FreeBSD kézikönyv
Előző | Fejezet 29. Hálózati szerverek | Következő

# 29.3. A hálózati állományrendszer (NFS)

Átdolgozta és javította: Tom Rhodes. Írta: Bill Swingle.

A FreeBSD több állományrendszert ismer, köztük a hálózati állományrendszert (Network File System, NFS) is. Az NFS állományok és könyvtárak megosztását teszi lehetővé a hálózaton keresztül. Az NFS használatával a felhasználók és a programok képesek majdnem úgy elérni a távoli rendszereken található állományokat, mintha helyben léteznének.

Íme az NFS néhány legjelentősebb előnye:

- A helyi munkaállomások kevesebb tárterületet használnak, mivel a közös adatokat csak egyetlen számítógépen tároljuk és megosztjuk mindenki között.

- A felhasználóknak nem kell a hálózat minden egyes gépén külön felhasználói könyvtárral rendelkezniük. Ezek ugyanis az NFS segítségével akár egy szerveren is beállíthatóak és elérhetővé tehetőek a hálózaton keresztül.

- A különböző háttértárak, mint például a floppy lemezek, CD-meghajtók és Zip® meghajtók a hálózaton több számítógép között megoszthatóak. Ezzel csökkenteni tudjuk a hálózatunkban szükséges cserélhető lemezes eszközök számát.

## 29.3.1. Ahogy az NFS működik

Az NFS legalább két fő részből rakható össze: egy szerverből és egy vagy több kliensből. A kliensek a szerver által megosztott adatokhoz képesek távolról hozzáférni. A megfelelő működéshez mindössze csak néhány programot kell beállítani és futtatni.

A szervernek a következő démonokat kell működtetnie:

Démon | Leírás
--- | ---
nfsd | Az NFS démon, amely kiszolgálja az NFS kliensektől érkező kéréseket.
mountd | Az NFS csatlakoztató démonja, amely végrehajtja az nfsd(8) által átküldött kéréseket.
rpcbind | Ez a démon lehetővé teszi az NFS kliensek számára, hogy fel tudják deríteni az NFS szerver által használt portot.

A kliensen is futnia kell egy démonnak, amelynek a neve nfsiod. Az nfsiod démon az NFS szerver felől érkező kéréseket szolgálja ki. A használata teljesen opcionális, csupán a teljesítményt hívatott javítani, de a normális és helyes működéshez nincs rá szükségünk. Az nfsiod(8) man oldalán erről többet is megtudhatunk.

## 29.3.2. Az NFS beállítása

Az NFS beállítása viszonylag egyértelműen adja magát. A működéséhez szükséges programok automatikus elindítása csupán néhány apró módosítást igényel az `/etc/rc.conf` állományban.

Az NFS szerveren gondoskodjunk róla, hogy az alábbi beállítások szerepeljenek az `/etc/rc.conf` állományban:

    rpcbind_enable="YES"
    nfs_server_enable="YES"
    mountd_flags="-r"

A mountd magától el fog indulni, ha az NFS szervert engedélyezzük.

A kliensen a következő beállítást kell felvennünk az `/etc/rc.conf` állományba:

    nfs_client_enable="YES"

Az `/etc/exports` állomány adja meg, hogy az NFS milyen állományrendszereket exportáljon (vagy másképpen szólva “osszon meg”). Az `/etc/exports` állományban tehát a megosztani kívánt állományrendszereket kell szerepeltetnünk, és azt, hogy melyik számítógépekkel tudjuk ezeket elérni. A gépek megnevezése mellett a hozzáférésre további megszorításokat írhatunk fel. Ezek részletes leírását az exports(5) man oldalon találjuk meg.

Lássunk néhány példát az `/etc/exports` állományban megjelenő bejegyzésekre:

A most következő példákban az állományrendszerek exportálásának finomságait igyekszünk érzékeltetni, noha a konkrét beállítások gyakran a rendszerünktől és a hálózati konfigurációtól függenek. Például, ha a `/cdrom` könytárat akarjuk három gép számára megosztani, akik a szerverrel megegyező tartományban találhatóak (ezért nem is kell megadnunk a tartományt) vagy mert egyszerűen megtalálhatók az `/etc/hosts` állományunkban. Az `-ro` beállítás az exportált állományrendszereket írásvédetté teszi. Ezzel a beállítással a távoli rendszerek nem lesznek képesek módosítani az exportált állományrendszer tartalmát.

    /cdrom -ro gép1 gép2 gép3

