diff --git a/hu_HU.ISO8859-2/articles/Makefile b/hu_HU.ISO8859-2/articles/Makefile index 1e7981d5b7..b5d1e022c9 100644 --- a/hu_HU.ISO8859-2/articles/Makefile +++ b/hu_HU.ISO8859-2/articles/Makefile @@ -1,23 +1,23 @@ -# $FreeBSD$ +# $FreeBSD: doc/hu_HU.ISO8859-2/articles/Makefile,v 1.8 2008/10/29 20:43:35 pgj Exp $ # # The FreeBSD Hungarian Documentation Project # %SOURCE% en_US.ISO8859-1/articles/Makefile -# %SRCID% 1.60 +# %SRCID% 1.61 # MAINTAINER= gabor@FreeBSD.org SUBDIR = compiz-fusion SUBDIR+= cups SUBDIR+= dialup-firewall SUBDIR+= explaining-bsd SUBDIR+= gjournal-desktop SUBDIR+= laptop SUBDIR+= linux-comparison SUBDIR+= linux-users SUBDIR+= multi-os SUBDIR+= version-guide DOC_PREFIX?= ${.CURDIR}/../.. .include "${DOC_PREFIX}/share/mk/doc.project.mk" diff --git a/hu_HU.ISO8859-2/books/handbook/firewalls/chapter.sgml b/hu_HU.ISO8859-2/books/handbook/firewalls/chapter.sgml index 5b8693f19d..c4a05d0a92 100644 --- a/hu_HU.ISO8859-2/books/handbook/firewalls/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/firewalls/chapter.sgml @@ -1,4558 +1,4560 @@ Joseph J. Barbish Írta: Brad Davis SGML formátumúra alakította és aktualizálta: Tûzfalak tûzfalak biztonság tûzfalak Bevezetés A tûzfalakkal a rendszerünkön keresztülfolyó bejövõ és kimenõ forgalmat tudjuk szûrni. A tûzfalak egy vagy több szabályrendszer alapján vizsgálják az éppen érkezõ vagy távozó hálózati csomagokat, és vagy továbbengedik ezeket vagy megállítják. A tûzfalak szabályai a csomagok egy vagy több jellemzõjét veszik szemügyre, amelyek lehetnek például a protokoll típusa, a forrás vagy cél hálózati címe, esetleg a forrás- vagy a célport. A tûzfalak jelentõs mértékben képesek gyarapítani egy gép vagy egy hálózat védelmét. Leginkább a következõkre tudjuk felhasználni: A belsõ hálózatunkban futó alkalmazások, szolgáltatások, gépek megvédésére és elszigetelésére az internetrõl érkezõ nem kívánt forgalom ellen A belsõ hálózatban levõ gépek elérését tudjuk korlátozni vagy letiltani az interneten elérhetõ szolgáltatások felé A hálózati címfordítás (Network Address Translation, NAT) beállításához, ahol a belsõ hálózatunk privát IP-címeket használnak és egy közös kapcsolaton keresztül érik el az internetet (egyetlen IP-címmel, vagy pedig automatikusan kiosztott publikus címekkel). A fejezet elolvasása során megismerjük: hogyan adjuk meg helyesen a csomagok szûrését leíró szabályokat; a &os;-be épített tûzfalak közti különbségeket; hogyan állítsuk be és használjuk az OpenBSD PF tûzfalát; hogyan állítsuk be és használjuk az IPFILTER tûzfalat; hogyan állítsuk be és használjuk az IPFW tûzfalat. A fejezet elolvasása elõtt ajánlott: a &os;-hez és az internethez kötõdõ alapvetõ fogalmak ismerete. Röviden a tûzfalakról tûzfalak szabályrendszerei A tûzfalak szabályrendszereit alapvetõen kétféleképpen tudjuk összeállítani: inkluzív, vagyis megengedõ, illetve exkluzív vagyis kizáró módon. Az exkluzív tûzfalak minden forgalmat átengednek, amirõl nem rendelkeznek a tûzfal szabályai. Az inkluzív tûzfalak ennek pontosan az ellenkezõjét teszik. Csak azt a forgalmat engedik át, amirõl van szabály és minden mást blokkolnak. Az inkluzív tûzfalak alkalmazásával sokkal jobban kezünkbentudjuk tartani a hálózatunk kimenõ forgalmát, ezért leginkább az internetes szolgáltatásokat futtató rendszerek esetében bizonyulhat jobb választásnak. Emellett az internetrõl a hálózatunk felé irányuló forgalmat is képes szabályozni. Ekkor az egyetlen szabályra sem illeszkedõ csomagokat egyszerûen eldobjuk és naplózzuk. Az inkluzív tûzfalak általában biztonságosabbak az exkluzív típusú társaiknál, mivel esetükben jelentõs mértékben visszaszorul a nem kívánatos átfolyó forgalom. Hacsak nem emeljük ki külön, a fejezet további részében minden példaként megadott szabályrendszer inkluzív tûzfalat hoz létre. Ez a típusú védelem még tovább fokozható az állapottartó tûzfalak (stateful firewall) használatával. Az ilyen típusú tûzfalak szemmel tartják a rajtuk keresztül megnyitott kapcsolatokat, és vagy csak a már meglevõ kapcsolathoz tartozó forgalmat engedik át vagy nyitnak egy újat. Az állapottartó tûzfalak hátránya, hogy a Denial of Service (DoS) típusú támadásokkal szemben sokkal sérülékenyebbek olyan helyzetekben, amikor az új kapcsolatok nagyon gyorsan jönnek létre. A legtöbb tûzfal esetében azonban tudjuk vegyíteni az állapottartó és nem állapottartó viselkedést, és ezzel egy ideális beállítást kialakítani. Tûzfalak A &os; alaprendszerébe három különbözõ tûzfalat építettek be, melyek a következõk: az IPFILTER (másik nevén IPF), az IPFIREWALL (más néven IPFW) és az OpenBSD csomagszûrõje (Packet Filter, azaz PF). A forgalom szabályozására (vagyis alapvetõen a sávszélesség kihasználtságának vezérlésére) a &os; két beépített csomagot tartalmaz: ez az &man.altq.4; és a &man.dummynet.4;. Általában a Dummynet az IPFW, míg az ALTQ a PF partnere. Az IPFILTER esetében maga az IPFILTER végzi a címfordítást és a szûrést, a sávszélességet pedig az IPFW a &man.dummynet.4; vagy a PF az ALTQ segítségével. Az IPFW és a PF szabályokkal rendelkezik a rendszerünkbe érkezõ vagy onnan távozó csomagokról, habár megoldásaik teljesen máshogy mûködnek és a szabályok megadási módja is eltér. A &os; azért tartalmaz egyszerre ennyiféle tûzfalat, mert az emberek elvárásai és igényei eltérnek. Egyikük sem tekinthetõ a legjobbnak. A szerzõ egyébként az IPFILTER megoldását részesíti elõnyben, mivel egy hálózati címfordítást alkalmazó környezetben sokkal könnyebb vele megfogalmazni az állapottartó szabályokat, valamint tartalmaz egy beépített FTP proxyt is, amivel így a kimenõ FTP kapcsolatok beállítása még tovább egyszerûsödik. Mivel az összes tûzfal a csomagok fejlécének bizonyos mezõinek alapján dolgozik, ezért a tûzfal szabályrendszerét megalkotó egyénnek teljesen tisztában kell lennie a TCP/IP mûködésével, továbbá azzal, hogy ezekben a mezõkben milyen értékek szerepelhetnek és ezeket hogyan használják egy átlagos kapcsolat alatt. Ebben a témában a címen találhatunk egy remek ismertetõt (angolul). John Ferrell Átnézte és aktualizálta: Az OpenBSD csomagszûrõje (PF) és az <acronym>ALTQ</acronym> tûzfalak PF 2003 júliusában az OpenBSD PF néven ismert csomagszûrõjét átírták &os;-re és elérhetõvé tették a &os; Portgyûjteményének részeként. A PF programot beépítetten tartalmazó elsõ kiadás pedig 2004 novemberében a &os; 5.3 volt. A PF egy teljes, mindentudó tûzfal, amely támogatja az ún. ALTQ (Alternate Queuing, vagyis a váltóbesorolás) megoldást. Az ALTQ lehetõvé teszi a sávszélesség korlátozását a szolgáltatás minõsége (Quality of Service, QoS) alapján. Az OpenBSD Projekt kiváló munkát végez a PF felhasználói útmutatójának karbantartásával. A kézikönyv ezen szakasza ezért elsõsorban azzal foglalkozik, hogyan kell a PF-et &os; alatt használni, miközben igyekszik egy általános összefoglalást adni a témáról. A részletesebb információkkal kapcsolatban azonban feltétlenül nézzük meg a felhasználói útmutatót. A címen olvashatunk többet arról (angolul), hogy a PF-et hogyan használjunk &os;-n. A PF rendszermagmodul használata A &os; 5.3 megjelenése óta a PF az alaprendszer része mint futás közben betölthetõ rendszermagmodul. A rendszer induláskor tehát képes automatikusan betölteni, ha az &man.rc.conf.5; állományban megadjuk a pf_enable="YES" sort. A PF modul azonban csak akkor fog mûködésbe lépni, ha talál hozzátartozó szabályrendszert, amely alapértelmezés szerint az /etc/pf.conf állományban található. Amennyiben a PF szabályrendszere a mi esetünkben máshol található, akkor az rc.conf állományban ne felejtsük megadni a pf_rules="/elérési/útvonal/pf.szabályok" sor használatával. A &os; 7.0 kiadással a minta pf.conf állomány az /etc könyvtárból átkerült a /usr/share/examples/pf könyvtárba. A &os; 7.0 elõtti kiadásokban alapértelmezés szerint található egy pf.conf állomány az /etc könyvtárban. A PF modul parancssorból akár kézzel is betölthetõ: &prompt.root; kldload pf.ko A betölthetõ modul tartalmazza a &man.pflog.4; támogatását, amely segítségével naplózni is tudunk. Amennyiben a PF további szolgáltatásaira is szükségünk lenne, akkor a PF támogatását be kell építenünk a rendszermagba. A PF rendszermagbeli beállításai a rendszermag beállításai device pf a rendszermag beállításai device pflog a rendszermag beállításai device pfsync Noha egyáltalán nem szükséges beépítenünk a PF támogatását a rendszermagba, abban az esetben mégis szükségünk lehet rá, amikor a PF olyan komolyabb lehetõségeit szeretnénk kiaknázni, amelyek már nem részei a modulnak. Ilyen például a &man.pfsync.4;, amely a PF által használt állapottáblázatok bizonyos változásainak megjelenítésére alkalmas pszeudoeszköz. A &man.carp.4; megoldásával párosítva így akár hibatûrõ tûzfalak is kialakíthatóak a PF-fel. A CARP megoldásáról a kézikönyvben bõvebb ismertetést a ad. A PF rendszermag konfigurációs beállításai a /usr/src/sys/conf/NOTES állományban találhatóak: device pf device pflog device pfsync A device pf beállítás engedélyezi a csomagszûrõ tûzfalat (&man.pf.4;). A device pflog megadásával keletkezik egy &man.pflog.4; pszeudo hálózati eszköz, amellyel egy &man.bpf.4; eszközre érkezõ forgalmat tudunk naplózni. Ezután a &man.pflogd.8; démon használható tõle származó naplózott adatok rögzítésére. A device pfsync engedélyezi a &man.pfsync.4; pszeudo hálózati eszköz létrejöttét, amely az ún. állapotváltások megfigyelésére alkalmas. Az <filename>rc.conf</filename> állományban elérhetõ beállítások A következõ &man.rc.conf.5; beállítások aktiválják a rendszerindítás során a PF és a &man.pflog.4; használatát: pf_enable="YES" # a PF engedélyezése (a modul betöltése, ha kell) pf_rules="/etc/pf.conf" # a pf szabályait tartalmazó állomány pf_flags="" # a pfctl indításához szükséges további paraméterek pflog_enable="YES" # a pflogd(8) elindítása pflog_logfile="/var/log/pflog" # hol tartsa a pflogd az naplóit pflog_flags="" # a pflogd indításához szükséges paraméterek Ha a tûzfalunk mögött egy helyi hálózat is meghúzódik, akkor az ott levõ gépek számára valamilyen módon tudnunk kell továbbítani a csomagokat vagy címfordítást kell végezni, így ez is mindenképpen kelleni fog: gateway_enable="YES" # az átjáró funkciók engedélyezése A szûrési szabályok megfogalmazása A PF a beállításait a &man.pf.conf.5; állomány tárolja (amely alapértelmezés szerint az /etc/pf.conf helyen található), és az ebben található szabályok alapján módosítja, dobja el vagy éppen engedi át a csomagokat. A &os; rendszerünkben ehhez találhatunk néhány példát a /usr/share/examples/pf/ könyvtárban. A PF által használt szabályokról minden részletre kiterjedõen a PF felhasználói útmutatójában olvashatunk. A PF felhasználói útmutatójának olvasásakor ne feledkezzünk meg róla, hogy a különbözõ &os; verziók különbözõ PF verziókat tartalmaznak: &os; 5.X — OpenBSD 3.5 PF &os; 6.X — OpenBSD 3.7 PF &os; 7.X — OpenBSD 4.1 PF A &a.pf; remek hely a PF tûzfal beállításával és futtatásával kapcsolatos kérdésekre. A kérdezés elõtt azonban ne felejtsük el alaposan átnézni az archívumot! A PF használata A PF a &man.pfctl.8; segítségével vezérelhetõ. Az alábbiakban ezzel kapcsolatban most összefoglalunk néhány hasznos parancsot (de ne felejtsük el megnézni a &man.pfctl.8; man oldalon található többi lehetõséget sem): Parancs Leírás pfctl A PF engedélyezése pfctl A PF tiltása pfctl all /etc/pf.conf Az összes (címfordítási, szûrési, állapottartási stb.) szabály törlése, és az /etc/pf.conf állomány újratöltése pfctl [ rules | nat | state ] A szûrési (rules), címfordítási (nat) és állapottartási (state) információk lekérdezése pfctl /etc/pf.conf Az /etc/pf.conf állomány ellenõrzése a benne levõ szabályok betöltése nélkül Az <acronym>ALTQ</acronym> engedélyezése Az ALTQ kizárólag csak úgy használható, ha a konfigurációs beállításokon keresztül beépítjük a &os; rendszermagjába. Az ALTQ alkalmazását nem minden hálózati kártya meghajtója támogatja, ezért ezt a &man.altq.4; man oldalon ellenõrizzük. A következõ rendszermag konfigurációs beállításokkal engedélyezhetjük az ALTQ használatát és bõvíthetjük azt további lehetõségekkel: options ALTQ options ALTQ_CBQ # osztályozás alapú besorolás (Class Bases Queuing, CBQ) options ALTQ_RED # véletlen korai észlelés (Random Early Detection, RED) options ALTQ_RIO # RED befele/kifele options ALTQ_HFSC # hiearchikus csomagütemezõ (Hierarchical Packet Scheduler, HFSC) options ALTQ_PRIQ # prioritásos besorolás (Priority Queuing, PRIQ) options ALTQ_NOPCC # az SMP esetén kell Az options ALTQ az ALTQ rendszert engedélyezi. Az options ALTQ_CBQ engedélyezi a osztályozás alapú besorolást (Class Based Queuing, CBQ). A CBQ használatával a kapcsolatunkhoz tartozó sávszélességet különbözõ osztályokra vagy sorokra tudjuk bontani és a szûrési szabályoknak megfelelõen osztályozni segítségükkel a forgalmat. Az options ALTQ_RED a véletlen korai észlelés (Random Early Detection, RED) használatát engedélyezi. A RED a hálózati forgalomban keletkezõ torlódások elkerülésére alkalmas. A RED ezt a problémát úgy oldja meg, hogy méri a sorok hosszát és összeveti a hozzátartozó minimális és maximális küszöbértékekkel. Ha a sor hossza meghaladja a számára elõírt maximális értéket, akkor az új csomagokat eldobja. Nevéhez hûen a RED az eldobásra ítélt csomagokat véletlenszerûen választja ki. Az options ALTQ_RIO engedélyezi a RED használatát mind a két irányba, tehát be- és kifelé. Az options ALTQ_HFSC a pártatlan hierachikus szolgáltatási görbe alapú csomagütemezõt (Hierarchical Fair Service Curve Packet Scheduler, HFSC) engedélyezi. Vele kapcsolatban a címen találhatunk bõvebben olvasnivalót (angolul). Az options ALTQ_PRIQ a prioritásos besorolást (Priority Queuing, PRIQ) teszi elérhetõvé. A PRIQ mindig elsõként a nagyobb értékû sorban levõ forgalmat továbbítja. Az options ALTQ_NOPCC az ALTQ SMP, vagyis többprocesszoros támogatását adja meg. Ilyen típusú rendszerekben ez kötelezõ. Az IPFILTER (IPF) tûzfal tûzfalak IPFILTER Az IPFILTER szerzõje Darren Reed. Az IPFILTER nem kötõdik egyik rendszerhez sem: ez egy olyan nyílt forráskódú alkalmazás, amelyet átírtak &os;, NetBSD, OpenBSD, &sunos;, HP/UX és &solaris; operációs rendszerekre. Az IPFILTER karbantartása és támogatása pillanatnyilag is aktív, folyamatosan jelennek meg újabb változatai. Az IPFILTER egy rendszermag oldalán mûködõ tûzfalazási és egy címfordítási mechanizmusra alapszik, amelyet felhasználói programokkal tudunk felügyelni és vezérelni. A tûzfal szabályai az &man.ipf.8; segédprogrammal állíthatóak be vagy törölhetõek. A hálózati címfordításra vonatkozó szabályokat az &man.ipnat.1; segédprogrammal állíthatjuk be vagy törölhetjük. Az &man.ipfstat.8; segédprogram képes futás közben statisztikákat készíteni az IPFILTER rendszermagban elhelyezkedõ részeinek viselkedésérõl. Az &man.ipmon.8; program pedig az IPFILTER cselekvéseit képes a rendszernaplókba feljegyezni. Az IPF eredetileg olyan szabályfeldolgozási módszer szerint készült, amelyben az utolsó egyezõ szabály nyer és csak állapotnélküli szabályokat ismert. Az idõ múlásával az IPF részévé vált a quick opció és a keep state opción keresztül az állapottartás is, melyek drámai mértékben korszerûsítették a szabályok feldolgozásának elvét. Az IPF hivatalos dokumentációja csak a régi szabályok létrehozását és azok feldolgozásának leírását tartalmazza. A korszerûsített funkciók csak kiegészítésképpen jelennek meg, és az általuk felkínált elõnyök megértése egy sokkal magasabb szintû és biztonságosabb tûzfal megépítését teszik lehetõvé. A szakaszban szereplõ utasításokban olyan szabályok szerepelnek, amelyek kihasználják a quick és keep state opciókat. Ezek az inkluzív tûzfalszabályok létrehozásának alapjai. A régi típusú szabályokról a és címeken olvashatunk (angolul). Az IPF gyakran ismételt kérdései a címen érhetõek el (angolul). A nyílt forrású IPFILTER levelezési lista kereshetõ archívumait a címen találjuk (angolul). Az IPF engedélyezése IPFILTER engedélyezés Az IPF megtalálható a &os; alaptelepítésében mint menet közben külön betölthetõ modul. Ha az rc.conf állományba beírjuk a ipfilter_enable="YES" sort, akkor ez a modul dinamikusan betöltõdik. A betölthetõ modul alapból naplóz és a default pass all beállítást tartalmazza. Ha helyette a block all szabályt akarjuk használni, akkor emiatt még nem kell feltétlenül újrafordítanunk a &os; rendszermagját, elég ha egyszerûen csak a szabályrendszerünk végére beszúrjuk. A rendszermag beállításai a rendszermag beállításai IPFILTER a rendszermag beállításai IPFILTER_LOG a rendszermag beállításai IPFILTER_DEFAULT_BLOCK IPFILTER a rendszermag beállításai Az IPF használatához nem kötelezõ a következõ beállításokkal újrafordítani a &os; rendszermagját, itt csupán háttérinformációként szerepel. Amikor az IPF a rendszermagba kerül, a betölhetõ modulra nem lesz szükség. Az IPF a rendszermag forrásai között található /usr/src/sys/conf/NOTES állományban megadott beállításai a következõ módon foglalhatóak össze: options IPFILTER options IPFILTER_LOG options IPFILTER_DEFAULT_BLOCK Az options IPFILTER engedélyezi az IPFILTER tûzfal támogatását. Az options IPFILTER_LOG hatására az IPF az ipl csomagnaplózó pszeudo eszközre jegyzi fel a forgalmat — minden olyan szabály esetén, ahol megjelenik a log kulcsszó. Az options IPFILTER_DEFAULT_BLOCK megváltoztatja az alapértelmezett viselkedést, tehát minden olyan csomag, amely nem illeszkedik a tûzfal valamelyik pass típusú (átengedõ) szabályára, blokkolásra kerül. Ezek a beállítások csak azt követõen érvényesülnek, ha fordítottunk és telepítettünk velük egy új rendszermagot. Az <filename>rc.conf</filename> állomány beállításai Az /etc/rc.conf állományban a következõ utasításokra lesz szükségünk az IPF mûködésbe hozására a rendszer indítása során: ipfilter_enable="YES" # az ipf tûzfal indítása ipfilter_rules="/etc/ipf.rules" # betölti a szabályokat tartalmazó szöveges állományt ipmon_enable="YES" # elindítja az IP monitor naplózását ipmon_flags="-Ds" # D = indítás démonként # s = naplózás a syslog használatával # v = a tcp ablak, ack, seq csomagok naplózása # n = az IP-címek és portok feloldása Ha olyan helyi hálózat áll meg a tûzfal mögött, amely egy fenntartott privát IP-címtartományt használ, akkor még a következõ utasításokra is szükségünk lesz a címfordítás bekapcsolásához: gateway_enable="YES" # a helyi hálózat átjárója ipnat_enable="YES" # az ipnat funkció elindítása ipnat_rules="/etc/ipnat.rules" # az ipnat mûködéséhez szükséges definíciók IPF ipf Az &man.ipf.8; parancs használható a szabályokat tartalmazó állomány betöltésére. Általában egy állományba írjuk össze a tûzfal szabályait és ezzel a paranccsal cseréljük le egyszerre a tûzfalban levõ jelenlegi szabályokat: &prompt.root; ipf -Fa -f /etc/ipf.rules Az az összes belsõ szabály törlését jelenti. Az jelzi, hogy egy állományból kell beolvasni a betöltendõ szabályokat. Ezzel mintegy lehetõségünk van változtatni a korábban összeállított szabályainkon, futtatni a fenti IPF parancsot és ezen keresztül úgy frissíteni a szabályok friss másolatával a már mûködõ tûzfalat, hogy nem is kell újraindítanunk a rendszert. Ez a módszer igen kényelmes az új szabályok kipróbálásához, mivel bármikor tetszõlegesen végrehajtható. Az &man.ipf.8; man oldala tartalmazza a parancsnak megadható további beállításokat. Az &man.ipf.8; parancs a szabályokat tároló állományt egy szabványos szöveges állománynak tekinti, semmilyen szimbolikus helyettesítést alkalmazó szkriptet nem fogad el. Lehetõségünk van azonban olyan IPF szabályokat készíteni, amelyek kiaknázzák a szkriptek szimbolikus helyettesítésének lehetõségeit. Errõl bõvebben lásd . Az IPFSTAT ipfstat IPFILTER statisztika Az &man.ipfstat.8; alapértelmezés szerint a arra használatos, hogy le tudjuk kérdezni és megjeleníteni a tûzfalhoz tartozó számlálók értékeit, amelyek a legutóbbi indítás vagy az ipf -Z parancs által kiadott lenullázásuk óta a bejövõ vagy kimenõ forgalomból a megadott szabályoknak megfelelõ csomagok alapján gyûjtenek össze statisztikákat. A parancs mûködésének részleteit az &man.ipfstat.8; man oldalon olvashatjuk. Az &man.ipfstat.8; meghívása alapból így néz ki: input packets: blocked 99286 passed 1255609 nomatch 14686 counted 0 output packets: blocked 4200 passed 1284345 nomatch 14687 counted 0 input packets logged: blocked 99286 passed 0 output packets logged: blocked 0 passed 0 packets logged: input 0 output 0 log failures: input 3898 output 0 fragment state(in): kept 0 lost 0 fragment state(out): kept 0 lost 0 packet state(in): kept 169364 lost 0 packet state(out): kept 431395 lost 0 ICMP replies: 0 TCP RSTs sent: 0 Result cache hits(in): 1215208 (out): 1098963 IN Pullups succeeded: 2 failed: 0 OUT Pullups succeeded: 0 failed: 0 Fastroute successes: 0 failures: 0 TCP cksum fails(in): 0 (out): 0 Packet log flags set: (0) Az mint bejövõ (inbound), vagy az mint kimenõ (outbound) forgalomra vonatkozó paraméterek megadásával a rendszermagban az adott oldalon jelenleg telepített és alkalmazott szabályokat kérhetjük le és jeleníthetjük meg. Az ipfstat -in parancs így a bejövõ forgalomra vonatkozó belsõ szabályokat mutatja a szabályok számával. Az ipfstat -on parancs a kimenõ forgalmat érintõ belsõ szabályokat mutatja a szabályok számával. Az eredmény körülbelül ilyen lesz: @1 pass out on xl0 from any to any @2 block out on dc0 from any to any @3 pass out quick on dc0 proto tcp/udp from any to any keep state Az ipfstat -ih a bejövõ forgalomhoz tartozó belsõ szabályokat mutatja és mindegyik elé odaírja, hogy eddig mennyi csomag illeszkedett rájuk. Az ipfstat -oh ugyanígy a kimentõ forgalom esetén mutatja a belsõ szabályokat és mindegyik elõtt feltünteti, hogy az adott pillanatig mennyi csomag illeszkedett rájuk. A kimenete nagyjából ilyen lesz: 2451423 pass out on xl0 from any to any 354727 block out on dc0 from any to any 430918 pass out quick on dc0 proto tcp/udp from any to any keep state Az ipfstat parancs talán egyik legfontosabb funkciója a kapcsolóval csalható elõ, melynek hatására a rendszerben aktív állapotok táblázatát mutatja meg ugyanúgy, ahogy a &man.top.1; a &os; rendszerben futó programokat. Amikor a tûzfalunk támadás alatt áll, ezzel a funkcióval tudjuk a problémát beazonosítani, leásni a mélyébe és látni a támadótól érkezõ csomagokat. A kiegészítésképpen megadható alkapcsolók megadásával kiválaszthatjuk azt a cél vagy forrás IP-címet, portot vagy protokollt, amelyet valós idõben meg akarunk figyelni. Ennek részleteit az &man.ipfstat.8; man oldalán láthatjuk. Az IPMON ipmon IPFILTER naplózás Az ipmon megfelelõ mûködéséhez be kell kapcsolnunk a rendszermag IPFILTER_LOG beállítását. Ez a parancs két különbözõ módban használható. Ha parancsot a opció nélkül gépeljük be, akkor ezek közül alapból a natív módot kapjuk meg. A démon mód abban az esetben hasznos, ha folyamatosan naplózni akarjuk a rendszerben zajló eseményeket, majd késõbb ezeket átnézni. Így képes egymással együttmûködni a &os; és az IPFILTER. A &os; beépítve tartalmaz olyan lehetõséget, aminek révén magától cseréli a rendszernaplókat. Ezért ha átküldjük a &man.syslogd.8; démonnak a naplózandó üzeneteket, akkor sokkal jobban járunk, mintha egyszerûen csak mezei állományba naplóznánk. Az rc.conf alapértelmezései között az ipmon_flags beállítás a kapcsolókat rögzíti: ipmon_flags="-Ds" # D = indítás démonként # s = naplózás a syslog használatával # v = a tcp ablak, ack, seq csomagok naplózása # n = az IP-címek és portok nevének feloldása Ennek a viselkedésnek az elõnyei minden bizonnyal egyértelmûek. Segítségével képesek vagyunk az esetek megtörténte után átnézni, hogyan milyen csomagokat dobott el a rendszer, azok milyen címekrõl érkeztek és hova szánták. Ez egy komoly fegyver a támadók lenyomozásában. Hiába engedélyezzük a naplózást, az IPF önszántából semmilyen naplózási szabályt nem fog gyártani. A tûzfal gazdájának kell eldöntenie, hogy a szabályokat közül melyiket akarja naplózni, és így neki kell megadnia a log kulcsszót ezekben az esetekben. Normális esetben csak a deny szabályokat naplózzák. Egyáltalán nem ritka, hogy a szabályrendszer végén egy alapértelmezés szerint mindent eldobó szabály áll, amely naplóz. Ezzel lehetõségünk nyílik rögzíteni azokat a csomagokat, amelyek egyetlen szabályra sem illeszkedtek. Naplózás az IPMON használatával A syslogd egy saját módszert alkalmaz a naplózott adatok elkülönítésére. Egy funkciók (facility) és szintek (level) segítségével kialakított speciális csoportosítást alkalmaz. Az IPMON módja a security (biztonság) funkciót használja. Tehát az IPMON által naplózott összes adat a security csoportjába kerül. Ezen túl a következõ szinteken különíthetjük el igényeinknek megfelelõen a naplózott adatokat: LOG_INFO - az átengedés vagy blokkolás helyett a "log" kulcsszóval ellátott csomagok LOG_NOTICE - az át is engedett csomagok LOG_WARNING - a blokkolt csomagok LOG_ERR - a naplózott csomagok közül azok, amelyek túlságosan kicsik (hibás a fejlécük) Az IPFILTER csak akkor tud naplózni a /var/log/ipfilter.log állományba, ha elõtte létrehozzuk. Az alábbi parancs erre tökéletesen megfelelõ: &prompt.root; touch /var/log/ipfilter.log A &man.syslogd.8; mûködését az /etc/syslog.conf állományban szereplõ definíciók vezérlik. A syslog.conf állomány számottevõ mértékben képes meghatározni azt, ahogy a syslog az IPF és a hozzá hasonló alkalmazásoktól kapott rendszerszintû üzeneteket kezeli. Az /etc/syslog.conf állományba az alábbi sor kell felvennünk: security.* /var/log/ipfilter.log A security.* megadásával az összes ilyen típusú üzenet egy elõre rögzített helyre kerül. Az /etc/syslog.conf állományban elvégzett módosításokat úgy léptethetjük érvénybe, ha újraindítjuk a számítógépet vagy az /etc/rc.d/syslogd reload paranccsal megkérjük a &man.syslogd.8; démont, hogy olvassa újra az /etc/syslog.conf állományt. Az imént létrehozott naplót ne felejtsük el megadni az /etc/newsyslog.conf állományban sem, és akkor ezzel a cseréjét is megoldjuk. A naplózott üzenetek formátuma Az ipmon által létrehozott üzenetek whitespace karakterekkel elválasztott adatmezõkbõl állnak. A következõ mezõk az összes üzenet esetében megjelennek: A csomag megérkezésének dátuma A csomag megérkezésének idõpontja. ÓÓ:PP:MM.E alakban jelennek meg az órák, percek, másodpercek és ezredmásodpercek (ez több számjegy hosszú is lehet) szerint Azon interfész a neve, ahol a csomag feldolgozásra került, például dc0 A szabályhoz tartozó csoport és sorszám, például @0:17 Ezek az ipfstat -in paranccsal nézhetõek meg. Cselekvés: a p mint átment (passed), b mint blokkolt (blocked), S mint rövid csomag (short packet), n mint egyik szabályra sem illeszkedett (not match), L mint naplózás (log). A módosítók megjelenítésének sorrendje: S, p, b, n, L. A nagybetûs P és B azt jelzi, hogy a csomagot egy felsõbb szintû beállítás miatt naplózták, nem egy szabály hatására. Címek: ez tulajdonképpen három mezõt takar: a forrás címet és portot (melyet egy vesszõ választ el), a -> jelet és cél címet és portot. Például: 209.53.17.22,80 -> 198.73.220.17,1722. A PR után a protokoll neve vagy száma olvasható, például PR tcp. A len csomaghoz tartozó fejléc és törzsének teljes hosszát jelöli, például len 20 40. Amennyiben a csomag TCP, egy kötõjellel kezdõdõen további mezõk is megjelenhetnek a beállított opcióknak megfelelõ betûk képében. A betûket és beállításaikat az &man.ipmon.8; man oldalán olvashatjuk. Amennyiben a csomag ICMP, a sort két mezõ zárja, melyek közül az elsõ tartalma mindig ICMP, és ezt egy perjellel elválasztva az ICMP üzenet típusa és altípusa követi. Tehát például az ICMP 3/3 a nem elérhetõ port üzenetet hordozza. A szabályok felírása szimbolikus helyettesítéssel Az IPF használatában gyakorlott felhasználók közül néhányan képesek olyan stílusú szabályrendszert készíteni, ahol szimbolikus helyettesítést használnak. Ennek az egyik legnagyobb elõnye az, hogy ilyenkor elég csak a szimbolikus névhez tartozó értéket megváltoztatni és amikor a szkript lefut, akkor az összes rá hivatkozó szabályba ez kerül be. Szkript lévén a szimbolikus helyettesítéssel ki tudjuk emelni a gyakran használt értékeket és behelyettesíteni ezeket több helyre. Ezt a most következõ példában láthatjuk. Az itt alkalmazott felírás kompatibilis az &man.sh.1;, &man.csh.1; és &man.tcsh.1; parancsértelmezõkkel. A szimbolikus helyettesítést egy dollárjellel fejezzük ki: $. A szimbolikus mezõkben nem szerepel a $ jelölés. A szimbolikus mezõ tartalmát kettõs idézõjelbe (") tesszük. Kezdjük így el a szabályok írását: ######### Az IPF szabályait tartalmazó szkript eleje ########### oif="dc0" # a kimenõ interfész neve odns="192.0.2.11" # az internet szolgáltató névszerverének IP-címe myip="192.0.2.7" # a szolgáltatótól kapott statikus IP-címünk ks="keep state" fks="flags S keep state" # Választhatunk, hogy az /etc/ipf.rules állományt ebbõl a szkriptbõl # hozzuk létre vagy futtathatjuk "magát" a szkriptet. # # Egyszerre csak az egyik sort használjuk. # # 1) Ezzel gyárhatjuk le az /etc/ipf.rules állományt: #cat > /etc/ipf.rules << EOF # # 2) Ezzel futtathajuk "magát" a szkriptet: /sbin/ipf -Fa -f - << EOF # Engedélyezzük a szolgáltató névszerverének elérését. pass out quick on $oif proto tcp from any to $odns port = 53 $fks pass out quick on $oif proto udp from any to $odns port = 53 $ks # Engedélyezzük kifelé a titkosítatlan www funkciót. pass out quick on $oif proto tcp from $myip to any port = 80 $fks # Engedélyezzük kifelé a TLS SSL felett üzemelõ titkosított www funkciót. pass out quick on $oif proto tcp from $myip to any port = 443 $fks EOF ################## Itt az IPF szkript vége ######################## Ennyi lenne. A példában szereplõ szabályok most nem annyira lényegesek, a hangsúly most igazából a szimbolikus helyettesítésen és annak használatán van. Ha a fenti példát az /etc/ipf.rules.script állományba mentjük, akkor ezeket a szabályokat a következõ paranccsal újra tudjuk tölteni: &prompt.root; sh /etc/ipf.rules.script Egyetlen aprócska gond van a beágyazott szimbólumokat tartalmazó állományokkal: az IPF maga nem képes megérteni a helyettesítéseket, azért közvetlenül nem olvassa a szkriptet. Ez a szkript két módon hasznosítható: Vegyük ki megjegyzésbõl a cat paranccsal kezdõdõ sort, és tegyük megjegyzésbe az /sbin/ipf kezdetût. A megszokottak szerint tegyük az ipfilter_enable="YES" sort az /etc/rc.conf állományba, majd minden egyes módosítása után futtassuk le a szkriptet az /etc/ipf.rules állomány létrehozásához vagy frissítéséhez. Tiltsuk le az IPFILTER aktiválását a rendszerindításkor, tehát írjuk bele az ipfilter_enable="NO" sort (ami mellesleg az alapértelmezett értéke) az /etc/rc.conf állományba. Tegyünk egy, az alábbi szkripthez hasonlót az /usr/local/etc/rc.d/ könyvtárba. A szkriptnek adjuk valamilyen értelmes nevet, például ipf.loadrules.sh. Az .sh kiterjesztés használata kötelezõ. #!/bin/sh sh /etc/ipf.rules.script A szkript engedélyeit állítsuk be úgy, hogy a root tulajdonában legyen és képes legyen olvasni, írni valamint végrehajtani. &prompt.root; chmod 700 /usr/local/etc/rc.d/ipf.loadrules.sh Most miután a rendszer elindult, az IPF szabályai be fognak töltõdni. Szabályrendszerek az IPF-ben Az IPF esetében a szabályrendszer olyan szabályokból áll, amelyek a csomagokról tartalmuk alapján eldöntik, hogy át kell engedni vagy vissza kell tartani. A gépek közt két irányban áramló csomagok egy munkamenet alapú társalgást képeznek. A tûzfalhoz tartozó szabályrendszer egyaránt feldolgozza a internetrõl a hálózatunk felé igyekvõ csomagokat, illetve a hálózatunk ezekre adott válaszait. Az egyes TCP/IP szolgáltatásokat (mint például telnet, www, levelezés stb.) a hozzájuk tartozó protokol és szabványos (fogadó) portszám írja le. Ezekre a forrásról általában valamilyen nem szabványos (magasabb értékû) portról érkeznek csomagok. Ekkor a kommunikáció összes paramétere (vagyis a portok és címek) bármelyike alapján definiálhatunk blokkolást vagy továbbengedést leíró szabályokat. IPFILTER a szabályok feldolgozásának sorrendje Az IPF eredetileg úgy íródott, hogy a szabályokat az utolsó illeszkedõ szabály nyer stílusban dolgozza fel és csak állapot nélküli szabályokat ismert. Az idõk folyamán az IPF szabályai kiegészültek a quick és az állapottartásra vonatkozó keep state opciókkal, amelynek köszönhetõen óriási mértékben korszerûsödött a szabályok feldolgozása. A szakaszban szereplõ utasítások olyan szabályokat alkalmaznak, amelyekben egyaránt szerepel a quick és az állapottartásért felelõs keep state beállítás. Ez az inkluzív tûzfalak létrehozásának egyik alapeszköze. A tûzfal szabályainak összeállítása során nagyon óvatosnak kell lennünk! Bizonyos beállítások hatására akár ki is zárhatjuk magunkat a szerverünkrõl. Az ebbõl fakadó esetleges kellemetlenségek elkerülése érdekében javasoljuk, hogy a tûzfal alapjait elõször helyi konzolról építsük fel, ne pedig távolról, például ssh segítségével. A szabályok felépítése IPFILTER a szabályok felépítése A szabályok felépítésének bemutatását itt most leszûkítjük a modern állapottartó szabályokra és az elsõ illeszkedõ szabály nyer típusú feldolgozásra. A szabályok felírásának régebbi módjai az &man.ipf.8; man oldalon találhatóak. A # karakterrel egy megjegyzés kezdetét jelezzük, és általában a sor végén vagy egy külön sorban bukkan fel. Az üres sorokat a rendszer nem veszi figyelembe. A szabályok kulcsszavakat tartalmaznak. Ezeknek a kulcsszavaknak balról jobbra haladva adott sorrendben kell szerepelniük. A kulcsszavakat kiemeltük. Egyes kulcsszavakhoz további beállítások is tartozhatnak, amelyek maguk is kulcsszavak lehetnek, és még további opciókkal rendelkezhetnek. Az alábbi nyelvtan mindegyik elemét kiemeltük és az alábbiakban egyenként kifejtjük a részleteiket. CSELEKVÉS BE-KI OPCIÓK SZÛRÉS ÁLLAPOTTARTÓ PROTOKOLL FORRÁS_CÍM,CÉL_CÍM OBJEKTUM PORTSZÁM TCP_BEÁLLÍTÁS ÁLLAPOTTARTÓ CSELEKVÉS = block | pass BE-KI = in | out OPCIÓK = log | quick | on interfész SZÛRÉS = proto érték | forrás/cél IP | port = szám | flags beállítás PROTOKOLL = tcp/udp | udp | tcp | icmp FORRÁS_CÍM,CÉL_CÍM = all | from objektum to objektum OBJEKTUM = IP-cím | any PORTSZÁM = portszám TCP_BEÁLLÍTÁS = S ÁLLAPOTTARTÓ = keep state CSELEKVÉS A cselekvés határozza meg, hogy mit kell tenni azokkal a csomagokkal, amelyek illeszkednek a szabály többi részére. Minden szabályhoz tartoznia kell egy cselekvésnek. A következõ cselekvések közül választhatunk: A block megadásával a szabályban szereplõ szûrési feltételre illeszkedõ csomagot eldobjuk. A pass megadásával a szabályban szereplõ szûrési feltételre illeszkedõ csomagot átengedjük a tûzfalon. BE-KI Az összes szûrési szabály esetében kötelezõ egyértelmûen nyilatkozunk arról, hogy a bemenõ vagy a kimenõ forgalomra vonatkozik. Ezért a következõ kulcsszó vagy az in vagy pedig az out, de közülük egyszerre csak az egyiket szabad használni, máskülönben a szabály hibásnak minõsül. Az in jelenti, hogy a szabályt az internet felõl az adott interfészen beérkezõ csomagokra kell alkalmazni. Az out jelenti, hogy a szabályt az internet felé az adott interfészen kiküldött csomagokra kell alkalmazni. OPCIÓK Ezek az opciók csak a lentebb bemutatott sorrendben használhatók. A log jelzi, hogy illeszkedés esetén a csomag fejlécét az ipl eszközön keresztül naplózni kell (lásd a naplózásról szóló szakaszt). A quickjelzi, hogy illeszkedés esetén ez lesz a legutolsónak ellenõrzött szabály és így egy olyan rövidzárat tudunk képezni a feldolgozásban, amellyel elkerüljük a csomagra egyébként vonatkozó többi szabály illesztését. Ez az opció a korszerûsített szabályfeldolgozás kihasználásához elengedhetetlen. Az on használatával a szûrés feltételei közé bevonhatjuk a csomaghoz tartozó hálózati interfészt. Itt az interfészek az &man.ifconfig.8; által megjelenített formában adhatóak meg. Az opció megadásával csak az adott interfészen az adott irányba (befelé/kifelé) közlekedõ csomagokra fog illeszkedni a szabály. Ez az opció a korszerûsített szabályfeldolgozás kihasználásához nélkülözhetetlen. Amikor naplózunk egy csomagot, akkor a hozzátartozó fejléc az IPL csomagnaplózó pszeudo eszközhöz kerül. A log kulcsszó után közvetlenül a következõ minõsítõk szerepelhetnek (a következõ sorrendben): A body jelzi, hogy a csomag tartalmának elsõ 128 byte-ját még jegyezzük fel a fejléc mellé. A first minõsítõt akkor érdemes használnunk, amikor a log kulcsszót a keep state opcióval együtt alkalmazzuk, mivel ilyenkor csak a szabályt kialakító csomag kerül naplózásra és nem minden olyan, ami illeszkedik az állapottartási feltételekre. SZÛRÉS Ebben a szakaszban olyan kulcsszavak jelenhetnek meg, amelyekkel a csomagok különféle tulajdonságai alapján ítélkezhetünk azok illeszkedésérõl. Itt adott egy kiinduló kulcsszó, amelyhez további kulcsszavak is tartoznak, és amelyek közül csak egyet választhatunk. Az alábbi általános tulajdonságok alapján tudjuk szûrni a csomagokat, ebben a sorrendben: PROTOKOLL A proto egy olyan kulcsszó, amelyhez hozzá kell rendelnünk még valamelyik opcióját is. Ez az opció segít az adott protokolloknak megfelelõen válogatni a csomagok között. A korszerûsített szabályfeldolgozás lehetõségeinek kihasználásához nélkülözhetetlen. Opcióként a tcp/udp | udp | tcp | icmp, vagy bármelyik, az /etc/protocols állományban megtalálható kulcsszó felhasználható. A tcp/udp ebbõl a szempontból speciálisnak tekinthetõ, mivel hatására egyszerre illeszthetõek a szabályra a TCP és UDP csomagok, és így a protokolltól eltekintve azonos szabályok felesleges többszörözését kerülhetjük el. FORRÁS_CÍM/CÉL_CÍM Az all kulcsszó gyakorlatilag a from any to any (bárhonnan bárhova) szinonímája és nem tartozik hozzá paraméter. A from forrás to cél felépítése: a from és to kulcsszavak az IP-címek illesztésére használhatóak. Ilyenkor a szabályokban a forrás és a cél paramétereknek is szerepelniük kell. Az any egy olyan speciális kulcsszó, amely tetszõleges IP-címre illeszkedik. Néhány példa az alkalmazására: from any to any vagy from 0.0.0.0/0 to any, from any to 0.0.0.0/0, from 0.0.0.0/0 to any vagy from any to 0.0.0.0. Az IP-címek megadhatóak pontozott numerikus formában a hálózati maszk bitekben mért hosszával együtt, vagy akár egyetlen pontozott numerikus IP-címként. Nincs lehetõség olyan IP-címtartományok illesztésére, amelyek nem adhatóak meg kényelmesen ponttal elválasztott számok és maszk hosszával. A net-mgmt/ipcalc port az ilyen számításokat könnyíti meg. A hálózati maszkok hosszának megállapításban segíthet az említett segédprogram (angol nyelvû) honlapja: . PORT Amikor portra vonatkozó illeszkedést írunk elõ, megadhatjuk a forrásra és célra, amit aztán vagy csak TCP vagy pedig csak UDP csomagokra alkalmazunk. A portok feltételeinek megfogalmazásánál használhatjuk a portok számát vagy az /etc/services állományban szereplõ nevüket. Amikor a port egy from típusú objektum leírásában jelenik meg, akkor automatikusan a forrásportot jelenti, míg a to objektum leírásában pedig a célportot. A to objektumoknál a port megadása elengedhetetlen a korszerûsített szabályfeldolgozás elõnyeinek kihasználásához. Példa: from any to any port = 80. Az egyes portokat különbözõ mûveletek segítségével, numerikusan hasonlíthatjuk össze, ahol akár porttartományt is megadhatunk. port "=" | "!=" | "<" | ">" | "<=" | ">=" | "eq" | "ne" | "lt" | "gt" | "le" | "ge". A porttartományok megadásához használjuk a port "<>" | "><" felírási módot. A forrásra és célra vonatkozó paraméterek után szereplõ másik két paraméter nélkülözhetetlen a korszerûsített szabályfeldolgozás mûködéséhez. <acronym>TCP</acronym>_BEÁLLÍTÁS A beállítások csak a TCP forgalom szûrésénél érvényesülnek. A betûk jelölik azokat a lehetséges beállításokat, amelyek a TCP csomagok fejlécében megvizsgálhatóak. A korszerûsített szabályfeldolgozás a flags S paraméter segítségével ismeri fel a TCP munkameneteket kezdeményezõ kéréseket. ÁLLAPOTTARTÓ A keep state jelzi, hogy a szabály paramétereinek megfelelõ bármely csomag aktiválja az állapottartó szûrés használatát. Ez a beállítás feltétlenül szükséges a korszerûsített szabályfeldolgozás megfelelõ kihasználásához. Állapottartó csomagszûrés IPFILTER állapottartó szûrés Az állapottartó szûrés a csomagok kétirányú áramlását egy létrejött kapcsolatba sorolja be. Amikor aktiválódik, az állapottartó szabály elõre dinamikusan létrehozza a kétirányú kommunikációban megforduló csomagokhoz a megfelelõ belsõ szabályokat. Olyan vizsgálatokat végez, amelyek segítségével ki tudja deríteni, hogy a csomag küldõje és címzettje között fennálló kétirányú kapcsolat érvényes szabályok szerint zajlik-e. Minden olyan csomagot, amely nem illeszkedik megfelelõen a kapcsolatra vonatkozó sémára, csalásnak tekintjük és automatikusan eldobjuk. Az állapottartás révén lehetõségünk van a TCP vagy UDP kapcsolatokhoz tartozó ICMP csomagokat is átengedni a tûzfalon. Tehát ha kapunk egy 3-as típusú, 4-es kódú ICMP választ valamilyen böngészésre használt állapottartó szabályon keresztül kiküldött kérésre, akkor az automatikusan bejöhet. Amelyik csomagot az IPF egyértelmûen képes besorolni az aktív kapcsolatba, még ha az eltérõ protokollt is használ, beengedi. Ami ilyenkor történik: Az internethez csatlakozó interfészen keresztül kifelé haladó csomagokat elõször egy dinamikus állapottábla alapján illesztjük, és ha a csomag illeszkedik az aktív kapcsolatban következõként várt csomagra, akkor átmegy a tûzfalon és a dinamikus állapottáblában frissül a kapcsolat állapota. Az aktív munkameneten kívül csomagok pedig egyszerûen a kimenõ szabályrendszer szerint kerülnek ellenõrzésre. Hasonlóan az elõzõhöz, az internethez csatlakozó interfészen keresztül befelé haladó csomagokat elõször egy dinamikus állapottábla alapján illesztjük, és ha a csomag illeszkedik az aktív kapcsolatban következõként várt csomagra, akkor átmegy a tûzfalon és a dinamikus állapottáblában frissül a kapcsolat állapota. Az aktív munkamenethez nem tartozó csomagok pedig egyszerûen a bejövõ szabályrendszer szerint kerülnek ellenõrzésre. Amikor egy kapcsolat befejezõdik, automatikusan törlõdik a dinamikus állapottáblából. Az állapottartó csomagszûrés használatával az újonnan keletkezõ kapcsolatok elutasítására vagy engedélyezésére tudunk koncentrálni. Ha engedélyeztük egy új kapcsolat létrejöttét, akkor a rákövetkezõ összes többi csomag automatikusan átmegy a tûzfalon és minden más hamis csomag eldobódik. Ha tiltjuk az új kapcsolatot, akkor egyetlen rákövetkezõ csomag sem juthat át. Az állapottartó szûrés által felkínált fejlett elemzési lehetõségek képesek védelmet nyújtani a behatolók részérõl alkalmazott megannyi különbözõ támadási módszer ellen. Példa inkluzív szabályrendszerre A most következõ szabályrendszer arra mutat példát, hogyan programozzunk le egy nagyon biztonságos inkluzív tûzfalat. Az inkluzív tûzfalak csak a szabályainak megfelelõ szolgáltatásokat engedik keresztül, és alapértelmezés szerint minden mást blokkolnak. Egy hálózat gépeit védõ tûzfalnak, amelyet gyakran hálózati tûzfalnak (network firewall) is neveznek, legalább két hálózati interfésszel kell rendelkeznie. Ezeket az interfészeket általában úgy állítják be, hogy tökéletesen megbíznak az egyik oldalban (a helyi hálózatban), a másikban (az internetben) pedig egyáltalán nem. A tûzfalat egyébként úgy is beállíthatjuk, hogy csak a tûzfalat mûködtetõ gépet védje — ezt egyrendszeres tûzfalnak (host based firewall) nevezik. Az ilyen típusú megoldásokat nem biztonságos hálózaton keresztül kommunikáló szervereknél alkalmaznak. Mindegyik &unix;-típusú rendszert, köztük a &os;-t is úgy alakították ki, hogy az operációs rendszeren belüli kommunikáció az lo0 interfészen és a 127.0.0.1 IP-címen keresztül történik. A tûzfal szabályai között feltétlenül szerepelniük kell olyanoknak, amelyek lehetõvé teszik ezen a speciális intefészen a csomagok zavartalan mozgását. Az internetre csatlakozó interfészhez kell rendelni a kifelé és befelé haladó forgalom hitelesítését é a hozzáférésének vezérlését. Ez lehet a felhasználói PPP által létrehozott tun0 interfész vagy a DSL-, illetve kábelmodemhez csatlakozó hálózati kártya. Ahol egy vagy több hálózati kártya is csatlakozik több különbözõ helyi hálózathoz, úgy kell beállítani a hozzájuk tartozó interfészeket, hogy egymás felé és az internet felé képesek legyenek küldeni és fogadni. A szabályokat elõször három nagy csoportba kell szerveznünk: elõször jönnek a megbízható interfészek, ezeket követik az internet felé mutató interfészek, végül internet felõl jövõ, nem megbízható interfészeke. Az egyes csoportokban szereplõ szabályokat úgy kell megadni, hogy közülük elõre kerüljenek a leggyakrabban alkalmazottak, és a csoport utolsó szabálya blokkoljon és naplózzon minden csomagot az adott interfészen és irányban. A kimenõ forgalomat vezérlõ szabályrendszer csak pass (tehát átengedõ) szabályokat tartalmazhat, amelyek bentrõl az interneten elérhetõ szolgáltatásokat azonosítják egyértelmûen. Az összes ilyen szabályban meg kell jelenni a quick, on, proto, port és keep state beállításoknak. A proto tcp szabályok esetében meg kell adni a flag opciót is, amivel fel tudjuk ismertetni a kapcsolatok keletkezését és ezen keresztül aktiválni az állapottartást. A bejövõ forgalmat vezérlõ szabályrendszerben elõször az eldobni kívánt csomagokat kell megadni, aminek két eltérõ oka van. Elõször is elõfordulhat, hogy a veszélyes csomagok részleges illeszkedés miatt szabályosnak tûnnek. Az ilyen csomagokat értelemszerûen nem lenne szabad beengedni a szabályok részleges megfelelése alapján. A másodszor az eleve ismerten problémás és értelmetlen csomagokat csendben el kellene vetni, mielõtt a szakaszhoz tartozó utolsó szabály fogná meg és naplózná. Ez az utolsó szabály egyébként szükség esetén felhasználható a támadók elleni bizonyítékok begyûjtésére. A másik, amire még oda kell figyelnünk, hogy a blokkolt csomagok esetében semmilyen válasz nem keletkezzen, egyszerûen csak tûnjenek el. Így a támadó nem fogja tudni, hogy a csomagjai vajon elérték-e a rendszerünket. Minél kevesebb információt tudnak összegyûjteni a rendszerünkrõl a támadók, annál több idõt kell szánniuk csínytevéseik kieszelésére. A log first opciót tartalmazó szabályok csak az illeszkedésnél fogják naplózni a hozzájuk tartozó eseményt. Erre láthatunk példát az nmap OS fingerprint szabálynál. Az security/nmap segédprogramot a támadók gyakran alkalmazzák a megtámadni kívánt szerver operációs rendszerének felderítésére. Minden log first opcióval megadott szabály illeszkedésénél a ipfstat -hio parancs meghatározódik az eddigi illeszkedések aktuális száma. Nagyobb értékek esetében következtethetünk arra, hogy a rendszerünket megtámadták (vagyis csomagokkal árasztják éppen el). Az ismeretlen portszámok felderítésére az /etc/services állomány, esetleg a (angol nyelvû) honlap használható. Érdemes továbbá megnézni a trójai programok által használt portokat a címen (angolul). A következõ szabályrendszer egy olyan biztonságos inkluzív típusú tûzfal, amelyet éles rendszeren is használnak. Ezt a rendszerünkön nem használt szolgáltatásokra vonatkozó pass szabályok törlésével könnyedén a saját igényeink szerint alakíthatjuk. Ha nem akarunk látni bizonyos üzeneteket, akkor vegyünk fel hozzájuk egy block típusú szabályt a befelé irányuló forgalomhoz tartozó szabályok közé. A szabályokban írjuk át a dc0 interfész nevét annak a hálózati kártyának az interfészére, amelyen keresztül csatlakozunk az internethez. A felhasználói PPP esetében ez a tun0 lesz. Tehát a következõket kell beírni az /etc/ipf.rules állományba: ################################################################# # A helyi hálózatunkon zajló forgalmat ne korlátozzuk. # Csak akkor kell, ha helyi hálózathoz is csatlakozunk. ################################################################# #pass out quick on xl0 all #pass in quick on xl0 all ################################################################# # A belsõ interfészen szintén ne korlátozzunk semmit. ################################################################# pass in quick on lo0 all pass out quick on lo0 all ################################################################# # Az internet felé forgalmazó interfész (kimenõ kapcsolatok) # A saját hálózatunkról belülrõl vagy errõl az átjáróról # kezdeményezett kapcsolatokat vizsgáljuk az internet felé. ################################################################# # Engedélyezzük az internet szolgáltatók névszerverének elérését, # az "xxx" helyett a névszervet IP-címét kell megadni. # Másoljuk le ezeket a sorokat, ha a szolgáltatónknak több # névszerverét is beakarjuk állítani. A címeiket az /etc/resolv.conf # állományban találjuk. pass out quick on dc0 proto tcp from any to xxx port = 53 flags S keep state pass out quick on dc0 proto udp from any to xxx port = 53 keep state # DSL vagy kábeles hálózatoknál engedélyezzük a # szolgáltatónk DHCP szerverének elérését. # Ez a szabály nem kell, ha "felhasználói PPP"-vel # kapcsolódunk az internethez, ilyenkor tehát az egész # csoport törölhetõ. # Használjuk az alábbi szabályt és keressük meg a naplóban az # IP-címet. Ha megtaláltuk, akkor tegyük bele a megjegyzésben # szereplõ szabályba és töröljük az elsõ szabályt. pass out log quick on dc0 proto udp from any to any port = 67 keep state #pass out quick on dc0 proto udp from any to z.z.z.z port = 67 keep state # Kifelé engedélyezzük a szabványos nem biztonságos WWW funkciókat. pass out quick on dc0 proto tcp from any to any port = 80 flags S keep state # Kifelé engedélyezzük a biztonságos WWW funkciókat TLS SSL # protokollal. pass out quick on dc0 proto tcp from any to any port = 443 flags S keep state # Kifelé engedélyezzük az e-mailek küldését és fogadását. pass out quick on dc0 proto tcp from any to any port = 110 flags S keep state pass out quick on dc0 proto tcp from any to any port = 25 flags S keep state # Kifelé engedélyezzük az idõ szolgáltatást. pass out quick on dc0 proto tcp from any to any port = 37 flags S keep state # Kifelé engedélyezzük az nntp híreket. pass out quick on dc0 proto tcp from any to any port = 119 flags S keep state # Kifelé engedélyezzük az átjáróról és a helyi hálózatról a nem # biztonságos FTP használatát (passzív és akív módokban is). Ez a # funkció a mûködéséhez a nat szabályokat tartalmazó állományban # hivatkozott FTP proxyt használja. Amennyiben a pkg_add paranccsal # csomagokat akarunk telepíteni az átjáróra, erre a szabályra # mindenképpen szükségünk lesz. pass out quick on dc0 proto tcp from any to any port = 21 flags S keep state # Kifelé engedélyezzük az ssh/sftp/scp # (biztonságos telnet/rlogin/FTP) # szolgáltatások # elérését az SSH (secure shell) használatával. pass out quick on dc0 proto tcp from any to any port = 22 flags S keep state # Kifelé engedélyezzük a nem biztonságos telnet elérését. pass out quick on dc0 proto tcp from any to any port = 23 flags S keep state # Kifelé engedélyezzük FreeBSD CVSUp funkcióját. pass out quick on dc0 proto tcp from any to any port = 5999 flags S keep state # Kifelé engedélyezzük a pinget. pass out quick on dc0 proto icmp from any to any icmp-type 8 keep state # Kifelé engedélyezzük a helyi hálózatról érkezõ whois kéréseket. pass out quick on dc0 proto tcp from any to any port = 43 flags S keep state # Minden mást eldobunk és naplózzuk az elsõ elõfordulásukat. # Ez a szabály blokkol alapértelmezés szerint mindent. block out log first quick on dc0 all ################################################################# # Az internet felõli interfész (bejövõ kapcsolatok) # A saját hálózatunk felé vagy erre az átjáróra # nyitott kapcsolatokat vizsgáljuk az internet felõl. ################################################################# # Eldobjuk az összes olyan bejövõ forgalmat, amit hivatalosan nem # lehetne továbbítani vagy fenntartott címterülethez tartozik. block in quick on dc0 from 192.168.0.0/16 to any #RFC 1918: privát IP block in quick on dc0 from 172.16.0.0/12 to any #RFC 1918: privát IP block in quick on dc0 from 10.0.0.0/8 to any #RFC 1918: privát IP block in quick on dc0 from 127.0.0.0/8 to any #helyi block in quick on dc0 from 0.0.0.0/8 to any #helyi block in quick on dc0 from 169.254.0.0/16 to any #DHCP block in quick on dc0 from 192.0.2.0/24 to any #dokumentációs célokra fenntartva block in quick on dc0 from 204.152.64.0/23 to any #Sun klaszterek összekötésére használt block in quick on dc0 from 224.0.0.0/3 to any #D és E osztályú multicast ##### Itt eldobunk egy rakás csúf dolgot ############ # Ezeket nem akarjuk a naplóban látni: # Eldobjuk a töredékcsomagokat. block in quick on dc0 all with frags # Eldobjuk a túlságosan rövid TCP csomagokat. block in quick on dc0 proto tcp all with short # Eldobjuk a forrás által közvetített (source routed) csomagokat. block in quick on dc0 all with opt lsrr block in quick on dc0 all with opt ssrr # Elutasítjuk az "OS fingerprint" kéréseket. # Naplózzuk az elsõ elõfordulást, így nálunk lesz a kíváncsiskodó # egyén IP-címe. block in log first quick on dc0 proto tcp from any to any flags FUP # Eldobunk mindent, aminek speciális beállításai vannak. block in quick on dc0 all with ipopts # Elutasítjuk a publikus pinget. block in quick on dc0 proto icmp all icmp-type 8 # Elutasítjuk az ident kéréseket. block in quick on dc0 proto tcp from any to any port = 113 # Blokkoljuk az összes Netbios szolgáltatást: 137=név, 138=datagram, # 139=session. A Netbios az MS Windows megosztását implementálja. # Blokkoljuk az MS Windows hosts2 névszerver kéréseit is a 81-es # porton. block in log first quick on dc0 proto tcp/udp from any to any port = 137 block in log first quick on dc0 proto tcp/udp from any to any port = 138 block in log first quick on dc0 proto tcp/udp from any to any port = 139 block in log first quick on dc0 proto tcp/udp from any to any port = 81 # Engedélyezzük a szolgáltatónk DHCP szerverétõl érkezõ forgalmat. # Ebben a szabályban meg kell adnunk a szolgáltató DHCP szerverének # IP-címét, mivel itt csak a hiteles forrásból fogadunk el csomagokat. # Erre csak DSL- és kábelmodemes kapcsolat esetében van szükség, a # "felhasználói PPP" alkalmazása során szükségtelen. Ez az IP-cím # megegyezik a kimenõ kapcsolatoknál megadott címmel. pass in quick on dc0 proto udp from z.z.z.z to any port = 68 keep state # Befelé engedélyezzük a szabványos WWW funkciót, mivel webszerverünk # van. pass in quick on dc0 proto tcp from any to any port = 80 flags S keep state # Befelé engedélyezzük az internetrõl érkezõ nem biztonságos telnet # kapcsolatokat. Azért nem biztonságos, mert az azonosítókat és # jelszavakat titkosítatlan formában közli az interneten keresztül. # Töröljük ezt a szabályt, ha nem használunk telnet szervert. #pass in quick on dc0 proto tcp from any to any port = 23 flags S keep state # Befelé engedélyezzük az internetrõl # érkezõ ssh/sftp/scp (biztonságos # telnet/rlogin/FTP) # kapcsolatokat az SSH (secure shell) használatával. pass in quick on dc0 proto tcp from any to any port = 22 flags S keep state # Minden mást dobjuk el és naplózzuk az elsõ elõfordulásukat. # Az elsõ alkalom naplózásával elejét tudjuk venni a "Denial of # Service" típusú támadásoknak, amivel egyébként lehetséges lenne a # napló elárasztása. # Ez a szabály blokkol alapértelmezés szerint mindent. block in log first quick on dc0 all ################### Itt van a szabályok vége ############################## <acronym>NAT</acronym> NAT IP maszkolás NAT hálózati címfordítás NAT A NAT jelentése Network Address Translation, vagyis hálózati címfordítás. A &linux; esetében ezt IP masqueradingnak, vagyis IP maszkolásnak hívják. A hálózati címfordítás és az IP maszkolás lényegben ugyanazt takarja. Az IPF címfordításért felelõs funkciójának köszönhetõen képesek vagyunk a tûzfal mögött elhelyezkedõ helyi hálózat számára megosztani az internet-szolgáltatól kapott publikus IP-címet. Sokakban felmerülhet a kérdés, hogy erre vajon mi szükségünk lehet. Az internet-szolgáltatók a magánszemélyeknek általában dinamikus IP-címeket osztanak ki. A dinamikus itt arra utal, hogy a címünk minden alkalommal változik, amikor betárcsázunk a szolgáltatóhoz vagy amikor ki- és bekapcsoljuk a modemünket. Ez a dinamikus IP-cím fog azonosítani minket az interneten. Most tegyük fel, hogy öt gépünk van otthon, viszont csak egyetlen elõfizetéssel rendelkezünk. Ebben az esetben öt telefonvonalat kellene használnunk és mindegyik géphez elõfizetni az internetre. A hálózati címfordítás alkalmazásával azonban mindössze egyetlen elõfizetés kell. A gépek közül négyet hozzákötünk egy switch-hez és a switch-et pedig a fennmaradó géphez, amelyen &os; fut. Ez utóbbi lesz az így kialakított helyi hálózatunk átjárója. A tûzfalban mûködõ címfordítás segítségével a helyi hálózaton található gépek IP-címeit észrevétlenül át tudjuk fordítani a hálózatunk publikus IP-címére, ahogy a csomagok elhagyják az átjárót. A beérkezõ csomagok esetében mindez visszafelé történik meg. Az IP-címek közül adott egy tartomány, amit a címfordítást használó helyi hálózatok részére tartanak fenn. Az RFC 1918 szerint az alábbi IP-címtartományok használhatók a helyi hálózatban, mivel ezeken keresztül közvetlenül sosem lehet kijutni az internetre: Kezdõ IP: 10.0.0.0 - Záró IP: 10.255.255.255 Kezdõ IP: 172.16.0.0 - Záró IP: 172.31.255.255 Kezdõ IP: 192.168.0.0 - Záró IP: 192.168.255.255 IP<acronym>NAT</acronym> NAT IPFILTER ipnat A címfordításra vonatkozó szabályokat az ipnat paranccsal tudjuk betölteni. Az ilyen típusú szabályokat általában az /etc/ipnat.rules állományban találjuk. A részleteket lásd az &man.ipnat.1; man oldalán. Amikor a címfordítás üzembe helyezése után meg akarjuk változtatni a címfordítás szabályait, elõször a címfordítás szabályait tartalmazó állományt módosítsuk, majd a belsõ címfordítási szabályok és a címfordítási táblázatban szereplõ aktív bejegyzések törléséhez futassuk le az ipnat parancsot a beállítással. A címfordítási szabályok újratöltését egy ehhez hasonló paranccsal tudjuk elvégezni: &prompt.root; ipnat -CF -f /etc/ipnat.szabályok A címfordításhoz tartozó statisztikákat ezzel a paranccsal tudjuk lekérdezni: &prompt.root; ipnat -s A címfordítási táblázatban pillanatnyilag szereplõ összerendeléseket a következõ paranccsal tudjuk listázni: &prompt.root; ipnat -l A szabályok feldolgozásával és az aktív szabályokkal/bejegyzésekkel kapcsolatos információk részletezését így engedélyezhetjük: &prompt.root; ipnat -v A címfordítási szabályok A címfordítási szabályok nagyon rugalmasak és rengeteg olyan funkciót meg tudunk velük valósítani, ami az üzleti és otthoni felhasználók számára egyaránt hasznos. Itt most a szabályok felépítését csak egyszerûsítve mutatjuk be, leginkább a nem üzleti környezetek tekintetében. A szabályok komplett formai leírását az &man.ipnat.5; man oldalán találjuk. Egy címfordítási szabály tehát valahogy így néz ki: map INTERFÉSZ HELYI_IP_TARTOMÁNY -> PUBLIKUS_CÍM A szabályt a map kulcsszó kezdi. A INTERFÉSZ helyére az internet felé mutató külsõ interfész nevét írjuk be. A HELYI_IP_TARTOMÁNY lesz az, amelyben a kliensek címeznek. Ez például a 192.168.1.0/24. A PUBLIKUS_CÍM lehet egy külsõ IP-cím vagy a 0/32 speciális kulcsszó, amellyel a FELÜLET-hez rendelt IP-címre hivatkozunk. Hogyan mûködik a hálózati címfordítás A publikus cél felé haladó csomag megérkezik a helyi hálózatról. Miután a kimenõ kapcsolatokra vonatkozó szabályok átengedik, a címfordítás kapja meg a szerepet és fentrõl lefelé haladva nekilát alkalmazni a saját szabályait, ahol az elsõ egyezõ szerint cselekszik. A címfordítás a szabályokat a csomaghoz tartozó interfészre és a forrás IP-címére illeszti. Amikor a csomag interfészének neve illeszkedik egy címfordítási szabályra, akkor ezután a csomag forrás (vagyis a helyi hálózaton belüli) IP-címérõl igyekszik eldönteni, hogy a szabály nyilának bal oldalán szereplõ tartományba esik-e. Ha erre is illeszkedik, akkor a forrás IP-címét átírjuk a 0/32 kulcsszó alapján felderített publikus IP-címre. A címfordító rutin ezt feljegyzi a saját belsõ táblázatába, így amikor a csomag visszatér az internetrõl, akkor képes lesz visszafordítani az eredeti belsõ IP-címére és feldolgozásra átadni a tûzfal szabályainak. A címfordítás engedélyezése A címfordítás életre keltéséhez a következõket kell beállítanunk az /etc/rc.conf állományban. Elõször engedélyezzük a gépünknek, hogy közvetítsen forgalmat az interfészek között: gateway_enable="YES" Minden alkalommal indítsuk el a címfordításért felelõs IPNAT programot: ipnat_enable="YES" Adjuk meg az IPNAT számára a betöltendõ szabályokat: ipnat_rules="/etc/ipnat.rules" Hálózati címfordítás nagyon nagy helyi hálózatok esetében Az olyan helyi hálózatokban, ahol rengeteg PC található vagy több alhálózatot is tartalmaz, az összes privát IP-cím egyetlen publikus IP-címbe tömörítése igen komoly problémává tud dagadni és az azonos portok gyakori használata a helyi hálózatra kötött számítógépek között ütközéseket okoz. Két módon tudunk megoldást nyújtani erre a problémára. A használható portok kiosztása Egy normális címfordítási szabály valahogy így nézne ki: map dc0 192.168.1.0/24 -> 0/32 A fenti szabályban a csomag forrásportját az IPNAT változatlanul a feldolgozás után hagyja. Ha ehhez még hozzátesszük a portmap kulcsszót, akkor ezzel utasítani tudjuk az IPNAT-ot, hogy csak az adott tartományban képezze le a forrásportokat. Például a következõ szabály hatására az IPNAT a forrásportokat egy adott tartományon belül fogja módosítani: map dc0 192.168.1.0/24 -> 0/32 portmap tcp/udp 20000:60000 Ha viszont még inkább meg akarjuk könnyíteni a dolgunkat, akkor itt egyszerûen csak adjuk meg az auto kulcsszót, amellyel az IPNAT önmagától megállapítja, hogy milyen portokat tud használni: map dc0 192.168.1.0/24 -> 0/32 portmap tcp/udp auto Több publikus cím használata Minden nagyobb helyi hálózat esetében elérkezünk ahhoz a ponthoz, ahol már egyetlen publikus cím nem elég. Ha több publikus IP-címmel is rendelkezünk, akkor ezekbõl a címekbõl egy közös készletet hozhatunk létre, amibõl majd az IPNAT válogathat miközben a csomagok címeit átírja kifelé menetben. Például ahelyett, hogy a csomagokat egyetlen publikus IP-címre képeznénk le, ahogy itt tesszük: map dc0 192.168.1.0/24 -> 204.134.75.1 A hálózati maszk segítségével meg tudjuk adni IP-címek egy tartományát is: map dc0 192.168.1.0/24 -> 204.134.75.0/255.255.255.0 CIDR-jelöléssel: map dc0 192.168.1.0/24 -> 204.134.75.0/24 A portok átirányítása Gyakran elõfordul, hogy van webszerverünk, levelezõ szerverünk, adatbázis szerverünk és névszerverünk, melyek a helyi hálózat különbözõ gépein futnak. Ebben az esetben a szerverekhez tartozó forgalmat is fordítanunk kell, illetve valamilyen módon a bejövõ forgalmat is át kell irányítanunk a helyi hálózat megfelelõ gépeihez. Az IPNAT ezt a gondot a hálózati címfordítás átirányítást támogató funkcióival szünteti meg. Tegyük fel, hogy a 10.0.10.25 belsõ címen van egy webszerverünk, amelyhez a 20.20.20.5 publikus IP tartozik. Ilyenkor a következõ szabályt adjuk meg: rdr dc0 20.20.20.5/32 port 80 -> 10.0.10.25 port 80 vagy: rdr dc0 0.0.0.0/0 port 80 -> 10.0.10.25 port 80 Így tudjuk beállítani a 10.0.10.33 címmel rendelkezõ névszervert a kintrõl érkezõ névfeloldási kérések fogadására: rdr dc0 20.20.20.5/32 port 53 -> 10.0.10.33 port 53 udp Az FTP és a címfordítás Az FTP egy olyan õskövület, amely még az internet egy régi korszakából maradt fenn, amikor az egyetemek között még bérelt vonal létezett és az FTP szolgált a kutatók közt az állományok megosztására. Ez még abban az idõben történt, amikor a biztonság egyáltalán nem volt lényeges szempont. Az évek elõrehaladtával az FTP protokoll beleivódott a feltörekvõ internet gerincébe és a titkosítatlanul küldött azonosítóival és jelszavaival továbbra is ugyanolyan védtelen maradt. Az FTP két változatban, aktív és passzív módban képes mûködni. Az eltérés kettejük között az adatcsatorna megállapításában van. A passzív mód sokkal biztonságosabb, mivel ilyenkor az adatcsatornát az FTP kapcsolatot kezdeményezõ állítja be. Az FTP különbözõ módjainak magyarázatát és a köztük levõ különbséget a címen ismerhetjük meg részleteiben (angolul). Az IPNAT szabályai Az IPNAT egy speciális beépített FTP proxyval rendelkezik, amelyre a hálózati címfordítás leképezései között hivatkozhatunk. Képes figyelni az összes aktív vagy passzív FTP kapcsolathoz tartozó kimenõ kérést és ezekhez dinamikusan létrehozni olyan ideiglenes szûrési szabályokat, amelyek valóban csak az adatcsatornához felhasznált portokat tartalmazzák. Ezzel ki tudjuk küszöbölni az FTP azon káros hatását a tûzfalra nézve, hogy egyszerre túlságosan sok magasabb tartománybeli port legyen nyitva. Ez a szabály a belsõ hálózat összes FTP forgalmát lekezeli: map dc0 10.0.10.0/29 -> 0/32 proxy port 21 ftp/tcp Ez a szabály pedig az átjáróról érkezõ FTP forgalommal bírkózik meg: map dc0 0.0.0.0/0 -> 0/32 proxy port 21 ftp/tcp Ez a szabály kezeli a belsõ hálózatról érkezõ összes nem FTP típusú forgalmat: map dc0 10.0.10.0/29 -> 0/32 Az FTP leképzésére vonatkozó szabály a szokásos leképzési szabály elé kerül. Az összes csomag fentrõl haladva az elsõ illeszkedõ szabály alapján kerül feldolgozásra. Elõször az interfész nevét vizsgáljuk, majd a belsõ hálózatbeli forrás IP-t, végül azt, hogy a csomag egy FTP kapcsolat része. Ha minden paraméterében megfelel, akkor az FTP proxy készít egy ideiglenes szûrési szabályt hozzá, amellyel az FTP kapcsolathoz tartozó csomagok mind a két irányba képesek lesznek vándorolni, természetesen a címfordítással együtt. Az összes többi bentrõl érkezõ csomag átlép ezen a szabályon és megáll a harmadiknál, ahol az interfésznek és forrás IP-nek megfelelõen átfordítjuk a címét. Az IPNAT szûrési szabályai FTP-re Az FTP esetében csak egyetlen szûrési szabályra van szükségünk a hálózati címfordításba épített FTP proxy használatához. FTP proxy nélkül az alábbi három szabály kellene: # Kifelé engedélyezzük a belsõ gépek FTP elérést az internet irányába, # aktív és passzív módokban. pass out quick on rl0 proto tcp from any to any port = 21 flags S keep state # Kifelé engedélyezzük a passzív módhoz tartozó magasabb tartománybeli # adatcsatornákat. pass out quick on rl0 proto tcp from any to any port > 1024 flags S keep state # Aktív módban beengedjük az FTP szervertõl érkezõ adatcsatornát. pass in quick on rl0 proto tcp from any to any port = 20 flags S keep state IPFW tûzfalak IPFW Az IPFIREWALL (IPFW) a &os; által támogatott tûzfalazó alkalmazás, melyet a &os; Projektben résztvevõ önkéntesek fejlesztettek ki és tartanak karban. Régi típusú, állapottartás nélküli szabályokat használ, és az itt használatos szabályírási technikát egyszerû állapottartó megoldásnak nevezzük. Az IPFW szabvány &os;-ben levõ, mintaként szolgáló szabályrendszere (ez az /etc/rc.firewall és /etc/rc.firewall6 állományokban található meg) annyira egyszerû, hogy komolyabb módosítások nélkül nem ajánlatos használni. Ez a példa nem tartalmaz állapottartó szûrést, ami viszont a legtöbb esetben kívánatos lenne, ezért ezt a szakaszt nem erre alapozzuk. Az IPFW állapottartás nélküli szabályainak felépítésében olyan technikailag kifinomult leválogatási képességek bújnak meg, amelyek jócskán meghaladják az átlagos tûzfalépítõk tudását. Az IPFW elsõsorban olyan szakemberek vagy szakmailag elõrehaladott felhasználók számára készült, akiknek speciális csomagszûrési igényeik vannak. A különbözõ protokollok használatának és a hozzájuk tartozó fejlécinformációk mindenre kiterjedõ ismerete szinte nélkülözhetetlen az IPFW valódi erejének kihasználásához. Ez a szint azonban túlmutat a kézikönyv ezen szakaszának keretein. Az IPFW hét komponensbõl épül fel, melyek közül az elsõdleges a rendszermag tûzfalazásért felelõs szabályfeldolgozó és a hozzátartozó csomagnyilvántartás, majd ezt követi a naplózás, a hálózati címfordítást aktiváló divert szabály, valamint a komolyabb célok megvalósítására alkalmas lehetõségek: a forgalom korlátozásáért felelõs dummynet, a továbbküldésre alkalmas fwd rule szabály, a hálózati hidak támogatása, illetve az ipstealth. Az IPFW egyaránt használható IPv4 és IPv6 esetén. Az IPFW engedélyezése IPFW engedélyezése Az IPFW az alap &os; telepítésben külön, futás idõben betölthetõ modulként érhetõ el. Ha az rc.conf állományban megadjuk a firewall_enable="YES" beállítást, akkor a rendszer indulásakor ezt a modult dinamikusan betölti. Az IPFW-t csak akkor kell a &os; rendszermagjába beépítenünk, ha szükségünk van a címfordítási funkciójára is. Ha tehát az rc.conf állományban megadtuk a firewall_enable="YES" sort és újraindítottuk a számítógépünket, akkor a következõ fehérrel kiemelt üzenet fog megjelenni a rendszerindítás során: ipfw2 initialized, divert disabled, rule-based forwarding disabled, default to deny, logging disabled A logging disabled üzenetbõl kiderül, hogy a modul nem végez naplózást. A naplózást és a hozzátartozó részletesség szintjét úgy tudjuk beállítani, ha az /etc/sysctl.conf állományba felvesszük a következõ sorokat, amivel a következõ indításkor már mûködni fog: net.inet.ip.fw.verbose=1 net.inet.ip.fw.verbose_limit=5 A rendszermag beállításai a rendszermag beállításai IPFIREWALL a rendszermag beállításai IPFIREWALL_VERBOSE a rendszermag beállításai IPFIREWALL_VERBOSE_LIMIT IPFW a rendszermag beállításai Ha nem akarjuk kihasználni az IPFW által felkínált címfordítási lehetõségeket, akkor egyáltalán nem szükséges a &os; rendszermagjába belefordítani a támogatását. Ezért az alábbiakat csak kiegészítõ információként tüntettük fel. options IPFIREWALL Ez a beállítás engedélyezi az IPFW használatát a rendszermag részeként. options IPFIREWALL_VERBOSE Ezzel és a log kulcsszóval tudjuk az IPFW szabályain keresztülhaladó csomagokat naplózni. options IPFIREWALL_VERBOSE_LIMIT=5 Ez az érték korlátozza a &man.syslogd.8; segítségével naplózott azonos bejegyzések maximális számát. Ezt a beállítást olyan veszélyes környezetekben érdemes használnunk, ahol naplózni akarunk. Segítségével meg tudjuk akadályozni, hogy a rendszernapló elárasztásával megakasszák a rendszerünket. a rendszermag beállításai IPFIREWALL_DEFAULT_TO_ACCEPT options IPFIREWALL_DEFAULT_TO_ACCEPT Ezen beállítás hatására a tûzfal alapértelmezés szerint mindent átenged, ami általában akkor jöhet jól, amikor elõször beállítjuk a tûzfalat. a rendszermag beállításai IPDIVERT options IPDIVERT Ezzel a beállítással engedélyezzük a címfordítás használatát. Ha nem adjuk meg az IPFIREWALL_DEFAULT_TO_ACCEPT beállítást, vagy ha nem engedélyezzük a bejövõ csomagokat, akkor a gépünkre semmilyen csomag nem lesz képes bejutni, illetve onnan kijutni. Az <filename>/etc/rc.conf</filename> beállításai Így tudjuk engedélyezni a tûzfalat: firewall_enable="YES" A &os;-hez mellékelt alapértelmezett tûzfaltípusok közül az /etc/rc.firewall állomány átolvasásával tudunk választani, és megadni az alábbi helyett: firewall_type="open" A következõ értékek állnak rendelkezésünkre: open — átengedi az összes forgalmat client — csak ezt a gépet védi simple — az egész hálózatot védi closed — a helyi interfész kivételével minden IP alapú forgalmat tilt UNKNOWN — tiltja a tûzfal szabályainak betöltését állománynév — a tûzfal szabályait tartalmazó állomány abszolút elérési útvonala Két különbözõ módon lehet betölteni a saját ipfw szabályainkat. Az egyik közülük, ha a firewall_type változóban megadjuk a tûzfal szabályait tartalmazó állomány abszolút elérési útvonalát, az &man.ipfw.8; parancssori beállításai nélkül. - Egy egyszerû szabályrendszer lehet - például a következõ: + Az alábbi példában egy olyan egyszerû + szabályrendszert láthatunk, amely blokkolja az + összes bejövõ és kimenõ + forgalmat: - add block in all -add block out all + add deny in +add deny out Másrészrõl az firewall_script változóban is megadhatjuk azt a szkriptet, amelyben a rendszerindítás során meghívjuk ipfw parancsot. Az iménti szabályrendszert az alábbi szkripttel tudjuk kiváltani: #!/bin/sh ipfw -q flush -ipfw add block in all -ipfw add block out all +ipfw add deny in +ipfw add deny out Ha a firewall_type változó client vagy simple értékét használjuk, akkor az /etc/rc.firewall állományban található alapértelmezett szabályokat érdemes átvizsgálnunk, hogy kellõen illeszkednek-e az adott géphez. Hozzátennénk, hogy a fejezetben szereplõ példák azt feltételezik, hogy a firewall_script értéke az /etc/ipfw.rules állomány. A naplózás így engedélyezhetõ: firewall_logging="YES" A firewall_logging változó egyedül csak annyit tesz, hogy beállítja a net.inet.ip.fw.verbose sysctl változónak az 1 értéket (lásd ). A napló korlátozására nincs külön változó az rc.conf állományon belül, de az /etc/sysctl.conf állomány segítségével és manuálisan be tudjuk állítani a hozzátartozó változót: net.inet.ip.fw.verbose_limit=5 Amennyiben a gépünk átjáróként viselkedik, tehát a &man.natd.8; segítségével címfordítást végez, a ban olvashatunk utána, hogy ehhez az /etc/rc.conf állományban milyen beállításokat kell megadnunk. Az IPFW parancs ipfw Normál esetben az ipfw parancs használatos arra, hogy a tûzfal mûködése közben az aktív belsõ szabályai közé vegyünk fel vagy töröljünk közülük manuálisan bejegyzéseket. Ennek a módszernek az egyedüli hátránya, hogy az így végrehajtott módosítások el fognak veszni a rendszer leállításával. Itt inkább azt a megoldást javasoljuk, hogy az összes szabályt tegyük bele egy állományba és a rendszerindítás során ezt töltsük be, majd ha változtatni akarunk a tûzfalon, akkor ezt az állományt módosítsuk és a régiek törlésével töltsük be újra az egész szabályrendszert. Az ipfw parancs mellesleg remekül használható a jelenleg futó tûzfalszabályok megjelenítésére a konzolon. Az IPFW nyilvántartásában az egyes szabályokhoz dinamikusan jönnek létre számlálók, amelyek a rá illeszkedõ csomagokat számolják. A tûzfal tesztelése folyamán a szabályok és hozzátartozó számlálók lekérdezése a megfelelõ mûködés ellenõrzésének egyik lehetséges módja. A szabályokat így tudjuk egymás után felsoroltatni: &prompt.root; ipfw list A szabályokat így tudjuk az utolsó illeszkedésük idejével együtt megjeleníteni: &prompt.root; ipfw -t list A következõ példában a nyilvántartási információkat kérdezzük le, ekkor a szabályok mellett az illeszkedõ csomagok száma is láthatóvá válik. Az elsõ sorban a szabály száma szerepel, majd ezt követi rendre az illeszkedõ kimenõ és bejövõ csomagok mennyisége, valamint végül maga a szabály. &prompt.root; ipfw -a list A statikus szabályok mellett a dinamikusakat így lehet kilistázni: &prompt.root; ipfw -d list A lejárt dinamikus szabályokat is meg tudjuk nézni: &prompt.root; ipfw -d -e list A számlálók nullázása: &prompt.root; ipfw zero Csak a SZÁM sorszámú szabályhoz tartozó számlálók nullázása: &prompt.root; ipfw zero SZÁM Szabályrendszerek az IPFW-ben Az IPFW esetében a szabályrendszer olyan szabályokból áll, amelyek a csomagokról tartalmuk alapján eldöntik, hogy át kell engedni vagy vissza kell tartani. A gépek közt két irányban áramló csomagok egy munkamenet alapú társalgást képeznek. A tûzfalhoz tartozó szabályrendszer egyaránt feldolgozza a internetrõl a hálózatunk felé igyekvõ csomagokat, illetve a hálózatunk ezekre adott válaszait. Az egyes TCP/IP szolgáltatásokat (mint például telnet, www, levelezés stb.) a hozzájuk tartozó protokol és szabványos (fogadó) portszám írja le. Ezekre a forrásról általában valamilyen nem szabványos (magasabb értékû) portról érkeznek csomagok. Ekkor a kommunikáció összes paramétere (vagyis a portok és címek) bármelyike alapján definiálhatunk blokkolást vagy továbbengedést leíró szabályokat. IPFW a szabályok feldolgozásának sorrendje Amikor egy csomag eléri a tûzfalat, a szabályrendszer elsõ szabályával kerül összehasonlításra és amíg nem illeszkedik valamelyikre, addig lefut rá a többi szabály is fentrõl lefelé egyesével, a sorszámuknak megfelelõ növekvõ sorrendben. Ha a csomag megfelel valamelyik szabály leválogatási paramétereinek, akkor a benne megnevezett cselekvés zajlik le, és számára a feldolgozás befejezõdik. Ezt a viselkedést neveztük az elsõ illeszkedés nyer típusú keresésnek. Amennyiben a csomag egyetlen szabályra sem illeszkedik, akkor az IPFW 65535-ös sorszámú állandó szabálya fogja elcsípni, amely feladata szerint eldobja az összes hozzá beérkezõ csomagot anélkül, hogy bármit is válaszolna a csomag feladójának. A keresés a count, skipto és tee szabályok után még folytatódik. Az itt szereplõ utasítások különbözõ állapottartásra vonatkozó opciókat, például a keep state, limit, in, out és via kulcsszavakat tartalmazó szabályokon alapulnak. Lényegében ezt tekinthetjük az inkluzív típusú tûzfalak kiindulási alapjaként. A tûzfal szabályainak beállítása során nem árt óvatosnak lennünk, mert figyelmetlenségünk révén könnyen kizárathatjuk magunkat a gépünkrõl. A szabályok felépítése IPFW a szabályok felépítése Az itt bemutatásra kerülõ szabályok felépítését csak olyan mértékig részletezzük, ami elengedõ a szabványos inkluzív típusú tûzfalak kialakításához. A szabályok felépítésének pontos leírását az &man.ipfw.8; man oldalán találhatjuk meg. A szabályok kulcsszavakat tartalmaznak. Ezeket a kulcsszavakat soronként egy elõre rögzített sorrendben kell szerepeltetni. A kulcsszavakat a szövegben kiemeltük. Bizonyos kulcsszavakhoz további opciókhoz is tartozhatnak, amelyek gyakran maguk is kulcsszavak és szintén további opciókat tartalmazhatnak. A # egy megjegyzés kezdetét jelzi, mely egyaránt megjelenhet egy külön sorban, vagy egy szabályt tartalmazó sor végén. Az üres sorok nem vesznek részt a feldolgozásban. PARANCS SZABÁLY_SZÁM CSELEKVÉS NAPLÓZÁS SZÛRÉS ÁLLAPOTTARTÁS PARANCS Minden új szabály elõttt az add (mint hozzáadás) parancsnak kell szerepelni, amellyel a belsõ táblázatba tudjuk felvenni. SZABÁLY_SZÁM A szabályokhoz mindig tartozik egy sorszám is. CSELEKVÉS A szabályhoz az alábbi cselekvések valamelyike kapcsolható, amely akkor hajtódik végre, amikor a csomag megfelel a hozzátartozó szûrési feltételeknek. allow | accept | pass | permit A fentiek közül mindegyik ugyanazt jelenti, vagyis hatásukra az illeszkedõ csomag kilép a tûzfalból. Ez a szabály megállítja a keresést. check-state A csomagot a dinamikus szabályokat tároló táblázattal veti össze. Ha itt egyezést talál, akkor végrehajtja az egyezõ dinamikus szabályhoz tartozó cselekvést, minden más esetben továbblép a következõ szabályra. Ennek a szabálynak nincs illeszthetõ paramétere. Ha a szabályrendszerben nem szerepel ilyen, akkor a dinamikus szabályok vizsgálatát az elsõ keep-state vagy limit használatánál vonja be a rendszer. deny | drop Mind a két szó ugyanarra utal, vagyis a szabályra illeszkedõ csomagokat el kell dobni. Ebben az esetben a keresés befejezõdik. NAPLÓZÁS log vagy logamount Amikor egy csomag egy log kulcsszót tartalmazó szabályra illeszkedik, akkor a rendszernaplóban egy üzenet keletkezik a security (biztonság) funkción keresztül. A naplóba ténylegesen csak akkor kerül bele az üzenet, ha az adott szabály még nem haladta meg a hozzátartozó logamount paraméter értékét. Ha ezt nem adtuk meg, akkor az itt érvényes korlát a net.inet.ip.fw.verbose_limit sysctl változóból fog származni. A nulla érték mind a két esetben megszünteti ezt a korlátozást. Ha elértük a korlátot, akkor a naplózást úgy tudjuk újra engedélyezni, ha töröljük a naplózáshoz tartozó számláló értékét, lásd az ipfw reset log parancsot. A naplózás mindig az összes paraméter illeszkedésének ellenõrzése után történik, de még a cselekvés (accept, deny) elvégzése elõtt. Teljesen rajtunk múlik, hogyan milyen szabályokat naplózunk. SZÛRÉS Ebben a szakaszban azok a kulcsszavak találhatóak, amelyek segítségével a csomagok különbözõ tulajdonságait tudjuk megvizsgálni és eldönteni, hogy illeszkedik-e a szabályra vagy sem. A következõ általános tulajdonságokat tudjuk megvizsgálni, ebben a kötött sorrendben: udp | tcp | icmp Bármilyen más olyan protokoll is megadható, amely megtalálható az /etc/protocols állományban. Ezzel adjuk a csomaghoz tartozó protokollt. Használata kötelezõ. from forrás to cél Mind a from és to kulcsszavak IP-címek illesztésére alkalmasak. A szabályoknak tartalmazniuk kell a forrás ÉS a cél paramétereket is. Az any egy olyan kulcsszó, amely tetszõleges IP-címre illeszkedik. A me pedig egy olyan speciális kulcsszó, amely a tûzfalat mûködtetõ &os;-s gép (tehát ez a gép) adott interfészhez tartozó IP-címét jelöli, mint ahogy a from me to any, from any to me, from 0.0.0.0/0 to any, from any to 0.0.0.0/0, from 0.0.0.0 to any, from any to 0.0.0.0 vagy from me to 0.0.0.0 paraméterekben. Az IP-címek numerikus pontozott formában a hálózati maszk hosszával együtt (CIDR-jelöléssel), vagy egyszerûen csak pontozott formában adhatóak meg. A hálózati maszkok megállapításában a net-mgmt/ipcalc port lehet segítségünkre. Errõl bõvebb információkat a segédprogram honlapján, a címen találhatunk (angolul). port szám A portszámokat is ismerõ protokollok esetében (mint például a TCP vagy UDP) adhatjuk meg. Fontos, hogy itt annak a szolgáltatásnak a portszámát adjuk meg, amelyre a szabály vonatkozik. A szolgáltatás (az /etc/services állományból származó) nevét is megadhatjuk a port száma helyett. in | out A beérkezõ valamint a kimenõ csomagokat adhatjuk meg ezen a módon. Itt az in és out kulcsszavak, melyeket kötelezõ megadni a szabály részeként. via interfész Név szerint az adott interfészen keresztül haladó csomagokat tudjuk szûrni. A via kulcsszó hatására a használt interfész is számítani fog a csomag feldolgozása során. setup Ez a kulcsszó a TCP csomagok esetében a kapcsolatok felépítésére vonatkozó kéréseket segít beazonosítani. keep-state Ez egy kötelezõ kulcsszó. Feldolgozásakor a tûzfal létrehoz dinamikus szabályt, amely alapértelmezés szerint az egyazon protokollt használó forrás és cél IP/port párosok közti kétirányú forgalomra fog automatikusan illeszkedni. limit {forráscím | forrásport | célcím | célport} A tûzfal csak N darab, a szabálynak megfelelõ azonos paraméterû kapcsolatot fog átengedi. Itt egy vagy több forrás- és célcím valamint forrás- és célport adható meg. A limit és a keep-state egy szabályon belül nem használható. A limit ugyanazokat az állapottartó funkciókat képviseli, mint a keep-state, csak a saját kiegészítéseivel megtoldva. ÁLLAPOTTARTÁS IPFW állapottartó szûrés Az állapottartó szûrés a kétirányú csomagváltásokat egy létrejött kapcsolatba sorolja. Olyan vizsgálatokat végez, amivel képes megállapítani, hogy a csomag küldõje és címzettje között kialakult kommunikáció követ-e valamilyen kétirányú csomagküldésre érvényes folyamatot. Az így felállított sablontól eltérõ összes csomag hamisnak minõsül és automatikusan eldobásra kerül. A check-state segítségével ellenõrizhetjük, hogy az adott csomag a IPFW szerint megfelel-e valamelyik dinamikusan leképzett szabálynak. Ha egyezik valamelyikõjükkel, akkor a csomag a tûzfalból kilépve folytatja útját és a kommunikációban soron következõ csomag számára létrejön egy másik dinamikus szabály. Ha nincs egyezés, akkor csomag feldolgozása a szabályrendszer következõ szabályánál folytatódik. A dinamikus szabályokat kezelõ rutin sebezhetõ, mivel ha egyszerre nagy mennyiségû SYN csomagot küldünk, akkor olyan sok dinamikus bejegyzés keletkezik, hogy egyszerûen kifogyunk a rendelkezésre álló erõforrásokból. A &os; fejlesztõi azonban az ilyen természetû támadások kivédésére is felkészítették, és kialakították belõle a limit opciót. Alkalmazásával le tudjuk korlátozni az egyszerre folyó párhuzamos kapcsolatok számát a forrás vagy a cél a limit paraméternél megadott mezõinek és a csomag IP-címe alapján. Így az adott szabályhoz és IP-címhez csak elõre rögzített mennyiségû nyitott állapotú dinamikus szabály létezhet egy idõben. Ha ezt a korlátot átlépjük, a csomag eldobódik. A tûzfal üzeneteinek naplózása IPFW naplózás A naplózás elõnyei nyilvánvalóak. Ha engedélyezzük, aktiválása után képesek leszünk olyan információknak utánanézni, mint például milyen csomagokat dobtunk el, honnan érkeztek, hova tartottak. Ez egy komoly fegyverünk lehet a potenciális támadókkal szemben. Azonban hiába engedélyezzünk önmagában a naplózást, attól az IPFW még saját magától nem fog naplózást elõíró szabályokat gyártani. A tûzfal karbantartóinak maguknak kell eldöntenie, hogy a szabályrendszerben mely szabályokhoz tartozzon naplózás, nekik kell felvenni ezekhez a log kulcsszót. Általában csak az eldobással járó deny típusú szabályokat vagy a bejövõ ICMP pingeket szokták naplózni. Gyakran úgy oldják meg ezt, hogy a szabályrendszer utolsó szabályaként lemásolják az ipfw alapértelmezett mindent eldobunk szabályát és a naplózást adják meg benne. Ezen a módon fény derül azokra a csomagokra, amelyek a szabályrendszerben semmire sem illeszkedtek. A naplózás azonban egy kétélû fegyver, mivel ha nem vagyunk elég körültekintõek, akkor a sok naplóinformáció között könnyen el tudunk veszni és a lemezünk is gyorsan betelhet a mindent elfoglaló naplóktól. Mellesleg a naplók megdagasztását célzó DoS típusú támadás a rendszerek lebénítására alkalmazott egyik legõsibb technika. Ezek az üzenetek nem csak a rendszernaplóba kerülnek bele, hanem az elsõdleges konzol képernyõjére is kiíródnak, ami egy idõ után idegesítõ tud lenni. A rendszermag IPFIREWALL_VERBOSE_LIMIT=5 beállításával azonban képesek vagyunk korlátozni azokat a rendszernapló felé küldött egymás után következõ üzeneteket, amelyek ugyanarra a szabályra vonatkoznak. Amikor ezt a beállítást megadjuk a rendszermag fordításánál, akkor az egyes szabályokhoz az általa meghatározott értéken felül nem jön létre több hasonló üzenet. Hiszen semmi sem derül ki 200 teljesen azonos naplóüzenetbõl. Például, ha az egyes szabályokhoz legfeljebb öt egymást követõ üzenetet engedélyezünk, akkor a többi fennmaradó azonos üzenetet összeszámolja a rendszer és a következõ módon közvetíti a rendszernaplózó szolgáltatás felé: last message repeated 45 times Ami magyarul így hangzik: az utolsó üzenet 45 alkalommal ismétlõdött meg Az összes csomagokkal kapcsolatos naplózás alapértelmezés szerint a /var/log/security állományba kerül, amelyet az /etc/syslog.conf állomány definiál. Szabályokat tartalmazó szkript készítése A rutinosabb IPFW felhasználók a szabályokat egy állományban programozzák le olyan stílusban, hogy szkriptként is futtatható legyen. Ennek az egyik legnagyobb elõnye, hogy a tûzfal szabályai így egyszerre cserélhetõek a rendszer újraindítása nélkül. Ez a módszer nagyon kényelmes az új szabályok kipróbálásánál, mivel tetszõleges alkalommal végrehajthatjuk. Mivel ez egy szkript, ki tudjuk használni az itt megszokott szimbolikus helyettesítés által felkínált lehetõségeket, és ezzel a gyakran használt értékeket is egyszerre több szabályban tudjuk helyettesíteni. Erre a következõkben fogunk egy konkrét példát látni. A szkript felépítése kompatibilis a &man.sh.1;, &man.csh.1; és &man.tcsh.1; parancsértelmezõkkel. A szimbolikus mezõk helyettesítését a $ vagyis dollárjel vezeti be. Maguk a szimbolikus mezõk nem tartalmazzák a $ elõtagot. A szimbolikus mezõk értékeit "kettõs idézõjelek" között kell megadni. A szabályok összeírását kezdjük el így: ####### itt kezdõdik az ipfw szabályait tartalmazó szkript ###### # ipfw -q -f flush # töröljük az összes aktuális szabályt # Set defaults oif="tun0" # a kimenõ interfész odns="192.0.2.11" # az internet szolgáltató névszerverének IP-címe cmd="ipfw -q add " # a szabályok hozzáadásához szükséges elemek ks="keep-state" # csupán a lustaság miatt $cmd 00500 check-state $cmd 00502 deny all from any to any frag $cmd 00501 deny tcp from any to any established $cmd 00600 allow tcp from any to any 80 out via $oif setup $ks $cmd 00610 allow tcp from any to $odns 53 out via $oif setup $ks $cmd 00611 allow udp from any to $odns 53 out via $oif $ks #### itt fejezõdik be az ipfw szabályait tartalmazó szkript ###### Ezzel készen is vagyunk. Most ne törõdjünk a példában szereplõ szabályokkal, itt most a szimbolikus helyettesítés használatát igyekeztük bemutatni. Ha az iménti példát az /etc/ipfw.rules állományba mentettük el, akkor az alábbi parancs kiadásával tudjuk újratölteni a benne szereplõ szabályokat: &prompt.root; sh /etc/ipfw.rules Az /etc/ipfw.rules állományt egyébként tetszõleges néven hívhatjuk és bárhová rakhatjuk. Ugyanez természetesen elérhetõ a következõ parancsok egymás utáni begépelésével is: &prompt.root; ipfw -q -f flush &prompt.root; ipfw -q add check-state &prompt.root; ipfw -q add deny all from any to any frag &prompt.root; ipfw -q add deny tcp from any to any established &prompt.root; ipfw -q add allow tcp from any to any 80 out via tun0 setup keep-state &prompt.root; ipfw -q add allow tcp from any to 192.0.2.11 53 out via tun0 setup keep-state &prompt.root; ipfw -q add 00611 allow udp from any to 192.0.2.11 53 out via tun0 keep-state Állapottartó szabályrendszerek A most következõ címfordítás nélküli szabályrendszer arra mutat példát, hogyan valósítsunk meg egy biztonságos inkluzív tûzfalat. Az inkluzív tûzfalak csak a szabályainak megfelelõ szolgáltatásokat engedik át, minden mást alapértelmezés szerint tiltanak. A komplett hálózati szegmensek védelmére összeállított tûzfalaknak legalább két interfészük van, amelyek mindegyikéhez tartoznia kell szabályoknak a megfelelõ mûködéshez. Az &unix; mintájú operációs rendszer, köztül a &os; is olyan, hogy a rendszerben belüli kommunikációt a lo0 nevû interfészen és a 127.0.0.1 IP-címen bonyolítja le. A tûzfalban mindenképpen szerepelniük kell olyan szabályoknak, amelyek gondoskodnak ezen speciális belsõ csomagok zavartalan közlekedésérõl. Az internet felé csatlakozó interfész lesz az, amelyen keresztül a kifelé menõ kéréseket hitelesítjük és vezéreljük az internet elérését, valamint ahol szûrjük az internet felõl érkezõ kéréseket. Ez lehet a PPP esetében a tun0 eszköz, vagy a DSL-, illetve kábelmodemhez csatlakozó hálózati kártya. Abban az esetben, amikor egy vagy több hálózati kártyával csatlakozunk a tûzfal mögött található belsõ helyi hálózatra, szintén gondoskodnunk kell a helyi hálózaton belül mozgó csomagok akadálymentes továbbításáról. A szabályokat elõször három nagyobb osztályba kell sorolnunk: az összes szabadon forgalmazó interfész, a publikus kimenõ és a publikus bejövõ interfész csoportjába. A publikus interfészekhez tartozó csoportokban úgy kell rendeznünk a szabályokat, hogy elõre kerüljenek a gyakrabban használtak és hátra a kevésbé használtak, valamint a csoportok utolsó szabálya blokkoljon és naplózzon minden csomagot az adott interfészen és irányban. A következõ szabályrendszerben szereplõ, a kimenõ kapcsolatokat tartalmazó csoport csak olyan allow típusú szabályokat tartalmaz, amelyek szûrési feltételei egyértelmûen azonosítják az interneten elérhetõ szolgáltatásokat. Az összes szabályban megjelennek a proto, port, in/out, via és keep state opciók. A proto tcp szabályokban emellett szerepel még egy setup opció is, amellyel a kapcsolatokat kezdeményezõ csomagokat tudjuk azonosítani és felvenni az állapottartásért felelõs dinamikus szabályok közé. A bejövõ forgalmat vezérlõ szabályrendszerben elõször az eldobni kívánt csomagokat kell megadni, aminek két eltérõ oka van. Elõször is elõfordulhat, hogy a veszélyes csomagok részleges illeszkedés miatt szabályosnak tûnnek. Az ilyen csomagokat értelemszerûen nem lenne szabad beengedni a szabályok részleges megfelelése alapján. A másodszor az eleve ismerten problémás és értelmetlen csomagokat csendben el kellene vetni, mielõtt a szakaszhoz tartozó utolsó szabály fogná meg és naplózná. Ez az utolsó szabály egyébként szükség esetén felhasználható a támadók elleni bizonyítékok begyûjtésére. A másik, amire még oda kell figyelnünk, hogy a blokkolt csomagok esetében semmilyen válasz nem keletkezzen, egyszerûen csak tûnjenek el. Így a támadó nem fogja tudni, hogy a csomagjai vajon elérték-e a rendszerünket. Minél kevesebb információt tudnak összegyûjteni a rendszerünkrõl a támadók, annál biztonságosabbnak tekinthetõ. Amikor ismeretlen portokra érkezõ csomagokat naplózunk, érdemes az /etc/services/ állományban vagy címen (angolul) utánanézni a porthoz tartozó szolgáltatásnak. A különbözõ trójai programok által portok számai ezen a linken érhetõek el (angolul): . Példa egy inkluzív szabályrendszerre A most következõ, címfordítást nem tartalmazó szabályrendszer teljesen inkluzív típusú. Éles rendszereken is nyugodtan alkalmazhatjuk. Egyszerûen csak annyit kell tennünk, hogy megjegyzésbe tesszük az olyan szolgáltatásokra vonatkozó szabályokat, amelyeket nem akarunk engedélyezni. Amikor pedig olyan üzenetek jelennek meg a naplóban, amelyeket nem akarunk tovább látni, a bejövõ kapcsolatokhoz vegyünk fel egy deny típusú szabályt hozzájuk. Minden szabályban cseréljük ki a dc0 interfészt arra a hálózati kártyára, amely közvetlenül csatlakoztatja rendszerünket az internethez. A felhasználói PPP esetében ez a tun0. A szabályok használatában felfedezhetünk egyfajta rendszerszerûséget: Mindegyik sorban, ahol az internet felé nyitunk meg egy kapcsolatot, a keep-state opciót használjuk. Az internetrõl az összes hitelesített szolgáltatás elérése tartalmazza a limit opciót az elárasztások kivédése miatt. Az összes szabályban az in vagy az out paraméterrel megadjuk szûrni kívánt forgalom irányát. Az összes szabályban szerepel a via paraméterrel a csomagokat továbbító interfész neve. Az alábbi szabályokat tegyük az /etc/ipfw.rules állományba. ############## Itt kezdõdnek az IPFW szabályai ########################## # Kezdés elõtt töröljük az összes aktív szabályt. ipfw -q -f flush # Állítsuk be a parancsok további szükséges opciót. cmd="ipfw -q add" pif="dc0" # az internethez csatlakozó # interfész neve ################################################################# # A belsõ hálózat számára ne korlátozzunk semmit se. # Ha nincs helyi hálózatunk, akkor erre nincs szükségünk. # Az 'xl0' nevét írjuk át a helyi hálózatra csatlakozó # interfész nevére. ################################################################ #$cmd 00005 allow all from any to any via xl0 ################################################################ # A rendszer belsõ interfészét se szûrjük. ################################################################ $cmd 00010 allow all from any to any via lo0 ################################################################ # A csomagot engedjük át a tûzfalon, ha korábban már felvettünk # hozzá egy dinamikus szabályt a keep-state opcióval. ################################################################ $cmd 00015 check-state ################################################################ # Az internet felé forgalmazó interfész (kimenõ kapcsolatok) # A saját hálózatunkról belülrõl vagy errõl az átjáróról # kezdeményezett kapcsolatokat vizsgáljuk az internet felé. ################################################################ # Kifelé engedélyezzük az internet-szolgáltatónk névszerverének # elérését. Az x.x.x.x a szolgáltatónk névszerverének IP-címe # legyen. Ha a szolgáltatónak több névszervere is van, akkor # másoljuk le ezeket a sorokat és az /etc/resolv.conf # állományban található IP-címeket helyettesítsük be. $cmd 00110 allow tcp from any to x.x.x.x 53 out via $pif setup keep-state $cmd 00111 allow udp from any to x.x.x.x 53 out via $pif keep-state # Kábel/DSL konfigurációk esetében kifelé engedélyezzük a # szolgáltatónk DHCP szerverének elérését. Ha a "felhasználói # PPP"-t használjuk, akkor erre nem lesz szükségünk, az egész # csoportot törölhetjük. Az alábbi szabállyal csíphetjük el a # beírandó IP-címet. Ha a naplóban megtaláltuk, akkor vegyük # ki az elsõ szabályt, a másodikba írjuk bele a címet és # engedélyezzük. $cmd 00120 allow log udp from any to any 67 out via $pif keep-state #$cmd 00120 allow udp from any to x.x.x.x 67 out via $pif keep-state # Kifelé engedélyezzük a szabvány nem biztonságos WWW # funkció elérését. $cmd 00200 allow tcp from any to any 80 out via $pif setup keep-state # Kifelé engedélyezzük a biztonságos HTTPS funkció # elérését TLS SSL használatával. $cmd 00220 allow tcp from any to any 443 out via $pif setup keep-state # Kifelé engedélyezzük a e-mailek küldését és fogadását. $cmd 00230 allow tcp from any to any 25 out via $pif setup keep-state $cmd 00231 allow tcp from any to any 110 out via $pif setup keep-state # Kifelé engedélyezzük a FreeBSD (a make install és a CVSUP) # funkcióit. Ezzel lényegében a rendszeradminisztrátornak # ,,ISTENI'' jogokat adunk. $cmd 00240 allow tcp from me to any out via $pif setup keep-state uid root # Kifelé engedélyezzük a pinget. $cmd 00250 allow icmp from any to any out via $pif keep-state # Kifelé engedélyezzük az idõ szolgáltatást. $cmd 00260 allow tcp from any to any 37 out via $pif setup keep-state # Kifelé engedélyezzük az nntp news szolgáltatást # (vagyis a hírcsoportokat) $cmd 00270 allow tcp from any to any 119 out via $pif setup keep-state # Kifelé engedélyezzük a biztonságos FTP, telnet és SCP # elérését az SSH (secure shell) használatával. $cmd 00280 allow tcp from any to any 22 out via $pif setup keep-state # Kifelé engedélyezzük a whois szolgáltatást. $cmd 00290 allow tcp from any to any 43 out via $pif setup keep-state # Dobjuk el és naplózzunk mindent, ami megpróbál kijutni. # Ez a szabály gondoskodik róla, hogy alapértelmezés szerint # mindent blokkoljunk. $cmd 00299 deny log all from any to any out via $pif ################################################################ # Az internet felõli interfész (bejövõ kapcsolatok) # A saját hálózatunk felé vagy erre az átjáróra # nyitott kapcsolatokat vizsgáljuk az internet felõl. ################################################################ # Blokkoljunk minden olyan bejövõ forgalmat, amely a fenntartott # címtartományok felé tart. $cmd 00300 deny all from 192.168.0.0/16 to any in via $pif #RFC 1918: privát IP $cmd 00301 deny all from 172.16.0.0/12 to any in via $pif #RFC 1918: privát IP $cmd 00302 deny all from 10.0.0.0/8 to any in via $pif #RFC 1918: privát IP $cmd 00303 deny all from 127.0.0.0/8 to any in via $pif #helyi $cmd 00304 deny all from 0.0.0.0/8 to any in via $pif #helyi $cmd 00305 deny all from 169.254.0.0/16 to any in via $pif #DHCP $cmd 00306 deny all from 192.0.2.0/24 to any in via $pif #dokumentációs célokra fenntartott $cmd 00307 deny all from 204.152.64.0/23 to any in via $pif #Sun klaszterek összekötésére használt $cmd 00308 deny all from 224.0.0.0/3 to any in via $pif #D és E osztályú multicast # A nyilvános pingek tiltása. $cmd 00310 deny icmp from any to any in via $pif # Az ident szolgáltatás tiltása. $cmd 00315 deny tcp from any to any 113 in via $pif # Blokkoljuk az összes Netbios szolgáltatást: 137=név, 138=datagram, # 139=session. A Netbios az MS Windows megosztását implementálja. # Blokkoljuk az MS Windows hosts2 névszerver kéréseit is a 81-es # porton. $cmd 00320 deny tcp from any to any 137 in via $pif $cmd 00321 deny tcp from any to any 138 in via $pif $cmd 00322 deny tcp from any to any 139 in via $pif $cmd 00323 deny tcp from any to any 81 in via $pif # Eldobjuk az összes késõn érkezõ csomagot. $cmd 00330 deny all from any to any frag in via $pif # Eldobjuk azokat az ACK csomagokat, amelyek egyik dinamikus # szabálynak sem felelnek meg. $cmd 00332 deny tcp from any to any established in via $pif # Befelé engedélyezzük a szolgáltató DHCP szerverének válaszát. Ebben # a szabályban csak a DHCP szerver IP-címe szerepelhet, mivel ez az # egyetlen olyan hitelesített forrás, ami ilyen csomagokat küldhet. # Ez csak a kábeles és DSL típusú kapcsolatok esetében szükséges. # Amikor a "felhasználói PPP"-vel csatlakozunk az internethez, nem # kell ez a szabály. Ugyanazt az IP-címet kell megadnunk, amelyet a # kimenõ kapcsolatoknál is. #$cmd 00360 allow udp from any to x.x.x.x 67 in via $pif keep-state # Befelé engedélyezzük a szabvány WWW funkciót, mivel webszerverünk # is van. $cmd 00400 allow tcp from any to me 80 in via $pif setup limit src-addr 2 # Befelé engedélyezzük a biztonságos FTP, telnet és SCP # típusú kapcsolatokat az internetrõl. $cmd 00410 allow tcp from any to me 22 in via $pif setup limit src-addr 2 # Befelé engedélyezzük az internetrõl érkezõ nem biztonságos telnet # kapcsolatokat. Azért tekintjük nem biztonságosnak, mert az # azonosítók és a jelszavak az interneten titkosítatlanul vándorolnak. # Töröljük ezt a csoportot, ha nincs telnet szolgáltatásunk. $cmd 00420 allow tcp from any to me 23 in via $pif setup limit src-addr 2 # Dobjuk el és naplózzuk az összes többi kintrõl érkezõ csomagot. $cmd 00499 deny log all from any to any in via $pif # Alapértelmezés szerint dobjuk el mindent. Az ide érkezõ # csomagokat is naplózzuk, amibõl többet is ki tudunk majd # deríteni. $cmd 00999 deny log all from any to any ############# Itt fejezõdnek be az IPFW szabályai ##################### Példa hálózati címfordításra és állapottartásra címfordítás és az IPFW Az IPFW címfordító funkciójának kihasználásához további konfigurációs beállítások alkalmazására is szükségünk lesz. A rendszermagban opció között meg kell adnunk az option IPDIVERT sort a többi IPFIREWALL sor mellett, és fordítanunk egy saját verziót. Emellett még az /etc/rc.conf állományban is engedélyezni kell az IPFW alapvetõ funkcióit. natd_enable="YES" # engedélyezzük a címfordításért felelõs démont natd_interface="rl0" # az internet felé mutató hálózati kártya neve natd_flags="-dynamic -m" # -m = a portszámok megtartása, ha lehetséges Az állapottartó szabályok használata a divert natd címfordítási opcióval együtt nagyban növeli a szabályrendszer leprogramozásának bonyolultságát. A check-state és divert natd szabályok helye kritikus a megfelelõ mûködés tekintetében. Az eddig megszokott egyszerû viselkedés itt már nem érvényesül. Bevezetünk egy új cselekvést is, amelynek a neve skipto. A skipto parancs használatához elengedhetetlen a szabályok sorszámozása, mivel pontosan tudnunk kell, hogy a skipto hatására hova kell ugrania a vezérlésnek. A következõ példában nem fogunk sok megjegyzést látni, mivel benne az egyik lehetséges programozási stílust próbáljuk érzékeltetni és a csomagok szabályrendszerek közti áramlását magyarázzuk. A feldolgozás a szabályokat tartalmazó állomány tetején található elsõ szabállyal kezdõdik, és innen egyesével pereg végig lefelé a feldolgozás egészen addig, amíg a csomag a szûrési feltételek valamelyikének eleget nem tesz és távozik a tûzfalból. Leginkább a 100-as, 101-es, 450-es, 500-as és 510-es sorszámú szabályokat emelnénk ki. Ezek vezérlik kimenõ és bejövõ csomagok fordítását, ezért a hozzájuk tartozó dinamikus állapottartó bejegyzések mindig a helyi hálózat IP-címeire hivatkoznak. Amit még érdemes megfigyelnünk, hogy az összes áteresztõ és eldobó szabályban szerepel a csomag haladási iránya (tehát kimenõ vagy éppen bejövõ) és az érintett interfészt megnevezése. Emellett azt is vegyük észre, hogy az összes kifelé irányuló kapcsolatlétrehozási kérés az 500-as sorszámú szabályhoz fog ugrani a címfordítás elvégzéséhez. Tegyük fel, hogy a helyi hálózatunkon levõ felhasználók szeretnek honlapokat nézgetni az interneten. A honlapok a 80-as porton keresztül kommunikálnak. Tehát amikor egy ilyen csomag eléri a tûzfalat, nem fog illeszkedni a 100-as szabályra, mert a fejléce szerint kifelé halad és nem befelé. A 101-es szabályon is átlép, mivel ez az elsõ csomag, így a dinamikus állapottartó táblázatban sem szerepel még. A csomag végül a 125-ös szabályra fog illeszkedni: kifelé halad az internetre csatlakozó hálózati kártyán. A csomagban azonban még mindig az eredeti forrás IP-címe található, amely a helyi hálózat egyik gépére hivatkozik. A szabály illeszkedésekor két cselekvés is végbemegy. A keep-state opció hatására ez a szabály felveszi ezt a kapcsolatot az állapottartó dinamikus szabályok közé és végrehajtja a másik megadott feladatot. Ez a feladat része a dinamikus táblázatba rögzített bejegyzésnek, ami ebben az esetben a skipto 500 (ugorjunk az 500-as szabályra) lesz. Az 500-as szabály a továbbküldés elõtt lefordítja a csomag forrás IP-címét. Ezt ne felejtsük el, nagyon fontos! A csomag ezután eljut a céljához, és visszatérve ismét belép a szabályrendszer tetején. Ezúttal illeszkedni fog a 100-as szabályra és a cél IP-címét visszafordítjuk a helyi hálózatunk megfelelõ gépének címére. Ezután a check-state szabályhoz kerül, amely megtalálja a dinamikus szabályok között és továbbengedi a belsõ hálózatra. Ezzel visszakerül a küldõ géphez, amely egy újabb csomagot küld egy újabb adatszeletet kérve a távoli szervertõl. Ekkor már a check-state szabály megtalálja a hozzátartozó bejegyzést a dinamikus szabályok között és végrehajtódik a korábban letárolt skipto 500 mûvelet. A csomag erre az 500-as szabályra ugrik, ahol lefordítjuk a címét és továbbküldjük. Az bejövõ oldalon minden, ami egy korábban kialakult kapcsolat részeként érkezik, automatikusan a check-state és a megfelelõ helyre rakott divert natd szabályok által dolgozódik fel. Itt mindössze a rossz csomagok eldobásával és a hitelesített szolgáltatások elérésének biztosításával kell foglalkoznunk. Például a tûzfalon egy webszerver fut, és azt szeretnénk, hogy az internetrõl képesek legyenek elérni a rajta levõ oldalakat. Az újonnan beérkezõ kapcsolatépítési kérelem a 100-as szabályra fog illeszkedni, amelynek a cél IP-címét a tûzfal helyi hálózaton található címére fogjuk leképezni. A csomagot ezután még megvizsgáljuk, nem tartalmaz-e valamilyen huncutságot, majd végül a 425-ös szabálynál fog kikötni. Az egyezéskor két dolog történhet: a csomaghoz felveszünk egy dinamikus szabályt, de ezúttal az adott forrás IP-címrõl érkezõ kapcsolatkérések számát 2-re lekorlátozzuk. Ezzel az adott szolgáltatás portján meg tudjuk óvni a tûzfalat üzemeltetõ gépet a DoS típusú támadásoktól. A csomagot ezután hozzátartozó cselekvés szerint továbbengedjük a belsõ hálózat felé. Visszatéréskor a tûzfal felismeri, hogy a csomag egy már meglevõ kapcsolathoz tartozik, ezért közvetlenül az 500-as szabályhoz kerül címfordításra, majd a kimenõ interfészen keresztül továbbküldjük. Íme az elsõ példa egy ilyen szabályrendszerre: #!/bin/sh cmd="ipfw -q add" skip="skipto 500" pif=rl0 ks="keep-state" good_tcpo="22,25,37,43,53,80,443,110,119" ipfw -q -f flush $cmd 002 allow all from any to any via xl0 # nem szûrjük a belsõ hálózatot $cmd 003 allow all from any to any via lo0 # nem szûrjük a helyi interfészt $cmd 100 divert natd ip from any to any in via $pif $cmd 101 check-state # A kimenõ csomagok hitelesítése: $cmd 120 $skip udp from any to xx.168.240.2 53 out via $pif $ks $cmd 121 $skip udp from any to xx.168.240.5 53 out via $pif $ks $cmd 125 $skip tcp from any to any $good_tcpo out via $pif setup $ks $cmd 130 $skip icmp from any to any out via $pif $ks $cmd 135 $skip udp from any to any 123 out via $pif $ks # Az összes olyan csomagot eldobjuk, amely a fenntartott # címtartományokba tart: $cmd 300 deny all from 192.168.0.0/16 to any in via $pif #RFC 1918: privát IP $cmd 301 deny all from 172.16.0.0/12 to any in via $pif #RFC 1918: privát IP $cmd 302 deny all from 10.0.0.0/8 to any in via $pif #RFC 1918: privát IP $cmd 303 deny all from 127.0.0.0/8 to any in via $pif #helyi $cmd 304 deny all from 0.0.0.0/8 to any in via $pif #helyi $cmd 305 deny all from 169.254.0.0/16 to any in via $pif #DHCP $cmd 306 deny all from 192.0.2.0/24 to any in via $pif #dokumentációs célokra fenntartott $cmd 307 deny all from 204.152.64.0/23 to any in via $pif #Sun klaszter $cmd 308 deny all from 224.0.0.0/3 to any in via $pif #D és E osztályú multicast # Az érkezõ csomagok hitelesítése: $cmd 400 allow udp from xx.70.207.54 to any 68 in $ks $cmd 420 allow tcp from any to me 80 in via $pif setup limit src-addr 1 $cmd 450 deny log ip from any to any # Ide ugrunk a kimenõ állapottartó szabályoknál: $cmd 500 divert natd ip from any to any out via $pif $cmd 510 allow ip from any to any ##################### a szabályok vége ################## A következõ példa teljesen megegyezik az elõzõvel, azonban itt már dokumentációs szándékkal szerepelnek megjegyzések is, melyek a tapasztalatlan IPFW szabályíróknak segítik jobban megérteni a szabályok pontos mûködését. A második példa: #!/bin/sh ############# Az IPFW szabályai itt kezdõdnek ########################### # Kezdés elõtt töröljük az összes jelenleg aktív szabályt: ipfw -q -f flush # Beállítjuk a parancsok megfelelõ elõtagjait: cmd="ipfw -q add" skip="skipto 800" pif="rl0" # az internethez csatlakozó # hálózati interfész neve ################################################################# # A belsõ hálózat számára ne korlátozzunk semmit se. # Ha nincs helyi hálózatunk, akkor erre nincs szükségünk. # Az 'xl0' nevét írjuk át a helyi hálózatra csatlakozó # interfész nevére. ################################################################# $cmd 005 allow all from any to any via xl0 ################################################################# # A rendszer belsõ interfészét se szûrjük. ################################################################# $cmd 010 allow all from any to any via lo0 ################################################################# # Ellenõrizzük, hogy ez egy beérkezõ csomag és ha igen, akkor # fordítsuk a címét. ################################################################# $cmd 014 divert natd ip from any to any in via $pif ################################################################# # Ha ehhez a csomaghoz korábban már vettük fel dinamikus # szabályt a keep-state opció révén, akkor engedjük tovább. ################################################################# $cmd 015 check-state ################################################################# # Az internet felé forgalmazó interfész (kimenõ kapcsolatok) # A saját hálózatunkról belülrõl vagy errõl az átjáróról # kezdeményezett kapcsolatokat vizsgáljuk az internet felé. ################################################################# # Kifelé engedélyezzük az internet-szolgáltatónk névszerverének # elérését. Az x.x.x.x a szolgáltató névszerverének IP-címe # lesz. Ha a szolgáltatónknak több névszervere is van, akkor # az /etc/resolv.conf állományból nézzük ki a címeiket és # másoljuk le az alábbi sor mindegyikükhöz. $cmd 020 $skip tcp from any to x.x.x.x 53 out via $pif setup keep-state # A kábeles és DSL kapcsolatok esetén engedélyezzük a szolgáltató # DHCP szerverének elérését. $cmd 030 $skip udp from any to x.x.x.x 67 out via $pif keep-state # Kifelé engedélyezzük a szabvány nem biztonságos WWW funkciót $cmd 040 $skip tcp from any to any 80 out via $pif setup keep-state # Kifelé engedélyezzük a biztonságos HTTPS funkciót a TLS SSL # használatával. $cmd 050 $skip tcp from any to any 443 out via $pif setup keep-state # Kifelé engedélyezzük az e-mailek küldését és fogadását. $cmd 060 $skip tcp from any to any 25 out via $pif setup keep-state $cmd 061 $skip tcp from any to any 110 out via $pif setup keep-state # Kifelé engedélyezzük a FreeBSD (make install és CVSUP) funkcióit. # Ezzel a rendszeradminisztrátornak ,,ISTENI'' jogokat adunk. $cmd 070 $skip tcp from me to any out via $pif setup keep-state uid root # Kifelé engedélyezzük a pinget. $cmd 080 $skip icmp from any to any out via $pif keep-state # Kifelé engedélyezzük az idõ szolgáltatást. $cmd 090 $skip tcp from any to any 37 out via $pif setup keep-state # Kifelé engedélyezzük az nntp news szolgáltatást (tehát a # hírcsoportokat). $cmd 100 $skip tcp from any to any 119 out via $pif setup keep-state # Kifelé engedélyezzük a biztonságos FTP, telnet és SCP # funkciókat az SSH (secure shell) használatával. $cmd 110 $skip tcp from any to any 22 out via $pif setup keep-state # Kifelé engedélyezzük ki a whois kéréseket. $cmd 120 $skip tcp from any to any 43 out via $pif setup keep-state # Kifelé engedélyezzük az NTP idõszerver elérését. $cmd 130 $skip udp from any to any 123 out via $pif keep-state ################################################################# # Az internet felõli interfész (bejövõ kapcsolatok) # A saját hálózatunk felé vagy erre az átjáróra # nyitott kapcsolatokat vizsgáljuk az internet felõl. ################################################################# # Tiltsuk a fenntartott címtartományok felé haladó összes beérkezõ # forgalmat. $cmd 300 deny all from 192.168.0.0/16 to any in via $pif #RFC 1918: privát IP $cmd 301 deny all from 172.16.0.0/12 to any in via $pif #RFC 1918: privát IP $cmd 302 deny all from 10.0.0.0/8 to any in via $pif #RFC 1918: privát IP $cmd 303 deny all from 127.0.0.0/8 to any in via $pif #helyi $cmd 304 deny all from 0.0.0.0/8 to any in via $pif #helyi $cmd 305 deny all from 169.254.0.0/16 to any in via $pif #DHCP $cmd 306 deny all from 192.0.2.0/24 to any in via $pif #dokumentációs célokra fenntartott $cmd 307 deny all from 204.152.64.0/23 to any in via $pif #Sun klaszter $cmd 308 deny all from 224.0.0.0/3 to any in via $pif #D és E osztályú multicast # Az ident tiltása. $cmd 315 deny tcp from any to any 113 in via $pif # Blokkoljuk az összes Netbios szolgáltatást: 137=név, 138=datagram, # 139=session. A Netbios az MS Windows megosztását implementálja. # Blokkoljuk az MS Windows hosts2 névszerver kéréseit is a 81-es # porton. $cmd 320 deny tcp from any to any 137 in via $pif $cmd 321 deny tcp from any to any 138 in via $pif $cmd 322 deny tcp from any to any 139 in via $pif $cmd 323 deny tcp from any to any 81 in via $pif # Dobjuk el a késõn érkezõ csomagokat. $cmd 330 deny all from any to any frag in via $pif # Dobjuk el azokat az ACK csomagokat, amelyekre nincs # dinamikus szabály. $cmd 332 deny tcp from any to any established in via $pif # Engedélyezzük a szolgáltató DHCP szerverétõl érkezõ forgalmat. Ennek # a szabálynak tartalmaznia kell a DHCP szerver címét, mert csak tõle # fogadunk el ilyen típusú csomagokat. Egyedül csak kábeles vagy DSL # konfigurációk esetén használatos, a "felhasználói PPP" esetében # törölhetjük. Ez ugyanaz az IP-cím, amelyet a kimenõ kapcsolatoknál # megadtunk. $cmd 360 allow udp from x.x.x.x to any 68 in via $pif keep-state # Befelé engedélyezzük a szabvány WWW funkciót, mivel van # webszerverünk. $cmd 370 allow tcp from any to me 80 in via $pif setup limit src-addr 2 # Befelé engedélyezzük a biztonságos FTP, telnet és SCP # használatát az internetrõl. $cmd 380 allow tcp from any to me 22 in via $pif setup limit src-addr 2 # Befelé engedélyezzük a nem biztonságos telnet elérését az # internetrõl. Azért nem tekintjük biztonságosnak, mert az # azonosítókat és a jelszavakat az interneten titkosítatlanul # közvetíti. Ha nincs telnet szolgáltatásunk, akkor törölhetjük is ezt # a csoportot. $cmd 390 allow tcp from any to me 23 in via $pif setup limit src-addr 2 # Dobjuk el és naplózzuk az összes internetrõl érkezõ hitelesítetlen kapcsolatot. $cmd 400 deny log all from any to any in via $pif # Dobjuk el és naplózzuk az összes internetre menõ hitelesítetlen kapcsolatot. $cmd 450 deny log all from any to any out via $pif # Ez lesz a kimenõ szabályokhoz tartozó "skipto" célja. $cmd 800 divert natd ip from any to any out via $pif $cmd 801 allow ip from any to any # Minden mást alapértelmezés szerint tiltunk és naplózunk. $cmd 999 deny log all from any to any ############# Az IPFW szabályai itt fejezõdnek be ##################### diff --git a/hu_HU.ISO8859-2/books/handbook/linuxemu/chapter.sgml b/hu_HU.ISO8859-2/books/handbook/linuxemu/chapter.sgml index cb95baff77..c2d969f4fc 100644 --- a/hu_HU.ISO8859-2/books/handbook/linuxemu/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/linuxemu/chapter.sgml @@ -1,4417 +1,4443 @@ Jim Mock Átdolgozta és egyes részeit aktualizálta: Brian N. Handy Eredetileg írta: Rich Murphey Bináris Linux kompatibilitás Áttekintés Bináris Linux kompatibilitás bináris kompatibilitás Linux A &os; számos más &unix;-szerû operációs rendszerhez nyújt bináris kompatibilitást, köztük a Linuxhoz is. Elcsodálkozhatnánk rajta, hogy vajon miért kell tudnia a &os;-nek Linux binárisokat futtatnia? A válasz erre nagyon egyszerû. Rengeteg cég és fejlesztõ kizárólag csak Linuxra fejleszt, hiszen ez mostanság egy nagyon izgalmas téma az informatika világában. Emiatt azonban a &os; közösségnek külön gyõzködnie kell ezeket a cégeket és fejlesztõket, hogy készítsék el a termékeik natív &os;-s változatát. Ezzel az a gond, a legtöbb ilyen cég egyszerûen nem veszi észre, hogy ha létezne a terméküknek &os;-re írt változata, akkor még többen használnák. Így továbbra is csak Linuxra fejlesztenek. Mit tudnak tenni ilyenkor a &os; használói? Nos, ekkor jön jól a &os; bináris szintû kompatibilitása. Dióhéjban úgy tudnánk összefoglalni, hogy ennek köszönhetõen a &os; felhasználók képesek a linuxos alkalmazások közel 90%-át mindenféle további módosítás nélkül futtatni. Így tehát használható a &staroffice;, &netscape; Linux változata, az &adobe; &acrobat;, &realplayer;, VMware, &oracle;, &wordperfect;, Doom, Quake, és még sok minden más. Sõt, egyes tapasztalatok szerint bizonyos helyzetekben a &os; által futtatott Linux binárisok sokkal jobban teljesítenek, mint Linux alatt. Azonban vannak olyan Linuxra jellemzõ, az operációs rendszer szintjén meghúzódó eszközök, amelyek &os; alatt nem használhatóak. &os;-n nem fognak mûködni azok a Linux binárisok, amelyek túlzottan kihasználják az olyan &i386;-os rendszerhívásokat, mint például a virtuális 8086 mód. A fejezet elolvasása során megismerjük: hogyan engedélyezzük rendszerünkön a Linux kompatibilitást; hogyan telepítsünk linuxos osztott könyvtárakat; hogyan telepítsünk linuxos alkalmazásokat a &os; rendszerünkre; a &os; Linux kompatibilitásának implementációs részleteit. A fejezet elolvasásához ajánlott: külsõ szoftverek telepítésének ismerete (). Telepítés KLD (betölthetõ rendszermag objektum) A bináris Linux kompatibilitás alapértelmezés szerint nem engedélyezett. Legkönnyebben úgy tudjuk elérhetõvé tenni, ha betöltjük a linux nevû KLD modult (Kernel LoaDable). Ehhez root felhasználóként a következõket kell begépelni: &prompt.root; kldload linux Ha minden egyes rendszerindítás során engedélyezni szeretnénk a bináris kompatibilitást, akkor tegyük bele az /etc/rc.conf állományba ezt a sort: linux_enable="YES" A modul betöltõdését a &man.kldstat.8; paranccsal tudjuk ellenõrizni: &prompt.user; kldstat Id Refs Address Size Name 1 2 0xc0100000 16bdb8 kernel 7 1 0xc24db000 d000 linux.ko a rendszermag beállításai COMPAT_LINUX Ha valamiért nem akarjuk vagy nem éppen nem tudjuk betölteni a modult, akkor a bináris Linux kompatibilitást az options COMPAT_LINUX beállítással be is tudjuk építeni a rendszermagba. Ennek pontos menetét a ben találjuk meg. Linuxos futtatókönyvtárak telepítése Linux linuxos könyvtárak telepítése A linuxos könyvtárakat két módon is felrakhatjuk: egyrészt a linux_base port telepítésével, másrészt manuálisan. A könyvtárak telepítése a linux_base porttal Portgyûjtemény A futtatókönyvtárakat a lehetõ legegyszerûbben a emulators/linux_base porton keresztül tudjuk telepíteni. Teljesen úgy történik, mint a Portgyûjtemény akármelyik másik portjának telepítése. Csupán ennyit kell beírnunk: &prompt.root; cd /usr/ports/emulators/linux_base-f10 &prompt.root; make install distclean A &os; 8.0 kiadását megelõzõ változataiban az emulators/linux_base-f10 port helyett az emulators/linux_base-fc4 portot használjuk. A telepítés végeztével kaptunk is egy mûködõ bináris Linux kompatibilitást, habár egyes programok még panaszkodhatnak a rendszerkönyvtárak alverzióit illetõen. Általánosságban véve ez azonban nem okoz nagyobb gondot. A emulators/linux_base portnak több változata is használható, melyek az egyes Linux disztribúcióknak feleltethetõek meg. Ilyenkor mindig érdemes közülük azt választani, amelyik a leginkább megfelel a telepíteni kívánt linuxos alkalmazás igényeinek. A könyvtárak telepítése manuálisan Ha korábban még nem telepítettük volna a Portgyûjteményt, akkor egyénileg kell felraknunk az egyes könyvtárakat. Közülük azokra lesz szükségünk, amelyeket maga az alkalmazás is használni akar, valamint a futásidejû linkerre. Emellett még a &os; rendszerükön levõ Linux binárisok számára a /compat/linux könyvtárban létre kell hoznunk a gyökér ún. árnyékkönyvtárát is. A &os; alatt elindított Linux programok elõször ebben a könyvtárban fogják keresni a hozzájuk tartozó osztott könyvtárakat. Így tehát, amikor egy linuxos program betölti például a /lib/libc.so függvénykönyvtárat, akkor a &os; elõször a /compat/linux/lib/libc.so állományt próbálja meg megnyitni, majd ha az nem létezik, akkor a /lib/libc.so állományt. Az osztott könyvtárak ezért a /compat/linux/lib árnyékkönyvtárba telepítendõek, és nem oda, ahova a linuxos ld.so mutat. Általánosságban szólva eleinte elég csak azokat az osztott könyvtárakat megkeresni és felrakni, amelyekre a telepítendõ linuxos alkalmazásunknak ténylegesen szüksége van. Egy idõ után úgyis összegyûlnek azok a fontosabb függvénykönyvtárak, amelyek segítségével már minden további ráfordítás nélkül futtatni tudjuk a frissen importált programokat. Hogyan telepítsünk újabb osztott könyvtárakat? osztott könyvtárak Mit tegyünk, ha az emulators/linux_base port telepítése után az alkalmazás még mindig követel néhány hiányzó osztott könyvtárat? Honnan tudhatjuk meg, hogy milyen osztott könyvtárak kellenek majd egy Linux bináris használatához és honnan szerezzük be ezeket? Erre alapvetõn két lehetõségünk van (az utasításokat root felhasználóként kell majd végrehajtanunk). Ha hozzáférünk egy Linux rendszerhez, akkor szedjük össze az alkalmazásunk futtatásához szükséges osztott könyvtárakat és másoljuk ezeket a &os; partíciójára. Például: Tegyük fel, hogy FTP-n keresztül leszedtük a Doom Linux változatát és felraktuk egy általunk elérhetõ Linux rendszerre. Az ldd linuxdoom parancs segítségével ki tudjuk deríteni, milyen osztott könyvtárak kellenek majd nekünk: &prompt.user; ldd linuxdoom libXt.so.3 (DLL Jump 3.1) => /usr/X11/lib/libXt.so.3.1.0 libX11.so.3 (DLL Jump 3.1) => /usr/X11/lib/libX11.so.3.1.0 libc.so.4 (DLL Jump 4.5pl26) => /lib/libc.so.4.6.29 szimbolikus linkek Az utolsó oszlopban levõ állományokat másoljuk át, tegyük ezeket a /compat/linux könyvtárba, és hozzunk létre az elsõ oszlopban szereplõ szimbolikus linkeket. Így tehát a következõ állományok kellenének: /compat/linux/usr/X11/lib/libXt.so.3.1.0 /compat/linux/usr/X11/lib/libXt.so.3 -> libXt.so.3.1.0 /compat/linux/usr/X11/lib/libX11.so.3.1.0 /compat/linux/usr/X11/lib/libX11.so.3 -> libX11.so.3.1.0 /compat/linux/lib/libc.so.4.6.29 /compat/linux/lib/libc.so.4 -> libc.so.4.6.29
Ha már rendelkezünk az ldd kimenetének elsõ oszlopában szereplõ fõverziószámú osztott könyvtár, akkor nem kell átmásolni az utolsó oszlopban levõ állományokat, hiszen így is mûködnie kellene mindennek. Ha viszont egy újabb változattal találkozunk, akkor érdemes mégis inkább átmásolni. Miután a szimbolikus linkeket átirányítottuk az új változatra, a régit akár törölhetjük is. Ha például ezek a könyvtárak elérhetõek a rendszerünkön: /compat/linux/lib/libc.so.4.6.27 /compat/linux/lib/libc.so.4 -> libc.so.4.6.27 Észrevesszük, hogy az ldd kimenetében az új bináris egy újabb változatot igényel: libc.so.4 (DLL Jump 4.5pl26) -> libc.so.4.6.29 Ha csak az utolsó jegyében marad le valamivel a verziószám, akkor nem különösebben aggódnunk a /lib/libc.so.4.6.29 miatt sem, hiszen a programnak egy picivel korábbi verzióval is remekül kellene tudnia mûködnie. Természetesen, ha akarjuk, ettõl függetlnül lecserélhetjük a libc.so állományt, ami ezt eredményezi: /compat/linux/lib/libc.so.4.6.29 /compat/linux/lib/libc.so.4 -> libc.so.4.6.29
A szimbolikus linkek karbantartása csak a Linux binárisok esetén szükséges. A &os; saját futásidejû linkere magától megkeresi a megfelelõ fõverziószámú könyvtárakat, ezért emiatt általában nem kell aggódni.
Linux ELF binárisok telepítése Linux ELF binárisok Az ELF binárisok futtatása elõtt néha még szükség van a megbélyegzés (branding) használatára is. Ha egy bélyegezetlen ELF binárist akarunk elindítani, akkor a következõ hibaüzenetet kapjuk: &prompt.user; ./egy-linux-elf-bináris ELF binary type not known Abort A &os; rendszermagjának a &man.brandelf.1; paranccsal tudunk segíteni a &os; és a Linux binárisainak megkülönböztetésében. &prompt.user; brandelf -t Linux egy-linux-elf-bináris GNU eszköztár A GNU által fejlesztett eszközök manapság már automatikusan elhelyezik az ELF binárisok azonosításához szükséges bélyegeket, ezért ez a lépés a jövõben egyre inkább feleslegessé válik. + + + + Tetszõleges RPM formátumú csomag + telepítése + A &os; a telepített (akár linuxos) + alkalmazások nyomonkövetésére + saját csomagadatbázissal rendelkezik, amelynek + következében a &linux; által + felkínált RPM adatbázisokat nem + támogatja. + + Ennek ellenére akármelyik RPM alapú + &linux; alkalmazás telepíthetõ + rendszerünkre a következõ módon: + + &prompt.root; cd /compat/linux +&prompt.root; rpm2cpio -q < /a/linuxos/allomány.helye.rpm | cpio -id + + Ezt követõen a &man.brandelf.1; + segítségével állítsuk be az ELF + binárisokat (könyvtárakat viszont ne!) + megfelelõ típusúra. Ekkor ugyan nem + leszünk képesek rendesen eltávolítani + az így telepített szoftvert, de ez a + módszer teszteléshez megfelelõ. A névfeloldó beállítása Ha a névfeloldás (DNS) valamiért nem mûködne, vagy egy ehhez hasonló üzenetet kapunk: resolv+: "bind" is an invalid keyword resolv+: "hosts" is an invalid keyword Akkor az /compat/linux/etc/host.conf állományba be kell illesztenünk a következõ sorokat: order hosts, bind multi on Az itt megszabott sorrend szerint elõször a /etc/hosts állományt nézi át, és majd csak ezután próbálja meg feloldani a nevet. Ha a /compat/linux/etc/host.conf állomány nem létezik, akkor a linuxos alkalmazás a &os; /etc/host.conf állományát találja meg, és panaszkodni fog a &os; eltérõ formátumára. Távolítsuk el a bind szócskát, ha nem állítottunk be névszervert az /etc/resolv.conf állományhoz. Boris Hollas A Mathematica 5.X verziójához igazította: A &mathematica; telepítése alkalmazások Mathematica Ebben a szakaszban megismerhetjük, hogyan telepítsük a &mathematica; 5.X Linux változatát &os; rendszerekre. A &mathematica; vagy a &mathematica; for Students linuxos változatai közvetlenül megrendelhetõek a fejlesztõtõl: . A &mathematica; telepítõjének elindítása Elõször is jeleznünk kell a &os;-nek, hogy a &mathematica; binárisai a linuxos ABI-t (Appplication Binary Interface) fogják használni. Itt legkönnyebben úgy járhatunk el, ha egyszerûen beállítjuk, hogy a rendszer a bélyegezetlen ELF binárisokat automatikusan Linux binárisoknak tekintse: &prompt.root; sysctl kern.fallback_elf_brand=3 Ennek köszönhetõen a &os; most már az összes bélyegezetlen ELF bináris esetén a linuxos ABI-t fogja használni, és így a telepítõt akár már közvetlenül a CD-rõl is indíthatjuk. Most másoljuk át a MathInstaller nevû állományt a merevlemezünkre: &prompt.root; mount /cdrom &prompt.root; cp /cdrom/Unix/Installers/Linux/MathInstaller helyi_könyvtár Az állományban cseréljük ki az elsõ sorban található /bin/sh hivatkozást a /compat/linux/bin/sh hivatkozásra. Ezzel biztosíthatjuk be, hogy a telepítõt a linuxos &man.sh.1; fogja elindítani. Ezután a kedvenc szövegszerkesztõnkkel vagy a következõ szakaszban található szkript segítségével helyettesítsük benne a Linux) szöveg összes elõfordulását a FreeBSD) szöveggel. Mivel a &mathematica; telepítõje az uname -s parancsra kapott válaszból állapítja meg az operációs rendszer típusát, ezért ezzel a módosítással a &os;-t is a Linuxhoz hasonló módon fogja kezelni. A MathInstaller elindítása után most már telepíthetõ a &mathematica;. A &mathematica; állományainak módosítása A &mathematica; telepítése során létrejött szkripteket a használatuk elõtt át kell írnunk. Amennyiben a &mathematica;hoz tartozó programokat a /usr/local/bin könyvtárba telepítettük, akkor itt találunk kell a math, mathematica, Mathematica és MathKernel állományokra mutató szimbolikus linkeket. Ezek mindegyikében cseréljük ki a Linux) karakterláncot a FreeBSD) szövegre a kedvenc szövegszerkesztõnkkel vagy az alábbi szkripttel: #!/bin/sh cd /usr/local/bin for i in math mathematica Mathematica MathKernel do sed 's/Linux)/FreeBSD)/g' $i > $i.tmp sed 's/\/bin\/sh/\/compat\/linux\/bin\/sh/g' $i.tmp > $i rm $i.tmp chmod a+x $i done A &mathematica; jelszavának megszerzése Ethernet MAC-cím A &mathematica; elsõ indítása során kérni fog egy jelszót. Ha még nem kértünk volna jelszót a fejlesztõtõl, akkor a számítógépünk azonosítójának (machine ID) megállapításához indítsuk el a telepítés könyvtárában található mathinfo nevû programot. Ez az azonosító lényegében az elsõdleges Ethernet kártyánk MAC-címe lesz, ezért a &mathematica; nem futtatható több számítógépen. Amikor e-mailen, telefonon vagy faxon keresztül regisztráljuk a terméket a Wolframnál, akkor meg kell adnunk nekik ezt az azonosítót machine ID néven, amire õk elküldik a hozzátartozó jelszót. A &mathematica; frontendjének futtatása hálózaton keresztül A &mathematica; a szabványos betûkészletekkel meg nem jeleníthetõ szimbólumokhoz (integráljelek, szummák, görög betûk, matematikai jelölések stb.) használ néhány olyan speciális betûtípust, amelyek nem minden esetben állnak rendelkezésre. A X által használt protokoll miatt ezeket a betûtípusokat helyben kell telepíteni. Ennek értelmében a &mathematica; CD-jén található betûtípusokat telepítenünk kell a számítógépünkre is. A CD-n ezeket általában a /cdrom/Unix/Files/SystemFiles/Fonts könyvtárban találjuk meg, vagy a merevlemezen a /usr/local/mathematica/SystemFiles/Fonts könyvtárban. Ezen belül pedig a Type1 és X alkönyvtárakra van szükségünk. Az alábbiakban leírtak szerint több módon is használhatjuk ezeket. Az egyik ilyen módszer, ha átmásoljuk az imént említett könyvtárakat a többi mellé, vagyis a /usr/X11R6/lib/X11/fonts könyvtárba. Ekkor szükségünk lesz még a fonts.dir állomány átírására is, ahova fel kell vennünk a betûtípusok neveit, majd ennek megfelelõen az elsõ sorban módosítanunk a könyvtárban található betûtípusok számát. De ugyanígy lefuttathatjuk ebben a könyvtárban a &man.mkfontdir.1; parancsot is. Az a másik megoldás, ha a könyvtárakat így másoljuk át a /usr/X11R6/lib/X11/fonts helyre: &prompt.root; cd /usr/X11R6/lib/X11/fonts &prompt.root; mkdir X &prompt.root; mkdir MathType1 &prompt.root; cd /cdrom/Unix/Files/SystemFiles/Fonts &prompt.root; cp X/* /usr/X11R6/lib/X11/fonts/X &prompt.root; cp Type1/* /usr/X11R6/lib/X11/fonts/MathType1 &prompt.root; cd /usr/X11R6/lib/X11/fonts/X &prompt.root; mkfontdir &prompt.root; cd ../MathType1 &prompt.root; mkfontdir Most adjuk hozzá az új könyvtárakat a betûtípusok könyvtáraihoz: &prompt.root; xset fp+ /usr/X11R6/lib/X11/fonts/X &prompt.root; xset fp+ /usr/X11R6/lib/X11/fonts/MathType1 &prompt.root; xset fp rehash Ha az &xorg; szervert használjuk, akkor az xorg.conf állományban megadhatjuk ezen könyvtárak automatikus betöltését is. Az &xfree86; típusú szerverek esetén az XF86Config konfigurációs állományt kell módosítanunk. betûk Ha még nincs /usr/X11R6/lib/X11/fonts/Type1 nevû könyvtárunk, akkor a példában szereplõ MathType1 könyvtárat nyugodtan átnevezhetjük Type1 nevûre. Aaron Kaplan Írta: Robert Getschmann Köszönet: A &maple; telepítése alkalmazások Maple A &maple; egy &mathematica;hoz hasonló kereskedelmi alkalmazás. A használatához elõször meg kell vásárolni a címrõl, majd a licenc megszerzéséhez ugyanott regisztrálni. &os;-re a szoftvert a következõ egyszerû lépéseken keresztül tudjuk telepíteni. Indítsuk el a termékhez mellékelt INSTALL nevû szkriptet. Válasszuk a telepítõprogram által felkínált opciók közül a RedHat címkéjût. A telepítés célkönyvtára legyen a /usr/local/maple. Ha eddig még nem tettük volna meg, rendeljük meg a &maple; licencét a Maple Waterloo Software-tõl () és másoljuk az /usr/local/maple/license/license.dat állományba. Az &maple;-höz mellékelt INSTALL_LIC szkript elindításával telepítsük a FLEXlm licenckezelõt. A szervernek adjuk meg a számítógépünk hálózati nevét. Javítsuk át a /usr/local/maple/bin/maple.system.type állományt a következõ módon: ----- itt kezdõdik a módosítás --------- *** maple.system.type.orig Sun Jul 8 16:35:33 2001 --- maple.system.type Sun Jul 8 16:35:51 2001 *************** *** 72,77 **** --- 72,78 ---- # the IBM RS/6000 AIX case MAPLE_BIN="bin.IBM_RISC_UNIX" ;; + "FreeBSD"|\ "Linux") # the Linux/x86 case # We have two Linux implementations, one for Red Hat and ----- módosítás vége ------------------- Vigyázzunk, hogy a "FreeBSD"|\ kezdetû sor végén nem szabad semmilyen további whitespace karakternek lennie. Ez a javítás arra utasítja a &maple;-t, hogy FreeBSD-t Linux rendszerként ismerje fel. A bin/maple szkript hívja a bin/maple.system.type szkriptet, ami pedig a uname -a hívással próbálja kideríteni a operációs rendszer nevét. Ettõl függõen választja ki, hogy milyen típusú binárisokat fog futtatni. Indítsuk el a licenckezelõ szervert. A most következõ szkripttel könnyedén el tudjuk indítani az lmgrd programot. A szkriptet /usr/local/etc/rc.d/lmgrd.sh néven hozzuk létre: ----- nyissz ----------- #! /bin/sh PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin PATH=${PATH}:/usr/local/maple/bin:/usr/local/maple/FLEXlm/UNIX/LINUX export PATH LICENSE_FILE=/usr/local/maple/license/license.dat LOG=/var/log/lmgrd.log case "$1" in start) lmgrd -c ${LICENSE_FILE} 2>> ${LOG} 1>&2 echo -n " lmgrd" ;; stop) lmgrd -c ${LICENSE_FILE} -x lmdown 2>> ${LOG} 1>&2 ;; *) echo "Usage: `basename $0` {start|stop}" 1>&2 exit 64 ;; esac exit 0 ----- nyissz ----------- Próbáljuk meg elindítani a &maple;-t: &prompt.user; cd /usr/local/maple/bin &prompt.user; ./xmaple Szerencsés esetben innentõl kezdve már minden mûködik. És ne felejtsünk el írni a Maplesoftnak, hogy szeretnénk egy natív &os; verziót a termékükbõl! Általános buktatók A FLEXlm licenckezelõvel esetenként nehéz lehet elboldogulni. Errõl témáról bõvebben a címen találunk leírásokat. Az lmgrd nagyon válogatós a licencállományokat illetõen és bármilyen apróságra kiakad. Egy szabályos licencállomány valahogy így néz ki: # ======================================================= # License File for UNIX Installations ("Pointer File") # ======================================================= SERVER chillig ANY #USE_SERVER VENDOR maplelmg FEATURE Maple maplelmg 2000.0831 permanent 1 XXXXXXXXXXXX \ PLATFORMS=i86_r ISSUER="Waterloo Maple Inc." \ ISSUED=11-may-2000 NOTICE=" Technische Universitat Wien" \ SN=XXXXXXXXX A sorozatszámot természetesen eltávolítottuk. Itt a chillig a számítógép neve. Az itt megadott licencállomány remekül használható egészen addig a pontig, amíg békén hagyjuk a FEATURE kezdetû sort (melyet a licenckulcs véd). Dan Pelleg Írta: A &matlab; telepítése alkalmazások MATLAB Ez a leírás azt mutatja be, hogyan telepítsük &os; rendszerekre a &matlab; version 6.5 Linux változatát. A &java.virtual.machine; (lásd ) használatától eltekintve meglepõen jól mûködik. A &matlab; Linux változata közvetlenül megrendelhetõ a The MathWorks-tõl, a címen. Ne felejtsük el beszerezni a licencállományt és az elkészítéséhez szükséges útmutatót. Ha már úgy is arra járunk, jelezzük a fejlesztõknek, hogy igényt tartanánk a termékük natív &os;-s változatára is! A &matlab; telepítése A &matlab; telepítéséhez a következõket kell tennünk: Helyezzük be a telepítõt CD-t és csatlakoztassuk. A telepítõszkript javaslatának megfelelõen váltsuk át a root felhasználóra. A szóbanforgó szkript elindításához gépeljük be a következõt: &prompt.root; /compat/linux/bin/sh /cdrom/install A telepítõ grafikus. Ha a megjelenítõ használatáról szóló hibaüzeneteket kapunk, akkor adjuk ki a setenv HOME ~FELHASZNÁLÓ parancsot, ahol a FELHASZNÁLÓ annak a felhasználónak a neve legyen, amivel az imént meghívtuk a &man.su.1; programot. Amikor a &matlab; könyvtárát kell megadnunk, ezt írjuk be: /compat/linux/usr/local/matlab. A telepítés további részeinek megkönnyítése érdekében írjuk be ezt a parancssorba: set MATLAB=/compat/linux/usr/local/matlab Miután megkaptuk a &matlab; licencét, az útmutatás szerint szerkesszük át. A licencállományt a kedvenc szövegszerkesztõnkkel akár már korábban elõ is készíthetjük, és majd amikor a telepítõnek szüksége lesz rá, másoljuk be $MATLAB/license.dat helyre. Futtassuk le a telepítést. Ezzel befejezõdõtt a &matlab; hagyományos telepítése. Innentõl már csak a &os; rendszer hozzátapasztásán fogunk dolgozni. A licenckezelõ elindítása Hozzunk létre szimbolikus linkeket a licenckezelõ szkriptjeire: &prompt.root; ln -s $MATLAB/etc/lmboot /usr/local/etc/lmboot_TMW &prompt.root; ln -s $MATLAB/etc/lmdown /usr/local/etc/lmdown_TMW Hozzunk létre egy indítószkriptet /usr/local/etc/rc.d/flexlm.sh néven. A lentebb látható minta a &matlab;hoz mellékelt $MATLAB/etc/rc.lm.glnx86 állomány egy módosított változata. Benne az állományok helyét és a licenckezelõ indításának körülményeit változtattuk meg (hogy Linux emuláció alatt fusson). #!/bin/sh case "$1" in start) if [ -f /usr/local/etc/lmboot_TMW ]; then /compat/linux/bin/sh /usr/local/etc/lmboot_TMW -u felhasználó && echo 'MATLAB_lmgrd' fi ;; stop) if [ -f /usr/local/etc/lmdown_TMW ]; then /compat/linux/bin/sh /usr/local/etc/lmdown_TMW > /dev/null 2>&1 fi ;; *) echo "Usage: $0 {start|stop}" exit 1 ;; esac exit 0 Tegyük ezt az állományt végrehajthatóvá: &prompt.root; chmod +x /usr/local/etc/rc.d/flexlm.sh A fenti szkriptben cseréljük ki a felhasználó nevét a rendszerünkben levõ egyik felhasználó nevére (ami persze nem a root). A licenckezelõt az alábbi paranccsal indítsuk el: &prompt.root; /usr/local/etc/rc.d/flexlm.sh start A &java; futtató környezet élesítése A &java; futtató környezet (&java; Runtime Environment, JRE) linkjét irányítsuk át egy &os; alatt mûködõ változatéra: &prompt.root; cd $MATLAB/sys/java/jre/glnx86/ &prompt.root; unlink jre; ln -s ./jre1.1.8 ./jre A &matlab; indítószkriptjének elkészítése Hozzunk létre egy ilyen indítószkriptet a /usr/local/bin/matlab könyvtárban: #!/bin/sh /compat/linux/bin/sh /compat/linux/usr/local/matlab/bin/matlab "$@" Futtassuk le a chmod +x /usr/local/bin/matlab parancsot. A szkript lefutása során a emulators/linux_base verziójától függõen hibákat is kaphatunk. Ha el akarjuk kerülni ezeket, akkor szerkesszük át a /compat/linux/usr/local/matlab/bin/matlab állomány következõ sorát: if [ `expr "$lscmd" : '.*->.*'` -ne 0 ]; then (a 13.0.1 számú verzióban ez 410. sor) erre: if test -L $newbase; then A &matlab; leállító szkriptjének elkészítése A &matlab; szabálytalan kilépéseit az alábbi utasítások nyomán tudjuk megszüntetni. Hozzunk létre egy $MATLAB/toolbox/local/finish.m nevû állományt, majd írjuk bele ezt a sort: ! $MATLAB/bin/finish.sh A $MATLAB szöveget pontosan így írjuk be. Ugyanebben a könyvtárban találjuk a beállításaink kilépés elõtti mentéséért felelõs finishsav.m és finishdlg.m állományokat. Ha ezek valamelyikét módosítjuk, akkor a elõbbi parancsot közvetlenül a save után szúrjuk be. Hozzunk létre egy $MATLAB/bin/finish.sh állományt, amiben szerepeljen a következõ: #!/usr/compat/linux/bin/sh (sleep 5; killall -1 matlab_helper) & exit 0 Tegyük végrehajthatóvá: &prompt.root; chmod +x $MATLAB/bin/finish.sh A &matlab; használata Most már a matlab parancs begépelésével bármikor elindíthatjuk. Marcel Moolenaar Írta: Az &oracle; telepítése alkalmazások Oracle Elõszó Ez a leírás azt mutatja be, hogyan telepítsük &os;-re az &oracle; 8.0.5 és &oracle; 8.0.5.1 Enterprise Edition Linux változatait. A Linux környezet telepítése Telepítsük a emulators/linux_base és devel/linux_devtools portokat a Portgyûjteménybõl. Amennyiben ennek során nehézségekbe ütköznénk, próbálkozzunk a korábbi változataikkal. Fel kell raknunk a Red Hat Tcl csomagját is, ha az alkalmazáshoz tartozó intelligens ügynököt is futtatni szeretnénk. Ez a tcl-8.0.3-20.i386.rpm. A hivatalos RPM port segítségével az alábbi általános parancson keresztül tudunk csomagokat telepíteni: &prompt.root; rpm -i --ignoreos --root /compat/linux --dbpath /var/lib/rpm csomag A csomag telepítésének semmilyen hibát nem kellene okoznia. Az &oracle; környezetének létrehozása Az &oracle; telepítéséhez elõször ki kell alakítanunk a megfelelõ környezetet. Ez a leírás kifejezetten arról szól, hogy &os;-n hogyan futtassuk a linuxos &oracle;-t, nem pedig az &oracle; telepítési útmutatójában bemutatottakat taglalja. A rendszermag hangolása a rendszermag hangolása Ahogy a &oracle; telepítési útmutatójában is olvashatjuk, be kell állítanunk az osztott memória maximális méretét. &os; alatt erre a célra ne használjuk a SHMMAX értéket, mivel az SHMMAX az SHMMAXPGS és PGSIZE értékekbõl számolódik ki. Ezért nekünk itt a SHMMAXPGS értékét kell meghatároznunk. Minden egyéb beállítás történhet az útmutatóban megadottak szerint. Például: options SHMMAXPGS=10000 options SHMMNI=100 options SHMSEG=10 options SEMMNS=200 options SEMMNI=70 options SEMMSL=61 Hangoljuk be ezeket az értékeket a &oracle; tervezett használatához. Emellett a konfigurációs állományban ne feledkezzünk meg az alábbi beállítások megadásáról sem: options SYSVSHM #SysV osztott memória options SYSVSEM #SysV szemaforok options SYSVMSG #SysV folyamatok közti kommunikáció Az &oracle; hozzáférése Egy rendes hozzáféréshez hasonlóan hozzunk létre egy külön oracle hozzáférést is rendszerünkön. Az oracle hozzáférés annyira különleges, hogy csak linuxos parancsértelmezõt társítsunk hozzá. Ehhez vegyük fel /compat/linux/bin/bash sort az /etc/shells állományba, majd állítsuk át az oracle nevû felhasználó parancsértelmezõjét a /compat/linux/bin/bash programra. Környezet A megszokott &oracle; környezeti változók, mint például a ORACLE_HOME és ORACLE_SID mellett még definiálnunk kell a következõket is: Változó Érték LD_LIBRARY_PATH $ORACLE_HOME/lib CLASSPATH $ORACLE_HOME/jdbc/lib/classes111.zip PATH /compat/linux/bin /compat/linux/sbin /compat/linux/usr/bin /compat/linux/usr/sbin /bin /sbin /usr/bin /usr/sbin /usr/local/bin $ORACLE_HOME/bin Javasoljuk, hogy az összes környezeti változót a .profile állományban adjuk meg. Ennek megfelelõen a példa beállításai így fognak kinézni benne: ORACLE_BASE=/oracle; export ORACLE_BASE ORACLE_HOME=/oracle; export ORACLE_HOME LD_LIBRARY_PATH=$ORACLE_HOME/lib export LD_LIBRARY_PATH ORACLE_SID=ORCL; export ORACLE_SID ORACLE_TERM=386x; export ORACLE_TERM CLASSPATH=$ORACLE_HOME/jdbc/lib/classes111.zip export CLASSPATH PATH=/compat/linux/bin:/compat/linux/sbin:/compat/linux/usr/bin PATH=$PATH:/compat/linux/usr/sbin:/bin:/sbin:/usr/bin:/usr/sbin PATH=$PATH:/usr/local/bin:$ORACLE_HOME/bin export PATH Az &oracle; telepítése A Linux emulátorban meghúzódó apró egyenletlenségek miatt a telepítés elõtt létre kell hoznunk egy .oracle nevû alkönyvtárat a /var/tmp könyvtárban. Helyezzük ezt a oracle felhasználó tulajdonába. Ezt követõen minden további gond nélkül képesek leszünk az &oracle; telepítésére. Ha netalán mégis problémákba ütköznénk, elõször mindig az &oracle; telepítési és konfigurációs állományait ellenõrizzük! Az &oracle; telepítése után rakjuk fel a következõ szakaszokban bemutatandó javításokat. Gyakran problémát okoz, ha a TCP protokollt még nem telepítettük. Ennek következményeképpen ugyanis nem tudnak elindulni a TCP alapú szolgáltatások. Az alábbi mûveletek ebben igyekeznek segíteni: &prompt.root; cd $ORACLE_HOME/network/lib &prompt.root; make -f ins_network.mk ntcontab.o &prompt.root; cd $ORACLE_HOME/lib &prompt.root; ar r libnetwork.a ntcontab.o &prompt.root; cd $ORACLE_HOME/network/lib &prompt.root; make -f ins_network.mk install Ne felejtsük el ismét elindítani a root.sh szkriptet! A root.sh javítása Az &oracle; telepítése során root (privilegizált) felhasználóként elvégzendõ mûveleteket a root.sh elnevezésû szkriptben találjuk. Ez a szkript a orainst könyvtárba kerül. A chown parancs helyes lefutásához alkalmazzunk az alább mellékelt javítást, vagy az egész szkriptet egy linuxos parancsértelmezõbõl indítsuk el. *** orainst/root.sh.orig Tue Oct 6 21:57:33 1998 --- orainst/root.sh Mon Dec 28 15:58:53 1998 *************** *** 31,37 **** # This is the default value for CHOWN # It will redefined later in this script for those ports # which have it conditionally defined in ss_install.h ! CHOWN=/bin/chown # # Define variables to be used in this script --- 31,37 ---- # This is the default value for CHOWN # It will redefined later in this script for those ports # which have it conditionally defined in ss_install.h ! CHOWN=/usr/sbin/chown # # Define variables to be used in this script Ha nem CD-rõl telepítjük az &oracle;-t, akkor akár a root.sh forrását is kijavíthatjuk. A neve rthd.sh, és a forrásfa orainst könyvtárában találhatjuk. A genclntsh javítása A genclntsh szkript a kliensek által használt osztott könyvtár létrehozására alkalmazható. Általában demók fordításához van rá szükség. Az alábbi javítás alkalmazásával a PATH változó értéke törölhetõ: *** bin/genclntsh.orig Wed Sep 30 07:37:19 1998 --- bin/genclntsh Tue Dec 22 15:36:49 1998 *************** *** 32,38 **** # # Explicit path to ensure that we're using the correct commands #PATH=/usr/bin:/usr/ccs/bin export PATH ! PATH=/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin export PATH # # each product MUST provide a $PRODUCT/admin/shrept.lst --- 32,38 ---- # # Explicit path to ensure that we're using the correct commands #PATH=/usr/bin:/usr/ccs/bin export PATH ! #PATH=/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin export PATH # # each product MUST provide a $PRODUCT/admin/shrept.lst Az &oracle; futtatása Ha rendesen követtük az iménti utasításokat, akkor most már úgy tudjuk futtatni az &oracle;-t, mintha csak Linuxon futna. Holger Kipp Írta: Valentino Vaschetto Az eredeti verziót SGML-re ültette: Az &sap.r3; telepítése alkalmazások SAP R/3 Az &sap; típusú rendszerek telepítéséhez &os;-re hivatalosan nem kaphatunk mûszaki segélynyújtást — csak a minõsített plaformokat támogatják. Elõszó Ez a leírás az &sap.r3; rendszer és &oracle; adatbázis Linux változatainak telepítését mutatja be &os;-n, beleértve a &os; és az &oracle; telepítését. Kétféle konfigurációt írunk le: &sap.r3; 4.6B (IDES) és &oracle; 8.0.5, FreeBSD 4.3-STABLE &sap.r3; 4.6C és &oracle; 8.1.7, FreeBSD 4.5-STABLE Habár ez a dokumentum igyekszik az összes fontos lépést a lehetõ legrészletesebb módon tárgyalni, semmiképpen sem célja az &oracle; és az &sap.r3; alkalmazásokhoz mellékelt telepítési útmutatók kiváltása. A kifejezetten az &sap; vagy az &oracle; Linux változataira vonatkozó kérdések, valamint az &oracle; és az &sap; OSS konkrét használatával kapcsolatos leírások tekintetében a saját dokumentációjukat olvassuk el. A szoftver Az &sap; telepítéséhez az alábbi CD-ket használtuk fel: &sap.r3; 4.6B, &oracle; 8.0.5 Név Szám Leírás KERNEL 51009113 SAP Kernel Oracle / telepítõ / AIX, Linux, Solaris RDBMS 51007558 Oracle / RDBMS 8.0.5.X / Linux EXPORT1 51010208 IDES / DB-Export / 1. lemez EXPORT2 51010209 IDES / DB-Export / 2. lemez EXPORT3 51010210 IDES / DB-Export / 3. lemez EXPORT4 51010211 IDES / DB-Export / 4. lemez EXPORT5 51010212 IDES / DB-Export / 5. lemez EXPORT6 51010213 IDES / DB-Export / 6. (utolsó) lemez Emellett még használtuk az &oracle; 8 Server (az elõzetes 8.0.5 változat a Linux 2.0.33 verziójához) CD-jét is, amely igazából nem feltétlenül szükséges, valamint a &os; (a 4.3 RELEASE kiadása után nem sokkal levõ) 4.3-STABLE változatát. &sap.r3; 4.6C SR2, &oracle; 8.1.7 Név Szám Leírás KERNEL 51014004 SAP Kernel Oracle / SAP Kernel 4.6D változat / DEC, Linux RDBMS 51012930 Oracle 8.1.7/ RDBMS / Linux EXPORT1 51013953 4.6C kiadás SR2 / Export / 1. lemez EXPORT1 51013953 4.6C kiadás SR2 / Export / 2. lemez EXPORT1 51013953 4.6C kiadás SR2 / Export / 3. lemez EXPORT1 51013953 4.6C kiadás SR2 / Export / 4. (utolsó) lemez LANG1 51013954 4.6C kiadás SR2 / Nyelvi támogatás / német, angol, francia / 1. lemez A telepítendõ nyelvtõl függõen egyéb nyelvi támogatást tartalmazó CD használata is szükségessé válhat. Itt most csak a német és angol nyelveket használjuk, ezért elegendõ az elsõ CD. Csendben hozzátesszük, hogy mind a négy EXPORT CD száma megegyezik. Ugyanígy a három nyelvi CD-nek is megegyeznek a számai (ez eltér a 4.6B IDES kiadás CD számozásától). Az írás pillanatában a &os; 4.5-STABLE (2002.03.20-i) változatát használjuk. &sap; füzetek Az &sap.r3; telepítésével kapcsolatban az alábbi füzetek bizonyultak hasznosnak: &sap.r3; 4.6B, &oracle; 8.0.5 Szám Cím 0171356 SAP Software on Linux: Essential Comments 0201147 INST: 4.6C R/3 Inst. on UNIX - Oracle 0373203 Update / Migration Oracle 8.0.5 --> 8.0.6/8.1.6 LINUX 0072984 Release of Digital UNIX 4.0B for Oracle 0130581 R3SETUP step DIPGNTAB terminates 0144978 Your system has not been installed correctly 0162266 Questions and tips for R3SETUP on Windows NT / W2K &sap.r3; 4.6C, &oracle; 8.1.7 Szám Cím 0015023 Initializing table TCPDB (RSXP0004) (EBCDIC) 0045619 R/3 with several languages or typefaces 0171356 SAP Software on Linux: Essential Comments 0195603 RedHat 6.1 Enterprise version: Known problems 0212876 The new archiving tool SAPCAR 0300900 Linux: Released DELL Hardware 0377187 RedHat 6.2: important remarks 0387074 INST: R/3 4.6C SR2 Installation on UNIX 0387077 INST: R/3 4.6C SR2 Inst. on UNIX - Oracle 0387078 SAP Software on UNIX: OS Dependencies 4.6C SR2 Hardverkövetelmények Az alábbi hardvereszközök szükségesek az &sap.r3; rendszer telepítéséhez. Az éles használathoz ennél természetesen valamivel több kell majd: Változat 4.6B 4.6C Processzor Két &pentium; III 800MHz Két &pentium; III 800MHz Memória 1GB ECC 2GB ECC Szabad hely a merevlemezen 50 - 60GB (IDES) 50 - 60GB (IDES) Éles használatra nagyobb gyorsítótárral rendelkezõ &xeon; processzorokat, nagysebességû háttértárakat (SCSI, hardveres RAID vezérlõvel), USV és ECC memória modulok ajánlottak. A nagy tárigényt egyébként az elõre beállított IDES rendszer indokolja, ami egy 27 GB méretû adatbázist hoz létre a telepítés során. Ez a terület általában elegendõ egy frissen induló rendszer és hozzátartozó alkalmazásadatok tárolására. &sap.r3; 4.6B, &oracle; 8.0.5 A következõ hardverkonfigurációt használtuk: két 800 MHz-es &pentium; III processzor és a hozzájuk tartozó alaplap, egy &adaptec; 29160 Ultra160 SCSI-vezérlõ (a 40/80 GB méretû DLT szalagos meghajtó és CD-meghajtó használatához) és egy &mylex; &acceleraid; RAID-vezérlõ (2 csatorna, 6.00-1-00 verziójú firmware és 32 MB memória), amihez két 17 GB-os (tükrözött) merevlemez és négy 36 GB-os merevlemez (RAID 5) csatlakozik. &sap.r3; 4.6C, &oracle; 8.1.7 Itt a hardver egy &dell; &poweredge; 2500 volt: kétprocesszoros alaplap, két darab 1000 MHz-es &pentium; III processzorral (fejenként 256 KB gyorsítótárral), 2 GB PC133-as ECC SDRAM memóriával, PERC/3 DC PCI RAID-vezérlõvel (128 MB memória), valamint egy EIDE DVD-meghajtóval. A RAID-vezérlõre két, egyenként 18 GB méretû merevlemezt (tükrözve) és négy 36 GB méretû merevlemezt csatlakoztattunk (RAID 5-ben). A &os; telepítése Elõször is telepítenünk kell a &os;-t. Ez több módon is lehetséges, ezekrõl a ban olvashatunk bõvebben. A lemezek felosztása Az egyszerûség kedvéért az &sap.r3; 46B és &sap.r3; 46C SR2 telepítése során is ugyanazt a felosztást használtuk. Egyedül az eszközök nevei változtak, mivel a telepítés eltérõ hardvereken történt (/dev/da) és /dev/amr, tehát ha az AMI &megaraid; esetén a /dev/da0s1a helyett a /dev/amr0s1a eszközt láthatjuk): Állományrendszer Méret (1 KB-os blokkokban) Méret (GB-ban) Csatlakozási pont /dev/da0s1a 1.016.303 1 / /dev/da0s1b 6 lapozóállomány /dev/da0s1e 2.032.623 2 /var /dev/da0s1f 8.205.339 8 /usr /dev/da1s1e 45.734.361 45 /compat/linux/oracle /dev/da1s1f 2.032.623 2 /compat/linux/sapmnt /dev/da1s1g 2.032.623 2 /compat/linux/usr/sap Elõre állítsuk be és inicializáljuk a két logikai meghajtót a &mylex; és a PERC/3 RAID-vezérlõkön. A hozzátartozó szoftver a BIOS indításának fázisában hívható be. A lemezek felosztása némileg eltér az &sap; által javasoltaktól, mivel az &sap; szerint az &oracle; könyvtárait (néhány másikkal együtt) külön-külön érdemes csatlakoztatni — mi most az egyszerûsítés kedvéért csak létrehoztuk ezeket. A <command>make world</command> és egy új rendszermag Töltsük le a legfrissebb -STABLE forrásokat. Fordítsuk újra az összes forrást (make world) és a beállításainak elvégzése után a saját rendszermagunkat is. Itt ne felejtsük el megadni az &sap.r3; és az &oracle; mûködéséhez szükséges paramétereket. A Linux környezet telepítése Az linuxos alaprendszer telepítése Elsõként a linux_base portot kell felraknunk (root felhasználóként): &prompt.root; cd /usr/ports/emulators/linux_base-fc4 &prompt.root; make install distclean A linuxos fejlesztõi környezet telepítése Ha az &oracle;-t &os;-re a ban leírtak szerint akarjuk telepíteni, akkor szükségünk lesz a linuxos fejlesztõeszközökre is: &prompt.root; cd /usr/ports/devel/linux_devtools &prompt.root; make install distclean A linuxos fejlesztõkörnyezetet csak az &sap.r3; 46B IDES telepítésénél raktuk fel. Nincs rá szükségünk, ha a &os; rendszeren nem akarjuk újralinkelni az &oracle; adatbázist. Pontosan ez a helyezet, amikor egy Linux rendszerhez gyártott &oracle; készletet használunk. A szükséges RPM csomagok telepítése RPM Az R3SETUP elindításához PAM támogatásra is szükségünk lesz. Amikor elõször próbáltuk meg telepíteni a &os; 4.3-STABLE változatára az &sap;-t, felraktuk PAM-et és az összes hozzátartozó csomagot, majd végül úgy bírtuk mûködésre, hogy kényszerítettük a PAM telepítését is. Az &sap.r3; 4.6C SR2 esetén szintén sikerült önmagában felrakni a PAM RPM csomagját is, tehát úgy néz ki, hogy a függõségeit már nem kell telepíteni: &prompt.root; rpm -i --ignoreos --nodeps --root /compat/linux --dbpath /var/lib/rpm \ pam-0.68-7.i386.rpm Az &oracle; 8.0.5 verziójához mellékelt intelligens ügynök futtatásához fel kell rakni a RedHat tcl-8.0.5-30.i386.rpm nevû Tcl csomagját is (máskülönben a az &oracle; telepítése közben szükséges újralinkelés nem fog mûködni). Vannak ugyan egyébként is gondok az &oracle; újralinkelésével, azonban ez linuxos probléma, nem pedig &os;-s. Néhány további tipp Hasznos lehet, ha felvesszük a linprocfs bejegyzést az /etc/fstab állományba. Ennek pontos részleteit a &man.linprocfs.5; man oldalon találjuk meg. Másik fontos paraméter a kern.fallback_elf_brand=3, amelyet az /etc/sysctl.conf állományba kell beszúrnunk. Az &sap.r3; környezetének létrehozása A szükséges állományrendszerek és csatlakozási pontok létrehozása Egy egyszerûbb telepítéshez elég csupán a következõ állományrendszereket elkészíteni: csatlakozási pont méret GB-ban /compat/linux/oracle 45 GB /compat/linux/sapmnt 2 GB /compat/linux/usr/sap 2 GB Készítenünk kell még néhány linket is, különben az &sap; telepítõje panaszkodni fogni az ellenõrzésük során: &prompt.root; ln -s /compat/linux/oracle /oracle &prompt.root; ln -s /compat/linux/sapmnt /sapmnt &prompt.root; ln -s /compat/linux/usr/sap /usr/sap Az egyik ilyen telepítés közben megjelenõ hibaüzenet (a PRD rendszer és az &sap.r3; 4.6C SR2 telepítése esetén): INFO 2002-03-19 16:45:36 R3LINKS_IND_IND SyLinkCreate:200 Checking existence of symbolic link /usr/sap/PRD/SYS/exe/dbg to /sapmnt/PRD/exe. Creating if it does not exist... WARNING 2002-03-19 16:45:36 R3LINKS_IND_IND SyLinkCreate:400 Link /usr/sap/PRD/SYS/exe/dbg exists but it points to file /compat/linux/sapmnt/PRD/exe instead of /sapmnt/PRD/exe. The program cannot go on as long as this link exists at this location. Move the link to another location. ERROR 2002-03-19 16:45:36 R3LINKS_IND_IND Ins_SetupLinks:0 can not setup link '/usr/sap/PRD/SYS/exe/dbg' with content '/sapmnt/PRD/exe' A felhasználók és könyvtárak létrehozása Az &sap.r3; rendszernek két felhasználóra és három csoportra van szüksége. Az igényelt felhasználók nevei az &sap; rendszer azonosítójától (System ID, SID) függenek, amely három betûbõl áll. Egyes ilyen rendszerazonosítók az &sap; számára vannak fenntartva. (Például a SAP és a NIX. Ezek teljes listáját az &sap; dokumentációjában találjuk meg.) Erre az IDES telepítéséhez az IDS, a 4.6C SR2 telepítésénél a PRD neveket adtuk, mivel ezeket a rendszereket éles használatra szánták. Ennélfogva a következõ csoportokat hoztuk létre hozzájuk (a csoportok azonosítói ugyan eltérhetnek az általunk használtaktól): csoport azonosítója csoport neve leírás 100 dba Adatbázis adminisztrátor 101 sapsys &sap; rendszer 102 oper Adatbázis operátor Az &oracle; alapértelmezett telepítésénél csak a dba csoport jön létre. A dba csoportot oper csoportként is használhatjuk (bõvebb információkért lásd az &oracle; és az &sap; dokumentációját). Ezenkívül az alábbi felhasználókra van még szükségünk: felhasználói azonosító felhasználói név általános név csoport egyéb csoportok leírás 1000 idsadm/prdadm sidadm sapsys oper &sap; adminisztrátor 1002 oraids/oraprd orasid dba oper &oracle; adminisztrátor Az &man.adduser.8; parancs használata során a következõkre lesz szükségünk egy &sap; Administrator létrehozásához (figyeljük a parancsértelmezõt (shell) és a felhasználói könyvtárat (home directory)): Name: sidadm Password: ****** Fullname: SAP Administrator SID Uid: 1000 Gid: 101 (sapsys) Class: Groups: sapsys dba HOME: /home/sidadm Shell: bash (/compat/linux/bin/bash) Ugyanígy az &oracle; Administrator esetében: Name: orasid Password: ****** Fullname: Oracle Administrator SID Uid: 1002 Gid: 100 (dba) Class: Groups: dba HOME: /oracle/sid Shell: bash (/compat/linux/bin/bash) A dba és oper csoportok használata során ne felejtsük el megadni az oper csoportot sem. Könyvtárak létrehozása A könyvtárakat általában külön állományrendszerekként hozzák létre, de ez teljesen az igényeinken múlik. Mi most egyszerû könyvtárakként alakítottuk ki ezeket, ezért tulajdonképpen ugyanazon a RAID 5 tömbön találhatóak meg: Ehhez elõször beállítjuk az egyes könyvtárak tulajdonosait és engedélyeit (root felhasználóként): &prompt.root; chmod 775 /oracle &prompt.root; chmod 777 /sapmnt &prompt.root; chown root:dba /oracle &prompt.root; chown sidadm:sapsys /compat/linux/usr/sap &prompt.root; chmod 775 /compat/linux/usr/sap Másodsorban orasid felhasználóként hozzuk létre az /oracle/SID alkönyvtárait: &prompt.root; su - orasid &prompt.root; cd /oracle/SID &prompt.root; mkdir mirrlogA mirrlogB origlogA origlogB &prompt.root; mkdir sapdata1 sapdata2 sapdata3 sapdata4 sapdata5 sapdata6 &prompt.root; mkdir saparch sapreorg &prompt.root; exit Az &oracle; 8.1.7 telepítésénél még további könyvtárakra is szükségünk lesz: &prompt.root; su - orasid &prompt.root; cd /oracle &prompt.root; mkdir 805_32 &prompt.root; mkdir client stage &prompt.root; mkdir client/80x_32 &prompt.root; mkdir stage/817_32 &prompt.root; cd /oracle/SID &prompt.root; mkdir 817_32 A client/80x_32 könyvtárnak pontosan ilyen névvel kell rendelkeznie. Ne cseréljük ki a benne szereplõ x-et semmire se! A harmadik lépésben létrehozzuk a sidadm felhasználóhoz tartozó könyvtárakat: &prompt.root; su - sidadm &prompt.root; cd /usr/sap &prompt.root; mkdir SID &prompt.root; mkdir trans &prompt.root; exit Az <filename>/etc/services</filename> A &sap.r3; mûködéséhez fel kell vennünk néhány olyan bejegyzést is az /etc/services állományba, amelyek a &os; telepítése során nem jönnek létre. Így tehát írjuk be az alábbi sorokat (legalább a használni kívánt példány számához illõ sorokat adjuk meg — ez jelen esetünkben most a 00. Természetesen az sem okoz gond, ha a dp, gw, sp és ms esetén beírjuk az összes példánynak megfelelõ portot 00-tól 99-ig). Amennyiben a SAProuter vagy az &sap; OSS használatára lenne szükségünk, akkor adjuk meg a SAProuter által lefoglalt 99-es példánynak megfelelõ 3299-es portot a rendszerünkön: sapdp00 3200/tcp # SAP menetirányító 3200 + a példány száma sapgw00 3300/tcp # SAP átjáró 3300 + a példány száma sapsp00 3400/tcp # 3400 + a példány száma sapms00 3500/tcp # 3500 + a példány száma sapmsSID 3600/tcp # SAP üzenetkezelõ szerver 3600 + a példány száma sapgw00s 4800/tcp # biztonságos SAP átjáró 4800 + a példány száma A szükséges nyelvi beállítások nyelvi beállítás Az &sap;-nek legalább két olyan nyelvre van szüksége, amely nem részei az alap RedHat telepítéseknek. Az &sap; a saját FTP szervereirõl elérhetõvé tette az ehhez szükséges RPM csomagokat (amelyek viszont csak OSS típusú hozzáférés birtokában tölthetõek le). A 0171356 számú jegyzet tartalmazza a beszerzendõ RPM-ek listáját. Megcsinálhatjuk úgy is, hogy egyszerûen csak linkeket hozunk létre (például az de_DE és en_US könyvtárakra), habár ezt egy éles rendszer esetében semmiképpen sem ajánljuk (az IDES rendszerrel tapasztalataink szerint eddig még remekül mûködött). Az alábbi nyelvi beállítások fognak tehát nekünk kelleni: de_DE.ISO-8859-1 en_US.ISO-8859-1 Így hozzuk létre hozzájuk a linkeket: &prompt.root; cd /compat/linux/usr/share/locale &prompt.root; ln -s de_DE de_DE.ISO-8859-1 &prompt.root; ln -s en_US en_US.ISO-8859-1 A telepítés során az iméntiek hiánya gondokat okozhat. Ha folyamatosan figyelmen kívül hagyjuk az ezekbõl fakadó hibákat (vagyis a CENTRDB.R3S állományban a gondot okozó lépések STATUS értékét OK-ra állítjuk), akkor komolyabb erõfeszítések megtétele nélkül majd képtelenek leszünk bejelentkezni a frissen telepített &sap; rendszerünkbe. A rendszermag finomhangolása a rendszermag finomhangolása Az &sap.r3; rendszerek temérdek mennyiségû erõforrást igényelnek. Ennek kielégítésére az alábbi paramétereket adjuk hozzá a rendszermag beállításait tartalmazó állományhoz: # Adjunk a memóriazabálóknak (SAP és Oracle): options MAXDSIZ="(1024*1024*1024)" options DFLDSIZ="(1024*1024*1024)" # Kell néhány System V beállítás is: options SYSVSHM # SYSV típusú osztott memória be options SHMMAXPGS=262144 # a megosztható memória maximális mérete lapokban #options SHMMAXPGS=393216 # a 46C telepítésekor ezt használjuk options SHMMNI=256 # az osztott memóriákhoz tartozó azonosítók maximális száma options SHMSEG=100 # a futó programonként megosztható szegmensek maximuma options SYSVMSG # SYSV típusú üzenetsorok options MSGSEG=32767 # a rendszerben keringõ üzenetszegmensek maximális száma options MSGSSZ=32 # az üzenetszegmensek mérete. 2 hatványa LEGYEN options MSGMNB=65535 # maximális karakter üzenetsoronként options MSGTQL=2046 # a rendszerben levõ üzenetek maximuma options SYSVSEM # SYSV típusú szemaforok options SEMMNU=256 # a szemaforok UNDO struktúráinak száma options SEMMNS=1024 # a rendszerben levõ szemaforok száma options SEMMNI=520 # a szemaforok azonosítóinak mennyisége options SEMUME=100 # az UNDO kulcsok száma Az itt megadott minimum értékek az &sap; által kiadott dokumentációkból származnak. Mivel a Linux változathoz errõl nincs külön leírás, ezért a (32 bites) HP-UX változat dokumentációi között érdemes ennek utánanézni. Mivel a 4.6C SR2 telepítéséhez használt rendszeren valamivel több fizikai memória állt rendelkezésünkre, ezért az osztott szegmensek méretét nagyobbra tudtuk megválasztani mind az &sap; és mind az &oracle; esetében, ami magyarázza a megosztható lapok nagyobb számát. Az &os; &i386; változatának telepítése során hagyjuk meg a MAXDSIZ és DFLDSIZ értékek alapértelmezett 1 GB-os maximumát. Ellenkezõ esetben ezekhez hasonló furcsa hibaüzeneteket láthatunk: ORA-27102: out of memory vagy Linux Error: 12: Cannot allocate memory. Az &sap.r3; telepítése Az &sap; CD-k elõkészítése Sok CD-t kell a telepítés során mozgatni, tehát csatlakoztatni és leválasztani. Ha viszont elegendõ meghajtóval rendelkezünk, akkor akár csatlakoztathatjuk egyszerre is az összeset. Vagy felmásolhatjuk a CD-t tartalmát a nekik megfelelõ könyvtárakba: /oracle/SID/sapreorg/cd-neve ahol a cd-neve a következõk valamelyike: KERNEL, RDBMS, EXPORT1, EXPORT2, EXPORT3, EXPORT4, EXPORT5 és EXPORT6 (4.6B/IDES), valamint KERNEL, RDBMS, DISK1, DISK2, DISK3, DISK4 és LANG (4.6C SR2). A csatlakoztatott CD-ken található állományok neveinek nagybetûseknek kell lenniük. Ha nem így lenne, akkor a csatlakoztatásnál adjuk meg a opciót. Így tehát a következõ parancsokat kell kiadnunk: &prompt.root; mount_cd9660 -g /dev/cd0a /mnt &prompt.root; cp -R /mnt/* /oracle/SID/sapreorg/cd-neve &prompt.root; umount /mnt A telepítõszkript futtatása Elsõként egy install nevû könyvtárat kell elõkészítenünk: &prompt.root; cd /oracle/SID/sapreorg &prompt.root; mkdir install &prompt.root; cd install Ezután futtassuk le a telepítõszkriptet, ami pedig bemásolja az install könyvtárba szinte az összes fontos állományt: &prompt.root; /oracle/SID/sapreorg/KERNEL/UNIX/INSTTOOL.SH Az IDES (4.6B) változathoz egy teljes &sap.r3; bemutató rendszer is tartozik, ezért a megszokott három CD helyett hat EXPORT típusú CD-bõl áll. Itt a CENTRDB.R3S telepítõsablon csak a szabvány központi példányt hozza létre (&r3; és az adatbázis), az IDES központi példányát már nem. Ezért az EXPORT1 könyvtárból ki kell másolnunk a CENTRDB.R3S állományt, különben az R3SETUP csak három EXPORT CD-t fog kérni. Az újabb &sap; 4.6 SR2 kiadáshoz négy EXPORT CD tartozik. A telepítés folyamatát a CENTRAL.R3S állományban levõ paraméterek vezérlik. A korábbi kiadásokkal ellentétben nincsenek külön sablonok az adatbázissal és a nélküle telepítendõ központi példányok számára. Az &sap; az adatbázisok telepítésére külön sablont használ. Újrakezdéskor a telepítést ettõl függetlenül elegendõ az eredeti állománnyal újraindítani. A telepítés közben és után az &sap;-nek a hostname paranccsal csak a gép saját nevét, nem pedig a teljes hálózati nevét kell megadnunk. Ilyenkor ezt vagy egyenként begépeljük, vagy létrehozunk rá egy álnevet az orasid és sidadm (valamint a megfelelõ lépésekben a root) felhasználóknak: alias hostname='hostname -s'. Ezenkívül még az &sap; telepítésekor létrehozott mindkét felhasználó .profile és .login állományait is beállíthatjuk ennek megfelelõen. Az <command>R3SETUP</command> 4.6B verziójának indítása Ne felejtsük el jól beállítani az LD_LIBRARY_PATH környezeti változót: &prompt.root; export LD_LIBRARY_PATH=/oracle/IDS/lib:/sapmnt/IDS/exe:/oracle/805_32/lib A telepítés könyvtárában root felhasználóként indítsuk el az R3SETUP programot: &prompt.root; cd /oracle/IDS/sapreorg/install &prompt.root; ./R3SETUP -f CENTRDB.R3S A szkript ezek után feltesz néhány kérdést (az alapértelmezett válaszok zárójelben, közvetlenül a megadottak után): Kérdés Alapértelmezés Válasz Enter SAP System ID [C11] IDSEnter Enter SAP Instance Number [00] Enter Enter SAPMOUNT Directory [/sapmnt] Enter Enter name of SAP central host [troubadix.domain.de] Enter Enter name of SAP db host [troubadix] Enter Select character set [1] (WE8DEC) Enter Enter Oracle server version (1) Oracle 8.0.5, (2) Oracle 8.0.6, (3) Oracle 8.1.5, (4) Oracle 8.1.6 1Enter Extract Oracle Client archive [1] (Yes, extract) Enter Enter path to KERNEL CD [/sapcd] /oracle/IDS/sapreorg/KERNEL Enter path to RDBMS CD [/sapcd] /oracle/IDS/sapreorg/RDBMS Enter path to EXPORT1 CD [/sapcd] /oracle/IDS/sapreorg/EXPORT1 Directory to copy EXPORT1 CD [/oracle/IDS/sapreorg/CD4_DIR] Enter Enter path to EXPORT2 CD [/sapcd] /oracle/IDS/sapreorg/EXPORT2 Directory to copy EXPORT2 CD [/oracle/IDS/sapreorg/CD5_DIR] Enter Enter path to EXPORT3 CD [/sapcd] /oracle/IDS/sapreorg/EXPORT3 Directory to copy EXPORT3 CD [/oracle/IDS/sapreorg/CD6_DIR] Enter Enter path to EXPORT4 CD [/sapcd] /oracle/IDS/sapreorg/EXPORT4 Directory to copy EXPORT4 CD [/oracle/IDS/sapreorg/CD7_DIR] Enter Enter path to EXPORT5 CD [/sapcd] /oracle/IDS/sapreorg/EXPORT5 Directory to copy EXPORT5 CD [/oracle/IDS/sapreorg/CD8_DIR] Enter Enter path to EXPORT6 CD [/sapcd] /oracle/IDS/sapreorg/EXPORT6 Directory to copy EXPORT6 CD [/oracle/IDS/sapreorg/CD9_DIR] Enter Enter amount of RAM for SAP + DB 850Enter (megabyte) Service Entry Message Server [3600] Enter Enter Group-ID of sapsys [101] Enter Enter Group-ID of oper [102] Enter Enter Group-ID of dba [100] Enter Enter User-ID of sidadm [1000] Enter Enter User-ID of orasid [1002] Enter Number of parallel procs [2] Enter Ha a CD-ket nem különbözõ helyekre másoltuk, akkor az &sap; telepítõje nem fogja megtalálni a ezeket (a rajtuk levõ LABEL.ASC segít neki az azonosításban) és kérni fogja a CD csatlakoztatását, illetve a csatlakozási pontjának megadását. A CENTRDB.R3S sem minden esetben mentes a hibáktól. A tapasztalataink szerint az EXPORT4 címkéjû CD-t kérte újra, miközben a helyes kulcsokat jelezte ki (6_LOCATION, majd 7_LOCATION stb.), így egyszerûen csak lépjünk tovább az értékek meghagyásával. Függetlenül az iménti megemlített problémáktól, egészen az &oracle; adatbáziskezelõ telepítéséig mindennek mûködnie kellene. Az <command>R3SETUP</command> 4.6C SR2 elindítása Állítsuk be jól az LD_LIBRARY_PATH környezeti változó értékét. Ez némileg eltér a 4.6B és az &oracle; 8.0.5 párosának beállításától: &prompt.root; export LD_LIBRARY_PATH=/sapmnt/PRD/exe:/oracle/PRD/817_32/lib A telepítés könyvtárából root felhasználóként indítsuk el az R3SETUP programot: &prompt.root; cd /oracle/PRD/sapreorg/install &prompt.root; ./R3SETUP -f CENTRAL.R3S A szkript ezek után feltesz néhány kérdést (az alapértelmezett válaszok zárójelben, közvetlenül a megadottak után): Kérdés Alapértelmezés Válasz Enter SAP System ID [C11] PRDEnter Enter SAP Instance Number [00] Enter Enter SAPMOUNT Directory [/sapmnt] Enter Enter name of SAP central host [majestix] Enter Enter Database System ID [PRD] PRDEnter Enter name of SAP db host [majestix] Enter Select character set [1] (WE8DEC) Enter Enter Oracle server version (2) Oracle 8.1.7 2Enter Extract Oracle Client archive [1] (Yes, extract) Enter Enter path to KERNEL CD [/sapcd] /oracle/PRD/sapreorg/KERNEL Enter amount of RAM for SAP + DB 2044 1800Enter (megabyte) Service Entry Message Server [3600] Enter Enter Group-ID of sapsys [100] Enter Enter Group-ID of oper [101] Enter Enter Group-ID of dba [102] Enter Enter User-ID of oraprd [1002] Enter Enter User-ID of prdadm [1000] Enter LDAP support 3Enter (nincs támogatás) Installation step completed [1] (continue) Enter Choose installation service [1] (DB inst,file) Enter Az OSUSERDBSID_IND_ORA és OSUSERIDADM_IND_ORA lépésekben az orasid és sidadm) felhasználók létrehozása hibákra futhat. Függetlenül az említett problémáktól, az &oracle; adatbáziskezelõ telepítéséig mindennek remekül kell mûködnie. Az &oracle; 8.0.5 telepítése Az &oracle; Linux változatának telepítése során felmerülõ problémák tekintetében keressük fel az &sap; füzeteket és az &oracle; Readme állományait. A legtöbb, ha nem is az összes gondot az egymással nem kompatibilis függvénykönyvtárak okozzák. Az &oracle; telepítésének részleteit a Az &oracle; telepítése címû szakaszban találjuk. Az &oracle; 8.0.5 telepítése az <command>orainst</command> segítségével Az &oracle; 8.0.5 verziójának használata esetén néhány további függvénykönyvtár újralinkelésére is szükség lesz, mivel az &oracle; 8.0.5 még a régi glibc könyvtárral lett fordítva (RedHat 6.0), viszont a RedHat 6.1 már a glibc újabb verzióját használja. A linkelés mûködéséhez az alábbi csomagokat kell még telepítenünk: compat-libs-5.2-2.i386.rpm compat-glibc-5.2-2.0.7.2.i386.rpm compat-egcs-5.2-1.0.3a.1.i386.rpm compat-egcs-c++-5.2-1.0.3a.1.i386.rpm compat-binutils-5.2-2.9.1.0.23.1.i386.rpm A részleteket lásd az &sap; füzeteiben vagy az &oracle; Readme állományaiban. Amennyiben ez nem oldható meg, akkor az eredeti binárisok, esetleg az eredeti RedHat rendszerbõl származó újralinkelt binárisok is használhatóak (habár a telepítés pillanatában személyesen ezt nem tudtuk ellenõrizni). Az intelligens ügynök lefordításához fel kell raknunk a RedHat saját Tcl csomagját. Ha ehhez nem tudjuk beszerezni a tcl-8.0.3-20.i386.rpm csomagot, akkor a RedHat 6.1 változatához készült tcl-8.0.5-30.i386.rpm is megteszi. Az újralinkeléstõl eltekintve a telepítés többi része szinte adja magát: &prompt.root; su - oraids &prompt.root; export TERM=xterm &prompt.root; export ORACLE_TERM=xterm &prompt.root; export ORACLE_HOME=/oracle/IDS &prompt.root; cd $ORACLE_HOME/orainst_sap &prompt.root; ./orainst Az &oracle; On-Line Text Viewer kikapcsolásán (mivel az jelenleg nem Linux alatt sem érhetõ el) kívül mindegyik képernyõt hagyjuk jóvá az Enter billentyû lenyomásával. Az &oracle; ezután a rendelkezésre álló gcc, egcs vagy i386-redhat-linux-gcc helyett a i386-glibc20-linux-gcc használatával újra akarjuk linkelni magát. Idõ hiányában az &oracle; 8.0.5 PreProduction kiadásából emeltünk ki binárisokat, de az adatbáziskezelõ rendszer felélesztésére tett elsõ kísérleteink kudarcba fulladtak, és ezután a megfelelõ RPM-ek összeszedése valódi rémálomnak bizonyult. Az &oracle; 8.0.5 Pre-production Release for Linux (Kernel 2.0.33) telepítése A telepítés nagyon könnyû. Csatlakoztassuk a CD-t, majd indítsuk el a telepítõt. Ezután meg kell adnunk az &oracle; felhasználói könyvtárát és a telepítõ odamásolja az összes binárist. Habár a telepítés megkezdése elõtt a korábbi kísérleteink nyomát nem tüntettük el. Ezt követõen az &oracle; adatbázisrendszer minden további gond nélkül elindítható. Az &oracle; 8.1.7 Linux változatának telepítése Szedjük le az oracle8172.tgz állományt a Linux rendszeren létrehozott könyvtárából, és bontsuk ki a /oracle/SID/817_32/ könyvtárba. Az &sap.r3; telepítésének folytatása Elõször is ellenõrizzük az isamd (sidadm) és oraids (orasid) felhasználók környezeti beállításait. A .profile, .login és .cshrc állományaikban a korábbi beállítások szerint kell szerepelnie a hostname parancsnak. Ha még mindig a teljes hálózati név lenne meg bennünk, akkor a hostname parancsot át kell írni mind a három állományban a hostname -s parancsra. Az adatbázis feltöltése Ezután az R3SETUP folytatható vagy újraindítható (attól függõen, hogy a kilépés választottuk-e vagy sem). Az R3SETUP ekkor létrehozza az adatbázisban a táblákat és az R3load meghívásával feltölti ezeket adatokkal (a 46B IDES változat esetében az EXPORT1 - EXPORT6, a 46C esetében pedig a DISK1 - DISK4 lemezekrõl). Amikor a feltöltés befejezõdõtt (ami akár órákig is eltarthat), szükség lesz még néhány jelszó megadására is. A próbatelepítéseknél nyugodtan használhatjuk a jól ismert alapértelmezett jelszavakat (azonban mindenképpen változtassuk meg ezeket, ha egy kicsit is számít a biztonság!): Kérdés Válasz Enter Password for sapr3 sapEnter Confirum Password for sapr3 sapEnter Enter Password for sys change_on_installEnter Confirm Password for sys change_on_installEnter Enter Password for system managerEnter Confirm Password for system managerEnter A 4.6B telepítése során még gondjaink akadtak a dipgntab használatával. Az &oracle; Listener elindítása Így kell elindítani az orasid felhasználóval az &oracle; Listenert: &prompt.user; umask 0; lsnrctl start Ha máshogy próbálkozunk, akkor az ORA-12546 kódú hibát fogjuk kapni, mert a hálózati portok socketei nem rendelkeznek a szükséges engedélyekkel. Lásd a 072984-es &sap; füzet. Az MNLS táblák frissítése Ha nem Latin 1 kódolású nyelveket akarunk importálni az &sap; rendszerbe, akkor frissítenünk kell a többnyelvû nyelvi támogatáshoz (Multi National Language Support, MNLS) tartozó táblázatokat. Ezek bemutatását a 15023 és 45619 számú &sap; OSS füzetekben olvashatjuk. Minden más esetben az &sap; telepítésekor nyugodtan kihagyhatjuk. Ha még nincs is konkrétan szükségünk az MNLS-re, akkor is ellenõriznünk és inicializálnunk kell a TCPDB táblát. A 0015023 és 0045619 számú &sap; füzetekben tudhatunk meg errõl többet. Telepítés utáni teendõk Az &sap.r3; licenckulcsának megszerzése Az &sap.r3; licenckulcsát külön kell kérni. Fontos, mert a telepítéshez használatos ideiglenes licenc csak négy hétig érvényes. Elõször szerezzük meg a hardverkulcsot. Jelentkezzünk be az idsadm felhasználóval és adjuk ki a saplicense parancsot: &prompt.root; /sapmnt/IDS/exe/saplicense -get Ha a saplicense paraméter nélkül meghívására válaszul opciókat listáz ki. A licenckulcsot megérkezése után így tudjuk élesíteni: &prompt.root; /sapmnt/IDS/exe/saplicense -install Ezután a következõ értékeket kell megadni: SAP SYSTEM ID = SID, 3 karakter CUSTOMER KEY = hardverkulcs, 11 karakter INSTALLATION NO = telepítés száma, 10 számjegy EXPIRATION DATE = ééééhhnn, tehát "99991231" LICENSE KEY = licenckulcs, 24 karakter A felhasználók létrehozása Hozzunk létre egy felhasználót a 000 kliensen belül (a csak rajta belül elvégezhetõ feladatokhoz, aki különbözik a sap* és ddic felhasználóktól). Felhasználónévként általában a wartung nevet választottuk (ami angolul a service névnek, avagy szolgáltatásnak felel meg). A sap_new és sap_all nevû profilok is kellenek. A biztonságosság kedvéért a kliens összes alapértelmezett felhasználójának (beleértve a sap* és ddic felhasználókat is) változtassuk meg a jelszavát. A szállítási rendszer, a profilok, mûködési módok stb. beállítása A ddic és sap* felhasználóktól eltérõ nevû felhasználóval a 000 kliensen belül legalább a következõket végezzük el: Feladat Tranzakció A szállítási rendszer (Transport System) beállítása, például a Stand-Alone Transport Domain Entity értékre STMS A rendszer profiljának létrehozása és szerkesztése RZ10 A mûködési módok és példányok karbantartása RZ04 Az iménti és az összes többi telepítés utáni lépések leírása teljes egészében megtalálható az &sap; telepítési útmutatóiban. Az <filename>init<replaceable>sid</replaceable>.sap</filename> (<filename>initIDS.sap</filename>) szerkesztése Az /oracle/IDS/dbs/initIDS.sap állomány tartalmazza a &sap; tartalék profilját. Itt többek közt a használni kívánt szalag méretét, a tömörítés típusát és hasonló paramétereket kell definiálni. A sapdba / brbackup futtatásához a következõ értékeket változtattuk meg: compress = hardware archive_function = copy_delete_save cpio_flags = "-ov --format=newc --block-size=128 --quiet" cpio_in_flags = "-iuv --block-size=128 --quiet" tape_size = 38000M tape_address = /dev/nsa0 tape_address_rew = /dev/sa0 Magyarázat: compress (tömörítés): HP DLT1 típusú szalagot használtunk, ami tud hardveres tömörítést. archive_function (archiválási házirend): Ez adja meg, hogy alapértelmezés szerint mi történjen az &oracle; archívált naplóival: az új naplóállományok elõször a szalagra mentõdnek, majd a már lementett naplók ismét mentésre kerülnek és végül törlõdnek. Ezzel sok fejfájástól menekülünk meg, mivel ilyenkor az archiváló szalagok esetleges sérülése esetén is valószínûleg képesek leszünk visszaállítani az adatbázist. cpio_flags (a cpio beállítása): A használata alapértelmezés, amivel a blokkok mérete 5120 byte-ra állítódik. A DLT típusú szalagokhoz a HP legalább 32 KB-os blokkméretet javasolt, ezért a beállítással ezt 64 KB-ra növeltük. Szükségünk volt a beállításra is, mivel 65535-nél több inode számunk van. Az utolsó beállítás a , amivel megakadályozzuk, hogy a cpio lementett blokkokat összefoglaló kijelzésére begerjedjen a brbackup. cpio_in_flags (a cpio bemeneti beállításai): A szalagok visszatöltésénél használt beállítások. A formátumot automatikusan felismeri. tape_size (szalagméret): Ezzel adjuk meg általában a szalag nyers kapacitását. Biztonsági okokból (hardveres tömörítést használunk) ez az érték a ténylegesnél valamivel kisebb. tape_address (szalagos eszköz): a cpio által használható nem visszatekerhetõ eszköz. tape_address_rew (visszatekerhetõ szalagos eszköz): A cpio által használható visszatekerhetõ eszköz. Telepítés utáni beállítások Az &sap; alábbi paramétereit kell beállítani a telepítés után (IDES 46B, 1 GB memóriával): Név Érték ztta/roll_extension 250000000 abap/heap_area_dia 300000000 abap/heap_area_nondia 400000000 em/initial_size_MB 256 em/blocksize_kB 1024 ipc/shm_psize_40 70000000 0013026 &sap; füzet: Név Érték ztta/dynpro_area 2500000 0157246 &sap; füzet: Név Érték rdisp/ROLL_MAXFS 16000 rdisp/PG_MAXFS 30000 A fenti paraméterek használatával egy 1 gigabyte fizikai memóriával rendelkezõ rendszer esetén nagyjából így alakul a memóriahasználat: Mem: 547M Active, 305M Inact, 109M Wired, 40M Cache, 112M Buf, 3492K Free (547 MB aktív, 305 MB inaktív, 109 MB rögzített, 40 MB gyorsítótár, 112 MB puffer, 3492 KB szabad) A telepítés során adódó problémák Az <command>R3SETUP</command> újraindítása egy probléma kijavítása után Az R3SETUP hiba esetén leáll. Miután átnéztük a hibára utaló naplókat és elhárítottuk a hiba okát, újra el kell indítanunk az R3SETUP programot, majd a REPEAT opció kiválasztásával próbáljuk megismételni az R3SETUP által kifogásolt legutóbbi mûveletet. Az R3SETUP újraindításához egyszerûen adjuk meg a megfelelõ R3S állományt: &prompt.root; ./R3SETUP -f CENTRDB.R3S a 4.6B verzió esetén, vagy a &prompt.root; ./R3SETUP -f CENTRAL.R3S a 4.6C verzió esetén, függetlenül attól, hogy a hiba a CENTRAL.R3S vagy DATABASE.R3S állományoknál keletkezett. Egyes lépéseknél az R3SETUP úgy véli, hogy az &sap; programjai mûködnek (mivel a hozzájuk tartozó lépéseket már megtettük), így a hibák miatt az adatbázist esetleg korábban nem tudta elindítani. Ezért a hibák kijavításának végeztével az R3SETUP ismételt indítása elõtt nekünk kell beindítani mind az adatbázist, mind pedig az &sap; rendszert. Ne felejtsük el újra elindítani az &oracle; Listener segédprogramját sem (az orasid felhasználóval adjuk ki a umask 0; lsnrctl start parancsot), ha az idõközben leállt volna (például a rendszer kényszerû újraindítása miatt). OSUSERSIDADM_IND_ORA az <command>R3SETUP</command> közben Ha az R3SETUP panaszkodik ebben a lépésben, akkor írjuk át az általa ekkor használt sablont (a 4.6B esetén ez a CENTRDB.R3S, illetve a 4.6C esetén ez a CENTRAL.R3S vagy a DATABASE.R3S). Keressük a [OSUSERSIDADM_IND_ORA] szöveget, vagy csak a STATUS=ERROR bejegyzést, majd írjuk be a következõ értékeket: HOME=/home/sidadm (üres volt) STATUS=OK (ERROR státusza volt) Ezután indítsuk újra az R3SETUP programot. OSUSERDBSID_IND_ORA az <command>R3SETUP</command> közben Az R3SETUP ebben a lépésben is hajlamos panaszkodni. Az itt felbukkanó hiba hasonló az OSUSERSIDADM_IND_ORA lépésben jelentkezõhöz. Szerkesszük át az R3SETUP által ilyenkor használt sablont (4.6B verzió esetén ez a CENTRDB.R3S, illetve 4.6C verziónál a CENTRAL.R3S vagy DATABASE.R3S). Keressük meg a [OSUSERDBSID_IND_ORA] részt, vagy csak a STATUS=ERROR bejegyzést, majd írjuk át az ebben a szakaszban szereplõ értéket így: STATUS=OK Indítsuk újra az R3SETUP programot. <errorname>oraview.vrf FILE NOT FOUND</errorname> hiba az &oracle; telepítése közben A telepítés megkezdése elõtt nem tiltottuk le az &oracle; On-Line Text Viewer felrakását. Habár Linux esetén ez nem használható, alapértelmezés szerint mégis ki van választva. Az &oracle; telepítõ menüjében tiltsuk le ezt és nélküle kezdjük újra a telepítést. <errorname>TEXTENV_INVALID</errorname> hiba az <command>R3SETUP</command>, RFC vagy SAPgui Start programokban Ha ilyen hibával kerülünk szembe, akkor hiányoznak a megfelelõ nyelvi állományok. A 0171356 &sap; füzet tartalmazza a telepítendõ RPM csomagok felsorolását (például a RedHat 6.1 esetén a saplocales-1.0-3 és saposcheck-1.0-1). Amennyiben figyelmen kívül hagyjuk az ilyen hibákat, és az R3SETUP minden kiakadásánál átírjuk (a CENTRDB.R3S állományban) az STATUS értékét az ERROR értékrõl az OK értékre és újraindítjuk, az &sap; nem állítódik be jól és nem tudunk a SAPgui alkalmazással rácsatlakozni a frissen telepített rendszerre még akkor sem, ha el tudtuk indítani. Amikor a régebbi linuxos SAPgui alkalmazással csatlakozunk, a következõ üzeneteket kapjuk: Sat May 5 14:23:14 2001 *** ERROR => no valid userarea given [trgmsgo. 0401] Sat May 5 14:23:22 2001 *** ERROR => ERROR NR 24 occured [trgmsgi. 0410] *** ERROR => Error when generating text environment. [trgmsgi. 0435] *** ERROR => function failed [trgmsgi. 0447] *** ERROR => no socket operation allowed [trxio.c 3363] Speicherzugriffsfehler Ez a viselkedés annak köszönhetõ, hogy az &sap.r3; nem képes jól összerendelni a nyelvi beállításokat, sõt, magát sem képes jól beállítani (hiányoznak némely bejegyzések az adatbázis egyes tábláiban). Az &sap;-hez úgy tudunk ilyenkor csatlakozni, ha a DEFAULT.PFL állományba felvesszük a következõ bejegyzéseket (lásd 0043288 füzet): abap/set_etct_env_at_new_mode = 0 install/collate/active = 0 rscp/TCP0B = TCP0B Majd indítsuk újra az egész &sap; rendszert. Ezután már tudunk csatlakozni hozzá, még ha az országra jellemzõ nyelvi beállítások nem is mûködnek tökéletesen. Miután korrigáltuk az ország beállításait (és felraktuk a megfelelõ nyelvi állományokat), távolítsuk el az iménti bejegyzéseket a DEFAULT.PFL állományból és indítsuk újra az &sap; rendszert. Az <errorcode>ORA-00001</errorcode> hiba Ez a hiba &os; alatt az &oracle; 8.1.7 használata során következhet be. Akkor történik, amikor az &oracle; adatbázis nem volt képes rendesen inicializálni magát és összeomlott, aminek révén szemaforokat és memóriát hagyott megosztva a rendszerben. Így az adatbázis következõ indításakor kapunk egy kövér ORA-00001 hibát. Az ipcs -a paranccsal keressük meg ezeket, majd az ipcrm segítségével pedig számoljuk fel. Az <errorcode>ORA-00445</errorcode> (a PMON háttérprogram nem indult el) hiba Ez a hiba az &oracle; 8.1.7 használatakor következhet be. Akkor kapjuk ezt a hibát, amikor prdadm felhasználóként a elindítjuk startsap szkriptet (például startsap_majestix_00). Erre gyógyír lehet, ha ehelyette az adatbázis elindításához az oraprd felhasználóval adjuk ki az svrmgrl parancsot: &prompt.user; svrmgrl SVRMGR> connect internal; SVRMGR> startup; SVRMGR> exit Az <errorcode>ORA-12546</errorcode> (A Listener indítása megfelelõ engedélyekkel) hiba Az &oracle; Listener alkalmazását oraids felhasználóként az alábbi paranccsal indítsuk el: &prompt.root; umask 0; lsnrctl start Máskülönben ORA-12546 hibát kapunk, mivel a hálózati portokhoz tartozó socketek nem rendelkeznek a megfelelõ engedélyekkel. Lásd 0072984 &sap; füzet. Az <errorcode>ORA-27102</errorcode> (Nincs elég memória) hiba Akkor fordul elõ ilyen hiba, amikor a MAXDSIZ és DFLDSIZ értékeit 1 GB-nál (1024 x 1024 x 1024-nél) nagyobbra állítottuk. Mellé még kapunk egy Linux Error 12: Cannot allocate memory hibát is. [DIPGNTAB_IND_IND] az <command>R3SETUP</command> közben Errõl alapvetõen a 0130581 számú &sap; füzet ad tájékoztatást (az R3SETUP DIPGNTAB lépése hibára fut). Az IDES telepítése során az &sap; rendszer valamiért az IDS név helyett egy üres karakterláncot használ. Ez a könyvtárak elérésében kisebb gondokat okoz, mivel az elérési útvonaluk a SID-bõl generálódik (ami ebben az esetben az IDS). Tehát a /usr/sap/IDS/SYS/... /usr/sap/IDS/DVMGS00 helyett a következõt próbálja meg elérni: /usr/sap//SYS/... /usr/sap/D00 A telepítés folytatásához létrehoztunk egy linket és egy másik könyvtárat: &prompt.root; pwd /compat/linux/usr/sap &prompt.root; ls -l total 4 drwxr-xr-x 3 idsadm sapsys 512 May 5 11:20 D00 drwxr-x--x 5 idsadm sapsys 512 May 5 11:35 IDS lrwxr-xr-x 1 root sapsys 7 May 5 11:35 SYS -> IDS/SYS drwxrwxr-x 2 idsadm sapsys 512 May 5 13:00 tmp drwxrwxr-x 11 idsadm sapsys 512 May 4 14:20 trans Észrevettük, hogy a &sap; füzetekben (0029227 és 0008401) ugyanezt a viselkedést írják le. Az &sap; 4.6C telepítésénél azonban ilyen hibával nem találkoztunk. [RFCRSWBOINI_IND_IND] az <command>R3SETUP</command> közben Az &sap; 4.6C telepítése folyamán ez a hiba csupán egy korábban bekövetkezett másik hiba utóhatása volt. Itt át kell néznünk az összes érintett naplót és ki kell javítanunk a tényleges problémát. Amennyiben a naplók átvizsgálása után csak ezt találjuk egyedüli hibának (lásd &sap; füzetek), állítsuk át (a CENTRDB.R3S állományban) a STATUS értékét az OK értékre, majd indítsuk újra az R3SETUP programot. A telepítés befejezése után hajtsuk végre az SE38 tranzakcióból az RSWBOINS riportot. A további RFCRSWBOINI és RFCRADDBDIF lépésekkel kapcsolatban lásd a 0162266 &sap; füzetet. [RFCRADDBDIF_IND_IND] az <command>R3SETUP</command> közben Itt az elõbbihez hasonló feltételek élnek: mindenképpen ellenõrizzük a naplókban, hogy a hibát nem egy korábban keletkezett hiba okozta. Ha tényleg csak az 0162266 &sap; füzetben leírtak érvényesek, akkor (a CENTRDB.R3S állományban) állítsuk a gondot okozó lépés STATUS értékét az ERROR értékrõl az OK értékre, és indítsuk újra az R3SETUP programot. A telepítés után pedig hajtsuk végre az SE38 tranzakciból az RADDBDIF riportot. A <errorcode>sigaction sig31: File size limit exceeded</errorcode> hiba Ez a disp és work &sap; programok indítása során történhet meg. Az &sap; rendszert indító startsap szkriptrõl leválva indulnak el a többi &sap; program elindításáért felelõs alfolyamatok. Ennek eredményeképpen a szkript maga nem fogja észrevenni a hibát. Az &sap; programok elindulását az ps ax | grep SID paranccsal tudjuk ellenõrizni. Az eredményül kapott listában az összes aktív &oracle; és &sap; programnak szerepelnie kell. Ha ebbõl az tûnik ki, hogy bizonyos programok hiányoznak, vagy nem képesek kapcsolódni az &sap; rendszerhez, akkor az /usr/sap/SID/DVEBMGSnr/work/ könyvtárban nézzük át a hozzájuk tartozó naplóállományokat. Elsõsorban a dev_ms és a dev_disp állományok fontosak számunkra. A 31-es jelzés akkor keletkezik, ha az &oracle; és az &sap; által használt osztott memória mértéke meghaladja a rendszermag beállításai közt megadott értéket. Ezt tehát ennek növelésével lehet orvosolni: # az éles 46C rendszereknek több kell: options SHMMAXPGS=393216 # a 46B beéri kevesebbel is: #options SHMMAXPGS=262144 A <command>saposcol</command> nem indul A saposcol (4.6D verzió) programmal akad néhány probléma. Az &sap; rendszer az saposcol segítségével próbál adatokat gyûjteni a rendszer teljesítményérõl. Mivel ez a program nem feltétlenül szükséges az &sap; rendszer mûködéséhez, ez a probléma nem tekinthetõ komolynak. A korábbi (4.6B) verziókban ugyan mûködik, de semmilyen adatot nem képes begyûjteni (mivel a legtöbb hívás, például a processzorhasználat függvénye, egyszerûen csak nullát ad vissza). Témák haladóknak Ha kíváncsiak vagyunk a Linux emuláció mûködésére, olvassuk el ezt a szakaszt. Az itt ismertettek leginkább Terry Lambert (tlambert@primenet.com) &a.chat; címére írt levele nyomán kerülnek bemutatásra (Az üzenet azonosítója: <199906020108.SAA07001@usr09.primenet.com>). Hogyan mûködik? végrehajtási osztály betöltõ A &os; rendelkezik egy ún. végrehajtási osztály betöltõvel (execution class loader). Ez lényegében a &man.execve.2; rendszerhívás alatt meghúzódó absztrakciós réteg. A &os;-nek a #! karaktersorozat hatására parancsértelmezõk vagy a hozzájuk tartozó szkriptek betöltésére utasító biztonsági betöltõ helyett van egy listája az alkalmas betöltõkrõl. A &unix; rendszerek a hagyományok szerint egyetlen betöltõvel rendelkeznek, ami elõször megvizsgálja a betölteni kívánt állomány bûvös számát (ami általában az elsõ 4 vagy 8 byte) és ez alapján eldönti, hogy az adott formátum támogatott-e. Amennyiben ez így van, meghívja a betöltõt. Ha a bináris típusa nem ismert a rendszer számára, akkor az &man.execve.2; hívás hibával tér vissza, és a parancsértelmezõ próbálja meg a saját parancsaiként értelmezni. Eddig ez volt az alapértelmezés, akármilyen parancsértelmezõnk is volt. Késõbb az &man.sh.1; kódjába bekerült egy aprócska okosítás, amivel megnézte az állomány elsõ két karakterét, és ha az :\n volt, akkor a futtatáshoz maga helyett a &man.csh.1; parancsértelmezõt hívta meg (ezt állítólag elõször a SCO csinálta). A &os; viszont végignézi a betöltõk teljes listáját, amiben a sor végén szerepel egy általános #! formátumú betöltõ. Ez az állomány futtatásához használatos értelmezõk kódját keresi, és ha egyet sem sikerül azonosítania, akkor a /bin/sh programot indítja el. ELF A Linux ABI támogatását a &os; úgy oldja meg, hogy elõször észleli az ELF bináris bûvös számát (ekkor még nem tesz különbséget a &os;, &solaris;, Linux vagy más ELF típusú binárisokat használó operációs rendszerek közt). Solaris Ezután az ELF formátum betöltõje az ELF állomány megjegyzéseket tároló szakaszában bélyegek (brand) után kutat, ami SVR4 és &solaris; ELF binárisok esetén nem létezik. A Linux binárisokat mûködésükhöz a &man.brandelf.1; segítségével Linux típusúnak kell megbélyegezni: &prompt.root; brandelf -t Linux állomány Miután ezt megcsináltuk, az ELF betöltõ észre fogja venni az állomány Linux típusát. ELF megbélyegzés Mikor az ELF betöltõ észleli, hogy az állomány Linux típusú, kicseréli egy mutató értékét a proc struktúrában. Minden rendszerhívás ezen a mutatón keresztül érhetõ el (a hagyományos &unix; rendszerekben ez a rendszerhívásokat tartalmazó sysent[] struktúratömb). Emellett a frissen elindított program szoftveres megszakításait tartalmazó tömbjéhez beállítja a speciális jelzések kezelését, valamint a Linux modul által végzett néhány további (kisebb) javítást. A Linux rendszerhívásokat tartalmazó tömb többek közt tartalmazza a sysent[] bejegyzések egy listáját, amelyek címei a rendszermag Linux moduljára mutatnak. Amikor a Linux bináris hív egy rendszerhívást, a hozzátartozó szoftveres megszakítás kódja a proc struktúrából a neki megfelelõ rendszerhívás kódját hivatkozza, így &os; rendszerhívás belépési pontja helyett a Linuxét kapja meg. Ráadásul Linux módban a különbözõ állományok hivatkozásai is átirányítódnak. Ez lényegében olyan, mint amit az állományrendszerek csatlakoztatásánál a beállítás csinál (ami nem egyezik meg az unionfs állományrendszerrel!). Ilyenkor az állományokat elõször a /compat/linux/eredeti-hely könyvtárában keresi, és majd ha ott nem találja, csak akkor kezdi el keresni az /eredeti-hely ponton. Ezzel oldhatjuk meg, hogy más binárisok futtatását igénylõ binárisok is képesek legyenek rendesen mûködni (például így az egész linuxos eszköztár tud futni a Linux ABI-n keresztül). Egyúttal arra is utal, hogy ha a Linux binárisok számára nem áll rendelkezésre a megfelelõ bináris, akkor &os; binárisokat is el tudnak indítani. Ha a &man.uname.1; programot pedig bemásoljuk a /compat/linux könyvtáron belülre, akkor a Linux binárisok képtelenek lesznek megmondani, hogy nem Linux alatt futnak. Így lényegében egy Linux magot találunk a &os; rendszermagjában. A benne megtalálható különbözõ szolgáltatásokat megvalósító függvények: az állománymûveletek, a virtuális memória kezelése, a jelzések küldése és System V típusú folyamatok közti kommunikáció stb. megegyeznek a &os; és a Linux hívásai esetén egyaránt. Egyetlen eltérés, hogy a &os; binárisok a &os; segédfüggvényein (glue function), a Linux binárisok pedig a Linux segédfüggvényein keresztül férnek hozzájuk (a legelsõ operációs rendszerek tulajdonképpen csak a saját segédfüggvényeiket tartalmazták: a hívást kezdeményezõ program proc struktúrájában a függvények dinamikusan beállított címe helyett egy globális sysent[] struktúratömbben tárolták a meghívható függvényeket). Melyik közülük a &os; natív ABI-ja? Ez teljesen lényegtelen. Alapvetõen az egyetlen különbség csupán annyi (pillanatnyilag, de ez a jövõben még változhat, valószínûleg hamarosan), hogy a &os; segédfüggvényei statikusan megtalálhatóak a rendszermagban, míg a Linux segédfüggvényei egyaránt elérhetõek modulból vagy statikus linkeléssel. Na igen, de akkor ez most emuláció? Nem. Ez egy ABI, nem emuláció. Itt szó sincs emulátorról (ahogy szimulátorról sincs). De akkor mégis miért hívják ezt sokszor Linux emulációnak? Hát hogy nehezebb legyen eladni a &os;-t! Komolyra fordítva a szót: ennek a kezdeti változata akkoriban született meg, amikor erre még nem volt rendes szó. Nem mondhattuk, hogy a &os; befordítás vagy egy modul betöltése nélkül képes lett volna Linux binárisokat futtatni, ezért valamilyen módon meg kellett neveznünk az ilyenkor betöltött kódot — ebbõl lett a Linux emulátor. diff --git a/hu_HU.ISO8859-2/books/handbook/virtualization/chapter.sgml b/hu_HU.ISO8859-2/books/handbook/virtualization/chapter.sgml index 3f55f0d9cc..8681f35e17 100644 --- a/hu_HU.ISO8859-2/books/handbook/virtualization/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/virtualization/chapter.sgml @@ -1,1393 +1,1391 @@ Murray Stokely Írta: Virtualizáció Áttekintés A virtualizációs szoftverek lehetõvé teszik, hogy ugyanazon a számítógépen egyszerre több operációs rendszert is futassunk. Ezeknek a programcsomagoknak gyakorta részük egy gazda operációs rendszer is, amely a virtualizációs szoftvert futattja és ismer bizonyos vendég operációs rendszereket. A fejezet elolvasása során megismerjük: a gazda- és a vendég operációs rendszerek közti különbségeket; hogyan telepítsünk &os;-t egy &intel;-alapú &apple; &macintosh; számítógépre; hogyan telepítsünk a &xen; használatával &os;-t &linux;-ra; hogyan telepítsünk a Virtual PC használatával &os;-t µsoft.windows;-ra; hogyan hozzuk ki a legtöbbet &os; rendszerünkbõl virtualizáció alatt. A fejezet elolvasásához ajánlott: alapvetõ &unix;-os és &os;-s ismeretek (); a &os; telepítésének ismerete (); a hálózati kapcsolatok beállításának ismerete (); külsõs alkalmazások telepítésének ismerete (). A &os; mint vendég Parallelsszel &macos;-en A Parallels Desktop a &macos; 10.4.6, vagy afeletti verzióját futattó, &intel;-alapú &apple; &mac; személyi számítógépekre fejlesztett kereskedelmi alkalmazás. A &os;-t teljes mértékben támogatja vendégként. Miután telepítettük a Parallels-t a &macos; X-re, be kell állítanunk egy virtuális gépet, majd erre felraknunk a kívánt vendég operációs rendszert. A &os; telepítése &macos; X/Parallelsre A &os; &macos; X/Parallels párosra telepítéséhez elsõ lépésként készítenünk kell egy új virtuális számítógépet. A létrehozás során válasszuk a Guest OS Type-nak (a vendég operációs rendszer típusának) a &os;-t: Ezután adjunk meg egy nagyjából elfogadható méretet a virtuális merevlemezünknek, valamint annyi memóriát, amennyire szükségünk lehet a virtuális &os;-nk használata során. Egy 4 GB-os lemez és 512 MB rendszermemória a legtöbb esetben jó választásnak bizonyulhat a &os; Parallels alatti használata során: Válasszuk ki a hálózatkezelés típusát és a hálózati csatolót. Mentsük el és fejezzük be a konfigurálást. Miután a &os;-s virtuális gépünk elkészült, telepítenünk kell rá magát az operációs rendszert is. Ezt a legegyszerûbben a hivatalosan &os; telepítõ CD-rõl, vagy a hivatalos FTP oldalról letölthetõ CD-képpel tehetjük meg. Ha lemásoltuk a megfelelõ CD-képet a &mac; helyi állományrendszerére, vagy behelyeztük a telepítõ CD-t a CD-meghajtóba, kattintsunk a &os;-s Parallels ablakunk jobb alsó sarkában található lemez ikonjára. Ekkor feljön egy párbeszédablak, ahol összerendelhetjük a virtuális gépünk CD-meghajtóját egy lemezen található képpel, vagy éppen a valódi CD-meghajtónkkal. Ahogy megtettük az imént említett összerendelést, indítsuk is újra a &os;-s virtuális gépünket a megszokott módon, az újraindítás ikonjára kattintva. Ekkor a rendszer megtalálja a &os; telepítõlemezt és a sysinstall segítségével megkezdi a telepítést a ben leírtak szerint. Ha szükségünk van rá, telepíthetjük az X11-et is, de egyelõre még ne próbáljuk beállítani. A telepítés befejezését követõen indítsuk újra a frissen telepített &os;-s virtuális gépünket. A &os; beállítása &macos; X/Parallelsen Miután telepítettük a &os;-t &macos; X/Parallels-re, még vár ránk néhány konfigurációs lépés a rendszer virtuálizált mûködésének optimalizálása érdekében. A rendszerbetöltõ változóinak beállítása A legfontosabb lépés a változó értékének csökkentése, amivel így a &os; processzor-kihasználtságát is csökkentjük a Parallels alatt. Ezt a következõ sor hozzadásával tehetjük meg a /boot/loader.conf állományban: kern.hz=100 Enélkül egy üresjáratban levõ &os; Parallels-vendég az &imac; egy processzorának durván 15%-át foglalja le. A változtatás életbe léptetése után azonban ez megközelítõen 5%-ra redukálható. Egy új konfigurációs állomány létrehozása a rendszermaghoz Nyugodtan eltávolíthatjuk az összes SCSI, FireWire és USB eszközmeghajtót. A Parallels által felkínált virtuális hálózati csatolót az &man.ed.4; meghajtón keresztül tudjuk elérni, ezért az &man.ed.4; és &man.miibus.4; meghajtókon kívül az összes többi elhagyható. A hálózati kapcsolat beállítása Az alapvetõ hálózati beállítás a virtuális gépünkön a DHCP aktiválása, aminek segítségével csatlakozni tudunk arra a helyi hálózatra, amelyen maga a gazda &mac; is megtalálható. Ezt az alábbi sor felvételével tudjuk megoldani az /etc/rc.conf állományba: ifconfig_ed0="DHCP". Bõvebb információkért járuljunk a fejezethez. Fukang Chen (Loader) Írta: &xen;nel &linux;-on A &xen; hipervisor egy nyílt forráskódú, paravirtualizációt nyújtó termék, amely mögött mostanra már a XenSource kereskedelmi cég áll. Itt a vendég operációs rendszereket a domU tartományként azonosítják, míg a gazda operációs rendszer a dom0. A &os; &linux; alatti virtuális futattásához elsõként telepítenünk kell a &xen;-t egy dom0-ás Linuxra. A leírásban a gazda operációs rendszer a Slackware &linux; disztribúció lesz. A &xen; 3 beállítása egy &linux; dom0-án Töltsük le a &xen; 3.0-át a XenSource-tól Töltsük le a xen-3.0.4_1-src.tgz állományt a XenSource oldaláról. Bontsuk ki a csomagot &prompt.root; cd xen-3.0.4_1-src &prompt.root; KERNELS="linux-2.6-xen0 linux-2.6-xenU" make world &prompt.root; make install A rendszermagot így tudjuk dom0 módban újrafordítani: &prompt.root; cd xen-3.0.4_1-src/linux-2.6.16.33-xen0 &prompt.root; make menuconfig &prompt.root; make &prompt.root; make install A &xen; régebbi verzióinál elképzelhetõ, hogy így kell megadni: make ARCH=xen menuconfig. Vegyük fel a megfelelõ pontot a GRUB menüjébe Nyissuk meg a /boot/grub/menu.lst állományt és írjuk be a következõ sort: title Xen-3.0.4 root (hd0,0) kernel /boot/xen-3.0.4-1.gz dom0_mem=262144 module /boot/vmlinuz-2.6.16.33-xen0 root=/dev/hda1 ro Indítsuk újra a gépet és aktiváljuk a &xen;t Elõször nyissuk meg az /etc/xen/xend-config.sxp állományt, majd adjuk hozzá a következõ sort: (network-script 'network-bridge netdev=eth0') Ezután el is indíthatjuk a &xen;t: &prompt.root; /etc/init.d/xend start &prompt.root; /etc/init.d/xendomains start Láthatjuk, hogy a dom0 tartomány most már aktív: &prompt.root; xm list Name ID Mem VCPUs State Time(s) Domain-0 0 256 1 r----- 54452.9 A &os; 7-CURRENT mint domU Töltsük le a &os; &xen; 3.0-ás domU rendszermagját és a hozzátartozó lemezképet a http://www.fsmware.com/ címrõl: kernel-current mdroot-7.0.bz2 xmexample1.bsd Tegyük a xmexample1.bsd konfigurációs állományt a /etc/xen/ könyvtárba és írjuk át a releváns bejegyzéseket a rendszermag és a lemezkép elérési útjának megfelelõen. Valahogy így kellene kinézni az eredménynek: kernel = "/opt/kernel-current" memory = 256 name = "freebsd" vif = [ '' ] disk = [ 'file:/opt/mdroot-7.0,hda1,w' ] #on_crash = 'preserve' extra = "boot_verbose" extra += ",boot_single" extra += ",kern.hz=100" extra += ",vfs.root.mountfrom=ufs:/dev/xbd769a" Az mdroot-7.0.bz2 állományt ki kell tömöríteni! Ezután a kernel-current állományban található __xen_guest részt át kell írni úgy, hogy hozzáadjuk a &xen; 3.0.3 számára fontos VIRT_BASE értéket: &prompt.root; objcopy kernel-current -R __xen_guest &prompt.root; perl -e 'print "LOADER=generic,GUEST_OS=freebsd,GUEST_VER=7.0,XEN_VER=xen-3.0,BSD_SYMTAB,VIRT_BASE=0xC0000000\x00"' > tmp &prompt.root; objcopy kernel-current --add-section __xen_guest=tmp &prompt.root; objdump -j __xen_guest -s kernel-current kernel-current: file format elf32-i386 Contents of section __xen_guest: 0000 4c4f4144 45523d67 656e6572 69632c47 LOADER=generic,G 0010 55455354 5f4f533d 66726565 6273642c UEST_OS=freebsd, 0020 47554553 545f5645 523d372e 302c5845 GUEST_VER=7.0,XE 0030 4e5f5645 523d7865 6e2d332e 302c4253 N_VER=xen-3.0,BS 0040 445f5359 4d544142 2c564952 545f4241 D_SYMTAB,VIRT_BA 0050 53453d30 78433030 30303030 3000 SE=0xC0000000. Most már készen állunk a domU létrehozására és beindítására: &prompt.root; xm create /etc/xen/xmexample1.bsd -c Using config file "/etc/xen/xmexample1.bsd". Started domain freebsd WARNING: loader(8) metadata is missing! Copyright (c) 1992-2006 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 7.0-CURRENT #113: Wed Jan 4 06:25:43 UTC 2006 kmacy@freebsd7.gateway.2wire.net:/usr/home/kmacy/p4/freebsd7_xen3/src/sys/i386-xen/compile/XENCONF WARNING: DIAGNOSTIC option enabled, expect reduced performance. Xen reported: 1796.927 MHz processor. Timecounter "ixen" frequency 1796927000 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 1.80GHz (1796.93-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH, DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> Features2=0x4400<CNTX-ID,<b14>> real memory = 265244672 (252 MB) avail memory = 255963136 (244 MB) xc0: <Xen Console> on motherboard cpu0 on motherboard Timecounters tick every 10.000 msec [XEN] Initialising virtual ethernet driver. xn0: Ethernet address: 00:16:3e:6b:de:3a [XEN] Trying to mount root from ufs:/dev/xbd769a WARNING: / was not properly dismounted Loading configuration files. No suitable dump device was found. Entropy harvesting: interrupts ethernet point_to_point kickstart. Starting file system checks: /dev/xbd769a: 18859 files, 140370 used, 113473 free (10769 frags, 12838 blocks, 4.2% fragmentation) Setting hostname: demo.freebsd.org. lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet 127.0.0.1 netmask 0xff000000 Additional routing options:. Mounting NFS file systems:. Starting syslogd. /etc/rc: WARNING: Dump device does not exist. Savecore not run. ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/X11R6/lib /usr/local/lib a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout /usr/X11R6/lib/aout Starting usbd. usb: Kernel module not available: No such file or directory Starting local daemons:. Updating motd. Starting sshd. Initial i386 initialization:. Additional ABI support: linux. Starting cron. Local package initialization:. Additional TCP options:. Starting background file system checks in 60 seconds. Sun Apr 1 02:11:43 UTC 2007 FreeBSD/i386 (demo.freebsd.org) (xc0) login: A domU-ban a &os; 7.0-CURRENT rendszermagnak kell futnia: &prompt.root; uname -a FreeBSD demo.freebsd.org 7.0-CURRENT FreeBSD 7.0-CURRENT #113: Wed Jan 4 06:25:43 UTC 2006 kmacy@freebsd7.gateway.2wire.net:/usr/home/kmacy/p4/freebsd7_xen3/src/sys/i386-xen/compile/XENCONF i386 Miután errõl megbizonyosodtunk, be tudjuk állítani a hálózatot is domU-ban. A domU &os; egy xn0 nevû speciális eszközt használ erre a célra: &prompt.root; ifconfig xn0 10.10.10.200 netmask 255.0.0.0 &prompt.root; ifconfig xn0: flags=843<UP,BROADCAST,RUNNING,SIMPLEX> mtu 1500 inet 10.10.10.200 netmask 0xff000000 broadcast 10.255.255.255 ether 00:16:3e:6b:de:3a lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet 127.0.0.1 netmask 0xff000000 Eközben a dom0 Slackware-en néhány &xen;-függõ hálózati csatolónak is meg kell jelennie: &prompt.root; ifconfig eth0 Link encap:Ethernet HWaddr 00:07:E9:A0:02:C2 inet addr:10.10.10.130 Bcast:0.0.0.0 Mask:255.0.0.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:815 errors:0 dropped:0 overruns:0 frame:0 TX packets:1400 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:204857 (200.0 KiB) TX bytes:129915 (126.8 KiB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:99 errors:0 dropped:0 overruns:0 frame:0 TX packets:99 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:9744 (9.5 KiB) TX bytes:9744 (9.5 KiB) peth0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF UP BROADCAST RUNNING NOARP MTU:1500 Metric:1 RX packets:1853349 errors:0 dropped:0 overruns:0 frame:0 TX packets:952923 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2432115831 (2.2 GiB) TX bytes:86528526 (82.5 MiB) Base address:0xc000 Memory:ef020000-ef040000 vif0.1 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF UP BROADCAST RUNNING NOARP MTU:1500 Metric:1 RX packets:1400 errors:0 dropped:0 overruns:0 frame:0 TX packets:815 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:129915 (126.8 KiB) TX bytes:204857 (200.0 KiB) vif1.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF UP BROADCAST RUNNING NOARP MTU:1500 Metric:1 RX packets:3 errors:0 dropped:0 overruns:0 frame:0 TX packets:2 errors:0 dropped:157 overruns:0 carrier:0 collisions:0 txqueuelen:1 RX bytes:140 (140.0 b) TX bytes:158 (158.0 b) xenbr1 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF UP BROADCAST RUNNING NOARP MTU:1500 Metric:1 RX packets:4 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:112 (112.0 b) TX bytes:0 (0.0 b) &prompt.root; brctl show bridge name bridge id STP enabled interfaces xenbr1 8000.feffffffffff no vif0.1 peth0 vif1.0 Virtual PC-vel &windows;-on A &windows;-ra fejlesztett Virtual PC a µsoft; egyik szabadon letölthetõ szoftverterméke. A rendszerkövetelményeit bõvebben lásd a linken. Miután telepítettük a µsoft.windows;-ra a Virtual PC alkalmazást, be kell állítanunk egy virtuális gépet, majd telepítenünk kell rá a kívánt vendég operációs rendszert. A &os; telepítése Virtual PC/µsoft.windows;-ra Amikor a &os;-t a µsoft.windows; és Virtual PC párosra akarjuk telepíteni, akkor kezdjünk egy egy új virtuális gép létrehozásával. Ehhez válasszuk ki a menübõl a Create a virtual machine (Virtuális gép létrehozása) pontot. Majd válasszuk az Operating system (Operációs rendszer) beállításánál az Other (Egyéb) opciót. Ezután válasszuk ki a szándékainknak megfelelõen a telepítendõ &os; példányhoz mért memória és lemezterület mennyiségét. Ahhoz, hogy a &os; fusson Virtual PC alatt, 4 GB-nyi lemezterület és 512 MB RAM beállítása a legtöbb esetben kiválóan megfelelõ. Mentsük el és fejezzük be a konfigurációt. Válasszuk ki a &os;-s virtuális gépünket, majd kattintsunk a Settings (Beállítások) menüre és állítsuk be hálózati csatoló és hálózatkezelés típusát. A &os;-nek otthont adó virtuális gépünk létrehozása után telepítenünk is kell rá a rendszert. Ez legegyszerûbben a hivatalos &os; telepítõ CD-vel vagy a hivatalos FTP oldalról letölthetõ CD-képpel tehetjük meg. Amikor letöltöttük a megfelelõ CD-képet a helyi &windows;-os állományrendszerünkre vagy behelyeztük a telepítéshez használható CD-t a CD-meghajtónkba, a &os;-s virtuális gépünk elindításához kattintsunk rá duplán. Ezt követõen a Virtual PC ablakában kattintsunk a CD menüre és válasszuk ki belõle a Capture ISO Image... (Lemezkép használata...) pontot. Ennek hatására megjelenik egy ablak, amiben a virtuális gépünk CD-meghajtóihoz tudunk csatlakoztatni lemezképeket vagy akár létezõ CD-meghajtókat. Miután sikeresen beállítottuk a telepítõ CD forrását, indítsuk újra a virtuális gépet az Action (Mûvelet) menün belül a Reset (Újraindítás) pont kiválasztásával. Így a Virtual PC újraindítja a virtuális rendszert egy olyan speciális BIOS használatával, amely a normális BIOS-hoz hasonlóan elõször megkeresi az elérhetõ CD-meghajtókat. Ebben az esetben a &os; telepítõeszközét fogja megtalálni és megkezdi a ben ismertetett szokásos, sysinstall programra alapuló telepítési eljárást. Ennek során az X11-et is feltelepíthetjük, habár egyelõre még ne állítsuk be. Ne felejtsük el kivenni a meghajtóból a telepítéshez használt CD-t vagy elengedni a megfelelõ lemezképet, amikor befejezõdõtt a telepítés. Végezetül indítsuk ismét újra a frissen telepített &os;-s virtuális gépünket. A &os; beállítása a µsoft.windows;/Virtual PC-n Miután a &os;-t minden gond nélkül telepítettük a µsoft.windows;-on futó Virtual PC-re, még további beállítási lépéseket is meg kell tennünk a rendszer virtualizált mûködésének finomhangolásához. A rendszertöltõ változóinak beállítása A legfontosabb teendõnk csökkenteni a konfigurációs beállítás értéket, aminek köszönhetõen vissza tudjuk fogni a Virtual PC alatt futó &os; processzorhasználatát. Ezt úgy tudjuk megtenni, ha a /boot/loader.conf állományba felvesszük a következõ sort: kern.hz=100 Enélkül a Virtual PC alatt üresjáratban futó &os; vendég operációs rendszer egy egyprocesszoros számítógép idejének durván 40%-át foglalja le. A változtatás után azonban ez az érték pusztán közel 3%-ra csökken le. Új konfigurációs állomány létrehozása a rendszermaghoz Nyugodtan eltávolíthatjuk a SCSI, FireWire és USB eszközmeghajtókat. A Virtual PC által felajánlott virtuális hálózati csatolót a &man.de.4; meghajtón keresztül tudjuk használni, ezért a &man.de.4; és &man.miibus.4; eszközön kívül az összes többi hálózati eszköz támogatása kiszedhetõ a rendszermagból. A hálózati kapcsolat beállítása A legalapvetõbb hálózati beállítás csupán annyiból áll, hogy DHCP-n keresztül csatlakoztatjuk a virtuális gépünket ugyanahhoz a helyi hálózathoz, amiben a gazda µsoft.windows;-os gépünk is megtalálható. Ezt úgy tudjuk elérni, ha a /etc/rc.conf állományba megadjuk a ifconfig_de0="DHCP" sort. A komolyabb hálózati beállításokat a ben találhatjuk. VMware-rel MacOS-en A &mac;-ek számára fejlesztett VMWare Fusion egy olyan kereskedelmi termék, amit az &intel; alapú &apple; &mac; gépekre tudunk telepíteni a &macos; 10.4.9 és késõbbi változatain. A &os; itt egy teljesen támogatott vendég operációs rendszer. Miután a VMWare Fusion felkerült a &macos; X rendszerünkre, be kell állítanunk a virtuális gépet és telepítenünk rá a vendég operációs rendszert. A &os; telepítése a &macos; X/VMWare-re Elõször indítsuk el a VMWare Fusion-t, aminek eredményeképpen betöltõdik a Virtual Machine Library. Egy új virtuális gépre létrehozásához kattintsunk a "New" gombra: Ekkor bejön az új gép összeállítását segítõ New Virtual Machine Assistant, ahol a továbblépéshez kattintsunk a Continue gombra: Az operációs rendszerek (Operating System) közül válasszuk az egyéb (Other) kategóriát, majd a Version fülön a FreeBSD vagy a FreeBSD 64-bit változatot attól függõen, hogy 32 bites vagy 64 bites támogatásra van szükségünk: Adjuk meg a virtuális gép képének nevét és a könyvtárat, ahova el akarjuk menteni: Válasszuk meg a virtuális géphez tartozó virtuális merevlemez méretét is: Mondjuk meg, hogy milyen módon szeretnénk telepíteni a virtuális gépre, ISO formátumú lemezképrõl vagy CD-rõl: Ahogy a Finish feliratú gombra kattintunk, a virtuális gép máris elindul: Telepítsük fel a &os;-t a megszokott módon vagy a utasításai mentén: Miután befejezõdött a telepítés, módosítsuk a virtuális gép beállításait, például a memória mennyiségét: A virtuális gép hardveres beállításai a futása alatt nem változtathatóak meg. A virtuális gép által használható processzorok számát: A CD-meghajtó állapotát. Általában lehetõségünk van a virtuális gépet leválasztani a CD-meghajtóról vagy ISO lemezképrõl, ha már nem használjuk. A hálózati csatlakozás a virtuális géppel kapcsolatban utolsóként beállítandó tényezõ. Ha a befogadó gépen kívül még más gépeket is el akarunk érni a virtuális géprõl, akkor ehhez mindenképpen a Connect directly to the physical network (Bridged) opciót válasszuk. Minden más esetben a Share the host's internet connection (NAT) az ajánlott, mivel így a virtuális gép eléri az internetet, de a hálózatról nem lehet azt elérni. Miután befejeztük a beállítások finomhangolását, indítsuk is el a frissen telepített &os;-s virtuális gépünket. A &os; beállítása a &macos; X/VMWare-en Ahogy a &os;-t sikeresen telepítettük a &macos; X alatt futó VMWare-re, néhány konfigurációs lépést még meg kell tennünk a virtualizált rendszer teljesítmények optimalizálása érdekében. A rendszertöltõ változóinak beállítása A legfontosabb lépés talán a változó értékének csökkentése, amivel a VMWare alatt futó &os; processzorhasználatát szoríthatjuk vissza. Ezt a következõ sor hozzáadásával érhetjük el a /boot/loader.conf állományban: kern.hz=100 Enélkül az üresjáratban zakatoló &os;-s VMWare vendég nagyjából az &imac; egyik processzorának 15%-át emészti fel. Ezzel a módosítással azonban ez lenyomható közel 5%-ra. Új konfigurációs állomány létrehozása a rendszermaghoz Nyugodtan törölhetjük az összes FireWire és USB eszköz meghajtóját. A VMWare egy &man.em.4; meghajtón keresztül elérhetõ virtuális hálózati kártyát biztosít, így az &man.em.4; kivételével az összes hálózati eszköz meghajtóját kivehetjük a rendszermagból. A hálózat beállítása A legegyszerûbb hálózati beállítás mindösszesen a DHCP használatát igényli, aminek révén a virtuális gépünk a befogadó &mac;-kel egy helyi hálózatra kerül. Ezt úgy tudjuk engedélyezni, ha az /etc/rc.conf állományba felvesszük az ifconfig_em0="DHCP" sort. Ha ennél komolyabb hálózati beállítások is érdekelnek minket, akkor olvassuk el a et. A &os; mint gazda Gazda operációs rendszerként a &os; évekig nem kapott hivatalosan támogatást egyetlen elterjedtebb virtualizációs megoldás részérõl sem. Sokan erre a célra eddig a VMware korábbi és inkább már elavult, a &linux; kompatibilitási rétegre épülõ változatait (mint például emulators/vmware3) használták. Nem sokkal azonban a &os; 7.2 megjelenése után a Sun &virtualbox; OSE (Open Source Edition) natív &os; alkalmazásként bukkant fel a Portgyûjteményben. A &virtualbox; egy folyamatos fejlesztés alatt álló, komplett virtualizációs csomag, amely immáron elérhetõ a legtöbb népszerû operációs rendszerre, mint a &windows;, &macos;, &linux; és a &os;. Egyaránt képes &windows; és &unix; fajtájú vendégrendszerek futattására. Nyílt- és zárt forráskódú változatban is elérhetõ. A felhasználók szempontjából a kettõ közti talán legfontosabb eltérés, hogy a nyílt forráskódú változat nem tartalmaz USB támogatást. A különbségek teljes listája megtalálható a &virtualbox; wiki Editions oldalán, a címen. &os; alatt jelenleg csak a nyílt forráskódú változat érhetõ el. A <application>&virtualbox;</application> telepítése A &virtualbox; a emulators/virtualbox könyvtárból érhetõ el portként, és onnan a következõ parancsokkal telepíthetõ: &prompt.root; cd /usr/ports/emulators/virtualbox &prompt.root; make install clean A beállítások közt az egyik leghasznosabb a GuestAdditions nevû programcsomag telepítése. A benne található programokon keresztül a vendégként futó operációs rendszer számos hasznos szolgáltatását el tudjuk érni, úgy mint az egérmutató integrációját (ekkor az egérkurzor zökkenõmentesen használható a gazda és a vendég rendszerben is) vagy a videomemória gyorsabb elérését (különösen &windows; esetében). A vendégekhez telepíthetõ ilyen jellegû kiegészítések az adott rendszer telepítése után a Devices menübõl érhetõek el. A &virtualbox; elsõ indítása elõtt el kell még végeznünk néhány további beállítást. Fontos tudnunk, hogy a port a telepítés során a /boot/modules könyvtárba tesz még egy rendszermagmodult is, amelyet még külön be kell töltenünk: &prompt.root; kldload vboxdrv Ehhez még vegyük fel a következõ sort a /boot/loader.conf állományba, így a modul a rendszer minden egyes indításakor magától betöltõdik: vboxdrv_load="YES" A &virtualbox; ezenkívül még igényli a proc állományrendszer csatlakoztatását is: &prompt.root; mount -t procfs proc /proc Ha hozzáadjuk az alábbi sort a /etc/fstab állományhoz, akkor ez a beállítás is megmarad a rendszer újraindítása után: proc /proc procfs rw 0 0 Nagyon valószínû, hogy proc állományrendszerrel van gondunk, amikor a következõ hibaüzenetet kapjuk a &virtualbox; indításakor: VirtualBox: supR3HardenedExecDir: couldn't read "", errno=2 cchLink=-1 Ilyenkor a mount parancs kiadásával ellenõrizzük az állományrendszer sikeres csatlakoztatását. A &virtualbox; telepítése során keletkezik még egy vboxusers nevû csoport. Ide azokat a felhasználókat vegyük fel, akik részére szeretnénk engedélyezni a &virtualbox; használatát. A csoportba új tagokat például a pw paranccsal tudunk felvenni: &prompt.root; pw groupmod vboxusers -m felhasználónév Ezek után a &virtualbox; indításához válasszuk a grafikus környezetünk menüjében található Sun VirtualBox menüpontot, vagy egy terminálban gépeljük be ezt a parancsot: &prompt.user; VirtualBox A &virtualbox; beállításának további lehetõségeirõl a címen elérhetõ hivatalos holnapon olvashatunk. Tekintettel arra, hogy a &os; port még viszonylag friss és folyamatos fejlesztés alatt áll, ehhez még érdemes átolvasnunk a &os; wikiben szereplõ oldalt is, ahol a vele kapcsolatos legfrissebb információkat és egyéb tudnivalókat találhatjuk. Egyéb virtualizációs lehetõségek A &os; &xen; - gazdarendszerként is hamarosan elérhetõ lesz, a - &os; 8.0 kiadása már kísérleti - jelleggel tartalmazni fogja egy változatát. + gazdarendszerként is hamarosan elérhetõ lesz.