29. Fejezet - Hálózati szerverek

Az inetd(8) démont gyakran csak "internet szuperszerverként" nevezik, mivel a helyi szolgáltatások kapcsolatainak kezeléséért felelõs. Amikor az inetd fogad egy csatlakozási kérelmet, akkor eldönti róla, hogy ez melyik programhoz tartozik és elindít egy példányt belõle, majd átadja neki a socketet (az így meghívott program a szabvány bemenetéhez, kimenetéhez és hibajelzési csatornájához kapja meg a socket leíróit). Az inetd használatával úgy tudjuk csökkenteni a rendszerünk terhelését, hogy a csak alkalmanként meghívott szolgáltatásokat nem futtatjuk teljesen független önálló módban.

Az inetd démont elsõsorban más démonok elindítására használjuk, de néhány triviális protokollt közvetlenül is képes kezelni, mint például a chargen, auth és a daytime.

Ebben a fejezetben az inetd beállításának alapjait foglaljuk össze mind parancssoros módban, mind pedig az /etc/inetd.conf konfigurációs állományon keresztül.

Az inetd mûködése az rc(8) rendszeren keresztül inicializálható. Az inetd_enable ugyan alapból a NO értéket veszi fel, vagyis tiltott, de a sysinstall használatával már akár a telepítés során bekapcsolható attól függõen, hogy a felhasználó milyen konfigurációt választott. Ha tehát a:

vagy

sort tesszük az /etc/rc.conf állományba, akkor azzal az inetd démont indíthatjuk el vagy tilthatjuk le a rendszer indítása során. Az

paranccsal lekérdezhetjük a pillanatnyilag érvényes beállítást.

Emellett még az inetd démonnak az inetd_flags változón keresztül különbözõ parancssori paramétereket is át tudunk adni.

Hasonlóan a legtöbb szerverhez, az inetd viselkedését is befolyásolni tudjuk a parancssorban átadható különbözõ paraméterekkel. Ezek teljes listája a következõ:

inetd [-d] [-l] [-w] [-W] [-c maximum] [-C arány] [-a cím | név] [-p állomány] [-R arány] [-s maximum] [konfigurációs állomány]

Ezek a paraméterek az /etc/rc.conf állományban az inetd_flags segítségével adhatóak meg az inetd részére. Alapértelmezés szerint az inetd_flags értéke -wW -C 60, ami az inetd által biztosított szolgáltatások TCP protokollon keresztüli wrappelését kapcsolja be, illetve egy IP-címrõl nem engedi a felkínált szolgáltatások elérését percenként hatvannál többször.

A kezdõ felhasználók örömmel nyugtázhatják, hogy ezeket az alapbeállításokat nem szükséges módosítaniuk. A késõbbiekben majd fény derül arra, hogy a kiszolgálás gyakoriságának szabályozása remek védekezést nyújthat túlzottan nagy mennyiségû kapcsolódási kérelem ellen. A megadható paraméterek teljes listája az inetd(8) man oldalán olvasható.

Az inetd beállítását az /etc/inetd.conf konfigurációs állományon keresztül végezhetjük el.

Amikor az /etc/inetd.conf állományban módosítunk valamit, az inetd démont a következõ paranccsal meg kell kérnünk, hogy olvassa újra:

A konfigurációs állomány minden egyes sora egy-egy démont ír le. A megjegyzéseket egy "#" jel vezeti be. Az /etc/inetd.conf állomány bejegyzéseinek formátuma az alábbi:

Az IPv4 protokollt használó ftpd(8) démon bejegyzése például így néz ki:

Attól függõen, hogy a telepítés során mit választottunk, az inetd által támogatott szolgáltatások egyes része talán alapból engedélyezett is. Amennyiben egy adott démont konkrétan nem használunk, akkor érdemes megfontolni a letiltását. A kérdéses démon sorába tegyünk egy "#" jelet az /etc/inetd.conf állományba, majd olvastassuk újra az inetd beállításait. Egyes démonok, mint például az fingerd használata egyáltalán nem ajánlott, mivel a támadók számára hasznos információkat tudnak kiszivárogtatni.

Más démonok nem ügyelnek a védelemre, és a kapcsolatokhoz rendelt lejárati idejük túlságosan hosszú vagy éppen nincs is. Ezzel a támadónak lehetõsége van lassú kapcsolatokkal leterhelni az adott démont, ezáltal kimeríteni a rendszer erõforrásait. Ha úgy találjuk, hogy túlságosan sok az ilyen kapcsolat, akkor jó ötletnek bizonyulhat a démonok számára a max-connections-per-ip-per-minute, max-child vagy max-child-per-ip korlátozások elrendelése.

Alapértelmezés szerint a TCP kapcsolatok wrappelése engedélyezett. A hosts_access(5) man oldalon találhatjuk meg az inetd által meghívható különféle démonok TCP-alapú korlátozásainak lehetõségeit.

A daytime, time, echo, discard, chargen és auth szolgáltatások feladatainak mindegyikét maga az inetd is képes ellátni.

Az auth szolgáltatás a hálózati keresztül azonosítást teszi lehetõvé és bizonyos mértékig beállítható. A többit egyszerûen csak kapcsoljuk ki vagy be.

A témában az inetd(8) man oldalán tudunk még jobban elmerülni.

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.

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:

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:

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.

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.

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

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:

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:

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:

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