A következő sorban a `/home` könyvtárat három gép számára osztjuk meg, melyeket IP-címekkel adtunk meg. Ez olyan helyi hálózat esetén hasznos, ahol nem állítottunk be névfeloldást. Esetleg a belső hálózati neveket az `/etc/hosts` állományban is tárolhatjuk. Ezzel utóbbival kapcsolatban a hosts(5) man oldalt érdemes fellapoznunk. Az `-alldirs` beállítás lehetővé teszi, hogy az alkönyvtárak is csatlakozási pontok lehessenek. Más szóval, nem fogja csatlakoztatni az alkönyvtárakat, de megengedi a kliensek számára, hogy csak azokat a könyvtárakat csatlakoztassák, amelyeket kell vagy amelyekre szükségünk van.

    /home  -alldirs  10.0.0.2 10.0.0.3 10.0.0.4

A következő sorban az `/a` könyvtárat úgy exportáljuk, hogy az állományrendszerhez két különböző tartományból is hozzá lehessen férni. A `-maproot=root` beállítás hatására a távoli rendszer `root` felhasználója az exportált állományrendszeren szintén `root` felhasználóként fogja írni az adatokat. Amennyiben a `-maproot=root` beállítást nem adjuk meg, akkor a távoli rendszeren hiába `root` az adott felhasználó, az exportált állományrendszeren nem lesz képes egyetlen állományt sem módosítani.

    /a  -maproot=root  gep.minta.com doboz.haz.org

A kliensek is csak a megfelelő engedélyek birtokában képesek elérni a megosztott állományrendszereket. Ezért a klienst ne felejtsük el felvenni a szerver `/etc/exports` állományába.

Az `/etc/exports` állományban az egyes sorok az egyes állományrendszerekre és az egyes gépekre vonatkoznak. A távoli gépek állományrendszerenként csak egyszer adhatóak meg, és csak egy alapértelmezett bejegyzésük lehet. Például tegyük fel, hogy a `/usr` egy önálló állományrendszer. Ennek megfelelően az alábbi bejegyzések az `/etc/exports` állományban érvénytelenek:

    # Nem használható, ha a /usr egy állományrendszer:
    /usr/src   kliens
    /usr/ports kliens

Egy állományrendszerhez, vagyis itt a `/usr` partícióhoz, két export sort is megadtunk ugyanahhoz a `kliens` nevű géphez. Helyesen így kell megoldani az ilyen helyzeteket:

    /usr/src /usr/ports  kliens

Az adott géphez tartozó egy állományrendszerre vonatkozó exportoknak mindig egy sorban kell szerepelniük. A kliens nélkül felírt sorok egyetlen géphez tartozónak fognak számítani. Ezzel az állományrendszerek megosztását tudjuk szabályozni, de legtöbbek számára nem jelent gondot.

Most egy érvényes exportlista következik, ahol a `/usr` és az `/exports` mind helyi állományrendszerek:

    # Osszuk meg az src és ports könyvtárakat a kliens01 és kliens02 részére, de csak a
    # kliens01 férhessen hozzá rendszeradminisztrátori jogokkal:
    /usr/src /usr/ports -maproot=root    kliens01
    /usr/src /usr/ports               kliens02
    # A kliensek az /exports könyvtárban teljes joggal rendelkeznek és azon belül
    # bármit tudnak csatlakoztatni. Rajtuk kívül mindenki csak írásvédetten képes
    # elérni az /exports/obj könyvtárat:
    /exports -alldirs -maproot=root      kliens01 kliens02
    /exports/obj -ro

A mountd démonnal az `/etc/exports` állományt minden egyes módosítása után újra be kell olvastatni, mivel a változtatásaink csak így fognak érvényesülni. Ezt megcsinálhatjuk úgy is, hogy küldünk egy HUP (hangup, avagy felfüggesztés) jelzést a már futó démonnak:

    # kill -HUP `cat /var/run/mountd.pid`

vagy meghívjuk a `mountd` rc(8) szkriptet a megfelelő paraméterrel:

    # /etc/rc.d/mountd onereload

