Uwaga: Ten podręcznik nie jest już aktualizowany, zastąpiono go nowszą wersją. |
Spis treści:
Po pierwsze witamy w Gentoo. Wkraczasz w świat szerokich możliwości i dużej wydajności. Możliwość wyboru to podstawowa zaleta naszej dystrybucji. Podczas instalacji można zdecydować jak dużą część systemu pragnie się zbudować samodzielnie, który program logujący ma pracować w systemie itd.
Gentoo to szybka i nowoczesna dystrybucja. Do jej głównych zalet należą przejrzystość i elastyczność. Tworzymy je jako wolne oprogramowanie i staramy się nie ukrywać niczego przed użytkownikiem. Portage, czyli nasz system zarządzania pakietami napisaliśmy w Pythonie, dzięki czemu można z łatwością przeglądać i modyfikować jego kod tak, aby dostosować go do swoich potrzeb. Gentoo jest oparte głównie na pakietach źródłowych, ale posiada również wsparcie dla pakietów prekompilowanych. Cała konfiguracja odbywa się za pomocą zwyczajnych plików tekstowych. Podsumowując: Gentoo to pełna otwartość.
Niezwykle istotne jest zrozumienie, czemu możliwość wyboru jest aż tak ważna. Nie próbujemy zmuszać użytkowników do robienia czegoś, czego nie chcą. Jeśli uważasz, że w jakimś przypadku powinniśmy, powiadom nas o tym.
W jaki sposób zainstalować Gentoo?
Gentoo Linux dostarczany jest z dwiema prostymi w użyciu wersjami instalatora. Bazująca na bibliotece GTK+ używana w środowisku X oraz Dialog używana w konsoli tekstowej. W rozdziale 3 podręcznika opisano instalację za pomocą wersji GTK+, natomiast w rozdziale 4 za pomocą wersji bazującej na bibliotece Dialog.
Gentoo można zainstalować na wiele różnych sposobów. Najczęściej wybierana metoda to ta przy użyciu jednej z naszych płyt instalacyjnych. Istnieje również możliwość przeprowadzenia tego procesu poprzez już zainstalowaną dystrybucję, inną uruchamialną płytę (np. Knoppix), środowisko uruchamiane z sieci (netmount) czy dyskietkę ratunkową.
W tym Podręczniku omawiamy instalację przy użyciu płyt z instalatorem Gentoo, które zawierają wszystkie narzędzia konieczne do instalacji systemu Gentoo. Do wyboru mamy dwa rodzaje płyt instalacyjnych, zwyczajną płytę instalacyjną oraz LiveCD. Płyta instalacyjna zawiera jedynie minimum wymagane do zainstalowania Gentoo Linux. LiveCD jest w pełni kompletnym środowiskiem Gentoo Linux i może zostać użyte do wielu zadań, w tym do instalacji samego systemu. LiveCD na razie dostępny jest wyłącznie na architekturę x86, więc dokument ten w innych przypadkach opisywał będzie instalacje z użyciem uniwersalnej płyty instalacyjnej.
Taka metoda instalacji nie zapewnia najnowszych wersji pakietów. Opis pobierania najnowszych źródeł programów z Internetu znajduje się w zwykłym Podręczniku Gentoo.
Przewodnik po alternatywnych metodach instalacji to dobre źródło informacji na temat mniej konwencjonalnych sposobów instalowania Gentoo. Ponadto warto zapoznać się z dokumentem zawierającym przydatne rady dotyczące instalacji Gentoo. Zaawansowani użytkownicy, którzy uważają, że w Podręczniku proces instalacji jest omówiony zbyt rozwlekle powinni skorzystać z dokumentu opisującego wszystkie czynności w mocno skrótowej formie (quick install how-to), który znajduje się w naszych zasobach dokumentacji.
Jeśli w czasie instalacji pojawi się jakiś problem (lub wystąpią błędy w dokumentacji) zachęcamy do odwiedzenia strony projektu Gentoo Release Engineering, naszej bugzilli i sprawdzenia czy został on już zgłoszony. Jeśli jeszcze o nim nie wiemy prosimy o wypełnienie i wysłanie odpowiedniego formularza. Nie należy się bać deweloperów, do których zostanie przypisany raport, zwykle nie gryzą.
Pomimo że spora część Podręcznika jest wspólna dla wszystkich architektur istnieją w nim również odnośniki do poszczególnych z nich. Staramy się ograniczać to zjawisko do minimum, aby uniknąć dezorientowania czytelników.
Jeśli nie wiadomo czy kłopot leży po stronie systemu (pewne rzeczy mogą nie być dostatecznie przetestowane) czy po stronie użytkownika (czasami problem może wyniknąć z nieuważnego czytania opisu) warto odwiedzić kanał #gentoo na sieci irc.freenode.net. Zapraszamy tam wszystkich użytkowników.
Odpowiedzi na wiele pytań związanych z Gentoo znajdują się w naszym FAQ. Warto również przejrzeć FAQ na naszym forum. Jeśli odpowiedzi na pytanie nie ma w żadnym z nich zawsze można zapytać maniaków przesiadujących na kanale #gentoo (w sieci freenode), zwykle są dobrze poinformowani.
1.b. Szybka instalacja programów za pomocą GRP
Co to jest "Gentoo Reference Platform"?
GRP (Gentoo Reference Platform) to zestaw prekompilowanych pakietów, które przygotowujemy dla użytkowników wraz z każdym wydaniem naszej dystrybucji. Zestaw ten umożliwia błyskawiczną instalację tych programów w ich systemach. Znajdują się tam nie tylko te pakiety, które są konieczne do działania podstawowego systemu Gentoo, dodajemy także kompilacje większych programów i środowisko, np. xorg-x11, GNOME, OpenOffice, Mozillę.
Zestaw tych pakietów jest aktualizowany wraz z każdym wydaniem Gentoo, pomiędzy nimi wersje pozostają te same. Można je wykorzystać do szybkiej instalacji podstawowego środowiska, a następnie zaktualizować je do najnowszej wersji już mogąc w nim pracować.
Jak Portage obsługuje pakiety GRP?
Drzewo Portage to kolekcja ebuildów, czyli plików zawierających wszystkie informacje dotyczące określonych pakietów, takie jak ich opis, adres strony internetowej projektu, odnośniki do kodów źródłowych, instrukcje dotyczące ich kompilacji czy ich zależności. W naszym przypadku drzewo to musi być zsynchronizowane z konkretnym zestawem GRP, a wersje ebuildów w drzewie muszą zgadzać się z wersjami prekompilowanych pakietów.
W związku z tym z zalet GRP można skorzystać wyłącznie podczas instalacji Gentoo. GRP nie są dostępne dla osób chcących zainstalować najnowsze wersje wszystkich programów.
Nie zapewniamy GRP dla wszystkich architektur. Nie oznacza to, że Portage nie jest tam przygotowane do ich obsługi, po prostu nie mamy zasobów, aby je dla danej architektury zbudować.
Obecnie GRP są dostępne dla następujących architektur:
Jeśli jakiejś architektury nie ma na liście, oznacza to, że pakiety GRP nie są dla niej w danym momencie dostępne.
To tyle tytułem wstępu, przechodzimy do uruchamiania systemu z uniwersalnej płyty instalacyjnej/z LiveCD.
Zanim zaczniemy, musimy wiedzieć jakiego sprzętu będziemy potrzebować, aby zainstalować Gentoo używając LiveCD z instalatorem.
| CPU | Każdy procesor AMD64 lub z rozszerzeniem EM64T |
| Pamięć | 256 MB |
| Wolna przestrzeń na dysku | 1.5 GB (wyłączając miejsca na partycję wymiany) |
| Partycja wymiany | Co najmniej 256 MB |
2.b. LiveCD Gentoo Linux z instalatorem
LiveCD jest uruchamialnym medium zawierającym środowisko Gentoo. Nośnik ten pozwala na uruchomienie Linuksa z płyty CD. Podczas uruchamiania system rozpoznaje nasz sprzęt i ładuje odpowiednie sterowniki. Rozwojem płyt instalacyjnych Gentoo zajmują się deweloperzy Gentoo.
Na chwile obecną dostępne są dwie płyty instalacyjne:
2.c. Ściąganie, nagrywanie i uruchamianie LiveCD z instalatorem
Ściąganie i nagrywanie LiveCD z instalatorem
LiveCD z instalatorem możemy pobrać z jednego z serwerów lustrzanych. Obraz znajduje się w katalogu releases/amd64/2007.0livecd/.
Wewnątrz tego katalogu znajdziemy obraz ISO. Jest to pełny obraz, który nagrywamy na płycie CD-R.
Po pobraniu pliku, możemy sprawdzić jego poprawność, w celu wykrycia błędnych danych:
Aby pobrać nasz klucz publiczny przy użyciu aplikacji GnuPG należy wydać następujące polecenie:
Listing 3.1: Pobieranie klucza publicznego |
$ gpg --keyserver subkeys.pgp.net --recv-keys 17072058
|
Teraz należy zweryfikować podpis:
Listing 3.2: Weryfikowanie podpisu kryptograficznego |
$ gpg --verify <plik podpisu> <obraz iso>
|
Aby nagrać pobrane pliki ISO, musimy wybrać nagrywanie w trybie RAW. Położenie tej opcji uzależnione jest od używanego programu do nagrywania. W poniższym przykładzie omówimy cdrecord i K3B. Więcej informacji możemy znaleźć w naszym Gentoo FAQ.
Uruchamianie LiveCD z instalatorem
Ważne: Należy przeczytać ten rozdział przed przystąpieniem do dalszych pracy, ponieważ w późniejszym czasie nie będziemy mieli okazji przeczytać go przed dalszymi pracami. |
Kiedy już nagramy płytę LiveCD nadchodzi czas, aby ją uruchomić. Usuwamy wszystkie płyty z napędów CD, uruchamiamy ponownie komputer i wchodzimy do BIOS-u. W większości przypadków służy do tego przycisk DEL, F1 lub ESC. W BIOS-ie zmieniamy, kolejność urządzeń bootujących, tak, aby CD-ROM był przed dyskiem twardym. Jeżeli tego nie zrobimy, nasz komputer uruchomi się prosto z dysku ignorując CD-ROM.
W tym momencie należy umieścić LiveCD w napędzie CD-ROM, a następnie ponownie uruchomić komputer. Powinniśmy ujrzeć ekran startowy, na którym należy kliknąć Enter, aby przejść do dalszego procesu uruchamiania z domyślnymi opcjami. Możemy również uruchomić LiveCD z własnymi opcjami oraz z wyszczególnieniem jądra. Po wpisaniu własnych opcji naciskamy Enter.
Wybór jądra? Tak, na LiveCD znajduje się kilka jąder. Domyślnym jest gentoo. Pozostałe przeznaczone są dla specyficznego sprzętu, dodatkowo znajdziemy również warianty -nofb, które pozwalają na wyłączenie framebuffer.
Poniżej znajdziemy krótki opis dostępnych jąder:
| Jądro | Opis |
| gentoo | Domyślne jądro ze wsparcie dla procesorów K8 (włączając w to wsparcie dla NUMA) oraz EM64T. |
| memtest86 | Jądro przeznaczone do testowania pamięci RAM |
Możemy również wpisać dodatkowe opcje dla jądra. Pozwalają one na włączanie/wyłączanie dodatkowych ustawień wedle naszej woli. Poniższa lista jest identyczną z tą, którą otrzymujemy poprzez naciskanie przycisków od F2 do F7 na ekranie startowym.
Listing 3.3: Dostępne opcje, które podajemy dla jądra systemu |
Opcje sprzętowe: acpi=on Opcja powodująca załadowanie wsparcia dla ACPI oraz sprawiająca, że demon acpid, będzie uruchomiony przez CD przy starcie systemu. Funkcja ta jest wymagana jedynie w przypadku, gdy nasz komputer potrzebuje ACPI do poprawnego działania. Nie jest ona konieczna w przypadku wsparcia Hyperthreadingu. acpi=off Całkowicie wyłącza ACPI. Opcja wykorzystywana na starszych komputerach oraz w sytuacji gdy chcemy skorzystać z APM. Completely disables ACPI. W przypadku włączenia tej opcji wsparcie dla Hyperthreadingu zostanie wyłączone. console=X Ustawienie dostępu przy pomocy konsoli szeregowej do CD. Pierwszą opcją jest urządzenie, na architekturze x86 zazwyczaj ttyS0, poprzedzone przez wszystkie opcje potrzebne do połączenia i oddzielone przecinkiem. Domyślną wartością jest 9600,8,b,1. dmraid=X Pozwala na podanie opcji dla urządzenia mapującego podsystem RAID. Opcje powinny być zawarte w cudzysłów. doapm Ładuje sterownik dla wsparcia APM. Wymagane jest ustawienie opcji acpi=off. doslowusb Powoduje krótkie przerwy podczas uruchamiania, niezbędne dla wolnych CDROM-ów USB, wchodzących w skład IBM BladeCenter. dopcmcia Ładuje wsparcie dla kart PCMCIA oraz uruchamia menedżer kart PCMCIA przy starcie płyty. Opcja ta wymagana jest wyłącznie przy uruchamianiu systemu z urządzenia PCMCIA. doscsi Opcja ładująca wsparcie dla kontrolerów SCSI. Wymagana jest ona również w przypadku uruchamiania komputera z urządzenia USB. hda=stroke Pozwala nam na partycjonowanie naszego dysku, nawet w przypadku gdy BIOS nie wykrywa dysków o dużej pojemności. Opcji tej wymagają jedynie komputery ze starszymi wersjami BIOS-u. Wyrażenie hda zastępujemy odpowiednio do naszych potrzeb. ide=nodma Wymusza wyłączenie wsparcia dla DMA w jądrze. Opcja ta wymagana jest przez część chipsetów IDE oraz CDROM-ów. Jeżeli mamy problemy z odczytanie płyty przez nas napęd polecamy wypróbowanie tej opcji. Dodatkowo użycie jej spowoduje zaniechanie wykonania przez hdparm domyślnych poleceń. noapic Wyłącza Advanced Programmable Interrupt Controller, który jest obecny na nowszych płytach głównych. nodetect Wyłącz automatyczne wykrywanie podczas startu płyty, takie jak automatyczne wykrywanie urządzeń czy próba pobrania adresu sieciowego przy użyciu DHCP. nodhcp Wyłącza pobieranie adresu sieciowego przy użyciu DHCP na wykrytych kartach sieciowych. Opcja przydatna w przypadku sieci, nie oferujących usługi DHCP. nodmraid Wyłącza wsparcie dla urządzeń mapujących RAID, na przykład takich jak te używane przez wbudowane na płycie głównej kontrolery RAID IDE/SATA. nofirewire Wyłącza ładowanie modułów odpowiedzialnych za obługę Firewire. Powinniśmy jej używać wyłącznie w przypadku, gdy urządzenia Firewire powodują problemy podczas uruchamiania. nogpm Wyłącza wsparcie sterownika myszki dla konsoli. nohotplug Powoduje zaniechanie uruchamiania skryptów init dla hotplug i coldplug podczas uruchamiania płyty. Opcja przydaje się podczas debugowania problemów związanych z CD lub sterownikami. nokeymap Uniemożliwia wybór innego układu klawiatury niż standardowy układ US. nolapic Wyłącza lokalne APIC. nosata Powoduje nie ładowanie modułów SATA. nosmp Wyłącza wsparcie dla SMP, na jądrach mających aktywną opcję SMP. nosound Powoduje nie ładowanie wsparcia dla dźwięku oraz ustawień wolumenów. nousb Wyłącza automatyczne ładowanie modułów USB. Zarządzanie urządzeniami/wolumenami: dodevfs Włącza przestarzały system devfs na jądrach serii 2.6. Aby opcja ta zadziałała jej użycie musi być połączone z opcją noudev. Ponieważ w jądrach serii 2.4 udevfs jest jedynym wyborem, użycie tej opcji nie spowoduje żadnych efektów. dooevms2 Włącza wsparcie dla EVMS. Nie poleca się używać tej opcji razem z lvm2. dolvm2 Włącza wsparcie LVM. Nie poleca się używać tej opcji razem z evms2. doudev Wyłącza wsparcie udev w jądrach serii 2.6. Gdy jej użyjemy powinniśmy również użyć opcji dodevfs. Ponieważ udev nie znajdziemy w jądrach serii 2.4, opcja ta nie ma żadnego przełożenia na uruchamianie jądra z tej serii. unionfs Włącza wsparcie Unionfs. Opcja ta pozwala stworzyć warstwę Unionfs w tmpfs, która umożliwia zmianę plików na płycie. unionfs=X Włącza wsparcie Unionfs. W odróżnieniu od opcji opisanej wyżej, ta tworzy warstwę Unionfs na dowolnym podanym jako parametr urządzeniu. Urządzenie to musi zostać sformatowane przy użyciu systemu rozpoznawalnego przez jądro. Inne opcje: debug Włącza tryb debugowania. Trzeba być uważnym, gdyż polecenie to powoduje generowanie dużej liczby komunikatów. docache Ładuje do pamięci RAM wszystkie potrzebne składniki CD, tak aby można było zamontować inną płytę. Opcja ta wymaga, aby nasz komputer posiadał co najmniej drugie tyle pamięci RAM ile wynosi pojemność płyty. doload=X Powoduje ładowanie wymienionych modułów oraz ich zależności. W miejsce X wstawiamy nazwy pożądanych modułów, większą ich ilość oddzielamy przecinkiem. noload=X Powoduje działanie odwrotne do opcji doload, to jest nie ładuje wymienionych modułów. Składnia zgodna jest z powyższą opcją. nox Powoduje nie włączanie automatyczne X-ów na LiveCD. scandelay Opcja wywołująca, krótkie 10 sekundowe przerwy podczas uruchamiania LiveCD. Pozwala to wolnym urządzeniom, na inicjalizację i gotowość do użycia. scandelay=X Opcja działa w podobny sposób do powyższej, jednak w tym przypadku to od użytkownika zależy jak długi będzie okres przerwy w ładowaniu systemu. Czas określamy w sekundach i wpisujemy zamiast X. |
Pora na uruchomienie systemu z płyty. Wybieramy jądro (jeśli domyślne gentoo nas nie zadowala) oraz opcje z jakimi ma zostać ono uruchomione. Jako przykład podamy linię uruchamiającą jądro gentoo z opcją dopcmcia:
Listing 3.4: Uruchamianie płyty instalacyjnej |
boot: gentoo dopcmcia
|
Jeśli instalujemy Gentoo w systemie, w którym mamy klawiaturę inną niż US musimy wcisnąć ALT+F1, 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. Jak tylko skończy się proces wczytywania systemu, zostanie uruchomiony Gnome oraz zostaniemy automatycznie zalogowani do "Live" Gentoo Linux w trybie graficznym jako użytkownik "gentoo". Na innych konsolach powinniśmy zostać zalogowani jako "root", nazywany też czasem superużytkownikiem. Pojawi się tam znak zachęty ("#") roota. Konsole zmieniamy kombinacjami klawiszy Alt-F2, Alt-F3, Alt-F4, Alt-F5, Alt-F6. Do środowiska graficznego, które widzieliśmy na początku wracamy naciskając Alt-F7. W obrębie środowiska X między konsolami poruszamy się dodając Ctrl do powyższych skrótów. W środowisku graficznym mamy możliwość wykonywać polecenia z prawami roota przez użycie aplikacji sudo.
Listing 3.5: Używanie aplikacji sudo |
(Są to jedynie przykłady użycia) (Edycja pliku z grupami) # sudo vi /etc/group (Przełączanie do roota w obrębie sesji) # sudo su - |
Konfiguracja dodatkowego sprzętu
W czasie uruchamiania system spróbuje wykryć sprzęt i załadować odpowiednie sterowniki. Zazwyczaj czyni to prawidłowo, ale czasami mogą zdarzyć się problemy i nie wszystkie moduły zostaną aktywowane. Gdy zawiedzie skanowanie PCI musimy ręcznie załadować odpowiednie moduły.
W poniższym przykładzie spróbujemy załadować moduł 8139too (obsługujący całą serię urządzeń sieciowych):
Listing 3.6: Ładowanie modułów jądra |
# modprobe 8139too
|
Opcjonalnie: Poprawianie wydajności twardego dysku
Zaawansowanych użytkowników na pewno zainteresuje możliwość zwiększenia wydajności twardych dysków IDE za pomocą programu hdparm. Obecną wydajność można przetestować za pomocą parametrów -tT (kilkukrotne wykonanie polecenia zwiększa precyzję pomiaru):
Listing 3.7: Testowanie wydajności twardego dysku |
# hdparm -tT /dev/hda
|
Aby poprawić wydajność można wykorzystać któryś z poniższych przykładów (lub poeksperymentować samodzielnie). Oczywiście musimy zastąpić /dev/hda ścieżką do naszego dysku.
Listing 3.8: Poprawianie wydajności dysku |
(Aktywowanie DMA:) # hdparm -d 1 /dev/hda (Lub z bezpiecznymi opcjami poprawiającymi wydajność:) # hdparm -d 1 -A 1 -m 16 -u 1 -a 64 /dev/hda |
Opcjonalnie: Konta użytkowników
Jeśli planujemy umożliwienie innym osobom dostępu do środowiska instalacyjnego lub zamierzamy korzystać z irssi nie uruchomionego z przywilejami roota musimy stworzyć dodatkowe konta. Musimy posiadać uprawienia root, aby zmienić hasło dla tego użytkownika i dodać nowych.
Do zmiany hasła root posłuży nam polecenie passwd:
Listing 3.9: Changing the root password |
$ sudo su - # passwd New password: (Enter your new password) Re-enter password: (Re-enter your password) |
Aby stworzyć konto użytkownika musimy najpierw podać jego parametry, a następnie ustawić hasło. Skorzystamy przy tym z poleceń useradd oraz passwd. W przykładzie stworzymy użytkownika o nazwie "rane".
Listing 3.10: Tworzenie konta użytkownika |
# useradd -m -G users rane # passwd rane New password: (Podajemy hasło) Re-enter password: (Potwierdzamy hasło) |
Mamy także możliwość zmiany user id przy pomocy konta root i polecenia su:
Listing 3.11: Zmiana user id |
# su - john
|
Możemy również zmienić hasło, dla użytkownika "gentoo", na który jak pamiętamy LiveCD zalogowało nas automatycznie.
Listing 3.12: Zmiana hasła użytkownika gentoo |
$ passwd New password: (Podajemy hasło) Re-enter password: (Potwierdzamy hasło) |
Opcjonalnie: Dostęp do dokumentacji podczas instalowania Gentoo
Jeżeli zamierzamy podczas instalacji przeglądać Podręcznik Gentoo (obojętnie czy nagrany na CD czy znajdujący się w Internecie) możemy użyć Mozilla Firefox (ze środowiska graficznego) lub przy pomocy programu links (ze środowiska tekstowego).
Listing 3.13: Przeglądanie dokumentacji na CD przy pomocy przeglądarki Firefox |
# firefox /mnt/cdrom/docs/handbook/html/index.html
|
Jeżeli wolimy używać programu links, aby przeglądać wersje tekstową podręcznika, powinniśmy się upewnić, że utworzyliśmy konto zwykłego użytkownika (więcej informacji w dziale Opcjonalnie: Konta użytkowników). Przy pomocy klawiszy Alt-F2 otwieramy nowy terminal, aby się zalogować.
Listing 3.14: Przeglądanie dokumentacji na CD przy pomocy przeglądarki links |
# links /mnt/cdrom/docs/handbook/html/index.html
|
Na pierwszy terminal powracamy przy pomocy kombinacji klawiszy Alt-F7.
Najnowsza i najlepsza wersja podręcznika znajduje się na naszej stronie internetowej. Do jej przeglądanie możemy używać przeglądarek Firefox lub links, jednak tylko w przypadku gdy przeprowadziliśmy konfigurację sieci zgodnie z instrukcjami w rozdziale Konfiguracja sieci (w przeciwnym wypadku nie będziemy mogli przeglądać internetowej wersji podręcznika):
Listing 3.15: Przeglądanie dokumentacji w Internecie przy pomocy przeglądarki Firefox |
# firefox http://www.gentoo.org/doc/en/handbook/2007.0/handbook-amd64.xml
|
Listing 3.16: Przeglądanie dokumentacji w Internecie przy pomocy przeglądarki links |
# links http://www.gentoo.org/doc/en/handbook/2007.0/handbook-amd64.xml
|
Instalacje możemy rozpocząć korzystając z graficznego instalatora opartego bibliotece GTK+ (wymagane środowisko X) lub bazującego na biblioteceDialog, który może być użyty w środowisku tekstowym.
Po uruchomieniu instalatora Gentoo Linux wyświetlony zostanie ekran powitalny. Razem z instalatorem dostarczana jest przejrzysta instrukcja opisująca proces instalacji. Należy pamiętać o przeczytaniu każdej opcji z należytą uwagą. Dla każdego z etapów instalacji przewidziana jest pomoc, wystarczy spojrzeć na lewą stronę każdej z zakładek. Zalecamy przeczytanie tej pomocy przed dokonywaniem dalszych wyborów. Godnym uwagi szczegółem jest również możliwość zapisania aktualnych postępów konfiguracji, a następnie odtworzenie procesu instalacji w późniejszym czasie.
Do wyboru mamy trzy możliwości instalacji. Wybieramy Networkless, aby zainstalować Gentoo Linux.
Uwaga: Wybierając opcję Networkless sprawimy, że w późniejszym czasie część opcji będzie niedostępna. |
Pierwszą rzeczą, którą należy zrobić, by móc zainstalować Gentoo na swoim komputerze jest przygotowanie dysków. W zakładce Partitioning możemy znaleźć listę wykrytych dysków oraz partycji, a także zdecydować jaki system plików powinien się na nich znaleźć. Należy bardzo uważać w przypadku opcji Clear partitions ponieważ powoduje ona usunięcie wszystkich partycji z naszego dysku! Możliwa jest również zmiana rozmiaru partycji.
Jeżeli wybierzemy opcję Recommended layout, instalator usunie całą poprzednią zawartość dysku, a następnie stworzy trzy partycje: 100 megabajtową /boot, /swap o rozmiarze do 512MB, natomiast reszta dostępnego miejsca na dysku zostanie użyta do utworzenia partycji głównej (/).
Ostrzeżenie: Tak jak w przypadku każdej aplikacji tworzącej partycje powinniśmy zrobić kopie zapasową naszych danych przed dokonaniem jakichkolwiek zmian w strukturze dysku ponieważ istnieje ryzyko utraty danych. Wszystkie zmiany, które przeprowadzamy na partycji zostają natychmiast zapisane przez instalator. |
Opcjonalnie: Montowanie sieciowych systemów plików
W tej zakładce użytkownik może ustawić gdzie oraz jak powinny być montowane sieciowe systemy plików, które można wykorzystać zarówno w trakcie, jak i po instalacji. Aby rozpocząć konfigurację należy wybrać opcję New. W tym momencie wspierany jest tylko NFS.
Ponieważ nasza instalacja odbywa się bez dostępu do sieci lub z prekompilowanych pakietów GRP, nie będziemy mogli wybrać flag USE przed instalacją. Jednak, nic nie stoi na przeszkodzie, aby flagi te odpowiednio ustawić w pliku /etc/make.conf, zaraz po instalacji i uruchomieniu naszego systemu.
Typ naszego procesora powinniśmy wybrać w sekcji CFLAGS razem z innymi flagami optymalizacyjnymi, takimi jak -O2 czy -pipe.
Wszystkie opcje, których chcemy używać w przyszłości powinni zostać wybrane w tym momencie. Opcja Build binary packages tworzy gotowe do instalacji pakiety binarne, ze wszystkich programów, które skompilujemy w naszym systemie. Opcja DistCC pozwala dzielić obciążenie wywołane przez kompilację na inne komputery znajdujące się w sieci lokalnej.
W instalatorze nie możemy zmienić wartości CHOST, ponieważ nieumiejętna jej zmiana może poważnie uszkodzić system. W opcji MAKEOPTS określamy maksymalną liczbę możliwych równoległych kompilacji podczas instalacji pakietu. Przyjęto zasadę, że wpisujemy tutaj ilość procesorów powiększona o jeden, jednak ten wzór nie zawsze jest dobrym rozwiązaniem. W systemie jednoprocesorowym, można używać ustawienia -j2.
Należy przyjrzeć się mapie i wybrać region najbliższy naszej aktualnej lokalizacji. W kolejnym kroku zostaniemy zapytani czy ustawić nasz zegar zgodnie z czasem UTC czy z czasem lokalnym.
Jeżeli instalacja odbywa się bez dostępu do internetu lub z pakietów prekompilowanych, musimy użyć jądra znajdującego się na LiveCD. Jest to jądro gentoo-sources skompilowane przy użyciu genkernela, przez co będzie ono automatycznie wykrywało i konfigurowało sprzęt podczas uruchamiania.
Na tej zakładce można skonfigurować interfejsy sieciowe, które zostały wykryte na naszym komputerze. Każdą opcję należy przeczytać bardzo uważnie.
Zakładka Hostname/Proxy Information/Other pozwala nam ustalić nazwę dla naszego komputera. Możemy również wprowadzić tutaj ustawienia serwera proxy oraz DNS, jeśli ich potrzebujemy.
Demony cron są użytecznymi programami, które uruchamiają zadania w określonym przez nas czasie. Być może nie potrzebujemy ich instalować jednak mogą one okazać się dosyć przydatne. Ponieważ przeprowadzamy instalację bez dostępu do internetu, jedynym wyborem jaki w tym momencie mamy jest vixie-cron lub całkowity brak demona cron.
Aplikacja logująca jest bezwzględnie potrzebna w systemie operacyjnym Linux. Ponieważ jest to instalacja bez dostępu do sieci internet, jesteśmy ograniczeni do aplikacji syslog-ng lub do całkowitego jej braku.
Zakładka ta pozwala nam na wybór programu ładującego oraz opcjonalne wpisanie parametrów dla jądra uruchamianego podczas startu systemu.
Możemy wybrać dysk z którego będzie uruchamiany program ładujący, opcją Boot Drive. W hierarchii Linuksa, pierwszy dysk IDE nazwany jest hda, drugi hdb i tak dalej. Jeżeli posiadamy dysk SATA lub SCSI, będą one nosić nazwę odpowiednio sda, sdb itd. Należy się upewnić, że wybraliśmy odpowiedni dysk.
Jeżeli musimy dodać dodatkowe parametry jądra takie jak na przykład video czy VGA, wpisujemy je w pole "Extra kernel parameters".
W przypadku problemów z wykryciem naszego dysku przez BIOS z powodu jego dużej wielkości, powinniśmy dodać opcję hdx=stroke. Jeżeli nasz dysk jest dyskiem SCSI niezbędnym okaże się podanie parametru jądra doscsi.
Na samym początku należy ustawić hasło użytkownika root (administratora systemu).
Wykonywanie zadań z przywilejami roota jest niebezpieczne i należy tego unikać. Do codziennej pracy należy utworzyć konto zwykłego użytkownika, któremu możemy zmienić hasło oraz dodać go do wybranych grup. Dodatkowo można zmienić domyślne ustawienia katalogu domowego, powłoki, której będzie używał, oraz ustawić pomocne komentarze.
Opcjonalnie: instalacja dodatkowych pakietów
LiveCD zawiera kilka prekompilowanych pakietów. Jeżeli chcemy je zainstalować, należy zaznaczyć odpowiednie pola.
3.l. Uruchamianie usług na starcie
Zakładka ta pozwoli nam wybrać usługi, które mają być uruchamiane przy starcie systemu operacyjnego. Należy przeczytać wszystkie możliwe do wyboru usługi i wybrać te potrzebne. Dla przykładu, jeśli zainstalowaliśmy xorg-x11 i chcemy na starcie systemu uruchamiać graficzne środowisko, powinniśmy wybrać z listy usługę "xdm".
W tym momencie będziemy mogli zmienić pozostałe ustawienia, włączając w to układ klawiatury, środowisko graficzne, domyślny edytor tekstowy. Dodatkowo należy dokonać wyboru czy zegar sprzętowy powinien być ustawiony jako UTC czy czas lokalny.
Na tym kończy się instalacja. Teraz możemy ponownie uruchomić komputer i zalogować się do naszego nowego systemu Gentoo.
Gratulacje! Nasz system jest teraz w pełni gotowy. Aby dowiedzieć się więcej na temat Gentoo należy zajrzeć do następnego rozdziału "I co dalej?".
Zaraz po załadowaniu LiveCD, nastąpi próba uruchomienia środowiska graficznego. Jeżeli zakończy się ona niepowodzeniem, w linii poleceń pojawi się znak zachęty. Aby uruchomić instalator, należy wpisać:
Listing 1.1: Uruchamianie instalatora |
# installer-dialog
|
Po zakończeniu ładowania, naszym oczom ukaże się ekran powitalny. Razem z instalatorem mamy dostęp do przejrzystej instrukcji instalacji Gentoo. Każdą z opcji należy najpierw uważnie przeczytać, dopiero później z niej korzystać. Do każdego z kroków instalacji na górze zakładki dostępna jest szczegółowa pomoc. Radzimy ją wykorzystać przed podjęciem własnych decyzji dotyczących instalacji. Ważne jest, iż możemy w dowolnym momencie zapisać stan instalacji i powrócić do tego samego momentu w późniejszym czasie. Do poruszania się po opcjach wewnątrz kolejnych zakładek należy skorzystać z klawisza Tab (na klawiaturze) oraz klawisza Enter aby zatwierdzić jakąś akcję.
Do wyboru mamy dwie możliwości instalacji, Standard oraz Advanced. Pierwszy z trybów ustawi szereg opcji bez potrzeby naszej ingerencji. Drugi natomiast, podczas instalacji, wymaga od użytkownika odpowiedzi na kilka dodatkowych pytań.
Jeśli wybraliśmy opcję Standard, przechodzimy dalej do rozdziału Partycjonowanie. W przeciwnym wypadku musimy przeczytać dalszą cześć.
4.b. Opcja Advanced: Przygotowania do instalacji
Pomimo tego, że będziemy instalować system bez połączenia z internetem, możemy skonfigurować połączenie z naszą siecią lokalną (LAN), na wypadek gdy zechcielibyśmy zainstalować Gentoo z innego komputera znajdującego się w tej sieci.
Jeżeli chcemy umożliwić dostęp do naszego komputera za pomocą SSH, w celu zdalnej instalacji, należy uruchomić demona sshd i ustawić hasło dla użytkownika root.
Ładowanie dodatkowych modułów jądra
W przypadku chęci załadowania dodatkowych modułów do obsługi naszego sprzętu, powinniśmy wymienić ich nazwy, każdą oddzielona spacją od drugiej.
Pierwszą rzeczą, którą należy zrobić, aby móc zainstalować Gentoo na swoim komputerze jest przygotowanie dysków. W zakładce Partitioning możemy znaleźć listę wykrytych dysków oraz partycji, a także zdecydować jaki system plików powinien się na nich znaleźć. Należy bardzo uważać w przypadku opcji Clear partitions ponieważ powoduje ona usunięcie wszystkich partycji z naszego dysku!
Jeżeli wybierzemy opcję Recommended layout, instalator stworzy trzy partycje: 100 megabajtową /boot, /swap o rozmiarze do 512MB, natomiast reszta dostępnego miejsca na dysku zostanie użyta do utworzenia partycji głównej (/).
Ostrzeżenie: Tak jak w przypadku każdej aplikacji tworzącej partycje powinniśmy zrobić kopie zapasową naszych danych przed dokonaniem jakichkolwiek zmian w strukturze dysku ponieważ istnieje ryzyko utraty danych. |
Ponieważ instalujemy Gentoo bez dostępu do internetu lub z GRP, musimy wybrać opcję Networkless. Następnie przechodzim do dalszej części instalacji.
Należy przejrzeć listę i wybrać region najbliższy naszej aktualnej pozycji.
Na tej zakładce można skonfigurować interfejsy sieciowe, które zostały wykryte na naszym komputerze. Każdą opcję należy przeczytać bardzo uważnie.
Następna zakładka pozwala wybrać pomiędzy DHCP a ręcznym ustawieniem adresu IP. Jeżeli nasz interfejs sieciowy zostanie poprawnie skonfigurowany, należy utworzyć nazwę dla naszego komputera. Dodatkowo można również sprecyzować nazwę domeny oraz informacje na temat serwerów DNS.
Ta zakładka daje nam możliwość wyboru programu ładującego (grub lub brak programu ładującego). Następnie wybieramy urządzenie, z którego uruchamiany będzie program oraz (opcjonalnie) dodajemy dodatkowe opcję uruchamiania.
W pierwszej kolejności należy ustawić hasło administratora systemu (użytkownik root).
Wykonywanie zadań z przywilejami roota jest niebezpieczne i należy tego unikać. Do codziennej pracy należy utworzyć konto zwykłego użytkownika, któremu możemy zmienić hasło oraz dodać go do wybranych grup. Dodatkowo można zmienić domyślne ustawienia katalogu domowego, powłoki, której będzie używał, oraz ustawić pomocne komentarze.
LiveCD zawiera kilka prekompilowanych pakietów. Jeżeli chcemy je zainstalować, należy zaznaczyć odpowiednie pola.
Zakładka ta pozwala na wybranie serwisów, które mają być uruchamiane podczas startu systemu. Należy przeczytać dostępne opcję wraz z ich opisem, a następnie wybrać odpowiednie serwisy. Dla przykładu, jeżeli wybraliśmy instalację pakietu xorg-x11 i podczas uruchamiania systemu, chcemy bezpośrednio uruchamiać graficzne środowisko, powinniśmy wybrać z listy opcję "xdm".
Jeżeli wybraliśmy opcję Advanced instalacji, w tym momencie będziemy mogli zmienić szereg ustawień, włączając w to rozkład klawiatury, graficzny menedżer okien, domyślny edytor oraz czy nasz zegar sprzętowy ma działać zgodnie z czasem lokalnym czy UTC.
Instalator zapyta nas czy chcemy zachować nasz profil instalacji (installation profile) do dalszego wykorzystania. Instalator powiadomi nas o zakończeniu działania i powróci do linii komend. Pozostanie nam jedynie ponowne uruchomienie komputera:
Listing 5.1: Ponowne uruchamianie |
# shutdown -r now
|
Gratulacje! Nasz system jest teraz w pełni gotowy. Aby dowiedzieć się więcej na temat Gentoo należy zajrzeć do następnego rozdziału "I co dalej?".
Gratulacje! Od teraz masz działający system Gentoo Linux. Ale... co teraz? Czego można dokonać? Co odkryć najpierw? Gentoo daje swoim użytkownikom ogromne możliwości, których większość jest świetnie udokumentowana.
Zdecydowanie warto rzucić okiem na drugą część Podręcznika, zatytułowaną Praca z Gentoo. Omówiliśmy w niej metody instalacji i aktualizacji oprogramowania, flagi USE i system skryptów startowych.
Aby zoptymalizować system na desktop lub dowiedzieć się jak najlepiej skonfigurować oprogramowanie biurkowe, warto poznać rozdział Zasoby dokumentacji Gentoo dla stacji roboczych. Warto również zainteresować się możliwością spolszczenia systemu, wszystkie czynności, jakich należy dokonać w tym celu opisaliśmy w tekście zatytułowanym Lokalizacja Gentoo Linux.
Wartą przeczytania pozycją jest także Podręcznik bezpieczeństwa Gentoo.
Pełna lista dostępnych dokumentów znajduje się na stronie zasobów dokumentacji Gentoo.
Wszystkich użytkowników zapraszamy na Forum Gentoo oraz nasze liczne kanały IRC.
Dodatkowo posiadamy wiele list dyskusyjnych dostępne dla wszystkich zainteresowanych. Informacje o subskrybcji zamieściliśmy na ich stronie.
I tyle. Po tej całej ciężkiej pracy związanej z instalacją przyszła pora głęboko odetchnąć i zacząć cieszyć się świeżo zainstalowanym systemem. :)
Gentoo jest dynamicznie zmieniającym się systemem. Poniższe akapity opisują ważne zmiany, które wpływają na sposób instalacji. Przedstawiamy tylko te modyfikacje, które są w jakiś sposób związane z procesem budowania systemu.
Nie ma żadnych znaczących zmian.
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
|
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.
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
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
|
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. |
(Oczywiście alsa-lib to tylko przykład) # emerge -vp alsa-lib [ebuild N ] media-libs/alsa-lib-1.0.14_rc1 -debug +doc 698 kB |
Najlepszym sposobem uaktywnienia flagi USE doc jest wykonanie tego dla jednego pakietu przy użyciu pliku /etc/portage/package.use tak, aby pobrać dokumentację jedynie dla programu, którym jesteśmy zainteresowani. Uaktywnienie tej flagi globalnie, może powodować błędy wywoływane przez zapętlające się zależności. Aby dowiedzieć się więcej należy przeczytać rozdział podręcznika dotyczący flag USE.
Dokumentacja do zainstalowanego już pakietu na ogół znajduje się w podkatalogu o nazwie takiej samej jak pakiet, w katalogu /usr/share/doc. Można wyświetlić listę wszystkich zainstalowanych plików za pomocą narzędzia equery, które jest częścią pakietu app-portage/gentoolkit.
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 (Można też użyć equery do zlokalizowania plików dokumentacji) # equery files alsa-lib | less media-libs/alsa-lib-1.0.14_rc1 * Contents of media-libs/alsa-lib-1.0.14_rc1: /usr /usr/bin /usr/bin/alsalisp (Wyjście programu zostało skrócone) |
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.
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
|
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
|
...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.
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.
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:
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.
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ę.
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.
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. |
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ń.
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.
Wyróżniamy dwa typy flag USE: globalne oraz lokalne.
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.
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 |
(Ten przykład to suma ustawień w plikach base, default-linux,
default-linux/x86 i default-linux/x86/2004.3)
USE="x86 oss apm arts avi berkdb bitmap-fonts crypt cups encode fortran f77
foomaticdb gdbm gif gpm gtk imlib jpeg kde gnome libg++ libwww mad
mikmod motif mpeg ncurses nls oggvorbis opengl pam pdflib png python qt
quicktime readline sdl spell ssl svga tcpd truetype X xml2 xmms xv zlib"
|
Jak łatwo zauważyć, domyślny zestaw zawiera dość dużo słów kluczowych. Pamiętajmy, aby nie dokonywać zmian w pliku make.defaults, w celu dostosowywania zmiennej USE do swoich potrzeb. Zmiany te zostaną usunięte przy najbliższej aktualizacji drzewa Portage!
Aby zmienić domyślne ustawienia, musimy dodać (lub usunąć) słowa kluczowe w zmiennej USE. Dokonuje się tego definiując globalnie zmienną USE w pliku /etc/make.conf. Do tej zmiennej możemy dodać flagi, które są nam potrzebne lub też usunąć te, których nie potrzebujemy. Usunięcia flagi dokonuje się poprzez wstawienie znaku minus (-) przed wybraną flagą.
Na przykład, aby usunąć obsługę KDE i QT oraz dodać obsługę ldap, zmienna USE w pliku /etc/make.conf powinna wyglądać następująco:
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
|
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):
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
|
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
|
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.
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
|
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 |
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.
Instalowanie ccache w Gentoo jest bardzo proste - jedyne, co należy zrobić, to zainstalować odpowiedni pakiet:
Listing 3.1: Instalacja ccache |
# emerge 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}"
|
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
|
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.
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.
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 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.
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.
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
|
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.
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.
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.
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).
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!
Poniżej znajduje się szablon skryptu init.
Listing 4.1: Szablon skryptu init |
#!/sbin/runscript
depend() {
(Informacje o zależnościach)
}
start() {
(Komendy niezbędne do uruchomienia usługi)
}
stop() {
(Komendy niezbędne do jej wyłączenia)
}
restart() {
(Polecenia służące do restartu usługi)
}
|
Każdy skrypt wymaga zdefiniowanej funkcji start(). Pozostałe funkcje są opcjonalne.
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:
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
}
|
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 # czekaj 3 sekundy przed ponownym uruchomieniem
start()
}
|
Zmienne konfiguracyjne dla usług
Aby skrypt uruchamiający daną usługę sięgał do plików konfiguracyjnych, zlokalizowanych w /etc/conf.d nie trzeba praktycznie robić niczego. W chwili kiedy skrypt zostanie uruchomiony, przetworzone zostaną następujące pliki:
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.
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 |
(Kopiowanie wszystkich usług z domyślnego runlevela do runlevela offline # cd /etc/runlevels/default # for service in *; do rc-update add $service offline; done (Usuwanie niechcianej usługi z runlevela offline # rc-update del net.eth0 offline (Wyświetlenie wszystkich aktywnych usług dla runlevela offline # rc-update show offline (Częściowe wyjście) acpid | offline domainname | offline local | offline net.eth0 | |
Nawet jeśli net.eth0 zostanie usunięte z poziomu uruchomieniowego offline, udev będzie próbował uruchomić urządzenia, które wykryje, a następnie uruchomi potrzebne usługi. Dlatego należy dodać każdą usługę sieciową, której nie chcemy startować (sposób ten działa również w przypadku, innych urządzeń wykrywanych przez udev), do pliku /etc/conf.d/rc, według podanego poniżej wzoru.
Listing 5.3: Wyłączanie usług przy pomocy pliku /etc/conf.d/rc |
RC_COLDPLUG="yes"
(Następnie wpisujemy usługi, których nie chcemy uruchamiać automatycznie)
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 jest analogiczne do softlevela. Jedyną różnicą jest definiowanie drugiego "rozruchowego" poziomu uruchamiania zamiast drugiego "domyślnego" poziomu uruchamiania.
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
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.
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
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 |
Dwukropek na końcu zmiennej oznacza, że wejdzie do niej także katalog, w którym będzie przebywał użytkownik
PATH="${PATH}:/home/my_user/bin:"
|
Po wylogowaniu się i ponownym zalogowaniu, wartość zmiennej PATH będzie uaktualniona.
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"
|
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:
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 |
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.
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.
Domyślnie, pobrany kod źródłowy instalowanych aplikacji jest przechowywany wewnątrz /usr/portage/distfiles. Tę lokalizację określa zmienna DISTDIR.
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 (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.
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.
Tymczasowe, osobne dla każdego budowanego pakietu katalogi powstają w /var/tmp/portage. Miejsce to zapisane jest w zmiennej BUILD_PREFIX.
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.
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:
Ważne: Jeżeli używaliśmy enotice z Portage-2.0.*, musimy go całkowicie usunąć gdyż nie jest on kompatybilny z elog. |
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
W trakcie budowania programu, Portage przekazuje kompilatorowi następujące zmienne:
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.
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:
Kolejna zmienna zawiera adres serwera rsync, z którego pobierane będą 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.
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.
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.
Aby dowiedzieć się więcej o opcjach, należy zapoznać się z manualem, wywoływanym poleceniem man rsync.
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.
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.
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.
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.
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
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
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 |
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 |
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:
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
|
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.
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.a. Używanie podzestawów drzewa Portage
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 |
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 |
# Dla DHCP config_eth0=( "dhcp" ) # Dla statycznego IP używając notacji CIDR config_eth0=( "192.168.0.7/24" ) routes_eth0=( "default via 192.168.0.1" ) # Dla statycznego IP używając notacji netmaski config_eth0=( "192.168.0.7 netmask 255.255.255.0" ) routes_eth0=( "default via 192.168.0.1" ) |
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.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 |
(Dodawanie trzech adresów IPv4) config_eth0=( "192.168.0.2/24" "192.168.0.3/24" "192.168.0.4/24" ) (Dodawanie adresu IPv4 oraz dwóch adresów IPv6) config_eth0=( "192.168.0.2/24" "4321:0:1:2:3:4:567:89ab" "4321:0:1:2:3:4:567:89ac" ) # Zachowuje przypisany adres, chyba że urządzenie zostanie wyłączone # - w takim wypadku należy przypisać kolejny adres poprzez DHCP. # Jeżeli pobranie adresu przez DHCP nie powiedzie się - zostanie # przypisany stały adres IP poprzez APIPA config_eth0=( "noop" "dhcp" ) fallback_eth0=( "null" "apipa" ) |
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ę. |
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 |
# Można użyć dowolnej zależności (use, after, before) według przykładów znalezionych w skryptach startowych
depend_br0() {
need net.eth0 net.eth1
}
|
Więcej informacji o zależnościach można znaleźć w sekcji dotyczącej tworzenia skryptów inicjacyjnych w Podręczniku Gentoo.
2.c. Nazwy zmiennych i ich wartości
Nazwy zmiennych są dynamiczne. Najczęściej posiadają one strukturę zmienna_${interfejs|mac|essid|apmac}. Przykładowo, zmienna dhcpcd_eth0 przechowuje wartość dla opcji dhcpcd dla interfejsu eth0, zaś dhcpcd_essid przechowuje wartości dla opcji dhcpcd gdy interfejs podłączy się do ESSID o nazwie "essid".
Jednakże, nie ma zasady mówiącej o tym, iż nazwy interfejsów muszą mieć format ethx. Wiele urządzeń bezprzewodowych posiadają nazwy takie jak wlanx, rax, jak również eth.x Dodatkowo, niektóre interfejsy sieciowe zdefiniowane przez użytkowników, takie jak mostki, mogą posiadać dowolną nazwą, np. foo. Aby urozmaicić życie, bezprzewodowe punkty dostępu mogą mieć nazwy ze znakami nie alfanumerycznymi - jest to ważne, gdyż część opcji można konfigurować dla konkretnego ESSID-a.
Na domiar złego, Gentoo używa zmiennych bashowych do kontrolowania sieci - a bash nie potrafi korzystać z niczego co pochodzi spoza angielskich znaków alfanumerycznych. Aby ominąć te ograniczenie, każdy znak pochodzący spoza znaków dopuszczalnych zamieniany jest na znak _.
Kolejnym ograniczeniem powłoki bash jest to, że niektóre ze znaków muszą być specjalnie cytowane, czyli musi pojawić się przed nimi symbol \. Znaki, których to dotyczy to ", ' oraz \.
W poniższym przykładzie, zostaje użyty bezprzewodowy ESSID z najszerszym możliwym zestawem znaków. Zostanie użyty ESSID My "\ NET:
Listing 3.1: przykład nazewnictwa zmiennej |
(Poniższe działa, ale domena jest nieprawidłowa) dns_domain_My____NET="My \"\\ NET" (Powyższe ustawienia ustawiają domenę dns jako My "\ NET gdy karta #bezprzewodowa połączy się z punktem dostępu którego ESSID to My "\ NET) |
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 |
# iproute2 ważniejsze niż ifconfig modules=( "iproute2" ) # Można również określić inne moduły dla interfejsu. # W tym przypadku pump jest ważniejsze niż dhcpcd modules_eth0=( "pump" ) # Możliwe jest również określenie których modułów nie używać wcale - # przykładowo może być używana kliencka lub kontrolowana przez linux-wlan-ng # konfiguracja wifi, jednakże zachodzi potrzeba skonfigurowania własnych # ustawień sieciowych dla każdego ESSID-a z którym sieć jest powiązana osobno. modules=( "!iwconfig" ) |
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 # Aby iproute2 miało wyższy priorytet niż ifconfig, w przypadku gdy obydwa są zainstalowane modules=( "iproute2" ) |
Jako że ifconfig oraz iproute2 są podobne w działaniu, można pozwolić, aby ich podstawowa konfiguracja współpracowała ze sobą. Dla przykładu, poniższe linijki współpracują z obydwoma programami.
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" )
# Można również zdefiniować adres broadcast
config_eth0=( "192.168.0.2/24 brd 192.168.0.255" )
config_eth0=( "192.168.0.2 netmask 255.255.255.0 broadcast 192.168.0.255" )
|
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.
Listing 3.1: Przykładowa konfiguracja DHCP w /etc/conf.d/net |
# Potrzebne tylko wtedy, gdy jest więcej niż jeden moduł DHCP modules=( "dhcpcd" ) config_eth0=( "dhcp" ) dhcpcd_eth0="-t 10" # Wygaśnięcie po 10 sekundach dhcp_eth0="release nodns nontp nonis" # Zdobywa jedynie adres |
Uwaga: dhcpcd, udhcpc oraz pump domyślnie wysyłają aktualną nazwę hosta do serwera DHCP wobec czego nie trzeba tego definiować. |
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 ) (Używamy nazwy własnego interfejsu sieciowego) config_ppp0=( "ppp" ) link_ppp0="eth0" (Używamy nazwy własnego interfejsu sieciowego) plugins_ppp0=( "pppoe" ) username_ppp0='user' password_ppp0='password' pppd_ppp0=( "noauth" "defaultroute" "usepeerdns" "holdoff 3" "child-timeout 60" "lcp-echo-interval 15" "lcp-echo-failure 3" noaccomp noccp nobsdcomp nodeflate nopcomp novj novjccomp ) depend_ppp0() { need net.eth0 } |
Hasło możemy również przechowywać w pliku /etc/ppp/pap-secrets.
Listing 4.4: Przykładowy plik /etc/ppp/pap-secrets |
# * jest bardzo ważna
"username" * "password"
|
Jeżeli używamy PPPoE z modemem USB musimy zainstalować br2684ctl. Aby poprawnie go skonfigurować należy przeczytać /usr/portage/net-dialup/speedtouch-usb/files/README.
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 |
# Najpierw próbujemy skonfigurować poprzez DHCP - jeżeli to się nie powiedzie, próbujemy APIPA config_eth0=( "dhcp" ) fallback_eth0=( "apipa" ) # Należy użyć jedynie APIPA config_eth0=( "apipa" ) |
3.f. Wiązanie urządzeń sieciowych
Aby mieć możliwość łączenia urządzeń sieciowych, należy zainstalować net-misc/ifenslave.
Łączenie urządzeń sieciowych stosuje się w celu zwiększenia przepustowości sieci. Jeżeli w komputerze są do dyspozycji dwie karty sieciowe znajdujące się w tej samej sieci, można je połączyć tak, żeby aplikacje w rzeczywistości używały obu urządzeń jednocześnie.
Listing 6.1: Konfiguracja łączenia w /etc/conf.d/net |
Aby połączyć urządzenia razem slaves_bond0="eth0 eth1 eth2" # Jeżeli nie trzeba przypisywać adresu IP do interfejsu config_bond0=( "null" ) # Zależne od eth0, eth1 oraz eth2 jako, że mogą wymagać dodatkowej konfiguracji depend_bond0() { need net.eth0 net.eth1 net.eth2 } |
3.g. Mostkowanie (wsparcie dla 802.1d)
Aby mieć możliwość mostkowania, należy zainstalować net-misc/bridge-utils.
Mostkowanie jest używane do łączenia w całość dużych sieci. Dla przykładu można mieć serwer, który łączy się z internetem przy pomocy ADSL oraz ma połączenie z bezprzewodową kartą sieciową by umożliwić innym komputerom łączenie się z internetem przy pomocy modemu ADSL. Można stworzyć mostek do połączenia obydwu interfejsów.
Listing 7.1: Konfiguracja mostka w /etc/conf.d/net |
# Konfiguracja mostka - "man brctl", aby uzyskać szczegółowe informacje brctl_br0=( "setfd 0" "sethello 0" "stp off" ) # Aby dodać porty do mostka br0 bridge_br0="eth0 eth1" # Należy skonfigurować porty jako wartość null tak aby dhcp nie uruchomiło się config_eth0=( "null" ) config_eth1=( "null" ) # Na koniec należy nadać mostkowi adres - można również użyć DHCP config_br0=( "192.168.0.1/24" ) # Należy zależeć od eth0 oraz eth1 jako że mogą wymagać dodatkowej konfiguracji depend_br0() { need net.eth0 net.eth1 } |
Ważne: Aby korzystać z niektórych ustawień mostków, warto zajrzeć do dokumentacji opisującej nazwy zmiennych. |
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 |
# Aby przypisać adres MAC konkretnemu urządzeniu mac_eth0="00:11:22:33:44:55" # Aby tylko ostatnie trzy bajty były losowe mac_eth0="random-ending" # Aby wybierać losowo pomiędzy tym samym fizycznym połączeniem (np. # światłowód, miedź lub bezprzewodowo), wszyscy producenci mac_eth0="random-samekind" # Aby wybierać losowo pomiędzy różnymi fizycznymi połączeniami (np. światłowód, miedź lub bezprzewodowo), wszyscy producenci mac_eth0="random-anykind" # Pełna losowość - UWAGA: niektóre adresy MAC wygenerowane w ten sposób mogą zachowywać się inaczej niż powinny mac_eth0="random-full" |
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 |
# Dla tuneli GRE iptunnel_vpn0="mode gre remote 207.170.82.1 key 0xffffffff ttl 255" # Dla tuneli IPIP iptunnel_vpn0="mode ipip remote 207.170.82.2 ttl 255" # Aby skonfigurować interfejs config_vpn0=( "192.168.0.2 peer 192.168.1.1" ) |
3.j. VLAN (wsparcie dla 802.1q)
Aby posiadać wsparcie dla VLAN, należy zainstalować net-misc/vconfig.
VLAN to grupa urządzeń sieciowych które zachowują się tak, jakby były podłączone do jednego segmentu sieciowego - nawet jeśli tak nie jest. Członkowie VLAN-u mogą jedynie widzieć innych członków VLAN-u, nawet jeśli współdzielą sieć z innymi urządzeniami.
Listing 10.1: Konfiguracja VLAN w /etc/conf.d/net |
# Wyznaczanie numerów VLAN dla urządzeń # Należy być pewnym, że ID VLAN-u NIE składają się z zera vlans_eth0="1 2" # Można również skonfigurować sam VLAN # wystarczy zajrzeć do manuala vconfig, aby uzyskać szczegółowe #informacje vconfig_eth0=( "set_name_type VLAN_PLUS_VID_NO_PAD" ) vconfig_vlan1=( "set_flag 1" "set_egress_map 2 6" ) # Konfiguracja interfejsu w tradycyjny sposób config_vlan1=( "172.16.3.1 netmask 255.255.254.0" ) config_vlan2=( "172.16.2.1 netmask 255.255.254.0" ) |
Ważne: Aby używać niektórych ustawień VLAN, może zajść potrzeba zajrzenia do dokumentacji opisującej nazwy zmiennych. |
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. |
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 |
# wpa_supplicant będzie użyty przed wireless-tools modules=( "wpa_supplicant" ) # Bardzo istotne jest, aby wskazać wpa_supplicant który sterownik # powinien zostać użyty, gdyż na obecnym etapie rozwoju nie jest jeszcze # najlepszy w samodzielnym zgadywaniu wpa_supplicant_eth0="-Dmadwifi" |
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 |
# Zmiana poniższej linijki może spowodować, że wpa_supplicant nie będzie działać ctrl_interface=/var/run/wpa_supplicant # Należy być pewnym, że tylko root ma dostęp do konfiguracji WPA ctrl_interface_group=0 # Niech wpa_supplicant zajmie sie wyszukiwaniem i ustawianiem AP ap_scan=1 # Prosty przykład: WPA-PSK, PSK oraz hasło w ASCII umożliwiają poprawną autoryzację network={ ssid="proste" psk="bardzo tajne hasło" # Im wyższy priorytet, tym wcześniej zostanie dopasowane priority=5 } # Podobne jak poprzednie, ale będzie dokonane skanowanie SSID-ów (dla # AP, które nie wysyłają swojego SSID-a) network={ ssid="drugi ssid" scan_ssid=1 psk="bardzo tajne hasło" priority=2 } # Jedynie WPA-PSK jest używane. Dowolna kombinacja hasła jest akceptowana network={ ssid="przykład" proto=WPA key_mgmt=WPA-PSK pairwise=CCMP TKIP group=CCMP TKIP WEP104 WEP40 psk=06b4be19da289f475aa46a33cb793029d4ab3db7a23ee92382eb0106c72ac7bb priority=2 } # Połączenie bez szyfrowania (brak WPA, brak IEEE 802.1X) network={ ssid="test-bez-szyfrowania" key_mgmt=NONE } # Połączenie ze współdzielonym WEP (brak WPA, brak IEEE 802.1X) network={ ssid="test-statycznego-wep" key_mgmt=NONE # Klucze umieszczone w cudzysłowiach są kluczami ASCII wep_key0="abcde" # Klucze bez cudzysłowiów są kluczami w postaci szesnastkowej wep_key1=0102030405 wep_key2="1234567890123" wep_tx_keyidx=0 priority=5 } # Połączenie ze współdzielonym WEP z kluczem (brak WPA, brak IEEE # 802.1X) używając autoryzację ze współdzielonym kluczem IEEE 802.11 network={ ssid="test2-statycznego-wep" key_mgmt=NONE wep_key0="abcde" wep_key1=0102030405 wep_key2="1234567890123" wep_tx_keyidx=0 priority=5 auth_alg=SHARED } # Sieć IBSS/ad-hoc z WPA-None/TKIP network={ ssid="test adhoc" mode=1 proto=WPA key_mgmt=WPA-NONE pairwise=NONE group=TKIP psk="tajne hasło" } |
4.c. Narzędzia do sieci bezprzewodowych
Wstępna konfiguracja i tryb zarządzany
Wireless Tools posiadają podstawowe metody na konfigurację podstawowych interfejsów sieci bezprzewodowych aż do ustawień poziomu zabezpieczeń WEP. Mimo, że WEP to dość słaba metoda zabezpieczeń, jest najczęściej stosowana.
Konfiguracje Wireless Tools są kontrolowane przy pomocy kilku głównych zmiennych. Przykładowa konfiguracja poniżej powinna opisać wszystko co jest potrzebne. Jedyne o czym należy pamiętać, to fakt, że dana konfiguracja nie oznacza "połącz się z najlepszym nieszyfrowanym access pointem" - zawsze nastąpi próba połączenia z czymkolwiek.
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 |
# W pierwszej kolejności zostanie użyte iwconfig przed wpa_supplicant modules=( "iwconfig" ) # Konfiguracja dla Access Pointów nazwanych ESSID1 oraz ESSID2 # Można skonfigurować do 4 kluczy WEP, ale tylko jeden może być aktywny # w danym momencie, tak aby domyślny indeks [1] był ustawiony na klucz [1] i z # powrotem aby ustawić klucz na [1]. Dokonuje się tego w przypadku gdy # ESSID został skonfigurowany dla kluczy WEP innych niż 1. # Poprzedzając klucz przy pomocy s: oznacza że jest to klucz w ASCII, w innym # przypadku jest to klucz w HEX # enc open oznacza otwarte bezpieczeństwo (najbezpieczniejsze) # enc restricted oznacza zastrzeżone bezpieczeństwo (mniej bezpieczne) key_ESSID1="[1] s:twojklucz key [1] enc open" key_ESSID2="[1] aaaa-bbbb-cccc-dd key [1] enc restricted" # Poniższe zadziała tylko gdy będą poszukiwane dostępne Access Pointy # Niekiedy widocznych jest więcej Access Pointów, więc należy # zdefiniować który jest preferowany i w jakiej kolejności należy się łączyć preferred_aps=( "ESSID1" "ESSID2" ) |
Konfiguracja wyboru punktów dostępu
Można dodać kilka opcji, aby lepiej skonfigurować wybór Access Pointów, jednakże na ogół nie są one wymagane.
Można zdecydować czy łączymy się tylko z preferowanymi Access Pointami czy nie. Domyślnie, jeśli żadne z ustawień nie zadziałają i można połączyć się do nieszyfrowanego Access Pointa, to nastąpi połączenie. Można to kontrolować przy pomocy zmiennej associate_order. Poniżej znajduje się tabela z wartościami oraz jak wpływają na kontrolę.
| 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 |
# Niekiedy nie powinno nastąpić połączenie do poszczególnych access pointów blacklist_aps=( "ESSID3" "ESSID4" ) # Jeżeli jest więcej niż jedna karta bezprzewodowa, można określić czy # powinno nastąpić połączenie każdej karty z tym samym punktem dostępu czy nie # Wartości to "yes" (tak) lub "no" (nie) # Domyślnie jest "yes" unique_ap="yes" |
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 |
# Ustawienie trybu - może być zarządzany (domyślnie), ad-hoc lub # zarządcy. Nie wszystkie sterowniki umożliwiaj skorzystanie z tych trybów mode_eth0="ad-hoc" # Ustawienie ESSID interfejsu # W trybie zarządzanym, zmusza to interfejs do połączenia się z wyznaczonym # ESSIESSID-em niczym innym essid_eth0="Ten węzeł Adhoc" # Jeśli nie zostanie wyznaczony żaden inny, zostanie użyty 3. channel_eth0="9" |
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" ) # Można skonfigurować serwery nazw i inne rzeczy # NOTATKA: DHCP to przepisze, chyba że zostanie ustawione inaczej dns_servers_ESSID1=( "192.168.0.1" "192.168.0.2" ) dns_domain_ESSID1="some.domain" dns_search_domains_ESSID1="szukaj.tej.domeny szukaj.tamtej.domeny" # Nadpisuje się adres MAC adresem Access Pointa. Jest to przydatne gdy # zachodzi potrzeba przemieszczania się między różnymi lokalizacjami, które # posiadają ten sam ESSID config_001122334455=( "dhcp" ) dhcpcd_001122334455="-t 10" dns_servers_001122334455=( "192.168.0.1" "192.168.0.2" ) |
5.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() {
# Sprawdza czy istnieje link na interfejsie, który jest
# uruchamiany. Ta opcja działa jedynie na kilku urządzeniach
# sieciowych i wymaga, aby pakiet ethtool był zainstalowany
if ethtool ${IFACE} | grep -q 'Link detected: no'; then
ewarn "Brakuje linku na ${IFACE}, przerywam konfigurację"
return 1
fi
# Należy pamiętać o zwróceniu wartości 0 w przypadku powodzenia
return 0
}
predown() {
# Domyślny skrypt sprawdza czy istnieje katalog główny NFS i
# nie zezwala na wyłączenie interfejsów w takim przypadku. Należy
# zauważyć, że jeśli określi się własną funkcję predown(), to właściwość
# ta zostanie usunięta. Poniżej znajduje się ten skrypt, jeśli okazałoby
# się, że jest nadal potrzebny...
if is_net_fs /; then
eerror "katalog główny jest zamontowany przez sieć -- nie można zatrzymać ${IFACE}"
return 1
fi
# Należy pamiętać o zwróceniu wartości 0 w przypadku powodzenia
return 0
}
postup() {
# Ta funkcja zostanie użyta dla przykładu, aby zarejestrować
# interfejs z usługą DNS. Inną możliwością jest np. wysłanie wiadomości
# mailowej z informacją o uruchomieniu interfejsu
return 0
}
postdown() {
# Ta funkcja jest tu tylko dla zasady... Jeszcze nie
# wiadomo co fajnego można z nią zrobić ;-)
return 0
}
|
5.b. Funkcje dla sieci bezprzewodowych
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() {
# Poniższe linijki dodają dwie zmienne leap_user_ESSID oraz
# leap_pass_ESSID. Jeżeli obie są skonfigurowane dla ESSID-a z którym są
# połączone, uruchamiany jest skrypt CISCO LEAP
local user pass
eval user=\"\$\{leap_user_${ESSIDVAR}\}\"
eval pass=\"\$\{leap_pass_${ESSIDVAR}\}\"
if [[ -n ${user} && -n ${pass} ]]; then
if [[ ! -x /opt/cisco/bin/leapscript ]]; then
eend "For LEAP support, please emerge net-misc/cisco-aironet-client-utils"
return 1
fi
einfo "Waiting for LEAP Authentication on \"${ESSID//\\\\//}\""
if /opt/cisco/bin/leapscript ${user} ${pass} | grep -q 'Login incorrect'; then
ewarn "Login Failed for ${user}"
return 1
fi
fi
return 0
}
postassociate() {
# Ta funkcja jest tu tylko dla zasady... Jeszcze nie
# wiadomo co fajnego można z nią zrobić ;-)
return 0
}
|
Uwaga: ${ESSID} oraz ${ESSIDVAR} są niedostępne dla funkcji predown() oraz postdown(). |
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. |
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 |
(Zastępujemy eth0 nazwą interfejsu, który chcemy monitorować) ifplugd_eth0="..." (Aby monitorować kartę sieci bezprzewodowej) ifplugd_eth0="--api-mode=wlan" |
Jeżeli zechcemy zarządzać wieloma połączeniami sieciowymi, będziemy potrzebowali narzędzia, które pomoże nam w pracy z wieloma serwerami DNS oraz wieloma konfiguracjami. Jest to bardzo przydatne, gdy adres IP otrzymujemy za pomocą DHCP. Do tego celu instalujemy openresolv.
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.