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.
Megjegyzés: 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.
Megjegyzés: 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).
Megjegyzés: 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:
+:::::::::
Megjegyzés: 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.
Megjegyzés: 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.
Megjegyzés: Az elérési útvonala megadható a
-popció 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.
Megjegyzés: 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.
Megjegyzés: 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 NAGYCSP3Ugyanez 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.
Figyelem: 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="-S NIS 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
Megjegyzés: 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): <freebsd-questions@FreeBSD.org>.
Ha ezzel a dokumentummal kapcsolatban van kérdése,
kérjük erre a címre írjon: <gabor@FreeBSD.org>.