Az 11.7 Szakaszban tudhatunk meg részleteket az rc szkriptek használatáról.

Ezek után akár a FreeBSD újraindításával is aktiválhatjuk a megosztásokat, habár ez nem feltétlenül szükséges. Ha `root` felhasználónként kiadjuk a következő parancsokat, akkor azzal minden szükséges programot elindítunk.

Az NFS szerveren tehát:

    # rpcbind
    # nfsd -u -t -n 4
    # mountd -r

Az NFS kliensen pedig:

    # nfsiod -n 4

Ezzel most már minden készen áll a távoli állományrendszer csatlakoztatására. A példákban a szerver neve `szerver` lesz, valamint a kliens neve `kliens`. Ha csak ideiglenesen akarunk csatlakoztatni egy állományrendszert vagy egyszerűen csak ki akarjuk próbálni a beállításainkat, a kliensen `root` felhasználóként az alábbi parancsot hajtsuk végre:

    # mount szerver:/home /mnt

Ezzel a szerveren található `/home` könyvtárat fogjuk a kliens `/mnt` könyvtárába csatlakoztatni. Ha mindent jól beállítottunk, akkor a kliensen most már be tudunk lépni az `/mnt` könyvtárba és láthatjuk a szerveren található állományokat.

Ha a számítógép indításával automatikusan akarunk hálózati állományrendszereket csatlakoztatni, akkor vegyük fel ezeket az `/etc/fstab` állományba. Erre íme egy példa:

    szerver:/home	/mnt	nfs	rw	0	0

Az fstab(5) man megtalálhatjuk az összes többi beállítást.

## 29.3.3. Zárolások

Bizonyos alkalmazások (például a mutt) csak akkor működnek megfelelően, ha az állományokat a megfelelő módon zárolják. Az NFS esetében az rpc.lockd használható az ilyen zárolások megvalósítására. Az engedélyezéséhez mind a szerveren és a kliensen vegyük fel a következő sort az `/etc/rc.conf` állományba (itt már feltételezzük, hogy az NFS szervert és klienst korábban beállítottuk):

    rpc_lockd_enable="YES"
    rpc_statd_enable="YES"

A következő módon indíthatjuk el:

    # /etc/rc.d/lockd start
    # /etc/rc.d/statd start

Ha nincs szükségünk valódi zárolásra az NFS kliensek és az NFS szerver között, akkor megcsinálhatjuk azt is, hogy az NFS kliensen a mount_nfs(8) programnak az `-L` paraméter átadásával csak helyileg végzünk zárolást. Ennek további részleteről a mount_nfs(8) man oldalon kaphatunk felvilágosítást.

## 29.3.4. Gyakori felhasználási módok

Az NFS megoldását a gyakorlatban rengeteg esetben alkalmazzák. Ezek közül most felsoroljuk a legelterjedtebbeket:

- Több gép között megosztunk egy telepítőlemezt vagy más telepítőeszközt. Ez így sokkal olcsóbb és gyakorta kényelmes megoldás abban az esetben, ha egyszerre több gépre akarjuk ugyanazt a szoftvert telepíteni.

- Nagyobb hálózatokon sokkal kényelmesebb lehet egy központi NFS szerver használata, ahol a felhasználók könyvtárait tároljuk. Ezek a felhasználói könyvtárak aztán megoszthatóak a hálózaton keresztül, így a felhasználók mindig ugyanazt a könyvárat kapják függetlenül attól, hogy milyen munkaállomásról is jelentkeztek be.

- Több géppel is képes így osztozni az `/usr/ports/distfiles` könyvtáron. Ezen a módon sokkal gyorsabban tudunk portokat telepíteni a gépekre, mivel nem kell külön mindegyikre letölteni az ehhez szükséges forrásokat.

## 29.3.5. Automatikus csatlakoztatás az amd használatával

Készítette: Wylie Stilwell. Újraírta: Chern Lee.

Az amd(8) (automatikus csatlakoztató démon, az automatic mounter daemon) önműködően csatlakoztatja a távoli állományrendszereket, amikor azokon belül valamelyik állományhoz vagy könyvtárhoz próbálunk hozzáférni. Emellett az amd az egy ideje már inaktív állományrendszereket is automatikusan leválasztja. Az amd használata egy remek alternatívát kínál az általában az `/etc/fstab` állományban megjelenő állandóan csatlakoztatott állományrendszerekkel szemben.

