Ostatnia rewizja: 18/07/2012

Montowanie i oznaczenia urządzeń blokowych

Trochę teorii

Nazwa "urządzenia blokowe" jest umowna i oznacza zwykle urządzenia z którymi komunikacja odbywa się za pomocą pakietów danych nazywanych blokami. Urządzenie blokowe komunikuje się z komputerem najczęściej z użyciem buforów i umożliwia swobodny dostęp do przestrzeni adresowej. Warunki te spełniają dyski twarde, CD-ROM-y, pamięci flash...

Po co montować urządzenia?

W Windows po włożeniu nośnika (płyty do napędu, pendrive do USB, ...) po chwili pojawia się możliwość korzystania z jego zawartości – w Linuksie też, z tym że jak ze wszystkim, nie jest to takie oczywiste. Po dodaniu nowego nośnika nie ma udostępnionej możliwości korzystania z niego (bo niby dlaczego miałaby być?), ta możliwość pojawia się dopiero po zamontowaniu tego nośnika. Montowanie polega na wskazaniu katalogu, w którym ma się pojawić zawartość nośnika. W trakcie montowania można określić różne opcje opcje, na przykład dla pendrive'a będziemy chcieli prawdopodobnie mieć możliwość zapisu.

W dzisiejszych czasach prawie nikt już nie montuje nośników z konsoli. Po prostu wkłada się pendrive'a czy płytę do napędu, pojawia się ikonka na pulpicie i działa. Kiedyś nie było tak dobrze.

W dalszym ciągu możemy mieć jednak do czynienia z sytuacją gdy automatyczne montowanie zawiedzie. Warto też znać oznaczenia linuksowych urządzeń, aby umieć je podać jako argument dla różnych programów działających niskopoziomowo. Przedstawiona tu wiedza przyda się do zarządzania partycjami na dysku i ich formatowania.

To wszystko brzmi strasznie, ale sprowadza się do zapamiętania bardzo prostego wzoru, który nawet humaniście nie sprawi problemu.

Oznaczenia urządzeń

Może zamiast teoretyzować zobaczmy jak to wygląda w praktyce:


  /dev/sda - primary master
  /dev/sdb - primary slave
  /dev/sdc - secondary master
  /dev/sdd - secondary slave

(w starszych systemach odpowienio /dev/hda, /dev/hdb, /dev/hdc, /dev/hdd)

  /dev/sr0 - pierwszy nośnik wymienny SATA lub USB
  /dev/sr1 - drugi magazyn wymienny SATA lub USB
  ...
  /dev/sr9 - dziesiąty magazyn wymienny SATA lub USB
  ...

(w starszych systemach odpowiednio /dev/sda, /dev/sdb, /dev/sdj)

Oznaczenia primary/secondary master/slave zależą oczywiście od fizycznego ustawienia zworek w na dyskach / napędach (dotyczy tych podłączanych przez gniazda IDE), można je odczytać także na ekranach startowych BIOS-u, takich jak te.

Zamiast zgadywać nazwy urządzeń, można wyświetlić sobie zawartość /etc/fstab, dyski twarde zobaczyć testdiskiem, a napędy znaleźć w dmesg lub K3B. Zwykle jednak w komputerze nie ma urządzeń nadających się do montowania w większej ilości niż 6-7, więc jesteśmy w stanie ich nazwę utworzyć sobie w pamięci.

A co z numerkami? Spotkałeś się zapewne z zapisami takimi jak /dev/hda5. Najprościej posiłkować się obrazkiem, który był już umieszczony we wcześniejszym dziale:

Podział na partycję rozszerzoną i dysk logiczny

Kolejne numerki oznaczają kolejne partycje.

Weźmy jakieś praktyczne zastosowanie dla tej wiedzy, oprócz zabawy z partycjami. Kupiłeś sobie nagrywarkę na SATA, która otrzymuje nieznaną w starym KDE nazwę urządzenia (/dev/sr0). Należałoby więc we własnym zakresie utworzyć skrót na pulpicie:

Utwórz nowe -> Dowiązanie do urządzenia -> Nagrywarka CD

Wybieramy odpowiednie urządzenie na zakładce Urządzenie

Montowanie

Uruchamiasz Linuksa w środowisku tekstowym, chcesz włączyć X, jednak zapomniałeś go zainstalować. Wkładasz płytę instalacyjną z pakietami i... nic. No przecież ktoś ją musi zamontować.

Użytkownik nie ma prawa do montowania, dlatego przeloguj się na roota. Następnie poszukaj gdzie ta płyta jest:

