Nie lubię Slackware’a. Och nie, nie! Nie kamienujcie mnie od razu! Slackware to bardzo dobry system. Tylko nie bardzo zgodny z moim charakterem. Najstarsza istniejąca dystrybucja Linuksa, chyba jedyna w pełni zgodna z pierwotnymi założeniami UNIX-a, funkcjonuje według filozofii „zrób to sam”. Jest stabilna i wydajna, jak się ją już skonfiguruje. Problem w tym, że ja często wymieniam oprogramowanie i to ciągłe zmienianie zawartości plików konfiguracyjnych „z ręki”, to permanentne sprawdzanie czy wersje programów składowych się zgadzają… No, na taki serwer, który się konfiguruje raz, a dobrze, jest to dystrybucja jak znalazł. Albo jakby tak rozsądnie wybrać oprogramowanie, zainstalować, solidnie skonfigurować i wypalić na płycie jako LiveCD. Tak… i dodać jeszcze logo w kształcie czterolistnej koniczynki na szczęście… O, to by było coś!

Nowe wcielenie SLAX-a, 6.0 rc 6 wydane 26 lipca Roku Pańskiego 2007 można by było opisać krótko: Linux 2.6.21.5, KDE 3.5.7, xorg-server 1.3.0, KOffice 1.6.3 i tak dalej, ale to przecież można wyczytać na stronie dystrybucji albo na distrowatch.com. Ja, jeśli Państwo pozwolicie, chciałbym się skupić nie na tym co, ale jak to działa. Oczywiście nie kompleksowo, ale mam nadzieję, że i tak będzie ciekawie. Zaznaczam przy tym na wstępie, iż zakładam, że czytelnik widział już w swoim życiu jakąkolwiek dystrybucję GNU/Linux, wie, choćby w ogólnym zarysie, jak wygląda drzewo katalogów systemu UNIX i słyszał, choćby tylko z nazwy, o poleceniu mount.
Zanim jednak przejdę do szczegółów…

Kilka słów o LiveCD

Co to jest LiveCD? Ogólnie, krótko: dystrybucja systemu operacyjnego, którą da się uruchomić z nośnika optycznego. Tak, ale czy wszystkie LiveCD bazujące na Linuksie, a wspomniany serwis distrowatch.com zawiera opis grubo ponad 150 takich dystrybucji, można wkładać do jednego worka? Według mnie nie. Na użytek niniejszego artykułu wprowadźmy mały – poglądowy podział na cztery grupy:

1. Dema – przykładem może tu być openSUSE Live, czy na przykład Symphony OS. Pierwsza z nich ma za zadanie prezentację możliwości systemu openSUSE. Nie bójmy się pewnych dosadnych stwierdzeń. W środowisku Live dystrybucji openSUSE pracować się nie da… o ile się człowiek naprawdę nie uprze. System Novella w ogóle nie należy do demonów szybkości, a uruchamiany z płyty działa odpowiednio wolniej. Ale też nie chodzi tutaj o pracę, a o pokazanie, jak system wygląda, tak, by nie trzeba było go uprzednio instalować. Druga z wspomnianych dystrybucji prezentuje środowisko ciekawego pulpitu – Mezzo. Do tej grupy zaliczyłbym jeszcze choćby: Elive, Mandrivę Live czy na przykład LG3D.
2. Instalatory – do tej grupy należy przede wszystkim SimplyMEPIS, Ubuntu CD, Dreamlinux czy GoboLinux. Osobiście nie znam prostszej metody instalacji systemu niż ta, którą zaproponował w 2003 roku Warren Woodford. Każdy z systemów tej grupy jest również rodzajem prezentacji sytemu, lecz w odróżnieniu od grupy poprzedniej ich głównym zadaniem jest dostarczenie wygodnego i prostego sposobu instalacji systemu. Dodatkowo, płyta taka może być użyta do naprawy systemu uszkodzonego.
3. Dystrybucje specjalizowane – GParted, którego zadaniem jest dostarczenie narzędzi do partycjonowania dysku, Clusterix i clusterKNOPPIX zawierające wszystko co niezbędne do budowy systemu przetwarzania rozproszonego, Devil-Linux stworzony z myślą o budowie zabezpieczeń sieciowych, czy wreszcie Hikarunix – dystrybucja dla graczy w Go. Wszystkie te dystrybucje istnieją z jakiegoś, konkretnego powodu – najczęściej jednego. Nie są więc przeznaczone do codziennej pracy, stanowią raczej panaceum na jakiś konkretny problem.
4. LiveCD „właściwe” – czyli SLAX, KNOPPIX, Puppy Linux, itp… Czy Linux LiveCD to po prostu nagrany na płytę system bazujący na Linuksie, który dostosowano do uruchamiania z płyty? Pytanie jest oczywiście retoryczne. Twórca poważnej dystrybucji typu Live przez cały czas jej tworzenia – od projektu, po końcowe testy – musi pamiętać, że dystrybucja będzie działać z nośnika tylko do odczytu, z ilością miejsca ograniczoną do 700 MB w przypadku klasycznego CD, który dodatkowo jest o wiele wolniejszy niż dysk twardy.

