SSH, scp, sftp :: Generowanie kluczy SSH :: Montowanie SFTP jako systemu plików :: Tunelowanie SSH :: Restricted SFTP/SSH :: Podstawy "życia" w Debianie :: Instalacja oprogramowania :: Struktura katalogów i pliki konfiguracyjne :: GRUB :: Start systemu - initrd, init i pliki startowe :: Moduły - ładowanie, konfiguracja, ... :: udev :: Tablica partycji GPT :: RAID i LVM - bezpieczniejsze, większe i bardziej elastyczne partycje dyskowe :: Konfiguracja sieci bezprzewodowej :: Tworzenie mirroru zainstalowanego systemu :: Uwagi o hasłach :: Wycinki z Debian Reference :: Podstawy Unix'a: :: Warto wiedzieć: :: Dla admina: :: Unixowate systemy operacyjne :: *BSD :: (Open)Solaris :: inne ... :: Linki

Systemy POSIXowe

SSH, scp, sftp

Składnia poleceń SSH:
ssh użytkownik@serwer (następnie akceptujemy klucz kodowania (przy pierwszym połączeniu) i podajemy hasło) lub ssh serwer (następnie podajemy nazwę użytkownika, akceptujemy klucz kodowania (przy pierwszym połączeniu) i podajemy hasło)
scp ścieżka-źródła ścieżka-celu lub scp -r ścieżka-źródła ścieżka-celu (pozwala na rekurencyjne kopiowanie katalogów), gdzie ścieżka oznacza ścieżkę lokalną lub użytkownik@serwer: ścieżka-na-serwerze (następnie również akceptujemy klucz kodowania (przy pierwszym połączeniu) i podajemy hasło)
sftp

Przy pomocy ssh (bez scp) tez da się przesyłać pliki (w przypadku dużej ilości plików jest to metoda wydajniejsza, którą możemy także łatwo wzbogacić o kompresję):