Jest pod hda. Czas poszukać jakiegoś punktu montowania, czyli miejsca gdzie obraz płyty zostanie "odbity" i użytkownik będzie mógł z niego korzystać. Może to być zupełnie dowolne miejsce, ale zwyczajowo przyjmuje się, że płyty montujemy w jakimś podkatalogu /mnt lub /media:

Zamontujmy płytkę pod cdrom. W razie braku odpowieniej pozycji możemy zawsze ją utworzyć: mkdir /mnt/cdrom

Jak dzisiaj wygląda automatyczne montowanie?

W nowoczesnych dystrybucjach linuksowych obowiązuje pewien standard obsługi urządzeń. Zobaczmy jak on wygląda na przykładzie włożenia pendrive'a do gniazda USB:

Za Wiki Archlinuksa

Sam pomysł montowania wynika oczywiście z tego, że Linux niczego nie robi sam bez wyraźnego polecenia. Brak uprawnień do montowania dla zwykłego użytkownika to efekt jak zwykle przesadnej dbałości o bezpieczeństwo.

Montowanie przez zwykłego użytkownika – /etc/fstab

Spójrzmy w /etc/fstab na taki wpis:


urządzenie	punkt montowania    system plików	opcje		dump	fsck
/dev/sdb	/media/pendrive 	auto	rw,noauto,user,sync	 0	 0

Najważniejsza jest tu linijka opcje. Jak widać utworzyliśmy sobie wpis dla pendrive'a z opcją montowania w trybie do odczytu i zapisu (rw - read write), który nie będzie montowany automatycznie (ale można to przecież zmienić jak ktoś lubi), który może być montowany przez zwykłego użytkownika (user), i który będzie zapisywany synchronicznie, czyli bez opóźnienia. W przypadku opcji async dane zostaną zapisane dopiero jakiś czas po żądaniu ich zapisania. Zwiększa to szybkość i trwałość nośnika kosztem bezpieczeństwa (jeśli ktoś na przykad zapomni odmontować przed wyjęciem, dane nie zostaną zapisane).

Każde mądrzejsze środowisko graficzne potrafi, korzystając z takiego wpisu, wyświetlić ikonkę pendrive'a i go zamontować przy pierwszej próbie użycia. Poprawnie skonfigurowane demony Udev, D-bus i PolicyKit zastępują wpisy dla nośników wymiennych z pliku /etc/fstab. Przy użyciu demonów (a nie wpisów w /etc/fstab), aby dodać niestandardowe opcje montowania należy ustawić je odpowiednio w środowisku graficznym.

Udev, D-Bus i PolicyKit — jak się ich pozbyć? (apologia)

(Poniższy tekst wbrew nagłówkowi nie zawiera instrukcji jak pozbyć się Udeva, D-Busa i PolicyKita)

Na trio Udev, D-Bus i PolicyKit pojawiają się często narzekania z powodu wad w samych założeniach (choćby skomplikowana konfiguracja przez pliki XML, dziwne komunikaty), niepoprawnej domyślnej konfiguracji w niektórych tak zwanych "przyjaznych" dystrybucjach oraz niepoprawnej implementacji funkcjonalności w środowiskach graficznych. W przeciwieństwie do większości linuksowych demonów, Udev, D-Bus i PolicyKit przeznaczone są do integracji ze środowiskiem graficznym (projekt freedesktop), a ich przewagą nad starymi rozwiązaniami jest brak sztywno określonej bazy podłączanych urządzeń (w opozycji do statycznej zawartości /etc/fstab czy devfs zastąpionego przez udev). Teoretycznie od jakiegoś czasu do komputera z Linuksem można podłączać "pod prądem" klawiatury, ekrany, touchpady i inne urządzenia, które będą natychmiast obsługiwane. PolicyKit może zastąpić wszelkie pytania o hasło roota, umożliwiając wygodną pracę zgodnie z nadanymi przez administratora wcześniej uprawnieniami (np. konfiguracja sieci, usypianie systemu, instalowanie oprogramowania).

Ta technologia naprawdę jest przyszłością i już w tej chwili sprawdza się dobrze w popularnych zastosowaniach pod porządnymi dystrybucjami. Integracja ze środowiskami graficznymi czyni usunięcie tych demonów dosyć karkołomnym zadaniem. Zamiast miotać się z nimi, lepiej zainstalować ich najnowsze wersje i sprawdzić swoje uprawnienia. W tej chwili problematyczne jest tylko montowanie dysków wewnętrznych, które nie mają wpisów w /etc/fstab (z opcją user), można w tym celu zmienić konfigurację PolicyKita. I tylko tyle, w typowych zastosowaniach nie ma w ogóle potrzeby edytować konfiguracji Udeva, D-Busa czy PolicyKita przez pliki tekstowe w /etc.

PolicyKit i autoryzacja przy montowaniu dysków wewnętrznych

