Migracja na Baselayout-2 i OpenRC
1.
Tło
Czym jest baselayout?
Baselayout dostarcza podstawowego zestawu plików takich jak
/etc/hosts, niezbędnych do prawidłowej pracy wszystkich
systemów. Dostarcza również podstawowego układu systemu plików używanego
przez Gentoo (na przykład katalogi /etc, /var,
/usr, /home).
Czym jest OpenRC?
OpenRC jest bazującym na zależnościach systemem uruchomieniowym, który może
działać z dowolnym init dostarczanym przez system, zazwyczaj
/sbin/init. Nie jest on jednak zastępstwem dla
/sbin/init. Standardowy init używany w Gentoo Linux to
sys-apps/sysvinit, natomiast Gentoo/FreeBSD korzysta z init FreeBSD
zawartego w pakiecie sys-freebsd/freebsd-sbin.
Po co więc migrować?
Pierwotnie system uruchomieniowy Gentoo był wbudowany w baselayout 1 i w
całości napisany w bashu. Doprowadziło to do kilku ograniczeń. Na
przykład, pewne wywołania systemowe muszą być dostępne podczas
uruchamiania systemu, a to wymagało dodania wywołań opartych na języku C.
Wywołania te były dowiązane statycznie i stale zmuszały system
uruchomieniowy do nadawania wspomnianego dostępu.
Dodatkowo, gdy Gentoo rozszerzyło się na inne platformy, takie jak
Gentoo/FreeBSD czy Gentoo Embedded stało się niemożliwym, by wymagać systemu
uruchomieniowego bazującego na bashu. Doprowadziło to do powstania baselayout 2,
który napisany został w C i wymaga jedynie powłoki zgodnej z POSIX. Podczas
rozwoju baselayout 2 ustalono, że najlepiej będzie, jeśli baselayout po
prostu dostarczy podstawowych plików i układu systemu plików dla Gentoo, a
system uruchomieniowy zostanie przeniesiony do osobnego pakietu. Tak powstał
OpenRC.
OpenRC jest rozwijane głównie przez
Roya Marples'a i wspiera wszystkie istniejące obecnie wariacje Gentoo
(na przykład Gentoo Linux Gentoo/FreeBSD, Gentoo Embedded i Gentoo Vserver) oraz
inne platformy takie jak FreeBSD i NetBSD.
2.
Migracja na OpenRC
Migracja do OpenRC jest całkiem prosta; będzie ona umieszczona jako część
zwyczajowych aktualizacji systemu dokonywanych za pomocą menadżera pakietów.
Właściwie najważniejszy krok ma miejsce już po zainstalowaniu nowych pakietów
>=sys-apps/baselayout-2 i sys-apps/openrc. Przed ponownym
uruchomieniem komputera, krytycznym krokiem jest wykonanie
dispatch-conf i upewnienie się, że pliki w /etc zostały
zaktualizowane. Pominięcie tego może doprowadzić do nieuruchamiającego
się systemu i wymagać będzie użycia Gentoo LiveCD, w celu
przeprowadzenia poniższych kroków, które naprawią niedziałający system.
Gdy już wszystkie pliki konfiguracyjne zostaną zaktualizowane, zostanie jeszcze
kilka rzeczy, które koniecznie należy sprawdzić przed ponownym uruchomieniem
komputera.
/etc/conf.d/rc
Plik /etc/conf.d/rc jest przestarzały i wszystkie ustawienia w nim
zapisane muszą zostać przeniesione do odpowiadających ustawień w
/etc/rc.conf. Należy przeczytać oba pliki /etc/rc.conf
i /etc/conf.d/rc, a następnie przenieść ustawienia. Po wykonaniu
migracji należy skasować plik /etc/conf.d/rc.
Moduły jądra
Zazwyczaj gdy istniała potrzeba załadowania pewnych modułów automatycznie
podczas uruchamiania systemu, były one umieszczone w
/etc/modules.autoload.d/kernel-2.6 razem z wybranymi parametrami. W
baselayout-2 plik ten nie jest już używany. Zamiast niego wszystkie dodatkowe
moduły ładowane podczas startu i ich parametry, niezależnie od wersji jądra,
zostały umieszczone w pliku /etc/conf.d/modules.
Przykładem starego stylu konfiguracji będzie:
Listing 2.1: /etc/modules.autoload.d/kernel-2.6 |
ivtv
cx88_dvb video_br=2
|
Konwersja powyższego skutkować będzie poniższym:
Listing 2.2: /etc/conf.d/modules |
modules_2_6="ivtv cx88_dvb"
module_cx88_dvb_args_2_6="video_br=2"
|
W powyższych przykładach moduły i ich parametry będą działać jedynie na jądrach
z serii 2.6. Nowy sposób konfiguracji pozwala na łatwą kontrolę nad modułami i
ich parametrami bazującą na wersji jądra.
Bardziej szczegółowy przykład:
Listing 2.3: Szczegółowy przykład /etc/conf.d/modules |
modules="ohci1394 ieee1394"
modules_2_6="tun usbserial"
modules_2_6_23="cx88_dvb"
modules_2_6_23_gentoo_r5="ivtv"
module_cx88_dvb_args_2_6_23_gentoo_r5="video_br=2"
module_usbserial_args_2_6="vendor=0x1410 product=0x2110"
module_ieee1394_args="debug"
|
Uwaga:
Należy zwrócić uwagę na różnicę pomiędzy module_ a modules_.
|
Poziom uruchomieniowy boot
Poziom uruchomieniowy boot dokonuje kilku ważnych kroków dla każdego
komputera. Sprawdza na przykład, czy główny system plików jest zamontowany w
trybie zapisu i odczytu, czy partycje zostały sprawdzone i nie zawierają błędów,
czy punkty montowania są dostępne i czy system plików /proc został
uruchomiony podczas startu.
W OpenRC usługi zarządzające woluminami urządzeń blokowych nie są teraz
uruchamiane standardowo podczas startu systemu. Zaliczają się do nich usługi
takie jak: lvm, raid, swap, device-mapper (dm), dm-crypt, evms i podobne. Należy
upewnić się, że skrypty init odpowiednie dla powyższych usług umieszczone są w
poziomie uruchomieniowym boot. W przeciwnym wypadku, możliwym jest, że
system nie będzie w stanie się uruchomić!
Podczas gdy ebuild OpenRC będzie usiłował dokonać migracji ustawień
automatycznie, konieczne będzie sprawdzenie czy wszystko przebiegło prawidłowo:
Listing 2.4: Sprawdzenie wszystkich usług poziomu uruchomieniowego boot |
# ls -l /etc/runlevels/boot/
|
Jeżeli wynik powyższego polecenia nie pokaże root, procfs, mtab, swap i fsck,
należy wykonać poniższe polecenia, aby dodać je do poziomu uruchomieniowego
boot:
Listing 2.5: Dodawanie krytycznych usług do poziomu uruchomieniowego boot |
# rc-update add root boot
# rc-update add procfs boot
# rc-update add mtab boot
# rc-update add fsck boot
# rc-update add swap boot
|
W przypadku gdy użytkownik korzysta z mdraid bądź lvm, a nie widnieją one na
powyższej liście, konieczne będzie wykonanie poniższych poleceń, by dodać te
usługi do poziomu uruchomieniowego boot:
Listing 2.6: Dodawanie brakujących usług zarządzania woluminami do poziomu uruchomieniowego boot |
# rc-update add raid boot
# rc-update add lvm boot
|
Udev
OpenRC nie uruchamia udev domyślnie, obecnie musi on być dodany na poziom
uruchomieniowy sysinit. Ebuild OpenRC powinien wykryć czy udev był
wcześniej używany i doda go do sysinit automatycznie. Dla pewności jednak
warto sprawdzić czy to się naprawdę wydarzyło i czy udev tam się naprawdę
znajduje.
Listing 2.7: Sprawdzanie czy udev jest uruchamiany |
# ls -l /etc/runlevels/sysinit
lrwxrwxrwx 1 root root 14 2009-01-29 08:00 /etc/runlevels/sysinit/udev -> \
/etc/init.d/udev
|
Jeśli udev nie ma na liście, dodajemy go tam:
Listing 2.8: Dodawanie udev na poziom uruchomieniowy sysinit |
# rc-update add udev sysinit
|
Sieć
Z powodu rozdzielenia baselayout i OpenRC na dwa różne pakiety, skrypt startowy
net.eth0 może zostać usunięty podczas procesu aktualizacji. Aby zastąpić ten
skrypt init należy wykonać poniższe:
Listing 2.9: Ponowne tworzenie brakującego skryptu net.eth0 |
# cd /etc/init.d
# ln -s net.lo net.eth0
|
W przypadku, gdy brakuje jakichkolwiek innych skryptów startowych sieci, należy
dodać je ponownie, zwyczajnie zastępując eth0 nazwą brakującego
urządzenia sieciowego.
Także, /etc/conf.d/net nie korzysta już ze składni znanej z basha.
Należy więc przyjrzeć się plikowi
/usr/share/doc/openrc/net.example, w którym podano instrukcje
dotyczące konfiguracji. Konwersja powinna być stosunkowo nieskomplikowana. Dla
przykładu konfiguracja statycznie przypisanego IP powinna zostać zmieniona jak
niżej:
Listing 2.10: Stary styl konfiguracji /etc/conf.d/net |
config_eth0=( "192.168.1.37 netmask 255.255.255.0 brd 192.168.1.255" )
routes_eth0=( "default via 192.168.1.100" )
|
Listing 2.11: Nowy styl konfiguracji /etc/conf.d/net |
config_eth0="192.168.1.37 netmask 255.255.255.0 brd 192.168.1.255"
routes_eth0="default via 192.168.1.100"
|
Zegar
Ustawienia zegara zmieniły nazwę z /etc/conf.d/clock na natywne
narzędzie systemowe regulujące zegar. Oznacza to, że w Linuksie będzie to
/etc/conf.d/hwclock, natomiast we FreeBSD będzie to
/etc/conf.d/adjkerntz. Nazwa skryptu init umieszczonego w
/etc/init.d/ także została zmieniona na odpowiednią dla danego
systemu. Należy się więc upewnić, że jest umieszczona w odpowiednim poziomie
uruchomieniowym.
Dodatkowo, zmienna TIMEZONE nie jest już obecna w wymienionym pliku.
Można ją teraz znaleźć w pliku /etc/timezone. Jeśli plik ten
nie istnieje, oczywiście należy go utworzyć umieszczając w nim swoją strefę
czasową. Należy więc jeszcze raz przyjrzeć się obydwu plikom aby być pewnym ich
poprawności.
Właściwa wartość dla tego pliku jest odpowiadająca strefie czasowej
użytkownika ścieżka z /usr/share/zoneinfo. Na przykład, osoba
mieszkająca na wschodnim wybrzeżu Stanów Zjednoczonych Ameryki powinna użyć
ustawienia:
Listing 2.12: /etc/timezone |
America/New_York
|
XSESSION
Zmienna XSESSION nie jest już obecna w /etc/rc.conf. W zamian
zmienną tę możemy ustawić na użytkownika w pliku ~/.bashrc (lub
odpowiedniku) lub na cały system w katalog /etc/env.d.
Poniżej znajduje się przykład ustawienia zmiennej XSESSION dla całego systemu:
Listing 2.13: Ustawianie zmiennej XSESSION |
# echo 'XSESSION="Xfce4"' > /etc/env.d/90xsession
|
Ważne:
Po utworzeniu pliku w /etc/env.d koniecznym jest wykonanie
env-update. Aby nowe ustawienia odniosły skutek należy wylogować się i
zalogować ponownie. W przypadku użycia pliku ~/.bashrc, aby nowe
ustawienia zostały zastosowane należy wydać polecenie source ~/.bashrc.
|
EDITOR i PAGER
Zmienna EDITOR nie jest już obecna w /etc/rc.conf. Obydwie zmienne
EDITOR i PAGER ustawione są domyślnie w /etc/profile. Namawia się
użytkowników do ustawienia ich samodzielnie wedle potrzeb w pliku
~/.bashrc (lub odpowiedniku) bądź utworzenia pliku
/etc/env.d/99editor i ustawienie tam zmiennych.
Ważne:
Po utworzeniu pliku w /etc/env.d, koniecznym jest, aby wykonać
env-update. Aby nowe ustawienia odniosły skutek należy wylogować się i
zalogować ponownie. W przypadku gdy zmienna została ustawiona w
~/.bashrc, można wczytać nowe ustawienia wykonując source
~/.bashrc.
|
Logowanie uruchomienia systemu
Poprzednio, aby logować proces uruchamiania systemu musieliśmy użyć pakietu
app-admin/showconsole. Obecnie jednak, OpenRC posiada wewnętrzny system
logowania. Nie musimy więc stosować sztuczek jakich używa showconsole.
Aby logować informacje z uruchamiania systemu wystarczy ustawić odpowiednią
zmienną w pliku /etc/rc.conf. Logi pojawią się w pliku
/var/log/rc.log.
Listing 2.14: Uaktywnienia logowania w pliku /etc/rc.conf |
rc_logger="YES"
|
Zakończenie
W momencie gdy wszystkie pliki konfiguracyjne i skrypty rozruchowe zostaną
zaktualizowane, ostatnią rzeczą którą należy zrobić jest ponowne uruchomienie
komputera. Jest to konieczne, ponieważ informacje o stanie systemu nie są
zachowywane podczas aktualizacji. Należy więc dostarczyć ich poprzez ponowne
uruchomienie.
Materiał udostępniany na podstawie licencji Creative Commons -
Attribution / Share Alike.
|