NFS i NIS

Rozdział 12. NFS i NIS

301

W tym rozdziale zajmiemy się sieciowym systemem plików (ang. Network File System - NFS). Stanowi on zbiór protokołów i produktów im towarzyszących, rozpowszech­nionych w sieciach opartych na TCP/IP, głównie w różnych odmianach LINIXa, choć nie tylko. Nierozerwalnie związane są z nim dwa inne protokoły - informacja siecio­wa NIS (ang. Network Information Service) i zdalne wykonywanie REX (ang. Remote Execution Service) - im również poświęcimy nieco uwagi.

Treść niniejszego rozdziału koncentruje się - z pewnymi wyjątkami - na systemie UNIX, chociaż wymienione protokoły są również dostępne na innych platformach sys­temowych; jakkolwiek koncepcje i zasady działania pozostają te same, to mogą wystą­pić różnice w szczegółach, głównie w nazwach plików.

m plików sieciowych

Pojawienie się systemów klient /serwer oraz przetwarzania rozproszonego stworzyło sy­tuację, gdzie niewielka, acz poręczna stacja robocza ~w rodzaju komputera PCK, korzy­sta z usług znacznie potężniejszego serwera. Zawiera on wi~kszość aplikacji i danych, konieczne jest więc opracowanie pewnych reguł ich wykorzystania. Co prawda progra­my telnet oraz rlogin umożliwiają dostęp do serwera i wielodostępną pracę na nim, lecz użytkownikom wcale nie o to chodzi - nie chcą oni rezygnować z funkcjonalności swoich pecetów (przez zredukowanie ich do roli terminali), oczekując raczej uczynienia plików serwera częścią dziedziny przetwarzania, w którym uczestniczą ich komputery lokalne. Temu zapotrzebowaniu wychodzi naprzeciw system plików sieciowych NFS, opracowany pierwotnie przez Sun Microsystems.

Firma Sun zaprojektowała swój system z myślą o umożliwieniu współpracy w ramach jednej sieci maszyn pochodzących od różnych producentów, różniących się platformą sprzętową i pracujących pod kontrolą różnych systemów operacyjnych. W tym celu do­

_.

302

TCP/IP

konała ona publikacji specyfikacji NFS, aby umożliwić producentom sprzętu i oprogra­mowania przystosowanie ich produktów do wymagań systemu. 1'o spowodowało, że NFS stał się standardem de facto - w całej pełni w systemie UNIX, w dużym stopniu w wielu innych systemach.

Nazwa NFS odnosi się zarówno do protokołu, jak i całej gamy produktów; owe produk­ty to nic innego, jak implementacja wielu protokołów związanych z NFS (szerzej na ten temat w sekcji Protokoly NFS~. Aby uniknąć nieporozumień, pod skrótem NFS będzie­

- my rozumieć konkretny protokół; jest to jedyny protokół całej rodziny NFS, który ma związek z dostępem do plików.z3

Historia NFS jest nierozerwalnie związana z systemem UNIX, gdyż stanowi on część Systemu V Release 4, co natychmiast implikuje jego ścisły związek z protokołem TCPI IP, stanowiącym podstawowy protokół komunikacyjny w sieciach UNIX. Jak można się spodziewać, za chwilę padnie nazwa programu-demona, który realizuje usługi NFS­istotnie, programem tym jest nf sd, uruchamiany podczas startu systemu. Dostęp do pli­ków za pośrednictwem NFS nie różni się od dostępu do plików lokalnych (oczywiście z wyjątkiem reguł wielodostępu), co czyni go (tj. protokół) bardzo atrakcyjnym.

Udostępnienie aplikacji mechanizmów NFS następuje w wyniku czynności zwanej mon­towaniem24 (ang. mounting); może zostać udostępniony cały system plików serwera lub jego wybrane katalogi; katalog maszyny-klienta, odzwierciedlający montowany katalog r.

secwera, nosi nazwępunktu montowania (ang. mountpoint).

Terminologia protokołu NFS określa mianem klienta maszynę, żądającą dostępu do sys­'' temu plików innej maszyny, zwanej serwerem. W systemie wielozadaniowym, maszyna I

może spełniać rolę zarówno serwera, jak i klienta, często nawet równocześnie. Oczywi­ście, wielodostęp wymaga istnienia pewnych reguł, ograniczających dostęp do plików, głównie ze względów bezpieczeństwa, jak równieź ze względu na szybkość pracy. Ty­

owa instalac a NFS składa si z wielu bezd sko ch stac i robocz ch, korz sta c ch p j ę Y wY J Y Y Ją Y z usług jednego lub kilku serwerów. Ponieważ typowym systemem operacyjnym stacji roboczych jest jednozadaniowy MS-DOS, mogą one występować jedynie w roli klien­tów. Nieco inna sytuacja zachodzi, gdy stacje robocze pracują pod kontrolą systemów wielozadaniowych, jak Windows NT czy OS/2: mogą one wtedy występować również

f; w roli serwerów, co nadaje całej sieci nieco inny charakter - jej maszyny potrafiąna- :' '..` wzajem udostępniać sobie swoje pliki. Rozwiązanie takie jest jednak do przyjęcia jedy­nie w niewielkich sieciach, gdyż jednoczesna obsługa wielu systemów plików znacząco wpływa na zwiększenie ruchu w sieci.

E~ z3 W dziedzinie systemów komputerowych od zarania ich historii często tak się zdarza, że wielo­

~i~ '~, składnikowy produkt otrzymuje nazwę (najpierw żargonową, następnie usankcjonowani ~i swego najważniejszego składnika: tak jest przecież z rodziną protokołów TCP/IP, tak jest też z j mechanizmem NFS - jak w starym dowcipie, zgodnie z którym pies policyjny składa się z

obroży, kagańca i psa wlaśc~we~o. ~waioy Ciy~e`W k ~powiW en panivę~ać o tym przy aalszel lekturze książki (przyp. tłum.)

I z4 Termin ten może wydawać się nieco dziwny - ma on genezę historyczną: w systemach kom­i'- puterowych typu mainframe, udostępnienie plików zawartych na zewnętrznym nośniku - naj­częściej taśmie magnetycznej lub dysku - wymagało jego fizycznego zamontowania na urządzeniu. Zmieniły się realia, termin pozostał (przyp. tłum.)

1 l;

,' r`'

NFS i NIS

sny

Szybkość przesyłania informacji odgrywa tutaj rolę pierwszorzędną, o czym oczywiście projektanci NFS nie mogli zapomnieć: założenia projektowe ustalają jego sprawność na 80 procent sprawności dostępu do lokalnego dysku twardego. Stawia to szczególnie wy­sokie wymagania architekturze sprzętowej serwerów i ich systemom operacyjnym.

Ponieważ NFS oparty jest na filozofii UNIXa, więc brak jest w nim wyszukanych metod ochrony danych. W związku z tym firma Sun opracowała wersję Secure NFS, oferującą szyfrowanie danych oraz autoryzację dostępu do plików.

j

Protoko~y NFS

Rodzina NFS składa się kilka protokołów, z których każdy nosi tą samą nazwę - NFS. Protokoły tej rodziny mają architekturę warstwową, podobnie do modelu OSI-RM. Do­kładnemu opisowi warstw poszczególnych protokołów rodziny NFS zostały poświęcone odrębne dokumenty RFC. Rysunek 12.1 przestawia warstwy protokołu NFS w kontek­ście warstw modelu OSI-RM.

Rysunek 12.1.

NF&, MOUNT, YP Wpl'SIW,y~7Y0i!~:JIL! YPBIND, NLM, REX NFS NFS XDR

RPC TCP lub UDP IP

Ethemet

WHRSTWY: Aplikacji

Prozontacji Sesji Transportowa Ł.~cza danych

Firyczna

Podobnie jak w modelu ISO, poszczególne warstwy są od siebie niezależne (przynaj­mniej w teorii), co oznacza, że wymiana danej warstw w~~.a~a ;~ayr;~ ~~~o

bez zni~any jej cech funkcjonalnych, istotnych dla warstw sąsiednich. W chwili obecnej nie istnieje żadna szerzej rozpowszechniona alternatywa dla warstw RPC i XDR, lecz istniejątakowe dla protokołów najwyższej warstwy.

Kod źródłowy protokołów RPC oraz XDR dostępny jest bezpłatnie w firmie Sun Microsystem.

tdafne wywo~anie procedury (RPC)

Protokół zdalnego wywołania procedury (ang. Remote Procedure Call - RPC) umiej­scowiony jest w warstwie sesji i spełnia rolę mechanizmu wymiany komunikatów dla wszystkich aplikacji korzystających z NFS. Na jego oprogramowanie składa się zbiór procedur, zapewniających dostęp aplikacji wysokiego poziomu do zasobów sieci; wy­woływanie tych procedur nie jest wcale bardziej skomplikowane niż wywoływanie pro­cedur lokalnych.

304 TCPIIP

P~otokó~ RPC zostal stworzony specjalnie na potrzeby NFS, lecz obecnie spoty~ kany jest jako członek innych rodzin protokołów. Jego zasady pozostaje jednak niezmienione.

"twórcy aplikacji mogątworzyć swe własne procedury RPC. Grupaprocedur nosi n. usługi (ang. service); każda usługa ma przyporządkowany unikalny numer i jest rea wena przez program-demon, noszący popularną nazwę serwera RPC (nie mylić z se rem jako konkretnym komputerem); w danej maszynie może działać równocześnie le serwerów RPC, z których każdy identyfikowany jest unikalnym numerem.

Proces zdalnego ~rty~tołansa procedury pokazano na rysunku 12.2. Oawolanie się pi klienta do zdalnej procedury spowoduje wygenerowanie żądania RPC pod adresem esera. Serwer, otrzymawszy żądanie, analizuje jego parametry, wykonuje żądanąpri durę i wysyła odpowiedź zwrotną odnośnie rezultatów tego wykonania. Przez cały czas proces klienta pozostaje bezczynny. Otrzymawszy odpowiedź, dokonuje on jej a lizy, by następnie kontynuować pracę. Cała opisana akcja odbywa się pod kontrolą cedur sterujących protokołu RPC, automatycznie dołączonych do aplikacji.

Rysunek 12.2. IaIENT SERWER

Zdalne wywolanie PmcBS "', pYOCedLIYy Nykonuje sio

2gdanie RPC Start RPC II

Proces Wykonanie zawieszony Procedury ,c.

~ .r

' Odpowisdf procesu Odpawiedt RPC ł

Kontynuacja i procesu h-.

~lt ' Komunikaty RPC przesyłane są przy użyciu zarówno UDP, jak i TCP (lub równowai~ I ~:

!,,,; nych protokołów o tej samej funkcjonalności). Zazwyczaj używany jest UDP, gdyż nie ' jest wymagane nawiązywanie połączenia, a samo przesłanie odbywa się szybciej. Jed~ nak użycie UDP wiąże się z tendencją do formowania dużych pakietów, co może stano wić problem dla niektórych procedur. Poza tym, jak dobrze wiesz, UDP nie gwarantuje

