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

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:

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

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.

% 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

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.