Podręcznik Gentoo PPC
Spis treści:
-
Instalacja Gentoo
Naucz się instalować Gentoo!
-
O instalacji Gentoo Linux
Wprowadzenie do opisanego w dalszych rozdziałach procesu instalacji
Gentoo.
-
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.
-
Konfigurowanie sieci
Aby mieć możliwość ściągnięcia z Internetu najnowszych źródeł programów, należy
najpierw skonfigurować połączenie sieciowe.
-
Przygotowywanie dysków
Opis tworzenia partycji, na których zostanie zainstalowane Gentoo.
-
Wypakowywanie plików instalacyjnych Gentoo
Gentoo instaluje się rozpakowując archiwum o nazwie stage3. W tym rozdziale
opisujemy wypakowywanie tego pliku i wstępną konfigurację Portage.
-
Instalowanie systemu podstawowego
Przed przystąpieniem do instalacji z pliku stage3 trzeba nagrać system
podstawowy.
-
Konfigurowanie jądra
Jądro Linux jest rdzeniem każdej dystrybucji. W tym rozdziale wytłumaczymy, jak
je skonfigurować.
-
Konfigurowanie systemu
Dla poprawnej pracy systemu, należy wyedytować kilka ważnych plików
konfiguracyjnych.
-
Instalowanie narzędzi systemowych
W tym rozdziale pomożemy w wybraniu i instalacji najważniejszych narzędzi
potrzebnych do prawidłowego funkcjonowania systemu.
-
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.
-
Zakończenie instalacji Gentoo
Na koniec musimy jeszcze utworzyć jedno lub kilka dodatkowych kont użytkowników.
-
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.
-
Wprowadzenie do Portage
Wszystko to, co trzeba wiedzieć na temat Portage, aby móc przy jego pomocy
skutecznie zarządzać systemem.
-
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.
-
Funkcje Portage
Ten rozdział pomaga odkryć dodatkowe funkcje Portage.
-
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ć.
-
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.
-
Pliki i katalogi
Omówienie struktury i miejsca przechowywania plików konfiguracyjnych używanych
przez Portage.
-
Konfigurowanie Portage
Proces konfigurowania systemu Portage poprzez zmianę odpowiednich plików
konfiguracyjnych i zmiennych środowiskowych.
-
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.
-
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.
-
Pozostawiając oficjalne drzewo Portage
Opis kilku sztuczek związanych z codzienną pracą w Gentoo, m.in. tworzenia
własnego drzewa Portage, synchronizowania tylko wybranych kategorii, czy
wstrzykiwania (inject) pakietów.
-
Konfiguracja sieci w Gentoo
Szczegółowy opis zagadnień sieciowych w Gentoo
-
Wprowadzenie
Opis szybkiego i sprawnego skonfigurowania interfejsu sieciowego w większości
środowisk.
-
Zaawansowana konfiguracja
Przed przejściem do modularnej pracy w sieci musimy nauczyć się zasad jakimi
rządzi się konfiguracja.
-
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.
-
Połączenia bezprzewodowe
To nie jest prosta sprawa, na szczeście zwykle udaje się jednak połączyć.
-
Dodawanie możliwości
Osoby czujące się na siłach mogą znacznie rozszerzyć funkcje swojej sieci.
-
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 jest inaczej, 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.
-
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 Podręczniku omawiamy instalację przy użyciu płyt Gentoo LiveCD oraz,
w pewnych przypadkach, rozruchu z sieci (netboot). Generalnie zakładamy, że
użytkownik zamierza zainstalować najnowsze dostępne wersje pakietów. Instalację
bez dostępu do Internetu omawiamy w Podręcznikach Gentoo 2008.0.
W przypadku instalacji przy pomocy GRP (Gentoo Reference Platform - kolekcja
prekompilowanych pakietów służących do błyskawicznego instalowania Gentoo)
trzeba skorzystać z instrukcji w Podręcznikach Gentoo 2008.0.
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, który
znajduje się w naszych zasobach
dokumentacji.
Możliwości wyboru nie kończą się na medium instalacyjnym. Możliwe jest
skompilowanie całego systemu od podstaw lub wykorzystanie do jego budowy
prekompilowanych pakietów, co zaoszczędzi mnóstwo czasu. Oczywiście są także
rozwiązania mieszane, dzięki którym nie trzeba kompilować wszystkiego i
można zacząć od częściowo przygotowanego systemu.
Problemy?
Jeśli w czasie instalacji pojawi się jakiś problem (lub wystąpią błędy w
dokumentacji) zachęcamy do odwiedzenia 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.
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
| Komputery Apple NewWorld |
Procesor Power/PowerPC (G3, G4, G5) takie jak iMac, eMac, iBook, PowerBook,
Xserver, PowerMac
|
| Komputery Apple OldWorld |
Komputery z wersją Open Firmware mniejszą niż 3, takie jak: Beige G3, PCI
PowerMac i PCI PowerBook oraz klony Apple oparte na PCI.
|
| Genesi |
Pegasos I/II, Open Desktop Workstation, Efika
|
| IBM |
RS/6000, iSeries, pSeries |
| Pamięć |
Co najmniej 64 MB |
| Wolne miejsce na dysku |
1.5 GB (bez miejsca na partycję wymiany) |
| Partycja wymiany |
Co najmniej 256 MB |
Należy również zapoznać się z dokumentem Gentoo PPC FAQ, gdzie znajdują się
odpowiedzi na najczęściej zadawane pytania oraz rozwiązania najczęstszych
problemów.
2.b. Uniwersalna płyta instalacyjna Gentoo
Wprowadzenie
Gentoo Linux może zostać zainstalowane z użyciem archiwum stage3. Plik taki
zawiera minimalne środowisko, którego możemy użyć do instalacji Gentoo Linux na
naszym komputerze.
Proces instalacji z użycie stage1 lub stage2 nie został opisany w Podręczniku
Gentoo. Aby dowiedzieć się więcej o instalacji z tych archiwów należy zapoznać
się z dokumentem Gentoo, często zadawane
pytania.
Uniwersalna płyta instalacyjna Gentoo
Płyta instalacyjna jest medium, które zawiera w pełni sprawne środowisko
Gentoo. Pozwala ona na uruchomienie Linuksa z CD. Podczas jej uruchamiania
wykrywane są nasze podzespoły oraz ładowane są odpowiednie sterowniki. Płyty
instalacyjne Gentoo są rozwijane przez deweloperów Gentoo.
Obecie dostępne są dwie płyty instalacyjne:
-
Uniwersalna płyta instalacyjna zawiera wszystkie potrzebne do instalacji
Gentoo narzędzia. Wraz z płytą dostarczane są pliki stage3 dla wszystkich
popularnych architektur, kody źrodłowe dla dodatkowych aplikacji oraz
oczywiście instrykcje dotyczące instalacji systemu.
-
Minimalna płyta instalacyjna Gentoo, zawiera jedynie minimalne środowisko
pozwalające uruchomić i skonfigurować sieć, aby móc połączyć się z
Internetem. Nie zawiera żadnych dodatkowych plików i nie może być użyta do
instalacji opisanej w tym dokumencie.
Gentoo dostarcza również płytę CD z prekompilowanymi pakietami. Nie jest to
płyta instalacyjna, a dodatkowe źródło, które możemy wykorzystać podczas
instalacji Gentoo. Zawiera skompilowane pakiety (znane tez jako zestaw GRP),
które pozwalają w szybki i łatwy sposób zainstalować dodatkowe aplikacje (takie
jak OpenOffice.org, KDE, Gnome...) zaraz po zakończeniu instalacji samego
systemu, a jeszcze przed aktualizacją drzewa Portage.
Dokładniejszy opis użycia płyty z pakietami prekompilowanymi znajduje się w
dalszej części tego dokumentu.
2.c. Pobieranie, nagrywanie i uruchamianie uniwersalnej płyty instalacyjnej Gentoo
Pobieranie i nagrywanie płyty instalacyjnej
Uniwersalną płytę instalacyjną (oraz jeśli zechcemy płytę z pakietami
prekompilowanymi) możemy pobrać z jednego z serwerów lustrzanych. Płyty instalacyjne
znajdują się w katalogu releases/ppc/2008.0/installcd, a
płyty z pakietami prekompilowanym w katalogu releases/ppc/2008.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ągnieciu obrazu możemy sprwdzić jego poprawność poprzez kontrole sum
kontrolnych.
-
Możemy sprawdzić sumy MD5 i porównać je z wartościami dostarczanymi przez
nas (dla przykładu przy pomocy narzędzia md5sum dla Linuksa, lub
jego odpowiednika dla
Windows). Sprawdzanie sum kontrolnych MD5 w systemie Mac OS X opisano w
dokumencie Gentoo/PPC,
często zadawane pytania
-
Możemy również sprawdzić kryptograficzny podpis, który jest przez nas
dostarczany. Musimy uzyskać publiczny klucz, którego używamy (0x17072058)
przed przystąpieniem do tej czynności.
Aby pobrać nasz publiczny klucz używając programu GnuPG, należy wydać poniższe
polecenie:
Listing 3.1: Pozyskiwanie klucza publicznego |
$ gpg --keyserver subkeys.pgp.net --recv-keys 0x17072058
|
Następnie weryfikujemy sygnaturę.
Listing 3.2: Weryfikowanie sygnatury plików |
$ 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 należy wybrać Tools (Narzędzia) > Burn CD Image
(Nagraj obraz płyty), a następnie wskazać plik ISO w obszarze "Image to
Burn" (Obraz do nagrania) i kliknąć 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:
Dostarczamy jeden wspólny kernel, o nazwie apple. Ma wsparcie dla
komputerów wieloprocesorowych, ale na komputerze z jednym procesorem również
nie ma z nim żadnych problemów.
Można tu również podać kilka dodatkowych opcji z jakim zostanie uruchomione
wybrane jądro. Są to:
| Opcja |
Opis |
| video |
Do tej opcji można podać następujące, zależne od producenta karty
parametry: radeonfb, rivafb, atyfb, aty128,
aty128 lub ofonly. Do tego warto również dopisać żądaną
rozdzielczość i częstotliwość odświeżania. Wpis może na przykład wyglądać
tak: video=radeonfb:1280x1024@75. Jeśli nie jest się pewnym co
wybrać należy skorzystać z opcji ofonly, ona działa we wszystkich
przypadkach.
|
| nol3 |
Wyłącza cache 3 poziomu w niektórych PowerBookach |
| dofirewire |
Włącza obsługę urządzeń z interfejsem IEEE1394 (FireWire), np. zewnętrznych
dysków.
|
| dopcmcia |
Umożliwia korzystanie w trakcie procesu instalacji z różnych
urządzeń PCMCIA, np. kart sieciowych.
|
| dosshd |
Uruchamia usługę sshd umożliwiając zdalną instalację |
| passwd=foo |
Zmienia hasło na podane po znaku = wyrażenie, używane z opcją dosshd
do zdalnych instalacji
|
Aby czerpać pożytek z powyższych opcji, w linii boot:, powinniśmy
wpisać apple, a następnie porządaną przez nas opcję. W poniższym
przykładzie, zmusimy jądro do używania sterownika framebuffer Open Firmware w
miejsce sterownika specyficznego dla danego urządzenia.
Listing 3.3: Przymusowe użycie sterownika framebuffer Open Firmware |
boot: apple 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ń, na przykład wpisując boot cd /boot/pegasos
video=radeonfb:1280x1024@75 mem=256M. Kompletna 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=/image.squashfs 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 apple z płyty instalacyjnej. Na koniec należy jeszcze
przekopiować plik apple.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 apple.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:
Listing 3.4: Parametry jądra podawane przez BootX |
cdroot root=/dev/ram0 init=linuxrc loop=image.squashfs looptype=squashfs console=tty0
|
Uwaga:
Można tu użyć wszystkich parametrów jądra z akapitu o yaboot.
|
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.
Listing 3.5: Listing dostępnych map klawiszy |
# ls /usr/share/keymaps/i386
|
Następnie ładujemy wybraną mapę klawiszy:
Listing 3.6: Ładowanie mapy klawiszy |
# loadkeys be-latin1
|
Kolejna część dokumentu to Konfigurowanie
dodatkowego sprzętu.
Konfiguracja dodatkowych urządzeń
Kiedy instalacyjna płyta CD zostaje uruchomiona, system próbuje wykryć
wszystkie urządzenia zainstalowane w naszym komputerze, a następnie ładuje
odpowiednie moduły. W ogromnej większości przypadków rezultaty są bardzo dobre.
Jednak w niektórych przypadkach, może nastąpić nie załadowanie modułu jądra,
który jest potrzebny. Jeśli zostanie pominięty jakiś moduł, możemy go załadować
ręcznie.
W poniższym przykładzie pokazano w jaki sposób załadować moduł 8139too
(wsparcie dla części popularnych kart sieciowych):
Listing 3.7: Ładnowanie modułów jądra |
# modprobe 8139too
|
Opcjonalnie: Konta użytkowników
Jeśli planujemy dać dostęp do środowiska instalacyjnego osobom trzecim lub
chcemy używać irssi z konta innego niż root (ze względów
bezpieczeństwa), należy stworzyć potrzebne konta użytkownika,a następnie
zmienić hasło dla root.
Aby zmienić hasło root używamy narzędzia passwd:
Listing 3.8: Zmiana hasła root |
# passwd
New password:
Re-enter password:
|
Aby utworzyć konto użytkownika, należy najpierw wpisać odpowiednie referencje,
a następnie hasło. Do tych czynności użyć należy poleceń useradd oraz
passwd. W poniższym przypadku stworzymy użytkownika "damian".
Listing 3.9: Tworzenie konta użytkownika |
# useradd -m -G users damian
# passwd damian
New password:
Re-enter password:
|
Na konto nowo utworzonego użytkownika możemy dostać się używając polecenia
su.
Listing 3.10: Zmiana aktualnego użytkownika |
# su - damian
|
Opcjonalnie: Przeglądanie dokumentacji podczas instalacji
W przypadku gdy chcemy przeglądać Podręcznik Gentoo (zarówno w wersji CD jak i
online) podczas instalacji, należy się upewnić, że stworzyliśmy konto
użytkownika (więcej informacji w rozdziale Opcjonalnie: Konta użytkowników. Następnie używamy
kombinacji Alt-F2, aby przenieść się na nowy terminal i tam się
logujemy:
Dostęp do dokumentacji znajdującej się na CD możemy uzyskać natychmiast
używając polecenia links:
Listing 3.11: Przeglądanie dokumentacji znajdującej się na CD |
# links /mnt/cdrom/docs/html/index.html
|
Jednak zalecane jest używanie wersji znajdującej się online, ponieważ będzie
ona aktualniejsza od tej znajdującej się na CD. I w tym przypadku możemy użyć
links, ale jedynie w przypadku gdy zakończyliśmy już konfigurację sieci
opisaną w rozdziale Konfiguracja sieci (w przeciwnym wypadku nasze
połączenie z Internetem będzie niemożliwe):
Listing 3.12: Prezglądanie dokumentacji znajdującej się online |
# links http://www.gentoo.org/doc/en/handbook/handbook-ppc.xml
|
Do pierwotnego okna terminala wracamy przyciskając Alt-F1.
Opcjonalnie: Uruchamianie demona SSH
Gdy zechcemy udostępnić dostęp do naszego komputera innym osobom podczas
instalacji Gentoo (np. w przypadku gdy takie osoby chcą Ci pomóc w instalacji,
bądź nawet zrobią to za Ciebie), należy utworzyć konto użytkownika dla nich
oraz przekazać im hasło dla konta root (tylko w przypadku gdy w
pełni ufamy tym osobom).
Aby uruchomić demona SSH, wykonujemy poniższe polecenie:
Listing 3.13: Uruchamianie demona SSH |
# /etc/init.d/sshd start
|
Aby używać demona sshd, w pierwszej kolejności należy skonfigurować sieć.
Więcej o konfiguracji sieci znajdziemy w rozdziale Konfiguracja sieci.
3. Konfigurowanie sieci
3.a. Automatyczne wykrywanie sieci
Może po prostu 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, polecenie /sbin/ifconfig
powinno wyświetlić oprócz lo także inne urządzenia, na przykład eth0:
Listing 1.1: Wynik /sbin/ifconfig przy poprawnej konfiguracji sieci |
# /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ą 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.
Listing 1.2: Definiowanie serwerów proxy |
# export http_proxy="http://proxy.gentoo.org:8080"
# export ftp_proxy="ftp://proxy.gentoo.org:8080"
# 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:
Listing 1.3: Dodawanie nazwy i hasła użytkownika do zmiennej |
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.
Listing 1.4: Testowanie sieci |
# ping -c 3 www.gentoo.org
|
Działa? Jeśli tak, można pominąć resztę tego rozdziału i bezpośrednio przejść do
przygotowania dysków. Jeśli nie, trzeba
będzie zapoznać się z dalszą częścią tego tekstu.
3.b. 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, pppoe-setup (dla użytkowników ASDL) albo pptp
(dla użytkowników PPTP - dostępne tylko dla architektury x86, amd64, alpha, ppc
oraz ppc64).
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.
Domyślnie: Używanie net-setup
Najprostszą metodą konfigurowania sieci (poza automatyczną) jest skorzystanie ze
skryptu net-setup:
Listing 2.1: Uruchamianie 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, pora zacząć instalację
Gentoo. Można pominąć resztę tego rozdziału i przejść 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 ppp nagranego na naszej płycie instalacyjnej. Skrypt
pppoe-setup służy do konfiguracji połączenia. Zostaniemy zapytani o
urządzenie sieciowe podłączone do modemu adsl, nazwę użytkownika i hasło oraz o
IP serwerów DNS i o to czy potrzebujemy podstawowego firewalla.
Listing 2.2: Używanie ppp |
# pppoe-setup
# pppoe-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:
Listing 2.3: Edytowanie /etc/ppp/chap-secrets |
# nano -w /etc/ppp/chap-secrets
|
Następnie konfigurujemy /etc/ppp/options.pptp:
Listing 2.4: Edytowanie /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:
Listing 2.5: Łączenie z serwerem dial-in |
# pptp <server ip>
|
Kolejny etap instalacji to przygotowywanie
dysków.
3.c. 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 pppoe-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:
Listing 3.1: Szukanie modułów |
# ls /lib/modules/`uname -r`/kernel/drivers/net
|
Gdy znajdziemy odpowiedni sterownik dla karty sieciowej, ładujemy go przy pomocy
polecenia modprobe:
Listing 3.2: Ładowanie modułów kernela za pmocą modprobe |
# modprobe pcnet32
|
Aby sprawdzić czy karta sieciowa została wykryta, korzystamy z polecenia
ifconfig. Prawidłowy rezultat powinien wyglądać mniej więcej tak:
Listing 3.3: Sprawdzanie dostępności karty sieciowej. Wynik pozytywny |
# 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:
Listing 3.4: Sprawdzanie dostępności karty sieciowej. Wynik negatywny |
# ifconfig eth0
eth0: error fetching interface information: Device not found
|
Jeżeli w komputerze znajduje się 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 tym 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 pppoe-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
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:
Listing 3.5: Używanie dhcpcd |
# dhcpcd eth0
# 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
Uwaga:
Program iwconfig dostępny jest wyłącznie na płytach instalacyjnych dla
architektur x86, amd64 oraz ppc. Opis instalacji dla pozostałych płyt znajduje
się na stronach
projektu linux-wlan-ng.
|
Jeśli używamy karty bezprzewodowej (802.11), musimy ją odpowiednio
skonfigurować. Aby poznać aktualne ustawienia skorzystamy z polecenia
iwconfig. Rezultat wygląda zwykle tak:
Listing 3.6: Wyświetlanie aktualnych ustawień interfejsów kart do połączeń bezprzewodowych |
# 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
|
Uwaga:
Nazwa urządzenia karty bezprzewodowej to wlan0 zamiast eth0.
Uruchomienie polecenia iwconfig bez dodatkowych parametrów pozwoli na
poznanie nazwy odpowiedniego urządzenia.
|
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, połączenie już
działa. Aby zmodyfikować ESSID lub dodać klucz WEP, skorzystamy z następujących
poleceń:
Uwaga:
Jeśli nasza sieć bezprzewodowa zabezpieczona jest kluczem WPA lub WPA2 będziemy
musieli użyć programu wpa_supplicant. Więcej informacji na ten temat
znajdziemy w rozdziale Konfiguracja sieci
bezprzewodowej podręcznika Gentoo Linux.
|
Listing 3.7: Modyfikowanie ESSID i/lub dodawanie klucza WEP |
# iwconfig eth0 essid GentooNode
# iwconfig eth0 key 1234123412341234abcd
# 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, zatytułowanym (Terminologia
sieciowa) lub wykorzystać omówiony wcześniej program net-setup.
Terminologia sieciowa
Uwaga:
Znając adres IP, broadcast, maskę sieciową i serwery nazw, można pominąć tę
część i od razu przejść do Używania ifconfig i
route.
|
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 konieczna. 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 address). 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:
Listing 3.8: Przykład adresu IP |
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.
Listing 3.9: Przykład oddzielenia sieci/hosta |
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.
Listing 3.10: Adres broadcast |
Adres IP: 192 168 0 2
11000000 10101000 00000000 00000010
Broadcast: 11000000 10101000 00000000 11111111
192 168 0 255
+--------------------------+--------+
Sieć Host
|
Aby "surfować" po Internecie, trzeba wiedzieć, który komputer udostępnia z nim
połączenie. Komputer ten nazywamy bramą. To zwykły komputer ze zwyczajnym
adresem IP (np. 172.168.0.1).
Wcześniej 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:
| Parametr |
Przykład |
| Adres IP |
192.168.0.2 |
| Maska |
255.255.255.0 |
| Broadcast |
192.168.0.255 |
| Brama |
192.168.0.1 |
| Serwer(y) nazw |
195.130.130.5, 195.130.130.133 |
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ą:
Listing 3.11: Używanie ifconfig |
# ifconfig eth0 ${IP_ADDR} broadcast ${BROADCAST} netmask ${NETMASK} up
|
Bramę ustawiamy poleceniem route. Wpis ${GATEWAY} należy zastąpić
jej adresem IP:
Listing 3.12: Używanie route |
# route add default gw ${GATEWAY}
|
Następnie otwieramy swoim ulubionym edytorem (w przykładzie skorzystamy z
nano) plik /etc/resolv.conf:
Listing 3.13: Tworzenie /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:
Listing 3.14: Przykładowy /etc/resolv.conf |
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
opiszemy proces podziału twardego dysku tak, aby jak najlepiej wykorzystać
dostępne miejsce.
Zaczniemy od omówienia urządzeń blokowych. Najpopularniejszym z nich
prawdopodobnie jest /dev/sda reprezentujący w Linuksie pierwszy
napęd. Napędy SATA i SCSI otrzymują nazwy z rodziny /dev/sd*.
Dzięki libata, nawet stare napędy IDE są nazywane /dev/sd*.
Urządzenie to dawniej nazywało się /dev/hda.
Urządzenia blokowe stanowią abstrakcyjny interfejs dysków. Programy użytkownika
mogą z nich korzystać nie martwiąc się o to czy napędy są typu IDE, SCSI czy
jakiegoś 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. Należy wybrać
schemat systemu plików, który najlepiej pasuje do systemu PowerPC.
Nowy Świat Apple
Nowy Świat maszyn Apple jest w zasadzie prosty do konfiguracji. Pierwszą
partycją zawsze jest Apple Partition Map. Znajduje się na niej schemat
podziału dysku. Następna partycja zawsze powinna być samoładowalna (bootstrap
partition). Zawiera ona mały (800kb) system plików HFS, który "trzyma" kopię
bootloadera Yaboot i jego plik konfiguracyjny. Partycja ta nie jest
tym samym, co partycja /boot. Po partycji rozruchowej zaczynają
się typowe i systemy plików, jak widać na schemacie poniżej. Partycja wymiany
jest tymczasowym miejscem przechowywania danych, kiedy system wykroczy poza
swoją fizyczną pamięć. Partycja główna zawiera system plików, na którym będzie
zainstalowane Gentoo. Jeśli chcemy mieć możliwość uruchomienia dwóch systemów,
partycja z OSX może być umiejscowiona w każdym innym miejscu po partycji
samoładowalnej, aby mieć pewność, że Yaboot uruchomi się jako pierwszy.
Uwaga:
Na dysku mogą znalźć się partycje "Disk Driver", takie jak
Apple_Driver63, Apple_Driver_ATA,
Apple_FWDriver, Apple_Driver_IOKit oraz
Apple_Patches. Są one używane w procesie uruchamiania MacOS, więc
jeśli nie nie będzie to potrzebne, można je śmiało usunąć poprzez opcję i
dla programu mac-fdisk. Spowoduje to kompletne usunięcie danych z dysku, więc
w razie wątpliwości lepiej pozwolić im tam być.
|
Uwaga:
Jeśli do podziału dysku został użyty Apple Disk Utility, może się okazać, że
jest 128MB przestrzeni pomiędzy partycjami, które Apple rezerwuje do "przyszłego
użycia". Można je bezpiecznie usunąć.
|
| Partycja |
Rozmiar |
System plików |
Opis |
| /dev/sda1 |
32k |
Brak |
Mapa Partycji Apple |
| /dev/sda2 |
800k |
HFS |
Apple Bootstrap |
| /dev/sda3 |
512Mb |
Swap |
Linuks Swap |
| /dev/sda4 |
Reszta dysku |
ext3, reiserfs, xfs |
Partycja główna |
Stary Świat Apple
Stary Świat maszyn Apple jest trochę bardziej skomplikowany w konfiguracji.
Pierwsza partycja zawsze jest Apple Partition Map. Zawiera ona schemat
podziału dysku. Poniższa konfiguracja dla BootX uwzględnia zainstalowany MacOS
na oddzielnym dysku. Będą również dodatkowe partycje dla "Apple Disk Drivers"
takie jak Apple_Driver63, Apple_Driver_ATA,
Apple_FWDriver, Apple_Driver_IOkit,
Apple_Patches oraz kopia MacOS. W przypadku używania Quick, będzie
potrzeba stworzenia partycji boot, na której będzie się znajdowało jądro. Za
partycją rozruchową powinien się znajdować typowy system plików, według schematu
poniżej. Partycja wymiany jest tymczasowym miejscem do przechowywania danych,
które wykroczyły fizyczną pamięć. Partycja główna powinna zawierać system
plików, na którym zostanie zainstalowane Gentoo.
Uwaga:
Jeśli w użyciu jest maszyna OldWorld, będzie potrzeba przechowania MacOS
dostępnego. Poniższy schemat uwzględnia zainstalowaną kopię MacOS na oddzielnym
dysku.
|
| Partycja |
Rozmiar |
System plików |
Opis |
| /dev/sda1 |
32k |
Brak |
Apple Partition Map |
| /dev/sda2 |
32Mb |
ext2 |
Quick Boot Partition (tylko quick) |
| /dev/sda3 |
512Mb |
Swp |
Partycja wymiany |
| /dev/sda4 |
Reszta dysku |
ext3, reiserfs, xfs |
Główna partycja |
Pegasos
IBM PowerPC Reference Platform (PReP) wymaga małej partycji PReP na pierwszym
miejscu na dysku. Dopiero po niej należy zakładać partycje wymiany i danych.
| Partycja |
Rozmiar |
System plików |
Opis |
| /dev/sda1 |
32Mb |
affs1 lub ext2 |
Partycja rozruchowa |
| /dev/sda2 |
512Mb |
Swap |
Partycja wymiany |
| /dev/sda3 |
Reszta dysku |
Ext3, reiserfs, xfs |
Partycja główna |
IBM PReP (RS/6000)
IBM PowerPC Peference Platform (PReP) wymaga małej, aby na pierwszym miejscu w
schemacie podziały dysku znalazła się mała partycja rozruchowa, a następnie
partycja wymiany oraz partycja główna.
| Partycja |
Rozmiar |
System plików |
Opis |
| /dev/sda1 |
800k |
Brak |
PReP Boot Partition (Typ 0x41) |
| /dev/sda2 |
512Mb |
Swap |
Partycja wymiany (Typ 0x82) |
| /dev/sda3 |
Reszta dysku |
ext3, reiserfs, xfs |
Partycja główna (Typ 0x83) |
Ostrzeżenie:
Program parted ma możliwość zmiany rozmiaru partycji (również HFS+).
Niestety wiąże się to z dużym ryzykiem w przypadku partycji HFS+ używających
księgowania, nawet jeśli zostanie ono wyłączone w Mac OS X. Wszystkie próby
zmiany rozmiaru partycji przy pomocy parted to spore ryzyko, należy więc
wykonać najpierw kopie zapasowe danych!
|
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 (Apple)
Aby utworzyć partycje skorzystamy z programu mac-fdisk:
Listing 3.1: Uruchamianie mac-fdisk |
# mac-fdisk /dev/sda
|
Jeśli do pozostawienia miejsca na dysku dla Linuksa było użyte narzędzie Apple
Disk Utility, należy najpierw usunąć partycje stworzone wcześniej. W tym celu
stosuje się opcję d w programie mac-fdisk. Aplikacja zapyta o
numer partycji, którą ma usunąć. Zwykle pierwsza partycja na maszynach NewWorld
(Apple_partition_map) nie może być w żaden sposób usunięta. Jeśli zamiarem jest
całkowite pozbycie się danych z dysku, należy użyć opcji i. Uwaga! Tej
opcji należy używać rozważnie!
Następnie (na komputerze NewWorld) założymy partycję Apple_bootstrap za
pomocą b. Zostaniemy zapytani o początkowy blok. Jeśli poprzednio
wybraliśmy na ten cel trzecią partycję, wpiszemy 3p.
Uwaga:
To nie jest partycja "boot". Nie jest nawet używana przez Linuksa; nie
potrzeba na niej miejsca do założenia systemu plików, nie powinno jej nawet
montować. Użytkownicy Apple nie potrzebują osobnej partycji rozruchowej.
|
Teraz stworzymy partycję wymiany za pomocą c. Program mac-fdisk
ponownie zapyta o blok początkowy. Jako, że wcześniej skorzystaliśmy z 2,
teraz wpiszemy 3p. 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 (obowiązkowo).
Na zakończenie zachowujemy zmiany i opuszczamy mac-fdisk poleceniami
w oraz q.
Uwaga:
Aby się upewnić, że wszystko zostało poprawnie wykonane, należy uruchomić
mac-fdisk jeszcze raz i sprawdzić czy są tam wszystkie nowo utworzone
partycje. Jeśli nie widać żadnych partycji lub też nie ma zmian, które przed
chwilą wprowadziliśmy, należy ponownie wprowadzić zmiany, przy pomocy klawisza
i. Należy zwrócić uwagę, że polecenie to usuwa wszystkie obecne partycje
i zastępuje je tymi odtworzonymi.
|
Następnie przechodzimy do paragrafu Zakładanie
systemów plików.
4.d. Alternatywnie: Podział dysku przy pomocy parted (Pegasos i RS/6000)
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:
Listing 4.1: Uruchamianie parted |
# parted /dev/sda
|
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, na początku urządzenia. 32MB powinny wystarczyć do
przechowania jądra MorphOS. Jeśli używamy Pegasos I lub planujemy użyć innego
systemu plików poza ext2 lub ext3, będzie również konieczne przechować jądro
linuksa na tej partycji (Pegasos II ma możliwość uruchomienia z partycji ext2,
ext3 i affs1). Aby stworzyć partycję należy uruchomić mkpart primary affs1
START END gdzie START i END są odpowiednio zamienione na
wartości w megabajtach. (np. 0 32) które utworzy partycję o rozmiarze
32MB, zaczynającą się w 0MB i kończącą w 32MB). Jeśli wybraliśmy ext2 lub ext3
jako system plików, wystarczy zamienić affs1 w poleceniu mkpart.
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). 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.
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
Do wyboru mamy kilka systemów plików. Ext2, ext3, XFS i ReiserFS są uważane za
stabilne na architekturze PPC. Pozostałe są eksperymentalne.
ext2 to sprawdzony i popularny linuksowy system plików, którego główną
wadą jest to, że nie posiada księgowania. Powoduje to, że 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. ext3
używa indeksu drzewa HTree, który zapewnia wysoką wydajność w prawie wszystkich
zastosowaniach. W skrócie, ext3 to bardzo dobry i niezawodny system plików.
ReiserFS to system plików z księgowaniem oparty na drzewie B+. Wykazuje
się doskonałą wydajnością przy obsłudze bardzo wielu małych plików (kosztem
zwiększonego obciążenia procesora). Nie jest tak aktywnie rozwijany jak inne
systemy plików.
XFS to system plików z księgowaniem metadanych, który został
zaprojektowany z myślą o skalowalności i nie posiada wielu dodatkowych
możliwości. Nie jest on również zbyt odporny na problemy sprzętowe.
Aktywacja partycji wymiany
mkswap jest poleceniem używanym do inicjacji partycji wymiany
Listing 5.1: Tworzenie sygnatury swap |
# mkswap /dev/sda3
|
Aby aktywować partycję wymiany, należy użyć polecenia swapon:
Listing 5.2: Aktywacja partycji wymiany |
# swapon /dev/sda3
|
Partycję wymiany należy stworzyć i aktywować zanim stworzymy kolejne systemy
plików.
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:
| System plików |
Program do zakładania |
| ext2 |
mke2fs |
| ext3 |
mke2fs -j |
| reiserfs |
mkreiserfs |
| xfs |
mkfs.xfs |
Na przykład, aby założyć ext3 na głównej partycji (w naszym przypadku
/dev/sda4), należy wykonać następujące polecenia:
Listing 5.3: Zakładanie systemu plików na partycji |
# mke2fs -j /dev/sda4
|
Teraz założymy systemy plików na partycjach, które wcześniej utworzyliśmy.
Ważne:
Jeśli na partycji głównej (/ ma być ReiserFS, nie wolno zmieniać
domyślnego rozmiaru bloku jeśli jednocześnie wybiera się program yaboot
jako program ładujący w rozdziale Konfigurowanie
bootloadera.
|
Uwaga:
Na maszynach Pegasos II kernel musi znajdować się na systemach plików ext2,
ext3 lub affs1. Maszyny NewWorld można uruchomić z ext2, ext3, ReiserFS, a
nawet z HFS/HFS+.
|
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.
Listing 6.1: Montowanie partycji |
# mount /dev/sda4 /mnt/gentoo
|
Uwaga:
Jeżeli chcemy przenieść /tmp na oddzielną partycję,
nie można zapomnieć po zamontowaniu odpowiednio poprawić praw dostępu: chmod
1777 /mnt/gentoo/tmp. Dotyczy to również /var/tmp.
|
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:
Listing 1.1: Sprawdzenie daty/czasu |
# 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:
Listing 1.2: Ustawienie daty/czasu UTC |
# date 032916212005
|
Podejmowanie decyzji
W następnym kroku należy wykonać instalację wybranego tarballa stage3.
Można go pobrać z Internetu lub, jeśli działamy z którejś płyty Gentoo
Universal CD lub LiveDVD, przekopiować z CD. Jeżeli mamy Universal CD lub
LiveDVD 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.
Polecenie uname -m pozwala na zdecydowanie jaki plik stage jest
potrzebny.
W odróżnieniu od LiveDVD, płyty Minimal CD i LiveCD nie zawierają żadnych plików
stage3.
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):
Listing 2.1: Przechodzenie do punktu montowania systemu plików 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:
Listing 2.2: Ustawienie informacji o proxy dla lynxa |
# 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 katalogu releases/ppc/2008.0/. Powinniśmy
tam zobaczyć wszystkie dostępne pliki stage, dla naszej architektury (mogą one
znajdować się w podkatalogach). Wybieramy jeden i wciskamy klawisz D,
aby ściągnąć plik. Kiedy ściągniemy plik, wciskamy Q, aby
wyjść z przeglądarki.
Listing 2.3: Przeglądanie listy serwerów lustrzanych za pomocą links |
# links http://www.gentoo.org/main/en/mirrors.xml
# links -http-proxy serwer.proxy.com:8080 http://www.gentoo.org/main/en/mirrors.xml
|
Wybranie pliku stage3 jest konieczne, nie wspieramy już instalacji za pomocą
stage 1 i 2.
Jeśli chcemy zweryfikować poprawność pobranych archiwów stage, musimy porównać
wynik polecenia md5sum z sumami MD5 udostępnianymi na serwerze.
Listing 2.4: Sprawdzanie integralności archiwum stage |
# md5sum -c stage3-ppc-2008.0.tar.bz2.DIGESTS
stage3-ppc-2008.0.tar.bz2: OK
|
Rozpakowywanie tarballa Stage
Wypakowujemy pobrany plik stage przy pomocy programu tar:
Listing 2.5: Wypakowanie stage |
# tar xvjpf stage3-*.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 Universal CD
Rozpakowanie tarballa stage
Pliki stage umieszczone są na CD w katalogu /mnt/cdrom/stages. Aby
obejrzeć ich spis korzystamy z polecenia ls:
Listing 3.1: Lista dostępnych wersji stage |
# ls /mnt/cdrom/stages
|
Jeśli system zgłasza błąd to możliwe, że musimy najpierw zamontować CD-ROM:
Listing 3.2: Montowanie 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):
Listing 3.3: Zmiana katalogu na /mnt/gentoo |
# cd /mnt/gentoo
|
Następnie wypakowujemy wybrany tarball. Użyjemy do tego celu programu
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>-2008.0.tar.bz2. Oczywiście jego
nazwę należy odpowiednio zmodyfikować.
Listing 3.4: Wypakowanie tarballa stage |
# tar xvjpf /mnt/cdrom/stages/stage3-<architektura>-2008.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):
Listing 4.1: Przechodzenie do punktu montowania 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
(portage-latest.tar.bz2) poprzez jego wybranie i naciśnięcie
klawisza D.
Listing 4.2: Przeglądanie listy mirrorów Gentoo |
# links http://www.gentoo.org/main/en/mirrors.xml
|
Teraz wychodzimy z przeglądarki naciskając klawisz Q. Plik znajduje się
w katalogu /mnt/gentoo.
Jeśli chcemy sprawdzić poprawność ściągniętego pliku, należy użyć md5sum
i porównać sumę kontrolną pliku z podaną na serwerze lustrzanym.
Listing 4.3: Sprawdzanie poprawności pliku |
# md5sum -c portage-latest.tar.bz2.md5sum
portage-latest.tar.bz2: OK
|
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.
Listing 4.4: Wypakowywanie snapshota Portage |
# tar xvjf /mnt/gentoo/portage-latest.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ę.
Uwaga:
Opatrzona komentarzami lista wszystkich możliwych zmiennych znajduje się
w pliku /mnt/gentoo/etc/make.conf.example. Do szczęśliwego
ukończenia instalacji wystarczy wyedytowanie tylko kilku z nich, tych, których
listę przedstawiamy poniżej.
|
Uruchamiamy ulubiony edytor (w przykładach używamy nano),
którym wprowadzimy omawiane nieco dalej opcje optymalizacji.
Listing 5.1: Edytowanie /etc/make.conf |
# 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 określa architekturę, na jakiej będzie budowany system i powinna
już być ustawiona na odpowiednią wartość. Nie wolno jej
zmieniać, ponieważ może to zepsuć system. Jeśli w zmiennej CHOST
znajduje się nieprawidłowa wartość, najprawdopodobniej oznacza to, że użyto
złego archiwum stage3.
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= lub
-mcpu=, która określa docelową architekturę. Możliwe jej wartości są
opisane jako komentarze w make.conf.example.
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). Zalecanym ustawieniem jest -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). Flaga ta
nie ma wpływu na generowany kod.
Dodatkowo możemy użyć flagi -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. Domyślne wartości znajdujące się w pliku stage3 powinny być
wystarczające. Poniższe wartości są jedynie przykładem:
Listing 5.2: Definiowanie zmiennych CFLAGS i CXXFLAGS |
CFLAGS="-O2 -mcpu=powerpc -mtune=powerpc -fno-strict-aliasing -pipe"
CXXFLAGS="${CFLAGS}"
|
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.
Listing 5.3: MAKEOPTS dla przeciętnego systemu jednoprocesorowego |
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
Opcjonalnie: Wybieranie serwerów lustrzanych
Aby móc szybko ściągać źródła programów, należy wybrać szybki serwer lustrzany.
Portage używa serwerów zawartych w zmiennej GENTOO_MIRRORS, która znajduje się
w pliku make.conf. Aby wybrać najlepsze serwery, należy wejść na
stronę listy serwerów lustrzanych Gentoo
i wybrać z nich te, które znajdują się najbliżej lub użyć narzędzia
mirrorselect, które potrafi w prosty sposób automatycznie wybrać
najlepsze serwery lustrzane.
Listing 1.1: Sposób użycia programu mirrorselect |
# mirrorselect -i -o >> /mnt/gentoo/etc/make.conf
|
Ostrzeżenie:
Nie należy wybierać żadnych serwerów IPv6. Nasze pliki stage aktualnie nie
wspierają IPv6.
|
Następną ważną sprawą jest ustawienie zmiennej SYNC w pliku
make.conf. Zmienna ta wskazuje na serwer rsync, z którego będzie
uaktualniane drzewo Portage (kolekcja ebuildów, czyli skryptów które zawierają
wszystkie informacje potrzebne do ściągnięcia i zainstalowania programów).
Można ręcznie wpisać serwer, którego chcemy używać lub skorzystać z programu
mirrorselect:
Listing 1.2: Wybór serwera rsync za pomocą programu mirrorselect |
# mirrorselect -i -r -o >> /mnt/gentoo/etc/make.conf
|
Po konfiguracji plików za pomocą programu mirrorselect należy sprawdzić
czy wszystko zostało prawidłowo dopisane do pliku
/mnt/gentoo/etc/make.conf.
Kopiowanie informacji o DNS
Zanim zmienimy środowisko pracy, musimy wykonać pewną bardzo ważną czynność.
Jest nią przekopiowanie ustawień DNS z pliku /etc/resolv.conf do
nowego środowiska. Jest to konieczne, by sieć działała także tam. Plik
/etc/resolv.conf określa jakie serwery nazw będą używane dla
sieci.
Listing 1.3: Kopiowanie informacji o DNS |
# cp -L /etc/resolv.conf /mnt/gentoo/etc/
|
Montowanie systemów plików /proc i /dev
Następnie 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.
Listing 1.4: Montowanie /proc i /dev |
# mount -t proc none /mnt/gentoo/proc
# mount -o bind /dev /mnt/gentoo/dev
|
Zmiana środowiska
Teraz, gdy wszystkie partycje są już założone, a podstawowe środowisko
zainstalowane, nadszedł czas wejścia do niego poprzez chroot. Oznacza to
przejście z systemu instalacyjnego (płyty instalacyjnej lub innego medium) do
systemu instalowanego (czyli na założone partycje).
Przechodzenie odbywa sie w trzech etapach. Najpierw zamieniamy katalog
z / (w systemie 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.
Listing 1.5: Zmiana środowiska poprzez chroot |
# chroot /mnt/gentoo /bin/bash
# env-update
>> Regenerating /etc/ld.so.cache...
# source /etc/profile
# export PS1="(chroot) $PS1"
|
Gratulacje! Znajdujemy się wewnątrz nowego systemu Gentoo Linux. Oczywiście do
końca jeszcze daleko, przecież zostało jeszcze kilka rozdziałów Podręcznika do
przeczytania. :-)
6.b. Konfiguracja Portage
Aktualizacja drzewa Portage
Aktualizujemy drzewo Portage za pomocą polecenia emerge --sync.
Listing 2.1: Aktualizowanie drzewa Portage |
# emerge --sync
# emerge --sync --quiet
|
Portage używa protokołu RSYNC do uaktualniania drzewa pakietów. Jeżeli powyższe
polecenie zakończy się niepowodzeniem (np. z winy firewalla) używamy polecenia
emerge-webrsync, które ściąga i instaluje drzewo Portage przy za pomocą
protokołu HTTP.
Jeśli otrzymamy ostrzeżenie, że dostępna jest nowa wersja programu Portage i
należy dokonać jego aktualizacji, należy to natychmiast zrobić. Dokonuje się
tego poleceniem emerge --oneshot portage.
Wybór odpowiedniego profilu
Najpierw mała definicja.
Profil jest szablonem budowy systemu Gentoo. Nie tylko określa domyślne
wartości dla CHOST, CFLAGS i innych ważnych zmiennych, ale również ogranicza
wersje pakietów jakie mogą zostać zainstalowane w systemie. Wszystkie te
informacje są konfigurowane przez deweloperów Gentoo.
Poprzednio profil taki był niemodyfikowalny przez użytkownika. Jednak może się
nadarzyć taka okoliczność, w której zmiana profilu będzie potrzebna.
Aktualnie używany profil można sprawdzić za pomocą poniższego polecenia:
Listing 2.2: Sprawdzanie profilu systemowego |
# ls -FGg /etc/make.profile
lrwxrwxrwx 1 48 Apr 8 18:51 /etc/make.profile -> ../usr/portage/profiles/default/linux/ppc/ppc32/2008.0
|
Domyślny profil jest profilem bazującym na systemie z jądrem serii 2.6. Jest to
zalecane ustawienie chociaż mamy możliwość wyboru innego profilu.
Istnieją również podprofile desktop oraz server dla niektórych
architektur. Należy przejrzeć katalog profilu 2008.0/, aby
przekonać się czy podprofile dostępne są dla architektury używanej przez nas.
Oczywiście możemy przejrzeć plik make.defaults profilu
desktop, aby sprawdzić czy odpowiada on naszym potrzebom.
W katalogu /usr/portage/profiles/ znajduje się wiele różnych
profili dla różnych architektur. Warto przejrzeć te dostępne dla używanej
architektury i sprawdzić czy któryś z nich będzie wygodniejszy niż ten domyślny.
Listing 2.3: Zmiana profilu |
# ln -snf /usr/portage/profiles/<nazwa> /etc/make.profile
|
Uwaga:
Podprofil o nazwie developer przeznaczony jest do zadań mających na celu
rozwój systemu Gentoo Linux. Nie jest on przeznaczony do konfiguracji
ogólnego środowiska dla rozwoju jakiejkolwiek aplikacji.
|
Konfiguracja zmiennych 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żemy
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 definiujemy 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
(należy zwrócić uwagę na znak minusa z przodu). Ustawienie gnome gtk -kde
-qt3 -qt4 zaowocuje wsparciem dla GNOME (oraz gtk), ale nie dla KDE (i
związanym z nim ściśle qt), znakomicie przygotowując grunt pod GNOME.
Domyślny zestaw flag USE znajduje się w pliku make.defaults
wybranego profilu. Wszystkie pliki make.defaults znajdują się w
katalogu wskazywanym przez dowiązanie /etc/make.profile oraz w
katalogach nadrzędnych. 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 chcemy coś z niej usunąć wpisujemy wybraną flagę ze znakiem minus na
początku. Nie wolno zmieniać plików wewnątrz katalogu
/etc/make.profile, zmiany zostaną nadpisane przy następnej
aktualizacji drzewa Portage.
Pełny opis USE znajduje się w drugiej części Podręcznika Gentoo, w
rozdziale Flagi USE. Kompletną
charakterystykę dostępnych flag USE znajdziemy w pliku
/usr/portage/profiles/use.desc.
Listing 2.4: Przegląd dostępnych flag USE |
# less /usr/portage/profiles/use.desc
|
Jako przykład przedstawimy flagi USE dla systemu bazującego na KDE ze
wsparciem dla DVD, ALSA i nagrywania CD:
Listing 2.5: Edytowanie /etc/make.conf |
# nano -w /etc/make.conf
|
Listing 2.6: Ustawienia USE |
USE="-gtk -gnome qt3 qt4 kde dvd alsa cdr"
|
Opcjonalnie: Lokalizacje GLIBC
Zwykle w systemie używa się tylko jednej, góra dwóch lokalizacji. Można je
wybrać w pliku /etc/locale.gen.
Listing 2.7: Otwieranie pliku /etc/locale.gen |
# nano -w /etc/locale.gen
|
Poniższy przykład to lokalizacje polskie oraz angielskie (Ameryka) z obsługą
kodowania znaków (jak UTF-8).
Listing 2.8: Ustawianie lokalizacji |
en_US ISO-8859-1
en_US.UTF-8 UTF-8
pl_PL ISO-8859-2
pl_PL.UTF-8 UTF-8
|
Następnie należy uruchomić polecenie locale-gen, które utworzy wszystkie
lokalizacje wybrane w pliku /etc/locale.gen.
Kolejny etap instalacji to Konfigurowanie
jądra.
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 kopiujemy ją do
pliku /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.
Listing 1.1: Konfiguracja strefy czasowej |
# ls /usr/share/zoneinfo
# cp /usr/share/zoneinfo/Europe/Warsaw /etc/localtime
|
7.b. Instalacja źródeł jądra
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ę na liście jąder Gentoo.
Dla architektury PPC polecamy jądra gentoo-sources, które pochodzi z
serii 2.6.
Listing 2.1: Instalowanie źródeł jądra |
# 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.24-r5. W komputerze użytkownika
może być to inna wersja, dlatego należy mieć to na uwadze.
Listing 2.2: Podgląd dowiązania do źródeł kernela |
# ls -l /usr/src/linux
lrwxrwxrwx 1 root root 22 Mar 18 16:23 /usr/src/linux -> linux-2.6.24-gentoo-r5
|
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
zainstalowanie 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żne 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.
Kiedy już zbierzemy wszystkie informacje przechodzimy do katalogu ze
źródłami i konfigurujemy jądro. Proponujemy zacząć od stworzenia jądra, które
zadziała na większości 32-bitowych komputerach klasy PowerPC. Wykonujemy
polecenie make pmac32_defconfig. Później można uruchomić oparty na
ncurses interfejs (make menuconfig) i dostosować ustawienia do
konkretnego przypadku.
Listing 3.1: Uruchamianie menuconfig |
# cd /usr/src/linux
# make pmac32_deconfig
# 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ń
Najpierw 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. Należy się upewnić, że włączyliśmy wsparcie dla
partycji Amigi jeśli używamy Pegasosa lub partycji Macintosha jeśli używamy
komputera Apple.
Listing 3.2: Wybór potrzebnych systemów plików |
File systems --->
Pseudo Filesystems --->
[*] /proc file system support
[*] Virtual memory file system support (former shm fs)
Partition Types --->
[*] Advanced partition support
[*] Amiga partition table support
[*] Macintosh partition map support
<*> Reiserfs support
<*> Ext3 journalling file system support
<*> Second extended fs support
<*> XFS filesystem support
|
Użytkownicy maszyn NewWorld i OldWorld będą zapewne chieli obsługę HFS.
Użytkownicy OldWorld potrzebują tego do kopiowania skompilowanego kernela na
partycję MacOS, zaś użytkownicy NewWorld do konfiguracji specjalnej partycji
Apple_bootstrap.
Listing 3.3: Aktywacja HFS |
File Systems --->
Miscellaneous filesystems --->
<M> Apple Macintosh file system support
<M> Apple Extended HFS file system 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:
Listing 3.4: Sterowniki niezbędne dla użytkowników PPPoE |
Device Drivers --->
Network device 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 ppp do
pracy w trybie jądra PPPoE.
Należy pamiętać aby aktywować również sterownik dla karty sieciowej. Większość
nowych komputerów Apple używa sterownika SunGEM. Starsze komputery zazwyczaj
używają sterownika BMAC.
Listing 3.5: Wybór sterownika karty sieciowej |
Device Drivers --->
Network device support --->
Ethernet (10 or 100Mbit) --->
[*] Ethernet (10 or 100Mbit)
<*> Generic Media Independent Interface device support
<*> MACE (Power Mac ethernet) support
<*> BMAC (G3 ethernet) support
<*> Sun GEM 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.
Listing 3.6: Upewnianie się, że wyłączono wywłaszczanie |
Kernel options --->
Preemption Model
(X) No Forced Preemption (Server)
(X) Voluntary Kernel Preemption (Desktop)
|
Jeśli komputer uruchamiany jest poprzez Firewire, potrzebne będzie włączenie
poniższych opcji. Można użyć w tym celu modułów.
Listing 3.7: Włączenie wsparcia dla urzadzeń firewire podczas bootowania |
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.
Listing 3.8: Włączenie wsparcia dla urządzeń USB podczas bootowania |
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
Open Firmware. Dla kart ATI należy wybrać odpowiedni bufor ramki w zależności od
posiadanego chipsetu karty (Mach64, Rage128 or Radeon).
Listing 3.9: Wybieranie sterownika bufora ramki |
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
|
Uwaga:
Jeśli włączy się więcej niż jeden sterownik to przy uruchamianiu może zostać
wybrany niewłaściwy z nich. Należy zatem powstrzymać się od wybierania większej
ilości urządzeń bufora ramki lub wybrać to najbardziej pożądane za pomocą opcji
linii video=radeonfb podczas rozruchu systemu.
|
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 menu programu konfiguracyjnego i wpisujemy następujące polecenia:
Listing 3.10: Kompilowanie kernela. |
# make && make modules_install
|
Kiedy jądro skończy się kompilować kopiujemy jego obraz do katalogu
/boot, jak pokazano poniżej. Jeśli korzystamy z BootX, obraz
będziemy kopiować nieco później.
Yaboot i BootX wymagają użycia nieskompresowanego jądra. Jego nazwa to vmlinux
i znajduje się on w katalogu /usr/src/linux po zakończeniu
kompilacji. Firmware Pegasosa wymaga skompresowanego jądra o nazwie
zImage.chrp, można je znaleźć w katalogu
/usr/src/linux/arch/ppc/boot/images.
Listing 3.11: Instalowanie kernela |
# cd /usr/src/linux
# cp vmlinux /boot/kernel-2.6.24-gentoo-r5
# cp arch/powerpc/boot/images/zImage /boot/kernel-2.6.24-gentoo-r5
|
Następnie przechodzimy do opisu instalacji
dodatkowych modułów jądra.
7.d. Alternatywnie: użycie 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ć:
Listing 4.1: Emergowanie genkernela |
# emerge genkernel
|
Następnie kopiujemy konfigurację jądra z płyty instalacyjnej do miejsca, w
którym znajdzie ją i wykorzysta genkernel:
Listing 4.2: Kopiowanie konfiguracji jądra z płyty instalacyjnej |
# 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.
Przed kompilacją źródeł, musimy dokonać paru poprawek w fstab. Pozostała część
tego pliku zostanie uzupełniona później więc nie należy się teraz tym
przejmować. Jeżeli nie stworzyliśmy oddzielnej partycji boot (NIE bootstrap,
jest to zupełnie co innego), należy usunąć wpis odnoszący się do
/boot z /etc/fstab. Krok ten będziemy musieli wykonać
na większości komputerów.
Listing 4.3: Usuwanie wpisu /boot z /etc/fstab na komputerach bez partycji boot |
# nano -w /etc/fstab
/dev/BOOT /boot ext2 noauto,noatime 1 2
|
Ź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 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.
Listing 4.4: Uruchamianie genkernel |
# genkernel all
|
Listing 4.5: Na Pegasosach |
# 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.
Listing 4.6: Sprawdzanie nazw utworzonych plików jądra |
# ls /boot/kernel-genkernel-ppc-2.6.24-gentoo-r5 /boot/initramfs-genkernel-ppc-2.6.24-gentoo-r5
|
Kolejny etap instalacji to instalacja dodatkowych
modułów jądra.
7.e. Moduły jądra
Konfiguracja modułów jądra
Moduły ładowane w czasie startu systemu muszą zostać dopisane do pliku
/etc/modules.autoload.d/kernel-2.6. Można tu również dodać
dodatkowe opcje ich ładowania.
Żeby przejrzeć listę wszystkich dostępnych modułów, użyjemy polecenia
find. Należy zastąpić wpis "wersja" wersją używanego jądra.
Listing 5.1: Znajdowanie dostępnych modułów |
# find /lib/modules/<kernel version>/ -type f -iname '*.o' -or -iname '*.ko' | less
|
Dla przykładu, aby załadować moduł 3c59x.o, należy edytować plik
kernel-2.6 i dodać tam jego nazwę.
Listing 5.2: Zmiany w /etc/modules.autoload.d/kernel-2.6 |
# nano -w /etc/modules.autoload.d/kernel-2.6
|
Listing 5.3: /etc/modules.autoload.d/kernel-2.6 |
3c59x
|
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
Plik /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 należy 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 należy wpisać 1, natomiast dla pozostałych
2 (lub 0 jeśli kontrola nie jest konieczna).
Ważne:
Domyślny /etc/fstab dostarczany przez Gentoo nie jest
poprawnym plikiem fstab, uruchamiamy więc nano (lub inny edytor) i
tworzymy własny plik /etc/fstab:
|
Listing 1.1: Tworzenie /etc/fstab |
# nano -w /etc/fstab
|
Dodajemy regułki, które odpowiadają naszemu schematowi podziału oraz linie dla
napędu CD-ROM i innych dysków, jeśli są zainstalowane w komputerze.
Następnie używamy poniższego przykładu do stworzenia pliku
/etc/fstab:
Uwaga:
Pomiędzy komputerami PPC występują duże różnice. Dlatego należy zmienić
poniższy przykład tak, aby pasował do konkretnej sytuacji.
|
Listing 1.2: Plik /etc/fstab |
/dev/sda4 / ext3 noatime 0 1
/dev/sda3 none swap sw 0 0
/dev/cdrom /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.
Aby zwiększyć wydajność, należy dodać opcję noatime do parametrów
montowania. Dzięki temu można skrócić czas dostępu do partycji i znacznie
przyspieszyć system. Opcja ta powoduje, że czasy dostępu nie będą zapisywane. Ta
informacja nie jest do niczego potrzebna większości użytkowników.
Sprawdzamy ponownie /etc/fstab, zapisujemy zmiany i zamykamy plik.
8.b. Konfiguracja sieci
Nazwa hosta, nazwa domeny 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.
Listing 2.1: Konfiguracja nazwy hosta |
# nano -w /etc/conf.d/hostname
HOSTNAME="tux"
|
Następnie, jeśli potrzebujemy ustawić nazwę domeny, dokonujemy tego w
pliku /etc/conf.d/net. Ustawienie to jest nam potrzebne jedynie w
przypadku gdy nasz dostawca internetu lub administrator sieci zaleci nam takie
działanie. Również w przypadku gdy posiadamy serwer DNS, a nie posiadamy
serwera DHCP, ustawienie nazwy domeny będzie wymagane. Nie musimy się martwić o
ustawienia DNS lub nazw domen, jeśli nasza sieć korzysta z ustawień za pomocą
DHCP.
Listing 2.2: Ustawianie nazwy domeny |
# nano -w /etc/conf.d/net
dns_domain_lo="homenetwork"
|
Uwaga:
Jeżeli nie ustawimy nazwy domeny, możemy pozbyć się wiadomości "This is
hostname.(none)" na ekranie logowania poprzez edycję pliku
/etc/issue. Powinniśmy wykasować wpis .\O z tego pliku.
|
W przypadku posiadania domeny NIS (jeżeli nie wiemy co to jest, zapewne jej nie
posiadamy) będziemy musieli również ją zdefiniować:
Listing 2.3: Ustawianie nazwy domeny NIS |
# nano -w /etc/conf.d/net
nis_domain_lo="my-nisdomain"
|
Uwaga:
Więcej informacji na temat konfiguracji DNS i NIS znajdziemy w przykładach
znajdujących się w pliku /etc/conf.d/net.example. Przydatnym może
okazać się również program openresolv, który pomoże zarządzać
naszą konfiguracją DNS/NIS.
|
Konfiguracja sieci
Zanim powiemy "Hej, przecież już to zrobiliśmy!" należy pamiętać, że to co
ustawialiśmy na początku instalacji jest przeznaczone tylko na jej potrzeby.
Teraz ostatecznie skonfigurujemy sieć dla instalowanego systemu Gentoo.
Uwaga:
Szczegółowe informacje dotyczące zagadnień sieciowych, takich jak bonding,
bridging, VLAN czy 802.11q, znajdują się w rozdziale dotyczącym Konfiguracji sieci.
|
Wszystkie ustawienia dotyczące sieci znajdują się w
/etc/conf.d/net. Mają prostą, ale niekoniecznie intuicyjną
składnię. Nie ma czego się obawiać, wszystko zostanie wyjaśnione. 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. Nie zwalnia to ich jednak z konieczności zainstalowania
klienta DHCP. Wszystko na ten temat znajduje się w rozdziale Instalowanie narzędzi
systemowych.
Jeśli jednak zajdzie potrzeba dokonfigurowania 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):
Listing 2.4: Otwieranie /etc/conf.d/net do edycji |
# nano -w /etc/conf.d/net
|
Znajduje się tam następujący wpis:
Listing 2.5: Domyślny /etc/conf.d/net |
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, edytujemy obie zmienne,
config_eth i routes_eth0:
Listing 2.6: Ręczne ustawianie informacji o IP dla eth0 |
config_eth0=( "192.168.0.2 netmask 255.255.255.0 brd 192.168.0.255" )
routes_eth0=( "default via 192.168.0.1" )
|
Dla DHCP wystarczy skonfigurować config_eth0 w następujący sposób:
Listing 2.7: Automatyczne pobieranie adresu IP dla eth0 |
config_eth0=( "dhcp" )
|
Powtarzamy powyższe instrukcje dla pozostałych interfejsów sieciowych
(odpowiednio config_eth1, config_eth2).
Lista dostępnych ustawień znajduje się w pliku
/etc/conf.d/net.example. Warto również przeczytać stronę man
używanego klienta DHCP i zapoznać się z jego ustawieniami.
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.
Listing 2.8: Dodawanie net.eth0 do domyślnego poziomu uruchamiania |
# 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:
Listing 2.9: Tworzenie dodatkowych skryptów startowych |
# cd /etc/init.d
# ln -s net.lo 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. Możemy tutaj również umieścić komputery z naszej
sieci jeżeli nie będziemy chcieli konfigurować wewnętrznego serwera DNS.
Listing 2.10: Otwieranie /etc/hosts |
# nano -w /etc/hosts
|
Listing 2.11: Wpisywanie informacji o sieci |
127.0.0.1 localhost
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-utils.
Listing 2.12: Instalacja pcmcia-utils |
# emerge pcmcia-utils
|
8.c. Konfiguracja systemu
Hasło superużytkownika
Hasło roota zmieniamy poleceniem:
Listing 3.1: Ustawienie hasła superużytkownika |
# passwd
|
Informacje o systemie
Do najbardziej podstawowych ustawień Gentoo używa pliku
/etc/rc.conf. Otwieramy go i zapoznajemy się z umieszczonymi w nim
komentarzami. :)
Listing 3.2: Otwieranie /etc/rc.conf |
# 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ń.
Listing 3.3: Otwieranie /etc/conf.d/keymaps |
# 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.
Uwaga:
PPC w większości przypadków korzysta z map klawiszy takich jak x86.
Użytkownicy, którzy chcą używać map klawiszy ADB muszą włączyć "ADB keycode
sendings" w jądrze i ustawić mac/ppc w pliku /etc/conf.d/keymaps.
|
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.
Listing 3.4: Otwieranie /etc/conf.d/clock |
# 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ą.
Należy zdefiniować poprzednio skopiowaną do pliku /etc/localtime
strefę czasową, tak aby przy kolejnych aktualizacjach pakietu
sys-libs/timezone-data, automatycznie aktualizowany był również plik
/etc/localtime. Na przykład by ustawić strefę czasową dla Warszawy,
do pliku dodaje się wpis TIMEZONE="Europe/Warsaw".
Po ukończeniu edycji zapisujemy zmiany i zamykamy edytor.
Teraz należy przejść do instalacji narzędzi
systemowych.
9. Instalowanie narzędzi systemowych
9.a. Program logujący
W archiwum stage3 brakuje kilka ważnych programów, gdyż kilka pakietów spełnia
te same funkcje, a my nie chcemy dokonywać ich wyboru w imieniu użytkownika.
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:
Listing 1.1: Instalacja programu logującego |
# 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).
Gentoo oferuje trzy różne demony crona: dcron, fcron oraz
vixie-cron. Instalacja każdego z nich jest analogiczna do instalacji
programu logującego, jednakże dcron i frcon wymagają dodatkowej
konfiguracji (wykonywanej przez polecenie: crontab /etc/crontab).
Niezdecydowanym polecamy program vixie-cron.
Dla instalacji bez sieci dostarczamy tylko vixie-cron. Aby używać innego
demona cron, trzeba będzie poczekać i zainstalować go później.
Listing 2.1: Instalacja demona cron |
# emerge vixie-cron
# rc-update add vixie-cron default
# crontab /etc/crontab
|
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.
Listing 3.1: Instalacja 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). Należy mieć na uwadzę, że narzędzie
do zarządzania partycjami ext2/ext3 (e2fsprogs) są już zainstalowane w
systemie.
W poniższej tabeli przedstawiono narzędzia, których należy użyć dla
poszczególnych używanych systemów plików:
| System plików |
Narzędzie |
Polecenie instalujące |
| XFS |
xfsprogs |
emerge xfsprogs |
| ReiserFS |
reiserfsprogs |
emerge reiserfsprogs |
| JFS |
jfsutils |
emerge jfsutils |
Użytkownicy EVMS powinni zainstalować pakiet evms:
Listing 4.1: Instalacja narzędzi EVMS |
# USE="-gtk" emerge evms
|
Parametr USE="-gtk" spowoduje, że nie zostaną zainstalowane wszystkie
zależności. Aby w przyszłości skorzystać z graficznych nakładek na evms należy
przebudować ten pakiet bez tej flagi.
Opcjonalnie: Narzędzia RAID dla komputerów IBM
Użytkownicy SCSI RAID na systemach opartych na POWER-5 powinni rozważyć
instalację pakietu iprutils, dzięki któremu możliwe będą operacje na
macierzach dysków RAID, takie jak pobieranie ich statusu oraz uaktualnianie
mikrokodu.
Listing 4.2: Instalowanie iprutils |
# emerge iprutils
|
9.e. Narzędzia sieciowe
Jeżeli nie potrzebujemy żadnych dodatkowych narzędzi związanych z siecią (takich
jak na przykład ppp czy klient dhcp) należy przejść do rozdziału Konfiguracja Bootloadera
Opcjonalnie: Instalowanie klienta DHCP
Jeżeli chcemy, aby Gentoo automatycznie uzyskiwało adres IP karty sieciowej,
musimy zainstalować dhcpcd (lub jakiegokolwiek innego klienta DHCP -
opis w Modularna praca w sieci).
Jeżeli nie zrobi się tego teraz, połączenie sieciowe może nie działać po
zakończeniu instalacji!
Listing 5.1: Instalacja dhcpcd |
# emerge dhcpcd
|
Opcjonalnie: Instalacja klienta PPPoE
Jeśli do łączenia się z siecią potrzeba nam ppp, należy zainstalować
wymagane narzędzia.
Listing 5.2: Instalacja klienta PPPoE |
# emerge ppp
|
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 zainstalowanie programu
bootcreator, aby możliwe było stworzenie bootmenu SmartFirmware.
10.b. Domyślnie: Używanie yaboot
Wprowadzenie
Ważne:
yaboot może być używany tylko na komputerach NewWorld Apple lub IBM!
|
W celu prawidłowego zlokalizowania urządzenia bootowalnego, yaboot potrzebuje
dostępu do plików urządzeń utworzonych przez udev przy starcie systemu oraz do
systemu plików sysfs. Systemy te znajdują się w katalogach /dev i
/sys. Aby były dostępne w instalowanym systemie, trzeba je
podmontować również tam. Jeśli są już tam zamontowane, można pominąć ten krok.
Listing 2.1: Dowiązywanie systemu plików /dev i /sys |
# exit
# 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.
Uwaga:
W przypadku gdy do wygenerowania jądra użyto programu genkernel, konieczna
będzie ręczna edycja pliku yaboot.conf, nawet jeśli wykorzystano
yabootconfig. Sekcja obrazu jądra powinna zostać zmodyfikowana w
następujący sposób:
|
Listing 2.2: Dodawanie argumentów właściwych dla jąder wygenerowanych programem genkernel do yaboot.conf |
image=/boot/kernel-genkernel-ppc2.6.24-gentoo-r5
label=Linux
root=/dev/ram0
partition=3
initrd=/boot/initramfs-genkernel-ppc-2.6.24-gentoo-r5
append="real_root=/dev/sda3 init=/linuxrc"
read-only
|
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.
Korzystanie z yabootconfig jest możliwe tylko wtedy, gdy na dysku
znajduje się partycja Apple_Bootstrap, a plik /etc/fstab zawiera
wszystkie partycje linuksowe (partycja Bootstrap nie powinna znajdować się w
pliku fstab). Możliwe, że to już kolejny raz gdy wykonuje się te czynności
podczas instalacji, ale mimo wszystko zalecamy sprawdzenie
/etc/fstab raz jeszcze.
Listing 2.3: Instalowanie yaboota |
# emerge yaboot
|
Następnie opuszczamy chroot i wykonujemy polecenie yabootconfig --chroot
/mnt/gentoo. Zostaniemy poproszeni o potwierdzenie lokalizacji partycji
Apple_Bootstrap. Jeśli korzysta się z domyślnego układu partycji, to będzie to
/dev/sda2. Należy wcisnąć klawisz Y jeśli jest ona poprawna. Jeśli
nie, musimy sprawdzić plik /etc/fstab i upewnić się, że ścieżki do
urządzeń są prawidłowe. Gdy partycja bootstrap zostanie wybrana,
yabootconfig przeskanuje ustawienia systemowe, utworzy plik
/etc/yaboot.conf i uruchomi mkofboot. mkofboot jest
programem, który formatuje partycję Apple_Bootstrap i umieszcza na niej plik
konfiguracyjny yaboota. Gdy operacje te zostaną wykonane powracamy do środowiska
chrootowanego.
Listing 2.4: Powrót do 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. Teraz po każdej modyfikacji pliku haboot.conf należy uruchomić
ybin -v.
Po wykonaniu tych operacji, kontynuujemy instalację zgodnie z instrukcjami w
podrozdziale Ponowne uruchomienie systemu.
Alternatywnie: Ręczna konfiguracja yaboot
Po pierwsze należy zainstalować yaboot:
Listing 2.5: Instalowanie yaboot |
# emerge yaboot
|
Poniżej znajduje się przykładowy plik yaboot.conf. Konieczna jest
jego modyfikacja w celu dopasowania do wymagań systemu i użytkownika.
Listing 2.6: /etc/yaboot.conf |
boot=/dev/sda2
device=hd:
delay=5
defaultos=macosx
timeout=30
install=/usr/lib/yaboot/yaboot
magicboot=/usr/lib/yaboot/ofboot
image=/boot/kernel-2.6.24-gentoo-r5
label=Linux
root=/dev/sda3
partition=3
read-only
macos=/dev/sda13
macosx=/dev/sda12
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.
Listing 2.7: Ustawianie partycji bootstrap |
# mkofboot -v
|
Więcej informacji o yaboot uzyskać można na stronie projektu yaboot. Po
skonfigurowaniu bootloadera kontynuujemy instalację zgodnie z instrukcjami w
podrozdziale Ponowne uruchomienie systemu.
10.c. Alternatywnie: BootX
Ważne:
BootX może być używany tylko na systemach OldWorld Apple z zainstalowanym
systemem MacOS 9 lub wcześniejszym!
|
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).
Listing 3.1: Kopiowanie jądra na partycję MacOS-a |
# 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/kernel-2.6.24-gentoo-r5"
|
Jeśli użyto programu genkernel, to zarówno jądro, jak i initrd muszą zostać
skopiowane na partycję MacOS-a.
Listing 3.2: Kopiowanie jądra i initrd wygenerowanych genkernelem na partycję MacOS-a |
# exit
cdimage ~# mkdir /mnt/mac
cdimage ~# mount /dev/sda6 /mnt/mac -t hfs
cdimage ~# cp /mnt/gentoo/boot/kernel-genkernel-ppc-2.6.24-gentoo-r5 "/mnt/mac/System Folder/Linux Kernels"
cdimage ~# cp /mnt/gentoo/boot/initramfs-genkernel-ppc-2.6.24-gentoo-r5 "/mnt/mac/System Folder"
|
Gdy jądro zostało skopiowane, musimy ponownie uruchomić komputer i skonfigurować
BootX.
Listing 3.3: Odmontowywanie wszystkich partycji i rebootowanie |
cdimage ~# cd /
cdimage ~# umount /mnt/gentoo/proc /mnt/gentoo/dev /mnt/gentoo/sys /mnt/gentoo /mnt/mac
cdimage ~# reboot
|
Oczywiście należy usunąć bootowalną płytę CD, 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.
Ważne:
Należy upewnić się, że w jądro wkompilowaliśmy wsparcie dla systemów HFS i
HFS+. W przeciwnym wypadku nie będziemy mogli zaktualizować lub zmienić jądra
znajdującego się na partycji MacOS.
|
Następnie jeszcze raz restartujemy komputer, uruchamiamy Linuksa i kontynuujemy
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:
Listing 4.1: Emergowanie 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.
Listing 4.2: Konfigurowanie quik.conf |
# Przykładowy plik quik.conf
init-message = "Gentoo 2008.0\n"
partition = 2
root = /dev/sda4
timeout = 30
default = gentoo
image = /vmlinux
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.
Listing 4.3: Przenoszenie quik.conf do /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.
Listing 4.4: Ustawianie zmiennych związanych z bootowaniem |
# nvsetenv auto-boot true
# nvsetenv output-device video
# nvsetenv input-device kbd
# nvsetenv boot-device scsi/sd@1:0
# nvsetenv boot-device ata/ata-disk@0:0
# nvsetenv boot-file /boot/kernel-2.6.24-gentoo-r5 root=/dev/sda4
#
# nvsetenv boot-command boot
|
Uwaga:
Możliwa jest także modyfikacja zmiennych związanych z bootowaniem z poziomu
MacOS-a. W zależności od posiadanego modelu należy użyć bootvars
lub .
Apple System Disk. Warto odwiedzić powyższą stronę quirks w celu
uzyskania szerszych informacji na ten temat.
|
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.
Uwaga:
Jeśli coś poszło nie tak, możemy zresetować PRAM do ustawień domyślnych poprzez
kombinację command + option + p + r, przed uruchomieniem naszego
komputera. Wyczyści to wartości jakie ustawiliśmy przy pomocy programu
nvsetenv i powinno umożliwić uruchomienie zarówno z bootowalnej płyty
MacOS-a jak i z płyty instalacyjnej Linuksa.
|
Kolejnym krokiem jest Ponowne uruchomienie systemu.
10.e. Alternatywnie: BootCreator
Ważne:
BootCreator stworzy menu bootowania SmartFirmware napisane dla komputerów
Pegasos.
|
Po pierwsze, upewnijmy się, że mamy zainstalowany program bootcreator:
Listing 5.1: Instalowanie programu bootcreator |
# emerge bootcreator
|
Teraz przekopiujmy plik /etc/bootmenu.example do
/etc/bootmenu i zmodyfikujmy go, aby odpowiadał naszym potrzebom:
Listing 5.2: Edycja pliku configuracyjnego programu bootcreator |
# cp /etc/bootmenu.example /etc/bootmenu
# nano -w /etc/bootmenu
|
Poniżej znajduje się przykładowy plik /etc/bootmenu. Nazwy
vmlinux oraz initrd powinny zostać zastąpione nazwami naszego jądra
oraz pliku initrd.
Listing 5.3: Plik konfiguracyjny programu bootcreator |
[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 (Normal)
de:0 kernel-2.6.24-gentoo-r5 video=radeonfb:1024x768@70 root=/dev/sda3
[SECTION]
Local HD -> Genkernel (Normal)
ide:0 kernel-genkernel-ppc-2.6.24-gentoo-r5 root=/dev/ram0 real_root=/dev/sda3 init=/linuxrc
initrd=initramfs-genkernel-ppc2.6.24-gentoo-r5
|
Następnie musimy skopiować plik bootmenu na partycję
boot, aby SmartFirmware mógł go odczytać. Użyjemy do tego programu
bootcreator:
Listing 5.4: Instalowanie bootmenu |
# bootcreator /etc/bootmenu /boot/menu
|
Uwaga:
W czasie rebootowania musimy upewnić się, że menu jest plikiem,
który zostanie załadowany jako domyślny.
|
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.
Listing 6.1: Opuszczanie chroot, odmontowywanie partycji i rebootowanie |
# exit
livecd ~# umount /mnt/gentoo/proc /mnt/gentoo/dev /mnt/gentoo/sys /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:
| Grupa |
Opis |
| audio |
Dostęp do urządzeń audio |
| cdrom |
Bezpośredni dostęp do urządzeń optycznych |
| floppy |
Bezpośredni dostęp do stacji dyskietek |
| games |
Możliwość uruchomienia gier |
| portage |
Daje możliwość korzystania z polecenie emerge --pretend przez
zwykłego użytkownika.
|
| usb |
Dostęp do urządzeń USB |
| plugdev |
Umożliwia montowanie i używanie przenośnych urządzeń takich jak pamięci
podręczne USB czy aparaty fotograficzne.
|
| video |
Możliwość dostępu do urządzeń wideo oraz pracy z akceleracją sprzętową
|
| wheel |
możliwość używania polecenia su
|
Na przykład, aby utworzyć konto użytkownika mkay i dodać go do grup
wheel (możliwość korzystajania 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:
Listing 1.1: Dodawanie użytkownika do codziennej pracy |
Login: root
Password:
# useradd mkay -m -G users,wheel,audio -s /bin/bash
# passwd mkay
Password:
Re-enter password:
|
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. Porządkowanie dysku
Usuwanie archiwów
Po zakończeniu instalacji i ponownym, poprawnym uruchomieniu systemu możemy
usunąć ściągnięty plik stage3 oraz migawkę Portage z naszego dysku. Należy
pamiętać, że znajdują się one w katalogu root (/).
Listing 2.1: Usuwanie archiwum stage3 |
# rm /stage3-*.tar.bz2*
|
Listing 2.2: Usuwanie migawki Portage |
# rm /portage-latest.tar.bz2*
|
12. I co dalej?
12.a. Dokumentacja
Gratulacje! Mamy już 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ówione w niej zostały 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
subskrypcji 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. :)
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ć:
Listing 1.1: Czytanie man emerge |
$ 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:
Listing 2.1: Uaktualnianie drzewa Portage |
# 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.
Listing 2.2: Uruchamianie emerge-webrsync |
# 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:
Listing 3.1: Wyszukiwane pakietów z 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).
Listing 3.2: Wyszukiwanie wszystkich związanych z pdf paczek |
$ 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ć.
Listing 3.3: Przykładowy wynik polecenia emerge --search |
* 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:
Listing 3.4: Instalacja 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:
Listing 3.5: Udajemy, że chcemy zainstalować gnumeric |
# 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:
Listing 3.6: Pobieranie kodu źródłowego gnumeric |
# 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>.
Listing 3.7: Sprawdzenie czy pakiet używa flagi doc. |
# 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.
Listing 3.8: Lokalizowanie dokumentacji pakietu |
# 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
# 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
|
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.
Listing 3.9: Usuwanie gnumeric z systemu |
# 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ć.
Listing 3.10: Uaktualnianie systemu |
# 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:
Listing 3.11: Uaktualnienie całego systemu |
# 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:
Listing 3.12: Przeprowadzenie pełnego uaktualnienia |
# 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ń:
Listing 3.13: Usuwanie osieroconych zeleżności |
# 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.
Listing 3.14: Instalacja pakietu gentoolkit |
# 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
Listing 4.1: Ostrzeżenie przed blokadą pakietu w Portage (z opcją --pretend) |
[blocks B ] mail-mta/ssmtp (is blocking mail-mta/postfix-2.2.2-r1)
|
Listing 4.2: Ostrzeżenie Portage przed blokadą pakietu (bez opcji --pretend) |
!!! 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
Listing 4.3: Ostrzeżenie Portage o zamaskowanych pakietach |
!!! all ebuilds that could satisfy "bootsplash" have been masked.
|
Listing 4.4: Ostrzeżenie Portage o zamaskowanych pakietach - z podaniem przyczyny |
!!! 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
Listing 4.5: Komunikat Portage o brakujących zależnościach |
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
Listing 4.6: Ostrzeżenie Portage dotyczące niejasnych nazw pakietów |
!!! 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
Listing 4.7: Ostrzeżenie Portage na temat wzajemnie od siebie zależnych pakietów |
!!! 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
Listing 4.8: Komunikat Portage o nieudanym pobieraniu |
!!! 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
Listing 4.9: Ostrzeżenie Portage dotyczące pakietu chronionego profilem systemowym |
!!! 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:
Listing 4.10: Błąd sprawdzania sumy kontrolnej |
>>> 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.
Ważne:
Nie znaczy to, że aktualizację trzeba przeprowadzać kilka razy! Zgodnie
z zapisem w polityce serwerów rsync (w czasie gdy uruchamiamy polecenie
emerge --sync) użytkownik, który zbyt często aktualizuje drzewo zostanie
zbanowany! Lepiej jest poczekać do następnej zaplanowanej aktualizacji niż
niepotrzebnie obciążać serwery rsync.
|
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:
Listing 2.1: Skumulowana zmienna USE dla profilu 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:
Listing 2.2: Przykładowe ustawienia zmiennej USE w pliku /etc/make.conf |
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ć:
Listing 2.3: Przykład /etc/portage/package.use |
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:
Listing 2.4: 2 przykład /etc/portage/package.use |
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.
Listing 2.5: Używanie USE jako zmiennej środowiskowej |
# 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):
-
Domyślne ustawienia zmiennej USE znajdujące się w pliku
make.defaults będącym częścią wybranego profilu
-
Zdefiniowana przez użytkownika zmienna USE znajdująca się w pliku
/etc/make.conf
-
Zdefiniowana przez użytkownika zmienna USE w pliku
/etc/portage/package.use
-
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.
Listing 2.6: Wykonywanie polecenia emerge --info |
# 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.
Listing 2.7: Rekompilacja systemu |
# 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.
Ostrzeżenie:
Uruchomienie emerge --depclean jest niebezpieczną operacją i powinno być
wykonywane z zachowaniem pełnej ostrożności. Należy dwukrotnie sprawdzić listę
"nieaktualnych" pakietów i upewnić się, że Portage nie chce usunąć czegoś
ważnego. W poniższym przykładzie dodajemy opcję -p, która wyświetli listę
pakietów do usunięcia, bez ich usuwania.
|
Listing 2.8: Usuwanie niepotrzebnych pakietów |
# 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.
Listing 2.9: Uruchomienie revdep-rebuild |
# 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:
Listing 3.1: Przeglądanie używanych flag USE: |
# 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:
Listing 3.2: Instalacja gentoolkit |
# emerge gentoolkit
|
Następnie uruchamiamy equery z argumentem uses aby przejrzeć flagi
USE dla konkretnego pakietu. Dla przykładu sprawdźmy pakiet
gnumeric:
Listing 3.3: Użycie equery do przeglądania użytych flag USE: |
# 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:
Listing 1.1: Warto zajrzeć na stronę man pliku 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:
Listing 1.2: Sprawdzanie czy FEATURES są już ustawione |
$ 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".
Listing 2.1: Instalacja Distcc |
# 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):
Listing 2.2: Użycie trzech serwerów DistCC |
# 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:
Listing 2.3: Uruchamianie demona distcc |
# 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:
Listing 3.1: Instalacja ccache |
# 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".
Listing 3.2: Zmiana CCACHE_SIZE w /etc/make.conf |
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:
Listing 3.3: Przeglądanie statystyk ccache |
# 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.
Listing 3.4: Edytowanie .bash_profile |
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:
Listing 4.1: Konfiguracja zmiennej PORTAGE_BINHOST w pliku /etc/make.conf |
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:
Listing 4.2: Instalacja prekompilowanego gnumeric |
# emerge --usepkg --getbinpkg gnumeric
|
Więcej informacji o prekompilowanych pakietach znajduje się na stronie man
programu emerge.
Listing 4.3: Strona 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:
Listing 1.1: Inicjacja systemu w /etc/inittab |
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:
Listing 1.2: Kontynuacja procesu uruchamiania systemu |
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:
Listing 1.3: Linia initdefault |
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).
Listing 1.4: Definicja poziomów działania |
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.
Listing 1.5: Definicja konsol wirtualnych |
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:
Listing 1.6: Uruchamianie Postfixa |
# /etc/init.d/postfix start
|
Uwaga:
Wyłączane lub przeładowywane są tylko te usługi,, które tego wymagają. Inne,
które są powiązane z przeładowywaną usługą, jeśli nie ma takiej potrzeby, nie
są restartowane.
|
Aby wyłączyć daną usługę pozostawiając przy życiu usługi z nią powiązane należy
użyć argumentu pause:
Listing 1.7: Wyłączanie Postfixa, zachowując włączone powiązane z nim usługi |
# /etc/init.d/postfix pause
|
Aby zobaczyć jaki status ma aktualnie dana usługa (włączony, wyłączony...)
trzeba użyć argumentu status:
Listing 1.8: Informacje o statusie postfixa |
# /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.
Listing 1.9: Uaktualnienie informacji o statusie postfixa |
# /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.
Listing 1.10: Zapytanie o listę usług niezbędnych do działania Postfixa |
# /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):
Listing 1.11: Zapytanie o listę usług, które wymagają Postfixa |
# /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.
Listing 1.12: Zapytanie o listę brakujących usług powiązanych z Postfixem |
# /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:
Listing 2.1: Usuwanie Postfixa z poziomu default |
# 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:
Listing 2.2: Informacje o dostępnych skryptach init |
# 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:
Listing 3.1: Zmienna zdefiniowana w pliku /etc/conf.d/apache2 |
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.
Listing 4.1: Szablon skryptu init |
#!/sbin/runscript
depend() {
}
start() {
}
stop() {
}
restart() {
}
|
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.
Listing 4.2: Zależności Postfixa |
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:
Listing 4.3: Funkcja depend() 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.
Listing 4.4: Uruchamianie skryptu init jako pierwszego w poziomie działania |
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:
Listing 4.5: Przykładowa funkcja depend() |
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:
Listing 4.6: Przykład funkcji start() |
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.
Uwaga:
Należy się upewnić, że parametr --exec wywołuje usługę, a nie skrypt
bash, który po uruchomieniu tej usługi wyłącza sie. Tak zachowują się skrypty
init.
|
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ć:
Listing 4.7: Przykładowa funkcja stop() |
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:
Listing 4.8: Usługa, która uruchamia skrypt 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:
Listing 4.9: Uruchamianie manuala dla start-stop-daemon |
$ 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:
Listing 4.10: Dodanie opcji restartdelay |
opts="${opts} restartdelay"
restartdelay() {
stop()
sleep 3
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:
Listing 5.1: Tworzenie katalogu poziomu działania |
# 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:
Listing 5.2: Dodawanie potrzebnych skryptów startowych |
# cd /etc/runlevels/default
# for service in *; do rc-update add $service offline; done
# rc-update del net.eth0 offline
# rc-update show offline
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.
Listing 5.3: Wyłączanie usług przy pomocy pliku /etc/conf.d/rc |
RC_COLDPLUG="yes"
RC_PLUG_SERVICES="!net.eth0"
|
Uwaga:
Aby dowiedzieć się więcej na ten temat, należy przeczytać komentarze znajdujące
się wewnątrz pliku /etc/conf.d/rc.
|
Teraz należy wyedytować pliki konfiguracyjne bootloadera i dodać wpis dla
poziomu działania offline. Dla przykładu w
/boot/grub/grub.conf:
Listing 5.4: Dodawanie wpisu dla poziomu działania offline |
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ą.
| Zmienna |
Opis |
| PATH |
Ta zmienna zawiera oddzieloną dwukropkami listę katalogów, w których system
operacyjny szuka plików z prawami do uruchomienia. Jeśli w konsoli wpiszesz
nazwę programu mającego prawa do uruchamiania (np. ls,
rc-update lub emerge) lecz program ten nie znajduje się w
jednym z katalogów zdefiniowanych w zmiennej PATH, system nie wykona
tego programu (chyba, że wpiszesz pełną ścieżkę do miejsca gdzie znajduje się
ten program, np. /bin/ls).
|
| ROOTPATH |
Ta zmienna spełnia prawie taką samą funkcję jak PATH, z tą tylko
różnicą, że zawiera informacje o katalogach które są sprawdzane w
poszukiwaniu programów dla superużytkownika (czyli root'a).
|
| LDPATH |
Zmienna zawiera podzieloną dwukropkami listę katalogów, które konsolidator
przeszukuje w celu odnalezienia bibliotek.
|
| MANPATH |
Zmienna, podobnie jak inne zawiera listę katalogów oddzielonych dwukropkiem,
w których man szukał będzie dokumentów w odpowiednim dla siebie
formacie.
|
| INFODIR |
Zmienna ta, to lista katalogów oddzielona znakiem dwukropka, które
przeszukiwane są przez program info w celu odnalezienia dokumentacji w
odpowiednim dla niego formacie.
|
| PAGER |
Zmienna zawiera ścieżkę do programu, który służy do prezentacji zawartości
plików (przykładowo less lub more)
|
| EDITOR |
Zmienna zawiera ścieżkę do programu używanego do edycji plików (przykładowo
nano lub vi) |
| KDEDIRS |
Zmienna zawiera listę oddzielonych znakiem dwukropka katalogów, w których
mieszczą się materiały związane z środowiskiem graficznym KDE.
|
| CONFIG_PROTECT |
Zmienna ta zawiera listę oddzielonych znakiem spacji katalogów, które
mają być zabezpieczone przez Portage w trakcie dokonywania uaktualnień
oprogramowania.
|
| CONFIG_PROTECT_MASK |
Zmienna zawiera listę oddzielonych znakiem spacji katalogów, które nie
mają być zabezpieczane przez Portage podczas dokonywania uaktualnienia
oprogramowania.
|
Poniżej znajdują się przykładowe wartości omówionych zmiennych środowiskowych:
Listing 1.1: Przykładowe wartości zmiennych |
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:
Listing 2.1: /etc/env.d/05gcc |
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:
Listing 2.2: /etc/env.d/99local |
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.
Listing 2.3: Kolejność w jakiej env-update uaktualnia zmienne |
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:
Listing 2.4: Uaktualnianie zmiennych środowiskowych |
# env-update && source /etc/profile
|
Uwaga:
Powyższe polecenie uaktualnia zmienne tylko na terminalu, na którym zostało
uruchomione i jego terminalach potomnych. W związku z tym jeśli pracuje się w
X11 należy albo wpisywać source /etc/profile w każdym terminalu, który
się otwiera albo zrestartować serwer X tak żeby wszystkie nowe terminale
posiadały nowe zmienne. Użytkownicy menedżerów logowania powinni przełączyć się
na konto roota i wpisać /etc/init.d/xdm restart. Jeśli się tego nie zrobi
to konieczne będzie przelogowanie się w X by uruchamiać terminale potomne z
nowymi zmiennymi.
|
Ważne:
Przy definiowaniu zmiennych nie możemy używać innych zmiennych obecnych w
powłoce. Oznacza to, że zapis FOO="$BAR" (gdzie $BAR jest inną
zmienną) jest zabroniony.
|
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ę:
Listing 3.1: Definicja lokalnej zmiennej PATH w pliku ~/.bashrc |
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ę.
Listing 3.2: Definiowanie zmiennych środowiskowych dla bieżącej sesji |
# 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:
Listing 1.1: Czytanie strony man dla 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.
Listing 1.2: Czytanie stron man Portage i pliku 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"
Ważne:
Jeżeli używaliśmy enotice z Portage-2.0.*, musimy go całkowicie usunąć
gdyż nie jest on kompatybilny z elog.
|
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:
Listing 1.1: Wywoływanie man make.conf |
$ 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:
Listing 3.1: Znajdowanie aktualnego ustawienie zmiennej CONFIG_PROTECT |
$ emerge --info | grep 'CONFIG_PROTECT='
|
Więcej informacji na temat ochrony plików konfiguracyjnych w Portage znajduje
się na stronie man emerge.
Listing 3.2: Więcej informacji nt. ochrony plików konfiguracyjnych w Portage |
$ 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:
Listing 4.1: Więcej informacji o mirrorselect |
# 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:
Listing 6.1: Więcej informacji o 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:
Listing 1.1: Ustawianie zmiennej ACCEPT_KEYWORDS |
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:
Listing 2.1: /etc/portage/package.keywords - ostateczna wersja ustawienia dla 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:
Listing 2.2: Włączanie konkretnej wersji testowej gnumerica |
=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:
Listing 3.1: /etc/portage/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:
Listing 3.2: Przykładowy wpis do /etc/portage/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.
Listing 1.1: Uruchamianie dispatch-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.
Listing 1.2: Czytanie manuala dispatch-conf |
$ 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.
Listing 2.1: Uruchamianie etc-update |
# 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:
Listing 2.2: Opcje etc-update |
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:
Listing 2.3: Oddzielne uaktualnienie wybranego pliku |
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:
Listing 2.4: Komendy dostępne podczas interaktywnej edycji plikó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:
Listing 3.1: Przykład użycia quickpkg |
# 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.
Listing 1.1: Definiowanie pliku z pominiętymi pakietami w make.conf |
PORTAGE_RSYNC_EXTRA_OPTS="--exclude-from=/etc/portage/rsync_excludes"
|
Listing 1.2: Wyłączanie wszystkich gier w pliku /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:
Listing 2.1: Użycie gensync do aktutalizacji repozytoriów |
# 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:
Listing 3.1: Przykładowa linijka dla pliku package.provided |
sys-kernel/gentoo-sources-2.6.11.6
|
D. Konfiguracja sieci w Gentoo
1. Wprowadzenie
1.a. Początek
Uwaga:
Ten dokument zakłada, że jądro zostało poprawnie skonfigurowane, że prawidłowo
zainstalowano również jego moduły dla sprzętu oraz, że znana jest nazwa
interfejsu sprzętowego. Zakłada się również, że konfigurowane jest eth0,
ale może to być również eth1, wlan0, etc.
|
Uwaga:
Przy pisaniu dokumentu zakładamy, że jest zainstalowany
baselayout-1.11.11 lub nowszy.
|
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.
Listing 1.1: Tworzenie połączenia symbolicznego między net.eth0 i net.lo |
# 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.
Listing 1.2: Przykłady dla /etc/conf.d/net |
config_eth0=( "dhcp" )
config_eth0=( "192.168.0.7/24" )
routes_eth0=( "default via 192.168.0.1" )
config_eth0=( "192.168.0.7 netmask 255.255.255.0" )
routes_eth0=( "default via 192.168.0.1" )
|
Uwaga:
Jeżeli nie zostanie określona konfiguracja dla interfejsu, zakłada się że użyte
zostanie DHCP.
|
Uwaga:
CIDR oznacza Classless InterDomain Routing. Początkowo adresy IPv4 były
podzielone na klasy A, B lub C. Klasyfikacja ta nie przewidywała takiego wzrostu
popularności Internetu i teraz stoi przed obliczem utraty unikalnych adresów IP.
CIDR pozwala użyć jednego schematu adresowania w celu użycia jednego adresu IP
do reprezentowania wielu adresów. Adres IP w notacji CIDR wygląda jak zwykły
adres IP, z tą różnicą, że kończy się ukośnikiem za którym znajduje się liczba.
Dla przykładu, 192.168.0.0/16. CIDR jest dokładnie opisany w RFC 1519.
|
Teraz, gdy interfejs został już skonfigurowany, można go uruchomić i zatrzymać
używając poleceń znajdujących się poniżej.
Listing 1.3: Uruchamianie i zatrzymywanie sieci przy pomocy skryptów startowych |
# /etc/init.d/net.eth0 start
# /etc/init.d/net.eth0 stop
|
Ważne:
W przypadku problemów z siecią, zaleca się ustawienie zmiennej
RC_VERBOSE="yes" w /etc/conf.d/rc, aby uzyskać więcej
informacji na temat tego, co się dzieje.
|
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.
Listing 1.4: Konfiguracja interfejsu sieciowego, aby uruchamiał się przy starcie systemu |
# 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ń.
| Polecenie |
Opis |
| null |
Nie robi nic |
| noop |
Jeżeli urządzenie działa i jest przypisany adres, zakończy pomyślnie
konfigurację.
|
| adres IPv4 lub IPv6 |
Dodaje wskazany adres do interfejsu |
|
dhcp, adsl lub apipa
(lub dowolne polecenie pochodzące z modułu producenta)
|
Uruchamia moduł, który posiada dane polecenie. Dla przykładu, dhcp
uruchomi moduł, który zapewnia DHCP i który może być którymś z grupy
dhcpcd, dhclient lub pump.
|
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.
Listing 1.1: Przykłady konfiguracji |
config_eth0=(
"192.168.0.2/24"
"192.168.0.3/24"
"192.168.0.4/24"
)
config_eth0=(
"192.168.0.2/24"
"4321:0:1:2:3:4:567:89ab"
"4321:0:1:2:3:4:567:89ac"
)
config_eth0=(
"noop"
"dhcp"
)
fallback_eth0=(
"null"
"apipa"
)
|
Uwaga:
Przy używaniu modułu ifconfig oraz dodawaniu więcej niż jednego adresu
zostają utworzone aliasy dla każdego dodatkowego adresu. Wobec tego, powyższe
dwa przykłady utworzą interfejsy eth0, eth0:1 oraz eth0:2.
Nie można nic specjalnego z tymi interfejsami zrobić, gdyż jądro oraz programy
będą traktować interfejsy eth0:1 oraz eth0:2 jako eth0.
|
Ważne:
Kolejność zapasowej konfiguracji jest bardzo ważna! Gdyby polecenie null
nie zostało zdefiniowane, to polecenie apipa zostałoby wykonane tylko w
przypadku gdyby polecenie noop nie powiodło się.
|
Uwaga:
APIPA oraz
DHCP będą omawiane później.
|
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.
| Wartość |
Opis |
| none |
Zakłada, że usługa sieci net jest zawsze włączona |
| no |
Oznacza, że co najmniej jedna usługa sieciowa net.* prócz
net.lo musi być włączona. Opcja ta może być używana przez
właścicieli komputerów przenośnych z kartami wifi oraz zwykłymi kartami
sieciowymi, w których powinno być uruchomione jednocześnie tylko jedno
urządzenie.
|
| lo |
Działa podobnie jak opcja no, z tą różnicą, że net.lo
również jest wliczane. Jest to szczególnie przydatne dla osób, którym nie
robi różnicy czy uruchamia się jakiekolwiek urządzenie sieciowe.
|
| yes |
Ta opcja oznacza, że WSZYSTKIE urządzenia sieciowe MUSZĄ być uruchomione,
aby można było uznać usługę net za działającą.
|
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
Listing 2.1: Zależność net.br0 w /etc/conf.d/net |
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:
Listing 3.1: przykład nazewnictwa zmiennej |
dns_domain_My____NET="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.
Uwaga:
Wszystkie omówione w tym rozdziale ustawienia powinny być wpisane do pliku
/etc/conf.d/net, chyba, że zaznaczymy inaczej.
|
Listing 1.1: Ustawienia modułów |
modules=( "iproute2" )
modules_eth0=( "pump" )
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.
Listing 2.1: Aby zainstalować iproute2 |
# emerge sys-apps/iproute2
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.
Listing 2.2: Przykłady dla ifconfig oraz iproute2 |
config_eth0=( "192.168.0.2/24" )
config_eth0=( "192.168.0.2 netmask 255.255.255.0" )
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.
| Moduł DHCP |
Pakiet |
Zalety |
Wady |
| dhclient |
net-misc/dhcp |
Stworzone przez ISC, te same osoby które stworzyły BIND DNS
Bardzo konfigurowalne.
|
Konfiguracja jest bardzo skomplikowana, oprogramowanie jest dość duże,
nie można otrzymać serwerów NTP z DHCP i domyślnie nie jest wysyłana nazwa
hosta.
|
| dhcpcd |
net-misc/dhcpcd |
Przez długi czas jako domyślny w Gentoo, nie związany z zewnętrznymi
narzędziami, aktywnie rozwijany przez Gentoo
|
Bywa powolny, nie zawsze potrafi przejść w tryb demona |
| pump |
net-misc/pump |
Niewielkie rozmiary, nie związany z zewnętrznymi narzędziami
|
Brak wsparcia ze strony twórców, źle działa przy połączeniach
modemowych, nie można otrzymać serwerów NIS z DHCP
|
| udhcpc |
net-misc/udhcp |
Niewielkie rozmiary - najmniejszy dostępny klient dhcpd, stworzony dla
systemów wbudowanych
|
Żadna dystrybucja nie używa go jako domyślnego, nie można ustawić czasu
wygaśnięcia dłuższego niż 3 sekundy
|
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
Listing 3.1: Przykładowa konfiguracja DHCP w /etc/conf.d/net |
modules=( "dhcpcd" )
config_eth0=( "dhcp" )
dhcpcd_eth0="-t 10"
dhcp_eth0="release nodns nontp nonis"
|
Uwaga:
dhcpcd, udhcpc oraz pump domyślnie wysyłają aktualną nazwę
hosta do serwera DHCP wobec czego nie trzeba tego definiować.
|
3.d. ADSL z PPPoE/PPPoA
Na początek należy zainstalować oprogramowanie do ADSL-a.
Listing 4.1: Instalacja pakietu ppp |
# emerge net-dialup/ppp
|
Uwaga:
Jeżeli potrzebujemy PPPoA należy się upewnić, że używamy
>=baselayout-1.12.x.
|
Następnie, tworzymy skrypt internetowy PPP oraz skrypt dla interfejsu
sieciowego, który będzie używał PPP.
Listing 4.2: Tworzenie skryptu PPP oraz sieciowego |
# 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.
Listing 4.3: Podstawowa konfiguracja PPPoE |
config_eth0=( null )
config_ppp0=( "ppp" )
link_ppp0="eth0"
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.
Listing 4.4: Przykładowy plik /etc/ppp/pap-secrets |
"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.
Ważne:
Powinniśmy uważnie przeczytać sekcje dotyczące ADSL i PPP znajdujące się w
pliku /etc/conf.d/net.example. Zawarte są tam bardziej szczegółowe
wyjaśnienia opcji PPP, których zapewne będziemy potrzebować.
|
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.
Listing 5.1: Konfiguracja APIPA w /etc/conf.d/net |
config_eth0=( "dhcp" )
fallback_eth0=( "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.
Listing 6.1: Konfiguracja łączenia w /etc/conf.d/net |
slaves_bond0="eth0 eth1 eth2"
config_bond0=( "null" )
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.
Listing 7.1: Konfiguracja mostka w /etc/conf.d/net |
brctl_br0=( "setfd 0" "sethello 0" "stp off" )
bridge_br0="eth0 eth1"
config_eth0=( "null" )
config_eth1=( "null" )
config_br0=( "192.168.0.1/24" )
depend_br0() {
need net.eth0 net.eth1
}
|
Ważne:
Aby korzystać z niektórych ustawień mostków, warto zajrzeć do dokumentacji
opisującej nazwy zmiennych.
|
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.
Listing 8.1: Przykład zmiany adresu MAC |
mac_eth0="00:11:22:33:44:55"
mac_eth0="random-ending"
mac_eth0="random-samekind"
mac_eth0="random-anykind"
mac_eth0="random-full"
|
3.i. Tunelowanie
Nie trzeba niczego instalować, aby korzystać z tunelowania, gdyż kontroler
sieciowy posiada już tę możliwość.
Listing 9.1: Konfiguracja tunelowania w /etc/conf.d/net |
iptunnel_vpn0="mode gre remote 207.170.82.1 key 0xffffffff ttl 255"
iptunnel_vpn0="mode ipip remote 207.170.82.2 ttl 255"
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.
Listing 10.1: Konfiguracja VLAN w /etc/conf.d/net |
vlans_eth0="1 2"
vconfig_eth0=( "set_name_type VLAN_PLUS_VID_NO_PAD" )
vconfig_vlan1=( "set_flag 1" "set_egress_map 2 6" )
config_vlan1=( "172.16.3.1 netmask 255.255.254.0" )
config_vlan2=( "172.16.2.1 netmask 255.255.254.0" )
|
Ważne:
Aby używać niektórych ustawień VLAN, może zajść potrzeba zajrzenia do
dokumentacji opisującej nazwy
zmiennych.
|
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.
Ostrzeżenie:
Sterownik linux-wlan-ng nie jest w chwili obecnej wspierany przez
baselayout. Spowodowane to jest tym, że linux-wlan-ng posiada zestaw
własnych ustawień i konfigurację która jest zupełnie inna od pozostałych.
Developerzy linux-wlan-ng są namawiani do przejścia na ustawienia zgodne
z wireless-tools - gdy to zostanie dokonane, baselayout pozwoli na
użycie linux-wlan-ng.
|
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.
Listing 2.1: Instalacja wpa_supplicant |
# emerge net-wireless/wpa_supplicant
|
Ważne:
Należy mieć włączoną opcję CONFIG_PACKET w jądrze, aby
wpa_supplicant działało.
|
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).
Listing 2.2: Konfiguracja /etc/conf.d/net dla wpa_supplicant |
modules=( "wpa_supplicant" )
wpa_supplicant_eth0="-Dmadwifi"
|
Uwaga:
Jeżeli używany jest sterownik host-ap, należy ustawić tryb zarządzania w karcie,
zanim zacznie poprawnie współpracować z wpa_supplicant. Aby to osiągnąć,
można użyć iwconfig_eth0="mode managed" w /etc/conf.d/net.
|
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.
Listing 2.3: Przykładowy /etc/wpa_supplicant/wpa_supplicant.conf |
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=0
ap_scan=1
network={
ssid="proste"
psk="bardzo tajne hasło"
priority=5
}
network={
ssid="drugi ssid"
scan_ssid=1
psk="bardzo tajne hasło"
priority=2
}
network={
ssid="przykład"
proto=WPA
key_mgmt=WPA-PSK
pairwise=CCMP TKIP
group=CCMP TKIP WEP104 WEP40
psk=06b4be19da289f475aa46a33cb793029d4ab3db7a23ee92382eb0106c72ac7bb
priority=2
}
network={
ssid="test-bez-szyfrowania"
key_mgmt=NONE
}
network={
ssid="test-statycznego-wep"
key_mgmt=NONE
wep_key0="abcde"
wep_key1=0102030405
wep_key2="1234567890123"
wep_tx_keyidx=0
priority=5
}
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
}
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.
Listing 3.1: Instalacja wireless-tools |
# emerge net-wireless/wireless-tools
|
Uwaga:
Mimo że ustawienia sieci bezprzewodowych można trzymać w
/etc/conf.d/wireless, my radzimy przetrzymać je w
/etc/conf.d/net.
|
Ważne:
Koniecznie należy zajrzeć do dokumentacji opisującej nazwy zmiennych.
|
Listing 3.2: Przykładowe ustawienia iwconfig w /etc/conf.d/net |
modules=( "iwconfig" )
key_ESSID1="[1] s:twojklucz key [1] enc open"
key_ESSID2="[1] aaaa-bbbb-cccc-dd key [1] enc restricted"
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ę.
| Wartość |
Opis |
| any |
Domyślne zachowanie |
| preferredonly |
Będzie można połączyć się jedynie z AP z listy preferowanych |
| forcepreferred |
Będą dokonywane połączenia z AP w preferowanej kolejności jeśli nie
zostały one odnalezione w skanowaniu
|
| forcepreferredonly |
Nie będzie skanowania w poszukiwaniu AP - w zamian nastąpi próba
połączenia się z każdym w kolejności
|
| forceany |
Podobnie jak forcepreferred + połącz się z dowolnym dostępnym AP
|
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.
Listing 3.3: przykład z blacklist_aps oraz unique_ap |
blacklist_aps=( "ESSID3" "ESSID4" )
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.
Listing 3.4: Przenieś się na tryb ad-hoc |
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.
Listing 3.5: Przykładowa konfiguracja ad-hoc/master |
mode_eth0="ad-hoc"
essid_eth0="Ten węzeł Adhoc"
channel_eth0="9"
|
Ważne:
Poniżej znajduje się dosłowny wycinek z BSD wavelan documentation, który
znajduje się w zasobach
dokumentacji NetBSD Jest 14 kanałów do wyboru. Kanały od 1 do 11 są
legalne w Północnej Ameryce, kanały od 1 do 13 w większości Europy, kanały od
10 do 13 we Francji, a kanał 14 jest przeznaczony dla Japonii. W przypadku
wątpliwości, należy odnieść się do dokumentacji znajdującej się przy karcie
bezprzewodowej lub access poincie. Należy upewnić się, że wybrany kanał jest
ten sam który jest obsługiwany przez access point (lub inna karta znajdująca
się w sieci typu ad-hoc). Domyślnym kanałem dla kart w Północnej Ameryce oraz
Europie jest kanał 3; domyślny dla kart francuskich jest 11, zaś dla tych
sprzedawanych w Japonii to 14.
|
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.
| Zmienna |
Domyślna wartość |
Opis |
| iwconfig_eth0 |
|
Szczegóły dotyczące iwconfig znajdują się w manualu iwconfig |
| iwpriv_eth0 |
|
Szczegóły dotycząca iwpriv znajdują się w manualu iwpriv |
| sleep_scan_eth0 |
0 |
Liczba sekund uśpienia przed rozpoczęciem skanowania. Jest to potrzebne dla
tych sterowników, które potrzebują więcej czasu na uruchomienie zanim mogą
zostać użyte.
|
| sleep_associate_eth0 |
5 |
Liczba sekund oczekiwania na połączenie się interfejsu z Access Pointem
przed przeniesieniem się na kolejny
|
| associate_test_eth0 |
MAC |
Niektóre sterowniki nie zerują adresów MAC przypisanych gdy zgubią adres
lub następuje próba połączenia. Niektóre sterowniki nie zerują poziomu
jakości gdy zgubią adres lub następuje próba połączenia. Prawidłowe
wartości to MAC, quality lub all.
|
| scan_mode_eth0 |
|
Niektóre sterowniki muszą dokonać skanowania w trybie ad-hoc, więc jeśli
skanowanie nie działa, należy ustawić tutaj ad-hoc.
|
| iwpriv_scan_pre_eth0 |
|
Wysyła polecenia iwpriv do interfejsu przed skanowaniem. Więcej informacji
znajduje się w man iwpriv.
|
| iwpriv_scan_post_eth0 |
|
Wysyła polecenia iwpriv do interfejsu po skanowaniu. Więcej informacji
znajduje się w man iwpriv.
|
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ć.
Uwaga:
Poniższe działają jeśli używa się WPA Supplicant lub Wireless Tools.
|
Ważne:
Koniecznie należy zajrzeć do dokumentacji opisującej nazwy zmiennych.
|
Listing 4.1: nadpisywanie ustawień sieciowych w zależności od ESSIDa |
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" )
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"
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.
Listing 1.1: Przykłady funkcji pre/post up/down |
preup() {
if ethtool ${IFACE} | grep -q 'Link detected: no'; then
ewarn "Brakuje linku na ${IFACE}, przerywam konfigurację"
return 1
fi
return 0
}
predown() {
if is_net_fs /; then
eerror "katalog główny jest zamontowany przez sieć -- nie można zatrzymać ${IFACE}"
return 1
fi
return 0
}
postup() {
return 0
}
postdown() {
return 0
}
|
5.b. Funkcje dla sieci bezprzewodowych
Uwaga:
Poniższe funkcje nie zadziałają z WPA Supplicant, ale zmienne${ESSID}
oraz ${ESSIDVAR} są dostępne w funkcji postup().
|
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
Listing 2.1: Funkcje pre/post association |
preassociate() {
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() {
return 0
}
|
Uwaga:
${ESSID} oraz ${ESSIDVAR} są niedostępne dla funkcji
predown() oraz postdown().
|
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.
Uwaga:
Ten dokument opisuje jedynie ifplugd, jednakże istnieją alternatywy, jak
na przykład netplug. Jest on jednak zależny od poprawnego działania
naszej karty na sterownikach z jądra, a często tak się nie dzieje.
|
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.
Listing 2.1: Instalacja ifplugd |
# 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.
Listing 2.2: Przykładowa konfiguracja ifplugd |
ifplugd_eth0="..."
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.
Listing 2.3: Instalacja 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.
|