I ' dostarczenia komunikatu, co wymusza dodatkową kontrolę ze strony aplikacji końco~ '' esej, najczęściej za pomocąstopera retransmisji.

Zalety wykorzystania TCP zamiast UDP dotyczą nie tylko samej niezawodności, leci również możliwości tzw. żądań wsadowych (ang. balch requests). Podczas nawiązani go połączenia użytkownik może mianowicie przesłać całą serię żądań, bez oczekiwania na kolejne potwierdzenia. Może to czasem znacznie przyspieszyć pracę aplikacji.

~C~l, .

NFS i NIS

305

Nagłówek komunikatu protokołu RPC przedstawia rysunek 12.3. Komunikat ten może być żądaniem klienta lub stanowić odpowiedź z serwera. Wszystkie jego pola zakodo­wane są zgodnie z konwencją XDR (patrz jedna z kolejnych sekcji). Pole identyfikacji transakcji służy do wzajemnego przyporządkowania żądań i odpowiedzi. Pole Kierunek przesyłania, stanowi rozróżnienie pomiędzy żądaniem (=0) oraz odpowiedzią (=1). Ko­lejne cztery pola oznaczają odpowiednio wersję protokołu RPC, numer programu (usłu­gi), wersję programu oraz numer procedury.

Rysunek 12.3. Naglówek

i komunikatzr RPC

Nr identyfikacyjny traneakeji Wakafnik kierunku prualania

Numer wersji Numer programu Numer wersji

Numer procedury Intormac~a dla celów weryfikacp toisamości (maksimum 400 bajtów)

Autoryzacja (maksimum 400 bajtów)

Parametry wywołania procedury

Niektóre procedury mogą wymagać, na przykład ze względów bezpieczeństwa, wery­fikacji klienta, czemu poświęcone są dwa kolejne pola. Dokumenty RFC nie określają sposobu przeprowadzenia weryfikacji, pozostawiając ją w gestii wywoływanej procedu­ry, określają jedynie maksymalną wielkość każdego z tych pól na 400 bajtów. Istnieją obecnie cztery predefiniowane typy weryfikacji (podano zawartość drugiego pola):

• puste - brak weryfikacji, obydwa pola są puste;

• UNIX - weryfikacja w stylu UNIXa (identyfikator grupy i użytkownika); weryfikacja przeprowadzana jest przez NFS, pierwsze pole jest puste;

• Short - klient generuje sekwencję weryfikującą, która zwracana jest przez serwer (zazwyczaj jako odwołanie do poprzednich żądań RPC);

• DES -- informację weryfikującą stanowi zaszyfrowany zgodnie ze standar­dem DES (ang. Data Encryption Standard) znacznik czasu (ang. timestamp). Ten rodzaj weryfikacji jest wykorzystywany przez Secure NFS.

Jedynym wiarygodnym zabezpieczeniem jest ostatnie z wymienionych, pozostałe mogą zostać złamane przez średnio zdolnego hackera.

Każda usługa w ramach RPC posiada unikalny numer, jednoznacznie identyfikujący ją względem protokołu. Listę usług wraz z ich numerami oraz przyporządkowaniem im poszczególnych programów zawiera plik /etc/rpc. Oto przykład jego zawartości:

portmapper 100000 portmap sunrpc

rstat_svc 100001 rstatd rstat rup perfmeter rusersd 100002 rusers

nfs 100003 nfsprog

306 TCP/IP i

ypserv 100004 yprog

mountd 100005 mount showmount

ypbind 100007

walid 100008 rwali shutdown

yppasswdd 100009 yppasswd

etherstatd 100010 etherstat

rquotad 100011 rquotaprog quota rquota

sprayd 100012 spray

3270_mapper 100013

rje_mapper 100019

selection_svc 100015 selnsvc

database_svc 100016

rexd 100017 rex

alis 100018

sched 100019

llockmgr 100020

nlockmgr 100021

x25.inr 100022

statmon 100023

status 100029

bootparam 100026

ypupdated 100028 ypupdate

keyserv 100029 keyserver

ypxfrd 100069 ypxfr

pcnfsd 150001 pcnsfd

Numery przyporządkowane poszczególnym procesom-usługom zdefiniowane są w do- r kumencie RFC i powinny być identyczne we wszystkich impłementacjach RPC.

i Maper portów

POIIąCZC111C między idientem a serwerem przebiega w oparciu o numer portu TCP/IP. Aby uniknąć problemów z przydziałem portów opracowano maper portów (ang. port mapper) - bez niego zasób dostępnych portów wyczerpałby się już przy kilku aktyw­nych po%ezeW ac1~ RAC. Maper pocfów ~~esf cenha~nym procesem szeregU~ącym, kon­trolującym listę portów i ich wykorzystanie przez poszczególne programy. Sam maper używa portu o numerze 1 11.

Kiedy klient zamierza dokonać zdalnego wywołania pcocedwry, wysyka odpowiednie żądanie do serwem. Żądanie to, mające postać komunikatu rozpoczynającego się od na­główka pokazanego na rys. 12.3, zawiera numer wersji RPC, numer usługi oraz używa­ny protokół. Na jego podstawie maper przyporządkowuje mu właściwy port, który po­zostaje przydzielony aż do zakończenia pracy aplikacji.

Opisana procedura posiada dość poważną uciążliwość: klient musi znać adres serweta udostępniającego konkretną usługę - nie istnieje mechanizm poszukiwania określonej usługi wśród serwerów sieci. Jako że natura nie znosi próżni, nowo opracowywane sys~ temy plików nie posiadają już tej wady, nie dotyczy to jednak jeszcze NFS.

NFS i NIS 307

Zewnętrzna reprezentacja danych (XDR)

W rozdziale Telnet i FTP, przy opisywaniu telnetu, przedstawiłem aplikację TN3270, której zadaniem było pogodzenie dwóch komputerów używających niezgodnych kodów - ASCII i EBCDIC. To tylko jeden z przykładów niezgodności, wcale nie najistotniej­szy. Innym problemem jest hierarchia poszczególnych bajtów w słowie wielobajtowym: procesory Intela stosują konwencję, zgodnie z którą bajt o najniższym adresie jest naj­mniej znaczący w słowie (konwencja little endian), podczas gdy np. procesory Motorołi czy mainframe IBM, uważają bajt o nąjniższym adresie za najbardziej znaczący (kon­wencja big endian). Jeszcze inne różnice biorą się z różnicy w formacie poszczególnych typów danych - większość maszyn używa kodu uzupełnień do dwóch (U2), ale istnieją architektury (na przykład wszystkie wersje CRAYów), wykorzystujące kod uzupeł­nieniowy do 1.