Az Az rc használata FreeBSD alattban 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:

Az NFS kliensen pedig:

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:

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:

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

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

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:

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.

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

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:

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(8) 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:

És így tudjuk manuálisan csatlakoztatni:

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

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

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.

A hálózati információs szolgáltatást (Network Information Service, avagy NIS) a Sun Microsystems fejlesztette ki a UNIX® (eredetileg SunOS™) rendszerek központosított karbantartásához. Mostanra már lényegében ipari szabvánnyá nõtte ki magát, hiszen az összes nagyobb UNIX®-szerû rendszer (a Solaris™, HP-UX, AIX®, Linux, NetBSD, OpenBSD, FreeBSD stb.) támogatja a NIS használatát.

A NIS régebben sárga oldalak (Yellow Pages) néven volt ismert, de a különbözõ jogi problémák miatt késõbb ezt a Sun megváltoztatta. A régi elnevezést (és a yp rövidítést) azonban még napjainkban is lehet néhol látni.

Ez egy RPC alapján mûködõ, kliens/szerver felépítésû rendszer, amely az egy NIS tartomány belül levõ számítógépek számára teszi lehetõvé ugyanazon konfigurációs állományok használatát. Segítségével a rendszergazda a NIS klienseket a lehetõ legkevesebb adat hozzáadásával, eltávolításával vagy módosításával képes egyetlen helyrõl beállítani.

Hasonló a Windows NT® tartományaihoz, és habár a belsõ implementációt tekintve már akadnak köztük jelentõs eltérések is, az alapvetõ funkciók szintjén mégis összevethetõek.

A NIS telepítése számos fogalom és fontos felhasználói program kerül elõ FreeBSD-n, akár egy NIS szervert akarunk beállítani, akár csak egy NIS klienst:

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.

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

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

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.

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:

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.

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:

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.

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

A mezõk mindegyike tartalmazhat dzsókerkaraktereket. Errõl részletesebben a netgroup(5) man oldalon olvashatunk.

Az így létrehozott új NIS táblázat szétküldése meglehetõsen könnyû feladat:

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:

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:

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.

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:

Az egyszerû munkaállomások esetében pedig ezekre a sorokra lesz szükségünk:

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:

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:

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:

Ha a felhasználói hozzáféréseinket valamilyen adatbázisban tároljuk, akkor a táblázat elsõ részét akár az adatbázis lekérdezésein keresztül is elõ tudjuk állítani. Ezzel a módszerrel az új felhasználók automatikusan hozzáférnek a gépekhez.

Legyünk viszont óvatosak: nem mindig javasolt gépeken alapuló hálózati csoportokat készíteni. Ha a hallgatói laborokba egyszerre több tucat vagy akár több száz azonos konfigurációjú gépet telepítünk, akkor a gép alapú csoportok helyett inkább szerep alapú csoportokat építsünk fel, mivel így a NIS táblázatok méretét egy elfogadható méreten tudjuk tartani.

Még mindig akad néhány olyan dolog, amit másképpen kell csinálnunk azután, hogy most már NIS környezetben vagyunk.

A FreeBSD-ben megtalálható ypserv szolgáltatás valamennyire képes ellátni a NIS elsõ változatát használó klienseket is. A FreeBSD NIS implementációja csak a NIS v2 protokollt használja, azonban mivel más implementációk kompatibilisek kívánnak maradni a régebbi rendszerekkel, ismerik a v1 protokollt is. Az ilyen rendszerekhez tartozó ypbind démonok még olyankor is megpróbálnak v1-es NIS szerverekhez kötést létrehozni, amikor valójában nincs is rá szükségük (és gyakran még akkor is ilyet keresnek, amikor az üzenetükre már válaszolt egy v2-es szerver). Hozzátennénk, hogy bár az ypserver ezen változata a normál klienshívásokat képes feldolgozni, a táblázatokat már nem tudja átküldeni a v1-es klienseknek. Ebbõl következik, hogy a központi vagy alárendelt szerverek nem tudnak együttmûködni olyan NIS szerverekkel, amelyek csak a v1-es protokollt beszélik. Szerencsére ilyen szervereket manapság már alig használnak.

Óvatosan kell bánnunk az ypserv elindításával olyan többszerveres tartományokban, ahol a szerverek maguk is NIS kliensek. Alapvetõen nincs abban semmi kivetnivaló, ha a szervereket saját magukhoz kötjük ahelyett, hogy engednénk nekik a kötési kérések küldését és így egymáshoz kötnénk ezeket. Különös hibák tudnak származni olyan helyzetekben, amikor az egyik szerver leáll, miközben a többiek pedig függenek tõle. Végül is ilyenkor minden kliens szépen kivárja a szükséges idõt, aztán megpróbál más szerverekhez kötõdni, de az itt fellépõ késlekedés jelentõs mennyiségû lehet, és ez a hibajelenség ismét fennállhat, mivel elõfordulhat, hogy a szerverek megint egymáshoz kapcsolódnak.

A klienst úgy tudjuk egy adott szerverhez kötni, ha az ypbind parancsot a -S beállítással indítjuk. Ha mindezt nem akarjuk manuálisan megtenni a NIS szerver minden egyes újraindításakor, akkor vegyük fel a következõ sorokat az /etc/rc.conf állományba:

Részletesebb lásd az ypbind(8) man oldalát.

