29.4. Hálózati információs rendszer (NIS/YP)
Vissza | 29. fejezet - Hálózati szerverek | Előre

## 29.4. Hálózati információs rendszer (NIS/YP)

Írta: Swingle, Bill.
Írta: Ogren, Eric és Erdelhoff, Udo.

### 29.4.1. Mi ez?

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.

### 29.4.2. A témához tartozó fogalmak és programok

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.

### 29.4.3. Hogyan működik?

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.

#### 29.4.3.1. A gépek típusai

- 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.

### 29.4.4. A NIS/YP használata

Ebben a szakaszban egy példa NIS környezetet állítunk be.

#### 29.4.4.1. Tervezés

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.

##### 29.4.4.1.1. A NIS tartománynév megválasztása

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.

##### 29.4.4.1.2. A szerverek fizikai elvárásai

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.

#### 29.4.4.2. A NIS szerverek

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.

##### 29.4.4.2.1. A központi NIS szerver beállítása

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.

1.     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`.

2.     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.

3.     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

##### 29.4.4.2.2. A NIS táblázatok inicializálása

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).

##### 29.4.4.2.3. Az alárendelt NIS szerverek beállítása

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.

#### 29.4.4.3. A NIS kliensek

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.

##### 29.4.4.3.1. A NIS kliensek beállítása

Egy FreeBSD-s gépet NIS kliensként meglehetősen egyszerűen lehet beállítani.

1. 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"

2. 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.

3. 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.

### 29.4.5. A NIS biztonsága

Á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 `-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.

### 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.

### 29.4.6. Egyes felhasználók bejelentkezésének megakadályozása

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#

### 29.4.7. A hálózati csoportok alkalmazása

Készítette: Erdelhoff, Udo.

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ő:

1. 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.

2. A csoporthoz tartozó hozzáférés neve.

3. 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 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á a`find . -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.

### 29.4.8. Amit feltétlenül észben kell tartanunk

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!

### 29.4.9. Kompatibilitás a NIS első változatával

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.

### 29.4.10. NIS szerverek, melyek egyben NIS kliensek

Ó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.

### 29.4.11. A jelszavak formátuma

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.

Vissza | Fel | Előre
29.3. A hálózati állományrendszer (NFS) | Főoldal | 29.5. A hálózat automatikus beállítása (DHCP)

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>.