Aby ujednolicić format danych przesyłanych pomiędzy różnymi maszynami, opracowa­no konwencję XDR (ang. Exter~ral Data Representation). Polega ona na tym, że dane, przed opuszczeniem komputera, zostają przekształcone do postaci zgodnej ze standar­dem XDR (o nim za chwilę); algorytm takiego przekształcenia jest oczywiście różny dla różnych architektur sprzętowych. Po dotarciu do komputera docelowego, są następnie przekształcane na format właściwy jego architekturze.

Tak więc standard XDR, stanowiący coś w rodzaju hipotetycznej, uniwersalnej archi­tektury, posiada następujące cechy:

• obowiązuje konwencja big endian, co oznacza, że bajt o najmniejszym adre­sie jest najbardziej znaczący;

• dane całkowite zapisywane sąw kodzie uzupełnień do dwóch (U2);

• istnieją dwa typy danych całkowitych: 4-bajtowry (long integer~) i 8-bajtowy (hyperinteger~);

• liczby zmiennoprzecinkowe zapisywane są w 32-bitowym formacie IEEE:zS I-bitowy znak, 8-bitowy wykładnik i 23-bitowa mantysa.

Istnieje specjalny język zwany XDR o składni zbliżonej do języka C, ułatwiający ope­rowanie danymi w opisanym formacie. Można go wykorzystać łącznic z wieloma inny­mijęzykami.

NFS

Protokół NFS jest zbudowany jako zbiór procedur RPC. Nie jest on protokołem w kla­sycznym tego słowa znaczeniu, nie wykonuje bowiem niczego w rodzaju negocjacji pomiędzy maszynami, lecz stanowi raczej standard dostępu do plików sieciowych. Wy­korzystuje on protokół transportowy UDP. Jako numer portu została mu przypisana ­

zs Dla programistów Borland Pascala: jest to odpowiednik typu Single (przyp. tłum.)

308

TCP/IP

celowo - bezsensowna wartość 2049. Wartość ta nie powinna zostać nigdy użyta, nieważ przydziałem numerów portów dla zdalnie wywoływanych procedur zajmuje opisany przed chwilą maper portów.

NFS został pomyślany jako protokół bezstanowy (ang. stateless) co oznacza, że nie maga on utrzymywania tablicy stanów w wykorzystującej go maszynie. Jest on rów odporny na zakłócenia (ang. robust), np. załamanie się połączenia lub awaria wewr maszyny, które to sytuacje potrafi właściwie obsłużyć.

Systematyczny opis protokołu NFS wymagałby użycia języka XDR, co wykracza ramy niniejszej książki. Poprzestaniemy więc na ogólnym opisie.

NFS definiuje szereg stałych (ang. constants) określających wiele jego parametrów, np. maksymalna długość ścieżki dostępu, maksymalny rozmiar komunikatu-żąda odczytu lub zapisu, rozmiar wskaźnika NFS i in. Nazywane są one stałymi protok yj i powinny być identyczne we wszystkich implementacjach NFS.

Oprócz stałych definiowane są struktury danych i rekordy, w terminologii NFS zwane - nieco na wyrost - obiektami, a stanowiące agregaty pól różnego typu.

Kilka obiektów NFS definiuje wielkości związane z plikami. Podstawowym obiektem identyfikującym plik jest jego uchwyt (ang. handle), mający rozmiar 32 bitów. Znacze~ nie poszczególnych bitów jest zrozumiałe dla serwera i nieistotne dla użytkownika. Typ opisujący uchwyt pliku nosi nazwę thandle.

Innym obiektem związanym z plikami jest obiekt typu ftype, opisujący typ pliku. Wy~ różnia się m.in: plik regularny (dowolny plik danych), katalog (ang. directory), łącznik~b (ang. Brak), plik blokowy i plik znakowy.

Atrybuty pliku związane są z typem fattr. Definiuje on prawa dostępu do pliku, liczbę dostępów, właściciela i wiele innych parametrów. Parametry te są istotne w przypadku próby odczytu lub zapisu do pliku.

! Obiekty danych mogą być organizowane w bardziej złożone struktury, zwane uniami

(ang. discriminating union).z' Unia rozpoczyna się od etykiety, która określa sposób in~

i,

r„ terpretacJr JeJ pozostałe) częscr; odzwrercredla to oczywrsty fakt, ze rozne rodzaJe rnfor~

f~~ mac_ji posiadają różnorodne elementy i stąd niejednolity format.

i

yi Operacje na plikach wykonywane są za pomocą poniższych procedur NFS (tabela 12.1),

Jeżeli przypadkowo jesteś programistą, zauważyłeś zapewne brak w powyższym zesta~

wie funkcji otwarcia i zamknięcia pliku. Jest to związane z tym, że NFS jest protokołem,

bezstanowym - operacje otwierania i zamykania pliku wykonuje jego część lokalna

!', w stacji roboczej, co umożliwia lepszą kontrolę sytuacji w przypadku błędu lub zerwa

,I

nia połączenia.

' Z~Odpowiadający skrótowi (ang..shortcut) w Windows 95 (przyp. tłum.)

.; z~Odpowiadające uniom języka C lub rekordom z wariantami Borland Pascala (przyp. tłum.)

NFS i NIS

gna

Tabela i2.1. Proceduryprotokolu NFS

Nazwa procedury Zrzeczenie Null Procedura pusta

Fetch file attributes Pobiera atrybutypJiku

Set file attruibutes Ustawia atrybuty pliku

Read file system root Obecnie już nie używana

Lookup filename Udostępnia uchwyt związany z plikiem

o zadanej nazwie

Read contents of link Udostępnia parametry łącznik do pliku

Read file Odczytuje porcję danych zpliku

write to cache Nie używana

Create file Tworzy nowy plik i udostępnia jego uchwyt

Delete file Usuwa plik

Rename file Zmienia nazwę pliku

Generate link Tworzy łącznik do pliku

Create directory Tworzy nowy katalog

Delete directory Usuwa katalog

Read directory Pobiera listę plików katalogu

Read file system attribUtes Udostępń~a informację o systemie plików

Protokół montowania

Jak już wcześniej wspominałem, korzystanie przez stację roboczą z usług NFS milsi byĆ poprzedzone procesem montowania. Nie zajmuje się tym właściwy protokół NFS, lecz odrębny protokół montowania. Wykorzystuje on na swoje potrzeby protokóle txanspor­towy UDP.

Proces montowania wiąże się z przydzieleniem aplikacji tzw. obszaru NFS, obejmujące­go jeden lub więcej katalogów. Obszar taki jest identyfikowany za pomocą tzw. uchwy­tu montowania (ang. mount handle), analogicznego do uchwytu pliku. Procesem monto­wania zarządza programdemon mountd; to właśnie jego zmartwieniem jest to, które ma­szyny i które aplikacje ukrywają się pod zwracanym uchwytem. Pozwala mu to na swo­bodną modyfikację swoich tablic roboczych, bez wpływu na aplikację (która nie ma do nich dostępu), lecz stanowi pewien kłopot w przypadku niespodziewanego zakończenia pracy (załamania); można sobie z tym poradzić wykorzystując polecenie oMNTALL (zo­bacz tabela poniżej), anulujące wszystkie istniejące montowania w stosunku do danej stacj i-kl ienta.

310 TCPIIP 1 ~ Protokół montowania aktywnyjest tylko podczas nawiazywania połaczenia klienta

z serwerem; po nawiazaniu połaczenia, dołaczony (zamontowany) system plików w znajduje się całkowicie pod kontrola procedur NFS, a odwołanie do niego na­stępuje z wykorzystaniem uchwytu montowania.

Procedury protokołu montowania przedstawione są w tabeli 12.2.

Tabela 12.2,

Procedury protokole montowania

Nazwa Znaczenie

NULL Nic nie rób

MNT Zamontuj system plików, zwracąjąc uchwyt montowania i nazwę

;; .

systemu

UMNT Anuluj montowanie związane z konkretnym uchwytem

UMNTALL Anuluj wszystkie montowania w stosunku do danego klienta

y, EXPORT Udostępnij listę wyeksportowanych systemów plików

DUMP Udostępnij listę wszystkich systemów plików aktualnie

zamontowanych dla danego klienta