A NIS rendszerek kiépítése során az emberek leggyakrabban a jelszavak formátumával kapcsolatban tapasztalnak nehézségeket. Ha a szerverünk DES titkosítású jelszavakat használ, akkor csak olyan klienseket fog tudni támogatni, amelyek szintén így kódolják ezeket. Például, ha a hálózaton vannak Solaris™ rendszerû NIS klienseink, akkor szinte biztos, hogy DES titkosítást kell használnunk.

A szerverek és a kliensek által használt formátumokat az /etc/login.conf állományba tekintve deríthetjük ki. Ha a gépek többségén a DES titkosítást látjuk, akkor a default osztálynak egy ilyen bejegyzést kell tartalmaznia:

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:

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

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.

A Dinamikus állomáskonfigurációs protokoll, avagy Dynamic Host Configuration Protocol (DHCP) annak eszközeit írja le, hogy egy rendszer miként tud csatlakozni egy hálózathoz és miként tudja azon belül megszerezni a kommunikációhoz szükséges információkat. A FreeBSD 6.0 elõtti változatai az ISC (Internet Systems Consortium, vagyis az internetes rendszerkonzorcium) által kidolgozott DHCP kliens (dhclient(8)) implementációját tartalmazzák. A késõbbi verziókban pedig az OpenBSD 3.7 verziójából átvett dhclient paranccsal dolgozhatunk. Ebben a szakaszban a dhclient parancsra vonatkozó összes információ egyaránt érvényes az ISC és az OpenBSD által fejlesztett DHCP kliensekre. A DHCP szerver az ISC-tõl származik.

Ebben a szakaszban az ISC és az OpenBSD DHCP klienseinek kliens- és szerver oldali komponsenseit mutatjuk be. A kliens oldali program neve a dhclient, amely a FreeBSD részeként érkezik, és a szerver oldali elem pedig a net/isc-dhcp31-server porton keresztül érhetõ el. A lentebb említett hivatkozások mellett a témában még a dhclient(8), dhcp-options(5) és a dhclient.conf(5) man adhatnak bõvebb felvilágosítást a témában.

Amikor a dhclient, vagyis a DHCP kliens elindul egy kliensgépen, akkor a hálózaton üzenetszórással próbálja meg elkérni a konfigurációjához szükséges adatokat. Alapértelmezés szerint ezek a kérések a 68-as UDP porton keresztül mennek. A szerver ezekre a 67-es UDP porton válaszol, ahol visszaad a kliensnek egy IP-címet és a hálózat használatához szükséges további információkat, mint például a hálózati maszkot, az alapértelmezett átjáró és a névfeloldásért felelõs szerverek címét. Az összes ilyen jellegû adat egy DHCP "bérlet" (lease) formájában érkezik meg, amely csak egy adott ideig érvényes (ezt a DHCP szerver karbantartója állítja be). Így a hálózaton a kliens nélküli IP-címeket egy idõ után automatikusan visszanyerjük.

A DHCP kliensek rengeteg információt képes elkérni a szervertõl. Ezek teljes listáját a dhcp-options(5) man oldalán olvashatjuk el.

A FreeBSD teljes egészében tartalmazza az ISC vagy az OpenBSD DHCP kliensét, a dhclient programot (attól függõen, hogy a FreeBSD melyik változatát használjuk). A DHCP kliensek támogatása a telepítõben és az alaprendszerben is megtalálható, és ezzel mentesülünk minden konkrét hálózati beállítás alól a DHCP szervereket alkalmazó hálózatokon. A dhclient a FreeBSD 3.2 változata óta megtalálható a rendszerben.

DHCP használatát a sysinstall is lehetõvé teszi. Amikor egy hálózati felületet a sysinstall programon belül állítunk be, akkor a második kérdés mindig ez szokott lenni: "Do you want to try DHCP configuration of the interface?" ("Megpróbáljuk DHCP használatával beállítani a felületet?") Ha erre igennel válaszolunk, akkor azzal lényegében a dhclient parancsot indítjuk el, és ha mindez sikerrel zárul, akkor szinte magától kitöltõdik az összes hálózati beállításunk.

A DHCP használatához két dolgot kell beállítanunk a rendszerünkön:

A DHCP szerver, a dhcpd a net/isc-dhcp31-server port részeként érhetõ el. Az a port tartalmazza az ISC DHCP szerverét és a hozzá tartozó dokumentációt.

A DHCP protokoll mûködését az RFC 2131 mutatja be. A témához kapcsolódóan itt tudunk még leírásokat találni.

A FreeBSD alapértelmezés szerint a BIND (Berkeley Internet Name Domain) egyik verzióját tartalmazza, amely a névfeloldási (Domain Name System, DNS) protokoll egyik elterjedt implementációja. A DNS protokollon keresztül tudunk az IP-címekhez neveket rendelni és fordítva. Például a www.FreeBSD.org névre a FreeBSD Projekt webszerverének IP-címét kapjuk meg, miközben a ftp.FreeBSD.org pedig a hozzá tartozó FTP szerver IP-címét fogja visszaadni. Ehhez hasonlóan a fordítottja is megtörténhet, vagyis egy IP-címhez is kérhetjük a hálózati név feloldását. A névfeloldási kérések kiszolgálásához nem feltétlenül szükséges névszervert futtatni a rendszerünkön.

A FreeBSD jelen pillanatban alapból a BIND9 névszervert tartalmazza. A benne szereplõ változata több biztonsági javítást, új állományrendszeri kiosztást és automatizált chroot(8) beállítást is magában foglal.

