Podręcznik Gentoo 2006.0 dla architektury PPC

Spis treści:

• Instalacja Gentoo
  Naucz się instalować Gentoo!
  1. O instalacji Gentoo Linux
     Wprowadzenie do opisanego w dalszych rozdziałach procesu instalacji Gentoo.
  2. Wybór medium instalacyjnego
     Wybieramy w jaki sposób chcemy zainstalować Gentoo. Opisujemy tu różne media, za pomocą których można zainstalować Gentoo.
  3. Konfigurowanie sieci
     Aby mieć możliwość ściągnięcia z Internetu najnowszych źródeł programów należy najpierw skonfigurować połączenie sieciowe.
  4. Przygotowywanie dysków
     Opis tworzenia partycji, na których zostanie zainstalowane Gentoo.
  5. Wypakowywanie plików instalacyjnych Gentoo
     Gentoo instaluje się przez tzw. pliki etapów (stage). W tym rozdziale opisujemy wypakowywanie tych plików i wstępną konfigurację Portage.
  6. Instalowanie systemu podstawowego
     Przed przystąpieniem do instalacji z wybranego etapu trzeba nagrać system podstawowy.
  7. Konfigurowanie jądra
     Jądro Linux jest rdzeniem każdej dystrybucji. W tym rozdziale wytłumaczymy, jak je skonfigurować.
  8. Konfigurowanie systemu
     Dla poprawnej pracy systemu, należy wyedytować kilka ważnych plików konfiguracyjnych.
  9. Instalowanie narzędzi systemowych
     W tym rozdziale pomożemy w wybraniu i instalacji najważniejszych narzędzi potrzebnych do prawidłowego funkcjonowania systemu.
  10. Konfiguracja bootloadera
      Na platformie PPC dostępnych jest kilka programów ładujących (boot loader). W tym rozdziale przeprowadzamy użytkownika przez proces instalacji i konfiguracji niektórych z nich.
  11. Zakończenie instalacji Gentoo
      Na koniec musimy jeszcze utworzyć jedno lub kilka dodatkowych kont użytkowników.
  12. I co dalej?
      Gentoo zostało zainstalowane, ale co dalej?
• Praca z Gentoo
  Nauka pracy z Gentoo: instalowania programów, modyfikowania zmiennych, zmiany różnych domyślnych zachowań Portage, itp.
  1. Wprowadzenie do Portage
     Wszystko to, co trzeba wiedzieć na temat Portage, aby móc przy jego pomocy skutecznie zarządzać systemem.
  2. Flagi USE
     Flagi USE są bardzo ważnym aspektem pracy z Gentoo. W tym rozdziale omawiamy pracę z nimi oraz tłumaczymy to jak wpływają one na pracę systemu.
  3. Funkcje Portage
     Ten rozdział pomaga odkryć dodatkowe funkcje Portage.
  4. Skrypty startowe
     Gentoo używa specjalnego formatu skryptów startowych, które pozwalają na budowanie zależności oraz zarządzanie wirtualnymi skryptami startowymi. Rozdział ten pokaże jak je tworzyć i jak nimi zarządzać.
  5. Zmienne środowiskowe
     Zarządzanie zmiennymi środowiskowymi w Gentoo jest bardzo łatwe. W tym rozdziale opiszemy najczęściej używane zmienne oraz wytłumaczymy jak je modyfikować.
• Praca z Portage
  Rozdział ten odkrywa wnętrze Portage, omawiamy w nim narzędzia do zarządzania programami w Gentoo.
  1. Pliki i katalogi
     Omawiamy tu strukturę i miejsca przechowywania plików konfiguracyjnych używanych przez Portage.
  2. Konfigurowanie Portage
     Proces konfigurowania samego systemu Portage poprzez zmianę odpowiednich plików konfiguracyjnych i zmiennych środowiskowych.
  3. Mieszanie różnych gałęzi Portage
     Oprogramowanie w Gentoo, w zależności od stopnia przetestowania i używanej architektury, jest podzielone na kilka gałęzi. W rozdziale tym omawiamy proces konfigurowania i dostosowywania tych gałęzi do określonych potrzeb.
  4. Dodatkowe narzędzia Portage
     Portage zawiera sporo narzędzi, które znacznie ułatwiają codzienną pracę z nim. W tym rozdziale opisujemy kilka najważniejszych, np. dispatch-conf.
  5. Pozostawiając oficjalne drzewo Portage
     Rozdział ten pokazuje kilka sztuczek związanych z codzienną pracą w Gentoo, m.in. tworzenie własnego drzewa Portage, synchronizowanie tylko wybranych kategorii, czy wstrzykiwanie (inject) pakietów.
• Konfiguracja sieci w Gentoo
  Szczegółowy opis zagadnień sieciowych w Gentoo
  1. Wprowadzenie
     Opis szybkiego i sprawnego skonfigurowania interfejsu sieciowego w większości środowisk.
  2. Zaawansowana konfiguracja
     Przed przejściem do modularnej pracy w sieci musimy nauczyć się zasad działania konfiguracji.
  3. Modularna praca w sieci
     Gentoo zapewnia wiele różnych rozwiązań sieciowych, w tym rozdziale omawiamy konfigurację różnych klientów DHCP, bonding, bridging oraz sieci VLAN.
  4. Połączenia bezprzewodowe
     To nie jest prosta sprawa, na szczęście zwykle udaje się jednak połączyć.
  5. Dodawanie możliwości
     Osoby czujące się na siłach mogą znacznie rozszerzyć funkcje swojej sieci.
  6. Zarządzanie siecią
     Dobry rozdział dla posiadaczy laptopów, którzy bez przerwy przemieszczają komputer między sieciami.

A. Instalacja Gentoo

1. O instalacji Gentoo Linux

1.a. Wprowadzenie

Witaj!

Po pierwsze witamy w Gentoo. Wkraczasz w świat szerokich możliwości i dużej wydajności. Możliwość wyboru to podstawowa zaleta naszej dystrybucji. Podczas instalacji można zdecydować jak dużą część systemu pragnie się zbudować samodzielnie, który program logujący ma pracować w systemie itd.

Gentoo to szybka i nowoczesna dystrybucja. Do jej głównych zalet należą przejrzystość i elastyczność. Tworzymy je jako wolne oprogramowanie i staramy się nie ukrywać niczego przed użytkownikiem. Portage, czyli nasz system zarządzania pakietami napisaliśmy w Pythonie, dzięki czemu można z łatwością przeglądać i modyfikować jego kod tak, aby dostosować go do swoich potrzeb. Gentoo jest oparte głównie na pakietach źródłowych, ale posiada również wsparcie dla pakietów prekompilowanych. Cała konfiguracja odbywa się za pomocą zwyczajnych plików tekstowych. Podsumowując: Gentoo to pełna otwartość.

Niezwykle istotne jest zrozumienie, czemu możliwość wyboru jest aż tak ważna. Nie próbujemy zmuszać użytkowników do robienia czegoś, czego nie chcą. Jeśli uważasz, że w jakimś przypadku powinniśmy, powiadom nas o tym.

Jak przebiega instalacja?

Proces instalacji Gentoo można podzielić na 10 etapów, opisanych odpowiednio w rozdziałach 2 - 11. Każdy z nich kończy się w określonym momencie:

• Po ukończeniu etapu pierwszego użytkownik znajduje się wewnątrz w pełni skonfigurowanego i przygotowanego do pracy środowiska instalacyjnego.
• Po ukończeniu etapu drugiego możemy korzystać z właśnie skonfigurowanego łącza internetowego (jeśli jest taka potrzeba, to opcjonalne rozwiązanie).
• Po ukończeniu etapu trzeciego dyski i partycje w komputerze są gotowe do zainstalowania Gentoo.
• Po ukończeniu etapu czwartego środowisko instalacyjne jest w pełni przygotowane i można zalogować się do systemu.
• Po ukończeniu etapu piątego są zainstalowane wszystkie podstawowe pakiety.
• Po ukończeniu etapu szóstego jądro Linuksa jest przygotowane do pracy.
• Po ukończeniu etapu siódmego mamy naniesione odpowiednie poprawki na większość plików konfiguracyjnych.
• Po ukończeniu etapu ósmego mamy zainstalowane niezbędne narzędzia systemowe.
• Po ukończeniu etapu dziewiątego mamy zainstalowany i skonfigurowany bootloader. Możemy też zalogować się do świeżo zainstalowanego systemu.
• Po ukończeniu etapu dziesiątego proces instalacji został zakończony i można przystąpić do odkrywania ogromnych możliwości Gentoo.

Za każdym razem gdy użytkownik będzie zmuszony do wybrania jednej z kilku opcji postaramy się jak najlepiej przedstawić wady i zalety każdego z rozwiązań. Następnie będziemy kontynuować omawianie procesu instalacji opisując kolejno wybór domyślny, a następnie wszystkie alternatywne możliwości. Domyślne opcje nie są tymi zalecanymi, po prostu przy pisaniu dokumentacji zakładamy, że wybierze je większość użytkowników.

Część dokumentacji jest opcjonalna. Zwykle konieczność korzystania z niej wynika z wcześniejszych wyborów użytkownika i jeśli nie dotyczy naszego przypadku spokojnie możemy ją pominąć.

Co mamy do wyboru?

Gentoo można zainstalować na wiele różnych sposobów. Najczęściej wybierana metoda to ta przy użyciu jednej z naszych płyt instalacyjnych. Istnieje również możliwość przeprowadzenia tego procesu poprzez już zainstalowaną dystrybucję, inną uruchamialną płytę (np. Knoppix), środowisko uruchamiane z sieci (netmount), czy dyskietkę ratunkową.

W tym Podręczniku omawiamy instalację przy użyciu płyt z instalatorem Gentoo, które zawierają wszystkie narzędzia konieczne do instalacji systemu Gentoo. Do wyboru mamy dwa rodzaje płyt instalacyjnych, zwyczajną płytę instalacyjną oraz LiveCD. Płyta instalacyjna zawiera jedynie minimum wymagane do zainstalowania Gentoo Linux. LiveCD jest w pełni kompletnym środowiskiem Gentoo Linux i może zostać użyte do wielu zadań, w tym do instalacji samego systemu. LiveCD na razie dostępny jest wyłącznie na architekturę x86, więc dokument ten w innych przypadkach opisywał będzie instalacje z użyciem uniwersalnej płyty instalacyjnej.

Taka metoda instalacji nie zapewnia najnowszych wersji pakietów. Opis pobierania najnowszych źródeł programów z Internetu znajduje się w zwykłym Podręczniku Gentoo.

Przewodnik po alternatywnych metodach instalacji to dobre źródło informacji na temat mniej konwencjonalnych sposobów instalowania Gentoo. Ponadto warto zapoznać się z dokumentem zawierającym przydatne rady dotyczące instalacji Gentoo. Zaawansowani użytkownicy, którzy uważają, że w Podręczniku proces instalacji jest omówiony zbyt rozwlekle powinni skorzystać z dokumentu opisującego wszystkie czynności w mocno skrótowej formie (quick install how-to), który znajduje się w naszych zasobach dokumentacji.

Problemy?

Jeśli w czasie instalacji pojawi się jakiś problem (lub wystąpią błędy w dokumentacji) zachęcamy do odwiedzenia strony projektu Gentoo Release Engineering, naszej bugzilli i sprawdzenia czy został on już zgłoszony. Jeśli jeszcze o nim nie wiemy prosimy o wypełnienie i wysłanie odpowiedniego formularza. Nie należy się bać deweloperów, do których zostanie przypisany raport, zwykle nie gryzą.

Pomimo że spora część Podręcznika jest wspólna dla wszystkich architektur istnieją w nim również odnośniki do poszczególnych z nich. Staramy się ograniczać to zjawisko do minimum, aby uniknąć dezorientowania czytelników.

Jeśli nie wiadomo czy kłopot leży po stronie systemu (pewne rzeczy mogą nie być dostatecznie przetestowane) czy po stronie użytkownika (czasami problem może wyniknąć z nieuważnego czytania opisu) warto odwiedzić kanał #gentoo na sieci irc.freenode.net. Zapraszamy tam wszystkich użytkowników.

Odpowiedzi na wiele pytań związanych z Gentoo znajdują się w naszym FAQ. Warto również przejrzeć FAQ na naszym forum. Jeśli odpowiedzi na pytanie nie ma w żadnym z nich zawsze można zapytać maniaków przesiadujących na kanale #gentoo (w sieci freenode), zwykle są dobrze poinformowani.

1.b. Szybka instalacja programów za pomocą GRP

Co to jest "Gentoo Reference Platform"?

GRP (Gentoo Reference Platform) to zestaw prekompilowanych pakietów, które przygotowujemy dla użytkowników wraz z każdym wydaniem naszej dystrybucji. Zestaw ten umożliwia błyskawiczną instalację tych programów w ich systemach. Znajdują się tam nie tylko te pakiety, które są konieczne do działania podstawowego systemu Gentoo, dodajemy także kompilacje większych programów i środowisko, np. xorg-x11, GNOME, OpenOffice, Mozillę.

Zestaw tych pakietów jest aktualizowany wraz z każdym wydaniem Gentoo, pomiędzy nimi wersje pozostają te same. Można je wykorzystać do szybkiej instalacji podstawowego środowiska, a następnie zaktualizować je do najnowszej wersji już mogąc w nim pracować.

Jak Portage obsługuje pakiety GRP?

Drzewo Portage to kolekcja ebuildów, czyli plików zawierających wszystkie informacje dotyczące określonych pakietów, takie jak ich opis, adres strony internetowej projektu, odnośniki do kodów źródłowych, instrukcje dotyczące ich kompilacji, czy ich zależności. W naszym przypadku drzewo to musi być zsynchronizowane z konkretnym zestawem GRP, a wersje ebuildów w drzewie muszą zgadzać się z wersjami prekompilowanych pakietów.

W związku z tym z zalet GRP można skorzystać wyłącznie podczas instalacji Gentoo. GRP nie są dostępne dla osób chcących zainstalować najnowsze wersje wszystkich programów.

Czy GRP są dostępne?

Nie zapewniamy GRP dla wszystkich architektur. Nie oznacza to, że Portage nie jest tam przygotowane do ich obsługi, po prostu nie mamy zasobów, aby je dla danej architektury zbudować.

Obecnie GRP są dostępne dla następujących architektur:

• Architektura amd64 (amd64)
• Architektura ppc (ppc32, ppc64)
• Architektura sparc (sparc64)
• Architektura x86 (athlon, athlon-xp, athlon-mp, pentium-pro, pentium2, pentium3, pentium4, pentium-m). Uwaga: Pakiety przeznaczone są dla i686 i dostępne są na LiveCD.

Jeśli jakiejś architektury nie ma na liście, oznacza to, że pakiety GRP nie są dla niej w danym momencie dostępne.

To tyle tytułem wstępu, przechodzimy do uruchamiania systemu z uniwersalnej płyty instalacyjnej/z LiveCD.

2. Wybór medium instalacyjnego

2.a. Wymagania sprzętowe

Wprowadzenie

Zanim zaczniemy musimy ustalić jakie wymagania sprzętowe powinien spełniać komputer, aby pomyślnie zainstalować na nim Gentoo.

Wymagania sprzętowe

Należy również zapoznać się z dokumentem Gentoo PPC FAQ, w którym znajdziemy odpowiedzi na najczęściej zadawane pytania związane z instalacją oraz z samym komputerem PowerPC.

2.b. Płyta instalacji uniwersalnej

Wstęp

Gentoo można zainstalować przy pomocy archiwum o nazwie stage3, który zawiera spakowany podstawowy system Gentoo, za pomocą którego można skonfigurować w pełni funkcjonalne środowisko.

Instalacja z użyciem plików stage1 i stage2 jest opisana w Gentoo FAQ.

W tym dokumencie będziemy używali pliku stage3. Jeśli użytkownik zechce użyć pliku stage1 lub stage2, wtedy należy podążyć za wskazówkami instalacji z Podręcznika Gentoo.

Płyta instalacji uniwersalnej

Płyta instalacyjna jest bootowalna i zawiera w pełni funkcjonalne środowisko Gentoo. Pozwala to na uruchomienie Linuksa z płyty CD. Podczas ładowania wykrywany jest sprzęt zainstalowany w komputerze, a następnie odpowiednie moduły są ładowane. Płyty instalacyjne są tworzone przez deweloperów Gentoo.

Obecnie dostępne są następujące płyty instalacyjne:

• "Gentoo Universal Installation CD" - zawiera wszystko co potrzeba do instalacji Gentoo. Dostarcza ona pliki "stage" dla najpopularniejszych architektur, kod źródłowy różnych aplikacji oraz instrukcje instalacji dla naszej architektury
• "Gentoo Minimal Installation CD" - zawiera tylko minimalne środowisko, które pozwala na załadowanie systemu oraz konfigurację sieci, aby móc połączyć się z Internetem. Nie zawiera żadnych dodatkowych plików i nie może być użyta podczas instalacji opartej na tym dokumencie.

Gentoo również dostarcza tzw. Package CD. To nie jest płyta instalacyjna ale dodatkowe źródło, które można wykorzystać podczas instalacji systemu Gentoo. Zawiera ona fabrycznie skompilowane pakiety (tzw. zbiór GRP), które umożliwiają łatwą i szybką instalację dodatkowych aplikacji (takich jak OpenOffice.org, KDE, GNOME,...) natychmiast po instalacji Gentoo, ale tuż przed zaktualizowaniem drzewa Portage.

Jak użyć płytę Package CD zostanie wyjaśnione później w tym dokumencie.

2.c. Pobieranie, nagrywanie i uruchamianie uniwersalnej płyty instalacji Gentoo

Pobieranie i nagrywanie płyty instalacyjnej

Wszystkie obrazy płyt instalacji uniwersalnej (również płyt Package CD) znajdują się na naszych serwerach lustrzanych w katalogu releases/ppc/2006.0/installcd; obraz płyt Package CD znajduje się w katalogu releases/ppc/2006.0/packagecd.

Wewnątrz tych katalogów znajduje się zbiór plików ISO. Są to pełne i gotowe do nagrania obrazy płyt CD.

Po ściągnięciu pliku należy sprawdzić czy nie zawiera żadnych błędów:

• Weryfikujemy poprawność pobranych plików ISO za pomocą porównania ich sum MD5 z tymi znajdującymi się na naszym serwerze lustrzanym (np. w pliku o nazwie install-x86-minimal-2005.1.iso.md5). Sumy MD5 dla pobranych plików można wygenerować przy pomocy narzędzia md5sum dla Linuksa, lub jego odpowiednika dla Windows. Sprawdzanie sum MD5 w Mac OS X jest opisane w dokumencie Gentoo PPC FAQ.
• Innym sposobem sprawdzania poprawności pobranych plików jest weryfikacja ich kryptograficznych sygnatur przy pomocy GnuPG. Należy otrzymać klucz publiczny, którego my używamy (0x17072058) przed przejściem dalej.

Pozyskujemy klucz publiczny za pomocą GnuPG:

$ gpg --keyserver subkeys.pgp.net --recv-keys 17072058

Następnie weryfikujemy sygnaturę.

$ gpg --verify <plik sygnatury> <plik iso>

Pobrane pliki ISO należy nagrywać w trybie RAW. To jak się go włącza zależy od programu, którego używamy. W Podręczniku opiszemy nagrywanie za pomocą programów cdrecord i K3B. Więcej informacji można znaleźć w dokumencie Gentoo FAQ.

• Jeśli chodzi o cdrecord to wystarczy wpisać polecenie cdrecord dev=/dev/hdc <pobrany plik ISO>. Zamiast /dev/hdc należy podać odpowiednią ścieżkę do urządzenia CD-RW.
• W K3B trzeba wybierać z menu kolejno zakładki Tools > CD > Burn Image. Następnie wskazujemy nasz plik ISO i klikamy w przycisk Start.

Domyślnie: Uruchamianie płyt instalacyjnych za pomocą Yaboot

Na komputerach NewWorld wystarczy umieścić płytę instalacyjną w napędzie CD-ROM i ponownie uruchomić komputer. Kiedy zabrzmi dźwięk uruchamiania systemu należy wcisnąć przycisk C i przytrzymać go do czasu wczytania płyty.

Po załadowaniu płyty CD na ekranie pojawi się znak zachęty w postaci boot:

System dostarczany jest z jednym jądrem, ppc32, dla wszystkich podarchitektur. Zawiera on wkompilowane wsparcie dla wielu procesorów, jednak bez przeszkód można go używać w komputerach jednoprocesorowych.

Można tu również podać kilka dodatkowych opcji z jakim zostanie uruchomione wybrane jądro. Są to:

Aby czerpać pożytek z powyższych opcji, w linii boot:, powinniśmy wpisać ppc32, a następnie porządaną przez nas opcję. W poniższym przykładzie, zmusimy jądro do używania sterownika framebuffer OpenFirmware w miejsce sterownika specyficznego dla danego urządzenia.

boot: ppc32 video=ofonly

Jeżeli nie potrzebujemy dodawać żadnych opcji, po prostu wciskamy Enter w tym miejscu, a w pełni użyteczne środowisko Gentoo Linux zostanie załadowane z CD. Dalsze instrukcje zawarte są w rozdziale Czynności po uruchomienie.

Alternatywnie: Uruchamianie płyty instalacyjnej na Pegasosie

Na komputerach Pegasos wystarczy włożyć płytę do napędu, a następnie w SmartFirmware wpisać boot cd /boot/menu. Otworzy to małe menu, w którym można wybrać jedno z kilku domyślnych ustawień wyświetlania. Własne ustawienia podaje się w linii poleceń, tak jak w przykładzie z Yaboot powyżej. Dla przykładu: boot cd /boot/pegasos video=radeonfb:1280x1024@75 mem=256M. Domyślna lista możliwych opcji jądra (przydatna w przypadku gdyby coś poszło naprawdę źle) wygląda następująco: console=ttyS0,115200 console=tty0 init=/linuxrc looptype=squashfs loop=/livecd.squashfs udev nodevfs cdroot root=/dev/ram0.

Alternatywnie: Uruchamianie płyty za pomocą BootX

Na komputerach OldWorld nie jest możliwe skorzystanie z części uruchamialnej płyty instalacyjnej. Najprostszym rozwiązaniem tego problemu jest użycie MacOS 9 lub wcześniejszego do przeprowadzenia bootstrapu systemu, co umożliwia narzędzie o nazwie BootX.

Po pierwsze należy pobrać BootX i rozpakować archiwum. Następnie należy skopiować BootX Extension do katalogu Extensions Folder i panel sterowania BootX do katalogu Control Panels. Oba te katalogi znajdują się w katalogu systemowym MacOS. Następnie należy utworzyć katalog "Linux Kernels" w tymże folderze systemowym i skopiować do niego jądro ppc32 z płyty instalacyjnej. Na koniec należy jeszcze przekopiować plik ppc32.igz z płyty instalacyjnej również do folderu systemowego MacOS.

Aby przygotować BootX należy uruchomić jego panel sterowania i wybrać menu o nazwie "Options", w którym należy zaznaczyć opcję Use Specified RAM Disk i wybrać plik ppc32.igz z folderu systemowego. Następnie trzeba wrócić na początkowy ekran i upewnić się, że wybrany rozmiar ramdysku ma co najmniej 32000. Na koniec można dodać jądru kilka parametrów argumentów, tak jak zrobimy to poniżej:

cdroot root=/dev/ram0 init=linuxrc loop=image.squashfs looptype=squashfs console=tty0

Następnie należy upewnić się, że wybrane ustawienia są prawidłowe i je zapisać. Oszczędza to trochę pisania w przypadku, gdy proces uruchamiania się nie powiedzie. Następnie należy wcisnąć przycisk Linux na górze okna w celu uruchomienia środowiska instalacyjnego z płyty i przejść do akapitu czynności po uruchomieniu.

Czynności po uruchomieniu

Pojawi się znak zachęty roota ("#"). Można zmieniać konsole, służą do kombinacje klawiszy Alt-F2, Alt-F3, itp. Na pierwszą wraca się przy pomocy Alt-F1. Na niektórych komputerach Apple konieczne jest wciśnięcie dodatkowo przycisku fn.

Jeśli instalujemy Gentoo w systemie, w którym mamy klawiaturę inną niż US musimy wcisnąć F2, aby przejść do trybu potwierdzania kolejnych czynności, a następnie postępować zgodnie ze wskazówkami na ekranie. Jeśli nie wybierzemy nowego mapowania w ciągu 10 sekund, zostanie załadowane to domyślne, czyli amerykańskie.

(PPC korzysta z map takich jak x86, mapy klawiszy ADB dla ppc/mac nie
są obsługiwane)
# ls /usr/share/keymaps/i386

Następnie ładujemy wybraną mapę klawiszy:

# loadkeys be-latin1

Kolejna część dokumentu to Konfigurowanie dodatkowego sprzętu.

Konfigurowanie dodatkowego sprzętu

W czasie uruchamiania system spróbuje wykryć sprzęt i załadować odpowiednie sterowniki. Zazwyczaj czyni to prawidłowo, ale czasami mogą zdarzyć się problemy i nie wszystkie moduły zostaną aktywowane. Gdy zawiedzie skanowanie PCI musimy ręcznie załadować odpowiednie moduły.

W poniższym przykładzie spróbujemy załadować moduł airport. Ten moduł wspiera tylko stary karty Airport (802.11b). W chwili obecnej AirportExtreme (802.11g) nie znajduje się na płycie instalacyjnej.

# modprobe airport

Na starszych komputerach iMac, karta sieciowa nie jest poprawnie wykrywana. Powinniśmy w takim przypadku załadować moduł sterownika BMAC:

# modprobe bmac

Opcjonalnie: Poprawianie wydajności twardego dysku

Zaawansowanych użytkowników na pewno zainteresuje możliwość zwiększenia wydajności dysków twardych IDE za pomocą programu hdparm. Obecną wydajność można przetestować za pomocą parametrów -tT (kilkukrotne wykonanie polecenia zwiększa precyzję pomiaru):

# hdparm -tT /dev/hda

Aby poprawić wydajność można wykorzystać któryś z poniższych przykładów (lub eksperymentować samodzielnie). Oczywiście musimy zastąpić /dev/hda ścieżką do naszego dysku.

Aktywowanie DMA:
# hdparm -d 1 /dev/hda
Aktywowanie DMA oraz zestawu bezpiecznych opcji poprawiających
wydajność:
# hdparm -d 1 -A 1 -m 16 -u 1 -a 64 /dev/hda

Opcjonalnie: Konta użytkowników

Jeśli planujemy umożliwienie innym osobom dostępu do środowiska instalacyjnego lub zamierzamy korzystać z irssi nie uruchomionego z przywilejami roota musimy stworzyć dodatkowe konta.

Najpierw jednak należy zmienić hasło roota. Dokonuje się tego przy pomocy polecenia passwd:

# passwd
New password: (Podajemy nowe hasło)
Re-enter password: (Potwierdzamy nowe hasło)

Aby stworzyć konto użytkownika musimy najpierw podać jego parametry, a następnie ustawić hasło. Skorzystamy przy tym z poleceń useradd oraz passwd. W przykładzie stworzymy użytkownika o nazwie "rane".

# useradd rane
# passwd rane
New password: (Podajemy hasło)
Re-enter password: (Potwierdzamy hasło)

Aby przełączyć się z konta roota na nowo utworzone konto użytkownika korzystamy z polecenia su:

# su - rane

Opcjonalnie: Dostęp do dokumentacji podczas instalowania Gentoo

Jeśli zamierzamy podczas instalacji korzystać z Podręcznika Gentoo (obojętnie czy nagranego na CD czy znajdującego się w Internecie) powinniśmy dodać do tych celów konto zwykłego użytkownika, tak jak opisaliśmy to przed chwilą, a następnie przejść przy pomocy kombinacji klawiszy Alt-F2 na nowy terminal i tam się zalogować.

Do przeglądania dokumentacji nagranej na CD służą programy links oraz links -g:

# links /mnt/cdrom/docs/handbook/html/index.html

Najnowszą i najlepszą dostępną wersją Podręcznika Gentoo jest ta znajdująca się na naszej stronie internetowej. Polecamy korzystanie właśnie z tej wersji. Podobnie jak w przypadku dokumentacji nagranej na CD można użyć do tego programu links, pod warunkiem oczywiście, że mamy już skonfigurowane i działające połączenie z Internetem.

# links http://www.gentoo.org/doc/pl/handbook/handbook-ppc.xml

Na pierwszy terminal powracamy przy pomocy kombinacji klawiszy Alt-F1.

Opcjonalnie: Uruchamianie demona SSH

Aby umożliwić innym osobom dostęp do naszego komputera podczas instalacji (by mogły nam pomóc w konfigurowaniu Gentoo lub nawet przeprowadzić cały proces za nas) musimy dodać im odpowiednie konta użytkowników lub nawet podać hasło roota (nie należy tego robić jeśli nie jest to osoba, której ufa się całkowicie).

Demona SSH uruchamia się następującym poleceniem:

# /etc/init.d/sshd start

Korzystanie z sshd jest możliwe tylko wtedy, gdy komputer jest połączony z Internetem. Połączenie nawiążemy dzięki wskazówkom spisany, w rozdziale zatytułowanym konfiguracja sieci.

3. Konfigurowanie sieci

3.a. Czy potrzebujemy dostępu do sieci?

Kto nie potrzebuje dostępu do internetu?

Generalnie nie jest potrzebny dostęp do internetu, jeśli instalujemy Gentoo przy użyciu uniwersalnej płyty instalacyjnej lub LiveCD. Istnieją jednak sytuacje, w który dostęp do sieci może być niezbędny:

• Pliki stage3 dostarczone na płycie nie odpowiadają naszej architekturze i konieczne jest pobranie poprawnego pliku.
• Plik stage 3 generowany przez LiveCD nie odpowiada naszej architekturze i koniecznie jest pobranie poprawnego pliku.
• Musimy zainstalować specyficzny program do łączenia się z internetem, który nie jest dostępny na uniwersalnej płycie instalacyjnej lub na LiveCD, a posiada wsparcie na naszej płycie (przykładowo można połączyć się z siecią przy użyciu tej płyty, jednak nie ma na niej potrzebnych źródeł).
• Potrzebujemy dodatkowego wsparcia w czasie instalacji systemu (z użyciem SSH, czy też poprzez rozmowy na kanałach IRC).

Czy potrzebujemy dostępu do sieci?

W przypadku gdy używamy uniwersalnej płyty instalacyjnej sprawdźmy czy na płycie znajduje się odpowiedni dla naszej architektury plik stage3. Wszystkie pliki stage znajdują się w katalogu /mnt/cdrom/stages. Jeśli żaden plik nie odpowiada naszemu sprzętowi, możemy użyć innego przeznaczonego dla architektury kompatybilnej z naszą.

Plik stage 3 generowany przez instalator znajdujący się na LiveCD optymalizowany jest dla komputerów i686 lub lepszy. Posiada on również wsparcie dla NPTL. Plik stage 3 budowany przez instalator znajdujący się na LiveCD, przeznaczonych dla architektury amd64, posiada generalne wsparcie tej architektury oraz podobnie jak w poprzednim przypadku posiada wsparcie dla NPTL.

Jeśli nie znajdziemy pliku stage3, który moglibyśmy wykorzystać, konieczne będzie połączenie z internetem, w celu jego pobrania.

Podsumowując, jeśli nie potrzebujemy połaczenia z internetem, możemy pominąć pozostałą cześć tego dokumentu i przejść bezpośrednio do rozdziału Przygotowywanie dysków. W innym przypadku kontynuujemy lekturę tego rozdziału.

3.b. Automatyczne wykrywanie sieci

Może po prostu to już działa?

Jeżeli komputer jest podłączony do sieci Ethernet z serwerem, DHCP jest bardzo prawdopodobne, że połączenie zostało skonfigurowane automatycznie. Dzięki temu od razu można skorzystać z wielu narzędzi sieciowych dostępnych na płycie instalacyjnej, takich jak ssh, scp, ping, irssi, wget czy links.

Jeśli sieć jest skonfigurowana prawidłowo to polecenie /sbin/ifconfig powinno wyświetlić oprócz lo także inne urządzenia, na przykład eth0:

# /sbin/ifconfig
(...)
eth0      Link encap:Ethernet  HWaddr 00:50:BA:8F:61:7A
          inet addr:192.168.0.2  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::50:ba8f:617a/10 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1498792 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1284980 errors:0 dropped:0 overruns:0 carrier:0
          collisions:1984 txqueuelen:100
          RX bytes:485691215 (463.1 Mb)  TX bytes:123951388 (118.2 Mb)
          Interrupt:11 Base address:0xe800

Opcjonalnie: Konfigurowanie proxy

Jeśli korzystamy z proxy, musimy skonfigurować je w czasie instalacji. Jest to bardzo proste, wystarczy zdefiniować odpowiednią zmienną, zawierającą z informacje o serwerze proxy.

W większości przypadków można zdefiniować tę zmienną przy pomocy jego domeny. Pokażemy to na przykładzie serwera proxy.gentoo.org i portu 8080.

(Jeśli proxy filtruje HTTP)
# export http_proxy="http://proxy.gentoo.org:8080"
(Jeśli proxy filtruje FTP)
# export ftp_proxy="ftp://proxy.gentoo.org:8080"
(Jeśli proxy filtruje RSYNC)
# export RSYNC_PROXY="rsync://proxy.gentoo.org:8080"