Niektóre wersje NFS udostępniająmożliwość automatycznego mornowania (ang. auto m0u?'lt~ - System plikÓw montowany jest tylko w razie potrzeby', upraszcza to admini~ strowanie systemem i często zmniejsza obciążenie jego zasobów. Proces ten jest całka wicie niewidoczny dla użytkownika. Nie jest on częścią protokołu NFS, lecz stanowi odrębną aplikację wykorzystującą jego procedury i komunikującą się z właściwą aplika cją za pomocą łączników symbolicznych (ang. links).

Blokowanie plików

Administrator sieci może okazjonalnie zabronić dostępu do wybranych plików czy kata logów, głównie w celu uzyskania wyłączności dostępu na czas zmiany wersji oprogra~ mowania czy wykonywania pewnych czynności diagnostycznych. Ten sam efekt można osiągnąć wykorzystując standardowe możliwości regulowania uprawnień dostępu da plików (ang. per~missions) systemu UNIX. Można jednak oczekiwać, że możliwdści of~ rowane w tym względzie przez protokół NFS są bardziej wyrafinowane; bowiem nawd ba~cdzo prosie s~s~em~ ,'~a1~MS ~OS,~doS~ę~~civa~~swó~m ap\~kać~om mecha~i~zmy bat

dziej subtelne od wyżej opisanego. Istotnie, mechanizm blokowania NFS funkcjon~ przy wsparciu ze strony wielu protokołów i programów-demonów (na przykład w ternie pochodzącym z Sun Microsystems, demonem tym jest proces lockd). Wszys działania związane z blokowaniem plików odbywają się pod jego kontrolą, z wyko staniem protokołu zwanego systemowym zarządcą blokowania, w skrócie KLM Kernel Lock Manager). j

Gdy aplikacja wywołuje procedurę blokowania, proces lockd sprawdza, czy doty ono „jego" maszyny (co wymaga uruchomienia lokalnego zadania), czy też wiąże

NFS i NIS

Z11

z koniecznością przekazania komunikatu (za pomocą UDP) procesowi lockd działają­temu w innej maszynie. Komunikacją pomiędzy różnymi procesami lockd zarządza protokół, zwany sieciowym zarządcą blokowania, w skrócie NLMZB (ang. Net~a~>rk Lock Manager). Istnie je wiele wersji KI,M i NUM dla có'rnych p~a~form S~pr2e~~,owych.

Z mechanizmem blokowania plików związany jest nierozerwalnie proces statd (moni­tor stanu- ang. statz~s monitor), kontrolujący bieżący stan blokad i decydujący o przy­jęciu lub odrzuceniu kolejnego żądania blokowania.

System blokowania plików posiada jeszcze kilka dodatkowych możliwości, jak np. sto­pery zabezpieczające przed nieskończenie długim blokowaniem (np. w przypadku zała­mania się aplikacji użytkownika lub jej błędnej pracy), wczesne wykrywanie możliwo­ści tzw. zakleszczenia (ang. deadlock) itd. Wszystkie one opisane sąw odnośnym doku­mencie RFC.

Zdalne wykonywanie poleceń

Usługa zdalnego wykonywania (ang. Remote Executioh Service), polega na wykorzy­staniu zasobów odległego komputera bez konieczności wykorzystywania programów lo­gujących: telnet, rlogin czy rsh. Jest realizowana za pomocą działającego na ser­werze programu-demona rexd, wykorzystującego mechanizmy NFS; w warunkach sys­temu wielozadaniowego, każda maszyna może być potencjalnie klientem lub serwerem (nawet jednocześnie), możliwe jest więc współdziałanie wielu procesów rexd w sieci.

Zdalne wykonywanie umożliwia wykorzystanie przez stacje robocze-klientów aplikacji obecnych jedynie na serwerze; aplikacje te mogą przy tym wykorzystywać wszystkie zasoby stacji roboczych, łącznie z ich zmiennymi środowiskowymi.

Wykonanie aplikacji lub polecenia na odległej maszynie następuje w wyniku wydania polecenia on, specyfikującego nazwę zdalnej maszyny oraz polecenie do wykonania. Oto przykład:

$ hostname tpci_hpws4 $ cat filel

This is the file "filel" on "tpci_hpws4". This is the client machine.

$ on merlin hostname merlin

$ rsh merlin cat filel cat: cannot open filel $ on merlin cat filel

This is the file "filel" on "tpci_hpws9". This is the client machine.

'R Przypadkowa zbieżność skrótów z modułami ładowalnymi Novella (Network Load Module,r) (przyp. tłum.)

312

TCP/IP

j Przykład ilustruje wykonanie polecenia cat na zdalnej maszynie, w stosunku do pli filer znajdującego się w maszynie lokalnej (na jednym z jej dysków). Za pierwsz~ razem polecenie wykonane zostało na maszynie lokalnej, toteż jego związek z lokalu; plikiem fi1e1 jest oczywisty. Kolejne wykonanie odbywa się w kontekście maszt' zdalnej, za sprawą rsh; globalna zmiana kontekstu oznacza, że i plik filer razpat want' jest w tym kontekście, czyli - mówiąc prosto - poszukiwany na zdalnej mas; nie. Ponieważ nie zawiera on pliku o tęj nazwie, polecenie sygnalizuje ten fakt jako bl Ostatnie trzecie wywołanie realizuje dokładnie to, o co chodziło: z maszyny zdalnej] pobierana jedynie aplikacja cat, natomiast jest ona wykonywana w kontekście mas; ny lokalnej - jej komunikaty nie pozostawiają co do tego wątpliwości.

rusers i spray

Przykładem aplikacji korzystających z usług NFS są aplikacje narzędziowe wymienione! w tytule. Działanie pierwszej z nich - spray -podobne jest do znanego ping i pole. ga na testowaniu połączenia z serwerem. Testowanie to polega na wysyłaniu komunika­tów wsadowych i oczekiwaniu na nie odpowiedzi. Jedną z opcji programu jest opcja-c;! specyfikująca liczbę wysyłanych datagramów. Oto przykład:

$ spray -c200 beast

sending 200 packets of length 86 to beast... in 18.3 seconds elapsed time,

4 packets (2.00) dropped by beast Sent: 10 packets/sec, 912 bytes/sec Recd: 9 packets/sec, 862 bytes/sec

i Drugi z wymienionych programów- rusers -podobny jest do polecenia who, udo­stępniając listę użytkowników zalogowanych na zdalnych maszynach:

$ rusers

beast.tpci.com tparker bsmallwood rmaclean merlin.tpci.com ychow etreijs tgrace

i' tpci_hpws3.tpci.com tparker sysadm tpci hpws9.tpci.com pepper

~Configurowanie NF~

Mechanizm NFS jest bardzo chętnie wykorzystywany przez użytkowników, lecz ich en­tuzjazm znacznie słabnie, jeśli chodzi o jego szczegóły konfiguracyjne; niczym diabel od święconej wody, uciekają oni wręcz od tego problemu, spychając wszystko na barki biednego administratora. Może to i dobrze, wszak konfigurowanie NFS postrzeganejest przez użytkowników jako proces pracochłonny, złożony i wymagający sporej wiedzy, a to wymaga już zaangażowania specjalisty - ale czy taki punkt widzenia nie jest przy­padkiem przesadzony? Można się o to spierać w nieskończoność, więc może niech su­biektywne sądy ustąpią teraz miejsca realnym faktom: w kolejnych punktach zostaną

NFS i NIS

313

przedstawione podstawy konfigurowania NFS w środowisku dwóch różnych systemów operacyjnych: na serwerze SCO UNIX oraz stacji roboczej-kliencie pracującej pod kon­trolą Windows for Workgroups. To, czy temat ten jest rzeczywiście aż tak nieprzystęp­ny dla szeregowego użytkownika, niech pozostanie kwestią subiektywnej oceny.

Konfigurowanie serwera NFS w środowisku SCO UNIX

Ponieważ trzonem protokołu NFS są zdalne wywołania procedur, więc pierwszym kro­kiem jego konfigurowania jest sprawdzenie obecności usług RPC.

W systemie UNIX możesz to wykonać za pomocą polecenia:

rpcinfo -p

wyświetlającego listę serwerów RPC, uruchomionych na Twoim komputerze; lista ta składa się z czterech sekcji rpcbind (po dwie dla protokołów UDP i TCP) oraz sekcji pcnfsd, związanej właśnie z demonem NFS.

W systemie SCO UNIX uruchomienie i zatrzymanie t~FS wykonywane jest za pomocą skryptu /etc/nfs. Skrypt ten może zostać dołączony do procedur startowych, co spo­woduje, że NFS będzie uruchamiany automatycznie podczas startu systemu (lista dołą­czonych w ten sposób skryptów znajduje się w pliku /etc/rc2 . d/Sname). ArlaloglcZ­nie, aby wymusić zamknięcie NFS przed zakończeniem pracy systemu UNIX, należy dołączyć nazwę skryptu /etc/nfs do pliku /etc/rco.d/Kname (nazwy te mogą się nieco różnić w poszczególnych implementacjach UNIXa).

Polecenie uruchamiające pracę systemu NFS ma postać:

/etc/nfs start

Potwierdzeniem rozpoczęcia pracy NFS jest wyświetlenie dwóch komunikatów: Starting NFS services: exportfs mountd nfsd pcnfsd biod(x4) Starting NLM services: ststd lockd

wyświetlających nazwy uruchamianych demonów.

W równie nieskomplikowany sposób można zakończyć pracę systemu:

$ /etc/nfs stop

NFS shutdown: (NFS Shutdown Complete]