LiveCD na przykładzie SLAX-a

No dobrze. Spróbujmy rozłożyć ostatni punkt na czynniki. Mamy więc: problem szybkości, doboru oprogramowania i problem z zapisem danych. O dwóch pierwszych krótko, gdyż nie są przedmiotem niniejszego artykułu.

• Szybkość działania – temat sam w sobie. Napiszę więc bardzo krótko, że narzucająca się tu optymalizacja plików konfiguracyjnych optymalizacją, ale w pewnych przypadkach trzeba jednak zlikwidować „wąskie gardło”, jakim jest czas dostępu napędów optycznych. Można to zrobić na przykład poprzez przeniesienie kluczowych danych do pamięci operacyjnej. Niekoniecznie chodzi tu o tak zwany RAM-dysk, czyli fragment pamięci operacyjnej, który z punktu widzenia systemu operacyjnego „widziany jest” jako nośnik danych, przykładowo – mogą to być po prostu większe bufory danych.
• Wybór oprogramowania – zdroworozsądkowy. W dystrybucjach GNU/Linux praktycznie każdy program ma przynajmniej jeden alternatywny odpowiednik. Dość oczywiste, że trzeba wziąć pod uwagę szybkość działania i wielkość z jednej strony, ale także funkcjonalność i popularność z drugiej. Fakt, że na aplikację raz wybraną przez twórcę, użytkownicy są potem skazani nie upraszcza wyboru… No, z tym „skazaniem” nie jest tak źle, ale o tym za chwilę.
• I wreszcie – meritum tego artykułu. Otóż – wielkie odkrycie – płyta CD / DVD jest zasadniczo nośnikiem tylko do odczytu. Może to nawet być zaletą, jeśli jesteśmy właścicielem kafejki internetowej, albo nauczycielem, który ma do czynienia z niszczycielską młodzieżą, próbującą swoich sił jako początkujący hakerzy. LiveCD nie jest tu może optymalnym rozwiązaniem, ale działa. A do sprawdzenia poczty na Onecie możliwość zapisu nie jest niezbędna. Częściej jednak jest to problem, bo prędzej czy później zabraknie jakiegoś programu i chciałoby się też przecież zapisać efekty mrówczej pracy. Celem naszych działań uskutecznianych przy pomocy komputera nie jest wszakże obsługa systemu operacyjnego, a uzyskanie jakichś danych, najczęściej w postaci plików. Wydawałoby się, że sprawa jest beznadziejna. Jak do systemu na płycie doinstalować, dajmy na to GIMP-a? A jednak…

SLAX-a można dowolnie dostosowywać do swoich potrzeb

Tak, tak. SLAX pozwala na doinstalowywanie programów i co więcej, jest to bardzo proste. Powszechnie wiadomo, że Linux ma budowę modułową. W dystrybucji SLAX stwierdzenie to ma, jakby to powiedzieć… drugie dno. Otóż system ów składa się z modułów, które podczas jego startu składane są w jeden system plików, tworząc jedną całość. Domyślnie SLAX zawiera 9 modułów, które można zobaczyć zaglądając do katalogu slax/base na płycie. Dosłownie, przypomina to klocki LEGO. Osoba obdarzona dobrym refleksem, może zauważyć jak podczas startu SLAX pobiera poszczególne „fragmenty”:

