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.
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.
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.
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.
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.
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.
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.
Ha kérdése van a FreeBSD-vel kapcsolatban, a következő
címre írhat (angolul): <[email protected]>.
Ha ezzel a dokumentummal kapcsolatban van kérdése,
kérjük erre a címre írjon: <[email protected]>.