Plik /etc/exports związany jest nierozerwalnie z usługami NFS w Systemie SCO UNIX. Zawiera on listę wszystkich katalogów, które zostają przeznaczone do udostęp­nienia ich klientom (wg. terminologii NFS - wyeksportowane). Każda linia tego pliku ma postać:

nazwa-katalogu [ -opcja, -opcja, ...... ]

I '1! i '' 314 TCP/IP

I Poszczególne opcje określają dokładniej sposób udostępnienia katalogu wymieniom ,`;! na początku linii. Dostępne są następujące wartości opcji:

• ro: Eksportowany katalog przeznaczony jest tylko do odczytu (read only); " domyślnie dozwolony jest zarówno odczyt jak i zapis;

`' • rw=nazwy maszyn: Katalog zostanie udostępniony jak tzw. read mostly, co oznacza, że dla większości maszyn będzie on katalogiem tylko do odczytu, ` jedynie wymienione maszyny będą miały prawo zapisu;

• anonsidentyfikator użytkownika: Jeżeli źródłem żądania jest niema­ny użytkownik, to należy użyć profilu (własności i uprawnień) wymienione­go użytkownika;

• root=nazwy maszyn: Udostępnia katalog dla użytkownika root na wybra­nych maszynach;

• access=id_klienta: Udostępnia katalog wszystkim wymienionym klien­tom; pod określeniem id klienta może ukrywać się nazwa hosta lub grupy s~ ­

użytkowników.