To co jest najistotniejsze, to fakt, iż owe moduły można dodawać i usuwać według uznania. Załóżmy, że chcemy skorzystać z programu GIMP. Przede wszystkim, na stronie internetowej SLAX-a odnajdujemy sekcję modules, a w niej gotowy moduł zawierający aplikację GIMP. Teraz mamy dwa wyjścia. Możemy dodać moduł po uruchomieniu systemu, o czym będzie mowa pod koniec artykułu, albo przygotować własną płytkę z dodanym modułem, o czym będzie jeszcze dalej. Teraz jednak, jak już zapowiadałem wcześniej, ma być mowa nie o tym co ale w jaki sposób. Aby zrozumieć, jak to działa, musimy cofnąć się do elementarza systemu GNU/Linux i omówić…

Polecenie mount

Jak pisałem na wstępie, zakładam, że czytelnikowi nie jest obca, choćby pobieżna, znajomość struktury katalogów systemów uniksowych, i że słyszał o poleceniu mount. Dla „wyrównania poziomów” przypominam:

W systemach z rodziny UNIX wszystkie dostępne pliki zorganizowane są w jednym drzewie, hierarchii plików. Zasadą jest, że podstawą owej hierarchii jest katalog zwany root i oznaczany jako / (slash). Wszystkie pozostałe pliki i katalogi znajdują się wewnątrz katalogu root. Polecenie mount służy do przyłączania urządzeń i pod-hierarchii plików do głównego drzewa.

Czytelnik wie zapewne, że interfejsy poszczególnych urządzeń w systemie Linux znajdują się w katalogu /dev i nazywają się przykładowo:

/dev/hda – oznacza pierwszy (a) dysk fizyczny IDE (czyli – proszę wybaczyć kolokwializm – „zwykły”, w odróżnieniu od SATA lub SCSI),
/dev/hdd – czwarty (d), przy czym może to być nagrywarka CD / DVD,

Tak na marginesie, zastanawia mnie, czemu nigdzie nie pisze się po prostu, co nie jest dla osoby początkującej takie oczywiste, że oznaczenia te odpowiadają urządzeniom wypisywanym na ekranie komputera podczas POST, czyli podczas startu systemu. Proszę popatrzeć na obrazek.

Gdyby otworzyć komputer, zobaczylibyśmy dyski podłączone do płyty głównej, najprawdopodobniej przy pomocy szerokich „taśm”. Gdyby przyjrzeć się uważniej, dałoby się zauważyć, że taśmy te podłączone są do gniazd, obok których jest napisane coś w stylu „IDE 1″ oraz „IDE 2″. Oznacza to pierwszy i drugi kanał IDE. Podobnie, kiedy spojrzymy na ustawienia zworek na dyskach lub napędach CD / DVD, można zauważyć oznaczenia Master lub Slave. (No, tu może być jeszcze Single lub Cable Select, ale to nie wpływa na całość rozumowania.) Dysk, który ma ustawienie Master i podpięty jest do IDE 1 to nasz /dev/hda, napęd, który posiada ustawienie Slave i podpięty jest do IDE 2 to nasz /dev/hdd. Proste? Podobnie ma się sprawa z dyskami Serial ATA. Na płycie głównej (lub kontrolerze) można zauważyć oznaczenia takie jak SATA1 lub SATA2 i nietrudno się domyślić, że dysk podpięty do SATA1 to nasz /dev/sda.
To co nas interesuje bardziej, to fakt, że dyski fizyczne podzielone są logicznie na partycje. Z punktu widzenia oprogramowania, partycja „widziana jest” jako autonomiczny dysk. Co do zasady Linux posiada przynajmniej dwie partycje. Główną – zawierającą dane i pomocniczą – przestrzeń wymiany. Mogą to być:

/dev/hda1 – pierwszy dysk logiczny – partycja – na pierwszym dysku fizycznym,
/dev/hda2 – drugi dysk logiczny – partycja – na pierwszym dysku fizycznym.

Warto podkreślić, że urządzenie może być podłączone do dowolnego katalogu w hierarchii plików. Zwyczajowo dyski podłącza się w podkatalogach /mnt lub /media ale nie jest to zasadą.

Na zakończenie przypomnienia – konkretny przykład:

root@slax:/# mount /dev/hdd /mnt/cdrom -t iso9660 -o ro

Poszczególne składowe polecenia oznaczają:

mount – polecenie samo w sobie oczywiście;
/dev/hdd – co montujemy; tutaj – czwarty dysk IDE, czyli CD-ROM;
/mnt/cdrom – gdzie montujemy; tutaj do przygotowanego uprzednio katalogu /mnt/cdrom;
-t iso9660 – typ systemu plików; tutaj system stosowany w zapisie płyt CD;
-o ro – opcje – tutaj zaznaczamy, że system jest tylko do odczytu (Read Only). Wprawdzie polecenie mount i tak nie zamontuje nam płyty CD w trybie zapisu, ale podajemy dla zasady.