W przypadku gdy chcemy bezpośrednio poprzez ssh wywołać jakąś komendę interaktywną po zdalnej stronie (bez odpalania shell'a przydatna może być opcja -t wymuszająca utworzenie wirtualnego terminala - dzięki niej zadziała poprawnie ssh 'sudo bash' itp komendy.

W ~/.ssh/config możemy definiować skrócone nazwy dla hostów wraz z określeniem opcji używanych przy logowaniu (np. port, użytkownik). Ponadto nazwy hostów podane w tym pliku będą rozwijane w ramach pakietu "bash_completion" poprzez tab. Dodanie do tego pliku HashKnownHosts no powoduje że nazwy hostów w ~/.ssh/known_hosts będą zapisywane w sposób jawny i również będą autouzupełniane przez "bash_completion".

W przypadku systemów Windows konieczna jest instalacja programów "Putty" (do połączeń SSH, tekstowe programy scp, sftp dostarczane z Putty noszą nazwy pscp i psftp) i/lub WinSCP (graficzny interfejs do SCP) i/lub "ssh secure shell client" (terminal SSH i graficzny interfejs do SFTP).

Generowanie kluczy SSH

SSH umożliwia także opcję nawiązywania połączeń bez potrzeby podawania hasła - wykorzystuje się do tego klucze asymetryczne. Aby je wygenerować korzystamy z komendy ssh-keygen -t rsa (możemy także wybrać inny typ klucza - dsa), jeżeli zależy nam na uniknięciu podawania hasła generujemy klucze niezabezpieczone hasłem (bezpieczniej jest używać kluczy z hasłem i ssh-agent aby podawać je tylko raz ...). Wygenerowane klucze znajdą się w ~/.ssh/id_rsa - prywatny, ~/.ssh/id_rsa.pub - publiczny. Klucz publiczny należy przekopiować na komputer z którym chcemy się łączyć (np[. przy pomocy scp) i dopisać do ~/.ssh/authorized_keys - cat id_rsa.pub >> ~/.ssh/authorized_keys.

Możliwa jest także konwersja pomiędzy formatem kluczy openssh a ssh2: ssh-keygen -e -f id_dsa.pub > id_dsa_ssh2.pub i w drugą stronę: ssh-keygen -i -f id_dsa_ssh2.pub > id_dsa.pub

Montowanie SFTP jako systemu plików

Możliwe jest montowanie zdalnych zasobów SFTP jako lokalnego systemu plików. Wymaga to zainstalowania pakietu z sshfs oraz załadowania modułu fuse (mechanizm fs opartego na fuse zastąpił opisywany tu niegdyś shfs stanowiący moduł jądra). Montowanie wykonujemy przy pomocy polecenia sshfs -o workaround=rename serwer:katalog punkt_montowania (dość istotna jest opcja "workaround=rename" umożliwiająca przenoszenie plików na takim systemie). Oczywiście użytkownik wykonujący to polecenie musi mieć prawa do /dev/fuse (należeć do grupy fuse). Warto na koniec też zwrócić uwagę iż możliwe jest korzystanie z standardowych kluczy generowanych przez ssh-keygen (i umieszczanych w $HOME/.ssh/ jako: authorized_keys , id_rsa , id_rsa.pub).

W przypadku KDE możliwe jest też korzystanie z zasobów SFTP bez ich montowania - wystarczy w Konqueror'ze wpisać sftp://uzytkownik@nazwa.serwera .

Tunelowanie SSH

Możliwości SSH nie kończą się na udostępnieniu zdalnego shella i możliwości bezpiecznego przesyłu plików, umożliwia on także zdalny dostęp do programów działających w trybie graficznym. Wymaga to jednak włączenia opcji przekazywania protokołu X'ów (w przypadku ssh z linii poleceń opcja -X) oraz działającego na maszynie z której się łączymy serwera X'ów (na maszynie docelowej takiego serwera może nie być w ogóle - musza być tylko stosowne biblioteki oraz program który chcemy odpalić). Po uzyskaniu połączenia shellowego z włączoną opcją przekazywania X'ów programy graficzne odpala się tak jak każdy inny program.

SSH umożliwia także tworzenie tuneli przekierowujących połączenia TCP na zadany port komputera z którego wykonujemy połączenie ssh do określonego adresu IP (wraz z portem) dostępnego z maszyny (serwera ssh) do której się łączymy (może być to np. prywatny adres IP dostępny tylko wewnątrz LANu): ssh -L lokalny_port:mapowany_adres_ip:mapowany_port uzytkownik@serwer_ssh. Możliwe jest też tunelowanie w drugą stronę (ssh -R mapowany_port_serwera:adres_ip:port uzytkownik@serwer_ssh) co umożliwia utworzenie (na serwerze ssh) portu nasłuchujacego który umożliwi połączenie do komputera (z którego zestawiony został tunel) do którego może nie być bezpośredniego dostępu (np. za firewallem); należy tutaj zaznaczyć iż domyślnie nasłuchiwanie na zadanym porcie odbywa się tylko lokalnie aby to zmienić należy przed tym portem określić adres nasłuchiwania (lub * dla wszystkich), aby było to skuteczne musi być włączona w konfiguracji serwera opcja "GatewayPorts". Umożliwia to także proste tworzenie swego rodzaju sieci VPN o bardzo dobrym zabezpieczeniu.

Inną intersującą opcją jest wykozystanie ssh w roli proxy którego jeden koniec mamy lokalnie, a drugi gdzieś daleko. Funkconalność taką zapewnia opcja -D w ssh i wykorzystanie lokalnego końca tunelu jako proxy typu SOCKS. Kolejną z ciekawych opcji jest -w pozwalająca na tworzenie urządzeń tunelowych, które mogą posłużyć do realizacji prawdziwego VPN.

Restricted SFTP/SSH

Niekiedy zachodzi potrzeba nałożenia pewnych ograniczeń na to co mogą robić użytkownicy którym dajemy dostęp poprzez ssh i pochodne.

Jednym z takich ograniczeń może być dostęp tylko przez klucze do jakiejś wskazanej komendy - wymaga to utworzenia użytkownika baz hasła (w /etc/shadow dajemy coś co na pewno nie jest hashem hasła) oraz utworzeniu wpisu w ~/.ssh/authorized_keys postaci: command="svnserve -t",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty ssh-rsa __KLUCZ__ITD (podana w przykładzie svnserve -t pozwala na dostęp do svn poprzez ssh - svn ls svn+ssh://serwer/repo/path).

Innym ograniczeniem jest dostęp tylko do SFTP bez możliwości zalogowania się do shella, uzyskać to można poprzez wpis w /etc/passwd postaci: sftponly:x:UID:GID:SFTP uploader:HOME/PATH:/usr/lib/openssh/sftp-server. Jeżeli chemy udostępnic także inne protokoły kopiowania plików - takie jak np. rsync możemy skorzystać także z rssh.

Aby użytkownik nie tylko nie miał dostępu do shella ale także nie mógł wyjść poza swój katalog trzeba zastosować chroot, współczesne wersje OpenSSH bardzo ułatwiają budowę takiego środowiska należy w konfiguracji SSH umieścić następujące wpisy (polecam zwrócić uwagę na informacje w komentarzach):

Subsystem sftp internal-sftp
# zamiast Subsystem sftp /usr/lib/openssh/sftp-server
Match User ftplim1
	ForceCommand internal-sftp
	# należy też ustawić "Subsystem sftp" na internal-sftp
	X11Forwarding no
	AllowTcpForwarding no
	ChrootDirectory /var/chroot-sftp/%u
	# %u podmieniane jest na nazwę użytkownika, dzięki czemu można zamiast Match User użyć Match Group
	# w passwd $HOME musi wskazywać na coś nadrzędnego $SHELL może być /dev/null
	# jeżeli nie chcemy robić go global-writable to wewnątrz niego powinien być katalog który należy do ftplim1

Wpisanie session optional pam_lastlog.so w /etc/pam.d/sshd spowoduje logowaniw wszystkich połączeń ssh (np. połączeń sftp) w pliku wtmp (podobnie można uczynić z /etc/pam.d/su). Natomiast jeżeli występuje problem z starszymi klientami ssh (nieprzyjmowanie poprawnego hasła) to warto w konfiguracji tego serwera ustawić opcję "PasswordAuthentication yes".

Podstawy "życia" w Debianie

Debian jest to wolny system operacyjny, zawierający bardzo dużo oprogramowania, od innych dystrybucji odróżnia go położenie bardzo dużego nacisku na kwestie wolności poszczególnych składników oraz posiadanie wersji opartych na różnych jądrach (Linux, Hurd, BSD). W standardowej dystrybucji znajdziemy większość opisywanych wyżej programów. Należy jednak zwrócić uwagę iż w pojedynczej paczce .deb może być kilka programów (np. procmail zawiera formail; w takich wypadkach przydatna jest wyszukiwarka wewnątrz pakietowa - http://packages.debian.org/, gdyż komendy włączające program są na ogół zgodne z jego nazwą ...), jak również jeden pakiet może być podzielony na bardzo wiele paczek .deb na ogół (ale nie zawsze) powiązanych zależnościami (np. KDE). Jednak niektórych wymienionych wyżej programów (cinelerra) nie ma (jeszcze ...) w oficjalnej dystrybucji, stosownych paczek warto dodać do /etc/apt/sources.list. Warto także zwrócić uwagę na snapshot.debian.net przechowujący starsze wersje pakietów (może być bardzo przydatny gdy używając Sid'a dorobimy się zabugowanej wersji kluczowego dla nas pakietu).

Instalacja oprogramowania

Polecam zakończenie działania programu dokonującego podstawowej konfiguracji systemu (automatycznie uruchamianego przy pierwszym starcie po ewentualnym wybraniu dodatkowych źródeł apta - w przypadku dobrego łącza do Internetu warto wybrać źródła HTTP lub FTP). System ten posiada na tyle wygodny system zarządzania pakietami (chyba najlepszy z jakim się spotkałem), że późniejsze dodanie potrzebnego oprogramowania nie będzie problemem. Poniżej omówię kilka poleceń i programów związanych z zarządzaniem pakietami w Debianie.

aptitude - najbardziej wysokopoziomowy i "user-friendly" (z standardowych) program do zarządzania pakietami, mogący pracującować w tzw. "trybie pełnoekranowym". Do najważniejszych jego poleceń zaliczyć należy {podane w postaci: "znak wywołujący akcje w trybie pełnoekranowym" - "opis" ("komenda trybu linii poleceń")}:
+ - instaluje wybrany pakiet (install)
- - odinstalowywuje wybrany pakiet (remove)
_ - wykasowywuje (w raz z plikami konfiguracyjnymi) wybrany pakiet (purge)
L - reinstaluje wybrany pakiet
R - rekonfiguruje wybrany pakiet {odpowiada wywołaniu: dpkg-reconfigure nazwa_pakietu}
= - wstrzymuje aktualizację wybranego pakietu (hold)
I - instaluje "pojedyńczo" (bez spełniania zależności) wybrany pakiet
M - dodaje znacznik automatycznej instalacji (markauto)
m - usuwa znacznik automatycznej instalacji (unmarkauto)
/ - wyszukiwanie pakietu (standardowo według nazwy, aby szukać w opisie ~d szukany_tekst, aby znaleźć niedokasowane ~c lub nieoficjalne !~Odebian, aby szukać tylko w zainstalowanych ~i)
\ - wyszukiwanie wstecz
n - następny wyszukany pakiet
N - poprzedni wyszukany pakiet
l - filtr pakietów (np. ?any-version(~i !~Astable !~Atesting) zawęzi listę wyświetlanych pakietów tylko do tych których zainstalowana wersja jest różna od wersji z stable i testing)
d - wyświetla zależności danego pakietu
r - wyświetla zależności od pakietu
i - wyświetla informacje o pakiecie
g - wykonuje zaplanowane akcje
q - wychodzi z aktualnego okna bądź z programu
? - pomoc
jednym z mniej znanych, a bardzo przydatnych wywołań jest aptitude -F '%c%a%M %p %V' search '~Rdepends:nazwa_pakietu' wypisujące pakietów wymaganych itp dla danego
więcej: menu Pomoc w programie i man 8 aptitude

Warto także zwrócić uwage na plik konfiguracyjny aptitude (i apt'a) - /etc/apt/apt.conf (lub jego odpowiedniki w katalogu domowym) - umożliwia on m.in. wyłączenie instalowania pakietów polecanych:

# nie trzyma polecanych i sugerowanych jak zalezności
APT::AutoRemove::RecommendsImportant "false";
APT::AutoRemove::SuggestsImportant "false";

# nie instaluje automatycznie olecanych i sugerowanych
APT::Install-Recommends "false";
APT::Install-Suggests "false";

# wyłączenie wyszukiwania przyrostowego w aptitude
aptitude::UI::Incremental-Search "false";

# wyłączenie pobierania aktualizacji listy pakietów jako pdiff
# (polecam jeżeli stosunkowo rzadko aktualizujemy listy pakietów np. na testingu)
Acquire::PDiffs "false";

apt-get - program do pobierania i instalowania pakietów ...

apt-file - program umożliwiający wyszukiwanie pakietu zawierającego plik o podanej nazwie lub ścieżce (w odróżnieniu od dpkg -S nie ogranicza się tylko do zainstalowanych pakietów) - apt-file update - aktualizacja informacji o pakietach, apt-file search test - wyszukanie pakietów zawierających plik test

apt-build - program ułatwiający kompilowanie Debiana ze źródeł, celem optymalizacji

dpkg - potężne niskopoziomowe narządzie do zarządzania pakietami. Do najważniejszych opcji zaliczyć należy:
-i nazwa_pakietu [...] - instaluje pakiet(y)
-l wzorzec_nazwy_pakietu [...] - wypisuje informacje o stanie pakietów (w szczególności czy jest zainstalowany)
-L nazwa_pakietu [...] - lista plików zawartych w pakietach
-S sciezka_do_pliku - lista pakietów zawierających plik
--get-selections - lista zainstalowanych pakietów wraz z statusem - aktualnie zainstalowany (install) lub usunięty (deinstall)
warto zwrócić uwagę na możliwość zapisania listy zainstalowanych pakietów do pliku - dpkg --get-selections > pakiety.txt oraz zaznaczenia do instalacji pakietów zapisanych w tak wygenerowanej liście - dpkg --set-selections < pakiety.txt

więcej - tradycyjnie: man 8 dpkg, dpkg --help | less

Zachęcam do zapoznania się także z pozostałymi programami z rodziny apt-* (niektóre z nich to osobne paczki, wymagające doinstalowania) - umożliwiają one m.in. budowę systemu Debian ze źródeł (jak Gentoo ...) oraz programem aptsh (shell do zarządzania pakietami, podobnie jak jest w PLD).

Niekiedy przydatna może być sztuczka z fałszywym zainstalowaniem paczki. Operacja taka sprowadza się do:

Struktura katalogów i pliki konfiguracyjne

Na wstępie warto napisać jeszcze parę słów o strukturze katalogowej w Debianie (a poniekąd też i innych "Unixach") oraz kilka ogólnych uwag o plikach konfiguracyjnych i ich edycji. Katalog główny (korzeń, root) oznaczany jest przez / w nim znajdują się m.in. podkatalogi: /bin (pliki wykonywalne podstawowych programów), /sbin (pliki wykonywalne podstawowych programów administracyjnych), /lib (podstawowe biblioteki), /etc (pliki konfiguracyjne), /var (dane trwałe stacji - np. kolejka wydruków czy też pocztowa, logi systemowe - podkatalog /var/log), /tmp (pliki tymczasowe, usuwane przy starcie), /usr/bin (pliki wykonywalne pozostałych programów), /usr/sbin (pliki wykonywalne pozostałych programów administracyjnych), /usr/lib (pozostałe biblioteki), /usr/include (pliki nagłówkowe C/C++), /usr/share (pliki dodatkowe - danych ... zainstalowanych programów), /usr/src (źródła), /usr/local (podobnie jak /usr ale wykorzystywane głównie dla programów dokompilowywanych). Zobacz w sieci: Filesystem Hierarchy Standard.

Warto tutaj także wspomnieć iż właśnie w (pozornie może niezbyt interesującym) katalogu /var przechowywana jest konfiguracja dotycząca zainstalowanych paczek *.deb. Warto od czasu do czasu zadbać o jej zarchiwizowanie np. przy pomocy tar -czf /etc/pakiety-stan.tgz /var/lib/dpkg/status /var/lib/dpkg/statoverride /var/lib/dpkg/diversions /var/lib/dpkg/alternatives /var/lib/dpkg/info /var/lib/apt/extended_states /var/lib/aptitude/pkgstates.

Jak już wspomniałem pliki konfiguracyjne systemu znajdują się w katalogu /etc i jego podkatalogach (pliki konfiguracyjne użytkowników to ukryte (zaczynające się od kropki) pliki i katalogi w jego katalogu domowym). Zasadniczo każda aplikacja ma własny format plików konfiguracyjnych, dlatego też trudno podać jakieś ogólne informacje o nich i ich edycji ... informacji tych należy szukać w dokumentacji danego programu, także stronach mauala opisujących dane pliki (rozdział 5), bardzo przydatne gdy chcemy cos zrobić, a za bardzo nie wiemy jak jest Google ... . Można jednak powiedzieć że generalnie są to pliki tekstowe, niekiedy z podziałem na sekcje, najczęściej oparte o zasadzie że w kolejnych liniach są podawane ciągi: klucz wartosc, komentarzami na ogół są całe linie zaczynające się od #.

GRUB

Po zakończeniu procesu inicjalizacji sprzętu i testów rozruchowych BIOS ładuje do pamięci kod znajdujący się w pierwszym sektorze dysku twardego (sektorze rozruchowym rozpoczynającym się od adresu zerowego) i uruchamia go (przekazuje do niego kontrolę). W przypadku sektorów rozruchowych typu MBR (i kompatybilnych z nim), kod ten może liczyć maksymalnie 446 bajtów (gdyż na kolejnych pozycjach znajduje się tablica partycji) i jego zadaniem jest załadowanie i uruchomienie pozostałej częsci programu rozruchowego (np. może użyć programu w partycji oznaczonej jako bootowalna).

GRUB jest jednym z najpopularniejszych w środowisku linuxowym boot menagerów / boot loaderów. Jego wykonywalna przy starcie komputera wersja składa się z 3 części:

Może on być zainstalowany zarówno w MBR, jak i w bootowalnej partycji. W tym pierwszym przypadku w MBR wgrywany jest stage1, natomiast stage1.5 w zależności od używanego typu tablicy partycji znajduje się albo tuż za MBR - w przerwie pomiędzy MBR a pierwszą partycją (dla partycji MBR/msdos), albo w dedykowanej partycji BIOS boot partition (w przypadku GPT).

W przypadku komputerów opartych na UEFI firmware odpowiedzialny jest za zinterpretowanie tablicy partycji (GPT) i załadowanie progragramu rozruchowego z pliku znajdującego się na specjalnej partycji EFI (EFI System partition) z systemem plików FAT32. GRUB może pełnic funkcję tak uruchamianego boot loadera (w tym przypadku całość potrzebnego kodu stage1 i stage1.5 znajduje się w pliku na tej partycji).

Zadaniem GRUBa jest umożliwenie wyboru, załadowanie i uruchomienie jądra systemu operacyjnego z zadanymi opcjami. Jego działanie kończy się w momencie gdy jądro przejmuje sterowanie. Zobacz także w Sieci: GRUBkopia lokalna, MBRkopia lokalna, GPTkopia lokalna, UEFIkopia lokalna.

Konfiguracja

Współcześnie konfiguracja GRUB'a jest generowana automatycznie w oparciu o /etc/grub.d/ i /etc/default/grub przez grub-mkconfig w oparciu o wykrywanie typów dysków na których jest zainstalowany system (raid, lvm, typ systemu plików, ...) oraz unikalne identyfikatory dysków, partycji, itd. Mimo to warto znać przynajmniej podstawy działania grub'a, jego komend, aby być wstanie coś zrobić gdy zamiast menu startowego ujrzymy tylko konsolę awaryjną. Poniżej zamieszczam przykładowy plik konfiguracyjny /boot/grub/grub.cfg z komentarzami opisującymi zanczenie różnych poleceń i opcji.

# oficjalna dokumentacja: http://www.gnu.org/software/grub/manual/grub.html

# korzystanie z konsoli na porcie szeregowym
#serial --speed=115200 --unit=1 --word=8 --parity=no --stop=1
#terminal_input serial console
#terminal_output serial console
# za to na którym RS jest grub odpowiada --unit w serial
#
# korespondujące opcje uruchamiania dla Linuxa:
#   module    /boot/vmlinuz [...] console=tty0 console=ttyS1,115200n8
# korespondujące opcje uruchamiania dla XENa:
#   multiboot /boot/xen.gz  [...] com2=115200,8n1 vga=mode-0x0319 console=com2,vga
#   module    /boot/vmlinuz [...] console=tty0 console=hvc0
#
# w opcjach kernela szczególną rolę odgrywa ostatni podany terminal (ostatnia opcja console)
# jest on związany z /dev/console i na nim pokazywany jest init, ponadto należy uruchamiać getty
# na odpowiednim urządzeniu poprzez wpis w inittab np.:
#   T0:23:respawn:/sbin/getty -L /dev/ttyS1 115200 vt100
# lub (dla wariantu XENowego, UWAGA: w przykładzie tylko runlevel 4 i 5):
#   T1:45:respawn:/sbin/getty 38400 hvc0

# timeout w sekundach dla domyślnej pozycji menu
set timeout=60
set default="0"

# ładowanie modułów - typ tablicy partycji
insmod part_gpt
#insmod part_msdos

# ładowanie modułów - RAID
insmod mdraid1x # mdraid metadata 1.x
#insmod mdraid09 # mdraid metadata 0.9
#insmod raid5rec # faulty RAID4/5
#insmod raid6rec # faulty RAID6

# ładowanie modułów - LVM
insmod lvm

# ładowanie modułów - File System
insmod xfs

# ustawienie root'a
set root='lvm0-root'

menuentry 'Debian GNU/Linux' {
	# obraz jądra Linuxa z przekazywanymi do systemu opcjami 
	linux   /boot/vmlinuz-3.12-trunk-amd64 root=/dev/mapper/lvm0-root ro rootdelay=3 quiet
	# obraz initrd
	initrd  /boot/initrd.img-3.12-trunk-amd64
}

menuentry "SBM Boot Manager" {
	linux16  /boot/extra/memdisk floppy
	# memdisk z pakietu syslinux-common (/usr/lib/syslinux/memdisk)
	initrd16 /boot/extra/sbootmgr.dsk
	# SBM Boot Manager (http://btmgr.sourceforge.net/about.html)
	# z http://ftp.lanet.lv/ftp/mirror/Slackware/isolinux/sbootmgr/
}

Start systemu - initrd, init i pliki startowe

Start systemu rozpoczyna się od załadowania do pamięci obrazu jądra wraz z parametrami oraz (opcjonalnie) initrd i przekazania kontroli do jądra przez program rozruchowy (np. GRUB, LILO). W przypadku korzystania z initrd obraz ten przekształcany jest na RAM-dysk w trybie zapisu-odczytu i montowany jako rootfs z którego uruchamiany jest /sbin/init. Po zakończeniu jego działania (lub od razu gdy nie używamy initrd) uruchamiany jest program wskazany w opcji init= jądra (domyślnie typowo /sbin/init) z rootfs wskazanego w opcji root= jądra.

Zawartość obrazu rozruchowego można podejrzeć poprzez jego rozpakowanie komendą: mkdir -p /tmp/initrd && cd /tmp/initrd && gzip -dc < /initrd.img | cpio -i (jednak ponowne spakowanie go nie przynosi pożądanych rezultatów, ponadto współczesnych obrazów nie da się już montować przez mount -o loop). Celem dostosowywania initrd do własnych potrzeb polecam przyjrzenie się strukturze katalogów /usr/share/initramfs-tools/ i /etc/initramfs-tools/. W szczególności wart przeanalizowania jest skrypt /usr/share/initramfs-tools/init, który jest uruchamiany zaraz po odpaleniu obrazu startowego (jest kopiowany przy tworzeniu initrd.img na /init). Po wykonaniu stosownych zmian w tych plikach obraz można zbudować poprzez wywołanie mkinitramfs lub wygodniejszego update-initramfs -u.

Część z opcji przekazywanych jako parametry jądra jest obsługiwana przez initrd - wybrane z tych opcji:

Więcej opcji linii poleceń jądra znaleźć można w man bootparam oraz man init. Zaznaczyć tu należy iż zgodnie z man bootparam parametry postaci nazwa=wartosc nie rozpoznane jako parametry jądra są przekazywane jako zmienne środowiskowe, obecnie trafiają one w tej postaci do skryptów wywoływanych przez init (jednak zdarzało się że gdzieś ginęły). Natomiast same procesy związane z logowaniem użytkownika nie przekazują tych zmiennych do środowiska obecnego po zalogowaniu, zatem aby z nich skorzystać konieczne jest przetwarzanie /proc/cmdline (ze względów na nie pewność co do ustawienia środowiska przez init warto tak postępować także w skryptach init). Można to realizować w następujący sposób ZMIENNA=`awk 'BEGIN {RS="[ \n]"; FS="=";} $1=="ZMIENNA" {print $2}' /proc/cmdline` lub:

for tmp in $(cat /proc/cmdline); do
	case $tmp in
		ZMIENNA=*)
			ZMIENNA=${tmp#ZMIENNA=}
			;;
	esac
done

Jak już wspomniano po zakończeniuinitrd typowo uruchamiany jest standardowy init (polecam zapoznanie się z plikiem konfiguracyjnym - /etc/initab), oferuje on 7 poziomów działania (0 - wyłączenie, 1 - pojedynczy użytkownik (single), 2...5 - standardowe (najczęściej używany 2), 6 - restart). Program ten podczas zmiany poziomu rozruchu przetwarza skrypty startowe z odpowiedniego katalogu /etc/rcX.d (X- poziom rozruchu na który przechodzi init), w katalogach tych znajdują się najczęściej dowiązania symboliczne do skryptów umieszczonych w /etc/init.d. Pliki w katalogach /etc/rcX.d mają zawsze nazwy postaci YZZxxxx, gdzie Y to S gdy dany skrypt wykonywany ma być z parametrem "start" albo K gdy z parametrem "stop", ZZ to dwucyfrowy numer decydujący o kolejności wykonania, xxxx - nazwa skryptu. Przy starcie systemu najpierw wykonywane są skrypty z /etc/rcS.d a następnie zadanego poziomu (zazwyczaj /etc/rc2.d, rzadziej z /etc/rc1.d - tu na ogół i tak są same "stop", a jeszcze rzadziej z innych).

Standardowo skrypty (będące na ogół zwykłymi skryptami powłoki) mają dość złożoną strukturę - zależność działania od argumentu (start, stop, restart, ...), kontrola prawa wykonywalności uruchamianego programu; nic jednak nie stoi na przeszkodzie aby umieścić tam dowolne inne (dużo prostsze ;-) ) skrypty. Jest też programik do zarządzania rozruchem systemu - update-rc.d.

systemd

Współcześnie funkcję klasycznego init'a przejmuje systemd. W odróżnieniu od klasycznego podejścia nie opiera się on na skryptach umieszczanych w /etc/init.d i linkowanych do odpowiedniego /etc/rc*.d a na opisach usług w postaci plików konfiguracyjnych typu .desktop / .ini, jednak obsługuje też te pierwsze.

Do zarządzania plikami usług (listowania dostępnych, włączania/wyłączania autostartu, blokowania, itd) służą m.in. następujące polecenia programu systemctl:

systemctl  list-unit-files
systemctl  enable|disable  NAZWA_USLUGI
	ls /etc/systemd/system/*.target.wants/
systemctl  mask|unmask  NAZWA_USLUGI
systemctl  show|list-dependencies  NAZWA_USLUGI
systemctl  cat|edit  NAZWA_USLUGI

Poziomy startu, czyli to jakie usługi kiedy mają byćn uruchomione (z wyłączeniem rzeczy wynikłych z zależności - są one uruychamiane automatycznie na podstawie zależności zdefiniowanych w pliku usługi) opisywane są linkami w /etc/systemd/system/*.target.wants/

Do zarządzania aktualnym stanem usługi (jej startowania, zatrzymywania itd) a także wyświetlania timerów służy również program systemctl z następującymi poleceniami:

systemctl  list-units|list-timers
systemctl  status|start|stop|restart|reload  NAZWA_USLUGI

Jak wspomniano systemd jest kompatybilny z klasycznymi sktyptami startowymi (z /etc/rc[0-6].d, typowo nie dla /etc/rcS.d) - automatycznie generuje dla nich pliki konfiguracyjne usług i umieszcza je w /run/systemd/generator.late/ a linki do usług związanych z danym poziomem uruchomienia w /run/systemd/generator.late/*.target.wants/.

systemd umożliwia także tworzenie katalogów, linków itp przy starcie systemu. Np. aby mieć /tmp i /var/log na tmpfs (przydatne dla systemów np. na kartach SD) możemy utworzyć plik /etc/tmpfiles.d/on_tmpfs.conf z następującą zawartością:

d  /run/tmp   1777 root root -
L+ /tmp       -    -    -    -  /run/tmp
L+ /var/tmp   -    -    -    -  /run/tmp

d  /run/log   0755 root root -
L+ /var/log   -    -    -    -  /run/log

Zobacz w Sieci: Systemdkopia lokalna, Systemd - FAQkopia lokalna, Systemd - Timerskopia lokalna, Systemd - Userkopia lokalna, Getting Started With systemd on Debian Jessie, How To Use Systemctl to Manage Systemd Services and Units, Can systemd replace monit?.

Moduły - ładowanie, konfiguracja, ...

Jądro linuxa od dłuższego już czasu ma zmodularyzowana budowę i wiele sterowników (urządzeń, protokołów, ...) oraz innych funkcji zawartych jest w osobnych modułach. Moduły te mogą być ładowane podczas startu systemu (/etc/init.d/module-init-tools) bądź być ładowane dynamicznie lub ręcznie podczas działania systemu. Plikiem określającym jakie moduły i z jakimi parametrami chcemy załadować podczas startu jest /etc/modules, gdzie w każdej linii nie zaczętej od # pierwszy wyraz to nazwa modułu a wszystko następne to parametry.

Za konfigurację modułów (oprócz wspomnianego pliku z listą ładowanych modułów) odpowiadają również pliki w katalogu /etc/modprobe.d (wszystkie pliki w tym katalogu są równoważne). W skrypcie startowym modułów znajduje się polecenie budujące drzewo zależności (depmod), jeżeli zależy nam na przyspieszeniu startu komputera możemy je wyłączyć i uruchamiać ręcznie po zmianie, dodaniu, ... jakiś modułów, bądź modyfikacji ich parametrów w wspomnianych wyżej ktalogach.

Trzeba także zaznaczyć że w nowszych jądrach gdzie wykorzystywany jest udev, większość modułów (domyślnie) ładowana będzie automatycznie - dlatego ważniejsza jest konfiguracja /etc/modprobe* niż /etc/modules. Trzeba także zwrócić uwagę na konfigurację /etc/udev/*.

Moduły są ładowane na etapie initrd (wtedy aby jakiekolwiek zmiany konfiguracyjne mogły odnieść skutek należy przebudować initrd) lub na etapie normalnego init'a - poprzez udev (/etc/rcS.d/S03udev) lub na podstawie wspomnianego /etc/modules (/etc/rcS.d/S20module-init-tools). Oczywiście inne skrypty startowe mogą ładować swoje moduły, jeżeli robią to np. przez insmod (a nie modprobe) to wszelkie opcje z konfiguracji udev i modprobe są ignorowane.

udev

udev jest mechcanizmem służącym do dynamicznego zarządzania zawartością katalogu /dev, jego konfiguracja znajduje się w katalogu /etc/udev (osobiście polecam swoje wpisy umieszczać na początku pliku udev.rules, kolejność wykonywania reguł określana jest przez porządek linków w /etc/udev/rules.d i jest ona istotna) i umożliwia m.in. (oczywiście to tylko parę przykładów zastosowań konfiguracji udev):

Przy tworzeniu i testowaniu reguł udev'a pomocna może być komenda udevadm, która umożliwia testowanie reguł dla danego urządzenia (określonego ścieżką względem /sys) - np. udevadm test /devices/platform/ipmi_si.0/ipmi/ipmi0, uzyskanie informacji o istniejącym urzadzeniu w dev - np. udevadm info --query=all --name=ipmi0, czy też przeładowanie i wykonanie reguł na działającym systemie (w celu np. zmiany nazw interfejsów sieciowych):

udevadm control --reload-rules
udevadm trigger --action=add --verbose --subsystem-match=net

Udev do identyfikacji urządzeń oprócz czytania informacji z /sys/ korzysta z różnych pomocniczych programów są to m.in.:

Od pewnego czasu stosowane są dziwne nazwy interfejsów (np. z całym numerem MAC w nazwie), jeżeli chcemy uniknąć takiego zachowania i powrócić do klasycznych nazw interfejsów typu ethX (przydatne np. w bootowalnych nośniach USB) możemy zablokować nowy tryb nazewnictwa poprzez: ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules i ln -s /dev/null /etc/udev/rules.d/73-special-net-names.rules. Można także utworzyć plik /etc/udev/rules.d/80-net-names przypisujący nasze nazwy do interfejsów wpisami typu: SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="aa:bb:cc:dd:ee:ff", NAME="lan1"

Zazwyczj całkiem dobrym miejscem na umieszczanie swoich wpisów jest /etc/udev/udev.rules. Na koniec wspomnę że udev'owi nie zawsze udaje się ładować wszystko autmagicznie i np. aby mieć /dev/lp0 należy załadować (np. przez /etc/modules) moduł lp. Podobnie warto tam dopisać ipv6. Podobną rolę jak wpisy udev mogą pełnić w niektórych przypadkach parametry modułów określające z jakim numerem ma występować urządzenie (tak jest np. w modułach v4l) - możemy je podać w konfiguracji modprobe. Z kolei nieskuteczną drogą jest określanie numerów urządzeń poprzez wpisy alias w konfiguracji modprobe.

Zobacz też: Automontowanie systemów plików (automount, autofs).

Tablica partycji GPT

GUID Partition Table (niekiedy określany także jako tablica partycji EFI) jest jednym z kilku stosowanych typów tablic partycji (należy tutaj wspomnieć o tablicach typu disklabel charakterystycznych dla rodziny BSD, partycjach typu x86 (msdos, fdisk, mbr) charakterystycznych dla platformy PC, typu APM charakterystycznych dla Apple). W porównaniu do wymienionych konkurentów jest rozwiązaniem dość nowym i posiadającym zalety wobec nich (obsługa dużych partycji, bezpośrednia - bez zagnieżdżania bsd disklabel - obsługa systemów BSD, obsługa do 128 partycji, itd).

Do tworzenia tego typu partycji pod linuxem możemy posłużyć się GNU parted (niestety fdisk ich nie wspiera):

# tworzymy tablicę partycji typu gpt
parted $DEV "mklabel gpt"

# tworzy partycję która posłuży do wgrania gruba
# należy zaznaczyć iż nie jest to partycja /boot
# jest to surowe (bez filesystemu) miejsce na dysku gdzie
# zostanie wgrany fragment gruba normalnie wgrywany zaraz za MBR
parted $DEV "mkpart grub 0 2MB";

# ustawiamy dla tej partycji flagę "GRUB BIOS partition"
parted $DEV "set 1 bios_grub on"

# resztę dysku możemy podzielić wg uznania
# w tym przykładzie robimy jedną dużą partycję o nazwie raid
parted $DEV "mkpart raid 2MB 100%";  

Tak zainstalowany GRUB2 radzi sobie bez problemu z partycjami GPT, macierzami mdadm, wolumenami LVM itd.

RAID i LVM - bezpieczniejsze, większe i bardziej elastyczne partycje dyskowe

Linux oferuje dwie przydatne technologie dotyczące zarządzania pamięciami masowymi - jest to programowy RAID oraz woluminy logiczne LVM. RAID umożliwia realizację różnych form mirroringu mających na celu zabezpieczenie przed utratą danych, a także uzyskiwanie większych przestrzeni złożonych z kilku dysków. LVM służy umożliwieniu bardziej elastycznego podziału dysku oraz uzyskania logicznych partycji złożonych z wielu różnych fragmentów dysków fizycznych. Również główny system plików (/) może korzystać z tych dobrodziejstw, należy tylko pamiętać aby gdy korzystamy z LVM bądź RAID'a innego niż RAID1 zostawić zwykłą partycję na /boot (pliki bootloadera i obrazy jądra).

	# tworzymy RAID1 dla partycji /
	mdadm -C -v /dev/md0 --level=1 -n 2 /dev/sda1 /dev/sdb1
	# tworzymy zdegradowany RAID1 dla dwóch partycji na których będzie /home
	mdadm -C -v /dev/md1 --level=1 -n 2 /dev/sda3 missing
	mdadm -C -v /dev/md2 --level=1 -n 2 /dev/sdb3 missing
	
	# tworzymy volumeny fizyczne na urządzeniach RAID dla potrzeb LVM
	pvcreate /dev/md1
	pvcreate /dev/md2
	# tworzymy grupę voluminów dla LVM
	vgcreate lvm0 /dev/md1
	# dodajemy volumen fizyczny do grupy
	vgextend lvm0 /dev/md2
	# można też usunąć przy pomocy:
	# vgreduce lvm0 /dev/md2
	# tworzenie volumenu logicznego o zadanej wielkości i nazwie w ramch podanej grupy
	# będzie z nim związane urządzenie /dev/lvm0/home
	lvcreate -L 25G -n home lvm0
	# ogladamy to co żesmy stworzyli
	pvdisplay
	vgdisplay
	lvdisplay
	# powiększamy volumen logiczny
	lvextend  -L +1GB  /dev/sys/homes
	# powiększamy system plików, np.
	#  xfs_growfs /home
	#  resize2fs /dev/lvm0/home
	#  btrfs filesystem resize max /home
	#  # więcej poleceń btrfs-owych: https://btrfs.wiki.kernel.org/index.php/Btrfs%28command%29
	
	# uzupełniamy nasz zdegradowany raid
	/sbin/mdadm -a /dev/md1 /dev/sdc1
	/sbin/mdadm -a /dev/md2 /dev/sdc2

Do kasowania macierzy możemy posłużyc się komendą: mdadm -S --zero-superblock /dev/md14; mdadm -S /dev/md11

Warto zachęcać LVM do używania identyfikatorów dysków w tym celu: w /etc/mdadm/mdadm.conf umieszczamy wpis DEVICE /dev/disk/by-id/*, macierz budujemy (w tym przykładzie raid 6 na 8 dyskach) np. mdadm -C -v --auto=mdp --level=raid6 --raid-devices=8 /dev/disk/by-id/scsi-*part2 i w oparciu o wynik mdadm --detail --scan edytujemy /etc/mdadm/mdadm.conf

W zasadzie LVM sam się konfiguruje przy uruchamianiu jądra, ale niekiedy może zajść potrzeba ręcznego uruchamiania LVM w trakcie startu systemu. Procedura takiej operacji wygląda następująco:

  1. załadowanie modułów od devicemaper dm-mod i od lvm lvm* (jeżeli jest jako moduły)
  2. jeżeli udev nie potworzył urządzeń to tworzymy ręcznie:
    mknod --mode=600 /dev/lvm c 109 0
    mknod --mode=600 /dev/mapper/control c 10 62
    # numery możemy odczytać z /proc/device:
    #  major = misc
    #  minor = device-mapper
  3. wykonanie /sbin/vgscan, ewentualnie z opcjami --ignorelockingfailure i/lub --mknodes
  4. wykonanie /sbin/vgchange -a y, ewentualnie z opcją --ignorelockingfailure
  5. ustawienie odpowiednich uprawnień do urządzeń

W przypadku ręcznej konfiguracji LVM na wczesnych etapach działania systemu może pojawić się problem z tworzeniem pliku blokady - "LVM - Locking type 1 initialisation failed", spowodowane to może być tym iż partycja zawierająca /var/lock jest w trybie tylko do odczytu, rozwiązaniem jest np. mount -t tmpfs tmpfs /var/lock

Niekiedy (np. niezgodne UUIDy dysków/partycji wchodzących w skład RAIDa) może zajść potrzeba ręcznego wystartowania RAIDa wg podanego trybu i na podanych urządzeniach. W tym celu należy (po zatrzymaniu raida który wystartował z błędem poprzez mdadm -S /dev/mdX) skorzystać z opcji --create --assume-clean do polecenia mdadm wraz z określeniem jaki typ raida, z ilu dysków i wylistoiwaniem tych dysków, np. mdadm --create --assume-clean --level=1 --raid-devices=2 /dev/md1 /dev/sda1 /dev/sdb1. Odczyt UUIDów oraz innych informacji odnośnie RAIDa zapisanych na składowym dysku możliwy jest za pomocą: mdadm --examine /dev/sda1. W przypadku kłopotów z mdadm'em przydatne mogą być także opcje --scan, --detail, --verbose.

Zobacz w Sieci: RAID programowykopia lokalna, Instalacja Linuksa Na Raid1, Migracja Serwera Na RAID1, LVMkopia lokalna, LVMkopia lokalna.

Konfiguracja sieci bezprzewodowej

W trybie klienta podstawowym narzędziem konfiguracji dostępu sieci bezprzewodowej są narzędzia z pakietu iwconfig (umożliwiające włączanie interfejsów, skanowanie, etc) oraz wpa_supplicant (umożliwijący dostęp do sieci zabezpieczonych WPA - Przykładowy plik konfiguracyjny).

Możliwe jest także zastosowanie systemu linux (z odpowiednią kartą sieciową) jako access-pointa - służy temu hostapd (Przykładowy plik konfiguracyjny) wraz z serwerem DHCP (i ew. DNS) - np. dnsmasq.

Przykładowa konfiguracja dnsmasq:

interface=wlan0
dhcp-range=wlan0,192.168.22.193,192.168.22.222,255.255.255.0,1h
log-dhcp

Tworzenie mirroru zainstalowanego systemu

Jako że w systemach POSIXowatych "wszystko jest plikiem", zdecydowaną większość z nich możemy przenosić na inny sprzęt, powielać, backupować po prostu kopiując pliki (wraz z atrybutami). W celu wykonania kopii systemu na innym dysku/partycji (przeniesienia działającego systemu) należy najpierw utworzyć system plików na tym urządzeniu z wykorzystaniem stosownych narzędzi - fdisk, mkfs, tune2fs, następnie podmontować gdzieś ten system plików i przy pomocy cp -a skopiować pliki z starego na nowy dysk (warto tutaj skorzystać z symboli wieloznacznych basha np. /[a-o]* tak aby wyspecyfikować wszystkie katalogi za wyjątkiem /proc /sys oraz katalogu w którym podmontowaliśmy nowy system). Po skopiowaniu systemu należy odpowiednio zmodyfikować /etc/fstab na nowym systemie oraz konfigurację bootloadera.

Najprostszą metodą stworzenia kopi zapasowej systemu czy też przeniesienia zainstalowanego systemu na kilka maszyn (nie muszą być nawet takie same) jest wykorzystanie programu tar oraz ssh do zdalnego zapisu/odczytu pliku kopi:

	# utworzenie kopii zapasowej
	cd / && tar -cf - --exclude="./proc/*" --exclude="./sys/*" --exclude="./dev/*" --exclude="./run/*" --exclude="./mnt/*" --exclude="./media/*" --exclude="./srv/*" --exclude="./home/*" --exclude="./tmp/*" . | ssh user@host 'cat > /path/to/file.tar'
	
	# przywrócenie systemu
	# uprzednio fdisk, mkfs, mount nowego FS
	cd /mount/point/of/root/fs && ssh user@host 'cat /path/to/file.tar' | tar --numeric-owner -xf -
	grub-install --root-directory=/mount/point/of/root/fs --recheck /dev/device_witch_system
	
	# bezpośrednie kopiowanie pomiędzy dyskami (nowy zamontowany w /mnt):
	cd / && tar -cf - --exclude="./proc/*" --exclude="./sys/*" --exclude="./dev/*" --exclude="./run/*" --exclude="./mnt/*"  --exclude="./media/*" --exclude="./srv/*" --exclude="./home/*" --exclude="./tmp/*" . | tar --numeric-owner -C /mnt/ -xf -

W przypadku przenoszenia w ten sposób systemu na inną maszynę może być konieczna edycja plików konfiguracyjnych związanych z siecią (dla Debiana /etc/network/interfaces, /etc/udev/rules.d/*-persistent-net.rules, /etc/hosts, /etc/hostname, ...) oraz w przypadku specyficznych ustawień innych plików ...

Oczywiście możliwe jest także kopiowanie całych urządzeń blokowych (z odmontowanymi systemami plików) przy pomocy dd. Tak powstały obraz dysku może zostać zamontowany bezpośrednio z postaci pliku. Przykład montowania (dla obrazu karty SD dla Raspberry Pi):

IMAGE=rpi.img
MNT=/mnt

# map image to loop device
kpartx -va $IMAGE

# get loop device name, and mount partitions
DEV=/dev/mapper/`kpartx -l $IMAGE | awk '/^loop[0-9]/ { print gensub("^(loop[0-9]*)p.*$", "\\\1", "", $1); exit; }'`
mount ${DEV}p2 $MNT
mount ${DEV}p1 $MNT/boot

# chroot
chroot $MNT

[...]

# umount and remove map
umount $MNT/boot
umount $MNT
kpartx -d $IMAGE

Uwagi o hasłach

Do zmiany hasła korzystamy z polecenia passwd (podając następnie stare hasło i dwukrotnie nowe), zmiana ta nie dotyczy jednak zazwyczaj haseł do innych usług (np.: MySQL'a - hasło to zmieniamy poleceniem mysqladmin -unazwa-użytkownika -pstare-hasło password nowe-hasło, uwaga nazwę użytkownika poprzedza u (bez spacji), a stare hasło p (również bez spacji))

Wycinki z Debian Reference

Jest to subiektywny wybór linków do kilku fragmentów Debian Referencekopia lokalna (bardziej aktualna wersjakopia lokalna).

Podstawy Unix'a:

Warto wiedzieć:

Dla admina:

Unixowate systemy operacyjne

Wbrew pozorom/wrażeniom które niekiedy można odnieść Linux nie jest jedynym współczesnym "posixowatym" systemem operacyjnym. Z istotnych pozycji na rynku open-source należy wymienić przynajmniej także rodzinę BSD oraz OpenSolaris'a. Co prawda większość prezentowanych w tym serwisie artykułów powstała w oparciu o system GNU/Linux, a konkretnie dystrybucję Debian, to jednak wiele z tych rozwiązań sprawdzi się w innych dystrybucjach (nie tylko tych debiano-podobnych), a często także innych systemach "posixowych".

*BSD

Jest to znana i ceniona rodzina systemów operacyjnych, wywodząca się od oryginalnego Unixa, dystrybuowana na bardzo liberalnej licencji. Do użytkowania i konfiguracji systemów z tej rodziny odnoszę się w kilku artykułach w tym serwisie. Większość informacji dotyczy FreeBSD i OpenBSD co nie znaczy że nie mogą one być przydatne w innych systemach z tej rodziny takich jak NetBSD, BSD/OS.

(Open)Solaris

Solaris jest unixowym systemem operacyjnym opracowanym przez Sun jest następcą SunOs'ów i niekiedy nazywany jest SunOS 5.x, gdzie x to numer wersji Solarisa (pierwotnie numery Solarisów poprzedzane były dodatkowo 2.). W wielu aspektach przypomina systemy *BSD, z którymi łączy go wspólny przodek. Elementem wyróżniającym go z pośród innych systemów operacyjnych jest zaawansowany system plików ZFS (Zettabyte File System). System ten posiada wbudowane mechanizmy zarządzania dyskami będące odpowiednikiem programowego RAID oraz LVM (stanowiące dodatkową warstwę abstrakcji pomiędzy sprzętem a samym systemem plików). System obok oficjalnej Sun'owskiej gałęzi posiada także gałąź na wolnej licencji - OpenSolaris. Poniżej przedstawię kilka uwag konfiguracyjnych dotyczących tego systemu, a w szczególności OpenSolarisa.

inne ...

Oczywiście wyżej przedstawione systemy nie wyczerpują całej gamy systemów operacyjnych (nawet jeżeli brać pod uwagę tylko te POSIXowate lub tylko te typu FLOS). Z systemów o których uważam że trzeba tu wspomnieć są jeszcze dwa systemy wywodzące się z architektury PPC (stare Mac'i) - są to Haiku (dawniej OpenBeOS) oraz Darwin.

Haiku jest będącym ciągle w (dość wczesnej) fazie rozwojowej wolnym (na licencji MIT X11) klonem BeOSa. Sam BeOS był posixowym systemem operacyjnym, wyposarzonym w środowisko graficzne, ale bez X-serwera. Oprócz dobrego wsparcia dla multimediów system charakteryzował się interesującym systemem plików z bardzo rozbudowanymi atrybutami (np. wszystkie dane książki adresowej były przechowywane jako atrybuty pustych (!!) plików). W serwisie tym kiedyś było trochę więcej na temat tego systemu - zainteresowanych zapraszam do archiwum oraz działu o C/C++. System pomimo swojej unixowatości odbiegał jednak dość znacznie (np. strukturą katalogów) od powszechnie spotykanych unixów - programy były przechowywane np. w katalogach /boot/beos/bin i /boot/home/config/bin, ten drugi miał wyższy priorytet w ścieżce wyszukiwania, konfiguracja umieszczona była w /boot/home/config/settings/, a za autostart odpowiadał skrypt bashowy /boot/home/config/boot/UserBootscript, sam basz natomiast był dostępny tylko jako /bin/sh (a nie jako /bin/bash).

Darwin jest unixowatym systemem operacyjnym, stanowiącym podstawę dla Mac OS X. Swoimi korzeniami sięga systemów z rodziny BSD.

Jeszcze innym, niekiedy bardzo przydatnym system operacyjnym FLOS jest FreeDOS, warta uwagi jest także jego odmiana w formie bootującej dyskietki - Balder.

Linki

Zobacz także: man nazwa-polecenia i/albo info nazwa-polecenia i/albo nazwa-polecenia --help.

Zachęcam też do zapoznania się z artykułemi o konfiguracji sieci IP, podstawowych usługach w sieciach komputerowych, bazą przydatnych programów, obróbce multimediów, poradami konfiguracyjnymi.

Zobacz w Sieci: The Debian Administrator's Handbookkopia lokalna, The Linux Documentation Project - Guideskopia lokalna, Debian refcardkopia lokalna, Unix Toolboxkopia lokalna, Identyfikacja i testowanie sprzętu PC pod Linuksem, A Quick Introduction to Unix, Guide to Unix, Guide to X11, FOSS Network Infrastructure and Security

Warty uwagi jest także commandlinefu.com - serwis gromadzący przykłady użycia różnych komend unixowych. Aby wykodnie kożystać z poziomu powłoki możemy w jej pliku startowym zdefiniować funkcję wyświetlającą przykłady dla danego polecenia - np.: fu() { wget -O - "http://www.commandlinefu.com/commands/matching/$@/$(echo -n $@ | openssl base64)/plaintext" 2>/dev/null; };



Copyright (c) 1999-2015, Robert Paciorek (http://www.opcode.eu.org/), BSD/MIT-type license


Redystrybucja wersji źródłowych i wynikowych, po lub bez dokonywania modyfikacji JEST DOZWOLONA, pod warunkiem zachowania niniejszej informacji o prawach autorskich. Autor NIE ponosi JAKIEJKOLWIEK odpowiedzialności za skutki użytkowania tego dokumentu/programu oraz za wykorzystanie zawartych tu informacji.

This text/program is free document/software. Redistribution and use in source and binary forms, with or without modification, ARE PERMITTED provided save this copyright notice. This document/program is distributed WITHOUT any warranty, use at YOUR own risk.

Valid XHTML 1.1 Dokument ten (URL: http://www.opcode.eu.org/debian_and_posix) należy do serwisu OpCode. Autorem tej strony jest Robert Paciorek, wszelkie uwagi proszę kierować na adres e-mail serwisu: webmaster@opcode.eu.org.
Data ostatniej modyfikacji artykulu: '2016-05-03 07:48:39 (UTC)' (data ta może być zafałszowana niemerytorycznymi modyfikacjami artykułu).