Policykit: Not Authorized, Authentication is required to mount the device, wpisywanie hasła i inne głupoty przy montowaniu swoich własnych dysków: kiedy to się wreszcie skończy? Nigdy! Chyba że przeczytasz ten artykuł.

PolicyKit domyślnie nie pozwala na dostęp zwykłego użytkownika do dysków wewnętrznych, które nie posiadają wpisów we fstabie z opcją user. Kwestie bezpieczeństwa zapewne, ale użytkownika to raczej nie interesuje. Najpoprawniej będzie, jeśli wpiszesz po prostu te partycje do /etc/fstab. Jeśli jednak nie chcesz z jakichś powodów, poniżej przedstawiony został sposób na zmianę domyślnej konfiguracji PolicyKita. Zacznijmy od tego, że regułki PolicyKita są dostępne w /usr/share/polkit-1/actions/. Po małej inwencji polegającej na przeszukiwaniu treści XML-ów znajdujemy plik org.freedesktop.udisks.policy z taką treścią:

lokalna kopia udisks_policy w razie niedziałania usługi pastebin

allow_any, allow_inactive and allow_active to oznaczenia odpowiedzi, które PolicyKit zwróci każdej, nieaktywnej oraz aktywnej sesji (czymkolwiek sesja jest). Więcej informacji na temat konfiguracji Policykita w oficjalnej pomocy. Z doświadczenia wynika, że allow_active załatwia sprawę dla zwykłego użytkownika. Jak widać mount-system-internal posiada wartość auth_admin_keep, co powoduje wyświetlanie zapytań o hasło.

Nie trzeba nam jednak edytować tego XML-a – zostanie on nadpisany przy aktualizacji. Zamiast tego udajemy się do /etc/polkit-1/localauthority. Znajdziemy tam katalogi 10-vendor.d 20-org.d 30-site.d 50-local.d 90-mandatory.d. W katalogach tych mieszczą się pliki konfiguracyjne PolicyKita. Użytkownik powinien swoje pliki zapisać do 50-local.d. Liczby na początku nazw umożliwiają łatwe sortowanie reguł w porządku alfanumerycznym, to znaczy 30 występuje przed 50. Reguły stosowane są na zasadzie kaskady, to znaczy jeśli w katalogu 30-site.d znajdzie się plik zabraniający montowania, a w 50-local.d pozwalający montować, to ten ostatni decyduje. Jeśli jednak dodatkowo w 90-mandatory.d znajdzie się plik zabraniający montowania, wtedy PolicyKit nie zezwoli na zamontowanie urządzenia. Warto sprawdzić, czy w podanych katalogach nie znajdują się już jakieś reguły, które mogłoby nadpisać te, które zaraz utworzymy (zwykle jednak niczego tam nie ma).

Plik konfiguracyjny PolicyKita powinien mieć nazwę odnoszącą się do programu, którym ten będzie zarządzać, na przykład 10-udisks.pkla. Liczba porządkowa ułatwia sortowanie. Rozszerzenie jest obligatoryjne.

Plik powinien mieć następującą postać:


[Dowolna nazwa klucza]
Identity= unix-group:nazwa_grupy lub unix-user:użytkownik, wartości łączymy średnikiem
Action= przyporządkowujemy wartość action id z XML-a powyżej. Można użyć symbolu "*"
ResultAny= odpowiedź zwracana każdej sesji wysyłającej żądanie
ResultActive= odpowiedź zwracana aktywnej sesji wysyłającej żądanie //to zmieniamy
ResultInactive= odpowiedź zwracana nieaktywnej sesji wysyłającej żądanie 

Wartości dla kluczy Result to: yes, no, auth_self, auth_self_keep, auth_admin oraz auth_admin_keep. Aby nadpisać domyślne opcje montowania urządzeń wewnętrznych, utwórzmy plik konfiguracyjny PolicyKita 10-udisks.pkla z następującą treścią:

[Internal Disks Permissions]
Identity=unix-group:disk
Action=org.freedesktop.udisks.*-internal*
ResultAny=no
ResultActive=yes
ResultInactive=no

Naturalnie użytkownik, który ma korzystać z tego uprawnienia, musi należeć do grupy disk. Można ustawić grupę users, jeśli ktoś woli. Jak widać użyto wieloznacznika (*), który dopasuje nam ładnie reguły dotyczące dysków wewnętrznych. PolicyKit jest tutaj dosyć elastyczny, umożliwia także wpisanie kilku reguł oddzielonych średnikiem, jeśli chcemy je określić dokładnie. Zapis Action=*udisks* także zadziała, lecz może być niebezpieczny ze względu na zbyt szerokie uprawnienia.