Oczywiście trzeba mieć prawa administratora. Dla porządku: ten i wszystkie następne przykłady testowane są na dystrybucji SLAX. Gdyby któryś z czytelników chciał powtórzyć samodzielnie opisywane tu polecenia, zachęcam, o ile to możliwe, do jej pobrania. Przede wszystkim, większość dystrybucji nie zawiera domyślnie opisywanych dalej mechanizmów. Po drugie na LiveCD można bez obaw „działać” na koncie administratora bez obawy zniszczenia systemu, co może być kłopotliwe na systemie „prawdziwym”… A tak w ogóle, to każdy testuje polecenia na własne ryzyko, bo Live CD daje nam pewne bezpieczeństwo… o ile oczywiście nie zapomnimy, że SLAX najprawdopodobniej automatycznie przyłączy nam nasz dysk twardy. (Taki żarcik… choć nie do końca…) A propos przyłączania dysków takie pytanie:

Czy przyłączać można tylko urządzenia?

Pytanie oczywiście sugeruje odpowiedź: Nie. Wróćmy do ostatniego przykładu. Owo /dev/hda1 będące interfejsem do pierwszej partycji, pierwszego dysku, jest to – proszę nie zapominać – plik. Niby oczywiste? Załóżmy, że mamy pewien szczególny plik o nazwie plikopartycja.img umieszczony w katalogu /pliki. Można napisać:

root@slax:/# mount /pliki/plikopartycja.img /mnt/test -o loop,rw

Polecenie jest jak najbardziej poprawne i zadziała. Jak taki odpowiedni plik utworzyć? Posłużymy się tu poleceniem o skomplikowanej nazwie dd, które służy do kopiowania oraz konwersji plików. Piszemy:

root@slax:/# mkdir /pliki

root@slax:/# dd if=/dev/zero of=/pliki/plikopartycja.img bs=1M count=4

Co po polsku znaczy mniej więcej tyle: „W katalogu /pliki utwórz plik o nazwie plikopartycja.img o rozmiarze czterech jedno-megabajtowych bloków, co da w sumie rozmiar czerech megabajtów i wypełnij go zerami”. Po rozłożeniu na czynniki pierwsze:

dd – oczywiście – polecenie we własnej osobie;
if=/dev/zero – plik z danymi wejściowymi (Input File); mm… to wymaga specjalnego komentarza…
of=/pliki/plikopartycja.img – plik z danymi wyjściowymi (Output File) – podajemy pełną ścieżkę;
bs=1M – rozmiar bloku (Block Size); 1 megabajt. Chodzi o to, że polecenie dd zapisuje dane „kawałkami”. Kiedy kopiujemy określony plik – nie ma sprawy – polecenie poradzi sobie samo. Tutaj jednak preparujemy nowy plik i rozmiar bloku należy podać, gdyż nie ma żadnych danych, aby ów rozmiar wyliczyć;
count=4 – po prostu ile bloków określonych powyżej ma zostać zapisanych; count=1024 dałoby tu oczywiście gigabajt.

Teraz szerzej o /dev/zero. Otóż katalog /dev, oprócz plików będących interfejsami do konkretnych – fizycznych urządzeń, zawiera również pliki specjalne. Plik zero, użyty w tym przykładzie, to zbiór zwracający zera (dokładnie: znak 0×00). W kółko. Jest to dość nietypowy przykład użycia owego zbioru. Zazwyczaj występuje on jako plik, do którego kierujemy dane wynikowe. Przykładowo:

root@slax:/# tar -cvvf root.tar /root 1> /dev/zero 2>&1

spowoduje przekierowanie tego, co program wypisałby na ekranie w niebyt. Z tego powodu plik zero bywa nazywany także „czarną dziurą”. Częściej stosuje się co prawda jego brata bliźniaka – plik /dev/null (dokładnie – znak końca pliku), lecz skutek jest ten sam.
Nie jest to jedyny dziwny zbiór tego typu. Przykładowo /dev/random jest interfejsem do generatora danych losowych a zapis do urządzenia /dev/full zawsze kończy się niepowodzeniem. (Jest ono, jak nawa wskazuje – zawsze pełne.)
Tak na marginesie, jak już omawiamy polecenie dd…
Warto zauważyć, że analogicznie, jeśli do katalogu /mnt/cdrom mamy przyłączony napęd CD z płytką, możemy napisać:

