Sr-08-lab-1.0
Network File System
Mapowanie użytkowników
Identyfikacja użytkowników w systemie NFS odbywa się wg. ich identyfikatorów numerycznych. Oznacza to, że w przypadku niezgodności w konfiguracji użytkowników pomiędzy systemami klienta i serwera może dojść do nieuprawnionego dostępu do danych. Z tego powodu w domyślnej konfiguracji konto użytkownika root podlega mapowaniu na użytkownika o identyfikatorze -2 (65534). Działanie to można kontrolować następującymi parametrami eksportowania katalogów:
root_squash- włączenie mapowania użytkownika o identyfikatorze 0 (
root) na użytkownika o identyfikatorze -2 (nobody) no_root_squash- wyłączenie mapowania użytkownika 0
all_squash- mapowanie wszystkich użytkowników do użytkownika o identyfikatorze -2
anonuid- identyfikator użytkownika anonimowego
anonguid- identyfikator grupy użytkownika anonimowego
Poniższy przykład pokazuje konfigurację serwera NFS udostępniającego katalogi domowe użytkownikom systemów innych niż Unix:
/home/pc1 pc1(rw,all_squash,anonuid=1001,anongid=100) /home/pc2 pc2(rw,all_squash,anonuid=1002,anongid=100) /home/pc3 pc3(rw,all_squash,anonuid=1003,anongid=100)
W przykładzie użytkownik użytkownik o identyfikatorze 1001 korzysta z komputera o nazwie pc1 i należy do grupy o identyfikatorze 100. Serwer NFS udostępnia jego katalog domowy tylko dla komputera pc1. Analogicznie użytkownicy 1002 i 1003 korzystają z komputerów pc2 i pc3.
Mapowanie statyczne
Serwer może wprowadzić statyczną tabelę odwzorowań użytkowników z systemu klienta na użytkowników serwera. Wymaga to wyspecyfikowania dodatkowej opcji w konfiguracji wskazującej na plik z odwzorowaniami:
/home *.cs.put.poznan.pl(rw,map_static=/etc/nfs/home.map)
Zawartość pliku /etc/nfs/home.map definiuje odwzorowania poszczególnych użytkowników:
uid 0-99 - # mapowanie do nobody uid 100-500 1000 # mapowanie 100-500 na 1000-1400 gid 0-49 - # mapowanie id grup 0-49 na -2 gid 50-100 700 # mapowanie grup 50-100 na 700-750
Mapowanie dynamiczne
Wadą mapowania statycznego jest oczywiście jego statyczność. Rozwiązanie dynamiczne polega na uruchomieniu po stronie klienta dodatkowej usługi, której zadaniem jest udostępnianie informacji o odwzorowaniach identyfikatorów użytkowników na nazwy. W celu należy po stronie klienta uruchomić proces:
# rpc.ugidd
a do konfiguracji serwera dopisać nową opcję:
/home *.cs.put.poznan.pl(rw,map_daemon)
WebNFS
WebNFS to rozszerzenie standardowego protokołu NFS o możliwość pobierania plików za pośrednictwem publicznego uchwytu do plików. Umożliwi to proste pobieranie plików np. przez przeglądarki internetowe. Konfiguracja wymaga wskazania głównego katalogu dla WebNFS i udostępnienia wybranych katalogów w zwykły sposób. Oto przykładowa konfiguracja:
/test =public /test *.cs.put.poznan.pl(ro,all_squash,insecure)
W przeglądarce należy wpisać odpowiedni adres URL:
nfs://galio.cs.put.poznan.pl/plik.txt
Przeglądarka Konqueror obsługuje rozszerzenie WebNFS.
Automonter
Dołączanie systemów plików może być automatyzowane za pomocą uzupełniającego oprogramowania uruchamianego po stronie klienta o nazwie automounter. Konfiguracja automontera opiera się na głównym pliku konfiguracyjnym /etc/auto.master oraz na plikach uzupełniających /etc/auto.*. W pliku /etc/auto.master wskazywane są katalogi, które będą kontrolowane przez oprogramowanie automontera:
/home /etc/auto.home /a /etc/auto.a
Nazwa pliku pojawiająca się po nazwie katalogu wskazuje na szczegółowy plik konfiguracyjny opisujący dany katalog. Skrypt startowy automontera dla każdego katalogu wymienionego w pliku /etc/auto.master uruchamia komendę automount wskazując plik konfiguracyjny. W przypadku katalogu /home zostanie więc wydana komenda:
# automount /home file /etc/auto.home
Argument file wskazuje, że konfiguracja znajduje się w zwykłym pliku o nazwie wskazanej trzecim argumentem. Dane dla automontera mogą również pochodzić z systemu NIS (zobacz punkt) lub mogą być generowane dynamicznie przez program. Szczegółowy opis konfiguracji znajduje się stronie pomocy systemowej autofs(5).
Działanie automontera sprowadza się do monitorowania odwołań do podkatalogów kontrolowanego katalogu. W przypadku stwierdzenia odwołania do zdefiniowanego katalogu następuje jego dołączenie, zgodnie ze wskazaniami z pliku konfiguracyjnego. Poniższy przykład prezentuje konfigurację z pliku /etc/auto.home:
user1 unixlab:/home/user1 user2 galio:/export/home/user2 user3 -fstype=ext3,rw :/dev/sda4
W pierwszej kolumnie znajdują się nazwy podkatalogów konfigurowanego katalogu. Druga kolumna (opcjonalna) zawiera dodatkowe opcje montowania systemu plików. Trzecia kolumna to wskazanie na system plików. Zakładając powyższą konfigurację wykonanie komendy:
# ls /home/user1
spowoduje dołączenie katalogu zdalnego /home/user1 z systemu unixlab. Katalog domowy użytkownika user3 dołączany jest z lokalnego systemu plików, co powoduje wykonanie przez automontera komendy:
# mount -o rw -t ext3 /dev/sda4 /home/user3
W przypadku konfiguracji katalogów domowych użytkowników, których pliki znajdują się w podkatalogach jednego wspólnego katalogu, można zastosować zapis skrócony:
* unixlab:/export/home/&
Znak * oznacza w tym miejscu dowolny ciąg znaków, który zostanie następnie użyty w miejscu wystąpienia znaku &. Odwołanie do katalogu /home/abc spowoduje więc próbę dołączania katalogu /export/home/abc z systemu unixlab.
Zwiększanie dostępności
Automonter umożliwia zwiększanie dostępności zdalnych katalogów poprzez ich replikację. Zakładając, że serwery srv1 i srv2 udostępniają to samo oprogramowanie w katalogu /usr/local, można rozważyć następującą konfigurację:
local / srv2:/usr/local / srv1:/usr/local
W przykładzie wskazano na dwa źródła dla podkatalogu local co oznacza, że niemożność dołączenia tego katalogu z systemu srv1 spowoduje dołączenie go z srv2. Ponieważ cała operacja będzie niewidoczna dla użytkownika, jedynym efektem tej konfiguracji będzie zwiększona niezawodność zdalnego katalogu. Parametr poprzedzający wskazanie na dalszy serwer oznacza dodatkowy podkatalog katalogu local, który pojawi się w momencie dołączenia systemu plików, co może umożliwić rozróżnienie przez użytkownika źródła danych.
Dynamiczna konfiguracja
Dane dla automontera mogą pochodzić z programu dynamicznie generującego konfigurację. Wymaga to uruchomienia programu automount z opcją program:
# automount /a program /etc/auto.sh
W powyższym przykładzie konfigurację dostarcza skrypt /etc/auto.sh. Program ten jest wywoływany z argumentem będącym nazwą podkatalogu, do którego odwołuje się użytkownik. Oto przykładowa implementacja w języku sh:
#!/bin/sh echo "unixlab.cs.put.poznan.pl:/export/home/$1"
Skrypt umożliwia dostęp do katalogów domowych wszystkich użytkowników. Specjalnym zastosowaniem programów generujących zapisy konfiguracyjne jest równoważenie obciążenia serwerów. Zakładając konfigurację z poprzedniego punktu (podkatalog local), program konfiguracyjny mógłby zwracać naprzemiennie wskazania na serwery srv1 i srv2.
Dokumentacja
Strony pomocy systemowej: mount(8), nfs(5), autofs(5), autofs(8), automount(8), auto.master(5).
Zadania
- Udostępnij katalog do zapisu dla wszystkich użytkowników łącznie z użytkownikiem
root. - Skonfiguruj serwer NFS do pracy w trybie statycznego mapowania użytkownika ze stacji roboczej o identyfikatorze 1500 na użytkownika o tej samej nazwie i identyfikatorze 1600 po stronie serwera. Zastosuj mapowanie statyczne i dynamiczne.
- Udostępnij katalog w trybie WebNFS.
- Skonfiguruj oprogramowanie automontera tak, aby umożliwiało dołączanie systemów plików z napędów CD-ROM i zdalnego katalogu poprzez system plików NFS.
- Sprawdź możliwość zwiększania niezawodności dostępu do replikowanych danych poprzez odpowiednią konfigurację automontera.