Az amd úgy működik, hogy kapcsolódik egy NFS szerver `/host` és `/net` könyvtáraihoz. Amikor egy állományt akarunk elérni ezeken a könyvtárakon belül, az amd kikeresi a megfelelő távoli csatlakoztatást és magától csatlakoztatja. A `/net` segítségével egy IP-címről tudunk exportált állományrendszereket csatlakoztatni, miközben a `/host` a távoli gép hálózati neve esetében használatos.

Ha tehát a `/host/izemize/usr` könyvtárban akarunk elérni egy állományt, akkor az amd démonnak ahhoz először az `izemize` nevű gépről exportált `/usr` könyvtárat kell csatlakoztatnia.

Példa 29-2. Egy exportált állományrendszer csatlakoztatása az amd használatával

Egy távoli számítógép által rendelkezésre bocsátott megosztásokat a `showmount` paranccsal tudjuk lekérdezni. Például az `izemize` gépen elérhető exportált állományrendszereket így láthatjuk:

    % showmount -e izemize
    Exports list on izemize:
    /usr                               10.10.10.0
    /a                                 10.10.10.0
    % cd /host/izemize/usr

Ahogy a példában látjuk is, a `showmount` parancs a `/usr` könyvtárat mutatja megosztásként. Amikor tehát belépünk a `/host/izemize/usr` könyvtárba, akkor amd magától megpróbálja feloldani az `izemize` hálózati nevet és csatlakoztatni az elérni kívánt exportált állományrendszert.

Az amd az indító szkripteken keresztül az `/etc/rc.conf` alábbi beállításával engedélyezhető:

    amd_enable="YES"

Emellett még az `amd_flags` használatával további paraméterek is átadható az amd felé. Alapértelmezés szerint az `amd_flags` tartalmaz az alábbi:

    amd_flags="-a /.amd_mnt -l syslog /host /etc/amd.map /net /etc/amd.map"

Az `/etc/amd.map` állomány adja meg az exportált állományrendszerek alapértelmezett beállításait. Az `/etc/amd.conf` állományban az amd további lehetőségeit konfigurálhatjuk..

Ha többet is szeretnénk tudni a témáról, akkor az amd(8) és az amd.conf(5) man oldalakat javasolt elolvasnunk.

## 29.3.6. Problémák más rendszerek használatakor

Készítette: John Lind.

Némely PC-s ISA buszos Ethernet kártyákra olyan korlátozások érvényesek, melyek komoly hálózati problémák keletkezéséhez vezethetnek, különösen az NFS esetében. Ez a nehézség nem FreeBSD-függő, de a FreeBSD rendszereket is érinti.

Ez gond általában majdnem mindig akkor merül fel, amikor egy (FreeBSD-s) PC egy hálózatba kerül többek közt a Silicon Graphic és a Sun Microsystems által gyártott nagyteljesítményű munkaállomásokkal. Az NFS csatlakoztatása és bizonyos műveletek még hibátlanul végrehajtódnak, azonban hirtelen a szerver látszólag nem válaszol többet a kliens felé úgy, hogy a többi rendszertől folyamatosan dolgozza felfele a kéréseket. Ez a kliens rendszeren tapasztalható csak, amikor a kliens FreeBSD vagy egy munkaállomás. Sok rendszeren egyszerűen rendesen le sem lehet állítani a klienst, ha a probléma egyszer már felütötte a fejét. Egyedüli megoldás gyakran csak a kliens újraindítása marad, mivel az NFS-ben kialakult helyzetet máshogy nem lehet megoldani.

Noha a “helyes” megoldás az lenne, ha beszereznénk egy nagyobb teljesítményű és kapacitású kártyát a FreeBSD rendszer számára, azonban egy jóval egyszerűbb kerülőút is található a kielégítő működés eléréséhez. Ha a FreeBSD rendszer képviseli a szervert, akkor a kliensnél adjuk meg a `-w=1024` beállítást is a csatlakoztatásnál. Ha a FreeBSD rendszer a kliens szerepét tölti be, akkor az NFS állományrendszert az `-r=1024` beállítással csatlakoztassuk róla. Ezek a beállítások az `fstab` állomány negyedik mezőjében is megadhatóak az automatikus csatlakoztatáshoz, vagy manuális esetben a mount(8) parancsnak a `-o` paraméterrel.