root@slax:/# dd if=/mnt/cdrom of=/pliki/plytka_cd.iso

i po chwilach paru (no, może parunastu) mamy gotowy obraz ISO naszej płyty.

A wracając do meritum, mamy pusty plik, więc teraz utwórzmy w nim system plików, czyli, inaczej mówiąc, sformatujmy go. Oczywiście jest to całkiem poprawne, nigdzie nie jest napisane, że formatować można wyłącznie „dyski”.

root@slax:/# mkfs.ext3 /pliki/plikopartycja.img

Program jednak chciałby się upewnić, że na pewno chcemy sformatować plik, więc otrzymujemy komunikat:

plikopartycja.img is not a block special device.
Proceed anyway? (y,n)

Zgadzamy się wpisując y i potwierdzając klawiszem enter. Po kilku chwilach nasza pliko-partycja jest gotowa.
Można ją teraz zamontować, co pokazano już powyżej. Przypomnijmy:

root@slax:/# mount /pliki/plikopartycja.img /mnt/test -o loop,rw

Dla pewności, czy wszystko działa, stwórzmy plik:

root@slax:/# echo ‘Bardzo tajne dane’ >> /mnt/test/jakies_tajne_dane.txt

i wypiszmy teraz jego zawartość:

root@slax:/# cat /mnt/test/jakies_tajne_dane.txt
Bardzo tajne dane

W ramach irytującego zachłystywania się wspaniałością Linuksa w opozycji do brzydkiego i ślamazarnego Windowsa, w Linuksie nie potrzeba programów typu DAEMON Tools, które przyłączają obrazy płyt CD jako tak zwane wirtualne CD-ROM-y – wystarczy wiedza i polecenie mount. (OK, OK – nie zawsze.)

Chwilowo posprzątajmy (odłączmy pliko-partycję):

root@slax:/# umount /mnt/test

Wyposażeni w tę wiedzę możemy wrócić do tematu i odpowiedzieć na pytanie: jak wygląda…

Uruchamianie modułowej dystrybucji LiveCD (wersja modelowa)

Jak przebiega start dystrybucji Live takiej jak SLAX?

Przede wszystkim, ładowany jest „system właściwy”, czyli kernel. Jak opisywałem już w innym artykule na tym wortalu, Linux (kernel) ma budowę monolityczną, co oznacza w tym przypadku tyle, że jest samodzielny. Po załadowaniu kernela mamy przygotowane kompleksowe środowisko do dalszych działań.

Drugim krokiem jest utworzenie ramdysku. Przypominam, że ów twór jest to po prostu wydzielony fragment pamięci operacyjnej, który „zachowuje się” tak, jakby był trwałym nośnikiem pamięci, takim jak dysk twardy, dyskietka, itp. W przypadku SLAX-a ma on rozmiar 4 MB.

Po trzecie na ów dysk rozpakowywany jest plik initrd.gz zawierający obraz dyskietki root. Po tej operacji, na ramdysku mamy także przygotowane drzewo katalogów.

Wreszcie jako krok czwarty, przyłączane są poszczególne katalogi, takie jak /var, /opt i tak dalej. Warto zauważyć, że posługujemy się tutaj pliko-partycjami (prawie) takimi, jak ta opisana powyżej. Co więcej z uwagi na to, iż znajdują się one na płycie, muszą być przyłączane w trybie tylko do odczytu.

Stop, stop. Tutaj pojawia się problem. Może nie napisałem tego wprost, ale pliko-partycja może być jedna, ale też – jak w przypadku SLAX-a – może być ich kilka. Każda z osobną grupą aplikacji. Co za tym idzie, każda z pliko-partycji winna zawierać co najmniej pliki programu, ewentualne biblioteki oraz ewentualną konfigurację. Mamy więc kilka systemów plików z których każdy zawiera kawałek katalogu /usr/bin, kawałek katalogu /etc i tak dalej. Problem? Rozwiązanie jest takie: Każdą z pliko-partycji przyłączamy do osobnego katalogu w katalogu /mnt. Mamy więc /mnt/modul1, /mnt/modul2 – tyle, ile poszczególnych modułów. Następnie, poszczególne pliki bądź katalogi „linkujemy” za pomocą mechanizmu dowiązań symbolicznych do odpowiednich katalogów, czy to /etc, czy /usr/bin. Nie ma co ukrywać, iż nie jest to zadanie trywialne, ale też nie niemożliwe. Przypominam, że dowiązanie symboliczne systemu UNIX nie jest to skrót znany z systemów Windows do wersji XP włącznie, ani też nie jest to aktywator, znany ze środowisk graficznych systemów uniksowych. Dowiązanie symboliczne jest własnością systemu plików. Za pomocą polecenia:

