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 a15404ca36..08efed1233 100644 --- a/hu_HU.ISO8859-2/books/handbook/advanced-networking/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/advanced-networking/chapter.sgml @@ -1,7814 +1,7814 @@ 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; modul betöltését jelenti. Ez a modul automatikusan betöltõdik a vezeték nélküli eszközmeghajtóval együtt. 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_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. 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 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 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 Le tudjuk korlátozni az egy felület mögül küldeni képes egyedi MAC-címeket. 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 + class="directory">/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 2c33312e3a..1c6a850bde 100644 --- a/hu_HU.ISO8859-2/books/handbook/config/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/config/chapter.sgml @@ -1,4813 +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 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. +# 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 myname.my.domain -127.0.0.1 localhost localhost.my.domain myname.my.domain +::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. NAGYON SZÉPEN KÉRÜNK mindenkit, -# hogy ne találj ki magunknak hálózati címeket, hanem használja az -# internet-szolgáltatótól kapott címet (amennyiben rendelkezünk -# ilyennel) vagy az internetes nyilvántartásban szereplõ címek közül -# valamelyiket (FTP-n keresztül jelentkezzünk be az rs.internic.net -# gépre, majd lépjünk be a /templates könyvtárba). +# 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/disks/chapter.sgml b/hu_HU.ISO8859-2/books/handbook/disks/chapter.sgml index d38e157732..659c505cfc 100644 --- a/hu_HU.ISO8859-2/books/handbook/disks/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/disks/chapter.sgml @@ -1,5838 +1,5838 @@ Háttértárak Áttekintés Ez a fejezet arról szól, hogy miként használjuk a lemezeinket a &os;-vel. Itt többek közt szó esik a memória (alapú) lemezekrõl, a hálózaton keresztül csatlakoztatott meghajtókról, a szabványos SCSI/IDE tárolóeszközökrõl és az USB felületet használó eszközökrõl. A fejezet elolvasása során megismerjük: a &os; által alkalmazott terminológiát, amivel a fizikai lemezeken elhelyezkedõ adatokat írja le (partíciók és slice-ok); hogyan bõvítsük rendszerünket további merevlemezekkel; hogyan állítsuk be a &os;-t USB tárolóeszközök használatára; hogyan állítsunk be virtuális állományrendszereket, például memórialemezeket; hogyan használjuk a kvótákat a lemezterület használatának korlátozására; hogyan védjüket meg lemezeinket titkosítással az illetéktelenektõl; &os; alatt hogyan készítsünk és írjuk CD-ket, DVD-ket; a biztonsági mentések készítésének különbözõ lehetõségeit; hogyan használjuk a &os; alatt rendelkezésünkre álló, biztonsági mentést készítõ programokat; hogyan mentsünk floppy lemezekre; mik az állományrendszerek pillanatképei és hogyan kell ezeket hatékonyan használni. A fejezet elolvasásához ajánlott: a &os; rendszermag beállításának és telepítésének ismerete () Az eszközök elnevezései A most következõ listában felsoroljuk a &os; által ismert fizikai tárolóeszközöket és a hozzájuk tartozó elnevezéseket. A fizikai lemezek elnevezésének szabályai A meghajtó típusa A meghajtóeszköz neve IDE merevlemezek ad IDE CD-meghajtók acd SCSI merevlemezek és USB tárolóeszközök da SCSI CD-meghajtók cd Különbözõ nem szabványos CD-meghajtók mcd (Mitsumi CD-ROM) és scd (Sony CD-ROM) Floppy meghajtók fd SCSI szalagos meghajtók sa IDE szalagos meghajtók ast Flash meghajtó fla (&diskonchip; Flash eszköz) RAID meghajtók aacd (&adaptec; AdvancedRAID), mlxd és mlyd (&mylex;), amrd (AMI &megaraid;), idad (Compaq Smart RAID), twed (&tm.3ware; RAID).
David O'Brien Eredetileg írta: Lemezek hozzáadása lemezek hozzáadás Tegyük fel, hogy a jelenleg egyetlen meghajtót tartalmazó rendszerünket szeretnénk bõvíteni egy új SCSI-lemez hozzáadásával. Ehhez elsõként kapcsoljuk ki a számítógépünket és szereljük be a helyére az új meghajtót a számítógép, a lemezvezérlõ és a meghajtó gyártójának utasításai alapján. Mivel ezt a mûveletet rengeteg módon lehet elvégezni, ezért ennek pontos részleteivel ez a leírás most nem foglalkozik. Jelentkezzünk be root felhasználóként. Miután beszereltük a meghajtót, a /var/run/dmesg.boot állomány végignézésével bizonyosodjuk meg róla, hogy a rendszer valóban megtalálta a lemezt. A példánk szerint ez a meghajtó tehát a da1 nevet fogja viselni, amelyet a /1 könyvtárba akarunk csatlakoztatni (ha IDE-meghajtót telepítünk, akkor a hozzátartozó eszköz neve ad1 lesz). partíciók slice-ok fdisk Mivel a &os; IBM PC kompatibilis számítógépeken fut, ezért nem szabad figyelmen kívül hagynunk a PC BIOS partícióit is. Ezek eltérnek a hagyományos BSD partícióktól. Egy PC-s lemeznek négy BIOS-os partícióbejegyzése lehet. Ha egy lemezt tényleg csak a &os;-nek szánunk, akkor használhatjuk az ún. dedikált módot. Minden más esetben a &os;-nek egy PC BIOS partícióban kell elhelyezkednie. A &os; a PC BIOS partícióit slice-nak nevezi, ezzel különbözteti ezeket a hagyományos BSD partícióktól. Dedikált esetekben is használhatjuk, de elsõsorban akkor kap fontosabb szerepet, amikor a &os;-nek más operációs rendszerekkel kell megosztani a helyet. Ezzel el tudjuk kerülni, hogy a más operációs rendszerekben megtalálható, nem &os; alapú fdisk parancs megzavarodjon. A slice-ok használatakor a meghajtó /dev/da1s1e néven kerül hozzáadásra. Így kell olvasni: egyes SCSI lemezes egység (második SCSI lemez), elsõ slice (elsõ PC BIOS partíció) és e BSD partíció. A dedikált esetben a meghajtó neve viszont egyszerûen csak /dev/da1e. Mivel a &man.bsdlabel.8; 32 bites egész számokat használ a szektorok számának tárolására, ezért lemezenként csak 2^32-1 szektort tud ábrázolni, ami az esetek többségében 2 TB méretû címezhetõ területet jelent. Az &man.fdisk.8; formátuma szerint sem a kezdõszektor, sem a hossz nem lehet 2^32-1-nél több, amivel így a partíciókat 2 TB, a lemezeket pedig 4 TB méretûre korlátozza. A &man.sunlabel.8; formátuma partíciónként 2^32-1 szektort enged meg és összesen 8 partíciót, amely ezáltal 16 TB terület lefedését teszi lehetõvé. Nagyobb lemezekhez &man.gpt.8; partíciók használatosak. A &man.sysinstall.8; használatával sysinstall lemezek hozzáadása su Közlekedés a <application>sysinstall</application> programban A sysinstall könnyen használható menüinek segítségével az új lemezen pillanatok alatt létre tudunk hozni partíciókat és megcímkézni ezeket. Ehhez vagy root felhasználóként jelentkezzünk be a rendszerbe, vagy adjuk ki a su parancsot. A sysinstall parancs kiadása után lépjünk be a Configure (Beállítások) menübe. A &os; Configuration Menu menüben ezután keressük meg és válasszuk ki az Fdisk menüpontot. Az <application>fdisk</application> partíciószerkesztõ Miután eljutottunk az fdisk alkalmazáshoz, az A lenyomásával felajánlhatjuk az egész lemezt a &os; számára. Amikor elõkerül a kérdés, hogy remain cooperative with any future possible operating systems (mûködõképes maradjon-e a késõbbiekben telepítendõ operációs rendszerekkel), akkor válaszoljuk rá YES-szel (tehát igen). A W gomb lenyomásával írjuk a lemezre a most elvégzett változtatásokat. Ezután már a Q használatával ki is léphetünk az FDISK szerkesztõbõl. A következõ lépésben a Master Boot Record-ról fognak minket megkérdezni. Mivel most egy már mûködõ rendszert bõvítünk, ezért a válaszunk erre None lesz. A lemezcímkék szerkesztése BSD partíciók Most lépjünk ki a sysinstall alkalmazásból és indítsuk el újra. Kövessük az iménti útmutatásokat, de ezúttal a Label menüpontot válasszuk ki. Ezzel a Disk Label Editor-ba vagyis a lemezcímkék szerkesztõjéhez jutunk. Itt fogjuk létrehozni a hagyományos BSD partíciókat. Egy lemezen nyolc ilyen partíció lehet, a-tól h-ig. Közülük néhány partíció címkéjét megkülönböztetjük. Az a partíció jelöli a rendszer indításához használt partíciót, a gyökérpartíciót (/). Tehát a partíció csak a rendszerlemezünkön szerepelhet (tehát ahonnan indul a rendszer). A b partíció a lapozáshoz használt partíciókat jelöli és több lemezen is szerepelhet. A c partíción keresztül lehet elérni az egészt lemezt dedikált módban vagy az egész &os; slice-ot slice módban. A többi partíció tetszõlegesen felhasználható. A sysinstall címkeszerkesztõje az e betûvel szereti megjelölni a sem nem rendszerindító, sem nem lapozó partíciókat. A címkeszerkesztõben egyetlen állományrendszert a C lenyomásával lehet készíteni. Amikor erre válaszul megkérdezi a típusát (FS (állományrendszer) vagy swap (lapozóterület) legyen), akkor válasszuk az FS beállítást és adjuk meg a csatlakozási pontját (például /mnt). Amikor a lemezt telepítés után (post-install) adjuk hozzá, akkor a sysinstall valójában nem hoz létre hozzá bejegyzéseket az /etc/fstab állományban, ezért a csatlakozási pont megadása nem is feltétlenül fontos. Most már készen állunk arra, hogy rögzítsük az új címkét a lemezre és létrehozzunk vele egy állományrendszert. Ehhez nyomjuk le a W gombot. Ne foglalkozzunk vele, ha a sysinstall nem képes csatlakoztatni az új partíciót. Ha ezzel megvagyunk, akkor lépjünk ki a címkeszerkesztõbõl és a sysinstallból is. Befejezés Most már csak annyi teendõnk maradt, hogy felvegyük az /etc/fstab állományba az új lemezhez tartozó bejegyzést. Parancssoros eszközök használatával Slice módban Ezzel a beállítással a lemezünkre késõbb más operációs rendszereket is telepíthetünk, és nem okoz gondot a saját fdisk segédprogramjaik mûködésében. Az új lemezek telepítésénél ezt a módszer ajánlatos követni. A dedikált módot viszont csak abban az esetben használjuk, ha erre nyomós okunk van! &prompt.root; dd if=/dev/zero of=/dev/da1 bs=1k count=1 &prompt.root; fdisk -BI da1 # inicializáljuk az új lemezt &prompt.root; bsdlabel -B -w da1s1 auto # címkézzük meg &prompt.root; bsdlabel -e da1s1 # szerkeszzük át a frissen létrehozott címkét és vegyünk fel egy új partíciót &prompt.root; mkdir -p /1 &prompt.root; newfs /dev/da1s1e # ismételjük meg minden létrehozott partícióhoz &prompt.root; mount /dev/da1s1e /1 # csatlakoztassuk a partíció(ka)t &prompt.root; vi /etc/fstab # vegyük fel a megfelelõ bejegyzés(eke)t az /etc/fstab állományba IDE-lemezek esetén azad eszközt a da eszközzel helyettesítsük. Dedikált módban OS/2 Amennyiben az új meghajtót nem akarjuk megosztani egyetlen más operációs rendszerrel sem, használhatjuk a dedicated (dedikált) módot. Ne felejtsük el azonban, hogy ez képes összezavarni a Microsoft operációs rendszereit, habár ebbõl semmilyen kárunk nem fog származni. Az IBM &os2; operációs rendszere azonban kisajátít minden olyan partíciót, amelyet nem tud olvasni. &prompt.root; dd if=/dev/zero of=/dev/da1 bs=1k count=1 &prompt.root; bsdlabel -Bw da1 auto &prompt.root; bsdlabel -e da1 # létrehozzuk az `e' partíciót &prompt.root; newfs /dev/da1e &prompt.root; mkdir -p /1 &prompt.root; vi /etc/fstab # felvesszük a /dev/da1e partíciót &prompt.root; mount /1 Egy másik megoldás: &prompt.root; dd if=/dev/zero of=/dev/da1 count=2 &prompt.root; bsdlabel /dev/da1 | bsdlabel -BR da1 /dev/stdin &prompt.root; newfs /dev/da1e &prompt.root; mkdir -p /1 &prompt.root; vi /etc/fstab # felvesszük a /dev/da1e partíciót &prompt.root; mount /1 RAID Szoftveres RAID Christopher Shumway Eredetileg készítette: Jim Brown Ellenõrizte: RAIDszoftveres RAIDCCD Összefûzött lemezek beállítása A nagyobb méretû háttértárolók kiválasztásánál a legfontosabb tényezõk a sebesség, megbízhatóság és a költség. Nagyon ritkán lehet csak ezt a hármat egyensúlyba hozni: általában a gyors és megbízható tárolóeszközök sok pénzbe kerülnek, valamint a költségek megtakarításához vagy a sebességet vagy pedig a megbízhatóságot kell feláldoznunk. A továbbiakban egy olyan rendszert mutatunk be, ahol a elsõsorban a költségek, majd csak ezután a sebesség és megbízhatóság kerültek elõtérben. A rendszer adatátviteli sebességét a hálózat korlátozza. Habár emellett a megbízhatóság is nagyon fontos, a tárgyalt összefûzött meghajtó (Concenated Disk, CCD) csak adatokat szolgáltat és a teljes tartalma bármikor visszaállítható, mivel rendelkezésre áll CD-n. A feladat elvégzésére alkalmas háttértároló kiválasztásában elsõként a saját elvárásainkat kell tudnunk megfogalmazni. Ha nekünk jobban számít az árnál a sebesség vagy a megbízhatóság, akkor a mostaniaktól némileg eltérõ konfigurációt kell majd építenünk. A hardver telepítése A rendszert tartalmazó IDE-lemez mellett három darab, egyenként 30 GB-os 5400-as percenkénti fordulatszámú Western Digital gyártmányú merevlemez alkotja majd a létrehozni kívánt, kb. 90 GB összméretû összefûzött lemezt. Ideális esetben minden IDE-lemez saját külön vezérlõn és kábelen van, de a költségek csökkentése miatt nem használtunk további IDE-vezérlõket. Ehelyett inkább jumperekkel úgy állítottuk be a lemezeket, hogy minden vezérlõre egy mester (master) és egy szolga (slave) módú merevlemez kapcsolódjon. A beszerelés után beállítottuk a rendszer BIOS-át, hogy automatikusan felismerje a csatlakoztatott lemezeket. De ami még fontosabb, hogy a &os; is észlelte ezeket az indítás során: ad0: 19574MB <WDC WD205BA> [39770/16/63] at ata0-master UDMA33 ad1: 29333MB <WDC WD307AA> [59598/16/63] at ata0-slave UDMA33 ad2: 29333MB <WDC WD307AA> [59598/16/63] at ata1-master UDMA33 ad3: 29333MB <WDC WD307AA> [59598/16/63] at ata1-slave UDMA33 Ha a &os; nem látná az összes lemezt, akkor ellenõrizzük a jumperek helyes beállítását. Napjainkban a legtöbb IDE-meghajtón találunk egy Cable Select jumpert is. Ezzel nem a mester/szolga módot állítjuk be! A megfelelõ jumper beazonosításához olvassuk el a meghajtóhoz tartozó dokumentációt. A következõ lépésben azt vesszük nagyító alá, hogyan lehet ezeket az állományrendszer részévé tenni. Ezzel kapcsolatban a &man.vinum.8; () és a &man.ccd.4; elolvasása ajánlatos. Erre a célra itt most a &man.ccd.4; használatát választottuk. A CCD beállítása A &man.ccd.4; meghajtó segítségével több ugyanolyan lemezt tudunk összefûzni egyetlen logikai állományrendszerré. A &man.ccd.4; használatához arra is szükségünk van, hogy a &man.ccd.4; támogatása jelen legyen a rendszermagban. A következõ sor tegyük bele a rendszermag konfigurációs állományába, fordítsuk újra és telepítsük a rendszermagot: device ccd A &man.ccd.4; támogatása modulként is betölthetõ. A &man.ccd.4; beállításához elõször a &man.bsdlabel.8; programmal meg fel kell címkéznünk a lemezeket: bsdlabel -w ad1 auto bsdlabel -w ad2 auto bsdlabel -w ad3 auto Így létrejön egy-egy BSD típusú címke a ad1c, ad2c és ad3c eszközökre, amely így lefedi a lemez egész területét. Most pedig változtassuk meg a lemezcímke típusát. Ehhez használjuk ismét a &man.bsdlabel.8; programot: bsdlabel -e ad1 bsdlabel -e ad2 bsdlabel -e ad3 Az EDITOR környezeti változóban megadott szövegszerkesztõvel (ez általában a &man.vi.1;) megnyílik minden egyes lemezhez a jelenlegi lemezcímke. Egy módosítatlan lemezcímke valahogy így néz ki: 8 partitions: # size offset fstype [fsize bsize bps/cpg] c: 60074784 0 unused 0 0 0 # (Cyl. 0 - 59597) A &man.ccd.4; számára hozzunk létre egy új e partíciót. Ezt lényegében a c partíció lemásolásával keletkezik, de nála az (az állományrendszer típusa) oszlopban mindenképpen 4.2BSD szerepeljen! A lemezcímke most már valahogy így fog kinézni: 8 partitions: # size offset fstype [fsize bsize bps/cpg] c: 60074784 0 unused 0 0 0 # (Cyl. 0 - 59597) e: 60074784 0 4.2BSD 0 0 0 # (Cyl. 0 - 59597) Az állományrendszer kiépítése Most, miután felcímkéztük az összes lemezünket, lássunk neki a &man.ccd.4; kiépítésének. Ezt a &man.ccdconfig.8; meghívásával és az alábbihoz hasonló paraméterek átadásával tehetjük meg: ccdconfig ccd0 32 0 /dev/ad1e /dev/ad2e /dev/ad3e A paraméterek rövid leírása és használata: Az elsõ paraméter a létrehozandó eszköz, ami jelen esetünkben a /dev/ccd0c. A /dev/ részt nem kötelezõ megadni. A kihagyás nagysága az állományrendszerben. A kihagyás határozza meg a lemezblokkban alkalmazott csíkozás (striping) vastagságát, ami általában 512 byte. Ennek megfelelõen a 32-es kihagyás 16 384 byte-os csíkokat ad meg. A &man.ccdconfig.8; beállításai. Ha engedélyezni akarjuk a lemezek tükrözését, akkor itt megadhatjuk. Mivel ez a konfiguráció most nem nyújt tükrözést a &man.ccd.4; számára, ezért állítsuk nullára (0). A &man.ccdconfig.8; parancsnak utolsóként azokat az eszközöket kell felsorolni, amelyeket tömbbe akarunk fûzni. Minden eszközt teljes elérési úttal adjuk meg. A &man.ccdconfig.8; futtatása után a &man.ccd.4; beállítódik. Most már állományrendszert is rakhatunk rá. A &man.newfs.8; man oldalról szedjük össze a szükséges paraméterezést, vagy egyszerûen csak gépeljünk be ennyit: newfs /dev/ccd0c Az egész önmûködõvé tétele A &man.ccd.4; eszközt általában minden egyes indítás után használni akarjuk. Ennek eléréséhez elõször ezt be kell állítanunk. Az alábbi parancs kiadásával írassuk be a jelenlegi beállítasainkat tükrözõ /etc/ccd.conf állományt: ccdconfig -g > /etc/ccd.conf Az újraindítás során az /etc/rc parancs futtatja le a ccdconfig -C parancsot, ha az /etc/ccd.conf állomány létezik. Ez automatikusan beállítja a &man.ccd.4; eszközöket, így ilyenkor tudjuk csatlakoztatni is ezeket. Ha egyfelhasználós módban indítjuk a rendszert, mielõtt még a &man.mount.8; paranccsal csatlakoztatni tudnánk a &man.ccd.4; eszközt, a tömb beállításához meg kell hívnunk a következõ parancsot: ccdconfig -C Ha a rendszerindításkor automatikusan csatlakoztatni akarjuk a &man.ccd.4; eszközt, akkor az /etc/fstab állományba helyezzünk el egy hozzátartozó bejegyzést: /dev/ccd0c /media ufs rw 2 2 A Vinum kötetkezelõ RAID szoftveres RAID Vinum A Vinum kötetkezelõ egy blokkos eszközmeghajtó, ami virtuális lemezes meghajtókat valósít meg. Elkülöníti a lemezes hardvereszközöket a blokkos eszközmeghajtók felületétõl és a kettõ között úgy képezi le az adatokat, hogy a hagyományos lemezes tárolással szemben megnövekedett rugalmasságot, teljesítményt és megbízhatóságot kapunk. A &man.vinum.8; ismeri a RAID-0, RAID-1 és RAID-5 modelleket egyaránt, melyeket önmagukban és együttesen kombinálva is használhatunk. A bõvebben ismerteti a &man.vinum.8; rendszerét. Hardveres RAID RAID hardveres A &os; rengeteg különbözõ típusú hardveres RAID-vezérlõt ismer. Ezek az eszközök a &os; külön erre a célra szánt támogatása nélkül képesek vezérelni a RAID-alrendszert. A rajta levõ BIOS segítségével a kártya a legtöbb lemezmûveletet egyedül kezeli. A következõkben egy Promise IDE RAID vezérlõt alkalmazó rendszert fogunk beállítani. Miután telepítettük a kártyát és indítjuk a rendszert, bekéri a szükséges információkat. Kövessük az utasításokat és lépjünk be a kártya beállító képernyõjére. Itt tudjuk kombinálni az összes csatlakoztatott meghajtónkat. Amikor ezzel a végeztünk, a lemezek egyetlen lemezként fognak a &os; számára viselkedni. A többi RAID-szint is ehhez hasonlóan állítható be. Az ATA RAID-1 tömbök újraszervezése A &os; lehetõséget a tömbben levõ meghibásodott eszközök menet közben elvégezhetõ cseréjére. Ehhez arra van szükségünk, hogy még újraindítás elõtt elcsípjük a hibát. Hiba esetén valami hasonlót fogunk látni a /var/log/messages állományban vagy a &man.dmesg.8; kimenetében: ad6 on monster1 suffered a hard error. ad6: READ command timeout tag=0 serv=0 - resetting ad6: trying fallback to PIO mode ata3: resetting devices .. done ad6: hard error reading fsbn 1116119 of 0-7 (ad6 bn 1116119; cn 1107 tn 4 sn 11)\\ status=59 error=40 ar0: WARNING - mirror lost További információkat az &man.atacontrol.8; programtól szerezhetünk: &prompt.root; atacontrol list ATA channel 0: Master: no device present Slave: acd0 <HL-DT-ST CD-ROM GCR-8520B/1.00> ATA/ATAPI rev 0 ATA channel 1: Master: no device present Slave: no device present ATA channel 2: Master: ad4 <MAXTOR 6L080J4/A93.0500> ATA/ATAPI rev 5 Slave: no device present ATA channel 3: Master: ad6 <MAXTOR 6L080J4/A93.0500> ATA/ATAPI rev 5 Slave: no device present &prompt.root; atacontrol status ar0 ar0: ATA RAID1 subdisks: ad4 ad6 status: DEGRADED A lemez biztonságos eltávolításához elõször válasszuk le (detach) a meghibásodott lemezhez tartozó csatornát: &prompt.root; atacontrol detach ata3 Cseréljük ki a lemezt. Csatlakoztassuk újra (attach) az ATA csatornát: &prompt.root; atacontrol attach ata3 Master: ad6 <MAXTOR 6L080J4/A93.0500> ATA/ATAPI rev 5 Slave: no device present Tartalékként (spare) adjuk hozzá az új lemezt a tömbhöz: &prompt.root; atacontrol addspare ar0 ad6 Szervezzük újra (rebuild) a tömböt: &prompt.root; atacontrol rebuild ar0 A folyamat elõrehaladását a következõ parancs begépelésével tudjuk figyelni: &prompt.root; dmesg | tail -10 [a kimenet többi része] ad6: removed from configuration ad6: deleted from ar0 disk1 ad6: inserted into ar0 disk1 as spare &prompt.root; atacontrol status ar0 ar0: ATA RAID1 subdisks: ad4 ad6 status: REBUILDING 0% completed Várjunk a mûvelet befejezõdéséig. Marc Fonvieille Írta: USB tárolóeszközök USB lemezek Manapság már számos külsõ tárolóeszköz az USB (Universal Serial Bus) közvetítésével csatlakozik a számítógéphez: merevlemezek, pen drive-ok, CD-írók stb. A &os; ezeket az eszközöket is ismeri. Beállítás A USB tárolóeszközöket kezelõ meghajtó, az &man.umass.4; felelõs az USB alapú tárolóeszközök támogatásáért. Ha a GENERIC rendszermagot használjuk, akkor semmit sem kell változtatnunk. Ha saját rendszermagunk van, akkor gondoskodjunk róla, hogy a következõ sorokat beraktuk a rendszermag beállításait tartalmazó állományba: device scbus device da device pass device uhci device ohci device usb device umass Az &man.umass.4; meghajtó a SCSI alrendszeren keresztül éri el az USB tárolóeszközöket, tehát az USB eszközeinket a rendszer SCSI eszközként látja. Az alaplapon található USB chipkészlet típusától függõen vagy csak a device uhci vagy pedig a device ohci bejegyzésre lesz szükségünk. De abból sem származik kárunk, ha mind a kettõt meghagyjuk. Ha módosítani kellett a konfigurációs állományt, akkor ne felejtsük el újrafordítani és telepíteni sem a rendszermagot. Ha az USB eszközünk egy CD- vagy DVD-író, akkor a következõ sorral a SCSI CD-meghajtók meghajtóját, a &man.cd.4; eszközt kell beépítenünk a rendszermagba: device cd Mivel az író is SCSI eszközként látszik, ezért az &man.atapicam.4; nem szerepelhet a rendszermag beállításai között. A &os;-ben a USB 2.0-ás vezérlõk támogatásához azonban a következõ sort is fel kell vennünk a konfigurációs állományba: device ehci Ha mellette tovább is szükségünk lenne az USB 1.X támogatásra, akkor hagyjuk meg a &man.uhci.4; és &man.ohci.4; eszközmeghajtókat. A beállítások kipróbálása A beállításaink készen állnak a kipróbálásra: csatlakoztassuk a számítógéphez az USB eszközünket és a rendszerüzeneteket tároló pufferben (&man.dmesg.8;) hamarosan meg is jelenik a hozzátartozó meghajtó: umass0: USB Solid state disk, rev 1.10/1.00, addr 2 GEOM: create disk da0 dp=0xc2d74850 da0 at umass-sim0 bus 0 target 0 lun 0 da0: <Generic Traveling Disk 1.11> Removable Direct Access SCSI-2 device da0: 1.000MB/s transfers da0: 126MB (258048 512 byte sectors: 64H 32S/T 126C) Természetesen a gyártóra, márkára, az eszköz leírójára (da0) és egyebekre vonatkozó részletek eltérhetnek. Mivel az USB eszköz SCSI eszközként látszik, ezért a camcontrol parancs használható a rendszerhez csatlakoztatott USB tárolóeszközök listázásához: &prompt.root; camcontrol devlist <Generic Traveling Disk 1.11> at scbus0 target 0 lun 0 (da0,pass0) Ha a meghajtón állományrendszer is található, akkor képesek vagyunk csatlakoztatni. A elolvasása segíthet az USB meghajtón partíciókat kialakítani és formázni, amennyiben szükséges. Ha az eszközt normál felhasználókkal is csatlakoztathatóvá akarjuk tenni, akkor további lépések megtételére is szükségünk lesz. Elõször is a felhasználóknak valahogy el kell tudniuk érniük az USB tárolóeszköz csatlakoztatásakor keletkezõ eszközöket. Ezt úgy tudjuk megoldani, ha az érintett felhasználókat felvesszük az operator csoportba. Ebben a &man.pw.8; lehet a segítségünkre. Másodsorban amikor ezek az eszközök létrejönnek, az operator csoportnak tudniuk kell ezeket olvasniuk és írniuk. Ezt úgy tudjuk megvalósítani, ha felvesszük a következõ sorokat az /etc/devfs.rules állományba: [localrules=1] add path 'da*' mode 0660 group operator Ha viszont vannak SCSI lemezeink is rendszerben, akkor a helyzet egy kicsit megváltozik. Tehát például a rendszerben már eleve vannak da0, da1 és da2 néven lemezek, akkor a második sort ennek megfelelõen változtassuk meg: add path 'da[3-9]*' mode 0660 group operator Ezzel kizárunk minden, korábban már létezõ lemezt az operator csoportból. Emellett még az /etc/rc.conf állományban engedélyeznünk kell a saját &man.devfs.rules.5; szabályrendszerünket is: devfs_system_ruleset="usb_rules" Ezt követõen be kell állítanunk a rendszermagban, hogy a hagyományos felhasználók képesek legyenek állományrendszereket csatlakoztatni. Ezt a legkönnyebb úgy tudjuk megtenni, ha az /etc/sysctl.conf állományba felvesszük a következõ sort: vfs.usermount=1 Azonban ne felejtsük el, hogy ez csak a rendszer következõ indításától él. De a &man.sysctl.8; parancs használatával is beállíthatjuk ezt az értéket. Az utolsó lépésben hozzunk létre egy könyvtárat az állományrendszer csatlakoztatásához. Ezt a könyvtárat az a felhasználó fogja birtokolni, aki az állományrendszert csatlakoztatnia akarja. Ez például root felhasználóként úgy tudjuk megtenni, ha a felhasználónak létrehozunk egy könyvtárat /mnt/felhasználó néven (ahol a felhasználó nevet cseréljük a tényleges felhasználó nevére): &prompt.root; mkdir /mnt/felhasználó &prompt.root; chown felhasználó:felhasználó /mnt/felhasználó Most tegyük fel, hogy csatlakoztatnuk egy USB pen drive-ot és ennek megfelelõen megjelenik a /dev/da0s1 eszköz. Mivel az ilyen eszközökre általában gyárilag FAT állományrendszert tesznek, ezért így kell ezeket csatlakoztatni a &man.mount.8; paranccsal: &prompt.user; mount -t msdosfs -m 644 -M 755 /dev/da0s1 /mnt/felhasználó Ha leválasztjuk az eszközt (miután kiadtuk a &man.umount.8; parancsot), akkor a rendszerüzenetek között valami ilyesmit fogunk látni: umass0: at uhub0 port 1 (addr 2) disconnected (da0:umass-sim0:0:0:0): lost device (da0:umass-sim0:0:0:0): removing device entry GEOM: destroy disk da0 dp=0xc2d74850 umass0: detached A témáról bõvebben A Lemezek hozzáadása és az Állományrendszerek csatlakoztatása és leválasztása címû szakaszok elolvasása mellett a következõ man oldalakat is ajánljuk: &man.umass.4;, &man.camcontrol.8; és &man.usbdevs.8;. Mike Meyer Írta: Lézeres tárolóeszközök (CD-k) létrehozása és használata CD-k létrehozása Bevezetés A CD-k számos lehetõségünkben eltérnek a hagyományos lemezektõl. Kezdetben a felhasználók nem is voltak képesek írni ezeket. Olyannak tervezték, hogy a fejek sávok közti mozgásából fakadó késleltetés nélkül lehessen folyamatosan olvasni. A szállítása a maga idejében sokkal könnyebb volt minden vele egyforma méretû eszköznél. A CD-ken is találhatunk sávokat, azonban ez csak a folyamatosan olvasható adat egy szakaszát jelenti, nem pedig a lemez fizikai tulajdonságát. Ha &os;-n akarunk CD-t készíteni, akkor ehhez elõször össze kell állítanunk a CD egyes sávjaira kerülõ adatokat és ezután rögzíteni ezeket a sávokat a CD-n. ISO 9660 állományrendszerek ISO 9660 Az ISO 9660 állományrendszert úgy tervezték, hogy megbirkózzon ezekkel az eltérésekkel. Sajnos ezzel együtt kõbe vésték az állományrendszerek akkoriban érvényes korlátozásait is. Szerencsére lehetõséget ad bõvítésre, ezáltal a helyesen megírt CD-k képesek úgy átlépni ezeket a határokat, hogy közben az általuk alkalmazott kiterjesztéseket nem ismerõ rendszerekkel is együtt tudnak mûködni. sysutils/cdrtools A sysutils/cdrtools port tartalmaz egy &man.mkisofs.8; nevû programot, amellyel létre tudunk hozni ISO 9660 típusú állományrendszert tartalmazó adatállományt. Többféle kiterjesztést is ismer, amit majd a lentebb ismertett opciókkal érhetünk el. CD-író ATAPI A CD írásához használt konkrét segédeszköz attól függ, hogy ATAPI vagy esetleg másmilyen írónk van. Az ATAPI CD-írók az alaprendszer részeként elérhetõ burncd programon keresztül használhatóak. A SCSI és USB CD-írók esetén pedig a sysutils/cdrtools portban megtalálható cdrecord programot használhatjuk. Az ATAPI/CAM modul segítségével a cdrecord és más SCSI-írókra készült programokat is tudunk használni ATAPI hardvereken. Ha a CD-író szoftverünket grafikus felhasználói felületen keresztül szeretnénk használni, akkor az X-CD-Roast vagy a K3b alkalmazásokat érdemes szemügyre vennünk. Ezek az eszközök elérhetõek csomagként vagy a sysutils/xcdroast és sysutils/k3b portokból. ATAPI hardver esetén az X-CD-Roast és a K3b alkalmazások használatához szükségünk lesz az ATAPI/CAM modulra. mkisofs A sysutils/cdrtools port részeként elérhetõ &man.mkisofs.8; program képes a &unix; típusú állományrendszer könyvtárszerkezete alapján egy ISO 9660 típusú állományrendszert tartalmazó image-et készíteni. Legegyszerûbb módon így használhatjuk: &prompt.root; mkisofs -o image.iso /az/elérési/út állományrendszerek ISO 9660 Ezzel a paranccsal egy olyan image.iso nevû állományt hozunk létre, amely /az/elérési/út által megadott helyen található könyvtárszerkezetet mintázza ISO 9660 állományrendszer formájában. A folyamat során minden olyan állományt leképez szabványos ISO 9660 állományrendszerbeli névre, amely megfelel a szabvány elvárásainak, és kihagy minden olyan állományt, amely nem jellemzõ az ISO állományrendszerekre. állományrendszerek HFS állományrendszerek Joliet Számos opció lehet segítségünkre az ilyenkor felbukkanó akadályok leküzdésében. Ezek közül különösen fontos az , amely a &unix; rendszerek számára megszokott Rock Ridge kiterjesztéseket, valamint a , amely a Microsoft rendszerekben használt Joliet kiterjesztéseit, és végül a , amely a &macos; alatt létrehozott HFS állományrendszerek kiterjesztéseit engedélyezi. A kizárólag csak &os; rendszereken használt CD-k esetében a megadásával kapcsolhatjuk ki az állománynevek mindenféle korlátozását. Az beállítás használatával olyan állományrendszer képét hozzuk létre, amely teljesen megegyezik a parancsban megadott könyvtárból induló fa tartalmával, habár több módon is sérti az ISO 9660 szabvány elõírásait. CD-k rendszerindításhoz Az utolsó általános jelleggel használható beállítás a . Ezzel lehet megadni az El Torito szabványnak megfelelõ rendszerindító CD készítéséhez szükséges rendszerindító image elérését. Ennél a beállításnál tehát meg kell adni a rendszerindításhoz használt lemez image-ét, amely a CD tartalmát magában foglaló könyvtárszerkezetben található valahol. A &man.mkisofs.8; alapértelmezés szerint egy ún. floppy emulációs módban hozza létre az ISO image-et, ezért a rendszerindításhoz használatos lemez image-ének pontosan 1200, 1440 vagy 2880 KB méretûnek kell lennie. Egyes rendszerbetöltõk, mint amilyen például a &os; terjesztéséhez használt lemezeken található, nem használják ezt az emulációt. Ilyen helyzetekben a kapcsolót kell megadni. Tehát ha a /tmp/sajátboot könyvtárban van egy indítható &os; rendszerünk, amelyben a /tmp/sajátboot/boot/cdboot a rendszerindító lemez image-e, akkor egy /tmp/indítható.iso nevû ISO 9660 formátumú állományrendszert tartalmazó image-et például így tudunk elkészíteni: &prompt.root; mkisofs -R -no-emul-boot -b boot/cdboot -o /tmp/indítható.iso /tmp/sajátboot Miután ezt megtettük, és a rendszermagunkban benne van az md eszköz támogatása, csatlakoztathatjuk is az állományrendszert: &prompt.root; mdconfig -a -t vnode -f /tmp/indítható.iso -u 0 &prompt.root; mount -t cd9660 /dev/md0 /mnt Ezután már össze tudjuk vetni az /mnt és /tmp/sajátboot könyvtárak egyezõségét. A &man.mkisofs.8; viselkedését több más opcióval tudjuk finomhangolni, mint például az ISO 9660 kiosztás módosítása vagy a Joliet és HFS lemezek készítése. A &man.mkisofs.8; man oldalon mindezekrõl bõvebben olvashatunk. burncd CD-k írása Ha ATAPI CD-írónk van, akkor a burncd paranccsal írhatjuk az ISO image-et a lemezre. A burncd az alaprendszer része, és /usr/sbin/burncd néven érhetõ el. A használata igen egyszerû, csupán pár paramétere van: &prompt.root; burncd -f eszköz data image.iso fixate Ezzel a paranccsal rámásoljuk az image.iso állományt az eszköz eszközre. Az alapértelmezett eszköz a /dev/acd0. A &man.burncd.8; man oldalán találjuk meg az írási sebességgel, a CD írás utáni kiadásával és az audio lemezek írásával kapcsolatos beállításokat. cdrecord Ha nincs ATAPI CD-írónk, akkor az íráshoz a cdrecord parancsot kell használnunk. A cdrecord nem az alaprendszer része: vagy a sysutils/cdrtools portból vagy a neki megfelelõ csomagból kell telepítenünk. Az alaprendszerben végbemenõ változások miatt a program bináris változatai hibázhatnak, aminek következtében csak poháralátéteket fogunk tudni gyártani. Ezért a rendszerrel együtt érdemes frissíteni ezt a portot is. Vagy ha a -STABLE verziót használjuk, akkor mindig érdemes a port elérhetõ legújabb verziójára frissíteni. Miközben a cdrecord számos paraméterrel rendelkezik, az alapvetõ használata mégis egyszerûbb a burncd parancsénál. Egy ISO 9660 formátumú image-et ugyanis a következõ módon tudunk felírni lemezre: &prompt.root; cdrecord dev=eszköz image.iso A cdrecord használatának trükkös része a megfelelõ eszköz megtalálása, tehát a beállítás helyes megadása. Ehhez használjuk a cdrecord paraméterét, amely az alábbihoz hasonló eredményt fog produkálni: CD-k írása &prompt.root; cdrecord -scanbus Cdrecord-Clone 2.01 (i386-unknown-freebsd7.0) Copyright (C) 1995-2004 Jörg Schilling Using libscg version 'schily-0.1' scsibus0: 0,0,0 0) 'SEAGATE ' 'ST39236LW ' '0004' Disk 0,1,0 1) 'SEAGATE ' 'ST39173W ' '5958' Disk 0,2,0 2) * 0,3,0 3) 'iomega ' 'jaz 1GB ' 'J.86' Removable Disk 0,4,0 4) 'NEC ' 'CD-ROM DRIVE:466' '1.26' Removable CD-ROM 0,5,0 5) * 0,6,0 6) * 0,7,0 7) * scsibus1: 1,0,0 100) * 1,1,0 101) * 1,2,0 102) * 1,3,0 103) * 1,4,0 104) * 1,5,0 105) 'YAMAHA ' 'CRW4260 ' '1.0q' Removable CD-ROM 1,6,0 106) 'ARTEC ' 'AM12S ' '1.06' Scanner 1,7,0 107) * Itt felsorolásra kerülnek a beállítás értékeként felhasználható eszközök. Keressük meg köztük a CD írónkat és a értékének a három vesszõvel elválasztott számot adjuk meg. Ebben az esetben a CD-író eszköz most az 1,5,0 lesz, tehát itt a helyes paraméterezés . Ezt az értékét könnyebben is meg lehet adni. Ennek részleteirõl a &man.cdrecord.1; man oldalán olvashatunk. Abban az esetben is érdemes fellapoznunk, ha az audio sávok írásáról, az írási sebesség korlátozásáról vagy más hasonló dolgokról akarunk olvasni. Audio CD-k másolása Audio CD-t úgy tudunk másolni, ha elõször állományok sorozatába mentjük a lemez tartalmát, majd ezeket az állományokat egy üres CD-re írjuk. Ennek konkrét folyamata azonban némileg eltér az ATAPI- és SCSI-meghajtók használata során. SCSI-meghajtók esetén A cdda2wav programmal mentsük le a lemez tartalmát. &prompt.user; cdda2wav -v255 -D2,0 -B -Owav A cdrecord paranccsal írjuk fel a .wav kiterjesztésû állományokat. &prompt.user; cdrecord -v dev=2,0 -dao -useinfo *.wav Gondoskodjunk róla, hogy a 2,0 értéket a nak megfelelõen helyesen állítottuk be. ATAPI-meghajtók esetén Az ATAPI CD meghajtója az egyes sávokat /dev/acddtnn néven teszi elérhetõvé, ahol a d a meghajtó sorszáma, a nn a sáv két számjeggyel kiírt sorszáma, amelyet szükség szerint balról nullával egészítenek ki. Így tehát az elsõ meghajtó elsõ sávja a /dev/acd0t01, a második a /dev/acd0t02, a harmadik a /dev/acd0t03 és így tovább. Ellenõrizzük, hogy ezek az eszközök jelen vannak a /dev könyvtárban. Amennyiben hiányoznának, kényszerítsük ki a lemez újbóli beolvasását: &prompt.root; dd if=/dev/acd0 of=/dev/null count=1 Szedjük le az egyes sávokat a &man.dd.1; használatával. A parancs kiadásakor meg kell adnunk egy blokkméretet is: &prompt.root; dd if=/dev/acd0t01 of=track1.cdr bs=2352 &prompt.root; dd if=/dev/acd0t02 of=track2.cdr bs=2352 ... A burncd használatával írjuk fel a lemezre az imént lementett állományokat. Meg kell adnunk, hogy ezek audio állományok, és hogy a burncd a munka befejeztével zárja le (fixate) a lemezt. &prompt.root; burncd -f /dev/acd0 audio track1.cdr track2.cdr ... fixate Adat CD-k másolása Az adatot tartalmazó CD-ket le tudjuk másolni egy olyan image-be, amely funkcionálisan megegyezik egy &man.mkisofs.8; által létrehozott image-dzsel és amivel le tudunk másolni bármilyen adat CD-t. Az itt megadott példa azt feltételezi, hogy a CD-meghajtónk neve acd0. Helyére a saját CD-meghajtónk nevét kell behelyettesíteni. &prompt.root; dd if=/dev/acd0 of=állomány.iso bs=2048 Most miután lementettük az image-et, írjuk fel CD-re a fentiek szerint. Adat CD-k használata Most, hogy már készítettünk egy szabványos adat CD-t, valószínûleg szeretnénk is valamilyen csatlakoztatni és elérni a rajta levõ adatokat. Alapértelmezés szerint a &man.mount.8; mindig azt feltételezi, hogy az állományrendszerek ufs típusúak. Ezért ha valami ilyesmivel próbálkozunk: &prompt.root; mount /dev/cd0 /mnt akkor egy Incorrect super block szövegû hibaüzenetet lesz a jutalmunk, és természetesen nem tudjuk csatlakoztatni a CD-t. Mivel a CD nem UFS állományrendszert tartalmaz, ezért az ilyen jellegû kísérleteink mind kudarcba fognak fulladni. Valahogy fel kell világosítanunk a &man.mount.8; parancsot arról, hogy itt most egy ISO9660 típusú állományrendszert akarunk csatlakoztatni, és akkor minden a helyére kerül. Ezt úgy tudjuk megtenni, ha a &man.mount.8; parancsnak megadjuk a paramétert. Például, ha a /dev/acd0 néven elérhetõ CD-meghajtóban levõ lemezt akarjuk a /mnt könyvtárba csatlakoztatni, akkor ezt kell begépelnünk: &prompt.root; mount -t cd9660 /dev/cd0 /mnt Vegyük észre, hogy az eszköz neve (ez ebben a példában most /dev/cd0) lehet más is attól függõen, hogy milyen csatolófelületet használ a CD-meghajtónk. Sõt, a valójában csak a &man.mount.cd9660.8; parancsot indítja el. Ennek tükrében tehát az elõbbi példát így rövidíthetjük le: &prompt.root; mount_cd9660 /dev/cd0 /mnt Ezen a módon bármilyen gyártmányú adat CD-t képesek vagyunk csatlakoztatni. Egyes ISO 9660 kiterjesztéseket használó lemezek azonban esetleg furcsán mûködhetnek. Például Joliet lemezek az összes állomány nevét kétbyte-os Unicode karakterben tárolják. A &os; rendszermagja ugyan nem beszéli a Unicode-ot, de a &os; CD9660 meghajtója képes menetközben átkonvertálni a Unicode karaktereket. Ha bizonyos nem angol karakterek kérdõjelekként jelennének meg, akkor a beállítás használatával még egy helyi kódlapot is meg kell adnunk. Ezzel kapcsolatban bõvebb tájékoztatásért forduljunk a &man.mount.cd9660.8; man oldalhoz. A beállítás segítségével csak akkor lesz képes a rendszermag elvégezni ezt az átalakítást, ha elõtte betöltjük a cd9660_iconv.ko modult. Ezt megtehetjük úgy, hogy ha felvesszük a következõ sort a loader.conf állományba: cd9660_iconv_load="YES" Indítsuk újra a számítógépünket, vagy közvetlenül töltsük be a modult a &man.kldload.8; használatával. Estenként elõfordulhat, hogy kapunk egy Device not configured hibaüzenetet a CD-k csatlakoztatásakor. Ez általában arra utal, hogy a CD-meghajtó nem érzékeli a berakott lemezt, vagy éppen a meghajtó nem látható a buszon. A CD-meghajtók esetében pár másodpercig eltarthat, amíg felismeri a berakott lemezt, ilyenkor mindig legyünk türelemmel. Néha a SCSI CD-meghajtó nem látható, mert nem volt elég ideje válaszolni busz újraindítása elõtt. Ha SCSI CD-meghajtónk van, akkor a következõ beállítást tegyük hozzá a rendszermagunk konfigurációjához és fordítsuk újra a rendszermagukat. options SCSI_DELAY=15000 Ezzel utasítjuk a SCSI buszunkat egy 15 másodperces várakozásra a rendszer indítása során, és így ezzel elég esélyt adunk arra, hogy a CD-meghajtó válaszolni tudjon a busz újraindítása elõtt. Nyers adat CD-k írása Írhatunk közvetlenül is állományokat a CD-re, ISO 9660 formátumú állományrendszer használata nélkül. Sokan így oldják meg a mentést. Ezt sokkal gyorsabban lebonyolítható egy szabványos CD esetében: &prompt.root; burncd -f /dev/acd1 -s 12 data archive.tar.gz fixate Az ezen a módon megírt CD-ket szintén nyers módon kell olvasnunk: &prompt.root; tar xzvf /dev/acd1 Az ilyen lemezeket nem tudjuk a normális CD-khez hasonlóan csatlakoztatni. Sõt, az ilyen CD-ket csak &os; alatt tudjuk olvasni. Ha csatlakoztathatóvá akarjuk tenni a lemezt, vagy más operációs rendszerek alól is szeretnénk olvasni, akkor erre a célra a fentebb bemutatott &man.mkisofs.8; parancsot kell használnunk. Marc Fonvieille Írta: CD-írók ATAPI/CAM meghajtó Az ATAPI/CAM meghajtó használata Ez a meghajtó lehetõvé teszi az ATAPI eszközök (CD-ROM, CD-RW, DVD meghajtók stb...) számára, hogy a SCSI alrendszeren keresztül legyenek elérhetõek, így esetünkben is használhatóvá válnak olyan alkalmazások, mint például sysutils/cdrdao vagy a &man.cdrecord.1;. A meghajtó használatához a következõ sort kell a /boot/loader.conf állományba illeszteni: atapicam_load="YES" Indítsuk újra a számítógépet. Amennyiben a rendszermagban az &man.atapicam.4; statikus támogatását szeretnénk használni, úgy a következõ sort kell a rendszermag konfigurációs állományába felvenni: device atapicam Továbbá a következõ sorokra lesz még szükségünk: device ata device scbus device cd device pass Ezeknek már eleve ott kell szerepelnie. Ezután fordítsuk újra és telepítsük a rendszermagot, majd indítsuk újra a számítógépet. A rendszer indulásakor az írónak ehhez hasonló módon kell megjelennie: acd0: CD-RW <MATSHITA CD-RW/DVD-ROM UJDA740> at ata1-master PIO4 cd0 at ata1 bus 0 target 0 lun 0 cd0: <MATSHITA CDRW/DVD UJDA740 1.00> Removable CD-ROM SCSI-0 device cd0: 16.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed A meghajtó most már elérhetõ a /dev/cd0 eszközön keresztül, és például ennyi begépelésével csatlakoztatni tudunk róla egy CD-t a /mnt könyvtárba: &prompt.root; mount -t cd9660 /dev/cd0 /mnt root felhasználóként a következõ paranccsal tudjuk lekérdezi az író SCSI címét: &prompt.root; camcontrol devlist <MATSHITA CDRW/DVD UJDA740 1.00> at scbus1 target 0 lun 0 (pass0,cd0) Eszerint a 1,0,0 lesz az eszköz SCSI címe, amelyet a &man.cdrecord.1; és más SCSI alkalmazások esetén adunk meg. Az ATAPI/CAM és SCSI rendszerek tekintetében olvassuk el az &man.atapicam.4; és &man.cam.4; man oldalakat. Marc Fonvieille Írta: Andy Polyakov Segítséget nyújtott benne: Lézeres tárolóeszközök (DVD-k) létrehozása és használata DVD írása Bevezetés A DVD a CD-hez képest a lézeres tárolóeszközök technológiájának újabb generációját képviseli. A DVD bármelyik CD-nél több adatot képes tárolni és napjaink ez a videók kiadásának szabványa. Öt fizikailag írható formátummal határozhatjuk meg az írható DVD fogalmát: DVD-R: Ez volt az elsõ elérhetõ írható DVD formátum. A DVD-R szabványát a DVD Fórum fektette le. Ez a formátum csak egyszer írható. DVD-RW: Ez a DVD-R szabvány újraírható változata. A DVD-RW körülbelül 1000 alkalommal írható újra. DVD-RAM: Ez is a DVD Fórum által támogatott újraírható formátum. A DVD-RAM cserélhetõ merevlemeznek látzsik. Azonban ez típusú adathordozó nem kompatibilis legtöbb DVD-ROM hajtóval és DVD-Video lejátszóval. Csupán csak néhány DVD-író ismeri a DVD-RAM formátumot. A DVD-RAM használatáról a ban találunk bõvebben információkat. DVD+RW: Ezt az újraírható formátumot a DVD+RW szövetség alkotta meg. A DVD+RW lemezek nagyjából 1000 alkalommal írhatóak újra. DVD+R: Ez a formátum a DVD+RW formátum egyszer írható változata. Az egyrétegû írható DVD-k összesen 4 700 000 000 byte-ot képesek rögzíteni, ami 4,38 GB vagy 4 485 MB (1 kilobyte itt 1024 byte). Meg kell különböztetnünk fizikai tárolóeszközt és az alkalmazást. Például a DVD-Video állományok olyan jellegû elrendezését írja elõ, ami bármelyik írható fizikai DVD eszközön megjelenhet: DVD-R, DVD+R, DVD-RW stb. Mielõtt kiválasztanánk az eszköz típusát, biztosnak kell lennünk benne, hogy az író és a DVD-Video lejátszó (ez lehet egy önálló lejátszó vagy egy számítógép DVD-ROM meghajtója) kompatibilis a szóbanforgó lemezzel. Beállítás A &man.growisofs.1; programot fogjuk a DVD rögzítésére használni. Ez a program a dvd+rw-tools segédprogramok (sysutils/dvd+rw-tools) gyûjteményének része. A dvd+rw-tools az összes DVD médium típusát ismeri. Ezek a segédprogramok a SCSI alrendszeren keresztül érik az eszközöket, ezért a használhatukhoz a rendszermagban szükségünk lesz az ATAPI/CAM támogatásra. Ha az írónk USB felületen csatlakozik, akkor mindez szükségtelen, és ehelyett a t kell elolvasnunk az USB eszközök beállításához. Engedélyeznünk kell az ATAPI eszközök DMA hozzáférését is, amit a /boot/loader.conf állományban a következõ sor hozzáadásával tudunk megtenni: hw.ata.atapi_dma="1" A dvd+rw-tools használatának megkezdése elõtt a DVD-írónkkal kapcsolatban érdemes átolvasnunk a dvd+rw-tools hardverkompatibilitási jegyzeteit (angolul). Ha grafikus felületet szeretnénk használni, akkor érdemes egy pillanatást vetnünk a K3bre (sysutils/k3b), amely egy felhasználóbarát felületet ad a &man.growisofs.1; és sok más íróprogram felé. Adat DVD-k írása A &man.growisofs.1; a mkisofs parancs elõlapja, tehát az állományrendszer létrehozásához a &man.mkisofs.8; programot fogja meghívni és ezt írja fel a DVD-re. Ez azt jelenti, hogy az írási folyamat megkezdése elõtt nem kell semmilyen image-et létrehoznunk. A /az/elérési/út könyvtárból a következõ paranccsal tudjuk kiírni az adatokat DVD+R vagy DVD-R lemezre: &prompt.root; growisofs -dvd-compat -Z /dev/cd0 -J -R /az/elérési/út A beállítások a &man.mkisofs.8; programhoz kerülnek át az állományrendszer létrehozásakor (itt most egy ISO 9660 állományrendszert hozunk létre, Joliet és Rock Ridge kiterjesztésekkel), használatának részleteit lásd &man.mkisofs.8;. A beállítást a kezdõmenetek létrehozásakor használjuk: több menetben akarjuk írni a lemezt vagy sem. A DVD eszközt, amely itt most a /dev/cd0, a saját konfigurációnknak megfelelõen kell megadni. A paraméterrel lezárjuk a lemezt, így ezután további írás már nem lehetséges. Ezért cserébe jobb kompatibilitást kapunk a DVD-ROM meghajtókkal. Elõre legyártott image-dzsel is dolgozhatunk, tehát például, ha az image.iso állományt akarjuk kiírni, akkor ezt kell lefuttatnunk: &prompt.root; growisofs -dvd-compat -Z /dev/cd0=image.iso Az írási sebességet magától beállítja a lemez és meghajtó képességeinek megfelelõen. Az írási sebesség felülbírálásához használjuk a paramétert. A paraméterek lehetõségeirõl a &man.growisofs.1; man oldaláról tudhatunk meg többet. DVD DVD-Video DVD-Video írása A DVD-Video az állományok speciális szervezésére utal, amely az ISO 9660 és az mikró UDF (M-UDF) specifikációkon alapszik. A DVD-Video emellett egy adott adatszerkezeti hierarchiát is takar, ezért kell egy külön programmal, például a multimedia/dvdauthor segítségével összeállítani egy DVD-t. Ha már a birtokunkban van egy DVD-Video állományrendszer képe, akkor az eddigiek szerint egyszerûen csak írjuk fel egy lemezre, ahogy azt az elõzõ szakaszban is láthattuk. Ha összeállítottuk a DVD anyagát és például a /a/videó/elérési/útja könyvtárba raktuk, akkor a következõ paranccsal írathatjuk ki a DVD-Video formátumú lemezt: &prompt.root; growisofs -Z /dev/cd0 -dvd-video /a/videó/elérési/útja A paramétert kell átadni a &man.mkisofs.8; programnak, amelynek hatására létrehoz egy DVD-Video formátumú állományrendszert. Emellett a beállítás maga után vonja a &man.growisofs.1; beállítását is. DVD DVD+RW A DVD+RW használata Eltérõen a CD-RW-tõl, egy érintetlen DVD+RW-t az elsõ használat elõtt meg kell formázni. A &man.growisofs.1; program errõl az elsõ adandó alkalommal gondoskodik, és ez az ajánlott. Azonban a DVD+RW formázására használhatjuk a dvd+rw-format parancsot is: &prompt.root; dvd+rw-format /dev/cd0 Ezt a mûveletet csak egyszer kell elvégezni, hiszen ne feledjük, hogy csak a szûz DVD+RW lemezeket kell megformázni. Ezután a DVD+RW-t a korábbi szakaszoknak megfelelõen tudjuk írni. Ha a DVD+RW-re új adatot akarunk írni (egy teljesen új állományrendszert, nem pedig adatokat hozzáfûzni), akkor nem kell üressé tenni a lemezt, egyszerûen csak elegendõ felülírni az elõzõeket (egy új kezdõmenet létrehozásával) valahogy így: &prompt.root; growisofs -Z /dev/cd0 -J -R /az/új/adat/helye A DVD+RW formátum felajánlja annak lehetõségét is, hogy könnyedén hozzá lehessen fûzni adatokat az elõzõ íráshoz. A mûvelet során az új menetet összefûzi a meglévõvel, tehát ez nem egy többmenetes írás, hanem a &man.growisofs.1; megnöveli a lemezen található ISO 9660 állományrendszert. Például, ha egy korábban megírt DVD+RW lemezen levõ adatokhoz akarunk hozzáírni, akkor a következõ parancsot kell kiadnunk: &prompt.root; growisofs -M /dev/cd0 -J -R /az/új/adat/helye A &man.mkisofs.8; beállításainál a kezõmenetnél megadottakat érdemes ismét megadni. Ha kompatibilisek akarunk maradni a többi DVD-meghajtóval, akkor adjuk meg paramétert. Ez a DVD+RW esetében annyit jelent, hogy nem tudunk további adatokat hozzáfûzni. Ha valamilyen okból mégis üressé szeretnénk tenni a lemez, akkor ír járhatunk el: &prompt.root; growisofs -Z /dev/cd0=/dev/zero DVD DVD-RW A DVD-RW használata A DVD-RW két lemezformátumot fogad el: a inkrementális soros hozzáférést és a korlátozott felülírást. Alapértelmezés szerint a DVD-RW lemezek soros elérésûek. A még fel nem használt DVD-RW lemezek közvetlenül írhatóak külön formázás nélkül, habár a korábban már soros formátumban használt DVD-RW lemezeket egy új kezdõmenet létrehozása elõtt üressé kell tenni. Soros módban így kell letörölni egy DVD-RW lemezt: &prompt.root; dvd+rw-format -blank=full /dev/cd0 A teljes törlés () egy 1x média esetén körülbelül egy órát vesz igénybe. A beállítással egy gyorsított törlés zajlik le, amennyiben a DVD-RW lemezt Disk-At-Once (DAO) módban írjuk. A DVD-RW lemezeket az alábbi paranccsal tudjuk DAO módban írni: &prompt.root; growisofs -use-the-force-luke=dao -Z /dev/cd0=image.iso A beállítást nem kötelezõ megadni, mivel a &man.growisofs.1; igyekszik a lehetõ leggyorsabban törölni a lemezt és megkezdeni a DAO módú írást. A DVD-RW esetében valójában a korlátozott felülírást lenne érdemes használnunk, mivel ez a formátum sokkal rugalmasabb az alapértelmezés szerint felkínált inkrementális soros elérésnél. A soros DVD-RW lemezekre ugyanúgy tudunk adatokat rögzíteni, mint az összes többi formátum esetében: &prompt.root; growisofs -Z /dev/cd0 -J -R /az/adat/helye Ha az elõzõ íráshoz akarunk még hozzáfûzni adatokat, akkor ehhez a &man.growisofs.1; beállítását kell használnunk. Azonban ha a DVD-RW lemezhet inkrementális soros módban adunk hozzá adatot, akkor ezzel egy új menetet hozunk létre a lemezen és így egy többmenetes lemezt kapunk. A korlátozott felülírású DVD-RW formátum használata esetén nem kell mindegyik kezdõmenet elõtt törölni a lemezt, egyszerûen csak felül kell írni a beállítással, hasonlóan a DVD+RW esetéhez. A DVD+RW beállításához hasonlóan lehetõségünk van a lemezen található ISO 9660 formátumú állományrendszer növelésére. Ennek az eredménye egy egymenetes DVD. A következõ paranccsal tudjuk a DVD-RW lemezt korlátozott felülírású módba tenni: &prompt.root; dvd+rw-format /dev/cd0 Így tudunk visszaváltani a soros formátum használatára: &prompt.root; dvd+rw-format -blank=full /dev/cd0 Több menet használata Nagyon kevés DVD-ROM meghajtó ismeri a többmenetes DVD-ket, és legtöbbször is csak általában az elsõ menetet olvassák. A DVD+R, DVD-R és DVD-RW formátumok soros formátumban képesek több mentetet is befogadni, viszont a DVD+RW és DVD-RW korlátozott felülírású formátuma esetén nem létezik több menet. Az alábbi parancs egy újabb menetet ad hozzá egy megkezdett (le nem zárt) DVD+R, DVD-R vagy DVD-RW soros formátumú lemezhez: &prompt.root; growisofs -M /dev/cd0 -J -R /az/új/adat/helye Ha ezt a parancsot egy korlátozott felülírású DVD+RW vagy DVD-RW lemez esetén adjuk ki, akkor az új adatokat úgy fûzi hozzá, hogy egy új menetet összefésüli a meglévõvel. Ezzel egy egymenetes lemez keletkezik. Ilyenkor így bõvítik a megkezdett lemezeket. A menetek kezdése és befejezése általában felhasznál valamennyi helyet a lemezen. Ezért úgy tudjuk optimalizálni a lemez helykihasználtságát, hogy kevés menetben sok adatot viszünk fel rá. A DVD+R esetén 154, a DVD-R-nél körülbelül 2000, és a dupla rétegû DVD+R lemezeknél 127 menetet tudunk létrehozni. További olvasnivalók A DVD lemezrõl részletesebb információkat a dvd+rw-mediainfo /dev/cd0 parancs kiadásával tudunk lekérdezni. A dvd+rw-tools használatáról a &man.growisofs.1; man oldalon találunk információt, valamint a dvd+rw-tools honlapján (angolul) és a cdwrite levelezési lista archívumaiban (angolul). Futassuk dvd+rw-mediainfo parancsot minden olyan esetben, amikor gondunk akad valamilyen lemez írásával. A kimenete nélkül szinte lehetetlen segítenünk bárkinek is. A DVD-RAM használata DVD DVD-RAM Beállítás A DVD-RAM írók SCSI vagy ATAPI csatolófelülettel rendelkeznek. Az ATAPI eszközök esetén engedélyezni kell a DMA elérését, amit a /boot/loader.conf állományban az alábbi sor hozzáadásával tudunk megtenni: hw.ata.atapi_dma="1" A lemez elõkészítése Ahogy arra már korábban utaltunk a fejezet bevezetésében, a DVD-RAM úgy látható, mint egy cserélhetõ merevlemez. A hagyományos merevlemezekhez hasonlóan a DVD-RAM-ot is elõ kell készíteni az elsõ használatához. Ebben a példában a lemez teljes területét egy szabványos UFS2 állományrendszerrel töltjük fel: &prompt.root; dd if=/dev/zero of=/dev/acd0 bs=2k count=1 &prompt.root; bsdlabel -Bw acd0 &prompt.root; newfs /dev/acd0 A DVD eszköz nevét, vagyis az acd0 eszközt a saját rendszerünknek megfelelõen kell módosítani. A lemez használata Miután az elõbbi mûveletet elvégeztük a DVD-RAM lemezen, már tudjuk is normális merevlemezként csatlakoztatni: &prompt.root; mount /dev/acd0 /mnt Ezt követõen a DVD-RAM egyaránt olvasható és írható. Julio Merino Eredetileg készítette: Martin Karlsson Átdolgozta: Hajlékonylemezek létrehozása és használata Néha hasznos lehet, ha az adatokat floppy lemezeken tároljuk, például olyankor, amikor más cserélhetõ tárolóeszköz már nem jöhet számításba, vagy amikor kis mennyiségû adatot kell átvinnünk az egyik számítógéprõl a másikra. Ebben a szakaszban bemutatjuk hogyan kell &os; alatt floppy lemezeket használni. Elsõsorban a 3,5 colos DOS lemezek formázásával és használatával foglalkozik, de ezek fogalmak a többi hajlékonylemezes formátum esetében is hasonlóak. A hajlékonylemezek formázása Az eszköz A floppy lemezek a többi eszközhöz hasonlóan a /dev könyvtárban érhetõek el. A nyers floppy lemezek eléréséhez egyszerûen csak használjuk a /dev/fdN hivatkozást. A formázás Használat elõtt a floppy lemezeket alacsony szinten meg kell formázni. Ezt általában maga a gyártó végzi el, de a formázás gyakran hasznos lehet a lemez sértetlenségének ellenõrzésére. A legtöbb floppy lemez hivatalos kapacitása 1440 KB, de használhatjuk nagyobb (és kisebb) méretekben is. A floppy lemezek alacsony szintû formázására az &man.fdformat.1; parancsot használhatjuk. Ez a segédprogram paraméterként az eszköz nevét várja. Figyeljünk a menetközben megjelenõ hibaüzenetekre, mivel ezek segítik eldönteni, hogy a lemez használható vagy sem. A hajlékonylemezek formázása A /dev/fdN eszközök segítségével tudunk megformázni egy floppy lemezt. Tegyünk be egy 3,5 colos floppy lemezt a meghajtóba, majd adjuk ki a következõ parancsot: &prompt.root; /usr/sbin/fdformat -f 1440 /dev/fd0 A lemez címkézése Miután alacsony szinten formáztuk a lemezt, tennünk kell rá egy lemezcímkét is. Ez a lemezcímke késõbb meg fog semmisülni, de a rendszernek szüksége van rá, hogy pontosan meg tudja állapítani a lemez méretét és geometriáját. Az új lemezcímke lefedi az egész lemezt, és tartalmazni fogja az összes információt a floppy geometriájáról. A lemezcímkék geometriaértékeit az /etc/disktab állományban találjuk meg felsorolva. Most már futtathatjuk is a &man.bsdlabel.8; parancsot: &prompt.root; /sbin/bsdlabel -B -w /dev/fd0 fd1440 Az állományrendszer A hajlékonylemez most már készen áll a magas szintû formázásra. Ennek során egy új állományrendszert teszünk rá, amelyet a &os; képes írni és olvasni. Miután létrejött ez az új állományrendszer, a lemezcímke megsemmisül, így tehát ha újra meg akarjuk formázni a lemezt, akkor újra létre kell majd hoznunk a lemezcímkét. A floppy állományrendszere lehet UFS vagy FAT. A FAT általánosságban véve jobb választás a floppy lemezek számára. Az alábbi módon tudunk új állományrendszert tenni a floppyra: &prompt.root; /sbin/newfs_msdos /dev/fd0 A lemez most már készen áll a használatra. A hajlékonylemezek használata A floppy lemezt használatához a &man.mount.msdosfs.8; paranccsal kell csatlakoztatnunk. Ugyanerre a célra használhatjuk a Portgyûjteménybõl elérhetõ emulators/mtools portot is. Szalagok létrehozása és használata szalagos adathordozó A legfontosabb szalagos adathordozók a 4 mm-es, 8 mm-es, QIC, a minikazettás és a DLT. 4 mm-es (Digitális adattároló, avagy DDS: Digital Data Storage) szalagos adathordozó (4 mm-es) DDS-szalagok szalagos adathordozó QIC-szalagok A 4 mm-es szalagok a QIC-szalagokat váltják fel a munkaállomások biztonsági mentésének eszközeként. Ez a tendencia csak tovább növekedett, ahogy a Conner felvásárolta az Archive-ot, a QIC típusú meghajtók legnagyobb gyártóját, majd leállított a QIC-meghajtók gyártását. A 4 mm-es meghajtók mérete kicsi és csendben is dolgoznak, de a megbízhatóság terén nem tudhatják maguknak mindazt a sikert, amit a 8 mm-es társaiknál könyvelhettünk el. A kazetták is sokkal olcsóbbak és kisebbek (3 x 2 x 0,5 col, ami 76 x 51 x 12 mm) a 8 mm-es kiadásénál. A 4 mm-es feje, hasonlóan a 8 mm-eséhez, valamilyen okból szintén viszonylag rövid ideig bírja, és mind a kettõ spirális pásztázást használ. Ezeknél a meghajtóknál az adatátvitel nagyjából 150 KB/mp-nél kezdõdik és 500 KB/mp-nél végzõdik. Az adattárolási képességük 1,3 GB-tól indul és 2,0 GB-ig tart. A hardveres tömörítés, ami a legtöbb ilyen típusú meghajtónál elérhetõ, közel megduplázza a kapacitást. A többmeghajtós szalagos könyvtár egységek egyetlen szekrényben 6 meghajtót képes befogadni, a szalagok automatikus cserélgetésével. Az ilyen könyvtárak kapacitása a 240 GB-ot is elérheti. A DDS-3 szabvány most már akár 12 GB (vagy tömörítve 24 GB) kapacitást is elérhetõvé tesz. A 4 mm-es meghajtók, hasonlóan a 8 mm-es meghajtókhoz, spirális pásztázást alkalmaznak. A spirális pásztázás összes elõnye és hátránya ezért egyaránt él a 4 mm-es és 8 mm-es meghajtók esetén. A szalagok 2 000 menet vagy 100 teljes mentes után kopnak el. 8 mm-es (Exabyte) szalagos adathordozó (8 mm-es) Exabyte szalagok A 8 mm-es szalagok a legelterjedtebb szalagos SCSI-meghajtók. A szalagok használatára ez a legjobb választás. Szinte mindegyik rendszerben egy 2 GB-os 8 mm-es Exabyte szalagos meghajtót használnak. A 8 mm-es meghajtók megbízhatóak, kényelmesek és csendesek. A kazetták olcsók és kicsik (4,8 x 3,3 x 0,6 col, azaz 122 x 84 x 15 mm). A 8 mm-es szalagok feje viszonylag csak rövid ideig bírja a szalag nagy mértékû oda-vissza mozgása miatt. Az adatátvitel sebessége 250 KB/mp-tõl 500 KB/mp-ig terjed, valamint a 300 MB-tól egészen 7 GB-os méretig találkozhatunk velük. A meghajtókban elérhetõ hardveres tömörítés képes közel megduplázni a kapacitást. Ezek a meghajtók önálló egységként is beszerezhetõek vagy egy 6 egységbõl álló és 120 szalagos szalagos könyvtár részeként. Ezek az egységek önállóan váltják a szalagokat. Az ilyen könyvtárak kapacitása eléri a közel 840 GB-ot. Az Exabyte Mammoth modellje szalagonként 12 GB (tömörítéssel pedig 24 GB) adatot képes tárolni, viszont a hagyományos szalagos meghajtóknál nagyjából kétszer többe kerül. Az adatok spirális pásztázással kerülnek a szalagra, és a fejek adott (nagyjából 6 fokos) szögben állnak a szalag felett. A szalag a fejeket tartó orsó köré tekeredik, körülbelül 270 fokban. Ennek eredményképpen nagyobb adatsûrûség és szorosan zárt sávok jönnek létre, ahogy ebben a szögben a fej eljut a szalag egyik élérõl a másikra. QIC szalagos adathordozó QIC-150 A QIC-150 meghajtók és szalagok talán a legelterjedtebb szalagos egységek és adathordozók. A QIC szalagos meghajtók a legolcsóbb komolynak tekinthetõ biztonsági mentésre alkalmas meghajtók. Az olcsóság azonban megköveteli a maga árát. A QIC-szalagok a 4 és 8 mm-es szalagokkal szemben akár ötször is drágábbak lehetnek gigabyte-onként. De ha megelégszünk csupán féltucat szalaggal is, akkor a QIC jó vásárnak tûnhet. A QIC a leginkább elterjedtebb szalagos meghajtó. Minden rendszerben biztonsan találunk valamilyen minõségben QIC-meghajtót. A QIC fizikailag hasonló (és gyakran azonos) felépítésû szalagokat gyárt rengeteg különbözõ adatsûrûséggel. Az ilyenkor keletkezõ súrlódások miatt a QIC-meghajtók egyáltalán nem nevezhetõek csendesnek. Az ilyen típusú meghajtók az adatok rögzítése elõtt külön hangjelenség kíséretében keresik meg a megfelelõ pozíciót és tisztán hallható, ahogy olvasnak, írnak és keresnek. A QIC-szalagok mérete 6 x 4 x 0,7 col (avagy 152 x 102 x 17 mm). Az adatátviteli sebesség nagyjából 150 KB/mp-tõl 500 KB/mp-ig terjedhet. A kapacitás szalagonként 40 MB és 15 GB között változhat. A legtöbb újabb QIC-meghajtó támogatja a hardveres tömörítést. QIC-meghajtókat azonban egyre kevésbé találhatunk, helyüket szépen lassan mindenhol átveszik a DAT-meghajtók. A szalagokra sávokban rögzítik az adatokat. Ezek a sávok szalag felületének hosszanti tengelyén futnak az egyik végétõl a másikig. A sávok száma valamint a sávok vastagsága a szalagok kapacitásától függõen változnak. Ha nem is összes legújabb, de a legtöbb meghajtó legalább olvasás szintjén kompatibilis a régebbi típusokkal (de gyakran írásban is). A QIC híresen megbízható az adatbiztonság tekintetében (a mechanikája sokkal egyszerûbb és strapabíróbb a spirális pásztázással mûködõ meghajtókénál). A szalagokat 5000 mentés után érdemes lecserélni. DLT szalagos adathordozó DLT A DLT rendelkezik a legnagyobb adatátviteli sebességgel az itt összefoglalt mezõnyben. A 1/2 colos (12,5 mm-es) szalag egy egyorsós tokban foglal helyet (mérete 4 x 4 x 1 col, azaz 100 x 100 x 25 mm). A tok egyik oldalán végig egy csúszó kapu található. A meghajtó ezt a kaput nyitja ki és ezen keresztül húzza be a szalagot. A szalag elején található egy ovális lyuk, amibe a meghajtó bele tud akaszkodni. A feszítõ orsó a szalagos meghajtóban foglal helyet. Az összes többi szalag esetén (kivéve egyedül a 9 sávos szalagokat) mind a segéd- és feszítõ orsók magában a kazettában találhatóak. Az adatátviteli sebessége megközelítõleg 1,5 MB/mp, tehát háromszor nagyobb bármelyik 4 mm-es, 8 mm-es vagy QIC-szalagos egységénél. Az adattároló képessége kazettánként 10 GB-tól 20 GB-ig terjedhet. A meghajtók egyaránt elérhetõek többkazettás, cserélgetõs és többkazettás, többmeghajtós könyvtárakban is, melyek 5 kazettától egészen 900 kazettáig, illetve 1 meghajtótól 20 meghajtóig képesek befogadni, így teljes tárterületük 50 GB-tól 9 TB-ig terjed. A DLT Type V formátum tömörítéssel közel 70 GB-os kapacitást képes elérni. A szalagra az adatok a haladási iránnyal párhuzamosan kerülnek fel (akárcsak a QIC-szalagok esetében). Egyszerre két sávot rögzít. A író/olvasó fejek élettartama viszonylag nagy. Ahogy a szalag megáll, a fej és a szalag között nincs szükség további relatív mozgásra. AIT szalagos adathordozó AIT Az AIT a Sony új formátuma, ami egészen 50 GB mennyiségû adatot képes tárolni (tömörítéssel) egyetlen szalagon. A szalagokat memóriachipekkel látják el, melyek a szalag tartalmát indexelik. Az indexek felhasználásával aztán a szalagos meghajtó villámgyorsan képes meghatározni a szalagon található állományok helyét, szemben az ilyenkor megszokott többperces mûvelettel. A SAMS:Alexandria és a hozzá hasonló szoftverek negyven vagy több AIT-szalagos könyvtárral is képesek egyszerre dolgozni, és közvetlenül a szalagok memóriájával veszik fel a kapcsolatot a tartalmuk megjelenítéséhez, a mentett állományok rendszerezéséhez, a helyes szalag megkereséséhez, betöltéséhez és visszatöltéséhez. Az ilyen könyvtárak a 20 000 dolláros (kb. 3,5 millió forintos) árkategóriába tartoznak, ami miatt csak egy kicsivel csúsznak ki a hobbi kategóriából. Az új szalagok elsõ használata Amikor az elsõ alkalommal akarunk beolvasni vagy írni egy új, teljesen üres szalagot, hibára fogunk futni. Egy ehhez hasonló konzolüzenet fog megjelenni: sa0(ncr1:4:0): NOT READY asc:4,1 sa0(ncr1:4:0): Logical unit is in process of becoming ready A szalag nem tartalmaz azonosító blokkot (Identifier Block) a nulladik blokkban. A QIC-525 szabvány átvétele óta mindegyik QIC szalagos meghajtó létrehozza ezt az azonosító blokkot. Tehát két megoldás létezik: Az mt fsf 1 paranccsal felírunk egy ilyen azonosító blokkot a szalagra. A meghajtó elõlapján található gomb segítségével dobassuk ki a szalagot. Rakjuk vissza a szalagot és hajtsunk végre rajta egy dump parancsot. A dump parancs erre egy DUMP: End of tape detected (szalag vége) hibaüzenetet ad, majd a következõ jelenik meg a konzolon: HARDWARE FAILURE info:280 asc:80,96. Tekertessük vissza a szalagot az mt rewind paranccsal. A szalag következõ mûvelete most már sikeres lesz. Biztonsági mentés hajlékonylemezekre Hajlékonylemezre is lehet biztonsági mentést készíteni? biztonsági floppyk floppy lemezek A floppy lemezek nem igazán felelnek meg biztonsági mentés készítésére, mivel: Nem megbízható adathordozók, különösen hosszabb idõre. Esetükben a mentés és visszaállítás nagyon lassú. Kapacitásuk erõsen korlátozott (annak már régen elmúlt az ideje, amikor egész merevlemezeket tudtunk lementeni egy tucat floppyra). Habár ha máshogy nem tudunk biztonsági mentést készíteni, akkor a floppy lemezekkel még mindig jobban járunk, mint nélkülük. Ha már mindenképpen floppy lemezeket kell használnunk, akkor igyekezzünk minél jobb minõségûeket beszerezni. Tehát az olyan floppyk, amik már évek óta kavarognak az irodában, erre a célra nem éppen bizonyulnak a legjobb választásnak. Ideális esetben egy megbízható gyártótól származó új floppykat használunk. Tehát akkor hogyan mentsük az adatokat hajlékonylemezre? Legegyszerûbban a &man.tar.1; (többkötetes) opciójával tudunk floppy lemezre menteni, aminek használatával több floppyra kiterjedõ mentéseket is készíthetünk. Az aktuális könyvtár és a benne levõ alkönyvtárak tartalmát (root) felhasználóként a következõ paranccsal tudjuk lementeni: &prompt.root; tar Mcvf /dev/fd0 * Amikor az elsõ floppy megtelik, a &man.tar.1; kérni fogja a következõ kötetet (volume) (mivel a &man.tar.1; adathordozótól független módon hivatkozik a kötetekre, tehát ebben a környezetben a kötet egy floppy lemezt jelent): Prepare volume #2 for /dev/fd0 and hit return: Az üzenet fordítása: Készítse elõ a 2. kötetet a /dev/fd0 eszközön és nyomja le a return billentyût A folyamat egészen addig ismétlõdik (a kötetek számának növekedésével), amíg az összes állomány lementésre nem kerül. Lehet tömöríteni a mentéseket? tar gzip tömörítés Sajnos a &man.tar.1; többkötetes mentések esetén nem engedi a beállítás használatát. Természetesen ettõl függetlenül a &man.gzip.1; segítségével még be tudjuk tömöríteni az összes állományt, a &man.tar.1; paranccsal floppyra menteni ezeket, majd a &man.gunzip.1; paranccsal kitömöríteni. Hogyan állítsuk vissza a biztonsági mentéseket? Az egész mentés visszaállításához adjuk ki a következõ parancsot: &prompt.root; tar Mxvf /dev/fd0 Két módon tudunk csak bizonyos állományokat visszaállítani. Elõször is, tegyük be a mentés elsõ lemezét és adjuk ki a következõ parancsot: &prompt.root; tar Mxvf /dev/fd0 állomány A &man.tar.1; segédprogram ezután sorban kérni fogja a többi lemezt egészen addig, amíg meg nem találja a keresett állományt. Vagy ha pontosan tudjuk, hogy melyik lemezen található a keresett állomány, akkor az iménti parancs használatát azzal a lemezzel kezdjük. Vigyázzunk, mert ha a lemezen található elsõ állomány az elõzõ lemezen kezdõdik, akkor a &man.tar.1; figyelmeztetni fog minket, hogy nem állítja vissza még akkor sem, ha erre nem is kértük! Lowell Gilbert Eredetileg készítette: Mentési stratégiák Egy biztonsági mentés kidolgozása során az elsõ követelmény gondoskodnunk az alábbi problémákról: Lemezhiba Az állományok véletlen törlése Az állományok véletlenszerû károsodása Számítógépek teljes megsemmisülése (például tûz által), belértve a közelében tárolt összes biztonsági mentést Tökéletesen megoldható, hogy egyes rendszerek a fentebb felsorolt problémák mindegyikét teljesen eltérõ technikával oldják meg. A nagyon személyes rendszerektõl és a nagyon értéktelen adatoktól eltekintve szinte egyértelmûen kizárt, hogy egyetlen technika képes lefedni az összes problémát. Kelléktárunk néhány alapvetõ eszköze: Az egész rendszer mentése, amit egy megbízható helyre elzárt, tartós adattárolóra készítünk. Ez tulajdonképpen védelmet biztosít a fentebb megemlített összes probléma esetében, de lassú és kényelmetlen róla visszaállítani az adatokat. A közelben és/vagy neten is tarthatunk errõl másolatokat, de még így is kényelmetlen az állományok visszaállítása, különösen az egyszerû felhasználók számára. Pillanatképek készítése az állományrendszerrõl. Ez valójában csak olyan esetekben lehet a segítségünkre, amikor véletlenül töröltünk állományokat, ám ilyenkor határozottan jól jön, mivel igen gyorsan és könnyen lehet vele dolgozni. Az egész állományrendszer és/vagy az összes lemez másolata (például az &man.rsync.1; idõszakos alkalmazása a komplett gépre). Az általában az egyedi igényekkel bíró hálózatok esetében eshet a kezünkre. A lemezhiba ellen védelemben ez a megoldás általában a RAID alatt áll. A véletlenül törölt állományok visszaállításának tekintetében az UFS pillanatképeivel mérhetõ össze, de ez leginkább a saját igényeinktõl függ. RAID alkalmazása. A lemezek meghibásodása esetén segíti minimalizálni vagy elkerülni a kiesést, ugyan gyakori lemezhibák árán (mivel ilyenkor több lemezt használunk) de kisebb sürgõsséggel. Az állományok ujjlenyomatának ellenõrzése. Az &man.mtree.8; segédprogram nagyon hasznos tud lenni ebben az esetben. Habár ez nem egy mentési technika, mégis segít megállapítani, hogy mikor kell nyugdíjba küldenünk a biztonsági mentéseinket. Ez különösen az aktív nem használt mentésekre vonatkozik, ezeket bizonyos idõ elteltével mindig érdemes ellenõrizni. Nagyon könnyû lenne további technikákat is felsorolni, melyek legtöbbje az iméntiek valamilyen kombinációja lenne. A speciális igények általában speciális technikákat eredményeznek (például egy éles adatbázis biztonsági mentése általában az adott adatbáziskezelõ rendszer közremûködését is elvárja). Mindig fontos tudni, hogy milyen veszélyek ellen védekezünk és hogyan kezeljük le ezeket. Alapvetõ tudnivalók a biztonsági mentésrõl A &man.dump.8;, &man.tar.1; és &man.cpio.1; a három legfontosabb biztonsági mentésekkel kapcsolatos program. Mentés és helyreállítás biztonsági mentést végzõ szoftverek mentés / helyreállítás dump restore A &unix; típusú rendszerekben a biztonsági mentést hagyományosan a dump és restore programok végzik. A meghajtókat lemezblokkok összeségeként kezelik, az állományrendszerek által létrehozott állományok, linkek és könyvtárak szintje alatt. A dump az adott eszközön egy egész állományrendszert képes lementeni. Nem képes csak az állományrendszer vagy egy több állományrendszerre kiterjedõ könyvtárszerkezet egy részét lementeni. A dump nem állományokat és könyvtárakat ír a szalagra, hanem nyers adatblokkokat, amelyek állományokat és könyvtárakat formáznak. Ha a dump parancsot a gyökér könyvtárban adjuk ki, akkor nem fogja lementeni a /home vagy /usr vagy bármilyen más könyvtárat, mivel ezek jellemzõ módon más állományrendszerek csatlakozási pontja vagy más állományrendszerekre mutató szimbolikus linkek. A dump parancsnak vannak olyan rigolyái, amelyek még az AT&T UNIX 6. verziójából (1975 környékérõl) maradtak vissza. Az alapértelmezett paraméterezése 9 sávos szalagokat feltételezi (6250 bpi), nem pedig a napjainkban elterjedt nagy írássûrûsségû (egészen 62 182 ftpi-s) adathordozókat. Ezek az alapértelmezések természetesen paranccsorból felülbírálhatóak, és így a manapság alkalmazott szalagos meghajtók teljes kapacitása is kihasználható vele. .rhosts Emellett az rdump és rrestore programok segítségével hálózaton keresztül is le tudjuk menteni az adatainkat egy másik számítógépre csatlakoztatott szalagos egységre. Mind a két program az &man.rcmd.3; és a &man.ruserok.3; parancsokat használja a távoli szalagos meghajtó eléréséhez. Az rdump és rrestore paramétereinek a távoli számítógép használatához kell illeszkedniük. Amikor egy &os; rendszerû számítógépet az rdump paranccsal egy Sun rendszerû, komodo nevû számítógépre mentünk, amelyhez egy Exabyte szalagos meghajtó csatlakozik, akkor ezt a írjuk be: &prompt.root; /sbin/rdump 0dsbfu 54000 13000 126 komodo:/dev/nsa8 /dev/da0a 2>&1 Figyelem: az .rhosts állományon keresztül hitelesítésnek megvannak a maga biztonsági kockázatai. Ne felejtsük el felmérni ezt a saját környezetünkben sem. A dump és restore parancsokat az ssh használatával még biztonságosabbá tehetjük. A <command>dump</command> használata az <application>ssh</application> alkalmazással &prompt.root; /sbin/dump -0uan -f - /usr | gzip -2 | ssh -c blowfish \ célfelhasználó@cél.gép.hu dd of=/nagyállományok/dump-usr-l0.gz Vagy az RSH környezeti változó megfelelõ beállításával használhatjuk a dump beépített módszerét: A <command>dump</command> használata az <application>ssh</application> alkalmazással, az <envar>RSH</envar> környezeti változó beállításával &prompt.root; RSH=/usr/bin/ssh /sbin/dump -0uan -f célfelhasználó@cél.gép.hu:/dev/sa0 /usr <command>tar</command> biztonsági mentést végzõ szoftverek tar A &man.tar.1; is az AT&T UNIX 6. verziójáig nyúlik vissza (tehát nagyjából 1975-ig). A tar az állományrendszerrel szoros együttmûködésben dolgozik, állományokat és könyvtárakat ír a szalagra. A tar ugyan nem ismeri a &man.cpio.1; által felkínált összes lehetõséget, de nincs is szüksége olyan szokatlan paranccsoros összekapcsolásokra, mint a cpio parancsnak. tar A &os; 5.3 vagy késõbbi változataiban a GNU tar és az alapértelmezés szerinti bsdtar egyaránt elérhetõ. A GNU változat a gtar paranccsal hívható meg. Az rdump parancshoz hasonló felírásban képes kezelni a távoli eszközöket. Tehát így tudjuk használni a tar parancsot a komodo nevû Sun számítógép Exabíte szalagos meghajtójának elérésére: &prompt.root; /usr/bin/gtar cf komodo:/dev/nsa8 . 2>&1 Ugyanez eltérhetõ a bsdtar használatával is, amikor az rsh programmal összekapcsolva küldünk át a távoli szalagos egységre. &prompt.root; tar cf - . | rsh hálózati-név dd of=szalagos-eszköz obs=20b Ha a hálózaton keresztül mentés során fontos számunkra a biztonság, akkor az rsh parancs helyett az ssh parancsot használjuk. <command>cpio</command> biztonsági mentést végzõ szoftverek cpio A &man.cpio.1; eredetileg a &unix; szalagos programjai és szalagos egységei között közvetített. A cpio parancs (többek közt) képes a byte-ok sorrendjének felcserélésére, több különbözõ archívum formátuma szerint írni és adatokat közvetíteni más programok felé. Ez utóbbi lehetõsége miatt a cpio kíválóan alkalmas a telepítõeszközök számára. A cpio nem képes bejárni a könyvtárszerkezetet, és az állományok listáját a szabványos bemeneten keresztül kell megadni neki. cpio A cpio nem támogatja a biztonsági mentés átküldését a hálózaton. Programok összekapcsolásával és az rsh használatával tudunk adatokat küldeni távoli szalagos meghajtókra. &prompt.root; for f in könyvtár_lista; do find $f >> mentési.lista done &prompt.root; cpio -v -o --format=newc < backup.list | ssh felhasználó@gép "cat > mentõeszköz" Ahol a könyvtár_lista a menteni kívánt könyvtárak listája, a felhasználó@gép a mentést végzõ gép felhasználójának és hálózati nevének együttese, valamint a mentõeszköz, ahova a mentés kerül (például /dev/nsa0). <command>pax</command> biztonsági mentést végzõ szoftverek pax pax POSIX IEEE A &man.pax.1; az IEEE/&posix; válasza a tar és cpio programokra. Az évek során a tar és a cpio különbözõ változatai egy kissé inkompatibilissé váltak. Ezért a szabványosításuk kiharcolása helyett inkább a &posix; létrehozott egy új archiváló segédprogramot. A pax megpróbálja írni és olvasni a cpio és tar formátumok legtöbb változatát, valamint emellett további saját formátumokat is kezel. A parancskészlete inkább a cpio parancséra emlékeztet, mintsem a tar parancséra. <application>Amanda</application> biztonsági mentést végzõ szoftverek Amanda Amanda Az Amanda (Advanced Maryland Network Disk Archiver) egy kliens-szerver alapú mentési rendszer, nem pedig egy önálló program. Az Amanda szerver menti tetszõleges számú számítógép adatát egyetlen szalagra, melyek az Amanda klienst futtatják és hálózaton keresztül hozzá csatlakoznak. A nagy mennyiségû és nagy kapacitású lemezekkel rendelkezõ rendszerekben közvetlenül a mentéshez szükséges idõ nem áll rendelkezésre a feladat elvégzéséhez. Az Amanda viszont képes megoldani ezt a problémát. Az Amanda képes egy saját lemez használatával egyszerre több állományrendszerrõl is biztonsági mentést készíteni. Az Amanda archívumkészleteket hoz létre: az Amanda konfigurációs állományában megadott állományrendszerekrõl készít teljes mentést egy adott idõ alatt egy adott mennyiségû szalagra. Az archívumkészlet ezenkívül még tartalmaz egy napi inkrementális (vagy különbözeti) mentést is minden egyes állományrendszerrõl. A sérült állományrendszerek visszaállításához mindig a legújabb teljes biztonsági mentésre és a hozzátartozó inkrementális mentésekre van szükségünk. A konfigurációs állomány segítségével precíz irányítást gyakorolhatunk a létrehozott mentések és az Amanda által keltett hálózati forgalom felett. Az Amanda a fentiek közül bármelyik programmal képes az adatokat szalagra rögzíteni. Az Amanda portként vagy csomagként is elérhetõ, alapértelmezés szerint nem települ. Ne csináljunk semmit A Ne csináljunk semmit nem egy újabb számítógépes program, hanem egy igen gyakran alkalmazott mentési stratégia. Nem kell beruházni. Nem kell semmilyen biztonsági mentési rendet követni. Egyszerûen semmit se csinálunk. Ha véletlenül valami történne az adatainkkal, akkor csak mosolyogjunk és törõdjünk bele! Amennyiben az idõnk és adataink keveset vagy éppen semmit se érnek, akkor a Ne csináljunk semmit az elérhetõ legjobb biztonsági mentési megoldás számítógépünk számára. De legyünk óvatosak, mert a &unix; egy igen hasznos eszköz, és fél éven belül könnyen úgy találhatjuk magunkat, hogy mégis csak vannak értékes adataink. A Ne csináljunk semmit tökéletesen megfelelõ mentési módszer a /usr/obj és a hozzá hasonló módon a számítógépen automatikusan generált könyvtárak és állományok esetében. Ugyanilyen példa lehetne a kézikönyv HTML vagy &postscript; változata. Ezek a formátumok ugyanis az SGML források alapján keletkeznek, így a HTML vagy &postscript; állományok mentése nem életbevágó. Az SGML állományokat viszont már annál inkább mentsük! Melyik a legjobb? LISA &man.dump.8; Pont. Elizabeth D. Zwicky komolyan letesztelte az itt felsorolt összes programot. A &unix; állományrendszerek jellegzetességeinek és rajtuk az összes adatunk megõrzésének egyértelmûen a dump felel meg a legjobban. Elizabeth a minden egyes program tesztjéhez olyan állományrendszereket hozott létre, amelyek rengeteg különféle szokatlan helyzetet tartalmaztak (valamint néhány nem annyira szokatlant). Az érintett jellegzetességek: lyukas állományok, lyukas állományok és egy halom nulla, állományok érdekes karakterekkel a nevükben, olvashatatlan és írhatatlan állományok, eszközök, a mentés közben méretüket változtató állományok, a mentés közben keletkezõ és megszûnõ állományok és még sok minden más. Az eredményeit a LISA V-ben jelentette meg 1991. októberében. Lásd A biztonsági mentéshez és archiváláshoz használt programok tesztje (angolul). Az adatok helyreállítása vészhelyzetben A katasztrófa elõtt Csupán négy lépést kell megtennünk az esetleges katasztrófák bekövetkezésének esetére. bsdlabel Elõször is két példányban nyomtassuk ki az egyes lemezek lemezcímkéjét (például a bsdlabel da0 | lpr paranccsal) valamint az állományrendszerek táblázatát (az /etc/fstab állományt) és az összes rendszerindításkor megjelenõ üzenetet. helyreállító lemezek Másodsorban gondoskodjunk róla, hogy a helyreállító lemezek (boot.flp és fixit.flp) használatakor minden eszközünk látható. Ezt a legkönnyebben úgy tudjuk ellenõrizni, hogy újraindítjuk a gépet a lemezrõl és átnézzük a rendszerindítás során megjelenõ üzeneteket. Ha szerepel bennük minden eszköz és a rendszer indulása után mûködõképesek, akkor jöhet a következõ lépés. Ellenkezõ esetben létre kell hoznunk két saját rendszerindító lemezt, amelyeken a rendszermag olyan változata található, amely képes csatlakoztatni az összes lemezünket és el tudja érni a szalagos egységünket. A floppykon a következõknek kell meglennie: fdisk, bsdlabel, newfs, mount és a program, amellyel a biztonsági mentéseinket kezeljük. Az összes program legyen statikusan linkelt. Ha a dump programot használjuk, akkor a lemezekrõl ne felejtsük le a restore programot sem. A harmadik lépésben igyekezzünk minél gyakrabban szalagra menteni. Mindig gondoljuk arra, hogy a legutolsó mentés óta létrehozott változatásaink teljesen el fognak veszni. A mentéseket tartalmazó szalagokat tegyük írásvédetté. A negyedik lépésben ellenõrizzük a helyreállító lemezeket (vagy a boot.flp és fixit.flp állományokat, vagy a második lépésben készített saját lemezeinket) és mentéseket tartalmazó szalagokat. Jegyezzük le az eljárást. Ezeket a jegyzeteket is rakjuk el rendszerindító lemezekkel, a kinyomtatott adatokkal és a mentéseket tartalmazó szalagokkal együtt. Ezek a jegyzetek megvédenek minket attól, hogy a helyreállítás közbeni kétségbeesésünkben nehogy véletlenül tönkretegyük a biztonsági mentéseinket. (Hogy miként is? Például ha a tar xvf /dev/sa0 parancs helyett izgalmunkban a tar cvf /dev/sa0 parancsot gépeljük be, akkor azzal felülírjuk a biztonsági mentéseinket). A fokozott biztonság kedvéért minden alkalommal készítsünk rendszerindító lemezeket és legalább két mentést. Az egyiket valamilyen távoli helyen tároljuk. Ez a távoli hely NE ugyanannak az épületnek az alagsora legyen! Számos cég alaposan megtanulta ezt a szabályt a Világkereskedelmi központ tragédiája kapcsán. Ez a távoli hely számítógépeinkbõl és merevlemezes meghajtóinkól is fizikailag jól elkülöníthetõ, jelentõs távolságban legyen. A rendszerindító lemezek létrehozásához használható szkript /mnt/sbin/init gzip -c -best /sbin/fsck > /mnt/sbin/fsck gzip -c -best /sbin/mount > /mnt/sbin/mount gzip -c -best /sbin/halt > /mnt/sbin/halt gzip -c -best /sbin/restore > /mnt/sbin/restore gzip -c -best /bin/sh > /mnt/bin/sh gzip -c -best /bin/sync > /mnt/bin/sync cp /root/.profile /mnt/root chmod 500 /mnt/sbin/init chmod 555 /mnt/sbin/fsck /mnt/sbin/mount /mnt/sbin/halt chmod 555 /mnt/bin/sh /mnt/bin/sync chmod 6555 /mnt/sbin/restore # # Egy minimális állományrendszeri táblázat létrehozása. # cat > /mnt/etc/fstab < /mnt/etc/passwd < /mnt/etc/master.passwd < A katasztrófa után Az alapvetõ kérdés: a hardver túlélte? Ha rendszeresen készítettünk biztonsági mentéseket, akkor a szoftverek miatt egyáltalán nem kell aggódnunk. Ha a hardver megsérült, akkor a számítógép használatának újból megkezdése elõtt javasolt cserélni a meghibásodott alkatrészeket. Ha a hardverrel minden rendben találtunk, akkor nézzük meg a floppykat. Ha saját rendszerindító lemezt használunk, akkor indítsuk el egyfelhasználós módban (a boot: parancssornál írjuk be, hogy -s) és ugorjuk át a következõ bekezdést. Amennyiben viszont a boot.flp és fixit.flp állományok alapján készítettük a lemezeket, olvassunk tovább. Helyezzük a boot.flp tartalmú lemezt az elsõdleges floppy meghajtóba és indítsuk el vele a számítógépet. Az eredeti telepítõmenü jelenik meg ezután a képernyõn. Innen válasszuk ki a Fixit -- Repair mode with CDROM or floppy (Helyreállítás -- A rendszer helyreállítása CD-rõl vagy floppyról) menüpontot. Amikor kéri a telepítõ, tegyük be a fixit.flp alapján készült lemezt. A restore és az összes többi számunkra fontos program a /mnt2/rescue könyvtárban található (vagy a &os; 5.2-nél korábbi változatai esetén a /mnt2/stand könyvtárban). Egyenként állítsuk vissza az egyes állományrendszereket. mount gyökér partíció bsdlabel newfs A mount paranccsal próbáljuk meg csatlakoztatni az elsõ lemezünk rendszerindító partícióját (például mount /dev/da0a /mt). Ha a lemezcímke megsérült, akkor bsdlabel alkalmazásával partícionáljuk újra a lemezt és címkézzük meg a korábban kinyomtatott címke adatainak megfelelõen. A newfs segítségével újra hozzuk létre az állományrendszereket. Írható-olvasható módban csatlakoztassuk újra a floppy rendszerinító partícióját (mount -u -o rw /mnt). A biztonság mentést végzõ program és a biztonsági mentést tartalmazó szalagok használatával állítsuk helyre az állományrendszer tartalmát (például restore vrf /dev/sa0). Válasszuk le az állományrendszert (például umount /mnt). Mindegyik sérült állományrendszerre ismételjük a folyamatot. Ahogy mûködõképessé vált a rendszerünk, mentsük az adatainkat új szalagokra. Akármi is okozta a rendszer összeomlását vagy az adatvesztést, ismét lecsaphat. Ha most áldozunk erre még egy órát, akkor azzal a késõbbiekben számos kellemetlenségtõl óvhatjuk meg magunkat. * Mit tegyek, ha nem készültem fel a katasztrófára? ]]> Marc Fonvieille Átdolgozta és feljavította: Hálózat, memória és állomány alapú állományrendszerek virtuális lemezek lemezek virtuális A számítógépünkben létezõ fizikai lemezek, például floppyk, CD-k, merevlemezek és egyebek mellett a lemezek egy másik formáját is képes megérteni a &os; — a virtuális lemezeket. NFS Coda lemezek memória A virtuális lemeznek tekinthetõek többek közt az olyan hálózati állományrendszerek, mint például a Hálózati állományrendszer (Network File System, NFS) és a Coda, valamint a memóriában és állományokban létrehozott állományrendszerek. Attól függõen, hogy a &os; melyik változatát használjuk, az állomány és memória alapú állományrendszerek létrehozásához, illetve használatához különbözõ segédprogramokra lesz szükségünk. A &man.devfs.5; a felhasználó számára láthatatlan módon hozza létre az eszközök leíróit. Állomány alapú állományrendszerek lemezek állomány alapú &os; alatt az &man.mdconfig.8; segédprogram segítségével tudunk memórialemezeket (&man.md.4;) beállítani és engedélyezni. Az &man.mdconfig.8; használatához be kell töltenünk az &man.md.4; modult vagy hozzá kell tennünk a rendszermagunk beállításait tartalmazó állományhoz: device md Az &man.mdconfig.8; parancs háromféle memória alapú virtuális lemezt ismer: a &man.malloc.9;, állományok vagy lapozóterület használatával létrehozott memórialemezeket. Így lehet például csatlakoztatni a floppyk vagy CD-k állományokban tárolt image-eit. Egy meglevõ állományrendszer image-ének csatlakoztatása: Egy meglevõ állományrendszer image-ének csatlakoztatása az <command>mdconfig</command> paranccsal &prompt.root; mdconfig -a -t vnode -f image -u 0 &prompt.root; mount /dev/md0 /mnt Új állományrendszer létrehozása az &man.mdconfig.8; használatával: Új állomány alapú lemez létrehozása az <command>mdconfig</command> paranccsal &prompt.root; dd if=/dev/zero of=új-image bs=1k count=5k 5120+0 records in 5120+0 records out &prompt.root; mdconfig -a -t vnode -f új-image -u 0 &prompt.root; bsdlabel -w md0 auto &prompt.root; newfs md0a /dev/md0a: 5.0MB (10224 sectors) block size 16384, fragment size 2048 using 4 cylinder groups of 1.25MB, 80 blks, 192 inodes. super-block backups (for fsck -b #) at: 160, 2720, 5280, 7840 &prompt.root; mount /dev/md0a /mnt &prompt.root; df /mnt Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/md0a 4710 4 4330 0% /mnt Ha az beállítással nem adjuk meg az egység számát, akkor az &man.mdconfig.8; az &man.md.4; automatikus kiosztásán keresztül fog egy használatban még nem levõ eszközt kiválasztani. Az így kiosztott egység neve az md4 névhez hasonlóan jelenik meg a szabványos kimeneten. Az &man.mdconfig.8; használatának részleteirõl olvassuk el a hozzátartozó man oldalt. Az &man.mdconfig.8; egy nagyon sokoldalú segédeszköz, habár használatakor viszonylag sok parancsot kell kiadni egy állomány alapú állományrendszer létrehozásához. A &os; azonban alapból tartalmaz még egy &man.mdmfs.8; nevû segédprogramot is, ami az &man.md.4; lemezeket az &man.mdconfig.8; segítségével állítja be, létrehoz rajtuk egy UFS típusú állományrendszert a &man.newfs.8; segítségével és csatlakoztatja a &man.mount.8; paranccsal. Így például, ha az iménti állományrendszert akarjuk létrehozni és csatlakoztatni, akkor egyszerûen csak gépeljünk be ennyit: Állomány alapú lemezek beállítása és csatlakoztatása az <command>mdmfs</command> paranccsal &prompt.root; dd if=/dev/zero of=új-image bs=1k count=5k 5120+0 records in 5120+0 records out &prompt.root; mdmfs -F új-image -s 5m md0 /mnt &prompt.root; df /mnt Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/md0 4718 4 4338 0% /mnt Ha az paramétert az egység száma nélkül adjuk meg, akkor &man.mdmfs.8; az &man.md.4; automatikus kiosztására támaszkodva fog egy addig még nem használt eszközt kiválasztani. A &man.mdmfs.8; használatának pontos részleteivel kapcsolatban lásd a hozzátartozó man oldalt. Memória alapú állományrendszerek lemezek memória állományrendszer A memória alapú állományrendszerek esetében általában a lapozóállomány alapú megközelítést alkalmazzák. A lapozóállomány alapúság nem arra utal, hogy a memórialemezt alapból kilapozzák lemezre, hanem inkább arra, hogy a memórialemez olyan területen jön létre, amelyet szükség esetén lemezre lehet lapozni. Memória alapú lemezeket a (rendszermag szintû) &man.malloc.9; használatával is létre lehet hozni, de a malloc alapú memórialemezeknél, különösen a nagyon nagyok esetében, a rendszer könnyen össze tud omlani, ha kifut a rendelkezésére álló memóriából. Új memória alapú lemez létrehozása az <command>mdconfig</command> paranccsal &prompt.root; mdconfig -a -t swap -s 5m -u 1 &prompt.root; newfs -U md1 /dev/md1: 5.0MB (10240 sectors) block size 16384, fragment size 2048 using 4 cylinder groups of 1.27MB, 81 blks, 192 inodes. with soft updates super-block backups (for fsck -b #) at: 160, 2752, 5344, 7936 &prompt.root; mount /dev/md1 /mnt &prompt.root; df /mnt Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/md1 4718 4 4338 0% /mnt Új memória alapú lemez létrehozása az <command>mdmfs</command> paranccsal &prompt.root; mdmfs -s 5m md2 /mnt &prompt.root; df /mnt Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/md2 4846 2 4458 0% /mnt Memórialemezek leválasztása a rendszerrõl lemezek egy memórialemez leválasztása Amikor már nem akarunk tovább használni egy memória vagy állomány alapú állományrendszert, érdemes visszaadnunk az általuk felhasznált erõforrásokat a rendszernek. Elsõként válasszuk le magát az állományrendszert, majd az &man.mdconfig.8; segítségével kapcsoljuk le a lemezt a rendszerrõl és szabadítsuk fel az általa felhasznált erõforrásokat. Például az /dev/md4 eszközt így lehet lekapcsolni és felszabadítani: &prompt.root; mdconfig -d -u 4 A beállított &man.md.4; eszközökkel kapcsolatos többi információt az mdconfig -l paranccsal tudjuk lekérdezni. Tom Rhodes Írta: Az állományrendszerek pillanatképei állományrendszerek pillanatképek A &os; a Soft Updates mellett felkínál egy másik lehetõséget: az állományrendszerekrõl készíthetõ pillanatfelvételeket. Ezek a pillanatképek lehetõvé teszik a felhasználók számára, hogy adott állományrendszerekrõl képeket hozzanak létre és azt állományként kezeljék. A pillanatképeket az adott állományrendszerben kell létrehozni, és a felhasználók állományrendszerenként húsznál többet nem hozhatnak belõlük létre. Az aktív pillanatképek a szuperblokkban kerülnek rögzítésre, ezért az állományrendszerek leválasztása és újracsatlakoztatása esetén is megmaradnak, még újraindítás után is. Amikor egy pillanatképre már nincs tovább szükségünk, egy szimpla &man.rm.1; paranccsal eltávolítható. A pillanatképek tetszõleges sorrendben eltávolíthatóak, habár ilyenkor az összes általuk lefoglalt hely nem szabadul fel, mivel más pillanatképeknek még szüksége lehet bizonyos blokkjaira. Miután az &man.mksnap.ffs.8; paranccsal létrehoztunk egy pillanatképet tartalmazó állományt, beállítódik rá a módosíthatatlanságot jelentõ állományjelzõ. Egyedül az &man.unlink.1; parancs képez ez alól kivételt, mivel segítségével a pillanatképek eltávolíthatóak. A pillanatképek a &man.mount.8; paranccsal hozhatóak létre. A következõ módon tudjuk a /var egy pillanatképét elkészíteni a /var/snapshot/snap állományban: &prompt.root; mount -u -o snapshot /var/snapshot/snap /var Vagy a &man.mksnap.ffs.8; meghívásával is készíthetünk pillanatképeket: &prompt.root; mksnap_ffs /var /var/snapshot/snap Az állományrendszeren (például /var) a pillanatképeket tartalmazó állományokat a &man.find.1; paranccsal kereshetjük meg: &prompt.root; find /var -flags snapshot Ahogy elkészítettünk egy pillanatképet, több mindenre is felhasználhatjuk: Egyes rendszergazdák a pillanatképeket biztonsági mentésekhez használják, mivel ezek gond nélkül áttehetõek CD-re vagy szalagra. Az állományrendszerek sértetlenségét ellenõrzõ program, az &man.fsck.8; is lefuttatható egy ilyen pillanatképen. Feltéve, hogy az állományrendszer csatlakoztatásakor tiszta volt, mindig egy tiszta (és változásokat nem tartalmazó) eredményt kell kapnunk. Ennek megléte elengedhetetlen a háttérben futtatható &man.fsck.8; mûködéséhez. Futassuk le a &man.dump.8; segédprogramot a pillanatképen. Az így létrehozott mentés megegyezik az állományrendszer adott pillanatban felvett állapotával. Az beállítás megadásával maga a &man.dump.8; is képes egyetlen parancsban pillanatfelvételt készíteni, ebbõl létrehozni a mentést, majd eltávolítani. A pillanatképet képesek vagyunk a &man.mount.8; paranccsal az állományrendszer befagyasztott változataként csatlakoztatni: &prompt.root; mdconfig -a -t vnode -f /var/snapshot/snap -u 4 &prompt.root; mount -r /dev/md4 /mnt Így már a /mnt könyvtárba csatlakoztatva be tudjuk járni a befagyasztott /var állományrendszert. Minden a pillanatfelvétel készítésének idõpontjának megfelelõ állapotban fog maradni. Az egyetlen kivétel talán annyi, hogy korábbi pillanatképek nulla méretû állományként fognak megjelenni. Mikor befejeztük a pillanatképek használatát, a &man.umount.8; paranccsal le tudjuk választani: &prompt.root; umount /mnt &prompt.root; mdconfig -d -u 4 A és az állományrendszerek pillanatképeinek használatával, illetve mûszaki leírásukkal kapcsolatban látogassuk meg Marshall Kirk McKusick honlapját a címen (angolul). Az állományrendszerek kvótái nyilvántartás lemezterület lemezkvóták A kvóták használata az operációs rendszerben egy olyan választható lehetõség, aminek segítségével állományrendszerenként korlátozni tudjuk az egyes felhasználók vagy csoporttagok által elhasznált lemezterület és/vagy állományok mennyiségét. Ezt leggyakrabban olyan idõosztásos rendszerekben használják ki, ahol szükség lehet az egyes felhasználókra vagy csoportokra esõ erõforrások mennyiségének szabályozására. Ezzel tudjuk megakadályozni, hogy a felhasználók vagy csoportok elfogyasszák az összes rendelkezésre álló lemezterületet. A kvóták használatának beállítása Mielõtt nekilátnánk a kvóták használatának, meg kell gyõzõdnünk róla, hogy a rendszermagunkban megvan hozzá a szükséges támogatás. A kvótákat a következõ sorral lehet engedélyezni a rendszermag beállításait tartalmazó állományban: options QUOTA A gyári GENERIC rendszermag ezt alapból nem engedélyezi, ezért ehhez mindenképpen be kell állítani, le kell fordítani és telepíteni egy kell saját rendszermagot. A saját rendszermag létrehozásához kövessük a utasításait. Ha ezzel megvagyunk, akkor a következõ sorral bõvítsük ki az /etc/rc.conf állományt: enable_quotas="YES" lemezkvóták ellenõrzése A kvótákat kezelõ rendszer indításának finomabb szabályozására létezik még egy további beállítási lehetõség is. A rendszer indítása során általában az egyes állományrendszerek kvótáját a &man.quotacheck.8; program ellenõrzi. A &man.quotacheck.8; gondoskodik róla, hogy a kvótákat tároló adatbázis ténylegesen az állományrendszeren található adatokat tükrözi. Ez egy nagyon idõigényes folyamat, ami rányomja bélyegét a rendszer elindulásához szükséges idõ mennyiségére is. Amennyiben szeretnénk megtakarítani ezt a lépést, tegyük bele az /etc/rc.conf állományba a direkt erre a célra kialakított beállítást: check_quotas="NO" Végezetül az állományrendszereken az /etc/fstab megfelelõ módosításával tudjuk egyenként engedélyezni a lemezkvóták használatát. Itt lehet bekapcsolni az állományrendszerek felhasználókra vagy csoportokra, esetleg mind a kettõjükre vonatkozó kvótáikat. Ha felhasználói szintû kvótákat akarunk engedélyezni egy állományrendszeren, akkor az /etc/fstab állományban az állományrendszer beállításai közé vegyük fel a opciót. Például így: /dev/da1s2g /home ufs rw,userquota 1 2 Ehhez hasonlóan tudjuk engedélyezni a helyett a opció használatával a csoportszintû kvótákat is. A felhasználói- és csoportszintû kvóták együttes engedélyezéséhez így kell átírni az állományrendszer bejegyzését: /dev/da1s2g /home ufs rw,userquota,groupquota 1 2 Alapértelmezés szerint az állományrendszerekhez tartozó kvóták a gyökerükben található quota.user valamint quota.group állományokban tárolódnak. Errõl részletesebben az &man.fstab.5; man oldalon olvashatunk. Noha még az &man.fstab.5; man oldala szerint is megadható más elérési út a kvótákat tároló állományokhoz, semmiképpen sem javasoljuk ezt, mert úgy tûnik, hogy a kvótákat kezelõ különbözõ segédprogramok ezzel nem képesek rendesen megbirkózni. Most kell újraindítani a rendszerünket az új rendszermaggal. Az /etc/rc magától le fogja futtatni a kezdeti kvótaállományok létrehozásához szükséges parancsokat az /etc/fstab állományban megadott állományrendszereken. Ennek megfelelõen tehát nem nekünk kell kézzel létrehoznunk ezeket az állományokat. Hétköznapi esetben egyáltalán nem kell manuális futtatnunk a &man.quotacheck.8;, &man.quotaon.8; vagy &man.quotaoff.8; parancsokat. Habár ha tisztában szeretnénk lenni a pontos mûködésükkel, akkor mindenképpen lapozzuk fel a hozzájuk tartozó man oldalakat. A kvóták beállítása lemezkvóták korlátok Ahogy sikerült beállítani a kvóták használatát, egybõl ellenõrizzük is a mûködõképességüket. Ezt legegyszerûbben a következõ paranccsal tehetjük meg: &prompt.root; quota -v Itt egy sorban összefoglalva láthatjuk a jelenlegi lemezhasználatot és az egyes állományrendszereken engedélyezett kvóták korlátait. Most már készenállunk arra, hogy az &man.edquota.8; paranccsal végre korlátokat is beállítsunk a kvótákhoz. Számos beállítás áll rendelkezésünkre a felhasználók vagy csoportok által lefoglalható lemezterület vagy a létrehozható állományok számának korlátozását illetõen. A helyfoglalást szabályozhatjuk lemezterület alapján (blokk kvóta) vagy az állományok száma szerint (állományleíró kvóta), esetleg a kettõ kombinációjával. A korlátok további két kategóriára bonthatóak: erõsre és gyengére. erõs korlát Az erõs korlátot (hard limit) nem lehet túllépni. Ahogy a felhasználó eléri a számára kiszabott erõs korlátot, semmilyen további területet nem használhat fel a kérdéses állományrendszeren. Például, ha a felhasználónak az állományrendszeren 500 kilobyte-os erõs korlátot állítottunk be, és éppen 490 kilobyte-nál tart, akkor a felhasználó innen már csak 10 kilobyte-nyi helyet foglalhat le. 11 kilobyte lefoglalása már nem fog sikerrel járni. gyenge korlát Ezzel szemben a gyenge korlátok (soft limit) egy adott ideig átléphetõek. Ezt az idõt türelmi idõnek (grace period) nevezik, ami alapértelmezés szerint egy hét. Ha a felhasználó a gyenge korláton felül marad a türelmi idõ után is, akkor ezt a gyenge korlát erõssé válik és semmilyen további helyfoglalásra nem lesz lehetõsége. Amikor a felhasználók újra a gyenge korlát alá kerül, a türelmi idõ is visszaáll a beállított értékére. A most következõ példában az &man.edquota.8; parancsot mutatjuk be. Amikor meghívjuk az &man.edquota.8; parancsot, akkor elindul az EDITOR környezeti változónak megfelelõ szövegszerkesztõ, illetve ennek hiányában a vi, és lehetõségünk nyílik a kvóta korlátainak módosítására. &prompt.root; edquota -u teszt Quotas for user teszt: /usr: kbytes in use: 65, limits (soft = 50, hard = 75) inodes in use: 7, limits (soft = 50, hard = 60) /usr/var: kbytes in use: 0, limits (soft = 50, hard = 75) inodes in use: 0, limits (soft = 50, hard = 60) Normális esetben minden kvótával rendelkezõ állományrendszerhez két sort kapunk. Közülük az egyik sorban szerepelnek a blokkok korlátai, a másikban az állományleírók korlátai. Ha valamelyiküket meg akarjuk változtatni, akkor egyszerûen csak át kell írnunk az adott korlát értékét. Például növeljük meg a felhasználók 50-es gyenge és 75-ös erõs blokk korlátját 500-as gyenge és 600-as erõs korlátra. Ehhez szerkesszük át a /usr: kbytes in use: 65, limits (soft = 50, hard = 75) sort erre: /usr: kbytes in use: 65, limits (soft = 500, hard = 600) Az új korlátok akkor fognak érvénybe lépni, miután kiléptünk a szövegszerkesztõbõl. Néha hasznos lehet a korlátokat adott felhasználói azonosítókhoz beállítani. Ezt az &man.edquota.8; parancs paraméterével tudjuk elvégezni. Elõször is állítsuk be egy felhasználónak a beállítani kívánt korlátokat, majd futtassuk le az edquota -p teszt kezdõuid-véguid parancsot. Például ha a teszt nevû felhasználónak állítottuk be a számunkra megfelelõ korlátokat, akkor a következõ paranccsal lehet a rá vonatkozó korlátokat kiterjeszteni a 10 000 és 19 999 közötti azonosítójú felhasználókra: &prompt.root; edquota -p teszt 10000-19999 Errõl bõvebben az &man.edquota.8; man oldalán kaphatunk felvilágosítást. A kvóták korlátainak és a lemezhasználat ellenõrzése lemezkvóták ellenõrzése A kvóták korlátait és a lemez jelenlegi kihasználtságát a &man.quota.1; vagy &man.repquota.8; parancsokkal is ellenõrizhetjük. A &man.quota.1; parancs segítségével ellenõrizhetõ az egyes felhasználók vagy csoportok kvótája és lemezhasználata. A felhasználók csak a saját adataikhoz férhetnek hozzá, illetve mindazon csoportokéhoz, aminek tagjai. Egyedül a rendszeradminisztrátor képes látni az összes felhasználó és csoport kvótáját. A &man.repquota.8; paranccsal kérdezhetõ le az összes kvóta és lemezhasználat rövid kimutatása minden olyan állományrendszeren, ahol azok engedélyezettek. A következõ kimenet a quota -v parancstól származik, ahol a felhasználónak két állományrendszeren is vannak kvótái: Disk quotas for user teszt (uid 1002): Filesystem usage quota limit grace files quota limit grace /usr 65* 50 75 5days 7 50 60 /usr/var 0 50 75 0 50 60 türelmi idõ A fenti példában látható, hogy a felhasználó a /usr állományrendszeren pillanatnyilag 15 kilobyte-tal van az 50 kilobyte-os gyenge korlátja felett és 5 napja van hátra a türelmi idõbõl. Vegyük észre a szám mellett levõ csillagot (*), amivel a rendszer jelzi, hogy a felhasználó túllépte a korlátját. A &man.quota.1; parancs kimenetében általában nem jelennek meg azok az állományrendszerek, amelyeken a felhasználónak ugyan vannak kvótái, de nem foglal rajtuk lemezterületet. A beállítás megadásával ezek az állományrendszerek is láthatóvá válnak, mint ahogy azt a fenti példában is megfigyelhettük a /usr/var esetében. Kvóták NFS-en keresztül NFS A kvóták az NFS szerver kvótákért felelõs alrendszerében is engedélyezhetõek. Az &man.rpc.rquotad.8; démon teszi az NFS klienseken futtatott &man.quota.1; parancsok számára elérhetõvé a kvótákkal kapcsolatos információkat, aminek köszönhetõen a felhasználók távolról is képesek lekérdezni a kvótáikat. Az rpc.rquotad aktivilásához a következõt kell beállítani az /etc/inetd.conf állományban: rquotad/1 dgram rpc/udp wait root /usr/libexec/rpc.rquotad rpc.rquotad Majd ne felejtsük el újraindítani az inetd démont sem: &prompt.root; /etc/rc.d/inetd restart Lucky Green Írta:
shamrock@cypherpunks.to
 A lemezpartíciók titkosítása lemezek titkosítása A &os; kitûnõ futásközbeni védelmet ajánl fel az adatok illetéktelen hozzáférése ellen. Az állományok engedélyei és a kötelezõ hozzáférés-vezérlés (Mandatory Access Control, MAC, lásd ) segítenek megvédeni érzékeny adatainkat az illéktelenek ellen az operációs rendszer futása és a számítógép mûködése során. Azonban az operációs rendszerben kezelt engedélyek teljesen hatástalanok abban az esetben, ha a támadó fizikailag is képes hozzáférni a számítógépünkhöz, eltávolítani a merevlemezt és egy másik operációs rendszer segítségével kielemezni a rajta található fontos adatainkat. Függetlenül attól, hogy a támadó valójában miként is férkõzött hozzá a merevlemezünkhöz, vagy miként kapcsolta le a számítógépünket, a &os; megtalálható GEOM alapú lemeztitkosítás (gbde) és a geli titkosítási alrendszer egyaránt képes védelmet nyújtani a számítógépen található állományrendszerek számára az értékes adatok után kutató igen motivált betörõk ellen. A csupán egyes állományokra kiterjedõ körmönfont titkosítási módszerekkel szemben a gbde és a geli az egész állományrendszert észrevétlen módon titkosítja. Titkosítatlan adat nem is kerül a merevlemezre. A lemez titkosítása a <application>gbde</application> használatával Váljunk <username>root</username> felhasználóvá A gbde beállításához rendszeradminisztrátori jogosultságokra lesz szükségünk. &prompt.user; su - Password: Adjuk hozzá a &man.gbde.4; támogatását a rendszermag konfigurációs állományához Tegyük a következõ sort a rendszermag beállításait tartalmazó állományba: options GEOM_BDE Fordítsuk újra a rendszermagot a ben leírtak szerint. Indítsuk el a számítógépet az új rendszermaggal. A rendszermag újrafordítása helyett a kldload paranccsal is betölthetjük a &man.gbde.4; modulját: &prompt.root; kldload geom_bde A titkosított merevlemez elõkészítése A következõ példa azt feltételezi, hogy a rendszerünkhöz egy új merevlemezt adunk hozzá, amin egyetlen titkosított partíció foglal helyet. Ezt a partíciót a /private könyvtárba fogjuk csatlakoztatni. A gbde használható a /home és a /var/mail titkosítására is, de ennek megvalósítása olyan bonyolult utasításokat igényel, amelyek meghaladják ennek a bevezetésnek a kereteit. Az új merevlemez hozzáadása A ban bemutatottak szerint adjuk hozzá a rendszerünkhöz az új merevlemezt. A példában az új lemez partícióját a /dev/ad4s1c néven fogjuk tudni elérni. A /dev/ad0s1* eszközök a példában szereplõ &os; rendszer szabványos partícióit jelölik. &prompt.root; ls /dev/ad* /dev/ad0 /dev/ad0s1b /dev/ad0s1e /dev/ad4s1 /dev/ad0s1 /dev/ad0s1c /dev/ad0s1f /dev/ad4s1c /dev/ad0s1a /dev/ad0s1d /dev/ad4 Hozzunk létre egy könyvtárat a gbde zárolásainak tárolásához &prompt.root; mkdir /etc/gbde A gbdenek azért van szüksége a zárolásokat rögzítõ állományokra, hogy hozzá tudjon férni a titkosított partíciókhoz. Amennyiben ezt nem tudja megtenni, a gbde anélkül nem lesz képes visszafejteni a titkosított partíciókon tárolt adatokat, hogy az ezeket elérni akaró szoftvereknek ne kelljen jelentõsebb mértékben manuálisan beavatkoznia. Mindegyik titkosított partíció külön zároló állományt használ. A gbde partíció inicializálása A gbde által használt partíciókat használatuk elõtt inicializálni kell. Ezt a mûveletet azonban csak egyszer kell elvégezni: &prompt.root; gbde init /dev/ad4s1c -i -L /etc/gbde/ad4s1c.lock A &man.gbde.8; ekkor elindít egy szövegszerkesztõt és benne egy sablon segítségével be tudjuk állítani a különbözõ konfigurációs értékeket. Az UFS1 vagy UFS2 használata esetén állítsuk a szektorméretet 2048-ra: $FreeBSD: src/sbin/gbde/template.txt,v 1.1 2002/10/20 11:16:13 phk Exp $ # # Sector size is the smallest unit of data which can be read or written. # Making it too small decreases performance and decreases available space. # Making it too large may prevent filesystems from working. 512 is the # minimum and always safe. For UFS, use the fragment size # sector_size = 2048 [...] A megjegyzés fordítása: A szektorméret az adatok írásának és olvasásának legkisebb egysége. Ha túlságosan kicsire választjuk meg, akkor csökken a teljesítmény és csökken a rendelkezésre álló hely. Ha viszont túlságosan nagyra hagyjuk, akkor azzal akadályozzuk az állományrendszerek munkáját. 512 a legkisebb érték, amely mindig megbízható. Az UFS esetén használjuk a fragmensek méretét. A &man.gbde.8; kétszer is rá fog kérdeni az adatok titkosítására használt jelmondatra. A jelmondatnak természetesen mind a kétszer ugyanannak kell lennie. A gbde védelmének hatékonysága teljesen mértékben az általunk választott jelmondat minõségétõl függ A könnyen megjegyezhetõ ám mégis biztonságos jelmondatok megválasztásához a Diceware Passphrase honlapján találunk egy kis segítséget (angolul). . A gbde init parancs létrehoz egy zároló állományt a gbde partícióhoz, amely ebben a példában az /etc/gbde/ad4s1c.lock néven keletkezett. A gbde zároló állományainak .lock névre kell végzõdniük, mivel az /etc/rc.d/gbde indítószkript csak ebben az esetben észleli rendesen. A gbde zároló állományait a titkosított partíciók tartalmával együtt kell lementeni. Miközben a zároló állomány törlése nem tudja megakadályozni, hogy az elszánt támadó visszafejtse a gbde által titkosított partíciót, addig a zároló állomány nélkül a jogos tulajdonos órási mennyiségû munka befektetése nélkül képtelen lesz hozzáférni a rajta levõ adatokhoz. Ez utóbbitól egyébként a &man.gbde.8; és a rendszer tervezõje is totálisan elhatárolja magát. A titkosított partíció illesztése a rendszermaghoz &prompt.root; gbde attach /dev/ad4s1c -l /etc/gbde/ad4s1c.lock Ekkor a titkosított partíció illesztéséhez a rendszer kérni fogja az inicializálás során választott jelmondatot. Ezután az új titkosított eszköz megjelenik a /dev könyvtárban /dev/eszköznév.bde néven: &prompt.root; ls /dev/ad* /dev/ad0 /dev/ad0s1b /dev/ad0s1e /dev/ad4s1 /dev/ad0s1 /dev/ad0s1c /dev/ad0s1f /dev/ad4s1c /dev/ad0s1a /dev/ad0s1d /dev/ad4 /dev/ad4s1c.bde Állományrendszer kialakítása egy titkosított eszközön Ahogy sikerült a titkosított eszközt illeszteni a rendszermaghoz, létre is tudunk hozni egy állományrendszert rajta. Erre a célra a &man.newfs.8; remekül használható. Mivel egy új UFS2 állományrendszerek inicializálása sokkal gyorsabb a régi UFS1 állományrendszerek inicializálásánál, ezért a &man.newfs.8; használata esetén az beállítás megadása ajánlott. &prompt.root; newfs -U -O2 /dev/ad4s1c.bde A &man.newfs.8; parancsot egy illesztett gbde partíción kell végrehajtani, amit onnan ismerhetünk meg, hogy az eszköz nevében szerepel a *.bde kiterjesztés. A titkosított partíció csatlakoztatása Hozzunk létre egy csatlakozási pontot a titkosított állományrendszer számára. &prompt.root; mkdir /privát Csatlakoztassuk a titkosított állományrendszert. &prompt.root; mount /dev/ad4s1c.bde /privát Ellenõrizzük a titkosított állományrendszer mûködõképességét A titkosított állományrendszert most már látja a &man.df.1; program és készen áll a használatra. &prompt.user; df -H Filesystem Size Used Avail Capacity Mounted on /dev/ad0s1a 1037M 72M 883M 8% / /devfs 1.0K 1.0K 0B 100% /dev /dev/ad0s1f 8.1G 55K 7.5G 0% /home /dev/ad0s1e 1037M 1.1M 953M 0% /tmp /dev/ad0s1d 6.1G 1.9G 3.7G 35% /usr /dev/ad4s1c.bde 150G 4.1K 138G 0% /private Létezõ titkosított állományrendszerek csatlakoztatása A rendszer minden egyes indítása után az összes titkosított állományrendszert tényleges használata elõtt újra illeszteni kell a rendszermaghoz, ellenõrizni az épségét és csatlakoztatni. Az ehhez szükséges parancsokat root felhasználóként kell kiadni. A gbde partíció illesztése a rendszermaghoz &prompt.root; gbde attach /dev/ad4s1c -l /etc/gbde/ad4s1c.lock A gbde partíció inicializálása során megadott jelmondatot kell megadnunk a mûvelet elvégzéséhez. Az állományrendszer épségének ellenõrzése Mivel a titkosított állományrendszerek az automatikus csatlakoztatáshoz még nem szerepeltethetõek az /etc/fstab állományban, ezért az ilyen állományrendszereket csatlakoztatásuk elõtt manuálisan ellenõriztetni kell a &man.fsck.8; lefuttatásával. &prompt.root; fsck -p -t ffs /dev/ad4s1c.bde A titkosított állományrendszer csatlakoztatása &prompt.root; mount /dev/ad4s1c.bde /privát A titkosított állományrendszer most már készen áll a használatra. A titkosított partíciók önálló csatlakoztatása Lehet írni olyan szkriptet, amely a titkosított partíciókat magától illeszti, ellenõrzi és csatlakoztatja, de biztonsági megfontolásokból semmi esetben sem szabad tartalmaznia a &man.gbde.8; jelszavát. Ehelyett azt javasoljuk, hogy az ilyen szkripteknek külön meg kelljen adni a jelszót konzolon vagy az &man.ssh.1; használatán keresztül. De használhatjuk a mellékelt rc.d szkriptet is. A szkript paramétereit az &man.rc.conf.5; állományon keresztül adhatjuk meg, például: gbde_autoattach_all="YES" gbde_devices="ad4s1c" gbde_lockdir="/etc/gbde" Ilyenkor a gbde által használt jelmondatot a rendszer indításakor kell megadni. Miután begépeltük a megfelelõ jelmondatot, a titkosított gbde partíció magától csatlakoztatásra kerül. Ez akkor lehet hasznos, ha a gbde megoldását hordozható számítógépeken alkalmazzuk. A gbde által alkalmazott titkosítási módszerek A &man.gbde.8; a szektorok tartalmát 128 bites AES használatával CBC módban titkosítja. A lemezen található minden egyes szektort eltérõ AES kulccsal kódolja. A gbde kriptográfiai felépítését, valamint mindazt, hogy az egyes szektorok kulcsai miként származtathatóak a felhasználó által megadott jelmondatból, a &man.gbde.4; man oldalán olvashatjuk. Kompatibilitási problémák A &man.sysinstall.8; nem kompatibilis a gbde által titkosított eszközökkel. A &man.sysinstall.8; indítása elõtt minden *.bde eszközt ki kell iktatni a rendszermagból, különben az eszközök keresése során össze fog omlani. A példánkban használt titkosított eszközt a következõ paranccsal kell lekapcsolni: &prompt.root; gbde detach /dev/ad4s1c Továbbá megjegyezzük azt is, hogy a &man.vinum.4; nem használja a &man.geom.4; alrendszert, ezért a gbde alkalmazása során nem használhatunk Vinum-köteteket. Daniel Gerzo Írta: A lemezek titkosítása a <command>geli</command> használatával A &os; 6.0 változatától kezdve egy új kriptográfiai GEOM osztály is a rendelkezésünkre áll, melyet pillanatnyilag &a.pjd; fejleszt. A geli segédprogram némileg különbözõ a gbde megoldásától — más lehetõségeket kínál fel és a titkosítást is egy eltérõ séma mentén valósítja meg. A &man.geli.8; legfontosabb jellemzõi a következõk: A &man.crypto.9; keretrendszerét használja — tehát ha rendelkezünk kriptográfiai hardverrel, akkor a geli automatikusan használni fogja. Több kriptográfiai algoritmust is ismer (melyek jelenleg az AES, Blowfish és a 3DES). Segítségével a rendszerindításhoz használt (gyökér) partíció is titkosítható. Ilyenkor a szükséges jelmondatot a rendszer indításakor kell megadni. Két független kulcsot (például egy kulcsot és egy céges kulcsot) is használhatunk vele. A geli gyors — egyszerûen csak szektorról szektorra titkosít. Lehetõvé teszi a mesterkulcsok mentését is visszaállítását. Ha a felhasználó véletlenül megsemmisítené a kulcsát, akkor a biztonsági mentésbõl helyreállított kulcsok segítségével vissza tudjuk szerezni az adatainkat is. Segítségével a lemezeket véletlenszerû, egyszeri jelszavakkal is illeszthetjük — ez különösen fontos lapozóterületek és ideiglenes állományrendszerek esetében. A geli által felkínált lehetõségekrõl a &man.geli.8; man oldalán találhatunk többet. A következõ lépések bemutatják, hogyan lehet a &os; rendszermagjában engedélyezni a geli támogatását, és hogyan lehet létrehozni és használni egy geli titkosítással rendelkezõ adathordozót. A geli alkalmazásához legalább a &os; 6.0-RELEASE vagy késõbbi változatára van szükségünk. Mivel a rendszermagot is módosítanunk kell, ezért rendszeradminisztrátori jogosultságok kellenek a mûveletek elvégzéséhez. A <command>geli</command> támogatásának hozzáadása a rendszermaghoz Vegyük hozzá a következõ sorokat a rendszermag beállításait tartalmazó állományhoz: options GEOM_ELI device crypto Fordítsuk újra a rendszermagot a ben leírtak szerint. Betölthetjük a geli modulját is a rendszer indításakor. Ehhez a következõ sort kell betenni a /boot/loader.conf állományba: geom_eli_load="YES" A &man.geli.8; most már használható a rendszermagban. A mesterkulcs legenerálása A most következõ példában egy kulcsot tartalmazó állomány létrehozását illusztráljuk, amit a /privát + class="directory">/privát könyvtárba csatlakoztatott titkosított adathordozó mesterkulcsához fogunk használni. A kulcs állomány a mesterkulcs titkosításához felhasznált véletlenszerû adatot fogja tartalmazni, valamint rajta kívül még a mesterkulcsot egy jelmondattal is védjük. Az adathordozó szektormérete 4 kilobyte-os lesz. Emellett még bemutatjuk, hogyan kell illeszteni egy geli-adathordozót, állományrendszert létrehozni rajta, csatlakoztatni, dolgozni vele és lekapcsolni. A nagyobb teljesítmény érdekében javasolt nagyobb szektorméretet választani (mint például 4 kilobyte). A mesterkulcsot egy jelmondattal fogjuk védeni és a kulcsok készítéséhez használt adatforrás a /dev/random lesz. A /dev/da2.eli, amelyet mit csak adathordozónak fogunk csak hívni, szektorainak mérete 4 kilobyte lesz. &prompt.root; dd if=/dev/random of=/root/da2.key bs=64 count=1 &prompt.root; geli init -s 4096 -K /root/da2.key /dev/da2 Enter new passphrase: Reenter new passphrase: Nem kötelezõ egyszerre használni a jelmondatot és a kulcs állományt. A mesterkulcs elzárásának bebiztosítására bármelyik módszer alkalmas. Ha a kulcs állomány a - paraméterrel adjuk meg, akkor a szabványos bemenetrõl olvassa be a program. Ez a példa több kulcs használatát mutatja be. &prompt.root; cat kulcs1 kulcs2 kulcs3 | geli init -K - /dev/da2 Az adathordozó illesztése a generált kulccsal &prompt.root; geli attach -k /root/da2.key /dev/da2 Enter passphrase: Az új titkosítatlan eszköz neve /dev/da2.eli lesz. &prompt.root; ls /dev/da2* /dev/da2 /dev/da2.eli Az új állományrendszer kialakítása &prompt.root; dd if=/dev/random of=/dev/da2.eli bs=1m &prompt.root; newfs /dev/da2.eli &prompt.root; mount /dev/da2.eli /privát A titkosított állományrendszer most már &man.df.1; számára is látszik és használható: &prompt.root; df -H Filesystem Size Used Avail Capacity Mounted on /dev/ad0s1a 248M 89M 139M 38% / /devfs 1.0K 1.0K 0B 100% /dev /dev/ad0s1f 7.7G 2.3G 4.9G 32% /usr /dev/ad0s1d 989M 1.5M 909M 0% /tmp /dev/ad0s1e 3.9G 1.3G 2.3G 35% /var /dev/da2.eli 150G 4.1K 138G 0% /private Az adathordozó leválasztása és lekapcsolása Miután befejeztük a munkát a titkosított partíción, és a /privát + class="directory">/privát partícióra már nincs tovább szükségünk, érdemes leválasztanunk és kiiktatnunk a geli titkosítású partíciót a rendszermagból. &prompt.root; umount /privát &prompt.root; geli detach da2.eli A &man.geli.8; használatáról bõvebben a saját man oldalán tájékozódhatunk. A <filename>geli</filename> <filename>rc.d</filename> szkriptjének használata A geli mellett találhatunk egy saját rc.d szkriptet, amely jelentõsen leegyszerûsíti a geli használatát. A geli például így paraméterezhetõ az &man.rc.conf.5; állományon keresztül: geli_devices="da2" geli_da2_flags="-p -k /root/da2.key" Ennek segítségével a /dev/da2 eszközt geli adathordozóként állítjuk be a /root/da2.key állományban található mesterkulcs felhasználásával, de az illesztéskor a geli nem kér jelmondatot (ezt csak akkor fogja tenni, ha a geli init parancs kiadásához hozzátesszük a beállítást). A rendszer leállítása elõtt pedig a geli adathordozó így automatikusan leválasztásra kerül. Az rc.d beállításával kapcsolatos tudnivalókat a kézikönyv rc.d szkriptekrõl szóló szakaszában ismerhetjük meg. Christian Brüffer Írta: A lapozóterület titkosítása lapozóterület titkosítása A &os;-ben a lapozóterület titkosítása nagyon könnyen beállítható és már a &os; 5.3-RELEASE változata óta elérhetõ. Attól függõen, hogy konkrétan a &os; melyik verzióját használjuk, a konfigurációhoz kapcsolódó beállítások némileg eltérhetnek. A &os; 6.0-RELEASE változatától kezdõdõen a &man.gbde.8; és a &man.geli.8; alrendszerek is használhatóak a lapozóterület titkosítására. A korábbi verziókban egyedül csak a &man.gbde.8; érhetõ el. Mind a két rendszer az encswap rc.d szkriptet használja. Az elõzõ szakaszban, vagyis a A lemezpartíciók titkosításában már röviden összefoglaltuk a különbözõ titkosítással foglalkozó alrendszereket. Miért kellene titkosítanunk a lapozóterületet? Hasonlóan a lemezpartíciók titkosításához, a lapozóterület titkosításának is az a célja, hogy védjük az érzékeny információkat. Képzeljük el, hogy egy olyan alkalmazással dolgozunk, amely jelszavakat kezel. Amíg ezek a jelszavak a memóriában maradnak, addig minden a legnagyobb rendben van. Azonban amikor az operációs rendszer nekilát a fizikai memória felszabadításához kilapozni ezeket az adatokat, a jelszavak titkosítatlanul kerülnek a lemez felületére és egy támadó számára könnyû prédává válnak. Ilyen helyzetekben csak lapozóterület titkosítása jelenthet megoldást. Elõkészületek A szakasz további részében a ad0s1b lesz a lapozásra használt partíció. Egészen mostanáig nem titkosítottuk a lapozóterületet. Így elképzelhetõ, hogy a lemezre már titkosítatlanul kikerültek jelszavak vagy bármilyen más érzékeny adatok. A csorba kiköszörülésére a lapozóterületen található összes adatot írjuk felül véletlenszerûen generált szeméttel: &prompt.root; dd if=/dev/random of=/dev/ad0s1b bs=1m A lapozóterület titkosítása a &man.gbde.8; használatával Ha a &os; 6.0-RELEASE vagy újabb változatát használjuk, akkor az /etc/fstab állományban tegyük hozzá a .bde utótagot az a lapozóterülethez tartozó eszköz nevéhez. # Device Mountpoint FStype Options Dump Pass# /dev/ad0s1b.bde none swap sw 0 0 A &os; 6.0-RELEASE elõtti kiadások esetében a következõ sort is hozzá kell tennünk az /etc/rc.conf állományhoz: gbde_swap_enable="YES" A lapozóterület titkosítása a &man.geli.8; használatával A &man.gbde.8; használatához hasonlóan a &man.geli.8; által felajánlott titkosítást is alkalmazhatjuk a lapozóterület védelmére. Ilyenkor az /etc/fstab állományban az .eli utótagot kell hozzátenni a lapozóterülethez tartozó eszköz névhez. # Device Mountpoint FStype Options Dump Pass# /dev/ad0s1b.eli none swap sw 0 0 Az &man.geli.8; az AES algoritmust alapértelmezés szerint 256 bites kulccsal használja. Ezek az alapértelmezések megváltoztathatóak az /etc/rc.conf állományban a geli_swap_flags beállítás használatával. A következõ sor arra utasítja az encswap rc.d szkriptet, hogy a &man.geli.8; és a Blowfish algoritmus használatával hozzon létre egy lapozópartíciót 128 bites kulccsal, 4 kilobyte-os szektormérettel és a detach on last close (lekapcsolás használat után) beállítással: geli_swap_flags="-e blowfish -l 128 -s 4096 -d" A &os; 6.2-RELEASE verzió elõtti rendszerekben a következõ sort kell használni: geli_swap_flags="-a blowfish -l 128 -s 4096 -d" A többi beállításhoz a &man.geli.8; man oldalán a onetime parancs leírását érdemes áttanulmányozni. Ellenõrizzük a mûködését Miután újraindítottuk a rendszert, a titkosított lapozóterület helyes mûködését a swapinfo paranccsal ellenõrizhetjük le. A &man.gbde.8; esetében: &prompt.user; swapinfo Device 1K-blocks Used Avail Capacity /dev/ad0s1b.bde 542720 0 542720 0% Valamint a &man.geli.8; esetében: &prompt.user; swapinfo Device 1K-blocks Used Avail Capacity /dev/ad0s1b.eli 542720 0 542720 0% diff --git a/hu_HU.ISO8859-2/books/handbook/firewalls/chapter.sgml b/hu_HU.ISO8859-2/books/handbook/firewalls/chapter.sgml index e07d83ff03..f03b7a89ec 100644 --- a/hu_HU.ISO8859-2/books/handbook/firewalls/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/firewalls/chapter.sgml @@ -1,4585 +1,4585 @@ Joseph J. Barbish Írta: Brad Davis SGML formátumúra alakította és aktualizálta: Tûzfalak tûzfalak biztonság tûzfalak Bevezetés A tûzfalakkal a rendszerünkön keresztülfolyó bejövõ és kimenõ forgalmat tudjuk szûrni. A tûzfalak egy vagy több szabályrendszer alapján vizsgálják az éppen érkezõ vagy távozó hálózati csomagokat, és vagy továbbengedik ezeket vagy megállítják. A tûzfalak szabályai a csomagok egy vagy több jellemzõjét veszik szemügyre, amelyek lehetnek például a protokoll típusa, a forrás vagy cél hálózati címe, esetleg a forrás- vagy a célport. A tûzfalak jelentõs mértékben képesek gyarapítani egy gép vagy egy hálózat védelmét. Leginkább a következõkre tudjuk felhasználni: A belsõ hálózatunkban futó alkalmazások, szolgáltatások, gépek megvédésére és elszigetelésére az internetrõl érkezõ nem kívánt forgalom ellen A belsõ hálózatban levõ gépek elérését tudjuk korlátozni vagy letiltani az interneten elérhetõ szolgáltatások felé A hálózati címfordítás (Network Address Translation, NAT) beállításához, ahol a belsõ hálózatunk privát IP-címeket használnak és egy közös kapcsolaton keresztül érik el az internetet (egyetlen IP-címmel, vagy pedig automatikusan kiosztott publikus címekkel). A fejezet elolvasása során megismerjük: hogyan adjuk meg helyesen a csomagok szûrését leíró szabályokat; a &os;-be épített tûzfalak közti különbségeket; hogyan állítsuk be és használjuk az OpenBSD PF tûzfalát; hogyan állítsuk be és használjuk az IPFILTER tûzfalat; hogyan állítsuk be és használjuk az IPFW tûzfalat. A fejezet elolvasása elõtt ajánlott: a &os;-hez és az internethez kötõdõ alapvetõ fogalmak ismerete. Röviden a tûzfalakról tûzfalak szabályrendszerei A tûzfalak szabályrendszereit alapvetõen kétféleképpen tudjuk összeállítani: inkluzív, vagyis megengedõ, illetve exkluzív vagyis kizáró módon. Az exkluzív tûzfalak minden forgalmat átengednek, amirõl nem rendelkeznek a tûzfal szabályai. Az inkluzív tûzfalak ennek pontosan az ellenkezõjét teszik. Csak azt a forgalmat engedik át, amirõl van szabály és minden mást blokkolnak. Az inkluzív tûzfalak általában biztonságosabbak az exkluzív társaiknál, mivel esetükben jelentõs mértékben visszaszorul a nem kívánatos átfolyó forgalom. Ez a típusú védelem még tovább fokozható az állapottartó tûzfalak (stateful firewall) használatával. Ilyenkor a tûzfal szemmel tartja a rajta keresztül megnyitott kapcsolatokat, és vagy csak a már meglevõ kapcsolathoz tartozó forgalmat engedi át, vagy nyit egy újat. Az állapottartó tûzfalak hátránya, hogy a Denial of Service (DoS) típusú támadásokkal szemben sokkal sérülékenyebbek olyan helyzetekben, amikor az új kapcsolatok nagyon gyorsan jönnek létre. A legtöbb tûzfal esetében azonban tudjuk vegyíteni az állapottartó és nem állapottartó viselkedést, és ezzel egy ideális beállítást kialakítani. Tûzfalak A &os; alaprendszerébe három különbözõ tûzfalat építettek be, melyek a következõk: az IPFILTER (másik nevén IPF), az IPFIREWALL (más néven IPFW) és az OpenBSD csomagszûrõje (Packet Filter, azaz PF). A forgalom szabályozására (vagyis alapvetõen a sávszélesség kihasználtságának vezérlésére) a &os; két beépített csomagot tartalmaz: ez az &man.altq.4; és a &man.dummynet.4;. Általában a Dummynet az IPFW, míg az ALTQ a PF partnere. Az IPFILTER esetében maga az IPFILTER végzi a címfordítást és a szûrést, a sávszélességet pedig az IPFW a &man.dummynet.4; vagy a PF az ALTQ segítségével. Az IPFW és a PF szabályokkal rendelkezik a rendszerünkbe érkezõ vagy onnan távozó csomagokról, habár megoldásaik teljesen máshogy mûködnek és a szabályok megadási módja is eltér. A &os; azért tartalmaz egyszerre ennyiféle tûzfalat, mert az emberek elvárásai és igényei eltérnek. Egyikük sem tekinthetõ a legjobbnak. A szerzõ egyébként az IPFILTER megoldását részesíti elõnyben, mivel egy hálózati címfordítást alkalmazó környezetben sokkal könnyebb vele megfogalmazni az állapottartó szabályokat, valamint tartalmaz egy beépített FTP proxyt is, amivel így a kimenõ FTP kapcsolatok beállítása még tovább egyszerûsödik. Mivel az összes tûzfal a csomagok fejlécének bizonyos mezõinek alapján dolgozik, ezért a tûzfal szabályrendszerét megalkotó egyénnek teljesen tisztában kell lennie a TCP/IP mûködésével, továbbá azzal, hogy ezekben a mezõkben milyen értékek szerepelhetnek és ezeket hogyan használják egy átlagos kapcsolat alatt. Ebben a témában a címen találhatunk egy remek ismertetõt (angolul). John Ferrell Átnézte és aktualizálta: Az OpenBSD csomagszûrõje (PF) és az <acronym>ALTQ</acronym> tûzfalak PF 2003 júliusában az OpenBSD PF néven ismert csomagszûrõjét átírták &os;-re és elérhetõvé tették a &os; Portgyûjteményének részeként. A PF programot beépítetten tartalmazó elsõ kiadás pedig 2004 novemberében a &os; 5.3 volt. A PF egy teljes, mindentudó tûzfal, amely támogatja az ún. ALTQ (Alternate Queuing, vagyis a váltóbesorolás) megoldást. Az ALTQ lehetõvé teszi a sávszélesség korlátozását a szolgáltatás minõsége (Quality of Service, QoS) alapján. Az OpenBSD Projekt kiváló munkát végez a PF felhasználói útmutatójának karbantartásával. A kézikönyv ezen szakasza ezért elsõsorban azzal foglalkozik, hogyan kell a PF-et &os; alatt használni, miközben igyekszik egy általános összefoglalást adni a témáról. A részletesebb információkkal kapcsolatban azonban feltétlenül nézzük meg a felhasználói útmutatót. A címen olvashatunk többet arról (angolul), hogy a PF-et hogyan használjunk &os;-n. A PF rendszermagmodul használata A &os; 5.3 megjelenése óta a PF az alaprendszer része mint futás közben betölthetõ rendszermagmodul. A rendszer induláskor tehát képes automatikusan betölteni, ha az &man.rc.conf.5; állományban megadjuk a pf_enable="YES" sort. A PF modul azonban csak akkor fog mûködésbe lépni, ha talál hozzátartozó szabályrendszert, amely alapértelmezés szerint az /etc/pf.conf állományban található. Amennyiben a PF szabályrendszere a mi esetünkben máshol található, akkor az rc.conf állományban ne felejtsük megadni a pf_rules="/elérési/útvonal/pf.szabályok" sor használatával. A &os; 7.0 kiadással a minta pf.conf állomány az - /etc + /etc könyvtárból átkerült a - /usr/share/examples/pf + /usr/share/examples/pf könyvtárba. A &os; 7.0 elõtti kiadásokban alapértelmezés szerint található egy pf.conf állomány az /etc könyvtárban. A PF modul parancssorból akár kézzel is betölthetõ: &prompt.root; kldload pf.ko A betölthetõ modul tartalmazza a &man.pflog.4; támogatását, amely segítségével naplózni is tudunk. Amennyiben a PF további szolgáltatásaira is szükségünk lenne, akkor a PF támogatását be kell építenünk a rendszermagba. A PF rendszermagbeli beállításai a rendszermag beállításai device pf a rendszermag beállításai device pflog a rendszermag beállításai device pfsync Noha egyáltalán nem szükséges beépítenünk a PF támogatását a rendszermagba, abban az esetben mégis szükségünk lehet rá, amikor a PF olyan komolyabb lehetõségeit szeretnénk kiaknázni, amelyek már nem részei a modulnak. Ilyen például a &man.pfsync.4;, amely a PF által használt állapottáblázatok bizonyos változásainak megjelenítésére alkalmas pszeudoeszköz. A &man.carp.4; megoldásával párosítva így akár hibatûrõ tûzfalak is kialakíthatóak a PF-fel. A CARP-ról bõvebb ismertetést a kézikönyv e ad. A PF rendszermag konfigurációs beállításai a /usr/src/sys/conf/NOTES állományban találhatóak: device pf device pflog device pfsync A device pf beállítás engedélyezi a csomagszûrõ tûzfalat (&man.pf.4;). A device pflog megadásával keletkezik egy &man.pflog.4; pszeudo hálózati eszköz, amellyel egy &man.bpf.4; eszközre érkezõ forgalmat tudunk naplózni. Ezután a &man.pflogd.8; démon használható tõle származó naplózott adatok rögzítésére. A device pfsync engedélyezi a &man.pfsync.4; pszeudo hálózati eszköz létrejöttét, amely az ún. állapotváltások megfigyelésére alkalmas. Az <filename>rc.conf</filename> állományban elérhetõ beállítások A következõ &man.rc.conf.5; beállítások aktiválják a rendszerindítás során a PF és a &man.pflog.4; használatát: pf_enable="YES" # a PF engedélyezése (a modul betöltése, ha kell) pf_rules="/etc/pf.conf" # a pf szabályait tartalmazó állomány pf_flags="" # a pfctl indításához szükséges további paraméterek pflog_enable="YES" # a pflogd(8) elindítása pflog_logfile="/var/log/pflog" # hol tartsa a pflogd az naplóit pflog_flags="" # a pflogd indításához szükséges paraméterek Ha a tûzfalunk mögött egy helyi hálózat is meghúzódik, akkor az ott levõ gépek számára valamilyen módon tudnunk kell továbbítani a csomagokat vagy címfordítást kell végezni, így ez is mindenképpen kelleni fog: gateway_enable="YES" # az átjáró funkciók engedélyezése A szûrési szabályok megfogalmazása A PF a beállításait a &man.pf.conf.5; állomány tárolja (amely alapértelmezés szerint az /etc/pf.conf helyen található), és az ebben található szabályok alapján módosítja, dobja el vagy éppen engedi át a csomagokat. A &os; rendszerünkben ehhez találhatunk néhány példát a /usr/share/examples/pf/ könyvtárban. A PF által használt szabályokról minden részletre kiterjedõen a PF felhasználói útmutatójában olvashatunk. A PF felhasználói útmutatójának olvasásakor ne feledkezzünk meg róla, hogy a különbözõ &os; verziók különbözõ PF verziókat tartalmaznak: &os; 5.X — OpenBSD 3.5 PF &os; 6.X — OpenBSD 3.7 PF &os; 7.X — OpenBSD 4.1 PF A &a.pf; remek hely a PF tûzfal beállításával és futtatásával kapcsolatos kérdésekre. A kérdezés elõtt azonban ne felejtsük el alaposan átnézni az archívumot! A PF használata A PF a &man.pfctl.8; segítségével vezérelhetõ. Az alábbiakban ezzel kapcsolatban most összefoglalunk néhány hasznos parancsot (de ne felejtsük el megnézni a &man.pfctl.8; man oldalon található többi lehetõséget sem): Parancs Leírás pfctl A PF engedélyezése pfctl A PF tiltása pfctl all /etc/pf.conf Az összes (címfordítási, szûrési, állapottartási stb.) szabály törlése, és az /etc/pf.conf állomány újratöltése pfctl [ rules | nat | state ] A szûrési (rules), címfordítási (nat) és állapottartási (state) információk lekérdezése pfctl /etc/pf.conf Az /etc/pf.conf állomány ellenõrzése a benne levõ szabályok betöltése nélkül Az <acronym>ALTQ</acronym> engedélyezése Az ALTQ kizárólag csak úgy használható, ha a konfigurációs beállításokon keresztül beépítjük a &os; rendszermagjába. Az ALTQ alkalmazását nem minden hálózati kártya meghajtója támogatja, ezért ezt a &man.altq.4; man oldalon ellenõrizzük. A következõ rendszermag konfigurációs beállításokkal engedélyezhetjük az ALTQ használatát és bõvíthetjük azt további lehetõségekkel: options ALTQ options ALTQ_CBQ # osztályozás alapú besorolás (Class Bases Queuing, CBQ) options ALTQ_RED # véletlen korai észlelés (Random Early Detection, RED) options ALTQ_RIO # RED befele/kifele options ALTQ_HFSC # hiearchikus csomagütemezõ (Hierarchical Packet Scheduler, HFSC) options ALTQ_PRIQ # prioritásos besorolás (Priority Queuing, PRIQ) options ALTQ_NOPCC # az SMP esetén kell Az options ALTQ az ALTQ rendszert engedélyezi. Az options ALTQ_CBQ engedélyezi a osztályozás alapú besorolást (Class Based Queuing, CBQ). A CBQ használatával a kapcsolatunkhoz tartozó sávszélességet különbözõ osztályokra vagy sorokra tudjuk bontani és a szûrési szabályoknak megfelelõen osztályozni segítségükkel a forgalmat. Az options ALTQ_RED a véletlen korai észlelés (Random Early Detection, RED) használatát engedélyezi. A RED a hálózati forgalomban keletkezõ torlódások elkerülésére alkalmas. A RED ezt a problémát úgy oldja meg, hogy méri a sorok hosszát és összeveti a hozzátartozó minimális és maximális küszöbértékekkel. Ha a sor hossza meghaladja a számára elõírt maximális értéket, akkor az új csomagokat eldobja. Nevéhez hûen a RED az eldobásra ítélt csomagokat véletlenszerûen választja ki. Az options ALTQ_RIO engedélyezi a RED használatát mind a két irányba, tehát be- és kifelé. Az options ALTQ_HFSC a pártatlan hierachikus szolgáltatási görbe alapú csomagütemezõt (Hierarchical Fair Service Curve Packet Scheduler, HFSC) engedélyezi. Vele kapcsolatban a címen találhatunk bõvebben olvasnivalót (angolul). Az options ALTQ_PRIQ a prioritásos besorolást (Priority Queuing, PRIQ) teszi elérhetõvé. A PRIQ mindig elsõként a nagyobb értékû sorban levõ forgalmat továbbítja. Az options ALTQ_NOPCC az ALTQ SMP, vagyis többprocesszoros támogatását adja meg. Ilyen típusú rendszerekben ez kötelezõ. Az IPFILTER (IPF) tûzfal tûzfalak IPFILTER Ez a szakasz fejlesztés alatt áll. Ennek megfelelõen a tartalma nem minden esetben pontos. Az IPFILTER szerzõje Darren Reed. Az IPFILTER nem kötõdik egyik rendszerhez sem: ez egy olyan nyílt forráskódú alkalmazás, amelyet átírtak &os;, NetBSD, OpenBSD, &sunos;, HP/UX és &solaris; operációs rendszerekre. Az IPFILTER karbantartása és támogatása pillanatnyilag is aktív, folyamatosan jelennek meg újabb változatai. Az IPFILTER egy rendszermag oldalán mûködõ tûzfalazási és egy címfordítási mechanizmusra alapszik, amelyet felhasználói programokkal tudunk felügyelni és vezérelni. A tûzfal szabályai az &man.ipf.8; segédprogrammal állíthatóak be vagy törölhetõek. A hálózati címfordításra vonatkozó szabályokat az &man.ipnat.1; segédprogrammal állíthatjuk be vagy törölhetjük. Az &man.ipfstat.8; segédprogram képes futás közben statisztikákat készíteni az IPFILTER rendszermagban elhelyezkedõ részeinek viselkedésérõl. Az &man.ipmon.8; program pedig az IPFILTER cselekvéseit képes a rendszernaplókba feljegyezni. Az IPF eredetileg olyan szabályfeldolgozási módszer szerint készült, amelyben az utolsó egyezõ szabály nyer és csak állapotnélküli szabályokat ismert. Az idõ múlásával az IPF részévé vált a quick opció és a keep state opción keresztül az állapottartás is, melyek drámai mértékben korszerûsítették a szabályok feldolgozásának elvét. Az IPF hivatalos dokumentációja tartalmazza a régi szabályok létrehozását és azok feldolgozásának leírását. A korszerûsített funkciók csak kiegészítésképpen jelennek meg, és az általuk felkínált elõnyök megértése egy sokkal magasabb szintû és biztonságosabb tûzfal megépítését teszik lehetõvé. A szakaszban szereplõ utasításokban olyan szabályok szerepelnek, amelyek kihasználják a quick és keep state opciókat. Ezek az inkluzív tûzfalszabályok létrehozásának alapjai. Az inkluzív tûzfalak csak olyan csomagokat engednek keresztül, amelyek megfelelnek a szabályoknak. Ezen módon képesek vagyunk megmondani, hogy a tûzfal mögül milyen szolgáltatások érhetõek el az interneten és segítségével azt is megadhatjuk, hogy az internetrõl a belsõ hálózatunkon milyen szolgáltatásokat érhetnek el. A tûzfal alapból minden mást visszautasít és naplóz. Az inkluzív tûzfalak sokkal, de sokkal megbízhatóbbak az exkluzív tûzfalaknál, ezért itt most csak ilyenekkel foglalkozunk. A régi típusú szabályokról a és címeken olvashatunk (angolul). Az IPF gyakran ismételt kérdései a címen érhetõek el (angolul). A nyílt forrású IPFILTER levelezési lista kereshetõ archívumait a címen találjuk (angolul). Az IPF engedélyezése IPFILTER engedélyezés Az IPF megtalálható a &os; alaptelepítésében mint menet közben külön betölthetõ modul. Ha az rc.conf állományba beírjuk a ipfilter_enable="YES" sort, akkor ez a modul dinamikusan betöltõdik. A betölthetõ modul alapból naplóz és a default pass all beállítást tartalmazza. Ha helyette a block all szabályt akarjuk használni, akkor emiatt még nem kell feltétlenül újrafordítanunk a &os; rendszermagját, elég ha egyszerûen csak a szabályrendszerünk végére beszúrjuk. A rendszermag beállításai a rendszermag beállításai IPFILTER a rendszermag beállításai IPFILTER_LOG a rendszermag beállításai IPFILTER_DEFAULT_BLOCK IPFILTER a rendszermag beállításai Az IPF használatához nem kötelezõ a következõ beállításokkal újrafordítani a &os; rendszermagját, itt csupán háttérinformációként szerepel. Amikor az IPF a rendszermagba kerül, a betölhetõ modulra nem lesz szükség. Az IPF a rendszermag forrásai között található /usr/src/sys/conf/NOTES állományban megadott beállításai a következõ módon foglalhatóak össze: options IPFILTER options IPFILTER_LOG options IPFILTER_DEFAULT_BLOCK Az options IPFILTER engedélyezi az IPFILTER tûzfal támogatását. Az options IPFILTER_LOG hatására az IPF az ipl csomagnaplózó pszeudo eszközre jegyzi fel a forgalmat — minden olyan szabály esetén, ahol megjelenik a log kulcsszó. Az options IPFILTER_DEFAULT_BLOCK megváltoztatja az alapértelmezett viselkedést, tehát minden olyan csomag, amely nem illeszkedik a tûzfal valamelyik pass típusú (átengedõ) szabályára, blokkolásra kerül. Ezek a beállítások csak azt követõen érvényesülnek, ha fordítottunk és telepítettünk velük egy új rendszermagot. Az <filename>rc.conf</filename> állomány beállításai Az /etc/rc.conf állományban a következõ utasításokra lesz szükségünk az IPF mûködésbe hozására a rendszer indítása során: ipfilter_enable="YES" # az ipf tûzfal indítása ipfilter_rules="/etc/ipf.rules" # betölti a szabályokat tartalmazó szöveges állományt ipmon_enable="YES" # elindítja az IP monitor naplózását ipmon_flags="-Ds" # D = indítás démonként # s = naplózás a syslog használatával # v = a tcp ablak, ack, seq csomagok naplózása # n = az IP-címek és portok feloldása Ha olyan helyi hálózat áll meg a tûzfal mögött, amely egy fenntartott privát IP-címtartományt használ, akkor még a következõ utasításokra is szükségünk lesz a címfordítás bekapcsolásához: gateway_enable="YES" # a helyi hálózat átjárója ipnat_enable="YES" # az ipnat funkció elindítása ipnat_rules="/etc/ipnat.rules" # az ipnat mûködéséhez szükséges definíciók IPF ipf Az ipf parancs használható a szabályokat tartalmazó állomány betöltésére. Általában egy állományba írjuk össze a tûzfal szabályait és ezzel a paranccsal cseréljük le egyszerre a tûzfalban levõ jelenlegi szabályokat: &prompt.root; ipf -Fa -f /etc/ipf.rules Az az összes belsõ szabály törlését jelenti. Az jelzi, hogy egy állományból kell beolvasni a betöltendõ szabályokat. Ezzel mintegy lehetõségünk van változtatni a korábban összeállított szabályainkon, futtatni a fenti IPF parancsot és ezen keresztül úgy frissíteni a szabályok friss másolatával a már mûködõ tûzfalat, hogy nem is kell újraindítanunk a rendszert. Ez a módszer igen kényelmes az új szabályok kipróbálásához, mivel bármikor tetszõlegesen végrehajtható. Az &man.ipf.8; man oldala tartalmazza a parancsnak megadható további beállításokat. Az &man.ipf.8; parancs a szabályokat tároló állományt egy szabványos szöveges állománynak tekinti, semmilyen szimbolikus helyettesítést alkalmazó szkriptet nem fogad el. Lehetõségünk van azonban olyan IPF szabályokat készíteni, amelyek kiaknázzák a szkriptek szimbolikus helyettesítésének lehetõségeit. Errõl bõvebben lásd . Az IPFSTAT ipfstat IPFILTER statisztika Az &man.ipfstat.8; alapértelmezés szerint a arra használatos, hogy le tudjuk kérdezni és megjeleníteni a tûzfalhoz tartozó számlálók értékeit, amelyek a legutóbbi indítás vagy az ipf -Z parancs által kiadott lenullázásuk óta a bejövõ vagy kimenõ forgalomból a megadott szabályoknak megfelelõ csomagok alapján gyûjtenek össze statisztikákat. A parancs mûködésének részleteit az &man.ipfstat.8; man oldalon olvashatjuk. Az &man.ipfstat.8; meghívása alapból így néz ki: input packets: blocked 99286 passed 1255609 nomatch 14686 counted 0 output packets: blocked 4200 passed 1284345 nomatch 14687 counted 0 input packets logged: blocked 99286 passed 0 output packets logged: blocked 0 passed 0 packets logged: input 0 output 0 log failures: input 3898 output 0 fragment state(in): kept 0 lost 0 fragment state(out): kept 0 lost 0 packet state(in): kept 169364 lost 0 packet state(out): kept 431395 lost 0 ICMP replies: 0 TCP RSTs sent: 0 Result cache hits(in): 1215208 (out): 1098963 IN Pullups succeeded: 2 failed: 0 OUT Pullups succeeded: 0 failed: 0 Fastroute successes: 0 failures: 0 TCP cksum fails(in): 0 (out): 0 Packet log flags set: (0) Az mint bejövõ (inbound), vagy az mint kimenõ (outbound) forgalomra vonatkozó paraméterek megadásával a rendszermagban az adott oldalon jelenleg telepített és alkalmazott szabályokat kérhetjük le és jeleníthetjük meg. Az ipfstat -in parancs így a bejövõ forgalomra vonatkozó belsõ szabályokat mutatja a szabályok számával. Az ipfstat -on parancs a kimenõ forgalmat érintõ belsõ szabályokat mutatja a szabályok számával. Az eredmény körülbelül ilyen lesz: @1 pass out on xl0 from any to any @2 block out on dc0 from any to any @3 pass out quick on dc0 proto tcp/udp from any to any keep state Az ipfstat -ih a bejövõ forgalomhoz tartozó belsõ szabályokat mutatja és mindegyik elé odaírja, hogy eddig mennyi csomag illeszkedett rájuk. Az ipfstat -oh ugyanígy a kimentõ forgalom esetén mutatja a belsõ szabályokat és mindegyik elõtt feltünteti, hogy az adott pillanatig mennyi csomag illeszkedett rájuk. A kimenete nagyjából ilyen lesz: 2451423 pass out on xl0 from any to any 354727 block out on dc0 from any to any 430918 pass out quick on dc0 proto tcp/udp from any to any keep state Az ipfstat parancs talán egyik legfontosabb funkciója a kapcsolóval csalható elõ, melynek hatására a rendszerben aktív állapotok táblázatát mutatja meg ugyanúgy, ahogy a &man.top.1; a &os; rendszerben futó programokat. Amikor a tûzfalunk támadás alatt áll, ezzel a funkcióval tudjuk a problémát beazonosítani, leásni a mélyébe és látni a támadótól érkezõ csomagokat. A kiegészítésképpen megadható alkapcsolók megadásával kiválaszthatjuk azt a cél vagy forrás IP-címet, portot vagy protokollt, amelyet valós idõben meg akarunk figyelni. Ennek részleteit az &man.ipfstat.8; man oldalán láthatjuk. Az IPMON ipmon IPFILTER naplózás Az ipmon megfelelõ mûködéséhez be kell kapcsolnunk a rendszermag IPFILTER_LOG beállítását. Ez a parancs két különbözõ módban használható. Ha parancsot a opció nélkül gépeljük be, akkor ezek közül alapból a natív módot kapjuk meg. A démon mód abban az esetben hasznos, ha folyamatosan naplózni akarjuk a rendszerben zajló eseményeket, majd késõbb ezeket átnézni. Így képes egymással együttmûködni a &os; és az IPFILTER. A &os; beépítve tartalmaz olyan lehetõséget, aminek révén magától cseréli a rendszernaplókat. Ezért ha átküldjük a syslogd démonnak a naplózandó üzeneteket, akkor sokkal jobban járunk, mintha egyszerûen csak mezei állományba naplóznánk. Az rc.conf alapértelmezései között az ipmon_flags beállítás a kapcsolókat rögzíti: ipmon_flags="-Ds" # D = indítás démonként # s = naplózás a syslog használatával # v = a tcp ablak, ack, seq csomagok naplózása # n = az IP-címek és portok nevének feloldása Ennek a viselkedésnek az elõnyei minden bizonnyal egyértelmûek. Segítségével képesek vagyunk az esetek megtörténte után átnézni, hogyan milyen csomagokat dobott el a rendszer, azok milyen címekrõl érkeztek és hova szánták. Ez egy komoly fegyver a támadók lenyomozásában. Hiába engedélyezzük a naplózást, az IPF önszántából semmilyen naplózási szabályt nem fog gyártani. A tûzfal gazdájának kell eldöntenie, hogy a szabályokat közül melyiket akarja naplózni, és így neki kell megadnia a log kulcsszót ezekben az esetekben. Normális esetben csak a deny szabályokat naplózzák. Egyáltalán nem ritka, hogy a szabályrendszer végén egy alapértelmezés szerint mindent eldobó szabály áll, amely naplóz. Ezzel lehetõségünk nyílik rögzíteni azokat a csomagokat, amelyek egyetlen szabályra sem illeszkedtek. Naplózás az IPMON használatával A syslogd egy saját módszert alkalmaz a naplózott adatok elkülönítésére. Egy funkciók (facility) és szintek (level) segítségével kialakított speciális csoportosítást alkalmaz. Az IPMON módja a security (biztonság) funkciót használja. Tehát az IPMON által naplózott összes adat a security csoportjába kerül. Ezen túl a következõ szinteken különíthetjük el igényeinknek megfelelõen a naplózott adatokat: LOG_INFO - az átengedés vagy blokkolás helyett a "log" kulcsszóval ellátott csomagok LOG_NOTICE - az át is engedett csomagok LOG_WARNING - a blokkolt csomagok LOG_ERR - a naplózott csomagok közül azok, amelyek túlságosan kicsik (hibás a fejlécük) Az IPFILTER csak akkor tud naplózni a /var/log/ipfilter.log állományba, ha elõtte létrehozzuk. Az alábbi parancs erre tökéletesen megfelelõ: &prompt.root; touch /var/log/ipfilter.log A syslog mûködését az /etc/syslog.conf állományban szereplõ definíciók vezérlik. A syslog.conf állomány számottevõ mértékben képes meghatározni azt, ahogy a syslog az IPF és a hozzá hasonló alkalmazásoktól kapott rendszerszintû üzeneteket kezeli. Az /etc/syslog.conf állományba az alábbi sor kell felvennünk: security.* /var/log/ipfilter.log A security.* megadásával az összes ilyen típusú üzenet egy elõre rögzített helyre kerül. Az /etc/syslog.conf állományban elvégzett módosításokat úgy léptethetjük érvénybe, ha újraindítjuk a számítógépet vagy az /etc/rc.d/syslogd reload paranccsal megkérjük a syslog programot, hogy olvassa újra az /etc/syslog.conf állományt. Az imént létrehozott naplót ne felejtsük el megadni az /etc/newsyslog.conf állományban sem, és akkor ezzel a cseréjét is megoldjuk. A naplózott üzenetek formátuma Az ipmon által létrehozott üzenetek whitespace karakterekkel elválasztott adatmezõkbõl állnak. A következõ mezõk az összes üzenet esetében megjelennek: A csomag megérkezésének dátuma A csomag megérkezésének idõpontja. ÓÓ:PP:MM.E alakban jelennek meg az órák, percek, másodpercek és ezredmásodpercek (ez több számjegy hosszú is lehet) szerint Annak a felületnek a neve, ahol a csomag feldolgozásra került, például dc0 A szabályhoz tartozó csoport és sorszám, például @0:17 Ezek az ipfstat -in paranccsal nézhetõek meg. Cselekvés: a p mint átment (passed), b mint blokkolt (blocked), S mint rövid csomag (short packet), n mint egyik szabályra sem illeszkedett (not match), L mint naplózás (log). A módosítók megjelenítésének sorrendje: S, p, b, n, L. A nagybetûs P és B azt jelzi, hogy a csomagot egy felsõbb szintû beállítás miatt naplózták, nem egy szabály hatására. Címek: ez tulajdonképpen három mezõt takar: a forrás címet és portot (melyet egy vesszõ választ el), a -> jelet és cél címet és portot. Például: 209.53.17.22,80 -> 198.73.220.17,1722. A PR után a protokoll neve vagy száma olvasható, például PR tcp. A len csomaghoz tartozó fejléc és törzsének teljes hosszát jelöli, például len 20 40. Amennyiben a csomag TCP, egy kötõjellel kezdõdõen további mezõk is megjelenhetnek a beállított opcióknak megfelelõ betûk képében. A betûket és beállításaikat az &man.ipmon.8; man oldalán olvashatjuk. Amennyiben a csomag ICMP, a sort két mezõ zárja, melyek közül az elsõ tartalma mindig ICMP, és ezt egy perjellel elválasztva az ICMP üzenet típusa és altípusa követi. Tehát például az ICMP 3/3 a nem elérhetõ port üzenetet hordozza. A szabályok felírása szimbolikus helyettesítéssel Az IPF használatában gyakorlott felhasználók közül néhányan képesek olyan stílusú szabályrendszert készíteni, ahol szimbolikus helyettesítést használnak. Ennek az egyik legnagyobb elõnye az, hogy ilyenkor elég csak a szimbolikus névhez tartozó értéket megváltoztatni és amikor a szkript lefut, akkor az összes rá hivatkozó szabályba ez kerül be. Szkript lévén a szimbolikus helyettesítéssel ki tudjuk emelni a gyakran használt értékeket és behelyettesíteni ezeket több helyre. Ezt a most következõ példában láthatjuk. Az itt alkalmazott felírás kompatibilis az sh, csh és tcsh parancsértelmezõkkel. A szimbolikus helyettesítést egy dollárjellel fejezzük ki: $. A szimbolikus mezõkben nem szerepel a $ jelölés. A szimbolikus mezõ tartalmát kettõs idézõjelbe (") tesszük. Kezdjük így el a szabályok írását: ######### Az IPF szabályait tartalmazó szkript eleje ########### oif="dc0" # a kimenõ felület neve odns="192.0.2.11" # az internet szolgáltató névszerverének IP-címe myip="192.0.2.7" # a szolgáltatótól kapott statikus IP-címünk ks="keep state" fks="flags S keep state" # Választhatunk, hogy az /etc/ipf.rules állományt ebbõl a szkriptbõl # hozzuk létre vagy futtathatjuk "magát" a szkriptet. # # Egyszerre csak az egyik sort használjuk. # # 1) Ezzel gyárhatjuk le az /etc/ipf.rules állományt: #cat > /etc/ipf.rules << EOF # # 2) Ezzel futtathajuk "magát" a szkriptet: /sbin/ipf -Fa -f - << EOF # Engedélyezzük a szolgáltató névszerverének elérését. pass out quick on $oif proto tcp from any to $odns port = 53 $fks pass out quick on $oif proto udp from any to $odns port = 53 $ks # Engedélyezzük kifelé a titkosítatlan www funkciót. pass out quick on $oif proto tcp from $myip to any port = 80 $fks # Engedélyezzük kifelé a TLS SSL felett üzemelõ titkosított www funkciót. pass out quick on $oif proto tcp from $myip to any port = 443 $fks EOF ################## Itt az IPF szkript vége ######################## Ennyi lenne. A példában szereplõ szabályok most nem annyira lényegesek, a hangsúly most igazából a szimbolikus helyettesítésen és annak használatán van. Ha a fenti példát az /etc/ipf.rules.script állományba mentjük, akkor ezeket a szabályokat a következõ paranccsal újra tudjuk tölteni: &prompt.root; sh /etc/ipf.rules.script Egyetlen aprócska gond van a beágyazott szimbólumokat tartalmazó állományokkal: az IPF maga nem képes megérteni a helyettesítéseket, azért közvetlenül nem olvassa a szkriptet. Ez a szkript két módon hasznosítható: Vegyük ki megjegyzésbõl a cat paranccsal kezdõdõ sort, és tegyük megjegyzésbe az /sbin/ipf kezdetût. A megszokottak szerint tegyük az ipfilter_enable="YES" sort az /etc/rc.conf állományba, majd minden egyes módosítása után futtassuk le a szkriptet az /etc/ipf.rules állomány létrehozásához vagy frissítéséhez. Tiltsuk le az IPFILTER aktiválását a rendszerindításkor, tehát írjuk bele az ipfilter_enable="NO" sort (ami mellesleg az alapértelmezett értéke) az /etc/rc.conf állományba. Tegyünk egy, az alábbi szkripthez hasonlót az /usr/local/etc/rc.d/ könyvtárba. A szkriptnek adjuk valamilyen értelmes nevet, például ipf.loadrules.sh. Az .sh kiterjesztés használata kötelezõ. #!/bin/sh sh /etc/ipf.rules.script A szkript engedélyeit állítsuk be úgy, hogy a root tulajdonában legyen és képes legyen olvasni, írni valamint végrehajtani. &prompt.root; chmod 700 /usr/local/etc/rc.d/ipf.loadrules.sh Most miután a rendszer elindult, az IPF szabályai be fognak töltõdni. Szabályrendszerek az IPF-ben Az ipf esetében a szabályrendszer olyan szabályokból áll, amelyek a csomagokról tartalmuk alapján eldöntik, hogy át kell engedni vagy vissza kell tartani. A gépek közt két irányban áramló csomagok egy munkamenet alapú társalgást képeznek. A tûzfal szabályrendszere minden csomagot kétszer dolgoz fel: egyszer, amikor befut az internetrõl, illetve még egyszer, amikor visszatér az internetre. Mindegyik TCP/IP szolgáltatást (például telnet, www, levelezés stb.) elõre meghatározza a hozzátartozó protokoll, cél és forrás IP-cím vagy port. Ez az alapja a szolgáltatások engedélyezésérõl vagy tiltásáról szóló szabályok megfogalmazásának. IPFILTER a szabályok feldolgozásának sorrendje Az IPF eredetileg úgy íródott, hogy a szabályokat az utolsó illeszkedõ szabály nyer stílusban dolgozza fel és csak állapot nélküli szabályokat ismert. Az idõk folyamán az IPF szabályai kiegészültek a quick és az állapottartásra vonatkozó keep state opciókkal, amelynek köszönhetõen óriási mértékben korszerûsödött a szabályok feldolgozása. A szakaszban szereplõ utasítások olyan szabályokat alkalmaznak, amelyekben egyaránt szerepel a quick és az állapottartásért felelõs keep state beállítás. Ez az inkluzív tûzfalak létrehozásának egyik alapeszköze. Az inkluzív tûzfalak csak olyan szolgáltatásokat engednek át, amelyek megfelelnek valamelyik szabálynak. Ezzel lényegében meg tudjuk adni, hogy milyen szolgáltatások érhetõek el a tûzfal mögül az internet felé, valamint az internetrõl a magánhálózatunkon. A tûzfal minden mást elutasít és alapértelmezés szerint naplóz. Az inkluzív tûzfalak sokkal, de sokkal biztonságosabbak az exkluzív tûzfalaknál, ezért itt most csak ezzel az egyetlen típussal foglalkozunk. A tûzfal szabályainak összeállítása során nagyon óvatosnak kell lennünk! Bizonyos beállítások hatására akár ki is zárhatjuk magunkat a szerverünkrõl. Az ebbõl fakadó esetleges kellemetlenségek elkerülése érdekében javasoljuk, hogy a tûzfal alapjait elõször helyi konzolról építsük fel, ne pedig távolról, például ssh segítségével. A szabályok felépítése IPFILTER a szabályok felépítése A szabályok felépítésének bemutatását itt most leszûkítjük a modern állapottartó szabályokra és az elsõ illeszkedõ szabály nyer típusú feldolgozásra. A szabályok felírásának régebbi módjai az &man.ipf.8; man oldalon találhatóak. A # karakterrel egy megjegyzés kezdetét jelezzük, és általában a sor végén vagy egy külön sorban bukkan fel. Az üres sorokat a rendszer nem veszi figyelembe. A szabályok kulcsszavakat tartalmaznak. Ezeknek a kulcsszavaknak balról jobbra haladva adott sorrendben kell szerepelniük. A kulcsszavakat kiemeltük. Egyes kulcsszavakhoz további beállítások is tartozhatnak, amelyek maguk is kulcsszavak lehetnek, és még további opciókkal rendelkezhetnek. Az alábbi nyelvtan mindegyik elemét kiemeltük és az alábbiakban egyenként kifejtjük a részleteiket. CSELEKVÉS BE-KI OPCIÓK SZÛRÉS ÁLLAPOTTARTÓ PROTOKOLL FORRÁS_CÍM,CÉL_CÍM OBJEKTUM PORTSZÁM TCP_BEÁLLÍTÁS ÁLLAPOTTARTÓ CSELEKVÉS = block | pass BE-KI = in | out OPCIÓK = log | quick | on felületnév SZÛRÉS = proto érték | forrás/cél IP | port = szám | flags beállítás PROTOKOLL = tcp/udp | udp | tcp | icmp FORRÁS_CÍM,CÉL_CÍM = all | from objektum to objektum OBJEKTUM = IP-cím | any PORTSZÁM = portszám TCP_BEÁLLÍTÁS = S ÁLLAPOTTARTÓ = keep state CSELEKVÉS A cselekvés határozza meg, hogy mit kell tenni azokkal a csomagokkal, amelyek illeszkednek a szabály többi részére. Minden szabályhoz tartoznia kell egy cselekvésnek. A következõ cselekvések közül választhatunk: A block megadásával a szabályban szereplõ szûrési feltételre illeszkedõ csomagot eldobjuk. A pass megadásával a szabályban szereplõ szûrési feltételre illeszkedõ csomagot átengedjük a tûzfalon. BE-KI Az összes szûrési szabály esetében kötelezõ egyértelmûen nyilatkozunk arról, hogy a bemenõ vagy a kimenõ forgalomra vonatkozik. Ezért a következõ kulcsszó vagy az in vagy pedig az out, de közülük egyszerre csak az egyiket szabad használni, máskülönben a szabály hibásnak minõsül. Az in jelenti, hogy a szabályt az internet felõl az adott felületen beérkezõ csomagokra kell alkalmazni. Az out jelenti, hogy a szabályt az internet felé az adott felületen kiküldött csomagokra kell alkalmazni. OPCIÓK Ezek az opciók csak a lentebb bemutatott sorrendben használhatók. A log jelzi, hogy illeszkedés esetén a csomag fejlécét az ipl eszközön keresztül naplózni kell (lásd a naplózásról szóló szakaszt). A quickjelzi, hogy illeszkedés esetén ez lesz a legutolsónak ellenõrzött szabály és így egy olyan rövidzárat tudunk képezni a feldolgozásban, amellyel elkerüljük a csomagra egyébként vonatkozó többi szabály illesztését. Ez az opció a korszerûsített szabályfeldolgozás kihasználásához elengedhetetlen. Az on használatával a szûrés feltételei közé bevonhatjuk a csomaghoz tartozó hálózati felületet. Itt a felületek az &man.ifconfig.8; által megjelenített formában adhatóak meg. Az opció megadásával csak az adott felületen az adott irányba (befelé/kifelé) közlekedõ csomagokra fog illeszkedni a szabály. Ez az opció a korszerûsített szabályfeldolgozás kihasználásához nélkülözhetetlen. Amikor naplózunk egy csomagot, akkor a hozzátartozó fejléc az IPL csomagnaplózó pszeudo eszközhöz kerül. A log kulcsszó után közvetlenül a következõ minõsítõk szerepelhetnek (a következõ sorrendben): A body jelzi, hogy a csomag tartalmának elsõ 128 byte-ját még jegyezzük fel a fejléc mellé. A first minõsítõt akkor érdemes használnunk, amikor a log kulcsszót a keep state opcióval együtt alkalmazzuk, mivel ilyenkor csak a szabályt kialakító csomag kerül naplózásra és nem minden olyan, ami illeszkedik az állapottartási feltételekre. SZÛRÉS Ebben a szakaszban olyan kulcsszavak jelenhetnek meg, amelyekkel a csomagok különféle tulajdonságai alapján ítélkezhetünk azok illeszkedésérõl. Itt adott egy kiinduló kulcsszó, amelyhez további kulcsszavak is tartoznak, és amelyek közül csak egyet választhatunk. Az alábbi általános tulajdonságok alapján tudjuk szûrni a csomagokat, ebben a sorrendben: PROTOKOLL A proto egy olyan kulcsszó, amelyhez hozzá kell rendelnünk még valamelyik opcióját is. Ez az opció segít az adott protokolloknak megfelelõen válogatni a csomagok között. A korszerûsített szabályfeldolgozás lehetõségeinek kihasználásához nélkülözhetetlen. Opcióként a tcp/udp | udp | tcp | icmp, vagy bármelyik, az /etc/protocols állományban megtalálható kulcsszó felhasználható. A tcp/udp ebbõl a szempontból speciálisnak tekinthetõ, mivel hatására egyszerre illeszthetõek a szabályra a TCP és UDP csomagok, és így a protokolltól eltekintve azonos szabályok felesleges többszörözését kerülhetjük el. FORRÁS_CÍM/CÉL_CÍM Az all kulcsszó gyakorlatilag a from any to any (bárhonnan bárhova) szinonímája és nem tartozik hozzá paraméter. A from forrás to cél felépítése: a from és to kulcsszavak az IP-címek illesztésére használhatóak. Ilyenkor a szabályokban a forrás ÉS a cél paramétereknek is szerepelniük kell. Az any egy olyan speciális kulcsszó, amely tetszõleges IP-címre illeszkedik. Néhány példa az alkalmazására: from any to any vagy from 0.0.0.0/0 to any, from any to 0.0.0.0/0, from 0.0.0.0/0 to any vagy from any to 0.0.0.0. Az IP-címek megadhatóak pontozott numerikus formában a hálózati maszk bitekben mért hosszával együtt, vagy akár egyetlen pontozott numerikus IP-címként. Nincs lehetõség olyan IP-címtartományok illesztésére, amelyek nem adhatóak meg kényelmesen a maszk hosszával. A hálózati maszkok hosszának megállapításban segíthet a következõ (angol nyelvû) honlap: . PORT Amikor portra vonatkozó illeszkedést írunk elõ, megadhatjuk a forrásra és célra, amit aztán vagy csak TCP vagy pedig csak UDP csomagokra alkalmazunk. A portok feltételeinek megfogalmazásánál használhatjuk a portok számát vagy az /etc/services állományban szereplõ nevüket. Amikor a port egy from típusú objektum leírásában jelenik meg, akkor automatikusan a forrásportot jelenti, míg a to objektum leírásában pedig a célportot. A to objektumoknál a port megadása elengedhetetlen a korszerûsített szabályfeldolgozás elõnyeinek kihasználásához. Példa: from any to any port = 80. A portokat különbözõ mûveletek segítségével, numerikusan hasonlíthatjuk össze, ahol akár porttartományt is megadhatunk. port "=" | "!=" | "<" | ">" | "<=" | ">=" | "eq" | "ne" | "lt" | "gt" | "le" | "ge". A porttartományok megadásához használjuk a port "<>" | "><" felírási módot. A forrásra és célra vonatkozó paraméterek után szereplõ másik két paraméter nélkülözhetetlen a korszerûsített szabályfeldolgozás mûködéséhez. <acronym>TCP</acronym>_BEÁLLÍTÁS A beállítások csak a TCP forgalom szûrésénél érvényesülnek. A betûk jelölik azokat a lehetséges beállításokat, amelyek a TCP csomagok fejlécében megvizsgálhatóak. A korszerûsített szabályfeldolgozás a flags S paraméter segítségével ismeri fel a TCP munkameneteket kezdeményezõ kéréseket. ÁLLAPOTTARTÓ A keep state jelzi, hogy a szabály paramétereinek megfelelõ bármely csomag aktiválja az állapottartó szûrés használatát. Ez a beállítás feltétlenül szükséges a korszerûsített szabályfeldolgozás megfelelõ kihasználásához. Állapottartó csomagszûrés IPFILTER állapottartó szûrés Az állapottartó szûrés a csomagok kétirányú áramlását egy létrejött kapcsolatba sorolja be. Amikor aktiválódik, az állapottartó szabály elõre dinamikusan létrehozza a kétirányú kommunikációban megforduló csomagokhoz a megfelelõ belsõ szabályokat. Olyan vizsgálatokat végez, amelyek segítségével ki tudja deríteni, hogy a csomag küldõje és címzettje között fennálló kétirányú kapcsolat érvényes szabályok szerint zajlik-e. Minden olyan csomagot, amely nem illeszkedik megfelelõen a kapcsolatra vonatkozó sémára, csalásnak tekintjük és automatikusan eldobjuk. Az állapottartás révén lehetõségünk van a TCP vagy UDP kapcsolatokhoz tartozó ICMP csomagokat is átengedni a tûzfalon. Tehát ha kapunk egy 3-as típusú, 4-es kódú ICMP választ valamilyen böngészésre használt állapottartó szabályon keresztül kiküldött kérésre, akkor az automatikusan bejöhet. Amelyik csomagot az IPF egyértelmûen képes besorolni az aktív kapcsolatba, még ha az eltérõ protokollt is használ, beengedi. Ami ilyenkor történik: Az internethez csatlakozó felületen keresztül kifelé haladó csomagokat elõször egy dinamikus állapottábla alapján illesztjük, és ha a csomag illeszkedik az aktív kapcsolatban következõként várt csomagra, akkor átmegy a tûzfalon és a dinamikus állapottáblában frissül a kapcsolat állapota, a fennmaradó csomagok pedig a kimenõ szabályrendszer szerint kerülnek ellenõrzésre. Hasonlóan az elõzõhöz, az internethez csatlakozó felületen keresztül befelé haladó csomagokat elõször egy dinamikus állapottábla alapján illesztjük, és ha a csomag illeszkedik az aktív kapcsolatban következõként várt csomagra, akkor átmegy a tûzfalon és a dinamikus állapottáblában frissül a kapcsolat állapota, a fennmaradó csomagok pedig a bejövõ szabályrendszer szerint kerülnek ellenõrzésre. Amikor egy kapcsolat befejezõdik, automatikusan törlõdik a dinamikus állapottáblából. Az állapottartó csomagszûrés használatával az újonnan keletkezõ kapcsolatok elutasítására vagy engedélyezésére tudunk koncentrálni. Ha engedélyeztük egy új kapcsolat létrejöttét, akkor a rákövetkezõ összes többi csomag automatikusan átmegy a tûzfalon és minden más hamis csomag eldobódik. Ha tiltjuk az új kapcsolatot, akkor egyetlen rákövetkezõ csomag sem juthat át. Az állapottartó szûrés által felkínált fejlett elemzési lehetõségek képesek védelmet nyújtani a behatolók részérõl alkalmazott megannyi különbözõ támadási módszer ellen. Példa inkluzív szabályrendszerre A most következõ szabályrendszer arra mutat példát, hogyan programozzunk le egy nagyon biztonságos inkluzív tûzfalat. Az inkluzív tûzfalak csak a szabályainak megfelelõ szolgáltatásokat engedik keresztül, és alapértelmezés szerint minden mást blokkolnak. Minden tûzfal legalább két felülettel dolgozik, melyek mindegyikéhez írnunk kell szabályokat a tûzfal megfelelõ mûködéséhez. Mindegyik &unix;-típusú rendszert, köztük a &os;-t is úgy alakították ki, hogy az operációs rendszeren belüli kommunikáció az lo0 felületen és a 127.0.0.1 IP-címen keresztül történik. A tûzfal szabályai között feltétlenül szerepelniük kell olyanoknak, amelyek lehetõvé teszik ezen a speciális felületen a csomagok zavartalan mozgását. Az internetre csatlakozó felülethez kell rendelni a kifelé haladó forgalom hitelesítését és az internetrõl befelé irányuló hozzáférés vezérlését. Ez lehet a felhasználói PPP által létrehozott tun0 felület vagy a DSL-, illetve kábelmodemhez csatlakozó hálózati kártya. Ahol egy vagy több hálózati kártya is csatlakozik a tûzfal mögött elhelyezkedõ helyi magánhálózathoz, ott ezeket a felületeket úgy kell felvenni a tûzfal szabályai közé, hogy a helyi hálózaton zajló forgalmat ne akadályozzuk. A szabályokat elõször három nagy csoportba kell szerveznünk: az összes szabadon forgalmazó felület, az internet felé haladó kimenõ forgalom és az internet felõl befelé haladó forgalom. Az egyes csoportokban szereplõ szabályokat úgy kell megadni, hogy közülük elõre kerüljenek a leggyakrabban alkalmazottak, és a csoport utolsó szabálya blokkoljon és naplózzon minden csomagot az adott felületen és irányban. A kimenõ forgalomat vezérlõ szabályrendszer csak pass (tehát átengedõ) szabályokat tartalmazhat, amelyek bentrõl az interneten elérhetõ szolgáltatásokat azonosítják egyértelmûen. Az összes ilyen szabályban meg kell jelenni a quick, on, proto, port és keep state beállításoknak. A proto tcp szabályok esetében meg kell adni a flag opciót is, amivel fel tudjuk ismertetni a kapcsolatok keletkezését és ezen keresztül aktiválni az állapottartást. A bejövõ forgalmat vezérlõ szabályrendszerben elõször az eldobni kívánt csomagokat kell megadni, aminek két eltérõ oka van. Elõször is a blokkolt elemek lehetnek egy egyébként szabályos csomag részei, amit a késõbbiekben a hitelesített szolgáltatások alapján beengedünk. Másodszor ezzel az olyan rendszertelenül érkezõ csomagokat tudjuk blokkolni, amelyeket nem akarunk a naplóban látni, mivel ilyenkor a csoport utolsójaként megadott blokkoló és naplózó szabályhoz már nem jut el. A csoport utolsó tagjaként megadott szabály blokkolja és naplózza az illétektelen hozzáféréseket, amit akár jogi bizonyítékként is felhasználhatunk a rendszerünket megtámadók ellen. A másik, amire még oda kell figyelnünk, hogy a blokkolt csomagok esetében semmilyen válasz nem keletkezik, egyszerûen csak eltûnnek. Így a támadó nem fogja tudni, hogy a csomagjai vajon elérték-e a rendszerünket. Minél kevesebb információt tudnak összegyûjteni a rendszerünkrõl a támadók, annál több idõt kell szánniuk csínytevéseik kieszelésére. Javasolt a beérkezõ OS fingerprint jellegû kéréseket az elsõ alkalmommal naplózni, mert ez az elsõ jele annak, amikor valaki meg akar támadni minket. Amikor a log first szabály alapján keletkezõ üzeneteket akarjuk látni, hívjuk meg a ipfstat -hio parancsot, ahol megjelenik, hogy melyik szabályra mennyi csomag illeszkedett. Ennek alapján el tudjuk dönteni, hogy éppen elárasztanak-e bennünket, tehát meg akarnak-e támadni. Ha ismeretlen porthoz tartozó csomagokat naplózunk, akkor az /etc/services állományban vagy a (angol nyelvû) honlap segítségével tudjuk kideríteni, hogy pontosan melyik portról van szó. Érdemes továbbá megnézni a trójai programok által használt portokat a címen (angolul). A következõ szabályrendszer egy olyan biztonságos inkluzív típusú tûzfal, amelyet maga a szerzõ is használ. Ha ezt átvesszük egy az egyben, akkor abból semmilyen bajunk nem származhat. Egyszerûen csak vegyük ki azokat a szabályokat, amelyek olyan szolgáltatásokra vonatkoznak, amiket nem akarunk hitelesíteni. Ha nem akarunk látni bizonyos üzeneteket a naplóban, akkor vegyünk fel hozzájuk egy block típusú szabályt a befelé irányuló forgalomhoz tartozó szabályok közé. Ne felejtsük el minden szabályban átírni a dc0 felület nevét annak a hálózati kártyának a felületére, amelyen keresztül csatlakozunk az internethez. A felhasználói PPP esetében ez a tun0 lesz. Tehát a következõket kell beírni az /etc/ipf.rules állományba: ################################################################# # A helyi hálózatunkon zajló forgalmat ne korlátozzuk. # Csak akkor kell, ha helyi hálózathoz is csatlakozunk. ################################################################# #pass out quick on xl0 all #pass in quick on xl0 all ################################################################# # A belsõ felületen szintén ne korlátozzunk semmit. ################################################################# pass in quick on lo0 all pass out quick on lo0 all ################################################################# # Az internet felé forgalmazó felület (kimenõ kapcsolatok) # A saját hálózatunkról belülrõl vagy errõl az átjáróról # kezdeményezett kapcsolatokat vizsgáljuk az internet felé. ################################################################# # Engedélyezzük az internet szolgáltatók névszerverének elérését, # az "xxx" helyett a névszervet IP-címét kell megadni. # Másoljuk le ezeket a sorokat, ha a szolgáltatónknak több # névszerverét is beakarjuk állítani. A címeiket az /etc/resolv.conf # állományban találjuk. pass out quick on dc0 proto tcp from any to xxx port = 53 flags S keep state pass out quick on dc0 proto udp from any to xxx port = 53 keep state # DSL vagy kábeles hálózatoknál engedélyezzük a # szolgáltatónk DHCP szerverének elérését. # Ez a szabály nem kell, ha "felhasználói PPP"-vel # kapcsolódunk az internethez, ilyenkor tehát az egész # csoport törölhetõ. # Használjuk az alábbi szabályt és keressük meg a naplóban az # IP-címet. Ha megtaláltuk, akkor tegyük bele a megjegyzésben # szereplõ szabályba és töröljük az elsõ szabályt. pass out log quick on dc0 proto udp from any to any port = 67 keep state #pass out quick on dc0 proto udp from any to z.z.z.z port = 67 keep state # Kifelé engedélyezzük a szabványos nem biztonságos WWW funkciókat. pass out quick on dc0 proto tcp from any to any port = 80 flags S keep state # Kifelé engedélyezzük a biztonságos WWW funkciókat TLS SSL # protokollal. pass out quick on dc0 proto tcp from any to any port = 443 flags S keep state # Kifelé engedélyezzük az e-mailek küldését és fogadását. pass out quick on dc0 proto tcp from any to any port = 110 flags S keep state pass out quick on dc0 proto tcp from any to any port = 25 flags S keep state # Kifelé engedélyezzük az idõ szolgáltatást. pass out quick on dc0 proto tcp from any to any port = 37 flags S keep state # Kifelé engedélyezzük az nntp híreket. pass out quick on dc0 proto tcp from any to any port = 119 flags S keep state # Kifelé engedélyezzük az átjáróról és a helyi hálózatról a nem # biztonságos FTP használatát (passzív és akív módokban is). Ez a # funkció a mûködéséhez a nat szabályokat tartalmazó állományban # hivatkozott FTP proxyt használja. Amennyiben a pkg_add paranccsal # csomagokat akarunk telepíteni az átjáróra, erre a szabályra # mindenképpen szükségünk lesz. pass out quick on dc0 proto tcp from any to any port = 21 flags S keep state # Kifelé engedélyezzük a biztonságos FTP, telnet és SCP szolgáltatások # elérését az SSH (secure shell) használatával. pass out quick on dc0 proto tcp from any to any port = 22 flags S keep state # Kifelé engedélyezzük a nem biztonságos telnet elérését. pass out quick on dc0 proto tcp from any to any port = 23 flags S keep state # Kifelé engedélyezzük FreeBSD CVSUP funkcióját. pass out quick on dc0 proto tcp from any to any port = 5999 flags S keep state # Kifelé engedélyezzük a pinget. pass out quick on dc0 proto icmp from any to any icmp-type 8 keep state # Kifelé engedélyezzük a helyi hálózatról érkezõ whois kéréseket. pass out quick on dc0 proto tcp from any to any port = 43 flags S keep state # Minden mást eldobunk és naplózzuk az elsõ elõfordulásukat. # Ezzel a szabállyal állítjuk be, hogy alapértelmezés szerint minden # blokkolva legyen. block out log first quick on dc0 all ################################################################# # Az internet felõli felület (bejövõ kapcsolatok) # A saját hálózatunk felé vagy erre az átjáróra # nyitott kapcsolatokat vizsgáljuk az internet felõl. ################################################################# # Eldobjuk az összes olyan bejövõ forgalmat, amit hivatalosan nem # lehetne továbbítani vagy fenntartott címterülethez tartozik. block in quick on dc0 from 192.168.0.0/16 to any #RFC 1918: privát IP block in quick on dc0 from 172.16.0.0/12 to any #RFC 1918: privát IP block in quick on dc0 from 10.0.0.0/8 to any #RFC 1918: privát IP block in quick on dc0 from 127.0.0.0/8 to any #helyi block in quick on dc0 from 0.0.0.0/8 to any #helyi block in quick on dc0 from 169.254.0.0/16 to any #DHCP block in quick on dc0 from 192.0.2.0/24 to any #dokumentációs célokra fenntartva block in quick on dc0 from 204.152.64.0/23 to any #Sun klaszterek összekötésére használt block in quick on dc0 from 224.0.0.0/3 to any #D és E osztályú multicast ##### Itt eldobunk egy rakás csúf dolgot ############ # Ezeket nem akarjuk a naplóban látni: # Eldobjuk a töredékcsomagokat. block in quick on dc0 all with frags # Eldobjuk a túlságosan rövid TCP csomagokat. block in quick on dc0 proto tcp all with short # Eldobjuk a forrás által közvetített (source routed) csomagokat. block in quick on dc0 all with opt lsrr block in quick on dc0 all with opt ssrr # Elutasítjuk az "OS fingerprint" kéréseket. # Naplózzuk az elsõ elõfordulást, így nálunk lesz a kíváncsiskodó # egyén IP-címe. block in log first quick on dc0 proto tcp from any to any flags FUP # Eldobunk mindent, aminek speciális beállításai vannak. block in quick on dc0 all with ipopts # Elutasítjuk a publikus pinget. block in quick on dc0 proto icmp all icmp-type 8 # Elutasítjuk az ident kéréseket. block in quick on dc0 proto tcp from any to any port = 113 # Blokkoljuk az összes Netbios szolgáltatást: 137=név, 138=datagram, # 139=session. A Netbios az MS Windows megosztását implementálja. # Blokkoljuk az MS Windows hosts2 névszerver kéréseit is a 81-es # porton. block in log first quick on dc0 proto tcp/udp from any to any port = 137 block in log first quick on dc0 proto tcp/udp from any to any port = 138 block in log first quick on dc0 proto tcp/udp from any to any port = 139 block in log first quick on dc0 proto tcp/udp from any to any port = 81 # Engedélyezzük a szolgáltatónk DHCP szerverétõl érkezõ forgalmat. # Ebben a szabályban meg kell adnunk a szolgáltató DHCP szerverének # IP-címét, mivel itt csak a hiteles forrásból fogadunk el csomagokat. # Erre csak DSL- és kábelmodemes kapcsolat esetében van szükség, a # "felhasználói PPP" alkalmazása során szükségtelen. Ez az IP-cím # megegyezik a kimenõ kapcsolatoknál megadott címmel. pass in quick on dc0 proto udp from z.z.z.z to any port = 68 keep state # Befelé engedélyezzük a szabványos WWW funkciót, mivel webszerverünk # van. pass in quick on dc0 proto tcp from any to any port = 80 flags S keep state # Befelé engedélyezzük az internetrõl érkezõ nem biztonságos telnet # kapcsolatokat. Azért nem biztonságos, mert az azonosítókat és # jelszavakat titkosítatlan formában közli az interneten keresztül. # Töröljük ezt a szabályt, ha nem használunk telnet szervert. #pass in quick on dc0 proto tcp from any to any port = 23 flags S keep state # Befelé engedélyezzük az internetrõl érkezõ biztonságos FTP, telnet és SCP # kapcsolatokat az SSH (secure shell) használatával. pass in quick on dc0 proto tcp from any to any port = 22 flags S keep state # Minden mást dobjuk el és naplózzuk az elsõ elõfordulásukat. # Az elsõ alkalom naplózásával elejét tudjuk venni a "Denial of # Service" típusú támadásoknak, amivel egyébként lehetséges lenne a # napló elárasztása. # Ez a szabály gondoskodik arról, hogy a rendszer alapértelmezés # szerint mindent eldobjon. block in log first quick on dc0 all ################### Itt van a szabályok vége ############################## <acronym>NAT</acronym> NAT IP maszkolás NAT hálózati címfordítás NAT A NAT jelentése Network Address Translation, vagyis hálózati címfordítás. A &linux; esetében ezt IP masqueradingnak, vagyis IP maszkolásnak hívják. A hálózati címfordítás és az IP maszkolás lényegben ugyanazt takarja. Az IPF címfordításért felelõs funkciójának köszönhetõen képesek vagyunk a tûzfal mögött elhelyezkedõ helyi hálózat számára megosztani az internet-szolgáltatól kapott publikus IP-címet. Sokakban felmerülhet a kérdés, hogy erre vajon mi szükségünk lehet. Az internet-szolgáltatók a magánszemélyeknek általában dinamikus IP-címeket osztanak ki. A dinamikus itt arra utal, hogy a címünk minden alkalommal változik, amikor betárcsázunk a szolgáltatóhoz vagy amikor ki- és bekapcsoljuk a modemünket. Ez az IP-cím lesz az, ami alapján az interneten elérhetõek leszünk. Most tegyük fel, hogy öt gépünk van otthon, viszont csak egyetlen elõfizetéssel rendelkezünk. Ebben az esetben öt telefonvonalat kellene használnunk és mindegyik géphez elõfizetni az internetre. A hálózati címfordítás alkalmazásával azonban mindössze egyetlen elõfizetés kell. A gépek közül négyet hozzákötünk egy switch-hez és a switch-et pedig a fennmaradó géphez, amelyen &os; fut. Ez utóbbi lesz az így kialakított helyi hálózatunk átjárója. A tûzfalban mûködõ címfordítás segítségével a helyi hálózaton található gépek IP-címeit észrevétlenül át tudjuk fordítani a hálózatunk publikus IP-címére, ahogy a csomagok elhagyják az átjárót. A beérkezõ csomagok esetében mindez visszafelé történik meg. A hálózati címfordítás gyakran a szolgáltató engedélye vagy éppen tudta nélkül történik, és ha a szolgáltató rájön, akkor a legtöbb esetben ez az elõfizetés megszûntetésével jár. Az üzleti felhasználók jóval többet fizetnek az internet kapcsolatért és általában egy olyan statikus IP-címblokkot kapnak, amely sosem változik. A szolgáltatók az üzleti célú felhasználás esetében gyakran ajánlják és támogatják a hálózati címfordítást a belsõ hálózatok számára. Az IP-címek közül adott egy tartomány, amit a címfordítást használó helyi hálózatok részére tartanak fenn. Az RFC 1918 szerint az alábbi IP-címtartományok használhatók a helyi hálózatban, mivel ezeken keresztül közvetlenül sosem lehet kijutni az internetre: Kezdõ IP: 10.0.0.0 - Záró IP: 10.255.255.255 Kezdõ IP: 172.16.0.0 - Záró IP: 172.31.255.255 Kezdõ IP: 192.168.0.0 - Záró IP: 192.168.255.255 IP<acronym>NAT</acronym> NAT IPFILTER ipnat A címfordításra vonatkozó szabályokat az ipnat paranccsal tudjuk betölteni. Az ilyen típusú szabályokat általában az /etc/ipnat.rules állományban találjuk. A részleteket lásd az &man.ipnat.1; man oldalán. Amikor a címfordítás üzembe helyezése után meg akarjuk változtatni a címfordítás szabályait, elõször a címfordítás szabályait tartalmazó állományt módosítsuk, majd a belsõ címfordítási szabályok és a címfordítási táblázatban szereplõ aktív bejegyzések törléséhez futassuk le az ipnat parancsot a beállítással. A címfordítási szabályok újratöltését egy ehhez hasonló paranccsal tudjuk elvégezni: &prompt.root; ipnat -CF -f /etc/ipnat.szabályok A címfordításhoz tartozó statisztikákat ezzel a paranccsal tudjuk lekérdezni: &prompt.root; ipnat -s A címfordítási táblázatban pillanatnyilag szereplõ összerendeléseket a következõ paranccsal tudjuk listázni: &prompt.root; ipnat -l A szabályok feldolgozásával és az aktív szabályokkal/bejegyzésekkel kapcsolatos információk részletezését így engedélyezhetjük: &prompt.root; ipnat -v A címfordítási szabályok A címfordítási szabályok nagyon rugalmasak és rengeteg olyan funkciót meg tudunk velük valósítani, ami az üzleti és otthoni felhasználók számára egyaránt hasznos. Itt most a szabályok felépítését csak egyszerûsítve mutatjuk be, leginkább a nem üzleti környezetek tekintetében. A szabályok komplett formai leírását az &man.ipnat.5; man oldalán találjuk. Egy címfordítási szabály tehát valahogy így néz ki: map FELÜLET HELYI_IP_TARTOMÁNY -> PUBLIKUS_CÍM A szabályt a map kulcsszó kezdi. A FELÜLET helyére az internet felé mutató külsõ felület nevét írjuk be. A HELYI_IP_TARTOMÁNY lesz az, amelyben a kliensek címeznek. Ez például a 192.168.1.0/24. A PUBLIKUS_CÍM lehet egy külsõ IP-cím vagy a 0/32 speciális kulcsszó, amellyel a FELÜLET-hez rendelt IP-címre hivatkozunk. Hogyan mûködik a hálózati címfordítás A publikus cél felé haladó csomag megérkezik a helyi hálózatról. Miután a kimenõ kapcsolatokra vonatkozó szabályok átengedik, a címfordítás kapja meg a szerepet és fentrõl lefelé haladva nekilát alkalmazni a saját szabályait, ahol az elsõ egyezõ szerint cselekszik. A címfordítás a szabályokat a csomaghoz tartozó felületre és a forrás IP-címére illeszti. Amikor a csomag felületének neve illeszkedik egy címfordítási szabályra, akkor ezután a csomag forrás (vagyis a helyi hálózaton belüli) IP-címérõl igyekszik eldönteni, hogy a szabály nyilának bal oldalán szereplõ tartományba esik-e. Ha erre is illeszkedik, akkor a forrás IP-címét átírjuk a 0/32 kulcsszó alapján felderített publikus IP-címre. A címfordító rutin ezt feljegyzi a saját belsõ táblázatába, így amikor a csomag visszatér az internetrõl, akkor képes lesz visszafordítani az eredeti belsõ IP-címére és feldolgozásra átadni a tûzfal szabályainak. A címfordítás engedélyezése A címfordítás életre keltéséhez a következõket kell beállítanunk az /etc/rc.conf állományban. Elõször engedélyezzük a gépünknek, hogy közvetítsen forgalmat a felületek között: gateway_enable="YES" Minden alkalommal indítsuk el a címfordításért felelõs IPNAT programot: ipnat_enable="YES" Adjuk meg az IPNAT számára a betöltendõ szabályokat: ipnat_rules="/etc/ipnat.rules" Hálózati címfordítás nagyon nagy helyi hálózatok esetében Az olyan helyi hálózatokban, ahol rengeteg PC található vagy több alhálózatot is tartalmaz, az összes privát IP-cím egyetlen publikus IP-címbe tömörítése igen komoly problémává tud dagadni és az azonos portok gyakori használata a helyi hálózatra kötött számítógépek között ütközéseket okoz. Két módon tudunk megoldást nyújtani erre a problémára. A használható portok kiosztása Egy normális címfordítási szabály valahogy így nézne ki: map dc0 192.168.1.0/24 -> 0/32 A fenti szabályban a csomag forrásportját az IPNAT változatlanul a feldolgozás után hagyja. Ha ehhez még hozzátesszük a portmap kulcsszót, akkor ezzel utasítani tudjuk az IPNAT-ot, hogy csak az adott tartományban képezze le a forrásportokat. Például a következõ szabály hatására az IPNAT a forrásportokat egy adott tartományon belül fogja módosítani: map dc0 192.168.1.0/24 -> 0/32 portmap tcp/udp 20000:60000 Ha viszont még inkább meg akarjuk könnyíteni a dolgunkat, akkor itt egyszerûen csak adjuk meg az auto kulcsszót, amellyel az IPNAT önmagától megállapítja, hogy milyen portokat tud használni: map dc0 192.168.1.0/24 -> 0/32 portmap tcp/udp auto Több publikus cím használata Minden nagyobb helyi hálózat esetében elérkezünk ahhoz a ponthoz, ahol már egyetlen publikus cím nem elég. Ha több publikus IP-címmel is rendelkezünk, akkor ezekbõl a címekbõl egy közös készletet hozhatunk létre, amibõl majd az IPNAT válogathat miközben a csomagok címeit átírja kifelé menetben. Például ahelyett, hogy a csomagokat egyetlen publikus IP-címre képeznénk le, ahogy itt tesszük: map dc0 192.168.1.0/24 -> 204.134.75.1 A hálózati maszk segítségével meg tudjuk adni IP-címek egy tartományát is: map dc0 192.168.1.0/24 -> 204.134.75.0/255.255.255.0 CIDR-jelöléssel: map dc0 192.168.1.0/24 -> 204.134.75.0/24 A portok átirányítása Gyakran elõfordul, hogy van webszerverünk, levelezõ szerverünk, adatbázis szerverünk és névszerverünk, melyek a helyi hálózat különbözõ gépein futnak. Ebben az esetben a szerverekhez tartozó forgalmat is fordítanunk kell, illetve valamilyen módon a bejövõ forgalmat is át kell irányítanunk a helyi hálózat megfelelõ gépeihez. Az IPNAT ezt a gondot a hálózati címfordítás átirányítást támogató funkcióival szünteti meg. Tegyük fel, hogy a 10.0.10.25 belsõ címen van egy webszerverünk, amelyhez a 20.20.20.5 publikus IP tartozik. Ilyenkor a következõ szabályt adjuk meg: rdr dc0 20.20.20.5/32 port 80 -> 10.0.10.25 port 80 vagy: rdr dc0 0.0.0.0/0 port 80 -> 10.0.10.25 port 80 Így tudjuk beállítani a 10.0.10.33 címmel rendelkezõ névszervert a kintrõl érkezõ névfeloldási kérések fogadására: rdr dc0 20.20.20.5/32 port 53 -> 10.0.10.33 port 53 udp Az FTP és a címfordítás Az FTP egy olyan õskövület, amely még az internet egy régi korszakából maradt fenn, amikor az egyetemek között még bérelt vonal létezett és az FTP szolgált a kutatók közt az állományok megosztására. Ez még abban az idõben történt, amikor a biztonság egyáltalán nem volt lényeges szempont. Az évek elõrehaladtával az FTP protokoll beleivódott a feltörekvõ internet gerincébe és a titkosítatlanul küldött azonosítóival és jelszavaival továbbra is ugyanolyan védtelen maradt. Az FTP két változatban, aktív és passzív módban képes mûködni. Az eltérés kettejük között az adatcsatorna megállapításában van. A passzív mód sokkal biztonságosabb, mivel ilyenkor az adatcsatornát az FTP kapcsolatot kezdeményezõ állítja be. Az FTP különbözõ módjainak magyarázatát és a köztük levõ különbséget a címen ismerhetjük meg részleteiben (angolul). Az IPNAT szabályai Az IPNAT egy speciális beépített FTP proxyval rendelkezik, amelyre a hálózati címfordítás leképezései között hivatkozhatunk. Képes figyelni az összes aktív vagy passzív FTP kapcsolathoz tartozó kimenõ kérést és ezekhez dinamikusan létrehozni olyan ideiglenes szûrési szabályokat, amelyek valóban csak az adatcsatornához felhasznált portokat tartalmazzák. Ezzel ki tudjuk küszöbölni az FTP azon káros hatását a tûzfalra nézve, hogy egyszerre túlságosan sok magasabb tartománybeli port legyen nyitva. Ez a szabály a belsõ hálózat összes FTP forgalmát lekezeli: map dc0 10.0.10.0/29 -> 0/32 proxy port 21 ftp/tcp Ez a szabály pedig az átjáróról érkezõ FTP forgalommal bírkózik meg: map dc0 0.0.0.0/0 -> 0/32 proxy port 21 ftp/tcp Ez a szabály kezeli a belsõ hálózatról érkezõ összes nem FTP típusú forgalmat: map dc0 10.0.10.0/29 -> 0/32 Az FTP leképzésére vonatkozó szabály a szokásos leképzési szabály elé kerül. Az összes csomag fentrõl haladva az elsõ illeszkedõ szabály alapján kerül feldolgozásra. Elõször a felület nevét vizsgáljuk, majd a belsõ hálózatbeli forrás IP-t, végül azt, hogy a csomag egy FTP kapcsolat része. Ha minden paraméterében megfelel, akkor az FTP proxy készít egy ideiglenes szûrési szabályt hozzá, amellyel az FTP kapcsolathoz tartozó csomagok mind a két irányba képesek lesznek vándorolni, természetesen a címfordítással együtt. Az összes többi bentrõl érkezõ csomag átlép ezen a szabályon és megáll a harmadiknál, ahol a felületnek és forrás IP-nek megfelelõen átfordítjuk a címét. Az IPNAT szûrési szabályai FTP-re Az FTP esetében csak egyetlen szûrési szabályra van szükségünk a hálózati címfordításba épített FTP proxy használatához. FTP proxy nélkül az alábbi három szabály kellene: # Kifelé engedélyezzük a belsõ gépek FTP elérést az internet irányába, # aktív és passzív módokban. pass out quick on rl0 proto tcp from any to any port = 21 flags S keep state # Kifelé engedélyezzük a passzív módhoz tartozó magasabb tartománybeli # adatcsatornákat. pass out quick on rl0 proto tcp from any to any port > 1024 flags S keep state # Aktív módban beengedjük az FTP szervertõl érkezõ adatcsatornát. pass in quick on rl0 proto tcp from any to any port = 20 flags S keep state IPFW tûzfalak IPFW Ez a szakasz fejlesztés alatt áll. Ennek megfelelõen a tartalma nem minden esetben pontos. Az IPFIREWALL (IPFW) a &os; által támogatott tûzfalazó alkalmazás, melyet a &os; Projektben résztvevõ önkéntesek fejlesztettek ki és tartanak karban. Régi típusú, állapottartás nélküli szabályokat használ, és az itt használatos szabályírási technikát egyszerû állapottartó megoldásnak nevezzük. Az IPFW szabvány &os;-ben levõ, mintaként szolgáló szabályrendszere (ez az /etc/rc.firewall állományban található meg) annyira egyszerû, hogy komolyabb módosítások nélkül nem ajánlatos használni. Ez a példa nem tartalmaz állapottartó szûrést, ami viszont a legtöbb esetben kívánatos lenne, ezért ezt a szakaszt nem erre alapozzuk. Az IPFW állapottartás nélküli szabályainak felépítésében olyan technikailag kifinomult leválogatási képességek bújnak meg, amelyek jócskán meghaladják az átlagos tûzfalépítõk tudását. Az IPFW elsõsorban olyan szakemberek vagy szakmailag elõrehaladott felhasználók számára készült, akiknek speciális csomagszûrési igényeik vannak. A különbözõ protokollok használatának és a hozzájuk tartozó fejlécinformációk mindenre kiterjedõ ismerete szinte nélkülözhetetlen az IPFW valódi erejének kihasználásához. Ez a szint azonban túlmutat a kézikönyv ezen szakaszának keretein. Az IPFW hét komponensbõl épül fel, melyek közül az elsõdleges a rendszermag tûzfalazásért felelõs szabályfeldolgozó és a hozzátartozó csomagnyilvántartás, majd ezt követi a naplózás, a hálózati címfordítást aktiváló divert szabály, valamint a komolyabb célok megvalósítására alkalmas lehetõségek: a forgalom korlátozásáért felelõs dummynet, a továbbküldésre alkalmas fwd szabály, a hálózati hidak támogatása, illetve az ipstealth. Az IPFW engedélyezése IPFW engedélyezése Az IPFW az alap &os; telepítésben külön, futás idõben betölthetõ modulként érhetõ el. Ha az rc.conf állományban megadjuk a firewall_enable="YES" beállítást, akkor a rendszer indulásakor ezt a modult dinamikusan betölti. Az IPFW-t csak akkor kell a &os; rendszermagjába beépítenünk, ha szükségünk van a címfordítási funkciójára is. Ha tehát az rc.conf állományban megadtuk a firewall_enable="YES" sort és újraindítottuk a számítógépünket, akkor a következõ fehérrel kiemelt üzenet fog megjelenni a rendszerindítás során: ipfw2 initialized, divert disabled, rule-based forwarding disabled, default to deny, logging disabled A logging disabled üzenetbõl kiderül, hogy a modul nem végez naplózást. A naplózást és a hozzátartozó részletesség szintjét úgy tudjuk beállítani, ha az /etc/sysctl.conf állományba felvesszük a következõ sorokat, amivel a következõ indításkor már mûködni fog: net.inet.ip.fw.verbose=1 net.inet.ip.fw.verbose_limit=5 A rendszermag beállításai a rendszermag beállításai IPFIREWALL a rendszermag beállításai IPFIREWALL_VERBOSE a rendszermag beállításai IPFIREWALL_VERBOSE_LIMIT IPFW a rendszermag beállításai Ha nem akarjuk kihasználni az IPFW által felkínált címfordítási lehetõségeket, akkor egyáltalán nem szükséges a &os; rendszermagjába belefordítani a támogatását. Ezért az alábbiakat csak kiegészítõ információként tüntettük fel. options IPFIREWALL Ez a beállítás engedélyezi az IPFW használatát a rendszermag részeként. options IPFIREWALL_VERBOSE Ezzel és a log kulcsszóval tudjuk az IPFW szabályain keresztülhaladó csomagokat naplózni. options IPFIREWALL_VERBOSE_LIMIT=5 Ez az érték korlátozza a &man.syslogd.8; segítségével naplózott azonos bejegyzések maximális számát. Ezt a beállítást olyan veszélyes környezetekben érdemes használnunk, ahol naplózni akarunk. Segítségével meg tudjuk akadályozni, hogy a rendszernapló elárasztásával megakasszák a rendszerünket. a rendszermag beállításai IPFIREWALL_DEFAULT_TO_ACCEPT options IPFIREWALL_DEFAULT_TO_ACCEPT Ezen beállítás hatására a tûzfal alapértelmezés szerint mindent átenged, ami általában akkor jöhet jól, amikor még csak ismerkedünk a tûzfallal. options IPV6FIREWALL options IPV6FIREWALL_VERBOSE options IPV6FIREWALL_VERBOSE_LIMIT options IPV6FIREWALL_DEFAULT_TO_ACCEPT Ezek a beállítások teljesen megegyeznek az IPv4 alapú társaikkal, csak ezek az IPv6-ra vonatkoznak. Ha nem akarunk IPV6-ot használni, akkor ne adjunk meg az IPV6FIREWALL beállításhoz szabályokat, és így az összes IPv6 csomag blokkolásra kerül. a rendszermag beállításai IPDIVERT options IPDIVERT Ezzel a beállítással engedélyezzük a címfordítás használatát. Ha nem adjuk meg az IPFIREWALL_DEFAULT_TO_ACCEPT beállítást, vagy ha nem engedélyezzük a bejövõ csomagokat, akkor a gépünkre semmilyen csomag nem lesz képes bejutni, illetve onnan kijutni. Az <filename>/etc/rc.conf</filename> beállításai Így tudjuk engedélyezni a tûzfalat: firewall_enable="YES" A &os;-hez mellékelt alapértelmezett tûzfaltípusok közül az /etc/rc.firewall állomány átolvasásával tudunk választani, és megadni az alábbi helyett: firewall_type="open" A következõ értékek állnak rendelkezésünkre: open — átengedi az összes forgalmat client — csak ezt a gépet védi simple — az egész hálózatot védi closed — a helyi felület kivételével minden IP alapú forgalmat tilt UNKNOWN — tiltja a tûzfal szabályainak betöltését állománynév — a tûzfal szabályait tartalmazó állomány abszolút elérési útvonala Két különbözõ módon lehet betölteni a saját ipfw szabályainkat. Az egyik közülük, ha a firewall_type változóban megadjuk a tûzfal szabályait tartalmazó állomány abszolút elérési útvonalát, az &man.ipfw.8; parancssori beállításai nélkül. Egy egyszerû szabályrendszer lehet például a következõ: add block in all add block out all Másrészrõl az firewall_script változóban is megadhatjuk azt a szkriptet, amelyben a rendszerindítás során meghívjuk ipfw parancsot. Az iménti szabályrendszert az alábbi szkripttel tudjuk kiváltani: #!/bin/sh ipfw -q flush ipfw add block in all ipfw add block out all Ha a firewall_type változó client vagy simple értékét használjuk, akkor az /etc/rc.firewall állományban található alapértelmezett szabályokat érdemes átvizsgálnunk, hogy kellõen illeszkednek-e az adott géphez. Hozzátennénk, hogy a fejezetben szereplõ példák azt feltételezik, hogy a firewall_script értéke az /etc/ipfw.rules állomány. A naplózás így engedélyezhetõ: firewall_logging="YES" A firewall_logging változó egyedül csak annyit tesz, hogy beállítja a net.inet.ip.fw.verbose sysctl változónak az 1 értéket (lásd ). A napló korlátozására nincs külön változó az rc.conf állományon belül, de az /etc/sysctl.conf állomány segítségével és manuálisan be tudjuk állítani a hozzátartozó változót: net.inet.ip.fw.verbose_limit=5 Amennyiben a gépünk átjáróként viselkedik, tehát a &man.natd.8; segítségével címfordítást végez, a ban olvashatunk utána, hogy ehhez az /etc/rc.conf állományban milyen beállításokat kell megadnunk. Az IPFW parancs ipfw Normál esetben az ipfw parancs használatos arra, hogy a tûzfal mûködése közben az aktív belsõ szabályai közé vegyünk fel vagy töröljünk közülük manuálisan bejegyzéseket. Ennek a módszernek az egyedüli hátránya, hogy az így végrehajtott módosítások el fognak veszni a rendszer leállításával. Itt inkább azt a megoldást javasoljuk, hogy az összes szabályt tegyük bele egy állományba és a rendszerindítás során ezt töltsük be, majd ha változtatni akarunk a tûzfalon, akkor ezt az állományt módosítsuk és a régiek törlésével töltsük be újra az egész szabályrendszert. Az ipfw parancs mellesleg remekül használható a jelenleg futó tûzfalszabályok megjelenítésére a konzolon. Az IPFW nyilvántartásában az egyes szabályokhoz dinamikusan jönnek létre számlálók, amelyek a rá illeszkedõ csomagokat számolják. A tûzfal tesztelése folyamán a szabályok és hozzátartozó számlálók lekérdezése a megfelelõ mûködés ellenõrzésének egyik lehetséges módja. A szabályokat így tudjuk egymás után felsoroltatni: &prompt.root; ipfw list A szabályokat így tudjuk az utolsó illeszkedésük idejével együtt megjeleníteni: &prompt.root; ipfw -t list A nyilvántartás lekérdezésekor a szabályok mellett az illeszkedõ csomagok száma is láthatóvá válik. Az elsõ sorban a szabály száma szerepel, majd ezt követi rendre az illeszkedõ kimenõ és bejövõ csomagok mennyisége, valamint végül maga a szabály. &prompt.root; ipfw -a list A statikus szabályok mellett a dinamikusakat így lehet kilistázni: &prompt.root; ipfw -d list A lejárt dinamikus szabályokat is meg tudjuk nézni: &prompt.root; ipfw -d -e list A számlálók nullázása: &prompt.root; ipfw zero Csak a SZÁM sorszámú szabályhoz tartozó számlálók nullázása: &prompt.root; ipfw zero SZÁM Szabályrendszerek az IPFW-ben Egy szabályrendszer lényegében nem több, mint ipfw szabályok egy csoportja, amelyekben a csomagokat tartalmuktól függõen továbbengedjük vagy eldobjuk. A gépek közti kétirányú csomagváltás egy kapcsolat létrejöttének számít. A tûzfalszabályok a csomagokat kétszer dolgozzák fel: elõször amikor az internetrõl megérkeznek, másodjára pedig akkor, amikor visszatérnek az internetre. Minden egyes TCP/IP szolgáltatást (vagyis a telnet, www, levelezés stb.) meghatároz a saját protokollja és a hozzátartozó port száma. Ez az az alapvetõ szûrési feltétel, ami alapján a szolgáltatásokhoz engedélyezését vagy tiltását megvalósító szabályokat megalkotjuk. IPFW a szabályok feldolgozásának sorrendje Amikor egy csomag eléri a tûzfalat, a szabályrendszer elsõ szabályával kerül összehasonlításra és amíg nem illeszkedik valamelyikre, addig lefut rá a többi szabály is fentrõl lefelé egyesével, a sorszámuknak megfelelõ növekvõ sorrendben. Ha a csomag megfelel valamelyik szabály leválogatási paramétereinek, akkor a benne megnevezett cselekvés zajlik le, és számára a feldolgozás befejezõdik. Ezt a viselkedést neveztük az elsõ illeszkedés nyer típusú keresésnek. Amennyiben a csomag egyetlen szabályra sem illeszkedik, akkor az ipfw 65535-ös sorszámú állandó szabálya fogja elcsípni, amely feladata szerint eldobja az összes hozzá beérkezõ csomagot anélkül, hogy bármit is válaszolna a csomag feladójának. A keresés a count, skipto és tee szabályok után még folytatódik. Az itt szereplõ utasítások az állapottartó keep state, a limit, in/out és via szabályokra építkeznek. Ezek szolgálnak az inkluzív tûzfalak megvalósításának alapvetõ eszközeiként. Az inkluzív tûzfal csak a szabályoknak megfelelõ szolgáltatásokat engedélyez. Segítségével meg tudjuk határozni, hogy a tûzfal mögül milyen szolgáltatásokat érhetünk el az interneten, valamint azt is megadhatjuk vele, hogy az internetrõl melyik szolgáltatásokhoz férhetnek hozzá a saját belsõ hálózatunkban. Felépítése szerint minden mást tilt. Az inkluzív jellegû tûzfalak sokkal bizontságosabbak az exkluzív tûzfalaknál, ezért itt most csak ilyen típusú szabályrendszerekkel foglalkozunk. A tûzfal szabályainak beállítása során nem árt óvatosnak lennünk, mert figyelmetlenségünk révén könnyen kizárathatjuk magunkat a gépünkrõl. A szabályok felépítése IPFW a szabályok felépítése Az itt bemutatásra kerülõ szabályok felépítését csak olyan mértékig részletezzük, ami elengedõ a szabványos inkluzív típusú tûzfalak kialakításához. A szabályok felépítésének pontos leírását az &man.ipfw.8; man oldalán találhatjuk meg. A szabályok kulcsszavakat tartalmaznak. Ezeket a kulcsszavakat soronként egy elõre rögzített sorrendben kell szerepeltetni. A kulcsszavakat a szövegben kiemeltük. Bizonyos kulcsszavakhoz további opciókhoz is tartozhatnak, amelyek gyakran maguk is kulcsszavak és szintén további opciókat tartalmazhatnak. A # egy megjegyzés kezdetét jelzi, mely egyaránt megjelenhet egy külön sorban, vagy egy szabályt tartalmazó sor végén. Az üres sorok nem vesznek részt a feldolgozásban. PARANCS SZABÁLY_SZÁM CSELEKVÉS NAPLÓZÁS SZÛRÉS ÁLLAPOTTARTÁS PARANCS Minden új szabály elõttt az add (mint hozzáadás) parancsnak kell szerepelni, amellyel a belsõ táblázatba tudjuk felvenni. SZABÁLY_SZÁM A szabályokhoz mindig tartozik egy sorszám is. CSELEKVÉS A szabályhoz az alábbi cselekvések valamelyike kapcsolható, amely akkor hajtódik végre, amikor a csomag megfelel a hozzátartozó szûrési feltételeknek. allow | accept | pass | permit A fentiek közül mindegyik ugyanazt jelenti, vagyis hatásukra az illeszkedõ csomag kilép a tûzfalból. Ez a szabály megállítja a keresést. check-state A csomagot a dinamikus szabályokat tároló táblázattal veti össze. Ha itt egyezést talál, akkor végrehajtja az egyezõ dinamikus szabályhoz tartozó cselekvést, minden más esetben továbblép a következõ szabályra. Ennek a szabálynak nincs illeszthetõ paramétere. Ha a szabályrendszerben nem szerepel ilyen, akkor a dinamikus szabályok vizsgálatát az elsõ keep-state vagy limit használatánál vonja be a rendszer. deny | drop Mind a két szó ugyanarra utal, vagyis a szabályra illeszkedõ csomagokat el kell dobni. Ebben az esetben a keresés befejezõdik. NAPLÓZÁS log vagy logamount Amikor egy csomag egy log kulcsszót tartalmazó szabályra illeszkedik, akkor a rendszernaplóban egy üzenet keletkezik a security (biztonság) funkción keresztül. A naplóba ténylegesen csak akkor kerül bele az üzenet, ha az adott szabály még nem haladta meg a hozzátartozó logamount paraméter értékét. Ha ezt nem adtuk meg, akkor az itt érvényes korlát a net.inet.ip.fw.verbose_limit sysctl változóból fog származni. A nulla érték mind a két esetben megszünteti ezt a korlátozást. Ha elértük a korlátot, akkor a naplózást úgy tudjuk újra engedélyezni, ha töröljük a naplózáshoz tartozó számláló értékét, lásd az ipfw reset log parancsot. A naplózás mindig az összes paraméter illeszkedésének ellenõrzése után történik, de még a cselekvés (accept, deny) elvégzése elõtt. Teljesen rajtunk múlik, hogyan milyen szabályokat naplózunk. SZÛRÉS Ebben a szakaszban azok a kulcsszavak találhatóak, amelyek segítségével a csomagok különbözõ tulajdonságait tudjuk megvizsgálni és eldönteni, hogy illeszkedik-e a szabályra vagy sem. A következõ általános tulajdonságokat tudjuk megvizsgálni, ebben a kötött sorrendben: udp | tcp | icmp Bármilyen más olyan protokoll is megadható, amely megtalálható az /etc/protocols állományban. Ezzel adjuk a csomaghoz tartozó protokollt. Használata kötelezõ. from forrás to cél Mind a from és to kulcsszavak IP-címek illesztésére alkalmasak. A szabályoknak tartalmazniuk kell a forrás ÉS a cél paramétereket is. Az any egy olyan kulcsszó, amely tetszõleges IP-címre illeszkedik. A me pedig egy olyan speciális kulcsszó, amely a tûzfalat mûködtetõ &os;-s gép (tehát ez a gép) adott felülethez tartozó IP-címét jelöli, mint ahogy a from me to any, from any to me, from 0.0.0.0/0 to any, from any to 0.0.0.0/0, from 0.0.0.0 to any, from any to 0.0.0.0 vagy from me to 0.0.0.0 paraméterekben. Az IP-címek numerikus pontozott formában a hálózati maszk hosszával együtt, vagy egyszerûen csak pontozott formában adhatóak meg. A hálózati maszkok megállapításában a címen található honlap nyújthat segítséget (angolul). port szám A portszámokat is ismerõ protokollok esetében (mint például a TCP vagy UDP) adhatjuk meg. Fontos, hogy itt annak a szolgáltatásnak a portszámát adjuk meg, amelyre a szabály vonatkozik. A szolgáltatás (az /etc/services állományból származó) nevét is megadhatjuk a port száma helyett. in | out A beérkezõ valamint a kimenõ csomagokat adhatjuk meg ezen a módon. Itt az in és out kulcsszavak, melyeket kötelezõ megadni a szabály részeként. via felület Név szerint az adott felületen keresztül haladó csomagokat tudjuk szûrni. A via kulcsszó hatására a használt felület is számítani fog a csomag feldolgozása során. setup Ez a kulcsszó a TCP csomagok esetében a kapcsolatok felépítésére vonatkozó kéréseket segít beazonosítani. keep-state Ez egy kötelezõ kulcsszó. Feldolgozásakor a tûzfal létrehoz dinamikus szabályt, amely alapértelmezés szerint az egyazon protokollt használó forrás és cél IP/port párosok közti kétirányú forgalomra fog automatikusan illeszkedni. limit {forráscím | forrásport | célcím | célport} A tûzfal csak N darab, a szabálynak megfelelõ azonos paraméterû kapcsolatot fog átengedi. Itt egy vagy több forrás- és célcím valamint forrás- és célport adható meg. A limit és a keep-state egy szabályon belül nem használható. A limit ugyanazokat az állapottartó funkciókat képviseli, mint a keep-state, csak a saját kiegészítéseivel megtoldva. ÁLLAPOTTARTÁS IPFW állapottartó szûrés Az állapottartó szûrés a kétirányú csomagváltásokat egy létrejött kapcsolatba sorolja. Olyan vizsgálatokat végez, amivel képes megállapítani, hogy a csomag küldõje és címzettje között kialakult kommunikáció követ-e valamilyen kétirányú csomagküldésre érvényes folyamatot. Az így felállított sablontól eltérõ összes csomag hamisnak minõsül és automatikusan eldobásra kerül. A check-state segítségével ellenõrizhetjük, hogy az adott csomag a IPFW szerint megfelel-e valamelyik dinamikusan leképzett szabálynak. Ha egyezik valamelyikõjükkel, akkor a csomag a tûzfalból kilépve folytatja útját és a kommunikációban soron következõ csomag számára létrejön egy másik dinamikus szabály. Ha nincs egyezés, akkor csomag feldolgozása a szabályrendszer következõ szabályánál folytatódik. A dinamikus szabályokat kezelõ rutin sebezhetõ, mivel ha egyszerre nagy mennyiségû SYN csomagot küldünk, akkor olyan sok dinamikus bejegyzés keletkezik, hogy egyszerûen kifogyunk a rendelkezésre álló erõforrásokból. A &os; fejlesztõi azonban az ilyen természetû támadások kivédésére is felkészítették, és kialakították belõle a limit opciót. Alkalmazásával le tudjuk korlátozni az egyszerre folyó párhuzamos kapcsolatok számát a forrás vagy a cél a limit paraméternél megadott mezõinek és a csomag IP-címe alapján. Így az adott szabályhoz és IP-címhez csak elõre rögzített mennyiségû nyitott állapotú dinamikus szabály létezhet egy idõben. Ha ezt a korlátot átlépjük, a csomag eldobódik. A tûzfal üzeneteinek naplózása IPFW naplózás A naplózás elõnyei nyilvánvalóak. Ha engedélyezzük, aktiválása után képesek leszünk olyan információknak utánanézni, mint például milyen csomagokat dobtunk el, honnan érkeztek, hova tartottak. Ez egy komoly fegyverünk lehet a potenciális támadókkal szemben. Azonban hiába engedélyezzünk önmagában a naplózást, attól az IPFW még saját magától nem fog naplózást elõíró szabályokat gyártani. A tûzfal karbantartóinak maguknak kell eldöntenie, hogy a szabályrendszerben mely szabályokhoz tartozzon naplózás, nekik kell felvenni ezekhez a log kulcsszót. Általában csak az eldobással járó deny típusú szabályokat vagy a bejövõ ICMP pingeket szokták naplózni. Gyakran úgy oldják meg ezt, hogy a szabályrendszer utolsó szabályaként lemásolják az ipfw alapértelmezett mindent eldobunk szabályát és a naplózást adják meg benne. Ezen a módon fény derül azokra a csomagokra, amelyek a szabályrendszerben semmire sem illeszkedtek. A naplózás azonban egy kétélû fegyver, mivel ha nem vagyunk elég körültekintõek, akkor a sok naplóinformáció között könnyen el tudunk veszni és a lemezünk is gyorsan betelhet a mindent elfoglaló naplóktól. Mellesleg a naplók megdagasztását célzó DoS típusú támadás a rendszerek lebénítására alkalmazott egyik legõsibb technika. Ezek az üzenetek nem csak a rendszernaplóba kerülnek bele, hanem az elsõdleges konzol képernyõjére is kiíródnak, ami egy idõ után idegesítõ tud lenni. A rendszermag IPFIREWALL_VERBOSE_LIMIT=5 beállításával azonban képesek vagyunk korlátozni azokat a rendszernapló felé küldött egymás után következõ üzeneteket, amelyek ugyanarra a szabályra vonatkoznak. Amikor ezt a beállítást megadjuk a rendszermag fordításánál, akkor az egyes szabályokhoz az általa meghatározott értéken felül nem jön létre több hasonló üzenet. Hiszen semmi sem derül ki 200 teljesen azonos naplóüzenetbõl. Például, ha az egyes szabályokhoz legfeljebb öt egymást követõ üzenetet engedélyezünk, akkor a többi fennmaradó azonos üzenetet összeszámolja a rendszer és a következõ módon közvetíti a rendszernaplózó szolgáltatás felé: last message repeated 45 times Ami magyarul így hangzik: az utolsó üzenet 45 alkalommal ismétlõdött meg Az összes csomagokkal kapcsolatos naplózás alapértelmezés szerint a /var/log/security állományba kerül, amelyet az /etc/syslog.conf állomány definiál. Szabályokat tartalmazó szkript készítése A rutinosabb IPFW felhasználók a szabályokat egy állományban programozzák le olyan stílusban, hogy szkriptként is futtatható legyen. Ennek az egyik legnagyobb elõnye, hogy a tûzfal szabályai így egyszerre cserélhetõek a rendszer újraindítása nélkül. Ez a módszer nagyon kényelmes az új szabályok kipróbálásánál, mivel tetszõleges alkalommal végrehajthatjuk. Mivel ez egy szkript, ki tudjuk használni az itt megszokott szimbolikus helyettesítés által felkínált lehetõségeket, és ezzel a gyakran használt értékeket is egyszerre több szabályban tudjuk helyettesíteni. Erre a következõkben fogunk egy konkrét példát látni. A szkript felépítése kompatibilis a sh, csh és tcsh parancsértelmezõkkel. A szimbolikus mezõk helyettesítését a $ vagyis dollárjel vezeti be. Maguk a szimbolikus mezõk nem tartalmazzák a $ elõtagot. A szimbolikus mezõk értékeit "kettõs idézõjelek" között kell megadni. A szabályok összeírását kezdjük el így: ####### itt kezdõdik az ipfw szabályait tartalmazó szkript ###### # ipfw -q -f flush # töröljük az összes aktuális szabályt # Set defaults oif="tun0" # a kimenõ felület odns="192.0.2.11" # az internet szolgáltató névszerverének IP-címe cmd="ipfw -q add " # a szabályok hozzáadásához szükséges elemek ks="keep-state" # csupán a lustaság miatt $cmd 00500 check-state $cmd 00502 deny all from any to any frag $cmd 00501 deny tcp from any to any established $cmd 00600 allow tcp from any to any 80 out via $oif setup $ks $cmd 00610 allow tcp from any to $odns 53 out via $oif setup $ks $cmd 00611 allow udp from any to $odns 53 out via $oif $ks #### itt fejezõdik be az ipfw szabályait tartalmazó szkript ###### Ezzel készen is vagyunk. Most ne törõdjünk a példában szereplõ szabályokkal, itt most a szimbolikus helyettesítés használatát igyekeztük bemutatni. Ha az iménti példát az /etc/ipfw.rules állományba mentettük el, akkor az alábbi parancs kiadásával tudjuk újratölteni a benne szereplõ szabályokat: &prompt.root; sh /etc/ipfw.rules Az /etc/ipfw.rules állományt egyébként tetszõleges néven hívhatjuk és bárhová rakhatjuk. Ugyanez természetesen elérhetõ a következõ parancsok egymás utáni begépelésével is: &prompt.root; ipfw -q -f flush &prompt.root; ipfw -q add check-state &prompt.root; ipfw -q add deny all from any to any frag &prompt.root; ipfw -q add deny tcp from any to any established &prompt.root; ipfw -q add allow tcp from any to any 80 out via tun0 setup keep-state &prompt.root; ipfw -q add allow tcp from any to 192.0.2.11 53 out via tun0 setup keep-state &prompt.root; ipfw -q add 00611 allow udp from any to 192.0.2.11 53 out via tun0 keep-state Állapottartó szabályrendszerek A most következõ címfordítás nélküli szabályrendszer arra mutat példát, hogyan valósítsunk meg egy biztonságos inkluzív tûzfalat. Az inkluzív tûzfalak csak a szabályainak megfelelõ szolgáltatásokat engedik át, minden mást alapértelmezés szerint tiltanak. Minden tûzfalhoz legalább két felület tartozik, és a mûködéséhez ezek mindegyikéhez meg kell adnunk szabályokat. Az &unix; mintájú operációs rendszer, köztül a &os; is olyan, hogy a rendszerben belüli kommunikációt a lo0 nevû felületen és a 127.0.0.1 IP-címen bonyolítja le. A tûzfalban mindenképpen szerepelniük kell olyan szabályoknak, amelyek gondoskodnak ezen speciális belsõ csomagok zavartalan közlekedésérõl. Az internet felé csatlakozó felület lesz az, amelyen keresztül a kifelé menõ kéréseket hitelesítjük és vezéreljük az internet elérését, valamint ahol szûrjük az internet felõl érkezõ kéréseket. Ez lehet a PPP esetében a tun0 eszköz, vagy a DSL-, illetve kábelmodemhez csatlakozó hálózati kártya. Abban az esetben, amikor egy vagy több hálózati kártyával csatlakozunk a tûzfal mögött található belsõ helyi hálózatra, szintén gondoskodnunk kell a helyi hálózaton belül mozgó csomagok akadálymentes továbbításáról. A szabályokat elõször három nagyobb osztályba kell sorolnunk: az összes szabadon forgalmazó felület, a publikus kimenõ és a publikus bejövõ felület csoportjába. A publikus felületekhez tartozó csoportokban úgy kell rendeznünk a szabályokat, hogy elõre kerüljenek a gyakrabban használtak és hátra a kevésbé használtak, valamint a csoportok utolsó szabálya blokkoljon és naplózzon minden csomagot az adott felületen és irányban. A következõ szabályrendszerben szereplõ, a kimenõ kapcsolatokat tartalmazó csoport csak olyan allow típusú szabályokat tartalmaz, amelyek szûrési feltételei egyértelmûen azonosítják az interneten elérhetõ szolgáltatásokat. Az összes szabályban megjelennek a proto, port, in/out, via és keep state opciók. A proto tcp szabályokban emellett szerepel még egy setup opció is, amellyel a kapcsolatokat kezdeményezõ csomagokat tudjuk azonosítani és felvenni az állapottartásért felelõs dinamikus szabályok közé. A bejövõ felülettel foglalkozó csoport elsõsorban a kéretlen csomagokat igyekszik blokkolni, aminek két oka is van. Elõször is a blokkolt csomagról elképzelhetõ, hogy egyébként érvényes és valamelyik késõbbi szabály fogja hitelesíteni. Másodszor ezekkel a szabályokkal olyan szabálytalan idõközönként érkezõ csomagokat tudunk eldobni, amelyeket nem akarunk a naplóban feljegyezni, és ennek segítségével távoltartjuk az utolsó, mindent blokkoló és naplózó szabálytól. A csoport utolsó szabálya dobja el és naplózza a hozzá befutó összes csomagot, illetve ezen keresztül rögzíthetünk olyan jogi bizonyítékot, amellyel hivatalosan fel tudunk lépni a rendszerünket támadó emberek ellen. Amit még nem szabad elfelejtenünk: a tûzfal az eldobott csomagokra egyáltalán nem válaszol, egyszerûen csak eltûnnek, mintha sosem lettek volna. Ennek köszönhetõen a támadóknak fogalma sem lesz arról, hogy a csomagjaik elérték-e a rendszerünket. Minél kevesebbet tudnak a támadók a rendszerünkrõl, annál biztonságosabb. Amikor ismeretlen portokra érkezõ csomagokat naplózunk, érdemes az /etc/services/ állományban vagy címen (angolul) utánanézni a porthoz tartozó szolgáltatásnak. A különbözõ trójai programok által portok számai ezen a linken érhetõek el (angolul): . Példa egy inkluzív szabályrendszerre A most következõ, címfordítást nem tartalmazó szabályrendszer teljesen inkluzív típusú. Ha ezt használjuk, nem járunk rosszul. Egyszerûen csak annyit kell tennünk, hogy megjegyzésbe tesszük az olyan szolgáltatásokra vonatkozó szabályokat, amelyeket nem akarunk engedélyezni. Amikor pedig olyan üzenetek jelennek meg a naplóban, amelyeket nem akarunk tovább látni, a bejövõ kapcsolatokhoz vegyünk fel egy deny típusú szabályt hozzájuk. Minden szabályban cseréljük ki a dc0 felületet arra a hálózati kártyára, amely közvetlenül csatlakoztatja rendszerünket az internethez. A felhasználói PPP esetében ez a tun0. A szabályok használatában felfedezhetünk egyfajta rendszerszerûséget: Mindegyik sorban, ahol az internet felé nyitunk meg egy kapcsolatot, a opciót használjuk. Az internetrõl az összes hitelesített szolgáltatás elérése tartalmazza a opciót az elárasztások kivédése miatt. Az összes szabályban az vagy az paraméterrel megadjuk szûrni kívánt forgalom irányát. Az összes szabályban szerepel a paraméterrel a csomagokat továbbító felület neve. Az alábbi szabályokat tegyük az /etc/ipfw.rules állományba. ############## Itt kezdõdnek az IPFW szabályai ########################## # Kezdés elõtt töröljük az összes aktív szabályt. ipfw -q -f flush # Állítsuk be a parancsok további szükséges opciót. cmd="ipfw -q add" pif="dc0" # az internethez csatlakozó # felület neve ################################################################# # A belsõ hálózat számára ne korlátozzunk semmit se. # Ha nincs helyi hálózatunk, akkor erre nincs szükségünk. # Az 'xl0' nevét írjuk át a helyi hálózatra csatlakozó # felület nevére. ################################################################ #$cmd 00005 allow all from any to any via xl0 ################################################################ # A rendszer belsõ felületét se szûrjük. ################################################################ $cmd 00010 allow all from any to any via lo0 ################################################################ # A csomagot engedjük át a tûzfalon, ha korábban már felvettünk # hozzá egy dinamikus szabályt a keep-state opcióval. ################################################################ $cmd 00015 check-state ################################################################ # Az internet felé forgalmazó felület (kimenõ kapcsolatok) # A saját hálózatunkról belülrõl vagy errõl az átjáróról # kezdeményezett kapcsolatokat vizsgáljuk az internet felé. ################################################################ # Kifelé engedélyezzük az internet-szolgáltatónk névszerverének # elérését. Az x.x.x.x a szolgáltatónk névszerverének IP-címe # legyen. Ha a szolgáltatónak több névszervere is van, akkor # másoljuk le ezeket a sorokat és az /etc/resolv.conf # állományban található IP-címeket helyettesítsük be. $cmd 00110 allow tcp from any to x.x.x.x 53 out via $pif setup keep-state $cmd 00111 allow udp from any to x.x.x.x 53 out via $pif keep-state # Kábel/DSL konfigurációk esetében kifelé engedélyezzük a # szolgáltatónk DHCP szerverének elérését. Ha a "felhasználói # PPP"-t használjuk, akkor erre nem lesz szükségünk, az egész # csoportot törölhetjük. Az alábbi szabállyal csíphetjük el a # beírandó IP-címet. Ha a naplóban megtaláltuk, akkor vegyük # ki az elsõ szabályt, a másodikba írjuk bele a címet és # engedélyezzük. $cmd 00120 allow log udp from any to any 67 out via $pif keep-state #$cmd 00120 allow udp from any to x.x.x.x 67 out via $pif keep-state # Kifelé engedélyezzük a szabvány nem biztonságos WWW # funkció elérését. $cmd 00200 allow tcp from any to any 80 out via $pif setup keep-state # Kifelé engedélyezzük a biztonságos HTTPS funkció # elérését TLS SSL használatával. $cmd 00220 allow tcp from any to any 443 out via $pif setup keep-state # Kifelé engedélyezzük a e-mailek küldését és fogadását. $cmd 00230 allow tcp from any to any 25 out via $pif setup keep-state $cmd 00231 allow tcp from any to any 110 out via $pif setup keep-state # Kifelé engedélyezzük a FreeBSD (a make install és a CVSUP) # funkcióit. Ezzel lényegében a rendszeradminisztrátornak # ,,ISTENI'' jogokat adunk. $cmd 00240 allow tcp from me to any out via $pif setup keep-state uid root # Kifelé engedélyezzük a pinget. $cmd 00250 allow icmp from any to any out via $pif keep-state # Kifelé engedélyezzük az idõ szolgáltatást. $cmd 00260 allow tcp from any to any 37 out via $pif setup keep-state # Kifelé engedélyezzük az nntp news szolgáltatást # (vagyis a hírcsoportokat) $cmd 00270 allow tcp from any to any 119 out via $pif setup keep-state # Kifelé engedélyezzük a biztonságos FTP, telnet és SCP # elérését az SSH (secure shell) használatával. $cmd 00280 allow tcp from any to any 22 out via $pif setup keep-state # Kifelé engedélyezzük a whois szolgáltatást. $cmd 00290 allow tcp from any to any 43 out via $pif setup keep-state # Dobjuk el és naplózzunk mindent, ami megpróbál kijutni. # Ez a szabály gondoskodik róla, hogy alapértelmezés szerint # mindent blokkoljunk. $cmd 00299 deny log all from any to any out via $pif ################################################################ # Az internet felõli felület (bejövõ kapcsolatok) # A saját hálózatunk felé vagy erre az átjáróra # nyitott kapcsolatokat vizsgáljuk az internet felõl. ################################################################ # Blokkoljunk minden olyan bejövõ forgalmat, amely a fenntartott # címtartományok felé tart. $cmd 00300 deny all from 192.168.0.0/16 to any in via $pif #RFC 1918: privát IP $cmd 00301 deny all from 172.16.0.0/12 to any in via $pif #RFC 1918: privát IP $cmd 00302 deny all from 10.0.0.0/8 to any in via $pif #RFC 1918: privát IP $cmd 00303 deny all from 127.0.0.0/8 to any in via $pif #helyi $cmd 00304 deny all from 0.0.0.0/8 to any in via $pif #helyi $cmd 00305 deny all from 169.254.0.0/16 to any in via $pif #DHCP $cmd 00306 deny all from 192.0.2.0/24 to any in via $pif #dokumentációs célokra fenntartott $cmd 00307 deny all from 204.152.64.0/23 to any in via $pif #Sun klaszterek összekötésére használt $cmd 00308 deny all from 224.0.0.0/3 to any in via $pif #D és E osztályú multicast # A nyilvános pingek tiltása. $cmd 00310 deny icmp from any to any in via $pif # Az ident szolgáltatás tiltása. $cmd 00315 deny tcp from any to any 113 in via $pif # Blokkoljuk az összes Netbios szolgáltatást: 137=név, 138=datagram, # 139=session. A Netbios az MS Windows megosztását implementálja. # Blokkoljuk az MS Windows hosts2 névszerver kéréseit is a 81-es # porton. $cmd 00320 deny tcp from any to any 137 in via $pif $cmd 00321 deny tcp from any to any 138 in via $pif $cmd 00322 deny tcp from any to any 139 in via $pif $cmd 00323 deny tcp from any to any 81 in via $pif # Eldobjuk az összes késõn érkezõ csomagot. $cmd 00330 deny all from any to any frag in via $pif # Eldobjuk azokat az ACK csomagokat, amelyek egyik dinamikus # szabálynak sem felelnek meg. $cmd 00332 deny tcp from any to any established in via $pif # Befelé engedélyezzük a szolgáltató DHCP szerverének válaszát. Ebben # a szabályban csak a DHCP szerver IP-címe szerepelhet, mivel ez az # egyetlen olyan hitelesített forrás, ami ilyen csomagokat küldhet. # Ez csak a kábeles és DSL típusú kapcsolatok esetében szükséges. # Amikor a "felhasználói PPP"-vel csatlakozunk az internethez, nem # kell ez a szabály. Ugyanazt az IP-címet kell megadnunk, amelyet a # kimenõ kapcsolatoknál is. #$cmd 00360 allow udp from any to x.x.x.x 67 in via $pif keep-state # Befelé engedélyezzük a szabvány WWW funkciót, mivel webszerverünk # is van. $cmd 00400 allow tcp from any to me 80 in via $pif setup limit src-addr 2 # Befelé engedélyezzük a biztonságos FTP, telnet és SCP # típusú kapcsolatokat az internetrõl. $cmd 00410 allow tcp from any to me 22 in via $pif setup limit src-addr 2 # Befelé engedélyezzük az internetrõl érkezõ nem biztonságos telnet # kapcsolatokat. Azért tekintjük nem biztonságosnak, mert az # azonosítók és a jelszavak az interneten titkosítatlanul vándorolnak. # Töröljük ezt a csoportot, ha nincs telnet szolgáltatásunk. $cmd 00420 allow tcp from any to me 23 in via $pif setup limit src-addr 2 # Dobjuk el és naplózzuk az összes többi kintrõl érkezõ csomagot. $cmd 00499 deny log all from any to any in via $pif # Alapértelmezés szerint dobjuk el mindent. Az ide érkezõ # csomagokat is naplózzuk, amibõl többet is ki tudunk majd # deríteni. $cmd 00999 deny log all from any to any ############# Itt fejezõdnek be az IPFW szabályai ##################### Példa hálózati címfordításra és állapottartásra címfordítás és az IPFW Az IPFW címfordító funkciójának kihasználásához további konfigurációs beállítások alkalmazására is szükségünk lesz. A rendszermagban opció között meg kell adnunk az option IPDIVERT sort a többi IPFIREWALL sor mellett, és fordítanunk egy saját verziót. Emellett még az /etc/rc.conf állományban is engedélyezni kell az IPFW alapvetõ funkcióit. natd_enable="YES" # engedélyezzük a címfordításért felelõs démont natd_interface="rl0" # az internet felé mutató hálózati kártya neve natd_flags="-dynamic -m" # -m = a portszámok megtartása, ha lehetséges Az állapottartó szabályok használata a divert natd címfordítási opcióval együtt nagyban növeli a szabályrendszer leprogramozásának bonyolultságát. A check-state és divert natd szabályok helye kritikus a megfelelõ mûködés tekintetében. Az eddig megszokott egyszerû viselkedés itt már nem érvényesül. Bevezetünk egy új cselekvést is, amelynek a neve skipto. A skipto parancs használatához elengedhetetlen a szabályok sorszámozása, mivel pontosan tudnunk kell, hogy a skipto hatására hova kell ugrania a vezérlésnek. A következõ példában nem fogunk sok megjegyzést látni, mivel benne az egyik lehetséges programozási stílust próbáljuk érzékeltetni és a csomagok szabályrendszerek közti áramlását magyarázzuk. A feldolgozás a szabályokat tartalmazó állomány tetején található elsõ szabállyal kezdõdik, és innen egyesével pereg végig lefelé a feldolgozás egészen addig, amíg a csomag a szûrési feltételek valamelyikének eleget nem tesz és távozik a tûzfalból. Leginkább a 100-as, 101-es, 450-es, 500-as és 510-es sorszámú szabályokat emelnénk ki. Ezek vezérlik kimenõ és bejövõ csomagok fordítását, ezért a hozzájuk tartozó dinamikus állapottartó bejegyzések mindig a helyi hálózat IP-címeire hivatkoznak. Amit még érdemes megfigyelnünk, hogy az összes áteresztõ és eldobó szabályban szerepel a csomag haladási iránya (tehát kimenõ vagy éppen bejövõ) és az érintett felület megnevezése. Emellett azt is vegyük észre, hogy az összes kifelé irányuló kapcsolatlétrehozási kérés az 500-as sorszámú szabályhoz fog ugrani a címfordítás elvégzéséhez. Tegyük fel, hogy a helyi hálózatunkon levõ felhasználók szeretnek honlapokat nézgetni az interneten. A honlapok a 80-as porton keresztül kommunikálnak. Tehát amikor egy ilyen csomag eléri a tûzfalat, nem fog illeszkedni a 100-as szabályra, mert a fejléce szerint kifelé halad és nem befelé. A 101-es szabályon is átlép, mivel ez az elsõ csomag, így a dinamikus állapottartó táblázatban sem szerepel még. A csomag végül a 125-ös szabályra fog illeszkedni: kifelé halad az internetre csatlakozó hálózati kártyán. A csomagban azonban még mindig az eredeti forrás IP-címe található, amely a helyi hálózat egyik gépére hivatkozik. A szabály illeszkedésekor két cselekvés is végbemegy. A opció hatására ez a szabály felveszi ezt a kapcsolatot az állapottartó dinamikus szabályok közé és végrehajtja a másik megadott feladatot. Ez a feladat része a dinamikus táblázatba rögzített bejegyzésnek, ami ebben az esetben a skipto 500 (ugorjunk az 500-as szabályra) lesz. Az 500-as szabály a továbbküldés elõtt lefordítja a csomag forrás IP-címét. Ezt ne felejtsük el, nagyon fontos! A csomag ezután eljut a céljához, és visszatérve ismét belép a szabályrendszer tetején. Ezúttal illeszkedni fog a 100-as szabályra és a cél IP-címét visszafordítjuk a helyi hálózatunk megfelelõ gépének címére. Ezután a check-state szabályhoz kerül, amely megtalálja a dinamikus szabályok között és továbbengedi a belsõ hálózatra. Ezzel visszakerül a küldõ géphez, amely egy újabb csomagot küld egy újabb adatszeletet kérve a távoli szervertõl. Ekkor már a check-state szabály megtalálja a hozzátartozó bejegyzést a dinamikus szabályok között és végrehajtódik a korábban letárolt skipto 500 mûvelet. A csomag erre az 500-as szabályra ugrik, ahol lefordítjuk a címét és továbbküldjük. Az bejövõ oldalon minden, ami egy korábban kialakult kapcsolat részeként érkezik, automatikusan a check-state és a megfelelõ helyre rakott divert natd szabályok által dolgozódik fel. Itt mindössze a rossz csomagok eldobásával és a hitelesített szolgáltatások elérésének biztosításával kell foglalkoznunk. Például a tûzfalon egy webszerver fut, és azt szeretnénk, hogy az internetrõl képesek legyenek elérni a rajta levõ oldalakat. Az újonnan beérkezõ kapcsolatépítési kérelem a 100-as szabályra fog illeszkedni, amelynek a cél IP-címét a tûzfal helyi hálózaton található címére fogjuk leképezni. A csomagot ezután még megvizsgáljuk, nem tartalmaz-e valamilyen huncutságot, majd végül a 425-ös szabálynál fog kikötni. Az egyezéskor két dolog történhet: a csomaghoz felveszünk egy dinamikus szabályt, de ezúttal az adott forrás IP-címrõl érkezõ kapcsolatkérések számát 2-re lekorlátozzuk. Ezzel az adott szolgáltatás portján meg tudjuk óvni a tûzfalat üzemeltetõ gépet a DoS típusú támadásoktól. A csomagot ezután hozzátartozó cselekvés szerint továbbengedjük a belsõ hálózat felé. Visszatéréskor a tûzfal felismeri, hogy a csomag egy már meglevõ kapcsolathoz tartozik, ezért közvetlenül az 500-as szabályhoz kerül címfordításra, majd a kimenõ felületen keresztül továbbküldjük. Íme az elsõ példa egy ilyen szabályrendszerre: #!/bin/sh cmd="ipfw -q add" skip="skipto 500" pif=rl0 ks="keep-state" good_tcpo="22,25,37,43,53,80,443,110,119" ipfw -q -f flush $cmd 002 allow all from any to any via xl0 # nem szûrjük a belsõ hálózatot $cmd 003 allow all from any to any via lo0 # nem szûrjük a helyi felületet $cmd 100 divert natd ip from any to any in via $pif $cmd 101 check-state # A kimenõ csomagok hitelesítése: $cmd 120 $skip udp from any to xx.168.240.2 53 out via $pif $ks $cmd 121 $skip udp from any to xx.168.240.5 53 out via $pif $ks $cmd 125 $skip tcp from any to any $good_tcpo out via $pif setup $ks $cmd 130 $skip icmp from any to any out via $pif $ks $cmd 135 $skip udp from any to any 123 out via $pif $ks # Az összes olyan csomagot eldobjuk, amely a fenntartott # címtartományokba tart: $cmd 300 deny all from 192.168.0.0/16 to any in via $pif #RFC 1918: privát IP $cmd 301 deny all from 172.16.0.0/12 to any in via $pif #RFC 1918: privát IP $cmd 302 deny all from 10.0.0.0/8 to any in via $pif #RFC 1918: privát IP $cmd 303 deny all from 127.0.0.0/8 to any in via $pif #helyi $cmd 304 deny all from 0.0.0.0/8 to any in via $pif #helyi $cmd 305 deny all from 169.254.0.0/16 to any in via $pif #DHCP $cmd 306 deny all from 192.0.2.0/24 to any in via $pif #dokumentációs célokra fenntartott $cmd 307 deny all from 204.152.64.0/23 to any in via $pif #Sun klaszter $cmd 308 deny all from 224.0.0.0/3 to any in via $pif #D és E osztályú multicast # Az érkezõ csomagok hitelesítése: $cmd 400 allow udp from xx.70.207.54 to any 68 in $ks $cmd 420 allow tcp from any to me 80 in via $pif setup limit src-addr 1 $cmd 450 deny log ip from any to any # Ide ugrunk a kimenõ állapottartó szabályoknál: $cmd 500 divert natd ip from any to any out via $pif $cmd 510 allow ip from any to any ##################### a szabályok vége ################## A következõ példa teljesen megegyezik az elõzõvel, azonban itt már dokumentációs szándékkal szerepelnek megjegyzések is, melyek a tapasztalatlan IPFW szabályíróknak segítik jobban megérteni a szabályok pontos mûködését. A második példa: #!/bin/sh ############# Az IPFW szabályai itt kezdõdnek ########################### # Kezdés elõtt töröljük az összes jelenleg aktív szabályt: ipfw -q -f flush # Beállítjuk a parancsok megfelelõ elõtagjait: cmd="ipfw -q add" skip="skipto 800" pif="rl0" # az internethez csatlakozó # hálózati felület neve ################################################################# # A belsõ hálózat számára ne korlátozzunk semmit se. # Ha nincs helyi hálózatunk, akkor erre nincs szükségünk. # Az 'xl0' nevét írjuk át a helyi hálózatra csatlakozó # felület nevére. ################################################################# $cmd 005 allow all from any to any via xl0 ################################################################# # A rendszer belsõ felületét se szûrjük. ################################################################# $cmd 010 allow all from any to any via lo0 ################################################################# # Ellenõrizzük, hogy ez egy beérkezõ csomag és ha igen, akkor # fordítsuk a címét. ################################################################# $cmd 014 divert natd ip from any to any in via $pif ################################################################# # Ha ehhez a csomaghoz korábban már vettük fel dinamikus # szabályt a keep-state opció révén, akkor engedjük tovább. ################################################################# $cmd 015 check-state ################################################################# # Az internet felé forgalmazó felület (kimenõ kapcsolatok) # A saját hálózatunkról belülrõl vagy errõl az átjáróról # kezdeményezett kapcsolatokat vizsgáljuk az internet felé. ################################################################# # Kifelé engedélyezzük az internet-szolgáltatónk névszerverének # elérését. Az x.x.x.x a szolgáltató névszerverének IP-címe # lesz. Ha a szolgáltatónknak több névszervere is van, akkor # az /etc/resolv.conf állományból nézzük ki a címeiket és # másoljuk le az alábbi sor mindegyikükhöz. $cmd 020 $skip tcp from any to x.x.x.x 53 out via $pif setup keep-state # A kábeles és DSL kapcsolatok esetén engedélyezzük a szolgáltató # DHCP szerverének elérését. $cmd 030 $skip udp from any to x.x.x.x 67 out via $pif keep-state # Kifelé engedélyezzük a szabvány nem biztonságos WWW funkciót $cmd 040 $skip tcp from any to any 80 out via $pif setup keep-state # Kifelé engedélyezzük a biztonságos HTTPS funkciót a TLS SSL # használatával. $cmd 050 $skip tcp from any to any 443 out via $pif setup keep-state # Kifelé engedélyezzük az e-mailek küldését és fogadását. $cmd 060 $skip tcp from any to any 25 out via $pif setup keep-state $cmd 061 $skip tcp from any to any 110 out via $pif setup keep-state # Kifelé engedélyezzük a FreeBSD (make install és CVSUP) funkcióit. # Ezzel a rendszeradminisztrátornak ,,ISTENI'' jogokat adunk. $cmd 070 $skip tcp from me to any out via $pif setup keep-state uid root # Kifelé engedélyezzük a pinget. $cmd 080 $skip icmp from any to any out via $pif keep-state # Kifelé engedélyezzük az idõ szolgáltatást. $cmd 090 $skip tcp from any to any 37 out via $pif setup keep-state # Kifelé engedélyezzük az nntp news szolgáltatást (tehát a # hírcsoportokat). $cmd 100 $skip tcp from any to any 119 out via $pif setup keep-state # Kifelé engedélyezzük a biztonságos FTP, telnet és SCP # funkciókat az SSH (secure shell) használatával. $cmd 110 $skip tcp from any to any 22 out via $pif setup keep-state # Kifelé engedélyezzük ki a whois kéréseket. $cmd 120 $skip tcp from any to any 43 out via $pif setup keep-state # Kifelé engedélyezzük az NTP idõszerver elérését. $cmd 130 $skip udp from any to any 123 out via $pif keep-state ################################################################# # Az internet felõli felület (bejövõ kapcsolatok) # A saját hálózatunk felé vagy erre az átjáróra # nyitott kapcsolatokat vizsgáljuk az internet felõl. ################################################################# # Tiltsuk a fenntartott címtartományok felé haladó összes beérkezõ # forgalmat. $cmd 300 deny all from 192.168.0.0/16 to any in via $pif #RFC 1918: privát IP $cmd 301 deny all from 172.16.0.0/12 to any in via $pif #RFC 1918: privát IP $cmd 302 deny all from 10.0.0.0/8 to any in via $pif #RFC 1918: privát IP $cmd 303 deny all from 127.0.0.0/8 to any in via $pif #helyi $cmd 304 deny all from 0.0.0.0/8 to any in via $pif #helyi $cmd 305 deny all from 169.254.0.0/16 to any in via $pif #DHCP $cmd 306 deny all from 192.0.2.0/24 to any in via $pif #dokumentációs célokra fenntartott $cmd 307 deny all from 204.152.64.0/23 to any in via $pif #Sun klaszter $cmd 308 deny all from 224.0.0.0/3 to any in via $pif #D és E osztályú multicast # Az ident tiltása. $cmd 315 deny tcp from any to any 113 in via $pif # Blokkoljuk az összes Netbios szolgáltatást: 137=név, 138=datagram, # 139=session. A Netbios az MS Windows megosztását implementálja. # Blokkoljuk az MS Windows hosts2 névszerver kéréseit is a 81-es # porton. $cmd 320 deny tcp from any to any 137 in via $pif $cmd 321 deny tcp from any to any 138 in via $pif $cmd 322 deny tcp from any to any 139 in via $pif $cmd 323 deny tcp from any to any 81 in via $pif # Dobjuk el a késõn érkezõ csomagokat. $cmd 330 deny all from any to any frag in via $pif # Dobjuk el azokat az ACK csomagokat, amelyekre nincs # dinamikus szabály. $cmd 332 deny tcp from any to any established in via $pif # Engedélyezzük a szolgáltató DHCP szerverétõl érkezõ forgalmat. Ennek # a szabálynak tartalmaznia kell a DHCP szerver címét, mert csak tõle # fogadunk el ilyen típusú csomagokat. Egyedül csak kábeles vagy DSL # konfigurációk esetén használatos, a "felhasználói PPP" esetében # törölhetjük. Ez ugyanaz az IP-cím, amelyet a kimenõ kapcsolatoknál # megadtunk. $cmd 360 allow udp from x.x.x.x to any 68 in via $pif keep-state # Befelé engedélyezzük a szabvány WWW funkciót, mivel van # webszerverünk. $cmd 370 allow tcp from any to me 80 in via $pif setup limit src-addr 2 # Befelé engedélyezzük a biztonságos FTP, telnet és SCP # használatát az internetrõl. $cmd 380 allow tcp from any to me 22 in via $pif setup limit src-addr 2 # Befelé engedélyezzük a nem biztonságos telnet elérését az # internetrõl. Azért nem tekintjük biztonságosnak, mert az # azonosítókat és a jelszavakat az interneten titkosítatlanul # közvetíti. Ha nincs telnet szolgáltatásunk, akkor törölhetjük is ezt # a csoportot. $cmd 390 allow tcp from any to me 23 in via $pif setup limit src-addr 2 # Dobjuk el és naplózzuk az összes internetrõl érkezõ hitelesítetlen kapcsolatot. $cmd 400 deny log all from any to any in via $pif # Dobjuk el és naplózzuk az összes internetre menõ hitelesítetlen kapcsolatot. $cmd 450 deny log all from any to any out via $pif # Ez lesz a kimenõ szabályokhoz tartozó "skipto" célja. $cmd 800 divert natd ip from any to any out via $pif $cmd 801 allow ip from any to any # Minden mást alapértelmezés szerint tiltunk és naplózunk. $cmd 999 deny log all from any to any ############# Az IPFW szabályai itt fejezõdnek be ##################### diff --git a/hu_HU.ISO8859-2/books/handbook/geom/chapter.sgml b/hu_HU.ISO8859-2/books/handbook/geom/chapter.sgml index e3de4dc528..2b796d79c3 100644 --- a/hu_HU.ISO8859-2/books/handbook/geom/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/geom/chapter.sgml @@ -1,891 +1,891 @@ Tom Rhodes Írta: GEOM: A moduláris lemezszervezõ rendszer Áttekintés GEOM A GEOM lemezrendszer GEOM Ez a fejezet a &os;-ben található GEOM rendszert mutatja be. Ez a rendszer tömöríti az általa is alkalmazott fontosabb RAID-vezérlõ segédprogramokat. A fejezet nem részletezi, hogy a GEOM konkrétan milyen módon kezeli és vezérli az I/O-t, ahogy azt sem, hogyan mûködik az alapjául szolgáló alrendszer vagy hogy néz ki annak forráskódja. Az ilyen jellegû információk a &man.geom.4; man oldalon, valamint az ott felsorolt helyeken találhatóak meg. Továbbá, ez a fejezet magukról a RAID-konfigurációkról sem ad pontos tájékoztatást. Kizárólag csak a GEOM által is támogatott RAID-besorolásokról esik szó. A fejezet elolvasása során megismerjük: a GEOM segítségével milyen fajtájú RAID támogatást érhetünk el; hogyan kell használni a rendszer által nyújtott alapvetõ segédeszközöket a különféle RAID-szintek konfigurálásához, karbantartásához és kezeléséhez; hogyan kell a GEOM-on keresztül tükrözni, csíkozni, titkosítani és távolról összekapcsolni lemezes eszközöket; hogyan kell a GEOM rendszerben összekapcsolt lemezeknél felmerülõ hibákat felderíteni. A fejezet elolvasásához ajánlott: megérteni, hogyan kezeli a &os; a lemezes eszközöket (); ismerni, hogyan konfiguráljunk és telepítsünk egy új &os; rendszermagot (). A GEOM bemutatása A GEOM rendszer adatszolgáltatókon vagy speciális /dev-állományokon + class="directory">/dev-állományokon keresztül hozzáférést és vezérlést tesz lehetõvé bizonyos osztályokhoz — Master Boot Recordokhoz, BSD-címkékhez stb. Számos szoftveres RAID konfiguráció támogatásával a GEOM transzparens elérést tesz lehetõvé mind az operációs rendszer, mind pedig az általa felkínált segédprogramok számára. Tom Rhodes Írta: Murray Stokely RAID0 - Csíkozás GEOM Lemezcsíkozás A csíkozás módszerét használjuk abban az esetben, amikor több lemezmeghajtót akarunk egyetlen kötetté összevonni. A GEOM lemezalrendszer szoftveres támogatást nyújt a RAID0, más néven a lemezcsíkozás megvalósításához. Egy RAID0 rendszerben az adatokat blokkokra bontva írjuk fel a tömbben található lemezek között szétosztva. Így ahelyett, hogy meg kellene várnunk 256 kb-nyi adat egyetlen lemezre írását, egy RAID0 rendszerben egyszerre íródik 64 kb-nyi adat négy különbözõ lemezre, és ezáltal gyorsabb elérést szolgáltat. Ez a gyorsaság további lemezvezérlõk használatával még jobban fokozható. Az egy RAID0-csíkozásban résztvevõ lemezek mindegyikének azonos méretûnek kell lennie, mivel az írásra és olvasásra irányuló I/O-kérések a párhuzamos kiszolgálás érdekében összefésülõdnek. Példa lemezcsíkozásra Csíkozás kialakítása formázatlan ATA-lemezekkel Töltsük be a geom_stripe modult: &prompt.root; kldload geom_stripe Bizonyosodjuk meg róla, hogy a rendszerünkben található egy szabad csatlakozási pont. Ha majd ezt a kötetet szánjuk rendszerünk gyökérpartíciójának, használjunk erre a célra egy másik könyvtárat, például a /mnt-ot: + class="directory">/mnt-ot: &prompt.root; mkdir /mnt Keressük meg a csíkozásra felhasználni kívánt lemezek eszközneveit, és hozzunk létre belõlük egy új csíkozott eszközt. Például, ha két használatban nem levõ, particionálatlan ATA-lemezt, név szerint a /dev/ad2 és /dev/ad3 eszközöket akarjunk csíkozni: &prompt.root; gstripe label -v st0 /dev/ad2 /dev/ad3 Az így létrejött új köteten most hozzunk létre egy általános címkét, vagy más néven egy partíciós táblát, és telepítsük fel rá a rendszer alapértelmezett rendszerindító programját: &prompt.root; bsdlabel -wB /dev/stripe/st0 Ezzel meg kellett jelennie további másik két eszköznek is a /dev/stripe + class="directory">/dev/stripe könyvtárban, a st0 eszköz mellett. Ezek többek közt az st0a és az st0c. Itt már ki is tudunk alakítani egy állományrendszert az st0a eszközön a newfs használatával: &prompt.root; newfs -U /dev/stripe/st0a Sok-sok számot fogunk látni cikázni a képernyõn, majd néhány másodperc múlva befejezõdik a folyamat. Létrehoztuk a kötetet, ami most már készen áll a becsatolásra. A kialakított lemezcsíkozást így tudjuk kézzel csatlakoztatni: &prompt.root; mount /dev/stripe/st0a /mnt A csíkozott állományrendszert a rendszerindítás folyamán automatikusan becsatlakoztathatjuk, ha elhelyezzük az alábbi kötetinformációkat az /etc/fstab állományba: &prompt.root; echo "/dev/stripe/st0a /mnt ufs rw 2 2" \ >> /etc/fstab A geom_stripe modult is automatikusan be kell tölteni a rendszerindítás során. Ehhez a következõ sort kell hozzáadni a /boot/loader.conf állományhoz: &prompt.root; echo 'geom_stripe_load="YES"' >> /boot/loader.conf RAID1 - Tükrözés GEOM lemeztükrözés A tükrözés számos vállalatnál és háztartásban alkalmazott technológia, amely az adatok megszakítás nélküli lementésére használatos. Amikor tükrözést használunk, az egyszerûen csak arra utal, hogy a B lemez ugyanazokat az adatokat tartalmazza, mint az A lemez. Vagy amikor a C és D lemez tartalma egyezik meg az A és B lemezekével. Függetlenül a lemezek kiosztásától, itt az a lényeg, hogy az egyik lemez teljes területe vagy az egyik partíciója le van másolva. Késõbb az ezen a módon lementett adatok könnyen visszaállíthatóak anélkül, hogy ez a szolgáltatásban vagy az elérhetõségben bármilyen kimaradást okozna, és akár még fizikailag is biztonságosan tárolhatóak. Elõször is szereznünk kell két egyforma méretû lemezt, valamint ez a példa feltételezi, hogy ezek a lemezek közvetlen elérésû (&man.da.4;) SCSI-lemezek. Kezdetnek telepítsük fel a &os;-t az elsõ lemezre, de csak két partícióval. Ezek egyike legyen a lapozóállományt tartalmazó partíció, aminek mérete pedig a fizikailag rendelkezésre álló memória (RAM) méretének kétszere legyen. A többi helyet adjuk oda a gyökérpartíciónak (/). Természetesen a többi + class="directory">/). Természetesen a többi csatolási pontot is kihasználhatjuk, külön partíciókkal, de ezzel a feladat nehézsége tízszeresére növekszik, mivel ekkor manuálisan kell átírnunk a &man.bsdlabel.8; és &man.fdisk.8; beállításokat. Indítsuk újra a számítógépet és várjuk meg, amíg a rendszer teljesen készen nem áll. Amint ez a folyamat véget ért, jelentkezzük be a root felhasználóval. Hozzuk létre a /dev/mirror/gm eszközt és kössük hozzá a /dev/ad1 eszközhöz: &prompt.root; gmirror label -vnb round-robin gm0 /dev/da1 A rendszernek erre így kell reagálnia: Metadata value stored on /dev/da1. Done. Keltsük életre a GEOM-ot, aminek során betöltõdik a /boot/kernel/geom_mirror.ko modul: &prompt.root; gmirror load Ezzel a paranccsal létre kellett jönnie a gm0 eszköznek a /dev/mirror + class="directory">/dev/mirror könyvtárban. Helyezzünk el egy partíciós táblát és rendszerindító programot az fdisk segítségével az újonnan létrehozott gm0 eszközön: &prompt.root; fdisk -vBI /dev/mirror/gm0 Most pedig tegyünk fel egy általános címkét a bsdlabel programmal: &prompt.root; bsdlabel -wB /dev/mirror/gm0s1 Ha több slice-unk és partíciónk is van, az iménti két parancsban máshogy kell megadnunk a paramétereket. Meg kell egyezniük a másik lemezen található slice-al és a partíciójának méretével. Használjuk a &man.newfs.8; segédprogramot a gm0s1a eszközön egy UFS típusú állományrendszer létesítésére: &prompt.root; newfs -U /dev/mirror/gm0s1a Ennek eredményeképpen kapunk egy halom számot a képernyõn. Nagyon jó! Ellenõrizzük, nem látunk-e a képernyõn valamilyen hibaüzenetet, majd csatlakoztassuk az eszközt a a /mnt pontra: + class="directory">/mnt pontra: &prompt.root; mount /dev/mirror/gm0s1a /mnt Ezt követõen pedig mozgassunk át minden adatot a frissen létrehozott állományrendszere arról a lemezrõl, ahonnan elindítottuk a rendszert. Ebben a példában ezt ugyan a &man.dump.8; és &man.restore.8; parancsokkal oldjuk meg, erre a célra viszont a &man.dd.1; is remekül használható. &prompt.root; dump -L -0 -f- / |(cd /mnt && restore -r -v -f-) Ezt el kell végeznünk mindegyik állományrendszerre. Egyszerûen másoljuk be az érintett állományrendszert a megfelelõ helyre az elõbb bemutatott parancsban. Ezután írjuk át a duplikált /mnt/etc/fstab állományt, és távolítsuk el vagy csak kommentezzük ki belõle a lapozóállományt Megjegyezzük, hogy az fstab állományból kiszedett bejegyzés miatt valószínûleg más módon kell majd engedélyeznünk a lapozóállomány használatát. Errõl bõvebben lásd a . . Írjuk felül a másik állományrendszer adatait is az új eszköznek megfelelõ beállításokkal, ahogy a példa is mutatja: # Device Mountpoint FStype Options Dump Pass# #/dev/da0s2b none swap sw 0 0 /dev/mirror/gm0s1a / ufs rw 1 1 Az alábbi paranccsal gondoskodjunk róla, hogy a geom_mirror.ko modul betöltõdjön a rendszerindítás során: &prompt.root; echo 'geom_mirror_load="YES"' >> /mnt/boot/loader.conf &prompt.root; echo 'geom_mirror_load="YES"' >> /boot/loader.conf Indítsuk újra a rendszert: &prompt.root; shutdown -r now A rendszerindító képernyõn az egyfelhasználós mód eléréséhez válasszuk a negyedik (4) opciót. A konzol használatával gyõzödjünk meg róla, hogy a rendszer a gm0s1a eszközrõl indult. Ezt a &man.df.1; kimenetébõl deríthetjük ki. Ha minden rendben zajlott, akkor a rendszerünk elindult a gm0s1a eszközrõl, és a login vár minket. Innen a lemez a következõ parancsok kiadásával törölhetõ és illeszhetõbe a tükrözések közé: &prompt.root; dd if=/dev/zero of=/dev/da0 bs=512 count=79 &prompt.root; gmirror configure -a gm0 &prompt.root; gmirror insert gm0 /dev/da0 Az paraméter tudatja a &man.gmirror.8;-al, hogy automatikus szinkronizációt használjon, tehát az lemezre írást magától tükrözze. A hozzátartozó man oldal elmagyarázza, hogyan építsük át a tömböt és hogyan cseréljük benne a lemezeket, habár az data névvel hivatkozik az itt említett gm0 eszközre. A frissen létrehozott tükrözés állapotát az alábbi paranccsal ellenõrizhetjük: &prompt.root; gmirror status Hibakeresés A rendszer nem hajlandó elindulni Ha a rendszerünk ehhez hasonló módon indul: ffs_mountroot: can't find rootvp Root mount failed: 6 mountroot> Indítsuk újra a gépünket a kikapcsoló gomb vagy a reset segítségével. A rendszerindító menüben válasszuk a hatodik opciót (6). Ennek eredményeképpen megkapjuk a &man.loader.8; parancssorát. Töltsük be a modult manuálisan: OK? load geom_mirror OK? boot Ha ez beválik, akkor valamiért a modult nem sikerült rendesen betölteni. Helyezzük el a options GEOM_MIRROR sort a rendszermag konfigurációs állományában, fordítsuk újra és telepítsük. Ezzel várhatóan orvosoltuk a problémát. Eszközök hálózati illesztése a GEOM-ban A GEOM távoli eszközök, például lemezek, CD-meghajtók stb. használatát is támogatja a hálózati illesztést szolgáló segédprogramjaival, hasonlóan az NFS-hez. Kezdésként létre kell hozni a megosztást elõsegítõ állományt. Ez az állomány határozza meg, ki és milyen szinten jogosult használni a megosztott erõforrásokat. Például ha megosztjuk az elsõ SCSI-lemezen a negyedik slice-ot, az alábbi /etc/gg.exports állomány tökéletesen megfelel: 192.168.1.0/24 RW /dev/da0s4d Ezzel a belsõ hálózaton levõ összes számítógép képes lesz elérni a da0s4d partíción található állományrendszert. Az eszköz megosztásához elõször gondoskodnunk kell róla, hogy ne legyen csatlakoztatva, majd ezután indítsuk el a &man.ggated.8; szerver démonját: &prompt.root; ggated Ezt követõen a mount felhasználásával csatoljuk az eszközt a kliensen, az alábbi parancs kiadásával: &prompt.root; ggatec create -o rw 192.168.1.1 /dev/da0s4d ggate0 &prompt.root; mount /dev/ggate0 /mnt Innentõl kezdve az eszköz elérhetõ lesz - a /mnt csatlakozási + a /mnt csatlakozási ponton keresztül. Fontos kiemelnünk, hogy ez a mûvelet eredménytelen, ha az adott eszközt vagy maga a szerver, vagy pedig valamelyik másik kliens már korábban csatolta. Amikor az eszközre már nincs tovább szükségünk, biztonságosan le tudjuk választani az &man.umount.8; paranccsal, hasonlóan bármelyik más lemezes eszközhöz. A lemezes eszközök címkézése GEOM Lemezcímkék A rendszer indítása közben a &os; rendszermagja a talált eszközöknek megfelelõen mindegyiknek létrehoz egy-egy eszközleírót. Ezzel a próbálgatásos módszerrel együtt jár néhány gond, például mi történik akkor, ha az új lemezes eszközt USB-n keresztül adjuk a rendszerhez? Nagyon valószínû, hogy ez az eszköz megkapja a da0 nevet és ezzel az eredeti da0 eszköz eltolódik a da1 névhez. Ennek köszönhetõen az /etc/fstab állományban felsorolt állományrendszerek csatolása veszélybe kerül, aminek következtében akár meghiúsulhat a rendszerindulás is. Az egyik lehetséges megoldása a problémának, ha sorbafûzzük a SCSI eszközeinket, és így a SCSI-kártyához kapcsolt újabb eszköz egy addig nem használt számot fog birtokba venni. Mi helyzet azonban az USB-s eszközökkel, amelyek kiüthetik az elsõdleges SCSI-lemezeinket? Ez egyébként azért történhet meg, mert az USB-s eszközöket általában hamarabb keresi a rendszer, mint a SCSI kártyán levõ eszközöket. Megoldhatjuk úgy ezt a gondot, hogy csak azután csatlakoztatjuk az említett eszközöket, miután a rendszer elindult. Megoldhatjuk viszont úgy is, hogy csak egyetlen ATA-meghajtót használunk és soha nem soroljuk fel a SCSI eszközöket az /etc/fstab állományban. Ezeknél kínálkozik azonban egy jobb megoldás! A glabel nevû segédprogrammal a rendszergazda vagy a felhasználó úgy tudja címkézni a lemezmeghajtókat, hogy azok a /etc/fstab állományban szereplõ címkéket használják. Mivel a glabel a címkét az adott szolgáltató utolsó szektorában tárolja el, ez a címke megmarad az újraindítás után is. Ha ezt a címkét eszközként használjuk, az állományrendszerek mindig ugyanarról a meghajtóról fognak csatolódni, függetlenül attól, hogy milyen eszközleírón keresztül érjük el ezeket. Egyáltalán nem állítottuk, hogy egy címke csak állandó lehet. A glabel segítségével egyaránt létre lehet hozni állandó és átmeneti címkéket, de csak az állandó címke képes az újraindítás után is megmaradni. A két címketípus közti különbségeket a &man.glabel.8; man oldal tárgyalja részletesebben. Címketípusok és példák A címkéknek két típusa létezik, az általános címke és az állományrendszer-címke. A kettõ közötti eltérés az állandó címkékkel kapcsolatos automatikus detektálás, illetve a tény, hogy ez a típusú címke az újraindítás után is megmarad. Ezeknek a címkéknek van egy külön, az állományrendszerük szerint elnevezett könyvtára a /dev könyvtáron belül. Például az UFS2 állományrendszer-címkék a /dev/ufs könyvtárban keletkeznek. Egy általános címke a következõ induláskor elveszik. Ezek a címkék a /dev/label könyvtárban keletkeznek, és ideálisak a kísérletezgetésre. Állandó címkék az állományrendszereken a tunefs vagy a newfs segédprogramok valamelyikével helyezhetõek el. Ha egy UFS2 állományrendszerre szeretnénk tenni egy állandó címkét az adataink megsemmisítése nélkül, adjuk ki a következõ parancsot: &prompt.root; tunefs -L home /dev/da3 Ha az érintett állományrendszeren nincs üres hely, ennek a parancsnak a használata adatvesztéshez vezethet. Ilyen esetben inkább a felesleges állományok eltávolításával kellene törõdnünk, nem pedig címkék hozzáadásával. Ezután egy címkének kell megjelennie a /dev/ufs könyvtárban, amelyet vegyünk is fel az /etc/fstab állományba: /dev/ufs/home /home ufs rw 2 2 Az állományrendszert tilos csatolni a tunefs futtatása alatt! Most már a megszokott módon csatolhatjuk az állományrendszert: &prompt.root; mount /home Ettõl a ponttól kezdve, amíg a geom_label.ko modul betöltõdik a rendszerindítás során a /boot/loader.conf állományon keresztül, vagy a GEOM_LABEL opció megtalálható a rendszermag konfigurációs állományában, az eszközleíró a rendszerre nézve minden komolyabb következmény nélkül megváltozhat. Állományrendszereket létrehozhatunk alapértelmezett címkével is a newfs paraméterével. Errõl részletesebben a &man.newfs.8; man oldalon olvashatunk. Az alábbi paranccsal tudjuk törölni a címkét: &prompt.root; glabel destroy home Naplózó UFS GEOM-on keresztül GEOM naplózás A &os; 7.0-ás verziójának megjelenésével egy rég várt kiegészítés, a naplózó UFS végre elérhetõvé válik. Maga az implementáció a GEOM alrendszeren keresztül érhetõ el, és a &man.gjournal.8; segédprogram segítségével könnyedén beállítható. Mit is jelent a naplózás? A naplózás támogatásával a rendszer egy naplót vezet az állományrendszert érintõ tranzakciókról — például az olyan változtatásokról, amelyek egy komplett írási mûveletet eredményeznek — mielõtt még a metaadatok és lemezírási mûveletek szabályosan befejezõdnének. Ez a könyvelés késõbb visszajátszható az állományrendszerben lezajlott tranzakciók reprodukálásához, és ezzel megelõzhetõek az állományrendszerben keletkezõ esetleges ellentmondások. Ez egy újabb módszer az adatvesztés és az állományrendszerben elõforduló ellentmondások elkerülésére. Eltérõen a Soft Updates módszertõl, ahol a metaadatok frissítését biztosítják és követik nyomon, vagy a Snapshots módszertõl, ahol pillanatképeket tárolunk az állományrendszerrõl, itt egy konkrét naplót tárolunk az utolsó szektorokban, illetve bizonyos esetekben egy teljesen másik lemezen. Ellentétben a többi naplózó állományrendszertõl, a gjournal módszere blokk alapú és nem az állományrendszer részeként került implementálásra — csupán a GEOM egyik bõvítménye. A gjournal támogatásához a &os; rendszermag konfigurációs állományában be kell állítani a következõ opciót — amely a 7.X rendszereken alapbeállítás: options UFS_GJOURNAL Ha ezt aktiváltuk, egy szabad állományrendszeren az alábbi lépéseken keresztül tudunk létrehozni egy naplót, feltéve, hogy a da4 egy új SCSI-meghajtó: &prompt.root; gjournal label /dev/da4 &prompt.root; gjournal load Ennél a pontnál lennie kell egy /dev/da4 és egy /dev/da4.journal eszközleírónak. Hozzunk létre egy állományrendszert ezen az eszközön: &prompt.root; newfs -O 2 -J /dev/da4.journal Ez a parancs létrehoz egy naplózó UFS2 állományrendszert. Csatoljuk is be a mount segítségével az eszközt kívánt csatlakozási pontra: &prompt.root; mount /dev/da4.journal /mnt Ha több slice-unk is van, akkor a napló mindegyik slice-hoz külön létrejön. Például, ha az ad4s1 és ad4s2 egyaránt slice-ok, akkor a gjournal legyártja az ad4s1.journal és ad4s2.journal eszközleírókat. Abban az esetben, ha kétszer futattjuk le a parancsot, az eredmény journals lesz. Bizonyos körülmények között kívánatos lehet a naplót egy másik lemezen tartani. Ilyen esetekben a naplózás bekapcsolásához a naplót biztosító szolgáltatót vagy tárolóeszközt a naplózni kívánt eszköz után kell szerepeltetni. A naplózás akár az aktuálisan használt állományrendszeren is aktiválható a tunefs használatával. Az állományrendszer módosításakor viszont mindig érdemes biztonsági másolatot készíteni! Az esetek többségében a gjournal hibát fog jelezni, mivel nem tudja létrehozni a naplót, azonban ez nem védi meg az adatainkat a tunefs helytelen használata által okozott sérülésektõl. diff --git a/hu_HU.ISO8859-2/books/handbook/jails/chapter.sgml b/hu_HU.ISO8859-2/books/handbook/jails/chapter.sgml index a23be79a97..6a28b72f76 100644 --- a/hu_HU.ISO8859-2/books/handbook/jails/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/jails/chapter.sgml @@ -1,1312 +1,1312 @@ Matteo Riondato Írta: A jail alrendszer jail Áttekintés Ez a fejezet a &os;-ben található jail alrendszert, valamint annak használatát mutatja be közelebbrõl. Az jail, melyet gyakran csak úgy emlegetnek, mint a chroot környezetek továbbfejlesztését, a rendszergazdák számára ajánlott, nagyon sokoldalú eszköz, de a haladó felhasználók is hasznosnak találhatják. A fejezet elolvasása során megismerjük: mi is az a jail, milyen célra használható a &os;-ben; hogyan hozzunk létre, indítsunk el és állítsunk le jaileket; a létrehozott jailek karbantartásainak alapjait, a jailek belülrõl és kívülrõl egyaránt. A jail alrendszerrõl még több hasznos információt a következõ helyekrõl tudhatunk meg: A &man.jail.8; man oldal. Ez tartalmazza a jail segédprogram teljes referenciáját — ez az a karbantartásra használható eszköz, amellyel el tudjuk indítani, le tudjuk állítani és vezérelni tudjuk a jaileket a &os;-ben. A levelezési listák és azok archívumai. A &a.questions; archívuma és a &a.mailman.lists;en található többi levelezési lista rengeteg olvasnivalót tartogat a jailekkel kapcsolatban. Mindig érdemes keresni ezekben az archívumokban, vagy beküldeni a kérdésünket a &a.questions.name; levelezési listára. A jail alrendszerhez kapcsolódó fogalmak A fejezet további részében a következõ fogalmakat fogjuk használni, hogy a &os; jailekhez tartozó egyes részeit és azok belsõ mûködését, valamint kapcsolatukat a rendszer többi részével még inkább érthetõvé tegyük: &man.chroot.2; (parancs) A &os; azon rendszerhívása, amely egy program és annak leszármazottjai futtatása során megváltoztatja a gyökérkönyvtárat. (change root) &man.chroot.2; (környezet) A chroot módban futó programok környezete. Olyan erõforrásokat foglal magában, mint mondjuk az állományrendszer látható része, az elérhetõ felhasználói és csoport azonosítók, hálózati csatolók és egyéb folyamatok közti kommunikációs mechanizmusok stb. &man.jail.8; (parancs) Az a rendszerkarbantartó segédprogram, amely lehetõvé teszi program elindítását elzárt környezetben. befogadó (rendszer, program, felhasználó stb.) Az elzárt környezetet irányító rendszer. A befogadó rendszer hozzá tud férni az összes elérhetõ hardveres erõforráshoz, képes az elzárt környezeten kívül és belül futó programokat vezérelni. Az egyik legfontosabb különbség a befogadó és az elzárt rendszer között, hogy azok a korlátozások, amelyek az elzárt környezetben rendszeradminisztrátori jogokkal futó programokra vonatkoznak, nem feltétlenül érvényesek a befogadó rendszerben futóakra. befogadott (rendszer, program, felhasználó stb.) Olyan program, felhasználó vagy más egyéb egyed, amely csak egy jailen keresztül, korlátozottan tud hozzáférni az erõforrásokhoz. Bevezetés Mivel a rendszeradminisztráció egy nehéz és zavarba ejtõ feladat, rengeteg komoly eszköz jött létre a rendszergazdák életének megkönnyítésére. Ezek az eszközök többnyire a rendszerek telepítését, beállítását és karbantartását igyekeznek valamilyen módon jobbá tenni. A rendszergazdák egyik feladata úgy gondoskodni a biztonságról, hogy közben a rendszer képes legyen ellátni eredeti feladatát. A &os; rendszerek biztonságosságának növelését hivatott egyik ilyen eszköz a jails. Elõször a &os; 4.X verziójában bukkant fel, de jelentõs fejlõdésen ment keresztül a &os; 5.X verziókban, aminek köszönhetõen sokkal erõteljesebb és rugalmasabb alrendszerré vált. A fejlesztése természetesen most is folytatódik tovább, állandóan fejlõdik a használhatósága, teljesítménye, megbízhatósága és biztonságossága. Mi is az a jail? A BSD-szerû operációs rendszerekben már a 4.2BSD óta megtalálható volt a &man.chroot.2;. A &man.chroot.8; segédprogrammal meg tudjuk megváltoztatni adott programok számára a gyökérkönyvtárat, és ezzel egy biztonságos környezetet teremteni, távol a rendszer többi részétõl. A chroot-tal kialakított környezetben elinduló programok nem tudnak hozzáférni a rajta kívül található állományokhoz és erõforrásokhoz. Ennek okán, ha egy ilyen környezetben futó szolgáltatást megtámadnak, az önmagában még nem teszi lehetõvé a támadó számára, hogy elérhesse az egész rendszert. A &man.chroot.8; remekül használható olyan egyszerûbb feladatok megoldására, amelyek nem igényelnek túlságosan sok rugalmasságot vagy bonyolult és fejlett támogatást. A chroot ötletének felmerülése óta azonban számos kiskaput találtak már az általa létrehozott környezetekben, és habár ezek mindegyikét javították a &os; újabb változataiban, teljesen egyértelmûvé vált, hogy a &man.chroot.2; nem biztosít járható utat a szolgáltatások biztonságossá tételéhez. Erre a feladatra egy új alrendszert kellett kiépíteni. Ez az egyik oka annak, amiért az jaileket kifejlesztették. A jailek által képviselt elzárás ötlete több szempontból is a hagyományos &man.chroot.2; környezet elvén alapszik. Egy hagyományos &man.chroot.2; környezetben futó programok korlátozása csupán abban merül ki, hogy az állományrendszer melyik részét láthatják. A rendszer többi erõforrása (mint mondjuk a felhasználók, futó programok vagy a hálózati alrendszer) azonban továbbra is megosztva marad a chroot környezetben és a befogadó rendszerben futó programok között. A jailek által alkalmazott megoldás kibõvíti ezt a modellt, és nem csak az állományrendszerre vonatkozó hozzáférést virtualizálja, hanem több más dolog mellett kiterjeszti ezt a felhasználókra és a &os; hálózati alrendszerére is. Az elzárt környezetek beállításaihoz elérhetõ finomhangolási lehetõségekrõl bõvebben a ban esik szó. A jaileket az alább négy elem írja le: A könyvtárszerkezet egy részfája — attól a résztõl indulva, ahonnan a jail kezdõdik. A jailen belül futó programok nem léphetnek ki ebbõl a részfából. Az eredeti &man.chroot.2; kialakításában merengõ biztonsági hibák lehetõségei nem veszélyeztetik a többi &os; jailt. A rendszer neve — a név, amelyet a jailen belül használunk. Mivel a jaileket elsõsorban hálózati szolgáltatások kordában tartására használjuk, a jailekhez tartozó beszédes rendszernevek sokat tudnak segíteni a rendszergazdák munkájában. Egy IP-cím — a jailhez tartozik és nem változtatható meg a mûködése során. Egy jail IP-címe általában egy már létezõ hálózati csatoló másik címe, de ez nem szükségszerûen igaz minden esetben. Egy parancs — annak a programnak az elérési útja, amelyet elzártan kívánunk futtatni. Az elzárt környezet gyökerétõl mérve relatívan adjuk meg, és az adott környezet típusától függõen eltérõ lehet. Ezektõl eltekintve a jailek rendelkezhetnek saját felhasználókkal és lehetnek saját root felhasználóik is. Természetesen a root hatásköre csak az elzárt környezetre korlátozódik, és a befogadó rendszer szemszögébõl az elzárt root nem mindenható. Ráadásul az elzárt root felhasználó nem hajthat végre semmilyen kritikus mûveletet a saját &man.jail.8; környezetén kívül. A root további képességeirõl és korlátozásairól lentiekben bõvebben is említést teszünk a ban. A jailek létrehozása és vezérlése Egyes rendszergazdák a jaileket a következõ két típusba sorolják: teljes jail, mely egy valódi &os; rendszerre emlékeztet, és a szolgáltatás jail, mely egyetlen, feltehetõen kiemelt jogokkal futó alkalmazás vagy szolgáltatás számára van elõkészítve. Ez a besorolás csupán fogalmi szintû, a jail felépítésének módját nem befolyásolja. A &man.jail.8; man oldal részletesen ismerteti a jailek létrehozását: &prompt.root; setenv D /itt/lesz/a/jail &prompt.root; mkdir -p $D &prompt.root; cd /usr/src &prompt.root; make world DESTDIR=$D &prompt.root; cd etc/ Ez a lépés nem szükséges a &os; 6.0-ás vagy annál újabb verziójában. &prompt.root; make distribution DESTDIR=$D &prompt.root; mount -t devfs devfs $D/dev Érdemes elõször a jail helyét megválasztani. Itt fog fizikailag helyet foglalni a befogadó rendszer állományrendszerén belül a jail. Jó választás lehet erre a /usr/jail/jailnév, + class="directory">/usr/jail/jailnév, ahol a jailnév a jailt azonosító rendszernév. A /usr/ + class="directory">/usr/ állományrendszeren általában elegendõ hely jut a jail állományrendszerének, ami egy teljes jail esetén lényegében a &os; alaprendszer alapértelmezett telepítésében megtalálható összes állomány másolatát tartalmazza. Ez a parancs fogja felmásolni a jail fizikai helyének választott könyvtár-részfába a mûködéshez szükséges programokat, függvénykönyvtárakat, man oldalakat és így tovább. Minden a &os; megszokott stílusában történik — elõször mindent lefordít, majd az eredményt feltelepíti a célként megadott könyvtárba. A make paramétereként megadott distribution cél gondoskodik az összes szükséges konfigurációs állomány felmásolásáról. Magyarán szólva, átmásolja az összes telepíhetõ állományt a /usr/src/etc/ + class="directory">/usr/src/etc/ könyvtárból a jail /etc + class="directory">/etc alkönyvtárába, vagyis a $D/etc/ + class="directory">$D/etc/ könyvtárba. A jaileken belül a &man.devfs.8; csatlakoztatása nem kötelezõ. Másrészt azonban majdnem mindegyik alkalmazás, a feladatától függõen, legalább egy eszközhöz hozzá akar férni. Nagyon fontos, hogy a kezünkbe vegyük a eszközök hozzáférésének irányítását a jaileken belül, mivel a helytelen beállítások révén a támadók csúnya dolgokat tudnak majd mûvelni. A &man.devfs.8; mûködését a &man.devfs.8; és &man.devfs.conf.5; man oldalakon is ismertetett szabályrendszerek irányítják. Ahogy a jailt telepítettük, a &man.jail.8; segédprogrammal tudjuk elindítani. A &man.jail.8; négy kötelezõ paramétert vár, melyekre a ban ki is térünk. Más paramétereket is megadhatunk, például azt, hogy az elzárt program egy adott felhasználó jogaival fusson. A paraméter használata a jail típusától függ: egy virtuális rendszer esetében a /etc/rc jó választásnak bizonyulhat, mivel ennek segítségével egy valódi &os; rendszerindítási folyamatát játszhatjuk le. Amennyiben elzárt szolgáltatásról van szól, az adott szolgáltatástól vagy alkalmazástól függ. A jaileket gyakran már a rendszerindítás során elindítják, amit a &os; rc mechanizmusa nagyban meg is könnyít. A rendszer indítása során aktiválandó jailek listáját vegyük hozzá a &man.rc.conf.5; állományhoz: jail_enable="YES" # Ide NO-t írjunk, ha ki akarjuk kapcsolni jail_list="www" # Szóközzel elválasztva soroljuk fel a jaileket A jail_list-ben szereplõ összes jailt meg kell adnunk az ezeket leíró &man.rc.conf.5;-beli beállításokat: jail_www_rootdir="/usr/jail/www" # a jail gyökérkönyvtára jail_www_hostname="www.example.org" # a jail neve jail_www_ip="192.168.0.10" # a jail IP-címe jail_www_devfs_enable="YES" # legyen-e devfs a jailen belül jail_www_devfs_ruleset="www_ruleset" # az alkalmazott devfs szabályrendszer Az &man.rc.conf.5; állományban szereplõ jailek esetén a /etc/rc szkript fut le, tehát feltételezi, hogy az így megadott jail egy teljes virtuális rendszer. A szolgáltatások jailbe foglalásához meg kell változtatnunk a jail alapértelmezett parancsát is. Ezt a jail_jailnév_exec_start opció megfelelõ beállításával tudjuk megtenni. Az összes itt elérhetõ opciót a &man.rc.conf.5; man oldalon találhatjuk meg. Ha léteznek a megfelelõ bejegyzések az rc.conf állományban, akkor az /etc/rc.d/jail szkript is használható arra, hogy a jaileket kézzel indítsuk el vagy állítsuk le: &prompt.root; /etc/rc.d/jail start www &prompt.root; /etc/rc.d/jail stop www A &man.jail.8; leállítására jelen pillanatban még nem érhetõ el szabályos módszer. Ez azért van, mert a szabályos rendszerleállítást elvégzõ parancsok nem használhatóak a jailen belül. Emiatt a jaileket a legtisztábban úgy tudjuk leállítani, ha kiadjuk az alábbi parancsot magában a jailben vagy pedig a &man.jexec.8; segédprogrammal a jailen kívülrõl: &prompt.root; sh /etc/rc.shutdown Errõl a témáról többet a &man.jail.8; man oldalon olvashatunk. Finomhangolás és karbantartás Számos opció állítható be a jaileknél, és sokféle módon vegyíthetjük a befogadó &os; rendszerünket a jailekkel, ami által magasabb szintû alkalmazásokat hozhatunk létre. Ebben a részben bemutatunk: Néhány olyan beállítást, amellyel finomhangolhatjuk a telepített jailek által megvalósított biztonsági megszorítások viselkedését. A jailek kezelésére alkalmas néhány olyan magasabb szintû alkalmazást, amelyek elérhetõek a &os; Portgyûjteményén keresztül, és általános jail alapú megoldások kialakításához használhatóak. A &os;-ben található finomhangoló eszközök A jailek beállításainak finomhangolását túlnyomórészt &man.sysctl.8; változókkal végezhetjük el. A sysctl-en belül egy speciális részfában találhatunk erre alkalmas beállításokat: ez a a &os; rendszermag opciói között megtalálható security.jail.*. Itt közüljük a jailekre vonatkozó fontosabb sysctl változók listáját, az alapértelmezett értékeikkel együtt. A nevek minden bizonnyal sokat elárulnak, de ha többet szeretnénk tudni róluk, lapozzuk fel a &man.jail.8; és &man.sysctl.8; man oldalakat. security.jail.set_hostname_allowed: 1 security.jail.socket_unixiproute_only: 1 security.jail.sysvipc_allowed: 0 security.jail.enforce_statfs: 2 security.jail.allow_raw_sockets: 0 security.jail.chflags_allowed: 0 security.jail.jailed: 0 Ezekkel a változókkal a befogadó rendszer rendszergazdája tud hozzátenni vagy elvenni a root felhasználó alapértelmezett határaihoz. Vegyük azonban észre, hogy egyes korlátozások azonban semmiképpen sem szüntethetõek meg. A root nem csatlakoztathat és választhat le állományrendszereket a &man.jail.8; környezetben. Az elzárt root nem tölthet be és törölhet &man.devfs.8; szabályrendszereket, tûzfal szabályokat sem, ill. nem végezhet semmilyen olyan bármilyen más karbantartási feladatot, amely a rendszermag adataiban módosítást vonna maga után, például nem állíthatja a rendszermag securelevel (biztonsági szintjének) értékét. A &os; alaprendszere tartalmazza azokat a segédeszközöket, amelyekkel a rendszerben aktív jailek információt tudjuk megjeleníteni, vagy csatlakozni tudunk hozzájuk. A &man.jls.8; és &man.jexec.8; parancsok részei az alap &os; rendszernek, segítségükkel elvégezhetõek az alábbi egyszerû feladatokat: Ki tudjuk íratni az aktív jailek és hozzájuk tartozó azonosítókat (JID-eket), IP-címeket, neveket és útvonalakat. A befogadó rendszerbõl hozzá tudunk csatlakozni egy futó jailhez, és parancsokat tudunk futtatni a jailen belül vagy karbantartási feladatokat tudunk elvégezni magán a jailen belül. Ez különösen hasznosnak bizonyulhat, amikor a root felhasználó szabályosan le akarja állítani a jailt. A &man.jexec.8; segédprogrammal el tudunk indítani egy parancsértelmezõt a jailen belül, amibõl aztán irányíthatjuk. Példa: &prompt.root; jexec 1 tcsh Magasszintû karbantartó eszközök a &os; Portgyûjteményében A sok külsõ karbantartó eszköz közül az egyik legteljesebb és leghasznosabb a sysutils/jailutils. Sok kisebb alkalmazást tartalmaz, melyek kibõvítik a &man.jail.8; irányíthatóságát. Bõvebb információkért kérjük, látogassa meg a hozzátartozó honlapot. A jailek alkalmazása Daniel Gerzo Írta: Szolgáltatások jailbe foglalása Ez a rész eredetileg &a.simon; oldalon található írásán, valamint Ken Tom (locals@gmail.com) átdolgozott cikkén alapul. Itt megismerhetjük, hogyan állítsunk be a &os; rendszerünkben egy biztonsági réteget a &man.jail.8; felhasználásával. Továbbá feltételezzük, hogy ez a rendszer legalább RELENG_6_0 verziójú és a fejezetben korábban tárgyaltakat az olvasó teljes mértékben megértette. A kialakítás A jailek egyik legnagyobb gondja a frissítés folyamatának lebonyolítása. Azért jelent ez egyre inkább gondot, mert minden egyes jailt újra fel kell építenünk a frissítése során. Ez többnyire nem okoz gondot egyetlen jail használata során, mivel maga a frissítési folyamat meglehetõsen egyszerû, azonban igen idõigényessé és fárasztóvá tud válni több jail esetében. Ez a példa a &os; képességeinek haladó szintû ismeretét követeli meg. Amennyiben az itt bemutatott lépesek túlságosan is bonyolultnak tûnnének, érdemes olyan egyszerûbb rendszerek után nézni, mint mondjuk a sysutils/ezjail, amely egy egyszerûbb módszert kínál fel a &os;-ben használt jailek karbantartására, és nem is annyira bonyolult, mint ez a példa. A bemutatandó példa célja, hogy feloldja az ilyen jellegû problémákat, és ezért igyekszik a jailek között mindent megosztani, ami csak lehetséges. Mindezt biztonságosan éri el — írásvédett &man.mount.nullfs.8; állományrendszer használatával, aminek köszönhetõen a frissítés maga egyszerûbbé, az egyes szolgáltatások különzárása pedig vonzóbbá válik. Ráadásul egyúttal egy nagyon egyszerû módszert mutat az új jailek hozzáadására és a régi törlésére ugyanúgy, mint a frissítésükre. Például ilyen szolgáltatásokat kívánunk szabályozni: egy HTTP szervert, egy DNS szervert, egy SMTP szervert és így tovább. Az itt szereplõ beállítás céljai: Készítsünk egy egyszerûen és könnyen átlátható jailkezelési rendszert. Ebbõl tehát következik, hogy ne kelljen lefuttatni a teljes rendszer telepítését minden egyes jailre. Könnyítsük meg az új jailek hozzáadását és a régiek eltávolítását. Könnyítsük meg a már létezõ jailek frissítését és cseréjét. Tegyük lehetõvé saját &os; ágak futtatását. Legyünk különösen körültekintõek a biztonság tekintetében, és igyekezzünk minél jobban csökkenteni veszély kockázatát. Takarékoskodjunk a tárhellyel és az állományrendszerrel, amennyire csak lehet. Ahogy azt már korábban is említettük, ez a kialakítás nagyban építkezik egyetlen fõ sablonra, amely írásvédetten kerül csatlakoztatásra (nullfsen keresztül) az egyes jailekben, valamint jailenként egy-egy írható-olvasható eszközre. Ez az eszköz lehet egy külön fizikai lemez, egy partíció vagy egy vnode alapú &man.md.4; eszköz. Ebben a példában írható-olvasható nullfs csatlakozásokat használunk. Az állományrendszer kiosztása a most következõ listában szerepel: Minden jailt a /home/j + class="directory">/home/j könyvtárban csatlakoztatunk. - A /home/j/mroot + A /home/j/mroot lesz az összes jail sablonja és mindegyikük számára írásvédett. Minden jailnek létrehozunk egy üres alkönyvtárat a /home/j + class="directory">/home/j könyvtárban. Minden jailnek lesz egy /s alkönyvtára, + class="directory">/s alkönyvtára, amelyet a rendszer írható-olvasható részére irányítunk. Minden jailnek lesz egy saját írható-olvasható része, amely - a /home/j/skel + a /home/j/skel könyvtáron alapszik. Mindegyik elzárt terület (a jailek írható-olvasható része) a - /home/js + /home/js könyvtárban jön létre. Ez a kiosztás feltételezi, hogy a jaileket - a /home + a /home partíción hozzuk létre. Ez természetesen bármi másra megváltoztatható, de akkor figyelnünk kell erre minden egyes parancs kiadása elõtt. A sablon létrehozása Ez a rész leírja a fõ sablon létrehozásához szükséges lépéseket. Ez a jailek számára írásvédett lesz. Érdemes mindig frissíteni a &os; rendszerünket a legújabb -RELEASE ágra. Ehhez olvassuk el az ide tartozó fejezetet a kézikönyvbõl. Abban az esetben, ha a frissítés nem lenne megoldható, egy make buildworld parancsot mindenképpen le kell tudnunk futtatni. Ezenfelül a sysutils/cpdup csomagra is szükségünk van. Használni fogjuk a &man.portsnap.8; segédprogramot is a &os; Portgyûjtemény letöltéséhez. Akik nem ismernék, a kézikönyv errõl szóló fejezetében olvashatnak róla. Elõször is, készítsük el az írásvédett állományrendszer könyvtárszerkezetét, amely majd tartalmazni fogja a jailek által használt &os;-s programokat. Ezután lépjünk be a &os; forrásfájának könyvtárába és telepítsük fel az írásvédett állományrendszert a sablonba: &prompt.root; mkdir /home/j /home/j/mroot &prompt.root; cd /usr/src &prompt.root; make installworld DESTDIR=/home/j/mroot Ezt követõen készítsük elõ a jailek számára a &os; Portgyûjteményt és &os; forrásfát, melyek kellenek a mergemaster használatához: &prompt.root; cd /home/j/mroot &prompt.root; mkdir usr/ports &prompt.root; portsnap -p /home/j/mroot/usr/ports fetch extract &prompt.root; cpdup /usr/src /home/j/mroot/usr/src Hozzuk létre a rendszer írásvédett részének vázát: &prompt.root; mkdir /home/j/skel /home/j/skel/home /home/j/skel/usr-X11R6 /home/j/skel/distfiles &prompt.root; mv etc /home/j/skel &prompt.root; mv usr/local /home/j/skel/usr-local &prompt.root; mv tmp /home/j/skel &prompt.root; mv var /home/j/skel &prompt.root; mv root /home/j/skel Használjuk a mergemastert a hiányzó konfigurációs állományok telepítésére. Szabaduljunk meg a mergemaster által készített felesleges könyvtáraktól: &prompt.root; mergemaster -t /home/j/skel/var/tmp/temproot -D /home/j/skel -i &prompt.root; cd /home/j/skel &prompt.root; rm -R bin boot lib libexec mnt proc rescue sbin sys usr dev Most pedig szimbolikusan linkeljük az írható-olvasható állományrendszert az írásvédett állományrendszerre. Ellenõrizzük, hogy a szimbolikus linkek a megfelelõ s/ könyvtárakban + class="directory">s/ könyvtárakban jöttek létre. Valós vagy rossz helyen létrehozott könyvtárak használata esetén a telepítés nem fog sikerülni. &prompt.root; cd /home/j/mroot &prompt.root; mkdir s &prompt.root; ln -s s/etc etc &prompt.root; ln -s s/home home &prompt.root; ln -s s/root root &prompt.root; ln -s ../s/usr-local usr/local &prompt.root; ln -s ../s/usr-X11R6 usr/X11R6 &prompt.root; ln -s ../../s/distfiles usr/ports/distfiles &prompt.root; ln -s s/tmp tmp &prompt.root; ln -s s/var var Utolsó lépésként hozzunk létre egy /home/j/skel/etc/make.conf állományt az alábbi tartalommal: WRKDIRPREFIX?= /s/portbuild A WRKDIRPREFIX beállításával lehetõvé válik a &os; portok jaileken belüli fordítása. Ne felejtsük el, hogy a portokat tartalmazó könyvtár az írásvédett rendszer része! Az átállított WRKDIRPREFIX azonban megengedi, hogy a fordítások az egyes jailek írható-olvasható részeiben történjenek. A jailek létrehozása Most, miután teljesen elkészült a &os; jailek sablonja, be is tudjuk állítani és hozzá is tudjuk venni ezeket az /etc/rc.conf állományhoz. Ebben a példában 3 jail létrehozását láthatjuk: NS, MAIL és WWW. Írjuk bele a következõ sorokat az /etc/fstab állományba, aminek köszönhetõen az egyes jailek számára elérhetõvé válik az írásvédett sablon és a hozzájuk tartozó írható-olvasható területek: /home/j/mroot /home/j/ns nullfs ro 0 0 /home/j/mroot /home/j/mail nullfs ro 0 0 /home/j/mroot /home/j/www nullfs ro 0 0 /home/js/ns /home/j/ns/s nullfs rw 0 0 /home/js/mail /home/j/mail/s nullfs rw 0 0 /home/js/www /home/j/www/s nullfs rw 0 0 Az elsõ helyen nullával jelölt partíciókat a &man.fsck.8; nem fogja ellenõrizni a rendszer indulása során, a második helyen nullával jelölt partíciókat pedig nem fogja menteni a &man.dump.8;. Mi egyáltalán nem akarjuk, hogy az fsck ellenõrizze vagy a dump lementse a jailjeinkhez tartozó írásvédett nullfs-partícióinkat. Ezért szerepel végig 0 0 a fentebb szereplõ fstab-bejegyzések utolsó két oszlopában. Állítsuk be a jaileket az /etc/rc.conf-ban: jail_enable="YES" jail_set_hostname_allow="NO" jail_list="ns mail www" jail_ns_hostname="ns.example.org" jail_ns_ip="192.168.3.17" jail_ns_rootdir="/usr/home/j/ns" jail_ns_devfs_enable="YES" jail_mail_hostname="mail.example.org" jail_mail_ip="192.168.3.18" jail_mail_rootdir="/usr/home/j/mail" jail_mail_devfs_enable="YES" jail_www_hostname="www.example.org" jail_www_ip="62.123.43.14" jail_www_rootdir="/usr/home/j/www" jail_www_devfs_enable="YES" Azért állítottuk a jail_név_rootdir változó értékét a - /usr/home + /usr/home könyvtárra a /home könyvtár + class="directory">/home könyvtár helyett, mert a &os; alaptelepítésében a /home könyvtár + class="directory">/home könyvtár fizikailag a /usr/home + class="directory">/usr/home könyvtárral egyezik meg. A jail_név_rootdir változó értékeként megadott könyvtár nem tartalmazhat szimbolikus linket, máskülönben a jailek nem lesznek hajlandóak létrejönni. Ennek megállapításában a &man.realpath.1; segédprogram lehet segítségünkre. A korlátozás részleteirõl a &os;-SA-07:01.jail biztonsági figyelmeztetésben olvashatunk. Hozzuk létre az egyes jailek írásvédett állományrendszereihez szükséges csatlakozási pontokat: &prompt.root; mkdir /home/j/ns /home/j/mail /home/j/www Telepítsük az írható-olvasható sablont az egyes jailekbe. Figyeljük meg a sysutils/cpdup használatát, amellyel az egyes könyvtárak pontos másolatait hozhatjuk létre: &prompt.root; mkdir /home/js &prompt.root; cpdup /home/j/skel /home/js/ns &prompt.root; cpdup /home/j/skel /home/js/mail &prompt.root; cpdup /home/j/skel /home/js/www Ebben a fázisban a jailek már elkészültek és készen állnak a futásra. Elõször csatlakoztassuk az egyes jailekhez szükséges állományrendszereket, majd indítsuk el ezeket a /etc/rc.d/jail szkripttel: &prompt.root; mount -a &prompt.root; /etc/rc.d/jail start A jailek most már futnak. Az elindulásuk ellenõrzéséhez használjuk a &man.jls.8; parancsot. Valami ilyesmit láthatunk a kiadása után: &prompt.root; jls JID IP Address Hostname Path 3 192.168.3.17 ns.example.org /home/j/ns 2 192.168.3.18 mail.example.org /home/j/mail 1 62.123.43.14 www.example.org /home/j/www Itt már be tudunk jelentkezni az egyes jailekbe, új felhasználókat tudunk készíteni vagy démonokat tudunk beállítani. A JID oszlop mutatja az egyes jailek azonosítási számát. A 3-as JID számú jailben az alábbi parancs használatával karbantartási feladatokat elvégezni: &prompt.root; jexec 3 tcsh Frissítés Idõrõl idõre adódhat, hogy frissítenünk kell a rendszert a &os; egy újabb változatára, vagy egy biztonsági hiba javítása miatt, vagy pedig a már meglevõ jailek számára hasznos újítások bevezetése miatt. Ez a kialakítás megkönnyíti a korábban létrehozott jailjeink frissítését. Továbbá igyekszik minimalizálni a kiesésüket is, mivel a jaileket csak a legutolsó pillanatban fogjuk leállítani. Sõt, még az is lehetõvé válik, hogy visszaállítsuk a korábbi verziót, ha véletlenül valami rosszul sülne el menetközben. Elsõ lépéseként frissítsük magát a befogadó rendszert a megszokott módon. Ezután hozzunk létre egy új írásvédett sablont a /home/j/mroot2 + class="directory">/home/j/mroot2 könyvtárban. &prompt.root; mkdir /home/j/mroot2 &prompt.root; cd /usr/src &prompt.root; make installworld DESTDIR=/home/j/mroot2 &prompt.root; cd /home/j/mroot2 &prompt.root; cpdup /usr/src usr/src &prompt.root; mkdir s A installworld lefuttatása létrehoz néhány felesleges könyvtárat, melyeket takarítsunk is el: &prompt.root; chflags -R 0 var &prompt.root; rm -R etc var root usr/local tmp Hozzuk újra létre az írható-olvasható szimbolikus linkjeinket a fõ állományrendszerre: &prompt.root; ln -s s/etc etc &prompt.root; ln -s s/root root &prompt.root; ln -s s/home home &prompt.root; ln -s ../s/usr-local usr/local &prompt.root; ln -s ../s/usr-X11R6 usr/X11R6 &prompt.root; ln -s s/tmp tmp &prompt.root; ln -s s/var var Most érkezett el az idõ, hogy leállítsuk a jaileket: &prompt.root; /etc/rc.d/jail stop Válasszuk le az eredeti állományrendszereket: &prompt.root; umount /home/j/ns/s &prompt.root; umount /home/j/ns &prompt.root; umount /home/j/mail/s &prompt.root; umount /home/j/mail &prompt.root; umount /home/j/www/s &prompt.root; umount /home/j/www Az írható-olvasható állományrendszerek hozzá vannak kapcsolva az írásvédett állományrendszerhez (/s), ezért azokat + class="directory">/s), ezért azokat elõször le kell választani. Mozgassuk el az útból a régi írásvédett állományrendszerünket és váltsuk fel az újjal. Így biztonsági mentésként és a régi írásvédett rendszer archívumaként továbbra is rendelkezésre áll, ha valami baj történne. Az itt használt elnevezés az újonnan létrehozott írásvédett állományrendszer dátumából ered. Mozgassuk át az eredeti &os; Portgyûjteményt az új állományrendszerre, hogy megtakarítsunk némi tárhelyet és állományleírót: &prompt.root; cd /home/j &prompt.root; mv mroot mroot.20060601 &prompt.root; mv mroot2 mroot &prompt.root; mv mroot.20060601/usr/ports mroot/usr Most már készen áll az új írásvédett sablon, így már csak az állományrendszerek újracsatlakoztatása és a jailek újraindítása maradt: &prompt.root; mount -a &prompt.root; /etc/rc.d/jail start A &man.jls.8; használatával ellenõrizzük, hogy a jailek rendesen elindultak. Ne felejtsük el jailenként lefuttatni a mergemastert sem. A konfigurációs állományokat és az rc.d szkripteket is frissítenünk kell majd. diff --git a/hu_HU.ISO8859-2/books/handbook/kernelconfig/chapter.sgml b/hu_HU.ISO8859-2/books/handbook/kernelconfig/chapter.sgml index 6234d80dc0..c4afe2ea5c 100644 --- a/hu_HU.ISO8859-2/books/handbook/kernelconfig/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/kernelconfig/chapter.sgml @@ -1,2035 +1,2106 @@ Jim Mock Frissítette és átdolgozta: Jake Hamby Eredetileg írta: A &os; rendszermag testreszabása Áttekintés rendszermag saját rendszermag készítése A rendszermag a &os; operációs rendszer lelke. Felelõs a memória kezelésért, a biztonsági szabályozások betartatásáért, a hálózat mûködtetéséért, a lemezhozzáférésért és sok minden másért is. Miközben maga a &os; egyre jobban konfigurálható dinamikusan, addig alkalmanként elegedhetetlen, hogy újrakonfiguráljuk és újrafordítsuk a rendszermagot. A fejezet elolvasása során megismerjük: miért lehet szükségünk egy saját rendszermagra; hogyan készítsünk konfigurációs állományt a rendszermaghoz, vagy hogyan módosítsunk egy már létezõt; hogyan használjuk a rendszermag konfigurációs állományát egy új rendszermag lefordítására és létrehozására; hogyan telepítsük az új rendszermagot; hogyan orvosoljuk a felmerülõ problémákat. A fejezetben az összes példaként bemutatásra kerülõ parancsot root felhasználóként kell kiadni a sikeres végrehajtásukhoz. Miért készítsünk saját rendszermagot? A &os; eredetileg ún. monolitikus rendszermaggal rendelkezett. Ez azt jelenti, hogy a rendszermag egyetlen nagy program volt, ami elõre rögzített eszközöket ismert, és ha meg akartuk változtatni a rendszermag mûködését, akkor fordítanunk kellett új rendszermagot, majd újra kellett indítanunk vele a számítógépet. Manapság azonban a &os; már inkább afelé a megközelítés felé halad, ahol a rendszermag funkcionalitásának nagy részét mûködés közben az igények szerint betölthetõ és eltávolítható modulok adják. Ezzel lehetõvé válik, hogy a rendszermag gyorsan illeszkedjen az újonnan megjelenõ hardvereszközökhöz (mint például a laptopok PCMCIA-kártyáihoz), vagy olyan új funkciókat tegyünk a rendszermaghoz, amelyek a fordításánál nem voltak feltétlenül szükségesek. Ezt a modellt nevezik moduláris rendszermagnak. Ennek ellenére még mindig elkerülhetetlen, hogy esetenként ne legyen szükség a rendszermag statikus testreszabására. Ez a legtöbb esetben azzal magyarázható, hogy vannak olyan funkciók, amelyek túlságosan is mélyen helyezkednek el a rendszermagban, ezáltal nem tölthetõek be dinamikusan. Máskor viszont egyszerûen azért nem lehetséges, mert még senki sem szánt idõt az adott funkcióhoz tartozó, dinamikusan betölthetõ modul elkészítésére. Egy saját rendszermag készítése azon legfontosabb próbatételek egyike, melyet majdnem az összes BSD felhasználónak ki kell állnia. Ez a folyamat, habár némileg idõigényes, számos elõnyt tartogat &os; rendszerünk számára. Eltérõen egy GENERIC (általános) rendszermagtól, amely rengeteg hardvert támogat, egy saját rendszermag csak a saját PC-nk hardverét ismeri. Ennek több elõnye is van, például: A rendszerünk gyorsabban indul. Mivel a rendszermag csak azokat a hardvereket fogja keresni, melyek a rendszerünkben megtalálhatóak, jelentõs mértékben le tud csökkeni az induláshoz szükséges idõ. Kisebb memóriahasználat. Egy saját rendszermag gyakran kevesebb memóriát emészt fel, mint a GENERIC rendszermag, ami azért is fontos, mert a rendszermag mindig benn van a memóriában. Emiatt egy saját rendszermag elkészítése különösen hasznos lehet egy kevés fizikai memóriával rendelkezõ rendszeren. További hardverek támogatása. A saját rendszermagunkba olyan eszközök támogatását is beletehetjük, amelyek nem szerepelnek a GENERIC rendszermagban, mint például a hangkártyákét. Tom Rhodes Írta: A rendszerünkben levõ hardverek összeszedése Mielõtt belevetnénk magunkat a rendszermag beállításába, érdemes egy leltárt készíteni a gépünkben található különbözõ eszközökrõl. Ahol a &os; nem elsõdlegesen használt operációs rendszer, ott ehhez elegendõ megnézni a jelenlegi rendszerben található elemeket. Például az µsoft; rendszerek Eszközkezelõjében (Device Manager) általában az összes eszköz fontosabb adatait megtaláljuk. Magát az Eszközkezelõt pedig a Vezérlõpultból (Control Panel) érhetjük el. A µsoft.windows; egyes verzióiban a Rendszer (System) ikonjára kattintva megkapjuk azt a képernyõt, ahonnan közvetlenül el tudjuk érni az Eszközkezelõt. Ha viszont nincs másik operációs rendszer a gépünkön, akkor magunknak kell mindezeknek utánanéznünk. Erre az egyik alkalmas módszer a &man.dmesg.8; és a &man.man.1; parancsok használata. A &os;-ben található legtöbb meghajtónak van saját man oldala, ami tartalmazza az általuk kezelt eszközök listáját, illetve így a rendszerindítás során észlelt hardvereket nézhetjük vissza. Például az alábbi sor arra utal, hogy a psm meghajtó megtalálta a gépünkhöz tartozó egeret: psm0: <PS/2 Mouse> irq 12 on atkdbc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Generic PS/2 mouse, device ID 0 Ezután ezt a meghajtót vagy a rendszermagba kell beépítenünk, vagy pedig a &man.loader.conf.5; állományon keresztül betöltenünk. Bizonyos esetekben a dmesg az eszközök felkutatásának eredményei helyett csak a rendszer üzeneteit mutatja. Ilyen helyezetekben a teljes kimenet a /var/run/dmesg.boot állományban tekinthetõ meg. A hardverek manuális felderítésének módja a &man.pciconf.8; segédprogram kimenetének böngészése, ami egy valamivel részletesebb eredményt ad. Mint például: ath0@pci0:3:0:0: class=0x020000 card=0x058a1014 chip=0x1014168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'AR5212 Atheros AR5212 802.11abg wireless' class = network subclass = ethernet A pciconf paranccsal kapott kimenet ezen része azt mutatja, hogy az ath meghajtó talált egy vezeték nélküli Ethernet eszközt. Innen a man ath paranccsal érhetjük el a &man.ath.4; man oldalát. A &man.man.1; a paraméter megadásával további hasznos információkkal is tud szolgálni. A fentiekbõl kiindulva például a következõ paranccsal: &prompt.root; man -k Atheros le tudjuk kérdezni azokat a man oldalakat, amelyek tartalmazzák az adott szót: ath(4) - Atheros IEEE 802.11 wireless network driver ath_hal(4) - Atheros Hardware Access Layer (HAL) A hardvereszközeink listájával felvértezve most már egy saját rendszermag létrehozása sem lesz annyira ijesztõ. + + + + Meghajtók, alrendszerek és modulok + + rendszermag + meghajtók, modulok, alrendszerek + + Mielõtt új rendszermagot + készítenénk, érdemes megfontolnunk, hogy + egyáltalán szükségünk lesz-e + rá. Ha például valamilyen eszköz + támogatásához kell, akkor könnyen + elõfordulhat, hogy azt modulként is be tudjuk + tölteni. + + A rendszermaghoz tartozó modulok a /boot/kernel + könyvtárban találhatóak, és a + &man.kldload.8; segítségével a rendszer + mûködése közben dinamikusan + betölthetõek. Ha nem is az összes, de a + legtöbb meghajtóhoz tartozik egy modul és egy + man oldal. Például az elõzõ szakaszban az + ath vezeték nélküli + Ethernet meghajtóval foglalkoztunk. A következõ + leírást találjuk a hozzátartozó + man oldalon: + + Vagy ha modulként akarjuk betölteni ezt a meghajtót + a rendszer indítása során, akkor a &man.loader.conf.5; állományba + vegyük fel a következõ sort: + + if_ath_load="YES" + + A fentebb leírtak szerint tehát ha a + if_ath_load="YES" sort hozzáadjuk a + /boot/loader.conf állományhoz, + akkor a rendszer indulásakor ez a modul mindig dinamikusan + betöltõdik. + + Némely esetben azonban nem áll + rendelkezésünkre ilyen modul. Ez + különösen igaz bizonyos alrendszerekre és a + fontosabb meghajtókra, például az + FFS állományrendszerre + vonatkozóan, mivel ezeknek kötelezõen a + rendszermagban kell lenniük. Ugyanez elmondható a + hálózati támogatásra is (INET). Csak + úgy tudjuk megmondani, hogy valamelyik meghajtóra + szükség van a rendszermagban, ha elõször + megpróbáljuk megkeresni hozzá a + megfelelõ modult. + + + A beépített meghajtók figyelmetlen + eltávolításával könnyen + lefordíthatatlan állapotba kerülhet a + rendszermag. Például, ha a &man.ata.4; + meghajtót kivesszük a rendszermag + konfigurációs + állományából, az + ATA alrendszert használó + meghajtók csak abban az esetben fognak biztosan + mûködni, ha egyúttal felvesszük a + loader.conf állományba. Ha + nem vagyunk benne biztosak, akkor elõször + próbáljuk meg használni a modult és + csak utána hagyjuk el a rendszermagba + épített változatát. + Saját rendszermag készítése és telepítése rendszermag készítése, telepítése Elõször is tegyünk egy rövidke sétát a rendszermag könyvtárában. A továbbiakban említendõ összes könyvtár a /usr/src/sys könyvtáron belül található, amely /sys néven is elérhetõ. Itt rengeteg alkönyvtár található, mindegyikük a rendszermag különbözõ részeit testesíti meg. Ezek közül most számunkra a legfontosabb az architektúra/conf lesz, ahol majd létrehozzuk a saját rendszermagunk konfigurációs állományát, valamint a compile, ahol majd a rendszermagunk fordítása történik. Itt az architektúra lehet i386, alpha, amd64, ia64, powerpc, sparc64 vagy pc98 (a PC-k egyik, leginkább Japánban elterjedt változata). Az adott architektúra könyvtárában található összes állomány csak arra az architektúrára vonatkozik, a kód többi része pedig gépfüggetlen és közös az összes többi létezõ és leendõ &os; platformon. Érdemes megfigyelni a könyvtárak logikai elrendezését: minden egyes ismert eszköz, állományrendszer és bõvítmény saját alkönyvtárral rendelkezik. A példák során ez a fejezet feltételezi, hogy az i386 architektúrát használjuk. Ha ez a mi esetünkben nem így lenne, ne felejtsük el átírni bennük az elérési útvonalakat a rendszerünk architektúrájának megfelelõen. Ha nem lenne /usr/src/sys könyvtár a rendszerünkben, valószínûleg még nem telepítettük a rendszermag forráskódját. Ezt a legkönnyebben úgy tudjuk megtenni, ha root felhasználóként elindítjuk a sysinstall programot és ott kiválasztjuk a Configure (Beállítások), azon belül Distributions (Terjesztések) menüpontot, amiben válasszuk ki a src, base és sys terjesztéseket. Ha nem szeretnénk erre a célra a sysinstall programot használni, de rendelkezésünkre áll a hivatalos &os; CD, akkor a forrásokat akár parancssorból is telepíthetjük: &prompt.root; mount /cdrom &prompt.root; mkdir -p /usr/src/sys &prompt.root; ln -s /usr/src/sys /sys &prompt.root; cat /cdrom/src/ssys.[a-d]* | tar -xzvf - &prompt.root; cat /cdrom/src/sbase.[a-d]* | tar -xzvf - Ezután lépjünk be az i386/conf könyvtárba és másoljuk le a GENERIC konfigurációs állományt a kedvünk szerinti nevûre. Például: &prompt.root; cd /usr/src/sys/i386/conf &prompt.root; cp GENERIC SAJÁT Általában a nevet végig nagybetûkkel írjuk, és ha több &os;-s gépet is üzemeltetünk különbözõ hardverekkel, hasznosnak bizonyulhat megemlíteni benne az adott gép rendszerének nevét is. Ebben a példában ez most a SAJÁT lesz. A rendszermagunk konfigurációs állományát nem éppen a legjobb ötlet a /usr/src könyvtárban tárolni. Ugyanis könnyen elõfordulhat, hogy egy rosszul sikerült fordítás után egyszerûen csak letöröljük az egész /usr/src könyvtárat és onnan kezdjük újra. Azonban csak ezután juthat eszünkbe, hogy vele együtt bizony letöröltük a saját rendszermagunk konfigurációs állományát is! Ehhez hasonlóan, közvetlenül a GENERIC konfigurációs állomány szerkesztése sem ajánlott, mivel a források egy esetleges frissítésénél könnyen felülíródhat és ezzel együtt elvesznek a módosításaink is. Tehát érdemes inkább valahol máshol tárolnunk a rendszermagunk konfigurációs állományát, majd létrehozni rá egy szimbolikus linket a i386 könyvtárban. Valahogy így: &prompt.root; cd /usr/src/sys/i386/conf &prompt.root; mkdir /root/kernel &prompt.root; cp GENERIC /root/kernel/SAJÁT &prompt.root; ln -s /root/kernel/SAJÁT Most pedig a kedvenc szövegszerkesztõnkkel lássunk neki a SAJÁT átírásának! Ha nemrég telepítettük csak a rendszerünket, az egyetlen elérhetõ szövegszerkesztõnk minden bizonnyal a vi lesz. Róla most túlságosan is bonyolult lenne leírást adnunk, de az Irodalomjegyzékben található könyvek közül sokban elég jól bemutatják. Ezen kívül a &os; ajánl egy könnyebben megtanulható szövegszerkesztõt is az ee személyében, amely a kezdõk számára az ideális választás. Nyugodtan átírhatjuk az elöl található megjegyzéseket a saját konfigurációnknak megfelelõen, vagy akár azt is rögzíthetjük, hogy miben tértünk el a GENERIC beállításaitól. SunOS Ha fordítottunk már rendszermagot &sunos; vagy más BSD operációs rendszer alatt, ez az állomány ismerõsnek tûnhet. Ha viszont más operációs rendszerek, mint például a DOS felõl érkezünk, a GENERIC konfigurációs állomány egy kissé terebélyesnek tûnhet számunkra, ezért A konfigurációs állomány címû részt figyelmesen és lassan olvassuk át. Amennyiben a forrásfánkat a &os; projekt legfrissebb forrásaival szinkronizáljuk, mindig olvassuk el a /usr/src/UPDATING állományt, mielõtt bármilyen frissítéshez is kezdenénk. Itt megtalálhatóak azok a fontos érintett kérdések és területek, amely külön figyelmet igényelnek a frissített forráskód esetén. A /usr/src/UPDATING mindig a &os; forrásának legfrissebb változatához igazodik, és ezért sokkal naprakészebb információkat tartalmaz, mint ez a kézikönyv. Most pedig le kell lefordítanunk a rendszermag forráskódját. A rendszermag lefordítása Lépjünk be a /usr/src + class="directory">/usr/src könyvtárba: &prompt.root; cd /usr/src Fordítsuk le a rendszermagot: &prompt.root; make buildkernel KERNCONF=SAJÁT Telepítsük az új rendszermagot: &prompt.root; make installkernel KERNCONF=SAJÁT A &os; teljes forrásfájára szükség van a rendszermag lefordításához. Amikor egy saját rendszermagot alapértelmezés szerint fordítunk, vele együtt az összes modul is lefordításra kerül. Ha viszont idõt szeretnénk megtakarítani a rendszermag frissítése során vagy csak a saját moduljainkat akarjuk lefordítani, érdemes átírnunk az /etc/make.conf állományt a rendszermag fordításának megkezdése elõtt: MODULES_OVERRIDE = linux acpi sound/sound sound/driver/ds1 ntfs Ez a változó megadja a ténylegesen lefordítandó modulok listáját. WITHOUT_MODULES = linux acpi sound/sound sound/driver/ds1 ntfs Ez a változó a fordításból kihagyandó modulokat sorolja fel. A rendszermag fordításának folyamatában egyéb hasznosnak tekinthetõ változókról a &man.make.conf.5; man oldalán olvashatunk. /boot/kernel.old Ezután az új rendszermag a /boot/kernel könyvtárba kerül /boot/kernel/kernel néven és a korábbi rendszermag pedig /boot/kernel.old/kernel néven õrzõdik meg. Most állítsuk le a rendszert és indítsuk újra az új rendszermag aktiválásához. Ha közben valamilyen hiba történt volna, nézzük meg a fejezet végén található, hibakeresésre vonatkozó utasításokat. Mindenképpen olvassuk el azt a részt, amely leírja, hogyan állítsuk helyre a rendszerünket abban az esetben, ha az új rendszermaggal nem indul. A rendszerindítási folyamathoz tartozó további állományok, mint például a rendszerbetöltõ (&man.loader.8;) és annak konfigurációs állománya, a /boot könyvtárban találhatóak. A külsõ és saját modulok a /boot/kernel a könyvtárba kerülhetnek, azonban a felhasználóknak nagyon ügyelniük kell rá, hogy az itt található modulok szinkronban legyenek a lefordított rendszermaggal. Ellenkezõ esetben a rendszerben megbízhatatlanságot, hibákat észlelhetünk. Joel Dahl A &os; 6.X verziójához igazította: A konfigurációs állomány rendszermag NOTES NOTES rendszermag konfigurációs állomány A konfigurációs állomány általános formátuma igen egyszerû. Minden sor tartalmaz egy kulcsszót és egy vagy több paramétert. A további egyszerûsítés kedvéért a legtöbb sor csak egyetlen paramétert tartalmaz. Bármi, ami egy # (kettõskereszt) jelet követ, megjegyzésnek minõsül és nem számít konfigurációs elemnek. A most következõ részek bemutatják az egyes kulcsszavakat abban a sorrendben, ahogy azokat a GENERIC állományban is megtalálhatjuk. Az architektúrafüggõ opciók és eszközök teljes listáját a GENERIC állománnyal egy könyvtárban levõ NOTES állományban találhatjuk meg. Az architektúrától független opciókat a /usr/src/sys/conf/NOTES állományban találjuk. Ha olyan állományt akarunk készíteni, amely tartalmazza az összes lehetséges opciót, például teszteléshez, futtassuk le root felhasználóként az alábbi parancsot: &prompt.root; cd /usr/src/sys/i386/conf && make LINT rendszermag konfigurációs állomány Itt a GENERIC rendszermag-konfigurációs állomány ismertetése következik, az érthetõség kedvéért helyenként megjegyzésekkel kibõvítve. A bemutatott állománynak majdnem pontosan meg kell egyeznie a rendszerünkben található /usr/src/sys/i386/conf/GENERIC állománnyal. a rendszermag beállításai machine machine i386 A számítógépünk architektúráját adja meg. A következõk valamelyikének kell lennie: alpha, amd64, i386, ia64, pc98, powerpc, vagy sparc64. a rendszermag beállításai cpu cpu I486_CPU cpu I586_CPU cpu I686_CPU A fenti beállítás segítségével megadhatjuk, milyen típusú processzor található a számítógépünkben. Több ilyen sorunk is lehet (ha például nem lennénk biztosak benne, hogy a I586_CPU vagy I686_CPU értéket kellene megadnunk), de a saját rendszermagunk összeállításához érdemes csak egyet meghagynunk. Ha nem ismerjük pontosan a processzorunk típusát, vessünk egy pillantást a /var/run/dmesg.boot állományra és keressük ki belõle. a rendszermag beállításai ident ident GENERIC Ez a rendszermag azonosítója. Változtassuk meg rendszermagunk nevére, legyen például SAJAT, ha a korábbi utasításokat követtük. Az ident után írt sztring fog megjelenni a rendszermag neve mellett a rendszer indítása során, ezért fontos, hogy az új rendszermagunknak más nevet adjunk, ha meg akarjuk különböztetni az általában használttól (például egy tesztelésre szánt rendszermagot akarunk készíteni). # ha a /boot/device.hints használata helyett statikusan bele akarjuk fordítani #hints "GENERIC.hints" # itt szerepelnek a device hintek A &man.device.hints.5; használható az eszközmeghajtók beállítására. A &man.loader.8; a rendszer indítása során alapértelmezés szerint a /boot/device.hints állományt olvassa be erre a célra. A hints beállítás használatával ezeket a hinteket statikusan bele tudjuk építeni a rendszermagba. Ebben az esetben nincs szükségünk külön device.hints állomány létrehozására a /boot könyvtárban. makeoptions DEBUG=-g # a nyomkövetéshez szükséges gdb(1) szimbólumok beépítése A &os; hagyományos fordításának folyamata során a rendszermagot a használatával készítjük el, aminek köszönhetõen hibakeresési információkat tudunk átadni a &man.gcc.1; fordítónak. options SCHED_4BSD # 4BSD ütemezõ A &os; tradicionális és alapértelmezett rendszerütemezõje. Ne változtassuk meg! options PREEMPTION # a rendszerszálak megszakíthatóságának engedélyezése Ha engedélyezzük, a rendszermagban futó szálakat meg tujdák szakítani más, magasabb prioritású szálak. Ez segít növelni a rendszer válaszadási sebességét és csökkenti a megszakításokat kezelõ szálak várakozását. options INET # hálózatkezelés A hálózatkezelés támogatása. Ne töröljük ki, még akkor sem, ha nem tervezzük hálózatra kapcsolni a rendszert. Sok programnak szüksége van legalább az ún. loopback típusú hálózat támogatására (vagyis a számítógépünkön belüli hálózati kapcsolatokra), ezért ez feltétlenül kötelezõ! options INET6 # IPv6 kommunikációs prokotollok Engedélyezi az IPv6 kommunikációs protokollok használatát. options FFS # Berkeley Fast Filesystem Ez a legalapvetõbb merevlemezes állományrendszer. Hagyjuk meg, ha merevlemezrõl akarjuk indítani a rendszerünket. options SOFTUPDATES # az FFS Soft Updates támogatása Ez a beállítás engedélyezi a rendszermagban a Soft Updates használatát, amely segít felgyorsítani a lemez írási sebességét. Ha már a rendszermag ezt a funkcionalitást ismeri, akkor még külön az egyes lemezeken is engedélyezni kell. Nézzük meg a &man.mount.8; kimenetét, hogy lássuk, a rendszerünkben levõ lemezek közül melyiken van ténylegesen engedélyezve a Soft Updates használata. Ha nem látjuk benne sehol sem a soft-updates opciót, akkor azt (meglevõ állományrendszerek esetén) a &man.tunefs.8; vagy (új állományrendszerek esetén) a &man.newfs.8; parancsokkal tudjuk bekapcsolni. options UFS_ACL # a hozzáférés-vezérlési listák (ACL) támogatása Ezzel a beállítással engedélyezhetjük a rendszermagban a hozzáférés-vezérlési listák támogatását. Ez a kiterjesztett attribútumok és az UFS2 használatára támaszkodik. Ezt a lehetõséget részleteiben a ban tárgyaljuk. Az ACL alapértelmezés szerint támogatott, és korábban már használtuk, akkor semmiképpen se kapcsoljuk ki, mert ezzel az eddig létrehozott hozzáférés-vezérlési listáink érvénytelenné, az állományaink pedig védtelenné válnak. options UFS_DIRHASH # nagyobb könyvtárak esetén gyorsulást hoz Ezzel a beállítással némi memória feláldozása árán fel tudjuk gyorsítani a nagyobb könyvtárakon végzett lemezmûveletek sebességét, ezért ezt a beállítást érdemes nagyobb szerverekre vagy interaktívitást igénylõ munkaállomásokra tartogatni, és eltávolítani olyan esetekben, amikor a &os;-t egy olyan kisebb számítógépeken használjuk, ahol a memória kevés és a lemezmûveletek sebessége kevésbé fontos, például egy tûzfalon. options MD_ROOT # tudunk memórialemezrõl is rendszert indítani Ezzel az opcióval engedélyezni tudjuk a rendszer indítását memóriában tárolt virtuális lemezekrõl. a rendszermag beállításai NFS a rendszermag beállításai NFS_ROOT options NFSCLIENT # hálózati állományrendszer (NFS) kliens options NFSSERVER # NFS szerver options NFS_ROOT # NFS használható gyökérként is, kell hozzá az NFSCLIENT A hálózati állományrendszer támogatása. Hacsak nem akarunk TCP/IP-n keresztül állományrendszereket csatlakoztatni egy &unix; állományszerverrõl, kivethetjük. a rendszermag beállításai MSDOSFS options MSDOSFS # MS-DOS állományrendszer Az &ms-dos; állományrendszer. Hacsak nem akarunk DOS-ra formázott merevlemezes partíciót csatlakoztatni a rendszerindítás során, nyugodtan elhagyhatjuk. A fentebb leírtak szerint az elsõ olyan alkalommal automatikusan betöltõdik, amikor egy DOS partíciót csatlakoztatni akarunk. Sõt, a nagyszerû emulators/mtools szoftver segítségével külön csatlakoztatás és leválasztás nélkül tudunk DOS-os floppykat olvasni (és az MSDOSFS-re egyáltalán nincs is szüksége). options CD9660 # ISO 9660 állományrendszer Az ISO 9660 állományrendszert a CD-k használják. Vegyük ki, ha nincs a számítógépben CD-ROM meghajtó vagy csak ritkán fogunk CD-ket csatlakoztatni (mivel a hozzátartozó modul magától betöltõdik az elsõ adat CD csatlakoztatása során). Az audio CD-k nem használják ezt az állományrendszert. options PROCFS # a futó programok állományrendszere (szükséges hozzá a PSEUDOFS) A futó programok állományrendszere. Ez csak a /proc könyvtárra csatlakoztatott színlelt állományrendszer, amely segítségével a &man.ps.1; és hozzá hasonló programok képesek több információt adni a futó programokról. A PROCFS használata a legtöbb esetben nem indokolt, mivel a különféle nyomkövetõ és felügyeleti eszközök képesek a PROCFS használata nélkül is mûködni: alapértelmezés szerint a telepített rendszerek sem csatlakoztatják ezt az állományrendszer. options PSEUDOFS # pszeudo állományrendszerek támogatása A 6.X verziójú rendszermagokban a PROCFS használatához engedélyeznünk kell a PSEUDOFS használatát is. options GEOM_GPT # GUID típusú partíciós táblák használata Ezzel a beállítással engedélyezni tudjuk nagy mennyiségû partíció támogatását egyetlen lemezen. options COMPAT_43 # kompatibilitás fenntartása a 4.3 BSD-vel [NE TÖRÖLD!] Kompatibilitás a 4.3BSD-vel. Ne vegyük ki, mert bizonyos programok furcsán fognak viselkedni a hiánya esetén. options COMPAT_FREEBSD4 # kompatibilitás a &os;4-el Ez a beállítás szükséges a &os; 5.X &i386; és Alpha rendszerein a &os; korábbi verzióihoz fordított alkalmazások támogatásához, melyek régebbi rendszerhívásokat használnak. Az összes &i386; és Alpha típusú rendszeren ajánlott engedélyezni, mivel itt elõfordulhatnak régebbi alkalmazások. A többi platform, mint például az ia64 vagy a &sparc64;, támogatása csak az 5.X verzióban jelent meg, ezért ott nincs szükség erre. options COMPAT_FREEBSD5 # kompatibilitás a &os;5-el Ezt a beállítást a &os; 6.X és afeletti verziókban kell használni az olyan &os; 5.X verziókra fordított alkalmazások futtatásának támogatásához, melyek a &os; 5.X rendszerhívásait használják. options SCSI_DELAY=5000 # a SCSI eszközök keresése elõtt késleltetés (ezredmásodpercben) Ezzel a beállítással a rendszermag 5 másodpercig várakozni fog a SCSI eszközök keresése elõtt. Ha kizárolag csak IDE típusú merevlemezeink vannak, nyugodtan kihagyhatjuk, máskülönben érdemes a rendszerindítás gyorsítása érdekében próbáljuk meg csökkenteni ezt az értéket. Természetesen, ha így teszünk és a &os; nem tudja felismerni a SCSI eszközeinket, akkor növeljük meg valamennyivel. options KTRACE # a ktrace(1) támogatása Engedélyezi a rendszermagban futó rutinok nyomonkövetését, ami hasznos lehet a hibák keresése során. options SYSVSHM # SYSV-szerû osztott memória Ezzel a beállítással engedélyezni tudjuk a rendszerben a System V típusú osztott memória használatát. Leggyakrabban az X rendszer XSHM kiterjesztése használja, amelyen keresztül számos mûveletigényes grafikus program mûködését fel lehet gyorsítani. Ha X-et használunk, mindenképpen szükségünk lehet erre. options SYSVMSG # SYSV-szerû üzenetsorok A System V üzenetek támogatása. Ez a beállítás csupán néhány száz byte-tal növeli a rendszermagot. options SYSVSEM # SYSV-szerû szemaforok A System V szemaforok támogatása. Nem túl gyakran alkalmazzák ezeket, de ez csak néhány száz byte-ot tesz hozzá a rendszermaghoz. A &man.ipcs.1; parancs paraméterével ki tudjuk listáztatni azokat futó programokat, amelyek ezen System V eszközöket használják. options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B valósidejû kiterjesztések A &posix; 1993-as változatában megjelent valósidejû bõvítések. A Portgyûjteményben megjelenõ egyes alkalmazások használják ezeket (mint például a &staroffice;). options KBD_INSTALL_CDEV # CDEV bejegyzés létrehozása a /dev könyvtárban Ez a beállítás kell ahhoz, hogy /dev könyvtárban létre tudjunk hozni eszközleírókat a billentyûzethez. options ADAPTIVE_GIANT # adaptív Giant mutexek A Giant annak a kölcsönös kizárási mechanizmusnak (blokkolt mutexnek) a neve, amely a rendszermag erõforrásainak jelentõs részét védi. Manapság ez már egy elfogadhatatlanul szûk keresztmetszet képez a teljesítményben, ezért a fejlesztésben fokozatosan felváltják az egyes erõforrásokat külön-külön védõ zárolások. Az ADAPTIVE_GIANT beállítás hatására a Giant a helyzethez igazodóan forgó (spin) mutexek közé kerül. Ez azt jelenti, hogy amikor egy szál zárolni akarja a Giant mutexet, de ezt már megtette elõtte egy másik processzorról futó szál, a szál tovább fut és várakozni fog a zárolás feloldására. Normális esetben ugyanis egy szál továbbra is blokkolt állapotban marad, várakozva a futásra. Ha nem tudunk dönteni, hagyjuk változatlanul. Hozzátesszük, hogy a &os; 8.0-CURRENT és késõbbi változataiban az össszes mutex alapértelmezés szerint adaptív, hacsak meg nem adjuk a NO_ADAPTIVE_MUTEXES beállítást. Ennek eredményeképpen a Giant most már alapból adaptív, ezért esetükben az ADAPTIVE_GIANT nem szerepel a rendszermag beállításai között. a rendszermag beállításai SMP device apic # I/O APIC Az apic nevû eszköz engedélyezésével használhatjuk a hardveres APIC-ot a megszakítások vezérlésére. Az apic alkalmazható egy- és többprocesszoros rendszerek esetén is egyaránt, de az SMP rendszermagoknál szükséges. Több processzor támogatásánál mindenképpen tegyük hozzá az options SMP beállítást is. Az apic eszköz csak az i386 architektúrán létezik, ezért a többi architektúrán nem szabad használnunk ezt a beállítást. device eisa Abban az esetben engedélyezzük, ha EISA-s alaplapunk van, ezzel aktiváljuk az EISA buszra csatlakoztatott eszközök automatikus felismerését és beállíthatóságát. device pci Tegyük hozzá a konfigurációs állományhoz, ha PCI-os alaplapuk van. Ezzel engedélyezhetjük a PCI kártyák automatikus felismerését és a PCI és ISA buszok közti átirányítást. # Hajlékonylemezes meghajtók device fdc Ez a hajlékonylemezes meghajtó vezérlõje. # ATA és ATAPI eszközök device ata Ez az eszközmeghajtó felelõs az összes ATA és ATAPI eszközért. A modern számítógépeken csak egyszer kell megadnunk a device ata sort a beállítások között az összes PCI-os ATA/ATAPI eszköz felismeréséhez. device atadisk # ATA lemezmeghajtók Az ATA lemezmeghajtók támogatásához erre van még szükség a device ata mellett. device ataraid # ATA RAID-meghajtók Az ATA RAID-meghajtók kezeléséhez erre a sorra van szükség a device ata mellett. device atapicd # ATAPI CD-meghajtók Az ATAPI CD-meghajtók használatához ezt is tegyük a konfigurációba a device ata mellé. device atapifd # ATAPI floppy meghajtók A device ata használata mellett erre van még szükségünk az ATAPI floppy meghajtók kezeléséhez. device atapist # ATAPI szalagos meghajtók Az ATAPI szalagos egységek ezt a sort is tegyük a konfigurációba a device ata mellé. options ATA_STATIC_ID # statikus eszközszámozás Ezzel a beállítással a vezérlõk számozása állandó lesz. Nélküle az eszközszámok dinamikusan kerülnek kiosztásra. # SCSI vezérlõk device ahb # EISA AHA1742 család device ahc # AHA2940 és integrált AIC7xxx eszközök options AHC_REG_PRETTY_PRINT # a hibák kereséséhez kiíratja a regiszterek # bitmezõit. Kb. 128 KB-al növeli a méretét. device ahd # AHA39320/29320 és integrált AIC79xx eszközök options AHD_REG_PRETTY_PRINT # a hibák kereséséhez kiíratja a regiszterek # bitmezõit. Kb. 215 KB-al növeli a méretét. device amd # AMD 53C974 (Teckram DC-390(T)) device isp # Qlogic család #device ispfw # a QLogic HBA firmware-e, többnyire modul device mpt # LSI-Logic MPT-Fusion #device ncr # NCR/Symbios Logic device sym # NCR/Symbios Logic (újabb chipsetek, illetve az `ncr' típusúak) device trm # Tekram DC395U/UW/F DC315U csatolók device adv # Advansys SCSI-csatolók device adw # Advansys wide SCSI-csatolók device aha # Adaptec 154x SCSI-csatolók device aic # Adaptec 15[012]x SCSI-csatolók, AIC-6[23]60. device bt # Buslogic/Mylex MultiMaster SCSI-csatolók device ncv # NCR 53C500 device nsp # Workbit Ninja SCSI-3 device stg # TMC 18C30/18C50 SCSI-vezérlõk. Vegyük ki azokat, amelyekkel ténylegesen nem rendelkezünk. Ha csak IDE eszközeink vannak a rendszerünkben, az összeset eltávolíthatjuk. A _REG_PRETTY_PRINT végzõdésû sorok a megfelelõ meghajtók hibakerési beállításait takarják. # SCSI-perifériák device scbus # SCSI-busz (kell a SCSI-hoz) device ch # SCSI médiumváltók (media changer) device da # közvetlen hozzáférés (lemezek) device sa # soros hozzáférés (szalag stb.) device cd # CD device pass # áteresztõ eszköz (közvetlen SCSI hozzáférés) device ses # SCSI környezeti szolgáltatások (és SAF-TE) SCSI-perifériák. Itt is érvényes, hogy kivethetjük azokat az eszközöket, amelyekkel nem rendelkezünk. De ha csak IDE hardvereink vannak, teljesen eltávolíthatjuk ezeket. Annak ellenére, hogy valójában nem igazi SCSI-eszközök, az USB-s &man.umass.4; és még néhány más egyéb meghajtó is használja a SCSI alrendszert. Emiatt semmiképpen se távolítsuk el a SCSI támogatást a rendszerünkõl abban az esetben, ha ilyen meghajtókat is használni szándékozunk. # a SCSI alrendszerhez kapcsolódó RAID-vezérlõk device amr # AMI MegaRAID device arcmsr # Areca SATA II RAID device asr # DPT SmartRAID V, VI és Adaptec SCSI RAID device ciss # Compaq Smart RAID 5* device dpt # DPT Smartcache III, IV - lásd a NOTES állományt device hptmv # Highpoint RocketRAID 182x device rr232x # Highpoint RocketRAID 232x device iir # Intel Integrated RAID device ips # IBM (Adaptec) ServeRAID device mly # Mylex AcceleRAID/eXtremeRAID device twa # 3ware 9000 series PATA/SATA RAID # RAID vezérlõk device aac # Adaptec FSA RAID device aacp # SCSI áteresztõ az aac-hez (kell hozzá a CAM) device ida # Compaq Smart RAID device mfi # LSI MegaRAID SAS device mlx # Mylex DAC960 család device pst # Promise Supertrak SX6000 device twe # 3ware ATA RAID Az ismert RAID-vezérlõk. Ha közülük egyikkel sem rendelkezünk, távolítsuk el ezeket a konfigurációból. # az atkbdc0 vezérli a billentyûzetet és a PS/2-es egeret device atkbdc # AT billentyûzet vezérlõ A billentyûzet vezérlõje (atkbdc) az AT-s billentyûzet és a PS/2 stílusú pozícionáló eszközök vezérléséhez szükséges I/O szolgáltatásokat biztosítja. Erre a vezérlõre a billentyûzet meghajtójának (atkbd) és a PS/2 pozícionáló eszközök eszközmeghajtójának (psm) is szüksége van. device atkbd # AT billentyûzet Az atkbd meghajtó, a atkbdc vezérlõvel együtt, adja a hozzáférést az AT billentyûzet vezérlõre csatlakoztatott AT 84 és a fejlettebb AT billentyûzetek felé. device psm # PS/2 egér Használjuk ezt az eszközt, ha az egerünk a PS/2 portra csatlakozik. device kbdmux # billentyûzet multiplexer A billentyûzet multiplexer alapszintû támogatása. Ha nem kívánunk a jövõben egynél több billentyûzetet csatlakoztatni a rendszerünkre, nyugodt szívvel kivehetjük ezt a sort. device vga # VGA videokártya meghajtó Videokártya meghajtó. device splash # üdvözlõképernyõk és képernyõkímélõk támogatása Nyissunk egy üdvözlõképernyõvel! A képernyõkímélõknek is szüksége van erre az eszközre. # a syscons az alapértelmezett konzolmeghajtó, hasonlít a SCO konzolra device sc Az sc az alapértelmezett meghajtó a konzolok számára, és sokban hasonlít a SCO konzolra. Mivel a legtöbb teljesképernyõs program a termcap termináladatbázis könyvtáron keresztül éri el a konzolt, nem igazán számít, hogy ezt vagy a VT220-kompatibilis vt konzolmeghajtót használjuk. Ha bármilyen gondunk lenne a teljesképernyõs programok futtatásával ezen a konzolon, a bejelentkezéskor állítsuk a TERM környezeti változónk a scoansi értékre. # ezzel tudjuk engedélyezni a pcvt (VT220-kompatibilis) konzolmeghajtót #device vt #options XSERVER # az X szerver támogatása vt konzolon #options FAT_CURSOR # telt kurzor használata Ez a VT220-kompatibilis konzolmeghajtó, amely visszafele kompatibilis a VT100/102-vel is. Remekül mûködik olyan laptopokon, ahol a hardver nem használható az sc konzollal. Itt ugyanúgy érdemes egyébként a vt100 értékre vagy a vt220 értékre állítani a TERM környezeti változónkat. Hasznosnak bizonyulhat abban az esetben is, amikor hálózaton keresztül nagy mennyiségû és eltérõ típusú számítógépekhez csatlakozunk, és ahol a termcap és terminfo adatbázisokban az sc bejegyzései gyakran nem is érhetõek el — a vt100 viszont virtuálisan az összes platformon elérhetõ. device agp Írjuk bele a konfigurációba, ha van AGP kártya a rendszerünkben. Ezzel engedélyezzük az AGP és az AGP GART támogatását az ezeket ismerõ kártyák számára. APM # energiagazdálkodás támogatása (bõvebben lásd: NOTES) #device apm A fejlett energiagazdálkodás támogatása. Laptopok esetén hasznos, habár ez alapértelmezés szerint nincs engedélyezve a GENERIC konfigurációban. # az i8254 készenléti módjának támogatása device pmtimer Az energiagazdálkodási események, mint például APM és ACPI idõzítõjének eszközmeghajtója. # PCCARD (PCMCIA) támogatás # PCMCIA és cardbus támogatás device cbb # cardbus (yenta) bridge device pccard # PC Card (16 bites) busz device cardbus # CardBus (32 bites) busz A PCMCIA támgotása. Mindenképpen szükségünk lesz rá, ha laptopunk van. # soros (COM) portok device sio # 8250, 16[45]50 alapú soros portok Ezek azok a soros portok, amelyek az &ms-dos;/&windows; világban csak COM portokként ismernek. Ha van egy belsõ modemünk a COM4-en és egy soros portunk a COM2-n, a modem IRQ-ját meg kell változtatnunk 2-re (valamilyen homályos mûszaki októl kifolyólag a COM2 = IRQ9), hogy hozzá tudjunk férni &os;-bõl. Ha többportos soros kártyánk lenne, lapozzuk fel a &man.sio.4; man oldalát, és ott hozzá megtaláljuk a /boot/device.hints állományba írandó megfelelõ értékeket. Egyes videokártyák (különösen az S3 chipekre épülõk) az I/O címeket 0x*2e8 alakban használják, és mivel rengeteg olcsó soros kártya nem kódolja vissza egészében a 16 bites I/O címteret, ütközni fognak ezekkel a kártyákkal, és ezáltal a COM4 port gyakorlatilag elérhetetlenné válik. Minden egyes soros portnak egyedi IRQ-ja kell legyen (hacsak nem használunk olyan többportos kártyát, amely támogatja a megosztott megszakításokat), ezért a COM3 és COM4 esetén alapértelmezett IRQ-k nem használhatóak. # párhuzamos port device ppc Ez az ISA busz párhuzamos portjának felülete. device ppbus # a párhuzamos port busza (kell) A párhuzamos porthoz tartozó busz támogatása. device lpt # nyomtató A párhuzamos portra csatlakozó nyomtatók támogatása. A fentiek közül mind a három szükséges a párhuzamos porton csatlakozó nyomtatók használatához. device plip # TCP/IP párhuzamos porton keresztül Ez a párhuzamos port hálózati felületének meghajtója. device ppi # a párhuzamos port felületének eszköze Általános célú (geek port) és IEEE1284 I/O. #device vpo # az scbus és a da kell a használatához zip meghajtó Ez az Iomega Zip meghajtóihoz tartozó eszköz. A mûködéséhez szükség van az scbus és da engedélyezésére. A legjobb teljesítményt EPP 1.9 módban mûködõ portokkal lehet kihozni belõle. #device puc Tegyük bele a konfigurációba ezt az eszközt, ha egy olyan buta soros vagy párhuzamos PCI kártyánk van, amelyet a &man.puc.4; segédmeghajtó ismer. # PCI Ethernet kártyák device de # DEC/Intel DC21x4x (Tulip) device em # Intel PRO/1000 Gigabit Ethernet kártya device ixgb # Intel PRO/10GbE Ethernet kártya device txp # 3Com 3cR990 (Typhoon) device vx # 3Com 3c590, 3c595 (Vortex) Különféle PCI hálózati kártyák meghajtói. Vegyük ki azokat, amelyek nem találhatóak meg a rendszerünkben. # PCI Ethernet kártyák, melyek az MII busz vezérlõkódját használják # FIGYELEM: Ne töröljük ki a 'device miibus' sort, ha ilyen kártyánk van! device miibus # az MII busz támogatása Az MII busz engedélyezése elengedhetetlen bizonyos 10/100-as PCI Ethernet kártyák használatához, konkrétan azokéhoz, amelyek az MII-vel együttmûködni képes adó-vevõt használnak vagy az MII-höz hasonló adó-vevõ vezérlõ felületet valósítanak meg. A device miibus hozzáadása a rendszermaghoz magával vonja az általános miibus API és az összes PHY meghajtó támogatását, beleértve azt az általános PHY eszközt is, amelyet az egyes eszközmeghajtók külön nem támogatnak. device bce # Broadcom BCM5706/BCM5708 Gigabit Ethernet device bfe # Broadcom BCM440x 10/100 Ethernet device bge # Broadcom BCM570xx Gigabit Ethernet device dc # DEC/Intel 21143 és egyéb hasonlóak device fxp # Intel EtherExpress PRO/100B (82557, 82558) device lge # Level 1 LXT1001 gigabit ethernet device msk # Marvell/SysKonnect Yukon II Gigabit Ethernet device nge # NatSemi DP83820 gigabit ethernet device nve # nVidia nForce MCP integrált Ethernet hálózat device pcn # AMD Am79C97x PCI 10/100 (az 'lnc' elõtt) device re # RealTek 8139C+/8169/8169S/8110S device rl # RealTek 8129/8139 device sf # Adaptec AIC-6915 (Starfire) device sis # Silicon Integrated Systems SiS 900/SiS 7016 device sk # SysKonnect SK-984x & SK-982x gigabit Ethernet device ste # Sundance ST201 (D-Link DFE-550TX) device stge # Sundance/Tamarack TC9021 gigabit Ethernet device ti # Alteon Networks Tigon I/II gigabit Ethernet device tl # Texas Instruments ThunderLAN device tx # SMC EtherPower II (83c170 EPIC) device vge # VIA VT612x gigabit ethernet device vr # VIA Rhine, Rhine II device wb # Winbond W89C840F device xl # 3Com 3c90x (Boomerang, Cyclone) Meghajtók, melyek az MII busz vezérlõkódját használják. # ISA Ethernet és pccard hálózati kártyák. device cs # Crystal Semiconductor CS89x0 NIC # az 'device ed' eszközhöz kell a 'device miibus' device ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards device ex # Intel EtherExpress Pro/10 és Pro/10+ device ep # Etherlink III alapú kártyák device fe # Fujitsu MB8696x alapú kártyák device ie # EtherExpress 8/16, 3C507, StarLAN 10 stb. device lnc # NE2100, NE32-VL Lance Ethernet kártyák device sn # az SMC 9000-res sorozatú Ethernet chipjei device xe # Xircom pccard Ethernet # ISA eszközök, melyek a régi ISA betétet használják #device le ISA Ethernet meghajtók. A konkrétan támogatott kártyák teljes felsorolását lásd a /usr/src/sys/i386/conf/NOTES állományban. # vezeték nélküli hálózati kártyák device wlan # 802.11 támogatás Általános 802.11 támogatás. Erre a sorra mindenképpen szükség van a vezeték nélküli hálózatok használatához. device wlan_wep # 802.11 WEP támogatás device wlan_ccmp # 802.11 CCMP támogatás device wlan_tkip # 802.11 TKIP támogatás A 802.11 eszközök esetén a titkosítás támogatása. Ezeket a sorokat akkor adjuk meg, ha titkosítást akarunk használni vagy a 802.11i biztonsági protokolljait. device an # Aironet 4500/4800 802.11 vezeték nélküli hálózati kártyák device ath # Atheros pci/cardbus hálózati kártyák device ath_hal # Atheros HAL (Hardware Access Layer) device ath_rate_sample # küldési mintavételi vezérlés az ath-hoz device awi # BayStack 660 és mások device ral # Ralink Technology RT2500 vezeték nélküli hálózati kártyák device wi # WaveLAN/Intersil/Symbol 802.11 vezeték nélküli hálózati kártyák #device wl # régebbi, nem 802.11 Wavelan vezeték nélküli hálózati kártyák A különbözõ vezeték nélküli kártyák támogatása. # Pszeudo eszközök device loop # hálózati loopback Ez a TCP/IP általános loopback eszköze. Ha telnettel vagy FTP-vel rácsatlakozunk a localhost címére (vagyis a 127.0.0.1-re), akkor rajta keresztül saját magunkhoz jutunk vissza. Ennek a megléte kötelezõ! device random # álvéletlenszám eszköz Kriptográfiai szempontból biztonságos álvéletlenszám generátor. device ether # Ethernet támogatás Az ether eszközre csak abban az esetben van szükség, ha Ethernet kártyán van. Ez magában foglalja az általános Ethernet protokoll kódját. device sl # belsõ SLIP Az sl a SLIP használatát engedélyezi. Ez egy régi protokoll, amelyet azóta már szinte teljesen kiszorított a PPP, mivel azt könnyebb beállítani és sokkal jobban is illik a modem-modem kapcsolatokhoz, illetve sokkal erõteljesebb. device ppp # belsõ PPP Ez a tárcsázós kapcsolatok rendszermagon belüli PPP támogatását adja meg. Van a PPP-nek egy külsõ, a felhasználói programként megvalósított változata is, amely a tun eszközt használja és sokkal nagyobb rugalmasságot kínál fel, illetve olyan lehetõségeket, mint például az igény szerinti tárcsázás. device tun # csomag alagút Ezt a felhasználói PPP szoftver használja. A könyv PPP-rõl szóló részében többet is megtudhatunk róla. device pty # Pszeudo terminálok (telnet stb.) Ezek a pszeudo terminálok vagy más néven szimulált bejelentkezési portok. A bejövõ telnet és rlogin munkamenetek használják, valamint az xterm és a hozzá hasonló alkalmazások, mint például az Emacs. device md # memórialemezek A memóriában levõ pszeudo lemezes meghajtók. device gif # IPv6 és IPv4 tunnelek használata Megvalósítja az IPv6 IPv4 feletti, az IPv4 IPv6 feletti, az IPv4 IPv4 feletti és az IPv6 IPv6 feletti közvetítését. A gif eszköz magától másolódik, vagyis szükség szerint hozza létre a megfelelõ eszközleírókat. device faith # IPv6-IPv4 közti továbbítás (fordítás) Ez a pszeudo eszköz elfogja a hozzá küldött csomagokat és átadja ezeket az IPv4/IPv6 fordítással foglalkozó démonnak. # a `bpf' eszköz használatával a Berkeley csomagszûrõt (Berkeley Packet Filter) engedélyezzük # Legyünk rá tekintettel, hogy ennek komoly következményei lehetnek # rendszeradminisztrációs szempontból! # A 'bpf'-re szükség van a DHCP-hez. device bpf # Berkeley csomagszûrõ A Berkeley csomagszûrõje. Ez egy olyan pszeudo eszköz, amely lehetõvé teszi, hogy a hálózati csatolók forgalmát megfigyeljük, mivel a (pl. Ethernet) hálózatunkon minden csomagot elkap. Ezek a csomagok lemezre is menthetõek vagy kielemezhetõek a &man.tcpdump.1; program segítségével. A &man.bpf.4; eszközt a &man.dhclient.8; is használja többek közt az alapértelmezett átjáró IP-címének megszerzéséhez. Ha DHCP-t akarunk használni, hagyjuk így. # USB támogatás device uhci # UHCI PCI->USB felület device ohci # OHCI PCI->USB felület device ehci # EHCI PCI->USB felület (USB 2.0) device usb # USB busz (kell) #device udbp # USB Double Bulk Pipe eszközök device ugen # általános device uhid # Human Interface Devices device ukbd # billentyûzet device ulpt # nyomtató device umass # lemez/háttértároló - kell hozzá az scbus és a da device ums # egér device ural # Ralink Technology RT2500USB vezeték nélküli hálózati kártyák device urio # Diamond Rio 500 MP3 lejátszó device uscanner # lapolvasók # USB Ethernet, kell hozzá az mii device aue # ADMtek USB Ethernet device axe # ASIX Electronics USB Ethernet device cdce # általános USB, Etherneten keresztül device cue # CATC USB Ethernet device kue # Kawasaki LSI USB Ethernet device rue # RealTek RTL8150 USB Ethernet A különféle USB eszközök támogatása. # FireWire támogatás device firewire # FireWire buszkód device sbp # SCSI FireWire-ön keresztül (kell hozzá az scbus és a da) device fwe # Ethernet FireWire-ön keresztül (nem szabványos!) A különféle Firewire eszközök támogatása. A &os; által ismert további eszközökrõl a /usr/src/sys/i386/conf/NOTES állományból tájékozódhatunk. Sok memória kezelése (<acronym>PAE</acronym>) Fizikai címkiterjesztés (PAE) sok memória A sok memóriával rendelkezõ számítógépek esetén szükség lehet a felhasználói és rendszerszintû virtuális címek (Kernel Virtual Address, KVA) 4 gigabyte feletti használatára. Ennek a korlátozásnak a kiküszöbölésére az &intel; külön támogatást épített be a &pentium; Pro és az azt követõ processzorok 36 bites fizikai címzésének kialakításához. A Fizikai Címkiterjesztés (Physical Address Extension, PAE) az &intel; &pentium; Pro és késõbbi processzoraiban található meg, és lehetõvé teszi egészen 64 gigabyte-ig a memóriahasználatot. A &os; is támogatja ezt a tulajdonságot a rendszermag beállítás használatával, és megtalálható a &os; összes jelenlegi verziójában. Az &intel; architektúrájú processzorok memóriaszervezésének korlátai miatt nem különböztethetõ meg a 4 gigabyte alatti és feletti memória. A 4 gigabyte felett található memóriaterületek egyszerûen hozzáadódnak a rendelkezésre álló memóriához. A rendszermagban a PAE támogatását egyszerûen az alábbi sor segítségével hozzáadásával tudjuk engedélyezni: options PAE A &os;-ben a PAE támogatása csak az &intel; IA-32 architektúrájú processzoraihoz érhetõ el. Emellett meg kell említenünk, hogy a &os;-ben található PAE támogatás nem lett szélesebb körben próbára téve, ezért a &os; többi megbízható elemeihez képest csak béta állapotúnak tekinthetõ. A &os; PAE támogatásának van néhány hiányossága: Egy futó program a virtuális memóriában nem képes 4 gigabyte-nál többet elérni. A KLD modulok nem tölthetõek be egy PAE-t támogató rendszermagba, mivel eltérnek a modulok és a rendszermag létrehozásának módszerei. A &man.bus.dma.9; felületet nem használó eszközmeghajtók adathibákat okozhatnak a PAE-t támogató rendszermagokban, és emiatt nem ajánljuk a használatukat. Ebbõl a megfontolásból készítettünk egy PAE nevû konfigurációs állományt a &os;-hez, amelyben nem szerepel egyetlen olyan meghajtó sem, amely ismereteink szerint nem mûködik együtt a PAE-t támogató rendszermagokkal. Bizonyos finomhangolási beállítások a memóriahasználatot a rendelkezésre álló fizikai memória mennyiségébõl számítják ki. A PAE támogatással mûködõ rendszerek esetében megjelenõ sok memória miatt azonban az ilyen eszközök szükségtelenül több területet foglalhatnak le. Erre példa lehet a sysctl változó, amely a rendszermag által maximálisan felhasználható virtuális csomópontok számát korlátozza. Ajánlott tehát az ilyen és ehhez hasonló beállítások értelmes értékre történõ visszaállítása. Szükséges lehet a rendszermag virtuális címterének (KVA) növelése vagy a rendszermag által túlságosan nagy méretûre foglalt címterû különféle erõforrások (lásd fentebb) csökkentése a KVA kifogyásának elkerülésére. A KVA területének növelését a beállításával tehetjük meg. Ha gondjaink lennének a teljesítménnyel vagy a megbízhatósággal, keressük fel a &man.tuning.7; man oldalt. A &man.pae.4; man oldalon pedig a &os; PAE támogatásáról találhatunk naprakész információkat. Ha valamilyen hiba történne Négyféle probléma jelentkezhet egy saját rendszermag készítése során. Ezek: A config hibát jelez: Amikor a &man.config.8; parancs hibát jelez vissza a rendszermagunk konfigurációs beállításainak feldolgozása során, akkor minden bizonnyal csak egy apró hibát vétettünk valahol. Szerencsére a &man.config.8; kiírja a hibás sor számát, ezért gyorsan fel tudjuk kutatni a hibát tartalmazó sort. Például, ha ezt látjuk: config: line 17: syntax error Akkor gyõzödjünk meg róla, hogy helyesen írtuk be az adott sorban szereplõ kulcsszót. Ebben segítségünkre lehet, ha összevetjük a GENERIC konfigurációs állománnyal vagy más hivatkozásokkal. A make hibát jelez: Ha a make jelez hibát, az általában arra utal, hogy az általunk korábban megadott rendszermag konfigurációs állományt a &man.config.8; nem értette meg rendesen. Megint azt tudjuk csak javasolni, hogy nézzük át a konfigurációs beállításainkat, és ha ezután sem sikerül megoldani a problémát, akkor mellékeljük egy levélben a rendszermagunk konfigurációs beállításait és küldjük el a &a.questions; címére, ahol a hozzáértõk gyorsan átnézik. A rendszermag nem indul: Ha az új rendszermagunk nem indul vagy nem képes felismerni az eszközeinket, ne essünk kétségbe! Szerencsére a &os; tökéletes megoldással tud szolgálni az összeférhetetlen rendszermagok esetére: a &os; rendszerbetöltõjében egyszerûen válasszuk ki az indítandó rendszermagot. Ezt akkor tudjuk elõhívni, amikor a rendszerindító menü megjelenik. Válasszuk ki a hatos, vagyis az Escape to a loader prompt (a betöltõ parancssorának elõhívása) menüpontot. Mikor megjelenik a parancssor, írjuk be, hogy unload kernel, majd adjuk ki a boot /boot/kernel.old/kernel, parancsot, amiben bármilyen más olyan rendszermagot is megnevezhetünk, ami korábban már mûködött. Ezért amikor beállítunk egy új rendszermagot, mindig érdemes a kezünk ügyében tartani legalább egy olyan rendszermagot, amely mûködik. Miután sikerült elindítanunk az egyik használható rendszermagot, nézzük át még egyszer a konfigurációs állományt és próbáljuk újra lefordítani a rendszermagot. A probléma megoldását segítheti a /var/log/messages állomány áttanulmányozása is, ami többek közt rögzíti a rendszermag sikeres indulása során keletkezõ üzeneteket. Ezenkívül a &man.dmesg.8; parancs is meg tudja jeleníteni az aktuális rendszerindítás üzeneteit. Ha gondok merülnének fel a rendszermag elkészítése során, mindenképpen tartsuk meg a GENERIC, vagy bármilyen másik olyan rendszermagot, amelyrõl tudjuk, hogy mûködik. Nevezzük át, így nem fog felülíródni a következõ fordítás és telepítés során. A kernel.old állományra ugyanis nem minden esetben számíthatunk, mivel az új rendszermagok telepítésénél a kernel.old mindig felülíródik a legutóbb telepített rendszermaggal, amely azonban nem feltétlenül lesz mûködõképes. Sõt, amint csak lehetséges, rakjuk a mûködõ rendszermagot a /boot/kernel könyvtárba vagy különben a &man.ps.1; és a hozzá hasonló parancsok nem fognak rendesen mûködni. Mindezek elvégzéséhez egyszerûen nevezzük át a jó rendszermagot tartalmazó könyvtárt: &prompt.root; mv /boot/kernel /boot/kernel.rossz &prompt.root; mv /boot/kernel.jó /boot/kernel A rendszermag mûködik, de a &man.ps.1; viszont nem: Ha olyan rendszermagot telepítettünk, aminek a verziója nem egyezik meg a hozzátartozó segédprogramokéval, tehát például -CURRENT rendszermagot raktunk egy -RELEASE rendszerhez, egyes rendszerállapotjelzõ parancsok, mint például a &man.ps.1; vagy a &man.vmstat.8; nem fognak mûködni. Ebben az esetben az egész rendszert újra kell fordítanunk és telepítenünk a rendszermagunkkal megegyezõ verziójú forrásból. Részben ezért sem különösen ajánlott, hogy az operációs rendszer többi részétõl eltérõ verziójú rendszermagot használjunk. diff --git a/hu_HU.ISO8859-2/books/handbook/linuxemu/chapter.sgml b/hu_HU.ISO8859-2/books/handbook/linuxemu/chapter.sgml index cc48d033ca..c8db56b0e0 100644 --- a/hu_HU.ISO8859-2/books/handbook/linuxemu/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/linuxemu/chapter.sgml @@ -1,4408 +1,4408 @@ Jim Mock Átdolgozta és egyes részeit aktualizálta: Brian N. Handy Eredetileg írta: Rich Murphey Bináris Linux kompatibilitás Áttekintés Bináris Linux kompatibilitás bináris kompatibilitás Linux A &os; számos más &unix;-szerû operációs rendszerhez nyújt bináris kompatibilitást, köztük a Linuxhoz is. Elcsodálkozhatnánk rajta, hogy vajon miért kell tudnia a &os;-nek Linux binárisokat futtatnia? A válasz erre nagyon egyszerû. Rengeteg cég és fejlesztõ kizárólag csak Linuxra fejleszt, hiszen ez mostanság egy nagyon izgalmas téma az informatika világában. Emiatt azonban a &os; közösségnek külön gyõzködnie kell ezeket a cégeket és fejlesztõket, hogy készítsék el a termékeik natív &os;-s változatát. Ezzel az a gond, a legtöbb ilyen cég egyszerûen nem veszi észre, hogy ha létezne a terméküknek &os;-re írt változata, akkor még többen használnák. Így továbbra is csak Linuxra fejlesztenek. Mit tudnak tenni ilyenkor a &os; használói? Nos, ekkor jön jól a &os; bináris szintû kompatibilitása. Dióhéjban úgy tudnánk összefoglalni, hogy ennek köszönhetõen a &os; felhasználók képesek a linuxos alkalmazások közel 90%-át mindenféle további módosítás nélkül futtatni. Így tehát használható a &staroffice;, &netscape; Linux változata, az &adobe; &acrobat;, &realplayer;, VMware, &oracle;, &wordperfect;, Doom, Quake, és még sok minden más. Sõt, egyes tapasztalatok szerint bizonyos helyzetekben a &os; által futtatott Linux binárisok sokkal jobban teljesítenek, mint Linux alatt. Azonban vannak olyan Linuxra jellemzõ, az operációs rendszer szintjén meghúzódó eszközök, amelyek &os; alatt nem használhatóak. &os;-n nem fognak mûködni azok a Linux binárisok, amelyek túlzottan kihasználják az olyan &i386;-os rendszerhívásokat, mint például a virtuális 8086 mód. A fejezet elolvasása során megismerjük: hogyan engedélyezzük rendszerünkön a Linux kompatibilitást; hogyan telepítsünk linuxos osztott könyvtárakat; hogyan telepítsünk linuxos alkalmazásokat a &os; rendszerünkre; a &os; Linux kompatibilitásának implementációs részleteit. A fejezet elolvasásához ajánlott: külsõ szoftverek telepítésének ismerete (). Telepítés KLD (betölthetõ rendszermag objektum) A bináris Linux kompatibilitás alapértelmezés szerint nem engedélyezett. Legkönnyebben úgy tudjuk elérhetõvé tenni, ha betöltjük a linux nevû KLD modult (Kernel LoaDable). Ehhez root felhasználóként a következõket kell begépelni: &prompt.root; kldload linux Ha minden egyes rendszerindítás során engedélyezni szeretnénk a bináris kompatibilitást, akkor tegyük bele az /etc/rc.conf állományba ezt a sort: linux_enable="YES" A modul betöltõdését a &man.kldstat.8; paranccsal tudjuk ellenõrizni: &prompt.user; kldstat Id Refs Address Size Name 1 2 0xc0100000 16bdb8 kernel 7 1 0xc24db000 d000 linux.ko a rendszermag beállításai COMPAT_LINUX Ha valamiért nem akarjuk vagy nem éppen nem tudjuk betölteni a modult, akkor a bináris Linux kompatibilitást az options COMPAT_LINUX beállítással be is tudjuk építeni a rendszermagba. Ennek pontos menetét a ben találjuk meg. Linuxos futtatókönyvtárak telepítése Linux linuxos könyvtárak telepítése A linuxos könyvtárakat két módon is felrakhatjuk: egyrészt a linux_base port telepítésével, másrészt manuálisan. A könyvtárak telepítése a linux_base porttal Portgyûjtemény A futtatókönyvtárakat a lehetõ legegyszerûbben a emulators/linux_base porton keresztül tudjuk telepíteni. Teljesen úgy történik, mint a Portgyûjtemény akármelyik másik portjának telepítése. Csupán ennyit kell beírnunk: &prompt.root; cd /usr/ports/emulators/linux_base-fc4 &prompt.root; make install distclean A telepítés végeztével kaptunk is egy mûködõ bináris Linux kompatibilitást, habár egyes programok még panaszkodhatnak a rendszerkönyvtárak alverzióit illetõen. Általánosságban véve ez azonban nem okoz nagyobb gondot. A emulators/linux_base portnak több változata is használható, melyek az egyes Linux disztribúcióknak feleltethetõek meg. Ilyenkor mindig érdemes közülük azt választani, amelyik a leginkább megfelel a telepíteni kívánt linuxos alkalmazás igényeinek. A könyvtárak telepítése manuálisan Ha korábban még nem telepítettük volna a Portgyûjteményt, akkor egyénileg kell felraknunk az egyes könyvtárakat. Közülük azokra lesz szükségünk, amelyeket maga az alkalmazás is használni akar, valamint a futásidejû linkerre. Emellett még a &os; rendszerükön levõ Linux binárisok számára a /compat/linux könyvtárban létre kell hoznunk a gyökér ún. árnyékkönyvtárát is. A &os; alatt elindított Linux programok elõször ebben a könyvtárban fogják keresni a hozzájuk tartozó osztott könyvtárakat. Így tehát, amikor egy linuxos program betölti például a /lib/libc.so függvénykönyvtárat, akkor a &os; elõször a /compat/linux/lib/libc.so állományt próbálja meg megnyitni, majd ha az nem létezik, akkor a /lib/libc.so állományt. Az osztott könyvtárak ezért a /compat/linux/lib árnyékkönyvtárba telepítendõek, és nem oda, ahova a linuxos ld.so mutat. Általánosságban szólva eleinte elég csak azokat az osztott könyvtárakat megkeresni és felrakni, amelyekre a telepítendõ linuxos alkalmazásunknak ténylegesen szüksége van. Egy idõ után úgyis összegyûlnek azok a fontosabb függvénykönyvtárak, amelyek segítségével már minden további ráfordítás nélkül futtatni tudjuk a frissen importált programokat. Hogyan telepítsünk újabb osztott könyvtárakat? osztott könyvtárak Mit tegyünk, ha az emulators/linux_base port telepítése után az alkalmazás még mindig követel néhány hiányzó osztott könyvtárat? Honnan tudhatjuk meg, hogy milyen osztott könyvtárak kellenek majd egy Linux bináris használatához és honnan szerezzük be ezeket? Erre alapvetõn két lehetõségünk van (az utasításokat root felhasználóként kell majd végrehajtanunk). Ha hozzáférünk egy Linux rendszerhez, akkor szedjük össze az alkalmazásunk futtatásához szükséges osztott könyvtárakat és másoljuk ezeket a &os; partíciójára. Például: Tegyük fel, hogy FTP-n keresztül leszedtük a Doom Linux változatát és felraktuk egy általunk elérhetõ Linux rendszerre. Az ldd linuxdoom parancs segítségével ki tudjuk deríteni, milyen osztott könyvtárak kellenek majd nekünk: &prompt.user; ldd linuxdoom libXt.so.3 (DLL Jump 3.1) => /usr/X11/lib/libXt.so.3.1.0 libX11.so.3 (DLL Jump 3.1) => /usr/X11/lib/libX11.so.3.1.0 libc.so.4 (DLL Jump 4.5pl26) => /lib/libc.so.4.6.29 szimbolikus linkek Az utolsó oszlopban levõ állományokat másoljuk át, tegyük ezeket a /compat/linux könyvtárba, és hozzunk létre az elsõ oszlopban szereplõ szimbolikus linkeket. Így tehát a következõ állományok kellenének: /compat/linux/usr/X11/lib/libXt.so.3.1.0 /compat/linux/usr/X11/lib/libXt.so.3 -> libXt.so.3.1.0 /compat/linux/usr/X11/lib/libX11.so.3.1.0 /compat/linux/usr/X11/lib/libX11.so.3 -> libX11.so.3.1.0 /compat/linux/lib/libc.so.4.6.29 /compat/linux/lib/libc.so.4 -> libc.so.4.6.29
Ha már rendelkezünk az ldd kimenetének elsõ oszlopában szereplõ fõverziószámú osztott könyvtár, akkor nem kell átmásolni az utolsó oszlopban levõ állományokat, hiszen így is mûködnie kellene mindennek. Ha viszont egy újabb változattal találkozunk, akkor érdemes mégis inkább átmásolni. Miután a szimbolikus linkeket átirányítottuk az új változatra, a régit akár törölhetjük is. Ha például ezek a könyvtárak elérhetõek a rendszerünkön: /compat/linux/lib/libc.so.4.6.27 /compat/linux/lib/libc.so.4 -> libc.so.4.6.27 Észrevesszük, hogy az ldd kimenetében az új bináris egy újabb változatot igényel: libc.so.4 (DLL Jump 4.5pl26) -> libc.so.4.6.29 Ha csak az utolsó jegyében marad le valamivel a verziószám, akkor nem különösebben aggódnunk a /lib/libc.so.4.6.29 miatt sem, hiszen a programnak egy picivel korábbi verzióval is remekül kellene tudnia mûködnie. Természetesen, ha akarjuk, ettõl függetlnül lecserélhetjük a libc.so állományt, ami ezt eredményezi: /compat/linux/lib/libc.so.4.6.29 /compat/linux/lib/libc.so.4 -> libc.so.4.6.29
A szimbolikus linkek karbantartása csak a Linux binárisok esetén szükséges. A &os; saját futásidejû linkere magától megkeresi a megfelelõ fõverziószámú könyvtárakat, ezért emiatt általában nem kell aggódni.
Linux ELF binárisok telepítése Linux ELF binárisok Az ELF binárisok futtatása elõtt néha még szükség van a megbélyegzés (branding) használatára is. Ha egy bélyegezetlen ELF binárist akarunk elindítani, akkor a következõ hibaüzenetet kapjuk: &prompt.user; ./egy-linux-elf-bináris ELF binary type not known Abort A &os; rendszermagjának a &man.brandelf.1; paranccsal tudunk segíteni a &os; és a Linux binárisainak megkülönböztetésében. &prompt.user; brandelf -t Linux egy-linux-elf-bináris GNU eszköztár A GNU által fejlesztett eszközök manapság már automatikusan elhelyezik az ELF binárisok azonosításához szükséges bélyegeket, ezért ez a lépés a jövõben egyre inkább feleslegessé válik. A névfeloldó beállítása Ha a névfeloldás (DNS) valamiért nem mûködne, vagy egy ehhez hasonló üzenetet kapunk: resolv+: "bind" is an invalid keyword resolv+: "hosts" is an invalid keyword Akkor az /compat/linux/etc/host.conf állományba be kell illesztenünk a következõ sorokat: order hosts, bind multi on Az itt megszabott sorrend szerint elõször a /etc/hosts állományt nézi át, és majd csak ezután próbálja meg feloldani a nevet. Ha a /compat/linux/etc/host.conf állomány nem létezik, akkor a linuxos alkalmazás a &os; /etc/host.conf állományát találja meg, és panaszkodni fog a &os; eltérõ formátumára. Távolítsuk el a bind szócskát, ha nem állítottunk be névszervert az /etc/resolv.conf állományhoz. Boris Hollas A Mathematica 5.X verziójához igazította: A &mathematica; telepítése alkalmazások Mathematica Ebben a szakaszban megismerhetjük, hogyan telepítsük a &mathematica; 5.X Linux változatát &os; rendszerekre. A &mathematica; vagy a &mathematica; for Students linuxos változatai közvetlenül megrendelhetõek a fejlesztõtõl: . A &mathematica; telepítõjének elindítása Elõször is jeleznünk kell a &os;-nek, hogy a &mathematica; binárisai a linuxos ABI-t (Appplication Binary Interface) fogják használni. Itt legkönnyebben úgy járhatunk el, ha egyszerûen beállítjuk, hogy a rendszer a bélyegezetlen ELF binárisokat automatikusan Linux binárisoknak tekintse: &prompt.root; sysctl kern.fallback_elf_brand=3 Ennek köszönhetõen a &os; most már az összes bélyegezetlen ELF bináris esetén a linuxos ABI-t fogja használni, és így a telepítõt akár már közvetlenül a CD-rõl is indíthatjuk. Most másoljuk át a MathInstaller nevû állományt a merevlemezünkre: &prompt.root; mount /cdrom &prompt.root; cp /cdrom/Unix/Installers/Linux/MathInstaller helyi_könyvtár Az állományban cseréljük ki az elsõ sorban található /bin/sh hivatkozást a /compat/linux/bin/sh hivatkozásra. Ezzel biztosíthatjuk be, hogy a telepítõt a linuxos &man.sh.1; fogja elindítani. Ezután a kedvenc szövegszerkesztõnkkel vagy a következõ szakaszban található szkript segítségével helyettesítsük benne a Linux) szöveg összes elõfordulását a FreeBSD) szöveggel. Mivel a &mathematica; telepítõje az uname -s parancsra kapott válaszból állapítja meg az operációs rendszer típusát, ezért ezzel a módosítással a &os;-t is a Linuxhoz hasonló módon fogja kezelni. A MathInstaller elindítása után most már telepíthetõ a &mathematica;. A &mathematica; állományainak módosítása A &mathematica; telepítése során létrejött szkripteket a használatuk elõtt át kell írnunk. Amennyiben a &mathematica;hoz tartozó programokat a /usr/local/bin + class="directory">/usr/local/bin könyvtárba telepítettük, akkor itt találunk kell a math, mathematica, Mathematica és MathKernel állományokra mutató szimbolikus linkeket. Ezek mindegyikében cseréljük ki a Linux) karakterláncot a FreeBSD) szövegre a kedvenc szövegszerkesztõnkkel vagy az alábbi szkripttel: #!/bin/sh cd /usr/local/bin for i in math mathematica Mathematica MathKernel do sed 's/Linux)/FreeBSD)/g' $i > $i.tmp sed 's/\/bin\/sh/\/compat\/linux\/bin\/sh/g' $i.tmp > $i rm $i.tmp chmod a+x $i done A &mathematica; jelszavának megszerzése Ethernet MAC-cím A &mathematica; elsõ indítása során kérni fog egy jelszót. Ha még nem kértünk volna jelszót a fejlesztõtõl, akkor a számítógépünk azonosítójának (machine ID) megállapításához indítsuk el a telepítés könyvtárában található mathinfo nevû programot. Ez az azonosító lényegében az elsõdleges Ethernet kártyánk MAC-címe lesz, ezért a &mathematica; nem futtatható több számítógépen. Amikor e-mailen, telefonon vagy faxon keresztül regisztráljuk a terméket a Wolframnál, akkor meg kell adnunk nekik ezt az azonosítót machine ID néven, amire õk elküldik a hozzátartozó jelszót. A &mathematica; frontendjének futtatása hálózaton keresztül A &mathematica; a szabványos betûkészletekkel meg nem jeleníthetõ szimbólumokhoz (integráljelek, szummák, görög betûk, matematikai jelölések stb.) használ néhány olyan speciális betûtípust, amelyek nem minden esetben állnak rendelkezésre. A X által használt protokoll miatt ezeket a betûtípusokat helyben kell telepíteni. Ennek értelmében a &mathematica; CD-jén található betûtípusokat telepítenünk kell a számítógépünkre is. A CD-n ezeket általában a /cdrom/Unix/Files/SystemFiles/Fonts könyvtárban találjuk meg, vagy a merevlemezen a /usr/local/mathematica/SystemFiles/Fonts könyvtárban. Ezen belül pedig a Type1 és X alkönyvtárakra van szükségünk. Az alábbiakban leírtak szerint több módon is használhatjuk ezeket. Az egyik ilyen módszer, ha átmásoljuk az imént említett könyvtárakat a többi mellé, vagyis a /usr/X11R6/lib/X11/fonts könyvtárba. Ekkor szükségünk lesz még a fonts.dir állomány átírására is, ahova fel kell vennünk a betûtípusok neveit, majd ennek megfelelõen az elsõ sorban módosítanunk a könyvtárban található betûtípusok számát. De ugyanígy lefuttathatjuk ebben a könyvtárban a &man.mkfontdir.1; parancsot is. Az a másik megoldás, ha a könyvtárakat így másoljuk át a /usr/X11R6/lib/X11/fonts helyre: &prompt.root; cd /usr/X11R6/lib/X11/fonts &prompt.root; mkdir X &prompt.root; mkdir MathType1 &prompt.root; cd /cdrom/Unix/Files/SystemFiles/Fonts &prompt.root; cp X/* /usr/X11R6/lib/X11/fonts/X &prompt.root; cp Type1/* /usr/X11R6/lib/X11/fonts/MathType1 &prompt.root; cd /usr/X11R6/lib/X11/fonts/X &prompt.root; mkfontdir &prompt.root; cd ../MathType1 &prompt.root; mkfontdir Most adjuk hozzá az új könyvtárakat a betûtípusok könyvtáraihoz: &prompt.root; xset fp+ /usr/X11R6/lib/X11/fonts/X &prompt.root; xset fp+ /usr/X11R6/lib/X11/fonts/MathType1 &prompt.root; xset fp rehash Ha az &xorg; szervert használjuk, akkor az xorg.conf állományban megadhatjuk ezen könyvtárak automatikus betöltését is. Az &xfree86; típusú szerverek esetén az XF86Config konfigurációs állományt kell módosítanunk. betûk Ha még nincs /usr/X11R6/lib/X11/fonts/Type1 nevû könyvtárunk, akkor a példában szereplõ MathType1 könyvtárat nyugodtan átnevezhetjük Type1 nevûre. Aaron Kaplan Írta: Robert Getschmann Köszönet: A &maple; telepítése alkalmazások Maple A &maple; egy &mathematica;hoz hasonló kereskedelmi alkalmazás. A használatához elõször meg kell vásárolni a címrõl, majd a licenc megszerzéséhez ugyanott regisztrálni. &os;-re a szoftvert a következõ egyszerû lépéseken keresztül tudjuk telepíteni. Indítsuk el a termékhez mellékelt INSTALL nevû szkriptet. Válasszuk a telepítõprogram által felkínált opciók közül a RedHat címkéjût. A telepítés célkönyvtára legyen a /usr/local/maple. Ha eddig még nem tettük volna meg, rendeljük meg a &maple; licencét a Maple Waterloo Software-tõl () és másoljuk az /usr/local/maple/license/license.dat állományba. Az &maple;-höz mellékelt INSTALL_LIC szkript elindításával telepítsük a FLEXlm licenckezelõt. A szervernek adjuk meg a számítógépünk hálózati nevét. Javítsuk át a /usr/local/maple/bin/maple.system.type állományt a következõ módon: ----- itt kezdõdik a módosítás --------- *** maple.system.type.orig Sun Jul 8 16:35:33 2001 --- maple.system.type Sun Jul 8 16:35:51 2001 *************** *** 72,77 **** --- 72,78 ---- # the IBM RS/6000 AIX case MAPLE_BIN="bin.IBM_RISC_UNIX" ;; + "FreeBSD"|\ "Linux") # the Linux/x86 case # We have two Linux implementations, one for Red Hat and ----- módosítás vége ------------------- Vigyázzunk, hogy a "FreeBSD"|\ kezdetû sor végén nem szabad semmilyen további whitespace karakternek lennie. Ez a javítás arra utasítja a &maple;-t, hogy FreeBSD-t Linux rendszerként ismerje fel. A bin/maple szkript hívja a bin/maple.system.type szkriptet, ami pedig a uname -a hívással próbálja kideríteni a operációs rendszer nevét. Ettõl függõen választja ki, hogy milyen típusú binárisokat fog futtatni. Indítsuk el a licenckezelõ szervert. A most következõ szkripttel könnyedén el tudjuk indítani az lmgrd programot. A szkriptet /usr/local/etc/rc.d/lmgrd.sh néven hozzuk létre: ----- nyissz ----------- #! /bin/sh PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin PATH=${PATH}:/usr/local/maple/bin:/usr/local/maple/FLEXlm/UNIX/LINUX export PATH LICENSE_FILE=/usr/local/maple/license/license.dat LOG=/var/log/lmgrd.log case "$1" in start) lmgrd -c ${LICENSE_FILE} 2>> ${LOG} 1>&2 echo -n " lmgrd" ;; stop) lmgrd -c ${LICENSE_FILE} -x lmdown 2>> ${LOG} 1>&2 ;; *) echo "Usage: `basename $0` {start|stop}" 1>&2 exit 64 ;; esac exit 0 ----- nyissz ----------- Próbáljuk meg elindítani a &maple;-t: &prompt.user; cd /usr/local/maple/bin &prompt.user; ./xmaple Szerencsés esetben innentõl kezdve már minden mûködik. És ne felejtsünk el írni a Maplesoftnak, hogy szeretnénk egy natív &os; verziót a termékükbõl! Általános buktatók A FLEXlm licenckezelõvel esetenként nehéz lehet elboldogulni. Errõl témáról bõvebben a címen találunk leírásokat. Az lmgrd nagyon válogatós a licencállományokat illetõen és bármilyen apróságra kiakad. Egy szabályos licencállomány valahogy így néz ki: # ======================================================= # License File for UNIX Installations ("Pointer File") # ======================================================= SERVER chillig ANY #USE_SERVER VENDOR maplelmg FEATURE Maple maplelmg 2000.0831 permanent 1 XXXXXXXXXXXX \ PLATFORMS=i86_r ISSUER="Waterloo Maple Inc." \ ISSUED=11-may-2000 NOTICE=" Technische Universitat Wien" \ SN=XXXXXXXXX A sorozatszámot természetesen eltávolítottuk. Itt a chillig a számítógép neve. Az itt megadott licencállomány remekül használható egészen addig a pontig, amíg békén hagyjuk a FEATURE kezdetû sort (melyet a licenckulcs véd). Dan Pelleg Írta: A &matlab; telepítése alkalmazások MATLAB Ez a leírás azt mutatja be, hogyan telepítsük &os; rendszerekre a &matlab; version 6.5 Linux változatát. A &java.virtual.machine; (lásd ) használatától eltekintve meglepõen jól mûködik. A &matlab; Linux változata közvetlenül megrendelhetõ a The MathWorks-tõl, a címen. Ne felejtsük el beszerezni a licencállományt és az elkészítéséhez szükséges útmutatót. Ha már úgy is arra járunk, jelezzük a fejlesztõknek, hogy igényt tartanánk a termékük natív &os;-s változatára is! A &matlab; telepítése A &matlab; telepítéséhez a következõket kell tennünk: Helyezzük be a telepítõt CD-t és csatlakoztassuk. A telepítõszkript javaslatának megfelelõen váltsuk át a root felhasználóra. A szóbanforgó szkript elindításához gépeljük be a következõt: &prompt.root; /compat/linux/bin/sh /cdrom/install A telepítõ grafikus. Ha a megjelenítõ használatáról szóló hibaüzeneteket kapunk, akkor adjuk ki a setenv HOME ~FELHASZNÁLÓ parancsot, ahol a FELHASZNÁLÓ annak a felhasználónak a neve legyen, amivel az imént meghívtuk a &man.su.1; programot. Amikor a &matlab; könyvtárát kell megadnunk, ezt írjuk be: /compat/linux/usr/local/matlab. A telepítés további részeinek megkönnyítése érdekében írjuk be ezt a parancssorba: set MATLAB=/compat/linux/usr/local/matlab Miután megkaptuk a &matlab; licencét, az útmutatás szerint szerkesszük át. A licencállományt a kedvenc szövegszerkesztõnkkel akár már korábban elõ is készíthetjük, és majd amikor a telepítõnek szüksége lesz rá, másoljuk be $MATLAB/license.dat helyre. Futtassuk le a telepítést. Ezzel befejezõdõtt a &matlab; hagyományos telepítése. Innentõl már csak a &os; rendszer hozzátapasztásán fogunk dolgozni. A licenckezelõ elindítása Hozzunk létre szimbolikus linkeket a licenckezelõ szkriptjeire: &prompt.root; ln -s $MATLAB/etc/lmboot /usr/local/etc/lmboot_TMW &prompt.root; ln -s $MATLAB/etc/lmdown /usr/local/etc/lmdown_TMW Hozzunk létre egy indítószkriptet /usr/local/etc/rc.d/flexlm.sh néven. A lentebb látható minta a &matlab;hoz mellékelt $MATLAB/etc/rc.lm.glnx86 állomány egy módosított változata. Benne az állományok helyét és a licenckezelõ indításának körülményeit változtattuk meg (hogy Linux emuláció alatt fusson). #!/bin/sh case "$1" in start) if [ -f /usr/local/etc/lmboot_TMW ]; then /compat/linux/bin/sh /usr/local/etc/lmboot_TMW -u felhasználó && echo 'MATLAB_lmgrd' fi ;; stop) if [ -f /usr/local/etc/lmdown_TMW ]; then /compat/linux/bin/sh /usr/local/etc/lmdown_TMW > /dev/null 2>&1 fi ;; *) echo "Usage: $0 {start|stop}" exit 1 ;; esac exit 0 Tegyük ezt az állományt végrehajthatóvá: &prompt.root; chmod +x /usr/local/etc/rc.d/flexlm.sh A fenti szkriptben cseréljük ki a felhasználó nevét a rendszerünkben levõ egyik felhasználó nevére (ami persze nem a root). A licenckezelõt az alábbi paranccsal indítsuk el: &prompt.root; /usr/local/etc/rc.d/flexlm.sh start A &java; futtató környezet élesítése A &java; futtató környezet (&java; Runtime Environment, JRE) linkjét irányítsuk át egy &os; alatt mûködõ változatéra: &prompt.root; cd $MATLAB/sys/java/jre/glnx86/ &prompt.root; unlink jre; ln -s ./jre1.1.8 ./jre A &matlab; indítószkriptjének elkészítése Hozzunk létre egy ilyen indítószkriptet a /usr/local/bin/matlab könyvtárban: #!/bin/sh /compat/linux/bin/sh /compat/linux/usr/local/matlab/bin/matlab "$@" Futtassuk le a chmod +x /usr/local/bin/matlab parancsot. A szkript lefutása során a emulators/linux_base verziójától függõen hibákat is kaphatunk. Ha el akarjuk kerülni ezeket, akkor szerkesszük át a /compat/linux/usr/local/matlab/bin/matlab állomány következõ sorát: if [ `expr "$lscmd" : '.*->.*'` -ne 0 ]; then (a 13.0.1 számú verzióban ez 410. sor) erre: if test -L $newbase; then A &matlab; leállító szkriptjének elkészítése A &matlab; szabálytalan kilépéseit az alábbi utasítások nyomán tudjuk megszüntetni. Hozzunk létre egy $MATLAB/toolbox/local/finish.m nevû állományt, majd írjuk bele ezt a sort: ! $MATLAB/bin/finish.sh A $MATLAB szöveget pontosan így írjuk be. Ugyanebben a könyvtárban találjuk a beállításaink kilépés elõtti mentéséért felelõs finishsav.m és finishdlg.m állományokat. Ha ezek valamelyikét módosítjuk, akkor a elõbbi parancsot közvetlenül a save után szúrjuk be. Hozzunk létre egy $MATLAB/bin/finish.sh állományt, amiben szerepeljen a következõ: #!/usr/compat/linux/bin/sh (sleep 5; killall -1 matlab_helper) & exit 0 Tegyük végrehajthatóvá: &prompt.root; chmod +x $MATLAB/bin/finish.sh A &matlab; használata Most már a matlab parancs begépelésével bármikor elindíthatjuk. Marcel Moolenaar Írta: Az &oracle; telepítése alkalmazások Oracle Elõszó Ez a leírás azt mutatja be, hogyan telepítsük &os;-re az &oracle; 8.0.5 és &oracle; 8.0.5.1 Enterprise Edition Linux változatait. A Linux környezet telepítése Telepítsük a emulators/linux_base és devel/linux_devtools portokat a Portgyûjteménybõl. Amennyiben ennek során nehézségekbe ütköznénk, próbálkozzunk a korábbi változataikkal. Fel kell raknunk a Red Hat Tcl csomagját is, ha az alkalmazáshoz tartozó intelligens ügynököt is futtatni szeretnénk. Ez a tcl-8.0.3-20.i386.rpm. A hivatalos RPM port segítségével az alábbi általános parancson keresztül tudunk csomagokat telepíteni: &prompt.root; rpm -i --ignoreos --root /compat/linux --dbpath /var/lib/rpm csomag A csomag telepítésének semmilyen hibát nem kellene okoznia. Az &oracle; környezetének létrehozása Az &oracle; telepítéséhez elõször ki kell alakítanunk a megfelelõ környezetet. Ez a leírás kifejezetten arról szól, hogy &os;-n hogyan futtassuk a linuxos &oracle;-t, nem pedig az &oracle; telepítési útmutatójában bemutatottakat taglalja. A rendszermag hangolása a rendszermag hangolása Ahogy a &oracle; telepítési útmutatójában is olvashatjuk, be kell állítanunk az osztott memória maximális méretét. &os; alatt erre a célra ne használjuk a SHMMAX értéket, mivel az SHMMAX az SHMMAXPGS és PGSIZE értékekbõl számolódik ki. Ezért nekünk itt a SHMMAXPGS értékét kell meghatároznunk. Minden egyéb beállítás történhet az útmutatóban megadottak szerint. Például: options SHMMAXPGS=10000 options SHMMNI=100 options SHMSEG=10 options SEMMNS=200 options SEMMNI=70 options SEMMSL=61 Hangoljuk be ezeket az értékeket a &oracle; tervezett használatához. Emellett a konfigurációs állományban ne feledkezzünk meg az alábbi beállítások megadásáról sem: options SYSVSHM #SysV osztott memória options SYSVSEM #SysV szemaforok options SYSVMSG #SysV folyamatok közti kommunikáció Az &oracle; hozzáférése Egy rendes hozzáféréshez hasonlóan hozzunk létre egy külön oracle hozzáférést is rendszerünkön. Az oracle hozzáférés annyira különleges, hogy csak linuxos parancsértelmezõt társítsunk hozzá. Ehhez vegyük fel /compat/linux/bin/bash sort az /etc/shells állományba, majd állítsuk át az oracle nevû felhasználó parancsértelmezõjét a /compat/linux/bin/bash programra. Környezet A megszokott &oracle; környezeti változók, mint például a ORACLE_HOME és ORACLE_SID mellett még definiálnunk kell a következõket is: Változó Érték LD_LIBRARY_PATH $ORACLE_HOME/lib CLASSPATH $ORACLE_HOME/jdbc/lib/classes111.zip PATH /compat/linux/bin /compat/linux/sbin /compat/linux/usr/bin /compat/linux/usr/sbin /bin /sbin /usr/bin /usr/sbin /usr/local/bin $ORACLE_HOME/bin Javasoljuk, hogy az összes környezeti változót a .profile állományban adjuk meg. Ennek megfelelõen a példa beállításai így fognak kinézni benne: ORACLE_BASE=/oracle; export ORACLE_BASE ORACLE_HOME=/oracle; export ORACLE_HOME LD_LIBRARY_PATH=$ORACLE_HOME/lib export LD_LIBRARY_PATH ORACLE_SID=ORCL; export ORACLE_SID ORACLE_TERM=386x; export ORACLE_TERM CLASSPATH=$ORACLE_HOME/jdbc/lib/classes111.zip export CLASSPATH PATH=/compat/linux/bin:/compat/linux/sbin:/compat/linux/usr/bin PATH=$PATH:/compat/linux/usr/sbin:/bin:/sbin:/usr/bin:/usr/sbin PATH=$PATH:/usr/local/bin:$ORACLE_HOME/bin export PATH Az &oracle; telepítése A Linux emulátorban meghúzódó apró egyenletlenségek miatt a telepítés elõtt létre kell hoznunk egy .oracle nevû alkönyvtárat a /var/tmp könyvtárban. Helyezzük ezt a oracle felhasználó tulajdonába. Ezt követõen minden további gond nélkül képesek leszünk az &oracle; telepítésére. Ha netalán mégis problémákba ütköznénk, elõször mindig az &oracle; telepítési és konfigurációs állományait ellenõrizzük! Az &oracle; telepítése után rakjuk fel a következõ szakaszokban bemutatandó javításokat. Gyakran problémát okoz, ha a TCP protokollt még nem telepítettük. Ennek következményeképpen ugyanis nem tudnak elindulni a TCP alapú szolgáltatások. Az alábbi mûveletek ebben igyekeznek segíteni: &prompt.root; cd $ORACLE_HOME/network/lib &prompt.root; make -f ins_network.mk ntcontab.o &prompt.root; cd $ORACLE_HOME/lib &prompt.root; ar r libnetwork.a ntcontab.o &prompt.root; cd $ORACLE_HOME/network/lib &prompt.root; make -f ins_network.mk install Ne felejtsük el ismét elindítani a root.sh szkriptet! A root.sh javítása Az &oracle; telepítése során root (privilegizált) felhasználóként elvégzendõ mûveleteket a root.sh elnevezésû szkriptben találjuk. Ez a szkript a orainst könyvtárba kerül. A chown parancs helyes lefutásához alkalmazzunk az alább mellékelt javítást, vagy az egész szkriptet egy linuxos parancsértelmezõbõl indítsuk el. *** orainst/root.sh.orig Tue Oct 6 21:57:33 1998 --- orainst/root.sh Mon Dec 28 15:58:53 1998 *************** *** 31,37 **** # This is the default value for CHOWN # It will redefined later in this script for those ports # which have it conditionally defined in ss_install.h ! CHOWN=/bin/chown # # Define variables to be used in this script --- 31,37 ---- # This is the default value for CHOWN # It will redefined later in this script for those ports # which have it conditionally defined in ss_install.h ! CHOWN=/usr/sbin/chown # # Define variables to be used in this script Ha nem CD-rõl telepítjük az &oracle;-t, akkor akár a root.sh forrását is kijavíthatjuk. A neve rthd.sh, és a forrásfa orainst könyvtárában találhatjuk. A genclntsh javítása A genclntsh szkript a kliensek által használt osztott könyvtár létrehozására alkalmazható. Általában demók fordításához van rá szükség. Az alábbi javítás alkalmazásával a PATH változó értéke törölhetõ: *** bin/genclntsh.orig Wed Sep 30 07:37:19 1998 --- bin/genclntsh Tue Dec 22 15:36:49 1998 *************** *** 32,38 **** # # Explicit path to ensure that we're using the correct commands #PATH=/usr/bin:/usr/ccs/bin export PATH ! PATH=/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin export PATH # # each product MUST provide a $PRODUCT/admin/shrept.lst --- 32,38 ---- # # Explicit path to ensure that we're using the correct commands #PATH=/usr/bin:/usr/ccs/bin export PATH ! #PATH=/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin export PATH # # each product MUST provide a $PRODUCT/admin/shrept.lst Az &oracle; futtatása Ha rendesen követtük az iménti utasításokat, akkor most már úgy tudjuk futtatni az &oracle;-t, mintha csak Linuxon futna. Holger Kipp Írta: Valentino Vaschetto Az eredeti verziót SGML-re ültette: Az &sap.r3; telepítése alkalmazások SAP R/3 Az &sap; típusú rendszerek telepítéséhez &os;-re hivatalosan nem kaphatunk mûszaki segélynyújtást — csak a minõsített plaformokat támogatják. Elõszó Ez a leírás az &sap.r3; rendszer és &oracle; adatbázis Linux változatainak telepítését mutatja be &os;-n, beleértve a &os; és az &oracle; telepítését. Kétféle konfigurációt írunk le: &sap.r3; 4.6B (IDES) és &oracle; 8.0.5, FreeBSD 4.3-STABLE &sap.r3; 4.6C és &oracle; 8.1.7, FreeBSD 4.5-STABLE Habár ez a dokumentum igyekszik az összes fontos lépést a lehetõ legrészletesebb módon tárgyalni, semmiképpen sem célja az &oracle; és az &sap.r3; alkalmazásokhoz mellékelt telepítési útmutatók kiváltása. A kifejezetten az &sap; vagy az &oracle; Linux változataira vonatkozó kérdések, valamint az &oracle; és az &sap; OSS konkrét használatával kapcsolatos leírások tekintetében a saját dokumentációjukat olvassuk el. A szoftver Az &sap; telepítéséhez az alábbi CD-ket használtuk fel: &sap.r3; 4.6B, &oracle; 8.0.5 Név Szám Leírás KERNEL 51009113 SAP Kernel Oracle / telepítõ / AIX, Linux, Solaris RDBMS 51007558 Oracle / RDBMS 8.0.5.X / Linux EXPORT1 51010208 IDES / DB-Export / 1. lemez EXPORT2 51010209 IDES / DB-Export / 2. lemez EXPORT3 51010210 IDES / DB-Export / 3. lemez EXPORT4 51010211 IDES / DB-Export / 4. lemez EXPORT5 51010212 IDES / DB-Export / 5. lemez EXPORT6 51010213 IDES / DB-Export / 6. (utolsó) lemez Emellett még használtuk az &oracle; 8 Server (az elõzetes 8.0.5 változat a Linux 2.0.33 verziójához) CD-jét is, amely igazából nem feltétlenül szükséges, valamint a &os; (a 4.3 RELEASE kiadása után nem sokkal levõ) 4.3-STABLE változatát. &sap.r3; 4.6C SR2, &oracle; 8.1.7 Név Szám Leírás KERNEL 51014004 SAP Kernel Oracle / SAP Kernel 4.6D változat / DEC, Linux RDBMS 51012930 Oracle 8.1.7/ RDBMS / Linux EXPORT1 51013953 4.6C kiadás SR2 / Export / 1. lemez EXPORT1 51013953 4.6C kiadás SR2 / Export / 2. lemez EXPORT1 51013953 4.6C kiadás SR2 / Export / 3. lemez EXPORT1 51013953 4.6C kiadás SR2 / Export / 4. (utolsó) lemez LANG1 51013954 4.6C kiadás SR2 / Nyelvi támogatás / német, angol, francia / 1. lemez A telepítendõ nyelvtõl függõen egyéb nyelvi támogatást tartalmazó CD használata is szükségessé válhat. Itt most csak a német és angol nyelveket használjuk, ezért elegendõ az elsõ CD. Csendben hozzátesszük, hogy mind a négy EXPORT CD száma megegyezik. Ugyanígy a három nyelvi CD-nek is megegyeznek a számai (ez eltér a 4.6B IDES kiadás CD számozásától). Az írás pillanatában a &os; 4.5-STABLE (2002.03.20-i) változatát használjuk. &sap; füzetek Az &sap.r3; telepítésével kapcsolatban az alábbi füzetek bizonyultak hasznosnak: &sap.r3; 4.6B, &oracle; 8.0.5 Szám Cím 0171356 SAP Software on Linux: Essential Comments 0201147 INST: 4.6C R/3 Inst. on UNIX - Oracle 0373203 Update / Migration Oracle 8.0.5 --> 8.0.6/8.1.6 LINUX 0072984 Release of Digital UNIX 4.0B for Oracle 0130581 R3SETUP step DIPGNTAB terminates 0144978 Your system has not been installed correctly 0162266 Questions and tips for R3SETUP on Windows NT / W2K &sap.r3; 4.6C, &oracle; 8.1.7 Szám Cím 0015023 Initializing table TCPDB (RSXP0004) (EBCDIC) 0045619 R/3 with several languages or typefaces 0171356 SAP Software on Linux: Essential Comments 0195603 RedHat 6.1 Enterprise version: Known problems 0212876 The new archiving tool SAPCAR 0300900 Linux: Released DELL Hardware 0377187 RedHat 6.2: important remarks 0387074 INST: R/3 4.6C SR2 Installation on UNIX 0387077 INST: R/3 4.6C SR2 Inst. on UNIX - Oracle 0387078 SAP Software on UNIX: OS Dependencies 4.6C SR2 Hardverkövetelmények Az alábbi hardvereszközök szükségesek az &sap.r3; rendszer telepítéséhez. Az éles használathoz ennél természetesen valamivel több kell majd: Változat 4.6B 4.6C Processzor Két &pentium; III 800MHz Két &pentium; III 800MHz Memória 1GB ECC 2GB ECC Szabad hely a merevlemezen 50 - 60GB (IDES) 50 - 60GB (IDES) Éles használatra nagyobb gyorsítótárral rendelkezõ &xeon; processzorokat, nagysebességû háttértárakat (SCSI, hardveres RAID vezérlõvel), USV és ECC memória modulok ajánlottak. A nagy tárigényt egyébként az elõre beállított IDES rendszer indokolja, ami egy 27 GB méretû adatbázist hoz létre a telepítés során. Ez a terület általában elegendõ egy frissen induló rendszer és hozzátartozó alkalmazásadatok tárolására. &sap.r3; 4.6B, &oracle; 8.0.5 A következõ hardverkonfigurációt használtuk: két 800 MHz-es &pentium; III processzor és a hozzájuk tartozó alaplap, egy &adaptec; 29160 Ultra160 SCSI-vezérlõ (a 40/80 GB méretû DLT szalagos meghajtó és CD-meghajtó használatához) és egy &mylex; &acceleraid; RAID-vezérlõ (2 csatorna, 6.00-1-00 verziójú firmware és 32 MB memória), amihez két 17 GB-os (tükrözött) merevlemez és négy 36 GB-os merevlemez (RAID 5) csatlakozik. &sap.r3; 4.6C, &oracle; 8.1.7 Itt a hardver egy &dell; &poweredge; 2500 volt: kétprocesszoros alaplap, két darab 1000 MHz-es &pentium; III processzorral (fejenként 256 KB gyorsítótárral), 2 GB PC133-as ECC SDRAM memóriával, PERC/3 DC PCI RAID-vezérlõvel (128 MB memória), valamint egy EIDE DVD-meghajtóval. A RAID-vezérlõre két, egyenként 18 GB méretû merevlemezt (tükrözve) és négy 36 GB méretû merevlemezt csatlakoztattunk (RAID 5-ben). A &os; telepítése Elõször is telepítenünk kell a &os;-t. Ez több módon is lehetséges, ezekrõl a ban olvashatunk bõvebben. A lemezek felosztása Az egyszerûség kedvéért az &sap.r3; 46B és &sap.r3; 46C SR2 telepítése során is ugyanazt a felosztást használtuk. Egyedül az eszközök nevei változtak, mivel a telepítés eltérõ hardvereken történt (/dev/da) és /dev/amr, tehát ha az AMI &megaraid; esetén a /dev/da0s1a helyett a /dev/amr0s1a eszközt láthatjuk): Állományrendszer Méret (1 KB-os blokkokban) Méret (GB-ban) Csatlakozási pont /dev/da0s1a 1.016.303 1 / /dev/da0s1b 6 lapozóállomány /dev/da0s1e 2.032.623 2 /var /dev/da0s1f 8.205.339 8 /usr /dev/da1s1e 45.734.361 45 /compat/linux/oracle /dev/da1s1f 2.032.623 2 /compat/linux/sapmnt /dev/da1s1g 2.032.623 2 /compat/linux/usr/sap Elõre állítsuk be és inicializáljuk a két logikai meghajtót a &mylex; és a PERC/3 RAID-vezérlõkön. A hozzátartozó szoftver a BIOS indításának fázisában hívható be. A lemezek felosztása némileg eltér az &sap; által javasoltaktól, mivel az &sap; szerint az &oracle; könyvtárait (néhány másikkal együtt) külön-külön érdemes csatlakoztatni — mi most az egyszerûsítés kedvéért csak létrehoztuk ezeket. A <command>make world</command> és egy új rendszermag Töltsük le a legfrissebb -STABLE forrásokat. Fordítsuk újra az összes forrást (make world) és a beállításainak elvégzése után a saját rendszermagunkat is. Itt ne felejtsük el megadni az &sap.r3; és az &oracle; mûködéséhez szükséges paramétereket. A Linux környezet telepítése Az linuxos alaprendszer telepítése Elsõként a linux_base portot kell felraknunk (root felhasználóként): &prompt.root; cd /usr/ports/emulators/linux_base &prompt.root; make install distclean A linuxos fejlesztõi környezet telepítése Ha az &oracle;-t &os;-re a ban leírtak szerint akarjuk telepíteni, akkor szükségünk lesz a linuxos fejlesztõeszközökre is: &prompt.root; cd /usr/ports/devel/linux_devtools &prompt.root; make install distclean A linuxos fejlesztõkörnyezetet csak az &sap.r3; 46B IDES telepítésénél raktuk fel. Nincs rá szükségünk, ha a &os; rendszeren nem akarjuk újralinkelni az &oracle; adatbázist. Pontosan ez a helyezet, amikor egy Linux rendszerhez gyártott &oracle; készletet használunk. A szükséges RPM csomagok telepítése RPM Az R3SETUP elindításához PAM támogatásra is szükségünk lesz. Amikor elõször próbáltuk meg telepíteni a &os; 4.3-STABLE változatára az &sap;-t, felraktuk PAM-et és az összes hozzátartozó csomagot, majd végül úgy bírtuk mûködésre, hogy kényszerítettük a PAM telepítését is. Az &sap.r3; 4.6C SR2 esetén szintén sikerült önmagában felrakni a PAM RPM csomagját is, tehát úgy néz ki, hogy a függõségeit már nem kell telepíteni: &prompt.root; rpm -i --ignoreos --nodeps --root /compat/linux --dbpath /var/lib/rpm \ pam-0.68-7.i386.rpm Az &oracle; 8.0.5 verziójához mellékelt intelligens ügynök futtatásához fel kell rakni a RedHat tcl-8.0.5-30.i386.rpm nevû Tcl csomagját is (máskülönben a az &oracle; telepítése közben szükséges újralinkelés nem fog mûködni). Vannak ugyan egyébként is gondok az &oracle; újralinkelésével, azonban ez linuxos probléma, nem pedig &os;-s. Néhány további tipp Hasznos lehet, ha felvesszük a linprocfs bejegyzést az /etc/fstab állományba. Ennek pontos részleteit a &man.linprocfs.5; man oldalon találjuk meg. Másik fontos paraméter a kern.fallback_elf_brand=3, amelyet az /etc/sysctl.conf állományba kell beszúrnunk. Az &sap.r3; környezetének létrehozása A szükséges állományrendszerek és csatlakozási pontok létrehozása Egy egyszerûbb telepítéshez elég csupán a következõ állományrendszereket elkészíteni: csatlakozási pont méret GB-ban /compat/linux/oracle 45 GB /compat/linux/sapmnt 2 GB /compat/linux/usr/sap 2 GB Készítenünk kell még néhány linket is, különben az &sap; telepítõje panaszkodni fogni az ellenõrzésük során: &prompt.root; ln -s /compat/linux/oracle /oracle &prompt.root; ln -s /compat/linux/sapmnt /sapmnt &prompt.root; ln -s /compat/linux/usr/sap /usr/sap Az egyik ilyen telepítés közben megjelenõ hibaüzenet (a PRD rendszer és az &sap.r3; 4.6C SR2 telepítése esetén): INFO 2002-03-19 16:45:36 R3LINKS_IND_IND SyLinkCreate:200 Checking existence of symbolic link /usr/sap/PRD/SYS/exe/dbg to /sapmnt/PRD/exe. Creating if it does not exist... WARNING 2002-03-19 16:45:36 R3LINKS_IND_IND SyLinkCreate:400 Link /usr/sap/PRD/SYS/exe/dbg exists but it points to file /compat/linux/sapmnt/PRD/exe instead of /sapmnt/PRD/exe. The program cannot go on as long as this link exists at this location. Move the link to another location. ERROR 2002-03-19 16:45:36 R3LINKS_IND_IND Ins_SetupLinks:0 can not setup link '/usr/sap/PRD/SYS/exe/dbg' with content '/sapmnt/PRD/exe' A felhasználók és könyvtárak létrehozása Az &sap.r3; rendszernek két felhasználóra és három csoportra van szüksége. Az igényelt felhasználók nevei az &sap; rendszer azonosítójától (System ID, SID) függenek, amely három betûbõl áll. Egyes ilyen rendszerazonosítók az &sap; számára vannak fenntartva. (Például a SAP és a NIX. Ezek teljes listáját az &sap; dokumentációjában találjuk meg.) Erre az IDES telepítéséhez az IDS, a 4.6C SR2 telepítésénél a PRD neveket adtuk, mivel ezeket a rendszereket éles használatra szánták. Ennélfogva a következõ csoportokat hoztuk létre hozzájuk (a csoportok azonosítói ugyan eltérhetnek az általunk használtaktól): csoport azonosítója csoport neve leírás 100 dba Adatbázis adminisztrátor 101 sapsys &sap; rendszer 102 oper Adatbázis operátor Az &oracle; alapértelmezett telepítésénél csak a dba csoport jön létre. A dba csoportot oper csoportként is használhatjuk (bõvebb információkért lásd az &oracle; és az &sap; dokumentációját). Ezenkívül az alábbi felhasználókra van még szükségünk: felhasználói azonosító felhasználói név általános név csoport egyéb csoportok leírás 1000 idsadm/prdadm sidadm sapsys oper &sap; adminisztrátor 1002 oraids/oraprd orasid dba oper &oracle; adminisztrátor Az &man.adduser.8; parancs használata során a következõkre lesz szükségünk egy &sap; Administrator létrehozásához (figyeljük a parancsértelmezõt (shell) és a felhasználói könyvtárat (home directory)): Name: sidadm Password: ****** Fullname: SAP Administrator SID Uid: 1000 Gid: 101 (sapsys) Class: Groups: sapsys dba HOME: /home/sidadm Shell: bash (/compat/linux/bin/bash) Ugyanígy az &oracle; Administrator esetében: Name: orasid Password: ****** Fullname: Oracle Administrator SID Uid: 1002 Gid: 100 (dba) Class: Groups: dba HOME: /oracle/sid Shell: bash (/compat/linux/bin/bash) A dba és oper csoportok használata során ne felejtsük el megadni az oper csoportot sem. Könyvtárak létrehozása A könyvtárakat általában külön állományrendszerekként hozzák létre, de ez teljesen az igényeinken múlik. Mi most egyszerû könyvtárakként alakítottuk ki ezeket, ezért tulajdonképpen ugyanazon a RAID 5 tömbön találhatóak meg: Ehhez elõször beállítjuk az egyes könyvtárak tulajdonosait és engedélyeit (root felhasználóként): &prompt.root; chmod 775 /oracle &prompt.root; chmod 777 /sapmnt &prompt.root; chown root:dba /oracle &prompt.root; chown sidadm:sapsys /compat/linux/usr/sap &prompt.root; chmod 775 /compat/linux/usr/sap Másodsorban orasid felhasználóként hozzuk létre az /oracle/SID alkönyvtárait: &prompt.root; su - orasid &prompt.root; cd /oracle/SID &prompt.root; mkdir mirrlogA mirrlogB origlogA origlogB &prompt.root; mkdir sapdata1 sapdata2 sapdata3 sapdata4 sapdata5 sapdata6 &prompt.root; mkdir saparch sapreorg &prompt.root; exit Az &oracle; 8.1.7 telepítésénél még további könyvtárakra is szükségünk lesz: &prompt.root; su - orasid &prompt.root; cd /oracle &prompt.root; mkdir 805_32 &prompt.root; mkdir client stage &prompt.root; mkdir client/80x_32 &prompt.root; mkdir stage/817_32 &prompt.root; cd /oracle/SID &prompt.root; mkdir 817_32 A client/80x_32 könyvtárnak pontosan ilyen névvel kell rendelkeznie. Ne cseréljük ki a benne szereplõ x-et semmire se! A harmadik lépésben létrehozzuk a sidadm felhasználóhoz tartozó könyvtárakat: &prompt.root; su - sidadm &prompt.root; cd /usr/sap &prompt.root; mkdir SID &prompt.root; mkdir trans &prompt.root; exit Az <filename>/etc/services</filename> A &sap.r3; mûködéséhez fel kell vennünk néhány olyan bejegyzést is az /etc/services állományba, amelyek a &os; telepítése során nem jönnek létre. Így tehát írjuk be az alábbi sorokat (legalább a használni kívánt példány számához illõ sorokat adjuk meg — ez jelen esetünkben most a 00. Természetesen az sem okoz gond, ha a dp, gw, sp és ms esetén beírjuk az összes példánynak megfelelõ portot 00-tól 99-ig). Amennyiben a SAProuter vagy az &sap; OSS használatára lenne szükségünk, akkor adjuk meg a SAProuter által lefoglalt 99-es példánynak megfelelõ 3299-es portot a rendszerünkön: sapdp00 3200/tcp # SAP menetirányító 3200 + a példány száma sapgw00 3300/tcp # SAP átjáró 3300 + a példány száma sapsp00 3400/tcp # 3400 + a példány száma sapms00 3500/tcp # 3500 + a példány száma sapmsSID 3600/tcp # SAP üzenetkezelõ szerver 3600 + a példány száma sapgw00s 4800/tcp # biztonságos SAP átjáró 4800 + a példány száma A szükséges nyelvi beállítások nyelvi beállítás Az &sap;-nek legalább két olyan nyelvre van szüksége, amely nem részei az alap RedHat telepítéseknek. Az &sap; a saját FTP szervereirõl elérhetõvé tette az ehhez szükséges RPM csomagokat (amelyek viszont csak OSS típusú hozzáférés birtokában tölthetõek le). A 0171356 számú jegyzet tartalmazza a beszerzendõ RPM-ek listáját. Megcsinálhatjuk úgy is, hogy egyszerûen csak linkeket hozunk létre (például az de_DE és en_US könyvtárakra), habár ezt egy éles rendszer esetében semmiképpen sem ajánljuk (az IDES rendszerrel tapasztalataink szerint eddig még remekül mûködött). Az alábbi nyelvi beállítások fognak tehát nekünk kelleni: de_DE.ISO-8859-1 en_US.ISO-8859-1 Így hozzuk létre hozzájuk a linkeket: &prompt.root; cd /compat/linux/usr/share/locale &prompt.root; ln -s de_DE de_DE.ISO-8859-1 &prompt.root; ln -s en_US en_US.ISO-8859-1 A telepítés során az iméntiek hiánya gondokat okozhat. Ha folyamatosan figyelmen kívül hagyjuk az ezekbõl fakadó hibákat (vagyis a CENTRDB.R3S állományban a gondot okozó lépések STATUS értékét OK-ra állítjuk), akkor komolyabb erõfeszítések megtétele nélkül majd képtelenek leszünk bejelentkezni a frissen telepített &sap; rendszerünkbe. A rendszermag finomhangolása a rendszermag finomhangolása Az &sap.r3; rendszerek temérdek mennyiségû erõforrást igényelnek. Ennek kielégítésére az alábbi paramétereket adjuk hozzá a rendszermag beállításait tartalmazó állományhoz: # Adjunk a memóriazabálóknak (SAP és Oracle): options MAXDSIZ="(1024*1024*1024)" options DFLDSIZ="(1024*1024*1024)" # Kell néhány System V beállítás is: options SYSVSHM # SYSV típusú osztott memória be options SHMMAXPGS=262144 # a megosztható memória maximális mérete lapokban #options SHMMAXPGS=393216 # a 46C telepítésekor ezt használjuk options SHMMNI=256 # az osztott memóriákhoz tartozó azonosítók maximális száma options SHMSEG=100 # a futó programonként megosztható szegmensek maximuma options SYSVMSG # SYSV típusú üzenetsorok options MSGSEG=32767 # a rendszerben keringõ üzenetszegmensek maximális száma options MSGSSZ=32 # az üzenetszegmensek mérete. 2 hatványa LEGYEN options MSGMNB=65535 # maximális karakter üzenetsoronként options MSGTQL=2046 # a rendszerben levõ üzenetek maximuma options SYSVSEM # SYSV típusú szemaforok options SEMMNU=256 # a szemaforok UNDO struktúráinak száma options SEMMNS=1024 # a rendszerben levõ szemaforok száma options SEMMNI=520 # a szemaforok azonosítóinak mennyisége options SEMUME=100 # az UNDO kulcsok száma Az itt megadott minimum értékek az &sap; által kiadott dokumentációkból származnak. Mivel a Linux változathoz errõl nincs külön leírás, ezért a (32 bites) HP-UX változat dokumentációi között érdemes ennek utánanézni. Mivel a 4.6C SR2 telepítéséhez használt rendszeren valamivel több fizikai memória állt rendelkezésünkre, ezért az osztott szegmensek méretét nagyobbra tudtuk megválasztani mind az &sap; és mind az &oracle; esetében, ami magyarázza a megosztható lapok nagyobb számát. Az &os; &i386; változatának telepítése során hagyjuk meg a MAXDSIZ és DFLDSIZ értékek alapértelmezett 1 GB-os maximumát. Ellenkezõ esetben ezekhez hasonló furcsa hibaüzeneteket láthatunk: ORA-27102: out of memory vagy Linux Error: 12: Cannot allocate memory. Az &sap.r3; telepítése Az &sap; CD-k elõkészítése Sok CD-t kell a telepítés során mozgatni, tehát csatlakoztatni és leválasztani. Ha viszont elegendõ meghajtóval rendelkezünk, akkor akár csatlakoztathatjuk egyszerre is az összeset. Vagy felmásolhatjuk a CD-t tartalmát a nekik megfelelõ könyvtárakba: /oracle/SID/sapreorg/cd-neve ahol a cd-neve a következõk valamelyike: KERNEL, RDBMS, EXPORT1, EXPORT2, EXPORT3, EXPORT4, EXPORT5 és EXPORT6 (4.6B/IDES), valamint KERNEL, RDBMS, DISK1, DISK2, DISK3, DISK4 és LANG (4.6C SR2). A csatlakoztatott CD-ken található állományok neveinek nagybetûseknek kell lenniük. Ha nem így lenne, akkor a csatlakoztatásnál adjuk meg a opciót. Így tehát a következõ parancsokat kell kiadnunk: &prompt.root; mount_cd9660 -g /dev/cd0a /mnt &prompt.root; cp -R /mnt/* /oracle/SID/sapreorg/cd-neve &prompt.root; umount /mnt A telepítõszkript futtatása Elsõként egy install nevû könyvtárat kell elõkészítenünk: &prompt.root; cd /oracle/SID/sapreorg &prompt.root; mkdir install &prompt.root; cd install Ezután futtassuk le a telepítõszkriptet, ami pedig bemásolja az install könyvtárba szinte az összes fontos állományt: &prompt.root; /oracle/SID/sapreorg/KERNEL/UNIX/INSTTOOL.SH Az IDES (4.6B) változathoz egy teljes &sap.r3; bemutató rendszer is tartozik, ezért a megszokott három CD helyett hat EXPORT típusú CD-bõl áll. Itt a CENTRDB.R3S telepítõsablon csak a szabvány központi példányt hozza létre (&r3; és az adatbázis), az IDES központi példányát már nem. Ezért az EXPORT1 könyvtárból ki kell másolnunk a CENTRDB.R3S állományt, különben az R3SETUP csak három EXPORT CD-t fog kérni. Az újabb &sap; 4.6 SR2 kiadáshoz négy EXPORT CD tartozik. A telepítés folyamatát a CENTRAL.R3S állományban levõ paraméterek vezérlik. A korábbi kiadásokkal ellentétben nincsenek külön sablonok az adatbázissal és a nélküle telepítendõ központi példányok számára. Az &sap; az adatbázisok telepítésére külön sablont használ. Újrakezdéskor a telepítést ettõl függetlenül elegendõ az eredeti állománnyal újraindítani. A telepítés közben és után az &sap;-nek a hostname paranccsal csak a gép saját nevét, nem pedig a teljes hálózati nevét kell megadnunk. Ilyenkor ezt vagy egyenként begépeljük, vagy létrehozunk rá egy álnevet az orasid és sidadm (valamint a megfelelõ lépésekben a root) felhasználóknak: alias hostname='hostname -s'. Ezenkívül még az &sap; telepítésekor létrehozott mindkét felhasználó .profile és .login állományait is beállíthatjuk ennek megfelelõen. Az <command>R3SETUP</command> 4.6B verziójának indítása Ne felejtsük el jól beállítani az LD_LIBRARY_PATH környezeti változót: &prompt.root; export LD_LIBRARY_PATH=/oracle/IDS/lib:/sapmnt/IDS/exe:/oracle/805_32/lib A telepítés könyvtárában root felhasználóként indítsuk el az R3SETUP programot: &prompt.root; cd /oracle/IDS/sapreorg/install &prompt.root; ./R3SETUP -f CENTRDB.R3S A szkript ezek után feltesz néhány kérdést (az alapértelmezett válaszok zárójelben, közvetlenül a megadottak után): Kérdés Alapértelmezés Válasz Enter SAP System ID [C11] IDSEnter Enter SAP Instance Number [00] Enter Enter SAPMOUNT Directory [/sapmnt] Enter Enter name of SAP central host [troubadix.domain.de] Enter Enter name of SAP db host [troubadix] Enter Select character set [1] (WE8DEC) Enter Enter Oracle server version (1) Oracle 8.0.5, (2) Oracle 8.0.6, (3) Oracle 8.1.5, (4) Oracle 8.1.6 1Enter Extract Oracle Client archive [1] (Yes, extract) Enter Enter path to KERNEL CD [/sapcd] /oracle/IDS/sapreorg/KERNEL Enter path to RDBMS CD [/sapcd] /oracle/IDS/sapreorg/RDBMS Enter path to EXPORT1 CD [/sapcd] /oracle/IDS/sapreorg/EXPORT1 Directory to copy EXPORT1 CD [/oracle/IDS/sapreorg/CD4_DIR] Enter Enter path to EXPORT2 CD [/sapcd] /oracle/IDS/sapreorg/EXPORT2 Directory to copy EXPORT2 CD [/oracle/IDS/sapreorg/CD5_DIR] Enter Enter path to EXPORT3 CD [/sapcd] /oracle/IDS/sapreorg/EXPORT3 Directory to copy EXPORT3 CD [/oracle/IDS/sapreorg/CD6_DIR] Enter Enter path to EXPORT4 CD [/sapcd] /oracle/IDS/sapreorg/EXPORT4 Directory to copy EXPORT4 CD [/oracle/IDS/sapreorg/CD7_DIR] Enter Enter path to EXPORT5 CD [/sapcd] /oracle/IDS/sapreorg/EXPORT5 Directory to copy EXPORT5 CD [/oracle/IDS/sapreorg/CD8_DIR] Enter Enter path to EXPORT6 CD [/sapcd] /oracle/IDS/sapreorg/EXPORT6 Directory to copy EXPORT6 CD [/oracle/IDS/sapreorg/CD9_DIR] Enter Enter amount of RAM for SAP + DB 850Enter (megabyte) Service Entry Message Server [3600] Enter Enter Group-ID of sapsys [101] Enter Enter Group-ID of oper [102] Enter Enter Group-ID of dba [100] Enter Enter User-ID of sidadm [1000] Enter Enter User-ID of orasid [1002] Enter Number of parallel procs [2] Enter Ha a CD-ket nem különbözõ helyekre másoltuk, akkor az &sap; telepítõje nem fogja megtalálni a ezeket (a rajtuk levõ LABEL.ASC segít neki az azonosításban) és kérni fogja a CD csatlakoztatását, illetve a csatlakozási pontjának megadását. A CENTRDB.R3S sem minden esetben mentes a hibáktól. A tapasztalataink szerint az EXPORT4 címkéjû CD-t kérte újra, miközben a helyes kulcsokat jelezte ki (6_LOCATION, majd 7_LOCATION stb.), így egyszerûen csak lépjünk tovább az értékek meghagyásával. Függetlenül az iménti megemlített problémáktól, egészen az &oracle; adatbáziskezelõ telepítéséig mindennek mûködnie kellene. Az <command>R3SETUP</command> 4.6C SR2 elindítása Állítsuk be jól az LD_LIBRARY_PATH környezeti változó értékét. Ez némileg eltér a 4.6B és az &oracle; 8.0.5 párosának beállításától: &prompt.root; export LD_LIBRARY_PATH=/sapmnt/PRD/exe:/oracle/PRD/817_32/lib A telepítés könyvtárából root felhasználóként indítsuk el az R3SETUP programot: &prompt.root; cd /oracle/PRD/sapreorg/install &prompt.root; ./R3SETUP -f CENTRAL.R3S A szkript ezek után feltesz néhány kérdést (az alapértelmezett válaszok zárójelben, közvetlenül a megadottak után): Kérdés Alapértelmezés Válasz Enter SAP System ID [C11] PRDEnter Enter SAP Instance Number [00] Enter Enter SAPMOUNT Directory [/sapmnt] Enter Enter name of SAP central host [majestix] Enter Enter Database System ID [PRD] PRDEnter Enter name of SAP db host [majestix] Enter Select character set [1] (WE8DEC) Enter Enter Oracle server version (2) Oracle 8.1.7 2Enter Extract Oracle Client archive [1] (Yes, extract) Enter Enter path to KERNEL CD [/sapcd] /oracle/PRD/sapreorg/KERNEL Enter amount of RAM for SAP + DB 2044 1800Enter (megabyte) Service Entry Message Server [3600] Enter Enter Group-ID of sapsys [100] Enter Enter Group-ID of oper [101] Enter Enter Group-ID of dba [102] Enter Enter User-ID of oraprd [1002] Enter Enter User-ID of prdadm [1000] Enter LDAP support 3Enter (nincs támogatás) Installation step completed [1] (continue) Enter Choose installation service [1] (DB inst,file) Enter Az OSUSERDBSID_IND_ORA és OSUSERIDADM_IND_ORA lépésekben az orasid és sidadm) felhasználók létrehozása hibákra futhat. Függetlenül az említett problémáktól, az &oracle; adatbáziskezelõ telepítéséig mindennek remekül kell mûködnie. Az &oracle; 8.0.5 telepítése Az &oracle; Linux változatának telepítése során felmerülõ problémák tekintetében keressük fel az &sap; füzeteket és az &oracle; Readme állományait. A legtöbb, ha nem is az összes gondot az egymással nem kompatibilis függvénykönyvtárak okozzák. Az &oracle; telepítésének részleteit a Az &oracle; telepítése címû szakaszban találjuk. Az &oracle; 8.0.5 telepítése az <command>orainst</command> segítségével Az &oracle; 8.0.5 verziójának használata esetén néhány további függvénykönyvtár újralinkelésére is szükség lesz, mivel az &oracle; 8.0.5 még a régi glibc könyvtárral lett fordítva (RedHat 6.0), viszont a RedHat 6.1 már a glibc újabb verzióját használja. A linkelés mûködéséhez az alábbi csomagokat kell még telepítenünk: compat-libs-5.2-2.i386.rpm compat-glibc-5.2-2.0.7.2.i386.rpm compat-egcs-5.2-1.0.3a.1.i386.rpm compat-egcs-c++-5.2-1.0.3a.1.i386.rpm compat-binutils-5.2-2.9.1.0.23.1.i386.rpm A részleteket lásd az &sap; füzeteiben vagy az &oracle; Readme állományaiban. Amennyiben ez nem oldható meg, akkor az eredeti binárisok, esetleg az eredeti RedHat rendszerbõl származó újralinkelt binárisok is használhatóak (habár a telepítés pillanatában személyesen ezt nem tudtuk ellenõrizni). Az intelligens ügynök lefordításához fel kell raknunk a RedHat saját Tcl csomagját. Ha ehhez nem tudjuk beszerezni a tcl-8.0.3-20.i386.rpm csomagot, akkor a RedHat 6.1 változatához készült tcl-8.0.5-30.i386.rpm is megteszi. Az újralinkeléstõl eltekintve a telepítés többi része szinte adja magát: &prompt.root; su - oraids &prompt.root; export TERM=xterm &prompt.root; export ORACLE_TERM=xterm &prompt.root; export ORACLE_HOME=/oracle/IDS &prompt.root; cd $ORACLE_HOME/orainst_sap &prompt.root; ./orainst Az &oracle; On-Line Text Viewer kikapcsolásán (mivel az jelenleg nem Linux alatt sem érhetõ el) kívül mindegyik képernyõt hagyjuk jóvá az Enter billentyû lenyomásával. Az &oracle; ezután a rendelkezésre álló gcc, egcs vagy i386-redhat-linux-gcc helyett a i386-glibc20-linux-gcc használatával újra akarjuk linkelni magát. Idõ hiányában az &oracle; 8.0.5 PreProduction kiadásából emeltünk ki binárisokat, de az adatbáziskezelõ rendszer felélesztésére tett elsõ kísérleteink kudarcba fulladtak, és ezután a megfelelõ RPM-ek összeszedése valódi rémálomnak bizonyult. Az &oracle; 8.0.5 Pre-production Release for Linux (Kernel 2.0.33) telepítése A telepítés nagyon könnyû. Csatlakoztassuk a CD-t, majd indítsuk el a telepítõt. Ezután meg kell adnunk az &oracle; felhasználói könyvtárát és a telepítõ odamásolja az összes binárist. Habár a telepítés megkezdése elõtt a korábbi kísérleteink nyomát nem tüntettük el. Ezt követõen az &oracle; adatbázisrendszer minden további gond nélkül elindítható. Az &oracle; 8.1.7 Linux változatának telepítése Szedjük le az oracle8172.tgz állományt a Linux rendszeren létrehozott könyvtárából, és bontsuk ki a /oracle/SID/817_32/ könyvtárba. Az &sap.r3; telepítésének folytatása Elõször is ellenõrizzük az isamd (sidadm) és oraids (orasid) felhasználók környezeti beállításait. A .profile, .login és .cshrc állományaikban a korábbi beállítások szerint kell szerepelnie a hostname parancsnak. Ha még mindig a teljes hálózati név lenne meg bennünk, akkor a hostname parancsot át kell írni mind a három állományban a hostname -s parancsra. Az adatbázis feltöltése Ezután az R3SETUP folytatható vagy újraindítható (attól függõen, hogy a kilépés választottuk-e vagy sem). Az R3SETUP ekkor létrehozza az adatbázisban a táblákat és az R3load meghívásával feltölti ezeket adatokkal (a 46B IDES változat esetében az EXPORT1 - EXPORT6, a 46C esetében pedig a DISK1 - DISK4 lemezekrõl). Amikor a feltöltés befejezõdõtt (ami akár órákig is eltarthat), szükség lesz még néhány jelszó megadására is. A próbatelepítéseknél nyugodtan használhatjuk a jól ismert alapértelmezett jelszavakat (azonban mindenképpen változtassuk meg ezeket, ha egy kicsit is számít a biztonság!): Kérdés Válasz Enter Password for sapr3 sapEnter Confirum Password for sapr3 sapEnter Enter Password for sys change_on_installEnter Confirm Password for sys change_on_installEnter Enter Password for system managerEnter Confirm Password for system managerEnter A 4.6B telepítése során még gondjaink akadtak a dipgntab használatával. Az &oracle; Listener elindítása Így kell elindítani az orasid felhasználóval az &oracle; Listenert: &prompt.user; umask 0; lsnrctl start Ha máshogy próbálkozunk, akkor az ORA-12546 kódú hibát fogjuk kapni, mert a hálózati portok socketei nem rendelkeznek a szükséges engedélyekkel. Lásd a 072984-es &sap; füzet. Az MNLS táblák frissítése Ha nem Latin 1 kódolású nyelveket akarunk importálni az &sap; rendszerbe, akkor frissítenünk kell a többnyelvû nyelvi támogatáshoz (Multi National Language Support, MNLS) tartozó táblázatokat. Ezek bemutatását a 15023 és 45619 számú &sap; OSS füzetekben olvashatjuk. Minden más esetben az &sap; telepítésekor nyugodtan kihagyhatjuk. Ha még nincs is konkrétan szükségünk az MNLS-re, akkor is ellenõriznünk és inicializálnunk kell a TCPDB táblát. A 0015023 és 0045619 számú &sap; füzetekben tudhatunk meg errõl többet. Telepítés utáni teendõk Az &sap.r3; licenckulcsának megszerzése Az &sap.r3; licenckulcsát külön kell kérni. Fontos, mert a telepítéshez használatos ideiglenes licenc csak négy hétig érvényes. Elõször szerezzük meg a hardverkulcsot. Jelentkezzünk be az idsadm felhasználóval és adjuk ki a saplicense parancsot: &prompt.root; /sapmnt/IDS/exe/saplicense -get Ha a saplicense paraméter nélkül meghívására válaszul opciókat listáz ki. A licenckulcsot megérkezése után így tudjuk élesíteni: &prompt.root; /sapmnt/IDS/exe/saplicense -install Ezután a következõ értékeket kell megadni: SAP SYSTEM ID = SID, 3 karakter CUSTOMER KEY = hardverkulcs, 11 karakter INSTALLATION NO = telepítés száma, 10 számjegy EXPIRATION DATE = ééééhhnn, tehát "99991231" LICENSE KEY = licenckulcs, 24 karakter A felhasználók létrehozása Hozzunk létre egy felhasználót a 000 kliensen belül (a csak rajta belül elvégezhetõ feladatokhoz, aki különbözik a sap* és ddic felhasználóktól). Felhasználónévként általában a wartung nevet választottuk (ami angolul a service névnek, avagy szolgáltatásnak felel meg). A sap_new és sap_all nevû profilok is kellenek. A biztonságosság kedvéért a kliens összes alapértelmezett felhasználójának (beleértve a sap* és ddic felhasználókat is) változtassuk meg a jelszavát. A szállítási rendszer, a profilok, mûködési módok stb. beállítása A ddic és sap* felhasználóktól eltérõ nevû felhasználóval a 000 kliensen belül legalább a következõket végezzük el: Feladat Tranzakció A szállítási rendszer (Transport System) beállítása, például a Stand-Alone Transport Domain Entity értékre STMS A rendszer profiljának létrehozása és szerkesztése RZ10 A mûködési módok és példányok karbantartása RZ04 Az iménti és az összes többi telepítés utáni lépések leírása teljes egészében megtalálható az &sap; telepítési útmutatóiban. Az <filename>init<replaceable>sid</replaceable>.sap</filename> (<filename>initIDS.sap</filename>) szerkesztése Az /oracle/IDS/dbs/initIDS.sap állomány tartalmazza a &sap; tartalék profilját. Itt többek közt a használni kívánt szalag méretét, a tömörítés típusát és hasonló paramétereket kell definiálni. A sapdba / brbackup futtatásához a következõ értékeket változtattuk meg: compress = hardware archive_function = copy_delete_save cpio_flags = "-ov --format=newc --block-size=128 --quiet" cpio_in_flags = "-iuv --block-size=128 --quiet" tape_size = 38000M tape_address = /dev/nsa0 tape_address_rew = /dev/sa0 Magyarázat: compress (tömörítés): HP DLT1 típusú szalagot használtunk, ami tud hardveres tömörítést. archive_function (archiválási házirend): Ez adja meg, hogy alapértelmezés szerint mi történjen az &oracle; archívált naplóival: az új naplóállományok elõször a szalagra mentõdnek, majd a már lementett naplók ismét mentésre kerülnek és végül törlõdnek. Ezzel sok fejfájástól menekülünk meg, mivel ilyenkor az archiváló szalagok esetleges sérülése esetén is valószínûleg képesek leszünk visszaállítani az adatbázist. cpio_flags (a cpio beállítása): A használata alapértelmezés, amivel a blokkok mérete 5120 byte-ra állítódik. A DLT típusú szalagokhoz a HP legalább 32 KB-os blokkméretet javasolt, ezért a beállítással ezt 64 KB-ra növeltük. Szükségünk volt a beállításra is, mivel 65535-nél több inode számunk van. Az utolsó beállítás a , amivel megakadályozzuk, hogy a cpio lementett blokkokat összefoglaló kijelzésére begerjedjen a brbackup. cpio_in_flags (a cpio bemeneti beállításai): A szalagok visszatöltésénél használt beállítások. A formátumot automatikusan felismeri. tape_size (szalagméret): Ezzel adjuk meg általában a szalag nyers kapacitását. Biztonsági okokból (hardveres tömörítést használunk) ez az érték a ténylegesnél valamivel kisebb. tape_address (szalagos eszköz): a cpio által használható nem visszatekerhetõ eszköz. tape_address_rew (visszatekerhetõ szalagos eszköz): A cpio által használható visszatekerhetõ eszköz. Telepítés utáni beállítások Az &sap; alábbi paramétereit kell beállítani a telepítés után (IDES 46B, 1 GB memóriával): Név Érték ztta/roll_extension 250000000 abap/heap_area_dia 300000000 abap/heap_area_nondia 400000000 em/initial_size_MB 256 em/blocksize_kB 1024 ipc/shm_psize_40 70000000 0013026 &sap; füzet: Név Érték ztta/dynpro_area 2500000 0157246 &sap; füzet: Név Érték rdisp/ROLL_MAXFS 16000 rdisp/PG_MAXFS 30000 A fenti paraméterek használatával egy 1 gigabyte fizikai memóriával rendelkezõ rendszer esetén nagyjából így alakul a memóriahasználat: Mem: 547M Active, 305M Inact, 109M Wired, 40M Cache, 112M Buf, 3492K Free (547 MB aktív, 305 MB inaktív, 109 MB rögzített, 40 MB gyorsítótár, 112 MB puffer, 3492 KB szabad) A telepítés során adódó problémák Az <command>R3SETUP</command> újraindítása egy probléma kijavítása után Az R3SETUP hiba esetén leáll. Miután átnéztük a hibára utaló naplókat és elhárítottuk a hiba okát, újra el kell indítanunk az R3SETUP programot, majd a REPEAT opció kiválasztásával próbáljuk megismételni az R3SETUP által kifogásolt legutóbbi mûveletet. Az R3SETUP újraindításához egyszerûen adjuk meg a megfelelõ R3S állományt: &prompt.root; ./R3SETUP -f CENTRDB.R3S a 4.6B verzió esetén, vagy a &prompt.root; ./R3SETUP -f CENTRAL.R3S a 4.6C verzió esetén, függetlenül attól, hogy a hiba a CENTRAL.R3S vagy DATABASE.R3S állományoknál keletkezett. Egyes lépéseknél az R3SETUP úgy véli, hogy az &sap; programjai mûködnek (mivel a hozzájuk tartozó lépéseket már megtettük), így a hibák miatt az adatbázist esetleg korábban nem tudta elindítani. Ezért a hibák kijavításának végeztével az R3SETUP ismételt indítása elõtt nekünk kell beindítani mind az adatbázist, mind pedig az &sap; rendszert. Ne felejtsük el újra elindítani az &oracle; Listener segédprogramját sem (az orasid felhasználóval adjuk ki a umask 0; lsnrctl start parancsot), ha az idõközben leállt volna (például a rendszer kényszerû újraindítása miatt). OSUSERSIDADM_IND_ORA az <command>R3SETUP</command> közben Ha az R3SETUP panaszkodik ebben a lépésben, akkor írjuk át az általa ekkor használt sablont (a 4.6B esetén ez a CENTRDB.R3S, illetve a 4.6C esetén ez a CENTRAL.R3S vagy a DATABASE.R3S). Keressük a [OSUSERSIDADM_IND_ORA] szöveget, vagy csak a STATUS=ERROR bejegyzést, majd írjuk be a következõ értékeket: HOME=/home/sidadm (üres volt) STATUS=OK (ERROR státusza volt) Ezután indítsuk újra az R3SETUP programot. OSUSERDBSID_IND_ORA az <command>R3SETUP</command> közben Az R3SETUP ebben a lépésben is hajlamos panaszkodni. Az itt felbukkanó hiba hasonló az OSUSERSIDADM_IND_ORA lépésben jelentkezõhöz. Szerkesszük át az R3SETUP által ilyenkor használt sablont (4.6B verzió esetén ez a CENTRDB.R3S, illetve 4.6C verziónál a CENTRAL.R3S vagy DATABASE.R3S). Keressük meg a [OSUSERDBSID_IND_ORA] részt, vagy csak a STATUS=ERROR bejegyzést, majd írjuk át az ebben a szakaszban szereplõ értéket így: STATUS=OK Indítsuk újra az R3SETUP programot. <errorname>oraview.vrf FILE NOT FOUND</errorname> hiba az &oracle; telepítése közben A telepítés megkezdése elõtt nem tiltottuk le az &oracle; On-Line Text Viewer felrakását. Habár Linux esetén ez nem használható, alapértelmezés szerint mégis ki van választva. Az &oracle; telepítõ menüjében tiltsuk le ezt és nélküle kezdjük újra a telepítést. <errorname>TEXTENV_INVALID</errorname> hiba az <command>R3SETUP</command>, RFC vagy SAPgui Start programokban Ha ilyen hibával kerülünk szembe, akkor hiányoznak a megfelelõ nyelvi állományok. A 0171356 &sap; füzet tartalmazza a telepítendõ RPM csomagok felsorolását (például a RedHat 6.1 esetén a saplocales-1.0-3 és saposcheck-1.0-1). Amennyiben figyelmen kívül hagyjuk az ilyen hibákat, és az R3SETUP minden kiakadásánál átírjuk (a CENTRDB.R3S állományban) az STATUS értékét az ERROR értékrõl az OK értékre és újraindítjuk, az &sap; nem állítódik be jól és nem tudunk a SAPgui alkalmazással rácsatlakozni a frissen telepített rendszerre még akkor sem, ha el tudtuk indítani. Amikor a régebbi linuxos SAPgui alkalmazással csatlakozunk, a következõ üzeneteket kapjuk: Sat May 5 14:23:14 2001 *** ERROR => no valid userarea given [trgmsgo. 0401] Sat May 5 14:23:22 2001 *** ERROR => ERROR NR 24 occured [trgmsgi. 0410] *** ERROR => Error when generating text environment. [trgmsgi. 0435] *** ERROR => function failed [trgmsgi. 0447] *** ERROR => no socket operation allowed [trxio.c 3363] Speicherzugriffsfehler Ez a viselkedés annak köszönhetõ, hogy az &sap.r3; nem képes jól összerendelni a nyelvi beállításokat, sõt, magát sem képes jól beállítani (hiányoznak némely bejegyzések az adatbázis egyes tábláiban). Az &sap;-hez úgy tudunk ilyenkor csatlakozni, ha a DEFAULT.PFL állományba felvesszük a következõ bejegyzéseket (lásd 0043288 füzet): abap/set_etct_env_at_new_mode = 0 install/collate/active = 0 rscp/TCP0B = TCP0B Majd indítsuk újra az egész &sap; rendszert. Ezután már tudunk csatlakozni hozzá, még ha az országra jellemzõ nyelvi beállítások nem is mûködnek tökéletesen. Miután korrigáltuk az ország beállításait (és felraktuk a megfelelõ nyelvi állományokat), távolítsuk el az iménti bejegyzéseket a DEFAULT.PFL állományból és indítsuk újra az &sap; rendszert. Az <errorcode>ORA-00001</errorcode> hiba Ez a hiba &os; alatt az &oracle; 8.1.7 használata során következhet be. Akkor történik, amikor az &oracle; adatbázis nem volt képes rendesen inicializálni magát és összeomlott, aminek révén szemaforokat és memóriát hagyott megosztva a rendszerben. Így az adatbázis következõ indításakor kapunk egy kövér ORA-00001 hibát. Az ipcs -a paranccsal keressük meg ezeket, majd az ipcrm segítségével pedig számoljuk fel. Az <errorcode>ORA-00445</errorcode> (a PMON háttérprogram nem indult el) hiba Ez a hiba az &oracle; 8.1.7 használatakor következhet be. Akkor kapjuk ezt a hibát, amikor prdadm felhasználóként a elindítjuk startsap szkriptet (például startsap_majestix_00). Erre gyógyír lehet, ha ehelyette az adatbázis elindításához az oraprd felhasználóval adjuk ki az svrmgrl parancsot: &prompt.user; svrmgrl SVRMGR> connect internal; SVRMGR> startup; SVRMGR> exit Az <errorcode>ORA-12546</errorcode> (A Listener indítása megfelelõ engedélyekkel) hiba Az &oracle; Listener alkalmazását oraids felhasználóként az alábbi paranccsal indítsuk el: &prompt.root; umask 0; lsnrctl start Máskülönben ORA-12546 hibát kapunk, mivel a hálózati portokhoz tartozó socketek nem rendelkeznek a megfelelõ engedélyekkel. Lásd 0072984 &sap; füzet. Az <errorcode>ORA-27102</errorcode> (Nincs elég memória) hiba Akkor fordul elõ ilyen hiba, amikor a MAXDSIZ és DFLDSIZ értékeit 1 GB-nál (1024 x 1024 x 1024-nél) nagyobbra állítottuk. Mellé még kapunk egy Linux Error 12: Cannot allocate memory hibát is. [DIPGNTAB_IND_IND] az <command>R3SETUP</command> közben Errõl alapvetõen a 0130581 számú &sap; füzet ad tájékoztatást (az R3SETUP DIPGNTAB lépése hibára fut). Az IDES telepítése során az &sap; rendszer valamiért az IDS név helyett egy üres karakterláncot használ. Ez a könyvtárak elérésében kisebb gondokat okoz, mivel az elérési útvonaluk a SID-bõl generálódik (ami ebben az esetben az IDS). Tehát a /usr/sap/IDS/SYS/... /usr/sap/IDS/DVMGS00 helyett a következõt próbálja meg elérni: /usr/sap//SYS/... /usr/sap/D00 A telepítés folytatásához létrehoztunk egy linket és egy másik könyvtárat: &prompt.root; pwd /compat/linux/usr/sap &prompt.root; ls -l total 4 drwxr-xr-x 3 idsadm sapsys 512 May 5 11:20 D00 drwxr-x--x 5 idsadm sapsys 512 May 5 11:35 IDS lrwxr-xr-x 1 root sapsys 7 May 5 11:35 SYS -> IDS/SYS drwxrwxr-x 2 idsadm sapsys 512 May 5 13:00 tmp drwxrwxr-x 11 idsadm sapsys 512 May 4 14:20 trans Észrevettük, hogy a &sap; füzetekben (0029227 és 0008401) ugyanezt a viselkedést írják le. Az &sap; 4.6C telepítésénél azonban ilyen hibával nem találkoztunk. [RFCRSWBOINI_IND_IND] az <command>R3SETUP</command> közben Az &sap; 4.6C telepítése folyamán ez a hiba csupán egy korábban bekövetkezett másik hiba utóhatása volt. Itt át kell néznünk az összes érintett naplót és ki kell javítanunk a tényleges problémát. Amennyiben a naplók átvizsgálása után csak ezt találjuk egyedüli hibának (lásd &sap; füzetek), állítsuk át (a CENTRDB.R3S állományban) a STATUS értékét az OK értékre, majd indítsuk újra az R3SETUP programot. A telepítés befejezése után hajtsuk végre az SE38 tranzakcióból az RSWBOINS riportot. A további RFCRSWBOINI és RFCRADDBDIF lépésekkel kapcsolatban lásd a 0162266 &sap; füzetet. [RFCRADDBDIF_IND_IND] az <command>R3SETUP</command> közben Itt az elõbbihez hasonló feltételek élnek: mindenképpen ellenõrizzük a naplókban, hogy a hibát nem egy korábban keletkezett hiba okozta. Ha tényleg csak az 0162266 &sap; füzetben leírtak érvényesek, akkor (a CENTRDB.R3S állományban) állítsuk a gondot okozó lépés STATUS értékét az ERROR értékrõl az OK értékre, és indítsuk újra az R3SETUP programot. A telepítés után pedig hajtsuk végre az SE38 tranzakciból az RADDBDIF riportot. A <errorcode>sigaction sig31: File size limit exceeded</errorcode> hiba Ez a disp és work &sap; programok indítása során történhet meg. Az &sap; rendszert indító startsap szkriptrõl leválva indulnak el a többi &sap; program elindításáért felelõs alfolyamatok. Ennek eredményeképpen a szkript maga nem fogja észrevenni a hibát. Az &sap; programok elindulását az ps ax | grep SID paranccsal tudjuk ellenõrizni. Az eredményül kapott listában az összes aktív &oracle; és &sap; programnak szerepelnie kell. Ha ebbõl az tûnik ki, hogy bizonyos programok hiányoznak, vagy nem képesek kapcsolódni az &sap; rendszerhez, akkor az /usr/sap/SID/DVEBMGSnr/work/ könyvtárban nézzük át a hozzájuk tartozó naplóállományokat. Elsõsorban a dev_ms és a dev_disp állományok fontosak számunkra. A 31-es jelzés akkor keletkezik, ha az &oracle; és az &sap; által használt osztott memória mértéke meghaladja a rendszermag beállításai közt megadott értéket. Ezt tehát ennek növelésével lehet orvosolni: # az éles 46C rendszereknek több kell: options SHMMAXPGS=393216 # a 46B beéri kevesebbel is: #options SHMMAXPGS=262144 A <command>saposcol</command> nem indul A saposcol (4.6D verzió) programmal akad néhány probléma. Az &sap; rendszer az saposcol segítségével próbál adatokat gyûjteni a rendszer teljesítményérõl. Mivel ez a program nem feltétlenül szükséges az &sap; rendszer mûködéséhez, ez a probléma nem tekinthetõ komolynak. A korábbi (4.6B) verziókban ugyan mûködik, de semmilyen adatot nem képes begyûjteni (mivel a legtöbb hívás, például a processzorhasználat függvénye, egyszerûen csak nullát ad vissza). Témák haladóknak Ha kíváncsiak vagyunk a Linux emuláció mûködésére, olvassuk el ezt a szakaszt. Az itt ismertettek leginkább Terry Lambert (tlambert@primenet.com) &a.chat; címére írt levele nyomán kerülnek bemutatásra (Az üzenet azonosítója: <199906020108.SAA07001@usr09.primenet.com>). Hogyan mûködik? végrehajtási osztály betöltõ A &os; rendelkezik egy ún. végrehajtási osztály betöltõvel (execution class loader). Ez lényegében a &man.execve.2; rendszerhívás alatt meghúzódó absztrakciós réteg. A &os;-nek a #! karaktersorozat hatására parancsértelmezõk vagy a hozzájuk tartozó szkriptek betöltésére utasító biztonsági betöltõ helyett van egy listája az alkalmas betöltõkrõl. A &unix; rendszerek a hagyományok szerint egyetlen betöltõvel rendelkeznek, ami elõször megvizsgálja a betölteni kívánt állomány bûvös számát (ami általában az elsõ 4 vagy 8 byte) és ez alapján eldönti, hogy az adott formátum támogatott-e. Amennyiben ez így van, meghívja a betöltõt. Ha a bináris típusa nem ismert a rendszer számára, akkor az &man.execve.2; hívás hibával tér vissza, és a parancsértelmezõ próbálja meg a saját parancsaiként értelmezni. Eddig ez volt az alapértelmezés, akármilyen parancsértelmezõnk is volt. Késõbb az &man.sh.1; kódjába bekerült egy aprócska okosítás, amivel megnézte az állomány elsõ két karakterét, és ha az :\n volt, akkor a futtatáshoz maga helyett a &man.csh.1; parancsértelmezõt hívta meg (ezt állítólag elõször a SCO csinálta). A &os; viszont végignézi a betöltõk teljes listáját, amiben a sor végén szerepel egy általános #! formátumú betöltõ. Ez az állomány futtatásához használatos értelmezõk kódját keresi, és ha egyet sem sikerül azonosítania, akkor a /bin/sh programot indítja el. ELF A Linux ABI támogatását a &os; úgy oldja meg, hogy elõször észleli az ELF bináris bûvös számát (ekkor még nem tesz különbséget a &os;, &solaris;, Linux vagy más ELF típusú binárisokat használó operációs rendszerek közt). Solaris Ezután az ELF formátum betöltõje az ELF állomány megjegyzéseket tároló szakaszában bélyegek (brand) után kutat, ami SVR4 és &solaris; ELF binárisok esetén nem létezik. A Linux binárisokat mûködésükhöz a &man.brandelf.1; segítségével Linux típusúnak kell megbélyegezni: &prompt.root; brandelf -t Linux állomány Miután ezt megcsináltuk, az ELF betöltõ észre fogja venni az állomány Linux típusát. ELF megbélyegzés Mikor az ELF betöltõ észleli, hogy az állomány Linux típusú, kicseréli egy mutató értékét a proc struktúrában. Minden rendszerhívás ezen a mutatón keresztül érhetõ el (a hagyományos &unix; rendszerekben ez a rendszerhívásokat tartalmazó sysent[] struktúratömb). Emellett a frissen elindított program szoftveres megszakításait tartalmazó tömbjéhez beállítja a speciális jelzések kezelését, valamint a Linux modul által végzett néhány további (kisebb) javítást. A Linux rendszerhívásokat tartalmazó tömb többek közt tartalmazza a sysent[] bejegyzések egy listáját, amelyek címei a rendszermag Linux moduljára mutatnak. Amikor a Linux bináris hív egy rendszerhívást, a hozzátartozó szoftveres megszakítás kódja a proc struktúrából a neki megfelelõ rendszerhívás kódját hivatkozza, így &os; rendszerhívás belépési pontja helyett a Linuxét kapja meg. Ráadásul Linux módban a különbözõ állományok hivatkozásai is átirányítódnak. Ez lényegében olyan, mint amit az állományrendszerek csatlakoztatásánál a beállítás csinál (ami nem egyezik meg az unionfs állományrendszerrel!). Ilyenkor az állományokat elõször a /compat/linux/eredeti-hely könyvtárában keresi, és majd ha ott nem találja, csak akkor kezdi el keresni az /eredeti-hely ponton. Ezzel oldhatjuk meg, hogy más binárisok futtatását igénylõ binárisok is képesek legyenek rendesen mûködni (például így az egész linuxos eszköztár tud futni a Linux ABI-n keresztül). Egyúttal arra is utal, hogy ha a Linux binárisok számára nem áll rendelkezésre a megfelelõ bináris, akkor &os; binárisokat is el tudnak indítani. Ha a &man.uname.1; programot pedig bemásoljuk a /compat/linux könyvtáron belülre, akkor a Linux binárisok képtelenek lesznek megmondani, hogy nem Linux alatt futnak. Így lényegében egy Linux magot találunk a &os; rendszermagjában. A benne megtalálható különbözõ szolgáltatásokat megvalósító függvények: az állománymûveletek, a virtuális memória kezelése, a jelzések küldése és System V típusú folyamatok közti kommunikáció stb. megegyeznek a &os; és a Linux hívásai esetén egyaránt. Egyetlen eltérés, hogy a &os; binárisok a &os; segédfüggvényein (glue function), a Linux binárisok pedig a Linux segédfüggvényein keresztül férnek hozzájuk (a legelsõ operációs rendszerek tulajdonképpen csak a saját segédfüggvényeiket tartalmazták: a hívást kezdeményezõ program proc struktúrájában a függvények dinamikusan beállított címe helyett egy globális sysent[] struktúratömbben tárolták a meghívható függvényeket). Melyik közülük a &os; natív ABI-ja? Ez teljesen lényegtelen. Alapvetõen az egyetlen különbség csupán annyi (pillanatnyilag, de ez a jövõben még változhat, valószínûleg hamarosan), hogy a &os; segédfüggvényei statikusan megtalálhatóak a rendszermagban, míg a Linux segédfüggvényei egyaránt elérhetõek modulból vagy statikus linkeléssel. Na igen, de akkor ez most emuláció? Nem. Ez egy ABI, nem emuláció. Itt szó sincs emulátorról (ahogy szimulátorról sincs). De akkor mégis miért hívják ezt sokszor Linux emulációnak? Hát hogy nehezebb legyen eladni a &os;-t! Komolyra fordítva a szót: ennek a kezdeti változata akkoriban született meg, amikor erre még nem volt rendes szó. Nem mondhattuk, hogy a &os; befordítás vagy egy modul betöltése nélkül képes lett volna Linux binárisokat futtatni, ezért valamilyen módon meg kellett neveznünk az ilyenkor betöltött kódot — ebbõl lett a Linux emulátor. diff --git a/hu_HU.ISO8859-2/books/handbook/mac/chapter.sgml b/hu_HU.ISO8859-2/books/handbook/mac/chapter.sgml index ed045a505b..c712d9c992 100644 --- a/hu_HU.ISO8859-2/books/handbook/mac/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/mac/chapter.sgml @@ -1,2981 +1,2981 @@ Tom Rhodes Írta: Kötelezõ hozzáférés-vezérlés Áttekintés MAC kötelezõ hozzáférés-vezérlés MAC A &os; 5.X változata új biztonsági bõvítéseket vett át a TrustedBSD projektbõl a &posix;.1e nyomán. A két legjelentõsebb új biztonsági mechanizmus az állományrendszerekben megtalálható hozzáférés-vezérlési listák (Access Control List, ACL) és a kötelezõ hozzáférés-vezérlés (Mandatory Access Control, MAC). A kötelezõ hozzáférés-vezérlés segítségével olyan új hozzáférés-vezérlési modulok tölthetõek be, amelyek új biztonsági házirendeket implementálnak. Némelyek közülük védelmet nyújtanak a rendszer egy szûk részének, amivel így egy adott szolgáltatást bástyáznak alá. Mások minden részletre kiterjedõ címkézett biztonságot szolgáltatnak alanyokon és objektumokon keresztül. A meghatározás kötelezõ része onnan fakad, hogy a szabályok betartatását a rendszergazdák és a rendszer végzik, és nem bízzák a felhasználókra, ahogy azt a System V típusú rendszerekben a szabványos állományokra és IPC-re érvényes engedélyeken keresztül a tetszés szerinti hozzáférés-vezérlés (Discretionary Access Control, DAC) teszi. Ebben a fejezetben a kötelezõ hozzáférés-vezérlést övezõ keretrendszerre (MAC Framework) és a különbözõ biztonsági házirendeket megvalósító, beilleszthetõ modulokra fogunk összpontosítani. A fejezet elolvasása során megismerjük: hogy a &os; jelen pillanatban milyen modulokat tartalmaz a MAC rendszeren belül és milyen mechanizmusok tartoznak hozzájuk; hogy a MAC biztonsági házirendjeit képezõ modulok miket valósítanak meg, valamint mi a különbség a címkézett és címkézetlen házirendek között; hogyan kell hatékonyan beállítani és használni rendszerünkben a MAC rendszert; hogyan állítsuk be a MAC rendszerben található különféle biztonsági házirendeket képezõ modulokat; hogyan hozzunk létre a MAC rendszer segítségével egy biztonságosabb környezetet, amire példákat is mutatunk; hogyan teszteljük le a MAC rendszer beállításait és bizonyosodjunk meg mûködésének helyességérõl. A fejezet elolvasásához ajánlott: a &unix; és a &os; alapjainak ismerete () a rendszermag beállításának és lefordításának ismerete () tisztában lenni az alapvetõ biztonsági kérdésekkel és azok hatásával a &os;-n belül () Az itt ismertetésre kerülõ információk helytelen alkalmazása a rendszer hozzáférhetõségének teljes elvesztését, a felhasználók bosszantását vagy az X11 által felkínált lehetõségek kirekesztését eredményezheti. Ami viszont ennél is fontosabb, hogy a MAC rendszerre nem úgy kell tekinteni, mint amitõl a rendszerünk tökéletesen biztonságossá válik. A MAC segítségével csupán a meglevõ biztonsági házirendeket gyarapítjuk. A szilárd biztonsági rutin és a rendszeres ellenõrzések elvégzése nélkül a rendszerünk valójában sosem lesz teljesen biztonságos. Hozzá kell tennünk, hogy a fejezetben bemutatott példák tényleg csak példák. Senkinek sem tanácsoljuk, hogy az itt említett beállításokat egy éles rendszerre is kiterjessze. A különbözõ biztonsági modulok felépítése rengeteg gondolkodást és próbálgatást igényel. Aki nem érti meg az egész mûködését, könnyen azon kaphatja magát, hogy újra végig kell mennie a rendszeren és egyenként be kell állítania minden könyvtárat és állományt. Amivel itt nem foglalkozunk Ebben a fejezetben a MAC rendszerrel kapcsolatban rengeteg biztonsági kérdéssel foglalkozni fogunk. Az új MAC biztonsági modulok kifejlesztését azonban már nem érintjük. Számos olyan biztonsági modul található a MAC rendszerben, amelyek rendelkeznek az új modulok kialakításához és teszteléséhez szükséges jellemzõkkel. Ilyenek többek közt a &man.mac.test.4;, &man.mac.stub.4; és a &man.mac.none.4;. Ezekrõl a biztonsági modulokról és az általuk szolgáltatott mechnanizmusokról a man oldalaik tudnak bõvebb tájékoztatást adni. A fejezet fontosabb fogalmai A fejezet tartalmának kifejtéséhez szükségünk lesz néhány fontosabb alapfogalom tisztázására. Segítségükkel vélhetõen sikerül eloszlatni a téma feldolgozása során felmerülõ félreértéseket, illetve elkerülni az új fogalmak és információk váratlan felbukkanását. alany: Alanynak tekintünk a rendszerben minden olyan aktív egyedet, amely információt áramoltat az objektumok, tehát a felhasználók, a processzorok, a rendszerben futó programok stb. között. A &os;-ben majdnem minden esetben a felhasználók egy szálon keresztül vezérlik a futó programokat. címke: A címke egy olyan biztonsági tulajdonság, ami vonatkozhat állományokra, könyvtárakra vagy a rendszer más elemeire. Egy címke tekinthetõ a bizalmasságot jelzõ pecsétnek is: ha egy állományra címkét teszünk, akkor benne megadjuk a rá vonatkozó biztonsági jellemzõket, és csak a hozzá hasonló biztonsági beállításokkal rendelkezõ állományok, felhasználók, erõforrások stb. érhetik el. A címkék jelentését és értelmezését a házirendek beállítása határozza meg: míg egyes házirendek a címkéket egy objektum sértetlenségének vagy titkosságának tekintik, addig mások a hozzáféréssel kapcsolatos szabályokat rögzítik bennük. egycímkés: Egycímkés esetrõl akkor beszélünk, amikor az adat áramlásának szabályozására az egész állományrendszer egyetlen címkét alkalmaz. Ha ezt beállítjuk egy állományrendszernél, de nem adjuk meg vele együtt a opciót, akkor az összes állományra ugyanaz a címke érvényes. erõs vízjel: Az erõs vízjel házirendje szerint a biztonsági szint akkor növelhetõ, ha magasabb szintû információkhoz akarunk hozzájutni. A legtöbb esetben a folyamatok befejezõdése után visszaállítódik az eredeti szint. A &os; MAC rendszere pillanatnyilag ehhez nem tartalmaz házirendet, de a teljesség kedvéért megadtuk ennek a definícióját is. gyenge vízjel: A gyenge vízjel házirendje szerint a biztonsági szint csökkenthetõ az alacsonyabb szintû információk elérése érdekében. A legtöbb esetben a folyamatok befejezõdése után visszaállítódik az eredeti szint. A &os;-ben ezt a házirendet egyedül a &man.mac.lomac.4; alkalmazza. házirend: Szabályok olyan gyûjteménye, amely megadja, hogy miként kell a célokat teljesíteni. Egy házirend általában az egyes elemek kezelését rögzíti. Ebben a fejezetben a házirend kifejezés alatt a biztonsági házirendet értjük, tehát olyan szabályok gyûjteményét, amelyek az adatok és az információ áramlását határozzák meg, továbbá megadják, hogy közülük ki mihez férhet hozzá. kényesség: Általában az MLS tárgyalásakor kerül elõ. Az kényesség szintjével az adatok fontosságát vagy titkosságát szokták jelölni. A kényességi szint növekedésével növekszik az adat titkosságának vagy bizalmasságának szintje. objektum: Objektum vagy rendszerobjektum minden olyan egyed, amelyen információ folyik keresztül az alanyok irányításával. Ezek lehetnek többek közt könyvtárak, állományok, mezõk, képernyõk, billentyûzetek, a memória, mágneses tárolóeszközök, nyomtatók vagy bármilyen más adattároló/hordozó eszköz. Az objektumok alapvetõen adattárolók vagy a rendszer erõforrásai. Egy objektum elérésén gyakorlatilag az adatok elérését értjük. rekesz: Egy rekeszbe soroljuk az elrekeszteni vagy elkülöníteni kívánt programok és adatok összeségét, ahol a felhasználók explicit módon képesek hozzáférni a rendszer bizonyos komponenseihez. Emellett a rekesz utalhat egy tetszõleges csoportosításra is, például munkacsoportra, osztályra, projektre vagy témára. A rekeszek használata elengedhetetlen a biztonsági házirendek kialakításához. sértetlenség: A sértetlenség, mint kulcsfogalom, az adatok megbízhatóságának szintje. Minél sértetlenebb az adat, annál inkább tekinthetjük megbízhatónak. szint: Egy biztonsági tulajdonság megnövelt vagy lecsökkentett beállítása. A szint növekedésével együtt a biztonság mértéke is növekszik. többcímkés: A vagyis többcímkés jellemzõ az állományrendszerek esetén fordulhat elõ, és a &man.tunefs.8; segédprogrammal állítható be egyfelhasználós módban vagy a rendszer indítása során az &man.fstab.5; állományon keresztül, esetleg egy új állományrendszer létrehozásakor. Ezzel a beállítással a rendszergazda különféle MAC címkéket rendelhet különbözõ objektumokhoz. Ez a beállítás természetesen csak olyan biztonsági modulok esetén él, amelyek tudnak címkézni. A MAC ismertetése Az imént definiált új fogalmak tükrében most nézzük meg, hogy a MAC rendszer alkalmazásával miként javíthatunk rendszerünk biztonságán. A MAC rendszerhez készített különbözõ biztonsági modulok alkalmasak a hálózat és az állományrendszerek védelmére, valamint segítségükkel megakadályozhatjuk, hogy a felhasználók elérhessenek bizonyos portokat és socketeket stb. A házirendeket formázó modulokat talán együttesen tudjuk a leghatékonyabban alkalmazni, és ha egyszerre több modul betöltésével egy többrétegû védelmi rendszert alakítunk ki. Ez nem ugyanaz, mint a rendszer megerõsítése, ahol a rendszer összetevõit jellemzõ módon csak bizonyos célok tekintetében edzzük meg. A módszer egyedüli hátulütõi a többszörös állományrendszeri címkékkel, a felhasználónként beállítandó hálózati eléréssel stb. járó adminisztrációs költségek. Ezek a hátrányok azonban eltörpülnek a létrehozott rendszer tartósságával szemben. Például, ha képesek vagyunk megmondani, hogy az adott konfigurációban milyen házirendek alkalmazására van szükség, akkor ezzel az adminisztrációs költségek visszaszoríthatóak. A szükségtelen házirendek eltávolításával még növelhetjük is a rendszer összteljesítményét, valamint az így felkínált rugalmasságot. Egy jó kialakításban figyelembe kell venni az összes biztonsági elõírást, és hatékonyan megvalósítani ezeket a rendszer által felajánlott különféle biztonsági modulokkal. Ezért tehát a MAC lehetõségeit kihasználó rendszerekben legalább annyit meg kell tudni oldani, hogy a felhasználók ne változtathassák kedvükre a biztonsági tulajdonságokat. Az összes felhasználói segédprogramnak, programnak és szkriptnek a kiválasztott biztonsági modulokban szereplõ hozzáférési szabályokkal kifeszített kereten belül kell mozognia. A MAC totális irányítása pedig a rendszergazda kezében van. A rendszergazda így egyedül csak a megfelelõ biztonsági modulok gondos összeválogatásáért felelõs. Bizonyos környezetekben szükséges lehet a hálózaton keresztüli hozzáférések korlátozása is. Ilyen esetekben a &man.mac.portacl.4;, &man.mac.ifoff.4; vagy a &man.mac.biba.4; moduloktól érdemes elindulnunk. Más esetekben az állományrendszerek objektumainak bizalmasságát kell csupán megõriznünk. Erre a célra a &man.mac.bsdextended.4; és &man.mac.mls.4; modulok a legalkalmasabbak. A házirendekhez kapcsolódó döntések a hálózati beállítások alapján is meghozhatóak. Elképzelhetõ, hogy csak bizonyos felhasználók férhetnek hozzá az &man.ssh.1; szolgáltatásain keresztül a hálózathoz vagy az internethez. A &man.mac.portacl.4; pontosan ilyen helyzetekben tud a segítségünkre sietni. Mit tegyünk viszont az állományrendszerek esetén? Vágjunk el adott felhasználókat vagy csoportokat bizonyos könyvtáraktól? Vagy korlátozzuk a felhasználók vagy segédprogramok hozzáférését adott állományokhoz bizonyos objektumok bizalmassá tételével? Az állományrendszerek esetében az objektumokat néhány felhasználó elérheti, mások pedig nem. Például egy nagyobb fejlesztõcsapat kisebb csoportokra bontható. Az A projektben résztvevõ fejlesztõk nem férhetnek hozzá a B projektben dolgozó fejlesztõk munkájához. Ellenben szükségük lehet a C projekten munkálkodó fejlesztõk által létrehozott objektumokra. Ez egy igen érdekes helyzet. A MAC rendszer által felkínált különbözõ biztonsági modulokra építkezve azonban könnyedén csoportokba tudjuk szervezni a felhasználókat, és a megfelelõ területekhez az információ kiszivárgása nélkül hozzá tudjuk õket engedni. Ennek következtében minden egyes biztonsági modul a maga módján gondoskodik az egész rendszer biztonságáról. A céljainknak megfelelõ modulokat egy jól átgondolt biztonsági házirend alapján válasszuk ki. Sok esetben az egész házirendet át kell tekinteni és újra kell alkalmazni a rendszerben. A MAC által felajánlott különbözõ biztonsági modulok megértése segít a rendszergazdáknak megválasztani az adott helyzetben legjobban alkalmazható házirendeket. A &os; rendszermagja alapból nem tartalmazza a MAC rendszert. Ezért a fejezetben szereplõ példák vagy az itt leírtak kipróbálásához az alábbi beállítást kell hozzátennünk a rendszermag beállításait tartalmazó állományhoz: options MAC Majd fordítsuk és telepítsük újra a rendszermagot. Miközben a MAC rendszerhez készült különbözõ modulok a saját man oldalaik szerint igénylik a beépítésüket, vigyázzunk velük, mert ezzel a rendszerüket pillanatok alatt ki tudjuk zárni a hálózatból és így tovább. A MAC alapú védelem felépítése leginkább egy tûzfal összeállításához hasonlítható, ahol ugyanígy számolni kell azzal, hogy egy óvatlan paranccsal kizárhatjuk magunkat a rendszerbõl. Valamilyen módon mindig próbáljunk gondoskodni a rendszer elõzõ állapotának visszaállíthatóságáról, és a MAC távoli adminisztrációját mindig nagyfokú körültekintéssel végezzük. Bõvebben a MAC címkéirõl A MAC-címke egy olyan biztonsági tulajdonság, amelyet a rendszerben található alanyokhoz és objektumokhoz rendelhetünk. Egy címke beállításához a felhasználónak pontosan ismernie kell, hogy ilyenkor mi történik. Az objektumokhoz tartozó tulajdonságok a betöltött moduloktól függenek, és az egyes modulok eltérõ módon értelmezik ezeket a tulajdonságokat. Ha a precíz megértésük hiányában helytelenül állítjuk be ezeket, vagy nem vagyunk képesek tisztázni a velük járó következményeket, akkor az a rendszerünk kiszámíthatatlan és valószínûleg kedvezõtlen viselkedését eredményezi. A házirendek az objektumhoz rendelt biztonsági címkéket a hozzáféréssel kapcsolatos döntések meghozásában használják fel. Bizonyos házirendek esetében már maga a címke elegendõ információt tartalmaz a döntés megformálásához. Máshol viszont a címkék egy nagyobb szabályrendszer részeként dolgozódnak fel stb. Például, ha egy állományra beállítjuk a biba/low címkét, akkor az arra fog utalni, hogy a címkét a Biba nevû biztonsági modul kezeli és értéke low. Az a néhány modul, amely a &os;-ben támogatja a címkézés lehetõségét, három speciális címkét definiál elõre. Ezek rendre a low (alacsony), high (magas) és equal (egyezõ) címkék. Habár az egyes modulok esetén eltérõ módon képesek vezérelni a hozzáférést, azt mindig biztosra vehetjük, hogy a low a legalacsonyabb érték, az equal címke hatására az adott alanyt vagy objektumot érintetlenül hagyják, és a high értékû címke a Biba és MLS modulok esetében a legmagasabb beállítást jelenti. Az egycímkés állományrendszerek használata során az egyes objektumonkhoz csak egyetlen címkét rendelhetünk hozzá. Ezzel az egész rendszerben csak egyfajta engedélyt alkalmazunk, ami sok esetben pontosan elegendõ. Létezik néhány különleges eset, amikor az állományrendszerben levõ alanyokhoz vagy objektumokhoz egyszerre több címkét is hozzá kell rendelnünk. Ilyenkor a opciót kell átadnunk a &man.tunefs.8; segédprogramnak. A Biba és az MLS esetében elõfordulhat, hogy egy numerikus címkével fogjuk jelölni a hierarchikus irányítás pontos szintjét. A numerikus szintek használatával tudjuk az információt különbözõ csoportokba szétosztani vagy elrendezni, például úgy, hogy csak az adott szintû vagy a felette álló csoportok számára engedélyezzük a hozzáférést. Az esetek többségében a rendszergazdának csak egyetlen címkét kell beállítania az egész állományrendszerre. Hé, álljunk csak meg! Akkor ez viszont pont olyan, mint a DAC! Én azt hittem, hogy a MAC szigorúan a rendszergazda kezébe adja az irányítást. Ez az állítás továbbra is fennáll, mivel bizonyos értelemben a root lesz az, aki beállítja a házirendeket, tehát õ mondja meg, hogy a felhasználók milyen kategóriákba vagy hozzáférési szintekbe sorolódnak. Sajnos, sok biztonsági modul még magát a root felhasználót is korlátozza. Az objektumok feletti irányítás ilyenkor a csoportra száll, de a root bármikor visszavonhatja vagy módosíthatja a beállításokat. Ezzel a hierarchikus/engedély alapú modellel a Biba és az MLS nevû házirendek foglalkoznak. A címkék beállítása A címkézéshez kapcsolódó összes beállítást gyakorlatilag az alapvetõ rendszerprogramokkal végezhetjük el. Ezek a parancsok az objektumok és az alanyok szabályozásához, valamint a konfiguráció módosításához és ellenõrzéséhez adnak egy egyszerû kezelõfelületet. Az összes konfigurációs beállítást a &man.setfmac.8; és &man.setpmac.8; segédprogramokkal végezhetjük el. A setfmac segítségével a rendszerszintû objektumokhoz tudunk hozzárendelni a MAC-címkéket, míg a setpmac paranccsal a rendszerben levõ alanyokhoz tudunk címkéket rendelni. Vegyük például ezt: &prompt.root; setfmac biba/high próba Amennyiben az iménti parancs hibátlanul lefutott, visszakapjuk a paranccsort. Ezek a parancsok csak olyankor maradnak nyugodtan, amikor semmilyen hiba nem történt. Mûködésük hasonló a &man.chmod.1; és &man.chown.8; parancsokéhoz. Bizonyos esetekben Permission denied (A hozzáférés nem engedélyezett) hibát kapunk, ami általában akkor bukkan fel, ha egy korlátozott objektummal kapcsolatban próbálunk meg címkét beállítani vagy módosítani Más feltételek mellett másmilyen hibák keletkezhetnek. Például, ha egy olyan objektumot próbálunk újracímkézni, amely nincs a felhasználó birtokában, esetleg nem is létezik vagy írásvédett. Adódhat, hogy a kötelezõ házirend az állomány, a program, vagy az új címkeérték tulajdonságai miatt nem fogja lehetõvé tenni egy futó program számára egy állomány újracímkézését. Nézzük erre egy példát: egy kevésbé sértetlen felhasználó megpróbálja megváltoztatni egy sokkal sértetlenebb állomány címkéjét. Vagy egy kevésbé sértetlen felhasználó sokkal sértetlenebbre akarja állítani egy kevésbé sértetlen állomány címkéjét. . A rendszergazda a következõ paranccsal tudja feloldani az ilyen helyzeteket: &prompt.root; setfmac biba/high próba Permission denied &prompt.root; setpmac biba/low setfmac biba/high próba &prompt.root; getfmac próba próba: biba/high Ahogy az itt tetten is érhetõ, a setpmac használható a modul beállításainak felülbírálására úgy, hogy a meghívott programban egy másik címkét állít be. A getpmac segédprogram általában a sendmailhez hasonló háttérben futó programok esetében alkalmazható: ilyenkor a konkrét parancs helyett a futó program azonosítóját kell megadnunk, de mûködése ugyanaz. Ha a felhasználók a hatókörükön túl levõ állományokat próbálnak meg módosítani, akkor a betöltött modulok szabályainak megfelelõen a mac_set_link függvény Operation not permitted (A mûvelet nem engedélyezett) hibát fog adni. Gyakori címketípusok A &man.mac.biba.4;, &man.mac.mls.4; és &man.mac.lomac.4; moduloknál használhatunk címkéket. Értékük lehet high, equal vagy low, melyek rövid magyarázata a következõ: A low címke az objektumra vagy alanyra érvényes leggyengébb beállítást jelenti. Az ilyen címkéjû objektumok vagy alanyok nem érhetik el a high címkéjûeket. Az equal címke használható minden olyan objektum vagy alany esetében, amelyeket ki akarunk vonni az adott házirend hatálya alól. A high címke adja az objektumhoz vagy alanyhoz tartozó legerõsebb beállítást. Az egyes moduloktól függõen ezek az értékek az információ áramoltatásának különbözõ irányait írhatják le. A megfelelõ man oldalak elolvasásával még jobban megismerhetjük az egyes címketípusok beállításának jellegzetességeit. A címkék beállításáról részletesebben A numerikus osztályozó címkék összehasonlítás:rekesz+rekesz alakban használatosak, tehát a biba/10:2+3+6(5:2+3-20:2+3+4+5+6) kifejezés így értelmezhetõ: A Biba házirend címkéje/10 osztály :2, 3 és 6 rekeszek: (5 osztály...) Ebben a példában az elsõ osztály tekinthetõ valódi osztálynak, amely a valódi rekeszeket jelenti, a második osztály egy alacsonyabb besorolás, míg az utolsó egy magasabb szintû. A legtöbb konfigurációban nem lesz szükségünk ennyire összetett beállításokra, noha képesek vagyunk felírni ezeket. Ha ezt kivetítjük a rendszer objektumaira, akkor a rendszerben levõ alanyokat illetõen csupán az aktuális osztály/rekeszek számítanak, mivel a rendszerben és hálózati csatolófelületeken elérhetõ hozzáférés-vezérlési jogokat tükrözi. Az alany-objektum párokban megadott osztályzatok és rekeszek használhatóak fel egy olyan kapcsolat kiépítésére, amit dominanciának nevezünk. Ilyenkor egy alany ural egy objektumot, vagy egy objektum ural egy alanyt, vagy egyikük sem uralja a másikat, esetleg mind a kettõ uralja egymást. A kettõs dominancia esete akkor forog fenn, amikor a két címke megegyezik. A Biba információáramoltatási sajátosságaiból adódóan jogunk van rekeszeket létrehozni, tudunk kell, hogy ezek projekteknek feleltethetõek meg, de az objektumok is rendelkezhetnek rekeszekkel. A felhasználók ilyenkor csak úgy tudnak elérni egyes objektumokat, ha az su vagy a setpmac használatával leszûkítik a jogaikat egy olyan rekeszre, ahol már nem érvényesülnek rájuk korlátozások. A felhasználók és címkék kapcsolata Maguknak a felhasználóknak is szükségük van címkékre, mivel csak ezek segítségével tudnak az állományaik és programjaik megfelelõ módon együttmûködni a rendszerben érvényes biztonsági házirenddel. Ezt a login.conf állományban megadható bejelentkezési osztályokkal állíthatjuk be. Minden címkéket használó modulban a felhasználóknak is van címkéjük. Lentebb látható egy ilyen minta bejegyzés, amely minden modulhoz tartalmaz beállítást: default:\ :copyright=/etc/COPYRIGHT:\ :welcome=/etc/motd:\ :setenv=MAIL=/var/mail/$,BLOCKSIZE=K:\ :path=~/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:\ :manpath=/usr/share/man /usr/local/man:\ :nologin=/usr/sbin/nologin:\ :cputime=1h30m:\ :datasize=8M:\ :vmemoryuse=100M:\ :stacksize=2M:\ :memorylocked=4M:\ :memoryuse=8M:\ :filesize=8M:\ :coredumpsize=8M:\ :openfiles=24:\ :maxproc=32:\ :priority=0:\ :requirehome:\ :passwordtime=91d:\ :umask=022:\ :ignoretime@:\ :label=partition/13,mls/5,biba/10(5-15),lomac/10[2]: Itt a label opciót használtuk a felhasználói osztályhoz tartozó alapértelmezett címkék beállításához, amit majd a MAC betartat. A felhasználók nem módosíthatják ezt az értéket, ezért ez a felhasználók számára nem tekinthetõ tetszõlegesen elhagyható beállításnak. Egy valós konfigurációban azonban a rendszergazda valószínûleg nem akarja majd egyszerre az összes modult használni. Javasoljuk, hogy mielõtt egy ilyen jellegû konfigurációt adnánk meg, olvassuk el az egész fejezetet. A felhasználók ezt a címkét meg tudják változtatni az elsõ bejelentkezés után, de csak a házirend keretein belül. A fenti példában úgy állítjuk be a Biba házirendet, hogy a futó programok sértetlenségi foka legalább 5, legfeljebb 15 lehet, de az alapértéke 10. Tehát a programok egészen addig 10-es szinten futnak, amíg a programok a Biba bejelentkezéskor megadott tartományában meg nem változtatják ezt a címkét, feltehetõen a setpmac parancs hatására. Mindig, amikor megváltozatjuk a login.conf beállításait, a cap_mkdb paranccsal újra kell generálni a bejelentkezési osztályokhoz tartozó adatbázist, amire a késõbbi példákban vagy részekben igyekszünk is mindig felhívni a figyelmet. Nem árt hozzátennünk, hogy sok rendszerben kifejezetten sok felhasználót kell kezelnünk, amihez több különbözõ bejelentkezési osztályra is szükségünk lehet. Mivel késõbb már csak egyre jobban bonyolódni fog a felhasználók kezelése, ezért soha ne felejtsünk el komolyan elõre tervezni. A &os; következõ változataiban meg fognak jelenni más módszerek is a felhasználók és címkék közti kapcsolatok kezelésére. A &os; 5.3 elõtt azonban ez még semmiképpen sem várható. A hálózati csatolófelületek és a címkék kapcsolata A hálózati csatlakozások esetében is állíthatunk be címkéket, melyek a hálózaton keresztül folyó adatok áramlását határozzák meg. Minden esetben ugyanúgy mûködnek, mint ahogy a házirendek az objektumokra. Például a biba esetében a magas beállításokkal rendelkezõ felhasználók nem férhetnek hozzá az alacsonyabb címkéjû hálózati csatolófelületekhez. Ha MAC-címkéket akarunk rendelni egy hálózati felülethez, akkor az ifconfig parancsnak adjuk meg a paramétert. Például a &prompt.root; ifconfig bge0 maclabel biba/equal parancs beállítja a biba/equal MAC-címkét a &man.bge.4; felületre. A biba/high(low-high) alakú címkéket átadásukhoz idézõjelek közé kell tenni, különben hibát kapunk. Minden címkézést támogató modulhoz tartoznak futási idõben állítható paraméterek, amelyekkel akár le is tudjuk tiltani a MAC-címkéket a hálózati csatolófelületeken. Ugyanezt jelenti egyébként, ha értéket adunk meg a címkének. Ezt behatóbban úgy ismerhetjük meg, ha kielemezzük a sysctl parancs kimenetét, a megfelelõ modul man oldalát vagy a fejezetben további részében található, erre vonatkozó információkat. Egy címke vagy több címke? Alapértelmezés szerint a rendszer a beállítást használja. Ez vajon mit tartogat a rendszergazda számára? Számos olyan eltérést, aminek megvannak a saját elõnyei és hátrányai a rendszer védelmi modelljének rugalmassága szempontjából. A beállítás minden alany vagy objektum esetében csupán egyetlen címke, például a biba/high használatát engedi. Kevesebb adminisztrációs költséggel jár, azonban csökkenteni a címkézést támogató modulok testreszabhatóságát. Ezért sok rendszergazda inkább a beállítást választja a biztonsági házirend kialakítása során. A beállítás lehetõvé teszi, hogy mindegyik alanyhoz és objektumhoz a szabványos beállítás lehetõségeivel szemben egymástól függetlenül külön-külön rendelhessünk címkéket a partíciókon. Az egy- és többcímkés opciónak csak olyan modulok esetében van értelme, amelyek támogatják a címkézést, mint például a Biba, Lomac, MLS és a SEBSD házirendek. Sokszor egyáltalán nincs is szükségünk a használatára. Tekintsük például a következõ helyzetet és biztonsági modellt: Adott egy &os; webszerver, ahol a MAC rendszert több biztonsági házirenddel alkalmazzuk. A gépen egyedül csak a biba/high címkére van szükségünk mindenhez a rendszerben. Itt egyszerûen csak nem adjuk meg az állományrendszernek a beállítást, mivel az egycímkés rendszer mindig rendelkezésünkre áll. Mivel azonban erre a gépre telepíteni akarunk egy webszervert is, ilyenkor a biba/low címke használatával igyekszünk korlátozni a szerver feldolgozási képességeit. A Biba házirendrõl és annak mûködésérõl csak a késõbbiekben fogunk írni, ezért ha az elõbbi megjegyzést még nem teljesen értjük, akkor egyszerûen csak olvassunk tovább és térjünk vissza ide. A szerver futása alatt, vagy legalább is idejének nagy részében egy külön partíciót használhatna, amire a biba/low címkét állítanánk be. Természetesen ez a példa korántsem teljes, hiszen hiányoznak belõle az adatokra érvényes korlátozások, a konfigurációs és felhasználói beállítások. Ez csupán az iménti gondolatmenet gyors illusztrációja. Amennyiben címkézést nem támogató modulokat alkalmazunk, a beállításra szinte sosem lesz szükségünk. Ilyenek például a seeotheruids, portacl és partition házirendek. A opció használata és így speciális, többcímkés védelmi modell létrehozása képes elbonyolítani a rendszer karbantartását, mert ilyenkor az állományrendszerben mindennek lennie kell címkéjének: könyvtáraknak, állományok és még az eszközleíróknak is. A most következõ paranccsal beállítjuk az állományrendszerre a opciót. Ez csak egyfelhasználós módban tehetõ meg: &prompt.root; tunefs -l enable / A lapozópartíció esetében erre nincs szükség. Elõfordulhat, hogy néhány felhasználónak nem sikerül a opciót beállítania a rendszerindító partícióra. Ha ez történne, akkor olvassuk el a fejezet át. A védelem megtervezése Mindig hasznos idõt szánni a tervezésre, amikor nekilátunk egy új technológia alkalmazásához. A tervezés közben a rendszergazdának egyben kell látnia a képet, lehetõleg az alábbiak figyelembevételével: Elvárások a modell felé A modell célkitûzései Továbbá a MAC használata esetén: Miként osztályozzuk a célrendszeren rendelkezésre álló információt és erõforrásokat Milyen információt vagy erõforrást kell korlátoznunk és milyen típusú korlátozást alkalmazzunk rájuk A MAC melyik moduljain keresztül tudjuk elérni céljainkat Habár mindig módunkban áll megváltoztatni és újra konfigurálni a rendszerben található erõforrásokat és biztonsági beállításokat, sokszor azért igen kényelmetlen utánanézni a rendszerben és állítgatni az állományok, illetve felhasználói hozzáférések paramétereit. A beállításainkat valamint azok konfigurációját elõször külön próbáljuk ki, mielõtt a MAC alapú megvalósításunkat egy éles rendszeren kezdjük el használni. Ennek elhagyása szinte biztosan kudarcra ítél minket. A különbözõ környezetek igényei és elvárásai eltérnek. Egy alaposan és minden részletében átgondolt védelmi profil megalapozása csökkenti a rendszer üzembehelyezése után elvégzendõ módosítások számát. Mint olyanokra, a következõ szakaszokban kitérünk a rendszergazdák számára elérhetõ modulokra, bemutatjuk a használatukat és beállításukat és egyes esetekben betekintést is adunk olyan helyzetekbe, ahol a legjobban kiaknázhatóak a képességeik. Például egy webszerver esetén hasznos lehet a &man.mac.biba.4; és &man.mac.bsdextended.4; házirendek alkalmazása. Más esetekben, például egy kevés felhasználóval mûködõ számítógépen, a &man.mac.partition.4; modul lehet jó választás. A modulok beállítása A MAC rendszerben megtalálható összes modul a korábban leírtak szerint beépíthetõ a rendszermagba vagy menet közben is betölthetõ modulként. A használni kívánt modulokat a /boot/loader.conf állományba javasolt felvenni, így azok be tudnak töltõdni a rendszer indítása folyamán. A soron következõ szakaszokban a különbözõ MAC-modulokat dolgozzuk fel és foglaljuk össze a lehetõségeiket. Továbbá a fejezet szeretne szólni ezek alkalmazásáról speciális helyzetekben is. Egyes modulokkal címkézni is tudunk, aminek révén a hozzáféréseket címkékkel szabályozzuk, például úgy, hogy megmondjuk mit szabad és mit nem. A címkék beállításait tartalmazó állomány vezérli az állományok elérését, a hálózati kommunikációt és még sok minden mást. Az elõzõ szakaszban már megismerhettük, hogy a opció segítségével hogyan állíthatjuk be az állományonkénti vagy partíciónkénti hozzáférés-vezérlést. Az egycímkés konfigurációban az egész rendszerben csupán egyetlen címke használatára nyílik mód, ezért is hívják a tunefs beállítását nek. A seeotheruids MAC-modul Lássak másokatMAC-házirend A modul neve: mac_seeotheruids.ko A rendszermag konfigurációs beállítása: options MAC_SEEOTHERUIDS Rendszerindítási beállítás: mac_seeotheruids_load="YES" A &man.mac.seeotheruids.4; modul a security.bsd.see_other_uids és security.bsd.see_other_gids sysctl-változókat utánozza és terjeszti ki. A használatához semmilyen címkét nem kell beállítani és transzparens módon képes együttmûködni a többi modullal. A modult betöltése után az alábbi sysctl-változókkal tudjuk vezérelni: A security.mac.seeotheruids.enabled engedélyezi a modult és az alapértelmezett beállításokat használja. Alapértelmezés szerint egyik felhasználó sem láthatja a többiek futó programjait és csatlakozásait. A security.mac.seeotheruids.specificgid_enabled egy adott csoportot mentesít a házirend szabályozásai alól. Tehát ki akarunk vonni egy csoportot a házirend alkalmazásából, akkor állítsuk be a security.mac.seeotheruids.specificgid=XXX sysctl-változót, ahol az XXX a mentesíteni kívánt csoport numerikus azonosítója. A security.mac.seeotheruids.primarygroup_enabled segítségével adott elsõdleges csoportokat vonhatunk ki a házirend hatálya alól. Ezt a változót nem használhatjuk a security.mac.seeotheruids.specificgid_enabled változóval együtt. A bsdextended MAC-modul MAC Állományrendszeri tûzfal MAC-házirend A modul neve: mac_bsdextended.ko A rendszermag konfigurációs beállítása: options MAC_BSDEXTENDED Rendszerindítási beállítás: mac_bsdextended_load="YES" A &man.mac.bsdextended.4; modul segítségével egy állományrendszer szintjén mûködõ tûzfalat tudunk kialakítani. Ez a modul a szabványos állományrendszeri engedély alapú modelljét bõvíti ki, lehetõvé téve, hogy a rendszergazda tûzfalszerû szabályokkal nyújtson védelmet a könyvtárszerkezetben található állományoknak, segédprogramoknak és könyvtáraknak. Amikor egy állományrendszerbeli objektumhoz próbálunk meg hozzáférni, a modul illeszti ezt egy szabályrendszerre, amiben vagy talál egy hozzátartozó szabályt vagy kifut belõle. Ez a viselkedés a security.mac.bsdextended.firstmatch_enabled &man.sysctl.8; paraméter segítségével változtatható meg. Hasonlóan a &os;-ben található többi tûzfalmodulhoz, az állományok elérését definiáló szabályok a rendszerindítás során egy &man.rc.conf.5; változóból olvasódnak be. A szabályokat a &man.ugidfw.8; segédprogrammal adhatjuk meg, amelynek a formai szabályai hasonlóak az &man.ipfw.8; programéhoz. A &man.libugidfw.3; függvénykönyvtár felhasználásával azonban további segédprogramok is írhatóak hozzá. A modul használata során igyekezzünk minél jobban odafigyelni, mert helytelen alkalmazásával el tudjuk vágni magunkat az állományrendszer bizonyos részeitõl. Példák Miután sikerült betölteni a &man.mac.bsdextended.4; modult, a következõ paranccsal tudjuk lekérdezni a jelenleg érvényes szabályokat: &prompt.root; ugidfw list 0 slots, 0 rules Ahogy az várható is volt, pillanatnyilag még egyetlen szabályt sem adtunk meg. Ennek értelmében tehát mindent el tudunk érni. A következõ paranccsal tudunk olyan szabályt létrehozni, ahol a root kivételével elutasítjuk az összes felhasználó hozzáférését: &prompt.root; ugidfw add subject not uid root new object not uid root mode n A &os; 5.3 elõtti változataiban az add paraméter nem létezett. Ezeknél ehelyett a set paramétert kell majd használnunk, lásd lentebb. Ez egyébként egy nagyon buta ötlet, mivel így a felhasználók még a legegyszerûbb parancsokat, mint például az ls-t, sem tudják rájuk kiadni. Ennél sokkal humánusabb lesz, ha: &prompt.root; ugidfw set 2 subject uid felhasználó1 object uid felhasználó2 mode n &prompt.root; ugidfw set 3 subject uid felhasználó1 object gid felhasználó2 mode n Ilyenkor a felhasználó1 nevû felhasználótól megvonjuk a felhasználó2 felhasználói könyvtárának összes hozzáférését, beleértve a listázhatóságot is. A felhasználó1 helyett megadhatjuk a opciót is. Ebben az esetben egy felhasználó helyett az összes felhasználóra ugyanaz a korlátozás fog érvényesülni. A root felhasználóra ezek a beállítások nem vonatkoznak. Ezzel felvázoltuk, miként lehet a &man.mac.bsdextended.4; modult felhasználni az állományrendszerek megerõsítésére. Részletesebb információkért járuljunk a &man.mac.bsdextended.4; és &man.ugidfw.8; man oldalakhoz. Az ifoff MAC-modul a csatolófelületek elfojtása MAC-házirend A modul neve: mac_ifoff.ko A rendszermag konfigurációs beállítása: options MAC_IFOFF Rendszerindítási beállítás: mac_ifoff_load="YES" A &man.mac.ifoff.4; modul kizárólag abból a célból készült, hogy segítségével menet közben le tudjuk tiltani bizonyos hálózati csatolófelületek beállítását a rendszerindítás közben. Sem címkékre, sem pedig a többi MAC-modulra nincs szükségünk a használatához. A vezérlést nagyrészt az alábbi sysctl-változókkal tudjuk megoldani. A security.mac.ifoff.lo_enabled engedélyezi vagy letiltja a (&man.lo.4;) helyi loopback felületen az összes forgalmat. A security.mac.ifoff.bpfrecv_enabled engedélyezi vagy letiltja a Berkeley csomagszûrõ (BPF, Berkeley Packet Filter) felületén az összes forgalmat. A security.mac.ifoff.other_enabled engedélyezi vagy letiltja az összes többi csatolófelületen az összes forgalmat. A &man.mac.ifoff.4; modult általában olyan környezetek monitorozásakor szokták használni, ahol a rendszer indítása során még nem szabad hálózati forgalomnak keletkeznie. Vagy például a security/aide porttal együtt használva automatikusan el tudjuk zárni a rendszerünket, ha a védett könyvtárakban új állományok keletkeznek vagy megváltoznak a régiek. A portacl MAC-modul Port hozzáférés-vezérlési lista MAC-házirend A modul neve: mac_portacl.ko A rendszermag konfigurációs beállítása: MAC_PORTACL Rendszerindítási beállítás: mac_portacl_load="YES" A &man.mac.portacl.4; modul a helyi TCP és UDP portok kiosztásának korlátozását teszi lehetõvé különféle sysctl-változókon keresztül. A &man.mac.portacl.4; segítségével lényegében a nem-root felhasználók is használhatnak privilegizált, tehát 1024 alatti portokat. Miután betöltöttük, a modul az összes csatlakozásra alkalmazza a MAC-házirendet. Ezután az alábbi változókkal hangolhatjuk a viselkedését: A security.mac.portacl.enabled totálisan engedélyezi vagy letiltja a házirend használatát. A security.mac.portacl.port_high megadja azt a legmagasabb portot, amelyre még kiterjed a &man.mac.portacl.4; védelme. Ha a security.mac.portacl.suser_exempt változónak nem nulla értéket adunk meg, akkor azzal a root felhasználót kivonjuk a szabályozások alól. A security.mac.portacl.rules az érvényes mac_portacl házirendet adja meg, lásd lentebb. A security.mac.portacl.rules változó által megadott aktuális mac_portacl házirend formátuma a következõ: szabály[,szabály,...], ahol ezen a módon tetszõleges számú szabályt adhatunk meg. Az egyes szabályok pedig így írhatóak fel: azonosítótípus: azonosító: protokoll: port. Az azonosítótípus értéke uid vagy gid lehet, amivel megadjuk, hogy az azonosító paraméter felhasználóra vagy csoportra hivatkozik. A protokoll paraméter adja meg, hogy a szabályt TCP vagy UDP típusú kapcsolatra értjük, és ennek megfelelõen az értéke is tcp vagy udp lehet. A sort végül a port paraméter zárja, ahol annak a portnak számát adjuk meg, amelyhez az adott felhasználót vagy csoportot akarjuk kötni. Mivel a szabályokat közvetlenül maga a rendszermag dolgozza fel, ezért a felhasználók illetve csoportok azonosítója, valamint a port értéke kizárólag numerikus érték lehet. Tehát a szabályokban név szerint nem hivatkozhatunk felhasználókra, csoportokra vagy szolgáltatásokra. A &unix;-szerû rendszereken alapértelmezés szerint az 1024 alatti portokat csak privilegizált programok kaphatják meg és használhatják, tehát a root felhasználó neve alatt kell futniuk. A &man.mac.portacl.4; azonban a nem privilegizált programok számára is lehetõvé teszi, hogy elfoglalhassanak 1024 alatti portokat, amihez viszont elõször le kell tiltani ezt a szabvány &unix;-os korlátozást. Ezt úgy érhetjük el, ha a net.inet.ip.portrange.reservedlow és net.inet.ip.portrange.reservedhigh változókat egyaránt nullára állítjuk. A &man.mac.portacl.4; mûködésének részleteirõl a példákon keresztül vagy a megfelelõ man oldalakból tudhatunk meg többet. Példák A következõ példák az iméntieket igyekeznek jobban megvilágítani: &prompt.root; sysctl security.mac.portacl.port_high=1023 &prompt.root; sysctl net.inet.ip.portrange.reservedlow=0 net.inet.ip.portrange.reservedhigh=0 Elsõként beállítjuk, hogy a &man.mac.portacl.4; vegye át a szabványos privilegizált portok vezérlését és letiltjuk a normál &unix;-os korlátozásokat. &prompt.root; sysctl security.mac.portacl.suser_exempt=1 A root felhasználót azonban nem akarjuk kitenni a házirendnek, ezért a security.mac.portacl.suser_exempt változónak egy nem nulla értéket adunk meg. A &man.mac.portacl.4; modul most pontosan ugyanúgy mûködik, mint a &unix;-szerû rendszerek alapértelmezés szerint. &prompt.root; sysctl security.mac.portacl.rules=uid:80:tcp:80 A 80-as azonosítóval rendelkezõ felhasználó (aki általában a www) számára engedélyezzük a 80-as port használatát. Így a www felhasználó anélkül képes webszervert futtatni, hogy szüksége lenne a root jogosultságaira. &prompt.root; sysctl security.mac.portacl.rules=uid:1001:tcp:110,uid:1001:tcp:995 Az 1001-es azonosítóval rendelkezõ felhasználónak megengedjük, hogy elfoglalhassa a 110-es (pop3) és 995-ös (pop3s) portokat. Ennek köszönhetõen az adott felhasználó el tud indítani egy szervert, amihez a 110-es és 995-ös portokon lehet kapcsolódni. A partition MAC-modul a futó programok felosztását megvalósító MAC-házirend A modul neve: mac_partition.ko A rendszermag konfigurációs beállítása: options MAC_PARTITION Rendszerindítási beállítás: mac_partition_load="YES" A &man.mac.partition.4; házirend a futó programokat címkéjük szerint adott partíciókra osztja szét. Ezt leginkább egy speciális &man.jail.8; megoldásként tudjuk elképzelni, noha teljesen felesleges összehasonlítani a kettõt. Ez egy olyan modul, amelyet a &man.loader.conf.5; állományba kell felvenni, hogy a rendszerindítása közben be tudjon töltõdni. Ezt a házirendet többségében a &man.setpmac.8; segédprogrammal tudjuk állítgatni, ahogy az majd lentebb látható lesz. A következõ sysctl-változó tartozik még a modulhoz: A security.mac.partition.enabled engedélyezi a futó programok MAC rendszeren keresztüli felosztását. A házirend engedélyezésével a felhasználók csak a saját programjaikat láthatják, illetve mindazokat, amelyek az övékével egy partícióba tartoznak, de a rajta kívül levõ programokkal már nem dolgozhatnak. Például, ha egy felhasználó az insecure (nem biztonságos) osztály tagja, akkor ne engedjük, hogy hozzáférhessen a top vagy bármilyen más olyan parancshoz, amely további futó programokat hoz létre. A setpmac használatával tudunk címkéket készíteni a partíciókhoz és programokat rendelni hozzájuk: &prompt.root; setpmac partition/13 top Így a top parancsot hozzáadjuk az insecure osztályban levõ felhasználókhoz rendelt címkéhez. Vegyük észre, hogy az insecure osztályba tartozó felhasználók által elindított összes program a partition/13 címkét fogja használni. Példák A következõ parancs megmutatja a partíciók címkéit és a futó programok listáját: &prompt.root; ps Zax Ezzel paranccsal pedig megnézhetjük egy másik felhasználó programjainak címkéit és a felhasználó által futtatott programokat: &prompt.root; ps -ZU trhodes A felhasználók látják a root címkéjével futó programokat is, hacsak be nem töltjük a &man.mac.seeotheruids.4; házirendet. Ezt a megoldást úgy tudnánk igazán ravaszul felhasználni, ha például az /etc/rc.conf állományban letiltanánk az összes szolgáltatást és egy olyan szkripttel indítanánk el ezeket, amely futtatásuk elõtt beállítja hozzájuk a megfelelõ címkét. A most következõ házirendek a három alapértelmezett címkeérték helyett egész számokat használnak. Ezekrõl, valamint a rájuk vonatkozó korlátozásokról a megfelelõ modulok man oldalain ismerhetünk meg többet. A többszintû biztonsági MAC-modul a többszintû biztonsági MAC-házirend A modul neve: mac_mls.ko A rendszermag konfigurációs beállítása: options MAC_MLS Rendszerindítási beállítás: mac_mls_load="YES" A &man.mac.mls.4; (MLS, Multi-Level Security) házirend az információ szigorú áramoltatásával vezérli a rendszerben található alanyok és objektumok közti elérést. A MLS megoldását alkalmazó környezetekben a rekeszek mellett minden alanyra és objektumra be kell még állítanunk egy adott szintû engedélyt is. Mivel az engedélyek avagy az érzékenység szintje akár a hatezret is meghaladhatja, egy rendszergazda számára valódi rémálommá válthat az egyes alanyok és objektumok precíz beállítása. Szerencsére a házirend erre a célra tartalmaz három elõre definiált instant címkét. Ezek az mls/low, mls/equal és mls/high. Mivel a man oldal elég részletesen kifejti ezeket, ezért itt csak érintõlegesen foglalkozunk velük: Az mls/low címke egy olyan alacsony szintû beállítást képvisel, amely lehetõvé teszi, hogy az összes többi objektum uralja. Tehát bárminek is adjuk az mls/low címkét, alacsony szintû engedéllyel fog rendelkezni és nem lesz képes elérni a magasabb szinten levõ információt. Ráadásul a címke a magasabb szintû objektumok számára se fogja engedni, hogy információt közöljön vagy adjon át az alacsonyabb szintek felé. Az mls/equal címke olyan objektumok esetében ajánlott, amelyeket ki akarunk hagyni a házirend szabályozásaiból. Az mls/high címke az elérhetõ legmagasabb szintû engedélyt ábrázolja. Az ilyen címkével ellátott objektumok a rendszer összes többi objektuma felett uralommal rendelkeznek, habár az alacsonyabb szintû objektumok felé nem képesek információt közvetíteni. Az MLS: Egy hierarchikus védelmi szinteket épít fel nem hierarchikus kategóriákkal. Szabályai rögzítettek: a felsõbb szintek olvasása és az alsóbb szintek írása egyaránt tiltott (az alanyok csak a saját vagy az alatta levõ szinteken levõ objektumokat képesek olvasni, de a felette állókat már nem. Ehhez hasonlóan az alanyok a velük egyezõ vagy a felsõbb szinteket tudják írni, de az alattuk levõket már nem). Megõrzi a titkokat (megakadályozza az adatok alkalmatlan közzétételét). Megadja mindazt az alapot, ami szükséges ahhoz, hogy az adatokat több kényességi szinten, párhuzamosan is kezelni tudjuk (anélkül, hogy titkos és bizalmas információkat szivárogtatnánk ki). A speciális szolgáltatások és felületek beállításához az alábbi sysctl-változók használhatóak: A security.mac.mls.enabled engedélyezi vagy tiltja le az MLS házirend alkalmazását. A security.mac.mls.ptys_equal hatására látja el mls/equal címkével az összes &man.pty.4; eszközt létrehozásuk során. A security.mac.mls.revocation_enabled használható az alacsonyabb szintre minõsített objektumok hozzáférésének megvonására. A security.mac.mls.max_compartments segítségével adható meg az objektumok által használt rekeszek szintjének maximális száma. Lényegében a rekeszek rendszerben engedélyezett maximuma. Az MLS címkéit a &man.setfmac.8; paranccsal tudjuk módosítani. Egy ehhez hasonló paranccsal tudunk egy objektumhoz címkét rendelni: &prompt.root; setfmac mls/5 próba A próba állomány MLS-címkéjét az alábbi paranccsal kérhetjük le: &prompt.root; getfmac próba Ezzel össze is foglaltuk az MLS házirend lehetõségeit. Az eddigiket úgy is megoldhatjuk, hogy létrehozunk egy központi házirendet az /etc könyvtárban, amelyben megadjuk az MLS házirendhez tartozó információkat, majd átadjuk a setfmac parancsnak. Erre a módszerre majd a házirendek bemutatása után kerül sor. A kényesség megállapítása A többszintû biztonsági házirend használatával a rendszergazda a kényes információk áramlásának irányát tudja befolyásolni. A megoldás felfele nem lehet olvasni, lefele nem lehet írni jellege folytán alapból mindent a legalacsonyabb szintre helyez. Így tehát kezdetben minden elérhetõ, és a rendszergazdának lassanként ebbõl az állapotból elindulva kell behangolnia az erre alapozó védelmi rendszert az információ bizalmasságának megfelelõen. A fentebb említett három alapvetõ címke mellett a rendszergazdának valószínûleg szüksége lesz a felhasználók csoportosítására és a csoportok közti információáramlás szabályozására. A információ bizalmasságának szintjeit minden bizonnyal könnyebb szavakkal beazonosítani, például Confidential (bizalmas), Secret (titkos) vagy Top Secret (szigorúan bizalmas). Bizonyos helyzetekben elég csak a futó projekteknek megfelelõen kialakítani csoportokat. Az osztályozás konkrét módszerétõl függetlenül azonban mindig elmondható, hogy elõzetes tervezés nélkül sose állítsunk össze ilyen fajsúlyú házirendet. Ezt a biztonsági modult például webes üzletek esetén érdemes használnunk, ahol egy állományszerver tárolja a cég fontos adatait és pénzügyi információit. Viszont egy két vagy három felhasználóval üzemelõ munkaállomás esetében szinte teljesen felesleges gondolkodni rajta. A Biba MAC-modul a Biba sértetlenségi MAC-házirend A modul neve: mac_biba.ko A rendszermag konfigurációs beállítása: options MAC_BIBA Rendszerindítási beállítás: mac_biba_load="YES" A &man.mac.biba.4; modul a MAC Biba elnevezésû házirendjét tölti be. Ez leginkább az MLS házirendhez hasonlít, azzal a kivétellel, hogy az információ áramoltatására vonatkozó szabályok némileg visszafelé mûködnek. Tehát míg az MLS házirend a kényes információ áramlását felfelé nem engedi, addig ez a lefelé irányuló áramlást állítja meg. Emiatt ez a szakasz tulajdonképpen mind a két házirendre érvényesül. A Biba alkalmazása során minden alany és objektum egy sértetlenséget jelképezõ címkét visel. Ezek a címkék hierarchikus osztályokból, nem peidg hiearchikus összetevõkbõl származnak. Egy objektum vagy alany sértetlensége a besorolásával növekszik. A modul a biba/low, biba/equal és biba/high címkéket ismeri, vagyis bõvebben: A biba/low címke tekinthetõ az alanyok és objektumok legkisebb sértetlenségének. Ha beállítjuk egy objektumra vagy alanyra, akkor ezzel megakadályozzuk, hogy nagyobb sértetlenségû objektumokat vagy alanyokat tudjanak írni. Ettõl függetlenül azonban még képesek olvasni ezeket. A biba/equal címke használata kizárólag olyan objektumok esetében javasolt, amelyeket ki akarunk vonni a házirend alól. A biba/high címke megengedi az alacsonyabb szinteken levõ objektumokat írását, de az olvasását viszont már nem. Ezt a címkét olyan objektumra érdemes ragasztani, amelyek hatással vannak az egész rendszer sértetlenségére. A Biba: Hierarchikus sértetlenségi szinteket épít fel nem hiearchikus sértetlenségi kategóriákkal kiegészítve. Szabályai rögzítettek: az felsõbb szintek írása és az alsóbb szintek olvasása egyaránt tilos (pontosan az MLS ellentéte). Egy alany csak a saját vagy az alatta álló szinteken szereplõ objektumokat tudja írni. Ehhez hasonló módon egy alany csak a saját vagy az afeletti szinten található objektumokat képes olvasni. Az adatok sértetlenségét biztosítja (megakadályozza az alkalmatlan módosításukat) Sértetlenségi szinteket határoz meg (szemben az MLS kényességi szintjeivel). Az alábbi sysctl-változókkal vezérlhetjük a Biba házirend mûködését: A security.mac.biba.enabled használható a célrendszeren a Biba házirend engedélyezére vagy letiltására. A security.mac.biba.ptys_equal segítségével kapcsolhatjuk ki a Biba házirend alkalmazását a &man.pty.4; eszközökön. A security.mac.biba.revocation_enabled hatására visszavonódik az objektumok hozzáférése, ha az rájuk vonatkozó címke megváltozik. A rendszer objektumain a Biba házirendet a setfmac és getfmac paranccsal állíthatjuk be: &prompt.root; setfmac biba/low próba &prompt.root; getfmac próba próba: biba/low A sértetlenség megállapítása A sértetlenség a kényességtõl eltérõen azt igyekszik szavatolni, hogy az információt illetéktelenek nem módosítják. Ez egyaránt vonatkozik az alanyok, objektumok és a kettõ között átadott adatokra. Gondoskodik róla, hogy a felhasználók csak olyan információkat változtathathassanak meg, sõt csak olyat érhessenek el, amire ténylegesen szükségük van. A &man.mac.biba.4; biztonsági modul megengedi a rendszergazda számára, hogy megmondja milyen állományokat és programokat láthat vagy hívhat meg a felhasználó vagy felhasználók egy csoportja, miközben biztosítja, hogy az állományok és a programok nincsenek kitéve semmilyen fenyegetésnek, és a rendszer az adott felhasználóban vagy felhasználói csoportban megbízik. A kezdeti tervezési fázis során a rendszergazdának fel kell készülnie arra, hogy a felhasználókat osztályokra, szintekre és területekre kell osztania. A felhasználók nem csak adatokhoz, hanem programokhoz és segédprogramokhoz sem lesznek képesek hozzáférni, mind az indításuk elõtt és után. A modul aktiválás után a rendszer alapból rögtön a legmagasabb címkét kapja meg, és teljesen a rendszergazdára hárul, hogy a felhasználókhoz beállítsa a különféle osztályokat és szinteket. A fentebb leírt engedélyszintek helyett akár témák alapján is tervezhetünk. Például kizárólag csak a fejlesztõk számára engedjük meg a forráskód módosítását, a forráskód lefordítását és a többi fejlesztõeszköz használatát. Eközben a többi felhasználót felosztjuk további csoportokba, például tesztelõkre és tervezõkre, vagy meghagyjuk ezeket átlagos felhasználóknak, akik csak olvasási joggal rendelkeznek. A megvalósított biztonsági modell természetébõl fakadóan egy kevésbé sértetlenebb alany nem írhatja a sokkal sértetlenebb alanyokat, a sokkal sértetlenebb alanyok pedig nem érhetik el vagy olvashatják a kevésbé sértetlen objektumokat. A lehetõ legkisebb osztályú címke beállításával gyakorlatilag elérhetetlenné teszük az alanyok számára. A modult valószínûleg egy korlátozott webszerver, fejlesztõi- és tesztgépek vagy forráskód tárolására szánt környezetben érdemes bevetni. Annál esélytelenebb a használata viszont egy munkaállomás, útválasztó vagy hálózati tûzfal esetében. A LOMAC MAC-modul a LOMAC MAC-házirend A modul neve: mac_lomac.ko A rendszermag konfigurációs beállítása: options MAC_LOMAC Rendszerindítás beállítás: mac_lomac_load="YES" Eltérõen a MAC Biba házirendjétõl, a &man.mac.lomac.4; egyedül csak azután engedi elérni az kevésbé sértetlenebb objektumokat, miután csökkentjük a sértetlenség szintjét és ezzel betartjuk a sértetlenségre vonatkozó szabályokat. A gyenge vízjeles sértetlenségi házirend MAC alapú változatát nem szabad összetéveszteni a korábbi &man.lomac.4; implementációval, amely majdnem ugyanúgy mûködik, mint a Biba, azzal az a kivétellel, hogy a lebegõ címkékkel támogatjuk az alanyok lefokozását egy kisegítõ osztály rekeszén keresztül. Ez a másodlagos rekesz [kisegítõ_osztály] alakú. Tehát amikor egy kisegítõ osztállyal adjuk meg a lomac házirendet, valahogy így néz ki: lomac/10[2], ahol a kettes (2) szám ez a kisegítésre használt osztály. A MAC LOMAC házirendje az összes rendszerszintû objektum esetében jelenlevõ sértetlenségi címkézésen alapszik, megengedve az alanyok számára, hogy az kevésbé sértetlen objektumokat olvasni tudják, majd a címke leminõsítésével az alany meg tudja akadályozni a sokkal sértetlenebbnek ítélt objektumok jövõbeni írását. Ez az a fentebb tárgyalt [kisegítõ_osztály] opció, ezért ez a modul a Bibáénál több kompatibilitást és kevesebb kezdeti beállítást igényel. Példák Hasonlóan a Biba és MLS házirendeknél megszokottakhoz, a setfmac és setpmac segédprogramok használhatóak a címkék hozzárendeléséhez: &prompt.root; setfmac /usr/home/trhodes lomac/high[low] &prompt.root; getfmac /usr/home/trhodes lomac/high[low] Itt a kisegítõ osztály a low. Ezt csak a LOMAC MAC-házirendnél adhatjuk meg. A Nagios elzárása a MAC rendszerrel a Nagios elzárása a MAC rendszerrel A most következõ bemutatóban a MAC moduljainak és a megfelelõen beállított házirendek használatával fogunk kialakítani egy biztonságos környezetet. Ne feledjük azonban, hogy ez csupán egy ártatlan próba és nem pedig a mindenki biztonsági aggályait kielégítõ legvégsõ megoldás. Ha egy házirendet vakon építünk fel és nem értjük meg a mûködését, az soha nem válik hasznunkra, és egy éles helyzetben katasztrofális hatással járhat. A folyamat megkezdése elõtt be kell állítanunk a multilabel opciót mindegyik állományrendszerre, a fejezet elején leírtaknak megfelelõen. Ha ezt a lépést kihagyjuk, akkor hibákat kapunk. Továbbá még az elõkészület részeként ne felejtsünk el gondoskodni a - net-mngt/nagios-plugins, - net-mngt/nagios és - www/apache13 portok + net-mngt/nagios-plugins, + net-mngt/nagios és + www/apache13 portok telepítésérõl, beállításáról és megfelelõ mûködésérõl sem. A nem megbízható felhasználók osztályának létrehozása Az eljárást kezdjük az alábbi (insecure) felhasználói osztály hozzáadásával az /etc/login.conf állományban: insecure:\ :copyright=/etc/COPYRIGHT:\ :welcome=/etc/motd:\ :setenv=MAIL=/var/mail/$,BLOCKSIZE=K:\ :path=~/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin :manpath=/usr/share/man /usr/local/man:\ :nologin=/usr/sbin/nologin:\ :cputime=1h30m:\ :datasize=8M:\ :vmemoryuse=100M:\ :stacksize=2M:\ :memorylocked=4M:\ :memoryuse=8M:\ :filesize=8M:\ :coredumpsize=8M:\ :openfiles=24:\ :maxproc=32:\ :priority=0:\ :requirehome:\ :passwordtime=91d:\ :umask=022:\ :ignoretime@:\ :label=biba/10(10-10): Valamint egészítsük ki az alapértelmezett (default) felhasználói osztályt a következõ sorral: :label=biba/high: Ahogy ezzel elkészültünk, az hozzátartozó adatbázis újbóli legyártásához a következõ parancsot kell kiadnunk: &prompt.root; cap_mkdb /etc/login.conf A rendszerindítással kapcsolatos beállítások Még ne indítsuk újra a számítógépet, csupán a szükséges modulok betöltéséhez bõvítsük ki a /boot/loader.conf állományt az alábbi sorokkal: mac_biba_load="YES" mac_seeotheruids_load="YES" A felhasználók beállítása Soroljuk be a root felhasználót a default osztályba: &prompt.root; pw usermod root -L default Az összes root felhasználón kívüli hozzáférésnek vagy rendszerfelhasználónak most kelleni fog egy bejelentkezési osztály. A bejelentkezési osztályra egyébként is szükség lesz, mert ennek hiányában a felhasználók még az olyan egyszerû parancsokat sem tudják kiadni, mint például a &man.vi.1;. A következõ sh szkript nekünk erre pontosan megfelel: &prompt.root; for x in `awk -F: '($3 >= 1001) && ($3 != 65534) { print $1 }' \ /etc/passwd`; do pw usermod $x -L default; done; Helyezzük át a nagios és www felhasználókat az insecure osztályba: &prompt.root; pw usermod nagios -L insecure &prompt.root; pw usermod www -L insecure A <filename>contexts</filename> állomány létrehozása Most csinálnunk kell egy contexts állományt. Ebben példában az /etc/policy.contexts állományt használjuk. # Ez a rendszer alapértelmezett BIBA házirendje. # Rendszer: /var/run biba/equal /var/run/* biba/equal /dev biba/equal /dev/* biba/equal /var biba/equal /var/spool biba/equal /var/spool/* biba/equal /var/log biba/equal /var/log/* biba/equal /tmp biba/equal /tmp/* biba/equal /var/tmp biba/equal /var/tmp/* biba/equal /var/spool/mqueue biba/equal /var/spool/clientmqueue biba/equal # Nagios: /usr/local/etc/nagios /usr/local/etc/nagios/* biba/10 /var/spool/nagios biba/10 /var/spool/nagios/* biba/10 # Apache: /usr/local/etc/apache biba/10 /usr/local/etc/apache/* biba/10 Ezzel a házirenddel az információ áramlását szabályozzuk. Ebben a konkrét konfigurációban a felhasználók, a root és társai, nem férhetnek hozzá a Nagioshoz. A Nagios beállításait tároló állományok és a neve alatt futó programok így teljesen különválnak vagyis elzáródnak a rendszer többi részétõl. Ez az iménti állomány a következõ parancs hatására kerül be a rendszerünkbe: &prompt.root; setfsmac -ef /etc/policy.contexts / &prompt.root; setfsmac -ef /etc/policy.contexts / A fenti állományrendszer felépítése a környezettõl függõen eltérhet, habár ezt minden egyes állományrendszeren le kell futtatni. Az /etc/mac.conf állományt törzsét a következõképpen kell még átírnunk: default_labels file ?biba default_labels ifnet ?biba default_labels process ?biba default_labels socket ?biba A hálózat engedélyezése Tegyük hozzá a következõ sort az /boot/loader.conf állományhoz: security.mac.biba.trust_all_interfaces=1 Ezt az alábbi beállítást pedig szúrjuk be az rc.conf állományba a hálózati kártya konfigurációjához. Amennyiben az internetet DHCP segítségével érjük el, ezt a beállítást manuálisan kell megtenni minden rendszerindítás alkalmával: maclabel biba/equal A konfiguráció kipróbálása a MAC beállításainak kipróbálása Gondoskodjunk róla, hogy a webszerver és a Nagios nem fog elindulni a rendszer indításakor, majd indítsuk újra a gépet. Ezenkívül még ellenõrizzük, hogy a root ne tudjon hozzáférni a Nagios beállításait tartalmazó könyvtárhoz. Ha a root képes kiadni egy &man.ls.1; parancsot a /var/spool/nagios könyvtárra, akkor valamit elronthattunk. Normális esetben egy permission denied üzenetet kell kapnunk. Ha minden jónak tûnik, akkor a Nagios, Apache és Sendmail most már elindítható a biztonsági házirend szabályozásai szerint. Ezt a következõ parancsokkal tehetjük meg: &prompt.root; cd /etc/mail && make stop && \ setpmac biba/equal make start && setpmac biba/10\(10-10\) apachectl start && \ setpmac biba/10\(10-10\) /usr/local/etc/rc.d/nagios.sh forcestart Kétszer is ellenõrizzük, hogy minden a megfelelõ módon viselkedik-e. Ha valamilyen furcsaságot tapasztalunk, akkor nézzük át a naplókat vagy a hibaüzeneteket. A &man.sysctl.8; használatával tiltsuk le a &man.mac.biba.4; biztonsági modult és próbáljunk meg mindent a szokott módon újraindítani. A root felhasználó különösebb aggodalom nélkül képes megváltoztatni a biztonsági rend betartatását és átírni a konfigurációs állományokat. Egy frissen indított parancsértelmezõ számára ezzel a paranccsal tudjuk csökkenteni a biztonsági besorolást: &prompt.root; setpmac biba/10 csh Ennek kivédésére a felhasználókat a &man.login.conf.5; beállításaival le kell korlátozni. Ha a &man.setpmac.8; megpróbál a rekesz határain túl futtatni egy parancsot, akkor hibát ad vissza és a parancs nem fut le. Ebben az esetben a root felhasználót tegyük a biba/high(high-high) értékek közé. A felhasználók korlátozása Ebben a példában egy viszonylag kicsi, nagyjából mindössze ötven felhasználós, adattárolásra használatos rendszert veszünk alapul. A felhasználók rendelkezhetnek bizonyos bejelentkezési tulajdonságokkal, és nem csak adatokat tudnak tárolni, hanem az erõforrásokhoz is hozzá tudnak férni. Itt most a &man.mac.bsdextended.4; és a &man.mac.seeotheruids.4; modulokat vetjük be együttesen, és nem csak a rendszer objektumainak elérését tudjuk megakadályozni, hanem az egyes felhasználók futó programjait is elrejtjük. A mûveletet kezdjük azzal, hogy a /boot/loader.conf állományt kibõvítjük a következõ módon: mac_seeotheruids_enabled="YES" A &man.mac.bsdextended.4; biztonsági modul az alábbi rc.conf-változóval hozható mûködésbe: ugidfw_enable="YES" A hozzátartozó alapértelmezett szabálykészlet az /etc/rc.bsdextended állományban tárolódik, amely pedig a rendszer indítása során töltõdik be. Ezeket némileg módosítanunk kell majd. Mivel a példában szereplõ számítógép csak a felhasználók kiszolgálását hivatott ellátni, az utolsó kettõ kivételével mindent hagyhatunk megjegyzésben. Így kikényszerítjük felhasználók által birtokolt rendszerobjektumok alapértelmezés szerinti betöltését. Vegyük fel a szükséges felhasználókat a számítógépre és indítsuk újra. Tesztelési célból próbáljunk meg különbözõ felhasználókként bejelentkezni két konzolon. Futassuk le a ps aux parancsot, és így meg tudjuk figyelni, hogy mennyire látjuk a többi felhasználót. Amikor megpróbáljuk kiadni a &man.ls.1; parancsot a többiek felhasználói könyvtáraira, akkor hibát kell kapnunk. Ne próbálgassunk a root felhasználóval, hacsak a megfelelõ sysctl változókban be nem állítottuk az õ hozzáférésének blokkolását is. Amikor felveszük egy felhasználót a rendszerbe, a hozzátartozó &man.mac.bsdextended.4; szabály nem fog szerepelni a szabályrendszerben. A szabályrendszer gyors frissítését úgy tudjuk megoldani, ha a &man.kldunload.8; használatával egyszerûen eltávolítjuk a biztonsági modult a memóriából és újratöltjük a &man.kldload.8; paranccsal. A hibák elhárítása a MAC rendszerben MAC hibaelhárítás A fejlesztés fázisában bizonyos normál konfigurációval rendelkezõ felhasználók gondokat jeleztek. Ezeket foglaljuk most itt össze: A <option>multilabel</option> beállítás nem adható meg a <filename>/</filename> állományrendszerre A beállítás nem marad meg a rendszerindító (/) partíciómon! A tapasztalatok szerint körülbelül minden ötvenedik felhasználó szembesül ezzel a problémával, és mi is találkozunk vele a kezdeti konfigurációk kialakítása során. Ennek az úgynevezett hibának a behatóbb tanulmányozása során arra jutottunk, hogy ez többnyire vagy a hibás dokumentálásból vagy a dokumentáció félreértelmezésébõl ered. Független attól, hogy ez mitõl is következett be, a következõ lépések megtételével orvosolhatjuk: Nyissuk meg az /etc/fstab állományt és adjuk meg a rendszerindító partíciónak az , vagyis az írásvédett (read-only) beállítást. Indítsuk újra a gépet egyfelhasználós módban. A tunefs parancsot futtassuk le a / állományrendszeren. Indítsuk újra a rendszert normál módban. Adjuk ki a mount / parancsot, majd az /etc/fstab állományban írjuk át a beállítást az értékre és megint indítsuk újra a rendszert. Alaposan nézzük át a mount parancs kimenetét és gyõzödjünk meg róla, hogy a opció valóban beállítódott a rendszerindító állományrendszerre. A <acronym>MAC</acronym> után nem lehet indítani az X11 szervert Nem indul az X, miután MAC-kel kialakítottunk egy biztonságos környezetet! Ezt vagy a MAC partition házirendje okozza, vagy az egyik címkékeket használó házirend helytelen beállítása. A következõ módon deríthetjük ki az okát: Figyelmesen olvassuk el a hibaüzenetet: ha a felhasználó az insecure osztály tagja, akkor a partition házirend lesz a bûnös. Próbáljuk meg a felhasználót visszatenni a default osztályba és a cap_mkdb paranccsal újragenerálni az adatbázist. Ha ez nem segít a problémán, akkor haladjunk tovább. Alaposan ellenõrizzük a címkékhez tartozó házirendeket. Vizsgáljuk meg, hogy a kérdeses felhasználó esetében a házirendet és az X11 alkalmazást, valamint a /dev eszközöket tényleg jól állítottuk be. Ha az iméntiek egyik sem oldja meg gondunkat, küldjük el a hibaüzenetet és a környezetünk rövid leírását a a TrustedBSD honlapjáról elérhetõ TrustedBSD levelezési lista vagy a &a.questions; címére. Hiba: &man..secure.path.3; cannot stat <filename>.login_conf</filename> Amikor a rendszerben megpróbálok a root felhasználóról átváltani egy másik felhasználóra, a _secure_path: unable to state .login_conf hibaüzenet jelenik meg. Ez az üzenet általában akkor látható, amikor a felhasználó nagyobb értékû címkével rendelkezik annál, mint akivé válni akar. Például vegyük a joska nevû felhasználót a rendszerben, aki az alap biba/low címkével rendelkezik. A root felhasználó, akinek biba/high címkéje van, nem láthatja joska felhasználói könyvtárát. Ez attól függetlenül megtörténik, hogy a root a su paranccsal váltott át a joska nevû felhasználóra vagy sem. Egy ilyen helyzetben a Biba sértetlenségi modellje nem fogja engedni a root felhasználóra számára, hogy láthassa a kevésbé sértetlen objektumokat. A <username>root</username> felhasználó nem megy! A rendszer normál vagy egyfelhasználós módban sem ismeri fel a root felhasználót. A whoami parancs 0 (nullát) ad vissza és a su parancs pedig annyit mond: who are you? (ki vagy?). Mi történhetett? Ez csak olyankor történhet, ha a címkézési házirendet nem engedélyezzük, vagy a &man.sysctl.8; használatával, vagy pedig a modul eltávolításával. Ha a házirendet letiltjuk vagy ideiglenesen letiltódik, akkor a bejelentkezési tulajdonságokat tároló adatbázist a beállítás eltávolításával kell újrakonfigurálni. A login.conf állományból ne felejtsük el kivenni az összes beállítást és a cap_mkdb paranccsal újragenerálni az adatbázist. Ilyen akkor is elõfordulhat, amikor a házirend valamilyen módon korlátozza a master.passwd állomány vagy adatbázis elérhetõségét. Ezt általában az okozza, hogy a rendszergazda az állományt olyan címke alatt módosítja, amely ütközik a rendszerben alkalmazott általános házirenddel. Ebben az esetekben a rendszer próbálja meg beolvasni a felhasználók adatait, azonban mivel közben az állomány új címkét örökölt, nem fér hozzá. Ha a &man.sysctl.8; paranccsal letiltjuk a házirendet, minden vissza fog térni a rendes kerékvágásba. diff --git a/hu_HU.ISO8859-2/books/handbook/mirrors/chapter.sgml b/hu_HU.ISO8859-2/books/handbook/mirrors/chapter.sgml index 4981ea3bec..db6bf96431 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. + class="directory">/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/network-servers/chapter.sgml b/hu_HU.ISO8859-2/books/handbook/network-servers/chapter.sgml index 13a60672c8..05d5477029 100644 --- a/hu_HU.ISO8859-2/books/handbook/network-servers/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/network-servers/chapter.sgml @@ -1,6696 +1,6696 @@ Murray Stokely Átdolgozta: Hálózati szerverek Áttekintés Ebben a fejezetben a &unix; típusú rendszerekben leggyakrabban alkalmazott hálózati szolgáltatások közül fogunk néhányat bemutatni. Ennek során megismerjük a hálózati szolgáltatások különbözõ típusainak telepítését, beállítását, tesztelését és karbantartását. A fejezet tartalmát folyamatosan példákkal igyekszünk illusztrálni. A fejezet elolvasása során megismerjük: hogyan dolgozzunk az inetd démonnal; hogyan állítsuk be a hálózati állományrendszereket; hogyan állítsunk be egy hálózati információs szervert a felhasználói hozzáférések megosztására; hogyan állítsuk be automatikusan a hálózati hozzáférésünket a DHCP használatával; hogyan állítsunk be névfeloldó szervereket; hogyan állítsuk be az Apache webszervert; hogyan állítsuk be az állományok átviteléért felelõs (FTP) szervert; a Samba használatával hogyan állítsunk be &windows;-os kliensek számára állomány- és nyomtatószervert; az NTP protokoll segítségével hogyan egyeztessük az idõt és dátumot, hogyan állítsunk be egy idõszervert. A fejezet elolvasásához ajánlott: az /etc/rc szkriptek alapjainak ismerete; az alapvetõ hálózati fogalmak ismerete; a külsõ szoftverek telepítésének ismerete (). Chern Lee Készítette: A &os; 6.1-RELEASE változatához igazította: A &os; Dokumentációs Projekt Az <application>inetd</application> <quote>szuperszerver</quote> Áttekintés Az &man.inetd.8; démont gyakran csak internet szuperszerverként nevezik, mivel a helyi szolgáltatások kapcsolatainak kezeléséért felelõs. Amikor az inetd fogad egy csatlakozási kérelmet, akkor eldönti róla, hogy ez melyik programhoz tartozik és elindít egy példányt belõle, majd átadja neki a socketet (az így meghívott program a szabvány bemenetéhez, kimenetéhez és hibajelzési csatornájához kapja meg a socket leíróit). Az inetd használatával úgy tudjuk csökkenteni a rendszerünk terhelését, hogy a csak alkalmanként meghívott szolgáltatásokat nem futtatjuk teljesen független önálló módban. Az inetd démont elsõsorban más démonok elindítására használjuk, de néhány triviális protokollt közvetlenül is képes kezelni, mint például a chargen, auth és a daytime. Ebben a fejezetben az inetd beállításának alapjait foglaljuk össze mind parancssoros módban, mind pedig az /etc/inetd.conf konfigurációs állományon keresztül. Beállítások Az inetd mûködése az &man.rc.8; rendszeren keresztül inicializálható. Az inetd_enable ugyan alapból a NO értéket veszi fel, vagyis tiltott, de a sysinstall használatával már akár a telepítés során bekapcsolható attól függõen, hogy a felhasználó milyen konfigurációt választott. Ha tehát a: inetd_enable="YES" vagy inetd_enable="NO" sort tesszük az /etc/rc.conf állományba, akkor azzal az inetd démont indíthatjuk el vagy tilthatjuk le a rendszer indítása során. Az &prompt.root; /etc/rc.d/inetd rcvar paranccsal lekérdezhetjük a pillanatnyilag érvényes beállítást. Emellett még az inetd démonnak az inetd_flags változón keresztül különbözõ parancssori paramétereket is át tudunk adni. Parancssori paraméterek Hasonlóan a legtöbb szerverhez, az inetd viselkedését is befolyásolni tudjuk a parancssorban átadható különbözõ paraméterekkel. Ezek teljes listája a következõ: inetd Ezek a paraméterek az /etc/rc.conf állományban az inetd_flags segítségével adhatóak meg az inetd részére. Alapértelmezés szerint az inetd_flags értéke -wW -C 60, ami az inetd által biztosított szolgáltatások TCP protokollon keresztüli wrappelését kapcsolja be, illetve egy IP-címrõl nem engedi a felkínált szolgáltatások elérését percenként hatvannál többször. A kezdõ felhasználók örömmel nyugtázhatják, hogy ezeket az alapbeállításokat nem szükséges módosítaniuk, habár a késõbbiekben majd fény derül arra, hogy a kiszolgálás gyakoriságának szabályozása remek védekezést nyújthat túlzottan nagy mennyiségû kapcsolódási kérelem ellen. A megadható paraméterek teljes listája az &man.inetd.8; man oldalán olvasható. -c maximum Az egyes szolgáltatásokhoz egyszerre felépíthetõ kapcsolatok alapértelmezett maximális számát adja meg. Alapból ezt a démont nem korlátozza. A beállítással ez akár szolgáltatásonként külön is megadható. -C arány Korlátozza, hogy egyetlen IP-címrõl alapból hányszor hívhatóak meg az egyes szolgáltatások egy percen belül. Ez az érték alapból korlátlan. A beállítással ez szolgáltatásonként is definiálható. -R arány Megadja, hogy egy szolgáltatást egy perc alatt mennyiszer lehet meghívni. Ez az érték alapértelmezés szerint 256. A 0 megadásával eltöröljük ezt a típusú korlátozást. -s maximum Annak maximumát adja meg, hogy egyetlen IP-címrõl egyszerre az egyes szolgáltatásokat mennyiszer tudjuk elérni. Alapból ez korlátlan. Szolgáltatásonként ezt a paraméterrel tudjuk felülbírálni. Az <filename>inetd.conf</filename> állomány Az inetd beállítását az /etc/inetd.conf konfigurációs állományon keresztül végezhetjük el. Amikor az /etc/inetd.conf állományban módosítunk valamit, az inetd démont a következõ paranccsal meg kell kérnünk, hogy olvassa újra: Az <application>inetd</application> konfigurációs állományának újraolvasása &prompt.root; /etc/rc.d/inetd reload A konfigurációs állomány minden egyes sora egy-egy démont ír le. A megjegyzéseket egy # jel vezeti be. Az /etc/inetd.conf állomány bejegyzéseinek formátuma az alábbi: szolgáltatás-neve socket-típusa protokoll {wait|nowait}[/max-child[/max-connections-per-ip-per-minute[/max-child-per-ip]]] felhasználó[:csoport][/bejelentkezési-osztály] szerver-program szerver-program-paraméterei Az IPv4 protokollt használó &man.ftpd.8; démon bejegyzése például így néz ki: ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l szolgáltatás-neve Ez az adott démon által képviselt szolgáltatást nevezi meg, amelynek szerepelnie kell az /etc/services állományban. Ez határozza meg, hogy az inetd milyen porton figyelje a beérkezõ kapcsolatokat. Ha egy új szolgáltatást hozunk létre, akkor azt elõször az /etc/services állományba kell felvennünk. csatlakozás-típusa Ennek az értéke stream, dgram, raw, vagy seqpacket lehet. A stream típust használja a legtöbb kapcsolat-orientált TCP démon, miközben a dgram típus az UDP szállítási protokollt alkalmazó démonok esetében használatos. protokoll Valamelyik a következõk közül: Protokoll Magyarázat tcp, tcp4 TCP IPv4 udp, udp4 UDP IPv4 tcp6 TCP IPv6 udp6 UDP IPv6 tcp46 TCP IPv4 és v6 udp46 UDP IPv4 és v6 {wait|nowait}[/max-child[/max-connections-per-ip-per-minute[/max-child-per-ip]]] A beállítás mondja meg, hogy az inetd démonból meghívott démon saját maga képes-e kezelni kapcsolatokat. A típusú kapcsolatok esetében egyértelmûen a beállítást kell használni, miközben a esetén, ahol általában több szálon dolgozunk, a megadása javasolt. A hatására általában egyetlen démonnak adunk át több socketet, míg a minden sockethez egy újabb példányt indít el. Az inetd által indítható példányokat a megadásával korlátozhatjuk. Ha tehát például az adott démon számára legfeljebb példány létrehozását engedélyezzük, akkor a után /10 beállítást kell megadnunk. A /0 használatával korlátlan mennyiségû példányt engedélyezhetünk. A mellett még további két másik beállítás jöhet számításba az egyes démonok által kezelhetõ kapcsolatok maximális számának korlátozásában. A az egyes IP-címekrõl befutó lekezelhetõ kapcsolatok percenkénti számát szabályozza, így például ha itt a tizes értéket adjuk meg, akkor az adott szolgáltatáshoz egy IP-címrõl percenként csak tízszer férhetünk hozzá. A az egyes IP-címekhez egyszerre elindítható példányok számára ír elõ egy korlátot. Ezek a paraméterek segítenek megóvni rendszerünket az erõforrások akaratos vagy akaratlan kimerítésétõl és a DoS (Denial of Service) típusú támadásoktól. Ebben a mezõben a vagy valamelyikét kötelezõ megadni. A , és paraméterek ellenben elhagyhatóak. A típusú több szálon futó démonok a , vagy korlátozása nélkül egyszerûen csak így adhatóak meg: nowait. Ha ugyanezt a démont tíz kapcsolatra lekorlátozzuk, akkor a következõt kell megadnunk: nowait/10. Amikor pedig IP-címenként 20 kapcsolatot engedélyezünk percenként és mindössze 10 példányt, akkor: nowait/10/20. Az iménti beállítások a &man.fingerd.8; démon alapértelmezett paramétereinél is megtalálhatóak: finger stream tcp nowait/3/10 nobody /usr/libexec/fingerd fingerd -s Végezetül engedélyezzük 100 példányt, melyek közül IP-címenként 5 használható: nowait/100/0/5. felhasználó Ezzel azt a felhasználót adjuk meg, akinek a nevében az adott démon futni fog. Az esetek túlnyomó részében a démonokat a root felhasználó futtatja. Láthatjuk azonban, hogy biztonsági okokból bizonyos démonok a daemon vagy a legkevesebb joggal rendelkezõ nobody felhasználóval futnak. szerver-program A kapcsolat felépülésekor az itt teljes elérési úttal megadott démon indul el. Ha ezt a szolgáltatást maga az inetd belsõleg valósítja meg, akkor ebben a mezõben az értéket adjuk meg. szerver-program-paraméterei Ez a beállítással együtt mûködik, és ebben a mezõben a démon meghívásakor alkalmazandó paramétereket tudjuk rögzíteni, amelyet a démon nevével kezdünk. Ha a démont a parancssorból a sajátdémon -d paranccsal hívnánk meg, akkor a sajátdémon -d lesz beállítás helyes értéke is. Természetesen, ha a démon egy belsõleg megvalósított szolgáltatás, akkor ebben a mezõben is az fog megjelenni. Védelem Attól függõen, hogy a telepítés során mit választottunk, az inetd által támogatott szolgáltatások egyes része talán alapból engedélyezett is. Amennyiben egy adott démont konkrétan nem használunk, akkor érdemes megfontolni a letiltását. A kérdéses démon sorába tegyünk egy # jelet az /etc/inetd.conf állományba, majd olvastassuk újra az inetd beállításait. Egyes démonok, mint például az fingerd használata egyáltalán nem ajánlott, mivel a támadók számára hasznos információkat tudnak kiszivárogtatni. Más démonok nem ügyelnek a védelemre, és a kapcsolatokhoz rendelt lejárati idejük túlságosan hosszú vagy éppen nincs is. Ezzel a támadónak lehetõsége van lassú kapcsolatokkal leterhelni az adott démont, ezáltal kimeríteni a rendszer erõforrásait. Ha úgy találjuk, hogy túlságosan sok az ilyen kapcsolat, akkor jó ötletnek bizonyulhat a démonok számára a , vagy korlátozások elrendelése. Alapértelmezés szerint a TCP kapcsolatok wrappelése engedélyezett. A &man.hosts.access.5; man oldalon találhatjuk meg az inetd által meghívható különféle démonok TCP-alapú korlátozásainak lehetõségeit. Egyéb lehetõségek A daytime, time, echo, discard, chargen és auth szolgáltatások feladatainak mindegyikét maga az inetd is képes ellátni. Az auth szolgáltatás a hálózati keresztül azonosítást teszi lehetõvé és bizonyos mértékig beállítható. A többit egyszerûen csak kapcsoljuk ki vagy be. A témában az &man.inetd.8; man oldalán tudunk még jobban elmerülni. Tom Rhodes Átdolgozta és javította: Bill Swingle Írta: A hálózati állományrendszer (NFS) NFS A &os; több állományrendszert ismer, köztük a hálózati állományrendszert (Network File System, NFS) is. Az NFS állományok és könyvtárak megosztását teszi lehetõvé a hálózaton keresztül. Az NFS használatával a felhasználók és a programok képesek majdnem úgy elérni a távoli rendszereken található állományokat, mintha helyben léteznének. Íme az NFS néhány legjelentõsebb elõnye: A helyi munkaállomások kevesebb tárterületet használnak, mivel a közös adatokat csak egyetlen számítógépen tároljuk és megosztjuk mindenki között. A felhasználóknak nem kell a hálózat minden egyes gépén külön felhasználói könyvtárral rendelkezniük. Ezek ugyanis az NFS segítségével akár egy szerveren is beállíthatóak és elérhetõvé tehetõek a hálózaton keresztül. A különbözõ háttértárak, mint például a floppy lemezek, CD-meghajtók és &iomegazip; meghajtók a hálózaton több számítógép között megoszthatóak. Ezzel csökkenteni tudjuk a hálózatunkban szükséges cserélhetõ lemezes eszközök számát. Ahogy az <acronym>NFS</acronym> mûködik Az NFS legalább két fõ részbõl rakható össze: egy szerverbõl és egy vagy több kliensbõl. A kliensek a szerver által megosztott adatokhoz képesek távolról hozzáférni. A megfelelõ mûködéshez mindössze csak néhány programot kell beállítani és futtatni. A szervernek a következõ démonokat kell mûködtetnie: NFS szerver állományszerver UNIX kliensek rpcbind mountd nfsd Démon Leírás nfsd Az NFS démon, amely kiszolgálja az NFS kliensektõl érkezõ kéréseket. mountd Az NFS csatlakoztató démonja, amely végrehajtja az &man.nfsd.8; által átküldött kéréseket. rpcbind Ez a démon lehetõvé teszi az NFS kliensek számára, hogy fel tudják deríteni az NFS szerver által használt portot. A kliensen is futnia kell egy démonnak, amelynek a neve nfsiod. Az nfsiod démon az NFS szerver felõl érkezõ kéréseket szolgálja ki. A használata teljesen opcionális, csupán a teljesítményt hívatott javítani, de a normális és helyes mûködéshez nincs rá szükségünk. Az &man.nfsiod.8; man oldalán errõl többet is megtudhatunk. Az <acronym>NFS</acronym> beállítása NFS beállítás Az NFS beállítása viszonylag egyértelmûen adja magát. A mûködéséhez szükséges programok automatikus elindítása csupán néhány apró módosítást igényel az /etc/rc.conf állományban. Az NFS szerveren gondoskodjunk róla, hogy az alábbi beállítások szerepeljenek az /etc/rc.conf állományban: rpcbind_enable="YES" nfs_server_enable="YES" mountd_flags="-r" A mountd magától el fog indulni, ha az NFS szervert engedélyezzük. A kliensen a következõ beállítást kell felvennünk az /etc/rc.conf állományba: nfs_client_enable="YES" Az /etc/exports állomány adja meg, hogy az NFS milyen állományrendszereket exportáljon (vagy másképpen szólva osszon meg). Az /etc/exports állományban tehát a megosztani kívánt állományrendszereket kell szerepeltetnünk, és azt, hogy melyik számítógépekkel tudjuk ezeket elérni. A gépek megnevezése mellett a hozzáférésre további megszorításokat írhatunk fel. Ezek részletes leírását az &man.exports.5; man oldalon találjuk meg. Lássunk néhány példát az /etc/exports állományban megjelenõ bejegyzésekre: NFS példák exportálásra A most következõ példákban az állományrendszerek exportálásának finomságait igyekszünk érzékeltetni, noha a konkrét beállítások gyakran a rendszerünktõl és a hálózati konfigurációtól függenek. Például, ha a /cdrom könytárat akarjuk három gép számára megosztani, akik a szerverrel megegyezõ tartományban találhatóak (ezért nem is kell megadnunk a tartományt) vagy mert egyszerûen megtalálhatók az /etc/hosts állományunkban. Az beállítás az exportált állományrendszereket írásvédetté teszi. Ezzel a beállítással a távoli rendszerek nem lesznek képesek módosítani az exportált állományrendszer tartalmát. /cdrom -ro gép1 gép2 gép3 A következõ sorban a /home könyvtárat három gép számára osztjuk meg, melyeket IP-címekkel adtunk meg. Ez olyan helyi hálózat esetén hasznos, ahol nem állítottunk be névfeloldást. Esetleg a belsõ hálózati neveket az /etc/hosts állományban is tárolhatjuk. Ezzel utóbbival kapcsolatban a &man.hosts.5; man oldalt érdemes fellapoznunk. Az beállítás lehetõvé teszi, hogy az alkönyvtárak is csatlakozási pontok lehessenek. Más szóval, nem fogja csatlakoztatni az alkönyvtárakat, de megengedi a kliensek számára, hogy csak azokat a könyvtárakat csatlakoztassák, amelyeket kell vagy amelyekre szükségünk van. /home -alldirs 10.0.0.2 10.0.0.3 10.0.0.4 A következõ sorban az /a könyvtárat úgy exportáljuk, hogy az állományrendszerhez két különbözõ tartományból is hozzá lehessen férni. A beállítás hatására a távoli rendszer root felhasználója az exportált állományrendszeren szintén root felhasználóként fogja írni az adatokat. Amennyiben a -maproot=root beállítást nem adjuk meg, akkor a távoli rendszeren hiába root az adott felhasználó, az exportált állományrendszeren nem lesz képes egyetlen állományt sem módosítani. /a -maproot=root gep.minta.com doboz.haz.org A kliensek is csak a megfelelõ engedélyek birtokában képesek elérni a megosztott állományrendszereket. Ezért a klienst ne felejtsük el felvenni a szerver /etc/exports állományába. Az /etc/exports állományban az egyes sorok az egyes állományrendszerekre és az egyes gépekre vonatkoznak. A távoli gépek állományrendszerenként csak egyszer adhatóak meg, és csak egy alapértelmezett bejegyzésük lehet. Például tegyük fel, hogy a /usr egy önálló állományrendszer. Ennek megfelelõen az alábbi bejegyzések az /etc/exports állományban érvénytelenek: # Nem használható, ha a /usr egy állományrendszer: /usr/src kliens /usr/ports kliens Egy állományrendszerhez, vagyis itt a /usr partícióhoz, két export sort is megadtunk ugyanahhoz a kliens nevû géphez. Helyesen így kell megoldani az ilyen helyzeteket: /usr/src /usr/ports kliens Az adott géphez tartozó egy állományrendszerre vonatkozó exportoknak mindig egy sorban kell szerepelniük. A kliens nélkül felírt sorok egyetlen géphez tartozónak fognak számítani. Ezzel az állományrendszerek megosztását tudjuk szabályozni, de legtöbbek számára nem jelent gondot. Most egy érvényes exportlista következik, ahol a /usr és az /exports mind helyi állományrendszerek: # Osszuk meg az src és ports könyvtárakat a kliens01 és kliens02 részére, de csak a # kliens01 férhessen hozzá rendszeradminisztrátori jogokkal: /usr/src /usr/ports -maproot=root kliens01 /usr/src /usr/ports kliens02 # A kliensek az /exports könyvtárban teljes joggal rendelkeznek és azon belül # bármit tudnak csatlakoztatni. Rajtuk kívül mindenki csak írásvédetten képes # elérni az /exports/obj könyvtárat: /exports -alldirs -maproot=root kliens01 kliens02 /exports/obj -ro A mountd démonnal az /etc/exports állományt minden egyes módosítása után újra be kell olvastatni, mivel a változtatásaink csak így fognak érvényesülni. Ezt megcsinálhatjuk úgy is, hogy küldünk egy HUP (hangup, avagy felfüggesztés) jelzést a már futó démonnak: &prompt.root; kill -HUP `cat /var/run/mountd.pid` vagy meghívjuk a mountd &man.rc.8; szkriptet a megfelelõ paraméterrel: &prompt.root; /etc/rc.d/mountd onereload Az ban tudhatunk meg részleteket az rc szkriptek használatáról. Ezek után akár a &os; újraindításával is aktiválhatjuk a megosztásokat, habár ez nem feltétlenül szükséges. Ha root felhasználónként kiadjuk a következõ parancsokat, akkor azzal minden szükséges programot elindítunk. Az NFS szerveren tehát: &prompt.root; rpcbind &prompt.root; nfsd -u -t -n 4 &prompt.root; mountd -r Az NFS kliensen pedig: &prompt.root; nfsiod -n 4 Ezzel most már minden készen áll a távoli állományrendszer csatlakoztatására. A példákban a szerver neve szerver lesz, valamint a kliens neve kliens. Ha csak ideiglenesen akarunk csatlakoztatni egy állományrendszert vagy egyszerûen csak ki akarjuk próbálni a beállításainkat, a kliensen root felhasználóként az alábbi parancsot hajtsuk végre: NFS csatlakoztatás &prompt.root; mount szerver:/home /mnt Ezzel a szerveren található /home könyvtárat fogjuk a kliens /mnt könyvtárába csatlakoztatni. Ha mindent jól beállítottunk, akkor a kliensen most már be tudunk lépni az /mnt könyvtárba és láthatjuk a szerveren található állományokat. Ha a számítógép indításával automatikusan akarunk hálózati állományrendszereket csatlakoztatni, akkor vegyük fel ezeket az /etc/fstab állományba. Erre íme egy példa: szerver:/home /mnt nfs rw 0 0 Az &man.fstab.5; man megtalálhatjuk az összes többi beállítást. Zárolások Bizonyos alkalmazások (például a mutt) csak akkor mûködnek megfelelõen, ha az állományokat a megfelelõ módon zárolják. Az NFS esetében az rpc.lockd használható az ilyen zárolások megvalósítására. Az engedélyezéséhez mind a szerveren és a kliensen vegyük fel a következõ sort az /etc/rc.conf állományba (itt már feltételezzük, hogy az NFS szervert és klienst korábban beállítottuk): rpc_lockd_enable="YES" rpc_statd_enable="YES" A következõ módon indíthatjuk el: &prompt.root; /etc/rc.d/lockd start &prompt.root; /etc/rc.d/statd start Ha nincs szükségünk valódi zárolásra az NFS kliensek és az NFS szerver között, akkor megcsinálhatjuk azt is, hogy az NFS kliensen a &man.mount.nfs.8; programnak az paraméter átadásával csak helyileg végzünk zárolást. Ennek további részleterõl a &man.mount.nfs.8; man oldalon kaphatunk felvilágosítást. Gyakori felhasználási módok Az NFS megoldását a gyakorlatban rengeteg esetben alkalmazzák. Ezek közül most felsoroljuk a legelterjedtebbeket: NFS használata Több gép között megosztunk egy telepítõlemezt vagy más telepítõeszközt. Ez így sokkal olcsóbb és gyakorta kényelmes megoldás abban az esetben, ha egyszerre több gépre akarjuk ugyanazt a szoftvert telepíteni. Nagyobb hálózatokon sokkal kényelmesebb lehet egy központi NFS szerver használata, ahol a felhasználók könyvtárait tároljuk. Ezek a felhasználói könyvtárak aztán megoszthatóak a hálózaton keresztül, így a felhasználók mindig ugyanazt a könyvárat kapják függetlenül attól, hogy milyen munkaállomásról is jelentkeztek be. Több géppel is képes így osztozni az /usr/ports/distfiles könyvtáron. Ezen a módon sokkal gyorsabban tudunk portokat telepíteni a gépekre, mivel nem kell külön mindegyikre letölteni az ehhez szükséges forrásokat. Wylie Stilwell Készítette: Chern Lee Újraírta: Automatikus csatlakoztatás az <application>amd</application> használatával amd automatikus csatlakoztató démon Az &man.amd.8; (automatikus csatlakoztató démon, az automatic mounter daemon) önmûködõen csatlakoztatja a távoli állományrendszereket, amikor azokon belül valamelyik állományhoz vagy könyvtárhoz próbálunk hozzáférni. Emellett az amd az egy ideje már inaktív állományrendszereket is automatikusan leválasztja. Az amd használata egy remek alternatívát kínál az általában az /etc/fstab állományban megjelenõ állandóan csatlakoztatott állományrendszerekkel szemben. Az amd úgy mûködik, hogy kapcsolódik egy NFS szerver /host és /net könyvtáraihoz. Amikor egy állományt akarunk elérni ezeken a könyvtárakon belül, az amd kikeresi a megfelelõ távoli csatlakoztatást és magától csatlakoztatja. A /net segítségével egy IP-címrõl tudunk exportált állományrendszereket csatlakoztatni, miközben a /host a távoli gép hálózati neve esetében használatos. Ha tehát a /host/izemize/usr könyvtárban akarunk elérni egy állományt, akkor az amd démonnak ahhoz elõször az izemize nevû géprõl exportált /usr könyvtárat kell csatlakoztatnia. Egy exportált állományrendszer csatlakoztatása az <application>amd</application> használatával Egy távoli számítógép által rendelkezésre bocsátott megosztásokat a showmount paranccsal tudjuk lekérdezni. Például az izemize gépen elérhetõ exportált állományrendszereket így láthatjuk: &prompt.user; showmount -e izemize Exports list on izemize: /usr 10.10.10.0 /a 10.10.10.0 &prompt.user; cd /host/izemize/usr Ahogy a példában látjuk is, a showmount parancs a /usr könyvtárat mutatja megosztásként. Amikor tehát belépünk a /host/izemize/usr könyvtárba, akkor amd magától megpróbálja feloldani az izemize hálózati nevet és csatlakoztatni az elérni kívánt exportált állományrendszert. Az amd az indító szkripteken keresztül az /etc/rc.conf alábbi beállításával engedélyezhetõ: amd_enable="YES" Emellett még az amd_flags használatával további paraméterek is átadható az amd felé. Alapértelmezés szerint az amd_flags tartalmaz az alábbi: amd_flags="-a /.amd_mnt -l syslog /host /etc/amd.map /net /etc/amd.map" Az /etc/amd.map állomány adja meg az exportált állományrendszerek alapértelmezett beállításait. Az /etc/amd.conf állományban az amd további lehetõségeit konfigurálhatjuk.. Ha többet is szeretnénk tudni a témáról, akkor az &man.amd.8; és az &man.amd.conf.5; man oldalakat javasolt elolvasnunk. John Lind Készítette: Problémák más rendszerek használatakor Némely PC-s ISA buszos Ethernet kártyákra olyan korlátozások érvényesek, melyek komoly hálózati problémák keletkezéséhez vezethetnek, különösen az NFS esetében. Ez a nehézség nem &os;-függõ, de a &os; rendszereket is érinti. Ez gond általában majdnem mindig akkor merül fel, amikor egy (&os;-s) PC egy hálózatba kerül többek közt a Silicon Graphic és a Sun Microsystems által gyártott nagyteljesítményû munkaállomásokkal. Az NFS csatlakoztatása és bizonyos mûveletek még hibátlanul végrehajtódnak, azonban hirtelen a szerver látszólag nem válaszol többet a kliens felé úgy, hogy a többi rendszertõl folyamatosan dolgozza felfele a kéréseket. Ez a kliens rendszeren tapasztalható csak, amikor a kliens &os; vagy egy munkaállomás. Sok rendszeren egyszerûen rendesen le sem lehet állítani a klienst, ha a probléma egyszer már felütötte a fejét. Egyedüli megoldás gyakran csak a kliens újraindítása marad, mivel az NFS-ben kialakult helyzetet máshogy nem lehet megoldani. Noha a helyes megoldás az lenne, ha beszereznénk egy nagyobb teljesítményû és kapacitású kártyát a &os; rendszer számára, azonban egy jóval egyszerûbb kerülõút is található a kielégítõ mûködés eléréséhez. Ha a &os; rendszer képviseli a szervert, akkor a kliensnél adjuk meg a beállítást is a csatlakoztatásnál. Ha a &os; rendszer a kliens szerepét tölti be, akkor az NFS állományrendszert az beállítással csatlakoztassuk róla. Ezek a beállítások az fstab állomány negyedik mezõjében is megadhatóak az automatikus csatlakoztatáshoz, vagy manuális esetben a &man.mount.8; parancsnak a paraméterrel. Hozzá kell azonban tennünk, hogy létezik egy másik probléma, amit gyakran ezzel tévesztenek össze, amikor az NFS szerverek és kliensek nem ugyanabban a hálózatban találhatóak. Ilyen esetekben mindenképpen gyõzõdjünk meg róla, hogy az útválasztók rendesen továbbküldik a mûködéshez szükséges UDP információkat, különben nem sokat tudunk tenni a megoldás érdekében. A most következõ példákban a gyorsvonat lesz a nagyteljesítményû munkaállomás (felület) neve, illetve a freebsd pedig a gyengébb teljesítményû Ethernet kártyával rendelkezõ &os; rendszer (felület) neve. A szerveren az /osztott nevû könyvtárat fogjuk NFS állományrendszerként exportálni (lásd &man.exports.5;), amelyet majd a /projekt könyvtárba fogunk csatlakoztatni a kliensen. Minden esetben érdemes lehet még megadnunk a vagy , illetve opciókat is. Ebben a példában a &os; rendszer (freebsd) lesz a kliens, és az /etc/fstab állományában így szerepel az exportált állományrendszer: gyorsvonat:/osztott /projekt nfs rw,-r=1024 0 0 És így tudjuk manuálisan csatlakoztatni: &prompt.root; mount -t nfs -o -r=1024 gyorsvonat:/osztott /projekt Itt a &os; rendszer lesz a szerver, és a gyorsvonat /etc/fstab állománya így fog kinézni: freebsd:/osztott /projekt nfs rw,-w=1024 0 0 Manuálisan így csatlakoztathatjuk az állományrendszert: &prompt.root; mount -t nfs -o -w=1024 freebsd:/osztott /projekt Szinte az összes 16 bites Ethernet kártya képes mûködni a fenti írási vagy olvasási korlátozások nélkül is. A kíváncsibb olvasók számára eláruljuk, hogy pontosan miért is következik be ez a hiba, ami egyben arra is magyarázatot ad, hogy miért nem tudjuk helyrehozni. Az NFS általában 8 kilobyte-os blokkokkal dolgozik (habár kisebb méretû darabkákat is tud készíteni). Mivel az Ethernet által kezelt legnagyobb méret nagyjából 1500 byte, ezért az NFS blokkokat több Ethernet csomagra kell osztani — még olyankor is, ha ez a program felsõbb rétegeiben osztatlan egységként látszik — ezt aztán fogadni kell, összerakni és nyugtázni mint egységet. A nagyteljesítményû munkaállomások a szabvány által még éppen megengedett szorossággal képesek ontani magukból az egy egységhez tartozó csomagokat, közvetlenül egymás után. A kisebb, gyengébb teljesítményû kártyák esetében azonban az egymáshoz tartozó, késõbb érkezõ csomagok ráfutnak a korábban megkapott csomagokra még pontosan azelõtt, hogy elérnék a gépet, így az egységek nem állíthatóak össze vagy nem nyugtázhatóak. Ennek eredményeképpen a munkaállomás egy adott idõ múlva megint próbálkozik, de ismét az egész 8 kilobyte-os blokkot küldi el, ezért ez a folyamat a végtelenségig ismétlõdik. Ha a küldendõ egységek méretét az Ethernet által kezelt csomagok maximális mérete alá csökkentjük, akkor biztosak lehetünk benne, hogy a teljes Ethernet csomag egyben megérkezik és nyugtázódik, így elkerüljük a holtpontot. A nagyteljesítményû munkaállomások természetesen továbbra is küldhetnek a PC-s rendszerek felé túlfutó csomagokat, de egy jobb kártyával az ilyen túlfutások nem érintik az NFS által használt egységeket. Amikor egy ilyen túlfutás bekövetkezik, az érintett egységet egyszerûen újra elküldik, amelyet a rákövetkezõ alkalommal nagy valószínûséggel már tudunk rendesen fogadni, összerakni és nyugtázni. Bill Swingle Írta: Eric Ogren Írta: Udo Erdelhoff Hálózati információs rendszer (NIS/YP) Mi ez? NIS Solaris HP-UX AIX Linux NetBSD OpenBSD A hálózati információs szolgáltatást (Network Information Service, avagy NIS) a Sun Microsystems fejlesztette ki a &unix; (eredetileg &sunos;) rendszerek központosított karbantartásához. Mostanra már lényegében ipari szabvánnyá nõtte ki magát, hiszen az összes nagyobb &unix;-szerû rendszer (a &solaris;, HP-UX, &aix;, Linux, NetBSD, OpenBSD, &os; stb.) támogatja a NIS használatát. sárga oldalak NIS A NIS régebben sárga oldalak (Yellow Pages) néven volt ismert, de a különbözõ jogi problémák miatt késõbb ezt a Sun megváltoztatta. A régi elnevezést (és a yp rövidítést) azonban még napjainkban is lehet néhol látni. NIS tartományok Ez egy RPC alapján mûködõ, kliens/szerver felépítésû rendszer, amely az egy NIS tartomány belül levõ számítógépek számára teszi lehetõvé ugyanazon konfigurációs állományok használatát. Segítségével a rendszergazda a NIS klienseket a lehetõ legkevesebb adat hozzáadásával, eltávolításával vagy módosításával képes egyetlen helyrõl beállítani. Windows NT Hasonló a &windowsnt; tartományaihoz, és habár a belsõ implementációt tekintve már akadnak köztük jelentõs eltérések is, az alapvetõ funkciók szintjén mégis összevethetõek. A témához tartozó fogalmak és programok A NIS telepítése számos fogalom és fontos felhasználói program kerül elõ &os;-n, akár egy NIS szervert akarunk beállítani, akár csak egy NIS klienst: rpcbind portmap Fogalom Leírás NIS tartománynév A NIS központi szerverei és az összes hozzájuk tartozó kliens (beleértve az alárendelt szervereket) rendelkezik egy NIS tartománynévvel. Hasonló a &windowsnt; által használt tartománynevekhez, de a NIS tartománynevei semmilyen kapcsolatban nem állnak a névfeloldással. rpcbind Az RPC (Remote Procedure Call, a NIS által használt egyik hálózati protokoll) engedélyezéséhez lesz rá szükségünk. Ha az rpcbind nem fut, akkor sem NIS szervert, sem pedig NIS klienst nem tudunk mûködtetni. ypbind A NIS klienst köti össze a hozzátartozó NIS szerverrel. A NIS tartománynevet a rendszertõl veszi, és az RPC használatával csatlakozik a szerverhez. Az ypbind a NIS környezet kliens és szerver közti kommunikációjának magját alkotja. Ha az ypbind leáll a kliens gépén, akkor nem tudjuk elérni a NIS szervert. ypserv Csak a NIS szervereken szabad futnia, mivel ez maga a NIS szerver programja. Ha az &man.ypserv.8; leáll, akkor a szerver nem lesz képes tovább kiszolgálni a NIS kéréseket (szerencsére az alárendelt szerverek képesek átvenni ezeket). A NIS bizonyos változatai (de nem az, amelyik a &os;-ben is megjelenik) nem próbálnak meg más szerverekhez csatlakozni, ha bedöglik az aktuális használt szerver. Ezen gyakran egyedül csak a szervert képviselõ program (vagy akár az egész szerver) újraindítása segíthet, illetve az ypbind újraindítása a kliensen. rpc.yppasswdd Ez egy olyan program, amelyet csak a NIS központi szerverein kell csak futtatni. Ez a démon a NIS kliensek számára a NIS jelszavaik megváltoztatását teszi lehetõvé. Ha ez a démon nem fut, akkor a felhasználók csak úgy tudják megváltoztatni a jelszavukat, ha bejelentkeznek a központi NIS szerverre. Hogyan mûködik? A NIS környezetekben háromféle gép létezik: a központi szerverek, az alárendelt szerverek és a kliensek. A szerverek képezik a gépek konfigurációs információinak központi tárhelyét. A központi szerverek tárolják ezen információk hiteles másolatát, míg ezt az alárendelt szerverek redundánsan tükrözik. A kliensek a szerverekre támaszkodnak ezen információk beszerzéséhez. Sok állomány tartalma megosztható ezen a módon. Például a master.passwd, a group és hosts állományokat meg szokták osztani NFS-en. Amikor a kliensen futó valamelyik programnak olyan információra lenne szüksége, amely általában ezekben az állományokban nála megtalálható lenne, akkor helyette a NIS szerverhez fordul. A gépek típusai NIS központi szerver A központi NIS szerver. Ez a szerver, amely leginkább a &windowsnt; elsõdleges tartományvezérlõjéhez hasonlítható tartja karban az összes, NIS kliensek által használt állományt. A passwd, group, és összes többi ehhez hasonló állomány ezen a központi szerveren található meg. Egy gép akár több NIS tartományban is lehet központi szerver. Ezzel a lehetõséggel viszont itt most nem foglalkozunk, mivel most csak egy viszonylag kis méretû NIS környezetet feltételezünk. NIS alárendelt szerver Az alárendelt NIS szerverek. A &windowsnt; tartalék tartományvezérlõihez hasonlítanak, és az alárendelt NIS szerverek feladata a központi NIS szerveren tárolt adatok másolatainak karbantartása. Az alárendelt NIS szerverek a redundancia megvalósításában segítenek, aminek leginkább a fontosabb környezetekben van szerepe. Emellett a központi szerver terhelésének kiegyenlítését is elvégzik. A NIS kliensek elsõként mindig ahhoz a NIS szerverhez csatlakoznak, amelytõl elõször választ kapnak, legyen akár az egy alárendelt szerver. NIS kliens A NIS kliensek. A NIS kliensek, hasonlóan a &windowsnt; munkaállomásokhoz, a NIS szerveren (amely a &windowsnt; munkaállomások esetében a tartományvezérlõ) keresztül jelentkeznek be. A NIS/YP használata Ebben a szakaszban egy példa NIS környezetet állítunk be. Tervezés Tegyük fel, hogy egy aprócska egyetemi labor rendszergazdái vagyunk. A labor, mely 15 &os;-s gépet tudhat magáénak, jelen pillanatban még semmilyen központosított adminisztráció nem létezik. Mindegyik gép saját /etc/passwd és /etc/master.passwd állománnyal rendelkezik. Ezeket az állományokat saját kezûleg kell szinkronban tartani. Tehát ha most felveszünk egy felhasználót a laborhoz, akkor az adduser parancsot mind a 15 gépen ki kell adni. Egyértelmû, hogy ez így nem maradhat, ezért úgy döntöttük, hogy a laborban NIS-t fogunk használni, és két gépet kinevezünk szervernek. Az iméntieknek megfelelõen a labor most valahogy így néz ki: A gép neve IP-cím A gép szerepe ellington 10.0.0.2 központi NIS coltrane 10.0.0.3 alárendelt NIS basie 10.0.0.4 tanszéki munkaállomás bird 10.0.0.5 kliensgép cli[1-11] 10.0.0.[6-17] a többi kliensgép Ha még nincs tapasztalatunk a NIS rendszerek összeállításában, akkor elõször jó ötlet lehet végiggondolni, miként is akarjuk kialakítani. A hálózatunk méretétõl függetlenül is akadnak olyan döntések, amelyeket mindenképpen meg kell hoznunk. A NIS tartománynév megválasztása NIS tartománynév Ez nem az a tartománynév, amit megszokhattunk. Ennek a pontos neve NIS tartománynév. Amikor a kliensek kérnek valamilyen információt, akkor megadják annak a NIS tartománynak a nevét is, amelynek részei. Így tud egy hálózaton több szerver arról dönteni, hogy melyikük melyik kérést válaszolja meg. A NIS által használt tartománynévre tehát inkább úgy érdemes gondolni, mint egy valamilyen módon összetartozó gépek közös nevére. Elõfordul, hogy egyes szervezetek az interneten is nyilvántartott tartománynevüket választják NIS tartománynévnek. Ez alapvetõen nem ajánlott, mivel a hálózati problémák felderítése közben félreértéseket szülhet. A NIS tartománynévnek a hálózatunkon belül egyedinek kell lennie, és lehetõleg minél jobban írja le az általa csoportba sorolt gépeket. Például a Kis Kft. üzleti osztályát tegyük a kis-uzlet NIS tartományba. Ebben a példában most a proba-tartomany nevet választottuk. SunOS A legtöbb operációs rendszer azonban (köztük a &sunos;) a NIS tartománynevet használja internetes tartománynévként is. Ha a hálózatunkon egy vagy több ilyen gép is található, akkor a NIS tartomány nevének az internetes tartománynevet kell megadnunk. A szerverek fizikai elvárásai Nem árt néhány dolgot fejben tartani, amikor a NIS szervernek használt gépet kiválasztjuk. Az egyik ilyen szerencsétlen dolog az a szintû függõség, ami a NIS kliensek felõl megfigyelhetõ a szerverek felé. Ha egy kliens nem tudja a NIS tartományon belül felvenni a kapcsolatot valamelyik szerverrel, akkor az a gép könnyen megbízhatatlanná válhat. Felhasználói- és csoportinformációk nélkül a legtöbb rendszer egy idõre le is merevedik. Ennek figyelembevételével tehát olyan gépet kell szervernek választanunk, amelyet nem kell gyakran újraindítani, és nem végzünk rajta semmilyen komoly munkát. A célnak legjobban megfelelõ NIS szerverek valójában olyan gépek, amelyek egyedüli feladata csak a NIS kérések kiszolgálása. Ha a hálózatunk nem annyira leterhelt, akkor még a NIS szerver mellett más programokat is futtathatunk, de ne feledjük, hogy ha a NIS szolgáltatás megszûnik, akkor az az összes NIS kliensen éreztetni fogja kedvezõtlen hatását. A NIS szerverek A NIS rendszerben tárolt összes információ általános példánya egyetlen gépen található meg, amelyet a központi NIS szervernek hívunk. Az információk tárolására szánt adatbázis pedig NIS táblázatoknak (NIS map) nevezzük. &os; alatt ezek a táblázatok a /var/yp/tartománynév könyvtárban találhatóak, ahol a tartománynév a kiszolgált NIS tartományt nevezi meg. Egyetlen NIS szerver egyszerre akár több tartományt is kiszolgálhat, így itt több könyvtár is található, minden támogatott tartományhoz egy. Minden tartomány saját, egymástól független táblázatokkal rendelkezik. A központi és alárendelt NIS szerverek az ypserv démon segítségével dolgozzák fel a NIS kéréseket. Az ypserv felelõs a NIS kliensektõl befutó kérések fogadásáért, és a kért tartomány valamint táblázat nevébõl meghatározza az adatbázisban tárolt állományt, majd innen visszaküldi a hozzátartozó adatot a kliensnek. A központi NIS szerver beállítása NIS szerver beállítása A központi NIS szerver beállítása viszonylag magától értetõdõ, de a nehézségét az igényeink szabják meg. A &os; alapból támogatja a NIS használatát. Ezért mindössze annyit kell tennünk, hogy a következõ sorokat betesszük az /etc/rc.conf állományba, és a &os; gondoskodik a többirõl. nisdomainname="proba-tartomany" Ez a sor adja meg a hálózati beállítások (vagy például az újraindítás) során a NIS tartomány nevét, amely a korábbiak szerint itt most a proba-tartomany. nis_server_enable="YES" Ezzel utasítjuk a &os;-t, hogy a hálózati alkalmazások következõ indításakor a NIS szervert is aktiválja. nis_yppasswdd_enable="YES" Ezzel engedélyezzük az rpc.yppasswdd démont, amely a korábban említettek szerint lehetõvé teszi a felhasználók számára, hogy a közvetlenül a kliensekrõl változtassák meg a NIS jelszavukat. A konkrét NIS beállításainktól függõen további bejegyzések felvételére is szükségünk lehet. Erre késõbb még az olyan NIS szervereknél, amelyek egyben NIS kliensek, vissza fogunk térni. Most mindössze annyit kell tennünk, hogy rendszeradminisztrátorként kiadjuk az /etc/netstart parancsot. Az /etc/rc.conf állományban szereplõ adatok alapján mindent beállít magától. A NIS táblázatok inicializálása NIS táblázatok A NIS táblázatok lényegében a /var/yp könyvtárban tárolt adatbázisok. A központi NIS szerver /etc könyvtárában található konfigurációs állományokból állítódnak elõ, egyetlen kivétellel: ez az /etc/master.passwd állomány. Ennek megvan a maga oka, hiszen nem akarjuk a root és az összes többi fontosabb felhasználóhoz tartozó jelszót az egész NIS tartománnyal megosztani. Ennek megfelelõen a NIS táblázatok inicializálásához a következõt kell tennünk: &prompt.root; cp /etc/master.passwd /var/yp/master.passwd &prompt.root; cd /var/yp &prompt.root; vi master.passwd El kell távolítanunk az összes rendszerszintû (bin, tty, kmem, games, stb), és minden olyan egyéb hozzáférést, amelyeket nem akarjuk közvetíteni a NIS kliensek felé (például a root és minden más nullás, vagyis rendszeradminisztrátori azonosítóval ellátott hozzáférést). Gondoskodjunk róla, hogy az /var/yp/master.passwd állomány sem a csoport, sem pedig bárki más számára nem olvasható (600-as engedély)! Ennek beállításához használjuk az chmod parancsot, ha szükséges. Tru64 UNIX Ha végeztünk, akkor már tényleg itt az ideje inicializálni NIS táblázatainkat. A &os; erre egy ypinit nevû szkriptet ajánl fel (errõl a saját man oldalán tudhatunk meg többet). Ez a szkript egyébként a legtöbb &unix; típusú operációs rendszeren megtalálható, de nem az összesen. A Digital UNIX/Compaq Tru64 UNIX rendszereken ennek a neve ypsetup. Mivel most a központi NIS szerver táblázatait hozzuk létre, azért az ypinit szkriptnek át kell adnunk a opciót is. A NIS táblázatok elõállításánál feltételezzük, hogy a fentebb ismertetett lépéseket már megtettük, majd kiadjuk ezt a parancsot: ellington&prompt.root; ypinit -m proba-tartomany Server Type: MASTER Domain: proba-tartomany Creating an YP server will require that you answer a few questions. Questions will all be asked at the beginning of the procedure. Do you want this procedure to quit on non-fatal errors? [y/n: n] n Ok, please remember to go back and redo manually whatever fails. If you don't, something might not work. At this point, we have to construct a list of this domains YP servers. rod.darktech.org is already known as master server. Please continue to add any slave servers, one per line. When you are done with the list, type a <control D>. master server : ellington next host to add: coltrane next host to add: ^D The current list of NIS servers looks like this: ellington coltrane Is this correct? [y/n: y] y [ .. a táblázatok generálása .. ] NIS Map update completed. ellington has been setup as an YP master server without any errors. Az üzenetek fordítása: A szerver típusa: KÖZPONTI, tartomány: proba-tartomany Az YP szerver létrehozásához meg kell válaszolni néhány kérdést az eljárás megkezdése elõtt. Szeretnénk, ha az eljárás megszakadna a nem végzetes hibák esetén is? [i/n: n] n Rendben, akkor ne felejtsük el manuálisan kijavítani a hibát, ha valamivel gond lenne. Ha nem tesszük meg, akkor elõfordulhat, hogy valami nem fog rendesen mûködni. Most össze kell állítanunk egy listát a tartomány YP szervereirõl. Jelenleg a rod.darktech.org a központi szerver. Kérjünk, adjon meg további alárendelt szervereket, soronként egyet. Amikor ezt befejeztük, a <control D> lenyomásával tudunk kilépni. központi szerver : ellington következõ gép : coltrane következõ gép : ^D A NIS szerverek listája jelenleg a következõ: ellington coltrane Ez megfelelõ? [i/n: i] i [ .. a táblázatok generálása .. ] A NIS táblázatok sikeressen frissültek. Az elligon szervert minden hiba nélkül sikerült központi szerverként beállítani. Az ypinit a /var/yp/Makefile.dist állományból létrehozza a /var/yp/Makefile állományt. Amennyiben ez létrejött, az állomány feltételezi, hogy csak &os;-s gépek részvételével akarunk kialakítani egy egyszerveres NIS környezetet. Mivel a proba-tartomany még egy alárendelt szervert is tartalmaz, ezért át kell írnunk a /var/yp/Makefile állományt: ellington&prompt.root; vi /var/yp/Makefile Ezt a sort kell megjegyzésbe tennünk: NOPUSH = "True" (ha még nem lenne úgy). Az alárendelt NIS szerverek beállítása NIS alárendelt szerver Az alárendelt NIS szerverek beállítása még a központinál is egyszerûbb. Jelentkezzünk be az alárendelt szerverre és az eddigieknek megfelelõen írjuk át az /etc/rc.conf állományt. Az egyetlen különbség ezúttal csupán annyi lesz, hogy az ypinit lefuttatásakor a opciót kell megadnunk (mint slave, vagyis alárendelt). A opció használatához a központi NIS szerver nevét is át kell adnunk, ezért a konkrét parancs valahogy így fog kinézni: coltrane&prompt.root; ypinit -s ellington proba-tartomany Server Type: SLAVE Domain: test-domain Master: ellington Creating an YP server will require that you answer a few questions. Questions will all be asked at the beginning of the procedure. Do you want this procedure to quit on non-fatal errors? [y/n: n] n Ok, please remember to go back and redo manually whatever fails. If you don't, something might not work. There will be no further questions. The remainder of the procedure should take a few minutes, to copy the databases from ellington. Transferring netgroup... ypxfr: Exiting: Map successfully transferred Transferring netgroup.byuser... ypxfr: Exiting: Map successfully transferred Transferring netgroup.byhost... ypxfr: Exiting: Map successfully transferred Transferring master.passwd.byuid... ypxfr: Exiting: Map successfully transferred Transferring passwd.byuid... ypxfr: Exiting: Map successfully transferred Transferring passwd.byname... ypxfr: Exiting: Map successfully transferred Transferring group.bygid... ypxfr: Exiting: Map successfully transferred Transferring group.byname... ypxfr: Exiting: Map successfully transferred Transferring services.byname... ypxfr: Exiting: Map successfully transferred Transferring rpc.bynumber... ypxfr: Exiting: Map successfully transferred Transferring rpc.byname... ypxfr: Exiting: Map successfully transferred Transferring protocols.byname... ypxfr: Exiting: Map successfully transferred Transferring master.passwd.byname... ypxfr: Exiting: Map successfully transferred Transferring networks.byname... ypxfr: Exiting: Map successfully transferred Transferring networks.byaddr... ypxfr: Exiting: Map successfully transferred Transferring netid.byname... ypxfr: Exiting: Map successfully transferred Transferring hosts.byaddr... ypxfr: Exiting: Map successfully transferred Transferring protocols.bynumber... ypxfr: Exiting: Map successfully transferred Transferring ypservers... ypxfr: Exiting: Map successfully transferred Transferring hosts.byname... ypxfr: Exiting: Map successfully transferred coltrane has been setup as an YP slave server without any errors. Don't forget to update map ypservers on ellington. Most már lennie kell egy /var/yp/proba-tartomany nevû könyvtárunknak is. A központi NIS szerver táblázatainak másolata itt fognak tárolódni. Ezeket soha ne felejtsük el frissen tartani. Az alárendelt szervereken a következõ /etc/crontab bejegyzések pontosan ezt a feladatot látják el: 20 * * * * root /usr/libexec/ypxfr passwd.byname 21 * * * * root /usr/libexec/ypxfr passwd.byuid Ez a két sor gondoskodik róla, hogy az alárendelt szerverek ne felejtsék el egyeztetni a táblázataikat a központi szerver táblázataival. Habár ezek a bejegyzések nem nélkülözhetetlenek a megfelelõ mûködéshez, mivel a központi szerver mindig igyekszik az alárendelt szervereknek elküldeni a NIS táblázataiban létrejött változásokat. Mivel azonban a jelszavak létfontosságúak a szervertõl függõ rendszerek számára, ezért jó ötlet lehet explicit módon is elõírni a frissítést. Ez a forgalmasabb hálózatokon nagyobb jelentõséggel bír, mivel ott a táblázatok frissítése nem mindig fejezõdik be rendesen. Most pedig futassuk le a /etc/netstart parancsot az alárendelt szervereken is, amivel így elindul a NIS szerver. A NIS kliensek A NIS kliens az ypbind démon segítségével egy kötésnek (bind) nevezett kapcsolatot épít ki egy adott NIS szerverrel. Az ypbind ellenõrzi a rendszer alapértelmezett tartományát (ezt a domainname paranccsal állítottunk be), majd RPC kéréseket kezd szórni a helyi hálózaton. Ezek a kérések annak a tartománynak a nevét tartalmazzák, amelyhez az ypbind megpróbál kötést létrehozni. Ha az adott tartomány kiszolgálására beállított szerver észleli ezeket a kéréseket, akkor válaszol az ypbind démonnak, amely pedig feljegyzi a szerver címét. Ha több szerver is elérhetõ (például egy központi és több alárendelt), akkor az ypbind az elsõként válaszoló címét fogja rögzíteni. Innentõl kezdve a kliens közvetlenül ennek a szervernek fogja küldeni a NIS kéréseit. Az ypbind idõnként megpingeli a szervert, hogy meggyõzõdjön az elérhetõségérõl. Ha az ypbind egy adott idõn belül nem kap választ a ping kéréseire, akkor megszünteti a kötést a tartományhoz és nekilát keresni egy másik szervert. A NIS kliensek beállítása NIS a kliensek beállítása Egy &os;-s gépet NIS kliensként meglehetõsen egyszerûen lehet beállítani. Nyissuk meg az /etc/rc.conf állományt és a NIS tartománynév beállításához, valamint az ypbind elindításához a következõket írjuk bele: nisdomainname="proba-tartomany" nis_client_enable="YES" A NIS szerveren található jelszavak importálásához távolítsuk el az összes felhasználói hozzáférést az /etc/master.passwd állományunkból és a vipw segítségével adjuk hozzá az alábbi sort az állomány végéhez: +::::::::: Ez a sor beenged bárkit a rendszerünkre, akinek a NIS szervereken van érvényes hozzáférése. A NIS klienseket ezzel a sorral sokféle módon tudjuk állítani. A hálózati csoportokról szóló szakaszban találunk majd errõl több információt. A téma mélyebb megismeréséhez az O'Reilly Managing NFS and NIS címû könyvét ajánljuk. Legalább helyi hozzáférést (vagyis amit nem NIS-en keresztül importálunk) azonban mindenképpen hagyjunk meg az /etc/master.passwd állományunkban, és ez a hozzáférés legyen a wheel csoport tagja. Ha valami gond lenne a NIS használatával, akkor ezen a hozzáférésen keresztül tudunk a gépre távolról bejelentkezni, majd innen root felhasználóra váltva megoldani a felmerült problémákat. A NIS szerverrõl az összes lehetséges csoport-bejegyzést az /etc/group állományban így tudjuk importálni: +:*:: Miután elvégeztük ezeket a lépéseket, képesek leszünk futtatni az ypcat passwd parancsot, és látni a NIS szerver jelszavakat tartalmazó táblázatát. A NIS biztonsága Általában tetszõleges távoli felhasználó küldhet RPC kéréseket az &man.ypserv.8; számára és kérheti le a NIS táblázatok tartalmát, feltéve, hogy ismeri a tartomány nevét. Az ilyen hitelesítés nélküli mûveletek ellen az &man.ypserv.8; úgy védekezik, hogy tartalmaz egy securenets nevû lehetõséget, amellyel az elérhetõségüket tudjuk leszûkíteni gépek egy csoportjára. Az &man.ypserv.8; indításakor ezeket az információkat a /var/yp/securenets állományból próbálja meg betölteni. Az elérési útvonala megadható a opció használatával. Ez az állomány olyan bejegyzéseket tartalmaz, amelyekben egy hálózati cím és tõle láthatatlan karakterekkel elválasztva egy hálózati maszk szerepel. A # karakterrel kezdõdõ sorokat megjegyzésnek nyilvánítjuk. Egy minta securenets állomány valahogy így nézne ki: # Engedélyezzük önmagunkról a csatlakozást -- kell! 127.0.0.1 255.255.255.255 # Engedélyezzük a 192.168.128.0 hálózatról érkezõ csatlakozásokat: 192.168.128.0 255.255.255.0 # Engedélyezzük a laborban található 10.0.0.0 és 10.0.15.255 közti # címekkel rendelkezõ gépek csatlakozását: 10.0.0.0 255.255.240.0 Ha az &man.ypserv.8; olyan címrõl kap kérést, amely illeszkedik az elõírt címek valamelyikére, akkor a szokásos módon feldolgozza azt. Ellenkezõ esetben a kérést figyelmen kívül hagyja és egy figyelmeztetést vesz fel hozzá a naplóba. Ha a /var/yp/securenets állomány nem létezik, akkor az ypserv tetszõleges géprõl engedélyezi a csatlakozást. Az ypserv lehetõséget ad a Wietse Venema által fejlesztett TCP Wrapper csomag használatára is. Ezzel a rendszergazda a /var/yp/securenets állomány helyett a TCP Wrapper konfigurációs állományai alapján képes szabályozni az elérhetõséget. Miközben mind a két módszer nyújt valamilyen fajta védelmet, de a privilegizált portok teszteléséhez hasonlóan az IP álcázásával (IP spoofing) sebezhetõek. Ezért az összes NIS-hez tartozó forgalmat tûzfallal kell blokkolnunk. Az /var/yp/securenets állományt használó szerverek nem képesek az elavult TCP/IP implementációkat használó érvényes klienseket rendesen kiszolgálni. Egyes ilyen implementációk a címben a géphez tartozó biteket nullára állítják az üzenetszóráshoz, és/vagy ezért az üzenetszóráshoz használt cím kiszámításakor nem tudja észleli a hálózati maszkot. A legtöbb ilyen probléma megoldható a kliens konfigurációjának megváltoztatásával, míg más problémák megoldása a kérdéses kliensek nyugdíjazását kívánják meg, vagy a /var/yp/securenets használatának elhagyását. Egy régebbi TCP/IP implementációval üzemelõ szerveren pedig a /var/yp/securenets állomány használata kifejezetten rossz ötlet, és a hálózatunk nagy részében képes használhatatlanná tenni a NIS funkcióit. TCP wrapperek A TCP Wrapper csomag alkalmazása a NIS szerverünk válaszadáshoz szükséges idejét is segít csökkenteni. Az ilyenkor jelentkezõ plusz késlekedés mellesleg elég nagy lehet ahhoz, hogy a klienseknél idõtúllépés következzen be, különösen a terheltebb hálózatokon vagy a lassú NIS szerverek esetében. Ha egy vagy több kliensünk is ilyen tüneteket mutat, akkor érdemes a kérdéses kliens rendszereket alárendelt NIS szerverekké alakítani és önmagukhoz rendelni. Egyes felhasználók bejelentkezésének megakadályozása A laborunkban van egy basie nevû gép, amely a tanszék egyetlen munkaállomása. Ezt a gépet nem akarjuk kivenni a NIS tartományból, de a központi NIS szerver passwd állománya mégis egyaránt tartalmazza a hallgatók és az oktatók eléréseit. Mit lehet ilyenkor tenni? Adott felhasználók esetében le tudjuk tiltani a bejelentkezést a gépen még olyankor is, ha léteznek a NIS adatbázisában. Ehhez mindössze a kliensen az /etc/master.passwd állomány végére be kell tennünk egy -felhasználónév sort, ahol a felhasználónév annak a felhasználónak a neve, akit nem akarunk beengedni a gépre. Ezt leginkább a vipw használatán keresztül érdemes megtennünk, mivel a vipw az /etc/master.passwd állomány alapján végez némi ellenõrzést, valamint a szerkesztés befejeztével magától újragenerálja a jelszavakat tároló adatbázist. Például, ha a bill nevû felhasználót ki akarjuk tiltani a basie nevû géprõl, akkor: basie&prompt.root; vipw [vegyük fel a -bill sort a végére, majd lépjünk ki] vipw: rebuilding the database... vipw: done basie&prompt.root; cat /etc/master.passwd root:[jelszó]:0:0::0:0:The super-user:/root:/bin/csh toor:[jelszó]:0:0::0:0:The other super-user:/root:/bin/sh daemon:*:1:1::0:0:Owner of many system processes:/root:/sbin/nologin operator:*:2:5::0:0:System &:/:/sbin/nologin bin:*:3:7::0:0:Binaries Commands and Source,,,:/:/sbin/nologin tty:*:4:65533::0:0:Tty Sandbox:/:/sbin/nologin kmem:*:5:65533::0:0:KMem Sandbox:/:/sbin/nologin games:*:7:13::0:0:Games pseudo-user:/usr/games:/sbin/nologin news:*:8:8::0:0:News Subsystem:/:/sbin/nologin man:*:9:9::0:0:Mister Man Pages:/usr/share/man:/sbin/nologin bind:*:53:53::0:0:Bind Sandbox:/:/sbin/nologin uucp:*:66:66::0:0:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico xten:*:67:67::0:0:X-10 daemon:/usr/local/xten:/sbin/nologin pop:*:68:6::0:0:Post Office Owner:/nonexistent:/sbin/nologin nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/sbin/nologin +::::::::: -bill basie&prompt.root; Udo Erdelhoff Készítette: A hálózati csoportok alkalmazása hálózati csoportok Az elõzõ szakaszban ismertetett módszer viszonylag jól mûködik olyan esetekben, amikor nagyon kevés felhasználóra és/vagy számítógépre kell alkalmaznunk speciális megszorításokat. A nagyobb hálózatokban szinte biztos, hogy elfelejtünk kizárni egyes felhasználókat az érzékeny gépekrõl, vagy az összes gépen egyenként kell ehhez a megfelelõ beállításokat elvégezni, és ezzel lényegében elvesztjük a NIS legfontosabb elõnyét, vagyis a központosított karbantarthatóságot. A NIS fejlesztõi erre a problémára a hálózati csoportokat létrehozásával válaszoltak. A céljuk és mûködésük szempontjából leginkább a &unix;-os állományrendszerekben található csoportokhoz mérhetõek. A legnagyobb eltérés a numerikus azonosítók hiányában mutatkozik meg, valamint a hálózati csoportokat a felhasználókon kívül további hálózati csoportok megadásával is ki lehet alakítani. A hálózati csoportok a nagyobb, bonyolultabb, többszáz felhasználós hálózatok számára jöttek létre. Egy részrõl ez nagyon jó dolog, különösen akkor, ha egy ilyen helyzettel kell szembenéznünk. Másrészrõl ez a mértékû bonyolultság szinte teljesen lehetetlenné teszi a hálózati csoportok egyszerû bemutatását. A szakasz további részében használt példa is ezt a problémát igyekszik illusztrálni. Tételezzük fel, hogy laborunkban a NIS sikeres bevezetése felkeltette a fõnökeink figyelmét. Így a következõ feladatunk az lett, hogy terjesszük ki a NIS tartományt az egyetemen található néhány másik gépre is. Az alábbi két táblázatban az új felhasználók és az új számítógép neveit találjuk, valamint a rövid leírásukat. Felhasználók nevei Leírás alpha, beta az IT tanszék hétköznapi dolgozói charlie, delta az IT tanszék újdonsült dolgozói echo, foxtrott, golf, ... átlagos dolgozók able, baker, ... ösztöndíjasok Gépek nevei Leírás haboru, halal, ehseg, szennyezes A legfontosabb szervereink. Csak az IT tanszék dolgozói férhetnek hozzájuk. buszkeseg, kapzsisag, irigyseg, harag, bujasag, lustasag Kevésbé fontos szerverek. Az IT tankszék összes tagja el tudja érni ezeket a gépeket. egy, ketto, harom, negy, ... Átlagos munkaállomások. Egyedül csak a valódi dolgozók jelentkezhetnek be ezekre a gépekre. szemetes Egy nagyon régi gép, semmi értékes adat nincs rajta. Akár még az öszöndíjasok is nyúzhatják. Ha ezeket az igényeket úgy próbáljuk meg teljesíteni, hogy a felhasználókat egyenként blokkoljuk, akkor minden rendszer passwd állományába külön fel kell vennünk a -felhasználó sorokat a letiltott felhasználókhoz. Ha csak egyetlen bejegyzést is kihagyunk, akkor könnyen bajunk származhat belõle. Ez a rendszer kezdeti beállítása során még talán nem okoz gondot, de az új felhasználókat biztosan el fogjuk felejteni felvenni a megfelelõ csoportokba. Elvégre Murphy is optimista volt. A hálózati csoportok használata ilyen helyzetekben számos elõnyt rejt. Nem kell az egyes felhasználókat külön felvenni, egy felhasználót felveszünk valamelyik csoportba vagy csoportokba, és a csoportok összes tagjának egyszerre tudjuk tiltani vagy engedélyezni a hozzáféréseket. Ha hozzáadunk egy új gépet a hálózatunkhoz, akkor mindössze a hálózati csoportok bejelentkezési korlátozásait kell beállítani. Ha új felhasználót veszünk fel, akkor a felhasználót kell vennünk egy vagy több hálózati csoportba. Ezek a változtatások függetlenek egymástól, és nincs szükség minden felhasználó és minden gép összes kombinációjára. Ha a NIS beállításainkat elõzetesen körültekintõen megterveztük, akkor egyetlen központi konfigurációs állományt kell módosítani a gépek elérésének engedélyezéséhez vagy tiltásához. Az elsõ lépés a hálózati csoportokat tartalmazó NIS táblázat inicializálása. A &os; &man.ypinit.8; programja alapértelmezés szerint nem hozza létre ezt a táblázatot, de ha készítünk egy ilyet, akkor a NIS implementációja képes kezelni. Egy ilyen üres táblázat elkészítéséhez ennyit kell begépelni: ellington&prompt.root; vi /var/yp/netgroup Ezután elkezdhetjük felvenni a tartalmát. A példánk szerint legalább négy hálózati csoportot kell csinálnunk: az IT dolgozóinak, az IT új dolgozóinak, a normál dolgozóknak és az öszöndíjasoknak. IT_DOLG (,alpha,proba-tartomany) (,beta,proba-tartomany) IT_UJDOLG (,charlie,proba-tartomany) (,delta,proba-tartomany) FELHASZNALO (,echo,proba-tartomany) (,foxtrott,proba-tartomany) \ (,golf,proba-tartomany) OSZTONDIJAS (,able,proba-tartomany) (,baker,proba-tartomany) Az IT_DOLG, IT_UJDOLG stb. a hálózati csoportok nevei lesznek. Minden egyes zárójelezett csoport egy vagy több felhasználói hozzáférést tartalmaz. A csoportokban szereplõ három mezõ a következõ: Azon gépek neve, amelykre a következõ elemek érvényesek. Ha itt nem adunk meg neveket, akkor a bejegyzés az összes gépre vonatkozik. Ha megadjuk egy gép nevét, akkor jutalmunk a teljes sötétség, a rettegetés és totális megtébolyodás. A csoporthoz tartozó hozzáférés neve. A hozzáféréshez kapcsolódó NIS tartomány. A csoportba más NIS tartományokból is át tudunk hozni hozzáféréseket, ha netalán éppen olyan szerencsétlenek lennénk, hogy több NIS tartományt is felügyelnünk kell. A mezõk mindegyike tartalmazhat dzsókerkaraktereket. Errõl részletesebben a &man.netgroup.5; man oldalon olvashatunk. hálózati csoportok A hálózati csoportoknak lehetõleg ne adjunk 8 karakternél hosszabb nevet, különösen abban az esetben, ha a NIS tartományban más operációs rendszereket is használunk. A nevekben eltérnek a kis- és nagybetûk. Ha a hálózati csoportokat nevét nagybetûkkel írjuk, akkor könnyen különbséget tudunk tenni a felhasználók, gépek és hálózati csoportok nevei között. Egyes (nem &os; alapú) NIS kliensek nem képesek kezelni a nagyon sok bejegyzést tartalmazó hálózati csoportokat. Például a &sunos; néhány korábbi verziója fennakad rajta, ha egy hálózati csoport 15 bejegyzésnél többet tartalmaz. Az ilyen korlátozások alól úgy tudunk kibújni, ha 15 felhasználónként újabb hálózati csoportokat hozunk létre, amelyekkel az eredeti hálózati csoportot építjük fel: NAGYCSP1 (,joe1,tartomany) (,joe2,tartomany) (,joe3,tartomany) [...] NAGYCSP2 (,joe16,tartomany) (,joe17,tartomany) [...] NAGYCSP3 (,joe31,tartomany) (,joe32,tartomany) NAGYCSOPORT NAGYCSP1 NAGYCSP2 NAGYCSP3 Ugyanez a folyamat javasolt olyan esetekben is, ahol 225 felhasználónál többre lenne szükség egyetlen hálózati csoporton belül. Az így létrehozott új NIS táblázat szétküldése meglehetõsen könnyû feladat: ellington&prompt.root; cd /var/yp ellington&prompt.root; make Ez a parancs létrehoz három NIS táblázatot: netgroup, netgroup.byhost és netgroup.byuser. Az &man.ypcat.1; paranccsal ellenõrizni is tudjuk az új NIS táblázatainkat: ellington&prompt.user; ypcat -k netgroup ellington&prompt.user; ypcat -k netgroup.byhost ellington&prompt.user; ypcat -k netgroup.byuser Az elsõ parancs kimenete a /var/yp/netgroup állomány tartalmára emlékeztethet minket. A második parancsnak nincs semmilyen kimenete, hacsak nem adtunk meg valamilyen gépfüggõ hálózati csoportot. A harmadik parancs a hálózati csoportokat listázza ki a felhasználókhoz. A kliensek beállítása tehát nagyon egyszerû. A haboru nevû szerver beállításához indítsuk el a &man.vipw.8; programot, és cseréljük a +::::::::: sort erre: +@IT_DOLG::::::::: Innentõl kezdve kizárólag csak az IT_DOLG csoportban található felhasználók fognak bekerülni a haboru jelszó adatbázisába, és csak ezek a felhasználók tudnak ide bejelentkezni. Sajnos ez a korlátozás a parancsértelmezõ ~ funkciójára és összes olyan rutinra is vonatkozik, amelyet a felhasználói nevek és azok numerikus azonosító között képez le. Más szóval a cd ~felhasználó parancs nem fog mûködni, és az ls -l parancs kimenetében a felhasználói nevek helyett csak numerikus azonosítók jelennek meg, továbbá afind . -user joe -print No such user (Nincs ilyen felhasználó) hibát fog visszaadni. Ez úgy tudjuk megjavítani, ha úgy importáljuk a szerverre az összes felhasználó bejegyzését, hogy közben tiltjuk a hozzáférésüket. Ehhez vegyünk fel egy újabb sort az /etc/master.passwd állományba. A sor valahogy így fog kinézni: +:::::::::/sbin/nologin, amely annyit tesz, hogy importáljuk az összes bejegyzést, de a hozzájuk tartozó parancsértelmezõ a /sbin/nologin legyen. A passwd állományban tetszõleges mezõ tartalmát le tudjuk úgy cserélni, ha megadunk neki egy alapértelmezett értéket az /etc/master.passwd állományban. Vigyázzunk, hogy a +:::::::::/sbin/nologin sort az +@IT_DOLG::::::::: sor után írjuk. Ha nem így teszünk, akkor a NIS-bõl importált összes felhasználói hozzáférés a /sbin/nologin parancsértelmezõt kapja. Miután elvégeztük ezt a változtatást, minden újabb dolgozó felvétele után csupán egyetlen táblázatot kell megváltoztatnunk. Ugyanezt a taktikát követhetjük a kevésbé fontosabb szerverek esetében is, hogy ha a helyi /etc/master.passwd állományukban a korábbi +::::::::: bejegyzést valami ilyesmivel helyettesítjük: +@IT_DOLG::::::::: +@IT_UJDOLG::::::::: +:::::::::/sbin/nologin Az egyszerû munkaállomások esetében pedig ezekre a sorokra lesz szükségünk: +@IT_DOLG::::::::: +@FELHASZNALOK::::::::: +:::::::::/sbin/nologin Minden remekül üzemel egészen addig, amíg néhány múlva ismét változik a házirend: az IT tanszékre ösztöndíjasok érkeznek. Az IT ösztöndíjasai a munkaállomásokat és a kevésbé fontosabb szervereket tudják használni. Az új IT dolgozók már a központi szerverekre is bejelentkezhetnek. Így tehát létrehozunk egy új hálózati csoportot IT_OSZTONDIJAS néven, majd felvesszük ide az új IT ösztöndíjasokat, és nekilátunk végigzongorázni az összes gép összes konfigurációs állományát... Ahogy azonban egy régi mondás is tartja: A központosított tervezésben ejtett hibák teljes káoszhoz vezetnek. A NIS az ilyen helyzeteket úgy igyekszik elkerülni, hogy megengedi újabb hálózati csoportok létrehozását más hálózati csoportokból. Egyik ilyen lehetõség a szerep alapú hálózati csoportok kialakítása. Például, ha a fontosabb szerverek bejelentkezési korlátozásai számára hozzunk létre egy NAGYSRV nevû csoportot, valamint egy másik hálózati csoportot KISSRV néven a kevésbé fontosabb szerverekhez, végül MUNKA néven egy harmadik hálózati csoportot a munkaállomásokhoz. Mindegyik ilyen hálózati csoport tartalmazza azokat a csoportokat, amelyek engedélyezik a gépek elérését. A hálózati csoportok leírását tartalmazó NIS táblázat most valahogy így fog kinézni: NAGYSRV IT_DOLG IT_UJDOLG KISSRV IT_DOLG IT_UJDOLG IT_OSZTONDIJAS MUNKA IT_DOLG IT_OSZTONDIJAS FELHASZNALOK A bejelentkezési megszorítások ilyen típusú megadása viszonylag jól mûködik, hogy ha azonos korlátozások alá esõ gépek csoportjait akarjuk felírni. Bánatunk ez a kivétel, és nem a szabály. Az esetek nagy többségében ugyanis a bejelentkezésre vonatkozó korlátozásokat gépenként kell egyesével megadni. A hálózati csoportok gépfüggõ megadása tehát az iménti házirendhez társuló igények kielégítésének egyik módja. Ebben a forgatókönyvben az /etc/master.passwd állomány minden számítógépen két +-os sorral kezdõdik. Közülük az elsõ a gépen engedélyezett hozzáféréseket tartalmazó hálózati csoportra vonatkozik, a második pedig az összes többi hozzáféréshez az /sbin/nologin parancsértelmezõt kapcsolja hozzá. Itt jó ötlet, ha a gép nevének VÉGIG-NAGYBETÛS változatát adjuk meg a hozzátartozó hálózati csoport nevének: +@GÉPNÉV::::::::: +:::::::::/sbin/nologin Miután elvégeztük ezt a feladatot minden egyes gépen, az /etc/master.passwd állomány helyi változatait soha többé nem kell módosítanunk. Az összes többi változtatást a NIS táblázaton keresztül tudjuk keresztül vinni. Íme a felvázolt forgatókönyvhöz tartozó hálózati csoportok kiépítésének egyik lehetséges változata, egy-két finomsággal kiegészítve: # Elõször a felhasználók csoportjait adjuk meg: IT_DOLG (,alpha,proba-tartomany) (,beta,proba-tartomany) IT_UJDOLG (,charlie,proba-tartomany) (,delta,proba-tartomany) TANSZ1 (,echo,proba-tartomany) (,foxtrott,proba-tartomany) TANSZ2 (,golf,proba-taromany) (,hotel,proba-tartomany) TANSZ3 (,india,proba-taromany) (,juliet,proba-tartomany) IT_OSZTONDIJAS (,kilo,proba-tartomany) (,lima,proba-tartomany) D_OSZTONDIJAS (,able,proba-tartomany) (,baker,proba-tartomany) # # Most pedig hozzunk létre csoportokat szerepek szerint: FELHASZNALOK TANSZ1 TANSZ2 TANSZ3 NAGYSRV IT_DOLG IT_UJDOLG KISSRV IT_DOLG IT_UJDOLG IT_OSZTONDIJAS MUNKA IT_DOLG IT_OSZTONDIJAS FELHASZNALOK # # Következzenek a speciális feladatokhoz tartozó csoportok: # Az echo és a golf tudja elérni a vírusvédelemért felelõs gépet: VEDELEM IT_DOLG (,echo,proba-tartomany) (,golf,proba-tartomany) # # Gép alapú hálózati csoportok # A fõ szervereink: HABORU NAGYSRV EHSEG NAGYSRV # Az india nevû felhasználó hozzá szeretné ehhez férni: SZENNYEZES NAGYSRV (,india,proba-tartomany) # # Ez valóban fontos és komolyan szabályoznunk kell: HALAL IT_DOLG # # Az elõbb említett vírusvédelmi gép: EGY VEDELEM # # Egyetlen felhasználóra korlátozzuk le ezt a gépet: KETTO (,hotel,proba-tartomany) # [...és itt folytatódik a többi csoporttal] Ha a felhasználói hozzáféréseinket valamilyen adatbázisban tároljuk, akkor a táblázat elsõ részét akár az adatbázis lekérdezésein keresztül is elõ tudjuk állítani. Ezzel a módszerrel az új felhasználók automatikusan hozzáférnek a gépekhez. Legyünk viszont óvatosak: nem mindig javasolt gépeken alapuló hálózati csoportokat készíteni. Ha a hallgatói laborokba egyszerre több tucat vagy akár több száz azonos konfigurációjú gépet telepítünk, akkor a gép alapú csoportok helyett inkább szerep alapú csoportokat építsünk fel, mivel így a NIS táblázatok méretét egy elfogadható méreten tudjuk tartani. Amit feltétlenül észben kell tartanunk Még mindig akad néhány olyan dolog, amit másképpen kell csinálnunk azután, hogy most már NIS környezetben vagyunk. Amikor egy új felhasználót akarunk felvenni a laborba, akkor csak a központi NIS szerverre kell felvennünk, és újra kell generáltatnunk a NIS táblázatokat. Ha ezt elfelejtjük megtenni, akkor az új felhasználó a központi NIS szerveren kívül sehova sem lesz képes bejelentkezni. Például, ha fel akarjuk venni a jsmith nevû felhasználót a laborba, akkor ezt kell tennünk: &prompt.root; pw useradd jsmith &prompt.root; cd /var/yp &prompt.root; make proba-tartomany Vagy a pw useradd jsmith parancs helyett az adduser jsmith parancsot is használhatjuk. A rendszergazdai szintû hozzáféréseket ne tároljuk a NIS táblázatokban. Olyan gépekre egyáltalán ne is küldjünk olyan karbantartáshoz használt hozzáféréseket, amelynek a felhasználói hivatalosan nem is férhetnének hozzájuk. A központi NIS szervert és az alárendelt szervereket óvjuk minél jobban, és igyekezzünk minimalizálni a kieséseiket. Ha valaki feltöri vagy egyszerûen csak kikapcsolja ezeket a gépeket, akkor ezzel lényegében mindenkit megakadályoz abban, hogy be tudjon jelentkezni a laborban. Ezek a központosított vezérlésû rendszerek legfõbb gyengeségei. Ha nem védjük kellõen a NIS szervereinket, akkor azzal nagyon ellenséget szerezhetünk magunknak! Kompatibilitás a NIS elsõ változatával A &os;-ben megtalálható ypserv szolgáltatás valamennyire képes ellátni a NIS elsõ változatát használó klienseket is. A &os; NIS implementációja csak a NIS v2 protokollt használja, azonban mivel más implementációk kompatibilisek kívánnak maradni a régebbi rendszerekkel, ismerik a v1 protokollt is. Az ilyen rendszerekhez tartozó ypbind démonok még olyankor is megpróbálnak v1-es NIS szerverekhez kötést létrehozni, amikor valójában nincs is rá szükségük (és gyakran még akkor is ilyet keresnek, amikor az üzenetükre már válaszolt egy v2-es szerver). Hozzátennénk, hogy bár az ypserver ezen változata a normál klienshívásokat képes feldolgozni, a táblázatokat már nem tudja átküldeni a v1-es klienseknek. Ebbõl következik, hogy a központi vagy alárendelt szerverek nem tudnak együttmûködni olyan NIS szerverekkel, amelyek csak a v1-es protokollt beszélik. Szerencsére ilyen szervereket manapság már alig használnak. NIS szerverek, melyek egyben NIS kliensek Óvatosan kell bánnunk az ypserv elindításával olyan többszerveres tartományokban, ahol a szerverek maguk is NIS kliensek. Alapvetõen nincs abban semmi kivetnivaló, ha a szervereket saját magukhoz kötjük ahelyett, hogy engednénk nekik a kötési kérések küldését és így egymáshoz kötnénk ezeket. Különös hibák tudnak származni olyan helyzetekben, amikor az egyik szerver leáll, miközben a többiek pedig függenek tõle. Végül is ilyenkor minden kliens szépen kivárja a szükséges idõt, aztán megpróbál más szerverekhez kötõdni, de az itt fellépõ késlekedés jelentõs mennyiségû lehet, és ez a hibajelenség ismét fennállhat, mivel elõfordulhat, hogy a szerverek megint egymáshoz kapcsolódnak. A klienst úgy tudjuk egy adott szerverhez kötni, ha az ypbind parancsot a beállítással indítjuk. Ha mindezt nem akarjuk manuálisan megtenni a NIS szerver minden egyes újraindításakor, akkor vegyük fel a következõ sorokat az /etc/rc.conf állományba: nis_client_enable="YES" # elindítjuk a klienst is nis_client_flags="-S NIS tartomány,szerver" Részletesebb lásd az &man.ypbind.8; man oldalát. A jelszavak formátuma NIS jelszavak formátuma A NIS rendszerek kiépítése során az emberek leggyakrabban a jelszavak formátumával kapcsolatban tapasztalnak nehézségeket. Ha a szerverünk DES titkosítású jelszavakat használ, akkor csak olyan klienseket fog tudni támogatni, amelyek szintén így kódolják ezeket. Például, ha a hálózaton vannak &solaris; rendszerû NIS klienseink, akkor szinte biztos, hogy DES titkosítást kell használnunk. A szerverek és a kliensek által használt formátumokat az /etc/login.conf állományba tekintve deríthetjük ki. Ha a gépek többségén a DES titkosítást látjuk, akkor a default osztálynak egy ilyen bejegyzést kell tartalmaznia: default:\ :passwd_format=des:\ :copyright=/etc/COPYRIGHT:\ [a többit most nem mutatjuk] A passwd_format tulajdonság további lehetséges értékei lehetnek a blf és az md5 (melyek rendre a Blowfish és MD5 titkosítású jelszavakat adják meg). Ha változtattunk valamit az /etc/login.conf állományban, akkor a bejelentkezési tulajdonságok adatbázisát is újra kell generálni, melyet root felhasználóként a következõ módon tehetünk meg: &prompt.root; cap_mkdb /etc/login.conf Az /etc/master.passwd állományban jelenlevõ jelszavak formátuma azonban nem frissítõdik egészen addig, amíg a felhasználók a bejelentkezési adatbázis újragenerálása után meg nem változtatják a jelszavaikat. Úgy tudjuk még biztosítani, hogy a jelszavak megfelelõ formátumban kódolódjanak, ha az /etc/auth.conf állományban megkeressük a crypt_default sort, amelyben a választható jelszóformátumok felhasználásái sorrendjét találhatjuk meg. Itt tehát mindössze annyit kell tennünk, hogy a kiszemelt formátumot a lista elejére tesszük. Például, ha a DES titkosítású jelszavakat akarunk használni, akkor ez a bejegyzés így fog kinézni: crypt_default = des blf md5 Ha a fenti lépéseket követjük az összes &os; alapú NIS szervernél és kliensnél, akkor biztosra mehetünk abban, hogy a hálózatunkon belül ugyanazt a jelszóformátumot fogják használni. Ha gondunk akadna a NIS kliensek hitelesítésével, akkor itt érdemes kezdeni a hiba felderítését. Ne felejtsük: ha egy NIS szervert egy heterogén hálózatba akarunk telepíteni, akkor valószínûleg az összes rendszeren a DES titkosítást kell választani, mivel általában ez a közös nevezõ ebben a tekintetben. Greg Sutter Írta: A hálózat automatikus beállítása (DHCP) Mi az a DHCP? Dinamikus állomáskonfigurációs protokoll DHCP internetes szoftverkonzorcium (ISC) A Dinamikus állomáskonfigurációs protokoll, avagy Dynamic Host Configuration Protocol (DHCP) annak eszközeit írja le, hogy egy rendszer miként tud csatlakozni egy hálózathoz és miként tudja azon belül megszerezni a kommunikációhoz szükséges információkat. A &os; 6.0 elõtti változatai az ISC (Internet Software Consortium, vagyis az internetes szoftverkonzorcium) által kidolgozott DHCP kliens (&man.dhclient.8;) implementációját tartalmazzák. A késõbbi verziókban pedig az OpenBSD 3.7 verziójából átvett dhclient paranccsal dolgozhatunk. Ebben a szakaszban a dhclient parancsra vonatkozó összes információ egyaránt érvényes az ISC és az OpenBSD által fejlesztett DHCP kliensekre. A DHCP szerver az ISC-tõl származik. Mivel foglalkozik ez a szakasz Ebben a szakaszban az ISC és az OpenBSD DHCP klienseinek kliens- és szerver oldali komponsenseit mutatjuk be. A kliens oldali program neve a dhclient, amely a &os; részeként érkezik, és a szerver oldali elem pedig a net/isc-dhcp3-server porton keresztül érhetõ el. A lentebb említett hivatkozások mellett a témában még a &man.dhclient.8;, &man.dhcp-options.5; és a &man.dhclient.conf.5; man adhatnak bõvebb felvilágosítást a témában. Ahogyan mûködik UDP Amikor a dhclient, vagyis a DHCP kliens elindul egy kliensgépen, akkor a hálózaton üzenetszórással próbálja meg elkérni a konfigurációjához szükséges adatokat. Alapértelmezés szerint ezek a kérések a 68-as UDP porton keresztül mennek. A szerver ezekre a 67-es UDP porton válaszol, ahol visszaad a kliensnek egy IP-címet és a hálózat használatához szükséges további információkat, mint például a hálózati maszkot, az alapértelmezett átjáró és a névfeloldásért felelõs szerverek címét. Az összes ilyen jellegû adat egy DHCP bérlet (lease) formájában érkezik meg, amely csak egy adott ideig érvényes (ezt a DHCP szerver karbantartója állítja be). Így a hálózaton a kliens nélküli IP-címeket egy idõ után automatikusan visszanyerjük. A DHCP kliensek rengeteg információt képes elkérni a szervertõl. Ezek teljes listáját a &man.dhcp-options.5; man oldalán olvashatjuk el. Használat a &os;-n belül A &os; teljes egészében tartalmazza az ISC vagy az OpenBSD DHCP kliensét, a dhclient programot (attól függõen, hogy a &os; melyik változatát használjuk). A DHCP kliensek támogatása a telepítõben és az alaprendszerben is megtalálható, és ezzel mentesülünk minden konkrét hálózati beállítás alól a DHCP szervereket alkalmazó hálózatokon. A dhclient a &os; 3.2 változata óta megtalálható a rendszerben. sysinstall DHCP használatát a sysinstall is lehetõvé teszi. Amikor egy hálózati felületet a sysinstall programon belül állítunk be, akkor a második kérdés mindig ez szokott lenni: Do you want to try DHCP configuration of the interface? (Megpróbáljuk DHCP használatával beállítani a felületet?) Ha erre igennel válaszolunk, akkor azzal lényegében a dhclient parancsot indítjuk el, és ha mindez sikerrel zárul, akkor szinte magától kitöltõdik az összes hálózati beállításunk. A DHCP használatához két dolgot kell beállítanunk a rendszerünkön: DHCP követelmények Gondoskodjunk róla, hogy a bpf eszköz része a rendszermagunknak. Ha még nem lenne benne, akkor a rendszermag beállításait tartalmazó állományba vegyük fel a device bpf sort és fordítsuk újra a rendszermagot. A rendszermagok fordításáról a ben tudhatunk meg többet. A bpf eszköz alapból megtalálható a GENERIC rendszermagokban, így ha ezt használjuk, akkor nem kell saját verziót készítenünk a DHCP használatához. Azok számára viszont, akik biztonsági szempontból aggódnak a rendszerük miatt, meg kell említenünk, hogy a bpf egyben az az eszköz, amely a csomagok lehallgatását is lehetõvé teszi (habár az ilyeneket root felhasználóként lehet csak elindítani). A bpf kell a DHCP használatához, azonban ha nagyon fontos nekünk a rendszerünk biztonsága, akkor a bpf eszközt érdemes kivennünk a rendszermagból, ha még pillanatnyilag nem használunk ilyet. Az /etc/rc.conf állományunkat az alábbiak szerint kell módosítani: ifconfig_fxp0="DHCP" Az fxp0 eszközt ne felejtsük el kicserélni arra a felületre, amelyet automatikusan akarunk beállítani. Ennek mikéntje a ban olvasható. Ha a dhclient a rendszerünkben máshol található, vagy egyszerûen csak további beállításokat akarunk átadni a dhclient parancsnak, akkor adjuk meg a következõt is (változtassuk meg igényeink szerint): dhcp_program="/sbin/dhclient" dhcp_flags="" DHCP szerver A DHCP szerver, a dhcpd a net/isc-dhcp3-server port részeként érhetõ el. Az a port tartalmazza az ISC DHCP szerverét és a hozzátartozó dokumentációt. Állományok DHCP konfigurációs állományok /etc/dhclient.conf A dhclient mûködéséhez szükség lesz egy konfigurációs állományra, aminek a neve /etc/dhclient.conf. Ez az állomány általában csak megjegyzéseket tartalmaz, mivel az alapértelmezett értékek többnyire megfelelõek. Ezt a konfigurációs állományt a &man.dhclient.conf.5; man oldal írja le. /sbin/dhclient A dhclient statikusan linkelt és az /sbin könyvtárban található. A &man.dhclient.8; man oldal tud róla részletesebb felvilágosítást adni. /sbin/dhclient-script A dhclient-script a &os;-ben levõ DHCP kliens konfigurációs szkriptje. Mûködését a &man.dhclient-script.8; man oldal írja le, de a felhasználók részérõl semmilyen módosítást nem igényel. /var/db/dhclient.leases A DHCP kliens az érvényes bérleteket tartja nyilván ezekben az állományban és naplóként használja. A &man.dhclient.leases.5; man oldal ezt valamivel bõvebben kifejti. További olvasnivalók A DHCP protokoll mûködését az RFC 2131 mutatja be. A témához kapcsolódóan itt tudunk még leírásokat találni. A DHCP szerverek telepítése és beállítása Mirõl szól ez a szakasz Ebben a szakaszban arról olvashatunk, hogy miként kell egy &os; típusú rendszert DHCP szervernek beállítani, ha az ISC (internetes szoftverkonzorcium) DHCP szerverét használjuk. Ez a szerver nem része a &os;-nek, ezért a szolgáltatás elindításához elõször fel kell raknunk a net/isc-dhcp3-server portot. A Portgyûjtemény használatára vonatkozóan a lehet segítségünkre. A DHCP szerver telepítése DHCP telepítés Ha a &os; rendszerünket DHCP szerverként akarjuk beállítani, akkor ehhez elsõként a &man.bpf.4; eszköz jelenlétét kell biztosítani a rendszermagban. Ehhez vegyük fel a device bpf sort a rendszermagunk beállításait tartalmazó állományba, majd fordítsuk újra a rendszermagot. A rendszermag lefordításáról a ben olvashatunk. A bpf eszköz a &os;-hez alapból adott GENERIC rendszermag része, ezért a DHCP használatához nem kell feltétlenül újat fordítanunk. A biztonsági szempontok miatt aggódó felhasználók részére megjegyezzük, hogy a bpf eszköz egyben a csomagok lehallgatását is lehetõvé teszi (habár az ilyen témájú programok futtatásához megfelelõ jogokra is szükség van). A bpf használata kötelezõ a DHCP mûködtetéséhez, de ha nagyon kényesek vagyunk a biztonságot illetõen, akkor minden olyan esetben, amikor nem használjuk ki ezt a lehetõséget, távolítsuk el a rendszermagból. A következõ lépésben át kell szerkesztenünk a mintaként mellékelt dhcpd.conf állományt, amelyet a net/isc-dhcp3-server port rakott fel. Ez alapértelmezés szerint a /usr/local/etc/dhcpd.conf.sample néven található meg, és mielõtt bármit is változtatnánk rajta, másoljuk le /usr/local/etc/dhcpd.conf néven. A DHCP szerver beállítása DHCP dhcpd.conf A dhcpd.conf az alhálózatokat illetve a gépeket érintõ deklarációkat tartalmazza, és talán a legkönnyebben a következõ példa alapján mutatható be: option domain-name "minta.com"; option domain-name-servers 192.168.4.100; option subnet-mask 255.255.255.0; default-lease-time 3600; max-lease-time 86400; ddns-update-style none; subnet 192.168.4.0 netmask 255.255.255.0 { range 192.168.4.129 192.168.4.254; option routers 192.168.4.1; } host mailhost { hardware ethernet 02:03:04:05:06:07; fixed-address levelezes.minta.com; } Ez a beállítás adja meg a kliensek számára az alapértelmezett keresési tartományt (search domain). A &man.resolv.conf.5; tud ezzel kapcsolatban részletesebb információkat adni. Ez a beállítás adja meg a kliensek által használt névfeloldó szerverek vesszõvel elválasztott felsorolását. A kliensekhez tartozó hálózati maszk. A kliens egy adott idõre kérhet bérleti jogot, egyébként a szerver dönt a bérlet lejárati idejérõl (másodpercekben). Ez az a maximális idõ, amennyire a szerver hajlandó bérbe adni IP-címet. A kliens ugyan hosszabb idõre is kérheti és meg is kapja, de legfeljebb csak max-lease-time másodpercig lesz érvényes. Ez a beállítás határozza meg, hogy a DHCP szervernek frissítse-e a névoldási információkat a bérlések elfogadásánál vagy visszamondásánál. Az ISC implementációjánál ez a beállítás kötelezõ. Ezzel adjuk meg milyen tartományból tudunk IP-címeket kiosztani a kliensek számára. A kezdõ címet is beleértve, innen fogunk kiutalni egyet a klienseknek. A kliensek felé elküldött alapértelmezett átjáró címe. A gép hardveres MAC-címe (így a DHCP szerver képes felismerni a kérés küldõjét). Ennek megadásával a gépek mindig ugyanazt az IP-címet kapják. Itt már megadhatunk egy hálózati nevet, mivel a bérlethez tartozó információk visszaküldése elõtt maga a DHCP szerver fogja feloldani a gép nevét. Miután befejeztük a dhcpd.conf módosítását, a DHCP szerver az /etc/rc.conf állományban tudjuk engedélyezni, vagyis tegyük bele a következõt: dhcpd_enable="YES" dhcpd_ifaces="dc0" A dc0 felület nevét helyettesítsük annak a felületnek (vagy whitespace karakterekkel elválasztott felületeknek) a nevével, amelyen keresztül a DHCP szerver várni fogja a kliensek kéréseit. Ezután a következõ parancs kiadásával indítsuk el a szervert: &prompt.root; /usr/local/etc/rc.d/isc-dhcpd.sh start Amikor a jövõben valamit változtatunk a konfigurációs állományon, akkor ezzel kapcsolatban fontos megemlíteni, hogy ha csak egy SIGHUP jelzést küldünk a dhcpd démonnak, akkor az a többi démontól eltérõen önmagában még nem eredményezi a konfigurációs adatok újraolvasását. Helyette a SIGTERM jelzéssel kell leállítani a programot, majd újraindítani a fenti paranccsal. Állományok DHCP konfigurációs állományok /usr/local/sbin/dhcpd A dhcpd statikusan linkelt és a /usr/local/sbin könyvtárban található. A porttal együtt felkerülõ &man.dhcpd.8; man oldal ad részletesebb útmutatást dhcpd használatáról. /usr/local/etc/dhcpd.conf Mielõtt a dhcpd megkezdhetné mûködését, egy konfigurációs állományra is szükségünk lesz, amely a /usr/local/etc/dhcpd.conf. Ez az állomány tartalmazza az összes olyan információt, ami kell a kliensek megfelelõ kiszolgálásához valamint a szerver mûködéséhez. Ez a konfigurációs állomány porthoz tartozó &man.dhcpd.conf.5; man oldalon kerül ismertetésre. /var/db/dhcpd.leases A DHCP szerver ebben az állományba tartja nyilván a kiadott bérleteket, egy napló formájában. A porthoz kapcsolódó &man.dhcpd.leases.5; man oldalon errõl többet is megtudhatunk. /usr/local/sbin/dhcrelay A dhcrelay állománynak olyan komolyabb környezetekben van szerepe, ahol a DHCP szerver a kliensektõl érkezõ kéréseket egy másik hálózaton található DHCP szerverhez továbbítja. Ha szükség lenne erre a lehetõségre, akkor telepítsük fel a net/isc-dhcp3-relay portot. A porthoz tartozó &man.dhcrelay.8; man oldal ennek részleteit taglalja. Chern Lee Készítette: Tom Rhodes Daniel Gerzo Névfeloldás (<acronym>DNS</acronym>) Áttekintés BIND A &os; alapértelmezés szerint a BIND (Berkeley Internet Name Domain) egyik verzióját tartalmazza, amely a névfeloldási (Domain Name System, DNS) protokoll egyik elterjedt implementációja. A DNS protokollon keresztül tudunk az IP-címekhez neveket rendelni és fordítva. Például a www.FreeBSD.org névre a &os; Projekt webszerverének IP-címét kapjuk meg, miközben a ftp.FreeBSD.org pedig a hozzátartozó FTP szerver IP-címét fogja visszaadni. Ehhez hasonlóan a fordítottja is megtörténhet, vagyis egy IP-címhez is kérhetjük a hálózati név feloldását. A névfeloldási kérések kiszolgálásához nem feltétlenül szükséges névszervert futtatni a rendszerünkön. A &os; jelen pillanatban alapból a BIND9 névszervert tartalmazza. A benne szereplõ változata több biztonsági javítást, új állományrendszeri kiosztást és automatizált &man.chroot.8; beállítást is magában foglal. névfeloldás Az interneten keresztüli névfeloldást legfelsõ szintû tartományoknak (Top Level Domain, TLD) nevezett hitelesített tövek némileg bonyolult rendszerén alapszik, valamint más egyéb olyan névszervereken, amelyek további egyéni információkat tárolnak és táraznak. A BIND fejlesztését jelenleg az Internet Software Consortium () felügyeli. Alapfogalmak A leírás megértéséhez be kell mutatnunk néhány névfeloldással kapcsolatos fogalmat. névfeloldó inverz DNS gyökérzóna Fogalom Meghatározás Közvetlen névfeloldás (forward DNS) A hálózati nevek leképezése IP-címekre. Õs (origin) Egy adott zóna állományban szereplõ tartományra vonatkozik. named, BIND, névszerver (name server) A &os;-n belüli BIND névszerver különbözõ megnevezései. Névfeloldó (resolver) Az a program a rendszerben, amelyhez a hálózaton levõ gépek a zónák adatainak elérésével kapcsolatban fordulnak. Inverz névfeloldás (reverse DNS) A rendes névfeloldás ellentéte, vagyis az IP-címek leképzése hálózati nevekre. Gyökérzóna (root zone) Az interneten található zónák hierarchiájának töve. Minden zóna ebbe a gyökérzónába esik, ahhoz hasonlóan, ahogy egy állományrendszerben az állományok a gyökérkönyvtárba. Zóna (zone) Egy különálló tartomány, altartomány vagy a névfeloldás azon része, amelyet egyazon fennhatóság alatt tartanak karban. zónák példák Példák zónákra: A . gyökérzóna. A org. egy legfelsõ szintû tartomány (TLD) a gyökérzónán belül. A minta.org. a org. TLD tartomány alatti zóna. A 1.168.192.in-addr.arpa egy olyan zóna, amelyek a 192.168.1.* IP-tartományban szereplõ összes címet jelöli. Mint láthatjuk, a hálózati nevek balról kiegészülve pontosodnak. Tehát például a minta.org. sokkal pontosabb meghatározás, mint a org., ahogy az org. magánál a gyökérzónánál jelent többet. A hálózati nevek felosztása leginkább egy állományrendszerhez hasonlítható, például a /dev könyvtár a + class="directory">/dev könyvtár a gyökéren belül található, és így tovább. Miért érdemes névszervert futtatni A névszerverek általában két alakban jelennek meg. Egyikük a hitelesített névszerver, a másikuk a gyorsítótárazó névszerver. Egy hitelesített névszerverre akkor van szükségünk, ha: a világ többi része felé akarunk hiteles névfeloldási információkat szolgáltatni; regisztráltunk egy tartományt (például minta.org) és az alatta levõ hálózati nevekhez is szeretnénk IP-címeket rendeltetni; a IP-címtartományunkban szükség van inverz névfeloldási bejegyzésekre (amely IP-címbõl ad meg hálózati nevet) is; a kérések teljesítéséhez egy tartalék avagy második, alárendelt (slave) névszerver kell. A gyorsítótárazó névszerverre akkor van szükségünk, ha: egy helyi névfeloldó szerver felhasználásával fel akarjuk gyorsítani az egyébként a külsõ névszerver felé irányuló kérések kiszolgálását. Amikor valaki lekérdezi a www.FreeBSD.org címét, akkor a névfeloldó elõször általában a kapcsolatot rendelkezésre bocsátó internet-szolgáltató névszerverét kérdezi meg és onnan kapja meg a választ. Egy helyi, gyorsítótárazó névszerver használata esetén azonban egy ilyen kérést csak egyszer kell kiadni a külsõ névszervernek. Ezután már minden további ilyen kérés el sem hagyja a belsõ hálózatunkat, mivel a válasz szerepel a gyorsítótárban. Ahogyan mûködik &os; alatt a BIND démon nyilvánvaló okokból named néven érhetõ el. Állomány Leírás &man.named.8; A BIND démon. &man.rndc.8; A névszervert vezérlõ segédprogram. - /etc/namedb + /etc/namedb A BIND által kezelt zónák adatait tároló könyvtár. /etc/namedb/named.conf A démon konfigurációs állománya. Attól függõen, hogy miként állítjuk be az adott zónát a szerveren, a hozzátartozó állományok - a /etc/namedb + a /etc/namedb könyvtáron belül a master, slave vagy dynamic alkönyvtárban + class="directory">master, slave vagy dynamic alkönyvtárban foglalnak helyet. Az itt tárolt állományokban levõ névfeloldási információk alapján válaszol a névszerver a felé intézett kérésekre. A BIND elindítása BIND elindítás Mivel a BIND alapból elérhetõ a rendszerben, viszonylag könnyen be tudjuk állítani. A named alapértelmezett beállítása szerint egy &man.chroot.8; környezetben futó egyszerû névfeloldást végzõ szerver. Ezzel a beállítással a következõ parancson keresztül tudjuk elindítani: &prompt.root; /etc/rc.d/named forcestart Ha engedélyezni akarjuk a named démont minden egyes rendszerindításkor, tegyük a következõ sort az /etc/rc.conf állományba: named_enable="YES" Értelemszerûen az /etc/namedb/named.conf tele van olyan beállítási lehetõségekkel, amelyek meghaladják ennek a leírásnak a kereteit. Ha viszont kíváncsiak vagyunk a &os;-ben a named indításához használt beállításokra, akkor az /etc/defaults/rc.conf állományban nézzük meg named_* változókat és olvassuk át az &man.rc.conf.5; man oldalt. Emellett még a t is hasznos lehet elolvasni. A konfigurációs állományok BIND konfigurációs állományok A named beállításait tartalmazó állományok pillanatnyilag az /etc/namedb könyvtárban + class="directory">/etc/namedb könyvtárban találhatóak és hacsak nem egy egyszerû névfeloldóra tartunk igényt, akkor a használata elõtt módosítanunk is kell. Itt ejtjük meg a beállítások nagy részét. A <command>make-localhost</command> használata Ha a helyi gépen egy központi zónát akarunk beállítani, akkor lépjünk be az /etc/namedb könyvtárba + class="directory">/etc/namedb könyvtárba és futtassuk le a következõ parancsot: &prompt.root; sh make-localhost Ha nem történt semmilyen hiba, akkor a master alkönyvtárban most meg kell jelennie egy új állománynak. A helyi tartománynévhez tartozó állomány a localhost.rev, valamint IPv6 környezetben a localhost-v6.rev. Alapértelmezett konfigurációs állományként a named.conf ehhez tartalmaz minden szükséges információt. <filename>/etc/namedb/named.conf</filename> // $FreeBSD$ // // Részletesebb leírást a named.conf(5) és named(8) man oldalakon, valamint // a /usr/share/doc/bind9 könyvtárban találhatunk. // // Ha egy hitelesített szervert akarunk beállítani, akkor igyekezzünk // a névfeloldás összes finom részletével pontosan tisztában lenni. // Ugyanis még a legkisebb hibákkal is egyrészt elvághatunk gépeket az // internet-lérésétõl, vagy másrészt felesleges forgalmat tudunk // generálni // options { directory "/etc/namedb"; pid-file "/var/run/named/pid"; dump-file "/var/dump/named_dump.db"; statistics-file "/var/stats/named.stats"; // Ha a named démont csak helyi névfeloldóként használjuk, akkor ez // egy biztonságos alapbeállítás. Ha viszont a named démon az egész // hálózatunkat is kiszolgálja, akkor ezt a beállítást tegyük // megjegyzésbe, vagy adjunk meg egy rendes IP-címet, esetleg // töröljük ki. listen-on { 127.0.0.1; }; // Ha rendszerünkön engedélyezett az IPv6 használata, akkor a helyi // névfeloldó használatához ezt a sort vegyük ki a megjegyzésbõl. // A hálózatunk többi részérõl pedig úgy lehet elérni, ha itt megadunk // egy IPv6 címet, vagy az "any" kulcsszót. // listen-on-v6 { ::1; }; // A "forwarders" blokk mellett a következõ sorral megkérhetjük a // névszervert, hogy önmagától soha nem kezdeményezzen kéréseket, // hanem mindig az iménti helyen megjelölt szerverekhez irányítsa // ezeket: // // forward only; // Ha a szolgáltatónk névszervert is elérhetõvé tett számunkra, akkor // itt adjuk meg annak az IP-címét és engedélyezzük az alábbi sort. // Ezzel egyben kihasználjuk a gyorsítótárat is, így mérsékeljük az // internet felé mozgó névfeloldásokat. /* forwarders { 127.0.0.1; }; */ Ahogy arról a megjegyzésekben is szó esik, úgy tudjuk aktiválni a gyorsítótárat, ha megadjuk a forwarders beállítást. Normális körülmények között a névszerver az interneten az egyes névszervereket rekurzívan fogja keresni egészen addig, amíg meg nem találja a keresett választ. Az iménti beállítás engedélyezésével azonban elõször a szolgáltató névszerverét (vagy az általa kijelölt névszervert) fogjuk megkérdezni, a saját gyorsítótárából. Ha a szolgáltató kérdéses névszervere egy gyakran használt, gyors névszerver, akkor ezt érdemes bekapcsolnunk. Itt a 127.0.0.1 megadása nem mûködik. Mindenképpen írjuk át a szolgáltatónk névszerverének IP-címére. /* * Ha köztünk és az elérni kívánt névszerverek között tûzfal * is található, akkor az alábbi "query-source" direktívát is * engedélyeznünk kell. A BIND korábbi változatait mindig az * 53-as porton keresztül küldték el a kéréseiket, de BIND * nyolcadik verziójától kezdve alapértelmezés szerint * erre a feladatra már egy véletlenszerûen választott, nem * privilegizált UDP portot használnak. */ // query-source address * port 53; }; // Ha engedélyezzük a helyi névszervert, akkor az /etc/resolv.conf // állományban elsõ helyen megadni a 127.0.0.1 címet. Sõt, az // /etc/rc.conf állományból se felejtsük ki. zone "." { type hint; file "named.root"; }; zone "0.0.127.IN-ADDR.ARPA" { type master; file "master/localhost.rev"; }; // RFC 3152 zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA" { type master; file "master/localhost-v6.rev"; }; // FONTOS: Ne használjuk ezeket az IP-címeket, mert nem valódiak, // csupán illusztrációs és dokumentációs célokból adtuk meg! // // Az alárendelt zónák beállításaira vonatkozó bejegyzések. Érdemes // ilyet beállítani legalább ahhoz a zónához, amelyhez a tartományunk is // tartozik. Az elsõdleges zónához tartozó IP-címet érdeklõdjük meg // az illetékes hálózati rendszergazdától. // // Soha ne felejtsünk el megadni zónát az inverz kereséshez // IN-ADDR.ARPA)! (A neve a IP-cím tagjainak fordított sorrendjébõl // származik, amelyhez hozzátoldunk még egy ".IN-ADDR.ARPA" részt.) // // Mielõtt nekilátnánk egy elsõdleges zóna beállításának, gondoljuk // végig, hogy tényleg a megfelelõ szinten ismerjük a névfeloldás és // a BIND mûködését. Gyakran ugyanis egyáltalán nem nyilvánvaló // csapdákba tudunk esni. Egy alárendelt zóna beállítása sokkal // egyszerûbb feladat. // // FONTOS: Ne kövessük vakon a most következõ példát :-) Helyette inkább // valódi neveket és címeket adjunk meg. /* Példa központi zónára zone "minta.net" { type master; file "master/minta.net"; }; */ /* Példa dinamikus zónára key "mintaorgkulcs" { algorithm hmac-md5; secret "sf87HJqjkqh8ac87a02lla=="; }; zone "minta.org" { type master; allow-update { key "mintaorgkulcs"; }; file "dynamic/minta.org"; }; */ /* Példa közvetlen és inverz alárendelt zónákra zone "minta.com" { type slave; file "slave/minta.com"; masters { 192.168.1.1; }; }; zone "1.168.192.in-addr.arpa" { type slave; file "slave/1.168.192.in-addr.arpa"; masters { 192.168.1.1; }; }; */ A named.conf állományban tehát így adhatunk meg közvetlen és inverz alárendelt zónákat. Minden egyes újabb kiszolgált zónához az egy új bejegyzést kell felvenni a named.conf állományban. Például a minta.org címhez tartozó legegyszerûbb ilyen bejegyzés így néz ki: zone "minta.org" { type master; file "master/minta.org"; }; Ez egy központi zóna, ahogy arról a mezõ, vagyis a típusa is árulkodik. Továbbá a mezõben láthatjuk, hogy a hozzátartozó információkat az /etc/namedb/master/minta.org állományban tárolja. zone "minta.org" { type slave; file "slave/minta.org"; }; Az alárendelt esetben a zónához tartozó információkat a zóna központi szerverétõl kapjuk meg és megadott állományban mentjük el. Ha valamiért a központi szerver leáll vagy nem érhetõ el, akkor az alárendelt szerver az átküldött zóna információk alapján képes helyette kiszolgálni a kéréseket. A zóna állományok BIND zóna állományok A minta.org címhez tartozó példa központi zóna állomány (amely az /etc/namedb/master/néven.org érhetõ el) tartalma az alábbi: $TTL 3600 ; 1 óra minta.org. IN SOA ns1.minta.org. admin.minta.org. ( 2006051501 ; sorozatszám 10800 ; frissítés 3600 ; ismétlés 604800 ; lejárat 86400 ; minimális TTL ) ; névszerverek IN NS ns1.minta.org. IN NS ns2.minta.org. ; MX rekordok IN MX 10 mx.minta.org. IN MX 20 levelezes.minta.org. IN A 192.168.1.1 ; a gépek nevei localhost IN A 127.0.0.1 ns1 IN A 192.168.1.2 ns2 IN A 192.168.1.3 mx IN A 192.168.1.4 levelezes IN A 192.168.1.5 ; álnevek www IN CNAME @ A .-ra végzõdõ hálózati nevek abszolút nevek, míg minden más . nélküli név az õsére vezehetõ vissza (tehát relatív). Például a www a www.õs. A kitalált zóna állományunkban itt most az õs a minta.org, így a www névbõl a www.minta.org név keletkezik. A zóna állományok felépítése a következõ: rekordnév IN rekordtípus érték névfeloldás rekordok A névfeloldásban leggyakrabban alkalmazott rekordok típusai: SOA a zóna fennhatóságának kezdete NS egy hitelesített névszerver A egy gép címe CNAME egy álnév kanonikus neve MX levélváltó PTR mutató a tartománynévre (az inverz feloldás használja) minta.org. IN SOA ns1.minta.org. admin.minta.org. ( 2006051501 ; sorozatszám 10800 ; 3 óránként frissítsünk 3600 ; 1 óra után próbálkozzunk újra 604800 ; 1 hét után jár le 86400 ) ; a minimális TTL 1 nap minta.org. a tartomány neve, amely egyben a zóna õse ns1.minta.org. a zóna elsõdleges/hitelesített névszervere admin.minta.org. a zónáért felelõs személy neve, akinek az e-mail címét a @ behelyettesítésével kapjuk meg. (Tehát a admin@example.org címbõl admin.example.org lesz.) 2006051501 az állomány sorozatszáma. Ezt a zóna állomány módosításakor mindig növelnünk kell. Manapság a rendszergazdák a sorozatszámot ééééhhnnvv alakban adják meg. A 2006051501 tehát azt jelenti, hogy az állományt 2006. május 15-én módosították utoljára, és a 01 pedig arra utal, hogy aznap elõször. A sorozatszám megadása fontos az alárendelt névszerverek számára, mivel így tudják megállapítani, hogy a zóna mikor változott utoljára. IN NS ns1.minta.org. Ez egy NS bejegyzés. A zónához tartozó minden hitelesített névszervernek lennie kell legalább egy ilyen bejegyzésének. localhost IN A 127.0.0.1 ns1 IN A 192.168.1.2 ns2 IN A 192.168.1.3 mx IN A 192.168.1.4 levelezes IN A 192.168.1.5 Az A rekord egy gép nevét adja meg. Ahogy a fenti példából is kiderül, az ns1.minta.org név a 192.168.1.2 címre képzõdik le. IN A 192.168.1.1 Ez a sor 192.168.1.1 címet rendeli az aktuális õshöz, amely jelen esetünkben az example.org. www IN CNAME @ A kanonikus neveket tároló rekordokat általában egy gép álneveihez használjuk. Ebben a példában a www a fõgép egyik álneve, amely itt a minta.org (192.168.1.1) tartomány. A CNAME rekordok tehát álnevek megadására használhatóak, vagy egyetlen állománynév körkörös rendszerû (round robin típusú) feloldására több gép között. MX rekord IN MX 10 levelezes.minta.org. Az MX rekord adja meg, hogy milyen levelezõ szerverek felelõsek a zónába érkezõ levelek fogadásáért. A levelezes.minta.org a levelezõ szerver hálózati neve, ahol a 10 az adott levelezõ szerver prioritása. Több levelezõ szerver is megadható 10-es, 20-as stb. prioritásokkal. A minta.org tartományon belül elõször mindig a legnagyobb MX prioritással rendelkezõ levelezõ szervernek próbáljuk meg továbbítani a leveleket (a legkisebb prioritási értékkel rendelkezõ rekord), majd ezután a második legnagyobbnak stb. egészen addig, amíg a levelet tovább nem küldtük. Az in-addr.arpa zóna állományok (inverz DNS) esetén ugyanez a felépítés, kivéve, hogy a PTR típusú bejegyzések szerepelnek az A és CNAME helyett. $TTL 3600 1.168.192.in-addr.arpa. IN SOA ns1.minta.org. admin.minta.org. ( 2006051501 ; sorozatszám 10800 ; frissítés 3600 ; ismétlés 604800 ; lejárat 3600 ) ; minimum IN NS ns1.minta.org. IN NS ns2.minta.org. 1 IN PTR minta.org. 2 IN PTR ns1.minta.org. 3 IN PTR ns2.minta.org. 4 IN PTR mx.minta.org. 5 IN PTR levelezes.minta.org. Ez az állomány írja le tehát a kitalált tartományunkon belül az IP-címek és hálózati nevek összerendelését. A gyorsítótárazó névszerver BIND gyorsítótárazó névszerver A gyorsítótárazó névszerver az a névszerver, amelyik egyik zónában sem hitelesített. Egyszerûen csak öncélú kéréseket küld, és a kapott válaszokat megjegyzi. A beállításához mindössze annyit kell tennünk, hogy az eddigiekhez hasonlóan, de zónák nélkül beállítunk egy névszervert. Biztonság Habár a névfeloldás szempontjából a BIND a legelterjedtebb, a biztonságosságával azért akadnak gondok. Gyakran találnak benne potenciális és kihasználható biztonsági réseket. A &os; azonban a named démont automatikusan egy &man.chroot.8; környezetbe helyezi. Emellett még léteznek további más védelmi mechanizmusok is, amelyek segítségével el tudjuk kerülni a névfeloldást célzó esetleges támadásokat. Sosem árt olvasgatni a CERT által kiadott biztonsági figyelmeztetéseket és feliratkozni a &a.security-notifications; címére, hogy folyamatosan értesüljünk az interneten és a &os;-ben talált különbözõ biztonsági hibákról. Ha valamilyen gondunk támadna, akkor esetleg próbálkozzunk meg a forrásaink frissítésével és a named újrafordításával. Egyéb olvasnivalók A BIND/named man oldalai: &man.rndc.8; &man.named.8; &man.named.conf.5; Az ISC BIND hivatalos honlapja (angolul) Az ISC BIND hivatalos fóruma (angolul) A BIND GYIK (angolul) O'Reilly DNS and BIND 5th Edition RFC1034 - Domain Names - Concepts and Facilities RFC1035 - Domain Names - Implementation and Specification Murray Stokely Készítette: Az Apache webszerver webszerverek beállítása Apache Áttekintés A &os; szolgálja ki a legforgalmasabb honlapok nagy részét szerte a világban. A mögöttük álló webszerverek általában az Apache webszervert alkalmazzák. Az Apache használatához szükséges csomagok megtalálhatóak a &os; telepítõlemezén is. Ha a &os; elsõ telepítésekor még nem telepítettük volna az Apache szerverét, akkor a www/apache13 vagy www/apache12 portból tudjuk feltenni. Az Apache szervert sikeres telepítését követõen be kell állítanunk. Ebben a szakaszban az Apache webszerver 1.3.X változatát mutatjuk be, mivel ezt használják a legtöbben &os; alatt. Az Apache 2.X rengeteg új technológiát vezetett be, de ezekkel itt most nem foglalkozunk. Az Apache 2.X változatával kapcsolatban keressük fel a oldalt. Beállítás Apache konfigurációs állományok Az Apache webszerver konfigurációs állománya &os; alatt /usr/local/etc/apache/httpd.conf néven található. Ez az állomány egy szokványos &unix;-os szöveges konfigurációs állomány, ahol a megjegyzéseket egy # karakterrel vezetjük be. Az itt használható összes lehetséges beállítási lehetõség átfogó ismertetése meghaladná az egész kézikönyv határait, ezért most csak a leggyakrabban módosított direktívákat fogjuk ismertetni. ServerRoot "/usr/local" Ez adja meg az Apache számára az alapértelmezett könyvtárat. A binárisai ezen belül a bin és sbin alkönyvtárakban, a konfigurációs állományai pedig az etc/apache könyvtárban tárolódnak. ServerAdmin saját@címünk.az.interneten Erre a címre küldhetik nekünk a szerverrel kapcsolatos hibákat. Ez a cím egyes szerver által generált oldalakon jelenik meg, például hibák esetében. ServerName www.minta.com A ServerName segítségével meg tudjuk adni, hogy milyen nevet küldjön vissza a szerver a klienseknek olyankor, ha az nem egyezne meg a jelenlegivel (vagyis a www nevet használjuk a gépünk valódi neve helyett). DocumentRoot "/usr/local/www/data" A DocumentRoot adja meg azt a könyvtárat, ahonnan kiszolgáljuk a dokumentumokat. Alapértelmezés szerint az összes kérés erre a könyvtárra fog vonatkozni, de a szimbolikus linkek és az álnevek akár más helyekre is mutathatnak. A változtatások végrehajtása elõtt mindig is jó ötlet biztonsági másolatot készíteni az Apache konfigurációs állományairól. Ahogy sikerült összerakni egy számunkra megfelelõ konfigurációt, készen is állunk az Apache futtatására. Az <application>Apache</application> futtatása Apache indítása és leállítása A többi hálózati szervertõl eltérõen az Apache nem az inetd szuperszerverbõl fut. A kliensektõl érkezõ HTTP kérések minél gyorsabb kiszolgálásának érdekében úgy állítottuk be, hogy önállóan fusson. Ehhez egy szkriptet is mellékeltünk, amellyel igyekeztünk a lehetõ legjobban leegyszerûsíteni a szerver indítását, leállítását és újraindítását. Az Apache elsõ indításához adjuk ki a következõ parancsot: &prompt.root; /usr/local/sbin/apachectl start Így pedig a szervert bármikor leállíthatjuk: &prompt.root; /usr/local/sbin/apachectl stop Ha valamilyen okból megváltoztattuk volna a szerver beállításait, akkor ezen a módon tudjuk újraindítani: &prompt.root; /usr/local/sbin/apachectl restart Ha a jelenleg megnyitott kapcsolatok felbontása nélkül akarjuk újraindítani az Apache szervert, akkor ezt írjuk be: &prompt.root; /usr/local/sbin/apachectl graceful Mindezekrõl az &man.apachectl.8; man oldalon találunk bõvebb leírást. Amennyiben szükségünk lenne az Apache elindítására a rendszer indításakor, akkor a következõ sort vegyünk fel az /etc/rc.conf állományba: apache_enable="YES" Az Apache 2.2 esetében: apache22_enable="YES" Amikor az Apache httpd nevû programjának szeretnénk további paranccsori paramétereket átadni a rendszer indítása során, akkor ezeket így tudjuk megadni az rc.conf állományban: apache_flags="" Most, miután a webszerverünk mûködik, a böngészõnkkel mindezt ellenõrizni is tudjuk a http://localhost/ cím beírásával. Ilyenkor az alapértelmezés szerinti /usr/local/www/data/index.html állomány tartalmát láthatjuk. Virtuális nevek Az Apache a virtuális nevek használatának két különbözõ módját ismeri. Ezek közül az elsõ módszer a név alapú virtualizáció (Name-based Virtual Hosting). Ilyenkor a kliens HTTP/1.1 fejlécébõl próbálja meg a szerver megállapítani a hivatkozási nevet. Segítségével több tartomány is osztozhat egyetlen IP-címen. Az Apache név alapú virtualizációjának beállításához az alábbi beállítást kell hozzátennünk a httpd.conf állományhoz: NameVirtualHost * Ha a webszerverünk neve www.tartomany.hu, és hozzá egy www.valamilyenmasiktartomany.hu virtuális nevet akarunk megadni, akkor azt a következõképpen tehetjük meg a httpd.conf állományon belül: <VirtualHost *> ServerName www.tartomany.hu DocumentRoot /www/tartomany.hu </VirtualHost> <VirtualHost *> ServerName www.valamilyenmasiktartomany.hu DocumentRoot /www/valamilyenmasiktartomany.hu </VirtualHost> A címek és elérési utak helyére helyettesítsük be a használni kívánt címeket és elérési utakat. A virtuális nevek beállításának további részleteivel kapcsolatosan keressük fel az Apache hivatalos dokumentációját a címen (angolul). Apache-modulok Apache modulok Az alap szerver képességeinek kiegészítéséhez több különbözõ Apache modul áll rendelkezésünkre. A &os; Portgyûjteménye az Apache telepítése mellett lehetõséget ad a népszerûbb bõvítményeinek telepítésére is. mod_ssl webszerverek biztonság SSL titkosítás A mod_ssl modul az OpenSSL könyvtár használatával valósít meg erõs titkosítást a biztonságos socket réteg második, illetve harmadik verziójával (Secure Sockets Layer, SSL v2/v3) és a biztonságos szállítási rétegbeli (Transport Layer Security v1) protokoll segítségével. Ez a modul mindent biztosít ahhoz, hogy a megfelelõ hatóságok által aláírt tanúsítványokat tudjunk kérni, és ezáltal egy védett webszervert futtassunk &os;-n. Ha még nem telepítettünk volna fel az Apache szervert, akkor a www/apache13-modssl porton keresztül a mod_ssl modullal együtt is fel tudjuk rakni az Apache 1.3.X változatát. Az SSL támogatása pedig már az Apache 2.X www/apache22 porton keresztül elérhetõ változataiban alapértelmezés szerint engedélyezett. Kapcsolódás nyelvekhez Mindegyik nagyobb szkriptnyelvhez létezik egy külön Apache-modul, amelyek segítségével komplett Apache-modulokat tudunk készíteni az adott nyelven. Gyakran a dinamikus honlapok is így próbálják a szerverbe épített belsõ értelmezõn keresztül a külsõ értelmezõ indításából és benne a szkriptek lefuttatásából fakadó költségeket megspórolni, ahogy errõl a következõ szakaszokban olvashatunk. Dinamikus honlapok webszerverek dinamikus Az utóbbi évtizedben egyre több vállalkozás fordult az internet felé bevételeik és részesedéseinek növelésének reményében, amivel egyre jobban megnõtt az igény a dinamikus honlapokra is. Miközben bizonyos cégek, mint például a µsoft;, a saját fejlesztésû termékeikbe építettek be ehhez támogatást, addig a nyílt forrásokkal foglalkozó közösség sem maradt tétlen és felvette a kesztyût. A dinamikus tartalom létrehozásához többek közt Django, Ruby on Rails, a mod_perl és a mod_php modulok használhatóak. Django Python Django A Django egy BSD típusú licensszel rendelkezõ keretrendszer, amelynek használatával nagy teljesítményû és elegáns webes alkalmazásokat tudunk gyorsan kifejleszteni. Tartalmaz egy objektum-relációs leképezõt, így az adattípusokat Python-objektumokként tudjuk leírni, és ezekhez az objektumokhoz egy sokrétû, dinamikus adatbázis hozzáférést nyújtó alkalmazásfejlesztõi felületet, így a fejlesztõknek egyetlen SQL utasítást sem kell megírniuk. Találhatunk még benne továbbá egy bõvíthetõ sablonrendszert, amelynek köszönhetõen az alkalmazás belsõ mûködése elválasztható a HTML-beli megjelenésétõl. A Django mûködéséhez a mod_python modulra, az Apache szerverre és egy tetszõlegesen választott SQL alapú adatbázisrendszerre van szükség. A hozzátartozó &os; port mindezeket automatikusan telepíti a megadott beállítások szerint. A Django telepítése az Apache, mod_python3 és a PostgreSQL használatával &prompt.root; cd /usr/ports/www/py-django; make all install clean -DWITH_MOD_PYTHON3 -DWITH_POSTGRESQL Miután a Django és a hozzá szükséges komponensek felkerültek rendszerünkre, hozzunk létre egy könyvtárat a leendõ Django projektünknek és állítsuk be az Apache szervert, hogy az oldalunk belül a megadott linkekre a saját alkalmazásunkat hívja meg a beágyazott Python-értelmezõn keresztül. Az Apache beállítása a Django és mod_python használatához A következõ sort kell hozzátennünk a httpd.conf állományhoz, hogy az Apache bizonyos linkeket a webes alkalmazás felé irányítson át: <Location "/"> SetHandler python-program PythonPath "['/a/django/csomagok/helye/'] + sys.path" PythonHandler django.core.handlers.modpython SetEnv DJANGO_SETTINGS_MODULE azoldalam.beallitasai PythonAutoReload On PythonDebug On </Location> Ruby on Rails Ruby on Rails A Ruby on Rails egy olyan másik nyílt forráskódú keretrendszer, amivel lényegében egy teljes fejlesztõi készletet kapunk és amelyet kifejezetten arra élezték ki, hogy segítségével a webfejlesztõk sokkal gyorsabban tudjanak haladni és a komolyabb alkalmazások gyorsabb elkészítése se okozzon nekik gondot. A Portrgyûjteménybõl pillanatok alatt telepíthetõ. &prompt.root; cd /usr/ports/www/rubygem-rails; make all install clean mod_perl mod_perl Perl Az Apache és Perl egyesítésén fáradozó projekt a Perl programozási nyelv és az Apache webszerver erejének összehangolásán dolgozik. A mod_perl modulon keresztül Perlben vagyunk képesek modulokat készíteni az Apache szerverhez. Ráadásul a szerverben egy belsõ állandó értelmezõ is található hozzá, ezzel igyekeznek megspórolni a külsõ értelmezõ és a Perl indításából keletkezõ többletköltségeket. A mod_perl több különbözõ módon állítható munkába. A mod_perl használatához nem szabad elfelejtenünk, hogy a mod_perl 1.0-ás verziója csak az Apache 1.3 változatával mûködik, és a mod_perl 2.0-ás változata pedig csak az Apache 2.X változataival. A mod_perl 1.0 a www/mod_perl portból telepíthetõ, valamint a statikusan beépített változata a www/apache13-modperl portban található. A mod_perl 2.0 a www/mod_perl2 portból rakható fel. Tom Rhodes Írta: mod_php mod_php PHP A PHP, vagy másik nevén PHP, a hipertext feldolgozó egy általános célú szkriptnyelv, amelyet kifejezetten honlapok fejlesztéséhez hoztak létre. A szabványos HTML ágyazható nyelv felépítésében a C, &java; és Perl nyelveket ötvözi annak elérése érdekében, hogy ezzel segítse a fejlesztõket a dinamikusan generált oldalak minél gyorsabb megírásában. A PHP5 támogatását úgy tudjuk hozzáadni az Apache webszerverhez, ha telepítjük a lang/php5 portot. Ha a lang/php5 portot most telepítjük elõször, akkor a vele kapcsolatos beállításokat tartalmazó OPTIONS menü automatikusan megjelenik. Ha ezzel nem találkoznánk, mert például valamikor korábban már felraktuk volna a lang/php5 portot, akkor a port könyvtárában következõ parancs kiadásával tudjuk újra visszahozni: &prompt.root; make config A beállítások között jelöljük be az APACHE opciót, amelynek eredményeképpen létrejön az Apache webszerverhez használható mod_php5 betölthetõ modul. A PHP4 modult még ma is rengeteg szerver használja több különbözõ okból (például kompatibilitási problémák vagy a már korábban kiadott tartalom miatt). Ha tehát a mod_php5 helyett inkább a mod_php4 modulra lenne szükségünk, akkor a lang/php4 portot használjuk. A lang/php4 portnál is megtalálhatjuk a lang/php5 fordítási idejû beállításainak nagy részét. Az iméntiek révén települnek és beállítódnak a dinamikus PHP alkalmazások támogatásához szükséges mouldok. Az /usr/local/etc/apache/httpd.conf állományban ellenõrizni is tudjuk, hogy az alábbi részek megjelentek-e: LoadModule php5_module libexec/apache/libphp5.so AddModule mod_php5.c <IfModule mod_php5.c> DirectoryIndex index.php index.html </IfModule> <IfModule mod_php5.c> AddType application/x-httpd-php .php AddType application/x-httpd-php-source .phps </IfModule> Ahogy befejezõdött a mûvelet, a PHP modul betöltéséhez mindösszesen az apachectl paranccsal kell óvatosan újraindítanunk a webszervert: &prompt.root; apachectl graceful A PHP jövõbeni frissítéseihez már nem lesz szükségünk a make config parancsra, mivel a korábban kiválasztott OPTIONS menün belüli beállítasainkat a &os; Portgyûjteményéhez tartozó keretrendszer automatikusan elmenti. A PHP &os;-ben megtalálható támogatása kifejezetten moduláris, ezért az alap telepítése igencsak korlátozott. A további elemek hozzáadásához a lang/php5-extensions portot tudjuk használni. A port egy menüvezérelt felületet nyújt a PHP különbözõ bõvítményeinek telepítéséhez. Az egyes bõvítményeket azonban a megfelelõ portok használatával is fel tudjuk rakni. Például PHP5 modulhoz úgy tudunk támogatást adni a MySQL adatbázis szerverhez, ha feltelepítjük a databases/php5-mysql portot. Miután telepítettünk egy bõvítményt, az Apache szerverrel újra be kell töltetnünk a megváltozott beállításokat: &prompt.root; apachectl graceful Murray Stokely Készítette: Állományok átvitele (FTP) FTP szerverek Áttekintés Az adatállomány átviteli protokoll (File Transfer Protocol, FTP) a felhasználók számára lehetõséget ad az ún. FTP szerverekre állományokat feltölteni, illetve onnan állományokat letölteni. A &os; alaprendszere is tartalmaz egy ilyen FTP szerverprogramot, ftpd néven. Ezért &os; alatt egy FTP szerver beállítása meglehetõsen egyszerû. Beállítás A beállítás legfontosabb lépése, hogy eldöntsük milyen hozzáféréseken át lehet elérni az FTP szervert. Egy hétköznapi &os; rendszerben rengeteg hozzáférés a különbözõ démonokhoz tartozik, de az ismeretlen felhasználók számára nem kellene megengednünk ezek használatát. Az /etc/ftpusers állományban szerepelnek azok a felhasználók, akik semmilyen módon nem érhetik el az FTP szolgáltatást. Alapértelmezés szerint itt találhatjuk az elõbb említett rendszerszintû hozzáféréseket is, de ide minden további nélkül felvehetjük azokat a felhasználókat, akiknél nem akarjuk engedni az FTP elérését. Más esetekben elõfordulhat, hogy csak korlátozni akarjuk egyes felhasználók FTP elérését. Ezt az /etc/ftpchroot állományon keresztül tehetjük meg. Ebben az állományban a lekorlátozni kívánt felhasználókat és csoportokat írhatjuk bele. Az &man.ftpchroot.5; man oldalán olvashatjuk el ennek részleteit, ezért ennek pontos részleteit itt most nem tárgyaljuk. FTP anonim Ha az FTP szerverünkhöz névtelen (anonim) hozzáférést is engedélyezni akarunk, akkor ahhoz elõször készítenünk kell egy ftp nevû felhasználót a &os; rendszerünkben. A felhasználók ezután az ftp vagy anonymous nevek, valamint egy tetszõleges jelszó (ez a hagyományok szerint a felhasználó e-mail címe) használatával is képesek lesznek bejelentkezni. Az FTP szerver ezután a névtelen felhasználók esetében meghívja a &man.chroot.2; rendszerhívást, és ezzel lekorlátozza hozzáférésüket az ftp felhasználó könyvtárára. Két szöveges állományban adhatunk meg a becsatlakozó FTP kliensek számára üdvözlõ üzeneteket. Az /etc/ftpwelcome állomány tartalmát még a bejelentkezés elõtt látni fogják a felhasználók, a sikeres bejelentkezést követõen pedig az /etc/ftpmotd állomány tartalmát látják. Vigyázzunk, mert ennek az állománynak már a bejelentkezési környezethez képest relatív az elérése, ezért a névtelen felhasználók esetében ez konkrétan az ~ftp/etc/ftpmotd állomány lesz. Ahogy beállítottuk az FTP szervert, az /etc/inetd.conf állományban is engedélyeznünk kell. Itt mindössze annyira lesz szükségünk, hogy eltávolítjuk a megjegyzést jelzõ # karaktert a már meglevõ ftpd sor elõl: ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l Ahogy arról már a szót ejtett, az inetd beállításait újra be kell olvastatunk a konfigurációs állomány megváltoztatása után. Most már be is tudunk jelentkezni az FTP szerverre: &prompt.user; ftp localhost Karbantartás syslog naplóállományok FTP Az ftpd démon a &man.syslog.3; használatával naplózza az üzeneteket. Alapértelmezés szerint a rendszernaplózó démon az FTP mûködésére vonatkozó üzeneteket az /var/log/xferlog állományba írja. Az FTP naplóinak helyét az /etc/syslog.conf állományban tudjuk módosítani: ftp.info /var/log/xferlog FTP anonim Legyünk körültekintõek a névtelen FTP szerverek üzemeltetésekor. Azt pedig kétszer is gondoljuk meg, hogy engedélyezzük-e a névtelen felhasználók számára állományok feltöltését, hiszen könnyen azon kaphatjuk magunkat, hogy az FTP oldalunk illegális állománycserék színterévé válik vagy esetleg valami sokkal rosszabb történik. Ha mindenképpen szükségünk lenne erre a lehetõségre, akkor állítsunk be olyan engedélyeket a feltöltött állományokra, hogy a többi névtelen felhasználó ezeket a tartalmuk tüzetes ellenõrzéséig ne is olvashassa. Murray Stokely Készítette: Állomány- és nyomtatási szolgáltatások µsoft.windows; kliensek számára (Samba) Samba szerver Microsoft Windows állományszerver windowszos kliensek nyomtatószerver windowszos kliensek Áttekintés A Samba egy olyan elterjedt nyílt forráskódú szoftver, ami µsoft.windows; kliensek számára tesz lehetõvé állomány- és nyomtatási szolgáltatásokat. Az ilyen kliensek általa helyi meghajtóként képesek elérni a &os; állományrendszerét, vagy helyi nyomtatóként a &os; általt kezelt nyomtatókat. A Samba csomagja általában megtalálható a &os; telepítõeszközén. Ha a &os;-vel együtt nem raktuk fel a Samba csomagját, akkor ezt késõbb net/samba3 port vagy csomag telepítésével pótolhatjuk. Beállítás A Samba konfigurációs állománya a telepítés után /usr/local/share/examples/samba/smb.conf.default néven található meg. Ezt kell lemásolnunk /usr/local/etc/smb.conf néven, amelyet aztán a Samba tényleges használata elõtt módosítanunk kell. Az smb.conf állomány a Samba futásához használt beállításokat tartalmazza, mint például &windows; kliensek számára felkínált a nyomtatók és megosztások adatait. A Samba csomagban ezen kívül találhatunk még egy swat nevû webes eszközt, amellyel egyszerû módon tudjuk az smb.conf állományt állítgatni. A Samba webes adminisztrációs eszköze (SWAT) A Samba webes adminisztrációs segédeszköze (Samba Web Administration Tool, SWAT) az inetd démonon keresztül fut démonként. Ennek megfelelõn az /etc/inetd.conf állományban a következõ sort kell kivennünk megjegyzésbõl, mielõtt a swat segítségével megkezdenénk a Samba beállítását: swat stream tcp nowait/400 root /usr/local/sbin/swat swat Ahogy azt a is mutatja, az inetd démont újra kell indítanunk a megváltozott konfigurációs állományának újbóli beolvasásához. Miután az inetd.conf állományban a swat engedélyezésre került, a böngészõnk segítségével próbáljunk meg a címre csatlakozni. Elõször a rendszer root hozzáférésével kell bejelentkeznünk. Miután sikeresen bejelentkeztünk a Samba beállításait tárgyaló lapra, el tudjuk olvasni a rendszer dokumentációját, vagy a Globals fülre kattintva nekiláthatunk a beállítások elvégzésének. A Globals részben található opciók az /usr/local/etc/smb.conf állomány [global] szekciójában található változókat tükrözik. Általános beállítások Akár a swat eszközzel, akár a /usr/local/etc/smb.conf közvetlen módosításával dolgozunk, a Samba beállítása során a következõkkel mindenképpen össze fogunk futni: workgroup A szervert elérni kívánó számítógépek által használt NT tartomány vagy munkacsoport neve. netbios name NetBIOS A Samba szerver NetBIOS neve. Alapértelmezés szerint ez a név a gép hálózati nevének elsõ tagja. server string Ez a szöveg jelenik meg akkor, ha például a net view paranccsal vagy valamilyen más hálózati segédprogrammal kérdezzük le a szerver beszédesebb leírását. Biztonsági beállítások A /usr/local/etc/smb.conf állományban a két legfontosabb beállítás a választott biztonsági modell és a kliensek felhasználói jelszavainak tárolásához használt formátum. Az alábbi direktívák vezérlik ezeket: security Itt a két leggyakoribb beállítás a security = share és a security = user. Ha a kliensek a &os; gépen található felhasználói neveiket használják, akkor felhasználói szintû védelemre van szükségünk (tehát a user beállításra). Ez az alapértelmezett biztonsági házirend és ilyenkor a klienseknek elõször be kell jelentkezniük a megosztott erõforrások eléréséhez. A megosztás (share) szintû védelem esetében, a klienseknek nem kell a szerveren érvényes felhasználói névvel és jelszóval rendelkezniük a megosztott erõforrások eléréséhez. Ez volt az alapbeállítás a Samba korábbi változataiban. passdb backend NIS+ LDAP SQL adatbázis A Samba számos különbözõ hitelesítési modellt ismer. A klienseket LDAP, NIS+, SQL adatbázis vagy esetleg egy módosított jelszó állománnyal is tudjuk hitelesíteni. Az alapértelmezett hitelesítési módszer a smbpasswd, így itt most ezzel foglalkozunk. Ha feltesszük, hogy az alapértelmezett smbpasswd formátumot választottuk, akkor a Samba úgy fogja tudni hitelesíteni a klienseket, ha elõtte létrehozzuk a /usr/local/private/smbpasswd állományt. Ha a &windows;-os kliensekkel is el akarjuk érni a &unix;-os felhasználói hozzáféréseinket, akkor használjuk a következõ parancsot: &prompt.root; smbpasswd -a felhasználónév A hivatalos Samba HOGYAN ezekrõl a beállításokról szolgál további információkkal (angolul). Viszont az itt vázolt alapok viszont már elegendõek a Samba elindításához. A <application>Samba</application> elindítása A net/samba3 port a Samba irányítására egy új indító szkriptet tartalmaz. A szkript engedélyezéséhez, tehát általa a Samba elindításának, leállításának és újraindításának lehetõvé tételéhez vegyük fel a következõ sort az /etc/rc.conf állományba: samba_enable="YES" Ha még finomabb irányításra vágyunk: nmbd_enable="YES" smbd_enable="YES" Ezzel egyben a rendszer indításakor automatikusan be is indítjuk a Samba szolgáltatást. A Samba a következõkkel bármikor elindítható: &prompt.root; /usr/local/etc/rc.d/samba start Starting SAMBA: removing stale tdbs : Starting nmbd. Starting smbd. Az rc szkriptekkel kapcsolatban a t ajánljuk elolvasásra. A Samba jelen pillanatban három különálló démonból áll. Láthatjuk is, hogy az nmbd és smbd démonokat elindította a samba szkript. Ha az smb.conf állományban engedélyeztük a winbind névfeloldási szolgáltatást is, akkor láthatjuk, hogy ilyenkor a winbindd démon is elindul. A Samba így állítható le akármikor: &prompt.root; /usr/local/etc/rc.d/samba stop A Samba egy összetett szoftercsomag, amely a µsoft.windows; hálózatokkal kapcsolatos széles körû együttmûködést tesz lehetõvé. Az általa felkínált alapvetõ lehetõségeken túl a többit a honlapon ismerhetjük meg (angolul). Tom Hukins Készítette: Az órák egyeztetése az NTP használatával NTP Áttekintés Idõvel a számítógép órája hajlamos elmászni. A hálózati idõ protokoll (Network Time Protocol, NTP) az egyik módja az óránk pontosan tartásának. Rengeteg internetes szolgáltatás elvárja vagy éppen elõnyben részesíti a számítógép órájának pontosságát. Például egy webszervertõl megkérdezhetik, hogy egy állományt adott ideje módosítottak-e. A helyi hálózatban az egyazon állományszerveren megosztott állományok ellentmondásmentes dátumozása érdekében szinte elengedhetetlen az órák szinkronizálása. Az olyan szolgáltatások, mint a &man.cron.8; is komolyan építkeznek a pontosan járó rendszerórára, amikor egy adott pillanatban kell lefuttatniuk parancsokat. NTP ntpd A &os; alapból az &man.ntpd.8; NTP szervert tartalmazza, amellyel más NTP szerverek segítségével tudjuk beállítani gépünk óráját, vagy éppen idõvel kapcsolatos információkat szolgáltatni másoknak. A megfelelõ NTP szerverek kiválasztása NTP a szerverek kiválasztása Az óránk egyeztetéséhez egy vagy több NTP szerverre lesz szükségünk. Elõfordulhat, hogy a hálózati rendszergazdánk vagy az internet-szolgáltatónk már beállított egy ilyen szervert erre a célra. Ezzel kapcsolatban olvassuk el a megfelelõ leírásokat. A nyilvánosan elérhetõ NTP szerverekrõl készült egy lista, ahonnan könnyedén ki tudjuk keresni a számunkra leginkább megfelelõ (hozzánk legközelebbi) szervert. Ne hagyjuk figyelmen kívül a szerverre vonatkozó házirendet és kérjünk engedélyt a használatához, amennyiben ez szükséges. Több, egymással közvetlen kapcsolatban nem álló NTP szerver választásával járunk jól, ha netalán az egyikük váratlanul elérhetetlenné vagy az órája pontatlanná válna. Az &man.ntpd.8; a visszakapott válaszokat intelligensen használja fel, mivel esetükben a megbízható szervereket részesíti elõnyben. A gépünk beállítása NTP beállítása Alapvetõ beállítások ntpdate Ha a számítógépünk indításakor akarjuk egyeztetni az óránkat, akkor erre az &man.ntpdate.8; nevû programot használhatjuk. Ez olyan asztali gépek számára megfelelõ választás, amelyeket gyakran indítanak újra és csak idõnként kell szinkronizálnunk. A legtöbb gépnek viszont az &man.ntpd.8; használatára van szüksége. Az &man.ntpdate.8; elindítása olyan esetekben is hasznos, ahol az &man.ntpd.8; is fut. Az &man.ntpd.8; az órát fokozatosan állítja, ellenben az &man.ntpdate.8; az eltérés mértékétõl és irányától függetlenül egyszerûen átállítja a gép óráját a pontos idõre. Az &man.ntpdate.8; elindítását úgy tudjuk engedélyezni a rendszer indításakor, ha az /etc/rc.conf állományba berakjuk az ntpdate_enable="YES" sort. Emellett még ntpdate_flags változóban meg kell adnunk az alkalmazott beállítások mellett azokat a szervereket, amelyekkel szinkronizálni akarunk. NTP ntp.conf Általános beállítások Az NTP az /etc/ntp.conf állományon keresztül állítható, amelyek felépítését az &man.ntp.conf.5; man oldal tárgyalja. Íme erre egy egyszerû példa: server ntplocal.minta.com prefer server timeserver.minta.org server ntp2a.minta.net driftfile /var/db/ntp.drift A server beállítás adja meg az egyeztetéshez használt szervereket, soronként egyet. Ha egy szerver mellett szerepel még a prefer paraméter is, ahogy azt a példában a ntplocal.minta.com mellett láthattuk, akkor a többivel szemben azt a szervert fogjuk elõnyben részesíteni. Az így kiemelt szervertõl érkezõ választ abban az esetben viszont eldobjuk, hogy a többi szervertõl kapott válasz jelentõs mértékben eltér tõle. Minden más esetben a õ válasza lesz a mérvadó. A prefer paramétert általában olyan NTP szerverekhez használják, amelyek közismerten nagy pontosságúak, tehát például külön erre a célra szánt felügyeleti eszközt is tartalmaznak. A driftfile beállítással azt az állományt adjuk meg, amiben a rendszeróra frekvencia eltolódásait tároljuk. Az &man.ntpd.8; program ezzel ellensúlyozza automatikusan az óra természetes elmászását, ezáltal lehetõvé téve, hogy egy viszonylag pontos idõt kapjuk még abban az esetben is, amikor egy kis idõre külsõ idõforrások nélkül maradnánk. A driftfile beállítással egyben azt az állományt jelöljük ki, amely az NTP szervertõl kapott korábbi válaszokat tárolja. Ez az NTP mûködéséhez szükséges belsõ adatokat tartalmaz, ezért semmilyen más programnak nem szabad módosítania. A szerverünk elérésének szabályozása Alapértelmezés szerint az NTP szerverünket bárki képes elérni az interneten. Az /etc/ntp.conf állományban szereplõ restrict beállítás segítségével azonban meg tudjuk mondani, milyen gépek érhetik el a szerverünket. Ha az NTP szerverünk felé mindenféle próbálkozást el akarunk utasítani, akkor az /etc/ntp.conf állományba a következõ sort kell felvennünk: restrict default ignore Ezzel egyben azonban a helyi beállításainkban szereplõ szerverek elérését is megakadályozzuk. Ha külsõ NTP szerverekkel is szeretnénk szinkronizálni, akkor itt is engedélyezünk kell ezeket. Errõl bõvebben lásd az &man.ntp.conf.5; man oldalon. Ha csak a belsõ hálózatunkban levõ gépek számára szeretnénk elérhetõvé tenni az órák egyeztetését, de sem a szerver állapotának módosítását nem engedélyezzük, sem pedig azt, hogy a vele egyenrangú szerverekkel szinkronizáljon, akkor az iménti helyett a restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap sort írjuk bele, ahol a 192.168.1.0 a belsõ hálózatunk IP-címe és a 255.255.255.0 a hozzátartozó hálózati maszk. Az /etc/ntp.conf több restrict típusú beállítást is tartalmazhat. Ennek részleteirõl az &man.ntp.conf.5; man oldalon, az Access Control Support címû szakaszban olvashatunk. Az NTP futtatása Úgy tudjuk az NTP szervert elindítani a rendszerünkkel együtt, ha az /etc/rc.conf állományban szerepeltetjük az ntpd_enable="YES" sort. Ha az &man.ntpd.8; számára további beállításokat is át akarunk adni, akkor az /etc/rc.conf állományban adjuk meg az ntpd_flags paramétert. Ha a gépünk újraindítása nélkül akarjuk elindítani a szerver, akkor az ntpd parancsot adjuk ki az /etc/rc.conf állományban a ntpd_flags változóhoz megadott paraméterekkel. Mint például: &prompt.root; ntpd -p /var/run/ntpd.pid Az ntpd használati idõleges internet csatlakozással Az &man.ntpd.8; program megfelelõ mûködéséhez nem szükséges állandó internet kapcsolat. Ha azonban igény szerinti tárcsázással építjünk fel ideiglenes kapcsolatot, akkor érdemes letiltani az NTP forgalmát, nehogy feleslegesen aktiválja vagy tartsa életben a vonalat. Ha PPP típusú kapcsolatunk van, akkor az /etc/ppp/ppp.conf állományban a filter direktívával tudjuk ezt leszabályozni. Például: set filter dial 0 deny udp src eq 123 # Nem engedjük az NTP által küldött adatoknak, hogy tárcsázást # kezdeményezzenek: set filter dial 1 permit 0 0 set filter alive 0 deny udp src eq 123 # Nem engedjük az NTP adatainak, hogy fenntartsák a kapcsolatot: set filter alive 1 deny udp dst eq 123 set filter alive 2 permit 0/0 0/0 Mindenezekrõl részletesebb felvilágosítást a &man.ppp.8; man oldal PACKET FILTERING címû szakaszában és a /usr/share/examples/ppp/ könyvtárban található példákban kaphatunk. Egyes internet-szolgáltatók blokkolják az alacsonyabb portokat, ezáltal az NTP nem használható, mivel a válaszok nem fogják elérni a gépünket. További olvasnivalók Az NTP szerver dokumentációja HTML formátumban a /usr/share/doc/ntp/ könyvtárban található. diff --git a/hu_HU.ISO8859-2/books/handbook/ports/chapter.sgml b/hu_HU.ISO8859-2/books/handbook/ports/chapter.sgml index ccdaf2d85d..4edc7065e9 100644 --- a/hu_HU.ISO8859-2/books/handbook/ports/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/ports/chapter.sgml @@ -1,2175 +1,2175 @@ Alkalmazások telepítése: csomagok és portok Áttekintés portok csomagok A &os; rendszereszközök gazdag gyûjteményével érkezik az alaprendszer részeként. Azonban a külsõ alkalmazások telepítéséhez rengeteg teendõt kell elvégeznünk. A feladat elvégzésére ezért a &os; két, egymást kiegészítõ technológiát kínál fel: a &os; Portgyûjteményt (telepítés forráskódból) és a csomagokat (telepítés elõre elkészített bináris csomagokból). Mind a két módszerrel fel tudjuk telepíteni a kedvenc alkalmazásunk legújabb verzióját lokálisan vagy egyenesen a hálózatról. A fejezet elolvasása során megismerjük: hogyan telepítsünk külsõ fejlesztésû bináris szoftvercsomagokat; hogyan fordítsunk le a forrásukból külsõ fejlesztésû szoftvereket a Portgyûjtemény segítségével; hogyan távolítsunk el korábban már telepített csomagokat és portokat; hogyan bíráljuk felül a Portgyûjtemény által használt alapértelmezett értékeket; hogyan keressük meg a megfelelõ szoftvercsomagokat; hogyan frissítsük a telepített alkalmazásokat. Az alkalmazások telepítésének összefoglalása Ha korábban már használtunk &unix; rendszereket, valószínûleg ismerjük a külsõ alkalmazások telepítésének jellemezõ menetét: Töltsük le a szoftvert, amelyet vagy forráskód vagy pedig bináris formátumban érhetünk el. Bontsuk ki az alkalmazás letöltött változatát (ez általában a &man.compress.1;, &man.gzip.1; vagy a &man.bzip2.1; által tömörített tar állomány). Keressük meg dokumentációt (többnyire az INSTALL vagy a README állományban található, vagy a doc/ alkönyvtárban) és olvassuk el benne, hogyan tudjuk telepíteni a szoftvert. Ha a szoftver forrását töltöttük le, fordítsuk le. Elképzelhetõ, hogy ennek során szerkesztenünk kell a Makefile állományt vagy lefuttatnunk a configure szkriptet, illetve más lépéseket is el kell végeznünk. Próbáljuk a ki szoftvert, majd telepítsük. Ez annak a forgatókönyve, amikor minden hiba nélkül lezajlik. Megeshet azonban, ha olyan szoftvert telepítünk, amelyet nem kifejezetten a &os;-hez terveztek, akkor javítanunk kell a forráskódban a szoftver megfelelõ mûködéséhez. Ha sikerül mûködésre bírni, folytathatjuk &os;-n a szoftver telepítését a megszokott módon. Habár a &os; erre a célra két lehetõséget is felkínál, amivel rengeteg erõfeszítéstõl megkímélhet minket: ezek a csomagok és a portok. Az írás pillanatában közel &os.numports; külsõ alkalmazás érhetõ el ilyen formában. Egy adott alkalmazás esetén a hozzátartozó &os;-s csomag mindössze egyetlen letöltendõ állományt takar. A csomag tartalmazza az alkalmazás telepítéséhez szükséges összes parancs elõre lefordított változtatát, ugyanígy magát a dokumentációt is. A letöltött csomagokat a &os; csomagkezelõ parancsaival vehetjük használatba: ezek a &man.pkg.add.1;, &man.pkg.delete.1;, &man.pkg.info.1; és így tovább. Az új alkalmazások telepítése ennek köszönhetõen egyetlen paranccsal elvégezhetõ. Egy alkalmazás &os;-s portja mögött lényegében állományok gyûjteménye áll, amelyek abban segítenek, hogy automatikusan tudjunk telepíteni a forráskód felhasználásával. Ne felejtsük el, hogy normális esetben számos lépcsõt végig kell járnunk egy program sajátkezû lefordításához (letöltés, kitömörítés, javítgatás, fordítás, telepítés). A portot alkotó állományok tartalmazzák az összes olyan szükséges információt, amelyek átengedik ezt a feladatot a rendszernek. Kiadunk néhány egyszerû parancsot és az alkalmazás magától letöltõdik, kitömörítõdik, módosítja a forráskódját, lefordul és települ. Valójában a portrendszer használható olyan csomagok létrehozására is, amelyeket késõbb a pkg_add és többi hozzá hasonló, hamarosan részletesebben is bemutatandó csomagkezelõ paranccsal is kezelni tudunk. A csomagok és a portok egyaránt képesek függõségeket kezelni. Tegyük fel, hogy egy olyan alkalmazást akarunk telepíteni, amely egy adott függvénykönyvtár meglététõl függ a rendszeren. Az alkalmazás és a könyvtár is elérhetõ &os; portként és csomagként. Akár a pkg_add parancsot, akár a portrendszert használjuk az alkalmazás hozzáadására, mind a kettõ észre fogja venni, hogy a szükséges könyvtárt még nem telepítettük, ezért elõször azt fogja automatikusan telepíteni. Tudván, hogy a két említett megoldás szinte teljesen egyenértékû, felmerülhet a kérdés: a &os; mégis miért rendelkezik mindkettõvel? A csomagoknak és a portoknak is megvannak a maguk elõnyei, és hogy a kettõ közül melyiket használjuk, csak az egyéni ízlésünkön múlik. A csomagok használatának elõnyei Egy csomag általában kisebb, mint az alkalmazás forráskódját tartalmazó tömörített tar állomány. A csomagokat nem kell fordítani. Nagyobb alkalmazások, mint például a Mozilla, KDE vagy GNOME esetén ez kulcsfontosságú lehet, fõleg abban az esetben, ha a rendszerünk ehhez nem eléggé gyors. A csomagok használata nem várja el tõlünk, hogy behatóbban ismerjük miként is kell &os;-n szoftvereket lefordítani. A portok használatának elõnyei A csomagokat általános esetben igen óvatos beállításokkal készítik el, hiszen a lehetõ legtöbb rendszeren mûködõképesnek kell lenniük. Ha viszont portból telepítünk, nyugodtan hangolhatjuk úgy a beállításokat, hogy (például) a &pentium; 4 vagy az Athlon processzoroknak kedvezõ kódot hozzanak létre. Bizonyos alkalmazások fordítás idején állítandó beállításokkal rendelkeznek arról, hogy mire lesznek képesek és mire nem. Például az Apache beépített konfigurációs opciók széles kelléktárával rendelkezik. Amikor viszont portból hozzuk létre, nem kell elfogadnunk ezek alapértelmezett értékeit, hanem a saját igényeinknek megfelelõen átállíthatjuk ezeket. Egyes esetekben több különféle beállítást tükrözõ csomag is létezhet ugyanahhoz az alkalmazáshoz. Például a Ghostscript elérhetõ ghostscript és ghostscript-nox11 csomagként is attól függõen, hogy telepítettük-e az X11 szervert. Ez természetesen egy meglehetõsen durva kijátszása a csomagrendszernek, és gyorsan lehetetlenné is válik a használata, ha az adott alkalmazás egy-két fordítási idejû beállításnál többel rendelkezik. Néhány szoftver licencelése tiltja a bináris terjesztést. Ezért ezek a szoftverek kizárólag csak forráskód formájában továbbíthatóak. Néhányan nem bíznak meg a bináris verziókban. Ha látjuk a forráskódot is, akkor (elméletben) át tudjuk nézni, és mi magunk is megkereshetjük a benne lappangó hibákat. Ha vannak saját javításaink, csak a forráskód birtokában tudjuk ezeket felhasználni. Sokan szeretik, ha egyszerûen csak ott van a szoftverek forráskódja. Ha éppen unatkoznak, beléjük tudnak nézni, ötleteket és kódot tudnak belõlük meríteni (persze csak akkor, ha ezt a licenc megengedi), vagy tovább tudják ezeket fejleszteni, orvosolni tudják a hibáikat stb. A portok frissítésérõl a &a.ports; és a &a.ports-bugs; valamelyikérõl szerezhetünk naprakész információkat. Mielõtt bármelyik alkalmazást is telepítenénk, érdemes meglátogatnunk az oldalt, ahol a hozzátartozó ismert biztonsági problémákról olvashatunk. Telepíthetjük a ports-mgmt/portaudit programot is, amely automatikusan ellenõrzi a telepített alkalmazások ismert sebezhetõségeit. Ez az ellenõrzés egyébként megejthetõ minden port lefordítása elõtt is. Ezalatt a portaudit -F -a parancs kiadásával ellenõrizhetjük utólag a telepített csomagokat. A fejezet fennmaradó részében megmutatjuk, hogyan használjuk &os;-ben a csomagokat és portokat külsõ alkalmazások telepítésére és karbantartására. A számunkra szükséges alkalmazások felkutatása Mielõtt telepítenénk bármilyen alkalmazást, tudnunk kell, hogyan is nevezik. A &os;-hez elérhetõ alkalmazások listája folyamatosan növekszik. Szerencsére számos módja van annak, hogy utánajárjunk a keresett szoftvernek: A &os; honlapján találhatunk egy rendszeresen frissülõ listát az összes elérhetõ alkalmazásról, a http://www.FreeBSD.org/ports/ címen. Itt a portok különbözõ kategóriákba sorolva találhatóak meg, ahol név szerint megkereshetjük az alkalmazást (amennyiben ismerjük), vagy végigböngészhetjük az adott kategóriában elérhetõ alkalmazásokat is. FreshPorts Dan Langlille a címen karbantartja a FreshPorts nevû oldalt. Ezen az oldalon folyamatosan nyomon lehet követni a Portgyûjteményben megtalálható alkalmazások változásait, lehetõvé téve, hogy egy vagy több portot is figyeljünk, vagy e-mailt küldjünk a frissítésükrõl. FreshMeat Amennyiben nem ismerjük a keresett alkalmazás nevét, próbáljuk meg felkutatni a FreshMeaten () vagy hozzá hasonló oldalakon, majd nézzük a &os; honlapján, hogy az adott alkalmazást portolták-e már a rendszerre. Ha pontosan ismerjük a port nevét, és csak a kategóriáját kellene megkeresnünk, használjuk a &man.whereis.1; parancsot. Egyszerûen csak adjuk ki a whereis név parancsot, ahol az név a telepítendõ program neve. Ha sikerült megtalálni, részletes információt kapunk arról, hogy hol található, valahogy így: &prompt.root; whereis lsof lsof: /usr/ports/sysutils/lsof A fenti példában megtudhatjuk, hogy az lsof parancs a /usr/ports/sysutils/lsof könyvtárban található. Vagy egy egyszerû &man.echo.1; paranccsal is megkereshetjük a portfában a portokat. Mint például: &prompt.root; echo /usr/ports/*/*lsof* /usr/ports/sysutils/lsof Ez a módszer a /usr/ports/distfiles + class="directory">/usr/ports/distfiles könyvtárba letöltött összes illeszkedõ állományt is kilistázza. Egy másik lehetõség egy adott port megtalálására, ha a Portgyûjtemény beépített keresési mechanizmusát használjuk. Ennek használatához a /usr/ports könyvtárban kell lennünk. Miután beléptünk ide, futtassuk le a make search name=programnév parancsot, ahol a programnév a keresendõ program neve. Például, ha az lsof programot keressük: &prompt.root; cd /usr/ports &prompt.root; make search name=lsof Port: lsof-4.56.4 Path: /usr/ports/sysutils/lsof Info: Lists information about open files (similar to fstat(1)) Maint: obrien@FreeBSD.org Index: sysutils B-deps: R-deps: A keresés eredményében leginkább a Path: kezdetû sorra kell odafigyelnünk, mivel ez árulja el, hol is találhatjuk meg a portot. Az itt szereplõ többi információ nem szükséges a port telepítéséhez, ezért azokkal itt most nem foglalkozunk. Mélyebb keresésekhez használhatjuk a make search key=szöveg parancsot is, ahol a szöveg a keresendõ szöveg(részlet) lesz. Ezt a rendszer keresni fogja a portok neveiben, megjegyzésekben, leírásokban és függõségekben. Amikor nem ismerjük a keresett program nevét, ez olyan portok keresésére alkalmas, amelyek egy adott témához kapcsolódnak. A fenti esetek mindegyikében a keresés nem különbözteti meg a kis- és nagybetûket. Tehát a LSOF keresése ugyanazt az eredményt adja, mint az lsof esetén. Chern Lee Írta: A csomagrendszer használata Csomagok telepítése csomagok telepítése pkg_add A &man.pkg.add.1; segédprogram segítségével telepíthetünk &os;-hez készült szoftvercsomagokat lokálisan vagy a hálózaton levõ egyik szerveren megtalálható állományokból: Csomagok letöltése manuálisan és telepítése lokálisan &prompt.root; ftp -a ftp2.FreeBSD.org Connected to ftp2.FreeBSD.org. 220 ftp2.FreeBSD.org FTP server (Version 6.00LS) ready. 331 Guest login ok, send your email address as password. 230- 230- This machine is in Vienna, VA, USA, hosted by Verio. 230- Questions? E-mail freebsd@vienna.verio.net. 230- 230- 230 Guest login ok, access restrictions apply. Remote system type is UNIX. Using binary mode to transfer files. ftp> cd /pub/FreeBSD/ports/packages/sysutils/ 250 CWD command successful. ftp> get lsof-4.56.4.tgz local: lsof-4.56.4.tgz remote: lsof-4.56.4.tgz 200 PORT command successful. 150 Opening BINARY mode data connection for 'lsof-4.56.4.tgz' (92375 bytes). 100% |**************************************************| 92375 00:00 ETA 226 Transfer complete. 92375 bytes received in 5.60 seconds (16.11 KB/s) ftp> exit &prompt.root; pkg_add lsof-4.56.4.tgz Ha nincsenek egyáltalán helyben csomagjaink (például egy &os; CD-készletben), akkor a legjobban úgy járunk, ha a használjuk a &man.pkg.add.1; kapcsolóját. Ennek hatására a segédprogram önmagától meghatározza a szükséges állományformátumot és verziót, majd FTP-n keresztül letölti és telepíti a csomagot. pkg_add &prompt.root; pkg_add -r lsof Az iménti példában a program mindenféle további beavatkozás nélkül letölti a megfelelõ csomagot és felteszi. Ha a központi helyett egy másik szervert szeretnénk használni, felül kell bírálnunk az alapértelmezett beállításokat és igényeinknek megfelelõen be kell állítanunk a PACKAGESITE környezeti változó értékét. A &man.pkg.add.1; a &man.fetch.3; programot használja az állományok letöltésére, amely pedig számos egyéb környezeti változót is figyel, mint például az FTP_PASSIVE_MODE, az FTP_PROXY és az FTP_PASSWORD. Ha tûzfal mögött vagyunk, ezek közül néhányat biztosan be kell majd állítanunk, vagy FTP/HTTP proxyt kell használnunk. A &man.fetch.3; man oldalán megtaláljuk ezen változók teljes felsorolását. Figyeljük meg, hogy az lsof-4.56.4 helyett csak lsof-ot adtunk meg. Amikor ugyanis kérjük a csomag letöltését is, nem szabad verziószámot megadnunk. A &man.pkg.add.1; mindig az alkalmazás legfrissebb verzióját fogja letöltetni. Ha a &os.current; vagy &os.stable; verziókat használjuk, a &man.pkg.add.1; mindig az alkalmazás elérhetõ legfrissebb verzióját fogja letölteni. Ha azonban valamelyik -RELEASE verziót használjuk, a csomagnak az adott kiadáshoz készült verzióját fogja leszedni. Ezt a mûködési módot a PACKAGESITE változó felülírásával viszont meg tudjuk változtatni. Például ha a &os; 5.4-RELEASE változatával dolgozunk, a &man.pkg.add.1; alapértelmezés szerint a ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-5.4-release/Latest/ címrõl fogja letölteni a csomagokat. Ha mi viszont a &os; 5-STABLE csomagok letöltését akarjuk elérni, állítsuk az PACKAGESITE értékét a ftp://ftp.freebsd.org/pub/FreeBSD/i386/packages-5-stable/Latest/ címre. A csomagok .tgz és .tbz formátumokban kerülnek terjesztésre. Ezek az címen, vagy pedig a &os; CD-ken találhatóak meg. A 4 CD-bõl álló készlet (illetve a PowerPak stb.) minden CD-jén találhatunk csomagokat a packages/ könyvtárban. A csomagokat tároló könyvtár struktúrája hasonló a /usr/ports könyvtárban kialakított könyvtárfához. Minden kategóriának saját könyvtára van, és minden csomag megtalálható az All (összes) kategóriában. A csomagrendszer könyvtárszerkezete tehát megegyezik a portok szétosztásával, ezáltal így képesek egymással összedolgozni a teljes csomag/port rendszer megformálásában. A csomagok kezelése csomagok kezelés A &man.pkg.info.1; egy olyan segédprogram, amellyel készíteni lehet egy listát a telepített csomagokról, és emellett még más egyéb információkat tudhatunk meg róluk. pkg_info &prompt.root; pkg_info cvsup-16.1 A general network file distribution system optimized for CV docbook-1.2 Meta-port for the different versions of the DocBook DTD ... A &man.pkg.version.1; összefoglalja az összes telepített csomag verzióját. Ezenkívül össze is hasonlítja a csomagok verzióját a portfában található aktuális verziókéval. pkg_version &prompt.root; pkg_version cvsup = docbook = ... A második oszlopban látható jelek utalnak a telepített verzió a helyi portfában található verzióéhoz viszonyított korára. Jel Jelentés = A telepített csomag verziója megegyzik a helyi portfában található verziójával. < A telepített verzió a portfában levõnél régebbi. > A telepített verzió újabb, mint a portfában található. (A helyi portfa valószínûleg nem lett frissítve.) ? A telepített csomag nem található a portok között. (Ez akkor történhet meg, amikor például egy portot eltávolítottak a Portgyûjteménybõl vagy átnevezték.) * A csomagnak több verziója is jelen van. ! A telepített csomag szerepel az indexben, de a pkg_version valamiért nem volt képes összehasonlítani a verziószámát az indexben levõ bejegyzéssel. Csomagok törlése pkg_delete csomagok törlés Egy korábban már telepített csomag eltávolításához használjuk a &man.pkg.delete.1; segédprogramot. &prompt.root; pkg_delete xchat-1.7.1 A &man.pkg.delete.1; használatánál szükség van a csomag teljes nevének és verziószámának megadására. A fenti parancs tehát nem mûködik, ha csak az xchat-et adjuk meg az xchat-1.7.1 helyett. A telepített csomag verzióját azonban könnyedén kitalálhatjuk a &man.pkg.version.1; alkalmazásával. Esetleg egyszerûen dzsókerkaraktereket is használhatunk: &prompt.root; pkg_delete xchat\* Ebben az esetben az összes xchat-tel kezdõdõ csomagot letörli. Egyebek A csomagokra vonatkozó összes információ a /var/db/pkg könyvtárban található. Az egyes csomagok leírása és hozzájuk telepített állományok listája az ezen a könyvtáron belül elhelyezkedõ állományokban tárolódik. A Portgyûjtemény használata A most következõ szakaszokban megismerhetjük azokat az alapvetõ utasításokat, amelyekkel a Portgyûjteményen keresztül tudunk programokat telepíteni és eltávolítani. Az ehhez használható make targetek és környezeti változók részletesebb leírását a &man.ports.7; man oldalán lelhetjük meg. A Portgyûjtemény beszerzése Mielõtt bármelyik portot is tudnánk telepíteni, elsõként magát a Portgyûjteményt kell megszereznünk — ez lényegében a /usr/ports könyvtárban megtalálható Makefile állományok, javítások és leírások gyûjteménye. A &os; telepítése közben a sysinstall rákérdez a Portgyûjtemény telepítésére is. Ha erre nemet válaszoltunk volna, a portok gyûjteményét az alábbi módokon szerezhetjük be: A CVSup használatával A CVSup protokoll használatával viszonylag gyorsan el tudjuk érni és naprakészen tudjuk tartani a Portgyûjtemény egy példányát. A CVSup használatát alaposabban a A CVSup használata címû függelékben ismerhetjük meg. A &os; 6.2 változatától kezdve az alaprendszerben a CVSup protokollt a csup valósítja meg. A &os; korábbi változatának használói ezt a programot a net/csup porton vagy csomagon keresztül tudják telepíteni. Gondoskodjunk róla, hogy a /usr/ports üres legyen a + class="directory">/usr/ports üres legyen a csup elsõ futtatása elõtt! Ha más forrásból raktuk ide a Portgyûjteményt, a csup nem fogja lenyesegetni az azóta eltávolított javításokat. Futtassuk a csup programot: &prompt.root; csup -L 2 -h cvsup.FreeBSD.org /usr/share/examples/cvsup/ports-supfile Itt írjuk át a cvsup.FreeBSD.org címét a hozzánk legközelebb levõ CVSup szerver címére. Az összes elérhetõ tükörszerver címét a CVSup tükrözések () címû részben olvashatjuk. Ha például el akarjuk kerülni a CVSup szerver megadását a parancssorban, akkor mindenképpen a ports-supfile állományból érdemes készíteni egy saját verziót. Ebben az esetben root felhasználóként másoljuk a /usr/share/examples/cvsup/ports-supfile állományt egy új helyre, például a /root könyvtárba vagy a saját felhasználói könyvtárunkba. Szerkesszük át a ports-supfile állományt. Írjuk át a CHANGE_THIS.FreeBSD.org értéket a hozzánk legközelebb található CVSup szerverére. A CVSup tükrözések () címû részben megtaláljuk az összes ilyen tükörszervert. És most indítsuk el a csup parancsot az alábbi módon: &prompt.root; csup -L 2 /root/ports-supfile A &man.csup.1; parancs késõbbi futása során már letölti és érvényesíti az észlelt változtatásokat a saját Portgyûjteményünkben, de a telepített portokat viszont nem fogja újrafordítani. A Portsnap használatával A Portsnap egy másik módszert képvisel a Portgyûjtemény terjesztésére. Elõször a &os; 6.0-ás verziójában jelent meg. A régebbi rendszereken a ports-mgmt/portsnap csomag telepítésével válik elérhetõvé: &prompt.root; pkg_add -r portsnap A Portsnap lehetõségeinek részletesebb megismeréséhez tekintsük át A Portsnap használata címû szakaszt. Mivel a &os; 6.1-RELEASE és az utána következõ verziók már alapból tartalmazzák a Portsnap portot vagy csomagot, nyugodtan kihagyhatjuk a most következõ lépést. A /usr/ports könyvtár + class="directory">/usr/ports könyvtár magától létrejön a &man.portsnap.8; parancs elsõ futtatása során. A Portsnap korábbi verziói esetén viszont, ha nem létezett, elõzetesen készíteni - kellett egy + kellett egy könyvtárat: &prompt.root; mkdir /usr/ports Töltsük le a Portgyûjtemény tömörített pillanatképét a - /var/db/portsnap + /var/db/portsnap könyvtárba. Ha akarjuk, ezután a lépés után már lekapcsolódhatunk az internetrõl. &prompt.root; portsnap fetch Ha még csak elõször futtatjuk a Portsnapet, bontsuk ki az imént letöltött állapotot a - /usr/ports + /usr/ports könyvtárba: &prompt.root; portsnap extract Ha viszont már korábban is létezett - a /usr/ports + a /usr/ports könyvtárunk és most csak frissítjük, akkor helyette ezt a parancsot adjuk ki: &prompt.root; portsnap update A <application>sysinstall</application> használatával Ebben az esetben a sysinstall nevû programmal telepítjük a Portgyûjteményt valamilyen telepítõeszközrõl. Ilyenkor azonban a kiadás dátumának megfelelõ, valószínûlég régebbi változat kerül fel. Ha rendelkezünk internet-hozzáféréssel, akkor inkább az elõbb tárgyalt módszerek valamelyikét alkalmazzuk. root felhasználóként adjuk ki a sysinstall (vagy a &os; 5.2 elõtti verzióban a /stand/sysinstall) parancsot, ahogy itt is láthatjuk: &prompt.root; sysinstall Menjünk le és álljunk meg a Configure (Beállítások), menüpontnál, és nyomjunk Enter billentyût. Menjünk le és keressük meg a Distributions (Terjesztések) menüponot, majd nyomjunk meg az Enter billentyût. Menjünk le, válasszuk ki a ports elemet a Szóköz megnyomásával. Menjünk fel az Exit (Kilépés) ponthoz, nyomjunk meg az Enter billentyût. Válasszuk ki a telepítéshez használni kívánt eszközt, mint például CD, FTP stb. Menjünk fel az Exit (Kilépés) menüpontig, majd nyomjunk meg az Enter billentyût. Végezetül lépjünk ki a sysinstall programból, aminhez nyomjunk meg az X billentyût. Portok telepítése portok telepítés A váz fogalma az elsõ, amit a Portgyûjteménnyel kapcsolatban tisztázni kell. Dióhéjban összefoglalva, egy port váza azon állományok legszûkebb halmaza, amelyek elárulják a &os; számára, hogyan fordítsuk le hibamentesen és hogyan telepítsük az adott programot. Ehhez minden port vázában megtalálható: Egy Makefile nevû állomány. Ez tartalmazza azokat a különbözõ utasításokat, amelyek megmondják, hogyan kell lefordítani és hova kell telepíteni a rendszerünkben az adott alkalmazást. Egy distinfo nevû állomány. Ebben található információ a port lefordításához szükséges állományok letöltésérõl, valamint a letöltött állományok ellenõrzéséhez szükséges (az &man.md5.1; és &man.sha256.1; programokkal számolt) ellenõrzõösszegek. Egy files alkönyvtár. Itt találhatjuk meg azokat a javításokat, amelyek alkalmazásával le tudjuk fordítani a programot &os;-n is. Ezek a javítások többnyire bizonyos állományok módosításaira vonatkozó apró állományok formájában jelennek meg. Természetüknél fogva szöveges formátumúak, és általában olyanok szerepelnek bennük, hogy Töröld a 10. sort vagy Változtasd meg a 26. sort erre: .... Ezeket a javításokat eredetileg patcheknek (foltoknak) nevezik, vagy másképp diffeknek (eltéréseknek) is, mivel a &man.diff.1; program segítségével hozzák ezeket létre. Ez a könyvtár tartalmazhat további állományokat is portok elkészítéséhez. Egy pkg-descr nevû állomány. Ez a program részletesebb, gyakran többsoros bemutatása. Egy pkg-plist nevû állomány. Itt találjuk meg a port által telepítendõ összes állományt. Ez egyben közli a portrendszerrel is, hogy az eltávolítás során mely állományokat kell majd törölnie. Egyes portokban szereplhetnek még egyéb állományok is, mint például a pkg-message. Ezeket az állományokat a portrendszer különleges helyzetek kezelésére tartogatja. Ha még többet kívánunk megtudni ezekrõl az állományokról, vagy magukról a portokról általánosságban, lapozzuk fel a &os; porterek kézikönyvét. A port ugyan tartalmazza a forráskód lefordításához szükséges utasításokat, de konkrétan a forráskódot viszont nem. Ezt egy CD-rõl vagy az internetrõl tudjuk megszerezni. A forráskód általában a szerzõje által kedvelt formában jelenik meg: ez gyakran egy gzip-pel tömörített tar állomány, de lehet tömörítve mással is, vagy éppen lehet tömörítetlen. A program forráskódját, legyen akármilyen formában is, nevezik distfile-nak (terjesztési állománynak). A &os; portok telepítésének két módszerét tárjuk fel a következõkben. A portok telepítéséhez root felhasználóként kell bejelentkeznünk. Mielõtt telepítenénk bármelyik portot is, ajánlott frissíteni a Portgyûjteményünket és ellenõriznünk az adott portot a címen található biztonsági adatbázisban. Az újonnan telepítendõ alkalmazások biztonsági sebezhetõségeinek ellenõrzését automatikussá is tehetjük a portaudit használatával. Ez a segédeszköz is a Portgyûjteményben található (ports-mgmt/portaudit). Érdemes minden port telepítése elõtt letöltenünk a legfrissebb sebezhetõségi adatbázist a portaudit -F parancs kiadásával. Mellesleg az adatbázis rendszeres frissítése és ez a biztonsági felülvizsgálat a naponként elvégzendõ biztonsági ellenõrzések közt is megjelenik. Ezekrõl részletesebben a &man.portaudit.1; és &man.periodic.8; man oldalakon olvashatunk. A Portgyûjtemény feltételezi, hogy mûködõ internet-hozzáféréssel rendelkezünk. Amennyiben ez nem így lenne, a terjesztési állományokat, forráskódokat saját magunknak kell bemásolnunk a /usr/ports/distfiles könyvtárba. A kezdéshez lépjünk be a telepítendõ port könyvtárába: &prompt.root; cd /usr/ports/sysutils/lsof Miután beléptünk az lsof könyvtárába, láthatjuk a port vázát. A következõ lépés a fordítás avagy a port buildelése (elkészítése). Ezt egy szimpla make parancs kiadásával kezdeményezhetjük. Miután megtettük, valami ilyesmit kell tapasztalnunk: &prompt.root; make >> lsof_4.57D.freebsd.tar.gz doesn't seem to exist in /usr/ports/distfiles/. >> Attempting to fetch from ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/. ===> Extracting for lsof-4.57 ... [ide jön a kitömörítés kimenete] ... >> Checksum OK for lsof_4.57D.freebsd.tar.gz. ===> Patching for lsof-4.57 ===> Applying FreeBSD patches for lsof-4.57 ===> Configuring for lsof-4.57 ... [ide jön a configure szkript kimenete] ... ===> Building for lsof-4.57 ... [ide jön a fordítás kimenete] ... &prompt.root; A fordítás befejeztével visszakapjunk a parancssort. A soron következõ lépés a port telepítése lesz. Ehhez mindössze egyetlen szóval kell kiegészítenünk a make parancs meghívását: ez a szó pedig az install (telepít) lesz. &prompt.root; make install ===> Installing for lsof-4.57 ... [a telepítés kimenete kimarad] ... ===> Generating temporary packing list ===> Compressing manual pages for lsof-4.57 ===> Registering installation for lsof-4.57 ===> SECURITY NOTE: This port has installed the following binaries which execute with increased privileges. &prompt.root; Miután ismét visszakaptuk a parancssort, már futtatni is tudjuk a frissen telepített alkalmazásunkat. Mivel az lsof programnak tovább jogosultságokra is szüksége van, egy errõl szóló biztonsági figyelmeztetést is láthatunk. A portok létrehozása és telepítése során érdemes figyelnünk az ehhez hasonló figyelmeztetésekre. A telepítés befejeztével nem árt törölnünk a fordításhoz felhasznált alkönyvtárat (work) is. Ezzel nemcsak a drága lemezterületet spóroljuk meg, hanem megelõzzük a port késõbbi frissítése során felmerülõ esetleges problémákat is. &prompt.root; make clean ===> Cleaning for lsof-4.57 &prompt.root; Az eljárásból két lépést meg is tudunk takarítani, ha egyszerûen csak a make install clean parancsot adjuk ki az elõbb három lépésben tagolt make, make install és make clean parancsok helyett. Bizonyos parancsértelmezõk a PATH környezeti változóban felsorolt könyvtárakban található parancsokat gyorsítótárban tárolják, ezzel felgyorsítva a hozzájuk tartozó végrehajtható állományok keresését. Ha történetesen ilyen parancsértelmezõt használnánk, az új portok telepítése után szükségünk lehet a rehash parancs kiadására, mivel enélkül nem tudjuk elérni a frissen telepített parancsokat. Ezt a parancsot például a tcsh és a hozzá hasonló parancsértelmezõkben találhatjuk meg, az sh és rokonainál pedig a hash -r ennek a megfelelõje. A pontos információkat errõl a témáról a parancsértelmezõnk dokumentációjában lelhetjük meg. Némely külsõ DVD termék, mint például a &os; Malltól megrendelhetõ &os; Toolkit, tartalmazhatnak terjesztési állományokat. Ezek remekül használhatóak a Portgyûjteménnyel. Ehhez csatlakoztatnunk kell a DVD-t a /cdrom könyvtárba. Ettõl eltérõ csatlakozási pontok használata esetén ne felejtsük el átállítani a CD_MOUNTPTS változót sem a make számára. Ekkor a fordításhoz szükséges állományokat úgy fogja kezelni a rendszer, mintha a merevlemezünkön lennének. Vigyázzunk arra, hogy néhány portot nem lehet CD-n terjeszteni. Ez részben azért lehet, mert a szükséges állományok letöltéséhez, illetve újbóli terjesztéséhez ki kell tölteni valamilyen regisztrációs nyomtatványt, vagy pedig egyéb okok miatt. Tehát ha olyan portot akarunk telepíteni, ami nincs rajta a CD-n, mindenképpen rendelkeznünk kell internetkapcsolattal. A portrendszer a &man.fetch.1; segédprogramot használja az állományok letöltésére, amely figyelembevesz különféle környezeti változókat, ilyenek többek közt az FTP_PASSIVE_MODE, FTP_PROXY és az FTP_PASSWORD. Ha tûzfal mögött vagyunk, szükségünk lehet ezek némelyikének helyes beállítására, vagy FTP/HTTP proxyt kell használnunk. A &man.fetch.3; man oldala tartalmazza ezen változók teljes listáját. A make fetch azon felhasználók számára nyújt segítséget, akik nem csatlakoznak minden esetben a hálózatra. Egyszerûen csak futtassuk le a könyvtárszerkezet legtetejérõl (/usr/ports) ezt a parancsot és a szükséges állományok letöltõdnek nekünk. A parancs mûködik az alsóbb szinteken is, például a /usr/ports/net könyvtárban. Azonban legyünk tekintettel arra, hogy ha egy port függ más portoktól vagy függvénykönyvtáraktól, ez a parancs nem fogja letölteni a hozzájuk tartozó állományokat. Ilyenkor a fetch helyett használjuk a fetch-recursive targetet. Ha a make parancsot egy felsõbb szinten futtatjuk, akkor ezzel létre tudjuk hozni az összes vagy csak kategóriánként az összes portot, hasonlóan az elõbb említett make fetch módszerhez. Ez azonban veszélyes, mivel egyes portok kizárják mások használatát. Emellett elõfordulhat az is, hogy bizonyos portok ugyanazon a néven telepítenek több, tartalmukban különbözõ állományt. Nagyon ritkán adódhat, hogy a felhasználónak nem a MASTER_SITES által mutatott helyekrõl kell beszereznie a szükséges állományokat (innen töltõdnek ugyanis le). A MASTER_SITES beállítást az alábbi paranccsal bírálhatjuk felül: &prompt.root; cd /usr/ports/könyvtár &prompt.root; make MASTER_SITE_OVERRIDE= \ ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/ fetch Ebben a példában a MASTER_SITES értékét a ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/ címre változtattuk meg. A portok némelyike lehetõvé teszi (esetleg meg is követeli), hogy engedélyezzük vagy letiltsuk a készülõ program bizonyos elemeit hatékonysági, biztonsági vagy egyéb testreszabási irányelvek mentén. Ilyen többek közt a www/mozilla, a security/gpgme és a mail/sylpheed-claws. Ha elérhetõek ilyen beállítási lehetõségek, arról a rendszer egy üzenetben tájékoztat minket. Az alapértelmezett könyvtárak felülbírálása Néha hasznos (vagy kötelezõ) lehet eltérõ munka- és célkönyvtárak alkalmazása. A WRKDIRPREFIX és a PREFIX változókkal ezek alapértelmezéseit tudjuk megváltoztatni. Például a &prompt.root; make WRKDIRPREFIX=/usr/home/example/ports install parancs a portot a /usr/home/example/ports könyvtárban fogja lefordítani és az eredményét a /usr/local könyvtárba telepíti. A &prompt.root; make PREFIX=/usr/home/example/local install parancs hatására a port a /usr/ports könyvtárban készül el és a /usr/home/example/local könyvtárba települ. Természetesen a &prompt.root; make WRKDIRPREFIX=../ports PREFIX=../local install parancs ötvözi az elõbbi kettõt (amelyet most túlságosan is hosszú lenne kiírni, de vélhetõen sejthetõ belõle az alapötlet). Lehetõség van ezen változókat a saját környezetünkben is beállítani. Ha erre lenne szükségünk, nézzünk utána az ezzel kapcsolatos teendõnek a parancsértelmezõnk man oldalán. Az <command>imake</command> használatáról Bizonyos portok az (X Window System részeként megjelenõ) imake segédprogramra támaszkodnak, ahol viszont nem mûködik a PREFIX átállítása és mindenképpen a /usr/X11R6 könyvtárba akar telepíteni. Ehhez hasonlóan egyes Perl portok figyelmen kívül hagyják a PREFIX változót és közvetlenül a Perl fájába kerülnek. Az ilyen portok esetén nagyon nehéz vagy szinte lehetetlen betartatni a PREFIX használatát. A portok újrakonfigurálása Egyes portok lefordítása elõtt megjelenik egy ncurses alapú menü, ahol ki tudunk választani bizonyos fordítási beállításokat. Gyakran elõfordul, hogy a port lefordítása után a felhasználók szeretnék újra elõhozni ezt a menüt és megadni vagy kivenni bizonyos beállításokat. Erre több mód is kínálkozik. Egyik ilyen lehetõség az, ha belépünk a port könyvtárába és kiadjuk a make config parancsot, amivel lényegében ismét elõcsaljuk a beállításokat összefoglaló menüt. Másik ilyen lehetõség a make showconfig alkalmazása, amivel a porthoz tartozó összes beállítást tudjuk egyszerre megjeleníteni. Ezek mellett még használható a make rmconfig parancs is, amivel törölni tudjuk az összes eddigi beállítást és így újrakezdhetjük a port konfigurációját. Ezek és a többi ilyen opció a &man.ports.7; man oldalon kerül bõvebb kifejtésre. A portok eltávolítása portok eltávolítás Most már tudjuk, miként lehet portokat telepíteni, azonban valószínûleg még az is érdekelhet minket, hogy miként kell ezeket eltávolítani abban az esetben, ha például késõbb meggondolnánk magunkat velük kapcsolatban. A korábban telepített példaportot fogjuk eltávolítani (a figyelmetlenek kedvéért megemlítjük, hogy ez az lsof volt). A portok eltávolítása teljesen egybevág a csomagokéval (errõl a csomagokról szóló részben beszéltünk), mivel ekkor is használhatjuk a &man.pkg.delete.1; parancsot: &prompt.root; pkg_delete lsof-4.57 A portok frissítése portok frissítés Elõször is a &man.pkg.version.1; parancs felhasználásával listázzuk ki azokat a portokat, amik felett már eljárt az idõ és a Portgyûjteményben található belõlük újabb verzió: &prompt.root; pkg_version -v A <filename>/usr/ports/UPDATING</filename> állomány Miután frissítettük a Portgyûjteményünket, de még mielõtt megpróbálnánk akármelyik portot is frissíteni, érdemes egy pillantást vetnünk a /usr/ports/UPDATING állományra. Itt megtalálhatóak azok a problémák és a hozzájuk tartozó lépések, amelyekkel a felhasználóknak a portok frissítése során szembe kell nézniük, beleértve az állományformátumok, a konfigurációs állományok helyének megváltozását vagy egyéb olyan módosításokat, amik a korábbi verziókkal összeférhetetlenséget szülhetnek. Amennyiben az UPDATING állomány tartalma ellentmondana az itt olvasottakkal, mindig az UPDATING állományban leírtak az irányadóak. Portok frissítése a <application>portupgrade</application> használatával portupgrade A portupgrade nevû segédprogramot a portok egyszerûbb frissítésére találták ki, és a ports-mgmt/portupgrade portban található meg. A make install clean paranccsal bármelyik más porthoz hasonlóan telepíthetjük: &prompt.root; cd /usr/ports/ports-mgmt/portupgrade &prompt.root; make install clean A pkgdb -F paranccsal fésültessük át a telepített portok listáját, és javítsuk az általa jelentett ellentmondásokat. Érdemes rendszeresen elvégezni ezt, lehetõleg minden frissítés elõtt. Miután kiadtuk a portupgrade -a parancsot, a portupgrade nekilát frissíteni az összes elavult portot a rendszerünkben. Ha minden egyes frissítést külön meg szeretnénk erõsíteni, használjuk a kapcsolót is. &prompt.root; portupgrade -ai Ha nem akarjuk az összes portot frissíteni, csupán egy bizonyos alkalmazásét, használjuk a portupgrade pkgname paraméterezést. A kapcsoló megadásával a portupgrade elõször frissíti az adott alkalmazás függõségeit. &prompt.root; portupgrade -R firefox Ha a mûvelet során csomagokat kívánunk használni portok helyett, adjuk meg a kapcsolót. Ennek révén a portupgrade megkeresi a csomagokat a PKG_PATH környezeti változóban felsorolt könyvtárakban vagy ha itt nem találja, letölti ezeket egy távoli szerverrõl. Amennyiben a csomagokat sem helyben, sem pedig a távoli szerveren nem találja, a portupgrade helyettük portokat fog használni. Ilyenkor a portok használatát a kapcsoló beállításával lehet elkerülni: &prompt.root; portupgrade -PP gnome2 Csak a terjesztési állományok (vagy a esetén csomagok) letöltéséhez használjuk a kapcsolót. Mindezekrõl részletesebben a &man.portupgrade.1; man oldalon olvashatunk. Portok frisstse a <application>Portmanager</application> használatával portmanager A Portmanager egy másik hasznos segédprogram a portok könnyû frissítéséhez. A ports-mgmt/portmanager porton keresztül érhetõ el: - &prompt.root; cd /usr/ports/ports-mgmt/portmanager + &prompt.root; cd /usr/ports/ports-mgmt/portmanager &prompt.root; make install clean Használatával az összes telepített port egyetlen paranccsal frissíthetõ: &prompt.root; portmanager -u Ha a Portmanager minden egyes lépését külön meg kívánjuk erõsíteni, akkor a kapcsolókat se felejtsük el megadni. A Portmanager emellett új portok telepítésére is használható. Eltérõen a make install clean parancsban megszokottaktól, a kiválasztott port összes függõségét még a fordítás és a telepítés elõtt fogja frissíteni. &prompt.root; portmanager x11/gnome2 Ha bármilyen gondot tapasztalnánk a kiválasztott port függõségeit illetõen, a Portmanagert felkérhetjük az összes függõség helyes sorrendben történõ újrafordítására. Amikor befejezte, a problémás portot is újra létrehozza. &prompt.root; portmanager graphics/gimp -f Bõvebb információkért lásd &man.portmanager.1;. Portok frissítése a <application>Portmaster</application> használatával portmaster A Portmaster szintén a portok frissítésére alkalmas segédprogram. A Portmaster esetében a hangsúly az alaprendszerben is megtalálható eszközök használatán van (tehát nem függ semmilyen más porttól) és a /var/db/pkg/ könyvtárban található információk alapján dönti el, hogy milyen portokat kell frissítenie. A ports-mgmt/portmaster portból érhetõ el: - &prompt.root; cd /usr/ports/ports-mgmt/portmaster + &prompt.root; cd /usr/ports/ports-mgmt/portmaster &prompt.root; make install clean A Portmaster a portokat az alábbi négy kategória valamelyikébe sorolja be: Gyökér (root) portok (nem függenek semmitõl, semmi sem függ tõlük) Törzs (trunk) portok (nem függenek semmitõl, de mások függenek tõlük) Ág (branch) portok (vannak függõségeik és mások is függenek tõlük) Levél (leaf) portok (vannak függõségeik, de semmi sem függ tõlük) A következõ paranccsal le tudjuk kérni az összes telepített portot és az kapcsolóval frissítéseket keresni hozzájuk: &prompt.root; portmaster -L ===>>> Root ports (No dependencies, not depended on) ===>>> ispell-3.2.06_18 ===>>> screen-4.0.3 ===>>> New version available: screen-4.0.3_1 ===>>> tcpflow-0.21_1 ===>>> 7 root ports ... ===>>> Branch ports (Have dependencies, are depended on) ===>>> apache-2.2.3 ===>>> New version available: apache-2.2.8 ... ===>>> Leaf ports (Have dependencies, not depended on) ===>>> automake-1.9.6_2 ===>>> bash-3.1.17 ===>>> New version available: bash-3.2.33 ... ===>>> 32 leaf ports ===>>> 137 total installed ports ===>>> 83 have new versions available Az összes telepített port egyetlen egyszerû paranccsal frissíthetõ: &prompt.root; portmaster -a A Portmaster alapértelmezés szerint minden egyes törlendõ korábbi portról biztonsági másolatot készít. Amikor az új változat telepítése sikeresen lezajlott, akkor a Portmaster ezt a másolatot megsemmisíti. A paraméterrel azonban megkérhetjük, hogy ne törölje le a biztonsági mentést. Az megadásával a Portmaster interaktív módban indul el, és minden port frissítése elõtt a felhasználó megerõsítését fogja kérni. Amennyiben valamilyen hiba lép fel a frissítés folyamán, az opció megadásával kérhetjük az összes port frissítését és újrafordítását is: &prompt.root; portmaster -af A Portmaster használatával új portokat is fel tudunk telepíteni a rendszerre úgy, hogy azok függõségeit is igyekszik frissíteni a lefordításuk elõtt: &prompt.root; portmaster shells/bash A további részleteket a &man.portmaster.8; man oldalon találjuk. A portok tárigénye portok tárigény A Portgyûjtemény idõvel egyre több helyet fog elfoglalni a merevlemezünkön. Miután sikeresen létrehoztunk és telepítettünk egy szoftvert a hozzátartozó portból, érdemes mindig eltakarítanunk magunk után a work könyvtárban menet közben keletkezett átmeneti állományokat a make clean parancs használatával. Az egész Portgyûjteményt egyetlen mozdulattal ezzel a paranccsal tudjuk végigsepregetni: &prompt.root; portsclean -C Az idõ elõrehaladtával a distfiles könyvtárban is rengeteg régi forrás tud felhalmazódni. Ezeket eltávolíthatjuk kézzel, vagy az alábbi parancs segítségével törölhetjük az összes olyan terjesztési állományt, amelyekre már egyetlen port sem hivatkozik: &prompt.root; portsclean -D Vagy törölhetjük az összes olyan terjesztési állományt, amelyre egyetlen pillanatnyilag feltelepített port sem hivatkozik a rendszerünkben: &prompt.root; portsclean -DD A portsclean segédprogram a portupgrade programcsomag része. Ne felejtsük el eltávolítani azokat a portokat, amikre már nincs szükségünk a továbbiakban. Ebben a feladatban egy jól használható segédeszköz lehet a segítségünkre, a ports-mgmt/pkg_cutleaves port. Telepítés utáni teendõk Az új alkalmazás feltelepítése után minden bizonnyal szeretnénk elolvasni a hozzá társított dokumentációt, az egyedi beállításainknak megfelelõen módosítani a konfigurációs állományokat, engedélyezni a rendszerindítás során történõ automatikus indítását (ha démonról lenne szó) és így tovább. Az egyes alkalmazások beállításához elvégzendõ lépések nyilvánvalóan egyedenként eltérõek. Azonban tudunk szolgálni néhány általános tanáccsal válaszként az ilyenkor felmerülõ Na és akkor most mi legyen? kérdésre: Kérdezzük meg a &man.pkg.info.1; programtól, milyen állományok és hova kerültek fel a telepítés során. Például, ha a SzuperCsomag 1.0.0-át raktunk fel, akkor a &prompt.root; pkg_info -L SzuperCsomag-1.0.0 | less parancs kilistázza az összes állományt, amit a csomagból felraktunk. Ezek közül leginkább a man/ könyvtárban levõekre figyeljünk, mivel ezek lesznek az alkalmazás man oldalai. Ehhez hasonlóan a etc/ könyvtárban a konfigurációs állományok és a doc/ könyvtárban pedig a nagyobb lélegzetvételû dokumentációk foglalnak helyet. Ha nem emlékszünk pontosan rá, hogy az alkalmazások melyik verzióját is telepítettük, a &prompt.root; pkg_info | grep -i SzuperCsomag alakú parancs megkeresi az összes olyan csomagot, aminek a nevében szerepel a SzuperCsomag szövegrészlet. A fenti példában természetesen igény szerint változtassuk meg a SzuperCsomag szöveget a tényleges csomag nevére. Ahogy sikerült megtalálnunk az alkalmazáshoz tartozó man oldalakat, lapozzuk fel ezeket a &man.man.1; segítségével. Ugyanígy nézzük át a mellékelt minta konfigurációs állományokat és az összes elérhetõ dokumentációt. Ha az alkalmazásnak van saját honlapja, kutassunk ott is információk után, olvassuk el a gyakran ismételt kérdéseket és így tovább. Ha nem tudnánk pontosan a honlap címét, a &prompt.root; pkg_info SzuperCsomag-1.0.0 kimenetébõl könnyen elõkeríthetõ. Itt egy WWW: kezdetû sort kell keresnünk (már amennyiben létezik), amit az alkalmazás honlapjának címe kell kövessen. A rendszerrel együtt indítandó portok (ilyenek többek közt az internetes szolgáltatások), általában a /usr/local/etc/rc.d könyvtárba rakják a saját indítószkriptjüket. Érdemes leellenõrizni ezt a szkriptet és az igényeinknek megfelelõen módosítani, átnevezni. A Szolgáltatások indítása címû szakaszban ezt részleteiben is megismerhetjük. Teendõ a sérült portokkal Ha véletlenül ráakadnánk egy olyan portra, ami nem mûködik megfelelõen, nagyjából a következõket tudjuk tenni: Derítsük ki a Hibajelentések adatbázisából, hogy készül-e már javítás az adott porthoz. Ha igen, akkor annak befejezése után már képesek leszünk használni. Kérjük meg a port karbantartóját, hogy segítsen. A karbantartó elérhetõségének felderítéséhez gépeljük be a make maintainer parancsot, vagy keressük meg a Makefile állományban a karbantartó e-mail címét. Ne felejtsük el neki megemlíteni a levélben a port nevét és verzióját (vagyis mindenképpen küldjük el a $FreeBSD: sort a Makefile állományból) és a parancs kiadásától a hiba felbukkanásáig tartó kimenetet. Némely portokat nem egyedülálló személyek tartanak karban, hanem egy levelezési lista. A legtöbbjük neve, ha nem is mindé, nagyjából ilyen alakú: freebsd-listanév@FreeBSD.org. Egy ilyen jellegû kérdés megfogalmazása során ezt is vegyük figyelembe! Kifejezetten a freebsd-ports@FreeBSD.org karbantartóval rendelkezõ portoknak nincs rendes gazdája. A hozzájuk kapcsolódó javítások és mindenféle segítség, ötlet errõl a levelezési listáról érkeznek. Ilyen esetekben számítunk az önkéntes segítõkre! Ha nem kapunk semmilyen választ, a hiba bejelentésére használhatjuk a &man.send-pr.1; programot is (errõl bõvebben lásd a &os;-s hibajelentések írása címû cikket). Javítsuk meg mi magunk! A porterek kézikönyve részletesen taglalja a portok belsõ felépítését, így onnan elindulva akár magunktól is meg tudunk javítani egy esetlegesen sérült portot, vagy be is küldhetjük a sajátunkat! Töltsük le a porthoz tartozó csomagot a hozzánk legközelebb levõ FTP oldalról. A központi csomaggyûjtemény a ftp.FreeBSD.org címen, a packages nevû könyvtárban található, de mielõtt ide fordulnánk, nézzük meg a hozzánk legközelebb levõ tükörszervert is! Ha egy csomagot így telepítünk, akkor több eséllyel fog mûködni és ráadásul még jóval gyorsabb is. A csomag telepítésére használjuk a &man.pkg.add.1; programot. diff --git a/hu_HU.ISO8859-2/books/handbook/printing/chapter.sgml b/hu_HU.ISO8859-2/books/handbook/printing/chapter.sgml index 1073046038..181b795e14 100644 --- a/hu_HU.ISO8859-2/books/handbook/printing/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/printing/chapter.sgml @@ -1,6926 +1,6926 @@ Sean Kelly Írta: Jim Mock Átdolgozta és frissítette: Nyomtatás Áttekintés LPD nyomtatási rendszer nyomtatás A &os; képes rengeteg féle és fajta nyomtatóval együttmûködni, a legrégebbi vegyszeres nyomtatótól kezdve egészen napjaink lézernyomtatójáig, aminek köszönhetõen alkalmazásaikkal nagyon jó minõségû nyomtatásokat tudunk készíteni. A &os; a helyi hálózaton nyomtatószervernek is beállítható. Ekkor a vele közös hálózatra csatlakozó többi, &os;, &windows; vagy &macos; rendszerû számítógéptõl képes nyomtatási kéréseket elfogadni. A &os; gondoskodik róla, hogy egyszerre csak egy nyomtatás készüljön el, számon tartja, hogy mely felhasználók és számítógépek nyomtatnak a legtöbbet, és minden feladathoz munkalapot (banner page) készít, amiben többek közt megtalálhatjuk, hogy kihez tartozik. A fejezet elolvasása során megismerjük: hogyan állítsuk be a &os; nyomtatási sorát; hogyan telepítsünk nyomtatási szûrõket, hogyan kezeljünk különbözõ speciális nyomtatási feladatokat, tehát például miként alakítsuk át a beérkezõ dokumentumokat olyan nyomtatási formátumra, amelyet a nyomtatónk is megért; hogyan engedélyezzük a fejléc- vagy munkainformációk kinyomtatását; hogyan nyomtassunk más számítógépekhez csatlakoztatott nyomtatókkal; hogyan nyomtassunk a hálózatra közvetlenül kapcsolt nyomtatókkal; hogyan állítsuk be a nyomtató korlátait, például a nyomtatási munkák méretét, amivel egyes felhasználók nyomtatását visszafoghatjuk; hogyan készítsünk nyomtatási kimutatásokat és nyilvántartást a nyomtató használatáról; hogyan keressük meg a nyomtatás során felmerül problémák okait. A fejezet elolvasásához ajánlott: egy új rendszermag beállításának és telepítésének ismerete (). Bevezetés A &os;-ben a nyomtatók mûködéséhez be kell állítani az LPD nyomtatási rendszert. Ez a Berkeley sornyomtatási rendszere, amelyet ezentúl röviden csak LPD-nek fogunk hívni. Ez a &os; alapértelmezett szabványos nyomtatásvezérlõ rendszere. Ebben a fejezetben az LPD és annak konfigurációja kerül bemutatásra. Ha már találkoztunk az LPD-vel vagy hozzá hasonló rendszerekkel, akkor innen nyugodtan ugorhatunk az Kezdeti beállítások címû szakaszra. Az LPD vezérli a számítógéphez csatlakoztatott nyomtató összes funkcióját. Számos feladata van: Felügyeli a lokálisan és hálózaton keresztül csatlakoztatott nyomtatók hozzáféréseit. nyomtatási munkák Lehetõvé teszi az átküldött állományok kinyomtatását, amelyeket munkáknak nevezünk. Minden nyomtatóhoz fenntart egy nyomtatási sort, amivel meg tudja akadályozni, hogy egyszerre több felhasználó is hozzá tudjon férni az egyes nyomtatókhoz. A fejléceket (vagy más néven munka- vagy elválasztó lapokat) nyomtat, így a felhasználók könnyen megtalálják a saját nyomtatásaikat a többi közt. Felügyeli a soros portokon csatlakozó nyomtatók kommunikációs beállításait. A hálózaton keresztül átküli a munkákat egy másik számítógép LPD sorába. A nyomtatandó munkák formázásához lefuttatja az adott nyomtató nyelvéhez és képességeihez illeszkedõ speciális szûrõket. Nyilvántartja a nyomtató kihasználtságát. A beállításait tartalmazó állomány (/etc/printcap) és a speciális szûrõprogramok segítségével az LPD sokféle nyomtatón képes az összes említett feladatot vagy annak egy részét megvalósítani. Amiért nyomtatási sort érdemes használni Amikor csak egyedül vagyunk a rendszerben, felmerülhet bennünk a kérdés, hogy minek is kellene nekünk veszõdni a nyomtatási sor beállításával, hiszen nincs szükségünk sem a hozzáférések vezérlésére, sem fejlécekre, sem pedig nyilvántartásra. Noha akár közvetlenül is el tudjuk érni a nyomtatót, néhány okból azért mégis érdemes nyomtatási sort használni: Az LPD a háttérben nyomtat, ezért ilyenkor nem kell megvárni, amikor az adat átmásolódik a nyomtatóra. &tex; Az LPD tetszõlegesen tudja alakítani a nyomtatási munkákat: hozzájuk tud tenni különbözõ adatokat (dátum és idõ), vagy a speciális állományokat (például a &tex; DVI formátumát) képes megértetni a nyomtatóval, és nem nekünk kell mindezeket a lépéseket elvégeznünk. Számos nyomtatási lehetõséggel rendelkezõ szabad és kereskedelmi program arra számít, hogy a rendszerünkben nyomtatási sor található, ezért egy ilyen beállításával sokkal könnyebb használni ezeket a szoftvereket. Kezdeti beállítások Úgy tudjuk használni a nyomtatókat az LPD nyomtatási rendszerével, ha egyaránt beállítjuk a nyomtatót és magát az LPD-t is. Itt a beállítás két szintjét tárgyaljuk: Az Alacsonyszintû nyomtatóbeállítás címû szakaszból megtudhatjuk, hogyan tudunk csatlakoztatni egy nyomtatót, hogyan adjuk meg az LPD-nek, miként kommunikáljon vele, hogyan nyomtassunk ki egyszerû szöveges állományokat a nyomtatón. A Magasszintû nyomtatóbeállítás szakaszban bemutatjuk, hogyan nyomtassunk ki különféle speciális állományokat, hogyan készítessünk fejléceket, hogyan nyomtassuk hálózaton keresztül, hogyan vezéreljük a nyomtatók hozzáférését és hogyan tartsuk nyilván a nyomtató használatát. Alacsonyszintû nyomtatóbeállítás Ebben a szakaszban láthatjuk, miképpen kell beállítani a nyomtatónkat és az LPD hogyan lesz képes azt használatba venni. Az alapoktól kezdünk: A Hardveres beállítás címû szakaszban abban kapunk segítséget, hogyan kell a nyomtatót a számítógéphez csatlakoztatni. A Szoftveres beállítás címû szakaszban az LPD nyomtatási rendszer beállítását tartalmazó állományt (/etc/printcap) vesszük sorra. Amennyiben olyan nyomtatót akarunk beállítani, amely nem helyileg, hanem valamilyen hálózati protokollon keresztül csatlakozik, nézzük meg a Nyomtatók hálózati adatcsatlakozással címû szakaszt. Habár ez a szakasz nevében csupán Alacsonyszintû nyomtatóbeállításról szól, meglehetõsen szerteágazó tud lenni. A nyomtató hardveres és szoftveres életre keltése az egyik legnehezesebb feladat. Ha van egy mûködõ nyomtatónk, a fejlécek és a nyilvántartás beállítása tulajdonképpen már gyerekjáték. Hardveres beállítás Ebben a szakaszban a nyomtatók csatlakoztatásának lehetséges módozatairól esik szó. Beszélni fogunk mindenféle portokról és kábelekrõl, és a &os; rendszermagjának az egyes nyomtatók használatához szükséges beállításairól is. Ha korábban tudtuk csatlakoztatni a nyomtatónkat, és más operációs rendszerekkel már sikeresen is nyomtattunk vele, akkor rögtön ugorhatunk is a Szoftveres beállításokat tartalmazó szakaszra. Portok és kábelek A személyi számítógépekhez kapható nyomtatók általában a következõ három csatolófelület egyikével rendelkeznek: nyomtató soros A soros, más néven RS-232-es vagy COM porton keresztül kommunikáló felületek a számítógép soros portján küldenek adatot a nyomtatónak. A soros csatolófelületek igen elterjedtek a számítógépiparban, könnyen tudunk ilyen kábelt szerezni, gyorsan is gyártható. Elõfordulhat, hogy a soros csatolófelületek használatához valamilyen különleges kábelre, valamint bonyolult kommunikációs beállítások megadására van szükség. A legtöbb soros port által elérhetõ legnagyobb adatátviteli sebesség másodpercenként 115 200 bit, ami miatt azonban a komolyabb grafikai tartalmak nyomtatása szinte lehetetlen. nyomtató párhuzamos A párhuzamos csatolófelületek a számítógépünk párhuzamos portjával küldenek adatokat a nyomtatónak. A párhuzamos felületek gyorsabbak az RS-232 soros felületnél, és a számítógéppiacon is gyakran megtalálhatóak. Könnyen tudunk ilyen kábelt szerezni, azonban kézileg nehezebb elkészíteni. A párhuzamos csatolófelületekhez általában nem tartoznak kommunikációs beállítások, ezért rendkívül egyszerûen el lehet boldogulni velük. centronics párhuzamos nyomtató A párhuzamos felületekre olykor Centronics csatolófelületként is hivatkoznak, amelyet egy nyomtatótípus után neveztek el. nyomtató USB A Universal Serial Bus (Univerzális soros busz) rövidítéseként használt USB elnevezésû csatolófelület a párhuzamos és a soros felületeknél jóval nagyobb sebességre képes. A hozzátartozó kábelek felépítése egyszerû és az áruk olcsó. Habár a nyomtatás terén az USB hivatott leváltani az RS-232-es soros és a párhuzamos felületeket, nem mindegyik &unix; rendszer támogatja kellõképpen. Ezt a problémát például úgy kerülhetjük el, ha olyan nyomtatót vásárolunk, amelyen a legtöbbhöz hasonlóan a párhuzamos és az USB csatlakozás is megtalálható. A párhuzamos felületeken általában csak egy irányban tudunk üzeneteket küldeni (a számítógéptõl a nyomtatóhoz), miközben az USB és a soros felület használatával mind a két irányban is. &os; alatt viszont már az újabb (EPP és ECP) párhuzamos portok egy IEEE 1284 szabványú kábellel képesek oda-vissza kommunikálni. PostScript A párhuzamos nyomtatók kétirányú kommunikációját általában két mód közül az egyiken szokták megvalósítani. Az elsõ esetben a &os; a nyomtatóhoz egy speciális meghajtót használ, amely ismeri az általa beszélt nyelvet. Ilyenek a tintasugaras nyomtatók, amelyek más egyéb állapotinformációk mellett ezen keresztül képesek jelezni a tinapatronokban levõ tinta mennyiségét. A második esetben a nyomtató ismeri a &postscript; nyelvet. A &postscript; nyelvû munkák valójában a nyomtatónak küldött programok. Használatukhoz még papírra sincs feltétlenül szükség, és adódhat, hogy közvetlenül a számítógépnek válaszolnak. A &postscript; is kétirányú kommunikáción keresztül értesíti a számítógépet az olyan gondokról, mint például a &postscript; programokban levõ hibák vagy a papír beakadása, amely információnak a felhasználók szoktak örülni. Hovatovább ez a kétirányú kommunikáció a kulcsa a &postscript; nyomtatók hatékony nyilvántartásának is: egyszerûen lekérdezzük a nyomtatótól a lapszámlálót (ami megadja, hogy a nyomtató eddig mennyi lapot nyomtatott ki), kiküldjük a felhasználóhoz tartozó feladatot és ismét lekérdezzük a lapszámlálót. A két érték kivonásából tájékozódhatunk a felhasználó által igényelt lapok mennyiségérõl. Párhuzamos portok A párhuzamos csatolófelületen érintkezõ nyomtató használatához kapcsoljunk össze számítógépünket és nyomtatónkat egy párhuzamos kábellel. Az erre vonatkozó konkrét utasítások a nyomtató és/vagy a számítógép kézikönyvében olvashatóak. Jegyezzük meg, hogy a számítógép melyik párhuzamos portjára csatlakoztattuk a kábelt. &os; alatt az elsõ ilyen port a ppc0 eszköz, a második pedig a ppc1 eszköz lesz és így tovább. A nyomtatóeszköz elnevezése ugyanezt a sémát követi: a /dev/lpt0 lesz az elsõ + class="devicefile">/dev/lpt0 lesz az elsõ párhuzamos porton levõ nyomtató stb. Soros portok A soros csatolófelületet használó nyomtatók beüzemeléséhez elõször egy soros kábel segítségével kapcsoljuk össze a számítógépünkkel. Ennek pontos részleteit a nyomtató és/vagy a számítógépünk kézikönyvében találhatjuk meg. Ha nem vagyunk benne biztosak, hogy milyen a megfelelõ soros kábel, próbáljunk az alábbiak alapján dönteni: A modem kábele a két oldalán levõ az egymásnak megfelelõ tüskéket közvetlenül összeköti. Ezt a típust nevezik DTE-DCE kábelnek. null-modem kábel A null-modem kábel bizonyos érintkezõket rendesen, másokat pedig fordítva köt össze (például a küldõt a fogadóval), illetve némelyeket rövidre zár közvetlenül a csatlakozón belül. Ez a típus a DTE-DTE kábel. Néhány speciális nyomtató esetén elõfordul még a soros nyomtatókábel, amelyek leginkább a null-modem kábelekez hasonlítanak, azonban az ott rövidre zárt csatornák itt a nekik megfelelõ érintkezõknek továbbítanak jeleket. jelváltási sebesség paritás forgalomirányítási protokoll Emellett még a nyomtató elõlapján vagy az alján található kapcsolók segítségével be kell állítanunk a nyomtatóhoz tartozó kommunikációs paramétereket is. Itt válasszuk azt a bps (a bitek száma másodpercenként) értéket, amelyet még a számítógépünk és a nyomtatónk is egyaránt képes támogatni. Válasszunk 7 vagy 8 adatbitet, páros, páratlan vagy kikapcsolt paritásbitet és 1 vagy 2 stopbitet. Ekkor tudjuk megadni a forgalomirányítási protokollt is: lehet kikapcsolt, XON/XOFF (ez az ún. sávon belüli vagy szoftveres) forgalomirányítás. Ne felejtsük el ezeket a beállításokat a most következõ szoftveres beállítások elvégzése során sem. Szoftveres beállítás Ebben a fejezetben tárgyaljuk a &os;-ben található LPD nyomtatási rendszer mûködéséhez és a nyomtatáshoz szükséges szoftveres beállításokat. Íme az elvégzendõ lépések rövid vázlata: Amennyiben szükséges, állítsuk be a rendszermagunkat nyomtató által használt portra. Ehhez A rendszermag beállítása szakaszban olvashatjuk mit is kell pontosan tenni. Ha párhuzamos portot használunk, akkor állítsuk be, hogy a párhuzamos port miként fog kommunikálni. A párhuzamos port kommunikációs módjának beállítása címû szakasz tárja fel ennek részleteit. Próbáljuk ki, hogy ezek után az operációs rendszer képes-e adatot küldeni a nyomtatónak. A nyomtató kommunikációjának ellenõrzése szakaszban kapunk erre pár javaslatot. Az /etc/printcap állomány felhasználásával állítsuk be a nyomtatónkhoz a LPD-t. Errõl a fejezet további részei adnak majd felvilágosítást. A rendszermag beállítása Az operációs rendszer magja eszközök egy adott csoportjával képes együttmûködni, amiben a soros és párhuzamos felületen csatlakozó nyomtatók is megtalálhatóak. Azonban ha a rendszermag nem ismeri fel még valamelyiket, akkor a soros vagy párhuzamos portok használatához külön támogatásra van szükség. Így tudjuk megnézni, hogy a jelenleg használt rendszermag támogatja-e a soros csatolófelületet: &prompt.root; grep sioN /var/run/dmesg.boot Itt az N nullától kezdõdõen adja meg a soros port sorszámát. Amennyiben látunk valami ilyesmit: sio2 at port 0x3e8-0x3ef irq 5 on isa sio2: type 16550A Ez azt jelenti, hogy a rendszermag sikeresen észlelte a portot. A párhuzamos csatolófelület támogatásáról így gyõzõdhetünk meg: &prompt.root; grep ppcN /var/run/dmesg.boot Itt az N nullától kezdõdõen sorszámozza a párhuzamos portot. Ha eredményül valami hasonlót kapunk: ppc0: <Parallel port> at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold Ez arra utal, hogy a rendszermagunk tud a portról. Elõfordulhat azonban, hogy az operációs rendszer csak akkor fogja észrevenni a nyomtatásra használt soros vagy párhuzamos portot, ha átállítjuk a rendszermagunkat. A soros port támogatásának beállításához olvassuk el a rendszermag beállításáról szóló szakaszt. A párhuzamos port támogatásához szintén olvassuk el ugyanazt a szakaszt és a most a következõt. A párhuzamos port kommunikációs módjának beállítása A párhuzamos csatolófelület használata esetén választhatunk, hogy a &os; milyen módon tartsa a kapcsolatot a nyomtatóval: megszakításokkal vezérelje (interrupt-driven) vagy esetleg folyamatosan kérdezgesse (polled). A &os; általános meghajtója (&man.lpt.4;) a &man.ppbus.4; alrendszert használja, ami a portot a &man.ppc.4; meghajtón keresztül vezérli. A megszakítás alapú módszer a GENERIC rendszermagban alapértelmezés. Ilyenkor az operációs rendszer egy megszakításkérés felhasználásával értesül arról, hogy a nyomtató mikor áll készen adatok fogadására. A lekérdezéses módszer használata során az operációs rendszer folyamatosan érdeklõdik a nyomtató rendelkezésre állásáról. Amikor erre pozitív megerõsítést kap, akkor a rendszermag újabb adatokat küld. A megszakításos módszer valamivel gyorsabb, azonban cserébe lefoglal egy értékes IRQ vonalat. A HP újabb nyomtatói állítólag nem mûködnek megfelelõen ilyen módban, valamilyen (pillanatnyilag még nem teljesen tisztázott) idõzítési probléma miatt. Ezért az ilyen nyomtatóknak is valószínûleg a lekérdezéses módszer kell használniuk. Más nyomtatók pedig habár mûködnek mind a két módszerrel, hihetetlenül lassúak a megszakításokkal. Kétféleképpen állíthatjuk be a kommunikációs módot: a rendszermagon keresztül, vagy az &man.lptcontrol.8; segédprogrammal. A rendszermagban így állíthatjuk be a kommunikációt: Írjuk át a rendszermag beállításait tartalmazó állományt. Keressük meg benne a használt párhuzamos portnak megfelelõen a ppc0, ppc1 (második párhuzamos port) vagy ppc2 (harmadik párhuzamos port) bejegyzést, és engedélyezzük. A megszakításos mód használatához nyissuk meg a /boot/device.hints állományt, és az N helyére írjuk be a hint.ppc.0.irq="N" sorba a megfelelõ IRQ számát. A rendszermag beállításait tartalmazó állománynak tartalmaznia kell a &man.ppc.4; meghajtót is: device ppc A lekérdezéses mód használatához a /boot/device.hints állományból távolítsuk el a következõ sort: hint.ppc.0.irq="N" Némely esetben azonban ennyi még nem lesz elég a port lekérdezéses beállításához. Ugyanis ha a hozzátartozó meghajtó az &man.acpi.4;, akkor ez fogja felismerni, kezelni és a nyomtatóhoz tartozó portok hozzáférési módját vezérelni. A problémát ezért gyakran érdemes a &man.acpi.4; beállításai között is keresni. Mentsük el az állományt. Konfiguráljuk be, fordítsuk le és telepítsük az új rendszermagot. Ennek pontos részleteit a rendszermag beállításáról szóló fejezetben olvashatjuk. A kommunikáció módjának beállítása az &man.lptcontrol.8; programmal: A megszakításos mód beállításához írjuk be: &prompt.root; lptcontrol /dev/lptN ahol az lptN a nyomtatóhoz tartozó eszköz neve. A lekérdezéses mód beállításához írjuk be: &prompt.root; lptcontrol /dev/lptN ahol az lptN a nyomtatóhoz tartozó eszköz neve. Ha ezeket a parancsokat berakjuk az /etc/rc.local állományunkba, akkor azzal a rendszer minden egyes indítása során beállítjuk a számunkra megfelelõ módot. Errõl többet az &man.lptcontrol.8; man oldaláról tudhatunk meg. A kommunikáció ellenõrzése Még mielõtt nekilátnánk a nyomtatási rendszer beállításának, bizonyosodjuk meg róla, hogy az operációs rendszer képes adatokat továbbítani a nyomtatónak. Sokkal könnyebb egymástól függetlenül megvizsgálni a kommunikáció és nyomtatási rendszer mûködését. A nyomtatót úgy tudjuk kipróbálni, ha küldünk neki valamilyen szöveget. Az &man.lptest.1; tökéletesen megfelelõ akkor, ha olyan nyomtatónk van, amely azonnal kinyomtatja a kapott szöveget. Ez a program 96 sorban létrehozza mind az összes 96 kinyomtatható ASCII karaktert. PostScript A &postscript; (vagy más egyéb nyelvet ismerõ) nyomtatóknak azonban ennél kifinomultabb próbára van szüksége. Erre a célra tökéletesen megfelel egy olyan kisebb &postscript; programocska, mint például ez: %!PS 100 100 moveto 300 300 lineto stroke 310 310 moveto /Helvetica findfont 12 scalefont setfont (Remek! Ez mukodik!) show showpage Ezt a &postscript; kódot nyugodtan elmenthetjük egy állományba, amelyet aztán a késõbbi szakaszokban megjelenõ példák szerint használni is tudunk majd. PCL A kézikönyvben a nyomtató nyelve alatt leginkább egy &postscript;-szerû nyelvet értünk, nem pedig a Hewlett Packard PCL típusú nyelvét. Habár a PCL nagyon sokra képes, hiszen keverhetjük még benne akár a programokat és a nyers szövegeket is. Ezzel szemben a &postscript; nem képes nyers szöveget kinyomtatni, ezért az ilyen típusú nyomtatók mûködtetéséhez külön támogatásra van szükségünk. A párhuzamos nyomtató ellenõrzése nyomtató párhuzamos Ebben a szakaszban megtudhatjuk, hogy &os; alatt miként ellenõrizzük a párhuzamos portra csatlakozó nyomtatók mûködését. A párhuzamos porton levõ nyomtató kipróbálásához: A &man.su.1; segítségével váljunk root felhasználóvá. Küldjünk a nyomtatónak valamilyen adatot. Ha a nyomtató képes nyers szöveget fogadni, akkor használjuk az &man.lptest.1; programot. Ehhez gépeljük be: &prompt.root; lptest > /dev/lptN ahol az N nullától kezdõdõen a párhuzamos port sorszáma. Ha a nyomtató &postscript; vagy más nyomtatási nyelvet ismer, akkor egy apró programot kell küldenünk neki. Ehhez írjuk be: &prompt.root; cat > /dev/lptN Ezután soronként írjuk be a programot, de vigyázzunk, mert az Enter vagy a Return lenyomása után már nem tudjuk kijavítani! A program begépelése után nyomjuk meg a CtrlD vagy bármely más olyan billentyûkombinációt, amivel ki tudunk lépni. Ezt a programot belerakhatjuk egy állományba is, amire aztán adjuk ki az alábbi parancsot: - &prompt.root; cat állomány > /dev/lptN + &prompt.root; cat állomány > /dev/lptN ahol az állomány a nyomtatóra küldendõ program neve lesz. Ezután a nyomtató megkezdi a nyomtatást. Ne aggódjunk, ha netalán valami furcsán nézne ki, mert a késõbbiekben ezt még úgyis rendbetesszük. A soros nyomtató ellenõrzése nyomtató soros Ebben a szakaszban megtudhatjuk, hogyan ellenõrizzük a &os; és soros portra kötött nyomtató kapcsolódását. Így tudjuk kipróbálni a soros porton csatlakozó nyomtatónkat: A &man.su.1; paranccsal váljunk root felhasználóvá. Nyissuk meg az /etc/remote állományt. Tegyük hozzá a következõ sort: printer:dv=/dev/port:br#bps:pa=paritás bit-per-másodperc soros port paritás ahol a port a soros porthoz tartozó eszközleíró neve (ttyd0, ttyd1, stb.), a bps a nyomtató által használt adatátviteli sebesség, végül a paritás a nyomtatóhoz használt paritás (ami lehet even (páros), odd (páratlan), none (nincs), vagy zero (nulla)). Íme egy olyan soros nyomtató beállítása (printer néven), amely sebessége 19 200 bps, a harmadik portra csatlakozik és nem használ paritást: printer:dv=/dev/ttyd2:br#19200:pa=none Kapcsolódjunk a nyomtatóhoz a &man.tip.1; segítségével. Ennek parancsa: &prompt.root; tip printer Ha az iménti lépés nem mûködne, próbálkozzunk az /etc/remote állomány újbóli módosításával, és a /dev/cuaaN eszköz helyett használjuk a /dev/ttydN eszközt! Küldjünk adatot a nyomtatónak. Ha a nyomtató képes nyers szöveget nyomtatni, akkor használjuk az &man.lptest.1; segédprogramot. Gépeljük be: &prompt.user; $lptest Ha a nyomtató a &postscript; vagy egy hozzá hasonló nyomtatási nyelven kommunikál, akkor a nyomtatónak egy rövid programot kell küldenünk. Soronként gépeljük be a programot, azonban vigyázzunk arra, hogy a törlés és minden más szerkesztésre használt billentyû a nyomtató számára is értelmes lehet. Az is elõfordulhat, hogy a program küldését egy speciális jelsorozattal tudjuk csak lezárni. A &postscript; nyomtatók esetén ilyenkor elegendõ a Ctrl D billentyûk együttes lenyomása. Vagy tehetjük az egész programot egy állományba, amihez aztán írjuk be ezt: &prompt.user; >állomány ahol az állomány a programot tartalmazó állomány neve. Miután a &man.tip.1; elküldte az állományt, nyomjuk le a lezáráshoz szükséges billentyûkombinációt. Most már meg kellene jelennie valaminek a nyomtatón. Az még nem számít, pontosan mi is lesz az — késõbb még majd úgyis beállítjuk. A nyomtatási rendszer aktiválása: a <filename>/etc/printcap</filename> állomány Csatlakoztattuk a nyomtatónkat, a mûködtetéséhez beállítottuk a rendszermagot (amennyiben erre szükségünk volt), és tudtunk neki adatokat küldeni. Most már készen állunk arra, hogy LDP alkalmazáson keresztül beállítsuk a nyomtató hozzáférésének vezérlését. Az LPD beállításait az /etc/printcap állományban találjuk. Az LPD nyomtatási rendszer minden egyes mûvelet elõtt beolvassa ezt az állományt, ezért a benne végzett módosítások szinte azonnal életbe is lépnek. nyomtató tulajdonságai A &man.printcap.5; tartalma könnyen érthetõ, a /etc/printcap állományt egyszerûen módosíthatjuk a kedvenc szövegszerkesztõnkkel. A felépítése teljesen megegyezik a többi hozzá hasonló állományéval: ilyenek például a /usr/share/misc/termcap és a /etc/remote. Az itt alkalmazott formátum teljes leírását a &man.cgetent.3; man oldalon találjuk. A nyomtatási rendszer egyszerû beállítása az alábbi lépésekbõl áll: Adjunk nevet (és még néhány álnevet) a nyomtatónak, írjuk ezeket az /etc/printcap állományba. A nevekrõl A nyomtató elnevezése címû szakaszban kapunk felvilágosítást. fejléclapok A(z alapból bekapcsolt) fejléclapokat az sh tulajdonság megadásával kapcsolhatjuk ki. A részleteket A fejléclapok letiltása címû szakaszban találjuk. Hozzunk létre egy nyomtatási könyvtárat, és adjuk meg a helyét az sd tulajdonság beállításával. A nyomtatási könyvtár létrehozása címû szakaszban fogunk errõl többet mondani. Állítsunk be egy nyomtató által használt /dev könyvtárbeli leírót, és az lp tulajdonsággal adjuk meg az /etc/printcap állományban. Errõl részletesebben A nyomtatóeszköz azonosítása címû szakaszban olvashatunk. Ha a nyomtató soros porton keresztül csatlakozik, az ms# tulajdonsággal még meg kell adnunk A nyomtatási rendszer kommunikációs paraméterei szakaszban tárgyaltakat is. Helyezzünk el egy szûrõt a beérkezõ nyers szövegek számára. Errõl A szövegszûrõ telepítése címû szakasz értekezik. Az &man.lpr.1; parancs segítségével próbáljuk ki a nyomtatást. Ennek pontos részleteit a Próbáljuk ki! és a Hibakeresés címû fejezetekben találhatjuk meg. A magasabb szintû nyomtatók, mint például a &postscript; nyomtatók nem képesek közvetlenül nyers szöveget nyomtatni. Az imént felvázolt egyszerû beállítási séma feltételezi, hogy csak olyan állományokat fogunk nyomtatni a nyomtatón, amelyeket meg is ért. A felhasználók gyakran arra számítanak, hogy bármelyik általuk elérhetõ nyomtatón képesek nyers szöveget kinyomtatni. Az LPD alkalmazással kapcsolatban álló programok is általában ugyanezt az elgondolást követik. Ha egy saját nyelvvel rendelkezõ nyomtatót akarunk telepíteni, de a nyomtató saját nyelvén és a nyers szöveg formájában érkezõ munkákat is rendesen ki akarjuk nyomtatni, akkor mindenképpen javasoljuk, hogy illeszünk még egy további lépést is ebbe a sorba: illesszünk a rendszerbe egy nyers szövegrõl automatikusan &postscript; (vagy más egyéb) nyelvre tolmácsoló programot. Errõ a Szöveges nyomtatási feladatok &postscript; nyomtatókon címû fejezetben olvashatunk. A nyomtató elnevezése Az elsõ (egyszerû) lépés a nyomtatónk nevének kiválasztása. Igazából nem számít, mennyire kifejezõ vagy éppen hóbortos nevet adunk neki, hiszen emellett még számos álnévvel is illethetjük. Az /etc/printcap állományban megtalálható nyomtatók egyikének legalább az lp álnévvel rendelkeznie kell, mivel ez lesz az alapértelmezett nyomtató neve. Tehát ha a felhasználó nem adja meg sem a PRINTER környezeti változót, sem pedig az LPD-vel kapcsolatban álló aktuális parancsban a használni kívánt nyomtató nevét, akkor a rendszer az lp nevût fogja keresni. Ezenkívül általában még gyakran adnak egy olyan álnevet is a nyomtatónak, ahol annak teljes leírása, többek közt a gyártmánya és a típusa szerepel. Ahogy sikerült nevet és álneveket adni a nyomtatónak, írjuk is be ezeket az /etc/printcap állományba. Itt a nyomtató neveit balról el kezdjük felsorolni, mindegyik álnevet egy függõleges vonallal válasszunk el, és az utolsó után pedig tegyünk pontosvesszõt. A most következõ példában egy olyan vázt mutatunk be az /etc/printcap állományhoz, amiben két nyomtatót (egy Diablo 630 márkájú sornyomtatót és egy Panasonic KX-P4455 típusú &postscript; lézernyomtatót) adunk meg: # # /etc/printcap (rose) # rattan|line|diablo|lp|Diablo 630 Line Printer: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4: Ebben a példában az elsõ nyomtató neve rattan, és ehhez tartozik még a line, diablo, lp, és Diablo 630 Line Printer álnév. Mivel itt soroltuk fel az lp álnevet is, ezért a rendszerben ez lesz az alapértelmezett nyomtató. A második nyomtató neve bamboo, és álnevei többek közt a ps, PS, S, panasonic, valamint a Panasonic KX-P4455 PostScript v51.4. A fejléclapok letiltása nyomtatás fejléclapok Az LPD nyomtatási rendszer alapértelmezés szerint minden egyes feladathoz fejléclapot készít. Ez a lap szép nagy betûkkel tartalmazza a munkát kiadó felhasználó nevét, a gépet, amirõl küldték, és a feladat nevét. Sajnálatos módon ez azonban inkább akadályozza a hibakeresést a nyomtató beállításában, ezért most inkább kapcsoljuk ki ezeket. Ha le akarjuk tiltani a fejléclapokat, az /etc/printcap állományban adjuk meg az sh (úgy mint suppress header pages) tulajdonságot. Íme egy példa az sh tulajdonsággal bõvített /etc/printcap állományra: # # /etc/printcap (rose) - sehol sem lesznek fejléclapok # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh: Ebben a példában megfigyelhetjük a helyes felírási módot: az elsõ sor a legbaloldalibb oszlopban kezdõdik, és az azt követõ sorok pedig bentebb. Minden bejegyzésben az utolsó kivételével mindegyik sor egy visszaper (backslash) karakterrel zárul. A nyomtatási könyvtár létrehozása nyomtatási rendszer nyomtatási munkák A nyomtatási rendszerünk beállításának következõ lépése a nyomtatási könyvtár létrehozása. Ez egy olyan könyvtár, ahová a különbözõ nyomtatási feladatok kerülnek a feldolgozásuk elõtt, valamint ahol a nyomtatási rendszer többi állománya lakozik. A nyomtatási rendszer adatait tároló könyvtárakat tartalmuk gyakori változása miatt általában a /var/spool könyvtárba szokás tenni. Ezen könyvtárak tartalmát nem szükséges menteni sem. Az &man.mkdir.1; parancs futtatásával egyszerûen újra létre tudjuk hozni. Általában minden nyomtatóhoz külön létre szoktak hozni egy könyvtárat az adott nyomtató nevén. Erre példa: - &prompt.root; mkdir /var/spool/nyomtatónév + &prompt.root; mkdir /var/spool/nyomtatónév Azonban ha a hálózatunkon rengeteg nyomtató található, akkor érdemes inkább egyetlen könyvtárat használni, amelyet az LPD számára tartunk fenn. &prompt.root; mkdir /var/spool/lpd &prompt.root; mkdir /var/spool/lpd/rattan &prompt.root; mkdir /var/spool/lpd/bamboo Amennyiben fontos nekünk a felhasználói nyomtatások titkosságának megóvása, érdemes levédenünk a nyomtatási könyvtárat, így az nem lesz mindenki által elérhetõ. A nyomtatási könyvtárak tulajdonosa egyedül és kizárólag a daemon felhasználó és a daemon csoport legyen, és hozzá olvasási, írási és keresési engedélyekkel rendelkezzen. Ezt fogjuk most beállítani a példáinkban szereplõ nyomtatóinkhoz is: &prompt.root; chown daemon:daemon /var/spool/lpd/rattan &prompt.root; chown daemon:daemon /var/spool/lpd/bamboo &prompt.root; chmod 770 /var/spool/lpd/rattan &prompt.root; chmod 770 /var/spool/lpd/bamboo Végezetül az /etc/printcap állományban ezeket a könyvtárakat se felejtsük el megadni az LPD-nek. Itt a nyomtatási könyvtár nevét az sd tulajdonsággal írjuk le: # # /etc/printcap (rose) - a nyomtatási könyvtárak hozzáadása # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo: Vegyük észre, hogy a nyomtató neve ugyan a sor elején kezdõdik, azonban a hozzátartozó összes többi sor mind bentebb kezdõdik és egy visszaper (backslash) karakterrel választjuk le. Ha az sd tulajdonsággal nem adunk meg semmilyen nyomtatási könyvtárat, akkor ennek az értéke alapértelmezés szerint a /var/spool/lpd lesz. + class="directory">/var/spool/lpd lesz. A nyomtatóeszköz azonosítása A Hardveres beállítás címû szakaszban már beazonosítottuk, hogy a &os; a /dev könyvtárban melyik eszközleírón keresztül fogja megszólítani a nyomtatót. Most ideje ugyanezt tudatni az LPD démonnal is. Így amikor a nyomtatási rendszer ki szeretne nyomtatni egy munkát, a szûrõprogram nevében ezt az eszközt nyitja meg (ahol a szûrõn keresztül továbbítjuk az adatokat a nyomtató felé). Az lp tulajdonság segítségével a /etc/printcap állományban soroljuk fel a nyomtatók /dev könyvtárban található leíróit. Az eddig használt példánkban most tételezzük fel, hogy a rattan nevû nyomtató az elsõ párhuzamos porton található, míg a bamboo nevû a hatodik soros porton. Ebben a helyzetben így kellene kiegészítenünk az /etc/printcap állományunkat: # # /etc/printcap (rose) - a használni kívánt eszközök # beazonosítása # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:\ :lp=/dev/ttyd5: Az LPD alapértelmezés szerint a /dev/lp eszköz fogja használni, ha nem adjuk meg az lp tulajdonságot az /etc/printcap állományban. Az /dev/lp azonban a &os;-ben jelenleg nem létezik. Ha a telepítendõ nyomtatónk valamelyik párhuzamos portra csatlakozik, akkor innen akár tovább is léphetünk A szövegszûrõ telepítése címû szakaszra. Ha viszont nem, kövessük a most következõ szakaszban szereplõ utasításokat. A nyomtatási rendszer kommunikációs paraméterei nyomtató soros A soros portra csatlakozó nyomtatóknál az LPD képes beállítani az adatátviteli sebességet, a paritást, valamint más egyéb olyan kommunikációs paramétereket, amelyekkel a szûrõprogram adatokat tud továbbítani a nyomtató felé. Ez több szempontból is elõnyös, mivel: Egyszerûen az /etc/printcap állomány átírásával ki tudunk próbálni több kommunikációs beállítást, nem kell magát a szûrõprogramot újrafordítanunk. A nyomtatási rendszer képes ugyanazt a szûrõt több, különbözõ kommunikációs beállítást alkalmazó nyomtatóhoz is használni. Az /etc/printcap állományban az lp tulajdonsággal megadott eszközök soros kommunikációjának beállításait az alábbi tulajdonságok határozzák meg: br#sebesség Beállítja az eszköz adatátviteli sebességét a sebesség értékre, ahol a sebesség lehet 50, 75, 110, 134, 150, 200, 300, 600, 1200, 1800, 2400, 4800, 9600, 19 200, 38 400, 57 600 vagy 115 200 bit másodpercenként (bps). ms#stty-mód Beállítja az eszköz megnyitása után használt termináleszköz mûködésének paramétereit. Az &man.stty.1; man oldalon többet is megtudhatunk róluk. Miután az LPD megnyitja az lp tulajdonsággal megadott eszközt, beállítja az ms# tulajdonság értéke szerint annak jellemzõit. Itt a parenb, parodd, cs5, cs6, cs7, cs8, cstopb, crtscts, és ixon módok lehetnek lényegesek, melyekrõl az &man.stty.1; man oldalon többet is megtudhatunk. Állítsunk most akkor be az egyik képzeletbeli nyomtatónkat a hatodik soros portra. Az adatátviteli sebessége 38 400 bps lesz. A kommunikáció módjánál kapcsoljuk ki a paritást (-parenb), 8 bites karakterek legyenek (cs8), ne legyen modemes vezérlés (clocal) és a hardveres forgalomirányítás legyen crtscts: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:\ :lp=/dev/ttyd5:ms#-parenb cs8 clocal crtscts: A szövegszûrõ telepítése nyomtatás szûrõk Most már utasíthatjuk az LPD-t, hogy milyen szövegszûrõt használjon a munkák nyomtatóra küldéséhez. A szövegszûrõ (text filter), vagy más néven bemeneti szûrõ (input filter) egy olyan program, amelyet az LPD egy nyomtatási feladat elvégzésekor lefuttat. Amikor az LPD lefuttatja a nyomtatóhoz tartozó szövegszûrõt, a szûrõ szabványos bemenetére elküldi a kinyomtatandó munkát, és a szabványos kimenetét pedig átirányítja az lp tulajdonság által megadott nyomtatóeszközre. Ennek megfelelõen a szûrõnek a szabványos bemenetrõl kell olvasnia az elvégzendõ feladatot, a szabványos kimenetre pedig a ténylegesen nyomtatandót kell kiírnia. A szövegszûrõk részleteirõl a Hogyan mûködnek a szûrõk? szakasz szól. A mi esetünkben most szövegszûrõnek tökéletesen megfelel egy olyan rövid szkript, ami a nyomtatóra a munkát a /bin/cat paranccsal küldi ki. A &os;-ben még találhatunk egy másik szûrõt is, amelynek a neve lpf. Ez képes a törlést és aláhúzást jelzõ karaktereket érthetõvé tenni bizonyos nyomtatók számára. Természetesen itt használhatunk kedvünk szerinti szûrõt is. Az lpf szûrõ mûködésének részleteit Az lpf szövegszûrõ címû szakaszban fejtjük ki bõvebben. Elõször is készítsünk egy /usr/local/libexec/if-simple nevû egyszerû szövegszûrõ szkriptet. A kedvenc szövegszerkesztõnkkel írjuk bele a következõ sorokat: #!/bin/sh # # if-simple - egyszerû szövegszûrõ szkript az lpd-hez # Helye: /usr/local/libexec/if-simple # # Egyszerûen átmásolja a kimenetére a bemenetérõl érkezõ adatokat; nem # fogad el semmilyen paramétert. /bin/cat && exit 0 exit 2 Tegyük indíthatóvá: &prompt.root; chmod 555 /usr/local/libexec/if-simple Ezután tájékoztassuk róla az LPD-t az /etc/printcap állományban található if tulajdonság megadásával. Itt most a példánkban szereplõ mind a két nyomtatóhoz beillesztjük: # # /etc/printcap (rose) - a szövegszûrõ hozzáadása # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0:\ :if=/usr/local/libexec/if-simple: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:\ :lp=/dev/ttyd5:ms#-parenb cs8 clocal crtscts:\ :if=/usr/local/libexec/if-simple: Az if-simple szkript megtalálható a /usr/share/examples/printing könyvtárban. Az <application>LPD</application> elindítása Az &man.lpd.8; az /etc/rc szkriptbõl, az lpd_enable változó értékének megfelelõen indul el. Ennek értéke alapból NO, vagyis nem. Ha eddig még nem tettük volna meg, akkor az /etc/rc.conf állományba most vegyük fel a következõ sort: lpd_enable="YES" Ezután vagy indítsuk újra a számítógépünket, vagy pedig adjuk ki az &man.lpd.8; parancsot: &prompt.root; lpd Próbáljuk ki! Elérkeztünk az LPD egyszerû beállításának utolsó lépéséhez. Sajnos azonban még nem gratulálhatunk, hiszen hátra van még a nyomtató kipróbálása és az esetlegesen elõforduló hibák kijavítása. A beállítást úgy tudjuk a legegyszerûbben letesztelni, ha megpróbálunk valamit kinyomtatni. Az LPD rendszerben az &man.lpr.1; parancs használatával tudunk nyomtatási feladatokat kiadni. A kommunikáció ellenõrzése címû szakaszban megtalálhatjuk, hogy hozzunk létre tesztelésre alkalmas szövegeket az &man.lpr.1; és az &man.lptest.1; programok segítségével. Az LPD beállításainak egyszerû tesztelése: Írjuk be: &prompt.root; lptest 20 5 | lpr nyomtatónév ahol a nyomtatónév az /etc/printcap állományban megadott egyik nyomtató neve (vagy álneve) lehet. Az alapértelmezett nyomtató kipróbálásához ne adjunk meg az &man.lpr.1; parancsnak semmilyen paramétert. Még egyszer megemlítenénk, hogy amennyiben &postscript; nyomtatót tesztelünk, az elõbbi helyett az &man.lptest.1; paranccsal küldjünk ki egy &postscript; programot. Ehhez tegyük a tesztelõ programunkat egy állományba, majd írjuk be az lpr állománynév parancsot. A &postscript; nyomtató esetén a kiküldött program eredményét kell látnunk. Amennyiben az &man.lptest.1; parancsot használjuk, valami ilyesmire kell számítanunk: !"#$%&'()*+,-./01234 "#$%&'()*+,-./012345 #$%&'()*+,-./0123456 $%&'()*+,-./01234567 %&'()*+,-./012345678 A nyomtató kimerítõbb teszteléséhez próbáljunk meg nagyobb programokat keríteni valahonnan (ha a nyomtatónk valamilyen nyelven kommunikál) vagy adjunk meg az &man.lptest.1; parancsnak más paramétereket. Például az lptest 80 60 soronként 80 karaktert írat ki 60 sorban. Amennyiben a nyomtató nem mûködne, nézzük meg a Hibakereséshez tartozó szakaszt. Magasszintû nyomtatóbeállítás Ebben a szakaszban olyan szûrõket mutatunk be, amelyek speciálisan formázott állományok, fejléclapok, hálózati nyomtatás, nyomtatási nyilvántartás vagy szabályozás esetén használhatóak. Szûrõk nyomtatás szûrõk Noha az LPD képes hálózati protokollokat, nyomtatási sorokat, hozzáférést és sok minden más nyomtatási feladatot kezelni, a tényleges munka legnagyobb része a szûrõkben (filter) történik. A szûrõk olyan programok, amelyek tartják a kapcsolatot a nyomtatóval és megbírkóznak annak eszközfüggõségeivel és különleges igényeivel. Az egyszerû beállítás során egy primitív szövegszûrõt állítottunk be (lásd A szövegszûrõ telepítése) — ami annyira egyszerû, hogy szinte minden nyomtatón mûködnie kell. Azonban mindahhoz, hogy ki tudjuk használni a különbözõ átalakítási, nyilvántartási lehetõségeket, valamint a nyomtatók különlegességeit és egyebeit, meg kell értenünk a szûrõk pontos mûködését. Az elõbb említett feladatok ugyanis teljesen a szûrõ kezében vannak. Ezzel kapcsolatban azonban rossz hír, hogy ezeket a szûrõket nekünk kell megírnunk. A jó hír ellenben az, hogy könnyen találunk ilyen szûrõket, vagy ha éppen nem lelnénk valamelyiket, akkor is gyorsan meg tudjuk ezeket írni. Sõt, a &os; alapból tartalmaz is egyet, amit a /usr/libexec/lpr/lpf helyen találunk meg, és sok olyan nyomtatóval képes együttmûködni, amelyek nyers szöveget tudnak nyomtatni. (Kezeli az állományokban felbukkanó törléseket és tabulalásokat, valamint képes nyilvántartást vezetni, de semmi többet.) Rajta kívül még számos szûrõt és szûrõelemet is találhatunk a &os; Portgyûjteményében. Lássuk, mit tartogat számunkra ez a rész: A Hogyan mûködnek a szûrõk? címû szakaszban megpróbálunk egyfajta áttekintést adni a szûrõk nyomtatási folyamatban betöltött szerepérõl. Mindenképpen érdemes elolvasnunk ezt a szakaszt, mivel ebben derül ki, hogy valójában mi is történik a függöny mögött, vagyis amikor az LPD használja ezeket a szûrõket. Ezzel a tudással el tudjuk kerülni vagy éppen nyakon tudjuk csípni azokat a problémákat, amelyek a nyomtatóinkhoz telepített szûrõk hozzáadása során adódhatnak. Az LPD alapból arra számít, hogy minden nyomtató képes nyers szöveget nyomtatni. Ez gondot okoz a &postscript; (és minden más nyelv alapú) nyomtatók esetén, mivel azok nem képesek nyers szöveget nyomtatni. Szöveges nyomtatási feladatok &postscript; nyomtatókon címû szakaszban viszont fény derül rá, hogyan kerekedjünk felül ezen. Feltétlenül olvassuk el, ha &postscript; nyomtatónk van. A &postscript; számos program közkedvelt kimeneti formátuma, sõt gyakran maguk a felhasználók is szeretnek ilyen programokat írni. Sajnos azonban a &postscript; nyomtatók egyáltalán nem olcsók. A &postscript; szimulációja nem &postscript; nyomtatókon címû szakaszban megtudhatjuk, miképp tudjuk úgy módosítani a szûrõt, hogy nem &postscript; nyomtatókon is tudjunk &postscript; programokkal nyomtatni. Ezt a szakaszt akkor érdemes elolvasni, ha nincs &postscript; nyomtatónk. A Konverziós szûrõk címû szakaszban eláruljuk, miként lehetséges automatizálni a különbözõ állományformátumok és a nyomtatók által érthetõ formátumok közti konverziókat, legyen az grafikus vagy betûszedésre vonatkozó adat. A szakasz elolvasása során megismerjük, hogyan tudjuk a nyomtatónkat képessé tenni az lpr paranccsal troff adatok, vagy a lpr paranccsal a &tex; DVI állományainak, esetleg az lpr paranccsal raszteres képek nyomtatására és így tovább. Csak ajánlani tudjuk ennek elolvasását. A Kimeneti szûrõk címû szakaszban kivesézzük az LPD egyik kevésbé használt lehetõségét is, a kimeneti szûrõket. Hacsak nem fejléclapokat akarunk készíteni (lásd Fejléclapok), akkor ezt a szakaszt nyugodtan kihagyhatjuk. Az lpf szövegszûrõ szakaszban bemutatásra kerül a &os;-ben alapból megtalálható lpf szûrõ, amely egy sornyomtatónknál (vagy az így viselkedõ lézernyomtatóknál) használható egyszerû szövegszûrõ. Ha nyers szövegek nyomtatásánál meg akarjuk oldani a nyomtatási munkák nyilvántartását, vagy a törlés karakter láttán a nyomtatónk füstölni kezdene, akkor mindenképpen érdemes belemerülnünk az lpf titkaiba. A most következõ szkriptek mindegyike megtalálható a /usr/share/examples/printing könyvtárban. Hogyan mûködnek a szûrõk? Ahogy már korábban is jeleztük, a szûrõ egy olyan végrehajtható program, amelyet az LPD indít el, amikor a nyomtatóval eszközfüggetlen módon kommunikál. Amikor az LPD egy feladat elvégzése során ki akar nyomtatni egy állományt, akkor elindít egy ilyen szûrõprogramot. A szûrõ szabványos bemenetére elküldi a kinyomtatandó állományt, a szabványos kimenetét a nyomtatóra, a szabványos hibajelzéseit pedig egy naplóállományba irányítja (ez utóbbit az /etc/printcap) állományban az lf tulajdonsággal adhatjuk meg, vagy alapértelmezés szerinti a - /dev/console állományba + /dev/console állományba kerül). troff Az LPD a használni kívánt szûrõt és annak paramétereit az /etc/printcap állományban felsoroltak vagy az &man.lpr.1; parancssorában megadottak szerint választja ki. Például, ha a felhasználó a lpr parancsot adja ki, akkor az LPD a célként megadott nyomtatónál szereplõ tf tulajdonság által megadott troff szûrõt kezdi el használni. Amennyiben a felhasználó egyszerûen csak nyers szöveget akar nyomtatni, akkor az if szûrõnek kellene elindulnia (ez viszont csak részben igaz: lásd Kimeneti szûrõk). Háromfajta szûrõ jelenhet meg az /etc/printcap állományban: A szövegszûrõ (text filter), ami a hagyományos szöveges nyomtatásért felelõs, és amit az LPD dokumentációjában érdekes módon bemeneti szûrõnek (input filter) hívnak. Mivel az LPD arra számít, hogy minden nyomtató alapból képes kinyomtatni bármilyen nyers szöveget, ezért a szövegszûrõ feladata, hogy a nyomtató számára gondoskodjon a tabulátorok, törlések és más egyéb speciális karakterek megfelelõ kezelésérõl. Emellett ha olyan helyen vagyunk, ahol szükség van a nyomtatási munkák nyilvántartására is, a szövegszûrõ ennek megoldására is képes, méghozzá úgy, hogy összeszámolja a kinyomtatott sorokat és elosztja ezeket a nyomtató által oldalanként nyomtatott sorok számával. Egy szövegszûrõ a következõ paraméterekkel indulhat: szûrõnév -c -w szélesség -l hossz -i behúzás -n hozzáférés -h gépnév nyilvántartás ahol a akkor jelenik meg, ha egy munkát az lpr paranccsal adunk át szélesség az /etc/printcap állományban definiált pw (page width, avagy oldalszélesség) tulajdonság értéke, ami alapbeállítás szerint 132 hossz a pl (page length, avagy oldalhossz) tulajdonság értéke, amely az alapbeállítás szerint 66 behúzás az lpr parancs megadása során használt behúzás mértéke, ami alapból 0 hozzáférés a nyomtatást végzõ felhasználó hozzáférésének megnevezése gépnév a gép neve, amirõl a nyomtatási munka érkezett nyilvántartás ez a nyilvántartást tároló állomány af tulajdonsággal definiált neve nyomtatás szûrõk A konverziós szûrõk (conversion filter) egy adott állományformátumot hoznak a nyomtató számára értelmes formára. Például ditroff adatok közvetlenül ugyan nem nyomtathatóak, azonban a ditroff állományokhoz tudunk telepíteni egy olyan szûrõt, amely a ditroff adatokat a nyomtató számára is emészthetõ és nyomtatható formájúvá teszi. A Konverziós szûrõk címû szakasz tud ezekrõl többet mondani. Ilyen esetekben kérhetünk nyilvántartást. A konverziós szûrõk az alábbi paraméterekkel indulhatnak: szûrõnév -x pixelszélesség -y pixelmagasság -n hozzáférés -h gépnév nyilvántartás ahol a pixelszélesség a px tulajdonság értékébõl (ami alapból 0), a pixelmagasság a py tulajdonság értékébõl (ami alapból szintén 0) származik. A kimeneti szûrõ (output filter), ami csak akkor aktív, ha a szövegszûrõ nem, vagy ha engedélyeztük fejléclapok nyomtatását. Tapasztalatom szerint az ilyen szûrõket ritkán használják. A Kimeneti szûrõk címû szakasz mutatja be a mûködésüket. Ekkor csupán két paraméterünk van: szûrõnév -w szélesség -l hosszúság amik rendre megegyeznek a szövegszûrõk és paramétereivel. A szûrõk ki is tudnak lépni a következõ kódokkal (exit status): 0 A szûrõ sikeresen kinyomtatta az állományt. 1 A szûrõnek nem sikerült kinyomtatnia az állományt, azonban szeretné, ha az LPD újból megpróbálkozna vele. Az LPD tehát ebben az esetben újraindítja a szûrõt. 2 A szûrõnek nem sikerült kinyomtatnia az állományt, és nem is kívánja újra megpróbálni. Ekkor az LPD eldobja az állományt. A &os; kiadásokban megtalálható /usr/libexec/lpr/lpf szövegszûrõ képes a kapott szélesség és hossz paraméterekkel megállapítani az oldaltöréseket és a nyomtató használatát nyilvántartani, amihez a hozzáférés, gépnév és nyilvántartás adatait használja fel. Amikor majd igyekszünk mellé újabb szûrõket beszerezni, ne felejtsük el ellenõrizni, hogy együtt tudnak-e mûködni az LPD-vel. Ha a válasz igen, akkor a fentebb említett paraméterek mindegyikét ismerniük kell. Az általános használatra készült szûrõk készítése során mi magunknak is be kell tartanunk ezeket az elvárásokat. Szöveges nyomtatási feladatok &postscript; nyomtatókon nyomtatsái munkák Ha csak egyedül dolgozunk a számítógépen és &postscript; (vagy bármilyen más nyelvet ismerõ) nyomtatónk van, valamint megígérjük, hogy soha nem küldünk sem mi, sem pedig nem küldetünk semmilyen más programmal nyers szöveget a nyomtatóra, akkor átléphetjük ezt a szakaszt. Ha viszont egyaránt akarunk küldeni &postscript; programot és nyers szöveget tartalmazó munkákat a nyomtatónak, akkor ehhez kénytelenek vagyunk a rendszerünket beállítani. Elõször is szükségünk van szövegszûrõre, ami megállapítja, hogy a frissen érkezett munka nyers szöveget vagy &postscript; programot tartalmaz-e. Minden &postscript;-alapú feladat a %! karaktersorozattal kezdõdik (a többi esetben olvassuk a nyomtató leírását). Szóval, ha a nyomtatandó állomány elsõ két karaktere ilyen, akkor egy &postscript; programmal van dolgunk és közvetlenül továbbküldhetjük a munkát a nyomtatónak. Minden más esetben a szûrõnek elõbb át kell alakítania a szöveget &postscript; nyelvre. Hogyan érhetjük el mindezt? nyomtató soros Ha soros nyomtatónk van, akkor erre a feladatra az lprps parancs tökéletes. Az lprps egy olyan &postscript; szûrõ, amely mind a két irányban képes közvetíteni. Folyamatosan rögzíti egy állományba a nyomtató állapotát, így a felhasználók és rendszergazdák pontosan látják a nyomtató jelenlegi állapotát (például toner low (a toner hamarosan kifogy) vagy paper jam (a papír beragadt)). Ami viszont sokkal lényegesebb, hogy a psif nevû program képes megmondani az érkezõ munka valódi típusát, és ennek megfelelõen meg tudja hívni nyers szöveg átalakítására a textps (egy másik program, amit a lprps mellé kapunk) parancsot. Ezután az lprps elküldi a feladatot a nyomtatónak. Az lprps a &os; Portgyûjteményének része (lásd A Portgyûjtemény), ezért a használni kívánt papír méretétõl függõen pillanatok alatt magunk is letölhetjük, fordíthatjuk és telepíthetjük a print/lprps-a4 és print/lprps-letter csomagok valamelyikét. Az lprps telepítése után egyszerûen csak adjuk meg a psif elérési útvonalát. Ha tehát telepítettük a Portgyûjteménybõl az lprps csomagot, akkor egy soros portra csatlakozó &postscript; nyomtató esetén ezt kell beírnunk az /etc/printcap állományba: :if=/usr/local/libexec/psif: Ezenkívül még az rw tulajdonsággal meg kell mondanunk az LPD-nek, hogy a nyomtatót írásra és olvasásra nyissa meg. Amennyiben a &postscript; nyomtatónk a párhuzamos porton csatlakozik (és amiért a nyomtatónk nem képes az lprps által igényelt kétirányú kommunikációra), szövegszûrõként a következõ szkriptet fogjuk használni: #!/bin/sh # # psif - PostScript vagy nyers szöveg nyomtatása PostScript nyomtatón # Ez a szkriptes változat, NEM pedig az lprps-hez mellékelt szûrõ # (a /usr/local/libexec/psif állomány)! # IFS="" read -r first_line first_two_chars=`expr "$first_line" : '\(..\)'` if [ "$first_two_chars" = "%!" ]; then # # PostScript: nyomtassuk ki. # echo "$first_line" && cat && printf "\004" && exit 0 exit 2 else # # Nyers szöveg: alakítsuk át, majd nyomtassuk ki. # ( echo "$first_line"; cat ) | /usr/local/bin/textps && printf "\004" && exit 0 exit 2 fi A fentebb szereplõ szkriptben a textps programot használjuk a nyers szövegek &postscript; programokra alakításához, de helyette bármilyen más konvertáló programot is igénybe vehetünk. A &os; Portgyûjteményében (lásd A Portgyûjtemény) találhatunk erre a célra egy a2ps nevû programot is, amit esetleg érdemes lehet közelebbrõl megnéznünk. &postscript; szimulációja nem &postscript; nyomtatókon PostScript emuláció Ghostscript A &postscript; a magas színvonalú betûszedés és nyomtatás de facto szabványa. Emellett azonban a &postscript; egy költséges szabvány is. Az Aladdin Enterprises-nak hála azonban létezik egy hozzá hasonló szabad szoftver, a Ghostscript, amely képes &os;-n is futni. A Ghostscript képes a legtöbb &postscript; állomány olvasására, megjelenítésére mindenféle eszközökön, beleértve a &postscript;et nem ismerõ nyomtatókat is. A Ghostscript és egy speciális szövegszûrõ telepítésével el tudjuk érni, hogy egy nem &postscript; nyomtató valódi &postscript; nyomtatóként viselkedjen. Ha telepíteni szeretnénk, a Ghostscript megtalálható a &os; Portgyûjteményében. Innen tehát magunk is könnyedén le tudjuk tölteni, fordítani és telepíteni. A &postscript; nyomtatás szimulációjához elõször egy szûrõ segítségével észre kell vennünk, hogy egy &postscript; formátumú állományt készülünk kinyomtatni. Ha nem ilyen a nyomtatandó munka, akkor egyenesen a nyomtatóra küldjük, azonban minden más esetben elõször a Ghostscript segítségével átalakítjuk egy olyan formátumba, amit a nyomtató is képes feldolgozni. Nézzünk erre egy példát: a most következõ szövegszûrõ a Hewlett Packard DeskJet 500-as nyomtatóihoz használható. Más nyomtató esetén cseréljük ki a gs (Ghostscript) parancs paraméterét a neki megfelelõre. (A telepített Ghostscript által ismert nyomtatók listáját a gs paranccsal kérdezhetjük le.) #!/bin/sh # # ifhp - Ghostscripttel szimulált Postscript nyomtatás DeskJet 500-on # Helye: /usr/local/libexec/ifhp # # LF karaktereket CR+LF-ként kezeljük (elkerülve ezzel a HP/PCL # nyomtatókon a "lépcsõzést"): # printf "\033&k2G" || exit 2 # # Az állomány elsõ két karakterének beolvasása # IFS="" read -r first_line first_two_chars=`expr "$first_line" : '\(..\)'` if [ "$first_two_chars" = "%!" ]; then # # Ez PostScript: küldjük át a Ghostscripten és nyomtassuk ki. # /usr/local/bin/gs -dSAFER -dNOPAUSE -q -sDEVICE=djet500 \ -sOutputFile=- - && exit 0 else # # Nyers szöveg vagy HP/PCL, ezért küldjük át közvetlenül. Az utolsó # lap kidobásához küldünk még egy lapdobást is. # echo "$first_line" && cat && printf "\033&l0H" && exit 0 fi exit 2 Befejezésül az if tulajdonságon keresztül értesítenünk kell errõl a szûrõrõl az LPD-t is: :if=/usr/local/libexec/ifhp: Készen is vagyunk! Most már nyugodtan beírhatjuk, hogy lpr sima.szöveg vagy lpr akármi.ps, mind a kettõnek ki kell tudnia nyomtatódnia. Konverziós szûrõk Miután elvégeztük az Alacsonyszintû nyomtatóbeállítás címû szakaszban leírt beállításokat, a (nyers ASCII szöveg mellett) kedvenc állományformátumainkhoz is minden bizonnyal szeretnénk telepíteni néhány konverziós szûrõt. Miért használjunk konverziós szûrõket? &tex; DVI állományok nyomtatása A konverziós szûrõk segítségével állományok mindenféle formátumait könnyen ki tudjuk nyomtatni. Például tegyük fel, hogy a sokat dolgozunk a &tex; betûszedõ rendszerrel és egy &postscript; nyomtatónk van. Minden alkalommal, amikor egy DVI állományt hozunk létre a &tex; forrásból, azt közvetlenül még nem tudjuk a nyomtatóra küldeni. Ehhez a következõ parancsokat kell kiadnunk: &prompt.user; dvips hínár-elemzés.dvi &prompt.user; lpr hínár-elemzés.ps Ha telepítünk egy konverziós szûrõt a DVI állományokhoz, meg tudjuk spórolni ezt a manuális átalakítási lépést azzal, hogy átadjuk ezt a feladatot az LPD-nek. Így ezután mindig, amikor egy DVI állományt akarunk kinyomtatni, csupán egyetlen lépésre lesz szükségünk: &prompt.user; lpr hínár-elemzés.dvi Az LPD-nek a paraméterrel adjuk meg, hogy a nyomtatás elõtt hajtsa végre a DVI átalakítását. A Formázási és konverziós beállítások címû szakaszban találjuk meg a többi konverziós opciót. Minden olyan konverziós beállításhoz, amit használni szeretnénk a nyomtatóval, telepítenünk kell egy konverziós szûrõt (conversion filter) és meg kell adnunk a nevét az /etc/printcap állományban. A konverziós szûrõk az egyszerû nyomtatóbeállításnál szereplõ szövegszûrõkhöz hasonlítanak (lásd A szövegszûrõ telepítése szakasz) azzal a kivétellel, hogy a nyers szövegek kinyomtatása helyett ezek a szûrõk a nyomtató számára értelmes formátumra alakítják az állományokat. Milyen konverziós szûrõket érdemes telepíteni? Olyan konverziós szûrõket telepítsünk, amelyekre gyakran szükségünk lehet. Ha például sok DVI adatot szeretnénk nyomtatni a jövõben, akkor használjunk DVI konverziós szûrõt, vagy ha sok troff formátumú adatot nyomtatunk, akkor minden bizonnyal jól fog jönni egy troff szûrõ. A következõ táblázat foglalja össze azokat a szûrõket, amelyekkel az LPD képes együttmûködni. Megtudhatjuk, hogy az /etc/printcap állományban melyik tulajdonság tartozik hozzájuk és hogyan hívjuk meg ezeket az lpr paranccsal: Állománytípus Tulajdonság az /etc/printcap állományban Az lpr kapcsolója cifplot cf DVI df plot gf ditroff nf FORTRAN forrás rf troff tf raster vf nyers szöveg if nincs, , vagy A példánkban tehát a lpr parancs használata arra utal, hogy a nyomtatónak az /etc/printcap állományból a df tulajdonságára van szüksége. FORTRAN Minden hadakozás ellenére állíthatjuk, hogy a FORTRAN források és a plot által használt szövegek formátuma napjainkra már elavultnak tekinthetõ. Ezért ezekhez az opciókhoz a saját szûrõinkkel tetszõleges formázási lehetõségeket rendelhetünk. Például, ha Printerleaf (az Interleaf asztali kiadványszerkesztõ formátuma) állományokat szeretnénk közvetlenül nyomtatni, akkor valószínûleg nem lesz szükségünk plot állományokra. Ezért a gf tulajdonságnak megadhatunk egy Printerleaf konverziós szûrõt, amelyen keresztül aztán a felhasználók az lpr paranccsal Printerleaf állományokat tudnak nyomtatni. Konverziós szûrõk telepítése Mivel a konverziós szûrõk az alap &os; rendszeren kívülre kerülnek, ezért ezeket minden valószínûség szerint - valahol a /usr/local + valahol a /usr/local könyvtárban találjuk meg. Ezen belül is általában a - /usr/local/libexec + /usr/local/libexec könyvtárban fordulnak elõ, mivel ezeket csak az LPD futtatja, senki másnak nincs rájuk szüksége. A konverziós szûrõk aktiválásához az /etc/printcap állományban egyszerûen adjuk meg az alkalmas tulajdonságoknak megfelelõ szûrõk elérési útvonalait. A példánkban most felveszünk egy DVI konverziós szûrõt a bamboo nevû nyomtatóhoz. Itt ismét láthatjuk a korábban használt /etc/printcap állományt, ahol most azonban a bamboo nevû nyomtatónál hozzáadtunk egy df tulajdonságot: # # /etc/printcap (rose) - egy df szûrõ hozzáadása a bamboo # nevû nyomtatóhoz # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0:\ :if=/usr/local/libexec/if-simple: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:\ :lp=/dev/ttyd5:ms#-parenb cs8 clocal crtscts:rw:\ :if=/usr/local/libexec/psif:\ :df=/usr/local/libexec/psdf: A DVI szûrõ ebben az esetben a /usr/local/libexec/psdf néven elérhetõ aprócska szkript. Ezt találhatjuk benne: #!/bin/sh # # psdf - DVI szûrõ PostScript nyomtatóhoz # Helye: /usr/local/libexec/psdf # # Az lpr -d parancs hatására hívódik meg # exec /usr/local/bin/dvips -f | /usr/local/libexec/lprps "$@" A szkript a dvips parancsot szûrõként futtatja (az paraméterrel) a szabványos bemenetrõl, ahova a nyomtatási munkát is kapja. Ezután elindítja az lprps &postscript; szûrõt (lásd a Szöveges nyomtatási feladatok &postscript; nyomtatókon címû szakaszt) az LPD által átadott paraméterekkel. Az lprps parancs ezekkel a paraméterekkel tartja nyilván az így kinyomtatott lapokat. További példák konverziós szûrõkre A konverziós szûrõk telepítésének nincs bevált receptje, ezért ebben a szakaszban bemutatunk rájuk néhány mûködõ illusztrációt. Ezeket tudjuk felhasználni saját szûrõk elkészítésére. Vagy ha megtehetjük, használjuk közvetlenül ezeket. Ebben a példa szkriptben Hewlett Packard LaserJet III-Si nyomtatókhoz hozunk létre raszteres (pontosabban GIF formátumú) konverziós szûrõt: #!/bin/sh # # hpvf - GIF állományokat konvertál át HP/PCL-be, majd kinyomtatja # Helye: /usr/local/libexec/hpvf PATH=/usr/X11R6/bin:$PATH; export PATH giftopnm | ppmtopgm | pgmtopbm | pbmtolj -resolution 300 \ && exit 0 \ || exit 2 Úgy mûködik, hogy a GIF állományt elõször PNM (portable anymap), utána PGM (portable graymap), majd PBM (portable bitmap) formátumúra alakítja, amibõl végül LaserJet/PCL-kompatibilis adat lesz. Ez lesz a hozzátartozó /etc/printcap állomány: # # /etc/printcap (orchid) # teak|hp|laserjet|Hewlett Packard LaserJet 3Si:\ :lp=/dev/lpt0:sh:sd=/var/spool/lpd/teak:mx#0:\ :if=/usr/local/libexec/hpif:\ :vf=/usr/local/libexec/hpvf: A most következõ szkript a groff betûszedû rendszerbõl érkezõ troff adatokat alakítja át a bamboo nevû &postscript; nyomtató számára: #!/bin/sh # # pstf - a groff troff adait alakítja PS-re, majd kinyomtatja # Helye: /usr/local/libexec/pstf # exec grops | /usr/local/libexec/lprps "$@" A szkript az lprps parancs segítségével kommunikál a nyomtatóval. Ha a nyomtatónk párhuzamos porton csatlakozik, akkor helyette ezt a szkriptet használjuk: #!/bin/sh # # pstf - a groff troff adatait alakítja PS-re, majd kinyomtatja # Helye: /usr/local/libexec/pstf # exec grops Kész is! A szûrõ éltrekeltéséhez mindössze ennyit kell beillesztenünk az /etc/printcap állományba: - :tf=/usr/local/libexec/pstf: + :tf=/usr/local/libexec/pstf: Most pedig jöjjön a FORTRAN szerelmeseinek szívét megmelengetõ szkript. Ez egy olyan szövegszûrõ, amely bármelyik nyers szöveget közvetlenül kezelni tudó nyomtató esetén mûködik. A teak nevû nyomtatóhoz helyezzük be: #!/bin/sh # # hprf - FORTRAN szövegszûrõ LaserJet 3si-hez # Helye: /usr/local/libexec/hprf # printf "\033&k2G" && fpr && printf "\033&l0H" && exit 0 exit 2 Az /etc/printcap állományban a teak nyomtatóhoz a következõ sor beírásával tudjuk engedélyezni ezt a szûrõt: :rf=/usr/local/libexec/hprf: Most pedig következzen egy utolsó, de az eddigieknél valamivel összetettebb példa. Ebben a korábban bemutatott teak nevû LaserJet nyomtatóhoz fogunk hozzáadni egy DVI szûrõt. Elõször is következzen a mûvelet egyszerûbb része: bõvítsük ki az /etc/printcap állományt a DVI szûrõ helyének megadásával: :df=/usr/local/libexec/hpdf: Ezután következzék a nehezebb rész: a szûrõ elkészítése. Ehhez szükségünk lesz egy DVI-rõl LaserJet/PCL-re alakító programra. A &os; Portgyûjteményében (lásd A Portgyûjtemény) találunk is egyet: a csomag neve print/dvi2xx. A csomag telepítésével megkapjunk a nekünk kellõ dvilj2p programot, ami képes DVI-t LaserJet IIp, LaserJet III és a LaserJet 2000 típusok által ismert kódokra fordítani. A dvilj2p felhasználásától függetlenül a hpdf néven létrehozni kívánt szûrõnk még így is bonyolult lesz, hiszen a dvilj2p nem tud olvasni a szabványos bemenetrõl, hanem minden áron egy állománnyal akar dolgozni. Sõt, olyan állománnyal, amelynek .dvi kiterjesztése van, ezért még a /dev/fd/0 (vagyis a szabványos bemenethez tartozó eszközleíró) használata is akadályokba ütközik. Üröm még az örömünkben, hogy a /tmp könyvtárat sem tudjuk felhasználni ideiglenes link létrehozására: a szimbolikus linkeket a bin felhasználó és csoport birtokolja, a szûrõt pedig a daemon felhasználó futtatja. A /tmp könyvtárban rááadásul csak a tulajdonosaik képesek állományokat átnevezni vagy törölni (sticky bit). Ezért a szûrõ ugyan létre tudna hozni egy linket, azonban ezt a munkája végeztével nem lesz majd képes törölni, mivel a link egy másik felhasználóhoz tartozik. Ezért a szûrõ az aktuális könyvtárban fogja létrehozni ezt a szimbolikus linket, ami jelen esetünkben a nyomtatási rendszer által használt könyvtár lesz (ezt az /etc/printcap állomány sd tulajdonságával adjuk meg). Itt remekül el tudják végezni a feladataikat a szûrõk, különösen mivel (néha) több hely van itt, mint a /tmp könyvtárban. Végül lássuk magát a szûrõt: #!/bin/sh # # hpdf - DVI adat nyomtatása HP/PCL nyomtatón # Helye: /usr/local/libexec/hpdf PATH=/usr/local/bin:$PATH; export PATH # # Létrehozunk egy függvényt az átmeneti állományok törlésére. Ezek # az aktuális könyvtárban jönnek létre, ami pedig a nyomtatási # rendszer adott nyomtatóhoz tartozó könyvtára lesz. # cleanup() { rm -f hpdf$$.dvi } # # Létrehozunk egy függvényt a súlyos hibák kezelésére: írassunk ki # egy adott üzenetet és lépjünk ki a 2-es hibakóddal. Ezzel üzenünk # az LPD-nek, hogy ne nyomtatassa újra a munkát. # fatal() { echo "$@" 1>&2 cleanup exit 2 } # # Ha a felhasználó eltávolítja a munkát a sorból, akkor az LPD egy SIGINT # jelzést fog küldeni, ezért próbáljuk meg azt elkapni (néhány más egyéb # jelzéssel együtt), így még tudjuk törölni az ideiglenesen # létrehozott állományokat. # trap cleanup 1 2 15 # # Gondoskodjunk róla, hogy a feladat megkezdésekor még egyetlen # használt állomány sem létezik. # cleanup # # Kössük össze a szabványos bemenetet egy DVI állománnyal (amit # majd nyomtatni akarunk). # ln -s /dev/fd/0 hpdf$$.dvi || fatal "Cannot symlink /dev/fd/0" # # LF = CR+LF # printf "\033&k2G" || fatal "Cannot initialize printer" # # Alakítsuk át az adatot és nyomtassunk. A dvilj2p által visszaadott érték # nem túlságosan megbízható, ezért ne is foglalkozzunk vele. # dvilj2p -M1 -q -e- dfhp$$.dvi # # Takarítsunk el magunk után és lépjünk ki szabályosan # cleanup exit 0 Automatikus konverziók: a konverziós szûrõk helyett A konverziós szûrõk sokat segítenek egy kényelmes nyomtatási környezet kialakításában, azonban a használatukhoz a felhasználóknak (az &man.lpr.1; parancson keresztül) egyenként hivatkozniuk kell rájuk. Ha a rendszerünk felhasználói nem eléggé mûveltek számítástechnikai téren, akkor még egy szûrõ megadása is zavaró lehet számukra. Ami még ennél is rosszabb, hogy egy rosszul megadott szûrõ hatására a nyomtató sem fogja jól kezelni az adott állomány formátumát és erre válaszul akár többszáz lapot is pillanatok alatt kiköphet magából. A konverziós szûrõk telepítése helyett gyakran csak egy (alapértelmezett) szövegszûrõre van szükségünk, amely kideríti a nyomtatandó állomány pontos formátumát és magától elindítja a neki megfelelõ konverziós szûrõt. Ilyen esetekben például a file parancs pont a hasznunkra válhat. Persze bizonyos állománytípusok közt nagyon nehéz különbséget tenni — de ezekre továbbra is adhatunk még külön konverziós szûrõket. apsfilter nyomtatás szûrõk apsfilter A &os; Portgyûjteményében találhatunk egy apsfilter elnevezésû szövegszûrõt (print/apsfilter), ami képes ilyen automatikus konverzióra. Képes felismerni a nyers szöveget, &postscript; programokat, DVI és szinte bármilyen formátumú állományokat, lefuttatni rájuk a megfelelõ átalakítástokat, majd kinyomtatni ezeket. Kimeneti szûrõk Az LPD nyomtatási rendszer kezel egy eddig még nem tárgyalt szûrõtípust is: ez a kimeneti szûrõ. A kimeneti szûrõ a szövegszûrõhöz hasonlóan csak nyers szöveg nyomtatására használatos, de tartalmaz néhány egyszerûsítést. Ha kizárólag csak kimeneti szûrõket alkalmazunk, akkor: Az LPD az egész nyomtatási feladathoz egyetlen kimeneti szûrõt fog használni, nem pedig minden állományhoz külön. Az LPD a kimeneti szûrõ számára nem nyújt semmilyen segítséget a munkán belül szereplõ állományok kezdetének vagy végének megállapításában. Az LPD a szûrõnek nem adja át sem a felhasználó hozzáférését, sem pedig gépnevét, ezért nyilvántartásra nem alkalmas. Mindent összegezve lényegében csak két paramétert kap meg: szûrõnév -wszélesség -lhossz ahol a szélesség a kérdéses nyomtató pw tulajdonságából, a hossz pedig a pl tulajdonságából származik. Ne bûvöljön el minket a szûrõ egyszerûsége! Ha például a munkában minden állományt újabb lapon szeretnénk kezdeni, akkor azt kimeneti szûrõvel nem tudjuk megoldani. Erre a célra használjunk szövegszûrõt (másik nevén bemeneti szûrõt), lásd A szövegszûrõ telepítése szakaszt. Hovatovább, a kimeneti szûrõ valójában sokkal bonyolultabb abban a tekintetben, hogy a beérkezõ adatok közül neki kell kikeresnie a speciális jelentéssel bíró karaktereket ugyanúgy, ahogy az LPD helyett saját magának kell küldenie a jelzéseket. Azonban a kimeneti szûrõk használata elkerülhetetlen, ha például fejléclapokat akarunk nyomtatni, és esetleg még különbözõ inicializálásra használatos speciális kódokat vagy karakterláncokat akarunk ez elõtt kiküldeni. (Ellenben badarság a fejléclapoktól követelni a felhasználó adatait, hiszen az LPD a kimeneti szûrõnek nem ad semmilyen erre vonatkozó információt.) Egyetlen nyomtató esetén az LPD egyaránt lehetõvé teszi kimeneti, szöveg- és más egyéb szûrõk használatát. Ilyenkor az LPD a kimeneti szûrõn keresztül csak a fejlécet tartalmazó oldal (lásd a Fejléclapok szakaszt) nyomtatását indítja el. Ezt követõen az LPD arra számít, hogy a kimeneti szûrõ két karakter, az ASCII 031 és az ezt követõ ASCII 001, hatására leállítja magát. Amikor tehát a kimeneti szûrõ érzékeli ezt a két karaktert (031, 001), akkor a SIGSTOP jelzéssel le kell állnia. Miután az LPD lefuttatta a többi szûrõt, a SIGCONT jelzéssel újraindítja a kimeneti szûrõt. Ha van kimeneti szûrõnk, de nincs szövegszûrõnk, akkor az LPD minden további feldolgozás nélkül továbbadja a munkát a kimeneti szûrõnek. Ahogy már korábban is említettük, a kimeneti szûrõ a munkában levõ összes állományt egymás után nyomtatja ki, lapdobások vagy bármilyen más papírmozgatás nélkül, ezért valószínûleg nem ez kell nekünk. Az esetek túlnyomó részében ehhez elég egy szövegszûrõ. A korábban szövegszûrõként beharangozott lpf program kimeneti szûrõként is képes funkcionálni. Ha szükségünk lenne egy gyorsan összecsapható kimeneti szûrõre, és nem akarunk a speciális karakterek valamint a jelzések küldésével elidõzni, akkor próbálkozzunk az lpf használatával. Az lpf parancsot mellesleg becsomagolhatjuk egy olyan szkriptbe is, amely elvégzi a nyomtató számára szükséges inicializálást. Az <command>lpf</command> szövegszûrõ A &os; bináris terjesztéséhez mellékelt /usr/libexec/lpr/lpf program egy szövegszûrõ (bemeneti szûrõ), amely képes (az lpr paranccsal hozzáadott munkákat) tabulálni, (az lpr paranccsal felvett munkákban) a vezérlõkaraktereket figyelemen kívül hagyni, a munkában elõforduló törlések és behúzások nyomtatási pozícióját igazítani és nyilvántartani a kinyomtatott lapokat. Kimeneti szûrõként is tud viselkedni. Az lpf szûrõ rengeteg nyomtatási környezetben felhasználható. Habár nem képes a nyomtatónak inicializáló jelsorozatokat küldeni, mégis könnyû olyan szkriptet írni, amely elvégzi ezeket a hiányzó kezdeti beállításokat, majd lefuttatja az lpf szûrõt. oldalak nyilvántartása nyilvántartás nyomtató Az lpf akkor lesz képes helyesen számolni a kinyomtatott lapokat, ha ehhez az /etc/printcap állományban jól töltjük ki a pw és pl tulajdonságokat. Ezen értékek segítségével határozható meg ugyanis, hogy mennyi szöveg fért rá egy lapra és így mennyi lapot emésztett fel az adott felhasználó által küldött munka. A nyomtatás nyilvántartásával kapcsolatban A nyomtató használatának nyilvántartása címû szakaszt érdemes elolvasni. Fejléclapok Ha nagyon sok felhasználónk van, és sok különbözõ nyomtatót is használnak, akkor elõbb vagy utóbb minden bizonnyal elkerülhetetlenné fog válni a fejléclapok használata. munkalapok fejléclapok fejléclapok A fejléc-, vagy más néven munka vagy elválasztó lapok segítik elõ a kinyomtatott munkák azonosítását. A többi dokumentumtól kirívó módon, általában dekoratív keretben, nagy, vastag betûkkel nyomtatódnak ki, hogy a halomnyi papír között a felhasználók könnyedén megtalálhassák az elküldött munkáik eredményét. Természetesen a fejléclapok nyilvánvaló hátulütõje, hogy így minden munkához még egy lappal többet kell elhasználni és mivel gyakorlatilag néhány percnél tovább nincs is rájuk szükség, meglehetõsen hamar a kukába kerülnek. (A fejléclapok munkánként jönnek létre, nem pedig az munkákban levõ állományokhoz egyenként, ezért nem is akkora pazarlás ez.) Az LPD rendszer képes magától fejléclapokat készíteni a nyomtatásokhoz, amennyiben a nyomtatónk képes közvetlenül nyers szöveget nyomtatni. Ha &postscript; nyomtatónk van, akkor ennek legyártásához egy külsõ programra van szükségünk, lásd a Fejléclapok &postscript; nyomtatókon szakaszt. A fejléclapok engedélyezése Az Alacsonyszintû nyomtatóbeállítás címû szakaszban az /etc/printcap állományban a sh (úgy mint suppress header) tulajdonsággal kikapcsoltuk a fejléclapokat. A fejléclapok engedélyezéséhez mindösszesen el kell távolítanunk ezt az sh tulajdonságot. Ez túl egyszerû, nemde? Igen, ez így van. Elõfordulhat, hogy szükségünk van még egy olyan kimeneti szûrõre is, amely inicializáló karaktereket küld a nyomtatónak. Íme egy példa ehhez a Hewlett Packard PCL-kompatibilis nyomtatói esetére: #!/bin/sh # # hpof - Kimeneti szûrõ Hewlett Packard PCL-kompatibilis nyomtatókhoz # Helye: /usr/local/libexec/hpof printf "\033&k2G" || exit 2 exec /usr/libexec/lpr/lpf Az of tulajdonsággal adjuk meg a kimeneti szûrõt. A Kimeneti szûrõk szakaszban errõl részletesebben is olvashatunk. A korábban ismertetett teak nevû nyomtatóhoz most az alábbi minta /etc/printcap állományt mellékeljük. Itt engedélyeztük a fejléclapokat és hozzátettük az iménti kimeneti szûrõt: # # /etc/printcap (orchid) # teak|hp|laserjet|Hewlett Packard LaserJet 3Si:\ :lp=/dev/lpt0:sd=/var/spool/lpd/teak:mx#0:\ :if=/usr/local/libexec/hpif:\ :vf=/usr/local/libexec/hpvf:\ :of=/usr/local/libexec/hpof: Mostantól kezdve, amikor a felhasználók a teak nyomtatón akarnak nyomtatni, minden munkához kapni fognak egy fejléclapot. Amennyiben a kedves felhasználók mégis keresgetni akarják a nyomtatásaikat, az lpr paranccsal tetszõleges módon letilthatják azokat. Az &man.lpr.1; többi hasonló opcióját A fejléclapokhoz tartozó beállítások szakaszban találjuk. Az LPD minden fejléclap után egy lapdobást küld. Ha erre a célra a nyomtatónk egy eltérõ karaktert vagy karaktersorozatot használ, akkor azt az /etc/printcap állomány ff tulajdonságával határozhatjuk meg. A fejléclapok vezérlése A fejléclapok engedélyezésével az LPD egy ún. hosszú fejlécet fog készíteni, vagyis a felhasználót, gépet és a munkát jól azonosító, egész lapot kitöltõ óriási betûket. Erre egy példa (amiben a rose nevû géprõl kelly nyomtatta ki az outline elnevezésû munkát): k ll ll k l l k l l k k eeee l l y y k k e e l l y y k k eeeeee l l y y kk k e l l y y k k e e l l y yy k k eeee lll lll yyy y y y y yyyy ll t l i t l oooo u u ttttt l ii n nnn eeee o o u u t l i nn n e e o o u u t l i n n eeeeee o o u u t l i n n e o o u uu t t l i n n e e oooo uuu u tt lll iii n n eeee r rrr oooo ssss eeee rr r o o s s e e r o o ss eeeeee r o o ss e r o o s s e e r oooo ssss eeee Job: outline Date: Sun Sep 17 11:04:58 1995 Ezt követõen az LPD elküld még egy lapdobást is, ezért maga a munka egy új oldalon fog kezdõdni (kivéve, ha az /etc/printcap állományban az adott nyomtatóhoz tartozó bejegyzésben megadtuk az sf (úgy mint suppress form feeds, vagyis a lapdobások letiltása) tulajdonságot. Ha úgy jobban tetszik, akkor az /etc/printcap állományban a sb tulajdonsággal az LPD utasítható rövid fejlécek készítésére is. Ilyenkor a fejléclap tartalma mindössze ennyi lesz: rose:kelly Job: outline Date: Sun Sep 17 11:07:51 1995 Alapértelmezés szerint az LPD elõször a fejléclapot majd a munkát nyomtatja ki. Ezt a sorrendet az /etc/printcap állományban a hl (header last) tulajdonsággal meg tudjuk fordítani. A nyomtató használatának nyilvántartása Az LPD által felkínált fejléclapok használata során egyetlen irányelv érvényesül a nyilvántartásukban: a fejléclapok költségmentesek. De miért? Azért, mert kizárólag csak a kimeneti szûrõ képes a fejléclapok viselkedését irányítani, ami viszont nem képes semmiféle nyilvántartásra, hiszen nem kapja meg az ehhez szükséges felhasználói- vagy gépnév információkat, illetve nyilvántartásokat. Emiatt fogalma sincs róla, hogy kit terhel az adott nyomtató használata. Úgy sem tudjuk megoldani a problémát, ha a szöveg- vagy konverziós szûrõkben (ahol már rendelkezésünkre állnak a felhasználó és a gépének adatai) növeljük a lapok számát eggyel a munkában, mivel a felhasználók az lpr parancs használatával kedvük szerint letilthatják a fejléclapokat. Ezt ugyan alapvetõen a természetet óvni kívánó felhasználók részesítik elõnyben, de ettõl függetlenül sem erõszakolhatjuk rá mindenkire. Az sem elég, ha minden szûrõ létrehozza a saját fejlécét (amiért aztán pénzt kérhetnénk). Mivel ha a felhasználók az lpr paranccsal le akarják tiltani a fejlécek használatát, attól a szûrõkhöz még mindig létrejönnek, hiszen az LPD a opcióról semmilyen értesítést nem küld át a szûrõknek. Nos, ilyenkor mitévõk legyünk? A lehetõségeink: Elfogadjuk az LPD elvét, és nem számítunk fel költséget a fejléclapokra. Az LPD helyett egy másik nyomtatási rendszert használunk, például az LPRng rendszert. A Más nyomtatási rendszerek címû szakaszban kiderül, milyen alternatívák érhetõek el az LPD kiváltására. Írjunk mi magunk egy intelligens kimeneti szûrõt. Normális esetben a kimeneti szûrõk nem valók másra, csupán a nyomtató alaphelyzetbe hozására vagy egyszerûbb karakterkonverziók elvégzésére. Fejléclapokhoz és nyers szöveget tartalmazó munkákhoz remekül használható (ahol nincs szöveg- (avagy bemeneti) szûrõ). Azonban ha a nyers szövegekhez van szövegszûrõnk, akkor az LPD a kimeneti szûrõt csak a fejléclapokhoz indítja el. Emellett a kimeneti szûrõ az LPD által generált fejléc szövegébõl képes megmondani, melyik felhasználóhoz és géphez tartozik a szóbanforgó fejléc. A módszer egyetlen bökkenõje, hogy a nyilvántartásokat tároló állományról viszont még így se tudunk semmilyen információt szerezni (mivel nem kapjuk meg az af tulajdonsággal beállított állomány nevét). Ha azonban egy rendszerszinten elérhetõ állományba mentjük ezeket az adatokat, akkor akár bele is drótozhatjuk ezt a kimeneti szûrõbe. A kimeneti szûrõ az adatot megtalálásában ilyenkor úgy tudunk segíteni, ha az /etc/printcap állományban az sh (rövid fejléc) tulajdonságot állítjuk be. De ez igazából sok hûhó semmiért, és a felhasználók is jobban megbecsülik az olyan nagylelkû rendszergazdát, aki nem számítja fel nekik a fejléclapokat. Fejléclapok &postscript; nyomtatókon Ahogy arról már korábban is szó esett, az LPD képes többféle nyomtató számára is megfelelõ, nyers szövegû fejléclapokat készíteni. Persze a &postscript; közvetlenül nem képes nyers szövegek nyomtatására, ezért az LPD ezen lehetõsége lényegében használhatatlan — többnyire. Ilyen helyzetben a fejléclapok használatának nyilvánvaló módja, hogy minden szövegszûrõt fejlécek gyártására utasítunk. Ezek a szûrõk a felhasználóról és a gépérõl kapott információkból össze tudják állítani a megfelelõ fejléclapot. A megoldás hátránya, hogy ez még olyankor is megtörténik, amikor a felhasználók az lpr paranccsal küldik a munkájukat. Kísérletezzünk egy kicsit ezzel a módszerrel! A most következõ szkript három paramétert fogad el (a felhasználó hozzáférést, a gép és a munka nevét), majd ezekbõl létrehoz egy egyszerû &postscript; formátumú fejlécet: #!/bin/sh # # make-ps-header - PostScript fejléc létrehozása a szabvány kimenetre # Helye: /usr/local/libexec/make-ps-header # # # Ezek itt a PostScript által használt egységekben vannak megadva # (72/col vagy 28/cm). Írjuk át az általunk használt papírméretre, # A4-re vagy amit éppen használunk: # page_width=612 page_height=792 border=72 # # A paraméterek ellenõrzése. # if [ $# -ne 3 ]; then echo "Usage: `basename $0` <user> <host> <job>" 1>&2 exit 1 fi # # Mentsük el ezeket, leginkább az olvashatóság miatt. # user=$1 host=$2 job=$3 date=`date` # # Küldjük el a PostScript-kódot a szabványos kimenetre. # exec cat <<EOF %!PS % % Gondoskodjunk róla, hogy ne zavarjuk az utánunk következõ % felhasználó munkáját. % save % % Csináljunk egy csúf vastag szegélyt, körbe a papíron. % $border $border moveto $page_width $border 2 mul sub 0 rlineto 0 $page_height $border 2 mul sub rlineto currentscreen 3 -1 roll pop 100 3 1 roll setscreen $border 2 mul $page_width sub 0 rlineto closepath 0.8 setgray 10 setlinewidth stroke 0 setgray % % Jelenítsük meg a felhasználó azonosítóját szép, feltûnõ % betûkkel. % /Helvetica-Bold findfont 64 scalefont setfont $page_width ($user) stringwidth pop sub 2 div $page_height 200 sub moveto ($user) show % % Most pedig mutassuk az unalmas részleteket. % /Helvetica findfont 14 scalefont setfont /y 200 def [ (Job:) (Host:) (Date:) ] { 200 y moveto show /y y 18 sub def } forall /Helvetica-Bold findfont 14 scalefont setfont /y 200 def [ ($job) ($host) ($date) ] { 270 y moveto show /y y 18 sub def } forall % % Ennyi lett volna. % restore showpage EOF Ezzel a szkripttel pedig mindegyik konverziós- és szövegszûrõ elõször létrehoz egy fejléclapot, majd kinyomtatja a felhasználó munkáját. Íme egy korábban már bemutatott DVI szûrõ, amit most kiegészítünk a fejléclapok használatával: #!/bin/sh # # psdf - DVI szûrõ PostScript nyomtatóhoz # Helye: /usr/local/libexec/psdf # # Az lpr -d parancs hatására hívódik meg. # orig_args="$@" fail() { echo "$@" 1>&2 exit 2 } while getopts "x:y:n:h:" option; do case $option in x|y) ;; # Ignore n) login=$OPTARG ;; h) host=$OPTARG ;; *) echo "LPD started `basename $0` wrong." 1>&2 exit 2 ;; esac done [ "$login" ] || fail "No login name" [ "$host" ] || fail "No host name" ( /usr/local/libexec/make-ps-header $login $host "DVI File" /usr/local/bin/dvips -f ) | eval /usr/local/libexec/lprps $orig_args Láthatjuk, hogy a szûrõnek a felhasználói- és a gépnév megállapításához végig kell néznie a paraméterek listáját. Ez lényegében minden más konverziós szûrõnél ugyanígy néz ki. Ez a lista azonban a szövegszûrõk esetén némileg eltér (lásd a Hogyan mûködnek a szûrõk? szakaszt). Már az elõbbiekben is tárgyaltuk, hogy ez a megoldás, habár eléggé egyszerû, az lpr számára nem teszi lehetõvé a fejléclapok letiltását (a opció). Ha a felhasználóink kímélni akarják a fákat (vagy meg akarják úszni a fejléclapok égbeszökõ költségeit), akkor ezt nem tudják megtenni, hiszen a szûrõk minden munkához készíteni fognak fejléceket. Ezt a korlátozást csak úgy tudjuk elsöpörni, ha bevetjük a A nyomtató használatának nyilvántartása szakaszban leírt cselt, tehát készítünk egy olyan kimeneti szûrõt, amely megkeresi az LPD-vel generált fejléceket és létrehozza azok &postscript; változatát. Ha valaki az lpr paranccsal küld nyomtatnivalót, akkor LPD nem készít hozzá fejléclapot, ahogy a kimeneti szûrõnk sem. A kimeneti szûrõ minden más esetben beolvassa az LPD által küldött szöveget és átküldi a neki megfelelõ &postscript; kódot a nyomtatóra. Ha soros &postscript; nyomtatónk van, akkor használhatjuk a psof kimeneti szûrõhöz tartozó lprps parancsot is, ami pontosan az elõbbit végzi el. Hozzátennénk azonban, hogy a psof nem számolja a fejléclapokat. Hálózati nyomtatás nyomtató hálózati hálózati nyomtatás A &os; tud hálozaton is nyomtatni, vagyis tud távoli számítógépeknek is nyomtatási munkát küldeni. A hálózati nyomtatás kifejezés általánosságban véve két különbözõ dolgra utalhat: Egy távoli számítógéphez kapcsolt nyomtató hozzáférését. A géphez a nyomtató a hagyományos soros vagy párhuzamos csatolófelületen keresztül kapcsolódik, amit aztán az LPD alkalmas beállításával a hálózaton mindenki számára elérhetõvé teszünk. A Távoli számítógépekre csatlakoztatott nyomtatók címû szakasz errõl szól. Egy közvetlenül a hálózatra kapcsolt nyomtató hozzáférését. A nyomtató tehát rendelkezik még egy hálózati csatlakozással is a hagyományos soros vagy párhuzamos felület mellett (vagy éppen helyett). Egy ilyen nyomtató a következõképpen mûködhet: Elfogadja az LPD kéréseit, és még képes munkákat is tárolni. Ebben az esetben teljesen egyenértékû egy LPD alkalmazást futtató számítógéppel. Ekkor nincs más teendõnk, csak követnünk kell a Távoli számítógépeken telepített nyomtatók címû szakasz utasításait. Hálózati adatfolyamokkal dolgozik. Ebben az esetben a nyomtatót hozzá kell kapcsolnunk a hálózaton található egyik számítógéphez, ami majd a munkák tárolásáért és folyamatos küldéséért lesz felelõs. A Nyomtatók hálózati adatcsatlakozással szakasz az ilyen fajtájú nyomtatók telepítésére tesz néhány javaslatot. Távoli számítógépekre csatlakoztatott nyomtatók Az LPD nyomtatási rendszer alapból képes más, szintén LPD-t (vagy vele kompatibilis rendszert) futtató számítógépekre munkákat küldeni. Ezzel lényegében az egyik géphez hozzá tudunk kapcsolni egy nyomtatót, amit aztán a többiek számára elérhetõvé teszünk. Ez olyan nyomtatók esetében is mûködik, amelyek ismerik az LPD által alkalmazott protokollt. A távoli nyomtatáshoz elõször telepítsük a nyomtatót valamelyik számítógépre az Alacsonyszintû nyomtatóbeállítás szakaszban leírtak szerint, és ezzel az lesz a nyomtatószerverünk. Ezután, amennyiben szükségesnek találjuk, végezzünk magasabb szintû nyomtatóbeállításokat is. Ne felejtsük el kipróbálni a nyomtatón, hogy rendesen mûködik az LPD mindegyik olyan beállításával, amit engedélyeztünk. Emellett gondoskodjunk minden olyan jogosultságról is, amivel a helyi számítógéprõl el tudjuk érni a távoli számítógép által felkínált LPD szolgáltatást (lásd Távoli számítógépekrõl érkezõ kérések szabályozása). nyomtató hálózati hálózati nyomtatás Ha olyan nyomtatót használunk, aminek a hálózati felülete kompatibilis az LPD rendszerrel, akkor az elõbb említett nyomtatószerver lényegében maga lesz a nyomtató, valamint a nyomtató neve a rajta beállított név. Ezzel kapcsolatban olvassuk el a nyomtatóhoz és/vagy a hálózati csatolójához mellékelt dokumentációt. Amikor a Hewlett Packard Laserjet típusú nyomtatóit használjuk, a text nevû nyomtatónév magától elvégzi a LF és CRLF formátumú sortörések közti átalakítást, ezért ilyenkor nincs szükségünk a hpif szkriptre. Ezután ha szeretnénk más gépek részére is elérhetõvé tenni a frissen telepített nyomtatónkat, adjuk meg mindegyikük /etc/printcap állományában a következõket: Tetszõlegesen választott nevet, álneveket. Az egyszerûség kedvéért azonban itt érdemes ugyanazokat a neveket választani, mint amit a nyomtatószerveren is használunk. Szándékosan hagyjuk az lp tulajdonságot üresen (:lp=:). Hozzunk létre egy nyomtatási könyvtárat, és jelöljük meg a helyét az sd tulajdonsággal. Az LPD itt fogja összegyûjteni a munkákat, mielõtt elküldené azokat a nyomtatószervernek. Adjuk meg a nyomtatószerver nevét az rm tulajdonság segítségével. Az rp tulajdonsággal adjuk meg a nyomtatószerverre csatlakoztatott nyomtató nevét. Kész! Az /etc/printcap állományban már nem kell megadni konverziós szûrõket, oldalbeállításokat és semmi más egyebet. Lássunk mindezekre egy példát. A rose nevû számítógéphez két nyomtató csatlakozik, a bamboo és a rattan. Most pedig beállítjuk, hogy az orchid nevû gép felhasználói képesek legyenek ezekkel a nyomtatókkal dolgozni. Ekkor a most következõk szerint fog kinézni az orchid (a Fejléclapok engedélyezése szakaszban bemutatott) /etc/printcap állománya. Tartalmazza a teak nevû nyomtató beállításait is, és ehhez fogjuk hozzáadni a rose másik két nyomtatóját: # # /etc/printcap (orchid) - a rose két (távoli) nyomtatójának # hozzáadása # # # A "teak" egy helyi nyomtató, közvetlenül az orchidhoz # csatlakozik: # teak|hp|laserjet|Hewlett Packard LaserJet 3Si:\ :lp=/dev/lpt0:sd=/var/spool/lpd/teak:mx#0:\ :if=/usr/local/libexec/ifhp:\ :vf=/usr/local/libexec/vfhp:\ :of=/usr/local/libexec/ofhp: # # A "rattan" rose-hoz csatlakozik, így küldhetünk neki munkát: # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :lp=:rm=rose:rp=rattan:sd=/var/spool/lpd/rattan: # # A "bamboo" is a rose-hoz tartozik: # bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :lp=:rm=rose:rp=bamboo:sd=/var/spool/lpd/bamboo: Ezután más csak létre kell hoznunk a megfelelõ nyomtatási könyvtárakat az orchid nevû gépen: - &prompt.root; mkdir /var/spool/lpd/rattan /var/spool/lpd/bamboo -&prompt.root; chmod 770 /var/spool/lpd/rattan /var/spool/lpd/bamboo -&prompt.root; chown daemon:daemon /var/spool/lpd/rattan /var/spool/lpd/bamboo + &prompt.root; mkdir /var/spool/lpd/rattan /var/spool/lpd/bamboo +&prompt.root; chmod 770 /var/spool/lpd/rattan /var/spool/lpd/bamboo +&prompt.root; chown daemon:daemon /var/spool/lpd/rattan /var/spool/lpd/bamboo Mostantól kezdve az orchid felhasználói képesek lesznek nyomtatni a rattan és bamboo nevû nyomtatókon is. Ezért, ha az orchid egyik felhasználója beírja, hogy: &prompt.user; lpr bamboo sushi-leírás.dvi Az orchid gépen mûködõ LPD rendszer ezt a munkát a bemásolja a - /var/spool/lpd/bamboo nevû - nyomtatási könyvtárba és feljegyzi - róla, hogy a nyomtatásához DVI + /var/spool/lpd/bamboo + nevû nyomtatási könyvtárba és + feljegyzi róla, hogy a nyomtatásához DVI szûrõre lesz szükség. Ahogy rose gépen található bamboo nyomtatási könyvtárában elegendõ hely keletkezik, a két LPD átküldi egymás közt a rose nevû gépre az állományt. Ezután az állomány egészen addig várakozik a rose nyomtatási sorában, amíg végezetül kinyomtatásra nem kerül. A rose fogja átalakítani DVI-rõl &postscript; formátumra átalakítani (mivel a bamboo egy &postscript; nyomtató). Nyomtatók hálózati adatcsatlakozással Amikor hálózati kártyát vásárolunk a nyomtatónkhoz, általában két változatukkal találkozhatunk: az egyikük nyomtatási rendszerként mûködik (ez a drágább), a másikuk pedig egyszerûen csak soros vagy párhuzamos csatlakozón továbbítandó adatként közvetíti az adatokat a nyomtató felé (az olcsóbb). A drágábbik változatot az elõzõ, Távoli számítógépekre csatlakoztatott nyomtatók címû szakaszban leírtak szerint tudjuk használni. Az /etc/printcap állományban ugyan meg tudjuk adni, hogy a nyomtató soros vagy párhuzamos portra csatlakozik, és azon keresztül milyen adatátviteli sebességgel (amennyiben soros), forgalomirányítással, tabulálással, sortörési konvenció szerint stb. kommunikáljunk vele. Azonban TCP/IP vagy más hálózati porton ülõ nyomtatók adatait itt nem tudjuk kifejteni. A hálózatra kötött nyomtatók használatához lényegében egy olyan külön kifejlesztett kommunikációs programra van szükségünk, amely a szöveg- vagy konverziós szûrõkhöz hasonló módon hívható meg. Erre rögtön adunk is egy példát: a netprint szkript a szabványos bemenetrõl beolvassa az összes kinyomtatandó adatot és átküldi azokat a hálózatra csatlakoztatott nyomtatónak. A szkript elsõ paramétereként a nyomtató hálózati nevét adjuk meg, másodiknak pedig portot. Azonban megjegyezzünk, hogy ez csak egyirányú kommunikációt tesz lehetõvé (a &os;-tõl a nyomtatóig). Sok hálózati nyomtató viszont két irányban is képes kommunikálni, ezért érdemes lehet ezt kihasználni (a nyomtató állapotának lekérdezésére, nyilvántartások készítésére stb). #!/usr/bin/perl # # netprint - A hálózatra csatlakoztatott nyomtató szövegszûrõje # Helye: /usr/local/libexec/netprint # $#ARGV eq 1 || die "Usage: $0 <printer-hostname> <port-number>"; $printer_host = $ARGV[0]; $printer_port = $ARGV[1]; require 'sys/socket.ph'; ($ignore, $ignore, $protocol) = getprotobyname('tcp'); ($ignore, $ignore, $ignore, $ignore, $address) = gethostbyname($printer_host); $sockaddr = pack('S n a4 x8', &AF_INET, $printer_port, $address); socket(PRINTER, &PF_INET, &SOCK_STREAM, $protocol) || die "Can't create TCP/IP stream socket: $!"; connect(PRINTER, $sockaddr) || die "Can't contact $printer_host: $!"; while (<STDIN>) { print PRINTER; } exit 0; Rengeteg szûrõben fel tudjuk használni ezt a szkriptet. Például tegyük fel, hogy egy Diablo 750-N típusú sornyomtatót csatlakoztattunk a hálózatra, amely az 5100-as porton várja a nyomtatandó adatokat. A hálózati neve most scrivener lesz. Íme a hozzátartozó szövegszûrõ: #!/bin/sh # # diablo-if-net - Az 5100-as porton figyelõ `scrivener' nevû Diablo # nyomtató szövegszûrõje. Helye: /usr/local/libexec/diablo-if-net # exec /usr/libexec/lpr/lpf "$@" | /usr/local/libexec/netprint scrivener 5100 A nyomtató használatának szabályozása nyomtató a hozzáférés korlátozása Ebben a szakaszban a nyomtató használatának korlázásáról írunk. Az LPD rendszeren keresztül meghatározhatjuk, hogy ki képes helyben vagy távolról hozzáférni a nyomtatóhoz, mennyi másolatot nyomtathat, mennyi és egyenként mekkora munkákat küldhet. A másolatok számának szabályozása Az LPD segítségével a felhasználók egy állományt könnyen ki tudnak nyomtatni akár többször is. Ha (például) a felhasználó egy munka nyomtatásához az lpr parancsot használja, akkor a munkában levõ összes állományból öt példányt kap. Ennek létjogosultságát azonban nekünk kell megítélni. Amennyiben úgy érezzük, hogy a további példányok készítése csupán felesleges papír- és tintapazarlás, akkor az sc tulajdonság megadásával az /etc/printcap állományban kikapcsolhatjuk az &man.lpr.1; lehetõség használatát. Így amikor a felhasználók a kapcsolóval küldenek el munkákat a nyomtatóra, a következõt fogják tapasztalni: lpr: multiple copies are not allowed Fordítása: lpr: másolatok nyomtatása nem engedélyezett Vigyázzunk arra, hogy ha távoli számítógépen zajlik a nyomtatás (lásd Távoli számítógépekre csatlakoztatott nyomtatók), akkor az sc tulajdonságot a távoli számítógép /etc/printcap állományában is be kell állítani, máskülönben a felhasználók egy másik számítógéprõl mindig képesek lesznek több példány nyomtatására. Nézzünk erre egy példát. Itt most a rose nevû számítógép /etc/printcap állományát vesszük szemügyre. Ebben a rattan egy nagyon szívélyes nyomtató lesz, ezért engedélyezi a másolatok nyomtatását, azonban a bamboo nevû lézernyomtató nála már sokkal válogatósabb lesz, ezért a beállításai közt az sc tulajdonsággal kikapcsoljuk a másodpéldányok nyomtatását: # # /etc/printcap (rose) - A másolatok korlátozása a "bamboo" # nevû nyomtatón # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0:\ :if=/usr/local/libexec/if-simple: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:sc:\ :lp=/dev/ttyd5:ms#-parenb cs8 clocal crtscts:rw:\ :if=/usr/local/libexec/psif:\ :df=/usr/local/libexec/psdf: Az sc tulajdonságot az orchid /etc/printcap állományában is meg kell adni (és ha már itt vagyunk, akkor tegyük meg ugyanezt a teak esetében is): # # /etc/printcap (orchid) - Nincsenek másodpéldányok sem a helyi # "teak" nyomtatón, sem pedig a távoli "bamboo" nyomtatón teak|hp|laserjet|Hewlett Packard LaserJet 3Si:\ :lp=/dev/lpt0:sd=/var/spool/lpd/teak:mx#0:sc:\ :if=/usr/local/libexec/ifhp:\ :vf=/usr/local/libexec/vfhp:\ :of=/usr/local/libexec/ofhp: rattan|line|diablo|lp|Diablo 630 Line Printer:\ :lp=:rm=rose:rp=rattan:sd=/var/spool/lpd/rattan: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :lp=:rm=rose:rp=bamboo:sd=/var/spool/lpd/bamboo:sc: Az sc tulajdonság használatával ugyan megakadályozzuk az lpr parancs teljesítését, azonban ez még mindig nem óv minket attól, hogy a felhasználók képesek legyenek többször egymás után lefuttatni az &man.lpr.1; parancsot, vagy éppen egyetlen munkában több állományt is elküldeni: &prompt.user; lpr forsale.sign forsale.sign forsale.sign forsale.sign forsale.sign Számos módszer kínálkozik az effajta visszaélések kivédésére (beleértve a figyelmen kívül hagyást is), lehet velük kísérletezgetni! A nyomtatók hozzáférésének szabályozása A &unix; csoportkezelésével és az /etc/printcap állományban található rg tulajdonság felhasználásával korlátozni tudjuk, ki milyen nyomtatón dolgozhat. Ehhez mindösszesen annyit kell tennünk, hogy besoroljuk egy csoportba azokat a felhasználókat, amelyek hozzáférhetnek a nyomtatóhoz, és az rg tulajdonsággal megnevezzük azt. A csoporton kívüli felhasználókat (köztük magát a root felhasználót is) pedig ezután így üdvözli a rendszer, ha megpróbálnak valamit kinyomtatni egy korlátozott felhasználású nyomtatón: lpr: Not a member of the restricted group Az üzenet fordítása: lpr: Nem jogosult felhasználó Ha erre a távoli számítógépek esetén szükségünk lenne (lásd Távoli számítógépekre csatlakoztatott nyomtatók), akkor tegyük ugyanazt, mint amit az sc (a másodpéldányok letiltása, suppress multiple copies) tulajdonság esetén is, vagyis az rg tulajdonságot adjuk meg azokon a távoli számítógépeken is, amelyek hozzá tudnak férni a megosztott nyomtatóhoz. Például megengedjük, hogy a rattan nevû nyomtatót bárki használhassa, azonban a bamboo nyomtatón csak az artists nevû csoport használhatja. Következzen hát akkor a rose korábbról már ismert /etc/printcap állománya: # # /etc/printcap (rose) - A bamboo hozzáférésének korlátozása # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0:\ :if=/usr/local/libexec/if-simple: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:sc:rg=artists:\ :lp=/dev/ttyd5:ms#-parenb cs8 clocal crtscts:rw:\ :if=/usr/local/libexec/psif:\ :df=/usr/local/libexec/psdf: Most ne bántsuk a másik (az orchid nevû gépen levõ) /etc/printcap állományt. Így persze az orchid bármelyik felhasználója nyomtathat a bamboo nyomtatón. De ez most egy olyan eset, ahol egyébként lekorlátozzuk a orchid elérését is, ezért az ott beengedett felhasználók már akár használhatják is a nyomtatót. Vagy sem. Minden nyomtatóhoz csak egy ilyen csoportot adhatunk meg. A beküldött munkák méretének szabályozása nyomtatási munkák Ha sok felhasználó szeretne a nyomtatóinkhoz hozzáférni, akkor minden bizonnyal meg akarunk adni egy felsõ határt a felhasználók által beküldhetõ nyomtatások méretére vonatkozóan. Mivel a nyomtatási könyvtáraknak otthont adó állományrendszer is egyszer betelhet, ezért mindenképpen érdemes gondoskodni arról, hogy mindenki munkáját el tudjuk rendesen tárolni. nyomtatási munkák szabályozása Az LPD az mx tulajdonsággal lehetõséget ad arra, hogy lekorlátozzuk a munkákban található egyes állományok méretét. Ennek mértékegysége egy BUFSIZ blokk, ami pedig 1024 byte. Ha értékül nullát adunk meg, akkor nincs korlátozás, viszont ha semmit sem rögzítünk, akkor az mx tulajdonság alapértéke, vagyis 1000 blokk lesz a határ. Ez az érték a munkákban levõ egyes állományok méretére vonatkozik, nem pedig a munkák teljes méretére. Fontos tudni, hogy az LPD nem dobja vissza a méreten felüli állományokat. Ehelyett a méret alatti részt szépen berakja a sorba és kinyomtatja, a többi pedig elhagyja. Lehetne rajta vitázni, hogy ez mennyire helyes cselekedet. Példaképpen definiáljunk a korábban használt rattan és bamboo nyomtatóinkhoz ilyen korlátokat. Mivel az artists csoport tagjai hajlamosak nagy &postscript; állományokat küldeni, ezért most lekorlátozzuk ezt öt megabyte-ra. A szöveges nyomtatónk esetén azonban nem lesz semmilyen határ: # # /etc/printcap (rose) # # # Itt nincs korlát a munkákra: # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:mx#0:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0:\ :if=/usr/local/libexec/if-simple: # # Öt megabyte a PostScript: # bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:sc:rg=artists:mx#5000:\ :lp=/dev/ttyd5:ms#-parenb cs8 clocal crtscts:rw:\ :if=/usr/local/libexec/psif:\ :df=/usr/local/libexec/psdf: Ismét hozzátesszük, hogy ezek a korlátok csak a helyi felhasználókra vonatkoznak. Amennyiben távolról is el lehet érni ezt a nyomtatót, a távoli felhasználókat nem fog semmilyen korlátozás érinteni. Azokon a számítógépeken is meg kell adnunk az /etc/printcap állományban az mx tulajdonságot. Ehhez a Távoli számítógépekre csatlakoztatott nyomtatók címû szakaszban találunk segítséget. Van még egy speciális módszer, amivel képesek vagyunk szabályozni a távolról érkezõ kérések méretét. Errõl a Távoli számítógépekrõl érkezõ kérések szabályozása szakaszban olvashatunk. Távoli számítógépekrõl érkezõ kérések szabályozása Az LPD nyomtatási rendszer több módot is szolgáltat a távolról érkezõ nyomtatási munkák szabályozására: Az elérés szabályozása Az /etc/hosts.equiv és /etc/hosts.lpd állományok segítségével beállíthatjuk, hogy mely távoli számítógépektõl fogadjon el kéréseket az LPD. Az LPD minden kérés elfogadásakor ellenõrzi, hogy a küldõ számítógép címe szerepel-e az említett állományok valamelyikében. Ha nem, akkor az LPD visszautasítja a kérést. A két állomány felépítése egyszerû, mert bennük minden sorban egy-egy hálózati nevet adunk meg. Hozzátennénk azonban, hogy legyünk óvatosak, mivel az /etc/hosts.equiv állományt az &man.ruserok.3; protokoll is használja, ezért ennek módosítása hatással van az &man.rsh.1; és &man.rcp.1; programok mûködésére. Például most nézzük meg a rose /etc/hosts.lpd állományát: orchid violet madrigal.fishbaum.de Ennek megfelelõen tehát a rose elfogadja az orchid, violet és madrigal.fishbaum.de nevû távoli számítógépek kéréseit. Ha bármilyen más gép próbál hozzáférni a rose által felkínált LPD szolgáltatáshoz, visszautasítja. A méret szabályozása Szabályozhatjuk többek közt azt is, hogy mennyi szabad területnek kell fennmaradnia a nyomtatási könyvtárnak otthont adó állományrendszeren. A helyi nyomtató könyvtárában ehhez hozzunk létre egy minfree nevû állományt. Ide írjuk be, mennyi szabad lemezblokk (512 byte-os egység a lemezen) szükségeltetik egy távolról beérkezõ munka fogásához. Így gondoskodhatunk róla, hogy a távoli felhasználók nem fogják eltömíteni az állományrendszerünket, illetve ezzel egyúttal adhatunk némi elõnyt a helyi felhasználóknak is: õk ugyanis még azután is képesek lesznek munkákat küldeni a nyomtatónak, miután az állományrendszeren található szabad terület mennyisége már rég a minfree állományban szereplõ érték alá csökkent. Példaként most a bamboo nevû nyomtatónkhoz adjunk meg egy ilyen minfree állományt. Ehhez az /etc/printcap állományból tudjuk kideríteni a hozzátartozó nyomtatási könyvtárat. Lássuk tehát belõle a bamboo bejegyzését: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:sc:rg=artists:mx#5000:\ :lp=/dev/ttyd5:ms#-parenb cs8 clocal crtscts:rw:mx#5000:\ :if=/usr/local/libexec/psif:\ :df=/usr/local/libexec/psdf: A nyomtatási könyvtárat az sd tulajdonság határozza meg. Úgy állítjuk most be, hogy az LPD számára a távoli munkák fogadásához ebben a könyvtárban legalább három megabyte (6144 blokk) szabad területnek mindig lennie kell: &prompt.root; echo 6144 > /var/spool/lpd/bamboo/minfree A felhasználók szabályozása Az /etc/printcap állományban megadható rs tulajdonság segítségével korlátozhatjuk a helyi nyomtatókhoz hozzáférni képes távoli felhasználókat. Amikor az rs tulajdonság szerepel egy helyben csatlakozó nyomtató leírásánál, akkor az LPD csak abban az esetben fogad el távoli felhasználóktól munkát, ha a munkát küldõ felhasználónak ugyanazon a néven van a helyi gépen is hozzáférése. Máskülönben az LPD vissza fogja utasítani a kérést. Ez a tulajdonság különösen fontos olyan környezetben, ahol (például) több szervezeti egység használ egyetlen közös hálózatot és bizonyos felhasználók képesek átlépni szervezeti egységük határait, mivel ha a hozzáférést adunk neki a rendszereinkhez, akkor képesek a saját helyükrõl használni ezeket. Ha ehelyett csupán a nyomtatóinkat és a számítógépünk összes erõforrását akarjuk megosztani, akkor létrehozhatunk a számukra olyan token hozzáféréseket is, amikhez nem tartozik sem felhasználói könyvtár, sem pedig parancsértelmezõ (pontosabban a /usr/bin/false). A nyomtató használatának nyilvántartása nyilvántartás nyomtató Tehát szükségünk lenne a nyomtatások költségének elszámolására. Miért is ne tennénk ilyet? A papír és a tinta bizony pénzbe kerül, amihez még hozzájárulnak más egyéb karbantartási költségek is — a nyomtatók dugig vannak mindenféle mozgó alkatrésszel, amelyek elõbb-utóbbi el is romlanak. Tegyük fel, hogy a nyomtatóink kapacitása, kihasználtsága és karbantartási költsége alapján már megállapítottunk egy elszámolási egységet (oldalanként, méterenként, akárminként). De hogyan lássunk hozzá a nyomtatások költségének tényleges nyilvántartásához? Van egy rossz hírünk: az LPD nyomtatási rendszer önmaga nem tud segíteni ebben a feladatban. A nyilvántartás nagyban függ a használt nyomtatóktól, a nyomtatott formátumoktól és nyomtató általunk kiszabott költségeitõl. A nyilvántartás létrehozásához át kell írnunk a nyomtatóhoz tartozó szûrõt (a nyers szövegek költségének felszámításához) és konverziós szûrõket (a különféle formátumok költségei miatt), amikkel aztán számolhatjuk vagy lekérdezhetjük a kinyomtatott lapokat. Egyetlen kimeneti szûrõ használatával szinte semmire se megyünk, mivel az nem képes nyilvántartás vezetésére. Errõl bõvebb útmutatást a Szûrõk szakaszban találhatunk. Általánosságban véve két módon vezethetünk nyilvántartást: Az idõszakos elszámolás a gyakoribb, mivel ez az egyszerûbb. Amikor valaki kinyomtat egy munkát, a szûrõ a nyilvántartást tároló állományba feljegyzi a felhasználó azonosítóját, a gépének nevét és a kinyomtatott oldalakat. Ezután minden hónapban, félévben, évben vagy akár tetszõleges idõközönként összegyûjtjük a nyomtatók nyilvántartásait és külön feljegyezzük az egyes felhasználók nyomtatásait, majd benyújtjuk róla a számlát. Töröljük az összes naplóállományt, és tiszta lappal kezdjük a következõ idõszakot. Az azonnali elszámolás már nem annyira népszerû, mivel nehezebb megvalósítani. Ekkor a felhasználók már közvetlenül a nyomtatás után megkapják a számlát, hasonlóan a lemezkvótákhoz. Meg tudjuk akadályozni ezzel azt is, hogy a felhasználók túlléphessék az elõre kiszabott nyomtatási kvótájukat, amit persze menet közben lehet ellenõrizni és állítgatni. A felhasználók és kvótájuk nyomonkövetéséhez viszont szükségünk lesz egy kis adatbáziskezelésre is. Az LPD nyomtatási rendszer mind a két módszer kivitelezéséhez tud segítséget nyújtani, hiszen amikor szûrõket állítunk be (vagyis szinte mindig), lehetõségünk van a nyilvántartást végzõ programrészleteket is beilleszteni. És ami feltétlenül elõnyös: óriási mértékû rugalmasságot ajánl fel a nyilvántartás megvalósításához. Például magunk választhatjuk ki, hogy idõszakos vagy azonnali elszámolást alkalmazunk. Meg tudjuk adni, milyen információkat rögzítsünk: felhasználói neveket, számítógépek neveit, a munkák típusát, vagy a kinyomtatott oldalakat, a felhasznált lapok területét, a nyomtatások idõbeli igényeit és így tovább. Ehhez mindössze csak a szûrõket kell módosítani. Nyilvántartás gyorsan és egyszerûen A &os;-ben egybõl találunk is két programot, amivel pillanatok alatt ki tudunk alakítani egy egyszerû idõszakos elszámolási rendszert. Ezek Az lpf szövegszûrõ címû szakaszban ismertetett lpf és a nyomtatók nyilvántartásait tartalmazó állományok adatainak összegyûjtését és kiértékelését végzõ &man.pac.8;. Ahogy korábban már leírtuk a szûrõkrõl szóló szakaszban (Szûrõk), az LPD a szöveg- és konverziós szûrõket parancssorból a nyilvántartást tároló állomány nevével indítja el. Ezt a paramétert a szûrõk aztán fel tudják használni a nyilvántartások feljegyzéséhez. Az állomány nevét az /etc/printcap állományban szereplõ af tulajdonsággal tudjuk megadni, vagy teljes elérési úttal, vagy pedig a nyomtatási könyvtárhoz viszonyítva. Az LPD az lpf szûrõt a lap szélességének és hosszának megadásával indítja el (ezeket az értékeket a pw és pl tulajdonságokból származtatja). Az lpf ezek felhasználásával meg tudja mondani, mennyi papírt használtunk el. Miután kiküldte az állományt a nyomtatóra, nyilvántartásba is veszi. Ezek a típusú bejegyzések valahogy így néznek ki: 2.00 rose:andy 3.00 rose:kelly 3.00 orchid:mary 5.00 orchid:mary 2.00 orchid:zhang Minden nyomtatóhoz érdemes külön nyilvántartást vezetni, mivel az lpf nem tartalmaz semmilyen beépített zárolási megoldást, ezért két lpf párhuzamos futtatása könnyen összezagyválhatja a közösen használt nyilvántartások tartalmát. Az /etc/printcap állományban az af=acct tulajdonság megadásával könnyen létre tudunk hozni minden nyomtatóhoz külön nyilvántartást. Ilyenkor minden nyomtató könyvtárában megjelenik egy acct nevû állomány. Amikor elérkezünk a nyomtatások kiszámlázásához, futtassuk le a &man.pac.8; programot. Ehhez mindössze annyit kell tennünk, hogy átlépünk az elszámolni kívánt nyomtató könyvtárába és begépeljük a pac parancsot. Ekkor kapunk egy ehhez hasonló, dollár alapú kimutatást: Login pages/feet runs price orchid:kelly 5.00 1 $ 0.10 orchid:mary 31.00 3 $ 0.62 orchid:zhang 9.00 1 $ 0.18 rose:andy 2.00 1 $ 0.04 rose:kelly 177.00 104 $ 3.54 rose:mary 87.00 32 $ 1.74 rose:root 26.00 12 $ 0.52 total 337.00 154 $ 6.74 A &man.pac.8; a következõ paramétereket várja: Az kiértékelendõ nyomtató neve. Ez a paraméter csak akkor használható, ha az /etc/printcap állományban az af tulajdonságnak teljes elérési utat adtunk meg. A felhasználók nevei helyett a fizetendõ összeg szerint rendezze a listát. Hagyja figyelmen kívül a nyilvántartásban szereplõ gépek hálózati neveit. Ennek hatására az alpha géprõl nyomtató smith meg fog egyezni a gamma géprõl nyomtatóval. A beállítás nélkül ez a két felhasználó el fog térni. A paraméterként megadott ár dollár értékkel számol oldalanként vagy lábanként az /etc/printcap állományban megadott pc tulajdonság értéke helyett (ami alapból két cent). Az ár lebegõpontos (valós) számként is megadható. A rendezési sorrend megfordítása. Hozzon létre egy elszámolást, majd törölje a hozzá kapcsolódó nyilvántartási adatokat. név … Csak az adott nevû felhasználók adatait értékelje ki. A &man.pac.8; által alapértelmezés szerint generált kimutatásban láthatjuk az egyes gépekrõl származó egyes felhasználók kinyomtatott oldalait. Ha nekünk viszont nem számít, hogy honnan küldték a kéréseket (mivel bárhonnan lehet küldeni), akkor a pac paranccsal az alábbi táblázatot készítetthetjük el: Login pages/feet runs price andy 2.00 1 $ 0.04 kelly 182.00 105 $ 3.64 mary 118.00 35 $ 2.36 root 26.00 12 $ 0.52 zhang 9.00 1 $ 0.18 total 337.00 154 $ 6.74 Itt megtaláljuk a ténylegesen kifizetendõ összegeket is, amik kiszámításához a &man.pac.8; az /etc/printcap állomány pc tulajdonságát használja (ez alapból 200, avagy 2 cent oldalanként). Ezzel a tulajdonsággal tehát egy cent századrészében mérve tudjuk megadni az oldalakénti vagy lábankénti árakat. Ezt a beállítást természetesen a &man.pac.8; opciójával felül tudjuk bírálni. Arra azonban vigyázzunk, hogy a után dollárban kell megadnunk az árat. Emiatt tehát a &prompt.root; pac parancs szerint minden egyes oldal másfél dollárba fog kerülni. Ezzel az opcióval aztán alaposan megdönthetjük az árakat. Végezetül megemlítjük, hogy a pac parancs az általa létrehozott elszámolást egy külön állományba menti, amelynek a neve nagyjából megegyezik a nyilvántartást végzõével, de _sum-ra (mint summary, azaz elszámolás) végzõdik. Ezután nullázza a nyilvántartást. Amikor a &man.pac.8; programot újra lefuttatjuk, újból beolvassa a korábban elmentett elszámolásokat, majd hozzászámolja a többit a hagyományos nyilvántartási adatokból. Hogyan tudjuk számolni a kinyomtatott lapokat? A nyilvántartás pontos vezetéséhez még távolról is valamilyen módon meg kell tudnunk mondani, hogy mennyi lapot használt egy nyomtatási munka végrehajtása. Ez a nyomtatás nyilvántartásának egyik alapvetõ problémája. A nyers szövegek esetében ez nem is annyira bonyolult: egyszerûen számoljuk össze, hogy a munkában mennyi sor kinyomtatására lesz szükség és vessük össze ezt a nyomtató által lapoként kinyomtatott sorok számálva. Ne felejtsük el számításba venni a szövegben felbukkanó törlések hatását, vagy az olyan hosszú sorokat, amelyek a valóságban több sorban fognak megjelenni. Viszont (Az lpf szövegszûrõ címû szakaszban bemutatott) lpf program ezeket mind lekezeli a nyilvántartások készítése során. Ezért ha szintén egy nyilvántartást vezetni képes szövegszûrõt akarunk írni, akkor mindenképpen érdemes megnéznünk az lpf forráskódját. De hogyan bánjunk el a többi formátummal? Nos, a DVI-Laserjet és DVI-&postscript; közti átalakítások esetén a kinyomtatott lapok számának megállapításához meg kell tanítanunk a szûrõnket értelmezni a dvilj vagy dvips parancsok kimenetét. Ugyanezt meg tudjuk tenni más formátumok és más konverziós programok használata során is. Azonban ezek a módszerek nem veszik számításba, hogy a nyomtató egyáltalán ki is nyomtatta-e az összes elküldött oldalt. Sok minden történhet még addig, például beragadhat a papír, kifogyhat a tinta vagy akár felrobbanhat a nyomtató — a felhasználónak ettõl függetlenül még fizetnie kell. Mit lehet ilyenkor tenni? A precíz nyilvántartásnak csak egyetlen biztos módja létezik. Olyan nyomtatót szerezzünk be, amely képes megmondani, mennyi lapot használt el a nyomtatás során, majd egy ilyet csatlakoztassunk soros porton vagy hálózaton keresztül. Szinte majdnem az összes &postscript; nyomtató támogatja ezt a lehetõséget, ahogy sok más gyártmány és típus is (például a hálózati Imagen lézernyomtatók). A nyomtatóhoz tartozó szûrõt ehhez úgy kell módosítani, hogy lekérdezzük a kinyomtatott lapok számát a nyomtatás után és kizárólag erre az értékre alapozva készítünk nyilvántartást. Itt nincs szükség sem a sorok számolására, sem pedig az állományok (könnyen elhibázható) átvizsgálására. Természetesen lehetünk nagylelkûek és ne számítsunk fel semmit a nyomtatásért. A nyomtatók használata nyomtató használat Ebbõl a szakaszból megtudhatjuk, hogyan használjuk a &os;-n beállított nyomtatónkat. Röviden most itt foglaljuk össze az ide tartozó felhasználói parancsokat: &man.lpr.1; Munkákat nyomtat ki. &man.lpq.1; Ellenõrzi a nyomtatási sorokat. &man.lprm.1; Munkákat vesz ki a nyomtatási sorokból. Ezek mellett létezik még a nyomtatók és a hozzájuk tartozó sorok irányítására alkalmas parancs is, az &man.lpc.8;, amelyre a A nyomtatók vezérlése címû szakaszban fogunk részleteiben kitérni. A nyomtatók/sorok /etc/printcap állományban szereplõ nevük szerinti megadásához az &man.lpr.1;, &man.lprm.1; és &man.lpq.1; parancsok közül mindegyik elfogadja a paramétert. Ennek köszönhetõen képesek vagyunk munkákat küldeni, eltávolítani vagy felügyelni az egyes nyomtatók soraiban. Ha nem használjuk a kapcsolót, akkor az érintett nyomtató a PRINTER környezeti változó által meghatározott lesz. Végül, ha a PRINTER nevû környezeti változót sem állítottuk be, akkor a parancsok alapértelmezett módon az lp nevû nyomtatót fogják használni. A továbbiakban az alapértelmezett nyomtató kifejezés a PRINTER környezeti változó által megnevezett nyomtatóra fog utalni, illetve ha ezt nem definiáltuk, akkor az lp nevû nyomtatóra. Munkák nyomtatása Az állományok kinyomtatásához írjuk be: &prompt.user; lpr állománynév ... nyomtatás Ezzel kinyomtatjuk az összes felsorolt állományt az alapértelmezett nyomtatón. Ha nem adunk meg állományokat, akkor az &man.lpr.1; parancs a szabványos bemenetrõl várja a nyomtatandó adatokat. Például ezzel a paranccsal néhány igen fontos rendszerállományt tudunk kinyomtatni: &prompt.user; lpr /etc/host.conf /etc/hosts.equiv A nyomtató megválasztásához így adjuk ki a parancsot: &prompt.user; lpr nyomtatónév állománynév ... Ez a példa kinyomtatja az aktuális könyvtár részletes listáját a rattan nevû nyomtatón: &prompt.user; ls | lpr rattan Mivel egyetlen állományt sem adtunk meg az &man.lpr.1; programnak, az lpr parancs a nyomtatandó adatokat a szabványos bemenetrõl várja, ami jelen esetünkben a ls parancs kimenete. Az &man.lpr.1; ezeken felül még képes értelmezni rengeteg formázásra, konverzióra, másolatok készítésére stb. utasító kapcsolót is. Errõl bõvebben a Nyomtatási beállítások címû szakaszban lesz szó. Munkák felügyelete nyomtatási munkák Amikor az &man.lpr.1; programmal nyomtatunk, az összes nyomtatandónk egy nyomtatási munkának nevezett csomagba kerül, ami pedig az LPD nyomtatási rendszerébe. Minden nyomtatóhoz tartozik egy nyomtatási sor, ahol részünkrõl és mások által eddig kiadott munkákat találhatjuk. A nyomtató ezután ezeket a munkákat érkezési sorrend szerint dolgozza fel. Az alapértelmezett nyomtatóhoz tartozó sor állapotát az &man.lpq.1; programmal tudjuk megnézni. Ha egy adott nyomtatóra vagyunk kíváncsiak, akkor használjuk a kapcsolót. Például a &prompt.user; lpq bamboo parancs a bamboo nevû nyomtató sorát fogja megmutatni. Példaképpen lássuk is ilyen esetben az lpq parancs eredményét: bamboo is ready and printing Rank Owner Job Files Total Size active kelly 9 /etc/host.conf, /etc/hosts.equiv 88 bytes 2nd kelly 10 (standard input) 1635 bytes 3rd mary 11 ... 78519 bytes Itt három munkát láthatunk a bamboo nyomtatási sorában. Az elsõ munka, amit a kelly nevû felhasználó küldött, a 9-es munkaszámot kapta. A nyomtatóhoz tartozó összes munka kap egy ilyen egyedi számot. Többnyire nyugodtan figyelmen kívül hagyhatjuk, azonban szükségünk lehet rá, ha éppen törölni kívánjuk a hozzátartozó munkát. Ezzel majd a Munkák eltávolítása címû szakaszban foglalkozunk. A kilences számú munka két állományt tartalmaz: ha a parancssorban több állományt adunk meg az &man.lpr.1; programnak, akkor az egy munkának számít. Ez egyben a pillanatnyilag aktív munka (ezt a Rank oszlopban szereplõ active érték jelzi), tehát a nyomtató éppen ezzel foglalatoskodik. A második munka közvetlenül az &man.lpr.1; szabványos bemenetére érkezett. A harmadik a mary nevû felhasználótól jött, és ez egy nagyobbacska munka. A nyomtatandó állomány elérési útvonala túlságosan hosszú ahhoz, hogy ki lehessen írni, ezért az &man.lpr.1; csak három pontot jelez ki helyette. Az &man.lpq.1; kimenetének elsõ sorai is nagyon hasznos információt tartalmaz: megtudhatjuk, mit csinál éppen (legalább is az LPD szerint) a nyomtató. A kapcsolóval az &man.lpq.1; parancstól kérhetünk sokkal részletesebb listázást is. Például így nézhet ki a lpq parancs eredménye: waiting for bamboo to become ready (offline ?) kelly: 1st [job 009rose] /etc/host.conf 73 bytes /etc/hosts.equiv 15 bytes kelly: 2nd [job 010rose] (standard input) 1635 bytes mary: 3rd [job 011rose] /home/orchid/mary/research/venus/alpha-regio/mapping 78519 bytes Munkák eltávolítása Ha meggondoltuk volna magunkat egy munka kinyomtatásáról, az &man.lprm.1; paranccsal még törölni tudjuk a sorból. Az &man.lprm.1; gyakran még a nyomtatás alatt álló munkát is képes eltávolítani, azonban elõfordulhat, hogy a munka egy része már nyomtatásra került. Az alapértelmezett nyomtató sorából csak úgy tudunk munkákat törölni, ha elõször az &man.lpq.1; segítségével megkeressük a számukat. Ha ez megvan, írjuk be: &prompt.user; lprm munkaszám Adott nyomtatóról a kapcsoló segítségével tudunk munkákat törölni. A most következõ parancs a bamboo nevû nyomtatóról törli a 10-es számú munkát: &prompt.user; lprm bamboo 10 Az &man.lprm.1; parancs esetén még használhatóak az alábbi rövidítések is: lprm - Eltávolítja a hozzánk tartozó az összes munkát (az alapértelmezett nyomtatón). lprm felhasználó Eltávolítja az adott felhasználóhoz tartozó összes munkát (az alapértelmezett nyomtatón). Kizárólag a rendszergazdák képesek erre, a rendes felhasználók csak a saját munkáikat törölhetik. lprm A munka száma, a felhasználói név vagy a megadása nélkül az &man.lprm.1; törli az alapértelmezett nyomtatón éppen aktív munkát, amennyiben az a miénk. Csak a rendszergazdák képesek bármilyen aktív munkát törölni. Ha kiegészítjük az imént említett rövidítéséket a paraméter megadásával, akkor az alapértelmezett nyomtató helyett bármelyik másikat is használhatjuk. Például ez a parancs eltávolítja az aktuális felhasználó összes munkáját a rattan nevû nyomtatón: &prompt.user; lprm rattan - Hálózati környezetben az &man.lprm.1; csak arról a géprõl engedi törölni a munkákat, amelyrõl küldték ezeket, még abban az esetben is, amikor ugyanaz a nyomtató más számítógépekrõl is elérhetõ. A következõ parancssorozat ezt igyekszik szemléltetni: &prompt.user; lpr rattan myfile &prompt.user; rlogin orchid &prompt.user; lpq rattan Rank Owner Job Files Total Size active seeyan 12 ... 49123 bytes 2nd kelly 13 myfile 12 bytes &prompt.user; lprm rattan 13 rose: Permission denied &prompt.user; logout &prompt.user; lprm rattan 13 dfA013rose dequeued cfA013rose dequeued Túl a nyers szövegen: nyomtatási beállítások Az &man.lpr.1; parancs számos olyan beállítást enged, amelyekkel a szövegek formázását, grafikák átalakítását illetve más állományformátumok használatát, másolatok készítését, munkák irányítását és még sok minden mást el tudunk végezni. Ebben a szakaszban pontosan ezekrõl a kapcsolókról lesz szó. Formázási és konverziós beállítások Az &man.lpr.1; most következõ opciói a munkákban található állományok formázását vezérlik. Akkor használjuk ezeket a beállításokat, ha a munka nem tartalmaz nyers szöveget, vagy ha nyers szöveget akarunk formázni az &man.pr.1; segédprogrammal. &tex; Például az alábbi parancs kinyomtat egy halászati-jelentés.dvi nevû (a &tex; betûszedû rendszerbõl már jól ismert) DVI állományt a bamboo nevû nyomtatón: &prompt.user; lpr bamboo -d halászati-jelentés.dvi Ezek a beállítások a munkában szereplõ minden egyes állományra vonatkoznak, ezért nem keverhetjük (például) a DVI és ditroff formátumú állományokat egy munkán belül. Ehelyett külön munkákban kell elküldenünk az eltérõ formátumú állományokat, és mindegyik munkához külön konverziós beállításokat kell megadnunk. A és kapcsolók kivételével az itt felsorolt összes beállításnak a kiválasztott nyomtatóhoz szüksége van a megfelelõ konverziós szûrõre. Például a opció használatához kell egy konverziós szûrõ a DVI formátumhoz. A Konverziós szûrõk címû szakasz errõl ad bõvebb tájékoztatást. Cifplot állományok nyomtatása. DVI állományok nyomtatása. FORTRAN forrás nyomtatása. Plot formátumú adatok nyomtatása. A kinyomtatott szöveg behúzásának növelése a szám értékével. Ha nem adjuk meg a számot, akkor ennek értéke 8 lesz. Ez a beállítás csak bizonyos konverziós szûrõkkel mûködik. Ne hagyjunk helyet az és a szám között. A szöveg formázás nélküli nyomtatása, vezérlõkarakterekkel együtt. Ditroff (eszközfüggetlen troff) adat nyomtatása. -p Nyomtatás elõtt a szöveg formázása a &man.pr.1; programmal. Lásd &man.pr.1;. Az állomány neve helyett a fejlécben a címet jeleníti meg a &man.pr.1;. Ennek a beállításnak csak a opcióval együtt van hatása. Troff adat nyomtatása. Raszteres adatok nyomtatása. Vegyünk az iméntiekre egy példát. A következõ parancs az &man.ls.1; szépen megformázott man oldalát nyomtatja ki az alapértelmezett nyomtatón: &prompt.user; zcat /usr/share/man/man1/ls.1.gz | troff -man | lpr A &man.zcat.1; kitömöríti az &man.ls.1; man oldalának forrását és átadja a &man.troff.1; parancsnak, ami ebbõl létrehoz a GNU troff formátumának megfelelõ kimenetet és továbbadja az &man.lpr.1; parancsnak, ami végül elküldi a munkát az LPD nyomtatási rendszernek. Mivel az &man.lpr.1; parancsnak megadtuk az kapcsolót, a nyomtatási rendszer a GNU troff formátumban érkezõ adatokat magától át fogja alakítani olyan formátumra, amit a nyomtató is képes lesz megérteni. Munkák kezelése Az &man.lpr.1; most felsorolandó beállításaival az LPD rendszert arra tudjuk utasítani, hogy a munkát különleges módon kezelje: -# példányszám Egyetlen példány helyett hozzon létre példányszám számú példányt a munkában található összes állományból. A rendszergazda a nyomtató kímélése érdekében ezt a lehetõséget letilthatja, amivel inkább a fénymásoló használatára ösztönzi a felhasználókat. Lásd A másolatok számának szabályozása szakasz. A beállítás illusztrálásaként most az alapértelmezett nyomtatón elõször nyomtassuk ki három példányt a parser.c, majd ezután a parser.h állományokból: &prompt.user; lpr parser.c parser.h -m A rendszer küldjön levelet a munka teljesítése után. Ekkor az LPD a munka elvégzése után levelet küld a helyi postafiókunkba. A levélben kifejti, hogy sikeres volt-e a nyomtatás, vagy esetleg valamilyen hiba keletkezett, és ha hiba történt, akkor pontosan mi is volt az. -s Ne másolja közvetlenül az állományokat a nyomtatási könyvtárba, hanem készítsen hozzájuk szimbolikus linkeket. Egy nagyobb munka nyomtatása esetén javasolt használni ezt a kapcsolót. Ezzel a megoldással helyet tudunk spórolni a nyomtatási könyvtárban (amikor a munkánk könnyen megtelítheti a nyomtatási könyvtárat tároló állományrendszert). Emellett idõt is takarítunk meg, mivel az LPD-nek nem kell a munka minden egyes bitjét átmásolni a nyomtatási könyvtárba. Van azonban egy hátránya: mivel az LPD ekkor közvetlenül az eredeti állományra fog hivatkozni, ezért a nyomtatás befejezéséig azt nem módosíthatjuk vagy törölhetjük. Ha egy távoli nyomtatónak küldjük a munkát, akkor az LPD a helyi és a távoli számítógép között mégis kénytelen lesz átmásolni a munkát, így a kapcsoló egyedül csak a helyi nyomtatási könyvtárban fog helyet spórolni. Ettõl eltekintve még ilyenkor is hasznunkra válhat. -r Törölje a munkában szereplõ állományokat, miután átmásolta ezeket a nyomtatási könyvtárba, vagy miután a kapcsoló használatával kinyomtatta ezeket. Nagy körültekintéssel használjuk! A fejléclapok beállításai Az &man.lpr.1; most következõ beállításai a munkák fejlécében megjelenõ szövegekre vannak hatással. Így ha letiltottuk a fejléclapok használatát, akkor ezek a kapcsolók lényegében semmit sem állítanak. A Fejléclapok címû szakaszból tudhatunk meg többet ezek beállításáról. -C szöveg A fejléclapon megjelenõ hálózati név helyett a szöveg fog szerepelni. A hálózati név általában annak a gépnek a neve, ahonnan a munkát küldték. -J szöveg A fejléclapon megjelenõ munka neve helyett a szöveg fog megjelenni. A munka neve általában a benne szereplõ elsõ állomány nevével egyezik meg, ha a szabványos bemenetrõl nyomtatunk, akkor egyszerûen csak stdin. -h Ne nyomtasson fejléclapot. Bizonyos helyeken elõfordulhat, hogy ennek a kapcsolónak nincs semmilyen hatása a fejléclapok létrehozásának módszerébõl fakadóan. A részleteket lásd a Fejléclapok szakaszban. A nyomtatók vezérlése A nyomtatóink rendszergazdájaként nekünk kell telepítenük, üzembe helyeznünk és kipróbálnunk ezeket. Az &man.lpc.8; parancs használatával még jobban képesek vagyunk kapcsolatba lépni velük. Az &man.lpc.8; paranccsal: el tudjuk indítani és le tudjuk állítani a nyomtatókat; be- és ki tudjuk kapcsolni a nyomtatási soraikat; át tudjuk rendezni az egyes sorokban található munkákat. Elõször is essen pár a fogalmakról: ha a nyomtató leállt, akkor semmit sem fog kinyomtatni a sorából. A felhasználók továbbra is képesek munkákat küldeni, amik azonban egészen addig fognak várakozni, amíg a nyomtatót el nem indítjuk vagy a sorát ki nem ürítjük. Ha egy sort kikapcsolunk, akkor (a root kivételével) egyetlen felhasználó sem képes munkákat küldeni a nyomtatónak. A bekapcsolt sorok képesek csak munkát fogadni. A nyomtató elindítható kikapcsolt sorral is, ilyenkor egészen addig folytatja a munkák kinyomtatását, amíg a sor ki nem ürül. Általánosan elmondható, hogy az &man.lpc.8; parancs használatához a root felhasználó jogosultságaira van szükségünk. Az &man.lpc.8; parancsot minden más esetben csak a nyomtató állapotának ellenõrzésére vagy a megakadt nyomtató újraindítására használhatjuk. Foglaljuk röviden össze az &man.lpc.8; parancsait. A legtöbb parancs kiadásához még szükséges egy nyomtatónév paraméter megadása is, amivel megnevezzük az utasítani kívánt nyomtatót. Helyette használható az all szó is, amivel az /etc/printcap állományban szereplõ összes nyomtatót egyszerre utasíthatjuk. abort nyomtatónév Az aktuális munka megszakítása és a nyomtató leállítása. Ha a nyomtatási sort még nem kapcsoltuk ki, a felhasználók küldhetnek további munkákat. clean nyomtatónév A nyomtató könyvtárából töröljük a régi állományokat. Esetenként adódhat, hogy bizonyos munkák állományait nem takarította el az LPD, különösen abban az esetben, amikor a nyomtatás vagy az adminisztrálás során keletkezett valamilyen hiba. Ez a parancs segít megtalálni a nyomtatási könyvtárból már kikopott állományokat és törli ezeket. disable nyomtatónév Az újonnan érkezõ munkák besorolásának kikapcsolása. Ha a nyomtató még mûködik, akkor folytatni fogja a sorban még bennmaradt munkák nyomtatását. A rendszergazda (a root) még a kikapcsolt sorok esetén is küldhet munkákat. Ez a parancs valójában akkor hasznos, ha egy új nyomtató vagy egy új szûrõ mûködését próbálgatjuk: ilyenkor érdemes kikapcsolni a nyomtatási sort és root felhasználóként munkákat küldeni. A többi felhasználó a tesztelés befejezéséig nem tud majd munkákat küldeni, vagyis egészen addig, amíg a nyomtatási sort vissza nem kapcsoljuk az enable paranccsal. down nyomtatónév üzenet A nyomtató üzemen kívül helyezése. Lényegében megegyezik egy disable és utána egy stop parancs kiadásával. Az üzenet akkor jelenik meg, amikor a valaki megpróbálja lekérdezni a nyomtató állapotát az lpc status paranccsal, vagy amikor megnézi a nyomtatási sorát az &man.lpq.1; paranccsal. enable nyomtatónév A nyomtatóhoz tartozó nyomtatási sor bekapcsolása. A felhasználók ezután már képesek lesznek a nyomtatónak munkákat küldeni, azonban egészen addig nem nyomtatódik ki semmi, amíg a nyomtató el nem indítjuk. help parancsnév Megmutatja a parancsnév parancshoz tartozó súgót. A parancsnév megadása nélkül a rendelkezésre álló parancsok listáját kapjuk meg. restart nyomtatónév Elindítja a nyomtatót. A felhasználók ezt a parancsot tudják használni abban az esetben, amikor valamilyen megmagyarázhatatlan okból az LPD mûködése megáll, viszont ezzel nem tudják elindítani a stop vagy down parancsokkal leállított nyomtatót. A restart parancs megegyezik az abort és a start egymás utáni kiadásával. start nyomtatónév Elindítja a nyomtatót, és a nyomtató nekilát kinyomtatni a sorában levõ munkákat. stop nyomtatónév Leállítja a nyomtatót, és a nyomtató az aktuális munka befejezése után már nem kezd neki újabbnak. Ettõl függetlenül a felhasználók még továbbra is képesek munkákat küldeni a nyomtatási sorába. topq nyomtatónév munka-vagy-felhasználónév Átrendezi a nyomtatónév nevû nyomtató sorát úgy, hogy a megadott azonosítójú munkát vagy a megadott felhasználónévhez tartozó munkákat a sor elejére teszi. Ennél a parancsnál nyomtatónévnek nem adhatjuk meg az all értéket. up nyomtatónév Üzembe helyezi a nyomtatót, tulajdonképpen a down parancs ellentéte. Megegyezik egy egymás után kiadott start és enable paranccsal. Az &man.lpc.8; a fenti parancsokat a parancssorból fogadja el. Ha itt nem adunk meg neki semmilyen parancsot, akkor az &man.lpc.8; interaktív módba vált, ahol ugyanezeket a parancsokat adhatjuk ki, egészen az exit, quit parancsok vagy az állományvége jelzés begépeléséig. Más nyomtatási rendszerek Ha derekasan végigolvastuk eddig ezt a fejezetet, akkor mostanra már valószínûleg mindent tudunk a &os;-ben található LPD nyomtatási rendszerrõl. Ezzel együtt tisztában vagyunk a hiányosságaival is, aminek kapcsán természetes módon felmerülhet bennünk a kérdés: Milyen más (&os;-vel is mûködni képes) nyomtatási rendszerek léteznek még? LPRng LPRng Az LPRng, aminek jelentése LPR Next Generation (Az LPR következõ generációja), a PLP teljesen újraírt változata. Patrick Powell és Justin Mason (a PLP eredeti karbantartója) együttes munkájának gyümölcse az LPRng. Az LPRng honlapja: . CUPS CUPS A CUPS, vagy más néven a Common UNIX Printing System (Közös &unix;-os nyomtatási rendszer), egy hordozható nyomtatási réteg nyújt a &unix;-alapú operációs rendszerek számára. Az Easy Software Products fejlesztése és szinte az összes &unix; gyártó és felhasználó szemében elfogadott szabványos nyomtatási rendszer. A CUPS a nyomtatási munkák és sorok kezelését az internetes nyomtatási protokollon (Internet Printing Protocol, IPP) használatával oldja meg. Csökkentett képességekkel ugyan, de a sornyomtató démon (Line Printer Daemon, LPD), szerverüzenet-blokk (Server Message Block, SMB), és AppSocket (más néven JetDirect) protokollokat is ismeri. A CUPS a komolyabb &unix;-os nyomtatási feladatokhoz ezeken felül még a hálózati nyomtatók közti választást és PostScript nyomtatók leírásán (PostScript Printer Description, PPD) alapuló nyomtatási beállításokat is támogatja. A CUPS honlapja: . Hibakeresés Miután az &man.lptest.1; programmal elvégeztünk néhány egyszerû próbát, a várt helyett a következõk egyikét kaphatuk eredményül: Egy kis idõ után minden remekül mûködött, vagy nem dobta ki az egész lapot. A nyomtató nyomtatott egy keveset, aztán egy ideig csendben maradt és nem csinált semmit. Ilyenkor a nyomtatnivalók megjelenéséhez minden bizonnyal meg kell nyomnunk a nyomtatón levõ PRINT REMAINING vagy FORM FEED feliratú gombokat. Ebben az esetben a nyomtató valószínûleg még arra várt, hogy még a nyomtatás megkezdése elõtt érkezik valamilyen további adat. Ettõl a gondtól úgy szabadulhatunk meg, ha beállítunk egy szövegszûrõt, amely minden (szükséges) esetben küld egy FORM FEED (lapdobás) jelzést is a nyomtatónak. Ez kell általában ahhoz, hogy a szöveg a nyomtató belsõ pufferében megmaradt része azonnal kinyomtatódjon. Akkor is a javunkra válhat ez, ha minden egyes munkát külön lapon akarunk kezdeni, mivel így a következõ munka sosem közvetlenül ott kezdõdik, ahol az elõzõ munka befejezte a nyomtatást. A /usr/local/libexec/if-simple szûrõ helyett a következõ szkript használhatával tudunk minden munka után elküldeni egy lapdobást: #!/bin/sh # # if-simple - Egyszerû lpd szövegszûrõ # Helye: /usr/local/libexec/if-simple # # Egyszerûen átmásolja a szabvány bemenetet a szabvány kimenetre, # és figyelmen kívül hagyja az összes többi paramétert. # Minden nyomtatási munka után küld egy lapdobást (\f). /bin/cat && printf "\f" && exit 0 exit 2 Lépcsõsen jelentek meg a sorok. Ekkor a következõt látjuk a lapon: !"#$%&'()*+,-./01234 "#$%&'()*+,-./012345 #$%&'()*+,-./0123456 MS-DOS OS/2 ASCII Az ún. lépcsõhatás áldozatává váltunk, amelyet a sortörést jelzõ karakter eltérõ értelmezései okoznak. A &unix; stílusú operációs rendszerek erre mindössze egyetlen karaktert használnak: ez a 10-es kódú ASCII karakter (sordobás, Line Feed, LF). Az &ms-dos;, &os2; és mások pedig két karakterrel oldják meg ezt a feladatot: a 10-es és 13-as kódú (kocsivissza, Carriage Return, CR) ASCII karakterekkel. A sortöréseknél sok nyomtató az &ms-dos; szokásait követi. Amikor a &os;-vel nyomtatunk, akkor csak egyetlen karaktert használunk sortörésre. Ennek láttán a nyomtató lépteti a sort, azonban a fej vízszintes pozícióját nem változtatja meg a következõ sor nyomtatásának megkezdésekor. Erre lenne a kocsivissza karakter, vagyis ennek hatására fogja a nyomtató a papír bal oldalára visszaállítani a következõ nyomtatandó karakter pozícióját. A &os; így szeretné utasítani a nyomtatót: A nyomtató kocsivisszát kap A nyomtató visszalépteti a pozíciót A nyomtató sordobást kap A nyomtató új sort kezd Néhány módszer ennek kiváltására: A nyomtatón található kapcsolók vagy vezérlõpanel segítségével próbáljuk meg átállítani a vezérlõkarakterek nyomtató szerinti értelmezését. Keressük meg a nyomtató kézikönyvében, hogyan tudjuk ezt megcsinálni. Ha a &os; mellett más operációs rendszerekkel is használni akarjuk a nyomtatót, akkor azok indítása elõtt mindig át kell állítani a nyomtatót a megfelelõ értelmezés alkalmazására. Ilyenkor valószínûleg a lentebb szereplõ megoldásokat részesítjük majd inkább elõnyben. Állítsuk be úgy a &os; soros vonali meghajtóját, hogy magától alakítsa át az LF karaktereket CR+LF párokká. Természetesen ez a megoldás csak a soros portra csatlakozó nyomtatók esetében mûködhet. Ehhez az /etc/printcap állományban a nyomtató leírásánál az ms# tulajdonságnál adjuk meg az onlcr módot. Küldjünk olyan kódot a nyomtatónak, amelynek hatására ideiglenesen máshogy fogja kezelni az LF karaktereket. Nézzük meg a nyomtatóhoz mellékelt útmutatóban, hogy milyen kódokat tudunk ilyen célra használni. Ha találtunk ilyen kódot, akkor írjuk át úgy a hozzátartozó szövegszûrõt, hogy a munkák elõtt mindig elküldjük azt. PCL Most bemutatjuk egy olyan szövegszûrõ kódját, amely a Hewlett-Packard PCL kódjait ismerõ nyomtatókhoz készült. Ebben a szûrõben elõször kiadjuk, hogy az LF karaktereket LF és CR karakterek kombinációjának tekintse a nyomtató, majd elküldjük magát a munkát, és a munka utolsó lapja után pedig elküldünk egy lapdobást. Szinte az összes Hewlett Packard nyomtatóval mûködnie kell. #!/bin/sh # # hpif - Egyszerû lpd bemeneti szûrõ a HP-PCL alapú nyomtatókhoz # Helye: /usr/local/libexec/hpif # # Egyszerûen átmásolja a szabvány kimenetet a szabvány bemenetre, és # figyelmen kívül hagyja a paramétereket. Elküldi a nyomtatónak, hogy # az LF karaktereket CR+LF-ként kezelje, majd a feladat befejeztével # lapot dobat. printf "\033&k2G" && cat && printf "\033&l0H" && exit 0 exit 2 Példaként megadjuk még az orchid nevû számítógép /etc/printcap állományát is. Ebben egyetlen nyomtató csatlakozik a párhuzamos portra, amelynek a típusa LaserJet 3Si és a neve teak. Az elõbb bemutatott szövegszûrõt használja: # # /etc/printcap (orchid) # teak|hp|laserjet|Hewlett Packard LaserJet 3Si:\ :lp=/dev/lpt0:sh:sd=/var/spool/lpd/teak:mx#0:\ :if=/usr/local/libexec/hpif: Egymásra írja a sorokat. A nyomtató nem lépteti a sorokat, ezért az összes sor egymáson jelenik meg. Ez pontosan a ritka ellentéte a fentebb leírt lépcsõhatásnak. A &os; által sortörésre használt LF karakterek valamiért CR karakterekként viselkednek, ezért a nyomtató nem sort vált, hanem a lap bal szélére állítja a fejet. A nyomtatón található kapcsolókkal vagy vezérlõpanellel így állítsuk be az sordobás és kocsivissza karakterek értelmezését: Amit a nyomtató kap Arra a nyomtató nyomtat CR CR LF CR + LF A nyomtató elhagy karaktereket. Miközben nyomtatunk, a nyomtató bizonyos karaktereket nem hajlandó megjeleníteni. A probléma ennél nagyobb, ha a nyomtató mûködése közben egyre több és több karaktert hagy ki. Itt az a gond, hogy a nyomtató nem képes tartani az iramot a számítógép által a soros vonalon átküldött adatok sebességével (ez a probléma nem jelentkezhet a párhuzamos nyomtatók esetén). Két módon kerekedhetünk felül ezen: Ha a nyomtató ismeri a XON/XOFF típusú forgalomirányítást, akkor az ms# tulajdonságnál adjuk meg a &os; számára az ixon beállítást. Ha a nyomtató ismeri a Request to Send / Clear to Send alapú hardveres kézfogást (más néven RTS/CTS forgalomirányítást), akkor az ms# tulajdonságnál a crtscts beállítást adjuk meg. Gondoskodjunk róla, hogy a számítógépet és a nyomtató összekötõ kábel meg tudjon majd bírkózni ezzel a típusú forgalomirányítással. Mindenféle szemetet nyomtat. A nyomtató nem a nyomtatni kívánt szöveget hozza létre, hanem össze-vissza nyomtat. Ez a soros nyomtatók helytelen kommunikációs beállításának egy másik jellemzõ tünete. Ellenõrizzük a br tulajdonságnál megadott adatátviteli sebességet és az ms# tulajdonságnál megadott paritási beállításokat. Egyeztessük a nyomtató saját és az /etc/printcap állományban tárolt beállításait. Semmi sem történik. Ha semmi sem történt, akkor a gond magával a &os;-vel lehet, nem pedig a hardverrel. Az /etc/printcap állományba a vizsgálni kívánt nyomtató leírásához (az lf tulajdonsággal) illesszünk be naplózást. Például így fog kinézni a rattan nevû nyomtató bejegyzése az lf tulajdonság megadásával kibõvítve: rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0:\ :if=/usr/local/libexec/if-simple:\ :lf=/var/log/rattan.log Miután ezt megcsináltuk, próbálkozzunk újra. Nézzük meg a naplóállományban (ami a példánkban a /var/log/rattan.log nevén érhetõ el), hogy látunk-e valamilyen hibaüzenetet. Az itt tapasztalt hibaüzenetek nyomán elindulva igyekezzünk megszüntetni a probléma forrását. Ha nem adjuk meg az lf tulajdonságot, akkor az LPD erre a célra alapértelmezés szerint a /dev/console állományt használja. diff --git a/hu_HU.ISO8859-2/books/handbook/security/chapter.sgml b/hu_HU.ISO8859-2/books/handbook/security/chapter.sgml index 47f43c519f..0f30cbff49 100644 --- a/hu_HU.ISO8859-2/books/handbook/security/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/security/chapter.sgml @@ -1,6214 +1,6214 @@ Matthew Dillon A fejezet legnagyobb részét a security(7) man oldal alapján írta: Biztonság biztonság Áttekintés Ez a fejezet egy alapvetõ bevezetés a rendszerek biztonsági fogalmaiba, ad néhány általános jótanácsot és a &os;-vel kapcsolatban feldolgoz néhány komolyabb témát. Az itt megfogalmazott témák nagy része egyaránt ráhúzható rendszerünk és általánosságban véve az internet biztonságára is. A internet már nem az békés hely, ahol mindenki a kedves szomszéd szerepét játssza. A rendszerünk bebiztosítása elkerülhetetlen az adataink, szellemi tulajdonunk, idõnk és még sok minden más megvédésére az internetes banditák és hasonlók ellen. A &os; segédprogramok és mechanizmusok sorát kínálja fel a rendszerünk és hálózatunk sértetlenségének és biztonságának fenntartására. A fejezet elolvasása során megismerjük: az alapvetõ rendszerbiztonsági fogalmakat, különös tekintettel a &os;-re; milyen olyan különbözõ titkosítási mechanizmusok érthetõek el a &os;-ben, mint például a DES és az MD5; hogyan állítsunk be egyszeri jelszavas azonosítást; hogyan burkoljunk az inetd segítségével TCP kapcsolatokat; hogyan állítsuk be a KerberosIV-t a &os; 5.0-nál korábbi változatain; hogyan állítsuk be a Kerberos5-t a &os;-n; hogyan állítsuk be az IPsec-et és hozzunk létre VPN-t &os;/&windows; gépek között; hogyan állítsuk be és használjuk az OpenSSH-t, a &os; SSH implementációját; mik azok az ACL-ek az állományrendszerben és miként kell ezeket használni; hogyan kell használni a Portaudit segédprogramot a Portgyûjteménybõl telepített külsõ szoftvercsomagok biztonságosságának ellenõrzésére; hogyan hasznosítsuk a &os; biztonsági tanácsait tartalmazó leírásokat mit jelent a futó programok nyilvántartása és hogyan engedélyezzük azt &os;-n. A fejezet elolvasásához ajánlott: az alapvetõ &os; és internetes fogalmak ismerete. A könyvben további biztonsági témákról is szó esik, például a ben a Kötelezõ hozzáférés-vezérlésrõl (MAC) és a ben pedig az internetes tûzfalakról. Bevezetés A biztonság egy olyan funkció, ami a rendszergazdától indul és nála is végzõdik. Míg az összes többfelhasználós BSD &unix; rendszer önmagában is valamennyire biztonságos, a felhasználók fegyelmezéséhez szükség további biztonsági mechanizmusok kiépítésére és karbantartására, ami minden bizonnyal egy rendszergazda egyik legfontosabb kötelessége. A számítógépek csak annyira biztonságosak, mint amennyire beállítjuk, és a biztonsági megfontolások állandó versenyben vannak az emberi kényelemmel. A &unix; rendszerek általánosságban véve órási mennyiségû program párhuzamos futtatására képesek, melyek többsége kiszolgálóként fut — ez azt jelenti, hogy hozzájuk kívülrõl érkezõ egyedek csatlakozhatnak és társaloghatnak velük. Ahogy a tegnap kicsi és nagy számítógépei napjaink asztali gépeivé váltak és ahogy a számítógépek egyre többen csatlakoznak hálózatra és az internetre, a biztonság fontossága is egyre jobban növekszik. A rendszerek biztonsága a támadások különbözõ formáival is foglalkozik, többek közt olyan támadásokkal, amelyek a rendszer összeomlását vagy használhatatlanságát célozzák meg, de nem próbálják meg veszélybe sodorni a root felhasználó hozzáférését (feltörni a gépet). A biztonsággal kapcsolatos problémák több kategóriára oszthatóak: A szolgáltatások mûködésképtelenné tételére irányuló (DoS, Denial of Service) támadások. A felhasználói fiókok veszélyeztetése. Rendszergazdai jogok megszerzése a közeli szervereken keresztül. Rendszergazdai jogok megszerzése a felhasználói fiókokon keresztül. Kiskapuk létrehozása a rendszerben. DoS támadás Denial of Service (DoS) biztonság DoS támadás Denial of Service (DoS) Denial of Service (DoS) A szolgáltatások mûködésképtelenné tételére irányuló támadások olyan tevékenységre utalnak, amelyek képesek megfosztani egy számítógépet az erõforrásaitól. A DoS támadások többnyire nyers erõvel kivitelezett technikák, melyek vagy a rendszer összeomlasztását vagy pedig a használhatatlanná tételét veszik célba úgy, hogy túlterhelik az általa felkínált szolgáltatásokat vagy a hálózati alrendszert. Egyes DoS támadások a hálózati alrendszerben rejtõzõ hibákat igyekeznek kihasználni, amivel akár egyetlen csomaggal is képesek romba dönteni egy számítógépet. Ez utóbbit csak úgy lehet orvosolni, ha a hibát kijavítjuk a rendszermagban. A szerverekre mért csapásokat gyakran ki lehet védeni a paramétereik ügyes beállításával, melyek segítségével korlátozni tudjuk az ezeket ért terhelést egy kellemetlenebb helyezetben. A nyers erõt alkalmazó hálózati támadásokkal a legnehezebb szembenézni. Például az álcázott támadadások, melyeket szinte lehetetlen megállítani, remek eszközök arra, hogy elvágják gépünket az internettõl. Ezzel viszont nem csak azt iktatják ki, hanem az internet-csatlakozásunkat is eldugítják. biztonság a hozzáférések megszerzése A DoS támadásoknál még gyakrabban elõfordul, hogy feltörik a felhasználók fiókjait. A rendszergazdák többsége még mindig futtat telnetd, rlogin, rshd és ftpd szervereket a gépen. Ezek a szerverek alapértelmezés szerint nem titkosított kapcsolaton keresztül mûködnek. Ebbõl következik, hogy ha nincs annyira sok felhasználónk és közülük néhányan távoli helyekrõl jelentkeznek be (ami az egyik leggyakoribb és legkényelmesebb módja ennek), akkor elõfordulhat, hogy valami megneszeli a jelszavaikat. A körültekintõ rendszergazdák mindig ellenõrzik a bejelentkezéseket tartalmazó naplókat és igyekeznek kiszûrni a gyanús címeket még abban az esetben is, amikor a bejelentkezés sikeres volt. Mindig arra kell gondolni, hogy ha a támadónak sikerült megszerezni az egyik felhasználó hozzáférését, akkor akár képes lehet a root felhasználó fiókjának feltörésére is. Azonban a valóságban egy jól õrzött és karbantarott rendszer esetén a felhasználói hozzáférések megszerzése nem feltétlenül adja a támadó kezére a root hozzáférését. Ebben fontos különbséget tenni, hiszen a root felhasználó jogai nélkül a támadó nem képes elrejteni a nyomait és legjobb esetben sem tud többet tenni, mint tönkretenni az adott felhasználó állományait vagy összeomlasztani a rendszert. A felhasználói fiókok feltörése nagyon gyakran megtörténik, mivel a felhasználók messze nem annyira elõvigyázatosak, mint egy rendszergazda. biztonság kiskapuk A rendszergazdáknak mindig észben kell tartani, hogy egy számítógépen több módon is meg lehet szerezni a root felhasználó hozzáférését. A támadó megtudhatja a root jelszavát, hibát fedezhet fel az egyik rendszergazdai jogosultsággal futó szerverben és képes feltörni a root hozzáférést egy hálózati kapcsolaton keresztül, vagy a támadó olyan programban talál hibát, aminek segítségével el tudja érni a root fiókját egy felhasználói hozzáférésen keresztül. Miután a támadó megtalálta a rendszergazdai jogok megszerzésének módját, nem feltétlenül kell kiskapukat elhelyeznie a rendszerben. Az eddig talált és javított, rendszergazdai jogok megszerzését lehetõvé tevõ biztonsági rések egy része esetében viszont a támadónak akkora mennyiségû munkát jelentene eltûntetni maga után a nyomokat, hogy megéri neki egy kiskaput telepíteni. Ennek segítségével a támadó ismét könnyedén hozzájuthat a root felhasználó hozzáféréséhez a rendszerben, de ezen keresztül egy okos rendszergazda képes is a behatolót leleplezni. A kiskapuk lerakásának megakadályozása valójában káros a biztonság szempontjából nézve, mert ezzel nem szüntetjük meg azokat a lyukakat, amin keresztül a támadó elõször bejutott. A támadások elleni védelmet mindig több vonalban kell megvalósítani, melyeket így oszthatunk fel: A rendszergazda és a személyzet hozzáférésének védelme. A rendszergazdai jogokkal futó szerverek és a suid/sgid engedélyekkel rendelkezõ programok védelme. A felhasználói hozzáférések védelme. A jelszavakat tároló állomány védelme. A rendszermag belsejének, a nyers eszközök és az állományrendszerek védelme. A rendszert ért szabálytalan módosítások gyors észlelése. Állandó paranoia. A fejezet most következõ szakaszában az imént felsorolt elemeket fejtjük ki részletesebben. A &os; védelme biztonság a &os; védelme Parancs kontra protokoll A dokumentumban a félkövéren fogjuk szedni az alkalmazásokat, és egyenszélességû betûkkel pedig az adott parancsokra hivatkozunk. A protokollokat nem különböztetjük meg. Ez a tipográfiai elkülönítés hasznos például az ssh egyes vonatkozásainak esetén, mivel ez egyben egy protokoll és egy parancs is. A most következõ szakaszok a &os; védelmének azon módszereit ismertetik, amelyekrõl a fejezet elõzõ szakaszában már írtunk. A rendszergazda és a személyzet hozzáférésének védelme su Elõször is: ne törjük magunkat a személyzeti fiókok biztonságossá tételével, ha még a rendszergazda hozzáférését sem tettük eléggé biztonságossá. A legtöbb rendszerben a root hozzáféréshez tartozik egy jelszó. Elsõként fel kell tennünk, hogy ez a jelszó mindig megszerezhetõ. Ez természetesen nem arra utal, hogy el kellene távolítanunk. A jelszó szinte mindig szükséges a számítógép konzolon keresztüli eléréséhez. Valójában arra szeretnénk rávilágítani, hogy a konzolon kívül sehol máshol ne lehessen használni ezt a jelszót, még a &man.su.1; paranccsal sem. Például gondoskodjunk róla, hogy az /etc/ttys állományban megadott pszeudó terminálokat insecure (nem biztonságos) típusúnak állítottuk be, és így a telnet vagy az rlogin parancsokon keresztül nem lehet rendszergazdaként bejelentkezni. Ha más szolgáltatáson keresztül jelentkezünk be, például az sshd segítségével, akkor ebben az esetben is gondoskodjunk róla, hogy letiltottuk a közvetlen rendszergazdai bejelentkezés lehetõségét. Ezt úgy tudjuk megtenni, ha megnyitjuk az /etc/ssh/sshd_config állományt és a PermitRootLogin paramétert átállítjuk a NO értékre. Vegyünk számba minden lehetséges hozzáférési módot — az FTP és a hozzá hasonló módok gyakran átszivárognak a repedéseken. A rendszergazdának csak a rendszerkonzolon keresztül szabad tudnia bejelentkeznie. wheel Természetesen egy rendszergazdának valahogy el kell érnie a root hozzáférést, ezért ezzel felnyitunk néhány biztonsági rést. De gondoskodjunk róla, hogy ezek a rések további jelszavakat igényelnek a mûködésükhöz. A root hozzáférés eléréséhez érdemes felvenni tetszõleges személyzeti (staff) hozzáféréseket a wheel csoportba (az /etc/group állományban). Ha a személyzet tagjait a wheel csoportba rakjuk, akkor innen a su paranccsal fel tudjuk venni a root felhasználó jogait. A személyzet tagjait létrehozásukkor közvetlenül sose vegyük fel a wheel csoportba! A személyzet tagjai elõször kerüljenek egy staff csoportba, és majd csak ezután az /etc/group állományon keresztül a wheel csoportba. A személyzetnek csak azon tagjait tegyük ténylegesen a wheel csoportba, akiknek valóban szükségük van a root felhasználó hozzáférésére. Ha például a Kerberost használjuk hitelesítésre, akkor megcsinálhatjuk azt is, hogy a Kerberos .k5login állományában engedélyezzük a &man.ksu.1; parancson keresztül a root hozzáférés elérését a wheel csoport alkalmazása nélkül. Ez a megoldás talán még jobb is, mivel a wheel használata esetén a behatolónak még mindig lehetõsége van hozzájutni a root hozzáféréséhez olyankor, amikor a kezében van a jelszavakat tároló állomány és meg tudja szerezni a személyzet valamelyik tagjának hozzáférését. A wheel csoport által felkínált megoldás ugyan jobb, mint a semmi, de kétségtelenül nem a legbiztonságosabb. A hozzáférések teljes körû letiltásához a &man.pw.8; parancsot érdemes használni: &prompt.root; pw lock személyzet Ezzel meg tudjuk akadályozni, hogy a felhasználó akármilyen módon, beleértve az &man.ssh.1; használatát is, hozzá tudjon férni a rendszerünkhöz. A hozzáférések blokkolásának másik ilyen módszere a titkosított jelszó átírása egyetlen * karakterre. Mivel ez a karakter egyetlen titkosított jelszóra sem illeszkedik, ezért a felhasználó nem lesz képes bejelentkezni. Ahogy például a személyzet alábbi tagja sem: izemize:R9DT/Fa1/LV9U:1000:1000::0:0:Ize-Mize:/home/izemize:/usr/local/bin/tcsh Erre cseréljük ki: izemize:*:1000:1000::0:0:Ize-Mize:/home/izemize:/usr/local/bin/tcsh Ezzel megakadályozzuk, hogy az izemize nevû felhasználó a hagyományos módszerekkel be tudjon jelentkezni. Ez a megoldás azonban a Kerberost alkalmazó rendszerek esetén nem mûködik, illetve olyan helyezetekben sem, amikor a felhasználó az &man.ssh.1; paranccsal már létrehozott magának kulcsokat. Az ilyen védelmi mechanizmusok esetében mindig egy szigorúbb biztonsági szintû géprõl jelentkezünk be egy kevésbé biztonságosabb gépre. Például, ha a szerverünk mindenféle szolgáltatásokat futtat, akkor a munkaállomásunknak egyetlen egyet sem lenne szabad. A munkaállomásunk biztonságossá tételéhez a lehetõ legkevesebb szolgáltatást szabad csak futtatnunk, de ha lehet, egyet sem, és mindig jelszóval védett képernyõvédõt használjuk. Természetesen ha a támadó képes fizikailag hozzáférni a munkaállomásunkhoz, akkor szinte bármilyen mélységû védelmet képes áttörni. Ezt mindenképpen számításba kell vennünk, azonban ne felejtsük el, hogy a legtöbb betörési kísérlet távolról, hálózaton keresztülrõl érkezik olyan emberektõl, akik fizikailag nem férnek hozzá a munkaállomásunkhoz vagy a szervereinkhez. KerberosIV A Kerberos és a hozzá hasonló rendszerek használatával egyszerre tudjuk a személyzet tagjainak jelszavát letiltani vagy megváltoztatni, ami egybõl érvényessé válik minden olyan gépen, ahová az adott felhasználónak bármilyen hozzáférése is volt. Nem szabad lebecsülnünk ezt a gyors jelszóváltási lehetõséget abban az esetben, ha a személyzet valamelyik tagjának hozzáférését megszerezték. Hagyományos jelszavak használatával a jelszavak megváltoztatása N gépen igazi káosz. A Kerberosban jelszóváltási megszorításokat is felállíthatunk: nem csak a Kerberos által adott jegyek járnak le idõvel, hanem a Kerberos rendszer meg is követelheti a felhasználóktól, hogy egy adott idõ (például egy hónap) után változtasson jelszót. A rendszergazdai jogokkal futó szerverek és SUID/SGID engedélyekkel rendelkezõ programok védelme ntalk comsat finger járókák sshd telnetd rshd rlogind A bölcs rendszergazda mindig csak akkor futtat szervereket, amikor szüksége van rá, se többet, se kevesebbet. Az egyéb fejlesztõktõl származó szerverekkel bánjunk különösen óvatosan, mivel gyakran hajlamosak hibákat tartalmazni. Például az imapd vagy a popper használata olyan, mintha az egész világnak ingyenjegyet osztogatnánk a rendszerünk root hozzáféréséhez. Soha ne futtassunk olyan szervert, amelyet nem vizsgáltunk át kellõ alapossággal. Sok szervert nem is feltétlenül kell root felhasználóként futtatni. Például az ntalk, comsat és finger démonok egy speciális járókában (sandbox) futnak. Ezek a járókák sem teljesen tökéletesek, hacsak erre külön figyelmet nem fordítunk. Ilyenkor a többvonalas védelem eszménye még mindig él: ha valakinek sikerült betörnie a járókába, akkor onnan ki is tud törni. Minél több védelmi vonalat húzunk a támadó elé, annál jobban csökken a sikerének valószínûsége. A történelem során lényegében minden root jogokkal futó szerverben, beleértve az alapvetõ rendszerszintû szervereket is, találtak már biztonsági jellegû hibát. Ha a gépünkre csak az sshd szolgáltatáson keresztül tudnak belépni, és soha nem használja senki a telnetd, rshd vagy rlogind szolgáltatásokat, akkor kapcsoljuk is ki ezeket! A &os; most már alapértelmezés szerint járókában futtatja az ntalkd, comsat és finger szolgáltatásokat. Másik ilyen program, amely szintén esélyes lehet erre, az a &man.named.8;. Az /etc/defaults/rc.conf megjegyzésben tartalmazza a named járókában futtatásához szükséges paramétereket. Attól függõen, hogy egy új rendszert telepítünk vagy frissítjük a már meglévõ rendszerünket, a járókákhoz tartozó speciális felhasználói hozzáférések nem feltétlenül jönnek létre. Amikor csak lehetséges, az elõrelátó rendszergazda kikísérletez és létrehoz ilyen járókákat. sendmail Vannak más olyan szerverek, amelyek tipikusan nem járókákban futnak. Ilyen többek közt a sendmail, popper, imapd, ftpd és még sokan mások. Léteznek rájuk alternatívák, de a telepítésük valószínûleg több munkát igényel, mint amennyit megérné számunkra veszõdni velük (és itt megint lesújt a kényelmi tényezõ). Ezeket a szervereket többnyire root felhasználóként kell futtatnunk és a rajtuk keresztül érkezõ betörési kísérleteket más módokra támaszkodva kell észlelnünk. A root felhasználó keltette biztonsági rések másik nagy csoportja azok a végrehajtható állományok a rendszerben, amelyek a suid és sgid engedélyekkel rendelkeznek, futtatásuk rendszergazdai jogokkal történik. Az ilyen binárisok többsége, mint például az rlogin, a /bin és /sbin, /usr/bin vagy /usr/sbin könyvtárakban található meg. Habár semmi sem biztonságos 100%-ig, a rendszerben alapértelmezetten suid és sgid engedéllyel rendelkezõ binárisok ebbõl a szempontból meglehetõsen megbízhatónak tekinhetõek. Alkalmanként azonban találnak a root felhasználót veszélyeztetõ lyukakat az ilyen binárisokban is. Például 1998-ban az Xlib-ben volt egy olyan rendszergazdai szintû hiba, amellyel az xterm (ez általában suid engedéllyel rendelkezik) sebezhetõvé vált. Mivel jobb félni, mint megijedni, ezért az elõretekintõ rendszergazda mindig igyekszik úgy csökkenteni az ilyen engedélyekkel rendelkezõ binárisok körét, hogy csak a személyzet tagjai legyenek képesek ezeket futtatni. Ezt egy olyan speciális csoport létrehozásával oldhatjuk meg, amelyhez csak a személyzet tagjai férhetnek hozzá. Az olyan suid binárisoktól pedig, amelyeket senki sem használ, igyekszik teljesen megszabadulni (chmod 000). A monitorral nem rendelkezõ szervereknek általában nincs szükségük az xterm mûködtetésére. Az sgid engedéllyel rendelkezõ binárisok is legalább ugyanennyire veszélyesek. Ha a behatoló képes feltörni egy kmem csoporthoz tartozó sgid binárist, akkor képes lesz olvasni a /dev/kmem állomány tartalmát, ezáltal hozzájut a titkosított jelszavakhoz és így megszerezheti magának akármelyik hozzáférést. Sõt, a kmem csoportot megszerzõ behatolók figyelni tudják a pszeudó terminálokon keresztül érkezõ billentyûleütéseket, még abban az esetben is, amikor a felhasználók egyébként biztonságos módszereket használnak. A tty csoportot bezsebelõ támadók szinte bármelyik felhasználó termináljára képesek írni. Ha a felhasználó valamilyen terminál programot vagy terminál emulátort használ a billentyûzet szimulációjával, akkor a behatoló tud olyan adatokat generálni, amivel a felhasználó nevében adhat ki parancsokat. A felhasználói hozzáférések védelme A felhasználók hozzáféréseit szinte a legnehezebb megvédeni. Míg a személyzet tagjaival szemben lehetünk kíméletlenül szigorúak és ki is csillagozhatjuk a jelszavukat, addig a felhasználók hozzáféréseivel általánosságban véve ezt nem tehetjük meg. Ha a kezünkben van a megfelelõ mértékû irányítás, akkor még gyõzhetünk és kényelmesen biztonságba helyezethetjük a felhasználók hozzáférését. Ha nincs, akkor nem tehetünk mást, mint állandóan õrködünk a hozzáférések felett. Az ssh és Kerberos használata a felhasználók esetén sokkalta problematikusabb, mivel ilyenkor jóval több adminisztrációra és mûszaki segítségnyújtásra van szükség, de még mindig jobb megoldás a titkosított jelszavakhoz képest. A jelszavakat tároló állomány védelme Az a legbiztosabb, ha minél több jelszót kicsillagozunk és a hozzáférések hitelesítésére ssh-t vagy Kerberost használunk. Igaz, a titkosított jelszavakat tároló állományt (/etc/spwd.db) csak a root képes olvasni, de a támadó meg tudja szerezni ezt a jogot még olyankor is, ha root felhasználóként nem feltétlenül tud írni. A rendszerünkben futó biztonsági szkripteknek a jelszavakat tároló állomány változását folyamatosan tudnia kell figyelnie és jelentie (lásd lentebb a Az állományok sértetlenségének ellenõrzése címû fejezetet). A rendszermag belsejének, a nyers eszközök és az állományrendszerek védelme Ha a támadó megszerzi a root hozzáférését, akkor szinte bármit képes megtenni, de vannak bizonyos elõnyei. Például a mostanság fejlesztett legtöbb rendszermag tartalmaz valamilyen beépített csomaglehallgatót, amit &os; alatt a bpf eszköz valósít meg. A támadók szinte mindig megpróbálnak valamilyen csomaglehallgatót használni a feltört gépen. A legtöbb rendszeren azonban nem kell feltétlenül megadnunk ezt az örömet, ezért nem is kell beépítenünk a rendszermagba a bpf eszközt. sysctl De ha még ki is iktatjuk a bpf eszközt, még aggódhatunk a /dev/mem és /dev/kmem miatt. Egyébként ami azt illeti, a behatoló még így is képes írni a nyers eszközökre. Sõt, a rendszermagba képesek vagyunk modulokat is betölteni a &man.kldload.8; használatával. A vállalkozó kedvû támadó a rendszermag moduljaként képes telepíteni és használni a saját bpf eszközét vagy bármilyen más, a csomagok lehallgatására alkalmas eszközt. Az ilyen problémák elkerülése érdekében a rendszermagot a legmagasabb védelmi szinten kell üzemeltetni, tehát legalább 1-esen. A védelmi szint szabályozása a sysctl parancson keresztül a kern.securelevel változó értékének beállításával lehetséges. Ahogy a védelmi szintet 1-re állítottuk, a nyers eszközök írása azonnal letiltódik és az olyan speciális állományjelzõk, mint például az schg hatása mûködésbe lép. Gondoskodnunk kell róla, hogy a rendszer indítása szempontjából fontos programok, könyvtárak és szkriptek rendelkezzenek az schg állományjelzõvel — minden, ami a védelmi szint beállításáig elindult. Ez némileg túlzás, és ezzel a rendszer frissítése is valamivel nehezebbé válik egy magasabb védelmi szinten. Megkockáztathatjuk azt is, hogy a rendszert magasabb védelmi szinten futtatjuk, de nem állítunk be minden egyes állományra és könyvtárra schg állományjelzõt. Megoldhatjuk úgy is a problémát, ha egyszerûen írásvédett módon csatlakoztatjuk a / és /usr állományrendszereket. Ehhez viszont hozzátennénk, hogy az ilyen szigorú védekezés egyben megakadályozza a betörések felderítéséhez szükséges összes információ összeszedését is. Az állományok sértetlenségének ellenõrzése: binárisok, konfigurációs állományok stb. Ha arról van szó, csak a legfontosabb rendszerszintû konfigurációs- és vezérlõállományokat tudjuk megvédeni, még mielõtt a korábban emlegetett kényelmi tényezõ kimutatná a foga fehérjét. Például, ha a chflags paranccsal beállítjuk az schg állományjelzõt a / és /usr állományrendszereken található legtöbb állományra, akkor az minden bizonnyal csökkenti a hatékonyságunkat, hiszen az állományok védelmének növekedésével csökken az észlelés lehetõsége. A védelmi vonalaink közül ugyanis az utolsó talán az egyik legfontosabb — a detektálás. A felépített biztonsági rendszerünk legnagyobb része szinte teljesen hasztalan (vagy ami még rosszabb, a biztonság hamis érzetét kelti), ha nem vagyunk képesek észrevenni a betörési kísérleteket. A védelmi rendszer egyik részére nem a támadó megállításához, hanem a lelassításához van szükség, hogy így majd munka közben érhessük tetten. A betörés tényét legjobban a megváltozott, hiányzó vagy éppen váratlanul felbukkanó állományok utáni kutatással tudjuk felismerni. A módosított állományokat általában egy másik (gyakran központosított) korlátozott hozzáférésû rendszerbõl ellenõrizhetjük a legjobban. Fontos, hogy ha egy korlátozott hozzáférésû, kiemelten védett rendszeren írjuk a védelemért felelõs szkripteket, akkor azok szinte teljesen láthatlanok lesznek a támadó számára. A legjobb kihasználás érdekében a korlátozott hozzáférésû gépnek jelentõs mértékû rálátással kell rendelkeznie az összes többi gépre, amit írásvédett NFS exportok vagy ssh kulcspárok felhasználásával érhetünk el. A hálózati forgalmat leszámítva az NFS látszik a legkevésbé — segítségével lényegében észrevétlenül tudjuk figyelni az egyes gépek állományrendszereit. Ha a megfigyelésre használt szerver a kliensekhez switchen keresztül csatlakozik, akkor az NFS gyakran jobb választásnak bizonyul. Ha a szerver hubon vagy több hálózati elemen keresztül éri el a megfigyelni kívánt klienseket, akkor az NFS nem eléggé biztonságos (és hatékony), ezért ilyen esetekben az ssh választása lehet a kedvezõ még az ssh által hagyott nyomokkal együtt is. Miután a korlátozott hozzáférésû gépünk legalább látja a hozzátartozó kliensek rendszereit, el kell készítenünk a tényleges monitorozást végzõ szkripteket. Ha NFS csatlakozást tételezünk fel, akkor az olyan egyszerû rendszereszközökkel, mint például a &man.find.1; és &man.md5.1; képesek vagyunk összerakni ezeket. A szemmel tartott kliensek állományait naponta legalább egyszer érdemes ellenõrizni md5-tel, valamint még ennél gyakrabban is tesztelni az /etc és /usr/local/etc könyvtárakban található konfigurációs és vezérlõállományokat. Ha valamilyen eltérést tapasztal az ellenõrzést végzõ szerverünk és a rajta levõ md5 információk is helyesek, akkor értesítenie kell a rendszergazdát. Egy jó védelmi szkript képes megkeresni az oda nem illõ suid binárisokat, valamint az új vagy törölt állományokat a / és a /usr partíciókon. A védelmi szkriptek megírása valamivel nehezebb feladat, ha ssh-t használunk az NFS helyett. A futtatásukhoz a szkripteket és az általuk használt eszközöket (például find) az scp paranccsal lényegében át kell másolni a kliensekre, amivel így láthatóvá válnak. Ne feledjük továbbá, hogy az ssh kliens már eleve feltört lehet. Szó, ami szó, ha nem megbízható összeköttetésekrõl beszélünk, akkor az ssh használata elkerülhetetlen, de nem feltétlenül egyszerû. Egy jó védelmi szkript észreveszi a felhasználók és a személyzet tagjainak hozzáférését vezérlõ állományokban, mint például az .rhosts, .shosts, .ssh/authorized_keys és társaiban keletkezett változásokat is, amelyek esetleg elkerülhetik egy MD5 alapú ellenõrzés figyelmét. Ha netalán órási mennyiségû tárterületettel rendelkeznénk, akkor eltarthat egy ideig, amíg végigsöprünk az összes partíció összes állományán. Ebben az esetben érdemes olyan beállításokat megadni az állományrendszerek csatlakoztatásánál, amivel le tudjuk tiltani a suid engedéllyel rendelkezõ binárisok futtatását. Ezzel kapcsolatban a &man.mount.8; parancs nosuid opcióját nézzük meg. Hetente legalább egyszer azért mégis érdemes átnézni az ilyen partíciókat is, mivel ez a réteg a betörési kísérletek felderítésével foglalkozik, függetlenül a sikerességüktõl. A futó programok nyilvántartása (lásd &man.accton.8;) egy olyan viszonylag kevés költséggel járó lehetõség az operációs rendszerben, ami segítségünkre lehet a betörés utáni események kiértékelésében. Különösen hasznos olyankor, amikor megpróbáljuk modellezni, miképp is sikerült a támadónak bejutnia a rendszerünkbe, természetesen feltételezve, hogy az ehhez felhasznált feljegyzések a betörés után is érintetlenek maradtak. Végül a védelmet ellátó szkripteknek javasolt feldolgozni a naplóállományokat is, valamint a naplókat magukat is a lehetõ legbiztonságosabb formában generálni — ilyenkor nagyon hasznos lehet, ha egy távoli gépre naplózunk. A behatoló megpróbálja majd eltüntetni a nyomait, a naplóállományok viszont nagyon fontosak a rendszergazda számára a betörési kísérletek idejének és módjának megállapításában. A naplókat úgy tudjuk tartósan rögzíteni, ha a rendszerkonzol üzeneteit soros porton keresztül gyûjtjük össze a konzolok felügyeletéért felelõs biztonságos gépen. Állandó paranoia Egy kis paranoia sosem árt. Elmondható, hogy a rendszergazda tetszõleges számú biztonsági intézkedéssel élhet egészen addig, amíg az nincs hatással a kényelmére, és a kényelmet befolyásoló biztonsági intézkedéseket pedig megfelelõ mérlegelés mellett tegye meg. Ami még ennél is fontosabb, hogy mindig változtassunk valamit a biztonsági hálónkon — mivel ha egy az egyben követjük a dokumentumban leírtakat, akkor ezzel együtt kiadjuk a bejutás receptjét annak a leendõ támadónknak, aki szintén elolvasta ugyanezt. A szolgáltatások mûködésképtelenné tételét célzó támadások Denial of Service (DoS) Ez a szakasz a szolgáltatások mûködésképtelenségét elérni kívánó, más néven Denial of Service típusú támadásokkal foglalkozik. Noha nem tudunk túlságosan sokat tenni a manapság felbukkanó álcázott, a hálózatunk totális leterhelését célbavevõ támadások ellen, akadnak olyan általános érvényû eszközök, amelyekkel elejét vehetjük a szervereink szétbomzásának: A létjövõ szerverpéldányok korlátozása. Az ugródeszkaszerû támadások (támadás ICMP-válasszal, pingszórás stb.) korlátozása. A rendszermag útválasztási gyorsítótárának túlterhelése. A DoS támadások egyik jellemzõ sémája szerint egy sokszorozódni képes szervert támadnak meg, amelynek igyekeznek minél több példányát legyártatni, míg végül az ezt futtató rendszer ki nem fogy a memóriából, állományleíróból satöbbibõl és megállásra nem kényszerül. Az inetd (lásd &man.inetd.8;) számos lehetõséget kínál fel ennek megakadályozására. Ezzel kapcsolatban szeretnénk megjegyezni, hogy bár ezzel el tudjuk kerülni a gépünk leállását, semmilyen garanciát nem ad arra, hogy a szolgáltatás a támadás során is zavartalanul üzemel tovább. Alaposan olvassuk el az inetd man oldalát és legyünk különös tekintettel a , és kapcsolóira. Vigyázzunk, hogy az inetd kapcsolóját képesek kijátszani az álcázott IP-vel érkezõ támadások, ezért inkább az elõbbi kapcsolók valamilyen kombinációja az ajánlott. Egyes szerverprogramoknál be lehet állítani a példányainak maximális számát. A Sendmail rendelkezik egy beállítással, ami a terhelésben levõ késleltetése miatt néha mintha jobban beválna, mint a Sendmail terheléskorlátozó paraméterei. A Sendmail indításakor tehát a MaxDaemonChildren paramétert javasolt megadni egy olyan értékkel, amely elegendõ a Sendmail számára betervezett terhelés kiszolgálására, de még kevés ahhoz, hogy a Sendmail fûbe harapjon tõle. Továbbá bölcs dolog a Sendmailt várakozási sorral () és démonként (sendmail -bd), külön feldolgozási menetekkel (sendmail -q15m) futtatni. Ha továbbra is valós idejû kézbesítést akarunk, akkor a feldolgozást kisebb idõközökkel is lefuttathatjuk (például ), de arra mindig ügyeljünk, hogy a MaxDaemonChildren beállítása ne okozzon kaszkádosítási hibákat a Sendmail mûködésében. A Syslogd közvetlenül is támadható, ezért határozottan javasoljuk a használatát, amikor csak lehet, minden más esetben pedig a beállítást. Fordítsunk kellõ figyelmet a TCP kapcsolatok burkolását végzõ TCP Wrapper reverse-ident lehetõségére, ami szintén közvetlenül támadható. Ebbõl az okból kifolyólag valószínûleg nem is akarjuk a TCP Wrapper által felkínált reverse-ident-et használni. Jól járunk el abban az esetben, ha a belsõ szolgáltatásainkat az útválasztóink mentén tûzfal segítségével védjük meg a külsõ hozzáféréstõl. Ezzel lényegében a helyi hálózatunkat kívülrõl fenyegetõ támadások ellen védekezünk, de ez nem nyújt elegendõ védelmet a belsõ szolgáltatásaink esetén a root hozzáférés megszerzésére irányuló kísérletek ellen. Mindig egy exkluzív, tehát zárt tûzfalat állítsunk be, vagyis tûzfalazzunk mindent kivéve az A, B, C, D és M-Z portokat. Ezen a módon ki tudjuk szûrni az összes alacsonyabb portot, kivéve bizonyos eseteket, mint például a named (ha az adott zónában ez az elsõdleges gép), ntalkd, sendmail vagy más interneten keresztül elérhetõ szolgáltatásokat. Ha másképpen állítjuk a tûzfalat — inkluzív, nyílt avagy megengedõ módon, akkor jó eséllyel elfelejtünk lezárni egy csomó szolgáltatást, vagy úgy adunk hozzá egy új belsõ szolgáltatást, hogy közben elfelejtjük frissíteni a tûzfalat. Ennél még azon is jobb, ha a tûzfalon nyitunk egy magasabb portszámú tartományt, és ott valósítjuk meg ezt a megengedõ jellegû mûködést, az alacsonyabb portok veszélybe sodrása nélkül. Vegyük azt is számításba, hogy a &os;-ben a kiosztott portokat dinamikusan állíthatjuk a net.inet.ip.portrange sysctl változókon keresztül (sysctl -a | fgrep portrange), ami nagyságrendekkel megkönnyíti a tûzfal beállítását. Ennek megfelelõen például meg tudjuk adni, hogy a 4000-tõl 5000-ig terjedõ porttartomány a 49152-tõl 65535-ig húzódó tartományba kerüljön át, majd a 4000 alatti összes portot blokkoljuk (természetesen az internetrõl szándékosan hozzáférhetõ portok kivételével). A DoS támadások másik elterjedt fajtája az ún. ugródeszka támadás — ilyenkor a szervert úgy próbálják túlterhelni, hogy folyamatosan válaszokat kérnek tõle a helyi hálózatról vagy egy másik számítógéprõl. Az ilyen természetû támadások közül is a legnépszerûbb az ICMP pingszórásos támadás. A támadó olyan ping csomagokat küld szét a helyi hálózaton, amelyek forrásának azt a gépet jelöli meg, amelyiket meg akarja támadni. Ha a hálózatokat elválasztó útválasztók nem fogják meg a pingszórást, akkor a helyi hálózatról összes gépe nekilát válaszolgatni a meghamisított forrás címére, amivel így teljesen leterhelik az áldozatot. Ez különösen akkor hatásos, amikor a támadó ugyanezt a trükköt eljátssza egyszerre több tucat különbözõ hálózatban is. Az üzenetszórással járó támadások akár százhúsz megabitnyi forgalmat is képesek generálni másodpercenként. A második legelterjedtebb ugródeszkás támadás az ICMP hiba-visszajelzési rendszere ellen irányul. Ilyenkor a támadó ICMP hibaüzeneteket kiváltó csomagok készítésével képes eltömíteni egy szerver bejövõ hálózati kapcsolatát és az ICMP válaszokkal pedig a szerver maga dugítja el a kimenõ hálózati kapcsolatát. Ez a fajtájú támadás képes kinyomni az összes memóriát a szerverbõl és ezzel összeomlasztani, különösen olyankor, amikor a szerver nem tudja elég gyorsan elnyelni az általa generált ICMP válaszokat. A net.inet.icmp.icmplim sysctl változóval tudunk gátat szabni a támadások ezen fajtájának. Az ugródeszkás támadások utolsó nagyobb osztálya az inetd olyan szolgáltatásait szemeli ki, mint például az udp echo. A támadó ilyenkor egyszerûen küld a helyi hálózatunkon található A és B szerverünknek egy olyan UDP csomagot, ahol forrásként az A szerver echo portját adja meg, célnak pedig a B szerver echo portját. Ezután a két szerver elkezdi egymás között passzolgatni ezt az egyetlen csomagot. A támadó még több ilyen csomag befecskendezésével pillanatok alatt képes leterhelni a két szervert és helyi hálózatot. Hasonló problémák vannak a belsõ chargen portjával is. Egy hozzáértõ rendszergazda ezért kikapcsolja az összes ilyen inetd-alapú belsõ tesztelõ szolgáltatást. Az álcázott csomagok felhasználhatóak a rendszermag útválasztó gyorsítótárának túlterhelésére is. Ezzel kapcsolatban nézzük meg a net.inet.ip.rtexpire, rtminexpire és rtmaxcache sysctl változókat. A véletlenszerû IP-címekkel megcímzett álcázott csomagok hatására a rendszermag létrehoz mindegyikõjükhöz egy ideiglenesen pufferelt utat az útválasztó táblázatában, amelyet a netstat -rna | fgrep W3 paranccsal tudunk lekérdezni. Az ilyen útvonalak nagyjából 1600 másodperc múlva elévülnek. Ha a rendszermag észleli, hogy a gyorsítótárazott útválasztási táblázat mérete túlságosan megnövekedett, akkor automatikusan csökkenti az rtexpire értékét, de soha nem megy a rtminexpire alá. Ebbõl két probléma adódik: A rendszermag nem reagál elég gyorsan amikor egy alig terhelt szervert hirtelen megtámadnak. Az rtminexpire nem elég kicsi ahhoz, hogy a rendszermag túléljen egy tartósabb rohamot. Ha a szervereink az internethez T3 (kb. 45 Mbit/s) vagy gyorsabb összeköttetésen keresztül csatlakoznak, akkor határozottan javasolt kézileg behangolni a &man.sysctl.8; segítségével az rtexpire és az rtminexpire értékeket. Soha ne állítsuk egyiket sem nullára (hacsak nem akarjuk összeomlasztani a gépünket). Ha például mind a kettõt 2 másodpercre állítjuk, akkor az többnyire elegendõ az útválasztási táblázat megvédéséhez. Hozzáférés Kerberosszal és SSH-val ssh KerberosIV Van néhány dolog, amit a Kerberos és az ssh esetén ajánlatos tisztázni, mielõtt használjuk ezeket. A Kerberos 5 egy kifogástalan hitelesítési protokoll. A telnet és rlogin Kerberos által módosított változatában vannak olyan hibák, amelyek alkalmatlanná teszik ezeket a bináris adatfolyamok helyes kezelésére. Sõt, alapértelmezés szerint a Kerberos nem titkosítja a kapcsolatot, csak ha megadjuk neki a kapcsolót. Az ssh alapértelmezés szerint mindent titkosít. Az ssh minden szempontból nagyon jól teljesít kivéve, hogy alapértelmezés szerint átküldi a kulcsokat is. Ez azt jelenti, hogy ha van egy olyan biztonságos munkaállomásunk, ahol a rendszer többi részéhez tartozó kulcsainkat tartjuk és egy nem biztonságos gépre akarunk vele ssh-n keresztül belépni, akkor a kulcsaink használatóvá válnak. A tényleges kulcsokat ugyan nem látja senki, de a bejelentkezés során az ssh megnyit egy közvetítéshez használt portot, amit a nem biztonságos gépen a támadó egy feltört root hozzáférés birtokában ki tud használni úgy, hogy a kulcsaink segítségével hozzá tudjon férni egy másik olyan géphez, amelyet a kulcsok nyitnak. Ha lehetséges, akkor a személyzet bejelentkeztetéséhez az ssh-t és Kerberost együttesen használjuk. Az ssh lefordíható Kerberos támogatással. Ezzel csökkentjük a potenciálisan kiszivárgó ssh kulcsok esélyét, miközben jelszavainkat a Kerberosszal védjük. Az ssh kulcsokat csak biztonságos gépekrõl és csak automatizált feladatok esetén használjuk (amire a Kerberos lényegében nem alkalmas). Emellett javasoljuk azt is, hogy az ssh beállításai között tiltsuk le a kulcsok átküldését (key forwarding) vagy használjuk az from=IP/DOMAIN opciót, amivel az ssh csak a megadott gépekrõl engedi az authorized_keys állomány és a így benne levõ kulcsok használatát. Bill Swingle Egyes részeit újraírta és aktualizálta: DES, Blowfish, MD5 és a Crypt biztonság crypt crypt Blowfish DES MD5 Minden &unix; rendszer használójához tartozik egy jelszó is a hozzáféréséhez. Teljesen nyilvánvalónak tûnik, hogy ezt a jelszót csak az adott felhasználó és az adott operációs rendszer ismeri. A jelszavakat a titokban tartásukhoz ún. csapóajtó függvényekkel titkosítják, amelyeket könnyû titkosítani, ám nehéz visszafejteni. Tehát amit egy perccel ezelõtt még nyilvalónak tituláltunk, az mostanra már nem is teljesen igaz: valójában az operációs rendszer sem ismeri a jelszót. Az operációs rendszer csak a jelszó titkosított változatát ismeri. A jelszó titkosítatlan formáját csak nyers erõ igényebevételével tudjuk megkeresni az összes lehetséges jelszó szénakazlában. Sajnos, annak idején, amikor a jelszavak titkosítása bekerült a &unix;-ba, egyedül a DES, vagy más néven a Data Encryption Standard (Adattitkosítási szabvány) jött szóba. Ez alapvetõen nem jelentett problémát az Egyesült Államok állampolgárai számára, de mivel a DES forráskódját nem lehetett kivinni az Egyesült Államokból, a &os;-nek találnia kellett valami olyasmit, ami mind megfelel az Egyesült Államok törvényeinek, mind pedig kompatibilis marad az összes többi DES-t használó &unix; variánssal. Ezt úgy oldották meg, hogy felosztották a titkosítással foglalkozó függvénykönyvtárakat, így az Egyesült Államokban élõ felhasználók tudtak DES könyvtárakat telepíteni és használni, miközben a többi nemzet felhasználói olyan más titkosítási módszert tudtak választani, amit kinn is lehetett alkalmazni. Ennek tulajdonítható, hogy a &os; alapértelmezés szerint az MD5 segítségével titkosít. Az MD5-öt a DES-nél sokkalta biztonságosabbnak tartják, ezért a DES telepítésének lehetõségét leginkább csak kompatibilitási okokból ajánlották fel. A titkosítási mechanizmus azonosítása Jelenleg a könyvtár ismeri a DES, MD5 és Blowfish függvényeit. A &os; a jelszavak titkosításához alapból az MD5-öt használja. Nagyon könnyen meg tudjuk mondani, hogy a &os; éppen melyik titkosítási módszert alkalmazza. Ennek egyik lehetõsége, ha az /etc/master.passwd állományt vizsgáljuk meg. Az MD5 függvényével titkosított jelszavak hosszabbak, mint a DES függvényével titkosítottak és a $1$ karakterekkel kezdõdnek. A $2a$ karakterekkel kezdõdõ jelszavakat Blowfish-sel titkosították. A DES kódolású jelszavaknak nincs semmilyen különleges ismertetõjelük, de általánosságban elmondható róluk, hogy rövidebbek az MD5 jelszavaknál és olyan 64 karakteres ábécével kódolják ezeket, amelyek nem tartalmazzák a $ karaktert, így tehát a viszonylag rövid, nem dollárjellel kezdõdõ karakterláncok minden bizonnyal DES kódolású jelszavak. Az új jelszavak kódolásához használt formátumot az /etc/login.conf állományban tárolt passwd_format bejelentkezési tulajdonság adja meg, amelynek értékei des, md5 vagy blf lehetnek. A &man.login.conf.5; man oldalon tájékozódhatunk bõvebben a bejelentkezési tulajdonságokról. Egyszeri jelszavak egyszeri jelszavak biztonság egyszeri jelszavak A &os; alapértelmezés szerint támogatja az OPIE-t (One-time Passwords In Everything, azaz Egyszeri jelszavak mindenben), ami alapból az MD5 függvényét használja. A jelszavak három fajtáját fogjuk a továbbiakban tárgyalni. Az elsõ a megszokott &unix; stílusú avagy Kerberos jelszó. Ezt a továbbiakban &unix; jelszónak nevezzük. A második fajtában az OPIE &man.opiekey.1; nevû segédprogramja által generált és a bejelentkezésnél a &man.opiepasswd.1; által elfogadott jelszavak tartoznak. Ezeket egyszeri jelszavaknak fogjuk nevezni. A jelszavak utolsó típusa az a titkos jelszó, amit az opiekey programnak (és néha a opiepasswd programnak) adunk meg, ami ebbõl egyszer használatos jelszavakat állít elõ. Ezt innentõl titkos jelszónak vagy csak egyszerûen jelszónak hívjuk. A titkos jelszónak semmi köze sincs a &unix; jelszavunkhoz. Természetesen megegyezhetnek, de ezt nem ajánljuk. Az OPIE által használt titkos jelszavaknak nem kell a régi &unix; jelszavakhoz hasonlóan legfeljebb 8 karakteresnek lenniük &os; alatt a bejelentkezéshez használt szabványos jelszavak akár 128 karakteresek is lehetnek. , bármekkorát használhatunk. A hat vagy hét szóból álló jelszavak ilyenkor igen gyakoriak. Az OPIE jobbára a &unix; jelszórendszerétõl teljesen függetlenül mûködik. A jelszavak mellett két másik fajta adat fontos az OPIE számára. Közülük az egyiket magnak vagy kulcsnak nevezik, ami két betûbõl és öt számjegybõl áll. A másik az iterációk száma, ami egy 1 és 100 közötti számot takar. Az OPIE úgy hozza létre az egyszeri jelszavakat, hogy egymás után fûzi a magot és a titkos jelszót, majd az iterációk megadott számának megfelelõ mennyiségben kiszámolja rá az MD5 függvény értékét és az eredményt hat rövid angol szóba önti. Ez a hat angol szó lesz a mi egyszeri jelszavunk. A hitelesítéssel foglalkozó rendszer (elsõsorban a PAM) figyelemmel kíséri a legutoljára használt egyszeri jelszavunkat, és csak akkor engedi a felhasználót hitelesíteni, ha az általa megadott jelszó kódolt változata megegyezik az elõzõleg megadott jelszaváéval. A csapóajtó függvények használata miatt lehetetlen legenerálni a következõ egyszeri jelszót, ha a sikerült megszereznünk az egyiket. Az iterációk száma minden egyes sikeres bejelentkezés után csökken eggyel, amivel a felhasználót és a bejelentkeztetõ programot szinkronban tartja. Amikor így az iterációk száma eléri az egyet, az OPIE-t újra kell inicializálni. Az említésre kerülõ rendszerek mindegyikéhez tartozik néhány program. Az opiekey bekéri az iterációk számát, a magot és a titkos jelszót, majd elõállít egy egyszer használatos jelszót vagy azok folytonos listáját. Az opiepasswd az OPIE inicializálásért, a jelszavak, az iterációk számának és a mag megváltoztatásáért felelõs. Egyaránt elfogad titkos jelmondatot, iterációs számot vagy magot és egy egyszeri jelszót. Az opieinfo megvizsgálja a felhasználókra vonatkozó adatbázist (/etc/opiekeys) és kiírja az adott felhasználó által használt iterációs számot és magot. Négyféle különbözõ mûveletrõl fogunk most itt beszélni. Az elsõben egy biztonságos kapcsolaton keresztül elsõként inicializáljuk az egyszeri jelszavakat, vagy megváltoztatjuk a jelszót vagy a magot az opiepasswd segítségével. A második mûveletben ugyanarra adjuk ki az opiepasswd parancsot egy nem biztonságos kapcsolaton keresztül az opiekey paranccsal együtt egy biztonságos kapcsolaton keresztül. A harmadikban az opiekey használatával nem biztonságos kapcsolaton keresztül jelentkezünk be. A negyedikben az opiekey paranccsal létrehozunk egy adott mennyiségû kulcsot, amelyeket aztán leírhatunk vagy kinyomtathatunk, hogy magunkkal tudjuk vinni olyan helyre, ahonnan nem tudnk biztonságos módon csatlakozni. Inicializálás biztonságos kapcsolattal Az OPIE elsõ inicializálásához adjuk ki az opiepasswd parancsot: &prompt.user; opiepasswd -c [grimreaper] ~ $ opiepasswd -f -c Adding unfurl: Only use this method from the console; NEVER from remote. If you are using telnet, xterm, or a dial-in, type ^C now or exit with no password. Then run opiepasswd without the -c parameter. Using MD5 to compute responses. Enter new secret pass phrase: Again new secret pass phrase: ID unfurl OTP key is 499 to4268 MOS MALL GOAT ARM AVID COED A figyelmeztetés fordítása: Ezt a módszert csak konzolról alkalmazzuk, SOHA ne távoli kapcsolaton keresztül! Ha telnetet, xtermet vagy betárcsázós kapcsolatot használunk, akkor azonnal nyomjunk ^C-t vagy ne adjunk meg jelszót. Az Enter new secret pass phrase: vagy Enter secret password: kérdések után adjunk meg egy jelmondatot, illetve jelszót. Ne felejtsük el, hogy ez nem bejelentkezéshez használt jelszó lesz, hanem ebbõl jönnek majd létre az egyszeri kulcsaink. Az ID sor adja meg az aktuális példányunk paramétereit: a bejelentkezéshez használt nevünket, az iterációk számát és a magot. Amikor a bejelentkezések során a rendszer emlékszik a paraméterekre és megjeleníti ezeket, nem kell megjegyeznünk. Az utolsó sor adja meg a paramétereinknek és a titkos jelszavunknak megfelelõ egyszeri jelszót. Ha most azonnal akarnánk bejelentkezni, akkor ezt az egyszeri jelszót kellene hozzá használnunk. Inicializálás nem biztonságos kapcsolattal Ha egy nem biztonságos kapcsolaton keresztül akarjuk inicializálni vagy megváltoztatni a jelszavunkat, akkor szükségünk lesz valahol egy megbízható kapcsolatra, ahol le tudjuk futtatni az opiekey parancsot. Ez lehet egy számunkra biztonsági szempontból elfogadható gép parancssora. Emellett ki kell találnunk egy iterációs számot (erre a 100 egy jó választás) és adnunk egy magot vagy használni egy véletlenszerûen generáltat. Az inicializálás színtere felé vezetõ nem biztonságos kapcsolaton keresztül adjuk ki az opiepasswd parancsot: &prompt.user; opiepasswd Updating unfurl: You need the response from an OTP generator. Old secret pass phrase: otp-md5 498 to4268 ext Response: GAME GAG WELT OUT DOWN CHAT New secret pass phrase: otp-md5 499 to4269 Response: LINE PAP MILK NELL BUOY TROY ID mark OTP key is 499 gr4269 LINE PAP MILK NELL BUOY TROY Az alapértelmezett mag elfogadásához nyomjuk le a Return billentyût. Mielõtt megadnánk a hozzáférés jelszavát, menjünk át a biztonságos kapcsolatra és adjuk meg neki ugyanezeket a paramétereket: &prompt.user; opiekey 498 to4268 Using the MD5 algorithm to compute response. Reminder: Don't use opiekey from telnet or dial-in sessions. Enter secret pass phrase: GAME GAG WELT OUT DOWN CHAT Most váltsunk vissza a nem biztonságos kapcsolatra és másoljuk be az így generált egyszeri jelszót a megfelelõ programba. Egyetlen egyszeri jelszó létrehozása Miután sikeresen inicializáltuk az OPIE-t és bejelentkezünk, a következõket láthatjuk: &prompt.user; telnet example.com Trying 10.0.0.1... Connected to example.com Escape character is '^]'. FreeBSD/i386 (example.com) (ttypa) login: felhasználói_név otp-md5 498 gr4269 ext Password: Mellékesen megjegyezzük, hogy az OPIE paranccsorának van egy (itt nem látható) hasznos képessége: ha Return billentyût nyomunk a jelszó bekérésekor, akkor a program megmutatja a begépelt betûket, így láthatjuk pontosan mit is írunk be. Ez nagyon kényelmes lehet olyankor, amikor valahonnan, például egy lapról olvassuk a jelszót. MS-DOS Windows MacOS A bejelentkezéshez ekkor le kell valahogy generálnunk az egyszeri jelszavunkat. Ezt egy megbízható rendszeresen tudjuk megtenni az opiekey lefuttatásával. (Ennek vannak DOS-os, &windows;-os és &macos;-es változatai is.) Paraméterként az iterációs számot és a magot kell megadnunk. Ezt akár közvetlenül át is másolhatjuk annak a gépnek a bejelentkezési képernyõjérõl, ahova be akarunk jelentkezni. A megbízható rendszeren tehát: &prompt.user; opiekey 498 to4268 Using the MD5 algorithm to compute response. Reminder: Don't use opiekey from telnet or dial-in sessions. Enter secret pass phrase: GAME GAG WELT OUT DOWN CHAT Most már megvan a bejelentkezéshez szükséges egyszeri jelszavunk. Több egyszeri jelszó létrehozása Néha olyan helyekre kell mennünk, ahol se egy megbízható gép, sem pedig biztonságos kapcsolat nem található. Ilyen esetekben megadhatjuk az opiekey parancsnak, hogy elõre gyártson le több egyszer használatos jelszót, amit késõbb aztán ki tudunk nyomtatni. Például: &prompt.user; opiekey -n 5 30 zz99999 Using the MD5 algorithm to compute response. Reminder: Don't use opiekey from telnet or dial-in sessions. Enter secret pass phrase: <secret password> 26: JOAN BORE FOSS DES NAY QUIT 27: LATE BIAS SLAY FOLK MUCH TRIG 28: SALT TIN ANTI LOON NEAL USE 29: RIO ODIN GO BYE FURY TIC 30: GREW JIVE SAN GIRD BOIL PHI Az öt kulcsot kér egymás után, a pedig megadja az utolsó iterációs számot. Vegyük észre, hogy a kulcsokat a felhasználás sorrendjével ellentétes sorrendben írja ki a program. Ha igazán paranoiások vagyunk, akkor írjuk le kézzel a jelszavakat. Ha viszont annyira nem, akkor egyszerûen küldjük át ezeket az lpr parancsnak. Megfigyelhetjük, hogy minden sorban látható az iterációs szám és a hozzátartozó egyszeri jelszó. Hasznos lehet a felhasználás szerinti felírni a jelszavakat. A &unix; jelszavak használatának leszûkítése Az OPIE képes a bejelentkezéshez használt IP-címek alapján leszûkíteni a &unix; jelszavak használatát. Ehhez az /etc/opieaccess használható, amely alapból megtalálható a rendszerünkön. Az &man.opieaccess.5; man oldalán találhatjuk meg a rá vonatkozó információkat és az összes vele kapcsolatos biztonsági megfontolást. Íme egy példa az opieaccess állományra: permit 192.168.0.0 255.255.0.0 Ezzel a sorral megengedjük a &unix; jelszavak használatát minden olyan felhasználó számára, akinek az IP-je illeszkedik a megadott címre és maszkra (ez viszont álcázással kijátszható). Ha az opieaccess állományból egyetlen szabály sem illeszkedik, akkor alapértelmezés szerint nem engedélyezettek a nem OPIE típusú jelszavak. Tom Rhodes Írta: TCP burkolók A TCP kapcsolatok burkolása Aki ismeri az &man.inetd.8; programot, az már biztosan hallott a TCP kapcsolatok burkolásáról, eredeti nevén a a TCP wrapperekrõl. Azonban csak kevesek képesek felfogni ezek valódi hasznát. Úgy néz ki, mindenki csak tûzfalakon keresztül akarja megoldani a hálózati kapcsolatot kezelését. Habár a tûzfalakat sok mindenre fel lehet ugyan használni, egyetlen tûzfal nem képes például szövegesen válaszolni a kapcsolatok kezdeményezõinek. Ellenben bármelyik TCP-wrapper szoftver képes erre, sõt még többre is. A következõ néhány szakaszban szemügyre vesszük a TCP wrapperek számos lehetõségét, és ahol lehetséges, ott konfigurációs állományokkal is illusztráljuk ezek használatát. A TCP burkoló szoftverek kiterjesztik az inetd képességeit minden alatta dolgozó szerverdémon támogatására. Ezzel a módszerrel meg lehet oldani a naplózást, üzenetek küldését a kapcsolatokhoz, a démonok elérhetõségének korlátozását stb. Noha ezen lehetõségek közül néhány tûzfallal is megvalósítható, ezzel nem csupán egy további védelmi réteget húzunk fel a rendszerünk köré, hanem túllépjük mindazt, amit egy tûzfallal irányítani lehet. A TCP burkolók használatával hozzáadott funkcionalitás azonban nem helyettesít egy jó tûzfalat. A TCP kapcsolatok burkolását tûzfallal vagy más egyéb biztonsági megoldással együtt tudjuk csak eredményesen használni, viszont a rendszerünk biztonságában egy újabb remek védelmi vonalat képvisel. Mivel lényegében ez az inetd beállításának kibõvítése, ezért a szakasz elolvasásához feltételezzük az inetd beállításával kapcsolatos tudnivalók ismeretét. Bár az &man.inetd.8; által indított programok nem egészen tekinthetõen démonoknak, hagyományosan démonnak hívják ezeket. Ezért rájuk ebben a szakaszban is ezt a kifejezést használjuk. Kezdeti beállítások &os; alatt a TCP burkolók használatának egyetlen feltétele csupán annyi, hogy az inetd parancsot a paraméterrel indítsuk az rc.conf állományból. Az egyébként az alapbeállítás. Természetesen nem árt, ha helyesen állítjuk be az /etc/hosts.allow állományt is, ellenkezõ esetben a &man.syslogd.8; egyébként dobálni fogja errõl az üzeneteket. Eltérõen a TCP burkolók egyéb implementációitól, a hosts.deny állományt itt már nem használjuk. Minden beállítást az /etc/host.allow állományba kell raknunk. A legegyszerûbb konfiguráció esetén a démonok kapcsolódását egyszerûen engedélyezhetjük vagy letilthatjuk az /etc/hosts.allow állományban szereplõ beállításokkal. A &os; alapértelmezett beállításai szerint minden inetd által indított démonhoz lehet kapcsolódni. Ennek megváltoztatásával az alapkonfiguráció áttekintése után foglalkozunk. Az alapkonfiguráció általában démon : cím : cselekvés alakú. Itt a démon egy olyan démonra utal, amelyet az inetd indított el. A cím egy érvényes hálózati név, IP-cím vagy szögletes zárójelek ([ ]) között megadott IPv6 formátumú cím. A cselekvést tartalmazó mezõ (action) lehet allow vagy deny annak megfelelõen, hogy engedélyezzük vagy tiltjuk a megadott címrõl a csatlakozást. Nem szabad elfelejtenünk, hogy az így megadott beállítások közül mindig az elsõként illeszkedõ érvényesül, ami arra utal, hogy a konfigurációs állományban szereplõ szabályok egymás után növekvõ sorrendben értékelõdnek ki. Ha valamelyikük illeszkedik, akkor a keresés megáll. Rengeteg egyéb opció is megadható még, de ezekrõl csak a késõbbi szakaszokban fogunk szólni. Egy egyszerû konfigurációs állomány már ennyi információból is könnyedén összeállítható. Például, ha engedélyezni szeretnénk a POP3 kapcsolatokat a mail/qpopper démonon keresztül, akkor a következõ sorral kell kiegészítenünk a hosts.allow állományt: # Ez a sor kell a POP3 kapcsolatokhoz: qpopper : ALL : allow Miután hozzáadtuk ezt a sort, az inetd szervert újra kell indítanunk. Ezt vagy a &man.kill.1; paranccsal, vagy pedig az /etc/rc.d/inetd szkript restart paraméterével tehetjük meg. Komolyabb beállítások A TCP kapcsolatok burkolásánál is meg lehet adni további opciókat. Segítségükkel még jobban irányítani tudjuk a kapcsolatok kezelésének módját. Néhány esetben az is hasznos lehet, ha küldünk valamilyen választ az egyes gépeknek vagy démonoknak. Máskor szükségünk lehet a csatlakozások naplózására vagy e-mailen keresztüli jelzésére a rendszergazda felé. Teljesen más helyezetekben csak a helyi hálózatunkról engedjük meg a csatlakozást. Ez mind lehetséges a helyettesítõ jelekként ismert beállítási opciók, kiterjesztõ karakterek és külsõ parancsok végrehajtásának használatával. A következõ két szakasz az ilyen és ehhez hasonló szituációk megoldására íródott. Külsõ parancsok Tegyük fel, hogy olyan helyezetben vagyunk, amikor a kapcsolatot tiltani akarjuk, de közben azért szeretnénk errõl értesíteni a kapcsolatot kezdeményezõ felet is. Hogyan tudjuk ezt megcsinálni? Ezt a nevû opcióval tehetjük meg. Amikor megpróbál valaki csatlakozni, akkor a hívódik meg és végrehajt egy megadott parancsot vagy szkriptet. Erre találunk is egy példát a hosts.allow állományban: # The rest of the daemons are protected. ALL : ALL \ : severity auth.info \ : twist /bin/echo "You are not welcome to use %d from %h." Ez a példa a következõ üzenetet jeleníti meg: You are not allowd to use a démon neve from hálózati név. (Jelentése: A démon neve démont nem érheti el a hálózati név helyrõl!) Ez minden olyan démon esetén megjelenik, amirõl nem nyilatkoztunk korábban az állományban. Ezzel nagyon könnyen vissza tudunk küldeni egy választ a kapcsolat kezdményezõje felé, miután a kapcsolatot eldobtuk. Vegyük észre, hogy a visszaküldendõ üzenetet " karakterek közé kell tennünk, ez alól semmi sem kivétel. DoS támadást lehet elõidézni azzal, ha egy támadó vagy támadók egy csoportja csatlakozási kérelmekkel kezdi el bombázni a démonainkat. Ilyen esetekben használhatjuk a opciót is. A a opcióhoz hasonlóan implicit módon tiltja a kapcsolódást és arra használható, hogy lefuttassunk vele egy parancsot vagy szkriptet. A azonban a opciótól eltérõen nem küld vissza semmilyen választ a kapcsolatot létrehozni kívánó egyénnek. Ehhez példaként vegyük a következõ sort a konfigurációs állományban: # We do not allow connections from example.com: ALL : .example.com \ : spawn (/bin/echo %a from %h attempted to access %d >> \ /var/log/connections.log) \ : deny Ezzel a *.example.com címtartományból érkezõ összes kapcsolódási kísérlet sikertelen lesz, miközben ezzel egyidõben a /var/log/connections.log állományba rögzítjük a csatlakozni akaró egyén hálózati nevét, IP-címét és a démont. A korábban már kifejtett helyettesítõ karakterek túl, mint például az %a, még léteznek továbbiak is. Róluk a &man.hosts.access.5; man oldalon találhatjuk meg a teljes listát. Helyettesítõ jelek Az eddigi példákban folyamatosan csak az ALL opciót adtuk meg. Azonban rajta kívûl léteznek mások is, amivel a megoldás funkcionalitását még egy kicsivel tovább növelhetjük. Például az ALL használható egy démon, egy tartomány vagy egy IP-cím illesztésére. A másik ilyen helyettesítõ jel a PARANOID, amelyet olyan gépek IP-címének illesztésekor alkalmazhatunk, ami feltételezhetõen hamis. Más szóval a PARANOID olyan cselekvések megadását teszi lehetõvé, amelyek akkor hajtódnak végre, amikor a kapcsolatot létrehozó gép IP-címe eltér a hálózati nevétõl. A most következõ példa valószínûleg segít fényt deríteni ennek lényegére: # Block possibly spoofed requests to sendmail: sendmail : PARANOID : deny A példában minden olyan kapcsolatkérést elutasítunk, ami a sendmail felé a hálózati névtõl eltérõ IP-címrõl irányul. Ha rossz DNS beállításokat használunk, a PARANOID opcióval súlyosan mozgásképtelenné tehetjük a kliensünket vagy szerverünket. Ezért legyünk óvatosak vele! A helyettesítõ jelekrõl és hozzájuk tartozó további lehetõségekrõl a &man.hosts.access.5; man oldalon tájékozódhatunk. A hosts.allow állományból ki kell venni az elsõ sort ahhoz, hogy bármilyen egyéb konfigurációs beállítás mûködõképes legyen. Ezt említettük a szakasz elején is. Mark Murray Írta: Mark Dapoz Eredetileg írta: <application>KerberosIV</application> A Kerberos egy olyan járulékos rendszer/protokoll, amellyel a felhasználók egy biztonságos szerver szolgáltatásain keresztül tudják hitelesíteni magukat. Ilyen szolgáltatás többek közt a távoli bejelentkezés, távoli másolás, a rendszeren belüli biztonságos másolás és minden olyan egyéb veszélyes feladat, amit számottevõen megbízhatóbbá és irányíthatóbbá tettek. A következõ utasítások a &os;-hez mellékelt Kerberos beállításához adnak útmutatást. A teljes leíráshoz azonban érdemes fellapoznunk a menet közben hivatkozott man oldalakat is. A <application>KerberosIV</application> telepítése MIT KerberosIV telepítés A Kerberos a &os; egyik választható komponense. Legkönnyebben úgy tudjuk feltelepíteni, ha a &os; telepítése során a sysinstall programban kiválasztjuk a krb4 vagy krb5 terjesztések valamelyikét. Ezzel felrakhatjuk a Kerberos eBones (KerberosIV) vagy Heimdal (Kerberos5) elnevezésû változatait. A &os; azért tartalmazza ezeket az implementációkat, mert nem az Amerikai Egyesült Államokban vagy Kanadában fejlesztették, így az Egyesült Államok titkosításokkal kapcsolatos kiviteli korlátozások korában minden olyan rendszer adminisztrátora el tudta érni, aki nem ezekben az országokban lakott. A Kerberos MIT által fejlesztett implementációját egyébként a Portgyûjteménybõl a security/krb5 porton keresztül érhetjük el. A kezdeti adatbázis létrehozása Ezt a lépést csak a Kerberos szerveren kell elvégezni. Elõször is gyõzõdjünk meg róla, hogy semmilyen korábbi Kerberos adatbázis nem található a gépen. Váltsunk az /etc/kerberosIV könyvtárra és ellenõrizzük a következõ állományok meglétét: &prompt.root; cd /etc/kerberosIV &prompt.root; ls README krb.conf krb.realms Ha rajtuk kívül további állományok is feltûnnének (mint például a principal.* vagy master_key), akkor a kdb_destroy paranccsal pusztítsuk el a régi Kerberos adatbázist, vagy ha nem fut már a Kerberos, akkor egyszerûen csak törüljük le ezeket. Ezután lássunk neki a krb.conf és krb.realms állományok átírásán keresztül a Kerberos egyes övezeteinek (realm) létrehozásához. Itt most az EXAMPLE.COM lesz a létrehozandó övezet, a hozzátartozó szerver pedig a grunt.example.com. Így szerkesszük át vagy készítsünk el a neki megfelelõ krb.conf állományt: &prompt.root; cat krb.conf EXAMPLE.COM EXAMPLE.COM grunt.example.com admin server CS.BERKELEY.EDU okeeffe.berkeley.edu ATHENA.MIT.EDU kerberos.mit.edu ATHENA.MIT.EDU kerberos-1.mit.edu ATHENA.MIT.EDU kerberos-2.mit.edu ATHENA.MIT.EDU kerberos-3.mit.edu LCS.MIT.EDU kerberos.lcs.mit.edu TELECOM.MIT.EDU bitsy.mit.edu ARC.NASA.GOV trident.arc.nasa.gov A többi övezetnek valójában nem feltétlenül kell itt lennie. Ezek csupán azért szerepelnek itt, hogy bemutassák miként lehet egyetlen géphez hozzárendelni egyszerre több övezetet is. Az egyszerûség kedvéért nyugodtan elhagyhatóak. Az elsõ sor nevezi meg a rendszer által mûködtetett övezeteket. Az utána következõ sorokban övezeteket és hálózati neveket láthatunk. Itt az elsõ elem egy övezetet nevez meg, a második elem pedig az övezet kulcselosztó központját (key distribution center). A hálózati nevet követõ admin server kulcsszavak arra utalnak, hogy az adott gép adminisztratív szerepet ellátó adatbázist is tartalmaz. Ezeket a fogalmakat részleteiben a Kerberos man oldalain ismerhetjük meg. Ezután hozzá kell adnunk a grunt.example.com nevû gépet az EXAMPLE.COM övezethez, valamint az .example.com tartományban levõ összes géphez létre kell hoznunk egy bejegyzést az EXAMPLE.COM övezetben. A krb.realms állományt ehhez a következõképpen kellene módosítanunk: &prompt.root; cat krb.realms grunt.example.com EXAMPLE.COM .example.com EXAMPLE.COM .berkeley.edu CS.BERKELEY.EDU .MIT.EDU ATHENA.MIT.EDU .mit.edu ATHENA.MIT.EDU Ismét hozzátesszük, hogy a többi övezetnek nem kötelezõ itt szerepelnie. Ezek csupán azt demonstrálják, hogy miként kell egy gépet egyszerre több övezethez is beállítani. Az átláthatóság kedvéért minden további nélkül eltávolíthatjuk ezeket. Itt az elsõ sor az adott rendszert elhelyezi egy nevesített övezetbe. A többi sor azt mutatja meg, hogyan kell alapértelmezett módon a meghatározott altartományokba tartozó gépeket egy nevesített övezethez hozzárendelni. Most már készen állunk az adatbázis létrehozására. Ehhez egyedül a Kerberos szerverét (avagy Kulcselosztó központját) kell elindítanunk. Adjuk ki a kdb_init parancsot: &prompt.root; kdb_init Realm name [default ATHENA.MIT.EDU ]: EXAMPLE.COM You will be prompted for the database Master Password. It is important that you NOT FORGET this password. Enter Kerberos master key: Az üzenet fordítása: Most az adatbázis mesterkulcsát kell megadni. Fontos, hogy NE FELEJTSÜK EL ezt a jelszót. Most el kell mentenünk a kulcsot, így a helyi gépen futó szerverek fel tudják szedni. Ehhez a kstash parancsra van szükségünk: &prompt.root; kstash Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Az üzenet fordítása: A Kerberos mesterkulcsának jelenlegi változata: 1. VIGYÁZAT, megadták a mesterkulcsot! Ez elmenti a titkosított mesterkulcsot az /etc/kerberosIV/master_key állományba. Az egész beüzemelése KerberosIV kezdeti indítása Mindegyik Kerberosszal õrzött rendszerrel kapcsolatban két ún. szereplõt (principal) kell még hozzátennünk az adatbázishoz. A nevük kpasswd és rcmd. Minden rendszerhez létre kell hoznunk ezeket a szereplõket, példányonként (instance) az egyes rendszerek neveivel. A kpasswd és rcmd démonok teszik lehetõvé a többi rendszer számára, hogy megváltoztathassák a Kerberos jelszavukat, valamint hogy futtathassák az &man.rcp.1;, &man.rlogin.1; és &man.rsh.1; parancsokat. Vegyük fel ezeket a bejegyzéseket is: &prompt.root; kdb_edit Opening database... Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Previous or default values are in [brackets] , enter return to leave the same, or new value. Principal name: passwd Instance: grunt <Not found>, Create [y] ? y Principal: passwd, Instance: grunt, kdc_key_ver: 1 New Password: <---- írjuk be, hogy RANDOM Verifying password New Password: <---- írjuk be, hogy RANDOM Random password [y] ? y Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? Attributes [ 0 ] ? Edit O.K. Principal name: rcmd Instance: grunt <Not found>, Create [y] ? Principal: rcmd, Instance: grunt, kdc_key_ver: 1 New Password: <---- írjuk be, hogy RANDOM Verifying password New Password: <---- írjuk be, hogy RANDOM Random password [y] ? Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? Attributes [ 0 ] ? Edit O.K. Principal name: <---- ha nem adunk meg semmit, akkor kilép A szerver állomány létrehozása Most pedig kivonatolni kell azokat a példányokat, amelyek szolgáltatást definiálnak a gépen. Erre az ext_srvtab parancsot használjuk. Ennek eredményeképpen keletkezik egy állományt, amelyet biztonságos eszközökkel át kell másolni vagy át kell mozgatni az egyes Kerberos kliensek /etc könyvtárába. Ennek az állománynak egyaránt jelent kell lennie a szerveren és a kliensen is, nélküle a Kerberos mûködésképtelen. &prompt.root; ext_srvtab grunt Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Generating 'grunt-new-srvtab'.... Ez a parancs most létrehozott egy ideiglenes állományt, amit át kell nevezni az srvtab névre, hogy megtalálhassák a szerverek. Az eredeti rendszeren a &man.mv.1; paranccsal tudjuk a helyére rakni: &prompt.root; mv grunt-new-srvtab srvtab Ha egy kliensnek szánjuk az állományt és a hálozatunkat nem tekinthetjük biztonságosnak, akkor a kliens-new-srvtab állományt másoljuk egy mozgatható adathordozóra és megbízható módon jutassuk el. Ne felejtsük el az állományt srvtab néven átrakni a kliens /etc könyvtárába és az engedélyeit 600-ra állítani: &prompt.root; mv grumble-new-srvtab srvtab &prompt.root; chmod 600 srvtab Az adatbázis feltöltése Ezt követõen rögzítenünk kell néhány felhasználót is adatbázisban. Elõször is hozzunk létre egy bejegyzést a janos nevû felhasználónak. Ezt a kdb_edit parancs kiadásával tesszük meg: &prompt.root; kdb_edit Opening database... Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Previous or default values are in [brackets] , enter return to leave the same, or new value. Principal name: janos Instance: <Not found>, Create [y] ? y Principal: janos, Instance: , kdc_key_ver: 1 New Password: <---- adjunk meg egy biztonságos jelszót Verifying password New Password: <---- itt ismét adjuk meg a jelszót Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? Attributes [ 0 ] ? Edit O.K. Principal name: <---- ha nem írunk be semmit, akkor kilép Próbáljuk ki Elsõként a Kerberos démonait kell beindítanunk. Ezzel kapcsolatban megjegyeznénk, hogy ha ehhez megfelelõen átírtuk az /etc/rc.conf állományunkat, akkor ez az újraindítással együtt magától lezajlik. Ezt csak a Kerberos szerveren kell megcsinálni. A Kerberos kliensei maguktól összeszedik a mûködésükhöz szükséges adatokat az /etc/kerberosIV könyvtárból. &prompt.root; kerberos & Kerberos server starting Sleep forever on error Log file is /var/log/kerberos.log Current Kerberos master key version is 1. Master key entered. BEWARE! Current Kerberos master key version is 1 Local realm: EXAMPLE.COM &prompt.root; kadmind -n & KADM Server KADM0.0A initializing Please do not use 'kill -9' to kill this job, use a regular kill instead Current Kerberos master key version is 1. Master key entered. BEWARE! A fenti figyelmeztetés fordítása: A program leállítására ne a 'kill -9' parancsot, hanem a normális kill parancsot használjuk Ezután a kinit parancs használatával próbáljunk meg az elõbb létrehozott janos azonosítónak kérni egy jegyet: &prompt.user; kinit janos MIT Project Athena (grunt.example.com) Kerberos Initialization for "janos" Password: A klist paranccsal most próbáljuk meg kilistázni a tokeneket és így ellenõrizni, hogy valóban rendelkezünk velük: &prompt.user; klist Ticket file: /tmp/tkt245 Principal: janos@EXAMPLE.COM Issued Expires Principal Apr 30 11:23:22 Apr 30 19:23:22 krbtgt.EXAMPLE.COM@EXAMPLE.COM Ezután a &man.passwd.1; használatával próbáljuk meg megváltoztatni a jelszavunkat. Ezzel tudjuk ellenõrizni, hogy a kpasswd démon hozzáfér a Kerberos adatbázisához: &prompt.user; passwd realm EXAMPLE.COM Old password for janos: New Password for janos: Verifying password New Password for janos: Password changed. Adminisztrátori jogosultságok felvétele A Kerberos lehetõvé teszi, hogy mindegyik olyan felhasználónak, akinek rendszergazdai jogokra lenne szüksége, a &man.su.1; eléréséhez külön meg tudjunk adni egy jelszót. Most már tudunk mondani egy olyan azonosítót is, amely jogosult a &man.su.1; használatával root jogokat szerezni. Ezt úgy tudjuk megoldani, ha az adott szereplõhöz társítunk egy root példányt. A kdb_edit használatával készíteni tudunk egy janos.root bejegyzést a Kerberos adatbázisában: &prompt.root; kdb_edit Opening database... Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Previous or default values are in [brackets] , enter return to leave the same, or new value. Principal name: janos Instance: root <Not found>, Create [y] ? y Principal: janos, Instance: root, kdc_key_ver: 1 New Password: <---- ide csak egy BIZTONSÁGOS jelszót adjuk meg! Verifying password New Password: <---- adjuk meg ismét a jelszót Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? 12 <--- ne állítsuk nagyon hosszúra! Attributes [ 0 ] ? Edit O.K. Principal name: <---- ha nem adunk meg semmit, akkor kilép Ezt követõen úgy tudunk megbizonyosodni a mûködésérõl, hogy megpróbálunk neki tokeneket szerezni: &prompt.root; kinit janos.root MIT Project Athena (grunt.example.com) Kerberos Initialization for "janos.root" Password: Most rakjuk bele a felhasználót a root .klogin állományába: &prompt.root; cat /root/.klogin janos.root@EXAMPLE.COM Ezután próbáljunk meg kiadni a &man.su.1; parancsát: &prompt.user; su Password: Nézzük meg milyen tokenjeink is vannak: &prompt.root; klist Ticket file: /tmp/tkt_root_245 Principal: janos.root@EXAMPLE.COM Issued Expires Principal May 2 20:43:12 May 3 04:43:12 krbtgt.EXAMPLE.COM@EXAMPLE.COM Más parancsok használata Az iménti példában létrehoztunk egy janos nevû szereplõt, amihez a root egy példányát rendeltük. Ez egy olyan felhasználón alapján történt, akinek a neve megegyezik a hozzátartozó szereplõvel, ami a Kerberosban alapértelmezés. Amennyiben a szükséges megjegyzések megtalálhatóak a root könyvtárában levõ .klogin állományban, akkor a felhasználó.root formátumú szereplõ.példány azonosító megengedi a felhasználó számára, hogy végrehajtsa a &man.su.1; parancsot. &prompt.root; cat /root/.klogin janos.root@EXAMPLE.COM Ehhez hasonlóan, ha a felhasználó saját könyvtárában megtalálható egy ilyen állomány: &prompt.user; cat ~/.klogin janos@EXAMPLE.COM jozsef@EXAMPLE.COM Ezzel a konfigurációval bárki, aki janos felhasználóként vagy jozsef felhasználóként (a kinit parancson keresztül) hitelesítette magát EXAMPLE.COM övezetbõl, ezen a rendszeren (grunt) bejelentkezhet a janos nevû felhasználóként vagy hozzáférhet az állományaihoz az &man.rlogin.1;, &man.rsh.1; vagy &man.rcp.1; használatával. Például janos most egy másik Kerberost használó rendszerre jelentkezik be: &prompt.user; kinit MIT Project Athena (grunt.example.com) Password: &prompt.user; rlogin grunt Last login: Mon May 1 21:14:47 from grumble Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995 Vagy jozsef jelentkezik be ugyanazon a gépen janos hozzáférésével (a janos nevû felhasználónak a fentebb bemutatt .klogin állomány található a könyvtárában és a Kerberos üzemeltetéséért felelõs személy létrehozott egy jozsef nevû szereplõt egy null példánnyal): &prompt.user; kinit &prompt.user; rlogin grunt -l janos MIT Project Athena (grunt.example.com) Password: Last login: Mon May 1 21:16:55 from grumble Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995 Tillman Hodgson Írta: Mark Murray Eredetileg írta: <application>Kerberos5</application> A &os; 5.1 után következõ mindegyik &os; kiadás már csak a Kerberos5 támogatást tartalmaz. Ezért bennük csak a Kerberos5 található meg, és a beállítása sok szempontból hasonlít a KerberosIV beállításához. A most következõ információk csak és kizárólag a &os; 5.0 kiadás után következõkben található Kerberos5 változatra vonatkoznak. A KerberosIV szolgáltatásait a felhasználók csomagként, a security/krb4 porton keresztül érhetik el. A Kerberos egy hálózati kiegészítõ rendszer/protokoll, amivel a felhasználók egy biztonságos szerveren keresztül képesek magukat azonosítani. A távoli bejelentkezések, távoli másolások, a rendszer belüli védett másolások valamint egyéb nagyon kockázatos feladatok, szolgáltatások biztonsága és felügyelete így jelentõs mértékben javítható. A Kerberos úgy írható le, mint az személyazonosságok ellenõrzésére feljogosított rendszer. Vagy tekinthetjük egy megbízható külsõ megfigyelõ által végzett hitelesítési rendszernek is. A Kerberos csak egyetlen funkciót kínál fel — ez a felhasználók biztonságos hitelesítése a hálózaton. Viszont nem nyújt semmilyen felhatalmazási (mit csinálhatnak a felhasználók) vagy vizsgálati (mit csináltak végül a felhasználók) lehetõséget. Miután egy kliens és a szerver a Kerberos használatával azonosították egymást, az egymás közt folyó kommunikációjuk titkosításával képesek megõrzi az átáramló adatok sértetlenségét és lehallgathatatlanságát. Ennek tükrében a Kerberos használata csak más olyan biztonsági módszerekkel együttesen javasolt, amelyek felhatalmazást és vizsgálati szolgáltatásokkal is rendelkeznek. A most következõ utasítások arra igyekeznek útmutatást adni, hogy miként használjuk a &os;-vel együtt terjesztett Kerberos verziót. Azonban a teljes leírást csak a témához tartozó man oldalak átolvasásával együtt kapjuk meg. A Kerberos telepítésének bemutatásához az alábbi névtereket fogjuk használni: A DNS tartomány (zóna) az example.org lesz. A Kerberos övezet az EXAMPLE.ORG lesz. Kérjük, hogy még abban az esetben is valódi tartományneveket adjuk meg, amikor a Kerberos használatát csak a belsõ hálózaton tervezzük. Ezzel elkerülhetjük az egyes Kerberos övezetek együttmûködése során felmerülõ DNS problémákat. A <application>Kerberos</application> története Kerberos5 története A Kerberost az MIT hozta létre a hálózati biztonsággal kapcsolatos problémák egyik megoldásaként. A Kerberos erõs titkosítást használ, ezért a kliensek képesek egy nem biztonságos hálózaton is azonosítani magukat a szerver felé (és fordítva). A Kerberos egyaránt utal egy hálózati protokoll nevére és azokra programokra, amelyek implementálják (például Kerberos telnet). Az 5 a protokoll jelenlegi verziója, amit az RFC 1510 ír le. A protokollnak számos szabad változata létezik, rengeteg típusú operációs rendszerre. A Massachusettsi Mûszaki Intézet (Massachusetts Institute of Technology, MIT), ahol a Kerberost eredetileg kifejlesztették, napjainkban is folytatja a saját Kerberos csomagjának fejlesztését. Többnyire az Egyesült Államokban használják titkosításra, mivel régebben az amerikai kiviteli korlátozások voltak rá érvényesek. Az MIT Kerberos változata portként érhetõ el (security/krb5). A Heimdal Kerberos egy másik 5 verziójú implementáció, amit a kiviteli korlátozások elkerülése érdekében határozottan az Egyesült Államokon kívül fejlesztettek ki (ezért gyakran megtalálhatjuk a különbözõ nem kereskedelmi &unix; variánsokban). A Heimdal Kerberos terjesztés portként elérhetõ (security/heimdal) és kisebb méretben a &os; alaptelepítésének is része. Mivel ezzel az írással a legtöbb felhasználót kívánjuk segíteni, ezért a következõ utasítások a &os; telepítésében mellékelt Heimdal terjesztés használatát feltételezik. A Heimdal kulcselosztójának telepítése Kerberos5 kulcselosztó központ A kulcselosztó központ (Key Distribution Center, avagy KDC) az a centralizált hitelesítési szolgáltatás, amit a Kerberos nyújt — lényegében az a számítógép, amely Kerberos-jegyeket bocsájt ki. A KDC megbízhatónak tekinthetõ a Kerberos által kialakított övezetben levõ többi számítógép számára, ezért védelme kiemelten fontos. Itt jegyeznénk meg, hogy habár a Kerberos szerver futtatása nagyon kevés számítógépes erõforrást igényel, ennek ellenére biztonsági szempontból egy külön számítógépet javasoljunk a kulcselosztó szerepének betöltéséhez. Mielõtt nekifognánk a KDC konfigurálásának, ellenõrizzük, hogy az /etc/rc.conf tartalmazza a KDC mûködéséhez szükséges beállításokat (az elérési utakat természetesen a saját rendszerünk szerint állítsuk be): kerberos5_server_enable="YES" kadmind5_server_enable="YES" A következõ lépésben vegyük szemügyre a Kerberos beállításait tartalmazó /etc/krb5.conf állományt: [libdefaults] default_realm = EXAMPLE.ORG [realms] EXAMPLE.ORG = { kdc = kerberos.example.org admin_server = kerberos.example.org } [domain_realm] .example.org = EXAMPLE.ORG Vegyük észre, hogy az itt szereplõ /etc/krb5.conf állomány szerint a kulcselosztónk teljes hálózati neve kerberos.example.org. Ha a kulcselosztónknak nem ez a neve, akkor a zónákat leíró állományba vegyünk még fel egy ilyen CNAME (álnév) bejegyzést. Ha egy nagyobb hálózatban vagyunk, ahol a DNS szervert is megfelelõen beállították, akkor az iménti példa ennyire leszûkíthetõ: [libdefaults] default_realm = EXAMPLE.ORG Itt már a következõ sorokat hozzáadták example.org zónát leíró állományhoz: _kerberos._udp IN SRV 01 00 88 kerberos.example.org. _kerberos._tcp IN SRV 01 00 88 kerberos.example.org. _kpasswd._udp IN SRV 01 00 464 kerberos.example.org. _kerberos-adm._tcp IN SRV 01 00 749 kerberos.example.org. _kerberos IN TXT EXAMPLE.ORG A kliensek csak akkor lesznek képesek elérni a Kerberos szolgáltatásait, ha vagy kötelezõ jelleggel megadunk egy teljesen beállított /etc/krb5.conf állományt, vagy egy minimális /etc/krb5.conf állományt és egy helyesen beállított DNS szervert használunk. Ezután létrehozzuk a Kerberos adatbázisát. Ez az adatbázis tartalmazza az összes szereplõ kulcsát a mesterkulcssal titkosítva. Erre a jelszóra nem kell feltétlenül emlékeznünk, mivel ez egy állományban tárolódik (/var/heimdal/m-key). A mesterkulcsot a kstash parancs kiadásával és egy jelszó megadásával tudjuk létrehozni. Ahogy a mesterkulcs elkészült, a kadmin parancs -l (mint lokális, azaz helyi) opciójával inicializálni tudjuk az adatbázist. Ez az opció arra utasítja a kadmin programot, hogy ne a kadmind hálózati szolgáltatást használja, hanem közvetlenül az adatbázis állományait módosítsa. Ezzel oldható meg az adatbázis kezdeti létrehozásának problémája. Miután megkaptuk a kadmin parancssorát, az övezetünkhöz tartozó adatbázis inicializálásához adjuk ki az init parancsot. Végül, még mindig a kadmin parancssorát használva, az add paranccsal hozzuk létre az elsõ szereplõnket. Egyelõre érjük be az alapértelmezett értékekkel, a modify paranccsal késõbb úgyis meg tudjuk változtatni ezeket. Hozzátesszük, hogy itt a ? parancs segítségével bármikor lekérhetjük az opciók ismertetését. Példa egy adatbázis létrehozására: &prompt.root; kstash Master key: xxxxxxxx Verifying password - Master key: xxxxxxxx &prompt.root; kadmin -l kadmin> init EXAMPLE.ORG Realm max ticket life [unlimited]: kadmin> add tillman Max ticket life [unlimited]: Max renewable life [unlimited]: Attributes []: Password: xxxxxxxx Verifying password - Password: xxxxxxxx Most már ideje elindítani a KDC szolgáltatásait. Ezeket az /etc/rc.d/kerberos start és /etc/rc.d/kadmind start parancsok kiadásával tudjuk felhozni. Megjegyezzük, hogy most még semmilyen kerberizált démont nem kell elindítanunk. Ellenben igyekezzünk ellenõrizni a KDC mûködõképességét azzal, hogy KDC parancssorából kérünk egy jegyet a frissen hozzáadott szereplõnknek (felhasználónknak) és kilistázzuk: &prompt.user; kinit tillman tillman@EXAMPLE.ORG's Password: &prompt.user; klist Credentials cache: FILE:/tmp/krb5cc_500 Principal: tillman@EXAMPLE.ORG Issued Expires Principal Aug 27 15:37:58 Aug 28 01:37:58 krbtgt/EXAMPLE.ORG@EXAMPLE.ORG Miután végeztünk, nyugodtan törölhetjük a jegyet: &prompt.user; k5destroy Szerverek kerberizálása a Heimdal használatával Kerberos5 szolgáltatások kerberizálása Ehhez elõször is szükségünk lesz a Kerberos konfigurációs állományának, az /etc/krb5.conf másolatára. Ezt úgy tudjuk megtenni, ha egyszerûen átmásoljuk a kulcselosztóról az egyik kliensre valamilyen megbízható módon (vagy az &man.scp.1; programhoz hasonló hálózati segédprogramok, vagy például fizikailag egy floppy lemez használatával). Ezután szükségünk lesz egy /etc/krb5.keytab nevû állományra. Ez az alapvetõ különbség a kerberizált démonokat felkínáló szerver és egy munkaállomás közt — a szervernek rendelkeznie kell egy keytab állománnyal. Ez az állomány tartalmazza a szerver kulcsát, amivel így a kulcselosztóval kölcsönösen azonosítani tudják egymást. Ezt a szerverre biztonságosan kell eljuttatnunk, mivel ennek napvilágra kerülésével a szerver védelme komoly veszélybe kerül. Tehát, ha egy titkosítás nélküli csatornán, például FTP-n keresztül visszük át, akkor kifejezetten rossz ötlet. A szerverre általában a kadmin program használatával érdemes átvinni a keytab állományt. Ez azért is hasznos, mert ehhez a kadmin segítségével létre kell hoznunk a befogadó szereplõt is (a kulcselosztó a krb5.keytab állomány végén). Vegyük észre, hogy már kaptunk egy jegyet és ezzel a jeggyel jogosultaknak kell lennünk a kadmind.acl állomány kadmin felület használatára. A hozzáférést vezérlõ listák (ACL-ek) tervezésével kapcsolatban olvassuk el Heimdal info oldalán található Remote administration címû szakaszt (info heimdal). Amennyiben nem kívánjuk engedélyezni a kadmin távoli elérését, egyszerûen csak csatlakozzunk valamilyen biztonságos módon (helyi konzolon, &man.ssh.1; vagy egy kerberizált &man.telnet.1; használatával) a kulcselosztóhoz, és a kadmin -l paranccsal végezzük el helyben az adminisztrációt. Miután telepítettük az /etc/krb5.conf állományt, a Kerberos szerverrõl el tudjuk érni a kadmin felületét. Az add --random-key paranccsal most már hozzáadhatjuk a szerver befogadó szereplõjét és az ext paranccsal ki tudjuk vonni a szerver befogadó szereplõjét a saját keytab állományából. Például: &prompt.root; kadmin kadmin> add --random-key host/myserver.example.org Max ticket life [unlimited]: Max renewable life [unlimited]: Attributes []: kadmin> ext host/myserver.example.org kadmin> exit Itt jegyeznénk meg, hogy az ext parancs (az extract rövdítése) a kivont kulcsot alapértelmezés szerint az /etc/krb5.keytab állományba menti ki. Ha a kulcselosztón nem fut a kadmind szolgáltatás (valószínûleg biztonsági okokból) és ezért távolról nem tudjuk elérni a kadmin felületét, akkor így tudjuk közvetlenül hozzáadni a befogadó szereplõt (host/myserver.EXAMPLE.ORG), majd kivonatolni azt egy ideiglenes állományba (elkerülve az /etc/krb5.keytab felülírását): &prompt.root; kadmin kadmin> ext --keytab=/tmp/example.keytab host/myserver.example.org kadmin> exit Ezután valamilyen biztonságos eszközzel (például scp vagy floppy használatával) át tudjuk másolni keytab állományt a szerverre. A kulcselosztón levõ keytab felülírását elkerülendõ, ne feledkezzünk el egy megfelelõ név megadásáról sem. Ezen a ponton már a szerver képes felvenni a kapcsolatot a kulcselosztóval (a krb5.conf állomány miatt) és bizonyítani a személyazonosságát (a krb5.keytab állomány miatt). Így tehát készen állunk a szolgáltatások kerberizálására. Ebben a példában most a telnet szolgáltatást vesszük célba úgy, hogy elõször az /etc/inetd.conf állományba berakjuk az alábbi sort, majd újraindítjuk az &man.inetd.8; szolgáltatást az /etc/rc.d/inetd restart paranccsal: telnet stream tcp nowait root /usr/libexec/telnetd telnetd -a user Itt az a legfontosabb, hogy az -a (mint authentication, azaz hitelesítés) paramétert a user beállítással adjuk meg. A &man.telnetd.8; man oldalán olvashatunk ennek pontos részleteirõl. Kliensek kerberizálása a Heimdal használatával Kerberos5 kliensek beállítása A kliensek beállítása szinte majdnem gyerekjáték. A Kerberos beállításához egyedül az /etc/krb5.conf állományra lesz szükségünk. Valamilyen biztonságos eszközzel másoljuk át a kulcselosztóról a kliensre. Úgy tudjuk letesztelni klienst, ha megpróbáljuk róla kiadni a kinit, klist és kdestroy parancsokat a fentebb létrehozott szereplõ jegyének megszerzéséhez, lekérdezéséhez és megsemmisítéséhez. A Kerberos használatával megpróbálkozhatunk csatlakozni valamelyik kerberizált szerverre is, ha viszont ez nem mûködik még egy jegy megszerzése után sem, akkor a gond többnyire a szerverrel van, nem pedig a klienssel vagy a kulcselosztóval. Amikor egy telnet vagy egy hozzá hasonló alkalmazást tesztelünk, egy csomaglehallgató (mint amilyen például a &man.tcpdump.1;) elindításával gyõzödjünk meg róla, hogy a jelszavak ilyenkor titkosítva mennek át. Próbáljuk meg titkosítani a teljes kommunikációt a telnet paraméterével (hasonlóan az ssh parancshoz). Alapból még számos más kiegészítõ Kerberos kliensalkalmazás is telepítõdik. Ezeken érezhetõ meg valójában az alaprendszerhez tartozó Heimdal változat minimalitása: ebben a telnet az egyedüli kerberizált szolgáltatás. A Heimdal port igyekszik pótolni a hiányzó klienseket a kerberizált ftp, rsh, rcp, rlogin és néhány kevéséb ismert program telepítésével. Az MIT változat portja szintén tartalmazza a Kerberos kliensek teljes kelléktárát. A felhasználók konfigurációs állományai: a <filename>.k5login</filename> és a <filename>.k5users</filename> .k5login .k5users Általában az övezetben található felhasználók mindegyikéhez tartozik egy Kerberos-szereplõ (mint például a tillman@EXAMPLE.ORG), ami a felhasználó helyi hozzáférésére mutat (mint például a tillman nevû helyi hozzáférés). A telnet és a hozzá hasonló kliensalkalmazások általában nem igényelnek felhasználót vagy szereplõt. Elõfordulhat azonban, hogy valaki olyan szeretné elérni egy helyi felhasználó hozzáférését, aki nem rendelkezik a hozzátartozó Kerberos-szereplõvel. Például a tillman@EXAMPLE.ORG nevû felhasználó el szeretné érni a helyi számítógépen levõ webdevelopers hozzáférést. Más szereplõk is elérhetik a helyi hozzáféréseket. A probléma megoldásához a felhasználók könyvtárában található .k5login és a .k5users állományok használhatóak a .host és .rhosts állományok kombinációjához hasonlóan. Például a .k5login így néz ki: tillman@example.org jdoe@example.org Ezt a webdevelopers nevû helyi felhasználó könyvtárában kell elhelyeznünk, így a felsorolt szereplõt megosztott jelszó használata nélkül képesek elérni a hozzáférést. Az említett parancsok man oldalának elolvasása ajánlott. Megjegyezzük, hogy a ksu man oldal foglalkozik a .k5users állománnyal. Tippek, trükkök a <application>Kerberos</application> használatáról és hibaelhárítás Kerberos5 hibaelhárítás Akár a Kerberos Heimdal vagy az MIT változatát használjuk, ne felejtsük úgy beállítani a PATH környezeti változóban felsorolt elérési utakat, hogy a kliensalkalmazások kerberizált változatai a rendszerben használatos verziók elé kerüljenek. Az övezetben minden számítógép órája ugyanúgy jár? Ha nem, akkor a hitelesítés csõdöt mondhat. A ból tudhatjuk meg hogyan szinkronizáljunk órákat az NTP segítségével. Az MIT és a Heimdal verziók a kadmin kivételével remekül megvannak egymással, mivel az általa használt protokollt még nem szabványosították. Ha megváltoztatjuk a gépünk hálózati nevét, akkor a ugyanígy a host/ szereplõnket is meg kell változtatni és frissíteni a keytab állományunkat. Ez olyan speciális keytab bejegyzésekre is vonatkozik, mint például az Apache www/mod_auth_kerb moduljához tartozó www/ szereplõ. Az övezetünkben levõ összes számítógépnek (mind a két irányba) feloldható DNS névvel kell rendelkeznie (vagy legalább egy /etc/hosts állománnyal). Erre a CNAME rekord megfelelõ, de az A és PTR rekordoknak mindenképpen rendben kell lenniük. Az ilyenkor keletkezõ hibaüzenet nem éppen fogja meg a lényeget: Kerberos5 refuses authentication because Read req failed: Key table entry not found. A kulcselosztó számára kliensként viselkedõ bizonyos operációs rendszerek nem állítják be megfelelõen a ksu engedélyeit, ezért nem lehet root jogokkal futtatni. Ezért a ksu parancs nem fog mûködni, ami alapvetõen nem egy rossz ötlet, de idegesítõ. Ez nem a kulcselosztó hibája. Ha a Kerberos MIT változatát használjuk és a meg akarjuk hosszabbítani a szereplõknek kiadott jegyek élettartamát az alapértelmezett tíz óráról, akkor a kadmin felületén a modify_principal paranccsal tudjuk megváltoztatni mind a kérdéses szereplõ, mind pedig a krbtgt jegyeinek élettartamának maximumát. Ezt követõen a szereplõ a kinit opciójával tud egy nagyobb élettartammal rendelkezõ jegyet kérni. Amikor egy kulcselosztóval kapcsolatos hibát próbálunk felderíteni a csomagok lehallgatásával, és a munkaállomásunkról kiadjuk a kinit parancsot, akkor arra lehetünk figyelmesek, hogy a TGT már egybõl a kinit indításakor átküldésre kerül — még mielõtt egyáltalán megadtuk volna a jelszavunkat! Ezt azzal lehet magyarázni, hogy a Kerberos szerver bármilyen hitelesítetlen kérésre elküld egy TGT-t (Jegyadó jegy, azaz Ticket Granting Ticket). Azonban mindegyik ilyen TGT a felhasználó jelszavából származtatott kulccsal titkosítódik. Ezért amit a felhasználó jelszóként megad, nem megy el a kulcselosztónak, hanem vele a kinit a már megkapott TGT-t kódolja ki. Amennyiben a visszakódolás egy érvényes idõbélyeggel rendelkezõ, használható jegyet eredményez, akkor a felhasználó érvényes Kerberos hitelesítést szerez. Ez a hitelesítés magában foglal egy kulcsot, amellyel a késõbbiekben a Kerberos szerverekkel tudjuk felvenni biztonságos módon a kapcsolatot, és rajta kívül egy újabb jegyadó jegyet, amelyet a Kerberos szerver a saját kulcsával titkosított. A titkosítás második vonala a felhasználó számára ismeretlen, de segítségével a Kerberos szerer képes ellenõrizni az egyes jegyadó jegyek hitelességét. Ha a jegyeket hosszabb (például egyhetes) élettartammal akarjuk használni és a jegyeket tároló géphez OpenSSH segítségével csatlakozunk, akkor mindenképpen ellenõrizzük, hogy az sshd_config állományban a Kerberos beállításának értéke no, máskülönben a kijelentkezés után automatikusan törlõdnek a jegyeink. Ne hagyjuk figyelmen kívül azt sem, hogy a befogadó szereplõk is rendelkezhetnek nagyobb élettartamú jegyekkel. Ha a felhasználónkhoz tartozó szereplõ jegye például egy hét alatt évül el, de a számítógép, amire bejelentkezük, csupán kilenc óráig tartja életben ezeket, akkor a jegyeket tároló gyorsítótárunkban hamarabb elévül a hozzátartozó jegy, ami miatt pedig hibák keletkeznek. Ha a rossz jelszavak használata ellen beállítjuk a krb5.dic állományt (errõl a kadmind man oldalán találunk egy rövid leírást), akkor nem szabad elfelejteni, hogy ez csak olyan szereplõkre vonatkozik, akiknek a jelszavára is állítottunk be szabályozásokat. A krb5.dict állományok felépítési nem bonyolult: minden sorban egyetlen karakterlánc szerepel. Érdemes lehet például létrehozni ezen a néven egy szimbolikus linket a /usr/share/dict/words állományra. Eltérések az <acronym>MIT</acronym> porttól A Heimdal és az MIT változatok közti egyik legnagyobb eltérés a kadmin programmal kapcsolatban van, ami eltérõ (de egyébként ekivalens) parancskészlettel rendelkezik és más protokollt használ. Ennek komoly következménye, hogy ha az MIT-féle kulcselosztót használjuk, akkor azt a Heimdal kadmin felületével nem tudjuk távolról adminisztrálni (és vica versa). A kliensalkalmazások paraméterezése is eltérhet ugyanazon feladatoknál. Ezért velük kapcsolatban az MIT Kerberos honlapja () a mérvadó. Vigyázzunk az elérési utakkal: az MIT port magát alapértelmezés szerint a /usr/local könyvtárba telepíti, ezért az általuk kiváltani kívánt normális rendszerprogramokat esetleg hamarabb találja meg a rendszer, ha nem jól állítottuk be a PATH környezeti változónkat. Ha nem értjük, hogy miért mûködnek olyan furcsán a telnetd és a klogind által kezelt bejelentkezések, akkor olvassuk el a &os; security/krb5 portjával települõ MIT változat /usr/local/share/doc/krb5/README.FreeBSD állományt (angolul). Az a legfontosabb, hogy a incorrect permissions on cache file hiba eltüntetéséhez a login.krb5 binárist kell használnunk, így a továbbított jogosultságoknak megfelelõen át tudja állítani a tulajdonost. Az rc.conf állományt is módosítani kell a következõ beállítás kialakításához: kerberos5_server="/usr/local/sbin/krb5kdc" kadmind5_server="/usr/local/sbin/kadmind" kerberos5_server_enable="YES" kadmind5_server_enable="YES" Erre azért van szükség, mert a Kerberos MIT változata a /usr/local könyvtáron + class="directory">/usr/local könyvtáron belülre telepíti fel a hozzátartozó alkalmazásokat. A <application>Kerberos</application>ban talált korlátozások enyhítése Kerberos5 hiányosságok és korlátozások A <application>Kerberos</application> a <quote>mindent vagy semmit</quote> megközelítést követi A hálózaton minden szolgáltatást módosítanunk kell ahhoz, hogy együtt tudjanak mûködni a Kerberosszal (vagy valamilyen más módon védenünk kell ezeket a támadások ellen), különben a felhasználók jogait el lehet lopni vagy újra fel lehet használni. Erre jó példa lehet az összes távoli parancssoros elérés (például az rsh valamint a telnet) kerberizálása, de a jelszavakat titkosítatlanul küldõ POP3 levelezõ szerver kihagyása. A <application>Kerberos</application> az egyfelhasználós munkaállomások számára készült Többfelhasználós környezetben a Kerberos már nem annyira biztonságos. Ez azért mondható el, mert a jegyeket a mindenki által olvasható /tmp könyvtárban tárolja. Ha az adott felhasználó számítógépét egyszerre több emberrel is megosztja (tehát többfelhasználós), akkor a felhasználó jegyeit egy másik felhasználó bármikor lemásolhatja (ellophatja). Ezt a opció után megadott állománynévvel vagy (inkább) a KRB5CCNAME környezeti változó megfelelõ beállításával tudjuk áthidalni, habár ezt ritkán teszik is meg. Ha a felhasználók könyvtárában és a megfelelõ engedélyekkel tároljuk ezeket a jegyeket, akkor némileg visszaszoríthatjuk a probléma kockázatát. A kulcselosztó a rendszer legsebezhetõbb pontja A rendszer kialakításából fakadóan a kulcselosztónak legalább annyira megbízhatónak kell lennie, mint a rajta levõ központi jelszóadatbázisnak. A kulcselosztón semmilyen más szolgáltatás nem futhat és fizikailag is biztonságba kell helyezni. A kockázat nagy, mivel a Kerberos az összes jelszót ugyanazzal a kulcssal (a mesterkulcssal) titkosítja, amelyet a kulcselosztó egy állományban tárol. Széljegyzet gyanánt hozzátesszük, hogy a mesterkulcs elvesztése nem annyira rossz, mint azt elsõ gondolnánk. A mesterkulcsot csupán a véletlenszám-generátor inicializálásához használják a Kerberos adatbázisának titkosításakor. Amíg a kulcselosztóhoz nem tudnak illetéktelenek hozzáférni, addig nem tudnak sokat kezdeni a mesterkulccsal. Mellesleg ha a kulcselosztó nem elérhetõ (talán pontosan egy DoS támadás vagy éppen hálózati problémák miatt), akkor a hitelesítés nem végezhetõ el, mivel így a hozzá szükséges hálózati szolgáltatások sem használhatóak. Ez remek eszköz egy DoS támadáshoz. Ezen több (egy központi és egy vagy több alárendelt) kulcselosztó telepítésével, valamint a másodlagos vagy tartalékként használt hitelesítési eszközök (a PAM erre tökéletes) körültekintõ megvalósításával enyhíthetünk. A <application>Kerberos</application> hiányosságai A Kerberos révén a felhasználók, számítógépek és szolgáltatások tudják egymást hitelesíteni. Ellenben semmilyen eszközt nem kínál fel a kulcselosztó hitelességének ellenõrzésére. Így tehát (például) egy eltérített kinit képes ellopni az összes felhasználói nevet és jelszót. Az ilyen incidensek elkerülésére a security/tripwire és a hozzá hasonló segédprogramok segítségével lehet megõrizni a rendszer sértelenségét. Erõforrások és további információk Kerberos5 külsõ források A Kerberos GYIK (angolul) Egy hitelesítési rendszer kidolgozása: párbeszéd négy színben (angolul) RFC 1510: A Kerberos hálózati hitelesítési szolgáltatás (V5) (angolul) Az MIT Kerberos holnapja (angolul) A Heimdal Kerberos honlapja (angolul) Tom Rhodes Írta: OpenSSL biztonság OpenSSL A &os;-hez adott OpenSSL az egyik olyan tényezõ, amit a legtöbb felhasználó figyelmen kívül hagy. Az OpenSSL egy titkosítási réteget nyújt a hagyományos kommunikációs csatorna felett, így rengeteg hálózati alkalmazásba és szolgáltatásba bele lehet szõni. Az OpenSSL felhasználható többek közt a levelezõ kliensek titkosított hitelesítésére, hitelkártyás fizetések weben keresztüli lebonyolítására alkalmas, és még sok minden másra. Sok port, köztük a www/apache13-ssl és a mail/sylpheed-claws is felajánlja az OpenSSL felhasználását. A legtöbb esetben a Portgyûjtemény megpróbálja lefordítani a security/openssl portot, hacsak a WITH_OPENSSL_BASE változót határozottan a yes értékre nem állítjuk. A &os;-hez mellékelt OpenSSL ismeri a Secure Sockets Layer v2/v3 (SSLv2/SSLv3) és Transport Layer Security v1 (TLSv1) hálózatbiztonsági protokollokat, és általános célú titkosítási könyvtárként is alkalmazható. Noha az OpenSSL ismeri az IDEA algoritmusát is, az Egyesült Államokban érvényben levõ szabadalmak miatt alapértelmezés szerint nem engedélyezett. A használatához el kell olvasni a hozzátartozó licencet, és ha elfogadjuk a benne foglaltakat, akkor állítsuk be a MAKE_IDEA változót a make.conf állományban. Az OpenSSL-t leginkább a szoftverek tanúsítványainak elkészítéséhez használják. Ilyen tanúsítvánnyokkal lehet szavatolni, hogy az érte felelõs cég vagy egyén valóban megbízható és nem szélhámos. Amennyiben a kérdéses tanúsítványt nem vizsgálta be valamelyik tanúsítványok hitelesítésével foglalkozó hatóság (Certificate Authority, vagy CA), akkor errõl általában kap egy figyelmeztetést a felhasználó. A tanúsítványokat hitelesítõ cégek, mint például a VeriSign, írják alá ezeket a tanúsítványokat és ezzel érvényesítik az egyes cégek vagy egyének megbízhatóságát. Ez ugyan pénzbe kerül, de használatuk egyáltalán nem is kötelezõ. Azonban az átlagosnál paranoidabb felhasználók számára megnyugvást jelenthet. Tanúsítványok elõállítása OpenSSL tanúsítványok elõállítása A tanúsítványok létrehozására a következõ parancs áll rendelkezésre: &prompt.root; openssl req -new -nodes -out req.pem -keyout cert.pem Generating a 1024 bit RSA private key ................++++++ .......................................++++++ writing new private key to 'cert.pem' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:országnév (kétbetûs kóddal) State or Province Name (full name) [Some-State]:állam vagy tartomány teljes neve Locality Name (eg, city) []:település neve Organization Name (eg, company) [Internet Widgits Pty Ltd]:szervezet neve Organizational Unit Name (eg, section) []:szervezeti egység neve Common Name (eg, YOUR name) []:általános név (hálózati név!) Email Address []:e-mail cím Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []:VALAMILYEN JELSZÓ An optional company name []:egy másik szervezet neve Az adatok bekérésére elõtt megjelenõ figyelmeztetõ üzenet fordítása: Itt a tanúsítvány igénylésével kapcsolatos információkat kell megadnunk. Itt egy ún. ismertetõnevet (Distinguished Name, DN) kell megadnunk. Ezen kívül van még néhány más mezõ is, de ezeket akár üresen is hagyhatjuk. Néhány mezõnek van alapértelmezett értéke, de ha oda egy pontot írunk, akkor kitöröljük. A Common Name mezõnél ellenõrzési okokból egy hálózati nevet, tehát a szerverünk nevét kell megadnunk. Ha nem így járunk el, akkor lényegében egy használhatatlan tanúsítványt kapunk. További opciók is elérhetõek, mint például a lejárati idõ (expire time) megadása, a titkosítási algoritmus megváltoztatása stb. Ezek teljes listája megtalálható az &man.openssl.1; man oldalon. Az elõbbi parancs kiadása után két állománynak kell létrejönnie az aktuális könyvtárban. A tanúsítványkérést, vagyis az req.pem állományt kell eljuttatnunk a tanúsítványok hitelesítésével foglakozó szervhez, aki majd érvényesíti az imént megadott adatainkat. A második, cert.pem nevû állomány a tanúsítványhoz tartozó privát kulcs, amit semmilyen körülmények között sem szabad kiadnunk. Ha ez mások kezébe kerül, akkor el tudnak játszani bennünket (vagy a szerverünket). Amikor a hitelesítõ szerv aláírása nem feltétlenül szükséges, akkor készíthetünk egy saját magunk által aláírt tanúsítványt is. Ehhez elõször is generálnunk kell egy RSA-kulcsot: &prompt.root; openssl dsaparam -rand -genkey -out saját_RSA.kulcs 1024 Most pedig készítsünk el a hitelesítõ szerv kulcsát is: &prompt.root; openssl gendsa -des3 -out hitelesítõ.kulcs saját_RSA.kulcs Ezzel a kulccsal most gyártsunk le egy tanúsítványt: &prompt.root; openssl req -new -x509 -days 365 -key hitelesítõ.kulcs -out új.tanúsítvány Ekkor két új állomány keletkezik a könyvtárunkban: a hitelesítõ szerv aláírása, a hitelesítõ.kulcs és maga a tanúsítvány, az új.tanúsítvány állomány. Ezeket tegyük az /etc könyvtáron belül egy olyan könyvtárba, amelyet csak a root tud olvasni. A chmod paranccsal állítsunk be rá 0700-as kódú engedélyeket. Példa a tanúsítványok használatára Mire is jók ezek az állományok? Például kitûnõen alkalmazhatóak a Sendmail levelezõ szerverhez beérkezõ kapcsolatot titkosítására. Így lényegében felszámoljuk minden olyan felhasználó titkosítatlan módon zajló hitelesítését, aki a helyi levelezõ szerveren keresztül küldi a leveleit. Ez általában nem a legjobb megoldás, mivel egyes levelezõ kliensek hibát jeleneznek a felhasználónak, ha nem rendelkezik a tanúsítvánnyal. A tanúsítványok telepítésével kapcsolatban olvassuk el a szoftverhez adott leírást. A helyi .mc állományba ezeket a sorokat kell beletenni: dnl SSL Options define(`confCACERT_PATH',`/etc/certs')dnl define(`confCACERT',`/etc/certs/új.tanúsítvány')dnl define(`confSERVER_CERT',`/etc/certs/új.tanúsítvány')dnl define(`confSERVER_KEY',`/etc/certs/hitelesítõ.kulcs')dnl define(`confTLS_SRV_OPTIONS', `V')dnl Itt a /etc/certs/ az a könyvtár, amit tanúsítványok és kulcsok helyi tárolására használunk. Végezetül még újra kell generálnunk a helyi .cf állományokat. Ezt a /etc/mail könyvtárban a make install parancs kiadásával könnyen elvégezhetjük. Miután ez megtörtént, akkor Sendmailhoz tartozó démont a make restart paraméterével indíthatjuk újra. Ha minden jól ment, akkor a /var/log/maillog állományban nem találunk egyetlen hibaüzenetet sem, és a Sendmail is megjelenik a futó programok között. A &man.telnet.1; segédprogrammal így probálhatjuk ki a levelezõ szervert: &prompt.root; telnet example.com 25 Trying 192.0.34.166... Connected to example.com. Escape character is '^]'. 220 example.com ESMTP Sendmail 8.12.10/8.12.10; Tue, 31 Aug 2004 03:41:22 -0400 (EDT) ehlo example.com 250-example.com Hello example.com [192.0.34.166], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-8BITMIME 250-SIZE 250-DSN 250-ETRN 250-AUTH LOGIN PLAIN 250-STARTTLS 250-DELIVERBY 250 HELP quit 221 2.0.0 example.com closing connection Connection closed by foreign host. Ha itt megjelenik a STARTTLS sor, akkor mindent sikerült beállítanunk. Nik Clayton
nik@FreeBSD.org
 Írta: IPsec VPN IPsec felett VPN létrehozása &os; átjárók használatával két olyan hálózat között, amelyeket egymástól az internet választ el. Hiten M. Pandya
hmp@FreeBSD.org
 Írta: Az IPsec bemutatása Ebben a szakaszban az IPsec beállításának folyamatát vázoljuk fel. Az IPsec beállításához elengedhetetlen, hogy tisztában legyünk egy saját rendszermag fordításának alapjaival (lásd ). Az IPsec egy olyan protokoll, amely az Internet Protocol (IP) rétegére épül. Segítségével két vagy több számítógép képes biztonságos módon tartani egymással a kapcsolatot (innen ered a neve). A &os; IPsec hálózati protokollkészlete a KAME implementációjára épül, mely egyaránt támogatja az IPv4 és IPv6 protokollcsaládokat. IPsec ESP IPsec AH Az IPsec két alprotokollból tevõdik össze: A hasznos adat biztonságos becsomagolása (Encapsulated Security Payload, ESP) során egy szimmetrikus kriptográfiai algoritmussal (mint például Blowfish, 3DES) titkosítjuk az IP-csomagok tartalmát, ezáltal megvédjük ezeket az illetéktelenektõl. A Hitelesítési fejléc (Authentication Header, AH) használatával megakadályozzuk, hogy az illetéktelenek meghamisítsák az IP csomagok fejlécét. Ezt úgy érjük el, hogy kiszámolunk egy kriptográfiai ellenõrzõ összeget és az IP-csomagok fejlécének mezõire egy biztonságos függvénnyel generálunk valamilyen ujjlenyomatot. Az ez után következõ kiegészítõ fejléc tartalmazza ezt az ujjlenyomatot, amellyel a csomag hitelesíthetõ. Az ESP és az AH az alkalmazástól függõen használható együtt vagy külön-külön. VPN virtuális magánhálózat VPN Az IPsec akár közvetlenül is használható két számítógép forgalmának titkosítására (ezt Szállítási módnak (Transport Mode) nevezik), vagy két alhálózat között építhetünk ki vele virtuális tunneleket, ami remekül alkalmas két vállalati hálózat kommunikációjának bebiztosítására (ez a Tunnel mód (Tunnel Mode)). Ez utóbbit egyszerûen csak Virtuális magánhálózatként (Virtual Private Network, VPN) emlegetik. A &os; IPsec alrendszerérõl az &man.ipsec.4; man oldalon találhatunk további információkat. A rendszermag IPsec támogatásának aktiválásához a következõ paramétereket kell beletennünk a konfigurációs állományba: a rendszermag beállításai IPSEC options IPSEC # IP biztonság device crypto a rendszermag beállításai IPSEC_DEBUG Ha szükségünk van a IPsec nyomkövetésére, a következõ beállítást is hozzátehetjük: options IPSEC_DEBUG # az IP biztonság nyomkövetése A probléma Semmilyen szabvány nem fogalmazza meg mi is számít VPN-nek. A virtuális magánhálózatok tucatnyi különbözõ technológiával valósíthatóak meg, de mindegyiknek megvan a maga erõssége és gyengesége. Ebben a szakaszban körvonalazunk egy ilyen helyzetet, valamint a benne felépített VPN megvalósításához alkalmazott stratégiákat. A forgatókönyv: adott egy otthoni és egy vállalati hálózat, amelyek külön-külön csatlakoznak az internetre, és <acronym>VPN</acronym> használatával ezeket egyetlen hálózatként szeretnénk használni VPN létrehozása Elõfeltételezéseink a következõek: legalább két hálózatunk van; magán belül mind a két hálózat IP-t használ; mind a két hálózat egy &os; átjárón keresztül csatlakozik az internethez; a hálózatok átjárói legalább egy publikus IP-címmel rendelkeznek; a hálózatok belsõ címei lehetnek publikus vagy privát IP-címek, nem számít. Fontos viszont, hogy ezek ne ütközzenek, vagyis ne használja egyszerre mind a kettõ a 192.168.1.x címtartományt. Tom Rhodes
trhodes@FreeBSD.org
 Írta: Az IPsec beállítása &os; alatt Kezdésképpen a Portgyûjteménybõl telepítenünk kell a security/ipsec-tools portot. Ez a programcsomag rengeteg olyan alkalmazást tartalmaz, amely segítségünkre lehet a beállítások elvégzése során. A következõ lépésben létre kell hoznunk két &man.gif.4; típusú pszeudoeszközt, melyeken keresztül a két hálózat között egy tunnel segítségével ki tudjuk építeni a szükséges kapcsolatot. Ehhez root felhasználóként futtassuk a következõ parancsokat (a belsõ és külsõ megnevezésû paramétereket cseréljük ki a valós belsõ és külsõ átjárók címeire): &prompt.root; ifconfig gif0 create &prompt.root; ifconfig gif0 belsõ1 belsõ2 &prompt.root; ifconfig gif0 tunnel külsõ1 külsõ2 Tekintsük például, hogy a vállalati LAN publikus IP-címe 172.16.5.4, valamint a privát IP-címe 10.246.38.1. Az otthoni LAN publikus IP-címe legyen most 192.168.1.12, valamint a belsõ privát IP-címe pedig 10.0.0.5. Elsõre ez talán még nem teljesen érthetõ, ezért az &man.ifconfig.8; parancs használatával is nézzük meg a példában szereplõ hálózatok konfigurációját: Az elsõ átjáró: gif0: flags=8051 mtu 1280 tunnel inet 172.16.5.4 --> 192.168.1.12 inet6 fe80::2e0::81ff:fe02:5881%gif0 prefixlen 64 scopeid 0x6 inet 10.246.38.1 --> 10.0.0.5 netmask 0xffffff00 A második átjáró: gif0: flags=8051 mtu 1280 tunnel inet 192.168.1.12 --> 172.16.5.4 inet 10.0.0.5 --> 10.246.38.1 netmask 0xffffff00 inet6 fe80::250:bfff:fe3a:c1f%gif0 prefixlen 64 scopeid 0x4 Miután elvégeztük az iménti beállításokat, a &man.ping.8; paranccsal már mind a két privát IP-tartománynak elérhetõnek kell lennie, ahogy azt az alábbi példa is érzékeltetni kívánja: otthoni-halo# ping 10.0.0.5 PING 10.0.0.5 (10.0.0.5): 56 data bytes 64 bytes from 10.0.0.5: icmp_seq=0 ttl=64 time=42.786 ms 64 bytes from 10.0.0.5: icmp_seq=1 ttl=64 time=19.255 ms 64 bytes from 10.0.0.5: icmp_seq=2 ttl=64 time=20.440 ms 64 bytes from 10.0.0.5: icmp_seq=3 ttl=64 time=21.036 ms --- 10.0.0.5 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 19.255/25.879/42.786/9.782 ms vallalati-halo# ping 10.246.38.1 PING 10.246.38.1 (10.246.38.1): 56 data bytes 64 bytes from 10.246.38.1: icmp_seq=0 ttl=64 time=28.106 ms 64 bytes from 10.246.38.1: icmp_seq=1 ttl=64 time=42.917 ms 64 bytes from 10.246.38.1: icmp_seq=2 ttl=64 time=127.525 ms 64 bytes from 10.246.38.1: icmp_seq=3 ttl=64 time=119.896 ms 64 bytes from 10.246.38.1: icmp_seq=4 ttl=64 time=154.524 ms --- 10.246.38.1 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 28.106/94.594/154.524/49.814 ms Az elvárásainknak megfelelõen tehát a privát címeken mind a két oldalnak képesnek kell lennie ICMP csomagokat küldenie és fogadnia. A következõ lépésben meg kell mondanunk az átjáróknak hogyan irányítsák a csomagokat a két hálózat közti forgalom megfelelõ áramlásához. Ezt az alábbi paranccsal elérhetjük el: &prompt.root; vallalati-halo# route add 10.0.0.0 10.0.0.5 255.255.255.0 &prompt.root; vallalati-halo# route add net 10.0.0.0: gateway 10.0.0.5 &prompt.root; otthoni-halo# route add 10.246.38.0 10.246.38.1 255.255.255.0 &prompt.root; otthoni-halo# route add host 10.246.38.0: gateway 10.246.38.1 Itt már a belsõ gépeket az átjárókról és az átjárók mögül egyaránt el tudjuk érni. A következõ példa alapján errõl könnyedén meg is tudunk gyõzõdni: vallalati-halo# ping 10.0.0.8 PING 10.0.0.8 (10.0.0.8): 56 data bytes 64 bytes from 10.0.0.8: icmp_seq=0 ttl=63 time=92.391 ms 64 bytes from 10.0.0.8: icmp_seq=1 ttl=63 time=21.870 ms 64 bytes from 10.0.0.8: icmp_seq=2 ttl=63 time=198.022 ms 64 bytes from 10.0.0.8: icmp_seq=3 ttl=63 time=22.241 ms 64 bytes from 10.0.0.8: icmp_seq=4 ttl=63 time=174.705 ms --- 10.0.0.8 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 21.870/101.846/198.022/74.001 ms otthoni-halo# ping 10.246.38.107 PING 10.246.38.1 (10.246.38.107): 56 data bytes 64 bytes from 10.246.38.107: icmp_seq=0 ttl=64 time=53.491 ms 64 bytes from 10.246.38.107: icmp_seq=1 ttl=64 time=23.395 ms 64 bytes from 10.246.38.107: icmp_seq=2 ttl=64 time=23.865 ms 64 bytes from 10.246.38.107: icmp_seq=3 ttl=64 time=21.145 ms 64 bytes from 10.246.38.107: icmp_seq=4 ttl=64 time=36.708 ms --- 10.246.38.107 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 21.145/31.721/53.491/12.179 ms A tunnelek beállítása volt igazából a könnyebb rész, egy biztonságos összeköttetés kialakítása azonban már valamivel komolyabb folyamatot rejt magában. A most következõ konfigurációban erre elõre ismert (vagyis pre-shared, PSK) RSA-kulcsokat fogunk használni. A konkrét IP-címektõl eltekintve az átjárókon a /usr/local/etc/racoon/racoon.conf állományok hasonlóan fognak kinézni, nagyjából valahogy így: path pre_shared_key "/usr/local/etc/racoon/psk.txt"; # az ismert kulcsot tartalmazó állomány helye log debug; # a naplózás részletességének beállítása: ha végeztünk a teszteléssel és a hibakereséssel, akkor állítsuk át a 'notify' értékre padding # ezeket ne nagyon változtassuk meg { maximum_length 20; randomize off; strict_check off; exclusive_tail off; } timer # idõzítési beállítások, állítsuk be igény szerint { counter 5; interval 20 sec; persend 1; # natt_keepalive 15 sec; phase1 30 sec; phase2 15 sec; } listen # cím [port], ahol a racoon majd válaszolni fog { isakmp 172.16.5.4 [500]; isakmp_natt 172.16.5.4 [4500]; } remote 192.168.1.12 [500] { exchange_mode main,aggressive; doi ipsec_doi; situation identity_only; my_identifier address 172.16.5.4; peers_identifier address 192.168.1.12; lifetime time 8 hour; passive off; proposal_check obey; # nat_traversal off; generate_policy off; proposal { encryption_algorithm blowfish; hash_algorithm md5; authentication_method pre_shared_key; lifetime time 30 sec; dh_group 1; } } sainfo (address 10.246.38.0/24 any address 10.0.0.0/24 any) # address $hálózat/$hálózati_maszk $típus address $hálózat/$hálózati_maszk $típus # (a $típus lehet "any" vagy "esp") { # a $hálózat a két összekapcsolni kívánt belsõ hálózat legyen pfs_group 1; lifetime time 36000 sec; encryption_algorithm blowfish,3des,des; authentication_algorithm hmac_md5,hmac_sha1; compression_algorithm deflate; } A példában szereplõ összes opció részletes kifejtése jóval meghaladná ezen leírás kereteit, ezért a bõvebb információkkal kapcsolatban inkább a racoon beállításaihoz tartozó man oldal elolvasását javasoljuk. A gépek közti hálózati forgalom titkosításához be kell még állítanunk egy SPD házirendet is, így a &os; és a racoon képes kódolni és dekódolni a csomagokat. Ezt a most következõ, a vállalati átjárón találhatóhoz hasonló egyszerû shell szkripttel tudjuk elvégezni. Ezt az állományt a rendszer indításakor fogjuk felhasználni, melyet /usr/local/etc/racoon/setkey.conf néven mentsünk el: flush; spdflush; # Az otthoni hálózati felé spdadd 10.246.38.0/24 10.0.0.0/24 any -P out ipsec esp/tunnel/172.16.5.4-192.168.1.12/use; spdadd 10.0.0.0/24 10.246.38.0/24 any -P in ipsec esp/tunnel/192.168.1.12-172.16.5.4/use; Ahogy ezzel megvagyunk, a racoon az egyes átjárókon a következõ paranccsal indítható el: &prompt.root; /usr/local/sbin/racoon -F -f /usr/local/etc/racoon/racoon.conf -l /var/log/racoon.log A parancs eredménye ennek megfelelõen nagyjából a következõ lesz: vallalati-halo# /usr/local/sbin/racoon -F -f /usr/local/etc/racoon/racoon.conf Foreground mode. 2006-01-30 01:35:47: INFO: begin Identity Protection mode. 2006-01-30 01:35:48: INFO: received Vendor ID: KAME/racoon 2006-01-30 01:35:55: INFO: received Vendor ID: KAME/racoon 2006-01-30 01:36:04: INFO: ISAKMP-SA established 72.16.5.4[500]-192.168.1.12[500] spi:623b9b3bd2492452:7deab82d54ff704a 2006-01-30 01:36:05: INFO: initiate new phase 2 negotiation: 72.16.5.4[0]192.168.1.12[0] 2006-01-30 01:36:09: INFO: IPsec-SA established: ESP/Tunnel 92.168.1.12[0]->172.16.5.4[0] spi=28496098(0x1b2d0e2) 2006-01-30 01:36:09: INFO: IPsec-SA established: ESP/Tunnel 172.16.5.4[0]->192.168.1.12[0] spi=47784998(0x2d92426) 2006-01-30 01:36:13: INFO: respond new phase 2 negotiation: 172.16.5.4[0]192.168.1.12[0] 2006-01-30 01:36:18: INFO: IPsec-SA established: ESP/Tunnel 192.168.1.12[0]->172.16.5.4[0] spi=124397467(0x76a279b) 2006-01-30 01:36:18: INFO: IPsec-SA established: ESP/Tunnel 172.16.5.4[0]->192.168.1.12[0] spi=175852902(0xa7b4d66) A tunnel megfelelõ mûködését úgy tudjuk ellenõrizni, ha átváltunk egy másik konzolra és a &man.tcpdump.1; program segítségével figyeljük a hálózati forgalmat. A példában szereplõ em0 interfészt természetesen ne felejtsük el kicserélni a megfelelõ eszköz nevére. &prompt.root; tcpdump -i em0 host 172.16.5.4 and dst 192.168.1.12 Ennek hatására az alábbiakhoz hasonló adatoknak kellene megjelennie a konzolon. Amennyiben nem ez történik, valamilyen hiba történt, ezért meg kell keresnünk azt a visszakapott adatok alapján. 01:47:32.021683 IP vallalatihalozat.com > 192.168.1.12.otthonihalozat.com: ESP(spi=0x02acbf9f,seq=0xa) 01:47:33.022442 IP vallalatihalozat.com > 192.168.1.12.otthonihalozat.com: ESP(spi=0x02acbf9f,seq=0xb) 01:47:34.024218 IP vallalatihalozat.com > 192.168.1.12.otthonihalozat.com: ESP(spi=0x02acbf9f,seq=0xc) Itt már mind a két hálózatnak elérhetõnek kell lennie és egyként kell látszódnia. A hálózatokat ezen felül még érdemes külön védeni egy tûzfallal is. Ilyenkor a csomagok két hálózati közti zavartalan oda-vissza vándorlásához további szabályokat kell még felvennünk a tûzfal szabályrendszerébe. A &man.ipfw.8; tûzfal esetén ez a következõ sorok hozzáadását jelenti a tûzfal konfigurációs állományához: ipfw add 00201 allow log esp from any to any ipfw add 00202 allow log ah from any to any ipfw add 00203 allow log ipencap from any to any ipfw add 00204 allow log usp from any 500 to any A szabályok számozását mindig az adott gép aktuális beállításainak megfelelõen kell módosítani. A &man.pf.4; és &man.ipf.8; felhasználók számára ehhez a következõ parancsot javasoljuk: pass in quick proto esp from any to any pass in quick proto ah from any to any pass in quick proto ipencap from any to any pass in quick proto udp from any port = 500 to any port = 500 pass in quick on gif0 from any to any pass out quick proto esp from any to any pass out quick proto ah from any to any pass out quick proto ipencap from any to any pass out quick proto udp from any port = 500 to any port = 500 pass out quick on gif0 from any to any Végezetül a következõ sor hozzáadásával engedélyezzük az /etc/rc.conf állományban a VPN indítását a rendszer indítása során: ipsec_enable="YES" ipsec_program="/usr/local/sbin/setkey" ipsec_file="/usr/local/etc/racoon/setkey.conf" # engedélyezzük az spd házirend beállítását a rendszer indításakor racoon_enable="yes" Chern Lee Írta: OpenSSH OpenSSH biztonság OpenSSH Az OpenSSH olyan hálózati kapcsolódási eszközök összessége, amivel biztonságos módon érhetünk el távoli számítógépeket. Az rlogin, rsh, rcp és a telnet direkt kiváltására használható. Emellett SSH-n keresztül TCP/IP kapcsolatok is biztonságosan bújtathatóak vagy küldhetõek tovább. Az OpenSSH-t az OpenBSD projekt tartja karban, és az SSH 1.2.12 verziójára épül hibajavításokkal és frissítésekkel egyetemben. Az SSH 1 és 2 protokollokkal egyaránt kompatibilis. Az <application>OpenSSH</application> használatának elõnyei A hétköznapi esetben, vagyis amikor a &man.telnet.1; vagy &man.rlogin.1; alkalmazásokat használjuk, az adatok titkosítatlan formában közlekednek a hálózaton. A szerver és a kliens közé bárhova becsatlakozó hálózati kíváncsiskodók így könnyedén el tudják lopni a felhasználói nevünket és jelszavunkat, vagy lényegében bármilyen adatot, ami az adott munkamenetben megfordul. Az OpenSSH ennek kivédésére kínál fel különféle hitelesítési és titkosítási eszközöket. Az sshd engedélyezése OpenSSH engedélyezés Az sshd a &os; telepítésekor jelentkezõ Standard lehetõségek egyike. Az sshd engedélyezését úgy tudjuk kideríteni, ha az rc.conf állományban megkeressük a következõ sort: sshd_enable="YES" Ez tölti be a rendszer indításakor az &man.sshd.8;-t, az OpenSSH démonát. Vagy az /etc/rc.d/sshd &man.rc.8; szkript segítségével is elindíthatjuk az OpenSSH-t: /etc/rc.d/sshd start Az SSH kliens OpenSSH kliens Az &man.ssh.1; segédprogram az &man.rlogin.1; programhoz hasonlóan mûködik. &prompt.root; ssh felhasználó@gép.hu Host key not found from the list of known hosts. Are you sure you want to continue connecting (yes/no)? yes Host 'gép.hu' added to the list of known hosts. felhasználó@gép.hu's password: ******* Az üzenetek fordítása: Nem találtam meg a gépet az ismert gépek között. Biztosan csatlakozni akarunk hozzá (igen/nem)? igen A 'gép.hu' felkerült az ismert gépek közé. Adja meg a felhasználó@gép.hu jelszavát: Bejelentkezés után minden ugyanolyan, mintha az rlogin vagy a telnet programokat használtuk volna. Az SSH egy kulcs segítségével próbálja azonosítani a számítógépeket, ezzel ellenõrzi a szerver hitelességét a kliensek csatlakozásakor. A felhasználónak ilyenkor elõször mindig yes választ kell adnia. A késõbbi bejelentkezési kísérletek pedig majd mindig az így kapott kulccsal történnek. Ha eltérne a kulcs, akkor az SSH kliens erre figyelmeztetni fog minket. A kulcsok a ~/.ssh/known_hosts vagy az SSH v2 protokoll esetén a ~/.ssh/known_hosts2 állományba kerülnek elmentésre. Alapértelmezés szerint az OpenSSH szerverek csak SSH v2 kapcsolatokat fogadnak el. Lehetõség szerint a kliens is ezt a változatot fogja használni, de ha nem sikerül, akkor megpróbálkozik a v1-el. A kliensnek a vagy opciók segítségével elõ is lehet írni, hogy az elsõ vagy a második változatot használja. A kliensben az elsõ változat támogatását csupán a régebbi verziók kompatibilitása miatt tartják karban. Biztonságos másolás OpenSSH biztonságos másolás scp Az &man.scp.1; parancs az &man.rcp.1; parancshoz hasonlóan mûködik: egyik géprõl másol a másikra, biztonságosan. &prompt.root; scp felhasználó@gép.hu:/COPYRIGHT COPYRIGHT felhasználó@gép.hu's password: ******* COPYRIGHT 100% |*****************************| 4735 00:00 &prompt.root; Mivel a kulcsot már ismerjük ehhez a távoli géphez (az elõbbi példából), ezért az &man.scp.1; használatakor már ezzel hitelesítünk. Az &man.scp.1; paraméterei hasonlóak a &man.cp.1; parancséhoz: elsõ helyen az állomány vagy állományok neveit adjuk meg, a másodikon pedig a célt. Mivel az állományokat a hálózaton SSH-n keresztül küldik át, ezért az állományok neveit formában kell megadni. Beállítások OpenSSH beállítások Az OpenSSH démon és kliens rendszerszintû konfigurációs állományai az /etc/ssh könyvtárban találhatóak. Az ssh_config tartalmazza a kliens beállításait, miközben az sshd_config tartalmazza a démonét. Emellett az rc.conf állományban megadható (ez alapból a /usr/sbin/sshd) és opciókkal további beállítási szinteket nyújtanak. ssh-keygen Jelszavak helyett az &man.ssh-keygen.1; programmal a felhasználók azonosítására DSA- vagy RSA-kulcsokat tudunk készíteni: &prompt.user; ssh-keygen -t dsa Generating public/private dsa key pair. Enter file in which to save the key (/home/felhasználó/.ssh/id_dsa): Created directory '/home/felhasználó/.ssh'. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/felhasználó/.ssh/id_dsa. Your public key has been saved in /home/felhasználó/.ssh/id_dsa.pub. The key fingerprint is: bb:48:db:f2:93:57:80:b6:aa:bc:f5:d5:ba:8f:79:17 felhasználó@gép.hu Az &man.ssh-keygen.1; ekkor a hitelesítésre létrehoz egy publikus és egy privát kulcsból álló párt. A privát kulcs a ~/.ssh/id_dsa vagy ~/.ssh/id_rsa állományba kerül, miközben a publikus kulcs a ~/.ssh/id_dsa.pub vagy ~/.ssh/id_rsa.pub lesz attól függõen, hogy DSA vagy RSA a kulcs típusa. A módszer mûködéséhez a publikus DSA- vagy RSA-kulcsot a távoli számítógép ~/.ssh/authorized_keys állományába kell bemásolni. Így tehát a távoli számítógépre jelszavak alkalmazása helyett SSH-kulccsal tudunk belépni. Ha az &man.ssh-keygen.1; parancsnak megadunk egy jelmondatot is, akkor a felhasználó a privát kulcsát csak ennek megadásával tudja használni. A hosszú jelmondatok állandó beirogatásától a szakaszban hamarosan bemutatásra került &man.ssh-agent.1; igyekszik megkímélni minket. A különbözõ opciók és állományok eltérhetnek a számítógépünkre telepített OpenSSH verziójától függõen. Ilyen esetben javasolt felkeresni az &man.ssh-keygen.1; man oldalát. Az ssh-agent és az ssh-add Az &man.ssh-agent.1; és &man.ssh-add.1; segédprogramokkal be tudjuk tölteni az SSH-kulcsokat a memóriába, amivel elkerülhetjük a jelmondat állandó begépelését. A hitelesítést az &man.ssh-agent.1; program kezeli a betöltött privát kulcsok alapján. Az &man.ssh-agent.1; használatával egy másik programot is elindhatunk, egy parancsértelmezõtõl kezdve egy ablakkezelõig szinte bármit. Az &man.ssh-agent.1; programot úgy tudjuk egy parancsértelmezõben használni, hogy elõször is elindítjuk vele az adott parancsértelmezõt. Ezután az &man.ssh-add.1; lefuttatásával hozzá kell adnunk egy identitást, annak jelmondatának megadásával. Miután ezeket megtettük, a felhasználó bármelyik olyan távoli gépre be tud jelentkezni, ahol a publikus kulcsát ismerik. Például: &prompt.user; ssh-agent csh &prompt.user; ssh-add Enter passphrase for /home/felhasználó/.ssh/id_dsa: Identity added: /home/felhasználó/.ssh/id_dsa (/home/felhasználó/.ssh/id_dsa) &prompt.user; Az &man.ssh-agent.1; programot X11-el úgy tudjuk használni, ha az ~/.xinitrc állományba tesszük bele. Ezzel az &man.ssh-agent.1; az összes X11-ben indított program számára rendelkezésre áll. Példának vegyük ezt az ~/.xinitrc állományt: exec ssh-agent startxfce4 Így az X11 indulásakor mindig elindul az &man.ssh-agent.1;, amely pedig elindítja az XFCE alkalmazást. Miután átírtuk a saját állományunkat, a rendszer életbeléptetéséhez indítsuk újra az X11-et, az &man.ssh-add.1; futtatásával pedig töltsük be az összes SSH-kulcsunkat. Tunnelezés SSH-val OpenSSH tunnelezés Az OpenSSH-val létre tudunk hozni egy tunnelt, amellyel egy másik protokoll adatait tudjuk titkosított módon becsomagolni. Az alábbi parancs arra utasítja az &man.ssh.1; programot, hogy hozzon létre egy tunnelt a telnet használatához: &prompt.user; ssh -2 -N -f -L 5023:localhost:23 felhasználó@izé.mizé.hu &prompt.user; Az ssh parancsnak a következõ kapcsolókat adtuk meg: Az ssh parancs a protokoll második változatát használja. (Ne adjuk meg, ha régi SSH szerverekkel dolgozunk.) Tunnel létrehozása. Ha nem adjuk meg, akkor az ssh egy hagyományos munkamenet felépítését kezdi meg. Az ssh a háttérben fusson. Egy helyi tunnel a helyiport:távoligép:távoliport felírásban. A távoli SSH szerver. Az SSH által létrehozott járatok úgy mûködnek, hogy létrehozunk egy csatlakozást a localhost (a helyi gép) megadott portján. Ezután minden olyan kapcsolatot, ami a helyi gép adott portjára érkezik, SSH-n keresztül átirányítunk a távoli gép portjára. Ebben a példában a helyi gép 5023 portját átirányítjuk a helyi gép 23 portjára. Mivel a 23 a telnet portja, ezért az így definiált SSH járattal egy biztonságos telnet munkamenetet hozunk létre. Ezen a módon tetszõleges nem biztonságos TCP protokollt, például SMTP-t, POP3-at, FTP-t stb. be tudunk csomagolni. Biztonságos tunnel létrehozása SSH-val SMTP-hez &prompt.user; ssh -2 -N -f -L 5025:localhost:25 felhasználó@levelezõ.szerver.hu felhasználó@levelezõ.szerver.hu's password: ***** &prompt.user; telnet localhost 5025 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 levelezõ.szerver.hu ESMTP Az &man.ssh-keygen.1; és további felhasználói hozzáférések alkalmazásával ezen a módon ki tudunk alakítani egy minden további problémától és zûrtõl mentes SSH tunnelezési környezetet. A jelszavak helyett kulcsokat használunk és minden tunnel külön felhasználóként is futtatható. Gyakorlati példák a tunnelek használatára Egy POP3 szerver biztonságos elérése Tegyük fel, hogy a munkahelyünkön van egy SSH szerver, amire kívülrõl lehet csatlakozni, illetve vele egy hálózatban van egy POP3 levelezõ szerver is. A munkahelyünk és az otthonunk között levõ hálózati útvonalat részben vagy teljesen nem tartjuk megbízhatónak. Ezért az e-mailjeinket valamilyen biztonságos módon szeretnénk elérni. Ezt úgy tudjuk megvalósítani, ha otthonról csatlakozunk a munkahelyen levõ SSH szerverre és ezen keresztül érjük a levelezõ szervert. &prompt.user; ssh -2 -N -f -L 2110:levél.gép.hu:110 felhasználó@ssh-szerver.gép.hu felhasználó@ssh-szerver.gép.hu's password: ****** Miután a tunnel létrejött és mûködõképes, állítsuk be a levelezõ kliensünkben, hogy a POP3 kéréseket a localhost 2110 portjára küldje. Innen pedig biztonságos módon megy tovább a levél.gép.hu címre. Egy szigorú tûzfal megkerülése Egyes hálózati adminisztrátorok túlságosan szigorú szabályokat adnak meg a tûzfalban, és nem csak a bejövõ kapcsolatokat szûrik, hanem a kimenõket is. A távoli gépekhez csak a 22 (SSH) és 80 (böngészés) portjaikon tudunk csatlakozni. Mi viszont szeretnénk más (nem egészen a munkánkkal kapcsolatos) szolgáltatásokat is elérni, például egy Ogg Vorbis szerverrõl zenét hallgatni. Ehhez a szerverhez viszont csak akkor tudnánk csatlakozni, ha a 22 vagy 80 portokon üzemelne. Ezt a problémát úgy oldhatjuk meg, ha felépítünk egy SSH kapcsolatot a hálózatunk tûzfalán kívül levõ számítógéppel és segítségével átbújunk az Ogg Vorbis szerverhez. &prompt.user; ssh -2 -N -f -L 8888:zene.gép.hu:8000 felhasználó@tûzfalazatlan-rendszer.gép.org felhasználó@tûzfalazatlan-rendszer.gép.org's password: ******* A zenelejátszó kliensüknek adjuk meg a localhost 8888 portját, amely pedig a tûzfal sikeres kijátszásával továbbítódik a zene.gép.hu 8000-res portjára. Az <varname>AllowUsers</varname> felhasználói beállítás Gyakran nem árt korlátozni a felhasználók bejelentkezését. Az AllowUsers erre tökéletesen megfelel. Például, ha csak 192.168.1.32 címrõl engedjük bejelentkezni a root felhasználót, akkor ehhez valami ilyesmit kell beírnunk az /etc/ssh/sshd_config állományba: AllowUsers root@192.168.1.32 Ezzel pedig csupán nevének megadásával engedélyezzük az admin felhasználó bejelentkezését (bárhonnan): AllowUsers admin Egy sorban több felhasználó is megadható, mint például: AllowUsers root@192.168.1.32 admin Ilyenkor ne felejtsük el megadni az összes bejelentkezésre (valamilyen formában) jogosult felhasználót megadni, máskülönben kizárjuk ezeket. Miután elvégeztük a szükséges változtatásokat az /etc/ssh/sshd_config állományban, utasítsuk az &man.sshd.8; démont a konfigurációs állományok újraolvasására: &prompt.root; /etc/rc.d/sshd reload Ajánlott olvasnivalók (angolul) OpenSSH &man.ssh.1; &man.scp.1; &man.ssh-keygen.1; &man.ssh-agent.1; &man.ssh-add.1; &man.ssh.config.5; &man.sshd.8; &man.sftp-server.8; &man.sshd.config.5; Tom Rhodes Írta: ACL Az állományrendszerek hozzáféréseit vezérlõ listák A &os; 5.0 és késõbbi változatai különbözõ fejlesztéseket hoztak az állományrendszerekben, például a pillanatképek készítése vagy a hozzáférés-vezérlési listák (Access Control List, ACL-ek) támogatása. A hozzáférés-vezérlési listák a szabványos &unix;-os engedély modellt bõvítik ki egy igen kompatibilis (&posix;.1e) módon. Használatával a rendszergazdák egy sokkal kifinomultabb biztonsági modellt tudhatnak a kezük ügyében. Az UFS állományrendszerek ACL támogatását úgy tudjuk engedélyezni, ha a rendszermagot az options UFS_ACL paraméterrel fordítjuk le. Amennyiben ezt nem fordítottuk bele, akkor az ACL támogatással rendelkezõ állományrendszerek csatlakoztatása során egy figyelmeztetést kapunk. Ez az opció a GENERIC rendszermag része. Az ACL az állományrendszeren engedélyezett kiterjesztett tulajdonságokra támaszkodik. Ezeket a kiterjesztett tulajdonságokat a következõ generációs &unix; állományrendszer, az UFS2 már alapból ismeri. UFS1 típusú állományrendszereken sokkal nagyobb a kiterjesztett tulajdonságok kezelésének költsége, mint az UFS2 esetében. Az UFS2 jóval nagyobb teljesítménnyel képes dolgozni a kiterjesztett tulajdonságokkal. Emiatt a hozzáférés-vezérlési listák használatához az UFS2 sokkal inkább ajánlott, mint az UFS1. Az ACL használatát a csatlakoztatáskor megadott beállítással engedélyezhetjük, amelyet érdemes felvennünk az /etc/fstab állományba. Ha a &man.tunefs.8; segédprogrammal az állományrendszer fejlécében levõ szuperblokk ACL kapcsolóját átírjuk, akkor ez a beállítás automatikussá tehetõ. A szuperblokk használata több okból is ajánlatos: A csatlakoztatáskor megadott ACL beállítás nem változtatható egy egyszerû újracsatlakoztatással (&man.mount.8; ), csak egy teljes leválasztással (&man.umount.8;) és egy friss csatlakoztatással (&man.mount.8;). Ennek értelmében az ACL-ek a rendszerindító állományrendszeren a rendszer indulása után nem engedélyezhetõek. Ám ez azt is jelenti, hogy egy már használatban levõ állományrendszer beállításai sem változtathatóak meg. Ha a kapcsolót a szuperblokkban állítjuk be, akkor az állományrendszert még akkor is ACL támogatással csatlakoztatja a rendszer, ha azt nem adtuk meg az fstab állományban vagy az eszközeink átrendezõdtek. Így az állományrendszereket még véletlenül sem tudjuk ACL használata nélkül csatlakoztatni, ami egyébként így komoly biztonsági problémákat okozhatna. Beállíthatjuk úgy is ACL kezelését, hogy egy friss csatlakoztatás nélkül is bekapcsolható legyen, azonban az ilyen állományrendszerek ACL nélküli csatlakoztatását nem ajánljuk senkinek, mivel ha egyszer már engedélyeztük a használatukat, majd kikapcsoljuk ezeket és végül a kiterjesztett tulajdonságok törlése nélkül újra engedélyezzük, akkor nagyon könnyen pórul járhatunk. Ha elkezdtük használni az ACL-eket egy állományrendszeren, akkor ne tiltsuk le ezeket, mert az így keletkezõ állományvédelem nem feltétlenül lesz kompatibilis a felhasználók által beállítottakkal, és az ACL újraengedélyezése a változásaik elõtti korábbi ACL engedélyeket fogja visszaállítani az állományokra, aminek hatása kiszámíthatatlan. A hozzáférés-vezérlési listákat használó állományrendszerek esetén egy + (plusz) jellel ábrázolják a kiterjesztett engedélyeket. Például: drwx------ 2 robert robert 512 Dec 27 11:54 private drwxrwx---+ 2 robert robert 512 Dec 23 10:57 könyvtár1 drwxrwx---+ 2 robert robert 512 Dec 22 10:20 könyvtár2 drwxrwx---+ 2 robert robert 512 Dec 27 11:57 könyvtár3 drwxr-xr-x 2 robert robert 512 Nov 10 11:54 public_html Láthatjuk, hogy a könyvtár1, könyvtár2 és könyvtár3 könyvtárakhoz tartoznak ACL típusú engedélyek, míg a public_html könyvtárhoz nem. Az <acronym>ACL</acronym>-ek használata Az állományrendszerben található ACL engedélyeket a &man.getfacl.1; segédprogrammal nézhetjük meg. Például a próba állomány ACL engedélyeit a következõ paranccsal tudjuk megnézni: &prompt.user; getfacl próba #file:próba #owner:1001 #group:1001 user::rw- group::r-- other::r-- Egy állomány ACL engedélyeit a &man.setfacl.1; segédprogrammal tudjuk megváltoztatni. Figyeljük meg: &prompt.user; setfacl -k próba A opció törli az összes ACL alapú engedélyt egy állományról vagy állományrendszerrõl. Ennél viszont sokkal hasznosabb a opció használata, mivel az meghagyja az ACL mûködéséhez szükséges alapvetõ mezõket. &prompt.user; setfacl -m u:trhodes:rwx,group:web:r--,o::--- próba Ebben a fenti parancsban a opciót pedig arra használtuk, hogy módosítsuk az alapértelmezett ACL bejegyzéseket. Mivel az ezt megelõzõ parancsban teljesen töröltük még az elõredefiniált bejegyzéseket is, ez a parancs a megadott paraméterekkel kiegészítve ezeket vissza fogja állítani. Ügyeljünk arra, hogy ha olyan felhasználót vagy csoportot adunk meg, ami nem létezik a rendszerben, akkor a szabvány kimenetre egy Invalid argument hibaüzenetet kapunk. Tom Rhodes Írta: Portaudit A külsõ programok biztonsági problémáinak figyelése Az utóbbi években a biztonsági kérdésekkel foglalkozó világban számos fejlesztésre került sor a sebezhetõségi figyelmeztetések feldolgozásában. Manapság tulajdonképpen bármilyen operációs rendszer fokozott veszélynek teszik ki magát a külsõ programok telepítésével és használatával. A sebezhetõségekrõl beszámoló értesítések a biztonság egyik alapköve, azonban a &os; projekt nem tud ilyen jelentéseket kiadni a &os; alaprendszerén kívül minden egyes külsõ alkalmazáshoz. Azonban lehetõségünk van enyhíteni a külsõ csomagok sebezhetõségén és figyelmeztetni a rendszergazdákat az ismert biztonsági problémákra. A &os;-nek van egy Portaudit nevû segédprogramja, amit kizárólag erre a célra hoztak létre. - A ports-mgmt/portaudit port + A ports-mgmt/portaudit port egy adatbázist használ, ahol a &os; biztonsági csapata és a portok fejlesztõi tartják karban az ismert biztonsági problémákat. A Portaudit használatának megkezdéséhez telepítsük a Portgyûjteménybõl: &prompt.root; cd /usr/ports/ports-mgmt/portaudit && make install clean A telepítési folyamat során a &man.periodic.8; konfigurációs állományai is frissítõdnek, így a Portaudit is lefut a napi biztonsági ellenõrzések folyamán. Gondoskodjunk róla, hogy a root felhasználónak levélben elküldött a napi biztonsági értesítéseket rendesen elolvassuk. Nincs szükségünk további beállításokra. A telepítés után a rendszergazda a következõ paranccsal tudja frissíteni a saját adatbázispéldányát és megnézni a pillanatnyilag telepített csomagok ismert sebezhetõségeit: &prompt.root; portaudit -Fda Ez az adatbázis a &man.periodic.8; minden egy futásakor magától frissül, ezért ez a parancs lényegében elhagyható. Egyedül a soronkövetkezõ példákhoz kell kiadni. A Portgyûjteménybõl telepített külsõ alkalmazások megbízhatóságának ellenõrzését az alábbi parancs kiadásával bármikor elvégezhetjük: &prompt.root; portaudit -a A Portaudit ennek hatására valahogy így fogja megjeleníteni a sebezhetõ csomagokat: Affected package: cups-base-1.1.22.0_1 Type of problem: cups-base -- HPGL buffer overflow vulnerability. Reference: <http://www.FreeBSD.org/ports/portaudit/40a3bca2-6809-11d9-a9e7-0001020eed82.html> 1 problem(s) in your installed packages found. You are advised to update or deinstall the affected package(s) immediately. Fordítása: Érintett csomag: cups-base-1.1.22.0_1 A probléma jellege: cups-base -- HPGL puffer túlcsordulási sebezhetõség. Link: <http://www.FreeBSD.org/ports/portaudit/40a3bca2-6809-11d9-a9e7-0001020eed82.html> A telepített csomagokkal kapcsolatban 1 problemát találtam. Javasoljuk, hogy az érintett csomagokat azonnal frissítse vagy távolítsa el. Ha a böngészõnket az itt megadott címre irányítjuk, akkor megismerhetjük a kérdéses sebezhetõség pontosabb részleteit. Ezen az oldalon megtalálhatjuk a hiba által érintett verziókat a &os; portok verziója szerint, illetve más olyan honlapokat, ahol biztonsági figyelmeztetéseket találhatunk. Röviden összefoglalva, a Portaudit egy komoly segédeszköz és hitetlenül hasznos kiegészítõje a Portupgrade portnak. Tom Rhodes Írta: a FreeBSD biztonsági figyelmeztetései A &os; biztonsági figyelmeztetései A &os; több más kereskedelmi minõségû operációs rendszerhez hasonlóan Biztonsági figyelmeztéseket (Security Advisory) ad ki. Ezek a figyelmeztetések általában megjelennek a biztonsággal foglalkozó levelezési listákon és a hivatkozott hibák kijavítása után a megfelelõ kiadások hibajegyzékében is. Ebben a szakaszban megismerjük és értelmezzük ezeket a figyelmeztetéseket, valamint megtudhatjuk, milyen lépéseket kell megtennünk a rendszerünk kijavításához. Hogyan épül fel egy figyelmeztetés? A &os; biztonsági figyelmeztetései az alább látható formában jelennek meg, amit mi most a &a.security-notifications.name; levelezési listáról kölcsönöztünk. ============================================================================= &os;-SA-XX:XX.UTIL Security Advisory The &os; Project Topic: denial of service due to some problem Category: core Module: sys Announced: 2003-09-23 Credits: Person@EMAIL-ADDRESS Affects: All releases of &os; &os; 4-STABLE prior to the correction date Corrected: 2003-09-23 16:42:59 UTC (RELENG_4, 4.9-PRERELEASE) 2003-09-23 20:08:42 UTC (RELENG_5_1, 5.1-RELEASE-p6) 2003-09-23 20:07:06 UTC (RELENG_5_0, 5.0-RELEASE-p15) 2003-09-23 16:44:58 UTC (RELENG_4_8, 4.8-RELEASE-p8) 2003-09-23 16:47:34 UTC (RELENG_4_7, 4.7-RELEASE-p18) 2003-09-23 16:49:46 UTC (RELENG_4_6, 4.6-RELEASE-p21) 2003-09-23 16:51:24 UTC (RELENG_4_5, 4.5-RELEASE-p33) 2003-09-23 16:52:45 UTC (RELENG_4_4, 4.4-RELEASE-p43) 2003-09-23 16:54:39 UTC (RELENG_4_3, 4.3-RELEASE-p39) CVE Name: CVE-XXXX-XXXX For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit http://www.FreeBSD.org/security/. I. Background II. Problem Description III. Impact IV. Workaround V. Solution VI. Correction details VII. References A Topic mezõben olvashatjuk pontosan mi is maga a probléma. Alapvetõen bemutatja az érintett biztonsági figyelmeztetést és megemlíti a sebezhetõ segédprogramot. A Category mezõ hivatkozik a rendszer azon részére, amelyre a hiba kihatással lehet. Értéke lehet core, contrib vagy ports. A core kategória azt jelzi, hogy a sebezhetõség a &os; legfontosabb komponenseit érinti. A contrib kategória a &os; projekt számára felajánlott szoftverek, mint például a sendmail sebezhetõségére utal. Végezetül a ports kategória jelzi, hogy a sebezhetõség valamelyik, a Portgyûjteményben szereplõ szoftverre érvényes. A Module mezõ a sebezhetõ komponens helyét nevezi meg, például sys. Ebben a példában azt láthatjuk, hogy a sys modul a hibás. Ezért a sebezhetõség egy rendszermagban használt komponenst érint. Az Announced mezõ a biztonsági figyelmeztetés kiadásának vagy széleskörû kihirdetésének dátumát rögzíti. Ez azt jelenti, hogy a biztonsági csapat meggyõzõdött a probléma létezésérõl és a hibát orvosoló javítás már felkerült a &os; forráskódjába. A Credits mezõ azokat az egyéneket vagy szervezeteket említi meg, akik észlelték a sebezhetõséget és jelentették. Az Affects mezõben megadják, hogy a &os; melyik kiadásaira van hatással a sebezhetõség. Ha a rendszermag esetén lefuttatjuk az ident parancsot az érintett állományokra, akkor megtudhatjuk a pontos revíziójukat. A portoknál a verziószám a port neve után szerepel a /var/db/pkg könyvtárban. Ha a rendszerünket nem frissítettük CVS-rõl és fordítottuk újra, akkor nagy a valószínûsége, hogy a sebezhetõség minket is érint. A Corrected mezõ tartalmazza a a kijavítás dátumát, idejét, idõzónáját és az ezt tartalmazó kiadást. Az ismert sebezhetõségek adatbázisában (Common Vulnerabilities Database, CVD) használt azonosítási információk alapján végzett keresések számára fenntartott. A Background mezõ adja meg részleteiben a sebezhetõ programmal kapcsolatos tudnivalókat. Az esetek többségében itt írják le, hogy miért jött létre az adott eszköz a &os;-ben, mire használják és hogyan keletkezett. A Problem Description mezõ a biztonsági rést részletezi. Ebben a részben szerepelhet a hibás kódrészlet vagy akár még az is, hogy miként kell vele elõidézni a hibát. Az Impact mezõ a probléma lehetséges hatásait írja körül a rendszerben. Ez például lehet egy DoS támadás, speciális engedélyek ellopása vagy akár a rendszeradminisztrátori jogok megszerzése. A Workaround mezõ igyekszik elfogadható megoldást nyújtani a rendszerük frissítésére képtelen rendszergazdák számára. Ennek oka lehet az idõ rövidsége, a hálózati elérhetõség vagy más okokból fakadó elcsúszás. Ennek ellenére a biztonsági kérdéseket sosem szabad félvállról venni, ezért a sebezhetõ rendszereket vagy ki kell javítani vagy valamilyen módon meg kell kerülni a biztonsági rés kialakulását. A Solution mezõ utasításokkal segít a rendszer kijavítását. Ez egy lépésrõl lépésre tesztelt és ellenõrzött módszer, amellyel a rendszerünket megfelelõen ki tudjuk javítani és biztonságossá tenni. A Correction Details mezõ mutatja a CVS-ág vagy kiadás nevét, amelyben a pontokat aláhúzásra cserélték. Ezenkívül még az egyes ágakban az érintett állományok revízióját is mutatja. A References mezõ általában a témával kapcsolatos további forrásokat kínálja fel URL, könyv, levelezési lista vagy hírcsoport formájában. Tom Rhodes Írta: a futó programok nyilvántartása A futó programok nyilvántartása A futó programok nyilvántartása olyan biztonsági módszer, ahol a rendszergazda figyelemmel kíséri a rendszer használatban levõ erõforrásait, a felhasználók közti megoszlását, gondoskodik a rendszer felügyeletérõl és valamennyire nyomon követi a felhasználók parancsait. Ennek a módszernek egyaránt megvannak a maga elõnyei és hátrányai. Az egyik elõnye, hogy a használatával a behatolás egészen a betörés pontjáig visszakövethetõ. Hátranya viszont, hogy a futó programok nyilvántartása rengeteg mennyiségû naplót generál és ehhez sok lemezterületre lesz szükségünk. Ebben a szakaszban végigjárjuk a programok nyilvántartásának alapjait. A futó programok nyilvántartásának engedélyezése és használata A futó programok nyilvántartását elõször engedélyeznünk kell. Ehhez a következõ parancsokat kell kiadnunk: &prompt.root; touch /var/account/acct &prompt.root; accton /var/account/acct &prompt.root; echo 'accounting_enable="YES"' >> /etc/rc.conf Miután aktiváltuk, a nyilvántartást elkezdi számbavenni a processzor kihasználtságát, a parancsokat stb. A nyilvántartás emberek számára nem olvasható formátumban készül, ezért csak az &man.sa.8; segédprogrammal tudjuk megnézni. Ha nem adunk meg neki semmilyen opciót, akkor az sa kilistázza a felhasználónkénti hívásokat, az összes eltelt idõt percben, a teljes processzor- és felhasználói idõt percben, az I/O mûveletek átlagos számát stb. A kiadott parancsokról a &man.lastcomm.1; programmal tudunk tájékozódni. A lastcomm segítségével ki tudjuk íratni a felhasználók adott terminálon kiadott parancsait is, mint például: &prompt.root; lastcomm ls trhodes ttyp1 Ezzel megjelenik a trhodes nevû felhasználó ttyp1 terminálon kiadott összes ismert ls parancsa. Számos hasznos beállítást és hozzájuk tartozó leírást találhatunk még a &man.lastcomm.1;, &man.acct.5; és &man.sa.8; man oldalakon. diff --git a/hu_HU.ISO8859-2/books/handbook/serialcomms/chapter.sgml b/hu_HU.ISO8859-2/books/handbook/serialcomms/chapter.sgml index f74d5f1a6a..b4fe085cc6 100644 --- a/hu_HU.ISO8859-2/books/handbook/serialcomms/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/serialcomms/chapter.sgml @@ -1,3963 +1,3963 @@ Soros vonali kommunikáció Áttekintés soros kommunikáció A &unix; mindig is támogatta a soros vonali kommunikációt. Tulajdonképpen az elsõ &unix;-os gépek is soros vonalon kapták a felhasználóktól a bemenetet és ugyanígy küldték vissza a kimenetet. Az idõk azóta már sokat változtak, hogy egy átlagos terminál mindössze egy 10 karakter per másodperc sebességû soros nyomtatóból és egy billentyûzetbõl állt. Ebben a fejezetben ismertetünk néhány olyan megoldást, amellyel a &os; képes soros vonalon keresztül kommunikálni. A fejezet elolvasása során megismerjük: hogyan kapcsoljunk terminálokat a &os; rendszerünkre; hogyan tárcsázzunk modem segítségével távoli számítógépeket; hogyan tegyük lehetõvé gépünkre a bejelentkezést távoli felhasználók számára; hogyan indítsuk a rendszerünket soros konzolról. A fejezet elolvasásához ajánlott: egy új rendszermag beállításának és telepítésének ismerete (); a &unix;-os engedélyek és a &unix; alatt futtatott programok mûködtetésének megértése (); annak a soros vonali hardvernek (modemnek vagy többportos kártyának a) kézikönyve, amelyet a &os;-vel használni szeretnénk Bevezetés Alapfogalmak bit per másodperc bps Bit per másodperc — az adatátvitel sebessége DTE DTE Adatterminál eszköz (Data Terminal Equipment) — ez például a számítógépünk DCE DCE Adatkommunikációs eszköz (Data Communications Equipment) — ez a modem RS-232 RS-232C kábel a hardveres soros vonali kommunikációhoz szükséges EIA szabványú kábel Amikor ebben a fejezetben az adatátvitel sebességérõl beszélünk, akkor szándékosan nem használjuk a baud fogalmát. A baud ugyanis a kommunikációs eszközben adott idõ alatt lezajló jelváltások mennyiségét jelöli, miközben itt a bps (bit per másodperc) kifejezés használata a helyes (vagy legalább is a szõrszálhasogatók egyelõre megnyugodhatnak). Kábelek és portok Ha a &os; rendszerünkhöz egy modemet vagy egy terminált akarunk csatlakoztatni, akkor ahhoz a számítógépünkben szükség lesz egy szabad soros portra és egy megfelelõ típusú kábelre. Ha már tisztában vagyunk a rendelkezésre álló hardverrel és a hozzátartozó kábellel, akkor nyugodtan átléphetjük ezt a részt. A kábelek fajtái A soros kábeleknek több különbözõ típusa van. Közülük a céljainknak leginkább megfelelõ két legismertebb változatuk az ún. null-modem és a szabványos (egyenes) RS-232-es soros kábelek. A hardverhez tartozó dokumentációban megtaláljuk, hogy pontosan melyik típus tartozik hozzá. A null-modem kábelek null-modem kábel Egy null-modem kábel bizonyos jeleket, többek közt a földet (Signal Ground, SG), egyenesen küldi, másokat viszont felcserélten. Például az átküldött adat (Transmitted Data, TD) jelzésû tû a kábel másik végén a fogadott adat (Received Data, RD) tûhöz fut be. A terminálokhoz akár saját magunk is le tudunk gyártani egy null-modem kábelt (például ha a boltiakkal nem lennénk megelégedve). A következõ táblázatban az RS-232C jeleit és érintkezõinek számozását láthatjuk egy DB-25-ös csatlakozó esetében. A szabvány a kábel két 1-es tûjét összekapcsoló vonalat védõföldnek (Protective Ground, PD) nevezi, de ezt gyakran el is hagyják. Némely terminál remekül mûködik mindössze a 2-es, 3-as és 7-es tûk használatával, miközben mások az iménti példától eltérõ kiosztást igényelnek. A DB-25 DB-25 közti null-modem kábel Jel Tû Tû Jel SG 7 párja: 7 SG TD 2 párja: 3 RD RD 3 párja: 2 TD RTS 4 párja: 5 CTS CTS 5 párja: 4 RTS DTR 20 párja: 6 DSR DTR 20 párja: 8 DCD DSR 6 párja: 20 DTR DCD 8 párja: 20 DTR
Íme a mostanság elterjedt másik két séma. A DB-9 DB-9 közti null-modem kábel Jel Tû Tû Jel RD 2 párja: 3 TD TD 3 párja: 2 RD DTR 4 párja: 6 DSR DTR 4 párja: 1 DCD SG 5 párja: 5 SG DSR 6 párja: 4 DTR DCD 1 párja: 4 DTR RTS 7 párja: 8 CTS CTS 8 párja: 7 RTS
DB-9 DB-25 közti null-modem kábel Jel Tû Tû Jel RD 2 párja: 2 TD TD 3 párja: 3 RD DTR 4 párja: 6 DSR DTR 4 párja: 8 DCD SG 5 párja: 7 SG DSR 6 párja: 20 DTR DCD 1 párja: 20 DTR RTS 7 párja: 5 CTS CTS 8 párja: 4 RTS
Amikor egy tû az átellenes oldalon két másik tûhöz csatlakozik, akkor azt általában úgy valósítják meg, hogy a két tût a saját oldalukon összekötik, majd ezt kapcsolják hozzá a harmadik tûhöz. Ezek a megoldások a legnépszerûbbek. Természetesen a tûk összekötésének több más variációja is létezik (ezekrõl az RS-232 Made Easy c. könyvben olvashatunk bõvebben), ahol az SG párja az SG, a TD párja az RD, az RTS és a CTS párja az DCD, a DTR párja a DSR és ugyanezek fordítva. Szabványos RS-232C kábelek RS-232C kábel A szabványos soros kábel az összes RS-232C jelet közvetlenül átküldi. Vagyis a kábel egyik végén levõ átküldött adat tû a másik végén is az átküldött adat tûhöz csatlakozik. Az ilyen típusú kábeleket többnyire a számítógépek és a modemek között alkalmazzák, de egyes termináltípusok esetében is szükségünk lehet rá. A portok A soros port olyan eszköz, amelyen keresztül a &os;-s gép és a terminál között adatokat tudunk közvetíteni. Ebben a szakaszban az ilyen portok különféle típusait és ezek használatát ismertetjük &os; alatt. A portok típusai A soros portoknak több típusa létezik. Mielõtt vásárolnánk egy készítenénk egy soros kábelt, mindenképpen gyõzödjünk meg róla, hogy csatlakoztatni tudjuk majd a &os;-s rendszerünkhöz és a terminálhoz egyaránt. A legtöbb terminálon DB-25-ös portot találunk. A személyi számítógépek, köztük azok, amelyeken &os; fut, DB-25-ös és DB-9es portokkal rendelkeznek. Ha a gépünkben egy többportos soros kártya van, akkor ezeken kívül még RJ-12-es és RJ-45-ös portjaink is lehetnek. A hardverhez tartozó dokumentációból tudjuk kideríteni az adott port konkrét fajtáját, de gyakran a port vizuális vizsgálata is segíthet eldönteni a kérdést. A portok nevei &os; alatt az egyes soros portokat a /dev könyvtárban található eszközleírókon keresztül tudjuk elérni. Ezeknek két típusa van: A behíváshoz használt portok nevei /dev/ttydN alakúak, ahol az N a port sorszáma, ami nullától indul. A behívó portok alapvetõen a terminál esetében használatosak. A behívó portok használatához a soros vonalon az vonal észlelése (Data Carrier Detect, DCD) jelnek kell megbízhatóan mûködnie. A híváshoz használt portok nevei /dev/cuadN alakúak. A hívó portokat terminálok esetében ritkán alkalmazzák, helyettük inkább csak modemekhez használják. A hívó portokat akkor érdemes használni, ha a soros kábel vagy a terminál nem ismeri a DCD jelet. Ha a terminált az elsõ soros portra (ami &ms-dos;-ban a COM1) csatlakoztattuk, akkor a /dev/ttyd0 segítségével fogunk rá hivatkozni. Ha viszont a második soros porton (más néven COM2) található, akkor a /dev/ttyd1 eszközt használjuk, és így tovább. A rendszermag beállítása A &os; alapból négy soros portot támogat. Az &ms-dos; világban ezeket rendre COM1, COM2, COM3 és COM4 portoknak nevezik. A &os; jelen pillanatban ismeri még a butább többportos soros csatolókártyákat is, például a BocaBoard 1008 és 2016 típusokat, valamint több intelligensebb többportos kártyát, például a Digiboard és a Stallion Technologies gyártmányait. Az alap rendszermag azonban csak a szabványos COM portokat keresi. Ha ellenõrizni akarjuk, hogy a rendszermag rendben megtalálta a soros portokat, akkor figyelmesen olvassuk el a rendszerindítás során megjelenõ üzeneteket, vagy az /sbin/dmesg parancs kiadásával kérdezzük vissza a rendszermag üzeneteit. Különösen a sio kezdetû sorokra kell figyelnünk. Az alábbi paranccsal tudjuk leszûrni a sio szövegrészt tartalmazó sorokat: &prompt.root; /sbin/dmesg | grep 'sio' Például, ha négy soros port található a rendszerünkben, akkor a rájuk vonatkozó rendszerüzenetek a következõk lesznek: sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A sio2 at 0x3e8-0x3ef irq 5 on isa sio2: type 16550A sio3 at 0x2e8-0x2ef irq 9 on isa sio3: type 16550A Ha a rendszermagunk nem ismerte volna fel az összes soros portot, akkor valószínûleg a /boot/device.hints állományt kell módosítanunk. Tegyük megjegyzésbe vagy akár teljesen távolítsuk is el azokat az eszközöket, amelyekkel nem rendelkezünk. A soros portok és a többportos kártyák beállításával kapcsolatban a &man.sio.4; man oldalát olvassuk el. Óvatosan bánjunk a &os; megelõzõ változataiból származó konfigurációs állományokkal, mert az eszközök vonatkozó beállításokat és azok formátuma megváltozhatott azóta. Az port IO_COM1 a port 0x3f8, az IO_COM2 a 0x2f8, az IO_COM3 a 0x3e8 és az IO_COM4 a 0x2e8 beállítást helyettesíti. Ezek az adott porthoz tartozó gyakori címeket képviselik. A 4-es, 3-as, 5-ös és 9 megszakítások is igen általánosak ezeknél. A hagyományos soros portok viszont az ISA buszos PC-k esetében nem képesek a megszakításokon osztozni. (A többportos kártyák azonban lehetõvé teszik az 16550A számára, hogy mindössze egy vagy két megszakítást használjon.) Speciális eszközállományok A rendszermagban található legtöbb eszköz az ún. speciális eszközállományokon keresztül érhetõ el, melyek a /dev könyvtárban találhatóak. A sio eszközök a /dev/ttydN (behívó portok) és /dev/cuadN (hívó portok) állományok használatával érhetõek el. A &os; ezenkívül még külön eszközállományokat biztosít az inicializációhoz (/dev/cuadN.init) és a zároláshoz (/dev/cuadN.lock). Az inicializációs állományok a port megnyitásakor használhatóak a hozzátartozó paraméterek beállítására, például így tudjuk elküldeni a crtscts utasítást az olyan modemeknek, amelyek a forgalom irányítását RTS/CTS jelzéseken keresztül valósítják meg. A zároló állományokkal a portokra vonatkozó zárolásokat állíthatjuk be, így a felhasználók vagy a programok nem lesznek képesek bizonyos paramétereket megváltoztatni. A &man.termios.4;, &man.sio.4; és &man.stty.1; man oldalakon olvashatunk részletesebben a terminálok beállításairól, valamint az eszközök zárolásáról és inicializálásáról. A soros port beállítása ttyd cuad A ttydN (vagy cuadN) lesz az az eszköz, amit majd az alkalmazásainkból el akarunk érni. Amikor egy futó program megnyit egy ilyen eszközt, mindig tartoznak hozzá alapértelmezett terminál I/O beállítások. Ezeket a következõ paranccsal tudjuk lekérdezni: &prompt.root; stty -a -f /dev/ttyd1 Ha megváltoztatjuk az eszköz beállításait, akkor azok egészen addig érvényben is maradnak, amíg le nem zárjuk. Ha tehát ezután újra megnyitjuk, akkor minden visszaáll az alapértelmezett állapotra. Az alapértelmezett beállítások megváltoztatásához a kezdeti állapotot szimbolizáló eszközt kell megnyitnunk és átállítanunk. Például, ha alapból engedélyezni akarjuk a módot, a 8 bites kommunikációt és a típusú forgalomirányítást a ttyd5 eszközön, akkor a következõt gépeljük be: &prompt.root; stty -f /dev/ttyd5.init clocal cs8 ixon ixoff rc állományok rc.serial A soros eszközök rendszerszintû inicializálását az /etc/rc.d/serial állomány vezérli. Lényegében ez határozza meg az összes soros eszköz alapértelmezett beállítását. Ha bizonyos beállítások megváltoztatását tiltani szeretnénk az alkalmazások felé, akkor azt a zárolt állapotot tartalmazó eszközben kell rögzítenünk. Például, ha a ttyd5 eszköz sebességét fixen 57600 bps-ra akarjuk beállítani, akkor írjuk be ezt: &prompt.root; stty -f /dev/ttyd5.lock 57600 Ezután ha egy alkalmazás megnyitja a ttyd5 eszközt és megpróbálja a port sebességét átállítani, akkor az továbbra is 57600 bps marad. A kezdeti és a zárolt állapotot képezõ eszközöket általában csak a root felhasználó számára szabad írhatóvá tenni. Sean Kelly Készítette: Terminálok terminálok A terminálok olyankor kínálnak kényelmes és költséghatékony hozzáférést a &os; rendszerünkhöz, amikor sem a gép konzolját, sem pedig a hozzátartozó hálózatot nem érjük el. Ebben a szakaszban olvashatjuk, miként kell terminálokat használni &os; alatt. A terminálok alkalmazásai és típusai Az eredeti &unix; rendszereknek nem voltak konzoljaik. Ehelyett az emberek a soros portokra csatlakoztatott terminálokon keresztül jelentkeztek be és így futtattak rajtuk programokat. Ez nagyon hasonlít ahhoz, mint amikor egy modem és egy terminálprogram felhasználásával betárcsázunk egy távoli gépre és vele szöveges módban dolgozunk. Napjaink személyi számítógépein azonban találhatunk már akár nagy felbontású megjelenítéssel megáldott konzolokat is, habár a soros porton keresztüli bejelentkezés lehetõsége még mind a mai napig elérhetõ a legtöbb &unix;-alapú rendszerben. Ez alól a &os; sem kivétel. Ha rákötünk egy terminált a gépünk egyik üres soros portjára, akkor a megszokott módon képesek vagyunk bejelentkezni a rendszerbe és futtatni bármilyen szöveges programot, hasonlóan ahhoz, ahogy azt a konzolban vagy az X Window Systemben egy xterm ablakban megtehetjük. Ha egy irodában vagyunk, akkor egy &os; rendszerre több terminált is kapcsolhatunk, melyek az alkalmazottak asztalain foglalnak helyet. Otthoni használat esetén egy kiöregedett számítógép, például egy régi IBM PC vagy egy &macintosh; is ráköthetõ egy gyorsabb &os; rendszerre. Ennek segítségével az egyébként egyfelhasználós számítógépünket egy valódi többfelhasználós rendszerré alakíthatjuk. A &os; esetén háromféle terminálról beszélhetünk: A buta (dumb) terminálok A terminálként funkcionáló személyi számítógépek Az X terminálok A most következõ alszakaszokban ezeket fejtjük ki részletesebben. A buta terminálok A buta terminál alatt olyan speciálizált eszközt értünk, amellyel soros vonalon keresztül csatlakozunk számítógépekhez. Azért nevezik ezeket butának, mert csupán annyi számítási teljesítményt zsúfoltak beléjük, hogy szöveget legyenek képesek küldeni, fogadni és megjeleníteni. Semmilyen program nem képes rajtuk futni. Helyette az a számítógép fogja a szövegszerkesztõt, fordítóprogramot, levelezõ klienst, játékot és a többit futtatni, amelyre vele kapcsolódtunk. A buta termináloknak többszáz, különbözõ gyártmányú fajtája létezik. Ilyenek például a Digital Equipment VT-100 vagy a Wyse WY-75 típusú termináljai. A &os; szinte mindegyiküket ismeri. Egyes drágább terminálok még grafikus megjelenítésre is képesek, de ezeket a lehetõségeket csak bizonyos szoftverek tudják ténylegesen kihasználni. A buta terminálok leginkább olyan munkahelyeken terjedtek el, ahol az alkalmazottaknak nincs szükségük grafikus alkalmazások, tehát például az X Window System használatára. Személyi számítógépek mint terminálok Ha egy buta terminál csupán szöveg küldésére, fogadására és megjelenítésére képes, akkor bármelyik személyi számítógép utána tudja mindezt csinálni. Ehhez mindössze egy megfelelõ kábelre és az adott gépen futó terminál emulációs szoftverre van szükségünk. Az ilyen fajta megoldás nagyon elterjedt az otthoni használat esetén. Például, ha valamelyik családtagunk éppen szorgalmasan dolgozik a &os; rendszerkonzolján, akkor a rákapcsolt terminálon keresztül még mi magunk is el tudunk végezni valamennyi szöveges felületet igénylõ munkát. Az alap &os; rendszerben legalább két segédprogram használható a soros vonali kapcsolaton keresztüli munkára: a &man.cu.1; és a &man.tip.1;. Egy &os; rendszerû kliensrõl így tudunk csatlakozni egy másik rendszerre: &prompt.root; cu -l soros-vonali-eszköz Ahol a soros-vonali-eszköz a rendszerünkben a soros portot jelölõ speciális eszköz neve. Az ilyen eszközök neve /dev/cuadN. Az eszköz nevében az N-es rész a soros port sorszámát adja meg. A &os;-ben az eszközök sorszámozása nullától kezdõdik, nem pedig egytõl (ellentétben tehát azzal, ahogy azt az &ms-dos; rendszerekben és leszármazottaikban már megszokhattuk). Ez azt jelenti, hogy amit az &ms-dos; alapú rendszerekben COM1-nek hívnak, az a &os;-ben általában a /dev/cuad0. Egyes emberek más, többnyire a Portgyûjteménybõl is elérhetõ programokat szeretnek inkább használni. A portok között találhatunk elég sok olyan szoftvert, amely a &man.cu.1; és a &man.tip.1; programokhoz hasonlóan mûködik. Ilyen például a comms/minicom. Az X terminálok Az X terminálok a terminálok közül a legfejlettebbek. Általában nem is soros porton, hanem hálózaton, például Etherneten keresztül csatlakoznak. Természetesen nem csak szöveges alkalmazásokat, hanem lényegében bármilyen X alkalmazást képesek megjeleníteni. Az X terminálokról itt most csak a teljesség kedvéért szólunk, de ebben a fejezetben nem szándékozunk tárgyalni az X terminálok csatlakoztatását, beállítását és használatát. Beállítás Ebben a fejezetben ismertetjük mindazt, ami ahhoz kell, hogy a &os; rendszerünkön engedélyezni tudjuk a terminálon keresztüli bejelentkezéseket. Feltételezzük, hogy a rendszermagunk támogatja a terminálok által használt soros portokat, illetve, hogy ezeket már csatlakoztattuk is. Ha visszagondolunk a re, akkor eszünkbe juthat, hogy a rendszer indításakor az init nevû program felelõs az összes futó program irányításáért és inicializálódásáért. Az init egyik feladata, hogy beolvassa az /etc/ttys állományt és neki megfelelõen az elérhetõ terminálokon elindítsa a getty programot. A getty felelõs a bejelentkezéshez szükséges azonosító beolvasásáért és a login program elindításáért. Ennek megfelelõen tehát, ha a &os; rendszerünkön terminálokat akarunk beállítani, akkor ehhez a következõ lépéseket kell megtennünk root felhasználóként: Az /etc/ttys állományba vegyünk fel egy bejegyzést a soros porthoz tartozó /dev könyvtárbeli eszközhöz, ha még nem szerepelne benne. A porthoz adjuk meg a /usr/libexec/getty programot, majd hozzá az /etc/gettytab állományból válasszuk ki a megfelelõ getty típust. Adjuk meg a terminál alapértelmezett típusát. Állítsuk a portot on (bekapcsolt) állapotúra. Adjuk meg, hogy a port secure (biztonságos) legyen-e. Mondjuk meg az init programnak, hogy olvassa újra az /etc/ttys állományt. A másik lépés kiegészítõ lépéseként az /etc/gettytab állományban mi magunk is létrehozhatunk egy saját getty típust. A fejezetben ehhez ugyan nem adunk segítséget, de ha érdekel minket a téma, akkor ezzel kapcsolatban a &man.gettytab.5; és &man.getty.8; man oldalakat érdemes elolvasni. Egy bejegyzés felvétele az <filename>/etc/ttys</filename> állományba Az /etc/ttys állományban találhatjuk meg az összes portot, ahonnan a &os; rendszerünk engedélyezi a bejelentkezést. Például a ttyv0, az elsõ virtuális konzol is szerepel benne. Ezen a bejegyzésen keresztül tudunk bejelentkezni a konzolra. Ebben az állományban találjuk meg még a többi virtuális konzol, soros port és pszeudoterminál bejegyzéseit is. A rögzített terminálok esetén egyszerûen csak adjuk meg a soros porthoz tartozó /dev könyvtárbeli eszközt a /dev elõtag nélkül (így például a /dev/ttyv0 ttyv0 néven fog megjelenni). Az alap &os; telepítésben egy olyan /etc/ttys állomány található, amely tartalmazza az elsõ négy soros portot, a ttyd0 eszköztõl kezdve a ttyd3 eszközig. Ha tehát ezekre a portokra csatlakoztatnunk egy terminált, akkor már nem kell egy újabb bejegyzést felvennünk hozzájuk. Terminálok felvétele az <filename>/etc/ttys</filename> állományba Tegyük fel, hogy két eszközt szeretnénk a rendszerünkhöz csatlakoztatni: egy Wyse-50-es terminált és egy régi 286-os IBM PC-t, amelyen a Procomm terminálszoftverrel emulálunk egy VT-100-as terminált. A Wyse terminált a második soros portunkra kötjük, míg a 286-ost a hatodik soros portra (például egy többportos soros vonali kártyán). A nekik megfelelõ /etc/ttys állománybeli bejegyzések így fognak kinézni: ttyd1 "/usr/libexec/getty std.38400" wy50 on insecure ttyd5 "/usr/libexec/getty std.19200" vt100 on insecure Az elsõ mezõben általában a terminálhoz tartozó eszközt nevezzük meg, amely a /dev könyvtárban található. A második mezõ a vonalhoz tartozó végrehajtandó parancs, ami általában a &man.getty.8;. A getty mûködésbe helyezi és megnyitja a vonalat, beállítja a sebességét, bekéri a felhasználó nevét, majd elindítja a &man.login.1; programot. A getty program egy (opcionális) paramétert fogad el a parancssorában, ami a getty típusa. Egy ilyen getty típus szabja meg a terminálhoz tartozó vonal jellemzõit, például az adatátviteli sebességet és a paritást. A getty ezeket a jellemzõket az /etc/gettytab állományból olvassa be. A /etc/gettytab egyaránt tartalmaz bejegyzéseket a régi és új típusú terminálokhoz. Az std szöveggel kezdõdõ bejegyzések szinte majdnem minden esetben mûködnek a hardveres terminálokkal. Az ilyen bejegyzések figyelmen kívül hagyják a paritást. 110 és 115 200 bps között minden adatátviteli sebességhez tartozik egy-egy std bejegyzés. Természetesen ebbe az állományba akár a saját bejegyzéseinket is elkészíthetjük. A &man.gettytab.5; man oldal nyújt ehhez átfogó segítséget. Amikor az/etc/ttys állományban megadjuk a getty típusát, akkor ellenõrizzük, hogy a beállításai megfelelnek a terminálénak. A példánknál maradva: a Wyse-50 nem használ paritást és 38 400 bps-en üzemel. A 286-os gép szintén nem dolgozik paritással és 19200 bps-sel kapcsolódik. A harmadik mezõben adjuk meg általában a vonalra csatlakozó terminál típusát. Ez a betárcsázós portok esetében többnyire az unknown vagy a dialup, mivel ezeken keresztül a felhasználók gyakorlatilag szinte bármilyen típusú terminállal vagy szoftverrel be tudnak jelentkezni. A hardveres termináloknál a terminál típusa azonban nem változik, ezért a &man.termcap.5; adatbázisban keressük ki a nekik megfelelõt és adjuk meg ebben a mezõben. A példánkban a Wyse-50 egy valós termináltípust használ, miközben a 286-oson futó Procomm egy VT-100-as típusú terminált emulál. A negyedik mezõ azt mondja meg, hogy a port engedélyezett-e vagy sem. Ha itt a on értéket adjuk meg, akkor az init elindítja a második mezõben szereplõ getty programot. Ha viszont itt az off szerepel, akkor a getty nem fog elindulni, így ezen a porton be sem fogunk tudni jelentkezni. Az utolsó mezõben a port megbízhatóságát kell megjelölnünk. Ha biztonságosnak (secure) állítjuk be a portot, akkor rajta keresztül a root (vagy bármelyik nullás felhasználói azonosítóval rendelkezõ) felhasználó be tud jelentkezni. Amikor viszont nem biztonságos (insecure), akkor elõször egy normál felhasználóval kell bejelentkeznünk, majd a &man.su.1; programmal vagy egy hozzá hasonló megoldással kell rendszeradminisztrátorrá válnunk. Leginkább az insecure beállítást javasoljuk, még hét lakat alatt õrzött terminálok esetében is. Valójában sokkal egyszerûbb bejelentkezni, majd kiadni egy su parancsot, ha netalán rendszeradminisztrátori jogosultságokra lenne szükségünk. A <command>init</command> utasítása az <filename>/etc/ttys</filename> újraolvasására Miután az /etc/ttys állományban elvégeztük a megfelelõ módosításokat, a konfigurációs állomány újraolvasásához küldjünk egy SIGHUP (bontás) jelzést az init programnak. Mint például: &prompt.root; kill -HUP 1 Mivel mindig az init indul el elsõként a rendszerben, ezért a hozzátartozó azonosító az 1 lesz. Ha mindent jól állítottunk be, a kábelek is a helyükön vannak és a terminálokat is bekapcsoltuk, akkor minden terminálhoz elindul egy getty program, és mindegyikõjükön megjelenik a bejelentkezõ képernyõ. A terminálokkal kapcsolatos hibajelenségek Olykor hiába igyekszünk a lehetõ legaprólékosabban ügyelni minden apró részletre, könnyen elõfordulhat, hogy valamiért a terminál mégsem mûködik rendesen. Következzen most egy lista néhány ismert tünetrõl és azok javasolt gyógymódjairól. Nem jelenik meg a bejelentkezõ képernyõ Ellenõrizzük, hogy a terminált rendesen csatlakoztattuk és áram alá helyeztük. Amikor egy személyi számítógépet használunk terminálnak, akkor nézzük meg, hogy a terminál emulációs program a megfelelõ soros porton fut. Vizsgáljuk meg, hogy a kábel mind a két vége pontosan illeszkedik a portokba. Gyõzõdjünk meg róla, hogy valóban a megfelelõ típusú kábelt használjuk. Nézzük meg, hogy a terminál és a &os; is ugyanazon az adatátviteli sebességen és paritási beállítással megy. Ha képernyõvel rendelkezõ terminálunk van, akkor a kontrasztot és fényerõsséget is ellenõrizzük. Ha nyomtatós terminálunk van, akkor vizsgáljuk meg a papír és a tinta állapotát. Gyõzõdjünk meg róla, hogy a getty valóban fut és rendesen kiszolgálja a terminált. Például a ps paranccsal listázzuk ki az összes jelenleg futó programot és keressük meg köztük a getty programot: &prompt.root; ps -axww|grep getty Ekkor látnunk kell a terminálhoz tartozó bejegyzést. Például, ha a getty második soros portot jelképezõ ttyd1 eszközön fut, és az /etc/gettytab állományból az std.38400 nevû bejegyzést használja, akkor ez jelenik meg: 22189 d1 Is+ 0:00.03 /usr/libexec/getty std.38400 ttyd1 Amennyiben semmilyen getty nem fut, akkor ellenõrizzük, hogy valóban engedélyeztük-e a portot az /etc/ttys állományban. A ttys állomány átírása után ne felejtsük el kiadni a kill -HUP 1 parancsot sem. Ha a getty fut, de a terminálon továbbra sem látjuk a bejelentkezõ képernyõt, vagy megjelenik, de nem tudunk gépelni, akkor elõfordulhat, hogy a terminál vagy kábel nem támogatja a hardveres kézfogást (handshaking). Próbáljuk meg az /etc/ttys állományban levõ std.38400 bejegyzést az 3wire.38400 bejegyzésre kicserélni (de utána ne felejtsük el kiadni a kill -HUP 1 parancsot). A 3wire nagyon hasonlít az std bejegyzéshez, de elhagyja a hardveres kézfogást. A 3wire alkalmazásakor viszont a puffer telítõdésének megelõzése érdekében próbálkozzunk az adatátviteli sebesség csökkentésével vagy engedélyezzük a szoftveres forgalomirányítást. Amikor mindenféle szemét jelenik meg a képernyõn Ellenõrizzük, hogy a &os; és a terminál ugyanazt az adatátviteli sebességet és paritási beállítást használja. Nézzük meg a futó getty programokat, és hogy a megfelelõ getty típussal mennek-e. Ha nem, módosítsuk az /etc/ttys állományt és adjuk ki a kill -HUP 1 parancsot. A karakterek duplán jelennek meg, a jelszó begépelésekor látható Állítsuk át a terminált (vagy a terminál emulációs szofvert) half duplex vagy local echo módról full duplex módra. Guy Helmer Készítette: Sean Kelly Kiegészítette: Betárcsázós szolgáltatások betárcsázós szolgáltatás Amikor egy &os; rendszert akarunk betárcsázós szolgáltatásokhoz beállítani, akkor az nagyon hasonlít a terminálok csatlakoztatásához, azzal a eltéréssel, hogy ilyenkor a terminálok helyett modemekkel kell dolgoznunk. Külsõ kontra belsõ modemek A külsõ modemek sokkal kényelmesebbnek tûnnek betárcsázás szempontjából, mivel az ilyenek gyakran a statikus memóriájukban tárolt paraméterek révén tulajdonképpen félig elõre be vannak állítva és sok esetben a fontosabb RS-232 jeleket külön lámpácskákkal mutatják. A villogó lámpák könnyen elkápráztatják a laikusokat, de emellett igen fontosak a modem mûködõképességének megállapításában is. Ezzel szemben a belsõ modemeken nem található statikus memória, ezért a paramétereik csak DIP kapcsolókkal módosíthatóak. Még ha egy belsõ modemem látunk is lámpákat, akkor sem könnyû figyelni rájuk, mert a gépünk burkolata úgyis eltakarja ezeket. Modemek és kábelek modem Ha külsõ modemet használunk, akkor mindenképpen szükségünk lesz hozzá még egy megfelelõ kábelre is. Egy szabványos RS-232-es soros kábel erre tökéletesen megfelel egészen addig, amíg a normál jeleket így kötötték be rajta: A jelek neve Rövidítés Elnevezés RD Received Data (fogadott adat) TD Transmitted Data (küldött adat) DTR Data Terminal Ready (adatterminál kész) DSR Data Set Ready (adatbeállítás kész) DCD Data Carrier Detect (vonal észlése — az RS-232 fogadást érzékelõ vonala) SG Signal Ground (föld) RTS Request to Send (küldés kérése) CTS Clear to Send (küldés engedélyezése)
A &os;-nek 2400 bps felett a forgalom irányításához az RTS és CTS jelekre van szüksége. A CD jellel állapítja meg, hogy a hívás létrejött vagy a bontották a vonalat, és a DTR jel hozza alapállapotba a modemet a munkamenet befejezése után. Egyes kábelekben nem mindegyik jelet vezették át, így ha például gondjaink akadnak a bejelentkezõ képernyõvel amikor a vonalat bontjuk, akkor érdemes átnéznünk a kábelt. A többi &unix;-szerû operációs rendszerhez hasonlóan a &os; is hardveres jelek segítségével igyekszik kideríteni, hogy a hívás megvalósult vagy bontották a vonalat, valamint a hívás befejezése után így bontja a vonalat és állítja vissza a modemet. A &os; igyekszik elkerülni a parancsok küldését a modem felé, vagy a modem állapotának folyamatos ellenõrzését. Ha már van némi tapasztalatunk a PC-alapú BBS-ek modemes elérését illetõen, akkor valószínûleg értjük ezek okait. A soros vonali felülettel kapcsolatos megfontolások A &os; ismeri az NS8250-, NS16450-, NS16550- és NS16550A alapú EIA RS-232C (CCITT V.24) szabványú kommunikációs felületeket. A 8250-es és a 16450-es eszközök egykarakteres pufferrel rendelkeznek. A 16550-es eszközök 16 karakteres puffert tartalmaznak, amellyel jobb teljesítmény érhetõ el. (A sima 16550-esben levõ hibák miatt azonban ez a 16 karakteres puffer nem használható ki rendesen, ezért lehetõleg a 16550A verziót használjuk). Mivel az operációs rendszer részérõl az egykarakteres eszközök jóval több törõdést igényelnek, mint a 16 karakteres eszközök, ezért inkább a 16550A alapú soros felületi kártyákat ajánljuk. Amikor a rendszer egyszerre több soros portot is kezel, vagy erõs terhelés alatt áll, akkor a 16550A alapú kártyákról általában az is elmondható, hogy kisebb hibával dolgoznak. Egy gyors áttekintés getty Ahogy arról már a terminálok esetében szó esett, az init az összes betárcsázós kapcsolathoz tartozó soros porthoz elindít egy getty programot. Például, ha a modemet a /dev/ttyd0 eszközre kapcsoltuk, akkor a ps ax parancs kimenetében ezt láthatjuk: 4850 ?? I 0:00.09 /usr/libexec/getty V19200 ttyd0 Amikor egy felhasználó felhívja a modemet és az kapcsolódik, akkor a modem egy CD (Carrier Detect) jelet küld. A rendszermag ekkor tudomásul veszi a vonal észlelését és a getty segítségével megindítja a kommunikációt. A getty egy login: szöveget küld át a vonalhoz megadott sebességgel. A getty elkezdi figyelni, hogy a értelmes karakterek érkeznek-e vissza, és egy átlagos konfigurációban, ha ezt szemétnek találja (mert például a modem nem a getty számára beállított sebességgel csatlakozott), akkor megpróbálja egészen addig hangolni a vonal sebességét, amíg feldolgozásra alkalmas karaktereket nem kap. /usr/bin/login Miután a felhasználó megadta a felhasználói nevét, a getty elindítja a /usr/bin/login programot, amely befejezi a beléptetést a felhasználó jelszavának bekérésével és annak elfogadása esetén a hozzátartozó parancsértelmezõ elindításával. A konfigurációs állományok &os; rendszerünkben a betárcsázós kapcsolatok engedélyezéséhez az /etc könyvtárban három állomány módosítására lesz szükségünk. Közülük az elsõ, az /etc/gettytab a /usr/libexec/getty démon beállításait tartalmazza. A második, az /etc/ttys az /sbin/init számára mondja meg, hogy melyik tty eszközökhöz tartozik getty. Végezetül a portok inicializálásához kötõdõ beállításokat az /etc/rc.d/serial szkriptben kell megadnunk. Két iskola jött létre aszerint, hogy &unix; alatt hogyan használják a betárcsázós modemeket. Az egyik csoport úgy szereti beállítani a modemeit és rendszerit, hogy a távoli felhasználó által választott sebességtõl függetlenül a számítógép és a modem közti RS-232 felület egy fix sebességen fut. Ennek a beállításnak megvan az az elõnye, hogy a távoli felhasználó ilyenkor szinte azonnal megkapja a bejelentkezõ képernyõt. A hátránya viszont, hogy ebben az esetben a rendszer nem ismeri a felhasználó valódi adatátviteli sebességét, ezért az olyan teljes képernyõs alkalmazások, mint például az Emacs, nem lesznek képesek a lassabb kapcsolatokhoz szabni a megjelenítésüket. A másik csoport a modemek RS-232-es felületét a távoli felhasználó kapcsolódási sebessége szerint állítja be. Így például egy V.32bis (14,4 Kbps) kapcsolat esetén a modemhez tartozó RS-232 felület 19,2 Kbps-on fog menni, miközben a 2400 bps sebességû kapcsolatokhoz egy vele azonos sebességû RS-232-es felület fog tartozni. Mivel a getty nem képes kommunikálni a modemek által lejelentett csatlakozási sebességen, ezért úgy próbálja azt megállapítani, hogy elküldi a login: szöveget az alap sebességgel, majd figyeli a válaszul érkezõ karaktereket. Ha a felhasználó ilyenkor szemetet lát, akkor feltételezik, hogy addig fogja nyomkodni az Enter billentyût, amíg valami értelmes szöveget meg nem lát. Amikor az adatátviteli sebesség eltér, akkor a getty ebbõl csupán csak annyit vesz észre, hogy a felhasználó szemetet küld, ezért egy újabb sebességgel megpróbálja megint elküldeni a login: szöveget. Hivatalosan ez a folyamat ismétlõdik orrvérzésig, de általában csak egy-két billentyût kell leütni a megfelelõ beállításokhoz. Nyilvánvaló, hogy ilyenkor a bejelentkezés messze nem olyan zavartalan, mint a rögzített sebességû esetben, de így a lassabb kapcsolattal rendelkezõ felhasználók is jobb használatóságot kapnak a teljes képernyõs programokkal. Ebben a szakaszban egy valamennyire kiegyensúlyozott beállítást igyekszünk bemutatni, de részben elfogunk hajlani abban az irányba, amikor a modem a kapcsolat sebességét követi. <filename>/etc/gettytab</filename> /etc/gettytab A /etc/gettytab egy &man.termcap.5;-szerû állomány, amely a &man.getty.8; beállításait tartalmazza. A &man.gettytab.5; man oldalon olvashatunk az állomány pontos felépítésérõl és benne felsorolt beállításokról. A rögzített sebességû beállítás Ha a modem kommunikációs sebességét rögzíteni akarjuk, akkor ehhez többnyire semmit sem kell megváltoztatnunk az /etc/gettytab állományban. Az alkalmazkodó sebességû beállítás Az /etc/gettytab állományban létre kell hoznunk egy olyan bejegyzést, amelyen keresztül a getty tudni fogja, hogy milyen sebességeken akarjuk használni a modemet. Ha egy 2400 bps sebességû modemünk van, akkor hozzá a már meglevõ D2400-as bejegyzést kell használnunk. # # A gyors betárcsázós terminálokhoz íme egy 2400/1200/300-as váltás # (bárhonnan kezdõdhet): # D2400|d2400|Fast-Dial-2400:\ :nx=D1200:tc=2400-baud: 3|D1200|Fast-Dial-1200:\ :nx=D300:tc=1200-baud: 5|D300|Fast-Dial-300:\ :nx=D2400:tc=300-baud: Ha ennél gyorsabb modemünk van, akkor már mindenképpen fel kell vennünk hozzá egy új bejegyzést az /etc/gettytab állományba. Ezzel a beállítással egy 14,4 Kbps sebességû modemet tudunk legfeljebb 19,2 Kbps-en használni: # # Kiegészítések egy V.32bis modemhez: # um|V300|High Speed Modem at 300,8-bit:\ :nx=V19200:tc=std.300: un|V1200|High Speed Modem at 1200,8-bit:\ :nx=V300:tc=std.1200: uo|V2400|High Speed Modem at 2400,8-bit:\ :nx=V1200:tc=std.2400: up|V9600|High Speed Modem at 9600,8-bit:\ :nx=V2400:tc=std.9600: uq|V19200|High Speed Modem at 19200,8-bit:\ :nx=V9600:tc=std.19200: Ennek eredménye egy 8 bites, paritásmentes kapcsolat lesz. A fenti példában a kommunikációt 19,2 Kbps-en (V.32bis kapcsolaton) kezdjük, majd utána haladunk végig a 9600 bps (V.32), 2400 , 1200 bps és 300 bps sebességû kapcsolatokon, majd vissza ismét a 19,2 Kbps-re. Az adatátviteli sebesség ilyen típusú váltogatását az nx= (next table, azaz következõ táblázat) tulajdonság segítségével valósítják meg. Minden sorban látható még egy tc= (table continuation, vagyis a táblázat folytatása) bejegyzés is, amivel az adott adatátviteli sebesség szabványos beállításait adjuk meg. Ha egy 28,8 Kbps sebességû modemünk van és/vagy egy 14,4 Kbps sebességû modemen akarunk tömörítést használni, akkor a 19,2 Kbps-nél nagyobb kommunikációs sebességet kell használnunk. Íme egy olyan gettytab. ami 57,6 Kbps-rõl indít: # # A V.32bis vagy V.34 modemekhez kiegészítés, # 57,6 Kbps-rõl indulunk: # vm|VH300|Very High Speed Modem at 300,8-bit:\ :nx=VH57600:tc=std.300: vn|VH1200|Very High Speed Modem at 1200,8-bit:\ :nx=VH300:tc=std.1200: vo|VH2400|Very High Speed Modem at 2400,8-bit:\ :nx=VH1200:tc=std.2400: vp|VH9600|Very High Speed Modem at 9600,8-bit:\ :nx=VH2400:tc=std.9600: vq|VH57600|Very High Speed Modem at 57600,8-bit:\ :nx=VH9600:tc=std.57600: Ha lassú a processzorunk, vagy a rendszerünk túlságosan terhelt és nincs 16550A típusú soros portunk, akkor 57,6 Kbps-en sio silo hibák keletkezhetnek. <filename>/etc/ttys</filename> /etc/ttys Az /etc/ttys állomány beállításáról már a adott képet. Ez a modemek esetében sem tér el különösebben, habár a getty programnak más termináltípust és -beállításokat kell átadnunk. Akár rögzített, akár alkalmazkodó sebességet akarunk beállítani, ennek általános alakja az alábbi: ttyd0 "/usr/libexec/getty xxx" dialup on A sorban látható elsõ elem a megfelelõ speciális eszköz neve — jelen esetben ez a ttyd0, amely a /dev/ttyd0 eszközre vonatkozik és ezt fogja a getty figyelni. A második elem, vagyis a "/usr/libexec/getty xxx" (ahol a xxx helyére kell beírni a megfelelõ gettytab állománybeli bejegyzést nevét) lesz az a parancs, amelyet az init meghív. A harmadik elem, a dialup a terminálok alapértelmezett típusa. A negyedik paraméter, az on jelzi az init programnak, hogy aktiválja a vonalat. A sorban megjelenhetne továbbá még egy ötödik paraméter is, a secure, de ezt csak olyan terminálok esetében érdemes megadni, amelyek fizikailag megbízhatóak (például a rendszerkonzol). Az alapértelmezett termináltípus (vagyis a fenti példában a dialup) a helyi beállításoktól függ. A betárcsázós vonalak esetében hagyományosan a dialup a terminál alapértelmezett típusa, amit aztán a felhasználók a bejelentkezéskor lefutó szkriptjeiken keresztül a automatikusan át tudnak állítani a nekik megfelelõ terminálra. A szerzõ saját rendszerében azonban inkább a vt102 termináltípust volt érdemes megadni alapértelmezettként, mivel ott a felhasználók csak ilyen típusú terminálokat használnak. Miután az /etc/ttys állományban elvégeztük a szükséges módosításokat, egy HUP jelzéssel figyelmeztessük az init programot az újbóli beolvasására. Ehhez a következõ parancs ajánlott: &prompt.root; kill -HUP 1 Ha még csak állítjuk be elõször a rendszerünket, akkor az init figyelmeztetése elõtt legyünk türelmesek, és várjuk meg, amíg a modemek befejezik az inicializálást és kapcsolódnak a vonalakra. A rögzített sebességû beállítás A rögzített sebesség beállításánál a ttys állományban a getty paramétereként egy szintén rögzített sebességû bejegyzést kell megadnunk. Például az olyan modemeknél, ahol a sebességet 19,2 Kbps-re rögzítjük, a ttys így fog kinézni: ttyd0 "/usr/libexec/getty std.19200" dialup on Amennyiben a modemünk nem ezen a sebességen üzemelne, akkor az std.sebesség paramétert használjuk az std.19200 helyett. Elõtte azonban ne felejtsük el ellenõrizni, hogy a megadott típus szerepel-e az /etc/gettytab állományban. Az alkalmazkodó sebességû beállítás Az alkalmazkodó sebességû beállításnál a ttys állományban az /etc/gettytab állományból a megfelelõ auto-baud (sic) kell megadnunk. Például, ha modemünk kezdõsebessége 19,2 Kbps (és a gettytab ehhez tartalmaz egy V19200 nevû bejegyzést), akkor a ttys így fog kinézni: ttyd0 "/usr/libexec/getty V19200" dialup on <filename>/etc/rc.d/serial</filename> rc állományok rc.serial A gyorsabb, mint például a V.32, V.32bis és V.34 modemeknél meg kell adnunk a hardveres forgalomirányítás (RTS/CTS) használatát is. Az /etc/rc.d/serial állományban tudjuk megadni a &os; rendszermagban a vonal használatához szükséges vezérlési beállításokra vonatkozó stty parancsokat. Például állítsuk be az 1-es sorszámú (vagyis a COM2) soros porton a crtscts termios beállítást a behíváshoz és a híváshoz használt eszközök inicializálásakor. Ehhez a következõ sorokat kell felvennünk az /etc/rc.d/serial állományba: # A soros portok kezdeti beállításai: stty -f /dev/ttyd1.init crtscts stty -f /dev/cuad1.init crtscts A modemek beállításai Ha olyan modemeink vannak, amelyek paramétereit egy statikus memóriában tárolták le, akkor ezek beállításához egy terminálprogramot kell használnunk (amilyen például &ms-dos; alatt a Telix vagy &os; alatt a tip). A modemet a getty programnak megadott kezdeti sebességen csatlakoztassuk és az alábbi elvárások alapján állítsuk be a paramétereit: Kapcsolódáskor CD jelzése. Mûködéskor DTR jelzése. A DTR küldésekor bontsa a vonalat és hozza alapállapotba a modemet. CTS vezérlésû kimenõ adatforgalom. A XON/XOFF forgalomvezérlés tiltása. RTS vezérlésû bejövõ adatforgalom. Csendes mód (ne adjon értesítést az eredményekrõl). A parancsokat ne írja vissza. A modemhez tartozó dokumentációban kell utánajárnunk, hogy milyen parancsok és/vagy DIP kapcsolók átállításával lehet mindezeket elérni. Például, ha a fenti paramétereket egy &usrobotics; &sportster; 14400-as külsõ modem esetében a következõ neki kiküldött paranccsal lehet beállítani: ATZ AT&C1&D2&H1&I0&R2&W Ilyenkor még akár más egyéb paramétereket is beállíthatunk, például a V.42bis és/vagy az MNP5 tömörítést. Az &usrobotics; &sportster; 14400 külsõ modemen ezenkívül még találunk néhány DIP kapcsolót is. Az ilyen modemek esetében például ezeket a beállításokat tudjuk használni: 1. kapcsoló: FEL — normális DTR 2. kapcsoló: N/A (verbális/numerikus eredményjelzõ kódok) 3. kapcsoló: FEL — az eredményjelzõ kódok küldésének tiltása 4. kapcsoló: LE — nem küldi vissza a parancsokat 5. kapcsoló: FEL — automatikus válasz 6. kapcsoló: FEL — normális Carrier Detect 7. kapcsoló: FEL — a memóriában tárolt alapértelmezések betöltése 8. kapcsoló: N/A (intelligens/buta mód) A modemeknél az eredményjelzõ kódok kikapcsolása/letiltása ezért fontos, mert így el tudunk kerülni az olyan problémákat, hogy a getty tévesen egy login: promptot küld a parancs módban levõ modemnek, amikor az visszaküldi a parancsot és az eredmény kódját. Ennek eredménye egy hosszúra nyúló, zavaros társalgás lesz a getty és a modem között. A rögzített sebességû beállítás A rögzített sebességû konfiguráció használata esetén úgy kell beállítanunk a modemet, hogy a konkrét adatátviteli sebsségtõl függetlenül is egy állandó sebességû kapcsolat álljon fenn a számítógép és a modem között. A &usrobotics; &sportster; 14400-as külsõ modem esetében a most következõ parancsokkal tudjuk rögzíteni a kapcsolat sebességét: ATZ AT&B1&W Az alkalmazkodó sebességû beállítás Amikor változó sebességû konfigurációval dolgozunk, akkor a modemet úgy kell beállítani, hogy a bejövõ hívásnak megfelelõ adatátviteli sebességre váltson a soros portján. A &usrobotics; &sportster; 14400-as külsõ modem esetében az alábbi parancsokkal rögzítjük a modemnek küldött hibamentesített parancsok sebességét, miközben engedélyezzük, hogy a soros port sebessége változhasson a nem hibamentesített kapcsolatoknál: ATZ AT&B2&W A modem beállításainak ellenõrzése A legtöbb nagysebességû modem biztosít valamilyen lehetõséget arra, hogy emberi formában is le tudjuk kérdezni a belsõ mûködésének paramétereit. A &usrobotics; &sportster; 14400-as külsõ modem esetében az ATI5 parancs a statikus memóriában tárolt beállításokat mutatja meg. A modem valós mûködési paramétereit (amit ugyebár befolyásolnak a DIP kapcsolók állásai is) viszont az ATZ majd ATI4 parancsok küldésével tudjuk lekérni. Ha azonban másmilyen márkájú modemünk lenne, akkor a modem leírásában próbáljunk tájékozódni arról, miként tudjuk a modem beállításait ellenõrizni. Hibaelhárítás Ebben a szakaszban bemutatunk néhány lépést, amelyeken keresztül ellenõrizhetjük a rendszerünkhöz csatlakoztatott modemet. A &os; rendszer ellenõrzése Csatlakoztassuk a modemet a &os; rendszerre, indítsuk be a gépet, majd ezután figyeljük a modemünk állapotát jelzõ lámpákat, hogy közülük a DTR világít-e, amikor a login: felirat megjelenik a rendszerkonzolon. Amennyiben erre a válasz igen, akkor az arra utal, hogy a &os; a hozzátartozó kommunikációs porton elindította a megfelelõ getty programot és a modem várja a hívásokat. Amikor viszont a DTR lámpa nem világít, a konzolon keresztül jelentkezzünk be a &os; rendszerbe és adjuk ki egy ps ax parancsot, amivel így ellenõrizni tudjuk, hogy a porthoz tartozó getty elindult. A futó programok között tehát valami ilyesmit kell majd látnunk: 114 ?? I 0:00.10 /usr/libexec/getty V19200 ttyd0 115 ?? I 0:00.10 /usr/libexec/getty V19200 ttyd1 Ha viszont például ezt látjuk: 114 d0 I 0:00.10 /usr/libexec/getty V19200 ttyd0 és modem még nem fogadott hívást, akkor ez azt jelenit, hogy a getty megnyitotta a kommunikációs csatornát. Ez utalhat egyaránt egy hibás kábelre vagy a modem helytelen beállítására, mivel a getty egészen addig nem lesz képes megnyitni az adott portot, amíg a modem vissza nem küld neki egy CD (Carrier Detect) jelet. Ha a listában az adott ttydN eszközhöz semmilyen getty programot nem találunk, akkor újra nézzük át az /etc/ttys állományban szereplõ bejegyzéseket, mert elõfordulhat, hogy azokban vétettünk valamilyen hibát. Emellett még a /var/log/messages naplóban is érdemes utánanézni, hátha az init vagy a getty küldött valamilyen hibáról értesítést. Ha még ezek után sem találunk semmit, akkor megint kezdjük el keresni hibákat, hiányzó bejegyzéseket vagy eszközöket az /etc/ttys, /etc/gettytab és a megfelelõ /dev/ttydN állományokban. A betárcsázás kipróbálása Próbáljunk meg bejutni a rendszerünkbe. Ehhez a távoli rendszeren ne felejtsük el beállítani a 8 bites adatátvitelt és az 1 stopbitet, illetve a paritást kikapcsolni. Ha erre közvetlenül nem kapunk egy bejelentkezési képernyõt vagy csak szemét jelenik meg, akkor kb. másodpercenként egyszer nyomjuk le az Enter billentyût. Ha még ezután sem látjuk a bejelentkezési képernyõt felbukkani, akkor próbáljunk kiküldeni egy BREAK parancsot. Ha a híváshoz nagysebességû modemet használunk, akkor próbáljuk meg a modem sebességét rögzíteni és úgy tárcsázni (ezt például a &usrobotics; &sportster; modemnél az AT&B1 paranccsal tudjuk elérni): Ha viszont még ezek után sem kapjuk meg a bejelentkezõ képernyõt, akkor a /etc/gettytab állományban megint nézzük át az összes beállítást: Az /etc/ttys állományban megadott alaptulajdonság neve egyezik az /etc/gettytab állományban találhatóval. Mindegyik nx= bejegyzés után egy másik gettytab tulajdonság neve jön. Mindegyik tc= bejegyzés után egy másik gettytab tulajdonság neve következik. Ha hívunk, de a &os; rendszerünkre kapcsolt modem továbbra sem veszi fel, akkor a modem beállításai között ellenõrizzük, hogy a DTR jel küldésekor a modem fogadja-e a hívást. Ha úgy tûnik, hogy a modem minden ezzel kapcsolatos beállítása stimmel, akkor nézzük meg, hogy a modem lámpái közül a DTR világít-e (már ha van ilyen). Ha mindent többször is végignéztünk és még mindig nem leljük a megoldást, akkor tartsunk egy kis szünetet és térjünk vissza a problémához késõbb. Ha még ezután sem tudjuk mûködésre bírni, akkor küldjünk egy levelet a &a.questions; címére, amelyben leírjuk a modemünket és a vele kapcsolatos problémát, és a lista tagjai majd megpróbálnak nekünk segíteni. A betárcsázós szolgáltatások használata betárcsázós szolgáltatások használata A következõkben arra vonatkozóan igyekszünk tanácsokat adni, amikor mi magunk akarunk modemmel csatlakozni valamilyen számítógéphez. Ezek tehát olyan esetekben hasznosak, amikor egy távoli géppel akarunk terminálkapcsolatot létesíteni. A BBS-ek használatára is érvényes. Ez ilyen típusú kapcsolatok kifejezetten hasznosak tudnak lenni olyan esetekben, amikor az interneten el akarunk érni egy állományt, de gondjaink akadtak a PPP használatával. Ha például egy állományt akarunk letölteni, de a PPP valamiért nem mûködik, akkor ezt a terminál alapú kapcsolaton keresztül is meg tudjuk tenni. Ilyenkor egy zmodem segítségével tudjuk áttölteni a számítógépünkre. - + A gyári Hayes-modem erre nem alkalmas, mihez tudunk vele kezdeni? A tip man oldala valójában már nem is teljesen aktuális, ugyanis tartalmaz egy beépített Hayes-tárcsázót. Úgy tudjuk engedélyezni, ha az /etc/remote állományban megadjuk az at=hayes beállítást. A Hayes-eszközök meghajtója nem elég ügyes ahhoz, hogy felismerje az újabb modemek által felkínált fejlettebb lehetõségeket — például a BUSY, NO DIALTONE vagy a CONNECT 115200 üzenetek csak megzavarják. Ezért a tip használata során kapcsoljuk ki ezeket az üzeneteket (az ATXO&W paranccsal). Emellett még érdemes tudni, hogy a tip a híváskor 60 másodpercig vár. A modemünkön ennél kisebb idõt kell beállítanunk, máskülönben a tip azt hiszi, hogy valamilyen kommunikációs probléma merült fel. Ehhez próbálkozzunk az ATS7=45&W paranccsal. Hogyan adjuk meg ezeket az AT parancsokat? /etc/remote Az /etc/remote állományban hozzunk létre egy direct bejegyzést. Például, ha a modemünk az elsõ soros porton, vagyis a /dev/cuad0 eszközön tanyázik, akkor a következõ sort kell beleírnunk: cuad0:dv=/dev/cuad0:br#19200:pa=none A br tulajdonságnál a modem által ismert legnagyobb adatátviteli sebességet adjuk meg. Ezután gépeljük be a tip cuad0 parancsot és már kapcsolódunk is a modemhez. Vagy root felhasználóként a cu parancsot is használhatjuk: &prompt.root; cu -lvonal -ssebesség Itt a vonal a soros port (például /dev/cuad0) és a sebesség annak sebessége (például 57600) lesz. Miután befejeztük az AT parancsok kiadását, az ~. begépelésével tudunk kilépni. - + A pn tulajdonságnál a <literal>@</literal> jel nem használható! A pn (phone number) tulajdonság értékében szereplõ @ jel segítségével az /etc/phones állományban tudunk hivatkozni egy telefonszámra. A @ a tulajdonságokat tároló állományok azonban, így például az /etc/remote állomány esetén is megkülönböztetett jelentéssel bírnak. Ezért itt csak egy visszaper jellel tudjuk beírni: pn=\@ - + Hogyan hívjunk fel egy számot parancssorból? Tegyünk egy általános bejegyzést az /etc/remote állományunkba. Például egy ilyet: tip115200|Dial any phone number at 115200 bps:\ :dv=/dev/cuad0:br#115200:at=hayes:pa=none:du: tip57600|Dial any phone number at 57600 bps:\ :dv=/dev/cuad0:br#57600:at=hayes:pa=none:du: Ezután már ilyet is tudni fogunk: &prompt.root; tip -115200 5551234 Ha viszont a tip helyett inkább a cu programot használnánk szívesen, akkor ehhez készítsünk egy általános bejegyzést: cu115200|Use cu to dial any number at 115200bps:\ :dv=/dev/cuad1:br#57600:at=hayes:pa=none:du: Majd gépeljük be ezt: &prompt.root; cu 5551234 -s 115200 - + Ehhez minden adandó alkalommal meg kell adnom a sebességet is? Hozzunk létre egy tip1200 vagy cu1200 nevû bejegyzést, de a br tulajdonságnál adjuk meg a használni kívánt sebességet. Mivel a tip szerint az 1200 bps egy megfelelõ alapértelmezés, ezért alapból a tip1200 bejegyzést fogja keresni. Ez természetesen nem jelenti azt, hogy ilyen sebsséggel is akarunk dolgozni. - + A terminálszerveren keresztül több más gépet is elérek Ahelyett, hogy minden alkalommal megvárnánk a kapcsolódás befejezést és begépelnénk a CONNECT gép parancsot, használjuk a cm tulajdonságát. Például nézzük meg ilyen bejegyzést az /etc/remote állományban: pain|pain.deep13.com|Forrester's machine:\ :cm=CONNECT pain\n:tc=deep13: muffin|muffin.deep13.com|Frank's machine:\ :cm=CONNECT muffin\n:tc=deep13: deep13:Gizmonics Institute terminal server:\ :dv=/dev/cuad2:br#38400:at=hayes:du:pa=none:pn=5551234: Ennek hatására elég csak annyit megadnunk, hogy tip pain vagy tip muffin, és már kapcsolódunk is a pain vagy muffin gépekhez. A tip deep13 paranccsal pedig egyenesen a terminálszerverhez jutunk el. - + Több vonalon is lehet egy géphez csatlakozni? Ez gyakran okoz gondot olyan esetekben, amikor egy egyetemnek több betárcsázó vonala van, és azokon keresztül többezer hallgató próbál meg dolgozni. Vegyük fel az egyetemet az /etc/remote állományba és használjuk a pn tulajdonság megadásánál a @ jelet: nagy-egyetem:\ :pn=\@:tc=dialout dialout:\ :dv=/dev/cuad3:br#9600:at=courier:du:pa=none: Ezután adjuk hozzá az /etc/phones állományhoz az egyetem telefonszámait: nagy-egyetem 5551111 nagy-egyetem 5551112 nagy-egyetem 5551113 nagy-egyetem 5551114 A tip mindegyik telefonszámot az adott sorrendben próbálja tárcsázni és végén feladja a próbálkozást. Ha folyamatosan akarjuk ezeket a számokat hívni, akkor tip parancsot tegyük egy ciklusba. - + Miért kell kétszer lenyomni a <keycombo action="simul"> <keycap>Ctrl</keycap> <keycap>P</keycap> </keycombo> gombokat, hogy egyszer elküldje a <keycombo action="simul"> <keycap>Ctrl</keycap> <keycap>P</keycap> </keycombo> kombinációt? A CtrlP billentyûkombináció alapértelmezés szerint a kikényszerítést jelenti, amivel a tip programnak tudunk szólni, hogy a következõ adat szó szerint értendõ. A ~s szekvenciával bármelyik másik karakternek át tudjuk adni ezt a szerepet, ami egy változó beállítását jelenti (set a variable). Gépeljük be, hogy ~sforce=egyetlen-karakter és zárjuk le egy újsorral. Az egyetlen-karakter helyére tetszõleges, egykarakteres szimbólumot megadhatunk. Ha itt nem adunk meg semmit, akkor a kikényszerítõ karakter a nul lesz, amit a Ctrl2 vagy a CtrlSzóköz lenyomásával tudunk elõhozni. Az egyetlen-karakter szerepére például tökéletes a Shift Ctrl 6 , amit csak nagyon kevés terminálszerver alkalmaz. A kikényszerítést végzõ karaktert az $HOME/.tiprc állományban tetszõleges karakterre át tudjuk állítani: force=egyetlen-karakter - + Miért lett hirtelen minden begépelt betû nagybetûs?? Valószínûleg sikerült lenyomnunk a Ctrl A gombkombinációt, ami a tip betûmód váltás funkciójának felel meg. Ezt olyanok számára dolgozták ki, akiknél nem mûködik a Caps Lock billentyû. Az elõbb bemutatott ~s használatával állítsuk át a raisechar változót valami másra. Tulajdonképpen akár ugyanarra is állíthatjuk, mint a kikényszerítõ karaktert, ha nem áll szándékunkban használni. Ebben a példában egy olyan .tiprc állomány szerepel, amely tökéletesen megfelel azon Emacs felhasználók számára, akik sokat használják a Ctrl2 és CtrlA kombinációkat: force=^^ raisechar=^^ A ^^ a ShiftCtrl6 billentyûkombinációt jelenti. - + Hogyan mozgassunk állományokat a <command>tip</command> használatával? Amikor más &unix; rendszerekkel vesszük fel a kapcsolatot, akkor állományokat a ~p (mint put, vagyis adni) és ~t (mint take, vagyis venni) használatával tudunk mozgatni. Ezek a parancsok a távoli rendszeren a cat és az echo felhasználásával fogadnak és küldenek állományokat. Alakjuk a következõ: ~p helyi-állomány távoli-állomány ~t távoli-állomány helyi-állomány Ilyenkor nincs hibaellenõrzés, ezért inkább egy másik protokollt, például zmodemet érdemes használnunk. - + Hogyan lehet zmodemet használni a <command>tip</command> programban? Állományokat úgy tudunk fogadni, ha elõtte a kapcsolat távolabbi végén elindítjuk a küldést végzõ programot. Ezután a ~C rz parancs kiadásával kezdhetjük meg helyben a fogadását. Állományokat úgy tudunk küldeni, ha elõtte a kapcsolat másik végén elindítjuk a fogadó programot. Ezután a ~C sz állományok parancs kiadásával tudjuk megkezdeni a küldést. Kazutaka YOKOTA Készítette: Bill Paul Az alapján szolgáló írást készítette: A soros vonali konzol beállítása soros konzol Bevezetés A &os; képes úgy is elindulni, ha konzolként mindössze egy buta terminált kapcsolunk rá soros porton keresztül. Az ilyen típusú konfigurációs alapvetõen két típus számára bizonyul hasznosnak: azon rendszergazdák számára, akik billentyûzettel és monitorral nem rendelkezõ gépekre akarnak &os;-t telepíteni, és olyan fejlesztõk számára, akik a rendszermag vagy különbözõ eszközmeghajtók mûködését akarják nyomon követni. Ahogy arról már a ben is szó esett, a &os; három indítási fokozattal rendelkezik. Az elsõ két fokozat a rendszerindító blokk kódjában foglal helyet, amely pedig a lemezen található &os; slice elején. A rendszer indulásakor ez a blokk betöltõdik és lefuttatja a harmadik fokozatot képviselõ rendszertöltõt (a /boot/loader állományt). Ha soros vonali konzol beállításához tehát be kell állítanunk a rendszerindító blokkot, a rendszertöltõt és a rendszermagot. A soros konzol beállítása, rövidített változat Ebben a szakaszban azt feltételezzük, hogy az alap beállításokkal dolgozunk és csupán egy gyors áttekintésre van szükségünk a soros vonali konzolról. Csatlakoztassunk egy soros kábelt a COM1 portra és a terminálra. Rendszeradminisztrátorként a következõ parancs kell kiadnunk ahhoz, hogy a soros konzolon láthassuk az összes rendszerindításhoz tartozó üzenetet: &prompt.root; echo 'console="comconsole"' >> /boot/loader.conf Nyissuk meg az /etc/ttys állományt, és a ttyd0 eszközhöz tartozó sorban írjuk át az off paramétert az on értékre és a dialup paramétert a vt100 értékre. Ha nem ezeket állítjuk be, akkor a soros konzol keresztül jelszó megadása nélkül is be tudunk jelentkezni, ami viszont egy biztonsági rés veszélyével fenyeget. A változtatások érvényesítéséhez indítsuk újra a rendszerünket. Ha ettõl eltérõ beállításokra lenne szükségünk, akkor a folyamat egyes lépéseibe a ban kaphatunk mélyebb betekintést. A soros vonali konzol beállítása Készítsük elõ a soros kábelt. null-modem kábel Vagy a null-modem kábelre vagy pedig egy szabványos soros kábelre és egy null-modem átalakítóra lesz szükségünk. A soros kábelekkel kapcsolatosan a t érdemes elolvasni. Húzzuk ki a billentyûzetet. A legtöbb személyi számítógép az indítása (vagyis a Power-On Self-Test, POST) során hibát jelez, ha nem érzékel billentyûzetet. Egyes gépek hangosan panaszolják a billentyûzet hiányát, és nem is hajlandóak egészen addig elindulni, amíg nem csatlakoztatunk egyet. Ha a számítógépünk hibát küld, de ennek ellenére mégis elindul, akkor semmit nem kell csinálnunk. (Némelyik Phonix BIOS-os gépen ilyenkor megjelenik a Keyboard failed hibaüzenet, de ettõl még rendesen elindul a gép.) Amennyiben a számítógépünk nem hajlandó billentyûzet nélkül elindulni, állítsuk be a BIOS-ban a hiba figyelmen kívül hagyását (már ha ez lehetséges). Az alaplap leírásában találhatjuk meg ennek pontos részleit. A BIOS paraméterei között a billentyûzetet állítsuk Not installed állapotúra. Ilyenkor még továbbra is használható a billentyûzet, ezzel mindössze csak a BIOS számára tiltjuk le az indításkori ellenõrzést, ezért nem fog panaszkodni a hiánya miatt. Tehát a billentyûzetet még a Not installed beállítása esetén is nyugodtan csatlakoztatjuk, mert mûködni fog. Ha a rendszerünkön &ps2;-es egér is található, akkor jó eséllyel a billentyûzettel együtt az egeret is ki tudjuk húzni. Mivel a &ps2;-es egér osztozik a billentyûzettel bizonyos hardvereken, ezért ha nem húzzuk ki az egeret is, akkor az alaplap még továbbra is képes azt gondolni, hogy a billentyûzet ott van. Például az AMI BIOS-os Gateway 2000-as 90 MHz-es Pentium rendszer pontosan így mûködik. Általában véve azonban ez nem szokott gondot okozni, mivel az egér billentyûzet nélkül úgy sem ér túlságosan sokat. Csatlakoztassunk egy buta terminált a COM1 (sio0) portra. Ha nem rendelkezünk buta terminállal, akkor erre célra ugyanúgy alkalmas egy régi XT-s PC valamilyen modemprogrammal vagy egy soros porton csatlakozó másik &unix;-os gép. Ha nincs COM1 (sio0) portunk, akkor szerezzünk egyet. Jelen pillanatban a rendszerindító blokk újrafordítása nélkül a COM1 porton kívül nem tudunk másikat választani. Ha a COM1 portra már raktunk valamilyen másik eszközt, akkor azt ideiglenesen húzzuk le, majd a &os; telepítése és elindítása után tegyünk fel egy másik rendszerindító blokkot. (Egyébként feltételezzük, hogy a COM1 elérhetõ egy állomány/számító/terminálszerveren — ha valóban valamilyen másik célra szükségünk lenne a COM1 portra (és semmiképpen sem tudjuk átrakni a COM2 (sio1) portra), akkor valószínûleg nem is ezzel kellene elsõként foglalkoznunk.) Gondoskodjunk róla, hogy a rendszermag beállításait tartalmazó állományban a COM1 (sio0) eszközhöz megadtuk a megfelelõ paramétereket. Ezek az alábbiak: 0x10 A konzolos mûködési mód engedélyezése az adott egységhez. Ha megadjuk ezt a paramétert, akkor a többit a rendszer figyelmen kívül hagyja. Pillanatnyilag legfeljebb egy egység birtokolhatja ezt a beállítást. Ha több ilyet adtunk volna meg, akkor (a felírás sorrendje szerint) az elsõ kap ilyen szerepet. Ez a beállítás önmagában még nem teszi a soros portot konzollá. Ehhez még szükségünk van a következõ beállításra, vagy a megadására is. 0x20 Az egység konzollá nyilvánítása (hacsak nincs egy tõle nagyobb prioritású konzol), függetlenül a lentebb ismertetendõ opciótól. A 0x20 értéket a értékkel együtt kell megadni. 0x40 (A 0x10 értékkel együtt) az egységet kivonja a normális elérés alól. Ezt a beállítást ne használjuk, ha soros vonali konzolt akarunk üzemeltetni az adott porton. Ezzel az egységet csak a rendszermag távoli nyomkövetéséhez tudjuk használni. A távoli nyomkövetésrõl a fejlesztõk kézikönyvében olvastunk bõvebben. Példa: device sio0 at isa? port IO_COM1 flags 0x10 irq 4 A további részletekrõl a &man.sio.4; man oldal tud felvilágosítást nyújtani. Ha nem állítottuk be a megfelelõ paramétereket, akkor (egy másik konzolon) futtassuk a UserConfig programot vagy fordítsuk újra a rendszermagot. Hozzunk létre egy boot.config állományt a rendszer indításához használt meghajtó a partíciójának gyökerében. Ez az állomány mondja meg a rendszerindító blokkban található kódnak, hogy miként akarjuk indítani a rendszerünket. A soros vonali konzol életrekeltéséhez a most következõ opciók közül kell megadnunk egyet vagy többet — amennyiben többet akarunk megadni, akkor mindegyiket egyetlen sorban szerepeltessük: A belsõ és a soros vonali konzolok közti átkapcsolás. Ezzel tudunk a konzolos eszközök között váltani. Például, ha egy belsõ (video) konzolról indítjuk a rendszert, akkor a rendszertöltõnek és a rendszermagnak átadott paraméterrel arra tudjuk ezeket utasítani, hogy konzolként a soros portot használják. Vagy ha soros porton keresztül indítjuk a rendszert, akkor megadásával megkérhetjük a rendszertöltõt és a rendszermagot, hogy ezután már a videokártyát használja konzolként. Az egy- és kétkonzolos beállítások közti váltás. Az egykonzolos konfigurációban a konzol lehet belsõ (video) vagy soros vonali, attól függõen, hogy miként használtuk a fenti opciót. A kétkonzolos konfigurációban azonban a videokártyán és a soros vonalon keresztül is egyszerre megjelenik a konzol, függetlenül a hatásától. Ilyenkor viszont vegyük figyelembe, hogy ez a kétkonzolos konfiguráció csak a rendszerindító blokk futása alatt él. Amint a rendszerindító megkapja a vezérlést, a által megadott konzol válik az egyedülivé. A rendszerindító blokk megpróbálja megkeresni a billentyûzetet. Ha nem találja, akkor magától beállítja a és opciókat. Tárbeli korlátozások miatt a rendszerindító blokk jelenlegi változata a paraméterrel csak a kiterjesztett billentyûzeteket képes kezelni. A 101 gombnál kevesebbel (tehát F11 és F12 gombokkal nem) rendelkezõ billentyûzeteket ezért nem feltétlenül fogja észlelni. Ugyanezen korlátozás miatt egyes laptopokon sem minden esetben sikerül érzékelni a billentyûzetet. Ha ez a rendszerünkön problémához vezetne, akkor egyszerûbb lesz elhagyni a használatát. Sajnos, jelenleg semmilyen megoldás nincs erre. Vagy a opcióval állítassuk be automatikusan a konzolt, vagy pedig a opcióval engedélyezzük a soros vonali konzolt. Természetesen itt a &man.boot.8; man oldalon szereplõ összes többi paramétert is megadhatjuk. A kivételével az összes opció a rendszertöltõnek (/boot/loader) kerül átadásra. A rendszertöltõ egyedül a állapotából dönti el, hogy mely belsõ videoeszközön vagy soros porton legyen a konzol. Ez azt jelenti, hogy a /boot.config állományban ha megadjuk a opciót, de mellette nem szerepel a , akkor a soros vonali konzolt csak a rendszerindító blokk futása alatt tudjuk elérni — a rendszertöltõ ugyanis alapból a videokártyát használja konzolként. Kapcsoljuk be a számítógépünket. Amikor elindítjuk a &os;-s gépünket, a rendszerindító blokk kiírja a /boot.config tartalmát a konzolra. Például így: /boot.config: -P Keyboard: no A második sor csak olyankor jelenik meg, ha a /boot.config állományban a beállítás is szerepel, és a billentyûzet jelenlétét (yes) vagy hiányát (no) jelzi. A /boot.config tartalmától függõen ezek az üzenetek vagy a soros vonali vagy a belsõ konzolon jelennek meg, esetleg mind a kettõn. Beállítás Ahol megjelenik nincs belsõ konzol soros vonali konzol soros vonali és belsõ konzol soros vonali és belsõ konzol , van billentyûzet belsõ konzol , nincs billentyûzet soros vonali konzol Az iménti üzenetek felbukkanása után a további konzolos üzenetek küldésében egy rövid szünet következik, amíg a rendszerindító blokk a rendszertöltõ betöltésével folytatja a rendszer indítását. Normális körülmények között ezt a folyamatot nem kell megszakítanunk, de esetleg olyankor mégis érdemes lehet, ha le akarjuk ellenõrizni a beállításainkat. A rendszerindítási folyamat félbeszakításához az Enter billentyûn kívül nyomjuk le valamelyik másikat. Ekkor a rendszerindító blokk megáll és várja a további parancsokat. Ekkor valami ilyesmit láthatunk: >> FreeBSD/i386 BOOT Default: 0:ad(0,a)/boot/loader boot: Nézzük meg, hogy /boot.config beállításainak megfelelõen a fenti üzenet a soros vonali konzolon vagy a belsõ konzolon, illetve mind a kettõn megjelenik-e. Ha az üzenet a megfelelõ konzolon megjelenik, akkor az Enter lenyomásával folytathatjuk a rendszer indítását. Ha nekünk a soros vonali konzolra lenne szükségünk, de semmi nem jelenik meg a soros terminálon, akkor valamit valószínûleg nem jól állítottunk be. A rendszerindító blokktól kapott parancssorban a begépelésével és az Enter vagy Return lenyomásával (ha lehetséges) jelezzük neki (és így a rendszertöltõnek és a rendszermagnak is) a soros vonali konzol kiválasztását. Miután befejezõdött a rendszer indítása, menjünk vissza és ellenõrizzük a megfelelõ paramétereket. Ahogy sikerült elindítani a rendszertöltõt és a rendszerindítás harmadik fokozatába léptünk, a rendszertöltõ megfelelõ környezeti változóin keresztül még mindig van lehetõségünk váltani a soros vonali és a belsõ konzol között, lásd . Összefoglalás Itt most röviden összefoglaljuk az eddig tárgyalt különbözõ beállításokat és ténylegesen kiválasztott konzolt. 1. eset: a <devicename>sio0</devicename> eszköznél a 0x10 beállítást adjuk meg device sio0 at isa? port IO_COM1 flags 0x10 irq 4 A /boot.config beállításai Konzol a rendszerindító blokk alatt Konzol a rendszertöltõ alatt Konzol a rendszermagban nincsenek belsõ belsõ belsõ soros vonali soros vonali soros vonali soros vonali és belsõ belsõ belsõ soros vonali és belsõ soros vonali soros vonali , van billentyûzet belsõ belsõ belsõ , nincs billentyûzet soros vonali és belsõ soros vonali soros vonali 2. eset: a <devicename>sio0</devicename> eszköznél 0x30 beállítása device sio0 at isa? port IO_COM1 flags 0x30 irq 4 A /boot.config beállításai Konzol a rendszerindító blokk alatt Konzol a rendszertöltõ alatt Konzol a rendszermagban nincsenek belsõ belsõ soros vonali soros vonali soros vonali soros vonali soros vonali és belsõ belsõ soros vonali soros vonali és belsõ soros vonali soros vonali , van billentyûzet belsõ belsõ soros vonali , nincs billentyûzet soros vonali és belsõ soros vonali soros vonali Tanácsok a soros vonali konzol használatához Nagyobb soros vonali sebesség beállítása A soros port alapértelmezései a következõk: 9600 baud, 8 bites átvitel, paritás nincs és 1 stopbit. Ha a konzol alapsebességét meg akarjuk változtatni, akkor ahhoz a következõket kell tennünk: Fordítsuk újra a rendszerindító blokkokat úgy, hogy a BOOT_COMCONSOLE_SPEED változóban a konzolnak egy másik sebességet adunk meg. Az új rendszerindító blokkok fordításáról és telepítésérõl a ban kapunk részletes leírást. Ha a soros vonali konzolt nem a opcióval állítottuk be, vagy ha a rendszermag a rendszerindító blokkoktól eltérõ módon éri el a soros vonali konzolt, akkor a rendszermag beállításai közé még az alábbit is fel kell vennünk, majd újra kell fordítanunk: options CONSPEED=19200 A rendszermagnak adjuk át a rendszerindítási paramétert. A parancssori opció a /boot.config állományban is megadható. A &man.boot.8; man oldalon tudhatjuk meg, hogy a /boot.config beállításai közé hogyan tudjuk felvenni és ott milyen további lehetõségeink vannak még. A /boot/loader.conf állományban engedélyezzük a comconsole_speed beállítást. Ez a beállítás a szintén a /boot/loader.conf állományban megadható console, boot_serial és boot_multicons változóktól függ. A soros vonali konzol sebességét tehát például így tudjuk megváltoztatni a comconsole_speed megadásával: boot_multicons="YES" boot_serial="YES" comconsole_speed="115200" console="comconsole,vidconsole" Soros vonali konzol a <devicename>sio0</devicename> porton kívül máshol Ha valamilyen okból kifolyólag nem a sio0 porton keresztül akarjuk használni a konzolt, akkor ahhoz a rendszerindító blokkok, a rendszertöltõ és a rendszermag forrásait újra kell fordítanunk az alábbiak szerint: Szerezzük be a rendszermag forrását. (Lásd ) Írjuk át a /etc/make.conf állományban a BOOT_COMCONSOLE_PORT címét az általunk használt porthoz tartozóéra (0x3F8, 0x2F8, 0x3E8 vagy 0x2E8). Itt csak a sio0 és sio3 (COM1 és COM4) közti portok használhatóak — a töbportos soros kártyák címei nem adhatóak meg. A megszakításokat nem kell beállítanunk. Készítsünk egy saját rendszermag beállításait tartalmazó állományt, és vegyük fel bele a használni kívánt soros port megfelelõ paramétereit. Például, ha a sio1 (COM2) eszközt akarjuk konzolként használni: device sio1 at isa? port IO_COM2 flags 0x10 irq 3 vagy device sio1 at isa? port IO_COM2 flags 0x30 irq 3 A konzolra vonatkozó beállításokat a többi soros portnál ne adjuk meg. Fordítsuk újra és telepítsük a rendszerindító blokkot és a rendszertöltõt: &prompt.root; cd /sys/boot &prompt.root; make clean &prompt.root; make &prompt.root; make install Fordítsuk és telepítsük újra a rendszermagot. A &man.bsdlabel.8; segítségével másoljuk az új rendszerindító blokkot a rendszer indítását végzõ lemezre és töltsük be az új rendszermagot. A DDB elérése a soros vonalról Ha a soros vonali konzolról akarjuk használni a rendszermagba épített nyomkövetõt (ami hasznos lehet távoli vizsgálódáskor, de egyben veszélyes is, ha a soros porton tévesen kiküldünk egy BREAK jelzést!), akkor a rendszermagot a következõ beállításokkal kell fordítanunk: options BREAK_TO_DEBUGGER options DDB A bejelentkezõ képernyõ elérése a soros vonali konzolról Habár erre nincs feltétlenül szükségünk, a rendszer üzeneteinek és a rendszermag nyomkövetõjének elérése után akár be is tudunk jelentkezni a soros vonalon keresztül. Íme! Nyissuk meg az /etc/ttys állományt a kedvenc szövegszerkesztõnkkel és keressük meg a következõ sorokat: ttyd0 "/usr/libexec/getty std.9600" unknown off secure ttyd1 "/usr/libexec/getty std.9600" unknown off secure ttyd2 "/usr/libexec/getty std.9600" unknown off secure ttyd3 "/usr/libexec/getty std.9600" unknown off secure A ttyd0 és ttyd3 közti sorok pontosan a COM1 és COM4 közti portoknak felelnek meg. A használni kívánt port sorában szereplõ off paramétert írjuk át az on értékre. Ha a soros port sebességét is megváltoztattuk, minden bizonnyal a std.9600 helyett is az adott sebességhez illeszkedõ paramétert kell megadnunk, például az std.19200 értékkel. Érdemes továbbá még az unknown helyett megadni az adott terminál típusát. Az állomány módosítását követõen a változatások érvényesítéséhez ki kell adnunk a kill -HUP 1 parancsot is. A konzol megváltoztatása a rendszertöltõbõl A korábbi szakaszokban arról beszéltünk, hogy miként állítsuk be a soros vonali konzolt a rendszerindító blokk megpiszkálásával. Ebben a szakaszban viszont azt mutatjuk meg, hogy különbözõ parancsokon és környezeti változókon keresztül miként tudjuk megadni a konzolt a rendszertöltõben. Mivel a rendszertöltõre a rendszerindítás harmadik fokozatában kerül sor, az ott megadott értékekkel felül tudjuk bírálni a rendszerindító blokk beállításait. A soros vonali konzol beállítása A rendszertöltõ és a rendszermag az /boot/loader.conf állományon keresztül elég könnyen rávehetõ a soros vonali konzol használatára: set console="comconsole" Ez a rendszerindító blokk elõzõ szakaszban tárgyalt beállításaitól függetlenül érvényesül. A fenti sort a /boot/loader.conf állomány elejére érdemes tennünk, így a soros vonali konzolon már a lehetõ leghamarabb megjelennek a rendszer üzenetei. Ehhez hasonló módon a belsõ konzolt is megadhatjuk: set console="vidconsole" Ha a rendszertöltõben nem adjuk meg a console környezeti változó értékét, akkor a rendszertöltõ, és így a rendszermag is, a rendszerindító blokkban a opció által meghatározott konzolt fogja használni. A konzol a /boot/loader.conf.local vagy a /boot/loader.conf állományokban adható meg. A részletekkel kapcsolatban lásd a &man.loader.conf.5; man oldalt. Jelen pillanatban a rendszertöltõnek nincs a paraméterrel ekvivalens értékû beállítása, ezért a billentyûzet jelenléte alapján nem képes magától választani a belsõ és a soros vonali konzol között. Soros vonali konzol a <devicename>sio0</devicename> porton kívül máshol A rendszertöltõt ne a sio0 eszközzel fordítsuk újra a soros vonali konzolhoz. Ehhez kövessük a ban leírt eljárás lépéseit. Figyelmeztetések A szakaszban szereplõ ötletek alapján sokan így most már könnyen be tudnak állítani egy billentyûzet és grafikus hardver nélküli dedikált szervert. Sajnos azonban a legtöbb rendszer nem engedi a billentyûzet nélküli indítást, és akad néhány olyan is, amely pedig a grafikus kártya hiányában nem is indul el. Az AMI BIOS-os gépeknél a grafikus kártya nélküli indításhoz elegendõ csupán a beállítások között a grafikus kártyát (graphics adapter) Not installed (nem telepített) állapotúra állítani. Ennek ellenére elõfordulhat azonban, hogy egyes gépeken egyáltalán nem találunk ilyen lehetõséget és videokártya nélkül nem indulnak el. Ezekben az esetekben tegyünk a gépbe valamilyen kártyát (ehhez elég egy egyszerû típus is), de monitort már ne kössünk rá. Esetleg megpróbálkozhatunk még AMI BIOS telepítésével is.