Hozzá kell azonban tennünk, hogy létezik egy másik probléma, amit gyakran ezzel tévesztenek össze, amikor az NFS szerverek és kliensek nem ugyanabban a hálózatban találhatóak. Ilyen esetekben mindenképpen győződjünk meg róla, hogy az útválasztók rendesen továbbküldik a működéshez szükséges UDP információkat, különben nem sokat tudunk tenni a megoldás érdekében.

A most következő példákban a `gyorsvonat` lesz a nagyteljesítményű munkaállomás (felület) neve, illetve a `freebsd` pedig a gyengébb teljesítményű Ethernet kártyával rendelkező FreeBSD rendszer (felület) neve. A szerveren az `/osztott` nevű könyvtárat fogjuk NFS állományrendszerként exportálni (lásd exports(5)), amelyet majd a `/projekt` könyvtárba fogunk csatlakoztatni a kliensen. Minden esetben érdemes lehet még megadnunk a `hard` vagy `soft`, illetve `bg` opciókat is.

Ebben a példában a FreeBSD rendszer (`freebsd`) lesz a kliens, és az `/etc/fstab` állományában így szerepel az exportált állományrendszer:

    gyorsvonat:/osztott /projekt nfs rw,-r=1024 0 0

És így tudjuk manuálisan csatlakoztatni:

    # mount -t nfs -o -r=1024 gyorsvonat:/osztott /projekt

Itt a FreeBSD rendszer lesz a szerver, és a `gyorsvonat` `/etc/fstab` állománya így fog kinézni:

    freebsd:/osztott /projekt nfs rw,-w=1024 0 0

Manuálisan így csatlakoztathatjuk az állományrendszert:

    # mount -t nfs -o -w=1024 freebsd:/osztott /projekt

Szinte az összes 16 bites Ethernet kártya képes működni a fenti írási vagy olvasási korlátozások nélkül is.

A kíváncsibb olvasók számára eláruljuk, hogy pontosan miért is következik be ez a hiba, ami egyben arra is magyarázatot ad, hogy miért nem tudjuk helyrehozni. Az NFS általában 8 kilobyte-os “blokkokkal” dolgozik (habár kisebb méretű darabkákat is tud készíteni). Mivel az Ethernet által kezelt legnagyobb méret nagyjából 1500 byte, ezért az NFS “blokkokat” több Ethernet csomagra kell osztani -- még olyankor is, ha ez a program felsőbb rétegeiben osztatlan egységként látszik -- ezt aztán fogadni kell, összerakni és nyugtázni mint egységet. A nagyteljesítményű munkaállomások a szabvány által még éppen megengedett szorossággal képesek ontani magukból az egy egységhez tartozó csomagokat, közvetlenül egymás után. A kisebb, gyengébb teljesítményű kártyák esetében azonban az egymáshoz tartozó, később érkező csomagok ráfutnak a korábban megkapott csomagokra még pontosan azelőtt, hogy elérnék a gépet, így az egységek nem állíthatóak össze vagy nem nyugtázhatóak. Ennek eredményeképpen a munkaállomás egy adott idő múlva megint próbálkozik, de ismét az egész 8 kilobyte-os blokkot küldi el, ezért ez a folyamat a végtelenségig ismétlődik.

Ha a küldendő egységek méretét az Ethernet által kezelt csomagok maximális mérete alá csökkentjük, akkor biztosak lehetünk benne, hogy a teljes Ethernet csomag egyben megérkezik és nyugtázódik, így elkerüljük a holtpontot.

A nagyteljesítményű munkaállomások természetesen továbbra is küldhetnek a PC-s rendszerek felé túlfutó csomagokat, de egy jobb kártyával az ilyen túlfutások nem érintik az NFS által használt “egységeket”. Amikor egy ilyen túlfutás bekövetkezik, az érintett egységet egyszerűen újra elküldik, amelyet a rákövetkező alkalommal nagy valószínűséggel már tudunk rendesen fogadni, összerakni és nyugtázni.

Előző | Tartalom | Következő
Az inetd “szuperszerver” | Fel | Hálózati információs rendszer (NIS/YP)

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