root@slax:/# ln -s /mnt/modul15/etc/apache2 /etc/apche2

Tworzymy dowiązanie symboliczne w katalogu /etc do katalogu /mnt/modul15/etc/apache2. Nie należy zapominać o opcji -s. W przeciwnym razie, mielibyśmy do czynienia z tak zwanym dowiązaniem twardym, którego użycie w tym przypadku byłoby – nawiasem mówiąc – nieprawidłowe.

Uff… Mamy działający system. Problem w tym, że nie jest to najlepsze rozwiązanie, ze względu na to, iż jest ono bardzo trudne w pielęgnacji. Poza tym, jest jeszcze pewien drobiazg. Chciało by się mieć OpenOffice.org, może LaTeX czy parę innych programów, a tu brak miejsca. 700 MB i koniec. (Dla płyt DVD rozumowanie jest analogiczne – 4 GB z hakiem i koniec…) Oczywiście potrzeba jest matką wynalazków. Z pomocą przyjdzie nam:

SquashFS

Co to jest SquashFS? Najkrócej rzecz ujmując – przepis na łatwe kompresowanie danych. Dokładniej, SquashFS jest systemem plików tylko do odczytu, który pozwala na łatwe, przezroczyste korzystanie ze skompresowanych danych, które zawiera. Aby stworzyć skompresowany plik danych należy skorzystać z polecenia mksquashfs:

root@slax:/# mksquashfs /root /pliki/root.sqfs

Katalog domowy administratora systemu zostanie skompresowany do pliku root.sqfs. Użyte rozszerzenie jest oczywiście dowolne. Ja zastosowałem sqfs, ale może go oczywiście w ogóle nie być.
Dobrze – mamy plik z danymi. Teraz przyłączmy go do systemu plików. W tym celu utwórzmy katalog… powiedzmy /unia i zamontujmy nasz plik:

root@slax:/# mkdir /unia
root@slax:/# mount -t squashfs -o loop,ro /pliki/root.sqfs /unia

Dla porządku:

-t squashfs – określenie typu systemu plików;
-o loop,ro – loop jest nieodzowne, ponieważ montujemy plik, a nie urządzenie, a ro, gdyż, jak wspomniałem wyżej, SquashFS jest systemem tylko do odczytu, więc tak dla zasady;

I… to w sumie cała „wielka” wiedza na temat SquashFS. Można by oczywiście napisać więcej, ale dla dalszych rozważań naprawdę tyle wystarczy. System ten stosowany jest szeroko. Poza omawianym SLAX-em używa go również KNOPPIX, a co za tym idzie DSL i wiele, wiele innych…
Co uzyskaliśmy? Większą ilość danych na tej samej płycie CD / DVD. Nie zmieniło to jednak faktu, że panowanie nad dowiązaniami symbolicznymi nadal jest kłopotliwe. Oczywiście i na to jest rada…

Union File System

Idea jest taka: Mamy kilka plików – modułów, będących jakby klockami puzzli, które chcemy połączyć w jeden „obrazek” – katalog główny. I chcielibyśmy, aby było to możliwie najprostsze. Nie chcemy żmudnego tworzenia dowiązań. Ma się rozumieć, działające rozwianie istnieje i jak to w uniwersum open source często bywa – nie jedyne. Omawiane wydanie dystrybucji SLAX jest o tyle szczególne, że o ile dotychczas autor, Tomas Mateicek, używał dość powszechnego UnionFS, to teraz bazuje na aufs. Cóż to takiego? Spójrzmy na obrazek:

O ile w katalogu /mnt dyski i płytę CD przyłączono – każdy do osobnego katalogu – o tyle katalog /unia zawiera „równocześnie” system plików partycji, dyskietki oraz płyty CD. A wszystko to dzięki aufs.
Podobnie jak unionFS, aufs jest modułem kernela, pozwalającym na zamontowanie kilku urządzeń w tym samym katalogu.