A oto konkretny przykład (znak # oznacza początek komentarza):

/usr/stuff -ro # ogólnie dostępny jako read only /usr -access=physics # dostępny dla grupy physics /usr/public # ogólnie dost~pny bez ograniczeń

Interpretacjązawartości pliku /ext/exports zajmuje się program exportfs. Wyko­nuje on po prostu czynność tzw. eksportowania, polegającą na odzwierciedleniu zawar­tych tam zapisów w wewnętrznych obszarach roboczych NFS. Zazwyczaj tworzonyjest pomocniczy plik o nazwie /etclxtab; nie wolno go usuwać, gdyż spowodowałobyto całkowitą dezorganizację systemu NFS.

' W razie wprowadzenia zmian do pliku /etc/exports (lub po przypadkowym usunię­ciu pliku lete/xtab) należy ponownie uruchomić program exportfs, aby zmianyte stały się widoczne dla NFS.

Niektóre wersje UNIXa stosują inne podejście do eksportu katalogów: rolę poszczegól­nych linii (nieistniejącego) pliku /etclexports pełniąkolejne polecenia share o na­stępującęj postaci:

` share -F nfs -o opcje -d opis ścieżka

Przełącznik -F wskazuje, źe wymieniony plik Vub katalog staje się częścią systemu pli­ków NFS. Opcje występujące po przełączniku -o są identyczne jak w przypadku pliku letc/exports. Parametr opis jest słownym opisem udostępnianego pliku lub katalo­gu. Przykładowe polecenie share może wyglądać następująco:

share -F nfs -d "Serwer public directory" lusr/public

NFS i NIS 315

Opcje mogą być kombinowane, na przykład polecenie:

share -F nfs -o ro=artemis,anon=200 -d "Book material" /usr/tparker/book zezwala systemowi NFS na udostępnienie katalogu /usr/tparker/book, opisanego jako Book material, dostępnego dla wszystkich maszyn do odczytu i zapisu z wyjąt­kiem maszyny artemis, która posiada jedynie prawo jego odczytu. Anonimowy użyt­kownik równoważny jest użytkownikowi o identyfikatorze 200. Polecenie share bez parametrów powoduje wyświetlenie wszystkich eksportowanych katalogów.

Konfigurowanie klienta NFS w środowisku SCO UNIX

Wyeksportowane katalogi serwera mogą być następnie zamontowane w maszynie-klien­cie. Montowanie katalogu serwera polega na przyporządkowaniu go do (pustego) katalo­gu klienta; przyporządkowanie katalogów i inne parametry montowania stanowią skład­nię polecenia mount:

mount -F nfs -o opcje maszyna:system plików punkt montowania

Przełącżnik -F oznacza, że montowany system plików jest systemem NFS, natomiast fraza maszyna: system_plików punkt_montowania specyfikuje przyporządkowa­nie katalogów, na przykład w wyniku polecenia:

mount -F nfs artemis:usr/public /usr/artemis

lokalny katalog /usr/artemis zostaje utożsamiony z katalogiem /usr/public na zdalnej maszynie artemis, innymi słowy - wszystkie lokalne odwołania do katalogu /usr/artemis będąca rzeczywistości odwołaniami do katalogu /usr/public na ma­szynie artemis.

Opcje następujące po przełączniku -o mająznaczenie następujące:

• rw: Zamontuj katalog do odczytu i zapisu; • ro: Zamontuj katalog tylko do odczytu;

tirrrao=x: Poddaj się, jeżeli montowanie nW dojdzie do skutku w elągu x/10 sekund;

• retry=x: W przypadku nieudanego montowania ponów próbę najwyżej X razy;

• soft: Zrezygnuj z montowania w wypadku braku potwierdzenia z serwem; • bard: Nie rezygnuj z montowania pomimo braku potwierdzenia z serwem; • intr: Pozwól na przerwanie montowania za pomocą klawiatury.

Opcje mogą być grupowane, podobnie jak w poleceniu share, na przykład: mount -F nfs -o soft,ro artemis:usr/public /usr/artemis

316 TCP/IP

Konfigurowanie NFS w środowisku Windows

Większość produktów implementujących protokół TCP/IP w Windows 3.x, Windows for Workgroups, Windows 95 i Windows NT zawiera również sieciowy system plików NFS. Nie inaczej jest z naszym dobrym znajomym - Chameleonem NFS; wykorzystu­jąca go maszyna może pełnić rolę zarówno serwera, jak i klienta NFS.

s

Poszczególne implementac,je NFS w środowisku Windows różnią się znacznie zakresem oferowanych usług - wiele z nich nie realizuje na przykład funkcji serwem. Sam pro­ces instalacji i konfigurowania też jest w różnym stopniu skomplikowany - od bardzo łatwych do bardzo złożonych; ma to zresztą związek z zakresem spełnianych funkcji.

Dla celów prezentacji NFS wybrałem pakiet Chameleon pracujący w środowisku Win­dows 3.1 1. Jego funkcjonowanie oparte jest na programie zwanym Portmapper, kon­trolującym listę udostępnianych usług sieciowych, w tym NFS; program ten uruchamia­ny jest automatycznie przy starcie Windows (w większości instalacji).

Ustawienia Chameleona zapamiętywane są w pliku WIN.INI; umożliwia to automatycz­ne zamontowanie żądanych napędów dyskowychz9 podczas jego startu. Parametry doty­czące pracy serwem mogą być regulowane za pomocą ikony (a właściwie reprezentowa­i

nogo przez niąprogramu) NFS w grupie NetManage Menedżera Programów; wyjątkiem jest konfiguracja drukarek sieciowych, ustalana tradycyjnie za pomocą Panelu Sterowa­nia. Parametry związane z pracą Chameleona jako klienta, regulowane są przy pomocy Panelu Sterowania lub Menedżera Plików ten ostatni służy do montowania i rozmonto­wywania napędów sieciowych, pozostałe dostępne sąwłaśnie w Panelu Sterowania.

Po zainstalowaniu Chameleona możliwe jest zamontowanie napędu sieciowego; polega ono na odwzorowaniu nazwy zdalnego katalogu w oznaczenie lokalnego napędu; odtąd wszystkie odwołania do tego napędu będą w rzeczywistości odwołaniami do zdalnego katalogu.'" Aby je zrealizować wybierz opcję Podłącz dysk sieciowy z menu Dysk Me­nedżera Plików. Spowoduje to wyświetlenie okna dialogowego pokazanego na rys. 12.4; elementami tego dialogu są: nazwa zdalnej maszyny oraz jej montowany katalog. Wy­brane oznaczenie dysku musi być różne od dysków fizycznie istniejących w systemie.

Rysunek 12.4. Montowanie zdalnego katalogu w Charneleonie NFS

Mem l:roa~ectiun _.~_....

~etne~k Path: ~p- ~ C~lusr Dirve: ,Ń .~.~.........._.._ __3 Paxag~d: _ ~......'..._.._ F~tvloue_~

Cw~eeR DriYe Cneaeacihma: rp wy t.,. W ..

'Odmiennie niż w systemie UNIX, punktami montowania w środowisku Windows są tzw. ma­powane napędy dyskowe, nie katalogi (przyp. tłum.)

3°Identyczne możliwości zapewnia polecenie MAP sieci Novell oraz polecenie SUBST systemu MS-DOS w stosunku do napędów lokalnych (przyp. tłum.)

NFS i NIS

317

Przycisk _srowse umożliwi Ci zorientowanie się w zakresie istniejących maszyn oraz w zakresie systemów plików udostępnianych na każdej z nich. Za pomocą dwóch roz­wijalnych list (porównaj rysunek 12.5) możesz odczytać parametry interesującego Cię systemu plików (np, uprawnienia do odczytu/zapisu itd).

Rysunek 12.5.

°rzeglądanie a~c ~,~ ~l lostępnych ~~„~ca~ systemów plików

i•~`"t~t-..

Kliknięcie na przycisk oK spowoduje wyświetlenie propozycji zamontowania wybrane­go systemu plików - możesz przy tym zmienić oznaczenie mapowanego dysku (rysu­nek 12.6). Aby anulować montowanie wybranego systemu plików, kliknij na przycisk _nisconnect w oknie z rysunku 12.4. Ikona napędu, stanowiącego punkt montowania, powinna zniknąć z Menedżera Plików.

Rysunek 12.6. Prop~Zycja aamontowania wybranego systemu plików

New Cone~r.tiru,

jieMark PaRh: ~tpćt;.!^_._..-._..-..y...' .._ Dyiver. K:.

.._ ­r..~xara:

Cwrent Drirp t:onnectionsv

~la6e ~;ąnneL1­

cy.•nus ~ey,._SĄ ~

tłelp

ie katalogów w środowisku Windows

Chameleon umożliwia zdefiniowanie (jako funkcję serwem) uprawnień do współdzie­lenia przez poszczególnych użytkowników sieciowych dysków i katalogów; ewentualny brak takich definicji czyni je ogólnodostępnymi.

Definiowanie dostępu do dysków i katalogów odbywa się w oknie przedstawionym na rysunku 12.7. Aby je wyświetlić, kliknij ikonę NFS w grupie NetManage, potem w wy­świetlonym oknie głównym NFS wybierz opcję vsers. Wpisując nazwę użytkownika, jego hasło (jeżeli jest wymagane), jego identyfikator i identyfikator grupy, a następnie klikając na przycisk Add, spowodujesz dodanie nowej pozycji do listy (rys. 12.8).

12.7.

(puste)

318 TCP/IP

Rysunek 12.8. Dwaj nowi użytkownicy serwery

Kliknięcie na przycisk save spowoduje zapisanie zmian na dysku; zmiany nie zapisane ważne są jedynie do końca sesji Chameleona.

i#i

Po zdefiniowaniu użytkowników serwery należy teraz definiować prawa dostępu do po­szczególnych systemów plików.

Kliknij na opcję Exports w głównym oknie NFS - spowoduje to wyświetlenie okna pokazanego na rysunku 12.9. Z tego okna możesz wybierać poszczególne dyski i kata logi, w stosunku do których chcesz ustalić uprawniania dostępu. Kliknięcie na przycisk _Add spowoduje dodanie podświetlonego elementu listy w lewej części okna do listy Ex~ poru w jego prawej części. Ustalenie konkretnych uprawnień następuje w wyniku klik­nięcia na przycisk Access.

R ~

n

k 12

9

.

ysu

e

.

Definiowanie praw I ns^~«l

dostępu do dysków ~ _._ -_ . ~ -___. _____

i katalogów ~ i ,

serwery

~.,..bz~ 1 ;,~_*n~~~

~:

3

.

! ; ~,~., _.

,

t_..~~...t

~~

~

l; e ~ --

~ ~~ i

__ _____-

Kiedy tylko uprawnienia zostaną przypisane, poszczególne katalogi stają się dla użytkowników serwery. Opcjonalnie użytkownik może zostać poproszony o hasła, jeżeli reguły dostępu tak stanowią.

Informacja sieciowa (NIS)

W dużych sieciach, użytkownicy często logujący się na różnych maszynach, musząm każdej z nich posiadać odrębne konta, których częścią są m.in. hasła. Łatwo sobie wy~ obrazić, że może to być czasami denerwujące, zwłaszcza w przypadku okresowej zmia: ny haseł, wymuszanej przez system IINIX. Utrzymanie zgodności haseł we wszystkicjt maszynach - jakkolwiek w końcu możliwe - zaczyna być coraz bardziej uciążliwe, ai w końcu w kieszeni użytkownika pojawia się notatnik z listą różnych haseł dla - być może kilkudziesięciu-różnych maszyn sieci.

NFS i NIS 319

Chociaż skala opisanego zjawiska zależy głównie od staranności użytkowników, to jed­nak stanowi ono czynnik niepożądany, bo wymagający dodatkowej fatygi.

Lekarstwo na opisaną bolączkę stanowić więc może jakiś scentralizowany system kon­troli uprawnień; istotnie, w tym miejscu chcę takowy przedstawić.

System Yellow Pages, bo o nim mowa, jest aplikacją bazującą na zdalnym wywoływa­niu procedur (RPC). Ze względów podyktowanych prawami autorskimi, jego kolejna wersja, w której wyeliminowano błędy wersji pierwotnej, występuje pod zmienioną na­zwą Network Information Service (NIS). W użyciu są obydwie wersje, z przewagą wer­sji pierwszej, a piętno pierwotnej nazwy i tak widoczne jest w wersji poprawionej, w po­staci dwóch literek yp, stanowiących początek wielu programów i katalogów. Obydwie nazwy często funkcjonują jako synonimy; w tej książce będę konsekwentnie używał na­zwy nowszej (NIS).

Działanie systemu NIS opiera się na szeregu serwerów, podzielonych na dwie kategorie: pierwszą z nich stanowią serwery wiodące (ang. NIS master~s lub ypmasters), drugą zaś serwery podporządkowane (ang. NIS Slnves lub ypslaves). Te ostatnie wspomagają pracę serwera wiodącego, do którego sąprzyporządkowane, a w razie jego awarii przej­mują_jego funkcje. Usługi oferowane przez protokół NIS zrealizowane zostały z wyko­rzystaniem mechanizmu zdanego wywoływania procedur (RPC) i obejmują m.in. poszu­ki•L~anie serwerów NIS, dostęp do plików użytkowników, funkcje administracyjne itp. W roli protokołów transportowych wykorzystywane sąw równym stopniu TCP i UDP.

Z funkcjonowaniem serwerów NIS związany jest podział sieci na mniejsze obszary, zwa­ne domenami (ang. domains); każda domena zarządzana jest przez osobny serwer wio­dący oraz kilka serwerów podporządkowanych. Domeny NIS nie powinny być mylone z domenami DNS: są one koncepcyjnie czymś zupełnie różnym, paradoksalnie jednak, w przeważającej większości przypadków, podział sieci na domeny DNS jest identyczny z jej podziałem na domeny NIS.

Drugim stopniem podziału sieci (w kategoriach usług NIS), jest podział domeny na kil­ka tzw. map (ang. maps). Mapy służą do zróżnicowania uprawnień dla poszczególnych grup użytkowników, korzystających z tego samego serwem wiodącego. Fizyczna postać map jest identyczna ze strukturą zbioru, zawierającego konta użytkowników (typowo /etc/passwd) - są to rekordy ASCII dodatkowo poindeksowane według pola klu­ezowego (ang. index key field, którym jest najczęściej nazwa użytkownika.

Istnienie tak wspaniałego mechanizmu jak NIS w niczym nie umniejsza roli lokal­nych mechanizmów kontroli dostępu. Administrator sieci musi posiadać dostęp do wszystkich ważniejszych plików sieciowych także przy braku NIS (bo np. jeden z jego serwerów uległ awarii). Ponadto należy liczyć się z tym, że usunięcie awa­rii może trochę potrwać, a użytkownicy muszą jednak pracować, godząc się co najwyżej na przejściowe (miejmy nadzieję) obniżenie komfortu pracy; administra­tor powinien więc stworzyć jednolitą postać plików passwd (lub równoważnych) przynajmniej dla bardziej aktywnych użytkowników na wszystkich maszynach, z których moga potencjalnie korzystać.

320 TCPIIP Usługi protokołu NIS nie ograniczają się tylko do użytkowników systemu. Scentralizo­wana może zostać na przykład lista maszyn systemu (w systemie UNIX zawarta w pliku I etc I hostsy, pozy dok~czeW nowej maszyny do sieci, czy zmianie nazw istniejących maszyn, popzawki musząbyć dokonane tylko w jednym miejscu. Innąużytecznąfunk­cją jest (scentralizowane) nadawanie aliasów użytkownikom.

j , Poza wspomnianymi udogodnieniami, istnienie protokołu NIS nie powoduje dla nich żadnych dodatkowych konsekwencji; jedynym użytecznym poleceniem jest poleceni yppasswd, umożliwiające użytkownikowi zmianę jego hasła. Mechanizmy NIS mus być natomiast uwzględnione przez programistów tworzących aplikacje typu klient Iser• wer dla sieci TCP/IP.

Konfigurowanie NIS

Szczegóły konfigurowania NIS są miejscami bardzo złożone i zależne od konkretnej chitektury sieci, sprawiając niemało kłopotu jej administratorowi. Ogólne zasady ko gurowania nie są jednak zbyt skomplikowane i dlatego chciałbym przedstawić je ti na przykładzie małej sieci UNIXa.

Działanie NIS opiera się na zawartości kilku plików konfiguracyjnych; większość z nic egzystuje w takiej samej roli jako elementy informacji lokalnej. Oto ważniejsze plikiti

listy:

/etc/ethers odzwierciedla adresy sprzętowe MAC Ethernet w ~t~lresy IP

/etc/group określa zasady dostępu dla poszczególnych grup użytkowników

/etc/hosts wiąże nazwy maszyn z ich adresami IP

'i y: /etc/netmasks określa maski sieciowe IP dla poszczególnych domen

/etc/protocols zawiera listę protokołów obecnych w sieci

!' /etc/rpc zawiera listę numerów usług RPC

/ect/services określa numery portów TCP dla poszczególnych usług

~I' Zawartość wymienionych plików zostanie szczegółowo opisana przy okazji konfiguracji serwerów i klientów NIS.

Ustanawianie domeny NIS

Domenę NIS stanowi obszar sieci, podległy jednemu serwerowi wiodącemu NIS, w maganemu przez kilka serwerów podporządkowanych. Jak już wcześniej wspomniał domena NIS nie ma koncepcyjnie nic wspólnego z domeną DNS, lecz często wła f;

domeny DNS stanowią podstawę do podziału sieci na domeny NIS; bywa również że w ramach jednej domeny DNS wydzielone zostaje kilka domen NIS, każda zwid z określonym zastosowaniem, np. administracyjnym, naukowo-badawczym, handlov

NFS i NIS

321

itp. Taki sposób podziału jest jednak świadomym wyborem administratora i nie jest wy­muszony zasadami NIS.

Aby utworzyć domenę NIS, administrator musi wybrać dla niej nazwę, musi także znać adres IP maszyny, która będzie pełnić rolę serwera wiodącego. W końcu musi zdecydo­wać, które maszyny będą przynależne do nowo tworzonej domeny i logując się kolejno na każdej z nich (jako root lub inny z uprawnieniami administratora) wydać polecenie:

domainname nazwa domeny

Polecenie to stanie się skuteczne dopiero po ponownym uruchomieniu maszyny, toteż administrator powinien tę czynność wykonać; celowe jest ponadto wpisanie tego pole­cenia do skryptu startowego, którego nazwa zależy od konkretnej wersji systemu, za­zwyczaj jest to plik rc umieszczony w katalogu /etc/ r . d.

Demony NIS

Programami-demonami, organizującymi pracę protokołu NIS są: ypserv na serwerze oraz ypbind na maszynie-kliencie. Program ypserv oczekuje na żądanie od klienta i po jego otrzymaniu przystępuje do realizacji.

Program ypbind jest odpowiedzialny za połączenie z klienta z serwerem (wiodącym) za pomocą procesu zwanego związaniem (ang, binding). Jego praca rozpoczyna się od wysłania komunikatu typu broadcast do wszystkich serwerów wiodących, aby uzyskać adres 1P właściwego serwera oraz numer portu, przez który powinien wysyłać swoje żą­dania. Jeśli zareaguje równocześnie kilka serwerów, klient wybierze tylko pierwszą od­powiedź. Może się też tak zdarzyć, że nie nadejdzie żadna odpowiedź; program ypbind staje się uparty, ponawiając żądanie.

Programem umożliwiającym określenie, która maszyna pełni rolę serwem wiodącego dla danego klienta, jest program ypwhich:

$ ypwhich merlin

urowanie serwera wiodącego

Pierwszym krokiem konfigurowania serwem wiodącego jest zweryfikowanie zawartości wymienionych nieco wcześniej plików konfiguracyjnych N!S. Należy w szczególności upewnić się, że wszyscy użytkownicy posiadąjąprzypisane hasło, uzupełniając brakują­ce hasła lub usuwając nieaktualne konta. Należy ponadto sprawdzić prawidłowość przy­pisania poszczególnym użytkownikom katalogów roboczych.

Zaniedbania w tej dziedzinie mszczą się okrutnie - zdolnych hackerów nie brakuje ­a ich skutki dają znać o sobie wtedy, gdy zwykle jest za późno, bo przestają pracować krytyczne elementy sieci, jak główny serwer NIS lub jedna ze śluz.

ii 322 TCPIIP

i łi: i' i i..

Jeżeli wi c esteś uż ewien o rawne zawartości odnośn ch Tików u ewni si że ę j J p p P j Y P ~ P .I ę jesteś zalogowany jako root lub inny użytkownik posiadający uprawnienia administra­

i tura. Kolejnym krokiem konfigurowania serwem będzie bowiem generowanie map ­funkcję tę pełni program ypinit wywołany z opcją-m:

/usr/sbin/ypinit -m.

Ścieżka do programu może być inna w Twoim systemie. Program w czasie swojej pracy przegląda zawartość pliku /var/yp, zawierającego listę katalogów dla wszystkich pli-,1 ków NIS i na te odstawie tworz wsz stkie ma ane ma u ewni si co do loka­j p Y Y wY g pY ~ P j ę

lizacji tego pliku w Twojej instalacji).

Przy tworzeniu nowej domeny tworzony jest także katalog o tej samej nazwie co nazwa domeny, zlokalizowany jako podkatalog katalogu /var/yp. Jeżeli dla danego serwetą zostanie utworzone więcej domen, to każdej z nich przyporządkowany jest inny katalog.

Ostatnim etapem pracy programu ypinit jest przekazanie serwerowi wiodącemu maszyn-serwerów podporządkowanych, jako odpowiedzi na jego zapytanie.

W środowisku prawidłowo utworzonych map może być uruchomiony demon ypserv. Najbardziej typowym sposobem jego uruchamiania jest uruchamianie go równocześnie z systemem. Należy więc wpisać do skryptu rc sekwencję podobną do poniższej:

if [ -f /etd/yp/ypserv -a -d /var/yp/'domainname' ] then

/etc/yp/ypserv fi

Sekwencja ta sprawdza obecność katalogu tożsamego z nazwą domeny i w przypadku jego istnienia uruchamia program ypserv. Ponieważ konkretna nazwa domeny niejest znana, należy ją uzyskać jako wynik polecenia domainname - umieszczenie tego po­lecenia w apostrofach, służy właśnie temu celowi.

Należy teraz jeszcze uruchomić program ypbind - tak, ten sam co na maszynie lokal­nej - aby ypserv mógł odnaleźć żądane mapy w razie żądania maszyny-klienta. I znów najlepszym wyjściem jest wpisanie odpowiedniej sekwencji do skryptu startowego:

',~,' if [ -d /var/YP ] then /etc/yp/ypbind ; r

I,:; fi ł:.

Możesz wykonać prosty test na poprawność skonfigurowania: polecenie o następującej postaci:

a- ypmatch tparker passwd I

udostępnia odpowiednią linię pliku passwd, opisującąużytkownika o nazwie tparker. Możesz w ten sposób sprawdzić resztę użytkowników.

ś:';

NFS i NIS s2s

Konfigurowanie serwerów podporz~dkowanych

Xor~figmrora~anrćscr-werówpodparz~dkoruanych moźna rozpocząć dopiero po popraw­nym skonfigurowaniu serweta wiodącego. Zaloguj się więc jako ront na maszynie, któ­ra ma stać się serwerem podporządkowanym i na wstępie ustaw nazwę domeny, używa­jąc polecenia domainname. KolejnąTwojączynrościąbędzie uruchomietite programu ypb ind'.

/etc/yp/ypbind

aby serwer podporządkowany mógł ściągnąć potrzebne pliki z serwera wiodącego. Mo­żesz sprawdzić poprawność pracy programu ypbind przy pomocy polecenia ypwhich, które powinno zwrócić nazwę serwera wiodącego.

Ostateczne zainicjowanie serwera podporządkowanego następuje w wyniku polecenia:

letclyplypinit -s nazwa serwem

gdzie nazwa_serwera jest nazwą właściwego serwem wiodącego, natomiast przełącz­nik -s oznacza serwer podporządkowany (skrót od .rlnve).

Programy ypbind i ypinit powinny być normalnie uruchamiane ze skryptu startowe­go. Uaktualnienie map w serwerze podporządkowanym następuje w wyniku polecenia:

ypxfer mapy

gdzie mapy to nazwa pliku zawierającego poszczególne mapy, typowo jest to passwd. byname. Większość administratorów sieci zleca tę czynność demonowi zegarowemu tron, dodając xpfer do listy programów uruchamianych periodycznie.

Konfigurowanie klienta

Konfigurowanie klienta rozpoczyna się od wpisania do jego skryptu startowego polece­nia domainname, z nazwą domeny jako parametrem oraz polecenia uruchamiającego program ypbind(bezparametrów).

Zgodnie ztym, co wcześniej powiedziałem, jeżeli wymaga jest informacja o użytkowni­ku lub grupie, najpierw przeszukiwane są lokalne pliki /etc/passwd i /etc/group. Dopiero w przypadku nieznalezienia żądanej informacji następuje odwołanie do serwe­ra. W tym celu musisz na końcu pliku /etc/passwd dołączyć następującąlinię:

+:*:0:0:::

Jeżeli nie jest Ci obcy format pliku passwd, to z pewnością rozpoznałeś poprawną po­zycję z zerową informacją. Znak + w polu nazwy użytkownika stanowi dla programu ypbind polecenie odwołania się do serwera wiodącego. Linia taka może się znajdować w dowolnym miejscu pliku.

324

i:;.

yl, ; I', ,. ,,

Kontrola pracy RPC i NFS

Kontrolę pracy protokołów RPC i NFS umożliwiają dwa podstawowe programy. Są rpcinfo i nfsstat. Chociaż z reguły są one niedostępne dla użytkownika końcowej to jednak dobrze jest zdawać sobie sprawę z ich istnienia i roli pełnionej w systemie.

T'ak się niestety składa, że pojedynczy program diagnostyczny bardzo rzadko p. od razu uchwycić prawdziwą przyczynę błędu. Dla przykładu, oprogramowanie styczne wskazuje problemy z konkretnym portem, gdy tymczasem rzeczywistą ł ną błędu jest załamanie się drugiej końcówki połączenia. Dlatego też opisane tu my mogą być traktowane jedynie jako warte wzmianki uzupełnienie bardziej za. wanych narzędzi.

TCP/IP

rpcin#o

Program ten jest monitorem mapera portów RPC w maszynie, na której został urucho­miony oraz - za pośrednictwem sieci - mapera portów RPC na serwerze. Wyświetla ne przez niego informacje zawierają zawartość tablicy mapowania, pokazując numerł portów oraz programów związanych z każdym połączeniem. Ze względu na wyjątkowi istotną rolę mapera dla omawianych protokołów, informacje te mogą stanowić cenni wskazówkę ułatwiającą zlokalizowanie problemu.

Zazwyczaj program rpcinfo wywoływany jest z opcją -p, powodującą wyświetlenie wszystkich aktualnie wykonywanych programów znanych maperowi. Opcjonalnie moż~ na podać nazwę maszyny, co ograniczy informację wyłącznie do połączeń z konkretni maszyną. Oto jeden z typowych listingów produkowanych przez program:

rpcinfo -p

program wers proto 100000 2 tcp 100000 2 udp 100008 1 udp 150001 1 udp 150001 2 udp 100002 1 udp 100002 2 udp 100024 1 udp 100024 1 tcp 100020 1 udp 100020 1 tcp 100021 2 tcp 100021 1 tcp 100021 1 udp 100021 3 tcp 100021 3 udp

port 111 111

1026 1027 1027 1028 1028 1029 1024 1034 1025 1026 1027 1038 1028 1039

portmapper portmapper walki

pcnfsd pcnfsd rusersd rusersd status status llockmgr llockmgr nlockmgr nlockmgr nlockmgr nlockmgr nlockmgr

NFS i NIS

325

W przypadku problemów z uzyskaniem dostępu do mapera, program rpcinfo wyświe­tla komunikat o błędzie, na przykład:

$ rpcinfo -p.

rpcinfo: can't contact port mapper: RFC: Remote system error -125

Taki stan rzeczy może świadczyć o nieaktywności zdalnęj maszyny i pomocny może okazać się program ping.

Można uzyskać informacje o stanie wybranego połączenia, podając je (wraz z nazwą maszyny) jako parametr wywołania:

$ rpcinfo -u merlin walki

program 100008 version 1 is ready and waiting

Opcja -u oznacza połączenie wykorzystujące protokół UDP, dla połączenia wykorzy­stującego "fCP należy podać opcję -t. Wyświetlona informacja dotyczy programu. Je­żeli program nie uzyska odpowiedzi w założonym przedziale czasowym, zamiast stanu połączenia wyświetla komunikat o błędzie,

~isstat

Program nfsstat, jak sugeruje jego nazwa, duży do wyświetlenia statystyki dotyczą cej liczby i typów aktywnych żądań RPC. Zwykle wywoływany jest bez parametrów, choć różne implementacje oferują zróżnicowany zestaw opcji, zazwyczaj ograniczający statystykę do wybranych połączeń.

Przykładowy listing produkowany przez program nfsstat wygląda następująco: Serwer rpc:

calls badcalls nullrecv badlen xdrcall 10465 0 0 0 0

Serwer nfs:

calls badcalls

10432 0

null getattr setattr root lookup readlink read

1 0°-a 24 0~ 1 0% 0 0° 10123 0% 0 0° 5 0~

wrcache write create remove rename link symlink

0 O1 2 0° 0 0<. 1 0° 0 0% 1 0~ 0 0~

Client rpc:

calls badcalls retrans badxid timeout wait newcred

Ł3273 2 0 0 0 0 0

Client nfs:

calls badcalls

8263 0

null getattr setattr ront lookup readlink read

1 0~ 24 0~ 1 0°-„ 0 0~ 10123 0% 0 0~ 5 Oó

wrcache write create remove rename link symlink

0 0°~ 2 Oó 0 0% 1 Oó 0 Oó 1 0°-0 0 0%

326 TCP/IP

Listing ten zawiera wiele użytecznych informacji diagnostycznych. Pole badcalls po­kazuje liczbę błędnych komunikatów RPC. Wartości w polach nullrecv oraz badlen zawierająliczby komunikatów pustych i niekompletnych. W polu xdrcall znajdujesię liczba komunikatów nie dających się zinterpretować.

W części dotyczącej klienta, pole badxid pokazuje liczbę odebranych odpowiedzi, nie dających się skojarzyć z żadnym wysłanym żądaniem. Wartości timeout i retrans określają liczbę komunikatów wymagających powtórnego wysłania; duże liczby w tych polach mogąoznaczać zbyt wolne połączenie bądź awarię UDP. Pole wait wskazuje,ile razy (łącznie) procesy były zmuszone do oczekiwania z powodu braku wolnych portów. Wartości te mogą stanowić wskazówkę dla administratora, które elementy konfiguracji sieci należy poprawić; taki test powinien być wykonywany bardzo często.

a

f,ro' Podsumovuanie

System NFS zyskał sobie opinię systemu niezwykle złożonego i trudnego w użyciu. Nie wydaje się, aby te opinie były w pełni uzasadnione; w świetle informacji przedstawio­nych w tym rozdziale, jawi się on raczej jako eleganckie rozwiązanie najczęściej spoty~ kanych problemów przy wspólnym wykorzystywaniu zasobów sieciowych. Materiałowi tego rozdziału daleko do kompletności, gdyż pominąłem wiele szczegółów, chcąc unik nąć zniechęcenia Cię do dalszej lektury (mam nadzieję, że szczęśliwie udało mi się to). g,,,

R °Przedstawiłem również zasady działania i konfiguracji protokołu informacji sieciowej NIS. I chociaż nie każda sieć lokalna stanowi najbardziej podatny obszar do jego zaim~ plementowania, to jednak jest on na tyle istotnym elementem rodziny TCP/IP, żejego poznanie jest ze wszech miar pouczające.

i . i

Pytania i odpowiedzi

Scharakteryzuj w jednym zdaniu rolę, jaką spełnia NFS.

NFS umożliwia dostęp do zdalnych plików i katalogów w taki sam sposób, jak do kata logów i plików lokalnych.

Co, w kategoriach NFS, oznaczają pojęcia klienta i serwera? Po prostu: klient wysyła żądanie, a serwer na nie odpowiada.

Jaka jest rola RPC w NFS?

Protokół zdalnego wywołania procedury (RPC) zarządza komunikatami wymienianymi pomiędzy systemami bazującymi na NFS. Stanowi on zespół procedur wywoływanych przez klienta.

NFS i NIS

327

Jakie jest zadanie mapera portów?

Maper portów steruje przydziałem portów dla aplikacji, które ich wymagają.

Jakie funkcje spełnia Kernel Lock Manager?

Jest on częścią mechanizmu blokowania plików, synchronizującego ich wykorzystanie w warunkach wielodostępu. Jego praca sterowana jest żądaniami wysyłanymi przez klientów.

Quiz

1. Porównaj model warstwowy NFS z modelem OSI-RM.

2. Wyjaśnij, w jaki sposób maper dokonuje przydziału portów.

3. Co oznacza pojęcie „zewnętrznej reprezentacji danych" (XDR)?

4. Jakie zadania wykonuje protokół montowania?

5. Co oznacza termin „zdalne wykonywanie"? Jaka jest przewaga tego mechanizmu nad innymi podobnymi narzędziami?

---