diff --git a/hu_HU.ISO8859-2/articles/cups/article.sgml b/hu_HU.ISO8859-2/articles/cups/article.sgml index 22b178cd8c..4e63b90154 100644 --- a/hu_HU.ISO8859-2/articles/cups/article.sgml +++ b/hu_HU.ISO8859-2/articles/cups/article.sgml @@ -1,517 +1,534 @@ %articles.ent; ]>
A CUPS használata &os; rendszereken $FreeBSD$ Chess Griffin
chess@chessgriffin.com
 &tm-attrib.freebsd; &tm-attrib.general; Ez a cikk a CUPS beállítását és használatát mutatja be a &os; operációs rendszeren. Fordította: &a.hu.pgj; A Common Unix Printing System (CUPS) rövid bemutatása nyomtatás CUPS A CUPS, avagy Common UNIX Printing System (Egységes UNIX Nyomtatási Rendszer) a &unix; alapú operációs rendszerekhez fejlesztett hordozható nyomtatási réteg. Az Easy Software Products egy szabványos nyomtatási technológiaként alkotta meg a &unix; gyártók és felhasználók számára. A CUPS az ún. Internet Printing Protocol (IPP, Internetes Nyomtatási Protokoll) megoldásaira támaszkodóan kezeli a nyomtatási feladatokat és sorokat. Emellett még a Line Printer Daemon (LPD), a Server Message Block (SMB) és AppSocket (vagy más néven JetDirect) protokollokat is ismeri valamennyire. A CUPS a hétköznapi igényeknek megfelelõ &unix; alapú nyomtatás megteremtéséhez ezenkívül még támogatja a hálózati nyomtatók böngészésének lehetõségét, illetve a PostScript Printer Description (PPD, PostScript Nyomtató Leírás) használatát. Ennek eredményeképpen a CUPS tökéletesen alkalmas nyomtatók megosztására és elérésére &os;, &linux; &macos; X vagy &windows; típusú rendszereket vegyesen tartalmazó környezetekben. A CUPS hivatalos oldala a címen érhetõ el. A CUPS nyomtatószerver telepítése A CUPS telepíthetõ portként vagy csomagként. Ha portként szeretnénk telepíteni, akkor ahhoz a következõ parancsot kell kiadnunk rendszergazdaként: &prompt.root; cd /usr/ports/print/cups && make install clean A CUPS csomagjának telepítését pedig ezzel a paranccsal tudjuk (szintén rendszergazdaként) elvégezni: &prompt.root; pkg_add -r cups További nem kötelezõen telepítendõ, de határozottan ajánlott csomagok még a print/gutenprint-cups és a print/hplip, amelyek különbözõ típusú nyomtatókhoz tartalmaznak meghajtókat és segédprogramokat. A CUPS telepítése után a hozzá tartozó konfigurációs állományokat a /usr/local/etc/cups könyvtárban találhatjuk. A CUPS nyomtatószerver beállítása A CUPS szerver telepítése után néhány állomány módosításával végezhetjük el a szükséges beállításokat. Elõször is hozzunk létre (ha még nem létezne) vagy nyissuk meg az /etc/devfs.rules állományt és a cups csoport számára adjunk hozzáférést a rendszerünkben található összes nyomtatóra: [system=10] add path 'unlpt*' mode 0660 group cups add path 'ulpt*' mode 0660 group cups -add path 'lpt*' mode 0660 group cups +add path 'lpt*' mode 0660 group cups +add path 'usb/X.Y.Z' mode 0660 group cups + + + Az X, + Y és + Z helyén a nyomtató + /dev/usb + könyvtárban szereplõ értékeit + adjuk meg. A nyomtatóhoz tartozó + eszközleírót a &man.dmesg.8; + kimenetében találjuk meg + ugenX.Y + néven, amely egy szimbolikus link a /dev/usb + könyvtárban található + megfelelõjére. + Ezután az /etc/rc.conf állományba még vegyük fel a következõ két sort: cupsd_enable="YES" devfs_system_ruleset="system" Az iménti bejegyzések gondoskodnak a CUPS nyomtatószerver beüzemelésérõl a rendszer indítása során, illetve töltik be az elõbbi lépésben létrehozott helyi devfs szabályokat. Bizonyos µsoft.windows; rendszert használó kliensekkel csak akkor fogunk tudni nyomtatni a CUPS esetében, ha a /usr/local/etc/cups/mime.types és /usr/local/etc/cups/mime.convs állományokban kivesszük a megjegyzésbõl ezt a sort: application/octet-stream Miután végrehajtottuk ezeket a módosításokat, az alábbi parancsok használatával vagy az operációs rendszerrel együtt indítsuk újra a &man.devfs.8; és CUPS szolgáltatásokat: &prompt.root; /etc/rc.d/devfs restart &prompt.root; /usr/local/etc/rc.d/cupsd restart Nyomtatók beállítása a CUPS nyomtatószerveréhez A CUPS sikeres telepítését és beállítását követõen elkezdhetjük a nyomtatószerverhez kapcsolódó helyi nyomtatók hozzáadását. Ez nagyon hasonló, ha nem is teljesen megegyezõ más &unix; alapú rendszerek, például &linux; esetén a nyomtatók beállításához. A CUPS szerver irányítása és mûködtetése elsõsorban az általa felkínált webes felületen történik, amelyet a címen keresztül tudunk elérni. Amennyiben a CUPS egy másik számítógépen fut, akkor a címben természetesen a localhost (saját gépünk) helyén az adott gép IP-címét kell megadnunk. A CUPS webes felületén meglehetõsen könnyen lehet tájékozódni, külön menüket találunk a nyomtatók és nyomtatási sorok beállítására, a felhasználók hitelesítésére és a többi. Ezeken felül még az Administration képernyõ jobb oldalán különbözõ jelölõnégyzetekkel tudunk egyszerûen dönteni a gyakori beállításokról, például a szerverhez csatlakozó nyomtatókat megosztjuk-e a hálózaton keresztül, engedünk-e további felhasználókat hozzáférni a szolgáltatásokhoz, kinek milyen engédelyei legyenek a nyomtatókra és nyomtatási sorokra. A nyomtatók hozzáadásához elegendõ a CUPS webes felületén az Administration menün belül az Add Printer gombra vagy valamelyik New Printers Found gombra kattintani. A Device legördülõ menü megjelenése után egyszerûen válasszuk ki belõle a megfelelõ helyileg csatlakoztatott nyomtatót, majd folytassuk a telepítését. Ha telepítettük a korábban ajánlott print/gutenprint-cups és print/hplip programokat, akkor ennek során a hozzájuk tartozó meghajtók is meg fognak jelenni, amelyek esetleg többet tudnak vagy megbízhatóbbak. A CUPS kliensek beállítása A CUPS szerver beállítása, illetve a nyomtatók telepítése és megosztása után a kliensek, vagyis a CUPS által kínált szolgáltatásokat elérni kívánó gépek beállítása következik. Ha csupán egyetlen gépünk van, amely egyszerre szerver és kliens, akkor az itt szereplõ információk nagy részére nem lesz szükségünk. &unix; kliensek A &unix; kliensek esetében is a CUPS használatára lesz szükségünk. Miután rájuk is telepítettük, a CUPS által hálózaton megosztott nyomtatókat maguktól fel is ismerik a különbözõ munkakörnyezetek, például a GNOME vagy KDE nyomtatókezelõi. Emellett a szerverhez hasonlóan a kliensen is el tudjuk érni a címen a CUPS helyi felhasználói felületét, ahol az Administration menüben az Add Printer gombbal tudunk felvenni a szervernél tapasztalt módon hasonlóhoz. Amikor viszont megjelenik a Device legördülõ menü, akkor válasszuk az automatikusan felismert hálózati CUPS nyomtatót, vagy az ipp és http elemek valamelyikén keresztül adjuk meg a hálózati CUPS nyomtató IPP vagy HTTP alapú egységes forrásazonosítóját (URI) a következõ formák valamelyikében: ipp://szervernév-vagy-ip/printers/nyomtatónév http://szervernév-vagy-ip:631/printers/nyomtatónév Ha a CUPS kliensek valamiért nem látnák a hálózaton megosztott nyomtatókat, akkor próbáljuk meg hozzáadni a /usr/local/etc/cups/client.conf állományhoz a következõ sort: ServerName szerver-ip Ahol a szerver-ip helyére írjuk be a hálózatunkon található CUPS szerver helyi IP-címét. &windows; kliensek A &windows; XP elõtti változatai nem képesek együttmûködni a hálózaton megosztott IPP alapú nyomtatókkal. A &windowsxp; rendszertõl kezdõdõen azonban már rendelkeznek a szükséges támogatással, ezért itt már nagyon könnyû beállítani a CUPS nyomtatókat. Ehhez rendszeradminisztrátorként futtassuk a &windows; a nyomtatók hozzáadásához tartozó varázslóját, ahol válasszuk a Hálózati nyomtató típust, majd a következõ formában töltsük ki az eszköz forrásazonosítóját: http://szervernév-vagy-ip:631/printers/nyomtatónév Ha az IPP támogatását még nem tartalmazó régebbi &windows; változatunk van, akkor a CUPS szolgáltatásait a net/samba3 szerveren keresztül tudjuk elérhetõvé tenni, azonban ennek bemutatásával itt most nem foglalkozunk. Hibakeresés A CUPS használata során tapasztalható problémák többségét az engedélyek helytelen beállítása okozza. Elõször tehát, ha valami nem mûködik rendesen, akkor ellenõrizzük újra az elõbb felvázolt &man.devfs.8; beállításokat. Ezután gyõzõdjünk meg arról is, hogy az állományrendszerben ténylegesen keletkezõ eszközök engedélyei megfelelõek. Továbbá segíthet megoldani a problémát, ha felvesszük a felhasználónkat a korábban tárgyalt cups csoportba. Ha a CUPS felhasználói felületének Administration képernyõjén található beállítások látszólag hatástalanok, akkor érdemes úgy próbálkoznunk, hogy elõször készítünk egy bizonsági másolatot a /usr/local/etc/cups/cupsd.conf állományról és kézzel módosítgatva kísérletezünk különféle konfigurációs lehetõségek kombinációival. Ehhez találhatunk itt egy példát. Ezzel kapcsolatban azonban megjegyezzük, hogy a bemutatott cupsd.conf állomány inkább áttekinthetõ mintsem biztonságos módon tárgyalja a lehetõségeket. Ezért javasoljuk, hogy miután sikerült elérnünk a CUPS szervert és beállítani a klienseket, nézzük át alaposan a mintául szolgáló opciókat és korlátozzuk le minél jobban a hozzáférést. # Általános információk naplózása. Ha hibát keresünk, írjuk az # "info" helyett a "debug" értéket. LogLevel info # A rendszergazdák csoportja. SystemGroup wheel # A 631-es porton várjuk a kliensek kapcsolódását. Port 631 #Listen localhost:631 Listen /var/run/cups.sock # A helyi hálózaton megosztott nyomtatók mutatása. Browsing On BrowseOrder allow,deny #BrowseAllow @LOCAL BrowseAllow 192.168.1.* # Adjuk meg a helyi hálózatunkat. BrowseAddress 192.168.1.* # Adjuk meg a helyi hálózatunkat. # Alapértelmezett hitelesítési módszer, amikor szükség van rá. DefaultAuthType Basic DefaultEncryption Never # Vegyük ki ezt a sort, ha titkosítani akarunk. # A szervert a helyi hálózaton bármelyik gép elérheti. <Location /> Order allow,deny #Allow localhost Allow 192.168.1.* # Adjuk meg a helyi hálózatunkat. </Location> # A helyi hálózatról el tudjuk érni az adminisztrációs felületet. <Location /admin> #Encryption Required Order allow,deny #Allow localhost Allow 192.168.1.* # Adjuk meg a helyi hálózatunkat. </Location> # A helyi hálózatunkról el tudjuk érni a konfigurációs állományt. <Location /admin/conf> AuthType Basic Require user @SYSTEM Order allow,deny #Allow localhost Allow 192.168.1.* # Adjuk meg a helyi hálózatunkat. </Location> # Az alapértelmezett nyomtatási és feladatkezelési házirendek. <Policy default> # A feladatokat kizárólag csak a tulajdonosaik vagy a rendszergazda # képesek elvégezni. <Limit Send-Document Send-URI Hold-Job Release-Job Restart-Job Purge-Jobs \ Set-Job-Attributes Create-Job-Subscription Renew-Subscription Cancel-Subscription \ Get-Notifications Reprocess-Job Cancel-Current-Job Suspend-Current-Job Resume-Job \ CUPS-Move-Job> Require user @OWNER @SYSTEM Order deny,allow </Limit> # A karbantartást csak megfelelõ hitelesítés után végezhetünk. <Limit Pause-Printer Resume-Printer Set-Printer-Attributes Enable-Printer \ Disable-Printer Pause-Printer-After-Current-Job Hold-New-Jobs Release-Held-New-Jobs \ Deactivate-Printer Activate-Printer Restart-Printer Shutdown-Printer Startup-Printer \ Promote-Job Schedule-Job-After CUPS-Add-Printer CUPS-Delete-Printer CUPS-Add-Class \ CUPS-Delete-Class CUPS-Accept-Jobs CUPS-Reject-Jobs CUPS-Set-Default> AuthType Basic Require user @SYSTEM Order deny,allow </Limit> # A feladatokat csak a tulajdonosaik és a rendszergazda tudják törölni. <Limit Cancel-Job CUPS-Authenticate-Job> Require user @OWNER @SYSTEM Order deny,allow </Limit> <Limit All> Order deny,allow </Limit> </Policy> A CUPS portok finomhangolása Ha a CUPS lesz az elsõdlegesen használt nyomtatási rendszer, akkor az /etc/make.conf állományban érdemes lehet még további olyan változókat beállítanunk, amelyek elõtérbe helyezik a CUPS használatát a többi nyomtatási lehetõséggel szemben. Ezek közül most szót ejtünk néhányról: WITH_CUPS=YES CUPS_OVERWRITE_BASE=YES WITHOUT_LPR=YES Elsõként a WITH_CUPS látható, amely hatására a portok telepítésük során lehetõség szerint a CUPS megoldásaira fognak építkezni. Másodikként a CUPS_OVERWRITE_BASE szerepel, amely megadásával a telepítés során a &os; alapértelmezett nyomtatási rendszere, az LPR szimbolikus linkjei és állományai cserélõdnek le, illetve megakadályozza, hogy ez visszaforduljon a rendszer egy késõbbi frissítésekor. A harmadik, a WITHOUT_LPR az LPR használatának mellõzésére utasítja az érintett portokat.
diff --git a/hu_HU.ISO8859-2/books/handbook/advanced-networking/chapter.sgml b/hu_HU.ISO8859-2/books/handbook/advanced-networking/chapter.sgml index 4195a011ab..3153132cd6 100644 --- a/hu_HU.ISO8859-2/books/handbook/advanced-networking/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/advanced-networking/chapter.sgml @@ -1,8121 +1,8134 @@ Egyéb haladó hálózati témák Áttekintés Ebben a fejezetben számos komolyabb hálózati témát fogunk tárgyalni. A fejezet elolvasása során megismerjük: az átjárók és az útválasztás alapjait; hogyan állítsunk be &ieee; 802.11 és &bluetooth; eszközöket; a &os; segítségével hogyan tudunk két hálózatot összekötni hálózati hidakon keresztül; hogyan indítsuk hálózatról egy lemez nélküli gépet; hogyan állítsunk be hálózati címfordítást; hogyan kapcsoljunk össze két számítógépet PLIP használatával; hogyan állítsuk be az IPv6 használatát egy &os;-s gépen hogyan állítsuk be az ATM használatát; hogyan engedélyezzük és használjuk a Közös címredundancia protokollt &os;-ben. A fejezet elolvasásához ajánlott: az /etc/rc könyvtárban található szkriptek mûködésének ismerete; az alapvetõ hálózati fogalmak ismerete; egy új &os; rendszermag beállításának és telepítésének ismerete (); a külsõ szoftverek telepítésének ismerete (). Coranth Gryphon Készítette: Átjárók és az útválasztás útválasztás átjáró alhálózat Egy gép egy másikat úgy tud megtalálni a hálózaton, ha erre létezik egy olyan mechanizmus, amely leírja, hogyan tudunk eljutni az egyiktõl a másikig. Ezt hívjuk útválasztásnak (routing). Az útvonal (route) címek egy párjaként adható meg, egy céllal (destination) és egy átjáróval (gateway). Ez a páros mondja meg, hogy ha el akarjuk érni ezt a célt, akkor ezen az átjárón keresztül kell továbbhaladnunk. A céloknak három típusa lehet: egyéni gépek, alhálózatok és az alapértelmezett. Az alapértelmezett útvonalat (default route) abban az esetben alkalmazzuk, ha semelyik más útvonal nem megfelelõ. Az alapértelmezett útvonalakról a késõbbiekben még beszélni fogunk. Három típusa van az átjáróknak: egyéni gépek, felületek (avagy linkek) és a hardveres Ethernet címek (MAC-címek). Példa Az útválasztás különbözõ területeit a következõ netstat parancs alapján fogjuk bemutatni: &prompt.user; netstat -r Routing tables Destination Gateway Flags Refs Use Netif Expire default outside-gw UGSc 37 418 ppp0 localhost localhost UH 0 181 lo0 test0 0:e0:b5:36:cf:4f UHLW 5 63288 ed0 77 10.20.30.255 link#1 UHLW 1 2421 example.com link#1 UC 0 0 host1 0:e0:a8:37:8:1e UHLW 3 4601 lo0 host2 0:e0:a8:37:8:1e UHLW 0 5 lo0 => host2.example.com link#1 UC 0 0 224 link#1 UC 0 0 alapértelmezett útvonal Az elsõ két sorban az alapértelmezett útvonalat (melyrõl részleteiben majd a következõ szakaszban fogunk szólni) és a localhost útvonalát láthatjuk. loopback eszköz A localhost címhez az útválasztási táblázatban a lo0 eszköz tartozik (a Netif oszlopban), amelyet loopback eszköznek is neveznek. Ez arra utasítja a rendszert, hogy az ide küldött csomagokat ne a helyi hálózaton küldje keresztül, hanem csak ezen a belsõ felületen, mivel úgyis oda jutnának vissza, ahonnan indultak. Ethernet MAC-cím A táblázatban a következõ sor egy 0:e0 kezdetû címet tartalmaz. Ez egy hardveres Ethernet cím, más néven MAC-cím. A &os; magától képes beazonosítani tetszõleges gépet (ebben a példában a test0 gépet) a helyi Ethernetes hálózaton és felvenni hozzá egy útvonalat, közvetlenül az ed0 Ethernetes csatolófelületen keresztül. Ehhez a típusú útvonalhoz tartozik még egy lejárati idõ is (a Expire oszlop), amely akkor kap szerepet, ha ennyi idõ elteltével nem kapunk semmilyen hírt a géprõl. Amikor ilyen történik, az géphez eddig nyilvántartott útvonal automatikusan törlõdik. Ezek a gépek a RIP (útvonal-információs protokoll, Routing Information Protocol) nevû mechanizmuson keresztül azonosítódnak, mely a legrövidebb út kiszámítása alapján határozza meg a helyi gépekhez vezetõ útvonalat. alhálózat A &os; a helyi alhálózat (10.20.30.255 és example.com, az alhálózathoz tartozó név) esetében is felvesz útvonalakat. A link#1 megnevezés a gépben található elsõ Ethernet-kártyát jelöli. Megfigyelhetjük, hogy rajta kívül nincs is több felülete. Mindegyik csoport (a helyi hálózati gépek és a helyi alhálózatokatok) útvonalait a routed nevû démon tartja automatikusan karban. Ha ez nem fut, akkor csak a statikusan definiált (vagyis az elõre megadott) útvonalak fognak létezni. A host1 sor a saját gépünkre vonatkozik, amelyet az Ethernet címe szerint ismerünk. Mivel mi vagyunk küldõ gép, a &os; tudni fogja, hogy ilyenkor az Ethernetes felület helyett a loopback eszközt (lo0) kell használnia. A két host2 sor arra mutat példát, amikor az &man.ifconfig.8; paranccsal álneveket hozunk létre (ennek konkrét okait lásd az Ethernetrõl szóló részben). A lo0 felület neve után szereplõ => szimbólum azt jelzi, hogy ez nem csak egy loopback felület (mivel a címe szintén a helyi gépre mutat), hanem a felület egy másik neve. Ilyen útvonalak csak az álneveket ismerõ gépeknél jelennek meg. A helyi hálózaton minden más gépnél egyszerûen csak a link#1 jelenik meg az ilyen útvonalak esetében. Az utolsó sor (a 224 céllal rendelkezõ alhálózat) a multicastre (többesküldésre) szolgál, amellyel majd egy másik szakaszban foglalkozunk. Végezetül az útvonalakhoz tartozó különféle tulajdonságok a Flags oszlopban láthatóak. Az alábbi rövid táblázatban összefoglaltunk közülük néhányat: U Up: az útvonal aktív H Host: az útvonal egyetlen gépre mutat G Gateway: az adott cél felé ezen a gépen keresztül küldjünk, amely majd kitalálja, hogy merre küldje tovább S Static: ez az útvonal statikus, nem a rendszer hozta létre automatikusan C Clone: ebbõl az útvonalból származtatunk új útvonalat azokhoz a gépekhez, amelyekhez csatlakozunk. Ilyen útvonalakat általában a helyi hálózatokban találhatunk W WasCloned: azt jelzi, hogy ezt az útvonalat egy helyi hálózatra mutató (klón, avagy Clone típusú) útvonal alapján hoztuk létre automatikusan L Link: az útvonal Ethernetes hardverhez kapcsolódik Alapértelmezett útvonalak alapértelmezett útvonal Amikor a helyi rendszernek fel kell vennie a kapcsolatot egy távoli géppel, ellenõrzi az útválasztási táblázatban, hogy létezik-e már hozzá valamilyen útvonal. Ha a távoli gép egy olyan alhálózatba esik, amelyet már el tudunk érni (klónozott útvonalak), akkor a rendszer megnézi, hogy a hozzá tartozó felületen képes-e kapcsolatot létesíteni. Ha minden ismert útvonal csõdöt mond, akkor a rendszerünknek marad még egy utolsó esélye: az alapértelmezett útvonal használata. Ez az útvonal egy speciális átjáró útvonal (ebbõl általában csak egyetlen egy létezik a rendszerben) és tulajdonságai között mindig szerepel a c. A helyi hálózat gépei közül ez az átjáró az legyen, amelyik közvetlenül kapcsolódik a külsõ világhoz (PPP összeköttetéssel, DSL, kábelmodem, T1 vagy bármilyen más hálózati felületen keresztül). Amikor pedig magát a külsõ világ felé átjáróként szolgáló gépet állítjuk be, az alapértelmezett útvonal az internet-szolgáltatónk által megadott gép címe lesz. Vegyünk egy példát az alapértelmezett útvonalakra. Egy tipikus konfiguráció: [Helyi2] <--ether--> [Helyi1] <--PPP--> [ Szolg. ] <--ether--> [T1-ÁJ] A Helyi1 és Helyi2 gépek a hálózatunk tagjai. A Helyi1 az internet-szolgáltatót éri el egy betárcsázós PPP kapcsolaton keresztül. A PPP szerver a külsõ felületén keresztül a helyi hálózaton pedig egy másik átjáróhoz csatlakozik. Az egyes gépek alapértelmezett útvonalai így alakulnak: Gép Alapértelmezett átjáró Felület Helyi2 Helyi1 Ethernet Helyi1 T1-ÁJ PPP Gyakran felmerül a kérdés, hogy Miért (és hogy-hogy) a T1-ÁJ a Helyi1 gép számára az alapértelmezett átjáró és nem a szolgáltató azon szervere, amelyhez csatlakozott? Ne felejtsük el, hogy a PPP felület a szolgáltató helyi hálózatában a mi részünkre kap címet, és a itt az összes többi géphez tartozó útvonal automatikusan létrejön. Emiatt már eleve el tudjuk érni a T1-ÁJ gépet, ezért amikor a szolgáltatón keresztül küldünk, nincs szükségünk egy további lépcsõre. Általában a X.X.X.1 címet szokták a helyi hálózat átjárójának kiosztani. Ezért (az elõbbi példát újrahasznosítva) ha a helyi hálózatunkon a C osztályú 10.20.30 címtartományt használjuk, és a szolgáltatónkhoz a 10.9.9 címtartomány tartozik, akkor az alapértelmezett útvonalak a következõk lesznek: Gép Alapértelmezett útvonal Helyi2 (10.20.30.2) Helyi1 (10.20.30.1) Helyi1 (10.20.30.1, 10.9.9.30) T1-ÁJ (10.9.9.1) Az /etc/rc.conf állományon keresztül könnyen meg tudjuk adni az alapértelmezett útvonalat. A példánkban a Helyi2 gép /etc/rc.conf állományába kell felvennünk a következõ sort: defaultrouter="10.20.30.1" A &man.route.8; parancs használatával viszont akár közvetlenül is megtehetjük mindezt: &prompt.root; route add default 10.20.30.1 A &man.route.8; man oldalon olvashatunk arról bõvebben, hogy a hálózati útválasztási táblázatokat kézzel hogyan tudjuk módosítani. Kettõs hálózatú gépek kettõs hálózatú gépek Egy másik típusú konfigurációról is szót kell ejtenünk, ahol a gép egyszerre két hálózatnak is tagja. Gyakorlatilag az átjáróként üzemelõ számítógépek (mint például az, amelyik a fenti példában PPP kapcsolattal csatlakozott) ilyen kettõs hálózatú gépnek tekinthetõek. Ez a kifejezés azonban igazából csak azokra az esetekre illik, ahol a gép egyszerre két helyi hálózatban is megjelenik. Az egyik esetben a gépben két Ethernet kártya található, melyek mindegyike birtokol egy-egy hálózati címet az egyes alhálózatokon. De elõfordulhat az is, hogy a gépünkben csupán egyetlen Ethernet kártya van és az &man.ifconfig.8; segítségével álneveket hoztunk létre hozzá. Az elõbbi általában két fizikailag elkülönölõ Ethernet alapú hálózat esetében történik, míg az utóbbinál csak egyetlen fizikai hálózati szegmensrõl van szó, amely viszont logikailag két külön alhálózatot tartalmaz. Akármelyiket is vesszük, az útválasztási táblázatok úgy jönnek létre, hogy bennük a gép a másik alhálózat felé átjáróként (bejövõ útvonalként) lesz nyilvántartva. Ebben a konfigurációban a gép a két alhálózat között útválasztóként fog tevékenykedni, és gyakran valamelyik vagy éppen mind a két irányba be kell állítanunk valamilyen csomagszûrést vagy tûzfalazást. Ha azt szeretnénk, hogy ez a gép a két felület között továbbítson csomagokat, akkor a &os;-ben külön engedélyezni kell ezt a lehetõséget. A következõ szakaszban ennek részleteit tárjuk fel. Az útválasztók beállítása útválasztó A hálózati útválasztó nem csinál mást, csak továbbküldi az egyik felületén beérkezõ csomagokat egy másik felületére. Az internetes szabványok és a sokéves mérnöki tapasztalat azonban nem engedik, hogy a &os; Projekt alapértelmezés szerint is elérhetõvé tegye ezt a &os; rendszerekben. Ezt a lehetõséget az alábbi változó YES értékûre állításával lehet engedélyezni az &man.rc.conf.5; állományban: gateway_enable="YES" # Ez legyen YES, ha átjáróként akarunk üzemelni Ezzel lényegében a net.inet.ip.forwarding &man.sysctl.8; változó értékét állítjuk 1-re. Ha valamiért egy idõre szüneteltetni akarjuk a csomagok továbbküldését, akkor állítsuk a változó értékét 0-ra. BGP RIP OSPF Az új útválasztónak nem árt arról sem tudnia, hogy merre továbbítsa a forgalmat. Ha elég egyszerû a hálózatunk, akkor akár statikus útvonalakat is használhatunk. A &os; alapból tartalmazza a BSD-k esetén szabványos &man.routed.8; útválasztó démont, amely a RIP (v1 és v2) valamint az IRDP megoldásokat ismeri. A BGP v4, OSPF v2 és a többi fejlettebb útválasztási protokoll a net/zebra csomagban érhetõ el. Az ettõl bonyolultabb hálózati útválasztási feladatokhoz olyan kereskedelmi termékek is elérhetõek, mint például a &gated;. Al Hoang Írta: Statikus útvonalak beállítása Manuális konfiguráció Tegyük fel, hogy hálózatunk a következõ: INTERNET | (10.0.0.1/24) alapértelmezett átjáró internet felé | |az xl0 felület |10.0.0.10/24 +------+ | | A-utvalaszto | | (FreeBSD átjáró) +------+ | az xl1 felület | 192.168.1.1/24 | +--------------------------------+ 1. belsõ hálózat | 192.168.1.2/24 | +------+ | | B-utvalaszto | | +------+ | 192.168.2.1/24 | 2. belsõ hálózat Ebben a forgatókönyvben az A-utvalaszto a mi &os;-s gépünk, amely az internet felé vezetõ útválasztó szerepét játssza. Számára az alapértelmezett útvonal a 10.0.0.1, amelyen keresztül a külsõ világot tudja elérni. Feltételezzük, hogy a B-utvalaszto nevû gépet már eleve jól állítottuk be, ezért tudja merre kell mennie. (A kép alapján egyszerû: csak vegyünk fel egy alapértelmezett útvonalat a B-utvalaszto géphez, ahol így a 192.168.1.1 lesz az átjáró.) Ha megnézzük most az A-utvalaszto útválasztási táblázatát, akkor nagyjából a következõket fogjuk látni: &prompt.user; netstat -nr Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 10.0.0.1 UGS 0 49378 xl0 127.0.0.1 127.0.0.1 UH 0 6 lo0 10.0.0/24 link#1 UC 0 0 xl0 192.168.1/24 link#2 UC 0 0 xl1 Az A-utvalaszto útválasztási táblázata alapján jelen helyzetben nem lehet elérni a 2. belsõ hálózatot. Nincs ugyanis olyan útvonal, amely a 192.168.2.0/24 alhálózat felé vezetne. Ezt például úgy tudjuk megoldani, ha manuálisan felvesszük ezt az útvonalat. Az alábbi paranccsal hozzáadjuk a 2. belsõ hálózat elérését az A-utvalaszto útválasztási táblázatához, ahol a 192.168.1.2 lesz a következõ ugrási pont (next hop): &prompt.root; route add -net 192.168.2.0/24 192.168.1.2 Most már az A-utvalaszto bármelyik gépet képes elérni a 192.168.2.0/24 hálózaton. Rögzített konfiguráció A fenti példa tökéletesen szemlélti a statikus útvonalak felvételét egy mûködõ rendszeren. Azonban ezzel az a gond, hogy az így megadott útválasztási információ nem marad meg a gép újraindítása után. Ezért az elõbbihez hasonló statikus útvonalakat inkább az /etc/rc.conf állományban rögzítsük: # A 2. belsõ hálózat elérését felvesszük statikus útvonalként static_routes="belsohalo2" route_belsohalo2="-net 192.168.2.0/24 192.168.1.2" A static_routes konfigurációs változó karakterláncok szóközzel tagolt felsorolását tartalmazza. Mindegyik karakterlánc egy útvonal neve. Az iménti példában csak egyetlen ilyen név szerepelt a static_routes értékében, amely a belsohalo2 volt. Utána beírtunk még egy konfigurációs változót is, amelynek a neve route_belsohalo2. Ide helyeztük a &man.route.8; parancsnak átadandó beállítás összes paraméterét. Ez pontosan olyan, mintha a következõ parancsot adtuk volna ki: &prompt.root; route add -net 192.168.2.0/24 192.168.1.2 Ezért kellett a "-net 192.168.2.0/24 192.168.1.2". Ahogy már korábban is említettük, a static_routes értékében több karakterláncot is megadhatunk, aminek segítségével egyszerre több statikus útvonalat is létrehozhatunk. A következõ sorok arra mutatnak példát, hogy a 192.168.0.0/24 és 192.168.1.0/24 hálózatok számára miként állítsunk be statikus útvonalakat a képzeletbeli útválasztónkon: static_routes="net1 net2" route_net1="-net 192.168.0.0/24 192.168.0.1" route_net2="-net 192.168.1.0/24 192.168.1.1" Az útvonalak terjedése útvonalterjedés Azt már tudjuk, hogyan adjuk meg a külvilág felé vezetõ útvonalakat, azonban arról még nem beszéltünk, hogy kívülrõl miként találnak meg bennünket. Annyit már megismertünk, hogy az útválasztási táblázatokban megadhatjuk a hálózaton azt a gépet, amelyen keresztül az adott címtartomány (a példában egy C osztályú alhálózat) felé küldhetünk, amely pedig továbbküldi a hozzá érkezõ csomagokat. Amikor a csatlakozunk az internet-szolgáltatónkhoz, a nála levõ útválasztási táblázatok úgy állítódnak be, hogy az alhálózatunk felé igyekvõ adatok a korábban létrejött PPP összeköttetésen keresztül jutnak el hozzánk. A világ többi részén levõ rendszerek viszont honnan fogják tudni, hogy a mi internet-szolgáltatónknak küldjenek? Van egy rendszer (ez leginkább a névszerverek elosztott információs adatbázisához hasonlít), ami nyilvántartja a pillanatnyilag kiosztott címtartományokat és megadja a csatlakozási pontjukat az internet gerinchálózatán. Ez a gerinc tulajdonképpen olyan fõvonalakból áll, amelyen keresztül a világban az országok között mozog az internet forgalma. A gerinchálózat mindegyik gépe tárolja a központi útválasztási táblázatok egy másolatát, ami a forgalmat egy adott hálózatról a megadott gerincbeli hordozóra irányítja át, végig az internet-szolgáltatók láncán egészen addig, amíg az el nem éri a hálózatunkat. A szolgáltatónk feladata, hogy a gépünk felé leágazásként (és így a felénk vezetõ útként) beregisztálja magát a gerinchálózat gépein. Ezt nevezik az útvonal terjedésének. Hibaelhárítás traceroute Néha gondok lehetnek az útvonal terjedésével, és egyes gépek nem képesek elérni minket. A &man.traceroute.8; parancs mind közül talán az egyik leghasznosabb ilyen helyzetekben, mivel ezzel fel tudjuk deríteni, hogy az útválasztás hol akad meg. Ugyanilyen jól hasznosítható azokban az esetekben, amikor látszólag nem tudunk elérni egy távoli gépet (tehát a &man.ping.8; csõdöt mond). A &man.traceroute.8; parancsnak annak a távoli gépnek a nevét kell megadnunk, amelyhez csatlakozni akarunk. Futása közben megjeleníti azokat az átjárókat, amelyeken keresztül csatlakozni próbál, akár sikerült elérni a célgépet, akár a kapcsolat hiánya miatt kudarcot vall. A parancs használatáról és mûködésérõl részletesebb információkat a &man.traceroute.8; man oldalán találunk. Útválasztás multicast esetén multicast útválasztás a rendszermag beállításai MROUTING A &os; alapból támogatja mind a multicastet használó alkalmazásokat, mind pedig a multicasthez tartozó útválasztást. Multicast esetében semmilyen speciális beállítás nem szükségeltetik, az ilyen alkalmazások egybõl el tudják érni ezt a lehetõséget. A multicast kérések útválasztásához azonban be kell építenünk némi támogatást a rendszermagba: options MROUTING Emellett még el kell indítanunk az &man.mrouted.8; démont is, amelyhez az /etc/mrouted.conf állományban még be kell állítanunk tunneleket és a DVMRP használatát. A multicasthez tartozó további beállításokat az &man.mrouted.8; man oldalán találhatjuk. A &os; 7.0 megjelenésével a &man.mrouted.8; démont kivették az alaprendszerbõl. Azt a DVMRP többesküldési protokollt valósítja meg, amelyet a legtöbb alkalmazásban mostanság már a &man.pim.4; segítségével oldanak meg. Ennek megfelelõen a hozzá tartozó multicast protokollt valósítja meg, amelyet a legtöbb alkalmazásban mostanság már a &man.pim.4; segítségével oldanak meg. Ennek megfelelõen a hozzá tartozó &man.map-mbone.8; és &man.mrinfo.8; segédprogramok is eltávolításra kerültek. Ezek a programok attól a kiadástól kezdõdõen a Portgyûjtemény részeként érhetõek el a net/mrouted portban. Loader Marc Fonvieille Murray Stokely Vezeték nélküli hálózatok vezeték nélküli hálózatok 802.11 vezeték nélküli hálózatok A vezeték nélküli hálózatok alapjai A legtöbb vezeték nélküli hálózat az &ieee; 802.11 szabványon nyugszik. Az alapvetõ vezeték nélküli hálózatokban több olyan állomást találhatunk, amelyek egymással rádiójelek szórásával kommunikálnak a 2,4 GHz vagy 5 GHz frekvenciatartományban (noha ez a helyi viszonyoknak megfelelõen változhat, és a 2,3 GHz, illetve a 4,9 GHz tartományokban is lehetséges a kommunikáció). A 802.11 szabványú hálózatok kétféleképpen szervezõdnek. Elõször is infrastrukturálisan, (infrastructural mode) ahol az egyik állomást kinevezzük a központnak és a többi pedig ehhez fog tartozni. Az ilyen hálózatokat BSS-nek nevezzük és az imént említett központ neve hozzáférési pont (Access Point, AP) lesz. A BSS-ben az összes kommunikáció a hozzáférési pontokon keresztül halad még abban az esetben is, amikor az egyik állomás egy másik vezeték nélküli állomással akarja felvenni a kapcsolatot. Az ilyen jellegû hálózatok másik típusú szervezõdési módjában nincsenek kijelölt központok és a kommunikáció az állomások között közvetlenül zajlik. A hálózat ezen formáját IBBS-nek nevezzük, vagy ismeretebb nevén ad-hoc hálózatnak (ad-hoc network). A 802.11 alapú hálózatok elsõként a 2,4 GHz-es sávot hódították meg, és az &ieee; 802.11 valamint 802.11b szabványokban rögzített protokollokat használták. Ezekben a specifikációkban megtalálhatjuk a mûködési frekvenciát, a közeghozzáférési réteg jellemzõinek leírását, beleértve a keretezést és az átviteli sebességeket (a kommunikáció ugyanis eltérõ sebességekkel is történhet). A késõbb kiadott 802.11a szabvány azt specifikálja, hogy az 5 GHz-es tartományban miként mûködjenek, ahol többek közt megtalálhatjuk a különféle jelkezelési mechanizmusokat és a nagyobb átviteli sebességek használatát. Ezt még a 802.11g szabvány követte, ami a 802.11b hálózatokkal kompatibilis módon lehetõvé tette a 802.11a jelkezelésének és átviteli módszereinek használatát a 2,4 GHz-es sávban. A 802.11 alapú hálózatok mindenféle átviteli technikáitól eltekintve többféle biztonsági megoldással találkozhatunk. Az korai 802.11 dokumentumok egy nagyon egyszerû biztonsági protokollt, a WEP-et említenek. Ez a protokoll a hálózaton mozgó adatokat egy rögzített és ismert osztott kulccsal kódolja le az RC4 titkosítással. A kommunikációhoz az összes állomásnak elõre meg kell egyeznie ebben a kulcsban. Errõl a sémáról idõközben kiderült, hogy könnyen feltörhetõ és manapság már csak nagyon ritkán alkalmazzák, kivéve talán csak a kóbor felhasználók elijesztésére. A jelenleg érvényes biztonsági elõírásokat az &ieee; 802.11i specifikáció adja meg, amely új kriptográfiai titkosításokat definiál valamint egy további protokollt az állomások azonosítására és a kulcsok cseréjére. Emellett a titkosításhoz használt kulcsok idõszakosan frissülnek és külön eszközök állnak rendelkezésre a betörési kísérletek észlelésére (és azok elhárítására). A vezeték nélküli hálózatok esetében másik elterjedt titkosítási protokoll a WPA. Ez igazából 802.11i elõdjének tekinthetõ, amelyet egy ipari csoport definiált, amíg a 802.11i minõsítés alatt állt. A WPA ennek megfelelõen teljesíti a 802.11i szabvány elvárásainak egy részét és kifejezetten a régi hardverek számára készült. A WPA mûködéséhez egyedül a TKIP titkosításra van szükségünk, amely az eredeti WEP titkosításból származik. A 802.11i engedi a TKIP használatát, de az adatok kódolására egy erõsebb titkosítás, az AES-CCM ismeretét is igényli. (Az AES a WPA esetében nem kell, mivel a régi eszközök esetében túlságosan költségesnek ítélték meg a használatát.) A fenti szabványokon kívül a 802.11e a másik fontos szabvány, amire tekintettel kell lennünk. Ez írja le a 802.11 hálózatokon a multimédiás alkalmazások közvetítéséhez, mint például a videók valós idejû lejátszásához vagy a VoIP (voice over IP) megvalósításához tartozó protokollokat. A 802.11i szabványhoz hasonlóan a 802.11e is magában foglal egy elõzetes specifikációt, amelyet WME (késõbb pedig már WMM)-nek neveznek. Ezt szintén egy ipari csoport definiálta a 802.11e részeként, amivel a 802.11e végsõ elfogadásáig tudják a multimédiás igényeket kiszolgálni. Amit a 802.11e és WME/WMM megoldásaival kapcsolatban érdemes tudnunk: a QoS (Quality of Service) protokoll és más egyéb fejlett közeghozzáférési protokollok segítségével a vezeték nélküli hálózatokban lehetõvé teszik a forgalom prioritás szerinti ütemezését. Ezen protokollok megfelelõ implementációjának segítségével tehát a fontosabb adatok nagy sebességû küldését és áramoltatását vagyunk képesek elérni. A &os; a 6.0 verzió óta ismeri a 802.11a, 802.11b és 802.11g szabványokon alapján mûködõ hálózatokat. A WPA és 802.11i biztonsági protokollok (a 11a, 11b és 11g szabványok bármelyike esetén) hasonlóképpen támogatottak, valamint a WME/WMM protokollok mûködéséhez szükséges QoS csak bizonyos vezeték nélküli eszközök esetében. Kezdeti beállítások A rendszermag beállítása A vezeték nélküli hálózatok használatához egy vezeték nélküli hálózati kártyára lesz szükségünk, valamint a rendszermagban is be kell állítani ehhez a megfelelõ támogatást. Ez utóbbit több különbözõ modulra szedték szét, és ezek közül csak azokat kell beállítani, amelyeket tényleg használni is fogunk. Elõször is tehát kell egy vezeték nélküli eszköz. Az elterjedtebb típusaik általában az Atheos által gyártott alkatrészeket tartalmazzák. Az ilyen fajtájú eszközöket az &man.ath.4; meghajtó kezeli, melyet úgy tudunk a rendszer indításakor betölteni, ha a /boot/loader.conf állományba felvesszük a következõ sort: if_ath_load="YES" Az Atheos meghajtója három különálló részre oszlik: maga a meghajtó (&man.ath.4;), a hardveres réteg, ami a chipfüggõ funkciókat kezeli (&man.ath.hal.4;) és a keretek küldésével kapcsolatban az átviteli sebesség megválasztását lehetõvé tevõ algoritmus (ez itt most az ath_rate_sample). Amikor ezt a támogatást modulként töltjük be, ezek a függõségek automatikusan feloldódnak. Ha az Atheos eszközök helyett valamelyik másikhoz tartozó modult szeretnénk használni, akkor például az Intersil Prism esetében a &man.wi.4; meghajtót kell megadnunk: if_wi_load="YES" A leírás további részeiben az &man.ath.4; eszközt fogjuk használni, minden más esetben ennek a nevét kell csak lecserélünk a példákban. A rendszerben elérhetõ vezeték nélküli meghajtók és az általuk támogatott kártyák listája a &os; Hardverjegyzetekben található. Ezek a jegyzetek a különbözõ architektúrákra és kiadásokhoz a &os; holnapjáról, a Kiadási jegyzetek oldalról érhetõek el. Ha a vezeték nélküli eszközünkhöz nem létezik natív &os;-s meghajtó, akkor az NDIS meghajtó segítségével akár közvetlenül a &windows;-os meghajtóját is használhatjuk. &os; 7.X esetén az eszközmeghajtó beállításával együtt a 802.11 hálózatok támogatását is be kell töltenünk a rendszermagba. Ez az &man.ath.4; meghajtó esetében a legalább a &man.wlan.4;, wlan_scan_ap és wlan_scan_sta modulok betöltését jelenti. A &man.wlan.4; modul a vezetéknélküli eszköz meghajtóprogramjával együtt töltõdik be, míg a többi modult a /boot/loader.conf állomány használatával kell a rendszerindítás során betöltenünk: wlan_scan_ap_load="YES" wlan_scan_sta_load="YES" A &os; 8.0 kiadástól kezdõdõen ezek a modulok részei a &man.wlan.4; meghajtónak, amely a hálózati kártya meghajtójával együtt mindig automatikusan betöltõdik. Emellett még azokra a modulokra is szükségünk van, amelyek a használni kívánt biztonsági protokollokhoz nyújtanak kriptográfiai támogatást. Ezek hivatalosan a &man.wlan.4; modul kérésére automatikusan betöltõdnek, azonban itt most manuálisan állítjuk be. Erre a célra a következõ modulokat találjuk: &man.wlan.wep.4;, &man.wlan.ccmp.4; és &man.wlan.tkip.4;. A &man.wlan.ccmp.4; és &man.wlan.tkip.4; meghajtók csak akkor fognak kelleni, ha a WPA és/vagy a 802.11i biztonsági protokollokat használjuk. Amennyiben a hálózatunkon nincs titkosítás, akkor még a &man.wlan.wep.4; támogatás sem kell. Ezeket a modulok úgy lehet betölteni a rendszerindításnál, ha felvesszük a következõ sorokat a /boot/loader.conf állományba: wlan_wep_load="YES" wlan_ccmp_load="YES" wlan_tkip_load="YES" Miután ezt megcsináltuk, egyszerûen csak indítsuk újra a gépünket. Ha még nem akarjuk újraindítani a gépet, akkor a &man.kldload.8; parancs segítségével akár kézzel is betölthetjük az elõbb felsorolt modulokat. Ha nem akarunk modulokat használni, a mûködéshez szükséges meghajtókat a rendszermagba is be tudjuk építeni a következõ sorok megadásával a rendszermag beállításait tartalmazó állományban: device wlan # a 802.11 támogatása device wlan_wep # 802.11 WEP támogatás device wlan_ccmp # 802.11 CCMP támogatás device wlan_tkip # 802.11 TKIP támogatás device wlan_amrr # AMRR forgalomvezérlési algoritmus device ath # Atheros IEEE 802.11 vezeték nélküli hálózati meghajtó device ath_hal # az Atheros meghajtó hardveres rétege options AH_SUPPORT_AR5416 # az AR5416 tx/rx leírók engedélyezése device ath_rate_sample # SampleRate forgalomvezérlési algoritmus Hozzátesszük, hogy az alábbi sorok hozzáadása a &os; 7.X változatában kötelezõ, más verzióknál viszont nem: device wlan_scan_ap # a 802.11 AP módú keresés device wlan_scan_sta # a 802.11 STA módú keresés Az elõbbiek megadásával fordítsuk újra és telepítsük a rendszermagot, majd indítsuk újra a számítógépünket. Miután a rendszerünk újra elindult, a rendszer indítás során generált üzenetei között találnunk kell valamennyi információt a felismert vezeték nélküli eszközökrõl. Például: - ath0: <Atheros 5212> mem 0xff9f0000-0xff9fffff irq 17 at device 2.0 on pci2 -ath0: Ethernet address: 00:11:95:d5:43:62 -ath0: mac 7.9 phy 4.5 radio 5.6 + ath0: <Atheros 5212> mem 0x88000000-0x8800ffff irq 11 at device 0.0 on cardbus1 +ath0: [ITHREAD] +ath0: AR2413 mac 7.9 RF2413 phy 4.5 Az infrastrukturális mûködési mód Általában az infrastrukturális avagy a BBS mód használata a gyakori. Ebben a mûködési módban adott számú vezeték nélküli hozzáférési pont csatlakozik a hagyományos hálózatra. Mindegyik vezeték nélküli hálózatnak saját neve van, amit a hálózat SSID-jének hívunk. A vezeték nélküli kliensek ezekhez a vezeték nélküli hozzáférési pontokhoz kapcsolódnak. A &os;-s kliensek használata Hogyan keressünk hozzáférési pontokat A hálózatok kereséséhez az ifconfig paranccsal tudunk nekifogni. Egy ilyen kérés kiszolgálása eltarthat néhány pillanatig, mivel ekkor a rendszernek végig kell bóklásznia az összes elérhetõ frekvenciát és azokon hozzáférési pontok után kutatni. Egyedül a rendszeradminisztrátor kezdeményezheti ezeket a kereséseket: &prompt.root; ifconfig wlan0 create wlandev ath0 &prompt.root; ifconfig wlan0 up scan -SSID BSSID CHAN RATE S:N INT CAPS +SSID/MESH ID BSSID CHAN RATE S:N INT CAPS dlinkap 00:13:46:49:41:76 11 54M -90:96 100 EPS WPA WME freebsdap 00:11:95:c3:0d:ac 1 54M -83:96 100 EPS WPA Csak jelzésû felületen tudunk hálózatokat keresni. További keresésekre már nincs szükség a felület állapotban tartásához. &os; 7.X esetén a wlan0 eszköz helyett közvetlenül az adott eszköz nevét kell megadnunk, például ath0. Az iménti sorokat ennek megfelelõen tehát ebben az esetben így kell értelmezni: &prompt.root; ifconfig ath0 up scan A leírás további részében a &os; 7.X felhasználóknak ezen séma alapján kell használniuk a parancsokat és a konfigurációs beállításokat. A keresés során keletkezõ listában láthatjuk megtalált BBS vagy IBBS fajtájú hálózatokat. A hálózatok neve és SSID-ja mellett még megjelenik egy BSSID oszlop is, ahol a hozzáférési pontok MAC-címe szerepel. A CAPS oszlop az egyes állomások tulajdonságait adja meg: E Extended Service Set (ESS): az állomás egy infrastrukturális vagyis BBS hálózat része. I IBSS/ad-hoc hálózat: az állomás egy ad-hoc hálózat része. P Privacy: a BBS-en belül minden keretet titkosítani kell. Tehát a BSS arra kötelezi az állomást, hogy WEP, TKIP vagy AES-CCMP titkosítás használatával kódolja a hálózat tagjai között közlekedõ kereteket. S Short Preamble: a hálózatban rövid bevezetõjeleket használnak (a 802.11b High Rate/DSSS PHY elõírásai szerint), ahol a szokványos 128 bites szinkronizációs mezõ hossza csak 56 bit. s Short Slot Time: a 802.11g hálózat rövid slotidõt használ, mivel nem találhatóak benne régi (802.11b szabványú) állomások. A jelenleg ismert hálózatok listáját így tudjuk lekérdezni: &prompt.root; ifconfig wlan0 list scan Ezt az információt maga az adapter automatikusan, vagy a felhasználó tudja frissíteni a kérés kiadásával. Az elavult adatok maguktól törlõdnek a gyorsítótárból, így idõvel a lista zsugorodni fog, hacsak nem keresünk folyamatosan hálózatokat. Alapvetõ beállítások Ebben a szakaszban arra mutatunk példákat, hogy miként tudunk &os; alatt titkosítás nélkül használni egy vezeték nélküli hálózati kártyát. Miután elsajátítottuk az itt szereplõ ismereteket, határozottan javasoljuk, hogy a vezeték nélküli hálózatunkat WPA használatával állítsuk be. A vezeték nélküli hálózatok beállítása három elemi lépésbõl épül fel: a hozzáférési pont kiválasztása, az állomásunk hitelesítése és az IP-cím beállítása. A következõkben ezeket a lépéseket vitatjuk meg. A hozzáférési pont kiválasztása A legtöbb esetben hagyjuk, hogy a rendszer válassza ki magának a különbözõ heurisztikák alapján a leginkább megfelelõ hozzáférési pontot. Ez az alapértelmezett tevékenység, amikor aktiváljuk a felületet vagy valamilyen más módon, például az/etc/rc.conf állományból hivatkozunk rá: wlans_ath0="wlan0" ifconfig_wlan0="DHCP" A korábban említettek szerint a &os; 7.X felhasználóknak csak a kártyát kell beállítani: ifconfig_ath0="DHCP" Ha viszont több hozzáférési pont közül mi magunk akarunk kiválasztani egyet, akkor ezt az SSID megadásával tehetjük meg: wlans_ath0="wlan0" ifconfig_wlan0="ssid saját_ssid DHCP" Amikor olyan környezetben vagyunk, ahol több hozzáférési pontnak is megegyezik az SSID-ja (gyakran így próbálják egyszerûsíteni azt, hogy automatikusan váltani lehessen köztük), akkor szükségünk lehet ezt egy adott eszközhöz hozzárendelni. Ebben az esetben a hozzáférési pont BSSID-ját is definiálni kell (és az SSID-t akár el is hagyhatjuk): wlans_ath0="wlan0" ifconfig_wlan0="ssid saját_ssid bssid xx:xx:xx:xx:xx:xx DHCP" Más módokon is képesek vagyunk szabályozni a hozzáférési pontok megválasztását, például a rendszerünk által vizsgált frekvenciasávok megadásával. Ez olyankor tud hasznos lenni, ha többsávos vezeték nélküli kártyánk van, és az összes tartomány végigpásztázása túlságosan sok idõt venne el. Ezt a mûvelet a paraméter megadásával lehet egy konkrét sávra leszûkíteni, például a wlans_ath0="wlan0" ifconfig_wlan0="mode 11g ssid saját_ssid DHCP" beállítás hatására a kártya 802.11g módban fog üzemelni, ami kizárólag csak 2,4 GHz-es frekvenciákon használható, így az 5 GHz-es csatornákat egyszerûen figyelmen kívül hagyjuk. Ugyanezt a paraméterrel is meg tudjuk oldani, mivel így a mûködést egy adott frekvenciára korlátozzuk, valamint a paraméterrel, ahol a pásztázandó csatornákat sorolhatjuk fel. Ezekrõl a paraméterekrõl részletesebb leírást az &man.ifconfig.8; man oldalon találhatunk. Hitelesítés Miután sikeresen kiválasztottuk a számunkra megfelelõ hozzáférési pontot, az adatok küldéséhez az állomásunknak valamilyen módon hitelesítenie kell magát. A hitelesítés több módon történhet. Erre a leggyakrabban alkalmazott sémát nyílt hitelesítésnek (open authentication) nevezik, ahol a hálózathoz tetszõleges állomás csatlakozhat és kommunikálhat vele. Ezt a típusú hitelesítést akkor érdemes használni, amikor a vezeték nélküli hálózatunkat teszteljük. Más sémákban az adatfolyam megindításához egy titkosítási kézfogás szükséges, vagy elõre megosztott kulcsok esetleg jelszavak segítségével, vagy bonyolultabb sémák esetében itt még olyan különbözõ háttérszolgáltatások is megjelennek, mint például a RADIUS. A legtöbb felhasználó a nyílt hitelesítést használja, ami egyben az alapértelmezés is. A másik legelterjedtebb beállítás a WPA-PSK, avagy WPA Personal, amelyrõl lentebb még szólni fogunk. Ha &apple; &airport; Extreme Base Station típusú hozzáférési pontunk van, akkor az osztott kulcsú hitelesítés mellett egy WEP kulcsot is be állítanunk. Ezt az /etc/rc.conf állományban vagy a &man.wpa.supplicant.8; programban tehetjük meg. Ha egyetlen &airport; bázisállomásunk van, akkor az elérést valahogy így tudjuk beállítani: wlans_ath0="wlan0" ifconfig_wlan0="authmode shared wepmode on weptxkey 1 wepkey 01234567 DHCP" Általánosságban véve elmondhatjuk, hogy az osztott kulcsú hitelesítést inkább kerüljük el, mivel WEP kulcsok használatára alapszik és ráadásul olyan módon, hogy nagyon könnyû feltörni. Ha már mindenképpen a WEP mellett kell döntenünk (például a régebbi eszközökkel így tudunk csak kompatibilisek maradni), akkor jobban járunk, ha a nyílt hitelesítéshez alkalmazzuk. A WEP használatát érintõ további információkat a ban találjuk. IP-cím szerzése DHCP használatával Miután kiválasztottunk egy hozzáférési pontot és beállítottuk a hitelesítés paramétereit, egy IP-cím is kelleni fog a kommunikációhoz. Az esetek túlnyomó részében DHCP-n keresztül kapunk IP-címet a vezeték nélküli kapcsolatunkhoz. Ezt úgy érhetjük el, ha egyszerûen megnyitjuk az /etc/rc.conf állományt és az alábbihoz hasonló módon felvesszük a DHCP paramétert az eszközünk beállításaihoz: wlans_ath0="DHCP" ifconfig_wlan0="DHCP" Így már készen is állunk a vezeték nélküli felület használatára: &prompt.root; /etc/rc.d/netif start Ahogy a felület mûködõképessé válik, az ifconfig parancs segítségével ellenõrizni is tudjuk az ath0 felület állapotát: &prompt.root; ifconfig wlan0 wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 ether 00:11:95:d5:43:62 inet 192.168.1.100 netmask 0xffffff00 broadcast 192.168.1.255 media: IEEE 802.11 Wireless Ethernet OFDM/54Mbps mode 11g status: associated ssid dlinkap channel 11 (2462 Mhz 11g) bssid 00:13:46:49:41:76 country US ecm authmode OPEN privacy OFF txpower 21.5 bmiss 7 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS wme burst A status: associated azt jelenti, hogy sikeresen csatlakoztunk egy vezeték nélküli hálózathoz (jelen esetben ez a dlinkap). A bssid 00:13:46:49:41:76 rész a hozzáférési pont MAC-címét tartalmazza. Az authmode OPEN pedig arról számol be, hogy a kommunikáció nem titkosított. Statikus IP-cím Ha valami okból nem tudjuk az IP-címünket DHCP szerveren keresztül lekérni, beállíthatunk rögzített IP-címet is. Ehhez nem kell mást tennünk, mint a korábban bemutatott DHCP kulcsszót kicserélni egy konkrét címmel. A hozzáférési ponthoz megadott többi paramétert azonban feltétlenül hagyjuk meg: wlans_ath0="wlan0" -ifconfig_wlan0="ssid saját_ssid inet 192.168.1.100 netmask 255.255.255.0" +ifconfig_wlan0="inet 192.168.1.100 netmask 255.255.255.0ssid saját_ssidi" WPA A WPA (Wi-Fi Protected Access, vagyis védett wi-fi hozzáférés) a 802.11 szabványokban használatos biztonsági protokoll, amelyet a WEP gyengeségeinek és megfelelõ hitelesítésének ellensúlyozására dolgoztak ki. A WPA a 802.1X hitelesítési protokolljait erõsíti és az adat sértetlenségének megõrzésére a WEP helyett több titkosítási algoritmust is felhasznál. A WPA által igényelt egyetlen titkosítás a TKIP (Temporary Key Integrity Protocol, vagyis az ideiglenes kulcs integritási protokoll), amely a WEP által az integritás ellenõrzésére és a bejutások észlelésére és azok reagálására szánt alap RC4 titkosítást bõvíti ki. A TKIP a régebbi hardvereken csupán szoftveres módosítással mûködõképessé tehetõ. Ez a kompromisszum a védelmet ugyan növeli, de még mindig kevés a támadások megfelelõ elhárításához. A WPA a TKIP mellett tartalmazza még az AES-CCMP titkosítást is, és ennek a használata javasolt. Ezt a specifikációt gyakran WPA2 (vagy RSN) néven emlegetik. A WPA definiál hitelesítési és titkosítási protokollokat. A hitelesítés általában a következõ két technika egyike alapján történik: vagy 802.1X és egy háttérszolgáltatás, például a RADIUS segítségével, vagy egy elõre megosztott kulcsot alkalmazó minimális kézfogással az állomás és a hozzáférési pont között. Az elõbbit gyakran WPA Enterprise-nak, míg az utóbbit WPA Personalnak hívják. Mivel a legtöbben nem állítanak be egy komplett RADIUS alapú szervert a vezeték nélküli hálózatukhoz, ezért a WPA-PSK a WPA leginkább elterjedten használt változata. A vezeték nélküli kapcsolat és a hitelesítés (kulcs alapján vagy szerverrel) vezérlését a &man.wpa.supplicant.8; segédprogram végzi. Ennek a programnak mûködéséhez egy konfigurációs állományra van szüksége, amely az /etc/wpa_supplicant.conf néven érhetõ el. Errõl az állományról bõvebb információt a &man.wpa.supplicant.conf.5; man oldalán lelhetünk. WPA-PSK A WPA-PSK, más néven WPA-Personal, egy adott jelszó alapján generált elõre megosztott kulcssal (pre-shared key, PSK) mûködik, amit a vezeték nélküli hálózatokban mesterkulcsént használnak. Ez azt jelenti, hogy minden egyes vezeték nélküli felhasználó ugyanazon a kulcson osztozik. A WPA-PSK olyan kis méretû hálózatok esetében megfelelõ, ahol a hitelesítést elvégzõ szerver használata nem lehetséges vagy nem oldható meg. Mindig igyekezzünk erõs jelszavakat használni, melyek kellõen hosszúak és sokféle karaktert tartalmaznak, és így nehezebben fejthetõek meg vagy törhetõek fel. Elõször az /etc/wpa_supplicant.conf állományban állítsuk be az SSID-t és a hálózatunkhoz tartozó elõre megosztott kulcsot: network={ ssid="freebsdap" psk="freebsdmall" } Ezután az /etc/rc.conf állományban jelezzük, hogy a vezeték nélküli eszközt a WPA segítségével állítjuk be és az IP-címet a DHCP szervertõl kérjük el: wlans_ath0="wlan0" ifconfig_ath0="WPA DHCP" Innentõl már fel is tudjuk éleszteni a felületet: &prompt.root; /etc/rc.d/netif start Starting wpa_supplicant. DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 5 DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 6 DHCPOFFER from 192.168.0.1 DHCPREQUEST on wlan0 to 255.255.255.255 port 67 DHCPACK from 192.168.0.1 bound to 192.168.0.254 -- renewal in 300 seconds. wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 ether 00:11:95:d5:43:62 inet 192.168.0.254 netmask 0xffffff00 broadcast 192.168.0.255 media: IEEE 802.11 Wireless Ethernet autoselect OFDM/36Mbps mode 11g status: associated ssid freebsdap channel 1 (2412 Mhz 11g) bssid 00:11:95:c3:0d:ac country US ecm authmode WPA2/802.11i privacy ON deftxkey UNDEF AES-CCM 3:128-bit txpower 21.5 bmiss 7 scanvalid 450 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS wme burst roaming MANUAL Kézzel is megpróbálhatjuk elindítani az elõbb elkészített /etc/wpa_supplicant.conf állomány használatával: &prompt.root; wpa_supplicant -i wlan0 -c /etc/wpa_supplicant.conf Trying to associate with 00:11:95:c3:0d:ac (SSID='freebsdap' freq=2412 MHz) Associated with 00:11:95:c3:0d:ac WPA: Key negotiation completed with 00:11:95:c3:0d:ac [PTK=CCMP GTK=CCMP] CTRL-EVENT-CONNECTED - Connection to 00:11:95:c3:0d:ac completed (auth) [id=0 id_str=] A következõ parancs a dhclient indítása legyen, amivel megszerezzük a DHCP szervertõl az IP-címünket: &prompt.root; dhclient wlan0 DHCPREQUEST on wlan0 to 255.255.255.255 port 67 DHCPACK from 192.168.0.1 bound to 192.168.0.254 -- renewal in 300 seconds. &prompt.root; ifconfig wlan0 ath0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 ether 00:11:95:d5:43:62 inet 192.168.0.254 netmask 0xffffff00 broadcast 192.168.0.255 media: IEEE 802.11 Wireless Ethernet OFDM/36Mbps mode 11g status: associated ssid freebsdap channel 1 (2412 Mhz 11g) bssid 00:11:95:c3:0d:ac country US ecm authmode WPA2/802.11i privacy ON deftxkey UNDEF AES-CCM 3:128-bit txpower 21.5 bmiss 7 scanvalid 450 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS wme burst roaming MANUAL Ha az /etc/rc.conf állományban szerepel a ifconfig_wlan0="DHCP" sor, akkor egyáltalán nem szükséges a dhclient parancs manuális kiadása, mivel a dhclient magától el fog indulni, miután a wpa_supplicant egyeztette a kulcsokat. Amikor a DHCP nem használható, megadhatunk a statikus IP-címet is, miután a wpa_supplicant sikeresen lebonyolította a hitelesítést: &prompt.root; ifconfig wlan0 inet 192.168.0.100 netmask 255.255.255.0 &prompt.root; ifconfig wlan0 ath0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 ether 00:11:95:d5:43:62 inet 192.168.0.100 netmask 0xffffff00 broadcast 192.168.0.255 media: IEEE 802.11 Wireless Ethernet OFDM/36Mbps mode 11g status: associated ssid freebsdap channel 1 (2412 Mhz 11g) bssid 00:11:95:c3:0d:ac country US ecm authmode WPA2/802.11i privacy ON deftxkey UNDEF AES-CCM 3:128-bit txpower 21.5 bmiss 7 scanvalid 450 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS wme burst roaming MANUAL Ha egyáltalán nem használunk DHCP szervert, akkor nekünk kell beállítani az alapértelmezett átjárót és a névszervert is: &prompt.root; route add default alapértelmezett_átjáró &prompt.root; echo "nameserver névszerver" >> /etc/resolv.conf WPA és EAP-TLS A másik mód, ahogy a WPA használható, az a 802.1X hitelesítési szerveren keresztül történik, és ebben az esetben a WPA neve WPA-Enterprise. Ez sokkal biztonságosabb a WPA-Personal elõre kiosztott kulcsaival szemben. A WPA-Enterprise az EAP (Extensible Authentication Protocol, azaz Bõvíthetõ hitelesítési protokoll) használatán alapszik. Az EAP önmaga nem végez titkosítást, mivel úgy alakították ki, hogy magát az EAP protokollt kell egy titkosított járaton keresztül bújtatni. Az EAP hitelesítési módszereinek több típusát is kidolgozták, melyek közül a legismertebbek az EAP-TLS, EAP-TTLS valamint a EAP-PEAP. Az EAP-TLS (EAP szállítási rétegbeli védelemmel) a vezeték nélküli világban egy nagyon jól támogatott hitelesítési protokoll, mivel ez volt az elsõ EAP módszer, amit a Wi-fi szövetség jóváhagyott. Az EAP-TLS mûködéséhez három tanúsítvány kell: egy hitelesítõ hatóságtól (Certificate Authority, CA), egy a hitelesítést végzõ szervertõl és egy a klienstõl. Ezzel az EAP módszerrel mind a hitelesítõ szerver, mind a vezeték nélküli kliens külön képviselik a saját tanúsítványaikat, és ezeket a szervezetünket hitelesítõ hatóság aláírása alapján ellenõrzik. A korábbiaknak megfelelõen a beállításokat szintén az /etc/wpa_supplicant.conf állományon keresztül végezzük el: network={ ssid="freebsdap" proto=RSN key_mgmt=WPA-EAP eap=TLS identity="loader" ca_cert="/etc/certs/cacert.pem" client_cert="/etc/certs/clientcert.pem" private_key="/etc/certs/clientkey.pem" private_key_passwd="freebsdmallclient" } Ez a mezõ adja meg a hálózat nevét (SSID). Itt az RSN (&ieee; 802.11i), vagyis a WPA2 protokollt használjuk. A key_mgmt sor a kulcskezelési protokollt adja meg. A mi esetünkben ez a WPA lesz, EAP hitelesítéssel: WPA-EAP. Ebben a mezõben az EAP módszert nevezzük meg a kapcsolathoz. Az identity mezõ az EAP esetén használt azonosítót tartalmazza. A ca_cert mezõ a hitelesítõ hatóság tanúsítványát tároló állomány elérési útvonalát adja meg. Ezt a szerver tanúsítványának hitelesítéséhez használjuk. A client_cert sor a kliens tanúsítványát tartalmazó állomány elérési útvonalát adja meg. Ennek a vezeték nélküli hálózat minden egyes kliense esetében egyedinek kell lennie. A private_key mezõ a kliens tanúsítvánáynak privát kulcsát tároló állomány elérési útját adja meg. A private_key_passwd mezõ a privát kulcshoz tartozó jelmondatot rögzíti. Az /etc/rc.conf állományba vegyük fel a következõ sorokat: wlans_ath0="wlan0" ifconfig_wlan0="WPA DHCP" A következõ lépés a felület felébresztése lesz az rc.d eszköz segítségével: &prompt.root; /etc/rc.d/netif start Starting wpa_supplicant. DHCPREQUEST on wlan0 to 255.255.255.255 port 67 DHCPREQUEST on wlan0 to 255.255.255.255 port 67 DHCPACK from 192.168.0.20 bound to 192.168.0.254 -- renewal in 300 seconds. wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 ether 00:11:95:d5:43:62 inet 192.168.0.254 netmask 0xffffff00 broadcast 192.168.0.255 media: IEEE 802.11 Wireless Ethernet DS/11Mbps mode 11g status: associated ssid freebsdap channel 1 (2412 Mhz 11g) bssid 00:11:95:c3:0d:ac country US ecm authmode WPA2/802.11i privacy ON deftxkey UNDEF AES-CCM 3:128-bit txpower 21.5 bmiss 7 scanvalid 450 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS wme burst roaming MANUAL Természetesen, ahogy azt már az elõbbiekben is megmutattuk, mindezt manuálisan is el tudjuk végezni a wpa_supplicant és az ifconfig parancsok segítségével. WPA és EAP-TTLS Az EAP-TLS használatakor mind a hitelesítést végzõ szervernek és kliensnek is kell tanúsítvány, azonban az EAP-TTLS ( szállítási rétegbeli védelem EAP tunnelen keresztül) esetében a kliensnél ez elhagyható. Ez a módszer nagyjából olyan, mint amit a webes oldalak csinálnak, ahol a webszerverek egy védett SSL tunnelt képeznek még akkor is, amikor a látogatók nem rendelkeznek kliens oldali tanúsítvánnyal. Az EAP-TTLS egy titkosított TLS tunnelen keresztül védi le a hitelesítési adatok forgalmát. Ezt ismét az /etc/wpa_supplicant.conf állományon keresztül tudjuk beállítani: network={ ssid="freebsdap" proto=RSN key_mgmt=WPA-EAP eap=TTLS identity="test" password="test" ca_cert="/etc/certs/cacert.pem" phase2="auth=MD5" } Ebben a mezõben az EAP módszert állítjuk be a kapcsolathoz. Az identity mezõ a titkosított TLS tunnelen keresztül az EAP hitelesítésnél felhasznált azonosítót adja meg. A password tartalmazza az EAP hitelesítésnél használt jelmondatot. A ca_cert mezõ hivatkozik a hitelesítõ hatóság tanúsítványát tartalmazó állományra. Ez az állomány kell a szerver tanúsítványának ellenõrzéséhez. Ebben a mezõben a titkosított TLS tunnelben használt hitelesítési módszer nevezzük meg. Jelen esetünkben ez az EAP MD5-Challenge használatával. A belsõ hitelesítés fázisát gyakran csak phase2-nak (2. fázisnak) hívják. Mindezek mellett még a következõ sorokat is vegyük fel az /etc/rc.conf állományba: wlans_ath0="wlan0" ifconfig_wlan0="WPA DHCP" Ezután hozzuk mûködésbe a felületet: &prompt.root; /etc/rc.d/netif start Starting wpa_supplicant. DHCPREQUEST on wlan0 to 255.255.255.255 port 67 DHCPREQUEST on wlan0 to 255.255.255.255 port 67 DHCPREQUEST on wlan0 to 255.255.255.255 port 67 DHCPACK from 192.168.0.20 bound to 192.168.0.254 -- renewal in 300 seconds. wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 ether 00:11:95:d5:43:62 inet 192.168.0.254 netmask 0xffffff00 broadcast 192.168.0.255 media: IEEE 802.11 Wireless Ethernet DS/11Mbps mode 11g status: associated ssid freebsdap channel 1 (2412 Mhz 11g) bssid 00:11:95:c3:0d:ac country US ecm authmode WPA2/802.11i privacy ON deftxkey UNDEF AES-CCM 3:128-bit txpower 21.5 bmiss 7 scanvalid 450 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS wme burst roaming MANUAL WPA és EAP-PEAP A PEAP (Védett EAP) az EAP-TTLS egyik alternatívájaként jött létre. A PEAP módszernek két változata van, melyek közül a leggyakoribb a PEAPv0/EAP-MSCHAPv2. A leírás további részében a PEAP elnevezéssel erre az EAP módszerre fogunk hivatkozni. A PEAP az EAP-TLS után a leginkább alkalmazott szabvány, más szóval, ha a hálózatunkban többféle operációs rendszer is megtalálható, akkor az EAP-TLS után valószínûleg a PEAP lesz a másik, amit mindegyik ismerni fog. A PEAP hasonló az EAP-TTLS-hez: szerver oldali tanúsítványokkal hitelesíti a klienseket és titkosított TLS tunnelt hoz létre a kliens és a hitelesítést végzõ szerver között, amivel segíti megóvni a hitelesítési információkat. Biztonság szempontjából az EAP-TTLS és a PEAP között az a különbség, hogy a PEAP hitelesítés a felhasználói nevet titkosítatlanul küldi és csak a jelszó megy át a titkosított TLS tunnelen. Az EAP-TTLS egyaránt a TLS tunnelt használja mind a felhasználói név, mind a jelszó esetében. Az EAP-PEAP beállításait az /etc/wpa_supplicant.conf állományba kell felvenni: network={ ssid="freebsdap" proto=RSN key_mgmt=WPA-EAP eap=PEAP identity="test" password="test" ca_cert="/etc/certs/cacert.pem" phase1="peaplabel=0" phase2="auth=MSCHAPV2" } Ebben a mezõben megadjuk, az EAP módszert használjuk a kapcsolathoz. Az identity mezõ az EAP hitelesítés során a titkosított TLS tunnelben átküldött azonosítót tartalmazza. A password mezõ az EAP hitelesítés során használt jelmondatot definiálja. A ca_cert mezõ a hitelesítõ hatóság tanúsítványát tartalmazó állomány elérési útját adja meg. Ez az állomány kell a szerver tanúsítványának ellenõrzéséhez. Ez a mezõ a hitelesítés elsõ fázisának (vagyis a TLS tunnel) paramétereit tartalmazza. A hitelesítést végzõ szervertõl függõen a hitelesítéshez meg kell adnunk bizonyos címkéket. A legtöbb esetben a címke a kliens oldali EAP titkosítás lesz, amit a peaplabel=0 használatával állítunk be. A részleteket a &man.wpa.supplicant.conf.5; man oldalon olvashatjuk. Ebben a mezõben a titkosított TLS tunnelben alkalmazott hitelesítést protokollt nevezzük meg. A PEAP esetében ez az auth=MSCHAPV2 lesz. A következõket kell még hozzátennünk az /etc/rc.conf állományhoz: wlans_ath0="wlan0" ifconfig_wlan0="WPA DHCP" Ezután már mûködésbe is hozhatjuk a felületet: &prompt.root; /etc/rc.d/netif start Starting wpa_supplicant. DHCPREQUEST on wlan0 to 255.255.255.255 port 67 DHCPREQUEST on wlan0 to 255.255.255.255 port 67 DHCPREQUEST on wlan0 to 255.255.255.255 port 67 DHCPACK from 192.168.0.20 bound to 192.168.0.254 -- renewal in 300 seconds. wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 ether 00:11:95:d5:43:62 inet 192.168.0.254 netmask 0xffffff00 broadcast 192.168.0.255 media: IEEE 802.11 Wireless Ethernet DS/11Mbps mode 11g status: associated ssid freebsdap channel 1 (2412 Mhz 11g) bssid 00:11:95:c3:0d:ac country US ecm authmode WPA2/802.11i privacy ON deftxkey UNDEF AES-CCM 3:128-bit txpower 21.5 bmiss 7 scanvalid 450 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS wme burst roaming MANUAL WEP A WEP (Wired Equivalent Privacy, azaz kábellel egyenértékû titkosság) az eredeti 802.11 szabvány része. Nincs külön hitelesítési mechanizmusa, csupán a hozzáférés-vezérlés egy gyenge formájával találkozhatunk benne, amit azonban könnyen fel lehet törni. A WEP ifconfig parancs használatán keresztül állítható be: &prompt.root; ifconfig wlan0 create wlandev ath0 -&prompt.root; ifconfig wlan0 ssid saját_hálózat wepmode on weptxkey 3 wepkey 3:0x3456789012 \ - inet 192.168.1.100 netmask 255.255.255.0 +&prompt.root; ifconfig wlan0 inet 192.168.1.100 netmask 255.255.255.0 \ + ssid saját_hálózat wepmode on weptxkey 3 wepkey 3:0x3456789012 A weptxkey utal arra, hogy a küldés során WEP kulcsot használunk. Itt most egy harmadik kulcsot használtunk, amelynek egyeznie kell a hozzáférési pont beállításaival. Ha nem tudjuk pontosan, hogy milyen kulcsot használ a hozzáférési pont, akkor próbálkozzunk az 1 érték (vagyis az elsõ kulcs) megadásával. A wepkey után következik a kiválasztott WEP kulcs. index:kulcs alakban kell megadni, és ha itt nem adunk meg indexet, akkor azzal az 1 indexû kulcsot állítjuk be. Úgyis fogalmazhatnánk, hogy az indexet csak olyankor kell megadni, amikor nem az elsõ kulcsot akarjuk használni. A 0x3456789012 értéket a hozzáférési pontnál beállított kulcsra kell beállítani. Ha érdekelnek minket a további részletek, akkor bátran lapozzuk fel az &man.ifconfig.8; parancs man oldalát. A wpa_supplicant segédprogramot is bevonhatjuk a vezeték nélküli felületek WEP alapú használatába. A fenti példát a következõ módon tudjuk leírni az /etc/wpa_supplicant.conf állományban: network={ ssid="sajat_halozat" key_mgmt=NONE wep_key3=3456789012 wep_tx_keyidx=3 } Majd: &prompt.root; wpa_supplicant -i wlan0 -c /etc/wpa_supplicant.conf Trying to associate with 00:13:46:49:41:76 (SSID='dlinkap' freq=2437 MHz) Associated with 00:13:46:49:41:76 Az ad-hoc mûködési mód Az IBSS vagy más néven ad-hoc módot pont-pont típusú kapcsolatok kialakítására tervezték. Például, ha az A és a B gépek között egy ad-hoc típusú hálózatot akarunk létesíteni, akkor egyszerûen csak ki kell választanunk két IP-címet és egy SSID-t. Így állítjuk be az A gépet: - &prompt.root; ifconfig wlan0 create wlandev ath0 -&prompt.root; ifconfig wlan0 ssid freebsdap mediaopt adhoc inet 192.168.0.1 netmask 255.255.255.0 + &prompt.root; ifconfig wlan0 create wlandev ath0 wlanmode adhoc +&prompt.root; ifconfig wlan0 inet 192.168.0.1 netmask 255.255.255.0 ssid freebsdap &prompt.root; ifconfig wlan0 - wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 + wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 ether 00:11:95:c3:0d:ac inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 - media: IEEE 802.11 Wireless Ethernet autoselect <adhoc> (autoselect <adhoc>) - status: associated - ssid freebsdap channel 2 bssid 02:11:95:c3:0d:ac - authmode OPEN privacy OFF txpowmax 36 protmode CTS bintval 100 + media: IEEE 802.11 Wireless Ethernet autoselect mode 11g <adhoc> + status: running + ssid freebsdap channel 2 (2417 MHz) bssid 02:11:95:c3:0d:ac + country US ecm authmode OPEN privacy OFF txpower 21.5 scanvalid 60 + protmode CTS wme burst Az adhoc paraméterrel utalunk arra, hogy a felület most IBSS módban mûködik. A B gépen ezután már képesek vagyunk észlelni az A gépet: - &prompt.root; ifconfig wlan0 up scan - SSID BSSID CHAN RATE S:N INT CAPS - freebsdap 02:11:95:c3:0d:ac 2 54M -90:-96 100 IS + &prompt.root; ifconfig wlan0 create wlandev ath0 wlanmode adhoc + SSID/MESH ID BSSID CHAN RATE S:N INT CAPS + freebsdap 02:11:95:c3:0d:ac 2 54M -64:-96 100 IS WME A kimenetben szereplõ I is megerõsíti, hogy az A gépet ad-hoc módban érjük el. Így már csak a B gépet kell beállítanunk egy másik IP-címmel: - &prompt.root; ifconfig wlan0 create wlandev ath0 -&prompt.root; ifconfig wlan0 ssid freebsdap mediaopt adhoc inet 192.168.0.2 netmask 255.255.255.0 + &prompt.root; ifconfig wlan0 inet 192.168.0.2 netmask 255.255.255.0 ssid freebsdap &prompt.root; ifconfig wlan0 - wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 + wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 ether 00:11:95:d5:43:62 inet 192.168.0.2 netmask 0xffffff00 broadcast 192.168.0.255 - media: IEEE 802.11 Wireless Ethernet autoselect <adhoc> (autoselect <adhoc>) - status: associated - ssid freebsdap channel 2 bssid 02:11:95:c3:0d:ac - authmode OPEN privacy OFF txpowmax 36 protmode CTS bintval 100 + media: IEEE 802.11 Wireless Ethernet autoselect mode 11g <adhoc> + status: running + ssid freebsdap channel 2 (2417 Mhz 11g) bssid 02:11:95:c3:0d:ac + country US ecm authmode OPEN privacy OFF txpower 21.5 scanvalid 60 + protmode CTS wme burst Most már mind az A és mind a B készen áll az adatok cseréjére. - &os; alapú hozzáférési pontok A &os; képes hozzáférési pontként (Access Point, AP) is üzemelni, így nem kell külön hardveres hozzáférési pontot vásárolnunk vagy ad-hoc hálózatot használnunk. Ez különösen akkor hasznos, amikor a &os; gépet egy másik hálózat (például az internet) felé állítottuk be átjárónak. Alapvetõ beállítások Mielõtt nekiállnánk a &os;-s gépünket hozzáférési pontnak beállítani, egy olyan rendszermagra lesz szükségünk, amely tartalmazza a megfelelõ vezeték nélküli támogatást a kártyánkhoz. Emellett az alkalmazni kívánt biztonsági protokollok támogatását is bele kell építenünk. Ennek részleteit lásd a ban. Jelenleg az NDIS meghajtón keresztül használt &windows;-os meghajtók nem teszik lehetõvé hozzáférési pontok kialakítását. Egyedül a vezeték nélküli eszközök natív &os;-s meghajtói ismerik a hozzáférési pont módot. Ahogy betöltöttük a vezeték nélküli hálózatok támogatását, egybõl ellenõrizni is tudjuk, hogy a vezeték nélküli eszközünk használható-e hozzáférési pontként (avagy hostap módban): - &prompt.root; ifconfig ath0 list caps -ath0=783ed0f<WEP,TKIP,AES,AES_CCM,IBSS,HOSTAP,AHDEMO,TXPMGT,SHSLOT,SHPREAMBLE,MONITOR,TKIPMIC,WPA1,WPA2,BURST,WME> + &prompt.root; ifconfig wlan0 create wlandev ath0 +&prompt.root; ifconfig wlan0 list caps +drivercaps=6f85edc1<STA,FF,TURBOP,IBSS,HOSTAP,AHDEMO,TXPMGT,SHSLOT,SHPREAMBLE,MONITOR,MBSS,WPA1,WPA2,BURST,WME,WDS,BGSCAN,TXFRA> +crytocaps=1f<WEP,TKIP,AES,AES_CCM,TKIPMIC> A fenti kimenetben láthatjuk a kártyánk tulajdonságait. A HOSTAP szó arról tanúskodik, hogy a vezeték nélküli kártyánk képes hozzáférési pontként viselkedni. Mellette még a különféle támogatott titkosítási módszerek - is láthatóak: WEP, TKIP, WPA2 stb. Ezekbõl + is láthatóak: WEP, TKIP, AES stb. Ezekbõl az információkból tudjuk kideríteni, hogy a hozzáférési pontunkon milyen titkosítási protokollokat tudunk használni. A vezeték nélküli eszközünket - most már átállíthatjuk - hozzáférési pontnak, amihez megadunk - még egy SSID-t és egy IP-címet: + innentõl már csak hozzáférési + pontnak állíthatjuk át a viruális + hálózati eszköz + létrehozásakor, ezért a korábban + létrehozott eszközt ehhez elõször meg + kell semmisítenünk: + + &prompt.root; ifconfig wlan0 destroy + + Ezzel létrejön a megfelelõ + beállításokkal, majd ezekhez + állítjuk még be a többit: - &prompt.root; ifconfig ath0 ssid freebsdap mode 11g mediaopt hostap inet 192.168.0.1 netmask 255.255.255.0 + &prompt.root; ifconfig wlan0 create wlandev ath0 wlanmode hostap +&prompt.root; ifconfig wlan0 inet 192.168.0.1 netmask 255.255.255.0 ssid freebsdap mode 11g channel 1 Az ifconfig parancs ismételt használatával le is tudjuk kérdezni az - ath0 felület + wlan0 felület állapotát: - &prompt.root; ifconfig ath0 - ath0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 + &prompt.root; ifconfig wlan0 + wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 inet6 fe80::211:95ff:fec3:dac%ath0 prefixlen 64 scopeid 0x4 ether 00:11:95:c3:0d:ac media: IEEE 802.11 Wireless Ethernet autoselect mode 11g <hostap> - status: associated - ssid freebsdap channel 1 bssid 00:11:95:c3:0d:ac - authmode OPEN privacy OFF txpowmax 38 bmiss 7 protmode CTS burst dtimperiod 1 bintval 100 + status: running + ssid freebsdap channel 1 (2412 Mhz) bssid 00:11:95:c3:0d:ac + country US ecm authmode OPEN privacy OFF txpower 21.5 scanvalid 60 + protmode CTS wme burst dtimperiod 1 -dfs A hostap paraméterbõl kiderül, hogy a felület hozzáférési pont módban van. Ha az /etc/rc.conf - állományban megadjuk a következõ sort, - akkor a felület beállítása a - rendszer indításakor magától + állományban megadjuk a következõ + sorokat, akkor a felület beállítása + a rendszer indításakor magától megtörténik: - ifconfig_ath0="ssid freebsdap mode 11g mediaopt hostap inet 192.168.0.1 netmask 255.255.255.0" - + wlans_ath0="wlan0" +create_args_wlan0="wlanmode hostap" +ifconfig_wlan0="inet 192.168.0.1 netmask 255.255.255.0 ssid freebsdap mode 11g channel 1" Hitelesítés vagy titkosítás nélküli hozzáférési pontok Habár a hozzáférési pontok mûködtetése nem javasolt hitelesítés vagy titkosítás nélkül, ebben a módban könnyen meg tudunk gyõzõdni a hozzáférési pontunk használhatóságáról. Ez a típusú konfiguráció ezenkívül még fontos szerepet játszik a klienseken felbukkanó hibák kiszûrésében is. Miután sikerült az elõbbiekben bemutatottak alapján beállítani a hozzáférési pontunkat, egy másik vezeték nélküli géprõl rögtön meg is kezdhetjük a keresését: &prompt.root; ifconfig ath0 up scan -SSID BSSID CHAN RATE S:N INT CAPS -freebsdap 00:11:95:c3:0d:ac 1 54M 22:1 100 ES +SSID/MESH ID BSSID CHAN RATE S:N INT CAPS +freebsdap 00:11:95:c3:0d:ac 1 54M -66:-96 100 ES WME Láthatjuk, hogy a kliens megtalálta a hozzáférési pontot és tudunk is rá kapcsolódni: - &prompt.root; ifconfig ath0 ssid freebsdap inet 192.168.0.2 netmask 255.255.255.0 -&prompt.root; ifconfig ath0 - ath0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 - inet6 fe80::211:95ff:fed5:4362%ath0 prefixlen 64 scopeid 0x1 + &prompt.root; ifconfig wlan0 inet 192.168.0.2 netmask 255.255.255.0 ssid freebsdap +&prompt.root; ifconfig wlan0 + wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 inet 192.168.0.2 netmask 0xffffff00 broadcast 192.168.0.255 - ether 00:11:95:d5:43:62 - media: IEEE 802.11 Wireless Ethernet autoselect (OFDM/54Mbps) + media: IEEE 802.11 Wireless Ethernet OFDM/54Mbps mode 11g status: associated - ssid freebsdap channel 1 bssid 00:11:95:c3:0d:ac - authmode OPEN privacy OFF txpowmax 36 protmode CTS bintval 100 - + ssid freebsdap channel 1 (2412 Mhz 11g) bssid 00:11:95:c3:0d:ac + country US ecm authmode OPEN privacy OFF txpower 21.5 bmiss 7 + scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 + roam:rate 5 protmode CTS wme burst WPA titkosítást használó hozzáférési pontok Ebben a szakaszban a &os;-s hozzáférési pontunkat WPA titkosítással állítjuk be. A WPA és a WPA alapú kliensek beállításának részleteit a ban találjuk. A WPA titkosítást használó hozzáférési pontokon a hostapd démon foglalkozik a kliensek hitelesítésével és a kulcsok kezelésével. A továbbiakban az összes beállítást egy olyan &os;-s gépen végezzük el, amely hozzáférési pontként mûködik. Ahogy sikerült beállítanunk a hozzáférési pont módot, az /etc/rc.conf állományban a következõ sor segítségével könnyen meg tudjuk oldani, hogy az hostapd démon a rendszerrel együtt magától elinduljon: hostapd_enable="YES" Mielõtt megpróbálnánk beállítani a hostapd démont, ne felejtsük el elvégezni a ban említett alapvetõ beállításokat sem. WPA-PSK A WPA-PSK használatát olyan kis méretû hálózatok számára szánják, ahol egy külön hitelesítõ szervert alkalmazása nem lehetséges vagy nem kívánatos. A konfiguráció az /etc/hostapd.conf állományon keresztül történik: - interface=ath0 + interface=wlan0 debug=1 ctrl_interface=/var/run/hostapd ctrl_interface_group=wheel ssid=freebsdap wpa=1 wpa_passphrase=freebsdmall wpa_key_mgmt=WPA-PSK wpa_pairwise=CCMP TKIP Ebben a mezõben jelöljük ki a hozzáférési pontként használt vezeték nélküli felületet. Ebben a mezõben adjuk meg a hostapd futtatása során keletkezõ üzenetek részletességét. A példában szereplõ 1 érték ennek a legkisebb szintjét jelöli. A ctrl_interface mezõ megadja a hostapd által használt könyvtár elérési útvonalát, amiben azokat a tartományokhoz tartozó socketeket tároljuk, amelyeken keresztül olyan programokkal tudunk kommunikálni, mint például a &man.hostapd.cli.8;. Itt az alapértelmezett értéket írtuk be. A ctrl_interface_group sor beállítja azt a csoportot (ez jelen esetben a wheel), amin keresztül a vezérlõfelület (control interface) állományaihoz hozzá tudunk férni. Ebben a mezõben a hálózat nevét állítjuk be. A wpa mezõvel engedélyezzük a WPA használatát és megadjuk, hogy melyik WPA hitelesítési protokollt alkalmazzuk. Az itt szereplõ 1 érték a WPA-PSK hitelesítés állítja be a hozzáférési pont számára. A wpa_passphrase mezõ a WPA hitelesítéshez szükséges ASCII jelmondatot tartalmazza. Lehetõleg mindig erõs jelszavakat használjunk, amelyek kellõen hosszúak és sokféle karaktert tartalmaznak, így nehezebben fejthetõek meg vagy törhetõek fel. A wpa_key_mgmt sor a kulcsok kezelésére használt protokollt definiálja. Ez a mi esetünk most a WPA-PSK. A wpa_pairwise mezõ a hozzáférési pont által elfogadott titkosítási algoritmusokat határozza meg. A példában a TKIP (WPA) és CCMP (WPA2) titkosítást is támogatjuk. A CCMP titkosítás a TKIP egyik alternatívája, és lehetõség szerint használjuk ezt. A TKIP csak olyan állomások esetében javasolt, amelyek nem támogatják a CCMP használatát. A következõ lépés a hostapd elindítása: &prompt.root /etc/rc.d/hostapd forcestart - &prompt.root; ifconfig ath0 - ath0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 2290 + &prompt.root; ifconfig wlan0 + wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 2290 inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 inet6 fe80::211:95ff:fec3:dac%ath0 prefixlen 64 scopeid 0x4 ether 00:11:95:c3:0d:ac media: IEEE 802.11 Wireless Ethernet autoselect mode 11g <hostap> status: associated ssid freebsdap channel 1 bssid 00:11:95:c3:0d:ac authmode WPA2/802.11i privacy MIXED deftxkey 2 TKIP 2:128-bit txpowmax 36 protmode CTS dtimperiod 1 bintval 100 A hozzáférési pont mostantól mûködik, innentõl a kliensek már képesek csatlakozni hozzá, bõvebben lásd a ban. A hozzáférési ponthoz tartozó állomásokat az ifconfig - ath0 list sta paranccsal + wlan0 list sta paranccsal tudjuk listázni. - WEP titkosítást használó hozzáférési pontok A WEP titkosítást nem javasoljuk a hozzáférési pontok esetében, mivel nem tartalmaz semmilyen hitelesítési mechanizmust és könnyen feltörhetõ. Egyes régebbi vezeték nélküli kártyák azonban csak a WEP által nyújtott védelmet ismerik, ezért az ilyenek csak olyan hozzáférési pontokhoz tudnak csatlakozni, amelyek vagy nem használnank hitelesítést és titkosítást, vagy erre a WEP protokollt használják. A vezeték nélküli eszközt tegyük hozzáférési pont módba és állítsuk be neki a megfelelõ SSID-t és IP-címet: - &prompt.root; ifconfig ath0 ssid freebsdap wepmode on weptxkey 3 wepkey 3:0x3456789012 mode 11g mediaopt hostap \ - inet 192.168.0.1 netmask 255.255.255.0 + &prompt.root; ifconfig wlan0 create wlandev ath0 wlanmode hostap +&prompt.root; ifconfig wlan0 inet 192.168.0.1 netmask 255.255.255.0 \ + ssid freebsdap wepmode on weptxkey 3 wepkey 3:0x3456789012 mode 11g A weptxkey beállítás után adjuk meg a küldéshez használt WEP kulcsot. Itt a harmadik kulcsot adtuk meg (vegyük észre, hogy a kulcsok számozása az 1 értékkel kezdõdik). Ez a paramétert az adatok tényleges titkosításához kell megadni. A wepkey a kiválasztott WEP kulcs beállítását jelöli, aminek a formátuma index:kulcs. Ha itt nem adunk meg indexet, akkor automatikusan az elsõ kulcsot állítjuk be. Ezért talán mondanunk sem kell, hogy az indexet csak akkor kell megadni, ha nem az elsõ kulcsot akarjuk használni. - A ath0 felület + A wlan0 felület állapotának megtekintéséhez adjuk ki megint az ifconfig parancsot: - &prompt.root; ifconfig ath0 + &prompt.root; ifconfig wlan0 ath0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 - inet6 fe80::211:95ff:fec3:dac%ath0 prefixlen 64 scopeid 0x4 ether 00:11:95:c3:0d:ac media: IEEE 802.11 Wireless Ethernet autoselect mode 11g <hostap> - status: associated - ssid freebsdap channel 1 bssid 00:11:95:c3:0d:ac - authmode OPEN privacy ON deftxkey 3 wepkey 3:40-bit txpowmax 36 protmode CTS dtimperiod 1 bintval 100 + status: running + ssid freebsdap channel 4 (2427 Mhz) bssid 00:11:95:c3:0d:ac + country US ecm authmode OPEN privacy ON deftxkey 3 wepkey 3:40-bit + txpower 21.5 scanvalid 60 protmode CTS wme burst dtimperiod 1 -dfs Egy másik vezeték nélküli géprõl most már megpróbálhatjuk megkeresni a hozzáférési pontot: - &prompt.root; ifconfig ath0 up scan + &prompt.root; ifconfig wlan0 create wlandev ath0 SSID BSSID CHAN RATE S:N INT CAPS freebsdap 00:11:95:c3:0d:ac 1 54M 22:1 100 EPS Láthatjuk, hogy a kliens megtalálta a hozzáférési pontot, és a megfelelõ paraméterekkel (kulcs stb.) képes kapcsolódni hozzá a ban leírtak + linkend="network-wireless-wep">ban leírtak szerint. A vezetékes és vezeték nélküli hálózatok együttes használata A vezetékes hálózatok általában jobb teljesítményt nyújtanak és megbízhatóbbak, miközben a vezeték nélküli hálózatok pedig nagyobb rugalmasságot és mozgásteret szolgáltatnak. Ezért a hordozható számítógépek tulajdonosaiban felmerülhet az igény, hogy egyszerre mind a kettõt használva, tetszõlegesen és problémamentesen válthassanak a hálózatok között. &os; rendszereken ún. hibatûrõ módon két vagy akár több hálózati interfészt össze tudunk vonni. Ennek köszönhetõen az aktív hálózati kapcsolat megszünésekor rendszerünk önállóan igyekszik mindig a fennmaradó elérhetõ hálózatok közül a leginkább preferáltabbra váltani. A hálózati összeköttetések összefûzésével és a hibatûrés konkrét megvalósításával az ban foglalkozunk, ahol a ban láthatjuk is a vezetékes és vezeték nélküli kapcsolatok együttes használatának beállítását. Hibaelhárítás Ha valamilyen gondunk lenne a vezeték nélküli hálózatok használatával, akad néhány lépés, amivel esetleg fel tudjuk deríteni a hiba okát. Ha nem látjuk a hozzáférési pontot a pásztázás után, ellenõrizzük, hogy a vezeték nélküli eszközt véletlenül nem korlátoztuk-e le bizonyos csatornákra. Ha nem tudunk csatlakozni a hozzáférési ponthoz, akkor egyeztessük vele az állomás egyes paramétereit, beleértve a hitelesítési sémát és a biztonsági protokollokat. Minél jobban egyszerûsítsük le a konfigurációkat. Ha WPA vagy WEP titkosítást használunk, akkor a hozzáférési ponton állítsunk be nyílt hitelesítést és kapcsoljuk ki a titkosítást, majd nézzük meg, hogy így eljut-e hozzánk valamilyen forgalom. Ahogy sikerült csatlakozunk a hozzáférési ponthoz, a biztonsági beállításokat olyan egyszerû eszközökkel próbáljuk meg diagnosztizálni, mint például a &man.ping.8;. A wpa_supplicant segédprogrammal tudunk nyomkövetést végezni. A opció megadásával indítsuk el manuálisan és ellenõrizzük a rendszernaplókat. Vannak alacsonyabb szintû nyomkövetési lehetõségek is. A 802.11 protokollt támogató rétegben is tudunk engedélyezni nyomkövetési üzeneteket a /usr/src/tools/tools/net80211 könyvtárban található wlandebug program segítségével. Például a &prompt.root; wlandebug -i ath0 +scan+auth+debug+assoc net.wlan.0.debug: 0 => 0xc80000<assoc,auth,scan> paranccsal a hozzáférési pontok kereséséhez és a 802.11 protokollon belül a kapcsolat megszervezéséhez szükséges kézfogásokhoz kapcsolódó konzolüzeneteket tudjuk engedélyezni. A 802.11 rétegben rengeteg hasznos statisztikát találhatunk. Mindezeket a wlanstats eszközzel tudjuk kiíratni. Ezeknek a statisztikáknak a 802.11 réteg összes hibáját be kell tudniuk azonosítaniuk. Vigyázzunk azonban, mert az eszközmeghajtókban a 802.11 réteg alatt rejlõ bizonyos hibák ilyenkor nem jelennek meg. Az eszközfüggõ problémák felderítésével kapcsolatban a megfelelõ meghajtó dokumentációját olvassuk át. Amennyiben a fenti tanácsok mentén sem sikerül orvosolnunk a hibát okát, küldjünk egy hibajelentést és mellékeljük hozzá a fentebb tárgyalt eszközök által gyártott kimeneteket. Pav Lucistnik Írta:
pav@FreeBSD.org
 Bluetooth Bluetooth Bevezetés A Bluetooth egy olyan vezeték nélküli technológia, amellyel a 2,4 GHz-es frekvenciatartományban tudunk személyi hálózatokat létrehozni 10 méteren belül. Az ilyen típusú hálózatok általában alkalmi jelleggel keletkeznek különféle hordozható eszközök, mint például mobiltelefonok, kézi számítógépek és laptopok között. Eltérõen más népszerû vezeték nélküli technológiáktól, például a wi-fitõl, a Bluetooth magasabb szintû szolgáltási profilokat is felajánl: FTP-szerû állományszervereket, az állományok áttolását, hang átküldését, soros vonali emulációt és még sok minden mást. A &os;-ben megvalósított Bluetooth protokollkészlet a Netgraph rendszerre építkezik (lásd &man.netgraph.4;). A Bluetooth alapú USB-s hardverzárak széles körét támogatja az &man.ng.ubt.4; meghajtó. A Broadcom BCM2033 chipre épített Bluetooth eszközöket az &man.ubtbcmfw.4; és az &man.ng.ubt.4; meghajtók támogatják. A 3Com Bluetooth PC Card 3CRWB60-A eszközt az &man.ng.bt3c.4; meghajtó támogatja. A soros és UART alapú Bluetooth eszközöket a &man.sio.4;, &man.ng.h4.4; és &man.hcseriald.8; ismeri. Ebben a szakaszban a Bluetooth alapú USB-s hardverzárak használatát mutatjuk be. Az eszköz csatlakoztatása Alapértelmezés szerint a Bluetooth eszközmeghajtók modulként érhetõek el. Az eszköz csatlakoztatása elõtt a megfelelõ meghajtót be kell töltenünk a rendszermagba: &prompt.root; kldload ng_ubt Ha a Bluetooth eszköz már a rendszer indításakor is jelen van, akkor a modult az /boot/loader.conf állományon keresztül is betölthetjük: ng_ubt_load="YES" Dugjuk be az USB-s hardverzárunkat. Az alábbihoz hasonló kimenet fog keletkezni a konzolon (vagy a rendszernaplóban): ubt0: vendor 0x0a12 product 0x0001, rev 1.10/5.25, addr 2 ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2 ubt0: Interface 1 (alt.config 5) endpoints: isoc-in=0x83, isoc-out=0x3, wMaxPacketSize=49, nframes=6, buffer size=294 Az /etc/rc.d/bluetooth szkript fogja végezni a Bluetooth használatához szükséges protokollkészlet elindítását és leállítását. Jó ötlet leállítani az eszköz eltávolítása elõtt, de ha elhagyjuk, (általában) nem okoz végzetes hibát. Az indításkor a következõ kimenetet kapjuk: &prompt.root; /etc/rc.d/bluetooth start ubt0 BD_ADDR: 00:02:72:00:d4:1a Features: 0xff 0xff 0xf 00 00 00 00 00 <3-Slot> <5-Slot> <Encryption> <Slot offset> <Timing accuracy> <Switch> <Hold mode> <Sniff mode> <Park mode> <RSSI> <Channel quality> <SCO link> <HV2 packets> <HV3 packets> <u-law log> <A-law log> <CVSD> <Paging scheme> <Power control> <Transparent SCO data> Max. ACL packet size: 192 bytes Number of ACL packets: 8 Max. SCO packet size: 64 bytes Number of SCO packets: 8 HCI Host Controller Interface (HCI) A Host Controller Interface (HCI) egy parancsfelületet nyújt a mûködési sáv vezérlõjéhez (baseband controller) és az összeköttetések kezelõjéhez (link manager), valamint hozzáférést a hardverállapot és -vezérlõ regiszterekhez. Ez a felület egy egységes módszert szolgáltat a Bluetooth mûködési sávjához tartozó tulajdonságok eléréséhez. Az eszközön üzemelõ HCI réteg a Bluetooth hardverben található HCI firmware-rel vált adatokat és parancsokat. A Host Controller Transport Layer (vagyis a fizikai busz) meghajtója mind a két HCI réteget és a kettejük közti információcserét is elérhetõvé teszi. Az egyes Bluetooth eszközökhöz létrejön egy-egy hci típusú Netgraph-beli csomópont. Ez a HCI csomópont általában a Bluetooth eszközmeghajtó csomópontjához (lefelé) és az L2CAP csomóponthoz (felfelé) csatlakozik. Az összes HCI mûveletet a HCI csomóponton kell elvégezni és nem az eszközmeghajtóhoz tartozón. A HCI csomópont alapértelmezett neve a devicehci. Ezekrõl többet az &man.ng.hci.4; man oldalán tudhatunk meg. Az egyik legáltalánosabb feladat a Bluetooth eszközök esetében a közelben levõ további eszközök felderítése. Ezt a mûveletet tudakozódásnak (inquiry) nevezik. A tudakozódást és az összes többi HCI-hez kapcsolódó mûveletet a &man.hccontrol.8; segédprogrammal tudjuk elvégezni. A lentebb látható példa azt mutatja meg, hogyan tudunk Bluetooth eszközöket keresni egy adott távolságon belül. Az elérhetõ eszközök listáját néhány másodpercen alatt megkapjuk. A távoli azonban eszközök csak akkor fognak válaszolni, ha felderíthetõ (discoverable) módban vannak. &prompt.user; hccontrol -n ubt0hci inquiry Inquiry result, num_responses=1 Inquiry result #0 BD_ADDR: 00:80:37:29:19:a4 Page Scan Rep. Mode: 0x1 Page Scan Period Mode: 00 Page Scan Mode: 00 Class: 52:02:04 Clock offset: 0x78ef Inquiry complete. Status: No error [00] A BD_ADDR a Bluetooth eszköz egyedi címe, hasonló a hálózati kártyák MAC-címéhez. Erre a címre lesz szükség ahhoz, hogy a továbbiakban kommunikálni tudjunk az eszközzel. Emberek számára értelmezhetõ nevet is hozzá tudunk rendelni a BD_ADDR címhez. Az /etc/bluetooth/hosts állomány tartalmazza a Bluetooth eszközökre vonatkozó információkat. A következõ példában azt láthatjuk, hogyan tudunk beszédesebb nevet adni egy távoli eszköznek: &prompt.user; hccontrol -n ubt0hci remote_name_request 00:80:37:29:19:a4 BD_ADDR: 00:80:37:29:19:a4 Name: Pav T39-ese Amikor tudakozódni kezdünk a távoli Bluetooth eszközök jelenléte felõl, a gépünket sajat.gep.nev (ubt0) néven fogják látni. Ez a helyi eszközhöz rendelt név bármikor megváltoztatható. A Bluetooth rendszer lehetõség ad pont-pont (természetesen csak két Bluetooth egység között) vagy pont-multipont típusú kapcsolatok kiépítésére. A pont-multipont kapcsolat esetén a kapcsolaton több Bluetooth eszköz osztozik. A most következõ példában megláthatjuk, hogyan kell az aktív mûködési sávban lekérdezni a helyi eszköz létrejött kapcsolatait: &prompt.user; hccontrol -n ubt0hci read_connection_list Remote BD_ADDR Handle Type Mode Role Encrypt Pending Queue State 00:80:37:29:19:a4 41 ACL 0 MAST NONE 0 0 OPEN A kapcsolat azonosítója (connection handle) akkor hasznos, amikor egy sávbeli kapcsolatot akarunk lezárni. Ezt általában nem kell kézzel megcsinálni. A rendszer magától lezárja az inaktív sávbeli kapcsolatokat. &prompt.root; hccontrol -n ubt0hci disconnect 41 Connection handle: 41 Reason: Connection terminated by local host [0x16] A hccontrol help paranccsal tudjuk lekérdezni az elérhetõ HCI parancsokat. A legtöbb HCI parancs végrehajtásához nem kellenek rendszeradminisztrátori jogosultságok. L2CAP Logical Link Control and Adaptation Protocol (L2CAP) A Logical Link Control and Adaptation Protocol (L2CAP) a kapcsolat-orientált és a kapcsolat nélküli adatszolgáltatásokért felelõs a felsõbb rétegek felé, valamit támogatja a protokollok többszörözését, a darabolást és az összerakást. Az L2CAP a magasabb szintû protokollok és az alkalmazások számára egészen 64 kilobyte méretig lehetõvé teszi az adatcsomagok küldését és fogadását. A L2CAP a csatorna (channel) fogalmára építkezik. A csatorna egy logikai kapcsolatot képvisel a mûködési sávon belüli kapcsolat felett. Mindegyik csatornához egyetlen protokoll kötõdik, egy a többhöz alapon. Több csatorna is tarthozhat ugyanahhoz a protokollhoz, de egy csatornán nem használhatunk több protokollt. A csatornákon keresztül érkezõ L2CAP csomagok ezután a megfelelõ felsõbb rétegbeli protokollokhoz kerülnek. Több csatorna osztozhat ugyanazon a sávbeli kapcsolaton. Minden Bluetooth eszközhöz létrejön egy l2cap típusú Netgraph-csomópont. Az L2CAP csomópont általában egy Bluetooth HCI csomóponthoz (lefelé) és egy Bluetooth sockethez (felfelé) kapcsolódik. Az L2CAP csomópont alapértelmezett neve devicel2cap. Errõl részletesebben az &man.ng.l2cap.4; man oldal világosít fel minket. Ezen a szinten hasznos parancsnak bizonyulhat az &man.l2ping.8;, amivel más eszközöket tudunk pingelni. Elõfordulhat, hogy egyes Bluetooth implementációk nem válaszolnak semmilyen feléjük küldött adatra, így az alábbi példában is szereplõ 0 bytes teljesen normális. &prompt.root; l2ping -a 00:80:37:29:19:a4 0 bytes from 0:80:37:29:19:a4 seq_no=0 time=48.633 ms result=0 0 bytes from 0:80:37:29:19:a4 seq_no=1 time=37.551 ms result=0 0 bytes from 0:80:37:29:19:a4 seq_no=2 time=28.324 ms result=0 0 bytes from 0:80:37:29:19:a4 seq_no=3 time=46.150 ms result=0 Az &man.l2control.8; segédprogram használható az L2CAP csomópontok különbözõ mûveleteinek kivitelezésére. Ebben a példában a helyi eszközhöz tartozó logikai kapcsolatokat (csatornák) és sávokat kérdezzük le: &prompt.user; l2control -a 00:02:72:00:d4:1a read_channel_list L2CAP channels: Remote BD_ADDR SCID/ DCID PSM IMTU/ OMTU State 00:07:e0:00:0b:ca 66/ 64 3 132/ 672 OPEN &prompt.user; l2control -a 00:02:72:00:d4:1a read_connection_list L2CAP connections: Remote BD_ADDR Handle Flags Pending State 00:07:e0:00:0b:ca 41 O 0 OPEN Másik ugyanilyen diagnosztikai eszköz a &man.btsockstat.1;. Ha a viselkedését tekintjük, akkor leginkább a &man.netstat.1; programra hasonlít, de a Bluetooth hálózatban megjelenõ adatszerkezetekkel dolgozik. Az alábbi példa az iménti &man.l2control.8; parancs kimenetében szereplõ logikai kapcsolatokat mutatja: &prompt.user; btsockstat Active L2CAP sockets PCB Recv-Q Send-Q Local address/PSM Foreign address CID State c2afe900 0 0 00:02:72:00:d4:1a/3 00:07:e0:00:0b:ca 66 OPEN Active RFCOMM sessions L2PCB PCB Flag MTU Out-Q DLCs State c2afe900 c2b53380 1 127 0 Yes OPEN Active RFCOMM sockets PCB Recv-Q Send-Q Local address Foreign address Chan DLCI State c2e8bc80 0 250 00:02:72:00:d4:1a 00:07:e0:00:0b:ca 3 6 OPEN RFCOMM Az RFCOMM protokoll Az RFCOMM protokoll a soros portok emulációját valósítja meg az L2CAP protokollon keresztül. A protokoll az ETSI TS 07.10. RFCOMM szabványán alapszik, és egy egyszerû átviteli protokoll, amelyet a 9 tûs RS-232 (EIATIA-232-E) soros portok emulációjára készítettek fel. Az RFCOMM protokoll legfeljebb 60 kapcsolat (RFCOMM csatorna) párhuzamos használatát támogatja két Bluetooth eszköz között. Az RFCOMM számára a teljes kommunikációs útvonal két különbözõ eszközön futó alkalmazást (kommunikációs végpontot) és köztük levõ kommunikációs szegments foglalja magában. Az RFCOMM az adott eszközön a soros portot használó alkalmazások részére készült. A kommunikációs szegmens az egyik eszköztõl a másikig vezetõ Bluetooth alapú összeköttetés (közvetlen kapcsolat). Közvetlen kapcsolat esetén az RFCOMM csak az eszközök közti kapcsolattal foglalkozik, valamint hálózati kapcsolat esetén az eszköz és a modem közti kapcsolattal. Az RFCOMM más konfigurációkat is támogat, például olyan modulokat, amelyek az egyik oldalon a Bluetooth vezeték nélküli technológián keresztül kommunikálnak, míg a másik oldalon egy vonalas felületet nyújtanak. A &os;-ben az RFCOMM protokollt Bluetooth foglalatok rétegében valósították meg. párosítás Az eszközök párosítása Alapértelmezés szerint a Bluetooth kommunikáció nem hitelesítõdik és bármelyik eszköz képes bármelyik másikkal felvenni a kapcsolatot. Egy Bluetooth eszköz (például egy mobiltelefon) egy adott szolgáltatáshoz igényelhet hitelesítést (például betárcsázáshoz). A Bluetooth alapú hitelesítés többnyire PIN kódokkal történik. A PIN kód egy legfeljebb 16 karakterbõl álló ASCII karakterlánc. A felhasználóknak mind a két eszközön ugyanazt a PIN kódot kell megadniuk. Miután megadtuk a PIN kódot, az eszközök létrehoznak hozzájuk egy összekötettésbeli kulcsot (link key). Ezután ezt a kulcsot vagy az eszközökön tároljuk vagy pedig valamilyen tartós tárolón. A következõ alkalommal mind a két eszközt ezt a korábban elkészített kulcsot fogja használni. Ezt az eljárást nevezik párosításnak (pairing). Ha valamelyik eszköz elveszti az össszeköttetés kulcsát, akkor a párosítást meg kell ismételni. A &man.hcsecd.8; démon felelõs az összes Bluetooth alapú hitelesítési kérés lekezeléséért. Az alapértelmezett konfigurációs állománya az /etc/bluetooth/hcsecd.conf. Például így tudjuk benne egy mobiltelefonhoz megadni az 1234 PIN kódot: device { bdaddr 00:80:37:29:19:a4; name "Pav T39-ese"; key nokey; pin "1234"; } Semmilyen korlátozás nincs a PIN kódokra (a méretüktõl eltekintve). Egyes eszközökbe (például a Bluetooth fejhallgatók) elõre rögzített PIN kódot építettek bele. A kapcsoló hatására a &man.hcsecd.8; démont az elõtérben lehet futtatni, így könnyebben láthatjuk mi történik. A távoli eszközt állítsuk be a párosítás elfogadására és kezdeményezzünk felé egy Bluetooth kapcsolatot. A távoli eszköznek erre azt kell válaszolnia, hogy elfogadta a párosítást, majd kérni fogja a PIN kódot. Adjuk meg ugyanazt a PIN kódot, mint amit a hcsecd.conf állományba is beírtunk. Most már a gépünk és a távoli eszköz párban vannak. A párosítást a távoli eszközrõl is kezdeményezhetjük. A &os; 5.5, 6.1 és újabb változataiban az /etc/rc.conf állományba a következõ sort kell felvenni a hcsecd automatikus indításához: hcsecd_enable="YES" Ez pedig a hcsecd démon által generált kimenetre példa: hcsecd[16484]: Got Link_Key_Request event from 'ubt0hci', remote bdaddr 0:80:37:29:19:a4 hcsecd[16484]: Found matching entry, remote bdaddr 0:80:37:29:19:a4, name 'Pav's T39', link key doesn't exist hcsecd[16484]: Sending Link_Key_Negative_Reply to 'ubt0hci' for remote bdaddr 0:80:37:29:19:a4 hcsecd[16484]: Got PIN_Code_Request event from 'ubt0hci', remote bdaddr 0:80:37:29:19:a4 hcsecd[16484]: Found matching entry, remote bdaddr 0:80:37:29:19:a4, name 'Pav's T39', PIN code exists hcsecd[16484]: Sending PIN_Code_Reply to 'ubt0hci' for remote bdaddr 0:80:37:29:19:a4 SDP Service Discovery Protocol (SDP) A Service Discovery Protocol (SDP) segítségével a kliens alkalmazások képes felderíteni, hogy a szerver alkalmazások részérõl milyen szolgáltatások érhetõek el, valamint ezek a szolgáltatások milyen tulajdonságokkal rendelkeznek. A szolgáltatások tulajdonsági közé soroljuk többek között a felajánlott szolgáltatás típusát vagy osztályát, illetve a szolgáltatás kihasználásához szükséges mechanizmusra vagy protokollra vonatkozó információkat. Az SDP az SDP szerver és az SDP kliens közti kommunikációt foglalja magában. A szerver karbantart egy listát azokról a szolgáltatási rekordokról, amelyek a szerverhez tartozó szolgáltatások jellemzõit írják le. Mindegyik ilyen szolgáltatási rekord egyetlen szolgáltatás adatait tartalmazza. A kliensek egy SDP kéréssel ezeket a szolgáltatási rekordokat kérhetik el az SDP szervertõl. Amennyiben a kliens, vagy a hozzá tartozó alkalmazás a szolgáltatás használata mellett dönt, akkor a szolgáltatás használatához a megfelelõ szolgáltató felé nyitnia kell egy külön kapcsolatot. Az SDP csak a szolgáltatások és azok tulajdonságainak felderítéséhez ad segítséget, de semmilyen eszközt nem tartalmaz a felhasználásukra. Általában az SDP kliensek általában valamilyen számunkra kellõ tulajdonság alapján keresnek szolgáltatásokat. Ráadásul adódhatnak olyan alkalmak is, amikor a szolgáltatások elõzetes ismerete nélkül szeretnénk felderíteni a rendelkezésre álló szolgáltatások típusait. A felajánlott szolgáltatások ilyen típusú feldolgozását nevezzük böngészésnek (browsing). Az &man.sdpd.8; Bluetooth SDP szerver és a parancssoros &man.sdpcontrol.8; kliens az alap &os; telepítés része. Az alábbi példában egy SDP böngészési kérést adunk ki: &prompt.user; sdpcontrol -a 00:01:03:fc:6e:ec browse Record Handle: 00000000 Service Class ID List: Service Discovery Server (0x1000) Protocol Descriptor List: L2CAP (0x0100) Protocol specific parameter #1: u/int/uuid16 1 Protocol specific parameter #2: u/int/uuid16 1 Record Handle: 0x00000001 Service Class ID List: Browse Group Descriptor (0x1001) Record Handle: 0x00000002 Service Class ID List: LAN Access Using PPP (0x1102) Protocol Descriptor List: L2CAP (0x0100) RFCOMM (0x0003) Protocol specific parameter #1: u/int8/bool 1 Bluetooth Profile Descriptor List: LAN Access Using PPP (0x1102) ver. 1.0 és így tovább. Mindegyik szolgáltatáshoz hozzátartozik a tulajdonságok egy listája (például RFCOMM csatorna). Lehetséges, hogy szolgáltatástól függõen bizonyos tulajdonságokat kell figyelnünk. Egyes Bluetooth implementációk nem támogatják a szolgáltatások böngészését és ezért egy üres listát adnak vissza. Ebben az esetben egy konkrét szolgáltatásra tudunk rákeresni. A következõ példában az OBEX Object Push (OPUSH) szolgáltatást keressük: &prompt.user; sdpcontrol -a 00:01:03:fc:6e:ec search OPUSH &os; alatt az &man.sdpd.8; szerverrel tudunk szolgáltatásokat felajánlani a Bluetooth klienseknek. A &os; 5.5, 6.1 vagy késõbbi változataiban ehhez a következõ sort kell megadnunk az /etc/rc.conf állományban: sdpd_enable="YES" Ezután az sdpd démon így indítható el: &prompt.root; /etc/rc.d/sdpd start A távoli kliensek részére Bluetooth szolgáltatásokat felajánlani kívánó helyi szerver alkalmazásoknak regisztrálniuk kell magukat a helyi SDP démonnál. Például az egyik ilyen alkalmazás az &man.rfcomm.pppd.8;, és elindítása után regisztrálni fogja a Bluetooth LAN szolgáltatást a helyi SDP démonnál. A helyi SDP szerveren regisztrált szolgáltatásokat a helyi vezérlési csatornán keresztül egy browse kéréssel tudjuk lekérdezni: &prompt.root; sdpcontrol -l browse A betárcsázós hálózati és a PPP hálózati hozzáférési (LAN) profilok A betárcsázós hálózati (Dial-Up Networking, DUN) profil leggyakrabban a modemek és mobiltelefonok között tûnik fel. Ez a profil a következõ forgatókönyveket dolgozza fel: A számítógépünkkel egy mobiltelefont vagy modemet vezeték nélküli modemként használunk, amivel az internethez vagy más hálózatokhoz csatlakozunk betárcsázással. A számítógépünkkel egy mobiltelefonon vagy modemen keresztül fogadunk adathívásokat. A PPP hálózati hozzáférési (LAN) profil a következõ helyezetekben alkalmazható: LAN hozzáférés egyetlen Bluetooth eszközhöz LAN hozzáférés több Bluetooth eszközhöz Két gép összekötése (a soros vonali kapcsolat emulációval PPP-n keresztül) &os; alatt mind a két profilt a &man.ppp.8; és az &man.rfcomm.pppd.8; valósítja meg — egy olyan wrapper eszköz, amely az RFCOMM Bluetooth kapcsolatokat a PPP számára is értelmessé alakítja át. Mielõtt még bármelyik profilt elkezdenénk használni, egy új PPP címkét kell létrehozni az /etc/ppp/ppp.conf állományban. Erre példát az &man.rfcomm.pppd.8; man oldalon találhatunk. A következõ példában az &man.rfcomm.pppd.8; programot fogjuk használni arra, hogy egy RFCOMM típusú kapcsolatot nyissunk a 00:80:37:29:19:a4 címmel rendelkezõ távoli Bluetooth eszköz felé. A tényleges RFCOMM csatorna számát SDP-n keresztül a távoli eszköztõl kapjuk. Az RFCOMM csatorna kézzel is megadható, és ilyen esetekben az &man.rfcomm.pppd.8; nem fog SDP kérést küldeni. A &man.sdpcontrol.8; használatával tudjuk lekérdezni a távoli eszközön létrejött RFCOMM csatornát. &prompt.root; rfcomm_pppd -a 00:80:37:29:19:a4 -c -C dun -l rfcomm-dialup A PPP hálózati elérés (LAN) szolgáltatás beindításához futni kell a &man.sdpd.8; szervernek. A helyi hálózaton keresztül csatlakozó kliensekhez létre kell hozni egy új bejegyzést az /etc/ppp/ppp.conf állományban. Az &man.rfcomm.pppd.8; man oldalon találhatunk erre példákat. Végezetül indítsuk el az RFCOMM PPP szervert egy érvényes RFCOMM csatornaszámmal. Az RFCOMM PPP szerver ekkor automatikusan regisztrálja a Bluetooth LAN szolgáltatást a helyi SDP démonnál. A következõ példában megmutatjuk, hogyan lehet elindítani egy RFCOMM PPP szervert: &prompt.root; rfcomm_pppd -s -C 7 -l rfcomm-server OBEX Az OBEX Object Push (OPUSH) profil Az OBEX egy széles körben alkalmazott protokoll a mobileszközök közti egyszerû állományvitelre. Legfõképpen az infravörös kommunikációban alkalmazzák, ahol a laptopok vagy PDA-k közti általános állományátvitelre használják, illetve névjegykártyák vagy naptárbejegyzések átküldésére mobiltelefonok között és egyéb PIM alkalmazást futtató eszközök esetében. Az OBEX szervert és klienst egy külsõ csomag, az obexapp valósítja meg, amelyet az comms/obexapp portból érhetünk el. Az OBEX kliens használható objektumok áttolására vagy lehúzására az OBEX szerverhez. Ez az objektum lehet például egy névjegykártya vagy egy megbeszélt találkozó. Az OBEX kliens SDP-n keresztül tud magának RFCOMM csatornaszámot szerezni. Ezt úgy tehetjük meg, ha a szolgáltatás neve helyett egy RFCOMM csatorna számát adjuk meg. A támogatott szolgáltatások: IrMC, FTRN és OPUSH. Számként RFCOMM csatorna is megadható. Az alábbi példában egy OBEX munkamenetet láthatunk, ahol az eszköz információs objektumát húzzuk le a mobiltelefonról és egy új objektumot (egy névjegykártyát) tolunk fel a telefon könyvtárába. &prompt.user; obexapp -a 00:80:37:29:19:a4 -C IrMC obex> get telecom/devinfo.txt devinfo-t39.txt Success, response: OK, Success (0x20) obex> put new.vcf Success, response: OK, Success (0x20) obex> di Success, response: OK, Success (0x20) Az OBEX objektumok tologatásának támogatásához az &man.sdpd.8; szervernek kell futnia. Továbbá a beérkezõ objektumok tárolásához létre kell hoznunk még egy könyvtárat is. Ez az könyvtár alapértelmezés szerint a /var/spool/obex. Végül indítsuk el az OBEX szervert egy érvényes RFCOMM csatorna számának megadásával. Az OBEX szerver ezután automatikusan regisztrálja az OBEX Object Push nevû szolgáltatást a helyi SDP démonnál. Ebben a példában láthatjuk az OBEX szerver indítását: &prompt.root; obexapp -s -C 10 Soros vonali profil (SPP) A soros vonali profil (Serial Port Profile, SPP) használatával RS232 (vagy ahhoz hasonló) vonali adatátvitelt tudunk emulálni. Ez a profil a régebben fejlesztett alkalmazásokkal birkózik meg, és a Bluetooth technológiával valódi kábel helyett egy virtuális soros portot képez le. Az &man.rfcomm.sppd.1; segédprogram ezt a soros vonali profilt valósítja meg. Így egy pszeudo terminált tudunk virtuális soros portként használni. Ha nem adunk meg RFCOMM csatornát, akkor az &man.rfcomm.sppd.1; képes SDP-n keresztül kérni egyet magának a távoli eszköztõl. Ha ezt felül kívánjuk bírálni, akkor a parancssorban megadhatunk akár egy konkrét RFCOMM csatornát is. &prompt.root; rfcomm_sppd -a 00:07:E0:00:0B:CA -t /dev/ttyp6 rfcomm_sppd[94692]: Starting on /dev/ttyp6... Miután csatlakoztunk, a pszeudo terminált tudjuk soros portként használni: &prompt.root; cu -l ttyp6 Hibaelhárítás Nem tudunk csatlakozni a távoli eszközzel Egyes Bluetooth eszközök nem támogatják a szerepek cseréjét (role switch). Alapértelmezés szerint amikor a &os; elfogad egy új kapcsolatot, megpróbál rajta szerepet cserélni és mesterré válni. Azok az eszközök, amelyek ezt nem támogatják, nem lesznek képesek emiatt csatlakozni. Ez a szerepváltás az új kapcsolatok felépítése során zajlik le, ezért egy távoli eszköztõl nem lehet megtudni, hogy ismeri-e ezt a lehetõséget. A helyi oldalon a következõ HCI opcióval lehet kikapcsolni a szerepcserét: &prompt.root; hccontrol -n ubt0hci write_node_role_switch 0 Valami nem megy. Lehet látni valahogy, pontosan mi is történik? Persze, igen. Egy külsõ csomag, a hcidump segítségével, amely a comms/hcidump portból érhetõ el. A hcidump segédprogram a &man.tcpdump.1; programhoz hasonlítható. Ezzel lehet a Bluetooth csomagok tartalmát megnézni a terminálon vagy elmenteni ezeket egy állományba. Andrew Thompson Írta: Hálózati hidak Bevezetés IP-alhálózat hálózati híd Gyakran hasznos lehet anélkül felosztani egy fizikai hálózatot (például egy Ethernet szegmenst) két külön hálózati szegmensre, hogy külön IP-alhálózatot kellene létrehozunk és összekötnünk ezeket egy útválasztóval. A két ilyen módon kialakított hálózatot összekötõ eszközt nevezzük hálózati hídnak (bridge). A legalább két hálózati felülettel rendelkezõ &os; rendszerek képesek hálózati híd szerepét betölteni. A hálózati híd az eszközök adatkapcsolati rétegben a hozzá tartozó felületein megjelenõ (vagyis Ethernet) címének megtanulásával mûködik. A két hálózat között csak akkor közvetít forgalmat, amikor a forrás és cél nem ugyanabban a hálózatban található. A hálózati hidak bizonyos szempontból lényegében nagyon kevés porttal rendelkezõ Ethernet switch-ek. A hálózati hidak tipikus alkalmazásai Napjainkban akad néhány igen jellemzõ szituáció, ahol szükség van a hálózati hidak alkalmazására. Hálózatok összekötése A hálózati hidak alapvetõ feladata két vagy több hálózati szegmens összekötése. Az egyszerû hálózati környezet felállítása helyett több okból is felmerülhet a hidak létrehozása: kábelezési megszorítások, tûzfalazás vagy pszeudo hálózatok, például virtuális gépek felületének csatlakoztatása miatt. Egy híd használatával ráadásul össze tudunk kötni egy vezeték nélküli hozzáférési pontként üzemelõ felületet egy vezetékes hálózattal. Szûrés vagy forgalomkorlátozás tûzfallal tûzfal NAT Sokszor elõfordulhat, hogy útválasztás vagy hálózati címfordítás (NAT) nélkül szeretnénk tûzfalat használni. Példaként képzeljünk el egy olyan kis méretû céget, amely egy DSL vagy ISDN vonalon kapcsolódik az internet-szolgáltatójához. A szolgáltatótól 13, mindenki által használható IP-címet kaptak és a hálózatukban 10 gép van. Ebben a helyzetben egy útválasztást végzõ tûzfal mûködtetése nehézkessé válna az alhálózatok problémái miatt. útválasztó DSL ISDN Egy hídként viselkedõ tûzfallal azonban minden IP számozási probléma nélkül egyszerûen be tudjuk dobni a gépeket a DSL/ISDN útválasztó mögé. A hálózat megcsapolása Egy hálózati híddal úgy kapcsolunk össze két hálózati szegmenst, hogy közben meg tudjuk vizsgálni a kettejük között mozgó Ethernet kereteket. Ezt a híd felületen a &man.bpf.4; valamint a &man.tcpdump.1; segítségével tudjuk megoldani, vagy úgy, ha egy másik felületen elküldjük az összes keret másolatát (span, vagyis feszítõ port). VPN az adatkapcsolati rétegben A két Ethernet hálózatot egy IP alapú összeköttetésen keresztül is össze tudunk kötni, ha a hálózatokat egy EtherIP járaton keresztül kötjük össze híddal, vagy egy OpenVPN-hez hasonló &man.tap.4; alapú megoldással. Redundancia az adatkapcsolati rétegben A hálózatokat több linken keresztül kötjük össze és a redundáns útvonalakat a feszítõfa protokollal (Spanning Tree Protocol, STP). Az Ethernetes hálózatok esetében a megfelelõ mûködéshez a két eszköz között csak egyetlen aktív útvonal létezhet, így a feszítõfa protokoll észleli a hurkokat és a redundáns összeköttetéseket blokkolt állapotba teszi. Amikor azonban az aktív linkek egyike meghibásodik, akkor a protokoll újraszámolja a fát és a hálózati pontjai közti konnektivitást megpróbálja helyreállítani az addig blokkolt linkek ismételt engedélyezésével. A rendszermag beállításai Ebben a szakaszban az &man.if.bridge.4; hálózati híd implementációval foglalkozunk, de a Netgraph segítségével is tudunk hidakat építeni. Ez utóbbiról az &man.ng.bridge.4; man oldalon olvashatunk. Amikor létrehozunk egy hálózati hidat, az &man.ifconfig.8; automatikusan betölti a hozzá tartozó meghajtót. Ha viszont a rendszermag beállításait tartalmazó állományba felvesszük a device if_bridge sort, akkor akár be is építhetjük a rendszermagba. A csomagszûrés minden olyan tûzfallal használható, amely a &man.pfil.9; rendszerre kapcsolódik. Maga a tûzfal is betölthetõ modulként, vagy belefordítható a rendszermagba. A hálózati híddal forgalmat is tudunk szabályozni az &man.altq.4; vagy a &man.dummynet.4; segítségével. A hálózati híd engedélyezése Hálózati hidak felületek klónozásával hozhatóak létre. A híd létrehozásához használjuk az &man.ifconfig.8; programot, és a megfelelõ meghajtó automatikusan betöltõdik, ha nem lenne még elérhetõ a rendszermagban. &prompt.root; ifconfig bridge create bridge0 &prompt.root; ifconfig bridge0 bridge0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500 ether 96:3d:4b:f1:79:7a id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 0 ifcost 0 port 0 Ekkor létrejön a hálózati hídhoz tartozó felület és véletlenszerûen generálódik hozzá egy Ethernetes cím. A maxaddr és a timeout paraméterek vezérlik, hogy a híd mennyi MAC-címet tartson meg a keretek továbbításáért felelõs táblázatban és mennyi másodperc után töröljön automatikusan egy bejegyzést a legutolsó használat után. A többi paraméter a feszítõfa mûködését irányítja. Vegyük fel a hídhoz tartozó hálózati tagfelületeket. A híd csak akkor fog a tagfelületek között csomagokat továbbküldeni, amikor a híd és a tagok is up állapotban vannak: &prompt.root; ifconfig bridge0 addm fxp0 addm fxp1 up &prompt.root; ifconfig fxp0 up &prompt.root; ifconfig fxp1 up A híd most már átküldi az Ethernet kereteket a fxp0 és fxp1 felületek között. Az iméntiekkel megegyezõ konfigurációt az /etc/rc.conf állományban így alakíthatjuk ki: cloned_interfaces="bridge0" ifconfig_bridge0="addm fxp0 addm fxp1 up" ifconfig_fxp0="up" ifconfig_fxp1="up" Ha a hídhoz IP-címet is rendelni akarunk, akkor inkább magánál a hídnál adjuk meg, ne a tagoknál. Ezt statikusan vagy DHCP használatával is megtehetjük: &prompt.root; ifconfig bridge0 inet 192.168.0.1/24 A hídhoz IPv6 címet is hozzá tudunk rendelni. Tûzfalazás tûzfalak Ha engedélyezzük a csomagszûrést, a hídon áthaladó csomagok elõször a küldõ felület érkezési oldalára kerülnek, majd a hídra, végül a megfelelõ irányban levõ felület küldési oldalára. Bármelyik fázis letiltható. Amikor a csomagok áramlásának iránya fontos számunkra, akkor jobban járunk, ha nem magára a hídra, hanem csak a tagfelületekre állítjuk be a tûzfalat. A híd számos módosítható beállítással rendelkezik a nem-IP és ARP csomagok átküldésére, valamint arra, hogy az IPFW tûzfal adatkapcsolati réteg szintjén mûködhessen. Az &man.if.bridge.4; man oldal ennek részleteit tárja fel. Feszítõfák A híd meghajtója a gyors feszítõfa protokollt (Rapid Spanning Tree Protocol, RSTP avagy 802.1w) valósítja meg, ami visszafelé kompatibilis a korábban említett feszítõfa protokollal. A feszítõfákat a hálózati topológiában felbukkanó hurkok észlelésére és eltávolítására alkalmazzák. Az RSTP azonban a hagyományos STP-nél valamivel gyorsabb konvergenciát ígér, mivel itt a szomszédos switch-ek kicserélik egymás között az adataikat, és így újabb hurkok létrehozása nélkül képesek viszonylag gyorsan egyik állapotból átváltani a másikba. Az alábbi táblázat a támogatott mûködési módokat láthatjuk: Operációs rendszer STP módok Alapértelmezés &os; 5.4—&os; 6.2 STP STP &os; 6.3+ RSTP vagy STP STP &os; 7.0+ RSTP vagy STP RSTP A tagfelületeken az stp paranccsal tudjuk engedélyezni a feszítõfák használatát. Az fxp0 és fxp1 felületeket összekötõ hídfelület esetében tehát így: &prompt.root; ifconfig bridge0 stp fxp0 stp fxp1 bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 ether d6:cf:d5:a0:94:6d id 00:01:02:4b:d4:50 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:01:02:4b:d4:50 priority 32768 ifcost 0 port 0 member: fxp0 flags=1c7<LEARNING,DISCOVER,STP,AUTOEDGE,PTP,AUTOPTP> port 3 priority 128 path cost 200000 proto rstp role designated state forwarding member: fxp1 flags=1c7<LEARNING,DISCOVER,STP,AUTOEDGE,PTP,AUTOPTP> port 4 priority 128 path cost 200000 proto rstp role designated state forwarding Láthatjuk, hogy a híd a feszítõfában megkapta a 00:01:02:4b:d4:50-es azonosítót és a 32768-as prioritást. Mivel root id értéke is ugyanez, elmondhatjuk, hogy ez a fa gyökereként funkcionáló híd. Ha a hálózaton már valahol létezik egy másik híd: bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 ether 96:3d:4b:f1:79:7a id 00:13:d4:9a:06:7a priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:01:02:4b:d4:50 priority 32768 ifcost 400000 port 4 member: fxp0 flags=1c7<LEARNING,DISCOVER,STP,AUTOEDGE,PTP,AUTOPTP> port 4 priority 128 path cost 200000 proto rstp role root state forwarding member: fxp1 flags=1c7<LEARNING,DISCOVER,STP,AUTOEDGE,PTP,AUTOPTP> port 5 priority 128 path cost 200000 proto rstp role designated state forwarding A root id 00:01:02:4b:d4:50 priority 32768 ifcost 400000 port 4 sor mutatja, hogy a fa gyökerét képezõ híd most a 00:01:02:4b:d4:50 azonosítóval rendelkezik, és ezt a hidat 400000-res költséggel éri el a port 4 (a 4. porton) keresztül, amely jelen esetben az fxp0 felület. Komolyabb hidak építése A forgalom áramlásának átszerkesztése A hidak támogatják az ún. megfigyelési módot, ahol a csomagokat a &man.bpf.4; feldolgozásuk után eldobja, így nem folytatódik a feldolgozásuk vagy nem haladnak tovább. Ennek kihasználásával a két vagy több felületen érkezõ adatokat egyetlen &man.bpf.4; folyammá tudjuk alakítani. Ez olyan hálózati csapok forgalmának átszerkesztésében hasznos, ahol a két különbözõ felületen keresztül küldjük ki az RX/TX (fogadás/küldés) jeleket. Az alábbi paranccsal tudjuk megoldani, hogy négy felületrõl érkezõ adatot legyünk képesek egyetlen folyamként olvasni: &prompt.root; ifconfig bridge0 addm fxp0 addm fxp1 addm fxp2 addm fxp3 monitor up &prompt.root; tcpdump -i bridge0 Feszítõ portok A hídhoz befutó Ethernet keretek mindegyikérõl készül egy másolat, ami egy megadott feszítõ porton keresztül megy tovább. Hidanként végtelen számú ilyen feszítõ port létezhet, és ha egy felületet feszítõ portnak adtunk meg, akkor hagyományos portként már nem használhatjuk. Ez leginkább akkor hasznos, amikor passzívan akarjuk megfigyelni a híddal rendelkezõ hálózatot a híd valamelyik feszítõ portjára csatlakozó géprõl. Küldessük az összes keretrõl egy másolatot az fxp4 felületre: &prompt.root; ifconfig bridge0 span fxp4 Privát felületek A privát felületek (private interface) csak más privát felületek felé küldenek tovább adatot. Így feltétel nélkül tudjuk korlátozni a forgalmat, és sem Ethernet keretek, sem pedig ARP nem megy keresztül rajtuk. Ha viszont szelektíven akarjuk korlátozni a forgalmat, akkor helyette használjunk tûzfalat. Tapadós felületek Ha a híd egyik tagfelületét tapadósnak (sticky) adjuk meg, akkor a dinamikusan megtanult címek bejegyzései a gyorsítótárba kerülésük után állandósulnak. A tapadós bejegyzések soha nem évülnek el vagy cserélõdnek le, még abban az esetben sem, ha utána az adott címet egy másik felületrõl látjuk. Így a továbbításra vonatkozó táblázatot nem kell elõre feltöltenünk, és a híd egyik oldalán meglátott kliensek nem képesek átvándorolni egy másik hálózati szegmensbe. Másik ilyen példa a tapadós címek használatára az lehetne, amikor a hidat VLAN-nal kombináljuk, és így egy olyan útválasztót hozunk létre, ahol az ügyfeleink az IP-címtartomány pocséklása nélkül zárhatóak el egymástól. Tegyük fel, hogy az A-ugyfel a vlan100, és a B-ugyfel a vlan101 felületen csatlakozik. A híd IP-címe 192.168.0.1, amely maga is egy internet felé mutató útválasztó. &prompt.root; ifconfig bridge0 addm vlan100 sticky vlan100 addm vlan101 sticky vlan101 &prompt.root; ifconfig bridge0 inet 192.168.0.1/24 Mind a két kliens a 192.168.0.1 címet látja alapértelmezett átjáróként, és mivel a híd gyorsítótára tapadós bejegyzéseket tartalmaz, a MAC-címeik meghamisításával nem tudják elcsípni a másikuk forgalmát. A VLAN-ok közti bárminemû kommunikációt privát felületek létrehozásával akadályozzuk meg (vagy egy tûzfallal): &prompt.root; ifconfig bridge0 private vlan100 private vlan101 Ezzel a megoldással az ügyfeleinket teljesen elszigeteljük egymástól úgy, hogy közben az egész /24 címtartomány külön alhálózatok kialakítása nélkül kiosztható. Címek korlátozása Korlátozhatóak az egy felület mögül küldeni képes egyedi MAC-címek. Amikor ezen a határon felül érkeznek ismeretlen feladótól csomagok, egészen addig eldobjuk ezeket, amíg egy korábban már regisztrált bejegyzést a rendszer ki nem töröl vagy ki nem veszünk a gyorsítótárból. A következõ példában az vlan100 felületen csatlakozó A-ugyfel számára korlátozzuk le 10-re az Ethernet eszközök számát: &prompt.root; ifconfig bridge0 ifmaxaddr vlan100 10 SNMP felügyelet A hidak és az STP paraméterei az alap &os; rendszerben megtalálható SNMP démonnal felügyelhetõek. A hídhoz exportált felügyeleti információk (Management Information Base, MIB) megfelelnek az IETF által elõírt szabványoknak, így akár tetszõleges SNMP kliens vagy bármilyen más felügyeleti szoftver alkalmas az olvasásukra. A hidat mûködtetõ gépen az /etc/snmp.config állományban engedélyezzük a begemotSnmpdModulePath."bridge" = "/usr/lib/snmp_bridge.so" sort és indítsuk el a bsnmpd démont. Itt még szükség lehet más beállítások, például a közösségek nevének (community name) vagy a hozzáférési listák (access list) módosítására is. Ezzel kapcsolatban a &man.bsnmpd.1; és az &man.snmp.bridge.3; man oldalakat lapozzuk fel. A következõ példában a Net-SNMP nevû szoftver (net-mgmt/net-snmp) fogjuk használni a híd elérésére, de ugyanerre a net-mgmt/bsnmptools port is alkalmas. Az SNMP klienst használó gépen egészítsük ki az $HOME/.snmp/snmp.conf állományt a híd felügyeleti információinak importálásával az Net-SNMP rendszerébe: mibdirs +/usr/share/snmp/mibs mibs +BRIDGE-MIB:RSTP-MIB:BEGEMOT-MIB:BEGEMOT-BRIDGE-MIB Az IETF BRIDGE-MIB (RFC 4188) használatán keresztül így tudjuk elindítani egy híd felügyeletét: &prompt.user; snmpwalk -v 2c -c public bridge1.example.com mib-2.dot1dBridge BRIDGE-MIB::dot1dBaseBridgeAddress.0 = STRING: 66:fb:9b:6e:5c:44 BRIDGE-MIB::dot1dBaseNumPorts.0 = INTEGER: 1 ports BRIDGE-MIB::dot1dStpTimeSinceTopologyChange.0 = Timeticks: (189959) 0:31:39.59 centi-seconds BRIDGE-MIB::dot1dStpTopChanges.0 = Counter32: 2 BRIDGE-MIB::dot1dStpDesignatedRoot.0 = Hex-STRING: 80 00 00 01 02 4B D4 50 ... BRIDGE-MIB::dot1dStpPortState.3 = INTEGER: forwarding(5) BRIDGE-MIB::dot1dStpPortEnable.3 = INTEGER: enabled(1) BRIDGE-MIB::dot1dStpPortPathCost.3 = INTEGER: 200000 BRIDGE-MIB::dot1dStpPortDesignatedRoot.3 = Hex-STRING: 80 00 00 01 02 4B D4 50 BRIDGE-MIB::dot1dStpPortDesignatedCost.3 = INTEGER: 0 BRIDGE-MIB::dot1dStpPortDesignatedBridge.3 = Hex-STRING: 80 00 00 01 02 4B D4 50 BRIDGE-MIB::dot1dStpPortDesignatedPort.3 = Hex-STRING: 03 80 BRIDGE-MIB::dot1dStpPortForwardTransitions.3 = Counter32: 1 RSTP-MIB::dot1dStpVersion.0 = INTEGER: rstp(2) A példában látszik, hogy a dot1dStpTopChanges.0 értéke kettõ, ami arra utal, hogy az STP híd topológiája kétszer változott. A topológia változása pedig azt jelenti, hogy a hálózaton belül egy vagy több link állapota megváltozott vagy egyszerûen meghibásodott és ezért egy új fát kellett számolni. A dot1dStpTimeSinceTopologyChange.0 érték adja meg, hogy ez pontosan mikor is történt. Több híd felületének felügyeletéhez a belsõ BEGEMOT-BRIDGE-MIB parancsot is használhatjuk: &prompt.user; snmpwalk -v 2c -c public bridge1.example.com enterprises.fokus.begemot.begemotBridge BEGEMOT-BRIDGE-MIB::begemotBridgeBaseName."bridge0" = STRING: bridge0 BEGEMOT-BRIDGE-MIB::begemotBridgeBaseName."bridge2" = STRING: bridge2 BEGEMOT-BRIDGE-MIB::begemotBridgeBaseAddress."bridge0" = STRING: e:ce:3b:5a:9e:13 BEGEMOT-BRIDGE-MIB::begemotBridgeBaseAddress."bridge2" = STRING: 12:5e:4d:74:d:fc BEGEMOT-BRIDGE-MIB::begemotBridgeBaseNumPorts."bridge0" = INTEGER: 1 BEGEMOT-BRIDGE-MIB::begemotBridgeBaseNumPorts."bridge2" = INTEGER: 1 ... BEGEMOT-BRIDGE-MIB::begemotBridgeStpTimeSinceTopologyChange."bridge0" = Timeticks: (116927) 0:19:29.27 centi-seconds BEGEMOT-BRIDGE-MIB::begemotBridgeStpTimeSinceTopologyChange."bridge2" = Timeticks: (82773) 0:13:47.73 centi-seconds BEGEMOT-BRIDGE-MIB::begemotBridgeStpTopChanges."bridge0" = Counter32: 1 BEGEMOT-BRIDGE-MIB::begemotBridgeStpTopChanges."bridge2" = Counter32: 1 BEGEMOT-BRIDGE-MIB::begemotBridgeStpDesignatedRoot."bridge0" = Hex-STRING: 80 00 00 40 95 30 5E 31 BEGEMOT-BRIDGE-MIB::begemotBridgeStpDesignatedRoot."bridge2" = Hex-STRING: 80 00 00 50 8B B8 C6 A9 Így tudjuk megadni, hogy a hidat mib-2.dot1dBridge részfán keresztül akarjuk megfigyelni: &prompt.user; snmpset -v 2c -c private bridge1.example.com BEGEMOT-BRIDGE-MIB::begemotBridgeDefaultBridgeIf.0 s bridge2 Andrew Thompson Írta: Linkek összefûzése és hibatûrése lagg failover fec lacp loadbalance roundrobin Bevezetés A &man.lagg.4; felület lehetõvé teszi, hogy több hálózati felületet egyetlen virtuális felületként fûzzünk össze, és ezzel egy hibatûrõ és nagysebességû összeköttetést alakítsunk ki. Mûködési módok failover Csak az elsõdlegesként kijelölt porton keresztül fogad és küld adatokat. Amikor ez az elsõdleges port elérhetetlenné válik, a következõ aktív portot fogja használni. Az elsõként felvett felület válik automatikusan az elsõdleges porttá, és az utána felvett összes többit pedig csak hiba esetén használjuk. &cisco; Fast ðerchannel; A &cisco; Fast ðerchannel; (FEC) technológia támogatása. Ez egy statikus beállítás, és nem egyezteti az összefûzést a többiekkel vagy a linkek felügyeletéhez nem vált kereteket. Ha a switch támogatja az LACP használatát, akkor inkább azt válasszuk. A FEC a kimenõ forgalmat a fejlécekben szereplõ protokollok alapján számolt hasítókóddal próbálja szétosztani az aktív portok között, és tetszõleges aktív porton fogad beérkezõ adatokat. Az említett hasítókódban egy Ethernetes forrás- és célcím szerepel, valamint ha elérhetõ, akkor egy VLAN címke, illetve az IPv4/IPv6 forrás- és célcím. LACP Az &ieee; 802.3ad Link Aggregation Control Protocol (LACP) és a Marker Protcol támogatása. Az LACP megpróbálja egyeztetni a többi géppel az összefûzhetõ linkeket egy vagy több csoportban (Link Aggregated Group, LAG). Mindegyik ilyen csoportban ugyanolyan sebességû portokat találunk, full-duplex mûködési módban. A forgalmat így a legnagyobb összsebességgel rendelkezõ csoportban megtalálható portok között osztja el, ami a legtöbb esetben az összes portot magában foglaló csoport. A fizikai konnektivitás megváltozása esetén a linkek összefûzõdése igen gyorsan alkalmazkodik az új konfigurációhoz. Az LACP a kimenõ forgalmat az aktív portok között osztja szét fejlécekben szereplõ protokollok alapján számolt hasítókóddal, és bármelyik aktív portról fogad bejövõ forgalmat. A hasítókódban megtalálható az Ethernetes forrás- és célcím, valamint ha elérhetõ, akkor a VLAN címke, illetve az IPv4/IPv6 forrás- és célcímek. Loadbalance Ez a FEC mód másik neve. Round-Robin A kimenõ forgalmat egy körkörös (Round-Robin) elvû ütemezõvel osztja szét az aktív portok között és tetszõleges aktív portról fogad bejövõ forgalmat. Ez a mûködési mód megsérti az Ethernet keretek rendezését és csak nagy körültekintés mellett alkalmazzuk. Példák LACP alapú összefûzés egy &cisco; switch-csel Ebben a példában egy &os;-s gép két felületét kapcsoljuk össze switch-csel egy egyszerû terhelés-kiegyenlítéssel és hibatûréssel beállított linken keresztül. Mivel az Ethernet keretek sorrendje döntõ fontosságú, ezért a két állomás között egyazon fizikai linken zajló forgalom maximális sebességét az adott felület kapacitása korlátozza. A küldési algoritmus a lehetõ legtöbb információ alapján próbálja egymástól megkülönböztetni a forgalmakat és elosztani ezeket a rendelkezésre álló felületek között. A &cisco; switch-en vegyünk fel a FastEthernet0/1 és FastEthernet0/2 interfészeket az 1 csoportba (channel group): interface FastEthernet0/1 channel-group 1 mode active channel-protocol lacp ! interface FastEthernet0/2 channel-group 1 mode active channel-protocol lacp A &os;-s gépen pedig a fxp0 és fxp1 használatával hozzunk létre a &man.lagg.4; interfészt: &prompt.root; ifconfig lagg0 create &prompt.root; ifconfig lagg0 up laggproto lacp laggport fxp0 laggport fxp1 Ellenõrizzük a felület állapotát: &prompt.root; ifconfig lagg0 A ACTIVE jelzésû, vagyis aktív állapotú portok az összefûzéshez kialakított csoport azon tagjai, amelyeknél felépült a kapcsolat a távoli switch felé és készen állnak a küldésre és fogadásra. Ha az &man.ifconfig.8; programtól részletesebb kimenetet kérünk, akkor láthatjuk a csoportok azonosítóit is: lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=8<VLAN_MTU> ether 00:05:5d:71:8d:b8 media: Ethernet autoselect status: active laggproto lacp laggport: fxp1 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING> laggport: fxp0 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING> A show lacp neighbor paranccsal kérdezhetjük le a portok állapotát: switch# show lacp neighbor Flags: S - Device is requesting Slow LACPDUs F - Device is requesting Fast LACPDUs A - Device is in Active mode P - Device is in Passive mode Channel group 1 neighbors Partner's information: LACP port Oper Port Port Port Flags Priority Dev ID Age Key Number State Fa0/1 SA 32768 0005.5d71.8db8 29s 0x146 0x3 0x3D Fa0/2 SA 32768 0005.5d71.8db8 29s 0x146 0x4 0x3D Részletesebb kijelzést a show lacp neighbor detail paranccsal kaphatunk. A hibatûrés beállítása A hibatûrési mód arra alkalmas, hogy amikor az elsõdleges porton elvesztjük a kapcsolatot, helyette egy másodlagos interfész használatára tudunk áttérni. Hozzuk létre és állítsuk be a lagg0 interfészt, ahol az fxp0 legyen a fõinterfész, az fxp1 pedig a tartalék interfész: &prompt.root; ifconfig lagg0 create &prompt.root; ifconfig lagg0 up laggproto failover laggport fxp0 laggport fxp1 Az így létrejövõ interfész nagyjából az alábbi lesz, ahol eltérés a MAC-cím és az eszköz neve: &prompt.root; ifconfig lagg0 lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=8<VLAN_MTU> ether 00:05:5d:71:8d:b8 media: Ethernet autoselect status: active laggproto failover laggport: fxp1 flags=0<> laggport: fxp0 flags=5<MASTER,ACTIVE> A forgalom kezdetben az fxp0 felületen keresztül érkezik és távozik. Ha az fxp0 felületen valamiért megszakadna a kapcsolat, helyette az fxp1 lesz az aktív link. Ha késõbb helyreáll a kapcsolat az elsõdleges felületen, akkor újra az lesz aktív link. Hibatûrés beállítása vezetékes és vezeték nélküli hálózatok között Hordozható számítógépek használata esetén általában érdemesebb a vezeték nélküli kapcsolatot másodlagos interfészként beállítani, így csak akkor használja a rendszer, ha vezetékes hálózat nem érhetõ el. A &man.lagg.4; segítségével egyetlen IP-címmel tudjuk használni mind a két interfészt: a teljesítmény és biztonságosság miatt elsõsorban a vezetékes hálózatot használjuk, miközben megmarad a lehetõség az adatok továbbítására a vezeték nélküli kapcsolaton keresztül is. A beállítás során a vezeték nélküli interfész MAC-címét úgy kell módosítanunk, hogy megegyezzen a &man.lagg.4; címével. A &man.lagg.4; interfész a saját MAC-címét az elsõdleges interfésztõl örökli, amely jelen esetünkben a vezetékes interfész lesz. A most következõ példában a vezetékes hálózatunk lesz az elsõdleges interfész (bge0), míg a vezeték nélküli (wlan0) a másodlagos. A wlan0 interfészt az iwn0 interfészbõl hoztuk létre, és a vezetékes kapcsolat MAC-címét állítjuk be neki. Elsõ lépésként tehát le kell kérdeznünk a vezetékes interfész MAC-címét: &prompt.root; ifconfig bge0 bge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=19b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4> ether 00:21:70:da:ae:37 inet6 fe80::221:70ff:feda:ae37%bge0 prefixlen 64 scopeid 0x2 nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> media: Ethernet autoselect (1000baseT <full-duplex>) status: active A bge0 helyett természetesen a saját vezetékes hálózati interfészünket kell megadni, és az ether kezdetû sorban is saját kártyánk MAC-címe fog megjelenni. Ezután már meg is tudjuk változtatni az iwn0 címét: &prompt.root; ifconfig iwn0 ether 00:21:70:da:ae:37 Aktiváljuk a vezeték nélküli interfészt, de ne állítsunk be neki semmilyen IP-címet: &prompt.root; ifconfig wlan0 create wlandev iwn0 ssid wlan_hálózat up Hozzuk létre a &man.lagg.4; interfészt a bge0 mint elsõdleges interfész megadásával, valamint a wlan0 legyen a szükség esetén használható tartalék: &prompt.root; ifconfig lagg0 create &prompt.root; ifconfig lagg0 up laggproto failover laggport bge0 laggport wlan0 Az így létrehozott interfész nagyjából így fog megjelenni, egyedüli fontosabb eltérések a MAC-címek és az eszközök nevei: &prompt.root; ifconfig lagg0 lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=8<VLAN_MTU> ether 00:21:70:da:ae:37 media: Ethernet autoselect status: active laggproto failover laggport: wlan0 flags=0<> laggport: bge0 flags=5<MASTER,ACTIVE> Hogy ne kelljen a rendszer minden egyes indítása után ezt a mûveletet megismételni, vegyük fel a következõ sorokat az /etc/rc.conf állományba: ifconfig_bge0="up" ifconfig_iwn0="ether 00:21:70:da:ae:37" wlans_iwn0="wlan0" ifconfig_wlan0="WPA" cloned_interfaces="lagg0" ifconfig_lagg0="laggproto failover laggport bge0 laggport wlan0 DHCP" Jean-François Dockès Frissítette: Alex Dupre Átdolgozta és javította: Lemez nélküli mûködés lemez nélküli munkaállomás lemez nélküli mûködés A &os; képes hálózaton keresztül elindulni és helyi lemez nélkül egy NFS szerver által megosztott állományrendszer csatlakoztatásával mûködni. Ehhez a szabványos konfigurációs állományok módosításán kívül semmi másra nincs szükségünk. Egy ilyen rendszert viszonylag könnyû beállítani, mivel az összes hozzávaló szinte készen elérhetõ: Rögtön adott legalább két módszer, ha a rendszermagot hálózaton keresztül akarjuk betölteni: PXE: az &intel; által fejlesztett Preboot eXecution Environment (indítás elõtti végrehajtási környezet) nevû rendszer a hálózati kártyákba vagy alaplapokba épített ROM segítségével teszi lehetõvé az intelligens rendszerindítást. A &man.pxeboot.8; man oldalán olvashatunk errõl részletesebben. Az Etherboot port (net/etherboot) olyan ROM-ba programozható kódot készít, amellyel rendszermagokat tudunk hálózaton keresztül betölteni. Ez a kód egyaránt felhasználható egy hálózati rendszerindító PROM beégetéséhez, vagy betölthetõ a helyi floppy (esetleg merev)lemezrõl, illetve &ms-dos; rendszer alól. Elég sok hálózati kártya támogatja ezt a módot. Egy mintaszkript (/usr/share/examples/diskless/clone_root) is próbálja megkönnyíteni a szerveren a munkaállomás rendszerindító állományrendszerének létrehozását és karbantartását. Ezt a szkriptet valószínûleg némileg módosítani kell, de így is sokat segít az elindulásban. Az /etc könyvtárban található szabványos rendszerindításhoz használt állományok, amelyekkel a lemez nélküli indulást lehet detektálni és segíteni. A lapozás, amennyiben szükséges, NFS vagy helyi lemez segítségével oldható meg. Számos módon állíthatunk be egy lemez nélküli munkaállomást. Rengeteg részbõl tevõdik össze, és ezek legtöbbje remekül testreszabható az igényeinknek. A továbbiakban egy teljes rendszer összeállításának lehetséges variációit ismertetjük, különös hangsúlyt fektetünk arra, hogy egyszerûek és a hagyományos &os; indítószkriptekkel kompatibilisek maradjanak. A bemutatandó rendszer a következõ jellemzõkkel bír: A lemez nélküli munkaállomások megosztott / és /usr állományrendszereket használnak. A rendszer indításához használt gyökér állományrendszer a szabvány &os;-s gyökér (ez általában a szerveré), ahol néhány állományt felülírtunk a lemez nélküli mûködéshez vagy azért, mert egyszerûen az adott munkaállomáshoz tartozik. A gyökér azon részeit, amelyeket írhatóvá kívánunk tenni, &man.md.4; alapú állományrendszerekkel lapoljuk felül. Ilyenkor azonban bármilyen rajtuk ejtett változtatás a rendszer újraindításával elveszik. A rendszermagot vagy az Etherboot vagy a PXE használatával küldessük át és töltsük be, mivel egyes helyzetekben ezekre szükség lesz. A bemutatott rendszer nem biztonságos. Helyezzük a hálózatunk egy jól védett részére, és a többi gép ne tekintse megbízhatónak. A szakaszban szereplõ összes információt a &os; 5.2.1-RELEASE változatával teszteltük. Háttérinformációk A lemez nélküli munkaállomások beállítása egyszerre adja magát és könnyen is elvéthetõ. Az elkövetett hibákat olykor számos okból kifolyólag nehéz felismerni. Például: A fordítási idõben megadott beállítások mást eredményeznek futási idõben. A hibaüzenetek gyakran titokzatosak vagy esetleg teljesen el is maradnak. Ezért ha valamennyire tisztában vagyunk a háttérben zajló folyamatokkal, akkor sokkal több eséllyel leszünk képesek megoldani a menet közben felmerülõ problémákat. A rendszernek a sikeres felkapaszkodáshoz több mûveletet is végre kell hajtania: A gépnek szüksége van olyan induló paraméterekhez, mint például az IP-cím, a végrehajtható állomány neve, a szerver neve, a gyökér elérési útja. Ezeket a DHCP vagy a BOOTP protokollok használatával adhatjuk meg. A DHCP a BOOTP kompatibilis kiterjesztése, ezért ugyanazokat a portokat és alapvetõ csomagformátumot alkalmazza. A rendszerüket kizárólag BOOTP használatával is beállíthatjuk. A &man.bootpd.8; szerver az alap &os; rendszer része. A DHCP azonban rengeteg elõnnyel rendelkezik a BOOTP protokollal szemben (áttekinthetõbb konfigurációs állományok, a PXE használatának lehetõsége, illetve sok minden más, ami nem csak a lemez nélküli mûködéshez kellhet), ezért itt alapvetõen egy DHCP alapú konfigurációt mutatunk be, de ahol megoldható, megemlítjük a &man.bootpd.8; esetén alkalmas példákat is. A mintaként szolgáló konfiguráció az ISC DHCP szoftvercsomagot használja (a tesztszerverre ennek a 3.0.1.r12 verzióját telepítetük fel). A gépnek egy vagy több programot kell a saját memóriájába áttöltenie. Erre vagy a TFTP vagy pedig az NFS alkalmas. A TFTP és az NFS között sok helyen fordítási idõben tudunk választani. Gyakori hibaforrás a protokollhoz rosszul megadott állománynevek használata: a TFTP általában az összes állományt a szerverrõl egyetlen könyvtárból tölti át, ezért arra számít, hogy a neveiket ehhez viszonyítva adjuk meg. Az NFS használata során azonban abszolút elérési utakat kell megadnunk. A rendszer indítását lehetõvé tevõ közbensõ programokat és a rendszermagot valahogy inicializálni kell és elindítani. Ezen a területen több fontos változat kapott helyet: A PXE a &man.pxeboot.8; kódját fogja betölteni, ez lényegében a &os; betöltõ harmadik fokozatának egy módosított változata. A &man.loader.8; a mûködéséhez szükséges paramétereket a rendszer indításakor kapja meg, majd a vezérlés átadása elõtt ezeket a rendszermag környezetében hagyja. Ebben az esetben akár a GENERIC rendszermag is használható. Az Etherboot kevesebb elõkészítéssel közvetlenül magát a rendszermagot tölti be. Ehhez azonban egy saját rendszermagot kell építeni, külön beállításokkal. A PXE és az Etherboot egyaránt jól használható. Mivel azonban a rendszermagok általában a &man.loader.8; kódjára hagyják a munka legnagyobb részét, ezért ahol lehetséges, a PXE megoldását érdemes alkalmazni. Tehát ha az alaplapi BIOS és a hálózati kártya is támogatja a PXE használatát, akkor válasszunk inkább azt. Végezetül a gépnek valamilyen módon hozzá kell tudnia férnie az állományrendszerekhez. Erre többnyire az NFS jöhet szóba. A további részleket lásd a &man.diskless.8; man oldalon. Beállítási útmutató Beállítás a <application>ISC DHCP</application> használatával DHCP lemez nélküli mûködés Az ISC DHCP szervere képes a BOOTP és DHCP kéréseket is megválaszolni. Az ISC DHCP 3.0 nem az alaprendszer része, ezért a használatához elõször telepítenünk kell a net/isc-dhcp30-server portot vagy a neki megfelelõ csomagot. Ahogy feltelepítettük, le kell futtatnunk az ISC DHCP konfigurációs állományát (ezt általában /usr/local/etc/dhcpd.conf néven találjuk meg). A most következõ, megjegyzésekkel kiegészített példában egy margaux nevû gép az Etherboot, valamint egy corbieres nevû gép PXE használatával akar kapcsolódni: default-lease-time 600; max-lease-time 7200; authoritative; option domain-name "minta.com"; option domain-name-servers 192.168.4.1; option routers 192.168.4.1; subnet 192.168.4.0 netmask 255.255.255.0 { use-host-decl-names on; option subnet-mask 255.255.255.0; option broadcast-address 192.168.4.255; host margaux { hardware ethernet 01:23:45:67:89:ab; fixed-address margaux.minta.com; next-server 192.168.4.4; filename "/data/misc/kernel.diskless"; option root-path "192.168.4.4:/data/misc/diskless"; } host corbieres { hardware ethernet 00:02:b3:27:62:df; fixed-address corbieres.minta.com; next-server 192.168.4.4; filename "pxeboot"; option root-path "192.168.4.4:/data/misc/diskless"; } } Ez a beállítás arra utasítja a dhcpd démont, hogy a lemez nélküli gép hálózati neveként a host deklarációban megadott értéket küldje el. Ezt úgyis meg lehet csinálni, hogy felvesszünk egy option host-name margaux részt a host deklarációk közé. A next-server direktíva a betöltõ vagy a rendszermag betöltéséért felelõs TFTP vagy NFS szervert jelöli ki (alapértelmezés szerint ez megegyezik a DHCP szerverrel). A filename direktíva azt az állományt adja meg, amelyet az Etherboot vagy a PXE a következõ végrehajtási lépésben betölt. Ezt a kiválasztott átviteli módnak megfelelõen kell megadni. Az Etherboot lefordítható az NFS vagy a TFTP használatával is. A &os; port alapból az NFS támogatását tartalmazza. A PXE a TFTP protokollt használja, ezért itt relatív állományneveket adunk meg (ez persze a TFTP szerver beállításaitól függ, de általában ez a jellemzõ). Sõt, a PXE a pxeboot állományt tölti be, nem is a rendszermagot. Léteznek további érdekes lehetõségek is, mint például a pxeboot állomány betöltése a &os; CD-jén található /boot könyvtárból (mivel a &man.pxeboot.8; a GENERIC rendszermagot képes betölteni, ezért a PXE használatával akár egy távoli CD-meghajtóról is indíthatjuk a rendszert). A root-path opció a rendszer indításához használt gyökér állományrendszert nevezi meg, amelyet többnyire az NFS jelölési módszere szerint kell megadni. A PXE használata során el lehet hagyni a gép IP-címét egészen addig, amíg nem engedélyezzük a rendszermagban a BOOTP beállítást. Az NFS szerver ekkor megegyzik a TFTP szerverrel. Beállítás a BOOTP használatával BOOTP lemez nélküli mûködés Itt a bootpd (egyetlen kliensre korlátozott) beállítását láthatjuk. Ezt az /etc/bootptab állományba tegyük. Ne feledjük, hogy a BOOTP használatához az Etherboot portot a NO_DHCP_SUPPORT beállítással kell fordítanunk, miközben a PXE esetében kell a DHCP. Egyébként a bootpd egyedüli nyilvánvaló elõnye csupán annyi, hogy az alaprendszer része. .def100:\ :hn:ht=1:sa=192.168.4.4:vm=rfc1048:\ :sm=255.255.255.0:\ :ds=192.168.4.1:\ :gw=192.168.4.1:\ :hd="/tftpboot":\ :bf="/kernel.diskless":\ :rp="192.168.4.4:/data/misc/diskless": margaux:ha=0123456789ab:tc=.def100 A rendszer elõkészítése az <application>Etherboot</application> számára Etherboot Az Etherboot honlapján találhatunk egy minden részletre kiterjedõ dokumentációt (angolul), amely elsõsorban ugyan a Linux típusú rendszerek számára íródott, de ettõl függetlenül még hasznos információkat tartalmaz. A továbbiakban csak annyit szeretnénk körvonalazni, hogy az Etherboot miként bírható mûködésre &os; rendszerekkel. Elõször telepítenünk kell a net/etherboot csomagot vagy portot. Az Etherboot beállítását (vagyis a TFTP használatának megadását az NFS helyett) az Etherboot forrását tartalmazó könyvtárban található Config állomány megfelelõ átírásával tudjuk megtenni. Itt most floppyról fogjuk indítani a rendszert. A többi módszerrel (PROM vagy &ms-dos; program) kapcsolatban olvassuk el az Etherboot dokumentációját. A rendszerindító lemez elkészítéséhez tegyünk egy lemezt annak a gépnek a meghajtójába, ahová az Etherboot felkerült. Váltsunk az Etherboot könyvtárán belül az src alkönyvtárba és gépeljük be: &prompt.root; gmake bin32/eszköztípus.fd0 Az eszköztípus a lemez nélküli munkaállomás Ethernet kártyájától függ. Az ugyanebben a könyvtárban található NIC állományból tudjuk kiolvasni, hogy az adott kártyához melyik eszköztípus tartozik. A rendszer indítása <acronym>PXE</acronym> használatával Alapértelmezés szerint a &man.pxeboot.8; betöltõ a rendszermagot NFS-en keresztül tölti be. Ha az /etc/make.conf állományban a LOADER_TFTP_SUPPORT beállítást adjuk meg, akkor TFTP támogatással is lefordítható. Ezzel kapcsolatban a /usr/share/examples/etc/make.conf állományban található megjegyzéseket érdemes elolvasnunk. A make.conf állományban még további két másik hasznos opciót is találhatunk a soros vonali konzollal üzemelõ lemez nélküli gépek számára: az egyik a BOOT_PXELDR_PROBE_KEYBOARD, a másik pedig a BOOT_PXELDR_ALWAYS_SERIAL. A gép indításakor úgy tudjuk beüzemelni a PXE használatát, ha a BIOS beállításai között a Boot from network opciót választjuk ki, vagy a gép bekapcsolása után lenyomjuk hozzá a megfelelõ funkcióbillentyût. A <acronym>TFTP</acronym> és <acronym>NFS</acronym> szerverek beállítása TFTP lemez nélküli mûködés NFS lemez nélküli mûködés Ha a PXE vagy az Etherboot a TFTP protokollt használja, akkor az állományszerveren a tftpd démont kell elindítani: Készítsünk egy könyvtárat, ahonnan majd a tftpd küldi az állományokat, például legyen ez a /tftpboot. Vegyük fel a következõ sort az /etc/inetd.conf állományunkba: tftp dgram udp wait root /usr/libexec/tftpd tftpd -l -s /tftpboot A tapasztalat szerint egyes PXE verziók a TFTP TCP alapú változatát használják. Ebben az esetben vegyünk fel még egy második sort is, ahol a dgram udp részt stream tcp-re cseréljük. Mondjuk meg az inetd démonnak, hogy olvassa újra a konfigurációs állományát. Az alábbi parancs megfelelõ mûködéséhez Az sornak szerepelnie kell az /etc/rc.conf állományban: &prompt.root; /etc/rc.d/inetd restart A tftpboot könyvtárat bárhova rakhatjuk a szerveren. Viszont az inetd.conf és dhcpd.conf állományokban ezt ne felejtsük fel megadni. Minden esetben engedélyeznünk kell az NFS használatát és vele együtt exportálni az NFS szerverrõl elérni kívánt állományrendszereket. Az /etc/rc.conf állományba tegyük bele a következõt: nfs_server_enable="YES" Az /etc/exports állományban a lemez nélküli rendszereknek szánt gyökérkönyvtárat tegyük elérhetõvé (a példában írjuk át a kötet csatlakozási pontját és a margaux corbieres helyére állítsuk be a saját lemez nélküli munkaállomásaink neveit: /data/misc -alldirs -ro margaux corbieres Kérjük meg a mountd démont, hogy olvassa újra a konfigurációs állományát. Elõfordulhat azonban, hogy ehhez elõször az NFS szolgáltatást kell engedélyezni az /etc/rc.conf állományból és újraindítani a gépet. &prompt.root; /etc/rc.d/mountd restart Lemez nélküli rendszermag fordítása lemez nélküli mûködés a rendszermag beállításai Ha az Etherboot használata mellett döntünk, akkor a lemez nélküli kliensek számára a rendszermagot a következõ beállítások használatával kell újrafordítani (a megszokottak mellett): options BOOTP # BOOTP-n keresztül kérünk IP-címet és hálózati nevet options BOOTP_NFSROOT # a BOOTP-tõl kapott információk alapján csatoljuk a gyökeret NFS-en keresztül Ezek mellett valószínûleg szükségünk lesz a BOOTP_NFSV3, BOOT_COMPAT és BOOTP_WIRED_TO beállítások megadására is (lásd a NOTES állományt). A beállítások nevei régrõl származnak és némileg félrevezetõek lehetnek, mivel valójában semmit sem változtatnak a rendszermagban levõ DHCP vagy a BOOTP rutinok használatában (egyébként meg lehet adni vagy az egyik vagy a másik protokoll kizárólágos használatát is). Fordítsuk le a rendszermagot (lásd ), és másoljuk a dhcpd.conf állományban megadott helyre. Amikor a PXE protokollt használjuk, a rendszermagot nem fontos az imént felsorolt paraméterekkel fordítanunk (habár ajánlatos). Az engedélyezésükkel több DHCP kérés keletkezik a rendszermag elindulása közben, ezért kisebb a kockázata annak, hogy a &man.pxeboot.8; által bizonyos esetekben megszerzett és az új értékek között valamilyen ellentmondás jön létre. A használatuk egyik elõnye, hogy így mellékhatásként a hálózati nevünket is megkapjuk. Ellenkezõ esetben erre is találnunk kellene valamilyen módot, például fenntartani egy-egy rc.conf állományt minden kliensen. Az Etherboot csak akkor lesz képes betölteni a rendszermagot, ha device hinteket is beépítünk. Ezt a következõ beállítással tudjuk megoldani (errõl bõvebben lásd a NOTES állomány megjegyzéseit): hints "GENERIC.hints" A rendszerindító állományrendszer elõkészítése rendszerindító állományrendszer lemez nélküli mûködés A dhcpd.conf állomány root-path beállításának megfelelõen hozzunk létre a rendszer indítására alkalmas gyökér állományrendszert. Az állományrendszer feltöltése a <command>make world</command> paranccsal Ezzel a módszerrel a DESTDIR könyvtárba pillanatok alatt telepíteni tudunk egy teljes szûz rendszert (és nem csak a rendszerindító állományrendszert). Ehhez mindössze csak annyit kell tenni, hogy lefuttatjuk a következõ szkriptet: #!/bin/sh export DESTDIR=/data/misc/diskless mkdir -p ${DESTDIR} cd /usr/src; make buildworld && make buildkernel make installworld && make installkernel cd /usr/src/etc; make distribution Miután végzett, már csak a DESTDIR könyvtárban található /etc/rc.conf és /etc/fstab állományokat kell az igényeinkhez igazítani. A lapozóterület beállítása Amennyiben szükséges, a szerveren található lapozóállományt NFS-en keresztül el tudjuk érni. Lapozás <acronym>NFS</acronym>-sel A rendszermag maga nem támogatja az NFS alapú lapozás engedélyezését a rendszer indításakor. A lapozóállományt ezért a rendszerindító szkripteken keresztül aktiváljuk, amelyekben csatlakoztatunk egy írható állományrendszert, ahol létrehozzuk és engedélyezzük a lapozóállományt. Tetszõleges méretû lapozóállományt például így tudunk készíteni: &prompt.root; dd if=/dev/zero of=/a/lapozóállomány/helye bs=1k count=1 oseek=100000 Az engedélyezéséhez pedig a következõ sort kell felvenni az rc.conf állományba: swapfile=/a/lapozóállomány/helye Egyéb problémák Írásvédett <filename>/usr</filename> használata lemez nélküli mûködés írásvédett /usr Ha a lemez nélküli munkaállomáson X szervert akarunk futtatni, akkor az XDM konfigurációs állományait kicsit módosítanunk kell, mert alapértelmezés szerint a /usr könyvtárban hozza létre a naplókat. Nem &os;-s szerver használata Amikor a rendszer indításához használt állományrendszert nem egy &os; alapú számítógépen tároljuk, akkor elõször ezt egy &os;-s gépen kell elkészíteni, majd a tar vagy cpio segítségével átmásolni a megfelelõ helyre. Ilyen helyzetekben gyakran gondok adódhatnak olyan speciális állományokkal, mint például amelyek a /dev könyvtárban találhatóak, mivel a fõ- és aleszközazonosítók tárolására szánt méret különbözhet. Ezt úgy oldhatjuk meg, ha exportálunk egy könyvtárat a nem &os; alapú szerveren, ezt csatlakoztatjuk a &os;-s gépen, majd a &man.devfs.5; segítségével a eszközleírókat a felhasználó számára észrevétlen módon foglaljuk le. ISDN ISDN Az ISDN technológiai és hardveres hátterérõl sokat megtudhatunk Dan Kegel ISDN-rõl szóló oldalán (angolul). Az ISDN használatát röviden így foglalhatnánk össze: Ha Európában élünk, akkor minden bizonnyal az ISDN kártyákkal foglalkozó szakaszt érdemes elolvasnunk. Ha elsõsorban betárcsázós ISDN-nel szeretnénk csatlakozni az internetre egy internet-szolgáltatón keresztül, akkor a terminál adaptereket tárgyaló szakaszt nézzük meg. A szolgáltatók váltásakor ezzel jár a legtöbb rugalmasság és a legkevesebb probléma. Ha két helyi hálózat összekötésére használjuk, vagy az internethez egy bérelt ISDN vonalon keresztül kapcsolódunk, akkor egy önálló útválasztó vagy hálózati híd beállításában érdemes gondolkodnunk. A költség fontos szerepet játszik az elfogadható megoldás kiválasztásában. A most következõ lehetõségeket a legolcsóbbtól indulva kezdjük el felsorolni egészen a legdrágábbig. Hellmuth Michaelis Készítette: ISDN kártyák ISDN kártyák A &os;-ben megtalálható ISDN implementáció csak a DSS1/Q.931 (más néven Euro-ISDN) szabvány szerint gyártott passzív kártyákat támogatja. Ismer azonban egyes olyan aktív kártyákat is, amelyeknél a firmware további más jelkezelési protokollokat is támogat. Ilyen többek közt az elsõként támogatott Primary Rate (PRI) ISDN kártya. Az isdn4bsd szoftver segítségével kapcsolódni tudunk más ISDN útválasztókhoz IP-n keresztül a nyers HDLC felett, vagy szinkron PPP használatával. Mindezeket a rendszermagban található PPP-re vagy az isppp-re építkezik. &os; alatt egyre több PC-s ISDN kártyához készül el a támogatás, és a visszajelzések azt mutatják, hogy Európában és a világ minden részén sikerrel használják ezeket. A passzív ISDN kártyák közül is leginkább az Infineon (korábban Siemens) gyártmányú ISAC/HSCX/IPAC ISDN chipkészletek támogatottak, de a Cologne chippel rendelkezõ (de csak ISA buszos) ISDN kártyák, a Winbond W6692 chipes PCI buszos kártyák, és a Tiger300/320/ISAC chipkészletek egyes változatai, valamint néhány gyártófüggõ chipkészlettel rendelkezõ kártya, mint például az AVM Fritz!Card PCI V.1.0 és az AVM Fritz!Card PnP is remekül mûködik. Jelenleg a következõ aktív ISDN kártyákat támogatja a rendszer: AVM B1 (ISA és PCI) BRI kártyák és az AVM T1 PCI PRI kártyák. Az isdn4bsd dokumentációját a rendszerünkön belül a /usr/share/examples/isdn/ könyvtárban találhatjuk meg, vagy közvetlenül az isdn4bsd honlapján, ahol több hivatkozást is találunk tippekre, hibajegyzékekre és bõségesebb dokumentációra, például az isdn4bsd saját kézikönyvére. Ha szeretnénk egy másik ISDN protokoll támogatásának kifejlesztésében résztvenni, vagy egy jelenleg még nem támogatott ISDN kártyát használhatóvá tenni, esetleg valamilyen más módon segíteni az isdn4bsd ügyét, vegyük fel a kapcsolatot &a.hm; fejlesztõvel. Az isdn4bsd telepítésével, beállításával és hibaelhárításával kapcsolatos kérdéseinket a &a.isdn.name; levelezési listán tehetjük fel. ISDN terminál adapterek Az ISDN számára olyanok a terminál adapterek, mint a hagyományos telefonvonalak számára a modemek. modem A legtöbb terminál adapter a Hayes-modemek szabványos AT parancskészletét használja, és könnyen be lehet iktatni egy modem helyett. A terminál adapterek alapvetõen ugyanúgy mûködnek, mint a modemek, kivéve, hogy egy átlagos modemnél jóval nagyobb adatátviteli sebességre képesek. Ezért a PPP kapcsolatunkat pontosan ugyanúgy kell beállítani, mint a modemek esetében. Ne felejtsük a soros pont sebességét a maximális értékre állítani. PPP A terminál adapterek használatának egyik legnagyobb elõnye, hogy segítségükkel dinamikus PPP-n keresztül tudunk az internet-szolgáltatónkhoz kapcsolódni. Mivel az IP-címtartomány egyre inkább szûkösebb, a legtöbb szolgáltató nem szívesen oszt ki bárkinek is statikus IP-címet. A legtöbb önálló útválasztó azonban nem képes alkalmazkodni az IP-címek dinamikus kiosztásához. A terminál adapter az elérhetõ lehetõségeket és a kapcsolat stabilitását tekintve teljesen a PPP démontól függ. Emiatt egy &os;-s gépet könnyû modemrõl átállítani az ISDN használatára, ha már egyszer beállítottuk a PPP démont. Ezzel együtt azonban a PPP használata során tapasztalt problémák ugyanúgy ismét felmerülnek. Ha a maximális stabilitásra van szükségünk, akkor a rendszermag PPP beállítását használjuk, és ne a felhasználói PPP megoldást. A &os; hivatalosan az alábbi terminál adaptereket ismeri: Motorola BitSurfer és Bitsurfer Pro Adtran Valószínûleg a többi terminál adapterrel is képes együttmûködni, mivel a terminál adapterek gyártói általában igyekeznek a termékeiket a szabványos modemes AT parancskészletével kompatibilissá tenni. Az igazi probléma a külsõ terminál adapterekkel adódik, mivel, akárcsak a modemek esetében, egy nagyon jó soros kártyát igényelnek. A soros eszközök mûködésének részleteit valamint az aszinkron és szinkron soros portok közti különbségeket a &os; soros hardverekrõl szóló cikkében olvashatjuk. A terminál adaptereken keresztül elérhetõ sebességet a PC-kben található szabványos (aszinkron) soros port 115,2 Kb/mp-re korlátozza, még 128 Kb/mp-es adatátvitelû kapcsolatok esetében is. Az ISDN által nyújtott 128 Kb/mp kihasználásához a terminál adaptert egy szinkron soros kártyával kell összekötnünk. Ne higyjük, hogy egy belsõ terminál adapter megvásárlásával megmenekülünk ettõl a gondtól. A belsõ terminál adapterekbe egyszerûen csak egy sima szabványos PC-s soros portot építettek bele. Mindössze egy soros kábelt és egy konnektort takarítunk meg velük. A terminál adapterhez csatlakozó szinkron kártyák legalább olyan gyorsak, mint egy önálló útválasztó, és egy egyszerû 386-osra épülõ &os; rendszerrel talán még rugalmasabban is kezelhetõek. A terminál adapter plusz szinkron kártya kontra önálló útválasztó kérdése már hitkérdéssé fajult, amirõl igen sokat vitatkoztak szerte a levelezési listákon. A teljes okfejtés elolvasásához az archívum böngészését javasoljuk. Önálló ISDN hálózati hidak és útválasztók ISDN önálló hálózati hidak és útválasztók Az ISDN hidak vagy útválasztók nem egészen a &os; vagy operációs rendszerek területéhez tartoznak. Az útválasztás és a hálózatok hidak alapjainak a számítógépes hálózatokról szóló szakirodalomban járhatunk utána. Ebben a szakaszban a hálózati híd és az útválasztó kifejezéseket egymás szinonímájaként fogjuk használni. Ahogy az olcsóbb ISDN útválasztók és hidak árai egyre jobban csökkennek, ezért egyre inkább népszerûbbé válnak. Az ISDN útválasztó egy apró doboz, amelyet közvetlenül a helyi Ethernet hálózatunkra tudunk csatlakoztatni, és a többi útválasztóhoz vagy hídhoz kapcsolódik. A benne található szoftverrel képes kommunikálni a PPP vagy más egyéb népszerû protokollokon keresztül. Az útválasztó egy szabványos terminál adapternél sokkal nagyobb adatátvitelt tesz lehetõvé, mivel a teljes szinkron ISDN kapcsolatot képes kihasználni. Az ISDN útválasztókkal és hidakkal kapcsolatban az egyik legnagyobb problémát a különbözõ gyártók közti eltérések jelenthetik. Ha egy szolgáltatóhoz akarunk ezen a módon csatlakozni, akkor érdemes elõzetesen egyeztetni az igényeinket velük. Ha két helyi hálózati szegmenst akarunk összekapcsolni, mint például az otthoni és az irodai hálózatot, akkor ez a megoldás jár a legkevesebb karbantartási költséggel. Mivel ekkor mi magunk vásároljuk a kapcsolat mind a két oldalára a felszerelést, biztosak lehetünk benne, hogy az így létrehozott összekötettés mûködni fog. Például, ha egy otthon vagy a vállalat egy fiókjánál levõ gépet akarjuk összekötni az igazgatóság hálózatával, akkor a következõ felállást érdemes követnünk: Egy otthoni vagy egy fiókbeli hálózat 10 Base 2 A hálózat busz topológiájú és 10 Base 2 Ethernetet használ (thinnet). Ha szükséges, akkor az útválasztót egy AUI/10BT adó-vevõvel csatlakoztassuk a hálózati kábelre. ---Sun munkaállomás | ---&os; | ---Windows 95 | az önálló útválasztó | ISDN BRI vonal 10 Base 2 Ethernet Ha az otthoni vagy fiókbeli számítógép az egyedüli, akkor egy keresztkötésû sodrott érpár kábellel akár közvetlenül is csatlakozhatunk az útválasztóhoz. Az igazgatósági iroda vagy egy másik helyi hálózat 10 Base T A hálózat csillag topológiájú, és 10 Base T Ethernet kábelezésû (sodrott érpár). -------Novell szerver | H | | ---Sun | | | U ---&os; | | | ---Windows 95 | B | |___---az önálló útválasztó | ISDN BRI vonal Az ISDN hálózat felépítése A legtöbb útválasztó/híd elõnye, hogy egyszerre 2 egymástól független PPP kapcsolatot tudunk felépíteni velük 2 egymástól független géppel. Ezt a legtöbb terminál adapter nem támogatja, kivéve azok a (általában drága) típusok, amelyek két soros porttal rendelkeznek. Ezt ne tévesszük össze a csatornák nyalábolásával, az MPP-vel és a többivel. Ez nagyon hasznos lehet például olyan esetekben, amikor van egy dedikált ISDN kapcsolatunk az irodában, amelyet ugyan szeretnénk megcsapolni, de nem szeretnénk a másik ISDN vonalat is elrabolni. Az irodában levõ A útválasztó képes a dedikált B csatornájú kapcsolaton (64 Kb/mp) keresztül elérni az internetet, miközben a másik B csatornát ettõl független adatkapcsolatra használja. A második B csatorna így használható betárcsázásra, kitárcsázásra vagy a másik B csatornával együtt dinamikus nyalábolásra (MPP stb.) a nagyobb sávszélesség elérése érdekében. IPX/SPX Az Ethernetes híd nem IP alapú forgalmat is képes továbbítani, ezért rajta keresztül akár IPX vagy SPX és más egyéb protokollokat is használni tudunk. Chern Lee Írta: Hálózati címfordítás Áttekintés natd A &os; hálózati címfordításért felelõs démonprogramja, a &man.natd.8; (Network Address Translation daemon), a beérkezõ nyers IP csomagokat dolgozza fel, és a helyi gépek forráscímét kicserélve visszailleszti ezeket a csomagokat a kimenõ folyamba. A &man.natd.8; mindezt úgy teszi a forrás IP-címekkel és portokkal, hogy amikor az adat visszaérkezik, akkor képes lesz megmondani a csomag eredeti küldõjét és visszaküldeni neki a választ. internet-kapcsolat megosztása NAT A hálózati címfordítást általában az internet-kapcsolatok megosztásánál alkalmazzuk. A hálózat felépítése Az IPv4 világában egyre jobban fogyó IP-címek és az egyre növekvõ számú, nagysebességre vágyó, például kábeles vagy DSL-es fogyasztók miatt az igény is egyre nagyobb az internet-kapcsolatok megosztására. Ha több számítógéppel szeretnénk egyetlen kapcsolaton és egy IP-címen keresztül kapcsolódni az internetre, akkor ehhez a &man.natd.8; tökéletes választás. Az esetek többségében a felhasználók egy kábeles vagy DSL vonalra csatlakoznak, melyhez egyetlen IP-cím tartozik, és ezen a gépen keresztül szeretnék elérni az internetet a helyi hálózaton levõ többi géprõl. Ezt úgy tudjuk elérni, ha az internethez kapcsolódó &os;-s gépet átjárónak állítjuk be. Ebben az átjáróban legalább két hálózati felületnek kell léteznie — az egyikkel az internetes útválasztóhoz, a másikkal pedig a helyi hálózathoz kapcsolódik. A belsõ hálózaton levõ gépek egy hub vagy egy switch segítségével csatlakoznak egymáshoz. Több módon is el tudjuk érni a belsõ hálózatról az internetet egy &os;-s átjárón keresztül. Ebben a példában most csak olyan átjárókkal foglalkozunk, amelyekben legalább két hálózati kártya található. _______ __________ ________ | | | | | | | Hub |-----| B kliens |-----| Útvál. |----- Internet |_______| |__________| |________| | ____|_____ | | | A kliens | |__________| A hálózat felosztása Egy ehhez hasonló beállítás igen gyakori a megosztott internet-kapcsolatok esetében. A helyi hálózat egyik gépe csatlakozik az internetre. A többi gép ezen az átjárón keresztül éri el az internetet. rendszerbetöltõ beállítása A rendszerbetöltõ beállítása A &man.natd.8; mûködéséhez szükséges címfordítási támogatást a GENERIC típusú rendszermagok nem tartalmazzák, viszont a /boot/loader.conf megfelelõ paraméterezésével a rendszer betöltése közben ezt hozzá tudjuk adni: ipfw_load="YES" ipdivert_load="YES" Valamint a net.inet.ip.fw.default_to_accept változót állítsuk az 1 értékre. net.inet.ip.fw.default_to_accept="1" Ez utóbbi beállítást leginkább a tûzfal és a címfordítást végzõ átjáró próbálgatásakor érdemes alkalmazni. Ilyenkor ugyanis az &man.ipfw.8; alapértelmezett módon az allow ip from any to any (minden forgalom engedélyezett) szabályt követi, és nem pedig a kevésbé barátságos deny ip from any to any (minden forgalom tiltott) szabályt. A rendszer újraindításakor így valamivel nehezebb lesz kizárnunk magunkat a szabályok megadása során. rendszermag beállítása A rendszermag beállítása Amikor viszont nincs lehetõségünk modulok használatára, vagy szeretnénk minden igényelt funkciót beépíteni a rendszermagba, akkor a rendszermag beállításait tartalmazó állományban a következõket kell megadnunk: options IPFIREWALL options IPDIVERT A fentiek mellett még ezeket a lehetõségeket tudjuk választani: options IPFIREWALL_DEFAULT_TO_ACCEPT options IPFIREWALL_VERBOSE A rendszerindítás beállítása A tûzfal és a hálózati címfordítás beindításához a következõknek kell az /etc/rc.conf állományban lennie: gateway_enable="YES" firewall_enable="YES" firewall_type="OPEN" natd_enable="YES" natd_interface="fxp0" natd_flags="" A gépet átjárónak állítja be. Hatása megegyezik a sysctl net.inet.ip.forwarding=1 parancs kiadásával. A rendszer indításakor engedélyezi az /etc/rc.firewall állományban szereplõ tûzfalszabályok használatát. Egy olyan elõre definiált tûzfalat ad meg, amely alapból mindent beenged. Az /etc/rc.firewall állományban találhatjuk a többi típust. Megadja, hogy melyik felületen továbbítsunk csomagokat az internet felé (ez a felület csatlakozik az internetre). Itt szerepel minden további paraméter, amelyet még az indításkor át kell adnunk a &man.natd.8; démonnak. Amikor megadjuk ezeket a beállításokat az /etc/rc.conf állományban, pontosan ugyanaz történik, mintha a natd -interface fxp0 parancsot adtunk volna ki a rendszer indításakor. Ez tehát manuálisan is elindítható. Ha túlságosan sok paramétert akarunk egyszerre beállítani &man.natd.8; használatához, akkor akár egy külön konfigurációs állományt is megadhatunk. Ebben az esetben a konfigurációs állományt a következõ módon kell megjelölni az /etc/rc.conf állományban: natd_flags="-f /etc/natd.conf" Ekkor a /etc/natd.conf állomány fogja tartalmazni a beállításokat, soronként egyet. Például a következõ szakaszban ez lesz a tartalma: redirect_port tcp 192.168.0.2:6667 6667 redirect_port tcp 192.168.0.3:80 80 A konfigurációs állományról és az opció használatával kapcsolatban olvassuk el a &man.natd.8; man oldalát. A helyi hálózaton mindegyik gépnek az RFC 1918 által megadott privát IP-címterekbõl származó címet kell használnia, és az alapértelmezett átjárónak mindenhol a natd démont futtató gép IP-címét kell megadni. Például a belsõ hálózaton található A és B kliensek IP-címei rendre 192.168.0.2 és 192.168.0.3, míg a &man.natd.8; démont futtató gép belsõ címe 192.168.0.1. Az A és a B kliens alapértelmezett átjáróját a natd gépre, vagyis a 192.168.0.1 címre kell beállítanunk. A natd gép külsõ, avagy internetes felülete semmilyen további módosítást nem igényel a &man.natd.8; mûködéséhez. A portok átirányítása A &man.natd.8; alkalmazásának hátránya, hogy a belsõ hálózatra csatlakozó kliensek az internetrõl nem érhetõek el. Tehát a helyi hálózat kliensei képesek elérni a külvilágot, de az visszafelé már nem igaz. Ez akkor jelent igazából problémát, ha az egyik belsõ kliensen szolgáltatásokat akarunk futtatni. A probléma egyik egyszerû megoldása, ha a natd használatával az internet felõl egyszerûen átirányítunk bizonyos portokat a megfelelõ belsõ kliensre. Például tegyük fel, hogy az A kliens egy IRC szervert, míg a B kliens egy webszervert futtat. Ez akkor fog mûködni, ha a szolgáltatásokhoz tartozó 6667 (IRC) és 80 (web) portokat átirányítjuk a hozzájuk tartozó gépek felé. Ehhez a &man.natd.8; démonnak a paramétert kell átadni. A pontos felírás így néz ki: -redirect_port protokoll célIP:célPORT[-célPORT] [külsõIP:]külsõPORT[-külsõPORT] [távoliIP[:távoliPORT[-távoliPORT]]] A fenti példában tehát ezt kell megadnunk: -redirect_port tcp 192.168.0.2:6667 6667 -redirect_port tcp 192.168.0.3:80 80 Így az egyes külsõ tcp portokat átirányítjuk a belsõ hálózat gépei felé. A paraméternek akár egész porttartományokat is megadhatunk. Például a tcp 192.168.0.2:2000-3000 2000-3000 megadásával az összes 2000-tõl 3000-ig terjedõ port csatlakozását leképezzük az A kliens 2000 és 3000 közti portjaira. Ezek a beállítások a &man.natd.8; közvetlen futtatásakor adhatóak meg, esetleg az /etc/rc.conf állományban az natd_flags="" opció keresztül, vagy egy külön konfigurációs állományban. A többi beállítási lehetõséget a &man.natd.8; man oldalán ismerhetjük meg. A címek átirányítása címátirányítás A címek átirányítása abban az esetben hasznos, amikor több IP-cím áll rendelkezésünkre, de ezek egy géphez tartoznak. Ilyenkor az &man.natd.8; képes a belsõ hálózat egyes gépeihez saját külsõ IP-címet rendelni. A &man.natd.8; a belsõ hálózat kliensei által küldött csomagokban kicseréli a címüket a megfelelõ külsõ IP-címmel, illetve az ezekre a címekre érkezõ forgalmat továbbítja a megfelelõ belsõ kliens irányába. Ezt a megoldást statikus hálózati címfordításnak is nevezzük. Például a 128.1.1.2 és a 128.1.1.3 IP-címek a natd démont futtató átjáróhoz tartoznak. A 128.1.1.1 cím használható a natd alapú átjáró külsõ IP-címeként, miközben a 128.1.1.2 és a 128.1.1.3 címeket a belsõ hálózaton elérhetõ A és B kliensek felé közvetítjük. A felírása tehát a következõ: -redirect_address helyiIP publikusIP helyiIP A helyi hálózaton található kliens saját IP-címe. publikusIP A klienshez tartozó megfelelõ külsõ IP-cím. Az iménti példában a pontos paraméterek ezek lesznek: -redirect_address 192.168.0.2 128.1.1.2 -redirect_address 192.168.0.3 128.1.1.3 A opcióhoz hasonlóan ez is megadható az /etc/rc.conf állományban az natd_flags="" beállításon keresztül vagy egy külön konfigurációs állományban. A címek átirányításával nincs szüksége a portok átirányítására, mivel az adott IP-címhez tartozó összes forgalmat átirányítjuk. A natd démont futtató gépen a külsõ IP-címeket aktiválni kell és a külsõ felületéhez kell rendelni. A &man.rc.conf.5; man oldalon járhatunk utána, hogy mindezt hogyan is tudjuk megcsinálni. Párhuzamos vonali IP (PLIP) PLIP párhuzamos vonali IP PLIP A párhuzamos vonali IP (Parallel Line IP, PLIP) a TCP/IP protokoll használatát valósítja meg párhuzamos porton keresztül. Olyan gépek számára lehet hasznos, amelyekben nincs hálózati kártya, vagy esetleg laptopoknál. Ebben a szakaszban a következõket tárgyaljuk: Párhuzamos (laplink) kábel készítése Két számítógép összekapcsolása a PLIP segítségével Párhuzamos kábel készítése Párhuzamos kábelt a legtöbb számítástechnikai boltban tudunk vásárolni. Ha mégsem tudnánk sehol sem beszerezni, vagy egyszerûen tudni szeretnénk, hogyan lehet ilyet készíteni, akkor az alábbi táblázatban láthatjuk, hogy miként tudunk egy hétköznapi nyomtatókábelt átalakítani a céljainkra. A párhuzamos kábel hálózati használatra alkalmas bekötése A-név A-vég B-vég Leírás Post/Bit DATA0 -ERROR 2 15 15 2 Adat 0/0x01 1/0x08 DATA1 +SLCT 3 13 13 3 Adat 0/0x02 1/0x10 DATA2 +PE 4 12 12 4 Adat 0/0x04 1/0x20 DATA3 -ACK 5 10 10 5 Vál. imp. 0/0x08 1/0x40 DATA4 BUSY 6 11 11 6 Adat 0/0x10 1/0x80 GND 18-25 18-25 Föld -
A PLIP beállítása Elõször is szereznünk kell valahonnan egy laplink kábelt. Ha ez megvan, akkor mind a két gépen ellenõrizzük, hogy a rendszermag tartalmazza az &man.lpt.4; meghajtót: &prompt.root; grep lp /var/run/dmesg.boot lpt0: <Printer> on ppbus0 lpt0: Interrupt-driven port A párhuzamos portnak megszakítással vezéreltnek kell lennie (interrupt driven), és az /boot/device.hints állományban szerepelnie kell nagyjából a következõ soroknak: hint.ppc.0.at="isa" hint.ppc.0.irq="7" Ezután nézzük meg, hogy a rendszermag beállításait tartalmazó állományban megjelenik-e a device plip sor, vagy a plip.ko modul betöltõdött-e. Akármelyik is történt, a párhuzamos hálózati felület most már a rendelkezésünkre áll, és az &man.ifconfig.8; paranccsal ezt meg is tudjuk nézni: &prompt.root; ifconfig plip0 plip0: flags=8810<POINTOPOINT,SIMPLEX,MULTICAST> mtu 1500 A laplink kábelt csatlakoztassuk mind a két számítógéphez. Mind a két a hálózati felület paramétereit root felhasználóként hangoljuk be. Például, ha az egyikgép nevû gépet akarjuk a másikgép nevû géphez csatlakoztatni: egyikgép <-----> másikgép IP-cím 10.0.0.1 10.0.0.2 Az egyikgép felületét így állítsuk be: &prompt.root; ifconfig plip0 10.0.0.1 10.0.0.2 A másikgép felületét így állítsuk be: &prompt.root; ifconfig plip0 10.0.0.2 10.0.0.1 Ezt követõen már egy mûködõ kapcsolatnak kell felépülnie. Az egyéb részletek kapcsán az &man.lp.4; és az &man.lpt.4; man oldalait nézzük át. Ezt a két gépet vegyük fel az /etc/hosts állományba is: 127.0.0.1 localhost.saját.tartomány localhost 10.0.0.1 egyikgép.saját.tartomány egyikgép 10.0.0.2 másikgép.saját.tartomány A kapcsolat mûködõképességérõl úgy tudunk meggyõzõdni, ha az egyik géprõl megpróbáljuk pingelni a másikat. Például az egyikgép esetében: &prompt.root; ifconfig plip0 plip0: flags=8851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet 10.0.0.1 --> 10.0.0.2 netmask 0xff000000 &prompt.root; netstat -r Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire másikgép egyikgép UH 0 0 plip0 &prompt.root; ping -c 4 másikgép PING másikgép (10.0.0.2): 56 data bytes 64 bytes from 10.0.0.2: icmp_seq=0 ttl=255 time=2.774 ms 64 bytes from 10.0.0.2: icmp_seq=1 ttl=255 time=2.530 ms 64 bytes from 10.0.0.2: icmp_seq=2 ttl=255 time=2.556 ms 64 bytes from 10.0.0.2: icmp_seq=3 ttl=255 time=2.714 ms --- másikgép ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 2.530/2.643/2.774/0.103 ms Aaron Kaplan Eredetileg írta: Tom Rhodes Átszervezte és kiegészítette: Brad Davis Tovább bõvítette: Az IPv6 Az IPv6 (másik néven az IPng, vagy a az internet következõ generációs protokollja, IP next generation) a jól ismert IP protokoll (avagy az IPv4) új változata. Hasonlóan a jelenleg mûködõ összes többi BSD rendszerhez, a &os; is tartalmazza a KAME IPv6 referencia implementációt. Ezért ha ezzel szeretnénk kísérletezni, akkor ehhez a &os; minden eszköz biztosít számunkra. Ez a szakasz az IPv6 beállítását és használatát mutatja be. Az 1990-es évek elején az IPv4-es címterek rohamos mértékû kimerülését figyelték meg. Az internet jelenlegi bõvülési üteme mellett két nagyobb aggodalomnak adott okot: A címek elfogyása. Napjainkban efelõl egyre kevesebb a kétség, mivel az RFC 1918 által megfogalmazott privát címterek (10.0.0.0/8, 172.16.0.0/12, és 192.168.0.0/16), valamint a hálózati címfordítás (Network Address Translation, NAT) használata igen elterjedt. Az útválasztási táblázatok méretének növekedése. Ez még manapság is aggasztó. Az IPv6 ezeket és még más egyéb problémákat a következõ módon igyekszik megoldani: A 128 bites címtér használata. Más szóval, elméletben összesen 340 282 366 920 938 463 463 374 607 431 768 211 456 darab címet képes kiosztani. Ez azt jelenti, hogy bolygónk minden egyes négyzetméterére megközelítõleg 6,67 * 10^27 IPv6 típusú cím jut. Az útválasztók a saját táblázataikban csak a hálózatok összevont címeit tárolják el, ezáltal egy átlagos útválasztási táblázatban található bejegyzések száma 8192 alá csökken. Az IPv6 emellett még rengeteg más elõnyös lehetõséget is kínál: A címek automatikus beállítása (lásd RFC 2462) Anycast (bárkiküldés, vagyis egy a sokból) Kötelezõ (mandatory) multicast IPsec (IP szintû védelem) Egyszerûsített fejléc Mobil IP IPv6-IPv4 közti átjárhatóság Ha mindezekrõl többet szeretnénk megtudni, akkor erre érdemes továbblépnünk: Az IPv6 áttekintése a playground.sun.com honlapon KAME.net Az IPv6 címek háttere Az IPv6 címeknek több típusa létezik: a unicast (egyesküldés), az anycast (bárkiküldés) és a multicast (többesküldés). A unicasthez használt címek jól ismert címek. Az így elküldött csomag pontosan ahhoz a felülethez érkezik meg, amelyhez az adott cím tartozik. Az anycasthez használt címek felírásukban tökéletesen megegyeznek a unicast esetével, de valójában felületek egy csoportját címezik. Az anycastre beállított címekre küldött csomagok mindig a(z útválasztó szerinti) legközelebb levõ felülethez érkeznek meg. Az anycastet az útválasztók számára találták ki. A multicasthez használt címek felületek egy csoportját nevezik meg. A multicast címekre érkezõ csomagokat a csoport minden egyes tagja megkapja. Az IPv4 esetében az üzenetszórásra szánt (általában az xxx.xxx.xxx.255 formátumú) címeket az IPv6 esetében multicast címekkel fejezzük ki. Fenntartott IPv6 címek IPv6 cím Az elõtag hossza (bitekben) Leírás Megjegyzés :: 128 bit nem specifikált Vö. a 0.0.0.0 címmel az IPv4 esetében. ::1 128 bit saját cím Vö. a 127.0.0.1 címmel az IPv4 esetében. ::00:xx:xx:xx:xx 96 bit IPv4 beágyazása Az alsó 32 bit egy IPv4 formátumú cím. Ezt IPv4 kompatibilis IPv6 címnek is nevezik. ::ff:xx:xx:xx:xx 96 bit IPv4-re leképzett IPv6 címek Az alsó 32 bit egy IPv4 címet jelöl. Olyan gépeknél használatos, amelyek nem támogatják az IPv6 protokollt. fe80:: - feb:: 10 bit helyi összeköttetés Vö. az IPv4 loopback címeivel. fec0:: - fef:: 10 bit helyi cím   ff:: 8 bit multicast   001 (2-es alapú) 3 bit globális unicast Az összes globális unicast címet ebbõl a tartományból osztjuk ki. Az elsõ 3 bit értéke001.
Az IPv6 címek olvasása Az IPv6 címek kanonikus formája így ábrázolható: x:x:x:x:x:x:x:x, ahol mindegyik x egy 16 bites hexadecimális érték. Például: FEBC:A574:382B:23C1:AA49:4592:4EFE:9982. Gyakran a címek hosszú nullákból álló sorozatokat tartalmaznak, ezért mindegyik ilyen sorozatot rövidíteni tudjuk a :: jelöléssel. Rajtuk kívül még az egyes hexadecimális csoportokban a bevezetõ nullák is elhagyhatóak. Például az fe80::1 cím kanonikus formája: fe80:0000:0000:0000:0000:0000:0000:0001. A harmadik forma szerint az utolsó 32 bites részt írjuk fel a megszokott (decimális) IPv4 stílusú pontozással, ahol tehát a . választja el a tagokat. Így például a 2002::10.0.0.1 felírás a 2002:0000:0000:0000:0000:0000:0a00:0001 kanonikus (hexadecimális) ábrázolásnak feleltethetõ meg, ami pedig egyszerûen 2002::a00:1 alakban is megadható. Mostanra már minden bizonnyal a kedves olvasó érteni fogja a következõt: &prompt.root; ifconfig rl0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500 inet 10.0.0.10 netmask 0xffffff00 broadcast 10.0.0.255 inet6 fe80::200:21ff:fe03:8e1%rl0 prefixlen 64 scopeid 0x1 ether 00:00:21:03:08:e1 media: Ethernet autoselect (100baseTX ) status: active A fe80::200:21ff:fe03:8e1%rl0 cím az automatikusan beállított helyi összeköttetés címe. Ez az automatikus beállítás részeként a MAC-címbõl jött létre. Az IPv6 címek szerkezetérõl további részleteket az RFC 3513-ban találunk. Kapcsolódás Jelenleg négy módon tudunk más IPv6-os géphez és hálózathoz csatlakozni: Kérjünk a hálózati elérésünkért felelõs illetékesektõl IPv6 alapú hálózatot. A részletek tekintetében vegyük fel a kapcsolatot az internet-szolgáltatónkkal. A SixXS a világ minden táján kínál végpontokkal rendelkezõ tunneleket. Egy 6-ból-4 (RFC 3068) típusú tunnellel. Ha betárcsázós kapcsolatunk van, akkor használjuk a net/freenet6 portot. A nevek feloldása az IPv6 világában IPv6 alatt régebben két típusa volt a nevek feloldásáért felelõs rekordoknak. Az IETF az A6 rekordokat idõközben elavultnak nyilvánította. Ezért manapság már az AAAA rekordok tekinthetõek szabványosnak. Az AAAA rekordok használata magától értetõdik. A hálózati nevükhöz az alábbi módon tudunk IPv6 címet rendelni az elsõdleges zónát leíró állományban: SAJÁTNÉV AAAA SAJÁTIPv6CÍM Ha nem rendelkezünk saját névfeloldási zónával, akkor erre kérjük meg a névfeloldást végzõ szolgáltatónkat. A bind jelenlegi változatai (8.3 és 9), valamint a dns/djbdns (IPv6 támogatására vonatkozó javítással) támogatják az AAAA rekordokat. Az <filename>/etc/rc.conf</filename> szükséges módosításai Az IPv6 kliensek beállításai Ezek a beállítások egy helyi hálózaton levõ gépre vonatkoznak, nem pedig egy útválasztóra. Az &man.rtsol.8; az alábbi megadásával fogja automatikusan beállítani a felületeinket a rendszer indításakor: ipv6_enable="YES" Ha az fxp0 felülethez statikusan akarunk IP-címet rendelni, például a 2001:471:1f11:251:290:27ff:fee0:2093 címet, akkor ehhez a következõt kell megadni: ipv6_ifconfig_fxp0="2001:471:1f11:251:290:27ff:fee0:2093" Az /etc/rc.conf állományban az alapértelmezett átjárót a következõ módon tudjuk a 2001:471:1f11:251::1 címre beállítani: ipv6_defaultrouter="2001:471:1f11:251::1" Az IPv6 útválasztók és átjárók beállítása Itt most a tunnelt biztosító szolgáltató által mutatott irányt követjük, és olyan formára alakítjuk, amely megmarad az újraindítás után is. A rendszer indításakor az /etc/rc.conf állományban valami ilyesmit kell megadni a járat visszaállításához: Soroljuk fel a beállítandó általános tunnel alapú felületeket, ilyen lehet például a gif0: gif_interfaces="gif0" A felületnek állítsunk be egy helyi végpontot a SAJÁT_IPv4_CÍM megadásával, valamint egy távoli végpontot a TÁVOLI_IPv4_CÍM megadásával: gifconfig_gif0="SAJÁT_IPv4_CÍM TÁVOLI_IPv4_CÍM" Az IPv6 tunnelünk végpontjához kapott cím aktiválásához az alábbit kell még megadnunk: ipv6_ifconfig_gif0="SAJÁT_KAPOTT_IPv6_TUNNEL_VÉGPONTJÁNAK_CÍME" Ezután már csak az alapértelmezett útvonalat kell beállítani az IPv6 számára. Ez az IPv6 járat másik oldala: ipv6_defaultrouter="SAJÁT_IPv6_TÁVOLI_TUNNEL_VÉGPONTJÁNAK_CÍME" Az IPv6 tunnel beállításai Amennyiben a szerver IPv6 alapú forgalmat közvetít a hálózatunk és a világ között, az /etc/rc.conf állományba a következõt kell felvennünk: ipv6_gateway_enable="YES" Az útválasztók kihirdetése és automatikus konfigurációja Ebben a szakaszban az &man.rtadvd.8; beállításával fogjuk az alapértelmezett IPv6 útvonalat kihirdetni. Az &man.rtadvd.8; engedélyezéséhez az alábbi sort kell betennünk az /etc/rc.conf állományba: rtadvd_enable="YES" Emellett még fontos megadnunk azt a felületet, ahol az IPv6 útválasztó kérelmezését végezzük. Ha erre a feladatra például az fxp0 felületet választjuk, akkor errõl az &man.rtadvd.8; így értesíthetõ: rtadvd_interfaces="fxp0" Most pedig készítenünk kell hozzá egy konfigurációt is, vagyis az /etc/rtadvd.conf állományt. Íme erre egy példa: fxp0:\ :addrs#1:addr="2001:471:1f11:246::":prefixlen#64:tc=ether: Az fxp0 felületet természetesen cseréljük ki a sajátunkkal. Ezután a 2001:471:1f11:246:: címre helyére írjuk be a saját kiosztásunk elõtagját. Egy egész /64 alhálózat esetén nem is kell többet megadni. Minden más helyezetben az elõtag hosszára prefixlen# vonatkozó értéket is be kell még állítanunk. Harti Brandt Készítette: Az Aszinkron adatátviteli mód (ATM) A klasszikus IP-címek beállítása ATM felett (állandó) A klasszikus IP ATM felett (Classical IP over ATM, CLIP) a legegyszerûbb módszer az IP-címek használatára az Aszinkron adatátviteli móddal (Asynchronous Transfer Mode, ATM) együtt. Kapcsolt és állandó kapcsolatok (Switched Virtual Channel, SVC és Permanent Virtual Channel, PVC) esetén egyaránt megfelelõ. Ebben a szakaszban ez utóbbival fogunk foglalkozni. A teljesen hálószerû konfigurációk A CLIP beállítását állandó csatornákon például úgy tudjuk megoldani, ha az összes gépet külön ezekre a célokra szánt állandó csatornákkal összekapcsoljuk egymással. Ez az egyszerû megoldás azonban nagyobb számú gép esetében már nem eléggé hatékony. A következõ példában csupán négy gépet kötünk hálózatba, melyik mindegyike egy ATM kártyával csatlakozik az ATM hálózatra. Ehhez elsõként tervezzük meg az IP-címek kiosztását és a gépek közti ATM kapcsolatokat. A példában ez az alábbiak szerint alakul: Gép IP-cím A-gep 192.168.173.1 B-gep 192.168.173.2 C-gep 192.168.173.3 D-gep 192.168.173.4 A teljes hálózat felépítéséhez minden egyes pár között egy-egy ATM kapcsolatra lesz szükségünk: Gépek VPI.VCI pár A-gep - B-gep 0.100 A-gep - C-gep 0.101 A-gep - D-gep 0.102 B-gep - C-gep 0.103 B-gep - D-gep 0.104 C-gep - D-gep 0.105 A kapcsolatok egyes végein szereplõ VPI és VCI értékek természetesen eltérhetnek, de ezeket mi most az egyszerûség kedvéért egyenlõnek tekintettük. A következõ lépésben minden gépen állítsuk be az ATM felület: A-gep&prompt.root; ifconfig hatm0 192.168.173.1 up B-gep&prompt.root; ifconfig hatm0 192.168.173.2 up C-gep&prompt.root; ifconfig hatm0 192.168.173.3 up D-gep&prompt.root; ifconfig hatm0 192.168.173.4 up Ha feltételezzük, hogy minden gépen a hatm0 az ATM felület neve. Most pedig az A-gep-en állítsuk be az állandó csatornákat. (Itt most feltesszük, hogy az ATM switch-eken mindezt már elvégeztük. A switch kézikönyvében errõl részletesebb leírást is találhatunk.) A-gep&prompt.root; atmconfig natm add 192.168.173.2 hatm0 0 100 llc/snap ubr A-gep&prompt.root; atmconfig natm add 192.168.173.3 hatm0 0 101 llc/snap ubr A-gep&prompt.root; atmconfig natm add 192.168.173.4 hatm0 0 102 llc/snap ubr B-gep&prompt.root; atmconfig natm add 192.168.173.1 hatm0 0 100 llc/snap ubr B-gep&prompt.root; atmconfig natm add 192.168.173.3 hatm0 0 103 llc/snap ubr B-gep&prompt.root; atmconfig natm add 192.168.173.4 hatm0 0 104 llc/snap ubr C-gep&prompt.root; atmconfig natm add 192.168.173.1 hatm0 0 101 llc/snap ubr C-gep&prompt.root; atmconfig natm add 192.168.173.2 hatm0 0 103 llc/snap ubr C-gep&prompt.root; atmconfig natm add 192.168.173.4 hatm0 0 105 llc/snap ubr D-gep&prompt.root; atmconfig natm add 192.168.173.1 hatm0 0 102 llc/snap ubr D-gep&prompt.root; atmconfig natm add 192.168.173.2 hatm0 0 104 llc/snap ubr D-gep&prompt.root; atmconfig natm add 192.168.173.3 hatm0 0 105 llc/snap ubr Természetesen nem csak UBR használható, hanem minden más olyan forgalmazási beállítás, amit az ATM kártyáink ismernek. Itt most a forgalmi beállítás nevét a hozzá tartozó konkrét paraméterek követik. Az &man.atmconfig.8; segédprogram használatához így kérhetünk segítséget: &prompt.root; atmconfig help natm add Olvassuk el az &man.atmconfig.8; man oldalát. Ugyanez a beállítás az /etc/rc.conf állomány használatával is elvégezhetõ. Az A-gep esetében mindez így nézne ki: network_interfaces="lo0 hatm0" ifconfig_hatm0="inet 192.168.173.1 up" natm_static_routes="B-gep C-gep D-gep" route_B-gep="192.168.173.2 hatm0 0 100 llc/snap ubr" route_C-gep="192.168.173.3 hatm0 0 101 llc/snap ubr" route_D-gep="192.168.173.4 hatm0 0 102 llc/snap ubr" A CLIP útvonalak pillanatnyi állapota így kérdezhetõ le: A-gep&prompt.root; atmconfig natm show Tom Rhodes Írta: A Közös cím redundancia protokoll (CARP) CARP Közös cím redundancia protokoll A Közös cím redundancia protokoll (Common Address Redundancy Protocol, avagy CARP) segítségével több gép képes egyazon IP-címen osztozni. Bizonyos konfigurációkban ez a terhelés elosztására (terhelés-kiegyenlítésre) vagy a rendelkezésre állás növelésére (hibatûrésre) alkalmazható. A benne szereplõ gépek akár eltérõ IP-címmel is rendelkezhetnek, ahogy azt majd a példában is láthatjuk. A CARP támogatásának engedélyezéséhez a &os; rendszermagját a következõ beállítással kell újrafordítanunk: device carp A CARP által biztosított lehetõségek ezután már elérhetõek, és számos sysctl változón keresztül állíthatóak: Változó Leírás net.inet.carp.allow A beérkezõ CARP csomagok elfogadása. Alapértelmezés szerint engedélyezett. net.inet.carp.preempt Ezzel a beállítással az adott gépen az összes CARP felület leáll, ha közülük bármelyik is mûködésképtelenné válik. Alapértelmezés szerint tiltott. net.inet.carp.log A 0 értékkel kikapcsoljuk a naplózást. Az 1 értékkel a rossz CARP csomagok naplózását engedélyezzük. Az ettõl nagyobb értékek esetén pedig a CARP felületek változásait naplózzuk. Az alapértelmezett értéke az 1. net.inet.carp.arpbalance Az ARP protokoll segítségével próbálja meg a helyi hálózati forgalmat mentesíteni a terheléstõl. Alapértelmezés szerint tiltott. net.inet.carp.suppress_preempt Ez a változó írásvédett, és a megszakítás elnyomásának állapotát mutatja. A megszakítás elnyomható, ha a felület egyik linkje nem mûködik. A 0 érték arra utal, hogy a megszakítást nem nyomták el. Minden probléma növeli ennek a változónak az értékét. A CARP eszközök maguk az ifconfig paranccsal készíthetõek el: &prompt.root; ifconfig carp0 create Egy valós környezetben az ilyen felületeknek egy VHID néven ismert egyedi azonosítóval kell rendelkezniük. Ez a VHID vagy más néven a virtuális gépazonosító (azaz Virtual Host Identification) fogja a gépünket a hálózat többi elemétõl megkülönböztetni. A CARP felhasználása a rendelkezésre állás javításában A CARP használatának egyik módja, ahogy arra már korábban is utaltunk, a szerverek rendelkezésre állásának feljavítása. Ebben a példában három géppel fogunk hibatûrést biztosítani, melyik mindegyike egyedi IP-címmel rendelkezik és ugyanazt a webes tartalmat szolgáltatják. A gépeket egy Round Robin rendszerû (körbejáró) névfeloldással együtt használjuk. A tartalék gépünknek lesz még további két CARP felülete, külön a szerver IP-címeihez tartozó egyes webes tartalmakhoz. Amikor valami meghibásodik, a tartalék szerver átveszi a meghibásodott gép IP-címét. Ilyenkor a hiba teljesen észrevétlen marad a felhasználók számára. A tartalék szerveren a többi szerverrel egyezõ tartalomnak és szolgáltatásoknak kell megjelennie, hogy bármikor át tudja tõlük venni a forgalmat. A hálózati neveiktõl és a virtuális azonosítóiktól eltekintve a két gépet ugyanúgy kell beállítani. Ebben a példában a gépeket most az a-gep.minta.org és b-gep.minta.org nevekkel láttuk el. Elõször is a CARP beállításához el kell helyeznünk a megfelelõ hivatkozásokat az rc.conf állományban. Az a-gep.minta.org esetében az rc.conf állomány a következõ sorokat tartalmazza: hostname="a-gep.minta.org" ifconfig_fxp0="inet 192.168.1.3 netmask 255.255.255.0" cloned_interfaces="carp0" ifconfig_carp0="vhid 1 pass testpass 192.168.1.50/24" Miközben a b-gep.minta.org az rc.conf állományában ezeket adjuk meg: hostname="b-gep.minta.org" ifconfig_fxp0="inet 192.168.1.4 netmask 255.255.255.0" cloned_interfaces="carp0" ifconfig_carp0="vhid 2 pass testpass 192.168.1.51/24" Nagyon fontos, hogy az ifconfig parancs pass paraméterével megadott jelszavak megegyezzenek. A carp eszközök csak a megfelelõ jelszót birtokló gépeket fogadják el. A virtuális gépazonosítónak azonban minden esetben el kell térnie. A harmadik, szolgaltato.minta.org címmel rendelkezõ gépet fogjuk felkészíteni az elõbbi gépek meghibásodására felkészíteni. Ennek a gépnek két carp eszközre lesz szüksége, melyek az egyes gépeket kezelik. Az ehhez illeszkedõ sorok valahogy így fognak kinézni az rc.conf állományban: hostname="szolgaltato.minta.org" ifconfig_fxp0="inet 192.168.1.5 netmask 255.255.255.0" cloned_interfaces="carp0 carp1" ifconfig_carp0="vhid 1 advskew 100 pass testpass 192.168.1.50/24" ifconfig_carp1="vhid 2 advskew 100 pass testpass 192.168.1.51/24" Két carp eszköz használatával a szolgaltato.minta.org képes észlelni és átvenni bármelyik olyan gép IP-címét, amely nem válaszol. Az alap &os; rendszermag használata esetén elõfordulhat, hogy a megszakítás (a preemption opció) engedélyezett. Amennyiben így lenne, a szolgaltato.minta.org nem fogja minden esetben fogja rendesen visszaadni az IP-címet az eredeti tulajdonosának. Ilyenkor a rendszergazdának kell ezt manuálisan megtennie. Tehát a következõ parancsot kell kiadnia a szolgaltato.minta.org gépen: &prompt.root; ifconfig carp0 down && ifconfig carp0 up Ezt az adott géphez tartozó carp felülettel kell megcsinálni. Innentõl a CARP már teljesen engedélyezhetõ és készen áll a tesztelésre. A teszteléshez vagy a hálózati rendszert kell újraindítani, vagy a gépeket. További információkat a &man.carp.4; man oldalán találhatunk. diff --git a/hu_HU.ISO8859-2/books/handbook/config/chapter.sgml b/hu_HU.ISO8859-2/books/handbook/config/chapter.sgml index aa2d89019e..a571915cdb 100644 --- a/hu_HU.ISO8859-2/books/handbook/config/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/config/chapter.sgml @@ -1,4749 +1,4769 @@ Chern Lee Írta: Mike Smith Az alapjául szolgáló bemutatást írta: Matt Dillon Valamint az alapját képzõ tuning(7) oldalt írta: Beállítás és finomhangolás Áttekintés a rendszer beállítása a rendszer finomhangolása A &os; egyik fontos szempontja a rendszer megfelelõ beállítása, aminek segítségével elkerülhetjük a késõbbi frissítések során keletkezõ kellemetlenségeket. Ez a fejezet a &os; beállítási folyamatából kíván minél többet bemutatni, köztük a &os; rendszerek finomhangolására szánt paramétereket. A fejezet elolvasása során megismerjük: hogyan dolgozzunk hatékonyan az állományrendszerekkel és a lapozóállományokkal; az rc.conf beállításának alapjait és a /usr/local/etc/rc.d könyvtárban található indítási rendszert; hogyan állítsunk be és próbáljunk ki egy hálózati kártyát; hogyan állítsunk be virtuális címeket a hálózati eszközeinken; hogyan használjuk az /etc könyvtárban megtalálható különféle konfigurációs állományokat; hogyan hangoljuk a &os; mûködését a sysctl változóinak segítségével; hogyan hangoljuk a lemezek teljesítményét és módosítsuk a rendszermag korlátozásait. A fejezet elolvasásához ajánlott: a &unix; és a &os; alapjainak megértése (); a rendszermag beállításához és fordításához kötõdõ alapok ismerete (). Kezdeti beállítások A partíciók kiosztása partíciókiosztás /etc /var /usr Alappartíciók Amikor a &man.bsdlabel.8; vagy a &man.sysinstall.8; segítségével állományrendszereket telepítünk, nem szabad figyelmen kívül hagynunk a tényt, hogy a merevlemezes egységekben a külsõ sávokból gyorsabban lehet hozzáférni az adatokhoz, mint a belsõkbõl. Emiatt a kisebb és gyakrabban elérni kívánt állományrendszereket a meghajtó lemezének külsejéhez közel kell létrehozni, míg például a /usr partícióhoz hasonló nagyobb partíciókat annak belsõ része felé. A partíciókat a következõ sorrendben érdemes kialakítani: gyökér (rendszerindító), lapozóállomány, /var és /usr. A /var méretének tükröznie kell a számítógép szándékolt használatát. A /var partíción foglalnak helyet a felhasználók postaládái, a naplóállományok és a nyomtatási sorok. A postaládák és a naplóállományok egészen váratlan mértékben is képesek megnövekedni attól függõen, hogy mennyi felhasználónk van a rendszerben és hogy mekkora naplókat tartunk meg. Itt a legtöbb felhasználónak soha nem lesz szüksége egy gigabyte-nál több helyre. Bizonyos esetekben a /var/tmp könyvtárban azért ennél több tárterület szükségeltetik. Amikor a &man.pkg.add.1; segítségével egy friss szoftvert telepítünk a rendszerünkre, akkor a program a /var/tmp könyvtárba tömöríti ki a hozzá tartozó csomag tartalmát. Ezért a nagyobb szoftvercsomagok, mint például a Firefox vagy az OpenOffice esetén gondok merülhetnek fel, ha nem rendelkezünk elegendõ szabad területtel a /var/tmp könyvtárban. A /usr partíció tartalmaz számos, a rendszer mûködéséhez elengedhetetlenül fontos állományt, többek közt a portok gyûjteményét (ajánlott, lásd &man.ports.7;) és a forráskódot (választható). A portok és az alaprendszer forrásai telepítés során választhatóak, de telepítésük esetén akkor ezen a partíción legalább két gigabyte-nyi hely ajánlott. Vegyük figyelembe a tárbeli igényeket, amikor megválasztjuk a partíciók méretét. Igen kellemetlen lehet, amikor úgy futunk ki az egyik partíción a szabad helybõl, hogy a másikat alig használjuk. Egyes felhasználók szerint elõfordulhat, hogy a &man.sysinstall.8; Auto-defaults opciója a /var és / partíciók méretét túl kicsire választja. Particionáljunk okosan és nagylelkûen! A lapozóállomány partíciója a lapozóállomány mérete a lapozóállomány partíciója Általános szabály, hogy a lapozóállományt tároló partíció mérete legyen a rendszer fizikai memóriájának (RAM) kétszerese. Például, ha a számítógépünk 128 megabyte memóriával rendelkezik, akkor a lapozóállomány méretének 256 megabyte-nak kell lennie. Az ennél kevesebb memóriát maguknak tudó rendszerek több lapozóállománnyal jobban teljesítenek. 256 megabyte-nál kevesebb lapozóállományt semmiképpen sem ajánlunk, és inkább a fizikai memóriát érdemes bõvítenünk. A rendszermag virtuális memóriát kezelõ lapozási algoritmusait úgy állították be, hogy abban az esetben teljesítsenek a legjobban, ha a lapozóállomány mérete legalább kétszerese a központi memória mennyiségének. A túl kicsi lapozóállomány beállítása rontja a virtuális memória lapkeresésési rutinjának hatékonyságát és a memória bõvítése esetén még további gondokat is okozhat. A több SCSI-lemezzel (vagy a különbözõ vezérlõkre csatlakoztatott több IDE-lemezzel) bíró nagyobb rendszerek esetében érdemes minden egyes (de legfeljebb négy) meghajtóra beállítani lapozóállományt. A lapozóállományoknak közel azonos méretûnek kell lenniük. A rendszermag tetszõleges méretûeket képes kezelni, azonban a belsejében alkalmazott adatszerkezetek a legnagyobb lapozóállomány méretének négyszereséig képesek növekedni. Ha a lapozóállományokat nagyjából ugyanazon a méreten tartjuk, akkor a rendszermag képes lesz a lapozáshoz felhasznált területet optimálisan elosztani a lemezek között. A nagyobb lapozóállományok használata még akkor is jól jön, ha nem is használjuk annyira. Segítségével sokkal könnyebben talpra tudunk állni egy elszabadult program tombolásából, és nem kell rögtön újraindítanunk a rendszert. Miért particionáljunk? Egyes felhasználók úgy gondolják, hogy egyetlen nagyobb méretû partíció mindenre megfelel, ám ez a gondolat több okból is helytelennek tekinthetõ. Elõször is, minden egyes partíciónak eltér a mûködési jellemzõje, és különválasztásukkal lehetõvé válik az állományrendszerek megfelelõ behangolása. Például a rendszerindításhoz használt és a /usr partíciókat többségében csak olvasásra használják, és nem sokat írnak rájuk. Eközben a /var és /var/tmp könyvtárakban zajlik az írások és olvasások túlnyomó része. A rendszer megfelelõ felosztásával a kisebb, intenzívebben írt partíciókon megjelenõ töredezettség nem szivárog át a többségében csak olvasásra használt partíciókra. Ha a sokat írt partíciókat közel tartjuk a lemez széléhez, akkor azokon a partíciókon növekszik az I/O teljesítménye, ahol az a leggyakrabban megjelenik. Mivel mostanság az I/O teljesítményére inkább a nagyobb partíciók esetén van szükség, azzal nem érünk el ebben különösebb mértékû növekedést, ha a /var partíciót a lemez szélére toljuk. Befejezésképpen hozzátesszük, hogy ennek vannak biztonsági megfontolásai is. Egy kisebb és takarosabb rendszerindító partíció, ami többnyire írásvédett, nagyobb eséllyel él túl egy csúfos rendszerösszeomlást. A mag beállítása rc állományok rc.conf A rendszer beállításaira vonatkozó információk központi lelõhelye az /etc/rc.conf állomány. Ez az állomány tartalmazza a beállításokra vonatkozó adatok széles körét, amelyet elsõsorban a rendszer indulása során a rendszer beállítására használnak. Erre a neve is utal: ez az rc* állományok konfigurációs állománya. A rendszergazda az rc.conf állományban tudja felülbírálni az /etc/defaults/rc.conf állományban szereplõ alapértelmezett beállításokat. Az alapértelmezéseket tartalmazó állományt nem szabad közvetlenül átmásolni az /etc könyvtárba, hiszen alapértelmezett értékeket tartalmaz, nem pedig mintákat. Minden rendszerfüggõ beállítást magában az rc.conf állományban kell elvégezni. Számos stratégia létezik a tömegesen adminisztrált számítógépeknél a közös és rendszerfüggõ beállítások különválasztására, ezáltal a karbantartási költségek csökkentésére. A közös beállításokat ajánlott egy másik helyre, például az /etc/rc.conf.site állományba rakni, majd hivatkozni erre a kizárólag csak rendszerfüggõ információkat tartalmazó /etc/rc.conf állományból. Mivel az rc.conf állományt az &man.sh.1; dolgozza fel, ezt elég könnyen el tudjuk érni. Például: rc.conf: . /etc/rc.conf.site hostname="node15.example.com" network_interfaces="fxp0 lo0" ifconfig_fxp0="inet 10.1.1.1" rc.conf.site: defaultrouter="10.1.1.254" saver="daemon" blanktime="100" Az rc.conf.site állomány ezt követõen az rsync parancs használatával már szétszórható a rendszerben, miközben az rc.conf állomány mindenkinél egyedi marad. Ha a rendszert a &man.sysinstall.8; vagy a make world használatával frissítjük, akkor az rc.conf tartalma nem íródik felül, így a rendszer beállításairól szóló adatok nem vesznek el. Az alkalmazások beállítása A telepített alkalmazások általában saját konfigurációs állományokkal, azok pedig saját formátummal stb. rendelkeznek. Fontos, hogy ezeket az állományokat az alaprendszertõl elkülönítve tároljuk, ezáltal a csomagkezelõ eszközök könnyen rájuk tudjanak találni és dolgozni velük. /usr/local/etc Ezeket az állományokat általában a /usr/local/etc könyvtárban találjuk meg. Amennyiben egy alkalmazáshoz több konfigurációs állomány is tartozik, akkor ahhoz ezen belül egy külön alkönyvtár jön létre. Normális esetben, amikor egy portot vagy csomagot telepítünk, minta konfigurációs állományokat is kapunk. Ezek nevében többnyire a .default utótag szerepel. Ha még nincs konfigurációs állomány az adott alkalmazáshoz, akkor a .default jelzésû állományokból ez létrehozható. Példaképpen most tekintsük a /usr/local/etc/apache könyvtár tartalmát: -rw-r--r-- 1 root wheel 2184 May 20 1998 access.conf -rw-r--r-- 1 root wheel 2184 May 20 1998 access.conf.default -rw-r--r-- 1 root wheel 9555 May 20 1998 httpd.conf -rw-r--r-- 1 root wheel 9555 May 20 1998 httpd.conf.default -rw-r--r-- 1 root wheel 12205 May 20 1998 magic -rw-r--r-- 1 root wheel 12205 May 20 1998 magic.default -rw-r--r-- 1 root wheel 2700 May 20 1998 mime.types -rw-r--r-- 1 root wheel 2700 May 20 1998 mime.types.default -rw-r--r-- 1 root wheel 7980 May 20 1998 srm.conf -rw-r--r-- 1 root wheel 7933 May 20 1998 srm.conf.default Az állományok mérete jól mutatja, hogy csak az srm.conf változott meg. Az Apache késõbbi frissítései ezt az állományt nem fogják felülírni. Tom Rhodes Írta: Szolgáltatások indítása szolgáltatások A felhasználók közül sokan választják a &os; Portgyûjteményében található külsõ szoftverek telepítését. A telepített szoftvert ilyenkor gyakran úgy kell beállítani, hogy a rendszer indulásával együtt induljon. Az olyan szolgáltatások, mint például a mail/postfix vagy a www/apache13 csupán két olyan szoftvercsomag, amelyet a rendszerrel együtt kell elindítani. Ebben a szakaszban a külsõ szoftverek indítására használatos eljárásokkal foglalkozunk. A &os;-ben megjelenõ legtöbb szolgáltatás, mint például a &man.cron.8;, a rendszerindító szkripteken keresztül kel életre. Habár ezek a szkriptek a &os; egyes verziói vagy az egyes gyártók esetén különbözhetnek, azonban az mindegyikükben közös, hogy az elindításukra vonatkozó beállítások egyszerû indítószkriptekkel adhatóak meg. Az alkalmazások részletesebb beállítása Most miután a &os; rendelkezik egy rc.d könyvtárral, az alkalmazások indításának beállítása is könnyebbé és ügyesebbé vált. Az rc.d mûködésérõl szóló szakaszban megismert kulcsszavak segítségével az alkalmazások mostantól kezdve a többi szolgáltatás, például a DNS után indulnak el, és az rc.conf állományon keresztül a szkriptekbe huzalozottak helyett most már tetszõleges paramétereket is átadhatunk stb. Egy egyszerû szkript ehhez hasonlóan néz ki: #!/bin/sh # # PROVIDE: utility # REQUIRE: DAEMON # KEYWORD: shutdown . /etc/rc.subr name="utility" rcvar=`set_rcvar` command="/usr/local/sbin/utility" load_rc_config $name # # NE VÁLTOZTASSUK MEG AZ ITT LÉVÕ ALAPÉRTELMEZÉSEKET, # INKÁBB AZ /etc/rc.conf ÁLLOMÁNYBAN ÁLLÍTSUK BE EZEKET # utility_enable=${utility_enable-"NO"} utility_pidfile=${utility_pidfile-"/var/run/utility.pid"} pidfile="${utility_pidfile}" run_rc_command "$1" Ez a szkript gondoskodik arról, hogy a utility nevû alkalmazás a DAEMON szolgáltatás után induljon el. Emellett még felkínál egy módszert a PID avagy futó programok azonosítójának beállítására és nyomonkövetésére is. Ezt követõen az /etc/rc.conf állományból az alkalmazás elindítható az alábbi sor hozzáadásával: utility_enable="YES" Ez a módszer megkönnyíti a parancssorban átadott paraméterek módosítását, az /etc/rc.subr állományban szereplõ alapértelmezett függvények használatát, az &man.rcorder.8; segédprogrammal szembeni kompatibilitást és az rc.conf állomány könnyebb beállítását. Szolgáltatások indítása szolgáltatásokkal Más szolgáltatások, mint például a POP3 vagy IMAP szerverek démonai stb. az &man.inetd.8; segítségével indíthatóak el. Ez a Portgyûjteménybõl telepített szolgáltatások esetén magával vonja az adott segédprogram felvételét vagy a hozzá tartozó sor engedélyezését az /etc/inetd.conf állományban. Az inetd mûködésével és annak beállításával mélyrehatóbban az inetd szakasza foglalkozik. A legtöbb esetben a &man.cron.8; démon használata kézenfekvõ a rendszerszintû szolgáltatások elindításában. Ez a megközelítés számos elõnyt tartogat, mivel a cron ezeket a programokat a felhasználó crontab állománya alapján futtatja. Ezzel a mezei felhasználók számára is lehetõvé válik, hogy elindítsanak és karbantartsanak alkalmazásokat. A cron segédprogramnak van egy olyan speciális lehetõsége, hogy az idõ helyett a @reboot értéket adhatjuk meg. Ennek hatására a feladat a &man.cron.8; indításával együtt fut le, tehát megszokott esetben a rendszer indítása során. Tom Rhodes Írta: A <command>cron</command> segédprogram beállítása cron beállítása A &man.cron.8; a &os; egyik leghasznosabb segédprogramja. A cron segédprogram a háttérben fut és folyamatosan figyeli az /etc/crontab állományt. Emellett a cron új crontab állományok után kutatva folyamatosan ellenõrzi a /var/cron/tabs könyvtárat. Ezek a crontab állományok olyan feladatokról tárolnak adatokat, amelyeket a cron programnak egy adott pillanatban el kell végeznie. A cron a konfigurációs állományok két külön fajtáját, a rendszer- és felhasználói crontabokat használja. A két típus között levõ egyetlen különbség a hatodik mezõben található. A rendszerszintû crontabok esetében a hatodik mezõ annak a felhasználónak a nevét tartalmazza, amivel a program fut. Ezzel a rendszer szintjén mûködõ crontaboknak megadatott az a képesség, hogy tetszõleges felhasználó nevében futtassanak programokat. A felhasználók crontabjaiban a hatodik mezõ a futtatandó parancsot tartalmazza, és ilyenkor az összes parancs a crontabot létrehozó felhasználó nevében hajtódik végre. Ez utóbbi egy fontos biztonsági jellemzõ. A felhasználói crontabok lehetõvé teszik az egyes felhasználók számára, hogy a root felhasználó jogosultságai nélkül képesek legyenek feladatokat ütemezni, ugyanis a felhasználóhoz tartozó crontabban szereplõ parancsok mindegyike a tulajdonosának engedélyeivel fut. Az átlagos felhasználókhoz hasonlóan a root felhasználónak is lehet crontabja, ami nem ugyanaz, mint az /etc/crontab (a rendszer saját crontab állománya). De mivel a rendszernek külön crontabja van, ezért a root felhasználónak nem kell külön crontabot létrehozni. Vessünk egy pillanatást az /etc/crontab (a rendszer crontabjának) tartalmára: # /etc/crontab - a root crontabja &os; alatt # # $&os;: src/etc/crontab,v 1.32 2002/11/22 16:13:39 tom Exp $ # # SHELL=/bin/sh PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin HOME=/var/log # # #minute hour day month wday who command # # */5 * * * * root /usr/libexec/atrun A &os; legtöbb konfigurációs állományához hasonlóan itt is a # jelöli a megjegyzéseket. Az ilyen megjegyzések remekül használhatóak annak feljegyzésére, hogy mit és miért akarunk futtatni. A megjegyzések azonban nem szerepelhetnek a paranccsal egy sorban, mivel máskülönben a parancs részeként kerülnek értelmezésre. Tehát mindig új sorba kell raknunk ezeket. Az üres sorokat a program nem veszi figyelembe. Elõször is meg kell adnunk egy környezetet. Az egyenlõség (=) karakter használatos a környezeti beállítások meghatározására, ahogy mindezt az itteni példában is tapasztalhatjuk a SHELL, PATH és HOME értékek esetében. Ha nem adunk meg mást, akkor a cron az alapértelmezés szerinti sh parancsértelmezõt használja. Ha nem adjuk meg a PATH változó értékét, akkor minden állományra abszolút elérési úttal kell hivatkoznunk, mivel ennek nincs alapértelmezett értéke. Ha nem definiáljuk a HOME változó értékét, akkor a cron a parancshoz tartozó felhasználó könyvtárából fog dolgozni. Ez a sor írja le a megadható hét mezõt. Az itt szereplõ értékek a minute (perc), hour (óra), mday (a hónap napja), month (hónap), wday (a hét napja), who (ki) és command (mit). A mezõk szinte maguktól értetõdnek. A minute egy órán belül adja meg azokat a perceket, amikor az adott parancsot le kell futtatni. A hour hasonló a minute beállításhoz, csak az itt szereplõ értékét órákban kell értelmezni. Az mday a hónap napjaiban számol. A month hasonló a minute és hour opciókhoz, de ez hónapot jelöl. A wday a hét egy napját jelzi. Ezeknek a mezõknek numerikus, valamint a huszonnégy órás idõformátumnak megfelelõ értékeket kell tartalmazniuk. A who mezõ, a többiektõl eltérõ módon, csak az /etc/crontab állományban jelenik meg. Ez a mezõ adja meg, hogy a parancsot milyen felhasználóval kell futtatni. Ez az opció nem jelenik meg a felhasználók saját crontab állományainak telepítésekor. A sor végén láthatjuk még a command oszlopot is. Ez az utolsó mezõ, és ide kerül a végrehajtandó parancs. Ez az utolsó sor a fentebb tárgyalt értékeket határozza meg. Észrevehetjük, hogy a sor egy */5 alakú felírással kezdõdik, amelyet további * karakterek követnek. A * karakterek jelentése elsõ-utolsó, ami arra utal, hogy mindig. Ennek megfelelõen úgy értelmezhetjük ezt a sort, hogy a root felhasználóval le kell futtatni az atrun parancsot minden ötödik percben, függetlenül attól, hogy milyen nap vagy hónap van. Az atrun parancsról részletesebban az &man.atrun.8; man oldalán kapunk felvilágosítást. Az itt szereplõ parancsoknak tetszõleges mennyiségû paraméter adható át, azonban a több soron keresztül átívelõ parancsok tördelését a sor végén a \ karakterrel kell jelezni. Ez mindegyik crontab állomány alapbeállítása, habár ettõl általában egy dologban eltérnek. A hatodik mezõ, ahol a felhasználót adtuk meg, csak a rendszer /etc/crontab állományában jelenik meg. Ez a mezõ a felhasználók crontab állományaiból kimarad. Egy crontab telepítése Nem kötelezõ az itt ismertetésre kerülõ módon szerkeszteni vagy telepíteni a rendszer crontabját. Egyszerûen nyissuk meg a kedvenc szövegszerkesztõnkkel, és a cron segédprogram majd észreveszi, hogy az állomány megváltozott, majd ennek megfelelõen neki is lát a módosított változat használatának. Errõl a GYIK-ban (angolul) többet is megtudhatunk. Egy frissen készített felhasználói crontab telepítéséhez elõször a kedvenc szövegszerkesztõnk segítségével létre kell hoznunk a megfelelõ formátumú állományt, majd használnunk a crontab segédprogramot. Ennek általános alakja: &prompt.user; crontab crontab_állomány Ebben a példában a crontab_állomány a korábban létrehozott crontab neve lesz. Lehetõségünk van lekérdezni a telepített crontab állományokat: egyszerûen adjuk át a kapcsolót a crontab parancsnak, és nézzük meg, mit ad vissza. A crontab -e használata olyan felhasználók számára ajánlott, akik sablon alkalmazása nélkül szeretnének teljesen maguktól megírni egy crontab állományt. Ennek hatására a kiválasztott szövegszerkesztõ egy üres állományt kap. Miután ezt az állományt elmentettük, a crontab programmal magától telepítésre kerül. Ha a késõbbiekben törölni akarjuk a felhasználónkhoz tartozó crontab állományt, akkor erre a célra használjuk a crontab kapcsolóját. Tom Rhodes Írta: Az rc használata &os; alatt A rendszer indítására a &os; 2002-ben átvette a NetBSD rc.d rendszerét. Ezt a felhasználók könnyen felismerhetik az /etc/rc.d könyvtárban található állományokról. A legtöbbjük olyan alapvetõ szolgáltatás, amelyet a , és paraméterekkel lehet vezérelni. Például az &man.sshd.8; az alábbi paranccsal indítható újra: &prompt.root; /etc/rc.d/sshd restart Ez az eljárás hasonló a többi szolgáltatás esetén is. Természetesen ezek a szolgáltatások általában maguktól indulnak el a rendszer indítása során az &man.rc.conf.5; állományban megadottak szerint. Például ha a rendszerünk indulásakor szeretnénk aktiválni a hálózati címfordítással foglalatoskodó démont, akkor csak adjuk hozzá az /etc/rc.conf állományhoz a következõ sort: natd_enable="YES" Amennyiben a sor már szerepel benne, akkor egyszerûen írjuk át a értéket -re. Ezután az rc szkriptek a rendszer következõ indításakor a lentieknek megfelelõen automatikusan elindítják a hozzá tartozó szolgáltatásokat is. Mivel az rc.d rendszert elsõsorban arra használják, hogy szolgáltatásokat indítsanak el vagy állítsanak le az operációs rendszerrel együtt, a szabványos , és paraméterek csak abban az esetben látják el a feladatukat, ha a nekik megfelelõ változókat beállítottuk az /etc/rc.conf állományban. Tehát például az sshd restart csak abban az esetben fog bármit is csinálni, ha az /etc/rc.conf állományban az sshd_enable változót a értékre állítottuk. Ha az /etc/rc.conf beállításaitól függetlenül kívánunk egy szolgáltatásnak , vagy parancsot adni, akkor elé kell tennünk egy one szót. Például ha az sshd szolgáltatás újraindításához az /etc/rc.conf tartalmát figyelmen kívül akarjuk hagyni, akkor ezt a parancsot kell kiadnunk: &prompt.root; /etc/rc.d/sshd onerestart Könnyen ellenõrizni tudjuk, hogy az adott szolgáltatás az /etc/rc.conf részérõl engedélyezett-e, ha a neki megfelelõ rc.d szkriptnek megadjuk az paramétert. Ennek segítségével például a rendszergazda így képes ellenõrizni, hogy az sshd szolgáltatást engedélyezi-e az /etc/rc.conf: &prompt.root; /etc/rc.d/sshd rcvar # sshd $sshd_enable=YES A második sor (# sshd) az sshd parancs kimenete, nem pedig a root parancssora. A paraméterrel kideríthetjük, hogy egy szolgáltatás aktív-e. Ezzel például így tudjuk ellenõrizni az sshd szolgáltatás mûködését: &prompt.root; /etc/rc.d/sshd status sshd is running as pid 433. Az üzenet: Az sshd a 433-as azonosítóval fut. Bizonyos esetekben a paraméter használatával lehetõségünk van a szolgáltatások újraindítására is. Ilyenkor a rendszer megpróbál egy olyan jelzést küldeni a szolgáltatásnak, amivel a konfigurációs állományainak újraolvasását kéri. A legtöbbször lényegében ez a SIGHUP jelzés kiküldését rejti magában. Ez a lehetõség azonban nem mindegyik szolgáltatás esetén érhetõ el. Az rc.d rendszer nem csupán hálózati szolgáltatások esetén használatos, hanem nagyrészben hozzájárul a rendszer indításához is. Erre vegyük példának a bgfsck állományt. Amikor ez a szkript lefut, a következõ üzenetet jeleníti meg: Starting background file system checks in 60 seconds. Az üzenet fordítása: A háttérben 60 másodperc múlva megkezdõdik az állományrendszerek ellenõrzése. Ennek megfelelõen tehát ezt az állományt az állományrendszerek háttérben folyó ellenõrzésére használják, ami pedig a rendszer indítása során fut le. Számos rendszerszolgáltatás igényel a mûködéséhez további szolgáltatásokat. Például a NIS és más egyéb távoli eljáráshíváson alapú szolgáltatások egészen addig nem képesek elindulni, amíg az rpcbind (portmapper) szolgáltatást el nem indítjuk. Az ilyen jellegû gondok feloldására az indítószkriptek elején levõ megjegyzésekben található egy kevés metainformáció a szkript mûködéséhez szükséges elemekre (függõségeire) vonatkozóan. A rendszer indítása közben az &man.rcorder.8; nevû program képes a megjegyzések közt ezeket az információkat feldolgozni és ebbõl megállapítani, hogy a függõségi viszonyok betartásával milyen sorrendben kell elindítani a rendszer által felkínált szolgáltatásokat. Ehhez a következõ kulcsszavakat kell megadni az egyes indító szkriptek elején (az &man.rc.subr.8; így tudja engedélyezni az indító szkriptet): PROVIDE: segítségével megmondjuk, hogy ez az állomány milyen szolgáltatásokat nyújt. A következõ kulcsszavak az egyes indítóállományok elején szerepelhetnek. Nem kell feltétlenül használnunk ezeket, de velük az &man.rcorder.8; munkáját segíthetjük: REQUIRE: felsoroljuk azokat a szolgáltatásokat, amelyek a futásához kellenek. Az állomány tehát az itt megadott szolgáltatások után fog lefutni. BEFORE: felsoroljuk azokat a szolgáltatásokat, amelyek elõtt futtatni kell ezt az állományt. Az indító szkriptekben a kulcsszavak ügyes megválasztásával a rendszergazda nagyon finoman képes az indításkor végrehajtódó szkriptek sorrendjét szabályozni és a többi &unix; alapú operációs rendszerbõl ismert futtatási szintek használata nélkül vezérelni a rendszerben megjelenõ szolgáltatásokat. Az rc.d rendszerrõl bõvebben az &man.rc.8; és &man.rc.subr.8; man oldalakon olvashatunk. Ha szeretnénk saját rc.d szkripteket írni vagy javítani a már meglévõkön, akkor ez a cikk (angolul) segítségünkre lehet. Marc Fonvieille Írta: A hálózati kártyák beállítása hálózati kártyák beállítása Manapság már el sem tudunk képzelni számítógépet hálózati csatlakozás nélkül. A hálózati csatolókártyák hozzáadása és beállítása egy &os; rendszergazda mindennapos feladata. A megfelelõ meghajtóprogram felderítése hálózati kártyák meghajtó Mielõtt bárminek is nekikezdenénk, érdemes tisztában lennünk azzal, hogy a rendelkezésünkre álló kártya milyen típusú, milyen chipet használ és hogy PCI vagy ISA buszon csatlakozik-e. A &os; a PCI és ISA csatolós kártyák széles spektrumát ismeri. Az egyes kiadásokhoz mellékelt Hardware Compatibility List (Hardverkompatibilitási lista) dokumentumokban tudjuk ellenõrizni, hogy a kártyákat ismeri a rendszer. Miután meggyõzõdtünk róla, hogy a kártyánkat ismeri a rendszer, meg kell keresnünk a hozzá tartozó meghajtót. A /usr/src/sys/conf/NOTES és a /usr/src/sys/arch/conf/NOTES állományok tartalmazzák a hálózati kártyák meghajtóinak rövid leírását, benne a támogatott chipsetek és kártyák típusaival. Ha ez alapján nem tudjuk teljes biztosággal eldönteni, hogy melyik a számunkra megfelelõ meghajtó, nézzük meg a saját man oldalát. Ezen a man oldalon megtaláljuk az általa ismert összes eszközt és a velük kapcsolatban elõforduló jellemzõ problémákat. Ha egy elterjedt típust sikerült beszereznünk, akkor nem kell különösebben sokáig keresnünk a neki megfelelõ meghajtót. Az ismertebb hálózati kártyák meghajtói ugyanis alapból benne vannak a GENERIC rendszermagban, ezért a rendszer indítása során ehhez hasonlóan meg is jelennek a kártyák: dc0: <82c169 PNIC 10/100BaseTX> port 0xa000-0xa0ff mem 0xd3800000-0xd38 000ff irq 15 at device 11.0 on pci0 -dc0: Ethernet address: 00:a0:cc:da:da:da miibus0: <MII bus> on dc0 -ukphy0: <Generic IEEE 802.3u media interface> on miibus0 -ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto +bmtphy0: <BCM5201 10/100baseTX PHY> PHY 1 on miibus0 +bmtphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto +dc0: Ethernet address: 00:a0:cc:da:da:da +dc0: [ITHREAD] dc1: <82c169 PNIC 10/100BaseTX> port 0x9800-0x98ff mem 0xd3000000-0xd30 000ff irq 11 at device 12.0 on pci0 -dc1: Ethernet address: 00:a0:cc:da:da:db miibus1: <MII bus> on dc1 -ukphy1: <Generic IEEE 802.3u media interface> on miibus1 -ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto +bmtphy1: <BCM5201 10/100baseTX PHY> PHY 1 on miibus1 +bmtphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto +dc1: Ethernet address: 00:a0:cc:da:da:db +dc1: [ITHREAD] Ebben a példában láthatunk is két olyan kártyát, amelyek a &man.dc.4; meghajtót használják. Ha a hálózati kártyánk meghajtója nem szerepel a GENERIC konfigurációban, akkor a mûködéséhez be kell tölteni a megfelelõ meghajtót. Ezt alapvetõen kétféleképpen érhetjük el: Ennek legegyszerûbb módja, ha a &man.kldload.8; használatával alkalmanként vagy a /boot/loader.conf állományban a megfelelõ sor hozzáadásával a rendszer indításával együtt betöltjük a hálózati kártya meghajtójához tartozó modult. Nem mindegyik hálózati kártya meghajtója érhetõ el modul formájában. Erre konkrét például szolgálnak az ISA kártyákhoz tartozó modulok. Másik lehetõségünk, ha statikusan beépítjük a kártyánk támogatását a rendszermagba. A /usr/src/sys/conf/NOTES és az /usr/src/sys/arch/conf/NOTES állományok, valamint a meghajtóhoz tartozó man oldal elolvasásából megtudhatjuk a rendszermag beállításait tartalmazó állományban megadandó paramétereket. A rendszermag újrafordítását lásd . Ha a rendszermag (GENERIC) az indulás során észlelte a kártyánkat, nem kell újat készítenünk. A &windows; NDIS meghajtóinak használata NDIS NDISulator &windows; meghajtók Microsoft Windows Microsoft Windows eszközmeghajtók KLD (a rendszermag betölthetõ objektuma) Sajnos még mindig sok olyan gyártó akad, akik a nyílt forrású közösség számára nem adják ki a meghajtóik mûködésének alapjait, mivel az ilyen adatokat szakmai titoknak tekintik. Ebbõl következik, hogy a &os; és más operációs rendszerek fejlesztõi számára két választás marad: vagy a gyári meghajtók visszafejtésének hosszú és fájdalmas útján haladva fejlesztik ki a saját meghajtójukat, vagy pedig a µsoft.windows; platformra kiadott meghajtók binárisait hasznosítják. A legtöbb fejlesztõ, köztük a &os; fejlesztõi is, ez utóbbi megközelítést választották. Bill Paul (wpaul) jóvoltából a &os; 5.3-RELEASE változatában megjelent a Network Driver Interface Specification (NDIS, avagy hálózati meghajtók szabványos felülete) natív támogatása. A &os; NDISulator (másnéven Project Evil, a Gonosz terve) nevû komponense fog egy &windows;-os meghajtót és elhiteti vele, hogy a &windows; operációs rendszerrel kommunikál. Mivel az &man.ndis.4; meghajtó &windows; binárisokat használ fel, ezért csak &arch.i386; és &arch.amd64; rendszerek esetén érhetõ el. Az &man.ndis.4; meghajtó leginkább a PCI, CardBus és PCMCIA csatolójú eszközök támogatására lett kitalálva, az USB eszközöket még nem ismeri. Az NDISulator használatához három tényezõre van szükségünk: A rendszermag forrása a &windowsxp; meghajtó binárisa (.SYS a kiterjesztése) a &windowsxp; meghajtó konfigurációs állománya (.INF a kiterjesztése) Keressük meg az említett állományokat az adott kártyához. Ezeket általában a mellékelt CD-n vagy a gyártó honlapján találjuk meg. A most következõ példákban a W32DRIVER.SYS és a W32DRIVER.INF neveket fogjuk használni. A &windows; i386 architektúrájú verziójához készült meghajtóprogramokat nem tudjuk a &os;/amd64 verziójával használni. A mûködéshez amd64-re készült &windows;-os meghajtókra van szükség. A következõ lépés a meghajtó binárisainak betölthetõ modulba fordítása. Ennek eléréséhez használjuk az &man.ndisgen.8; parancsot a root felhasználóval: &prompt.root; ndisgen /windowsos/meghajtó/W32DRIVER.INF /windowsos/meghajtó/W32DRIVER.SYS Az &man.ndisgen.8; egy interaktív segédprogram, amely mûködése közben még rákérdez néhány szükséges információra. Az aktuális könyvtárban létrehoz egy rendszermagmodult, amelyet az alábbi módon tudunk betölteni: - &prompt.root; kldload ./W32DRIVER.ko + &prompt.root; kldload ./W32DRIVER_SYS.ko Az elõállított modul mellé be kell töltenünk még az ndis.ko és az if_ndis.ko modulokat is. Ez általában minden olyan modul esetén megtörténik magától, amely függ az &man.ndis.4; használatától. Kézileg a következõ parancsokkal tudjuk ezeket betölteni: &prompt.root; kldload ndis &prompt.root; kldload if_ndis Itt az elsõ parancs betölti az NDIS miniport meghajtó burkolására szánt kódot, valamint a második a tényleges hálózati csatolófelületet. Most pedig a &man.dmesg.8; kimenetében ellenõrizzük, hogy történt-e valamilyen hiba a betöltés során. Ha minden jól ment, akkor az alábbiakhoz hasonló kimenetet produkált: ndis0: <Wireless-G PCI Adapter> mem 0xf4100000-0xf4101fff irq 3 at device 8.0 on pci1 ndis0: NDIS API version: 5.0 ndis0: Ethernet address: 0a:b1:2c:d3:4e:f5 ndis0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps ndis0: 11g rates: 6Mbps 9Mbps 12Mbps 18Mbps 36Mbps 48Mbps 54Mbps Innentõl kezdve az ndis0 nevû eszközt úgy tudjuk használni, mint bármelyik más hálózati felületet (például dc0). A többi modulhoz hasonló módon be tudjuk állítani, hogy a rendszer indulásával együtt betöltõdjenek az NDIS modulok. Ehhez elõször másoljuk az imént létrehozott modult, az - W32DRIVER.ko állományt a + W32DRIVER_SYS.ko állományt a /boot/modules könyvtárba. Ezután adjuk hozzá a következõ sort a /boot/loader.conf állomány tartalmához: - W32DRIVER_load="YES" + W32DRIVER_SYS_load="YES" A hálózati kártya beállítása hálózati kártyák beállítása Ahogy betöltõdött a megfelelõ meghajtó a hálózati kártyánkhoz, be is kell állítanunk a kártyát. A hálózati kártyák sok más dologgal együtt beállíthatóak a telepítés során a sysinstall segítségével. A rendszerünkben beállított hálózati csatolófelületek megjelenítéséhez gépeljük be a következõ parancsot: &prompt.user; ifconfig -dc0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 - inet 192.168.1.3 netmask 0xffffff00 broadcast 192.168.1.255 +dc0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 + options=80008<VLAN_MTU,LINKSTATE> ether 00:a0:cc:da:da:da + inet 192.168.1.3 netmask 0xffffff00 broadcast 192.168.1.255 media: Ethernet autoselect (100baseTX <full-duplex>) status: active -dc1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 - inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255 +dc1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 + options=80008<VLAN_MTU,LINKSTATE> ether 00:a0:cc:da:da:db + inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255 media: Ethernet 10baseT/UTP status: no carrier -lp0: flags=8810<POINTOPOINT,SIMPLEX,MULTICAST> mtu 1500 -lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 +plip0: flags=8810<POINTOPOINT,SIMPLEX,MULTICAST> mtu 1500 +lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384 + options=3<RXCSUM,TXCSUM> + inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 + inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 -tun0: flags=8010<POINTOPOINT,MULTICAST> mtu 1500 - - - A &os; korábbi változatainál az - &man.ifconfig.8; parancsnak ehhez még meg kell adni az - kapcsolót is. Az &man.ifconfig.8; - érvényes paraméterezésével - kapcsolatban érdemes elolvasni a hozzá - tartozó man oldalt. Hozzátennénk, hogy - IPv6 (inet6 stb.) típusú - bejegyzések nem szerepelnek a - példában. - + nd6 options=8010<POINTOPOINT,MULTICAST> mtu 1500 Az elõbbi parancs kimenetében a következõ eszközök jelentek meg: dc0: az elsõ Ethernet felület dc1: a második Ethernet felület - lp0: a párhuzamos port - felülete + plilp0: a párhuzamos + port felülete (amennyiben található + párhuzamos port a + számítógépben) lo0: a loopback eszköz - - - tun0: a - ppp által használt - tunnelhez tartozó eszköz - A &os; a kártyához tartozó meghajtó nevével és egy sorszámmal azonosítja a rendszermag indulása során talált eszközöket. Például az sis2 a rendszerben található harmadik olyan eszköz, amely a &man.sis.4; meghajtót használja. A példában a dc0 eszköz aktív és mûködõképes. Ennek legfontosabb jelei: Az UP szó mutatja, hogy a kártyát sikerült beállítani és készen áll a használatra. A kártya internet (inet) címe (jelen esetünkben ez 192.168.1.3). Érvényes hálózati maszkkal rendelkezik (netmask, ahol a 0xffffff00 a 255.255.255.0 címnek felel meg). Érvényes broadcast (üzenetszóró) címmel rendelkezik (ami itt most 192.168.1.255). A kártya MAC-címe (ether) 00:a0:cc:da:da:da. A hozzá tartozó fizikai eszköz kiválasztása automatikus (media: Ethernet autoselect (100baseTX <full-duplex>)). Láthatjuk, hogy a dc1 eszközt egy 10baseT/UTP típusú fizikai eszközhöz állítottuk be. Az egyes meghajtókhoz tartozó fizikai módokról a nekik megfelelõ man oldalakon olvashatunk. A kapcsolat állapota (status) active értékû, tehát van vonal. A dc1 esetén láthatjuk, hogy a status: no carrier (nincs vonal). Ez teljesen normálisnak tekinthetõ minden olyan esetben, amikor a kártyába még nem dugtunk Ethernet-kábelt. Amennyiben az &man.ifconfig.8; kimenete valami ilyesmi: - dc0: flags=8843<BROADCAST,SIMPLEX,MULTICAST> mtu 1500 - ether 00:a0:cc:da:da:da + dc0: flags=8843<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500 + options=80008<VLAN_MTU,LINKSTATE> + ether 00:a0:cc:da:da:da + media: Ethernet autoselect (100baseTX <full-duplex>) + status: active akkor az arra utal, hogy a kártyát nem állítottuk be. A kártya beállításához a root felhasználó jogosultságaira van szükségünk. A hálózati kártyák beállítása az &man.ifconfig.8; segítségével elvégezhetõ parancssorból is, de a gép újraindításakor az így megadott értékek elvesznek. Ezért az /etc/rc.conf állományba kell felvennünk a hálózati kártyák érvényes beállításait. A kedvenc szövegszerkesztõnkben nyissuk meg az /etc/rc.conf állományt. Minden egyes hálózati csatolóhoz fel kell vennünk benne egy sort, ennek megfelelõen most a példához tartozó módon az alábbiakat: ifconfig_dc0="inet 192.168.1.3 netmask 255.255.255.0" ifconfig_dc1="inet 10.0.0.1 netmask 255.255.255.0 media 10baseT/UTP" A dc0 és dc1 neveket kell a rendszerünkben ténylegesen megtalálható eszközök neveire kicserélni, valamint megadni a nekik megfelelõ címeket. A kártya meghajtójának és az &man.ifconfig.8; man oldalának elolvasásával kideríthetjük az itt megadható további beállításokat, valamint az &man.rc.conf.5; man oldalán részletesebben megismerhetjük az /etc/rc.conf formai követelményeit. Ha a telepítés során beállítottuk volna a hálózati kapcsolatokat, akkor tapasztalhatjuk, hogy egyes hálózati kártyák sorai itt már szerepelnek. Ellenõrizzük az /etc/rc.conf tartalmát, mielõtt bõvítenénk! Mindezek mellett az /etc/hosts állományba is be kell írnunk a helyi hálózatunkon található különféle gépek neveit és IP-címeit, ha még nem szerepelnének ott. Errõl további részleteket a &man.hosts.5; man oldalról és az /usr/share/examples/etc/hosts állományból tudhatunk meg. + + + Ha a géppel szeretnénk majd csatlakozni az + internetre, akkor ne felejtsük el manuálisan + beállítani az alapértelmezett + átjárót és a + névfeloldáshoz szükséges + kiszolgálót: + + &prompt.root; echo 'defaultrouter="alapertelmezett_atjaro"' >> /etc/rc.conf +&prompt.root; echo 'nameserver DNS_kiszolgalo' >> /etc/resolv.conf + Tesztelés és hibaelhárítás Miután az /etc/rc.conf állományban elvégeztük a szükséges változtatásokat, érdemes újraindítanunk a rendszerünket. Ennek révén érvényesítjük a csatolófelületekkel kapcsolatos változtatásainkat és ellenõrizzük, hogy így a rendszer mindenféle hibaüzenet nélkül - képes elindulni. + képes elindulni. A másik lehetõség, + ha csak magát a hálózati alrendszer + konfigurációját indítjuk el + újra: + + &prompt.root; /etc/rc.d/netif restart + + + Ha az /etc/rc.conf + állományban már beállítottuk + az alapértelmezett átjárót, akkor + elegendõ csupán ez a parancs: + + &prompt.root; /etc/rc.d/routing restart + - Ahogy a rendszerünk - mûködõképessé vált, ki is - tudjuk próbálni a hálózati + Ahogy újrakonfiguráltuk a + hálózati alrendszert, ki is tudjuk + próbálni a hálózati felületeket. Az Ethernet kártyák tesztelése hálózati kártyák tesztelése Az Ethernet kártyák helyes beállításának vizsgálatához két dolgot kell kipróbálnunk. Elõször is pingeljük magát a felületet, majd ezután pingeljünk meg a helyi hálózaton egy másik számítógépet. Elsõként tehát próbáljuk meg a helyi felületet: &prompt.user; ping -c5 192.168.1.3 PING 192.168.1.3 (192.168.1.3): 56 data bytes 64 bytes from 192.168.1.3: icmp_seq=0 ttl=64 time=0.082 ms 64 bytes from 192.168.1.3: icmp_seq=1 ttl=64 time=0.074 ms 64 bytes from 192.168.1.3: icmp_seq=2 ttl=64 time=0.076 ms 64 bytes from 192.168.1.3: icmp_seq=3 ttl=64 time=0.108 ms 64 bytes from 192.168.1.3: icmp_seq=4 ttl=64 time=0.076 ms --- 192.168.1.3 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.074/0.083/0.108/0.013 ms Most pedig pingeljünk meg egy másik számítógépet a helyi hálózaton: &prompt.user; ping -c5 192.168.1.2 PING 192.168.1.2 (192.168.1.2): 56 data bytes 64 bytes from 192.168.1.2: icmp_seq=0 ttl=64 time=0.726 ms 64 bytes from 192.168.1.2: icmp_seq=1 ttl=64 time=0.766 ms 64 bytes from 192.168.1.2: icmp_seq=2 ttl=64 time=0.700 ms 64 bytes from 192.168.1.2: icmp_seq=3 ttl=64 time=0.747 ms 64 bytes from 192.168.1.2: icmp_seq=4 ttl=64 time=0.704 ms --- 192.168.1.2 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.700/0.729/0.766/0.025 ms Ha beállítottuk az /etc/hosts állományt, akkor a 192.168.1.2 helyett a gép nevét is megadhatjuk. A hibák elhárítása hálózati kártyák hibaelhárítása A hardverek és szoftverek beállításaiban mindig is valódi kín megtalálni a hibákat, és ezeket a kínokat többnyire úgy tudjuk enyhíteni, ha elõször az egyszerû hibaforrásokat szûrjük ki. Csatlakoztattuk a hálózati kábelt? Tisztességesen beállítottuk a hálózati szolgáltatásokat? Jól állítottuk be a tûzfalat? A &os; képes kezelni a kártyát? A hibajelentések elküldése elõtt mindig bújjuk át a támogatott hardvereszközök listáját. A &os; verziókat frissítsük a legújabb STABLE változatra. Olvassuk át a levelezési listák archívumait vagy legalább keressünk rá a témára az interneten. Ha a kártya mûködik, de a teljesítménye nem kielégítõ, érdemes ennek utánanézni a &man.tuning.7; man oldalon. Ilyenkor érdemes ellenõrizni a hálózati beállításainkat is, mivel a helytelen beállítások gyakran okoznak teljesítményvesztést. Bizonyos esetekben láthatunk egy vagy két device timeout típusú hibát is, ami a kártyák egyes fajtáinál elfogadható. Ha azonban folyamatosan megjelennek vagy zavaróvá válnak, érdemes utánanéznünk, hogy az eszköz nem ütközik-e valamelyik másikkal. Mindenképpen gyõzõdjünk meg a kábelek épségérõl és csatlakoztatásáról. Még az is elképzelhetõ, hogy egyszerûen csak egy másik hálózati kártyára van szükségünk. Néha felbukkanak watchdog timeout jellegû hibák is. Ilyenkor elsõként mindig a hálózati kábelt ellenõrizzük. Egyes kártyáknak olyan PCI foglalatra van szükségük, ami támogatja a Bus Mastering opciót. Néhány régebbi alaplapon csak ilyen PCI bõvítõhely található (ami általában a 0. foglalat). Olvassunk utána a hálózati kártya és az alaplap dokumentációjában, hátha ezek okozzák a problémát. A No route to host üzenet akkor jelenik meg, ha a rendszer képtelen megállapítani, milyen úton juttassa el a csomagokat a megadott célhoz. Ez többnyire olyankor történik meg, amikor nem adtunk meg alapértelmezett kézbesítési irányt (default route) vagy nem dugtuk be a hálózati kábelt. A netstat -rn kimenetébõl meg tudjuk állapítani, hogy létezik-e érvényes út az elérni kívánt cél felé. Ha nincs, akkor haladjunk tovább a re. A ping: sendto: Permission denied jellegû üzeneteket többségében egy helytelenül beállított tûzfal okozza. Ha az ipfw mûködését engedélyeztük a rendszermagban, de nem adtunk meg hozzá szabályokat, akkor az alapértelmezett házirend szerint minden forgalmat blokkolni fog, tehát még a pingeket is! Ezzel kapcsolatban a elolvasását ajánljuk. Elõfordulhat, hogy a kártya teljesítménye igen gyenge vagy az átlagos alatt van. Ilyenkor a fizikai eszköz autoselect (automatikus) típusú kiválasztása helyett érdemes megadnunk a konkrét eszköznek megfelelõ típust. Habár ez a legtöbb hardver esetén beválik, nem mindenki számára jelent megoldást. Ismételten csak annyit tudunk ehhez hozzátenni, hogy ellenõrizzük a hálózati beállításainkat és olvassuk el a &man.tuning.7; man oldalt. Virtuális címek virtuális címek IP-álnevek A &os; alkalmazása során igen gyakori a virtuális címek használata, aminek segítségével egyetlen szerver több szerverként képes látszódni a hálózaton. Ezt úgy érik el, hogy egyetlen felülethez több hálózati címet rendelnek hozzá. Az adott hálózati csatolófelületnek van egy valódi címe és tetszõleges számú álcíme. Ezeket az álcímeket általában az /etc/rc.conf állományban kell feltüntetni. Az fxp0 felület esetén az álcímek megadása valahogy így néz ki: ifconfig_fxp0_alias0="inet xxx.xxx.xxx.xxx netmask xxx.xxx.xxx.xxx" Figyeljük meg, hogy az álcímekhez tartozó bejegyzések az alias0 névvel kezdõdnek és szám szerint növekvõleg következnek egymás után (például, _alias1, _alias2 és így tovább). A beállítás a sorozat elsõ kimaradó tagjánál megszakad. Az álcímek hálózati maszkjának pontos meghatározása nagyon fontos, de szerencsére nem különösebben bonyolult. Minden felület esetén lennie kell egy olyan címnek, amely helyesen reprezentálja a hálózat hálózati maszkját. Minden egyéb olyan címnek, ami ugyanabba az alhálózatba esik, végig 1-esekbõl álló hálózati maszkkal kell rendelkezniük (ami felírható 255.255.255.255 vagy 0xffffffff formájában is). Például vegyük azt, hogy az fxp0 felületen keresztül két hálózathoz csatlakozunk, melyek közül az egyik a 10.1.1.0, amelynek hálózati maszkja 255.255.255.0, és a 202.0.75.16, amelynek hálózati maszkja 255.255.255.240. Azt szeretnénk elérni, hogy a rendszerünk a 10.1.1.1 címtõl a 10.1.1.5 címig, valamint a 202.0.75.17 címtõl a 202.0.75.20 címig jelenjen meg a nekik megfelelõ hálózatokon. Ahogy arra már fentebb is utaltunk, az adott hálózati tartományban csak az elsõ címnek (ebben az esetben ez a 10.0.1.1 és a 202.0.75.17) kell valódi hálózati maszkkal rendelkeznie. Minden további címnek (a 10.1.1.2 és 10.1.1.5 között, valamint a 202.0.75.18 és 202.0.75.20 között) legyen 255.255.255.255 a hálózati maszkja. Az alábbi /etc/rc.conf bejegyzések ennek az elrendezésnek megfelelõen állítják be a kártyát: ifconfig_fxp0="inet 10.1.1.1 netmask 255.255.255.0" ifconfig_fxp0_alias0="inet 10.1.1.2 netmask 255.255.255.255" ifconfig_fxp0_alias1="inet 10.1.1.3 netmask 255.255.255.255" ifconfig_fxp0_alias2="inet 10.1.1.4 netmask 255.255.255.255" ifconfig_fxp0_alias3="inet 10.1.1.5 netmask 255.255.255.255" ifconfig_fxp0_alias4="inet 202.0.75.17 netmask 255.255.255.240" ifconfig_fxp0_alias5="inet 202.0.75.18 netmask 255.255.255.255" ifconfig_fxp0_alias6="inet 202.0.75.19 netmask 255.255.255.255" ifconfig_fxp0_alias7="inet 202.0.75.20 netmask 255.255.255.255" Konfigurációs állományok Az <filename class="directory">/etc</filename> felépítése A beállításokkal kapcsolatos információk számos könyvtárban tárolódnak. Többek közt: /etc Általános rendszerszintû beállítások. Az itt levõ adatok a rendszer egészére vonatkoznak. /etc/defaults A rendszer konfigurációs állományainak alapértelmezett változatai. /etc/mail A &man.sendmail.8; beállításához tartozó további állományok, egyéb levélküldéshez használt adatok. /etc/ppp A felhasználói és rendszermag szintû ppp programok beállításai. /etc/namedb A &man.named.8; mûködéséhez szükséges adatok alapértelmezett helye. Általában a named.conf és a zónák leírását tároló állományok kerülnek ide. /usr/local/etc A telepített alkalmazások konfigurációs állományai. Néha alkalmazásonként külön könyvtárakba kerülnek a benne található állományok. /usr/local/etc/rc.d A telepített alkalmazások indításával és leállításával kapcsolatos szkriptek. /var/db Automatikusan generált rendszerszintû adatbázisok a csomagokkal, a programok helyével stb. kapcsolatosan. Hálózati nevek hálózati név DNS <filename>/etc/resolv.conf</filename> resolv.conf Az /etc/resolv.conf határozza meg, hogy a &os; névfeloldója miként fér hozzá az internet tartománynév rendszeréhez (a DNS-hez). Az resolv.conf állományban leggyakrabban a következõ bejegyzések fordulnak elõ: nameserver Annak a névszernek az IP-címe, ahova a névfeloldó küldi a kéréseit. A névszervereket a felírás sorrendjében kérdezi meg, maximum hármat. search A hálózati nevek keresõlistája. Ezt általában a helyi hálózati nevek tartománya határozza meg. domain A helyi tartomány neve. Egy átlagos resolv.conf tartalma: search example.com nameserver 147.11.1.11 nameserver 147.11.100.30 Csak egy search és domain opciót szabad megadni. A DHCP használatakor a &man.dhclient.8; felül szokta írni a resolv.conf tartalmát a DHCP szervertõl kapott információkkal. <filename>/etc/hosts</filename> hosts Az /etc/hosts az internet kezdeti napjaira emlékeztetõ egyszerû szöveges adatbázis. A nevek és IP-címek közti leképzéseket a DNS és NIS rendszerekkel karöltve oldja fel. Ide a helyi hálózaton csatlakozó számítógépek neveit lehet beírni ahelyett, hogy erre a célra beállítanánk egy külön &man.named.8; szervert. Ezenkívül még az /etc/hosts állományba internetes nevek rekordját is felvehetjük, amivel így csökkenthetjük a gyakran használt nevek feloldására irányuló külsõ kéréseket. # $&os;$ # # # A hálózati nevek adatbázisa # # Ebbe az állományba rakjuk a helyi hálózaton található címeket és # a hozzájuk tartozó hálózati neveket, ahol szinte ugyanez az # adatbázis megtalálható. A 'my.domain' helyére a saját gépünk # nevét írjuk be. # # A DNS vagy NIS alkalmazása esetén ez az állomány nem feltétlenül kerül # felhasználásra. A névfeloldás sorrendjét az /etc/nsswitch.conf # állományban adhatjuk meg. # ::1 localhost localhost.my.domain 127.0.0.1 localhost localhost.my.domain # # Egy képzeletbeli hálózat. #10.0.0.2 myname.my.domain myname #10.0.0.3 myfriend.my.domain myfriend # # Az RFC 1918-nak megfelelõen a következõ IP-címekkel rendelkezõ # alhálózatok sosem csatlakozhatnak közvetlenül az internetre: # # 10.0.0.0 - 10.255.255.255 # 172.16.0.0 - 172.31.255.255 # 192.168.0.0 - 192.168.255.255 # # Amikor csatlakozunk az internethez, egy valódi, hivatalosan # kiosztott számra lesz szükségünk. Ne találjunk ki magunknak # hálózati címeket, hanem használjuk az internetszolgáltatótól # kapott címet (amennyiben rendelkezünk # ilyennel) vagy az # regionális internetes nyilvántartásban szereplõ címek közül # valamelyiket (ARIN, APNIC, LACNIC, RIPE NCC vagy AfriNIC). Az /etc/hosts formai felépítése igen egyszerû: [internetes cím] [hivatalos hálózati név] [álnév1] [álnév2] ... Tehát például: 10.0.0.1 azEnValodiNevem.aHalozaton.hu azEnValodiNevem izemize1 izemize2 A részletekért keressük fel a &man.hosts.5; man oldalt. A naplóállományok beállítása naplóállományok <filename>syslog.conf</filename> syslog.conf A syslog.conf állomány a &man.syslogd.8; program beállításait tartalmazza. Segítségével megadhatjuk, hogy a syslog által generált üzenetek egyes típusait milyen naplóállományokba mentsük. # $&os;$ # # Ebben az állományban HASZNÁLHATÓAK szóközök a mezõk elválasztására, # habár a többi *nix-típusú rendszer inkább tabulátorokat használ # erre a célra. Ha több rendszeren is használni akarjuk ezt az # állományt, akkor ne használjunk szóközöket. # # A többit lásd a syslog.conf(5) man oldalon. # .err;kern.debug;auth.notice;mail.crit /dev/console *.notice;kern.debug;lpr.info;mail.crit;news.err /var/log/messages security.* /var/log/security mail.info /var/log/maillog lpr.info /var/log/lpd-errs cron.* /var/log/cron *.err root *.notice;news.err root *.alert root *.emerg * # Tegyük vissza ezt a sort, ha a /dev/console eszközre kiírt # üzeneteket át akarjuk irányítani az /var/log/console.log állományba. #console.info /var/log/console.log # Ha az összes üzenetet a /var/log/all.log állományba akarjuk menteni, # akkor tegyük vissza ezt a sort. #*.* /var/log/all.log # Ha egy "loghost" nevû gépre szeretnénk naplózni, akkor tegyük vissza # ezt a sort. #*.* @loghost # Az inn használatakor tegyük vissza ezeket a sorokat. # news.crit /var/log/news/news.crit # news.err /var/log/news/news.err # news.notice /var/log/news/news.notice !startslip *.* /var/log/slip.log !ppp *.* /var/log/ppp.log A &man.syslog.conf.5; man oldalának elolvasásával tudhatunk meg többet ezekrõl. <filename>newsyslog.conf</filename> newsyslog.conf A newsyslog.conf a &man.newsyslog.8; beállításait tároló állomány. Ez egy olyan program, amelyet általában a &man.cron.8; futtat le. A &man.newsyslog.8; dönti el, hogy mikor van szükség a naplók archiválására és átrendezésére. Ennek során a logfile állományból logfile.0 lesz, a logfile.0 állományból pedig logfile.1 és így tovább. Beállíthatjuk úgy is, hogy a naplóállományokat archiválja &man.gzip.1; formátumban, aminek megfelelõen ezek logfile.0.gz, logfile.1.gz és ehhez hasonló névvel jönnek létre. A newsyslog.conf megadja, hogy melyik naplóállományokat kell felügyelni, mennyi példányt tartsunk meg belõlük és mikor kell velük foglalkozni. A naplóállományok átrendezhetõek és/vagy archiválhatóak egy adott méret elérésekor vagy egy adott idõ eltelte után. # A newsyslog konfigurációs állománya # $&os;$ # # állománynév [tulajdonos:csoport] mód darab méret mikor [ZB] [/pid_állomány] [jelzés] /var/log/cron 600 3 100 * Z /var/log/amd.log 644 7 100 * Z /var/log/kerberos.log 644 7 100 * Z /var/log/lpd-errs 644 7 100 * Z /var/log/maillog 644 7 * @T00 Z /var/log/sendmail.st 644 10 * 168 B /var/log/messages 644 5 100 * Z /var/log/all.log 600 7 * @T00 Z /var/log/slip.log 600 3 100 * Z /var/log/ppp.log 600 3 100 * Z /var/log/security 600 10 100 * Z /var/log/wtmp 644 3 * @01T05 B /var/log/daily.log 640 7 * @T00 Z /var/log/weekly.log 640 5 1 $W6D0 Z /var/log/monthly.log 640 12 * $M1D0 Z /var/log/console.log 640 5 100 * Z További információkat a &man.newsyslog.8; man oldaláról nyerhetünk. <filename>sysctl.conf</filename> sysctl.conf sysctl A sysctl.conf állomány leginkább az rc.conf állományhoz hasonlít, benne az értékeket változó=érték párokban adhatjuk meg. Az itt definiált értékek akkor kerülnek ténylegesen beállításra, amikor a rendszer többfelhasználós módba vált. Ezen a módon nem mindegyik változó értékét tudjuk átállítani. A sysctl.conf állományban az alábbi érték beállításával tudjuk beállítani, hogy a rendszer ne naplózza, amikor a programok végzetes jelzéssel fejezõdnek be, valamint azt, hogy a felhasználók láthassák egymás futó programjait: # Ne naplózzuk a végzetes jelzésekhez (például sig 11) tartozó kilépéseket. kern.logsigexit=0 # Ne engedjük a felhasználóknak, hogy lássák egy másik felhasználó # azonosítójával futó programokat. security.bsd.see_other_uids=0 Finomhangolás a sysctl használatával sysctl finomhangolás a sysctl használatával A &man.sysctl.8; egy olyan felület, amely lehetõséget biztosít egy mûködõ &os; rendszer megváltoztatására. Segítségével többek közt hozzáférhetünk a TCP/IP protokollkészlet és a virtuális memóriát kezelõ alrendszer rengeteg apró opciójához, melyek megfelelõ beállításával egy tapasztalt rendszergazda kezében drasztikusan növelhetõ a rendszer teljesítménye. A &man.sysctl.8; alkalmazásával több mint ötszáz rendszerszintû változó kérdezhetõ le és állítható be. A &man.sysctl.8; két funkciót rejt magában: a rendszer beállításainak lekérdezését és módosítását. Így nézhetjük meg az összes lekérdezhetó változót: &prompt.user; sysctl -a Így kérhetjük egy konkrét változó, például a kern.maxproc értékét: &prompt.user; sysctl kern.maxproc kern.maxproc: 1044 Egy adott változó értékének módosításához pedig használjuk a változó=érték felírást: &prompt.root; sysctl kern.maxfiles=5000 kern.maxfiles: 2088 -> 5000 A sysctl változók értékei lehetnek karakterláncok, számok és logikai értékek (ahol az 1 az igennek, a 0 a nemnek felel meg). Ha a számítógép indításakor automatikusan be akarunk állítani bizonyos változókat, akkor vegyük fel ezeket az /etc/sysctl.conf állományba. Ennek pontosabb részleteit a &man.sysctl.conf.5; man oldalon és a ban találhatjuk meg. Tom Rhodes Írta: A &man.sysctl.8; írásvédett értékei Egyes esetekben szükséges lehet a &man.sysctl.8; írásvédett változóinak módosítása. Habár gyakran elengedhetetlen, ezt kizárólag csak a rendszer (újra)indításakor tudjuk megtenni. Például egyes laptopoknál a &man.cardbus.4; eszköz nem próbálkozik több memóriaterület használatával, ezért egy ehhez hasonló hibával leáll: cbb0: Could not map register memory device_probe_and_attach: cbb0 attach returned 12 Az ilyen és ehhez hasonló esetekben gyakran olyan &man.sysctl.8; változók alapértelmezett értékeit kellene megváltoztatnunk, amelyek írásvédettek. Ilyenkor tegyük az érintett &man.sysctl.8; változó objektumazonosítóját (OID) és a hozzá tartozó értéket a /boot/loader.conf állományunkba. Az alapértelmezéseket a /boot/defaults/loader.conf állományban találjuk meg. A fentebb tárgyalt probléma megoldásához a felhasználónak a értéket kell beállítania az elõbb említett állományban. Ezután már a &man.cardbus.4; megfelelõen fog mûködni. A lemezek finomhangolása Sysctl változók <varname>vfs.vmiodirenable</varname> vfs.vmiodirenable A vfs.vmiodirenable sysctl változó értéke lehet 0 (ki) vagy 1 (be, és ez az alapértelmezés is). Ez a változó vezérli a könyvtárak gyorsítótárazását a rendszerben. A könyvtárak többsége kis méretû, így az állományrendszerbõl csak egyetlen (általában 1 KB méretû) darabkát használnak és még ennél is kevesebbet (általában 512 byte-ot) a pufferben. A változó kikapcsolt (avagy 0) értéke mellett a puffer csak rögzített számú könyvtárat táraz be még abban az esetben is, amikor temérdek mennyiségû memória áll a rendelkezésére. Ha viszont (az 1 értékkel) engedélyezzük, akkor a rendszer a könyvtárak tárazására felhasználja a virtuális memóriában pufferelt lapokat is, amivel lényegében az összes elérhetõ memóriát a könyvtárak tárazására fordítja. Ilyenkor azonban az egyes könyvtárak tárazására használt legkisebb memóriaterület a fizikai lapmérettel egyezik meg (ami általában 4 KB) és nem 512 byte. Abban az esetben javasoljuk ennek a beállításnak a használatát, ha olyan szolgáltatásokkal dolgozunk, amelyek nagy számú állománnyal dolgoznak egyszerre. Ilyen szolgáltatások többek közt a webes gyorsítótárak, nagyobb levelezõrendszerek és hírrendszerek. Az opció engedélyezése alapvetõen nem veti vissza a rendszer teljesítményét még akkor sem, ha ezzel memóriát pazarlunk el, de ezt igazából érdemes kikísérletezni. <varname>vfs.write_behind</varname> vfs.write_behind A vfs.write_behind sysctl változó alapértelmezett értéke 1 (bekapcsolt). Ez arra utasítja az állományrendszert, hogy csak akkor küldje ki az adatokat az eszközre, ha belõlük teljes fürtök gyûltek össze. Ez jellemzõ módon nagyobb szekvenciális állományok írása esetén kedvezõ. Arra szolgál, hogy segítségével el lehessen kerülni az I/O túlságosan gyakori módosítások okozta terhelését. Bizonyos körülmények közt ez azonban lassíthatja a futó programok mûködését, ezért ilyenkor érdemes megfontolni a kikapcsolását. <varname>vfs.hirunningspace</varname> vfs.hirunningspace A vfs.hirunningspace sysctl változó értéke azt adja meg, hogy tetszõleges számú példánynál rendszerszinten mekkora mértékû írási mûvelet irányítható át a lemezvezérlõk soraiba. Az alapértelmezés többnyire elegendõ, de olyan gépeken, ahol sok lemez dolgozik egyszerre, ez az érték négy vagy öt megabyte-ra is felszökhet! Hozzátennénk, hogy ha ezt az értéket túlságosan nagyra állítjuk (és így túllépjük a puffer írási küszöbértékét), akkor ezzel hihetetlenül gyenge fürtözési teljesítményt nyerünk. Semmiképp se állítsuk túlzottan nagy értékre! A nagyobb írási értékek a velük párhuzamos olvasások számára késleltetést is jelentenek. Találhatunk még más egyéb pufferelési és gyorsítótárazási sysctl változókat, azonban ezek megváltoztatását egyáltalán nem javasoljuk, mivel a virtuális memória alrendszer kiválóan tudja önállóan állítani ezeket a paramétereit. <varname>vm.swap_idle_enabled</varname> vm.swap_idle_enabled A vm.swap_idle_enabled sysctl változó módosítása olyan nagyobb többfelhasználós rendszerekben bizonyulhat hasznosnak, ahol sok felhasználó lép be és lép ki a rendszerbe és sok az üresjáratban futó program. Az ilyen jellegû rendszerek hajlamosak nagy mennyiségû folyamatos terhelést mérni a tartalékolt szabad memóriára. A beállítás engedélyezésével, valamint a vm.swap_idle_threshold1 és a vm.swap_idle_threshold2 változókon keresztül a kilapozás reakcióidejének alkalmas behangolásával a megszokottnál gyorsabban lenyomhatjuk az üresjáratban dolgozó programokhoz tartozó memórialapok prioritását, amivel a kilapozásokat vezérlõ démon kezére játszunk. Azonban tényleg csak akkor engedélyezzük ezt a lehetõséget, ha valóban szükségünk van rá, mivel így a memóriát jóval elõbb lapozzuk ki és ezzel több lapozóállományt és lemezteljesítményt emésztünk fel. Kisebb rendszerekben jól behatárolható a hatása, azonban a nagyobb rendszerekben, ahol már eleve visszafogott mértékû lapozás történik, ez a beállítás lehetõvé teszi a virtuális memóriát kezelõ alrendszer számára, hogy könnyedén ki- és be rakosgasson komplett futó programokat a memóriába. <varname>hw.ata.wc</varname> hw.ata.wc A &os; 4.3 egyszer már kacérkodott az IDE-lemezek írási pufferének kikapcsolásával. Ez ugyan csökkentette az IDE-lemezek írási sávszélességét, azonban bizonyos merevlemezgyártók gondatlanságából eredõ súlyos adatvesztések miatt szükséges volt a használata. A gond ezzel kapcsolatban ott van, hogy egyes IDE-meghajtók hazudnak az írások teljesítésérõl. A lemezek írási gyorsítótárazásának bekapcsolásával az IDE-meghajtók nem csak az írások sorrendjét rendezik át, hanem nagyobb terhelés esetén egyes blokkokat jóval késõbb is rögzítenek. Ezért a rendszer esetleges összeomlása vagy egy áramkimaradás súlyos károkat okozhat az állományrendszerben. A &os; úgy döntött, hogy a megbízhatóságot választja. Sajnos ez olyan nagyságú teljesítményvesztést okozott, hogy a következõ kiadásban már kénytelenek voltunk alapértelmezés szerint is visszakapcsolni ezt a lehetõséget. A hw.ata.wc nevû sysctl változó vizsgálatával ellenõrizhetjük a rendszerünkön érvényes alapértelmezett beállítást. Amennyiben az IDE írások gyorsítótárazása nem engedélyezett, akkor ezt a változó értékének 1-re állításával állíthatjuk vissza. Ezt a rendszer indításakor a rendszerbetöltõben tehetjük meg. A rendszermag indítása után ennek már nincs hatása. A részleteket a &man.ata.4; man oldalon tudhatjuk meg. <literal>SCSI_DELAY</literal> (<varname>kern.cam.scsi_delay</varname>) kern.cam.scsi_delay a rendszermag beállításai SCSI_DELAY A rendszermag SCSI_DELAY nevû beállítása a rendszer indulásának idejét hivatott mérsékelni. Az alapértelmezett értéke viszonylag magas, innen származik a rendszer indítása során keletkezõ 15 másodperces csúszás. Általában az is megfelelõ, ha ezt visszavesszük az 5 értékre (fõleg a modernebb meghajtók számára). A &os; újabb (5.0 vagy késõbbi) változataiban ez az érték már a kern.cam.scsi_delay sysctl változó értékével is megadható a rendszer indításakor. Azonban ügyeljünk rá, hogy mind a finomhangoláshoz használt változó, mind pedig rendszermag beállítása ezredmásodpercben és nem másodpercben értelmezi ezt az értéket. Soft Updates Soft Updates tunefs A &man.tunefs.8; nevû program használható az állományrendszerek finomhangolására. Nagyon sok opciót találhatunk benne, de itt most csak a Soft Updates ki- és bekapcsolásával foglalkozunk, amit a következõ módon tehetünk meg: &prompt.root; tunefs -n enable /allomanyrendszer &prompt.root; tunefs -n disable /allomanyrendszer Amíg egy állományrendszer csatlakoztatott állapotban van, addig nem módosítható a &man.tunefs.8; paranccsal. A Soft Updates bekapcsolására ezért az a legalkalmasabb idõpont, amikor egyfelhasználós módban vagyunk és még egyetlen partíciót sem csatlakoztattunk. A Soft Updates beállítás engedélyezése a memóriában pufferelt gyorsítótáron keresztül jelentõs mértékben fokozza a metaadatok teljesítményét, elsõsorban az állományok létrehozását és törlését. A Soft Updates használatát ezért minden állományrendszer esetén ajánljuk. A Soft Updates alkalmazásának két rossz oldalára kell tekintettel lennünk. Elõször is a Soft Updates a rendszer összeomlása esetén ugyan garantálja az állományrendszer konzisztenciáját, de könnyen elképzelhetõ, hogy több másodperccel (vagy akár egy egész perccel!) hátrébb jár a fizikai lemez frissítésében. Másodszor a Soft Updates késlelteti az állományrendszer blokkjainak felszabadítását. Ha van egy olyan állományrendszerünk (mint például a rendszer indításához használt gyökér partíció), ami már majdnem betelt, akkor egy nagyobb frissítés, például a make installworld parancs kiadása, során az állományrendszer egyszerûen kifogy a helybõl és így a frissítés meghiúsul. Bõvebben a Soft Updates mûködésérõl Soft Updates részletei Két hagyományos megközelítés létezik az állományrendszerek metaadatainak visszaírására. (A metaadatok módosításakor olyan nem adatot tartalmazó blokkok változnak meg, mint például az állományokra vonatkozó információk vagy a könyvtárak.) Eredetileg alapértelmezés szerint a metaadatok változásait szinkron módon írták ki. Amikor egy könyvtár megváltozott, a rendszer egészen addig várt, amíg ez a változás a lemezre nem íródott. Ugyanekkor az állományok adatait tartalmazó pufferek (az állományok tartalma) átkerültek a pufferelt gyorsítótárba, hogy majd késõbb, aszinkron módon kerüljenek kiírásra. Ennek az implementációnak a biztonságos mûködés volt az elõnye, mivel így a metaadatok még akkor is konzisztens állapotban maradtak, amikor valamilyen hiba következett be. Tehát egy állomány vagy teljesen létrejött vagy egyáltalán nem. Ha az állományhoz tartozó blokkok már nem tudtak kijutni a gyorsítótárból az összeomlás ideje elõtt, akkor az &man.fsck.8; felismerte ezt a helyzetet és az állományrendszer ilyen jellegû hibáját úgy orvosolta, hogy az adott állomány méretét nullára állította. Ezenkívül még az implementációs részletek is tiszták és egyszerûek maradtak. Ennek viszont hátránya, hogy a metaadatok kezelése lassú. Ha például kiadunk egy rm -r parancsot, akkor az a könyvtárban levõ állományokat szekvenciálisan dolgozza fel, de minden egyes változtatást (az állományok törlését) csak szinkron módon rögzíti a lemezre. Ezek a frissítések érintik magát a könyvtárat, az állományokkal kapcsolatos információkat tároló táblázatot (az ún. inode táblát) és minden valószínûség szerint az állományok által lefoglalt blokkokat is közvetve. Hasonló megfontolások élnek a nagyobb könyvtárszerkezetek kibontása esetén is (tar -x). A második lehetõség a metaadatok aszinkron frissítése. Ez az alapértelmezés a Linux ext2fs és BSD-k mount -o async opcióval csatlakoztatott UFS állományrendszerei esetén. Ilyenkor minden metaadattal kapcsolatos aktualizálás egyszerûen bekerült a pufferelt gyorsítótárba, tehát az állományok adatai és ezek a típusú frissítések keverednek. Ennek a megvalósításnak az az elõnye, hogy nem kell megvárni, amíg a metaadatok is kiíródnak a lemezre, ezért a metaadatok óriási mennyiségû változásával járó mûveletek sokkal gyorsabban hajtódnak végre, mint a szinkron esetben. Sõt, maga az implementáció is tiszta és egyszerû marad, ezért a kódban megjelenõ hibák beszivárgásának kockázata alacsony. A módszer hátránya, hogy egyáltalán semmilyen garanciát nem kapunk az állományrendszer konzisztenciájára. Ha tehát egy rengeteg metaadat megváltozásával együttjáró mûvelet közben történik valamilyen probléma (áramkimaradás, vagy valaki egyszerûen megnyomja a reset gombot), akkor az állományrendszer elõre kiszámíthatatlan állapotba kerül. A rendszer újbóli indításakor ezért nincs lehetõségünk megvizsgálni az állományrendszer állapotát. Elképzelhetõ, hogy az állományokhoz tartozó adatok már kikerültek a lemezre, miközben a rá vonatkozó inode- vagy könyvtári bejegyzések még nem. Így lényegében lehetetlen olyan fsck implementációt készíteni, ami képes lenne eltüntetni ezt a káoszt (hiszen az ehhez szükséges adatok nem állnak rendelkezésre). Ha az állományrendszer helyrehozhatatlanul károsodott, akkor csak a &man.newfs.8; és a biztonsági mentés visszaállítása segíthet rajta. Ezt általában úgy küszöbölik ki, hogy az egészhez hozzáteszik még a módosított területek feljegyzését, amit gyakran csak naplózásnak (journaling) neveznek, habár ezt az elnevezést nem mindenhol ilyen értelemben használják, ezért a tranzakciók naplózásának más formáira is utalhat. A metaadatok frissítése ebben az esetben is csak szinkron módon történik, de csak a lemez egy kisebb területére. Késõbb ez a megfelelõ helyére kerül. Mivel a lemez naplózásra fordított része egy viszonylag kis méretû, folytonos terület, a lemez fejének még a megterhelõbb mûveletek esetén sem kell sokat mozognia, ezért valójában ez a megoldás gyorsabb, mint a mezei szinkron frissítések. Az implementáció bonyolultsága továbbra is jól behatárolható, a velejáró hibalehetõségek kockázata alacsony. Hátránya, hogy minden metaadat kétszer íródik ki (egyszer a naplózási területre, aztán a megfelelõ helyre), ezért a hétköznapi használat során visszaesés tapasztalható a teljesítményben. Másrészrõl azonban egy összeomlás esetén a naplózási terület segítségével minden függõben levõ metaadattal kapcsolatos mûvelet könnyen visszafordítható vagy lezárható a rendszer következõ indításakor, így ezzel egy gyors helyreállítást nyerünk. Kirk McKusick, a Berkeley FFS fejlesztõje ezt a problémát a Soft Updates segítségével hidalta át: a metaadatokkal kapcsolatos minden függõben levõ frissítést a memóriában tart, majd ezeket rendezett sorrendben írja ki a lemezre (a metaadatok rendezett frissítése). Ennek következményeképpen a metaadatok komolyabb frissítése során a késõbb érkezõ módosításoknak lehetõségük van elkapni a memóriában levõ korábbi változataikat, ha azok még nem kerültek ki a lemezre. Így az összes, például könyvtárakon végzett, mûvelet a lemezre írás elõtt általában elõször a memóriában játszódik le (az adatblokkok a pozíciójuknak megfelelõen kerülnek rendezésre, ezért a rájuk vonatkozó metaadatok elõtt nem jutnak ki a lemezre). Ha eközben a rendszer összeomlik, akkor így implicit módon a napló visszalapozását eredményezi: minden olyan mûvelet, ami már nem tudott kijutni a lemezre, meg nem történtnek számít. Ezen a módon az állományrendszernek egy 30 és 60 másodperc közti korábbi állapota marad fenn. Az algoritmus garantálja, hogy az összes használt erõforrás a nekik megfelelõ bittérképekben helyesen jelölõdik, a blokkokban és az inode-okban. Az összeomlás után az erõforrások kiosztásával kapcsolatban csak egyetlen hiba léphet fel: amikor olyan erõforrások jelölõdnek használtnak, amelyek igazából szabadok. Az &man.fsck.8; azonban képes felismerni ezeket a helyzeteket és felszabadítani a nem használt erõforrásokat. A mount -f parancs kiadásával minden további következmény nélkül figyelmen kívül hagyhatjuk az állományrendszer félkész állapotát és csatlakoztathatjuk az állományrendszereket. A használatban már nem levõ erõforrások felszabadításához az &man.fsck.8; parancsot késõbb kell futtatni. Ez az alapötlet húzódik meg a háttérben végzett lemezellenõrzés mögött. A rendszer indításakor az állományrendszernek csupán egy pillanatképét rögzítjük, és az fsck tényleges lefuttatását késõbbre toljuk. Mivel mindegyik állományrendszer csatlakoztatható félkész állapotban, ezért a rendszer képes elindulni többfelhasználós módban. Eközben a háttérben az fsck beütemezhetõ minden olyan állományrendszer számára, ahol arra szükség van, hogy szabadítsa fel az esetlegesen már nem használt erõforrásokat. (Így a Soft Updates opciót nem alkalmazó állományrendszerek esetén továbbra is szükség van az elõtérben elvégzett fsck parancsra.) A módszer elõnye, hogy így a metaadatokkal kapcsolatos mûveletek közel olyan gyorsak, mint az aszinkron módon végzett frissítések (tehát gyorsabb, mintha naplóznánk, ami ugye minden metaadatot kétszer ír ki). A hátránya a bonyolultabb kód (ami miatt növekszik az olyan hibák lehetõsége, amelyek érzékenyen befolyásolhatják a felhasználói adatok elvesztését) és a nagyobb memóriaigény. Ezenkívül még van néhány olyan egyéni jellemzõje, amelyet meg kell szokni. A rendszer összeomlása után az állományrendszer valamivel régebbi lesz. Amikor pedig megszokott szinkron megközelítés szerint az fsck lefutása után nulla méretû állományok jönnének létre, ezek az állományok a Soft Updates esetén egyáltalán meg sem jelennek, mivel sem a rájuk vonatkozó metaadatok, sem pedig a tartalmuk nem került ki a lemezre. Egy rm lefuttatása után a lemezterület addig nem kerül felszabadításra, amíg a frissítések teljesen rá nem kerülnek a lemezre. Ez nagyobb mennyiségû adat telepítésekor gondokat okozhat egy olyan állományrendszeren, ahol nincs elegendõ hely az állományok kétszeri tárolására. A rendszermag korlátainak finomhangolása finomhangolás a rendszermag korlátai Az állományok és a futó programok korlátozásai <varname>kern.maxfiles</varname> kern.maxfiles A kern.maxfiles értéke a rendszerünk igényeinek megfelelõen növelhetõ vagy csökkenthetõ. Ez a változó adja meg a rendszerünkben levõ állományleírók maximális számát. Amikor az állományleírókat tároló táblázat megtelik, a rendszer üzenetpufferében egy file: table is full üzenet jelenik meg, amit a dmesg paranccsal tudunk megnézni. Minden megnyitott állomány, csatlakozás vagy FIFO elhasznál egy állományleírót. Egy nagyméretû szerver könnyen felemészthet több ezernyi állományleírót attól függõen, hogy milyen és mennyi szolgáltatást futtat egymás mellett. A &os; korábbi kiadásaiban a kern.maxfiles a rendszermag beállításait tartalmazó állomány (a rendszerben egyszerre jelenlevõ felhasználók maximumának) értékébõl származott, tehát a kern.maxfiles a értékével arányosan növekszik. Amikor készítünk egy saját rendszermagot, mindig érdemes a rendszerünk használatának megfelelõen beállítani ezt az értéket, mivel a rendszermag ebbõl a számból határozza meg a legtöbb elõre meghatározott korlátait. Mivel még egy komoly szerveren sem jelentkeznek be egyszerre 256 felhasználónál többen, nagyjából ugyanannyi erõforrásra van szüksége, mint egy nagyobb webszervernek. A kern.maxusers értéke a rendelkezésre álló memóriának megfelelõen magától méretezõdik a rendszer indításakor, és amit futás közben csak a kern.maxusers sysctl változó írásvédett értékének lekérdezésébõl tudhatunk meg. Egyes oldalak üzemeltetése a kern.maxusers így megállapított értékétõl nagyobbat vagy éppen kisebbet igényel, ezért a betöltéskor minden gond nélkül át lehet állítani 64, 128 vagy 256 értékûre. Senkinek sem ajánljuk, hogy 256 felé menjen, hacsak tényleg nincs szüksége ekkora mennyiségû állományleíróra. A kern.maxusers függvényében beállított alapértelmezett értékek tetszõleges módon átállíthatóak a rendszer indításakor vagy futás közben a /boot/loader.conf módosításával (az ide kapcsolódó javaslatokról bõvebben lásd a &man.loader.conf.5; man oldalt vagy a /boot/defaults/loader.conf állományt) illetve a leírás más részén megadott módok szerint. A korábbi kiadásokban úgy lehet önszabályozóra állítani a maxusers beállítást, ha explicit módon 0 értéket adtunk meg neki Az önszabályozó algoritmus a maxusers értékét a rendszerben található memóriának megfelelõen legalább 32-re, legfeljebb 384-re állítja. . A maxusers paraméter beállításakor érdemes legalább 4-et megadni, különösen akkor, ha használjuk az X Window Systemet vagy szoftvereket fordítunk le. Azért van erre szükség, mert a maxusers értéke által szabályozott legfontosabb mennyiség az egyszerre futtatható programok táblázatának maximális mérete, amelyet így számolunk ki: 20 + 16 * maxusers. Tehát ha a maxusers értékét 1-re állítjuk be, akkor az elõbbi képlet értelmében csak 36 programunk futhat egymással párhuzamosan, beleértve mindazt a kb. 18 programot, amelyek a rendszerrel együtt indulnak, illetve még azt a további 15 programot, amelyeket az X Window System használatával indítunk el. Még egy olyan egyszerû dolog is, mint például egy man oldal megnézése, legalább kilenc programot indít el a szûréshez, kitömörítéshez és megnézéshez. Azonban ha a maxusers értékét 64-re állítjuk, akkor egyszerre akár már 1044 programot futtathatunk, ami szinte mindenre elegendõ. Ha persze egy új program indításakor kapunk egy proc table full típusú üzenetet vagy nagy számú konkurens felhasználóval futtatunk szervert (ilyen például az ftp.FreeBSD.org), akkor érdemes növelni ezt a számot és újrafordítani a rendszermagot. A maxusers nem korlátozza a számítógépre egyszerre bejelentkezni képes felhasználók számát. Egyszerûen csak beállítja néhány táblázat méretét és az egyszerre futtatható programok mennyiségét a rendszert egyidejûleg használni kívánó felhasználók maximális számának figyelembevételével. <varname>kern.ipc.somaxconn</varname> kern.ipc.somaxconn Az kern.ipc.somaxconn sysctl változó a beérkezõ TCP kapcsolatokat fogadó sor hosszát határozza meg. Ennek az alapértelmezett értéke 128, ami az új kapcsolatok megbízható kezeléséhez általában kevés egy erõsen leterhelt webszerver számára. Ilyen helyzetekben ezt az értéket javasolt 1024-re vagy még annál is nagyobbra állítani. Az egyes szolgáltatások démonai ugyan szintén korlátozni szokták a fogadósoruk méretét (például a &man.sendmail.8; vagy az Apache), de gyakran találunk a beállításai között olyat, amivel ennek a sornak a mérete növelhetõ. A nagyobb fogadósorok mellesleg jó szolgálatot tesznek a Denial of Service (DoS) típusú támadásokkal szemben is. Hálózati korlátozások A rendszermag NMBCLUSTERS nevû beállítása szab határt a rendszer részére elérhetõ memóriapufferek mennyiségének. Egy nagyobb forgalmú szerver esetén a pufferek alacsony száma gátat szabhat a &os; képességeinek. Minden klaszter nagyjából 2 KB memóriát takar, így az 1024-es érték azt jelenti, hogy a rendszermag memóriájából 2 megabyte-ot fordítunk a hálózati pufferelésre. Egyszerûen kiszámítható, mennyire is van szükségünk: ha van egy webszerverünk, amely egyszerre legfeljebb 1000 párhuzamos kapcsolatot fogad, és minden kapcsolat lefoglal 16 KB-ot a fogadó-, valamint újabb 16 KB-ot a küldõpuffer számára, akkor megközelítõleg 32 MB-nyi hálózati pufferre lesz szükségünk a webszerver hatékony mûködéséhez. Ezt az értéket gyakran még érdemes megszorozni kettõvel, így 2 x 32 MB / 2 KB = 64 MB / 2 KB = 32768. Több memóriával rendelkezõ számítógépek esetén egy 4096 és 32768 közti értéket javaslunk. Semmilyen körülmények között ne adjunk meg ennél nagyobb értéket, mert ezzel a rendszer már az indítása során összeomolhat. A &man.netstat.1; beállításával ellenõrizhetjük a hálózati klaszterek kihasználtságát. A kern.ipc.nmbclusters változó értékét a rendszer indításakor érdemes megváltoztatni. A &os; korábbi változataiban ehhez a rendszermag NMBCLUSTERS nevû &man.config.8; paraméterének módosítására van szükségünk. Az olyan forgalmasabb szervereken, ahol sokat használják a &man.sendfile.2; rendszerhívást, szükségünk lehet a &man.sendfile.2; által használt pufferek számának növelésére a rendszermag NFSBUFS nevû konfigurációs paraméterén vagy a /boot/loader.conf állományon keresztül (lásd &man.loader.8;). Amikor a futó programok közül sokan vannak sfbufa állapotban, akkor az egyértelmûen annak a jele, hogy ezen a paraméteren állítanunk kell. A kern.ipc.nsfbufs egy írásvédett változót, amelyet a rendszermag állít be. Ez a paraméter névlegesen a kern.maxusers változó értékének megfelelõen változik, de bizonyos esetekben ettõl függetlenül önállóan kell behangolni. Annak ellenére, hogy egy socketet blokkolásmentesnek jelöltünk meg, a &man.sendfile.2; meghívása egy blokkolásmentes socketre blokkolódást eredményezhet egészen addig, amíg a használatához elegendõ struct sf_buf struktúra össze nem gyûlik. <varname>net.inet.ip.portrange.*</varname> net.inet.ip.portrange.* A net.inet.ip.portrange.* sysctl változók vezérlik a TCP és UDP csatlakozásokhoz automatikusan hozzárendelt portszámok tartományát. Három ilyen tartomány létezik: az alsó, az alapértelmezett és a felsõ tartomány. A legtöbb hálózati program a net.inet.ip.portrange.first és net.inet.ip.portrange.last változók által rendre az 1024-tõl 5000-ig kijelölt alapértelmezett tartományt használja. A kimenõ kapcsolatok is rögzített porttartományokat követnek, és adott körülmények mellett be lehet állítani úgy a rendszerünket, hogy ezen kívül osszon ki portokat. Ez a legtöbbször akkor fordul elõ, amikor egy erõsen leterhelt webproxyt mûködtetünk. A porttartományok nem okoznak gondot olyan szervereknél, ahol általában bejövõ kapcsolatokra lehet számítani, tehát például webszerverek esetén, vagy ahol korlátozott a kimenõ kapcsolatok száma, mint például a levelek továbbításánál. Ha olyan helyzetbe keverednénk, ahol már kifutunk a felhasználható portokból, a net.inet.ip.portrange.last mérsékelt növelésével javasolt kitörni. Ilyenkor a 10000, 20000 vagy 30000 értékek elfogadhatóak. Amikor megváltoztatjuk a porttartományok határait, elõtte mindig gondoljuk át, milyen hatással lehet ez a tûzfalra. Egyes tûzfalak blokkolhatnak bizonyos tartományokat (általában az alacsonyabbakat) és arra számítanak, hogy a rendszerek a kimenõ kapcsolatokhoz a nagyobb számú portokat használják — ebbõl kifolyólag nem ajánlott csökkenteni a net.inet.ip.portrange.first értékét. A TCP sávszélesség-késletetés szorzat A TCP sávszélesség-késleltetés szorzatának korlátozása net.inet.tcp.inflight.enable A TCP sávszélesség-késleltetés szorzat korlátozása hasonlít a NetBSD-ben megtalálható TCP/Vegas implementációhoz. A net.inet.tcp.inflight.enable sysctl változó 1-re állításával lehet engedélyezni. A rendszer ilyenkor minden egyes kapcsolathoz megpróbálja kiszámítani a sávszélesség-késleltetés szorzatot és az optimális átviteli sebesség fenntartásához illeszkedõen korlátozni a hálózat felé küldött adatok sorának hosszát. Ez a lehetõség még olyankor bizonyulhat hasznosnak, amikor modemen, Gigabit Etherneten vagy nagysebességû WAN (vagy bármilyen más nagy sávszélesség-késleltetés szorzattal bíró) összeköttetéseken keresztül küldünk át adatokat, különösen abban az esetben, amikor ablakméretezést is használnunk vagy nagy küldési ablakot állítottunk be. Az engedélyezésekor ne felejtsük el net.inet.tcp.infligt.debug változót sem beállítani 0-ra (amivel így kikapcsoljuk a nyomkövetést),éles használat esetén pedig elõnyös lehet a net.inet.cp.inflight.min változót legalább 6144-re állítani. Azonban hozzátesszük, hogy összeköttetéstõl függõen a nagy minimum értékek tulajdonképpen kikapcsolják a sávszélességkorlátozást. Ez a korlátozási lehetõség csökkenti a közbensõ út adatainak és csomagváltásokhoz tartozó soroknak a méretét, miközben csökkenti a helyi számítógép felületén felépülõ sorok méretét is. Ha kevesebb csomagot rakunk be a sorba, akkor az interaktív kapcsolatok, különösen a lassabb modemek esetében, kisebb körbejárási idõvel (Round Trip Time) mûködnek. Továbbá megemlítenénk, hogy ez a lehetõség csak az adatok küldésére (feltöltésére, szerveroldalra) van hatással. Semmilyen befolyása nincs az adatok fogadására (letöltésére). A net.inet.tcp.inflight.stab állítgatása nem ajánlott. A paraméter értéke alapértelmezés szerint 20, ami legfeljebb 2 csomag hozzáadását jelenti a sávszélesség-késleltetés szorzat ablakának kiszámításakor. Erre a kiegészítõ ablakra azért van szükség, hogy stabilizálni tudjuk vele az algoritmust és javítani tudjuk a változó feltételekre adott reakciót, de lassabb összeköttetések esetében nagyobb ping idõket is eredményezhet (habár ezek még így kisebbek, mint ha nem használnánk az algoritmust). Ilyen esetekben megpróbálhatjuk 15-re, 10-re vagy esetleg 5-re visszavenni a paraméter értékét, de ekkor a kívánt hatás eléréséhez minden bizonnyal a net.inet.tcp.inflight.min értékét is redukálunk kell majd (például 3500-ra). Ezen paraméterek megváltoztatását csak végsõ esetben ajánljuk! Virtuális memória <varname>kern.maxvnodes</varname> A vnode egy állomány vagy könyvtár belsõ ábrázolása. Ennek megfelelõen a vnode-ok számának növelésével az operációs rendszer spórolni tud a lemezmûveletekkel. Ezt általában maga az operációs rendszer szabályozza, és nincs szükség a finomhangolására. Néhány esetben, amikor a lemezmûveletek jelentik a rendszerben a szûk keresztmetszetet és kezdenek elfogyni a vnode-ok, szükség lehet ennek a számnak a növelésére. Ehhez az inaktív és szabad fizikai memória mennyiségét kell számításba vennünk. Így kérhetjük le a pillanatnyilag használatban levõ vnode-ok mennyiségét: &prompt.root; sysctl vfs.numvnodes vfs.numvnodes: 91349 Így tudhatjuk meg a vnode-ok maximális számát: &prompt.root; sysctl kern.maxvnodes kern.maxvnodes: 100000 Ha a vnode-ok aktuális kihasználtsága megközelíti a csúcsértéket, nagyjából ezerrel javasolt megnövelni a kern.maxvnodes értékét. Ezután figyeljük továbbra is a vfs.numvnodes változását. Ha ismét felkúszik a maximális értékre, akkor növeljük megint egy keveset a kern.maxvnodes értékén. Eközben a &man.top.1; használatával figyelhetjük a memória kihasználtságának növekedését is, ilyenkor tehát több memóriának kell használatban lennie. A lapozóterület bõvítése Nem számít, mennyire tervezünk jól elõre, mindig elõfordulhat, hogy a rendszerünk mégsem teljesíti a kitûzött elvárásokat. Amennyiben további lapozóterület hozzáadására lenne szükségünk, azt igen könnyen megtehetjük. Háromféleképpen növelhetjük a lapozásra szánt területet: hozzáadunk a rendszerhez egy újabb merevlemezes meghajtót, NFS-en keresztül lapozunk, vagy egy már meglevõ partíción hozunk létre lapozóállományt. A lapozóterület titkosításával, valamint annak lehetõségeivel és okaival kapcsolatban lapozzuk fel a kézikönyv át. Lapozás egy új merevlemezre A lapozóterület bõvítésének legjobb módja természetesen remek indok egy új merevlemez beszerzésére is. Elvégre egy merevlemezt mindig fel tudunk ilyen célra használni. Ha ezt a megoldást választjuk, elõtte ajánlott (újra) elolvasni a kézikönyv ában a lapozóterületek elrendezésére vonatkozó javaslatokat. Lapozás NFS-en keresztül NFS-en keresztül csak akkor lapozzunk, ha ezt helyi lemezek segítségével nem tudjuk megtenni. Az NFS alapú lapozás hatékonyságát erõsen behatárolja a rendelkezésre álló hálózati sávszélesség és további terheket ró az NFS szerverünkre is. Lapozóállományok Lapozóállománynak egy adott méretû állományt hozzunk létre. Ebben a példában erre egy /usr/swap0 nevû, 64 MB méretû állományt fogunk használni. Természetesen bármilyen más nevet is választhatunk. Lapozóállomány létrehozása &os;-ben Gyõzõdjünk meg róla, hogy a rendszermagunk beállításai között megtalálható a memórialemez meghajtójának (&man.md.4;) használata. Ez a GENERIC rendszermag alapból tartalmazza. device md # Memória "lemezek" Hozzunk létre egy lapozóállományt (/usr/swap0): &prompt.root; dd if=/dev/zero of=/usr/swap0 bs=1024k count=64 Állítsuk be rá a megfelelõ engedélyeket (/usr/swap0): &prompt.root; chmod 0600 /usr/swap0 Adjuk meg a lapozóállományt az /etc/rc.conf állományban: swapfile="/usr/swap0" # Állítsuk be swapfile értékét, ha külsõ lapozóállományra van szükségünk. Indítsuk újra a számítógépünket, vagy a lapozóállomány azonnali használtba vételéhez írjuk be: &prompt.root; mdconfig -a -t vnode -f /usr/swap0 -u 0 && swapon /dev/md0 Hiten Pandya Írta: Tom Rhodes Energia- és erõforrásgazdálkodás Fontos a hardveres erõforrásaink hatékony kihasználása. Az ACPI megjelenése elõtt az operációs rendszerek csak nehézkesen és rugalmatlanul tudták kezelni a rendszer energiafelhasználási és hõszabályzási lehetõségeit. A hardvert a BIOS kezelte, ezért a felhasználó kevesebbet tudott látni és irányítani az energiagazdálkodási beállításokból. Az Fejlett energiagazdálkodás (Advanced Power Management, APM) ehhez nyújtott egy erõsen korlátozott felületet. Napjaink operációs rendszereiben az energia- és erõforráskezelés az egyik legfontosabb alkotóelem. Például, ha az operációs rendszerrel folyamatosan figyelni akarjuk a rendszer hõmérsékletének váratlan növekedését (és errõl figyelmeztetést kérni). A &os; kézikönyvének ezen szakaszában az ACPI-rõl adunk egy átfogó áttekintést, a végén pedig összefoglaljuk a témához tartozó irodalmat. Mi az ACPI? ACPI APM A speciális energia- és konfigurációs illesztõ felület (Advanced Configuration and Power Interface, avagy ACPI) gyártók egy csoportja által létrehozott szabvány, amely a hardveres erõforrások és az energiagazdálkodás egységes felületét rögzíti (innen a neve). Döntõ szerepet játszik a Beállítások és az energiagazdálkodás operációs rendszerek áltai vezérlésében, vagyis segítségével az operációs rendszer még nagyobb mértékben és rugalmassággal tudja irányítani ezeket a lehetõségeket. A modern operációs rendszerek az ACPI felbukkanásával kitolták a jelenleg meglevõ Plug and Play felületek korlátait. Az ACPI az APM közvetlen leszármazottja. A Fejlett energiagazdálkodás (APM) hiányosságai A Fejlett energiagazdálkodás (APM) a rendszer által felhasznált energiát annak elfoglaltsága alapján vezérli. Az APM-et támogató BIOS-t a (rendszert) gyártó állítja elõ és az adott hardverplatformra jellemzõ. Az APM operációs rendszerben levõ meghajtója hozzáférést biztosít az APM szoftveres felületéhez, amivel lehetõség nyílik az energiaszintek kezelésére. Az APM-et 2000 elõtt és körül még mindig használták egyes rendszerek gyártásánál. Az APM használata négy nagyobb gondot rejt magában. Elõször is, az energiagazdálkodást a (gyártófüggõ) BIOS végzi el, és az operációs rendszernek errõl semmilyen ismerete nincsen. Ennek egyik példája az, amikor a felhasználó az APM-et ismerõ BIOS-ban beállítja a merevlemezek automatikus kikapcsolásának idejét, majd amikor ez letelik, a BIOS az operációs rendszer tudta nélkül egyszerûen leállítja a lemezt. Másodszor: az APM mûködését a BIOS-ban programozták le, és teljesen az operációs rendszer hatáskörén túl tevékenykedik. Ez azt jelenti, hogy a felhasználó csak úgy tudja korrigálni az APM-es BIOS-ok problémáit, ha frissíti az alaplapi ROM-ot. Ez viszont egy nagyon kockázatos folyamat, amelynek hibája révén a rendszerünk helyrehozhatatlan állapotba kerülhet. Harmadszor: az APM alapvetõen egy gyártófüggõ megoldás, ami azt vonja maga után, hogy sok az átfedés (ugyanazt valósítják meg több módon), és ha az egyik gyártó BIOS-ában hibát találnak, akkor a másikéban az nem feltétlenül javítható. Végül, de nem utolsósorban, az APM alapú BIOS-okban nincs elég hely az igazán kifinomult energiagazdálkodási sémák vagy bármi más kialakítására, amivel a felhasználók képesek lennének az igényeikhez alakítani a számítógépet. A Plug and Play BIOS (PNPBIOS) sok szempontból megbízhatatlannak bizonyult. A PNPBIOS ráadásul egy 16 bites megoldás, ezért az operációs rendszereknek 16 bites emulációt kell használniuk a PNPBIOS eszközeinek eléréséhez. A &os; APM meghajtójának dokumentációját az &man.apm.4; man oldalon találjuk. Az <acronym>ACPI</acronym> beállítása Az acpi.ko meghajtó alapértelmezés szerint a &man.loader.8; segítségével töltõdik be, és ne is fordítsuk bele a rendszermagba. Ezt azzal tudnánk magyarázni, hogy modulokkal könnyebb dolgozni, például ha a rendszermag újrafordítása nélkül egy másik acpi.ko modult akarunk használni. Ezzel a lényegében a tesztelés is egyszerûbbé válik. Másik magyarázat, hogy a rendszer ACPI támogatása nem minden esetben mûködik rendesen. Ha a rendszer indítása során valamilyen problémát tapasztalunk, akkor próbálkozzunk meg az ACPI kikapcsolásával. Ezt a meghajtót nem lehet és nem is szabad kidobni a memóriából, mivel a hardverrel a rendszerbuszon keresztül tartja a kapcsolatot. Az ACPI a hint.acpi.0.disabled="1" sor megadásával kapcsolható a /boot/loader.conf állományban vagy a &man.loader.8; parancssorában. Az ACPI és az APM nem használató egyszerre. Közülük a késõbb betöltött magától kilép, ha észreveszi, hogy a másikuk már mûködésbe lépett. Az ACPI és az &man.acpiconf.8; használatával a rendszerünk készenléti módba helyezhetõ az valamint az 1-5 paraméterek megadásával. Ezek közül is a legtöbb felhasználó számára csak az 1 vagy a 3 (állapot mentése a fizikai memóriába) érdekes. Az 5 opció egy szoftveres kikapcsolást eredményez, ehhez hasonlóan: &prompt.root; halt -p A további opciók a &man.sysctl.8; man oldaláról érhetõek el. Ezen kívül még olvassuk el az &man.acpi.4; és &man.acpiconf.8; man oldalakat is. Nate Lawson Írta: Peter Schultz Segítségére volt még: Tom Rhodes A &os; <acronym>ACPI</acronym> támogatásának használata és nyomonkövetése ACPI problémák Az ACPI az eszközök felderítésének, energiagazdálkodásának és a korábban a BIOS által kezelt hardverek szabványosított hozzáférésének alapjaiban új módja. Az ACPI folyamatosan fejlõdik, de útját az egyes alaplapok ACPI Machine Language (AML) bytekód implementációjában megjelenõ hibák, a &os; rendszermag alrendszereinek befejezetlensége és az &intel; ACPI-CA értelmezõjében levõ hibák lassítják. Ez a leírás azzal a szándékkal készült, hogy segítsünk a felhasználóknak megtalálni az általuk tapasztalt problémák gyökerét és ezzel segíteni az ACPI fejlesztõket a nyomonkövetésében és kijavításában. A fejlesztõk köszönik, hogy ezt elolvassuk és segédkezünk a rendszerünkkel kapcsolatban felmerülõ problémák orvosolásában! A nyomkövetési információk beküldése Mielõtt beküldenénk bármilyen problémát is, gondoskodjunk róla, hogy a BIOS-unk, és ha lehetséges, akkor a beágyazott vezérlõk, legfrissebb verzióját használjuk. Megkérnénk azokat, akik hibát akarnak bejelenteni, hogy a következõ információkat küldjék a freebsd-acpi@FreeBSD.org címre: A hibás mûködés leírása, beleértve a rendszer típusát és gyártmányát, illetve minden olyat, aminek köze lehet a hibához. Ha eddig még nem tapasztaltuk, igyekezzünk minél pontosabban leírni a hiba keletkezésének folyamatát. A boot -v paranccsal indított rendszer &man.dmesg.8; kimenetét, beleértve a vizsgálni kívánt hiba által okozott összes hibaüzenetet. A boot -v paranccsal és az ACPI használata nélkül indított rendszer &man.dmesg.8; kimenete abban az esetben, ha ez segít megoldani a problémát. A sysctl hw.acpi parancs kimenete. Ezzel egyébként kitûnõen kideríthetõ, milyen lehetõségeket is kínál fel a rendszerünk. Az általunk használt ACPI forrásnyelvének (ACPI Source Language, ASL) elérhetõsége az interneten. Mivel ezek akár igen nagyok is lehetnek, ezért a listára közvetlenül ne küldjünk ASL kódokat! Az ASL másolatát az alábbi parancs kiadásával hozhatjuk létre: &prompt.root; acpidump -dt > név-rendszer.asl (Adjuk meg a név helyett a bejelentkezéshez használt nevünket, a rendszer helyett pedig a gyártót/típust. Például: njl-FooCo6000.asl) Habár a legtöbb fejlesztõ a &a.current;t figyeli, a problémáink leírását mindenképpen a &a.acpi.name; listára küldjük, hogy biztosan észrevegyék. A fejlesztõk azt kérik, hogy legyünk türelmesek, hiszen emellett mindannyian teljes állásban is dolgoznak. Ha az általunk felfedezett hiba nem teljesen egyértelmû, akkor a fejlesztõk valószínûleg meg fognak kérni arra, hogy a &man.send-pr.1; használatával hozzunk róla létre egy hivatalos hibajelentést. A hibajelentés készítésekor lehetõleg a fentebb megadott információkat ugyanúgy adjuk meg. Ez segít a probléma szemmel tartásában és elhárításában. Az &a.acpi.name; lista kihagyása nélkül közvetlenül ne küldjünk hibajelentést, mivel a hibabejelentõ rendszert elsõsorban emlékeztetõnek használjuk, nem pedig a hibák tényleges bejelentésére. Gyakran elõfordul, hogy valaki korábban már találkozott az adott problémával. Háttér ACPI Az ACPI minden olyan modern számítógépben megtalálható, mely megfelel az ia32 (x86), ia64 (Itanium) vagy amd64 (AMD) architektúrának. A teljes szabvány rengeteg lehetõséget biztosít, többek közt a processzor teljesítményének kezelését, az energiaszintek vezérlését, hõzónákat, különféle akkumulátor rendszereket, beágyazott vezérlõk és a buszok felsorolását. A legtöbb rendszer általában nem a teljes szabványt valósítja meg. Például egy asztali rendszer általában csak a buszok felsorolásával kapcsolatos részeket tartalmazza, miközben egy laptop felajánlhatja a hûtés és az akkumulátor kezelését is. A laptopokban gyakorta találunk készenléti üzemmódot a maguk elbonyolított formájában. Egy ACPI-nak megfelelõ rendszert számos összetevõ alkot. A BIOS-ok és chipkészletek gyártói a memóriában egy elõre rögzített ponton elhelyeznek bizonyos táblázatokat (például FADT), amelyekkel megadják például az APIC összerendeléseit (ezt az SMP rendszerek használják), a konfigurációs regisztereket és az egyszerûbb konfigurációs értékeket. Itt ezenkívül még bytekódok egy táblázata (amit Differenciált rendszerleírtó táblának, Differentiated System Description Table, DSDT nevezünk) is megtalálható, ahol az eszközök és módszerek nevei szerepelnek faszerû elrendezésben. Az ACPI-hoz tartozó meghajtónak képesnek kell lennie értelmezni ezeket a rögzített táblázatokat, implementálni egy bytekód-értelmezõt, módosítani az eszközmeghajtókat és a rendszermagot az ACPI alrendszerbõl érkezõ információk befogadásához. A Linuxszal és a NetBSD-vel közösen a &os; kapott egy ilyen értelmezõt az &intel;tõl (ACPI-CA). Az ACPI-CA forráskódja a rendszer forrásai között, a src/sys/dev/acpica könyvtárban található. A src/sys/dev/acpica/0sd könyvtárban található források pedig lehetõvé teszik, hogy az ACPI-CA mûködhessen &os;-n. Végezetül, az ACPI eszközöket megvalósító meghajtók a src/sys/dev/acpica könyvtárban találhatóak. Gyakori problémák ACPI problémák Az ACPI megfelelõ mûködéséhez minden alkotórésznek helyesen kell mûködnie. A most következendõkben elõfordulásuk gyakorisága szerint felsorolunk néhány ismert problémát, valamint a hozzájuk tartozó javításokat vagy elkerülésük módszerét. Gondok az egérrel Egyes esetekben felfüggesztett állapotból visszatérve az egerünk nem hajlandó mûködni. Ezt úgy lehet elkerülni, ha /boot/loader.conf állományba beírjuk a hint.psm.0.flags="0x3000" sort. Ha ez nem segít, akkor a fentieknek megfelelõen küldjünk be egy hibajelentést. Felfüggesztés/Folytatás Az ACPI három (STR) állapotban képes a fizikai memória segítségével készenléti módba váltani, ezek az S1-S3, és egy állapotban használja a lemezt (STD), amelyet S4-nek hívnak. Az S5 neve a szoftveres kikapcsolás, ami egy olyan állapotot takar, amikor a rendszerünk áram alatt van, de még nem üzemel. Az S4BIOS állapot a BIOS segítségével a lemezre menti a rendszert, az S4OS állapotot pedig teljes egészében az operációs rendszer valósítja meg. A rendszerünk által ismert készenléti módokat a sysctl hw.acpi paranccsal ellenõrizhetjük. Íme mindez egy Thinkpad esetén: hw.acpi.supported_sleep_state: S3 S4 S5 hw.acpi.s4bios: 0 Ez azt jelenti, hogy az acpiconf -s parancs kiadásával kipróbálhatjuk az S3, S4OS, és S5 állapotokat. Ha az értéke egy (1), akkor az S4BIOS támogatása helyett az S4 OS állapotot kapjuk. A felfüggesztés és folytatás kipróbálása során kezdjük az S1 állapottal, már amennyiben az támogatott a rendszerünkön. Ez az állapot többnyire használható, mivel nem igényel túlságosan sok támogatást a meghajtó részérõl. Eddig még senki sem implementálta az S2 állapotot, de ha ezt is tudja a rendszerünk, akkor az S1-hez hasonlót nyerünk vele. A következõ próba az S3 állapoté. Ez a legmélyebb STR állapot, és a hardver megfelelõ újraélesztéséhez rengeteg támogatás szükségeltetik a meghajtó részérõl. Ha gondjaink lennének a rendszerünk felébresztésével, nyugodtan írjunk egy levelet a &a.acpi.name; listára, ám a probléma gyors megoldódásában ne reménykedjünk, hiszen ehhez még temérdek meghajtón és hardveren kell tesztelni és kell dolgozni. Felfüggesztés és folytatás esetén gyakori probléma, hogy sok eszközmeghajtó nem menti el, nem állítja vissza vagy éppen nem hozza újra rendesen mûködésbe az adott eszközön található firmware-t, a regisztereket vagy memóriát. Az okok felderítéséhez elõször érdemes a következõket kipróbálni: &prompt.root; sysctl debug.bootverbose=1 &prompt.root; sysctl debug.acpi.suspend_bounce=1 &prompt.root; acpiconf -s 3 Ezzel a módszerrel tesztelni tudjuk az összes meghajtó felfüggesztési és folytatási rutinjait anélkül, hogy ténylegesen S3 állapotba helyeznénk az eszközt. Bizonyos esetekben ezzel könnyen elcsíphetõ a hiba (például a firmware állapotának elvesztése, watchdog time out, megállás nélküli újrapróbálkozások). A rendszer ilyenkor nem vált S3 állapotra, vagyis az eszköz nem kerül energiatakarékos állapotba, és eltérõen a valós S3 állapottól továbbra is mûködik még abban az esetben is, amikor a szükséges felfüggesztési és folytatási rutinok teljesen hiányoznak. Komolyabb esetben további segédeszközökre lesz szükségünk, vagyis soros portra és kábelre a soros vonali nyomkövetéshez, vagy Firewire portra és kábelre a &man.dcons.4; használatához, valamint némi tapasztalatra a rendszermagon belüli hibakeresésben. A problémát nagy mértékben segíti különválasztani, ha igyekszünk minél több meghajtót kivenni a rendszermagból. Ha így javul a helyzet, akkor már könnyen le lehet szûkíteni arra a meghajtóra a kört, aminek betöltésével esetleg gondok akadhatnak. Általában ilyenek a bináris meghajtók, mint például az nvidia.ko, az X11 megjelenítésért felelõs és az USB eszközök meghajtói, miközben az Ethernet eszközök remekül szoktak mûködni. Ha különösebb gond nélkül képesek vagyunk betölteni és eltávolítani ezeket a meghajtókat, akkor ezt a folyamatot önállósítani is tudjuk úgy, hogy az /etc/rc.suspend és /etc/rc.resume szkriptekbe beillesztjük az ehhez szükséges parancsokat. Ezekben egyébként találunk is egy megjegyzésbe rakott példát a meghajtók betöltésérõl és eltávolításáról. Ha az ébresztés után elszemetelõdik a képernyõ tartalma, akkor állítsuk át a változó értékét nullára (0). Sokat segíthet meg az is, ha a értékét csökkentjük vagy növeljük. Megpróbálhatjuk azt is, hogy elindítunk egy frissebb Linux disztribúciót ACPI támogatással és ugyanazon a hardveren kipróbáljuk az általa felkínált felfüggesztési és folytatási lehetõséget. Ha Linux alatt ez megbízhatóan mûködik, akkor nagy a valószínûsége, hogy ez &os; alatt az egyik meghajtó hibájából fakadóan nem használható. Így fokozatosan le is tudjuk szûkíteni, hogy pontosan melyikkel lehet a gond, és ezzel a fejlesztõk munkáját segítjük. Megjegyeznénk, hogy az ACPI-t karbantartó fejlesztõk általában nem foglalkoznak más meghajtókkal (például hangkártya vagy ATA stb.), ezért az adott meghajtóval kapcsolatos hibáról javasolt értesíteni a &a.current.name; listát és a meghajtóért felelõs fejlesztõt is. Ha van egy kis kedvünk és idõnk, mi magunk is belebiggyeszthetünk a meghajtóba néhány &man.printf.3; függvényt annak kiderítésére, pontosan hol is fagy le a folytatási funkció. Végül megpróbálkozhatunk az ACPI kikapcsolásával is, és áttérhetünk helyette az APM használatára. Ha az APM-mel mûködnek a készenléti állapotok, akkor érdemes inkább azzal dolgozni, különösen a régebbi (2000 elõtti) hardverek esetében. A gyártóknak eltartott egy ideig, amíg rendes ACPI támogatást voltak képesek adni, ezért a régebbi hardvereknél inkább a BIOS-nak akadnak gondjai az ACPI-val. A rendszer lemerevedik (ideiglenesen vagy teljesen) A legtöbb rendszer olyankor akad meg, amikor sok megszakítás elveszik, vagy amikor éppen sok megszakítás érkezik egyszerre. A chipkészleteknek számos baja származik abból, hogy a BIOS milyen módon állítja be a rendszer indítása elõtt a megszakításokat, mennyire helyes az APIC (MADT) táblázata és hogyan vezérli a Rendszervezérlõ megszakítást (System Control Interrupt, SCI). megszakítás-viharok A megszakítás-viharok a vmstat -i parancs kimenetében szereplõ elveszett megszakításokból azonosíthatók be, ahol keressünk rá az acpi0 sorra. Ha ez a számláló másodpercenként kettõnél többel növekszik, akkor a megszakításaink viharba keveredtek. Ha a rendszer látszólag lefagyott, próbáljuk meg elõhívni a DDB-t (konzolban a CTRLALTESC ) és gépeljük be, hogy show interrupts. APIC kikapcsolása A megszakítási problémákkal kapcsolatban egyetlen reményünk az APIC támogatás kikapcsolása lehet a loader.conf állományban a hint.apic.0.disabled="1" sor hozzáadásával. Végzetes hibák Az ACPI-vel kapcsolatos végzetes hibák viszonylag ritkák, és javításuk a legfontosabb. Ilyenkor az elsõ teendõnk elkülöníteni a hiba reprodukálásának egyes lépéseit és (ha lehetséges) lekérni a hívási láncot. Kövessük az options DDB és a soros vonali konzol beállításához adott tanácsokat (lásd ) vagy hozzunk létre egy &man.dump.8; partíciót. A DDB-ben a hívási láncot a tr parancs segítségével kérhetjük le. Ha kézzel írjuk le láncot, akkor legalább az alsó öt (5) és a felsõ öt (5) sorát mindenképpen jegyezzük fel! Ezután próbáljuk meg úgy szûkíteni a probléma lehetõségét, hogy az ACPI használata nélkül indítjuk a rendszert. Ha ezzel nincs semmi gond, akkor a változó értékének megfelelõ beállításával egyenként meg tudjuk figyelni az ACPI alrendszer egyes részeit. Ehhez példákat az &man.acpi.4; man oldalon találunk. Felfüggesztés vagy leállítás után elindul a rendszer Elõször is próbáljuk meg a hw.acpi.disable_on_poweroff változó értékét 0-ra állítani a &man.loader.conf.5; állományban. Ezzel távoltartjuk az ACPI alrendszert a rendszer leállítási folyamatától. Egyes rendszereknek valamilyen okból kifolyólag szükségük van itt az 1 (az alapértelmezett) értékre. Ez többnyire megoldja a problémát, amikor a rendszer váratlanul elindul a készenléti mód aktiválásákor vagy kikapcsoláskor. Egyéb problémák Ha más gondjaink lennének az ACPI-val (dokkoló állomásunk van, egyes eszközöket nem vesz észre stb.), akkor természetesen errõl is küldjünk egy leírást a levelezési listára. Azonban vegyük figyelembe, hogy egyes problémák a ACPI alrendszer eddig még nem implementált, befejezetlen részeihez kötõdnek, ezért azok megoldása még várat magára. Kérünk mindenkit, hogy legyen türelemmel és álljon készen a kiküldött javítások tesztelésére! <acronym>ASL</acronym>, <command>acpidump</command> és <acronym>IASL</acronym> ACPI ASL A problémák leggyakoribb forrása, hogy a BIOS-gyártók rossz (vagy kifejezetten hibás!) bytekódokat adnak. Ez általában a következõhöz hasonló rendszerüzenetbõl derül ki: ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.FIGD._STA] \\ (Node 0xc3f6d160), AE_NOT_FOUND Az ilyen jellegû hibákat gyakran úgy lehet orvosolni, ha a BIOS-unkat frissítjük a legújabb verzióra. A legtöbb ilyen üzenet teljesen ártalmatlan, de ha vannak más problémáink is, például az akkumulátor állapota nem olvasható le, akkor elõször az AML környékén érdemes kutakodnunk. A bytekód, más néven AML, az ASL elnevezésû forrásnyelvbõl származik. Az AML egy DSDT néven ismert táblázatban található meg. Az ASL másolatát az &man.acpidump.8; paranccsal készíthetjük el. Paraméterként egyaránt adjuk meg a (megmutatja a rögzített táblák tartalmát) és (visszafejti az AML kódokat az ASL nyelvére) kapcsolókat. A felírás pontos formátumát a A nyomkövetési információk beküldése címû szakaszban olvashatjuk. Elsõként próbáljuk meg újrafordítani az így nyert ASL programot és keressünk benne hibákat. A figyelmeztetések általában nyugodtan figyelmen kívül hagyhatóak, azonban a hibák olyan implementációs hibákra utalnak, amelyek akadályozzák az ACPI helyes mûködését. Az ASL újrafordítását az alábbi paranccsal tudjuk elvégezni: &prompt.root; iasl saját.asl Az <acronym>ASL</acronym> kijavítása ACPI ASL Végeredményben az a célunk, hogy az ACPI megfelelõ mûködéséhez senkinek se kelljen hozzányúlnia semmihez. Azonban még mindig szükség van BIOS-gyártók által elkövetett gyakori hibák elkerülésének kifejlesztésére. A µsoft; értelmezõje (acpi.sys és acpiec.sys) nem ellenõrzi szigorúan a szabvány szerinti megfelelést, ezért számos olyan BIOS-gyártó, akik csak &windows; alatt tesztelik az ACPI implementációjukat, soha nem fogják kijavítani a ASL kódjukban ejtett hibáikat. Reménykedünk, hogy folyamatosan sikerül felderíteni és dokumentálni a µsoft; értelmezõje által eltûrt szabványon kívüli viselkedést és leutánozni &os; alatt is, hogy így ne kelljen a felhasználóknak kézzel a saját ASL forrásaikat javítgatni. Az ebbõl fakadó hibákat úgy tudjuk elkerülni és segíteni a fejlesztõknek azonosítani a hozzá társuló viselkedést, hogy magunk javítjuk az ASL-ben felfedezett hibákat. Ha ez beválik, akkor küldjük el a régi és új ASL közti &man.diff.1;-et a fejlesztõknek, akik így majd az ACPI-CA-ban ki tudnak dolgozni egy megoldást a hibás viselkedésre, ezzel a javításunk szükségtelenné válik. ACPI hibaüzenetek Most pedig következzenek a legismertebb hibaüzenetek, az okaik és javításuk: Operációs rendszeri függõségek Néhány AML úgy gondolja, hogy a világ csak a különbözõ &windows; verziókból áll. A &os;-nek megadható, hogy másik operációs rendszernek adja ki magát, és ezzel talán meg is szüntethetõ pár hiba. Ezt a legegyszerûbb úgy tudjuk megtenni, ha a /boot/loader.conf állományhoz hozzáfûzzük a hw.acpi.osname="Windows 2001" sort, vagy itt egy olyan karakterláncot adunk meg, amit az ASL forrásban láttunk. Hiányzó visszatérési érték Bizonyos módszerek a szabvány szerint elvártaktól eltérõen nem adnak vissza explicit módon értéket. Mivel az ACPI-CA ezt nem kezeli le, ezért a &os; részérõl tartalmaz egy olyan módosítást, amivel implicit módon is vissza lehet adni értéket. Ha biztosak akarunk lenni a visszaadni kívánt értékben, akkor helyezzünk el a megfelelõ helyekre explicit Return utasításokat. Az iasl a paraméterrel kényszeríthetõ az ilyen ASL források lefordítására. Az alapértelmezett <acronym>AML</acronym> felülbírálása Miután módosítottuk a saját.asl állományunkat, így tudjuk lefordítani: &prompt.root; iasl saját.asl Az kapcsoló megadásával kikényszeríthetjük az AML létrehozását még abban az esetben is, amikor hibákat tartalmaz. Ügyeljünk rá, hogy bizonyos hibákat (például a hiányzó visszatérési értékeket) a fordító magától kikerül. Az iasl alapértelmezett kimenete a DSDT.aml állomány. A /boot/loader.conf átírásával így tudjuk ezzel helyettesíteni a BIOS-unk hibás változatát (ami még mindig megtalálható a flash memóriában): acpi_dsdt_load="YES" acpi_dsdt_name="/boot/DSDT.aml" Ehhez ne felejtsük el a saját DSDT.aml állományunkat bemásolni a /boot könyvtárba. Nyomkövetési információk kinyerése az <acronym>ACPI</acronym>-bõl ACPI problémák ACPI nyomkövetés Az ACPI meghajtója nagyon rugalmas nyomkövetési lehetõségekkel rendelkezik. Ennek révén ugyanúgy megadhatjuk a nyomonkövetni kívánt alrendszert, mint ahogy annak mélységét is. A nyomkövetni kívánt alrendszereket rétegekként adjuk meg, valamint ezek ACPI-CA komponensekre (ACPI_ALL_COMPONENTS) és ACPI hardvertámogatásra (ACPI_ALL_DRIVERS) bomlanak le. A nyomkövetéskor keletkezõ kimenet részletességét a szintként adjuk meg, ami az ACPI_LV_ERROR-tól (csak a hibák) ACPI_LV_VERBOSE-ig (minden) terjedhet. A szint itt egy bitmaszk, ezért szóközzel elválasztva egyszerre több beállítás megadható. Ha túlságosan sok üzenet érkezik a konzol üzenetpufferébe, akkor szükségünk lehet a soros konzol keresztüli nyomkövetésre is. Az összes szint és réteg az &man.acpi.4; man oldalon található meg. A nyomkövetés alapértelmezés szerint nem engedélyezett. Az engedélyezéséhez hozzá kell adnunk az options ACPI_DEBUG sort a rendszermagunk beállításait tartalmazó állományhoz, amennyiben a rendszermagba fordítjuk az ACPI támogatást. Ha az /etc/make.conf állományba írjuk bele az ACPI_DEBUG=1 sort, akkor azt globálisan engedélyezhetjük. Ha modulként használjuk, elegendõ csak a következõ módon újrafordítani az acpi.ko modult: &prompt.root; cd /sys/modules/acpi/acpi && make clean && make ACPI_DEBUG=1 Telepítsük fel a acpi.ko modult a /boot/kernel könyvtárba és állítsuk be a számunkra megfelelõ szintet és réteget a loader.conf állományban. Az alábbi példában engedélyezzük az összes ACPI-CA komponens és az összes ACPI hardvermeghajtó (processzor, LID stb.) nyomkövetését. Csak a hibaüzeneteket írja ki részletesen. debug.acpi.layer="ACPI_ALL_COMPONENTS ACPI_ALL_DRIVERS" debug.acpi.level="ACPI_LV_ERROR" Ha az általunk keresett információt egy adott esemény váltja ki (például egy felfüggesztés vagy egy ébresztés), akkor nem is fontos átírnunk hozzá a loader.conf állományt, hanem helyette a rendszer indítása után használjuk a sysctl parancsot a réteg és a szint megadására akkor, amikor a rendszert felkészítjük az eseményre. A sysctl változókat ugyanúgy nevezték el, mint a loader.conf állományban található beállításokat. Hivatkozások Az ACPI-rõl az alábbi helyeken találunk részletesebb információkat: A &a.acpi; Az ACPI levelezési lista archívuma: A korábbi ACPI levelezési lista archívuma: Az ACPI 2.0 specifikációja: A &os; következõ man oldalai: &man.acpi.4;, &man.acpi.thermal.4;, &man.acpidump.8;, &man.iasl.8;, &man.acpidb.8; A DSDT nyomkövetése (angolul). (Példának a Compaqot hozza fel, de általánosságban véve hasznos.) diff --git a/hu_HU.ISO8859-2/books/handbook/cutting-edge/chapter.sgml b/hu_HU.ISO8859-2/books/handbook/cutting-edge/chapter.sgml index 02f639904f..edd7753cd4 100644 --- a/hu_HU.ISO8859-2/books/handbook/cutting-edge/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/cutting-edge/chapter.sgml @@ -1,4607 +1,4613 @@ Jim Mock Átdolgozta, átrendezte és egyes részeit aktualizálta: Jordan Hubbard Eredetileg írta: Poul-Henning Kamp John Polstra Nik Clayton A &os; frissítése és frissen tartása Áttekintés A &os; a kiadások közt is állandó fejlõdésben van. Vannak felhasználók, akik a hivatalosan kiadott változatokat használják, és vannak, akik szeretik folyamatosan nyomonkövetni a fejlesztéseket. Emellett viszont a hivatalos kiadások esetében szükség lehet bizonyos biztonsági frissítések és kritikus javítások alkalmazására. Függetlenül a pillanatnyilag használt változattól, a &os; alaprendszerében megtalálható minden olyan eszköz, amellyel könnyedén frissíteni tudunk a különbözõ verziók között. Ebben a fejezetben segítünk dönteni a fejlesztõi változat és a kiadások használata között. Továbbá megismerhetjük a rendszer frissítéséhez használható alapvetõ eszközöket. A fejezet elolvasása során megismerjük: milyen segédprogramokkal tudjuk frissíteni az alaprendszert és a Portgyûjteményt; hogyan tartsuk naprakészen rendszerünket a freebsd-update, CVSup, CVS vagy CTM használatával; hogyan vessük össze a telepített rendszerünk aktuális állapotát egy ismert eredeti változattal; hogyan frissítsük a dokumentációt CVSup vagy dokumentációs portok segítségével. a két fejlesztõi ág, a &os.stable; és a &os.current; közti különbséget; a make buildworld (stb.) segítségével hogyan fordítsuk és telepítsük újra az egész alaprendszert. A fejezet elolvasásához ajánlott: a hálózati kapcsolatunk helyes beállítása (); a külsõ szoftverek telepítésének ismerete (). A fejezetben a &os; forrásainak frissítését a cvsup parancs segítségével fogjuk elvégezni. Ehhez telepítsük a net/cvsup portot vagy csomagot (ha a cvsup parancsot nem akarjuk grafikus felületen keresztül használni, akkor elegendõ csak a net/cvsup-without-gui portot). Ha a &os; 6.2-RELEASE vagy késõbbi változatával rendelkezünk, akkor elegendõ csak az alaprendszer részeként elérhetõ &man.csup.1; programot használnunk. Tom Rhodes Írta: Colin Percival A megíráshoz felhasznált jegyzeteket készítette: A &os; frissítése frissítés és frissen tartás freebsd-update frissítés és frissen tartás A biztonsági javítások telepítése minden számítógépes szoftver, különösen az operációs rendszerek számára lényeges mozzanat. Nagyon hosszú ideig ez a &os; esetében nem volt könnyen megoldható: a javításokat közvetlenül a forráskódon kellett elvégezni, ezekbõl újrafordítani a rendszert, majd telepíteni. Ez a nehézség mostanra viszont már elhárult, mivel a &os; legfrissebb verziói már tartalmaznak egy freebsd-update nevû segédprogramot, amellyel mindez leegyszerûsödik. Ez a program két külön funkciót lát el. Elõször is, lehetõvé teszi, hogy a &os; alaprendszer újrafordítása és -telepítése nélkül javítsunk biztonsági és egyéb apró hibákat, valamint másodsorban támogatja a kisebb és nagyobb verziójú kiadások közti váltást. Ezek a bináris frissítések azonban csak a &os; biztonsági csapata által is felügyelt architektúrák és kiadások esetén érhetõek el. Emellett bizonyos lehetõségek használatához, például a &os; verziói közti átállás támogatásához a &man.freebsd-update.8; legújabb változata szükségeltetik. Ezért ne felejtsük el alaposan átolvasni a legújabb kiadásokról szóló bejelentéseket mielõtt frissítenénk rájuk, mivel ezzel kapcsolatban fontos információkat tartalmazhatnak. Az említett bejelentések a címen érhetõek el. Ha a crontab már hivatkozik a freebsd-update programra, akkor a most következõ mûvelet elkezdése elõtt tiltsuk le. A konfigurációs állományok Ha változtatnénk szeretnénk a frissítési folyamaton, ekkor a programhoz tartozó, /etc/freebsd-update.conf nevû konfigurációs állományt kell módosítanunk. Az opciók részletes ismertetéssel rendelkeznek, habár némelyiknél még további magyarázat kellhet: # Az alaprendszerben frissíteni kívánt komponensek Components src world kernel Ezzel a paraméterrel határozhatjuk meg, hogy a &os; mely részei kerüljenek frissítésre. Alapértelmezés szerint a program frissíti a forrásokat, a teljes alaprendszert és a rendszermagot. Komponensként a telepítésnél választható elemeket adhatjuk meg, például "world/games" hozzáadásakor a games kategória elemei is folyamatosan frissülni fognak. Az "src/bin" megadásakor pedig az src/bin könyvtár tartalma frissül. Ezt a beállítást a legjobb meghagyni az alapértelmezett értéken, mivel a további elemek megadásánál egyenként fel kell sorolni a frissítendõ komponenseket. Ha itt viszont kifelejtünk valamit, akkor könnyen megeshet, hogy a források és a binárisok verziója elcsúszik egymástól. # Az IgnorePaths beállítás után megadott szövegre illeszkedõ összes # bejegyzés frissítése kimarad IgnorePaths Ennél a beállításnál azokat a könyvtárakat kell megadnunk, amelyeket (és tartalmukat) ki szeretnénk hagyni a frissítés során. Ezek lehetnek például a /bin vagy az /sbin. Így meg tudjuk akadályozni, hogy freebsd-update esetleg felülírjon valamilyen helyi változtatást a rendszerünkben. # Az UpdateIfUnmodified beállítás után megadott elérési útvonalakon csak # a felhasználó által még nem módosított állományok fognak frissülni # (hacsak a módosításokat össze nem fésüljük, lásd lentebb) UpdateIfUnmodified /etc/ /var/ /root/ /.cshrc /.profile A megadott könyvtárakban csak azokat a konfigurációs állományokat fogja frissíteni, amelyeket nem változtattuk meg. Amennyiben bármelyikük eltér az eredetileg frissítendõ változattól, azt a program nem módosítja. Létezik egy másik hasonló beállítás, a KeepModifiedMetadata, amely hatására a freebsd-update az összefésülés során elmenti a változtatásokat. # A MergeChanges beállításnál szereplõ állományok helyi módosításait # automatikusan összefésüljük a &os; újabb verziójára frissítése közben MergeChanges /etc/ /var/named/etc/ Itt azokat a könyvtárakat adhatjuk meg, amelyekben a freebsd-update számára engedélyezzük a konfigurációs állományok új verziójának összefésülését a jelenlegi állapottal. Az összefésülés lényegében a &man.mergemaster.8; használatánál már megszokott módon, &man.diff.1; formátumban érkezõ módosítások sorozata alapján történik. Ekkor egy szövegszerkesztõ segítségével felügyelhetjük az összefésülés menetét vagy megállíthatjuk a freebsd-update futását. Ha kétségeink adódnak, akkor egyszerûen mentsük le az /etc könyvtárat és fogadjuk el mindegyik összefésülés eredményét. A mergemaster mûködésérõl a ad részletesebb tájékoztatást. # A &os; frissítésekor ezt a könyvtárat fogja a program használni a # letöltött módosítások és az egyéb ideiglenes állományok tárolására # WorkDir /var/db/freebsd-update Az itt megadott könyvtárba fognak kerülni az elvégzendõ módosítások és az egyéb ideiglenesen keletkezõ állományok. A verziók közti váltás során ebben a könyvtárban ajánlott legalább 1 GB szabad tárterületnek lennie. # A kiadások közti váltás során a Components beállításnál megadott # elemek kerüljenek csak frissítésre (StrictComponents yes), vagy a # program próbálja meg magától kitalálni, hogy milyen komponesek # *lehetnek* fenn a rendszeren és azokat frissítse (StrictComponents # no)? # StrictComponents no Ha ennél a beállításnál a yes értéket adjuk meg, akkor a freebsd-update feltételezni fogja, hogy a Components opciónál felsoroltunk minden frissítendõ komponenst és nem próbál meg mást is megváltoztatni. Ilyenkor tehát a freebsd-update tulajdonképpen egyedül csak a Components által meghatározott elemekhez tartozó állományokat fogja frissíteni. Biztonsági javítások A biztonsági javítások mindig egy távoli gépen tárolódnak, a következõ parancsok használatával tölthetõek le és telepíthetõek: &prompt.root; freebsd-update fetch &prompt.root; freebsd-update install Amennyiben a rendszermagot is érintik javítások, úgy a rendszert a mûvelet befejezõdésével újra kell indítanunk. Ha minden a megfelelõ módon történt, akkor a rendszerünk már tartalmazni fogja a korábban letöltött és telepített javításokat, és a freebsd-update akár beállítható egy naponta végrehajtandó &man.cron.8; feladatnak. Ehhez mindössze a következõ bejegyzést kell elhelyeznünk az /etc/crontab állományban: @daily root freebsd-update cron A bejegyzés szerint naponta egyszer le fog futni a freebsd-update. Ilyenkor, vagyis a paraméter megadásakor a freebsd-update csak ellenõrzi, hogy vannak-e telepítendõ frissítések. Ha talál, akkor automatikusan letölti ezeket a lemezre, de nem telepíti. Helyette levélben értesíti a root felhasználót, aki ezután bármikor manuálisan kérheti a telepítést. Probléma esetén az alábbi paranccsal megkérhetjük a freebsd-update programot a legutóbb telepített módosítások visszavonására: &prompt.root; freebsd-update rollback Ha ez a visszavonás a rendszermagra vagy annak moduljaira is vonatkozott, akkor a rendszert újra kell indítanunk a parancs futásának befejezõdésével. A &os; csak ilyenkor képes betölteni az új binárisokat betölteni a memóriába. A freebsd-update önmagától csak a GENERIC típusú rendszermagokat képes frissíteni. Ha saját rendszermagot használunk, akkor azt a rendszer többi komponensének frissítését követõen újra kell fordítanunk és telepítenünk. A freebsd-update azonban még akkor is érzekelni és frissíteni fogja a GENERIC rendszermagot (amennyiben az létezik), ha az éppen nem az aktuális(an futó) rendszermag. Mindig érdemes tartani egy másolatot a GENERIC rendszermagról a /boot/GENERIC könyvtárban. Rengeteg különbözõ probléma felderítésében tud segíteni, illetve ez a szakaszban leírt freebsd-update programmal végzett frissítéseknél is hasznos lehet. Hacsak nem változtatjuk meg az /etc/freebsd-update.conf állományt, a freebsd-update a rendszermag forrásait is frissíti a többivel együtt. A saját rendszermag újrafordítása és telepítése ezután a már a megszokott módon elvégezhetõ. A freebsd-update által terjesztett frissítések nem mindig érintik a rendszermagot. Ha a rendszermag forrásai nem változnak egy freebsd-update install parancs kiadása során, akkor nem kötelezõ újrafordítani a saját rendszermagot. A freebsd-update viszont mindig módosítani fogja a /usr/src/sys/conf/newvers.sh állományt. Itt az aktuális hibajavítás sorszáma szerepel (amelyet a -p (mint patch level elõtaggal kapcsolnak a rendszer verziójához, és a uname -r paranccsal lehet lekérdezni). Ennek megfelelõen tehát a saját rendszermag újrafordítása után, még ha semmi más nem is változott, a &man.uname.1; képes pontosan jelezni a rendszerhez készült hibajavítás sorszámát. Ez különösen fontos több rendszer karbantartása során, mivel így könnyen és gyorsan tájékozódhatunk azok naprakészségérõl. Váltás kisebb és nagyobb verziók között Verziók közti váltás során a külsõ alkalmazások mûkõdését akadályozó régi tárgykódok és függvénykönyvtárak törlõdni fognak. Ezért javasoljuk, hogy vagy töröljük le az összes portot és telepítsük újra, vagy az alaprendszer frissítése után hozzuk ezeket is naprakész állapotba a ports-mgmt/portupgrade segédprogram segítségével. Elõször minden bizonnyal szeretnék kipróbálni a frissítést, ezt a következõ paranccsal tehetjük meg: &prompt.root; portupgrade -af Ezzel gondoskodunk róla, hogy a minden a megfelelõen telepítõdjön újra. Ha a BATCH környezeti változót a yes értékre állítjuk, akkor a folyamat során megjelenõ összes kérdésre automatikusan a yes választ adjuk, ezáltal önállósítani tudjuk. Ha saját rendszermagot használunk, akkor ennél valamivel azért több feladatunk van. Szükségünk lesz a GENERIC rendszermagot egy példányára, amelyet másoljunk a /boot/GENERIC könyvtárba. Amennyiben nincs GENERIC típusú rendszermag a rendszerünkön, a következõ módok valamelyikén keresztül tudunk szerezni: Ha a saját rendszermagot még csak egyszer fordítottuk, akkor a /boot/kernel.old könyvtárban még megtalálható a GENERIC. Ezt nevezzük át egyszerûen /boot/GENERIC könyvtárra. Ha fizikailag hozzá tudunk férni az érintett géphez, akkor a GENERIC egy példányát akár CD-rõl is átmásolhatjuk. Helyezzük be a telepítõlemezt és adjuk ki a következõ parancsokat: &prompt.root; mount /cdrom &prompt.root; cd /cdrom/X.Y-RELEASE/kernels &prompt.root; ./install.sh GENERIC Itt a X.Y-RELEASE könyvtár nevében értelemszerûen helyettesítsük be az általunk használt változatot. A GENERIC rendszermag ekkor alapértelmezés szerint a /boot/GENERIC könyvtárba kerül. Ha az elõbbiek közül egyik sem lehetséges, akkor a GENERIC rendszermagot közvetlenül akár forrásból is lefordíthatjuk és telepíthetjük: &prompt.root; cd /usr/src &prompt.root; env DESTDIR=/boot/GENERIC make kernel &prompt.root; mv /boot/GENERIC/boot/kernel/* /boot/GENERIC &prompt.root; rm -rf /boot/GENERIC/boot A freebsd-update akkor fogja ezt GENERIC rendszermagként felismerni, ha a hozzá tartozó konfigurációs állományt nem módosítjuk. Továbbá javasoljuk, hogy semmilyen speciális beállítást ne alkalmazzunk a fordítás során (érdemes üresen hagyni ehhez az /etc/make.conf állományt). Nem kötelezõ újraindítani a rendszert a GENERIC rendszermaggal. A freebsd-update képes frissíteni rendszerünket egy adott kiadásra. Például a következõ paraméterek megadásával válthatunk a &os; 6.4 használatára: &prompt.root; freebsd-update -r 6.4-RELEASE upgrade A parancs elindulása után nem sokkal, a váltáshoz szükséges információk összegyûjtéséhez a freebsd-update elemzi a konfigurációs állományában megadott beállításokat és a rendszer jelenleg használt verzióját. A képernyõn ekkor sorban megjelennek a program részérõl érzékelt és nem érzékelt komponensek. Mint például ahogy itt látható: Looking up update.FreeBSD.org mirrors... 1 mirrors found. Fetching metadata signature for 6.3-RELEASE from update1.FreeBSD.org... done. Fetching metadata index... done. Inspecting system... done. The following components of FreeBSD seem to be installed: kernel/smp src/base src/bin src/contrib src/crypto src/etc src/games src/gnu src/include src/krb5 src/lib src/libexec src/release src/rescue src/sbin src/secure src/share src/sys src/tools src/ubin src/usbin world/base world/info world/lib32 world/manpages The following components of FreeBSD do not seem to be installed: kernel/generic world/catpages world/dict world/doc world/games world/proflibs Does this look reasonable (y/n)? y Ekkor a freebsd-update megpróbálja letölteni a verziók közti váltáshoz szükséges összes állományt. Bizonyos esetekben kérdésekkel fordul a felhasználó felé arra vonatkozóan, hogy miket telepítsen fel vagy mit csináljon. A saját rendszermag használatakor az iménti lépés valamilyen ehhez hasonló figyelmeztetést fog adni: WARNING: This system is running a "SAJÁT RENDSZERMAG" kernel, which is not a kernel configuration distributed as part of FreeBSD 6.3-RELEASE. This kernel will not be updated: you MUST update the kernel manually before running "/usr/sbin/freebsd-update install" Ez a figyelmeztetés most nyugodtan figyelmen kívül hagyható. A folyamat során a frissített GENERIC rendszermagot fogjuk használni. A javítások letöltését követõen megkezdõdik a telepítésük. A váltás ezen lépése az adott gép aktuális terhelésétõl és sebességétõl függõen változó hosszúságú lehet. Ezután a konfigurációs állományok összefésülése zajlik le — itt általában a emberi felügyeletre is szükség van az állományok összefésülésének irányításához, amelynek folyamatosan láthatóak az eredményei. A meghiúsult vagy kihagyott összefésülések a teljes frissítési folyamat leállását vonják maguk után. Az /etc könyvtárban tárolt fontosabb állományokról, mint például a master.passwd vagy group javasolt elõzetesen biztonsági mentést készíteni és késõbb kézzel hozzájuk adni a változtatásaikat. A rendszerben ekkor még nem lesz jelen semmilyen konkrét változás, az összes említett javítás és összefésülés egy külön könyvtárban történik. A telepített javításokat és az összefésült konfigurációs állományokat a folyamat végén magának a felhasználónak kell véglegesíteni. A frissítési eljárás végén a következõ parancs kiadásával tudjuk ténylegesen érvényesíteni az eddig elvégzett módosításokat: &prompt.root; freebsd-update install Elõször mindig a rendszermag és a hozzá tartozó modulok cserélõdnek le. Ahogy ez végrehajtódott, újra kell indítanunk a rendszert. Ha saját rendszermagot használunk, akkor a &man.nextboot.8; parancs segítségével állítsuk be a következõ rendszerindítás során betöltendõ rendszermagot a /boot/GENERIC könyvtárban levõre (ezt frissítettük): &prompt.root; nextboot -k GENERIC Mielõtt újraindítanánk a gépünket a GENERIC rendszermaggal, gyõzõdjünk meg róla, hogy szerepel benne minden olyan meghajtó, amely elengedhetetlen a rendszer hiánytalan indításához (és képes lesz újra csatlakozni a hálózathoz, ha éppen távolról adminisztráljuk). Ez különösen olyan esetben fontos, amikor a saját rendszermagunkban beépítetten szerepeltek bizonyos modulok. Ilyenkor a GENERIC rendszermag használatakor ezeket a /boot/loader.conf állományon keresztül töltethetjük be ideiglenesen. A frissítés befejezéséig érdemes viszont minden nem létfontosságú szolgáltatást leállítani, leválasztani lemezeket és hálózati megosztásokat stb. A rendszerünk most már újraindítható a frissített rendszermaggal: &prompt.root; shutdown -r now A rendszer sikeres újraindulása után ismét el kell indítanunk a freebsd-update programot, amely korábban már elmentette a frissítés állapotát, emiatt a legutóbbi pontról fog folytatódni, illetve törli az osztott könyvtárak és tárgykódok régebbi változatait. Innen az alábbi paranccsal léphetünk tovább: &prompt.root; freebsd-update install A függvénykönyvtárak verziói közti eltérések mértékétõl függõen elképzelhetõ, hogy a telepítés az említett három fázis helyett kettõben történik. Most pedig újra kell fordítanunk vagy telepítenünk az összes általunk korábban használt külsõ alkalmazást. Erre azért van szükségünk, mert bizonyos alkalmazások a verziók közti váltás során törölt programkönyvtáraktól függtek. Ennek automatizálásában a ports-mgmt/portupgrade lesz segítségünkre. Az alkalmazások frissítésének elindításához a következõ parancsokat használjuk: &prompt.root; portupgrade -f ruby &prompt.root; rm /var/db/pkg/pkgdb.db &prompt.root; portupgrade -f ruby18-bdb &prompt.root; rm /var/db/pkg/pkgdb.db /usr/ports/INDEX-*.db &prompt.root; portupgrade -af A parancsok lefutását követõen a freebsd-update utolsó hívásával zárjuk le a frissítést. Ezzel a paranccsal tudunk tehát pontot tenni a frissítési procedúra végére: &prompt.root; freebsd-update install Ha a GENERIC rendszermagot csak átmenetileg használtuk, akkor most már a megszokott módon fordíthatunk és telepíthetünk magunk egy saját rendszermagot. Indítsuk újra a rendszert a &os; frissített változatával. A folyamat ezzel véget ért. Rendszerek állapotainak összehasonlítása A freebsd-update ragyogóan felhasználható a &os; egy telepített változatának és egy általunk garantáltan megbízható példányának összevetésére. Ilyenkor a rendszerhez tartozó segédprogramokat, programkönyvtárakat és konfigurációs állományokat ellenõriztethetjük le. Az összehasonlítást ezzel a paranccsal kezdhetjük meg: &prompt.root; freebsd-update IDS >> eredmeny.idk Habár a parancs neve IDS (intrusion detection system), nem helyettesít semmilyen olyan behatolásjelzõ megoldást, mint amilyen például a security/snort. Mivel a freebsd-update adatokat tárol a lemezen, teljesen kézenfekvõ a hamisítás lehetõsége. Míg ennek eshetõsége adott mértékben visszaszorítható a kern.securelevel csökkentésével és a freebsd-update által használt adatok írásvédett állományrendszerre helyezésével, erre a problémára az ideális megoldást mégis egy teljes biztonságban tudható referencia rendszer jelentheti. Ennek tárolására alkalmas lehet például egy DVD vagy egy külsõ USB-egység. A parancs kiadása után megkezdõdik a rendszer vizsgálata, és az ellenõrzés során folyamatosan jelennek meg az átvizsgált állományok a hozzájuk tartozó ismert és kiszámított &man.sha256.1;-kódjukkal együtt. Mivel a képernyõn túlságosan gyorsan elúsznának az eredmények, ezért ezeket egy eredmeny.idk nevû állományba mentjük a késõbbi elemzésekhez. Az így keletkezõ állomány sorai ugyan meglehetõsen hosszúak, de szerencsére viszonylag könnyen értelmezhetõek. Például az adott kiadásban szereplõ állományoktól eltérõeket ezzel a paranccsal kérdezhetjük le: &prompt.root; cat eredmeny.idk | awk '{ print $1 }' | more /etc/master.passwd /etc/motd /etc/passwd /etc/pf.conf A példában most csak az elsõ néhány állományt hagytuk meg, gyakran tapasztalhatunk viszont ennél többet. Ezek közül bizonyos állományok értelemszerûen eltérnek, mint itt például az /etc/passwd, mert idõközben új felhasználókat adtunk a rendszerhez. Máskor egyéb állományok, például modulok nevei is felbukkanhatnak, mert tegyük fel, hogy a freebsd-update már frissítette ezeket. Ha ki szeretnénk zárni valamilyen állományokat vagy könyvtárakat az ellenõrzésbõl, egyszerûen csak soroljuk fel ezeket az /etc/freebsd-update.conf állományban megjelenõ IDSIgnorePaths beállításnál. A korábban tárgyaltaktól függetlenül ez a rendszer alkalmas bonyolultabb frissítési folyamatok kisegítésére is. Tom Rhodes Írta: Colin Percival A megíráshoz felhasznált jegyzeteket készítette: A Portgyûjtemény frissítése a Portsnap használatával frissítés és frissen tartás Portsnap frissítés és frissen tartás A &os; alaprendszer a Portgyûjtemény frissítéséhez is tartalmaz egy &man.portsnap.8; elnevezésû segédprogramot. Ez a program elindítása után csatlakozik egy távoli géphez, ellenõrzi a biztonsági kulcsát és letölti a portok legfrissebb változatait. A biztonsági kulcs feladata a frissítés közben letöltött állományok sértetlenségének szavatolása, ezzel gondoskodik róla, hogy az adatok átvitelük közben nem változtak meg. A Portgyûjtemény legújabb változatát így érhetjük el: &prompt.root; portsnap fetch Looking up portsnap.FreeBSD.org mirrors... 3 mirrors found. Fetching snapshot tag from portsnap1.FreeBSD.org... done. Fetching snapshot metadata... done. Updating from Wed Aug 6 18:00:22 EDT 2008 to Sat Aug 30 20:24:11 EDT 2008. Fetching 3 metadata patches.. done. Applying metadata patches... done. Fetching 3 metadata files... done. Fetching 90 patches.....10....20....30....40....50....60....70....80....90. done. Applying patches... done. Fetching 133 new ports or files... done. A példában látható, hogy a &man.portsnap.8; eltéréseket talált a helyi és a távoli rendszerekben fellelhetõ portok között, majd azokat ellenõrizte. Emellett az is megfigyelhetõ, hogy korábban már futtatuk a programot, mivel ha most indítottuk volna az elsõ alkalommal, akkor egyszerûen letöltötte volna a teljes Portgyûjteményt. Ahogy a &man.portsnap.8; sikeresen befejezi az imént kiadott fetch mûvelet végrehajtását, a helyi rendszeren már telepítésre készen fognak várakozni a Portgyûjtemény és az hozzá tartozó ellenõrzött módosítások. A portsnap elsõ használatakor az extract parancs segítségével telepíthetjük a frissített állományokat: &prompt.root; portsnap extract /usr/ports/.cvsignore /usr/ports/CHANGES /usr/ports/COPYRIGHT /usr/ports/GIDs /usr/ports/KNOBS /usr/ports/LEGAL /usr/ports/MOVED /usr/ports/Makefile /usr/ports/Mk/bsd.apache.mk /usr/ports/Mk/bsd.autotools.mk /usr/ports/Mk/bsd.cmake.mk ... - A portsnap fetch késõbbi - futtatásakor viszont már az update - parancsot kell használnunk: + Egy korábban már telepített + Portgyûjteményt a portsnap update + paranccsal tudunk frissíteni: &prompt.root; portsnap update Ezzel lezárult a portok frissítése, innentõl már az aktualizált Portgyûjtemény felhasználásával tetszõlegesen telepíthetõek vagy frissíthetõek az alkalmazások. A fetch, extract vagy update mûveletek egyetlen parancsba is összefûzhetõek, ahogy ezt az alábbi példában is láthatjuk: &prompt.root; portsnap fetch update + + Ez a parancs letölti a Portgy&251;jtemény + legfrissebb változatát, majd + kitömöríti azt a helyi /usr/ports + könyvtárba. A dokumentáció frissítése frissítés és frissen tartás dokumentáció frissítés és frissen tartás Az alaprendszer és a Portgyûjtemény mellett a dokumentáció is a &os; operációs rendszer szerves részét képezi. Noha a &os; dokumentációjának legfrissebb változata folyamatosan elérhetõ a &os; honlapjáról, egyes felhasználók ezt csak lassan vagy nem képesek folyamatosan elérni. Szerencsére egy helyi másolat megfelelõ karbantartásával az egyes kiadásokhoz tartozó dokumentáció is frissíthetõ. A dokumentáció frissítése CVSup használatával A &os; telepített dokumentációjának forrásai az alaprendszeréhez hasonlóan (lásd ) a CVSup segítségével frissíthetõek. Ebben a szakaszban megismerhetjük: hogyan telepítsük a dokumentáció elõállításához szükséges eszközöket, amelyekkel a forrásokból újra tudjuk generálni a &os; dokumentációját; hogyan töltsük le a dokumentáció forrását CVSup segítségével a /usr/doc könyvtárba; a dokumentáció elõállításához alkalmazott rendszer milyen beállításokkal rendelkezik, vagyis hogyan korlátozzuk a generálást bizonyos nyelvekre vagy formátumokra. A CVSup és a dokumentációs eszközök telepítése Viszonylag sokféle eszközre lesz szükségünk, ha a &os; dokumentációját a forrásokból akarjuk elõállítani. Ezek az segédprogramok nem részei a &os; alaprendszerének, mivel alapvetõen nagyon sok helyet foglalnak el, és leginkább olyan &os; felhasználók számára fontosak, akik folyamatosan a dokumentációval dolgoznak vagy gyakran frissítik azt forrásból. A feladathoz szükséges összes eszköz elérhetõ a Portgyûjteménybõl. Ebben a &os; Dokumentációs Projekt összeállított egy textproc/docproj nevû portot, amellyel az említett programok telepítését és frissítését igyekezték megkönnyíteni. Ha nem tartunk igényt a dokumentáció &postscript; vagy PDF változatára, akkor ehelyett inkább érdemes megfontolnunk a textproc/docproj-nojadetex port telepítését. Ebben a változatban a teTeX betûszedõ rendszer kivételével az összes segédprogram megtalálható. Mivel a teTeX önmagában nagyon sok segédeszköz telepítését jelenti, ezért amennyiben a PDF változat ténylegesen nem szükséges, érdemes eltekinteni a telepítésétõl. A CVSup telepítésével kapcsolatban pedig részletesebb információkat a CVSup használatával foglalkozó szakaszban olvashatunk. A dokumentáció forrásának frissítése A /usr/share/examples/cvsup/doc-supfile konfigurációs állomány segítségével a CVSup képes letölteni a dokumentáció forrásállományainak legfrissebb példányait. Itt a frissítést alapértelmezés szerint egy nem létezõ géptõl fogjuk kérni (mivel ezt kötelezõ kitölteni), azonban a &man.cvsup.1; programnak egy parancssori paraméter segítségével megadhatjuk melyik CVSup szerverrõl töltse le a forrásokat: &prompt.root; cvsup -h cvsup.FreeBSD.org -g -L 2 /usr/share/examples/cvsup/doc-supfile Ne felejtsük el a cvsup.FreeBSD.org helyére beírni a hozzánk földrajzilag legközelebb elhelyezkedõ CVSup szervert. Ezek teljes listáját a tartalmazza. Egy ideig eltarthat, amíg elõször letöltjük a forrásokat. Várjuk meg türelmesen, amíg befejezõdik a mûvelet. Késõbb a forrásokat ugyanezzel a paranccsal tudjuk frissíteni. A CVSup ugyanis mindig csak a legutóbbi futtatása óta történt változásokat tölti le, ezért késõbb már ez a lépés jelentõsen felgyorsulhat. A források letöltése után a dokumentációt például az ekkor keletkezett /usr/doc könyvtárban található Makefile használatával állíthatjuk elõ. Tehát miután az /etc/make.conf állományban beállítottuk a SUP_UPDATE, SUPHOST és DOCSUPFILE változókat, le tudjuk futtatni a következõ parancsot: &prompt.root; cd /usr/doc &prompt.root; make update Az elõbb említett &man.make.1; változók jellemzõ értékei: SUP_UPDATE= yes SUPHOST?= cvsup.freebsd.org DOCSUPFILE?= /usr/share/examples/cvsup/doc-supfile Mivel a SUPHOST és a DOCSUPFILE változók értékét a ?= szimbólummal állítottuk be, lehetõségünk van a parancssorból ezeknek más értékeket adni. Az /etc/make.conf állományba általában így érdemes felvenni a változókat, így nem kell minden alkalommal módosítani, amikor valamilyen új beállítást akarunk kipróbálni. A dokumentáció különbözõ beállításai A &os; dokumentációjához tartozó, frissítést és elõállítást végzõ rendszernek van néhány olyan beállítása, amelyekkel kérhetjük kizárólag csak a dokumentáció egyes részeinek frissítését vagy bizonyos kimeneti formátumok használatát. Ezek vagy globálisan az /etc/make.conf állományban, vagy pedig a parancssorból, a &man.make.1; program paramétereként adhatóak meg. Ízelítõül néhány közülük: DOC_LANG Az elõállítandó és telepítendõ nyelvû dokumentáció felsorolása, tehát például csak az angol dokumentáció esetén ez en_US.ISO8859-1. FORMATS Az elõállítandó dokumentáció kimeneti formátumainak felsorolása. Itt pillanatnyilag értékként a html, html-split, txt, ps, pdf és rtf jelenhet meg. SUPHOST A frissítéshez használt CVSup szerver hálózati neve. DOCDIR Az elkészült dokumentáció telepítésének helye. Ez alapértelmezés szerint a /usr/share/doc. A folyamathoz kapcsolódóan további rendszerszintû &man.make.1; változókról a &man.make.conf.5; man oldalon olvashatunk. A &os; dokumentációjának elõállításáért felelõs rendszerben használható &man.make.1; további változók bemutatásával kapcsolatban pedig olvassuk el az A &os; Dokumentációs Projekt irányelvei kezdõknek címû könyvet. A &os; dokumentációjának telepítése forrásból Miután sikerült letöltenünk a /usr/doc könyvtárba a dokumentáció legfrissebb forrásait, készen állunk a rendszerünkön telepített példány frissítésére. A DOCLANG értékeként megadott nyelven készült dokumentációkat a következõ paranccsal tudjuk frissíteni: &prompt.root; cd /usr/doc &prompt.root; make install clean Ha a make.conf állományban korábban már megadtuk a DOCSUPFILE, SUPHOST és SUP_UPDATE változók értékeit, akkor a telepítés fázisa könnyedén össze is vonatható a források frissítésével: &prompt.root; cd /usr/doc &prompt.root; make update install clean Ha pedig csak bizonyos nyelvekhez tartozó dokumentációt szeretnénk frissíteni, akkor a &man.make.1; akár a /usr/doc könyvtáron belül az egyes nyelvekhez tartozó alkönyvtárakon belül is meghívható, például: &prompt.root; cd /usr/doc/en_US.ISO8859-1 &prompt.root; make update install clean A dokumentáció formátumát a FORMATS változó felhasználásával tudjuk meghatározni: &prompt.root; cd /usr/doc &prompt.root; make FORMATS='html html-split' install clean Marc Fonvieille A szóbanforgó megoldást fejlesztette: A dokumentációs portok használata frissítés és frissen tartás dokumentáció frissítés és frissen tartás Ez elõzõ szakaszban megmutattuk hogyan lehet a &os; dokumentációját a források felhasználásával frissíteni. A források használatával végzett frissítés azonban nem minden &os; rendszer esetében lehetséges vagy hatékony. Ha ugyanis a dokumentációs forrásból akarjuk elõállítani, viszonylag sok eszköz és segédprogram, az ún. dokumentációs eszközök használatával kell tisztában lennünk, valamint bizonyos mértékig ismernünk kell a CVS használatát, tudunk kell kikérni a legfrissebb változatot és elõállítatattnunk belõle a végleges változatot. Ezért ebben a szakaszban most szót ejtünk egy olyan módszerrõl, ahol a &os; dokumentációját a Portgyûjteményen keresztül tudjuk frissíteni, ezáltal: anélkül le tudjuk tölteni és telepíteni a dokumentáció adott pillanatban generált változatát, hogy a rendszerünkön bármi további teendõre szükség lenne (ennek köszönhetõen nem kell telepítenünk a dokumentációs eszközöket); letölthetjük a dokumentáció forrását és a Portgyûjtemény eszközeivel elõállíthatjuk belõle a megfelelõ változatot (ez a források beszerzésében és feldolgozásában segít valamelyest). A &os; dokumentáció frissítésének fentebb említett módjait támogatják tehát a dokumentációs portok, amelyeket a &a.doceng; havi rendszerességgel tart karban. Ezek a portok a &os; Portgyûjteményén belül a docs nevû virtuális kategóriában találhatóak meg. A dokumentációs portok fordítása és telepítése A dokumentáció könnyebb elõállításához a dokumentációs portok a Portgyûjtemény lehetõségeit veszik igénybe. Segítségükkel automatikussá teszik a dokumentáció forrásának letöltését, a &man.make.1; parancs meghívását a megfelelõ környezetben, beállításokkal és parancssori paraméterekkel. Rajtuk keresztül a dokumentáció eltávolítása ugyanolyan egyszerûen megtehetõ, mint akármelyik másik &os; port vagy csomag esetében. Továbbá, amikor a dokumentációs portokat a saját rendszerünkön fordítjuk, a dokumentációs eszközök függõségként automatikusan települni fognak. A dokumentációs portok a következõ módon szervezõdnek: Létezik egy ún. fõport, a misc/freebsd-doc-en, ahol az összes fontosabb állomány megtalálható. Ez lényegében a dokumentációs portok közös õse. Alapértelmezés szerint kizárólag csak az angol nyelvû dokumentációt állítja elõ. Létezik egy mindenes port, a misc/freebsd-doc-all, amely az összes elérhetõ nyelven és formátumban elõállítja a dokumentációt. Végezetül minden nyelvhez létezik egy-egy alport, ilyen például a magyar dokumentáció esetén a misc/freebsd-doc-hu port. Mindegyikük a fõporttól függ és az adott nyelvû dokumentációt telepítik. Az eddigi összefoglaltaknak megfelelõen a dokumentációs portokat forrásból a következõ paranccsal lehet telepíteni (root felhasználóként): &prompt.root; cd /usr/ports/misc/freebsd-doc-en &prompt.root; make install clean Ennek hatására elõáll és telepítõdik a /usr/local/share/doc/freebsd könyvtárba az angol nyelvû dokumentáció állományokra bontott HTML formátumban (hasonlóan a tartalmához). Gyakori beállítások A dokumentációs portok alapértelmezett viselkedése több különbözõ opció segítségével is befolyásolható. Ezek közül most összefoglalunk néhányat: WITH_HTML Minden dokumentum egyetlen HTML állományba kerüljön. A végeredmény ekkor az adott dokumentum típusának megfelelõen article.html (cikk) vagy book.html (könyv) néven keletkezik (képekkel együtt). WITH_PDF Minden dokumentum &adobe; Portable Document Format típusú állományban jön létre. Ezek az állományok a Ghostscript vagy más egyéb PDF nézegetõkkel nyithatóak meg. Ekkor a dokumentáció konkrét típusától függõen az állományok article.pdf (cikk) vagy book.pdf (könyv) néven állítódnak elõ. DOCBASE A dokumentáció telepítésének helye. Alapértelmezés szerint ez a /usr/local/share/doc/freebsd könyvtár. Ügyeljünk arra, hogy a telepítés alapértelmezett célkönyvtára eltér a CVSup módszerétõl. Ugyanis mivel ilyenkor egy portot telepítünk, a tartalma alapértelmezés szerint a /usr/local könyvtáron belülre kerül. Ez azonban a PREFIX változó átállításával tetszõleges megváltoztatható. Az elõbbieket most egy rövid példán keresztül összefoglaljuk. A következõ paranccsal tudjuk tehát a magyar nyelvû dokumentáció Portable Document Format változatát telepíteni: &prompt.root; cd /usr/ports/misc/freebsd-doc-hu &prompt.root; make -DWITH_PDF DOCBASE=share/doc/freebsd/hu install clean A dokumentációs csomagok használata A dokumentációs portok elõzõ szakaszban bemutatott forrásból telepítésével kapcsolatban már említettük, hogy szükséges hozzá a dokumentációs eszközök telepítése, valamint némi szabad tárterület. Ha a dokumentációs eszközök telepítéséhez nem elengedõek a rendelkezésre álló erõforrásaink vagy a források feldolgozása túlságosan sokat foglalna a rendszerünkön, akkor lehetõségünk van a dokumentációs portok elõre lefordított, csomagolt változatát használni. A &a.doceng; minden hónapban elõkészíti a &os; dokumentációs csomagok legfrissebb változatát. Az így karbantartott bináris csomagok azután tetszõlegesen használhatóak a szabványos csomagkezelõ eszközökkel, mint amilyen például a &man.pkg.add.1;, &man.pkg.delete.1; és így tovább. A bináris csomagok használata esetén a &os; dokumentációja az adott nyelvhez az összes elérhetõ formátumban telepítésre kerül. Például az alábbi paranccsal a magyar nyelvû dokumentációhoz tartozó legfrissebb bináris csomagot tudjuk telepíteni: &prompt.root; pkg_add -r hu-freebsd-doc A csomagok elnevezése eltér a hozzá tartozó port nevétõl. Alakja a következõ: nyelv-freebsd-doc, ahol a nyelv az adott nyelv rövid kódja, vagyis a magyar esetén a hu, illetve az egyszerûsített kínai esetén a zh_ch. A dokumentációs portok frissítése Az elõzetesen telepített dokumentációs portok bármilyen portok frissítésére alkalmas eszközzel frissíthetõek. Például a telepített magyar nyelvû dokumentáció a ports-mgmt/portupgrade eszközön keresztül így frissíthetõ csomagok használatával: &prompt.root; portupgrade -PP hu-freebsd-doc Pav Lucistnik A szükséges információkat szolgáltatta: A Docsnap használata frissítés és frissen tartás Docsnap frissítés és frissen tartás A Docsnap a &os; dokumentációjának egy viszonylag gyors és könnyû frissítésére alkalmas &man.rsync.1; repository. Az ún. Docsnap szerver folyamatosan követi a dokumentáció forrásainak változásait, majd minden órában elõállítja a HTML változatukat. A Docsnap használatakor nincs szükségünk a textproc/docproj port telepítésére, mivel mindig csak a már elõállított dokumentációt frissítjük. A módszer használatához mindössze a net/rsync port vagy csomag telepítése szükségeltetik. Ezt a következõ paranccsal tudjuk elvégezni: &prompt.root; pkg_add -r rsync A Docsnap módszerét eredetileg a /usr/share/doc könyvtárban tárolt dokumentáció frissítésére fejlesztették ki, de a bemutatott példák tetszõleges könyvtárra alkalmazhatóak. Felhasználói könyvtárak esetén még rendszergazdai jogosultságokra sincs szükségünk a feladat elvégzéséhez. A dokumentáció így az alábbi paranccsal frissíthetõ: &prompt.root; rsync -rltvz docsnap.sk.FreeBSD.org::docsnap /usr/share/doc Jelenleg csak egyetlen Docsnap szerver érhetõ el, ez a fentebb is látható docsnap.sk.FreeBSD.org. Közvetlenül ne használjuk a paramétert, mert a make installworld parancs futása közben olyan elemeket is telepíthetett a /usr/share/doc könyvtárba, amelyek így törlõdnének. Helyette inkább így használjuk a parancsot: &prompt.root; rsync -rltvz --delete docsnap.sk.FreeBSD.org::docsnap/??_??\.\* /usr/share/doc Ha csak a dokumentáció egy részét akarjuk frissíteni, például csak az angol nyelvû változatát, akkor pedig ezt a parancsot használjuk: &prompt.root; rsync -rltvz docsnap.sk.FreeBSD.org::docsnap/en_US.ISO8859-1 /usr/share/doc ]]> A fejlesztõi ág követése -CURRENT -STABLE A &os;-nek két fejlesztési ága van: a &os;.current és a &os.stable;. Ebben a szakaszban mindegyikükrõl monduk pár szót, és megmutatjuk, miként lehet az adott ághoz igazítani a rendszerünk frissítését. Elõször a &os.current;, majd a &os.stable; változata kerül tárgyalásra. A &os; friss változatának használata Ahogy arról már az imént is szó esett, nem szabad elfelejtenünk, hogy a &os.current; a &os; fejlesztésének frontvonala. Emiatt a &os.current; használóinak szakmailag jólképzetteknek kell lenniük, és sosem szabad visszariadniuk a használat közben felmerülõ rendszerszintû problémák önálló megoldásától. Ha korábban még nem foglalkoztunk &os;-vel, kétszer is gondoljuk meg a telepítését! Mi a &os.current;? pillanatkép A &os.current; a &os; mögött álló legfrissebb forráskódot képviseli. Itt találkozhatunk különféle olyan fejlesztés alatt álló részekkel, kísérletezésekkel és átmeneti megoldásokkal, amelyek nem feltétlenül kerülnek bele a szoftver következõ hivatalos kiadásába. Noha a &os; fejlesztõi a &os.current; forráskódját naponta fordítják, adódhatnak olyan idõszakok, amikor a források mégsem használhatóak maradéktalanul. Az ilyen gondokat általában a lehetõ leggyorsabban igyekeznek megoldani, azonban attól függõen, hogy éppen a forráskód melyik verzióját sikerült kifogni, a &os.current; használata kész katasztrófa vagy akár a fejlõdésben igazi továbblépés is lehet. Kinek van szüksége a &os.current;-re? A &os.current; használata elsõsorban az alábbi 3 csoportot érinti: A &os; közösség azon tagjait, akik aktívan dolgoznak a forrásfa valamelyik részén, és mindazokat, akik számára a legfrissebb verzió használata feltétlen elvárás. A &os; közösség azon tagjait, akik aktívan tesztelnek, és a &os.current; kordában tartásához hajlandóak idõt áldozni a menet közben felbukkanó problémák megoldására. Vannak olyanok is, akik a &os; változásaival és fejlesztési irányával kapcsolatban kívánnak javaslatokat tenni, melyeket javítások és módosítások formájában tesznek közzé. Mindazokat, akik pusztán kíváncsiak a fejlesztésben zajló eseményekre, vagy hivatkozási szándékkal töltik le a legfrissebb forrásokat (például csak nézegetik, de nem futtatják). Az ilyen emberek esetenként megjegyzéseket fûznek a fejlesztéshez vagy kódot küldenek be. Mi <emphasis>nem</emphasis> a &os.current;? Az olyan kiadás elõtt álló funkciók kipróbálásának egyszerû módja, amelyekrõl hallottunk, hogy milyen remek újdonságokat hoznak és mi akarunk lenni az elsõk, akik ezt használni is fogják. Ne feledjük azonban, hogy amikor mindenki elõtt kezdünk el használni egy újítást, mi leszünk egyben az elsõk is, akik szembesülnek a benne rejlõ hibákkal. A gyors hibajavítások eszköze. A &os.current; szinte bármelyik változata pontosan ugyanakkora valószínûséggel hoz magával új hibákat, mint ahogy eltünteti a régieket. Akármilyen értelemben is hivatalosan támogatott. Képességeinktõl függõen õszintén igyekszünk a lehetõ legtöbbet megtenni a 3 törvényes &os.current; csoportba tartozó emberekért, azonban egyszerûen nincs idõnk komolyabb segítségnyújtást adni. Ez viszont nem azt jelenti, hogy komisz és fukar emberek vagyunk, akik utálnak segíteni a másiknak (de máskülönben nem tudna fejlõdni a &os;). Csupán a &os; fejlesztése közben fizikailag képtelenek vagyunk a naponta érkezõ ezernyi üzenetet rendre megválaszolni! A &os; elõremozdítása és a kísérleti stádiumban álló kóddal kapcsolatos kérdések megválaszolása közül a fejlesztõk általában az elsõt részesítik elõnyben. A &os.current; használata -CURRENT használata Iratkozzunk fel az &a.current.name; és &a.svn-src-head.name; listákra. Ez nem egyszerûen hasznos, hanem elengedhetetlen. Ha nem vagyunk a &a.current.name; listán, akkor nem fogjuk látni a rendszer aktuális állapotára vonatkozó megjegyzéseket, és így esetleg feleslegesen öljük az idõnket olyan problémák megoldásába, amelyeket mások már korábban megoldottak. Ami viszont ennél is fontosabb, hogy így elszalasztjuk a rendszerünk folyamatos életbentartására vonatkozó létfontosságú bejelentéseket. Az &a.svn-src-head.name; listán láthatjuk az a forráskód egyes változtatásaihoz tartozó naplóbejegyzéseket, a hozzájuk tartozó esetleges mellékhatások ismertetésével együtt. A listákra vagy a &a.mailman.lists.link; oldalon található többi lista valamelyikére úgy tudunk feliratkozni, ha rákattintunk a nevére. A további lépésekrõl ezt követõen itt kapunk értesítést. Amennyiben a teljes forrásfa változásai érdekelnek minket, javasoljuk az &a.svn-src-all.name; lista olvasását. A tükrözések egyikérõl töltsük le a &os; forrását. Erre két mód is kínálkozik: cvsup cron -CURRENT frissítés CVSuppal Használjuk a cvsup programot a /usr/share/examples/cvsup könyvtárban található standard-supfile állománnyal. Ez a leginkább ajánlott módszer, hiszen így csak egyszer kell letölteni az egész gyûjteményt, majd ezután már csak a változásokat. Sokan a cvsup parancsot a cron parancson keresztül adják ki, és ezzel mindig automatikusan frissítik a forrásaikat. A cvsup mûködését a fentebb említett minta supfile állomány megfelelõ módosításával tudjuk a saját környezetünkhöz igazítani. Az említett standard-supfile állomány eredetileg nem a &os.current;, hanem inkább a &os; biztonsági problémáit érintõ javítások követésére használatos. A &os.current; forrásainak eléréséhez a következõ sort kell kicserélnünk ebben az állományban: *default release=cvs tag=RELENG_X_Y Erre: *default release=cvs tag=. A tag paramétereként megadható egyéb címkékrõl a kézikönyv CVS címkék szakaszában olvashatunk. -CURRENT frissítés CTM-mel Használjuk a CTM alkalmazás nyújtotta lehetõségeket. Amennyiben nagyon rossz netkapcsolattal rendelkezünk (drága vagy csak levelezésre használható) a CTM megoldást jelenthet számunkra. Legyünk azonban tekintettel arra, hogy helyenként zûrös lehet a használata és néha hibás állományokat gyárt. Emiatt viszont csak ritkán használják, így elõfordulhat, hogy hosszabb ideig nem is mûködik. A 9600 bps vagy annál nagyobb sebességû kapcsolatok esetén ezért inkább a CVSup használatát javasoljuk. Ha nem csak böngészésre, hanem fordításra is szedjük a forrásokat, mindig töltsük le a &os.current; egészét, ne csak egyes részeit. Ez azzal magyarázandó, hogy a forráskód bizonyos részei más helyeken található részektõl is függenek, és ezért az önálló fordításuk szinte garantáltan gondot fog okozni. -CURRENT fordítása A &os.current; lefordítása elõtt figyelmesen olvassuk át a /usr/src könyvtárban található Makefile állományt. A frissítési folyamat részeként elõször mindenképpen érdemes telepíteni egy új rendszermagot és újrafordítani az alaprendszert. Olvassuk el a &a.current; üzeneteit és a /usr/src/UPDATING állományt, ahol megtalálhatjuk az ezzel kapcsolatos legújabb információkat, melyek egy-egy újabb kiadás közeledtével egyre fontosabbá válnak. Foglalkozzunk vele! Ha már a &os.current; változatát használjuk, ne legyünk restek véleményt formálni róla, különösen abban az esetben, ha továbbfejlesztésekrõl vagy hibákra van szó. Leginkább a forráskóddal együtt érkezõ javaslatoknak szoktak örülni a fejlesztõk! A &os; stabil változatának használata Mi a &os.stable;? -STABLE A &os.stable; az a fejlesztési ág, ahonnan az egyes kiadások származnak. Ebbe az ágba már más ütemben kerülnek a változások, mivel általánosan elfogadott, hogy ide a korábban már kipróbált módosítások vándorolnak át a &os.current; ágból. Ez azonban még mindig csak egy fejlesztési ág, ami arra utal, hogy a &os.stable; által adott pillanatban képviselt források nem feltétlenül felelnek meg bizonyos célokra. Ez csupán egy újabb fejlesztési nyomvonal, nem pedig a végfelhasználók kenyere. Kinek van szüksége a &os.stable;-re? Ha szeretnénk figyelemmel kísérni vagy valamilyen módon kiegészíteni a &os; fejlesztési folyamatát, különösen a &os; következõ nagyobb kiadását illetõen, akkor érdemes követnünk a &os.stable; forrásait. Habár a &os.stable; ágba is bekerülnek a biztonsági jellegû javítások, ettõl még nem kell feltétlenül ezt követnünk. A &os;-hez kiadott biztonsági figyelmeztetések mindig leírják, hogyan kell javítani a hibát az érintett kiadásokban Ez azért nem teljesen igaz. A régebbi &os; kiadásokat ugyan nem támogathatjuk a végtelenségig, de általában így is több évig foglalkozunk velük. A &os; régebbi kiadásaival kapcsolatos jelenleg érvényes biztonsági házirend részletes bemutatása a http://www.FreeBSD.org/security/ oldalon olvasható (angolul). , azonban az egész fejlesztési ágat felesleges csak biztonsági okból kifolyólag követni, mivel így olyan változások is kerülhetnek a rendszerbe, amire nincs szükségünk. Habár igyekszünk gondoskodni a &os.stable; ágban található források lefordíthatóságáról és mûködõképességérõl, nem minden esetben szavatolható. Ráadásul mivel a &os.stable; ágba kerülõ kódokat elõször a &os.current; ágban fejlesztik ki, és mivel a &os.stable; felhasználói többen vannak a &os.current; változaténál, ezért szinte elkerülhetetlen, hogy ilyenkor a &os.stable; változatban bizonyos hibák és szélsõséges esetek be ne következzenek, amelyek a &os.current; használata során még nem buktak ki. Ezért a &os.stable; ág vakon követését senkinek sem ajánljuk, és különösen fontos, hogy éles szervereken elõzetes kimerítõ tesztelések nélkül ne futassunk &os.stable; rendszert. Ha ehhez nem rendelkezünk elegendõ erõforrással, akkor egyszerûen használjuk a &os; legfrissebb kiadását, és az egyes kiadások között pedig bináris frissítéssel közlekedjünk. A &os.stable; használata -STABLE használata Iratkozzunk fel a &a.stable.name; listára. Ezen keresztül értesülhetünk a &os.stable; használata során felmerülõ fordítási függõségekrõl vagy más, külön figyelmet igénylõ problémákról. Gyakran ezen a levelezési listán elmélkednek a fejlesztõk a vitatott javításokról vagy frissítésekrõl, amibe a felhasználók is beleszólhatnak, ha a szóbanforgó változtatással kapcsolatban bármilyen problémájuk vagy ötletünk van. Iratkozzunk fel a követni kívánt ághoz tartozó SVN levelezési listára. Például ha a 7-STABLE ág változásait követjük, akkor az &a.svn-src-stable-7.name; listára érdemes feliratkoznunk. Ennek segítségével elolvashatjuk az egyes változtatásokhoz tartozó naplóbejegyzéseket, a rájuk vonatkozó esetleges mellékhatások ismertetésével együtt. Ezekre, valamint a &a.mailman.lists.link; címen elérhetõ listák valamelyikére úgy tudunk feliratkozni, ha a nevükre kattintunk. A további teendõk ezután itt jelennek meg. Amennyiben egy új rendszert akarunk telepíteni és a &os.stable; havonta készült pillanatképeit akarjuk rajta futtatni, akkor errõl bõvebb felvilágosítást a Pillanatképek honlapján találhatunk (angolul). Emellett a legfrissebb &os.stable; kiadást telepíthetjük a tükrözések valamelyikérõl is, majd innen a lentebb található utasítások szerint tudunk hozzáférni a &os.stable; forráskódjának legfrissebb változatához. Ha már fut a gépünkön a &os; egy korábbi kiadása, és ezt akarjuk forráson keresztül frissíteni, akkor ezt a &os; tükrözéseivel könnyedén megtehetjük. Két módon is: cvsup cron -STABLE frissítés CVSuppal Használjuk a cvsup programot a /usr/share/examples/cvsup könyvtárból származó stable-supfile állománnyal. Ez a leginkább ajánlott módszer, mivel így csak egyszer kell letölteni a teljes gyûjteményt, utána már csak a hozzá tartozó változtatásokra van szükségünk. A cvsup parancsot sokan a cron segítségével futtatják, és ezzel automatikusan frissülnek a forrásainak. A cvsup mûködését környezetünkhöz az elõbb említett minta supfile megfelelõ módosításával tudjuk behangolni. -STABLE frissítés CTM-mel Használjuk a CTM programot. Ha nincs olcsó vagy gyors internetkapcsolatunk, akkor érdemes ezt a módszert választani. Alapvetõen azonban ha gyorsan szeretnénk hozzájutni a forrásokhoz és a sávszélesség nem meghatározó tényezõ, akkor helyette válasszuk a cvsup vagy az ftp használatát, és csak minden más esetben CTM-et. -STABLE fordítása Mielõtt lefordítanánk a &os.stable; változatát, figyelmesen olvassuk át a /usr/src könyvtárban levõ Makefile állományt. Az átállási folyamat részeként elõször minden bizonnyal telepítenünk kell egy új rendszermagot és újra kell fordítanunk az alaprendszert. A &a.stable; valamint a /usr/src/UPDATING elolvasásából értesülhetünk azokról az egyéb, gyakran nagyon fontos változásokról, melyek elengedhetetlenek lesznek a következõ kiadás használatához. A forrás szinkronizálása Az internet (vagy elektronikus levelek) használatán keresztül számos mód kínálkozik az &os; Projekthez tartozó források frissen tartásához egy adott, vagy éppen az összes területen attól függõen, hogy mik érdekelnek minket. Ehhez elsõsorban az Anonim CVS, CVSup és CTM szolgáltatásokat ajánljuk fel. Habár lehetséges csupán a forrásfa egyes részeit letölteni, a támogatott frissítési eljárás során azonban szükségünk lesz az egész fa szinkronizálására és a rendszerhez tartozó felhasználói programok (vagyis minden olyan program, amely a felhasználói térben fut, ilyeneket találhatunk többek közt a /bin és /sbin könyvtárakban) valamint rendszermag újrafordítására is. Ha csak a felhasználói programok forrásait, vagy csak a rendszermagot, esetleg csupán a forrásfa egyes részeit frissítjük, akkor az gondokat okozhat. Az itt elõforduló problémák fordítási hibáktól kezdve rendszerösszeomlásokon keresztül akár adatvesztésbe is torkollhatnak. CVS anonim Az Anonim CVS és a CVSup alkalmazások ún. lehúzással frissítik a forrásokat. A CVSup használatakor a felhasználó (vagy a cron szkript) meghívja a cvsup programot, amely az állományok aktualizálásához felveszi a kapcsolatot egy máshol megtalálható cvsupd szerverrel. Az így nyert frissítések az adott pillanatig visszemenõleg érkeznek meg, de csak akkor, ha igényeljük ezeket. A frissítést könnyedén le tudjuk szabályozni a számunkra érdekes egyes állományokra és könyvtárakra. A frissítéseket a szerver hozza létre menet közben annak megfelelõen, hogy milyen verziókkal rendelkezünk, és mihez akarunk szinkronizálni. Az Anonim CVS a CVSupnál valamivel egyszerûbb abban a tekintetben, hogy ez a CVS-nek egy olyan kiterjesztése, amely lehetõvé teszi a változtatások közvetlen lehúzását egy távoli CVS tárházból. Miközben a CVSup mindezt sokkal hatékonnyabb valósítja meg, addig az Anonim CVS jóval könnyebben használható. CTM Velük szemben a CTM nem hasonlítja össze interaktívan a saját és a központi szerveren tárolt forrásokat és nem is húzza át ezeket. Ehelyett egy olyan szkriptõl van szó, amely naponta többször megvizsgálja a központi CTM szerveren tárolt állományok a legutóbbi futtatás óta keletkezett változtatásait, majd az észlelt módosulásokat betömöríti, felcímkézi egy sorozatszámmal és (nyomtatható ASCII formátumban) elõkészíti ezeket az e-mailen keresztüli küldésre. Az így létrehozott CTM delták megérkezésük után a &man.ctm.rmail.1; segédprogrammal kerülnek feldolgozásra, amely magától visszaalakítja, ellenõrzi és alkalmazza a változtatásokat a forrásfa felhasználó birtokában levõ másolatára. Ez a megoldás hatékonyabb a CVSup használatánál, mert kisebb terhelést jelent a szerverek számára, hiszen a frissítéshez nem a lehúzást, hanem a küldést alkalmazzák. Természetesen minden említett eljárásnak megvannak a maga kompromisszumai. Ha véletlenül kitöröljük a forrásfánk egyes részeit, a CVSup képes ezt észrevenni és helyreállítani a sérült részeket. A CTM ezzel szemben ezt nem végzi el, szóval ha (biztonsági mentés nélkül) letöröljük a forrásainkat, akkor az egész szinkronizálást az elejérõl kell kezdenünk (pontosabban a legfrissebb CVS-es alapdeltától) és a CTM-mel újraépíteni az egészet, esetleg a Anonim CVS-sel letörölni a hibás adatokat és újraszinkronizálni. Az alaprendszer újrafordítása az alaprendszer újrafordítása Miután sikerült a helyi forrásfánkat a &os; egy nekünk szimpatikus (&os.stable;, &os.current; és így tovább) változatához igazítanunk, elérkezett az idõ, hogy a segítségével újrafordítsuk az egész rendszert. Készítsünk biztonsági mentést Nem tudjuk eléggé nyomatékosítani, hogy mielõtt nekikezdenénk, készítsünk egy biztonsági mentést a rendszerünkrõl. Míg az alaprendszer újrafordítása nem túlságosan bonyolult feladat (egészen addig, amíg a megadott utasításokat követjük), saját magunk vagy mások hibájából fakadóan kialakulhatnak olyan helyzetek, amikor a rendszer nem lesz képes elindulni. Mindenképpen gyõzödjünk meg róla, hogy tisztességesen elvégeztük a mentést és akad a kezünk ügyében egy javításra felhasználható rendszerindító floppy vagy CD. Valószínûleg soha nem lesz ténylegesen szükségünk rájuk, azonban jobb félni, mint megijedni! Iratkozzunk fel a megfelelõ levelezési listákra levelezési lista A &os.stable; és &os.current; ágak természetüknél fogva fejlesztés alatt állnak. A &os; fejlesztését is emberek végzik, ezért elõfordulhatnak benne tévedések. Ezek a tévedések gyakran csak ártalmatlan apróságok, amelyek hatására kapunk például egy ismeretlen diagnosztikai hibát. De ezzel szemben létrejöhetnek pusztító erejû hibák is, amelyek hatására a rendszerünk nem lesz képes elindulni, károsodnak az állományrendszerek (vagy még rosszabb). Ha ilyen történik, akkor egy felszólítást (egy heads up témájú üzenetet) küldenek az érintett változatokhoz tartozó listákra, amelyben igyekeznek kifejteni a probléma természetét és a rendszerre mért hatását. Miután minden rendbejött, a probléma megoldásáról is küldenek egy értesítést. Ha a &a.stable; vagy a &a.current; olvasása nélkül próbáljuk meg használni a &os.stable; és &os.current; verziókat, akkor csak magunknak keressük a bajt. Ne használjuk a <command>make world</command> parancsot Rengeteg régebben készült dokumentáció erre a feladatra a make world parancs kiadását javasolja. Ennek használatával azonban átlépünk olyan fontos lépéseket, amelyek valójában csak akkor lennének kihagyhatóak, ha pontosan tudjuk mit csinálunk. Ezért az esetek döntõ többségében nem a make world használatára van szükségünk, hanem a most bemutatandó eljárásra. A rendszer frissítése dióhéjban A frissítés megkezdése elõtt érdemes elolvasnunk a /usr/src/UPDATING állományt, ahol a letöltött források használatához elvégzendõ elõzetes intézkedésekrõl kaphatunk hírt. Ezután kövessük az alábbiakban körvonalazott módszer egyes lépéseit. Ezek a lépések feltételezik, hogy egy korábbi &os; verziót használunk, tehát a fordító, a rendszermag, az alaprendszer és a konfigurációs állományok valamelyik régebbi változatát. Alaprendszer alatt, amelyet sokszor csak a world néven hivatkozunk, a rendszer számára alapvetõ fontosságú binárisokat, programkönyvtárakat és programfejlesztéshez szükséges egyéb állományokat értjük. Maga a fordítóprogram is része ennek, azonban tartalmaz néhány speciális megszorítást. Mindezek mellett továbbá feltételezzük, hogy elõzetesen már valamilyen módon letöltöttük a friss forrásokat. Ha rendszerünkön ezt még nem tettük volna meg, akkor a segítségével tájékozódhatunk részletesen arról, hogyan tölthetjük le a legfrissebb verziót. A rendszer forráskódon keresztüli frissítése egy kicsivel körülményesebb, mint amennyire elsõre látszik. A &os; fejlesztõk az évek során fontosnak találták, hogy a folyamatosan felszínre bukkanó, elkerülhetetlen függõségek tükrében meglehetõsen drámai módon megváltoztassák az erre javasolt módszert. Ezért a szakasz további részében a pillanatnyilag javasolt frissítési megoldás nyomán fogunk haladni. A sikeres frissítések során az alábbi akadályokkal kell mindenképpen szembenéznünk: A fordító régebbi változata nem feltétlenül lesz képes lefordítani az új rendszermagot. (Illetve a régebbi fordítóprogramok tartalmazhatnak hibákat.) Ezért az új rendszermagot már a fordító új változatával kell elõállítanunk. Ebbõl következik, hogy az új rendszermag elkészítéséhez elõször a fordítóprogram újabb változatát kell lefordítanunk. Ez viszont nem feltétlenül jelenti azt, hogy az új rendszermag fordítása elõtt az új fordítóprogramot telepítenünk is kellene. Az új alaprendszer esetenként bizonyos új funkciókat igényelhet a rendszermagtól. Ezért a frissebb alaprendszer telepítése elõtt telepítenünk kell a frissebb rendszermagot. Ez az elõbb említett két akadály képzi az okát a következõ bekezdésekben bemutatott buildworld, buildkernel, installkernel, installworld sorozatnak. Természetesen léteznek további egyéb indokok is, amiért még érdemes az itt leírtak szerint frissíteni a rendszerünket. Ezek közül most vegyünk néhány kevésbé nyilvánvalóbbat: A régebbi alaprendszer nem minden esetben fog problémamentesen együttmûködni az új rendszermaggal, ezért az alaprendszer újabb változatát szinte azonnal az új rendszermagot követõen kell telepítenünk. Vannak olyan konfigurációs változtatások, amelyeket még az új alaprendszer telepítése elõtt el kell végeznünk, a többi viszont veszélyes lehet a korábbi alaprendszerre. Ezért a konfigurációs állományokat általában két külön lépésben kell frissíteni. A frissítés során nagyrészt csak állományok cserélõdnek el és újabbak érkeznek, a korábbiak nem törlõdnek. Ez bizonyos esetekben azonban gondokat okozhat. Ennek eredményeképpen a frissítés során idõnként elõfordulhat, hogy magunknak kell manuálisan némely megadott állományokat törölnünk. Elképzelhetõ, hogy ezt a jövõben még majd automatizálni fogják. Ezek a megfontolások vezettek tehát az ismertetendõ eljárás kialakításához. Ettõl függetlenül adódhatnak olyan helyzetek, amikor további lépéseket is be kell iktatnunk, viszont az itt bemutatott folyamat egy ideje már viszonylag elfogadottnak tekinthetõ: make buildworld Elõször lefordítja az új fordítóprogramot és néhány hozzá tartozó eszközt, majd ennek felhasználásával elkészíti az alaprendszer többi részét. Az eredmény a /usr/obj könyvtárban keletkezik. make buildkernel Eltérõen a &man.config.8; és &man.make.1; programok korábban javasolt alkalmazásától, ezzel a paranccsal már a /usr/obj könyvtárban létrehozott új fordítót használjuk. Ez védelmet nyújt a fordító és rendszermag változatai közti eltérésekbõl fakadó problémák ellen. make installkernel Telepíti a lemezre az új rendszermagot és a hozzá tartozó modulokat, ezáltal lehetõvé válik a frissített rendszermag betöltése. Átváltás egyfelhasználós módba. Egyfelhasználós módban a minimálisra csökkenthetjük a futó szoftverek frissítésébõl adódó bonyodalmakat. Ezzel együtt minimálissá válik a régi alaprendszer és az új rendszermag eltéréseibõl eredõ problémák elõfordulása is. mergemaster -p Az új alaprendszer telepítéséhez elvégzi a konfigurációs állományok részérõl szükséges frissítéseket. Például felvesz még nem létezõ csoportokat vagy felhasználókat. Ez gyakran elengedhetetlennek bizonyulhat, mivel ha a rendszer legutóbbi frissítése óta újabb csoportok vagy felhasználók kerültek be az alaprendszerbe, a installworld csak akkor tud hibamentesen lefutni, ha ezek már a futásakor is elérhetõek. make installworld Átmásolja a /usr/obj könyvtárból a korábban elkészített új alaprendszert. Lefutása után már mind az új rendszermag és az új alaprendszer a megfelelõ helyén található. mergemaster Feldolgozzuk a korábbi fázisból fennmaradó konfigurációs állományok frissítését, mivel most már elérhetõ az új alaprendszer. A rendszer újraindítása. Az új rendszermag és az új konfigurációs állományokkal futó alaprendszer használatához teljesen újra kell indítanunk a számítógépünket. Ha a &os; ugyanazon fejlesztési ágán belül frissítjük a rendszerünket, például a 7.0 kiadásról a 7.1 kiadásra, akkor értelemszerûen nem kell az iménti eljárás minden lépését szorosan követni, hiszen nagyon valószínûtlen, hogy komoly eltérések lennének a fordítóprogram, a rendszermag, az alaprendszer és a konfigurációs állományok között. Ilyenkor akár nyugodtan kiadhatjuk a make world parancsot, majd kérhetjük a rendszermag fordítását és telepítését. A fejlesztési ágak közti váltás során azonban könnyen érhetnek minket meglepetések, ha nem a megadottak szerint járunk el. Egyes váltásokhoz (például 4.X és 5.0 között) további lépések megtétele is szükséges lehet (például adott állományok törlése vagy átnevezése még az installworld elõtt). Ilyenkor mindig figyelmesen olvassuk át a /usr/src/UPDATING állományt, különös tekintettel a végére, mivel gyakran ott adják meg a konkrét verzióváltáshoz szükséges teendõket. A szakaszban összefoglalt lépések egyfajta evolúciós folyamat eredményei, melynek során a fejlesztõk felismerték, hogy nem tökéletesen kivédeni az összes frissítéssel járó problémát. A javasolt eljárás remélhetõleg viszont még sokáig érvényes marad. A &os; 3.X vagy annál is korábbi változatok frissítése még ennél is több ügyességet kíván. Ha ilyen verziót akarunk frissíteni, akkor feltétlenül olvassuk el az UPDATING állományt! Röviden tehát a &os; forráskódon keresztüli frissítését így foglalhatjuk össze: &prompt.root; cd /usr/src &prompt.root; make buildworld &prompt.root; make buildkernel &prompt.root; make installkernel &prompt.root; shutdown -r now Néhány ritka esetben a buildworld lépés elõtt szükségünk lehet a mergemaster -p parancs lefuttatására is. Errõl az UPDATING állományból tudakozódhatunk. Általában azonban nyugodt szívvel kihagyhatjuk ezt a lépést, kivéve, ha nem egy vagy több fõbb &os; változatot átívelõ frissítést végzünk. Miután az installkernel sikeresen befejezte a munkáját, indítsuk újra a számítógépet egyfelhasználós módban (a betöltõ parancssorában adjuk ki boot -s parancsot). Itt futtassuk a következõket: &prompt.root; adjkerntz -i &prompt.root; mount -a -t ufs &prompt.root; mergemaster -p &prompt.root; cd /usr/src &prompt.root; make installworld &prompt.root; mergemaster &prompt.root; reboot Olvassuk el a magyarázatokat Az iménti leírt folyamat csupán rövid összefoglalás, amivel némi gyorstalpalást igyekeztünk adni. Az egyes lépések megértéséhez azonban javasolt átolvasni a most következõ szakaszokat is, különösen abban az esetben, ha saját rendszermagot akarunk használni. Nézzük meg a <filename>/usr/src/UPDATING</filename> állományt Mielõtt bármihez is nekifognánk, keressük meg a /usr/src/UPDATING (vagy hasonló, a forráskód másolatunk tényleges helyétõl függõ) állományt. Ebben adják hírül az esetlegesen felmerülõ problémákra vonatkozó fontosabb információkat, vagy határozzák meg az egyes lefuttatandó parancsok pontos sorrendjét. Amennyiben az UPDATING ellentmondana az itt olvasottaknak, az UPDATING tartalma a mérvadó. A korábban tárgyaltak szerint az UPDATING elolvasása nem helyettesíti a megfelelõ levelezési listák figyelemmel kísérését. Ez a két elvárás nem kizárja, hanem kiegészíti egymást. Ellenõrizzük az <filename>/etc/make.conf</filename> állományt make.conf Vizsgáljuk át a /usr/share/examples/etc/make.conf és az /etc/make.conf állományokat. Az elõbbi tartalmaz néhány alapértelmezett beállítást – ezek javarészét megjegyzésbe rakták. Ha használni akarjuk a rendszer lefordítása során, tegyük bele ezeket az /etc/make.conf állományba. Ne felejtsük el azonban, hogy minden, amit megadunk az /etc/make.conf állományba, a make minden egyes elindításakor felhasználásra kerül. Éppen ezért olyanokat érdemes itt beállítani, amik az egész rendszerünket érintik. A legtöbb felhasználó számára az /etc/make.conf állományhoz a /usr/share/examples/etc/make.conf állományban található CFLAGS és NO_PROFILE sorokra lesz szüksége, melyeket kivehetünk a megjegyzésbõl. A többi definíció (COPTFLAGS, NOPORTDOCS és így tovább) használatáról már mindenki maga dönt. Frissítsük az <filename>/etc</filename> tartalmát Az /etc könyvtár tartalmazza a rendszer beállításaival kapcsolatos információk jelentõs részét, valamint a rendszer indítása során lefutó szkripteket. Egyes szkriptek a &os; verzióiról verzióira változnak. Némely konfigurációs állományok a rendszer hétköznapi mûködésében is szerepet játszanak. Ilyen például az /etc/group. Alkalmanként a make installworld parancs futása során igényt tart adott nevû felhasználókra és csoportokra. A frissítéskor azonban ezek a felhasználók vagy csoportok nem feltétlenül állnak rendelkezésre, ami gondokat okozhat. Ezért bizonyos esetekben a make buildworld elõzetesen ellenõrzi az igényelt felhasználók és csoportok meglétét. Erre például szolgálhat a smmsp felhasználó esete. Nélküle a felhasználók nem tudták telepíteni az új rendszert, mert hiányában az &man.mtree.8; nem volt képes létrehozni a /var/spool/clientmqueue könyvtárat. Ezt úgy lehetett megoldani, hogy még az alaprendszer lefordítása (a buildworld) elõtt meg kellett hívni a &man.mergemaster.8; parancsot a paraméterrel. Így csak azokat az állományokat fogja összehasonlítani, amelyek feltétlenül szükségesek a buildworld vagy az installworld sikeres mûködéséhez. Amennyiben a mergemaster egy olyan verziójával rendelkezünk, amely nem ismeri a paramétert, akkor az elsõ indításakor használjuk a forrásfában található újabb verzióját: &prompt.root; cd /usr/src/usr.sbin/mergemaster &prompt.root; ./mergemaster.sh -p Ha különösen paranoiásak vagyunk, akkor a csoport törlése vagy átnevezése elõtt az alábbi paranccsal ellenõrizni tudjuk az általa birtokolt állományokat: &prompt.root; find / -group GID -print Ez megmutatja GID (mely megadható numerikus vagy név formájában is) jelzésû csoporthoz tartozó összes állományt a rendszerünkben. Váltsunk egyfelhasználós módba egyfelhasználós mód A rendszert egyfelhasználós módban érdemes lefordítani. A nyilvánvalóan érezhetõ gyorsaság elõnyei mellett azért is jobban járunk, mert az új rendszer telepítése során számos rendszerszintû állomány is módosításra kerül, beleértve a szabványos rendszerszintû binárisokat, függvénykönyvtárakat, include állományokat és így tovább. Ha üzemelõ rendszeren végezzük el mindezen változtatásokat (különösen amikor rajtunk kívül még további felhasználók is tartózkodnak a rendszerben), az csak a bajt hozza ránk. többfelhasználós mód Másik lehetõség gyanánt a rendszert magát lefordíthatjuk többfelhasználós módban is, majd ezután csak a telepítést hajtjuk végre egyfelhasználós üzemmódban. Ha eszerint cselekszünk, egyszerûen várjunk addig, amíg az összes fordítás be nem fejezõdik, és az egyfelhasználósra váltást halasszuk a installkernel vagy installworld idejére. Egy mûködõ rendszerben rendszeradminisztrátorként az alábbi parancs kiadásával válthatunk át egyfelhasználós módba: &prompt.root; shutdown now Ezt elérhetjük úgy is, ha újraindítjuk a rendszert és a rendszer indításakor a single user pontot választjuk a menübõl. Ekkor a rendszer egyfelhasználós módban indul el. Miután ez megtörtént, adjuk ki a következõ parancsokat: &prompt.root; fsck -p &prompt.root; mount -u / &prompt.root; mount -a -t ufs &prompt.root; swapon -a Ezekkel a parancsokkal elõször ellenõrizzük az állományrendszereket, ezután újracsatlakoztatjuk a / állományrendszert írható módban, csatlakoztatjuk az /etc/fstab állományban megadott összes többi UFS típusú állományrendszert, majd bekapcsoljuk a lapozóállomány használatát. Ha a gépünk óráját nem a greenwich-i, hanem a helyi idõ szerint állítottuk be (ez akkor áll fenn, ha a &man.date.1; parancs nem a helyes idõt és idõzónát jelzi ki), akkor még erre is szükségünk lehet: &prompt.root; adjkerntz -i Ezzel a helyi idõzóna beállításait tudjuk jól beállítani — nélküle késõbb még gondjaink akadhatnak. Töröljük a <filename>/usr/obj</filename> könyvtárat A rendszer egyes részei fordításuk során a /usr/obj könyvtáron belülre kerülnek (alapértelmezés szerint). Az itt található könyvtárak a /usr/src könyvtárszerkezetét követik. Ha mindenestõl töröljük ezt a könyvtárat, akkor növeli tudjuk a make buildworld folyamat sebességét és megmenekülünk néhány függõségekkel kapcsolatos fejfájástól is. Egyes /usr/obj könyvtáron belüli állományoknál szerepelhet a megváltoztathatatlan (immutable) állományjelzõ (lásd &man.chflags.1;), amelyet a mûvelet elvégzéséhez elõször el kell távolítanunk. &prompt.root; cd /usr/obj &prompt.root; chflags -R noschg * &prompt.root; rm -rf * Fordítsuk újra az alaprendszert A kimenet elmentése Jól járunk azzal, ha a &man.make.1; futásának kimenetét elmentjük egy állományba, mivel így a hibák esetén lesz egy másolatunk a hibaüzenetrõl. Ha konkrétan nekünk nem is feltétlenül segít megtalálni a hiba tényleges okát, mások viszont többet tudnak róla mondani, ha beküldjük ezt a &os; egyik levelezési listájára. Ezt egyébként a legegyszerûbben a &man.script.1; parancs segítségével oldhatjuk meg, amelynek paraméteréül azt az állományt kell megadni, ahova menteni akarjuk a kimenetet. Ezt közvetlenül a rendszer újrafordítása elõtt kell kiadnunk, majd miután megállt, a exit paranccsal kiléphetünk belõle. &prompt.root; script /var/tmp/mw.out Script started, output file is /var/tmp/mw.out &prompt.root; make TARGET … fordít, fordít, fordít … &prompt.root; exit Script done, … Ilyenkor soha ne a /tmp könyvtárba mentsük a kimenetet, mert ennek a tartalma a következõ indítás során magától törlõdik. Sokkal jobban tesszük, ha a /var/tmp könyvtárba (ahogy tettük azt az elõbbi példában is) vagy a root felhasználó könyvtárába mentünk. Az alaprendszer fordítása A /usr/src könyvtárban kell állnunk: &prompt.root; cd /usr/src (kivéve természetesen, ha máshol van a forráskód, akkor abba a könyvtárba menjünk). make Az alaprendszert a &man.make.1; paranccsal fordíthatjuk újra. Ez a Makefile nevû állományból olvassa be a &os; programjainak újrafordítását leíró utasításokat, a fordításuk sorrendjét és így tovább. A begépelendõ paranccsor általános alakja tehát a következõképpen néz ki: &prompt.root; make -x -DVÁLTOZÓ target A fenti példában a egy olyan a paraméter, amelyet a &man.make.1; programnak adunk át. A &man.make.1; man oldalán megtalálhatjuk az összes neki átadható ilyen beállítást. A alakú paraméterek közvetlenül a Makefile állománynak adnak át olyan változókat, amelyek segítségével vezérelhetõ a viselkedése. Ezek ugyanazok a változók, mint amelyek az /etc/make.conf állományban is szerepelnek, és itt a beállításuk egy másik módját kapjuk. Így a &prompt.root; make -DNO_PROFILE target paranccsal is megadhatjuk, hogy ne profilozott függkönyvtárak jöjjenek létre, ami pontosan megfelel a NO_PROFILE= true # Avoid compiling profiled libraries sornak az /etc/make.conf állományban. A target árulja el a &man.make.1; programnak, hogy mi a teendõje. Minden egyes Makefile különbözõ targeteket definiál, és a kiválasztott target mondja meg, pontosan mi is fog történni. Egyes targetek ugyan megjelennek a Makefile állományban, azonban nem feltétlenül hivatkozhatunk rájuk közvetlenül. Ehelyett csupán arra valók, hogy a fordítás folyamatának lépéseit felbontsák még kisebb allépésekre. A legtöbb esetben azonban semmilyen paramétert nem kell átadnunk a &man.make.1; parancsnak, ezért a teljes formája így fog kinézni: &prompt.root; make target ahol a target az egyik fordítási lehetõséget képviseli. Az elsõ ilyen targetnek mindig a buildworld-nek kell lennie. Ahogy a neve is mutatja, a buildworld lefordítja az összes forrást a /usr/obj könyvtárba, majd a installworld mint másik target, telepíti az így létrehozott elemeket a számítógépre. A targetek szétválasztása két okból is elõnyös. Elõször is lehetõvé teszi, hogy az új rendszert biztonságban lefordíthassuk, miközben az a jelenleg futó rendszert nem zavarja. A rendszer tehát képes saját magát újrafordítani. Emiatt a buildworld target akár többfelhasználós módban is mindenféle nem kívánatos hatás nélkül használható. Ennek ellenére azonban továbbra is azt javasoljuk, hogy a installworld részt egyfelhasználós módban futtassuk le. Másodrészt ezzel lehetõségünk nyílik NFS állományrendszer alkalmazásával több számítógépre is telepíteni hálózaton keresztül. Ha például három frissítendõ számítógépünk van, az A, B és C, akkor az A gépen elõször adjuk ki a make buildworld, majd a make installworld parancsot. A B és C gépek ezután NFS segítségével csatlakoztatják az A /usr/src és /usr/obj könyvtárait, amelyet követõen a make installworld paranccsal telepíteni tudjuk a fordítás eredményét a B és C gépekre. Noha a world mint target még mindig létezik, használata határozottan ellenjavalt. A &prompt.root; make buildworld parancs kiadásakor a make parancsnak megadható egy paraméter is, amellyel párhuzamosíthatjuk a folyamat egyes részeit. Ez általában többprocesszoros számítógépeken nyer értelmet, azonban mivel a fordítás folyamatának haladását inkább az állománymûveletek mintsem a processzor sebessége korlátozza, ezért alkalmazható akár egyprocesszoros gépeken is. Tehát egy átlagos egyprocesszoros gépen így adható ki a parancs: &prompt.root; make -j4 buildworld Ennek hatására &man.make.1; egyszerre 4 szálon igyekszik mûködni. A levelezési listákra beküldött tapasztalati jellegû bizonyítékok azt igazolják, hogy általában ez a beállítás adja a legjobb teljesítményt. Ha többprocesszoros géppel rendelkezünk és rajta SMP támogatású rendszermagot indítottunk el, akkor érdemes 6 és 10 közötti értékekkel kísérleteznünk. Idõigény az alaprendszer újrafordítása idõigény Számos tényezõ befolyásolja a fordítás tényleges idõbeli hosszát, de a &os.stable; fa lefordítása mindenféle trükkök és rövidítések nélkül a legtöbb számítógépen olyan egy vagy két órára taksálható. A &os.current; fához ennél valamivel több idõre lesz szükségünk. Fordítsunk és telepítsünk egy új rendszermagot rendszermagot fordítása Az újdonsült rendszerünket csak akkor tudjuk igazán kihasználni, ha egy új rendszermagot is készítünk hozzá. Ez gyakorlati szinten tulajdonképpen elvárás, mivel könnyen elõfordulhat, hogy bizonyos memóriabeli adatszerkezetek felépítése megváltozott, ezért némely programok, mint például a &man.ps.1; és &man.top.1;, egészen addig nem lesznek képesek normálisan mûködni, amíg a rendszer és a rendszermag forráskódja nem illeszkedik egymáshoz. Ennek legegyszerûbb és egyben legbiztonságosabb módja, ha a GENERIC beállításai alapján gyártunk és telepítünk egy rendszermagot. Még ha a GENERIC beállításai nem is tartalmazzák a rendszerünkben fellelhetõ összes eszközt, minden megtalálható bennük ahhoz, hogy a rendszert sikeresen elindíthassuk legalább egyfelhasználós módban. Ez mellesleg remek próbája az új rendszer életképességének. Miután elindítottuk a rendszert a GENERIC típusú rendszermaggal és meggyõzõdtünk róla, hogy a rendszer tényleg mûködõképes, a megszokott rendszermagunk konfigurációs állománya alapján nyugodtan elkészíthetjük ezután azt is. &os; alatt egy új rendszermag építése elõtt fontos újrafordítani az alaprendszert. Ha saját beállításaink szerint akarunk rendszermagot létrehozni és már van is ehhez egy konfigurációs állományunk, akkor erre használhatjuk a KERNCONF=SAJÁTMAG paramétert is, valahogy így: &prompt.root; cd /usr/src &prompt.root; make buildkernel KERNCONF=SAJÁTMAG &prompt.root; make installkernel KERNCONF=SAJÁTMAG Hozzátennénk, hogy ha a kern.securelevel rendszerváltozó értékét 1 felé állítottuk és a rendszermag állományának beállítottunk noschg vagy hozzá hasonló állományjelzõt, akkor az installkernel lefuttatásához mindenképpen egyfelhasználós módba kell váltanunk. Minden más esetben további bonyodalmak nélkül ki tudjuk adni az említett parancsokat. A kern.securelevel részleteirõl az &man.init.8; oldalán, a különbözõ állományjelzõkrõl pedig a &man.chflags.1; oldalán olvashatunk. Indítsuk újra a rendszert egyfelhasználós módban egyfelhasználós mód Az új rendszermag mûködésének leteszteléséhez indítsuk újra a rendszert egyfelhasználós módban. Ennek pontos részleteit lásd . Telepítsük az új rendszer binárisait Ha a &os; friss változatát nemrég fordítottuk le a make buildworld paranccsal, akkor utána az installworld segítségével tudjuk telepíteni a keletkezett programokat. Tehát írjuk be ezeket: &prompt.root; cd /usr/src &prompt.root; make installworld Amennyiben a paranccsorban a make buildworld használata során adtunk meg változókat, akkor ne felejtsük el ugyanazokat megadni a make installworld kiadása során sem. Ez viszont a többi paraméterre már nem feltétlenül érvényes. Például a beállítást szigorúan tilos az installworld targettel együtt használni. Ennek megfelelõen tehát ha korábban ezt írtuk be: &prompt.root; make -DNO_PROFILE buildworld akkor így telepítsünk: &prompt.root; make -DNO_PROFILE installworld Máskülönben azokat a profilozott függvénykönyvtárakat próbáljuk meg telepíteni, amelyek a make buildworld futása során nem jöttek létre. Frissítsük a <command>make installworld</command> által kihagyott állományokat Az alaprendszer újrafordítása nem regisztrálja az új vagy megváltozott állományokat bizonyos könyvtárakban (különösen értendõ ez az /etc, /var és /usr esetén). Az ilyen állományokat a legegyszerûbben a &man.mergemaster.8; használatával tarthatjuk karban, de igény szerint akár kézzel is elvégezhetjük a szükséges aktualizálásokat. Függetlenül attól, hogy mit is választunk, mindenképpen készítsünk biztonsági mentést az /etc könyvtárról arra az esetre, ha bármilyen szörnyûség történne. Tom Rhodes Írta: A <command>mergemaster</command> mergemaster A &man.mergemaster.8; segédprogram valójában egy Bourne szkript, amely segít az /etc könyvtárunkban és a forrásfában levõ /usr/src/etc könyvtárban elhelyezkedõ konfigurációs állományok közti eltérések megállapításában. Ezt a módszert ajánljuk arra, hogy összevessük a konfigurációs állományainkat a forrásfában található változataikkal. A használatának megkezdéséhez egyszerûen írjuk be, hogy mergemaster, majd várjunk egy kicsit, amíg a mergemaster létrehoz magának egy átmeneti környezetet a / könyvtárból elindulva és megtölti azt a különbözõ rendszerszintû beállításokat tartalmazó állományokkal. Ezeket az állományokat aztán összehasonlítja a jelenleg érvényben levõ változataikkal. Ilyenkor a köztük talált eltéréseket a &man.diff.1; formátumának megfelelõen módon mutatja meg, ahol a jelöli a hozzáadott vagy módosított sorokat, a pedig a teljesen eltávolítandó vagy cserélendõ sorokat. Errõl a formátumról bõvebben a &man.diff.1; man oldalán találhatunk felvilágosítást. A &man.mergemaster.8; ezt követõen megmutatja az összes olyan állományt, ahol eltérést tapasztalt, és ezen a ponton van lehetõségünk letörölni (delete) az új állományokat (amelyekre itt most ideiglenes állományként hivatkozik), telepíteni (install) a módosítatlan ideiglenes (új) állományt, valamint összefésülni (merge) az ideiglenes (új) és a jelenlegi állományokat, vagy ismét átnézni (view) a &man.diff.1; által jelzett különbségeket. Ha az ideiglenes állomány törlését választjuk, akkor a &man.mergemaster.8; ezt úgy értelmezi, hogy változatlanul meg akarjuk tartani a jelenlegi változatot és törölni az újat. Ezt alapvetõen nem javasoljuk, hacsak tényleg nem látunk valamilyen okot erre. A &man.mergemaster.8; parancssorában a ? begépelésével bármikor kérhetünk segítséget. Ha az állomány kihagyását (skip) választjuk, akkor majd ismét felajánlja, amikor végeztünk az összes többivel. A módosítatlan ideiglenes állomány telepítésének választásával lecseréljük a jelenleg verziót az újra. Ha az aktuális verziót sem változtattuk meg, akkor számunkra ez a legjobb megoldás. Az állományok összefésülésének kiválasztásakor kapunk egy szövegszerkesztõt, benne a két állomány tartalmával. Ilyenkor tudjuk a képernyõn soronként egyeztetni a két állományt, majd a belõlük a megfelelõ részek összeválogatásával kialakítani az eredményt. Ebben a feldolgozási módban az l (mint left, vagyis bal) billentyû lenyomására a bal oldalon látható részt, az r (mint right, vagyis jobb) lenyomására pedig a jobb oldalon látható részt választjuk ki. Az így keletkezõ eredményt ezután egy állományba kerül, amelyet telepíteni tudunk. Ez a megoldás olyan állományok esetében használható, amikor a felhasználó módosított az alapértelmezett beállításokat. Ha a &man.diff.1; szerinti alakban akarjuk átnézni a különbségeket, akkor a &man.mergemaster.8; ugyanúgy megmutatja ezeket, mint a paranccsor megjelenítése elõtt. Miután a &man.mergemaster.8; végigment a rendszerszintû állományokon, további opciókat mutat. Megkérdezheti, hogy újra létre akarjuk-e hozni a jelszavakat tároló állományt (rebuild), illetve a folyamat végén a megmaradt ideiglenes állományok törlésére (remove) vár választ. Az állományok aktualizálása kézzel Ha inkább manuálisan szeretnénk frissíteni, akkor nem másolhatjuk csak egyszerûen át az állományokat a /usr/src/etc könyvtárból a /etc könyvtárba és nem hagyhatjuk ezeket sorsukra. Egyes állományokat elõször telepíteni kell. Ez azért van így, mert a /usr/src/etc könyvtár nem pusztán az /etc könyvtár egyszerû másolata. Ráadásul az /etc könyvtárban vannak olyan állományok, amelyek a /usr/src/etc könyvtárban nem is találhatóak meg. Ha (az ajánlottak szerint) a &man.mergemaster.8; segítségével dolgozunk, nyugodtan átléphetünk a következõ szakaszra. Saját magunk a legegyszerûbben ezt úgy tudjuk megoldani, ha telepítjük az állományokat egy új könyvtárba és ezután nekiállunk változásokat keresni. Az <filename>/etc</filename> meglevõ tartalmának mentése Habár elméletileg magától semmi sem fogja bántani ezt a könyvtárat, azért ettõl függetlenül mindig érdemes biztosra menni. Ezért másoljuk az /etc könyvtár tartalmát egy megbízható helyre. Például: &prompt.root; cp -Rp /etc /etc.old Az itt a rekurzív másolást jelenti, a pedig a dátumok, az állományok és egyebek tulajdoni viszonyainak megõrzését. Az /etc új változatának telepítéséhez szükségünk lesz még további könyvtárakra is. Erre a feladatra a /var/tmp/root tökéletesen megfelel, ahol még létre kell hoznunk néhány alkönyvtárat. &prompt.root; mkdir /var/tmp/root &prompt.root; cd /usr/src/etc &prompt.root; make DESTDIR=/var/tmp/root distrib-dirs distribution Ezzel létrejön a szükséges könyvtárszerkezet és települnek az állományok. Sok üres alkönyvtár is keletkezik a /var/tmp/root könyvtáron belül, ezeket töröljük. Ezt a legkönnyebben így tehetjük meg: &prompt.root; cd /var/tmp/root &prompt.root; find -d . -type d | xargs rmdir 2>/dev/null Ezzel törlõdnek az üres könyvtárak. (A szabvány hibakimenetet átirányítottuk a /dev/null eszközre, és ezzel elnyomtuk a nem üres könyvtárak esetén keletkezõ hibaüzeneteket.) A /var/tmp/root most már tartalmazza az összes olyan állományt, amelyek normális esetben a / könyvtáron belül foglalnak helyet. Ezt követõen nincs más dolgunk, csak végigmenni az itt található állományokon és megállapítani, miben térnek a meglévõektõl. Vegyük észre, hogy a /var/tmp/root könyvtárba telepített állományok némelyikének neve .-tal kezdõdik. Az írás pillanatában ezek csak a /var/tmp/root/ és /var/tmp/root/root/ könyvtárakban található parancsértelmezõhöz tartozó indító állományok lehetnek, habár adódhatnak még ilyenek (attól függõen, mikor olvassuk ezt). Ezért a feldolgozásukhoz ne felejtsük el a ls -a parancsot használni. A &man.diff.1; alkalmazásával legegyszerûbben így tudunk összehasonlítani két állományt: &prompt.root; diff /etc/shells /var/tmp/root/etc/shells Ennek hatására megjelennek az /etc/shells és az új /var/tmp/root/etc/shells állományok közti különbségek. A segítségével gyorsan el tudjuk dönteni, hogy összefésüljük-e a két állományt, vagy csak egyszerûen írjuk felül a régebbi verziót az újjal. Az új könyvtár (<filename>/var/tmp/root</filename>) nevébe írjuk bele a dátumot is, így könnyedén össze tudunk hasonlítani több verziót is A rendszer gyakori újrafordítása az /etc szintén gyakori aktualizálását is maga után vonja, ami viszont fárasztó lehet. Az iménti folyamatot fel tudjuk gyorsítani, hogy ha az /etc legutoljára összefésült változatát megtartjuk. A most következõ eljárás ennek mikéntjét vázolja fel. A megszokottak szerint fordítsuk le a rendszert. Majd amikor az /etc könyvtárat és a többit is frissíteni akarjuk, a célként megadott könyvtár nevében adjuk meg a dátumot. Ha tehát például 1998. február 14. van, akkor írjuk ezt: &prompt.root; mkdir /var/tmp/root-19980214 &prompt.root; cd /usr/src/etc &prompt.root; make DESTDIR=/var/tmp/root-19980214 \ distrib-dirs distribution Fésüljük össze a könyvtárban található az állományokat a fentiekben körvonalazottak szerint. Befejezés után õrizzük meg a /var/tmp/root-19980214 könyvtárat. Mikor újra letöltjük a legfrissebb forrásokat és megismételjük az elõbbi lépéseket, haladjunk megint az elsõ lépés szerint. Ekkor tehát létrejön egy újabb könyvtár, amelynek a neve ezúttal már /var/tmp/root-19980221 lesz (ha például hetente frissítünk). Most már meg tudjuk vizsgálni a közbeesõ héten született eltéréseket, ha a két könyvtárra kiadunk egy rekurzív &man.diff.1; hívást: &prompt.root; cd /var/tmp &prompt.root; diff -r root-19980214 root-19980221 Általában így kevesebb eltérést kapunk, mint amennyi például a /var/tmp/root-19980221/etc/ és az /etc összehasonlítása során elkerült volna. Mivel kisebb a keletkezett különbségek száma, ezért könnyebb lesz átvinnünk az /etc könyvtárunkba is a módosításokat. Ezután törölhetjük a régebbi /var/tmp/root-* könyvtárat: &prompt.root; rm -rf /var/tmp/root-19980214 Az /etc összefésülésekor mindig ismételjük meg ezeket a lépéseket. A &man.date.1; meghívásával akár automatikussá is tehetjük a könyvtárak névadását: &prompt.root; mkdir /var/tmp/root-`date "+%Y%m%d"` Újraindítás Ezzel készen is vagyunk. Miután ellenõriztük, hogy minden a megfelelõ helyére került, indítsuk újra a rendszert. Ehhez egy egyszerû &man.shutdown.8; is elegendõ: &prompt.root; shutdown -r now Befejeztük! Gratulálunk, sikerült frissítenünk a &os; rendszerünket. Ha mégis valami balul ütne ki, könnyen újra tudjuk fordítani a rendszer egyes részeit. Például, ha véletlenül letöröltük az /etc/magic állományt az /etc frissítése vagy összefésülése során, a &man.file.1; parancs nem fog tudni rendesen mûködni. Ilyenkor a következõket kell tennünk a hiba kijavításához: &prompt.root; cd /usr/src/usr.bin/file &prompt.root; make all install Kérdések Minden egyes változtatásnál újra kell fordítani a rendszert? Nem könnyû választ adni erre a kérdésre, mivel ez alapvetõen a változtatás jellegétõl függ. Például, ha elindítjuk a CVSup programot és csak az alábbi állományok frissülnek: src/games/cribbage/instr.c src/games/sail/pl_main.c src/release/sysinstall/config.c src/release/sysinstall/media.c src/share/mk/bsd.port.mk Ekkor valószínûleg nem éri meg újrafordítani a teljes rendszert. Elegendõ csupán belépni az érintett állományokat tartalmazó alkönyvtárakba és ott rendre kiadni a make all install parancsot. Ha viszont már valami komolyabb, például az src/lib/libc/stdlib változott meg, akkor vagy az egész rendszert, vagy legalább azon részeit fordítsuk újra, amely statikusan linkeltek (és minden más idõközben még hozzáadott statikusan linkelt dolgot). Hogy melyik megoldást választjuk, teljesen rajtunk áll. Újrafordíthatjuk az egész rendszert kéthetente, mondván, hadd gyüljenek fel szépen a módosítások, vagy a függõségek pontos kielemzésével csak azokat az elemeket fordítjuk újra, amelyek tényleg meg is változtak. Természetesen az egész attól függ, hogy milyen gyakran és melyik rendszert, a &os.stable;-t vagy a &os.current;-et frissítjük. A fordító rengeteg 11-es jelzést (signal 11) (vagy másfajta jelzéseket) dob hibával. Mi történhetett? signal 11 Ez általában hardveres meghibásodásra utal. A rendszer újrafordítása alapjaiban véve egy remek módszer számítógépünk alkatrészeinek terhelésére, ezért gyakorta elõhozza a memória már meglevõ hibáit. Ezek többnyire abban fogalmazódnak meg, hogy a fordító rejtélyes módon leáll mindenféle furcsa jelzések hatására. Errõl biztosan úgy tudunk meggyõzõdni, ha újraindítjuk a make programot és az a folyamat egy teljesen másik pontján vérzik el. Ilyenkor nem tudunk mást tenni, mint egymás után kicserélgetjük, kivesszük az alkatrészeket és így próbáljuk megállapítani, pontosan melyikük is okozza a gondokat. A fordítása befejezése után törölhetem a /usr/obj könyvtárat? Röviden: Igen. A /usr/obj tartalmazza a fordítás folyamata során keletkezõ összes tárgykódot. Ennek törlése általában a make buildworld elsõ lépései között szerepel. Ezért tulajdonképpen a /usr/obj megtartásának nincs túlságosan sok értelme, viszont elég sok (jelenleg úgy kb. 340 MB) helyet fel tudunk így szabadítani. Ha azonban értjük a dolgunkat, akkor megadhatjuk a make buildworld parancsnak, hogy hagyja ki ezt a lépést. Ennek hatására a fordítás sokkal hamarabb véget ér, mivel a legtöbb forrást így nem kell újrafordítani. Üröm az örömben, hogy ha netalán aprócska függõségi problémák merülnének fel, akkor az egész fordítás megfeneklik mindenfelé különös módokon. Emiatt gyakran írnak feleslegesen leveleket a &os; levelezési listáira, melyek a rendszer sikertelen újrafordításáról panaszkodnak, miközben kiderül, hogy az maguk az érintettek akarták lerövidíteni a folyamatot. Lehetséges a megszakadt fordítás folytatása? Ez attól függ, hogy a probléma bekövetkezése elõtt mennyire sikerült eljutni a fordításban. Általában (tehát nem feltétlenül minden esetben) a make buildworld lefordítja a fordításhoz szükséges eszközök (például a &man.gcc.1; és &man.make.1;) újabb változatait és a rendszer függvénykönyvtárait, majd ezeket telepíti. Ezután ezekkel az új eszközökkel lefordítattja saját magukat és ismét telepíti. Ezt követõen fordítja újra az új rendszerállományokkal az egész rendszert (így ezúttal már az olyan szokásos felhasználói programokat is, mint például az &man.ls.1; és a &man.grep.1;). Ha tudjuk, hogy az utolsó fázisban álltunk le (mivel megnéztük a fordításhoz tartozó kimenetet), akkor (minden további nélkül) elég ennyi: … kijavítjuk a hibát … &prompt.root; cd /usr/src &prompt.root; make -DNO_CLEAN all Ezzel megmarad a korábbi make buildworld munkájának eredménye. Ha ezt az üzenetet látjuk a make buildworld kimenetében: -------------------------------------------------------------- Building everything.. -------------------------------------------------------------- akkor különösebb gond nélkül megcsinálhatjuk. Amennyiben viszont nem látunk ilyen üzenetet, vagy nem vagyunk benne biztosak, akkor még mindig jobb elõvigyázatosnak lenni, ezért kénytelenek leszünk teljesen elölrõl kezdeni a fordítást. Hogyan tudjuk felgyorsítani a fordítást? Futtassuk egyfelhasználós módban. Tegyük a /usr/src és /usr/obj könyvtárakat külön állományrendszerekre, külön lemezekre. Sõt, ha lehetséges, akkor ezeket a lemezeket tegyük külön lemezvezérlõkre. Még mindig jobb, ha ezeket az állományrendszereket a &man.ccd.4; (lemezek összefûzését vezérlõ meghajtó) segítségével kiterjesztjük több lemezes eszközre. Kapcsoljuk ki a profilozást (az /etc/make.conf állományban a NO_PROFILE=true megadásával). Többnyire úgy sem lesz rá szükségünk. Az /etc/make.conf állományban a CFLAGS változót állítsuk az értékre. Az gyakran sokkal lassabb, az és alig tér el az optimalizálás mértékében. A paraméter hatására pedig a fordítóprogram átmeneti állományok helyett csöveket használ a kommunikációra, és így megtakarít némi lemezhasználatot (a memóriahasználat terhére). Ha a &man.make.1; parancsnak átadjuk a paramétert, akkor képes több mindent párhuzamosan futtatni. Ez sok esetben segít attól függetlenül, hogy egy- vagy többprocesszoros gépünk van. A /usr/src könyvtárat tartalmazó állományrendszert csatlakoztathatjuk (vagy újracsatlakoztathatjuk) a beállítással. Ilyenkor az állományrendszer nem rögzíti a hozzáférés idejét. Erre az információra sincs igazából szükségünk. &prompt.root; mount -u -o noatime /usr/src A fenti példa azt feltételezi, hogy a /usr/src könyvtárnak saját állományrendszere van. Ha ez nem így lenne (tehát például a /usr része), akkor itt azt kell megadnunk, nem pedig a /usr/src nevét. A /usr/obj könyvtárat tartalmazó állományrendszert csatlakoztathatjuk (vagy újracsatlakoztathatjuk) az beállítással. Ennek hatására a lemez írása aszinkron módon történik. Magyarul az írási mûveletek azonnal befejezõdnek, miközben az adat ténylegesen csak pár másodperccel késõbb kerül ki a lemezre. Ezzel az írási kérelmek gyönyörûen összegyûjthetõek, ami nagymértékû növekedést eredményez a teljesítményben. Ne felejtsük el azonban, hogy ezzel együtt az állományrendszerünk is sérülékenyebbé válik. Ezen beállítás használatával megnõ annak az esélye, hogy egy áramkimaradást követõ indításnál az állományrendszer helyreállíthatatlan állapotba kerül. Ha egyedül csak a /usr/obj található ezen az állományrendszeren, akkor ez nem jelent akkora veszélyt. Amikor viszont rajta kívül még értékes adat is található az állományrendszeren, a beállítás érvényesítése elõtt mindenképpen készítsünk róla friss mentéseket. &prompt.root; mount -u -o async /usr/obj Ahogy arról az elõbb is szó esett, ha a /usr/obj nem egy különálló állományrendszeren található, akkor a példában szereplõ csatlakozási pontot cseréljük ki a megfelelõre. Mi tegyünk, ha valami nem megy rendesen? Egyértelmûen bizonyosodjunk meg róla, hogy a korábbi fordításokból nem maradtak vissza semmiféle kóbor állományok. Ennyi sokszor pontosan elég. &prompt.root; chflags -R noschg /usr/obj/usr &prompt.root; rm -rf /usr/obj/usr &prompt.root; cd /usr/src &prompt.root; make cleandir &prompt.root; make cleandir Igen, a make cleandir parancsot tényleg kétszer kell kiadni. Ezután a make buildworld parancstól indulva kezdjük újra a fordítást. Ha még ezek után is fennáll a probléma, küldjük el a hibát tartalmazó kimenetet és a uname -a parancs eredményét a &a.questions; címére. Ne lepõdjünk meg, ha a beállításainkra vonatkozóan még kapunk további kérdéseket is! Mike Meyer Írta: A források követése több géppel NFS több gép telepítése Ha egyszerre több számítógéppel is szeretnénk követni ugyanannak a forrásfának a változásait és ezért mindegyikre letöltjük a forrásokat majd újrafordítjuk ezeket, akkor sok erõforrást, de leginkább lemezterületet, hálózati sávszélességet és processzoridõt, feleslegesen használunk. Ezekkel úgy tudunk spórolni, ha valójában csak egyetlen géppel végeztetjük el a munka legtöbb részét, miközben a többi NFS használatával dolgozik. Ez a szakasz ezt a módszert foglalja össze. Elõkészületek Elõször is szedjük össze az egyezõ binárisokat futtató gépeket, melyekre a továbbiakban csak fordítási csoport néven hivatkozunk. Minden gépnek lehet saját rendszermagja, viszont a felhasználói programok mindegyikõjük esetében ugyanazok. Ebbõl a csoportból válasszuk ki egy fordító gépet. Ez lesz az a gép, amelyen a rendszer és a rendszermag lefordításra kerül. Ideális esetben ez a leggyorsabb gép, amelynek elegendõ a processzorkapacitása arra, hogy lefuttassa a make buildworld és make buildkernel parancsokat. Érdemes még rajta kívül kiválasztanunk egy tesztelõ gépet is, ahol a véglegesítés elõtt kipróbálhatjuk a szoftverfrissítéseket. Ennek egy olyan gépnek kell lennie, amely akár hosszabb ideig is nélkülözhetõ a csoportból. Lehet akár maga a fordítást végzõ gép is, de nem elvárás. A fordítási csoportban levõ összes gépnek ugyanarról a géprõl és ugyanarra a pontra kell csatlakoztatnia a /usr/obj és /usr/src könyvtárakat. Ezek optimális esetben a fordítással foglalkozó gép két külön lemezmeghajtóján vannak, melyek egyaránt elérhetõek NFS-en keresztül. Ha több fordítási csoportunk is van, akkor az /usr/src könyvtárnak elegendõ csak egyetlen fordító gépen meglennie, a többi pedig csatlakoztassa NFS-en keresztül. Végül gyõzödjünk meg róla, hogy az /etc/make.conf és a /etc/src.conf állományok tartalma a fordítási csoport mindegyik gépénél megegyezik a fordító gépével. Ez azt jelenti, hogy a fordító gépnek az alaprendszer ugyanazon részeit és ugyanúgy kell létrehozni, mint amelyet a fordítási csoport akármelyik gépére telepíteni is akarunk. Ezenkívül még a fordítási csoportban levõ minden egyes gép /etc/make.conf állományában a KERNCONF értékének a saját rendszermagjára vonatkozó konfigurációt kell megadni, illetve a fordítással foglakozó gép KERNCONF változójánál pedig az együtt összeset, a sajátjával kezdve. Ennek megfelelõen a fordító gépnek a rendszermagok lefordításához rendelkeznie kell az egyes gépek /usr/src/sys/arch/conf könyvtárában meglevõ állományaival. Az alaprendszer Most, miután mindent megfelelõen elõkészítettünk, készen állunk a munkára. A ban leírtak szerint fordítsuk le a rendszermagokat és az alaprendszert a fordító gépen, de utána még nem telepítsünk semmit se. Ha befejezõdött a fordítás, lépjünk be a tesztelõ gépre és telepítsük a frissen fordított rendszermagot. Ha ez a gép NFS-en keresztül éri a /usr/src és /usr/obj könyvtárakat, akkor az egyfelhasználós módban aktiválni kell a hálózatot, majd csatlakoztatni ezeket. Ezt legkönnyebben úgy tudjuk megcsinálni, ha a gépet elõször elindítjuk többfelhasználós módban, majd a shutdown now paranccsal egyfelhasználós módba váltunk. Ha eljuttunk ide, telepítsünk az új rendszermagot és rendszert, illetve a megszokott módon futtassuk a mergemaster parancsot. Amikor ezt befejeztük, ezen a gépen térjünk vissza a hétköznapi többfelhasználós mûködési módba. Miután a tesztelésre szánt gépen ellenõriztük, hogy minden a megfelelõ módon mûködik, az elõbb tárgyalt eljárással telepítsük fel a fordítási csoportban levõ összes többi gépre is az új szoftvereket. Portok Ugyanezt a gondolatmenet alkalmazható a portfa esetében is. Az elsõ és egyben legfontosabb lépés a /usr/ports csatlakoztatása ugyanarról a géprõl a fordítási csoport minden gépére. Az /etc/make.conf megfelelõ beállításával még a terjesztési állományokat is meg tudjuk osztani. A DISTDIR értékét egy olyan közösen használt könyvtárra állítsuk, amely írható az NFS-en keresztül megosztott állományrendszerünkben a root felhasználóként tevékenykedõk számára. A WRKDIRPREFIX változót minden gépen egy helyi fordítási könyvtárra állítsuk. Zárásképpen még hozzátesszük, hogy ha csomagokat akarunk készíteni és mások számára is elérhetõvé tenni, akkor ne felejtsük el a PACKAGES változót a DISTDIR változóhoz hasonlóan beállítani. diff --git a/hu_HU.ISO8859-2/books/handbook/desktop/chapter.sgml b/hu_HU.ISO8859-2/books/handbook/desktop/chapter.sgml index 00ed5ff501..748ea59a1f 100644 --- a/hu_HU.ISO8859-2/books/handbook/desktop/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/desktop/chapter.sgml @@ -1,1430 +1,1456 @@ Christophe Juniet Írta: Asztali alkalmazások Áttekintés A &os;-n asztali alkalmazások széles spektrumát lehet futtatni, például böngészõket és szövegszerkesztõket. Legtöbbjük csomagként áll rendelkezésre, illetve automatizált módon lefordíthatóak a Portgyûjteménybõl. Az új felhasználók közül sokan szeretnének ilyen fajta alkalmazásokat használni, ezért ez a fejezet bemutatja, miként lehet a népszerûbb asztali alkalmazásokat minden különösebb erõfeszítés nélkül telepíteni, legyen szó az elõre csomagolt vagy a Portgyûjteményben megtalálható formájukról. Amikor portként telepítünk egy programot, lényegében a forráskódját fordítjuk le. Ez bizonyos esetekben nagyon sokáig is eltarthat attól függõen, hogy pontosan mit is fordítunk le, illetve mekkora az erre a célra felhasznált számítógépünk vagy számítógépeink teljesítménye. Amennyiben a fordításra nem tudunk vagy nem kívánunk elegendõ idõt szánni, a Portgyûjteményben található programok többségét már elõre lefordított csomagból is telepíthetjük. Mivel a &os;-ben bináris szintû Linux kompatibilitás is található, ezért az eredetileg Linuxra fejlesztett alkalmazások is használhatóak a munkakörnyezetünkben. Azonban határozottan javasoljuk, hogy a linuxos alkalmazások használatához elõször figyelmesen olvassuk át a et. A linuxos bináris kompabilitást használó portok neve általában a linux- elõtaggal kezdõdik, amit ne felejtsük el figyelembe venni, amikor például a &man.whereis.1; segítségével keressük valamelyiket. A fejezet további részében feltételezzük, hogy a linuxos alkalmazások telepítése elõtt aktiváltuk a bináris Linux kompatibilitást. Íme a fejezetben tárgyalt kategóriák: Böngészõk (mint a Firefox, Opera, Konqueror) Irodai eszközök (mint a KOffice, AbiWord, The GIMP, OpenOffice.org) Dokumentum-megjelenítõk (mint az &acrobat.reader;, gv, Xpdf, GQview) Pénzügyi szoftverek (mint a GnuCash, Gnumeric, Abacus) A fejezet elolvasásához ajánlott: a külsõ alkalmazások telepítésének ismerete (); linuxos alkalmazások telepítésének ismerete (). a multimédiás környezet kialakítására vonatkozó információkért a et érdemes elolvasni. Az elektronikus levelezés beállítását és használatát a bõl tudhatjuk meg. Böngészõk böngészõk világháló A &os;-vel együtt nem települ semmilyen böngészõ. Helyette keressük meg a Portgyûjteményben a www könyvtárat, ahol ezzel szemben rengeteg böngészõ áll telepítésre készen. Ha nem lenne idõnk mindent lefordítani (ami egyes esetekben akár rengeteg idõnkbe is kerülhet), ezek csomagolt formában is elérhetõek. A KDE-hez és a GNOME-hoz eleve tartoznak HTML-böngészõk. Ezen komplett munkakörnyezetek beállításához a t olvassuk el. Ha viszont csak egy kevés erõforrást igénylõ böngészõkre vágyunk, érdemes megnéznünk a Portgyûjteményben található www/dillo2, www/links vagy www/w3m portokat. Ez a rész az alábbi alkalmazásokat említi: Alkalmazás Erõforrásigény Telepítés forrásból Fõbb függõségek Firefox közepes nehéz Gtk+ Opera kevés könnyû Vannak &os;-s és linuxos változatai is. A linuxos verzió használatához azonban szükség van a bináris Linux kompatibilitásra és a linux-openmotif portra. Konqueror közepes nehéz A KDE függvénykönyvtárai. Firefox Firefox A Firefox egy modern, szabad és nyílt forráskódú böngészõ, amely tökéletesen használható &os; alatt. Megtalálható benne egy, a jelenlegi HTML szabványoknak nagyon jól megfelelõ megjelenítõ motor, a lapokra bontható böngészés támogatása, a kéretlenül felbukkanó ablakok blokkolása, különbözõ kiterjesztések, javított biztonsági lehetõségek és még sok minden más. A Firefox forrása a Mozilla kódján alapszik. Csomagból így telepíthetõ: &prompt.root; pkg_add -r firefox Ekkor a Firefox 3.6 változata fog települni. Ha helyette a Firefox 3.5 változatát szeretnénk használni, akkor ezt a parancsot adjuk ki: &prompt.root; pkg_add -r firefox35 Ha forrásból szeretnénk felrakni, használhatjuk a Portgyûjteményben található portját is: &prompt.root; cd /usr/ports/www/firefox &prompt.root; make install clean A Firefox 3.5 telepítéséhez az iménti parancsban cseréljük ki a firefox részt a firefox35 könyvtárra. A Firefox és a &java; plugin Ennél és a következõ résznél feltételezzük, hogy már korábban telepítettük a Firefox alkalmazást. A &java; plugin jelenleg nem mûködik a Firefox 3.6 változatával. A &os; Alapítvány megegyezett a Sun Microsystems-szel, hogy terjesztheti a &java; futtatókörnyezet (&jre;) és a &java; fejlesztõkörnyezet (&jdk;) &os;-re lefordított bináris változatait. Ezek a csomagok elérhetõek a &os; Alapítvány honlapjáról. Ha tehát &java;-támogatást szeretnénk hozzáadni a Firefox böngészõhöz, elsõként fel kell telepítenünk a java/javavmwrapper portot. Ezután le kell töltenünk a Diablo &jre; csomagot a címrõl, majd telepítenünk azt a &man.pkg.add.1; segítségével. + + Ezen az oldalon nem találunk bináris + csomagokat &os; 8.X + rendszerekhez, azonban a + &os; 7.X rendszerekhez + készült csomagok használhatóak + 8.X esetén is. Ehhez + mindössze a misc/compat7x portot kell + elõtte telepítenünk. + + A másik lehetõség a Diablo + &jre; (valamint a Diablo + &jdk;) telepítése a + Portgyûjteménybõl (java/diablo-jre16 és + java/diablo-jdk16). Ehhez + a szükséges forrásokat (distfile + állományokat) licencelési + megkötések miatt nekünk kell külön + letölteni. A kapcsolódó + utasításokat a make + maketarget parancs meghívásával + kaphatjuk meg. + + Indítsuk el a böngészõnket, és írjuk be a címsorba, hogy about:plugins és nyomjuk le az Enter billentyût. Az eredményül kapott oldalon láthatjuk az eddig telepített pluginok listáját, ahol mostanra már a &java; pluginnak is meg kell jelennie. Amennyiben ez nem következne be, mindegyik felhasználónál adjuk ki az alábbi parancsot: &prompt.user; ln -s /usr/local/diablo-jre1.6.0/plugin/i386/ns7/libjavaplugin_oji.so \ $HOME/.mozilla/plugins/ Vagy ha a Diablo &jdk; csomagot telepítettük: &prompt.user; ln -s /usr/local/diablo-jdk1.6.0/jre/plugin/i386/ns7/libjavaplugin_oji.so \ $HOME/.mozilla/plugins/ Ezt követõen indítsuk újra a böngészõnket. Ezek a parancsok az &arch.i386; architektúra használatát feltételezik, de a csomagok az &arch.amd64; architektúra esetén is elérhetõek. A Firefox és a ¯omedia; &flash; plugin Flash A ¯omedia; &flash; plugin nem érhetõ el közvetlenül &os;-re. Azonban létezik egy, a plugin linuxos verziójára épített szoftveres réteg (wrapper). Ez a wrapper még többek közt az &adobe; &acrobat; és a &realplayer; pluginjait is használhatóvá teszi. Attól függõen, hogy a &os; melyik változatát használjuk, különbözõ módokon tudjuk mûködésbe hozni: &os; 7.<replaceable>X</replaceable> Telepítsük a www/nspluginwrapper portot. Ehhez szükség lesz még az emulators/linux_base-fc4 portra is, amely viszonylag nagy méretû. Következõ lépésként telepítsük a www/linux-flashplugin9 portot. Ezáltal megkapjuk a &flash; 9.X változatát, amely &os; 7.X alatt remekül mûködik. A 7.1-RELEASE elõtti &os; verziók esetén a www/linux-flashplugin7 portot telepítsük és hagyjuk ki a &man.linprocfs.5; használatára vonatkozó részt. &os; 8.<replaceable>X</replaceable> Telepítsük a www/nspluginwrapper portot. Ehhez szükségünk lesz majd a valamivel nagyobb emulators/linux_base-f10 portra. Ezt követõen telepítsük a www/linux-f10-flashplugin10 portot. Ekkor a &flash; 10.X változatát kapjuk, amely &os; 8.X alatt remekül használható. Ezen változat beüzemeléséhez még létre kell hoznunk az alábbi linket: &prompt.root; ln -s /usr/local/lib/npapi/linux-f10-flashplugin/libflashplayer.so \ /usr/local/lib/browser_plugins/ Miután a &os; rendszerünk változatának megfelelõen elvégeztük a &flash; port telepítését, a plugint az egyes felhasználóknak a nspluginwrapper paranccsal tehetjük elérhetõvé: &prompt.user; nspluginwrapper -v -a -i Ha &flash; animációkat szeretnénk lejátszani, akkor ehhez a /usr/compat/linux/proc könyvtárba csatlakoztatnunk kell egy &man.linprocfs.5; típusú linuxos proc állományrendszert. Ezt a következõ paranccsal tehetjük meg: &prompt.root; mount -t linprocfs linproc /usr/compat/linux/proc Az /etc/fstab állományban az alábbi sor hozzáadásával azonban ennek csatlakoztatása akár automatikussá is tehetõ a rendszerindítás során: linproc /usr/compat/linux/proc linprocfs rw 0 0 Ezután indítsuk el a böngészõt, majd gépeljük be az about:plugins szöveget a címsorba és nyomjuk le az Enter billentyût. Ekkor a jelenleg elérhetõ pluginok listájának kell megjelennie. A Firefox és az Swfdec &flash; plugin Az Swfdec egy &flash; animációk dekódolásáért és megjelenítéséért felelõs programkönyvtár. Az Swfdec-Mozilla pedig egy Firefox böngészõkhöz készített plugin, amely az Swfdec könyvtáron keresztül játszik le SWF állományokat. Jelenleg még aktív fejlesztés alatt áll. Ha nem akarjuk vagy netalán nem tudjuk forrásból lefordítani, akkor egyszerûen csak telepítsük csomagként a hálózaton keresztül: &prompt.root; pkg_add -r swfdec-plugin Ha valamiért mégsem érhetõ el hozzá csomag, akkor a Portgyûjteménybõl is telepíthetjük: &prompt.root; cd /usr/ports/www/swfdec-plugin &prompt.root; make install clean Miután telepítettük a plugint, a használatához indítsuk újra a böngészõt. Opera Opera Az Opera egy sokoldalú és szabványokkal kompatibilis böngészõ. Tartalmaz beépített levelezõ klienst és hírolvasót, IRC-klienst, RSS/Atom-olvasót és még sok mindent mást. Ennek ellenére az Opera viszonylag pehelysúlyúnak és gyorsnak számít. Két fajta módon is használható: létezik natív &os;-s változata, valamint a Linux emulációval futó változata. Az Opera &os;-s változatát a megfelelõ csomag telepítésével érhetjük el: &prompt.root; pkg_add -r opera Habár egyes FTP oldalakon nem található meg az összes csomag, viszont a Portgyûjteménybõl még ekkor is be tudjuk szerezni az Operat: &prompt.root; cd /usr/ports/www/opera &prompt.root; make install clean A linuxos Opera telepítéséhez opera helyett linux-opera nevet kell megadnunk a fenti parancsokban. Ennek a verziónak a használata akkor lehet elõnyös, ha olyan plugineket akarunk elérni, amelyek csak Linuxra léteznek. Ilyen például az Adobe &acrobat.reader;. Ettõl eltekintve azonban a &os;-s és a linuxos változatok szinte teljesen megegyeznek. Konqueror Konqueror A Konqueror a KDE része, de a használatához elegendõ, ha csak a x11/kdebase3 portot telepítjük fel. A Konqueror több, mint egy egyszerû böngészõ: állománykezelõ és multimédiás nézegetõ is. Számtalan plugin áll rendelkezésre a Konquerorhoz, melyeket a misc/konq-plugins portban találunk meg. A Konqueror ismeri a &flash;t is. A &flash; és a Konqueror kapcsolatával egy külön Hogyan is foglalkozik, amelyet a címen olvashatunk el. Irodai eszközök Amikor irodai felhasználásról van szó, az új felhasználók gyakorta keresnek egy jó irodai programcsomagot vagy egy barátságos szövegszerkesztõt. Habár az egyes munkakörnyezetek, mint például a KDE, gyakran saját irodai eszközöket is tartalmaznak, &os; alatt nincs alapértelmezett irodai programcsomag. A rendszer a munkakörnyezetektõl függetlenül igyekszik felkínálni mindazt, amire szükségünk lehet. Ebben a részben a következõ alkalmazásokról esik szó: Alkalmazás Erõforrásigény Telepítés forrásból Fõbb függõségek KOffice kevés nehéz KDE AbiWord kevés könnyû Gtk+ vagy GNOME The Gimp kevés nehéz Gtk+ OpenOffice.org sok nagyon nehéz &jdk;, Mozilla KOffice KOffice irodai programcsomag KOffice A KDE közösség által kiadott munkakörnyezethez társul egy irodai programcsomag is, amely a KDE-tõl függetlenül is használható. Tartalmazza a többi irodai programcsomagban is megtalálható négy szabványos komponenst: a KWord szövegszerkesztõt, a KSpread táblazatkezelõt, a KPresenter prezentációkészítõt és végezetül a Kontourt, mellyel grafikus dokumentumokat tudunk elkészíteni. A legfrissebb KOffice telepítése elõtt bizonyosodjuk meg róla, hogy a KDE legfrissebb verziójával is rendelkezünk. Ha a KOffice-t csomagként akarjuk telepíteni, akkor adjuk ki az alábbi parancsot: &prompt.root; pkg_add -r koffice Amennyiben ez a csomag nem érhetõ el, telepíthetjük a Portgyûjteménybõl is. Például a KDE3-hoz tartozó KOffice-t így rakhatjuk fel: &prompt.root; cd /usr/ports/editors/koffice-kde3 &prompt.root; make install clean AbiWord AbiWord Az AbiWord egy szabad szövegszerkesztõ program, a µsoft; Word-höz hasonló kinézettel. Remekül használható levelek, beszámolók, feljegyzések, cikkek stb. írásához. Nagyon gyors, rengeteg funkciót ajánl fel, és kifejezetten felhasználóbarát. Az AbiWord képes többféle állományformátumba exportálni és onnan importálni, beleértve az olyan zárt formátumokat is, mint például a µsoft; .doc. Az AbiWord csomagból telepíthetõ a következõ módon: &prompt.root; pkg_add -r abiword Amennyiben ez a csomag nem érhetõ el, lefordítható a Portgyûjteménybõl is, ami ráadásul sokszor egy frissebb verziót tartalmaz. Ezt így tudjuk megtenni: &prompt.root; cd /usr/ports/editors/abiword &prompt.root; make install clean The GIMP The GIMP Képek készítésére vagy retusálásra a The GIMP a legfejlettebb képszerkesztõ program. Egyszerû rajzolóprogram gyanánt is használható, de akár minõségi fényképretusálásra is. Óriási mennyiségû plugin található hozzá és magában foglal egy szkriptes interfészt is. A The GIMP formátumok széles skáláját ismeri. Számos scanner és digitális rajztábla csatlakoztatható hozzá. A hozzá tartozó csomag a következõ módon telepíthetõ fel: &prompt.root; pkg_add -r gimp Ha a csomagoknak beállított FTP oldalon nem található meg ez a csomag, megpróbálkozhatunk vele a Portgyûjteményen keresztül is. A gyûjtemény graphics könyvtárában ezen felül fellelhetjük a The Gimp Manualt, vagyis a The GIMP kézikönyvét. Így kell ezeket innen telepíteni: &prompt.root; cd /usr/ports/graphics/gimp &prompt.root; make install clean &prompt.root; cd /usr/ports/graphics/gimp-manual-pdf &prompt.root; make install clean A Portgyûjtemény graphics könyvtárában a The GIMP fejlesztõi változatával is találkozhatunk a graphics/gimp-devel alkönyvtárban. A The Gimp Manual HTML változata pedig a graphics/gimp-manual-html alkönyvtárban található. OpenOffice.org OpenOffice.org irodai programcsomag OpenOffice.org Az OpenOffice.org tartalmaz minden olyan elengedhetetlenül fontos alkalmazást, amelyek napjaink bármelyik irodájához hozzátartoznak: egy szövegszerkesztõt, egy táblázatkezelõt, egy prezentációszerkesztõt és egy rajzolóprogramot. A felhasználói felülete nagyon hasonlít a többi irodai programcsomagéhoz, és képes többféle elterjedt állományformátumot kezelni. Számos különbözõ nyelven elérhetõ — a honosítása kiterjed a felületekre, helyesírás-ellenõrzõkre és szótárakra is. Az OpenOffice.org szövegszerkesztõje natív XML állományformátumot használ a hordozhatóság és a rugalmasság növeléséhez. A táblázatkezelõje tartalmaz egy makrónyelvet és könnyedén összekapcsolható külsõ adatbázisokkal. Az OpenOffice.org natívan és megbízhatóan fut &windows;-on, &solaris;-on, &linux;-on, &os;-n és &macos; X-en. Az OpenOffice.org-ról bõvebb információt a projekt saját honlapján találhatunk. A &os;-s változatra vonatkozó információkat és a csomagokat pedig a &os; OpenOffice.org Porting Team honlapján lelhetjük meg. Az OpenOffice.org telepítéséhez ennyit kell csak beírni: &prompt.root; pkg_add -r openoffice.org Ha a &os; -RELEASE ágát használjuk, ennek mûködnie kell. Ettõl eltérõ esetben érdemes egy pillantást vetni a &os; OpenOffice.org Porting Team honlapjára, ahonnan le tudjuk tölteni a verziókhoz megfelelõ csomagot, amelyet ezután a &man.pkg.add.1;-al fel is tudunk telepíteni. A legfrissebb megbízható és a fejlesztõi változat egyaránt elérhetõ errõl a helyrõl. Ahogy sikerült feltelepíteni a csomagot, egyszerûen csak be kell gépelni a következõ parancsot az OpenOffice.org futtatásához: &prompt.user; openoffice.org Az elsõ futtatás során válaszolnunk kell még néhány további kérdésre is, valamint a felhasználói könyvtárunkban keletkezik egy .openoffice.org könyvtár. Ha nem érhetõek el OpenOffice.org csomagok, lefordíthatjuk a forrását is. Azonban mielõtt még ennek nekilátnánk, el kell fogadnunk, hogy ez a mûvelet a lemezünkön rettenetesen sok területet fog igényelni és meglehetõsen sokáig tart. &prompt.root; cd /usr/ports/editors/openoffice.org-3 &prompt.root; make install clean Ha egy honosított verziót szeretnénk fordítani, az utolsó parancs helyett írjuk inkább ezt: &prompt.root; make LOCALIZED_LANG=nyelv install clean A nyelv helyett itt természetesen a nyelvnek megfelelõ ISO-kódot kell megadni. Az itt támogatott nyelvek kódjának listája a port könyvtárán belül, a files/Makefile.localized állományban található meg. Ahogy a fordítás befejezõdött, az OpenOffice.org így indítható el parancssorból: &prompt.user; openoffice.org Dokumentum-megjelenítõk A &unix; megjelenése óta néhány új népszerû dokumentumformátum is felbukkant, melyek szabványos megjelenítõi nem minden esetben részei az alaprendszernek. Ebben a részben azt tekintjük át, hogyan lehet ilyen megjelenítõket telepíteni. Ez a rész az alábbi alkalmazásokat említi: Alkalmazás Erõforrásigény Telepítés forrásból Fõbb függõségek &acrobat.reader; kevés könnyû Bináris Linux kompatibilitás gv kevés könnyû Xaw3d Xpdf kevés könnyû FreeType GQview kevés könnyû Gtk+ vagy GNOME &acrobat.reader; Acrobat Reader PDF megjelenítõ A dokumentumok többsége manapság PDF (Portable Document Format, avagy hordozható dokumentumformátum) állományok formájában terjed. Az ilyen típusú állományok megnézésére az egyik legmegfelelõbb alkalmazás az &acrobat.reader;, melyet az Adobe adott ki Linuxra. De mivel a &os; képes Linux binárisok futtatására, ezért így &os;-re is elérhetõ. Ha az &acrobat.reader; 8-at a Portgyûjteménybõl akarjuk telepíteni, akkor írjuk be: &prompt.root; cd /usr/ports/print/acroread8 &prompt.root; make install clean Licencelési megszorítások miatt csomag nem áll rendelkezésre. gv gv PDF megjelenítõ PostScript megjelenítõ A gv egy &postscript; és PDF megjelenítõ. Eredetileg a ghostview alapján készült, de a Xaw3d-nek köszönhetõen sokkal szebben néz ki. Gyors és a felülete letisztult. A gv sok mindent tud, többek közt beállítható benne a dokumentum tájolása, a papírméret, skálázás és az élsimítás. Szinte bármelyik mûvelet elvégezhetõ csak billentyûzetrõl vagy egérrel. A gv csomagjának telepítéséhez a következõ parancsot használhatjuk: &prompt.root; pkg_add -r gv Ha pedig nem tudjuk letölteni a csomagot, használhatjuk a Portgyûjteményt is: &prompt.root; cd /usr/ports/print/gv &prompt.root; make install clean Xpdf Xpdf PDF megjelenítõ Ha egy egyszerû &os;-s PDF megjelenítõre lenne szükségünk, erre a célra az Xpdf pontosan megfelel. Nagyon kevés erõforrást igényel és nagyon megbízható. A szabványos X-beli betûtípusokat használja, és nincs szüksége sem a &motif;ra, sem pedig más X-es eszközkészletre. Az Xpdf csomagjának felrakásához az alábbi parancs javasolt: &prompt.root; pkg_add -r xpdf Amennyiben nem áll rendelkezésre az említett csomag, vagy egyszerûen csak a Portgyûjteménybõl szeretnénk felrakni, adjuk ki ezeket a parancsokat: &prompt.root; cd /usr/ports/graphics/xpdf &prompt.root; make install clean Ahogy a telepítés befejezõdik, már el is indíthatjuk az Xpdf alkalmazást, ahol a jobb egérgombbal tudjuk aktiválni a menüt. GQview GQview A GQview egy képkezelõ. Állományokat tudunk megnyitni benne egyetlen kattintással, külsõ szerkesztõprogramot tudunk indítani vagy akár még a képek kicsinyített változatait is láthatjuk és így tovább. Megtalálható benne a diavetítés és az alapvetõ állománymûveletek. Képgyûjteményeket is kezelhetünk és könnyedén megtalálhatjuk a bennük levõ képek között az egyezõeket. A GQview teljes képernyõs nézegetést is megenged, illetve támogatja a honosítást. A GQview csomag telepítéséhez ezt a parancsot kell kiadni: &prompt.root; pkg_add -r gqview Amikor ez a csomag nem tölthetõ le, vagy amikor inkább a Portgyûjteménybõl szeretnénk felrakni, ezt írjuk be: &prompt.root; cd /usr/ports/graphics/gqview &prompt.root; make install clean Pénzügyi szoftverek Ha bármilyen ok folytán a &os;-vel szeretnénk kezeli személyes pénzügyeinket, akadnak olyan kellõen komoly és könnyen kezelhetõ alkalmazások, amelyek csak a telepítésükre várnak. Néhány közülük kompatibilis az elterjedtebb állományformátumokkal, mint például amiben a Quicken és az Excel is tárolja az adatait. Ebben a részben az alábbi programokat vesszük sorra: Alkalmazás Erõforrásigény Telepítés forrásból Fõbb függõségek GnuCash kevés nehéz GNOME Gnumeric kevés nehéz GNOME Abacus kevés könnyû Tcl/Tk KMyMoney kevés nehéz KDE GnuCash GnuCash A GnuCash a GNOME része, és egy felhasználóbarát, mégis hatékony eszközt ad a felhasználók kezébe. A GnuCash segítségével nyilván tudjuk tartani a bevételeinket és kiadásainkat, bankszámláinkat és befektetéseinket. Felülete intuitív, miközben továbbra is professzionális minõségû. A GnuCash-ben megtalálhatunk egy intelligens nyilvántartást, a számlák hierarchikus rendszerét, és számtalan billentyûkombinációt és automatikus kiegészítést, amivel felgyorsul a munkánk. Egyetlen tranzakciót képes felbontani több kisebb és részletesebb elemre. A GnuCash képes importálni és exportálni a Quicken QIF típusú állományait. Ezenkívül még kezeli a legtöbb nemzetközi dátumformátumot és pénznemet. A GnuCash-t az alábbi módon tudjuk telepíteni a rendszerünkre: &prompt.root; pkg_add -r gnucash Ha ez a csomag nem érhetõ el, használhatjuk a Portgyûjteményt is: &prompt.root; cd /usr/ports/finance/gnucash &prompt.root; make install clean Gnumeric Gnumeric táblázatkezelõ Gnumeric A Gnumeric egy táblázatkezelõ program, a GNOME munkakörnyezet része. Sok esetben képes a helyzethez alkalmazkodva automatikusan kitalálni a felhasználó gondolatait a cellák formátumának megfelelõ automatikus kiegészítõ rendszerével. Be tud olvasni számos népszerûbb formátumot, mint például az Excel, Lotus 1-2-3 vagy a Quattro Pro állományait. A math/guppi grafikonkészítõ programon keresztül támogatja grafikonok rajzolását is. Nagyszámú beépített funkcióval rendelkezik, és ismeri az összes megszokott cellaformátumot, legyen az szám, pénznem, dátum, idõ vagy bármi más. A Gnumeric telepítését az alábbi paranccsal adhatjuk ki: &prompt.root; pkg_add -r gnumeric Ha valamiért nem érhetõ el ez a csomag, a Portgyûjteménybõl is fel tudjuk rakni: &prompt.root; cd /usr/ports/math/gnumeric &prompt.root; make install clean Abacus Abacus táblázatkezelõ Abacus Az Abacus egy kicsi és egyszerûen használható táblázatkezelõ program. Számos olyan funkciót tartalmaz beépítve, amelyek kifejezetten hasznosnak bizonyulhatnak a statisztika, pénzügyek és a matematika területén. Importálni és exportálni tudja az Excel állományformátumát is. Az Abacus még &postscript; formátumú kimenetet is tud készíteni. Az Abacus telepítéséhez csupán ennyit kell tennünk: &prompt.root; pkg_add -r abacus Amennyiben viszont nem érhetõ el ez a csomag, használhatjuk a Portgyûjteményt is: &prompt.root; cd /usr/ports/deskutils/abacus &prompt.root; make install clean KMyMoney KMyMoney táblázatkezelõ KMyMoney A KMyMoney a KDE részeként kifejlesztett személyi pénzügyi nyilvántartó. A KMyMoney igyekszik az összes kereskedelmi pénzügyi nyilvántartó programban megtalálható fontosabb lehetõséget magában foglalni és rendelkezésre bocsátani. Mindezek mellett egy könnyen használható és nagyon ügyes kettõs könyvelést is találhatunk benne. A KMyMoney képes beolvasni a szabványos Quicken Interchange Format (QIF) szerint készült állományokat, követni a befektetéseket, többféle pénznemet kezelni és sokfajta kimutatást tudunk vele készíteni. A megfelelõ bõvítmény hozzáadásával még az OFX formátumú állományok olvasására is alkalmas. A KMyMoney csomagként így telepíthetõ: &prompt.root; pkg_add -r kmymoney2 Ha ez a csomag nem érhetõ el, akkor a Portgyûjteményen keresztül is fel tudjuk rakni: &prompt.root; cd /usr/ports/finance/kmymoney2 &prompt.root; make install clean Összefoglalás Miközben a &os; igen népszerû az internetszolgáltatók körében a teljesítménye és megbízhatósága révén, a hétköznapi használatban is remekül beválik. Többezernyi olyan alkalmazás érhetõ el hozzá csomagként vagy portként, amelyekkel az igényeinknek megfelelõ munkakörnyezetet tudjuk kiépíteni. Íme egy rövidke emlékeztetõ azokról az asztali alkalmazásokról, melyeket a fejezetben tárgyaltunk: Alkalmazás Csomag Port Opera opera www/opera Firefox firefox www/firefox KOffice koffice-kde3 editors/koffice-kde3 AbiWord abiword editors/abiword The GIMP gimp graphics/gimp OpenOffice.org openoffice editors/openoffice.org-3 &acrobat.reader; acroread print/acroread8 gv gv print/gv Xpdf xpdf graphics/xpdf GQview gqview graphics/gqview GnuCash gnucash finance/gnucash Gnumeric gnumeric math/gnumeric Abacus abacus deskutils/abacus KMyMoney kmymoney2 finance/kmymoney2 diff --git a/hu_HU.ISO8859-2/books/handbook/install/chapter.sgml b/hu_HU.ISO8859-2/books/handbook/install/chapter.sgml index 1dd9c30021..b68371700c 100644 --- a/hu_HU.ISO8859-2/books/handbook/install/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/install/chapter.sgml @@ -1,7204 +1,7203 @@ Jim Mock Átszervezte, átrendezte és egyes részeit átdolgozta: Randy Pratt A sysinstall bemutatása, ábrái és bemásolása: A &os; telepítése Áttekintés telepítés A &os; telepítéséhez egy könnyen használható szöveges telepítõprogram, a sysinstall használható. Ez a &os; alapértelmezett telepítõprogramja, habár ezt a különféle gyártók kedvük szerint lecserélhetik. Ebben a fejezetben bemutatjuk a &os; sysinstall segítségével történõ telepítését. A fejezet elolvasása során megismerjük: hogyan készítsünk telepítõlemezeket a &os;-hez; a &os; miként hivatkozza és osztja fel a merevlemezeinket; hogyan indítsuk el a sysinstall programot; milyen kérdéseket tesz fel nekünk a sysinstall, mire gondol, hogyan is kell azokat megválaszolni. A fejezet elolvasásához ajánlott: a telepítendõ &os; verzióhoz tartozó támogatott hardvereket felsoroló lista átolvasása és benne a saját hardvereszközeink megkeresése. Általánosan elmondható, hogy a most következõ telepítési utasítások az &i386; (PC kompatibilis) architektúrájú számítógépekre vonatkoznak. Ahol erre szükség van, ott más platformokra vonatkozó utasítások is szerepelhetnek. Habár ezt a leírás igyekszünk a lehetõ legjobban naprakészen tartani, elképzelhetõ, hogy felfedezhetünk kisebb eltéréseket a telepítõben és az itt leírtak közt. Ezért ezt a fejezetet inkább egy általános útmutatónak javasoljuk, nem pedig egy szó szerint értelmezendõ kézikönyvként. Hardverkövetelmények Minimális konfiguráció A &os; telepítéséhez szükséges minimális konfiguráció &os; verziónként és architektúránként eltérõ. A minimális konfigurációt a &os; honlapján a kiadásokról szóló oldalon, az Installation Notes részben találhatjuk meg. Ezt a következõ szakaszokban foglaljuk össze. A &os; telepítésének módszerétõl függõen szükségünk lehet egy hajlékonylemezes (floppy) vagy CD-ROM meghajtóra, esetleg egy hálózati kártyára. Ezt a ban tárgyaljuk. &os;/&arch.i386; és &os;/&arch.pc98; A &os;/&arch.i386; és &os;/&arch.pc98; egyaránt egy 486 vagy jobb processzort és legalább 24 MB memóriát igényel. A legkisebb telepítéshez legalább 150 MB szabad lemezterület szükséges. Régebbi konfigurációk esetén nem egy gyorsabb processzor, hanem inkább több memória beszerzése, illetve több lemezterület felszabadítása a fontosabb. &os;/&arch.alpha; Alpha Az Alpha támogatás a &os; 7.0 beindulásával eltávolításra került. A &os; 6.X sorozat az utolsó, amely valamilyen támogatást ajánl ehhez az architektúrához. Ezzel kapcsolatban részletesebben a kiadásokkal kapcsolatos információkat tartalmazó oldalon olvashatunk a &os; honlapján. &os;/&arch.amd64; Két típusú processzor képes futtatni a &os;/&arch.amd64; verzióját. Az elsõ ezek közül az AMD64 processzorok, beleértve az &amd.athlon;64, &amd.athlon;64-FX, &amd.opteron; vagy újabb processzorokat. A &os;/&arch.amd64; verzióját kihasználni képes processzorok másik csoportja az &intel; EM64T architektúrájára épülõ processzorok. Ilyen processzor például az &intel; &core; 2 Duo, Quad és Extreme processzorcsaládok, valamint az &intel; &xeon; 3000, 5000 és 7000 sorozatszámú processzorai. Ha nVidia nForce3 Pro-150 alapú géppel rendelkezük, ki kell kapcsolnunk a BIOS-ban az IO APIC használatát. Ha nem találnánk ilyen beállítást, akkor helyette magát az ACPI-t kell kikapcsolnunk. A Pro-150 chipsetnek vannak bizonyos hibái, amelyekre eddig még nem sikerült megfelelõ megoldást találnunk. &os;/&arch.sparc64; A &os;/&arch.sparc64; telepítéséhez egy támogatott platformra van szükségünk (lásd: ). A &os;/&arch.sparc64; telepítéséhez egy egész lemezre lesz szükségünk, mivel a rendszer jelenleg nem képes megosztani azt más operációs rendszerekkel. Támogatott hardverek A &os; minden kiadásához mellékelik a támogatott hardverek listáját &os; Hardware Notes címmel. Ezt a dokumentum többnyire a HARDWARE.TXT nevû állomány, amelyet a rendszer CD-n vagy FTP-n keresztül elérhetõ változatának gyökerében vagy a sysinstall dokumentációkat tartalmazó menüjében találhatunk meg. A telepítés elõtt elvégzendõ feladatok Készítsünk leltárt a számítógépünkrõl A &os; telepítése elõtt érdemes összeszedni, pontosan mi minden is található a számítógépünkben. A &os; telepítõrutinjai mutatni fogják a különbözõ komponensek (merevlemezek, hálózati kártyák, CD-meghajtók és a többi) modelljét és gyártóját. A &os; ezenkívü megpróbálja kideríteni a megjelenõ eszközök pontos konfigurációját is, beleértve a használt IRQ és IO portok kiosztását. A PC-s hardverek különféle szeszélyei miatt azonban ez az iménti folyamat nem minden esetben megbízható, ezért elõfordulhat, hogy helyesbíteni kell a &os; által megállapított értékeket. Ha már van a gépünkön egy másik operációs rendszer, például &windows; vagy &linux;, akkor mindenképpen hasznos lehet az általa felkínált eszközökkel lekérdezni a hardvereink beállításait. Ha nem lennénk biztosak benne, hogy az adott bõvítõkártyákat pontosan milyen beállításokkal is használjuk, nézzük meg ezeket magán a kártyán. A népszerû IRQ értékek általában a 3, 5 és 7, valamint az IO portok számát általában tizenhatos számrendszerben szerepeltetik, például 0x330. Javasoljuk, hogy nyomtassuk ki vagy írjuk le ezeket a paramétereket a &os; telepítése elõtt. Ehhez rendezzük ezeket egy táblázatban, valahogy így: Példa egy eszközleltárra Eszköz neve IRQ IO portok Megjegyzés Elsõ merevlemez - - Mérete 40 GB, gyártmánya Seagate, elsõdleges IDE master CD-ROM meghajtó - - Elsõdleges IDE slave Második merevlemez - - Mérete 20 GB, gyártmánya IBM, másodlagos IDE master Elsõ IDE vezérlõ 14 0x1f0 Hálózati kártya - - &intel; 10/100 Modem - - &tm.3com; 56K-s faxmodem, COM1 …
Ahogy elkészítettük a számítógépünk alkatrészeit tartalmazó listát, vessük ezeket össze a telepítendõ &os; kiadás által megkövetelt eszközökkel. Mentsük le az adatainkat Amennyiben a &os; telepítéséhez használt számítógép számunkra értékes adatokat tárol, igyekezzünk lementeni ezeket, és a &os; tényleges telepítése elõtt gyõzõdjünk is meg róla, hogy a mentés sikeres volt. A &os; telepítõrutinjai természetesen megerõsítést fognak kérni bármilyen adat lemezre írása elõtt, azonban ha egyszer már elindítottuk a folyamatot, már semmit sem tudunk visszafordítani. Döntsük el a &os; telepítésének helyét Ha a &os; telepítéséhez az egész merevlemezünket fel akarjuk használni, akkor még nincs miért izgatnunk magunkat — nyugodtan átléphetjük ezt a szakaszt. Amikor viszont a &os;-t más operációs rendszerek mellé szeretnénk telepíteni, ismernünk kell, miként is helyezkednek el az adatok a lemezeken, és hogy ez miként is érint bennünket. A lemezek kiosztása a &os;/&arch.i386; esetén A PC-k által használt lemezek különálló darabokra tagolhatóak. Ezeket a darabokat partícióknak nevezzük. Mivel azonban a &os; maga is tárol partíciókat, ezért ez az elnevezés pillanatok alatt megtévesztõvé válhat, ezért ezeket a lemezdarabokat a &os; lemezslice-oknak vagy egyszerûen csak slice-oknak hívja. Például a PC-s lemezpartíciókkal dolgozó, fdisk nevû &os;-s segédprogram partíciók helyett is slice-okra hivatkozik. A PC lemezenként alapvetõen csak négy partíciót enged meg. Ezeket a partíciókat nevezik elsõdleges partícióknak. Ettõl a korlátozástól egy új típus, a kiterjesztett partíció létrehozásával szabadultak meg, amivel így négynél több partíció is készíthetõ. Lemezenként egyetlen ilyen kiterjesztett partíció található, de ezen belül speciális, ún. logikai partíciók hozhatóak létre. Minden partíciónak van egy partíció-azonosítója, melyet a partíción található adatok típusának megállapítására használnak. A &os; partícióinak azonosítója a 165. Általánosságban véve minden operációs rendszer így azonosítja a partíciókat. Például a DOS és annak leszármazottai, mint például a &windows;, minden elsõdleges és logikai partícióhoz egy C:-tõl induló meghajtó-betûjelet társít. A &os;-t egy elsõdleges partícióra kell telepíteni. A &os; az összes adatát, beleértve minden általunk létrehozott állományt is, ezen az egyetlen partíción fogja elhelyezni. Ha viszont több lemezünk van, többen is, vagy akár mindegyiken létrehozhatunk &os;-s partíciókat. A &os; telepítésekor azonban legalább egy ilyen partíciónak használhatónak kell lennie. Ez lehet elõre megtisztított üres partíciói is, vagy akár egy olyan partíció, amelyen már nem használt adatok vannak. Ha már mindegyik partíciónk betelt, akkor a többi operációs rendszer által felkínált eszközök (például &ms-dos;-ban vagy &windows;-ban az fdisk) valamelyikével elõször fel kell közülük szabadítanunk egyet a &os; számára. Amennyiben akadna egy használható partíció, akkor használjuk azt. Ekkor azonban elõfordulhat, hogy ehhez elõször a meglévõk közül össze kell majd zsugorítanunk valamelyiket. A &os; legkisebb telepíthetõ változata nagyjából 100 MB lemezterületet igényel. Azonban ez egy nagyon kicsi változat és szinte semmi helyet nem hagy a saját állományainknak. Sokkal valósághûbb, ha grafikus felület nélkül nagyjából 250 MB-ot mondunk, és legalább 350 MB-ot a grafikus felület használata esetén. Ha ezeken felül további szoftvereket is telepíteni kívánunk, még több helyre lesz szükségünk. Amikor a &os; számára akarunk helyet csinálni, vagy partíciókat akarunk átméretezni, használjuk például a &partitionmagic; nevû kereskedelmi szoftvert, vagy esetleg egy olyan szabad szoftvert, mint például a GParted. Ismereteink szerint a &partitionmagic; és a GParted is használható az NTFS partíciókkal. A GParted számos live linuxos disztribúción megtalálható, ilyen többek közt a SystemRescueCD. Gondok lehetnek azonban a µsoft; Vista által használt partíciókkal. Ezért nem árt, ha az átméretezésekor a kezünk ügyében van a Vista telepítõ CD-je. Természetesen, mint minden lemezkarbantási mûvelet esetén, ilyenkor is határozottan ajánlott biztonsági mentéseket készíteni. Az említett eszközök helytelen használata megsemmisítheti a lemezeinken tárolt adatokat, ezért a használatuk elõtt gondoskodjunk friss, mûködõképes biztonsági mentésekrõl. Meglevõ partíció használata a méret megváltoztatása nélkül Tegyük fel, hogy a számítógépünkben egyetlen 4 GB méretû lemez van, amelyen megtalálható a &windows; valamelyik verziója, és ezt a lemezt korábban két, egyaránt 2 GB méretû meghajtóra osztottuk, a C:-re és D:-re. 1 GB adatunk van a C: meghajtón és fél GB a D:-n. Mindez tehát azt jelenti, hogy a lemezünkön két partíció található, betûjelenként egy. Ha átmásoljuk a D: meghajtón levõ adatainkat a C: meghajtóra, akkor ezzel felszabadíthatjuk a &os; számára a második partíciót. Meglevõ partíció zsugorítása Tegyük fel, hogy a számítógépünkben egyetlen 4 GB méretû lemez van, amelyet teljes egészében a &windows; valamelyik példánya foglal el. A &windows; telepítése során ezért minden bizonnyal egyetlen nagy partíciót hoztunk létre, amely a C: betûjelet kapta és a mérete 4 GB. Jelen pillanatban másfél GB helyet használunk a lemezen, és szeretnénk a &os; számára 2 GB helyet felszabadítani. A &os; telepítéséhez a következõk valamelyikét kell tennünk: Mentsük le a &windows;-os adatainkat, telepítsük újra a &windows;-t úgy, hogy egy 2 GB méretû partíciót választunk neki a telepítése során. A partíció összezsugorítására használjuk az elõbb említett alkalmazásokat, például a &partitionmagic;-et. Szedjük össze a hálózati beállításainkat Amennyiben a &os; telepítésének részeként hálózatra is szándékozunk csatlakozni (például egy FTP vagy NFS szerverrõl akarunk telepíteni), ismernünk kell a hálózatra vonatkozó beállításainkat is. A telepítõ rá fog kérdezni ezekre az információkra, amelyek megadása után a &os; a telepítés befejezéséhez csatlakozni tud majd a hálózatra. Csatlakozás Ethernet-hálózaton, kábel- vagy DSL-modemen keresztül Ha egy Ethernet-hálózathoz, vagy magához az internethez csatlakozunk egy DSL- vagy kábelmodemen keresztül, akkor az alábbi adatokra lesz szükségünk: IP-cím Az alapértelmezett átjáró IP-címe A gépünk neve DNS (névfeloldó) szerverek IP-címei Hálózati maszk Ha nem ismerjük ezeket, érdeklõdjünk a rendszergazdától vagy a szolgáltatónktól. Elképzelhetõ az is, hogy mindezen információkat DHCP segítségével, automatikusan kapjuk meg. Ezt is mindenképpen jegyezzük fel. Kapcsolódás modemmel Ha az internet-szolgáltatónkhoz hagyományos modemen keresztül csatlakozunk, akkor is tudjuk telepíteni a &os;-t interneten keresztül, azonban ez nagyon sokáig tarthat. Ehhez tudnunk kell: Az internet-szolgáltatónk behívószámát A soros (COM) port számát, amelyen keresztül a modem kapcsolódik a gépünkhöz Az internet-szolgáltatónktól kapott felhasználói nevet és jelszót Olvassuk el &os; hibajegyzékét Habár a &os; Projekt igyekszik a &os; minden egyes kiadását a lehetõ legmegbízhatóbban felkészíteni, hibák óhatatlanul is maradnak bennük. Nagyon ritka esetekben ezek a hibák magára a telepítés folyamatára is kihathatnak. Amint ezeket a problémákat sikerül felderíteni és javítani, rögvest megjelennek a &os; honlapján található hibajegyzékben (angolul). A telepítés elõtt ezért mindig ajánlott átolvasni ezt a dokumentumot, így megbizonyosodunk róla, hogy semmilyen utólag felmerült probléma nem akadályozza munkánkat. Az összes kiadáshoz tartozó információ, beleértve az egyes kiadások hibajegyzékeit is, a &os; honlapjáról a kiadásokra vonatkozó információkat tartalmazó részen érhetõ el (angolul). Szerezzük be a &os; telepítéséhez szükséges állományokat A &os; telepítése az alábbi helyek bármelyikén megtalálható állományok felhasználásával történik: Lokálisan: CD vagy DVD Ugyanazon a számítógépen levõ &ms-dos; partíció Pendrive (USB-flash-tároló) SCSI- vagy QIC-szalag Floppylemezek Hálózaton keresztül: FTP oldalról, tûzfalon keresztül vagy szükség szerint HTTP proxy használatával NFS szerverrõl Párhuzamos vagy soros vonali kapcsolaton keresztül Ha megvásároltuk a &os; telepítõ CD-jét vagy DVD-jét, akkor már mindennel rendelkezünk a telepítéshez. Lépjünk bátran tovább a következõ szakaszra ()! Ha eddig még nem szereztük volna be a &os; telepítéséhez szükséges állományokat, ugorjunk a hoz, ahol megtudhatjuk, hogyan készítsük elõ a &os; telepítését az imént felsorolt helyzetekben. A szakasz elolvasása után pedig jöjjünk vissza ide, majd folytassuk az olvasást a ban. Készítsünk egy rendszerindító lemezt A &os; telepítése úgy kezdõdik, hogy a számítógépünkkel a &os; telepítõjét indítjuk el — ez viszont nem egy olyan program, amit más operációs rendszerben el tudunk indítani. A számítógépünk általában a merevlemezünkre telepített operációs rendszert indítja el, azonban beállítható úgy is, hogy az indulásához egy ún. rendszerindító (bootolható) floppy lemezt használjon. Napjaink számítógépei azonban a CD-meghajtóban levõ CD-krõl vagy USB lemezrõl is el tudnak indulni. Ha CD-n vagy DVD-n megvan a &os; telepítõje (akár megvettük, akár éppen magunk készítettük) és a számítógépünk tud CD-rõl vagy DVD-rõl rendszert indítani (a BIOS-ban van egy Boot Order vagy hozzá hasonló nevû beállítás), akkor kihagyhatjuk ezt a szakaszt. A &os; CD- és DVD image-ek kiírásával egy rendszerindításra alkalmas lemezt kapunk, amirõl minden további elõkészület nélkül telepíthetünk. Rendszerindításra alkalmas pendrive-ot az alábbi lépések mentén tudunk készíteni: Az image állomány letöltése A pendrive-okhoz készült image állományok a ISO-IMAGES/ könyvtárból tölthetõek le, ftp://ftp.FreeBSD.org/pub/FreeBSD/releases/architektúra/ISO-IMAGES/verzió/&os;-&rel.current;-RELEASE-architektúra-memstick.img néven. Az architektúra és verzió helyére a telepítendõ architektúrát és verziószámot helyettesítsük be. Ennek megfelelõen tehát például a &os;/&arch.i386; &rel.current;-RELEASE változata a címrõl érhetõ el. A pendrive image .img kiterjesztéssel rendelkezik. A ISO-IMAGES/ könyvtár általában több különféle állományt tartalmaz, ezek közül kell választanunk a &os; telepítendõ változatának, és sok esetben a telepítéshez rendelkezésre álló hardver típusának megfelelõen. A következõ lépés megkezdése elõtt készítsünk biztonsági mentést a pendrive tartalmáról, mivel minden rajta levõ adat törlõdni fog. A pendrive elõkészítése Az itt található példában a rendszerindításhoz és így a mûvelet végrehajtásához a /dev/da0 nevû eszközt fogjuk használni. Ezt ne felejtsük el helyettesíteni a rendszerünkön erre a célra használt eszköz nevével, máskülönben kárt tehetünk az adatainkban. A kern.geom.debugflags változó értékének megfelelõ beállításával engedélyezzük a céleszközön a Master Boot Record írását. &prompt.root; sysctl kern.geom.debugflags=16 Az image pendrive-ra írása Az .img kiterjesztésû állományt nem egyszerûen a pendrive-ra kell másolni, ez a lemez teljes tartalmát magában foglalja. Ennek megfelelõen nem egyszerûen állományokat kell másolnunk az egyik lemezrõl a másikra. Helyette a &man.dd.1; parancs segítségével írjuk az image állomány tartalmát közvetlenül a lemezre. &prompt.root; dd if=&os;-&rel.current;-RELEASE-&arch.i386;-memstick.img of=/dev/da0 bs=64k Rendszerindításra alkalmas floppy lemezt az alábbi lépések mentén tudunk készíteni: A rendszerindító lemezek image-einek beszerzése A &os; 8.0 kiadásától kezdõdõen megszûnik a floppy lemezek támogatása. Helyette telepítsünk pendrive-ról, amelyrõl fentebb olvashatunk, vagy egyszerûen használjunk CD-t vagy DVD-t. A rendszerindító lemezek a telepítõeszköz floppies/ könyvtárában találhatóak, illetve letölthetõek az ftp://ftp.FreeBSD.org/pub/FreeBSD/releases/architektúra/változat-RELEASE/floppies/ helyrõl. Az architektúra és változat helyére természtesen írjuk be a telepíteni kívánt architektúrát és verziót. Így például a &os;/&arch.i386; &rel.current;-RELEASE rendszerindító lemezei az címrõl érhetõek el. A floppyk image-ei .flp kiterjesztésûek. A floppies/ könyvtár számos különféle image-et tartalmaz, ezek közül leginkább a telepítendõ &os; változat, valamint emellett olykor konkrétan a hardver határozza meg a használandót. Az esetek túlnyomó részében négy floppyra lesz szükségünk: boot.flp, kern1.flp, kern2.flp és kern3.flp. A lemezek image-eit illetõ legfrissebb információkat ugyanazon a könyvtáron belül szereplõ README.TXT állományban olvashatjuk (angolul). Az FTP-hez használt programunkat az image-ek letöltése során ne felejtsük el bináris (binary) átviteli módban használni. Egyes böngészõk hajlamosak ugyanis szöveges (text vagy ASCII) átviteli módot használni, ami viszont csak abból vehetõ észre, hogy nem tudjuk a lemezekrõl elindítani a rendszert. A floppyk elõkészítése Mindegyik letöltendõ image-hez elõ kell készíteni egy-egy hajlékonylemezt. Nagyon fontos, hogy ezek a lemezek teljesen hibátlanok legyenek. Errõl a legkönnyebben úgy gyõzõdhetünk meg, ha a lemezeket magunk formázzuk, és nem bízunk a különféle elõreformázott (preformatted) floppykban. A &windows;-ban található formázó segédprogram sem árul el nekünk semmit a lemezeken található hibás részekrõl, egyszerûen csak rossznak (bad) jelöli meg és figyelmen kívül hagyja ezeket. Határozottan ajánljuk, hogy amennyiben a telepítésnek ezt a módját választjuk, mindig használjunk teljesen új floppykat. Ha megpróbáljuk telepíteni a &os;-t, és a telepítõprogram összeomlik, lefagy vagy bármilyen furcsaságot mûvel, elsõként mindenképpen a floppykra gyanakodhatunk. Ilyenkor írjuk ki az image-eket új lemezekre és próbálkozzunk újra a telepítéssel. Az image állományok írása a floppykra Az .flp kiterjesztésû állományok nem a lemezre másolható hagyományos állományok, hanem a lemezek teljes tartalmának képei, ezért ezeket egyszerûen nem másolhatjuk egyik lemezrõl a másikra. Az image-ek közvetlen lemezreírásához ehelyett kifejezetten erre a célra alkalmas eszközöket kell használnunk. DOS Azok számára, akik a floppykat &ms-dos;/&windows; rendszerû számítógépeken kívánják elkészíteni, mellékeltünk egy fdimage nevû segédprogramot. Ha a CD-meghajtónk betûjele például E: és a telepítõ CD-n található image-eket szeretnénk kiírni vele, akkor ezt a parancsot kell kiadnunk: E:\> tools\fdimage floppies\boot.flp A: Ezután ismételten adjuk ki az iménti parancsot minden egyes használni kívánt .flp állományra, azonban elõtte mindig tegyünk be egy újabb floppyt, és a ráírt image-ek neveivel folyamatosan címkézzük fel a lemezeket. A megadott parancsot természetesen mindig írjuk át a konkrét .flp állományok tényleges elérési útvonalainak megfelelõen. Ha nincs CD-nk, akkor az fdimage programot az &os; FTP oldalán található tools könyvtárból is letölthetjük. Amikor a lemezeket egy &unix; rendszeren készítenénk el (például egy másik &os; rendszeren), akkor a &man.dd.1; parancs is használható az image állományok közvetlen lemezreírásához. &os; alatt így néz ki a paraméterezése: &prompt.root; dd if=boot.flp of=/dev/fd0 &os;-n a /dev/fd0 az elsõ hajlékonylemezes meghajtóra hivatkozik (tehát az A: betûjelû meghajtóra). Ennek megfelelõen a /dev/fd1 jelenti a B: meghajtót és így tovább. Más &unix; változatok esetleg más neveket használhatnak a hajlékonylemezes meghajtók megnevezésére, ezért errõl érdemes ilyenkor tájékozódni az adott rendszerhez tartozó dokumentációban. Most már készen állunk a &os; telepítésére! A telepítés megkezdése Alapértelmezés szerint a telepítés egészen addig nem fog semmit sem írni a lemezekre, amíg a következõ üzenet fel nem bukkan: Last Chance: Are you SURE you want continue the installation? If you're running this on a disk with data you wish to save then WE STRONGLY ENCOURAGE YOU TO MAKE PROPER BACKUPS before proceeding! We can take no responsibility for lost disk contents! A szöveg fordítása: Utolsó esély: BIZTOSAN folytatni kívánja a telepítést? Ha olyan lemezre szeretne telepíteni, amelyen fontos adatok találhatóak, HATÁROZOTTAN JAVASOLJUK, hogy a továbblépés elõtt KÉSZÍTSEN RÓLUK MEGBÍZHATÓ BIZTONSÁGI MÁSOLATOT! Nem vállalunk semmilyen felelõsséget az elveszett adatokért! A telepítõbõl tehát a fenti, végsõ figyelmeztetés elõtt bármikor ki lehet lépni anélkül, hogy a merevlemezünkön levõ adatokat veszélyeztetnénk. Ha úgy érezzük, hogy valamit véletlenül rosszul állítottunk volna be a telepítés során, ekkor még minden komolyabb kár okozása nélkül kikapcsolhatjuk a számítógépünket. A rendszer indítása Rendszerindítás &i386;-on Kezdjünk egy kikapcsolt számítógéppel. Kapcsoljuk be a számítógépet. Az indulása során látnunk kell egy olyan opciót, amivel be tudunk lépni a rendszer beállításait tartalmazó menübe, avagy a BIOS-ba. Ezt többnyire a F2, F10, Del vagy a AltS lenyomásával érhetjük el. Ezek közül használjuk a képernyõn megjelenõ billentyûket. Elõfordulhat, hogy induláskor a számítógépünk semmilyen szöveget, csak egy képet mutat. Ilyenkor általában a Esc billentyû megnyomására eltûnik a kép és láthatóvá válnak a számunkra fontos üzenetek. Miután beléptünk a menübe, keressük meg azt a beállítást, amely a rendszerindításhoz használt eszközt határozza meg. Ennek a neve sokszor Boot Order (rendszerindítási sorrend) vagy valami hozzá hasonló. Itt mindenféle eszköz felsorolását találjuk: Floppy, CDROM, First Hard Disk (elsõ merevlemezes meghajtó) és így tovább. Ha CD-rõl akarjuk a telepítést elindítani, akkor akkor a CDROM eszközt válasszuk. Ha bármilyen kétség merülne fel bennünk, keressük meg ezt a beállítást a számítógéphez és/vagy az alaplaphoz kapott kézikönyvben. Igényeink szerint végezzük el a beállítást, majd mentsük el és lépjünk ki. Most indítsuk újra a számítógépet. Ha a ban leírtak szerint rendszerindító pendrive-ot készítettünk, akkor bekapcsolás elõtt csatlakoztassuk a számítógéphez. Ha CD-rõl indítjuk a telepítést, akkor kapcsoljuk be a számítógépet és az elindulása után igyekezzünk minél hamarabb betenni a lemezt a meghajtóba. A &os; 7.3 és az azt megelõzõ változatokban a ban leírtak szerint elõkészített floppy-ról is el tudjuk kezdeni a telepítést. Ezek egyike lesz az elsõ rendszerindító lemez, a boot.flp. Helyezzük ezt a lemezt a meghajtóba, és indítsuk el vele a számítógépet. Ha minden próbálkozásunk ellenére a számítógépünk a megszokott módon indul és a meglevõ operációs rendszert tölti be, akkor a következõkkel lehet a gond: A lemezeket nem raktuk be eléggé korán. Hagyjuk benn ezeket és próbáljuk meg ismét újraindítani a számítógépet. Nem állítottuk be jól a BIOS-t. Próbáljuk meg egészen addig újra végrehajtani az elõzõ lépést, amíg a megfelelõ beállítást el nem találjuk. A BIOS nem támogatja a kiválasztott eszközrõl történõ rendszerindítást. A &os; megkezdi az indulását. Ha CD-rõl indítjuk, akkor valami ehhez hasonlót fogunk látni (a konkrét verzióra vonatkozó adatokat itt most kihagytuk): Booting from CD-Rom... 645MB medium detected CD Loader 1.2 Building the boot loader arguments Looking up /BOOT/LOADER... Found Relocating the loader and the BTX Starting the BTX loader BTX loader 1.00 BTX version is 1.02 Console: internal video/keyboard BIOS CD is cd0 BIOS drive C: is disk0 BIOS drive D: is disk1 BIOS 639kB/261056kB available memory FreeBSD/i386 bootstrap loader, Revision 1.1 Loading /boot/defaults/loader.conf /boot/kernel/kernel text=0x64daa0 data=0xa4e80+0xa9e40 syms=[0x4+0x6cac0+0x4+0x88e9d] \ Amikor floppyról indítjuk a rendszert, ehhez hasonlóval találkozhatunk (itt sem szerepelnek most verzióadatok): Booting from Floppy... Uncompressing ... done BTX loader 1.00 BTX version is 1.01 Console: internal video/keyboard BIOS drive A: is disk0 BIOS drive C: is disk1 BIOS 639kB/261120kB available memory FreeBSD/i386 bootstrap loader, Revision 1.1 Loading /boot/defaults/loader.conf /kernel text=0x277391 data=0x3268c+0x332a8 | Insert disk labelled "Kernel floppy 1" and press any key... Kövessük a képernyõn megjelenõ utasítást (Helyezze be a "Kernel floppy 1" címkéjû lemezt és nyomjon meg egy billentyût...), tehát vegyük ki a boot.flp image-hez tartozó lemezt és tegyük be helyette a kern1.flp image-hez tartozó lemezt, majd nyomjuk le az Enter billentyût. Várjuk meg amíg a rendszer megkezdi az indulást az elsõ lemezrõl, majd az utasításoknak megfelelõen folyamatosan tegyük be a soron következõ lemezeket. Miután elindítottuk a rendszert CD-rõl, pendrive-ról vagy floppy-ról, a rendszerindítási folyamat be fogja hozni a &os; rendszertöltõjének menüjét:
&os; rendszerbetöltõ menüje
Várjuk ki a tíz másodperces szünetet vagy egybõl nyomjuk le az Enter billentyût. Rendszerindítás &sparc64;-en A legtöbb &sparc64; alapú rendszert úgy állították be, hogy automatikusan lemezrõl induljon. A &os; telepítéséhez azonban hálózaton keresztül vagy CD-rõl kell indítanunk a rendszert, ezért módosítanunk kell a PROM (az OpenFirmware) beállításait. Mindehhez indítsuk újra a rendszert és várjuk meg, amíg feltûnik a rendszerindító üzenet. A konkrét üzenet nagyban függ a számítógép típusától, azonban valami ilyesmi lesz: Sun Blade 100 (UltraSPARC-IIe), Keyboard Present Copyright 1998-2001 Sun Microsystems, Inc. All rights reserved. OpenBoot 4.2, 128 MB memory installed, Serial #51090132. Ethernet address 0:3:ba:b:92:d4, Host ID: 830b92d4. Amikor megpróbálja a rendszert elindítani a lemezrõl, a PROM parancssorának bekéréshez nyomjuk le a billentyûzeten az L1 A vagy a StopA billentyûket, esetleg a soros konzolon keresztül küldjünk egy BREAK parancsot (például a &man.tip.1; vagy &man.cu.1; man oldalakon szereplõ ~# parancs használatával). Körülbelül így néz ki: ok ok {0} Ez a fajta parancssor csak az egy processzorral rendelkezõ rendszereken jelenik meg. Ez a fajta parancssor többprocesszoros (SMP) rendszereken jelenik meg, ahol a szám az éppen aktív processzor sorszámát jelöli. Most helyezzük a CD-t a meghajtóba, és a PROM parancssorában pedig gépeljük be boot cdrom parancsot. Az eszközkeresés eredményeinek vizsgálata A képernyõn megjelenõ utolsó pár száz sor mindig eltárolódik, késõbb tetszõlegesen átvizsgálhatóak. A puffer tartalmának átnézéséhez nyomjuk le a Scroll Lock billentyût, amivel bekapcsoljuk a korábban megjelent üzenetek közti visszalépést. Itt a nyílbillentyûk, vagy a PageUp és PageDown billentyûk használhatóak a kiírások átböngészéséhez. A Scroll Lock ismételt lenyomásával kiléphetünk ebbõl a módból. Tegyük most mi is ezt, és nézzük az összes olyan üzenetet, amely a rendszermag indulása során keletkezett. A ban látható szövegekhez hasonlóakat fogunk találni, habár ez a számítógépben található konkrét eszközöktõl függõen eltérõ lehet.
Példa az eszközkeresés eredményeire avail memory = 253050880 (247120K bytes) Preloaded elf kernel "kernel" at 0xc0817000. Preloaded mfs_root "/mfsroot" at 0xc0817084. md0: Preloaded image </mfsroot> 4423680 bytes at 0xc03ddcd4 md1: Malloc disk Using $PIR table, 4 entries at 0xc00fde60 npx0: <math processor> on motherboard npx0: INT 16 interface pcib0: <Host to PCI bridge> on motherboard pci0: <PCI bus> on pcib0 pcib1:<VIA 82C598MVP (Apollo MVP3) PCI-PCI (AGP) bridge> at device 1.0 on pci0 pci1: <PCI bus> on pcib1 pci1: <Matrox MGA G200 AGP graphics accelerator> at 0.0 irq 11 isab0: <VIA 82C586 PCI-ISA bridge> at device 7.0 on pci0 isa0: <iSA bus> on isab0 atapci0: <VIA 82C586 ATA33 controller> port 0xe000-0xe00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0 <VIA 83C572 USB controller> port 0xe400-0xe41f irq 10 at device 7.2 on pci 0 usb0: <VIA 83572 USB controller> on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr1 uhub0: 2 ports with 2 removable, self powered pci0: <unknown card> (vendor=0x1106, dev=0x3040) at 7.3 dc0: <ADMtek AN985 10/100BaseTX> port 0xe800-0xe8ff mem 0xdb000000-0xeb0003ff ir q 11 at device 8.0 on pci0 dc0: Ethernet address: 00:04:5a:74:6b:b5 miibus0: <MII bus> on dc0 ukphy0: <Generic IEEE 802.3u media interface> on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ed0: <NE2000 PCI Ethernet (RealTek 8029)> port 0xec00-0xec1f irq 9 at device 10. 0 on pci0 ed0 address 52:54:05:de:73:1b, type NE2000 (16 bit) isa0: too many dependant configs (8) isa0: unexpected small tag 14 orm0: <Option ROM> at iomem 0xc0000-0xc7fff on isa0 fdc0: <NEC 72065B or clone> at port 0x3f0-0x3f5,0x3f7 irq 6 drq2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5” drive> on fdc0 drive 0 atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0 atkbd0: <AT Keyboard> flags 0x1 irq1 on atkbdc0 kbd0 at atkbd0 psm0: <PS/2 Mouse> irq 12 on atkbdc0 psm0: model Generic PS/@ mouse, device ID 0 vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 sc0: <System console> at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A ppc0: <Parallel port> at port 0x378-0x37f irq 7 on isa0 pppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/15 bytes threshold plip0: <PLIP network interface> on ppbus0 ad0: 8063MB <IBM-DHEA-38451> [16383/16/63] at ata0-master UDMA33 acd0: CD-RW <LITE-ON LTR-1210B> at ata1-slave PIO4 Mounting root from ufs:/dev/md0c /stand/sysinstall running as init on vty0
Figyelmesen olvassuk át az üzeneteket, és bizonyosodjuk meg róla, hogy a &os; minden számunkra fontos eszközt felismert. Ha nem látunk egy eszközt, akkor azt valószínûleg nem találta meg. Egy saját rendszermag létrehozásával azonban fel tudunk ismertetni olyan eszközöket is, amelyek támogatása eredetileg nem szerepel a GENERIC rendszermagban. Ilyenek például a hangkártyák. A &os; 6.2 vagy késõbbi változataiban az eszközök felkutatása után a ban láthatóak következnek. Itt a nyílbillentyûk segítségével választhatjuk ki az országot (country), térséget (region) vagy csoportot (group). Az Enter lenyomása után pillanatok alatt beállítódik az országunk. Ha meg akarjuk ismételni az iménti beállítást, pillanatok alatt ki tudunk lépni a sysinstall programból.
Az ország kiválasztása
Ha országként United States (Egyesült Államok) került beállításra, akkor a szabványos amerikai billentyûzet-kiosztás állítódik be. A többi ország esetében az alábbi menü jelenik meg. A kurzormozgató billentyûk segítségével ekkor keressük meg ki a számunkra megfelelõ kiosztást, és az Enter billentyû lenyomásával válasszuk ki.
A billentyûzet típusának kiválasztása
Kilépés a <application>sysinstall</application> programból
A telepítõprogram fõképernyõjén válasszuk ki a nyílbillentyûkkel az Exit Install (Kilépés a telepítésbõl) menüpontot. Erre a következõ üzenet fog megjelenni: User Confirmation Requested Are you sure you wish to exit? The system will reboot [ Yes ] No Az üzenet fordítása: Felhasználói megerõsítés szükséges Valóban ki akar lépni? A rendszer ezt követõen újra fog indulni [ Igen ] Nem Ha a &gui.yes; választ adjuk és a CD-t az újraindításkor is a meghajtóban hagyjuk, akkor a telepítõprogram még egyszer el fog indulni. Ha floppyról indítottuk volna a rendszert, az újraindítás elõtt vegyük ki a boot.flp image-et tartalmazó lemezt. A <application>sysinstall</application> bemutatása A sysinstall a &os; Projekt által fejlesztett telepítõprogram. Konzol alapú, menükre és képernyõkre oszlik, amelyeken a beállításokat és a telepítési folyamat irányítását tudjuk elvégezni. A sysinstall menürendszerét több más billentyû mellett legfõképpen a nyílbillentyûkkel, az Enter, Tab és a Szóköz billentyûkkel kezelhetjük. Ezek és az általuk elvégezhetõ feladatok részletes leírása a sysinstall használatáról szóló információk között található. Ennek megtekintéséhez elõször gyõzõdjünk meg róla, hogy a által illusztrált helyzetnek megfelelõen kiválasztottuk a Usage (Használat) menüpontot és a [Select] (Kiválaszt) feliratú gombon állunk, majd nyomjuk le az Enter billentyût. Ezt követõen megjelenik a menürendszer használatát bemutató leírás. Miután végigolvastuk, a fõmenübe az Enter billentyû lenyomásával tudunk visszajutni.
A <quote>Usage</quote> kiválasztása a <application>sysinstall</application> fõmenüjében
A dokumentációs menü kiválasztása A fõmenüben a nyílbillentyûkkel válasszuk a Doc feliratú menüpontot és nyomjuk meg az Enter billentyût.
A dokumentációs menü kiválasztása
Ezzel megjelenik a dokumentációs menü.
A <application>sysinstall</application> dokumentációs menüje
Feltétlenül olvassuk el az itt található leírásokat. A dokumentumok elolvasásához elõször válasszunk közülük a nyílbillentyûkkel, majd nyomjuk meg az Enter billentyût. A dokumentum elolvasása után az Enter lenyomásával tudunk visszatérni a dokumentációs menübe. A dokumentációs menübõl a fõmenübe úgy tudunk kilépni, ha a nyílbillentyûkkel kiválasztjuk az Exit (Kilépés) menüpontot és megnyomjuk az Enter billentyût. A billentyûkiosztás menüjének kiválasztása A billentyûzetkiosztás megváltoztatásához válasszuk ki a nyílbillentyûk segítségével a Keymap menüpontot a menübõl és nyomjuk meg az Enter billentyût. Erre természetesen csak akkor lesz szükségünk, ha nem szabványos vagy nem angol billentyûzetet használunk.
A <application>sysinstall</application> fõmenüje
A különbözõ billentyûkiosztásoknak megfelelõ menüpontok a fel/le nyílak és a Szóköz billentyû segítségével választhatóak ki. A Szóköz ismételt lenyomásával töröljük a választásunkat. A befejezéshez válasszuk ki a nyilakkal a &gui.ok; gombot és nyomjuk le az Enter billentyût. A mellékelt képen a lista egy része látható csupán. Ha a Tab billentyûvel a &gui.cancel; gombot választjuk, akkor az alapértelmezett billentyûkiosztást kapjuk és visszakerülünk a fõmenübe.
A <application>sysinstall</application> billentyûkiosztást beállító menüje
A telepítés beállításai tartalmazó képernyõ Válasszuk az Options (Beállítások) menüpontot, majd nyomjuk le az Enter billentyût.
A <application>sysinstall</application> fõmenüje
A <application>sysinstall</application> beállításai
Az itt szereplõ alapértelmezett értékek a legtöbb felhasználó számára minden további nélkül megfelelnek, nem szükséges a megváltoztatásuk. A kiadás neve (release name) mezõ értéke a telepítendõ verziótól függõen változhat. A kiválasztott mezõ rövid leírása a képernyõ alján, kékkel kiemelten jelenik meg. A Use Defaults (Az alapértelmezések használata) beállítás az alapértelmezésére állítja vissza az összes értéket. Az F1 lenyomásával elolvashatjuk a különbözõ beállításokhoz tartozó súgót. A Q billentyûvel visszatérhetünk a fõmenübe. Egy szabványos telepítés megkezdése A Standard (Szabványos) elnevezésû menüpont által felkínált telepítési módszer ajánlott a &unix;-szal vagy a &os;-vel most ismerkedõk számára. A telepítés megkezdéséhez a nyilakkal válasszuk ki a Standard menüpontot, majd nyomjuk meg az Enter billentyût.
Egy szabványos telepítés megkezdése
Lemezterület lefoglalása Elsõ feladatunk lemezterületet foglalni a &os; számára, majd megcímkézni azt, hogy a sysinstall elõ tudja készíteni. Ehhez tisztában kell lennünk azzal, hogy a &os; milyen formában is keresi az adatokat a lemezünkön. A BIOS meghajtószámozása Egy témára különösen tekintettel kell lennünk mielõtt telepítenénk és beállítanánk a &os;-t a rendszerünkön, fõleg abban az esetben, ha több merevlemezünk is van. DOS Microsoft Windows Egy BIOS-függõ operációs rendszert, például &ms-dos;-t vagy &windows;-t futattó PC esetén a BIOS az operációs rendszer beleegyezésével képes elvonatkoztatni a lemezek megszokott sorrendjétõl. Ennek köszönhetõen a felhasználó nem csak az ún. primary master (elsõdleges master) merevlemezes meghajtótól tudja elindítani a rendszert. Ez kifejezetten kényelmes megoldás az olyan felhasználók számára, akik az elsõvel teljesen megegyezõ második merevlemez megvásárlásával kialakították a rendszerük egyszerû és egyben a legolcsóbb biztonsági mentését, amire a Ghost vagy XCOPY programokkal tudnak rendszeres másolatokat készíteni. Így, ha az elsõdleges meghajtó tönkremegy vagy vírus támadja meg, esetleg az operációs rendszer egy hiba miatt használhatatlanná teszi, akkor a BIOS-t utasíthatjuk a meghajtók logikai cseréjére és ezzel könnyen helyre tudjuk állítani. Olyan, mintha a ház felnyitása nélkül felcseréltük volna a lemezeket bekötõ kábeleket. SCSI BIOS A SCSI-vezérlõkkel szerelt drágább rendszerek gyakran tartalmaznak olyan BIOS-bõvítéseket, amelyeken keresztül a SCSI-lemezek ugyanígy tetszõlegesen átrendezhetõek, egészen hét meghajtóig. Az ilyen lehetõségek használatához szokott felhasználókat azonban könnyen csalódás érheti, amikor a &os; nem az elvárásaiknak megfelelõen cselekszik. A &os; ugyanis nem használja a BIOS-t és nem ismeri a BIOS logikai meghajtókiosztását. Ez meghökkentõ eredményekre vezethet, fõleg akkor, amikor paramétereiket tekintve a meghajtók fizikailag teljesen megegyeznek és ráadásul egymás másolatait tartalmazzák. A &os; telepítése elõtt mindig állítsuk vissza a BIOS-ban a meghajtók eredeti sorrendjét, és a használatához hagyjuk is így ezt a beállítást. Ha valamiért mégis meg kellene cserélnünk a meghajtókat, akkor ezentúl válasszuk a nehezebb utat: nyissuk ki a gépházat és kössük át a kábeleket, tegyük át a jumpereket mi magunk. Részlet Frédi és Vili különleges kalandjaiból: Vili fogott egy öreg Winteles számítógépet, hogy készítsen belõle egy &os;-s rendszert Frédinek. Vili ehhez beszerel egy SCSI-meghajtót, ami így nullás SCSI-egység lesz, majd telepíti rá a &os;-t. Frédi nekilát használni a rendszert, azonban pár nap elteltével tapasztalja, hogy az öregecske SCSI-meghajtó számos apróbb hibát jelez, és ezért szól Vilinek. Néhány nappal késõbb Vili eldönti, ideje pontot tenni az ügy végére, ezért a raktárban levõ SCSI-lemezek köztül elhoz az eredetivel egy teljesen megegyezõt. Az elõzetes felületellenõrzés eredményei szerint a meghajtó tökéletesen mûködik, ezért Vili beszerelni ezt a meghajtót a négyes SCSI-egységként, majd lemásolja a nullás meghajtó tartalmát a négyesre. Miután beszerelte a tökéletesen üzemelõ új meghajtót, Vili úgy határoz, ideje megkezdeni a használatát, ezért beállítja a SCSI BIOS-át, hogy a rendszer a nullás helyett ezentúl a négyes egységrõl induljon. A &os; elindul és mindenki örül. Frédi ezután folytatja megszokott munkáját, majd Vili és Frédi úgy gondolják, itt az ideje az újabb izgalmaknak — frissítsünk a &os; egy újabb változatára. Vili ekkor eltávolítja a nullás SCSI-egységet, mivel már egyébként is kezdett tönkremenni, és kicseréli egy másik teljesen azonos lemezes meghajtóra. Vili ezt követõen Frédi internetrõl letöltött varázslatos floppyjainak segítségével feltelepíti a &os; új verzióját az új nullás SCSI-egységre. A telepítés minden gond nélkül lezajlik. Frédi próbálgatja is a &os; új változatát néhány napig, és számára ez elegendõ bizonyíték ahhoz, hogy a munkahelyén is használja. Ideje hát átmásolni a régi munkáit, ezért Frédi csatlakoztatja a (korábbi &os; változat legfrissebb változatát tartalmazó) négyes SCSI-egységet. Frédin azonban hirtelen aggodalom tör ki, hiszen a négyes SCSI-egységen sehol sem találja munkája féltett eredményeit. Hova tûntek azok a komisz adatok? Amikor Vili másolatot készített az eredeti nullás SCSI-egységrõl a négyes SCSI-egységre, a négyes egység egy új klón lett. Amikor a rendszerindításhoz Vili átrendezte a meghajtókat a SCSI BIOS-ban, azzal csak magát csapta be, ugyanis a &os; továbbra is a nullás SCSI-egységrõl indult el! A BIOS által kiválasztott meghajtóról az effajta beállítások hatására ugyan behozható a rendszerindító és -betöltõ programok egy része, de amikor a &os; rendszermagja átveszi a vezérlést, a BIOS által meghatározott sorrendiség figyelmen kívül marad és a &os; visszatér a meghajtók eredeti rendezéséhez. Tehát ebben az esetben a rendszer továbbra is az eredeti nullás SCSI-egységrõl folytatja a mûködést, és Frédi összes adata itt található, nem pedig a négyes SCSI-egységen. A négyes SCSI-egységrõl futó rendszer illuziója így mindössze az emberi elvárások szüleménye. Örömmel említjük meg, hogy egyetlen byte-nyi adat sem sérült meg vagy pusztult el a jelenség felfedezése során. A korábbi nullás SCSI-egységet még sikerült megmenteni a szemétdombról és Frédi összes munkája visszakerült (és Vili most már el tud számolni nulláig). Habár a tanmesénkben SCSI-meghajtókról esett szó, ugyanez fennáll az IDE-meghajtókra is. Slice-ok létrehozása az FDisk használatával Itt még semmilyen változtatás nem kerül lemezre. Ha úgy érezzük, hogy valamit rosszul csináltunk és újra el akarjuk kezdeni a telepítést, a menük segítségével büntetlenül távozhatunk a sysinstallból és újra próbálkozhatunk, vagy az U billentyû lenyomásával aktiválhatjuk az Undo (Visszacsinál) funkciót. Ha véletlenül összezavarodtunk volna és nem találunk kilépési lehetõséget, akkor bármikor ki tudjuk kapcsolni a számítógépet. A sysinstallban a szabványos telepítés megkezdésekor az alábbi üzenet jelenik meg: Message In the next menu, you will need to set up a DOS-style ("fdisk") partitioning scheme for your hard disk. If you simply wish to devote all disk space to FreeBSD (overwriting anything else that might be on the disk(s) selected) then use the (A)ll command to select the default partitioning scheme followed by a (Q)uit. If you wish to allocate only free space to FreeBSD, move to a partition marked "unused" and use the (C)reate command. [ OK ] [ Press enter or space ] Az üzenet fordítása: Üzenet A most következõ menüben össze kell állítanunk a merevlemezünk DOS-szerû ("fdiskes") partícióit. Amennyiben egyszerûen csak át akarjuk adni az összes lemezterületet a FreeBSD számára (ezzel felülírva mindent, ami a kiválasztott lemezeken található), akkor az alapértelmezett partíció-kiosztás kiválasztásához használjuk az (A)ll (Mind), majd utána a (Q)uit (Kilépés) parancsokat. Ha viszont csak az éppen szabad területet szánjuk a FreeBSD-nek, lépjünk egy "unused" ("üres") feliratú partícióra és használjuk a (C)reate (Létrehozás) parancsot. [ OK ] [ Nyomja le az Enter vagy a Szóköz billentyût ] Az utasításnak megfelelõen nyomjuk le az Enter billentyût. Ezután a rendszermag által az eszközök felkutatása során megtalált összes merevlemezes meghajtót láthatjuk. A egy két IDE-lemezzel rendelkezõ rendszert mutat be, amelyeknek nevei rendre ad0 és ad2.
A meghajtó kiválasztása az FDisk számára
Feltûnhet, hogy itt nem szerepel az ad1. Vajon miért maradt ki? Képzeljük el, mi történne, ha két IDE-csatolós merevlemezünk lenne: az egyik az elsõ IDE-vezérlõn, a másik pedig a második IDE-vezérlõn lenne master. Ha a &os; a megtalálásuk szerint ad0 és ad1 nevekkel számozná ezeket, attól még minden remekül mûködhetne. Ha azonban beszerelnénk egy harmadik lemezt, például egy slave eszközt kapcsolnánk az elsõ IDE-vezérlõre, akkor már ez lenne a ad1, és ennek megfelelõen a korábban ad1 megnevezésû meghajtó pedig az ad2. Mivel az állományrendszerek felkutatására általában az eszközneveket (mint amilyen a ad1s1a) használják, ezért ilyenkor azt tapasztalhatnánk, hogy bizonyos állományrendszerek helytelenül jelennek meg, ezért meg kell változtatnunk a &os; ezeket érintõ beállításait. A probléma megoldására a rendszermag beállítható úgy, hogy az IDE-lemezeket a kapcsolódásuk szerint azonosítsa, ne pedig a megtalálásuk sorrendje szerint. Ezzel a kialakítással a második IDE-vezérlõn található master lemez mindig az ad2 eszköz lesz, tehát még olyankor is, amikor egyáltalán nincs a rendszerünkben ad0 vagy ad1 eszköz. Ez a beállítás alapértelmezés a &os; rendszermagjában, és ez magyarázza, hogy az iménti ábra miért csak ad0 és ad2 eszközöket mutat. Tehát a képen szereplõ számítógép mind a két IDE-vezérlõjének master csatornáján található egy-egy IDE-lemez, a slave csatornákon pedig nincs egy sem. Itt válasszuk ki azt a lemezt, amelyre a &os;-t telepíteni kívánjuk, majd nyomjuk meg a &gui.ok; gombot. Erre az által bemutatott képernyõvel elindul az FDisk. Az FDisk képernyõje három részre osztható. Az elsõ részben, amely a képernyõ felsõ két sorát foglalja össze, láthatjuk az éppen kiválasztott lemez adatait: a &os; szerinti nevét, a paramétereit és az összméretét. A második részben láthatjuk a lemezen megtalálható slice-okat: hol kezdõdnek (Offset) és hol érnek véget (End); mekkorák (Size); a &os; milyen névvel hivatkozik rájuk (Name); milyen leírás (Description) és altípus (Subtype) tartozik hozzájuk. A példában két kicsi üres slice-ot láthatunk, ami a PC-k lemezkiosztására jellemzõ. Ezenkívül felfedezhetünk egy nagyobb méretû FAT típusú slice-ot is, amely az &ms-dos; / &windows; világban szinte minden bizonnyal a C: betûjelet viseli, valamint egy kiterjesztett slice-ot is, amely az &ms-dos; / &windows; számára további meghajtókat is tartalmazhat. A harmadik részben az FDisk mûködtetésére használható parancsok láthatóak.
Átlagos Fdisk partíciók szerkesztés elõtt
A most következõ teendõink attól függenek, hogy miként is akarjuk felosztani a lemezünket. Ha az egész lemezt a &os; használatára áldozzuk (és amikor majd megerõsítjük a sysinstall számára a továbblépést, a lemezen így minden más adat törlõdni fog), akkor nyomjuk le az A billentyût, amely megfelel a Use Entire Disk (Az egész lemez használata) menüpontnak. A létezõ slice-ok eltávolításra kerülnek és helyettük megjelenik egy unused (üres) jelzésû kis méretû terület (elvégre PC-rõl beszélünk), valamint egy nagyobb slice a &os; számára. Ha így jártunk el, akkor válasszuk ki nyilakkal a frissen létrejött &os; slice-ot és az S billentyû lenyomásával jelöljük be indíthatónak (bootable). A képernyõ ekkor a által mutatotthoz fog erõsen hasonlítani. A Flags (Beállítások) oszlopban láthatjuk az A jelzést, amelybõl kiderül, hogy az adott slice aktív, tehát róla tud indulni a rendszer. Ha a &os; számára egy meglevõ slice törlésével szeretnénk helyet csinálni, akkor ehhez válasszuk ki nyílbillentyûkkel a használni kivánt slice-ot és nyomjuk le a D billentyût. Ezután nyomjuk le a C billentyût is, amire felbukkan a létrehozandó slice méretét kérdezõ ablak. Adjuk meg a számunkra megfelelõ méretet a számunkra megfelelõ formában, majd zárjuk le az Enter lenyomásával. Az ablakban szereplõ alapértelmezett érték a létrehozható lehetõ legnagyobb méretû slice-ot adja meg, ami vagy a legnagyobb összefüggõ üres terület, vagy pedig az egész merevlemez összterülete lehet. Ha már korábban készítettünk elõ helyet a &os;-nek (például egy &partitionmagic; vagy egy hozzá hasonló alkalmazás segítségével), akkor csak elegendõ az új slice létrehozásához megnyomnunk a C billentyût. Ekkor szintén megkérdezésre kerül a létrehozandó slice mérete.
Particionálás az Fdisk <quote>Using Entire Disk</quote> funkciójával
Amikor befejeztük, nyomjuk le a Q billentyût. Ekkor a sysinstall elmenti a beállított értékeket, azonban a lemezre ekkor még nem kerülnek ki. A rendszerválasztó telepítése Mindezek után lehetõségünk nyílik telepíteni egy rendszerválasztót (boot manager). Általában véve akkor van szükségünk a &os; rendszerválasztójának telepítésére, ha: Egynél több meghajtónk van, és közülük nem az elsõ meghajtóra telepítjük a &os;-t. A &os;-t ugyanazon a lemezen más operációs rendszerek mellé telepítjük, és szeretnénk választhatóvá tenni, hogy a számítógép indításakor a &os; vagy a többi operációs rendszer induljon-e el. Amennyiben a &os; lesz az egyetlen operációs rendszer a gépünkön és az elsõ merevlemezes meghajtóra telepítjük, akkor a Standard (Szabványos) rendszerválasztó tökéletesen megteszi. Ha viszont a &os; indításához egy másik rendszerválasztót szeretnénk használni, válasszuk a None (Nincs) opciót. Válasszunk, majd nyomjuk le az Enter billentyût!
A <application>sysinstall</application> rendszerválasztókat tartalmazó menüje
Az F1 billentyû lenyomásán keresztül elérhetõ súgóképernyõn olvashatunk az egy merevlemezen több operációs rendszer használatával kapcsolatos problémákról. Slice-ok létrehozása egy másik meghajtón Ha egynél több meghajtónk van, a program a rendszerválasztó képernyõje után ismét visszatér a meghajtók kiválasztásához. Amennyiben a &os;-t egy másik meghajtóra is telepíteni szeretnénk, itt válasszuk ki azt és ismételjük meg vele az imént az FDisk programmal végzett felosztási folyamatot. Amikor a &os;-t nem az elsõ meghajtóra telepítjük, akkor a &os; rendszerválasztóját mind a két meghajtóra telepíteni kell.
Kilépés a meghajtóválasztó menübõl
A Tab billentyûvel tudunk váltani a legutoljára kiválasztott meghajtó, a &gui.ok; és a &gui.cancel; gombok között. Az &gui.ok; gombra álláshoz nyomjuk le egyszer a Tabot, majd a telepítés folytatásához nyomjuk le az Enter billentyût. Partíciók létrehozása a <application>Disklabel</application> segítségével A következõ lépésként létre kell hoznunk partíciókat a frissen létrehozott slice-okban. Ne felejtsük el, hogy minden partíció rendelkezik egy a-tól h-ig terjedõ betûjellel, amelyek közül a b, c és d jelzésûeknek külön szerepe van, amire tekintettel kell lennünk. Bizonyos alkalmazások kedvelnek egyes partíciókiosztási sémákat, különösen az egynél több lemezen elhelyezkedõ partíciókat. Azonban az elsõ &os; telepítésünk során még nem annyira fontos koncentrálnunk a lemezünk hatékony felosztására. Sokkal inkább fontosabb, hogy elõször egyszerûen csak telepítsük a &os;-t és tanuljuk meg a használatát. Amikor már jobban ismerni fogjuk az operációs rendszert, a partíciók kiosztásának megváltoztatásához mindig újra tudjuk telepíteni a &os;-t. Ebben a sémában négy partíció szerepel — egy a lapozóállománynak és három az állományrendszereknek. Az elsõ lemez partícióinak kiosztása Partíció Állományrendszer Méret Leírás a / 1 GB Ez a rendszerindításhoz használt, más néven a gyökér állományrendszer (root filesystem). Minden további állományrendszer ehhez csatlakozik valahol. Ennek az állományrendszernek 1 GB méret elfogadható, mivel nem fogunk túlságosan sok adatot tárolni rajta, a &os; telepítõje is csak nagyjából 128 MB adatot fog ide tenni. Az így fennmaradó lemezterület felhasználható átmeneti adatok tárolására, illetve a / könyvtárban helyet ad a &os; késõbbi változatainak terjeszkedéséhez is. b - RAM mérete x 2-3 A rendszer lapozóállománya a b partíción tárolódik. Itt a megfelelõ méret megválasztása egyfajta mûvészet, azonban minden esetben hasznosnak bizonyulhat, ha tudjuk, hogy méretnek mindig érdemes a fizikai avagy központi memória (RAM) méretének két, esetleg háromszorosát választani. Legyen mindig legalább 64 MB-nyi méretû lapozóállományunk, és ha 32 MB RAM-nál kevesebb van a számítógépünkben, akkor is legalább 64 MB-ra állítsuk be. Ha egynél több lemezünk van, mindegyikre rakhatunk lapozóállományt, ezzel a &os; mindegyikõjüket fel tudja használni lapozásra, amivel pedig gyakorlatilag felgyorsítja a folyamatot. Ilyenkor számoljunk úgy, hogy elõször meghatározzuk a teljes lapozóállomány méretét (például 128 MB), majd ezt elosztjuk a rendelkezésünkre álló lemezek számával (például kettõ). Ebbõl kiszámítható az egyes lemezeken elhelyezendõ lapozóállomány mérete, ami most a példánk szerint 64 MB lesz. e /var 512 MB-tl 4096 MB-ig A /var könyvtár foglalja magában az állandó változó naplóállományokat, valamint a többi, adminisztrációhoz használt állományt. Ezek többsége a &os; mindennapos mûködése közben folyamatosan íródnak vagy olvasódnak. Ha ezeket az állományokat egy külön állományrendszerre rakjuk, akkor ezzel segítünk a &os;-nek optimalizálni az ilyen állományok elérését anélkül, hogy ez hatással lenne a többi, más hozzáférési gyakorisággal bíró állományra. f /usr A lemez többi része (legalább 8 GB) Az összes többi állomány többnyire a /usr könyvtárban és annak alkönyvtáraiban helyezkedik el.
Az imént megadott értékeket csak példaként adtuk meg és csak a tapasztalt felhasználók számára ajánljuk. A többi felhasználónak inkább a partíciók automatikus kiosztását javasoljuk a &os; partíciószerkesztõjében található Auto Defaults opció használatával. Ha a &os;-t egynél több lemezre telepítjük, akkor a korábban megadott többi slice-ban is létre kell hoznunk partíciókat. Ezt legegyszerûbben úgy tehetjük meg, ha minden lemezen létrehozunk két partíciót: egyet a lapozóállománynak, egyet pedig az állományrendszernek. Több lemez partícióinak kiosztása Partíció Állományrendszer Méret Leírás b - Lásd a leírást Ahogy már korábban is említettük, szét tudjuk osztani a lapozóállományt a lemezek között. Habár az a partíció szabad, a hagyományok mégis azt diktálják, hogy a lapozáshoz használt terület maradjon a b partíción. e /diskn A lemez többi része A lemez fennmaradó része egyetlen nagy partícióval fedhetõ le. Ez az e partíció helyett lehetne minden további nélkül az a partíció, azonban a hagyományok szerint az a partíciónak a rendszer gyökér állományrendszerét (/) kell tartalmaznia. Nekünk ugyan nem kellene ezt a megszokást követnünk, azonban a sysinstall viszont így tesz, ezért ezzel a választással csak magunkkal teszünk jót. Az állományrendszer bárhová csatlakoztatható — ebben a példában a lemezeket rendre a /diskn könyvtárakhoz csatoltuk, ahol az n az adott lemez sorszáma. De itt természetesen más rendszert is követhetünk.
A partíciók elrendezésének kigondolása után most már létre is hozathatjuk ezeket a sysinstall segítségével. Ekkor a következõ üzenetet fogjuk látni: Message Now, you need to create BSD partitions inside of the fdisk partition(s) just created. If you have a reasonable amount of disk space (1GMB or more) and don't have any special requirements, simply use the (A)uto command to allocate space automatically. If you have more specific needs or just don't care for the layout chosen by (A)uto, press F1 for more information on manual layout. [ OK ] [ Press enter or space ] Az üzenet fordítása: Üzenet Most létre kell hoznunk az fdiskkel nemrég elkészített partíciókban a BSD-s partíciókat. Ha van hozzá elegendõ helyünk (1G vagy több) és nincs semmilyen különleges elvárásunk, akkor egyszerûen csak osszuk fel automatikusan az (A)uto paranccsal. Amennyiben azonban ennél többre lenne szükségünk, vagy csak nincs szükségünk az (A)uto által felkínált sémára, az F1 lenyomására bõvebb információkat is kaphatunk a kézi kiosztás lehetõségeirõl. [ OK ] [ Nyomja le az Enter vagy a Szóköz billentyût ] Nyomjuk le a Enter billentyût a &os; partíciószerkesztõjének, avagy a Disklabel elindításához. A mutatja a Disklabel elsõ elindulásakor megjelenõ képet. A képernyõ három részre tagolható. A felsõ pár sorban a jelenleg használt lemez nevét láthatjuk, valamint azt a slice-ot, ami az általunk létrehozott partíciókat tartalmazza (itt a Disklabel a Partition name megnevezéssel hivatkozik a slice-ra). A képernyõn továbbá láthatjuk a slice-ban levõ szabad helyet is, vagyis azt a helyet, amely ugyan a slice-hoz tartozik, viszont még nem rendeltünk hozzá partíciót. A képernyõ közepén találhatóak az eddig már létrehozott partíciók, az általuk tartalmazott állományrendszerek, azok mérete és az állományrendszerek létrehozására vonatkozó különbözõ beállítások. A képernyõ alsó harmadában a Disklabel programban használható billentyûk felsorolása szerepel.
A <application>sysinstall</application> Disklabel partíciószerkesztõje
A Disklabel képes magától partíciókat készíteni a nekik megfelelõ alapértelmezett méretekkel. A partíciók automatikus méretét egy belsõ partícióméretezõ algoritmus számítja ki a lemez összmérete alapján. Próbáljuk most mi is ezt ki, és nyomjuk le az A billentyût. Ekkor a szerint illusztráltaknak megfelelõ képernyõt tapasztalhatunk. A használt lemez méretétõl függõen az alapértelmezett értékek megfelelõek lesznek vagy sem. Ez igazából nem számít, hiszen nem kell feltétlenül elfogadnunk az alapértelmezetten megállapított értékeket. Az alapértelmezett partícionálási sémában a /tmp könyvtár nem a / könyvtár része lesz, hanem saját partíciót kapott. Ezzel igyekszünk elkerülni, hogy a / partíció átmenetileg tárolt állományokkal teljen be.
A <application>sysinstall</application> Disklabel partíciószerkesztõje, alapértelmezett értékekkel
Ha nem az alapértelmezett partíciókat szeretnénk használni, és le akarjuk váltani ezeket a saját magunk által megadottakra, akkor a nyílbillentyûkkel válasszuk ki az elsõ partíciót és a törléséhez nyomjuk meg a D billentyût. Hasonlóan járjunk el az összes többi javasolt partíció törléséhez. Az elsõ (a, vagyis a / könyvtárként, azaz a gyökérként csatolt) partíció elkészítéséhez elõször gyõzõdjünk arról, hogy a felsõ sorban a megfelelõ slice van kiválasztva, majd nyomjuk meg a C billentyût. Ekkor az új partíció méretét kérdezõ párbeszédablak jelenik meg (lásd: ). Itt a méret a lemez blokkjainak számában adható meg, amit viszont M-mel lezárva megabyte-ban, G-vel gigabyte-ban vagy C-vel cilinderben is kifejezhetünk.
Szabad hely a gyökérpartíción
Az alapértelmezés szerint felkínált méret az egész slice-ot lefoglaló partíciót hoz létre. Amennyiben a korábbi példában tárgyalt partícióméreteket kívánjuk használni, akkor a Backspace billentyû használatával töröljük ki az így megadott értéket, és helyette gépeljük be, hogy 512M, ahogy ez a segítségével is látható. A bevitelt zárjuk a &gui.ok; gomb lenyomásával.
A gyökérpartíció méretének szerkesztése
Miután meghatároztuk a partíció méretét, a telepítõ megkérdezi, hogy a létrehozandó partícióban állományrendszer vagy lapozóállomány foglaljon-e helyet. Ennek a párbeszédablakját a mutatja. Mivel az elsõ partíciónk állományrendszert fog tartalmazni, ezért mindenképpen az FS paramétert válasszuk ki, majd nyomjuk meg az Enter billentyût.
A gyökérpartíció típusának kiválasztása
Végezetül, mivel egy állományrendszert hoztunk létre, meg kell mondanunk a Disklabelnek, hova csatlakoztassa. A hozzá tartozó párbeszédablak a n látható. A gyökér állományrendszer csatlakozási pontja a /, ezért itt csak annyit adjunk meg, hogy / és zárjuk az Enter billentyû lenyomásával.
A gyökér csatlakozási pontjának megadása
A képernyõn látható lista ezután az újonnan létrehozott partíciónak megfelelõen frissül. A többi partícióra ugyanígy meg kell ismételnünk ezt a mûveletsort. Arra azonban figyeljünk, hogy a lapozásra használt partíciót létrehozásánál a szerkesztõ nem fogja megkérdezni a csatlakozási pontot, hiszen az ilyen típusú partíciókat sosem csatlakoztatjuk. A /usr, vagyis az utolsó partíció készítése során a slice fennmaradó részének lefoglalásához már nyugodtan meghagyhatjuk a felajánlott értéket. A &os; partíciószerkesztõjének utolsó képernyõje a n hasonlóhoz, habár az általunk választott értékek minden bizonnyal eltérnek. A mûvelet befejezéséhez nyomjuk le a Q billentyût.
A Disklabel partíciószerkesztõ
A telepítendõ összetevõk kiválasztása A terjesztések típusának kiválasztása A telepítendõ terjesztések típusa nagyban függ attól, hogy a rendszerünket mire szándékozzuk majd használni és mennyi szabad hely áll rendelkezésünkre. Az elõre megadott beállítások a lehetõ legkisebb konfiguráció telepítésétõl egészen a komplett rendszer telepítéséig terjednek. A &unix; és/vagy &os; világában még az új felhasználók számára szinte tökéletesen megfelelõnek bizonyulhat az egyik ilyen elõkészített beállítás kiválasztása. A terjesztések kiválogatása pedig általában a tapasztaltabb felhasználók számára lehet hasznos. Az F1 billentyûvel többet is megtudhatunk a terjesztések különbözõ típusairól és bennük található összetevõkrõl. Miután befejeztük a súgó áttanulmányozását, nyomjuk le az Enter billentyût, és ezzel visszatérünk a terjesztések kiválasztását tartalmazó menübe. Ha grafikus felületet szeretnénk használni, akkor az X szerver beállítását az alapértelmezett munkakörnyezet beállítását a &os; telepítése után kell megtenni. Az X szerver beállításáról részletesebben a ban olvashatunk. Ha egy saját rendszermag építését is fontolgatjuk, akkor olyan terjesztést válasszuk, amiben a forráskód (kernel source) is megtalálható. A saját rendszermag építésének hátterérõl és mikéntjérõl lásd a et. Értelemszerûen a legsokoldalúbb rendszer az, amiben minden megtalálató. Így aztán, ha a lemezünk is megengedi, a nyilak és az Enter használatával válasszuk a All (Minden) opciót, ahogy azt az is mutatja. Ha viszont úgy érezzük, hogy ehhez nem eléggé nagy a lemezünk, akkor válasszuk az igényeinkhez jobban illeszkedõ típust. Sokat azonban ne üljünk a tökéletes megoldás kiötlésén, hiszen ezek a terjesztések még a telepítés befejezése után is hozzáadhatóak a rendszerünkhöz.
A terjesztések kiválasztása
A Portgyûjtemény telepítése Miután kiválasztottuk a nekünk megfelelõ terjesztést, a telepítõprogram felajánlja a &os; Portgyûjteményének (Ports Collection) telepítésének lehetõségét. A portok gyûjteménye a szoftverek telepítésének egyszerû és kényelmes módja. A Portgyûjtemény önmaga nem tartalmazza a szoftverek lefordításához szükséges forráskódot, hanem helyette csupán azokat az állományokat, amelyek a különbözõ külsõs programok letöltéséhez, fordításához és telepítéséhez kellenek. A ben megtalálhatjuk, miként is kell használni ezt a gyûjteményt. A telepítõprogram nem fogja ellenõrizni a kibontásához szükséges helyet, ezért csak abban az esetben válasszuk ezt a lehetõséget, ha mindenképpen elfér a merevlemezünkön. A &os; jelenlegi, &rel.current; változatában a Portgyûjtemény nagyjából &ports.size; helyet foglal el a lemezen. A &os; frissebb verzióiban nyugodtan feltételezhetünk ennél valamivel nagyobb értéket is. User Confirmation Requested Would you like to install the FreeBSD ports collection? This will give you ready access to over &os.numports; ported software packages, at a cost of around &ports.size; of disk space when "clean" and possibly much more than that if a lot of the distribution tarballs are loaded (unless you have the extra CDs from a FreeBSD CD/DVD distribution available and can mount it on /cdrom, in which case this is far less of a problem). The Ports Collection is a very valuable resource and well worth having on your /usr partition, so it is advisable to say Yes to this option. For more information on the Ports Collection & the latest ports, visit: http://www.FreeBSD.org/ports [ Yes ] No Az üzenet fordítása: Felhasználói megerõsítés szükséges Szeretné telepíteni a FreeBSD portjainak gyûjteményét? Ezen keresztül közel &os.numports; portolt szoftvercsomaghoz tudunk könnyedén hozzáférni, amelyek "tiszta" állapotukban nagyjából &ports.size; lemezterületünkbe kerülnek, ami a késõbbiekben valószínûleg majd növekedni fog, ahogy letöltjük a különbözõ szoftverekhez tartozó állományokat (hacsak nincs meg a FreeBSD valamelyik CD- vagy DVD alapú terjesztésének az összes lemeze, amelyeket a /cdrom könyvtárba csatlakoztatva el tudjuk ezeket érni, mert ekkor kevesebb gondunk lesz vele). A Portgyûjtemény egy nagyon értékes erõforrás, amelynek megéri helyet szentelni a /usr partíciónkon, ezért javasoljuk, hogy válassza az "Igen" opciót. A Portgyûjteményrõl és annak legújabb portjairól a http://www.FreeBSD.org/ports oldalon olvashat részletesebben. [ Igen ] Nem A Portgyûjtemény telepítéséhez a &gui.yes; gombot, ennek kihagyásához pedig a &gui.no; gombot válasszuk ki a nyilakkal, majd az Enter lenyomásával mehetünk tovább. Ekkor a kiválasztott terjesztések menüje fog újra megjelenni.
A terjesztések telepítésének megerõsítése
Ha elégedettek vagyunk a beállításokkal, válasszuk ki a nyilakkal az Exit menüpontot, gyõzõdjünk meg róla, hogy a &gui.ok; gombon állunk, majd nyomjuk le az Enter billentyût a folytatáshoz. A telepítés eszközének kiválasztása Ha CD-rõl vagy DVD-rõl telepítünk, akkor a következõ képernyõn a nyílbillentyûkkel válasszuk ki a Install from a CDROM or DVD (Telepítés CD-rõl vagy DVD-rõl) menüpontot. Ügyeljünk a &gui.ok; gomb kiválasztására is, majd a telepítés megkezdéséhez nyomjuk meg az Enter billenyût. A telepítés másfajta módszereinek alkalmazásához válasszuk ki a menüpontok közül a nekünk megfelelõt és kövessük a megjelenõ utasításokat. Az F1 billentyû lenyomására megjelenik az adott telepítõeszközhöz tartozó súgó. Innen az Enter lenyomása után térhetünk vissza a menühöz.
A telepítési eszköz kiválasztása
Telepítés FTP szerverrõl telepítés hálózat FTP Három FTP-s telepítési mód közül választhatunk: aktív, passzív vagy HTTP proxyn keresztül. Aktív FTP: Install from an FTP server (Telepítés FTP szerverrõl) Ezzel a beállítással az összes FTP-n keresztüli átvitel aktív módban történik. Ez tûzfalak esetén nem mûködik, de gyakran alkalmazható olyan régebbi FTP szerverek esetén, amelyek nem ismerik az passzív adatátvitelt. Ha (az alapértelmezett) passzív módban megakadna a kapcsolat, próbáljunk meg helyette az aktívat. Passzív FTP: Install from an FTP server through a firewall (Telepítés tûzfalon keresztül FTP szerverrõl) FTP passzív mód Ezzel a beállítással a sysinstall programot az FTP mûvelet végrehajtásakor a passzív mód használatára utasítjuk. Így át tudunk menni olyan tûzfalakon is, amelyek nem engedik a véletlenszerû TCP portokon érkezõ kapcsolatokat. FTP HTTP proxyn keresztül: Install from an FTP server through a http proxy (Telepítés HTTP proxyn keresztül FTP szerverrõl) FTP HTTP proxyn keresztül Ezzel a beállítással megmondhatjuk a sysinstall programnak, hogy (egy böngészõhöz hasonlóan) a HTTP protokollon keresztül használja az FTP mûveletek elvégzéséhez használt proxyt. Ennek a proxynak lesz a feladata az átadott kérések lefordítása és elküldése az FTP szervernek. Ennek köszönhetõen át tudunk menni olyan tûzfalakon is, amelyek egyáltalán nem engednek semmilyen FTP mûveletet, azonban tartozik hozzájuk egy HTTP proxy. Ilyenkor az FTP szerver beállításai mellett meg kell adnunk ezt a HTTP proxyt is. Az FTP szervert proxyn keresztül általában úgy érjük el, hogy a felhasználói név részeként egy @ jellel elválasztva megadjuk a ténylegesen elérni kívánt szerver nevét. A proxy szerver ezután helyettesíti a valódi szervert. Például tegyük fel, hogy a ftp.FreeBSD.org szerverrõl akarunk telepíteni az 1234 porton várakozó ize.minta.com proxy használatával. Ehhez lépjünk be a beállításokat tartalmazó menübe, állítsuk az FTP kapcsolathoz használt felhasználói nevet az ftp@ftp.FreeBSD.org értékre, majd jelszónak adjuk meg az e-mail címünket. Telepítési eszközként adjuk meg az FTP-t (vagy a passzív FTP-t, amennyiben a proxy ismeri) és a ftp://ize.minta.com:1234/pub/FreeBSD címet. Mivel az ftp.FreeBSD.org címrõl származó /pub/FreeBSD könyvtár a ize.minta.com szerveren keresztül érhetõ el számunkra, ezért lényegében arról a géprõl fogunk telepíteni (amely pedig a telepítõ kéréseire elhozza a ftp.FreeBSD.org szervertõl az állományokat). A telepítés véglegesítése Ezután ha óhajtjuk, megkezdhetjük a telepítést. Ez egyben az utolsó lehetõségünk a telepítés megszakítására és merevlemezünket érintõ változtatások érvénytelenítésére. User Confirmation Requested Last Chance! Are you SURE you want to continue the installation? If you're running this on a disk with data you wish to save then WE STRONGLY ENCOURAGE YOU TO MAKE PROPER BACKUPS before proceeding! We can take no responsibility for lost disk contents! [ Yes ] No Az üzenet fordítása: Felhasználói megerõsítés szükséges Utolsó esély: BIZTOSAN folytatni kívánja a telepítést? Ha olyan lemezre szeretne telepíteni, amelyen fontos adatok találhatóak, HATÁROZOTTAN JAVASOLJUK, hogy a továbblépés elõtt KÉSZÍTSEN RÓLUK MEGBÍZHATÓ BIZTONSÁGI MÁSOLATOT! Nem vállalunk semmilyen felelõsséget az elvesztett adatokért! [ Igen ] Nem A továbblépéshez válasszuk a &gui.yes; gombot és nyomjuk meg az Enter billentyût. A telepítés idõtartama a kiválasztott terjesztéstõl, a telepítésre használt eszköztõl és számítógépünk sebességétõl függ. A folyamat elõrehaladásáról üzenetek sorozata tájékoztat minket. A telepítés befejezése után a következõ üzenet jelenik meg: Message Congratulations! You now have FreeBSD installed on your system. We will now move on to the final configuration questions. For any option you do not wish to configure, simply select No. If you wish to re-enter this utility after the system is up, you may do so by typing: /usr/sbin/sysinstall. [ OK ] [ Press enter or space ] A szöveg fordítása: Üzenet Gratulálunk, sikeresen telepítette a FreeBSD rendszert a számítógépére! Most rátérünk az utolsó néhány kérdésre. A "Nem" választásával egyszerûen átugorhatjuk mindazt, amit nem szeretnénk beállítani. Ezt a segédprogramot a rendszer újbóli elindítása után a "/usr/sbin/sysinstall" parancs begépelésével tudjuk elérni. [ OK ] [ Nyomja le az Enter vagy a Szóköz billentyût ] Az Enter billentyû lenyomásával megkezdhetjük a telepítés utáni beállításokat. A &gui.no; gomb kiválasztásával és az Enter lenyomásával megszakíthatjuk a telepítést, így a rendszerünkön semmilyen változtatás nem történik. Ilyenkor a következõ üzenet jelenik meg: Message Installation complete with some errors. You may wish to scroll through the debugging messages on VTY1 with the scroll-lock feature. You can also choose "No" at the next prompt and go back into the installation menus to retry whichever operations have failed. [ OK ] Az üzenet fordítása: Üzenet A telepítés során hiba történt. A Scroll Lock használatával érdemes átnézni a VTY1 terminál megjelenõ üzeneteket. A következõ ablakban a "Nem" választásával vissza tudunk menni a telepítõmenühöz és megpróbálkozhatunk ismét a sikertelen mûveletek végrehajtásával. [ OK ] Ez az üzenet azért jelent meg, mert semmit sem sikerült telepíteni. Innen az Enter megnyomásával térhetünk vissza a fõmenübe, majd onnan tudunk kilépni a telepítõbõl. A telepítés után A sikeres telepítést különféle beállítások követik. Közülük az új &os; rendszer indítása elõtt bármelyik megismételhetõ a beállítások opcióit tartalmazó menü újbóli használatával, vagy pedig a telepítés után a sysinstall parancs kiadásával, majd a Configure (Beállítások) menüpont kiválasztásával. A hálózati eszközök beállítása A következõ képernyõ már nem jelenik meg, ha az FTP szerveren keresztüli telepítéshez korábban már beállítottuk a PPP kapcsolatot. Ez a korábbiakban említettek szerint állítható be. Ha többet szeretnénk megtudni a helyi hálózatokról (LAN), vagy a &os;-t átjáróként, illetve útválasztóként kívánjuk beállítani, olvassuk el az Egyéb haladó hálózati témák címû fejezetet. User Confirmation Requested Would you like to configure any Ethernet or PPP network devices? [ Yes ] No Fordítása: Felhasználói megerõsítés szükséges Szeretnénk beállítani valamilyen Ethernet- vagy PPP hálózati eszközt? [ Igen ] Nem A hálózati eszközeink beállításához válasszuk a &gui.yes; gombot, majd nyomjuk meg az Enter billentyût. Ellenkezõ esetben a &gui.no; gombbal mehetünk tovább.
Az Ethernet-eszköz kiválasztása
A beállítandó csatoló kiválasztásához használjuk a nyílbillentyûket és utána nyomjuk meg az Enter billentyût. User Confirmation Requested Do you want to try IPv6 configuration of the interface? Yes [ No ] Fordítás: Felhasználói megerõsítés szükséges Megpróbálkozik az IPv6 beállításával a csatolón? Igen [ Nem ] A példánkban szereplõ helyi hálózatban az aktuális internetes protokoll (IPv4) egyelõre megfelelõ, ezért válasszuk a &gui.no; gombot és nyomjuk meg az Enter billentyût. Amennyiben RA-szerveren keresztül egy már létezõ IPv6 hálózathoz csatlakozunk, akkor válasszuk a &gui.yes; gombot és nyomjuk meg az Enter billentyût. Ezt követõen az RA-szerverek felderítése kezdõdik meg, ami néhány másodpercig eltarthat. User Confirmation Requested Do you want to try DHCP configuration of the interface? Yes [ No ] Az üzenet fordítása: Felhasználói megerõsítés szükséges Megpróbálkozik a DHCP használatával a csatolón? Igen [ Nem ] Ha nincs szükségünk a DHCP (Dynamic Host Configuration Protocol, azaz a Dinamikus állomáskonfigurációs protokoll) használatára, akkor a &gui.no; gomb kiválasztásával majd az Enter lenyomásával továbbléphetünk. A &gui.yes; gomb kiválasztására elindul a dhclient nevû program, és amennyiben sikerrel jár, magától kitölti a hálózati beállításokra vonatkozó adatokat. Ennek részleteit a ben találhatjuk meg. Az alábbi hálózati beállító képernyõ mutatja a helyi hálózat átjárójaként használni kívánt Ethernet-eszköz konfigurációját.
Az ed0 hálózati beállítása
A Tab billentyûvel tudunk navigálni az adatlap mezõi között és kitölteni ezeket a megfelelõ információkkal: Host (Számítógépnév) A számítógépünk teljes neve, amely a példában most k6-2.example.com. Domain (Tartomány) Annak a tartománynak a neve, amelyben a számítógépünk a található. Ez itt konkrétan a example.com. IPv4 Gateway (IPv4-átjáró) A helyben nem elérhetõ célok megközelítésére használt gép IP-címe. Ezt a mezõt mindenképpen töltsük ki akkor, ha a számítógépünk valamilyen hálózatba van kötve. Azonban hagyjuk üresen, ha a számítógép a hálózat átjárója az internet felé. Az IPv4 átjárót más néven default gateway-nek (alapértelmezett átjárónak) vagy default route-nak (alapértelmezett útvonalnak) is nevezik. Name server (Névszerver) A helyi DNS (névfeloldó) szerverünk IP-címe. Ha nem található ilyen a helyi hálózatunkon, akkor az internet-szolgáltató DNS szerverének címét (a példában ez a 208.163.10.2) adjuk meg. IPv4 address (IPv4-cím) A csatoló IP-címe, amely az ábrán a 192.168.0.1. Netmask (Hálózati maszk) A helyi hálózatban használt címtartomány a 192.168.0.0 - 192.168.0.255, amihez a 255.255.255.0 hálózati maszk tartozik. Extra options to ifconfig (Az ifconfig további beállításai) Az ifconfig parancs adott csatolóra vonatkozó egyéb beállításai. Jelen esetünkben itt semmi sem szerepel. Miután végeztünk, a Tab billentyû lenyomásával válasszuk ki a &gui.ok; gombot és nyomjuk le az Enter billentyût. User Confirmation Requested Would you like to bring the ed0 interface up right now? [ Yes ] No A fordítás: Felhasználói megerõsítés szükséges Aktiválja most az ed0 csatolót? [ Igen ] Nem A &gui.yes; gomb kiválasztásával, majd az Enter lenyomásával csatlakoztatjuk a számítógépet a hálózathoz, ami ezután használhatóvá válik. Ez azonban a telepítés számára nem jelent túlságosan sokat, hiszen ettõl függetlenül a számítógépet egyébként is újra kell majd indítanunk. Az átjáró beállítása User Confirmation Requested Do you want this machine to function as a network gateway? [ Yes ] No A fordítás: Felhasználói megerõsítés szükséges Ezt a számítógépet hálózati átjáróként is használni akarja? [ Igen ] Nem Ha a számítógépet a helyi hálózat átjárójaként használni akarjuk gépek közti csomagok továbbítására, akkor válasszuk a &gui.yes; gombot és nyomjuk meg hozzá az Enter billentyût. Ha viszont ez a gép csupán a hálózat egy tagja, akkor válasszuk a &gui.no; gombot és a folytatáshoz nyomjuk meg az Enter billentyût. A hálózati szolgáltatások beállítása User Confirmation Requested Do you want to configure inetd and the network services that it provides? Yes [ No ] Fordítás: Felhasználói megerõsítés szükséges Beállítja az inetd démont és az általa felkínált hálózati szolgáltatásokat? Igen [ Nem ] Ha itt a &gui.no; gombot választjuk, akkor ezzel kikapcsoljuk a különbözõ szolgáltatásokat, például a telnetd démont. Ez azt jelenti, hogy a távoli felhasználók nem lesznek képesek a telnet program használatával belépni erre a számítógépre. A helyi felhasználók viszont továbbra is képesek lesznek távoli számítógépeket elérni a telnet segítségével. Az /etc/inetd.conf átírásával azonban ezek a szolgáltatások késõbb természetesen engedélyezhetõek. A foglalkozik a téma részleteivel. A &gui.yes; gomb választásával már a telepítés során beállíthatjuk a szolgáltatásokat. Ekkor egy további párbeszédablak is felbukkan: User Confirmation Requested The Internet Super Server (inetd) allows a number of simple Internet services to be enabled, including finger, ftp and telnetd. Enabling these services may increase risk of security problems by increasing the exposure of your system. With this in mind, do you wish to enable inetd? [ Yes ] No Fordítása: Felhasználói megerõsítés szükséges A fõ internetes kiszolgáló (az inetd) számos egyszerû internetes szolgáltatás, többek közt a finger, ftp és telnet elérését teszi lehetõvé. Ezen szolgáltatások engedélyezése azonban a felmerülõ biztonsági problémák kockázatát, mivel ezzel rendszerünket jobban kitesszük támadásoknak. Mindezek tudatában használni kívánja az inetd démont? [ Igen ] Nem A folytatáshoz válasszuk a &gui.yes; gombot. User Confirmation Requested inetd(8) relies on its configuration file, /etc/inetd.conf, to determine which of its Internet services will be available. The default FreeBSD inetd.conf(5) leaves all services disabled by default, so they must be specifically enabled in the configuration file before they will function, even once inetd(8) is enabled. Note that services for IPv6 must be separately enabled from IPv4 services. Select [Yes] now to invoke an editor on /etc/inetd.conf, or [No] to use the current settings. [ Yes ] No Fordítás: Felhasználói megerõsítés szükséges Az inetd(8) démonnak az elérhetõ internetes szolgáltatások megállapításához szüksége van a beállításait tartalmazó /etc/inetd.conf állományra. A FreeBSD-hez tartozó inetd.conf(5) állomány alapértelmezés szerint az összes szolgáltatást letiltja, ezért a mûködéséhez minden egyes szolgáltatást külön kell engedélyezni az említett állományban, még abban az esetben is, ha az inetd(8) démont korábban már engedélyeztük. Az IPv6 szolgáltatások az IPv4 szolgáltatásoktól külön engedélyezendõek. Az [ Igen ] választásával behívjuk az /etc/inetd.conf szerkesztését, míg a [ Nem ] választásával pedig az imént felvázolt beállításokat fogadjuk el. [ Igen ] Nem A &gui.yes; gomb kiválasztásával lehetõségünk nyílik szolgáltatásokat engedélyezni a sorok elején található # jel törlésével.
Az <filename>inetd.conf</filename> módosítása
Miután felvettük az összes használni kívánt szolgáltatást, az Esc billentyû lenyomásával elõhozhatjuk azt a menüt, ahol elmenthetjük a módosításainkat és kiléphetünk. Az SSH-n keresztüli bejelentkezés engedélyezése SSH sshd User Confirmation Requested Would you like to enable SSH login? Yes [ No ] Fordítás: Felhasználói megerõsítés szükséges Engedélyezi az SSH-n keresztüli bejelentkezést? Igen [ Nem ] A &gui.yes; gomb kiválasztása engedélyezi az OpenSSH-hoz tartozó &man.sshd.8; démont, aminek segítségével a számítógépünkre biztonságosan be tudunk jelentkezni távolról. Az OpenSSH részleteirõl lásd a t. Anonim FTP FTP anonim User Confirmation Requested Do you want to have anonymous FTP access to this machine? Yes [ No ] Fordítás: Felhasználói megerõsítés szükséges Hozzáférhetõ legyen ez a számítógép anonim FTP használatán keresztül? Igen [ Nem ] Az anonim FTP tiltása Az alapértelmezett &gui.no; gomb kiválasztásával és az Enter billentyû lenyomásával a jelszóval védett FTP hozzáféréssel rendelkezõ felhasználók továbbra is elérhetik a számítógépünket. Az anonim FTP engedélyezése Ha ezt választjuk, akkor anonim FTP kapcsolaton keresztül bárki hozzáférhet a számítógépünkhöz. Ebben az esetben azonban alaposan meg kell fontolnunk néhány biztonsági következményt. A beállítással járó kockázatokról az ben olvashatunk többet. Az anonim FTP bekapcsolásához a nyílbillentyûkkel válasszuk ki a &gui.yes; feliratú gombot és nyomjuk meg az Enter billentyût. Ekkor egy további párbeszédablak is megjelenik: User Confirmation Requested Anonymous FTP permits un-authenticated users to connect to the system FTP server, if FTP service is enabled. Anonymous users are restricted to a specific subset of the file system, and the default configuration provides a drop-box incoming directory to which uploads are permitted. You must separately enable both inetd(8), and enable ftpd(8) in inetd.conf(5) for FTP services to be available. If you did not do so earlier, you will have the opportunity to enable inetd(8) again later. If you want the server to be read-only you should leave the upload directory option empty and add the -r command-line option to ftpd(8) in inetd.conf(5) Do you wish to continue configuring anonymous FTP? [ Yes ] No Az üzenet fordítása: Felhasználói megerõsítés szükséges Az anonim FTP használatával a rendszer FTP szolgáltatásához hitelesítetlen felhasználók is hozzáférhetnek, amennyiben az aktív. A névtelen felhasználók az állományrendszernek csak egy részét érhetik el, valamint az alapbeállítások szerint a feltöltést egy külön erre a célra fenntartott könyvtárba végezhetik el. Az FTP szolgáltatás használatát külön engedélyeznünk kell az inetd(8) démon részérõl és az inetd.conf(5) állományban található ftpd(8) démon aktiválásával. Ha eddig még nem tettük volna meg, akkor az inetd(8) használatát késõbb még újra engedélyezhetjük. Ha csak letöltést kívánunk engedni, akkor hagyjuk a feltöltési könyvtárra vonatkozó paramétert üresen és az inetd.conf(5) állományban az ftpd(8) parancssorához adjuk hozzá az -r kapcsolót. Folytatja az anonim FTP beállítását? [ Igen ] Nem Az üzenet értesít minket arról, hogy az anonim FTP kapcsolatok engedélyezéséhez az FTP szolgáltatást az /etc/inetd.conf állományban is be kell majd kapcsolni, lásd . Válasszuk a &gui.yes; gombot és a folytatáshoz nyomjuk meg az Enter billentyût. Ekkor a következõ képernyõ jön elõ:
Az anonim FTP alapbeállításai
A beállítások kitöltése során a Tab billentyûvel mozoghatunk az adatmezõk között: UID (felhasználói azonosító) A névtelen FTP felhasználókhoz társított felhasználói azonosító. A feltöltött állomány tulajdonosa ez az azonosító lesz. Group (csoport) A névtelen FTP felhasználók csoportja. Comment (megjegyzés) Ez a szöveg szerepel a felhasználónál az /etc/passwd állományban. FTP Root Directory (az FTP gyökere) Itt találhatóak az anonim FTP-n keresztül elérhetõ állományok. Upload Subdirectory (feltöltési könyvtár) A névtelen FTP felhasználók által feltöltött állományok ide kerülnek. Az FTP gyökere alapból a /var könyvtár lesz. Ha a becsült FTP-forgalom lebonyolításához itt nem rendelkezünk elegendõ hellyel, akkor az /usr könyvtárban található /usr/ftp alkönyvtár is beállítható az FTP gyökerének. Ha elfogadhatónak találjuk az értékeket, nyomjuk le az Enter billentyût a folytatáshoz. User Confirmation Requested Create a welcome message file for anonymous FTP users? [ Yes ] No Fordítás: Felhasználói megerõsítés szükséges Létre kíván hozni egy köszöntõ üzenetet tartalmazó állományt az anonim FTP felhasználók számára? [ Igen ] Nem A &gui.yes; választásával és az Enter megnyomásával az üzenet szerkesztéséhez egy szövegszerkesztõ fog elindulni.
Az FTP köszöntõ üzenetének szerkesztése
Ez az ee szövegszerkesztõ. Az üzenet átírásához használjuk a megadott utasításokat, de akár késõbb is módosíthatjuk ezt a kedvenc szövegszerkesztõnkkel. Ehhez a módosítandó állomány neve és helye a szerkesztõ képernyõjének alján olvasható. A kilépéshez az Esc lenyomására felbukkanó menüben alapból az a) leave editor (kilépés a szerkesztõbõl) menüpont érhetõ el, ezért itt az Enter lenyomásával léphetünk tovább. Az Enter ismételt lenyomásával elmenthetjük a módosításainkat. A hálózati állományrendszer beállítása A hálózati állományrendszer (Network File System, NFS) állományok közzétételét teszi lehetõvé hálózaton keresztül. Használata során egy számítógép beállítható szervernek, kliensnek vagy akár mindkettõnek. Ezzel kapcsolatban a ajánlott elolvasásra. Az NFS szerver User Confirmation Requested Do you want to configure this machine as an NFS server? Yes [ No ] A fordítása: Felhasználói megerõsítés szükséges Be akarja állítani NFS szervernek ezt a számítógépet? Igen [ Nem ] Ha nincs szükségünk a hálózati állományrendszer szerver részére, akkor válasszuk a &gui.no; gombot és nyomjuk le az Enter billentyût. Amennyiben a &gui.yes; gombot választjuk, egy üzenet fogja közölni velünk, hogy létre kell hoznunk az exports állományt. Message Operating as an NFS server means that you must first configure an /etc/exports file to indicate which hosts are allowed certain kinds of access to your local filesystems. Press [Enter] now to invoke an editor on /etc/exports [ OK ] Az üzenet fordítása: Üzenet Az NFS szerver mûködtetéséhez elõször az /etc/exports állomány összeállításán keresztül meg kell adnunk, hogy milyen gépek milyen típusú hozzáféréssel rendelkezzenek a helyi állományrendszereinken. Az [Enter] lenyomására megkezdõdik az /etc/exports állomány szerkesztése. [ OK ] Az Enter billentyû lenyomásával továbbléphetünk. Ekkor az exports állomány létrehozására és szerkesztésére egy szövegszerkesztõ indul el.
Az <filename>exports</filename> szerkesztése
A exportálni kívánt állományrendszerek felsorolásához használjuk képernyõn a megadott utasításokat, vagy tegyük meg ezt késõbb az általunk választott szövegszerkesztõ segítségével. Ilyenkor ne felejtsük el megjegyezni az állomány képernyõ alján látható nevét és helyét. Amikor végeztünk, az Esc billentyûvel felhozható menüben alapból az a) leave editor (kilépés a szövegszerkesztõbõl) menüpont aktív, ezért itt a folytatáshoz egyszerûen nyomjuk le az Enter billentyût. Az NFS kliens Az NFS kliens beállításával NFS szerverekhez tudunk hozzáférni. User Confirmation Requested Do you want to configure this machine as an NFS client? Yes [ No ] Fordítás: Felhasználói megerõsítés szükséges Beállítja NFS kliensnek ezt a számítógépet? Igen [ Nem ] A nyílbillentyûkkel igényeinknek megfelelõen válasszuk a &gui.yes; vagy &gui.no; gombokat és utána nyomjuk meg az Enter billentyût. A rendszerkonzol beállításai Számos beállítás kapcsolódik a rendszerben található konzolok testreszabásához. User Confirmation Requested Would you like to customize your system console settings? [ Yes ] No Fordítás: Felhasználói megerõsítés szükséges Testreszabja a rendszerkonzol beállításait? [ Igen ] Nem A beállítások megtekintéséhez és megváltoztatásához válasszuk a &gui.yes; gombot és nyomjuk le az Enter billentyût.
A rendszerkonzol beállításai
A képernyõkímélõ beállítása egy gyakori opció. A nyilak használatával álljunk a Saver menüpontra, majd nyomjuk le az Enter billentyût.
A képernyõkímélõ beállításai
A nyilakkal válasszuk ki a használni kívánt képernyõkímélõt és nyomjuk meg hozzá az Enter billentyût. Ekkor a rendszerkonzol beállításait tartalmazó menü jelenik meg ismét. Az aktivizálódás ideje alapbeállítás szerint 300 másodperc. Ennek megváltoztatásához válasszuk ismét a Saver menüpontot. A képernyõkímélõ beállításait tartalmazó menüben a nyílbillentyûkkel válasszuk a Timeout (Idõkorlát) menüpontot és nyomjuk meg az Enter billentyût. Ekkor egy párbeszédablak jelenik meg:
A képernyõkímélõhöz tartozó idõkorlát beállítása
Miután megváltoztattuk az értéket, a rendszerkonzol beállításához a &gui.ok; gomb kiválasztásával, majd az Enter billentyû lenyomásával térhetünk vissza.
Kilépés a rendszerkonzol beállító menüjébõl
A Exit (Kilépés) választásával és az Enter lenyomásával folytathatjuk tovább a telepítés utólagos beállításait. Az idõzóna beállítása Ha kiválasztjuk számítógépünk számára a megfelelõ idõzónát, akkor lehetõvé tesszük, hogy magától elvégezze a helyi idõhöz kapcsolódó összes szükséges korrekciót és helyesen kezelje az idõzónákhoz kapcsolódó többi funkciót. A példában az Egyesült Államok keleti idõzónájában elhelyezkedõ számítógépet láthatunk. A mi beállításaink természetesen a saját földrajzi helyzetünktõl függenek. User Confirmation Requested Would you like to set this machine's time zone now? [ Yes ] No Fordítás: Felhasználói megerõsítés szükséges Beállítja most a számítógép idõzónáját? [ Igen ] Nem A &gui.yes; gomb és az Enter billentyû segítségével kiválaszthatjuk az idõzóna beállítását. User Confirmation Requested Is this machine's CMOS clock set to UTC? If it is set to local time or you don't know, please choose NO here! Yes [ No ] Fordítás: Felhasználói megerõsítés szükséges A számítógép órája az egységes világidõhöz (UTC) van beállítva? Ha a helyi idõhöz vagy nem tudjuk, akkor itt válasszuk a NEM gombot! Igen [ Nem ] A számítógépünk órájának beállításának megfelelõen válasszuk a &gui.yes; vagy &gui.no; gombot, és nyomjuk meg az Enter billentyût.
A térség kiválasztása
A nyilakkal kiválasztható a megfelelõ térség, amit aztán az Enter billentyûvel tudunk lezárni.
Az ország kiválasztása
A megfelelõ ország a nyílbillentyûkkel, valamint az Enter billentyûvel választható ki.
Az idõzóna kiválasztása
A nekünk megfelelõ idõzóna a nyilakkal választható meg, amit ezután az Enter billentyûvel tudunk jóváhagyni. Confirmation Does the abbreviation 'EDT' look reasonable? [ Yes ] No Az üzenet fordítása: Megerõsítés Ezek szerint az 'EDT' elfogadható? [ Igen ] Nem Erõsítsük meg, hogy az idõzóna helyes-e. Ha rendbenlevõnek látszik, nyomjuk meg az Enter billentyût a folytatáshoz. Linux binárisok használata Ez a rész csak a &os; 7.X telepítésére vonatkozik, &os; 8.X esetén ez a képernyõ nem jelenik meg. User Confirmation Requested Would you like to enable Linux binary compatibility? [ Yes ] No A fordítás: Felhasználói megerõsítés szükséges Engedélyezi a Linux binárisok futtatását? [ Igen ] Nem A &gui.yes; gomb kiválasztásával és az Enter lenyomásával megengedjük, hogy a Linuxra készült szoftvereket futtassunk &os;-n. A telepítõ ennek biztosításához még további csomagokat is fel fog rakni. Ha FTP-n keresztül telepítünk, akkor a számítógépnek csatlakoznia kell az internetre. Ilyenkor elõfordulhat, hogy az FTP szerveren nem találhatóak meg a &linux; kompatibilitással kapcsolatos csomagok. Ezeket azonban késõbb is telepíthetjük. Az egér beállításai Ezen beállítás használatával egy háromgombos egérrel lehetõségünk adódik a konzol és a felhasználói programok között kivágni és bemásolni szövegeket. Kétgombos egér használata esetén nézzük meg a &man.moused.8; man oldalán, miként tudjuk emulálni a háromgombos mûködést. A következõ példa egy nem USB-s (tehát PS/2-es vagy soros portra csatlakozó) egér beállítását illusztrálja: User Confirmation Requested Does this system have a PS/2, serial, or bus mouse? [ Yes ] No Fordítás: Felhasználói megerõsítés szükséges Csatlakozik a rendszeréhez PS/2-es, soros vagy buszos egér? [ Igen ] Nem A PS/2, soros vagy buszos egér használatához válasszuk a &gui.yes; gombot, illetve az USB-s egérhez pedig a &gui.no; gombot, majd nyomjuk meg az Enter billentyût.
Az egér által használt protokoll típusának beállítása
A nyílbillentyûk használatával keressük ki a Type (Típus) menüpontot és nyomjuk le az Enter billentyût.
Az egér protokolljának beállítása
A példában használt egér típusa PS/2, ezért itt a alapértelmezés szerint felkínált Auto megfelelõ. A protokoll megváltoztatásához a nyilakkal válasszunk ki egy másikat. Ezután gondoskodjunk róla, hogy az &gui.ok; gombot választottuk ki és a kilépéshez nyomjuk meg az Enter billentyût.
Az egér portjának beállítása
A nyílbillentyûkkel válasszuk ki a Port menüpontot és nyomjuk meg az Enter billentyût.
Az egér portjának kiválasztása
Mivel a példában szereplõ rendszerhez egy PS/2 egér csatlakozik, ezért az alapértelmezett PS/2 menüpont megfelelõnek tûnik. A port megváltoztatásához használjuk a nyilakat, majd nyomjuk le az Enter billentyût.
Az egérdémon engedélyezése
Befejezésül a egérhez tartozó démon aktiválásához és kipróbálásához válasszuk ki a nyilakkal az Enable (Engedélyezés) menüpontot.
Az egérdémon kipróbálása
Próbáljuk mozgatni a képernyõn megjelenõ egérkurzort, és ellenõrizzük, hogy a kurzor a mozdulatainknak megfelelõen reagál-e. Ha mindent rendben találunk, akkor válasszuk a &gui.yes; gombot és nyomjuk le az Enter billentyût. Ellenkezõ esetben az egeret nem jól állítottuk be — válasszuk a &gui.no; gombot és kísérletezzünk tovább más beállításokkal. Az utólagos beállítások folytatásához válasszuk elõször az Exit (Kilépés) menüpontot, majd nyomjuk meg az Enter billentyût. Csomagok telepítése A csomagok elõre lefordított binárisokat tartalmaznak, és használatukkal igen kényelmesen tudunk szoftvereket telepíteni. Szemléltetés céljából most bemutatjuk az egyik ilyen csomag telepítését. Természetesen igény szerint más csomagokat is hozzávehetünk. A telepítés után a sysinstall parancs használható további csomagok telepítésére. User Confirmation Requested The FreeBSD package collection is a collection of hundreds of ready-to-run applications, from text editors to games to WEB servers and more. Would you like to browse the collection now? [ Yes ] No Az üzenet fordítása: Felhasználói megerõsítés szükséges A FreeBSD csomaggyûjteménye többezernyi azonnal használható alkalmazást tartalmaz, a szövegszerkesztõktõl a játékokon keresztül a WEBszervereken át szinte mindent. Át kívánja lapozni most ezt a gyûjteményt? [ Igen ] Nem A &gui.yes; kiválasztása és az Enter lenyomása után a csomagválasztó képernyõ következik:
A csomagok kategóriájának kiválasztása
Ekkor csak az adott telepítõeszközön elérhetõ csomagok fognak megjelenni. Az összes csomagot az All (Mind) menüpont kiválasztásával láthatjuk, vagy leszûkíthetjük ezt egy adott kategóriára is. Álljunk a kiválasztott kategóriához tartozó menüpontra és nyomjuk meg az Enter billentyût. Ezután egy menü fogja felsorolni az adott kategórián belül telepíthetõ csomagokat:
Csomag kiválasztása
A példában a bash parancsértelmezõt választottuk ki. Válogassunk kedvünkre a csomagok között, és álljunk a telepíteni kívántakra, majd a Szóköz billentyû lenyomásával jelöljük be ezeket. Minden egyes csomag rövid leírása a képernyõ bal alsó sarkában olvasható. A Tab billentyû segítségével mozoghatunk az utoljára kiválasztott csomag, az &gui.ok; és &gui.cancel; gombok között. Miután bejelöltük az összes telepítésre szánt csomagot, a csomagválasztó menübe úgy tudunk visszatérni, ha a Tab billentyûvel átváltunk az &gui.ok; gombra és nyomjuk meg az Enter billentyût. Ezeken felül a bal és jobb nyilak használhatóak az &gui.ok; és &gui.cancel; gombok közti váltásra. Ugyanezzel a módszerrel választható ki az &gui.ok; gomb is, ami után az Enter billentyû megnyomásával visszajutunk a csomagválasztó menübe.
Csomagok telepítése
A nyilakkal és a Tab billentyûvel válasszuk ki az [ Install ] (Telepítés) gombot és nyomjuk meg az Enter billentyût. Ekkor meg kell erõsítenünk a csomagok telepítését:
Csomagok telepítésének megerõsítése
Az &gui.ok; kiválasztása majd az Enter billentyû lenyomása indítja el a csomagok telepítését. A telepítés befejezéséig különbözõ üzenetek fognak megjelenni. Figyeljünk az ilyenkor felbukkanó hibaüzenetekre! A beállítások véglegesítése a csomagok telepítése után folytatódik. Amennyiben egyetlen csomagot sem választottunk és szeretnénk továbblépni, akkor is az Install (Telepítés) gombot válasszuk. Felhasználók és csoportok felvétele A telepítés során legalább egy felhasználót érdemes hozzáadnunk a rendszerhez, mivel a rendszer használatához így nem kell root felhasználóként bejelentkezni. Általánosságban véve ahhoz egyébként is kicsi a gyökérpartíció, hogy root felhasználóként (rendszeradminisztrátorként) futtassunk rajta programokat, és gyorsan be is telik. A nagyobb veszélyt azonban itt olvashatjuk: User Confirmation Requested Would you like to add any initial user accounts to the system? Adding at least one account for yourself at this stage is suggested since working as the "root" user is dangerous (it is easy to do things which adversely affect the entire system). [ Yes ] No Felhasználói megerõsítés szükséges Szeretnénk mosta rendszerbe felvenni felhasználói fiókokat? Ebben a lépésben legalább egy felhasználó felvétele javasolt, hiszen "root" felhasználóként veszélyes dolgozni (mivel így könnyen tehetünk olyan dolgokat, amelyek káros hatással lehetnek rendszerünkre). [ Igen ] Nem Ezért válasszuk a &gui.yes; gombot és az Enter billentyû lenyomásával lépjünk tovább a felhasználók felvételéhez.
Felhasználók kiválasztása
A nyílbillentyûkkel válasszuk ki a User (Felhasználó) menüpontot és nyomjuk meg az Enter billentyût.
A felhasználó adatainak megadása
Amikor a Tab billentyûvel lépkedünk a kitöltendõ mezõk között, a képernyõ alsó részén az alábbi leírások magyarázzák az egyes mezõk tartalmát: Login ID (Bejelentkezési azonosító) Az új felhasználó bejelentkezési neve (kötelezõ). UID (Felhasználói azonosító) A felhasználó számszerû azonosítója (automatikusan létrejön, ha üresen hagyjuk). Group (Csoport) A felhasználó bejelentkezési csoportjának neve (automatikusan létrejön, ha üresen hagyjuk). Password (Jelszó) A felhasználó jelszava (óvatosan bánjunk ezzel a mezõvel!) Full name (Teljes név) A felhasználó teljes neve (megjegyzés). Member groups (További csoportok) A felhasználó ezen csoportoknak is tagja (tehát rendelkezik az engedélyeikkel). Home directory (Felhasználói könyvtár) A felhasználó saját könyvtára (ha üresen hagyjuk, az alapértelmezés szerint töltõdik ki). Login shell (Parancsértelmezõl) A felhasználó által használt parancsértelmezõ (ha üresen hagyjuk, az alapértelmezés szerint töltõdik, mint például /bin/sh). Az ábrán a bejelentkezés után használt parancsértelmezõt a /bin/sh parancsértelmezõrõl a /usr/local/bin/bash parancsértelmezõre változtattuk, így most a korábban telepített bash parancsértelmezõt fogjuk használni. Itt ne is próbáljunk nem létezõ parancsértelmezõt kiválasztani, hiszen ekkor nem tudunk majd bejelentkezni. A BSD világban egyébként a C shell a leggyakrabban használt, amelyet a /bin/tcsh megadásával választhatjuk ki. Az ábrán szereplõ felhasználót ezenkívül még a wheel csoportba is felvettük, aminek köszönhetõen képes lesz a rendszerünkben a root felhasználói jogaival rendelkezõ rendszeradminisztrátorrá válni. Amikor mindent megfelelõnek találunk, nyomjunk az &gui.ok; gombra és ekkor ismét a felhasználók és csoportok karbantartását tartalmazó menü jelenik meg:
Kilépés a felhasználók és csoportok menüjébõl
Csoportokat is létre tudunk hozni, amennyiben erre szükségünk lenne. Ez a rész a telepítés befejezése után továbbra is elérhetõ a sysinstall parancs segítségével. Amikor befejeztük a felhasználók hozzáadását, a nyilakkal válasszuk ki az Exit (Kilépés) menüpontot és a telepítés folytatásához nyomjuk meg az Enter billentyût. A <username>root</username> felhasználó jelszavának megadása Message Now you must set the system manager's password. This is the password you'll use to log in as "root". [ OK ] [ Press enter or space ] Fordítása: Üzenet Most meg kell adnia a rendszergazda jelszavát. Ezt a jelszót kell a "root" felhasználó bejelentkezésekor használni. [ OK ] [ Nyomja le az Enter vagy a Szóköz billentyût ] A root felhasználó jelszavának beállításához nyomjuk meg az Enter billentyût. A jelszót kétszer kell megadnunk. Felesleges megemlíteni, hogy gondoskodjunk arról az esetrõl is, ha véletlenül elfelejtenénk ezt a jelszót. Megemlítjük, hogy az itt begépelt jelszó nem lesz látható és a betûk helyett sem jelennek meg csillagok. New password: Retype new password : A jelszó sikeres megadása után a telepítés folytatódik. Kilépés a telepítõbõl Ha be szeretnénk még állítani egyéb hálózati szolgáltatást vagy valamilyen más konfigurációs lépést kívánunk még elvégezni, ezen a ponton megtehetjük vagy a telepítés után a sysinstall parancs kiadásával. User Confirmation Requested Visit the general configuration menu for a chance to set any last options? Yes [ No ] Fordítás: Felhasználói megerõsítés szükséges Végignézi még utoljára a beállításokat arra az esetre, ha véletlenül kihagytunk volna valamit? Igen [ Nem ] Ha a nyilakkal a &gui.no; gombot választjuk, majd megnyomjuk rajta az Enter billentyût, akkor visszatérünk a telepítõ fõmenüjébe.
Kilépés a telepítõbõl
Válasszuk ki a nyílbillentyûkkel a [X Exit Install] (Kilépés a telepítõbõl) gombot és nyomjuk meg az Enter billentyût. Ezután meg kell erõsítenünk kilépési szándékunkat: User Confirmation Requested Are you sure you wish to exit? The system will reboot. [ Yes ] No Fordítás: Felhasználói megerõsítés szükséges Valóban ki akar lépni? A rendszer ezt követõen újra fog indulni! [ Igen ] Nem Válasszuk a &gui.yes; gombot. Ha CD-meghajtóról indítottuk a telepítést, akkor a következõ üzenet fog figyelmeztetni minket a lemez kivételére: Message Be sure to remove the media from the drive. [ OK ] [ Press enter or space ] Fordítás: Üzenet Ne felejtsük el kivenni a CD-lemezt a meghajtóból. [ OK ] [ Nyomjunk Entert vagy szóközt ] A CD-meghajtó egészen az újraindítás megkezdéséig zárolt lesz, ezért csak ekkor tudjuk (gyorsan) kivenni a meghajtóból a lemezt. Nyomjuk meg az &gui.ok; gombot az újraindításhoz. A rendszer újraindul, legyünk résen és figyeljük a megjelenõ hibaüzeneteket, errõl bõvebben lásd a ban. Tom Rhodes Írta: További hálózati szolgálatások beállítása A hálózati szolgáltatások terén csekély tapasztalattal rendelkezõ kezdõ felhasználók számára ijesztõ lehet ezek beállítása. A hálózatok és többek közt az internet kezelése napjaink modern operációs rendszereink, így a &os;-nek is az egyik fontos területe. Ezért nagyon hasznos ismernünk valamennyire a &os; által felkínált hálózati lehetõségeket. A telepítés közben ezért a felhasználónak tisztában kell lennie a rendelkezésére álló szolgáltatásokkal. A hálózati szolgáltatások olyan programok, amelyek a hálózat minden részérõl fogadnak adatokat. Mindent el kell követnünk annak érdekében, hogy ezek a programok ne tehessenek semmilyen kárt. Sajnos a programozók sem tökéletesek, és az idõk során már elõfordult párszor, hogy a hálózati szolgáltatásokban maradtak hibák, amelyek kihasználásával a támadók rossz dolgokat tudtak csinálni. Ezért fontos, hogy csak is azokat a szolgáltatásokat engedélyezzük, amelyekre ténylegesen szükségünk van. Ha nem tudjuk eldönteni, akkor az a legjobb, ha egészen addig egyiket sem engedélyezzük, amíg valóban szükségünk nem lesz rájuk. A sysinstall újbóli elindításával vagy az /etc/rc.conf megfelelõ beállításával mindig tudunk új szolgáltatásokat aktiválni. A Networking (Hálózatok) menüpont kiválasztása után valami ilyesmit láthatunk:
A hálózati beállítások menüjének felsõ szintje
Ezek közül a Interfaces (Csatolók), vagyis az elsõ menüpontról korábban már szó esett a ban, ezért ez most nyugodtan kihagyható. Az AMD menüpont kiválasztásával engedélyezzük a BSD automatikus csatlakoztatásokért felelõs segédeszközét (AMD, az AutoMounter Daemon). Ezt általában az NFS protokollal (lásd lentebb) együtt szokás használni a távoli állományrendszerek automatikus csatlakoztatásához. Itt nincs szükség semmilyen különleges beállításra. A következõ sorban az AMD Flags (Az AMD beállításai) menüpont szerepel. Kiválasztása után az AMD beállításait bekérõ ablak fog felbukkani. Ez már számos alapértelmezett beállítást tartalmaz: -a /.amd_mnt -l syslog /host /etc/amd.map /net /etc/amd.map A kapcsolóval adjuk meg a csatlakozási pontok alapértelmezett helyét, amely ebben az esetben az /.amd_mnt. A kapcsolóval adjuk meg az alapértelmezett log (napló) állományt, habár a syslogd használata során az összes naplózási tevékenység a rendszer naplózó démonján fut majd keresztül. A /host könyvtárba fognak csatlakozni a távoli gépek exportált állományrendszerei, míg a /net könyvtárba a különbözõ IP-címekrõl exportált állományrendszerek kerülnek csatlakoztatásra. Az /etc/amd.map állomány tartalmazza az AMD exportjainak alapértelmezett beállításait. FTP anonim Az Anon FTP menüponton keresztül engedélyezhetjük az anonim FTP kapcsolatokat. A menüpont kiválasztásával számítógépünket egy anonim FTP szerverré tehetjük, azonban legyünk tekintettel a beállításhoz tartozó biztonsági veszélyekre! A kiválasztásakor egy ablak tájékoztat minket a beállítás részleteirõl és felmerülõ biztonsági kockázatokról. A Gateway (Átjáró) menüpont használatával a korábbiakban tárgyaltak szerint állíthatjuk be számítógépünket hálózati átjárónak. Ugyanekkor a Gateway menüben nyílik lehetõségük kikapcsolni ezt a beállítást, amennyiben a telepítési folyamat korábbi lépései során véletlenül engedélyeztük volna. Az Inetd menüpont segítségével beállíthatjuk, vagy akár teljesen ki is kapcsolhatjuk a korábban tárgyalt &man.inetd.8; démont. A Mail (Levelezés) menüpontban beállíthatjuk a rendszer alapértelmezett MTA avagy levéltovábbító ügynökét (Mail Transfer Agent). Ennek hatására a következõ menü jelenik meg:
Az alapértelmezett MTA kiválasztása
Itt válaszhatunk, hogy a különbözõ levélküldõ rendszerek közül melyiket telepítsük alapértelmezettként. Egy ilyen alkalmazás lényegében nem több, mint egy levélküldésre használt szerver, amely továbbítja a rendszerben vagy az interneten található felhasználók számára a leveleket. A Sendmail választásával a &os; alapból felkínált megoldását, a népszerû sendmail szervert telepíthetjük. A Sendmail local (Helyi Sendmail) menüpont kiválasztásával szintén a sendmail lesz a telepítendõ levélküldõ szerver, azonban nem lesz képes az internetrõl érkezõ leveleket fogadni. Az itt felsorolt többi beállítás, tehát a Postfix és Exim, a Sendmail beállításához hasonlóan zajlik. Mind a kettõ elektronikus levelek kézbesítésére használható, azonban bizonyos felhasználók a sendmail helyett inkább ezek valamelyikét használják. Valamelyik vagy éppen semelyik levéltovábbító szerver kiválasztása után az NFS client (NFS kliens) beállítására vonatkozó menü jelentkezik. Az NFS client beállításával a rendszerünk NFS szerverekkel lesz képes kapcsolatba lépni. Egy ilyen NFS szerver az NFS protokoll segítségével a hálózaton keresztül elérhetõvé tesz állományrendszereket. Ha gépünk független, akkor nem fontos kiválasztanunk ezt a menüpontot. A rendszernek késõbb további beállításokra is szüksége lehet, amelyekrõl az ban olvashatunk részletesebben. Az NFS server (NFS szerver) menüpont kiválasztásával hozzájárulunk, hogy rendszerünk NFS szerverként üzemeljen. Ehhez meg kell adnunk az RPC, vagyis a távoli eljáráshívások kiszolgálásának elindításához szükséges adatokat is. Az RPC használatával a különbözõ kiszolgálók és programok között tudjuk vezérelni a kapcsolatot. A sorban az Ntpdate beállítása következik, ahol az idõszinkronizációhoz kapcsolódó opciókat találjuk. Kiválasztásakor az ábrán szereplõhöz hasonló menü fog megjelenni:
Az Ntpdate beállítása
Ebbõl a menübõl válasszuk ki a hozzánk legközelebb levõ szevert. Egy közeli szerver megadásával az idõszinkronizáció sokkalta pontosabbá válik, mivel a tõlünk távolabbi szerverek kapcsolatának késleltetése nagyobb lehet. A következõ beállítás az PCNFSD. Ennek kiválasztása során a Portgyûjteménybõl telepítésre kerül a net/pcnfsd csomag. Ez lényegében egy hasznos segédprogram, amellyel olyan operációs rendszerek számára tudunk hitelesítést szolgáltatni az NFS használata során, amelyek maguktól erre nem képesek, mint például a µsoft; &ms-dos; rendszere. A többi beállítás megtekintéséhez egy kicsit lejjebb kell haladnunk a listában:
A hálózati beállítások menüjének alsó szintje
Az &man.rpcbind.8; és &man.rpc.statd.8;, valamint az &man.rpc.lockd.8; segédprogramok mind a távoli eljáráshívásokhoz (Remote Procedure Call, RPC) használhatóak. Az rpcbind segédprogram az NFS szerverei és kliensei között felügyeli a kapcsolatot, ezért a használata az NFS szerverek és kliensek mûködéséhez elengedhetetlen. Az állapot figyeléséhez az rpc.statd démon felveszi a kapcsolatot a többi gépen futó rpc.statd démonokkal. A jelentett állapotok általában a /var/db/statd.status állományban találhatóak. Itt a következõként felsorolt elem az rpc.lockd, amelynek kiválasztásával állományzárolási szolgáltatásokat érhetünk el. Ezt többnyire az rpc.statd démonnal együtt alkalmazzák a zárolásokat kérõ gépek és a kérések gyakoriságának nyilvántartására. Míg ezekkel a beállításokkal gyönyörûen nyomon lehet követni a mûködést, az NFS szerverek és kliensek megfelelõ mûködéséhez nem kötelezõ a használatuk. Ahogy haladunk tovább a listában, a következõ elem a Routed, vagyis az útválasztásért felelõs démon lesz. A &man.routed.8; segédprogram a hálózati útválasztó táblázatokat tartja karban, felderíti az elérhetõ útválasztókat és kérésre bármelyik hozzá fizikailag csatlakozó gép számára átadja az általa nyilvántartott útválasztási adatokat. Ezt leginkább a helyi hálózat átjárójaként mûködõ számítógépek használják. Kiválasztásakor egy ablak fog rákérdezni a segédprogram helyére. Az itt alapból felkínált érték általában megfelelõ, ezért nyugtázhatjuk az Enter billentyû lenyomásával. Ezt követõen egy másik menü jelenik meg, ahol a routed beállításait adhatjuk meg. Itt alapértelmezés szerint a kapcsoló szerepel. A következõ sor az Rwhod beállításé, aminek kiválasztásával el tudjuk indíttatni az &man.rwhod.8; démont a rendszer elindítása során. Az rwhod segédprogram a rendszerüzeneteket a hálózaton idõközönként szétküldi vagy figyelõ (consumer) módban összegyûjti ezeket. Ennek pontosabb részleteit az &man.ruptime.1; és &man.rwho.1; man oldalakon találhatjuk meg. Az &man.sshd.8; démoné az utolsó elõtti beállítás. Ez az OpenSSH biztonságos shell szervere, melyet a szabványos telnet és FTP szerverek helyett ajánlanak. Az sshd szerver tehát két gép közti biztonságos, titkosított kapcsolatok létrehozására használható. A lista végén a TCP Extensions (TCP kiterjesztések) menüpontot találhatjuk. Segítségével a TCP RFC 1323 és RFC 1644 dokumentumokban leírt kiterjesztéseinek használatát engedélyezhetjük. Ezzel egyes gépek esetén felgyorsulhat a kapcsolat, azonban más esetekben pedig eldobódhat. Ez szerverek használatánál nem ajánlott, viszont független gépeknél kifizetõdõ lehet. Most, miután beállítottuk a hálózati szolgáltatásokat, lépjünk vissza a lista elején található X Exit (Kilépés) menüpontra és folytassuk a beállítást a következõ opcióval, vagy egyszerûen az X Exit kétszeri kiválasztásával, majd a [X Exit Install] (Kilépés a telepítõbõl) gomb lenyomásával lépjünk ki a sysinstall programból. A &os; indulása A &os;/&arch.i386; indulása Ha minden remekült ment, a képernyõn lentrõl felfelé gördülõ üzeneteket fogunk látni, majd a rendszer várni fog tõlünk egy bejelentkezési nevet. A kiírt üzeneteket között a Scroll Lock lenyomása után a PgUp és PgDn billentyûk használatával tudunk lapozni. A Scroll Lock ismételt lenyomásával visszatérünk a bejelentkezéshez. Nem minden esetben lesz látható az összes üzenet (a puffer végessége miatt), de miután bejelentkeztünk, ezeket a dmesg parancs kiadásával is megnézhetjük. Bejelentkezni a telepítéskor megadott felhasználói név/jelszó párossal tudunk (a példában ez most rpratt). Lehetõleg ne jelentkezzünk be root felhasználóként! A rendszer indításakor jellemzõen elõforduló üzenetek (a verzióra vonatkozó adatokat kihagytuk): Copyright (c) 1992-2002 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. Timecounter "i8254" frequency 1193182 Hz CPU: AMD-K6(tm) 3D processor (300.68-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x580 Stepping = 0 Features=0x8001bf<FPU,VME,DE,PSE,TSC,MSR,MCE,CX8,MMX> AMD Features=0x80000800<SYSCALL,3DNow!> real memory = 268435456 (262144K bytes) config> di sn0 config> di lnc0 config> di le0 config> di ie0 config> di fe0 config> di cs0 config> di bt0 config> di aic0 config> di aha0 config> di adv0 config> q avail memory = 256311296 (250304K bytes) Preloaded elf kernel "kernel" at 0xc0491000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc049109c. md0: Malloc disk Using $PIR table, 4 entries at 0xc00fde60 npx0: <math processor> on motherboard npx0: INT 16 interface pcib0: <Host to PCI bridge> on motherboard pci0: <PCI bus> on pcib0 pcib1: <VIA 82C598MVP (Apollo MVP3) PCI-PCI (AGP) bridge> at device 1.0 on pci0 pci1: <PCI bus> on pcib1 pci1: <Matrox MGA G200 AGP graphics accelerator> at 0.0 irq 11 isab0: <VIA 82C586 PCI-ISA bridge> at device 7.0 on pci0 isa0: <ISA bus> on isab0 atapci0: <VIA 82C586 ATA33 controller> port 0xe000-0xe00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: <VIA 83C572 USB controller> port 0xe400-0xe41f irq 10 at device 7.2 on pci0 usb0: <VIA 83C572 USB controller> on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered chip1: <VIA 82C586B ACPI interface> at device 7.3 on pci0 ed0: <NE2000 PCI Ethernet (RealTek 8029)> port 0xe800-0xe81f irq 9 at device 10.0 on pci0 ed0: address 52:54:05:de:73:1b, type NE2000 (16 bit) isa0: too many dependant configs (8) isa0: unexpected small tag 14 fdc0: <NEC 72065B or clone> at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: <keyboard controller (i8042)> at port 0x60-0x64 on isa0 atkbd0: <AT Keyboard> flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: <PS/2 Mouse> irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 sc0: <System console> at flags 0x1 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A ppc0: <Parallel port> at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/15 bytes threshold ppbus0: IEEE1284 device found /NIBBLE Probing for PnP devices on ppbus0: plip0: <PLIP network interface> on ppbus0 lpt0: <Printer> on ppbus0 lpt0: Interrupt-driven port ppi0: <Parallel I/O> on ppbus0 ad0: 8063MB <IBM-DHEA-38451> [16383/16/63] at ata0-master using UDMA33 ad2: 8063MB <IBM-DHEA-38451> [16383/16/63] at ata1-master using UDMA33 acd0: CDROM <DELTA OTC-H101/ST3 F/W by OIPD> at ata0-slave using PIO4 Mounting root from ufs:/dev/ad0s1a swapon: adding /dev/ad0s1b as swap device Automatic boot in progress... /dev/ad0s1a: FILESYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s1a: clean, 48752 free (552 frags, 6025 blocks, 0.9% fragmentation) /dev/ad0s1f: FILESYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s1f: clean, 128997 free (21 frags, 16122 blocks, 0.0% fragmentation) /dev/ad0s1g: FILESYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s1g: clean, 3036299 free (43175 frags, 374073 blocks, 1.3% fragmentation) /dev/ad0s1e: filesystem CLEAN; SKIPPING CHECKS /dev/ad0s1e: clean, 128193 free (17 frags, 16022 blocks, 0.0% fragmentation) Doing initial network setup: hostname. ed0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 inet6 fe80::5054::5ff::fede:731b%ed0 prefixlen 64 tentative scopeid 0x1 ether 52:54:05:de:73:1b lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x8 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 Additional routing options: IP gateway=YES TCP keepalive=YES routing daemons:. additional daemons: syslogd. Doing additional network setup:. Starting final network daemons: creating ssh RSA host key Generating public/private rsa1 key pair. Your identification has been saved in /etc/ssh/ssh_host_key. Your public key has been saved in /etc/ssh/ssh_host_key.pub. The key fingerprint is: cd:76:89:16:69:0e:d0:6e:f8:66:d0:07:26:3c:7e:2d root@k6-2.example.com creating ssh DSA host key Generating public/private dsa key pair. Your identification has been saved in /etc/ssh/ssh_host_dsa_key. Your public key has been saved in /etc/ssh/ssh_host_dsa_key.pub. The key fingerprint is: f9:a1:a9:47:c4:ad:f9:8d:52:b8:b8:ff:8c:ad:2d:e6 root@k6-2.example.com. setting ELF ldconfig path: /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 standard daemons: inetd cron sshd usbd sendmail. Initial rc.i386 initialization:. rc.i386 configuring syscons: blank_time screensaver moused. Additional ABI support: linux. Local package initialization:. Additional TCP options:. FreeBSD/i386 (k6-2.example.com) (ttyv0) login: rpratt Password: Az RSA és DSA kulcsok generálása a lassabb gépeken sokág is eltarthat, habár ez mindig csak a friss telepítések utáni elsõ indításkor történik meg. A rendszer késõbbi indulásai ettõl már gyorsabbak lesznek. Ha X szervert is beállítottunk és választottunk hozzá egy alapértelmezett munkakörnyezetet, akkor ezt a parancssorból a startx kiadásával elindíthatjuk el. A &os; leállítása Fontos, hogy mindig szabályosan állítsuk le az operációs rendszert, ne kapcsoljuk ki csak úgy egyszerûen a számítógépünket! A leállításhoz elõször a su parancs kiadásával, majd itt a root jelszavának megadásával vegyük fel az ehhez szükséges rendszeradminisztrátori jogosultságokat. Ez viszont csak abban az esetben fog mûködni, ha a felhasználónk tagja a wheel csoportnak. Minden más esetben egyszerûen jelentkezzünk be root felhasználóként és használjuk a shutdown -h now parancsot. The operating system has halted. Please press any key to reboot. A fenti üzenet jelzi, hogy a leállító parancs kiadása után már kikapcsolhatjuk a számítógépet, vagy ha ehelyett egy billentyût nyomunk le, akkor a gép újraindul. A Ctrl Alt Del billentyûkombináció használatával is újra tudjuk indítani a rendszert, azonban ez normál mûködés közben nem ajánlott. Hibakeresés telepítés hibakeresés A most következõ szakaszban azokra a telepítés során felmerülõ problémákra próbálunk meg megoldásokat adni, amelyeket eddig már sokan jeleztek nekünk. Ezek mellett szerepel néhány kérdés és válasz is a &os; és az &ms-dos; vagy &windows; közös használatáról. Mit tegyünk ha valami nem mûködik A PC architektúra különféle korlátozásai miatt szinte lehetetlen 100%-ban megbízhatóvá tenni az eszközök felderítését, azonban ennek hibája kapcsán néhány dolgot még tenni tudunk. Ellenõrizzük a Hardware Notes (Hardverjegyzék) címû dokumentumban, hogy az adott hardvert a &os; valóban ismeri. Amennyiben a hardvereszközünket a rendszer ismeri, azonban még mindig jelentkeznek fagyások vagy egyéb gondok, készítenünk kell egy saját rendszermagot. Ezzel olyan eszközök támogatását is beépíthetjük a rendszermagba, amelyek eredetileg nem szerepelnek a GENERIC rendszermagban. A telepítéshez készített rendszerindító lemezeken található rendszermag a legtöbb eszközt a gyári IRQ, IO-cím és DMA csatorna beállításaik mentén próbálja felkutatni. Ha viszont a hardverünket átállítottuk, ennek megfelelõen módosítanunk kell a rendszermag beállításait és újra kell fordítanunk, hogy a &os; tudja, hol is keresse az eszközt. Olyan is adódhat, hogy egy nem létezõ eszköz keresése egy utána keresendõ másik, jelenlevõ eszköz felkutatását akadályozza meg. Ilyenkor az ütközõ meghajtókat le kell tiltani. Egyes problémák elkerülhetõek vagy csillapíthatóak a különbözõ hardverösszetevõk, különösen az alaplapi firmware frissítésével. Az alaplap firmware-jére sokszor csak BIOS-ként hivatkoznak, és a legtöbb alaplap- vagy számítógépgyártó honlapján találhatjuk meg ezeket, valamint a rájuk vonatkozó utasításokat. A legtöbb gyártó azonban erõsen tiltakozik az alaplapi BIOS-frissítések ellen, és csak indokolt esetekben, például kritikus javításoknál javasolják. A frissítés kimenetele lehet rossz is, aminek következménye a BIOS tartós károsodása. Az &ms-dos; és &windows; állományrendszereinek használata A &os; jelenleg nem támogatja a Double Space™ alkalmazással tömörített állományrendszereket, ezért a &os; csak úgy tud az adataihoz hozzáférni, ha elõtte kitömörítjük ezeket. Ezt a Start menü Programs (Programok) > System Tools (Rendszereszközök) menüjében található Compression Agent (Lemeztömörítés) elindításával tehetjük meg. A &os; támogatja az &ms-dos; alapú (gyakran csak FAT típusúnak nevezett) állományrendszereket. A &man.mount.msdosfs.8; parancs segítségével az ilyen rendszerek könnyedén becsatlakoztathatók a már létezõ könyvtárszerkezetbe, amivel így el tudjuk érni a tartalmát. A &man.mount.msdosfs.8; programot általában nem közvetlenül hívjuk meg, hanem az /etc/fstab vagy a &man.mount.8; segédprogram megfelelõ paraméterezésével. Az /etc/fstab állományban általában így néz ki egy ilyen sor: /dev/ad0sN /dos msdosfs rw 0 0 A mûvelet végrehajtásához a /dos könyvtárnak már léteznie kell. Az /etc/fstab pontos formátumával kapcsolatban a &man.fstab.5; man oldalt olvassuk el. Az &ms-dos; állományrendszerek esetében a &man.mount.8; parancsot többnyire így adjuk ki: &prompt.root; mount -t msdosfs /dev/ad0s1 /mnt Ebben a példában a &ms-dos; állományrendszer az elsõdleges merevlemez elsõ partícióján helyezkedik el. A mi helyzetünk ettõl eltérõ lehet, ezért ehhez vizsgáljuk meg a dmesg és mount parancsok kimeneteit. Segítségükkel elegendõ információt tudunk összeszedni a gépünkön található partíciók kiosztásáról. Elõfordulhat, hogy a &os; a többi operációs rendszertõl eltérõ módon számozza a slice-okat (vagyis az &ms-dos; partíciókat). Konkrétan: a kiterjesztett &ms-dos; partíciók általában nagyobb sorszámot kapnak, mint az elsõdleges &ms-dos; partíciók. Az &man.fdisk.8; segédprogram segíthet megállapítani, hogy mely slice-ok tartoznak a &os;-hez és melyek más operációs rendszerekhez. A &man.mount.ntfs.8; parancs használatával az NTFS partíciók hasonló módon csatlakoztathatóak. Kérdések és válaszok A rendszerem teljesen leáll amikor az indítás során eszközöket próbál megtalálni, vagy furcsán viselkedik a telepítés során, esetleg a floppy meghajtót nem is keresi. A &os; az i386, amd64 és ia64 platformokon az indítás közben az eszközök felderítésében erõsen építkeznek a rendszeren elérhetõ ACPI szolgáltatásra. Sajnos még mindig vannak hibák az ACPI meghajtóban, az alaplapokban és a BIOS-okban. A rendszerbetöltõ harmadik fokozatában viszont az hint.acpi.0.disabled megadásával kikapcsolható az ACPI használata: set hint.acpi.0.disabled="1" Ez a beállítás a rendszer minden egyes indításakor törlõdik, ezért a hint.acpi.0.disabled="1" bejegyzést fel kell vennünk a /boot/loader.conf állományba. A rendszerbetöltõ mûködésérõl részletesebben a ban olvashatunk. A &os; telepítése után elõször indítom el a merevlemezrõl a rendszert, a rendszermag betöltõdik és nekilát felkutatni a hardvereszközöket, azonban megáll a következõ üzenettel: changing root device to ad1s1a panic: cannot mount root Mi lehet a gond? Mit tegyek? Mit jelent a bios_drive:interface(unit,partition)kernel_name a rendszerindítás során megjelenõ súgóban? Ez egy régóta fennálló probléma olyan rendszerek esetén, ahol a rendszerindításhoz használt lemez nem az elsõ. A BIOS a &os;-tõl eltérõ sorszámozást használ, és az általa alkalmazott megfeleltetések megfejtése nehézkes. Amikor a rendszer indítására használt lemez nem az elsõ lemez a rendszerünkben, segítenünk kell a &os;-nek a megtalálásában. Két gyakori helyzet alakulhat ki, és mind a kettõben el kell árulnunk a &os;-nek, hogy hol található a rendszer indításához használható gyökér állományrendszer. Ezt a lemez BIOS-ban nyilvántartott sorszámának, típusának és a neki megfelelõ &os; szerinti lemezszám megadásával tehetjük meg. Az elsõ szituációban két IDE-lemezünk van, mind a kettõt masterként állítottuk be a hozzájuk tartozó IDE-buszokon, és a közülük a másodikról akarjuk indítani a &os;-t. A BIOS ezeket 0. és 1. lemezként látja, miközben a &os; pedig ad0 és ad2 eszközként. A &os; 1. BIOS-számozású lemezen van, amelynek a típusa ad és a &os; szerinti a 2 sorszámot viseli. Ezért ezt kell használnunk: 1:ad(2,a)kernel Ha az elsõdleges buszon van egy slave meghajtónk, akkor mindez nem szükséges (és valószínûleg rossz is). A második szituációban egy SCSI-lemezrõl akarjuk indítani a rendszert, miközben egy vagy több IDE-lemez is található a gépünkben. Ebben az esetben a &os; szerinti sorszám kisebb lesz, mint a BIOS szerinti. Ha tehát a két IDE-lemezünk mellett van még egy SCSI-lemez is, akkor annak a BIOS szerinti sorszáma 2, a típusa da és a &os; szerinti sorszáma pedig 0. Ennek megfelelõen a 2:da(0,a)kernel sorral tudjuk elárulni a &os;-nek, hogy a BIOS szerint 2. lemezrõl akarjuk indítani, amely a rendszerben található elsõ SCSI-lemeznek felel meg. Ha csak egy IDE-lemezünk van, akkor a sort kezdjük az 1: beírásával. Miután megtaláltuk a megfelelõ értékeket, a hozzá tartozó sort egy szövegszerkesztõ segítségével tegyük közvetlenül a /boot.config állományba. A &os; ezen állomány tartalmát fogja alapból felhasználni a boot: bekérésénél, hacsak másképpen nem utasítjuk. A telepítés után elõször próbálom meg elindítani a merevlemezrõl a &os;-t, azonban a rendszerválasztó mindig csak F? opciókat kínál fel, és a rendszer indítása sem halad tovább. A &os; telepítése során rosszul adtunk meg a partíciószerkesztõben a merevlemezhez tartozó geometriát. Menjünk vissza a partíciószerkesztõhöz és adjuk meg újra a merevlemezünk helyes geometriáját. Ennek használatához pedig a &os;-t is újra kell telepítenünk. Ha egyáltalán képtelenek vagyunk megállapítani a merevlemezhez tartozó geometriát, akkor próbáljuk meg ezt: a lemez elején hozzunk létre egy kis méretû DOS partíciót és rakjuk utána a &os;-t. Amikor a telepítõprogram észreveszi a DOS partíciót, megpróbálja magától kikövetkeztetni belõle a helyes geometriát, ami általában mûködik is. Ez a tanács ugyan már nem érvényes, de álljon itt felvilágosításként:
Ha teljesen egy &os; alapú szerver vagy munkaállomás kialakítására szánjuk a számítógépünket, és nem törõdünk a DOS-szal, Linuxszal és a többi operációs rendszerrel történõ (jövõbeli) kompatibilitással, használhatjuk akár az egész lemezt is (a partíciószerkesztõben ez az A opció). Ezzel egy olyan nem szabványos beállítást engedélyezünk, amivel a &os; elfoglalja a lemezt annak legelsõ szektorától a legutolsó szektoráig. Ilyenkor ugyan el tudunk tekinteni a geometriával kapcsolatos beállításoktól, azonban így a &os;-n kívül semmilyen más operációs rendszert nem tudunk majd futtatni a gépen.
A rendszer megtalálja a &man.ed.4; hálózati kártyámat, azonban folyamatosan hibát ad idõtúllépésre hivatkozva. Az említett kártya valószínûleg a /boot/device.hints állományban beállítottaktól eltérõ IRQ-t használ. A &man.ed.4; meghajtó alapértelmezés szerint nem használ szoftveres beállításokat (amiket DOS-ban az EZSETUP használatával adunk meg), viszont engedélyezhetjük, ha a kártyánál megadjuk az -l beállítást. Hardveresen ezt a kártyán levõ jumperek segítségével állíthatjuk be (ehhez változtassuk meg a rendszermag beállításait is, amennyiben szükséges), vagy a -l kapcsolón keresztül a hint.ed.0.irq="-l" megadásával utasíthatjuk a rendszermagot az IRQ szoftveres beállítására. Másik lehetõség, amikor a kártyánk a 9-es IRQ-t használja, amelyet általában megosztanak a 2-es IRQ-val, ami gyakori problémák forrása (különösen abban az esetben, amikor a VGA kártya a 2-es IRQ-t használja!) lehet. Lehetõleg ne használjuk a 2-es és 9-es IRQ-kat. színek kontraszt Amikor a sysinstall programot egy X11 terminálban futtatom, a sárga színû betûket viszonylag nehéz olvasni a világosszürke háttérrel. Esetleg lehet valahogy növelni a kontrasztot az alkalmazás használatakor? Ha az X11 telepítése után a sysinstall által választott színekkel nem olvasható a szöveg &man.xterm.1; vagy &man.rxvt.1; terminálokban, akkor vegyük fel a következõ sort a felhasználói könyvtárunkban levõ .Xdefaults konfigurációs állományunkba: XTerm*color7:#c0c0c0. Ezzel majd egy sötétebb szürke hátteret kapunk. Valentino Vaschetto Írta: Marc Fonvieille Frissítette: Telepítési útmutató haladóknak Ebben a szakaszban megtudhatjuk, hogyan telepítsük a &os;-t speciális esetekben. A &os; telepítése billentyûzet vagy monitor nélkül telepítés fej nélküli (soros konzol) soros konzol A telepítés ezen fajtáját fej nélküli telepítésnek (headless install) hívják, mivel a gép, amire a &os;-t telepíteni akarjuk, nem rendelkezik monitorral vagy éppen még VGA kimenettel sem. Felmerülhet a kérdés: hogyan lehetséges mindez? A soros vonali konzol használatával! A soros konzol segítségével lényegében egy másik számítógép monitorját és billentyûzetét használjuk. Ennek megvalósításához elsõként kövessük a rendszerindító pendrive készítésének ban leírt lépéseit, vagy töltsük le a megfelelõ ISO image-et a telepítéshez, lásd . A következõ lépésekkel tehetjük képessé a soros konzolon keresztüli rendszerindításra: (CD-lemez használata esetén az elsõ lépésre nincs szükség) A rendszerindító pendrive átállítása soros konzolra mount Ha a korábban elõkészített pendrive-val most csak egyszerûen elindítanánk a &os;-t, akkor a megszokott telepítési módban indulna el. Mi viszont azt akarjuk, hogy a telepítéshez a &os; a soros konzolon keresztül induljon el. Ehhez csatlakoztassuk az eszközt a számítógéphez, valamint a &man.mount.8; paranccsal &os; rendszerünkhöz pedig a hozzátartozó állományrendszert. &prompt.root; mount /dev/da0a /mnt A konkrét eszköznevet és csatlakozási pontot módosítsuk a saját környezetünknek megfelelõen. Most, miután már fizikailag és logikailag is csatlakoztattuk a pendrive-ot, be kell állítanunk a soros konzol használatára rendszerindítás közben. Ehhez egy loader.conf nevû állományt kell elhelyeznünk a pendrive állományrendszerén a soros konzolra (mint rendszerkonzolra) vonatkozó beállítással: &prompt.root; echo 'console="comconsole"' >> /mnt//boot/loader.conf Miután a pendrive-on sikeresen elvégeztük a szükséges beállítást, válasszuk le a &man.umount.8; parancs kiadásával: &prompt.root; umount /mnt Most már leválaszthatjuk a pendrive-ot, és ugorjunk közvetlenül a harmadik lépésre. A null-modem kábel csatlakoztatása null-modem kábel Össze kell kötnünk a két számítógépet egy null-modem kábellel. Nincs más teendõnk, mit összekapcsolni a két gép soros portjait. Itt a szokásos soros kábel nem mûködik, konkrétan null-modem kábelre van szükség, mivel benne néhány vezetéket máshogy kötöttek be. A telepítõ CD beállítása soros konzolra mount Ha a telepítésre szánt ISO image-bõl készített lemezzel (lásd ) a &os; normál módban indul el. A soros konzol használatához viszont kibontani, módosítani és újragenerálni kell az adott image-et mielõtt lemezre írnánk. A korábban, például a &os;-8.1-RELEASE-i386-disc1.iso néven letöltött image-bõl a &man.tar.1; segédprogrammal tudjuk kinyerni a benne tárolt összes állományt: &prompt.root; mkdir /a/hasznalt/iso/helye &prompt.root; tar -C /a/hasznalt/iso/helye -pxvf &os;-8.1-RELEASE-i386-disc1.iso Ezt követõen módosítanunk kell a telepítõlemezt a soros konzol használatára. Ehhez egy loader.conf állományt kell hozzáadnunk a kibontott ISO image tartalmához. Ebben állítjuk be a soros konzolt rendszerkonzolnak: &prompt.root; echo 'console="comconsole"' >> /a/hasznalt/iso/helye/boot/loader.conf Ezután készítsünk egy új ISO image-et a módosított tartalom alapján. Ehhez a sysutils/cdrtools port részeként elérhetõ &man.mkisofs.8; segédprogramot használjuk: &prompt.root; mkisofs -v -b boot/cdboot -no-emul-boot -r -J -V "soroskonzolos" -o soroskonzolos-&os;-8.1-RELEASE-i386-disc1.iso /a/hasznalt/iso/helye Most már van egy megfelelõen összeállított ISO image-ünk, amelyet CD-lemezre tudunk írni a kedvenc CD-író alkalmazásunkkal. A telepítés indítása Most már ideje elkezdeni a telepítést. Tegyük a boot.flp image-et tartalmazó lemezt a fej nélkül telepítendõ gép meghajtójába és kapcsoljuk be. Kapcsolódás a fej nélküli gépre cu Ezután a &man.cu.1; parancs felhasználásával kapcsolódjunk rá a gépre: &prompt.root; cu -l /dev/cuau0 Ezt &os; 7.X esetén így kell használnunk: &prompt.root; cu -l /dev/cuad0 Ezzel készen is vagyunk! Innentõl a cu által megnyitott kapcsolaton keresztül tudjuk vezérelni a fej nélküli számítógépet. Hamarosan betölti a rendszermagot, majd megkérdezi a használt terminál típusát. Itt válasszuk ki a színes &os; konzolt (&os; color console) és folytassuk a telepítést a megszokott módon. Saját telepítõeszköz elkészítése Az ismétlések elkerülése végett a továbbiakban a &os; lemez a megvásárolható vagy a magunk által készített &os; CD-re vagy DVD-re vonatkozik. Adódhatnak olyan esetek, amikor létre kell hoznunk a &os; telepítésére használt saját eszközünket és/vagy forrásunkat. Ez lehet egy tetszõleges fizikai eszköz, például szalag, vagy bármilyen olyan forrás, ahonnan a sysinstall képes állományokat elérni, például egy FTP oldal vagy egy &ms-dos; partíció. Például: Egy &os; lemezünk van és több hálózaton kapcsolódó számítógépünk. Készíteni akarunk egy helyi FTP oldalt a &os; lemez felhasználásával, és így a hálózaton levõ gépre az internet helyett innen telepítjük a rendszert. Van egy &os; lemezünk, azonban a &os;-nek nem sikerült felismernie a CD/DVD-meghajtónkat, viszont az &ms-dos;/&windows;-nak igen. Felmásoljuk a &os; telepítéséhez használt állományokat ugyanazon a számítógépen található egyik DOS partícióra, majd a &os;-t ezekkel telepítjük. A gépben, amelyre telepíteni akarunk, nincs CD/DVD-meghajtó vagy hálózati kártya, viszont Laplink stílusú soros vagy párhuzamos kábellel hozzá tudunk kapcsolódni egy olyan számítógéprõl, amelyben viszont van. Készíteni akarunk a &os; telepítésére használható szalagot. Telepítõ CD készítése A &os; Projekt minden kiadás részeként architektúránként elérhetõvé tesz legalább két CD image-et (ISO image-et). Ha rendelkezünk CD-íróval, ezeket az image-eket fel-, illetve ki tudjuk írni (égetni) CD-re, és a &os; telepítésére tudjuk használni. Tehát ha van a kezünk ügyében CD-író és olcsón jutunk nagyobb sebességû interneteléréshez, akkor a &os; telepítésének ez a legkönnyebb módja. A megfelelõ ISO image-ek letöltése Az egyes kiadások ISO image-ei letölthetõek a ftp://ftp.FreeBSD.org/pub/FreeBSD/ISO-IMAGES-architektúra/változat címrõl vagy annak legközelebbi tükrözésérõl. Az architektúra és változat részeket igényeinknek megfelelõen helyettesítsük. Az említett könyvtár általában a következõ lemezek image-eit tartalmazza: FreeBSD 7.<replaceable>X</replaceable> és 8.<replaceable>X</replaceable> ISO image-ek nevei és jelentései Állománynév Tartalom &os;-változat-RELEASE-architektúra-bootonly.iso Ezzel a CD image-dzsel tudjuk a &os; CD-meghajtóról indításával elkezdeni a telepítést. Fontos tudnunk azonban, hogy ez az image nem tartalmazza a &os; telepítéséhez szükséges komponenseket. Ezt a rendszer indítása után hálózaton keresztül (például egy FTP szerver segítségével) tudjuk megtenni. &os;-változat-RELEASE-architektúra-dvd1.iso.gz Ez a DVD image minden, az alap &os; rendszer telepítéséhez szükséges komponenst tartalmaz, bináris csomagokkal és dokumentációval együtt. Ezenkívül még élõ rendszert is tudunk indítani vele, közvetlenül a lemezrõl. &os;-változat-RELEASE-architektúra-memstick.img Ez az image egy USB pendrive-ra írható, és minden olyan számítógépen használható, amely képes ilyen eszközrõl elindulni. Támogatja az élõ módot is, amellyel rendszerünket állíthatjuk helyre. Ez az image nem érhetõ el &os; 7.3 vagy korábbi rendszerek esetén. &os;-változat-RELEASE-architektúra-disc1.iso Ez az image tartalmazza az alap &os; operációs rendszert és a hozzá tartozó dokumentációt, de semmilyen más további csomagot nem. &os;-változat-RELEASE-architektúra-disc2.iso Ezen az image-en bináris csomagok találhatóak. Ilyen a &os; 8.0 és az utána következõ változatoknál már nincs. &os;-változat-RELEASE-architektúra-disc3.iso Ez egy másik image, amelyen szintén bináris csomagok találhatóak. Ilyen a &os; 8.0 és az utána következõ változatoknál már nincs. &os;-változat-RELEASE-architektúra-docs.iso A &os; dokumentációja. &os;-változat-RELEASE-architektúra-livefs.iso Ez az image a rendszerhelyreállításhoz használt élõ indítási módot támogatja, telepítést alapvetõen nem lehet vele végezni.
A &os; 7.3 és a &os; 8.1 elõtti 7.X, illetve 8.X kiadások egy ettõl eltérõ elnevezési sémát követnek: a hozzájuk tartozó ISO image-ek neveiben nem szerepel a &os;- elõtag. Le kell töltenünk az elsõ lemez vagy (ha elérhetõ) a bootonly lemez ISO image-einek egyikét. A kettõt egyszerre viszont ne töltsük le, mivel a disc1 image tartalmaz mindent, ami a bootonly image-en megtalálható. Akkor használjuk a bootonly jelzésû image-et, ha szélessávú interneteléréssel rendelkezünk. Segítségével el tudjuk kezdeni a &os; telepítését, és szükség szerint a port/csomagrendszer (lásd ) használatával csomagokat tudunk letölteni és telepíteni. - Az elsõ lemez image-ét - (disc1) akkor érdemes - használni, ha a &os; adott kiadásának - telepítése mellett igényt tartunk - valamennyi csomagra is. + A DVD image-ét (dvd1) akkor + érdemes használni, ha a &os; adott + kiadásának telepítése mellett + igényt tartunk valamennyi csomagra is. A további lemezek image-ei is hasznosak lehetnek, de nem feltétlenül kellenek a telepítéshez, fõleg abban az esetben, amikor gyors interneteléréssel rendelkezünk. A CD-k írása Ezután lemezekre kell írnunk a letöltött image-eket. Amennyiben ezt egy másik &os; rendszeren végezzük, ennek részleteirõl a számol be (különösen a és a leírása). Ha másik platformon végezzük ezt a mûveletet, akkor az adott platformon felkínált CD-író szoftverekkel kell dolgoznunk. Az image-ek szabványos ISO formátumúak, amelyet szinte az összes CD-író alkalmazás ismer. Ha kíváncsiak vagyunk egy saját &os; kiadás elkészítésére, olvassuk el a kiadások szervezésérõl szóló cikket (angolul). Helyi FTP oldal létrehozása &os; lemezzel telepítés hálózat FTP A &os; lemezeken az FTP oldalakéhoz hasonló elrendezést találunk. Ez megkönnyíti a hálózatunkban található számítógépekhez a &os; telepítésére használható helyi FTP oldal létrehozását. Az FTP oldalnak otthont adó &os; számítógépen tegyük a CD-t a meghajtóba, majd csatlakoztassuk a /cdrom könyvtárba. &prompt.root; mount /cdrom Hozzunk létre egy anonim FTP hozzáférést az /etc/passwd állományban. A &man.vipw.8; segítségével tehát illesszük be a következõ sort az /etc/passwd állományba: ftp:*:99:99::0:0:FTP:/cdrom:/nonexistent Gondoskodjuk róla, hogy az FTP szolgáltatás engedélyezve legyen az /etc/inetd.conf állományban. Most már bárki, aki képes csatlakozni ehhez a számítógéphez, a telepítés típusának ki tudja választani az FTP-t. Az FTP oldalak menüjében válassza az Other (Egyéb) pontot, majd adja meg az ftp://gépnév címet. Ha az FTP-n csatlakozó kliensek rendszerindításhoz használt eszköze (általában a floppy) verziója nem egyezik meg tökéletesen a helyi FTP oldalon találhatóval, akkor a sysinstall nem engedi a telepítést. Ha a változatok nem hasonlóak és ezt felül akarjuk bírálni, akkor be kell lépnünk az Options (Beállítások) menübe, ahol át kell állítanunk a terjesztés nevét (distribution name) any (bármelyik)-re. A fenti megközelítés kizárólag csak egy tûzfallal védett helyi hálózaton javasolt. FTP szolgáltatás létrehozása az interneten (és nem a helyi hálózatunkban) levõ számítógépek számára különbözõ támadásoknak és egyéb kellemetlenségeknek teszi ki a számítógépünket. Határozottan javasoljuk, hogy ebben az esetben különösen ügyeljünk a biztonságra. Telepítõfloppyk létrehozása telepítés floppy Ha floppylemezrõl kellene telepítenünk (amit viszont semmiképpen sem ajánlanánk) egy nem támogatott hardvereszköz miatt, vagy mert egyszerûen szeretjük a dolgok nehezebbik oldalát megfogni, akkor ehhez elõször elõ kell készítenünk pár lemezt. Legalább annyi 1,44 MB-os lemezre van szükségünk, mint amennyire ráférnek a base (alapterjesztés) könyvtárban található állományok. Ha DOS-ban hozzuk létre ezeket a lemezeket, akkor a használatukhoz meg kell formázni ezeket az &ms-dos; FORMAT parancsával. &windows; használata esetén az Windows Explorerben (Intézõben) tudjuk megformázni a lemezeket (kattintsunk a jobb gombbal az A: meghajtóra, majd válasszuk a Format (Formázás) menüpontot). Ne bízzunk a gyárilag formázott (pre-formatted jelzésû) lemezekben! Menjünk biztosra és formázzuk meg mi magunk is lemezeket. A felhasználóinktól régebben számtalan olyan panasz érkezett, amely a helytelenül megformázott lemezbõl fakadt, ezért erre most kiemelten felhívjuk a figyelmet. A formázás abban az esetben sem bizonyul rossz ötletnek, ha egy másik &os; gépen gyártjuk le a lemezeket, habár nem kell mindegyik lemezre DOS állományrendszert tennünk. Helyette a bsdlabel és newfs parancsok használatával UFS állományrendszert is tehetünk rájuk, ahogy (1,44 MB méretû lemezek esetén) ezt az alábbi parancsok mutatják: &prompt.root; fdformat -f 1440 fd0.1440 &prompt.root; bsdlabel -w fd0.1440 floppy3 &prompt.root; newfs -t 2 -u 18 -l 1 -i 65536 /dev/fd0 Ezután a többi állományrendszerhez hasonlóan a lemezeket tudjuk csatlakoztatni és írni. Miután megformáztuk a lemezeket, rájuk kell másolnunk az állományokat. A terjesztésekhez tartozó állományokat adott méretû darabokra szeleteltük, így kényelmesen ráférnek egy hagyományos 1,44 MB méretû floppyra. Menjünk végig az összes floppyn és mindegyikre pakoljuk fel a lehetõ legtöbb állományt egészen addig, amíg így az összes szükséges terjesztést össze nem szedtük. A floppykon minden terjesztés kerüljön egy hozzá tartozó alkönyvtárba, például: a:\base\base.aa, a:\base\base.ab és így tovább. Az elsõ lemezre rá kell másolnunk a base.inf nevû állományt is, mivel ennek beolvasásával lesz képes kitalálni a telepítõ, hogy a terjesztések összeszedése és összefûzése során mennyi darabot keressen. Ahogy elérkezünk a telepítõeszköz kiválasztásához a telepítés folyamatában, ott válasszuk a Floppy menüpontot, majd utána kövessük a felbukkanó üzeneteket. Telepítés &ms-dos; partícióról telepítés MS-DOS partícióról Amikor egy &ms-dos; partícióról akarunk telepíteni, elõkészítés gyanánt másoljuk a terjesztésekhez tartozó állományokat a partícióra egy freebsd könyvtárba. Ez lesz például a c:\freebsd. Ebben a könyvtárban igyekezzük minél jobban megtartani a CD vagy az FTP oldal könyvtárszerkezetét, ezért erre a CD-rõl történõ átmásolásra a DOS xcopy parancsát javasoljuk. Például így tudjuk elõkészíteni a &os; legegyszerûbb változatának telepítését: C:\> md c:\freebsd C:\> xcopy e:\bin c:\freebsd\bin\ /s C:\> xcopy e:\manpages c:\freebsd\manpages\ /s A fentiekben feltételeztük, hogy ehhez a C: meghajtón elég szabad helyünk van, valamint az E: meghajtón érjük el a CD-t. Ha nincs CD-meghajtónk, az ftp.FreeBSD.org címrõl letölthetjük a terjesztésket. Minden egyes terjesztés külön könyvtárban található, tehát például a base (alap) terjesztés az &rel.current;/base/ könyvtárban található. Mindegyik telepítendõ terjesztést (ami még elfér) másoljuk át az &ms-dos; partíció c:\freebsd könyvtárába — a telepítéshez egyébként egyedül a BIN terjesztés szükséges. Telepítõszalag létrehozása telepítés QIC/SCSI-szalagról Valószínûleg a szalagos módszer a legegyszerûbb, egyfajta élõ FTP-s vagy CD-s telepítés. A telepítõprogram arra számít, hogy a szalagon az állományok egymás után helyezkednek el. Tehát miután beszereztük a nekünk kellõ terjesztésekhez tartozó összes állományt, egyszerûen vegyük fel ezeket a szalagra: &prompt.root; cd /freebsd/distdir &prompt.root; tar cvf /dev/rwt0 dist1 ... dist2 Mielõtt telepítenénk, ellenõrizzük, hogy legyen elég helyünk valamelyik (a telepítés során majd kiválasztható átmeneti) könyvtárban ahhoz, hogy az itt létrehozott szalag teljes tartalma elférjen benne. Mivel a szalagok csak szekvenciálisan érhetõek el, ezért ennél a módszernél jó sok ideiglenes tárhelyre lesz szükségünk. A telepítés megkezdése után a szalagnak már azelõtt a meghajtóban kell lennie, hogy rendszerindító floppyról elindítanánk a rendszert, máskülönben nem találja meg. Mielõtt hálózatról telepítenénk telepítés hálózat soros (PPP) telepítés hálózat párhuzamos (PLIP) telepítés hálózat Ethernet Háromféle hálózati telepítési mód létezik: Ethernet (szabványos Ethernet-vezérlõvel), soros port (PPP) vagy párhuzamos port (PLIP (laplink kábel)). Valószínûleg az Ethernet-csatlakozó választásával érjük el a leggyorsabb hálózati telepítést. A &os; ismeri a legtöbb PC-s Ethernet kártyát. Az ismert kártyák (és a hozzájuk tartozó beállítások) a &os; egyes kiadásának hardverjegyzékében (Hardware Notes) találhatóak meg. Amennyiben egy támogatott PCMCIA Ethernet kártyát használunk, mindig a laptop bekapcsolása elõtt helyezzük be! A &os; telepítés közben sajnos nem támogatja a PCMCIA kártyák menetközbeni behelyezését. Ezenkívül még ismernünk kell a hálózaton kapott IP-címünket, az általa használt címosztály hálózati maszkját, a gépünk nevét. Ha PPP kapcsolaton keresztül telepítünk és nincs statikus IP-címünk, akkor minden bizonnyal az internet-szolgáltatónktól kaptunk egyet dinamikusan. A konkrét hálózati beállításokat a hálózatunk rendszergazdájától is érdemes megkérdezni. Ha a hálózaton levõ többi gépre névvel és nem IP-címmel hivatkozunk, akkor szükségünk lesz még egy név(feloldó) szerverre és az internet eléréséhez egy átjáró címére is (ha PPP-t használunk, ez a szolgáltatónk IP-címe lesz). Ha FTP-rõl HTTP proxy használatával telepítünk, akkor a proxy címe is kelleni fog. Ha magunktól nem vagyunk képesek ezekre a kérdésekre válaszolni, akkor az ilyen típusú telepítés megkezdése elõtt tényleg segítséget kell kérnünk egy rendszergazdától vagy az internet-szolgáltatónktól. Ha modemet használunk, akkor a PPP szinte biztosan megfelel nekünk. Gondoskodjunk róla, hogy már a telepítés korai szakaszában rendelkezésünkre áll az internet-szolgáltatónkkal kapcsolatosan minden hasznos információ. Ha PAP vagy CHAP használatával kapcsolódunk a szolgáltatónkhoz (másképp szólva &windows;-ban így tudunk szkriptek nélkül csatlakozni), mindössze a dial parancsot kell kiadnunk a ppp parancssorában. Minden más esetben tudnunk kell a modemünk saját AT parancsaival tárcsázni az internet-szolgáltatónkat, hiszen ehhez a PPP tárcsázó csak egy nagyon kezdetleges terminálemulációt nyújt. Ezzel kapcsolatban olvassuk el a kézikönyv és a GYIK idevágó részeit. Ha gondjaink akadnának, a naplózás a set log local ... parancs kiadásával átirányítható közvetlenül a képernyõre. Ha kötött módon tudunk csatlakozni egy másik (2.0-R vagy késõbbi verziójú) &os; géphez, akkor megpróbálkozhatunk a párhuzamos laplink kábellel. A párhuzamos porton keresztüli adatátvitel sebessége a soros vonalénál jóval nagyobb (egészen 50 kbyte/mp), ezért vele a telepítés is gyorsabb. Mielõtt NFS-rõl telepítenénk telepítés hálózat NFS A telepítés NFS-en keresztül szinte magától értetõdik. Egyszerûen csak másoljuk a &os; terjesztéseihez tartozó állományokat az NFS szerverre és állítsuk be rá az NFS telepítõeszközt. Ha a szerver csak privilegizált portokat ismer (ami általában alapértelmezett a Sun munkaállomásoknál), a telepítés megkezdése elõtt az Options (Beállítások) menüben be kell állítani az NFS Secure (Biztonságos NFS) opciót. Ha egy gyenge minõségû és kis adatátviteli sebességû Ethernet kártyánk van, akkor emellett még hasznos lehet beállítani az NFS Slow (Lassú NFS) opciót is. Az NFS-en keresztüli telepítés mûködéséhez a szervernek támogatnia kell az alkönyvtárak csatlakoztatását is, tehát például ha a &os; &rel.current; terjesztésünk a ziggy:/usr/archive/stuff/FreeBSD könyvtárban található, akkor ziggy nevû gépnek lehetõvé kell tennie a /usr/archive/stuff/FreeBSD könyvtár közvetlen csatlakoztatását is, nem csak a /usr vagy /usr/archive/stuff könyvtárakét. A &os; /etc/exports állományában ezt az beállítással vezérelhetjük. Más NFS szervereken esetleg más megszokásokat kell követnünk. Amennyiben a szervertõl permission denied (hozzáférés megtagadva) üzeneteket kapjuk, valószínû, hogy ezt nem állítottuk be megfelelõen. diff --git a/hu_HU.ISO8859-2/books/handbook/network-servers/chapter.sgml b/hu_HU.ISO8859-2/books/handbook/network-servers/chapter.sgml index 1e5f9f97a8..69adf01960 100644 --- a/hu_HU.ISO8859-2/books/handbook/network-servers/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/network-servers/chapter.sgml @@ -1,7259 +1,7259 @@ Murray Stokely Átdolgozta: Hálózati szerverek Áttekintés Ebben a fejezetben a &unix; típusú rendszerekben leggyakrabban alkalmazott hálózati szolgáltatások közül fogunk néhányat bemutatni. Ennek során megismerjük a hálózati szolgáltatások különbözõ típusainak telepítését, beállítását, tesztelését és karbantartását. A fejezet tartalmát folyamatosan példákkal igyekszünk illusztrálni. A fejezet elolvasása során megismerjük: hogyan dolgozzunk az inetd démonnal; hogyan állítsuk be a hálózati állományrendszereket; hogyan állítsunk be egy hálózati információs szervert a felhasználói hozzáférések megosztására; hogyan állítsuk be automatikusan a hálózati hozzáférésünket a DHCP használatával; hogyan állítsunk be névfeloldó szervereket; hogyan állítsuk be az Apache webszervert; hogyan állítsuk be az állományok átviteléért felelõs (FTP) szervert; a Samba használatával hogyan állítsunk be &windows;-os kliensek számára állomány- és nyomtatószervert; az NTP protokoll segítségével hogyan egyeztessük az idõt és dátumot, hogyan állítsunk be egy idõszervert; a szabványos naplózó démon, a syslogd beállítását hálózati keresztüli naplózásra. A fejezet elolvasásához ajánlott: az /etc/rc szkriptek alapjainak ismerete; az alapvetõ hálózati fogalmak ismerete; a külsõ szoftverek telepítésének ismerete (). Chern Lee Készítette: A &os; 6.1-RELEASE változatához igazította: A &os; Dokumentációs Projekt Az <application>inetd</application> <quote>szuperszerver</quote> Áttekintés Az &man.inetd.8; démont gyakran csak internet szuperszerverként nevezik, mivel a helyi szolgáltatások kapcsolatainak kezeléséért felelõs. Amikor az inetd fogad egy csatlakozási kérelmet, akkor eldönti róla, hogy ez melyik programhoz tartozik és elindít egy példányt belõle, majd átadja neki a socketet (az így meghívott program a szabvány bemenetéhez, kimenetéhez és hibajelzési csatornájához kapja meg a socket leíróit). Az inetd használatával úgy tudjuk csökkenteni a rendszerünk terhelését, hogy a csak alkalmanként meghívott szolgáltatásokat nem futtatjuk teljesen független önálló módban. Az inetd démont elsõsorban más démonok elindítására használjuk, de néhány triviális protokollt közvetlenül is képes kezelni, mint például a chargen, auth és a daytime. Ebben a fejezetben az inetd beállításának alapjait foglaljuk össze mind parancssoros módban, mind pedig az /etc/inetd.conf konfigurációs állományon keresztül. Beállítások Az inetd mûködése az &man.rc.8; rendszeren keresztül inicializálható. Az inetd_enable ugyan alapból a NO értéket veszi fel, vagyis tiltott, de a sysinstall használatával már akár a telepítés során bekapcsolható attól függõen, hogy a felhasználó milyen konfigurációt választott. Ha tehát a: inetd_enable="YES" vagy inetd_enable="NO" sort tesszük az /etc/rc.conf állományba, akkor azzal az inetd démont indíthatjuk el vagy tilthatjuk le a rendszer indítása során. Az &prompt.root; /etc/rc.d/inetd rcvar paranccsal lekérdezhetjük a pillanatnyilag érvényes beállítást. Emellett még az inetd démonnak az inetd_flags változón keresztül különbözõ parancssori paramétereket is át tudunk adni. Parancssori paraméterek Hasonlóan a legtöbb szerverhez, az inetd viselkedését is befolyásolni tudjuk a parancssorban átadható különbözõ paraméterekkel. Ezek teljes listája a következõ: inetd Ezek a paraméterek az /etc/rc.conf állományban az inetd_flags segítségével adhatóak meg az inetd részére. Alapértelmezés szerint az inetd_flags értéke -wW -C 60, ami az inetd által biztosított szolgáltatások TCP protokollon keresztüli wrappelését kapcsolja be, illetve egy IP-címrõl nem engedi a felkínált szolgáltatások elérését percenként hatvannál többször. A kezdõ felhasználók örömmel nyugtázhatják, hogy ezeket az alapbeállításokat nem szükséges - módosítaniuk, habár a - késõbbiekben majd fény derül arra, hogy - a kiszolgálás gyakoriságának - szabályozása remek védekezést - nyújthat túlzottan nagy mennyiségû - kapcsolódási kérelem ellen. A - megadható paraméterek teljes listája az - &man.inetd.8; man oldalán olvasható. + módosítaniuk. A késõbbiekben majd + fény derül arra, hogy a kiszolgálás + gyakoriságának szabályozása remek + védekezést nyújthat túlzottan nagy + mennyiségû kapcsolódási kérelem + ellen. A megadható paraméterek teljes + listája az &man.inetd.8; man oldalán + olvasható. -c maximum Az egyes szolgáltatásokhoz egyszerre felépíthetõ kapcsolatok alapértelmezett maximális számát adja meg. Alapból ezt a démont nem korlátozza. A beállítással ez akár szolgáltatásonként külön is megadható. -C arány Korlátozza, hogy egyetlen IP-címrõl alapból hányszor hívhatóak meg az egyes szolgáltatások egy percen belül. Ez az érték alapból korlátlan. A beállítással ez szolgáltatásonként is definiálható. -R arány Megadja, hogy egy szolgáltatást egy perc alatt mennyiszer lehet meghívni. Ez az érték alapértelmezés szerint 256. A 0 megadásával eltöröljük ezt a típusú korlátozást. -s maximum Annak maximumát adja meg, hogy egyetlen IP-címrõl egyszerre az egyes szolgáltatásokat mennyiszer tudjuk elérni. Alapból ez korlátlan. Szolgáltatásonként ezt a paraméterrel tudjuk felülbírálni. Az <filename>inetd.conf</filename> állomány Az inetd beállítását az /etc/inetd.conf konfigurációs állományon keresztül végezhetjük el. Amikor az /etc/inetd.conf állományban módosítunk valamit, az inetd démont a következõ paranccsal meg kell kérnünk, hogy olvassa újra: Az <application>inetd</application> konfigurációs állományának újraolvasása &prompt.root; /etc/rc.d/inetd reload A konfigurációs állomány minden egyes sora egy-egy démont ír le. A megjegyzéseket egy # jel vezeti be. Az /etc/inetd.conf állomány bejegyzéseinek formátuma az alábbi: szolgáltatás-neve socket-típusa protokoll {wait|nowait}[/max-child[/max-connections-per-ip-per-minute[/max-child-per-ip]]] felhasználó[:csoport][/bejelentkezési-osztály] szerver-program szerver-program-paraméterei Az IPv4 protokollt használó &man.ftpd.8; démon bejegyzése például így néz ki: ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l szolgáltatás-neve Ez az adott démon által képviselt szolgáltatást nevezi meg, amelynek szerepelnie kell az /etc/services állományban. Ez határozza meg, hogy az inetd milyen porton figyelje a beérkezõ kapcsolatokat. Ha egy új szolgáltatást hozunk létre, akkor azt elõször az /etc/services állományba kell felvennünk. csatlakozás-típusa Ennek az értéke stream, dgram, raw, vagy seqpacket lehet. A stream típust használja a legtöbb kapcsolat-orientált TCP démon, miközben a dgram típus az UDP szállítási protokollt alkalmazó démonok esetében használatos. protokoll Valamelyik a következõk közül: Protokoll Magyarázat tcp, tcp4 TCP IPv4 udp, udp4 UDP IPv4 tcp6 TCP IPv6 udp6 UDP IPv6 tcp46 TCP IPv4 és v6 udp46 UDP IPv4 és v6 {wait|nowait}[/max-child[/max-connections-per-ip-per-minute[/max-child-per-ip]]] A beállítás mondja meg, hogy az inetd démonból meghívott démon saját maga képes-e kezelni kapcsolatokat. A típusú kapcsolatok esetében egyértelmûen a beállítást kell használni, miközben a esetén, ahol általában több szálon dolgozunk, a megadása javasolt. A hatására általában egyetlen démonnak adunk át több socketet, míg a minden sockethez egy újabb példányt indít el. Az inetd által indítható példányokat a megadásával korlátozhatjuk. Ha tehát például az adott démon számára legfeljebb példány létrehozását engedélyezzük, akkor a után /10 beállítást kell megadnunk. A /0 használatával korlátlan mennyiségû példányt engedélyezhetünk. A mellett még további két másik beállítás jöhet számításba az egyes démonok által kezelhetõ kapcsolatok maximális számának korlátozásában. A az egyes IP-címekrõl befutó lekezelhetõ kapcsolatok percenkénti számát szabályozza, így például ha itt a tizes értéket adjuk meg, akkor az adott szolgáltatáshoz egy IP-címrõl percenként csak tízszer férhetünk hozzá. A az egyes IP-címekhez egyszerre elindítható példányok számára ír elõ egy korlátot. Ezek a paraméterek segítenek megóvni rendszerünket az erõforrások akaratos vagy akaratlan kimerítésétõl és a DoS (Denial of Service) típusú támadásoktól. Ebben a mezõben a vagy valamelyikét kötelezõ megadni. A , és paraméterek ellenben elhagyhatóak. A típusú több szálon futó démonok a , vagy korlátozása nélkül egyszerûen csak így adhatóak meg: nowait. Ha ugyanezt a démont tíz kapcsolatra lekorlátozzuk, akkor a következõt kell megadnunk: nowait/10. Amikor pedig IP-címenként 20 kapcsolatot engedélyezünk percenként és mindössze 10 példányt, akkor: nowait/10/20. Az iménti beállítások a &man.fingerd.8; démon alapértelmezett paramétereinél is megtalálhatóak: finger stream tcp nowait/3/10 nobody /usr/libexec/fingerd fingerd -s Végezetül engedélyezzük 100 példányt, melyek közül IP-címenként 5 használható: nowait/100/0/5. felhasználó Ezzel azt a felhasználót adjuk meg, akinek a nevében az adott démon futni fog. Az esetek túlnyomó részében a démonokat a root felhasználó futtatja. Láthatjuk azonban, hogy biztonsági okokból bizonyos démonok a daemon vagy a legkevesebb joggal rendelkezõ nobody felhasználóval futnak. szerver-program A kapcsolat felépülésekor az itt teljes elérési úttal megadott démon indul el. Ha ezt a szolgáltatást maga az inetd belsõleg valósítja meg, akkor ebben a mezõben az értéket adjuk meg. szerver-program-paraméterei Ez a beállítással együtt mûködik, és ebben a mezõben a démon meghívásakor alkalmazandó paramétereket tudjuk rögzíteni, amelyet a démon nevével kezdünk. Ha a démont a parancssorból a sajátdémon -d paranccsal hívnánk meg, akkor a sajátdémon -d lesz beállítás helyes értéke is. Természetesen, ha a démon egy belsõleg megvalósított szolgáltatás, akkor ebben a mezõben is az fog megjelenni. Védelem Attól függõen, hogy a telepítés során mit választottunk, az inetd által támogatott szolgáltatások egyes része talán alapból engedélyezett is. Amennyiben egy adott démont konkrétan nem használunk, akkor érdemes megfontolni a letiltását. A kérdéses démon sorába tegyünk egy # jelet az /etc/inetd.conf állományba, majd olvastassuk újra az inetd beállításait. Egyes démonok, mint például az fingerd használata egyáltalán nem ajánlott, mivel a támadók számára hasznos információkat tudnak kiszivárogtatni. Más démonok nem ügyelnek a védelemre, és a kapcsolatokhoz rendelt lejárati idejük túlságosan hosszú vagy éppen nincs is. Ezzel a támadónak lehetõsége van lassú kapcsolatokkal leterhelni az adott démont, ezáltal kimeríteni a rendszer erõforrásait. Ha úgy találjuk, hogy túlságosan sok az ilyen kapcsolat, akkor jó ötletnek bizonyulhat a démonok számára a , vagy korlátozások elrendelése. Alapértelmezés szerint a TCP kapcsolatok wrappelése engedélyezett. A &man.hosts.access.5; man oldalon találhatjuk meg az inetd által meghívható különféle démonok TCP-alapú korlátozásainak lehetõségeit. Egyéb lehetõségek A daytime, time, echo, discard, chargen és auth szolgáltatások feladatainak mindegyikét maga az inetd is képes ellátni. Az auth szolgáltatás a hálózati keresztül azonosítást teszi lehetõvé és bizonyos mértékig beállítható. A többit egyszerûen csak kapcsoljuk ki vagy be. A témában az &man.inetd.8; man oldalán tudunk még jobban elmerülni. Tom Rhodes Átdolgozta és javította: Bill Swingle Írta: A hálózati állományrendszer (NFS) NFS A &os; több állományrendszert ismer, köztük a hálózati állományrendszert (Network File System, NFS) is. Az NFS állományok és könyvtárak megosztását teszi lehetõvé a hálózaton keresztül. Az NFS használatával a felhasználók és a programok képesek majdnem úgy elérni a távoli rendszereken található állományokat, mintha helyben léteznének. Íme az NFS néhány legjelentõsebb elõnye: A helyi munkaállomások kevesebb tárterületet használnak, mivel a közös adatokat csak egyetlen számítógépen tároljuk és megosztjuk mindenki között. A felhasználóknak nem kell a hálózat minden egyes gépén külön felhasználói könyvtárral rendelkezniük. Ezek ugyanis az NFS segítségével akár egy szerveren is beállíthatóak és elérhetõvé tehetõek a hálózaton keresztül. A különbözõ háttértárak, mint például a floppy lemezek, CD-meghajtók és &iomegazip; meghajtók a hálózaton több számítógép között megoszthatóak. Ezzel csökkenteni tudjuk a hálózatunkban szükséges cserélhetõ lemezes eszközök számát. Ahogy az <acronym>NFS</acronym> mûködik Az NFS legalább két fõ részbõl rakható össze: egy szerverbõl és egy vagy több kliensbõl. A kliensek a szerver által megosztott adatokhoz képesek távolról hozzáférni. A megfelelõ mûködéshez mindössze csak néhány programot kell beállítani és futtatni. A szervernek a következõ démonokat kell mûködtetnie: NFS szerver állományszerver UNIX kliensek rpcbind mountd nfsd Démon Leírás nfsd Az NFS démon, amely kiszolgálja az NFS kliensektõl érkezõ kéréseket. mountd Az NFS csatlakoztató démonja, amely végrehajtja az &man.nfsd.8; által átküldött kéréseket. rpcbind Ez a démon lehetõvé teszi az NFS kliensek számára, hogy fel tudják deríteni az NFS szerver által használt portot. A kliensen is futnia kell egy démonnak, amelynek a neve nfsiod. Az nfsiod démon az NFS szerver felõl érkezõ kéréseket szolgálja ki. A használata teljesen opcionális, csupán a teljesítményt hívatott javítani, de a normális és helyes mûködéshez nincs rá szükségünk. Az &man.nfsiod.8; man oldalán errõl többet is megtudhatunk. Az <acronym>NFS</acronym> beállítása NFS beállítás Az NFS beállítása viszonylag egyértelmûen adja magát. A mûködéséhez szükséges programok automatikus elindítása csupán néhány apró módosítást igényel az /etc/rc.conf állományban. Az NFS szerveren gondoskodjunk róla, hogy az alábbi beállítások szerepeljenek az /etc/rc.conf állományban: rpcbind_enable="YES" nfs_server_enable="YES" mountd_flags="-r" A mountd magától el fog indulni, ha az NFS szervert engedélyezzük. A kliensen a következõ beállítást kell felvennünk az /etc/rc.conf állományba: nfs_client_enable="YES" Az /etc/exports állomány adja meg, hogy az NFS milyen állományrendszereket exportáljon (vagy másképpen szólva osszon meg). Az /etc/exports állományban tehát a megosztani kívánt állományrendszereket kell szerepeltetnünk, és azt, hogy melyik számítógépekkel tudjuk ezeket elérni. A gépek megnevezése mellett a hozzáférésre további megszorításokat írhatunk fel. Ezek részletes leírását az &man.exports.5; man oldalon találjuk meg. Lássunk néhány példát az /etc/exports állományban megjelenõ bejegyzésekre: NFS példák exportálásra A most következõ példákban az állományrendszerek exportálásának finomságait igyekszünk érzékeltetni, noha a konkrét beállítások gyakran a rendszerünktõl és a hálózati konfigurációtól függenek. Például, ha a /cdrom könytárat akarjuk három gép számára megosztani, akik a szerverrel megegyezõ tartományban találhatóak (ezért nem is kell megadnunk a tartományt) vagy mert egyszerûen megtalálhatók az /etc/hosts állományunkban. Az beállítás az exportált állományrendszereket írásvédetté teszi. Ezzel a beállítással a távoli rendszerek nem lesznek képesek módosítani az exportált állományrendszer tartalmát. /cdrom -ro gép1 gép2 gép3 A következõ sorban a /home könyvtárat három gép számára osztjuk meg, melyeket IP-címekkel adtunk meg. Ez olyan helyi hálózat esetén hasznos, ahol nem állítottunk be névfeloldást. Esetleg a belsõ hálózati neveket az /etc/hosts állományban is tárolhatjuk. Ezzel utóbbival kapcsolatban a &man.hosts.5; man oldalt érdemes fellapoznunk. Az beállítás lehetõvé teszi, hogy az alkönyvtárak is csatlakozási pontok lehessenek. Más szóval, nem fogja csatlakoztatni az alkönyvtárakat, de megengedi a kliensek számára, hogy csak azokat a könyvtárakat csatlakoztassák, amelyeket kell vagy amelyekre szükségünk van. /home -alldirs 10.0.0.2 10.0.0.3 10.0.0.4 A következõ sorban az /a könyvtárat úgy exportáljuk, hogy az állományrendszerhez két különbözõ tartományból is hozzá lehessen férni. A beállítás hatására a távoli rendszer root felhasználója az exportált állományrendszeren szintén root felhasználóként fogja írni az adatokat. Amennyiben a -maproot=root beállítást nem adjuk meg, akkor a távoli rendszeren hiába root az adott felhasználó, az exportált állományrendszeren nem lesz képes egyetlen állományt sem módosítani. /a -maproot=root gep.minta.com doboz.haz.org A kliensek is csak a megfelelõ engedélyek birtokában képesek elérni a megosztott állományrendszereket. Ezért a klienst ne felejtsük el felvenni a szerver /etc/exports állományába. Az /etc/exports állományban az egyes sorok az egyes állományrendszerekre és az egyes gépekre vonatkoznak. A távoli gépek állományrendszerenként csak egyszer adhatóak meg, és csak egy alapértelmezett bejegyzésük lehet. Például tegyük fel, hogy a /usr egy önálló állományrendszer. Ennek megfelelõen az alábbi bejegyzések az /etc/exports állományban érvénytelenek: # Nem használható, ha a /usr egy állományrendszer: /usr/src kliens /usr/ports kliens Egy állományrendszerhez, vagyis itt a /usr partícióhoz, két export sort is megadtunk ugyanahhoz a kliens nevû géphez. Helyesen így kell megoldani az ilyen helyzeteket: /usr/src /usr/ports kliens Az adott géphez tartozó egy állományrendszerre vonatkozó exportoknak mindig egy sorban kell szerepelniük. A kliens nélkül felírt sorok egyetlen géphez tartozónak fognak számítani. Ezzel az állományrendszerek megosztását tudjuk szabályozni, de legtöbbek számára nem jelent gondot. Most egy érvényes exportlista következik, ahol a /usr és az /exports mind helyi állományrendszerek: # Osszuk meg az src és ports könyvtárakat a kliens01 és kliens02 részére, de csak a # kliens01 férhessen hozzá rendszeradminisztrátori jogokkal: /usr/src /usr/ports -maproot=root kliens01 /usr/src /usr/ports kliens02 # A kliensek az /exports könyvtárban teljes joggal rendelkeznek és azon belül # bármit tudnak csatlakoztatni. Rajtuk kívül mindenki csak írásvédetten képes # elérni az /exports/obj könyvtárat: /exports -alldirs -maproot=root kliens01 kliens02 /exports/obj -ro A mountd démonnal az /etc/exports állományt minden egyes módosítása után újra be kell olvastatni, mivel a változtatásaink csak így fognak érvényesülni. Ezt megcsinálhatjuk úgy is, hogy küldünk egy HUP (hangup, avagy felfüggesztés) jelzést a már futó démonnak: &prompt.root; kill -HUP `cat /var/run/mountd.pid` vagy meghívjuk a mountd &man.rc.8; szkriptet a megfelelõ paraméterrel: &prompt.root; /etc/rc.d/mountd onereload Az ban tudhatunk meg részleteket az rc szkriptek használatáról. Ezek után akár a &os; újraindításával is aktiválhatjuk a megosztásokat, habár ez nem feltétlenül szükséges. Ha root felhasználónként kiadjuk a következõ parancsokat, akkor azzal minden szükséges programot elindítunk. Az NFS szerveren tehát: &prompt.root; rpcbind &prompt.root; nfsd -u -t -n 4 &prompt.root; mountd -r Az NFS kliensen pedig: &prompt.root; nfsiod -n 4 Ezzel most már minden készen áll a távoli állományrendszer csatlakoztatására. A példákban a szerver neve szerver lesz, valamint a kliens neve kliens. Ha csak ideiglenesen akarunk csatlakoztatni egy állományrendszert vagy egyszerûen csak ki akarjuk próbálni a beállításainkat, a kliensen root felhasználóként az alábbi parancsot hajtsuk végre: NFS csatlakoztatás &prompt.root; mount szerver:/home /mnt Ezzel a szerveren található /home könyvtárat fogjuk a kliens /mnt könyvtárába csatlakoztatni. Ha mindent jól beállítottunk, akkor a kliensen most már be tudunk lépni az /mnt könyvtárba és láthatjuk a szerveren található állományokat. Ha a számítógép indításával automatikusan akarunk hálózati állományrendszereket csatlakoztatni, akkor vegyük fel ezeket az /etc/fstab állományba. Erre íme egy példa: szerver:/home /mnt nfs rw 0 0 Az &man.fstab.5; man megtalálhatjuk az összes többi beállítást. Zárolások Bizonyos alkalmazások (például a mutt) csak akkor mûködnek megfelelõen, ha az állományokat a megfelelõ módon zárolják. Az NFS esetében az rpc.lockd használható az ilyen zárolások megvalósítására. Az engedélyezéséhez mind a szerveren és a kliensen vegyük fel a következõ sort az /etc/rc.conf állományba (itt már feltételezzük, hogy az NFS szervert és klienst korábban beállítottuk): rpc_lockd_enable="YES" rpc_statd_enable="YES" A következõ módon indíthatjuk el: &prompt.root; /etc/rc.d/lockd start &prompt.root; /etc/rc.d/statd start Ha nincs szükségünk valódi zárolásra az NFS kliensek és az NFS szerver között, akkor megcsinálhatjuk azt is, hogy az NFS kliensen a &man.mount.nfs.8; programnak az paraméter átadásával csak helyileg végzünk zárolást. Ennek további részleterõl a &man.mount.nfs.8; man oldalon kaphatunk felvilágosítást. Gyakori felhasználási módok Az NFS megoldását a gyakorlatban rengeteg esetben alkalmazzák. Ezek közül most felsoroljuk a legelterjedtebbeket: NFS használata Több gép között megosztunk egy telepítõlemezt vagy más telepítõeszközt. Ez így sokkal olcsóbb és gyakorta kényelmes megoldás abban az esetben, ha egyszerre több gépre akarjuk ugyanazt a szoftvert telepíteni. Nagyobb hálózatokon sokkal kényelmesebb lehet egy központi NFS szerver használata, ahol a felhasználók könyvtárait tároljuk. Ezek a felhasználói könyvtárak aztán megoszthatóak a hálózaton keresztül, így a felhasználók mindig ugyanazt a könyvárat kapják függetlenül attól, hogy milyen munkaállomásról is jelentkeztek be. Több géppel is képes így osztozni az /usr/ports/distfiles könyvtáron. Ezen a módon sokkal gyorsabban tudunk portokat telepíteni a gépekre, mivel nem kell külön mindegyikre letölteni az ehhez szükséges forrásokat. Wylie Stilwell Készítette: Chern Lee Újraírta: Automatikus csatlakoztatás az <application>amd</application> használatával amd automatikus csatlakoztató démon Az &man.amd.8; (automatikus csatlakoztató démon, az automatic mounter daemon) önmûködõen csatlakoztatja a távoli állományrendszereket, amikor azokon belül valamelyik állományhoz vagy könyvtárhoz próbálunk hozzáférni. Emellett az amd az egy ideje már inaktív állományrendszereket is automatikusan leválasztja. Az amd használata egy remek alternatívát kínál az általában az /etc/fstab állományban megjelenõ állandóan csatlakoztatott állományrendszerekkel szemben. Az amd úgy mûködik, hogy kapcsolódik egy NFS szerver /host és /net könyvtáraihoz. Amikor egy állományt akarunk elérni ezeken a könyvtárakon belül, az amd kikeresi a megfelelõ távoli csatlakoztatást és magától csatlakoztatja. A /net segítségével egy IP-címrõl tudunk exportált állományrendszereket csatlakoztatni, miközben a /host a távoli gép hálózati neve esetében használatos. Ha tehát a /host/izemize/usr könyvtárban akarunk elérni egy állományt, akkor az amd démonnak ahhoz elõször az izemize nevû géprõl exportált /usr könyvtárat kell csatlakoztatnia. Egy exportált állományrendszer csatlakoztatása az <application>amd</application> használatával Egy távoli számítógép által rendelkezésre bocsátott megosztásokat a showmount paranccsal tudjuk lekérdezni. Például az izemize gépen elérhetõ exportált állományrendszereket így láthatjuk: &prompt.user; showmount -e izemize Exports list on izemize: /usr 10.10.10.0 /a 10.10.10.0 &prompt.user; cd /host/izemize/usr Ahogy a példában látjuk is, a showmount parancs a /usr könyvtárat mutatja megosztásként. Amikor tehát belépünk a /host/izemize/usr könyvtárba, akkor amd magától megpróbálja feloldani az izemize hálózati nevet és csatlakoztatni az elérni kívánt exportált állományrendszert. Az amd az indító szkripteken keresztül az /etc/rc.conf alábbi beállításával engedélyezhetõ: amd_enable="YES" Emellett még az amd_flags használatával további paraméterek is átadható az amd felé. Alapértelmezés szerint az amd_flags tartalmaz az alábbi: amd_flags="-a /.amd_mnt -l syslog /host /etc/amd.map /net /etc/amd.map" Az /etc/amd.map állomány adja meg az exportált állományrendszerek alapértelmezett beállításait. Az /etc/amd.conf állományban az amd további lehetõségeit konfigurálhatjuk.. Ha többet is szeretnénk tudni a témáról, akkor az &man.amd.8; és az &man.amd.conf.5; man oldalakat javasolt elolvasnunk. John Lind Készítette: Problémák más rendszerek használatakor Némely PC-s ISA buszos Ethernet kártyákra olyan korlátozások érvényesek, melyek komoly hálózati problémák keletkezéséhez vezethetnek, különösen az NFS esetében. Ez a nehézség nem &os;-függõ, de a &os; rendszereket is érinti. Ez gond általában majdnem mindig akkor merül fel, amikor egy (&os;-s) PC egy hálózatba kerül többek közt a Silicon Graphic és a Sun Microsystems által gyártott nagyteljesítményû munkaállomásokkal. Az NFS csatlakoztatása és bizonyos mûveletek még hibátlanul végrehajtódnak, azonban hirtelen a szerver látszólag nem válaszol többet a kliens felé úgy, hogy a többi rendszertõl folyamatosan dolgozza felfele a kéréseket. Ez a kliens rendszeren tapasztalható csak, amikor a kliens &os; vagy egy munkaállomás. Sok rendszeren egyszerûen rendesen le sem lehet állítani a klienst, ha a probléma egyszer már felütötte a fejét. Egyedüli megoldás gyakran csak a kliens újraindítása marad, mivel az NFS-ben kialakult helyzetet máshogy nem lehet megoldani. Noha a helyes megoldás az lenne, ha beszereznénk egy nagyobb teljesítményû és kapacitású kártyát a &os; rendszer számára, azonban egy jóval egyszerûbb kerülõút is található a kielégítõ mûködés eléréséhez. Ha a &os; rendszer képviseli a szervert, akkor a kliensnél adjuk meg a beállítást is a csatlakoztatásnál. Ha a &os; rendszer a kliens szerepét tölti be, akkor az NFS állományrendszert az beállítással csatlakoztassuk róla. Ezek a beállítások az fstab állomány negyedik mezõjében is megadhatóak az automatikus csatlakoztatáshoz, vagy manuális esetben a &man.mount.8; parancsnak a paraméterrel. Hozzá kell azonban tennünk, hogy létezik egy másik probléma, amit gyakran ezzel tévesztenek össze, amikor az NFS szerverek és kliensek nem ugyanabban a hálózatban találhatóak. Ilyen esetekben mindenképpen gyõzõdjünk meg róla, hogy az útválasztók rendesen továbbküldik a mûködéshez szükséges UDP információkat, különben nem sokat tudunk tenni a megoldás érdekében. A most következõ példákban a gyorsvonat lesz a nagyteljesítményû munkaállomás (felület) neve, illetve a freebsd pedig a gyengébb teljesítményû Ethernet kártyával rendelkezõ &os; rendszer (felület) neve. A szerveren az /osztott nevû könyvtárat fogjuk NFS állományrendszerként exportálni (lásd &man.exports.5;), amelyet majd a /projekt könyvtárba fogunk csatlakoztatni a kliensen. Minden esetben érdemes lehet még megadnunk a vagy , illetve opciókat is. Ebben a példában a &os; rendszer (freebsd) lesz a kliens, és az /etc/fstab állományában így szerepel az exportált állományrendszer: gyorsvonat:/osztott /projekt nfs rw,-r=1024 0 0 És így tudjuk manuálisan csatlakoztatni: &prompt.root; mount -t nfs -o -r=1024 gyorsvonat:/osztott /projekt Itt a &os; rendszer lesz a szerver, és a gyorsvonat /etc/fstab állománya így fog kinézni: freebsd:/osztott /projekt nfs rw,-w=1024 0 0 Manuálisan így csatlakoztathatjuk az állományrendszert: &prompt.root; mount -t nfs -o -w=1024 freebsd:/osztott /projekt Szinte az összes 16 bites Ethernet kártya képes mûködni a fenti írási vagy olvasási korlátozások nélkül is. A kíváncsibb olvasók számára eláruljuk, hogy pontosan miért is következik be ez a hiba, ami egyben arra is magyarázatot ad, hogy miért nem tudjuk helyrehozni. Az NFS általában 8 kilobyte-os blokkokkal dolgozik (habár kisebb méretû darabkákat is tud készíteni). Mivel az Ethernet által kezelt legnagyobb méret nagyjából 1500 byte, ezért az NFS blokkokat több Ethernet csomagra kell osztani — még olyankor is, ha ez a program felsõbb rétegeiben osztatlan egységként látszik — ezt aztán fogadni kell, összerakni és nyugtázni mint egységet. A nagyteljesítményû munkaállomások a szabvány által még éppen megengedett szorossággal képesek ontani magukból az egy egységhez tartozó csomagokat, közvetlenül egymás után. A kisebb, gyengébb teljesítményû kártyák esetében azonban az egymáshoz tartozó, késõbb érkezõ csomagok ráfutnak a korábban megkapott csomagokra még pontosan azelõtt, hogy elérnék a gépet, így az egységek nem állíthatóak össze vagy nem nyugtázhatóak. Ennek eredményeképpen a munkaállomás egy adott idõ múlva megint próbálkozik, de ismét az egész 8 kilobyte-os blokkot küldi el, ezért ez a folyamat a végtelenségig ismétlõdik. Ha a küldendõ egységek méretét az Ethernet által kezelt csomagok maximális mérete alá csökkentjük, akkor biztosak lehetünk benne, hogy a teljes Ethernet csomag egyben megérkezik és nyugtázódik, így elkerüljük a holtpontot. A nagyteljesítményû munkaállomások természetesen továbbra is küldhetnek a PC-s rendszerek felé túlfutó csomagokat, de egy jobb kártyával az ilyen túlfutások nem érintik az NFS által használt egységeket. Amikor egy ilyen túlfutás bekövetkezik, az érintett egységet egyszerûen újra elküldik, amelyet a rákövetkezõ alkalommal nagy valószínûséggel már tudunk rendesen fogadni, összerakni és nyugtázni. Bill Swingle Írta: Eric Ogren Írta: Udo Erdelhoff Hálózati információs rendszer (NIS/YP) Mi ez? NIS Solaris HP-UX AIX Linux NetBSD OpenBSD A hálózati információs szolgáltatást (Network Information Service, avagy NIS) a Sun Microsystems fejlesztette ki a &unix; (eredetileg &sunos;) rendszerek központosított karbantartásához. Mostanra már lényegében ipari szabvánnyá nõtte ki magát, hiszen az összes nagyobb &unix;-szerû rendszer (a &solaris;, HP-UX, &aix;, Linux, NetBSD, OpenBSD, &os; stb.) támogatja a NIS használatát. sárga oldalak NIS A NIS régebben sárga oldalak (Yellow Pages) néven volt ismert, de a különbözõ jogi problémák miatt késõbb ezt a Sun megváltoztatta. A régi elnevezést (és a yp rövidítést) azonban még napjainkban is lehet néhol látni. NIS tartományok Ez egy RPC alapján mûködõ, kliens/szerver felépítésû rendszer, amely az egy NIS tartomány belül levõ számítógépek számára teszi lehetõvé ugyanazon konfigurációs állományok használatát. Segítségével a rendszergazda a NIS klienseket a lehetõ legkevesebb adat hozzáadásával, eltávolításával vagy módosításával képes egyetlen helyrõl beállítani. Windows NT Hasonló a &windowsnt; tartományaihoz, és habár a belsõ implementációt tekintve már akadnak köztük jelentõs eltérések is, az alapvetõ funkciók szintjén mégis összevethetõek. A témához tartozó fogalmak és programok A NIS telepítése számos fogalom és fontos felhasználói program kerül elõ &os;-n, akár egy NIS szervert akarunk beállítani, akár csak egy NIS klienst: rpcbind portmap Fogalom Leírás NIS tartománynév A NIS központi szerverei és az összes hozzájuk tartozó kliens (beleértve az alárendelt szervereket) rendelkezik egy NIS tartománynévvel. Hasonló a &windowsnt; által használt tartománynevekhez, de a NIS tartománynevei semmilyen kapcsolatban nem állnak a névfeloldással. rpcbind Az RPC (Remote Procedure Call, a NIS által használt egyik hálózati protokoll) engedélyezéséhez lesz rá szükségünk. Ha az rpcbind nem fut, akkor sem NIS szervert, sem pedig NIS klienst nem tudunk mûködtetni. ypbind A NIS klienst köti össze a hozzá tartozó NIS szerverrel. A NIS tartománynevet a rendszertõl veszi, és az RPC használatával csatlakozik a szerverhez. Az ypbind a NIS környezet kliens és szerver közti kommunikációjának magját alkotja. Ha az ypbind leáll a kliens gépén, akkor nem tudjuk elérni a NIS szervert. ypserv Csak a NIS szervereken szabad futnia, mivel ez maga a NIS szerver programja. Ha az &man.ypserv.8; leáll, akkor a szerver nem lesz képes tovább kiszolgálni a NIS kéréseket (szerencsére az alárendelt szerverek képesek átvenni ezeket). A NIS bizonyos változatai (de nem az, amelyik a &os;-ben is megjelenik) nem próbálnak meg más szerverekhez csatlakozni, ha bedöglik az aktuális használt szerver. Ezen gyakran egyedül csak a szervert képviselõ program (vagy akár az egész szerver) újraindítása segíthet, illetve az ypbind újraindítása a kliensen. rpc.yppasswdd Ez egy olyan program, amelyet csak a NIS központi szerverein kell csak futtatni. Ez a démon a NIS kliensek számára a NIS jelszavaik megváltoztatását teszi lehetõvé. Ha ez a démon nem fut, akkor a felhasználók csak úgy tudják megváltoztatni a jelszavukat, ha bejelentkeznek a központi NIS szerverre. Hogyan mûködik? A NIS környezetekben háromféle gép létezik: a központi szerverek, az alárendelt szerverek és a kliensek. A szerverek képezik a gépek konfigurációs információinak központi tárhelyét. A központi szerverek tárolják ezen információk hiteles másolatát, míg ezt az alárendelt szerverek redundánsan tükrözik. A kliensek a szerverekre támaszkodnak ezen információk beszerzéséhez. Sok állomány tartalma megosztható ezen a módon. Például a master.passwd, a group és hosts állományokat meg szokták osztani NFS-en. Amikor a kliensen futó valamelyik programnak olyan információra lenne szüksége, amely általában ezekben az állományokban nála megtalálható lenne, akkor helyette a NIS szerverhez fordul. A gépek típusai NIS központi szerver A központi NIS szerver. Ez a szerver, amely leginkább a &windowsnt; elsõdleges tartományvezérlõjéhez hasonlítható tartja karban az összes, NIS kliensek által használt állományt. A passwd, group, és összes többi ehhez hasonló állomány ezen a központi szerveren található meg. Egy gép akár több NIS tartományban is lehet központi szerver. Ezzel a lehetõséggel viszont itt most nem foglalkozunk, mivel most csak egy viszonylag kis méretû NIS környezetet feltételezünk. NIS alárendelt szerver Az alárendelt NIS szerverek. A &windowsnt; tartalék tartományvezérlõihez hasonlítanak, és az alárendelt NIS szerverek feladata a központi NIS szerveren tárolt adatok másolatainak karbantartása. Az alárendelt NIS szerverek a redundancia megvalósításában segítenek, aminek leginkább a fontosabb környezetekben van szerepe. Emellett a központi szerver terhelésének kiegyenlítését is elvégzik. A NIS kliensek elsõként mindig ahhoz a NIS szerverhez csatlakoznak, amelytõl elõször választ kapnak, legyen akár az egy alárendelt szerver. NIS kliens A NIS kliensek. A NIS kliensek, hasonlóan a &windowsnt; munkaállomásokhoz, a NIS szerveren (amely a &windowsnt; munkaállomások esetében a tartományvezérlõ) keresztül jelentkeznek be. A NIS/YP használata Ebben a szakaszban egy példa NIS környezetet állítunk be. Tervezés Tegyük fel, hogy egy aprócska egyetemi labor rendszergazdái vagyunk. A labor, mely 15 &os;-s gépet tudhat magáénak, jelen pillanatban még semmilyen központosított adminisztráció nem létezik. Mindegyik gép saját /etc/passwd és /etc/master.passwd állománnyal rendelkezik. Ezeket az állományokat saját kezûleg kell szinkronban tartani. Tehát ha most felveszünk egy felhasználót a laborhoz, akkor az adduser parancsot mind a 15 gépen ki kell adni. Egyértelmû, hogy ez így nem maradhat, ezért úgy döntöttük, hogy a laborban NIS-t fogunk használni, és két gépet kinevezünk szervernek. Az iméntieknek megfelelõen a labor most valahogy így néz ki: A gép neve IP-cím A gép szerepe ellington 10.0.0.2 központi NIS coltrane 10.0.0.3 alárendelt NIS basie 10.0.0.4 tanszéki munkaállomás bird 10.0.0.5 kliensgép cli[1-11] 10.0.0.[6-17] a többi kliensgép Ha még nincs tapasztalatunk a NIS rendszerek összeállításában, akkor elõször jó ötlet lehet végiggondolni, miként is akarjuk kialakítani. A hálózatunk méretétõl függetlenül is akadnak olyan döntések, amelyeket mindenképpen meg kell hoznunk. A NIS tartománynév megválasztása NIS tartománynév Ez nem az a tartománynév, amit megszokhattunk. Ennek a pontos neve NIS tartománynév. Amikor a kliensek kérnek valamilyen információt, akkor megadják annak a NIS tartománynak a nevét is, amelynek részei. Így tud egy hálózaton több szerver arról dönteni, hogy melyikük melyik kérést válaszolja meg. A NIS által használt tartománynévre tehát inkább úgy érdemes gondolni, mint egy valamilyen módon összetartozó gépek közös nevére. Elõfordul, hogy egyes szervezetek az interneten is nyilvántartott tartománynevüket választják NIS tartománynévnek. Ez alapvetõen nem ajánlott, mivel a hálózati problémák felderítése közben félreértéseket szülhet. A NIS tartománynévnek a hálózatunkon belül egyedinek kell lennie, és lehetõleg minél jobban írja le az általa csoportba sorolt gépeket. Például a Kis Kft. üzleti osztályát tegyük a kis-uzlet NIS tartományba. Ebben a példában most a proba-tartomany nevet választottuk. SunOS A legtöbb operációs rendszer azonban (köztük a &sunos;) a NIS tartománynevet használja internetes tartománynévként is. Ha a hálózatunkon egy vagy több ilyen gép is található, akkor a NIS tartomány nevének az internetes tartománynevet kell megadnunk. A szerverek fizikai elvárásai Nem árt néhány dolgot fejben tartani, amikor a NIS szervernek használt gépet kiválasztjuk. Az egyik ilyen szerencsétlen dolog az a szintû függõség, ami a NIS kliensek felõl megfigyelhetõ a szerverek felé. Ha egy kliens nem tudja a NIS tartományon belül felvenni a kapcsolatot valamelyik szerverrel, akkor az a gép könnyen megbízhatatlanná válhat. Felhasználói- és csoportinformációk nélkül a legtöbb rendszer egy idõre le is merevedik. Ennek figyelembevételével tehát olyan gépet kell szervernek választanunk, amelyet nem kell gyakran újraindítani, és nem végzünk rajta semmilyen komoly munkát. A célnak legjobban megfelelõ NIS szerverek valójában olyan gépek, amelyek egyedüli feladata csak a NIS kérések kiszolgálása. Ha a hálózatunk nem annyira leterhelt, akkor még a NIS szerver mellett más programokat is futtathatunk, de ne feledjük, hogy ha a NIS szolgáltatás megszûnik, akkor az az összes NIS kliensen éreztetni fogja kedvezõtlen hatását. A NIS szerverek A NIS rendszerben tárolt összes információ általános példánya egyetlen gépen található meg, amelyet a központi NIS szervernek hívunk. Az információk tárolására szánt adatbázis pedig NIS táblázatoknak (NIS map) nevezzük. &os; alatt ezek a táblázatok a /var/yp/tartománynév könyvtárban találhatóak, ahol a tartománynév a kiszolgált NIS tartományt nevezi meg. Egyetlen NIS szerver egyszerre akár több tartományt is kiszolgálhat, így itt több könyvtár is található, minden támogatott tartományhoz egy. Minden tartomány saját, egymástól független táblázatokkal rendelkezik. A központi és alárendelt NIS szerverek az ypserv démon segítségével dolgozzák fel a NIS kéréseket. Az ypserv felelõs a NIS kliensektõl befutó kérések fogadásáért, és a kért tartomány valamint táblázat nevébõl meghatározza az adatbázisban tárolt állományt, majd innen visszaküldi a hozzá tartozó adatot a kliensnek. A központi NIS szerver beállítása NIS szerver beállítása A központi NIS szerver beállítása viszonylag magától értetõdõ, de a nehézségét az igényeink szabják meg. A &os; alapból támogatja a NIS használatát. Ezért mindössze annyit kell tennünk, hogy a következõ sorokat betesszük az /etc/rc.conf állományba, és a &os; gondoskodik a többirõl. nisdomainname="proba-tartomany" Ez a sor adja meg a hálózati beállítások (vagy például az újraindítás) során a NIS tartomány nevét, amely a korábbiak szerint itt most a proba-tartomany. nis_server_enable="YES" Ezzel utasítjuk a &os;-t, hogy a hálózati alkalmazások következõ indításakor a NIS szervert is aktiválja. nis_yppasswdd_enable="YES" Ezzel engedélyezzük az rpc.yppasswdd démont, amely a korábban említettek szerint lehetõvé teszi a felhasználók számára, hogy a közvetlenül a kliensekrõl változtassák meg a NIS jelszavukat. A konkrét NIS beállításainktól függõen további bejegyzések felvételére is szükségünk lehet. Erre késõbb még az olyan NIS szervereknél, amelyek egyben NIS kliensek, vissza fogunk térni. Miután ezeket beállítottuk, rendszeradminisztrátorként adjuk ki az /etc/netstart parancsot. Az /etc/rc.conf állományban szereplõ adatok alapján mindent beállít magától. Még mielõtt inicializálnánk a NIS táblázatokat, indítsuk el manuálisan az ypserv démont: &prompt.root; /etc/rc.d/ypserv start A NIS táblázatok inicializálása NIS táblázatok A NIS táblázatok lényegében a /var/yp könyvtárban tárolt adatbázisok. A központi NIS szerver /etc könyvtárában található konfigurációs állományokból állítódnak elõ, egyetlen kivétellel: ez az /etc/master.passwd állomány. Ennek megvan a maga oka, hiszen nem akarjuk a root és az összes többi fontosabb felhasználóhoz tartozó jelszót az egész NIS tartománnyal megosztani. Ennek megfelelõen a NIS táblázatok inicializálásához a következõt kell tennünk: &prompt.root; cp /etc/master.passwd /var/yp/master.passwd &prompt.root; cd /var/yp &prompt.root; vi master.passwd El kell távolítanunk az összes rendszerszintû (bin, tty, kmem, games, stb), és minden olyan egyéb hozzáférést, amelyeket nem akarjuk közvetíteni a NIS kliensek felé (például a root és minden más nullás, vagyis rendszeradminisztrátori azonosítóval ellátott hozzáférést). Gondoskodjunk róla, hogy az /var/yp/master.passwd állomány sem a csoport, sem pedig bárki más számára nem olvasható (600-as engedély)! Ennek beállításához használjuk az chmod parancsot, ha szükséges. Tru64 UNIX Ha végeztünk, akkor már tényleg itt az ideje inicializálni NIS táblázatainkat. A &os; erre egy ypinit nevû szkriptet ajánl fel (errõl a saját man oldalán tudhatunk meg többet). Ez a szkript egyébként a legtöbb &unix; típusú operációs rendszeren megtalálható, de nem az összesen. A Digital UNIX/Compaq Tru64 UNIX rendszereken ennek a neve ypsetup. Mivel most a központi NIS szerver táblázatait hozzuk létre, azért az ypinit szkriptnek át kell adnunk a opciót is. A NIS táblázatok elõállításánál feltételezzük, hogy a fentebb ismertetett lépéseket már megtettük, majd kiadjuk ezt a parancsot: ellington&prompt.root; ypinit -m proba-tartomany Server Type: MASTER Domain: proba-tartomany Creating an YP server will require that you answer a few questions. Questions will all be asked at the beginning of the procedure. Do you want this procedure to quit on non-fatal errors? [y/n: n] n Ok, please remember to go back and redo manually whatever fails. If you don't, something might not work. At this point, we have to construct a list of this domains YP servers. rod.darktech.org is already known as master server. Please continue to add any slave servers, one per line. When you are done with the list, type a <control D>. master server : ellington next host to add: coltrane next host to add: ^D The current list of NIS servers looks like this: ellington coltrane Is this correct? [y/n: y] y [ .. a táblázatok generálása .. ] NIS Map update completed. ellington has been setup as an YP master server without any errors. Az üzenetek fordítása: A szerver típusa: KÖZPONTI, tartomány: proba-tartomany Az YP szerver létrehozásához meg kell válaszolni néhány kérdést az eljárás megkezdése elõtt. Szeretnénk, ha az eljárás megszakadna a nem végzetes hibák esetén is? [i/n: n] n Rendben, akkor ne felejtsük el manuálisan kijavítani a hibát, ha valamivel gond lenne. Ha nem tesszük meg, akkor elõfordulhat, hogy valami nem fog rendesen mûködni. Most össze kell állítanunk egy listát a tartomány YP szervereirõl. Jelenleg a rod.darktech.org a központi szerver. Kérjünk, adjon meg további alárendelt szervereket, soronként egyet. Amikor ezt befejeztük, a <control D> lenyomásával tudunk kilépni. központi szerver : ellington következõ gép : coltrane következõ gép : ^D A NIS szerverek listája jelenleg a következõ: ellington coltrane Ez megfelelõ? [i/n: i] i [ .. a táblázatok generálása .. ] A NIS táblázatok sikeressen frissültek. Az elligon szervert minden hiba nélkül sikerült központi szerverként beállítani. Az ypinit a /var/yp/Makefile.dist állományból létrehozza a /var/yp/Makefile állományt. Amennyiben ez létrejött, az állomány feltételezi, hogy csak &os;-s gépek részvételével akarunk kialakítani egy egyszerveres NIS környezetet. Mivel a proba-tartomany még egy alárendelt szervert is tartalmaz, ezért át kell írnunk a /var/yp/Makefile állományt: ellington&prompt.root; vi /var/yp/Makefile Ezt a sort kell megjegyzésbe tennünk: NOPUSH = "True" (ha még nem lenne úgy). Az alárendelt NIS szerverek beállítása NIS alárendelt szerver Az alárendelt NIS szerverek beállítása még a központinál is egyszerûbb. Jelentkezzünk be az alárendelt szerverre és az eddigieknek megfelelõen írjuk át az /etc/rc.conf állományt. Az egyetlen különbség ezúttal csupán annyi lesz, hogy az ypinit lefuttatásakor a opciót kell megadnunk (mint slave, vagyis alárendelt). A opció használatához a központi NIS szerver nevét is át kell adnunk, ezért a konkrét parancs valahogy így fog kinézni: coltrane&prompt.root; ypinit -s ellington proba-tartomany Server Type: SLAVE Domain: test-domain Master: ellington Creating an YP server will require that you answer a few questions. Questions will all be asked at the beginning of the procedure. Do you want this procedure to quit on non-fatal errors? [y/n: n] n Ok, please remember to go back and redo manually whatever fails. If you don't, something might not work. There will be no further questions. The remainder of the procedure should take a few minutes, to copy the databases from ellington. Transferring netgroup... ypxfr: Exiting: Map successfully transferred Transferring netgroup.byuser... ypxfr: Exiting: Map successfully transferred Transferring netgroup.byhost... ypxfr: Exiting: Map successfully transferred Transferring master.passwd.byuid... ypxfr: Exiting: Map successfully transferred Transferring passwd.byuid... ypxfr: Exiting: Map successfully transferred Transferring passwd.byname... ypxfr: Exiting: Map successfully transferred Transferring group.bygid... ypxfr: Exiting: Map successfully transferred Transferring group.byname... ypxfr: Exiting: Map successfully transferred Transferring services.byname... ypxfr: Exiting: Map successfully transferred Transferring rpc.bynumber... ypxfr: Exiting: Map successfully transferred Transferring rpc.byname... ypxfr: Exiting: Map successfully transferred Transferring protocols.byname... ypxfr: Exiting: Map successfully transferred Transferring master.passwd.byname... ypxfr: Exiting: Map successfully transferred Transferring networks.byname... ypxfr: Exiting: Map successfully transferred Transferring networks.byaddr... ypxfr: Exiting: Map successfully transferred Transferring netid.byname... ypxfr: Exiting: Map successfully transferred Transferring hosts.byaddr... ypxfr: Exiting: Map successfully transferred Transferring protocols.bynumber... ypxfr: Exiting: Map successfully transferred Transferring ypservers... ypxfr: Exiting: Map successfully transferred Transferring hosts.byname... ypxfr: Exiting: Map successfully transferred coltrane has been setup as an YP slave server without any errors. Don't forget to update map ypservers on ellington. Most már lennie kell egy /var/yp/proba-tartomany nevû könyvtárunknak is. A központi NIS szerver táblázatainak másolata itt fognak tárolódni. Ezeket soha ne felejtsük el frissen tartani. Az alárendelt szervereken a következõ /etc/crontab bejegyzések pontosan ezt a feladatot látják el: 20 * * * * root /usr/libexec/ypxfr passwd.byname 21 * * * * root /usr/libexec/ypxfr passwd.byuid Ez a két sor gondoskodik róla, hogy az alárendelt szerverek ne felejtsék el egyeztetni a táblázataikat a központi szerver táblázataival. Ezek a bejegyzések nem nélkülözhetetlenek a megfelelõ mûködéshez, mivel a központi szerver automatikusan feltölti az alárendelt szerverekre a létrejött változásokat. Mivel azonban a jelszavak létfontosságúak a szervertõl függõ rendszerek számára, ezért ajánlott explicit módon is elõírni a frissítést. Ez a forgalmasabb hálózatokon nagyobb jelentõséggel bír, mivel ott a táblázatok frissítése nem mindig fejezõdik be rendesen. Most pedig futassuk le a /etc/netstart parancsot az alárendelt szervereken is, amivel így elindul a NIS szerver. A NIS kliensek A NIS kliens az ypbind démon segítségével egy kötésnek (bind) nevezett kapcsolatot épít ki egy adott NIS szerverrel. Az ypbind ellenõrzi a rendszer alapértelmezett tartományát (ezt a domainname paranccsal állítottunk be), majd RPC kéréseket kezd szórni a helyi hálózaton. Ezek a kérések annak a tartománynak a nevét tartalmazzák, amelyhez az ypbind megpróbál kötést létrehozni. Ha az adott tartomány kiszolgálására beállított szerver észleli ezeket a kéréseket, akkor válaszol az ypbind démonnak, amely pedig feljegyzi a szerver címét. Ha több szerver is elérhetõ (például egy központi és több alárendelt), akkor az ypbind az elsõként válaszoló címét fogja rögzíteni. Innentõl kezdve a kliens közvetlenül ennek a szervernek fogja küldeni a NIS kéréseit. Az ypbind idõnként megpingeli a szervert, hogy meggyõzõdjön az elérhetõségérõl. Ha az ypbind egy adott idõn belül nem kap választ a ping kéréseire, akkor megszünteti a kötést a tartományhoz és nekilát keresni egy másik szervert. A NIS kliensek beállítása NIS a kliensek beállítása Egy &os;-s gépet NIS kliensként meglehetõsen egyszerûen lehet beállítani. Nyissuk meg az /etc/rc.conf állományt és a NIS tartománynév beállításához, valamint az ypbind elindításához a következõket írjuk bele: nisdomainname="proba-tartomany" nis_client_enable="YES" A NIS szerveren található jelszavak importálásához távolítsuk el az összes felhasználói hozzáférést az /etc/master.passwd állományunkból és a vipw segítségével adjuk hozzá az alábbi sort az állomány végéhez: +::::::::: Ez a sor beenged bárkit a rendszerünkre, akinek a NIS szervereken van érvényes hozzáférése. A NIS klienseket ezzel a sorral sokféle módon tudjuk állítani. A hálózati csoportokról szóló szakaszban találunk majd errõl több információt. A téma mélyebb megismeréséhez az O'Reilly Managing NFS and NIS címû könyvét ajánljuk. Legalább helyi hozzáférést (vagyis amit nem NIS-en keresztül importálunk) azonban mindenképpen hagyjunk meg az /etc/master.passwd állományunkban, és ez a hozzáférés legyen a wheel csoport tagja. Ha valami gond lenne a NIS használatával, akkor ezen a hozzáférésen keresztül tudunk a gépre távolról bejelentkezni, majd innen root felhasználóra váltva megoldani a felmerült problémákat. A NIS szerverrõl az összes lehetséges csoport-bejegyzést az /etc/group állományban így tudjuk importálni: +:*:: Miután elvégeztük ezeket a lépéseket, képesek leszünk futtatni az ypcat passwd parancsot, és látni a NIS szerver jelszavakat tartalmazó táblázatát. A NIS biztonsága Általában tetszõleges távoli felhasználó küldhet RPC kéréseket az &man.ypserv.8; számára és kérheti le a NIS táblázatok tartalmát, feltéve, hogy ismeri a tartomány nevét. Az ilyen hitelesítés nélküli mûveletek ellen az &man.ypserv.8; úgy védekezik, hogy tartalmaz egy securenets nevû lehetõséget, amellyel az elérhetõségüket tudjuk leszûkíteni gépek egy csoportjára. Az &man.ypserv.8; indításakor ezeket az információkat a /var/yp/securenets állományból próbálja meg betölteni. Az elérési útvonala megadható a opció használatával. Ez az állomány olyan bejegyzéseket tartalmaz, amelyekben egy hálózati cím és tõle láthatatlan karakterekkel elválasztva egy hálózati maszk szerepel. A # karakterrel kezdõdõ sorokat megjegyzésnek nyilvánítjuk. Egy minta securenets állomány valahogy így nézne ki: # Engedélyezzük önmagunkról a csatlakozást -- kell! 127.0.0.1 255.255.255.255 # Engedélyezzük a 192.168.128.0 hálózatról érkezõ csatlakozásokat: 192.168.128.0 255.255.255.0 # Engedélyezzük a laborban található 10.0.0.0 és 10.0.15.255 közti # címekkel rendelkezõ gépek csatlakozását: 10.0.0.0 255.255.240.0 Ha az &man.ypserv.8; olyan címrõl kap kérést, amely illeszkedik az elõírt címek valamelyikére, akkor a szokásos módon feldolgozza azt. Ellenkezõ esetben a kérést figyelmen kívül hagyja és egy figyelmeztetést vesz fel hozzá a naplóba. Ha a /var/yp/securenets állomány nem létezik, akkor az ypserv tetszõleges géprõl engedélyezi a csatlakozást. Az ypserv lehetõséget ad a Wietse Venema által fejlesztett TCP Wrapper csomag használatára is. Ezzel a rendszergazda a /var/yp/securenets állomány helyett a TCP Wrapper konfigurációs állományai alapján képes szabályozni az elérhetõséget. Miközben mind a két módszer nyújt valamilyen fajta védelmet, de a privilegizált portok teszteléséhez hasonlóan az IP álcázásával (IP spoofing) sebezhetõek. Ezért az összes NIS-hez tartozó forgalmat tûzfallal kell blokkolnunk. Az /var/yp/securenets állományt használó szerverek nem képesek az elavult TCP/IP implementációkat használó érvényes klienseket rendesen kiszolgálni. Egyes ilyen implementációk a címben a géphez tartozó biteket nullára állítják az üzenetszóráshoz, és/vagy ezért az üzenetszóráshoz használt cím kiszámításakor nem tudja észleli a hálózati maszkot. A legtöbb ilyen probléma megoldható a kliens konfigurációjának megváltoztatásával, míg más problémák megoldása a kérdéses kliensek nyugdíjazását kívánják meg, vagy a /var/yp/securenets használatának elhagyását. Egy régebbi TCP/IP implementációval üzemelõ szerveren pedig a /var/yp/securenets állomány használata kifejezetten rossz ötlet, és a hálózatunk nagy részében képes használhatatlanná tenni a NIS funkcióit. TCP wrapperek A TCP Wrapper csomag alkalmazása a NIS szerverünk válaszadáshoz szükséges idejét is segít csökkenteni. Az ilyenkor jelentkezõ plusz késlekedés mellesleg elég nagy lehet ahhoz, hogy a klienseknél idõtúllépés következzen be, különösen a terheltebb hálózatokon vagy a lassú NIS szerverek esetében. Ha egy vagy több kliensünk is ilyen tüneteket mutat, akkor érdemes a kérdéses kliens rendszereket alárendelt NIS szerverekké alakítani és önmagukhoz rendelni. Egyes felhasználók bejelentkezésének megakadályozása A laborunkban van egy basie nevû gép, amely a tanszék egyetlen munkaállomása. Ezt a gépet nem akarjuk kivenni a NIS tartományból, de a központi NIS szerver passwd állománya mégis egyaránt tartalmazza a hallgatók és az oktatók eléréseit. Mit lehet ilyenkor tenni? Adott felhasználók esetében le tudjuk tiltani a bejelentkezést a gépen még olyankor is, ha léteznek a NIS adatbázisában. Ehhez mindössze a kliensen az /etc/master.passwd állomány végére be kell tennünk egy -felhasználónév sort, ahol a felhasználónév annak a felhasználónak a neve, akit nem akarunk beengedni a gépre. Ezt leginkább a vipw használatán keresztül érdemes megtennünk, mivel a vipw az /etc/master.passwd állomány alapján végez némi ellenõrzést, valamint a szerkesztés befejeztével magától újragenerálja a jelszavakat tároló adatbázist. Például, ha a bill nevû felhasználót ki akarjuk tiltani a basie nevû géprõl, akkor: basie&prompt.root; vipw [vegyük fel a -bill sort a végére, majd lépjünk ki] vipw: rebuilding the database... vipw: done basie&prompt.root; cat /etc/master.passwd root:[jelszó]:0:0::0:0:The super-user:/root:/bin/csh toor:[jelszó]:0:0::0:0:The other super-user:/root:/bin/sh daemon:*:1:1::0:0:Owner of many system processes:/root:/sbin/nologin operator:*:2:5::0:0:System &:/:/sbin/nologin bin:*:3:7::0:0:Binaries Commands and Source,,,:/:/sbin/nologin tty:*:4:65533::0:0:Tty Sandbox:/:/sbin/nologin kmem:*:5:65533::0:0:KMem Sandbox:/:/sbin/nologin games:*:7:13::0:0:Games pseudo-user:/usr/games:/sbin/nologin news:*:8:8::0:0:News Subsystem:/:/sbin/nologin man:*:9:9::0:0:Mister Man Pages:/usr/share/man:/sbin/nologin bind:*:53:53::0:0:Bind Sandbox:/:/sbin/nologin uucp:*:66:66::0:0:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico xten:*:67:67::0:0:X-10 daemon:/usr/local/xten:/sbin/nologin pop:*:68:6::0:0:Post Office Owner:/nonexistent:/sbin/nologin nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/sbin/nologin +::::::::: -bill basie&prompt.root; Udo Erdelhoff Készítette: A hálózati csoportok alkalmazása hálózati csoportok Az elõzõ szakaszban ismertetett módszer viszonylag jól mûködik olyan esetekben, amikor nagyon kevés felhasználóra és/vagy számítógépre kell alkalmaznunk speciális megszorításokat. A nagyobb hálózatokban szinte biztos, hogy elfelejtünk kizárni egyes felhasználókat az érzékeny gépekrõl, vagy az összes gépen egyenként kell ehhez a megfelelõ beállításokat elvégezni, és ezzel lényegében elvesztjük a NIS legfontosabb elõnyét, vagyis a központosított karbantarthatóságot. A NIS fejlesztõi erre a problémára a hálózati csoportokat létrehozásával válaszoltak. A céljuk és mûködésük szempontjából leginkább a &unix;-os állományrendszerekben található csoportokhoz mérhetõek. A legnagyobb eltérés a numerikus azonosítók hiányában mutatkozik meg, valamint a hálózati csoportokat a felhasználókon kívül további hálózati csoportok megadásával is ki lehet alakítani. A hálózati csoportok a nagyobb, bonyolultabb, többszáz felhasználós hálózatok számára jöttek létre. Egy részrõl ez nagyon jó dolog, különösen akkor, ha egy ilyen helyzettel kell szembenéznünk. Másrészrõl ez a mértékû bonyolultság szinte teljesen lehetetlenné teszi a hálózati csoportok egyszerû bemutatását. A szakasz további részében használt példa is ezt a problémát igyekszik illusztrálni. Tételezzük fel, hogy laborunkban a NIS sikeres bevezetése felkeltette a fõnökeink figyelmét. Így a következõ feladatunk az lett, hogy terjesszük ki a NIS tartományt az egyetemen található néhány másik gépre is. Az alábbi két táblázatban az új felhasználók és az új számítógép neveit találjuk, valamint a rövid leírásukat. Felhasználók nevei Leírás alpha, beta az IT tanszék hétköznapi dolgozói charlie, delta az IT tanszék újdonsült dolgozói echo, foxtrott, golf, ... átlagos dolgozók able, baker, ... ösztöndíjasok Gépek nevei Leírás haboru, halal, ehseg, szennyezes A legfontosabb szervereink. Csak az IT tanszék dolgozói férhetnek hozzájuk. buszkeseg, kapzsisag, irigyseg, harag, bujasag, lustasag Kevésbé fontos szerverek. Az IT tankszék összes tagja el tudja érni ezeket a gépeket. egy, ketto, harom, negy, ... Átlagos munkaállomások. Egyedül csak a valódi dolgozók jelentkezhetnek be ezekre a gépekre. szemetes Egy nagyon régi gép, semmi értékes adat nincs rajta. Akár még az öszöndíjasok is nyúzhatják. Ha ezeket az igényeket úgy próbáljuk meg teljesíteni, hogy a felhasználókat egyenként blokkoljuk, akkor minden rendszer passwd állományába külön fel kell vennünk a -felhasználó sorokat a letiltott felhasználókhoz. Ha csak egyetlen bejegyzést is kihagyunk, akkor könnyen bajunk származhat belõle. Ez a rendszer kezdeti beállítása során még talán nem okoz gondot, de az új felhasználókat biztosan el fogjuk felejteni felvenni a megfelelõ csoportokba. Elvégre Murphy is optimista volt. A hálózati csoportok használata ilyen helyzetekben számos elõnyt rejt. Nem kell az egyes felhasználókat külön felvenni, egy felhasználót felveszünk valamelyik csoportba vagy csoportokba, és a csoportok összes tagjának egyszerre tudjuk tiltani vagy engedélyezni a hozzáféréseket. Ha hozzáadunk egy új gépet a hálózatunkhoz, akkor mindössze a hálózati csoportok bejelentkezési korlátozásait kell beállítani. Ha új felhasználót veszünk fel, akkor a felhasználót kell vennünk egy vagy több hálózati csoportba. Ezek a változtatások függetlenek egymástól, és nincs szükség minden felhasználó és minden gép összes kombinációjára. Ha a NIS beállításainkat elõzetesen körültekintõen megterveztük, akkor egyetlen központi konfigurációs állományt kell módosítani a gépek elérésének engedélyezéséhez vagy tiltásához. Az elsõ lépés a hálózati csoportokat tartalmazó NIS táblázat inicializálása. A &os; &man.ypinit.8; programja alapértelmezés szerint nem hozza létre ezt a táblázatot, de ha készítünk egy ilyet, akkor a NIS implementációja képes kezelni. Egy ilyen üres táblázat elkészítéséhez ennyit kell begépelni: ellington&prompt.root; vi /var/yp/netgroup Ezután elkezdhetjük felvenni a tartalmát. A példánk szerint legalább négy hálózati csoportot kell csinálnunk: az IT dolgozóinak, az IT új dolgozóinak, a normál dolgozóknak és az öszöndíjasoknak. IT_DOLG (,alpha,proba-tartomany) (,beta,proba-tartomany) IT_UJDOLG (,charlie,proba-tartomany) (,delta,proba-tartomany) FELHASZNALO (,echo,proba-tartomany) (,foxtrott,proba-tartomany) \ (,golf,proba-tartomany) OSZTONDIJAS (,able,proba-tartomany) (,baker,proba-tartomany) Az IT_DOLG, IT_UJDOLG stb. a hálózati csoportok nevei lesznek. Minden egyes zárójelezett csoport egy vagy több felhasználói hozzáférést tartalmaz. A csoportokban szereplõ három mezõ a következõ: Azon gépek neve, amelykre a következõ elemek érvényesek. Ha itt nem adunk meg neveket, akkor a bejegyzés az összes gépre vonatkozik. Ha megadjuk egy gép nevét, akkor jutalmunk a teljes sötétség, a rettegetés és totális megtébolyodás. A csoporthoz tartozó hozzáférés neve. A hozzáféréshez kapcsolódó NIS tartomány. A csoportba más NIS tartományokból is át tudunk hozni hozzáféréseket, ha netalán éppen olyan szerencsétlenek lennénk, hogy több NIS tartományt is felügyelnünk kell. A mezõk mindegyike tartalmazhat dzsókerkaraktereket. Errõl részletesebben a &man.netgroup.5; man oldalon olvashatunk. hálózati csoportok A hálózati csoportoknak lehetõleg ne adjunk 8 karakternél hosszabb nevet, különösen abban az esetben, ha a NIS tartományban más operációs rendszereket is használunk. A nevekben eltérnek a kis- és nagybetûk. Ha a hálózati csoportokat nevét nagybetûkkel írjuk, akkor könnyen különbséget tudunk tenni a felhasználók, gépek és hálózati csoportok nevei között. Egyes (nem &os; alapú) NIS kliensek nem képesek kezelni a nagyon sok bejegyzést tartalmazó hálózati csoportokat. Például a &sunos; néhány korábbi verziója fennakad rajta, ha egy hálózati csoport 15 bejegyzésnél többet tartalmaz. Az ilyen korlátozások alól úgy tudunk kibújni, ha 15 felhasználónként újabb hálózati csoportokat hozunk létre, amelyekkel az eredeti hálózati csoportot építjük fel: NAGYCSP1 (,joe1,tartomany) (,joe2,tartomany) (,joe3,tartomany) [...] NAGYCSP2 (,joe16,tartomany) (,joe17,tartomany) [...] NAGYCSP3 (,joe31,tartomany) (,joe32,tartomany) NAGYCSOPORT NAGYCSP1 NAGYCSP2 NAGYCSP3 Ugyanez a folyamat javasolt olyan esetekben is, ahol 225 felhasználónál többre lenne szükség egyetlen hálózati csoporton belül. Az így létrehozott új NIS táblázat szétküldése meglehetõsen könnyû feladat: ellington&prompt.root; cd /var/yp ellington&prompt.root; make Ez a parancs létrehoz három NIS táblázatot: netgroup, netgroup.byhost és netgroup.byuser. Az &man.ypcat.1; paranccsal ellenõrizni is tudjuk az új NIS táblázatainkat: ellington&prompt.user; ypcat -k netgroup ellington&prompt.user; ypcat -k netgroup.byhost ellington&prompt.user; ypcat -k netgroup.byuser Az elsõ parancs kimenete a /var/yp/netgroup állomány tartalmára emlékeztethet minket. A második parancsnak nincs semmilyen kimenete, hacsak nem adtunk meg valamilyen gépfüggõ hálózati csoportot. A harmadik parancs a hálózati csoportokat listázza ki a felhasználókhoz. A kliensek beállítása tehát nagyon egyszerû. A haboru nevû szerver beállításához indítsuk el a &man.vipw.8; programot, és cseréljük a +::::::::: sort erre: +@IT_DOLG::::::::: Innentõl kezdve kizárólag csak az IT_DOLG csoportban található felhasználók fognak bekerülni a haboru jelszó adatbázisába, és csak ezek a felhasználók tudnak ide bejelentkezni. Sajnos ez a korlátozás a parancsértelmezõ ~ funkciójára és összes olyan rutinra is vonatkozik, amelyet a felhasználói nevek és azok numerikus azonosító között képez le. Más szóval a cd ~felhasználó parancs nem fog mûködni, és az ls -l parancs kimenetében a felhasználói nevek helyett csak numerikus azonosítók jelennek meg, továbbá afind . -user joe -print No such user (Nincs ilyen felhasználó) hibát fog visszaadni. Ez úgy tudjuk megjavítani, ha úgy importáljuk a szerverre az összes felhasználó bejegyzését, hogy közben tiltjuk a hozzáférésüket. Ehhez vegyünk fel egy újabb sort az /etc/master.passwd állományba. A sor valahogy így fog kinézni: +:::::::::/sbin/nologin, amely annyit tesz, hogy importáljuk az összes bejegyzést, de a hozzájuk tartozó parancsértelmezõ a /sbin/nologin legyen. A passwd állományban tetszõleges mezõ tartalmát le tudjuk úgy cserélni, ha megadunk neki egy alapértelmezett értéket az /etc/master.passwd állományban. Vigyázzunk, hogy a +:::::::::/sbin/nologin sort az +@IT_DOLG::::::::: sor után írjuk. Ha nem így teszünk, akkor a NIS-bõl importált összes felhasználói hozzáférés a /sbin/nologin parancsértelmezõt kapja. Miután elvégeztük ezt a változtatást, minden újabb dolgozó felvétele után csupán egyetlen táblázatot kell megváltoztatnunk. Ugyanezt a taktikát követhetjük a kevésbé fontosabb szerverek esetében is, hogy ha a helyi /etc/master.passwd állományukban a korábbi +::::::::: bejegyzést valami ilyesmivel helyettesítjük: +@IT_DOLG::::::::: +@IT_UJDOLG::::::::: +:::::::::/sbin/nologin Az egyszerû munkaállomások esetében pedig ezekre a sorokra lesz szükségünk: +@IT_DOLG::::::::: +@FELHASZNALOK::::::::: +:::::::::/sbin/nologin Minden remekül üzemel egészen addig, amíg néhány hét múlva ismét változik a házirend: az IT tanszékre ösztöndíjasok érkeznek. Az IT ösztöndíjasai a munkaállomásokat és a kevésbé fontosabb szervereket tudják használni. Az új IT dolgozók már a központi szerverekre is bejelentkezhetnek. Így tehát létrehozunk egy új hálózati csoportot IT_OSZTONDIJAS néven, majd felvesszük ide az új IT ösztöndíjasokat, és nekilátunk végigzongorázni az összes gép összes konfigurációs állományát... Ahogy azonban egy régi mondás is tartja: A központosított tervezésben ejtett hibák teljes káoszhoz vezetnek. A NIS az ilyen helyzeteket úgy igyekszik elkerülni, hogy megengedi újabb hálózati csoportok létrehozását más hálózati csoportokból. Egyik ilyen lehetõség a szerep alapú hálózati csoportok kialakítása. Például, ha a fontosabb szerverek bejelentkezési korlátozásai számára hozzunk létre egy NAGYSRV nevû csoportot, valamint egy másik hálózati csoportot KISSRV néven a kevésbé fontosabb szerverekhez, végül MUNKA néven egy harmadik hálózati csoportot a munkaállomásokhoz. Mindegyik ilyen hálózati csoport tartalmazza azokat a csoportokat, amelyek engedélyezik a gépek elérését. A hálózati csoportok leírását tartalmazó NIS táblázat most valahogy így fog kinézni: NAGYSRV IT_DOLG IT_UJDOLG KISSRV IT_DOLG IT_UJDOLG IT_OSZTONDIJAS MUNKA IT_DOLG IT_OSZTONDIJAS FELHASZNALOK A bejelentkezési megszorítások ilyen típusú megadása viszonylag jól mûködik, hogy ha azonos korlátozások alá esõ gépek csoportjait akarjuk felírni. Bánatunk ez a kivétel, és nem a szabály. Az esetek nagy többségében ugyanis a bejelentkezésre vonatkozó korlátozásokat gépenként kell egyesével megadni. A hálózati csoportok gépfüggõ megadása tehát az iménti házirendhez társuló igények kielégítésének egyik módja. Ebben a forgatókönyvben az /etc/master.passwd állomány minden számítógépen két +-os sorral kezdõdik. Közülük az elsõ a gépen engedélyezett hozzáféréseket tartalmazó hálózati csoportra vonatkozik, a második pedig az összes többi hozzáféréshez az /sbin/nologin parancsértelmezõt kapcsolja hozzá. Itt jó ötlet, ha a gép nevének VÉGIG-NAGYBETÛS változatát adjuk meg a hozzá tartozó hálózati csoport nevének: +@GÉPNÉV::::::::: +:::::::::/sbin/nologin Miután elvégeztük ezt a feladatot minden egyes gépen, az /etc/master.passwd állomány helyi változatait soha többé nem kell módosítanunk. Az összes többi változtatást a NIS táblázaton keresztül tudjuk keresztül vinni. Íme a felvázolt forgatókönyvhöz tartozó hálózati csoportok kiépítésének egyik lehetséges változata, egy-két finomsággal kiegészítve: # Elõször a felhasználók csoportjait adjuk meg: IT_DOLG (,alpha,proba-tartomany) (,beta,proba-tartomany) IT_UJDOLG (,charlie,proba-tartomany) (,delta,proba-tartomany) TANSZ1 (,echo,proba-tartomany) (,foxtrott,proba-tartomany) TANSZ2 (,golf,proba-taromany) (,hotel,proba-tartomany) TANSZ3 (,india,proba-taromany) (,juliet,proba-tartomany) IT_OSZTONDIJAS (,kilo,proba-tartomany) (,lima,proba-tartomany) D_OSZTONDIJAS (,able,proba-tartomany) (,baker,proba-tartomany) # # Most pedig hozzunk létre csoportokat szerepek szerint: FELHASZNALOK TANSZ1 TANSZ2 TANSZ3 NAGYSRV IT_DOLG IT_UJDOLG KISSRV IT_DOLG IT_UJDOLG IT_OSZTONDIJAS MUNKA IT_DOLG IT_OSZTONDIJAS FELHASZNALOK # # Következzenek a speciális feladatokhoz tartozó csoportok: # Az echo és a golf tudja elérni a vírusvédelemért felelõs gépet: VEDELEM IT_DOLG (,echo,proba-tartomany) (,golf,proba-tartomany) # # Gép alapú hálózati csoportok # A fõ szervereink: HABORU NAGYSRV EHSEG NAGYSRV # Az india nevû felhasználó hozzá szeretné ehhez férni: SZENNYEZES NAGYSRV (,india,proba-tartomany) # # Ez valóban fontos és komolyan szabályoznunk kell: HALAL IT_DOLG # # Az elõbb említett vírusvédelmi gép: EGY VEDELEM # # Egyetlen felhasználóra korlátozzuk le ezt a gépet: KETTO (,hotel,proba-tartomany) # [...és itt folytatódik a többi csoporttal] Ha a felhasználói hozzáféréseinket valamilyen adatbázisban tároljuk, akkor a táblázat elsõ részét akár az adatbázis lekérdezésein keresztül is elõ tudjuk állítani. Ezzel a módszerrel az új felhasználók automatikusan hozzáférnek a gépekhez. Legyünk viszont óvatosak: nem mindig javasolt gépeken alapuló hálózati csoportokat készíteni. Ha a hallgatói laborokba egyszerre több tucat vagy akár több száz azonos konfigurációjú gépet telepítünk, akkor a gép alapú csoportok helyett inkább szerep alapú csoportokat építsünk fel, mivel így a NIS táblázatok méretét egy elfogadható méreten tudjuk tartani. Amit feltétlenül észben kell tartanunk Még mindig akad néhány olyan dolog, amit másképpen kell csinálnunk azután, hogy most már NIS környezetben vagyunk. Amikor egy új felhasználót akarunk felvenni a laborba, akkor csak a központi NIS szerverre kell felvennünk, és újra kell generáltatnunk a NIS táblázatokat. Ha ezt elfelejtjük megtenni, akkor az új felhasználó a központi NIS szerveren kívül sehova sem lesz képes bejelentkezni. Például, ha fel akarjuk venni a jsmith nevû felhasználót a laborba, akkor ezt kell tennünk: &prompt.root; pw useradd jsmith &prompt.root; cd /var/yp &prompt.root; make proba-tartomany Vagy a pw useradd jsmith parancs helyett az adduser jsmith parancsot is használhatjuk. A rendszergazdai szintû hozzáféréseket ne tároljuk a NIS táblázatokban. Olyan gépekre egyáltalán ne is küldjünk olyan karbantartáshoz használt hozzáféréseket, amelynek a felhasználói hivatalosan nem is férhetnének hozzájuk. A központi NIS szervert és az alárendelt szervereket óvjuk minél jobban, és igyekezzünk minimalizálni a kieséseiket. Ha valaki feltöri vagy egyszerûen csak kikapcsolja ezeket a gépeket, akkor ezzel lényegében mindenkit megakadályoz abban, hogy be tudjon jelentkezni a laborban. Ezek a központosított vezérlésû rendszerek legfõbb gyengeségei. Ha nem védjük kellõen a NIS szervereinket, akkor azzal nagyon ellenséget szerezhetünk magunknak! Kompatibilitás a NIS elsõ változatával A &os;-ben megtalálható ypserv szolgáltatás valamennyire képes ellátni a NIS elsõ változatát használó klienseket is. A &os; NIS implementációja csak a NIS v2 protokollt használja, azonban mivel más implementációk kompatibilisek kívánnak maradni a régebbi rendszerekkel, ismerik a v1 protokollt is. Az ilyen rendszerekhez tartozó ypbind démonok még olyankor is megpróbálnak v1-es NIS szerverekhez kötést létrehozni, amikor valójában nincs is rá szükségük (és gyakran még akkor is ilyet keresnek, amikor az üzenetükre már válaszolt egy v2-es szerver). Hozzátennénk, hogy bár az ypserver ezen változata a normál klienshívásokat képes feldolgozni, a táblázatokat már nem tudja átküldeni a v1-es klienseknek. Ebbõl következik, hogy a központi vagy alárendelt szerverek nem tudnak együttmûködni olyan NIS szerverekkel, amelyek csak a v1-es protokollt beszélik. Szerencsére ilyen szervereket manapság már alig használnak. NIS szerverek, melyek egyben NIS kliensek Óvatosan kell bánnunk az ypserv elindításával olyan többszerveres tartományokban, ahol a szerverek maguk is NIS kliensek. Alapvetõen nincs abban semmi kivetnivaló, ha a szervereket saját magukhoz kötjük ahelyett, hogy engednénk nekik a kötési kérések küldését és így egymáshoz kötnénk ezeket. Különös hibák tudnak származni olyan helyzetekben, amikor az egyik szerver leáll, miközben a többiek pedig függenek tõle. Végül is ilyenkor minden kliens szépen kivárja a szükséges idõt, aztán megpróbál más szerverekhez kötõdni, de az itt fellépõ késlekedés jelentõs mennyiségû lehet, és ez a hibajelenség ismét fennállhat, mivel elõfordulhat, hogy a szerverek megint egymáshoz kapcsolódnak. A klienst úgy tudjuk egy adott szerverhez kötni, ha az ypbind parancsot a beállítással indítjuk. Ha mindezt nem akarjuk manuálisan megtenni a NIS szerver minden egyes újraindításakor, akkor vegyük fel a következõ sorokat az /etc/rc.conf állományba: nis_client_enable="YES" # elindítjuk a klienst is nis_client_flags="-S NIS tartomány,szerver" Részletesebb lásd az &man.ypbind.8; man oldalát. A jelszavak formátuma NIS jelszavak formátuma A NIS rendszerek kiépítése során az emberek leggyakrabban a jelszavak formátumával kapcsolatban tapasztalnak nehézségeket. Ha a szerverünk DES titkosítású jelszavakat használ, akkor csak olyan klienseket fog tudni támogatni, amelyek szintén így kódolják ezeket. Például, ha a hálózaton vannak &solaris; rendszerû NIS klienseink, akkor szinte biztos, hogy DES titkosítást kell használnunk. A szerverek és a kliensek által használt formátumokat az /etc/login.conf állományba tekintve deríthetjük ki. Ha a gépek többségén a DES titkosítást látjuk, akkor a default osztálynak egy ilyen bejegyzést kell tartalmaznia: default:\ :passwd_format=des:\ :copyright=/etc/COPYRIGHT:\ [a többit most nem mutatjuk] A passwd_format tulajdonság további lehetséges értékei lehetnek a blf és az md5 (melyek rendre a Blowfish és MD5 titkosítású jelszavakat adják meg). Ha változtattunk valamit az /etc/login.conf állományban, akkor a bejelentkezési tulajdonságok adatbázisát is újra kell generálni, melyet root felhasználóként a következõ módon tehetünk meg: &prompt.root; cap_mkdb /etc/login.conf Az /etc/master.passwd állományban jelenlevõ jelszavak formátuma azonban nem frissítõdik egészen addig, amíg a felhasználók a bejelentkezési adatbázis újragenerálása után meg nem változtatják a jelszavaikat. Úgy tudjuk még biztosítani, hogy a jelszavak megfelelõ formátumban kódolódjanak, ha az /etc/auth.conf állományban megkeressük a crypt_default sort, amelyben a választható jelszóformátumok felhasználásái sorrendjét találhatjuk meg. Itt tehát mindössze annyit kell tennünk, hogy a kiszemelt formátumot a lista elejére tesszük. Például, ha a DES titkosítású jelszavakat akarunk használni, akkor ez a bejegyzés így fog kinézni: crypt_default = des blf md5 Ha a fenti lépéseket követjük az összes &os; alapú NIS szervernél és kliensnél, akkor biztosra mehetünk abban, hogy a hálózatunkon belül ugyanazt a jelszóformátumot fogják használni. Ha gondunk akadna a NIS kliensek hitelesítésével, akkor itt érdemes kezdeni a hiba felderítését. Ne felejtsük: ha egy NIS szervert egy heterogén hálózatba akarunk telepíteni, akkor valószínûleg az összes rendszeren a DES titkosítást kell választani, mivel általában ez a közös nevezõ ebben a tekintetben. Greg Sutter Írta: A hálózat automatikus beállítása (DHCP) Mi az a DHCP? Dinamikus állomáskonfigurációs protokoll DHCP internetes rendszerkonzorcium (ISC) A Dinamikus állomáskonfigurációs protokoll, avagy Dynamic Host Configuration Protocol (DHCP) annak eszközeit írja le, hogy egy rendszer miként tud csatlakozni egy hálózathoz és miként tudja azon belül megszerezni a kommunikációhoz szükséges információkat. A &os; 6.0 elõtti változatai az ISC (Internet Systems Consortium, vagyis az internetes rendszerkonzorcium) által kidolgozott DHCP kliens (&man.dhclient.8;) implementációját tartalmazzák. A késõbbi verziókban pedig az OpenBSD 3.7 verziójából átvett dhclient paranccsal dolgozhatunk. Ebben a szakaszban a dhclient parancsra vonatkozó összes információ egyaránt érvényes az ISC és az OpenBSD által fejlesztett DHCP kliensekre. A DHCP szerver az ISC-tõl származik. Mivel foglalkozik ez a szakasz Ebben a szakaszban az ISC és az OpenBSD DHCP klienseinek kliens- és szerver oldali komponsenseit mutatjuk be. A kliens oldali program neve a dhclient, amely a &os; részeként érkezik, és a szerver oldali elem pedig a net/isc-dhcp31-server porton keresztül érhetõ el. A lentebb említett hivatkozások mellett a témában még a &man.dhclient.8;, &man.dhcp-options.5; és a &man.dhclient.conf.5; man adhatnak bõvebb felvilágosítást a témában. Ahogyan mûködik UDP Amikor a dhclient, vagyis a DHCP kliens elindul egy kliensgépen, akkor a hálózaton üzenetszórással próbálja meg elkérni a konfigurációjához szükséges adatokat. Alapértelmezés szerint ezek a kérések a 68-as UDP porton keresztül mennek. A szerver ezekre a 67-es UDP porton válaszol, ahol visszaad a kliensnek egy IP-címet és a hálózat használatához szükséges további információkat, mint például a hálózati maszkot, az alapértelmezett átjáró és a névfeloldásért felelõs szerverek címét. Az összes ilyen jellegû adat egy DHCP bérlet (lease) formájában érkezik meg, amely csak egy adott ideig érvényes (ezt a DHCP szerver karbantartója állítja be). Így a hálózaton a kliens nélküli IP-címeket egy idõ után automatikusan visszanyerjük. A DHCP kliensek rengeteg információt képes elkérni a szervertõl. Ezek teljes listáját a &man.dhcp-options.5; man oldalán olvashatjuk el. Használat a &os;-n belül A &os; teljes egészében tartalmazza az ISC vagy az OpenBSD DHCP kliensét, a dhclient programot (attól függõen, hogy a &os; melyik változatát használjuk). A DHCP kliensek támogatása a telepítõben és az alaprendszerben is megtalálható, és ezzel mentesülünk minden konkrét hálózati beállítás alól a DHCP szervereket alkalmazó hálózatokon. A dhclient a &os; 3.2 változata óta megtalálható a rendszerben. sysinstall DHCP használatát a sysinstall is lehetõvé teszi. Amikor egy hálózati felületet a sysinstall programon belül állítunk be, akkor a második kérdés mindig ez szokott lenni: Do you want to try DHCP configuration of the interface? (Megpróbáljuk DHCP használatával beállítani a felületet?) Ha erre igennel válaszolunk, akkor azzal lényegében a dhclient parancsot indítjuk el, és ha mindez sikerrel zárul, akkor szinte magától kitöltõdik az összes hálózati beállításunk. A DHCP használatához két dolgot kell beállítanunk a rendszerünkön: DHCP követelmények Gondoskodjunk róla, hogy a bpf eszköz része a rendszermagunknak. Ha még nem lenne benne, akkor a rendszermag beállításait tartalmazó állományba vegyük fel a device bpf sort és fordítsuk újra a rendszermagot. A rendszermagok fordításáról a ben tudhatunk meg többet. A bpf eszköz alapból megtalálható a GENERIC rendszermagokban, így ha ezt használjuk, akkor nem kell saját verziót készítenünk a DHCP használatához. Azok számára viszont, akik biztonsági szempontból aggódnak a rendszerük miatt, meg kell említenünk, hogy a bpf egyben az az eszköz, amely a csomagok lehallgatását is lehetõvé teszi (habár az ilyeneket root felhasználóként lehet csak elindítani). A bpf kell a DHCP használatához, azonban ha nagyon fontos nekünk a rendszerünk biztonsága, akkor a bpf eszközt érdemes kivennünk a rendszermagból, ha még pillanatnyilag nem használunk ilyet. Az /etc/rc.conf állományunkat az alábbiak szerint kell módosítani: ifconfig_fxp0="DHCP" Az fxp0 eszközt ne felejtsük el kicserélni arra a felületre, amelyet automatikusan akarunk beállítani. Ennek mikéntje a ban olvasható. Ha a dhclient a rendszerünkben máshol található, vagy egyszerûen csak további beállításokat akarunk átadni a dhclient parancsnak, akkor adjuk meg a következõt is (változtassuk meg igényeink szerint): dhclient_program="/sbin/dhclient" dhclient_flags="" DHCP szerver A DHCP szerver, a dhcpd a net/isc-dhcp31-server port részeként érhetõ el. Az a port tartalmazza az ISC DHCP szerverét és a hozzá tartozó dokumentációt. Állományok DHCP konfigurációs állományok /etc/dhclient.conf A dhclient mûködéséhez szükség lesz egy konfigurációs állományra, aminek a neve /etc/dhclient.conf. Ez az állomány általában csak megjegyzéseket tartalmaz, mivel az alapértelmezett értékek többnyire megfelelõek. Ezt a konfigurációs állományt a &man.dhclient.conf.5; man oldal írja le. /sbin/dhclient A dhclient statikusan linkelt és az /sbin könyvtárban található. A &man.dhclient.8; man oldal tud róla részletesebb felvilágosítást adni. /sbin/dhclient-script A dhclient-script a &os;-ben levõ DHCP kliens konfigurációs szkriptje. Mûködését a &man.dhclient-script.8; man oldal írja le, de a felhasználók részérõl semmilyen módosítást nem igényel. /var/db/dhclient.leases A DHCP kliens az érvényes bérleteket tartja nyilván ezekben az állományban és naplóként használja. A &man.dhclient.leases.5; man oldal ezt valamivel bõvebben kifejti. További olvasnivalók A DHCP protokoll mûködését az RFC 2131 mutatja be. A témához kapcsolódóan itt tudunk még leírásokat találni. A DHCP szerverek telepítése és beállítása Mirõl szól ez a szakasz Ebben a szakaszban arról olvashatunk, hogy miként kell egy &os; típusú rendszert DHCP szervernek beállítani, ha az ISC (internetes rendszerkonzorcium) DHCP szerverét használjuk. Ez a szerver nem része a &os;-nek, ezért a szolgáltatás elindításához elõször fel kell raknunk a net/isc-dhcp31-server portot. A Portgyûjtemény használatára vonatkozóan a lehet segítségünkre. A DHCP szerver telepítése DHCP telepítés Ha a &os; rendszerünket DHCP szerverként akarjuk beállítani, akkor ehhez elsõként a &man.bpf.4; eszköz jelenlétét kell biztosítani a rendszermagban. Ehhez vegyük fel a device bpf sort a rendszermagunk beállításait tartalmazó állományba, majd fordítsuk újra a rendszermagot. A rendszermag lefordításáról a ben olvashatunk. A bpf eszköz a &os;-hez alapból adott GENERIC rendszermag része, ezért a DHCP használatához nem kell feltétlenül újat fordítanunk. A biztonsági szempontok miatt aggódó felhasználók részére megjegyezzük, hogy a bpf eszköz egyben a csomagok lehallgatását is lehetõvé teszi (habár az ilyen témájú programok futtatásához megfelelõ jogokra is szükség van). A bpf használata kötelezõ a DHCP mûködtetéséhez, de ha nagyon kényesek vagyunk a biztonságot illetõen, akkor minden olyan esetben, amikor nem használjuk ki ezt a lehetõséget, távolítsuk el a rendszermagból. A következõ lépésben át kell szerkesztenünk a mintaként mellékelt dhcpd.conf állományt, amelyet a net/isc-dhcp31-server port rakott fel. Ez alapértelmezés szerint a /usr/local/etc/dhcpd.conf.sample néven található meg, és mielõtt bármit is változtatnánk rajta, másoljuk le /usr/local/etc/dhcpd.conf néven. A DHCP szerver beállítása DHCP dhcpd.conf A dhcpd.conf az alhálózatokat illetve a gépeket érintõ deklarációkat tartalmazza, és talán a legkönnyebben a következõ példa alapján mutatható be: option domain-name "minta.com"; option domain-name-servers 192.168.4.100; option subnet-mask 255.255.255.0; default-lease-time 3600; max-lease-time 86400; ddns-update-style none; subnet 192.168.4.0 netmask 255.255.255.0 { range 192.168.4.129 192.168.4.254; option routers 192.168.4.1; } host mailhost { hardware ethernet 02:03:04:05:06:07; fixed-address levelezes.minta.com; } Ez a beállítás adja meg a kliensek számára az alapértelmezett keresési tartományt (search domain). A &man.resolv.conf.5; tud ezzel kapcsolatban részletesebb információkat adni. Ez a beállítás adja meg a kliensek által használt névfeloldó szerverek vesszõvel elválasztott felsorolását. A kliensekhez tartozó hálózati maszk. A kliens egy adott idõre kérhet bérleti jogot, egyébként a szerver dönt a bérlet lejárati idejérõl (másodpercekben). Ez az a maximális idõ, amennyire a szerver hajlandó bérbe adni IP-címet. A kliens ugyan hosszabb idõre is kérheti és meg is kapja, de legfeljebb csak max-lease-time másodpercig lesz érvényes. Ez a beállítás határozza meg, hogy a DHCP szervernek frissítse-e a névoldási információkat a bérlések elfogadásánál vagy visszamondásánál. Az ISC implementációjánál ez a beállítás kötelezõ. Ezzel adjuk meg milyen tartományból tudunk IP-címeket kiosztani a kliensek számára. A kezdõ címet is beleértve, innen fogunk kiutalni egyet a klienseknek. A kliensek felé elküldött alapértelmezett átjáró címe. A gép hardveres MAC-címe (így a DHCP szerver képes felismerni a kérés küldõjét). Ennek megadásával a gépek mindig ugyanazt az IP-címet kapják. Itt már megadhatunk egy hálózati nevet, mivel a bérlethez tartozó információk visszaküldése elõtt maga a DHCP szerver fogja feloldani a gép nevét. Miután befejeztük a dhcpd.conf módosítását, a DHCP szerver az /etc/rc.conf állományban tudjuk engedélyezni, vagyis tegyük bele a következõt: dhcpd_enable="YES" dhcpd_ifaces="dc0" A dc0 felület nevét helyettesítsük annak a felületnek (vagy whitespace karakterekkel elválasztott felületeknek) a nevével, amelyen keresztül a DHCP szerver várni fogja a kliensek kéréseit. Ezután a következõ parancs kiadásával indítsuk el a szervert: &prompt.root; /usr/local/etc/rc.d/isc-dhcpd start Amikor a jövõben valamit változtatunk a konfigurációs állományon, akkor ezzel kapcsolatban fontos megemlíteni, hogy ha csak egy SIGHUP jelzést küldünk a dhcpd démonnak, akkor az a többi démontól eltérõen önmagában még nem eredményezi a konfigurációs adatok újraolvasását. Helyette a SIGTERM jelzéssel kell leállítani a programot, majd újraindítani a fenti paranccsal. Állományok DHCP konfigurációs állományok /usr/local/sbin/dhcpd A dhcpd statikusan linkelt és a /usr/local/sbin könyvtárban található. A porttal együtt felkerülõ &man.dhcpd.8; man oldal ad részletesebb útmutatást dhcpd használatáról. /usr/local/etc/dhcpd.conf Mielõtt a dhcpd megkezdhetné mûködését, egy konfigurációs állományra is szükségünk lesz, amely a /usr/local/etc/dhcpd.conf. Ez az állomány tartalmazza az összes olyan információt, ami kell a kliensek megfelelõ kiszolgálásához valamint a szerver mûködéséhez. Ez a konfigurációs állomány porthoz tartozó &man.dhcpd.conf.5; man oldalon kerül ismertetésre. /var/db/dhcpd.leases A DHCP szerver ebben az állományba tartja nyilván a kiadott bérleteket, egy napló formájában. A porthoz kapcsolódó &man.dhcpd.leases.5; man oldalon errõl többet is megtudhatunk. /usr/local/sbin/dhcrelay A dhcrelay állománynak olyan komolyabb környezetekben van szerepe, ahol a DHCP szerver a kliensektõl érkezõ kéréseket egy másik hálózaton található DHCP szerverhez továbbítja. Ha szükség lenne erre a lehetõségre, akkor telepítsük fel a net/isc-dhcp31-relay portot. A porthoz tartozó &man.dhcrelay.8; man oldal ennek részleteit taglalja. Chern Lee Készítette: Tom Rhodes Daniel Gerzo Névfeloldás (<acronym>DNS</acronym>) Áttekintés BIND A &os; alapértelmezés szerint a BIND (Berkeley Internet Name Domain) egyik verzióját tartalmazza, amely a névfeloldási (Domain Name System, DNS) protokoll egyik elterjedt implementációja. A DNS protokollon keresztül tudunk az IP-címekhez neveket rendelni és fordítva. Például a www.FreeBSD.org névre a &os; Projekt webszerverének IP-címét kapjuk meg, miközben a ftp.FreeBSD.org pedig a hozzá tartozó FTP szerver IP-címét fogja visszaadni. Ehhez hasonlóan a fordítottja is megtörténhet, vagyis egy IP-címhez is kérhetjük a hálózati név feloldását. A névfeloldási kérések kiszolgálásához nem feltétlenül szükséges névszervert futtatni a rendszerünkön. A &os; jelen pillanatban alapból a BIND9 névszervert tartalmazza. A benne szereplõ változata több biztonsági javítást, új állományrendszeri kiosztást és automatizált &man.chroot.8; beállítást is magában foglal. névfeloldás Az interneten keresztüli névfeloldást legfelsõ szintû tartományoknak (Top Level Domain, TLD) nevezett hitelesített tövek némileg bonyolult rendszerén alapszik, valamint más egyéb olyan névszervereken, amelyek további egyéni információkat tárolnak és táraznak. A BIND fejlesztését jelenleg az Internet Systems Consortium () felügyeli. Alapfogalmak A leírás megértéséhez be kell mutatnunk néhány névfeloldással kapcsolatos fogalmat. névfeloldó inverz DNS gyökérzóna Fogalom Meghatározás Közvetlen névfeloldás (forward DNS) A hálózati nevek leképezése IP-címekre. Õs (origin) Egy adott zóna állományban szereplõ tartományra vonatkozik. named, BIND A &os;-n belüli BIND névszerver különbözõ megnevezései. Névfeloldó (resolver) Az a program a rendszerben, amelyhez a hálózaton levõ gépek a zónák adatainak elérésével kapcsolatban fordulnak. Inverz névfeloldás (reverse DNS) Az IP-címek leképzése hálózati nevekre. Gyökérzóna (root zone) Az interneten található zónák hierarchiájának töve. Minden zóna ebbe a gyökérzónába esik, ahhoz hasonlóan, ahogy egy állományrendszerben az állományok a gyökérkönyvtárba. Zóna (zone) Egy különálló tartomány, altartomány vagy a névfeloldás azon része, amelyet egyazon fennhatóság alatt tartanak karban. zónák példák Példák zónákra: A gyökérzónára a leírásokban általában . néven szoktak hivatkozni. A org. egy legfelsõ szintû tartomány (TLD) a gyökérzónán belül. A minta.org. a org. TLD tartomány alatti zóna. A 1.168.192.in-addr.arpa egy olyan zóna, amelyek a 192.168.1.* IP-címtartományban szereplõ összes címet jelöli. Mint láthatjuk, a hálózati nevek balról kiegészülve pontosodnak. Tehát például a minta.org. sokkal pontosabb meghatározás, mint a org., ahogy az org. magánál a gyökérzónánál jelent többet. A hálózati nevek felosztása leginkább egy állományrendszerhez hasonlítható, például a /dev könyvtár a gyökéren belül található, és így tovább. Miért érdemes névszervert futtatni A névszerverek általában két alakban jelennek meg. Egyikük a hitelesített névszerver, a másikuk a gyorsítótárazó névszerver. Egy hitelesített névszerverre akkor van szükségünk, ha: a világ többi része felé akarunk hiteles névfeloldási információkat szolgáltatni; regisztráltunk egy tartományt (például minta.org) és az alatta levõ hálózati nevekhez is szeretnénk IP-címeket rendeltetni; a IP-címtartományunkban szükség van inverz névfeloldási bejegyzésekre (amely IP-címbõl ad meg hálózati nevet) is; a kérések teljesítéséhez egy tartalék avagy második, alárendelt (slave) névszerver kell. A gyorsítótárazó névszerverre akkor van szükségünk, ha: egy helyi névfeloldó szerver felhasználásával fel akarjuk gyorsítani az egyébként a külsõ névszerver felé irányuló kérések kiszolgálását. Amikor valaki lekérdezi a www.FreeBSD.org címét, akkor a névfeloldó elõször általában a kapcsolatot rendelkezésre bocsátó internet-szolgáltató névszerverét kérdezi meg és onnan kapja meg a választ. Egy helyi, gyorsítótárazó névszerver használata esetén azonban egy ilyen kérést csak egyszer kell kiadni a külsõ névszervernek. Ezután már minden további ilyen kérés el sem hagyja a belsõ hálózatunkat, mivel a válasz szerepel a gyorsítótárban. Ahogyan mûködik &os; alatt a BIND démon nyilvánvaló okokból named néven érhetõ el. Állomány Leírás &man.named.8; A BIND démon. &man.rndc.8; A névszervert vezérlõ segédprogram. /etc/namedb A BIND által kezelt zónák adatait tároló könyvtár. /etc/namedb/named.conf A démon konfigurációs állománya. Attól függõen, hogy miként állítjuk be az adott zónát a szerveren, a hozzá tartozó állományok a /etc/namedb könyvtáron belül a master, slave vagy dynamic alkönyvtárban foglalnak helyet. Az itt tárolt állományokban levõ névfeloldási információk alapján válaszol a névszerver a felé intézett kérésekre. A BIND elindítása BIND elindítás Mivel a BIND alapból elérhetõ a rendszerben, viszonylag könnyen be tudjuk állítani. A named alapértelmezett beállítása szerint egy &man.chroot.8; környezetben futó egyszerû névfeloldást végzõ szerver, amely a helyi IPv4 interfészen (127.0.0.1) fogadja a kéréseket. Ezzel a beállítással a következõ parancson keresztül tudjuk elindítani: &prompt.root; /etc/rc.d/named onestart Ha engedélyezni akarjuk a named démont minden egyes rendszerindításkor, tegyük a következõ sort az /etc/rc.conf állományba: named_enable="YES" Értelemszerûen az /etc/namedb/named.conf tele van olyan beállítási lehetõségekkel, amelyek meghaladják ennek a leírásnak a kereteit. Ha viszont kíváncsiak vagyunk a &os;-ben a named indításához használt beállításokra, akkor az /etc/defaults/rc.conf állományban nézzük meg named_* változókat és olvassuk át az &man.rc.conf.5; man oldalt. Emellett még a t is hasznos lehet elolvasni. A konfigurációs állományok BIND konfigurációs állományok A named beállításait tartalmazó állományok pillanatnyilag az /etc/namedb könyvtárban találhatóak és hacsak nem egy egyszerû névfeloldóra tartunk igényt, akkor a használata elõtt módosítanunk is kell. Itt ejtjük meg a beállítások nagy részét. <filename>/etc/namedb/named.conf</filename> // $FreeBSD$ // // Részletesebb leírást a named.conf(5) és named(8) man oldalakon, valamint // a /usr/share/doc/bind9 könyvtárban találhatunk. // // Ha egy hitelesített szervert akarunk beállítani, akkor igyekezzünk // a névfeloldás összes finom részletével pontosan tisztában lenni. // Ugyanis még a legkisebb hibákkal is egyrészt elvághatunk gépeket az // internet-lérésétõl, vagy másrészt felesleges forgalmat tudunk // generálni // options { // A chroot könyvtárhoz relatív elérési út, amennyiben létezik directory "/etc/namedb"; pid-file "/var/run/named/pid"; dump-file "/var/dump/named_dump.db"; statistics-file "/var/stats/named.stats"; // Ha a named démont csak helyi névfeloldóként használjuk, akkor ez // egy biztonságos alapbeállítás. Ha viszont a named démon az egész // hálózatunkat is kiszolgálja, akkor ezt a beállítást tegyük // megjegyzésbe, vagy adjunk meg egy rendes IP-címet, esetleg // töröljük ki. listen-on { 127.0.0.1; }; // Ha rendszerünkön engedélyezett az IPv6 használata, akkor a helyi // névfeloldó használatához ezt a sort vegyük ki a megjegyzésbõl. // A hálózatunk többi részérõl pedig úgy lehet elérni, ha itt megadunk // egy IPv6 címet, vagy az "any" kulcsszót. // listen-on-v6 { ::1; }; // Az alábbi zónákat már a lentebb található üres zónák eleve lefedik. // Ha tehát a lenti üres zónákat kivesszük a konfigurációból, akkor // ezeket a sorokat is tegyük megjegyzésbe. disable-empty-zone "255.255.255.255.IN-ADDR.ARPA"; disable-empty-zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA"; disable-empty-zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA"; // Ha a szolgáltatónk névszervert is elérhetõvé tett számunkra, akkor // itt adjuk meg annak az IP-címét és engedélyezzük az alábbi sort. // Ezzel egyben kihasználjuk a gyorsítótárat is, így mérsékeljük az // internet felé mozgó névfeloldásokat. /* forwarders { 127.0.0.1; }; * // Ha a 'forwarders' rész nem üres, akkor alapértelmezés szerint a // 'forward first' értékkel rendelkezik. Ekkor a kérést a helyi szerver // kapja abban az esetben, amikor a 'forwarders' részben megadott // szerverek nem tudják megválaszolni. Emellett a névszerverben a // következõ sor hozzáadásával letilthatjuk, hogy önmagától ne // kezdeményezzen kéréseket: // forward only; // Ha a kérések továbbítását az /etc/resolv.conf állományban megadott // bejegyzések mentén szeretnénk automatikusan konfigurálni, akkor vegyük // ki a megjegyzésbõl az alábbi sort és adjuk hozzá az /etc/rc.conf // állományhoz a name_auto_forward=yes sort. Emellett használható még a // named_auto_forward_only beállítás is (amely fentebb leírt funkciót // valósítja meg). // include "/etc/namedb/auto_forward.conf"; Ahogy arról a megjegyzésekben is szó esik, úgy tudjuk aktiválni a gyorsítótárat, ha megadjuk a forwarders beállítást. Normális körülmények között a névszerver az interneten az egyes névszervereket rekurzívan fogja keresni egészen addig, amíg meg nem találja a keresett választ. Az iménti beállítás engedélyezésével azonban elõször a szolgáltató névszerverét (vagy az általa kijelölt névszervert) fogjuk megkérdezni, a saját gyorsítótárából. Ha a szolgáltató kérdéses névszervere egy gyakran használt, gyors névszerver, akkor ezt érdemes bekapcsolnunk. Itt a 127.0.0.1 megadása nem mûködik. Mindenképpen írjuk át a szolgáltatónk névszerverének IP-címére. /* A BIND legújabb változataiban alapértelmezés szerint minden egyes kimenõ kérésnél más, véletlenszerûen választott UDP portot használnak, ezáltal jelentõs mértékben csökkenthetõ a gyorsítótár meghamisíthatóságának (cache poisoning) esélye. Javasoljuk mindenkinek, hogy használják ki ezt a lehetõséget és eszerint állítsák be a tûzfalakat. Ha nem sikerül a tûzfalat hozzáigazítani ehhez a viselkedéshez AKKOR ÉS CSAK IS AKKOR engedélyezzük a lenti beállítást. Alkalmazásával sokkal kevésbé lesz ellenálló a névszerver a különbözõ hamisítási kísérletekkel szemben, ezért lehetõség szerint kerüljük el. Az NNNNN helyére egy 49160 és 65530 közti számot kell beírnunk. */ // query-source address * port NNNNN; }; // Ha engedélyezzük a helyi névszervert, akkor az /etc/resolv.conf // állományban elsõ helyen megadni a 127.0.0.1 címet. Sõt, az // /etc/rc.conf állományból se felejtsük ki. // A hagyományos "root-hints" megoldás. Használjuk ezt VAGY a lentebb // megadott alárendelt zónákat. zone "." { type hint; file "named.root"; }; /* Több szempontból is elõnyös, ha a következõ zónákat alárendeljük a gyökér névfeloldó szervereknek: 1. A helyi felhasználók kéréseit gyorsabban tudjuk feloldalni. 2. A gyökérszerverek felé nem megy semmilyen hamis forgalom. 3. A gyökérszerverek meghibásodása vagy elosztott DoS támadás esetén rugalmasabban tudunk reagálni. Másfelöl azonban ez a módszer a "hints" állomány alkalmazásával szemben több felügyeletet igényel, mivel figyelnünk kell, nehogy egy váratlan meghibásodás mûködésképtelenné tegye a szerverünket. Ez a megoldás leginkább a sok klienst kiszolgáló névszerverek esetén bizonyulhat jövedelmezõbbnek. Óvatosan bánjunk vele! A módszer alkalmazásához vegyük ki a megjegyzésbõl a következõ bejegyzéseket és tegyük megjegyzésbe a fenti hint zónát. */ zone "." { type slave; file "slave/root.slave"; masters { 192.5.5.241; // F.ROOT-SERVERS.NET. }; notify no; }; zone "arpa" { type slave; file "slave/arpa.slave"; masters { 192.5.5.241; // F.ROOT-SERVERS.NET. }; notify no; } zone "in-addr.arpa" { type slave; file "slave/in-addr.arpa.slave"; masters { 192.5.5.241; // F.ROOT-SERVERS.NET. }; notify no; }; */ /* Az alábbi zónák helyi kiszolgálásával meg tudjuk akadályozni, hogy a belõlük indított kérések elhagyják a hálózatunkat és a elérjük a gyökér névfeloldó szervereket. Ez a megközelítés két komoly elõnnyel rendelkezik: 1. A helyi felhasználók kéréseit gyorsabban tudjuk megválaszolni. 2. A gyökérszerverek felé nem továbbítódik semmilyen hamis forgalom. */ // RFC 1912 zone "localhost" { type master; file "master/localhost-forward.db"; }; zone "127.in-addr.arpa" { type master; file "master/localhost-reverse.db"; }; zone "255.in-addr.arpa" { type master; file "master/empty.db"; }; // A helyi IPv6 címek részére létrehozott RFC 1912-szerû zóna zone "0.ip6.arpa" { type master; file "master/localhost-reverse.db"; }; // "Ez" a hálózat (RFC 1912 és 3330) zone "0.in-addr.arpa" { type master; file "master/empty.db"; }; // Magáncélú hálózatok (RFC 1918) zone "10.in-addr.arpa" { type master; file "master/empty.db"; }; zone "16.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "17.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "18.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "19.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "20.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "21.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "22.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "23.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "24.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "25.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "26.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "27.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "28.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "29.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "30.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "31.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "168.192.in-addr.arpa" { type master; file "master/empty.db"; }; // Helyi link/APIPA (RFC 3330 és 3927) zone "254.169.in-addr.arpa" { type master; file "master/empty.db"; }; // Dokumentációs próbahálózat (RFC 3330) zone "2.0.192.in-addr.arpa" { type master; file "master/empty.db"; }; // Útválasztási teljesítmény tesztelésére (RFC 3330) zone "18.198.in-addr.arpa" { type master; file "master/empty.db"; }; zone "19.198.in-addr.arpa" { type master; file "master/empty.db"; }; // Az IANA részére fentartott - a régi E osztályú címtér zone "240.in-addr.arpa" { type master; file "master/empty.db"; }; zone "241.in-addr.arpa" { type master; file "master/empty.db"; }; zone "242.in-addr.arpa" { type master; file "master/empty.db"; }; zone "243.in-addr.arpa" { type master; file "master/empty.db"; }; zone "244.in-addr.arpa" { type master; file "master/empty.db"; }; zone "245.in-addr.arpa" { type master; file "master/empty.db"; }; zone "246.in-addr.arpa" { type master; file "master/empty.db"; }; zone "247.in-addr.arpa" { type master; file "master/empty.db"; }; zone "248.in-addr.arpa" { type master; file "master/empty.db"; }; zone "249.in-addr.arpa" { type master; file "master/empty.db"; }; zone "250.in-addr.arpa" { type master; file "master/empty.db"; }; zone "251.in-addr.arpa" { type master; file "master/empty.db"; }; zone "252.in-addr.arpa" { type master; file "master/empty.db"; }; zone "253.in-addr.arpa" { type master; file "master/empty.db"; }; zone "254.in-addr.arpa" { type master; file "master/empty.db"; }; // Hozzárendelés nélküli IPv6-címek (RFC 4291) zone "1.ip6.arpa" { type master; file "master/empty.db"; }; zone "3.ip6.arpa" { type master; file "master/empty.db"; }; zone "4.ip6.arpa" { type master; file "master/empty.db"; }; zone "5.ip6.arpa" { type master; file "master/empty.db"; }; zone "6.ip6.arpa" { type master; file "master/empty.db"; }; zone "7.ip6.arpa" { type master; file "master/empty.db"; }; zone "8.ip6.arpa" { type master; file "master/empty.db"; }; zone "9.ip6.arpa" { type master; file "master/empty.db"; }; zone "a.ip6.arpa" { type master; file "master/empty.db"; }; zone "b.ip6.arpa" { type master; file "master/empty.db"; }; zone "c.ip6.arpa" { type master; file "master/empty.db"; }; zone "d.ip6.arpa" { type master; file "master/empty.db"; }; zone "e.ip6.arpa" { type master; file "master/empty.db"; }; zone "0.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "1.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "2.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "3.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "4.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "5.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "6.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "7.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "8.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "9.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "a.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "b.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "0.e.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "1.e.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "2.e.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "3.e.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "4.e.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "5.e.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "6.e.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "7.e.f.ip6.arpa" { type master; file "master/empty.db"; }; // IPv6 ULA (RFC 4193) zone "c.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "d.f.ip6.arpa" { type master; file "master/empty.db"; }; // IPv6 helyi link (RFC 4291) zone "8.e.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "9.e.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "a.e.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "b.e.f.ip6.arpa" { type master; file "master/empty.db"; }; // Elavult IPv6 helyi címek (RFC 3879) zone "c.e.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "d.e.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "e.e.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "f.e.f.ip6.arpa" { type master; file "master/empty.db"; }; // Az IP6.INT már elavult (RFC 4159) zone "ip6.int" { type master; file "master/empty.db"; }; // FONTOS: Ne használjuk ezeket az IP-címeket, mert nem valódiak, // csupán illusztrációs és dokumentációs célokból adtuk meg! // // Az alárendelt zónák beállításaira vonatkozó bejegyzések. Érdemes // ilyet beállítani legalább ahhoz a zónához, amelyhez a tartományunk is // tartozik. Az elsõdleges névszerverhez tartozó IP-címet érdeklõdjük meg // az illetékes hálózati rendszergazdától. // // Soha ne felejtsünk el megadni zónát az inverz kereséshez! A neve az IP-cím // tagjainak fordított sorrendjébõl // származik, amelyhez hozzátoldunk még egy // ".IN-ADDR.ARPA" (illetve IPv6 esetén ".IP6.ARPA") részt. // // Mielõtt nekilátnánk egy elsõdleges zóna beállításának, gondoljuk // végig, hogy tényleg a megfelelõ szinten ismerjük a névfeloldás és // a BIND mûködését. Gyakran ugyanis egyáltalán nem nyilvánvaló // csapdákba tudunk esni. Egy alárendelt zóna beállítása általában sokkal egyszerûbb feladat. // // FONTOS: Ne kövessük vakon a most következõ példát :-) Helyette inkább // valódi neveket és címeket adjunk meg. /* Példa dinamikus zónára key "mintaorgkulcs" { algorithm hmac-md5; secret "sf87HJqjkqh8ac87a02lla=="; }; zone "minta.org" { type master; allow-update { key "mintaorgkulcs"; }; file "dynamic/minta.org"; }; */ /* Példa inverz alárendelt zónákra zone "1.168.192.in-addr.arpa" { type slave; file "slave/1.168.192.in-addr.arpa"; masters { 192.168.1.1; }; }; */ A named.conf állományban tehát így adhatunk meg közvetlen és inverz alárendelt zónákat. Minden egyes újabb kiszolgált zónához az egy új bejegyzést kell felvenni a named.conf állományban. Például a minta.org címhez tartozó legegyszerûbb ilyen bejegyzés így néz ki: zone "minta.org" { type master; file "master/minta.org"; }; Ez egy központi zóna, ahogy arról a mezõ, vagyis a típusa is árulkodik. Továbbá a mezõben láthatjuk, hogy a hozzá tartozó információkat az /etc/namedb/master/minta.org állományban tárolja. zone "minta.org" { type slave; file "slave/minta.org"; }; Az alárendelt esetben a zónához tartozó információkat a zóna központi szerverétõl kapjuk meg és megadott állományban mentjük el. Ha valamiért a központi szerver leáll vagy nem érhetõ el, akkor az alárendelt szerver az átküldött zóna információk alapján képes helyette kiszolgálni a kéréseket. A zóna állományok BIND zóna állományok A minta.org címhez tartozó példa központi zóna állomány (amely az /etc/namedb/master/néven.org érhetõ el) tartalma az alábbi: $TTL 3600 ; alapértelmezés szerint 1 óra minta.org. IN SOA ns1.minta.org. admin.minta.org. ( 2006051501 ; sorozatszám 10800 ; frissítés 3600 ; ismétlés 604800 ; lejárat 300 ; TTL negatív válasz ) ; névszerverek IN NS ns1.minta.org. IN NS ns2.minta.org. ; MX rekordok IN MX 10 mx.minta.org. IN MX 20 levelezes.minta.org. IN A 192.168.1.1 ; a gépek nevei localhost IN A 127.0.0.1 ns1 IN A 192.168.1.2 ns2 IN A 192.168.1.3 mx IN A 192.168.1.4 levelezes IN A 192.168.1.5 ; álnevek www IN CNAME minta.org. A .-ra végzõdõ hálózati nevek abszolút nevek, míg minden más . nélküli név az õsére vezehetõ vissza (tehát relatív). Például az ns1 névbõl az ns1.minta.org keletkezik. A zóna állományok felépítése a következõ: rekordnév IN rekordtípus érték névfeloldás rekordok A névfeloldásban leggyakrabban alkalmazott rekordok típusai: SOA a zóna fennhatóságának kezdete NS egy hitelesített névszerver A egy gép címe CNAME egy álnév kanonikus neve MX levélváltó PTR mutató a tartománynévre (az inverz feloldás használja) minta.org. IN SOA ns1.minta.org. admin.minta.org. ( 2006051501 ; sorozatszám 10800 ; 3 óránként frissítsünk 3600 ; 1 óra után próbálkozzunk újra 604800 ; 1 hét után jár le 300 ) ; TTL negatív válasz minta.org. a tartomány neve, amely egyben a zóna õse ns1.minta.org. a zóna elsõdleges/hitelesített névszervere admin.minta.org. a zónáért felelõs személy neve, akinek az e-mail címét a @ behelyettesítésével kapjuk meg. (Tehát a admin@example.org címbõl admin.example.org lesz.) 2006051501 az állomány sorozatszáma. Ezt a zóna állomány módosításakor mindig növelnünk kell. Manapság a rendszergazdák a sorozatszámot ééééhhnnvv alakban adják meg. A 2006051501 tehát azt jelenti, hogy az állományt 2006. május 15-én módosították utoljára, és a 01 pedig arra utal, hogy aznap elõször. A sorozatszám megadása fontos az alárendelt névszerverek számára, mivel így tudják megállapítani, hogy a zóna mikor változott utoljára. IN NS ns1.minta.org. Ez egy NS bejegyzés. A zónához tartozó minden hitelesített névszervernek lennie kell legalább egy ilyen bejegyzésének. localhost IN A 127.0.0.1 ns1 IN A 192.168.1.2 ns2 IN A 192.168.1.3 mx IN A 192.168.1.4 levelezes IN A 192.168.1.5 Az A rekord egy gép nevét adja meg. Ahogy a fenti példából is kiderül, az ns1.minta.org név a 192.168.1.2 címre képzõdik le. IN A 192.168.1.1 Ez a sor 192.168.1.1 címet rendeli az aktuális õshöz, amely jelen esetünkben az example.org. www IN CNAME @ A kanonikus neveket tároló rekordokat általában egy gép álneveihez használjuk. Ebben a példában a www a fõgép egyik álneve, amely itt éppenséggel a minta.org (192.168.1.1) tartományneve. A CNAME rekordok mellé más típusú rekordokat ugyanarra a hálózati névre soha ne adjunk meg. MX rekord IN MX 10 levelezes.minta.org. Az MX rekord adja meg, hogy milyen levelezõ szerverek felelõsek a zónába érkezõ levelek fogadásáért. A levelezes.minta.org a levelezõ szerver hálózati neve, ahol a 10 az adott levelezõ szerver prioritása. Több levelezõ szerver is megadható 10-es, 20-as stb. prioritásokkal. A minta.org tartományon belül elõször mindig a legnagyobb MX prioritással rendelkezõ levelezõ szervernek próbáljuk meg továbbítani a leveleket (a legkisebb prioritási értékkel rendelkezõ rekord), majd ezután a második legnagyobbnak stb. egészen addig, amíg a levelet tovább nem küldtük. Az in-addr.arpa zóna állományok (inverz DNS) esetén ugyanez a felépítés, kivéve, hogy a PTR típusú bejegyzések szerepelnek az A és CNAME helyett. $TTL 3600 1.168.192.in-addr.arpa. IN SOA ns1.minta.org. admin.minta.org. ( 2006051501 ; sorozatszám 10800 ; frissítés 3600 ; ismétlés 604800 ; lejárat 300 ) ; TTL negatív válasz IN NS ns1.minta.org. IN NS ns2.minta.org. 1 IN PTR minta.org. 2 IN PTR ns1.minta.org. 3 IN PTR ns2.minta.org. 4 IN PTR mx.minta.org. 5 IN PTR levelezes.minta.org. Ez az állomány írja le tehát a kitalált tartományunkon belül az IP-címek és hálózati nevek összerendelését. Érdemes megemlíteni, hogy a PTR rekordok jobb oldalán álló nevek mindegyikének teljes hálózati névnek kell lennie (vagyis . karakterrel kell végzõdnie). A gyorsítótárazó névszerver BIND gyorsítótárazó névszerver A gyorsítótárazó névszerver az a névszerver, amely elsõdleges feladata a rekurzív kérések kiszolgálása. Egyszerûen továbbítja a beérkezõ kéréseket, majd megjegyzi azokat, így késõbb közvetlenül tud válaszolni. Biztonság Habár a névfeloldás szempontjából a BIND a legelterjedtebb, a biztonságosságával azért akadnak gondok. Gyakran találnak benne potenciális és kihasználható biztonsági réseket. A &os; azonban a named démont automatikusan egy &man.chroot.8; környezetbe helyezi. Emellett még léteznek további más védelmi mechanizmusok is, amelyek segítségével el tudjuk kerülni a névfeloldást célzó esetleges támadásokat. Sosem árt olvasgatni a CERT által kiadott biztonsági figyelmeztetéseket és feliratkozni a &a.security-notifications; címére, hogy folyamatosan értesüljünk az interneten és a &os;-ben talált különbözõ biztonsági hibákról. Ha valamilyen gondunk támadna, akkor esetleg próbálkozzunk meg a forrásaink frissítésével és a named újrafordításával. Egyéb olvasnivalók A BIND/named man oldalai: &man.rndc.8; &man.named.8; &man.named.conf.5; Az ISC BIND hivatalos honlapja (angolul) Az ISC BIND hivatalos fóruma (angolul) O'Reilly DNS and BIND 5th Edition RFC1034 - Domain Names - Concepts and Facilities RFC1035 - Domain Names - Implementation and Specification Murray Stokely Készítette: Az Apache webszerver webszerverek beállítása Apache Áttekintés A &os; szolgálja ki a legforgalmasabb honlapok nagy részét szerte a világban. A mögöttük álló webszerverek általában az Apache webszervert alkalmazzák. Az Apache használatához szükséges csomagok megtalálhatóak a &os; telepítõlemezén is. Ha a &os; elsõ telepítésekor még nem telepítettük volna az Apache szerverét, akkor a www/apache13 vagy www/apache12 portból tudjuk feltenni. Az Apache szervert sikeres telepítését követõen be kell állítanunk. Ebben a szakaszban az Apache webszerver 1.3.X változatát mutatjuk be, mivel ezt használják a legtöbben &os; alatt. Az Apache 2.X rengeteg új technológiát vezetett be, de ezekkel itt most nem foglalkozunk. Az Apache 2.X változatával kapcsolatban keressük fel a oldalt. Beállítás Apache konfigurációs állományok Az Apache webszerver konfigurációs állománya &os; alatt /usr/local/etc/apache/httpd.conf néven található. Ez az állomány egy szokványos &unix;-os szöveges konfigurációs állomány, ahol a megjegyzéseket egy # karakterrel vezetjük be. Az itt használható összes lehetséges beállítási lehetõség átfogó ismertetése meghaladná az egész kézikönyv határait, ezért most csak a leggyakrabban módosított direktívákat fogjuk ismertetni. ServerRoot "/usr/local" Ez adja meg az Apache számára az alapértelmezett könyvtárat. A binárisai ezen belül a bin és sbin alkönyvtárakban, a konfigurációs állományai pedig az etc/apache könyvtárban tárolódnak. ServerAdmin saját@címünk.az.interneten Erre a címre küldhetik nekünk a szerverrel kapcsolatos hibákat. Ez a cím egyes szerver által generált oldalakon jelenik meg, például hibák esetében. ServerName www.minta.com A ServerName segítségével meg tudjuk adni, hogy milyen nevet küldjön vissza a szerver a klienseknek olyankor, ha az nem egyezne meg a jelenlegivel (vagyis a www nevet használjuk a gépünk valódi neve helyett). DocumentRoot "/usr/local/www/data" A DocumentRoot adja meg azt a könyvtárat, ahonnan kiszolgáljuk a dokumentumokat. Alapértelmezés szerint az összes kérés erre a könyvtárra fog vonatkozni, de a szimbolikus linkek és az álnevek akár más helyekre is mutathatnak. A változtatások végrehajtása elõtt mindig is jó ötlet biztonsági másolatot készíteni az Apache konfigurációs állományairól. Ahogy sikerült összerakni egy számunkra megfelelõ konfigurációt, készen is állunk az Apache futtatására. Az <application>Apache</application> futtatása Apache indítása és leállítása A többi hálózati szervertõl eltérõen az Apache nem az inetd szuperszerverbõl fut. A kliensektõl érkezõ HTTP kérések minél gyorsabb kiszolgálásának érdekében úgy állítottuk be, hogy önállóan fusson. Ehhez egy szkriptet is mellékeltünk, amellyel igyekeztünk a lehetõ legjobban leegyszerûsíteni a szerver indítását, leállítását és újraindítását. Az Apache elsõ indításához adjuk ki a következõ parancsot: &prompt.root; /usr/local/sbin/apachectl start Így pedig a szervert bármikor leállíthatjuk: &prompt.root; /usr/local/sbin/apachectl stop Ha valamilyen okból megváltoztattuk volna a szerver beállításait, akkor ezen a módon tudjuk újraindítani: &prompt.root; /usr/local/sbin/apachectl restart Ha a jelenleg megnyitott kapcsolatok felbontása nélkül akarjuk újraindítani az Apache szervert, akkor ezt írjuk be: &prompt.root; /usr/local/sbin/apachectl graceful Mindezekrõl az &man.apachectl.8; man oldalon találunk bõvebb leírást. Amennyiben szükségünk lenne az Apache elindítására a rendszer indításakor, akkor a következõ sort vegyünk fel az /etc/rc.conf állományba: apache_enable="YES" Az Apache 2.2 esetében: apache22_enable="YES" Amikor az Apache httpd nevû programjának szeretnénk további paranccsori paramétereket átadni a rendszer indítása során, akkor ezeket így tudjuk megadni az rc.conf állományban: apache_flags="" Most, miután a webszerverünk mûködik, a böngészõnkkel mindezt ellenõrizni is tudjuk a http://localhost/ cím beírásával. Ilyenkor az alapértelmezés szerinti /usr/local/www/data/index.html állomány tartalmát láthatjuk. Virtuális nevek Az Apache a virtuális nevek használatának két különbözõ módját ismeri. Ezek közül az elsõ módszer a név alapú virtualizáció (Name-based Virtual Hosting). Ilyenkor a kliens HTTP/1.1 fejlécébõl próbálja meg a szerver megállapítani a hivatkozási nevet. Segítségével több tartomány is osztozhat egyetlen IP-címen. Az Apache név alapú virtualizációjának beállításához az alábbi beállítást kell hozzátennünk a httpd.conf állományhoz: NameVirtualHost * Ha a webszerverünk neve www.tartomany.hu, és hozzá egy www.valamilyenmasiktartomany.hu virtuális nevet akarunk megadni, akkor azt a következõképpen tehetjük meg a httpd.conf állományon belül: <VirtualHost *> ServerName www.tartomany.hu DocumentRoot /www/tartomany.hu </VirtualHost> <VirtualHost *> ServerName www.valamilyenmasiktartomany.hu DocumentRoot /www/valamilyenmasiktartomany.hu </VirtualHost> A címek és elérési utak helyére helyettesítsük be a használni kívánt címeket és elérési utakat. A virtuális nevek beállításának további részleteivel kapcsolatosan keressük fel az Apache hivatalos dokumentációját a címen (angolul). Apache-modulok Apache modulok Az alap szerver képességeinek kiegészítéséhez több különbözõ Apache modul áll rendelkezésünkre. A &os; Portgyûjteménye az Apache telepítése mellett lehetõséget ad a népszerûbb bõvítményeinek telepítésére is. mod_ssl webszerverek biztonság SSL titkosítás A mod_ssl modul az OpenSSL könyvtár használatával valósít meg erõs titkosítást a biztonságos socket réteg második, illetve harmadik verziójával (Secure Sockets Layer, SSL v2/v3) és a biztonságos szállítási rétegbeli (Transport Layer Security v1) protokoll segítségével. Ez a modul mindent biztosít ahhoz, hogy a megfelelõ hatóságok által aláírt tanúsítványokat tudjunk kérni, és ezáltal egy védett webszervert futtassunk &os;-n. Ha még nem telepítettünk volna fel az Apache szervert, akkor a www/apache13-modssl porton keresztül a mod_ssl modullal együtt is fel tudjuk rakni az Apache 1.3.X változatát. Az SSL támogatása pedig már az Apache 2.X www/apache22 porton keresztül elérhetõ változataiban alapértelmezés szerint engedélyezett. Kapcsolódás nyelvekhez Mindegyik nagyobb szkriptnyelvhez létezik egy külön Apache-modul, amelyek segítségével komplett Apache-modulokat tudunk készíteni az adott nyelven. Gyakran a dinamikus honlapok is így próbálják a szerverbe épített belsõ értelmezõn keresztül a külsõ értelmezõ indításából és benne a szkriptek lefuttatásából fakadó költségeket megspórolni, ahogy errõl a következõ szakaszokban olvashatunk. Dinamikus honlapok webszerverek dinamikus Az utóbbi évtizedben egyre több vállalkozás fordult az internet felé bevételeik és részesedéseinek növelésének reményében, amivel egyre jobban megnõtt az igény a dinamikus honlapokra is. Miközben bizonyos cégek, mint például a µsoft;, a saját fejlesztésû termékeikbe építettek be ehhez támogatást, addig a nyílt forrásokkal foglalkozó közösség sem maradt tétlen és felvette a kesztyût. A dinamikus tartalom létrehozásához többek közt Django, Ruby on Rails, a mod_perl és a mod_php modulok használhatóak. Django Python Django A Django egy BSD típusú licensszel rendelkezõ keretrendszer, amelynek használatával nagy teljesítményû és elegáns webes alkalmazásokat tudunk gyorsan kifejleszteni. Tartalmaz egy objektum-relációs leképezõt, így az adattípusokat Python-objektumokként tudjuk leírni, és ezekhez az objektumokhoz egy sokrétû, dinamikus adatbázis hozzáférést nyújtó alkalmazásfejlesztõi felületet, így a fejlesztõknek egyetlen SQL utasítást sem kell megírniuk. Találhatunk még benne továbbá egy bõvíthetõ sablonrendszert, amelynek köszönhetõen az alkalmazás belsõ mûködése elválasztható a HTML-beli megjelenésétõl. A Django mûködéséhez a mod_python modulra, az Apache szerverre és egy tetszõlegesen választott SQL alapú adatbázisrendszerre van szükség. A hozzá tartozó &os; port mindezeket automatikusan telepíti a megadott beállítások szerint. A Django telepítése az Apache, mod_python3 és a PostgreSQL használatával &prompt.root; cd /usr/ports/www/py-django; make all install clean -DWITH_MOD_PYTHON3 -DWITH_POSTGRESQL Miután a Django és a hozzá szükséges komponensek felkerültek rendszerünkre, hozzunk létre egy könyvtárat a leendõ Django projektünknek és állítsuk be az Apache szervert, hogy az oldalunk belül a megadott linkekre a saját alkalmazásunkat hívja meg a beágyazott Python-értelmezõn keresztül. Az Apache beállítása a Django és mod_python használatához A következõ sort kell hozzátennünk a httpd.conf állományhoz, hogy az Apache bizonyos linkeket a webes alkalmazás felé irányítson át: <Location "/"> SetHandler python-program PythonPath "['/a/django/csomagok/helye/'] + sys.path" PythonHandler django.core.handlers.modpython SetEnv DJANGO_SETTINGS_MODULE azoldalam.beallitasai PythonAutoReload On PythonDebug On </Location> Ruby on Rails Ruby on Rails A Ruby on Rails egy olyan másik nyílt forráskódú keretrendszer, amivel lényegében egy teljes fejlesztõi készletet kapunk és amelyet kifejezetten arra élezték ki, hogy segítségével a webfejlesztõk sokkal gyorsabban tudjanak haladni és a komolyabb alkalmazások gyorsabb elkészítése se okozzon nekik gondot. A Portrgyûjteménybõl pillanatok alatt telepíthetõ. &prompt.root; cd /usr/ports/www/rubygem-rails; make all install clean mod_perl mod_perl Perl Az Apache és Perl egyesítésén fáradozó projekt a Perl programozási nyelv és az Apache webszerver erejének összehangolásán dolgozik. A mod_perl modulon keresztül Perlben vagyunk képesek modulokat készíteni az Apache szerverhez. Ráadásul a szerverben egy belsõ állandó értelmezõ is található hozzá, ezzel igyekeznek megspórolni a külsõ értelmezõ és a Perl indításából keletkezõ többletköltségeket. A mod_perl több különbözõ módon állítható munkába. A mod_perl használatához nem szabad elfelejtenünk, hogy a mod_perl 1.0-ás verziója csak az Apache 1.3 változatával mûködik, és a mod_perl 2.0-ás változata pedig csak az Apache 2.X változataival. A mod_perl 1.0 a www/mod_perl portból telepíthetõ, valamint a statikusan beépített változata a www/apache13-modperl portban található. A mod_perl 2.0 a www/mod_perl2 portból rakható fel. Tom Rhodes Írta: mod_php mod_php PHP A PHP, vagy másik nevén PHP, a hipertext feldolgozó egy általános célú szkriptnyelv, amelyet kifejezetten honlapok fejlesztéséhez hoztak létre. A szabványos HTML ágyazható nyelv felépítésében a C, &java; és Perl nyelveket ötvözi annak elérése érdekében, hogy ezzel segítse a fejlesztõket a dinamikusan generált oldalak minél gyorsabb megírásában. A PHP5 támogatását úgy tudjuk hozzáadni az Apache webszerverhez, ha telepítjük a lang/php5 portot. Ha a lang/php5 portot most telepítjük elõször, akkor a vele kapcsolatos beállításokat tartalmazó OPTIONS menü automatikusan megjelenik. Ha ezzel nem találkoznánk, mert például valamikor korábban már felraktuk volna a lang/php5 portot, akkor a port könyvtárában következõ parancs kiadásával tudjuk újra visszahozni: &prompt.root; make config A beállítások között jelöljük be az APACHE opciót, amelynek eredményeképpen létrejön az Apache webszerverhez használható mod_php5 betölthetõ modul. A PHP4 modult még ma is rengeteg szerver használja több különbözõ okból (például kompatibilitási problémák vagy a már korábban kiadott tartalom miatt). Ha tehát a mod_php5 helyett inkább a mod_php4 modulra lenne szükségünk, akkor a lang/php4 portot használjuk. A lang/php4 portnál is megtalálhatjuk a lang/php5 fordítási idejû beállításainak nagy részét. Az iméntiek révén települnek és beállítódnak a dinamikus PHP alkalmazások támogatásához szükséges mouldok. Az /usr/local/etc/apache/httpd.conf állományban ellenõrizni is tudjuk, hogy az alábbi részek megjelentek-e: LoadModule php5_module libexec/apache/libphp5.so AddModule mod_php5.c <IfModule mod_php5.c> DirectoryIndex index.php index.html </IfModule> <IfModule mod_php5.c> AddType application/x-httpd-php .php AddType application/x-httpd-php-source .phps </IfModule> Ahogy befejezõdött a mûvelet, a PHP modul betöltéséhez mindösszesen az apachectl paranccsal kell óvatosan újraindítanunk a webszervert: &prompt.root; apachectl graceful A PHP jövõbeni frissítéseihez már nem lesz szükségünk a make config parancsra, mivel a korábban kiválasztott OPTIONS menün belüli beállítasainkat a &os; Portgyûjteményéhez tartozó keretrendszer automatikusan elmenti. A PHP &os;-ben megtalálható támogatása kifejezetten moduláris, ezért az alap telepítése igencsak korlátozott. A további elemek hozzáadásához a lang/php5-extensions portot tudjuk használni. A port egy menüvezérelt felületet nyújt a PHP különbözõ bõvítményeinek telepítéséhez. Az egyes bõvítményeket azonban a megfelelõ portok használatával is fel tudjuk rakni. Például PHP5 modulhoz úgy tudunk támogatást adni a MySQL adatbázis szerverhez, ha telepítjük a databases/php5-mysql portot. Miután telepítettünk egy bõvítményt, az Apache szerverrel újra be kell töltetnünk a megváltozott beállításokat: &prompt.root; apachectl graceful Murray Stokely Készítette: Állományok átvitele (FTP) FTP szerverek Áttekintés Az adatállomány átviteli protokoll (File Transfer Protocol, FTP) a felhasználók számára lehetõséget ad az ún. FTP szerverekre állományokat feltölteni, illetve onnan állományokat letölteni. A &os; alaprendszere is tartalmaz egy ilyen FTP szerverprogramot, ftpd néven. Ezért &os; alatt egy FTP szerver beállítása meglehetõsen egyszerû. Beállítás A beállítás legfontosabb lépése, hogy eldöntsük milyen hozzáféréseken át lehet elérni az FTP szervert. Egy hétköznapi &os; rendszerben rengeteg hozzáférés a különbözõ démonokhoz tartozik, de az ismeretlen felhasználók számára nem kellene megengednünk ezek használatát. Az /etc/ftpusers állományban szerepelnek azok a felhasználók, akik semmilyen módon nem érhetik el az FTP szolgáltatást. Alapértelmezés szerint itt találhatjuk az elõbb említett rendszerszintû hozzáféréseket is, de ide minden további nélkül felvehetjük azokat a felhasználókat, akiknél nem akarjuk engedni az FTP elérését. Más esetekben elõfordulhat, hogy csak korlátozni akarjuk egyes felhasználók FTP elérését. Ezt az /etc/ftpchroot állományon keresztül tehetjük meg. Ebben az állományban a lekorlátozni kívánt felhasználókat és csoportokat írhatjuk bele. Az &man.ftpchroot.5; man oldalán olvashatjuk el ennek részleteit, ezért ennek pontos részleteit itt most nem tárgyaljuk. FTP anonim Ha az FTP szerverünkhöz névtelen (anonim) hozzáférést is engedélyezni akarunk, akkor ahhoz elõször készítenünk kell egy ftp nevû felhasználót a &os; rendszerünkben. A felhasználók ezután az ftp vagy anonymous nevek, valamint egy tetszõleges jelszó (ez a hagyományok szerint a felhasználó e-mail címe) használatával is képesek lesznek bejelentkezni. Az FTP szerver ezután a névtelen felhasználók esetében meghívja a &man.chroot.2; rendszerhívást, és ezzel lekorlátozza hozzáférésüket az ftp felhasználó könyvtárára. Két szöveges állományban adhatunk meg a becsatlakozó FTP kliensek számára üdvözlõ üzeneteket. Az /etc/ftpwelcome állomány tartalmát még a bejelentkezés elõtt látni fogják a felhasználók, a sikeres bejelentkezést követõen pedig az /etc/ftpmotd állomány tartalmát látják. Vigyázzunk, mert ennek az állománynak már a bejelentkezési környezethez képest relatív az elérése, ezért a névtelen felhasználók esetében ez konkrétan az ~ftp/etc/ftpmotd állomány lesz. Ahogy beállítottuk az FTP szervert, az /etc/inetd.conf állományban is engedélyeznünk kell. Itt mindössze annyira lesz szükségünk, hogy eltávolítsuk a megjegyzést jelzõ # karaktert a már meglevõ ftpd sor elõl: ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l Ahogy arról már a szót ejtett, az inetd beállításait újra be kell olvastatnunk a konfigurációs állomány megváltoztatása után. A írja le az inetd engedélyezésének részleteit. Az ftpd önálló szerverként is elindítható. Ehhez mindössze elegendõ csak a megfelelõ változót beállítani az /etc/rc.conf állományban: ftpd_enable="YES" Miután megadtuk az iménti változót, a szerver el fog indulni a rendszer következõ indítása során. Szükség esetén természetesen root felhasználóként a következõ paranccsal is közvetlenül elindítható: &prompt.root; /etc/rc.d/ftpd start Most már be is tudunk jelentkezni az FTP szerverre: &prompt.user; ftp localhost Karbantartás syslog naplóállományok FTP Az ftpd démon a &man.syslog.3; használatával naplózza az üzeneteket. Alapértelmezés szerint a rendszernaplózó démon az FTP mûködésére vonatkozó üzeneteket az /var/log/xferlog állományba írja. Az FTP naplóinak helyét az /etc/syslog.conf állományban tudjuk módosítani: ftp.info /var/log/xferlog FTP anonim Legyünk körültekintõek a névtelen FTP szerverek üzemeltetésekor. Azt pedig kétszer is gondoljuk meg, hogy engedélyezzük-e a névtelen felhasználók számára állományok feltöltését, hiszen könnyen azon kaphatjuk magunkat, hogy az FTP oldalunk illegális állománycserék színterévé válik vagy esetleg valami sokkal rosszabb történik. Ha mindenképpen szükségünk lenne erre a lehetõségre, akkor állítsunk be olyan engedélyeket a feltöltött állományokra, hogy a többi névtelen felhasználó ezeket a tartalmuk tüzetes ellenõrzéséig ne is olvashassa. Murray Stokely Készítette: Állomány- és nyomtatási szolgáltatások µsoft.windows; kliensek számára (Samba) Samba szerver Microsoft Windows állományszerver windowszos kliensek nyomtatószerver windowszos kliensek Áttekintés A Samba egy olyan elterjedt nyílt forráskódú szoftver, ami µsoft.windows; kliensek számára tesz lehetõvé állomány- és nyomtatási szolgáltatásokat. Az ilyen kliensek általa helyi meghajtóként képesek elérni a &os; állományrendszerét, vagy helyi nyomtatóként a &os; általt kezelt nyomtatókat. A Samba csomagja általában megtalálható a &os; telepítõeszközén. Ha a &os;-vel együtt nem raktuk fel a Samba csomagját, akkor ezt késõbb net/samba3 port vagy csomag telepítésével pótolhatjuk. Beállítás A Samba konfigurációs állománya a telepítés után /usr/local/share/examples/samba/smb.conf.default néven található meg. Ezt kell lemásolnunk /usr/local/etc/smb.conf néven, amelyet aztán a Samba tényleges használata elõtt módosítanunk kell. Az smb.conf állomány a Samba futásához használt beállításokat tartalmazza, mint például &windows; kliensek számára felkínált a nyomtatók és megosztások adatait. A Samba csomagban ezen kívül találhatunk még egy swat nevû webes eszközt, amellyel egyszerû módon tudjuk az smb.conf állományt állítgatni. A Samba webes adminisztrációs eszköze (SWAT) A Samba webes adminisztrációs segédeszköze (Samba Web Administration Tool, SWAT) az inetd démonon keresztül fut démonként. Ennek megfelelõn az /etc/inetd.conf állományban a következõ sort kell kivennünk megjegyzésbõl, mielõtt a swat segítségével megkezdenénk a Samba beállítását: swat stream tcp nowait/400 root /usr/local/sbin/swat swat Ahogy azt a is mutatja, az inetd démont újra kell indítanunk a megváltozott konfigurációs állományának újbóli beolvasásához. Miután az inetd.conf állományban a swat engedélyezésre került, a böngészõnk segítségével próbáljunk meg a címre csatlakozni. Elõször a rendszer root hozzáférésével kell bejelentkeznünk. Miután sikeresen bejelentkeztünk a Samba beállításait tárgyaló lapra, el tudjuk olvasni a rendszer dokumentációját, vagy a Globals fülre kattintva nekiláthatunk a beállítások elvégzésének. A Globals részben található opciók az /usr/local/etc/smb.conf állomány [global] szekciójában található változókat tükrözik. Általános beállítások Akár a swat eszközzel, akár a /usr/local/etc/smb.conf közvetlen módosításával dolgozunk, a Samba beállítása során a következõkkel mindenképpen össze fogunk futni: workgroup A szervert elérni kívánó számítógépek által használt NT tartomány vagy munkacsoport neve. netbios name NetBIOS A Samba szerver NetBIOS neve. Alapértelmezés szerint ez a név a gép hálózati nevének elsõ tagja. server string Ez a szöveg jelenik meg akkor, ha például a net view paranccsal vagy valamilyen más hálózati segédprogrammal kérdezzük le a szerver beszédesebb leírását. Biztonsági beállítások A /usr/local/etc/smb.conf állományban a két legfontosabb beállítás a választott biztonsági modell és a kliensek felhasználói jelszavainak tárolásához használt formátum. Az alábbi direktívák vezérlik ezeket: security Itt a két leggyakoribb beállítás a security = share és a security = user. Ha a kliensek a &os; gépen található felhasználói neveiket használják, akkor felhasználói szintû védelemre van szükségünk (tehát a user beállításra). Ez az alapértelmezett biztonsági házirend és ilyenkor a klienseknek elõször be kell jelentkezniük a megosztott erõforrások eléréséhez. A megosztás (share) szintû védelem esetében, a klienseknek nem kell a szerveren érvényes felhasználói névvel és jelszóval rendelkezniük a megosztott erõforrások eléréséhez. Ez volt az alapbeállítás a Samba korábbi változataiban. passdb backend NIS+ LDAP SQL adatbázis A Samba számos különbözõ hitelesítési modellt ismer. A klienseket LDAP, NIS+, SQL adatbázis vagy esetleg egy módosított jelszó állománnyal is tudjuk hitelesíteni. Az alapértelmezett hitelesítési módszer a smbpasswd, így itt most ezzel foglalkozunk. Ha feltesszük, hogy az alapértelmezett smbpasswd formátumot választottuk, akkor a Samba úgy fogja tudni hitelesíteni a klienseket, ha elõtte létrehozzuk a /usr/local/private/smbpasswd állományt. Ha a &windows;-os kliensekkel is el akarjuk érni a &unix;-os felhasználói hozzáféréseinket, akkor használjuk a következõ parancsot: &prompt.root; smbpasswd -a felhasználónév A Samba a 3.0.23c verziójától kezdõdõen a hitelesítéshez szükséges állományokat a /usr/local/etc/samba könyvtárban tárolja. A felhasználói hozzáférések hozzáadására innentõl már a tdbsam parancs használata javasolt: &prompt.root; pdbedit felhasználónév A hivatalos Samba HOGYAN ezekrõl a beállításokról szolgál további információkkal (angolul). Viszont az itt vázolt alapok viszont már elegendõek a Samba elindításához. A <application>Samba</application> elindítása A net/samba3 port a Samba irányítására egy új indító szkriptet tartalmaz. A szkript engedélyezéséhez, tehát általa a Samba elindításának, leállításának és újraindításának lehetõvé tételéhez vegyük fel a következõ sort az /etc/rc.conf állományba: samba_enable="YES" Ha még finomabb irányításra vágyunk: nmbd_enable="YES" smbd_enable="YES" Ezzel egyben a rendszer indításakor automatikusan be is indítjuk a Samba szolgáltatást. A Samba a következõkkel bármikor elindítható: &prompt.root; /usr/local/etc/rc.d/samba start Starting SAMBA: removing stale tdbs : Starting nmbd. Starting smbd. Az rc szkriptekkel kapcsolatban a t ajánljuk elolvasásra. A Samba jelen pillanatban három különálló démonból áll. Láthatjuk is, hogy az nmbd és smbd démonokat elindította a samba szkript. Ha az smb.conf állományban engedélyeztük a winbind névfeloldási szolgáltatást is, akkor láthatjuk, hogy ilyenkor a winbindd démon is elindul. A Samba így állítható le akármikor: &prompt.root; /usr/local/etc/rc.d/samba stop A Samba egy összetett szoftvercsomag, amely a µsoft.windows; hálózatokkal kapcsolatos széles körû együttmûködést tesz lehetõvé. Az általa felkínált alapvetõ lehetõségeken túl a többit a honlapon ismerhetjük meg (angolul). Tom Hukins Készítette: Az órák egyeztetése az NTP használatával NTP Áttekintés Idõvel a számítógép órája hajlamos elmászni. A hálózati idõ protokoll (Network Time Protocol, NTP) az egyik módja az óránk pontosan tartásának. Rengeteg internetes szolgáltatás elvárja vagy éppen elõnyben részesíti a számítógép órájának pontosságát. Például egy webszervertõl megkérdezhetik, hogy egy állományt adott ideje módosítottak-e. A helyi hálózatban az egyazon állományszerveren megosztott állományok ellentmondásmentes dátumozása érdekében szinte elengedhetetlen az órák szinkronizálása. Az olyan szolgáltatások, mint a &man.cron.8; is komolyan építkeznek a pontosan járó rendszerórára, amikor egy adott pillanatban kell lefuttatniuk parancsokat. NTP ntpd A &os; alapból az &man.ntpd.8; NTP szervert tartalmazza, amellyel más NTP szerverek segítségével tudjuk beállítani gépünk óráját, vagy éppen idõvel kapcsolatos információkat szolgáltatni másoknak. A megfelelõ NTP szerverek kiválasztása NTP a szerverek kiválasztása Az óránk egyeztetéséhez egy vagy több NTP szerverre lesz szükségünk. Elõfordulhat, hogy a hálózati rendszergazdánk vagy az internet-szolgáltatónk már beállított egy ilyen szervert erre a célra. Ezzel kapcsolatban olvassuk el a megfelelõ leírásokat. A nyilvánosan elérhetõ NTP szerverekrõl készült egy lista, ahonnan könnyedén ki tudjuk keresni a számunkra leginkább megfelelõ (hozzánk legközelebbi) szervert. Ne hagyjuk figyelmen kívül a szerverre vonatkozó házirendet és kérjünk engedélyt a használatához, amennyiben ez szükséges. Több, egymással közvetlen kapcsolatban nem álló NTP szerver választásával járunk jól, ha netalán az egyikük váratlanul elérhetetlenné vagy az órája pontatlanná válna. Az &man.ntpd.8; a visszakapott válaszokat intelligensen használja fel, mivel esetükben a megbízható szervereket részesíti elõnyben. A gépünk beállítása NTP beállítása Alapvetõ beállítások ntpdate Ha a számítógépünk indításakor akarjuk egyeztetni az óránkat, akkor erre az &man.ntpdate.8; nevû programot használhatjuk. Ez olyan asztali gépek számára megfelelõ választás, amelyeket gyakran indítanak újra és csak idõnként kell szinkronizálnunk. A legtöbb gépnek viszont az &man.ntpd.8; használatára van szüksége. Az &man.ntpdate.8; elindítása olyan esetekben is hasznos, ahol az &man.ntpd.8; is fut. Az &man.ntpd.8; az órát fokozatosan állítja, ellenben az &man.ntpdate.8; az eltérés mértékétõl és irányától függetlenül egyszerûen átállítja a gép óráját a pontos idõre. Az &man.ntpdate.8; elindítását úgy tudjuk engedélyezni a rendszer indításakor, ha az /etc/rc.conf állományba berakjuk az ntpdate_enable="YES" sort. Emellett még ntpdate_flags változóban meg kell adnunk az alkalmazott beállítások mellett azokat a szervereket, amelyekkel szinkronizálni akarunk. NTP ntp.conf Általános beállítások Az NTP az /etc/ntp.conf állományon keresztül állítható, amelyek felépítését az &man.ntp.conf.5; man oldal tárgyalja. Íme erre egy egyszerû példa: server ntplocal.minta.com prefer server timeserver.minta.org server ntp2a.minta.net driftfile /var/db/ntp.drift A server beállítás adja meg az egyeztetéshez használt szervereket, soronként egyet. Ha egy szerver mellett szerepel még a prefer paraméter is, ahogy azt a példában a ntplocal.minta.com mellett láthattuk, akkor a többivel szemben azt a szervert fogjuk elõnyben részesíteni. Az így kiemelt szervertõl érkezõ választ abban az esetben viszont eldobjuk, hogy a többi szervertõl kapott válasz jelentõs mértékben eltér tõle. Minden más esetben a õ válasza lesz a mérvadó. A prefer paramétert általában olyan NTP szerverekhez használják, amelyek közismerten nagy pontosságúak, tehát például külön erre a célra szánt felügyeleti eszközt is tartalmaznak. A driftfile beállítással azt az állományt adjuk meg, amiben a rendszeróra frekvencia eltolódásait tároljuk. Az &man.ntpd.8; program ezzel ellensúlyozza automatikusan az óra természetes elmászását, ezáltal lehetõvé téve, hogy egy viszonylag pontos idõt kapjuk még abban az esetben is, amikor egy kis idõre külsõ idõforrások nélkül maradnánk. A driftfile beállítással egyben azt az állományt jelöljük ki, amely az NTP szervertõl kapott korábbi válaszokat tárolja. Ez az NTP mûködéséhez szükséges belsõ adatokat tartalmaz, ezért semmilyen más programnak nem szabad módosítania. A szerverünk elérésének szabályozása Alapértelmezés szerint az NTP szerverünket bárki képes elérni az interneten. Az /etc/ntp.conf állományban szereplõ restrict beállítás segítségével azonban meg tudjuk mondani, milyen gépek érhetik el a szerverünket. Ha az NTP szerverünk felé mindenféle próbálkozást el akarunk utasítani, akkor az /etc/ntp.conf állományba a következõ sort kell felvennünk: restrict default ignore Ezzel egyben azonban a helyi beállításainkban szereplõ szerverek elérését is megakadályozzuk. Ha külsõ NTP szerverekkel is szeretnénk szinkronizálni, akkor itt is engedélyezünk kell ezeket. Errõl bõvebben lásd az &man.ntp.conf.5; man oldalon. Ha csak a belsõ hálózatunkban levõ gépek számára szeretnénk elérhetõvé tenni az órák egyeztetését, de sem a szerver állapotának módosítását nem engedélyezzük, sem pedig azt, hogy a vele egyenrangú szerverekkel szinkronizáljon, akkor az iménti helyett a restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap sort írjuk bele, ahol a 192.168.1.0 a belsõ hálózatunk IP-címe és a 255.255.255.0 a hozzá tartozó hálózati maszk. Az /etc/ntp.conf több restrict típusú beállítást is tartalmazhat. Ennek részleteirõl az &man.ntp.conf.5; man oldalon, az Access Control Support címû szakaszban olvashatunk. Az NTP futtatása Úgy tudjuk az NTP szervert elindítani a rendszerünkkel együtt, ha az /etc/rc.conf állományban szerepeltetjük az ntpd_enable="YES" sort. Ha az &man.ntpd.8; számára további beállításokat is át akarunk adni, akkor az /etc/rc.conf állományban adjuk meg az ntpd_flags paramétert. Ha a gépünk újraindítása nélkül akarjuk elindítani a szerver, akkor az ntpd parancsot adjuk ki az /etc/rc.conf állományban a ntpd_flags változóhoz megadott paraméterekkel. Mint például: &prompt.root; ntpd -p /var/run/ntpd.pid Az ntpd használati idõleges internet csatlakozással Az &man.ntpd.8; program megfelelõ mûködéséhez nem szükséges állandó internet kapcsolat. Ha azonban igény szerinti tárcsázással építjünk fel ideiglenes kapcsolatot, akkor érdemes letiltani az NTP forgalmát, nehogy feleslegesen aktiválja vagy tartsa életben a vonalat. Ha PPP típusú kapcsolatunk van, akkor az /etc/ppp/ppp.conf állományban a filter direktívával tudjuk ezt leszabályozni. Például: set filter dial 0 deny udp src eq 123 # Nem engedjük az NTP által küldött adatoknak, hogy tárcsázást # kezdeményezzenek: set filter dial 1 permit 0 0 set filter alive 0 deny udp src eq 123 # Nem engedjük az NTP adatainak, hogy fenntartsák a kapcsolatot: set filter alive 1 deny udp dst eq 123 set filter alive 2 permit 0/0 0/0 Mindenezekrõl részletesebb felvilágosítást a &man.ppp.8; man oldal PACKET FILTERING címû szakaszában és a /usr/share/examples/ppp/ könyvtárban található példákban kaphatunk. Egyes internet-szolgáltatók blokkolják az alacsonyabb portokat, ezáltal az NTP nem használható, mivel a válaszok nem fogják elérni a gépünket. További olvasnivalók Az NTP szerver dokumentációja HTML formátumban a /usr/share/doc/ntp/ könyvtárban található. Tom Rhodes Készítette: Távoli gépek naplózása <command>syslogd</command> használatával A rendszernaplókkal kapcsolatos mûveletek egyaránt fontosak a biztonság és a karbantartás szempontjából. Ha közepes vagy nagyobb méretû, esetleg különbözõ típusú hálózatokban adminisztrálunk több gépet, akkor könnyen átláthatatlanná válhat a naplók rendszeres felügyelete. Ilyen helyzetekben a távoli naplózás beállításával az egész folyamatot sokkal kényelmesebbé tehetjük. Némileg képesek vagyunk enyhíteni a naplóállományok kezelésének terhét, ha egyetlen központi szerverre küldjük át az adatokat. Ekkor a &os; alaprendszerében megtalálható alapeszközökkel, mint például a &man.syslogd.8; vagy a &man.newsyslog.8; felhasználásával egyetlen helyen be tudjuk állítani a naplók összegyûjtését, összefésülését és cseréjét. A most következõ példa konfigurációban az A gép, a naploszerver.minta.com fogja gyûjteni a helyi hálózatról érkezõ naplóinformációkat. A B gép, a naplokliens.minta.com pedig a szervernek küldi a naplózandó adatokat. Éles környezetben mind a két gépnek rendelkeznie kell megfelelõ DNS bejegyzésekkel, vagy legalább szerepelniük kell egymás /etc/hosts állományaiban. Ha ezt elmulasztjuk, a szerver nem lesz hajlandó adatokat fogadni. A naplószerver beállítása A naplószerverek olyan gépek, amelyeket úgy állítottunk be, hogy naplózási információkat tudjanak fogadni távoli számítógépekrõl. A legtöbb esetben így egyszerûsíteni tudunk a konfiguráción, vagy olykor egyszerûen csak hasznos, ha ezt a megoldást alkalmazzuk. Függetlenül attól, hogy miért használjuk, a továbblépés elõtt néhány elõkészületet meg kell tennünk. Egy rendesen beállított naplószervernek legalább a következõ követelményeknek kell eleget tennie: az 514-es UDP portot engedélyezni kell mind a kliensen, mind pedig a szerveren futó tûzfal szabályrendszerében; a &man.syslogd.8; képes legyen a távoli kliens gépekrõl érkezõ üzeneteket fogadni; a &man.syslogd.8; szervernek és az összes kliensnek rendelkeznie kell érvényes DNS (közvetlen és inverz) bejegyzésekkel vagy szerepelnie kell az /etc/hosts állományban. A naplószerver beállításához mindegyik klienst fel kell vennünk az /etc/syslog.conf állományba, valamint meg kell adnunk a megfelelõ funkciót (facility): +naplokliens.minta.com *.* /var/log/naplokliens.log A &man.syslog.conf.5; man oldalán megtalálhatjuk a különbözõ támogatott és elérhetõ funkciókat. Miután beállítottuk, az összes adott funkcióhoz tartozó üzenet az elõbb megadott állományba (/var/log/naplokliens.log) fog kerülni. A szerveren továbbá meg kell adnunk a következõ sort az /etc/rc.conf állományban: syslogd_enable="YES" syslogd_flags="-a naplokliens.minta.com -vv" Az elsõ sorral engedélyezzük a syslogd elindítását a rendszerindítás során, majd a második sorral engedélyezzük, hogy a kliens naplózni tudjon a szerverre. Itt még látható a opció, amellyel a naplózott üzenetek részletességét tudjuk növelni. Ennek nagyon fontos a szerepe a naplózási funkciók behangolásakor, mivel így a rendszergazdák pontosan láthatják milyen típusú üzenetek milyen funkcióval kerültek rögzítésre a naplóban. Befejezésképpen hozzuk létre a naplóállományt. Teljesen mindegy, hogy erre milyen megoldást alkalmazunk, például a &man.touch.1; remekül megfelel: &prompt.root; touch /var/log/naplokliens.log Ezután indítsuk újra és ellenõrizzük a syslogd démont: &prompt.root; /etc/rc.d/syslogd restart &prompt.root; pgrep syslog Ha válaszul megkapjuk a futó démon azonosítóját, akkor sikerült újraindítanunk, elkezdhetjük a kliens beállítását. Ha valamiért nem indult volna újra a szerver, az /var/log/messages állományból próbáljuk meg kideríteni az okát. A naplókliens beállítása A naplókliens az a gép, amely egy helyi naplópéldány karbantartása mellett továbbküldni a naplózandó információkat egy naplószervernek. Hasonlóan a naplószerverekhez, a klienseknek is teljesítenie bizonyos alapvetõ elvárásokat: a &man.syslogd.8; démon küldjön bizonyos típusú üzeneteket a naplószervernek, amely ezeket pedig képes legyen fogadni; a hozzá tartozó tûzfal engedje át a forgalmat az 514-es UDP porton; rendelkezzen mind közvetlen, mind pedig inverz DNS bejegyzéssel, vagy szerepeljenek az /etc/hosts állományban. A kliens beállítása sokkal egyszerûbb a szerverhez képest. A kliensen adjuk hozzá a következõ sorokat az /etc/rc.conf állományhoz: syslogd_enabled="YES" syslogd_flags="-s -vv" A szerver beállításaihoz hasonlóan itt is engedélyezzük a syslogd démont és megnöveljük a naplózott üzenetek részletességét. A kapcsolóval pedig megakadályozzuk, hogy a kliens más gépekrõl is hajlandó legyen naplóüzeneteket elfogadni. A funkciók a rendszernek azon részét írják le, amelyhez létrejön az adott üzenet. Tehát például az ftp és ipfw egyaránt ilyen funkciók. Amikor keletkezik egy naplóüzenet valamelyikükhöz, általában megjelenik a nevük. A funkciókhoz tartozik még egy prioritás vagy szint is, amellyel az adott üzenet fontosságát jelzik. Ezek közül a leggyakoribb a warning (mint figyelmeztetés) és info (mint információ). A használható funkciók és a hozzájuk tartozó prioritások teljes listáját a &man.syslog.3; man oldalán olvashatjuk. A naplószervert meg kell adnunk a kliens /etc/syslog.conf állományában. Itt a @ szimbólummal jelezzük, hogy az adatokat egy távoli szerverre szeretnénk továbbküldeni, valahogy így: *.* @naploszerver.minta.com Ezután a beállítás érvényesítéséhez újra kell indítanunk a syslogd démont: &prompt.root; /etc/rc.d/syslogd restart A &man.logger.1; használatával próbáljuk ki a kliensrõl a aplóüzenetek hálózaton keresztüli küldését, és küldjünk valamit a syslogd démonnak: &prompt.root; logger "Udvozlet a naplokliensrol" A parancs kiadása után az üzenetnek mind a kliens, mind pedig a szerver /var/log/messages állományában meg kell jelennie. Hibakeresés Elõfordulhat, hogy a naplószerver valamiért nem kapja meg rendesen az üzeneteket, ezért valamilyen módon meg kell keresnünk a hiba okát. Ez több minden lehet, de általában két leggyakoribb ok valamilyen hálózati kapcsolódási vagy DNS beállítási hiba. Ezek teszteléséhez gondoskodjunk róla, hogy a gépek kölcsönösen elérhetõek egymásról az /etc/rc.conf állományban megadott hálózati nevük szerint. Ha ezzel látszólag minden rendben van, akkor próbáljuk meg módosítani a syslogd_flags értékét az /etc/rc.conf állományban. A most következõ példában a /var/log/naplokliens.log teljesen üres, illetve a /var/log/messages állomány semmilyen hibára utaló okot nem tartalmaz. A hibakereséshez még több információt a syslogd_flags átírásával tudunk kérni: syslogd_flags="-d -a naploklien.minta.com -vv" Természetesen ne felejtsük el újraindítani a szervert: &prompt.root; /etc/rc.d/syslogd restart A démon újraindítása után közvetlenül az alábbiakhoz hasonló üzenetek árasztják el a képernyõt: logmsg: pri 56, flags 4, from naploszerver.minta.com, msg syslogd: restart syslogd: restarted logmsg: pri 6, flags 4, from naploszerver.minta.com, msg syslogd: kernel boot file is /boot/kernel/kernel Logging to FILE /var/log/messages syslogd: kernel boot file is /boot/kernel/kernel cvthname(192.168.1.10) validate: dgram from IP 192.168.1.10, port 514, name naplokliens.minta.com; rejected in rule 0 due to name mismatch. A diagnosztikai üzeneteket végigolvasva nyilvánvaló válik, hogy azért dobja el az üzeneteket a szerver, mert nem megfelelõ a gép neve. Miután átnézzük a beállításainkat, felfedezhetünk az /etc/rc.conf állományban egy apró hibát: syslogd_flags="-d -a naploklien.minta.com -vv" Láthatjuk, hogy ebben a sorban a naplokliens névnek kellene szerepelni, nem pedig a naploklien névnek. Miután elvégeztük a szükséges javításokat, indítsuk újra a szervert és vizsgáljuk meg az eredményt: &prompt.root; /etc/rc.d/syslogd restart logmsg: pri 56, flags 4, from naploszerver.minta.com, msg syslogd: restart syslogd: restarted logmsg: pri 6, flags 4, from naploszerver.minta.com, msg syslogd: kernel boot file is /boot/kernel/kernel syslogd: kernel boot file is /boot/kernel/kernel logmsg: pri 166, flags 17, from naploszerver.minta.com, msg Dec 10 20:55:02 <syslog.err> naploszerver.minta.com syslogd: exiting on signal 2 cvthname(192.168.1.10) validate: dgram from IP 192.168.1.10, port 514, name naplokliens.minta.com; accepted in rule 0. logmsg: pri 15, flags 0, from naplokliens.minta.com, msg Dec 11 02:01:28 pgj: Masodik teszt uzenet Logging to FILE /var/log/naplokliens.log Logging to FILE /var/log/messages Itt már minden üzenet rendben megérkezett és a megfelelõ állományokba került (a /var/log/messages a kliensen, és a /var/log/naplokliens.log a szerveren)). Biztonsági megfontolások Mint minden hálózati szolgáltatás esetén, ilyenkor is figyelembe kell vennünk bizonyos biztonsági megfontolásokat a tényleges konfiguráció kiépítése elõtt. Olykor elõfordulhat, hogy a naplók különbözõ kényes információkat tartalmaznak, mint például a helyi rendszeren futó szolgáltatások nevei, felhasználói nevek vagy egyéb konfigurációs adatok. A kliens és a szerver között hálózaton utazó adatok viszont se nem titkosítottak, se nem jelszóval védettek. Ha titkosítást szeretnénk használni, akkor javasoljuk például a security/stunnel portot, amellyel egy titkosított tunnelen keresztül tudunk adatokat küldeni a hálózaton. A helyi rendszer biztonságának szavatolása is fontos lehet. A naplók sem a használat során, sem pedig a lecserélésük után nem kerülnek titkosításra. Emiatt a helyi rendszerhez hozzáférõ felhasználók kedvükre nyerhetnek ki belõlük a rendszerünket érintõ konfigurációs információkat. Ezért ilyenkor nagyon fontos, hogy mindig a megfelelõ engedélyeket állítsuk be a naplókra. A &man.newsyslog.8; segédprogrammal be tudjuk állítani a frissen létrehozott és a lecserélt naplók engedélyeit. Tehát könnyen megakadályozhatjuk a helyi felhasználók kíváncsiskodását, ha itt a naplók engedélyeit például a 600 kóddal adjuk meg.