Jeżeli proxy wymaga podania hasła i nazwy użytkownika, należy użyć następującej składni:

http://username:password@proxy.gentoo.org:8080

Testowanie sieci

Jeśli chcemy się upewnić, że pakiety dochodzą do celu, możemy spróbować pingowania któregoś z serwerów DNS (z pliku /etc/resolv.conf) lub dowolnie wybranej strony WWW.

# ping -c 3 www.yahoo.com

Działa? Jeśli tak, można pominąć resztę tego rozdziału i bezpośrednio przejść do rozdziału Przygotowanie dysków. Jeśli nie, to pora zapoznać się z dalszą częścią tego tekstu.

3.c. Automatyczne konfigurowanie sieci

Niektóre media instalacyjne pozwalają na skorzystanie z narzędzia net-setup (dla typowych lub bezprzewodowych sieci) jeśli sieć nie zadziała od razu, adsl-setup (dla użytkowników ASDL) albo pptp (dla użytkowników PPTP - dostępne tylko dla architektury x86).

W przypadku gdy nośnik instalacyjny nie zawiera żadnego z wymienionych narzędzi, lub sieć wciąż nie funkcjonuje prawidłowo, należy przejść do akapitu Ręczna konfiguracja sieci.

• Użytkownicy typowych sieci Ethernet powinni przejść do podrozdziału Domyślnie: Używanie net-setup.
• Użytkownicy ASDL powinni przejść do paragrafu Alternatywnie: Używanie RP-PPPoE.
• A użytkownicy PPTP powinni przejść do części Alternatywnie: Używanie PPTP.

Domyślnie: Używanie net-setup

Najprostszą metodą konfigurowania sieci (poza automatyczną) jest ta zakładająca skorzystanie ze skryptu net-setup:

# net-setup eth0

Następnie należy udzielić odpowiedzi na serię dotyczących różnych parametrów sieci. Po zakończeniu wszystko powinno być skonfigurowane. Sprawdzamy połączenie tak jak opisano to wyżej. Jeśli wszystko działa to pora zacząć instalację Gentoo. Można pominąć resztę tego rozdziału i przejdź od razu do Przygotowywania dysków.

Jeśli sieć wciąż nie działa, przechodzimy do Ręcznej konfiguracji sieci.

Alternatywnie: Używanie RP-PPPoE

Jeśli do połączenia z Internetem potrzebne jest PPPoE, należy skorzystać z programu rp-ppoe nagranego na naszej płycie instalacyjnej. Skrypt adsl-setup służy do konfiguracji połączenia. Zostaniemy zapytani o urządzenie sieciowe podłączone do modemu asdl, nazwę użytkownika i hasło, oraz o IP serwerów DNS i o to czy potrzebujemy podstawowego firewalla.

# adsl-setup
# adsl-start

Jeśli coś pójdzie nie tak, należy sprawdzić czy w /etc/ppp/pap-secrets lub /etc/ppp/chap-secrets podano prawidłową nazwę użytkownika i hasło oraz upewnić się, że wybrano właściwe urządzenie sieciowe. Jeśli nie zostało ono wykryte, konieczne będzie ręczne załadowanie odpowiednich sterowników. W takim wypadku należy przejść do Ręcznej konfiguracji sieci, gdzie szerzej to omówimy.

Jeżeli wszystko zadziałało przechodzimy do przygotowania dysków.

Alternatywnie: Używanie PPTP

Jeśli potrzebna jest obsługa PPTP, należy skorzystać z pptpclient zamieszczonego na płycie instalacyjnej. Najpierw jednak należy dodać prawidłową nazwę użytkownika i hasło do /etc/ppp/pap-secrets lub /etc/ppp/chap-secrets:

# nano -w /etc/ppp/chap-secrets

Następnie konfigurujemy /etc/ppp/options.pptp:

# nano -w /etc/ppp/options.pptp

Po zakończeniu uruchamiamy program pptp (razem z niemożliwymi do ustawienia w options.pptp opcjami), aby połączyć się z serwerem:

# pptp <server ip>

Kolejny etap instalacji to Przygotowywanie dysków.

3.d. Ręczne konfigurowanie sieci

Ładowanie odpowiednich modułów sieciowych

W czasie uruchamiania płyty instalacyjnej system spróbuje wykryć sprzęt i załadować odpowiednie sterowniki. W większości przypadków wykrywanie przebiega prawidłowo, czasem jednak trzeba ręcznie skorygować niektóre ustawienia.

Jeśli zawiódł net-setup lub asdl-setup, możliwe, że nie została wykryta karta sieciowa. Oznacza to, że trzeba będzie ręcznie załadować odpowiedni sterownik.

Do wyświetlenia listy modułów kernela ze sterownikami dla urządzeń sieciowych używamy polecenia ls:

# ls /lib/modules/`uname -r`/kernel/drivers/net

Gdy znajdziemy odpowiedni sterownik dla karty sieciowej, ładujemy go przy pomocy polecenia modprobe:

(W przykładzie załadujemy moduł pcnet32)
# modprobe pcnet32

Aby sprawdzić czy karta sieciowa została wykryta, korzystamy z polecenia ifconfig. Prawidłowy rezultat powinien wyglądać mniej więcej tak:

# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr FE:FD:00:00:00:00
          BROADCAST NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

Następujący błąd oznacza, że karta nie została wykryta:

# ifconfig eth0
eth0: error fetching interface information: Device not found

Jeżeli w komputerze znajduje się kilka kilka kart sieciowych, będą one miały nazwy (kolejno) eth0, eth1, itp. Należy się upewnić, czy karta sieciowa której chcemy używać działa poprawnie i pamiętać o używaniu poprawnego nazewnictwa przy wykonywaniu czynności opisanych w dalszej części tego dokumentu. W Podręczniku zakładamy, że karta sieciowa nazywa się eth0.

Jeśli karta jest już prawidłowo rozpoznawana przez system, można ponownie użyć programów net-setup lub asdl-setup (tym razem powinny zadziałać) lub skorzystać z poniższych instrukcji, aby połączenie skonfigurować ręcznie.

Następnie przechodzimy do jednej z następujących części:

• Używanie DHCP w celu uzyskania IP
• Przygotowywanie bezprzewodowego dostępu - dla kart bezprzewodowych
• Terminologia sieciowa, (niemal) wszystko co trzeba wiedzieć o działaniu sieci
• Używanie ifconfig i route - opis ręcznej konfiguracji sieci

Używanie DHCP

DHCP (Dynamic Host Configuration Protocol) umożliwia automatyczne otrzymywanie informacji o parametrach sieci (adresu IP, maski sieciowej, adresów broadcast, bramy, serwerów nazw, etc.). Niestety z metody tej można skorzystać tylko wtedy, gdy w sieci działa serwer DHCP (lub gdy ISP udostępnia taką usługę). Jeśli tak jest, można automatycznie skonfigurować połączenie przy pomocy dhcpd:

# dhcpcd eth0
Część administratorów wymaga używania
nazwy hosta i domeny dostarczanej przez serwer DHCP.
W tym przypadku używamy
# dhcpcd -HD eth0

Jeśli to zadziała (sprawdzamy pingując jakiś serwis internetowy, np. Google), wszystko jest gotowe i można pominąć resztę tego rozdziału i przejść bezpośrednio do Przygotowywania dysków.

Przygotowanie bezprzewodowego dostępu

Jeśli używamy karty wireless (802.11), musimy ją skonfigurować. Aby poznać aktualne ustawienia skorzystamy z polecenia ifconfig. Rezultat wygląda zwykle tak:

# iwconfig eth0
eth0      IEEE 802.11-DS  ESSID:"GentooNode"
          Mode:Managed  Frequency:2.442GHz  Access Point: 00:09:5B:11:CC:F2
          Bit Rate:11Mb/s   Tx-Power=20 dBm   Sensitivity=0/65535
          Retry limit:16   RTS thr:off   Fragment thr:off
          Power Management:off
          Link Quality:25/10  Signal level:-51 dBm  Noise level:-102 dBm
          Rx invalid nwid:5901 Rx invalid crypt:0 Rx invalid frag:0 Tx
          excessive retries:237 Invalid misc:350282 Missed beacon:84

W większości przypadków wystarcza zmodyfikowanie tylko dwóch opcji: ESSID (czyli nazwy sieci bezprzewodowej) oraz klucza WEP. Jeśli wyświetlone ESSID i Access Point są prawidłowe dla punktu dostępu i nie korzystamy z WEP, to połączenie już działa. Aby zmodyfikować ESSID lub dodać klucz WEP, skorzystamy z następujących poleceń:

(Polecenie zmieniające nazwę sieci na "GentooNode")
# iwconfig eth0 essid GentooNode

(Polecenie ustawiające heksadecymalny klucz WEPT)
# iwconfig eth0 key 1234123412341234abcd

(Polecenie ustawiające klucz ASCII - poprzedzony "s:")
# iwconfig eth0 key s:some-password

Można zatwierdzić te ustawienia ponownie wykonując iwconfig. Jeżeli sieć już działa, należy przejść do konfiguracji opcji na poziomie IP, opisanych w kolejnym paragrafie, (Terminologia sieciowa) lub wykorzystać omówiony wcześniej program net-setup.

Terminologia sieciowa

Jeżeli wszystkie powyższe zabiegi zawiodły, można jeszcze ręcznie skonfigurować sieć. Nie jest to bardzo trudne. Opiszemy najpierw różne parametry sieci, których znajomość jest koniecz. Opowiemy także o tym, czym jest brama, do czego służy maska sieciowa, jak ustala się adres broadcast i do czego potrzebne są serwery nazw.

Komputery w sieci są identyfikowane na podstawie adresów IP (Internet Protocol adress). Każdy z nich jest kombinacją czterech liczb od 0 do 255. Cóż, przynajmniej my tak to widzimy. W rzeczywistości jest to ciąg 32 bitów (zer i jedynek). Pokażemy to na przykładzie:

Adres IP (liczby):   192.168.0.2
Adres IP (bity):     11000000 10101000 00000000 00000010
                     -------- -------- -------- --------
                        192      168       0        2

Adres IP musi być unikalny dla każdego komputera, przynajmniej w obrębie jednej sieci. Aby oddzielić maszyny w sieci i poza nią IP podzielono na dwie części: część sieci oraz część hosta.

Podział zapisany jest za pomocą maski sieciowej, czyli zbioru zer poprzedzonego zbiorem jedynek. Ta część adresu, którą można odwzorować w jedynkach jest częścią sieci, reszta to część hosta. Zazwyczaj maskę zapisujemy jak zwykły adres IP.

Adres IP:     192      168      0         2
            11000000 10101000 00000000 00000010
Maska:      11111111 11111111 11111111 00000000
               255      255     255        0
           +--------------------------+--------+
                       Sieć              Host

Innymi słowy, 192.168.0.14 wciąż jest częścią naszej przykładowej sieci, ale 192.168.1.2 już nie.

Adres broadcast składa się z części sieci takiej samej jak reszta komputerów oraz samych jedynek w części hosta. Każdy komputer nasłuchuje jego adresu IP, gdyż służy on do nadawania pakietów rozgłaszających.

Adres IP:      192      168      0         2
            11000000 10101000 00000000 00000010
Broadcast:  11000000 10101000 00000000 11111111
               192      168      0        255
           +--------------------------+--------+
                      Sieć               Host

Żeby móc "surfować" po Internecie trzeba wiedzieć, który komputer udostępnia z nim połączenie. Komputer ten nazywamy bramą. To zwyczajna maszyna, ze zwyczajnym adresem IP (np. 172.168.0.1).

Poprzednio napisaliśmy, że każdy komputer ma własny adres IP. Aby móc się z nim połączyć za pomocą nazwy potrzebna jest usługa tłumacząca domeny (czyli na przykład dev.gentoo.org) na adresy IP (np. 64.5.62.82). Nazywa się ona serwerem nazw. Aby z niej skorzystać dodajemy ją do pliku /etc/resolv.conf.

Czasami brama może służyć również jako serwer nazw. Jeśli nie, to trzeba wpisać adresy DNS-ów dostarczanych przez ISP.

Podsumowując: potrzebne są następujące informacje:

Używanie ifconfig i route

Konfiguracja sieci składa się z trzech etapów. Najpierw przypisujemy sobie adres IP za pomocą ifconfig. Potem konfigurujemy bramę programem route. Na końcu wpisujemy adresy serwerów nazw do /etc/resolv.conf.

Aby przypisać komputerowi adres IP, należy oprócz niego znać również broadcast i maskę. Następnie wykonuje się następujące polecenie, zastępując wpisy ${IP_ADDR} swoim IP, ${BROADCAST} adresem broadcast i ${NETMASK} maską:

# ifconfig eth0 ${IP_ADDR} broadcast ${BROADCAST} netmask ${NETMASK} up

Następnie ustawiamy bramę poleceniem route. Wpis ${GATEWAY} należy zastąpić jej adresem IP:

# route add default gw ${GATEWAY}

Następnie otwieramy swoim ulubionym edytorem (w przykładzie skorzystamy z nano) plik /etc/resolv.conf:

# nano -w /etc/resolv.conf

I wypełniamy go jak w przykładzie. Zamieniamy przy tym ${NAMESERVER1} oraz ${NAMESERVER2} adresami serwerów nazw:

nameserver ${NAMESERVER1}
nameserver ${NAMESERVER2}

Na koniec testujemy sieć pingując jakiś serwer internetowy (na przykład Google). Jeśli wszystko działa, można rozpocząć instalację Gentoo, rozpoczynając od Przygotowywania dysków.

4. Przygotowywanie dysków

4.a. Wprowadzenie do urządzeń blokowych

Urządzenia blokowe

Rzućmy okiem na aspekty Gentoo Linux, oraz ogólnie Linuksa związane z dyskami. Omówimy systemy plików, partycje oraz urządzenia blokowe. Następnie wspólnie przejdziemy przez proces podziału twardego dysku, aby jak najlepiej wykorzystać dostępne miejsce.

Zaczniemy od omówienia urządzeń blokowych. Najpopularniejszym z nich prawdopodobnie jest /dev/hda, reprezentujący w Linuksie pierwszy napęd IDE. Jeśli w komputerze znajdują się urządzenia SCSI, FireWWire, USB lub SATA, pierwszym takim dyskiem jest /dev/sda.

Urządzenia blokowe stanowią abstrakcyjny interfejs dysków. Programy użytkownika mogą z nich korzystać nie martwiąc się czy napędy są typu IDE, SCSI, czy nawet jakiegoś jeszcze innego. Przechowywane dane adresuje się jako ciąg 512-bajtowych bloków.

Partycje

Teoretycznie możliwe jest przeznaczenie na system całego dysku, zazwyczaj nie jest to jednak rozwiązanie zbyt praktyczne. Zamiast tego dzielimy napęd na mniejsze, łatwiejsze w zarządzaniu urządzenia blokowe. Na większości platform nazywane są one partycjami.

4.b. Projektowanie schematu podziału

Domyślny schemat podziału

Jeśli nie mamy ochoty samodzielnie rozrysowywać schematu podziału dysku, możemy skorzystać z domyślnego, z którego korzystamy w podręczniku:

Jeśli nasze rady dotyczące rozmiarów partycji oraz ich ilości, wydaja się interesujące, proponujemy kontynuowanie lektury. W przeciwnym wypadku proponujemy przejść od razu do paragrafu Domyślnie: Użycie mac-fdisk lub Alternatywnie: Użycie parted (zwłaszcza dla Pegasosa).

Jak dużo i jak wielkich?

Ilość partycji ściśle zależy od naszego środowiska. Na przykład jeśli administrujemy systemem mającym wielu użytkowników prawdopodobnie uznamy za stosowne oddzielenie /home, co poprawi bezpieczeństwo i uprości proces tworzenia kopii zapasowych. Jeżeli docelowym zastosowaniem instalowanego systemu jest serwer pocztowy to na osobnej partycji należy umieścić /var gdzie przechowywane są listy. Dobry wybór systemu plików może tu znacznie zwiększyć wydajność. Za to oddzielenie /opt jest dobrym rozwiązaniem na serwerach gier, gdyż większość używanego oprogramowania będzie instalowana właśnie tam. Powodami przyjęcia takiego rozwiązania są również bezpieczeństwo i łatwość tworzenia kopii zapasowych. Warto upewnić się, że partycja /usr będzie wystarczająco duża ponieważ będą tam znajdowały się nie tylko dane wszystkich aplikacji, ale również ważące 500 MB drzewo Portage.

Jak widać, wiele zależy od oczekiwanego rezultatu. Wydzielenie partycji lub woluminów ma wiele zalet:

• Mamy możliwość dostosowania jak najwydajniejszego w danym zastosowaniu systemu plików dla poszczególnych partycji lub woluminów.
• Zapełnienie całego wolnego miejsca na partycji przez wadliwie działające narzędzie nie ma szkodliwego wpływu na całość systemu.
• Jeśli to konieczne, można skrócić czas kontroli systemów plików, dzięki możliwości jednoczesnego dokonywania jej na kilku partycjach (ma to znaczenie zwłaszcza na sprzęcie z wieloma dyskami).
• Montując część partycji lub woluminów z opcjami read-only (tylko do odczytu), nosuid (ignorowane są bity setuid), noexec (ignorowane są bity wykonywalności) itd. można znacznie poprawić bezpieczeństwo.

Niestety zbyt rozbudowany podział niesie z sobą spore niebezpieczeństwo: źle zaplanowany zaowocuje pustkami na zbyt dużych i ciasnotą na zbyt małych partycjach. Ponadto dla dysków opartych na interfejsach SCSI jest limit maksymalnie 15 partycji.

4.c. Domyślnie: Partycjonowanie dysku za pomocą mac-fdisk

Aby utworzyć partycje skorzystamy z programu mac-fdisk:

# mac-fdisk /dev/hda

Zaczniemy od pozbycia się starych partycji, aby zrobić miejsce na nowy system. Skorzystamy w tym celu z polecenia d. Zapyta ono o numer kasowanych partycji. Zwykle pierwsza partycja na komputerach NewWorld (Apple_partition_map) nie może zostać skasowana.

Następnie zakładamy partycję Apple_bootstrap za pomocą b. Zostaniemy zapytani o początkowy blok. Jeśli poprzednio wybraliśmy na ten cel trzecią partycję, wpiszemy 3p.

Teraz stworzymy partycję wymiany za pomocą c. Program mac-fdisk ponownie zapyta o blok początkowy. Jako, że wcześniej skorzystaliśmy z 3, teraz wpiszemy 4p. Gdy zostaniemy zapytani o rozmiar wpisujemy 512M (lub inny na jaki się zdecydowaliśmy - 512MB to zalecane minimum). Następnie na pytanie o nazwę wpisujemy swap (koniecznie).

Żeby założyć partycję root, wpiszemy c, następnie 5p, aby wybrać blok od którego ma się zaczynać. Na pytanie o rozmiar ponownie wpiszemy 5p, mac-fdisk przydzieli jej całą pozostałą wolną przestrzeń Należy koniecznie nadać jej nazwę root.

Na zakończenie zachowujemy zmiany i opuszczamy mac-fdisk poleceniami w oraz q.

Następnie przechodzimy do paragrafu Zakładanie systemów plików.

4.d. Alternatywnie: Partycjonowanie dysku przy pomocy parted (zwłaszcza Pegasos)

Program parted, czyli Partition Editor, jest w stanie obsłużyć partycje HFS+ używane przez Mac OS i Mac OS X. Dzięki niemu można zmienić rozmiar obecnych partycji, aby zrobić miejsce na partycje dla Linuksa. W przykładzie poniżej opiszemy jednak partycjonowanie dysku jedynie dla maszyn Pegasos.

Zacznijmy od uruchomienia programu parted:

# parted /dev/hda

Jeśli dysk nie jest jeszcze podzielony na partycje, uruchamiamy mklabel amiga, aby utworzyć nową etykietę dla tego napędu.

Zawsze można wpisać polecenie print, aby wyświetlić aktualną tabelę partycji. Zmiany jakie wprowadzimy nie zostaną zapisane aż do czasu wyjścia z aplikacji. Przez cały czas można anulować omyłkowo wprowadzone zmiany przy pomocy kombinacji klawiszy Ctrl-C, która przerwie działanie programu.

Jeśli zamierzamy na swojej maszynie zainstalować również MorphOS musimy utworzyć system plików affs1, o nazwie "BI0" (BI zero) na początku napędu. Do zainstalowania kernela MorphOS'a wystarczy 32MB miejsca. Jeśli mamy Pegasos lub chcemy używać reiserfs, bądź xfs będzie trzeba ponadto trzymać na tej partycji kernel Linuksa (Pegasos II może zostać zabootowany z partycji ext2/ext3 lub affs1). Aby utworzyć partycję wpiszemy polecenie mkpart primary affs1 START END, gdzie START i END to obszar w megabajtach (np. 0 32 tworzy partycję o rozmiarze 32MB, zaczynającą się na 0 i kończącą na 32MB).

Musimy utworzyć dwie partycje dla Linuksa, jedną root, która będzie zawierała programy itp. i drugą, która będzie partycją wymiany (swap). Przed utworzeniem partycji root należy wybrać system plików jakiego będziemy używać. Mamy do wyboru ext2, ext3, reiserfs i xfs. Jeśli nie jesteśmy pewni co wybrać, polecamy użycie ext3. Wpisujemy polecenie mkpart primary ext3 START END aby utworzyć partycję ext3. Również tutaj zamieniamy START i END obszarem w MB, na którym chcemy utworzyć partycję.

Partycja swap powinna w większości przypadków mieć rozmiar równy ilości pamięci RAM w komputerze pomnożonej przez dwa. Jeśli nie będziemy uruchamiać jednocześnie ogromnej ilości programów, powinna wystarczyć ilość swap równa ilości RAM (jednak nie mniejsza niż zalecane 512MB). Aby stworzyć partycję wymiany wpiszemy polecenie mkpart primary linux-swap START END.

Wpisujemy polecenie print, a następnie wynotowujemy numery partycji, ponieważ będziemy ich potrzebować w dalszej instalacji.

Kiedy skończymy pracę w parted wyłączamy go wpisując po prostu quit.

4.e. Tworzenie systemów plików

Wprowadzenie

Po utworzeniu partycji nadszedł czas na założenie na nich systemów plików. Jeśli jest to obojętne jakie zostaną wybrane lub odpowiadają nam domyślne ustawienia w podręczniku, przejdźmy do paragrafu Zakładania systemów plików na partycjach. W przeciwnym wypadku polecamy dalszą lekturę aby dowiedzieć się więcej na ich temat.

Systemy plików?

Mamy do dyspozycji następujące systemy plików: ext2, ext3, XFS i ReiserFS. Wszystkie działają stabilnie na architekturze PPC.

Ext2 to sprawdzony i popularny linuksowy system plików, którego główną wadą jest to, że nie posiada księgowania. Powoduje to, iż jego regularne kontrole przy starcie systemu bywają długotrwałe. Obecnie istnieją nowoczesne systemy plików z księgowaniem, które można szybko sprawdzić i to właśnie te polecamy naszym użytkownikom. Księgowanie zapobiega długotrwałym kontrolom podczas uruchamiania systemu oraz ewentualnym błędom spójności danych.

Ext3 to odpowiednik ext2 posiadający księgowanie w trybach full oraz ordered, dzięki czemu w razie awarii dane odzyskiwane są błyskawicznie. Jest on bardzo dobrym i niezawodnym rozwiązaniem. Posiada ukrytą opcję korzystania z drzewa b, co znacznie poprawia wydajność niemal we wszystkich sytuacjach. W celu włączenia księgowania należy dodać parametr -O dir_index do linii poleceń programu mke2fs.Krótko mówiąc ext3 jest świetny.

ReiserFS to system plików oparty na drzewie B*, oferujący dużą wydajność. Przy wielu małych plikach (poniżej 4k) może być szybszy od ext3 nawet piętnastokrotnie. ReiserFS jest wysoce skalowalny i posiada księgowanie, a począwszy od jądra 2.4.18, charakteryzuje go niezawodność i użyteczność zarówno na partycjach ogólnego przeznaczenia jak i w ekstremalnych przypadkach, takich jak ogromne partycje, operacje na wielu bardzo małych, lub bardzo dużych plikach czy też operacje na katalogach zawierających dziesiątki tysięcy plików.

XFS to system plików z księgowaniem, w pełni wspierany w Gentoo Linux przez jądro xfs-sources. Jest bardzo funkcjonalny i zoptymalizowany do skalowalności. Zalecamy go wyłącznie do systemów z nowoczesnymi dyskami SCSI i/lub ciągłego zapisu danych z nieprzerwanym dostępem zasilania. Ponieważ XFS przechowuje dużo danych w pamięci RAM, źle zaprojektowane programy (te, które nie zachowują odpowiednich środków ostrożności podczas zapisywania plików na dysk, których niestety jest sporo) mogą doprowadzić w razie awarii systemu do utraty danych.

Zakładanie systemów plików na partycjach

Aby założyć na woluminie lub partycji system plików należy skorzystać z odpowiednich narzędzi:

Na przykład, aby założyć ext3 na partycji boot (w naszym przypadku /dev/hda4), należy wykonać następujące polecenia:

# mkfs.ext3 /dev/hda4

Aktywacja partycji wymiany

Aby utworzyć partycję wymiany skorzystamy z programu mkswap.

# mkswap /dev/hda2

Aby ją aktywować skorzystamy z polecenia swapon:

# swapon /dev/hda2

4.f. Montowanie

Po założeniu partycji i utworzeniu systemów plików nadszedł czas na ich zamontowanie. Służy do tego program mount. Nie zapominamy również utworzyć odpowiednich katalogów dla każdego z nich. Pokażemy to na przykładzie partycji boot oraz root:

# mkdir /mnt/gentoo
# mount /dev/hda4 /mnt/gentoo

Będziemy musieli zamontować system plików proc (wirtualny interfejs jądra) w /proc. Najpierw jednak nagramy trochę plików na nasze partycje.

Następnie przechodzimy do rozdziału Wypakowywanie plików instalacyjnych.

5. Wypakowywanie plików instalacyjnych Gentoo

5.a. Instalowanie tarballa stage

Ustawienie poprawnej daty i czasu

Na samym początku całego procesu instalacji należy sprawdzić datę/czas i ewentualnie je zaktualizować. Niezsychronizowany zegar może być przyczyną dziwnych błędów w przyszłości!

Aby zweryfikować aktualną datę/czas, uruchamiamy date:

# date
nie sie 21 01:56:26 UTC 2005

Jeżeli wyświetlane data i czas są złe, musimy je uaktualnić poleceniem date MMDDggmmRRRR (Miesiąc, Dzień, godzina, minuta i Rok). Na tym etapie powinniśmy korzystać z czasu UTC. W późniejszym czasie będziemy mogli zdefiniować naszą strefę czasową. Na przykład, aby ustawić datę 29 marca 2005 roku, 16:21:

# date 032916212005

Podejmowanie decyzji

W następnym kroku należy wykonać instalację wybranego tarballa stage. Można go pobrać z Internetu lub, jeśli działamy z którejś płytki Gentoo Universal Installation CD, przekopiować z CD. Jeżeli mamy Universal CD i na płycie znajduje się stage którego chcemy używać ściąganie go z Internetu jest tylko niepotrzebną stratą czasu, gdyż pliki stage są takie same.

• Domyślnie: Użycie stage z Internetu.
• Alternatywnie: Wykorzystanie stage z płyty instalacyjnej.

5.b. Domyślnie: Użycie stage z Internetu

Pobieranie tarballa stage

Na początku przechodzimy do punktu montowania systemu plików Gentoo (zwykle jest to /mnt/gentoo):

# cd /mnt/gentoo

W zależności od medium instalacyjnego mamy do dyspozycji kilka narzędzi, za pomocą których możemy pobrać plik stage. Jeżeli mamy program links możemy wejść bezpośrednio na listę serwerów lustrzanych Gentoo i wybrać serwer, który znajduje się najbliżej.

Jeżeli nie mamy programu links, musimy skorzystać z przeglądarki lynx do tego celu. Aby używać serwera proxy musimy również wyeksportować zmienne http_proxy i ftp_proxy:

# export http_proxy="http://proxy.server.com:port"
# export ftp_proxy="http://proxy.server.com:port"

W dalszej części zakładamy, że do swojej dyspozycji mamy przeglądarkę links.

Przechodzimy do releases/, a następnie do katalogu odpowiedniej architektury (np. x86/) oraz wersji Gentoo (2006.0/) i na koniec do stages/. Znajdują się tam pliki stage dla wybranej architektury (czasem mogą być umieszczone w podkatalogach dla różnych podarchitektur). Wybieramy jeden i naciskamy D, aby go ściągnąć. Kiedy pobieranie dobiegnie końca wciskamy Q, aby wyjść z przeglądarki.

# links http://www.gentoo.org/main/en/mirrors.xml

(Jeżeli potrzebne jest proxy w links:)
# links -http-proxy serwer.proxy.com:8080 http://www.gentoo.org/main/en/mirrors.xml

Należy się upewnić, że posiadamy archiwum ze stage 3. Instalacje z użyciem stage 1 lub stage 2 nie są już wspierane.

Jeśli chcemy zweryfikować poprawność pobranych archiwów stage, musimy porównać wynik polecenia md5sum z sumami MD5 udostępnianymi na serwerze. Np. aby sprawdzić poprawność tarballa stage dla architektury x86:

# md5sum -c stage1-x86-2006.0.tar.bz2.md5
stage1-x86-2006.0.tar.bz2: OK

Rozpakowywanie tarballa Stage

Wypakowujemy pobrany plik stage przy pomocy tar:

# tar xvjpf /mnt/cdrom/stages/stage3-<subarch>-2006.0.tar.bz2

Należy użyć dokładnie tych samych przełączników (xvjpf). Opcja x oznacza wypakuj, v to wyświetl, aby widzieć co się dzieje podczas wypakowywania (ok, to jest opcjonalne), j służy do dekompresji archiwum bzip2, p to zachowuj uprawnienia, natomiast f podkreśla, że chcemy rozpakować to, co czytamy z pliku, a nie ze standardowego wejścia.

Gdy stage jest już zainstalowany, pora przejść do Instalacji Portage.

5.c. Alternatywnie: Wykorzystanie stage z płyty instalacyjnej

Rozpakowanie tarballa stage

Pliki stage umieszczone są na CD w katalogu /mnt/cdrom/stages. Aby obejrzeć ich spis korzystamy z polecenia ls:

# ls /mnt/cdrom/stages

Jeśli system zgłasza błąd to możliwe, że musimy najpierw zamontować CD-ROM:

# ls /mnt/cdrom/stages
ls: /mnt/cdrom/stages: No such file or directory
# mount /dev/cdroms/cdrom0 /mnt/cdrom
# ls /mnt/cdrom/stages

Teraz przechodzimy do punktu montowania Gentoo (zwykle /mnt/gentoo):

# cd /mnt/gentoo

Następnie wypakowujemy wybrany tarball. Użyjemy do tego celu tar. Przełączniki (-xvjpf) muszą być takie same! Należy pamiętać, że argument v jest opcjonalny i nie jest obsługiwany przez pewne wersje programu tar. W kolejnym przykładzie wykorzystujemy plik stage3-<podarchitektura>-2006.0.tar.bz2. Oczywiście jego nazwę należy odpowiednio zmodyfikować.

# tar -xvjpf /mnt/cdrom/stages/stage3-<subarch>-2006.0.tar.bz2

Gdy stage zostanie zainstalowany, przechodzimy do Instalacji Portage.

5.d. Instalacja Portage

Wypakowanie snapshota Portage

W tym rozdziale omówimy proces instalacji snapshota Portage, kolekcji plików, które informują Portage jakie programy można zainstalować, które profile są dostępne itp.

Ściąganie i instalowanie snapshota Portage

Przechodzimy do miejsca gdzie zamontowaliśmy system plików (zwykle /mnt/gentoo):

# cd /mnt/gentoo

Uruchamiamy links (lub lynx) i przechodzimy do listy mirrorów Gentoo. Wybieramy jeden z serwerów, najlepiej jak najbliższy naszej lokalizacji i przechodzimy do katalogu snapshots/. Ściągamy najnowszy snapshot Portage poprzez jego wybranie i naciśnięcie klawisza D.

# links http://www.gentoo.org/main/en/mirrors.xml

Teraz wychodzimy z przeglądarki naciskając klawisz Q. Plik snapshot znajduje się teraz w /mnt/gentoo. W następnym kroku wypakujemy snapshot Portage. Należy użyć dokładnie tych samych poleceń; ostatnia opcja to duża litera C, nie małe c.

(Zastępujemy wartość <data> to przez nas pożądaną)
# tar -xvjf /mnt/gentoo/portage-<data>.tar.bz2 -C /mnt/gentoo/usr

5.e. Konfigurowanie opcji kompilacji

Wprowadzenie

Jest wiele możliwych do skonfigurowania zmiennych wpływających na zachowanie Gentoo. Możemy je wprowadzać jako zmienne środowiskowe (poprzez export), ale wtedy nie zostaną zapisane na stałe. Zamiast tego Portage do zachowywania konfiguracji używa pliku konfiguracyjnego /etc/make.conf. Pora wziąć się za jego edycję.