Az interneten keresztüli névfeloldást legfelsõ szintû tartományoknak (Top Level Domain, TLD) nevezett hitelesített tövek némileg bonyolult rendszerén alapszik, valamint más egyéb olyan névszervereken, amelyek további egyéni információkat tárolnak és táraznak.

A BIND fejlesztését jelenleg az Internet Systems Consortium (http://www.isc.org/) felügyeli.

A leírás megértéséhez be kell mutatnunk néhány névfeloldással kapcsolatos fogalmat.

Példák zónákra:

Mint láthatjuk, a hálózati nevek balról kiegészülve pontosodnak. Tehát például a minta.org. sokkal pontosabb meghatározás, mint a org., ahogy az org. magánál a gyökérzónánál jelent többet. A hálózati nevek felosztása leginkább egy állományrendszerhez hasonlítható, például a /dev könyvtár a gyökéren belül található, és így tovább.

A névszerverek általában két alakban jelennek meg. Egyikük a hitelesített névszerver, a másikuk a gyorsítótárazó névszerver.

Egy hitelesített névszerverre akkor van szükségünk, ha:

A gyorsítótárazó névszerverre akkor van szükségünk, ha:

Amikor valaki lekérdezi a www.FreeBSD.org címét, akkor a névfeloldó elõször általában a kapcsolatot rendelkezésre bocsátó internet-szolgáltató névszerverét kérdezi meg és onnan kapja meg a választ. Egy helyi, gyorsítótárazó névszerver használata esetén azonban egy ilyen kérést csak egyszer kell kiadni a külsõ névszervernek. Ezután már minden további ilyen kérés el sem hagyja a belsõ hálózatunkat, mivel a válasz szerepel a gyorsítótárban.

FreeBSD alatt a BIND démon nyilvánvaló okokból named néven érhetõ el.

Attól függõen, hogy miként állítjuk be az adott zónát a szerveren, a hozzá tartozó állományok a /etc/namedb könyvtáron belül a master, slave vagy dynamic alkönyvtárban foglalnak helyet. Az itt tárolt állományokban levõ névfeloldási információk alapján válaszol a névszerver a felé intézett kérésekre.

Mivel a BIND alapból elérhetõ a rendszerben, viszonylag könnyen be tudjuk állítani.

A named alapértelmezett beállítása szerint egy chroot(8) környezetben futó egyszerû névfeloldást végzõ szerver, amely a helyi IPv4 interfészen (127.0.0.1) fogadja a kéréseket. Ezzel a beállítással a következõ parancson keresztül tudjuk elindítani:

Ha engedélyezni akarjuk a named démont minden egyes rendszerindításkor, tegyük a következõ sort az /etc/rc.conf állományba:

Értelemszerûen az /etc/namedb/named.conf tele van olyan beállítási lehetõségekkel, amelyek meghaladják ennek a leírásnak a kereteit. Ha viszont kíváncsiak vagyunk a FreeBSD-ben a named indításához használt beállításokra, akkor az /etc/defaults/rc.conf állományban nézzük meg named_* változókat és olvassuk át az rc.conf(5) man oldalt. Emellett még a Az rc használata FreeBSD alattt is hasznos lehet elolvasni.

A named beállításait tartalmazó állományok pillanatnyilag az /etc/namedb könyvtárban találhatóak és hacsak nem egy egyszerû névfeloldóra tartunk igényt, akkor a használata elõtt módosítanunk is kell. Itt ejtjük meg a beállítások nagy részét.

A gyorsítótárazó névszerver az a névszerver, amely elsõdleges feladata a rekurzív kérések kiszolgálása. Egyszerûen továbbítja a beérkezõ kéréseket, majd megjegyzi azokat, így késõbb közvetlenül tud válaszolni.

Habár a névfeloldás szempontjából a BIND a legelterjedtebb, a biztonságosságával azért akadnak gondok. Gyakran találnak benne potenciális és kihasználható biztonsági réseket.

A FreeBSD azonban a named démont automatikusan egy chroot(8) környezetbe helyezi. Emellett még léteznek további más védelmi mechanizmusok is, amelyek segítségével el tudjuk kerülni a névfeloldást célzó esetleges támadásokat.

Sosem árt olvasgatni a CERT által kiadott biztonsági figyelmeztetéseket és feliratkozni a FreeBSD security notifications levelezési lista címére, hogy folyamatosan értesüljünk az interneten és a FreeBSD-ben talált különbözõ biztonsági hibákról.

A BIND/named man oldalai: rndc(8) named(8) named.conf(8)

A FreeBSD szolgálja ki a legforgalmasabb honlapok nagy részét szerte a világban. A mögöttük álló webszerverek általában az Apache webszervert alkalmazzák. Az Apache használatához szükséges csomagok megtalálhatóak a FreeBSD telepítõlemezén is. Ha a FreeBSD elsõ telepítésekor még nem telepítettük volna az Apache szerverét, akkor a www/apache13 vagy www/apache12 portból tudjuk feltenni.

Az Apache szervert sikeres telepítését követõen be kell állítanunk.

Az Apache webszerver konfigurációs állománya FreeBSD alatt /usr/local/etc/apache/httpd.conf néven található. Ez az állomány egy szokványos UNIX®-os szöveges konfigurációs állomány, ahol a megjegyzéseket egy # karakterrel vezetjük be. Az itt használható összes lehetséges beállítási lehetõség átfogó ismertetése meghaladná az egész kézikönyv határait, ezért most csak a leggyakrabban módosított direktívákat fogjuk ismertetni.

A változtatások végrehajtása elõtt mindig is jó ötlet biztonsági másolatot készíteni az Apache konfigurációs állományairól. Ahogy sikerült összerakni egy számunkra megfelelõ konfigurációt, készen is állunk az Apache futtatására.

A többi hálózati szervertõl eltérõen az Apache nem az inetd szuperszerverbõl fut. A kliensektõl érkezõ HTTP kérések minél gyorsabb kiszolgálásának érdekében úgy állítottuk be, hogy önállóan fusson. Ehhez egy szkriptet is mellékeltünk, amellyel igyekeztünk a lehetõ legjobban leegyszerûsíteni a szerver indítását, leállítását és újraindítását. Az Apache elsõ indításához adjuk ki a következõ parancsot:

Így pedig a szervert bármikor leállíthatjuk:

Ha valamilyen okból megváltoztattuk volna a szerver beállításait, akkor ezen a módon tudjuk újraindítani:

Ha a jelenleg megnyitott kapcsolatok felbontása nélkül akarjuk újraindítani az Apache szervert, akkor ezt írjuk be:

Mindezekrõl az apachectl(8) man oldalon találunk bõvebb leírást.

Amennyiben szükségünk lenne az Apache elindítására a rendszer indításakor, akkor a következõ sort vegyünk fel az /etc/rc.conf állományba:

Az Apache 2.2 esetében:

Amikor az Apache httpd nevû programjának szeretnénk további paranccsori paramétereket átadni a rendszer indítása során, akkor ezeket így tudjuk megadni az rc.conf állományban:

Most, miután a webszerverünk mûködik, a böngészõnkkel mindezt ellenõrizni is tudjuk a http://localhost/ cím beírásával. Ilyenkor az alapértelmezés szerinti /usr/local/www/data/index.html állomány tartalmát láthatjuk.

Az Apache a virtuális nevek használatának két különbözõ módját ismeri. Ezek közül az elsõ módszer a név alapú virtualizáció (Name-based Virtual Hosting). Ilyenkor a kliens HTTP/1.1 fejlécébõl próbálja meg a szerver megállapítani a hivatkozási nevet. Segítségével több tartomány is osztozhat egyetlen IP-címen.

Az Apache név alapú virtualizációjának beállításához az alábbi beállítást kell hozzátennünk a httpd.conf állományhoz:

Ha a webszerverünk neve www.tartomany.hu, és hozzá egy www.valamilyenmasiktartomany.hu virtuális nevet akarunk megadni, akkor azt a következõképpen tehetjük meg a httpd.conf állományon belül:

A címek és elérési utak helyére helyettesítsük be a használni kívánt címeket és elérési utakat.

A virtuális nevek beállításának további részleteivel kapcsolatosan keressük fel az Apache hivatalos dokumentációját a http://httpd.apache.org/docs/vhosts/ címen (angolul).

Az alap szerver képességeinek kiegészítéséhez több különbözõ Apache modul áll rendelkezésünkre. A FreeBSD Portgyûjteménye az Apache telepítése mellett lehetõséget ad a népszerûbb bõvítményeinek telepítésére is.

Az utóbbi évtizedben egyre több vállalkozás fordult az internet felé bevételeik és részesedéseinek növelésének reményében, amivel egyre jobban megnõtt az igény a dinamikus honlapokra is. Miközben bizonyos cégek, mint például a Microsoft®, a saját fejlesztésû termékeikbe építettek be ehhez támogatást, addig a nyílt forrásokkal foglalkozó közösség sem maradt tétlen és felvette a kesztyût. A dinamikus tartalom létrehozásához többek közt Django, Ruby on Rails, a mod_perl és a mod_php modulok használhatóak.

Az adatállomány átviteli protokoll (File Transfer Protocol, FTP) a felhasználók számára lehetõséget ad az ún. FTP szerverekre állományokat feltölteni, illetve onnan állományokat letölteni. A FreeBSD alaprendszere is tartalmaz egy ilyen FTP szerverprogramot, ftpd néven. Ezért FreeBSD alatt egy FTP szerver beállítása meglehetõsen egyszerû.

A beállítás legfontosabb lépése, hogy eldöntsük milyen hozzáféréseken át lehet elérni az FTP szervert. Egy hétköznapi FreeBSD rendszerben rengeteg hozzáférés a különbözõ démonokhoz tartozik, de az ismeretlen felhasználók számára nem kellene megengednünk ezek használatát. Az /etc/ftpusers állományban szerepelnek azok a felhasználók, akik semmilyen módon nem érhetik el az FTP szolgáltatást. Alapértelmezés szerint itt találhatjuk az elõbb említett rendszerszintû hozzáféréseket is, de ide minden további nélkül felvehetjük azokat a felhasználókat, akiknél nem akarjuk engedni az FTP elérését.

Más esetekben elõfordulhat, hogy csak korlátozni akarjuk egyes felhasználók FTP elérését. Ezt az /etc/ftpchroot állományon keresztül tehetjük meg. Ebben az állományban a lekorlátozni kívánt felhasználókat és csoportokat írhatjuk bele. Az ftpchroot(5) man oldalán olvashatjuk el ennek részleteit, ezért ennek pontos részleteit itt most nem tárgyaljuk.

Ha az FTP szerverünkhöz névtelen (anonim) hozzáférést is engedélyezni akarunk, akkor ahhoz elõször készítenünk kell egy ftp nevû felhasználót a FreeBSD rendszerünkben. A felhasználók ezután az ftp vagy anonymous nevek, valamint egy tetszõleges jelszó (ez a hagyományok szerint a felhasználó e-mail címe) használatával is képesek lesznek bejelentkezni. Az FTP szerver ezután a névtelen felhasználók esetében meghívja a chroot(2) rendszerhívást, és ezzel lekorlátozza hozzáférésüket az ftp felhasználó könyvtárára.

Két szöveges állományban adhatunk meg a becsatlakozó FTP kliensek számára üdvözlõ üzeneteket. Az /etc/ftpwelcome állomány tartalmát még a bejelentkezés elõtt látni fogják a felhasználók, a sikeres bejelentkezést követõen pedig az /etc/ftpmotd állomány tartalmát látják. Vigyázzunk, mert ennek az állománynak már a bejelentkezési környezethez képest relatív az elérése, ezért a névtelen felhasználók esetében ez konkrétan az ~ftp/etc/ftpmotd állomány lesz.

Ahogy beállítottuk az FTP szervert, az /etc/inetd.conf állományban is engedélyeznünk kell. Itt mindössze annyira lesz szükségünk, hogy eltávolítsuk a megjegyzést jelzõ "#" karaktert a már meglevõ ftpd sor elõl:

Ahogy arról már a Az inetd konfigurációs állományának újraolvasása szót ejtett, az inetd beállításait újra be kell olvastatnunk a konfigurációs állomány megváltoztatása után. A Beállítások írja le az inetd engedélyezésének részleteit.

Az ftpd önálló szerverként is elindítható. Ehhez mindössze elegendõ csak a megfelelõ változót beállítani az /etc/rc.conf állományban:

Miután megadtuk az iménti változót, a szerver el fog indulni a rendszer következõ indítása során. Szükség esetén természetesen root felhasználóként a következõ paranccsal is közvetlenül elindítható:

Most már be is tudunk jelentkezni az FTP szerverre:

Az ftpd démon a syslog(3) használatával naplózza az üzeneteket. Alapértelmezés szerint a rendszernaplózó démon az FTP mûködésére vonatkozó üzeneteket az /var/log/xferlog állományba írja. Az FTP naplóinak helyét az /etc/syslog.conf állományban tudjuk módosítani:

Legyünk körültekintõek a névtelen FTP szerverek üzemeltetésekor. Azt pedig kétszer is gondoljuk meg, hogy engedélyezzük-e a névtelen felhasználók számára állományok feltöltését, hiszen könnyen azon kaphatjuk magunkat, hogy az FTP oldalunk illegális állománycserék színterévé válik vagy esetleg valami sokkal rosszabb történik. Ha mindenképpen szükségünk lenne erre a lehetõségre, akkor állítsunk be olyan engedélyeket a feltöltött állományokra, hogy a többi névtelen felhasználó ezeket a tartalmuk tüzetes ellenõrzéséig ne is olvashassa.

A Samba egy olyan elterjedt nyílt forráskódú szoftver, ami Microsoft® Windows® kliensek számára tesz lehetõvé állomány- és nyomtatási szolgáltatásokat. Az ilyen kliensek általa helyi meghajtóként képesek elérni a FreeBSD állományrendszerét, vagy helyi nyomtatóként a FreeBSD általt kezelt nyomtatókat.

A Samba csomagja általában megtalálható a FreeBSD telepítõeszközén. Ha a FreeBSD-vel együtt nem raktuk fel a Samba csomagját, akkor ezt késõbb net/samba3 port vagy csomag telepítésével pótolhatjuk.

A Samba konfigurációs állománya a telepítés után /usr/local/shared/examples/samba/smb.conf.default néven található meg. Ezt kell lemásolnunk /usr/local/etc/smb.conf néven, amelyet aztán a Samba tényleges használata elõtt módosítanunk kell.

Az smb.conf állomány a Samba futásához használt beállításokat tartalmazza, mint például Windows® kliensek számára felkínált a nyomtatók és "megosztások" adatait. A Samba csomagban ezen kívül találhatunk még egy swat nevû webes eszközt, amellyel egyszerû módon tudjuk az smb.conf állományt állítgatni.

A net/samba3 port a Samba irányítására egy új indító szkriptet tartalmaz. A szkript engedélyezéséhez, tehát általa a Samba elindításának, leállításának és újraindításának lehetõvé tételéhez vegyük fel a következõ sort az /etc/rc.conf állományba:

Ha még finomabb irányításra vágyunk:

A Samba a következõkkel bármikor elindítható:

Az rc szkriptekkel kapcsolatban a Az rc használata FreeBSD alattt ajánljuk elolvasásra.

A Samba jelen pillanatban három különálló démonból áll. Láthatjuk is, hogy az nmbd és smbd démonokat elindította a samba szkript. Ha az smb.conf állományban engedélyeztük a winbind névfeloldási szolgáltatást is, akkor láthatjuk, hogy ilyenkor a winbindd démon is elindul.

A Samba így állítható le akármikor:

A Samba egy összetett szoftvercsomag, amely a Microsoft® Windows® hálózatokkal kapcsolatos széles körû együttmûködést tesz lehetõvé. Az általa felkínált alapvetõ lehetõségeken túl a többit a http://www.samba.org honlapon ismerhetjük meg (angolul).

Idõvel a számítógép órája hajlamos elmászni. A hálózati idõ protokoll (Network Time Protocol, NTP) az egyik módja az óránk pontosan tartásának.

Rengeteg internetes szolgáltatás elvárja vagy éppen elõnyben részesíti a számítógép órájának pontosságát. Például egy webszervertõl megkérdezhetik, hogy egy állományt adott ideje módosítottak-e. A helyi hálózatban az egyazon állományszerveren megosztott állományok ellentmondásmentes dátumozása érdekében szinte elengedhetetlen az órák szinkronizálása. Az olyan szolgáltatások, mint a cron(8) is komolyan építkeznek a pontosan járó rendszerórára, amikor egy adott pillanatban kell lefuttatniuk parancsokat.

A FreeBSD alapból az ntpd(8) NTP szervert tartalmazza, amellyel más NTP szerverek segítségével tudjuk beállítani gépünk óráját, vagy éppen idõvel kapcsolatos információkat szolgáltatni másoknak.

Az óránk egyeztetéséhez egy vagy több NTP szerverre lesz szükségünk. Elõfordulhat, hogy a hálózati rendszergazdánk vagy az internet-szolgáltatónk már beállított egy ilyen szervert erre a célra. Ezzel kapcsolatban olvassuk el a megfelelõ leírásokat. A nyilvánosan elérhetõ NTP szerverekrõl készült egy lista, ahonnan könnyedén ki tudjuk keresni a számunkra leginkább megfelelõ (hozzánk legközelebbi) szervert. Ne hagyjuk figyelmen kívül a szerverre vonatkozó házirendet és kérjünk engedélyt a használatához, amennyiben ez szükséges.

Több, egymással közvetlen kapcsolatban nem álló NTP szerver választásával járunk jól, ha netalán az egyikük váratlanul elérhetetlenné vagy az órája pontatlanná válna. Az ntpd(8) a visszakapott válaszokat intelligensen használja fel, mivel esetükben a megbízható szervereket részesíti elõnyben.

Úgy tudjuk az NTP szervert elindítani a rendszerünkkel együtt, ha az /etc/rc.conf állományban szerepeltetjük az ntpd_enable="YES" sort. Ha az ntpd(8) számára további beállításokat is át akarunk adni, akkor az /etc/rc.conf állományban adjuk meg az ntpd_flags paramétert.

Ha a gépünk újraindítása nélkül akarjuk elindítani a szerver, akkor az ntpd parancsot adjuk ki az /etc/rc.conf állományban a ntpd_flags változóhoz megadott paraméterekkel. Mint például:

Az ntpd(8) program megfelelõ mûködéséhez nem szükséges állandó internet kapcsolat. Ha azonban igény szerinti tárcsázással építjünk fel ideiglenes kapcsolatot, akkor érdemes letiltani az NTP forgalmát, nehogy feleslegesen aktiválja vagy tartsa életben a vonalat. Ha PPP típusú kapcsolatunk van, akkor az /etc/ppp/ppp.conf állományban a filter direktívával tudjuk ezt leszabályozni. Például:

Mindenezekrõl részletesebb felvilágosítást a ppp(8) man oldal PACKET FILTERING címû szakaszában és a /usr/shared/examples/ppp/ könyvtárban található példákban kaphatunk.

Az NTP szerver dokumentációja HTML formátumban a /usr/shared/doc/ntp/ könyvtárban található.

A naplószerverek olyan gépek, amelyeket úgy állítottunk be, hogy naplózási információkat tudjanak fogadni távoli számítógépekrõl. A legtöbb esetben így egyszerûsíteni tudunk a konfiguráción, vagy olykor egyszerûen csak hasznos, ha ezt a megoldást alkalmazzuk. Függetlenül attól, hogy miért használjuk, a továbblépés elõtt néhány elõkészületet meg kell tennünk.

Egy rendesen beállított naplószervernek legalább a következõ követelményeknek kell eleget tennie:

A naplószerver beállításához mindegyik klienst fel kell vennünk az /etc/syslog.conf állományba, valamint meg kell adnunk a megfelelõ funkciót (facility):

Miután beállítottuk, az összes adott funkcióhoz tartozó üzenet az elõbb megadott állományba (/var/log/naplokliens.log) fog kerülni.

A szerveren továbbá meg kell adnunk a következõ sort az /etc/rc.conf állományban:

Az elsõ sorral engedélyezzük a syslogd elindítását a rendszerindítás során, majd a második sorral engedélyezzük, hogy a kliens naplózni tudjon a szerverre. Itt még látható a -vv opció, amellyel a naplózott üzenetek részletességét tudjuk növelni. Ennek nagyon fontos a szerepe a naplózási funkciók behangolásakor, mivel így a rendszergazdák pontosan láthatják milyen típusú üzenetek milyen funkcióval kerültek rögzítésre a naplóban.

Befejezésképpen hozzuk létre a naplóállományt. Teljesen mindegy, hogy erre milyen megoldást alkalmazunk, például a touch(1) remekül megfelel:

Ezután indítsuk újra és ellenõrizzük a syslogd démont:

Ha válaszul megkapjuk a futó démon azonosítóját, akkor sikerült újraindítanunk, elkezdhetjük a kliens beállítását. Ha valamiért nem indult volna újra a szerver, az /var/log/messages állományból próbáljuk meg kideríteni az okát.

A naplókliens az a gép, amely egy helyi naplópéldány karbantartása mellett továbbküldni a naplózandó információkat egy naplószervernek.

Hasonlóan a naplószerverekhez, a klienseknek is teljesítenie bizonyos alapvetõ elvárásokat:

A kliens beállítása sokkal egyszerûbb a szerverhez képest. A kliensen adjuk hozzá a következõ sorokat az /etc/rc.conf állományhoz:

A szerver beállításaihoz hasonlóan itt is engedélyezzük a syslogd démont és megnöveljük a naplózott üzenetek részletességét. A -s kapcsolóval pedig megakadályozzuk, hogy a kliens más gépekrõl is hajlandó legyen naplóüzeneteket elfogadni.

A funkciók a rendszernek azon részét írják le, amelyhez létrejön az adott üzenet. Tehát például az ftp és ipfw egyaránt ilyen funkciók. Amikor keletkezik egy naplóüzenet valamelyikükhöz, általában megjelenik a nevük. A funkciókhoz tartozik még egy prioritás vagy szint is, amellyel az adott üzenet fontosságát jelzik. Ezek közül a leggyakoribb a warning (mint "figyelmeztetés") és info (mint "információ"). A használható funkciók és a hozzájuk tartozó prioritások teljes listáját a syslog(3) man oldalán olvashatjuk.

A naplószervert meg kell adnunk a kliens /etc/syslog.conf állományában. Itt a @ szimbólummal jelezzük, hogy az adatokat egy távoli szerverre szeretnénk továbbküldeni, valahogy így:

Ezután a beállítás érvényesítéséhez újra kell indítanunk a syslogd démont:

A logger(1) használatával próbáljuk ki a kliensrõl a aplóüzenetek hálózaton keresztüli küldését, és küldjünk valamit a syslogd démonnak:

A parancs kiadása után az üzenetnek mind a kliens, mind pedig a szerver /var/log/messages állományában meg kell jelennie.

Elõfordulhat, hogy a naplószerver valamiért nem kapja meg rendesen az üzeneteket, ezért valamilyen módon meg kell keresnünk a hiba okát. Ez több minden lehet, de általában két leggyakoribb ok valamilyen hálózati kapcsolódási vagy DNS beállítási hiba. Ezek teszteléséhez gondoskodjunk róla, hogy a gépek kölcsönösen elérhetõek egymásról az /etc/rc.conf állományban megadott hálózati nevük szerint. Ha ezzel látszólag minden rendben van, akkor próbáljuk meg módosítani a syslogd_flags értékét az /etc/rc.conf állományban.

A most következõ példában a /var/log/naplokliens.log teljesen üres, illetve a /var/log/messages állomány semmilyen hibára utaló okot nem tartalmaz. A hibakereséshez még több információt a syslogd_flags átírásával tudunk kérni:

Természetesen ne felejtsük el újraindítani a szervert:

A démon újraindítása után közvetlenül az alábbiakhoz hasonló üzenetek árasztják el a képernyõt:

A diagnosztikai üzeneteket végigolvasva nyilvánvaló válik, hogy azért dobja el az üzeneteket a szerver, mert nem megfelelõ a gép neve. Miután átnézzük a beállításainkat, felfedezhetünk az /etc/rc.conf állományban egy apró hibát:

Láthatjuk, hogy ebben a sorban a naplokliens névnek kellene szerepelni, nem pedig a naploklien névnek. Miután elvégeztük a szükséges javításokat, indítsuk újra a szervert és vizsgáljuk meg az eredményt:

Itt már minden üzenet rendben megérkezett és a megfelelõ állományokba került (a /var/log/messages a kliensen, és a /var/log/naplokliens.log a szerveren)).

