Ludzie pragną czasami się rozstawać, żeby móc tęsknić, czekać i cieszyć się z powrotem.
Wywo³anie bez argumentów powoduje wypisanie ak-
tualnej nazwy domeny NIS. Aby nadaæ nazwê domenie, musisz uzyskaæ prawa
u¿ytkownika uprzywilejowanego:
# domainname brewery
Domeny NIS okreœlaj¹, do którego serwera NIS bêd¹ wysy³ane zapytania. Na
przyk³ad program login na hoœcie winiarni powinien oczywiœcie wysy³aæ zapytania
o has³o u¿ytkownika tylko do serwera NIS winiarni (lub jednego z nich, je¿eli jest ich
kilka), natomiast aplikacja dzia³aj¹ca na hoœcie browaru powinna trzymaæ siê ser-
wera nale¿¹cego do browaru.
Pozosta³a jeszcze jedna zagadka do wyjaœnienia: sk¹d klient wie, z którym serwerem
ma siê po³¹czyæ? Najprostsze rozwi¹zanie to u¿ycie pliku konfiguracyjnego, w któ-
rym znajduje siê nazwa hosta, na którym dzia³a serwer. Jednak podejœcie to jest ma³o
elastyczne, poniewa¿ nie pozwala klientom na u¿ywanie ró¿nych serwerów (z tej sa-
mej domeny oczywiœcie) w zale¿noœci od ich dostêpnoœci. Dlatego implementacje
NIS-a opieraj¹ siê na specjalnym demonie ypbind, dziêki któremu mo¿na wykryæ od-
powiedni serwer NIS w danej domenie. Przed wys³aniem zapytañ NIS, aplikacja
najpierw ustala za pomoc¹ ypbind, którego serwera ma u¿ywaæ.
ypbind znajduje serwery przez rozg³aszanie zapytania w lokalnej sieci IP. Pierwszy
serwer, który odpowie, jest uznawany za najszybszy i wykorzystywany we wszyst-
kich kolejnych zapytaniach NIS. Po pewnym czasie ypbind ponownie szuka aktyw-
nych serwerów. Robi tak równie¿, je¿eli serwer nie jest dostêpny.
Dynamiczne przypisywanie jest przydatne tylko wtedy, gdy twoja sieæ udostêpnia
wiêcej ni¿ jeden serwer NIS. Trzeba jednak pamiêtaæ, ¿e zagra¿a bezpieczeñstwu.
ypbind na œlepo wierzy temu, kto odpowie, bez wzglêdu na to, czy jest to oficjalny
serwer NIS, czy z³oœliwy intruz. Nie trzeba mówiæ, ¿e jest to szczególnie niebez-
NIS – strona klienta
233
pieczne, je¿eli za pomoc¹ NIS-a zarz¹dzasz bazami danych hase³. Aby uchroniæ siê
przed k³opotami, linuksowy program ypbind posiada opcjê szukania serwera NIS
w sieci lokalnej lub podania nazwy hosta, na którym dzia³a serwer NIS, w pliku kon-
figuracyjnym.
NIS kontra NIS+
Cel i nazwa to jedyne rzeczy, które ³¹cz¹ NIS-a i NIS+. NIS+ jest zbudowany zu-
pe³nie inaczej ni¿ NIS. Zamiast p³askiej przestrzeni nazw z chaotycznymi domenami
NIS-a, NIS+ wykorzystuje hierarchiczn¹ strukturê nazw podobn¹ do DNS-u. Za-
miast map, u¿ywane s¹ tak zwane tabele, które sk³adaj¹ siê z wierszy i kolumn. Ka¿-
dy wiersz zawiera obiekt z bazy danych NIS+, a ka¿da kolumna opisuje w³asnoœci
obiektu NIS+. Ka¿da tabela dla danej domeny NIS+ zawiera dane z domeny nad-
rzêdnej. Ponadto wpis w tabeli mo¿e zawieraæ dowi¹zanie do innej tabeli. Te funkcje
umo¿liwiaj¹ porz¹dkowanie informacji na wiele sposobów.
NIS+ dodatkowo obs³uguje bezpieczne i szyfrowane RPC, co znacznie pomaga
w rozwi¹zywaniu problemów z bezpieczeñstwem, które ujawni³y siê w przypadku
NIS-a.
Tradycyjny NIS u¿ywa RPC w wersji 2, natomiast NIS+ – w wersji 3. W czasie pisan-
ia tej ksi¹¿ki nie ma jeszcze dobrze dzia³aj¹cej implementacji NIS+ dla Linuksa, dla-
tego nie poœwiêcamy wiêcej miejsca temu tematowi.
NIS – strona klienta
Je¿eli znasz siê na pisaniu lub przenoszeniu aplikacji sieciowych, zapewne zauwa-
¿y³eœ, ¿e wiêkszoœæ przedstawionych map NIS odpowiada funkcjom bibliotecznym
z biblioteki C. Na przyk³ad, aby uzyskaæ informacje o passwd, u¿ywasz funkcji getpw-
nam i getpwuid, zwracaj¹cych informacje o koncie zwi¹zane odpowiednio z dan¹
nazw¹ u¿ytkownika lub jego ID. W normalnych warunkach funkcje te realizuj¹
przeszukiwanie standardowego pliku, na przyk³ad /etc/passwd.
Implementacja tych funkcji uwzglêdniaj¹ca NIS-a modyfikuje jednak to zachowanie
przez dodanie do serwera NIS wywo³ania RPC, które szuka nazwy u¿ytkownika lub