Uruchamiamy ulubiony edytor (w przykładach używamy nano), którym wprowadzimy omawiane nieco dalej opcje optymalizacji.

# nano -w /mnt/gentoo/etc/make.conf

Plik make.conf.example ma charakterystyczną strukturę: linie z komentarzem rozpoczynają się od znaku "#", linie zawierające zmienne używają składni ZMIENNA="zawartość". Takiej samej składni używa także plik /etc/make.conf. Kilka z tych zmiennych zostało przedyskutowanych poniżej.

CHOST

Zmienna CHOST definiuje architekturę, pod którą za pomocą gcc będą kompilowane programy. Możliwe jej wartości:

Upewniamy się, czy na pewno dobrze ustawiliśmy zmienną CHOST. Na przykład, zmienna CHOST dla sparc64 to nadal sparc-unknown-linux-gnu, a nie sparc64-unknown-linux-gnu!

Użytkownicy zainteresowani bootstrapowaniem systemu z obsługą NPTL w architekturze x86 muszą ustawić CHOST na i586-pc-linux-gnu lub wyższy.

CFLAGS i CXXFLAGS

Zmienne CFLAGS i CXXFLAGS definiują flagi optymalizujące używane odpowiednio przez kompilator gcc C i C++. Choć generalnie określamy ich wartości tutaj, maksimum wydajności osiągniemy dopasowując je do każdego programu z osobna. Jest tak dlatego, że programy znacząco różnią się między sobą.

W make.conf należy zdefiniować flagi optymalizacji co do których jesteśmy przekonani, że w głównej mierze poprawią czas reakcji systemu. Nie przypisujemy pod tę zmienną ustawień eksperymentalnych; przesada w optymalizacji może spowodować, że programy zaczną źle funkcjonować (nagle przerywać działanie, lub nawet gorzej, wcale nie działać).

Nie będziemy tłumaczyć znaczenia wszystkich możliwych opcji optymalizacji. Wszystkie są wymienione w Podręczniku Online GNU lub stronę info gcc (info gcc -- działa tylko na systemach linuksowych). Plik make.conf.example sam zawiera dużo informacji i przykładów - należy go uważnie przeczytać.

Pierwszym ustawieniem jakim się tu zajmiemy jest flaga -march=, która określa docelową architekturę. Możliwe jej wartości są opisane jako komentarze w make.conf.example. Na przykład dla architektury x86 Athlon XP będzie to:

# Użytkownicy AMD64, którzy chcą mieć natywny system 64bit powinni używać flagi -march=k8
# Użytkownicy EM64T powinni wybrać march=nocona
-march=athlon-xp

Prosimy, upewnijcie się, że macie poprawnie ustawiony CHOST. Na przykład ustawienie CHOST dla sparc64 to sparc-unknown-linux-gnu, a nie sparc64-unknown-linux-gnu!

Drugim jest flaga -O (to jest duże O, nie zero), która określa klasę optymalizacji gcc. Dostępne klasy to s (optymalizacja rozmiaru), 0 (brak optymalizacji), 1, 2 lub 3 - coraz silniej optymalizujące (każda z nich używa tych samych flag, co poprzednia oraz dodaje własne). Jako przykład posłuży nam klasa optymalizacji 2:

-O2

Inne popularne flagi optymalizujące to -pipe (gcc używa potoków zamiast plików tymczasowych w komunikacji między różnymi etapami kompilacji) oraz -fomit-frame-pointer (w rejestrach nie będą przechowywane wskaźniki ramki dla funkcji, które ich nie wymagają).

Używanie flagi -fomit-frame-pointer może powodować poważne problemy podczas debugowania kodu!

Podczas definiowania CFLAGS i CXXFLAGS można łączyć kilka flag optymalizacji, na przykład w ten sposób:

CFLAGS="-march=athlon-xp -pipe -O2"   # Użytkownicy AMD64 powinni używać flagi march=k8
                                      # Użytkownicy EM64T powinni wybrać march=nocona
CXXFLAGS="${CFLAGS}"                  # Użycie tych samych ustawień dla obu zmiennych

MAKEOPTS

Za pomocą MAKEOPTS definiujemy jak wiele równoległych kompilacji będzie przeprowadzanych podczas przygotowywania pakietu do instalacji. Sugerowaną liczbą jest ilość procesorów w systemie powiększona o jeden, nie jest to jednak zawsze najlepsze wyjście.

MAKEOPTS="-j2"

Gotowi, do biegu, start!

Na koniec poprawiamy jeszcze odrobinę /mnt/gentoo/etc/make.conf i zapisujemy wyniki naszych prac (w nano za pomocą Ctrl-X). Teraz jesteśmy przygotowani na Instalację systemu podstawowego .

6. Instalowanie systemu podstawowego

6.a. Praca w chroot

Montowanie systemu plików /proc i /dev

Przemontowujemy system plików /proc do /mnt/gentoo/proc, aby umożliwić systemowi korzystanie z informacji dostarczanych przez jądro także w środowisku chrootowanym oraz ponownie montujemy system plików /dev w innym miejscu.

# mount -t proc none /mnt/gentoo/proc
# mount -o bind /dev /mnt/gentoo/dev

Opcjonalnie: Kopiowanie informacji o DNS

Jeśli zamierzamy korzystać z połączenia z internetem podczas instalacji, aby pobrać właściwy plik stage, konieczne jest przekopiowanie informacji o DNS z pliku /etc/resolv.conf do /mnt/gentoo/etc/resolv.conf. Plik ten zawiera informacje, jakich będzie potrzebował system do połączenia z siecią.

# cp -L /etc/resolv.conf /mnt/gentoo/etc/resolv.conf

Zmiana środowiska

Teraz, gdy wszystkie partycje są już założone, a podstawowe środowisko zainstalowane, nadszedł czas wkroczenia w nie poprzez chroot. Oznacza to przejście z systemu źródła instalacyjnego do systemu instalowanego (czyli na założone partycje).

Przechodzenie odbywa sie w trzech etapach. Najpierw zamieniamy katalog z / (na medium instalacyjnym) na /mnt/gentoo (na założonych partycjach) poleceniem chroot. Następnie tworzymy nowe środowisko przy pomocy polecenia env-update, które wyeksportuje nowe zmienne środowiskowe. Ostatecznie wczytujemy te zmienne do pamięci poleceniem source.

# chroot /mnt/gentoo /bin/bash
# env-update
* Caching service dependencies...
# source /etc/profile
# export PS1="(chroot) $PS1"

Gratulacje! Znajdujesz się wewnątrz nowego systemu Gentoo Linux. Oczywiście do końca jeszcze daleko i to jest powód, dla którego zostało jeszcze kilka rozdziałów Podręcznika. :]

Tworzenie cache dla Portage

Po instalacji Portage warto stworzyć jego cache, co znacznie przyspieszy jego działanie. Służy do tego polecenie emerge --metadata.

# emerge --metadata

6.b. Konfigurowanie zmiennych USE

Czy są zmienne USE?

USE to jedna z najważniejszych zmiennych w Gentoo. Niektóre programy mogą być kompilowane z dodatkową obsługi niektórych funkcji lub bez niej. Na przykład możliwe jest budowanie różnych programów ze wsparciem dla bibliotek gtk lub qt. Inne pakiety możemy z kolei wyposażyć w obsługę SSL, bądź też jej pozbawić. Jeszcze inne mogą być kompilowane ze wsparciem bufora ramki (svgalib) zamiast X11 (serwera X).

Większość dystrybucji kompiluje swoje pakiety ze wsparciem dla tak wielu elementów, jak to tylko możliwe, powiększając rozmiar programów i czas ich uruchamiania, nie wspominając o olbrzymiej liczbie zależności. W Gentoo możesz zdecydować, z którymi opcjami dany pakiet powinien być budowany. I to właśnie jest moment, kiedy USE wkracza do gry.

W zmiennych USE definiujesz słowa kluczowe zamieniane następnie na opcje kompilowania. Na przykład dodanie do zmiennej ssl włączy obsługę SSL w programach, które go wykorzystują. -X usunie wsparcie dla serwera X (zwróć uwagę na znak minusa z przodu). Ustawienie gnome gtk -kde -qt zaowocuje wsparciem dla GNOME (oraz gtk), ale nie dla KDE (i związanym z nim ściśle qt), znakomicie przygotowując grunt pod GNOME.

Modyfikowanie zmiennych USE

Domyślny zestaw flag USE znajduje się w pliku /etc/make.profile/make.defaults wybranego profilu. Aktualna konfiguracja USE jest zawsze sumą wszystkich flag ustawionych w plikach make.defaults. Wszystko co umieścimy w pliku /etc/make.conf zostanie dodane do tej zmiennej, jeśli natomiast chcemy coś z niej usunąć wpisujemy wybraną flagę ze znakiem minus na początku.

Pełny opis USE znajduje się w drugiej części Podręcznika Gentoo, w rozdziale Flagi USE. Kompletną charakterystykę dostępnych flag USE znajdziesz w pliku /usr/portage/profiles/use.desc.

# less /usr/portage/profiles/use.desc
(Użyj strzałek aby przewijać plik. Aby wyjść naciśnij 'q')

Jako przykład przedstawimy flagi USE dla systemu bazującego na KDE ze wsparciem dla DVD, ALSA i nagrywania CD:

# nano -w /etc/make.conf

USE="-gtk -gnome qt kde dvd alsa cdr"

7. Konfigurowanie jądra

7.a. Strefa czasowa

Aby system wiedział gdzie się znajduje należy najpierw wybrać strefę czasową. Odszukujemy ją w /usr/share/zoneinfo, a następnie za pomocą ln tworzymy do niej symlinka /etc/localtime. Należy unikać stref czasowych o nazwie /usr/share/zoneinfo/Etc/GMT*, ponieważ ich nazwy mogą być mylące, na przykład GMT-8 jest w rzeczywistości GMT+8.

# ls /usr/share/zoneinfo
(Zakładając, że chcemy Poland)
# ln -sf /usr/share/zoneinfo/Poland /etc/localtime

7.b. Instalacja źródeł

Wybór jądra

Sercem każdej dystrybucji jest jądro Linux. Stanowi ono interfejs pomiędzy programami i sprzętem. Gentoo dostarcza użytkownikom różne źródła kerneli. Pełna lista wraz z opisami znajduje się w Przewodniku jąder Gentoo.

Dla architektury PPC polecamy jądra vanilla-sources i gentoo-sources (oba serii 2.6). Druga opcja jest dobra dla instalacji bez dostępu do sieci. Wybierzmy któreś i zainstalujmy. Flaga USE="-doc" uniemożliwi zainstalowanie xorg-x11 i innych zbędnych na tym etapie zależności. Flaga USE="symlink" nie jest konieczna w przypadku nowej instalacji, jednak zapewnia w późniejszym okresie tworzenie prawidłowych dowiązań symbolicznych /usr/src/linux.

# USE="-doc symlink" emerge gentoo-sources

W katalogu /usr/src powinien być mniej więcej taki jak poniższy symlink, o nazwie linux, wskazujący na źródła jądra. W przykładzie zakładamy, że źródła jądra zostały zainstalowane jako gentoo-sources-2.6.15. W komputerze użytkownika może być to inna wersja, dlatego należy mieć to na uwadze.

# ls -l /usr/src/linux
lrwxrwxrwx    1 root     root           22  Mar 18 16:23 /usr/src/linux -> linux-2.6.15

Pora na skonfigurowanie i skompilowanie źródeł jądra. Można użyć do tego celu program genkernel, który zbuduje uniwersalne jądro, takie jak np. to używane przez płyty instalacyjne. Można też przeprowadzić cały proces ręcznie i lepiej dostosować kernel do własnych potrzeb. Zaczniemy od omówienia tej drugiej, znacznie lepszej metody.

Aby ręcznie skonfigurować jądro należy przejść do paragrafu Ręczna konfiguracja, opis pracy z genkernelem opisaliśmy w paragrafie Alternatywnie: użycie genkernel

7.c. Ręczna konfiguracja

Wprowadzenie

Ręczna konfiguracja kernela jest często postrzegana jako najtrudniejsza czynność jaką użytkownicy Linuksa muszą wykonywać. Nie jest to prawdą, po skompilowaniu kilku kerneli nie będziemy pamiętać, że kiedykolwiek uważaliśmy to za trudne zadanie.

Nie sposób jednak zaprzeczyć, że należy dobrze znać swój komputer, aby móc prawidłowo skonfigurować jądro. Większość informacji można zdobyć poprzez zemergowanie pakietu pciutils (emerge pciutils) zawierającego program lspci. Dzięki temu będzie możliwe używanie lspci wewnątrz chrootowanego środowiska. Podczas pracy z tym programem można bezpiecznie zignorować wszelkie ostrzeżenia związane z pcilib (jak np. "pcilib: cannot open /sys/bus/pci/devices). Ponadto można również uruchomić lspci poza środowiskiem chroot. Powinno dać to taki sam efekt. Dodatkowe informacje o sterownikach, które należy włączyć do jądra można uzyskać dzięki poleceniu lsmod, które pokaże listę modułów jakie załadował system płyty instalacyjnej. Informacje zapisane podczas uruchamiania jądra również mogą okazać się cennym źródłem informacji. Do ich wyświetlania służy polecenie dmesg.

Teraz pora na przeniesienie się do katalogu ze źródłami kernel, a następnie jego konfiguracja. Aby dodać domyślne ustawienia do konfiguracji, zaleca się uruchomienie najpierw polecenia make defconfig. Po wygenerowaniu domyślnej konfiguracji pora na wydanie polecenia make menuconfig, po którym uruchomi się menu konfiguracyjne oparte na ncurses.

# cd /usr/src/linux
# make defconfig
# make menuconfig

Zobaczymy okienko z listą sekcji, na które podzielono cały proces konfiguracji. Zaczniemy od omówienia opcji, które należy aktywować, aby zapewnić prawidłowe działanie Gentoo.

Zaznaczanie wymaganych ustawień

Po pierwsze włączamy możliwość korzystania z rozwojowych i eksperymentalnych fragmentów kodu jądra. Jeśli tego nie zrobimy, nawet nie zobaczymy kilku bardzo ważnych opcji.

Code maturity level options --->
  [*] Prompt for development and/or incomplete code/drivers
General setup --->
  [*] Support for hot-pluggable devices

Następnie przechodzimy do File Systems i wybierz wsparcie dla systemów plików, których zamierzamy używać. Jeśli o to nie zadbamy, Gentoo nie będzie w stanie zamontować partycji, a czasem nawet się nie uruchomi. Pamiętać należy również, aby włączać te sterowniki na stałe do jądra, w żadnym wypadku nie kompilujmy ich jako moduły. Przy okazji zaznaczamy też Virtual memory i /proc file system.

File systems --->
  Pseudo Filesystems --->
    [*] /proc file system support
    [*] Virtual memory file system support (former shm fs)

(Wybieramy jedną lub kilka z tych opcji zależnie od używanych systemów plików.)
  <*> Reiserfs support
  <*> Ext3 journalling file system support
  <*> Second extended fs support
  <*> XFS filesystem support

Jeśli używany jest PPPoE do łączenia się z Internetem, lub gdy używamy modemu dial-up będzie trzeba włączyć następujące opcje:

Device Drivers --->
  Networking support --->
    <*> PPP (point-to-point protocol) support
    <*>   PPP support for async serial ports
    <*>   PPP support for sync tty ports

Obie opcje dotyczące kompresji nie są wprawdzie wymagane, ale również nie zaszkodzą naszemu systemowi, podobnie zresztą jak opcja PPP over Ethernet, która jest przydatna tylko gdy skonfigurujemy rp-pppoe do pracy w trybie jądra PPPoE.

Nie należy zapomnieć wkompilować sterownika dla karty sieciowej.

Użytkownicy zarówno komputerów OldWorld jak i NewWorld będą potrzebowali wsparcia dla HFS, aby skopiować skompilowane jądro na partycję MacOS. Użytkownicy NewWorld muszą także dodatkowo skonfigurować partycję Apple_Bootstrap:

File Systems --->
  [*] HFS Support

Wywłaszczanie w jądrze wciąż działa niestabilnie na platformie PPC i może spowodować błędy przy kompilacji, czy naruszenia ochrony pamięci. Nie radzimy korzystać z tej opcji.

Platform options --->
  [ ] Preemptible Kernel

Jeśli komputer uruchamiany jest poprzez Firewire, potrzebne będzie włączenie poniższych opcji. Można użyć w tym celu modułów.

   Device Drivers --->
     IEEE 1394 (FireWire) support --->
       <*> IEEE 1394 (FireWire) support
       <*>   OHCI-1394 support
       <*>   SBP-2 support (Harddisks etc.)

Jeśli komputer uruchamiany jest poprzez USB potrzebne będzie włączenie poniższych opcji. Można użyć w tym celu modułów.

   Device Drivers --->
      USB support --->
        <*> Support for Host-side USB
        <*>   OHCI HCD support
        <*>   USB Mass Storage support

Nie wolno wyłączać wsparcia dla framebuffera, jest on wymagany do udanego uruchomienia systemu. Jeśli jest to karta NVIDIA, należy użyć framebuffera OpenFirmware. Dla kart ATI należy wybrać odpowiedni bufor ramki w zależności od posiadanego chipsetu karty (Mach64, Rage128 or Radeon).

   Device Drivers --->
     Graphics support --->
       <*> Support for frame buffer devices
       [*] Open Firmware frame buffer device support
       <*> ATI Radeon display support
       <*> ATI Rage128 display support
       <*> ATI Mach64 display support
       Console display driver support --->
         <*> Framebuffer Console support

Po ukończeniu konfigurowania jądra należy przejść do paragrafu Kompilacja i instalacja.

Kompilacja i instalacja

Po skonfigurowaniu kernela przyszła pora na jego skompilowanie i instalację. Opuszczamy program konfiguracyjny i wpisujemy następujące polecenia:

# make && make modules_install

Kiedy jądro skończy się kompilować kopiujemy jego obraz do katalogu /boot (należy upewnić się, że jest to poprawnie montowane, zwłaszcza na komputerach Pegasos). Jeżeli do uruchamiania komputera używamy BootX, jądro skopiujemy w późniejszym czasie.

Yaboot i BootX używają nieskompresowanych jąder w odróżnieniu do innych tego typu programów. Nieskompresowane jądra posiada nazwę vmlinux, a jego obraz po skompilowaniu znajduje się w katalogu /usr/src/linux. Jeżeli używamy komputera Pegasos jego oprogramowania wewnętrzne wymaga jądra skompresowanego, które po skompilowaniu posiada nazwę zImage.chrp i znajduje się w katalogu /usr/src/linux/arch/ppc/boot/images.

# cd /usr/src/linux
replace <kernel-version> with your kernel version
(Apple/IBM)
# cp vmlinux /boot/<kernel-version>
(Pegasos)
# cp arch/ppc/boot/images/zImage.chrp /boot/<kernel-version>

Następnie przechodzimy do paragrafu Instalacja osobnych modułów jądra.

7.d. Instalacja osobnych modułów jądra

Konfigurowanie modułów

Lista modułów, które chcemy by były automatycznie ładowane przy starcie systemu powinna znajdować się w pliku /etc/modules.autoload.d/kernel-2.6. Jeśli jest to potrzebne, można dodać kilka opcji dla modułów.

Żeby przejrzeć listę wszystkich dostępnych modułów używamy komendy find. Oczywiście powinniśmy zastąpić słowa "<wersja jądra>" numerem świeżo skompilowanego kernela.

# find /lib/modules/<wersja jądra>/ -type f -iname '*.o' -or -iname '*.ko'

Na przykład, aby automatycznie ładować do pamięci moduł 3c59x.o edytujemy plik kernel-2.6 i wprowadzamy do niego nazwę tego modułu.

# nano -w /etc/modules.autoload.d/kernel-2.6

3c59x

Następnie przechodzimy do rozdziału Konfiguracja systemu.

7.e. Alternatywnie: użycie genkernel

W tym paragrafie omawiamy proces konfiguracji jądra przy pomocy programu genkernel.

Po zainstalowaniu źródeł należy je skonfigurować. Zrobimy to automatycznie przy pomocy programu genkernel, który wykonuje cały proces dokładnie w ten sam sposób w jaki jest konfigurowane jądro na płycie instalacyjnej. Konsekwencją wyboru genkernela jest to, że system będzie zmuszony do wykrywania dostępnego sprzętu przy każdym uruchomieniu komputera. W związku z tym, że genkernel nie wymaga od użytkownika żadnych ręcznych poprawek w konfiguracji, jest doskonałym rozwiązaniem dla tych wszystkich, którzy nie są najmocniejsi w samodzielnym kompilowaniu jądra.

Zanim jednak zdradzimy jak używa się tego programu musimy wytłumaczyć jak go zainstalować:

# emerge genkernel

Następnie kopiujemy konfigurację jądra z płyty instalacyjnej do miejsca, w którym znajdzie ją i wykorzysta genkernel:

# zcat /proc/config.gz > /usr/share/genkernel/ppc/kernel-config-2.6

Jeśli do uruchamiania wykorzystuje się Firewire lub USB, trzeba dodać moduły do initrd. W tym celu edytujemy /usr/share/genkernel/ppc/modules_load i dodajemy MODULES_FIREWIRE="ieee1394 ohci1394 sbp2" dla Firewire lub MODULES_USB="usbcore ohci-hcd ehci-hcd usb-storage" dla USB.

Źródła skompilujemy przy pomocy polecenia genkernel --genzimage all. Na Pegasosie należy inaczej skonfigurować jądro i zbudować je w formacie zImage zamiast vmlinux, z którego korzysta się na komputerach Apple. Kompilowanie zajmie mnóstwo czasu, ponieważ genkernel zawiera niemal wszystkie dostępne sterowniki.

Jeśli partycja rozruchowa została sformatowana w innym niż ext2 lub ext3 systemie plików należy ręcznie dodać potrzebne dla nich sterowniki, wybiera się je przy pomocy menu genkernel --menuconfig --genzimage all. Sterowniki te muszą być wkompilowane w jądro na stałe, nie można dodawać ich w postaci modułów. Użytkownicy EVMS2 lub LVM2 powinni dodać również --evms2 lub --lvm2 do listy argumentów.

# genkernel --genzimage all

# genkernel --genzimage --kernel-config=/usr/share/genkernel/ppc/Pegasos all

W wyniku tego procesu powstanie właściwy plik jądra, initrd (initial root disk) oraz ogromna ilość modułów. Nazwy plików jądra i initrd będą potrzebne przy konfiguracji bootloadera do prawidłowego wypełnienia jego pliku konfiguracyjnego, więc warto je sobie zapisać. Przy następnym uruchomieniu komputera zostanie najpierw wykonany plik initrd, który wykryje cały dostępny sprzęt i wczyta odpowiednie moduły, a następnie uruchomi się właściwy system. Należy się upewnić, że zapisaliśmy poprawnie wymagane argumenty do załadowania systemu, bez nich system się nie uruchomi.

# ls /boot/kernel* /boot/initramfs*

Następna czynność jeszcze bardziej upodobni nasz system do tego znajdującego się na płycie instalacyjnej. Zemergujemy coldplug, który działa na podobnej zasadzie jak initrd, który wykrywa przy starcie wszystkie niezbędne do uruchomienia systemu urządzenia, natomiast coldplug zajmuje się wszystkim innym. coldplug jest dostępny na płycie Package CD.

(Należy to wykonać po instalacji, czyli w trakcie instalacji według wskazówek GRP)
# emerge -k coldplug
# rc-update add coldplug boot

Jeśli chcemy, aby system reagował na zdarzenia hotplug, wtedy powinniśmy zainstalować i ustawić hotplug:

# emerge hotplug
# rc-update add hotplug default

Kolejny etap instalacji to Konfigurowanie systemu.

8. Konfigurowanie systemu

8.a. Informacje o systemach plików

Co to jest fstab?

W Linuksie wszystkie używane przez system partycje powinny być wpisane do /etc/fstab. Plik ten zawiera informacje o tym gdzie w strukturze katalogów), z jakimi opcjami i kiedy (automatycznie przy starcie systemu, czy nie, przez zwykłych użytkowników, czy nie itd.) mają zostać zamontowane.

Tworzenie /etc/fstab

/etc/fstab używa specyficznej składni. Wszystkie wiersze składają się z sześciu pól, oddzielonych spacjami lub/i tabulatorami. Każde z nich pełni określoną funkcję:

• Pierwsze pole definiuje partycję (ścieżkę do odpowiadającego jej urządzenia).
• Drugie pole kontroluje punkt montowania.
• Trzecie pole opisuje używany przez partycję system plików.
• W czwartym polu podane są opcje montowania używane przez mount. Każdy system plików posiada własne ustawienia, pełna lista znajduje się w podręczniku systemowym programu mount (man mount). Wszystkie opcje powinny być oddzielone przecinkami.
• Piąte pole używane jest przez dump do ustalenia czy dana partycja ma być dumpowana czy nie. Zazwyczaj powinieneś wpisać tu 0 (zero).
• Z szóstego pola korzysta fsck do ustalenia kolejności sprawdzania partycji po nieprawidłowym wyłączeniu systemu. Dla głównego systemu plików powinieneś wpisać 1, natomiast dla pozostałych 2 (lub 0 jeśli kontrola nie jest konieczna).

Domyślny /etc/fstab dostarczany przez Gentoo nie jest poprawnym plikiem fstab, uruchamiamy więc nano (lub inny ulubiony edytor) i tworzymy własny plik /etc/fstab:

# nano -w /etc/fstab

Spójrzmy jak zapisać opcje partycji /boot. To tylko przykład, nie trzeba go przepisywać, jeśli architektura nie wymaga takiej partycji (np. Apple PPC).

W naszym przykładowym schemacie (dla x86) /boot będzie partycją /dev/hda1 i będzie używał systemu plików ext2 oraz będzie sprawdzany podczas rozruchu.

/dev/hda1   /boot     ext2    defaults        1 2

Niektórzy użytkownicy ze względów bezpieczeństwa nie chcą, aby partycja /boot była montowana automatycznie. Powinni oni zastąpić opcję defaults opcją noauto. Potem trzeba będzie ręcznie zamontować tą partycję przed każdym jej użyciem.

Aby poprawić wydajność, większość użytkowników zapewne zechce dodać opcję noatime. Dzięki niej nie są rejestrowane czasy dostępów (które zazwyczaj nie są potrzebne):

/dev/hda1   /boot     ext2    defaults,noatime    1 2

W podobny sposób dodajemy kolejne partycje. Rezultatem będą następujące trzy wiersze (dla partycji /boot, / oraz swap):

/dev/hda1   /boot     ext2    defaults,noatime  1 2
/dev/hda2   none      swap    sw                0 0
/dev/hda3   /         ext3    noatime           0 1

Na koniec powinniśmy jeszcze dodać linijki dla /proc, tmpfs oraz CD-ROM-u (no i oczywiście pozostałych posiadanych partycji i napędów).

/dev/hda1   /boot     ext2    defaults,noatime  1 2
/dev/hda2   none      swap    sw                0 0
/dev/hda3   /         ext3    noatime           0 1

none        /proc     proc    defaults          0 0
none        /dev/shm  tmpfs   nodev,nosuid,noexec  0 0

/dev/cdroms/cdrom0    /mnt/cdrom    auto      noauto,user    0 0

Opcja auto powoduje, że mount sam próbuje wykryć system plików (zalecane dla wymienialnych nośników, które mogą posiadać różne systemy). a user umożliwia montowanie zwykłym użytkownikom.

Należy skorzystać z powyższego przykładu do utworzenia własnego /etc/fstab. Użytkownicy architektury SPARC powinni jeszcze dodać do niego następujące linie:

none        /proc/openprom  openpromfs    defaults      0 0

Podwójnie sprawdzamy /etc/fstab, zapisujemy zmiany i zamykamy plik.

8.b. Konfiguracja sieci

Hostname, domainname itp

Każdy użytkownik powinien nadać swojemu komputerowi jakąś nazwę. Wydaje się to proste, ale wielu ma z tym spore trudności. Zawsze można tę nazwę zmienić. My wybraliśmy host tux oraz domenę homenetwork.

Skorzystamy z tych ustawień w kolejnych przykładach. Zacznijmy od ustalenia nazwy hosta:

# nano -w /etc/conf.d/hostname
(Ustawienie zmiennej HOSTNAME)
HOSTNAME="tux"

Teraz skonfigurujmy domenę:

# nano -w /etc/conf.d/domainname
(Ustawienie zmiennej DNSDOMAIN)
DNSDOMAIN="homenetwork"

Posiadacze domeny NIS powinni ją ustawić. Jeśli nie wiesz czym jest domena NIS to zapewne jej nie posiadasz.

# nano -w /etc/conf.d/domainname
(Ustawienie zmiennej NISDOMAIN)
NISDOMAIN="my-nisdomain"

Konfiguracja sieci

Zanim powiesz "Hej, przecież już to zrobiliśmy!" pamiętaj, że to co ustawiałeś na początku instalacji jest przeznaczone tylko na jej potrzeby. Teraz ostatecznie skonfigurujemy sieć dla instalowanego systemu Gentoo.

Wszystkie ustawienia dotyczące sieci znajdują się w /etc/conf.d/net. Mają prostą, ale niekoniecznie intuicyjną składnię. Nie ma czego się, wszystko wyjaśnimy. Warto zapoznać się z przykładowym plikiem /etc/conf.d/net.example, w którym znajduje się wiele cennych wskazówek oraz kilka przykładowych konfiguracji sieci.

Domyślnym ustawieniem jest DHCP, dlatego jego użytkownicy nie muszą dokonywać w plikach żadnych zmian.

Jeśli jednak zajdzie potrzeba do konfigurowania sieci, np. by wybrać określone opcje dla DHCP lub całkowicie zrezygnować z jego użycia, należy otworzyć plik /etc/conf.d/net w ulubionym edytorze (w przykładzie użyjemy nano):

# nano -w /etc/conf.d/net

Znajduje się tam następujący wpis:

config_eth0=( "dhcp" )
# This blank configuration will automatically use DHCP for any net.*
# scripts in /etc/init.d.  To create a more complete configuration,
# please review /etc/conf.d/net.example and save your configuration
# in /etc/conf.d/net (this file :]!).

Gdy IP, maska sieciowa oraz brama są ustawiane ręcznie to edytujemy obie zmienne, config_eth i routes_eth0:

config_eth0=( "192.168.0.2 netmask 255.255.255.0 brd 192.168.0.255" )
routes_eth0=( "default gw 192.168.0.1" )

Aby wybrać określone opcje DHCP należy dodać zmienne config_eth0 i dhcp_eth0:

config_eth0=( "dhcp" )
dhcp_eth0="nodns nontp nonis"
 

Powtarzamy powyższe instrukcje dla pozostałych interfesów sieciowych (odpowiednio config_eth1, config_eth2).

Lista dostępnych ustawień znajduje się w pliku /etc/conf.d/net.example.

Następnie należy zapisać konfigurację i zamknąć edytor.

Automatyczny start sieci podczas uruchamiania systemu

Aby urządzenia sieciowe były aktywowane podczas startu, musimy je dodać do domyślnego poziomu uruchamiania. Posiadacze urządzeń PCMCIA mogą pominąć te czynności, gdyż są one inicjowane przez osobny skrypt startowy.

# rc-update add net.eth0 default

Posiadacze kilku urządzeń sieciowych muszą utworzyć odpowiednie skrypty startowe, np. net.eth1, net.eth2 itd. Można w tym celu skorzystać z ln:

# cd /etc/init.d
# ln -s net.eth0 net.eth1
# rc-update add net.eth1 default

Zapisywanie informacji o sieci

Trzeba poinformować system o istnieniu lokalnej sieci. Służy do tego plik /etc/hosts. Zapisujemy w nim nazwy hostów i odpowiadające im adresy IP, których nie może ustalić serwer nazw. Będziemy musieli w tym pliku zdefiniować nasz komputer. Dodatkowo, możemy tutaj również umieścić komputery z naszej sieci jeżeli nie będziemy chcieli konfigurować wewnętrznego serwera DNS.

# nano -w /etc/hosts

(Wpis definiujący nasz komputer).
127.0.0.1     localhost

(Definiujemy pozostałe komputery z naszej sieci. Muszą one posiadać IP
przypisane na stałe, aby skorzystać z tego sposobu).
192.168.0.5   jenny.homenetwork jenny
192.168.0.6   benny.homenetwork benny

Zapisujemy zmiany i zamykamy edytor.

Osoby nie posiadające PCMCIA mogą od razu przejść do sekcji Konfiguracja systemu. W przeciwnym wypadku należy czytać dalej.

Opcjonalnie: Konfiguracja PCMCIA

Posiadacze PCMCIA muszą zainstalować pakiet pcmcia-cs. Dotyczy to także użytkowników jąder z serii 2.6 (nawet jeżeli nie będą używali sterowników PCMCIA z tego pakietu). Aby pominąć opcjonalną zależność xorg-x11, wpisujemy dodatkowo USE="-X":

# USE="-X" emerge pcmcia-cs

Następnie dodajemy do domyślnego poziomu uruchamiania skrypt pcmcia:

# rc-update add pcmcia default

8.c. Konfiguracja systemu

Hasło superużytkownika

Hasło roota zmieniamy poleceniem:

# passwd

Jeżeli chcemy, aby superużytkownik mógł logować się na konsole szeregowe, dodajemy tts/0 do /etc/securetty:

