A hálózati információs szolgáltatást (Network Information Service, avagy NIS) a Sun Microsystems fejlesztette ki a UNIX® (eredetileg SunOS™) rendszerek központosított karbantartásához. Mostanra már lényegében ipari szabvánnyá nőtte ki magát, hiszen az összes nagyobb UNIX®-szerű rendszer (a Solaris™, HP-UX, AIX®, Linux, NetBSD, OpenBSD, FreeBSD stb.) támogatja a NIS használatát.
A NIS régebben sárga oldalak (Yellow Pages) néven volt ismert, de a különböző jogi problémák miatt később ezt a Sun megváltoztatta. A régi elnevezést (és a yp rövidítést) azonban még napjainkban is lehet néhol látni.
Ez egy RPC alapján működő, kliens/szerver felépítésű rendszer, amely az egy NIS tartomány belül levő számítógépek számára teszi lehetővé ugyanazon konfigurációs állományok használatát. Segítségével a rendszergazda a NIS klienseket a lehető legkevesebb adat hozzáadásával, eltávolításával vagy módosításával képes egyetlen helyről beállítani.
Hasonló a Windows NT® tartományaihoz, és habár a belső implementációt tekintve már akadnak köztük jelentős eltérések is, az alapvető funkciók szintjén mégis összevethetőek.
A NIS telepítése számos fogalom és fontos felhasználói program kerül elő FreeBSD-n, akár egy NIS szervert akarunk beállítani, akár csak egy NIS klienst:
Fogalom | Leírás |
---|---|
NIS tartománynév | A NIS központi szerverei és az összes hozzájuk tartozó kliens (beleértve az alárendelt szervereket) rendelkezik egy NIS tartománynévvel. Hasonló a Windows NT® által használt tartománynevekhez, de a NIS tartománynevei semmilyen kapcsolatban nem állnak a névfeloldással. |
rpcbind | Az RPC (Remote Procedure Call, a NIS által használt egyik hálózati protokoll) engedélyezéséhez lesz rá szükségünk. Ha az rpcbind nem fut, akkor sem NIS szervert, sem pedig NIS klienst nem tudunk működtetni. |
ypbind | A NIS klienst „köti össze” a hozzá tartozó NIS szerverrel. A NIS tartománynevet a rendszertől veszi, és az RPC használatával csatlakozik a szerverhez. Az ypbind a NIS környezet kliens és szerver közti kommunikációjának magját alkotja. Ha az ypbind leáll a kliens gépén, akkor nem tudjuk elérni a NIS szervert. |
ypserv | Csak a NIS szervereken szabad futnia, mivel ez maga a NIS szerver programja. Ha az ypserv(8) leáll, akkor a szerver nem lesz képes tovább kiszolgálni a NIS kéréseket (szerencsére az alárendelt szerverek képesek átvenni ezeket). A NIS bizonyos változatai (de nem az, amelyik a FreeBSD-ben is megjelenik) nem próbálnak meg más szerverekhez csatlakozni, ha bedöglik az aktuális használt szerver. Ezen gyakran egyedül csak a szervert képviselő program (vagy akár az egész szerver) újraindítása segíthet, illetve az ypbind újraindítása a kliensen. |
rpc.yppasswdd | Ez egy olyan program, amelyet csak a NIS központi szerverein kell csak futtatni. Ez a démon a NIS kliensek számára a NIS jelszavaik megváltoztatását teszi lehetővé. Ha ez a démon nem fut, akkor a felhasználók csak úgy tudják megváltoztatni a jelszavukat, ha bejelentkeznek a központi NIS szerverre. |
A NIS környezetekben háromféle gép létezik: a központi szerverek, az alárendelt szerverek és a kliensek. A szerverek képezik a gépek konfigurációs információinak központi tárhelyét. A központi szerverek tárolják ezen információk hiteles másolatát, míg ezt az alárendelt szerverek redundánsan tükrözik. A kliensek a szerverekre támaszkodnak ezen információk beszerzéséhez.
Sok állomány tartalma megosztható ezen
a módon. Például a
master.passwd
, a group
és hosts
állományokat
meg szokták osztani NFS-en. Amikor a kliensen
futó valamelyik programnak olyan
információra lenne szüksége, amely
általában ezekben az állományokban
nála megtalálható lenne, akkor helyette a
NIS szerverhez fordul.
A központi NIS szerver. Ez
a szerver, amely leginkább a Windows NT®
elsődleges
tartományvezérlőjéhez
hasonlítható tartja karban az összes,
NIS kliensek által használt
állományt. A passwd
,
group
, és összes
többi ehhez hasonló állomány
ezen a központi szerveren található
meg.
Egy gép akár több NIS tartományban is lehet központi szerver. Ezzel a lehetőséggel viszont itt most nem foglalkozunk, mivel most csak egy viszonylag kis méretű NIS környezetet feltételezünk.
Az alárendelt NIS szerverek. A Windows NT® tartalék tartományvezérlőihez hasonlítanak, és az alárendelt NIS szerverek feladata a központi NIS szerveren tárolt adatok másolatainak karbantartása. Az alárendelt NIS szerverek a redundancia megvalósításában segítenek, aminek leginkább a fontosabb környezetekben van szerepe. Emellett a központi szerver terhelésének kiegyenlítését is elvégzik. A NIS kliensek elsőként mindig ahhoz a NIS szerverhez csatlakoznak, amelytől először választ kapnak, legyen akár az egy alárendelt szerver.
A NIS kliensek. A NIS kliensek, hasonlóan a Windows NT® munkaállomásokhoz, a NIS szerveren (amely a Windows NT® munkaállomások esetében a tartományvezérlő) keresztül jelentkeznek be.
Ebben a szakaszban egy példa NIS környezetet állítunk be.
Tegyük fel, hogy egy aprócska egyetemi labor
rendszergazdái vagyunk. A labor, mely 15 FreeBSD-s
gépet tudhat magáénak, jelen pillanatban
még semmilyen központosított
adminisztráció nem létezik. Mindegyik
gép saját /etc/passwd
és /etc/master.passwd
állománnyal rendelkezik. Ezeket az
állományokat saját kezűleg kell
szinkronban tartani. Tehát ha most felveszünk egy
felhasználót a laborhoz, akkor az
adduser
parancsot mind a 15 gépen ki
kell adni. Egyértelmű, hogy ez így nem
maradhat, ezért úgy döntöttük,
hogy a laborban NIS-t fogunk használni, és
két gépet kinevezünk szervernek.
Az iméntieknek megfelelően a labor most valahogy így néz ki:
A gép neve | IP-cím | A gép szerepe |
---|---|---|
ellington | 10.0.0.2 | központi NIS |
coltrane | 10.0.0.3 | alárendelt NIS |
basie | 10.0.0.4 | tanszéki munkaállomás |
bird | 10.0.0.5 | kliensgép |
cli[1-11] | 10.0.0.[6-17] | a többi kliensgép |
Ha még nincs tapasztalatunk a NIS rendszerek összeállításában, akkor először jó ötlet lehet végiggondolni, miként is akarjuk kialakítani. A hálózatunk méretétől függetlenül is akadnak olyan döntések, amelyeket mindenképpen meg kell hoznunk.
Ez nem az a „tartománynév”, amit megszokhattunk. Ennek a pontos neve „NIS tartománynév”. Amikor a kliensek kérnek valamilyen információt, akkor megadják annak a NIS tartománynak a nevét is, amelynek részei. Így tud egy hálózaton több szerver arról dönteni, hogy melyikük melyik kérést válaszolja meg. A NIS által használt tartománynévre tehát inkább úgy érdemes gondolni, mint egy valamilyen módon összetartozó gépek közös nevére.
Előfordul, hogy egyes szervezetek az interneten is
nyilvántartott tartománynevüket
választják NIS tartománynévnek.
Ez alapvetően nem ajánlott, mivel a
hálózati problémák
felderítése közben
félreértéseket szülhet. A NIS
tartománynévnek a hálózatunkon
belül egyedinek kell lennie, és lehetőleg
minél jobban írja le az általa
csoportba sorolt gépeket. Például a
Kis Kft. üzleti osztályát tegyük a
„kis-uzlet” NIS tartományba. Ebben a
példában most a
proba-tartomany
nevet
választottuk.
A legtöbb operációs rendszer azonban (köztük a SunOS™) a NIS tartománynevet használja internetes tartománynévként is. Ha a hálózatunkon egy vagy több ilyen gép is található, akkor a NIS tartomány nevének az internetes tartománynevet kell megadnunk.
Nem árt néhány dolgot fejben tartani, amikor a NIS szervernek használt gépet kiválasztjuk. Az egyik ilyen szerencsétlen dolog az a szintű függőség, ami a NIS kliensek felől megfigyelhető a szerverek felé. Ha egy kliens nem tudja a NIS tartományon belül felvenni a kapcsolatot valamelyik szerverrel, akkor az a gép könnyen megbízhatatlanná válhat. Felhasználói- és csoportinformációk nélkül a legtöbb rendszer egy időre le is merevedik. Ennek figyelembevételével tehát olyan gépet kell szervernek választanunk, amelyet nem kell gyakran újraindítani, és nem végzünk rajta semmilyen komoly munkát. A célnak legjobban megfelelő NIS szerverek valójában olyan gépek, amelyek egyedüli feladata csak a NIS kérések kiszolgálása. Ha a hálózatunk nem annyira leterhelt, akkor még a NIS szerver mellett más programokat is futtathatunk, de ne feledjük, hogy ha a NIS szolgáltatás megszűnik, akkor az az összes NIS kliensen éreztetni fogja kedvezőtlen hatását.
A NIS rendszerben tárolt összes
információ általános
példánya egyetlen gépen
található meg, amelyet a központi NIS
szervernek hívunk. Az információk
tárolására szánt adatbázis
pedig NIS táblázatoknak (NIS map) nevezzük.
FreeBSD alatt ezek a táblázatok a
/var/yp/tartománynév
könyvtárban találhatóak, ahol a
tartománynév
a kiszolgált NIS tartományt nevezi meg.
Egyetlen NIS szerver egyszerre akár több
tartományt is kiszolgálhat, így itt
több könyvtár is található,
minden támogatott tartományhoz egy. Minden
tartomány saját, egymástól
független táblázatokkal rendelkezik.
A központi és alárendelt NIS szerverek
az ypserv
démon
segítségével dolgozzák fel a NIS
kéréseket. Az ypserv
felelős a NIS kliensektől befutó
kérések fogadásáért,
és a kért tartomány valamint
táblázat nevéből meghatározza
az adatbázisban tárolt állományt,
majd innen visszaküldi a hozzá tartozó
adatot a kliensnek.
A központi NIS szerver
beállítása viszonylag
magától értetődő, de a
nehézségét az igényeink
szabják meg. A FreeBSD alapból támogatja
a NIS használatát. Ezért
mindössze annyit kell tennünk, hogy a
következő sorokat betesszük az
/etc/rc.conf
állományba,
és a FreeBSD gondoskodik a többiről.
nisdomainname="proba-tartomany"
Ez a sor adja meg a hálózati
beállítások (vagy
például az
újraindítás) során a NIS
tartomány nevét, amely a korábbiak
szerint itt most a
proba-tartomany
.
nis_server_enable="YES"
Ezzel utasítjuk a FreeBSD-t, hogy a hálózati alkalmazások következő indításakor a NIS szervert is aktiválja.
nis_yppasswdd_enable="YES"
Ezzel engedélyezzük az
rpc.yppasswdd
démont, amely a
korábban említettek szerint
lehetővé teszi a felhasználók
számára, hogy a közvetlenül a
kliensekről változtassák meg a NIS
jelszavukat.
A konkrét NIS beállításainktól függően további bejegyzések felvételére is szükségünk lehet. Erre később még az olyan NIS szervereknél, amelyek egyben NIS kliensek, vissza fogunk térni.
Miután ezeket beállítottuk,
rendszeradminisztrátorként adjuk ki az
/etc/netstart
parancsot. Az
/etc/rc.conf
állományban
szereplő adatok alapján mindent
beállít magától. Még
mielőtt inicializálnánk a NIS
táblázatokat, indítsuk el
manuálisan az ypserv
démont:
#
/etc/rc.d/ypserv start
A NIS táblázatok
lényegében a /var/yp
könyvtárban tárolt adatbázisok. A
központi NIS szerver /etc
könyvtárában található
konfigurációs
állományokból
állítódnak elő, egyetlen
kivétellel: ez az
/etc/master.passwd
állomány. Ennek megvan a maga oka, hiszen nem
akarjuk a root
és az összes
többi fontosabb felhasználóhoz
tartozó jelszót az egész NIS
tartománnyal megosztani. Ennek megfelelően a
NIS táblázatok
inicializálásához a
következőt kell tennünk:
#
cp /etc/master.passwd /var/yp/master.passwd
#
cd /var/yp
#
vi master.passwd
El kell távolítanunk az összes
rendszerszintű (bin
,
tty
, kmem
,
games
, stb), és minden olyan
egyéb hozzáférést, amelyeket nem
akarjuk közvetíteni a NIS kliensek felé
(például a root
és
minden más nullás, vagyis
rendszeradminisztrátori azonosítóval
ellátott hozzáférést).
Gondoskodjunk róla, hogy az
/var/yp/master.passwd
állomány sem a csoport, sem pedig
bárki más számára nem
olvasható (600-as engedély)! Ennek
beállításához
használjuk az chmod
parancsot,
ha szükséges.
Ha végeztünk, akkor már
tényleg itt az ideje inicializálni NIS
táblázatainkat. A FreeBSD erre egy
ypinit
nevű szkriptet ajánl
fel (erről a saját man oldalán tudhatunk
meg többet). Ez a szkript egyébként a
legtöbb UNIX® típusú
operációs rendszeren
megtalálható, de nem az összesen. A
Digital UNIX/Compaq Tru64 UNIX rendszereken ennek a neve
ypsetup
. Mivel most a központi NIS
szerver táblázatait hozzuk létre,
azért az ypinit
szkriptnek
át kell adnunk a -m
opciót
is. A NIS táblázatok
előállításánál
feltételezzük, hogy a fentebb ismertetett
lépéseket már megtettük, majd
kiadjuk ezt a parancsot:
ellington#
ypinit -m proba-tartomany
Server Type: MASTER Domain: proba-tartomany Creating an YP server will require that you answer a few questions. Questions will all be asked at the beginning of the procedure. Do you want this procedure to quit on non-fatal errors? [y/n: n]n
Ok, please remember to go back and redo manually whatever fails. If you don't, something might not work. At this point, we have to construct a list of this domains YP servers. rod.darktech.org is already known as master server. Please continue to add any slave servers, one per line. When you are done with the list, type a <control D>. master server : ellington next host to add:coltrane
next host to add:^D
The current list of NIS servers looks like this: ellington coltrane Is this correct? [y/n: y]y
[ .. a táblázatok generálása .. ] NIS Map update completed. ellington has been setup as an YP master server without any errors.
Az üzenetek fordítása:
A szerver típusa: KÖZPONTI, tartomány: proba-tartomany Az YP szerver létrehozásához meg kell válaszolni néhány kérdést az eljárás megkezdése előtt. Szeretnénk, ha az eljárás megszakadna a nem végzetes hibák esetén is? [i/n: n]n
Rendben, akkor ne felejtsük el manuálisan kijavítani a hibát, ha valamivel gond lenne. Ha nem tesszük meg, akkor előfordulhat, hogy valami nem fog rendesen működni. Most össze kell állítanunk egy listát a tartomány YP szervereiről. Jelenleg a rod.darktech.org a központi szerver. Kérjünk, adjon meg további alárendelt szervereket, soronként egyet. Amikor ezt befejeztük, a <control D> lenyomásával tudunk kilépni. központi szerver : ellington következő gép :coltrane
következő gép :^D
A NIS szerverek listája jelenleg a következő: ellington coltrane Ez megfelelő? [i/n: i]i
[ .. a táblázatok generálása .. ] A NIS táblázatok sikeressen frissültek. Az elligon szervert minden hiba nélkül sikerült központi szerverként beállítani.
Az ypinit
a
/var/yp/Makefile.dist
állományból létrehozza a
/var/yp/Makefile
állományt. Amennyiben ez
létrejött, az állomány
feltételezi, hogy csak FreeBSD-s gépek
részvételével akarunk
kialakítani egy egyszerveres NIS környezetet.
Mivel a proba-tartomany
még egy
alárendelt szervert is tartalmaz, ezért
át kell írnunk a
/var/yp/Makefile
állományt:
ellington#
vi /var/yp/Makefile
Ezt a sort kell megjegyzésbe tennünk:
NOPUSH = "True"
(ha még nem lenne úgy).
Az alárendelt NIS szerverek
beállítása még a
központinál is egyszerűbb.
Jelentkezzünk be az alárendelt szerverre
és az eddigieknek megfelelően írjuk
át az /etc/rc.conf
állományt. Az egyetlen
különbség ezúttal csupán
annyi lesz, hogy az ypinit
lefuttatásakor a -s
opciót
kell megadnunk (mint slave, vagyis alárendelt). A
-s
opció használatához
a központi NIS szerver nevét is át kell
adnunk, ezért a konkrét parancs valahogy
így fog kinézni:
coltrane#
ypinit -s ellington proba-tartomany
Server Type: SLAVE Domain: test-domain Master: ellington Creating an YP server will require that you answer a few questions. Questions will all be asked at the beginning of the procedure. Do you want this procedure to quit on non-fatal errors? [y/n: n]n
Ok, please remember to go back and redo manually whatever fails. If you don't, something might not work. There will be no further questions. The remainder of the procedure should take a few minutes, to copy the databases from ellington. Transferring netgroup... ypxfr: Exiting: Map successfully transferred Transferring netgroup.byuser... ypxfr: Exiting: Map successfully transferred Transferring netgroup.byhost... ypxfr: Exiting: Map successfully transferred Transferring master.passwd.byuid... ypxfr: Exiting: Map successfully transferred Transferring passwd.byuid... ypxfr: Exiting: Map successfully transferred Transferring passwd.byname... ypxfr: Exiting: Map successfully transferred Transferring group.bygid... ypxfr: Exiting: Map successfully transferred Transferring group.byname... ypxfr: Exiting: Map successfully transferred Transferring services.byname... ypxfr: Exiting: Map successfully transferred Transferring rpc.bynumber... ypxfr: Exiting: Map successfully transferred Transferring rpc.byname... ypxfr: Exiting: Map successfully transferred Transferring protocols.byname... ypxfr: Exiting: Map successfully transferred Transferring master.passwd.byname... ypxfr: Exiting: Map successfully transferred Transferring networks.byname... ypxfr: Exiting: Map successfully transferred Transferring networks.byaddr... ypxfr: Exiting: Map successfully transferred Transferring netid.byname... ypxfr: Exiting: Map successfully transferred Transferring hosts.byaddr... ypxfr: Exiting: Map successfully transferred Transferring protocols.bynumber... ypxfr: Exiting: Map successfully transferred Transferring ypservers... ypxfr: Exiting: Map successfully transferred Transferring hosts.byname... ypxfr: Exiting: Map successfully transferred coltrane has been setup as an YP slave server without any errors. Don't forget to update map ypservers on ellington.
Most már lennie kell egy
/var/yp/proba-tartomany
nevű
könyvtárunknak is. A központi NIS szerver
táblázatainak másolata itt fognak
tárolódni. Ezeket soha ne felejtsük el
frissen tartani. Az alárendelt szervereken a
következő /etc/crontab
bejegyzések pontosan ezt a feladatot
látják el:
20 * * * * root /usr/libexec/ypxfr passwd.byname 21 * * * * root /usr/libexec/ypxfr passwd.byuid
Ez a két sor gondoskodik róla, hogy az alárendelt szerverek ne felejtsék el egyeztetni a táblázataikat a központi szerver táblázataival. Ezek a bejegyzések nem nélkülözhetetlenek a megfelelő működéshez, mivel a központi szerver automatikusan feltölti az alárendelt szerverekre a létrejött változásokat. Mivel azonban a jelszavak létfontosságúak a szervertől függő rendszerek számára, ezért ajánlott explicit módon is előírni a frissítést. Ez a forgalmasabb hálózatokon nagyobb jelentőséggel bír, mivel ott a táblázatok frissítése nem mindig fejeződik be rendesen.
Most pedig futassuk le a
/etc/netstart
parancsot az
alárendelt szervereken is, amivel így elindul
a NIS szerver.
A NIS kliens az ypbind
démon
segítségével egy kötésnek
(bind) nevezett kapcsolatot épít ki egy adott
NIS szerverrel. Az ypbind
ellenőrzi a
rendszer alapértelmezett tartományát (ezt
a domainname
paranccsal
állítottunk be), majd RPC
kéréseket kezd szórni a helyi
hálózaton. Ezek a kérések annak a
tartománynak a nevét tartalmazzák,
amelyhez az ypbind
megpróbál
kötést létrehozni. Ha az adott
tartomány kiszolgálására
beállított szerver észleli ezeket a
kéréseket, akkor válaszol az
ypbind
démonnak, amely pedig
feljegyzi a szerver címét. Ha több szerver
is elérhető (például egy
központi és több alárendelt), akkor az
ypbind
az elsőként
válaszoló címét fogja
rögzíteni. Innentől kezdve a kliens
közvetlenül ennek a szervernek fogja küldeni a
NIS kéréseit. Az ypbind
időnként „megpingeli” a szervert,
hogy meggyőződjön az
elérhetőségéről. Ha az
ypbind
egy adott időn belül nem
kap választ a ping kéréseire, akkor
megszünteti a kötést a tartományhoz
és nekilát keresni egy másik
szervert.
Egy FreeBSD-s gépet NIS kliensként meglehetősen egyszerűen lehet beállítani.
Nyissuk meg az /etc/rc.conf
állományt és a NIS
tartománynév
beállításához, valamint az
ypbind
elindításához a
következőket írjuk bele:
nisdomainname="proba-tartomany" nis_client_enable="YES"
A NIS szerveren található jelszavak
importálásához
távolítsuk el az összes
felhasználói
hozzáférést az
/etc/master.passwd
állományunkból és a
vipw
segítségével adjuk hozzá az
alábbi sort az állomány
végéhez:
+:::::::::
Ez a sor beenged bárkit a
rendszerünkre, akinek a NIS szervereken van
érvényes
hozzáférése. A NIS klienseket
ezzel a sorral sokféle módon tudjuk
állítani. A hálózati
csoportokról szóló
szakaszban találunk majd erről
több információt. A téma
mélyebb megismeréséhez az
O'Reilly Managing NFS and NIS
című könyvét
ajánljuk.
Legalább helyi
hozzáférést (vagyis amit nem
NIS-en keresztül importálunk) azonban
mindenképpen hagyjunk meg az
/etc/master.passwd
állományunkban, és ez a
hozzáférés legyen a
wheel
csoport tagja. Ha valami
gond lenne a NIS használatával, akkor
ezen a hozzáférésen
keresztül tudunk a gépre
távolról bejelentkezni, majd innen
root
felhasználóra
váltva megoldani a felmerült
problémákat.
A NIS szerverről az összes
lehetséges csoport-bejegyzést az
/etc/group
állományban így tudjuk
importálni:
+:*::
Miután elvégeztük ezeket a
lépéseket, képesek leszünk
futtatni az ypcat passwd
parancsot,
és látni a NIS szerver jelszavakat
tartalmazó táblázatát.
Általában tetszőleges távoli
felhasználó küldhet RPC
kéréseket az ypserv(8) számára
és kérheti le a NIS táblázatok
tartalmát, feltéve, hogy ismeri a tartomány
nevét. Az ilyen hitelesítés
nélküli műveletek ellen az ypserv(8)
úgy védekezik, hogy tartalmaz egy
„securenets” nevű lehetőséget,
amellyel az elérhetőségüket tudjuk
leszűkíteni gépek egy csoportjára. Az
ypserv(8) indításakor ezeket az
információkat a
/var/yp/securenets
állományból próbálja meg
betölteni.
Az elérési útvonala megadható
a -p
opció
használatával. Ez az állomány
olyan bejegyzéseket tartalmaz, amelyekben egy
hálózati cím és tőle
láthatatlan karakterekkel elválasztva egy
hálózati maszk szerepel. A „#”
karakterrel kezdődő sorokat megjegyzésnek
nyilvánítjuk. Egy minta securenets
állomány valahogy így nézne
ki:
# Engedélyezzük önmagunkról a csatlakozást -- kell! 127.0.0.1 255.255.255.255 # Engedélyezzük a 192.168.128.0 hálózatról érkező csatlakozásokat: 192.168.128.0 255.255.255.0 # Engedélyezzük a laborban található 10.0.0.0 és 10.0.15.255 közti # címekkel rendelkező gépek csatlakozását: 10.0.0.0 255.255.240.0
Ha az ypserv(8) olyan címről kap
kérést, amely illeszkedik az előírt
címek valamelyikére, akkor a szokásos
módon feldolgozza azt. Ellenkező esetben a
kérést figyelmen kívül hagyja
és egy figyelmeztetést vesz fel hozzá a
naplóba. Ha a /var/yp/securenets
állomány nem létezik, akkor az
ypserv
tetszőleges gépről
engedélyezi a csatlakozást.
Az ypserv
lehetőséget ad a
Wietse Venema által fejlesztett TCP
Wrapper csomag használatára is.
Ezzel a rendszergazda a /var/yp/securenets
állomány helyett a TCP
Wrapper konfigurációs
állományai alapján képes
szabályozni az elérhetőséget.
Miközben mind a két módszer nyújt valamilyen fajta védelmet, de a privilegizált portok teszteléséhez hasonlóan az „IP álcázásával” (IP spoofing) sebezhetőek. Ezért az összes NIS-hez tartozó forgalmat tűzfallal kell blokkolnunk.
Az /var/yp/securenets
állományt használó szerverek nem
képesek az elavult TCP/IP
implementációkat használó
érvényes klienseket rendesen kiszolgálni.
Egyes ilyen implementációk a címben a
géphez tartozó biteket nullára
állítják az
üzenetszóráshoz, és/vagy
ezért az üzenetszóráshoz
használt cím kiszámításakor
nem tudja észleli a hálózati maszkot. A
legtöbb ilyen probléma megoldható a kliens
konfigurációjának
megváltoztatásával, míg más
problémák megoldása a
kérdéses kliensek
nyugdíjazását
kívánják meg, vagy a
/var/yp/securenets
használatának elhagyását.
Egy régebbi TCP/IP implementációval
üzemelő szerveren pedig a
/var/yp/securenets
állomány
használata kifejezetten rossz ötlet, és a
hálózatunk nagy részében
képes használhatatlanná tenni a NIS
funkcióit.
A TCP Wrapper csomag alkalmazása a NIS szerverünk válaszadáshoz szükséges idejét is segít csökkenteni. Az ilyenkor jelentkező plusz késlekedés mellesleg elég nagy lehet ahhoz, hogy a klienseknél időtúllépés következzen be, különösen a terheltebb hálózatokon vagy a lassú NIS szerverek esetében. Ha egy vagy több kliensünk is ilyen tüneteket mutat, akkor érdemes a kérdéses kliens rendszereket alárendelt NIS szerverekké alakítani és önmagukhoz rendelni.
A laborunkban van egy basie
nevű
gép, amely a tanszék egyetlen
munkaállomása. Ezt a gépet nem akarjuk
kivenni a NIS tartományból, de a központi NIS
szerver passwd
állománya
mégis egyaránt tartalmazza a hallgatók
és az oktatók eléréseit. Mit lehet
ilyenkor tenni?
Adott felhasználók esetében le tudjuk
tiltani a bejelentkezést a gépen még
olyankor is, ha léteznek a NIS
adatbázisában. Ehhez mindössze a kliensen az
/etc/master.passwd
állomány
végére be kell tennünk egy
-felhasználónév
sort, ahol a
felhasználónév
annak a felhasználónak a neve, akit nem akarunk
beengedni a gépre. Ezt leginkább a
vipw
használatán keresztül
érdemes megtennünk, mivel a vipw
az /etc/master.passwd
állomány alapján végez némi
ellenőrzést, valamint a szerkesztés
befejeztével magától
újragenerálja a jelszavakat tároló
adatbázist. Például, ha a
bill
nevű felhasználót
ki akarjuk tiltani a basie
nevű
gépről, akkor:
basie#
vipw
[vegyük fel a -bill sort a végére, majd lépjünk ki]
vipw: rebuilding the database... vipw: done basie#
cat /etc/master.passwd
root:[jelszó]:0:0::0:0:The super-user:/root:/bin/csh toor:[jelszó]:0:0::0:0:The other super-user:/root:/bin/sh daemon:*:1:1::0:0:Owner of many system processes:/root:/sbin/nologin operator:*:2:5::0:0:System &:/:/sbin/nologin bin:*:3:7::0:0:Binaries Commands and Source,,,:/:/sbin/nologin tty:*:4:65533::0:0:Tty Sandbox:/:/sbin/nologin kmem:*:5:65533::0:0:KMem Sandbox:/:/sbin/nologin games:*:7:13::0:0:Games pseudo-user:/usr/games:/sbin/nologin news:*:8:8::0:0:News Subsystem:/:/sbin/nologin man:*:9:9::0:0:Mister Man Pages:/usr/share/man:/sbin/nologin bind:*:53:53::0:0:Bind Sandbox:/:/sbin/nologin uucp:*:66:66::0:0:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico xten:*:67:67::0:0:X-10 daemon:/usr/local/xten:/sbin/nologin pop:*:68:6::0:0:Post Office Owner:/nonexistent:/sbin/nologin nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/sbin/nologin +::::::::: -bill basie#
Az előző szakaszban ismertetett módszer viszonylag jól működik olyan esetekben, amikor nagyon kevés felhasználóra és/vagy számítógépre kell alkalmaznunk speciális megszorításokat. A nagyobb hálózatokban szinte biztos, hogy elfelejtünk kizárni egyes felhasználókat az érzékeny gépekről, vagy az összes gépen egyenként kell ehhez a megfelelő beállításokat elvégezni, és ezzel lényegében elvesztjük a NIS legfontosabb előnyét, vagyis a központosított karbantarthatóságot.
A NIS fejlesztői erre a problémára a hálózati csoportokat létrehozásával válaszoltak. A céljuk és működésük szempontjából leginkább a UNIX®-os állományrendszerekben található csoportokhoz mérhetőek. A legnagyobb eltérés a numerikus azonosítók hiányában mutatkozik meg, valamint a hálózati csoportokat a felhasználókon kívül további hálózati csoportok megadásával is ki lehet alakítani.
A hálózati csoportok a nagyobb, bonyolultabb, többszáz felhasználós hálózatok számára jöttek létre. Egy részről ez nagyon jó dolog, különösen akkor, ha egy ilyen helyzettel kell szembenéznünk. Másrészről ez a mértékű bonyolultság szinte teljesen lehetetlenné teszi a hálózati csoportok egyszerű bemutatását. A szakasz további részében használt példa is ezt a problémát igyekszik illusztrálni.
Tételezzük fel, hogy laborunkban a NIS sikeres bevezetése felkeltette a főnökeink figyelmét. Így a következő feladatunk az lett, hogy terjesszük ki a NIS tartományt az egyetemen található néhány másik gépre is. Az alábbi két táblázatban az új felhasználók és az új számítógép neveit találjuk, valamint a rövid leírásukat.
Felhasználók nevei | Leírás |
---|---|
alpha ,
beta | az IT tanszék hétköznapi dolgozói |
charlie ,
delta | az IT tanszék újdonsült dolgozói |
echo ,
foxtrott , golf ,
... | átlagos dolgozók |
able ,
baker , ... | ösztöndíjasok |
Gépek nevei | Leírás |
---|---|
haboru , halal ,
ehseg , szennyezes | A legfontosabb szervereink. Csak az IT tanszék dolgozói férhetnek hozzájuk. |
buszkeseg ,
kapzsisag , irigyseg ,
harag , bujasag ,
lustasag | Kevésbé fontos szerverek. Az IT tankszék összes tagja el tudja érni ezeket a gépeket. |
egy , ketto ,
harom , negy ,
... | Átlagos munkaállomások. Egyedül csak a valódi dolgozók jelentkezhetnek be ezekre a gépekre. |
szemetes | Egy nagyon régi gép, semmi értékes adat nincs rajta. Akár még az öszöndíjasok is nyúzhatják. |
Ha ezeket az igényeket úgy
próbáljuk meg teljesíteni, hogy a
felhasználókat egyenként blokkoljuk, akkor
minden rendszer passwd
állományába külön fel kell
vennünk a
-felhasználó
sorokat a letiltott felhasználókhoz. Ha csak
egyetlen bejegyzést is kihagyunk, akkor könnyen
bajunk származhat belőle. Ez a rendszer kezdeti
beállítása során még
talán nem okoz gondot, de az új
felhasználókat biztosan el
fogjuk felejteni felvenni a megfelelő csoportokba.
Elvégre Murphy is optimista volt.
A hálózati csoportok használata ilyen helyzetekben számos előnyt rejt. Nem kell az egyes felhasználókat külön felvenni, egy felhasználót felveszünk valamelyik csoportba vagy csoportokba, és a csoportok összes tagjának egyszerre tudjuk tiltani vagy engedélyezni a hozzáféréseket. Ha hozzáadunk egy új gépet a hálózatunkhoz, akkor mindössze a hálózati csoportok bejelentkezési korlátozásait kell beállítani. Ha új felhasználót veszünk fel, akkor a felhasználót kell vennünk egy vagy több hálózati csoportba. Ezek a változtatások függetlenek egymástól, és nincs szükség „minden felhasználó és minden gép összes kombinációjára”. Ha a NIS beállításainkat előzetesen körültekintően megterveztük, akkor egyetlen központi konfigurációs állományt kell módosítani a gépek elérésének engedélyezéséhez vagy tiltásához.
Az első lépés a hálózati csoportokat tartalmazó NIS táblázat inicializálása. A FreeBSD ypinit(8) programja alapértelmezés szerint nem hozza létre ezt a táblázatot, de ha készítünk egy ilyet, akkor a NIS implementációja képes kezelni. Egy ilyen üres táblázat elkészítéséhez ennyit kell begépelni:
ellington#
vi /var/yp/netgroup
Ezután elkezdhetjük felvenni a tartalmát. A példánk szerint legalább négy hálózati csoportot kell csinálnunk: az IT dolgozóinak, az IT új dolgozóinak, a normál dolgozóknak és az öszöndíjasoknak.
IT_DOLG (,alpha,proba-tartomany) (,beta,proba-tartomany) IT_UJDOLG (,charlie,proba-tartomany) (,delta,proba-tartomany) FELHASZNALO (,echo,proba-tartomany) (,foxtrott,proba-tartomany) \ (,golf,proba-tartomany) OSZTONDIJAS (,able,proba-tartomany) (,baker,proba-tartomany)
Az IT_DOLG
, IT_UJDOLG
stb. a hálózati csoportok nevei lesznek. Minden
egyes zárójelezett csoport egy vagy több
felhasználói hozzáférést
tartalmaz. A csoportokban szereplő három mező
a következő:
Azon gépek neve, amelykre a következő elemek érvényesek. Ha itt nem adunk meg neveket, akkor a bejegyzés az összes gépre vonatkozik. Ha megadjuk egy gép nevét, akkor jutalmunk a teljes sötétség, a rettegetés és totális megtébolyodás.
A csoporthoz tartozó hozzáférés neve.
A hozzáféréshez kapcsolódó NIS tartomány. A csoportba más NIS tartományokból is át tudunk hozni hozzáféréseket, ha netalán éppen olyan szerencsétlenek lennénk, hogy több NIS tartományt is felügyelnünk kell.
A mezők mindegyike tartalmazhat dzsókerkaraktereket. Erről részletesebben a netgroup(5) man oldalon olvashatunk.
A hálózati csoportoknak lehetőleg ne adjunk 8 karakternél hosszabb nevet, különösen abban az esetben, ha a NIS tartományban más operációs rendszereket is használunk. A nevekben eltérnek a kis- és nagybetűk. Ha a hálózati csoportokat nevét nagybetűkkel írjuk, akkor könnyen különbséget tudunk tenni a felhasználók, gépek és hálózati csoportok nevei között.
Egyes (nem FreeBSD alapú) NIS kliensek nem képesek kezelni a nagyon sok bejegyzést tartalmazó hálózati csoportokat. Például a SunOS™ néhány korábbi verziója fennakad rajta, ha egy hálózati csoport 15 bejegyzésnél többet tartalmaz. Az ilyen korlátozások alól úgy tudunk kibújni, ha 15 felhasználónként újabb hálózati csoportokat hozunk létre, amelyekkel az eredeti hálózati csoportot építjük fel:
NAGYCSP1 (,joe1,tartomany) (,joe2,tartomany) (,joe3,tartomany) [...] NAGYCSP2 (,joe16,tartomany) (,joe17,tartomany) [...] NAGYCSP3 (,joe31,tartomany) (,joe32,tartomany) NAGYCSOPORT NAGYCSP1 NAGYCSP2 NAGYCSP3
Ugyanez a folyamat javasolt olyan esetekben is, ahol 225 felhasználónál többre lenne szükség egyetlen hálózati csoporton belül.
Az így létrehozott új NIS táblázat szétküldése meglehetősen könnyű feladat:
ellington#
cd /var/yp
ellington#
make
Ez a parancs létrehoz három NIS
táblázatot: netgroup
,
netgroup.byhost
és
netgroup.byuser
. Az ypcat(1)
paranccsal ellenőrizni is tudjuk az új NIS
táblázatainkat:
ellington%
ypcat -k netgroup
ellington%
ypcat -k netgroup.byhost
ellington%
ypcat -k netgroup.byuser
Az első parancs kimenete a
/var/yp/netgroup
állomány
tartalmára emlékeztethet minket. A második
parancsnak nincs semmilyen kimenete, hacsak nem adtunk meg
valamilyen gépfüggő hálózati
csoportot. A harmadik parancs a hálózati
csoportokat listázza ki a
felhasználókhoz.
A kliensek beállítása tehát
nagyon egyszerű. A haboru
nevű
szerver beállításához
indítsuk el a vipw(8) programot, és
cseréljük a
+:::::::::
sort erre:
+@IT_DOLG:::::::::
Innentől kezdve kizárólag csak az
IT_DOLG
csoportban található
felhasználók fognak bekerülni a
haboru
jelszó
adatbázisába, és csak ezek a
felhasználók tudnak ide bejelentkezni.
Sajnos ez a korlátozás a
parancsértelmező ~
funkciójára és összes olyan rutinra is
vonatkozik, amelyet a felhasználói nevek és
azok numerikus azonosító között
képez le. Más szóval a cd
~felhasználó
parancs nem fog működni, és az ls
-l
parancs kimenetében a
felhasználói nevek helyett csak numerikus
azonosítók jelennek meg, továbbá
afind . -user joe -print
No such
user (Nincs ilyen
felhasználó) hibát fog
visszaadni. Ez úgy tudjuk megjavítani, ha
úgy importáljuk a szerverre az összes
felhasználó bejegyzését, hogy
közben tiltjuk a
hozzáférésüket.
Ehhez vegyünk fel egy újabb sort az
/etc/master.passwd
állományba. A sor valahogy így fog
kinézni:
+:::::::::/sbin/nologin
, amely annyit
tesz, hogy „importáljuk az összes
bejegyzést, de a hozzájuk tartozó
parancsértelmező a
/sbin/nologin
legyen”. A
passwd
állományban
tetszőleges mező tartalmát le tudjuk úgy
cserélni, ha megadunk neki egy alapértelmezett
értéket az /etc/master.passwd
állományban.
Vigyázzunk, hogy a
+:::::::::/sbin/nologin
sort az
+@IT_DOLG:::::::::
sor után
írjuk. Ha nem így teszünk, akkor a
NIS-ből importált összes
felhasználói hozzáférés a
/sbin/nologin
parancsértelmezőt kapja.
Miután elvégeztük ezt a
változtatást, minden újabb dolgozó
felvétele után csupán egyetlen
táblázatot kell megváltoztatnunk. Ugyanezt
a taktikát követhetjük a kevésbé
fontosabb szerverek esetében is, hogy ha a helyi
/etc/master.passwd
állományukban a korábbi
+:::::::::
bejegyzést valami
ilyesmivel helyettesítjük:
+@IT_DOLG::::::::: +@IT_UJDOLG::::::::: +:::::::::/sbin/nologin
Az egyszerű munkaállomások esetében pedig ezekre a sorokra lesz szükségünk:
+@IT_DOLG::::::::: +@FELHASZNALOK::::::::: +:::::::::/sbin/nologin
Minden remekül üzemel egészen addig,
amíg néhány hét múlva
ismét változik a házirend: az IT
tanszékre ösztöndíjasok érkeznek.
Az IT ösztöndíjasai a
munkaállomásokat és a kevésbé
fontosabb szervereket tudják használni. Az
új IT dolgozók már a központi
szerverekre is bejelentkezhetnek. Így tehát
létrehozunk egy új hálózati
csoportot IT_OSZTONDIJAS
néven, majd
felvesszük ide az új IT
ösztöndíjasokat, és nekilátunk
végigzongorázni az összes gép
összes konfigurációs
állományát... Ahogy azonban egy
régi mondás is tartja: „A
központosított tervezésben ejtett
hibák teljes káoszhoz vezetnek”.
A NIS az ilyen helyzeteket úgy igyekszik
elkerülni, hogy megengedi újabb
hálózati csoportok
létrehozását más
hálózati csoportokból. Egyik ilyen
lehetőség a szerep alapú
hálózati csoportok kialakítása.
Például, ha a fontosabb szerverek
bejelentkezési korlátozásai
számára hozzunk létre egy
NAGYSRV
nevű csoportot, valamint egy
másik hálózati csoportot
KISSRV
néven a kevésbé
fontosabb szerverekhez, végül
MUNKA
néven egy harmadik
hálózati csoportot a
munkaállomásokhoz. Mindegyik ilyen
hálózati csoport tartalmazza azokat a csoportokat,
amelyek engedélyezik a gépek
elérését. A hálózati
csoportok leírását tartalmazó NIS
táblázat most valahogy így fog
kinézni:
NAGYSRV IT_DOLG IT_UJDOLG KISSRV IT_DOLG IT_UJDOLG IT_OSZTONDIJAS MUNKA IT_DOLG IT_OSZTONDIJAS FELHASZNALOK
A bejelentkezési megszorítások ilyen típusú megadása viszonylag jól működik, hogy ha azonos korlátozások alá eső gépek csoportjait akarjuk felírni. Bánatunk ez a kivétel, és nem a szabály. Az esetek nagy többségében ugyanis a bejelentkezésre vonatkozó korlátozásokat gépenként kell egyesével megadni.
A hálózati csoportok gépfüggő
megadása tehát az iménti házirendhez
társuló igények
kielégítésének egyik módja.
Ebben a forgatókönyvben az
/etc/master.passwd
állomány
minden számítógépen két
„+”-os sorral kezdődik.
Közülük az első a gépen
engedélyezett hozzáféréseket
tartalmazó hálózati csoportra vonatkozik, a
második pedig az összes többi
hozzáféréshez az
/sbin/nologin
parancsértelmezőt
kapcsolja hozzá. Itt jó ötlet, ha a
gép nevének
„VÉGIG-NAGYBETűS”
változatát adjuk meg a hozzá tartozó
hálózati csoport nevének:
+@GÉPNÉV
:::::::::
+:::::::::/sbin/nologin
Miután elvégeztük ezt a feladatot minden
egyes gépen, az /etc/master.passwd
állomány helyi változatait soha
többé nem kell módosítanunk. Az
összes többi változtatást a NIS
táblázaton keresztül tudjuk keresztül
vinni. Íme a felvázolt
forgatókönyvhöz tartozó
hálózati csoportok
kiépítésének egyik lehetséges
változata, egy-két finomsággal
kiegészítve:
# Először a felhasználók csoportjait adjuk meg: IT_DOLG (,alpha,proba-tartomany) (,beta,proba-tartomany) IT_UJDOLG (,charlie,proba-tartomany) (,delta,proba-tartomany) TANSZ1 (,echo,proba-tartomany) (,foxtrott,proba-tartomany) TANSZ2 (,golf,proba-taromany) (,hotel,proba-tartomany) TANSZ3 (,india,proba-taromany) (,juliet,proba-tartomany) IT_OSZTONDIJAS (,kilo,proba-tartomany) (,lima,proba-tartomany) D_OSZTONDIJAS (,able,proba-tartomany) (,baker,proba-tartomany) # # Most pedig hozzunk létre csoportokat szerepek szerint: FELHASZNALOK TANSZ1 TANSZ2 TANSZ3 NAGYSRV IT_DOLG IT_UJDOLG KISSRV IT_DOLG IT_UJDOLG IT_OSZTONDIJAS MUNKA IT_DOLG IT_OSZTONDIJAS FELHASZNALOK # # Következzenek a speciális feladatokhoz tartozó csoportok: # Az echo és a golf tudja elérni a vírusvédelemért felelős gépet: VEDELEM IT_DOLG (,echo,proba-tartomany) (,golf,proba-tartomany) # # Gép alapú hálózati csoportok # A fő szervereink: HABORU NAGYSRV EHSEG NAGYSRV # Az india nevű felhasználó hozzá szeretné ehhez férni: SZENNYEZES NAGYSRV (,india,proba-tartomany) # # Ez valóban fontos és komolyan szabályoznunk kell: HALAL IT_DOLG # # Az előbb említett vírusvédelmi gép: EGY VEDELEM # # Egyetlen felhasználóra korlátozzuk le ezt a gépet: KETTO (,hotel,proba-tartomany) # [...és itt folytatódik a többi csoporttal]
Ha a felhasználói hozzáféréseinket valamilyen adatbázisban tároljuk, akkor a táblázat első részét akár az adatbázis lekérdezésein keresztül is elő tudjuk állítani. Ezzel a módszerrel az új felhasználók automatikusan hozzáférnek a gépekhez.
Legyünk viszont óvatosak: nem mindig javasolt gépeken alapuló hálózati csoportokat készíteni. Ha a hallgatói laborokba egyszerre több tucat vagy akár több száz azonos konfigurációjú gépet telepítünk, akkor a gép alapú csoportok helyett inkább szerep alapú csoportokat építsünk fel, mivel így a NIS táblázatok méretét egy elfogadható méreten tudjuk tartani.
Még mindig akad néhány olyan dolog, amit másképpen kell csinálnunk azután, hogy most már NIS környezetben vagyunk.
Amikor egy új felhasználót akarunk
felvenni a laborba, akkor csak a
központi NIS szerverre kell felvennünk, és
újra kell generáltatnunk a NIS
táblázatokat. Ha ezt
elfelejtjük megtenni, akkor az új
felhasználó a központi NIS szerveren
kívül sehova sem lesz képes
bejelentkezni. Például, ha fel akarjuk venni
a jsmith
nevű
felhasználót a laborba, akkor ezt kell
tennünk:
#
pw useradd jsmith
#
cd /var/yp
#
make proba-tartomany
Vagy a pw useradd jsmith
parancs
helyett az adduser jsmith
parancsot is
használhatjuk.
A rendszergazdai szintű hozzáféréseket ne tároljuk a NIS táblázatokban. Olyan gépekre egyáltalán ne is küldjünk olyan karbantartáshoz használt hozzáféréseket, amelynek a felhasználói hivatalosan nem is férhetnének hozzájuk.
A központi NIS szervert és az alárendelt szervereket óvjuk minél jobban, és igyekezzünk minimalizálni a kieséseiket. Ha valaki feltöri vagy egyszerűen csak kikapcsolja ezeket a gépeket, akkor ezzel lényegében mindenkit megakadályoz abban, hogy be tudjon jelentkezni a laborban.
Ezek a központosított vezérlésű rendszerek legfőbb gyengeségei. Ha nem védjük kellően a NIS szervereinket, akkor azzal nagyon ellenséget szerezhetünk magunknak!
A FreeBSD-ben megtalálható ypserv szolgáltatás valamennyire képes ellátni a NIS első változatát használó klienseket is. A FreeBSD NIS implementációja csak a NIS v2 protokollt használja, azonban mivel más implementációk kompatibilisek kívánnak maradni a régebbi rendszerekkel, ismerik a v1 protokollt is. Az ilyen rendszerekhez tartozó ypbind démonok még olyankor is megpróbálnak v1-es NIS szerverekhez kötést létrehozni, amikor valójában nincs is rá szükségük (és gyakran még akkor is ilyet keresnek, amikor az üzenetükre már válaszolt egy v2-es szerver). Hozzátennénk, hogy bár az ypserver ezen változata a normál klienshívásokat képes feldolgozni, a táblázatokat már nem tudja átküldeni a v1-es klienseknek. Ebből következik, hogy a központi vagy alárendelt szerverek nem tudnak együttműködni olyan NIS szerverekkel, amelyek csak a v1-es protokollt beszélik. Szerencsére ilyen szervereket manapság már alig használnak.
Óvatosan kell bánnunk az ypserv elindításával olyan többszerveres tartományokban, ahol a szerverek maguk is NIS kliensek. Alapvetően nincs abban semmi kivetnivaló, ha a szervereket saját magukhoz kötjük ahelyett, hogy engednénk nekik a kötési kérések küldését és így egymáshoz kötnénk ezeket. Különös hibák tudnak származni olyan helyzetekben, amikor az egyik szerver leáll, miközben a többiek pedig függenek tőle. Végül is ilyenkor minden kliens szépen kivárja a szükséges időt, aztán megpróbál más szerverekhez kötődni, de az itt fellépő késlekedés jelentős mennyiségű lehet, és ez a hibajelenség ismét fennállhat, mivel előfordulhat, hogy a szerverek megint egymáshoz kapcsolódnak.
A klienst úgy tudjuk egy adott szerverhez kötni,
ha az ypbind
parancsot a -S
beállítással indítjuk. Ha mindezt
nem akarjuk manuálisan megtenni a NIS szerver minden
egyes újraindításakor, akkor vegyük
fel a következő sorokat az
/etc/rc.conf
állományba:
nis_client_enable="YES" # elindítjuk a klienst is nis_client_flags="-SNIS tartomány
,szerver
"
Részletesebb lásd az ypbind(8) man oldalát.
A NIS rendszerek kiépítése során az emberek leggyakrabban a jelszavak formátumával kapcsolatban tapasztalnak nehézségeket. Ha a szerverünk DES titkosítású jelszavakat használ, akkor csak olyan klienseket fog tudni támogatni, amelyek szintén így kódolják ezeket. Például, ha a hálózaton vannak Solaris™ rendszerű NIS klienseink, akkor szinte biztos, hogy DES titkosítást kell használnunk.
A szerverek és a kliensek által
használt formátumokat az
/etc/login.conf
állományba
tekintve deríthetjük ki. Ha a gépek
többségén a DES titkosítást
látjuk, akkor a default
osztálynak egy ilyen bejegyzést kell
tartalmaznia:
default:\ :passwd_format=des:\ :copyright=/etc/COPYRIGHT:\ [a többit most nem mutatjuk]
A passwd_format
tulajdonság
további lehetséges értékei lehetnek
a blf
és az md5
(melyek rendre a Blowfish és MD5
titkosítású jelszavakat adják
meg).
Ha változtattunk valamit az
/etc/login.conf
állományban,
akkor a bejelentkezési tulajdonságok
adatbázisát is újra kell generálni,
melyet root
felhasználóként a következő
módon tehetünk meg:
#
cap_mkdb /etc/login.conf
Az /etc/master.passwd
állományban jelenlevő jelszavak
formátuma azonban nem frissítődik
egészen addig, amíg a felhasználók
a bejelentkezési adatbázis
újragenerálása
után meg nem
változtatják a jelszavaikat.
Úgy tudjuk még biztosítani, hogy a
jelszavak megfelelő formátumban
kódolódjanak, ha az
/etc/auth.conf
állományban
megkeressük a crypt_default
sort,
amelyben a választható
jelszóformátumok
felhasználásái sorrendjét
találhatjuk meg. Itt tehát mindössze annyit
kell tennünk, hogy a kiszemelt formátumot a lista
elejére tesszük. Például, ha a DES
titkosítású jelszavakat akarunk
használni, akkor ez a bejegyzés így fog
kinézni:
crypt_default = des blf md5
Ha a fenti lépéseket követjük az összes FreeBSD alapú NIS szervernél és kliensnél, akkor biztosra mehetünk abban, hogy a hálózatunkon belül ugyanazt a jelszóformátumot fogják használni. Ha gondunk akadna a NIS kliensek hitelesítésével, akkor itt érdemes kezdeni a hiba felderítését. Ne felejtsük: ha egy NIS szervert egy heterogén hálózatba akarunk telepíteni, akkor valószínűleg az összes rendszeren a DES titkosítást kell választani, mivel általában ez a közös nevező ebben a tekintetben.
Ha kérdése van a FreeBSD-vel kapcsolatban, a
következő címre írhat (angolul):
<questions@FreeBSD.org>.
Ha ezzel a dokumentummal kapcsolatban van kérdése, kérjük erre a címre írjon:
<gabor@FreeBSD.org>.