diff --git a/hu_HU.ISO8859-2/books/handbook/printing/chapter.sgml b/hu_HU.ISO8859-2/books/handbook/printing/chapter.sgml index 0d18b78aa5..1073046038 100644 --- a/hu_HU.ISO8859-2/books/handbook/printing/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/printing/chapter.sgml @@ -1,6905 +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õ párhuzamos porton levõ nyomtató + 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õ + 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 + &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 + &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 -i -d /dev/lptN + &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 -p -d /dev/lptN + &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 + &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 + &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 + 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 + 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 + &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 + /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 + á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 + á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 + &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 + &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: + :sh:sd=/var/spool/lpd/rattan: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ - :sh:sd=/var/spool/lpd/bamboo: + :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. + adunk meg semmilyen nyomtatási + könyvtárat, akkor ennek az értéke + alapértelmezés szerint a /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 + 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. + 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: + :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: + :sh:sd=/var/spool/lpd/bamboo:\ + :lp=/dev/ttyd5: Az LPD - alapértelmezés szerint a - /dev/lp eszköz fogja + 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. + á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: + :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 + &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: + :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: + :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 + &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 -Pnyomtatónév + &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 + !"#$%&'()*+,-./01234 "#$%&'()*+,-./012345 #$%&'()*+,-./0123456 $%&'()*+,-./01234567 -%&'()*+,-./012345678 +%&'()*+,-./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õ + linkend="printing-advanced-convfilters">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 -t - paranccsal troff adatok, vagy a lpr -d + képessé tenni az + lpr paranccsal troff + adatok, vagy a lpr paranccsal a &tex; DVI állományainak, esetleg - az lpr -v paranccsal raszteres - képek nyomtatására és így - tovább. Csak ajánlani tudjuk ennek + 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 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 -t 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) + 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 -l paranccsal adunk - át + 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 -i parancs - megadása során használt + 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: + :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 - -h paranccsal kérdezhetjük le.) + 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: + :if=/usr/local/libexec/ifhp: Készen is vagyunk! Most már nyugodtan beírhatjuk, hogy - lpr sima.szöveg vagy + 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 + &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 -d hínár-elemzés.dvi + &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 - -d parancs használata arra utal, hogy a - nyomtatónak az /etc/printcap + 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 -g - paranccsal Printerleaf állományokat tudnak + 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 könyvtárban találjuk meg. Ezen belül is általában a /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: + :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: + :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: + :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: 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: + :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: + :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ó + 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. + 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. + 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 - -i paranccsal hozzáadott munkákat) - tabulálni, (az lpr -l paranccsal - felvett munkákban) a vezérlõkaraktereket - figyelemen kívül hagyni, a munkában + 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: + :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 - -h 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 + 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 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 + 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 + 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) hozzátoldunk még egy - lapot a munkához, mivel a - felhasználók az lpr -h - parancs használatával kedvük szerint + 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 -h + 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 -h - paranccsal küldik a munkájukat. + 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 -h 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. + 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: + :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: + :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: + :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 -p /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 -P bamboo -d sushi-leírás.dvi + &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 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 -#5 - parancsot használja, akkor a munkában levõ + 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: + :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: + :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: + :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: + :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: + :lp=:rm=rose:rp=bamboo:sd=/var/spool/lpd/bamboo:sc: Az sc tulajdonság használatával ugyan megakadályozzuk az - lpr -# parancs + 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 + &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: + :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: + :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: + :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: + :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: + :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 - + &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 - -m paranccsal az alábbi - táblázatot készítetthetjük - el: + 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 -p1.50 + &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 -s parancs az általa - létrehozott elszámolást egy + 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 ... + &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 + &prompt.user; lpr /etc/host.conf /etc/hosts.equiv A nyomtató megválasztásához így adjuk ki a parancsot: - &prompt.user; lpr -P nyomtatónév állománynév ... + &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 -l | lpr -P rattan + &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 - -l parancs kimenete. + 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 -P bamboo + &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 - -l parancs eredménye: + 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 + &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 -P bamboo 10 + &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 -P rattan - + &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 -P rattan myfile -&prompt.user; rlogin orchid -&prompt.user; lpq -P rattan + &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 -P rattan 13 +&prompt.user; lprm rattan 13 rose: Permission denied -&prompt.user; logout -&prompt.user; lprm -P rattan 13 +&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 -P bamboo -d halászati-jelentés.dvi + &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 -t -man | lpr -t + &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 -#3 parser.c parser.h + &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 + !"#$%&'()*+,-./01234 "#$%&'()*+,-./012345 - #$%&'()*+,-./0123456 + #$%&'()*+,-./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: + :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 vonali - forgalomirányítást (carrier flow - control), akkor az ms# - tulajdonságnál a + 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 + :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. + 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 89b97e255e..47f43c519f 100644 --- a/hu_HU.ISO8859-2/books/handbook/security/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/security/chapter.sgml @@ -1,6224 +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 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, és &os; valamint - µsoft.windows; 2000/XP - számítógépekbõl - álló környezetben alkalmazzuk egy - biztonságos kommunikációs csatorna - kiépítéséhez. Az IPsec + 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 - - a rendszermag - beállításai - IPSEC_ESP - - options IPSEC # IP biztonság -options IPSEC_ESP # IP biztonság (titkosítás, az IPSEC-kel együtt) +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: - #!/bin/sh -/usr/local/sbin/setkey -FP -/usr/local/sbin/setkey -F + flush; +spdflush; # Az otthoni hálózati felé -/usr/local/sbin/setkey -c 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; -/usr/local/sbin/setkey -c 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; +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_file="/usr/local/etc/racoon/setkey.conf" # engedélyezzük az spd házirend beállítását a rendszer indításakor +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 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/virtualization/chapter.sgml b/hu_HU.ISO8859-2/books/handbook/virtualization/chapter.sgml index d0e078594d..d2b3606f4f 100644 --- a/hu_HU.ISO8859-2/books/handbook/virtualization/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/virtualization/chapter.sgml @@ -1,1240 +1,1240 @@ Murray Stokely Írta: Virtualizáció Áttekintés A virtualizációs szoftverek lehetõvé teszik, hogy ugyanazon a számítógépen egyszerre több operációs rendszert is futassunk. Ezeknek a programcsomagoknak gyakorta részük egy gazda operációs rendszer is, amely a virtualizációs szoftvert futattja és ismer bizonyos vendég operációs rendszereket. A fejezet elolvasása során megismerjük: a gazda- és a vendég operációs rendszerek közti különbségeket; hogyan telepítsünk &os;-t egy &intel;-alapú &apple; &macintosh; számítógépre; hogyan telepítsünk a &xen; használatával &os;-t &linux;-ra; hogyan telepítsünk a Virtual PC használatával &os;-t µsoft.windows;-ra; hogyan hozzuk ki a legtöbbet &os; rendszerünkbõl virtualizáció alatt. A fejezet elolvasásához ajánlott: alapvetõ &unix;-os és &os;-s ismeretek (); a &os; telepítésének ismerete (); a hálózati kapcsolatok beállításának ismerete (); külsõs alkalmazások telepítésének ismerete (). A &os; mint vendég Parallelsszel &macos;-en A Parallels Desktop a &macos; 10.4.6, vagy afeletti verzióját futattó, &intel;-alapú &apple; &mac; személyi számítógépekre fejlesztett kereskedelmi alkalmazás. A &os;-t teljes mértékben támogatja vendégként. Miután telepítettük a Parallels-t a &macos; X-re, be kell állítanunk egy virtuális gépet, majd erre felraknunk a kívánt vendég operációs rendszert. A &os; telepítése &macos; X/Parallelsre A &os; &macos; X/Parallels párosra telepítéséhez elsõ lépésként készítenünk kell egy új virtuális számítógépet. A létrehozás során válasszuk a Guest OS Type-nak (a vendég operációs rendszer típusának) a &os;-t: Ezután adjunk meg egy nagyjából elfogadható méretet a virtuális merevlemezünknek, valamint annyi memóriát, amennyire szükségünk lehet a virtuális &os;-nk használata során. Egy 4 GB-os lemez és 512 MB rendszermemória a legtöbb esetben jó választásnak bizonyulhat a &os; Parallels alatti használata során: Válasszuk ki a hálózatkezelés típusát és a hálózati csatolót. Mentsük el és fejezzük be a konfigurálást. Miután a &os;-s virtuális gépünk elkészült, telepítenünk kell rá magát az operációs rendszert is. Ezt a legegyszerûbben a hivatalosan &os; telepítõ CD-rõl, vagy a hivatalos FTP oldalról letölthetõ CD-képpel tehetjük meg. Ha lemásoltuk a megfelelõ CD-képet a &mac; helyi állományrendszerére, vagy behelyeztük a telepítõ CD-t a CD-meghajtóba, kattintsunk a &os;-s Parallels ablakunk jobb alsó sarkában található lemez ikonjára. Ekkor feljön egy párbeszédablak, ahol összerendelhetjük a virtuális gépünk CD-meghajtóját egy lemezen található képpel, vagy éppen a valódi CD-meghajtónkkal. Ahogy megtettük az imént említett összerendelést, indítsuk is újra a &os;-s virtuális gépünket a megszokott módon, az újraindítás ikonjára kattintva. Ekkor a rendszer megtalálja a &os; telepítõlemezt és a sysinstall segítségével megkezdi a telepítést a ben leírtak szerint. Ha szükségünk van rá, telepíthetjük az X11-et is, de egyelõre még ne próbáljuk beállítani. A telepítés befejezését követõen indítsuk újra a frissen telepített &os;-s virtuális gépünket. A &os; beállítása &macos; X/Parallelsen Miután telepítettük a &os;-t &macos; X/Parallels-re, még vár ránk néhány konfigurációs lépés a rendszer virtuálizált mûködésének optimalizálása érdekében. A rendszerbetöltõ változóinak beállítása A legfontosabb lépés a változó értékének csökkentése, amivel így a &os; processzor-kihasználtságát is csökkentjük a Parallels alatt. Ezt a következõ sor hozzadásával tehetjük meg a /boot/loader.conf állományban: kern.hz=100 Enélkül egy üresjáratban levõ &os; Parallels-vendég az &imac; egy processzorának durván 15%-át foglalja le. A változtatás életbe léptetése után azonban ez megközelítõen 5%-ra redukálható. Egy új konfigurációs állomány létrehozása a rendszermaghoz Nyugodtan eltávolíthatjuk az összes SCSI, FireWire és USB eszközmeghajtót. A Parallels által felkínált virtuális hálózati csatolót az &man.ed.4; meghajtón keresztül tudjuk elérni, ezért az &man.ed.4; és &man.miibus.4; meghajtókon kívül az összes többi elhagyható. A hálózati kapcsolat beállítása Az alapvetõ hálózati beállítás a virtuális gépünkön a DHCP aktiválása, aminek segítségével csatlakozni tudunk arra a helyi hálózatra, amelyen maga a gazda &mac; is megtalálható. Ezt az alábbi sor felvételével tudjuk megoldani az /etc/rc.conf állományba: ifconfig_ed0="DHCP". Bõvebb információkért járuljunk a fejezethez. Fukang Chen (Loader) Írta: &xen;nel &linux;-on A &xen; hipervisor egy nyílt forráskódú, paravirtualizációt nyújtó termék, amely mögött mostanra már a XenSource kereskedelmi cég áll. Itt a vendég operációs rendszereket a domU tartományként azonosítják, míg a gazda operációs rendszer a dom0. A &os; &linux; alatti virtuális futattásához elsõként telepítenünk kell a &xen;-t egy dom0-ás Linuxra. A leírásban a gazda operációs rendszer a Slackware &linux; disztribúció lesz. A &xen; 3 beállítása egy &linux; dom0-án Töltsük le a &xen; 3.0-át a XenSource-tól Töltsük le a xen-3.0.4_1-src.tgz állományt a XenSource oldaláról. Bontsuk ki a csomagot &prompt.root; cd xen-3.0.4_1-src &prompt.root; KERNELS="linux-2.6-xen0 linux-2.6-xenU" make world &prompt.root; make install A rendszermagot így tudjuk dom0 módban újrafordítani: &prompt.root; cd xen-3.0.4_1-src/linux-2.6.16.33-xen0 &prompt.root; make menuconfig &prompt.root; make &prompt.root; make install A &xen; régebbi verzióinál elképzelhetõ, hogy így kell megadni: make ARCH=xen menuconfig. Vegyük fel a megfelelõ pontot a GRUB menüjébe Nyissuk meg a /boot/grub/menu.lst állományt és írjuk be a következõ sort: title Xen-3.0.4 root (hd0,0) kernel /boot/xen-3.0.4-1.gz dom0_mem=262144 module /boot/vmlinuz-2.6.16.33-xen0 root=/dev/hda1 ro Indítsuk újra a gépet és aktiváljuk a &xen;t Elõször nyissuk meg az /etc/xen/xend-config.sxp állományt, majd adjuk hozzá a következõ sort: (network-script 'network-bridge netdev=eth0') Ezután el is indíthatjuk a &xen;t: &prompt.root; /etc/init.d/xend start &prompt.root; /etc/init.d/xendomains start Láthatjuk, hogy a dom0 tartomány most már aktív: &prompt.root; xm list Name ID Mem VCPUs State Time(s) Domain-0 0 256 1 r----- 54452.9 A &os; 7-CURRENT mint domU Töltsük le a &os; &xen; 3.0-ás domU rendszermagját és a hozzátartozó lemezképet a http://www.fsmware.com/ címrõl: kernel-current mdroot-7.0.bz2 xmexample1.bsd Tegyük a xmexample1.bsd konfigurációs állományt a /etc/xen/ könyvtárba és írjuk át a releváns bejegyzéseket a rendszermag és a lemezkép elérési útjának megfelelõen. Valahogy így kellene kinézni az eredménynek: kernel = "/opt/kernel-current" memory = 256 name = "freebsd" vif = [ '' ] disk = [ 'file:/opt/mdroot-7.0,hda1,w' ] #on_crash = 'preserve' extra = "boot_verbose" extra += ",boot_single" extra += ",kern.hz=100" extra += ",vfs.root.mountfrom=ufs:/dev/xbd769a" Az mdroot-7.0.bz2 állományt ki kell tömöríteni! Ezután a kernel-current állományban található __xen_guest részt át kell írni úgy, hogy hozzáadjuk a &xen; 3.0.3 számára fontos VIRT_BASE értéket: &prompt.root; objcopy kernel-current -R __xen_guest &prompt.root; perl -e 'print "LOADER=generic,GUEST_OS=freebsd,GUEST_VER=7.0,XEN_VER=xen-3.0,BSD_SYMTAB,VIRT_BASE=0xC0000000\x00"' > tmp &prompt.root; objcopy kernel-current --add-section __xen_guest=tmp &prompt.root; objdump -j __xen_guest -s kernel-current kernel-current: file format elf32-i386 Contents of section __xen_guest: 0000 4c4f4144 45523d67 656e6572 69632c47 LOADER=generic,G 0010 55455354 5f4f533d 66726565 6273642c UEST_OS=freebsd, 0020 47554553 545f5645 523d372e 302c5845 GUEST_VER=7.0,XE 0030 4e5f5645 523d7865 6e2d332e 302c4253 N_VER=xen-3.0,BS 0040 445f5359 4d544142 2c564952 545f4241 D_SYMTAB,VIRT_BA 0050 53453d30 78433030 30303030 3000 SE=0xC0000000. Most már készen állunk a domU létrehozására és beindítására: &prompt.root; xm create /etc/xen/xmexample1.bsd -c Using config file "/etc/xen/xmexample1.bsd". Started domain freebsd WARNING: loader(8) metadata is missing! Copyright (c) 1992-2006 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 7.0-CURRENT #113: Wed Jan 4 06:25:43 UTC 2006 kmacy@freebsd7.gateway.2wire.net:/usr/home/kmacy/p4/freebsd7_xen3/src/sys/i386-xen/compile/XENCONF WARNING: DIAGNOSTIC option enabled, expect reduced performance. Xen reported: 1796.927 MHz processor. Timecounter "ixen" frequency 1796927000 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 1.80GHz (1796.93-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH, DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> Features2=0x4400<CNTX-ID,<b14>> real memory = 265244672 (252 MB) avail memory = 255963136 (244 MB) xc0: <Xen Console> on motherboard cpu0 on motherboard Timecounters tick every 10.000 msec [XEN] Initialising virtual ethernet driver. xn0: Ethernet address: 00:16:3e:6b:de:3a [XEN] Trying to mount root from ufs:/dev/xbd769a WARNING: / was not properly dismounted Loading configuration files. No suitable dump device was found. Entropy harvesting: interrupts ethernet point_to_point kickstart. Starting file system checks: /dev/xbd769a: 18859 files, 140370 used, 113473 free (10769 frags, 12838 blocks, 4.2% fragmentation) Setting hostname: demo.freebsd.org. lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet 127.0.0.1 netmask 0xff000000 Additional routing options:. Mounting NFS file systems:. Starting syslogd. /etc/rc: WARNING: Dump device does not exist. Savecore not run. ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/X11R6/lib /usr/local/lib a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout /usr/X11R6/lib/aout Starting usbd. usb: Kernel module not available: No such file or directory Starting local daemons:. Updating motd. Starting sshd. Initial i386 initialization:. Additional ABI support: linux. Starting cron. Local package initialization:. Additional TCP options:. Starting background file system checks in 60 seconds. Sun Apr 1 02:11:43 UTC 2007 FreeBSD/i386 (demo.freebsd.org) (xc0) login: A domU-ban a &os; 7.0-CURRENT rendszermagnak kell futnia: &prompt.root; uname -a FreeBSD demo.freebsd.org 7.0-CURRENT FreeBSD 7.0-CURRENT #113: Wed Jan 4 06:25:43 UTC 2006 kmacy@freebsd7.gateway.2wire.net:/usr/home/kmacy/p4/freebsd7_xen3/src/sys/i386-xen/compile/XENCONF i386 Miután errõl megbizonyosodtunk, be tudjuk állítani a hálózatot is domU-ban. A domU &os; egy xn0 nevû speciális eszközt használ erre a célra: &prompt.root; ifconfig xn0 10.10.10.200 netmask 255.0.0.0 &prompt.root; ifconfig xn0: flags=843<UP,BROADCAST,RUNNING,SIMPLEX> mtu 1500 inet 10.10.10.200 netmask 0xff000000 broadcast 10.255.255.255 ether 00:16:3e:6b:de:3a lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet 127.0.0.1 netmask 0xff000000 Eközben a dom0 Slackware-en néhány &xen;-függõ hálózati csatolónak is meg kell jelennie: &prompt.root; ifconfig eth0 Link encap:Ethernet HWaddr 00:07:E9:A0:02:C2 inet addr:10.10.10.130 Bcast:0.0.0.0 Mask:255.0.0.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:815 errors:0 dropped:0 overruns:0 frame:0 TX packets:1400 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:204857 (200.0 KiB) TX bytes:129915 (126.8 KiB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:99 errors:0 dropped:0 overruns:0 frame:0 TX packets:99 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:9744 (9.5 KiB) TX bytes:9744 (9.5 KiB) peth0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF UP BROADCAST RUNNING NOARP MTU:1500 Metric:1 RX packets:1853349 errors:0 dropped:0 overruns:0 frame:0 TX packets:952923 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2432115831 (2.2 GiB) TX bytes:86528526 (82.5 MiB) Base address:0xc000 Memory:ef020000-ef040000 vif0.1 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF UP BROADCAST RUNNING NOARP MTU:1500 Metric:1 RX packets:1400 errors:0 dropped:0 overruns:0 frame:0 TX packets:815 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:129915 (126.8 KiB) TX bytes:204857 (200.0 KiB) vif1.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF UP BROADCAST RUNNING NOARP MTU:1500 Metric:1 RX packets:3 errors:0 dropped:0 overruns:0 frame:0 TX packets:2 errors:0 dropped:157 overruns:0 carrier:0 collisions:0 txqueuelen:1 RX bytes:140 (140.0 b) TX bytes:158 (158.0 b) xenbr1 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF UP BROADCAST RUNNING NOARP MTU:1500 Metric:1 RX packets:4 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:112 (112.0 b) TX bytes:0 (0.0 b) &prompt.root; brctl show bridge name bridge id STP enabled interfaces xenbr1 8000.feffffffffff no vif0.1 peth0 vif1.0 Virtual PC-vel &windows;-on A &windows;-ra fejlesztett Virtual PC a µsoft; egyik szabadon letölthetõ szoftverterméke. A rendszerkövetelményeit bõvebben lásd a linken. Miután telepítettük a µsoft.windows;-ra a Virtual PC alkalmazást, be kell állítanunk egy virtuális gépet, majd telepítenünk kell rá a kívánt vendég operációs rendszert. A &os; telepítése Virtual PC/µsoft.windows;-ra Amikor a &os;-t a µsoft.windows; és Virtual PC párosra akarjuk telepíteni, akkor kezdjünk egy egy új virtuális gép létrehozásával. Ehhez válasszuk ki a menübõl a Create a virtual machine (Virtuális gép létrehozása) pontot. Majd válasszuk az Operating system (Operációs rendszer) beállításánál az Other (Egyéb) opciót. Ezután válasszuk ki a szándékainknak megfelelõen a telepítendõ &os; példányhoz mért memória és lemezterület mennyiségét. Ahhoz, hogy a &os; fusson Virtual PC alatt, 4 GB-nyi lemezterület és 512 MB RAM beállítása a legtöbb esetben kiválóan megfelelõ. Mentsük el és fejezzük be a konfigurációt. Válasszuk ki a &os;-s virtuális gépünket, majd kattintsunk a Settings (Beállítások) menüre és állítsuk be hálózati csatoló és hálózatkezelés típusát. A &os;-nek otthont adó virtuális gépünk létrehozása után telepítenünk is kell rá a rendszert. Ez legegyszerûbben a hivatalos &os; telepítõ CD-vel vagy a hivatalos FTP oldalról letölthetõ CD-képpel tehetjük meg. Amikor letöltöttük a megfelelõ CD-képet a helyi &windows;-os állományrendszerünkre vagy behelyeztük a telepítéshez használható CD-t a CD-meghajtónkba, a &os;-s virtuális gépünk elindításához kattintsunk rá duplán. Ezt követõen a Virtual PC ablakában kattintsunk a CD menüre és válasszuk ki belõle a Capture ISO Image... (Lemezkép használata...) pontot. Ennek hatására megjelenik egy ablak, amiben a virtuális gépünk CD-meghajtóihoz tudunk csatlakoztatni lemezképeket vagy akár létezõ CD-meghajtókat. Miután sikeresen beállítottuk a telepítõ CD forrását, indítsuk újra a virtuális gépet az Action (Mûvelet) menün belül a Reset (Újraindítás) pont kiválasztásával. Így a Virtual PC újraindítja a virtuális rendszert egy olyan speciális BIOS használatával, amely a normális BIOS-hoz hasonlóan elõször megkeresi az elérhetõ CD-meghajtókat. Ebben az esetben a &os; telepítõeszközét fogja megtalálni és megkezdi a ben ismertetett szokásos, sysinstall programra alapuló telepítési eljárást. Ennek során az X11-et is feltelepíthetjük, habár egyelõre még ne állítsuk be. Ne felejtsük el kivenni a meghajtóból a telepítéshez használt CD-t vagy elengedni a megfelelõ lemezképet, amikor befejezõdõtt a telepítés. Végezetül indítsuk ismét újra a frissen telepített &os;-s virtuális gépünket. A &os; beállítása a µsoft.windows;/Virtual PC-n Miután a &os;-t minden gond nélkül telepítettük a µsoft.windows;-on futó Virtual PC-re, még további beállítási lépéseket is meg kell tennünk a rendszer virtualizált mûködésének finomhangolásához. A rendszertöltõ változóinak beállítása A legfontosabb teendõnk csökkenteni a konfigurációs beállítás értéket, aminek köszönhetõen vissza tudjuk fogni a Virtual PC alatt futó &os; processzorhasználatát. Ezt úgy tudjuk megtenni, ha a /boot/loader.conf állományba felvesszük a következõ sort: kern.hz=100 Enélkül a Virtual PC alatt üresjáratban futó &os; vendég operációs rendszer egy egyprocesszoros számítógép idejének durván 40%-át foglalja le. A változtatás után azonban ez az érték pusztán közel 3%-ra csökken le. Új konfigurációs állomány létrehozása a rendszermaghoz Nyugodtan eltávolíthatjuk a SCSI, FireWire és USB eszközmeghajtókat. A Virtual PC által felajánlott virtuális hálózati csatolót a &man.de.4; meghajtón keresztül tudjuk használni, ezért a &man.de.4; és &man.miibus.4; eszközön kívül az összes többi hálózati eszköz támogatása kiszedhetõ a rendszermagból. A hálózati kapcsolat beállítása A legalapvetõbb hálózati beállítás csupán annyiból áll, hogy DHCP-n keresztül csatlakoztatjuk a virtuális gépünket ugyanahhoz a helyi hálózathoz, amiben a gazda µsoft.windows;-os gépünk is megtalálható. Ezt úgy tudjuk elérni, ha a /etc/rc.conf állományba megadjuk a ifconfig_de0="DHCP" sort. A komolyabb hálózati beállításokat a ben találhatjuk. VMware-rel MacOS-en A &mac;-ek számára fejlesztett VMWare Fusion egy olyan kereskedelmi termék, amit az &intel; alapú &apple; &mac; gépekre tudunk telepíteni a &macos; 10.4.9 és késõbbi változatain. A &os; itt egy teljesen támogatott vendég operációs rendszer. Miután a VMWare Fusion felkerült a &macos; X rendszerünkre, be kell állítanunk a virtuális gépet és telepítenünk rá a vendég operációs rendszert. A &os; telepítése a &macos; X/VMWare-re Elõször indítsuk el a VMWare Fusion-t, aminek eredményeképpen betöltõdik a Virtual Machine Library. Egy új virtuális gépre létrehozásához kattintsunk a "New" gombra: Ekkor bejön az új gép összeállítását segítõ New Virtual Machine Assistant, ahol a továbblépéshez kattintsunk a Continue gombra: Az operációs rendszerek (Operating System) közül válasszuk az egyéb (Other) kategóriát, majd a Version fülön a FreeBSD vagy a FreeBSD 64-bit változatot attól függõen, hogy 32 bites vagy 64 bites támogatásra van szükségünk: Adjuk meg a virtuális gép képének nevét és a könyvtárat, ahova el akarjuk menteni: Válasszuk meg a virtuális géphez tartozó virtuális merevlemez méretét is: Mondjuk meg, hogy milyen módon szeretnénk telepíteni a virtuális gépre, ISO formátumú lemezképrõl vagy CD-rõl: Ahogy a Finish feliratú gombra kattintunk, a virtuális gép máris elindul: Telepítsük fel a &os;-t a megszokott módon vagy a utasításai mentén: Miután befejezõdött a telepítés, módosítsuk a virtuális gép beállításait, például a memória mennyiségét: A virtuális gép hardveres beállításai a futása alatt nem változtathatóak meg. A virtuális gép által használható processzorok számát: A CD-meghajtó állapotát. Általában lehetõségünk van a virtuális gépet leválasztani a CD-meghajtóról vagy ISO lemezképrõl, ha már nem használjuk. A hálózati csatlakozás a virtuális géppel kapcsolatban utolsóként beállítandó tényezõ. Ha a befogadó gépen kívül még más gépeket is el akarunk érni a virtuális géprõl, akkor ehhez mindenképpen a Connect directly to the physical network (Bridged) opciót válasszuk. Minden más esetben a Share the host's internet connection (NAT) az ajánlott, mivel így a virtuális gép eléri az internetet, de a hálózatról nem lehet azt elérni. Miután befejeztük a beállítások finomhangolását, indítsuk is el a frissen telepített &os;-s virtuális gépünket. A &os; beállítása a &macos; X/VMWare-en Ahogy a &os;-t sikeresen telepítettük a &macos; X alatt futó VMWare-re, néhány konfigurációs lépést még meg kell tennünk a virtualizált rendszer teljesítmények optimalizálása érdekében. A rendszertöltõ változóinak beállítása A legfontosabb lépés talán a változó értékének csökkentése, amivel a VMWare alatt futó &os; processzorhasználatát szoríthatjuk vissza. Ezt a következõ sor hozzáadásával érhetjük el a /boot/loader.conf állományban: kern.hz=100 Enélkül az üresjáratban zakatoló &os;-s VMWare vendég nagyjából az &imac; egyik processzorának 15%-át emészti fel. Ezzel a módosítással azonban ez lenyomható közel 5%-ra. Új konfigurációs állomány létrehozása a rendszermaghoz Nyugodtan törölhetjük az összes FireWire és USB eszköz meghajtóját. A VMWare egy &man.em.4; meghajtón keresztül elérhetõ virtuális hálózati kártyát biztosít, így az &man.em.4; kivételével az összes hálózati eszköz meghajtóját kivehetjük a rendszermagból. A hálózat beállítása A legegyszerûbb hálózati beállítás mindösszesen a DHCP használatát igényli, aminek révén a virtuális gépünk a befogadó &mac;-kel egy helyi hálózatra kerül. Ezt úgy tudjuk engedélyezni, ha az /etc/rc.conf állományba felvesszük az ifconfig_em0="DHCP" sort. Ha ennél komolyabb hálózati beállítások is érdekelnek minket, akkor olvassuk el a et. A &os; mint gazda Jelenleg a &os;-t hivatalosan egyik virtualizációs programcsomag sem támogatja gazda operációs rendszerként, de sokan használják a VMware régebbi verzióit ilyen megfontolásból. Emellett már dolgoznak azon, hogy a &xen; rendszert felkészítsék a &os; alatti mûködésre.