Przykład:

Nieco wcześniej stworzyliśmy sobie plik plikopartycja.img. To będzie jeden z naszych systemów plików. Partnerować mu będzie root.sqfs
Przyłączamy pierwszy system. Przede wszystkim musimy go zamontować gdzieś „na brudno”. Wydajemy więc polecenie:

root@slax:/# mkdir /mnt/pierwszy_system
root@slax:/# mount -o loop,rw /pliki/plikopartycja.img /mnt/pierwszy_system

Następnie w katalogu /unia przyłączamy go jako pierwszy składnik:

root@slax:/# mount -t aufs -o br:/mnt/pierwszy_system=rw aufs /unia

Dobrze, teraz przygotujmy system drugi:

root@slax:/# mkdir /mnt/drugi_system
root@slax:/# mount -t squashfs -o loop,ro /pliki/root.sqfs /mnt/drugi_system

A teraz najważniejsze, czyli przyłączenie drugiego składnika do unii:

root@slax:/# mount -o remount,add:1:/mnt/drugi_system=ro aufs /unia

wydajemy polecenie:

root@slax:/# ls /unia

i otrzymujemy:

Desktop/ lost+found/ jakies_tajne_dane.txt

W tak przygotowanym katalogu można zapisywać pliki – oczywiście znajdą się one na pliko-partycji. Proszę testować do woli. Przykładowo: przyłączenie trzeciego systemu plików…
Oczywiście „sklejanie” modułów nie jest jedynym zastosowaniem aufs. Wyobraźmy sobie jakikolwiek system obsługujący ten mechanizm (na przykład KNOPPIX). Chcemy sobie doinstalować program. Ponieważ KNOPPIX bazuje na Debianie, „normalnie” wystarczałoby skorzystać z polecenia dpkg lub apt-get, tylko, że płyta jest tylko do odczytu. Klaus Knopper jednak to przewidział i w dystrybucji KNOPPIX możliwe jest przyłączanie – na zasadzie analogicznej do opisanej – systemu plików umożliwiającego zapis (na przykład klucza USB) i „normalne” zainstalowanie programu. Ale to już inna historia…

Co do samego SLAX-a…

SLAX oferuje zestaw gotowych, wygodnych narzędzi do zarządzania modułami, tak, abyśmy na co dzień nie musieli zastanawiać się jak ich obsługa wygląda od kuchni. Przede wszystkim, po uruchomieniu systemu mamy do dyspozycji program Slax Module Manager. Cała obsługa sprowadza się do uruchomienia programu i wybraniu opcji dodania bądź usunięcia modułu. Aktualna lista dostępna jest w okienku aplikacji.

Inną ciekawą metodą dodawania potrzebnych nam programów jest skopiowanie całej zawartości płytki na dysk twardy – na przykład do katalogu /plytka, a następnie skopiowanie dodatkowych modułów do katalogu /plytka/slax/modules. Po tej czynności należy skorzystać z polecenia make_iso (make_iso.bat dla systemów z Redmond lub make_iso.sh dla Linuksa – oba na płytce), które utworzy nam nowy obraz iso płyty z systemem. Ponieważ autor SLAX-a dostarcza także zestaw narzędzi do modyfikowania zawartości modułów (katalog slax/tools na płycie), można do woli zmieniać ich zawartość.

Istnieje kilka dystrybucji zbudowanych na bazie SLAX-a. Są to między innymi: norweski Wolvix, argentyński DNALinux, amerykański LG3D LiveCD, czy polski TeaM-TL. Ostatnia jest podwójnie ciekawa. Nie dość, że zawiera kompletne środowisko systemu TeX, to jeszcze – ciekawostka – zajmuje blisko 2 GB. Jest to dziesięciokrotnie więcej niż bazowy SLAX.

I na koniec…

…chciałbym napisać, że niniejszy artykuł jest już wystarczająco długi. Jeżeli ktokolwiek wytrwał aż do tego miejsca, to znaczy, że było warto go było pisać. A może są jakieś pytania…?

Literatura:

• Strona SLAXa.
• (Stąd można SLAXa pobrać.)
• SLAX na http://distrowatch.com/
• Strona projektu squashfs.
• Strona projektu aufs.
• Strona projektu UnionFS.
• Jak to wygląda w Mac OS X.
• Strona dystrybucji TeaM-TL.

Korekta: Hubert Bielenia, t_ziel