# echo "tts/0" >> /etc/securetty

Informacje o systemie

Do najbardziej podstawowych ustawień Gentoo używa pliku /etc/rc.conf. Otwieramy go i zapoznajemy się z umieszczonymi w nim komentarzami. :)

# nano -w /etc/rc.conf

Po dokonaniu zmian należy zapisać je do pliku.

Jak widać, plik ten jest dobrze skomentowany. Dzięki temu można poradzić sobie z umieszczonymi w nim zmiennymi bez niemal żadnych problemów. Między innymi można tu skonfigurować czcionki używane przez system i menedżer uruchamiania serwera X (jak kdm czy gdm).

Konfiguracja klawiatury znajduje się w pliku /etc/conf.d/keymaps i to jego należy edytować w celu zmiany ustawień.

# nano -w /etc/conf.d/keymaps

Zmienna KEYMAP wymaga specjalnego traktowania. Jeśli zostanie wybrana zła wartość to mogą pojawić się dziwne rezultaty podczas pisania na klawiaturze.

Po dokonaniu zmian należy zapisać plik i opuścić edytor.

Ustawienia zegara w Gentoo znajdują się w pliku /etc/conf.d/clock. Należy go wyedytować i poprawić ustawienia.

# nano -w /etc/conf.d/clock

Jeśli zegar sprzętu jest inny niż UTC należy dodać do pliku opcję CLOCK="local", aby godzina w systemie zgadzała się z rzeczywistością.

Po ukończeniu edycji zapisujemy zmiany i zamykamy edytor.

Jeżeli nie jest to instalacja IBM PPC64 należy przejść do instalacji narzędzi systemowych.

Konfiguracja konsoli

Jeżeli Gentoo pracuje na sprzęcie IBM PPC64, należy odkomentować linie hvc w pliku /etc/inittab dla konsoli wirtualnej, aby umożliwić zalogowanie się użytkownikom.

hvc0:12345:respawn:/sbin/agetty -L 9600 hvc0
hvsi:12345:respawn:/sbin/agetty -L 19200 hvsi0

Warto w pliku /etc/securetty sprawdzić czy wybrana konsola jest prawidłowa.

Następnie należy przejść do Instalacji odpowiednich narzędzi systemowych.

9. Instalowanie narzędzi systemowych

9.a. Program logujący

W archiwum stage3 brakuje kilka ważnych dla prawidłowego działania systemu programów, ponieważ nie chcemy wybierać za użytkownika jednego z kilku programów danego typu, które mogą spełniać określone funkcje. W tym rozdziale opiszemy wszystkie te narzędzia oraz pomożemy użytkownikowi wybrać z nich najbardziej odpowiednie dla niego.

Pierwszym narzędziem przy którym należy dokonać wyboru, jest program do obsługi systemu logowania. Unix i Linux posiadają bogatą historię w tym zakresie. Jeśli to konieczne, można logować do plików wszystko, co dzieje się w systemie. Mechanizmem tym zarządza właśnie program logujący.

Gentoo oferuje kilka różnych programów logujących: sysklogd - tradycyjny zestaw logujących demonów, syslog-ng - zaawansowany program logujący oraz metalog charakteryzujący się dużą liczbą opcji konfiguracyjnych. W Portage znajduje cały wachlarz programów logujących i nie tylko - liczba naszych pakietów rośnie z każdym dniem.

Jeżeli planuje się używanie sysklogd lub syslog-ng dobrym pomysłem jest zainstalowanie programu logrotate, ponieważ te programy logujące nie są zaopatrzone w żaden mechanizm rotacyjny dla logów.

Aby zainstalować wybrany program logujący, korzystamy z polecenia emerge, a następnie dodajemy go do domyślnego poziomu startowego poprzez skrypt rc-update. Poniższy przykład przedstawia proces instalacji programu syslog-ng:

# emerge syslog-ng
# rc-update add syslog-ng default

9.b. Opcjonalnie: Demon Cron

Następnym programem jest demon Cron. Pomimo że jest on opcjonalny i nie jest wymagany do poprawnej pracy systemu, zalecane jest jego zainstalowanie. Czym jest demon Cron? Jest to program służący do wykonywania zaplanowanych poleceń w określonym czasie. Jest on bardzo przydatny, gdy wykonujemy pewne czynności regularnie (na przykład codziennie, co tydzień, co miesiąc).

Dla instalacji bez sieci dostarczamy tylko vixie-cron. Aby używać innego demona cron, trzeba będzie poczekać i zainstalować go później.

# emerge vixie-cron
# rc-update add vixie-cron default

9.c. Opcjonalnie: Indeksowanie plików

Aby możliwe było indeksowanie plików w systemie w celu ich szybkiego wyszukiwania za pomocą narzędzia locate, należy zainstalować pakiet sys-apps/slocate.

# emerge slocate

9.d. Narzędzia obsługi systemu plików

W zależności od tego, jakiego systemu plików używamy, musimy zainstalować odpowiednie narzędzia do jego obsługi (do sprawdzania jego integralności, czy tworzenia dodatkowych systemów plików).

W poniższej tabeli przedstawiono narzędzia, których należy użyć dla poszczególnych używanych systemów plików. Nie każdy system plików jest dostępny na wszystkich architekturach.

Użytkownicy EVMS powinni zainstalować pakiet lvm-user:

# USE="-gtk" emerge --usepkg evms

Flaga USE="-gtk" zapobiega instalacji zbędnych na tym etapie zależności evms. Bez problemu można później przebudować pakiet evms bez tej flagi i uzyskać dostęp do narzędzi graficznych, które teraz nie zostaną zainstalowane.

Jeżeli nie potrzeba żadnych dodatkowych narzędzi sieciowych (takich jak rp-pppoe lub klient dhcp) przechodzimy do Konfiguracji bootloadera.

9.e. Narzędzia sieciowe

Opcjonalnie: Instalowanie klienta DHCP

Jeżeli chcemy, aby Gentoo automatycznie uzyskiwało adres IP karty sieciowej, musimy zainstalować dhcpcd (lub jakiegokolwiek innego klienta DHCP). Jeżeli nie zrobi się tego teraz, połączenie sieciowe może nie działać po zakończeniu instalacji!

# emerge dhcpcd

Opcjonalnie: Instalacja klienta PPPoE

# USE="-X" emerge rp-pppoe

Ustawienie USE="-X" zapobiegnie instalacji pakietu xorg-x11 poprzez zależności (rp-pppoe posiada narzędzia graficzne, aby z nich korzystać, możesz przekompilować rp-pppoe po instacji serwera xorg-x11 lub zainstalować go teraz, jednak jego kompilacja zajmie dużo czasu).

Opcjonalnie: Narzędzia RAID dla komputerów IBM

Jeżeli używamy SCSI RAID na systemie bazującym na POWER5, powinniśmy rozważyć instalację pakietu iprutils, który pozwoli nam pracować z macierzami RAID, pobierać status dysków w macierzy oraz dostarczy wielu innych funkcji.

# emerge iprutils

Teraz jesteśmy już gotowi do przejścia do konfiguracji bootloadera.

10. Konfiguracja bootloadera

10.a. Wybór bootloadera

Wstęp

Gdy jądro zostało już skonfigurowane i skompilowane, do uruchomienia nowego systemu potrzebny jest bootloader. To, jakiego rodzaju bootloader należy wykorzystać, zależy od typu posiadanego komputera PPC.

Jeśli korzystamy z komputera NewWorld Apple lub IBM, jedyną możliwością jaką mamy jest bootloader yaboot. Dla OldWorld Apple istnieją dwie opcje: BootX (zalecany) i quik. Pegasos nie wymaga bootloadera, jednak w jego przypadku konieczne jest zemergowanie programu BootCreator, aby możliwe było stworzenie bootmenu SmartFirmware.

10.b. Domyślnie: Używanie yaboot

Wprowadzenie

W celu prawidłowego zlokalizowania urządzenia bootowalnego, yaboot potrzebuje węzłów sprzętowych utworzonych przez udev oraz systemu plików sysfs. Systemy te znajdziemy odpowiednio w /dev i /sys. Aby tego dokonać będziemy musieli dowiązać te systemy plików z płyty instalacyjnej do odpowiednich systemów wewnątrz środowiska chroot. Jeżeli już to zrobiliśmy, nie ma potrzeby, aby czynność tę powtarzać.

# exit  (opuszczenie chroot)
# mount -o bind /dev /mnt/gentoo/dev
# mount -o bind /sys /mnt/gentoo/sys
# chroot /mnt/gentoo /bin/bash
# /usr/sbin/env-update && source /etc/profile 

Aby skonfigurować yaboota można wykorzystać program yabootconfig w celu automatycznego wygenerowania pliku konfiguracyjnego. Jeśli jednak instalujemy Gentoo na G5 (na którym yabootconfig nie zawsze działa) lub planujemy bootować system z urządzeń podłączanych poprzez firewire lub USB, musimy własnoręcznie przeprowadzić konfigurację yaboota.

####################################################################
## Ta sekcja może zostać powielona w przypadku posiadania więcej niż
## jednego jądra, lub zestawu parametrów startowych. Należy zastąpić
## kernel-2.6.15 nazwą posiadanego jądra.
####################################################################
image=/boot/kernel-2.6.15
  label=Linux
  root=/dev/ram0
  partition=3
  append="real_root=/dev/hda3 init=/linuxrc"
  # Można dodać inne argumenty dla jądra, jak na przykład
rootdelay=10
  # dla bootowania z urządzeń USB/Firewire.
  read-only
###################################################################

• Domyślnie: Użycie yabootconfig
• Alternatywnie: Ręczna konfiguracja yaboot

Domyślnie: Użycie yabootconfig

Yabootconfig automatycznie wykryje podział na partycje i umożliwi uruchamianie wybranego z dwóch lub nawet trzech systemów, którymi mogą być Linux, Mac OS i Mac OS X.

Konieczne jest posiadanie na dysku partycji Apple_Bootstrap oraz odpowiednich wpisów dotyczących istniejących partycji Linuksa w pliku /etc/fstab, przed użyciem yaboot. Obydwa warunki powinny być już spełnione - wszystkie operacje zostały opisane w poprzednich rozdziałach. Należy jednak upewnić się sprawdzając plik /etc/fstab. oraz że posiadamy najnowszą wersję yaboota,

# emerge --usepkg yaboot

Następnie opuszczamy chroot i wykonujemy polecenie yabootconfig --chroot /mnt/gentoo. Po uruchomieniu programu zostaniemy poproszeni o potwierdzenie lokalizacji partycji bootstrap. W przypadku gdy używamy schematu podanego w tym podręczniku powinno to być partycja /dev/hda2. Należy wpisać Y, jeżeli zgadzamy się z wynikiem polecenia. Jeżeli tak nie jest, należy sprawdzić ponownie plik /etc/fstab. yabootconfig przeskanuje ustawienia naszego systemu, stworzy plik /dev/yaboot.conf i uruchomi polecenie mkofboot. Polecenie to używane jest do sformatowania partycji bootstrap oraz instalacji pliku konfiguracyjnego na tej partycji. Ponownie wracamy do środowiska chroot.

# chroot /mnt/gentoo /bin/bash
# /usr/sbin/env-update && source /etc/profile

Być może wystąpi potrzeba modyfikacji zawartości pliku /etc/yaboot.conf. Jeśli zostaną wprowadzone do niego jakieś zmiany (jak na przykład zmiana domyślnie uruchamianego systemy), konieczne będzie uruchomienie ybin -v, aby zmiany odniosły skutek na partycji Apple_Bootstrap.

Po wykonaniu tych operacji, kontynuujemy instalację zgodnie z instrukcjami w podrozdziale Ponowne uruchomienie systemu.

Alternatywnie: Ręczna konfiguracja yaboot

Po pierwsze należy upewnić się, że mamy zainstalowaną najnowszą wersję yaboota.

# emerge --usepkg yaboot

Poniżej znajduje się przykładowy plik yaboot.conf. Konieczna jest jego modyfikacja w celu dopasowania do wymagań systemu i użytkownika. Posiadacze G5, a także ci, którzy bootują z urządzeń firewire/USB muszą pamiętać, że ich dyski widoczne są dla jądra Linuksa jako urządzenia SCSI, więc konieczne jest zastąpienie /dev/hda ścieżką /dev/sda.

## /etc/yaboot.conf
##
## Więcej szczegółów: "man yaboot.conf". Nie należy wprowadzać zmian przed
## zapoznaniem się ze stronami man yaboot.conf!!
## Przykładowe konfiguracje znajdują się w : /usr/share/doc/yaboot/examples
##
## Aby możliwe było uruchamianie innych systemów, należy dodać jedną lub
więcej
## z przykładowych pozycji:
## bsd=/dev/hdaX, macos=/dev/hdaY, macosx=/dev/hdaZ

## nasza partycja bootstrap:

boot=/dev/hda2


## ofboot w openfirmware służy do wyboru partycji startowej.
## Bez tego parametru, yaboot nie zadziała na G5 (dopóki nie zostaną
przekazane
## odpowiednie opcje do programu mkofboot/ybin).
## hd:X oznacza /dev/sdaX (lub /dev/hdaX).
##
## Posiadacze G5 powinni odkomentować tą linię!

#ofboot=hd:2

## Bootujący z urządzeń firewire powinni użyć linii podobnej do poniższej:
# ofboot=fw/node/sbp-2/disk@0:

## Bootujący z urządzeń USB powinni użyć linii podobnej do poniższej:
# ofboot=usb/disk@0:

## hd: w terminologii OpenFirmware oznacza hda
device=hd:

## Bootujący z urządzeń Firewire/USB muszą określić nazwę aparatu OF
## Można ją uzyskać przy użyciu programu ofpath, który jest dołączony do
yaboota.

# device=fw/node@0001d200e00d0207/sbp-2@c000/disk@0:


delay=5
defaultos=macosx
timeout=30
install=/usr/lib/yaboot/yaboot
magicboot=/usr/lib/yaboot/ofboot

#################
## Ta sekcja może zostać powielona w przypadku posiadania więcej niż
## jednego jądra, lub zestawu parametrów startowych. Należy zastąpić
## kernel-2.6.12 nazwą posiadanego jądra.
#################
image=/boot/kernel-2.6.12
  label=Linux
  root=/dev/hda3
  partition=3
#  append="rootdelay=10"  # Wymagane dla bootowania z urządzeń
USB/Firewire
  read-only
##################

## Użytkownicy G5 i niektórzy użytkownicy G4 powinni wykorzystać ustawienia:
##   macos=hd:13
##   macosx=hd:12
## zamiast przykładowych wartości.
macos=/dev/hda13
macosx=/dev/hda12
enablecdboot
enableofboot

Gdy plik yaboot.conf jest prawidłowo skonfigurowany, należy uruchomić mkofboot -v, czego efektem będzie sformatowanie partycji Apple_bootstrap i zainstalowanie na niej aktualnej konfiguracji. Jeśli yaboot.conf zostanie zmodyfikowany po utworzeniu partycji Apple_bootstrap, konieczne będzie zaktualizowanie ustawień przy użyciu polecenia ybin -v.

Więcej informacji o yabootcie uzyskać można na stronie projektu yaboot. Po skonfigurowaniu bootloadera kontynuujemy instalację zgodnie z instrukcjami w podrozdziale Ponowne uruchomienie systemu.

10.c. Alternatywnie: BootX

Aby BootX mógł zbootować Linuksa z wnętrza MacOS-a, jądro systemu musi zostać przekopiowane z partycji Linuksa na partycję MacOS-a. Dokonamy tego montując najpierw partycję MacOS-a spoza środowiska chrootowanego, a następnie kopiując kernel do folderu systemowego, aby BootX mógł go odnaleźć. W celu określenia, na której partycji znajduje się MacOS użyjemy polecenia mac-fdisk -l (sda6 zostało poniżej użyte jako przykład).

# exit
cdimage ~# mkdir /mnt/mac
cdimage ~# mount /dev/sda6 /mnt/mac -t hfs
cdimage ~# cp /mnt/gentoo/usr/src/linux/vmlinux "/mnt/mac/System
Folder/Linux
Kernels"

Jeśli użyto programu genkernel, to zarówno jądro, jak i initrd muszą zostać skopiowane na partycję MacOS-a.

# exit
cdimage ~# mkdir /mnt/mac
cdimage ~# mount /dev/sda6 /mnt/mac -t hfs
cdimage ~# cp /mnt/gentoo/boot/kernel-* "/mnt/mac/System Folder/Linux
Kernels"
cdimage ~# cp /mnt/gentoo/boot/initramfs-* "/mnt/mac/System Folder"

Gdy jądro zostało skopiowane, musimy ponownie uruchomić komputer i skonfigurować BootX.

cdimage ~# cd /
cdimage ~# umount /mnt/gentoo/proc /mnt/gentoo/dev /mnt/gentoo /mnt/mac
cdimage ~# reboot

Oczywiście należy usunąć wszystkie bootowalne nośniki, ponieważ teraz powinien uruchomić się MacOS.

Gdy uruchomiony zostanie MacOS, otwieramy panel sterowania BootX. Jeśli nie korzystaliśmy z genkernela, wybieramy Options i odznaczamy Use specified RAM disk. Natomiast jeśli użyliśmy genkernela, musimy upewnić się, że initrd genkernela jest wybrany zamiast initrd płyty instalacyjnej. Użytkownicy niekorzystający z genkernela mogą określić teraz partycję root - podajemy tutaj wartość odpowiadającą naszemu podziałowi dysku. W zależności od konfiguracji jądra można dodać inne argumenty.

Program BootX można skonfigurować tak, aby automatycznie startował Linuksa. Jeśli się na to zdecydujemy, najpierw zobaczymy ekran ładowania MacOS, a następnie, już w trakcie wczytywania systemu, BootX załaduje i wystartuje Linuksa. Więcej informacji można uzyskać na Stronie domowej BootX.

Następnie jeszcze raz restartujemy komputer, uruchamiamy Linuksa i kontynujemy instalację zgodnie z instrukcjami w rozdziale Finalizowanie instalacji Gentoo.

10.d. Alternatywnie: quik

Program quik pozwala na bootowanie z pominięciem MacOS-a na komputerach OldWorld. Nie jest to jednak dobrze wspierane i zalecane rozwiązanie, gdyż może spowodować występowanie licznych dziwactw. Jeśli tylko istnieje taka możliwość, zalecane jest korzystanie z programu BootX zamiast quik, ze względu na znacznie większą stabilność i łatwiejszą konfigurację tego pierwszego.

Jeśli mimo wszystko zdecydujemy się na to rozwiązanie, postępujemy zgodnie z poniższymi instrukcjami. Po pierwsze musimy zainstalować quik:

# emerge quik

Następnie musimy dokonać jego konfiguracji. Edytujemy plik /etc/quik.conf ustawiając w nim obraz naszego jądra, które skopiowaliśmy na partycję boot.

# Przykładowy plik quik.conf
init-message = "Gentoo 2006.0\n"
partition = 2           # Partycja boot
root = /dev/hda4
timeout = 30
default = gentoo
image = /vmlinux-2.6.15
label = gentoo

Plik quik.conf musi znajdować się na tym samym dysku co bootowalny obraz, ale niekoniecznie na tej samej partycji. Jest jednak wskazane, aby przenieść go do partycji boot.

# mv /etc/quik.conf /boot/quik.conf

Teraz musimy ustawić zmienne związane z bootowaniem, aby quik był uruchamiany. Użyjemy do tego programu nvsetenv. To, jakie zmienne musimy ustawić, zależy od komputera jaki posiadamy. Zaleca się odszukanie prawidłowych wartości quirks przed rozpoczęciem konfiguracji.

# nvsetenv auto-boot true # Ustawiamy "false", aby uruchamiać
# OF; nie wszystkie komputery mogą korzystać z trybu OF
# nvsetenv output-device video # Wartość wybieramy na
podstawie
# powyższej strony quirks
# nvsetenv input-device kbd
# nvsetenv boot-device scsi/sd@1:0 # Dla SCSI
# nvsetenv boot-device ata/ata-disk@0:0 # Dla ATA
# nvsetenv boot-file /boot/vmlinux-2.6.15 root=/dev/hda4
# Pierwszy element wskazuje ścieżkę do jądra, drugi do partycji root.
# Dodać tu można wszelkie inne opcje jakie chcemy przekazać do
jądra.
# nvsetenv boot-command boot # Ustawiamy "bye" dla MacOS i
# "boot" dla Linuksa

Gdy ustawiliśmy już opcje uruchamiania, musimy upewnić się, że bootowalne obrazy są poprawnie zainstalowane. Uruchamiamy quik -v -C /boot/quik.conf. Powinniśmy uzyskać informację, że posiadamy boot block QUIK.

Kolejnym krokiem jest Ponowne uruchomienie systemu.

10.e. Alternatywnie: BootCreator

Po pierwsze, upewnijmy się, że mamy zainstalowaną najnowszą wersję programu bootcreator:

# emerge --usepkg bootcreator

Teraz przekopiujmy plik /etc/bootmenu.example do /etc/bootmenu i zmodyfikujmy go, aby odpowiadał naszym potrzebom:

# cp /etc/bootmenu.example /etc/bootmenu
# nano -w /etc/bootmenu

Poniżej znajduje się przykładowy plik /etc/bootmenu. Można go zmienić wedle upodobań.

#
# Przykładowy plik dla programu bootcreator 1.1
#

[VERSION]
1

[TITLE]
Boot Menu

[SETTINGS]
AbortOnKey = false
Timeout    = 9
Default    = 1

[SECTION]
Local HD -> Morphos      (Normal)
ide:0 boot2.img ramdebug edebugflags="logkprintf"

[SECTION]
Local HD -> Linux 2.6.15 (Normal)
ide:0 linux-2.6.15 video=radeonfb:1024x768@70 root=/dev/hda3

[SECTION]
Local HD -> Genkernel (Normal)
ide:0 kernelz-2.6.15 root=/dev/ram0 real_root=/dev/hda3 init=/linuxrc

Następnie musimy skopiować plik bootmenu na partycję boot, aby SmartFirmware mógł go odczytać. Użyjemy do tego programu bootcreator:

# bootcreator /etc/bootmenu /boot/menu

Następnym etapem instalacji jest Ponowne uruchomienie systemu.

10.f. Ponowne uruchomienie systemu

Opuszczamy środowisko chrootowane i odmontowujemy wszystkie partycje, aby możliwe było czyste ponowne uruchomienie. Następnie używamy komendy reboot.

# exit
livecd ~# umount /mnt/gentoo/proc /mnt/gentoo/dev /mnt/gentoo
livecd ~# reboot

Gdy nasze nowe Gentoo uruchomi się, kończymy instalację zgodnie z instrukcjami w rozdziale Finalizowanie instalacji Gentoo.

11. Zakończenie instalacji Gentoo

11.a. Administrowanie kontami użytkowników

Tworzenie konta do codziennej pracy

Wykonywanie zadań z przywilejami roota jest niebezpieczne i należy tego unikać. Do codziennej pracy należy utworzyć zwykłe konto użytkownika.

Czynności jakie może wykonać użytkownik są zależne od grup do jakich należy. Oto lista najważniejszych grup:

Na przykład, aby utworzyć konto użytkownika aye i dodać go do grup wheel (możliwość korzystania z su do przełączania się na konto root), users (grupa domyślna dla wszystkich użytkowników) oraz audio (możliwość korzystania z urządzeń dźwiękowych) należy z konta roota wykonać następujące polecenie:

Login: root
Password: (wpisujemy hasło)

