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 35efaa047d..6b0ca7d44e 100644 --- a/hu_HU.ISO8859-2/books/handbook/advanced-networking/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/advanced-networking/chapter.sgml @@ -1,7832 +1,7829 @@ 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. 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;. BGP RIP OSPF 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 a &man.wlan.4; man oldal elején találhatóak. 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. 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" 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ózatunk teljesen nyitott (azaz 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 ath # Atheros IEEE 802.11 vezeték nélküli hálózati meghajtó device ath_hal # az Atheros meghajtó hardveres rétege device ath_rate_sample # John Bicket "SampleRate" vezérlési algoritmusa device wlan # a 802.11 támogatása (kell!) device wlan_scan_ap # a 802.11 AP módú keresés device wlan_scan_sta # a 802.11 STA módú keresés device wlan_wep # WEP titkosítás támogatása a 802.11 eszközök számára device wlan_ccmp # AES-CCMP titkosítás támogatása a 802.11 eszközök számára device wlan_tkip # TKIP és Michael titkosítás támogatása a 802.11 eszközök számára A fentiek 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 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 ath0 up scan SSID BSSID CHAN RATE S:N INT CAPS dlinkap 00:13:46:49:41:76 6 54M 29:3 100 EPS WPA WME freebsdap 00:11:95:c3:0d:ac 1 54M 22:1 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. 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 ath0 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á: 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: ifconfig_ath0="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): ifconfig_ath0="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 ifconfig_ath0="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: ifconfig_ath0="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: ifconfig_ath0="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 ath0 ath0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet6 fe80::211:95ff:fed5:4362%ath0 prefixlen 64 scopeid 0x1 inet 192.168.1.100 netmask 0xffffff00 broadcast 192.168.1.255 ether 00:11:95:d5:43:62 media: IEEE 802.11 Wireless Ethernet autoselect (OFDM/54Mbps) status: associated ssid dlinkap channel 6 bssid 00:13:46:49:41:76 authmode OPEN privacy OFF txpowmax 36 protmode CTS bintval 100 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 pedig arról számol be, hogy a kommunikáció nem titkosított (OPEN). 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: ifconfig_ath0="ssid saját_ssid inet 192.168.1.100 netmask 255.255.255.0" 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: 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 ath0 to 255.255.255.255 port 67 interval 5 DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 6 DHCPOFFER from 192.168.0.1 DHCPREQUEST on ath0 to 255.255.255.255 port 67 DHCPACK from 192.168.0.1 bound to 192.168.0.254 -- renewal in 300 seconds. ath0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet6 fe80::211:95ff:fed5:4362%ath0 prefixlen 64 scopeid 0x1 inet 192.168.0.254 netmask 0xffffff00 broadcast 192.168.0.255 ether 00:11:95:d5:43:62 media: IEEE 802.11 Wireless Ethernet autoselect (OFDM/36Mbps) status: associated ssid freebsdap channel 1 bssid 00:11:95:c3:0d:ac authmode WPA privacy ON deftxkey UNDEF TKIP 2:128-bit txpowmax 36 protmode CTS roaming MANUAL bintval 100 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 ath0 -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=TKIP GTK=TKIP] 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 ath0 DHCPREQUEST on ath0 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 ath0 ath0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet6 fe80::211:95ff:fed5:4362%ath0 prefixlen 64 scopeid 0x1 inet 192.168.0.254 netmask 0xffffff00 broadcast 192.168.0.255 ether 00:11:95:d5:43:62 media: IEEE 802.11 Wireless Ethernet autoselect (OFDM/48Mbps) status: associated ssid freebsdap channel 1 bssid 00:11:95:c3:0d:ac authmode WPA privacy ON deftxkey UNDEF TKIP 2:128-bit txpowmax 36 protmode CTS roaming MANUAL bintval 100 Ha az /etc/rc.conf állományban szerepel a ifconfig_ath0="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 ath0 inet 192.168.0.100 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 inet 192.168.0.100 netmask 0xffffff00 broadcast 192.168.0.255 ether 00:11:95:d5:43:62 media: IEEE 802.11 Wireless Ethernet autoselect (OFDM/36Mbps) status: associated ssid freebsdap channel 1 bssid 00:11:95:c3:0d:ac authmode WPA privacy ON deftxkey UNDEF TKIP 2:128-bit txpowmax 36 protmode CTS roaming MANUAL bintval 100 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õ sort: ifconfig_ath0="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 ath0 to 255.255.255.255 port 67 DHCPREQUEST on ath0 to 255.255.255.255 port 67 DHCPACK from 192.168.0.20 bound to 192.168.0.254 -- renewal in 300 seconds. ath0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet6 fe80::211:95ff:fed5:4362%ath0 prefixlen 64 scopeid 0x1 inet 192.168.0.254 netmask 0xffffff00 broadcast 192.168.0.255 ether 00:11:95:d5:43:62 media: IEEE 802.11 Wireless Ethernet autoselect (DS/11Mbps) status: associated ssid freebsdap channel 1 bssid 00:11:95:c3:0d:ac authmode WPA2/802.11i privacy ON deftxkey UNDEF TKIP 2:128-bit txpowmax 36 protmode CTS roaming MANUAL bintval 100 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õ sort is vegyük fel az /etc/rc.conf állományba: ifconfig_ath0="WPA DHCP" Ezután hozzuk mûködésbe a felületet: &prompt.root; /etc/rc.d/netif start Starting wpa_supplicant. DHCPREQUEST on ath0 to 255.255.255.255 port 67 DHCPREQUEST on ath0 to 255.255.255.255 port 67 DHCPREQUEST on ath0 to 255.255.255.255 port 67 DHCPACK from 192.168.0.20 bound to 192.168.0.254 -- renewal in 300 seconds. ath0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet6 fe80::211:95ff:fed5:4362%ath0 prefixlen 64 scopeid 0x1 inet 192.168.0.254 netmask 0xffffff00 broadcast 192.168.0.255 ether 00:11:95:d5:43:62 media: IEEE 802.11 Wireless Ethernet autoselect (DS/11Mbps) status: associated ssid freebsdap channel 1 bssid 00:11:95:c3:0d:ac authmode WPA2/802.11i privacy ON deftxkey UNDEF TKIP 2:128-bit txpowmax 36 protmode CTS roaming MANUAL bintval 100 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: ifconfig_ath0="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 ath0 to 255.255.255.255 port 67 DHCPREQUEST on ath0 to 255.255.255.255 port 67 DHCPREQUEST on ath0 to 255.255.255.255 port 67 DHCPACK from 192.168.0.20 bound to 192.168.0.254 -- renewal in 300 seconds. ath0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet6 fe80::211:95ff:fed5:4362%ath0 prefixlen 64 scopeid 0x1 inet 192.168.0.254 netmask 0xffffff00 broadcast 192.168.0.255 ether 00:11:95:d5:43:62 media: IEEE 802.11 Wireless Ethernet autoselect (DS/11Mbps) status: associated ssid freebsdap channel 1 bssid 00:11:95:c3:0d:ac authmode WPA2/802.11i privacy ON deftxkey UNDEF TKIP 2:128-bit txpowmax 36 protmode CTS roaming MANUAL bintval 100 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 ath0 ssid saját_hálózat wepmode on weptxkey 3 wepkey 3:0x3456789012 \ inet 192.168.1.100 netmask 255.255.255.0 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 ath0 -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 ath0 ssid freebsdap mediaopt adhoc inet 192.168.0.1 netmask 255.255.255.0 &prompt.root; ifconfig ath0 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 <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 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 ath0 up scan SSID BSSID CHAN RATE S:N INT CAPS freebsdap 02:11:95:c3:0d:ac 2 54M 19:3 100 IS 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 ath0 ssid freebsdap mediaopt adhoc 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 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 <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 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> 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 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: &prompt.root; ifconfig ath0 ssid freebsdap mode 11g mediaopt hostap inet 192.168.0.1 netmask 255.255.255.0 Az ifconfig parancs ismételt használatával le is tudjuk kérdezni az ath0 felület állapotát: &prompt.root; ifconfig ath0 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 OFF txpowmax 38 bmiss 7 protmode CTS burst dtimperiod 1 bintval 100 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 megtörténik: ifconfig_ath0="ssid freebsdap mode 11g mediaopt hostap inet 192.168.0.1 netmask 255.255.255.0" 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 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 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) status: associated ssid freebsdap channel 1 bssid 00:11:95:c3:0d:ac authmode OPEN privacy OFF txpowmax 36 protmode CTS bintval 100 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 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 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 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 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 állapotának megtekintéséhez adjuk ki megint az ifconfig parancsot: &prompt.root; ifconfig ath0 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 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 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 szerint. 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 - Másoljuk az - /usr/share/examples/netgraph/bluetooth/rc.bluetooth - állományt valamilyen alkalmas helyre, - például az /etc/rc.bluetooth - könyvtárba. Ez a 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 + 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.bluetooth start ubt0 + &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. fec A Cisco EtherChannel 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 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. 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. roundrobin 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 ezeket a felületeket egy 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 hozzunk létre a lagg felületet: &prompt.root; ifconfig lagg0 create &prompt.root; ifconfig lagg0 up laggproto lacp laggport fxp0 laggport fxp1 Ellenõrizzük a felület állapotát az ifconfig parancs meghívásával. Az ACTIVE, 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 switch-en is látni fogjuk, hogy mely portjai aktívak. Pontosabb részleteket a show lacp neighbor detail paranccsal kapunk. 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 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ásik felület használatára tudunk áttérni. &prompt.root; ifconfig lagg0 create &prompt.root; ifconfig lagg0 up laggproto failover laggport fxp0 laggport fxp1 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. 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-dhcp3-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 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. rendszermag beállítása Beállítás A rendszermag beállításait tartalmazó állományban a következõ beállításokat 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 következõnek 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 Access 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 1c6a850bde..724678869a 100644 --- a/hu_HU.ISO8859-2/books/handbook/config/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/config/chapter.sgml @@ -1,4816 +1,4816 @@ 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özökeinken; 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, de ne feledjük, hogy a /var/tmp könyvtárban el kell tudni férnie a csomagoknak. A /usr partíció tartalmazza a rendszer mûködéséhez elengedhetetlenül fontos legtöbb állományt, a portok gyûjteményét (ajánlott, lásd &man.ports.7;) és a forráskódot (választható). Ez utóbbiak a telepítés során választhatóak. Ehhez a partícióhoz legalább két gigabyte-nyi hely ajánlott. Vegyük figyelembe a tárbeli igényeket, amikor megválasztjuk 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. Partícionáljuk 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 partícioná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, amelyek 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 gyakran ilyenkor ú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 rc.d eljövetele elõtt az alkalmazások indításához be kellett másolni egy egyszerû indítószkriptet a /usr/local/etc/rc.d könyvtárba, melyet aztán a rendszer indításához használt szkriptek olvastak be. Ezek a szkriptek aztán késõbb a rendszer indítása során végrehajtódtak. Miközben rengetegen próbálták beolvasztani ezt a megszokott konfigurációs stílust egy új rendszerbe, a külsõ alkalmazások mûködtetéséhez továbbra is az elõbb említett könyvtárban elhelyezett szkriptekre van szükség. A szkriptek közötti apró eltérések leginkább abban nyilvánulnak meg, hogy az rc.d könyvtárat használják-e vagy sem. A &os; 5.1-es verziója elõtt a régebbi konfigurációs megoldást használták, de az új szkriptek szinte az összes esetben megfelelõnek bizonyultak. Jóllehet minden szkriptnek teljesítenie kell minimális elvárásokat, ezek a legtöbb esetben függetlenek a &os; konkrét verziójától. Minden szkriptnek a rendszer által végrehajthatónak kell lennie. Ezt úgy érhetjük el, ha a chmod parancs felhasználásával beállítjuk a 555 kódú engedélyeket. Ezen felül a szkriptnek még tudnia kell kezelnie a start és stop paramétereket. A legegyszerûbb indítószkript valahogy így nézhet ki: #!/bin/sh echo -n ' utility' case "$1" in start) /usr/local/bin/utility ;; stop) kill -9 `cat /var/run/utility.pid` ;; *) echo "Usage: `basename $0` {start|stop}" >&2 exit 64 ;; esac exit 0 Ez a szkript képes értelmezni a start és stop parancsokat az alkalmazás számára, ami itt egyszerûen csak a utility nevet kapta. Manuálisan így tudjuk elindítani: &prompt.root; /usr/local/etc/rc.d/utility start Habár nem mindegyik külsõ szoftvert kell külön megadni az rc.conf állományban, majdnem minden nap módosítani kell egy portot a beállítások elfogadásához. Az egyes alkalmazásokra vonatkozó kiegészítõ információkhoz nézzük meg a telepítés után keletkezõ üzeneteket. Egyes külsõ szoftverekhez mellékelnek olyan indítószkripteket, amelyek lehetõvé teszik az alkalmazás meghívását az rc.d könyvtárból. Ezekrõl a következõ szakaszban még szólni fogunk. 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 # # 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_flags=${utility_flags-""} utility_pidfile=${utility_pidfile-"/var/run/utility.pid"} . /etc/rc.subr name="utility" rcvar=`set_rcvar` command="/usr/local/sbin/utility" load_rc_config $name pidfile="${utility_pidfile}" start_cmd="echo \"Starting ${name}.\"; /usr/bin/nice -5 ${command} ${utility_flags} ${command_args}" 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 paranccsorban á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 karbantsanak 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 ugyanazt, 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 átadható, 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 a /etc/rc.d könyvtárban található állományokról. A legtöbbjük olyan alapvetõ szolgáltatások, amelyeket 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 megadott 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 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 a feladatukat, ha a nekik megfelelõ változókat beállítottuk az /etc/rc.conf állományban. Tehát például a 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 le tudjuk ellenõrizni, 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 a 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 a 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 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ést 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érlelni 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 meglevõeken, 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 által ismert összes eszközt és 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 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 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 titkoknak 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;-szal 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 /windowszos/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 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 az 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 /boot/modules könyvtárba. Ezután adjuk hozzá a következõ sort a /boot/loader.conf állomány tartalmához: W32DRIVER_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 ether 00:a0:cc:da:da:da 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 ether 00:a0:cc:da:da:db media: Ethernet 10baseT/UTP status: no carrier lp0: flags=8810<POINTOPOINT,SIMPLEX,MULTICAST> mtu 1500 lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 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 legyünk szívesek elolvasni a hozzátartozó man oldalt. Hozzátennénk, hogy IPv6 (inet6 stb.) típusú bejegyzések nem szerepelnek a példában. 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 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 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 le 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. 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. Ahogy a rendszerünk mûködõképessé vált, 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 jutassa 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, ami 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 az 10.1.1.1 címtõl az 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>/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áltozatait. /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, ami á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 a 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ást. Általában az is megfelelõ, aa 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 ez 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, és ezzel így 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 (a 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 amely 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. Az 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, amik é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, amit 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 legalább érdemes 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õbb képlet értelmében csak 36 programunk futhat egymással párhuzamosan, beleértve mindazt a kb. 18 programot, amik a rendszerrel együtt indulnak, illetve még azt a további 15 programot, amit 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 elindít 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 a 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 le szokták korlátozni 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, ami 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 hasznosnak bizonyulhat, 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) és é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 adatinak és csomagváltásokhoz tartozó sorok 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 a 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ük 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 úgy 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 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 tudjuk korrigálni az APM-es BIOS-ok problémáit, ha frissíti az alaplapi ROM-ot. Ez viszont egy nagyon kockázatos folyamat, aminek hibája révén a rendszerünk helyrehozhatatlan állapotba kerül. 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 tesztelés is egyszerûbbé válik. Másik magyarázta, 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 APM egyszerre nem használatóak. 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 csak a legtöbb felhasználó számára 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 kisegíteni az ACPI fejlesztõket a nyomonkövetésében és kijavításában. Köszönjük, hogy ezt elolvassuk és segédkezünk a rendszerünkkel kapcsolatban felmerült 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, igyezzü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 okoztt ö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 és 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. Legyünk türelmesek, hiszen emellett mindannyiunk dolgozik. 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 a problémánkkal. 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 neveit szerepelnek faszerû elrendezésben. Az ACPI-hoz tartozó meghajtónak értelmeznie kell tudnia ezeket a rögzített táblázatokat, implementálnia egy bytekód-értelmezõt, módosítania 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óak. 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. 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 a pontosan melyikkel lehet a gond, és ezzel pedig 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ális 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/mirrors/chapter.sgml b/hu_HU.ISO8859-2/books/handbook/mirrors/chapter.sgml index db6bf96431..2685ca8823 100644 --- a/hu_HU.ISO8859-2/books/handbook/mirrors/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/mirrors/chapter.sgml @@ -1,4117 +1,4117 @@ A &os; beszerzése CD és DVD kiadók Kiskereskedelmi dobozos termékek A &os; beszerezhetõ számos kiskereskedõtõl dobozos termék formájában is (&os; CD-k, egyéb szoftverek és nyomtatott dokumentáció):
CompUSA WWW:
Frys Electronics WWW:
CD- és DVD-készletek &os; CD- és DVD-készletek rengeteg helyrõl rendelhetõek:
BSD Mall (Daemon News) PO Box 161 Nauvoo, IL 62354 Egyesült Államok Telefon: +1 866 273-6255 Fax: +1 217 453-9956 e-mail: sales@bsdmall.com WWW:
FreeBSD Mall, Inc. 3623 Sanford Street Concord, CA 94520-1405 Egyesült Államok Telefon: +1 925 240-6652 Fax: +1 925 674-0821 e-mail: info@freebsdmall.com WWW:
Dr. Hinner EDV St. Augustinus-Str. 10 D-81825 München Németország Telefon: (089) 428 419 WWW:
Ikarios 22-24 rue Voltaire 92000 Nanterre Franciaország WWW:
JMC Software Írország Telefon: 353 1 6291282 WWW:
The Linux Emporium Hilliard House, Lester Way Wallingford OX10 9TA Egyesült Királyság Telefon: +44 1491 837010 Fax: +44 1491 837016 WWW:
Linux+ DVD Magazine Lewartowskiego 6 Warsaw 00-190 Lengyelország Telefon: +48 22 860 18 18 e-mail: editors@lpmagazine.org WWW:
Linux System Labs Australia 21 Ray Drive Balwyn North VIC - 3104 Ausztrália Telefon: +61 3 9857 5918 Fax: +61 3 9857 8974 WWW:
LinuxCenter.Ru Galernaya utca, 55 Szentpétervár 190000 Oroszország Telefon: +7-812-3125208 e-mail: info@linuxcenter.ru WWW:
Terjesztõk Ha viszonteladók vagyunk és szeretnénk CD-s &os; termékeket forgalmazni, akkor az alábbi terjesztõk valamelyikével vegyük fel a kapcsolatot:
Cylogistics 809B Cuesta Dr., #2149 Mountain View, CA 94040 Egyesült Államok Telefon: +1 650 694-4949 Fax: +1 650 694-4953 e-mail: sales@cylogistics.com WWW:
Ingram Micro 1600 E. St. Andrew Place Santa Ana, CA 92705-4926 Egyesült Államok Telefon: 1 (800) 456-8000 WWW:
Kudzu, LLC 7375 Washington Ave. S. Edina, MN 55439 Egyesült Államok Telefon: +1 952 947-0822 Fax: +1 952 947-0876 e-mail: sales@kudzuenterprises.com
LinuxCenter.Ru Galernaya utca, 55 Szentpétervár 190000 Oroszország Telefon: +7-812-3125208 e-mail: info@linuxcenter.ru WWW:
Navarre Corp 7400 49th Ave South New Hope, MN 55428 Egyesült Államok Telefon: +1 763 535-8333 Fax: +1 763 535-0341 WWW:
FTP oldalak A &os; hivatalos forrásai anonim FTP-n keresztül is elérhetõek különféle tükrözésekrõl. Az oldal ugyan jó minõségû kapcsolattal rendelkezik és rengeteg felhasználót is enged egyidejûleg kapcsolódni, azonban valószínûleg jobban járunk, ha egy hozzánk közelebbi tükrözést választunk (különösen abban az esetben, amikor mi magunk is egy tükrözést akarunk készíteni). A &os; tükrözések adatbázisában az itt megtalálhatónál sokkal pontosabb leltárt kaphatunk az elérhetõ tükrözésekrõl, mivel közvetlenül a névfeloldás segítségével állapítja meg a szükséges adatokat és nem egy rögzített listát tárol. Emellett az alábbi tükrözésekrõl a &os; elérhetõ anonim FTP-n keresztül is. Amennyiben az anonim FTP használata mellett döntenénk, igyekezzünk a hozzánk legközelebb levõ szervert használni. Az Elsõdleges tükrözésekként feltüntetett oldalak általában a teljes &os; archívumot tartalmazzák (az összes jelenleg elérhetõ változatot az összes architektúrára), de a környékünkön vagy országunkban elhelyezkedõ tükörszerverekrõl többnyire gyorsabban tudunk majd letölteni. A regionális oldalakon gyakorta csak a népszerûbb architektúrákon futó népszerûbb változatokat találjuk meg, nem a teljes &os; archívumot. Minden szerver elérhetõ anonim FTP-vel, de közülük néhány még további más módszereket is támogat. Az egyes oldalak által ismert konkrét módszereket a nevük után zárójelben közüljük. &chap.mirrors.ftp.inc; Anonim CVS <anchor id="anoncvs-intro">Bevezetés CVS anonim Az anonim CVS (vagy más néven anoncvs) a &os;-hez mellékelt CVS-es segédprogramok által nyújtott olyan lehetõség, amivel távoli CVS repositorykkal tudunk szinkronizálni. Több más dolog mellett lehetõvé teszi a &os; felhasználói számára, hogy kiemelt jogosultságok nélkül képesek legyenek olvasással kapcsolatos CVS mûveleteket végrehajtani a &os; Projekt hivatalos anoncvs szerverein. A használatához egyszerûen csak a kiválasztott anoncvs szervert kell beállítani a CVSROOT környezeti változó értékének, ahol aztán a cvs login parancsnak a szerver által ismert anoncvs jelszót kell megadni. Ezután a &man.cvs.1; paranccsal a többi CVS szerverhez hasonlóan lehetõségünk nyílik hozzáférni. A cvs login parancs a bejelentkezésekhez szükséges jelszavakat a HOME könyvtárunkban levõ .cvspass állományban tárolja. Ha ez az állomány nem létezik, akkor a cvs login elsõ használatakor hibát kapunk. Ilyenkor csak hozzunk létre egy üres .cvspass állományt, majd próbálkozzunk újra. Habár azt mondhatnánk, hogy a CVSup és az anoncvs lényegében egyazon feladatot oldják meg, mind a két esetben léteznek olyan kompromisszumok, amelyek befolyásolhatják a felhasználó választását a két szinkronizációs módszer között. Dióhéjban ezt úgy tudnánk összefoglalni, hogy a CVSup a hálózati erõforrásokat hatékonyabban kihasználja és kettejük közül ez a fejlettebb, azonban ennek meg kell fizetnünk az árát. A CVSup használatához elõször ugyanis telepítenünk kell és be kell állítanunk egy speciális klienst, illetve az adatokat a CVSup által gyûjteményeknek (collection) nevezett, viszonylag nagy méretû egyeségekben érhetjük el. Ezzel szemben az anoncvs használata során a megfelelõ CVS modul nevének felhasználásával tetszõlegesen megvizsgálhatunk önálló állományokat vagy akár programokat (mint az ls vagy a grep). Természetesen az anoncvs segítségével csupán az olvasást igénylõ CVS mûveleteket végezhetjük el, ezért ha a &os; Projekt keretein belül fejleszteni is szeretnénk, akkor inkább érdemes a CVSup alkalmazást választani. <anchor id="anoncvs-usage">Az anonim CVS használata A &man.cvs.1; parancsot nagyon könnyû beállítani az anonim CVS repositoryk használatához, hiszen mindössze annyit kell tennünk, hogy a CVSROOT környezeti változó értékének megadjuk a &os; Projekt valamelyik anoncvs szerverét. Ezen sorok írásának pillanatában a következõ szerverek érhetõek el: Franciaország: :pserver:anoncvs@anoncvs.fr.FreeBSD.org:/home/ncvs (pserver (a jelszó anoncvs), ssh (nincs jelszó)) Japán: :pserver:anoncvs@anoncvs.jp.FreeBSD.org:/home/ncvs (a cvs login használatánál a jelszó anoncvs.) Tajvan: :pserver:anoncvs@anoncvs.tw.FreeBSD.org:/home/ncvs (pserver (a cvs login használatával tetszõleges jelszó megadható), ssh (nincs jelszó)) SSH2 HostKey: 1024 e8:3b:29:7b:ca:9f:ac:e9:45:cb:c8:17:ae:9b:eb:55 /etc/ssh/ssh_host_dsa_key.pub Egyesült Államok: freebsdanoncvs@anoncvs.FreeBSD.org:/home/ncvs (csak ssh — nincs jelszó) SSH HostKey: 1024 a1:e7:46:de:fb:56:ef:05:bc:73:aa:91:09:da:f7:f4 root@sanmateo.ecn.purdue.edu SSH2 HostKey: 1024 52:02:38:1a:2f:a8:71:d3:f5:83:93:8d:aa:00:6f:65 ssh_host_dsa_key.pub Egyesült Államok: anoncvs@anoncvs1.FreeBSD.org:/home/ncvs (csak ssh2 — nincs jelszó) SSH2 HostKey: 2048 53:1f:15:a3:72:5c:43:f6:44:0e:6a:e9:bb:f8:01:62 /etc/ssh/ssh_host_dsa_key.pub Mivel a CVS használatával kikérhetjük (check out) tulajdonképpen a &os; forrásainak akármelyik eddigi (vagy majd ezután keletkezõ) változatát, érdemes megismerkednünk a &man.cvs.1; által alkalmazott revízió (revision) (az opcióval állítható) fogalmával és a &os; Projekt repositoryjain belül engedélyezett értékeivel. Címkéket (tag) két esetben használhatunk: a revíziók és az ágak esetén. A revíziós címkék mindig egy adott revízióra hivatkoznak, ami állandóan ugyanazt jelenti. Ezzel szemben az ágak címkéi a fejlesztés adott irányú menetének az adott pillanatban legfrissebb revízióját hivatkozzák. Mivel az ágak címkéi nem egy adott revízióra vonatkoznak, ezért elmondhatjuk róluk, hogy naponta változik a jelentésük. Az tartalmazza a felhasználók számára fontos revíziós címkéket. Ezek azonban nem igazak a Portgyûjteményre, mivel a Portgyûjteménynek nincs egyszerre több fejlesztési iránya. Egy ág címkéjének megadásával általában az adott irányhoz tartozó állományok legfrissebb változatát kapjuk meg. Ha viszont az állományok egy korábbi változatára lenne szükségünk, akkor a opció megadásával meg tudjuk adni annak idõpontját. Errõl részletesebben a &man.cvs.1; man oldalán olvashatunk. Példák Habár a továbbhaladáshoz mindenképpen javasoljuk a &man.cvs.1; man oldalának részletes áttanulmányozását, mutatunk néhány gyors példát az anonim CVS használatának tömör illusztrálására: Valami (az &man.ls.1;) kikérése a -CURRENT ágból &prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.tw.FreeBSD.org:/home/ncvs &prompt.user; cvs login Jelszóként ezután bármit megadhatunk. &prompt.user; cvs co ls Az <filename>src/</filename> fa kikérése SSH-n keresztül &prompt.user; cvs -d freebsdanoncvs@anoncvs.FreeBSD.org:/home/ncvs co src The authenticity of host 'anoncvs.freebsd.org (128.46.156.46)' can't be established. DSA key fingerprint is 52:02:38:1a:2f:a8:71:d3:f5:83:93:8d:aa:00:6f:65. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'anoncvs.freebsd.org' (DSA) to the list of known hosts. Az &man.ls.1; 6-STABLE ágban szereplõ változatának kikérése &prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.tw.FreeBSD.org:/home/ncvs &prompt.user; cvs login Amikor kéri, jelszóként bármit megadhatunk. &prompt.user; cvs co -rRELENG_6 ls Az &man.ls.1; változásainak (Unified Diff formátumú) listázása &prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.tw.FreeBSD.org:/home/ncvs &prompt.user; cvs login Itt jelszóként bármit megadhatunk. &prompt.user; cvs rdiff -u -rRELENG_5_3_0_RELEASE -rRELENG_5_4_0_RELEASE ls A használható modulok nevének kiderítése &prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.tw.FreeBSD.org:/home/ncvs &prompt.user; cvs login Ezután jelszóként bármit megadhatunk. &prompt.user; cvs co modules &prompt.user; more modules/modules Egyéb helyek A következõ helyeken találhatunk még hasznos információkat a CVS használatáról: A CVS bemutatása (írta: Cal Poly). A CVS honlapja, a CVS fejlesztésével és alkalmazásával foglalkozó közösség oldala. A CVSweb a &os; Projekt által használt CVS rendszerének webes felülete. A CTM használata CTM A CTM használatáva a távoli könyvtárakat tudunk egy központi változattal szinkronban tartani. Eredetileg a &os; forrásaihoz fejlesztették ki, de idõvel mások más célokra is alkalmasnak találhatják majd. Az eltérések (delták) feldolgozásával kapcsolatban kevéske dokumentáció áll rendelkezésre, ezért a &a.ctm-users.name; levelezési listát érdemes felkeresni, ha többet szeretnénk megtudni a CTM egyéb célú alkalmazásairól. Miért használnánk a <application>CTM</application>-et? A CTM segítségével a &os; forrásainak helyi másolatát hozhatjuk létre. A források több különbözõ kivitelben is hozzáférhetõek. A CTM minden esetben képes eleget tenni az igényeinknek, akár az egész CVS fát, akár annak egy részét kívánjuk csak figyelemmel követni. Ha netalán &os; fejlesztõk lennénk, és híján vagyunk vagy éppen gyenge TCP/IP kapcsolattal rendelkezünk, esetleg egyszerûen csak automatikusan értesülni szeretnénk a változásokról, a CTM-et nekünk találták ki. A leggyorsabban fejlõdõ ágakból is naponta legfeljebb három deltát fogunk kapni, azonban érdemes megfontolni a változások automatikus elküldését levélben. A szükséges frissítések méretét mindig igyekszünk minimalizálni. Ez egyébként általában alig 5 KB, de néha (tízbõl egyszer) elõfordul, hogy 10 és 50 KB között van, és idõnként 100 KB vagy afeletti mennyiségû frissítés is érkezhet. Amikor a fejlesztõk által használt forrásokat töltjük le, magunknak kell gondoskodnunk a menet közben felmerülõ különbözõ problémák megoldásáról. Ez kiváltképp igaz abban az esetben, amikor az aktuális, vagy hivatalos nevén CURRENT ágat követjük. Mielõtt azonban egy ilyenbe belevágnánk, érdemes fellapozni a &os; legfrissebb változatának használatáról szóló fejezetet. Mire van szükségünk a <application>CTM</application> használatához? A mûködéshez két komponens szükségeltetik: a CTM kliensprogramja és hozzá a kezdeti delták (amivel majd letöltjük a CURRENT forrásait). A CTM program már a 2.0 kiadástól kezdve a &os; része, és a források között a /usr/src/usr.sbin/ctm könyvtárban találjuk meg (amennyiben felraktuk). A CTM mûködéséhez kellõ deltákat két módon, FTP-n vagy e-mailen keresztül szerezhetjük be. Ha el tudunk érni interneten levõ FTP oldalakat, akkor az alábbi FTP helyeken találunk a CTM-hez használható adatokat: valamint lásd a tükrözéseket. FTP-n keresztül lépjünk be a könyvtárba, töltsük le a README nevû állományt és kövessük a benne szereplõ utasításokat. Ha viszont e-mailen keresztül akarjuk megszerezni a deltákat: Iratkozzunk fel a CTM terjesztési listáinak egyikére. A &a.ctm-cvs-cur.name; lista az egész CVS-fát, míg a &a.ctm-src-cur.name; a fõ fejlesztési ágat teszi elérhetõvé. A &a.ctm-src-4.name; a 4.X kiadásaihoz ágakat tartalmazza, és így tovább. (Ha nem tudjuk, hogyan kell feliratkozni egy levelezési listára, akkor kattintsunk a lista nevére vagy kövessük a &a.mailman.lists.link; linket, majd kattintsunk arra a listára, ahova fel akarunk iratkozni. Ezen az oldalon az összes, a feliratkozáshoz nélkülözhetetlen információnak szerepelnie kell.) Miután elkezdenek megérkezni a CTM-frissítéseket tartalmazó levelek, a tartalmukat a ctm_rmail programmal tudjuk kicsomagolni és felhasználni. Az /etc/aliases állományba akár közvetlenül is beírhatjuk a ctm_rmail programot, és ezzel a önállósítani tudjuk a levélben érkezõ frissítések feldolgozását. A ctm_rmail man oldalán olvashatjuk ennek részleteit. Nem számít, milyen módon jutunk hozzá a CTM által használt deltákhoz, minden esetben fel kell iratkoznunk a &a.ctm-announce.name; levelezési listára. Az elkövetkezendõkben ez lesz az egyetlen hely, ahová a CTM rendszer mûködtetésével kapcsolatos bejelentések beküldésre kerülnek. A feliratkozáshoz kattinsunk a fenti lista nevére és kövessük a mellette szereplõ utasításokat. A <application>CTM</application> elsõ használata Mielõtt nekilátnánk a CTM-hez tartozó delták használatának, elõször el kell jutnunk egy kiindulási ponthoz, ahonnan majd létre tudjuk hozni a rákövetkezõ deltákat. Ehhez elsõként vegyük számba, pontosan mink is van. Általában mindenki egy üres könyvtárral kezd. Ilyenkor egy kezdeti Empty (mint üres) elnevezésû deltával tudjuk megkezdeni az CTM által ismert fa szinkronizálását. Erre a célra lesznek majd szintén alkalmasak a megkezdett delták is, amelyek valamikor a CD-re fognak felkerülni. Mivel a fák maguk több tíz megabyte-nyi méretûek, ezért érdemes inkább valami kéznél levõ eszközzel megkezdeni a folyamatot. Ha van -RELEASE verziójú CD-nk, akkor másoljuk le róla és bontsuk ki a kiindulásként használt forrásokat. Ezzel jelentõs mennyiségû adat átvitelét takaríthatjuk meg. A kezdõ deltákat könnyen megismerjük a szám után X karakterrel leválasztott nevükrõl (például src-cur.3210XEmpty.gz). Az X után szereplõ megnevezés a kezdeti kiindulás (seed) fokának felel meg. Az Empty egy üres könyvtárra utal. A szabályok szerint az Empty állapotból 100 deltánként jön létre újabb (kiindulásra alkalmas) alapváltozat. Ezek azonban nagyon nagyok is lehetnek. A 70 vagy 80 megabyte-os gzippel csomagolt adatok gyakoriak az XEmpty delták esetén. Miután kiválasztottuk a számunkra megfelelõ alapváltozatot, szükségünk lesz a tõle nagyobb sorszámú összes deltára is. A <application>CTM</application> használata a hétköznapokban A delták felhasználásához egyszerûen csak ennyit kell tennünk: &prompt.root; cd /ahol/tárolni/akarjuk/az/adatokat &prompt.root; ctm -v -v /ahol/tároljuk/a/deltákat/src-xxx.* A CTM képes értelmezni a gzip által csomagolt adatokat, ezért nincs szükség a delták elõzetes kitömörítésére, amivel tárhelyet tudunk spórolni. Hacsak nem tekinti tökéletesen biztonságosnak az egész folyamatot, akkor a CTM nem fog módosítani a fán. A deltákat a CTM kapcsolójával is ellenõrizhetjük, aminek során egyáltalán nem fog módosulni a forrásfa. Ekkor egyszerûen csak ellenõrzi a delták sértetlenségét és megnézi, hogy minden rendben zajlana-e az alkalmazásuk során. A CTM-nek vannak még további kapcsolói is, melyekrõl bõvebben a man oldalakból és a forráskódokból tájékozódhatunk. Most már minden megvan, ami kellhet. Amikor kapunk egy újabb deltát, a forrásaink frissítéséhez csak futtassuk át a CTM-en. Ne töröljük le azokat a deltákat, melyeket nehezen tudtunk letölteni. Helyette érdemes inkább megtartani ezeket arra az esetre, ha valami rossz történne. Még ha csak floppylemezek is állnak rendelkezésünkre, mindenképpen másoljuk le ezeket az fdwrite paranccsal. A saját változtatásaink megtartása Fejlesztõként biztosan szeretnénk kísérletezni és állományokat megváltoztatni a forrásfában. A CTM a helyben elkövetett változtatásokat csak korlátozottan támogatja: az ize nevû állomány meglétének vizsgálata elõtt az ize.ctm állományt fogja keresni. Ha létezik, akkor a CTM az ize helyett ezen fog dolgozni. Ezzel a viselkedéssel nyerjük a saját változtatásaink megtartásának egyszerû módját: csak másoljuk le .ctm kiterjesztéssel a módosítani tervezett állományokat. Ezután már szabadon módosíthatjuk a forrásokat, miközben a CTM a .ctm kiterjesztésû állományokat folyamatosan szinkronban tartja. A <application>CTM</application> egyéb érdekes beállításai Derítsük ki pontosan miket is fog érinteni a frissítés A CTM által a forrásokon elvégzendõ változtatások listáját az kapcsolóval kérdezhetjük le. Ez akkor esik kézre, ha szeretnénk feljegyezni a bekövetkezõ változásokat, vagy bármilyen módon elõ- vagy utófeldolgozni a módosított állományokat, esetleg szimplán elõvigyázatosak akarunk lenni. Biztonsági másolat készítése a frissítés elõtt Néha egyszerûen csak szeretnénk az összes érintett állományról biztonsági másolatot készíteni a CTM által elvégzett frissítés elõtt. A beállítás megadásával az adott CTM delta által módosítandó összes állomány tárolásra kerül a mentés-állomány nevû állományba. A frissíthetõ állományok korlátozása Egyes esetekben érdekünkben állhat leszûkíteni a CTM által eszközölt frissítések hatáskörét, vagy egyszerûen csak néhány állomány szinkronizálására van szükségünk. A CTM számára feldolgozható állományok listáját reguláris kifejezés formájában az és opciók mentén határozhatjuk meg. Például ha a lib/libc/Makefile állomány az összegyûjtött CTM delták szerinti legfrissebb verziójához kívánunk hozzájutni, akkor futtassuk az alábbi parancsot: &prompt.root; cd /akarhova/ahova/ki/akarjuk/bontani/ &prompt.root; ctm -e '^lib/libc/Makefile' ~ctm/src-xxx.* A CTM deltákban megadott minden egyes állomány esetén az az opciók a parancssorban történt megadásuk sorrendjében kerülnek feldolgozásra. Egy állományt kizárólag csak akkor dolgoz fel a CTM, ha az az és opciók kiértékelése után is indokolt. További tervek a <application>CTM</application>-mel kapcsolatban Rengeteg van: Valamiféle hitelesítés bevezetése a CTM rendszerbe, amivel észlelhetõek a meghamisított CTM-frissítések. A CTM beállításainak letisztázása, mivel eléggé megtévesztõek és nehézkesen használhatóak. Egyebek Léteznek delták a portok gyûjteményéhez is, azonban még nem mutatkozott túlzottan nagy érdeklõdés irántuk. CTM tükrözések A CTM/FreeBSD anonim FTP-n keresztül elérhetõ az alábbi tüköroldalak valamelyikérõl. Amennyiben ezen a módon kívánjuk letölteni a CTM rendszerhez tartozó állományokat, elõször próbálkozzunk a hozzánk legközelebb levõ szerverrel. Ha bármilyen gond merülne fel, értesítsük a &a.ctm-users.name; levelezési listát. Kalifornia, Bay Area (hivatalos forrás) Dél-Afrika (a korábbi delták biztonsági másolatai) Tajvan/R.O.C. Ha nem találtunk volna hozzánk közel esõ tükrözést, vagy ha talált tükör nem elég friss, akkor próbálkozzunk egy olyan keresõmotor használatával, mint például az alltheweb. A CVSup használata Bevezetés A CVSup távoli szervereken található központi repositorykban levõ forrásfák terjesztésére és a rajtuk keresztüli frissítésre alkalmas programcsomag. A &os; forrásait egy CVS repositoryban tartják karban Kaliforniában egy fejlesztéseket tároló központi számítógépen. A CVSup segítségével a &os; felhasználói könnyen szinkronban tudják vele tartani a saját forrásaikat. A CVSup az ún. lehúzással frissít. Ilyenkor a kliensek csak akkor kérnek a szervertõl frissítéseket, amikor szükségük van rá, miközben a szerver passzívan várja a frissítési kérelmeket. Ennek megfelelõen tehát minden esetben a kliens kezdeményezi a frissítést, a szerver pedig önmagától sosem küld ilyeneket kéretlenül. A felhasználóknak így vagy maguknak kell meghívniuk a CVSup kliensét, vagy a frissítések rendszeres automatikus letöltéséhez be kell állítaniuk a cron rendszerprogramot. A CVSup kifejezés ebben az írásmódban az egész programcsomagra utal. Fõ alkotórészei a a felhasználó gépén futó cvsup nevû kliens, és a &os; tüköroldalain futó cvsupd nevû szerver. A &os; dokumentációjának és levelezési listáinak fürkészése során rengeteg hivatkozást találhatunk egy sup nevû alkalmazásra. A sup a CVSup elõdje volt, és hasonló célokat szolgált. A CVSup használat tekintetében nagyon hasonlít a sup-hoz, és ami azt illeti, a a sup konfigurációs állományaival visszafele kompatibilis formátumot használ. Mivel a CVSup sokkal gyorsabb és rugalmasabb, a supot már nem használja a &os; Projekt. A csup a CVSup C nyelven újraírt változata. Legnagyobb elõnye, hogy gyorsabb és nincs szüksége a Modula-3 nyelv futtató környezetére, ezért azt nem kell a használatához telepíteni. Ráadásul, ha a &os; 6.2 vagy annál késõbbi változatát használjuk, akkor minden további nélkül a rendelkezésünkre áll, hiszen az alaprendszer része. A &os; korábbi verzióinak alaprendszerei ugyan nem tartalmazzák a &man.csup.1; parancsot, viszont a net/csup port vagy csomag segítségével pillanatok alatt telepíteni tudjuk. Emellett a csup segédprogram nem támogatja a CVS módot sem. Teljes repositoryk tükrözéséhez ezért továbbra is a CVSup kell használnunk. Amennyiben a csup mellett tennénk le a voksunkat, a szakasz fennmaradó részében egyszerûen hagyjuk ki a CVSup telepítésérõl szóló lépéseket és a CVSup hivatkozásait helyettesítsük a csup programmal. Telepítés A CVSup telepítésének legegyszerûbb módja a &os; csomaggyûjteményében található elõrefordított net/cvsup csomag használata. Ha viszont inkább forrásból akarjuk telepíteni a CVSupot, akkor helyette használjuk a net/cvsup portot. De legyünk elõvigyázatosak: a net/cvsup portnak szüksége van a Modula-3 rendszerre, aminek letöltése és lefordítása pedig meglehetõsen sok idõt és tárhelyet igényel. Ha olyan gépen akarjuk használni a CVSupot, ahol nincs &xfree86;, &xorg; vagy bármilyen más ilyen szerver, akkor használjuk a net/cvsup-without-gui portot, ami nem tartalmazza a hozzátartozó grafikus felületet. Ha a &os; 6.1 vagy korábbi változatain szeretnénk telepíteni a csupot, használjuk a &os; csomaggyûjteményében megtalálható net/csup csomagot. Ha viszont forrásból kívánjuk telepíteni a csup programot, akkor helyette használjuk a net/csup portot. A CVSup beállítása A CVSup mûködését a supfile elnevezésû állomány vezérli. A /usr/share/examples/cvsup/ könyvárban találhatunk néhány példát a supfile állományokra. A supfile állományban szereplõ információk a CVSup használatával kapcsolatban a következõ kérdéseket válaszolják meg: Milyen állományokat akarunk letölteni? Milyen verzióikra van szükségünk? Honnan akarjuk ezeket beszerezni? Hova akarjuk rakni a számítógépünkön? Hova akarjuk rakni az állapotot tároló állományokat? Az imént feltett kérdésekre a következõ szakaszokban összeállítandó supfile segítségével fogunk válaszolni. Ehhez elõször bemutatjuk a supfile formátumú állományok általános szerkezetét. A supfile állományok szöveget tartalmaznak. A megjegyzések # karakterrel kezdõdnek és a sor végéig tartanak. A kizárólag csak megjegyzéseket tartalmazó vagy üres sorok nem kerülnek feldolgozásra. Az összes többi fennmaradó sorban pedig azokat az állományokat írjuk le, amelyeket a felhasználó le akar tölteni. Az ilyen fajtájú sorok egy gyûjtemény (collection) nevével kezdõdnek, ami állományok egy szerver által meghatározott logikai csoportjára utal. A gyûjtemény neve ennek megfelelõen elárulja a szervernek, hogy pontosan milyen állományokra van szükségünk. Ezután következik whitespace-szel elválasztva nulla vagy több mezõ, amelyek a korábban feltett kérdéseinket válaszolják meg rendre. Ezeknek a mezõknek két típusa létezik: a beállításokat és a konkrét értéket tároló mezõk. A beállításokat tároló mezõk különbözõ kulcsszavakat tartalmaznak, például a delete (törlés) vagy compress (tömörítés). Az értéket tároló mezõk is egy kulcsszóval kezdõdnek, azonban utána közvetlenül egy = (egyenlõségjel) jön, amelyet egy második szó követ szorosan. Így például a release=cvs pontosan egy ilyen értékmezõ lesz. Egy supfile általában egynél több gyûjtemény letöltését írja le. Ezért az ilyen állományok felépítésének egyik módja, ha az egyes gyûjteményhez explicite megadjuk a hozzátartozó mezõket. Azonban így a supfile állományok gyorsan megnövekednek és kényelmetlenné válnak, mivel a legtöbb gyûjtemény esetén szinte ugyanazokat a mezõket kellene megadnunk. A CVSup az ilyen típusú bonyodalmak elkerülésére egy alapértelmezési megoldást javasol. A *default nevû álgyûjteménnyel kezdõdõ sorok segítségével meg tudunk adni olyan beállításokat és értékeket, amelyek az utána következõ gyûjtemények számára alapértelmezésnek fognak számítani a supfile állományban. Az itt megadott alapértelmezések természetesen az egyes gyûjteményekben tetszõleges módon felülbírálhatóak, a mezõk magán a gyûjteményen belüli megadásával. Az állományban az alapértelmezések is megváltoztathatóak vagy bõvíthetõek további *default sorok hozzáadásával. Mindezek tudatában most már megkezdhetjük a FreeBSD-CURRENT ág tartalmának letöltésére és frissen tartására alkalmas supfile állomány összeállítását. Milyen állományokat akarunk letölteni? A CVSupon keresztül elérhetõ állományok gyûjteményeknek hívott nevesített csoportokra bontva érhetõek el. A hivatkozható gyûjtemények leírását a következõ szakaszban találjuk. Ebben a példában most szeretnénk letölteni az egész &os; rendszer forrását. Ezt a src-all nevû gyûjteményre hivatkozva érhetjük el. A supfile állományunk létrehozásának elsõ lépéseként soronként egyet megadva felsoroljuk a letölteni kívánt gyûjteményeket (jelen esetünkben csak egyetlen egyet): src-all Milyen verzióikra van szükségünk? A CVSup használatával tulajdonképpen a források összes valaha létezett verziójához hozzá tudunk férni. Ez annak köszönhetõ, hogy a cvsupd szerver közvetlenül a CVS repositoryból dolgozik, ami pedig az összes verziót tartalmazza. A tag= és date= értékmezõk segítségével adhatjuk meg az igényelt verziókat. Legyünk óvatosak azonban a tag= mezõk helyes megadásával. Egyes címkék ugyanis csak bizonyos állománygyûjtemények esetén élnek. Ha hibás vagy elírt címkét adunk meg, akkor a CVSup törölni fog olyan állományokat, amelyeket valószínûleg nem kellene. A ports-* gyûjtemények esetében pedig kifejezetten csak a tag=. mezõk használhatóak! A tag= mezõk a tárházban található szimbolikus címkéket nevezik meg. A címkéknek két típusa van: a revíziókhoz és az ágakhoz tartozó címkék. A revíziós címkék mindig egy adott revíziót hivatkoznak, jelentésük állandó. Ezzel szemben az ágak címkéi egy adott fejlesztési ág adott idõpontjában elérhetõ revíziót címkézi. Mivel az ágak címkéi nem egy konkrét revízióra vonatkoznak, ezért akár olyanra is utalhatnak, ami pillanatnyilag még nem is létezik. Az ban megtalálhatjuk a fontosabb ágak címkéit. A CVSup konfigurációs állományában a címkéket a tag= elõtaggal kell bevezetni (így tehát a RELENG_4 címke hivatkozása tag=RELENG_4 lesz). Ne felejtsük el, hogy a Portgyûjtemény esetében csak tag=. mezõ megadásának van értelme. Igyekezzünk pontosan lemásolni a címkék neveit, mivel a CVSup nem képes megkülönböztetni az érvényes és az érvénytelen címkéket. Ha véletlen elírjuk a címkét, akkor a CVSup úgy fog viselkedni, mintha olyan érvényes címkére hivatkozhatunk volna, amihez nem tartoznak állományok. Ennek következtében pedig egyszerûen letörli a már meglevõ forrásainkat. Egy ág címkéjének megadása során általában az adott fejlesztési vonal legfrissebb verzióját kapjuk meg. Ha viszont az adott ág valamelyik korábbi változatára lenne szükségünk, akkor a értékmezõ felhasználásával meg tudjuk adni a hozzátartozó dátumot. Ennek mûködésérõl a &man.cvsup.1; man oldala részletesebben értekezik. A példában mi most a &os;-CURRENT verziót akarjuk letölteni. Ezért a következõ sort tesszük a supfile állományunk elejére: *default tag=. Ha nem adunk meg sem tag=, sem pedig date= mezõket, akkor egy fontos eset következik be. Ilyenkor ugyanis egy konkrét verzió helyett közvetlenül a szerver CVS repositoryjából kapjuk meg az állományokat, az összes kiegészítõ információjukkal együtt. A fejlesztõk általában ezt a típusú megoldást kedvelik, mivel így a saját rendszerükön is könnyen karban tudnak tartani egy példányt, amiben tudnak keresni a revíziók között és ki tudják kérni akár az állományok korábbi változatait is. Természetesen ennek függvényében jóval több tárhelyre van szükségük. Honnan akarjuk ezeket beszerezni? A host= mezõ beállításával közöljük a cvsup klienssel, honnan töltse le a frissítéseket. A CVSup tükrözések közül bármelyik megfelel erre a célra, habár leginkább azt érdemes választani, ami a kibertérben a hozzánk legközelebb esik. A példában most egy kitalált &os; terjesztési oldalt választunk, a cvsup99.FreeBSD.org-ot: *default host=cvsup99.FreeBSD.org A CVSup futtatása elõtt tehát ne felejtsük el megváltoztatni ezt a létezõ számítógép hálózati nevére. A cvsup futtatásakor a opció megadásával lehetõségünk ennek felülbírálására. Hova akarjuk rakni a számítógépünkön? A prefix= mezõ adja meg a cvsup számára, hogy hova tegye a kapott állományokat. A példában a forrásokat közvetlenül a forrásokat tároló központi könyvtárba, a /usr/src könyvtárba tettük. Mivel a src könyvtár neve már hallgatólagosan benne foglaltatik a letöltésre kiválasztott gyûjtemény nevében, ezért itt csak ennyit kell megadnunk: *default prefix=/usr Hova akarjuk rakni az állapotot tároló állományokat? A CVSup kliens egy bázisnak (base) nevezett könyvtárban folyamatosan fenntart bizonyos állományokban állapotokat (status file). Ezek a már letöltött állományok nyilvántartásával segítik a CVSup hatékony munkavégzését. Mi most a szabványos bázist, a /var/db könyvtárat fogjuk használni: *default base=/var/db Amennyiben még nem létezne a bázisként használni kívánt könyvtár, ideje létrehoznunk. A cvsup ugyanis egy nem létezõ könyvtár esetén nem lesz hajlandó mûködni. További beállítások a supfile állományban: Általában még egy sor szokott szerepelni a supfile állományokban: *default release=cvs delete use-rel-suffix compress A release=cvs mezõ jelzi, hogy a szervernek a &os; fõ CVS repositoryból kell kikeresnie az információkat. Tulajdonképpen majdnem mindig errõl van szó, és az itt megadható többi lehetõség ismertetése most egyébként is meghaladná a szakasz határait. A delete hatására a CVSup képes lesz állományokat törölni. Mindig érdemes megadnunk, hiszen a CVSup csak így tudja teljes mértékben frissentartani a forrásokat. A CVSup természetesen csak azokat az állományokat igyekszik letörölni, amelyek miatt valóban felelõs. A kóbor állományokat nem fogja bántani. A use-rel-suffix hatása egy igazi... Rejtély. Ha tényleg érdekel minket a mûködése, lapozzuk fel bátran a &man.cvsup.1; man oldalát. Nyugodtan adjuk meg és különösebben ne törõdjünk vele. A compress beállítás segítségével a kommunikációs csatornán vándorló adatokat tudjuk gzip-szerû módon tömöríteni. Ha a hálózati kapcsolatunk sebessége meghaladja a 1,5 Mbitet másodpercenként (T1), akkor ezt már nem érdemes használni, viszont minden más esetben lényeges gyorsulást hozhat. Összegezzük az eddigieket: Íme a példaként összerakott supfile állományunk teljes tartalma: *default tag=. *default host=cvsup99.FreeBSD.org *default prefix=/usr *default base=/var/db *default release=cvs delete use-rel-suffix compress src-all A <filename>refuse</filename> állomány Ahogy arról már korábban szó esett, a CVSup lehúzással frissít. Ez alapvetõen annyit jelent, hogy feltárcsázunk egy CVSup szervert, aki a következõt mondja nekünk: A következõket tudod tõlem letölteni..., amire a kliensünk ezt válaszolja: Rendben, akkor nekem kell ez, ez, ez meg ez. Alapértelmezés szerint a CVSup kliense azokat az állományokat fogja letölteni, amelyeket a konfigurációs állományban szereplõ gyûjtemények és címkék által megneveztünk. Ez azonban nem mindig felel meg az igényeinknek, különösen akkor, amikor a doc, ports vagy www fákat akarjuk letölteni — az emberek többsége ugyanis nem beszél négy vagy öt nyelven, ezért nincs is szükségük a nyelvfüggõ állományok letöltésére. A Portgyûjtemény letöltése során a ports-all helyett egyszerûen egyenként is felsorolhatjuk a számunkra érdekes kategóriákat (például ports-astrology, ports-biology stb). Azonban mivel a doc és a www fákhoz nincsenek nyelvfüggõ gyûjtemények, ezért elõ kell halásznunk a CVSup egyik remek funkcióját, a refuse állományt. A refuse állománnyal lényegében arra utasítjuk a CVSup alkalmazást, hogy a gyûjteményekbõl ne töltse le az összes állományt. Úgy is fogalmazhatnánk, hogy javaslatára a kliens visszautasít (refuse) bizonyos szervertõl érkezõ állományokat. Ezeket a visszautasításokat tároló refuse állományt a bázis/sup/ könyvtárban találhatjuk meg (illetve ha még nincsenek, akkor ide kell rakunk ezeket). Itt a bázis a supfile állományban megadott base= mezõre utal, ami a példánkban a /var/db könyvtár volt. Ennek megfelelõen tehát a refuse állomány a /var/db/sup/refuse lesz. A refuse állomány felépítése igen egyszerû: a letölteni nem kívánt állományok és könyvtárak neveit tartalmazza. Például ha az angolul mellett esetleg még beszélünk egy kevés németet is, de nincs szükségünk az angol dokumentáció német fordítására sem, akkor a következõket írjuk a refuse állományba: doc/bn_* doc/da_* doc/de_* doc/el_* doc/es_* doc/fr_* doc/hu_* doc/it_* doc/ja_* doc/mn_* doc/nl_* doc/no_* doc/pl_* doc/pt_* doc/ru_* doc/sr_* doc/tr_* doc/zh_* és így tovább a többi nyelvre is (melyeket a &os; CVS repository böngészésével deríthetjük ki). Ezzel az alkalmas funkcióval a lassú vagy drága internetes kapcsolattal rendelkezõ felhasználók nagyon jól tudnak gazdálkodni, mivel így nem kell letölteniük az egyáltalán nem használt állományokat. A refuse állományokról és a CVSup más hasonlóan elegáns funkcióiról a saját man oldaláról tudhatunk meg többet. A <application>CVSup</application> futtatása Most már készen állunk egy próba frissítés elvégzésére. A parancssorban nem sok mindent kell beírnunk ehhez: &prompt.root; cvsup supfile ahol a supfile a frissen létrehozott supfile állományunk neve lesz. Feltételezve, hogy a parancsot X11 alatt adtunk ki, az cvsup erre feldob egy grafikus ablakot néhány gombbal. Nyomjuk meg a go feliratú gombot és dõljünk hátra. Mivel a példában a /usr/src könyvtárunk frissítését állítottuk be, az állományok aktualizálásához szükséges jogosultságok biztosításához a cvsup programot root felhasználóként kell elindítanunk. Teljesen érthetõ, ha egy kicsit izgatottak vagyunk ezekben a pillanatokban, hiszen az elõbb hoztunk létre egy általunk eddig ismeretlen programhoz egy konfigurációs állományt. Ezért megemlítenénk, hogy ilyenkor elõször mindig próbáljuk ki a konfigurációkat, mielõtt azok bármilyen módosítást végeznének a fontos állományainkon. Ehhez hozzunk létre valahol egy üres könyvtárat, majd adjuk meg a parancssorban ennek a nevét: &prompt.root; mkdir /var/tmp/proba &prompt.root; cvsup supfile /var/tmp/proba Az így megadott könyvtárba kerülnek a frissítés eredményeképpen keletkezõ állományok. A CVSup elõször megvizsgálja a /usr/src könyvtárban található állományokat, viszont egyiküket sem módosítja vagy törli. A frissítések ehelyett a /var/tmp/proba/usr/src könyvtárba fognak kerülni. A CVSup emellett még a báziskönyvtárában tárolt állapotokat sem fogja megváltoztatni. A módosított állományok új változatai a megadott könyvtárba jönnek létre. Mivel a /usr/src könyvtárt ehhez csak olvasni fogjuk, a próba lefuttatásához még root felhasználónak sem kell lennünk. Ha nem használunk X11-et vagy egyszerûen csak nincs szükségünk a grafikus felületre, a parancssorban pár további opció megadásával így is kiadhatjuk a cvsup parancsot: &prompt.root; cvsup -g -L 2 supfile A hatására a CVSup nem hozza be a grafikus felületét. Ha nem talál X11-et, akkor ez természetesen automatikus, de ellenkezõ esetben ezt is meg kell adnunk. Az megadásával a CVSup az összes elvégzendõ frissítésrõl részletes értesítést ad. A részletességnek három foka van, -tól indulva egészen -ig. Itt az alapértelmezett érték a 0, amivel a hibaüzenetek kivételével egyetlen üzenetet sem kapunk. Rengeteg egyéb beállítás adható még meg, ezeket a cvsup -H kiadásával kérdezhetjük le. A beállítások pontosabb leírását a man oldalon találjuk meg. Miután elégedetten tapasztaltuk, hogy a frissítés remekül mûködik, a &man.cron.8; segítségével próbáljuk meg az egész folyamatot önmûködövé tenni a CVSup szabályos idõközönkénti futtatásával. Ekkor viszont magától értetõdik, hogy a CVSup számára ne engedjük használni a grafikus felületet. A <application>CVSup</application> állománygyûjteményei A CVSup révén elérhetõ állománygyûjtemények egy hierarchikus rendszert alkotnak. Van néhány nagyobb állománygyûjtemény, amelyek kisebb al-állománygyûjteményekre bonthatóak. A nagyobb gyûjtemények letöltése ezért a kisebb algyûjtemények letöltésével egyenlõ. A gyûjtemények közt fennálló hierarchikus rendszer a lentebb szereplõ lista behúzásaiban érhetõ tetten. A leggyakrabban használt gyûjtemények a src-all és a ports-all neveket viselik. A többi gyûjteményt általában csak kevesen és csak speciális célokra használják, ezért egyes tükrözéseken nem feltétlenül találjuk meg mindegyiküket. cvs-all release=cvs A &os; fõ CVS repositoryja, beleértve a titkosításhoz tartozó kódokat is. distrib release=cvs A &os; terjesztéséhez és tükrözéséhez kapcsolódó állományok. doc-all release=cvs A &os; kézikönyvének és a többi dokumentáció forrásai. Nem tartalmazza a &os; honlapjának forrásait. ports-all release=cvs A &os; portgyûjteménye. Ha nem akarjuk a ports-all egészét (vagyis a teljes portfát) frissíteni, csak a lentebb szereplõ egyes algyûjteményeket letölteni, akkor soha ne feledkezzünk meg a ports-base megadásáról! Amikor valami változik a portok mûködésében, akkor a ports-base által képviselt algyûjteményben szereplõ állományokat igen gyorsan elkezdik használni a valódi portok. Ezért ha csak a valódi portokat frissítjük, amelyek viszont igényt tartanak néhány újabb funkcióra is, akkor könnyen fordítási hibára vagy különbözõ rejtélyes hibaüzenetekbe futhatunk. Emiatt legeslegelõször mindig tegyünk róla, hogy a ports-base algyûjteményünk a lehetõ legfrissebb legyen. Ha a ports/INDEX állomány egy saját példányát kívánjuk létrehozni, akkor ahhoz a ports-all gyûjteményt (tehát a teljes portfát) le kell kérnünk. A ports/INDEX állományt a portfa egy része alapján nem készíthetjük el. Errõl bõvebben lásd a GYIK-ot. ports-accessibility release=cvs A fogyatékos felhasználókat segítõ szoftverek. ports-arabic release=cvs Arab nyelvi támogatás. ports-archivers release=cvs Archiváló eszközök. ports-astro release=cvs Csillagászathoz tartozó portok. ports-audio release=cvs Hangtámogatás. ports-base release=cvs A Portgyûjtemény saját infrastruktúrája — az Mk/, Tools/ és /usr/ports különféle alkönyvtáraiban elhelyezkedõ állományok. Ne hagyjuk figyelmen kívül a fenti fontos figyelmeztetést sem: ezt az algyûjteményt mindig a &os; Portgyûjteményével együtt frissítsük! ports-benchmarks release=cvs Teljesítménytesztek. ports-biology release=cvs Biológia. ports-cad release=cvs Számítógépes tervezõeszközök (CAD). ports-chinese release=cvs Kínai nyelvi támogatás. ports-comms release=cvs Kommunikációs szoftverek. ports-converters release=cvs Karakterkódolások közti átalakítók. ports-databases release=cvs Adatbázisok. ports-deskutils release=cvs A számítógép feltalálása elõtt is már létezõ eszközök. ports-devel release=cvs Fejlesztõeszközök. ports-dns release=cvs Névfeloldással kapcsolatos szoftverek. ports-editors release=cvs Szövegszerkesztõk. ports-emulators release=cvs Más operációs rendszerek emulátorai. ports-finance release=cvs Pénzügyi, gazdasági és hasonló alkalmazások. ports-ftp release=cvs FTP kliensek és szerverek. ports-games release=cvs Játékok. ports-german release=cvs Német nyelvi támogatás. ports-graphics release=cvs Grafikus segédeszközök. ports-hebrew release=cvs Héber nyelvi támogatás. ports-hungarian release=cvs Magyar nyelvi támogatás. ports-irc release=cvs IRC-vel kapcsolatos programok. ports-japanese release=cvs Japán nyelvi támogatás. ports-java release=cvs &java; segédeszközök. ports-korean release=cvs Koreai nyelvi támogatás. ports-lang release=cvs Programozási nyelvek. ports-mail release=cvs Levelezõ programok. ports-math release=cvs Numerikus számításokkal foglalkozó programok. ports-mbone release=cvs MBone alkalmazások. ports-misc release=cvs Egyéb segédprogramok. ports-multimedia release=cvs Multimediás szoftverek. ports-net release=cvs Hálózati szoftverek. ports-net-im release=cvs Üzenetküldõ (Instant Messaging, IM) szoftverek. ports-net-mgmt release=cvs Hálózati karbantartó szoftverek. ports-net-p2p release=cvs Egyenrangú (Peer to Peer, P2P) hálózatok. ports-news release=cvs USENET hírszoftverek. ports-palm release=cvs A Palm sorozat szoftveres támogatása. ports-polish release=cvs Lengyel nyelvi támogatás. ports-ports-mgmt release=cvs A portok és csomagok karbantartását végzõ segédeszközök. ports-portuguese release=cvs Portugál nyelvi támogatás. ports-print release=cvs Nyomdai programok. ports-russian release=cvs Orosz nyelvi támogatás. ports-science release=cvs Tudományos programok. ports-security release=cvs Biztonsági segédprogramok. ports-shells release=cvs Parancsértelmezõk. ports-sysutils release=cvs Rendszerprogramok. ports-textproc release=cvs Szövegfeldolgozást segítõ eszközök (kivéve az asztali kiadványszerkesztést). ports-ukrainian release=cvs Ukrán nyelvi támogatás. ports-vietnamese release=cvs Vietnámi nyelvi támogatás. ports-www release=cvs A világhálóhoz tartozó szoftverek. ports-x11 release=cvs Az X Window System mûködését segítõ portok. ports-x11-clocks release=cvs X11 órák. ports-x11-drivers release=cvs X11 meghajtók. ports-x11-fm release=cvs X11 állománykezelõk. ports-x11-fonts release=cvs X11 betûtípusok és a hozzájuk tartozó segédprogramok. ports-x11-toolkits release=cvs X11 eszközrendszerek. ports-x11-servers release=cvs X11 szerverek. ports-x11-themes release=cvs X11 témák. ports-x11-wm release=cvs X11 ablakkezelõk. projects-all release=cvs A &os; projektek forrásainak repositoryja. src-all release=cvs A &os; fontosabb forrásai, a titkosításhoz tartozó kódokkal együtt. src-base release=cvs A /usr/src könyvtárban levõ egyéb állományok. src-bin release=cvs Az egyfelhasználós módban használható segédeszközök (/usr/src/bin). src-cddl release=cvs A CDDL licenc szerint terjesztett segédprogramok és függvénykönyvtárak (/usr/src/cddl). src-contrib release=cvs A &os; Projekten kívül fejlesztett segédprogramok és függvénykönyvtárak, viszonylag kevés módosítással (/usr/src/contrib). src-crypto release=cvs A &os; Projekten kívül fejlesztett, titkosítással kapcsolatos segédprogramok és függvénykönyvtárak, viszonylag kevés módosítással (/usr/src/crypto). src-eBones release=cvs Kerberos és DES (/usr/src/eBones). A &os; jelenlegi változatai nem használják. src-etc release=cvs A rendszer beállításait tartalmazó állományok (/usr/src/etc). src-games release=cvs Játékok (/usr/src/games). src-gnu release=cvs A GPL licenc szerint terjesztett segédprogramok (/usr/src/gnu). src-include release=cvs (C nyelvi) Header állományok (/usr/src/include). src-kerberos5 release=cvs A Kerberos5 biztonsági csomag (/usr/src/kerberos5). src-kerberosIV release=cvs A KerberosIV biztonsági csomag (/usr/src/kerberosIV). src-lib release=cvs Függvénykönyvtárak (/usr/src/lib). src-libexec release=cvs Más programok által futtatott rendszerprogramok (/usr/src/libexec). src-release release=cvs A &os; kiadások elkészítéséhez szükséges állományok (/usr/src/release). src-rescue release=cvs Statikusan linkelt programok vészhelyzet esetére, lásd &man.rescue.8; (/usr/src/rescue). src-sbin release=cvs Egyfelhasználós módban használható rendszereszközök (/usr/src/sbin). src-secure release=cvs Titkosítással foglalkozó függvénykönyvtárak és parancsok (/usr/src/secure). src-share release=cvs Több rendszer között megosztható állományok (/usr/src/share). src-sys release=cvs A rendszermag (/usr/src/sys). src-sys-crypto release=cvs A rendszermagban levõ titkosítással foglalkozó kód (/usr/src/sys/crypto). src-tools release=cvs A &os; karbantartására való különbözõ segédprogramok (/usr/src/tools). src-usrbin release=cvs Felhasználói segédprogramok (/usr/src/usr.bin). src-usrsbin release=cvs Rendszerszintû segédprogramok (/usr/src/usr.sbin). www release=cvs A &os; Projekt honlapjának forráskódja. distrib release=self A CVSup szerver saját konfigurációs állományai. A CVSup tükrözései használják. gnats release=current A GNATS hibanyilvántartó adatbázis. mail-archive release=current A &os; levelezési listáinak archívuma. www release=current A &os; Projekt honlapjának generált állományai (de nem a forrásai). A WWW tükrözések használják. Bõvebb információk A CVSup részletesebb bemutatását és a hozzátartozó GYIK-ot A CVSup honlapján találjuk meg. A CVSup &os;-re vonatkozó tárgyalása a &a.hackers;n történik. Itt és az &a.announce;n jelentik be a szoftver újabb változatait. A CVSup alkalmazással kapcsolatos kérdéseket és hibajelentéseket illetõen a CVSup GYIK-ot érdemes megnéznünk. CVSup oldalak A &os; CVSup szerverei az alábbi oldalakon érhetõek el: &chap.mirrors.cvsup.inc; A <application>Portsnap</application> használata Bevezetés A Portsnap a &os; portfájának biztonságos terjesztésére megalkotott rendszer. Hozzávetõleg óránként egyszer a portfa egy újabb pillanatképe jön létre, amit ezután tömörítenek és digitálisan aláírnak. Az így keletkezõ állományokat végül HTTP-n keresztül terjesztik. A CVSuphoz hasonlóan a Portsnap szintén lehúzással frissít. Ennek folyamán a becsomagolt és aláírt portfák egy webszerveren tároltan várják passzívan a kliensek kéréseit. A felhasználók így vagy a &man.portsnap.8; elindításával azonnal, vagy pedig a &man.cron.8; segítségével rendszeresen automatikusan kérhetnek frissítéseket. Technikai megfontolásokból a Portsnap nem közvetlenül a /usr/ports/ könyvtárban található éles portfát változtatja meg. Helyette alapértelmezés szerint a /var/db/portsnap/ könyvtárba kerülõ tömörített változatával dolgozik. A frissítés befejeztével ezzel a tömörített változattal módosítja az éles portfát. Ha a Portsnapet a &os; Portgyûjteményébõl telepítjük, akkor alapértelmezés szerint a tömörített pillanatképet a /var/db/portsnap/ könyvtár helyett a /usr/local/portsnap/ könyvtárban hozza létre. Telepítés A &os; 6.0 vagy késõbbi változataiban már a Portsnap az alaprendszer része. A &os; korábbi verzióra a ports-mgmt/portsnap porton keresztül telepíthetjük. A <application>Portsnap</application> beállítása A Portsnap mûködését az /etc/portsnap.conf konfigurációs állomány vezérli. A felhasználók többségének a benne helyet kapott alapbeállítások megfelelõek. Aki kíváncsi a részletekre, nézze meg a &man.portsnap.conf.5; man oldalt. Amennyiben a Portsnapet a &os; Portgyûjteményébõl telepítettük, a /etc/portsnap.conf helyett a /usr/local/etc/portsnap.conf konfigurációs állományt fogja használni. Ez az állomány a port telepítésekor ugyan nem jön létre automatikusan, de találhatunk belõle egy mintát, amit a következõ paranccsal tudunk a helyére másolni: &prompt.root; cd /usr/local/etc && cp portsnap.conf.sample portsnap.conf A <application>Portsnap</application> elsõ futtatása A &man.portsnap.8; elsõ futtatásakor le kell töltenünk a /var/db/portsnap/ (vagy /usr/local/portsnap/, ha a Portsnapet a Portgyûjteménybõl telepítettük) könyvtárba az egész portfa tömörített képét. Ez 2006 elejétõl nagyjából 41 MB méretûre dagadt. &prompt.root; portsnap fetch Miután sikerült letöltenünk a tömörített képet, az éles portfa egy példányát tudjuk kibontani a /usr/ports/ könyvtárba. Ez a lépés még abban az esetben is kötelezõ, ha már valamilyen módon feltöltöttük volna ezt a könyvtárat (például a CVSup segítségével), hiszen ekkor hozza létre a portsnap a mûködéséhez szükséges adatokat is, amelyek révén el tudja majd dönteni, hogy a portfa pontosan mely részeit kell frissítenie. &prompt.root; portsnap extract A telepítés során alapból nem jön létre a /usr/ports/ könyvtár. Ha a &os; 6.0-RELEASE kiadását használjuk, akkor a portsnap indítása elõtt ezt a könyvtárat el kell készítenünk. A &os; vagy a Portsnap újabb változataiban a portsnap elsõ használata során ez már azonban önmagától megtörténik. A portfa frissítése Miután letöltöttük a portfa kiinduló pillanatképét és kibontottuk a /usr/ports/ könyvtárba, a frissítése két lépésben végezhetõ el: elõször elkérjük (fetch) a tömörített kép frissítéseit, majd ezután az így nyert módosításokat érvényesítjük az éles portfán (update). Ez a két lépés egyetlen portsnap parancs kiadásával összefoglalható: &prompt.root; portsnap fetch update A portsnap némely régebbi változatai nem támogatják ezt a típusú felírást. Ha tehát nem mûködne az iménti parancs, akkor helyette próbáljuk meg ezt: &prompt.root; portsnap fetch &prompt.root; portsnap update A <application>Portsnap</application> automatikus futtatása A Portsnap szervereken keletkezõ hirtelen tömeg elkerülése érdekében a portsnap fetch nem fog &man.cron.8; feladatként futni. Ehelyett erre létezik egy külön portsnap cron parancs, amivel a frissítések letöltése elõtt véletlenszerûen vár legfeljebb 3600 másodpercet. Emellett a portsnap update parancs futtatását sem javasoljuk cron feladatként, mivel komoly problémákat képes okozni akkor, amikor egy port fordítása vagy telepítése során adjuk ki. Azonban az kapcsoló megadásával a portok INDEX állományát biztonságosan tudjuk frissíteni. (Ebbõl nyilvánvalóan következik, hogy a portsnap -I update lefutása után a portsnap update parancsot is ki kell majd adni az kapcsoló nélkül a fa többi részének frissítéséhez.) Ha felvesszük a következõ sort az /etc/crontab állományba, akkor a portsnap frissíteni fogja a tömörített felvételt és a /usr/ports/ könyvtárban levõ INDEX állományokat, és küld egy levelet az elavult feltelepített portokról: 0 3 * * * root portsnap -I cron update && pkg_version -vIL= Ha a rendszeróra nem helyi idõ szerint jár, akkor a 3 értéket cseréljük ki egy 0 és 23 között tetszõleges számra, így hozzájárulunk a a Portsnap szerverek terhelésének egyenletes elosztásához. A portsnap egyes korábbi változatai nem engednek meg egyszerre több parancsot (mint például a cron update). Ha az iménti felírásban hibát kapunk, akkor próbáljuk meg a portsnap -I cron update parancsot kicserélni a portsnap cron && portsnap -I update parancsra. CVS címkék Meg kell adnunk egy revízió címkéjét, amikor a cvs vagy CVSup használatával letöltjük vagy frissítjük a forrásokat. A revíziós címkék a &os; egyik fejlesztési irányát vagy egy adott idõpontbeli állapotát hivatkozzák. Az elõbbi egy ág címkéje, míg az utóbbi pedig egy kiadás címkéje. Az ágak címkéi A HEAD kivételével (amely mindig egy érvényes címke) az összes címke csak a src/ fára vonatkozik. A ports/, doc/ és www/ fák nem tartalmaznak ágakat. HEAD A fõ fejlesztési ág, avagy a &os;-CURRENT szimbolikus neve. Ha nem adunk meg revíziót, ez lesz az alapértelmezés. A CVSup számára ezt . címke jelzi (itt most nem mondatvégi pontot jelöli, hanem a . karaktert). A CVS számára ez lesz az alapértelmezett érték, ha nem adunk meg konkrét revíziós címkét. Többnyire nem túlzottan jó ötlet egy STABLE változatot használó gépen a CURRENT verziójú források kikérése, kivéve hacsak nem ez a szándékunk. RELENG_7 A FreeBSD-7.X fejlesztési ága, más néven a FreeBSD 7-STABLE RELENG_7_0 A FreeBSD-7.0 kiadás ága, ahová csak a biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_6 A FreeBSD-6.X fejlesztési ága, más néven a FreeBSD 6-STABLE RELENG_6_3 A FreeBSD-6.3 kiadás ága, ahová csak biztonsági frissítések és a ritikus hibajavítások kerülnek. RELENG_6_2 A FreeBSD-6.2 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_6_1 A FreeBSD-6.1 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_6_0 A FreeBSD-6.0 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_5 A FreeBSD-5.X fejlesztési ág, más néven a FreeBSD 5-STABLE. RELENG_5_5 A FreeBSD-5.5 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_5_4 A FreeBSD-5.4 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_5_3 A FreeBSD-5.3 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_5_2 A FreeBSD-5.2 és FreeBSD-5.2.1 kiadások ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_5_1 A FreeBSD-5.1 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_5_0 A FreeBSD-5.0 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_4 A FreeBSD-4.X fejlesztési ága, más néven a FreeBSD 4-STABLE. RELENG_4_11 A FreeBSD-4.11 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_4_10 A FreeBSD-4.10 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_4_9 A FreeBSD-4.9 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_4_8 A FreeBSD-4.8 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_4_7 A FreeBSD-4.7 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_4_6 A FreeBSD-4.6 és FreeBSD-4.6.2 kiadások ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_4_5 A FreeBSD-4.5 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_4_4 A FreeBSD-4.4 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_4_3 A FreeBSD-4.3 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_3 A FreeBSD-3.X fejlesztési ága, más néven a 3.X-STABLE. RELENG_2_2 A FreeBSD-2.2.X fejlesztési ága, más néven a 2.2-STABLE. Ez az ág manapság már elavult. A kiadások címkéi Ezek a címkék a &os; egyes kiadásainak dátumára hivatkoznak. Egy kiadás elõkészítésének és terjesztésének folyamatáról részleteiben a kiadásokat összefoglaló lapról és a kiadások építésérõl szóló cikkbõl tájékozódhatunk. Az src fában RELENG_ kezdetû címkéket találunk. A ports és doc fákban a címkék nevei a RELEASE elõtaggal kezdõdnek. Végezetül a www fában nincsenek kiadásokhoz tartozó címkék. RELENG_7_0_0_RELEASE FreeBSD 7.0 RELENG_6_3_0_RELEASE FreeBSD 6.3 RELENG_6_2_0_RELEASE FreeBSD 6.2 RELENG_6_1_0_RELEASE FreeBSD 6.1 RELENG_6_0_0_RELEASE FreeBSD 6.0 RELENG_5_5_0_RELEASE FreeBSD 5.5 RELENG_5_4_0_RELEASE FreeBSD 5.4 RELENG_4_11_0_RELEASE FreeBSD 4.11 RELENG_5_3_0_RELEASE FreeBSD 5.3 RELENG_4_10_0_RELEASE FreeBSD 4.10 RELENG_5_2_1_RELEASE FreeBSD 5.2.1 RELENG_5_2_0_RELEASE FreeBSD 5.2 RELENG_4_9_0_RELEASE FreeBSD 4.9 RELENG_5_1_0_RELEASE FreeBSD 5.1 RELENG_4_8_0_RELEASE FreeBSD 4.8 RELENG_5_0_0_RELEASE FreeBSD 5.0 RELENG_4_7_0_RELEASE FreeBSD 4.7 RELENG_4_6_2_RELEASE FreeBSD 4.6.2 RELENG_4_6_1_RELEASE FreeBSD 4.6.1 RELENG_4_6_0_RELEASE FreeBSD 4.6 RELENG_4_5_0_RELEASE FreeBSD 4.5 RELENG_4_4_0_RELEASE FreeBSD 4.4 RELENG_4_3_0_RELEASE FreeBSD 4.3 RELENG_4_2_0_RELEASE FreeBSD 4.2 RELENG_4_1_1_RELEASE FreeBSD 4.1.1 RELENG_4_1_0_RELEASE FreeBSD 4.1 RELENG_4_0_0_RELEASE FreeBSD 4.0 RELENG_3_5_0_RELEASE FreeBSD-3.5 RELENG_3_4_0_RELEASE FreeBSD-3.4 RELENG_3_3_0_RELEASE FreeBSD-3.3 RELENG_3_2_0_RELEASE FreeBSD-3.2 RELENG_3_1_0_RELEASE FreeBSD-3.1 RELENG_3_0_0_RELEASE FreeBSD-3.0 RELENG_2_2_8_RELEASE FreeBSD-2.2.8 RELENG_2_2_7_RELEASE FreeBSD-2.2.7 RELENG_2_2_6_RELEASE FreeBSD-2.2.6 RELENG_2_2_5_RELEASE FreeBSD-2.2.5 RELENG_2_2_2_RELEASE FreeBSD-2.2.2 RELENG_2_2_1_RELEASE FreeBSD-2.2.1 RELENG_2_2_0_RELEASE FreeBSD-2.2.0 AFS oldalak A &os; a következõ szerverein érhetõ el AFS: Svédország Az állományok a következõ helyen érhetõek el: /afs/stacken.kth.se/ftp/pub/FreeBSD/ stacken.kth.se # Stacken Computer Club, KTH, Svédország 130.237.234.43 #hot.stacken.kth.se 130.237.237.230 #fishburger.stacken.kth.se 130.237.234.3 #milko.stacken.kth.se Karbantartó: ftp@stacken.kth.se Rsync oldalak A most következõ oldalakon a &os;-t érhetjük el az rsync protokollal. Az rsync segédprogram mûködésében leginkább a &man.rcp.1; parancshoz hasonlít, de sokkal több beállítással rendelkezik, és az rsync távoli frissítéseket kezelõ protokollja segítségével csak az állományok csoportjai között levõ eltéréseket küldi át, amivel a hálózaton keresztüli szinkronizáció rendkívül felgyorsítható. Ez olyankor jelent számunkra a legtöbbet, ha a &os; FTP szerverének vagy CVS repositoryjának egyik tükrözését tartjuk karban. Az rsync több operációs rendszerre is elérhetõ, és &os;-n a net/rsync port vagy csomag tartalmazza. Cseh Köztársaság rsync://ftp.cz.FreeBSD.org/ Elérhetõ gyûjtemények: ftp: a &os; FTP szerverének részleges tükrözése. FreeBSD: a &os; FTP szerverének teljes tükrözése. Németország rsync://grappa.unix-ag.uni-kl.de/ Elérhetõ gyûjtemények: freebsd-cvs: a &os; teljes CVS tárháza. Ez a gép ezen kívül még tükrözi a NetBSD és OpenBSD CVS repositorykat is. Hollandia rsync://ftp.nl.FreeBSD.org/ Elérhetõ gyûjtemények: vol/4/freebsd-core: a &os; FTP szerverének teljes tükrözése. Oroszország rsync://cvsup4.ru.FreeBSD.org Elérhetõ gyûjtemények: FreeBSD-gnats: A GNATS hibanyilvántartó adatbázis. Tajvan rsync://ftp.tw.FreeBSD.org/ rsync://ftp2.tw.FreeBSD.org/ rsync://ftp6.tw.FreeBSD.org/ Elérhetõ gyûjtemények: FreeBSD: a &os; FTP szerverének teljes tükrözése. Egyesült Királyság rsync://rsync.mirror.ac.uk/ Elérhetõ gyûjtemények: ftp.FreeBSD.org: a &os; FTP szerverének teljes tükrözése. Amerikai Egyesült Államok rsync://ftp-master.FreeBSD.org/ Ezt a szervert csak az elsõdleges &os; tükrözéseknek szabad használniuk. Elérhetõ gyûjtemények: FreeBSD: a &os; FTP szerverének központi archívuma. acl: a &os; központi ACL listája. rsync://ftp13.FreeBSD.org/ Elérhetõ gyûjtemények: FreeBSD: a &os; FTP szerver teljes tükrözése. diff --git a/hu_HU.ISO8859-2/books/handbook/ppp-and-slip/chapter.sgml b/hu_HU.ISO8859-2/books/handbook/ppp-and-slip/chapter.sgml index 25b24cefae..1175f7bdbc 100644 --- a/hu_HU.ISO8859-2/books/handbook/ppp-and-slip/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/ppp-and-slip/chapter.sgml @@ -1,4207 +1,4065 @@ Jim Mock Átdolgozta, átrendezte és aktualizálta: A PPP és a SLIP Áttekintés PPP SLIP A &os; számos módon képes összekötni két számítógépet. Ha betárcsázós modemmel akarunk hálózati vagy internetes kapcsolatot felépíteni, esetleg azt szeretnénk, hogy mások képesek legyenek minket ilyen módon elérni, akkor ahhoz PPP-t, illetve SLIP-et kell használnunk. Ebben a fejezetben a modemes kommunikáció beállításait mutatjuk be részletesebben. A fejezet elolvasása során megismerjük: hogyan állítsunk be felhasználói PPP-t; hogyan állítsunk be rendszerszintû PPP-t; hogyan állítsunk be egy PPPoE (PPP over Ethernet, vagyis PPP Ethernet felett) kapcsolatot; hogyan állítsunk be egy PPPoA (PPP over ATM, vagyis PPP ATM felett) kapcsolatot; hogyan állítsunk be SLIP klienst és szervert. PPP felhasználói PPP PPP rendszer PPP PPP Ethernet felett A fejezet elolvasásához ajánlott: az alapvetõ hálózati technológiák ismerete; a betárcsázós kapcsolatok, a PPP és/vagy SLIP alapjainak és céljainak megértése. Talán érdekli a kedves olvasót, hogy mi az alapvetõ különbség a felhasználói és a rendszerszintû PPP között. A válasz egyszerû: a felhasználói PPP a beérkezõ és kimenõ adatokat nem a rendszermagban, hanem a felhasználói szinten dolgozza fel. Ez költséges abból a szempontból, hogy emiatt adatokat kell másolgatni a rendszer és a felhasználói szint között, azonban egy sokkal többet tudó PPP implementációnak ad ezzel utat. A felhasználói PPP a tun eszközön keresztül kommunikál a külvilággal, miközben a rendszermagban található PPP mindezt a ppp eszközzel valósítja meg. A fejezetben a felhasználói PPP-t egyszerûen csak ppp néven fogjuk hivatkozni, hacsak nem lesz szükséges különbséget tennünk közte és más PPP szoftverek, mint például a pppd között. Ha mást nem mondunk, akkor a fejezetben ismertetett összes parancsot root felhasználóként kell kiadni. Tom Rhodes Frissítette és javította: Brian Somers Eredetileg készítette: Nik Clayton Segített még: Dirk Frömberg Peter Childs A felhasználói PPP alkalmazása A felhasználói PPP Elõfeltételek A leírás feltételezi, hogy rendelkezünk a következõkkel: internet-szolgáltató PPP kapcsolat Olyan internet-elõfizetés, ahol PPP-n keresztül csatlakozunk Egy modem vagy más olyan rendszerünkhöz csatlakozó eszköz, amelyen keresztül el tudjuk érni az internet-szolgáltatónkat Az internet-elõfizetés betárcsázásához szükséges telefonszámok PAP CHAP UNIX bejelentkezési név jelszó A bejelentkezési nevünk és jelszavunk. (Vagy a megszokott &unix;-os felhasználói név és jelszó páros, vagy egy PAP esetleg CHAP bejelentkezési név és jelszó.) névszerver Egy vagy több névszerver IP-címe. Ehhez az internet-szolgáltatók általában két IP-címet adnak meg. Ha egyet sem kaptunk, akkor a ppp.conf állományban erre a célra használhatjuk az enable dns parancsot, és ekkor a ppp majd automatikusan be fogja állítani nekünk a névszervereket. Ezt a lehetõséget az befolyásolja, hogy az internet-szolgáltató oldalán mûködõ PPP implementáció támogatja-e a névfeloldás egyeztetését (DNS negotiation). A következõ információkat is megkaphatjuk az internet-elõfizetésünkhöz, de nem feltétlenül szükségesek: Az internet-szolgáltató átjárójának IP-címe. Az átjáró az a gép, amelyen keresztül a gépünk csatlakozik és számára ez lesz az alapértelmezett átjáró. Ha nem rendelkezünk ezzel az információval, akkor csak állítsunk be valamit, és majd a csatlakozáskor a szolgáltató PPP szervere felülírja a megfelelõ beállításokkal. Erre a címre a ppp HISADDR néven hivatkozik. A használandó hálózati maszk. Amennyiben a szolgáltató ezt nem adta meg, nyugodtan használjuk erre a 255.255.255.255 értéket. statikus IP-cím Ha a szolgáltatónk statikus IP-címet és rögzített hálózati nevet is biztosít nekünk, ezt is megadhatjuk. Minden más esetben egyszerûen csak hagyjuk, hogy a rendszer automatikusan válasszon nekünk egyet. Ha a szükséges információknak nem vagyunk birtokában, akkor vegyük fel a kapcsolatot az internet-szolgáltatókkal. Ebben a szakaszban a példákban szereplõ konfigurációs állományok sorait számozva láthatjuk. Ezek a sorszámok a bemutatás és a tárgyalás megkönnyítése érdekében szerepelnek, és nem az eredeti állományok részei. Mindezek mellett a tabulátorok és szóközök megfelelõ használata is fontos. A <application>PPP</application> automatikus beállítása PPP beállítása A ppp és a pppd (a PPP rendszerszintû megvalósítása) egyaránt az /etc/ppp könyvtárban található konfigurációs állományokat használja. A felhasználói PPP-hez ezenkívül még a /usr/share/examples/ppp/ könyvtárban vannak példák. A ppp parancs beállítása az igényeinktõl függõen számos állomány módosítását igényelheti. A tartalmukat nagyban befolyásolja, hogy a szolgáltatónk részérõl a címeket kiosztása statikus (vagyis egy adott címet kapunk és folyamatosan azt használjuk) esetleg dinamikus (vagyis az IP-címünk minden egyes kapcsolódáskor más és más). PPP statikus IP-címmel PPP statikus IP-címmel Ebben az esetben az /etc/ppp/ppp.conf konfigurációs állományt kell átszerkesztenünk. Tartalma az alábbi példához hasonlítható. A : karakterrel végzõdõ sorok mindig az elsõ oszlopban kezdõdnek (tehát a sor elején), míg az összes többi sort tabulátorok vagy szóközök használatával bentebb kell raknunk. 1 default: 2 set log Phase Chat LCP IPCP CCP tun command 3 ident user-ppp VERSION (built COMPILATIONDATE) 4 set device /dev/cuad0 5 set speed 115200 6 set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \ 7 \"\" AT OK-AT-OK ATE1Q0 OK \\dATDT\\T TIMEOUT 40 CONNECT" 8 set timeout 180 9 enable dns 10 11 szolgaltato: 12 set phone "(123) 456 7890" 13 set authname ize 14 set authkey mize 15 set login "TIMEOUT 10 \"\" \"\" gin:--gin: \\U word: \\P col: ppp" 16 set timeout 300 17 set ifaddr x.x.x.x y.y.y.y 255.255.255.255 0.0.0.0 18 add default HISADDR 1. sor: Ez azonosítja be az alapértelmezett bejegyzést. Az itt szereplõ parancsok a ppp minden egyes futásakor magukból végrehajtódnak. 2. sor: Beállítja a naplózás paramétereit. Amikor a beállításaink már kifogástalanul mûködnek, akkor ezt a sort érdemes átírni a következõre: set log phase tun Ezzel jelentõs mértékben vissza tudjuk fogni a naplózás mértékét. 3. sor: Ezzel mondjuk meg a PPP-nek, hogy a többiek felé miként azonosítsa magát. A PPP akkor azonosítja magát a társak felé, ha valamilyen gondja akad az egyeztetésekkel és a kapcsolat beállításával. Az így továbbított információk a másik oldal rendszergazdái számára nyújthatnak segítséget az ilyen jellegû problémák felderítésében. 4. sor: Itt adjuk meg az eszközt, amelyre a modem csatlakozik. A COM1 neve /dev/cuad0, a COM2 neve pedig /dev/cuad1. 5. sor: A csatlakozás sebességét adjuk meg. Ha a 115 200-as érték itt nem mûködne (ez egyébként minden újabb gyártmányú modem esetében elfogadható), akkor helyette használjuk a 38400-as beállítást. 6. és 7. sorok: PPP felhasználói PPP A híváshoz használt karakterlánc. A felhasználói PPP a &man.chat.8; programhoz hasonló küldök-várok típusú szerkesztést alkalmaz. A kihasználható lehetõségekrõl a man oldalán olvashatunk részletesebben. Az olvashatóság kedvéért a parancs a következõ sorban folytatódik. A ppp.conf állományban bármelyik parancs, ahol a \ karakterrel zárjuk a sort, az ugyanígy folytatható a következõben. 8. sor: A kapcsolathoz tartozó üresjárati idõt állítja be. Ennek értéke alapból 180 másodperc, így ez a sor pusztán csak az érthetõséget szolgálja. 9. sor: Arra utasítja a PPP-t, hogy a többiektõl kérdezze le a helyi névfeloldó beállításait. Ha saját névszervert futtatunk, akkor ezt a sort tegyük inkább megjegyzésbe vagy töröljük ki. 10. sor: Ez az üres sor az átláthatóság kedvéért került bele. A PPP az összes üres sort figyelmen kívül hagyja. 11. sor: Itt kezdõdik a szolgaltato nevû szolgáltatóhoz tartozó bejegyzés. Ezt késõbb akár ki is cserélhetjük az internet-szolgáltatónk nevére, így a beállítással tudjuk majd beindítani a kapcsolatot. 12. sor: Beállítjuk a szolgáltatóhoz tartozó telefonszámot. A kettõspont (:) vagy a csõvezeték (|) karakterekkel elválasztva több telefonszámot is meg tudunk adni. A &man.ppp.8; oldalon olvashatunk a két elválasztó közti különbségekrõl. Röviden ezeket úgy foglalhatnánk össze, hogy ha váltogatni akarunk a számok között, akkor használjuk a kettõspontot. Ha mindig az elsõként megadott számot akarjuk hívni és a többit csak akkor, ha ez nem mûködik, akkor a csõvezeték karakterre lesz szükségünk. Ahogy a példa is mutatja, az összes telefonszámot tegyük mindig idézõjelek közé. Ha a telefonszámban egyébként is szerepelnek szóközök, akkor is idézõjelek (") közé kell tennünk. Ennek elhagyásával egy egyszerû, ámde kényes hibát ejtünk. 13. és 14. sor: A felhasználói nevet és jelszót tartalmazza. Amikor egy &unix; fajtájú bejelentkezést kapunk, akkor ezekre az értékekre a set login parancsban \U és \P változókkal tudunk hivatkozni. Ha PAP vagy CHAP használatával jelentkezünk be, akkor ezek az értékek a hitelesítéskor kerülnek felhasználásra. 15. sor: PAP CHAP Ha a PAP vagy CHAP protokollok valamelyikét használjuk, akkor nem lesz szükségünk a login változóra, ezért ezt megjegyzésbe is tehetjük, vagy akár ki is törölhetjük. A PAP és CHAP hitelesítésrõl szóló részben olvashatjuk ennek további részleteit. A bejelentkezéshez használt karakterlánc hasonlít a behíváshoz használt, chat-szerû felépítéssel rendelkezõ karakterlánchoz. A példában látható karakterlánc egy olyan szolgáltatáshoz illeszkedik, ahol a bejelentkezés valahogy így néz ki: A Világ Legjobb Szolgáltatója login: izé password: mizé protocol: ppp Ezt a szkriptet alakítsuk a saját igényeinkhez. Ha elõször próbálkozunk ilyen szkript írásával, akkor lehetõleg kapcsoljuk be a rendszerek között lezajló beszélgetés naplózását, hogy ellenõrizni tudjuk minden a megfelelõen módon történik-e. 16. sor: idõkorlát Beállítjuk a kapcsolathoz tartozó alapértelmezett idõkorlátot (másodpercben). Itt a kapcsolat automatikusan lezárul 300 másodperc tétlenséget követõen. Ha nem akarunk ilyen korlátot szabni, akkor ezt az értéket állítsuk nullára vagy használjuk a paranccsori kapcsolót. 17. sor: internet-szolgáltató A felülethez tartozó címeket állítja be. A x.x.x.x helyére a szolgáltató által kiosztott IP-címet kell beírnunk. A y.y.y.y helyett pedig a szolgáltató átjárója kerül be (lényegében az a gép, amelyhez csatlakozunk). Amennyiben az internet-szolgáltatónk nem adott meg semmilyen átjárót, erre a célra a 10.0.0.2/0 címet is használhatjuk. Amikor nekünk kell kitalálnunk ezeket a címeket, akkor ne felejtsünk el létrehozni hozzájuk egy bejegyzést az /etc/ppp/ppp.linkup állományban a PPP dinamikus IP-címmel szakaszban szereplõek szerint. Ha nem adjuk meg ezt a sort, akkor a ppp parancs nem képes módban mûködni. 18. sor: A szolgáltató átjárójához felvesz egy alapértelmezett útvonalat. A HISADDR kulcsszót a 17. sorban megadott átjáró címével helyettesítjük. Ezért fontos, hogy ez a 17. sor után szerepeljen, különben a HISADDR nem lesz képes inicializálódni. Ha a ppp parancsot nem akarjuk módban futtatni, akkor ezt a sort a ppp.linkup állományba is átrakhatjuk. Ha statikus IP-címmel rendelkezünk és a ppp módban fut, akkor a ppp.linkup állományba egészen addig nem kell semmit sem írnunk, amíg a csatlakozás elõtt az útválasztási táblázatokban a megfelelõ adatok találhatóak. Olyankor is jól jöhet, amikor a csatlakozást követõen meg akarunk hívni bizonyos programokat. Ezt majd a sendmailes példában fogjuk bõvebben kifejteni. Erre példákat a /usr/share/examples/ppp/ könyvtárban találhatunk. PPP dinamikus IP-címmel PPP dinamikus IP-címmel IPCP Ha az internet-szolgáltatónktól nem kaptunk statikus IP-címet, akkor a ppp paranccsal is be tudjuk állítani a helyi és távoli címeket. Ez az IP-címek kitalálásával történik, valamint úgy, hogy a ppp számára a csatlakozás után lehetõvé tesszük az IP konfigurációs protocol (IP Configuration Protocol, IPCP) használatát. A ppp.conf tartalma szinte teljesen megegyezik a PPP statikus IP-címmel részben szereplõvel, egyetlen apró különbséggel: 17 set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.255 Ismét szeretnénk elmondani, hogy a sorszámot ne írjuk bele, hiszen az csak hivatkozási céllal szerepel. Legalább egy szóközzel kezdjünk bentebb. 17. sor: A / után megjelenõ szám azoknak a biteknek a számát adja meg, amire a ppp támaszkodik. A környezetünknek jobban megfelelõ IP-címeket is megadhatunk, de a fenti példa minden esetben mûködni fog. Az utolsó paraméterrel (0.0.0.0) azt mondjuk a PPP-nek, hogy az egyeztetést ne a 10.0.0.1, hanem a 0.0.0.0 címmel kezdje meg, amire egyes szolgáltatók esetén szükségünk is lesz. A set ifaddr elsõ paramétereként azonban soha ne adjuk meg a 0.0.0.0 címet, mivel ezzel a PPP módban nem tudja beállítani a kezdeti útvonalat. Ha nem módban indítjuk, akkor az /etc/ppp/ppp.linkup állományban meg kell adnunk még egy bejegyzést is. A ppp.linkup állományt a kapcsolat létrejötte után dolgozzuk fel. Itt már a ppp megkapta a felülethez tartozó címeket, így az útválasztási táblázatba fel tudjuk venni hozzájuk a megfelelõ bejegyzéseket: 1 szolgaltato: 2 add default HISADDR 1. sor: A kapcsolat felépítése során a ppp a ppp.linkup állományban a következõ szabályok szerint fogja keresni a bejegyzéseket: elõször a ppp.conf állományban megadott címkét próbálja megtalálni. Ha ez nem sikerül, akkor az átjárónknak megfelelõ bejegyzést kezdi el keresni. Ez egy négy byte-ból álló, felírásában az IP-címekhez hasonlító címke. Ha még ez a címke sem található, akkor a MYADDR bejegyzést keresi. 2. sor: Ez a sor mondja meg a ppp programnak, hogy vegyen fel egy HISADDR címre vonatkozó alapértelmezett útvonalat. A HISADDR címet az IPCP által egyeztetett átjáró IP-címére cseréljük ki. Ha erre a részletesebb példát akarunk látni, akkor a /usr/share/examples/ppp/ppp.conf.sample és /usr/share/examples/ppp/ppp.linkup.sample állományokban a pmdemand bejegyzést nézzük meg. A bejövõ hívások fogadása PPP bejövõ hívások fogadása Amikor egy helyi hálózathoz csatlakozó gépen akarjuk a ppp programot beállítani a bejövõ hívások fogadására, akkor azt is el kell döntenünk, hogy engedélyezzük-e a csomagok továbbküldését a belsõ hálózat felé. Amennyiben igen, akkor a becsatlakozó gépenek a belsõ hálózatunkon ki kell osztani egy külön címet és az /etc/ppp/ppp.conf állományban, és meg kell adnunk az enable proxy parancsot. Emellett még az /etc/rc.conf állományban se feleljtsük el megadni a következõ sort: gateway_enable="YES" Melyik getty? A &os; beállítása betárcsázós kapcsolatokhoz nagyon jól bemutatja a betárcsázós szolgáltatások beállítását a &man.getty.8; segítségével. A getty helyett egyébként az mgetty, a getty egy ügyesebb változata is használható, ami kifejezetten a betárcsázós vonalakhoz készült. A mgetty használatának többek közt az egyik elõnye, hogy aktívan tartja a kapcsolatot a modemekkel, tehát hogy ha az /etc/ttys állományban letiltjuk a modemet, akkor nem is fog válaszolni a hívásokra. Emellett az mgetty késõbbi változatai (a 0.99 beta változatától kezdve) még a PPP folyamok automatikus észlelését is támogatják, ezáltal a kliensek szkriptek nélkül is képesek elérni a szerverünket. Ha errõl többet akarunk megtudni, akkor az mgetty paranccsal kapcsolatban olvassuk el Az mgetty és az AutoPPP címû szakaszt. A <application>PPP</application> engedélyei A ppp parancsot általában root felhasználóként kell futtatni. Ha viszont a ppp parancsot tetszõleges felhasználóval akarjuk szerver módban futtatni az iméntiek szerint, akkor ahhoz fel kell vennünk az /etc/group állományban szereplõ network csoportba. Ezeken kívül még az allow paranccsal is engedélyeznünk kell konfigurációs állomány egy vagy több részének elérését is: allow users fred mary Ha ezt a parancsot a default bejegyzésnél adjuk meg, akkor az így megadott felhasználók mindenhez hozzá tudnak férni. PPP shellek a dinamikus IP-címek használóinak PPP shellek Hozzunk létre egy /etc/ppp/ppp-shell nevû állományt, amelyben a következõk szerepelnek: #!/bin/sh IDENT=`echo $0 | sed -e 's/^.*-\(.*\)$/\1/'` CALLEDAS="$IDENT" TTY=`tty` if [ x$IDENT = xdialup ]; then IDENT=`basename $TTY` fi echo "PPP for $CALLEDAS on $TTY" echo "Starting PPP for $IDENT" exec /usr/sbin/ppp -direct $IDENT Ez a szkript legyen végrehajtható. Ezután az alábbi paranccsal ppp-dialup néven készítsünk egy szimbolikus linket erre a szkriptre: &prompt.root; ln -s ppp-shell /etc/ppp/ppp-dialup Ez a szkript lesz az összes betárcsázó felhasználónk shellje. A most következõ példa az /etc/passwd állományban szereplõ, pchilds nevû PPP felhasználó bejegyzését mutatja be (ne felejtsük el, hogy soha ne közvetlenül szerkesszük a jelszavakat tároló állományt, hanem a &man.vipw.8; segítségével). pchilds:*:1011:300:Peter Childs PPP:/home/ppp:/etc/ppp/ppp-dialup Hozzunk létre egy /home/ppp nevû könyvtárat a következõ bárki által olvasható 0 byte-os állományokkal: -r--r--r-- 1 root wheel 0 May 27 02:23 .hushlogin -r--r--r-- 1 root wheel 0 May 27 02:22 .rhosts Ezek hatására az /etc/motd állomány tartalma nem jelenik meg. PPP shellek a statikus IP-címek használóinak PPP shellek Az iméntiekhez hasonló módon készítsük el a ppp-shell állományt, és mindegyik statikus IP-vel rendelkezõ hozzáféréshez csináljunk egy szimbolikus linket a ppp-shell szkriptre. Például, ha három betárcsázós ügyfelünk van, fred, sam és mary, feléjük 24 bites CIDR hálózatokat közvetítünk, akkor a következõket kell begépelnünk: &prompt.root; ln -s /etc/ppp/ppp-shell /etc/ppp/ppp-fred &prompt.root; ln -s /etc/ppp/ppp-shell /etc/ppp/ppp-sam &prompt.root; ln -s /etc/ppp/ppp-shell /etc/ppp/ppp-mary A fentebb szereplõ betárcsázós felhasználók eléréseihez tartozó shelleket állítsuk be az itt létrehozott szimbolikus linkekre (így tehát mary shellje az /etc/ppp/ppp-mary lesz). A <filename>ppp.conf</filename> beállítása a dinamikus IP-címek használóinak Az /etc/ppp/ppp.conf állományban a következõ sorok valamelyikének kellene szerepelnie: default: set debug phase lcp chat set timeout 0 ttyd0: set ifaddr 203.14.100.1 203.14.100.20 255.255.255.255 enable proxy ttyd1: set ifaddr 203.14.100.1 203.14.100.21 255.255.255.255 enable proxy A bentebb kezdett sorokat mi is kezdjünk bentebb. A default: szakasz minden kapcsolat esetén betöltõdik. Az /etc/ttys állományban engedélyezett mindegyik betárcsázós vonal létrehoz a fenti ttyd0: szakaszhoz hasonló bejegyzést. Minden vonal kap egy egyedi IP-címet a dinamikus felhasználók számára szánt címtartományból. A <filename>ppp.conf</filename> beállítása a statikus IP-vel rendelkezõk számára A /usr/share/examples/ppp/ppp.conf állományban szereplõ tartalom mellett az összes statikus kiosztású IP-címmel rendelkezõ betárcsázó felhasználóhoz még hozzá kell tennünk egy szakaszt. A példánkban ezek továbbra is fred, sam és mary. fred: set ifaddr 203.14.100.1 203.14.101.1 255.255.255.255 sam: set ifaddr 203.14.100.1 203.14.102.1 255.255.255.255 mary: set ifaddr 203.14.100.1 203.14.103.1 255.255.255.255 Amennyiben szükséges, az /etc/ppp/ppp.linkup tartalmazhat további útválasztási információkat is az egyes statikus IP-címmel rendelkezõ felhasználókhoz. A lentebb bemutatott sor a kliens ppp összekötettésén keresztül vesz fel egy útvonalat a 203.14.101.0/24 hálózat felé. fred: add 203.14.101.0 netmask 255.255.255.0 HISADDR sam: add 203.14.102.0 netmask 255.255.255.0 HISADDR mary: add 203.14.103.0 netmask 255.255.255.0 HISADDR Az <command>mgetty</command> és az AutoPPP mgetty AutoPPP LCP Ha az mgetty programot az AUTO_PPP beállítással fordítjuk le, akkor azzal az mgetty képessé válik a PPP kapcsolatok LCP fázisát észlelni és magától létrehozni hozzá egy ppp shellt. Mivel az alapértelmezett név/jelszó páros azonban ilyenkor nem jelenik meg, a felhasználókat a PAP vagy a CHAP protokollon keresztül lehet hitelesíteni. Ez a szakasz most feltételezi, hogy a sikeresen beállítottuk, lefordítottuk és telepítettük az mgetty valamelyik (0.99 béta vagy késõbbi) változatát az AUTO_PPP opció engedélyezésével. Az /usr/local/etc/mgetty+sendfax/login.config állományban ne felejtsük ellenõrizni, hogy szerepel a következõ: /AutoPPP/ - - /etc/ppp/ppp-pap-dialup Ezzel utasítjuk az mgetty programot arra, hogy az észlelt PPP kapcsolatokhoz futtassa le a ppp-pap-dialup szkriptet. Hozzunk létre az /etc/ppp/ppp-pap-dialup nevû állományt, amelyben majd a következõk fognak szerepelni (az állomány legyen végrehajtható): #!/bin/sh exec /usr/sbin/ppp -direct pap$IDENT Az /etc/ttys állományban engedélyezett összes betárcsázós vonalhoz készítsük el a megfelelõ bejegyzést az /etc/ppp/ppp.conf állományban. Ezek remekül meg fognak férni az imént készített definíciókkal. pap: enable pap set ifaddr 203.14.100.1 203.14.100.20-203.14.100.40 enable proxy Minden olyan felhasználónak, aki ezzel a módszerrel jelentkezik be, szüksége lesz egy név/jelszó kombinációra az /etc/ppp/ppp.secret állományban, vagy az alábbi beállítás megadásával választhatjuk azt is, hogy a felhasználókat az /etc/passwd állományon keresztül a PAP protokoll segítségével azonosítjuk. enable passwdauth Ha statikus IP-címet akarunk kiosztani némely felhasználóknak, akkor az /etc/ppp/ppp.secret állományban ezt megadhatjuk a harmadik paraméternek. Errõl bõvebben a /usr/share/examples/ppp/ppp.secret.sample állományban láthatunk példát. A Microsoft kiterjesztései DNS NetBIOS PPP Microsoft kiterjesztések A PPP úgy is beállítható, hogy kérésre DNS és NetBIOS típusú névfeloldáshoz is szolgáltasson információkat. A PPP 1.x változatával úgy lehet engedélyezni ezeket a kiterjesztéseket, ha az /etc/ppp/ppp.conf állomány megfelelõ részeibe felvesszük a következõ sorokat: enable msext set ns 203.14.100.1 203.14.100.2 set nbns 203.14.100.5 A PPP második és késõbbi változataiban pedig: accept dns set dns 203.14.100.1 203.14.100.2 set nbns 203.14.100.5 Ezzel a kliens megkapja az elsõdleges és másodlagos névszerverek címeit, valamint a NetBIOS névszervert. Ha a második és az azt követõ verziókban a set dns sort elhagyjuk, akkor a PPP az /etc/resolv.conf állományban található értékeket fogja használni. A PAP és CHAP hitelesítés PAP CHAP Egyes internet-szolgáltatók úgy állítják be a rendszerüket, hogy a kapcsolat felépítése során a hitelesítés a PAP vagy CHAP mechanizmusok valamelyikével történik. Ilyenkor a szolgáltató nem egy login: sorral fogja bekérni a szükséges adatokat, hanem közvetlenül a PPP kapcsolatot kezdi el használni. A PAP nem olyan biztonságos, mint a CHAP, de itt a biztonság nem is annyira fontos, mivel a jelszavak, amelyeket ugyan a PAP titkosítatlan formában küld tovább, csak egy soros vonalon haladnak át. A rossz indulatú támadók itt nem sok mindent tudnak lehallgatni. A PPP statikus IP-címmel és a PPP dinamikus IP címmel címû szakaszokhoz képest a következõ módosításokat kell elvégeznünk: 13 set authname AFelhasználóiNevem 14 set authkey AJelszavam 15 set login 13. sor: Ebben a sorban adjuk meg a PAP/CHAP felhasználói nevünket, amelyet AFelhasználóiNevem helyett kell beírni. 14. sor: jelszó Ebben a sorban adjuk meg a PAP/CHAP jelszavunkat, AJelszavam helyett. Szándénkunk egyértelmûsítése érdekében ezek mellett még egy további sort is érdemes felvennünk, tehát: 16 accept PAP vagy 16 accept CHAP Alapértelmezés szerint a PAP és CHAP is egyaránt elfogadott. 15. sor: A PAP és CHAP alkalmazásakor általában nem is kell bejelentkeznünk a szolgáltató szerverére. Ezért a set login parancsnál használt karakterláncot le is kell tiltanunk. A <command>ppp</command> beállításainak megváltoztatása menet közben A háttérben futó ppp programhoz menet közben is tudunk beszélni, de csak olyankor, amikor az ehhez szükséges portot megadtuk. Ezt úgy tudjuk megtenni, ha beállítások közé felvesszük az alábbit: set server /var/run/ppp-tun%d DiagnosticPassword 0177 Így a PPP az elõre megadott &unix; tartománybeli socketen keresztül fogja várni a kapcsolódásunkat, és a konkrét hozzáféréshez jelszót kér. A névben szereplõ %d a használatban levõ tun eszköz sorszámát jelöli. Miután a csatlakozás beállítódott, a szkriptekben a &man.pppctl.8; program használható a futó program vezérléséhez. A PPP hálózati címfordítási képességének kihasználása PPPNAT A PPP képes a rendszermag rásegítése nélkül képes hálózati címfordítást végezni. Ezt a lehetõséget a következõ sor hozzáadásával tudjuk aktiválni az /etc/ppp/ppp.conf állományban: nat enable yes A PPP-be épített hálózati címfordítás a -nat parancssori paraméterrel is bekapcsolható. Az /etc/rc.conf állományban is található hozzá egy ppp_nat változó, amely alapértelmezés szerint engedélyezett. Amikor használjuk ezt a lehetõséget, az /etc/ppp/ppp.conf állományban a következõ opciókkal engedélyezhetjük a bejövõ kapcsolatok továbbítását: nat port tcp 10.0.0.2:ftp ftp nat port tcp 10.0.0.2:http http vagy egyáltalán ne bízzunk meg a külvilágban: nat deny_incoming yes A rendszer végsõ beállítása PPP beállítása Mostanra ugyan már beállítottuk a ppp programot, azonban még néhány dolgot be kell állítanunk, mielõtt ténylegesen nekilátnánk használni. Ezek mindegyike az /etc/rc.conf állomány módosítását igényli. Az állományt fentrõl lefelé fogjuk feldolgozni, de elõtte ne felejtsünk el értéket adni a hostname= változónak, például: hostname="ize.minta.com" Amennyiben a szolgáltatónk statikus IP-címet és nevet biztosít számunkra, az lesz a legjobb, ha itt a tõle kapott nevet adjuk meg. Keressük meg a network_interfaces változót. Ha a rendszerünkben kérésre akarjuk tárcsázni a szolgáltatónkat, akkor a tun0 eszközt mindenképpen vegyük fel az értékébe, minden más esetben pedig távolítsuk el. network_interfaces="lo0 tun0" ifconfig_tun0= Az ifconfig_tun0 változónak üres értéket kell megadnunk, és létre kell hoznunk egy /etc/start_if.tun0 nevû állományt. Ebben a következõ sornak kell szerepelnie: ppp -auto arendszerem Ez a szkript a hálózat beállításakor fut le, és a ppp démont automatikus módban indítja el. Ha az adott gép egy helyi hálózat átjárója is egyben, akkor az kapcsolót is érdemes megadnunk mellette. A pontosabb részletek tekintetében olvassuk el a megfelelõ man oldalt. Az /etc/rc.conf állományban a NO érték megadásával tiltsuk le az útválasztást végzõ program használatát: router_enable="NO" routed Fontos, hogy a routed démon ne induljon el, mivel routed hajlamos törölni a ppp által létrehozott alapértelmezett útválasztási bejegyzéseket. Ezenkívül még a sendmail_flags változóról szóló sorból is érdemes kivenni a opciót, máskülönben a sendmail minden mûvelet megkezdése elõtt nekiáll felderíteni a hálózatot, és ezzel megindítja a tárcsázást. Próbáljuk meg így átírni az értékét: sendmail_flags="-bd" sendmail Ezért cserébe viszont a sendmail programot a ppp kapcsolat létrejöttekor mindig utasítanunk kell, hogy újból ellenõrizze a levelezési sort. Ezt a következõk begépelésével érhetjük el: &prompt.root; /usr/sbin/sendmail -q Ugyanezt automatikusan is meg tudjuk tenni a !bg paranccsal a ppp.linkup állományban: 1 szolgaltato: 2 delete ALL 3 add 0 0 HISADDR 4 !bg sendmail -bd -q30m SMTP Ha nem felelne meg ez a megoldás, akkor egy dfilter is beállítható az SMTP forgalom szûrésére. A példák között megtaláljuk ennek pontos minkéntjét. Ezután már csak a gépünk újraindítása maradt hátra. Az újraindítás után már be is gépelhetjük: &prompt.root; ppp ahol a dial szolgaltato parancs kiadásával meg tudjuk kezdeni a PPP kapcsolat felépítését, vagy a ppp programot megkérhetjük arra, hogy automatikusan kezdje el, amint van kimenõ forgalom (és nem készítettük el a start_if.tun0 szkriptet). Ekkor gépeljük be ezt: &prompt.root; ppp -auto szolgaltato Összefoglalás Gyorsan foglaljuk össze, hogy az ppp beállításához milyen lépések megtétele szükséges az elsõ alkalommal: A kliens oldalán: Gyõzõdjünk meg róla, hogy a tun eszköz benne van a rendszermagban. Ellenõrizzük, hogy a tunN eszközhöz tartozó állomány rendelkezésre áll a /dev könyvtárban. Hozzunk létre egy bejegyzést az /etc/ppp/ppp.conf állományban. A pmdemand példából a legtöbb szolgáltató esetében ki tudunk indulni. Ha dinamikus IP-címet kapunk, akkor az /etc/ppp/ppp.linkup állományba is vegyünk fel egy bejegyzést. Frissítsük az /etc/rc.conf állományunkat. Ha igény szerint akarunk tárcsázni, akkor hozzunk létre start_if.tun0 néven egy szkriptet. A szerver oldalán: Gondoskodjunk róla, hogy a tun eszköz támogatása szerepel rendszermagban. Gyõzõdjünk meg róla, hogy a tunN eszköz megtalálható a /dev könyvtárban. Az /etc/passwd állományban (a &man.vipw.8; program használatával) hozzunk létre bejegyzéseket. A felhasználók könyvtáraiban hozzunk létre egy olyan profilt, amely ppp -direct direct-server vagy egy ehhez hasonló parancsot futtat le. Az /etc/ppp/ppp.conf állományban adjuk meg egy bejegyzést. A direct-server példa ehhez egy remek alapot biztosít. Az /etc/ppp/ppp.linkup állományban hozzunk létre egy bejegyzést. Frissítsük az /etc/rc.conf állományunkat. Gennady B. Sorokopud Egyes részeit készítette: Robert Huff A rendszerszintû PPP alkalmazása A rendszerszintû PPP beállítása PPP rendszer PPP Mielõtt a gépünkön nekikezdünk a PPP beállításának, ellenõrizzük, hogy a pppd megtalálható a /usr/sbin könyvtárban és az /etc/ppp könyvtár létezik. A pppd két módban képes mûködni: kliensként — a gépünket soros vonali vagy modemes PPP kapcsolaton keresztül csatlakoztatjuk a külvilághoz PPP szerver szerverként — a számítógépünk egy hálózat része, ahol a többieket a PPP használatával kapcsoljuk össze Mind a két esetben egy konfigurációs állomány tartalmát kell összeállítanunk (ez az /etc/ppp/options vagy a ~/.ppprc, ha a gépünkön több felhasználó is PPP-t akar használni). Egy modemes vagy soros vonali szoftverre is szükségünk lesz (ez többnyire a comms/kermit), amellyel távoli gépeket tudunk felhívni és feléjük kapcsolatot felépíteni. Trev Roydhouse Az alapjául szolgáló információkat adta: A <command>pppd</command> mint kliens PPP kliens Cisco A most következõ /etc/ppp/options állománnyal egy Cisco terminál szerverhez tudunk kapcsolódni egy PPP vonalon keresztül. crtscts # a hardveres forgalomirányítás engedélyezése modem # modem vezérlõvonal noipdefault # a távoli PPP szervernek kell IP-címet adnia # ha az IPCP alapú egyeztetés során a távoli gép nem küld # nekünk IP-címet, akkor vegyük ki ezt a beállítást passive # LCP csomagokat várunk domain ppp.ize.com # ide írjuk be a hálózati nevünket :távoli_ip # ide kell írni a távoli PPP szerver IP-címét # a PPP kapcsolaton keresztül erre fogjuk továbbküldeni a csomagokat # ha nem adtuk meg "noipdefault" beállítást, akkor ezt a sort # írjuk át helyi_ip:távoli_ip alakúra defaultroute # adjuk meg ezt a sort is, ha a PPP szerverünket egyben az # alapértelmezett átjárónak is be akarjuk állítani Így kapcsolódunk: Kermit modem Tárcsázzuk a távoli gépet a Kermit (vagy bármilyen más modemes program) elindításával, majd adjuk meg a felhasználói nevünket és jelszavunkat (vagy bármi mást, amivel a távoli gépen engedélyezni tudjuk a PPP használatát). Lépjünk ki a Kermit programból (anélkül, hogy bontanánk a vonalat). Írjuk be a következõket: &prompt.root; /usr/src/usr.sbin/pppd.new/pppd /dev/tty01 19200 Ne felejtsük el megadni a megfelelõ sebességet és eszközt. A számítógépünk most már PPP-n keresztül csatlakozik. Ha valamilyen okból nem sikerülne felépíteni a kapcsolatot, akkor vegyük fel a beállítást is az /etc/ppp/options állományba, majd a konzolra érkezõ üzenetek segítségével próbáljuk meg felderíteni a probléma okát. Az alábbi /etc/ppp/pppup szkript mind a három fázist automatikussá teszi: #!/bin/sh pgrep -l pppd pid=`pgrep pppd` if [ "X${pid}" != "X" ] ; then echo 'killing pppd, PID=' ${pid} kill ${pid} fi pgrep -l kermit pid=`pgrep kermit` if [ "X${pid}" != "X" ] ; then echo 'killing kermit, PID=' ${pid} kill -9 ${pid} fi ifconfig ppp0 down ifconfig ppp0 delete kermit -y /etc/ppp/kermit.dial pppd /dev/tty01 19200 Kermit Az /etc/ppp/kermit.dial egy olyan Kermit szkript, amivel tárcsázni tudunk és a távoli gépen elvégezni az összes szükséges hitelesítést (a leírás végén találhatunk is egy ilyen szkriptet példaként). Az alábbi /etc/ppp/pppdown szkripttel tudjuk bontani a PPP vonalat: #!/bin/sh pid=`pgrep pppd` if [ X${pid} != "X" ] ; then echo 'killing pppd, PID=' ${pid} kill -TERM ${pid} fi pgrep -l kermit pid=`pgrep kermit` if [ "X${pid}" != "X" ] ; then echo 'killing kermit, PID=' ${pid} kill -9 ${pid} fi /sbin/ifconfig ppp0 down /sbin/ifconfig ppp0 delete kermit -y /etc/ppp/kermit.hup /etc/ppp/ppptest A /usr/etc/ppp/ppptest elindításával ellenõrizni tudjuk, hogy a pppd még mindig fut. Ez valahogy így néz ki: #!/bin/sh pid=`pgrep pppd` if [ X${pid} != "X" ] ; then echo 'pppd running: PID=' ${pid-NONE} else echo 'No pppd running.' fi set -x netstat -n -I ppp0 ifconfig ppp0 A vonal bontásához az /etc/ppp/kermit.hup szkriptet kell elindítanunk, amiben a következõ szerepelnek: set line /dev/tty01 ; ide írjuk be a saját modemünket set speed 19200 set file type binary set file names literal set win 8 set rec pack 1024 set send pack 1024 set block 3 set term bytesize 8 set command bytesize 8 set flow none pau 1 out +++ inp 5 OK out ATH0\13 echo \13 exit A kermit helyett a chat programot is használhatjuk: A következõ két állomány már elég egy kapcsolat létrehozásához pppd használatával: /etc/ppp/options: /dev/cuad1 115200 crtscts # a hardveres forgalomirányítás engedélyezése modem # modemes vezérlõvonal connect "/usr/bin/chat -f /etc/ppp/login.chat.script" noipdefault # a távoli PPP kiszolgálónak adnia kell egy IP-címet # ha a távoli gép nem küldi az IP-címünk az IPCP alapú egyeztetés során # akkor távolítsuk el ezt a beállítást passive # LCP csomagokat várunk domain sajat.tartomany # ide írjuk be a saját tartománynevünket : # a távoli PPP kiszolgáló IP-címét tegyük ide # ezen keresztül fogjuk továbbküldeni a PPP kapcsolaton áthaladó csomagokat # nem adtuk meg a "noipdefault" beállítást, akkor ezt # sort írjuk át helyi_ip:távoli_ip alakúra defaultroute # ez a sor akkor kell, ha a PPP szerver lesz az # alapértelmezett átjárónk is /etc/ppp/login.chat.script: A most következõt egyetlen sorba kell írnunk. ABORT BUSY ABORT 'NO CARRIER' "" AT OK ATDTtelefon.szám CONNECT "" TIMEOUT 10 ogin:-\\r-ogin: bejelentkezési-azonosító TIMEOUT 5 sword: jelszó Miután ezeket telepítettük és a megfelelõképpen módosítottuk, már csak a pppd parancsot kell kiadnunk, valahogy így: &prompt.root; pppd A <command>pppd</command> mint szerver Az /etc/ppp/options állományban nagyjából a következõknek kell szerepelnie: crtscts # hardveres forgalomirányítás netmask 255.255.255.0 # hálózati maszk (nem kötelezõ) 192.114.208.20:192.114.208.165 # a helyi és távoli gépek IP-címei # a helyi IP-nek el kell térnie az Ethernet # (vagy más egyéb) felülethez tartozó címtõl. # a távoli IP a távoli géphez rendelt IP-cím domain ppp.ize.com # a saját tartományunk passive # az LCP csomagok várása modem # modemes vonal Az alábbi /etc/ppp/pppserv szkript a pppd démont szervernek állítja be: #!/bin/sh pgrep -l pppd pid=`pgrep pppd` if [ "X${pid}" != "X" ] ; then echo 'killing pppd, PID=' ${pid} kill ${pid} fi pgrep -l kermit pid=`pgrep kermit` if [ "X${pid}" != "X" ] ; then echo 'killing kermit, PID=' ${pid} kill -9 ${pid} fi # reset ppp interface ifconfig ppp0 down ifconfig ppp0 delete # enable autoanswer mode kermit -y /etc/ppp/kermit.ans # run ppp pppd /dev/tty01 19200 A szerver leállítására a következõ /etc/ppp/pppservdown szkriptet kell használnunk: #!/bin/sh pgrep -l pppd pid=`pgrep pppd` if [ "X${pid}" != "X" ] ; then echo 'killing pppd, PID=' ${pid} kill ${pid} fi pgrep -l kermit pid=`pgrep kermit` if [ "X${pid}" != "X" ] ; then echo 'killing kermit, PID=' ${pid} kill -9 ${pid} fi ifconfig ppp0 down ifconfig ppp0 delete kermit -y /etc/ppp/kermit.noans A következõ Kermit szkript (/etc/ppp/kermit.ans) engedélyezi vagy tiltja le a modem automatikus válaszadását. Körülbelül így épül fel: set line /dev/tty01 set speed 19200 set file type binary set file names literal set win 8 set rec pack 1024 set send pack 1024 set block 3 set term bytesize 8 set command bytesize 8 set flow none pau 1 out +++ inp 5 OK out ATH0\13 inp 5 OK echo \13 out ATS0=1\13 ; "ATS0=0\13"-ra írjuk át, ha le akarjuk tiltani az ; automatikus válaszadást inp 5 OK echo \13 exit Az /etc/ppp/kermit.dial elnevezésû szkriptet használhatjuk arra, hogy tárcsázzunk távoli gépeket és hitelesítsük magunkat rajtuk. Írjuk át az igényeinknek megfelelõen, tegyük bele a bejelentkezéshez szükséges azonosítót és jelszót, illetve a modemünk és a távoli gép válaszai szerint módosítsuk az input utasításokat. ; ; írjuk ide azt a com vonalat, amire a modemünk csatlakozik: ; set line /dev/tty01 ; ; ide kerül a modem sebessége: ; set speed 19200 set file type binary ; teljes 8 bites állomány-átvitel set file names literal set win 8 set rec pack 1024 set send pack 1024 set block 3 set term bytesize 8 set command bytesize 8 set flow none set modem hayes set dial hangup off set carrier auto ; adjuk meg a SET CARRIER utasítást is, ha kell set dial display on ; adjuk meg a SET DIAL utasítást is, ha kell set input echo on set input timeout proceed set input case ignore def \%x 0 ; a bejelentkezés számlálója goto slhup :slcmd ; tegyük a modemet parancs módba echo Tegyuk a modemet parancs modba. clear ; töröljük a be nem olvasott karaktereket a bemeneti pufferbõl pause 1 output +++ ; a Hayes-féle helyettesítési szekvenciák használata input 1 OK\13\10 ; várjuk meg az OK jelzést if success goto slhup output \13 pause 1 output at\13 input 1 OK\13\10 if fail goto slcmd ; ha a modem nem válaszol OK-val, akkor próbálkozzunk újra :slhup ; bontsuk a vonalat clear ; töröljük ki a be nem olvasott karaktereket a bemeneti pufferbõl pause 1 echo A vonal bontasa. output ath0\13 ; a kapcsolat létrejöttét jelzõ Hayes-parancs input 2 OK\13\10 if fail goto slcmd ; ha nincs OK válasz, akkor tegyük a modemet parancs módba :sldial ; tárcsázzuk a számot pause 1 echo Dialing. output atdt9,550311\13\10 ; ide írjuk a telefonszámot assign \%x 0 ; nullázzuk le az idõzítõt :look clear ; töröljük az olvasatlan karaktereket a bemeneti pufferbõl increment \%x ; számoljuk a másodperceket input 1 {CONNECT } if success goto sllogin reinput 1 {NO CARRIER\13\10} if success goto sldial reinput 1 {NO DIALTONE\13\10} if success goto slnodial reinput 1 {\255} if success goto slhup reinput 1 {\127} if success goto slhup if < \%x 60 goto look else goto slhup :sllogin ; bejelentkezés assign \%x 0 ; nullázzuk le az idõzítõt pause 1 echo A bejelentkezes keresese. :slloop increment \%x ; számoljuk a másodperceket clear ; töröljük az olvasatlan karaktereket a bemeneti pufferbõl output \13 ; ; ide írjuk be a várható bejelentkezési sablont: ; input 1 {Felhasznaloi nev: } if success goto sluid reinput 1 {\255} if success goto slhup reinput 1 {\127} if success goto slhup if < \%x 10 goto slloop ; tízszer próbálkozzunk a bejelentkezéssel else goto slhup ; 10 sikertelen próbálkozás után bontsuk a vonalat és kezdjük újra :sluid ; ; ide írjuk be a felhasználói azonosítónkat: ; output ppp-login\13 input 1 {Jelszo: } ; ; ide tegyük a hozzátartozó jelszót: ; output ppp-password\13 input 1 {Atvaltas SLIP modba.} echo quit :slnodial echo \7Nincs vonal. Ellenorizzuk a telefonvonalat!\7 exit 1 ; local variables: ; mode: csh ; comment-start: "; " ; comment-start-skip: "; " ; end: Tom Rhodes Készítette: <acronym>PPP</acronym> kapcsolatok hibaelhárítása PPP hibaelhárítás Ebben a szakaszban összefoglalunk néhány olyan problémát, ami a PPP modemen keresztüli használata során keletkezhet. Például pontosan tisztában kell lennünk azzal, hogy a tárcsázott rendszer milyen adatokat és hogyan fog tõlünk bekérni. Egyes szolgáltatók egy ssword promptot, míg mások egy password promptot adnak. Ha a ppp szkript nem illeszkedik ezekhez az elvárásokhoz, akkor nem tudunk bejelentkezni. A ppp csatlakozások nyomonkövetésének egyik leggyakoribb módja a manuális kapcsolódás. A következõkben ezért a manuális csatlakozásokra vonatkozó legszükségesebb ismereteket mutatjuk be lépésrõl lépésre. Az eszközleírók ellenõrzése Ha újrakonfiguráltuk a rendszermagunkat, akkor minden bizonnyal még emlékszünk a sio eszközre. Ha nem készítettünk volna új rendszermagot, ne aggódjunk. Egyszerûen csak a dmesg parancs kimenetében keressük meg a modemes eszközhöz tartozó adatokat: &prompt.root; dmesg | grep sio Ennek eredményeképpen kapunk egy rövid összefoglalást a sio típusú eszközökrõl. Ezek lesznek a számunkra fontos COM portok. Amennyiben a modemünk egy szabványos soros portként mûködik, akkor a sio1 vagy COM2 néven kell keresnünk. Ha megtaláltuk, akkor nem kell új rendszermagot fordítanunk. Amikor a soros vonali modemünk a sio1 vagy COM2 porton csatlakozik DOS-ban, akkor itt a neki megfelelõ eszköz a /dev/cuad1 lesz. Kapcsolódás manuálisan A ppp kézi irányításával gyorsan, egyszerûen és minden fájdalomtól mentesen tudunk csatlakozni az internethez, de olyankor is hasznos, ha ki akarjuk deríteni, hogy az internet-szolgáltatónk milyen módon kezeli a kliensek ppp csatlakozásait. Nos, akkor ehhez indítsuk is el a PPP alkalmazást a paranccsorból. Az alábbi példákban rendre a pelda névvel hivatkozunk a PPP-t mûködtetõ gépre. A ppp tehát a ppp parancs begépelésével indítható: &prompt.root; ppp Ezzel elindítottuk a ppp programot. ppp ON pelda> set device /dev/cuad1 Beállítjuk a modemünket, ami ebben az esetben a cuad1. ppp ON pelda> set speed 115200 Beállítjuk a csatlakozás sebességét, ami ebben az esetben 115 200 kbit/mp. ppp ON pelda> enable dns Azt mondjuk a ppp programnak, hogy állítsa be a névfeloldót és az /etc/resolv.conf állományt egészítse ki a megfelelõ névszerverekkel. Ha a ppp nem képes megállapítani a gépünk nevét, akkor késõbb ezt még kézzel is be tudjuk állítani. ppp ON pelda> term Váltsunk terminál módba, így mi irányítjuk a modemet. deflink: Entering terminal mode on /dev/cuad1 type '~h' for help at OK atdt123456789 Az at paranccsal hozzuk alaphelyzetbe a modemet, majd a atdt paranccsal és egy telefonszám megadásával megkezdjük a szolgáltató tárcsázását. CONNECT Ezzel jelez vissza a kapcsolódás megkezdésérõl. Ha itt bármilyen hardvertõl független csatlakozási probléma merülne fel, akkor ezen a ponton tudunk ellene tenni valamit. ISP Login:felhasznalonev Itt kell megadnunk a felhasználói nevünket, ami megegyezik a szolgáltató által adott azonosítónkkal. ISP Pass:jelszo Ezúttal a jelszavunkat kell megadni, amit szintén a szolgáltató bocsátott rendelkezésünkre az azonosító mellett. Akárcsak amikor bejelentkezünk a &os;-be, itt sem fog látszódni a jelszavunk. Shell or PPP:ppp Szolgáltatótól függõen elõfordulhat, hogy ez a sor soha nem is jelenik meg. Itt kérdezik meg, hogy a szolgáltatónál egy shellt akarunk használni, vagy csak elindítani egy ppp kapcsolatot. Ebben a példában természetesen a ppp opciót választjuk, mivel egy internet-elõfizetés birtokosai vagyunk. Ppp ON pelda> Figyeljük meg, hogy az elsõ nagybetûssé vált. Ezzel jelzi a program, hogy sikeresen csatlakoztunk a szolgáltatónkhoz. PPp ON pelda> Sikeresen azonosítottuk magunkat a szolgáltató felé és várjuk az IP-címünket. PPP ON pelda> Megkaptuk az IP-címünket és ezzel sikeresen felépült a kapcsolat. PPP ON pelda>add default HISADDR Itt adjuk hozzá az alapértelmezett útvonalat, amire mindenképpen szükségünk van ahhoz, hogy a külvilággal is kapcsolatban tudjunk lépni, mivel jelenleg csak a vonal másik végén lévõ gépet érjük el. Ha ezt bizonyos, már meglevõ útvonalak miatt nem sikerül felvenni, akkor az elé tegyünk egy ! jelet. Ezt viszont a kapcsolat felépítése elõtt is megtehetjük, így menet közben az új útvonalat felveszi a többi közé. Ha eddig minden remekül ment, akkor ezen ponton már egy élõ internet-kapcsolattal rendelkezünk, és a programot a CTRLz lenyomásával a háttérbe is tehetjük. Ha a PPP felirat ismét a ppp feliratra váltana, akkor az arra utal, hogy elvesztettük a kapcsolatot. Erre nem árt figyelni, mivel ezzel jelzi az aktuális kapcsolat állapotát. A nagybetûs P-k jelölik, hogy az adott szinten megvan a kapcsolat a szolgáltató felé, a kisbetûs p-k pedig arra utalnak, hogy azon a szinten a kapcsolat valamiért megszûnt. A ppp csak ezt a két állapotot ismeri. Nyomkövetés Ha közvetlen vonalunk van és mégsem sikerül kapcsolatot létesíteni, akkor tiltsuk le a hardveres CTS/RTS forgalomirányítást a paranccsal. Ez leginkább akkor fordul elõ, ha csatlakoztunk egy olyan terminálszerverhez, amely valamennyire képes kezelni a PPP kapcsolatokat, de a PPP megáll, mikor adatot próbál írni a kommunikációs csatornára, mivel arra a CTS (Clear To Send — lehet küldeni) jelzésre vár, amely soha nem fog megérkezni. Ha mégis ezt a beállítást akarjuk használni, akkor a beállításra is szükségünk lesz, mivel ez kell bizonyos karakterek hardverfüggõ átküldésének felülbírálásához, legtöbb esetben a XON/XOFF miatt. A &man.ppp.8; man oldalon találhatunk errõl és ennek használatáról részletesebb leírást. Ha egy régebbi gyártmányú modemünk van, akkor a beállítás alkalmazása is javasolt. Alapértelmezés szerint ugyanis nincs paritás, de a régebbi modemek és (a forgalom növekedésével) egyes szolgáltatók még használják hibaellenõrzésre. Ha Compuserve elõfizetésünk van, mindenképpen kapcsoljuk be. Amikor a PPP nem tér vissza parancs módba, akkor gyaníthatóan az egyeztetésben lesz valahol probléma, mivel a szolgáltató a kliensüktõl várja a kezdeményezését. Ezen a ponton a ~p paranccsal utasíthatjuk a ppp programot a konfigurációs információk átküldésének megkezdésére. Ha egyáltalán nem kapunk promptot a bejelentkezéshez, akkor nagy a alószínûsége, hogy az iménti &unix; stílusú hitelesítés helyett PAP vagy CHAP protokollt kell használnunk. A PAP vagy CHAP használatához mindössze a következõ beállításokat kell megadnunk PPP programnak a terminál mód aktiválása elõtt: ppp ON pelda> set authname felhasznalonev ahol a felhasznalonev helyett a szolgáltatótól kapott azonosítót kell beírnunk. ppp ON pelda> set authkey jelszo ahol a jelszo helyett a szolgáltatótól kapott jelszót kell megadnunk. Ha sikeresen csatlakoztunk, de még nem találunk semmilyen tartománynevet, akkor a &man.ping.8; és IP-cím segítségével tudjuk megvizsgálni, hogy mûködõképes-e a kapcsolat. Ha 100 százalékos (100%) csomagvesztést (packet loss) tapasztalunk, akkor szinte biztos, hogy nincs meg az alapértelmezett útvonal. Nézzük meg újra, hogy az beállítást megadtuk-e a kapcsolat felépítésekor. Ha viszont már el tudunk érni egy távoli IP-címet, akkor nagyon valószínû, hogy az /etc/resolv.conf állományba nem került bele a megfelelõ névfeloldó címe. Az említett állománynak valahogy így kellene kinéznie: domain minta.com nameserver x.x.x.x nameserver y.y.y.y Ahol az x.x.x.x és y.y.y.y címeket a szolgáltatónk névszervereinek címével kell behelyettesíteni. Ez nem minden esetben található meg az elõfizetõi szerzõdésben, de ha felhívjuk a szolgáltatónkat, akkor minden bizonnyal elárulják ezeket a címeket. A &man.syslog.3; is alkalmas a PPP kapcsolatok naplózására. Ehhez csupán ennyit kell megadnunk az /etc/syslog.conf állományban: !ppp *.* /var/log/ppp.log A legtöbb esetben ez a lehetõség már eleve adott. Jim Mock Készítette (a http://node.to/freebsd/how-tos/how-to-freebsd-pppoe.html alapján): A PPP használata Ethernet felett (PPPoE) PPP over Ethernet PPPoE PPP, over Ethernet Ebben a szakaszban azt ismertetjük, hogyan állítsuk be a PPP-t Ethernet felett (PPP over Ethernet, PPPoE). A rendszermag beállítása A PPPoE mûködéséhez most már semmilyen módosításra nincs szükség a rendszermag beállításaiban. Amennyiben a hozzá szükséges Netgraph támogatás nem található a rendszermagban, akkor azt a ppp önmûködõen betölti. A <filename>ppp.conf</filename> beállítása Íme egy mûködõ ppp.conf állomány: default: set log Phase tun command # itt akár egy részletesebb naplózást is be tudunk állítani set ifaddr 10.0.0.1/0 10.0.0.2/0 a_szolgaltato_neve: set device PPPoE:xl1 # az xl1 helyére írjuk be a saját Ethernet eszközünket set authname FELHASZNALONEV set authkey JELSZO set dial set login add default HISADDR A <application>ppp</application> futtatása root felhasználóként adjuk ki az alábbi parancsot: &prompt.root; ppp -ddial a_szolgaltato_neve A <application>ppp</application> indítása a rendszerindítás során Az /etc/rc.conf állományba vegyük fel a következõket: ppp_enable="YES" ppp_mode="ddial" ppp_nat="YES" # csak akkor, ha címfordítás kell a helyi hálózaton, máskülönben "NO" ppp_profile="a_szolgaltato_neve" A szolgáltatási címkék használata Bizonyos esetekben szolgáltatási címkét (service tag) is használnunk kell a kapcsolat létrehozásához. A szolgáltatási címkék segítségével tudjuk megkülönböztetni az adott hálózaton elérhetõ különbözõ PPPoE szervereket. A szolgáltatótól kapott dokumentációban szerepelnie kell minden ehhez kapcsolódó információnak. Amennyiben nem találjuk, érdeklõdjünk a szolgáltatónál. Utolsó reményként megpróbálhatjuk a Portgyûjteményben található Roaring Penguin PPPoE nevû program által javasolt módszert. Ennél vegyük azonban számításba, hogy félre tudja programozni a modemünket, amitõl akár használhatatlanná is válhat, ezért kétszer is gondoljuk meg, mielõtt használni kezdjük. Egyszerûen csak tegyük fel a szolgáltatótól a modemünk mellé kapott szoftvert. Ezután lépjünk be a program System menüjébe. Itt kell lennie a megfelelõ profilnak, ami általában az ISP. A profil neve (a szolgáltatás címkéje) a ppp.conf állományban a PPPoE bejegyzés részeként jelenik meg a set device parancsban (ennek pontos részleteit lásd a &man.ppp.8; man oldalon). Tehát nagyjából így néz ki: set device PPPoE:xl1:ISP Az xl1 eszköz nevét ne felejtsük el a megfelelõ Ethernet kártyához tartozó eszköz nevére kicserélni. Az ISP helyett pedig írjuk be az imént kiderített profil nevét. A témával kapcsolatban az alábbi helyeken találhatunk további információkat: Cheaper Broadband with FreeBSD on DSL, írta: Renaud Waldura (angolul). Nutzung von T-DSL und T-Online mit FreeBSD, írta: Udo Erdelhoff (németül). PPPoE és a &tm.3com; <trademark class="registered">HomeConnect</trademark> ADSL Modem Dual Link Ez a modem nem felel meg az RFC 2516 elõírásainak (A Method for transmitting PPP over Ethernet (PPPoE), írta: L. Mamakos, K. Lidl, J. Evarts, D. Carrel, D. Simone és R. Wheeler). Helyette az Ethernet keretekben eltérõ csomagtípus kódokat használ. A 3Com-nál panaszkodjunk, ha szerintünk is be kellene tartaniuk a PPPoE specifikációját. A &os; is csak akkor lesz képes együttmûködni ezzel az eszközzel, ha beállítjuk a megfelelõ sysctl változót. Ezt a rendszerindítás során automatikusan meg tudjuk tenni az /etc/sysctl.conf módosításával: net.graph.nonstandard_pppoe=1 vagy közvetlenül az alábbi paranccsal: &prompt.root; sysctl net.graph.nonstandard_pppoe=1 Sajnos, mivel ez egy rendszerszintû beállítás, ezért a &tm.3com; HomeConnect ADSL Modem és más normális PPPoE kliens vagy szerver egyszerre nem használható. <application>PPP</application> ATM felett (PPPoA) PPP over ATM PPPoA PPP, over ATM Most a PPP ATM feletti (PPP over ATM, PPPoA) beállítását fogjuk bemutatni. A PPPoA az európai DSL szolgáltatók körében igen nagy népszerûségnek örvend. PPPoA használata az Alcatel &speedtouch; USB-vel Az ilyen eszközökhöz tartozó PPPoA támogatás a &os;-ben portként áll rendelkezésre, mivel az ehhez szükséges firmware csak az Alcatel licencelési feltételei szerint terjeszthetõ, ezért nem lehet része az alap &os; rendszernek. A szoftver telepítéséhez ezért a Portgyûjteményt kell használnunk. Telepítsük a net/pppoa portot és kövessük a mellékelt utasításokat. Sok más USB-s eszközhöz hasonlóan az Alcatel &speedtouch; USB-nek a gépünkrõl kell letöltenie a mûködéséhez szükséges firmware-t. Ez a folyamat &os; alatt automatizálható, tehát ez a másolás minden esetben megtörténik, amikor az eszközt az USB portra csatlakoztatjuk. Ehhez az /etc/usbd.conf állományba a következõ adatokat kell beletennünk. Az állományt root felhasználóként tudjuk csak szerkeszteni. device "Alcatel SpeedTouch USB" devname "ugen[0-9]+" vendor 0x06b9 product 0x4061 attach "/usr/local/sbin/modem_run -f /usr/local/libdata/mgmt.o" Az usbd, vagyis az USB démon engedélyezéséhez az /etc/rc.conf állományba tegyük bele az alábbit: usbd_enable="YES" Emellett még a ppp kapcsolatot is be tudjuk állítani az indítás során. Ehhez mindössze a következõ sort kell megadnunk az /etc/rc.conf állományban. Ismét megemlítjük, hogy ezt a mûveletet csak a root felhasználóval tudjuk végrehajtani. ppp_enable="YES" ppp_mode="ddial" ppp_profile="adsl" Ezután úgy tudjuk szóra bírni a kapcsolatot, ha a net/pppoa porthoz mellékelt ppp.conf állományt használjuk fel kiindulásként. Az mpd használata Az mpd segítségével többféle szolgáltatáshoz, köztük a PPTP-hez hozzá tudunk férni. Az mpd a Portgyûjteményben net/mpd néven található meg. Sok ADSL modemnek szüksége van egy PPTP tunnelre közte és gép között. Ilyen modem például az Alcatel &speedtouch; Home is. Elõször magát a portot kell telepítenünk, majd ezután már be tudjuk állítani az mpd-t a saját és a szolgáltatónk igényei szerint. A port a rengeteg leírással megtûzdelt minta konfigurációs állományait a PREFIX/etc/mpd/ könyvtárba teszi. Itt a PREFIX azt a könyvtárat jelöli, ahova a portok kerülnek. Ez alapból a /usr/local/. Az mpd beállításáról szóló teljes dokumentáció a telepítés után elérhetõ HTML formátumban a PREFIX/share/doc/mpd/ könyvtárban. Íme egy példa az mpd beállítására ADSL kapcsolatok esetében. Az ezzel kapcsolatos beállításaink két állományra bomlanak, melyek közül az elsõ az mpd.conf: default: load adsl adsl: new -i ng0 adsl adsl set bundle authname felhasználónév set bundle password jelszó set bundle disable multilink set link no pap acfcomp protocomp set link disable chap set link accept chap set link keep-alive 30 10 set ipcp no vjcomp set ipcp ranges 0.0.0.0/0 0.0.0.0/0 set iface route default set iface disable on-demand set iface enable proxy-arp set iface idle 0 open A felhasználói azonosító, amellyel a szolgáltató felé hitelesítjük magunkat. Az azonosítóhoz tartozó jelszó, amelyet szintén a szolgáltatól kaptunk. Az mpd.links állomány tartalmazza a felépítendõ kapcsolatra vagy kapcsolatokra vonatkozó információkat. Például az elõbbiekhez tartozó mpd.links tartalma ez: adsl: set link type pptp set pptp mode active set pptp enable originate outcall set pptp self 10.0.0.1 set pptp peer 10.0.0.138 A &os;-s számítógépünk címe, ahonnan az mpd indul. Az ADSL modemünk IP-címe. Az Alcatel &speedtouch; Home esetén ez a cím alapértelmezés szerint a 10.0.0.138. A kapcsolat ezek után pillanatok alatt felépíthetõ, ha a root felhasználóval kiadjuk a következõ parancsot: &prompt.root; mpd -b adsl A kapcsolat állapotát a következõ paranccsal tudjuk ezután ellenõrizni: &prompt.user; ifconfig ng0 ng0: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> mtu 1500 inet 216.136.204.117 --> 204.152.186.171 netmask 0xffffffff &os; alatt az mpd használata ajánlott az ADSL szolgáltatások eléréséhez. A pptpclient használata &os; alatt a net/pptpclient segítségével is tudunk PPPoA típusú szolgáltatásokhoz kapcsolódni. A net/pptpclient felhasználásával úgy tudunk DSL szolgáltatásokat elérni, ha feltelepítjük a hozzátartozó portot vagy csomagot, majd módosítjuk az /etc/ppp/ppp.conf állományt. Mind a két mûveletet csak root felhasználóként tudjuk lebonyolítani. Ehhez egy ppp.conf állományt lentebb adtunk meg. A ppp.conf állományban található további beállítási lehetõségekrõl a &man.ppp.8; man oldalon olvashatunk. adsl: set log phase chat lcp ipcp ccp tun command set timeout 0 enable dns set authname felhasználónév set authkey jelszó set ifaddr 0 0 add default HISADDR A DSL szolgáltatónktól kapott felhasználói név. Az elõfizetéshez tartozó jelszó. Mivel az elõfizetéshez tartozó jelszót a ppp.conf állományba titkosítatlan formában kell szerepeltetnünk, ezért gondoskodjunk róla, hogy senki sem képes olvasni a tartalmát. A most következõ parancsokkal beállítjuk, hogy ez az állomány csak a root felhasználó számára legyen olvasható. A részletekért lásd a &man.chmod.1; és &man.chown.8; man oldalakat. &prompt.root; chown root:wheel /etc/ppp/ppp.conf &prompt.root; chmod 600 /etc/ppp/ppp.conf Ezzel a paranccsal a DSL útválasztónk felé nyitunk egy tunnelt a PPP kapcsolathoz. Az Ethernetes DSL modemek általában egy elõre beállított helyi hálózati IP-címmel rendelkeznek, amelyhez tudunk csatlakozni. Az Alcatel &speedtouch; Home esetében ez a cím a 10.0.0.138. Az útválasztóhoz adott dokumentációban keressük meg, hogy az eszközünkhöz konkrétan milyen cím tartozik. A tunnel megnyitásához és a PPP kapcsolat megindításához a következõ parancsot kell kiadnunk: &prompt.root; pptp cím adsl Az iménti parancs végére még érdemes odatenni az et jelet (&) is, mivel így a pptp mûködését a háttérben folytatja. A parancs hatására a virtuális tunnelt megtestesítõ tun eszköz jön létre a pptp és ppp programok között. Miután visszakaptuk a parancssort, vagy a pptp program megerõsítette a kapcsolódás sikerességét, a keletkezett járatot így tudjuk ellenõrizni: &prompt.user; ifconfig tun0 tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500 inet 216.136.204.21 --> 204.152.186.171 netmask 0xffffff00 Opened by PID 918 Ha nem tudnánk valamiért csatlakozni, akkor elõször nézzük meg az útválasztónk beállításait, ami általában a telnet vagy egy böngészõ segítségével elérhetõ. Ha még mindig nem vagyunk képesek csatlakozni, akkor a pptp parancs kimenetében és ppp /var/log/ppp.log néven elérhetõ naplójában kereshetünk árulkodó nyomokat. Satoshi Asami Eredetileg készítette: Guy Helmer A hozzávalókat biztosította: Piero Serini A SLIP használata SLIP A SLIP kliensek beállítása SLIP kliens A következõkben azt mutatjuk be, hogy egy &os;-s gépet miként tudunk egy hálózaton statikus névvel beállítani a SLIP használatával. A dinamikus hálózati nevek használatakor (vagyis amikor a címünk minden egyes tárcsázáskor megváltozhat) egy valamivel bonyolultabb beállításra van szükségünk. Elõször is állapítsuk meg, hogy a modemünk melyik soros portra csatlakozik. Sokan /dev/modem néven egy szimbolikus linket hoznak létre a valódi eszközre, például a /dev/cuadN leíróra. Ennek köszönhetõen az eszköz tényleges névetõl el tudunk vonatkoztatni és soha nem kell módosítanunk semmit, ha a modemet például egy másik portra kell átraknunk. Ugyanis könnyedén kacifántossá tud válni a helyzet, amikor egyszerre kell megváltoztatnunk egy rakat dolgot az /etc könyvtárban és módosítanunk az összes .kermrc állományt! A /dev/cuad0 a COM1 port, a cuad1 a COM2 és így tovább. A rendszermag beállításait tartalmazó állományban a következõnek mindenképpen szerepelnie kell: device sl Mivel ez általában a GENERIC rendszermagban megtalálható, így ez nem okoz semmilyen gondot, kivéve, hogy ha korábban már kitöröltük. Dolgok, amiket csak egyszer kell megtenni Vegyük fel az otthoni gépünket, az átjárónkat és a névszervereket az /etc/hosts állományba. Erre álljon itt egy konkrét példa: 127.0.0.1 localhost loghost 136.152.64.181 water.CS.Example.EDU water.CS water 136.152.64.1 inr-3.CS.Example.EDU inr-3 slip-gateway 128.32.136.9 ns1.Example.EDU ns1 128.32.136.12 ns2.Example.EDU ns2 - Ehhez a &os; 5.0 elõtti változataiban - az /etc/host.conf - állományban a hosts - szónak meg kell elõznie a - bind szót. A &os; 5.0 - utáni változatai erre a célra - már az /etc/nsswitch.conf - állományt használják, - ezért az állományban szereplõ - sorban ilyenkor a - dns szó elõtt a - files szónak kell megjelennie. - Ezek nélkül mókás dolgok tudnak - történni rendszerünkben. + Figyeljünk oda, hogy az + /etc/nsswitch.conf + állományban szereplõ + szakaszban a dns + szó elõtt a files + szónak kell megjelennie. Ezek nélkül + mókás dolgok tudnak történni + rendszerünkben. Szerkesszük át az /etc/rc.conf állományt. A hálózati nevünket a következõ sorban tudjuk megadni: hostname="az.en.nevem" Ide a gépünk teljes internetes hálózati nevét kell beírnunk. default route Az alapértelmezett átjárót az alábbi sor módosításával tudjuk beállítani úgy, hogy a defaultrouter="NO" változó értékét átírjuk: defaultrouter="slip-gateway" Készítsük el az /etc/resolv.conf állományt, amelyben majd a következõk legyenek: domain CS.Example.EDU nameserver 128.32.136.9 nameserver 128.32.136.12 névszerver tartománynév Látható, hogy ezek a névfeloldásért felelõs szerverek címei. Természetesen a ténylegesen beírandó tartomány (domain) neve és a névszerverek címei mindig az adott környezetünktõl függenek. Állítsuk be egy jelszót a root és toor felhasználóknak (és mindenki másnak, akinek még nem lenne). Indítsuk újra a számítógépünket és utána gyõzõdjünk meg róla, hogy a megfelelõ hálózati névvel rendelkezik. A SLIP kapcsolatok felépítése SLIP kapcsolódás Tárcsázzunk és gépeljük be a slip parancsot, majd ezt követõen a gépünk nevét és a jelszót. Ez leginkább a konkrét környezettõl függ. Ha a Kermit nevû programot használjuk, akkor egy ilyen szkripttel is próbálkozhatunk: # a kermit beállítása set modem hayes set line /dev/modem set speed 115200 set parity none set flow rts/cts set terminal bytesize 8 set file type binary # a következõ makró felelõs a tárcsázásért és a bejelentkezésért define slip dial 643-9600, input 10 =>, if failure stop, - output slip\x0d, input 10 Azonosito:, if failure stop, - output silvia\x0d, input 10 Jelszo:, if failure stop, - output ***\x0d, echo \x0aCONNECTED\x0a Természetesen a felhasználói nevet és a jelszót a sajátunkra kell benne kicserélnünk. Miután ezzel is megvagyunk, a Kermit paranccsorában a csatlakozáshoz egyszerûen csak írjuk be, hogy slip. Nem javasoljuk, hogy az állományrendszeren a jelszavakat titkosítatlan formában tároljuk. Mindeki csak a saját felelõsségére tegyen ilyet. Hagyjuk el a Kermit programot (a Ctrl z billentyûkombinációval bármikor fel tudjuk függeszteni a futását) és root felhasználóként írjuk be a következõt: &prompt.root; slattach -h -c -s 115200 /dev/modem Ha ezután már képesek vagyunk a ping paranccsal elérni az útválasztó másik oldalán található gépet, akkor az azt jelenti, hogy sikerült csatlakoznunk! Ha viszont itt még nem járnánk sikerrel, akkor az slattach parancsnak ne a paramétert adjuk meg, hanem a paramétert. Hogyan bontsunk egy kapcsolatot Tegyük a következõket: &prompt.root; kill -INT `cat /var/run/slattach.modem.pid` Ez leállítja az slattach programot. Ne felejtsük el azonban, hogy ezt csak a root felhasználóval tudjuk végrehajtani. Ezután térjünk vissza a kermit programhoz (ha felfüggesztettük volna, akkor ehhez a fg parancsra lesz szükségünk), és lépjünk ki belõle (q). Az &man.slattach.8; man oldala ehhez a ifconfig sl0 down parancsot javasolja, amellyel lényegében leállítjuk a hozzátartozó felületet. Igazából a kettõ között nincs semmilyen komolyabb eltérés (mivel az (ifconfig sl0 is ugyanezt eredményezi.) Néha elõfordulhat, hogy a modem egyszerûen nem hajlandó eldobni a vonalat. Ilyen esetekben indítsuk el a kermit programot és lépjünk ki megint. Másodjára általában már sikerül. Hibaelhárítás Ha valamiért ez mégsem válna be, akkor csak nyugodtan kérdezõsködjünk a &a.net.name; levelezési listán. A tapasztalatok szerint az embereknek eddig a következõkkel voltak problémáik: Az slattach meghívásakor sem a , sem pedig a paramétert nem adták meg. (Ez ugyan nem végzetes hiba, de egyes felhasználók szerint ez segített megoldani a gondokat.) Az helyett -et írtak be (egyes betûtípusoknál könnyen össze lehet téveszteni ezeket). Az ifconfig sl0 segítségével ellenõrizhetõ a felület állapota. Például ilyet láthatunk: &prompt.root; ifconfig sl0 sl0: flags=10<POINTOPOINT> inet 136.152.64.181 --> 136.152.64.1 netmask ffffff00 Ha a &man.ping.8; no route to host hibaüzenetet ad, akkor az útválasztási táblázattal van a gond. A netstat -r paranccsal gyorsan ki tudjuk listázni a rendszerünkben jelenleg nyilvántartott utakat: &prompt.root; netstat -r Routing tables Destination Gateway Flags Refs Use IfaceMTU Rtt Netmasks: (root node) (root node) Route Tree for Protocol Family inet: (root node) => default inr-3.Example.EDU UG 8 224515 sl0 - - localhost.Exampl localhost.Example. UH 5 42127 lo0 - 0.438 inr-3.Example.ED water.CS.Example.E UH 1 0 sl0 - - water.CS.Example localhost.Example. UGH 34 47641234 lo0 - 0.438 (root node) Az elõzõ példákat egy viszonylag forgalmas rendszerbõl ragadtuk ki. A rendszerünkön megjelenõ számok a hálózati aktivitás mértékének függvényei. A SLIP szerverek beállítása SLIP szerver Ebben a leírásban igyekszünk bemutatni hogyan kell egy &os; típusú rendszer alatt SLIP szervert beállítani, ami általában annyit jelent, hogy a rendszerünben a távoli SLIP kliensek csatlakozásakor automatikusan elindítjuk a kapcsolatokat. Elõfeltételek TCP/IP hálózatok Ez a szakasz igen szakmai jellegû, ezért az olvasó részérõl feltételezünk a témában némi alapismeretet. Ez alatt alapvetõen a TPC/IP hálózati protokollt értjük, különös hangsúllyal a hálózatok és hálózati csomópontok címzéséen, a hálózati maszkokon, alhálózatokon, útválasztáson, az olyan útválasztási protokollokon, mint például a RIP. A SLIP beállítása egy betárcsázós szerveren mindezen fogalmak ismeretét igényli, és ha ezekkel még nem lennénk tisztában, akkor olvassuk el például Craig Hunt TCP/IP Network Administration címû könyvét (O'Reilly & Associates, Inc.; ISBN: 0-937175-82-X) vagy Douglas Comer TCP/IP protokollról szóló könyveit. modem Mindezek mellett még feltételezzük, hogy már beállítottuk a modem(ek)et és a rajtuk keresztüli bejelentkezéshez szükséges állományokat. Ha még nem készítettük volna fel erre a rendszerünket, akkor a ad részletes tájékoztatást a betárcsázós szolgáltatások beállításáról. A soros vonali eszközmeghajtóval kapcsolatban továbbá érdemes átolvasni a &man.sio.4; oldalt, valamint a &man.ttys.5;, &man.gettytab.5;, &man.getty.8; és &man.init.8; oldalakat a bejelentkezések modemen keresztüli fogadásáról, illetve talán az &man.stty.1; oldalt a soros port paramétereinek megfelelõ beállításáról (mint például a clocal a közvetlenül csatlakozó soros felületek esetében). Gyors áttekintés A &os; SLIP szerverként általában a következõ módon üzemel: a SLIP felhasználó tárcsázza a &os;-s SLIP szerverünket, majd bejelentkezik egy specális SLIP bejelentkezési azonosító használatával, amely a /usr/sbin/sliplogin shellt használja. A sliplogin program az /etc/sliphome/slip.hosts állományban megkeresi a speciális felhasználóhoz tartozó sort, és ha talál egy ilyet, akkor csatlakoztatja a soros vonalat egy rendelkezésre álló SLIP felületre, amelyen aztán a SLIP felültet beállításához lefuttatja az /etc/sliphome/slip.login shell szkriptet. Példa SLIP szerveren keresztüli bejelentkezésre Például, ha a SLIP felhasználó azonosítója Shelmerg, akkor az /etc/master.passwd állományban a hozzátartozó bejegyzést nagyjából ilyen: Shelmerg:password:1964:89::0:0:Guy Helmer - SLIP:/usr/users/Shelmerg:/usr/sbin/sliplogin Amikor Shelmerg bejelentkezik, a sliplogin az /etc/sliphome/slip.hosts állományban keresni fog egy felhasználó azonosítójához illeszkedõ sort. Például tegyük fel, hogy az /etc/sliphome/slip.hosts állományban szerepel egy ilyen sor: Shelmerg dc-slip sl-helmer 0xfffffc00 autocomp A sliplogin ezt a sor fogja megtalálni, majd a soros vonalat a következõ elérhetõ SLIP felülethez kapcsolja, amelyen ezután végrehajtja az /etc/sliphome/slip.login szkriptet a következõ módon: /etc/sliphome/slip.login 0 19200 Shelmerg dc-slip sl-helmer 0xfffffc00 autocomp Ha minden jól megy, akkor az /etc/sliphome/slip.login kiad egy ifconfig parancsot azon a SLIP felületen, amelyre a sliplogin magát csatlakoztatta (amely a fenti példában a 0. SLIP felület volt, és amelyet meg is adtunk slip.login elsõ paramétereként), és így beállítja a helyi IP-címet (dc-slip), a távoli IP-címet (sl-helmer), a SLIP felülethez tartozó hálózati maszkot (0xfffffc00) valamint a további opciókat (autocomp). Ha valami rosszul sülne el, akkor a sliplogin ezekrõl általában nagyon jó minõségû, információdús üzeneteket készít, amelyeket a syslogd démon pedig a /var/log/messages állományba rögzít. (A &man.syslogd.8; és &man.syslog.conf.5; man oldalak és talán maga az /etc/syslog.conf segíthet kideríteni, hogy a syslogd jelenleg naplóz-e, és ha igen, akkor hova.) A rendszermag beállítása rendszermag beállítása SLIP A &os; alap (vagyis a GENERIC) rendszermagja támogatja a SLIP (&man.sl.4;) használatát. Ha viszont saját rendszermagunk van, akkor elõfordulhat, hogy beállítások közé fel kell vennünk a következõ sort is: device sl Alapértelmezés szerint a &os; nem továbbít semmilyen csomagot. Amennyiben a &os; SLIP szerverünket útválasztóként is mûködtetni akarjuk, úgy az /etc/rc.conf állományban a gateway_enable változó értékét át kell állítanunk a értékre. Az új beálllítások érvényesítéséhez újra kell indítanunk a gépünket. Ha a &os; rendszermag beállítása során segítségre szorulnánk, akkor olvassuk el et. A sliplogin beállítása Ahogy arra már korábban is utaltunk, az /etc/sliphome könyvtárban három állomány felelõs a /usr/sbin/sliplogin beállításáért (lásd &man.sliplogin.8;): a slip.hosts, amelyekben a SLIP felhasználókat és a hozzájuk tartozó IP-címeket adjuk meg; a slip.login, amely általában csak a SLIP felületet állítja be; (az elhagyható) slip.logout, amely a soros vonal bontásakor a slip.login hatását igyekszik visszafordítani. A <filename>slip.hosts</filename> beállítása Az /etc/sliphome/slip.hosts soraiban whitespace karakterekkel tagoltan legalább négy elem szerepel: a SLIP felhasználó bejelentkezési azonosítója a SLIP kapcsolat helyi címe (a SLIP szerveréhez képest) a SLIP kapcsolat távoli címe hálózati maszk A helyi és távoli címek lehetnek hálózati nevek is (amelyeket vagy az /etc/hosts, vagy pedig az /etc/nsswitch.conf állományban szereplõ beállítások alapján tudunk feloldani IP-címre), illetve a hálózati maszk is lehet egy olyan név, amelyet az /etc/networks fel tud oldani. A példaként bemutatott rendszerünkben az /etc/sliphome/slip.hosts állomány nagyjából így épül fel: # # login helyi-cím távoli-cím maszk opc1 opc2 # (normal,compress,noicmp) # Shelmerg dc-slip sl-helmerg 0xfffffc00 autocomp A sorok végén az alábbi opciók közül egy vagy több szerepelhet: — a fejléceket nem tömörítjük — a fejlécek tömörítése — ha a távoli végpont engedi, akkor tömörítsük a fejléceket — az ICMP csomagok tiltása (így például a ping által generált csomagok is eldobódnak a sávszélesség felemésztese helyett) SLIP TCP/IP hálózatok A SLIP kapcsolathoz tartozó helyi és távoli címek megválasztása függ attól, hogy egy külön TCP/IP alhálózatot szentelünk-e neki, vagy a SLIP szerverünkön egy ARP proxy-t használunk (amely tulajdonképpen nem egy valódi ARP proxy, de ebben a szakaszban így fogunk rá hivatkozni). Ha nem vagyunk biztosak benne, hogy melyik módszert válasszuk vagy hogy miként osszuk ki az IP-címeket, akkor nézzünk utána ezekenek a SLIP használatával kapcsolatos elõfeltételek között megemlített könyvekben () és/vagy konzultáljunk a hálózatunk karbantartójával. Ha a SLIP klienseknek külön alhálózatokat osztunk ki, akkor a saját IP-címünkbõl kell létrehoznunk és kiadnunk ezeket. Ezután valószínûleg a SLIP szerverünkön keresztül még meg kell adnunk egy statikus útvonalat legközelebbi IP útválasztó felé. Ethernet Minden más esetben az ARP proxy módszert kell alkalmaznunk, ahol a SLIP kliensek IP-címeit a SLIP szerver Ethernet alhálózatából osztjuk ki, és ennek megfelelõen az /etc/sliphome/slip.login és /etc/sliphome/slip.logout szkripteket módosítanunk kell úgy, hogy az &man.arp.8; segítségével képesek legyenek a SLIP szerver ARP táblázatában kezelni az ARP proxy bejegyzéseit. A <filename>slip.login</filename> beállítása Egy átlagos /etc/sliphome/slip.login állomány körülbelül ilyen: #!/bin/sh - # # @(#)slip.login 5.1 (Berkeley) 7/1/90 # # Egy általános slip vonali bejelentkezési állomány. A sliplogin ezt az alábbi # paraméterekkel hívja meg: # 1 2 3 4 5 6 7-n # slipegys. ttyseb. azonosító helyi-cím távoli-cím maszk egyéb-pmek. # /sbin/ifconfig sl$1 inet $4 $5 netmask $6 Ez a slip.login állomány az ifconfig segítségével pusztán beállítja a megfelelõ SLIP felülethez tartozó helyi, valamint távoli címet és a hálózati maszkot. Ha ehelyett azonban az ARP proxy módszerét választottuk volna (tehát a SLIP kliensekenek nem akarunk egész alhálózatokat kiutalni), akkor az /etc/sliphome/slip.login állomány eképpen alakul: #!/bin/sh - # # @(#)slip.login 5.1 (Berkeley) 7/1/90 # # Egy általános slip vonali bejelentkezési állomány. A sliplogin ezt az alábbi # paraméterekkel hívja meg: # 1 2 3 4 5 6 7-n # slipegys. ttyseb. azonosító helyi-cím távoli-cím maszk egyéb-pmek. # /sbin/ifconfig sl$1 inet $4 $5 netmask $6 # A SLIP kliensre vonatkozó ARP kéréseket a mi Ethernet címünkkel # válaszoljuk meg: /usr/sbin/arp -s $5 00:11:22:33:44:55 pub Láthatjuk, hogy az elõbbi slip.login állomány egy arp -s $5 00:11:22:33:44:55 pub paranccsal egészült ki, ami a SLIP szerver ARP táblázatában hoz létre egy ARP bejegyzést. Ez az ARP bejegyzés gondoskodik róla, hogy a SLIP szerver válaszoljon a saját Ethernetes MAC-címével, amikor egy másik IP csomópont a SLIP kliens IP-címe felõl érdeklõdik. Ethernet MAC-cím Amikor a fenti példából indulunk ki, a benne megadott MAC-címet (00:11:22:33:44:55) feltétlenül cseréljük a rendszerünk Ethernet kártyájának MAC-címével, mert különben az ARP proxy egyáltalán nem fog mûködni! A SLIP szerverünk MAC-címét a netstat -i paranccsal deríthetjük ki, amelynek a kimenetében a második sor valahogy így néz ki: ed0 1500 <Link>0.2.c1.28.5f.4a 191923 0 129457 0 116 Ebbõl derül ki, hogy az adott rendszer valódi MAC-címe a 00:02:c1:28:5f:4a — az &man.arp.8; számára azonban a netstat -i kimenetében szereplõ pontokat kettõspontokra kell cserélni, és a tagokat ki kell egészíteni kétkarakteres hexadecimális számokká. Az &man.arp.8; man oldalán tudhatunk meg ennek részleteirõl többet. Amikor létrehozzuk az /etc/sliphome/slip.login és /etc/sliphome/slip.logout állományokat, akkor ne felejtsük el hozzájuk beállítani a végrehajtást engedélyezõ bitet sem (tehát ilyenkor mindig adjuk ki a chmod 755 /etc/sliphome/slip.login /etc/sliphome/slip.logout parancsokat is), különben a sliplogin ezeket nem tudja majd elindítani. A <filename>slip.logout</filename> beállítása Az /etc/sliphome/slip.logout állományra nincs feltétlenül szükségünk (hacsak nem egy ARP proxy-t akarunk csinálni), de ha valamiért mégis el akarjuk készíteni, akkor ehhez a következõ alapvetõ slip.logout szkript használható: #!/bin/sh - # # slip.logout # # Egy logout állomány a slip vonalhoz. A sliplogin ezt a szkriptet a # következõ paraméterekkel hívja: # 1 2 3 4 5 6 7-n # slipegys. ttyseb. login helyi-cím távoli-cím maszk opc-pmek. # /sbin/ifconfig sl$1 down Ha az ARP proxy módszert használjuk, és az /etc/sliphome/slip.logout felhasználásával akarjuk a SLIP klienshez tartozó ARP bejegyzést törölni, akkor ebbõl induljunk ki: #!/bin/sh - # # @(#)slip.logout # # Egy logout állomány a slip vonalhoz. A sliplogin ezt a szkriptet a # következõ paraméterekkel hívja: # 1 2 3 4 5 6 7-n # slipegys. ttyseb. login helyi-cím távoli-cím maszk opc-pmek. # sbin/ifconfig sl$1 down # Ne válaszoljunk többet a SLIP kliensre vonatkozó ARP kérésekre /usr/sbin/arp -d $5 Az arp -d $5 parancs eltávolítja az ARP proxy mûködéséhez bejegyzést, amelyet még a slip.login szkripttel vettünk fel a SLIP kliens bejelentkezésekor. Talán felesleges ismételgetésnek tûnhet: az /etc/sliphome/slip.logout állománynak létrehozása után állítsuk be a végrehajtásra szóló bitet (vagyis adjuk ki a chmod 755 /etc/sliphome/slip.logout parancsot). Az útválasztással kapcsolatos megfontolások SLIP útválasztás Ha a hálózatunk többi része (lényegében az internet) és a SLIP klienseink között nem az ARP proxy módszerrel közvetítjük a csomagokat, akkor a legközelebbi alapértelmezett átjárókhoz minden bizonnyal fel kell vennünk statikus útvonalakat, így a SLIP kliensek alhálózatai a SLIP szerverünkön keresztül ki tudnak jutni. Statikus útvonalak statikus útvonalak A legközelebbi alapértelmezett átjárók felé nem minden esetben könnyû felvenni statikus útvonalakat (vagy egyes esetekben pedig egyenesen lehetetlen, mivel nincsenek meg hozzá a jogaink). Ha az intézményünkön belül több átjáró is megtalálható, akkor bizonyos útválasztók, például a Cisco és Proteon gyártmányúak esetében nem csak a SLIP alhálózatok felé kell beállítanunk statikus útvonalakat, hanem azt is meg kell mondanunk, hogy ezekrõl milyen más útválasztók is tudjanak. Pontosan emiatt a statikus útválasztás beüzemeléséhez szükségünk lesz egy kis utánajárásra és próbálgatásra. - - - - A <application>&gated;</application> - futtatása - - &gated; - - - A &gated; most már - magántulajdonú szoftver, amelynek a - forráskódja a továbbiakban már - nem rendelkezésre a nagyközönség - számára (errõl többet a &gated; honlapján - tudhatunk meg). Ez a fejezet csupán abból a - célból íródott, hogy a - visszafelel kompatibilitást szolgálja azok - számára, akik még valamelyik - régebbi verzióját - használják. - - - A &os; SLIP szerverünkön a statikus - útvonalak beállításával - kapcsolatos fejfájásoktól - részint a &gated; - telepítésével és a - megfelelõ útválasztási protokollok - (RIP/OSPF/BGP/EGP) beállításával - mentesülhetünk, melyek majd - információval látják el a - többi útválasztót a SLIP - alhálózatainkról. A - &gated; - beállításához egy - /etc/gated.conf állományt - kell megírnunk. Az itt látható - állomány csak egy példa, ami - hasonlít ahhoz, melyet a szerzõ a saját - SLIP szerverén használ: - - # -# a dc.dsu.edu tartomány gated konfigurációs állománya -- a gated 3.5alpha5 változatához -# az xxx.xxx.yy RIP információit küldi szét az ed Ethernet felületen -# -# -# Nyomkövetési beállítások: -# -traceoptions "/var/tmp/gated.output" replace size 100k files 2 general ; - -rip yes { - interface sl noripout noripin ; - interface ed ripin ripout version 1 ; - traceoptions route ; -} ; - -# -# Engedélyezzünk egy halom nyomkövetési információt a felület és a -# rendszermag között: -kernel { - traceoptions remnants request routes info interface ; -} ; - -# -# A RIP protokollon keresztül adjuk tovább az xxx.xxx.yy állomáshoz -# vezetõ utat az Ethernet felületen: -# - -export proto rip interface ed { - proto direct { - xxx.xxx.yy mask 255.255.252.0 metric 1; # SLIP kapcsolatok - } ; -} ; - -# -# A RIP protokollon és az ed Ethernet felületen keresztül -# fogadjuk útvonalakat: - -import proto rip interface ed { - all ; -} ; - - RIP - - A fentebb megadott példa - gated.conf állomány az - xxx.xxx.yy SLIP - alhálózat útválasztási - információit küldi szét a RIP - protokollal az Ethernet felületen keresztül. Ha a - hálózati kártyánk - meghajtására nem az - ed eszközmeghajtót - használjuk, akkor összes - ed felületre vonatkozó - hivatkozást cseréljük ki benne. Ebben a - példában beállítjuk még a - nyomkövetési információk - mentését is a - /var/tmp/gated.output - állományba, amellyel így - tulajdonképpen a &gated; - viselkedését tudjuk megfigyelni. Amennyiben a - &gated; már - tökéletesen mûködik, ezeket a - nyomkövetési beállításokat - akár el is hagyhatjuk. Az - xxx.xxx.yy cím helyett - pedig a saját SLIP alhálózatunk - hálózati címét - helyettesítsük be (de ehhez ne felejtsük - hozzáigazítani a proto - direct részben szereplõ - hálózati maszkot sem). - - Miután telepítettük és - beállítottuk a - &gated; démont a - rendszerünkön, nem kell mást tennünk, - csak a &os; rendszerindításért - felelõs szkriptjeiben a - routed helyett - &gated; démont - elindítani. Ezt a legegyszerûbben úgy - tudjuk elérni, ha a router - és router_flags - változók értékeit - átírjuk az /etc/rc.conf - állományban. A - &gated; man oldalán - találhatunk egy részletesebb - leírást a paranccsori - paraméterekrõl. - - diff --git a/hu_HU.ISO8859-2/books/handbook/x11/chapter.sgml b/hu_HU.ISO8859-2/books/handbook/x11/chapter.sgml index 304e9c17c9..2aa138f16f 100644 --- a/hu_HU.ISO8859-2/books/handbook/x11/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/x11/chapter.sgml @@ -1,2352 +1,2352 @@ Ken Tom Az X.Org X11 szerveréhez igazította: Marc Fonvieille Az X Window System Áttekintés A &os; az X11-en keresztül nyújt a felhasználók számára hatékony grafikus felhasználói felületet. Az X11 az X Window System szabadon elérhetõ változata, melyet az &xorg; és az &xfree86; egyaránt implementál (valamint más egyéb programcsomagok is, amelyeket itt viszont nem tárgyalunk). A &os; verziói a &os; 5.2.1-RELEASE kiadással bezárólag a The &xfree86; Project, Inc. által kiadott X11 szervert, az &xfree86;-ot tartalmazzák alapértelmezés szerint. A &os; 5.3-RELEASE kiadástól kezdve az X11 alapértelmezett és hivatalos változata az &xorg;, melyet az X.Org alapítvány a &os;-éhez nagyon hasonló licenc alatt fejleszt. A &os;-hez kereskedelmi X szerverek is elérhetõek. Ebben a fejezetben az X11 telepítését és beállítását járjuk végig, miközben a hangsúlyt az &xorg; &xorg.version; kiadására helyezzük. Az &xfree86; (vagyis a &os; olyan régebbi változata, ahol az &xfree86; az alapértelmezett X11 rendszer) vagy az &xorg; korábbi kiadásainak beállításával kapcsolatban mindig találhatunk információkat a &os; kézikönyv címen található archivált változataiban. Az X11 által támogatott megjelenítõkrõl bõvebben az &xorg; honlapján olvashatunk. A fejezet elolvasása során megismerjük: az X Window System különbözõ alkotóelemeit, és hogy ezek miként mûködnek együtt; hogyan telepítsük és állítsuk be az X11-et; hogyan telepítsük és használjuk a különféle ablakkezelõket; hogyan használjunk &truetype; betûtípusokat az X11-ben; hogyan állítsuk be rendszerünkön a grafikus bejelentkezést (XDM). A fejezet elolvasásához ajánlott: külsõ programok telepítésének ismerete (). Az X áttekintése Az X használata elsõre megdöbbentõ lehet azok számára, akik olyan más grafikus környezetekben járatosak, mint például a µsoft.windows; vagy a &macos;. Míg az X minden komponensének részleteit és azok kapcsolatát nem szükséges megérteni a használatukhoz, néhány alapvetõ ismeret velük kapcsolatban elõsegíti kiaknázni az X erõsségeit. Miért X? Az X ugyan nem az elsõ &unix;-ra íródott ablakozó rendszer, de fajtáját tekintve a legnépszerûbb. Az X eredeti fejlesztõcsapata az X elõtt egy másik ablakozó rendszeren dolgozott, aminek a neve W (mint Window, azaz ablak) volt. Az X pedig az arab ábécében pontosan ezt a betût követi. Az X-et hívhatjuk X-nek, X Window System-nek, és még sok más néven. Elõfordulhat azonban, hogy az X Windows elnevezés sértõ lehet egyes emberek számára. Errõl többet a &man.X.7; man oldalon tudhatunk meg többet. Az X kliens-szerver modellje Az X-et már az elejétõl kezdve hálózatközpontúnak tervezték, és ezért az ún. kliens-szerver modellt használja. Az X modelljében az X szerver egy olyan számítógépen fut, amelyhez billentyûzetet, monitort és egeret csatlakoztattunk. A szerver feladatai között találjuk a megjelenítés irányítását az egérrõl és a billentyûzetrõl, valamint a többi bemeneti és kimeneti eszközrõl érkezõ adatok felfeldolgozását és így tovább (például a digitális táblák is használhatóak beviteli eszközként, illetve egy projektor is lehet megjelenítõ). Mindegyik X alkalmazás (mint például az XTerm vagy a &netscape;) egy kliens. A kliens üzeneteket küld a szervernek, például Kérlek, rajzolj egy ablakot ezekre a koordinátákra, és a szerver pedig olyan üzeneteket küld, mint például A felhasználó az OK gombra kattintott. Az otthoni vagy a kisebb irodai környezetben az X szerver és az X kliensek általában ugyanazon a számítógépen futnak. Emellett azonban nagyon is lehetséges, hogy az X szerver egy kevésbé erõs gépen fusson, miközben az X alkalmazások (a kliensek) az irodát kiszolgáló erõsebb és drágább gépen fussanak. Egy ilyen konfigurációban az X kliensei és szerverei közti kommunikáció a hálózaton keresztül zajlik. Jegyezzük meg, hogy az X szerver az a számítógép, ahol a monitor és a billentyûzet található, az X kliensek pedig azok a programok, amelyek az ablakokat jelenítik meg. A protokollban semmi sem várja el, hogy a kliens és a szerver ugyanazon az operációs rendszeren vagy éppen ugyanolyan típusú számítógépen fusson. Ezért akár µsoft.windows;-on vagy &apple; &macos;-en is indíthatunk X szervert, és számos különbözõ szabad valamint kereskedelmi alkalmazás képes pontosan erre. Az ablakkezelõ Az X kialakításának filozófiája leginkább a &unix; kialakításának filozófiájához hasonlítható, vagyis eszközöket, ne szabályokat. Ez tehát azt jelenti, hogy az X nem köti meg miként oldjuk meg vele a feladatokat. Helyette különféle eszközeket ad a felhasználó kezébe, és onnantól a saját felelõssége eldönteni, hogyan használja ki ezeket. Ez a filozófia az X-ben egészen addig terjed, hogy nem rögzíti, hogyan nézzenek ki a képernyõn megjelenõ ablakok, miként kell ezeket mozgatni az egérrel, milyen billentyûk lenyomásával közlekedhetünk az ablakok között (ami a µsoft.windows; esetén az AltTab), hogyan nézzen ki az ablakok címsora, a bezárás funkciónak legyen-e rajtuk gombja és így tovább. Ehelyett az X az összes ezzel járó felelõsséget átadja az ablakkezelõ (window manager) részére. Tucatnyi ilyen ablakkezelõt találhatunk az X-hez: AfterStep, Blackbox, ctwm, Enlightement, fvwm, Sawfish, twm, Window Maker és még sok más. Ezen ablakkezelõk mindegyike más és más kinézetet és hangulatot kínál fel: némelyikük támogatja a virtuális munkaasztalok (virtual desktop) létrehozását; néhányuk pedig megengedi, hogy mi magunk állítsuk be az asztal irányításához használt gombkombinációkat; köztük találhatunk olyat is, amelynek van Start gombja vagy ehhez hasonló eszköze; némelyek közülük ismerik a témákat, aminek révén a kinézetük és hangulatuk teljesen megváltoztatható. Az említett ablakkezelõk és társaik a Portgyûjtemény x11-wm kategóriájában érhetõek el. Ráadásul a KDE és a GNOME munkakörnyezetek mindegyikének van saját integrált ablakkezelõje. Az egyes ablakkezelõk mellesleg eltérõ beállítási módszerrel rendelkeznek. Némelyikük kézzel összeállított konfigurációs állományt vár, mások pedig külön grafikus eszközöket tartalmaznak erre a feladatra is. Az egyikük (a Sawfish) konfigurációs állományát például a Lisp programozási nyelv egyik dialektuásban kell megírni. Az irányítás átadása Az ablakkezelõ másik fontos feladata lekezelni, hogy az egérrel miként tudjuk átadni az ablakok között az irányítást, vagyis a fókuszt (focus policy). Minden ablakkezelõ rendszerben el kell tudnunk valahogy dönteni, hogy a beérkezõ billentyûleütések melyik ablakhoz vándoroljanak, valamint az ilyen értelemben aktív ablakot valamilyen módon jeleznünk is kell. Ennek egyik ismert módszere a fókusz kattintásra megoldás, amely modellt a µsoft.windows; rendszerekben találhatjuk meg. Itt az ablakok akkor válnak aktívvá, amikor rájuk kattintunk az egérrel. Az X viszont nem kötelezi el magát egyik vezérlésátadási módszer mellett sem, helyette az ablakkezelõ fogja majd eldönteni, melyik ablak birtokolja a fókuszt az adott pillanatban. A különbözõ ablakkezelõk különbözõ fókuszvezérlési technikákat ismernek. Mindegyikük ismeri a kattintásos fókuszt, azonban a többségük emellett még sok más megoldást is felkínál. A legnépszerûbb fókuszvezérlési elvek: A fókusz az egeret követi (focus-follows-mouse) Az egérmutató alatt található ablak kapja meg fókuszt. Az érintett ablaknak nem kell feltétlenül az összes többi felett elhelyezkednie. Ilyenkor a fókuszt egyszerûen úgy vihetjük át egy másik ablakra, ha rámutatunk az egérrel, amihez még kattintanunk sem kell. Hanyag fókusz (sloppy-focus) Ez az elv az elõbbi apró kibõvítése. Amikor a fókusz az egérmutatót követi, és az egeret a leghátsó ablakra (vagy a háttérre) visszük, akkor valójában egyik ablak sem birtokolja az irányítást, ezért a leütött billentyûk elvesznek. A hanyag fókusz használatával azonban az irányítás csak abban az esetben kerül át máshová, amikor egy másik ablakba lépünk be, nem pedig akkor, amikor a jelenlegibõl lépünk ki. Fókusz kattintásra (click-to-focus) Az aktív ablakot egy egérkattintással választjuk ki. Ilyenkor a kiválasztott ablak felemelkedhet és a többi elõtt jelenhet meg. Ezt követõen az összes irányítás ebbe az ablakba vándorol, még abban az esetben is, amikor egy másik ablakra visszük az egérmutatót. Sok ablakkezelõ ismer ezekbõl különbözõ variációikat, valamint rajtuk kívül más egyéb vezérlési elvet is. Ezzel kapcsolatban az adott ablakkezelõ dokumentációjából deríthetünk ki a legtöbbet. Widgetek Az X megközelítése, vagyis az eszközök és nem a szabályok felsorakoztatása, kiterjed az egyes alkalmazásokban látható különféle widgetekre is. A widget (window gadget, vagyis widget, de magyarul sok helyen a mütyürke) elnevezést azokra a felhasználói felületen megjelenõ elemekre használjuk, amelyekkel valamilyen módon kapcsolatba léphetünk: kattinthatunk rájuk, piszkálhatjuk ezeket. Ilyenek többek közt a gombok, jelölõnégyzetek, rádiógombok, ikonok, listák és a többi. A µsoft.windows; nyelvén ezeket vezérlõknek (control) nevezzük. A µsoft.windows; és az &apple; &macos; ezen a téren nagyon merev. Az alkalmazások fejlesztõinek gondoskodniuk kell róla, hogy a programjaik az elterjedt kinézetet és kialakítást kövessék. Az X viszont nem várja az egységes vezérlõeszközök vagy grafikai stílus használatát. Ennek eredményeképpen az X cseppet sem kívánja meg az alkalmazásoktól, hogy közös kinézetben vagy viselkedésben osztozzanak. Természetesen léteznek népszerû eszközrendszerek és azoknak számos variációja is kialakult, beleértve az MIT Athenaját, a &motif;ot (amirõl a µsoft.windows; eszközeit is mintázták, az összes ferde élet és a három szürkeárnyalatot), az OpenLookot és társaikat. Napjaink X alkalmazásai a KDE fejlesztéséhez használt Qt, esetleg a GNOME-hoz használt GTK+ könyvtárból származó, korszerû kinézetû widgeteket tartalmaznak. Ebbõl a szempontból megfigyelhetõ egyfajta tendencia a grafikus &unix;-alkalmazások felépítésében, ami minden bizonnyal megkönnyíti a kezdõ felhasználók tájékozódását. Az X11 telepítése Az X11 &os;-n alapértelmezett implementációja az &xorg;. Az &xorg; az X.Org alapítvány által kiadott, az X Window Systemet megvalósító nyílt forráskódú X szerver. Az &xorg; az &xfree86; 4.4RC2 és X11R6.6 kódja alapján készült. A &os; Portgyûjteményében jelenleg az &xorg; &xorg.version; változata érhetõ el. Az &xorg;-ot a Portgyûjteménybõl így tudjuk lefordítani, majd telepíteni: &prompt.root; cd /usr/ports/x11/xorg &prompt.root; make install clean Az egész &xorg; lefordításához legalább 4 GB szabad helyre van szükségünk. Az X11-et természetesen telepíthetjük közvetlenül csomagok segítségével is. A &man.pkg.add.1; használatával telepíthetõ bináris csomagok is elérhetõek az X11-hez. Amikor a &man.pkg.add.1; programra bízzuk a csomag letöltését, ne adjunk meg verziószámot, a &man.pkg.add.1; ugyanis mindig automatikusan az alkalmazás legfrissebb verzióját tölti le. Az &xorg; csomagjának letöltéséhez és telepítéséhez egyszerûen csak ennyit írjunk be: &prompt.root; pkg_add -r xorg A fentebb megadott példák a teljes X11 rendszert telepíteni fogják, beleértve a szervereket, klienseket, betûtípusokat stb. Az X11 egyes részeihez külön találhatunk csomagokat és portokat. A fejezet további részében szót ejtünk az X11, valamint egy irodai használatra alkalmas munkakörnyezet beállításáról. Christopher Shunway Írta: Az X11 beállítása &xorg; X11 Mielõtt nekilátnánk Az X11 beállítása elõtt a célrendszer következõ adataira lesz szükségünk: A monitor jellemzõi A videokártya chipkészlete A videokártya memóriájának mérete függõleges frissítési frekvencia vízszintes frissítési frekvencia Az X11 a monitor jellemzõibõl állapítja meg, hogy milyen felbontásban és frissítési frekvenciával mûködtesse azt. Ezek általában a monitorhoz tartozó dokumentációból vagy a gyártó honlapjáról deríthetõek ki. Igazából két értékre van szükségünk: a függõleges és a vízszintes frissítési frekvenciára. A videokártya chipkészlete határozza meg, hogy az X11 melyik meghajtóján keresztül kommunikál a grafikus hardverrel. Ez a legtöbb chipkészlet esetén magától megállapítható, de ennek ellenére mégis jó tisztában lenni ezzel arra az esetre, ha az automatikus felismerés mégsem mûködne. A grafikus kártya memóriájának mérete határozza meg a rendszer által kihasználható felbontást és színmélységet. Ezt fontos tudunk ahhoz, hogy ismerjük a rendszerünk korlátait. Az X11 beállítása Az &xorg; 7.3-as változatában gyakran mindenféle konfigurációs állomány használata nélkül egyszerûen csak adjuk ki a következõ parancsot: &prompt.user; startx Amennyiben ez nem mûködne, vagy az alapértelmezések nem felelnek meg számunkra, az X11 kézzel is beállítható. Az X11 beállítása egy többlépcsõs folyamat. Elsõ lépésünk egy alap konfigurációs állomány összeállítása lesz. Rendszeradminisztrátorként adjuk ki az alábbi parancsot: &prompt.root; Xorg -configure Ennek segítségével az X11 xorg.conf.new néven létrehozza a konfigurációs állomány vázát a /root könyvtárban (akár a &man.su.1; parancsot használjuk, akár közvetlenül így jelentkezünk be, az így örökölt rendszeradminisztrátori szerepkör maga után vonja a $HOME könyvtár átállítását is). Az X11 megpróbálja megkeresni a célrendszerben elérhetõ grafikus eszközöket, és létrehozni egy olyan konfigurációs állományt, amely az észlelt eszközökhöz tartozó meghajtókat tölti be. A következõ lépésünk legyen az imént létrehozott beállítás kipróbálása, amin keresztül ellenõrizhetjük, hogy az &xorg; tényleg képes mûködni a célrendszer grafikus eszközén. Ehhez a következõt kell begépelnünk: &prompt.root; Xorg -config xorg.conf.new Ha ezután a képernyõn egy fekete-fehér rácsot látunk egy X alakú egérmutatóval a közepén, akkor jó a beállítás. A próbát a CtrlAltBackspace billentyûk együttes lenyomásával szakíthatjuk meg. Ha az egér még nem mûködne, mindenképpen be kell állítanunk a továbblépés elõtt. Ezzel kapcsolatban a &os; telepítésérõl szóló fejezetben levõ t ajánljuk elolvasásra. Az X11 finomhangolása Ezután az ízlésünknek megfelelõen hangoljuk be az xorg.conf.new állományt, nyissuk meg egy szövegszerkesztõben, például az &man.emacs.1;-ben vagy az &man.ee.1;-ben. Elsõként adjuk meg a célrendszerhez csatlakoztatott monitor frekvenciájára vonatkozó adatokat. Ezek általában a függõleges és a vízszintes frissítés értékei, melyeket az xorg.conf.new állomány "Monitor" szakaszában (Section) kell feltüntetni: Section "Monitor" Identifier "Monitor0" VendorName "A monitor gyártója" ModelName "A monitor típusa" HorizSync 30-107 VertRefresh 48-120 EndSection A konfigurációs állományból valószínûleg csak a HorizSync és VertRefresh kulcsszavak fognak hiányozni. Amennyiben ez tényleg így lenne, a megfelelõ vízszintes frissítés értékét a HorizSync kulcsszó után, a hozzátartozó függõleges frissítés értékét pedig a VertRefresh kulcsszó után kell hozzátennünk a szakaszhoz. Az iménti példában már megadtuk a célrendszer monitorának frissítési értékeit. Az X megengedi, hogy DPMS (Energy Star) energiagazdálkodási szabványt ismerõ monitorok lehetõséget is kihasználjuk. A &man.xset.1; program vezérli a monitorok ki- és bekapcsolását, és segítségével készenléti vagy energiatakarékos üzemmódba tudjuk helyezni azokat. Ha engedélyezni kívánjuk a monitorunk DPMS lehetõségeit, egyszerûen csak tegyük hozzá az alábbi sort a monitorunkat leíró szakaszhoz: Option "DPMS" xorg.conf Ha már a xorg.conf.new konfigurációs állomány szerkesztésével vagyunk elfoglalva, válasszuk ki számunkra kedvezõ alapértelmezett felbontást és színmélységet is. Ezt a "Screen" (Képernyõ) nevû szakaszban tehetjük meg: Section "Screen" Identifier "Screen0" Device "Card0" Monitor "Monitor0" DefaultDepth 24 SubSection "Display" Viewport 0 0 Depth 24 Modes "1024x768" EndSubSection EndSection A DefaultDepth kulcsszó után adjuk meg a rendszer alapértelmezett színmélységét. Ezt késõbb az &man.Xorg.1; paraméterével bírálhatjuk felül a parancssorból. A Modes kulcsszó után jelennek meg azok a felbontások, amelyekben az adott színmélység elérhetõ. Itt csak olyan VESA szabványú módok jelenhetnek meg, amelyet a célrendszer grafikus eszköze is támogat. A fenti példában az alapértelmezett színmélység képpontonként huszonnégy bit, és ebben a színmélységben az elfogadott felbontás 1024-szer 768 pixel. Végezetül mentsük el a szerkesztett konfigurációs állományt és próbáljuk ki a korábban leírt módszer szerint. A hibakeresés során maguk az X11 naplóállományai is hasznos eszköznek bizonyulhatnak, mivel ezek minden olyan eszközrõl tartalmaznak információt, amelyekhez az X11 szervernek sikerült csatlakoznia. Az &xorg; naplóit a /var/log/Xorg.0.log elnevezést követõ állományokban találjuk meg. A konkrét naplók nevei Xorg.0.log-tól Xorg.8.log-ig és így tovább terjedhetnek. Ha minden a legnagyobb rendben haladt eddig, a konfigurációs állományt el kell tennünk egy olyan központi helyre, ahol az &man.Xorg.1; képes lesz majd megtalálni. Ez a hely általában az /etc/X11/xorg.conf vagy a /usr/local/etc/X11/xorg.conf. &prompt.root; cp xorg.conf.new /etc/X11/xorg.conf Az X11 beállítását ezzel befejeztük. Az &xorg; innentõl elindítható a &man.startx.1; segédprogram vagy az &man.xdm.1; használatával. Létezik egy grafikus beállítást lehetõvé tevõ eszköz is, az &man.xorgcfg.1;, amely az X11 rendszer része. Használata során a megfelelõ meghajtók és beállítások kiválasztásával interaktívan megadhatjuk a rendszerünk jellemzõit. Ezt a programot az xorg -textmode parancs kiadásával hívhatjuk meg a konzolról. Bõvebb információkat a &man.xorgcfg.1; man oldalán találunk. Emellett találhatunk még egy &man.xorgconfig.1; nevezetû segédprogramot is. Ez egy szöveges felületû, kevésbé felhasználóbarát program, azonban olyan esetekben is mûködhet, amikor más programok már nem. Témák idõsebbeknek és haladóknak Az i810 grafikus chipkészlet beállítása Intel i810 grafikus chipkészlet Az &intel; i810 integrált chipkészletének meghajtásához szükségünk lesz az agpart nevû AGP programozási felületre az X11-ben. Errõl az &man.agp.4; meghajtó man oldalán olvashatuk többet. Ennek segítségével ezt a hardvert is a többi grafikus kártyához hasonlóan állíthatjuk be. Vegyük figyelmbe azonban, hogy az &man.agp.4; meghajtót beépítve nem tartalmazó rendszermaggal futó rendszerekben a &man.kldload.8; paranccsal utólag már nem tudjuk betölteni! Ezt a meghajtót már a rendszerindítás során be kell tudnunk tölteni: vagy a rendszermagba fordítjuk, vagy pedig a /boot/loader.conf állományban hivatkozunk rá. Widescreen Flat Panel monitorok használata widescreen flat panel beállítása Ebben a részben feltételezünk némi tapasztalatot a beállítások terén. Amennyiben a szabványos konfigurációs eszközök csõdöt mondtak a beállítás során, magukból a naplóállományokból is kinyerhetünk elegendõ információt ahhoz, hogy mûködésre bírjuk rendszerünket. Ehhez mindenképpen legyen kéznél egy szövegszerkesztõ! A jelenlegi szélesvásznú (WSXGA, WSXGA+, WUXGA, WXGA, WXGA+ és társai) formátumok a 16:10-es és 10:9-es képarányokat ismerik, amik néha gondot okozhatnak. Például a 16:10-es képarány felbontásai: 2560x1600 1920x1200 1680x1050 1440x900 1280x800 Bizonyos szempontból egyszerûen csak a fenti felbontások valamelyikét kell felvenni a "Screen" szakasz Mode sorába, valahogy így: Section "Screen" Identifier "Screen0" Device "Card0" Monitor "Monitor0" DefaultDepth 24 SubSection "Display" Viewport 0 0 Depth 24 Modes "1680x1050" EndSubSection EndSection Az &xorg; elég intelligens ahhoz, hogy a szélesvásznú megjelenítéssel kapcsolatos információkat lekérje a monitor I2C/DDC adatai közül, ezért meg tudja állapítani, hogy az eszköz milyen frissítési frekvenciákat és felbontásokat bír el. Ha az alábbi ModeLine értékek nem szerepelnének a meghajtókban, akkor velük kapcsolatban egy kicsit súgnunk kell az &xorg;-nak. A /var/log/Xorg.0.log átrágásával elegendõ információt tudunk gyûjteni ahhoz, hogy manuálisan vegyünk fel használható ModeLine értékeket. Nem kell mást tennünk, mint ehhez hasonló sorokat keresnünk: (II) MGA(0): Supported additional Video Mode: (II) MGA(0): clock: 146.2 MHz Image Size: 433 x 271 mm (II) MGA(0): h_active: 1680 h_sync: 1784 h_sync_end 1960 h_blank_end 2240 h_border: 0 (II) MGA(0): v_active: 1050 v_sync: 1053 v_sync_end 1059 v_blanking: 1089 v_border: 0 (II) MGA(0): Ranges: V min: 48 V max: 85 Hz, H min: 30 H max: 94 kHz, PixClock max 170 MHz Ezeket nevezik EDID-adatoknak (Extended display identification data, vagyis bõvített megjelenítési azonosító adatoknak). Belõlük a megfelelõ ModeLine sor létrehozása csupán annyiból áll, hogy a számértékeket a megfelelõ sorrendbe tesszük: ModeLine <name> <clock> <4 horiz. timings> <4 vert. timings> Ezáltal a példában látott "Monitor" szakasz ModeLine sora így fog kinézni: Section "Monitor" Identifier "Monitor1" VendorName "Bigname" ModelName "BestModel" ModeLine "1680x1050" 146.2 1680 1784 1960 2240 1050 1053 1059 1089 Option "DPMS" EndSection Miután végrehajtottuk ezeket az egyszerû beállítási lépéseket, az X most már valószínûleg el fog indulni az új szélesvásznú monitorunkon. Murray Stokely Írta: Betûtípusok használata az X11-ben Type1 betûtípusok Az X11-hez tartozó alap betûtípusok nem mondhatóak kifejezetten ideálisnak például egy átlagos asztali kiadványszerkesztõ alkalmazás számára. A nagyobb méretû bemutatókon a betûi szögletesen és idétlenül néznek ki, a &netscape;ben megjelenõ kisebb betûk pedig szinte teljességgel olvashatatlanok. Viszont manapság már rengeteg szabad, nagyon jó minõségû és könnyen használható Type1 (&postscript;) betûtípus érhetõ el az X11-hez. Például az URW betûtípus-gyûjtemény (x11-fonts/urwfonts) a szabványos Type1 betûtípusok (Times Roman, Helvetice, Palatino és még sok más) jó minõségû változatait tartalmazza. A Freefonts nevû gyûjtemény (x11-fonts/freefonts) is tartalmaz sok más betûtípust, de a legtöbbjüket inkább csak a Gimpben és a hozzá hasonló grafikai alkalmazásokban tudjuk használni, illetve nincsenek is még kellõ mértékben befejezve a hétköznapi munkákhoz. Ezeken felül az X11 minimális ügyeskedéssel beállítható a &truetype; betûtípusok használatára is. Errõl részleteket a &man.X.7; man oldalon, illetve a &truetype; betûtípusokról szóló szakaszban olvashatunk. A Portgyûjteménybõl az imént említett Type1 betûtípusokat az alábbi parancsok segítségével telepíthetjük: &prompt.root; cd /usr/ports/x11-fonts/urwfonts &prompt.root; make install clean Ugyanígy járjunk el a freefont és a többi gyûjtemény esetén is. Az X szerver akkor fogja észlelni ezeket a betûtípusokat, ha hozzáadjuk a következõ sort a konfigurációs állományához (/etc/X11/xorg.conf): FontPath "/usr/local/lib/X11/fonts/URW/" Vagy megtehetjük mindezt az X futtatása során is: &prompt.user; xset fp+ /usr/local/lib/X11/fonts/URW &prompt.user; xset fp rehash Ez utóbbi beállítás viszont el fog veszni az X leállításával, hacsak nem vesszük hozzá a indítószkriptjéhez (ez az ~/.xinitrc a startx használata esetén, illetve az ~/.xsession, amikor egy XDM-szerû grafikus bejelentkezést használunk). Ezek mellett használhatjuk a /usr/local/etc/fonts/local.conf állományt is: errõl az élsimítással foglalkozó szakaszban szólunk részletesebben. &truetype; betûtípusok TrueType betûtípusok betûtípusok TrueType Az &xorg; beépített támogatást tartalmaz a &truetype; betûtípusok rendereléséhez. Két különbözõ modul valósítja meg ezt a feladatot. Ebben példában a freetype nevû modult használjuk, mivel sokkal jobban illeszkedik a többi betûrenderelõhöz. A freetype modul használatához mindössze az /etc/X11/xorg.conf állomány "Module" szakaszába kell beírnunk a következõ sort: Load "freetype" Most pedig hozzunk létre egy könyvtárat a &truetype; betûtípusok számára (ez legyen például a /usr/local/lib/X11/fonts/TrueType), majd másoljuk az összes &truetype; betûtípusunkat ide. Vigyázzunk rá, hogy &macintosh;-ról &truetype; betûtípusok közvetlenül nem hozhatóak át, az X11 számára &unix;/&ms-dos;/&windows; formátumban kell lenniük. Miután sikerült átmásolnunk az állományokat ebbe a könyvtárba, használjuk a ttmkfdir parancsot a fonts.dir állomány létrehozására, aminek révén az X betûrenderelõje tudnia fogja, hogy új állományokat telepítettünk. A ttmkfdir x11-fonts/ttmkfdir néven elérhetõ a &os; Portgyûjteményébõl. &prompt.root; cd /usr/local/lib/X11/fonts/TrueType &prompt.root; ttmkfdir -o fonts.dir Ezután adjuk hozzá a &truetype; könyvtárat a betûtípusok könyvtáraihoz. Itt is a Type1 betûtípusoknál leírtak szerint kell eljárnunk, vagyis használjunk a &prompt.user; xset fp+ /usr/local/lib/X11/fonts/TrueType &prompt.user; xset fp rehash parancsot, vagy adjunk hozzá a xorg.conf állományhoz egy további FontPath sort. Ezzel végeztünk is. Innentõl kezdve a &netscape;, Gimp, a &staroffice; és mindegyik X alkalmazás fel fogja ismerni a frissen telepített &truetype; betûtípusokat. A nagyon kicsi betûk (egy honlap megtekintése során, nagyfelbontásban) és a nagyon nagy betûk (a &staroffice; használatakor) most már sokkal jobban fognak mutatni. Joe Marcus Clarke Frissítette: A betûk élsimítása élsimított betûk betûk élsimított Az X11-ben az &xfree86; 4.0.2-es változata óta érhetõ el az élsimítás, azonban az &xfree86; 4.3.0-at megelõzõen a betûk beállítása meglehetõsen körülményes volt. Az &xfree86; 4.3.0-as verziójával kezdõdõen az X11 által használt, a /usr/local/lib/X11/fonts/ és a ~/.fonts/ könyvtárakban található összes betûtípus élsimítása automatikusan elérhetõ az Xft-re felkészített alkalmazások számára. Nem mindegyik alkalmazás használja ki az Xft-t, de sokan kaptak hozzá támogatást. Ilyen Xft-alkalmazások a (KDE fejlesztéséhez használt) Qt 2.3 és késõbbi változatai, a (GNOME fejlesztéséhez használt) GTK+ 2.0 és késõbbi változatai, valamint a Mozilla 1.2 és késõbbi változatai. A betûtípusok élsimításának be- és kikapcsolásához, valamint élsimítási jellemzõinek beállításához hozzuk létre (vagy ha már létezne, módosítsuk) a /usr/local/etc/fonts/local.conf állományt. Az Xft betûrendszer számos kifinomult lehetõsége hangolható ezzel az állománnyal, amelyekbõl ebben a szakaszban csupán rövidke ízelítõt fogunk adni. A pontosabb részletekrõl a &man.fonts-conf.5; man oldalon tájékozódhatunk. XML Az állománynak XML formátumúnak kell lennie. Különösen ügyeljünk a kis- és nagybetûkre, illetve gyõzödjünk meg mindig róla, hogy lezártuk-e az összes taget. Az állomány a szokásos XML-fejléccel kezdõdik, amelyet egy DOCTYPE definíció követ, majd a <fontconfig> tag: <?xml version="1.0"?> <!DOCTYPE fontconfig SYSTEM "fonts.dtd"> <fontconfig> Ahogy azt már korábban is említettük, a /usr/local/lib/X11/fonts és a ~/.fonts/ könyvtárakban található összes betûtípus élsimítása elérhetõ az Xft-re felkészített alkalmazások számára. Amennyiben ezeken túl még további könyvtárakat is fel kívánunk venni, írjuk bele a /usr/local/etc/fonts/local.conf állományba, nagyjából ilyen alakban: <dir>/az/en/betu/tipusaim</dir> Az új betûtípusok, de legfõképpen az új betûtípusokat tartalmazó könyvtárak hozzáadása után a betûkkel kapcsolatos gyorsítótárak frissítéséhez mindenképpen javasolt lefuttatni az alábbi parancsot: &prompt.root; fc-cache -f Az élsimítás hatására a betûk kontúrjai egy kissé elmosódnak, aminek köszönhetõen a nagyon kis méretû szövegek sokkal olvashatóbbá válnak és eltûnnek a nagy méretû betûkrõl a lépcsõk, azonban a normál méretû betûknél megfájdulhat tõle a szemünk. A 14 pontnál kisebb méretû betûk esetén az alábbi sorok hozzáadásával tudjuk kikapcsolni az élsimítást: <match target="font"> <test name="size" compare="less"> <double>14</double> </test> <edit name="antialias" mode="assign"> <bool>false</bool> </edit> </match> <match target="font"> <test name="pixelsize" compare="less" qual="any"> <double>14</double> </test> <edit mode="assign" name="antialias"> <bool>false</bool> </edit> </match> betûk térköz Bizonyos egyenszélességû (monospaced) betûtípusok élsimítása esetén a betûk távolsága nem megfelelõ. Ez leginkább a KDE használata esetén merül fel. Ezt a problémát úgy is orvosolhatjuk, ha az ilyen betûtípusok térközét kézzel 100-ra állítjuk. Ehhez írjuk be a következõ sorokat: <match target="pattern" name="family"> <test qual="any" name="family"> <string>fixed</string> </test> <edit name="family" mode="assign"> <string>mono</string> </edit> </match> <match target="pattern" name="family"> <test qual="any" name="family"> <string>console</string> </test> <edit name="family" mode="assign"> <string>mono</string> </edit> </match> (ezzel lefedjük összes rögzített méretû (fixed) betûtípust "mono"-ként), majd vegyük hozzá ezt is: <match target="pattern" name="family"> <test qual="any" name="family"> <string>mono</string> </test> <edit name="spacing" mode="assign"> <int>100</int> </edit> </match> Egyes betûtípusoknál, mint például a Helveticánál, gondok akadhatnak az élsimítással. Ez általában egy függõlegesen kettévágottnak látszó betû képében jelenik meg. De ami a legrosszabb, hogy emiatt némely alkalmazás, mint például a Mozilla képes összeomlani. Ennek elkerülésére tegyük hozzá még az alábbi sorokat a local.conf állományhoz: <match target="pattern" name="family"> <test qual="any" name="family"> <string>Helvetica</string> </test> <edit name="family" mode="assign"> <string>sans-serif</string> </edit> </match> Miután befejeztük a local.conf szerkesztését, ellenõrizzük, hogy szerepel-e az állomány végén a </fontconfig> tag. Ha ugyanis nem zárjuk le rendesen, akkor a változtatásaink érvénytelenné válnak. Az X11-hez tartozó alap betûtípus nem éppen mutatós élsimított alakjában. Erre a célra sokkal jobb alap betûtípusok is találhatóak a x11-fonts/bitstream-vera portban. Ha még nem létezne /usr/local/etc/fonts/local.conf állományunk, akkor ezt a port létrehozza. Ellenkezõ esetben a port készít egy /usr/local/etc/fonts/local.conf-vera nevû állományt. Fésüljük össze ennek az állománynak a tartalmát a /usr/local/etc/fonts/local.conf tartalmával, és a Bitstream betûtípusok maguktól felváltják az X11 alapértelmezett talpas (serif), talpatlan (sans serif) és egyenszélességû (monospaced) betûtípusait. Végezetül a felhasználók is megadhatják a saját beállításaikat a saját .fonts.conf állományuk segítségével. Ehhez nem kell mást tenni, mindössze létrehozni egy ~/.fonts.conf XML-állományt. LCD képernyõ betûk LCD képernyõ Még egy utolsó ötlet: LCD képernyõk esetén szükségünk lehet az ún. sub-pixel sampling (részképpont mintavételezési) technikára. Ezzel lényegében a (vízszintesen elválasztott) vörös, zöld és kék összetevõket külön-külön kezeljük a horizontális felbontás javítására. Bámulatos eredményeket lehet elérni a segítségével! A bekapcsolásához a következõ sorokat kell beszúrnunk valahova a local.conf állományba: <match target="font"> <test qual="all" name="rgba"> <const>unknown</const> </test> <edit name="rgba" mode="assign"> <const>rgb</const> </edit> </match> A megjelenítõ fajtájától függõen lehet, hogy az rgb értéket bgr-re, vrgb-re vagy vbgr-re kell cserélnünk. Próbálgassuk és kiderül, hogy melyikkel mûködik jobban. Mozilla az élsimítás kikapcsolása Az élsimítás hatása az X következõ indításakor fog látszódni. Azonban a programoknak tudniuk is kell élni az általa felkínált elõnyökkel. A Qt pillanatnyilag képes erre, ezért az összes KDE-elem ki tudja használni a betûtípusok élsimítását. A GTK+ és a GNOME is használja az élsimítást a Font cappleten keresztül (errõl bõvebben ld. a t). A Mozilla 1.2 és késõbbi változatai már alapértelmezés szerint használják az élsimítást. Ennek kikapcsolásához a Mozillat a -DWITHOUT_XFT kapcsolóval fordítsuk újra. Seth Kingsley Írta: Az X bejelentkeztetõ képernyõje Összefoglalás X Display Manager Az X bejelentkeztetõ képernyõje (az X Display Manager vagy röviden csak XDM) az X Window System egyik kiegészítõ eleme, melyet a bejelentkezések lebonyolítására használunk. Számtalan helyzetben hasznosnak bizonyulhat, beleértve a legkisebb X terminálokat és a legnagyobb hálózati szervereket is. Mivel az X Window System független hálózattól és protokolltól, a hálózaton összekapcsolt, X klienseket és szervereket futtató különbözõ számítógépek széles kombinációja elõfordulhat. Az XDM egy grafikus felületen keresztül segít választani az elérhetõ szerverek között, valamint a felhasználók, például felhasználónév és jelszón keresztüli, hitelesítésében. Az XDM tulajdonképpen a felhasználó számára ugyanazokat a funkciókat nyújtja, mint a &man.getty.8; program (errõl bõvebben lásd ). Tehát: belépteti a felhasználót a szerverre, ahova csatlakozott, illetve elindítja helyette a hozzátartozó munkamenet kezelõjét (ami általában egy X-es ablakkezelõ). Az XDM megvárja ennek a programnak a befejezõdését, ami egyben jelzi számára, hogy a felhasználó elvégezte a dolgát, és kilépteti a szerverrõl. Ezután az XDM újra várakozni kezd a következõ felhasználóra, miközben a bejelentkezéshez és a szerver kiválasztásához szükséges képernyõket jeleníti meg. Az XDM használata Az XDM-hez tartozó démon a /usr/local/bin/xdm állomány. Ezt programot root felhasználóként bármikor tudjuk futtatni, és ez veszi kezelésbe a helyi gépen futó X szervert. Amennyiben az XDM-et a számítógép minden egyes indulása során el akarjuk indítani, egyszerûen csak adjuk hozzá a megfelelõ bejegyzést az /etc/ttys állományhoz. Ennek a formai szabályairól és használatáról bõvebben lásd . Az /etc/ttys alapértelmezett változatában az XDM démont ebben a formában találjuk meg a virtuális terminálok között: ttyv8 "/usr/local/bin/xdm -nodaemon" xterm off secure Ez a bejegyzés alapból nem aktív. Az engedélyezéséhez írjuk át az ötödik mezõben szereplõ off (kikapcsolva) értéket on (bekapcsolvá)-ra, majd indítsuk újra az &man.init.8; programot a ban leírtak szerint. Az elsõ mezõben találhatjuk a program által kezelt terminált, ez jelen esetünkben a ttyv8. Ennek megfelelõen az XDM a 9. virtuális terminálon kezdi meg a futását. Az XDM beállítása Az XDM beállításait tartalmazó könyvtár a /usr/local/lib/X11/xdm. Itt találhatjuk meg azokat az állományokat, amelyek megváltoztatásával befolyásolhatjuk az XDM megjelenését és viselkedését. Általában a következõ állományok bukkannak fel ezen a helyen: Állomány Leírás Xaccess A kliens hitelesítésének szabályrendszere. Xresources Az X erõforrásainak alapértelmezett értékei. Xservers Az ismert távoli és helyi X szerverek listája. Xsession A bejelentkezések során lefutó alapértelmezett szkript. Xsetup_* A bejelentkezõ felület indítása elõtt indítandó alkalmazásokkal kapcsolatos szkript. xdm-config A gépen futó összes X szerver globális beállításai. xdm-errors A szerver által jelentett hibák. xdm-pid A jelenleg futó XDM-hez tartozó azonosító. Ebben a könyvtárban találunk még néhány olyan programot és szkriptet, amelyekkel be tudjuk állítani a munkaasztalunkat az XDM futása alatt. Ezen állományok céljait egyenként ismertetni fogjuk. A felépítésükrõl és használatukról az &man.xdm.1; man oldala árul el többet. Az alapértelmezett beállítás egy téglalap alakú bejelentkezõ ablak, aminek tetején nagy betûkkel a gép neve olvasható, valamint alatta a Login: (felhasználói név) és Password: (jelszó) mezõk várnak kitöltésre. Ez egy remek kiindulási alap az XDM-képernyõ kinézetének megváltoztatásához. Xaccess Az XDM-mel szabályozott X szerverek által használt protokoll az X Display Manager Connection Protocol (XDMCP). Ez az állomány tartalmazza a távoli számítógépekrõl érkezõ XDMCP-kapcsolatok vezérlésére vonatkozó szabályokat. Ezt a rendszer általában figyelmen kívül hagyja, hacsak az xdm-config állományban be nem állítottuk a távoli számítógépek csatlakoztathatóságát. Alapértelmezés szerint viszont semmilyen klienst nem enged csatlakozni. Xresources Ez tartalmazza a szerverválasztó és bejelentkezõ képernyõ alapértelmezéseit. Segítségével a bejelentkeztetést végzõ program kinézetét változtathatjuk meg. Formátuma hasonló az X11 dokumentációjában leírt app-defaults állományhoz. Xservers A szerverválasztó által felkínálandó távoli X szerverek felsorolását tartalmazza. Xsession A felhasználó bejelentkezése után ez az XDM-szkript fog lefutni. Általában minden felhasználóhoz tartozik egy saját ~/.xsession szkript, ami ezt felülbírálja. Xsetup_* Ezek fognak automatikusan lefutni a szerverválasztó vagy bejelentkeztetõ felületek megjelenése elõtt. Minden általunk használt X szerverhez tartozik egy ilyen szkript, amelyek neve Xsetup_-al kezdõdik és a helyi X szerver sorszámával folytatódik (például Xsetup_0). Ezek a szkriptek általában egy-két programot, mint például az xconsole, indítanak el a háttérben. xdm-config Az app-defaults nevû állományéhoz hasonló alakban tartalmaz beállításokat a program által kezelt minden egyes X szerverhez. xdm-errors Ebben található meg az XDM által futtatni próbált X szerverek kimenete. Itt érdemes hibaüzenetek után kutatni, ha az XDM által indított X szerver valamiért megállna. Ezek az üzenetek egyébként a felhasználó ~/.xsession-errors állományába is beíródnak. Hálózati X szerver futtatása Az X szerverünkhöz csak akkor tudnak kívülrõl más felhasználók is kapcsolódni, ha átírjuk a hozzáférésre vonatkozó szabályokat és engedélyezzük rajta a kapcsolódást. Az alapértelmezett szabályok nagyon óvatosak. Ha tehát engedélyezni akarjuk a kívülrõl érkezõ kapcsolódásokat, akkor ahhoz elõször az xdm-config állományból vegyük ki az alábbi sort: ! SECURITY: do not listen for XDMCP or Chooser requests ! Comment out this line if you want to manage X terminals with xdm DisplayManager.requestPort: 0 Ezután indítsuk újra az XDM-et. Ne felejtsük el, hogy az app-defaults állományokban a megjegyzések ! (felkiáltó)jellel kezdõdnek, nem pedig a megszokott # (kettõskereszt)tel. A fentieknél természetesen szigorúbb hozzáférési szabályok is szükségesek lehetnek — ezzel kapcsolatban nézzük meg Xaccess állományban szereplõ példákat, illetve lapozzuk fel az &man.xdm.1; man oldalt. Az XDM helyett Az alapértelmezett XDM feladatát számos más program is képes ellátni. Ezek közül az egyik a kdm (a KDE része), amire ebben a fejezetben még vissza fogunk térni. A kdm különféle vizuális effekteket és egyéb kozmetikázást ígér, valamint lehetõvé teszi a felhasználók számára, hogy a bejelentkezés elõtt kiválaszthassák a használni kívánt ablakkezelõt. Valentino Vaschetto Írta: Munkakörnyezetek Ebben a szakaszban a &os;-n futó X-hez elérhetõ különbözõ munkakörnyezetekrõl (desktop environment) lesz szó. Maga a munkakörnyezet elnevezés sok mindenre utalhat egy mezei ablakkezelõtõl kezdve az asztali alkalmazások teljes garmadájáig, ahogy igaz ez a KDE vagy a GNOME esetében is. A GNOME Röviden a GNOME-ról GNOME A GNOME egy felhasználóbarát munkakörnyezet, aminek segítségével a felhasználók számára gyerekjáték a számítógép használata és beállítása. A GNOME-ban találhatunk egy panelt (az alkalmazások indítására és különféle állapotjelzõk megjelenítéséhez), egy asztalt (ahova az alkalmazások és az adatok kerülnek), szabványos asztali eszközöket és alkalmazásokat, valamint számos konvenciót, aminek mentén az alkalmazások könnyen együtt tudnak mûködni és tartani egymással az összhangot. Más operációs rendszerek vagy környezetek ismerõi otthon érezhetik magukat ebben a GNOME által nyújtott vizuális környezetben. A &os; és a GNOME kapcsolatáról bõvebb információkat a &os; GNOME Projekt honlapján találhatunk. Ezen az oldalon a GNOME telepítésérõl, beállításáról és karbantartásáról egy meglehetõsen átfogó leírást olvashatunk. A GNOME telepítése A programot könnyen fel tudjuk telepíteni csomagból vagy a Portgyûjtemény segítségével: A hálózatról a GNOME csomagját mindössze ennek a sornak a beírásával fel tudjuk telepíteni: &prompt.root; pkg_add -r gnome2 A portfa felhasználásával pedig a GNOME-ot így tudjuk forrásból telepíteni: &prompt.root; cd /usr/ports/x11/gnome2 &prompt.root; make install clean Miután a GNOME-ot sikerült feltelepítenünk, meg kell mondanunk az X szervernek, hogy az alapértelmezett ablakkezelõ helyett a GNOME-ot indítsa el. A GNOME-ot legkönnyebben a GDM, vagyis a GNOME Display Manager használatával indíthatjuk el. A GDM a GNOME részeként települ (habár alapból nincs bekapcsolva), és úgy tudjuk aktiválni, ha /etc/rc.conf állományba beírjuk a gdm_enable="YES" sort. Újraindítás után a GNOME automatikusan elindul bejelentkezéskor — nincs szükség további beállításra. A GNOME-ot parancssorból is elindíthatjuk, ha hozzá megfelelõen beállítjuk az .xinitrc nevû állományt. Ha már van egy saját .xinitrc állományunk, akkor nincs más teendõnk, mint átírni az aktuális ablakkezelõnket hívó sort a /usr/local/bin/gnome-session sorra. Ha nem csináltunk elõtte semmilyen különleges dolgot az említett konfigurációs állománnyal, akkor elegendõ csak ennyit beírnunk: &prompt.user; echo "/usr/local/bin/gnome-session" > ~/.xinitrc Ezt követõen írjuk be a startx parancsot, és a GNOME munkakörnyezete fog elindulni. Ha az XDM-hoz hasonló régebbi bejelentkeztetõ képernyõt használunk, ez a módszer nem fog mûködni. Helyette hozzunk létre egy .xsession nevû futtatható állományt, amely ezt a parancsot tartalmazza. Ehhez nyissuk meg és cseréljük ki benne a korábbi ablakkezelõnk hívását a /usr/local/bin/gnome-session utasításra: &prompt.user; echo "#!/bin/sh" > ~/.xsession &prompt.user; echo "/usr/local/bin/gnome-session" >> ~/.xsession &prompt.user; chmod +x ~/.xsession Megcsinálhatjuk azt is, hogy a bejelentkezéskor választható legyen az ablakkezelõ. A KDE-rõl bõvebben címû szakaszban látni fogjuk, hogyan tudjuk ezt a a KDE bejelentkeztetõ képernyõje, a kdm esetén beállítani. Élsimított betûtípusok a GNOME-mal GNOME élsimított betûk Az X11 a RENDER kiterjesztésén keresztül ismeri az élsimítást. A (GNOME által használt) GTK+ 2.0 és késõbbi változatai is képesek ezt a lehetõséget kihasználni. Az élsimítás beállítása a ban olvasható. Így tehát a GNOME legfrissebb verzióiban már használhatjuk az élsimítást. Ehhez menjünk az Applications Desktop Preferences Font (a magyar változatban ez az Alkalmazások A munkaasztal beállításai Betûk ) menübe, majd válasszuk vagy a Best shapes (A legszebb betûforma), Best contrast (A legjobb kontraszt) vagy a Subpixel smoothing (LCDs) (Simítás a képponton belül (LCD)) menüpontot. A GTK+-ot használó, de közvetlenül a GNOME-hoz nem tartozó alkalmazások esetén pedig állítsuk be a GDK_USE_XFT környezeti változót 1 a program indítása elõtt. A KDE KDE Röviden a KDE-rõl A KDE egy könnyen használható modern munkakörnyezet. Ízelítõül a KDE felhasználók számára felkínált lehetõségei közül: Gyönyörû, korszerû munkafelület Az asztal hálózaton keresztüli transzparens kezelése A KDE asztal és alkalmazásainak használatában egy beépített súgórendszer segíti a kényelmes és összefüggõ közlekedést A KDE alkalmazásainak összehangolt kinézete és hangulata Szabványosított menük és eszköztárak, billentyû-hozzárendelések, színsémák stb. Honosítás: a KDE több, mint 40 nyelven elérhetõ Központosított, összehangolt, párbeszédablak alapú asztalbeállítás Számos hasznos KDE-alkalmazás A KDE-hez egy Konqueror nevû böngészõ is tartozik, mely a többi &unix;-os böngészõ komoly ellenfelének bizonyul. A KDE-rõl többet a KDE honlapján olvashatunk. A KDE &os;-re vonatkozó tudnivalóiról és a hozzátartozó anyagokról a &os; KDE csapat honlapján találhatunk információkat. - &os; alatt a KDE két verziója - érhetõ el: a harmadik változat már - régóta használható, nagyon - megbízható, amely mellett viszont a - következõ generációt - képviselõ negyedik változat is - megtalálható a Portgyûjteményben. - Akár egymás mellé is - telepíthetõek. + &os; alatt a KDE két + verziója érhetõ el: a harmadik + változat már régóta + használható, nagyon megbízható, + amely mellett viszont a következõ + generációt képviselõ negyedik + változat is megtalálható a + Portgyûjteményben. Akár egymás + mellé is telepíthetõek. A KDE telepítése Ahogy a GNOME és a többi más munkakörnyezet esetében is, maga a program könnyen telepíthetõ csomagból vagy a Portgyûjtemény segítségével is: A KDE3 csomagját hálózaton keresztül így tudjuk telepíteni: &prompt.root; pkg_add -r kde A KDE4 csomagját pedig hálózaton keresztül így tudjuk telepíteni: &prompt.root; pkg_add -r kde4 A &man.pkg.add.1; magától letölti az alkalmazás legfrissebb verzióját. Ha a KDE3 környezetet forrásból akarjuk telepíteni, használjuk a portfát: &prompt.root; cd /usr/ports/x11/kde3 &prompt.root; make install clean Ha viszont a KDE4 környezetet akarjuk inkább a portfa felhasználásával forrásból telepíteni, akkor ezeket a parancsokat adjuk ki: &prompt.root; cd /usr/ports/x11/kde4 &prompt.root; make install clean Miután a KDE-t sikeresen telepítettük, tudatnunk kell az X szerverrel, hogy az alapértelmezett ablakkezelõ helyett ezt indítsa el. Ezt az .xinitrc állomány módosításával érhetjük el. KDE3 esetén: &prompt.user; echo "exec startkde" > ~/.xinitrc KDE4 esetén: &prompt.user; echo "exec /usr/local/kde4/bin/startkde" > ~/.xinitrc Mostantól pedig mindig KDE lesz az asztalunk, amikor az X Window Systemet elindítjuk a startx paranccsal. Ha az XDM-et használjuk bejelentkeztetõ képernyõként, a beállítást némileg máshogyan kell elvégeznünk. Ekkor az iménti helyett az .xsession állományt kell szerkesztenünk. A kdm-re vonatkozó utasítások a fejezet késõbbi részében találhatóak meg. A KDE-rõl bõvebben Most, miután telepítettük a KDE-t a rendszerünkre, a dolgok többsége felfedezhetõ a különféle súgók segítségével vagy egyszerûen a menükre történõ kattintással. A &windows;-hoz vagy &mac;-hez szokott felhasználók itt most már egészen otthonosan érezhetik magukat. A KDE-hez a legtöbb segítséget a saját internetes dokumentációjából nyerhetjük. A KDE a saját böngészõjét, a Konquerort tartalmazza, valamint tucatnyi ügyes alkalmazást és temérdek mennyiségû dokumentációt. A szakasz további részeiben ezért inkább olyan problémákkal foglalkozunk, amelyek megoldásai céltalan kóborlással már nem fedezhetõek fel olyan egyszerûen. A KDE bejelentkeztetõ képernyõje KDE bejelentkeztetõ képernyõ Egy többfelhasználós rendszer karbantartója minden bizonnyal szeretné üdvözölni rendszere felhasználóit egy grafikus bejelentkezõ képernyõn keresztül. A korábbiakban erre a célra az XDM-et javasoltuk. Azonban a KDE erre ajánl egy alternatívát, a kdm-et, amely jóval látványosabb és sokoldalúbb. Ez különösen abban merül ki, hogy a felhasználók (egy menün keresztül) ki tudják választani a bejelentkezés után használni kívánt munkakörnyezetet (legyen az KDE, GNOME vagy bármi más). A kdm használatához az /etc/ttys állományban található ttyv8 bejegyzést kell némileg átalakítanunk. KDE3 esetén: ttyv8 "/usr/local/bin/kdm -nodaemon" xterm on secure KDE4 esetén: ttyv8 "/usr/local/kde4/bin/kdm -nodaemon" xterm on secure Az XFce Röviden az XFce-rõl Az XFce a GNOME által használt GTK+-ra épülõ munkakörnyezet, amely azonban sokkal könnyedebb és azoknak készült, akik egy szimpla, hatékony, mindazonáltal könnyen használható és beállítható munkafelületre vágynak. Látvány szempontjából leginkább a kereskedelmi rendszereken megtalálható CDE-hez hasonlítható. Íme az XFce néhány jellemzõje: Egyszerû, könnyen kezelhetõ munkaasztal Tökéletesen konfigurálható egérrel, drag-and-droppal (vonszolás) stb. A menükkel, kisalkalmazásokkal és alkalmazásindítókkal tarkított fõpanelje hasonló a CDE paneljéhez Beépített ablak-, állomány- és hangkezelõvel, GNOME kompatibilitási modullal és még sok minden mással rendelkezik Használhatunk témákat (mivel GTK+-ra épül) Gyors, könnyû és hatékony: ideális régebbi vagy lassabb, esetleg kevés memóriával rendelkezõ számítógépekhez Az XFce-rõl részletesebben az XFce honlapján olvashatunk. Az XFce telepítése Az XFce-hez tartozik bináris csomag (legalább is az leírás készítésének pillanatában). Ezt a következõ módon tudjuk telepíteni: &prompt.root; pkg_add -r xfce4 Vagy a portgyûjtemény használatával forrásból is felrakhatjuk: &prompt.root; cd /usr/ports/x11-wm/xfce4 &prompt.root; make install clean Ezután világosítsuk fel az X szervert, hogy a következõ indulása során mi már az XFce-t kívánjuk használni. Ehhez csak ennyit kell tennünk: &prompt.user; echo "/usr/local/bin/startxfce4" > ~/.xinitrc Így az X következõ indításakor már az XFce lesz a munkakörnyezetünk. Ahogy azt már korábban is jeleztük, az XDM használata során a GNOMEban leírtak szerint létre kell hoznunk az .xsession állományt, azonban ezúttal a /usr/local/bin/startxfce4 parancs használatával. Vagy a kdm-rõl szóló szakaszban tárgyaltak mentén beállíthatjuk úgy a bejelentkeztetõ képernyõt, hogy a bejelentkezés elõtt válasszuk ki a munkakörnyezetet. diff --git a/hu_HU.ISO8859-2/share/sgml/freebsd.ent b/hu_HU.ISO8859-2/share/sgml/freebsd.ent index c546422d87..9bf311ca40 100644 --- a/hu_HU.ISO8859-2/share/sgml/freebsd.ent +++ b/hu_HU.ISO8859-2/share/sgml/freebsd.ent @@ -1,92 +1,92 @@ UNIX"> NIS"> TeX'> LaTeX'> [ OK ]"> [ Cancel ]"> [ Yes ]"> [ No ]">