--- title: Rozdział 3. Podstawy Uniksa part: Część I. Pierwsze kroki prev: books/handbook/install next: books/handbook/ports --- [[basics]] = Podstawy Uniksa :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :source-highlighter: rouge :experimental: :skip-front-matter: :toc-title: Spis treści :table-caption: Tabela :figure-caption: Rysunek :example-caption: Przykład :xrefstyle: basic :relfileprefix: ../ :outfilesuffix: :sectnumoffset: 3 ifeval::["{backend}" == "html5"] :imagesdir: ../../../../images/books/handbook/basics/ endif::[] ifeval::["{backend}" == "pdf"] :imagesdir: ../../../../static/images/books/handbook/basics/ endif::[] ifeval::["{backend}" == "epub3"] :imagesdir: ../../../../static/images/books/handbook/basics/ endif::[] include::shared/authors.adoc[] include::shared/releases.adoc[] include::shared/pl/mailing-lists.adoc[] include::shared/pl/urls.adoc[] include::shared/pl/teams.adoc[] toc::[] [[basics-synopsis]] == Streszczenie W niniejszym rozdziale omówione zostaną podstawowe polecenia i możliwości systemu operacyjnego FreeBSD. Wiele informacji dotyczyć będzie ogółem systemów typu UNIX(R). Czytelnikom zaznajomionym z tą tematyką w zupełności wystarczy pobieżne przejrzenie rozdziału. Natomiast ci, którzy dopiero rozpoczynają swoją przygodę z FreeBSD, powinni przeczytać go bardzo uważnie. Po przeczytaniu tego rozdziału będziemy wiedzieć: * Jak korzystać z "konsol wirtualnych" FreeBSD. * Jak działają prawa dostępu do plików i flagi plików we FreeBSD. * Jaki jest domyślny układ systemu plików FreeBSD. * Jaka jest organizacja dysku we FreeBSD. * Jak montować i odmontowywać systemy plików. * Czym są procesy, demony i sygnały. * Co to jest powłoka, oraz jak można zmienić własne środowisko pracy. * Jak posługiwać się prostymi edytorami tekstu. * Jaki jest związek pomiędzy urządzeniami i plikami węzłowymi urządzeń. * Jaki format binarny jest wykorzystywany we FreeBSD. * W jaki sposób korzystać z dokumentacji systemowej w poszukiwaniu dodatkowych informacji. [[consoles]] == Konsole wirtualne i terminale Z systemu FreeBSD korzystać można na różne sposoby; jednym z nich jest wpisywanie poleceń w terminalu tekstowym. Większość systemów operacyjnych typu UNIX(R) dostępna jest właśnie poprzez polecenia. W niniejszej części dowiemy się, czym są "terminale" i "konsole", oraz jak się nimi posługiwać we FreeBSD. [[consoles-intro]] === Konsola Jeśli konfigurując FreeBSD nie wybraliśmy, by przy uruchamianiu systemu było automatycznie ładowane środowisko graficzne, to po uruchomieniu i wykonaniu skryptów startowych system przywita nas komunikatem logowania się do systemu. Zobaczymy mniej więcej coś takiego: [source,shell] .... Additional ABI support:. Local package initialization:. Additional TCP options:. Fri Sep 20 13:01:06 EEST 2002 FreeBSD/i386 (pc3.example.org) (ttyv0) login: .... Na różnych komputerach komunikat ten może wyglądać nieco inaczej, jednak z pewnością będzie podobny. W tej chwili interesują nas jego dwa ostatnie wiersze. Wiersz drugi od końca ma postać: [.programlisting] .... FreeBSD/i386 (pc3.example.org) (ttyv0) .... Widać tu kilka informacji o systemie, który właśnie został uruchomiony. Mamy przed oczami konsolę "FreeBSD", działającą na komputerze z procesorem firmy Intel (lub kompatybilnym) z rodziny x86. Komputer ten został nazwany (każdy komputer uniksowy ma nazwę) `pc3.example.org` i w tej chwili widoczna jest jego konsola systemowa - terminal [.filename]#ttyv0#. Ostatni wiersz ma zawsze taką postać: [.programlisting] .... login: .... Tu wpisujemy "nazwę użytkownika", by zalogować się do systemu. Opis tej czynności przedstawiony jest w kolejnej części. [[consoles-login]] === Logowanie się do FreeBSD FreeBSD jest systemem wieloużytkownikowym i wielozadaniowym. Tak oficjalnie określa się system, z którego na jednym komputerze może korzystać wiele różnych osób, uruchamiając jednocześnie wiele programów. Każdy system wieloużytkownikowy musi mieć możliwość odróżnienia jednego "użytkownika" od pozostałych. FreeBSD (i wszystkie systemy uniksopodobne) wymaga, aby użytkownik "zalogował się" do systemu, zanim będzie mógł uruchamiać programy. Każdy użytkownik ma niepowtarzalną nazwę ("nazwę użytkownika") oraz sobie tylko znany klucz ("hasło"). FreeBSD wymaga wpisania jednego i drugiego, zanim zezwoli użytkownikowi na uruchamianie jakichkolwiek programów. Zaraz po załadowaniu systemu i zakończeniu uruchamiania skryptów startowych, FreeBSD wyświetli komunikat z prośbą o podanie nazwy użytkownika: [source,shell] .... login: .... Dla przykładu załóżmy, że nasz użytkownik nazywa się `janek`. Wpisujemy tutaj `janek` i naciskamy kbd:[Enter]. Powinniśmy zostać poproszeni o podanie "hasła": [source,shell] .... login: janek Password: .... Następnie wpisujemy hasło `janka`, i naciskamy kbd:[Enter]. Hasło _nie pojawia się!_ Na razie nie będziemy się tym zajmować. Wystarczy wiedzieć, że dzieje się tak ze względów bezpieczeństwa. Jeśli podaliśmy prawidłowe hasło, powinniśmy być już zalogowani do FreeBSD, i gotowi do eksperymentowania z dostępnymi poleceniami. Powinniśmy zobaczyć wiadomość dnia (ang. message of the day MOTD) oraz znak zachęty (`#`, `$` bądź `%`). Oznacza to, że udało nam się zalogować do FreeBSD. [[consoles-virtual]] === Konsole wirtualne Polecenia uniksowe można z powodzeniem wpisywać na jednej konsoli, jednak FreeBSD potrafi wykonywać wiele programów jednocześnie. Korzystanie z jednej konsoli do wydawania poleceń zakrawa na marnotrawstwo, ponieważ system zdolny jest obsłużyć w jednej chwili całe mnóstwo programów. W wykorzystaniu tej możliwości bardzo pomocne są "konsole wirtualne". Konfigurując FreeBSD możemy uaktywnić wiele konsol wirtualnych. Z dowolnej z nich możemy się przełączyć na inną naciskając odpowiednią kombinację klawiszy. Każda konsola ma własny kanał wyjściowy, FreeBSD zajmuje się odpowiednim przekazywaniem informacji wprowadzanych z klawiatury i wypisywanych na ekranie, gdy dochodzi do przełączenia konsoli na inną. Pewne kombinacje klawiszy używane są do przechodzenia między konsolami. Kombinacje kbd:[Alt+F1], kbd:[Alt+F2], aż do kbd:[Alt+F8] służą do przełączania na kolejną konsolę wirtualną. Przechodząc z jednej konsoli na inną, FreeBSD zajmuje się zachowaniem i odtworzeniem wyglądu ekranu. W efekcie otrzymujemy "złudzenie" posiadania wielu "wirtualnych" ekranów i klawiatur, które mogą służyć do wydawania poleceń systemowi FreeBSD. Programy uruchomione na jednej z konsol nie przerywają swej pracy, gdy ta konsola przestaje być widoczna - po przejściu na inną konsolę wirtualną programy kontynuują swoje działanie. [[consoles-ttys]] === Plik [.filename]#/etc/ttys# Zgodnie z domyślną konfiguracją FreeBSD uruchamia osiem konsol wirtualnych. Nie jest to jednak permanentne ustawienie, i może być w łatwy sposób zmienione, aby konsol wirtualnych było więcej lub mniej. Plik [.filename]#/etc/ttys# odpowiedzialny jest za liczbę konsol wirtualnych i ich konfigurację. Modyfikując plik [.filename]#/etc/ttys# możemy zmieniać konfigurację konsol wirtualnych FreeBSD. Każdy nie będący komentarzem wiersz tego pliku (czyli wiersz nie rozpoczynający się znakiem `#`) zawiera ustawienia jednego z terminali lub konsoli wirtualnej. W domyślnej wersji tego pliku występującej we FreeBSD skonfigurowanych jest 9 konsol wirtualnych, przy czym 8 z nich jest włączonych. Za ich konfigurację odpowiadają wiersze rozpoczynające się symbolem `ttyv`: [.programlisting] .... # name getty type status comments # ttyv0 "/usr/libexec/getty Pc" cons25 on secure # Virtual terminals ttyv1 "/usr/libexec/getty Pc" cons25 on secure ttyv2 "/usr/libexec/getty Pc" cons25 on secure ttyv3 "/usr/libexec/getty Pc" cons25 on secure ttyv4 "/usr/libexec/getty Pc" cons25 on secure ttyv5 "/usr/libexec/getty Pc" cons25 on secure ttyv6 "/usr/libexec/getty Pc" cons25 on secure ttyv7 "/usr/libexec/getty Pc" cons25 on secure ttyv8 "/usr/X11R6/bin/xdm -nodaemon" xterm off secure .... Dokładny opis poszczególnych kolumn tego pliku i opcji, za pomocą których konfiguruje się konsole wirtualne, znaleźć można w dokumentacji systemowej man:ttys[5]. [[consoles-singleuser]] === Konsola trybu jednego użytkownika "Tryb jednego użytkownika" szczegółowo opisuje crossref:boot[boot-singleuser,Single-User Mode]. Istotne jest, że w trybie jednego użytkownika dostępna jest tylko jedna konsola. Nie jest możliwe korzystanie z konsol wirtualnych. Konfiguracja konsoli trybu jednego użytkownika również znajduje się w pliku [.filename]#/etc/ttys#. Odpowiada jej wiersz rozpoczynający się słowem `console`: [.programlisting] .... # name getty type status comments # # If console is marked "insecure", then init will ask for the root password # when going to single-user mode. console none unknown off secure .... [NOTE] ==== Zgodnie z informacją zawartą w komentarzu nad wierszem `console`, wiersz ten można zmodyfikować, zmieniając parametr `secure` na `insecure`. Jeśli tak zrobimy, FreeBSD po uruchomieniu w trybie jednego użytkownika będzie pytać o hasło użytkownika `root`. Zachowajmy jednak ostrożność, jeśli wpisujemy tu `insecure`. Jeżeli zdarzy się nam zapomnieć hasła użytkownika `root`, może okazać się potrzebne uruchomienie trybu jednego użytkownika. Będzie to nadal możliwe, może jednak być nieco trudne dla osób nie orientujących się w procesie uruchamiania FreeBSD i uczestniczących w nim programach. ==== [[permissions]] == Prawa dostępu FreeBSD, będąc bezpośrednim potomkiem systemu UNIX(R) BSD, oparte jest na kilku kluczowych założeniach Uniksa. Najbardziej widocznym z nich jest fakt, że FreeBSD jest systemem wieloużytkownikowym - potrafi jednocześnie obsługiwać wielu użytkowników pracujących niezależnie od siebie. System jest odpowiedzialny za właściwe zarządzanie odwołaniami do sprzętu, pamięci i czasu procesora, po równo dla każdego z użytkowników. Ze względu na obsługę wielu użytkowników, zasoby, którymi zarządza system, mają przypisane prawa dostępu określające, kto może czytać, zapisywać i uruchamiać dany zasób. Prawa dostępu przechowywane są w postaci dwóch oktetów podzielonych na trzy części, z których pierwsza odnosi sie do właściciela pliku, druga do grupy posiadającej plik, a trzecia do innych użytkowników. W postaci numerycznej zapisuje się to następująco: [.informaltable] [cols="1,1,1", frame="none", options="header"] |=== | Wartość | Uprawnienia | Symbol |0 |Odczyt: nie, zapis: nie, wykonywanie: nie |`---` |1 |Odczyt: nie, zapis: nie, wykonywanie: tak |`--x` |2 |Odczyt: nie, zapis: tak, wykonywanie: nie |`-w-` |3 |Odczyt: nie, zapis: tak, wykonywanie: tak |`-wx` |4 |Odczyt: tak, zapis: nie, wykonywanie: nie |`r--` |5 |Odczyt: tak, zapis: nie, wykonywanie: tak |`r-x` |6 |Odczyt: tak, zapis: tak, wykonywanie: nie |`rw-` |7 |Odczyt: tak, zapis: tak, wykonywanie: tak |`rwx` |=== Korzystając z polecenia man:ls[1] możemy posłużyć się opcją `-l`, by zawartość katalogu została pokazana w formie szczegółowej, z uwzględnieniem kolumny zawierającej informację o prawach dostępu do pliku dla jego właściciela, grupy, oraz wszystkich innych. Przykładowy wynik polecenia `ls -l`: [source,shell] .... % ls -l total 530 -rw-r--r-- 1 root wheel 512 Sep 5 12:31 myfile -rw-r--r-- 1 root wheel 512 Sep 5 12:31 otherfile -rw-r--r-- 1 root wheel 7680 Sep 5 12:31 email.txt ... .... Pierwsza kolumna listy plików po wykonaniu polecenia `ls -l` ma następującą postać: [source,shell] .... -rw-r--r-- .... Pierwszy znak (od lewej) określa, czy plik jest zwyczajnym plikiem, katalogiem, urządzeniem znakowym, gniazdem, czy jakimkolwiek innym urządzeniem pseudo-plikowym. Widoczny w przykładzie znak `-` oznacza zwykły plik. Kolejne trzy znaki, w przykładzie są to `rw-`, reprezentują prawa dostępu, którymi dysponuje właściciel pliku. Następne trzy znaki `r--`, określają prawa dostępu grupy, do której należy plik. Ostatnia trójka `r--`, oznacza prawa dostępu dla innych. Minus oznacza brak jednego z praw dostępu. Plik przedstawiony w przykładzie może być więc odczytywany i zapisywany przez swojego właściciela, oraz jedynie odczytywany przez grupę i innych. Zgodnie z powyższą tabelą, prawa dostępu do tego pliku mają wartość `644`, przy czym każda cyfra reprezentuje trzy części uprawnień. W porządku, ale w jaki sposób system kontroluje dostęp do urządzeń? Zasadniczo większość urządzeń jest traktowana przez FreeBSD jak pliki, które mogą być otwierane, odczytywane i zapisywane podobnie jak wszystkie inne pliki. Specjalne pliki urządzeń przechowywane są w katalogu [.filename]#/dev#. Również katalogi traktowane są jak pliki - też są im przypisywane prawa odczytu, zapisu i wykonania. Bit wykonania katalogu ma nieco inne znaczenie niż w przypadku pliku. Posiadanie prawa wykonania katalogu oznacza, że można do niego wejść, czyli posłużyć się poleceniem "cd". Ponadto umożliwia to dostęp do zawartych w katalogu plików o znanych nazwach (oczywiście obowiązują także indywidualne prawa dostępu do każdego z plików). W szczególności, wyświetlenie listy plików katalogu wymaga posiadania prawa do jego odczytu, natomiast do usunięcia pliku o znanej nazwie potrzebne będą prawa do zapisu _i_ wykonania dla katalogu, w którym ów plik się znajduje. Jest jeszcze kilka innych bitów uprawnień, jednak są one stosowane w specjalnych przypadkach, np. do włączenia atrybutu SUID, lub "lepkiego" bitu dla katlogu. Więcej informacji o prawach dostępu i o ich przydzielaniu można znaleźć w dokumentacji systemowej polecenia man:chmod[1]. === Uprawnienia symboliczne Uprawnienia symboliczne, określane również jako wyrażenia symboliczne, przy określaniu praw dostępu do plików lub katalogów wykorzystują litery w miejsce wartości liczbowych. Wyrażenia symboliczne wykorzystują składnię: (kto) (akcja) (uprawnienia), przy czym dostępne są następujące wartości: [.informaltable] [cols="1,1,1", frame="none", options="header"] |=== | Opcja | Litera | Znaczenie |(kto) |u |Użytkownik (właściciel) |(kto) |g |Grupa |(kto) |o |Inni |(kto) |a |Wszyscy ("świat") |(akcja) |+ |Dodanie uprawnień |(akcja) |- |Usunięcie uprawnień |(akcja) |= |Ustawienie uprawnień |(uprawnienia) |r |Odczyt |(uprawnienia) |w |Zapis |(uprawnienia) |x |Wykonywanie |(uprawnienia) |t |Bit "lepki" |(uprawnienia) |s |Ustawienie UID lub GID |=== Do ustawienia tych wartości, podobnie jak w przypadku wartości liczbowych, wykorzystywane jest polecenie man:chmod[1]. Przykładowo, by zablokować dostęp innych użytkowników do _PLIKU_ należy wpisać: [source,shell] .... % chmod go= PLIK .... Gdy musimy wykonać więcej niż jedną zmianę uprawnień parametry należy oddzielić przecinkami. Na przykład, poniższe polecenie usunie prawa zapisu do _PLIKU_ grupie i innym. Następnie doda wszystkim prawo wykonywania: [source,shell] .... % chmod go-w,a+x PLIK .... === Flagi plików we FreeBSD Dodatkowo, oprócz opisanych wyżej praw dostępu, FreeBSD wykorzystuje również "flagi plików". Flagi te umożliwiają wprowadzenie dodatkowego poziomu ochrony i kontroli plików. Nie dotyczą natomiast katalogów. Dzięki zwiększonemu poziomowi kontroli plików system może zagwarantować, że w niektórych sytuacjach nawet użytkownik `root` nie będzie mógł usunąć bądź zmodyfikować plików. Zmiany flag plików dokonuje się poleceniem man:chflags[1]. Przykładowo, by plikowi [.filename]#plik1# nadać flagę nieusuwalności należy wydać poniższe polecenie: [source,shell] .... # chflags sunlink plik1 .... Natomiast, by usunąć flagę nieusuwalności wystarczy wprowadzić takie samo polecenie dodając "no" przed `sunlink`: [source,shell] .... # chflags nosunlink plik1 .... By wyświetlić flagi danego pliku wystarczy wpisać polecenie man:ls[1] z parametrem `-lo`: [source,shell] .... # ls -lo plik1 .... Wynik powinien być zbliżony do poniższego: [.programlisting] .... -rw-r--r-- 1 trhodes trhodes sunlnk 0 Mar 1 05:54 plik1 .... Niektóre z flag mogą być dodawane i usuwane jedynie przez użytkownika `root`, podczas gdy inne mogą być ustawiane również przez właściciela pliku. Zaleca się aby administratorzy przeczytali strony podręcznika systemowego man:chflags[1] oraz man:chflags[2]. [[dirstructure]] == Struktura katalogów Poznanie hierarchii katalogów FreeBSD jest podstawą ogólnego zrozumienia działania systemu. Najważniejszym zagadnieniem jest koncepcja katalogu głównego, "/". Jest on montowany jako pierwszy podczas uruchamiania systemu i zawiera podstawowe pliki niezbędne do przygotowania systemu do pracy w trybie wieloużytkownikowym. Ponadto w katalogu głównym znajdują się punkty montowania innych systemów plików, które możemy montować. Punktem montowania nazywany jest katalog, poprzez który inny system plików może być dołączony do głównego systemu plików. <> zawiera więcej informacji. Przykładem typowego punktu montowania może być [.filename]#/usr#, [.filename]#/var#, [.filename]#/tmp#, [.filename]#/mnt# oraz [.filename]#/cdrom#. Najczęściej każdemu z takich katalogów odpowiada wpis w pliku [.filename]#/etc/fstab#. Plik ten zawiera tabelę systemów plików i ich punktów montowania, z której korzysta system. Większość systemów plików wymienionych w [.filename]#/etc/fstab# jest montowana automatycznie przez skrypt man:rc[8] podczas uruchamiania systemu, wyjątkiem są te wpisy, które mają opcję `noauto`. <> zawiera więcej informacji. Pełny opis struktury systemu plików znajduje się w dokumentacji systemowej man:hier[7]. Tu ograniczymy się do pobieżnego zapoznania się z najważniejszymi katalogami. [.informaltable] [cols="1,1", frame="none", options="header"] |=== | Katalog | Opis |[.filename]#/# |Główny katalog systemu plików. |[.filename]#/bin/# |Programy użytkowe wykorzystywane zarówno w trybie jednego użytkownika, jak i w trybie wielu użytkowników. |[.filename]#/boot/# | Programy i pliki konfiguracyjne używane podczas uruchamiania systemu. |[.filename]#/boot/defaults/# |Pliki z domyślną konfiguracją uruchamiania systemu; patrz man:loader.conf[5]. |[.filename]#/dev/# |Pliki urządzeń; patrz man:intro[4]. |[.filename]#/etc/# |Pliki i skrypty konfiguracyjne. |[.filename]#/etc/defaults/# |Pliki z domyślną konfiguracją systemu; patrz man:rc[8]. |[.filename]#/etc/mail/# |Pliki konfiguracyjne dla serwerów poczty, na przykład man:sendmail[8]. |[.filename]#/etc/namedb/# |Pliki konfiguracyjne programu `named`; patrz man:named[8]. |[.filename]#/etc/periodic/# |Skrypty uruchamiane raz dziennie, raz na tydzień i raz na miesiąc za pośrednictwem man:cron[8]; patrz man:periodic[8]. |[.filename]#/etc/ppp/# |Pliki konfiguracyjne `ppp`; patrz man:ppp[8]. |[.filename]#/mnt/# |Pusty katalog, najczęściej wykorzystywany przez administratorów jako tymczasowy punkt montowania.. |[.filename]#/proc/# |System plików procesów, patrz man:procfs[5], man:mount_procfs[8]. |[.filename]#/rescue/# |Katalog zawierający programy przydatne w przypadku awarii; patrz man:rescue[8]. |[.filename]#/root/# |Katalog domowy użytkownika `root`. |[.filename]#/sbin/# |Programy i narzędzia administracyjne wykorzystywane zarówno w trybie jednego użytkownika, jak i w trybie wielu użytkowników. |[.filename]#/stand/# |Programy używane w samodzielnym środowisku. |[.filename]#/tmp/# |Pliki tymczasowe. Zawartość katalogu [.filename]#/tmp# NIE JEST zachowywana przy ponownym uruchamianiu systemu. Również pamięciowy system plików jest często montowany w katalogu [.filename]#/tmp#. Proces ten może zostać zautomatyzowany wykorzystując zmienne man:rc.conf[5] związane z tmpmfs (bądź za pomocą wpisu w [.filename]#/etc/fstab#; patrz man:mdmfs[8]). |[.filename]#/usr/# |Większość programów i aplikacji wykorzystywanych przez użytkowników. |[.filename]#/usr/bin/# |Najczęściej używane programy, narzędzia programistyczne, aplikacje. |[.filename]#/usr/include/# |Pliki nagłówkowe C. |[.filename]#/usr/lib/# |Biblioteki. |[.filename]#/usr/libdata/# |Pliki danych różnych programów użytkowych. |[.filename]#/usr/libexec/# |Demony i programy systemowe (uruchamiane przez inne programy). |[.filename]#/usr/local/# |Lokalne programy, biblioteki, itp. Ponadto jest to domyślny katalog dla instalowanych portów. Ogólna struktura katalogów wewnątrz [.filename]#/usr/local# powinna odpowiadać strukturze [.filename]#/usr# opisanej w dokumentacji man:hier[7]. Wyjątkiem jest katalog man, umieszczony bezpośrednio w [.filename]#/usr/local#, a nie w [.filename]#/usr/local/share#, oraz dokumentacja portów, znajdująca się w [.filename]#share/doc/port#. |[.filename]#/usr/obj/# |Pliki zależne od architektury komputera, tworzone w procesie budowania drzewa [.filename]#/usr/src#. |[.filename]#/usr/ports# |Kolekcja portów FreeBSD (opcjonalna). |[.filename]#/usr/sbin/# |Demony i programy systemowe (dostępne dla użytkowników). |[.filename]#/usr/shared/# |Pliki niezależne od architektury systemu. |[.filename]#/usr/src/# |Pliki źródłowe BSD, lokalne pliki źródłowe. |[.filename]#/usr/X11R6/# |Pliki wykonywalne, biblioteki, i inne pliki dystrybucji X11R6 (opcjonalnie). |[.filename]#/var/# |Rozmaite pliki dzienników systemowych, pliki tymczasowe, pliki kolejek. Również pamięciowy system plików jest często montowany w tym katalogu. Proces ten może zostać zautomatyzowany wykorzystując zmienne man:rc.conf[5] związane z varmfs (bądź za pomocą wpisu w [.filename]#/etc/fstab#; patrz man:mdmfs[8]). |[.filename]#/var/log/# |Pliki dzienników systemowych. |[.filename]#/var/mail/# |Skrzynki pocztowe użytkowników. |[.filename]#/var/spool/# |Katalogi kolejek systemu drukowania i poczty. |[.filename]#/var/tmp/# |Pliki tymczasowe nie usuwane przy ponownym uruchamianiu systemu. |[.filename]#/var/yp# |Mapy usługi NIS. |=== [[disk-organization]] == Organizacja dysku Najmniejszą jednostką organizacji dysku używaną przez FreeBSD do odnajdywania plików jest nazwa pliku. W nazwach plików rozróżniane są duże i małe litery, tak więc [.filename]#readme.txt# i [.filename]#README.TXT# to dwa różne pliki. FreeBSD nie wykorzystuje rozszerzeń nazw plików ([.filename]#.txt#) do określenia, czy plik jest programem, dokumentem, czy innym zbiorem danych. Pliki przechowywane są w katalogach. Katalog może być pusty, lub może zawierać setki plików. Może również zawierać inne katalogi, dzięki czemu mamy możliwość zbudowania hierarchicznej struktury katalogów. Pozwala to na łatwą organizację danych. Dostęp do plików i katalogów uzyskuje się podając nazwę pliku lub katalogu, poprzedzoną ukośnikiem `/` i innymi wymaganymi nazwami katalogów. Jeśli mamy katalog [.filename]#foo#, a w nim katalog [.filename]#bar#, w którym znajduje się plik [.filename]#readme.txt#, wówczas pełną nazwą, bądź ścieżką dostępu do pliku jest [.filename]#foo/bar/readme.txt#. Katalogi i pliki przechowywane są w systemie plików. Każdy system plików ma jeden katalog najwyższego poziomu, zwany _katalogiem głównym_ systemu plików. W katalogu głównym mogą być umieszczone następne katalogi. To, o czym mówimy, jest zapewne podobne do innych systemów operacyjnych, z którymi być może zetknęliśmy się wcześniej. Są jednak różnice; na przykład w systemie MS-DOS(R) nazwy plików i katalogów oddzielane są znakiem `\`, w Mac OS(R) natomiast znakiem `:`. We FreeBSD nie są używane litery dysków, lub inne nazwy dysków w ścieżce. Nie spotkamy się w FreeBSD z czymś takim jak [.filename]#c:/foo/bar/readme.txt#. Jest natomiast jeden system plików pełniący rolę _głównego systemu plików_. Zawiera on katalog główny dostępny jako `/`. Każdy inny system plików jest _montowany_ w głównym systemie plików. Niezależnie od tego, ile dysków mamy w komputerze, we FreeBSD każdy katalog wydaje się być częścią tego samego dysku. Załóżmy, że mamy trzy systemy plików, nazwane `A`, `B` i `C`. Każdy z nich ma katalog główny, zawierający dwa katalogi o nazwach `A1`, `A2` (oraz odpowiednio `B1`, `B2` i `C1`, `C2`). Niech `A` będzie głównym systemem plików. Gdybyśmy sprawdzili jego zawartość poleceniem `ls`, zobaczylibyśmy dwa podkatalogi `A1` i `A2`. Drzewo katalogów wygląda następująco: image::example-dir1.png[] System plików musi być montowany w katalogu innego systemu plików. Przyjmijmy teraz, że montujemy system plików `B` w katalogu `A1`. Główny katalog `B` zastąpi `A1`, a podkatalogi `B` pojawią się w odpowiednim miejscu: image::example-dir2.png[] Do plików znajdujących się w katalogach `B1` i `B2` można się dostać posługując się ścieżką [.filename]#/A1/B1# lub [.filename]#/A1/B2#. Pliki poprzednio obecne w katalogu [.filename]#/A1# są tymczasowo ukryte. Pojawią się ponownie po _odmontowaniu_[.filename]#B# z [.filename]#A#. Gdyby zamontować `B` w `A2`, drzewo katalogów wyglądałoby tak: image::example-dir3.png[] ścieżki natomiast miałyby postać [.filename]#/A2/B1# i [.filename]#/A2/B2#. Systemy plików mogą być montowane jeden na drugim. Rozwijając poprzedni przykład, możemy zamontować system plików `C` w katalogu `B1` systemu plików `B`, otrzymując następującą postać drzewa katalogów: image::example-dir4.png[] Można równie dobrze zamontować `C` bezpośrednio w systemie plików `A`, w katalogu `A1`: image::example-dir5.png[] Znającym system MS-DOS(R) może to przypominać polecenie `join`, choć nie jest to to samo. Zwykle nie trzeba zajmować się opisanymi powyżej rzeczami. Najczęściej tworzymy systemy plików podczas instalacji FreeBSD, wybieramy miejsce ich zamontowania i nie wprowadzamy później żadnych zmian, chyba, że zainstalujemy nowy dysk. Można utworzyć jeden obszerny główny system plików i nie tworzyć żadnych innych. Takie podejście ma kilka wad i jedną zaletę. .Korzyści z kilku systemów plików * Odrębne systemy plików mogą mieć różne _opcje montowania_ (mount options). Na przykład, przy odpowiednim przygotowaniu, główny system plików może być zamontowany tylko do odczytu, przez co niemożliwe będzie przypadkowe usunięcie lub zmiana ważnego pliku. Oddzielenie systemów plików dostępnych do zapisu dla użytkowników, jak np. [.filename]#/home#, od innych pozwala również na montowanie ich z opcją _nosuid_; co z kolei pozwala zwiększyć bezpieczeństwo systemu uniemożliwiając wykorzystanie bitów _suid_/_guid_. * FreeBSD automatycznie optymalizuje układ plików w systemie plików, w zależności od tego, jak ów system jest wykorzystywany. System plików zawierający wiele często zapisywanych małych plików będzie optymalizowany inaczej niż taki, w którym przechowywane jest mniej plików o dużych rozmiarach. W przypadku jednego dużego systemu plików taka optymalizacja nie zadziała. * Systemy plików FreeBSD są odporne na awarie zasilania. W niesprzyjających okolicznościach może się jednak zdarzyć, że przerwa w dostawie prądu w krytycznym momencie spowoduje uszkodzenie struktury systemu plików. Przechowywanie danych w kilku systemach plików zwiększa szansę, że system uruchomi się ponownie, dzięki czemu łatwiej będzie odzyskać dane z kopii zapasowej. .Korzyść z pojedynczego systemu plików * Systemy plików mają stały rozmiar. Podczas instalacji FreeBSD tworzymy system plików o zadanym rozmiarze; później może się okazać, że trzeba powiększyć partycję. Niełatwo jest to zrobić inaczej, niż przez przygotowanie zapasowej kopii danych, utworzenie na nowo systemu plików o większych rozmiarach, oraz skopiowanie danych z powrotem. + [IMPORTANT] ==== We FreeBSD dostępne jest polecenie man:growfs[8], które pozwala na zwiększenie rozmiaru systemu plików w locie, pomijając wspomniane ograniczenie. ==== Systemy plików przechowywane są na partycjach. Pojęcie partycji ma tu inne znaczenie niż popularnie stosowane (np. partycja systemu MS-DOS(R)), ze względu na uniksowy rodowód FreeBSD. Każda z partycji oznaczana jest literą, od `a` do `h`. Pojedyncza partycja może zawierać jeden system plików, dlatego też do systemów plików często odwołuje się albo poprzez miejsce ich zamontowania w głównym systemie plików, albo przez literowe oznaczenie partycji, na której dany system plików się znajduje. Przestrzeń dyskowa jest również używana we FreeBSD jako _przestrzeń wymiany_, pełniąc w ten sposób rolę _pamięci wirtualnej_. Komputer może dzięki temu dysponować większą ilością pamięci, niż ma w rzeczywistości. Kiedy pamięci zaczyna brakować, FreeBSD odsyła niektóre nieużywane dane do przestrzeni wymiany, a gdy znów okażą się potrzebne, przenosi je z powrotem (odsyłając jednocześnie inne dane). Z niektórymi partycjami związane są pewne konwencje dotyczące ich zastosowania. [.informaltable] [cols="1,1", frame="none", options="header"] |=== | Patrycja | Konwencja |`a` |Zwykle zawiera główny system plików |`b` |Zwykle zawiera przestrzeń wymiany |`c` |Zwykle jest tego samego rozmiaru, co obejmujący ją segment. Dzięki temu programy działające na całym segmencie (na przykład wykrywające uszkodzone obszary dysku) mogą działać na partycji `c`. Zwykle nie tworzy się na tej partycji systemu plików. |`d` |Swego czasu partycja `d` miała specjalne znaczenie, obecnie już go nie ma. Do dziś jednak niektóre programy mogą dziwnie się zachowywać, jeśli każe im się pracować na partycji `d`, dlatego też sysinstall zwykle w ogóle jej nie tworzy. |=== Każda partycja zawierająca system plików przechowywana jest na czymś, co we FreeBSD nosi nazwę _segmentu_. Jest to określenie tego, co wcześniej zwane było partycją, i ponownie jest to konsekwencją uniksowych korzeni FreeBSD. Segmenty są oznaczane liczbami od 1 do 4. Numery segmentów, wraz z przedrostkiem `s`, poprzedzone są nazwą urządzenia. Tak więc "da0_s1_" jest pierwszym segmentem na pierwszym dysku SCSI. Na dysku mogą być najwyżej cztery fizyczne segmenty, można jednak tworzyć segmenty logiczne wewnątrz segmentów fizycznych specjalnego typu. Powstałe w ten sposób segmenty rozszerzone mają numery od 5 wzwyż, zatem "ad0_s5_" odpowiada pierwszemu rozszerzonemu segmentowi na dysku IDE. Urządzenia te są wykorzystywane przez systemy plików, które zajmują cały segment. Segmenty, dyski "niebezpiecznie dedykowane" i inne dyski zawierają _partycje_, oznaczane literami od `a` do `h`. Litera dopisywana jest do nazwy urządzenia, więc "da0_a_" odpowiadać będzie partycji a na pierwszym dysku da, "niebezpiecznie dedykowanym". Z kolei "ad1s3_e_" oznacza piątą partycję w trzecim segmencie drugiego dysku IDE. Własne oznaczenie ma także każdy dysk. Nazwa dysku składa się z symbolu określającego typ dysku, oraz numeru, określającego który to dysk. Dyski, inaczej niż segmenty, numerowane są od zera. <> zawiera najczęściej spotykane zwykle oznaczenia. Gdy odwołujemy się do partycji, FreeBSD wymaga, byśmy podali również nazwę obejmującego ją segmentu i dysku. Z kolei gdy odwołujemy się do segmentu, podajemy również nazwę dysku. Kolejno podajemy więc nazwę dysku, `s`, numer segmentu, a na koniec literę partycji; patrz <>. <> pokazuje schematyczny model dysku, z pomocą którego łatwiej będzie zrozumieć pewne rzeczy. Gdy instalujemy FreeBSD, w pierwszej kolejności musimy przygotować segmenty na dysku, następnie w segmencie przeznaczonym dla FreeBSD utworzyć partycje, następnie wewnątrz partycji stworzyć system plików (lub przestrzeń wymiany) i określić miejsce jego montowania. [[basics-dev-codes]] .Oznaczenia dysków [cols="1,1", frame="none", options="header"] |=== | Oznaczenie | Znaczenie |[.filename]#ad# |Dysk ATAPI (IDE) |[.filename]#da# |Dysk SCSI o dostępie bezpośrednim |[.filename]#acd# |CDROM ATAPI (IDE) |[.filename]#cd# |CDROM SCSI |[.filename]#fd# |Stacja dyskietek |=== [[basics-disk-slice-part]] .Przykładowe nazwy dysków, segmentów i partycji [example] ==== [.informaltable] [cols="1,1", frame="none", options="header"] |=== | Nazwa | Znaczenie |`ad0s1a` |Pierwsza partycja (`a`) w pierwszym segmencie (`s1`) na pierwszym dysku IDE (`ad0`). |`da1s2e` |Piąta partycja `e` w drugim segmencie (`s2`) na drugim dysku SCSI (`da1`). |=== ==== [[basics-concept-disk-model]] .Schematyczny model dysku [example] ==== Rysunek przedstawia pierwszy dysk IDE z punktu widzenia FreeBSD. Zakładamy, że dysk ma rozmiar 4 GB i jest podzielony na dwa segmenty (partycje w MS-DOS(R)) o rozmiarze po 2 GB. Pierwszy segment zawiera DOS-owy dysk [.filename]#C:#, natomiast w drugim segmencie znajduje się przykładowa instalacja FreeBSD, z trzema partycjami oraz partycją wymiany. Każda z trzech partycji przechowuje system plików. Na partycji `a` umieszczony jest główny system plików, na `e` znajduje się katalog [.filename]#/var#, a na `f` katalog [.filename]#/usr#. image::disk-layout.png[] ==== [[mount-unmount]] == Montowanie i odmontowywanie systemów plików System plików można sobie wyobrazić jako drzewo, którego korzeniem jest [.filename]#/#. [.filename]#/dev#, [.filename]#/usr# i inne podkatalogi katalogu głównego są gałęziami, z których mogą wyrastać kolejne gałęzie, na przykład [.filename]#/usr/local#, itd. Jest kilka powodów, dla których warto jest trzymać niektóre katalogi w oddzielnych systemach plików. W katalogu [.filename]#/var# znajdują się podkatalogi [.filename]#log/# i [.filename]#spool/# oraz rozmaite pliki tymczasowe, z tego powodu może się on zapełnić. Zapełnienie głównego systemu plików jest raczej niepożądane, więc często zaleca się oddzielenie [.filename]#/var# od [.filename]#/#. Często niektóre katalogi umieszczane są na odrębnych systemach plików ze względu na to, że znajdują się na osobnych dyskach fizycznych lub dyskach wirtualnych, jak na przykład pliki udostępniane poprzez crossref:network-servers[network-nfs,Network File System] lub napędy CDROM. [[disks-fstab]] === Plik [.filename]#fstab# Systemy plików wymienione w pliku [.filename]#/etc/fstab# są automatycznie montowane podczas crossref:boot[boot,ładowania systemu] (prócz oznaczonych opcją `noauto`). Wpisy w pliku [.filename]#/etc/fstab# są następującej postaci: [.programlisting] .... urządzenie /punkt-montowania typ opcje archiwizacja nr-przebiegu .... `urządzenie`:: Nazwa pliku urządzenia (istniejącego), zgodnie z opisem w crossref:disks[disks-naming,Device Names]. `punkt-montowania`:: Katalog (istniejący), w którym system plików ma być zamontowany. `typ`:: Typ systemu plików przekazywany poleceniu man:mount[8]. We FreeBSD domyślnie jest to `ufs`. `opcje`:: Pierwszą opcją jest `rw`, jeśli w systemie plików ma być możliwy odczyt i zapis, albo `ro`, jeżeli dozwolony ma być tylko odczyt. W następnej kolejności podawane są inne opcje. Często stosowana jest opcja `noauto`, która zapobiega automatycznemu montowaniu systemu plików podczas uruchamiania systemu. Pozostałe opcje opisane są w dokumentacji systemowej man:mount[8]. `archiwizacja`:: Na podstawie tej informacji program man:dump[8] stwierdza, które systemy plików mają być archiwizowane. Jeśli pole to zostanie pominięte, domyślnie przyjmowana jest wartość zero. `nr-przebiegu`:: Na podstawie tego pola wyznaczana jest kolejność, w jakiej systemy plików poddawane są sprawdzaniu. Systemy plików, które nie mają być sprawdzane, powinny mieć `nr-przebiegu` ustawiony na zero. Główny system plików (powinien być sprawdzony jako pierwszy) powinien mieć `nr-przebiegu` o wartości jeden, a inne systemy plików powinny mieć wpisaną wartość większą od jednego. Jeśli dwa lub więcej systemów plików będzie miało taki sam `nr-przebiegu`, wówczas man:fsck[8], o ile będzie to możliwe, podejmie próbę równoległego sprawdzenia tych systemów plików. Więcej informacji o formacie pliku [.filename]#/etc/fstab# oraz definiowanych w nim opcji dostępnych w podręczniku systemowym man:fstab[5] [[disks-mount]] === Polecenie `mount` Polecenie man:mount[8] jest głównym poleceniem używanym do montowania systemów plików. W najprostszej postaci, używa się go następująco: [source,shell] .... # mount urządzenie punkt-montowania .... Polecenie to ma mnóstwo opcji wymienionych w dokumentacji systemowej man:mount[8]. Do najczęściej stosowanych należą: .Opcje montowania `-a`:: Montowanie wszystkich systemów plików wymienionych w [.filename]#/etc/fstab#. Nie są montowane systemy plików z opcją "noauto" oraz wykluczone przez opcję `-t`, jak również systemy plików już zamontowane. `-d`:: Wykonanie wszystkiego, oprócz faktycznego wywołania funkcji systemowej montowania. W połączeniu z opcją `-v` można w ten sposób sprawdzić, co tak naprawdę man:mount[8] stara się zrobić. `-f`:: Wymuszenie montowania nieuporządkowanego systemu plików (niebezpieczne), lub wymuszenie odebrania prawa do zapisu przy zmianie trybu montowania systemu plików z trybu "odczyt i zapis" na "tylko do odczytu". `-r`:: Montowanie systemu plików w trybie tylko do odczytu. Taki sam efekt ma zastosowanie opcji `-o` z argumentem `ro` (bądź `rdonly` w wersjach FreeBSD wcześniejszych niż 5.2). `-t` _typ_:: Montowanie systemu plików o określonym typie. Przy zastosowaniu opcji `-a` montowane są tylko systemy plików podanego typu. + Domyślnym typem systemu plików jest "ufs". `-u`:: Uaktualnienie opcji montowania systemu plików. `-v`:: Pokazywanie dodatkowych komunikatów. `-w`:: Montowanie w trybie odczytu i zapisu. Opcji `-o` towarzyszy lista oddzielonych przecinkami parametrów, oto niektóre z nich: nodev:: Ignorowanie obecnych w systemie plików urządzeń specjalnych. Przydatna opcja, jeśli chodzi o bezpieczeństwo. noexec:: Wyłączenie uruchamiania programów wykonywalnych na systemie plików. Również służy bezpieczeństwu. nosuid:: Ignorowanie bitów setuid i setgid w systemie plików. Kolejna opcja służąca bezpieczeństwu. [[disks-umount]] === Polecenie `umount` Command Poleceniu man:umount[8] należy podać jako parametr punkt montowania, nazwę urządzenia bądź opcję `-a` lub `-A`. Każdej z form wywołania polecenia można podać opcję `-f`, która nakazuje dokonać bezwarunkowego odmontowania, oraz opcję `-v`, powodującą wypisywanie dodatkowych komunikatów. Należy mieć na uwadze, że raczej nie zaleca się korzystania z `-f`. Bezwarunkowe odmontowywanie systemu plików może doprowadzić do awarii systemu lub uszkodzenia danych znajdujących się w danym systemie plików. Opcje `-a` oraz `-A` służą do odmontowania wszystkich zamontowanych systemów plików, lub systemów plików wybranych typów, określonych w opcji `-t`. Opcja `-A` nie dokonuje próby odmontowania głównego systemu plików. [[basics-processes]] == Procesy FreeBSD jest wielozadaniowym systemem operacyjnym. Oznacza to, że korzystając z systemu mamy wrażenie, że wiele programów działa jednocześnie. Działający w danej chwili program nazywany jest _procesem_. Po wydaniu dowolnego polecenia uruchamiany jest przynajmniej jeden proces. Są również procesy systemowe, które działają nieprzerwanie, zapewniając prawidłowe funkcjonowanie systemu. Każdemu procesowi przypisany jest jednoznaczny numer zwany _identyfikatorem procesu_, lub po prostu _PID_. Podobnie jak plik, również każdy proces ma swojego właściciela i grupę. Na podstawie informacji o właścicielu i grupie system operacyjny przydziela procesowi prawa do otwierania plików i urządzeń, przy zastosowaniu opisanych wcześniej praw dostępu. Większość procesów ma swój proces macierzysty; jest to proces, który uruchomił dany proces. Przykładowo, kiedy wydajemy polecenia w powłoce, to zarówno powłoka jest procesem, jak i każde z wykonanych poleceń. Procesem macierzystym każdego uruchomionego w ten sposób procesu będzie powłoka. Wyjątkiem jest specjalny proces zwany man:init[8]. `init` jest pierwszym procesem, więc jego PID jest zawsze równy 1. Proces `init` uruchamiany jest przez jądro systemu podczas ładowania FreeBSD. Są dwa bardzo przydatne polecenia, które pozwalają zobaczyć, jakie procesy są uruchomione: man:ps[1] i man:top[1]. Polecenie `ps` pokazuje statyczną listę działających w danej chwili procesów, uwzględniając informacje takie jak PID-y procesów, zużywaną pamięć, wydane do uruchomienia procesów polecenia, itd. Polecenie `top` wyświetla listę uruchomionych procesów, która jest co kilka sekund uaktualniana, dzięki czemu możemy na bieżąco śledzić, czym zajmuje się komputer. Domyślnie `ps` pokazuje tylko działające procesy należące do użytkownika wydającego polecenie. Na przykład: [source,shell] .... % ps PID TT STAT TIME COMMAND 298 p0 Ss 0:01.10 tcsh 7078 p0 S 2:40.88 xemacs mdoc.xsl (xemacs-21.1.14) 37393 p0 I 0:03.11 xemacs freebsd.dsl (xemacs-21.1.14) 48630 p0 S 2:50.89 /usr/local/lib/netscape-linux/navigator-linux-4.77.bi 48730 p0 IW 0:00.00 (dns helper) (navigator-linux-) 72210 p0 R+ 0:00.00 ps 390 p1 Is 0:01.14 tcsh 7059 p2 Is+ 1:36.18 /usr/local/bin/mutt -y 6688 p3 IWs 0:00.00 tcsh 10735 p4 IWs 0:00.00 tcsh 20256 p5 IWs 0:00.00 tcsh 262 v0 IWs 0:00.00 -tcsh (tcsh) 270 v0 IW+ 0:00.00 /bin/sh /usr/X11R6/bin/startx -- -bpp 16 280 v0 IW+ 0:00.00 xinit /home/nik/.xinitrc -- -bpp 16 284 v0 IW 0:00.00 /bin/sh /home/nik/.xinitrc 285 v0 S 0:38.45 /usr/X11R6/bin/sawfish .... Jak widzimy, man:ps[1] wyświetla informacje w kilku kolumnach. W kolumnie `PID` pokazywany jest omówiony wcześniej identyfikator procesu. PID-y są przydzielane po kolei od 1 do 99999 i znów od początku, gdy się skończą. Kolumna `TT` pokazuje terminal, na którym działa program - na razie nie będziemy się tym zajmować. W kolumnie `STAT` przedstawiony jest stan procesu, jego także na razie nie będziemy omawiać. `TIME` pokazuje czas wykorzystywania procesora przez dany proces, niekoniecznie odpowiada on czasowi, jaki upłynął od uruchomienia programu, ponieważ wiele programów przez długi czas oczekuje na jakieś zdarzenie, a dopiero potem wykorzystuje procesor. Ostatnia kolumna, `COMMAND`, pokazuje polecenie, którym uruchomiony został program. man:ps[1] ma wiele rozmaitych opcji, które mają wpływ na wyświetlane informacje. Jedną z najbardziej przydatnych kombinacji opcji jest `auxww`. Opcja a pokazuje informacje o wszystkich działających procesach, również nie należących do nas. `u` pokazuje nazwę użytkownika, do którego należy proces, jak również wykorzystanie pamięci. `x` pokazuje informacje o procesach - demonach. Opcja `ww` nakazuje, by polecenie man:ps[1] wyświetlało pełną linię polecenia, nie obcinając jej, by zmieściła się na ekranie. Informacje pokazywane przez man:top[1] wyglądają podobnie. Oto przykład: [source,shell] .... % top last pid: 72257; load averages: 0.13, 0.09, 0.03 up 0+13:38:33 22:39:10 47 processes: 1 running, 46 sleeping CPU states: 12.6% user, 0.0% nice, 7.8% system, 0.0% interrupt, 79.7% idle Mem: 36M Active, 5256K Inact, 13M Wired, 6312K Cache, 15M Buf, 408K Free Swap: 256M Total, 38M Used, 217M Free, 15% Inuse PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND 72257 nik 28 0 1960K 1044K RUN 0:00 14.86% 1.42% top 7078 nik 2 0 15280K 10960K select 2:54 0.88% 0.88% xemacs-21.1.14 281 nik 2 0 18636K 7112K select 5:36 0.73% 0.73% XF86_SVGA 296 nik 2 0 3240K 1644K select 0:12 0.05% 0.05% xterm 48630 nik 2 0 29816K 9148K select 3:18 0.00% 0.00% navigator-linu 175 root 2 0 924K 252K select 1:41 0.00% 0.00% syslogd 7059 nik 2 0 7260K 4644K poll 1:38 0.00% 0.00% mutt ... .... Informacje podzielone są na dwie części. Nagłówek (pierwsze pięć wierszy) zawiera PID ostatnio uruchomionego procesu, średnie obciążenie systemu (miara zapracowania systemu), czas działania systemu (od ostatniego uruchomienia) oraz aktualny czas. Inne liczby w nagłówku informują o liczbie działających procesów (w przykładzie 47), jak dużo pamięci i przestrzeni wymiany jest zajęte, oraz ile czasu system przebywa w różnych stanach procesora. Pod nagłówkiem w kilku kolumnach pokazane są informacje zbliżone do przedstawianych przez man:ps[1]. Podobnie można tu znaleźć PID procesu, nazwę użytkownika, czas zajmowania procesora, oraz polecenie, którym uruchomiono proces. man:top[1] pokazuje domyślnie także rozmiar pamięci zajmowanej przez proces. Ta ostatnia informacja podzielona jest na dwie kolumny; jedna odpowiada całkowitemu rozmiarowi, druga rozmiarowi rezydentnemu. Całkowity rozmiar oznacza, ile pamięci było potrzebne programowi, z kolei rozmiar rezydentny informuje, ile pamięci wykorzystuje program w danej chwili. W przykładzie widać, że man:getenv[3] potrzebował prawie 30 MB pamięci RAM, jednak obecnie wykorzystuje tylko 9 MB. man:top[1] automatycznie aktualizuje wyświetlane informacje co dwie sekundy; można to zmienić opcją `s`. [[basics-daemons]] == Demony, sygnały i unicestwianie procesów Kiedy korzystamy z edytora tekstu, możemy go w prosty sposób obsługiwać, wczytywać pliki, itp. Jest to możliwe dzięki cechom samego edytora oraz dzięki temu, że edytor jest podłączony do _terminala_. Jednakże, niektóre programy pracują bez ciągłej komunikacji z użytkownikiem, są więc odłączone od terminala. Przykładem takiego programu może być serwer WWW, nieustannie odpowiadający na żądania pochodzące z sieci, bez potrzeby komunikacji z użytkownikiem. Inny przykład to programy przesyłające emaile pomiędzy komputerami. Takie programy nazywane są _demonami_ (ang. daemons). Demony to postaci z mitologii greckiej - niewielkie usłużne istoty, ani dobre, ani złe, które w rozmaity sposób pomagały ludziom. Podobnie pomagają dzisiejsze serwery pocztowe i serwery WWW. Dlatego właśnie od długiego czasu maskotką BSD jest wesoły demon z widłami i w Przyjęto, iż programy uruchamiane jako demony mają nazwy zakończone literą "d". BIND (Berkeley Internet Name Daemon) jest serwerem nazw uruchamianym przez program `named`, serwer WWW Apache nosi nazwę `httpd`, demon kolejkowania drukarki (line printer spooling daemon) to `lpd`, itd. Nie jest to sztywna reguła, lecz przyjęta konwencja; na przykład główny demon pocztowy programu Sendmail nazywa się `sendmail`, a nie jak można by przypuszczać `maild`. Niekiedy istnieje potrzeba komunikacji z procesem - demonem. Odbywa się ona poprzez _sygnały_, to znaczy możemy porozumieć się z demonem (lub jakimkolwiek działającym procesem) wysyłając mu sygnał. Są różne rodzaje sygnałów, które możemy wysłać - niektóre z nich mają określone znaczenie, inne są odpowiednio interpretowane przez aplikację, co powinno być opisane w dokumentacji aplikacji. Sygnał możemy wysłać tylko do procesu, którego jesteśmy właścicielem. Wysłanie sygnału do procesu należącego do kogoś innego za pośrednictwem man:kill[1] lub man:kill[2] spowoduje odmowę dostępu. Wyjątkiem jest użytkownik `root`, który może wysyłać sygnały do dowolnego procesu, niezależnie od jego właściciela. Zdarza się, że samo FreeBSD również wysyła aplikacjom sygnały. Jeżeli niewłaściwie napisany program próbuje dostać się do niedostępnego dla niego obszaru pamięci, FreeBSD wysyła procesowi sygnał _Segmentation Violation_ (`SIGSEGV`). Aplikacja może skorzystać z funkcji systemowej man:alarm[3], wówczas po upłynięciu pewnego czasu zostanie do niej wysłany sygnał Alarm (`SIGALRM`). I tak dalej. Do zatrzymania procesu można wykorzystać dwa sygnały: `SIGTERM` i `SIGKILL`. Pierwszy z nich jest łagodnym sposobem unicestwienia procesu; proces może _przechwycić_ ten sygnał, następnie zakończyć swoją pracę, np. zamykając pliki, które otworzył. Czasami proces może zignorować sygnał `SIGTERM`, jeśli akurat zajmuje się czymś, co nie powinno być przerywane. Sygnał `SIGKILL` nie może zostać zignorowany. Działa według zasady "Nie obchodzi mnie, co robisz, w tej chwili przestań". Wysłanie procesowi sygnału `SIGKILL` powoduje, iż FreeBSD natychmiast go wstrzymuje. Inne użyteczne sygnały to `SIGHUP`, `SIGUSR1` i `SIGUSR2`. Są to sygnały ogólnego przeznaczenia, różne aplikacje reagują na nie w różny sposób. Powiedzmy, że dokonaliśmy zmiany w pliku konfiguracji serwera WWW, i chcemy nakazać serwerowi, aby konfiguracja została ponownie wczytana. Moglibyśmy zatrzymać i ponownie uruchomić `httpd`, ale ubocznym efektem takiego postępowania byłaby chwilowa przerwa w pracy serwera, co jest raczej niepożądane. Większość demonów działa w taki sposób, iż po otrzymaniu sygnału `SIGHUP` dokonują ponownego przeczytania swojego pliku konfiguracyjnego. Dzięki temu zamiast unicestwiania i ponownego uruchamiania `httpd` możemy wysłać mu sygnał `SIGHUP`. Nie jest jednoznacznie określone, jak procesy reagują na sygnał `SIGHUP`, dlatego różne demony mogą zachowywać się w różny sposób - w razie niepewności warto zapoznać się z dokumentacją konkretnego demona. Sygnały wysyłane są przy użyciu polecenia man:kill[1], jak w poniższym przykładzie. [.procedure] ==== *Procedure: Wysyłanie sygnału do procesu* W tym przykładzie zaprezentowano wysyłanie sygnału do man:inetd[8]. Plik konfiguracyjny dla `inetd` to [.filename]#/etc/inetd.conf#. Wysłanie sygnału `SIGHUP` spowoduje ponowne przeczytanie tego pliku. . Trzeba ustalić PID procesu, do którego wysyłać będziemy sygnał - do tego celu posłużą polecenia man:ps[1] i man:grep[1]. Polecenia man:grep[1] używamy do odnalezienia podanego ciągu znaków. Ponieważ polecenia wydajemy jako zwykły użytkownik, a man:inetd[8] działa jako `root`, polecenie man:ps[1] musimy wywołać z opcją `ax`. + [source,shell] .... % ps -ax | grep inetd 198 ?? IWs 0:00.00 inetd -wW .... + Jak widać, man:inetd[8] ma PID o wartości 198. Niekiedy w przedstawionym powyżej przykładzie może się także pojawić proces `grep inetd`, wynika to ze sposobu, w jaki man:ps[1] odnajduje działające procesy. . Sygnał wysyłamy przy pomocy polecenia man:kill[1]. Najpierw skorzystamy jednak z polecenia man:su[1] by stać się rootem, gdyż man:inetd[8] działa jako `root`. + [source,shell] .... % su # /bin/kill -s HUP 198 .... + Podobnie jak wiele poleceń w systemach UNIX(R), man:kill[1] nie wyświetla żadnego komunikatu w przypadku powodzenia. Jeżeli natomiast sygnał został wysłany do procesu, którego nie jest się właścicielem, pojawi się informacja: `kill: _PID_: Operation not permitted` (niedozwolona operacja). Błędne wpisanie PID-u spowoduje albo wysłanie sygnału do niewłaściwego procesu, co może skończyć się źle, albo też wysłanie sygnału do PID-u, który nie jest w danej chwili wykorzystywany - pojawi się wówczas komunikat `kill: _PID_: No such process` (nie ma takiego procesu). + [NOTE] .Dlaczego warto korzystać z `/bin/kill`? ====== W wielu powłokach polecenie `kill` jest wbudowane; oznacza to, że sama powłoka zajmuje się wysyłaniem sygnału, nie wywołując [.filename]#/bin/kill#. Może to być użyteczne, jednakże w różnych powłokach stosowana jest różna składnia do określenia nazwy sygnału, który ma być wysłany. Zamiast więc zapamiętywania wszystkich możliwych składni, łatwiej jest po prostu korzystać z polecenia `/bin/kill ...` ====== + Inne sygnały wysyła się tą samą metodą, wystarczy zastąpić `TERM` lub `KILL` w odpowiedni sposób. ==== [IMPORTANT] ==== Unicestwianie losowo wybranego procesu jest raczej złym pomysłem. Szczególne znaczenie ma man:init[8], proces o PID równym 1. Wydanie polecenia `/bin/kill -s KILL 1` jest szybką metodą wyłączenia systemu. Należy zawsze sprawdzać poprawność argumentów polecenia man:kill[1] przed naciśnięciem klawisza kbd:[Return]. ==== [[shells]] == Powłoki W codziennej pracy z FreeBSD bardzo często wykorzystywany jest interfejs linii poleceń, zwany powłoką (ang. shell). Podstawowym zadaniem powłoki jest przyjmowanie poleceń i wykonywanie ich. Wiele powłok wyposażonych jest także w dodatkowe funkcje ułatwiające pracę, np. usprawnienia zarządzania plikami, dopasowywanie nazw plików, ułatwienia korzystania z linii poleceń, makropolecenia i zmienne środowiskowe. We FreeBSD dostępnych jest kilka powłok, np. Bourne Shell `sh` i ulepszony C-shell `tcsh`. Wiele innych powłok, jak choćby `zsh` czy `bash`, można znaleźć w kolekcji portów FreeBSD. Której z powłok najlepiej jest używać? To właściwie kwestia gustu. Dla programistów C najwygodniejsze mogą być powłoki o składni wzorowanej na języku C, np. `tcsh`. Użytkownikom Linuksa i tym, dla których interfejs linii poleceń systemów 8unix; jest nowością, można polecić `bash`. Do wyboru jest wiele powłok, każda z nich ma pewne charakterystyczne tylko dla niej właściwości, które niekoniecznie będą działać w każdych warunkach. Często spotykanym udogodnieniem powłoki jest uzupełnianie nazw plików. Po wpisaniu kilku pierwszych liter polecenia lub nazwy pliku powłoka potrafi zwykle uzupełnić dalszy ciąg polecenia lub nazwy, dzieje się to po wciśnięciu klawisza kbd:[Tab]. Przyjmijmy przykładowo, że istnieją dwa pliki o nazwach [.filename]#foobar# i [.filename]#foo.bar#. Chcemy usunąć plik [.filename]#foo.bar#. Możemy więc wydać polecenie: `rm fo[Tab].[Tab]`. Powłoka wyświetli: `rm foo[BIIP].bar`. Napis [BIIP] oznacza sygnał dźwiękowy, będący informacją od powłoki, że uzupełnienie nazwy pliku nie było możliwe, ponieważ można dopasować więcej niż jedną nazwę. Zarówno [.filename]#foobar# jak i [.filename]#foo.bar# zaczynają się od `fo`. Powłoka mogła jednakże uzupełnić początek, czyli `foo`. Teraz można wpisać kropkę `.` i ponownie wcisnąć kbd:[Tab], tym razem powłoka uzupełni nazwę do końca. Inną cechą powłoki są zmienne środowiskowe. Przechowywane są one w przestrzeni środowiska powłoki w postaci par "nazwa = wartość". Przestrzeń środowiska jest widoczna dla każdego programu uruchamianego przez powłokę, dlatego też przechowuje się tam wiele parametrów konfiguracyjnych dla programów. Oto najczęściej spotykane zmienne środowiskowe wraz z krótkim opisem: [.informaltable] [cols="1,1", frame="none", options="header"] |=== | Zmienna | Opis |`USER` |Nazwa aktualnie zalogowanego użytkownika. |`PATH` |Lista katalogów zawierających pliki wykonywalne oddzielona przecinkami. |`DISPLAY` |Nazwa ekranu X11, jeśli takowy jest dostępny. |`SHELL` |Wykorzystywana powłoka. |`TERM` |Nazwa terminala użytkownika, wykorzystywana do określenia właściwości terminala. |`TERMCAP` |Zapis z bazy termcap zawierający sekwencje kodów odpowiadających różnym funkcjom terminala. |`OSTYPE` |Typ systemu operacyjnego, np. FreeBSD. |`MACHTYPE` |Architektura sprzętowa, na jakiej działa system. |`EDITOR` |Preferowany przez użytkownika edytor tekstu. |`PAGER` |Preferowany przez użytkownika program wyświetlający pliki tekstowe. |`MANPATH` |Lista katalogów zawierających dokumentację systemową oddzielona przecinkami. |=== Sposób odczytywania i ustawiania zmiennych środowiskowych zależy od rodzaju używanej powłoki. Na przykład w powłokach wzorowanych na C, jak `tcsh` i `csh`, do ustawiania i przeglądania zmiennych środowiskowych służy polecenie `setenv`, natomiast w powłokach Bourne'a, czyli `sh` i `bash`, do tych celów wykorzystywane jest polecenie `export`. Przykładowo, aby zmienić zmienną środowiskową `EDITOR` na [.filename]#/usr/local/bin/emacs# w powłoce `csh` lub `tcsh`, należy wydać polecenie: [source,shell] .... % setenv EDITOR /usr/local/bin/emacs .... A w powłokach Bourne'a: [source,shell] .... % export EDITOR="/usr/local/bin/emacs" .... W większości powłok można wyświetlić wartość zmiennej środowiskowej przez poprzedzenie jej nazwy znakiem `$`. Dla przykładu, polecenie `echo $TERM` pokaże wartość zmiennej `$TERM`, ponieważ powłoka zastępuje wyrażenie `$TERM` wartością zmiennej i przekazuje ją do `echo`. Wiele znaków, zwanych meta-znakami, traktowanych jest przez powłoki w specjalny sposób. Najczęściej wykorzystywanym jest `\*`, oznaczający dowolny ciąg znaków w nazwie pliku, umożliwiający wykonywanie operacji na wielu plikach. Przykładowo, wywołanie `echo *` jest prawie identyczne z wywołaniem `ls`, ponieważ powłoka przekazuje do `echo` nazwy wszystkich plików pasujących `*`. Jeśli potrzeba, by powłoka nie interpretowała znaku jako znak specjalny, należy go poprzedzić znakiem ukośnika (`\`). Wywołanie `echo $TERM` powoduje wypisanie ustawionego typu terminala, podczas gdy efektem polecenia `echo \$TERM` jest po prostu napis `$TERM`. [[changing-shells]] === Zmiana powłoki Najłatwiej jest zmienić powłokę przy użyciu polecenia `chsh`. Wywołanie tego polecenia uruchomi edytor wskazany przez zmienną `EDITOR`, lub edytor `vi`, jeśli nie jest ona zdefiniowana. Następnie należy zmienić nazwę powłoki w wierszu "Shell:". Można też skorzystać z `chsh` z opcją `-s`, która automatycznie zmieni powłokę, bez uruchamiania edytora. Poniżej przedstawiono wywołanie zmieniające powłokę na `bash`: [source,shell] .... % chsh -s /usr/local/bin/bash .... [NOTE] ==== Wybrana powłoka _musi_ być wymieniona w pliku [.filename]#/etc/shells#. Jeśli powłokę zainstalowano z crossref:ports[ports,kolekcji portów] powinna zostać dopisana automatycznie. Jeśli natomiast przeprowadzono ręczną instalację powłoki, trzeba to zrobić samemu. Dla przykładu, jeśli powłoka `bash` została zainstalowana i umieszczona w [.filename]#/usr/local/bin#, trzeba będzie wydać polecenie: [source,shell] .... # echo "/usr/local/bin/bash" >> /etc/shells .... Oraz uruchomić `chsh`. ==== [[editors]] == Edytory tekstu Konfiguracja FreeBSD polega głównie na edytowaniu plików tekstowych. Z tego właśnie powodu, dobrze byłoby zapoznać się z edytorami tekstu. FreeBSD posiada ich kilka, a kolejne można doinstalować z drzewa portów. Najłatwiejszym do nauki i w użyciu jest edytor ee, co jest skrótem od Easy Editor (ang. Łatwy Edytor). Aby uruchomić ee, należy użyć polecenia `ee plik`, gdzie _plik_ jest to, co chcemy edytować. Na przykład, aby wyedytować plik [.filename]#/etc/rc.conf#, napiszemy `ee /etc/rc.conf`. Gdy już jesteśmy w `ee`, możemy zauważyć, że wszystkie niezbędne komendy są wypisane u góry ekranu. Znak `^` oznacza wciśnięty klawisz kbd:[Ctrl]. Innymi słowy `^e` oznacza, że należy trzymać kbd:[Ctrl] i wcisnąć klawisz kbd:[e]. Aby wyjść z ee, wciśnij kbd:[Esc], następnie wybierz leave editor (opuść edytor). Edytor zapyta, czy zachować zmiany, jeśli plik został zmodyfikowany. FreeBSD w swoich zasobach ma także potężny edytor tekstu, jakim jest vi. W kolekcji portów dostępny jest także Emacs, czy vim (package:editors/emacs[] i package:editors/vim[]). Edytory te oferują dużo większą funkcjonalność, ale oczekują w zamian większego obeznania użytkownika z zasadami ich działania, ponadto ich obsługa jest trudniejsza do nauki. Jednakże, jeśli planujesz edytować wiele tekstu, nauka Emacs lub vim zwróci się w długim okresie w postaci zaoszczędzonego czasu. [[basics-devices]] == Urządzenia i pliki urządzeń Mianem urządzeń określa się komponenty komputera, takie jak dysk, drukarka, karta graficzna czy klawiatura. Podczas ładowania systemu FreeBSD większość wyświetlanych komunikatów dotyczy wykrywanych urządzeń. Komunikaty startowe dostępne są do późniejszego przeglądania w pliku [.filename]#/var/run/dmesg.boot#. Przykładowo, [.filename]#acd0# odpowiada pierwszemu napędowi CDROM IDE, natomiast [.filename]#kbd0# oznacza klawiaturę. Dostęp do większości urządzeń w systemie operacyjnym UNIX(R) odbywa się poprzez specjalne pliki, zwane plikami urządzeń, znajdujące się w katalogu [.filename]#/dev#. === Tworzenie plików urządzeń Kiedy wyposażamy komputer w nowe urządzenie, lub kompilujemy jądro z obsługą dodatkowych urządzeń, konieczne może okazać się utworzenie nowych plików urządzeń. ==== `DEVFS` (DEVice File System) System plików urządzeń, zwany `DEVFS`, udostępnia przestrzeń nazw urządzeń jądra jako część przestrzeni nazw głównego systemu plików. `DEVFS` zajmuje się obsługą systemu plików urządzeń, dzięki czemu nie trzeba samodzielnie tworzyć bądź modyfikować plików urządzeń. Więcej informacji znaleźć można w dokumentacji systemowej man:devfs[5]. [[binary-formats]] == Formaty binarne By zrozumieć czemu FreeBSD używa formatu man:elf[5], musimy wpierw poznać trzy obecnie "dominujace" formaty plików wykonywalnych w systemach UNIX(R): * man:a.out[5] + Najstarszy i najbardziej "klasyczny" format w Uniksie. Wykorzystuje krótki nagłówek z magicznym numerem na samym początku, często wykorzystywanym do określenia rodzaju pliku (szczegółowy opis dostępny jest w man:a.out[5]). Na plik składają się trzy segmenty: .text, .data i .bss oraz tablice symboli i ciągów tekstowych. * COFF + Format obiektowy pochodzący z SVR3. W tym formacie sekcja tablic w wchodzi już w skład nagłówka, tak więc możliwe jest zawarcie w pliku więcej sekcji niż tylko .text, .data i .bss. * man:elf[5] + Następca COFF zawierający wiele dodatkowych sekcji o 32- bądź nawet 64-bitowych wartościach. Jednym, acz wielkim minusem jest fakt, iż przy projektowaniu formatu ELF również założono, że na każdą architekturę sprzętową będzie istniał tylko jeden interfejs ABI. Okazało się natomiast, iż takie założenie jest błędne nawet w świecie komercyjnych SYSV (z którego pochodzą przynajmniej trzy ABI: SVR4, Solaris i SCO). + Sposobem na rozwiązanie tego problemu we FreeBSD są narzędzia do _metkowania_ plików wykonywalnych ELF informacjami, z którymi ABI jest on zgodny. Więcej informacji dostępnych jest w podręczniku systemowym man:brandelf[1]. System FreeBSD pochodzi z "klasycznego" obozu. Wykorzystywał on zatem format man:a.out[5] - technologię wypróbowaną w wielu pokoleniach systemów BSD i z powodzeniem stosowaną aż do gałęzi 3.X. Mimo, że skompilowanie i uruchomienie w sposób natywny plików binarnych ELF (a także jądra) było możliwe we FreeBSD już od pewnego czasu, Projekt oficjalnie opierał się przed migracją do formatu ELF jako podstawowego. Dlaczego? Otóż, gdy obóz linuksowy wykonał ten bolesny krok ku ELF nie udało się tak łatwo uciec od formatu [.filename]#a.out#. Wynikało to przede wszystkim z faktu, iż niezbyt elastyczny plan migracji bazował na mechanizmie współdzielonych bibliotek, których modyfikacja nastręczała wielu trudności zarówno producentom sprzętu jak i projektantom. Dopiero od momentu gdy narzędzia dostępne dla ELF zaoferowały sposób rozwiązania problemu ze współdzielonymi bibliotekami, zaczęły być postrzegane ogólnie jako "droga do przodu", a tym samym koszty migracji mogły zostać uznane za niezbędne do poniesienia. Mechanizm współdzielonych bibliotek FreeBSD w dużej mierze przypomina mechanizm z SunOS(TM) Sun'a i jako taki jest bardzo łatwy w użyciu. Skąd więc tyle różnych formatów? W zamierzchłych czasach do dyspozycji był prosty sprzęt komputerowy. Ów prosty sprzęt obsługiwał mały, prosty system. Stąd też format [.filename]#a.out# był całkowicie odpowiednim do prezentacji plików binarnych w tym prostym systemie (PDP-11). Gdy UNIX(R) został przeniesiony z tego prostego systemu na platformy typu Motorola 68k czy VAXen, zachowany został format [.filename]#a.out#, zdecydowanie wystarcząjacy dla wczesnych wersji Uniksa. Pewien czas później, jakiś bystry inżynier sprzętowy stwierdził że gdyby potrafił zmusić oprogramowanie do robienia kilku obskurnych sztuczek, wówczas mógłby pozbyć się kilku bramek z układu scalonego i zmusić CPU do szybszej pracy. Pomimo, że format [.filename]#a.out# potrafił współpracować z tym nowym rodzajem sprzętu (zwanego wówczas RISC) to mimo wszystko nie był najlepszym do tego formatem. Dlatego też rozpoczęto prace nad innymi formatami binarnymi, które miały osiągnąć lepsze wyniki niż ograniczony, prosty [.filename]#a.out# mógł zaoferować. Stworzone zostały COFF, ECOFF oraz kilka mniej znanych formatów, nim powstał ELF. Kolejnym problemem okazał się wzrost rozmiarów programów przy względnie małej pojemności dysków oraz pamięci fizycznych, a także zwiększeniu stopnia skomplikowania pamięci wirtualnej VM. Tak też narodziła się koncepcja współdzielonych bibliotek. Mimo, że ów postęp osiągnięty był przy pomocy formatu [.filename]#a.out# zakres jego przydatności był stale rozciągany, wraz z każdą nową funkcją. Pojawiła się konieczność dynamicznego wczytywanie pewnych rzeczy już w trakcie uruchamiania programu czy zapisywania części programu zaraz po wykonaniu kodu init w pamięci lub przestrzeni wymiany. Również języki programowania stawały się coraz bardziej wyrafinowane. Wiele poprawek wprowadzonych do formatu [.filename]#a.out# umożliwiały realizację kolejnych funkcji, przy czym z reguły działały one tylko przez pewien czas. Niestety, format a.out stał się z czasem niezdolny do rozwiązywania wszystkich problemów bez wciąż rozrastającego się narzutu w kodzie i poziomu skomplikowania. Mimo, że ELF potrafił rozwiązać wiele z ówczesnych problemów, zmiana formatu binarnego, który generalnie działał, wciąż była wielką uciążliwością. Dlatego też ELF musiał poczekać aż bardziej bolesnym okazało się pozostanie przy [.filename]#a.out# niż przejście do ELF. Wraz z upływem czasu, narzędzia kompilacyjne, z których FreeBSD wywodzi własne narzędzia (przede wszystkim assembler i loader), wyewoluowały w dwa równoległe projekty. Odmiana FreeBSD dała współdzielone biblioteki oraz poprawki kilku błędów. Ludzie z GNU, którzy oryginalnie napisali te programy, przepisali je na nowo i dodali proste kompilatory wskrośne, pozwalające na pracę w różnych formatach. Nowy pakiet narzędzi GNU (binutils) wspiera kompilowanie wskrośne, format ELF, współdzielone biblioteki, rozszerzenia C++, itp. Dodatkowo, wielu producentów sprzętu przygotowuje binaria ELF. Jest to zatem dobra rzecz dla FreeBSD, że je obsługuje. Format ELF oferuje większą rozszerzalność niz [.filename]#a.out#. Narzędzia ELF są lepiej przygotowywane i oferują kompilację wskrośną, co jest istotne dla wielu programistów. Co prawda ELF może być trochę wolniejszy niż [.filename]#a.out#, jednakże próba pomiaru może być trudna. Istnieje również wiele innych szczegółów różnych dla obydwu formatów, m.in. sposób mapowania stron, obsługi kodu init itp. Co prawda, żadne z nich nie jest istotne, jednakże różnice istnieją. Z czasem, wsparcie dla [.filename]#a.out# zostanie wstrzymane z jadra [.filename]#GENERIC# i ostatecznie usunięte z jądra gdy tylko zniknie potrzeba obsługi programów [.filename]#a.out#. [[basics-more-information]] == Więcej informacji [[basics-man]] === Dokumentacja systemowa Najdokładniejszą dokumentacją we FreeBSD jest dokumentacja systemowa. Dla prawie każdego dostępnego w systemie programu przygotowana jest krótka instrukcja obsługi, omawiająca podstawy jego działania i rozmaite opcje. Dokumentację możemy przeglądać przy pomocy polecenia `man`. Korzystanie z tego polecenia jest bardzo proste: [source,shell] .... % man polecenie .... `polecenie` jest nazwą polecenia, o którym chcemy uzyskać informacje. Na przykład, aby dowiedzieć się czegoś na temat polecenia `ls` wpisujemy: [source,shell] .... % man ls .... Dokumentacja systemowa podzielona jest na ponumerowane części: . Polecenia dostępne dla użytkowników. . Funkcje systemowe i kody błędów. . Funkcje z bibliotek języka C. . Sterowniki urządzeń. . Formaty plików. . Gry i inne rozrywki. . Różne informacje. . Polecenia służące do zarządzania systemem. . Informacje dla programistów jądra. Niekiedy takie samo zagadnienie może pojawić się w kilku częściach dokumentacji. Na przykład istnieje polecenie `chmod`, oraz funkcja systemowa `chmod()`. W taki wypadku możemy wybrać interesującą nas część dokumentacji, podając jej numer jako parametr polecenia `man`: [source,shell] .... % man 1 chmod .... W efekcie pokazana zostanie dokumentacja polecenia `chmod`. Zgodnie z przyjętą konwencją, numer odpowiedniej części dokumentacji podawany jest w nawiasach, tak więc man:chmod[1] odpowiada poleceniu `chmod`, natomiast man:chmod[2] odpowiada funkcji systemowej. W opisany powyżej sposób możemy dowiedzieć się, jak korzystać z danego polecenia, jeśli znamy jego nazwę. Co zrobić, jeśli nie możemy sobie przypomnieć nazwy polecenia? Otóż, `man` potrafi również wyszukiwać wybranych słów kluczowych w opisach poleceń, służy do tego opcja `-k`: [source,shell] .... % man -k mail .... Wpisanie takiego polecenia spowoduje wyświetlenie listy poleceń, których opisy zawierają słowo kluczowe "mail". Takie działanie jest równoważne skorzystaniu z polecenia `apropos`. Jeśli więc, przeglądając zawartość katalogu [.filename]#/usr/bin#, zastanawiamy się, do czego właściwie służą znajdujące się tam polecenia, możemy wpisać: [source,shell] .... % cd /usr/bin % man -f * .... lub [source,shell] .... % cd /usr/bin % whatis * .... W obu przypadkach efekt będzie taki sam. [[basics-info]] === Pliki GNU Info Do FreeBSD dołączonych jest wiele programów i narzędzi stworzonych przez Free Software Foundation (FSF). Prócz dokumentacji systemowej, do tych programów dołączone są bardziej rozbudowane dokumenty hipertekstowe, zwane plikami `info`. Można je przeglądać poleceniem `info`, lub trybem info emacsa, o ile emacs został zainstalowany. By skorzystać z polecenia man:info[1], wpisujemy: [source,shell] .... % info .... Krótkie wprowadzenie pojawia się po wpisaniu `h`. Spis poleceń jest dostępny po wpisaniu `?`.