# useradd aye -m -G users,wheel,audio -s /bin/bash
# passwd aye
Password: (hasło aye'go)
Re-enter password: (Ponownie hasło aye'go)

Jeśli użytkownik ten kiedykolwiek zechce wykonać jakiekolwiek czynności jako root powinien użyć polecenia su -, aby tymczasowo otrzymać uprawnienia superużytkownika. Alternatywnie może skorzystać z pakietu sudo charakteryzującego się wysokim poziomem bezpieczeństwa (o ile zostanie prawidłowo skonfigurowany).

11.b. Opcjonalnie: instalacja pakietów GRP

Po uruchomieniu systemu logujemy się na nowo utworzone konto użytkownika (np. aye i korzystamy z polecenia su - w celu uzyskania przywilejów roota.

$ su -
Password: (Wpisujemy hasło roota)

Następnie konfigurujemy Portage tak, aby poszukiwało prekompilowanych pakietów na płytach CD. Najpierw musimy jednak zamontować tę płytę.

(Wkładamy płytę do napędu i wpisujemy:)
# mount /mnt/cdrom

Następnie ustawiamy Portage tak, aby korzystało z pakietów w katalogu /mnt/cdrom.:

# ls /mnt/cdrom

(Jeśli na płycie znajduje się podkatalog /mnt/cdrom/packages:)
# export PKGDIR="/mnt/cdrom/packages"

(W innym wypadku:)
# export PKGDIR="/mnt/cdrom"

Następnie instalujemy potrzebne pakiety. Na płytach "Packages CD" znajduje się bardzo wiele, są tam np. gotowe pakiety KDE i GNOME.

# emerge --usepkg gnome

Listę dostępnych na płycie pakietów można uzyskać przeglądając katalog /mnt/cdrom/All. Np. by sprawdzić czy można z pomocą tej płyty zainstalować KDE należy wpisać:

# ls /mnt/cdrom/All/kde*

Należy się upewnić, że są instalowane binarne pakiety. Po wykonaniu polecenia emerge --sync, które aktualizuje Portage, wersje pakietów z płyty mogą być zbyt stare, aby Portage chciało je instalować domyślnie. Problem ten można obejść korzystając z parametru emerge --usepkgonly zamiast emerge --usepkg.

Gratulacje, system jest gotów do pracy. Kolejny rozdział jest zatytułowany I co dalej?.

12. I co dalej?

12.a. Dokumentacja

Gratulacje! Od teraz masz działający system Gentoo Linux. Ale... co teraz? Czego można dokonać? Co odkryć najpierw? Gentoo daje swoim użytkownikom ogromne możliwości, których większość jest świetnie udokumentowana.

Zdecydowanie warto rzucić okiem na drugą część Podręcznika, zatytułowaną Praca z Gentoo. Omówiliśmy w niej metody instalacji i aktualizacji oprogramowania, flagi USE i system skryptów startowych.

Aby zoptymalizować system na desktop lub dowiedzieć się jak najlepiej skonfigurować oprogramowanie biurkowe, warto poznać rozdział Zasoby dokumentacji Gentoo dla stacji roboczych. Warto również zainteresować się możliwością spolszczenia systemu, wszystkie czynności, jakich należy dokonać w tym celu opisaliśmy w tekście zatytułowanym Lokalizacja Gentoo Linux.

Wartą przeczytania pozycją jest także Podręcznik bezpieczeństwa Gentoo.

Pełna lista dostępnych dokumentów znajduje się na stronie zasobów dokumentacji Gentoo.

12.b. Gentoo w sieci

Wszystkich użytkowników zapraszamy na Forum Gentoo oraz nasze liczne kanały IRC.

Dodatkowo posiadamy wiele list dyskusyjnych dostępne dla wszystkich zainteresowanych. Informacje o subskrybcji zamieściliśmy na ich stronie.

I tyle. Po tej całej ciężkiej pracy związanej z instalacją przyszła pora głęboko odetchnąć i zacząć cieszyć się świeżo zainstalowanym systemem. :)

12.c. Zmiany w profilu 2006.0

Zmiany?

Gentoo jest dynamicznie zmieniającym się systemem. Poniższe akapity opisują ważne zmiany, które wpływają na sposób instalacji. Przedstawiamy tylko te modyfikacje, które są w jakiś sposób związane z procesem budowania systemu.

W profilu 2006.0 nie wprowadzono żadnych kluczowych zmian.

B. Praca z Gentoo

1. Wprowadzenie do Portage

1.a. Witamy w Portage

Portage to najlepszy istniejący program do zarządzania oprogramowaniem. Żadna inna dystrybucja Linuksa nie może się pochwalić równie kompleksowym, konfigurowalnym i użytecznym narzędziem jak to napisane przez deweloperów Gentoo.

Portage zostało napisane w dwóch językach skryptowych, Pythonie i Bashu, dzięki czemu sposób jego działania jest bardzo przejrzysty nawet dla niezbyt biegłych w programowaniu użytkowników.

Większość użytkowników pracuje z Portage przy pomocy narzędzia emerge. Aby uzyskać więcej informacji na temat tego programu, wystarczy wpisać:

$ man emerge

1.b. Drzewo Portage

Ebuildy

Kiedy mówimy o pakietach to tak naprawdę mamy na myśli programy dostępne dla użytkowników Gentoo w drzewie Portage. Drzewo to jest zbiorem ebuildów, czyli plików zawierających wszelkie informacje, które są niezbędne do zarządzania oprogramowaniem (instalacja, wyszukiwanie, inne zapytania...). Domyślnie kolekcja ebuildów znajduje się w katalogu /usr/portage.

Za każdym razem gdy zażądamy od Portage wykonania jakiegoś zadania związanego z naszym oprogramowaniem użyje ono jako podstawy swojego działania informacji zawartych w kolekcji ebuildów. Stąd też warto w miarę często uaktualniać swoje drzewo Portage tak, aby system wiedział o nowych wersjach programów, poprawkach do nich, etc.

Uaktualnianie drzewa Portage

Drzewo Portage uaktualniamy zazwyczaj za pomocą narzędzia rsync. Uaktualnienie to wykonuje się w stosunkowo prosty sposób dzięki jednemu z parametrów polecenia emerge, dzięki któremu komenda ta zadziała jak nakładka na rsync:

# emerge --sync

Jeśli nie jest możliwe użycie rsync w wyniku jakichś ograniczeń narzuconych przez różnego rodzaju firewalle to możliwa jest aktualizacja drzewa Portage przy użyciu jednego z generowanych codziennie snapshotów. Program emerge-webrsync automatycznie pobierze odpowiednie pliki i zainstaluje je w systemie.

# emerge-webrsync

1.c. Zarządzanie oprogramowaniem

Wyszukiwanie oprogramowania

Do wyszukiwania w drzewie Portage konkretnych programów można użyć funkcji wbudowanych w program emerge. Domyślnie emerge --search wypisze wszystkie zawierające dane wyrażenie nazwy pakietów.

Na przykład poszukajmy wszystkich pakietów zawierających literki "pdf" w nazwie:

$ emerge --search pdf

By przeszukiwać pakiety również po opisie pakietu, nie tylko po jego nazwie należy dopisać dodatkowo parametr --searchdesc (lub krócej -S).

$ emerge --searchdesc pdf

Kiedy przyjrzymy się wynikowi tego polecenia zauważymy, że dostarcza on wielu ciekawych informacji. Zawartość i opisy poszczególnych pól są dość przejrzyste i nie powinny przysporzyć nikomu problemów. Z tego względu nie będziemy ich tu szerzej omawiać.

*  net-print/cups-pdf
      Latest version available: 1.5.2
      Latest version installed: [ Not Installed ]
      Size of downloaded files: 15 kB
      Homepage:    http://cip.physik.uni-wuerzburg.de/~vrbehr/cups-pdf/
      Description: Provides a virtual printer for CUPS to produce PDF files.
      License:     GPL-2

Instalowanie oprogramowania

Instalacja znalezionych w ten sposób w Portage programów jest prosta i sprowadza się do dodania do polecenia emerge nazwy programu do zainstalowania. Dla przykładu zainstalujemy sobie gnumeric:

# emerge gnumeric

W związku z tym, że wiele aplikacji do prawidłowego działania potrzebuje innych programów, instalacja którejś paczki może nieść ze sobą potrzebę zainstalowania także jej zależności. Nie ma powodu do zmartwień, to nie RPM-y - Portage doskonale radzi sobie z zależnościami. By dowiedzieć się, jakie zależności zostaną zainstalowane z danym programem należy dodać przełącznik --pretend do zwykłej komendy instalującej program. Na przykład:

# emerge --pretend gnumeric

Kiedy zostanie wydane polecenie dla Portage by zainstalowało jakiś program, z Internetu zostaną pobrane wszystkie niezbędne, nieznajdujące się na dysku pliki zawierające kod źródłowy. Domyślnie są one przechowywane w katalogu /usr/portage/distfiles. Następnie program zostanie rozpakowany, skompilowany i zainstalowany. Aby Portage jedynie pobrało potrzebne pliki, należy dodać opcję --fetchonly do komendy emerge:

# emerge --fetchonly gnumeric

Wyszukiwanie dokumentacji do zainstalowanych pakietów

Wiele pakietów jest publikowanych jest wraz z dokumentacją. Czasem flaga USE doc określa czy dokumentacja dla danego pakietu zostanie zainstalowana czy nie. Informację o tym czy dany pakiet korzysta z flagi doc można uzyskać za pomocą następującego polecenia: emerge -vp <nazwa pakietu>.

(Oczywiście alsa-lib to tylko przykład)
# emerge -vp alsa-lib
[ebuild  N    ] media-libs/alsa-lib-1.0.14_rc1  -debug +doc 698 kB

Najlepszym sposobem uaktywnienia flagi USE doc jest wykonanie tego dla jednego pakietu przy użyciu pliku /etc/portage/package.use tak, aby pobrać dokumentację jedynie dla programu, którym jesteśmy zainteresowani. Uaktywnienie tej flagi globalnie, może powodować błędy wywoływane przez zapętlające się zależności. Aby dowiedzieć się więcej należy przeczytać rozdział podręcznika dotyczący flag USE.

Dokumentacja do zainstalowanego już pakietu na ogół znajduje się w podkatalogu o nazwie takiej samej jak pakiet, w katalogu /usr/share/doc. Można wyświetlić listę wszystkich zainstalowanych plików za pomocą narzędzia equery, które jest częścią pakietu app-portage/gentoolkit.

# ls -l /usr/share/doc/alsa-lib-1.0.14_rc1
total 28
-rw-r--r-- 1 root root 669 May 17 21:54 ChangeLog.gz
-rw-r--r-- 1 root root 9373 May 17 21:54 COPYING.gz
drwxr-xr-x 2 root root 8560 May 17 21:54 html
-rw-r--r-- 1 root root 196 May 17 21:54 TODO.gz

(Można też użyć equery do zlokalizowania plików dokumentacji)
# equery files alsa-lib | less
media-libs/alsa-lib-1.0.14_rc1
* Contents of media-libs/alsa-lib-1.0.14_rc1:
/usr
/usr/bin
/usr/bin/alsalisp
(Wyjście programu zostało skrócone)

Usuwanie oprogramowania

Do usuwania zainstalowanych programów służy polecenie emerge --unmerge. Nakaże ono Portage usunięcie wszystkich plików dodanych w procesie instalacji programu, z pominięciem jednak tych plików, które od instalacji programu zostały zmienione. Najczęściej chodzi tu o pliki konfiguracyjne, a pozostawienie ich na dysku umożliwia łatwe wznowienie pracy z programem w przypadku, gdy w przyszłości program zostanie ponownie zainstalowany.

W tym dość przejrzystym procesie kryje się pewna pułapka: Portage nie sprawdza czy pakiet, który ma być usunięty nie jest zależnością innego zainstalowanego programu. Jeśli jednak jest to program niezbędny dla prawidłowego działania systemu, pojawi się ostrzeżenie.

# emerge --unmerge gnumeric

Gdy program zostanie usunięty, jego zależności nie są usuwane razem z nim, ale pozostają na dysku. Aby odszukać i usunąć niepotrzebne w systemie zależności używamy polecenia emerge --depclean. Omówimy je dokładniej nieco później.

Uaktualnianie systemu

Aby utrzymać swój system w dobrej kondycji (nie wspominając już o instalacji najnowszych poprawek związanych z bezpieczeństwem), należy dość często go uaktualniać. W związku z tym, że w tym procesie Portage porównuje zainstalowane oprogramowanie z ebuildami z drzewa Portage, należy najpierw pobrać jego aktualną wersję. Kiedy już je zaktualizujemy przychodzi czas na właściwe uaktualnienie systemu. Dokonujemy tego poleceniem emerge --update world. W poniższym przykładzie skorzystamy także z opcji --ask, która spowoduje wyświetlenie listy pakietów do aktualizacji, a następnie pytania czy na pewno chcemy je zaktualizować.

# emerge --update --ask world

Portage znajdzie wszystkie bezpośrednio zainstalowane przez użytkownika aplikacje (znajdują się ona na liście w pliku /var/lib/portage/world), ale pominie uaktualnienia ich zależności. Aby uaktualnić całe oprogramowanie wraz z zależnościami, należy dodać jeszcze argument --deep:

# emerge --update --deep world

W związku z tym, że poprawki związane z bezpieczeństwem zdarzają się nie tylko w programach zainstalowanych bezpośrednio, ale również w ich zależnościach zalecamy częste uruchamianie tego polecenia.

Jeżeli ostatnio zmieniane były flagi USE, polecamy również dodanie do całej tej linii poleceń argumentu --newuse. Portage sprawdzi wtedy czy zmiany we flagach USE niosą ze sobą potrzebę przekompilowania i przeinstalowania którychś z zainstalowanych programów:

# emerge --update --deep --newuse world

Metapakiety

Niektóre z pakietów w drzewie Portage nie mają żadnej zawartości, ale służą do instalacji całych kolekcji innych pakietów. Doskonałym przykładem takiego zestawu jest pakiet KDE, który służy do instalowania kompletnego środowiska graficznego. Możemy dzięki jego istnieniu przy pomocy jednego polecenia dodać do systemu wszystkie programy, biblioteki oraz zależności związane z KDE.

Jeśli kiedykolwiek zdarzy nam się posiadać taki pakiety zainstalowany w systemie, będziemy mieli pewien problem z jego odinstalowaniem. Zwykłe wpisanie emerge --unmerge poczyni stosunkowo małe spustoszenie w niepotrzebnych nam już plikach, ponieważ ogromna ilość zależności pozostanie w systemie.

Portage jest w stanie poradzić sobie z tego typu "osieroconymi" zależnościami, ale najpierw należy w pełni uaktualnić swój system, uwzględniając przy tym również zmiany we flagach USE. Następnie uruchamiamy wspomniane już wcześniej polecenie emerge --depclean, aby usunąć "osierocone" zależności, a kiedy już skończymy je odinstalowywać przebudowujemy wszystkie programy, które wcześniej były dynamicznie z nimi zlinkowane, a teraz już ich nie potrzebują.

Cały proces sprowadza się do wpisania trzech prostych poleceń:

# emerge --update --deep --newuse world
# emerge --depclean
# revdep-rebuild

Program revdep-rebuild znajduje się w pakiecie gentoolkit wraz z kilkoma innymi bardzo przydatnymi programami. Aby używać programu, należy oczywiście najpierw zainstalować ten pakiet.

# emerge gentoolkit

1.d. Kiedy Portage narzeka

...na sloty, virtuale, gałęzie, architektury i profile

Jak już wcześniej zaznaczaliśmy, Portage jest potężnym narzędziem i posiada możliwości jakich nie ma żaden inny program do zarządzania oprogramowaniem. Postaramy się teraz w skrócie przedstawić kilka aspektów pracy z Portage.

W Portage możliwe jest posiadanie kilku różnych wersji jednego programu. Podczas gdy inne dystrybucje obchodzą problem nadając po prostu takim pakietom różne numery porządkowe, jak np. freetype i freetype2 Portage wykorzystuje tu technologię tzw. slotów. Każdy ebuild posiada osobny slot dla wersji programu, którą reprezentuje, więc ebuildy różnych wersji programu mogą koegzystować w jednym systemie. Na przykład paczka freetype posiada ebuildy z ustawionymi wartościami SLOT="1" i SLOT="2".

Są również pakiety, które wykonują te same czynności, ale w różny sposób. Doskonałym przykładem takiego programu są loggery systemowe: metalogd, sysklogd i syslog-ng. Aplikacje, które do prawidłowego działania potrzebują loggera systemowego nie mogą posiadać w zależnościach jedynie np. metalogd, ponieważ pozostałe programy z tej grupy również są w stanie spełnić tę zależność. Do tego właśnie służą Virtuale. Każdy z loggerów systemowych dostarcza po prostu virtual/syslog, który jest jednocześnie zależnością dla innych programów.

Oprogramowanie znajdujące się w drzewie Portage jest podzielone na gałęzie. Domyślnie używana jest gałąź stabilna dla danej architektury. Nowe i nieprzetestowane programy są dodawane do gałęzi niestabilnej, czyli testowej. Dopóki ich niezawodność nie zostanie potwierdzona i nie zostaną przeniesione do gałęzi stabilnej, Portage nie zainstaluje ich, chociaż ebuildy nowszych wersji będą się znajdowały w drzewie.

Niektóre programy są dostępne tylko dla określonych architektur. Czasem na innych wcale nie działają, czasem potrzebują jeszcze nieco testów, może się też zdarzyć, że deweloper danego programu nie ma po prostu czasu lub możliwości, aby przetestować taki pakiet na różnych architekturach.

Każdej instalacji Gentoo przypisany jest określony profil, który zawiera między innymi listę pakietów, które są niezbędne do prawidłowego działania systemu.

Zablokowane pakiety

[blocks B     ] mail-mta/ssmtp (is blocking mail-mta/postfix-2.2.2-r1)

!!! Error: the mail-mta/postfix package conflicts with another package.
!!!        both can't be installed on the same system together.
!!!        Please use 'emerge --pretend' to determine blockers.

W ebuildach znajdują się określone pola, które informują Portage na temat zależności danego programu. Są dwa rodzaje takich zależności: Zależności niezbędne do zbudowania programu - deklarowane przez DEPEND oraz zależności niezbędne do jego uruchomienia - deklarowane jako RDEPEND. Kiedy któraś z tych zależności jest niekompatybilna z jakimś virtualem lub pakietem, jest włączana blokada.

Są dwie możliwości na pozbycie się blokady: Nie instalować programu lub usunąć pakiet, który go blokuje. W podanym powyżej przykładzie mogliśmy wybrać pomiędzy rezygnacją z instalacji postfix lub usunięciem ssmtp.

Możemy również zauważyć wzajemne blokowanie się pakietów, takich jak na przykład <media-video/mplayer-bin-1.0_rc1-r2. W tym przypadku należy zaktualizować pakiet do najnowszej wersji co pomoże usunąć blokadę.

Może również się zdarzyć, że blokują się pakiety, które nie są jeszcze zainstalowane. W takim rzadkim przypadku należy się dokładnie zastanowić czemu oba mają być zainstalowane. Zwykle można sobie poradzić tylko z jednym z tych pakietów. Jeśli nie jest to możliwe prosimy o zgłoszenie błędu.

Zamaskowane pakiety

!!! all ebuilds that could satisfy "bootsplash" have been masked.

!!! possible candidates are:

- gnome-base/gnome-2.8.0_pre1 (masked by: ~x86 keyword)
- lm-sensors/lm-sensors-2.8.7 (masked by: -sparc keyword)
- sys-libs/glibc-2.3.4.20040808 (masked by: -* keyword)
- dev-util/cvsd-1.0.2 (masked by: missing keyword)
- games-fps/unreal-tournament-451 (masked by: package.mask)
- sys-libs/glibc-2.3.2-r11 (masked by: profile)

Jeśli zechcemy zainstalować paczkę, która nie jest dostępna dla naszego systemu dostaniemy właśnie taki komunikat. Możemy wtedy zainstalować inny spełniający te same funkcje, ale dostępny dla naszego systemu program lub poczekać aż pakiet zostanie odmaskowany. Maskowanie pakietów nie odbywa się bez przyczyny:

• Słowo kluczowe ~arch oznacza, że aplikacja nie została jeszcze dostatecznie sprawdzona na naszej architekturze, aby znaleźć się w gałęzi stabilnej. Zwykle w takim przypadku wystarczy poczekać kilka dni (rzadziej tygodni) i spróbować ponownej jej instalacji.
• Słowo kluczowe -arch lub -* oznacza, że program nie działa na naszej architekturze. Jeśli jednak aplikacja działa i są dowody na poparcie tej tezy prosimy o zgłoszenie tego na naszą Bugzillę.
• Komunikat missing keyword oznacza, że aplikacja nie została jeszcze przetestowana na tej architekturze. W takim przypadku należy poprosić któregoś z deweloperów zajmujących się tymi sprawami o przetestowanie pakietu lub uczynić to własnoręcznie i zgłosić wyniki swoich badań na Bugzillę.
• Komunikat package.mask oznacza, że pakiet jest uszkodzony, niestabilny lub co gorsza w ogóle nie nadaje się do użytku.
• Komunikat z tekstem profile oznacza, że pakiet nie pasuje do naszego profilu systemowego i gdybyśmy go zainstalowali mógłby zepsuć nasz system.

Brakujące zależności

emerge: there are no ebuilds to satisfy ">=sys-devel/gcc-3.4.2-r4".

!!! Problem with ebuild sys-devel/gcc-3.4.2-r2
!!! Possibly a DEPEND/*DEPEND problem.

Aplikacja, którą próbujemy zainstalować jest zależna od pakietu, który nie jest dostępny dla danej architektury. Należy sprawdzić na Bugzilli czy problem został już zgłoszony i ewentualnie go zgłosić, jeśli nie zrobił tego ktoś inny. Jeśli nie są mieszane różne typów gałęzi Portage w jednym systemie to problem ten nie powinien wystąpić i zwykle oznacza błąd w drzewie.

Niejasna nazwa pakietu

!!! The short ebuild name "aterm" is ambiguous.  Please specify
!!! one of the following fully-qualified ebuild names instead:

    dev-libs/aterm
    x11-terms/aterm

Program, który próbujemy zainstalować ma nazwę, którą posiada więcej niż jeden pakiet. Aby rozwiązać ten problem wystarczy dokładniej sprecyzować co chcemy zainstalować dodając przed nazwę programu kategorię, do której on należy.

Wzajemnie od siebie zależne pakiety

!!! Error: circular dependencies:

ebuild / net-print/cups-1.1.15-r2 depends on ebuild / app-text/ghostscript-7.05.3-r1
ebuild / app-text/ghostscript-7.05.3-r1 depends on ebuild / net-print/cups-1.1.15-r2

Sprawa jest prosta. Dwa pakiety (lub więcej), które próbujemy zainstalować są od siebie wzajemnie zależne i w związku z tym nie mogą zostać zainstalowane. Oznacza to błąd w drzewie Portage, który zostanie usunięty możliwie najszybciej od momentu jak pierwszy użytkownik zgłosi ten problem na Bugzillę.

Nieudane pobieranie

!!! Fetch failed for sys-libs/ncurses-5.4-r5, continuing...
(...)
!!! Some fetch errors were encountered.  Please see above for details.

Oznacza to, że Portage nie było w stanie pobrać źródeł żądanej aplikacji, w związku z czym zostało zmuszone do zrezygnowania z jej instalacji i będzie instalowało kolejne programy z listy. Błąd najczęściej jest spowodowany wstawieniem złego adresu serwera w ebuildzie programu lub dlatego, że serwer lustrzany nie zdążył jeszcze się zsynchronizować. Możliwa jest również sytuacja, że serwer, na którym znajdują się źródła, z jakichś względów jest nieczynny.

Należy odczekać około godziny i spróbować ponownie zainstalować program.

Ochrona profilu systemu

!!! Trying to unmerge package(s) in system profile. 'sys-apps/portage'
!!! This could be damaging to your system.

Taki komunikat oznacza, że pakiet, który próbujemy usunąć jest kluczowy dla działania systemu. Znajduje się on na liście profilu systemowego jako niezbędny i w związku z tym nie zostanie usunięty.

Błędy przy sprawdzaniu plików z sumami kontrolnymi

Czasami przy instalacji pakietu pojawia się następujący błąd:

>>> checking ebuild checksums

!!! Digest verification failed:

Jest to znak nieprawidłowego działania Portage jednak częściej przyczyną jest pomyłka dewelopera, który popełnił błąd przy dodawaniu pakietu do drzewa.

Kiedy zobaczymy taki błąd nie należy samemu tworzyć nowych sum kontrolnych. Wydanie polecenia ebuild coś manifest nie naprawi problemu, a może go nawet pogłębić!

Zamiast tego powinniśmy odczekać godzinę lub dwie, aż ktoś naprawi uszkodzony plik. Jest wielce prawdopodobne, że błąd został już zgłoszony jednak musi upłynąć kilka chwil, zanim prawidłowy plik pojawi się w drzewie Portage. W czasie gdy będziemy czekać na rozwiązanie, powinniśmy sprawdzić Bugzille czy ktokolwiek już zgłosił problem z danym pakietem. Jeżeli nie, powinniśmy sami wypełnić i wysłać raport.

Po rozwiązaniu problemu, należy ponownie przeprowadzić aktualizację drzewa Portage, aby pobrać naprawiony plik z sumami kontrolnymi.

2. Flagi USE

2.a. Czym są flagi USE?

Idea flag USE

Kiedy instalujemy Gentoo (lub dowolną inną dystrybucję albo nawet inny system operacyjny) zwykle dokonujemy wyborów zależnych od środowiska, w którym przychodzi nam pracować. Instalacja dla serwera różni się od instalacji dla stacji roboczej. Konfiguracja komputera dla gracza różni się od tej dla komputera przeznaczonego do obróbki grafiki 3D.

Nie jest tak tylko w przypadku pakietów, które wybieramy przy instalacji, ale także w przypadku cech, które dany pakiet powinien posiadać. Jeżeli nie potrzebujemy obsługi OpenGL, dlaczego mielibyśmy instalować OpenGL oraz jego obsługę w większości pakietów? Jeżeli nie chcemy używać KDE, dlaczego mamy budować pakiety ze wsparciem dla KDE, podczas gdy bez problemów mogą pracować bez niego?

Aby ułatwić użytkownikom decydowanie o tym czego potrzebują, a czego nie chcą instalować i aktywować, stworzyliśmy dla nich specjalne środowisko. Dzięki niemu użytkownik może wybrać to co jest mu potrzebne, a Portage znacznie ułatwi mu cały proces wybierania najlepszych ustawień.

Definicja flag USE

Każda flaga jest słowem kluczowym, które reprezentuje wspierane funkcje oraz informacje o zależnościach dla wybranego wątku. Jeżeli zdefiniujemy jakąś flagę USE, Portage będzie wiedziało, że jest nam potrzebne wsparcie funkcji przypisanej temu słowu kluczowemu. Oczywiście uwzględnione zostaną także pakiety zależne.

Przyjrzyjmy się zatem przykładowi: słowu kluczowemu kde. Jeżeli nie posiadamy go wśród zmiennych USE, wszystkie pakiety, które posiadają opcjonalną obsługę KDE zostaną skompilowane bez obsługi KDE. Wszystkie pakiety, które będą opcjonalnie zależne od KDE, zostaną zainstalowane bez bibliotek KDE jako zależności. Jeżeli zdefiniujemy słowo kluczowe kde, to te pakiety zostaną skompilowane z obsługą KDE a biblioteki KDE zostaną zainstalowane jako pakiety zależne.

Dzięki dobremu doborowi słów kluczowych otrzymamy system dokładnie dostosowany do naszych potrzeb.

Jakie wyróżniamy flagi USE?

Wyróżniamy dwa typy flag USE: globalne oraz lokalne.

• Globalne flagi USE są używane dla większej ilości pakietów, są ogólnosystemowe. Większość ludzi postrzega je właśnie jako flagi USE.
• Lokalne flagi USE są używane przez pojedynczy pakiet w celu podjęcia decyzji specyficznych dla danego pakietu.

Lista dostępnych globalnych flag USE jest dostępna w Internecie lub też lokalnie w pliku /usr/portage/profiles/use.desc.

Lista dostępnych lokalnych flag USE znajduje się w pliku /usr/portage/profiles/use.local.desc.

2.b. Używanie flag USE

Deklarowanie stałych flag USE

Kiedy już odkryliśmy jak ważny jest właściwy dobór flag USE możemy przystąpić do omawiania tego jak się je deklaruje.

Jak już wcześniej wspominaliśmy, wszystkie flagi USE są deklarowane wewnątrz zmiennej USE. Aby ułatwić użytkownikom szukanie oraz wybór flag USE, dostarczamy dobrany przez nas domyślny zestaw. Zestaw ten jest kolekcją flag, które według nas są najczęściej wybierane przez użytkowników Gentoo. Domyślny zestaw jest zadeklarowany w pliku make.defaults i jest częścią wybranego profilu.

Profil, którego system używa jest wskazywany przez dowiązanie symboliczne /etc/make.profile. Każdy profil działa ponad innym, większym profilem, końcowy wynik jest więc sumą wszystkich profili. Górny profil to base (/usr/portage/profiles/base).

Rzućmy okiem na domyślne ustawienia dla profilu 2004.3:

(Ten przykład to suma ustawień w plikach base, default-linux,
default-linux/x86 i default-linux/x86/2004.3)
USE="x86 oss apm arts avi berkdb bitmap-fonts crypt cups encode fortran f77
foomaticdb gdbm gif gpm gtk imlib jpeg kde gnome libg++ libwww mad
mikmod motif mpeg ncurses nls oggvorbis opengl pam pdflib png python qt
quicktime readline sdl spell ssl svga tcpd truetype X xml2 xmms xv zlib"

Jak łatwo zauważyć, domyślny zestaw zawiera dość dużo słów kluczowych. Pamiętajmy, aby nie dokonywać zmian w pliku make.defaults, w celu dostosowywania zmiennej USE do swoich potrzeb. Zmiany te zostaną usunięte przy najbliższej aktualizacji drzewa Portage!

Aby zmienić domyślne ustawienia, musimy dodać (lub usunąć) słowa kluczowe w zmiennej USE. Dokonuje się tego definiując globalnie zmienną USE w pliku /etc/make.conf. Do tej zmiennej możemy dodać flagi, które są nam potrzebne lub też usunąć te, których nie potrzebujemy. Usunięcia flagi dokonuje się poprzez wstawienie znaku minus (-) przed wybraną flagą.

Na przykład, aby usunąć obsługę KDE i QT oraz dodać obsługę ldap, zmienna USE w pliku /etc/make.conf powinna wyglądać następująco:

USE="-kde -qt3 -qt4 ldap"

Deklarowanie flag USE tylko dla wybranego pakietu

Czasami mamy zamiar zadeklarować wybraną flagę USE dla jednej (czasem kilku) aplikacji, ale nie dla całego systemu. Aby tego dokonać, będziemy zmuszeni do utworzenia katalogu /etc/portage (jeżeli nie istnieje) i wyedytowania pliku /etc/portage/package.use. W większości przypadków jest to pojedyńczy plik, jednak może to być również nazwa katalogu. Aby uzyskać więcej informacji należy przeczytać strone manuala dostępną po wydaniu polecenia man portage. W poniższych przykładach założono, że package.use jest plikiem.

Na przykład, jeżeli nie chcemy globalnego wsparcia dla berkdb, ale chcielibyśmy mieć jego wsparcie dla mysql, powinniśmy dodać:

dev-db/mysql berkdb

Oczywiście możemy też wyłączyć flagi USE dla wybranej aplikacji. Na przykład, jeżeli nie chcemy obsługi javy w PHP:

dev-php/php -java

Deklarowanie tymczasowych flag USE

Czasami zachodzi potrzeba użycia flagi USE tylko jeden raz. Zamiast dwukrotnego edytowania pliku /etc/make.conf (aby wprowadzić, a potem cofnąć zmiany w USE) możemy po prostu zadeklarować tą flagę jako zmienną środowiskową. Pamiętajmy jednak, że jeżeli ponownie zainstalujemy lub zaktualizujemy daną aplikację (przypadkowo lub przy aktualizacji systemu) to takie zmiany nie zostaną ponownie wprowadzone.

Dla przykładu usuniemy obsługę javy na czas instalacji seamonkey.

# USE="-java" emerge seamonkey

Pierwszeństwo

Oczywiście istnieje pierwszeństwo w przydzielaniu priorytetów konkretnym flagom USE. Nie ma sensu deklarować zmiennej USE="-java" tylko po to, aby zobaczyć, że java i tak zostanie użyta w związku z zadeklarowaniem na wyższym poziomie. Hierarchia flag USE prezentuje się następująco (pierwsze pozycje mają najniższy priorytet):

1. Domyślne ustawienia zmiennej USE znajdujące się w pliku make.defaults będącym częścią wybranego profilu
2. Zdefiniowana przez użytkownika zmienna USE znajdująca się w pliku /etc/make.conf
3. Zdefiniowana przez użytkownika zmienna USE w pliku /etc/portage/package.use
4. Zmienna USE zdefiniowana przez użytkownika jako zmienna środowiskowa.

Aby sprawdzić ostateczne ustawienia zmiennej USE widziane przez Portage wpisujemy polecenie emerge --info. Polecenie to wskaże wszystkie istotne zmienne (włączając zmienną USE) z wartościami używanymi aktualnie przez Portage.

# emerge --info

Adaptacja systemu do nowych flag USE

Jeżeli zmodyfikowaliśmy flagi USE i chcemy uaktualnić system tak, aby pakiety używały nowych flag USE musimy uruchomić emerge z opcją --newuse.

# emerge --update --deep --newuse world

Następnie uruchamiamy depclean, który usunie niepotrzebne zależności, które zostały zainstalowane na "starym" systemie, ale są nieaktualne z nowymi flagami USE.

# emerge -p --depclean

Po zakończeniu polecenia depclean uruchamiamy revdep-rebuild, aby przebudować aplikacje, które mogą być połączone dynamicznie z usuniętymi bibliotekami. revdep-rebuild jest częścią pakietu gentoolkit.

 # revdep-rebuild

Po zakończeniu tych wszystkich czynności system będzie używał nowych ustawień flag USE.

2.c. Zmienne USE specyficzne dla pakietów

Przeglądanie dostępnych flag USE

Weźmy na przykład seamonkey i dowiedzmy się których flag USE używa. Użyjemy do tego polecenia emerge z parametrami --pretend oraz --verbose:

# emerge --pretend --verbose seamonkey
These are the packages that I would merge, in order:

Calculating dependencies ...done!
[ebuild   R   ] www-client/seamonkey-1.0.7 USE="crypt gnome java -debug -ipv6
-ldap -mozcalendar -mozdevelop -moznocompose -moznoirc -moznomail -moznopango
-moznoroaming -postgres -xinerama -xprint" 0 kB

emerge nie jest jedynym narzędziem wykorzystywanym w celu przeglądania informacji o pakietach. Do dyspozycji mamy jeszcze program equery, znajdujący się w pakiecie gentoolkit. Zacznijmy od zainstalowania gentoolkit:

# emerge gentoolkit

Następnie uruchamiamy equery z argumentem uses aby przejrzeć flagi USE dla konkretnego pakietu. Dla przykładu sprawdźmy pakiet gnumeric:

# equery --nocolor uses =gnumeric-1.6.3 -a
[ Searching for packages matching =gnumeric-1.6.3... ]
[ Colour Code : set unset ]
[ Legend        : Left column  (U) - USE flags from make.conf  ]
[               : Right column (I) - USE flags packages was installed with ]
[ Found these USE variables for app-office/gnumeric-1.6.3 ]
 U I
- - debug    : Enable extra debug codepaths, like asserts and extra output. If
               you want to get meaningful backtraces see
               http://www.gentoo.org/proj/en/qa/backtraces.xml .
- - gnome    : Adds GNOME support
+ + python   : Adds support/bindings for the Python language
- - static   : !!do not set this during bootstrap!! Causes binaries to be
               statically linked instead of dynamically

3. Funkcje Portage

3.a. Funkcje Portage

Portage posiada szereg dodatkowych funkcji, które potrafią znacznie uprzyjemnić pracę z Gentoo. Wiele z nich opiera się na zewnętrznych programach, które zwiększają wydajność, stabilność i bezpieczeństwo pracy.

Aby włączyć lub wyłączyć określone dodatkowe funkcje Portage należy odpowiednio zmienić zmienną FEATURES w pliku /etc/make.conf. Zmienna ta to podzielona spacjami lista nazw dodatkowych możliwości. W niektórych przypadkach, aby móc korzystać z pewnych funkcji trzeba również zainstalować dodatkowe oprogramowanie.

Nie wszystkie funkcje, które Portage obsługuje są tutaj wymienione. By poznać wszystkie funkcje, należy przeczytać dokumentację make.conf:

$ man make.conf

By dowiedzieć się, jakie FEATURES są standardowo włączone, należy uruchomić emerge --info i poszukać zmiennej FEATURES za pomocą programu grep:

$ emerge --info | grep FEATURES

3.b. DistCC

Czym jest DistCC?

Distcc to program, dzięki któremu możemy rozłożyć obciążenie związane z kompilacją pomiędzy kilka niekoniecznie identycznych maszyn. Klient distcc wysyła wszystkie potrzebne informacje do dostępnych serwerów DistCC (na których jest uruchomiony distccd), które następnie kompilują części kodu źródłowego dla klienta. Końcowym wynikiem jest krótszy czas kompilacji.

Dokładniejsze informacje na temat distcc (oraz informacje na temat tego, jak używać distcc w Gentoo) można odnaleźć Dokumentacji Distcc Gentoo.

Instalacja DistCC

Distcc jest dostarczany z graficznym monitorem, dzięki któremu możliwe jest obserwowanie postępu zadań, które komputer wysłał do serwerów distcc. Jeśli używany jest Gnome, należy umieścić "gnome" w ustawieniach flag USE. Jeśli nie jest zainstalowany Gnome, a mimo to chcielibyśmy mieć możliwość monitorowania distcc, należy umieścić w flagach USE "gtk".

# emerge distcc

Używanie distcc z Portage

Najpierw należy dodać distcc do zmiennej FEATURES w pliku /etc/make.conf. Następnie należy dostosować zmienną MAKEOPTS do swoich potrzeb. Zwykle ma ona postać -jX, gdzie X to liczba procesorów, na których uruchomiony jest distccd (włącznie z komputerem, na którym teraz pracujemy) powiększona o jeden. Czasem inne wartości od tych zalecanych przynoszą lepsze rezultaty.

Teraz trzeba uruchomić distcc-config i wprowadzić listę dostępnych serwerów DistCC. W naszym prostym przykładzie zakładamy, że dostępne serwery DistCC to: 192.168.1.102 (aktualny host), 192.168.1.103 i 192.168.1.104 (dwa "zdalne" hosty):

# distcc-config --set-hosts "192.168.1.102 192.168.1.103 192.168.1.104"

Trzeba też pamiętać o uruchomieniu demona distccd na zdalnych hostach:

# rc-update add distccd default
# /etc/init.d/distccd start

3.c. ccache

Czym jest ccache?

ccache jest szybkim cache kompilatora. Dzięki niemu pliki pośrednie powstające w trakcie kompilacji będą cache'owane i podczas rekompilacji programu czas budowania plików wynikowych zostanie znacznie skrócony. W typowych sytuacjach czas kompilacji może być od 5 do 10 razy krótszy.

Szczegóły na temat ccache można odnaleźć na stronie domowej ccache.

Instalacja ccache

Instalowanie ccache w Gentoo jest bardzo proste - jedyne, co należy zrobić, to zainstalować odpowiedni pakiet:

# emerge ccache

Portage i ccache

Otwieramy plik /etc/make.conf i zmieniamy FEATURES tak, aby zawierało słowo kluczowe ccache oraz dodajemy zmienną CCACHE_SIZE o wartości "2G".

CCACHE_SIZE="2G"

Aby sprawdzić czy ccache działa poprawnie, należy sprawdzić statystyki. Ponieważ Portage używa innych katalogów domowych ccache, należy ustawić zmienną CCACHE_DIR na początku polecenia:

# CCACHE_DIR="/var/tmp/ccache" ccache -s

Katalog /var/tmp/ccache jest domyślną lokalizacją ccache w Portage. Jeżeli chcemy zmodyfikować tę pozycję należy ustawić zmienną CCACHE_DIR w pliku /etc/make.conf.

Jednak gdy będziemy uruchamiać polecenie ccache, będzie ono odwoływało się do domyślnej lokalizacji ${HOME}/.ccache, dlatego też musimy za każdym razem ustawiać zmienną CCACHE_DIR, gdy będziemy chcieli zobaczyć statystyki.

Używanie ccache dla kompilacji programów w C spoza Portage

Jeśli ccache ma być używane do kompilacji programów w C, ale nie znajdujących się w Portage, należy dodać katalog /usr/lib/ccache/bin na początku zmiennej PATH (przed wpisem /usr/bin). Robi się to przez edytowanie pliku .bash_profile w naszym katalogu domowym. Użycie .bash_profile jest jednym ze sposobów określenia zmiennej PATH.

PATH="/usr/lib/ccache/bin:/opt/bin:${PATH}"

3.d. Pakiety binarne

Tworzenie pakietów binarnych

Portage umożliwia pracę z prekompilowanymi pakietami. Nie dostarczamy wprawdzie ich zestawów użytkownikom (poza GRP, które wychodzą co kilka miesięcy wraz z wydaniami Gentoo), ale mimo wszystko pozostawiamy możliwość korzystania z nich w naszym oprogramowaniu.

Jeśli dany pakiet już jest zainstalowany, można użyć polecenia quickpkg, które utworzy archiwum tar zawierające zainstalowane pliki (bardzo przydatne przy robieniu kopii zapasowych). Jeśli nie jest zainstalowany, należy skorzystać z polecenia emerge z opcją --buildpkg lub --buildpkgonly.

Aby Portage domyślnie tworzyło binarne pakiety, wystarczy umieścić słowo kluczowe buildpkg w zmiennej FEATURES.

Szersze możliwości budowania pakietów daje program catalyst. Wszystkie informacje o nim znajdują się w Catalyst FAQ.

Instalacja prekompilowanych pakietów

Fakt, że Gentoo nie posiada repozytorium z prekompilowanymi pakietami nie oznacza, że użytkownicy nie mogą stworzyć takiego samodzielnie. Aby z niego korzystać, należy ustawić zmienną PORTAGE_BINHOST tak, aby na nie wskazywała. Na przykład, jeżeli prekompilowane pakiety znajdują się pod adresem ftp://buildhost/gentoo:

PORTAGE_BINHOST="ftp://buildhost/gentoo"

Za każdym razem, gdy chcemy zainstalować prekompilowany pakiet, musimy skorzystać z parametru --getbinpkg razem z opcją --usepkg. Pierwsza opcja nakazuje pobrać prekompilowany pakiet ze zdalnego serwera, druga nakazuje emerge skorzystanie ze ściągniętego pakietu podczas instalacji.

Na przykład, aby zainstalować gnumeric z prekompilowanego pakietu:

# emerge --usepkg --getbinpkg gnumeric

Więcej informacji o prekompilowanych pakietach znajduje się na stronie man programu emerge.

$ man emerge

3.e. Pobieranie plików

Pobieranie równoległe

Kiedy instalujemy kilka pakietów, Portage może pobierać pliki źródłowe dla pozostałych pakietów, które są na liście nawet podczas kompilacji innego programu, przez co skraca się czas całej operacji. Aby uaktywnić tę funkcję należy dodać wartość "parallel-fetch" do zmiennej FEATURES.

Userfetch

Kiedy uruchomimy Portage jako root, wpis FEATURES="userfetch" pozwoli na odrzucenie przez Portage uprawnień administratora podczas ściągania plików źródłowych dla pakietów. Dzięki temu uzyskamy małą poprawę bezpieczeństwa.

4. Skrypty startowe

4.a. Poziomy działania

Uruchamianie systemu operacyjnego

Podczas uruchamiania systemu operacyjnego na ekranie pojawia się dużo, nie zawsze zrozumiałego tekstu. Gdy przyjrzeć się dokładniej, można zauważyć, że tekst ten jest za każdym razem taki sam. Cały ten proces nazywamy sekwencją startową, która (w większym lub mniejszym stopniu) jest skonfigurowana statycznie.

Najpierw bootloader ładuje obraz jądra systemu do pamięci i zleca procesorowi jego wykonanie. W chwili kiedy jądro zostanie załadowane i wykonane, uruchamiane są specyficzne zadania, związane ściśle z jądrem po czym uruchamiany jest proces init.

Proces ten następnie upewnia się czy wszystkie systemy plików (zdefiniowane w /etc/fstab) zostały poprawnie zamontowane i są gotowe do pracy. Następnie uruchamiane są poszczególne skrypty umieszczone w katalogu /etc/init.d, które mają za zadanie uruchomić kolejno wszystkie usługi niezbędne do poprawnego działania systemu.

Na koniec, kiedy wszystkie skrypty zostaną wykonane, init aktywuje terminale (w większości przypadków są to po prostu wirtualne konsole, między którymi można się przełączać za pomocą kombinacji klawiszy Alt-F1, Alt-F2 itd.) przy pomocy służącego do tego programu pod nazwą agetty. Sprawdza on czy użytkownik może się zalogować na dany terminal, uruchamiając login.

Skrypty Init

Skrypty umieszczone w katalogu /etc/init.d nie są uruchamiane przez init w przypadkowej kolejności. Co więcej, nie są uruchamiane wszystkie naraz lecz w określonej kolejności. Informacje na ten temat tej kolejności pobierane są z katalogu /etc/runlevels.

Na samym początku init inicjuje te skrypty, do których dowiązania symboliczne znajdują się w katalogu /etc/runlevels/boot. Zazwyczaj uruchamiane są one w kolejności alfabetycznej. Wyjątek stanowią te, które posiadają informacje o zależnościach. Mówią one o tym, że do prawidłowego działania danej usługi musi wcześniej zostać uruchomiona inna.

Kiedy skrypty mające dowiązanie w /etc/runlevels/boot zostaną uruchomione, init kontynuuje uruchamianie tych, do których dowiązania znajdują się w katalogu /etc/runlevels/default. Podobnie jak w poprzednim przypadku, uruchamiane są w kolejności alfabetycznej. Wyjątek stanowią tylko sytuacje, gdy muszą zostać spełnione zależności niezbędne do poprawnego przeprowadzenia procesu startowego.

Jak działa Init

Oczywiście o wszystkim nie decyduje sam init. Potrzebuje on stosownego pliku konfiguracyjnego, który zawiera informacje o zadaniach jakie ma wykonać. Ten plik to /etc/inittab.

Na początku tej części dokumentu jest wzmianka o tym, że init w początkowej fazie działania sprawdza czy systemy plików zostały zamontowane poprawnie. Definicja tego zadania w /etc/inittab wygląda następująco:

si::sysinit:/sbin/rc sysinit

Powyższa linia mówi procesowi init, że w celu inicjacji systemu ma wykonać polecenie /sbin/rc sysinit. Tak naprawdę to właśnie skrypt /sbin/rc zajmuje się inicjacją, a init jedynie zleca zadania innym procesom.

Następnie init uruchamia wszystkie skrypty, do których dowiązania symboliczne znajdują się we wspomnianym wcześniej katalogu /etc/runlevels/boot. W pliku konfiguracyjnym jest to zdefiniowane w następujący sposób:

rc::bootwait:/sbin/rc boot

Ponownie skrypt rc wykonuje niezbędne zadania. Argument dla rc (boot) jest taki sam jak nazwa podkatalogu w /etc/runlevels, w którym znajdują się dowiązania do skryptów wykonywanych w tej części procesu uruchamiania systemu.

Następnie init sprawdza plik /etc/inittab w celu odszukania informacji, w który poziom działania (runlevel) ma "wejść" system:

id:3:initdefault:

W tym przypadku jest to poziom (runlevel) o numerze 3. Dzięki tej informacji init sprawdza co musi zostać uruchomione aby system zaczął działać w trzecim poziomie (rulevelu 3).

l0:0:wait:/sbin/rc shutdown
l3:3:wait:/sbin/rc default
l4:4:wait:/sbin/rc default
l5:5:wait:/sbin/rc default
l6:6:wait:/sbin/rc reboot

W linii, która definiuje trzeci poziom, podobnie jak w przypadku poprzednich, jest odwołanie do skryptu rc. Tym razem jest on uruchamiany z argumentem default. Argument ten brzmi tak samo, jak nazwa jednego z podkatalogów w /etc/runlevels.

Po tym jak rc zakończy swoją pracę, init decyduje o tym jakie, oraz przy użyciu jakich poleceń, mają zostać aktywowane wirtualne konsole.

c1:12345:respawn:/sbin/agetty 38400 tty1 linux
c2:12345:respawn:/sbin/agetty 38400 tty2 linux
c3:12345:respawn:/sbin/agetty 38400 tty3 linux
c4:12345:respawn:/sbin/agetty 38400 tty4 linux
c5:12345:respawn:/sbin/agetty 38400 tty5 linux
c6:12345:respawn:/sbin/agetty 38400 tty6 linux

Co to jest poziom działania (runlevel)?

Init używając notacji, w której każdy poziom działania ma swój numer decyduje o tym, który z nich ma być w danej chwili aktywny. Poziom działania (runlevel) to stan, w którym uruchomiony jest system operacyjny. Każdy z poziomów charakteryzuje się pewnym zestawem skryptów, które muszą być wykonane podczas wchodzenia lub wychodzenia z danego poziomu.

Gentoo posiada siedem zdefiniowanych poziomów: trzy wewnętrzne i cztery definiowane przez użytkownika. Wewnętrzne nazywają się sysinit, shutdown i reboot. Jak nietrudno się domyślić służą one kolejno do inicjacji, wyłączania oraz ponownego uruchamiania systemu.

Poziomy definiowane przez użytkownika związane są z podkatalogami /etc/runlevels: boot, default, nonetwork i single. W poziomie boot uruchamiane są wszystkie niezbędne usługi systemowe używane w pozostałych poziomach. Pozostałe trzy różnią się rodzajem uruchamianych usług: default służy do uruchamiania "standardowych" operacji, nonetwork wykorzystywany jest w przypadkach kiedy do uruchomienia danej usługi nie jest wymagane połączenie z siecią, zaś single używany jest tylko wtedy, gdy system wymaga naprawy.

Praca ze skryptami Init

Skrypty uruchamiane przez proces rc nazywane są skryptami init (ang. init scripts). Umieszczone są w katalogu /etc/init.d i mogą być uruchamiane wraz z następującymi argumentami: start, stop, restart, pause, zap, status, ineed, iuse, needsme, usesme lub broken.

Aby uruchomić, zatrzymać lub przeładować dowolną usługę (wraz z powiązanymi z nią innymi usługamii) należy użyć odpowiednio start, stop i restart. Przykładowo:

# /etc/init.d/postfix start

Aby wyłączyć daną usługę pozostawiając przy życiu usługi z nią powiązane należy użyć argumentu pause:

# /etc/init.d/postfix pause

Aby zobaczyć jaki status ma aktualnie dana usługa (włączony, wyłączony...) trzeba użyć argumentu status:

# /etc/init.d/postfix status

Jeśli powyższe polecenie zwróci informację, że Postfix jest uruchomiony, lecz faktycznie będzie inaczej, należy użyć argumentu zap w celu uaktualnienia informacji o statusie.

# /etc/init.d/postfix zap

Do sprawdzenia jakie zależności posiada usługa trzeba użyć argumentu iuse lub ineed. Dzięki ineed można uzyskać listę tych, które są niezbędne do prawidłowego działania danej usługi. iuse z kolei pokazuje te usługi, które mogą być używane lecz nie są niezbędne do jego uruchomienia i poprawnego funkcjonowania.

# /etc/init.d/postfix ineed

Podobnie można zapytać, które z usług w systemie wymagają danej usługi (needsme) lub mogą lecz nie muszą go używać (usesme):

# /etc/init.d/postfix needsme

Ostatnią z możliwości jest użycie argumentu, który wyświetli listę brakujących z listy wymaganych usług.

# /etc/init.d/postfix broken

4.b. Praca z rc-update

Co to jest rc-update?

W celu ustalenia poprawnej kolejności uruchamiania usług system init w Gentoo korzysta z drzewa zależności. Utrzymanie i zarządzanie takim drzewem bez użycia dodatkowych narzędzi byłoby bardzo nudnym i stosunkowo trudnym zadaniem. Na szczęście w Gentoo są już gotowe narzędzia, które znacznie ułatwiają zarządzanie poziomami działania oraz skryptami init.

Przy pomocy rc-update można dodawać i usuwać skrypty init z poziomu działania (runlevela). rc-update za każdym razem zleca skryptowi depscan.sh odbudowanie na nowo wspomnianego drzewa zależności.

Dodawanie i usuwanie usług

Pierwsze usługi są dodawane do poziomów działania już podczas procesu instalacyjnego. Wówczas można było nie skojarzyć czym jest na przykład poziom o nazwie "default", teraz powinno to być jasne. W celu dodania lub usunięcia usługi, rc-update wymaga podania między innymi argumentu określającego akcję (co rc-update ma zrobić): add, del lub show.

Zatem w celu dodania lub usunięcia skryptu init, należy wykonać polecenie rc-update wraz z argumentami add lub del, podając dalej nazwę skryptu oraz poziomu. Na przykład:

# rc-update del postfix default

Polecenie rc-update -v show pokazuje listę wszystkich dostępnych skryptów wraz z informacją w którym z poziomów są one uruchamiane:

# rc-update -v show

Można również wykonać polecenie rc-update show (bez -v) aby zobaczyć jakie skrypty są uruchomione w jakim poziomie.

4.c. Konfiguracja usług

Dlaczego dodatkowa konfiguracja jest potrzebna?

Skrypty init mogą być niekiedy dość skomplikowane. Dlatego część użytkowników nie jest zbytnio zainteresowana ich edytowaniem i modyfikacją z uwagi na możliwość popełnienia błędów. Jednak czasami możliwość zmiany konfiguracji usługi jest bardzo ważna. Na przykład w momencie kiedy zaistnieje potrzeba samodzielnego dodania jakiejś opcji.

Drugim powodem, dla którego ingerencja w skrypty init może okazać się pomocna jest możliwość uaktualnienia skryptów bez obawy przed tym, że dokonane zmiany nie zostaną zastosowane.

Katalog /etc/conf.d

Gentoo umożliwia bardzo prosty sposób konfiguracji poszczególnych usług. Każdy skrypt init może być skonfigurowany za pomocą stosownego pliku w katalogu /etc/conf.d. Na przykład skrypt apache2 (/etc/init.d/apache2) posiada swój własny plik konfiguracyjny, /etc/conf.d/apache2, w którym można umieścić wszelkie opcje z jakimi ma się uruchomić serwer Apache 2:

APACHE2_OPTS="-D PHP5"

Plik konfiguracyjny zawiera zmienne (podobnie jak /etc/make.conf), czyniąc konfigurację serwisów bardzo łatwą. Dostarcza nam to także więcej informacji na temat zmiennych (jako komentarz).

4.d. Pisanie skryptów Init

Czy muszę to robić?

Nie. Zwykle umiejętność pisania skryptów dla inita nie jest wymaganą umiejętnością ponieważ wraz z dystrybucją Gentoo dostarczane są wszystkie niezbędne skrypty, które pozwalają na uruchamianie wszystkich usług. Aczkolwiek umiejętność ta może okazać się przydatna, kiedy zainstalowana zostanie w systemie usługa, bez użycia do tego Portage. Wówczas będzie trzeba napisać skrypt samodzielnie.

Nie można używać skryptów init, które nie są napisane specjalnie dla Gentoo: skrypty init w Gentoo nie są kompatybilne ze skryptami z innych dystrybucji!

Szablon

Poniżej znajduje się szablon skryptu init.

#!/sbin/runscript

depend() {
  (Informacje o zależnościach)
}

start() {
  (Komendy niezbędne do uruchomienia usługi)
}

stop() {
  (Komendy niezbędne do jej wyłączenia)
}

restart() {
  (Polecenia służące do restartu usługi)
}

Każdy skrypt wymaga zdefiniowanej funkcji start(). Pozostałe funkcje są opcjonalne.

Zależności

W tym miejscu można zdefiniować dwa rodzaje zależności: use i need. Wspomniane wcześniej need są bardziej restrykcyjne niż zależności zdefiniowane jako use. Należy wybrać i dodać tu stosowne usługi, od których zależna będzie ta, dla której piszemy skrypt. Można też zdefiniować zależności wirtualne.

Zależności wirtualne to takie zależności, w których nie określą się ściśle konkretnej usługi. Przykładowo skrypt init wymaga działającego systemu logowania, lecz nie jest jasno określone jakiego. W Gentoo dostępnych jest kilka systemów logowania (metalogd, syslog-ng, sysklogd, ...). Zdefiniowanie każdego z nich (zainstalowanie i uruchomienie wszystkich wymienionych wyżej systemów logowania nie wydaje się być najlepszym pomysłem) nie było by dobrym rozwiązaniem. Jak można się jednak przekonać wszystkie z tych usług są akceptowane dzięki zależnościom wirtualnym.

Rzućmy okiem na informacje o zależnościach dla usługi Postfix.

depend() {
  need net
  use logger dns
  provide mta
}

Jak widać, postfix:

• wymaga usługi net (jest to zależność wirtualna, która może być spełniona przykładowo przez /etc/init.d/net.eth0).
• współpracuje z usługą logger (jest to zależność wirtualna, którą spełnia przykładowo /etc/init.d/syslog-ng).
• współpracuje z usługą dns (zależność wirtualna, którą spełnia przykładowo /etc/init.d/named).
• zapewnia usługę mta (zależność wirtualna, którą spełniają wszystkie serwery pocztowe).

Kontrola kolejności

Czasami nie potrzeba osobnego skryptu inicjującego. Chcemy jednak, aby usługa była uruchamiana przed (lub po) uruchomieniem innej usługi, jeśli ta jest dostępna w systemie i uruchamia się na tym samym poziomie działania. Informacji na ten temat możesz dostarczyć skryptowi za pomocą opcji before lub after.

Przyjrzyjmy się bliżej ustawieniom usługi Portmap:

depend() {
  need net
  before inetd
  before xinetd
}

Można użyć znaku "*" aby objąć wszystkie usługi w tym samym poziomie działania, nie jest to jednak zalecana metoda.

depend() {
  before *
}

Jeżeli nasza usługa musi posiadać prawo zapisywania na lokalnym dysku będzie potrzebowała localmount. Jeżeli zapisuje cokolwiek w katalogu /var/run, na przykład pliki pid, powinna zostać uruchomiona po bootmisc:

depend() {
  need localmount
  after bootmisc
}

Funkcje standardowe

Do tego aby funkcja depend() spełniała swoje zadanie, potrzebna jest poprawna definicja funkcji start(). Funkcja ta zawiera polecenia niezbędne do uruchomienia usługi. Wskazane jest użycie opcji ebegin i eend, dzięki którym można poinformować użytkownika co się w danym momencie dzieje:

start() {
  ebegin "Uruchamiam moja_usługa"
  start-stop-daemon --start --exec /path/to/my_service \
    --pidfile /path/to/my_pidfile
  eend $?
}

Zarówno --exec jak i --pidfile powinny zostać użyte w funkcjach start i stop. Jeżeli usługa nie tworzy pliku pid, należy użyć parametru --make-pidfile jeśli jest to możliwe. Należy jednak dla pewności przetestować możliwość użycia tego parametru. Możemy również dodać parametr --quite do opcji start-stop-daemon, jednak nie jest to działanie zalecane.

Jeżeli chcemy przejrzeć więcej przykładów funkcji start(), powinniśmy przeczytać kody źródłowe skryptów init dostępne w naszym katalogu /etc/init.d.

Pozostałe funkcje jakie można definiować to: stop() i restart(). Nie są one jednak konieczne! System init jest dostatecznie inteligentny aby poradzić sobie z ich brakiem dzięki start-stop-daemon.

Mimo że nie musimy tworzyć funkcji stop() poniżej znajdziemy przykład jak ją napisać:

stop() {
  ebegin "Stopping my_service"
  start-stop-daemon --stop --exec /path/to/my_service \
    --pidfile /path/to/my_pidfile
  eend $?
}

Jeżeli nasza usługa uruchamia inny skrypt (na przykład, bash, pythona, perl), a ten skrypt w czasie działania zmienia nazwę (na przykład foo.py na foo), będziemy musieli dodać parametr --name do start-stop-daemon. Musimy określić nazwę jaką będzie miał skrypt po zmianie. W przykładzie usługa uruchamia skrypt foo.py, który później zmienia nazwę ma foo:

start() {
  ebegin "Starting my_script"
  start-stop-daemon --start --exec /path/to/my_script \
    --pidfile /path/to/my_pidfile --name foo
  eend $?
}

start-stop-daemon posiada znakomity manual opisujący dokładnie wszelkie opcje:

$ man start-stop-daemon

Składnia skryptów startowych Gentoo opierają się na bashu przez co można w nich używać instrukcji zgodnych z bashem.

Dodawanie niestandardowych opcji

Jeśli chcemy aby init posiadał więcej opcji niż te dotychczas omówione, należy dodać nową opcję do zmiennej opts i stworzyć funkcję o takiej samej nazwie. Na przykład, aby utworzyć opcję o nazwie restartdelay:

opts="${opts} restartdelay"

restartdelay() {
  stop()
  sleep 3    # czekaj 3 sekundy przed ponownym uruchomieniem
  start()
}

Zmienne konfiguracyjne dla usług

Aby skrypt uruchamiający daną usługę sięgał do plików konfiguracyjnych, zlokalizowanych w /etc/conf.d nie trzeba praktycznie robić niczego. W chwili kiedy skrypt zostanie uruchomiony, przetworzone zostaną następujące pliki:

• /etc/conf.d/<nasz skrypt init>
• /etc/conf.d/basic
• /etc/rc.conf

Jeśli skrypt zawiera jakieś zależności wirtualne (np. takie jak net), pliki związane z tymi zależnościami (w tym przypadku /etc/conf.d/net) także zostaną przetworzone.

4.e. Zmiana zachowania poziomu działania

Kto może mieć z tego korzyści?

Wielu użytkowników laptopów zna taką sytuację: dopiero po powrocie do domu chcą uruchomić net.eth0, gdyż gdy są w drodze, to i tak nie ma sensu go uruchamiać, bo i tak nie ma dostępu do sieci. W Gentoo można dowolnie modyfikować zachowanie poziomów działania.

Możemy, na przykład utworzyć drugi "domyślny" poziom, który używa innych skryptów startowych. Można wybierać, którego poziomu działania chce się używać podczas startu systemu.

Używanie softlevela

Po pierwsze, trzeba utworzyć katalog poziomów działania dla swojego drugiego "domyślnego" poziomu działania. Jako przykład stworzymy katalog offline:

# mkdir /etc/runlevels/offline

Należy dodać potrzebne skrypty startowe do nowo utworzonego katalogu. Na przykład, jeżeli chcemy mieć dokładną kopię aktualnego domyślnego poziomu działania, wyłączając net.eth0:

(Kopiowanie wszystkich usług z domyślnego runlevela do runlevela offline
# cd /etc/runlevels/default
# for service in *; do rc-update add $service offline; done
(Usuwanie niechcianej usługi z runlevela offline
# rc-update del net.eth0 offline
(Wyświetlenie wszystkich aktywnych usług dla runlevela offline
# rc-update show offline
(Częściowe wyjście)
                    acpid | offline
               domainname | offline
                       local | offline
                 net.eth0 |

Nawet jeśli net.eth0 zostanie usunięte z poziomu uruchomieniowego offline, udev będzie próbował uruchomić urządzenia, które wykryje, a następnie uruchomi potrzebne usługi. Dlatego należy dodać każdą usługę sieciową, której nie chcemy startować (sposób ten działa również w przypadku, innych urządzeń wykrywanych przez udev), do pliku /etc/conf.d/rc, według podanego poniżej wzoru.

RC_COLDPLUG="yes"
(Następnie wpisujemy usługi, których nie chcemy uruchamiać automatycznie)
RC_PLUG_SERVICES="!net.eth0"

Teraz należy wyedytować pliki konfiguracyjne bootloadera i dodać wpis dla poziomu działania offline. Dla przykładu w /boot/grub/grub.conf:

title Gentoo Linux Tryb Offline
root (hd0,0)
kernel (hd0,0)/kernel-2.4.25 root=/dev/hda3 softlevel=offline

Teraz już jest wszystko ustawione. Jeżeli system zostanie uruchomiony i wybrana zostanie dodana przed chwilą pozycja, zamiast domyślnego poziomu działania będzie używany poziom offline.

Używanie bootlevela

Używanie bootlevela jest analogiczne do softlevela. Jedyną różnicą jest definiowanie drugiego "rozruchowego" poziomu uruchamiania zamiast drugiego "domyślnego" poziomu uruchamiania.

5. Zmienne środowiskowe

5.a. Zmienne środowiskowe

Czym są zmienne środowiskowe?

Zmienne środowiskowe to nazwa obiektów zawierających informacje, które używane są przez jeden lub wiele programów w systemie operacyjnym. Wielu użytkowników (zwłaszcza mających styczność z Linuksem od niedawna) traktuje je jako coś nie do ogarnięcia. Nic bardziej mylnego! Dzięki zmiennym środowiskowym zmiana konfiguracji jednego lub kilku programów jest banalnie prosta.

Przykłady ważniejszych zmiennych środowiskowych

Poniższa tabela przedstawia listę ważniejszych zmiennych używanych przez system Linux, wraz z krótkim opisem. Przykładowe ich wartości znajdują się pod tabelą.

Poniżej znajdują się przykładowe wartości omówionych zmiennych środowiskowych:

PATH="/bin:/usr/bin:/usr/local/bin:/opt/bin:/usr/games/bin"
ROOTPATH="/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin"
LDPATH="/lib:/usr/lib:/usr/local/lib:/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3"
MANPATH="/usr/share/man:/usr/local/share/man"
INFODIR="/usr/share/info:/usr/local/share/info"
PAGER="/usr/bin/less"
EDITOR="/usr/bin/vim"
KDEDIRS="/usr"
CONFIG_PROTECT="/usr/X11R6/lib/X11/xkb /opt/tomcat/conf \
                /usr/kde/3.1/share/config /usr/share/texmf/tex/generic/config/ \
                /usr/share/texmf/tex/platex/config/ /usr/share/config"
CONFIG_PROTECT_MASK="/etc/gconf"

5.b. Definiowanie zmiennych globalnych

Katalog /etc/env.d

Aby skupić w jednym miejscu definicje zmiennych, w Gentoo wprowadzono katalog /etc/env.d. W katalogu tym odnaleźć można pliki takie jak 00basic, 05gcc i inne. Zawierają one zmienne potrzebne do działania programów, których nazwy najczęściej są takie jak nazwy plików znajdujących się w katalogu /etc/env.d.

Na przykład po zainstalowaniu gcc, w katalogu /etc/env.d tworzony jest plik o nazwie 05gcc, który zawiera definicje następujących zmiennych:

PATH="/usr/i686-pc-linux-gnu/gcc-bin/3.2"
ROOTPATH="/usr/i686-pc-linux-gnu/gcc-bin/3.2"
MANPATH="/usr/share/gcc-data/i686-pc-linux-gnu/3.2/man"
INFOPATH="/usr/share/gcc-data/i686-pc-linux-gnu/3.2/info"
CC="gcc"
CXX="g++"
LDPATH="/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3"

W innych dystrybucjach trzeba by zmienić lub dodać definicje powyższych zmiennych systemowych do pliku /etc/profile lub w innym miejscu. W Gentoo jest to znacznie prostsze i nie wymaga w zasadzie ingerencji użytkownika.

W przypadku, kiedy gcc jest uaktualniane, uaktualniany jest także plik /etc/env.d/05gcc. Dzieje się to bez udziału użytkownika.

Rozwiązanie to przynosi korzyści nie tylko dla systemu Portage, ale także dla użytkownika. Sporadycznie użytkownik może być zapytany o to, jaką wartość ma mieć pewna zmienna środowiskowa. Może to mieć miejsce w przypadku zmiennej http_proxy. Zamiast zamiast ingerować w plik /etc/profile, można utworzyć plik (/etc/env.d/99local) i wpisać tam definicje swoich zmiennych. Na przykład:

http_proxy="proxy.server.com:8080"

Dzięki takiemu sposobowi definiowania zmiennych środowiskowych masz szybki wgląd na w te zmienne, które zdefiniowałeś samodzielnie.

Skrypt env-update

Kilka plików w katalogu /etc/env.d definiuje zmienną PATH. Nie jest to błędem. Kiedy wykonane zostanie env-update, to skrypt ten doda do siebie wszystkie definicje tej samej zmiennej, uaktualniając na koniec zmienne środowiskowe w systemie. Daje to możliwość dodawania własnych zmiennych środowiskowych bez obawy przed tym, że zmodyfikowana zostanie już istniejąca zmienna (pozbawiając ją dotychczasowej wartości).

Skrypt env-update dodaje wartości zmiennych w kolejności alfabetycznej. Tłumaczy to fakt dlaczego nazwy plików w katalogu /etc/env.d zaczynają się od dwóch cyfr.

         00basic        99kde-env       99local
     +-------------+----------------+-------------+
PATH="/bin:/usr/bin:/usr/kde/3.2/bin:/usr/local/bin"

Tylko wartości niektórych zmiennych są ze sobą łączone, należą do nich: KDEDIRS, PATH, LDPATH, MANPATH, INFODIR, INFOPATH, ROOTPATH, CONFIG_PROTECT, CONFIG_PROTECT_MASK, PRELINK_PATH i PRELINK_PATH_MASK. Dla wszystkich pozostałych zmiennych ważna jest ostatnia zdefiniowana wartość (pliki w kolejności alfabetycznej w katalogu /etc/env.d).

Uruchomienie skryptu env-update powoduje utworzenie zmiennych systemowych i umieszczenie ich w pliku /etc/profile.env (z którego korzysta /etc/profile). Skrypt ten pobiera także informacje z (opisanej wcześniej) zmiennej LDPATH i używa ich do utworzenia pliku /etc/ld.so.conf. Po wykonaniu tej czynności uruchamia polecenie ldconfig w celu odbudowania wspomnianego pliku /etc/ld.so.cache, który jest używany przez konsolidator.

Jeśli chcemy zaobserwować efekt, jaki przynosi wykonanie polecenia env-update, należy uruchomić następujące polecenia w celu uaktualnienia zmiennych środowiskowych. Użytkownicy mający już pierwszą instalację Gentoo za sobą pewnie pamiętają polecenie:

# env-update && source /etc/profile

5.c. Definiowanie zmiennych lokalnych

Zmienne użytkownika

Nie zawsze użytkownik chce aby zdefiniowane przez niego zmienne miały charakter globalny (były dostępne dla innych użytkowników w systemie). Na przykład może zechcieć dodać katalog /home/moj_uzytkownik/bin i katalog, w którym obecnie się znajduje do zmiennej PATH, lecz nie chce aby była ona dostępna dla pozostałych. Aby zdefiniować taką zmienną środowiskową lokalną, do pliku ~/.bashrc lub ~/.bash_profile należy dodać następującą linię:

Dwukropek na końcu zmiennej oznacza, że wejdzie do niej także katalog, w którym będzie przebywał użytkownik
PATH="${PATH}:/home/my_user/bin:"

Po wylogowaniu się i ponownym zalogowaniu, wartość zmiennej PATH będzie uaktualniona.

Zmienne bieżącej sesji

W niektórych przypadkach przydatna jest możliwość definiowania zmiennych, które używane są tylko w trakcie trwania bieżącej sesji. Na przykład może pojawić się potrzeba używania programów z katalogu tymczasowego, który nie jest ujęty standardowo w zmiennej PATH.

W tym przypadku można po prostu zdefiniować wartość tej zmiennej za pomocą polecenia export. Tak zdefiniowana zmienna będzie miała swoją wartość do momentu wylogowania się.

# export PATH="${PATH}:/home/my_user/tmp/usr/bin"

C. Praca z Portage

1. Pliki i katalogi

1.a. Pliki Portage

Dyrektywy konfiguracji

Domyślna konfiguracja Portage znajduje się w pliku /etc/make.globals. Gdy mu się przyjrzymy, możemy zauważyć, że Portage jest konfigurowane za pomocą zmiennych. Znaczenie poszczególnych zmiennych omówimy w dalszych częściach tego Podręcznika.

Portage ma również domyślne pliki konfiguracyjne wewnątrz wybranego profilu: /etc/make.profile/make.defaults, ponieważ większość dyrektyw konfiguracji zależy od architektury. Wybrany profil jest zdefiniowany przez dowiązanie symboliczne /etc/make.profile. Cała konfiguracja Portage znajduje się w pliku profilu oraz w plikach profili nadrzędnych. Więcej informacji o profilach i katalogu /etc/make.profile znajduje się w dalszych częściach tego Podręcznika.

Nie należy edytować plików make.globals ani make.defaults w celu zmiany jakiejkolwiek znajdującej się w nich zmiennej. Zamiast tego powinno się skorzystać z pliku /etc/make.conf, który jest pozycją nadrzędną nad wyżej wymienionymi plikami i jest jedynym odpowiednim miejscem do wprowadzania jakichkolwiek zmian do konfiguracji. Jeśli brak pomysłu co wpisać do tego pliku, warto zapoznać się z przykładowym plikiem /usr/share/portage/config/make.conf.example.

Istnieje również możliwość zdefiniowania zmiennej konfiguracyjnej Portage jako zmiennej środowiskowej, ale nie jest to zalecana metoda.

Informacje specyficzne dla profilu

Wspominaliśmy już o katalogu /etc/make.profile. Nie jest to de facto katalog, lecz symboliczne dowiązanie do katalogu profilu znajdującego się wewnątrz katalogu /usr/portage/profiles. Profile mogą znajdować się w dowolnym miejscu na dysku, wystarczy, że to dowiązanie wskazuje na prawidłowy katalog.

Każdy profil zawiera informacje specyficzne dla danej architektury. Należą do nich między innymi lista pakietów niezbędnych dla prawidłowego działania systemu oraz lista pakietów niedziałających (bądź zamaskowanych) na danym systemie.

Konfiguracja specyficzna dla użytkownika

Aby zmienić związane z instalacją pakietów zachowanie Portage, należy udać się do katalogu /etc/portage. Polecamy wpisywanie tam całej własnej konfiguracji, nalegamy też na rezygnowanie z konfigurowania Portage przez zewnętrzne zmienne środowiskowe.

Wewnątrz /etc/portage można stworzyć następujące pliki:

• package.mask, w którym znajduje się lista pakietów, których nie chcemy instalować
• package.unmask, w którym znajduje się lista pakietów, które mają być instalowane wbrew zaleceniom deweloperów
• package.keywords, w którym znajduje się lista pakietów, które zamierza się zainstalować pomimo faktu, że nie są do końca kompatybilne z danym systemem bądź architekturą
• package.use, w którym znajduje się lista flag USE, których chce się używać dla określonych pakietów, a które różnią się od tych ustawionych globalnie w systemie

To wcale nie muszą być pliki. Mogą to być również katalogi zawierające osobne pliki dla każdego pakietu. Więcej informacji o katalogu /etc/portage oraz pełna lista plików, które można tam stworzyć, znajduje się w manualu Portage:

$ man portage

Zmiana lokalizacji plików i katalogów należących do Portage

Omówione powyżej pliki zawsze muszą znajdować się w tym samym, określonym miejscu, gdyż tylko tam Portage będzie ich szukało. Można jednak zmienić lokalizację innych katalogów używanych przez system, takich jak na przykład miejsce zapisywania kodu źródłowego, katalog, w którym budowane są programy, czy miejsce, w którym znajduje się drzewo Portage.

Ścieżki do powyższych miejsc są doskonale znane wszystkim użytkownikom Gentoo. Jeśli jednak z jakichś względów zamierza się je zmienić można to zrobić poprzez plik /etc/make.conf. W pozostałej części tego rozdziału omówimy wszystkie specjalne lokalizacje w jakich działa Portage oraz sposoby ich zmieniania.

Wszystkie zawarte w tym dokumencie informacje można uzyskać czytając manuale Portage i make.conf.

$ man portage
$ man make.conf

1.b. Zapisywanie plików

Drzewo Portage

Domyślnie drzewo Portage znajduje się w katalogu /usr/portage, który definiowany jest przez zmienną PORTDIR. Po zmianie wartości tej zmiennej należy pamiętać również o wprowadzeniu odpowiednich zmian w /etc/make.profile.

Jeśli zmodyfikuje się zmienną PORTDIR, należy poprawić też zmienne PKGDIR, DISTDIR i RPMDIR, gdyż programy nie zauważą zmiany PORTDIR i akcje wykorzystujące te zmienne będą dalej wykonywane wewnątrz dawnego miejsca rezydowania drzewa Portage.

Prekompilowane pakiety

Domyślnie Portage nie korzysta z prekompilowanych pakietów, posiada jednak wsparcie dla nich i istnieje możliwość korzystania z nich w razie potrzeby. Jeśli zażądamy od Portage zbudowania takiej paczki, trafi ona do /usr/portage/packages. Ścieżka ta przechowywana jest w zmiennej PKGDIR.

Kod źródłowy

Domyślnie, pobrany kod źródłowy instalowanych aplikacji jest przechowywany wewnątrz /usr/portage/distfiles. Tę lokalizację określa zmienna DISTDIR.

Baza Portage

Lista pakietów zainstalowanych w systemie znajduje się w pliku /var/db/pkg. Pod żadnym pozorem nie należy zmieniać ręcznie jego zawartości. Może to poważnie uszkodzić Portage.

Cache Portage

Cache Portage (informacje o zmianach w plikach, virtualach, drzewie zależności itp.) znajduje się w katalogu /var/cache/edb. Katalog ten można wyczyścić tylko wtedy, gdy nie jest uruchomiona żadna związana z pracą z Portage aplikacja.

1.c. Budowanie programów

Tymczasowe pliki Portage

Tymczasowe pliki Portage zapisywane są domyślnie w katalogu /var/tmp, do którego ścieżkę przechowuje zmienna PORTAGE_TMPDIR.

Zmiana PORTAGE_TMPDIR powinna nieść ze sobą zmianę szeregu innych zmiennych, które przechowują ścieżki do katalogów wewnątrz starej lokalizacji katalogu tymczasowego. Spowodowane jest to sposobem zarządzania zmiennymi przez Portage.

Tworzenie katalogów

Tymczasowe, osobne dla każdego budowanego pakietu katalogi powstają w /var/tmp/portage. Miejsce to zapisane jest w zmiennej BUILD_PREFIX.

Lokalizacja systemu plików

Domyślnie Portage instaluje pakiety w bieżącym systemie plików (/), można jednak to zmienić ustawiając zmienną środowiskową ROOT. Przydaje się to, gdy chcemy stworzyć nowe obrazy systemu.

1.d. Logowanie zdarzeń

Logowanie Ebuild

Portage może tworzyć osobne logi dla każdego ebuildu tylko wtedy, gdy zmienna PORT_LOGDIR wskazuje na katalog, do którego grupa portage (z której prawami uruchamiane są wszystkie procesy) ma prawa zapisu. Domyślnie zmienna ta nie jest ustawiona. Jeżeli nie ustawimy tej zmiennej, nie otrzymamy żadnych logów kompilacji z nowym systemem logowania, ale mimo to możemy otrzymać logi z nowego elog. Jeżeli jednak ustawimy tę zmienną, będziemy otrzymywać logi kompilacji oraz wszystkie inne zapisane przez elog, w sposób w jaki zostało to opisane poniżej.

Obsługa logowania w Portage odbywa się poprzez program elog:

• PORTAGE_ELOG_CLASSES: Zmienna ta służy do ustawiania jakiego typu wiadomości mają być logowane. Wartości jakich możemy użyć to info, warn, error, log oraz qa. Do rozdzielenia kombinacji kilku wartości używamy spacji.
  • info: Zapisuje wiadomości "einfo" wyświetlane przez ebuild
  • warn: Zapisuje wiadomości "ewarn" wyświetlane przez ebuild
  • error: Zapisuje wiadomości "eerror" wyświetlane przez ebuild
  • log: Zapisuje wiadomości "elog" wyświetlane przez ebuild
  • qa: Zapisuje wiadomości "qa" wyświetlane przez ebuild
• PORTAGE_ELOG_SYSTEM: W zmiennej tej ustawiamy moduł(y), które posłużą do przetworzenia wiadomości z logów. Jeżeli nie ustawimy żadnej zmiennej, logowanie zostanie wyłączone. Wartości jakich możemy użyć to save, custom, syslog, mail, save_summary i mail_summary. Musimy wybrać przynajmniej jeden moduł, aby być w stanie korzystać z elog. Jeśli chcemy wybrać więcej, rozdzielamy je spacją.
  • save: Zapisuje jeden plik log na pakiet w pliku $PORT_LOGDIR/elog lub /var/log/portage/elog jeśli nie mamy zdefiniowanej zmiennej $PORT_LOGDIR.
  • custom: Przekazuje wszystkie komunikaty do zdefiniowanego przez użytkownika polecenia podanego w zmiennej $PORTAGE_ELOG_COMMAND. Więcej informacji na ten temat zostanie przedstawione później.
  • syslog: Wysyła wszystkie komunikaty do zainstalowanego systemu logującego.
  • mail: Przekazuje wszystkie komunikaty do zdefiniowanego przez użytkownika w zmiennej $PORTAGE_ELOG_MAILURI serwera poczty elektronicznej. Więcej informacji na ten temat zostanie przedstawiona później. Funkcja ta wymaga zainstalowania >=portage-2.1.1.
  • save_summary: Podobne do save ale dodaje wszystkie informacje do $PORT_LOGDIR/elog/summary.log i /var/log/portage/elog/summary.log (do jednego pliku zamiast wielu)jeśli zmienna $PORT_LOGDIR nie jest zdefiniowana.
  • mail_summary: Podobne do mail, tylko wysyła wszystkie komunikaty w jednym mailu zamiast wielu.
• PORTAGE_ELOG_COMMAND: Zmienna ta jest używana jedynie w przypadku gdy aktywny jest moduł custom. Ustawiamy w niej polecenie, za pomocą którego przetwarzane będą wiadomości logów. Należy zauważyć, że możemy tutaj użyć dwóch zmiennych: ${PACKAGE}, która podaje nam nazwę pakietu oraz wersję, natomiast ${LOGFILE} zawiera ścieżkę do pliku log. Poniżej przedstawiono wzór użycia tych zmiennych:
  • PORTAGE_ELOG_COMMAND="/path/to/logger -p '\${PACKAGE}' -f '\${LOGFILE}'"
• PORTAGE_ELOG_MAILURI: Zawiera ustawienia dla modułu mail takie jak adres, użytkownik, hasło, serwer poczty czy numer portu. Domyślnym ustawieniem jest "root@localhost localhost".
• Poniżej znajduje się przykład dla serwera smtp, który wymaga nazwy użytkownika oraz hasła do autoryzacji na specyficznym porcie (domyślnym portem jest 25):
  • PORTAGE_ELOG_MAILURI="user@some.domain username:password@smtp.some.domain:995"
• PORTAGE_ELOG_MAILFROM: Pozwala na ustawienie adresu "from" we wiadomościach elektronicznych z logami. Domyślnie ta wartość nie jest ustawiana.
• PORTAGE_ELOG_MAILSUBJECT: Pozwala na tworzenie tematu we wiadomościach elektronicznych z logami. Dodatkowo możemy użyć dwóch innych zmiennych: ${PACKAGE}, która wyświetla nazwę oraz wersję pakietu, natomiast wartość przechowywana w zmiennej ${HOST} jest nazwą domeny, na której uruchomione jest Portage.
• Poniżej znajduje się przykładowe użycie tej zmiennej:
  • PORTAGE_ELOG_MAILSUBJECT="package \${PACKAGE} was merged on \${HOST} with some messages"

2. Konfigurowanie Portage

2.a. Konfiguracja Portage

Portage konfiguruje się poprzez zmienne znajdujące się na ogół w pliku /etc/make.conf. Dla uzyskania pełnych informacji na temat tego pliku, zalecamy przeczytanie jego mana:

$ man make.conf

2.b. Opcje budowania programów

Opcje kompilacji

W trakcie budowania programu, Portage przekazuje kompilatorowi następujące zmienne:

• Zmienna CFLAGS & CXXFLAGS definiują żądane flagi dla kompilacji kodu C i C++
• Zmienna CHOST zawiera informację o hoście na którym budowany jest program
• Zmienna MAKEOPTS jest przekazywana do polecenia make i jej wartość jest najczęściej ilością równoległych zadań podczas kompilacji. Więcej informacji o make można znaleźć na jego stronie man.

Również flagi USE są używane podczas budowania programów przez Portage, ale zostały już szczegółowo omówione w poprzednich rozdziałach, nie ma zatem potrzeby omawiania ich tutaj po raz kolejny.

Opcje instalacji za pomocą emerge

Kiedy Portage instaluje nowszą wersję danego programu, usuwa przestarzałe pliki z systemu. Usunięcie to jest poprzedzone odpowiednim komunikatem, a użytkownik ma 5 sekund na przerwanie całej operacji i pozostanie przy aktualnej wersji programu. Owe 5 sekund definiowanie jest zmienną CLEAN_DELAY.

Wszelkie opcje, które będą wykonywane za każdym razem podczas wykonania polecenia emerge, możemy przekazać za pomocą zmiennej EMERGE_DEFAULT_OPTS. Takimi opcjami mogą być np. --ask, --verbose, --tree itd.

2.c. Ochrona plików konfiguracyjnych

Chronione przez Portage katalogi

Jeśli plik nie znajduje się w lokacji chronionej przez Portage, to przy instalowaniu nowszej wersji programu, do którego należy, zostanie po prostu nadpisany. Te chronione katalogi również możemy skonfigurować, są one przechowywane w zmiennej CONFIG_PROTECT.

Plik znajdujący się w takiej chronionej lokacji nie zostanie nadpisany, Portage zapisze nowy plik pod inną nazwą i poinformuje użytkownika o pojawieniu się nowszej wersji.

Więcej informacji na temat aktualnego ustawienia zmiennej CONFIG_PROTECT można uzyskać po wpisaniu polecenia emerge --info:

$ emerge --info | grep 'CONFIG_PROTECT='

Więcej informacji na temat ochrony plików konfiguracyjnych w Portage znajduje się na stronie man emerge.

$ man emerge

Odsłanianie chronionych katalogów

Aby odsłonić konkretny chroniony katalog i umożliwić w nim bezpośrednie nadpisywanie plików, dodajemy go do zmiennej CONFIG_PROTECT_MASK.

2.d. Opcje pobierania

Serwery

Jeśli potrzebne są jakieś pliki lub informacje, które nie znajdują się na dysku, Portage będzie zmuszone pobrać je z Internetu. Miejsca, w których program będzie ich szukał definiujemy w następujących zmiennych:

• GENTOO_MIRRORS zawiera adresy serwerów lustrzanych z kodami źródłowymi (distfiles) programów z Portage.
• PORTAGE_BINHOST zawiera adresy serwerów z prekompilowanymi pakietami.

Kolejna zmienna zawiera adres serwera rsync, z którego pobierane będą aktualizacje drzewa Portage:

• Zmienna SYNC zawiera nazwę serwera, z którego Portage będzie pobierało aktualizacje drzewa Portage.

Zmienne GENTOO_MIRRORS i SYNC mogą zostać ustawione przy pomocy programu mirrorselect. Przedtem należy go zainstalować, robimy to poleceniem emerge mirrorselect. Więcej informacji o programie uzyskamy wpisując:

# mirrorselect --help

Jeśli dodatkowo chcemy korzystać z serwera proxy, używamy do tego zmiennych http_proxy, ftp_proxy i RSYNC_PROXY.

Komendy pobierania

Do pobierania kodów źródłowych Portage domyślnie używa programu wget. Możemy to zmienić poprzez zmienną FETCHCOMMAND.

Portage jest w stanie wznowić przerwany transfer. Używa w takim przypadku jednej z możliwości programu wget. Jeśli chcemy to zmienić, wystarczy wyedytować zmienną RESUMECOMMAND.

Należy upewnić się, że wybrane przez nas nowe polecenia FETCHCOMMAND i RESUMECOMMAND umieszczają kody źródłowe w odpowiednich miejscach. Wewnątrz zmiennych powinno się umieścić \${URI} i \${DISTDIR} odpowiednie dla lokacji kodów źródłowych i distfiles.

Można również wybrać osobne polecenia pobierania w zależności od protokołu, który akurat jest używany. Służą do tego zmienne: FETCHCOMMAND_FTP, RESUMECOMMAND_HTTP, RESUMECOMMAND_FTP, itd.

Ustawienia rsync

Nie można wprawdzie zastąpić innym polecenia rsync, używanego do aktualizowania drzewa Portage, ale mamy za to do dyspozycji kilka zmiennych, dzięki którym można dostosować niektóre parametry jego działania.

• Zmienna PORTAGE_RSYNC_OPTS ustawia kilka domyślnych zmiennych używanych podczas aktualizacji. Każda z nich oddzielona jest spacją. Nie należy zmieniać wartości tej zmiennej, chyba że dokładnie wiemy co robimy. Dodatkowo należy mieć na uwadze, że istnieją takie opcję, które zawsze będą używane, nawet w przypadku gdy zmienna ta będzie pusta.
• Zmienna PORTAGE_RSYNC_EXTRA_OPTS może być użyta do ustawienia dodatkowych opcji podczas aktualizacji drzewa. Każda z nich powinna być oddzielona spacją od poprzedniej.
  • --timeout=<liczba>: Definiuje liczbę sekund po jakich bezczynne połączenie z serwerem zostanie uznane za martwe. Domyślną wartością jest 180, jednak użytkownicy korzystający z modemów lub osoby z wolnymi komputerami powinny zwiększyć tę wartość do 300 lub więcej.
  • --exclude-from=/etc/portage/rsync_excludes: Wskazuje na plik, w którym znajduje się lista pakietów i/lub kategorii, które powinny zostać zignorowane podczas procesu aktualizacji drzewa. W tym przypadku jest to plik /etc/portage/rsync_excludes. Aby zapoznać się ze składnią tego pliku, należy przeczytać rozdział Mieszanie gałęzi Portage.
  • --quiet: Zmiejsza ilość wysyłanych komunikatów na ekran
  • --verbose: Wyświetla kompletną listę plików
  • --progress: Wyświetla pasek postępu dla każdego pliku
• W zmiennej PORTAGE_RSYNC_RETRIES definiujemy ile prób połaczenia się z serwerem lustrzanym umieszczonym w zmiennej SYNC powinien podejmować rsync. Domyślną wartością jest 3.

Aby dowiedzieć się więcej o opcjach, należy zapoznać się z manualem, wywoływanym poleceniem man rsync.

2.e. Konfiguracja Gentoo

Wybór gałęzi

Wyboru gałęzi dokonujemy poprzez zmianę zmiennej ACCEPT_KEYWORDS. Domyślnie jest to stabilna gałąź naszej architektury, więcej informacji o innych gałęziach znaleźć można w dalszych rozdziałach Podręcznika.

Portage Features

Przy pomocy zmiennej FEATURES aktywujemy rozmaite dodatkowe możliwości Portage, które szerzej są omawiane w poświęconym im rozdziale Możliwości Portage.

2.f. Zachowanie Portage

Zarządzanie zasobami

Zmienna PORTAGE_NICENESS służy do zwiększania lub zmniejszania wartości nice z jaką działa Portage. Wartość ze zmiennej PORTAGE_NICENESS jest dodawana do aktualnej wartości nice.

Więcej informacji o wartościach nice znajduje się w manie programu nice:

$ man nice

Konfiguracja danych wyjściowych

Zmienna NOCOLOR, domyślnie ustawiona na "false" (fałsz), przestawiona na "true" (prawda), zakaże Portage kolorowania danych wyjściowych.

3. Mieszanie różnych gałęzi Portage

3.a. Gałęzie Portage

Gałąź stabilna

Zmienna ACCEPT_KEYWORDS definiuje której gałęzi Portage zamierzamy używać w danym systemie. Domyślnie jest to stabilna gałąź dla naszej architektury, np. x86.

Zwykle, zwłaszcza początkującym użytkownikom, zalecamy pozostanie przy gałęzi stabilnej. Natomiast użytkowników, którym nie zależy na pełnej stabilności lub którzy chcą nam pomóc zgłaszając błędy na stronie http://bugs.gentoo.org, zapraszamy do dalszej lektury.

Gałąź testowa

Najnowsze wersje wszystkich programów znajdują się w tzw. testowej części drzewa Portage. Wszystko co należy zrobić, aby przejść na tą wersję, to wpisanie ~ (tyldy) przed kodem architektury.

Jeżeli deweloper sądzi, że pakiet powinien działać w porządku, ale nie został jeszcze dokładnie przetestowany, zostaje on dodany gałęzi testowej. Każdy odnaleziony w takim pakiecie błąd należy zgłosić deweloperom Gentoo.

Odmaskowanie całej gałęzi testowej może sprawić, że system stanie się niestabilny, nie wszystkie pakiety będą się prawidłowo instalować (na przykład w związku z brakującymi lub zepsutymi zależnościami), aktualizacje będą musiały odbywać się częściej niż zwykle, a niektóre pakiety po prostu będą zepsute. Rozwiązanie to jest przeznaczone dla bardziej doświadczonych użytkowników.

Na przykład, aby wybrać testową gałąź dla architektury x86, wystarczy wyedytować plik /etc/make.conf i wstawić tam:

ACCEPT_KEYWORDS="~x86"

Gdy spróbujemy w tym momencie uaktualnić system, zorientujemy się, że Portage chce przeinstalować naprawdę wiele programów. Należy również pamiętać, że jeśli już uaktualnimy system do wersji testowej, nie będzie łatwej drogi powrotnej do oficjalnej wersji stabilnej.

3.b. Mieszanie gałęzi stabilnej i testowej

Plik package.keywords

Można nakazać Portage, aby używało wersji testowych tylko niektórych pakietów. Nie ma potrzeby przestawiania całego systemu w tryb testowy dla jednego lub nawet kilku programów. W tym celu wystarczy dodać kategorię i nazwę wybranego pakietu do pliku /etc/portage/package.keywords. Można również utworzyć katalog o takiej samej nazwie i umieścić tam pliki z wpisanymi do nich pakietami. Na przykład, aby Portage używało wersji niestabilnej programu gnumeric:

app-office/gnumeric ~x86

Testowanie określonej wersji programu

Czasem zdarza się tak, że chcemy zainstalować konkretną wersję danego programu, najczęściej z gałęzi niestabilnej i za żadne skarby nie chcemy, aby przy uaktualnieniach Portage instalowało, obojętnie, starszą lub nowszą wersję tego programu. Wtedy bardzo pomocna okazuje się możliwość wymuszenia na Portage używania tej właśnie wersji, a robimy to poprzez dodanie znaku = na początek linii danego programu w pliku package.keywords. Możemy też używać innych znaków matematycznych dla określenia przedziału, do którego należą żądane przez nas wersje - są to operatory <=, <, > i >=.

W każdym przypadku, gdy chcemy dodać informację o wersji, trzeba użyć odpowiedniego operatora. Jeśli nie chcemy dodawać żadnych informacji o pożądanych wersjach, po prostu nie dodawajmy żadnych operatorów.

Na przykład nakażemy Portage używać wyłącznie gnumeric-1.2.13:

=app-office/gnumeric-1.2.13

3.c. Instalacja zamaskowanych programów

Plik package.unmask

Deweloperzy Gentoo nie będą pomagać przy problemach w korzystaniu z pakietów odmaskowanych za pomocą tego pliku. Prosimy o zachowanie ostrożności przy wprowadzaniu tych zmian. Nikt nie będzie odpowiadał na pytania związane z programami uaktywnionymi za pomocą plików package.unmask i package.mask.

Jeśli zechcemy zainstalować program z jakichś względów zamaskowany przez deweloperów Gentoo, powinniśmy najpierw zapoznać się z powodem ukrycia danej jego wersji, znajdującym się domyślnie w pliku /usr/portage/profiles, a następnie dodać dokładnie taką samą linię do pliku /etc/portage/package.unmask (lub pliku w tym katalogu, jeśli jest on katalogiem o takiej nazwie).

Na przykład jeśli =net-mail/hotwayd-0.8 jest zamaskowane, można je odmaskować dodając taką linię do package.unmask:

=net-mail/hotwayd-0.8

Plik package.mask

Jeśli z jakichś powodów nie życzymy sobie, aby Portage uaktualniało program do jakiejś określonej wersji, możemy ją zamaskować dopisując odpowiednią linię do pliku /etc/portage/package.mask (lub w tym pliku w katalogu).

Na przykład jeśli nie chcemy, aby Portage instalowało nowsze źródła kernela niż gentoo-sources-2.6.8.1 dodajemy taką linię do lokalizacji package.mask:

>sys-kernel/gentoo-sources-2.6.8.1

4. Dodatkowe narzędzia Portage

4.a. dispatch-conf

dispatch-conf jest narzędziem, które służy do zastępowania plików konfiguracyjnych plikami ._cfg0000_<nazwa>, umożliwia ich interaktywną edycję oraz pozwala automatycznie dokonać drobnych zmian w tych plikach. Pliki ._cfg0000_<nazwa> są generowane przez Portage, gdy chce nadpisać jakiś plik w katalogu chronionym zmienną CONFIG_PROTECT.

Dzięki dispatch-conf można nadpisywać zmiany w plikach konfiguracyjnych zachowując jednocześnie na wszelki wypadek poprzednie wersje tych plików. dispatch-conf będzie przechowywał wszystkie zmiany jako pliki patch lub korzystając z systemu rewizji RCS. Dzięki temu w razie gdy popełni się błąd podczas aktualizacji pliku konfiguracyjnego, można łatwo wrócić do poprzedniej jego wersji.

dispatch-conf po uruchomieniu zapyta czy pozostawić pliki konfiguracyjne bez zmian, nadpisać je nowszymi wersjami, wyświetlić różnice lub uruchomić interaktywną aktualizację plików. Ponadto posiada wiele innych ciekawych funkcji:

• Automatycznie zamienia stare pliki nowymi jeśli zmiany w nich dotyczą jedynie linii oznaczonych jako komentarze
• Automatycznie zamienia pliki, gdy zmiany dotyczą jedynie pustego miejsca (spacje, tabulatory, puste wiersze itp.)

Pracę z programem dispatch-conf należy rozpocząć od utworzenia katalogu, na który wskazuje zmienna archive-dir znajdująca się w pliku /etc/dispatch-conf.conf.

# dispatch-conf

Po uruchomieniu dispatch-conf wyświetli kolejno opcje dla każdego aktualizowanego pliku konfiguracyjnego. Po naciśnięciu klawisza u stary plik zostanie nadpisany nowym, a program przejdzie do następnego pliku. Klawisz z usunie aktualizację pozostawiając stary plik bez zmian oraz przejdzie do następnego pliku. Po wybraniu opcji dla wszystkich plików konfiguracyjnych program dispatch-conf zakończy pracę. W każdej chwili można skorzystać z klawisza q, aby zakończyć pracę programu.

Więcej informacji o programie dostarczy man dispatch-conf. Można tam między innymi przeczytać o tym jak interaktywnie wprowadzać zmiany w plikach konfiguracyjnych, ręcznie edytować nowe pliki konfiguracyjne czy wyświetlać różnice między nimi.

$ man dispatch-conf

4.b. etc-update

Alternatywą dla dispatch-conf jest program o nazwie etc-update. Nie jest tak prosty w obsłudze, nie posiada też wielu funkcji swojego odpowiednika. Posiada jednak możliwość automatycznego dodawania drobnych zmian oraz opcję interaktywnej aktualizacji plików konfiguracyjnych.

Główną wadą etc-update jest to, że nie przechowuje dawnych wersji nadpisanych plików konfiguracyjnych. Po zaktualizowaniu pliki stara wersja jest stracona na zawsze. W związku z tym praca z etc-update jest znacznie bardziej ryzykowna niż praca z dispatch-conf.

# etc-update

Program automatycznie dokona drobnych zmian w plikach konfiguracyjnych, a potem pokaże listę plików chronionych i poprosi o decyzję w ich sprawie. Na dole pojawi się poniższa lista dostępnych opcji wraz z ich krótkim opisem:

Please select a file to
 edit by entering the corresponding number.
              (-1 to exit)
              (-3 to auto merge all remaining files)
              (-5 to auto-merge AND not use 'mv -i'):

Po wybraniu -1 etc-update zakończy działanie. Warto pamiętać, że jest to jedynie polecenie zakończenia programu i nie cofnie żadnych dokonanych wcześniej zmian. Po wybraniu -3 lub -5 wszystkie znajdujące się na liście pliki konfiguracyjne zostaną nadpisane nowszymi wersjami. Dobrym pomysłem jest zaznaczenie plików, których nie chcemy nadpisywać automatycznie. Dokonuje się tego po prostu wpisując liczbę znajdującą się na lewo od danego pliku.

Np. wybieramy sobie plik konfiguracyjny /etc/pear.conf i po wybraniu jego indeksu widzimy coś takiego:

Beginning of differences between /etc/pear.conf and /etc/._cfg0000_pear.conf
[...]
End of differences between /etc/pear.conf and /etc/._cfg0000_pear.conf
1) Replace original with update
2) Delete update, keeping original as is
3) Interactively merge original with update
4) Show differences again

W ten sposób można łatwo uzyskać informacje o różnicach pomiędzy oboma plikami. Jeśli jesteśmy pewni, że zastąpienie starego pliku nowym to dobry pomysł, naciskamy 1. Może zdarzyć się też tak, że nie będziemy chcieli nowego pliku. Wtedy naciskamy 2 i zapominamy o tym, że była nowsza wersja :) Jeśli chcemy bliżej zająć się tym plikiem (tzw. metoda interaktywna) wybieramy 3.

Nie ma sensu rozpisywać się na temat trzeciej metody - ograniczymy się jedynie do podania możliwych w tym trybie do wybrania komend. Generalnie wygląda to tak, że program pokazuje dwie linie - oryginalną i proponowaną i czeka aż wpiszemy jeden z ciągów znaków:

ed:     Edycja i użycie obu wersji, każdej z nagłówkiem.
eb:     Edycja i użycie obu wersji.
el:     Edycja i użycie wersji po lewej.
er:     Edycja i użycie wersji po prawej.
e:      Edycja nowej wersji.
l:      Użycie wersji po lewej.
r:      Użycie wersji po prawej.
s:      Dołączenie wspólnych linii bez informowania o tym.
v:      Dołączenie wspólnych linii z podaniem informacji.
q:      Zakończenie.

Kiedy już skończymy uaktualniać te najważniejsze pliki, pozostałe możemy zamienić w trybie automatycznym. etc-update wyłączy się kiedy już nie będzie miało żadnych plików do uaktualnienia.

4.c. Quickpkg

Program quickpkg umożliwia spakowanie zainstalowanego programu do paczki, z której następnie możemy go bezproblemowo i błyskawicznie odtworzyć. Uruchamianie quickpkg jest proste: po prostu podajemy nazwy programów do spakowania jako parametry i wciskamy enter.

Na przykład wybieramy do spakowania: curl, arts i procps:

# quickpkg curl arts procps

Po zakończeniu całego procesu gotowe paczki znajdziemy w katalogu $PKGDIR/All (domyślnie /usr/portage/packages/All). Ponadto w $PKGDIR/<kategoria> będą się znajdowały dowiązania symboliczne do wszystkich zbudowanych przez nas paczek.

5. Pozostawiając oficjalne drzewo Portage

5.a. Używanie podzestawów drzewa Portage

Pomijanie kategorii/pakietów

Możemy selektywnie uaktualniać poszczególne kategorie/pakiety oraz zignorować pozostałe kategorie/pakiety. Osiągamy to zmuszając rsync do pominięcia kategorii/pakietów podczas wykonywania emerge --sync.

W pliku /etc/make.conf można skonfigurować zmienną --exclude-from, która powinna zawierać ścieżkę do pliku, w którym znajdują się informacje o kategoriach i pakietach, które mają być pomijane przy aktualizowaniu drzewa.

PORTAGE_RSYNC_EXTRA_OPTS="--exclude-from=/etc/portage/rsync_excludes"

games-*/*

Należy zwrócić uwagę, że może to doprowadzić do problemów z zależnościami, gdyż nowe, niepominięte pakiety mogą zależeć od nowych lecz pominiętych pakietów.

5.b. Dodawanie nieoficjalnych ebuildów

Definiowanie katalogu-nakładki na Portage

Można zmusić Portage, aby używało ebuildów, które nie są dostępne w oficjalnym drzewie. W tym celu najpierw należy utworzyć nowy katalog (na przykład /usr/local/portage), w którym będą znajdować się dodatkowe ebuildy, przy czym należy pamiętać o zachowaniu struktury katalogów takiej jak w oficjalnym drzewie Portage.

Następnie trzeba zdefiniować zmienną PORTDIR_OVERLAY w pliku /etc/make.conf, aby wskazywała na właśnie utworzony katalog. Możliwe jest teraz użycie tych ebuildów bez obawy, że zostaną usunięte lub nadpisane przy następnym uruchomieniu emerge --sync.

Praca z kilkoma nakładkami (ang. overlay)

Zaawansowani użytkownicy często chcą zdefiniować kilka nakładek na drzewo Portage, gdyż dzięki temu mogą w łatwy sposób testować programy, które jeszcze nie znalazły się oficjalnym drzewie lub po prostu używać programów, do których ebuildów w nim nie ma i nie będzie. Pakiet app-portage/gentoolkit-dev zawiera program gensync, który pozwala na łatwą aktualizację tych nakładek z repozytoriów ich projektów.

gensync daje możliwość aktualizacji wszystkich nakładek za jednym razem lub wybranie tylko kilku z nich. Każda nakładka powinna posiadać plik .syncsource w katalogu /etc/gensync/, w którym jest podana lokalizacja repozytorium, nazwa, ID, itp.

Przypuśćmy, że posiadamy dwa repozytoria, java (dla ebuildów java) oraz entapps (dla aplikacji rozwijanych w warunkach domowych, jednak na potrzeby przedsiębiorstw). Ich aktualizację możemy przeprowadzić w następujący sposób:

# gensync java entapps

5.c. Programy, którymi nie zarządza Portage

Informowanie Portage a programach, którymi ma nie zarządzać

Bardzo często chcemy skonfigurować, zainstalować i zarządzać programami samodzielnie, bez pomocy Portage, nawet jeśli Portage zawiera te programy. Najczęściej są to źródła jądra i sterowniki nvidii. Można skonfigurować Portage, aby myślało, że dany pakiet jest zainstalowany w systemie. Ten proces nazywany jest wstrzykiwaniem i jest obsługiwany przez Portage dzięki plikowi /etc/portage/profile/package.provided.

Na przykład, jeśli chcemy poinformować Portage, że ręcznie zainstalowaliśmy gentoo-sources-2.6.11.6, dodajemy następującą linijkę do /etc/portage/profile/package.provided:

sys-kernel/gentoo-sources-2.6.11.6

D. Konfiguracja sieci w Gentoo

1. Wprowadzenie

1.a. Początek

Przed rozpoczęciem konfiguracji karty sieciowej, należy wspomnieć o systemowym RC w Gentoo. Jest to realizowane poprzez stworzenie linku symbolicznego z net.lo do net.eth0 w /etc/init.d.

# cd /etc/init.d
# ln -s net.lo net.eth0

System RC w Gentoo już wie o tym interfejsie. Musi również wiedzieć jak skonfigurować nowy interfejs. Wszystkie interfejsy sieciowe są konfigurowane w /etc/conf.d/net. Poniżej znajduje się przykładowa konfiguracja dla DHCP oraz statycznych adresów.

# Dla DHCP
config_eth0=( "dhcp" )

# Dla statycznego IP używając notacji CIDR
config_eth0=( "192.168.0.7/24" )
routes_eth0=( "default via 192.168.0.1" )

# Dla statycznego IP używając notacji netmaski
config_eth0=( "192.168.0.7 netmask 255.255.255.0" )
routes_eth0=( "default via 192.168.0.1" )

Teraz, gdy interfejs został już skonfigurowany, można go uruchomić i zatrzymać używając poleceń znajdujących się poniżej.

# /etc/init.d/net.eth0 start
# /etc/init.d/net.eth0 stop

Teraz, gdy już udało się uruchomić oraz zatrzymać urządzenie sieciowe, należałoby dodać je do domyślnych skryptów startowych Gentoo. Poniżej opisane jest jak tego dokonać. Ostatnie polecenie "rc" powoduje uruchomienie tych skryptów w danym poziomie uruchomieniowym, które jeszcze nie zostały jeszcze uruchomione.

# rc-update add net.eth0 default
# rc

2. Zaawansowana konfiguracja

2.a. Zaawansowana konfiguracja

Zmienna config_eth0 jest sercem konfiguracji interfejsu sieciowego. Jest to lista poleceń konfiguracyjnych wysokiego poziomu (w tym przypadku urządzenia eth0). Każde polecenie z listy poleceń jest uruchamiane w sposób sekwencyjny. Urządzenie uruchomi się jeżeli co najmniej jedno polecenie zostanie poprawnie uruchomione.

Poniżej znajduje się lista wbudowanych poleceń.

Jeżeli jakieś polecenie się nie wykona, można zdefiniować takie które będzie wykonywane zamiennie. Polecenie to musi pasować dokładnie do struktury konfiguracji głównej.

Można połączyć te polecenia razem. Poniżej znajduje się kilka przykładów.

(Dodawanie trzech adresów IPv4)
config_eth0=(
   "192.168.0.2/24"
   "192.168.0.3/24"
   "192.168.0.4/24"
)

(Dodawanie adresu IPv4 oraz dwóch adresów IPv6)
config_eth0=(
   "192.168.0.2/24"
   "4321:0:1:2:3:4:567:89ab"
   "4321:0:1:2:3:4:567:89ac"
)


# Zachowuje przypisany adres, chyba że urządzenie zostanie wyłączone
# - w takim wypadku należy przypisać kolejny adres poprzez DHCP.
# Jeżeli pobranie adresu przez DHCP nie powiedzie się - zostanie
# przypisany stały adres IP poprzez APIPA
config_eth0=(
   "noop"
   "dhcp"
)
fallback_eth0=(
   "null"
   "apipa"
)

2.b. Zależności sieciowe

Skrypty startowe znajdujące się w /etc/init.d mogą być zależne od konkretnego urządzenie sieciowego lub po prostu od usługi net. Usługa net może być zdefiniowana w /etc/conf.d/rc za pomocą zmiennej RC_NET_STRICT_CHECKING i może oznaczać różne rzeczy.

Ale co z net.br0 zależnym od net.eth0 oraz net.eth1? net.eth1 może być urządzeniem bezprzewodowym lub ppp, które potrzebuje skonfigurowania zanim zostanie uruchomione. Czynność ta nie może być dokonana w /etc/init.d/net.br0, gdyż jest to link symboliczny do net.lo.

Rozwiązaniem tego problemu jest samodzielne stworzenie funkcji depend() w /etc/conf.d/net

# Można użyć dowolnej zależności (use, after, before) według przykładów znalezionych w skryptach startowych
depend_br0() {
   need net.eth0 net.eth1
}

Więcej informacji o zależnościach można znaleźć w sekcji dotyczącej tworzenia skryptów inicjacyjnych w Podręczniku Gentoo.

2.c. Nazwy zmiennych i ich wartości

Nazwy zmiennych są dynamiczne. Najczęściej posiadają one strukturę zmienna_${interfejs|mac|essid|apmac}. Przykładowo, zmienna dhcpcd_eth0 przechowuje wartość dla opcji dhcpcd dla interfejsu eth0, zaś dhcpcd_essid przechowuje wartości dla opcji dhcpcd gdy interfejs podłączy się do ESSID o nazwie "essid".

Jednakże, nie ma zasady mówiącej o tym, iż nazwy interfejsów muszą mieć format ethx. Wiele urządzeń bezprzewodowych posiadają nazwy takie jak wlanx, rax, jak również eth.x Dodatkowo, niektóre interfejsy sieciowe zdefiniowane przez użytkowników, takie jak mostki, mogą posiadać dowolną nazwą, np. foo. Aby urozmaicić życie, bezprzewodowe punkty dostępu mogą mieć nazwy ze znakami nie alfanumerycznymi - jest to ważne, gdyż część opcji można konfigurować dla konkretnego ESSID-a.

Na domiar złego, Gentoo używa zmiennych bashowych do kontrolowania sieci - a bash nie potrafi korzystać z niczego co pochodzi spoza angielskich znaków alfanumerycznych. Aby ominąć te ograniczenie, każdy znak pochodzący spoza znaków dopuszczalnych zamieniany jest na znak _.

Kolejnym ograniczeniem powłoki bash jest to, że niektóre ze znaków muszą być specjalnie cytowane, czyli musi pojawić się przed nimi symbol \. Znaki, których to dotyczy to ", ' oraz \.

W poniższym przykładzie, zostaje użyty bezprzewodowy ESSID z najszerszym możliwym zestawem znaków. Zostanie użyty ESSID My "\ NET:

(Poniższe działa, ale domena jest nieprawidłowa)
dns_domain_My____NET="My \"\\ NET"

(Powyższe ustawienia ustawiają domenę dns jako My "\ NET gdy karta
#bezprzewodowa połączy się z punktem dostępu którego ESSID to My "\ NET)

3. Modularna praca w sieci

3.a. Moduły sieciowe

Obecnie wspierane są modułowe skrypty sieciowe, co oznacza, że w prosty sposób można dodawać kolejne urządzenia sieciowe i moduły konfiguracyjne, zachowując zgodność z obecnie działającymi.

Moduły są domyślnie wczytywane w momencie gdy są potrzebne przez jakiś pakiet. Jeżeli zostanie zdefiniowany moduł, który nie posiada zainstalowanego pakietu, wyświetlony zostanie błąd z komunikatem mówiącym jaki pakiet należy doinstalować. Najczęściej ustawień modułów używa się jedynie wtedy, gdy zostały zainstalowane dwa lub więcej pakiety, które udostępniają tę samą usługę i należy wyznaczyć która usługa ma pierwszeństwo.

# iproute2 ważniejsze niż ifconfig
modules=( "iproute2" )

# Można również określić inne moduły dla interfejsu.
# W tym przypadku pump jest ważniejsze niż dhcpcd
modules_eth0=( "pump" )

# Możliwe jest również określenie których modułów nie używać wcale -
# przykładowo może być używana kliencka lub kontrolowana przez linux-wlan-ng
# konfiguracja wifi, jednakże zachodzi potrzeba skonfigurowania własnych
# ustawień sieciowych dla każdego ESSID-a z którym sieć jest powiązana osobno.

modules=( "!iwconfig" )

3.b. Kontrolery sieciowe

Dostępne są dwa pakiety służące do kontrolowania interfejsów sieciowych: ifconfig oraz iproute2. Potrzebne jest jedno z tych dwóch, aby cokolwiek skonfigurować na urządzeniu sieciowym.

Domyślnie w Gentoo używane jest ifconfig i jest dostępny w profilu systemowym. iproute2 jest potężniejszy i elastyczniejszy, ale nie jest załączany domyślnie.

# emerge sys-apps/iproute2

# Aby iproute2 miało wyższy priorytet niż ifconfig, w przypadku gdy
obydwa są zainstalowane
modules=( "iproute2" )

Jako że ifconfig oraz iproute2 są podobne w działaniu, można pozwolić, aby ich podstawowa konfiguracja współpracowała ze sobą. Dla przykładu, poniższe linijki współpracują z obydwoma programami.

config_eth0=( "192.168.0.2/24" )
config_eth0=( "192.168.0.2 netmask 255.255.255.0" )

# Można również zdefiniować adres broadcast
config_eth0=( "192.168.0.2/24 brd 192.168.0.255" )
config_eth0=( "192.168.0.2 netmask 255.255.255.0 broadcast 192.168.0.255" )

3.c. DHCP

DHCP to pobieranie informacji o sieci (adres IP, serwery DNS, bramka, etc.). Oznacza to, że jeżeli jest serwer DHCP w sieci, należy wskazać komputerom klienckim, aby używały serwera DHCP, dzięki czemu sieć zostanie skonfigurowana automatycznie. Oczywiście, samodzielnie trzeba będzie skonfigurować takie rzeczy jak sieć bezprzewodowa, PPP czy inne, które są wymagane, zanim będzie można skorzystać z DHCP.

Z DHCP można skorzystać za pomocą dhcpcd, dhclient, pump lub udhcpc. Każdy z nich posiada swoje zalety i wady. Oto krótkie wprowadzenie.

Jeżeli jest zainstalowanych więcej niż jeden klient DHCP, należy określić który ma być używany. W innym przypadku zostanie użyty dhcpcd, jeżeli jest dostępny.

W celu wysłania określonych opcji do modułu dhcp, należy użyć module_eth0="..." (należy zmienić module na nazwę modułu dhcp, który jest używany, np. dhcpcd_eth0).

Dokładamy starań, aby DHCP było możliwie agnostyczne - wspieramy wobec tego następujące polecenia używając zmiennej dhcp_eth0. Domyślnie żadna z tych zmiennych nie jest ustawiona.

• release - uwalnia adres IP do ponownego użytku
• nodns - nie nadpisuje /etc/resolv.conf
• nontp - nie nadpisuje /etc/ntp.conf
• nonis - nie nadpisuje /etc/yp.conf

# Potrzebne tylko wtedy, gdy jest więcej niż jeden moduł DHCP
modules=( "dhcpcd" )

config_eth0=( "dhcp" )
dhcpcd_eth0="-t 10" # Wygaśnięcie po 10 sekundach
dhcp_eth0="release nodns nontp nonis" # Zdobywa jedynie adres

3.d. ADSL z PPPoE/PPPoA

Na początek należy zainstalować oprogramowanie do ADSL-a.

# emerge net-dialup/ppp

Następnie, tworzymy skrypt internetowy PPP oraz skrypt dla interfejsu sieciowego, który będzie używał PPP.

# ln -s /etc/init.d/net.lo /etc/init.d/net.ppp0
# ln -s /etc/init.d/net.lo /etc/init.d/net.eth0

Należy się upewnić, że posiadamy ustawioną zmienną RC_NET_STRICT_CHECKING="yes" w pliku /etc/conf.d/rc.

Następnie odpowiednio uzupełniamy plik /etc/conf.d/net.

config_eth0=( null ) (Używamy nazwy własnego interfejsu sieciowego)
config_ppp0=( "ppp" )
link_ppp0="eth0" (Używamy nazwy własnego interfejsu sieciowego)
plugins_ppp0=( "pppoe" )
username_ppp0='user'
password_ppp0='password'
pppd_ppp0=(
   "noauth"
   "defaultroute"
   "usepeerdns"
   "holdoff 3"
   "child-timeout 60"
   "lcp-echo-interval 15"
   "lcp-echo-failure 3"
   noaccomp noccp nobsdcomp nodeflate nopcomp novj novjccomp
)

depend_ppp0() {
  need net.eth0
}

Hasło możemy również przechowywać w pliku /etc/ppp/pap-secrets.

# * jest bardzo ważna
"username"  *  "password"

Jeżeli używamy PPPoE z modemem USB musimy zainstalować br2684ctl. Aby poprawnie go skonfigurować należy przeczytać /usr/portage/net-dialup/speedtouch-usb/files/README.

3.e. APIPA {Automatyczne prywatne adresowanie IP (ang. Automatic Private IP Addressing)}

APIPA stara sie znaleźć wolny adres w zakresie 169.254.0.0-169.254.255.255 poprzez losowe odpytywanie sieci za pomocą danego interfejsu. Jeżeli nie ma żadnej odpowiedzi, taki adres jest przypisywany do interfejsu.

Przydaje się tylko w sieciach LAN gdzie nie ma serwera DHCP, które nie mają połączenia z Internetem i gdzie wszystkie komputery używają APIPA.

Aby było wsparcie dla APIPA, należy zainstalować net-misc/iputils lub net-analyzer/arping.

# Najpierw próbujemy skonfigurować poprzez DHCP - jeżeli to się nie powiedzie, próbujemy APIPA
config_eth0=( "dhcp" )
fallback_eth0=( "apipa" )

# Należy użyć jedynie APIPA
config_eth0=( "apipa" )

3.f. Wiązanie urządzeń sieciowych

Aby mieć możliwość łączenia urządzeń sieciowych, należy zainstalować net-misc/ifenslave.

Łączenie urządzeń sieciowych stosuje się w celu zwiększenia przepustowości sieci. Jeżeli w komputerze są do dyspozycji dwie karty sieciowe znajdujące się w tej samej sieci, można je połączyć tak, żeby aplikacje w rzeczywistości używały obu urządzeń jednocześnie.

Aby połączyć urządzenia razem
slaves_bond0="eth0 eth1 eth2"

# Jeżeli nie trzeba przypisywać adresu IP do interfejsu
config_bond0=( "null" )

# Zależne od eth0, eth1 oraz eth2 jako, że mogą wymagać dodatkowej konfiguracji
depend_bond0() {
  need net.eth0 net.eth1 net.eth2
}

3.g. Mostkowanie (wsparcie dla 802.1d)

Aby mieć możliwość mostkowania, należy zainstalować net-misc/bridge-utils.

Mostkowanie jest używane do łączenia w całość dużych sieci. Dla przykładu można mieć serwer, który łączy się z internetem przy pomocy ADSL oraz ma połączenie z bezprzewodową kartą sieciową by umożliwić innym komputerom łączenie się z internetem przy pomocy modemu ADSL. Można stworzyć mostek do połączenia obydwu interfejsów.

# Konfiguracja mostka - "man brctl", aby uzyskać szczegółowe informacje
brctl_br0=( "setfd 0" "sethello 0" "stp off" )

# Aby dodać porty do mostka br0
bridge_br0="eth0 eth1"

# Należy skonfigurować porty jako wartość null tak aby dhcp nie uruchomiło się
config_eth0=( "null" )
config_eth1=( "null" )

# Na koniec należy nadać mostkowi adres - można również użyć DHCP
config_br0=( "192.168.0.1/24" )

# Należy zależeć od eth0 oraz eth1 jako że mogą wymagać dodatkowej konfiguracji
depend_br0() {
  need net.eth0 net.eth1
}

3.h. Adresy MAC

W celu zmiany adresów MAC interfejsów sieciowych wystarczy posiadać zainstalowany sys-apps/baselayout-1.11.14 lub nowszy. Jeżeli zachodzi potrzeba zamiany adresu na losowy lub baselayout jest starszy od wyżej wymienionej wersji, należy zainstalować net-analyzer/macchanger.

# Aby przypisać adres MAC konkretnemu urządzeniu
mac_eth0="00:11:22:33:44:55"

# Aby tylko ostatnie trzy bajty były losowe
mac_eth0="random-ending"

# Aby wybierać losowo pomiędzy tym samym fizycznym połączeniem (np.
# światłowód, miedź lub bezprzewodowo), wszyscy producenci
mac_eth0="random-samekind"

# Aby wybierać losowo pomiędzy różnymi fizycznymi połączeniami (np.
światłowód, miedź lub bezprzewodowo), wszyscy producenci
mac_eth0="random-anykind"

# Pełna losowość - UWAGA: niektóre adresy MAC wygenerowane w ten sposób
mogą zachowywać się inaczej niż powinny
mac_eth0="random-full"

3.i. Tunelowanie

Nie trzeba niczego instalować, aby korzystać z tunelowania, gdyż kontroler sieciowy posiada już tę możliwość.

# Dla tuneli GRE
iptunnel_vpn0="mode gre remote 207.170.82.1 key 0xffffffff ttl 255"

# Dla tuneli IPIP
iptunnel_vpn0="mode ipip remote 207.170.82.2 ttl 255"

# Aby skonfigurować interfejs
config_vpn0=( "192.168.0.2 peer 192.168.1.1" )

3.j. VLAN (wsparcie dla 802.1q)

Aby posiadać wsparcie dla VLAN, należy zainstalować net-misc/vconfig.

VLAN to grupa urządzeń sieciowych które zachowują się tak, jakby były podłączone do jednego segmentu sieciowego - nawet jeśli tak nie jest. Członkowie VLAN-u mogą jedynie widzieć innych członków VLAN-u, nawet jeśli współdzielą sieć z innymi urządzeniami.

# Wyznaczanie numerów VLAN dla urządzeń
# Należy być pewnym, że ID VLAN-u NIE składają się z zera
vlans_eth0="1 2"

# Można również skonfigurować sam VLAN
# wystarczy zajrzeć do manuala vconfig, aby uzyskać szczegółowe
#informacje
vconfig_eth0=( "set_name_type VLAN_PLUS_VID_NO_PAD" )
vconfig_vlan1=( "set_flag 1" "set_egress_map 2 6" )

# Konfiguracja interfejsu w tradycyjny sposób
config_vlan1=( "172.16.3.1 netmask 255.255.254.0" )
config_vlan2=( "172.16.2.1 netmask 255.255.254.0" )

4. Połączenia bezprzewodowe

4.a. Wstęp

Obecnie wspierane są ustawienia dla sieci bezprzewodowych poprzez wireless-tools lub wpa_supplicant. Ważne jest, aby pamiętać że urządzenia bezprzewodowe są konfigurowane globalnie, a nie dla konkretnych urządzeń.

wpa_supplicant jest najlepszym wyborem, jednakże nie wspiera wszystkich sterowników. Pod adresem projektu wpa_supplianet można uzyskać listę zgodnych urządzeń. Dodatkowo, wpa_supplicant może łączyć się jedynie z ESSID-ami dla których został skonfigurowany.

wireless-tools wspiera niemalże wszystkie karty oraz sterowniki, ale nie potrafi połączyć się z access pointami, które korzystają tylko z WPA.

4.b. WPA Supplicant

WPA Supplicant to pakiet, który pozwala połączyć się do punktów dostępowych z włączonym WPA. Jego ustawienia są dość płynne, ponieważ jest jeszcze w fazie beta - mimo to, działa całkiem dobrze.

# emerge net-wireless/wpa_supplicant

Teraz należy skonfigurować /etc/conf.d/net i wskazać, że wpa_supplicant ma być używany w pierwszej kolejności, przed wireless-tools (jeśli obydwa są zainstalowane, w pierwszej kolejności używany jest wireless-tools).

# wpa_supplicant będzie użyty przed wireless-tools
modules=( "wpa_supplicant" )

# Bardzo istotne jest, aby wskazać wpa_supplicant który sterownik
# powinien zostać użyty, gdyż na obecnym etapie rozwoju nie jest jeszcze
# najlepszy w samodzielnym zgadywaniu
wpa_supplicant_eth0="-Dmadwifi"

Nie było to trudne, prawda? Nadal jednak trzeba skonfigurować wpa_supplicant samo w sobie, co jest dość trudne w zależności od tego jak bezpieczne są access pointy, z którymi następuje połączenie. Poniższy przykład jest uproszczoną wersją z pliku /usr/share/doc/wpa_supplicant-<version>/wpa_supplicant.conf.gz, który pochodzi z wpa_supplicant.

# Zmiana poniższej linijki może spowodować, że wpa_supplicant nie będzie działać
ctrl_interface=/var/run/wpa_supplicant

# Należy być pewnym, że tylko root ma dostęp do konfiguracji WPA
ctrl_interface_group=0

# Niech wpa_supplicant zajmie sie wyszukiwaniem i ustawianiem AP
ap_scan=1

# Prosty przykład: WPA-PSK, PSK oraz hasło w  ASCII umożliwiają poprawną autoryzację
network={
   ssid="proste"
   psk="bardzo tajne hasło"
   # Im wyższy priorytet, tym wcześniej zostanie dopasowane
   priority=5
}

# Podobne jak poprzednie, ale będzie dokonane skanowanie SSID-ów (dla
# AP, które nie wysyłają swojego SSID-a)
network={
   ssid="drugi ssid"
   scan_ssid=1
   psk="bardzo tajne hasło"
   priority=2
}

# Jedynie WPA-PSK jest używane. Dowolna kombinacja hasła jest akceptowana
network={
   ssid="przykład"
   proto=WPA
   key_mgmt=WPA-PSK
   pairwise=CCMP TKIP
   group=CCMP TKIP WEP104 WEP40
   psk=06b4be19da289f475aa46a33cb793029d4ab3db7a23ee92382eb0106c72ac7bb
   priority=2
}

# Połączenie bez szyfrowania (brak WPA, brak IEEE 802.1X)
network={
   ssid="test-bez-szyfrowania"
   key_mgmt=NONE
}

# Połączenie ze współdzielonym WEP (brak WPA, brak IEEE 802.1X)
network={
   ssid="test-statycznego-wep"
   key_mgmt=NONE
   # Klucze umieszczone w cudzysłowiach są kluczami ASCII
   wep_key0="abcde"
   # Klucze bez cudzysłowiów są kluczami w postaci szesnastkowej
   wep_key1=0102030405
   wep_key2="1234567890123"
   wep_tx_keyidx=0
   priority=5
}

# Połączenie ze współdzielonym WEP z kluczem (brak WPA, brak IEEE
# 802.1X) używając autoryzację ze współdzielonym kluczem IEEE 802.11
network={
   ssid="test2-statycznego-wep"
   key_mgmt=NONE
   wep_key0="abcde"
   wep_key1=0102030405
   wep_key2="1234567890123"
   wep_tx_keyidx=0
   priority=5
   auth_alg=SHARED
}

# Sieć IBSS/ad-hoc z WPA-None/TKIP
network={
   ssid="test adhoc"
   mode=1
   proto=WPA
   key_mgmt=WPA-NONE
   pairwise=NONE
   group=TKIP
   psk="tajne hasło"
}

4.c. Narzędzia do sieci bezprzewodowych

Wstępna konfiguracja i tryb zarządzany

Wireless Tools posiadają podstawowe metody na konfigurację podstawowych interfejsów sieci bezprzewodowych aż do ustawień poziomu zabezpieczeń WEP. Mimo, że WEP to dość słaba metoda zabezpieczeń, jest najczęściej stosowana.

Konfiguracje Wireless Tools są kontrolowane przy pomocy kilku głównych zmiennych. Przykładowa konfiguracja poniżej powinna opisać wszystko co jest potrzebne. Jedyne o czym należy pamiętać, to fakt, że dana konfiguracja nie oznacza "połącz się z najlepszym nieszyfrowanym access pointem" - zawsze nastąpi próba połączenia z czymkolwiek.

# emerge net-wireless/wireless-tools

# W pierwszej kolejności zostanie użyte iwconfig przed wpa_supplicant
modules=( "iwconfig" )

# Konfiguracja dla Access Pointów nazwanych ESSID1 oraz ESSID2
# Można skonfigurować do 4 kluczy WEP, ale tylko jeden może być aktywny
# w danym momencie, tak aby domyślny indeks [1] był ustawiony na klucz [1] i z
# powrotem aby ustawić klucz na [1]. Dokonuje się tego w przypadku gdy
# ESSID został skonfigurowany dla kluczy WEP innych niż 1.
# Poprzedzając klucz przy pomocy s: oznacza że jest to klucz w ASCII, w innym
# przypadku jest to klucz w HEX
# enc open oznacza otwarte bezpieczeństwo (najbezpieczniejsze)
# enc restricted oznacza zastrzeżone bezpieczeństwo (mniej bezpieczne)
key_ESSID1="[1] s:twojklucz key [1] enc open"
key_ESSID2="[1] aaaa-bbbb-cccc-dd key [1] enc restricted"

# Poniższe zadziała tylko gdy będą poszukiwane dostępne Access Pointy

# Niekiedy widocznych jest więcej Access Pointów, więc należy
# zdefiniować który jest preferowany i w jakiej kolejności należy się łączyć
preferred_aps=( "ESSID1" "ESSID2" )

Konfiguracja wyboru punktów dostępu

Można dodać kilka opcji, aby lepiej skonfigurować wybór Access Pointów, jednakże na ogół nie są one wymagane.

Można zdecydować czy łączymy się tylko z preferowanymi Access Pointami czy nie. Domyślnie, jeśli żadne z ustawień nie zadziałają i można połączyć się do nieszyfrowanego Access Pointa, to nastąpi połączenie. Można to kontrolować przy pomocy zmiennej associate_order. Poniżej znajduje się tabela z wartościami oraz jak wpływają na kontrolę.

Ostatecznie, istnieje możliwość wyboru blacklist_aps oraz unique_ap. blacklist_aps działa podobnie jak preferred_aps. unique_ap to wartość tak lub nie które wskazuje czy drugi interfejs bezprzewodowy może połączyć się do tego samego Access Pointa co pierwszy interfejs.

# Niekiedy nie powinno nastąpić połączenie do poszczególnych access pointów
blacklist_aps=( "ESSID3" "ESSID4" )

# Jeżeli jest więcej niż jedna karta bezprzewodowa, można określić czy
# powinno nastąpić połączenie każdej karty z tym samym punktem dostępu czy nie
# Wartości to "yes" (tak) lub "no" (nie)
# Domyślnie jest "yes"
unique_ap="yes"

Tryb Ad-Hoc oraz Zarządzany

Jeżeli zachodzi potrzeba ustawienia własnego węzła Ad-Hoc w przypadku braku możliwości połączenia się z jakimkolwiek Access Pointem, to również jest to możliwe.

adhoc_essid_eth0="Ten Węzeł Adhoc"

A co z połączeniami do sieci Ad-Hoc lub działaniem w trybie zarządcy, aby stać się Access Pointem? Poniżej znajduje się konfiguracja do tego! Może zajść potrzeba, aby ustawić klucze WEP pokazane powyżej.

# Ustawienie trybu - może być zarządzany (domyślnie), ad-hoc lub
# zarządcy. Nie wszystkie sterowniki umożliwiaj skorzystanie z tych trybów
mode_eth0="ad-hoc"

# Ustawienie ESSID interfejsu
# W trybie zarządzanym, zmusza to interfejs do połączenia się z wyznaczonym
# ESSIESSID-em niczym innym
essid_eth0="Ten węzeł Adhoc"

# Jeśli nie zostanie wyznaczony żaden inny, zostanie użyty 3.
channel_eth0="9"

Rozwiązywanie problemów z Wireless Tools

Jest kilka zmiennych, których można użyć do ustawienia i uruchomienia sieci bezprzewodowej, pomimo napotkanych problemów. Poniżej znajduje się tabela, która przedstawia zmienne do wypróbowania.

4.d. Definiowanie konfiguracji sieci w zależności od ESSID

Niekiedy po połączeniu do ESSID1, zachodzi potrzeba otrzymania statycznego adresu IP, zaś w przypadku ESSID2 - dynamicznego przez DHCP. Większość zmiennych może być ustawianych w zależności od ESSIDa. Poniżej jest opisane jak tego dokonać.

config_ESSID1=( "192.168.0.3/24 brd 192.168.0.255" )
routes_ESSID1=( "default via 192.168.0.1" )

config_ESSID2=( "dhcp" )
fallback_ESSID2=( "192.168.3.4/24" )
fallback_route_ESSID2=( "default via 192.168.3.1" )

# Można skonfigurować serwery nazw i inne rzeczy
# NOTATKA: DHCP to przepisze, chyba że zostanie ustawione inaczej
dns_servers_ESSID1=( "192.168.0.1" "192.168.0.2" )
dns_domain_ESSID1="some.domain"
dns_search_domains_ESSID1="szukaj.tej.domeny szukaj.tamtej.domeny"

# Nadpisuje się adres MAC adresem Access Pointa. Jest to przydatne gdy
# zachodzi potrzeba przemieszczania się między różnymi lokalizacjami, które
# posiadają ten sam ESSID
config_001122334455=( "dhcp" )
dhcpcd_001122334455="-t 10"
dns_servers_001122334455=( "192.168.0.1" "192.168.0.2" )

5. Dodawanie możliwości

5.a. Standardowe zaczepy funkcji

Można zdefiniować cztery funkcje, które będą uruchamiane przy okazji operacji start/stop. Początkowo funkcje są uruchamiane razem z nazwą interfejsu tak, aby jedna funkcja mogła kontrolować wiele urządzeń.

Wartości jakie są zwracane po wykonaniu funkcji preup oraz predown powinny być równe 0 (sukces), aby powiadomić, że konfiguracja urządzenia mogła być kontynuowana. Jeżeli funkcja preup zwróci wartość różną od 0, konfiguracja zostanie przerwana. Jeżeli funkcja predown zwróci wartość różną od zera, to niemożliwa będzie dalsza dekonfiguracja urządzenia.

Wartości jakie są zwracane po wykonaniu funkcji postup oraz postdown są ignorowane, gdyż nic nie jest wykonywane w przypadku niepowodzenia.

${IFACE} jest ustawione jako nazwa urządzenia, które jest włączane/wyłączane. ${IFVAR} to ${IFACE} przekonwertowane do zmiennej akceptowanej przez bash.

preup() {
   # Sprawdza czy istnieje link na interfejsie, który jest
   # uruchamiany. Ta opcja działa jedynie na kilku urządzeniach
   # sieciowych i wymaga, aby pakiet ethtool był zainstalowany
   if ethtool ${IFACE} | grep -q 'Link detected: no'; then
      ewarn "Brakuje linku na ${IFACE}, przerywam konfigurację"
      return 1
   fi

   # Należy pamiętać o zwróceniu wartości 0 w przypadku powodzenia
   return 0
}

predown() {
   # Domyślny skrypt sprawdza czy istnieje katalog główny NFS i
   # nie zezwala na wyłączenie interfejsów w takim przypadku. Należy
   # zauważyć, że jeśli określi się własną funkcję predown(), to właściwość
   # ta zostanie usunięta. Poniżej znajduje się ten skrypt, jeśli okazałoby
   # się, że jest nadal potrzebny...
   if is_net_fs /; then
      eerror "katalog główny jest zamontowany przez sieć -- nie można zatrzymać ${IFACE}"
      return 1
   fi

   # Należy pamiętać o zwróceniu wartości 0 w przypadku powodzenia
   return 0
}

postup() {
   # Ta funkcja zostanie użyta dla przykładu, aby zarejestrować
   # interfejs z usługą DNS. Inną możliwością jest np. wysłanie wiadomości
   # mailowej z informacją o uruchomieniu interfejsu
   return 0
}

postdown() {
   # Ta funkcja jest tu tylko dla zasady... Jeszcze nie
   # wiadomo co fajnego można z nią zrobić ;-)
   return 0
}

5.b. Funkcje dla sieci bezprzewodowych

Można zdefiniować dwie funkcje, które zostaną uruchomione razem z powiązaną funkcją. Funkcje te są uruchamiane najpierw z nazwą interfejsu, aby jedna z nich mogła obsługiwać wiele urządzeń.

Zwracane wartości dla funkcji uruchamianych przed uruchomieniem urządzenia powinny być równe 0 (sukces), aby wskazać, że konfiguracja może być kontynuowana. Jeżeli zostanie zwrócona wartość różna od zera, konfiguracja zostanie przerwana.

Zwracane wartości dla funkcji preassociate są ignorowane gdyż i tak nie mają wpływu na dalszą konfigurację.

${ESSID} jest równe wartości ESSID punktu dostępu z którym dokonywane jest połączenie. ${ESSIDVAR} jest równe ${ESSID} przekonwertowane do zmiennej akceptowanej przez powłokę bash

preassociate() {
   # Poniższe linijki dodają dwie zmienne leap_user_ESSID oraz
   # leap_pass_ESSID. Jeżeli obie są skonfigurowane dla ESSID-a z którym są
   # połączone, uruchamiany jest skrypt CISCO LEAP

   local user pass
   eval user=\"\$\{leap_user_${ESSIDVAR}\}\"
   eval pass=\"\$\{leap_pass_${ESSIDVAR}\}\"

   if [[ -n ${user} && -n ${pass} ]]; then
      if [[ ! -x /opt/cisco/bin/leapscript ]]; then
         eend "For LEAP support, please emerge net-misc/cisco-aironet-client-utils"
         return 1
      fi
      einfo "Waiting for LEAP Authentication on \"${ESSID//\\\\//}\""
      if /opt/cisco/bin/leapscript ${user} ${pass} | grep -q 'Login incorrect'; then
         ewarn "Login Failed for ${user}"
         return 1
      fi
   fi

   return 0
}

postassociate() {
   # Ta funkcja jest tu tylko dla zasady... Jeszcze nie
   # wiadomo co fajnego można z nią zrobić ;-)

   return 0
}

6. Zarządzanie siecią

6.a. Zarządzanie siecią

Jeżeli komputer jest ciągle "w drodze", nie zawsze może być podłączony do sieci, czy też posiadać dostępu do access pointa. W takich przypadkach może okazać się, że pożądane by było, aby sieć włączała się automatycznie w momencie gdy możliwy jest do niej dostęp.

Poniżej można znaleźć opis kilku narzędzi, które mogą być w tym pomocne.

6.b. ifplugd

ifplugd to demon, który uruchamia i zatrzymuje urządzenia sieciowe gdy kabel sieciowy jest wkładany lub wyjmowany z gniazda. Może również zarządzać przypisaniami do access pointów, gdy jakiś nowy pojawi się w zasięgu.

# emerge sys-apps/ifplugd

Konfiguracja ifplugd jest bardzo prosta. Plik konfiguracyjny znajduje się w /etc/conf.d/ifplugd. man ifplugd pokaże co poszczególne opcje oznaczają. W pliku /etc/conf.d/net.example znajdziemy przykładowe wpisy, które pomogą nam przy tworzeniu naszej konfiguracji.

(Zastępujemy eth0 nazwą interfejsu, który chcemy monitorować)
ifplugd_eth0="..."

(Aby monitorować kartę sieci bezprzewodowej)
ifplugd_eth0="--api-mode=wlan"

Jeżeli zechcemy zarządzać wieloma połączeniami sieciowymi, będziemy potrzebowali narzędzia, które pomoże nam w pracy z wieloma serwerami DNS oraz wieloma konfiguracjami. Jest to bardzo przydatne, gdy adres IP otrzymujemy za pomocą DHCP. Do tego celu instalujemy openresolv.

# emerge openresolv

Aby dowiedzieć się więcej o programie, należy przeczytać man resolvconf.

Materiał udostępniany na podstawie licencji Creative Commons - Attribution / Share Alike.