Mint minden hálózati szolgáltatás esetén, ilyenkor is figyelembe kell vennünk bizonyos biztonsági megfontolásokat a tényleges konfiguráció kiépítése elõtt. Olykor elõfordulhat, hogy a naplók különbözõ kényes információkat tartalmaznak, mint például a helyi rendszeren futó szolgáltatások nevei, felhasználói nevek vagy egyéb konfigurációs adatok. A kliens és a szerver között hálózaton utazó adatok viszont se nem titkosítottak, se nem jelszóval védettek. Ha titkosítást szeretnénk használni, akkor javasoljuk például a security/stunnel portot, amellyel egy titkosított tunnelen keresztül tudunk adatokat küldeni a hálózaton.

A helyi rendszer biztonságának szavatolása is fontos lehet. A naplók sem a használat során, sem pedig a lecserélésük után nem kerülnek titkosításra. Emiatt a helyi rendszerhez hozzáférõ felhasználók kedvükre nyerhetnek ki belõlük a rendszerünket érintõ konfigurációs információkat. Ezért ilyenkor nagyon fontos, hogy mindig a megfelelõ engedélyeket állítsuk be a naplókra. A newsyslog(8) segédprogrammal be tudjuk állítani a frissen létrehozott és a lecserélt naplók engedélyeit. Tehát könnyen megakadályozhatjuk a helyi felhasználók kíváncsiskodását, ha itt a naplók engedélyeit például a 600 kóddal adjuk meg.