diff --git a/hu_HU.ISO8859-2/books/handbook/cutting-edge/chapter.sgml b/hu_HU.ISO8859-2/books/handbook/cutting-edge/chapter.sgml index a7f99fd985..bf313d7693 100644 --- a/hu_HU.ISO8859-2/books/handbook/cutting-edge/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/cutting-edge/chapter.sgml @@ -1,2626 +1,2627 @@ Jim Mock Átdolgozta, átrendezte és egyes részeit aktualizálta: Jordan Hubbard Eredetileg írta: Poul-Henning Kamp John Polstra Nik Clayton Az élvonal Áttekintés A &os; a kiadások közt is állandó fejlõdésben van. A legfrissebb fejlesztések elérésének számos egyszerû eszköze áll rendelkezésre mindazok számára, akik az élvonalban kívánnak lenni. Azonban vigyázzunk — ez az élvonal nem való ám mindenkinek! Ebben a fejezetben segítünk dönteni a fejlesztõi változat és a kiadások használata között. A fejezet elolvasása során megismerjük: a két fejlesztõi ág, a &os.stable; és a &os.current; közti különbséget; hogyan tartsuk naprakészen rendszerünket a CVSup, CVS, vagy CTM használatával; a make buildworld (stb.) segítségével hogyan fordítsuk és telepítsük újra az egész alaprendszert. A fejezet elolvasásához ajánlott: a hálózati kapcsolatunk helyes beállítása (); a külsõ szoftverek telepítésének ismerete (). &os.current; kontra &os.stable; -CURRENT -STABLE A &os;-nek két fejlesztési ága van: a &os;.current és a &os.stable;. Ebben a szakaszban mindegyikükrõl monduk pár szót, és megmutatjuk, miként lehet az adott ághoz igazítani a rendszerünk frissítését. Elõször a &os.current;, majd a &os.stable; változata kerül tárgyalásra. A &os; friss változatának használata Ahogy arról már az imént is szó esett, nem szabad elfelejtenünk, hogy a &os.current; a &os; fejlesztésének frontvonala. Emiatt a &os.current; használóinak szakmailag jólképzetteknek kell lenniük, és sosem szabad visszariadniuk a használat közben felmerülõ rendszerszintû problémák önálló megoldásától. Ha korábban még nem foglalkoztunk &os;-vel, kétszer is gondoljuk meg a telepítését! Mi a &os.current;? pillanatkép A &os.current; a &os; mögött álló legfrissebb forráskódot képviseli. Itt találkozhatunk különféle olyan fejlesztés alatt álló részekkel, kísérletezésekkel és átmeneti megoldásokkal, amelyek nem feltétlenül kerülnek bele a szoftver következõ hivatalos kiadásába. Noha a &os; fejlesztõi a &os.current; forráskódját naponta fordítják, adódhatnak olyan idõszakok, amikor a források mégsem használhatóak maradéktalanul. Az ilyen gondokat általában a lehetõ leggyorsabban igyekeznek megoldani, azonban attól függõen, hogy éppen a forráskód melyik verzióját sikerült kifogni, a &os.current; használata kész katasztrófa vagy akár a fejlõdésben igazi továbblépés is lehet. Kinek van szüksége a &os.current;-re? A &os.current; használata elsõsorban az alábbi 3 csoportot érinti: A &os; közösség azon tagjait, akik aktívan dolgoznak a forrásfa valamelyik részén, és mindazokat, akik számára a legfrissebb verzió használata feltétlen elvárás. A &os; közösség azon tagjait, akik aktívan tesztelnek, és a &os.current; kordában tartásához hajlandóak idõt áldozni a menet közben felbukkanó problémák megoldására. Vannak olyanok is, akik a &os; változásaival és fejlesztési irányával kapcsolatban kívánnak javaslatokat tenni, melyeket javítások és módosítások formájában tesznek közzé. Mindazokat, akik pusztán kíváncsiak a fejlesztésben zajló eseményekre, vagy hivatkozási szándékkal töltik le a legfrissebb forrásokat (például csak nézegetik, de nem futtatják). Az ilyen emberek esetenként megjegyzéseket fûznek a fejlesztéshez vagy kódot küldenek be. Mi <emphasis>nem</emphasis> a &os.current;? Az olyan kiadás elõtt álló funkciók kipróbálásának egyszerû módja, amelyekrõl hallottunk, hogy milyen remek újdonságokat hoznak és mi akarunk lenni az elsõk, akik ezt használni is fogják. Ne feledjük azonban, hogy amikor mindenki elõtt kezdünk el használni egy újítást, mi leszünk egyben az elsõk is, akik szembesülnek a benne rejlõ hibákkal. A gyors hibajavítások eszköze. A &os.current; szinte bármelyik változata pontosan ugyanakkora valószínûséggel hoz magával új hibákat, mint ahogy eltünteti a régieket. Akármilyen értelemben is hivatalosan támogatott. Képességeinktõl függõen õszintén igyekszünk a lehetõ legtöbbet megtenni a 3 törvényes &os.current; csoportba tartozó emberekért, azonban egyszerûen nincs idõnk komolyabb segítségnyújtást adni. Ez viszont nem azt jelenti, hogy komisz és fukar emberek vagyunk, akik utálnak segíteni a másiknak (de máskülönben nem tudna fejlõdni a &os;). Csupán a &os; fejlesztése közben fizikailag képtelenek vagyunk a naponta érkezõ ezernyi üzenetet rendre megválaszolni! A &os; elõremozdítása és a kísérleti stádiumban álló kóddal kapcsolatos kérdések megválaszolása közül a fejlesztõk általában az elsõt részesítik elõnyben. A &os.current; használata -CURRENT használata Iratkozzunk fel az &a.current.name; és &a.cvsall.name; listákra. Ez nem egyszerûen hasznos, hanem elengedhetetlen. Ha nem vagyunk a &a.current.name; listán, akkor nem fogjuk látni a rendszer aktuális állapotára vonatkozó megjegyzéseket, és így esetleg feleslegesen öljük az idõnket olyan problémák megoldásába, amelyeket mások már korábban megoldottak. Ami viszont ennél is fontosabb, hogy így elszalasztjuk a rendszerünk folyamatos életbentartására vonatkozó létfontosságú bejelentéseket. A &a.cvsall.name; listán láthatjuk az a forráskód egyes változtatásaihoz tartozó naplóbejegyzéseket, a hozzájuk tartozó esetleges mellékhatások ismertetésével együtt. A listákra vagy a &a.mailman.lists.link; oldalon található többi lista valamelyikére úgy tudunk feliratkozni, ha rákattintunk a nevére. A további lépésekrõl ezt követõen itt kapunk értesítést. A tükrözések egyikérõl töltsük le a &os; forrását. Erre két mód is kínálkozik: cvsup cron -CURRENT frissítés CVSuppal Használjuk a cvsup programot a /usr/share/examples/cvsup könyvtárban található standard-supfile állománnyal. Ez a leginkább ajánlott módszer, hiszen így csak egyszer kell letölteni az egész gyûjteményt, majd ezután már csak a változásokat. Sokan a cvsup parancsot a cron parancson keresztül adják ki, és ezzel mindig automatikusan frissítik a forrásaikat. A cvsup mûködését a fentebb említett minta supfile állomány megfelelõ módosításával tudjuk a saját környezetünkhöz igazítani. -CURRENT frissítés CTM-mel Használjuk a CTM alkalmazás nyújtotta lehetõségeket. Amennyiben nagyon rossz netkapcsolattal rendelkezünk (drága vagy csak levelezésre használható) a CTM megoldást jelenthet számunkra. Legyünk azonban tekintettel arra, hogy helyenként zûrös lehet a használata és néha hibás állományokat gyárt. Emiatt viszont csak ritkán használják, így elõfordulhat, hogy hosszabb ideig nem is mûködik. A 9600 bps vagy annál nagyobb sebességû kapcsolatok esetén ezért inkább a CVSup használatát javasoljuk. Ha nem csak böngészésre, hanem fordításra is szedjük a forrásokat, mindig töltsük le a &os.current; egészét, ne csak egyes részeit. Ez azzal magyarázandó, hogy a forráskód bizonyos részei más helyeken található részektõl is függenek, és ezért az önálló fordításuk szinte garantáltan gondot fog okozni. -CURRENT fordítása A &os.current; lefordítása elõtt figyelmesen olvassuk át a /usr/src könyvtárban található Makefile állományt. A frissítési folyamat részeként elõször mindenképpen érdemes telepíteni egy új rendszermagot és újrafordítani az alaprendszert. Olvassuk el a &a.current; üzeneteit és a /usr/src/UPDATING állományt, ahol megtalálhatjuk az ezzel kapcsolatos legújabb információkat, melyek egy-egy újabb kiadás közeledtével egyre fontosabbá válnak. Foglalkozzunk vele! Ha már a &os.current; változatát használjuk, ne legyünk restek véleményt formálni róla, különösen abban az esetben, ha továbbfejlesztésekrõl vagy hibákra van szó. Leginkább a forráskóddal együtt érkezõ javaslatoknak szoktak örülni a fejlesztõk! A &os; stabil változatának használata Mi a &os.stable;? -STABLE A &os.stable; az a fejlesztési ág, ahonnan az egyes kiadások származnak. Ebbe az ágba már más ütemben kerülnek a változások, mivel általánosan elfogadott, hogy ide a korábban már kipróbált módosítások vándorolnak át a &os.current; ágból. Ez azonban még mindig csak egy fejlesztési ág, ami arra utal, hogy a &os.stable; által adott pillanatban képviselt források nem feltétlenül felelnek meg bizonyos célokra. Ez csupán egy újabb fejlesztési nyomvonal, nem pedig a végfelhasználók kenyere. Kinek van szüksége a &os.stable;-re? Ha szeretnénk figyelemmel kísérni vagy valamilyen módon kiegészíteni a &os; fejlesztési folyamatát, különösen a &os; következõ nagyobb kiadását illetõen, akkor érdemes követnünk a &os.stable; forrásait. Habár a &os.stable; ágba is bekerülnek a biztonsági jellegû javítások, ettõl még nem kell feltétlenül ezt követnünk. A &os;-hez kiadott biztonsági figyelmeztetések mindig leírják, hogyan kell javítani a hibát az érintett kiadásokban Ez azért nem teljesen igaz. A régebbi &os; kiadásokat ugyan nem támogathatjuk a végtelenségig, de általában így is több évig foglalkozunk velük. A &os; régebbi kiadásaival kapcsolatos jelenleg érvényes biztonsági házirend részletes bemutatása a http://www.FreeBSD.org/security/ oldalon olvasható (angolul). , azonban az egész fejlesztési ágat felesleges csak biztonsági okból kifolyólag követni, mivel így olyan változások is kerülhetnek a rendszerbe, amire nincs szükségünk. Habár igyekszünk gondoskodni a &os.stable; ágban található források lefordíthatóságáról és mûködõképességérõl, nem minden esetben szavatolható. Ráadásul mivel a &os.stable; ágba kerülõ kódokat elõször a &os.current; ágban fejlesztik ki, és mivel a &os.stable; felhasználói többen vannak a &os.current; változaténál, ezért szinte elkerülhetetlen, hogy ilyenkor a &os.stable; változatban bizonyos hibák és szélsõséges esetek be ne következzenek, amelyek a &os.current; használata során még nem buktak ki. Ezért a &os.stable; ág vakon követését senkinek sem ajánljuk, és különösen fontos, hogy éles szervereken elõzetes kimerítõ tesztelések nélkül ne futassunk &os.stable; rendszert. Ha ehhez nem rendelkezünk elegendõ erõforrással, akkor egyszerûen használjuk a &os; legfrissebb kiadását, és az egyes kiadások között pedig bináris frissítéssel közlekedjünk. A &os.stable; használata -STABLE használata Iratkozzunk fel a &a.stable.name; listára. Ezen keresztül értesülhetünk a &os.stable; használata során felmerülõ fordítási függõségekrõl vagy más, külön figyelmet igénylõ problémákról. Gyakran ezen a levelezési listán elmélkednek a fejlesztõk a vitatott javításokról vagy frissítésekrõl, amibe a felhasználók is beleszólhatnak, ha a szóbanforgó változtatással kapcsolatban bármilyen problémájuk vagy ötletünk van. A &a.cvsall.name; lista segítségével elolvashatjuk az egyes változtatásokhoz tartozó naplóbejegyzéseket, a rájuk vonatkozó esetleges mellékhatások ismertetésével együtt. Ezekre, valamint a &a.mailman.lists.link; címen elérhetõ listák valamelyikére úgy tudunk feliratkozni, ha a nevükre kattintunk. A további teendõk ezután itt jelennek meg. Amennyiben egy új rendszert akarunk telepíteni és a &os.stable; havonta készült pillanatképeit akarjuk rajta futtatni, akkor errõl bõvebb felvilágosítást a Pillanatképek honlapján találhatunk (angolul). Emellett a legfrissebb &os.stable; kiadást telepíthetjük a tükrözések valamelyikérõl is, majd innen a lentebb található utasítások szerint tudunk hozzáférni a &os.stable; forráskódjának legfrissebb változatához. Ha már fut a gépünkön a &os; egy korábbi kiadása, és ezt akarjuk forráson keresztül frissíteni, akkor ezt a &os; tükrözéseivel könnyedén megtehetjük. Két módon is: cvsup cron -STABLE frissítés CVSuppal Használjuk a cvsup programot a /usr/share/examples/cvsup könyvtárból származó stable-supfile állománnyal. Ez a leginkább ajánlott módszer, mivel így csak egyszer kell letölteni a teljes gyûjteményt, utána már csak a hozzátartozó változtatásokra van szükségünk. A cvsup parancsot sokan a cron segítségével futtatják, és ezzel automatikusan frissülnek a forrásainak. A cvsup mûködését környezetünkhöz az elõbb említett minta supfile megfelelõ módosításával tudjuk behangolni. -STABLE frissítés CTM-mel Használjuk a CTM programot. Ha nincs olcsó vagy gyors internetkapcsolatunk, akkor érdemes ezt a módszert választani. Alapvetõen azonban ha gyorsan szeretnénk hozzájutni a forrásokhoz és a sávszélesség nem meghatározó tényezõ, akkor helyette válasszuk a cvsup vagy az ftp használatát, és csak minden más esetben CTM-et. -STABLE fordítása Mielõtt lefordítanánk a &os.stable; változatát, figyelmesen olvassuk át a /usr/src könyvtárban levõ Makefile állományt. Az átállási folyamat részeként elõször minden bizonnyal telepítenünk kell egy új rendszermagot és újra kell fordítanunk az alaprendszert. A &a.stable; valamint a /usr/src/UPDATING elolvasásából értesülhetünk azokról az egyéb, gyakran nagyon fontos változásokról, melyek elengedhetetlenek lesznek a következõ kiadás használatához. A forrás szinkronizálása Az internet (vagy elektronikus levelek) használatán keresztül számos mód kínálkozik az &os; Projekthez tartozó források frissen tartásához egy adott, vagy éppen az összes területen attól függõen, hogy mik érdekelnek minket. Ehhez elsõsorban az Anonim CVS, CVSup és CTM szolgáltatásokat ajánljuk fel. Habár lehetséges csupán a forrásfa egyes részeit letölteni, a támogatott frissítési eljárás során azonban szükségünk lesz az egész fa szinkronizálására és a rendszerhez tartozó felhasználói programok (vagyis minden olyan program, amely a felhasználói térben fut, ilyeneket találhatunk többek közt a /bin és /sbin könyvtárakban) valamint rendszermag újrafordítására is. Ha csak a felhasználói programok forrásait, vagy csak a rendszermagot, esetleg csupán a forrásfa egyes részeit frissítjük, akkor az gondokat okozhat. Az itt elõforduló problémák fordítási hibáktól kezdve rendszerösszeomlásokon keresztül akár adatvesztésbe is torkollhatnak. CVS anonim Az Anonim CVS és a CVSup alkalmazások ún. lehúzással frissítik a forrásokat. A CVSup használatakor a felhasználó (vagy a cron szkript) meghívja a cvsup programot, amely az állományok aktualizálásához felveszi a kapcsolatot egy máshol megtalálható cvsupd szerverrel. Az így nyert frissítések az adott pillanatig visszemenõleg érkeznek meg, de csak akkor, ha igényeljük ezeket. A frissítést könnyedén le tudjuk szabályozni a számunkra érdekes egyes állományokra és könyvtárakra. A frissítéseket a szerver hozza létre menet közben annak megfelelõen, hogy milyen verziókkal rendelkezünk, és mihez akarunk szinkronizálni. Az Anonim CVS a CVSupnál valamivel egyszerûbb abban a tekintetben, hogy ez a CVS-nek egy olyan kiterjesztése, amely lehetõvé teszi a változtatások közvetlen lehúzását egy távoli CVS tárházból. Miközben a CVSup mindezt sokkal hatékonnyabb valósítja meg, addig az Anonim CVS jóval könnyebben használható. CTM Velük szemben a CTM nem hasonlítja össze interaktívan a saját és a központi szerveren tárolt forrásokat és nem is húzza át ezeket. Ehelyett egy olyan szkriptõl van szó, amely naponta többször megvizsgálja a központi CTM szerveren tárolt állományok a legutóbbi futtatás óta keletkezett változtatásait, majd az észlelt módosulásokat betömöríti, felcímkézi egy sorozatszámmal és (nyomtatható ASCII formátumban) elõkészíti ezeket az e-mailen keresztüli küldésre. Az így létrehozott CTM delták megérkezésük után a &man.ctm.rmail.1; segédprogrammal kerülnek feldolgozásra, amely magától visszaalakítja, ellenõrzi és alkalmazza a változtatásokat a forrásfa felhasználó birtokában levõ másolatára. Ez a megoldás hatékonyabb a CVSup használatánál, mert kisebb terhelést jelent a szerverek számára, hiszen a frissítéshez nem a lehúzást, hanem a küldést alkalmazzák. Természetesen minden említett eljárásnak megvannak a maga kompromisszumai. Ha véletlenül kitöröljük a forrásfánk egyes részeit, a CVSup képes ezt észrevenni és helyreállítani a sérült részeket. A CTM ezzel szemben ezt nem végzi el, szóval ha (biztonsági mentés nélkül) letöröljük a forrásainkat, akkor az egész szinkronizálást az elejérõl kell kezdenünk (pontosabban a legfrissebb CVS-es alapdeltától) és a CTM-mel újraépíteni az egészet, esetleg a Anonim CVS-sel letörölni a hibás adatokat és újraszinkronizálni. Az alaprendszer újrafordítása az alaprendszer újrafordítása Miután sikerült a helyi forrásfánkat a &os; egy nekünk szimpatikus (&os.stable;, &os.current; és így tovább) változatához igazítanunk, elérkezett az idõ, hogy a segítségével újrafordítsuk az egész rendszert. Készítsünk biztonsági mentést Nem tudjuk eléggé nyomatékosítani, hogy mielõtt nekikezdenénk, készítsünk egy biztonsági mentést a rendszerünkrõl. Míg az alaprendszer újrafordítása nem túlságosan bonyolult feladat (egészen addig, amíg a megadott utasításokat követjük), saját magunk vagy mások hibájából fakadóan kialakulhatnak olyan helyzetek, amikor a rendszer nem lesz képes elindulni. Mindenképpen gyõzödjünk meg róla, hogy tisztességesen elvégeztük a mentést és akad a kezünk ügyében egy javításra felhasználható rendszerindító floppy vagy CD. Valószínûleg soha nem lesz ténylegesen szükségünk rájuk, azonban jobb félni, mint megijedni! Iratkozzunk fel a megfelelõ levelezési listákra levelezési lista A &os.stable; és &os.current; ágak természetüknél fogva fejlesztés alatt állnak. A &os; fejlesztését is emberek végzik, ezért elõfordulhatnak benne tévedések. Ezek a tévedések gyakran csak ártalmatlan apróságok, amelyek hatására kapunk például egy ismeretlen diagnosztikai hibát. De ezzel szemben létrejöhetnek pusztító erejû hibák is, amelyek hatására a rendszerünk nem lesz képes elindulni, károsodnak az állományrendszerek (vagy még rosszabb). Ha ilyen történik, akkor egy felszólítást (egy heads up témájú üzenetet) küldenek az érintett változatokhoz tartozó listákra, amelyben igyekeznek kifejteni a probléma természetét és a rendszerre mért hatását. Miután minden rendbejött, a probléma megoldásáról is küldenek egy értesítést. Ha a &a.stable; vagy a &a.current; olvasása nélkül próbáljuk meg használni a &os.stable; és &os.current; verziókat, akkor csak magunknak keressük a bajt. Ne használjuk a <command>make world</command> parancsot Rengeteg régebben készült dokumentáció erre a feladatra a make world parancs kiadását javasolja. Ennek használatával azonban átlépünk olyan fontos lépéseket, amelyek valójában csak akkor lennének kihagyhatóak, ha pontosan tudjuk mit csinálunk. Ezért az esetek döntõ többségében nem a make world használatára van szükségünk, hanem a most bemutatandó eljárásra. A rendszer frissítése dióhéjban A frissítés megkezdése elõtt érdemes elolvasnunk a /usr/src/UPDATING állományt, ahol a letöltött források használatához elvégzendõ elõzetes intézkedésekrõl kaphatunk hírt. Ezután adjuk ki az alábbi utasításokat: &prompt.root; make buildworld &prompt.root; make buildkernel &prompt.root; make installkernel &prompt.root; reboot Néhány ritka esetben a buildworld lépés elõtt szükségünk lehet a mergemaster -p parancs lefuttatására is. Errõl az UPDATING állományból tudakozódhatunk. Általában azonban nyugodt szívvel kihagyhatjuk ezt a lépést, kivéve, ha nem egy vagy több fõbb &os; változatot átívelõ frissítést végzünk. Miután az installkernel sikeresen befejezte a munkáját, indítsuk újra a számítógépet egyfelhasználós módban (a betöltõ parancssorában adjuk ki boot -s parancsot). Itt futtassuk a következõket: &prompt.root; mergemaster -p &prompt.root; make installworld &prompt.root; mergemaster &prompt.root; reboot Olvassuk el a magyarázatokat Az iménti leírt folyamat csupán rövid összefoglalás, amivel némi gyorstalpalást igyekeztünk adni. Az egyes lépések megértéséhez azonban javasolt átolvasni a most következõ szakaszokat is, különösen abban az esetben, ha saját rendszermagot akarunk használni. Nézzük meg a <filename>/usr/src/UPDATING</filename> állományt Mielõtt bármihez is nekifognánk, keressük meg a /usr/src/UPDATING (vagy hasonló, a forráskód másolatunk tényleges helyétõl függõ) állományt. Ebben adják hírül az esetlegesen felmerülõ problémákra vonatkozó fontosabb információkat, vagy határozzák meg az egyes lefuttatandó parancsok pontos sorrendjét. Amennyiben az UPDATING ellentmondana az itt olvasottaknak, az UPDATING tartalma a mérvadó. A korábban tárgyaltak szerint az UPDATING elolvasása nem helyettesíti a megfelelõ levelezési listák figyelemmel kísérését. Ez a két elvárás nem kizárja, hanem kiegészíti egymást. Ellenõrizzük az <filename>/etc/make.conf</filename> állományt make.conf Vizsgáljuk át a /usr/share/examples/etc/make.conf és az /etc/make.conf állományokat. Az elõbbi tartalmaz néhány alapértelmezett beállítást – ezek javarészét megjegyzésbe rakták. Ha használni akarjuk a rendszer lefordítása során, tegyük bele ezeket az /etc/make.conf állományba. Ne felejtsük el azonban, hogy minden, amit megadunk az /etc/make.conf állományba, a make minden egyes elindításakor felhasználásra kerül. Éppen ezért olyanokat érdemes itt beállítani, amik az egész rendszerünket érintik. A legtöbb felhasználó számára az /etc/make.conf állományhoz a /usr/share/examples/etc/make.conf állományban található CFLAGS és NO_PROFILE sorokra lesz szüksége, melyeket kivehetünk a megjegyzésbõl. A többi definíció (COPTFLAGS, NOPORTDOCS és így tovább) használatáról már mindenki maga dönt. Frissítsük az <filename>/etc</filename> tartalmát Az /etc könyvtár tartalmazza a rendszer beállításaival kapcsolatos információk jelentõs részét, valamint a rendszer indítása során lefutó szkripteket. Egyes szkriptek a &os; verzióiról verzióira változnak. Némely konfigurációs állományok a rendszer hétköznapi mûködésében is szerepet játszanak. Ilyen például az /etc/group. Alkalmanként a make installworld parancs futása során igényt tart adott nevû felhasználókra és csoportokra. A frissítéskor azonban ezek a felhasználók vagy csoportok nem feltétlenül állnak rendelkezésre, ami gondokat okozhat. Ezért bizonyos esetekben a make buildworld elõzetesen ellenõrzi az igényelt felhasználók és csoportok meglétét. Erre például szolgálhat a smmsp felhasználó esete. Nélküle a felhasználók nem tudták telepíteni az új rendszert, mert hiányában az &man.mtree.8; nem volt képes létrehozni a /var/spool/clientmqueue könyvtárat. Ezt úgy lehetett megoldani, hogy még az alaprendszer lefordítása (a buildworld) elõtt meg kellett hívni a &man.mergemaster.8; parancsot a paraméterrel. Így csak azokat az állományokat fogja összehasonlítani, amelyek feltétlenül szükségesek a buildworld vagy az installworld sikeres mûködéséhez. Amennyiben a mergemaster egy olyan verziójával rendelkezünk, amely nem ismeri a paramétert, akkor az elsõ indításakor használjuk a forrásfában található újabb verzióját: &prompt.root; cd /usr/src/usr.sbin/mergemaster &prompt.root; ./mergemaster.sh -p Ha különösen paranoiásak vagyunk, akkor a csoport törlése vagy átnevezése elõtt az alábbi paranccsal ellenõrizni tudjuk az általa birtokolt állományokat: &prompt.root; find / -group GID -print Ez megmutatja GID (mely megadható numerikus vagy név formájában is) jelzésû csoporthoz tartozó összes állományt a rendszerünkben. Váltsunk egyfelhasználós módba egyfelhasználós mód A rendszert egyfelhasználós módban érdemes lefordítani. A nyilvánvalóan érezhetõ gyorsaság elõnyei mellett azért is jobban járunk, mert az új rendszer telepítése során számos rendszerszintû állomány is módosításra kerül, beleértve a szabványos rendszerszintû binárisokat, függvénykönyvtárakat, include állományokat és így tovább. Ha üzemelõ rendszeren végezzük el mindezen változtatásokat (különösen amikor rajtunk kívül még további felhasználók is tartózkodnak a rendszerben), az csak a bajt hozza ránk. többfelhasználós mód Másik lehetõség gyanánt a rendszert magát lefordíthatjuk többfelhasználós módban is, majd ezután csak a telepítést hajtjuk végre egyfelhasználós üzemmódban. Ha eszerint cselekszünk, egyszerûen várjunk addig, amíg az összes fordítás be nem fejezõdik, és az egyfelhasználósra váltást halasszuk a installkernel vagy installworld idejére. Egy mûködõ rendszerben rendszeradminisztrátorként az alábbi parancs kiadásával válthatunk át egyfelhasználós módba: &prompt.root; shutdown now Ezt elérhetjük úgy is, ha újraindítjuk a rendszert és a rendszer indításakor a single user pontot választjuk a menübõl. Ekkor a rendszer egyfelhasználós módban indul el. Miután ez megtörtént, adjuk ki a következõ parancsokat: &prompt.root; fsck -p &prompt.root; mount -u / &prompt.root; mount -a -t ufs &prompt.root; swapon -a Ezekkel a parancsokkal elõször ellenõrizzük az állományrendszereket, ezután újracsatlakoztatjuk a / állományrendszert írható módban, csatlakoztatjuk az /etc/fstab állományban megadott összes többi UFS típusú állományrendszert, majd bekapcsoljuk a lapozóállomány használatát. Ha a gépünk óráját nem a greenwich-i, hanem a helyi idõ szerint állítottuk be (ez akkor áll fenn, ha a &man.date.1; parancs nem a helyes idõt és idõzónát jelzi ki), akkor még erre is szükségünk lehet: &prompt.root; adjkerntz -i Ezzel a helyi idõzóna beállításait tudjuk jól beállítani — nélküle késõbb még gondjaink akadhatnak. Töröljük a <filename>/usr/obj</filename> könyvtárat A rendszer egyes részei fordításuk során a /usr/obj könyvtáron belülre kerülnek (alapértelmezés szerint). Az itt található könyvtárak a /usr/src könyvtárszerkezetét követik. Ha mindenestõl töröljük ezt a könyvtárat, akkor növeli tudjuk a make buildworld folyamat sebességét és megmenekülünk néhány függõségekkel kapcsolatos fejfájástól is. Egyes /usr/obj könyvtáron belüli állományoknál szerepelhet a megváltoztathatatlan (immutable) állományjelzõ (lásd &man.chflags.1;), amelyet a mûvelet elvégzéséhez elõször el kell távolítanunk. &prompt.root; cd /usr/obj &prompt.root; chflags -R noschg * &prompt.root; rm -rf * Fordítsuk újra az alaprendszert A kimenet elmentése Jól járunk azzal, ha a &man.make.1; futásának kimenetét elmentjük egy állományba, mivel így a hibák esetén lesz egy másolatunk a hibaüzenetrõl. Ha konkrétan nekünk nem is feltétlenül segít megtalálni a hiba tényleges okát, mások viszont többet tudnak róla mondani, ha beküldjük ezt a &os; egyik levelezési listájára. Ezt egyébként a legegyszerûbben a &man.script.1; parancs segítségével oldhatjuk meg, amelynek paraméteréül azt az állományt kell megadni, ahova menteni akarjuk a kimenetet. Ezt közvetlenül a rendszer újrafordítása elõtt kell kiadnunk, majd miután megállt, a exit paranccsal kiléphetünk belõle. &prompt.root; script /var/tmp/mw.out Script started, output file is /var/tmp/mw.out &prompt.root; make TARGET … fordít, fordít, fordít … &prompt.root; exit Script done, … Ilyenkor soha ne a /tmp könyvtárba mentsük a kimenetet, mert ennek a tartalma a következõ indítás során magától törlõdik. Sokkal jobban tesszük, ha a /var/tmp könyvtárba (ahogy tettük azt az elõbbi példában is) vagy a root felhasználó könyvtárába mentünk. Az alaprendszer fordítása A /usr/src könyvtárban kell állnunk: &prompt.root; cd /usr/src (kivéve természetesen, ha máshol van a forráskód, akkor abba a könyvtárba menjünk). make Az alaprendszert a &man.make.1; paranccsal fordíthatjuk újra. Ez a Makefile nevû állományból olvassa be a &os; programjainak újrafordítását leíró utasításokat, a fordításuk sorrendjét és így tovább. A begépelendõ paranccsor általános alakja tehát a következõképpen néz ki: &prompt.root; make -x -DVÁLTOZÓ target A fenti példában a egy olyan a paraméter, amelyet a &man.make.1; programnak adunk át. A &man.make.1; man oldalán megtalálhatjuk az összes neki átadható ilyen beállítást. A alakú paraméterek közvetlenül a Makefile állománynak adnak át olyan változókat, amelyek segítségével vezérelhetõ a viselkedése. Ezek ugyanazok a változók, mint amelyek az /etc/make.conf állományban is szerepelnek, és itt a beállításuk egy másik módját kapjuk. Így a &prompt.root; make -DNO_PROFILE target paranccsal is megadhatjuk, hogy ne profilozott függkönyvtárak jöjjenek létre, ami pontosan megfelel a NO_PROFILE= true # Avoid compiling profiled libraries sornak az /etc/make.conf állományban. A target árulja el a &man.make.1; programnak, hogy mi a teendõje. Minden egyes Makefile különbözõ targeteket definiál, és a kiválasztott target mondja meg, pontosan mi is fog történni. Egyes targetek ugyan megjelennek a Makefile állományban, azonban nem feltétlenül hivatkozhatunk rájuk közvetlenül. Ehelyett csupán arra valók, hogy a fordítás folyamatának lépéseit felbontsák még kisebb allépésekre. A legtöbb esetben azonban semmilyen paramétert nem kell átadnunk a &man.make.1; parancsnak, ezért a teljes formája így fog kinézni: &prompt.root; make target ahol a target az egyik fordítási lehetõséget képviseli. Az elsõ ilyen targetnek mindig a buildworld-nek kell lennie. Ahogy a neve is mutatja, a buildworld lefordítja az összes forrást a /usr/obj könyvtárba, majd a installworld mint másik target, telepíti az így létrehozott elemeket a számítógépre. A targetek szétválasztása két okból is elõnyös. Elõször is lehetõvé teszi, hogy az új rendszert biztonságban lefordíthassuk, miközben az a jelenleg futó rendszert nem zavarja. A rendszer tehát képes saját magát újrafordítani. Emiatt a buildworld target akár többfelhasználós módban is mindenféle nem kívánatos hatás nélkül használható. Ennek ellenére azonban továbbra is azt javasoljuk, hogy a installworld részt egyfelhasználós módban futtassuk le. Másodrészt ezzel lehetõségünk nyílik NFS állományrendszer alkalmazásával több számítógépre is telepíteni hálózaton keresztül. Ha például három frissítendõ számítógépünk van, az A, B és C, akkor az A gépen elõször adjuk ki a make buildworld, majd a make installworld parancsot. A B és C gépek ezután NFS segítségével csatlakoztatják az A /usr/src és /usr/obj könyvtárait, amelyet követõen a make installworld paranccsal telepíteni tudjuk a fordítás eredményét a B és C gépekre. Noha a world mint target még mindig létezik, használata határozottan ellenjavalt. A &prompt.root; make buildworld parancs kiadásakor a make parancsnak megadható egy paraméter is, amellyel párhuzamosíthatjuk a folyamat egyes részeit. Ez általában többprocesszoros számítógépeken nyer értelmet, azonban mivel a fordítás folyamatának haladását inkább az állománymûveletek mintsem a processzor sebessége korlátozza, ezért alkalmazható akár egyprocesszoros gépeken is. Tehát egy átlagos egyprocesszoros gépen így adható ki a parancs: &prompt.root; make -j4 buildworld Ennek hatására &man.make.1; egyszerre 4 szálon igyekszik mûködni. A levelezési listákra beküldött tapasztalati jellegû bizonyítékok azt igazolják, hogy általában ez a beállítás adja a legjobb teljesítményt. Ha többprocesszoros géppel rendelkezünk és rajta SMP támogatású rendszermagot indítottunk el, akkor érdemes 6 és 10 közötti értékekkel kísérleteznünk. Idõigény az alaprendszer újrafordítása idõigény Számos tényezõ befolyásolja a fordítás tényleges idõbeli hosszát, de a &os.stable; fa lefordítása mindenféle trükkök és rövidítések nélkül a legtöbb számítógépen olyan egy vagy két órára taksálható. A &os.current; fához ennél valamivel több idõre lesz szükségünk. Fordítsunk és telepítsünk egy új rendszermagot rendszermagot fordítása Az újdonsült rendszerünket csak akkor tudjuk igazán kihasználni, ha egy új rendszermagot is készítünk hozzá. Ez gyakorlati szinten tulajdonképpen elvárás, mivel könnyen elõfordulhat, hogy bizonyos memóriabeli adatszerkezetek felépítése megváltozott, ezért némely programok, mint például a &man.ps.1; és &man.top.1;, egészen addig nem lesznek képesek normálisan mûködni, amíg a rendszer és a rendszermag forráskódja nem illeszkedik egymáshoz. Ennek legegyszerûbb és egyben legbiztonságosabb módja, ha a GENERIC beállításai alapján gyártunk és telepítünk egy rendszermagot. Még ha a GENERIC beállításai nem is tartalmazzák a rendszerünkben fellelhetõ összes eszközt, minden megtalálható bennük ahhoz, hogy a rendszert sikeresen elindíthassuk legalább egyfelhasználós módban. Ez mellesleg remek próbája az új rendszer életképességének. Miután elindítottuk a rendszert a GENERIC típusú rendszermaggal és meggyõzõdtünk róla, hogy a rendszer tényleg mûködõképes, a megszokott rendszermagunk konfigurációs állománya alapján nyugodtan elkészíthetjük ezután azt is. &os; alatt egy új rendszermag építése elõtt fontos újrafordítani az alaprendszert. Ha saját beállításaink szerint akarunk rendszermagot létrehozni és már van is ehhez egy konfigurációs állományunk, akkor erre használhatjuk a KERNCONF=SAJÁTMAG paramétert is, valahogy így: &prompt.root; cd /usr/src &prompt.root; make buildkernel KERNCONF=SAJÁTMAG &prompt.root; make installkernel KERNCONF=SAJÁTMAG Hozzátennénk, hogy ha a kern.securelevel rendszerváltozó értékét 1 felé állítottuk és a rendszermag állományának beállítottunk noschg vagy hozzá hasonló állományjelzõt, akkor az installkernel lefuttatásához mindenképpen egyfelhasználós módba kell váltanunk. Minden más esetben további bonyodalmak nélkül ki tudjuk adni az említett parancsokat. A kern.securelevel részleteirõl az &man.init.8; oldalán, a különbözõ állományjelzõkrõl pedig a &man.chflags.1; oldalán olvashatunk. Indítsuk újra a rendszert egyfelhasználós módban egyfelhasználós mód Az új rendszermag mûködésének leteszteléséhez indítsuk újra a rendszert egyfelhasználós módban. Ennek pontos részleteit lásd . Telepítsük az új rendszer binárisait Ha a &os; friss változatát nemrég fordítottuk le a make buildworld paranccsal, akkor utána az installworld segítségével tudjuk telepíteni a keletkezett programokat. Tehát írjuk be ezeket: &prompt.root; cd /usr/src &prompt.root; make installworld Amennyiben a paranccsorban a make buildworld használata során adtunk meg változókat, akkor ne felejtsük el ugyanazokat megadni a make installworld kiadása során sem. Ez viszont a többi paraméterre már nem feltétlenül érvényes. Például a beállítást szigorúan tilos az installworld targettel együtt használni. Ennek megfelelõen tehát ha korábban ezt írtuk be: &prompt.root; make -DNO_PROFILE buildworld akkor így telepítsünk: &prompt.root; make -DNO_PROFILE installworld Máskülönben azokat a profilozott függvénykönyvtárakat próbáljuk meg telepíteni, amelyek a make buildworld futása során nem jöttek létre. Frissítsük a <command>make installworld</command> által kihagyott állományokat Az alaprendszer újrafordítása nem regisztrálja az új vagy megváltozott állományokat bizonyos könyvtárakban (különösen értendõ ez az /etc, /var és /usr esetén). Az ilyen állományokat a legegyszerûbben a &man.mergemaster.8; használatával tarthatjuk karban, de igény szerint akár kézzel is elvégezhetjük a szükséges aktualizálásokat. Függetlenül attól, hogy mit is választunk, mindenképpen készítsünk biztonsági mentést az /etc könyvtárról arra az esetre, ha bármilyen szörnyûség történne. Tom Rhodes Írta: A <command>mergemaster</command> mergemaster A &man.mergemaster.8; segédprogram valójában egy Bourne szkript, amely segít az /etc könyvtárunkban és a forrásfában levõ /usr/src/etc könyvtárban elhelyezkedõ konfigurációs állományok közti eltérések megállapításában. Ezt a módszert ajánljuk arra, hogy összevessük a konfigurációs állományainkat a forrásfában található változataikkal. A használatának megkezdéséhez egyszerûen írjuk be, hogy mergemaster, majd várjunk egy kicsit, amíg a mergemaster létrehoz magának egy átmeneti környezetet a / könyvtárból elindulva és megtölti azt a különbözõ rendszerszintû beállításokat tartalmazó állományokkal. Ezeket az állományokat aztán összehasonlítja a jelenleg érvényben levõ változataikkal. Ilyenkor a köztük talált eltéréseket a &man.diff.1; formátumának megfelelõen módon mutatja meg, ahol a jelöli a hozzáadott vagy módosított sorokat, a pedig a teljesen eltávolítandó vagy cserélendõ sorokat. Errõl a formátumról bõvebben a &man.diff.1; man oldalán találhatunk felvilágosítást. A &man.mergemaster.8; ezt követõen megmutatja az összes olyan állományt, ahol eltérést tapasztalt, és ezen a ponton van lehetõségünk letörölni (delete) az új állományokat (amelyekre itt most ideiglenes állományként hivatkozik), telepíteni (install) a módosítatlan ideiglenes (új) állományt, valamint összefésülni (merge) az ideiglenes (új) és a jelenlegi állományokat, vagy ismét átnézni (view) a &man.diff.1; által jelzett különbségeket. Ha az ideiglenes állomány törlését választjuk, akkor a &man.mergemaster.8; ezt úgy értelmezi, hogy változatlanul meg akarjuk tartani a jelenlegi változatot és törölni az újat. Ezt alapvetõen nem javasoljuk, hacsak tényleg nem látunk valamilyen okot erre. A &man.mergemaster.8; parancssorában a ? begépelésével bármikor kérhetünk segítséget. Ha az állomány kihagyását (skip) választjuk, akkor majd ismét felajánlja, amikor végeztünk az összes többivel. A módosítatlan ideiglenes állomány telepítésének választásával lecseréljük a jelenleg verziót az újra. Ha az aktuális verziót sem változtattuk meg, akkor számunkra ez a legjobb megoldás. Az állományok összefésülésének kiválasztásakor kapunk egy szövegszerkesztõt, benne a két állomány tartalmával. Ilyenkor tudjuk a képernyõn soronként egyeztetni a két állományt, majd a belõlük a megfelelõ részek összeválogatásával kialakítani az eredményt. Ebben a feldolgozási módban az l (mint left, vagyis bal) billentyû lenyomására a bal oldalon látható részt, az r (mint right, vagyis jobb) lenyomására pedig a jobb oldalon látható részt választjuk ki. Az így keletkezõ eredményt ezután egy állományba kerül, amelyet telepíteni tudunk. Ez a megoldás olyan állományok esetében használható, amikor a felhasználó módosított az alapértelmezett beállításokat. Ha a &man.diff.1; szerinti alakban akarjuk átnézni a különbségeket, akkor a &man.mergemaster.8; ugyanúgy megmutatja ezeket, mint a paranccsor megjelenítése elõtt. Miután a &man.mergemaster.8; végigment a rendszerszintû állományokon, további opciókat mutat. Megkérdezheti, hogy újra létre akarjuk-e hozni a jelszavakat tároló állományt (rebuild), illetve a folyamat végén a megmaradt ideiglenes állományok törlésére (remove) vár választ. Az állományok aktualizálása kézzel Ha inkább manuálisan szeretnénk frissíteni, akkor nem másolhatjuk csak egyszerûen át az állományokat a /usr/src/etc könyvtárból a /etc könyvtárba és nem hagyhatjuk ezeket sorsukra. Egyes állományokat elõször telepíteni kell. Ez azért van így, mert a /usr/src/etc könyvtár nem pusztán az /etc könyvtár egyszerû másolata. Ráadásul az /etc könyvtárban vannak olyan állományok, amelyek a /usr/src/etc könyvtárban nem is találhatóak meg. Ha (az ajánlottak szerint) a &man.mergemaster.8; segítségével dolgozunk, nyugodtan átléphetünk a következõ szakaszra. Saját magunk a legegyszerûbben ezt úgy tudjuk megoldani, ha telepítjük az állományokat egy új könyvtárba és ezután nekiállunk változásokat keresni. Az <filename>/etc</filename> meglevõ tartalmának mentése Habár elméletileg magától semmi sem fogja bántani ezt a könyvtárat, azért ettõl függetlenül mindig érdemes biztosra menni. Ezért másoljuk az /etc könyvtár tartalmát egy megbízható helyre. Például: &prompt.root; cp -Rp /etc /etc.old Az itt a rekurzív másolást jelenti, a pedig a dátumok, az állományok és egyebek tulajdoni viszonyainak megõrzését. Az /etc új változatának telepítéséhez szükségünk lesz még további könyvtárakra is. Erre a feladatra a /var/tmp/root tökéletesen megfelel, ahol még létre kell hoznunk néhány alkönyvtárat. &prompt.root; mkdir /var/tmp/root &prompt.root; cd /usr/src/etc &prompt.root; make DESTDIR=/var/tmp/root distrib-dirs distribution Ezzel létrejön a szükséges könyvtárszerkezet és települnek az állományok. Sok üres alkönyvtár is keletkezik a /var/tmp/root könyvtáron belül, ezeket töröljük. Ezt a legkönnyebben így tehetjük meg: &prompt.root; cd /var/tmp/root &prompt.root; find -d . -type d | xargs rmdir 2>/dev/null Ezzel törlõdnek az üres könyvtárak. (A szabvány hibakimenetet átirányítottuk a /dev/null eszközre, és ezzel elnyomtuk a nem üres könyvtárak esetén keletkezõ hibaüzeneteket.) A /var/tmp/root most már tartalmazza az összes olyan állományt, amelyek normális esetben a / könyvtáron belül foglalnak helyet. Ezt követõen nincs más dolgunk, csak végigmenni az itt található állományokon és megállapítani, miben térnek a meglévõektõl. Vegyük észre, hogy a /var/tmp/root könyvtárba telepített állományok némelyikének neve .-tal kezdõdik. Az írás pillanatában ezek csak a /var/tmp/root/ és /var/tmp/root/root/ könyvtárakban található parancsértelmezõhöz tartozó indító állományok lehetnek, habár adódhatnak még ilyenek (attól függõen, mikor olvassuk ezt). Ezért a feldolgozásukhoz ne felejtsük el a ls -a parancsot használni. A &man.diff.1; alkalmazásával legegyszerûbben így tudunk összehasonlítani két állományt: &prompt.root; diff /etc/shells /var/tmp/root/etc/shells Ennek hatására megjelennek az /etc/shells és az új /var/tmp/root/etc/shells állományok közti különbségek. A segítségével gyorsan el tudjuk dönteni, hogy összefésüljük-e a két állományt, vagy csak egyszerûen írjuk felül a régebbi verziót az újjal. Az új könyvtár (<filename>/var/tmp/root</filename>) nevébe írjuk bele a dátumot is, így könnyedén össze tudunk hasonlítani több verziót is A rendszer gyakori újrafordítása az /etc szintén gyakori aktualizálását is maga után vonja, ami viszont fárasztó lehet. Az iménti folyamatot fel tudjuk gyorsítani, hogy ha az /etc legutoljára összefésült változatát megtartjuk. A most következõ eljárás ennek mikéntjét vázolja fel. A megszokottak szerint fordítsuk le a rendszert. Majd amikor az /etc könyvtárat és a többit is frissíteni akarjuk, a célként megadott könyvtár nevében adjuk meg a dátumot. Ha tehát például 1998. február 14. van, akkor írjuk ezt: &prompt.root; mkdir /var/tmp/root-19980214 &prompt.root; cd /usr/src/etc &prompt.root; make DESTDIR=/var/tmp/root-19980214 \ distrib-dirs distribution Fésüljük össze a könyvtárban található az állományokat a fentiekben körvonalazottak szerint. Befejezés után õrizzük meg a /var/tmp/root-19980214 könyvtárat. Mikor újra letöltjük a legfrissebb forrásokat és megismételjük az elõbbi lépéseket, haladjunk megint az elsõ lépés szerint. Ekkor tehát létrejön egy újabb könyvtár, amelynek a neve ezúttal már /var/tmp/root-19980221 lesz (ha például hetente frissítünk). Most már meg tudjuk vizsgálni a közbeesõ héten született eltéréseket, ha a két könyvtárra kiadunk egy rekurzív &man.diff.1; hívást: &prompt.root; cd /var/tmp &prompt.root; diff -r root-19980214 root-19980221 Általában így kevesebb eltérést kapunk, mint amennyi például a /var/tmp/root-19980221/etc/ és az /etc összehasonlítása során elkerült volna. Mivel kisebb a keletkezett különbségek száma, ezért könnyebb lesz átvinnünk az /etc könyvtárunkba is a módosításokat. Ezután törölhetjük a régebbi /var/tmp/root-* könyvtárat: &prompt.root; rm -rf /var/tmp/root-19980214 Az /etc összefésülésekor mindig ismételjük meg ezeket a lépéseket. A &man.date.1; meghívásával akár automatikussá is tehetjük a könyvtárak névadását: &prompt.root; mkdir /var/tmp/root-`date "+%Y%m%d"` Újraindítás Ezzel készen is vagyunk. Miután ellenõriztük, hogy minden a megfelelõ helyére került, indítsuk újra a rendszert. Ehhez egy egyszerû &man.shutdown.8; is elegendõ: &prompt.root; shutdown -r now Befejeztük! Gratulálunk, sikerült frissítenünk a &os; rendszerünket. Ha mégis valami balul ütne ki, könnyen újra tudjuk fordítani a rendszer egyes részeit. Például, ha véletlenül letöröltük az /etc/magic állományt az /etc frissítése vagy összefésülése során, a &man.file.1; parancs nem fog tudni rendesen mûködni. Ilyenkor a következõket kell tennünk a hiba kijavításához: &prompt.root; cd /usr/src/usr.bin/file &prompt.root; make all install Kérdések Minden egyes változtatásnál újra kell fordítani a rendszert? Nem könnyû választ adni erre a kérdésre, mivel ez alapvetõen a változtatás jellegétõl függ. Például, ha elindítjuk a CVSup programot és csak az alábbi állományok frissülnek: src/games/cribbage/instr.c src/games/sail/pl_main.c src/release/sysinstall/config.c src/release/sysinstall/media.c src/share/mk/bsd.port.mk Ekkor valószínûleg nem éri meg újrafordítani a teljes rendszert. Elegendõ csupán belépni az érintett állományokat tartalmazó alkönyvtárakba és ott rendre kiadni a make all install parancsot. Ha viszont már valami komolyabb, például az src/lib/libc/stdlib változott meg, akkor vagy az egész rendszert, vagy legalább azon részeit fordítsuk újra, amely statikusan linkeltek (és minden más idõközben még hozzáadott statikusan linkelt dolgot). Hogy melyik megoldást választjuk, teljesen rajtunk áll. Újrafordíthatjuk az egész rendszert kéthetente, mondván, hadd gyüljenek fel szépen a módosítások, vagy a függõségek pontos kielemzésével csak azokat az elemeket fordítjuk újra, amelyek tényleg meg is változtak. Természetesen az egész attól függ, hogy milyen gyakran és melyik rendszert, a &os.stable;-t vagy a &os.current;-et frissítjük. A fordító rengeteg 11-es jelzést (signal 11) (vagy másfajta jelzéseket) dob hibával. Mi történhetett? signal 11 Ez általában hardveres meghibásodásra utal. A rendszer újrafordítása alapjaiban véve egy remek módszer számítógépünk alkatrészeinek terhelésére, ezért gyakorta elõhozza a memória már meglevõ hibáit. Ezek többnyire abban fogalmazódnak meg, hogy a fordító rejtélyes módon leáll mindenféle furcsa jelzések hatására. Errõl biztosan úgy tudunk meggyõzõdni, ha újraindítjuk a make programot és az a folyamat egy teljesen másik pontján vérzik el. Ilyenkor nem tudunk mást tenni, mint egymás után kicserélgetjük, kivesszük az alkatrészeket és így próbáljuk megállapítani, pontosan melyikük is okozza a gondokat. A fordítása befejezése után törölhetem a /usr/obj könyvtárat? Röviden: Igen. A /usr/obj tartalmazza a fordítás folyamata során keletkezõ összes tárgykódot. Ennek törlése általában a make buildworld elsõ lépései között szerepel. Ezért tulajdonképpen a /usr/obj megtartásának nincs túlságosan sok értelme, viszont elég sok (jelenleg úgy kb. 340 MB) helyet fel tudunk így szabadítani. Ha azonban értjük a dolgunkat, akkor megadhatjuk a make buildworld parancsnak, hogy hagyja ki ezt a lépést. Ennek hatására a fordítás sokkal hamarabb véget ér, mivel a legtöbb forrást így nem kell újrafordítani. Üröm az örömben, hogy ha netalán aprócska függõségi problémák merülnének fel, akkor az egész fordítás megfeneklik mindenfelé különös módokon. Emiatt gyakran írnak feleslegesen leveleket a &os; levelezési listáira, melyek a rendszer sikertelen újrafordításáról panaszkodnak, miközben kiderül, hogy az maguk az érintettek akarták lerövidíteni a folyamatot. Lehetséges a megszakadt fordítás folytatása? Ez attól függ, hogy a probléma bekövetkezése elõtt mennyire sikerült eljutni a fordításban. Általában (tehát nem feltétlenül minden esetben) a make buildworld lefordítja a fordításhoz szükséges eszközök (például a &man.gcc.1; és &man.make.1;) újabb változatait és a rendszer függvénykönyvtárait, majd ezeket telepíti. Ezután ezekkel az új eszközökkel lefordítattja saját magukat és ismét telepíti. Ezt követõen fordítja újra az új rendszerállományokkal az egész rendszert (így ezúttal már az olyan szokásos felhasználói programokat is, mint például az &man.ls.1; és a &man.grep.1;). Ha tudjuk, hogy az utolsó fázisban álltunk le (mivel megnéztük a fordításhoz tartozó kimenetet), akkor (minden további nélkül) elég ennyi: … kijavítjuk a hibát … &prompt.root; cd /usr/src &prompt.root; make -DNO_CLEAN all Ezzel megmarad a korábbi make buildworld munkájának eredménye. Ha ezt az üzenetet látjuk a make buildworld kimenetében: -------------------------------------------------------------- Building everything.. -------------------------------------------------------------- akkor különösebb gond nélkül megcsinálhatjuk. Amennyiben viszont nem látunk ilyen üzenetet, vagy nem vagyunk benne biztosak, akkor még mindig jobb elõvigyázatosnak lenni, ezért kénytelenek leszünk teljesen elölrõl kezdeni a fordítást. Hogyan tudjuk felgyorsítani a fordítást? Futtassuk egyfelhasználós módban. Tegyük a /usr/src és /usr/obj könyvtárakat külön állományrendszerekre, külön lemezekre. Sõt, ha lehetséges, akkor ezeket a lemezeket tegyük külön lemezvezérlõkre. Még mindig jobb, ha ezeket az állományrendszereket a &man.ccd.4; (lemezek összefûzését vezérlõ meghajtó) segítségével kiterjesztjük több lemezes eszközre. Kapcsoljuk ki a profilozást (az /etc/make.conf állományban a NO_PROFILE=true megadásával). Többnyire úgy sem lesz rá szükségünk. Az /etc/make.conf állományban a CFLAGS változót állítsuk az értékre. Az gyakran sokkal lassabb, az és alig tér el az optimalizálás mértékében. A paraméter hatására pedig a fordítóprogram átmeneti állományok helyett csöveket használ a kommunikációra, és így megtakarít némi lemezhasználatot (a memóriahasználat terhére). Ha a &man.make.1; parancsnak átadjuk a paramétert, akkor képes több mindent párhuzamosan futtatni. Ez sok esetben segít attól függetlenül, hogy egy- vagy többprocesszoros gépünk van. A /usr/src könyvtárat tartalmazó állományrendszert csatlakoztathatjuk (vagy újracsatlakoztathatjuk) a beállítással. Ilyenkor az állományrendszer nem rögzíti a hozzáférés idejét. Erre az információra sincs igazából szükségünk. &prompt.root; mount -u -o noatime /usr/src A fenti példa azt feltételezi, hogy a /usr/src könyvtárnak saját állományrendszere van. Ha ez nem így lenne (tehát például a /usr része), akkor itt azt kell megadnunk, nem pedig a /usr/src nevét. A /usr/obj könyvtárat tartalmazó állományrendszert csatlakoztathatjuk (vagy újracsatlakoztathatjuk) az beállítással. Ennek hatására a lemez írása aszinkron módon történik. Magyarul az írási mûveletek azonnal befejezõdnek, miközben az adat ténylegesen csak pár másodperccel késõbb kerül ki a lemezre. Ezzel az írási kérelmek gyönyörûen összegyûjthetõek, ami nagymértékû növekedést eredményez a teljesítményben. Ne felejtsük el azonban, hogy ezzel együtt az állományrendszerünk is sérülékenyebbé válik. Ezen beállítás használatával megnõ annak az esélye, hogy egy áramkimaradást követõ indításnál az állományrendszer helyreállíthatatlan állapotba kerül. Ha egyedül csak a /usr/obj található ezen az állományrendszeren, akkor ez nem jelent akkora veszélyt. Amikor viszont rajta kívül még értékes adat is található az állományrendszeren, a beállítás érvényesítése elõtt mindenképpen készítsünk róla friss mentéseket. &prompt.root; mount -u -o async /usr/obj Ahogy arról az elõbb is szó esett, ha a /usr/obj nem egy különálló állományrendszeren található, akkor a példában szereplõ csatlakozási pontot cseréljük ki a megfelelõre. Mi tegyünk, ha valami nem megy rendesen? Egyértelmûen bizonyosodjunk meg róla, hogy a korábbi fordításokból nem maradtak vissza semmiféle kóbor állományok. Ennyi sokszor pontosan elég. &prompt.root; chflags -R noschg /usr/obj/usr &prompt.root; rm -rf /usr/obj/usr &prompt.root; cd /usr/src &prompt.root; make cleandir &prompt.root; make cleandir Igen, a make cleandir parancsot tényleg kétszer kell kiadni. Ezután a make buildworld parancstól indulva kezdjük újra a fordítást. Ha még ezek után is fennáll a probléma, küldjük el a hibát tartalmazó kimenetet és a uname -a parancs eredményét a &a.questions; címére. Ne lepõdjünk meg, ha a beállításainkra vonatkozóan még kapunk további kérdéseket is! Mike Meyer Írta: A források követése több géppel NFS több gép telepítése Ha egyszerre több számítógéppel is szeretnénk követni ugyanannak a forrásfának a változásait és ezért mindegyikre letöltjük a forrásokat majd újrafordítjuk ezeket, akkor sok erõforrást, de leginkább lemezterületet, hálózati sávszélességet és processzoridõt, feleslegesen használunk. Ezekkel úgy tudunk spórolni, ha valójában csak egyetlen géppel végeztetjük el a munka legtöbb részét, miközben a többi NFS használatával dolgozik. Ez a szakasz ezt a módszert foglalja össze. Elõkészületek Elõször is szedjük össze az egyezõ binárisokat futtató gépeket, melyekre a továbbiakban csak fordítási csoport néven hivatkozunk. Minden gépnek lehet saját rendszermagja, viszont a felhasználói programok mindegyikõjük esetében ugyanazok. Ebbõl a csoportból válasszuk ki egy fordító gépet. Ez lesz az a gép, amelyen a rendszer és a rendszermag lefordításra kerül. Ideális esetben ez a leggyorsabb gép, amelynek elegendõ a processzorkapacitása arra, hogy lefuttassa a make buildworld és make buildkernel parancsokat. Érdemes még rajta kívül kiválasztanunk egy tesztelõ gépet is, ahol a véglegesítés elõtt kipróbálhatjuk a szoftverfrissítéseket. Ennek egy olyan gépnek kell lennie, amely akár hosszabb ideig is nélkülözhetõ a csoportból. Lehet akár maga a fordítást végzõ gép is, de nem elvárás. A fordítási csoportban levõ összes gépnek ugyanarról a géprõl és ugyanarra a pontra kell csatlakoztatnia a /usr/obj és /usr/src könyvtárakat. Ezek optimális esetben a fordítással foglalkozó gép két külön lemezmeghajtóján vannak, melyek egyaránt elérhetõek NFS-en keresztül. Ha több fordítási csoportunk is van, akkor az /usr/src könyvtárnak elegendõ csak egyetlen fordító gépen meglennie, a többi pedig csatlakoztassa NFS-en keresztül. Végül gyõzödjünk meg róla, - hogy az /etc/make.conf tartalma a - fordítási csoport mindegyik + hogy az /etc/make.conf és a + /etc/src.conf állományok + tartalma a fordítási csoport mindegyik gépénél megegyezik a fordító gépével. Ez azt jelenti, hogy a fordító gépnek az alaprendszer ugyanazon részeit és ugyanúgy kell létrehozni, mint amelyet a fordítási csoport akármelyik gépére telepíteni is akarunk. Ezenkívül még a fordítási csoportban levõ minden egyes gép /etc/make.conf állományában a KERNCONF értékének a saját rendszermagjára vonatkozó konfigurációt kell megadni, illetve a fordítással foglakozó gép KERNCONF változójánál pedig az együtt összeset, a sajátjával kezdve. Ennek megfelelõen a fordító gépnek a rendszermagok lefordításához rendelkeznie kell az egyes gépek /usr/src/sys/arch/conf könyvtárában meglevõ állományaival. Az alaprendszer Most, miután mindent megfelelõen elõkészítettünk, készen állunk a munkára. A ban leírtak szerint fordítsuk le a rendszermagokat és az alaprendszert a fordító gépen, de utána még nem telepítsünk semmit se. Ha befejezõdött a fordítás, lépjünk be a tesztelõ gépre és telepítsük a frissen fordított rendszermagot. Ha ez a gép NFS-en keresztül éri a /usr/src és /usr/obj könyvtárakat, akkor az egyfelhasználós módban aktiválni kell a hálózatot, majd csatlakoztatni ezeket. Ezt legkönnyebben úgy tudjuk megcsinálni, ha a gépet elõször elindítjuk többfelhasználós módban, majd a shutdown now paranccsal egyfelhasználós módba váltunk. Ha eljuttunk ide, telepítsünk az új rendszermagot és rendszert, illetve a megszokott módon futtassuk a mergemaster parancsot. Amikor ezt befejeztük, ezen a gépen térjünk vissza a hétköznapi többfelhasználós mûködési módba. Miután a tesztelésre szánt gépen ellenõriztük, hogy minden a megfelelõ módon mûködik, az elõbb tárgyalt eljárással telepítsük fel a fordítási csoportban levõ összes többi gépre is az új szoftvereket. Portok Ugyanezt a gondolatmenet alkalmazható a portfa esetében is. Az elsõ és egyben legfontosabb lépés a /usr/ports csatlakoztatása ugyanarról a géprõl a fordítási csoport minden gépére. Az /etc/make.conf megfelelõ beállításával még a terjesztési állományokat is meg tudjuk osztani. A DISTDIR értékét egy olyan közösen használt könyvtárra állítsuk, amely írható az NFS-en keresztül megosztott állományrendszerünkben a root felhasználóként tevékenykedõk számára. A WRKDIRPREFIX változót minden gépen egy helyi fordítási könyvtárra állítsuk. Zárásképpen még hozzátesszük, hogy ha csomagokat akarunk készíteni és mások számára is elérhetõvé tenni, akkor ne felejtsük el a PACKAGES változót a DISTDIR változóhoz hasonlóan beállítani. diff --git a/hu_HU.ISO8859-2/books/handbook/eresources/chapter.sgml b/hu_HU.ISO8859-2/books/handbook/eresources/chapter.sgml index 3f7e171efa..c137a86c1e 100644 --- a/hu_HU.ISO8859-2/books/handbook/eresources/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/eresources/chapter.sgml @@ -1,2366 +1,2414 @@ Erõforrások az interneten A &os; gyors ütemû fejlõdése a nyomtatott médiát alkalmatlanná teszi a legfrissebb fejlesztések nyomonkövetésére. Ezzel szemben az elektronikus erõforrások a biztos, ha gyakran nem is csak az egyetlen, módjai a legújabb elõrelépések figyelemmel követésének. Mivel a &os;-t többségében önkéntesek fejlesztik, az õt körülvevõ felhasználói közösség önmaga is egyfajta szakmai segélynyújtó egyletként funkcionál, amelyet leghatékonyabban elektronikus levelében vagy USENET hírcsoportokon keresztül érhetünk el. A továbbiakban a &os; felhasználók közösségének különbözõ fajtájú elérhetõségeit vázoljuk fel nagyvonalakban. Ha úgy érezzük, hogy ebbõl a felsorolásban kimaradt volna valami, akkor ne habozzunk róla értesítést küldeni a &a.doc; címére (angolul), hogy felvehessük a többi közé. Levelezési listák Habár sok &os; fejlesztõ olvas USENET-et, nem tudjuk mindig szavatolni, hogy a comp.unix.bsd.freebsd.* csoportok valamelyikére küldött levelek idõben (vagy egyáltalán) megválaszolásra kerülnek. A megfelelõ levelezési listák címére küldött levelekkel a fejlesztõk mellett a &os; közönségét is egyaránt el tudjuk érni, ami változatlanul jobb (de legalább is gyorsabb) válaszokkal kecsegtet. A különbözõ listák témájának rövid leírása a dokumentum alján olvasható. Szeretnénk mindenkit megkérni, hogy mielõtt feliratkozik vagy levelet küld valamelyik listára, figyelmesen olvassa el ezeket. Az egyes listák tagjai már így is naponta többszáz &os;-vel kapcsolatos üzenetet kapnak, miközben a listák tematikájának és szabályainak lefektetésével igyekszünk a jel-zaj arányt minél kedvezõbb szinten tartani. Ezek nélkül a levelezési listák a Projekt számára haszontalan kommunikációs eszközökké válnának. A &a.test.name; címet használjuk, ha ki akarjuk próbálni, hogy tudunk-e levelet küldeni a &os; listáira. A többi listára viszont lehetõleg ne küldjünk teszt jellegû üzeneteket. Ha nem tudjuk eldönteni, hogy pontosan melyik listát is kellene megcímeznünk kérdésünkkel, olvassuk el a Hogyan kapjunk értékelhetõ választ a &os;-questions levelezési listáról címû leírást (angolul). Mielõtt akármelyik listára is levelet küldenénk, olvassuk el a Levelezési listák Gyakran Ismételt Kérdéseit (angolul), amivel elkerülhetjük a gyakran feltett kérdések és témák ismételt felhozását. A levelezési listák tartalma folyamatosan archiválódik, és ezekben az archívumokban a &os; honlapján tudunk keresni. Az itt elérhetõ, kulcsszavak alapján történõ keresés remek módját nyújtja a gyakran felmerülõ kérdések egyszerû és gyors megválaszolásának, ezért ilyen esetekben elõször mindig ezt javasolt használni. A listák összefoglalása Általános listák: A következõ általános célú listákhoz szabadon (és nyugodtan) csatlakozhatunk: Lista Tartalom &a.cvsall.name; Értesítés a &os; forrásfájában elvégzett változtatásokról &a.advocacy.name; A &os; igéjének terjesztése &a.announce.name; Fontosabb események és elõrelépések a projektek életében &a.arch.name; Architekturális és tervezési kérdések tárgyalása &a.bugbusters.name; A &os; hibabejelentéseit tároló adatbázis és a kapcsolódó eszközök karbantartására vonatkozó megbeszélések &a.bugs.name; Hibajelentések &a.chat.name; A &os; közösség nem szakmai jellegû dolgai &a.current.name; A &os.current; használatának tárgyalása &a.isp.name; A &os;-t alkalmazó internet-szolgáltatók fóruma &a.jobs.name; &os;-s munkalehetõségek &a.policy.name; A &os; fejlõdését irányító csoport (Core Team) döntéseirõl tájékoztató lista. A forgalma kicsi, csak olvasható. &a.questions.name; A felhasználók kérdései és szakmai segítségnyújtás &a.security-notifications.name; Biztonsági figyelmeztetések &a.stable.name; A &os.stable; használatát illetõ kérdések &a.test.name; Ide lehet küldeni a próbaüzeneteket Szakmai listák: A következõ listák szakmai jellegû témákat képviselnek. Mielõtt bármelyikükre levelet küldenénk vagy feliratkoznánk, figyelmesen olvassuk el a tartalmukat és céljaikat bemutató rövid leírásukat. Lista Tartalom &a.acpi.name; Az ACPI és energiagazdálkodás támogatás fejlesztése &a.afs.name; Az AFS portolása &os;-re &a.aic7xxx.name; Az &adaptec; AIC 7xxx sorozat meghajtóinak fejlesztése &a.alpha.name; A &os; Alpha portja &a.amd64.name; A &os; AMD64 portja &a.apache.name; Az Apache és hozzátartozó portok tárgyalása &a.arm.name; A &os; &arm; portja &a.atm.name; &os; használata ATM hálózatokkal &a.audit.name; A forráskód ellenõrzésérõl szóló projekt &a.binup.name; A bináris frissítésekkel foglalkozó rendszer tervezése és fejlesztése &a.bluetooth.name; A &bluetooth; technológia használata a &os;-ben &a.cluster.name; A &os; klaszteres környezetben &a.cvsweb.name; A CVSweb karbantartása &a.database.name; Adatbázisok használata és fejlesztése &os; alatt &a.doc.name; &os;-rõl szóló leírások készítése &a.drivers.name; Eszközmeghajtók írása &os;-re &a.eclipse.name; Az Eclipse integrált fejlesztõi környezet, eszközeinek, gazdag kliens alkalmazásinak és portjainak &os; alatti használata &a.embedded.name; A &os; használata beágyazott alkalmazásokban &a.eol.name; Olyan &os;-s szoftverek független továbbfejlesztése, amelyeket hivatalosan már nem támogatnak &a.emulation.name; Linux/&ms-dos;/&windows; és hasonló rendszerek emulációja &a.firewire.name; A &os; és a &firewire; (iLink, IEEE 1394) kapcsolatának technikai kérdései &a.fs.name; Állományrendszerek &a.geom.name; A GEOM-hoz tartozó témák és implementációk &a.gnome.name; A GNOME és GNOME-alkalmazások portolása &a.hackers.name; Általános szakmai témák &a.hardware.name; A &os; futtatására szolgáló hardverekkel foglalkozó témák &a.i18n.name; A &os; honosítása &a.ia32.name; A &os; használata az IA-32 (&intel; x86) platformon &a.ia64.name; A &os; portolása az &intel; következõ IA64 rendszereire &a.ipfw.name; Az IP tûzfal kódjának újratervezését érintõ szakmai megbeszélések &a.isdn.name; ISDN fejlesztõk levelei &a.jail.name; A &man.jail.8; segédprogram &a.java.name; &java; fejlesztõk kérdései és a &jdk;-k átültetése &os;-re &a.kde.name; A KDE és KDE-alkalmazások portolása &a.lfs.name; Az LFS portolása &os;-re &a.libh.name; A második generációs telepítõ- és csomagrendszer &a.mips.name; A &os; portolása &mips;-re &a.mobile.name; A mobil számítógépekkel kapcsolatos megbeszélések &a.mozilla.name; A Mozilla átültetése &os;-re &a.multimedia.name; Multimédia alkalmazások &a.newbus.name; A buszarchitektúrával kapcsolatos szakmai megbeszélések &a.net.name; A TCP/IP forráskódjával és hálózatkezeléssel kapcsolatos kérdések &a.openoffice.name; A OpenOffice.org és &staroffice; alkalmazások portolása &os;-re &a.performance.name; Nagy terhelésû és teljesítményû rendszerek teljesítményhangolási kérdései &a.perl.name; A rengeteg Perl alapú port karbantársa &a.pf.name; A csomagszûrõ mûködésével kapcsolatos kérdések és megbeszélések &a.platforms.name; Portolás nem &intel; architektúrájú platformokra &a.ports.name; A Portgyûjtemény mûködése &a.ports-bugs.name; A portokhoz tartozó hibák és hibajelentések megbeszélése &a.ppc.name; A &os; portolása &powerpc;-re &a.proliant.name; HP ProLiant szerverek és a &os; kapcsolata &a.python.name; A Python &os;-n futó változatának problémái &a.qa.name; A minõségbiztosítás megbeszélése, különösen a kiadások közeledtével &a.rc.name; Az rc.d rendszer és annak fejlõdése &a.realtime.name; A &os; valósidejû kiterjesztéseinek fejlesztése &a.ruby.name; A Ruby használata &os; rendszereken &a.scsi.name; A SCSI alrendszer &a.security.name; A &os; mûködését fenyegetõ biztonsági problémák &a.small.name; A &os; használata beágyazott alkalmazásokban (elavult; helyette a &a.embedded.name; címét használjuk) &a.smp.name; Az [A]Szimmetrikus többszálú feldolgozáshoz ([A]Symmetric MultiProcessing) tartozó tervezési megbeszélések &a.sparc.name; A &os; portolása &sparc; alapú rendszerekre &a.standards.name; A &os; megfelelése a C99 és &posix; szabványoknak &a.sun4v.name; A &os; portolása &ultrasparc; T1 alapú rendszerekre &a.threads.name; A &os; szálkezelése &a.testing.name; A &os; teljesítmény- és megbízhatósági tesztjei &a.tokenring.name; A Token Ring támogatása a &os;-ben &a.usb.name; USB támogatás a &os;-ben &a.virtualization.name; A &os; részérõl támogatott különbözõ virtualizációs technológiák tárgyalása &a.vuxml.name; A VuXML infrastruktúra tárgyalása &a.x11.name; Az X11 karbantartása és támogata &os; alatt Korlátozott listák: (Limited lists) A következõ listák sokkal jobban specializálódótt (és igényesebb) közösségnek szólnak, nem a nagyközönségnek. Ezért mielõtt egy ilyen listára feliratkoznánk, érdemes némi tapasztalatot gyûjtenünk a szakmai témájú listákon, így megismerjük az itt alkalmazott kommunikációs szabályokat. Lista Tartalom &a.hubs.name; A tükrözések üzemeltetõi számára (infrastrukturális támogatás) &a.usergroups.name; A felhasználói csoportok összefogása &a.vendors.name; A forgalmazók koordinálása a kiadások elõtt + + &a.wip-status.name; + A &os;-vel kapcsolatos folyamatban levõ + fejlesztések helyzetjelentései + + &a.www.name; A www.FreeBSD.org karbantartói számára Kivonatolt listák: (Digest lists) Az eddig említett listák elérhetõek kivonatolt formában is. Miután feliratkoztunk egy listára, a hozzáférésünk beállításainál kiválaszthatjuk, hogy kivonatolt formátumban kívánjuk-e kapni a leveleket. CVS listák: (CVS lists) A következõ listák a forrásfa különbözõ részeinek változtatásáról és a hozzájuk tartozó üzenetekrõl adnak értesítést. Ezek a listák csak olvasásra vannak, nem szabad rájuk levelet küldeni. Lista Forráskód területe A terület leírása (minek a forrása) &a.cvsall.name; /usr/(CVSROOT|doc|ports|projects|src) A fában végzett akármelyik módosítás (az összes CVS lista együtt) &a.cvs-doc.name; /usr/(doc|www) A doc és www ágak változásai &a.cvs-ports.name; /usr/ports A portfa változásai &a.cvs-projects.name; /usr/projects A projektek változásai &a.cvs-src.name; /usr/src A rendszer forrásának változásai Hogyan iratkozzunk fel Ha fel akarunk iratkozni valamelyik listára, kattintsunk a nevére, vagy menjünk a &a.mailman.lists.link; címre és a válasszuk ki onnan a keresett listát. A lista oldalán megtalálunk minden feliratkozással kapcsolatos utasítást. Ténylegesen úgy tudunk üzenni egy listára, ha levelet küldünk az listanév@FreeBSD.org címre, amely ezután a lista tagjai között kézbesítésre kerül a világban. A listáról úgy tudunk leiratkozni, ha a róla kapott valamelyik levél alján található URL-re kattintunk. Másik megoldás, ha magunk küldünk egy levelet a listanév-unsubscribe@FreeBSD.org címre. Még egyszer szeretnénk kérni, hogy a szakmai témájú levelezési listákon folyó társalgásokat igyekezzünk az adott témán belül tartani. Ha csupán a fontosabb bejelentésekre vagyunk kíváncsiak, akkor a kisforgalmú &a.announce; használatát válasszuk. A listák tematikája Minden &os;-s levelezési lista rendelkezik bizonyos alapszabályokkal, amelyek minden tagnak el kell fogadnia. Az ismeretett irányelvek elleni vétkezés a &os; postamesterének postmaster@FreeBSD.org két (2, azaz kettõ) írásos figyelmeztetését vonja maga után, amelyek figyelmen kívül hagyásával, tehát a harmadik szabálysértés alkalmával, a küldõ eltávolításra kerül a &os; összes levelezési listájáról és a továbbiakban szûrni fogják a leveleit. Sajnáljuk, hogy ilyen szabályokat és szankciókat kellett bevezetnünk, de napjaink internetes technológiái igen elvadultak és ahogy az látható is, sokan egyszerûen nem fogják fel, mennyire sérülékenyek egyes részei. Közlekedési szabályok: Minden beküldött levél témájának meg kell felelnie az adott lista tartalmának, tehát például a szakmai kérdésekkel foglalkozó listákon csak szakmai témájú leveleknek szabad megjelenniük. Az oda nem illõ cseverészés és értelmetlen vitázás csak a lista értékét csökkenti, ezért ezt senkitõl sem tûrjük. A kötetlenebb, konkrét téma nélküli megbeszéléseket inkább a &a.chat; címén folytassuk. 2 listánál többre ne küldjük be ugyanazt a levelet, és 2 listára is csak akkor küldjük, ha az egyértelmûen és nyilvánvalóan indokolt. A legtöbb listánál így is rengeteg az átfedés, kivéve a legtitkosabb kombinációkat (például -stable és -scsi), ezért nem túl sok értelme van egyszerre egynél több listát is értesíteni. Ha olyan üzenetet kapunk, amelynek a Cc (másolat) mezõjében több lista címe is szerepel, akkor továbbküldés vagy válaszadás során töröljük ezeket. Az általunk küldött levelekért továbbra is mi magunk vagyunk a felelõsek, függetlenül attól, hogy ki volt a levél eredeti feladója. Tilos (vita közben) személyeskedni vagy káromkodni, beleértve a felhasználókat és a fejlesztõket is. A netikett megszegését, például a privát levelezés elõzetes engedély nélküli továbbküldését vagy egyes részleteinek közlését, elítéljük, de nyíltan nem tiltjuk. Nagyon ritka esetekben azonban elõfordulhat, hogy a sértõ tartalom önmagában ellenkezik a lista elveivel és figyelmeztetést (esetleg kitiltást) von maga után. A &os;-hez nem kötõdõ termékek vagy szolgáltatások reklámozása szigorúan tilos, és ha bebizonyosodik, hogy a küldõ szándékosan küldte szét, akkor azonnali kitiltásban részesül. Az egyes listák tematikája: &a.acpi.name; Az ACPI és energiagazdálkodás támogatásának fejlesztése &a.afs.name; Andrew File System Ez a lista a CMU/Transarc AFS portolásáról szól &a.announce.name; Fontosabb események / nagyobb lépések Olyan emberek számára ajánlott ez a levelezési lista, akik csak a &os; jelentõsebb eseményei bejelentései iránt érdeklõdnek. Ide értendõk a különbözõ idõközi és egyéb kiadások, a &os; újításainak bejelentései. Idõnként önkéntesek toborzására stb. is használják. A forgalma nagyon kicsi, tartalma szigorúan ellenõrzõtt. &a.arch.name; Architekturális és tervezési kérdések Ez a lista a &os; architektúráját érintõ megbeszélések színtere. Az itt megjelenõ üzenetek szigorúan szakmai jellegûek. Néhány idevágó téma: Hogyan alakítsuk úgy át a fordítási rendszert, hogy egyszerre több különbözõ paraméterû fordítás is képes legyen futni. Mit kellene javítani a VFS-en a Heidemann-rétegek mûködéséhez. Hogyan tudnánk úgy átalakítani az eszközmeghajtók felületét, hogy ugyanazok a meghajtók minden gond nélkül képesek legyenek több buszon és architektúrán is mûködni. Hogyan írjunk meghajtót hálózati eszközökhöz. &a.audit.name; A forráskód vizsgálatát végzõ projekt Ez a levelezési lista a &os; forráskódjának vizsgálatával foglalkozik. Habár eredetileg csak a biztonságot érintõ változtatások ellenõrzésére jött létre, napjainkra már a forráskód mindenféle változását felülvizsgálja. Erre a listára rengeteg javítás érkezik, amelyek valószínûleg egy átlag &os; felhasználó számára nem túlzottan érdekesek. A kód változásától független biztonsági kérdések megvitatása a freebsd-security listán történik. Viszont az összes fejlesztõnek javasoljuk, hogy küldjék be felülvizsgálatra a javításaikat, különösen abban az esetben, amikor a forráskód olyan részéhez nyúlnak, ahol az adott hiba javítása a rendszer egészének mûködésére kihatással lehet. &a.binup.name; A &os; bináris frissítésével foglalkozó projekt Ez a lista ad otthont a binup vagy más néven a bináris frissítési rendszer (binary update system) körül felmerülõ problémák tárgyalásának. Tervezési kérdések, implementációs részletek, javítások, hiba- és állapotjelentések, funkciók igénylése, a kód változásainak naplózása és minden, ami a binuppal kapcsolatos. &a.bluetooth.name; &bluetooth; a &os;-ben Ez a &bluetooth;-os &os; felhasználók gyülekezõhelye. Tervezési és implementációs kérdések, javítások, hiba- és állapotjelentések, funkciók igénylése, minden, ami &bluetooth;. &a.bugbusters.name; A hibajelentések kezelésének összefogása A lista célja a Bugmeister és az õ Bugbustereinek, valamint a hibajelentések adatbázisai iránti kifejezetten érdeklõdõ személyek együttmûködésének és kapcsolattartásának elõsegítése. Ez a lista nem az egyes hibákról, javításokról vagy azok jelentésérõl szól. &a.bugs.name; Hibajelentések Ezen a levelezési listán lehet a &os; hibáit bejelenteni. Ha lehet, akkor a hibákat a &man.send-pr.1; paranccsal vagy a webes felületen keresztül küldjük be. &a.chat.name; A &os; közösség nem szakmai jellegû dolgai Erre a listára kerül minden olyan nem szakmai jellegû, társadalmi érintkezéssel kapcsolatos információ, ami a többi listáról kimaradt: Jordan mennyire hasonlít a rajzfilmeken látható vadászgörényre, kis- vagy nagybetûvel írjuk-e, ki iszik sok kávét, hol fõzik a legjobb söröket, ki fõz sört az alagsorában és így tovább. Elvétve felbukkannak olyan fontosabb események is (bulik, lakodalmak, gyermekáldás, új munkahely stb), amelyek ugyan szakmai témájúak, de a folyományaik már inkább a -chat listára tartoznak. &a.core.name; A &os; irányítását végzõ csapat Ezt a belsõ levelezési listát a Core Team tagjai használják. Akkor érdemes ide levelet küldeni, ha &os;-vel kapcsolatos fontos ügyekben lenne szükségünk döntésre vagy véleményre. &a.current.name; A &os.current; használatával kapcsolatos megbeszélések A &os.current; felhasználóinak levelezési listája. Itt értesülhetünk a -CURRENT felhasználókat érintõ friss újdonságairól, és azokról az utasításokról, amelyek követésével mûködéképesen tarthatjuk a -CURRENT rendszerünket. Aki a -CURRENT verziót használja, mindenképpen iratkozzon fel erre a listára. Ez is egy szakmai jellegû lista, ahová csak szigorúan ilyen témákat várnak. &a.cvsweb.name; A &os; CVSweb projekt A &os; CVSweb szolgáltatásának használatáról, fejlesztésérõl és karbantartásáról szóló megbeszélések. &a.doc.name; A dokumentációs projekt Ez a levelezési lista a &os;-rõl szóló különbözõ dokumentumok készítésével kapcsolatos problémák és projektek tárgyalásait öleli fel. A levelezési lista tagjait együttesen a &os; Dokumentációs Projekt-nek nevezik. Ez egy nyílt lista, csatlakozzunk hozzá bátran! &a.drivers.name; Eszközmeghajtók írása &os;-re A &os;-hez készülõ eszközmeghajtókról szóló szakmai fórum. Elsõsorban itt tehetik fel a meghajtók készítõi a &os; rendszermagjában megtalalálható API-kra vonatkozó kérdéseiket. &a.eclipse.name; Az Eclipse integrált fejlesztõi környezetének, segéprogramjainak, kliensalkalmazásainak és portjainak &os; felhasználók számára meghirdetett fóruma. A lista azzal a szándékkal jött létre, hogy kölcsönös támogatást nyújtson az Eclipse fejlesztõi környezet, a hozzátartozó segédeszközök, kliensalkalmazások &os; változatának megválasztásában, telepítésében és használatában. Emellett az Eclipse környezet és pluginjainak &os;-re történõ portolásáról is szó esik. Valamint igyekszik minél többet profitálni az Eclipse és a &os; köré csoportosuló közösségek kölcsönös információcseréjébõl. Habár a lista elsõdlegesen az Eclipse felhasználóinek igényeire koncentrál, azok számára is táptalajt ad, akik az Eclipse keretrendszer segítségével &os; specifikus alkalmazásokat szeretnének kifejleszteni. &a.embedded.name; A &os; használata beágyazott alkalmazásokban Ez a lista a &os; beágyazott rendszerekben történõ használatát igyekszik megvitatni. Ez egy szakmai jellegû lista, ezért ide szigorúan csak ilyen témájú leveleket várunk. A listán tárgyalt beágyazott rendszereknek tekintünk minden olyan számítási eszközt, amely az általános számítási környezetekkel szemben egyetlen feladatot lát el. Nem feltétlenül csak ilyenek, de például a különféle telefonok, illetve hálózati eszközök, mint például útválasztók, switchek, PBX-ek, távoli mérõeszközök, PDA-k, eladási rendszerek és így tovább. &a.emulation.name; A Linux/&ms-dos;/&windows; rendszerek emulációja Ezen a listán arról értekezhetünk és olvashatunk, hogy &os; alatt miként futtassunk más operációs rendszerekre írt programokat. &a.eol.name; Összefogás a &os; Projekt által tovább már támogatott, &os;-hez tartozó szoftverekért Ezen a listán kap vagy kaphat helyet a &os; Projekt által hivatalosan tovább már nem fejlesztett szoftverek felhasználói összefogáson alapuló támogatása (például biztonsági figyelmeztetések vagy javítások formájában). &a.firewire.name; &firewire; (iLink, IEEE 1394) Ez a levelezési lista foglalkozik a &os; &firewire; (azaz IEEE 1394, avagy iLink) alrendszerének implementációjával. Az itt felmerülõ témák többek közt a szabványok, buszos eszközök és a hozzájuk tartozó protokollok, vezérlõkártyák és chipkészletek, valamint a mûködtetésükre szánt programok felépítése és megvalósítása. &a.fs.name; Állományrendszerek A &os;-ben megjelenõ állományrendszerek kivesézése. Mivel ez egy szakmai jellegû lista, ide határozottan csak ilyen jellegû leveleket várunk. &a.geom.name; GEOM A GEOM és a vele kapcsolatos implementáció megbeszélései. Szakmai jellegû lista, ezért erre tekintettel csak ilyen témájú leveleket postázzunk ide. &a.gnome.name; GNOME A GNOME asztalkörnyezet &os; rendszereket érintõ használatáról szóló lista. Mûszaki jellegû, ezért szigorúan csak ilyen témákban társgalodjunk itt. &a.ipfw.name; IP tûzfalak A &os;-ben levõ IP tûzfal újratervezésével foglalkozó elgondolások és szakmai témájú megbeszélések otthona. Ide szigorúan csak ilyen témájú leveleket küldjünk! &a.ia64.name; A &os; portolása I64-re Ez a levelezési lista a &os; az &intel; IA-64 platformjára készített portjával foglalkozó egyének kommunikációs eszköze, ahol az ezzel kapcsolatos problémák és azok különbözõ megoldásai kerülnek terítékre. A téma iránt érdeklõdõket is szívesen látjuk. &a.isdn.name; ISDN kommunikáció Ez a levelezési lista a &os; ISDN támogatásáról szól. &a.java.name; &java; alapú fejlesztések A levelezési listán a nagyobb &java; alkalmazások &os; alapú fejlesztését, valamint a &jdk;-k portolásáról és karbantartását beszélik meg. &a.jobs.name; Munkát keres/kínál Erre a fórumra tudjuk beküldeni a kifejezetten &os;-hez kapcsolódó munkaajánlatokat és önéletrajzokat, tehát ez a megfelelõ hely, ha &os;-s munkát keresünk, vagy éppen &os; szakértõket. Ez azonban nem egy általános célú állásbörze, mert arra megvannak a megfelelõ helyek. Szeretnénk hozzátenni, hogy ez a lista, a többi FreeBSD.org levelezési listához hasonlóan, világméretekben mûködik. Ezért ne felejtsük sosem pontosan megjelölni a munkavégzés helyét, illetve hogy milyen kommunikációs és esetlegesen költözési lehetõségeket javaslunk. A leveleket csak nyílt formátumban küldjük — elsõsorban szöveges formátumban, de az egyszerûbb PDF, HTML vagy még néhány más hozzájuk hasonló formátumot is alkalmazhatunk. Az olyan zárt formátumok, mint például a µsoft; Word (.doc) azonban nem fognak továbbítódni. &a.kde.name; KDE A KDE és &os; kapcsolatáról szóló lista. Szigorúan szakmai jellegû, ezért csak ilyen témájú levelek küldése elfogadott. &a.hackers.name; Szakmai kérdések Ez a &os; szakmai jellegû kérdéseivel foglalkozó fórum. Ez az elsõ számû szakmai levelezési lista. A &os; fejlesztésével aktívan foglalkozó egyének számára ajánljuk, hiszen itt vethetik fel problémáikat, itt kereshetnek rájuk megoldásokat. Az ilyen típusú megbeszéléseket figyelemmel követõ egyéneket is szívesen fogadjuk. Mivel ez egy erõsen szakmai jellegû lista, ezért csak ilyen témájú leveleket várunk ide. &a.hardware.name; A &os; és a hardverek kapcsolatáról általában Ezen a listán kerül megvitatásra minden olyan hardver, amelyen a &os; mûködik: milyen gondok adódhatnak, milyen hardvereket érdemes beszereznünk vagy elkerülnünk. &a.hubs.name; Tükrözések A &os; tükrözéseit karbantartó egyének számára fontos bejelentések és megbeszélések. &a.isp.name; Az internet-szolgáltatók fóruma Ezen a levelezési listán a &os;-t használó internet-szolgáltatók tehetik fel kérdéseiket. Szigorúan csak szakmai jellegû kérdések engedélyezettek. &a.openoffice.name; OpenOffice.org Az OpenOffice.org és &staroffice; portolásával és karbantartásával kapcsolatos megbeszélések. &a.performance.name; A &os; hangolásának és gyorsításának tárgyalása Ezen a levelezési listán van lehetõségük a hackereknek, rendszergazdáknak és/vagy az érintett feleknek a &os; teljesítményével kapcsolatos témákban kifejteni a véleményüket. Leginkább nagy terhelés alatt levõ, vagy teljesítménybeli problémákkal küszködõ, esetleg még többet tudó &os; rendszerek tárgyalása a cél. Lehetõleg az érintett gyártókkal és szállítókkal együttesen próbáljuk kidolgozni a &os; teljesítményének növelésére tett kísérleteinket, ezért õket is szívesen látjuk ezen a listán. Ez a kifejezetten szakmai jellegû lista többségében a tapasztalt &os; felhasználók, hackerek vagy rendszergazdák számára tárja fel a gyors, megbízható és skálázható &os; rendszerek lehetõségeit. Ez alapvetõen nem egy kérdezgetõs lista, ahol a dokumentációk elolvasását tudjuk megspórolni, hanem egy olyan hely, ahol a teljesítményt érintõ megválaszolatlan kérdések és elõremutató fejlesztések nyernek teret. &a.pf.name; A csomagszûrõ tûzfalrendszerrel kapcsolatos kérdések A &os; csomagszûrõjéhez (packet filter, pf) tartozó tûzfalrendszer megbeszéléseit összefoglaló lista. Szakmai jellegû fejtegetések és felhasználói kérdések egyaránt jöhetnek. Továbbá ezen a listán foglalkozunk az ALTQ rendszer mûködésével is. &a.platforms.name; Portolás nem &intel; plaformokra A &os; különbözõ, nem az &intel; architektúrára építkezõ portjainak indítványozása és általános jellegû megvitatása. Ez egy kiemelten szakmai jellegû lista, ezért ide csak ilyen témájú leveleket várunk. &a.policy.name; Az Core Team szabályozásai Alacsony forgalmú, csak olvasható lista, ahol a &os; fejlesztését irányító csoport különbözõ döntéseirõl olvashatunk. &a.ports.name; A portok megbeszélése A &os; portgyûjteményével (/usr/ports), a portok infrastruktúrájával és a portok fejlesztésének irányításával kapcsolatos megbeszélések. Erõsen szakmai jellegû lista, ezért ide csak ilyen témában írjunk. &a.ports-bugs.name; A portok hibáinak tárgyalása A &os; portgyûjteményének (/usr/ports), a bejelentett portok és azok módosításához kötõdõ hibajelentésekkel foglalkozó lista. Ez egy szakmai jellegû lista, ahol csak ilyen jellegû témákra számítunk. &a.proliant.name; A &os; és a HP ProLiant szerverek kapcsolatát érintõ szakmai megbeszélések Ezen a levelezési listán a &os; HP ProLiant szervereken történõ használatát célozzuk meg, beleértve a ProLianthoz tartozó eszközmeghajtókat, karbantartó és konfigurációs szoftvereket és BIOS-frissítéseket. Ennek megfelelõen tehát a hpasmd, hpasmcli és hpacucli modulok is elsõsorban itt kerülnek felboncolásra. &a.python.name; A &os; és a Python A lista a &os; Python támogatásának fejlesztésérõl folytatott szakmai megbeszéléseket foglalja össze. Elsõsorban a Python portolásával foglalkozó egyének, valamint a külsõ fejlesztõk által készített modulok és a Zope &os;-s alkalmazásával foglalkozik. Az említett témák iránti érdeklõdõket is szeretettel várjuk. &a.questions.name; Felhasználói kérdések Ez a levelezési lista a &os;-vel kapcsolatos kérdésekrõl szól. Lehetõleg ne küldjünk hogyan témájú kérdéseket erre a szakmai listára, hacsak nem kifejezetten szakmai jellegûnek szánjuk. &a.ruby.name; A Ruby használata &os; rendszereken Ezen a listán a &os; Ruby támogatásával foglalkozunk, témáját tekintve teljesen szakmai jellegû. Elsõsorban a Ruby portokon, külsõ Ruby könyvtárakon és rendszereken dolgozó fejlesztõk figyelmébe ajánljuk. Mindenkit szeretettel várunk, aki ezekkel kapcsolatos szakmai tárgyú témákat szeretne megvitatni. &a.scsi.name; A SCSI alrendszer Ezt a levelezési listát a &os; alatt a SCSI alrendszerrel foglalkozók számára tarjuk fenn. Mivel ez egy erõsen szakmai jellegû lista, ezért rajta csak szakmai témák megengedettek. &a.security.name; Biztonsági problémák A &os; biztonságát illetõ kérdések (DES, Kerberos, biztonsági rések és javításaik, stb.) Szakmai jellegû lista, ezért ide csak a témához szorosan kapcsolódó leveleket szabad beküldeni. Alapvetõen nem kérdezz-felelek típusú a lista mûködése, habár a GYIK-hoz minden hozzájárulást (kérdést ÉS választ EGYARÁNT) szívesen veszünk. &a.security-notifications.name; Biztonsági figyelmeztetések A &os;-t érintõ biztonsági problémákról és javításaikról szóló értesítések. Megbeszélésekkel, vitákkal nem foglalkozik, mivel azok a &os;-security listán folynak. &a.small.name; A &os; használata beágyazott alkalmazásokban A szokatlanul kis méretû vagy beágyazott &os; rendszerekhez kapcsolódó megbeszélések színhelye. Szakmai jellegû lista, ezért szigorúan csak a témához tartozó leveleket fogad. Ezt a listát idõközben felváltotta a &a.embedded.name; lista. &a.stable.name; A &os.stable; használatáról szóló lista Ez a &os.stable; használóinak levelezési listája. Ide kerülnek beküldésre a -STABLE ágat futtató felhasználókat érintõ friss változások, valamint hozzájuk kötõdõen a -STABLE használatához szükséges elvégzendõ lépések. Aki a STABLE jelzésû változatot használja, mindenképpen iratkozzon fel rá. Szigorúan szakmai jellegû lista, ezért csak szakmai témájú leveleket vár. &a.standards.name; C99 és POSIX megfelelés Ez a fórum foglalkozik a &os; és a C99, valamint a POSIX szabványok szerinti megfelelésével. &a.usb.name; A &os; USB támogatása Ez a levelezési lista fogja összes a &os; USB támogatásával foglalkozó szakmai témákat. &a.usergroups.name; A felhasználói csoportokat irányító lista Ez a levelezési lista az egyes területeken mûködõ felhasználói csoportok az irányítást végzõ központi csoport tagjai általi összehangolásához tartozó problémák megbeszélésére való. Ez a lista leginkább a gyûlések letisztázására és a több csoporton átívelõ nagyobb projektek szervezéséhez használatos. &a.vendors.name; Gyártók A &os; projekt és a hozzá kötödõ hardver- és szoftvergyártók együttmûködését elõsegítõ lista. &a.virtualization.name; A &os; részérõl támogatott különbözõ virtualizációs technológiák Ezen a levelezési listán elsõsorban a &os; által támogatott virtualizációs megoldásokat vitatjuk meg. Ennek keretében egyrészt az ehhez kapcsolódó alapvetõ funkciók megvalósítása valamint további újítások kerülnek a középpontba, másrészt a felhasználók számára ezzel létrehoztunk egy fórumot a felmerülõ problémák megoldására és az alkalmazási lehetõségek megbeszelésére. + + &a.wip-status.name; + + + A &os;-vel kapcsolatos folyamatban levõ + fejlesztések + helyzetjelentése + + Ezen a levelezési listán kerülnek + bejelentésre a &os; + továbbfejlesztéséhez + fûzõdõ különbözõ + munkák és azok haladásának + menete. Az ide befutó üzeneteket + moderálják. Javasoljuk, hogy + elsõdlegesen az adott témához + tartozó tematikus &os; listára + küldjük a bejelentésünket és + csak egy másolatot erre a listára. Ennek + köszönhetõen a munkánk az adott + témaspecifikus listán rögtön meg + is vitatható, mivel ezen a listán semmi + ilyen nem engedélyezett. + + A lista archívumába tekintve + tájékozódhatunk arról, hogy pontosan + milyen formai követelmények illene megfelelnie a + beküldenõ üzenetünknek. + + A listára beérkezõ üzenetekbõl + egy szerkesztett válogatás jelenik meg + néhány havonta a &os; honlapján a Projekt + helyzetjelentésének részeként + + + . A korábban beküldött + jelentések mellett itt még találhatunk + további példákat. + + + A levelezési listák szûrése A kéretlen reklámlevelek, vírusok és egyebek elleni védekezés céljából a &os; levelezési listáinak forgalmát több módon is szûrik. Az ebben a szakaszban bemutatott szûrési megoldások nem fedik le a levelezési listák védelme érdekében alkalmazott összes lehetõséget. A levelezési listákra csak bizonyos típusú csatolt állományokat küldhetünk be. Az alábbi listában nem található MIME típusú csatolt objektumokat még a listára érkezés elõtt törlik. application/octet-stream application/pdf application/pgp-signature application/x-pkcs7-signature message/rfc822 multipart/alternative multipart/related multipart/signed text/html text/plain text/x-diff text/x-patch Egyes levelezési listák ugyan megengedhetnek további csatolt MIME objektumokat is, habár a legtöbb lista esetében a fenti lista a mérvadó. Ha egy levélben a szöveg HTML és nyers szöveg formátumban is szerepel, a HTML változat automatikusan eltávolításra kerül. Ha az e-mail csak HTML formában tartalmazza a szöveget, akkor automatikusan nyers szövegre alakítódik át. Usenet hírcsoportok A két &os;-s hírcsoport mellett még akadnak olyan további csoportok is, ahol &os; témájú kérdéseket vitathatunk meg vagy hasznos lehet számunkra. Az itt felsorolt hírcsoportok kulcsszavakkal kereshetõ archívuma Warren Toomey tulajdona (wkt@cs.adfa.edu.au). BSD-s hírcsoportok comp.unix.bsd.freebsd.announce comp.unix.bsd.freebsd.misc de.comp.os.unix.bsd (német) fr.comp.os.bsd (francia) it.comp.os.freebsd (olasz) tw.bbs.comp.386bsd (hagyományos kínai) Egyéb érdekes &unix;-os hírcsoportok comp.unix comp.unix.questions comp.unix.admin comp.unix.programmer comp.unix.shell comp.unix.user-friendly comp.security.unix comp.sources.unix comp.unix.advocacy comp.unix.misc comp.bugs.4bsd comp.bugs.4bsd.ucb-fixes comp.unix.bsd X Window System comp.windows.x.i386unix comp.windows.x comp.windows.x.apps comp.windows.x.announce comp.windows.x.intrinsics comp.windows.x.motif comp.windows.x.pex comp.emulators.ms-windows.wine Világhálós szolgáltatások &chap.eresources.www.inc; E-mail címek A következõ felhasználói csoportok nyújtanak &os;-s e-mail címeket tagjaiknak. A rendszergazdák bármilyen visszaélés esetén fenntartják a visszavonás jogát. Címtartomány Lehetõségek Felhasználói csoport Rendszergazda ukug.uk.FreeBSD.org Csak továbbítás freebsd-users@uk.FreeBSD.org Lee Johnston lee@uk.FreeBSD.org Felhasználói hozzáférések A következõ felhasználói csoportok felhasználói hozzáféréseket nyújtanak a &os; projektet aktívan támogató egyének számára. A felsorolásban szereplõ rendszergazdáknak visszaélés esetén jogukban áll megszüntetni a fiókot. Hálózati cím Hozzáférés típusa Lehetõségek Rendszergazda dogma.freebsd-uk.eu.org Telnet/FTP/SSH Levelezés, tárhely, anonim FTP Lee Johnston lee@uk.FreeBSD.org diff --git a/hu_HU.ISO8859-2/books/handbook/firewalls/chapter.sgml b/hu_HU.ISO8859-2/books/handbook/firewalls/chapter.sgml index bfc81c717e..e07d83ff03 100644 --- a/hu_HU.ISO8859-2/books/handbook/firewalls/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/firewalls/chapter.sgml @@ -1,4585 +1,4585 @@ Joseph J. Barbish Írta: Brad Davis SGML formátumúra alakította és aktualizálta: Tûzfalak tûzfalak biztonság tûzfalak Bevezetés A tûzfalakkal a rendszerünkön keresztülfolyó bejövõ és kimenõ forgalmat tudjuk szûrni. A tûzfalak egy vagy több szabályrendszer alapján vizsgálják az éppen érkezõ vagy távozó hálózati csomagokat, és vagy továbbengedik ezeket vagy megállítják. A tûzfalak szabályai a csomagok egy vagy több jellemzõjét veszik szemügyre, amelyek lehetnek például a protokoll típusa, a forrás vagy cél hálózati címe, esetleg a forrás- vagy a célport. A tûzfalak jelentõs mértékben képesek gyarapítani egy gép vagy egy hálózat védelmét. Leginkább a következõkre tudjuk felhasználni: A belsõ hálózatunkban futó alkalmazások, szolgáltatások, gépek megvédésére és elszigetelésére az internetrõl érkezõ nem kívánt forgalom ellen A belsõ hálózatban levõ gépek elérését tudjuk korlátozni vagy letiltani az interneten elérhetõ szolgáltatások felé A hálózati címfordítás (Network Address Translation, NAT) beállításához, ahol a belsõ hálózatunk privát IP-címeket használnak és egy közös kapcsolaton keresztül érik el az internetet (egyetlen IP-címmel, vagy pedig automatikusan kiosztott publikus címekkel). A fejezet elolvasása során megismerjük: hogyan adjuk meg helyesen a csomagok szûrését leíró szabályokat; a &os;-be épített tûzfalak közti különbségeket; hogyan állítsuk be és használjuk az OpenBSD PF tûzfalát; hogyan állítsuk be és használjuk az IPFILTER tûzfalat; hogyan állítsuk be és használjuk az IPFW tûzfalat. A fejezet elolvasása elõtt ajánlott: a &os;-hez és az internethez kötõdõ alapvetõ fogalmak ismerete. Röviden a tûzfalakról tûzfalak szabályrendszerei A tûzfalak szabályrendszereit alapvetõen kétféleképpen tudjuk összeállítani: inkluzív, vagyis megengedõ, illetve exkluzív vagyis kizáró módon. Az exkluzív tûzfalak minden forgalmat átengednek, amirõl nem rendelkeznek a tûzfal szabályai. Az inkluzív tûzfalak ennek pontosan az ellenkezõjét teszik. Csak azt a forgalmat engedik át, amirõl van szabály és minden mást blokkolnak. Az inkluzív tûzfalak általában biztonságosabbak az exkluzív társaiknál, mivel esetükben jelentõs mértékben visszaszorul a nem kívánatos átfolyó forgalom. Ez a típusú védelem még tovább fokozható az állapottartó tûzfalak (stateful firewall) használatával. Ilyenkor a tûzfal szemmel tartja a rajta keresztül megnyitott kapcsolatokat, és vagy csak a már meglevõ kapcsolathoz tartozó forgalmat engedi át, vagy nyit egy újat. Az állapottartó tûzfalak hátránya, hogy a Denial of Service (DoS) típusú támadásokkal szemben sokkal sérülékenyebbek olyan helyzetekben, amikor az új kapcsolatok nagyon gyorsan jönnek létre. A legtöbb tûzfal esetében azonban tudjuk vegyíteni az állapottartó és nem állapottartó viselkedést, és ezzel egy ideális beállítást kialakítani. Tûzfalak A &os; alaprendszerébe három különbözõ tûzfalat építettek be, melyek a következõk: az IPFILTER (másik nevén IPF), az IPFIREWALL (más néven IPFW) és az OpenBSD csomagszûrõje (Packet Filter, azaz PF). A forgalom szabályozására (vagyis alapvetõen a sávszélesség kihasználtságának vezérlésére) a &os; két beépített csomagot tartalmaz: ez az &man.altq.4; és a &man.dummynet.4;. Általában a Dummynet az IPFW, míg az ALTQ a PF partnere. Az IPFILTER esetében maga az IPFILTER végzi a címfordítást és a szûrést, a sávszélességet pedig az IPFW a &man.dummynet.4; vagy a PF az ALTQ segítségével. Az IPFW és a PF szabályokkal rendelkezik a rendszerünkbe érkezõ vagy onnan távozó csomagokról, habár megoldásaik teljesen máshogy mûködnek és a szabályok megadási módja is eltér. A &os; azért tartalmaz egyszerre ennyiféle tûzfalat, mert az emberek elvárásai és igényei eltérnek. Egyikük sem tekinthetõ a legjobbnak. A szerzõ egyébként az IPFILTER megoldását részesíti elõnyben, mivel egy hálózati címfordítást alkalmazó környezetben sokkal könnyebb vele megfogalmazni az állapottartó szabályokat, valamint tartalmaz egy beépített FTP proxyt is, amivel így a kimenõ FTP kapcsolatok beállítása még tovább egyszerûsödik. Mivel az összes tûzfal a csomagok fejlécének bizonyos mezõinek alapján dolgozik, ezért a tûzfal szabályrendszerét megalkotó egyénnek teljesen tisztában kell lennie a TCP/IP mûködésével, továbbá azzal, hogy ezekben a mezõkben milyen értékek szerepelhetnek és ezeket hogyan használják egy átlagos kapcsolat alatt. Ebben a témában a címen találhatunk egy remek ismertetõt (angolul). John Ferrell Átnézte és aktualizálta: Az OpenBSD csomagszûrõje (PF) és az <acronym>ALTQ</acronym> tûzfalak PF 2003 júliusában az OpenBSD PF néven ismert csomagszûrõjét átírták &os;-re és elérhetõvé tették a &os; Portgyûjteményének részeként. A PF programot beépítetten tartalmazó elsõ kiadás pedig 2004 novemberében a &os; 5.3 volt. A PF egy teljes, mindentudó tûzfal, amely támogatja az ún. ALTQ (Alternate Queuing, vagyis a váltóbesorolás) megoldást. Az ALTQ lehetõvé teszi a sávszélesség korlátozását a szolgáltatás minõsége (Quality of Service, QoS) alapján. Az OpenBSD Projekt kiváló munkát végez a PF felhasználói útmutatójának karbantartásával. A kézikönyv ezen szakasza ezért elsõsorban azzal foglalkozik, hogyan kell a PF-et &os; alatt használni, miközben igyekszik egy általános összefoglalást adni a témáról. A részletesebb információkkal kapcsolatban azonban feltétlenül nézzük meg a felhasználói útmutatót. A címen olvashatunk többet arról (angolul), hogy a PF-et hogyan használjunk &os;-n. A PF rendszermagmodul használata A &os; 5.3 megjelenése óta a PF az alaprendszer része mint futás közben betölthetõ rendszermagmodul. A rendszer induláskor tehát képes automatikusan betölteni, ha az &man.rc.conf.5; állományban megadjuk a pf_enable="YES" sort. A PF modul azonban csak akkor fog mûködésbe lépni, ha talál hozzátartozó szabályrendszert, amely alapértelmezés szerint az /etc/pf.conf állományban található. Amennyiben a PF szabályrendszere a mi esetünkben máshol található, akkor az rc.conf állományban ne felejtsük megadni a pf_rules="/elérési/útvonal/pf.szabályok" sor használatával. A &os; 7.0 kiadással a minta pf.conf állomány az /etc könyvtárból átkerült a /usr/share/examples/pf könyvtárba. A &os; 7.0 elõtti kiadásokban alapértelmezés szerint található egy pf.conf állomány az /etc könyvtárban. A PF modul parancssorból akár kézzel is betölthetõ: &prompt.root; kldload pf.ko A betölthetõ modul tartalmazza a &man.pflog.4; támogatását, amely segítségével naplózni is tudunk. Amennyiben a PF további szolgáltatásaira is szükségünk lenne, akkor a PF támogatását be kell építenünk a rendszermagba. A PF rendszermagbeli beállításai a rendszermag beállításai device pf a rendszermag beállításai device pflog a rendszermag beállításai device pfsync Noha egyáltalán nem szükséges beépítenünk a PF támogatását a rendszermagba, abban az esetben mégis szükségünk lehet rá, amikor a PF olyan komolyabb lehetõségeit szeretnénk kiaknázni, amelyek már nem részei a modulnak. Ilyen például a &man.pfsync.4;, amely a PF által használt állapottáblázatok bizonyos változásainak megjelenítésére alkalmas pszeudoeszköz. A &man.carp.4; megoldásával párosítva így akár hibatûrõ tûzfalak is kialakíthatóak a PF-fel. A CARP-ról bõvebb ismertetést a kézikönyv e ad. A PF rendszermag konfigurációs beállításai a /usr/src/sys/conf/NOTES állományban találhatóak: device pf device pflog device pfsync A device pf beállítás engedélyezi a csomagszûrõ tûzfalat (&man.pf.4;). A device pflog megadásával keletkezik egy &man.pflog.4; pszeudo hálózati eszköz, amellyel egy &man.bpf.4; eszközre érkezõ forgalmat tudunk naplózni. Ezután a &man.pflogd.8; démon használható tõle származó naplózott adatok rögzítésére. A device pfsync engedélyezi a &man.pfsync.4; pszeudo hálózati eszköz létrejöttét, amely az ún. állapotváltások megfigyelésére alkalmas. Az <filename>rc.conf</filename> állományban elérhetõ beállítások A következõ &man.rc.conf.5; beállítások aktiválják a rendszerindítás során a PF és a &man.pflog.4; használatát: pf_enable="YES" # a PF engedélyezése (a modul betöltése, ha kell) pf_rules="/etc/pf.conf" # a pf szabályait tartalmazó állomány pf_flags="" # a pfctl indításához szükséges további paraméterek pflog_enable="YES" # a pflogd(8) elindítása pflog_logfile="/var/log/pflog" # hol tartsa a pflogd az naplóit pflog_flags="" # a pflogd indításához szükséges paraméterek Ha a tûzfalunk mögött egy helyi hálózat is meghúzódik, akkor az ott levõ gépek számára valamilyen módon tudnunk kell továbbítani a csomagokat vagy címfordítást kell végezni, így ez is mindenképpen kelleni fog: gateway_enable="YES" # az átjáró funkciók engedélyezése A szûrési szabályok megfogalmazása A PF a beállításait a &man.pf.conf.5; állomány tárolja (amely alapértelmezés szerint az /etc/pf.conf helyen található), és az ebben található szabályok alapján módosítja, dobja el vagy éppen engedi át a csomagokat. A &os; rendszerünkben ehhez találhatunk néhány példát a /usr/share/examples/pf/ könyvtárban. A PF által használt szabályokról minden részletre kiterjedõen a PF felhasználói útmutatójában olvashatunk. A PF felhasználói útmutatójának olvasásakor ne feledkezzünk meg róla, hogy a különbözõ &os; verziók különbözõ PF verziókat tartalmaznak: &os; 5.X — OpenBSD 3.5 PF &os; 6.X — OpenBSD 3.7 PF &os; 7.X — OpenBSD 4.1 PF A &a.pf; remek hely a PF tûzfal beállításával és futtatásával kapcsolatos kérdésekre. A kérdezés elõtt azonban ne felejtsük el alaposan átnézni az archívumot! A PF használata A PF a &man.pfctl.8; segítségével vezérelhetõ. Az alábbiakban ezzel kapcsolatban most összefoglalunk néhány hasznos parancsot (de ne felejtsük el megnézni a &man.pfctl.8; man oldalon található többi lehetõséget sem): Parancs Leírás pfctl A PF engedélyezése pfctl A PF tiltása pfctl all /etc/pf.conf Az összes (címfordítási, szûrési, állapottartási stb.) szabály törlése, és az /etc/pf.conf állomány újratöltése pfctl [ rules | nat | state ] A szûrési (rules), címfordítási (nat) és állapottartási (state) információk lekérdezése pfctl /etc/pf.conf Az /etc/pf.conf állomány ellenõrzése a benne levõ szabályok betöltése nélkül Az <acronym>ALTQ</acronym> engedélyezése Az ALTQ kizárólag csak úgy használható, ha a konfigurációs beállításokon keresztül beépítjük a &os; rendszermagjába. Az ALTQ alkalmazását nem minden hálózati kártya meghajtója támogatja, ezért ezt a &man.altq.4; man oldalon ellenõrizzük. A következõ rendszermag konfigurációs beállításokkal engedélyezhetjük az ALTQ használatát és bõvíthetjük azt további lehetõségekkel: options ALTQ options ALTQ_CBQ # osztályozás alapú besorolás (Class Bases Queuing, CBQ) options ALTQ_RED # véletlen korai észlelés (Random Early Detection, RED) options ALTQ_RIO # RED befele/kifele options ALTQ_HFSC # hiearchikus csomagütemezõ (Hierarchical Packet Scheduler, HFSC) options ALTQ_PRIQ # prioritásos besorolás (Priority Queuing, PRIQ) options ALTQ_NOPCC # az SMP esetén kell Az options ALTQ az ALTQ rendszert engedélyezi. Az options ALTQ_CBQ engedélyezi a osztályozás alapú besorolást (Class Based Queuing, CBQ). A CBQ használatával a kapcsolatunkhoz tartozó sávszélességet különbözõ osztályokra vagy sorokra tudjuk bontani és a szûrési szabályoknak megfelelõen osztályozni segítségükkel a forgalmat. Az options ALTQ_RED a véletlen korai észlelés (Random Early Detection, RED) használatát engedélyezi. A RED a hálózati forgalomban keletkezõ torlódások elkerülésére alkalmas. A RED ezt a problémát úgy oldja meg, hogy méri a sorok hosszát és összeveti a hozzátartozó minimális és maximális küszöbértékekkel. Ha a sor hossza meghaladja a számára elõírt maximális értéket, akkor az új csomagokat eldobja. Nevéhez hûen a RED az eldobásra ítélt csomagokat véletlenszerûen választja ki. Az options ALTQ_RIO engedélyezi a RED használatát mind a két irányba, tehát be- és kifelé. Az options ALTQ_HFSC a pártatlan hierachikus szolgáltatási görbe alapú csomagütemezõt (Hierarchical Fair Service Curve Packet Scheduler, HFSC) engedélyezi. Vele kapcsolatban a címen találhatunk bõvebben olvasnivalót (angolul). Az options ALTQ_PRIQ a prioritásos besorolást (Priority Queuing, PRIQ) teszi elérhetõvé. A PRIQ mindig elsõként a nagyobb értékû sorban levõ forgalmat továbbítja. Az options ALTQ_NOPCC az ALTQ SMP, vagyis többprocesszoros támogatását adja meg. Ilyen típusú rendszerekben ez kötelezõ. Az IPFILTER (IPF) tûzfal tûzfalak IPFILTER Ez a szakasz fejlesztés alatt áll. Ennek megfelelõen a tartalma nem minden esetben pontos. Az IPFILTER szerzõje Darren Reed. Az IPFILTER nem kötõdik egyik rendszerhez sem: ez egy olyan nyílt forráskódú alkalmazás, amelyet átírtak &os;, NetBSD, OpenBSD, &sunos;, HP/UX és &solaris; operációs rendszerekre. Az IPFILTER karbantartása és támogatása pillanatnyilag is aktív, folyamatosan jelennek meg újabb változatai. Az IPFILTER egy rendszermag oldalán mûködõ tûzfalazási és egy címfordítási mechanizmusra alapszik, amelyet felhasználói programokkal tudunk felügyelni és vezérelni. A tûzfal szabályai az &man.ipf.8; segédprogrammal állíthatóak be vagy törölhetõek. A hálózati címfordításra vonatkozó szabályokat az &man.ipnat.1; segédprogrammal állíthatjuk be vagy törölhetjük. Az &man.ipfstat.8; segédprogram képes futás közben statisztikákat készíteni az IPFILTER rendszermagban elhelyezkedõ részeinek viselkedésérõl. Az &man.ipmon.8; program pedig az IPFILTER cselekvéseit képes a rendszernaplókba feljegyezni. Az IPF eredetileg olyan szabályfeldolgozási módszer szerint készült, amelyben az utolsó egyezõ szabály nyer és csak állapotnélküli szabályokat ismert. Az idõ múlásával az IPF részévé vált a quick opció és a keep state opción keresztül az állapottartás is, melyek drámai mértékben korszerûsítették a szabályok feldolgozásának elvét. Az IPF hivatalos dokumentációja tartalmazza a régi szabályok létrehozását és azok feldolgozásának leírását. A korszerûsített funkciók csak kiegészítésképpen jelennek meg, és az általuk felkínált elõnyök megértése egy sokkal magasabb szintû és biztonságosabb tûzfal megépítését teszik lehetõvé. A szakaszban szereplõ utasításokban olyan szabályok szerepelnek, amelyek kihasználják a quick és keep state opciókat. Ezek az inkluzív tûzfalszabályok létrehozásának alapjai. Az inkluzív tûzfalak csak olyan csomagokat engednek keresztül, amelyek megfelelnek a szabályoknak. Ezen módon képesek vagyunk megmondani, hogy a tûzfal mögül milyen szolgáltatások érhetõek el az interneten és segítségével azt is megadhatjuk, hogy az internetrõl a belsõ hálózatunkon milyen szolgáltatásokat érhetnek el. A tûzfal alapból minden mást visszautasít és naplóz. Az inkluzív tûzfalak sokkal, de sokkal megbízhatóbbak az exkluzív tûzfalaknál, ezért itt most csak ilyenekkel foglalkozunk. A régi típusú szabályokról a és címeken olvashatunk (angolul). Az IPF gyakran ismételt kérdései a címen érhetõek el (angolul). A nyílt forrású IPFILTER levelezési lista kereshetõ archívumait a címen találjuk (angolul). Az IPF engedélyezése IPFILTER engedélyezés Az IPF megtalálható a &os; alaptelepítésében mint menet közben külön betölthetõ modul. Ha az rc.conf állományba beírjuk a ipfilter_enable="YES" sort, akkor ez a modul dinamikusan betöltõdik. A betölthetõ modul alapból naplóz és a default pass all beállítást tartalmazza. Ha helyette a block all szabályt akarjuk használni, akkor emiatt még nem kell feltétlenül újrafordítanunk a &os; rendszermagját, elég ha egyszerûen csak a szabályrendszerünk végére beszúrjuk. A rendszermag beállításai a rendszermag beállításai IPFILTER a rendszermag beállításai IPFILTER_LOG a rendszermag beállításai IPFILTER_DEFAULT_BLOCK IPFILTER a rendszermag beállításai Az IPF használatához nem kötelezõ a következõ beállításokkal újrafordítani a &os; rendszermagját, itt csupán háttérinformációként szerepel. Amikor az IPF a rendszermagba kerül, a betölhetõ modulra nem lesz szükség. Az IPF a rendszermag forrásai között található /usr/src/sys/conf/NOTES állományban megadott beállításai a következõ módon foglalhatóak össze: options IPFILTER options IPFILTER_LOG options IPFILTER_DEFAULT_BLOCK Az options IPFILTER engedélyezi az IPFILTER tûzfal támogatását. Az options IPFILTER_LOG hatására az IPF az ipl csomagnaplózó pszeudo eszközre jegyzi fel a forgalmat — minden olyan szabály esetén, ahol megjelenik a log kulcsszó. Az options IPFILTER_DEFAULT_BLOCK megváltoztatja az alapértelmezett viselkedést, tehát minden olyan csomag, amely nem illeszkedik a tûzfal valamelyik pass típusú (átengedõ) szabályára, blokkolásra kerül. Ezek a beállítások csak azt követõen érvényesülnek, ha fordítottunk és telepítettünk velük egy új rendszermagot. Az <filename>rc.conf</filename> állomány beállításai Az /etc/rc.conf állományban a következõ utasításokra lesz szükségünk az IPF mûködésbe hozására a rendszer indítása során: ipfilter_enable="YES" # az ipf tûzfal indítása ipfilter_rules="/etc/ipf.rules" # betölti a szabályokat tartalmazó szöveges állományt ipmon_enable="YES" # elindítja az IP monitor naplózását ipmon_flags="-Ds" # D = indítás démonként # s = naplózás a syslog használatával # v = a tcp ablak, ack, seq csomagok naplózása # n = az IP-címek és portok feloldása Ha olyan helyi hálózat áll meg a tûzfal mögött, amely egy fenntartott privát IP-címtartományt használ, akkor még a következõ utasításokra is szükségünk lesz a címfordítás bekapcsolásához: gateway_enable="YES" # a helyi hálózat átjárója ipnat_enable="YES" # az ipnat funkció elindítása ipnat_rules="/etc/ipnat.rules" # az ipnat mûködéséhez szükséges definíciók IPF ipf Az ipf parancs használható a szabályokat tartalmazó állomány betöltésére. Általában egy állományba írjuk össze a tûzfal szabályait és ezzel a paranccsal cseréljük le egyszerre a tûzfalban levõ jelenlegi szabályokat: &prompt.root; ipf -Fa -f /etc/ipf.rules Az az összes belsõ szabály törlését jelenti. Az jelzi, hogy egy állományból kell beolvasni a betöltendõ szabályokat. Ezzel mintegy lehetõségünk van változtatni a korábban összeállított szabályainkon, futtatni a fenti IPF parancsot és ezen keresztül úgy frissíteni a szabályok friss másolatával a már mûködõ tûzfalat, hogy nem is kell újraindítanunk a rendszert. Ez a módszer igen kényelmes az új szabályok kipróbálásához, mivel bármikor tetszõlegesen végrehajtható. Az &man.ipf.8; man oldala tartalmazza a parancsnak megadható további beállításokat. Az &man.ipf.8; parancs a szabályokat tároló állományt egy szabványos szöveges állománynak tekinti, semmilyen szimbolikus helyettesítést alkalmazó szkriptet nem fogad el. Lehetõségünk van azonban olyan IPF szabályokat készíteni, amelyek kiaknázzák a szkriptek szimbolikus helyettesítésének lehetõségeit. Errõl bõvebben lásd . Az IPFSTAT ipfstat IPFILTER statisztika Az &man.ipfstat.8; alapértelmezés szerint a arra használatos, hogy le tudjuk kérdezni és megjeleníteni a tûzfalhoz tartozó számlálók értékeit, amelyek a legutóbbi indítás vagy az ipf -Z parancs által kiadott lenullázásuk óta a bejövõ vagy kimenõ forgalomból a megadott szabályoknak megfelelõ csomagok alapján gyûjtenek össze statisztikákat. A parancs mûködésének részleteit az &man.ipfstat.8; man oldalon olvashatjuk. Az &man.ipfstat.8; meghívása alapból így néz ki: input packets: blocked 99286 passed 1255609 nomatch 14686 counted 0 output packets: blocked 4200 passed 1284345 nomatch 14687 counted 0 input packets logged: blocked 99286 passed 0 output packets logged: blocked 0 passed 0 packets logged: input 0 output 0 log failures: input 3898 output 0 fragment state(in): kept 0 lost 0 fragment state(out): kept 0 lost 0 packet state(in): kept 169364 lost 0 packet state(out): kept 431395 lost 0 ICMP replies: 0 TCP RSTs sent: 0 Result cache hits(in): 1215208 (out): 1098963 IN Pullups succeeded: 2 failed: 0 OUT Pullups succeeded: 0 failed: 0 Fastroute successes: 0 failures: 0 TCP cksum fails(in): 0 (out): 0 Packet log flags set: (0) Az mint bejövõ (inbound), vagy az mint kimenõ (outbound) forgalomra vonatkozó paraméterek megadásával a rendszermagban az adott oldalon jelenleg telepített és alkalmazott szabályokat kérhetjük le és jeleníthetjük meg. Az ipfstat -in parancs így a bejövõ forgalomra vonatkozó belsõ szabályokat mutatja a szabályok számával. Az ipfstat -on parancs a kimenõ forgalmat érintõ belsõ szabályokat mutatja a szabályok számával. Az eredmény körülbelül ilyen lesz: @1 pass out on xl0 from any to any @2 block out on dc0 from any to any @3 pass out quick on dc0 proto tcp/udp from any to any keep state Az ipfstat -ih a bejövõ forgalomhoz tartozó belsõ szabályokat mutatja és mindegyik elé odaírja, hogy eddig mennyi csomag illeszkedett rájuk. Az ipfstat -oh ugyanígy a kimentõ forgalom esetén mutatja a belsõ szabályokat és mindegyik elõtt feltünteti, hogy az adott pillanatig mennyi csomag illeszkedett rájuk. A kimenete nagyjából ilyen lesz: 2451423 pass out on xl0 from any to any 354727 block out on dc0 from any to any 430918 pass out quick on dc0 proto tcp/udp from any to any keep state Az ipfstat parancs talán egyik legfontosabb funkciója a kapcsolóval csalható elõ, melynek hatására a rendszerben aktív állapotok táblázatát mutatja meg ugyanúgy, ahogy a &man.top.1; a &os; rendszerben futó programokat. Amikor a tûzfalunk támadás alatt áll, ezzel a funkcióval tudjuk a problémát beazonosítani, leásni a mélyébe és látni a támadótól érkezõ csomagokat. A kiegészítésképpen megadható alkapcsolók megadásával kiválaszthatjuk azt a cél vagy forrás IP-címet, portot vagy protokollt, amelyet valós idõben meg akarunk figyelni. Ennek részleteit az &man.ipfstat.8; man oldalán láthatjuk. Az IPMON ipmon IPFILTER naplózás Az ipmon megfelelõ mûködéséhez be kell kapcsolnunk a rendszermag IPFILTER_LOG beállítását. Ez a parancs két különbözõ módban használható. Ha parancsot a opció nélkül gépeljük be, akkor ezek közül alapból a natív módot kapjuk meg. A démon mód abban az esetben hasznos, ha folyamatosan naplózni akarjuk a rendszerben zajló eseményeket, majd késõbb ezeket átnézni. Így képes egymással együttmûködni a &os; és az IPFILTER. A &os; beépítve tartalmaz olyan lehetõséget, aminek révén magától cseréli a rendszernaplókat. Ezért ha átküldjük a syslogd démonnak a naplózandó üzeneteket, akkor sokkal jobban járunk, mintha egyszerûen csak mezei állományba naplóznánk. Az rc.conf alapértelmezései között az ipmon_flags beállítás a kapcsolókat rögzíti: ipmon_flags="-Ds" # D = indítás démonként # s = naplózás a syslog használatával # v = a tcp ablak, ack, seq csomagok naplózása # n = az IP-címek és portok nevének feloldása Ennek a viselkedésnek az elõnyei minden bizonnyal egyértelmûek. Segítségével képesek vagyunk az esetek megtörténte után átnézni, hogyan milyen csomagokat dobott el a rendszer, azok milyen címekrõl érkeztek és hova szánták. Ez egy komoly fegyver a támadók lenyomozásában. Hiába engedélyezzük a naplózást, az IPF önszántából semmilyen naplózási szabályt nem fog gyártani. A tûzfal gazdájának kell eldöntenie, hogy a szabályokat közül melyiket akarja naplózni, és így neki kell megadnia a log kulcsszót ezekben az esetekben. Normális esetben csak a deny szabályokat naplózzák. Egyáltalán nem ritka, hogy a szabályrendszer végén egy alapértelmezés szerint mindent eldobó szabály áll, amely naplóz. Ezzel lehetõségünk nyílik rögzíteni azokat a csomagokat, amelyek egyetlen szabályra sem illeszkedtek. Naplózás az IPMON használatával A syslogd egy saját módszert alkalmaz a naplózott adatok elkülönítésére. Egy funkciók (facility) és szintek (level) segítségével kialakított speciális csoportosítást alkalmaz. Az IPMON módja a security (biztonság) funkciót használja. Tehát az IPMON által naplózott összes adat a security csoportjába kerül. Ezen túl a következõ szinteken különíthetjük el igényeinknek megfelelõen a naplózott adatokat: LOG_INFO - az átengedés vagy blokkolás helyett a "log" kulcsszóval ellátott csomagok LOG_NOTICE - az át is engedett csomagok LOG_WARNING - a blokkolt csomagok LOG_ERR - a naplózott csomagok közül azok, amelyek túlságosan kicsik (hibás a fejlécük) Az IPFILTER csak akkor tud naplózni a /var/log/ipfilter.log állományba, ha elõtte létrehozzuk. Az alábbi parancs erre tökéletesen megfelelõ: &prompt.root; touch /var/log/ipfilter.log A syslog mûködését az /etc/syslog.conf állományban szereplõ definíciók vezérlik. A syslog.conf állomány számottevõ mértékben képes meghatározni azt, ahogy a syslog az IPF és a hozzá hasonló alkalmazásoktól kapott rendszerszintû üzeneteket kezeli. Az /etc/syslog.conf állományba az alábbi sor kell felvennünk: security.* /var/log/ipfilter.log A security.* megadásával az összes ilyen típusú üzenet egy elõre rögzített helyre kerül. Az /etc/syslog.conf állományban elvégzett módosításokat úgy léptethetjük érvénybe, ha újraindítjuk a számítógépet vagy az /etc/rc.d/syslogd reload paranccsal megkérjük a syslog programot, hogy olvassa újra az /etc/syslog.conf állományt. Az imént létrehozott naplót ne felejtsük el megadni az /etc/newsyslog.conf állományban sem, és akkor ezzel a cseréjét is megoldjuk. A naplózott üzenetek formátuma Az ipmon által létrehozott üzenetek whitespace karakterekkel elválasztott adatmezõkbõl állnak. A következõ mezõk az összes üzenet esetében megjelennek: A csomag megérkezésének dátuma A csomag megérkezésének idõpontja. ÓÓ:PP:MM.E alakban jelennek meg az órák, percek, másodpercek és ezredmásodpercek (ez több számjegy hosszú is lehet) szerint Annak a felületnek a neve, ahol a csomag feldolgozásra került, például dc0 A szabályhoz tartozó csoport és sorszám, például @0:17 Ezek az ipfstat -in paranccsal nézhetõek meg. Cselekvés: a p mint átment (passed), b mint blokkolt (blocked), S mint rövid csomag (short packet), n mint egyik szabályra sem illeszkedett (not match), L mint naplózás (log). A módosítók megjelenítésének sorrendje: S, p, b, n, L. A nagybetûs P és B azt jelzi, hogy a csomagot egy felsõbb szintû beállítás miatt naplózták, nem egy szabály hatására. Címek: ez tulajdonképpen három mezõt takar: a forrás címet és portot (melyet egy vesszõ választ el), a -> jelet és cél címet és portot. Például: 209.53.17.22,80 -> 198.73.220.17,1722. A PR után a protokoll neve vagy száma olvasható, például PR tcp. A len csomaghoz tartozó fejléc és törzsének teljes hosszát jelöli, például len 20 40. Amennyiben a csomag TCP, egy kötõjellel kezdõdõen további mezõk is megjelenhetnek a beállított opcióknak megfelelõ betûk képében. A betûket és beállításaikat az &man.ipmon.8; man oldalán olvashatjuk. Amennyiben a csomag ICMP, a sort két mezõ zárja, melyek közül az elsõ tartalma mindig ICMP, és ezt egy perjellel elválasztva az ICMP üzenet típusa és altípusa követi. Tehát például az ICMP 3/3 a nem elérhetõ port üzenetet hordozza. A szabályok felírása szimbolikus helyettesítéssel Az IPF használatában gyakorlott felhasználók közül néhányan képesek olyan stílusú szabályrendszert készíteni, ahol szimbolikus helyettesítést használnak. Ennek az egyik legnagyobb elõnye az, hogy ilyenkor elég csak a szimbolikus névhez tartozó értéket megváltoztatni és amikor a szkript lefut, akkor az összes rá hivatkozó szabályba ez kerül be. Szkript lévén a szimbolikus helyettesítéssel ki tudjuk emelni a gyakran használt értékeket és behelyettesíteni ezeket több helyre. Ezt a most következõ példában láthatjuk. Az itt alkalmazott felírás kompatibilis az sh, csh és tcsh parancsértelmezõkkel. A szimbolikus helyettesítést egy dollárjellel fejezzük ki: $. A szimbolikus mezõkben nem szerepel a $ jelölés. A szimbolikus mezõ tartalmát kettõs idézõjelbe (") tesszük. Kezdjük így el a szabályok írását: ######### Az IPF szabályait tartalmazó szkript eleje ########### oif="dc0" # a kimenõ felület neve odns="192.0.2.11" # az internet szolgáltató névszerverének IP-címe myip="192.0.2.7" # a szolgáltatótól kapott statikus IP-címünk ks="keep state" fks="flags S keep state" # Választhatunk, hogy az /etc/ipf.rules állományt ebbõl a szkriptbõl # hozzuk létre vagy futtathatjuk "magát" a szkriptet. # # Egyszerre csak az egyik sort használjuk. # # 1) Ezzel gyárhatjuk le az /etc/ipf.rules állományt: #cat > /etc/ipf.rules << EOF # # 2) Ezzel futtathajuk "magát" a szkriptet: /sbin/ipf -Fa -f - << EOF # Engedélyezzük a szolgáltató névszerverének elérését. pass out quick on $oif proto tcp from any to $odns port = 53 $fks pass out quick on $oif proto udp from any to $odns port = 53 $ks # Engedélyezzük kifelé a titkosítatlan www funkciót. pass out quick on $oif proto tcp from $myip to any port = 80 $fks # Engedélyezzük kifelé a TLS SSL felett üzemelõ titkosított www funkciót. pass out quick on $oif proto tcp from $myip to any port = 443 $fks EOF ################## Itt az IPF szkript vége ######################## Ennyi lenne. A példában szereplõ szabályok most nem annyira lényegesek, a hangsúly most igazából a szimbolikus helyettesítésen és annak használatán van. Ha a fenti példát az /etc/ipf.rules.script állományba mentjük, akkor ezeket a szabályokat a következõ paranccsal újra tudjuk tölteni: &prompt.root; sh /etc/ipf.rules.script Egyetlen aprócska gond van a beágyazott szimbólumokat tartalmazó állományokkal: az IPF maga nem képes megérteni a helyettesítéseket, azért közvetlenül nem olvassa a szkriptet. Ez a szkript két módon hasznosítható: Vegyük ki megjegyzésbõl a cat paranccsal kezdõdõ sort, és tegyük megjegyzésbe az /sbin/ipf kezdetût. A megszokottak szerint tegyük az ipfilter_enable="YES" sort az /etc/rc.conf állományba, majd minden egyes módosítása után futtassuk le a szkriptet az /etc/ipf.rules állomány létrehozásához vagy frissítéséhez. Tiltsuk le az IPFILTER aktiválását a rendszerindításkor, tehát írjuk bele az ipfilter_enable="NO" sort (ami mellesleg az alapértelmezett értéke) az /etc/rc.conf állományba. Tegyünk egy, az alábbi szkripthez hasonlót az /usr/local/etc/rc.d/ könyvtárba. A szkriptnek adjuk valamilyen értelmes nevet, például ipf.loadrules.sh. Az .sh kiterjesztés használata kötelezõ. #!/bin/sh sh /etc/ipf.rules.script A szkript engedélyeit állítsuk be úgy, hogy a root tulajdonában legyen és képes legyen olvasni, írni valamint végrehajtani. &prompt.root; chmod 700 /usr/local/etc/rc.d/ipf.loadrules.sh Most miután a rendszer elindult, az IPF szabályai be fognak töltõdni. Szabályrendszerek az IPF-ben Az ipf esetében a szabályrendszer olyan szabályokból áll, amelyek a csomagokról tartalmuk alapján eldöntik, hogy át kell engedni vagy vissza kell tartani. A gépek közt két irányban áramló csomagok egy munkamenet alapú társalgást képeznek. A tûzfal szabályrendszere minden csomagot kétszer dolgoz fel: egyszer, amikor befut az internetrõl, illetve még egyszer, amikor visszatér az internetre. Mindegyik TCP/IP szolgáltatást (például telnet, www, levelezés stb.) elõre meghatározza a hozzátartozó protokoll, cél és forrás IP-cím vagy port. Ez az alapja a szolgáltatások engedélyezésérõl vagy tiltásáról szóló szabályok megfogalmazásának. IPFILTER a szabályok feldolgozásának sorrendje Az IPF eredetileg úgy íródott, hogy a szabályokat az utolsó illeszkedõ szabály nyer stílusban dolgozza fel és csak állapot nélküli szabályokat ismert. Az idõk folyamán az IPF szabályai kiegészültek a quick és az állapottartásra vonatkozó keep state opciókkal, amelynek köszönhetõen óriási mértékben korszerûsödött a szabályok feldolgozása. A szakaszban szereplõ utasítások olyan szabályokat alkalmaznak, amelyekben egyaránt szerepel a quick és az állapottartásért felelõs keep state beállítás. Ez az inkluzív tûzfalak létrehozásának egyik alapeszköze. Az inkluzív tûzfalak csak olyan szolgáltatásokat engednek át, amelyek megfelelnek valamelyik szabálynak. Ezzel lényegében meg tudjuk adni, hogy milyen szolgáltatások érhetõek el a tûzfal mögül az internet felé, valamint az internetrõl a magánhálózatunkon. A tûzfal minden mást elutasít és alapértelmezés szerint naplóz. Az inkluzív tûzfalak sokkal, de sokkal biztonságosabbak az exkluzív tûzfalaknál, ezért itt most csak ezzel az egyetlen típussal foglalkozunk. A tûzfal szabályainak összeállítása során nagyon óvatosnak kell lennünk! Bizonyos beállítások hatására akár ki is zárhatjuk magunkat a szerverünkrõl. Az ebbõl fakadó esetleges kellemetlenségek elkerülése érdekében javasoljuk, hogy a tûzfal alapjait elõször helyi konzolról építsük fel, ne pedig távolról, például ssh segítségével. A szabályok felépítése IPFILTER a szabályok felépítése A szabályok felépítésének bemutatását itt most leszûkítjük a modern állapottartó szabályokra és az elsõ illeszkedõ szabály nyer típusú feldolgozásra. A szabályok felírásának régebbi módjai az &man.ipf.8; man oldalon találhatóak. A # karakterrel egy megjegyzés kezdetét jelezzük, és általában a sor végén vagy egy külön sorban bukkan fel. Az üres sorokat a rendszer nem veszi figyelembe. A szabályok kulcsszavakat tartalmaznak. Ezeknek a kulcsszavaknak balról jobbra haladva adott sorrendben kell szerepelniük. A kulcsszavakat kiemeltük. Egyes kulcsszavakhoz további beállítások is tartozhatnak, amelyek maguk is kulcsszavak lehetnek, és még további opciókkal rendelkezhetnek. Az alábbi nyelvtan mindegyik elemét kiemeltük és az alábbiakban egyenként kifejtjük a részleteiket. CSELEKVÉS BE-KI OPCIÓK SZÛRÉS ÁLLAPOTTARTÓ PROTOKOLL FORRÁS_CÍM,CÉL_CÍM OBJEKTUM PORTSZÁM TCP_BEÁLLÍTÁS ÁLLAPOTTARTÓ CSELEKVÉS = block | pass BE-KI = in | out OPCIÓK = log | quick | on felületnév SZÛRÉS = proto érték | forrás/cél IP | port = szám | flags beállítás PROTOKOLL = tcp/udp | udp | tcp | icmp FORRÁS_CÍM,CÉL_CÍM = all | from objektum to objektum OBJEKTUM = IP-cím | any PORTSZÁM = portszám TCP_BEÁLLÍTÁS = S ÁLLAPOTTARTÓ = keep state CSELEKVÉS A cselekvés határozza meg, hogy mit kell tenni azokkal a csomagokkal, amelyek illeszkednek a szabály többi részére. Minden szabályhoz tartoznia kell egy cselekvésnek. A következõ cselekvések közül választhatunk: A block megadásával a szabályban szereplõ szûrési feltételre illeszkedõ csomagot eldobjuk. A pass megadásával a szabályban szereplõ szûrési feltételre illeszkedõ csomagot átengedjük a tûzfalon. BE-KI Az összes szûrési szabály esetében kötelezõ egyértelmûen nyilatkozunk arról, hogy a bemenõ vagy a kimenõ forgalomra vonatkozik. Ezért a következõ kulcsszó vagy az in vagy pedig az out, de közülük egyszerre csak az egyiket szabad használni, máskülönben a szabály hibásnak minõsül. Az in jelenti, hogy a szabályt az internet felõl az adott felületen beérkezõ csomagokra kell alkalmazni. Az out jelenti, hogy a szabályt az internet felé az adott felületen kiküldött csomagokra kell alkalmazni. OPCIÓK Ezek az opciók csak a lentebb bemutatott sorrendben használhatók. A log jelzi, hogy illeszkedés esetén a csomag fejlécét az ipl eszközön keresztül naplózni kell (lásd a naplózásról szóló szakaszt). A quickjelzi, hogy illeszkedés esetén ez lesz a legutolsónak ellenõrzött szabály és így egy olyan rövidzárat tudunk képezni a feldolgozásban, amellyel elkerüljük a csomagra egyébként vonatkozó többi szabály illesztését. Ez az opció a korszerûsített szabályfeldolgozás kihasználásához elengedhetetlen. Az on használatával a szûrés feltételei közé bevonhatjuk a csomaghoz tartozó hálózati felületet. Itt a felületek az &man.ifconfig.8; által megjelenített formában adhatóak meg. Az opció megadásával csak az adott felületen az adott irányba (befelé/kifelé) közlekedõ csomagokra fog illeszkedni a szabály. Ez az opció a korszerûsített szabályfeldolgozás kihasználásához nélkülözhetetlen. Amikor naplózunk egy csomagot, akkor a hozzátartozó fejléc az IPL csomagnaplózó pszeudo eszközhöz kerül. A log kulcsszó után közvetlenül a következõ minõsítõk szerepelhetnek (a következõ sorrendben): A body jelzi, hogy a csomag tartalmának elsõ 128 byte-ját még jegyezzük fel a fejléc mellé. A first minõsítõt akkor érdemes használnunk, amikor a log kulcsszót a keep state opcióval együtt alkalmazzuk, mivel ilyenkor csak a szabályt kialakító csomag kerül naplózásra és nem minden olyan, ami illeszkedik az állapottartási feltételekre. SZÛRÉS Ebben a szakaszban olyan kulcsszavak jelenhetnek meg, amelyekkel a csomagok különféle tulajdonságai alapján ítélkezhetünk azok illeszkedésérõl. Itt adott egy kiinduló kulcsszó, amelyhez további kulcsszavak is tartoznak, és amelyek közül csak egyet választhatunk. Az alábbi általános tulajdonságok alapján tudjuk szûrni a csomagokat, ebben a sorrendben: PROTOKOLL A proto egy olyan kulcsszó, amelyhez hozzá kell rendelnünk még valamelyik opcióját is. Ez az opció segít az adott protokolloknak megfelelõen válogatni a csomagok között. A korszerûsített szabályfeldolgozás lehetõségeinek kihasználásához nélkülözhetetlen. Opcióként a tcp/udp | udp | tcp | icmp, vagy bármelyik, az /etc/protocols állományban megtalálható kulcsszó felhasználható. A tcp/udp ebbõl a szempontból speciálisnak tekinthetõ, mivel hatására egyszerre illeszthetõek a szabályra a TCP és UDP csomagok, és így a protokolltól eltekintve azonos szabályok felesleges többszörözését kerülhetjük el. FORRÁS_CÍM/CÉL_CÍM Az all kulcsszó gyakorlatilag a from any to any (bárhonnan bárhova) szinonímája és nem tartozik hozzá paraméter. A from forrás to cél felépítése: a from és to kulcsszavak az IP-címek illesztésére használhatóak. Ilyenkor a szabályokban a forrás ÉS a cél paramétereknek is szerepelniük kell. Az any egy olyan speciális kulcsszó, amely tetszõleges IP-címre illeszkedik. Néhány példa az alkalmazására: from any to any vagy from 0.0.0.0/0 to any, from any to 0.0.0.0/0, from 0.0.0.0/0 to any vagy from any to 0.0.0.0. Az IP-címek megadhatóak pontozott numerikus formában a hálózati maszk bitekben mért hosszával együtt, vagy akár egyetlen pontozott numerikus IP-címként. Nincs lehetõség olyan IP-címtartományok illesztésére, amelyek nem adhatóak meg kényelmesen a maszk hosszával. A hálózati maszkok hosszának megállapításban segíthet a következõ (angol nyelvû) honlap: . PORT Amikor portra vonatkozó illeszkedést írunk elõ, megadhatjuk a forrásra és célra, amit aztán vagy csak TCP vagy pedig csak UDP csomagokra alkalmazunk. A portok feltételeinek megfogalmazásánál használhatjuk a portok számát vagy az /etc/services állományban szereplõ nevüket. Amikor a port egy from típusú objektum leírásában jelenik meg, akkor automatikusan a forrásportot jelenti, míg a to objektum leírásában pedig a célportot. A to objektumoknál a port megadása elengedhetetlen a korszerûsített szabályfeldolgozás elõnyeinek kihasználásához. Példa: from any to any port = 80. A portokat különbözõ mûveletek segítségével, numerikusan hasonlíthatjuk össze, ahol akár porttartományt is megadhatunk. port "=" | "!=" | "<" | ">" | "<=" | ">=" | "eq" | "ne" | "lt" | "gt" | "le" | "ge". A porttartományok megadásához használjuk a port "<>" | "><" felírási módot. A forrásra és célra vonatkozó paraméterek után szereplõ másik két paraméter nélkülözhetetlen a korszerûsített szabályfeldolgozás mûködéséhez. <acronym>TCP</acronym>_BEÁLLÍTÁS A beállítások csak a TCP forgalom szûrésénél érvényesülnek. A betûk jelölik azokat a lehetséges beállításokat, amelyek a TCP csomagok fejlécében megvizsgálhatóak. A korszerûsített szabályfeldolgozás a flags S paraméter segítségével ismeri fel a TCP munkameneteket kezdeményezõ kéréseket. ÁLLAPOTTARTÓ A keep state jelzi, hogy a szabály paramétereinek megfelelõ bármely csomag aktiválja az állapottartó szûrés használatát. Ez a beállítás feltétlenül szükséges a korszerûsített szabályfeldolgozás megfelelõ kihasználásához. Állapottartó csomagszûrés IPFILTER állapottartó szûrés Az állapottartó szûrés a csomagok kétirányú áramlását egy létrejött kapcsolatba sorolja be. Amikor aktiválódik, az állapottartó szabály elõre dinamikusan létrehozza a kétirányú kommunikációban megforduló csomagokhoz a megfelelõ belsõ szabályokat. Olyan vizsgálatokat végez, amelyek segítségével ki tudja deríteni, hogy a csomag küldõje és címzettje között fennálló kétirányú kapcsolat érvényes szabályok szerint zajlik-e. Minden olyan csomagot, amely nem illeszkedik megfelelõen a kapcsolatra vonatkozó sémára, csalásnak tekintjük és automatikusan eldobjuk. Az állapottartás révén lehetõségünk van a TCP vagy UDP kapcsolatokhoz tartozó ICMP csomagokat is átengedni a tûzfalon. Tehát ha kapunk egy 3-as típusú, 4-es kódú ICMP választ valamilyen böngészésre használt állapottartó szabályon keresztül kiküldött kérésre, akkor az automatikusan bejöhet. Amelyik csomagot az IPF egyértelmûen képes besorolni az aktív kapcsolatba, még ha az eltérõ protokollt is használ, beengedi. Ami ilyenkor történik: Az internethez csatlakozó felületen keresztül kifelé haladó csomagokat elõször egy dinamikus állapottábla alapján illesztjük, és ha a csomag illeszkedik az aktív kapcsolatban következõként várt csomagra, akkor átmegy a tûzfalon és a dinamikus állapottáblában frissül a kapcsolat állapota, a fennmaradó csomagok pedig a kimenõ szabályrendszer szerint kerülnek ellenõrzésre. Hasonlóan az elõzõhöz, az internethez csatlakozó felületen keresztül befelé haladó csomagokat elõször egy dinamikus állapottábla alapján illesztjük, és ha a csomag illeszkedik az aktív kapcsolatban következõként várt csomagra, akkor átmegy a tûzfalon és a dinamikus állapottáblában frissül a kapcsolat állapota, a fennmaradó csomagok pedig a bejövõ szabályrendszer szerint kerülnek ellenõrzésre. Amikor egy kapcsolat befejezõdik, automatikusan törlõdik a dinamikus állapottáblából. Az állapottartó csomagszûrés használatával az újonnan keletkezõ kapcsolatok elutasítására vagy engedélyezésére tudunk koncentrálni. Ha engedélyeztük egy új kapcsolat létrejöttét, akkor a rákövetkezõ összes többi csomag automatikusan átmegy a tûzfalon és minden más hamis csomag eldobódik. Ha tiltjuk az új kapcsolatot, akkor egyetlen rákövetkezõ csomag sem juthat át. Az állapottartó szûrés által felkínált fejlett elemzési lehetõségek képesek védelmet nyújtani a behatolók részérõl alkalmazott megannyi különbözõ támadási módszer ellen. Példa inkluzív szabályrendszerre A most következõ szabályrendszer arra mutat példát, hogyan programozzunk le egy nagyon biztonságos inkluzív tûzfalat. Az inkluzív tûzfalak csak a szabályainak megfelelõ szolgáltatásokat engedik keresztül, és alapértelmezés szerint minden mást blokkolnak. Minden tûzfal legalább két felülettel dolgozik, melyek mindegyikéhez írnunk kell szabályokat a tûzfal megfelelõ mûködéséhez. Mindegyik &unix;-típusú rendszert, köztük a &os;-t is úgy alakították ki, hogy az operációs rendszeren belüli kommunikáció az lo0 felületen és a 127.0.0.1 IP-címen keresztül történik. A tûzfal szabályai között feltétlenül szerepelniük kell olyanoknak, amelyek lehetõvé teszik ezen a speciális felületen a csomagok zavartalan mozgását. Az internetre csatlakozó felülethez kell rendelni a kifelé haladó forgalom hitelesítését és az internetrõl befelé irányuló hozzáférés vezérlését. Ez lehet a felhasználói PPP által létrehozott tun0 felület vagy a DSL-, illetve kábelmodemhez csatlakozó hálózati kártya. Ahol egy vagy több hálózati kártya is csatlakozik a tûzfal mögött elhelyezkedõ helyi magánhálózathoz, ott ezeket a felületeket úgy kell felvenni a tûzfal szabályai közé, hogy a helyi hálózaton zajló forgalmat ne akadályozzuk. A szabályokat elõször három nagy csoportba kell szerveznünk: az összes szabadon forgalmazó felület, az internet felé haladó kimenõ forgalom és az internet felõl befelé haladó forgalom. Az egyes csoportokban szereplõ szabályokat úgy kell megadni, hogy közülük elõre kerüljenek a leggyakrabban alkalmazottak, és a csoport utolsó szabálya blokkoljon és naplózzon minden csomagot az adott felületen és irányban. A kimenõ forgalomat vezérlõ szabályrendszer csak pass (tehát átengedõ) szabályokat tartalmazhat, amelyek bentrõl az interneten elérhetõ szolgáltatásokat azonosítják egyértelmûen. Az összes ilyen szabályban meg kell jelenni a quick, on, proto, port és keep state beállításoknak. A proto tcp szabályok esetében meg kell adni a flag opciót is, amivel fel tudjuk ismertetni a kapcsolatok keletkezését és ezen keresztül aktiválni az állapottartást. A bejövõ forgalmat vezérlõ szabályrendszerben elõször az eldobni kívánt csomagokat kell megadni, aminek két eltérõ oka van. Elõször is a blokkolt elemek lehetnek egy egyébként szabályos csomag részei, amit a késõbbiekben a hitelesített szolgáltatások alapján beengedünk. Másodszor ezzel az olyan rendszertelenül érkezõ csomagokat tudjuk blokkolni, amelyeket nem akarunk a naplóban látni, mivel ilyenkor a csoport utolsójaként megadott blokkoló és naplózó szabályhoz már nem jut el. A csoport utolsó tagjaként megadott szabály blokkolja és naplózza az illétektelen hozzáféréseket, amit akár jogi bizonyítékként is felhasználhatunk a rendszerünket megtámadók ellen. A másik, amire még oda kell figyelnünk, hogy a blokkolt csomagok esetében semmilyen válasz nem keletkezik, egyszerûen csak eltûnnek. Így a támadó nem fogja tudni, hogy a csomagjai vajon elérték-e a rendszerünket. Minél kevesebb információt tudnak összegyûjteni a rendszerünkrõl a támadók, annál több idõt kell szánniuk csínytevéseik kieszelésére. Javasolt a beérkezõ OS fingerprint jellegû kéréseket az elsõ alkalmommal naplózni, mert ez az elsõ jele annak, amikor valaki meg akar támadni minket. Amikor a log first szabály alapján keletkezõ üzeneteket akarjuk látni, hívjuk meg a ipfstat -hio parancsot, ahol megjelenik, hogy melyik szabályra mennyi csomag illeszkedett. Ennek alapján el tudjuk dönteni, hogy éppen elárasztanak-e bennünket, tehát meg akarnak-e támadni. Ha ismeretlen porthoz tartozó csomagokat naplózunk, akkor az /etc/services állományban vagy a (angol nyelvû) honlap segítségével tudjuk kideríteni, hogy pontosan melyik portról van szó. Érdemes továbbá megnézni a trójai programok által használt portokat a címen (angolul). A következõ szabályrendszer egy olyan biztonságos inkluzív típusú tûzfal, amelyet maga a szerzõ is használ. Ha ezt átvesszük egy az egyben, akkor abból semmilyen bajunk nem származhat. Egyszerûen csak vegyük ki azokat a szabályokat, amelyek olyan szolgáltatásokra vonatkoznak, amiket nem akarunk hitelesíteni. Ha nem akarunk látni bizonyos üzeneteket a naplóban, akkor vegyünk fel hozzájuk egy block típusú szabályt a befelé irányuló forgalomhoz tartozó szabályok közé. Ne felejtsük el minden szabályban átírni a dc0 felület nevét annak a hálózati kártyának a felületére, amelyen keresztül csatlakozunk az internethez. A felhasználói PPP esetében ez a tun0 lesz. Tehát a következõket kell beírni az /etc/ipf.rules állományba: ################################################################# # A helyi hálózatunkon zajló forgalmat ne korlátozzuk. # Csak akkor kell, ha helyi hálózathoz is csatlakozunk. ################################################################# #pass out quick on xl0 all #pass in quick on xl0 all ################################################################# # A belsõ felületen szintén ne korlátozzunk semmit. ################################################################# pass in quick on lo0 all pass out quick on lo0 all ################################################################# # Az internet felé forgalmazó felület (kimenõ kapcsolatok) # A saját hálózatunkról belülrõl vagy errõl az átjáróról # kezdeményezett kapcsolatokat vizsgáljuk az internet felé. ################################################################# # Engedélyezzük az internet szolgáltatók névszerverének elérését, # az "xxx" helyett a névszervet IP-címét kell megadni. # Másoljuk le ezeket a sorokat, ha a szolgáltatónknak több # névszerverét is beakarjuk állítani. A címeiket az /etc/resolv.conf # állományban találjuk. pass out quick on dc0 proto tcp from any to xxx port = 53 flags S keep state pass out quick on dc0 proto udp from any to xxx port = 53 keep state # DSL vagy kábeles hálózatoknál engedélyezzük a # szolgáltatónk DHCP szerverének elérését. # Ez a szabály nem kell, ha "felhasználói PPP"-vel # kapcsolódunk az internethez, ilyenkor tehát az egész # csoport törölhetõ. # Használjuk az alábbi szabályt és keressük meg a naplóban az # IP-címet. Ha megtaláltuk, akkor tegyük bele a megjegyzésben # szereplõ szabályba és töröljük az elsõ szabályt. pass out log quick on dc0 proto udp from any to any port = 67 keep state #pass out quick on dc0 proto udp from any to z.z.z.z port = 67 keep state # Kifelé engedélyezzük a szabványos nem biztonságos WWW funkciókat. pass out quick on dc0 proto tcp from any to any port = 80 flags S keep state # Kifelé engedélyezzük a biztonságos WWW funkciókat TLS SSL # protokollal. pass out quick on dc0 proto tcp from any to any port = 443 flags S keep state # Kifelé engedélyezzük az e-mailek küldését és fogadását. pass out quick on dc0 proto tcp from any to any port = 110 flags S keep state pass out quick on dc0 proto tcp from any to any port = 25 flags S keep state # Kifelé engedélyezzük az idõ szolgáltatást. pass out quick on dc0 proto tcp from any to any port = 37 flags S keep state # Kifelé engedélyezzük az nntp híreket. pass out quick on dc0 proto tcp from any to any port = 119 flags S keep state # Kifelé engedélyezzük az átjáróról és a helyi hálózatról a nem # biztonságos FTP használatát (passzív és akív módokban is). Ez a # funkció a mûködéséhez a nat szabályokat tartalmazó állományban # hivatkozott FTP proxyt használja. Amennyiben a pkg_add paranccsal # csomagokat akarunk telepíteni az átjáróra, erre a szabályra # mindenképpen szükségünk lesz. pass out quick on dc0 proto tcp from any to any port = 21 flags S keep state # Kifelé engedélyezzük a biztonságos FTP, telnet és SCP szolgáltatások # elérését az SSH (secure shell) használatával. pass out quick on dc0 proto tcp from any to any port = 22 flags S keep state # Kifelé engedélyezzük a nem biztonságos telnet elérését. pass out quick on dc0 proto tcp from any to any port = 23 flags S keep state # Kifelé engedélyezzük FreeBSD CVSUP funkcióját. pass out quick on dc0 proto tcp from any to any port = 5999 flags S keep state # Kifelé engedélyezzük a pinget. pass out quick on dc0 proto icmp from any to any icmp-type 8 keep state # Kifelé engedélyezzük a helyi hálózatról érkezõ whois kéréseket. pass out quick on dc0 proto tcp from any to any port = 43 flags S keep state # Minden mást eldobunk és naplózzuk az elsõ elõfordulásukat. # Ezzel a szabállyal állítjuk be, hogy alapértelmezés szerint minden # blokkolva legyen. block out log first quick on dc0 all ################################################################# # Az internet felõli felület (bejövõ kapcsolatok) # A saját hálózatunk felé vagy erre az átjáróra # nyitott kapcsolatokat vizsgáljuk az internet felõl. ################################################################# # Eldobjuk az összes olyan bejövõ forgalmat, amit hivatalosan nem # lehetne továbbítani vagy fenntartott címterülethez tartozik. block in quick on dc0 from 192.168.0.0/16 to any #RFC 1918: privát IP block in quick on dc0 from 172.16.0.0/12 to any #RFC 1918: privát IP block in quick on dc0 from 10.0.0.0/8 to any #RFC 1918: privát IP block in quick on dc0 from 127.0.0.0/8 to any #helyi block in quick on dc0 from 0.0.0.0/8 to any #helyi block in quick on dc0 from 169.254.0.0/16 to any #DHCP block in quick on dc0 from 192.0.2.0/24 to any #dokumentációs célokra fenntartva block in quick on dc0 from 204.152.64.0/23 to any #Sun klaszterek összekötésére használt -block in quick on dc0 from 224.0.0.0/3 to any #D és E osztályú többesküldés +block in quick on dc0 from 224.0.0.0/3 to any #D és E osztályú multicast ##### Itt eldobunk egy rakás csúf dolgot ############ # Ezeket nem akarjuk a naplóban látni: # Eldobjuk a töredékcsomagokat. block in quick on dc0 all with frags # Eldobjuk a túlságosan rövid TCP csomagokat. block in quick on dc0 proto tcp all with short # Eldobjuk a forrás által közvetített (source routed) csomagokat. block in quick on dc0 all with opt lsrr block in quick on dc0 all with opt ssrr # Elutasítjuk az "OS fingerprint" kéréseket. # Naplózzuk az elsõ elõfordulást, így nálunk lesz a kíváncsiskodó # egyén IP-címe. block in log first quick on dc0 proto tcp from any to any flags FUP # Eldobunk mindent, aminek speciális beállításai vannak. block in quick on dc0 all with ipopts # Elutasítjuk a publikus pinget. block in quick on dc0 proto icmp all icmp-type 8 # Elutasítjuk az ident kéréseket. block in quick on dc0 proto tcp from any to any port = 113 # Blokkoljuk az összes Netbios szolgáltatást: 137=név, 138=datagram, # 139=session. A Netbios az MS Windows megosztását implementálja. # Blokkoljuk az MS Windows hosts2 névszerver kéréseit is a 81-es # porton. block in log first quick on dc0 proto tcp/udp from any to any port = 137 block in log first quick on dc0 proto tcp/udp from any to any port = 138 block in log first quick on dc0 proto tcp/udp from any to any port = 139 block in log first quick on dc0 proto tcp/udp from any to any port = 81 # Engedélyezzük a szolgáltatónk DHCP szerverétõl érkezõ forgalmat. # Ebben a szabályban meg kell adnunk a szolgáltató DHCP szerverének # IP-címét, mivel itt csak a hiteles forrásból fogadunk el csomagokat. # Erre csak DSL- és kábelmodemes kapcsolat esetében van szükség, a # "felhasználói PPP" alkalmazása során szükségtelen. Ez az IP-cím # megegyezik a kimenõ kapcsolatoknál megadott címmel. pass in quick on dc0 proto udp from z.z.z.z to any port = 68 keep state # Befelé engedélyezzük a szabványos WWW funkciót, mivel webszerverünk # van. pass in quick on dc0 proto tcp from any to any port = 80 flags S keep state # Befelé engedélyezzük az internetrõl érkezõ nem biztonságos telnet # kapcsolatokat. Azért nem biztonságos, mert az azonosítókat és # jelszavakat titkosítatlan formában közli az interneten keresztül. # Töröljük ezt a szabályt, ha nem használunk telnet szervert. #pass in quick on dc0 proto tcp from any to any port = 23 flags S keep state # Befelé engedélyezzük az internetrõl érkezõ biztonságos FTP, telnet és SCP # kapcsolatokat az SSH (secure shell) használatával. pass in quick on dc0 proto tcp from any to any port = 22 flags S keep state # Minden mást dobjuk el és naplózzuk az elsõ elõfordulásukat. # Az elsõ alkalom naplózásával elejét tudjuk venni a "Denial of # Service" típusú támadásoknak, amivel egyébként lehetséges lenne a # napló elárasztása. # Ez a szabály gondoskodik arról, hogy a rendszer alapértelmezés # szerint mindent eldobjon. block in log first quick on dc0 all ################### Itt van a szabályok vége ############################## <acronym>NAT</acronym> NAT IP maszkolás NAT hálózati címfordítás NAT A NAT jelentése Network Address Translation, vagyis hálózati címfordítás. A &linux; esetében ezt IP masqueradingnak, vagyis IP maszkolásnak hívják. A hálózati címfordítás és az IP maszkolás lényegben ugyanazt takarja. Az IPF címfordításért felelõs funkciójának köszönhetõen képesek vagyunk a tûzfal mögött elhelyezkedõ helyi hálózat számára megosztani az internet-szolgáltatól kapott publikus IP-címet. Sokakban felmerülhet a kérdés, hogy erre vajon mi szükségünk lehet. Az internet-szolgáltatók a magánszemélyeknek általában dinamikus IP-címeket osztanak ki. A dinamikus itt arra utal, hogy a címünk minden alkalommal változik, amikor betárcsázunk a szolgáltatóhoz vagy amikor ki- és bekapcsoljuk a modemünket. Ez az IP-cím lesz az, ami alapján az interneten elérhetõek leszünk. Most tegyük fel, hogy öt gépünk van otthon, viszont csak egyetlen elõfizetéssel rendelkezünk. Ebben az esetben öt telefonvonalat kellene használnunk és mindegyik géphez elõfizetni az internetre. A hálózati címfordítás alkalmazásával azonban mindössze egyetlen elõfizetés kell. A gépek közül négyet hozzákötünk egy switch-hez és a switch-et pedig a fennmaradó géphez, amelyen &os; fut. Ez utóbbi lesz az így kialakított helyi hálózatunk átjárója. A tûzfalban mûködõ címfordítás segítségével a helyi hálózaton található gépek IP-címeit észrevétlenül át tudjuk fordítani a hálózatunk publikus IP-címére, ahogy a csomagok elhagyják az átjárót. A beérkezõ csomagok esetében mindez visszafelé történik meg. A hálózati címfordítás gyakran a szolgáltató engedélye vagy éppen tudta nélkül történik, és ha a szolgáltató rájön, akkor a legtöbb esetben ez az elõfizetés megszûntetésével jár. Az üzleti felhasználók jóval többet fizetnek az internet kapcsolatért és általában egy olyan statikus IP-címblokkot kapnak, amely sosem változik. A szolgáltatók az üzleti célú felhasználás esetében gyakran ajánlják és támogatják a hálózati címfordítást a belsõ hálózatok számára. Az IP-címek közül adott egy tartomány, amit a címfordítást használó helyi hálózatok részére tartanak fenn. Az RFC 1918 szerint az alábbi IP-címtartományok használhatók a helyi hálózatban, mivel ezeken keresztül közvetlenül sosem lehet kijutni az internetre: Kezdõ IP: 10.0.0.0 - Záró IP: 10.255.255.255 Kezdõ IP: 172.16.0.0 - Záró IP: 172.31.255.255 Kezdõ IP: 192.168.0.0 - Záró IP: 192.168.255.255 IP<acronym>NAT</acronym> NAT IPFILTER ipnat A címfordításra vonatkozó szabályokat az ipnat paranccsal tudjuk betölteni. Az ilyen típusú szabályokat általában az /etc/ipnat.rules állományban találjuk. A részleteket lásd az &man.ipnat.1; man oldalán. Amikor a címfordítás üzembe helyezése után meg akarjuk változtatni a címfordítás szabályait, elõször a címfordítás szabályait tartalmazó állományt módosítsuk, majd a belsõ címfordítási szabályok és a címfordítási táblázatban szereplõ aktív bejegyzések törléséhez futassuk le az ipnat parancsot a beállítással. A címfordítási szabályok újratöltését egy ehhez hasonló paranccsal tudjuk elvégezni: &prompt.root; ipnat -CF -f /etc/ipnat.szabályok A címfordításhoz tartozó statisztikákat ezzel a paranccsal tudjuk lekérdezni: &prompt.root; ipnat -s A címfordítási táblázatban pillanatnyilag szereplõ összerendeléseket a következõ paranccsal tudjuk listázni: &prompt.root; ipnat -l A szabályok feldolgozásával és az aktív szabályokkal/bejegyzésekkel kapcsolatos információk részletezését így engedélyezhetjük: &prompt.root; ipnat -v A címfordítási szabályok A címfordítási szabályok nagyon rugalmasak és rengeteg olyan funkciót meg tudunk velük valósítani, ami az üzleti és otthoni felhasználók számára egyaránt hasznos. Itt most a szabályok felépítését csak egyszerûsítve mutatjuk be, leginkább a nem üzleti környezetek tekintetében. A szabályok komplett formai leírását az &man.ipnat.5; man oldalán találjuk. Egy címfordítási szabály tehát valahogy így néz ki: map FELÜLET HELYI_IP_TARTOMÁNY -> PUBLIKUS_CÍM A szabályt a map kulcsszó kezdi. A FELÜLET helyére az internet felé mutató külsõ felület nevét írjuk be. A HELYI_IP_TARTOMÁNY lesz az, amelyben a kliensek címeznek. Ez például a 192.168.1.0/24. A PUBLIKUS_CÍM lehet egy külsõ IP-cím vagy a 0/32 speciális kulcsszó, amellyel a FELÜLET-hez rendelt IP-címre hivatkozunk. Hogyan mûködik a hálózati címfordítás A publikus cél felé haladó csomag megérkezik a helyi hálózatról. Miután a kimenõ kapcsolatokra vonatkozó szabályok átengedik, a címfordítás kapja meg a szerepet és fentrõl lefelé haladva nekilát alkalmazni a saját szabályait, ahol az elsõ egyezõ szerint cselekszik. A címfordítás a szabályokat a csomaghoz tartozó felületre és a forrás IP-címére illeszti. Amikor a csomag felületének neve illeszkedik egy címfordítási szabályra, akkor ezután a csomag forrás (vagyis a helyi hálózaton belüli) IP-címérõl igyekszik eldönteni, hogy a szabály nyilának bal oldalán szereplõ tartományba esik-e. Ha erre is illeszkedik, akkor a forrás IP-címét átírjuk a 0/32 kulcsszó alapján felderített publikus IP-címre. A címfordító rutin ezt feljegyzi a saját belsõ táblázatába, így amikor a csomag visszatér az internetrõl, akkor képes lesz visszafordítani az eredeti belsõ IP-címére és feldolgozásra átadni a tûzfal szabályainak. A címfordítás engedélyezése A címfordítás életre keltéséhez a következõket kell beállítanunk az /etc/rc.conf állományban. Elõször engedélyezzük a gépünknek, hogy közvetítsen forgalmat a felületek között: gateway_enable="YES" Minden alkalommal indítsuk el a címfordításért felelõs IPNAT programot: ipnat_enable="YES" Adjuk meg az IPNAT számára a betöltendõ szabályokat: ipnat_rules="/etc/ipnat.rules" Hálózati címfordítás nagyon nagy helyi hálózatok esetében Az olyan helyi hálózatokban, ahol rengeteg PC található vagy több alhálózatot is tartalmaz, az összes privát IP-cím egyetlen publikus IP-címbe tömörítése igen komoly problémává tud dagadni és az azonos portok gyakori használata a helyi hálózatra kötött számítógépek között ütközéseket okoz. Két módon tudunk megoldást nyújtani erre a problémára. A használható portok kiosztása Egy normális címfordítási szabály valahogy így nézne ki: map dc0 192.168.1.0/24 -> 0/32 A fenti szabályban a csomag forrásportját az IPNAT változatlanul a feldolgozás után hagyja. Ha ehhez még hozzátesszük a portmap kulcsszót, akkor ezzel utasítani tudjuk az IPNAT-ot, hogy csak az adott tartományban képezze le a forrásportokat. Például a következõ szabály hatására az IPNAT a forrásportokat egy adott tartományon belül fogja módosítani: map dc0 192.168.1.0/24 -> 0/32 portmap tcp/udp 20000:60000 Ha viszont még inkább meg akarjuk könnyíteni a dolgunkat, akkor itt egyszerûen csak adjuk meg az auto kulcsszót, amellyel az IPNAT önmagától megállapítja, hogy milyen portokat tud használni: map dc0 192.168.1.0/24 -> 0/32 portmap tcp/udp auto Több publikus cím használata Minden nagyobb helyi hálózat esetében elérkezünk ahhoz a ponthoz, ahol már egyetlen publikus cím nem elég. Ha több publikus IP-címmel is rendelkezünk, akkor ezekbõl a címekbõl egy közös készletet hozhatunk létre, amibõl majd az IPNAT válogathat miközben a csomagok címeit átírja kifelé menetben. Például ahelyett, hogy a csomagokat egyetlen publikus IP-címre képeznénk le, ahogy itt tesszük: map dc0 192.168.1.0/24 -> 204.134.75.1 A hálózati maszk segítségével meg tudjuk adni IP-címek egy tartományát is: map dc0 192.168.1.0/24 -> 204.134.75.0/255.255.255.0 CIDR-jelöléssel: map dc0 192.168.1.0/24 -> 204.134.75.0/24 A portok átirányítása Gyakran elõfordul, hogy van webszerverünk, levelezõ szerverünk, adatbázis szerverünk és névszerverünk, melyek a helyi hálózat különbözõ gépein futnak. Ebben az esetben a szerverekhez tartozó forgalmat is fordítanunk kell, illetve valamilyen módon a bejövõ forgalmat is át kell irányítanunk a helyi hálózat megfelelõ gépeihez. Az IPNAT ezt a gondot a hálózati címfordítás átirányítást támogató funkcióival szünteti meg. Tegyük fel, hogy a 10.0.10.25 belsõ címen van egy webszerverünk, amelyhez a 20.20.20.5 publikus IP tartozik. Ilyenkor a következõ szabályt adjuk meg: rdr dc0 20.20.20.5/32 port 80 -> 10.0.10.25 port 80 vagy: rdr dc0 0.0.0.0/0 port 80 -> 10.0.10.25 port 80 Így tudjuk beállítani a 10.0.10.33 címmel rendelkezõ névszervert a kintrõl érkezõ névfeloldási kérések fogadására: rdr dc0 20.20.20.5/32 port 53 -> 10.0.10.33 port 53 udp Az FTP és a címfordítás Az FTP egy olyan õskövület, amely még az internet egy régi korszakából maradt fenn, amikor az egyetemek között még bérelt vonal létezett és az FTP szolgált a kutatók közt az állományok megosztására. Ez még abban az idõben történt, amikor a biztonság egyáltalán nem volt lényeges szempont. Az évek elõrehaladtával az FTP protokoll beleivódott a feltörekvõ internet gerincébe és a titkosítatlanul küldött azonosítóival és jelszavaival továbbra is ugyanolyan védtelen maradt. Az FTP két változatban, aktív és passzív módban képes mûködni. Az eltérés kettejük között az adatcsatorna megállapításában van. A passzív mód sokkal biztonságosabb, mivel ilyenkor az adatcsatornát az FTP kapcsolatot kezdeményezõ állítja be. Az FTP különbözõ módjainak magyarázatát és a köztük levõ különbséget a címen ismerhetjük meg részleteiben (angolul). Az IPNAT szabályai Az IPNAT egy speciális beépített FTP proxyval rendelkezik, amelyre a hálózati címfordítás leképezései között hivatkozhatunk. Képes figyelni az összes aktív vagy passzív FTP kapcsolathoz tartozó kimenõ kérést és ezekhez dinamikusan létrehozni olyan ideiglenes szûrési szabályokat, amelyek valóban csak az adatcsatornához felhasznált portokat tartalmazzák. Ezzel ki tudjuk küszöbölni az FTP azon káros hatását a tûzfalra nézve, hogy egyszerre túlságosan sok magasabb tartománybeli port legyen nyitva. Ez a szabály a belsõ hálózat összes FTP forgalmát lekezeli: map dc0 10.0.10.0/29 -> 0/32 proxy port 21 ftp/tcp Ez a szabály pedig az átjáróról érkezõ FTP forgalommal bírkózik meg: map dc0 0.0.0.0/0 -> 0/32 proxy port 21 ftp/tcp Ez a szabály kezeli a belsõ hálózatról érkezõ összes nem FTP típusú forgalmat: map dc0 10.0.10.0/29 -> 0/32 Az FTP leképzésére vonatkozó szabály a szokásos leképzési szabály elé kerül. Az összes csomag fentrõl haladva az elsõ illeszkedõ szabály alapján kerül feldolgozásra. Elõször a felület nevét vizsgáljuk, majd a belsõ hálózatbeli forrás IP-t, végül azt, hogy a csomag egy FTP kapcsolat része. Ha minden paraméterében megfelel, akkor az FTP proxy készít egy ideiglenes szûrési szabályt hozzá, amellyel az FTP kapcsolathoz tartozó csomagok mind a két irányba képesek lesznek vándorolni, természetesen a címfordítással együtt. Az összes többi bentrõl érkezõ csomag átlép ezen a szabályon és megáll a harmadiknál, ahol a felületnek és forrás IP-nek megfelelõen átfordítjuk a címét. Az IPNAT szûrési szabályai FTP-re Az FTP esetében csak egyetlen szûrési szabályra van szükségünk a hálózati címfordításba épített FTP proxy használatához. FTP proxy nélkül az alábbi három szabály kellene: # Kifelé engedélyezzük a belsõ gépek FTP elérést az internet irányába, # aktív és passzív módokban. pass out quick on rl0 proto tcp from any to any port = 21 flags S keep state # Kifelé engedélyezzük a passzív módhoz tartozó magasabb tartománybeli # adatcsatornákat. pass out quick on rl0 proto tcp from any to any port > 1024 flags S keep state # Aktív módban beengedjük az FTP szervertõl érkezõ adatcsatornát. pass in quick on rl0 proto tcp from any to any port = 20 flags S keep state IPFW tûzfalak IPFW Ez a szakasz fejlesztés alatt áll. Ennek megfelelõen a tartalma nem minden esetben pontos. Az IPFIREWALL (IPFW) a &os; által támogatott tûzfalazó alkalmazás, melyet a &os; Projektben résztvevõ önkéntesek fejlesztettek ki és tartanak karban. Régi típusú, állapottartás nélküli szabályokat használ, és az itt használatos szabályírási technikát egyszerû állapottartó megoldásnak nevezzük. Az IPFW szabvány &os;-ben levõ, mintaként szolgáló szabályrendszere (ez az /etc/rc.firewall állományban található meg) annyira egyszerû, hogy komolyabb módosítások nélkül nem ajánlatos használni. Ez a példa nem tartalmaz állapottartó szûrést, ami viszont a legtöbb esetben kívánatos lenne, ezért ezt a szakaszt nem erre alapozzuk. Az IPFW állapottartás nélküli szabályainak felépítésében olyan technikailag kifinomult leválogatási képességek bújnak meg, amelyek jócskán meghaladják az átlagos tûzfalépítõk tudását. Az IPFW elsõsorban olyan szakemberek vagy szakmailag elõrehaladott felhasználók számára készült, akiknek speciális csomagszûrési igényeik vannak. A különbözõ protokollok használatának és a hozzájuk tartozó fejlécinformációk mindenre kiterjedõ ismerete szinte nélkülözhetetlen az IPFW valódi erejének kihasználásához. Ez a szint azonban túlmutat a kézikönyv ezen szakaszának keretein. Az IPFW hét komponensbõl épül fel, melyek közül az elsõdleges a rendszermag tûzfalazásért felelõs szabályfeldolgozó és a hozzátartozó csomagnyilvántartás, majd ezt követi a naplózás, a hálózati címfordítást aktiváló divert szabály, valamint a komolyabb célok megvalósítására alkalmas lehetõségek: a forgalom korlátozásáért felelõs dummynet, a továbbküldésre alkalmas fwd szabály, a hálózati hidak támogatása, illetve az ipstealth. Az IPFW engedélyezése IPFW engedélyezése Az IPFW az alap &os; telepítésben külön, futás idõben betölthetõ modulként érhetõ el. Ha az rc.conf állományban megadjuk a firewall_enable="YES" beállítást, akkor a rendszer indulásakor ezt a modult dinamikusan betölti. Az IPFW-t csak akkor kell a &os; rendszermagjába beépítenünk, ha szükségünk van a címfordítási funkciójára is. Ha tehát az rc.conf állományban megadtuk a firewall_enable="YES" sort és újraindítottuk a számítógépünket, akkor a következõ fehérrel kiemelt üzenet fog megjelenni a rendszerindítás során: ipfw2 initialized, divert disabled, rule-based forwarding disabled, default to deny, logging disabled A logging disabled üzenetbõl kiderül, hogy a modul nem végez naplózást. A naplózást és a hozzátartozó részletesség szintjét úgy tudjuk beállítani, ha az /etc/sysctl.conf állományba felvesszük a következõ sorokat, amivel a következõ indításkor már mûködni fog: net.inet.ip.fw.verbose=1 net.inet.ip.fw.verbose_limit=5 A rendszermag beállításai a rendszermag beállításai IPFIREWALL a rendszermag beállításai IPFIREWALL_VERBOSE a rendszermag beállításai IPFIREWALL_VERBOSE_LIMIT IPFW a rendszermag beállításai Ha nem akarjuk kihasználni az IPFW által felkínált címfordítási lehetõségeket, akkor egyáltalán nem szükséges a &os; rendszermagjába belefordítani a támogatását. Ezért az alábbiakat csak kiegészítõ információként tüntettük fel. options IPFIREWALL Ez a beállítás engedélyezi az IPFW használatát a rendszermag részeként. options IPFIREWALL_VERBOSE Ezzel és a log kulcsszóval tudjuk az IPFW szabályain keresztülhaladó csomagokat naplózni. options IPFIREWALL_VERBOSE_LIMIT=5 Ez az érték korlátozza a &man.syslogd.8; segítségével naplózott azonos bejegyzések maximális számát. Ezt a beállítást olyan veszélyes környezetekben érdemes használnunk, ahol naplózni akarunk. Segítségével meg tudjuk akadályozni, hogy a rendszernapló elárasztásával megakasszák a rendszerünket. a rendszermag beállításai IPFIREWALL_DEFAULT_TO_ACCEPT options IPFIREWALL_DEFAULT_TO_ACCEPT Ezen beállítás hatására a tûzfal alapértelmezés szerint mindent átenged, ami általában akkor jöhet jól, amikor még csak ismerkedünk a tûzfallal. options IPV6FIREWALL options IPV6FIREWALL_VERBOSE options IPV6FIREWALL_VERBOSE_LIMIT options IPV6FIREWALL_DEFAULT_TO_ACCEPT Ezek a beállítások teljesen megegyeznek az IPv4 alapú társaikkal, csak ezek az IPv6-ra vonatkoznak. Ha nem akarunk IPV6-ot használni, akkor ne adjunk meg az IPV6FIREWALL beállításhoz szabályokat, és így az összes IPv6 csomag blokkolásra kerül. a rendszermag beállításai IPDIVERT options IPDIVERT Ezzel a beállítással engedélyezzük a címfordítás használatát. Ha nem adjuk meg az IPFIREWALL_DEFAULT_TO_ACCEPT beállítást, vagy ha nem engedélyezzük a bejövõ csomagokat, akkor a gépünkre semmilyen csomag nem lesz képes bejutni, illetve onnan kijutni. Az <filename>/etc/rc.conf</filename> beállításai Így tudjuk engedélyezni a tûzfalat: firewall_enable="YES" A &os;-hez mellékelt alapértelmezett tûzfaltípusok közül az /etc/rc.firewall állomány átolvasásával tudunk választani, és megadni az alábbi helyett: firewall_type="open" A következõ értékek állnak rendelkezésünkre: open — átengedi az összes forgalmat client — csak ezt a gépet védi simple — az egész hálózatot védi closed — a helyi felület kivételével minden IP alapú forgalmat tilt UNKNOWN — tiltja a tûzfal szabályainak betöltését állománynév — a tûzfal szabályait tartalmazó állomány abszolút elérési útvonala Két különbözõ módon lehet betölteni a saját ipfw szabályainkat. Az egyik közülük, ha a firewall_type változóban megadjuk a tûzfal szabályait tartalmazó állomány abszolút elérési útvonalát, az &man.ipfw.8; parancssori beállításai nélkül. Egy egyszerû szabályrendszer lehet például a következõ: add block in all add block out all Másrészrõl az firewall_script változóban is megadhatjuk azt a szkriptet, amelyben a rendszerindítás során meghívjuk ipfw parancsot. Az iménti szabályrendszert az alábbi szkripttel tudjuk kiváltani: #!/bin/sh ipfw -q flush ipfw add block in all ipfw add block out all Ha a firewall_type változó client vagy simple értékét használjuk, akkor az /etc/rc.firewall állományban található alapértelmezett szabályokat érdemes átvizsgálnunk, hogy kellõen illeszkednek-e az adott géphez. Hozzátennénk, hogy a fejezetben szereplõ példák azt feltételezik, hogy a firewall_script értéke az /etc/ipfw.rules állomány. A naplózás így engedélyezhetõ: firewall_logging="YES" A firewall_logging változó egyedül csak annyit tesz, hogy beállítja a net.inet.ip.fw.verbose sysctl változónak az 1 értéket (lásd ). A napló korlátozására nincs külön változó az rc.conf állományon belül, de az /etc/sysctl.conf állomány segítségével és manuálisan be tudjuk állítani a hozzátartozó változót: net.inet.ip.fw.verbose_limit=5 Amennyiben a gépünk átjáróként viselkedik, tehát a &man.natd.8; segítségével címfordítást végez, a ban olvashatunk utána, hogy ehhez az /etc/rc.conf állományban milyen beállításokat kell megadnunk. Az IPFW parancs ipfw Normál esetben az ipfw parancs használatos arra, hogy a tûzfal mûködése közben az aktív belsõ szabályai közé vegyünk fel vagy töröljünk közülük manuálisan bejegyzéseket. Ennek a módszernek az egyedüli hátránya, hogy az így végrehajtott módosítások el fognak veszni a rendszer leállításával. Itt inkább azt a megoldást javasoljuk, hogy az összes szabályt tegyük bele egy állományba és a rendszerindítás során ezt töltsük be, majd ha változtatni akarunk a tûzfalon, akkor ezt az állományt módosítsuk és a régiek törlésével töltsük be újra az egész szabályrendszert. Az ipfw parancs mellesleg remekül használható a jelenleg futó tûzfalszabályok megjelenítésére a konzolon. Az IPFW nyilvántartásában az egyes szabályokhoz dinamikusan jönnek létre számlálók, amelyek a rá illeszkedõ csomagokat számolják. A tûzfal tesztelése folyamán a szabályok és hozzátartozó számlálók lekérdezése a megfelelõ mûködés ellenõrzésének egyik lehetséges módja. A szabályokat így tudjuk egymás után felsoroltatni: &prompt.root; ipfw list A szabályokat így tudjuk az utolsó illeszkedésük idejével együtt megjeleníteni: &prompt.root; ipfw -t list A nyilvántartás lekérdezésekor a szabályok mellett az illeszkedõ csomagok száma is láthatóvá válik. Az elsõ sorban a szabály száma szerepel, majd ezt követi rendre az illeszkedõ kimenõ és bejövõ csomagok mennyisége, valamint végül maga a szabály. &prompt.root; ipfw -a list A statikus szabályok mellett a dinamikusakat így lehet kilistázni: &prompt.root; ipfw -d list A lejárt dinamikus szabályokat is meg tudjuk nézni: &prompt.root; ipfw -d -e list A számlálók nullázása: &prompt.root; ipfw zero Csak a SZÁM sorszámú szabályhoz tartozó számlálók nullázása: &prompt.root; ipfw zero SZÁM Szabályrendszerek az IPFW-ben Egy szabályrendszer lényegében nem több, mint ipfw szabályok egy csoportja, amelyekben a csomagokat tartalmuktól függõen továbbengedjük vagy eldobjuk. A gépek közti kétirányú csomagváltás egy kapcsolat létrejöttének számít. A tûzfalszabályok a csomagokat kétszer dolgozzák fel: elõször amikor az internetrõl megérkeznek, másodjára pedig akkor, amikor visszatérnek az internetre. Minden egyes TCP/IP szolgáltatást (vagyis a telnet, www, levelezés stb.) meghatároz a saját protokollja és a hozzátartozó port száma. Ez az az alapvetõ szûrési feltétel, ami alapján a szolgáltatásokhoz engedélyezését vagy tiltását megvalósító szabályokat megalkotjuk. IPFW a szabályok feldolgozásának sorrendje Amikor egy csomag eléri a tûzfalat, a szabályrendszer elsõ szabályával kerül összehasonlításra és amíg nem illeszkedik valamelyikre, addig lefut rá a többi szabály is fentrõl lefelé egyesével, a sorszámuknak megfelelõ növekvõ sorrendben. Ha a csomag megfelel valamelyik szabály leválogatási paramétereinek, akkor a benne megnevezett cselekvés zajlik le, és számára a feldolgozás befejezõdik. Ezt a viselkedést neveztük az elsõ illeszkedés nyer típusú keresésnek. Amennyiben a csomag egyetlen szabályra sem illeszkedik, akkor az ipfw 65535-ös sorszámú állandó szabálya fogja elcsípni, amely feladata szerint eldobja az összes hozzá beérkezõ csomagot anélkül, hogy bármit is válaszolna a csomag feladójának. A keresés a count, skipto és tee szabályok után még folytatódik. Az itt szereplõ utasítások az állapottartó keep state, a limit, in/out és via szabályokra építkeznek. Ezek szolgálnak az inkluzív tûzfalak megvalósításának alapvetõ eszközeiként. Az inkluzív tûzfal csak a szabályoknak megfelelõ szolgáltatásokat engedélyez. Segítségével meg tudjuk határozni, hogy a tûzfal mögül milyen szolgáltatásokat érhetünk el az interneten, valamint azt is megadhatjuk vele, hogy az internetrõl melyik szolgáltatásokhoz férhetnek hozzá a saját belsõ hálózatunkban. Felépítése szerint minden mást tilt. Az inkluzív jellegû tûzfalak sokkal bizontságosabbak az exkluzív tûzfalaknál, ezért itt most csak ilyen típusú szabályrendszerekkel foglalkozunk. A tûzfal szabályainak beállítása során nem árt óvatosnak lennünk, mert figyelmetlenségünk révén könnyen kizárathatjuk magunkat a gépünkrõl. A szabályok felépítése IPFW a szabályok felépítése Az itt bemutatásra kerülõ szabályok felépítését csak olyan mértékig részletezzük, ami elengedõ a szabványos inkluzív típusú tûzfalak kialakításához. A szabályok felépítésének pontos leírását az &man.ipfw.8; man oldalán találhatjuk meg. A szabályok kulcsszavakat tartalmaznak. Ezeket a kulcsszavakat soronként egy elõre rögzített sorrendben kell szerepeltetni. A kulcsszavakat a szövegben kiemeltük. Bizonyos kulcsszavakhoz további opciókhoz is tartozhatnak, amelyek gyakran maguk is kulcsszavak és szintén további opciókat tartalmazhatnak. A # egy megjegyzés kezdetét jelzi, mely egyaránt megjelenhet egy külön sorban, vagy egy szabályt tartalmazó sor végén. Az üres sorok nem vesznek részt a feldolgozásban. PARANCS SZABÁLY_SZÁM CSELEKVÉS NAPLÓZÁS SZÛRÉS ÁLLAPOTTARTÁS PARANCS Minden új szabály elõttt az add (mint hozzáadás) parancsnak kell szerepelni, amellyel a belsõ táblázatba tudjuk felvenni. SZABÁLY_SZÁM A szabályokhoz mindig tartozik egy sorszám is. CSELEKVÉS A szabályhoz az alábbi cselekvések valamelyike kapcsolható, amely akkor hajtódik végre, amikor a csomag megfelel a hozzátartozó szûrési feltételeknek. allow | accept | pass | permit A fentiek közül mindegyik ugyanazt jelenti, vagyis hatásukra az illeszkedõ csomag kilép a tûzfalból. Ez a szabály megállítja a keresést. check-state A csomagot a dinamikus szabályokat tároló táblázattal veti össze. Ha itt egyezést talál, akkor végrehajtja az egyezõ dinamikus szabályhoz tartozó cselekvést, minden más esetben továbblép a következõ szabályra. Ennek a szabálynak nincs illeszthetõ paramétere. Ha a szabályrendszerben nem szerepel ilyen, akkor a dinamikus szabályok vizsgálatát az elsõ keep-state vagy limit használatánál vonja be a rendszer. deny | drop Mind a két szó ugyanarra utal, vagyis a szabályra illeszkedõ csomagokat el kell dobni. Ebben az esetben a keresés befejezõdik. NAPLÓZÁS log vagy logamount Amikor egy csomag egy log kulcsszót tartalmazó szabályra illeszkedik, akkor a rendszernaplóban egy üzenet keletkezik a security (biztonság) funkción keresztül. A naplóba ténylegesen csak akkor kerül bele az üzenet, ha az adott szabály még nem haladta meg a hozzátartozó logamount paraméter értékét. Ha ezt nem adtuk meg, akkor az itt érvényes korlát a net.inet.ip.fw.verbose_limit sysctl változóból fog származni. A nulla érték mind a két esetben megszünteti ezt a korlátozást. Ha elértük a korlátot, akkor a naplózást úgy tudjuk újra engedélyezni, ha töröljük a naplózáshoz tartozó számláló értékét, lásd az ipfw reset log parancsot. A naplózás mindig az összes paraméter illeszkedésének ellenõrzése után történik, de még a cselekvés (accept, deny) elvégzése elõtt. Teljesen rajtunk múlik, hogyan milyen szabályokat naplózunk. SZÛRÉS Ebben a szakaszban azok a kulcsszavak találhatóak, amelyek segítségével a csomagok különbözõ tulajdonságait tudjuk megvizsgálni és eldönteni, hogy illeszkedik-e a szabályra vagy sem. A következõ általános tulajdonságokat tudjuk megvizsgálni, ebben a kötött sorrendben: udp | tcp | icmp Bármilyen más olyan protokoll is megadható, amely megtalálható az /etc/protocols állományban. Ezzel adjuk a csomaghoz tartozó protokollt. Használata kötelezõ. from forrás to cél Mind a from és to kulcsszavak IP-címek illesztésére alkalmasak. A szabályoknak tartalmazniuk kell a forrás ÉS a cél paramétereket is. Az any egy olyan kulcsszó, amely tetszõleges IP-címre illeszkedik. A me pedig egy olyan speciális kulcsszó, amely a tûzfalat mûködtetõ &os;-s gép (tehát ez a gép) adott felülethez tartozó IP-címét jelöli, mint ahogy a from me to any, from any to me, from 0.0.0.0/0 to any, from any to 0.0.0.0/0, from 0.0.0.0 to any, from any to 0.0.0.0 vagy from me to 0.0.0.0 paraméterekben. Az IP-címek numerikus pontozott formában a hálózati maszk hosszával együtt, vagy egyszerûen csak pontozott formában adhatóak meg. A hálózati maszkok megállapításában a címen található honlap nyújthat segítséget (angolul). port szám A portszámokat is ismerõ protokollok esetében (mint például a TCP vagy UDP) adhatjuk meg. Fontos, hogy itt annak a szolgáltatásnak a portszámát adjuk meg, amelyre a szabály vonatkozik. A szolgáltatás (az /etc/services állományból származó) nevét is megadhatjuk a port száma helyett. in | out A beérkezõ valamint a kimenõ csomagokat adhatjuk meg ezen a módon. Itt az in és out kulcsszavak, melyeket kötelezõ megadni a szabály részeként. via felület Név szerint az adott felületen keresztül haladó csomagokat tudjuk szûrni. A via kulcsszó hatására a használt felület is számítani fog a csomag feldolgozása során. setup Ez a kulcsszó a TCP csomagok esetében a kapcsolatok felépítésére vonatkozó kéréseket segít beazonosítani. keep-state Ez egy kötelezõ kulcsszó. Feldolgozásakor a tûzfal létrehoz dinamikus szabályt, amely alapértelmezés szerint az egyazon protokollt használó forrás és cél IP/port párosok közti kétirányú forgalomra fog automatikusan illeszkedni. limit {forráscím | forrásport | célcím | célport} A tûzfal csak N darab, a szabálynak megfelelõ azonos paraméterû kapcsolatot fog átengedi. Itt egy vagy több forrás- és célcím valamint forrás- és célport adható meg. A limit és a keep-state egy szabályon belül nem használható. A limit ugyanazokat az állapottartó funkciókat képviseli, mint a keep-state, csak a saját kiegészítéseivel megtoldva. ÁLLAPOTTARTÁS IPFW állapottartó szûrés Az állapottartó szûrés a kétirányú csomagváltásokat egy létrejött kapcsolatba sorolja. Olyan vizsgálatokat végez, amivel képes megállapítani, hogy a csomag küldõje és címzettje között kialakult kommunikáció követ-e valamilyen kétirányú csomagküldésre érvényes folyamatot. Az így felállított sablontól eltérõ összes csomag hamisnak minõsül és automatikusan eldobásra kerül. A check-state segítségével ellenõrizhetjük, hogy az adott csomag a IPFW szerint megfelel-e valamelyik dinamikusan leképzett szabálynak. Ha egyezik valamelyikõjükkel, akkor a csomag a tûzfalból kilépve folytatja útját és a kommunikációban soron következõ csomag számára létrejön egy másik dinamikus szabály. Ha nincs egyezés, akkor csomag feldolgozása a szabályrendszer következõ szabályánál folytatódik. A dinamikus szabályokat kezelõ rutin sebezhetõ, mivel ha egyszerre nagy mennyiségû SYN csomagot küldünk, akkor olyan sok dinamikus bejegyzés keletkezik, hogy egyszerûen kifogyunk a rendelkezésre álló erõforrásokból. A &os; fejlesztõi azonban az ilyen természetû támadások kivédésére is felkészítették, és kialakították belõle a limit opciót. Alkalmazásával le tudjuk korlátozni az egyszerre folyó párhuzamos kapcsolatok számát a forrás vagy a cél a limit paraméternél megadott mezõinek és a csomag IP-címe alapján. Így az adott szabályhoz és IP-címhez csak elõre rögzített mennyiségû nyitott állapotú dinamikus szabály létezhet egy idõben. Ha ezt a korlátot átlépjük, a csomag eldobódik. A tûzfal üzeneteinek naplózása IPFW naplózás A naplózás elõnyei nyilvánvalóak. Ha engedélyezzük, aktiválása után képesek leszünk olyan információknak utánanézni, mint például milyen csomagokat dobtunk el, honnan érkeztek, hova tartottak. Ez egy komoly fegyverünk lehet a potenciális támadókkal szemben. Azonban hiába engedélyezzünk önmagában a naplózást, attól az IPFW még saját magától nem fog naplózást elõíró szabályokat gyártani. A tûzfal karbantartóinak maguknak kell eldöntenie, hogy a szabályrendszerben mely szabályokhoz tartozzon naplózás, nekik kell felvenni ezekhez a log kulcsszót. Általában csak az eldobással járó deny típusú szabályokat vagy a bejövõ ICMP pingeket szokták naplózni. Gyakran úgy oldják meg ezt, hogy a szabályrendszer utolsó szabályaként lemásolják az ipfw alapértelmezett mindent eldobunk szabályát és a naplózást adják meg benne. Ezen a módon fény derül azokra a csomagokra, amelyek a szabályrendszerben semmire sem illeszkedtek. A naplózás azonban egy kétélû fegyver, mivel ha nem vagyunk elég körültekintõek, akkor a sok naplóinformáció között könnyen el tudunk veszni és a lemezünk is gyorsan betelhet a mindent elfoglaló naplóktól. Mellesleg a naplók megdagasztását célzó DoS típusú támadás a rendszerek lebénítására alkalmazott egyik legõsibb technika. Ezek az üzenetek nem csak a rendszernaplóba kerülnek bele, hanem az elsõdleges konzol képernyõjére is kiíródnak, ami egy idõ után idegesítõ tud lenni. A rendszermag IPFIREWALL_VERBOSE_LIMIT=5 beállításával azonban képesek vagyunk korlátozni azokat a rendszernapló felé küldött egymás után következõ üzeneteket, amelyek ugyanarra a szabályra vonatkoznak. Amikor ezt a beállítást megadjuk a rendszermag fordításánál, akkor az egyes szabályokhoz az általa meghatározott értéken felül nem jön létre több hasonló üzenet. Hiszen semmi sem derül ki 200 teljesen azonos naplóüzenetbõl. Például, ha az egyes szabályokhoz legfeljebb öt egymást követõ üzenetet engedélyezünk, akkor a többi fennmaradó azonos üzenetet összeszámolja a rendszer és a következõ módon közvetíti a rendszernaplózó szolgáltatás felé: last message repeated 45 times Ami magyarul így hangzik: az utolsó üzenet 45 alkalommal ismétlõdött meg Az összes csomagokkal kapcsolatos naplózás alapértelmezés szerint a /var/log/security állományba kerül, amelyet az /etc/syslog.conf állomány definiál. Szabályokat tartalmazó szkript készítése A rutinosabb IPFW felhasználók a szabályokat egy állományban programozzák le olyan stílusban, hogy szkriptként is futtatható legyen. Ennek az egyik legnagyobb elõnye, hogy a tûzfal szabályai így egyszerre cserélhetõek a rendszer újraindítása nélkül. Ez a módszer nagyon kényelmes az új szabályok kipróbálásánál, mivel tetszõleges alkalommal végrehajthatjuk. Mivel ez egy szkript, ki tudjuk használni az itt megszokott szimbolikus helyettesítés által felkínált lehetõségeket, és ezzel a gyakran használt értékeket is egyszerre több szabályban tudjuk helyettesíteni. Erre a következõkben fogunk egy konkrét példát látni. A szkript felépítése kompatibilis a sh, csh és tcsh parancsértelmezõkkel. A szimbolikus mezõk helyettesítését a $ vagyis dollárjel vezeti be. Maguk a szimbolikus mezõk nem tartalmazzák a $ elõtagot. A szimbolikus mezõk értékeit "kettõs idézõjelek" között kell megadni. A szabályok összeírását kezdjük el így: ####### itt kezdõdik az ipfw szabályait tartalmazó szkript ###### # ipfw -q -f flush # töröljük az összes aktuális szabályt # Set defaults oif="tun0" # a kimenõ felület odns="192.0.2.11" # az internet szolgáltató névszerverének IP-címe cmd="ipfw -q add " # a szabályok hozzáadásához szükséges elemek ks="keep-state" # csupán a lustaság miatt $cmd 00500 check-state $cmd 00502 deny all from any to any frag $cmd 00501 deny tcp from any to any established $cmd 00600 allow tcp from any to any 80 out via $oif setup $ks $cmd 00610 allow tcp from any to $odns 53 out via $oif setup $ks $cmd 00611 allow udp from any to $odns 53 out via $oif $ks #### itt fejezõdik be az ipfw szabályait tartalmazó szkript ###### Ezzel készen is vagyunk. Most ne törõdjünk a példában szereplõ szabályokkal, itt most a szimbolikus helyettesítés használatát igyekeztük bemutatni. Ha az iménti példát az /etc/ipfw.rules állományba mentettük el, akkor az alábbi parancs kiadásával tudjuk újratölteni a benne szereplõ szabályokat: &prompt.root; sh /etc/ipfw.rules Az /etc/ipfw.rules állományt egyébként tetszõleges néven hívhatjuk és bárhová rakhatjuk. Ugyanez természetesen elérhetõ a következõ parancsok egymás utáni begépelésével is: &prompt.root; ipfw -q -f flush &prompt.root; ipfw -q add check-state &prompt.root; ipfw -q add deny all from any to any frag &prompt.root; ipfw -q add deny tcp from any to any established &prompt.root; ipfw -q add allow tcp from any to any 80 out via tun0 setup keep-state &prompt.root; ipfw -q add allow tcp from any to 192.0.2.11 53 out via tun0 setup keep-state &prompt.root; ipfw -q add 00611 allow udp from any to 192.0.2.11 53 out via tun0 keep-state Állapottartó szabályrendszerek A most következõ címfordítás nélküli szabályrendszer arra mutat példát, hogyan valósítsunk meg egy biztonságos inkluzív tûzfalat. Az inkluzív tûzfalak csak a szabályainak megfelelõ szolgáltatásokat engedik át, minden mást alapértelmezés szerint tiltanak. Minden tûzfalhoz legalább két felület tartozik, és a mûködéséhez ezek mindegyikéhez meg kell adnunk szabályokat. Az &unix; mintájú operációs rendszer, köztül a &os; is olyan, hogy a rendszerben belüli kommunikációt a lo0 nevû felületen és a 127.0.0.1 IP-címen bonyolítja le. A tûzfalban mindenképpen szerepelniük kell olyan szabályoknak, amelyek gondoskodnak ezen speciális belsõ csomagok zavartalan közlekedésérõl. Az internet felé csatlakozó felület lesz az, amelyen keresztül a kifelé menõ kéréseket hitelesítjük és vezéreljük az internet elérését, valamint ahol szûrjük az internet felõl érkezõ kéréseket. Ez lehet a PPP esetében a tun0 eszköz, vagy a DSL-, illetve kábelmodemhez csatlakozó hálózati kártya. Abban az esetben, amikor egy vagy több hálózati kártyával csatlakozunk a tûzfal mögött található belsõ helyi hálózatra, szintén gondoskodnunk kell a helyi hálózaton belül mozgó csomagok akadálymentes továbbításáról. A szabályokat elõször három nagyobb osztályba kell sorolnunk: az összes szabadon forgalmazó felület, a publikus kimenõ és a publikus bejövõ felület csoportjába. A publikus felületekhez tartozó csoportokban úgy kell rendeznünk a szabályokat, hogy elõre kerüljenek a gyakrabban használtak és hátra a kevésbé használtak, valamint a csoportok utolsó szabálya blokkoljon és naplózzon minden csomagot az adott felületen és irányban. A következõ szabályrendszerben szereplõ, a kimenõ kapcsolatokat tartalmazó csoport csak olyan allow típusú szabályokat tartalmaz, amelyek szûrési feltételei egyértelmûen azonosítják az interneten elérhetõ szolgáltatásokat. Az összes szabályban megjelennek a proto, port, in/out, via és keep state opciók. A proto tcp szabályokban emellett szerepel még egy setup opció is, amellyel a kapcsolatokat kezdeményezõ csomagokat tudjuk azonosítani és felvenni az állapottartásért felelõs dinamikus szabályok közé. A bejövõ felülettel foglalkozó csoport elsõsorban a kéretlen csomagokat igyekszik blokkolni, aminek két oka is van. Elõször is a blokkolt csomagról elképzelhetõ, hogy egyébként érvényes és valamelyik késõbbi szabály fogja hitelesíteni. Másodszor ezekkel a szabályokkal olyan szabálytalan idõközönként érkezõ csomagokat tudunk eldobni, amelyeket nem akarunk a naplóban feljegyezni, és ennek segítségével távoltartjuk az utolsó, mindent blokkoló és naplózó szabálytól. A csoport utolsó szabálya dobja el és naplózza a hozzá befutó összes csomagot, illetve ezen keresztül rögzíthetünk olyan jogi bizonyítékot, amellyel hivatalosan fel tudunk lépni a rendszerünket támadó emberek ellen. Amit még nem szabad elfelejtenünk: a tûzfal az eldobott csomagokra egyáltalán nem válaszol, egyszerûen csak eltûnnek, mintha sosem lettek volna. Ennek köszönhetõen a támadóknak fogalma sem lesz arról, hogy a csomagjaik elérték-e a rendszerünket. Minél kevesebbet tudnak a támadók a rendszerünkrõl, annál biztonságosabb. Amikor ismeretlen portokra érkezõ csomagokat naplózunk, érdemes az /etc/services/ állományban vagy címen (angolul) utánanézni a porthoz tartozó szolgáltatásnak. A különbözõ trójai programok által portok számai ezen a linken érhetõek el (angolul): . Példa egy inkluzív szabályrendszerre A most következõ, címfordítást nem tartalmazó szabályrendszer teljesen inkluzív típusú. Ha ezt használjuk, nem járunk rosszul. Egyszerûen csak annyit kell tennünk, hogy megjegyzésbe tesszük az olyan szolgáltatásokra vonatkozó szabályokat, amelyeket nem akarunk engedélyezni. Amikor pedig olyan üzenetek jelennek meg a naplóban, amelyeket nem akarunk tovább látni, a bejövõ kapcsolatokhoz vegyünk fel egy deny típusú szabályt hozzájuk. Minden szabályban cseréljük ki a dc0 felületet arra a hálózati kártyára, amely közvetlenül csatlakoztatja rendszerünket az internethez. A felhasználói PPP esetében ez a tun0. A szabályok használatában felfedezhetünk egyfajta rendszerszerûséget: Mindegyik sorban, ahol az internet felé nyitunk meg egy kapcsolatot, a opciót használjuk. Az internetrõl az összes hitelesített szolgáltatás elérése tartalmazza a opciót az elárasztások kivédése miatt. Az összes szabályban az vagy az paraméterrel megadjuk szûrni kívánt forgalom irányát. Az összes szabályban szerepel a paraméterrel a csomagokat továbbító felület neve. Az alábbi szabályokat tegyük az /etc/ipfw.rules állományba. ############## Itt kezdõdnek az IPFW szabályai ########################## # Kezdés elõtt töröljük az összes aktív szabályt. ipfw -q -f flush # Állítsuk be a parancsok további szükséges opciót. cmd="ipfw -q add" pif="dc0" # az internethez csatlakozó # felület neve ################################################################# # A belsõ hálózat számára ne korlátozzunk semmit se. # Ha nincs helyi hálózatunk, akkor erre nincs szükségünk. # Az 'xl0' nevét írjuk át a helyi hálózatra csatlakozó # felület nevére. ################################################################ #$cmd 00005 allow all from any to any via xl0 ################################################################ # A rendszer belsõ felületét se szûrjük. ################################################################ $cmd 00010 allow all from any to any via lo0 ################################################################ # A csomagot engedjük át a tûzfalon, ha korábban már felvettünk # hozzá egy dinamikus szabályt a keep-state opcióval. ################################################################ $cmd 00015 check-state ################################################################ # Az internet felé forgalmazó felület (kimenõ kapcsolatok) # A saját hálózatunkról belülrõl vagy errõl az átjáróról # kezdeményezett kapcsolatokat vizsgáljuk az internet felé. ################################################################ # Kifelé engedélyezzük az internet-szolgáltatónk névszerverének # elérését. Az x.x.x.x a szolgáltatónk névszerverének IP-címe # legyen. Ha a szolgáltatónak több névszervere is van, akkor # másoljuk le ezeket a sorokat és az /etc/resolv.conf # állományban található IP-címeket helyettesítsük be. $cmd 00110 allow tcp from any to x.x.x.x 53 out via $pif setup keep-state $cmd 00111 allow udp from any to x.x.x.x 53 out via $pif keep-state # Kábel/DSL konfigurációk esetében kifelé engedélyezzük a # szolgáltatónk DHCP szerverének elérését. Ha a "felhasználói # PPP"-t használjuk, akkor erre nem lesz szükségünk, az egész # csoportot törölhetjük. Az alábbi szabállyal csíphetjük el a # beírandó IP-címet. Ha a naplóban megtaláltuk, akkor vegyük # ki az elsõ szabályt, a másodikba írjuk bele a címet és # engedélyezzük. $cmd 00120 allow log udp from any to any 67 out via $pif keep-state #$cmd 00120 allow udp from any to x.x.x.x 67 out via $pif keep-state # Kifelé engedélyezzük a szabvány nem biztonságos WWW # funkció elérését. $cmd 00200 allow tcp from any to any 80 out via $pif setup keep-state # Kifelé engedélyezzük a biztonságos HTTPS funkció # elérését TLS SSL használatával. $cmd 00220 allow tcp from any to any 443 out via $pif setup keep-state # Kifelé engedélyezzük a e-mailek küldését és fogadását. $cmd 00230 allow tcp from any to any 25 out via $pif setup keep-state $cmd 00231 allow tcp from any to any 110 out via $pif setup keep-state # Kifelé engedélyezzük a FreeBSD (a make install és a CVSUP) # funkcióit. Ezzel lényegében a rendszeradminisztrátornak # ,,ISTENI'' jogokat adunk. $cmd 00240 allow tcp from me to any out via $pif setup keep-state uid root # Kifelé engedélyezzük a pinget. $cmd 00250 allow icmp from any to any out via $pif keep-state # Kifelé engedélyezzük az idõ szolgáltatást. $cmd 00260 allow tcp from any to any 37 out via $pif setup keep-state # Kifelé engedélyezzük az nntp news szolgáltatást # (vagyis a hírcsoportokat) $cmd 00270 allow tcp from any to any 119 out via $pif setup keep-state # Kifelé engedélyezzük a biztonságos FTP, telnet és SCP # elérését az SSH (secure shell) használatával. $cmd 00280 allow tcp from any to any 22 out via $pif setup keep-state # Kifelé engedélyezzük a whois szolgáltatást. $cmd 00290 allow tcp from any to any 43 out via $pif setup keep-state # Dobjuk el és naplózzunk mindent, ami megpróbál kijutni. # Ez a szabály gondoskodik róla, hogy alapértelmezés szerint # mindent blokkoljunk. $cmd 00299 deny log all from any to any out via $pif ################################################################ # Az internet felõli felület (bejövõ kapcsolatok) # A saját hálózatunk felé vagy erre az átjáróra # nyitott kapcsolatokat vizsgáljuk az internet felõl. ################################################################ # Blokkoljunk minden olyan bejövõ forgalmat, amely a fenntartott # címtartományok felé tart. $cmd 00300 deny all from 192.168.0.0/16 to any in via $pif #RFC 1918: privát IP $cmd 00301 deny all from 172.16.0.0/12 to any in via $pif #RFC 1918: privát IP $cmd 00302 deny all from 10.0.0.0/8 to any in via $pif #RFC 1918: privát IP $cmd 00303 deny all from 127.0.0.0/8 to any in via $pif #helyi $cmd 00304 deny all from 0.0.0.0/8 to any in via $pif #helyi $cmd 00305 deny all from 169.254.0.0/16 to any in via $pif #DHCP $cmd 00306 deny all from 192.0.2.0/24 to any in via $pif #dokumentációs célokra fenntartott $cmd 00307 deny all from 204.152.64.0/23 to any in via $pif #Sun klaszterek összekötésére használt -$cmd 00308 deny all from 224.0.0.0/3 to any in via $pif #D és E osztályú többesküldés +$cmd 00308 deny all from 224.0.0.0/3 to any in via $pif #D és E osztályú multicast # A nyilvános pingek tiltása. $cmd 00310 deny icmp from any to any in via $pif # Az ident szolgáltatás tiltása. $cmd 00315 deny tcp from any to any 113 in via $pif # Blokkoljuk az összes Netbios szolgáltatást: 137=név, 138=datagram, # 139=session. A Netbios az MS Windows megosztását implementálja. # Blokkoljuk az MS Windows hosts2 névszerver kéréseit is a 81-es # porton. $cmd 00320 deny tcp from any to any 137 in via $pif $cmd 00321 deny tcp from any to any 138 in via $pif $cmd 00322 deny tcp from any to any 139 in via $pif $cmd 00323 deny tcp from any to any 81 in via $pif # Eldobjuk az összes késõn érkezõ csomagot. $cmd 00330 deny all from any to any frag in via $pif # Eldobjuk azokat az ACK csomagokat, amelyek egyik dinamikus # szabálynak sem felelnek meg. $cmd 00332 deny tcp from any to any established in via $pif # Befelé engedélyezzük a szolgáltató DHCP szerverének válaszát. Ebben # a szabályban csak a DHCP szerver IP-címe szerepelhet, mivel ez az # egyetlen olyan hitelesített forrás, ami ilyen csomagokat küldhet. # Ez csak a kábeles és DSL típusú kapcsolatok esetében szükséges. # Amikor a "felhasználói PPP"-vel csatlakozunk az internethez, nem # kell ez a szabály. Ugyanazt az IP-címet kell megadnunk, amelyet a # kimenõ kapcsolatoknál is. #$cmd 00360 allow udp from any to x.x.x.x 67 in via $pif keep-state # Befelé engedélyezzük a szabvány WWW funkciót, mivel webszerverünk # is van. $cmd 00400 allow tcp from any to me 80 in via $pif setup limit src-addr 2 # Befelé engedélyezzük a biztonságos FTP, telnet és SCP # típusú kapcsolatokat az internetrõl. $cmd 00410 allow tcp from any to me 22 in via $pif setup limit src-addr 2 # Befelé engedélyezzük az internetrõl érkezõ nem biztonságos telnet # kapcsolatokat. Azért tekintjük nem biztonságosnak, mert az # azonosítók és a jelszavak az interneten titkosítatlanul vándorolnak. # Töröljük ezt a csoportot, ha nincs telnet szolgáltatásunk. $cmd 00420 allow tcp from any to me 23 in via $pif setup limit src-addr 2 # Dobjuk el és naplózzuk az összes többi kintrõl érkezõ csomagot. $cmd 00499 deny log all from any to any in via $pif # Alapértelmezés szerint dobjuk el mindent. Az ide érkezõ # csomagokat is naplózzuk, amibõl többet is ki tudunk majd # deríteni. $cmd 00999 deny log all from any to any ############# Itt fejezõdnek be az IPFW szabályai ##################### Példa hálózati címfordításra és állapottartásra címfordítás és az IPFW Az IPFW címfordító funkciójának kihasználásához további konfigurációs beállítások alkalmazására is szükségünk lesz. A rendszermagban opció között meg kell adnunk az option IPDIVERT sort a többi IPFIREWALL sor mellett, és fordítanunk egy saját verziót. Emellett még az /etc/rc.conf állományban is engedélyezni kell az IPFW alapvetõ funkcióit. natd_enable="YES" # engedélyezzük a címfordításért felelõs démont natd_interface="rl0" # az internet felé mutató hálózati kártya neve natd_flags="-dynamic -m" # -m = a portszámok megtartása, ha lehetséges Az állapottartó szabályok használata a divert natd címfordítási opcióval együtt nagyban növeli a szabályrendszer leprogramozásának bonyolultságát. A check-state és divert natd szabályok helye kritikus a megfelelõ mûködés tekintetében. Az eddig megszokott egyszerû viselkedés itt már nem érvényesül. Bevezetünk egy új cselekvést is, amelynek a neve skipto. A skipto parancs használatához elengedhetetlen a szabályok sorszámozása, mivel pontosan tudnunk kell, hogy a skipto hatására hova kell ugrania a vezérlésnek. A következõ példában nem fogunk sok megjegyzést látni, mivel benne az egyik lehetséges programozási stílust próbáljuk érzékeltetni és a csomagok szabályrendszerek közti áramlását magyarázzuk. A feldolgozás a szabályokat tartalmazó állomány tetején található elsõ szabállyal kezdõdik, és innen egyesével pereg végig lefelé a feldolgozás egészen addig, amíg a csomag a szûrési feltételek valamelyikének eleget nem tesz és távozik a tûzfalból. Leginkább a 100-as, 101-es, 450-es, 500-as és 510-es sorszámú szabályokat emelnénk ki. Ezek vezérlik kimenõ és bejövõ csomagok fordítását, ezért a hozzájuk tartozó dinamikus állapottartó bejegyzések mindig a helyi hálózat IP-címeire hivatkoznak. Amit még érdemes megfigyelnünk, hogy az összes áteresztõ és eldobó szabályban szerepel a csomag haladási iránya (tehát kimenõ vagy éppen bejövõ) és az érintett felület megnevezése. Emellett azt is vegyük észre, hogy az összes kifelé irányuló kapcsolatlétrehozási kérés az 500-as sorszámú szabályhoz fog ugrani a címfordítás elvégzéséhez. Tegyük fel, hogy a helyi hálózatunkon levõ felhasználók szeretnek honlapokat nézgetni az interneten. A honlapok a 80-as porton keresztül kommunikálnak. Tehát amikor egy ilyen csomag eléri a tûzfalat, nem fog illeszkedni a 100-as szabályra, mert a fejléce szerint kifelé halad és nem befelé. A 101-es szabályon is átlép, mivel ez az elsõ csomag, így a dinamikus állapottartó táblázatban sem szerepel még. A csomag végül a 125-ös szabályra fog illeszkedni: kifelé halad az internetre csatlakozó hálózati kártyán. A csomagban azonban még mindig az eredeti forrás IP-címe található, amely a helyi hálózat egyik gépére hivatkozik. A szabály illeszkedésekor két cselekvés is végbemegy. A opció hatására ez a szabály felveszi ezt a kapcsolatot az állapottartó dinamikus szabályok közé és végrehajtja a másik megadott feladatot. Ez a feladat része a dinamikus táblázatba rögzített bejegyzésnek, ami ebben az esetben a skipto 500 (ugorjunk az 500-as szabályra) lesz. Az 500-as szabály a továbbküldés elõtt lefordítja a csomag forrás IP-címét. Ezt ne felejtsük el, nagyon fontos! A csomag ezután eljut a céljához, és visszatérve ismét belép a szabályrendszer tetején. Ezúttal illeszkedni fog a 100-as szabályra és a cél IP-címét visszafordítjuk a helyi hálózatunk megfelelõ gépének címére. Ezután a check-state szabályhoz kerül, amely megtalálja a dinamikus szabályok között és továbbengedi a belsõ hálózatra. Ezzel visszakerül a küldõ géphez, amely egy újabb csomagot küld egy újabb adatszeletet kérve a távoli szervertõl. Ekkor már a check-state szabály megtalálja a hozzátartozó bejegyzést a dinamikus szabályok között és végrehajtódik a korábban letárolt skipto 500 mûvelet. A csomag erre az 500-as szabályra ugrik, ahol lefordítjuk a címét és továbbküldjük. Az bejövõ oldalon minden, ami egy korábban kialakult kapcsolat részeként érkezik, automatikusan a check-state és a megfelelõ helyre rakott divert natd szabályok által dolgozódik fel. Itt mindössze a rossz csomagok eldobásával és a hitelesített szolgáltatások elérésének biztosításával kell foglalkoznunk. Például a tûzfalon egy webszerver fut, és azt szeretnénk, hogy az internetrõl képesek legyenek elérni a rajta levõ oldalakat. Az újonnan beérkezõ kapcsolatépítési kérelem a 100-as szabályra fog illeszkedni, amelynek a cél IP-címét a tûzfal helyi hálózaton található címére fogjuk leképezni. A csomagot ezután még megvizsgáljuk, nem tartalmaz-e valamilyen huncutságot, majd végül a 425-ös szabálynál fog kikötni. Az egyezéskor két dolog történhet: a csomaghoz felveszünk egy dinamikus szabályt, de ezúttal az adott forrás IP-címrõl érkezõ kapcsolatkérések számát 2-re lekorlátozzuk. Ezzel az adott szolgáltatás portján meg tudjuk óvni a tûzfalat üzemeltetõ gépet a DoS típusú támadásoktól. A csomagot ezután hozzátartozó cselekvés szerint továbbengedjük a belsõ hálózat felé. Visszatéréskor a tûzfal felismeri, hogy a csomag egy már meglevõ kapcsolathoz tartozik, ezért közvetlenül az 500-as szabályhoz kerül címfordításra, majd a kimenõ felületen keresztül továbbküldjük. Íme az elsõ példa egy ilyen szabályrendszerre: #!/bin/sh cmd="ipfw -q add" skip="skipto 500" pif=rl0 ks="keep-state" good_tcpo="22,25,37,43,53,80,443,110,119" ipfw -q -f flush $cmd 002 allow all from any to any via xl0 # nem szûrjük a belsõ hálózatot $cmd 003 allow all from any to any via lo0 # nem szûrjük a helyi felületet $cmd 100 divert natd ip from any to any in via $pif $cmd 101 check-state # A kimenõ csomagok hitelesítése: $cmd 120 $skip udp from any to xx.168.240.2 53 out via $pif $ks $cmd 121 $skip udp from any to xx.168.240.5 53 out via $pif $ks $cmd 125 $skip tcp from any to any $good_tcpo out via $pif setup $ks $cmd 130 $skip icmp from any to any out via $pif $ks $cmd 135 $skip udp from any to any 123 out via $pif $ks # Az összes olyan csomagot eldobjuk, amely a fenntartott # címtartományokba tart: $cmd 300 deny all from 192.168.0.0/16 to any in via $pif #RFC 1918: privát IP $cmd 301 deny all from 172.16.0.0/12 to any in via $pif #RFC 1918: privát IP $cmd 302 deny all from 10.0.0.0/8 to any in via $pif #RFC 1918: privát IP $cmd 303 deny all from 127.0.0.0/8 to any in via $pif #helyi $cmd 304 deny all from 0.0.0.0/8 to any in via $pif #helyi $cmd 305 deny all from 169.254.0.0/16 to any in via $pif #DHCP $cmd 306 deny all from 192.0.2.0/24 to any in via $pif #dokumentációs célokra fenntartott $cmd 307 deny all from 204.152.64.0/23 to any in via $pif #Sun klaszter -$cmd 308 deny all from 224.0.0.0/3 to any in via $pif #D és E osztályú többesküldés +$cmd 308 deny all from 224.0.0.0/3 to any in via $pif #D és E osztályú multicast # Az érkezõ csomagok hitelesítése: $cmd 400 allow udp from xx.70.207.54 to any 68 in $ks $cmd 420 allow tcp from any to me 80 in via $pif setup limit src-addr 1 $cmd 450 deny log ip from any to any # Ide ugrunk a kimenõ állapottartó szabályoknál: $cmd 500 divert natd ip from any to any out via $pif $cmd 510 allow ip from any to any ##################### a szabályok vége ################## A következõ példa teljesen megegyezik az elõzõvel, azonban itt már dokumentációs szándékkal szerepelnek megjegyzések is, melyek a tapasztalatlan IPFW szabályíróknak segítik jobban megérteni a szabályok pontos mûködését. A második példa: #!/bin/sh ############# Az IPFW szabályai itt kezdõdnek ########################### # Kezdés elõtt töröljük az összes jelenleg aktív szabályt: ipfw -q -f flush # Beállítjuk a parancsok megfelelõ elõtagjait: cmd="ipfw -q add" skip="skipto 800" pif="rl0" # az internethez csatlakozó # hálózati felület neve ################################################################# # A belsõ hálózat számára ne korlátozzunk semmit se. # Ha nincs helyi hálózatunk, akkor erre nincs szükségünk. # Az 'xl0' nevét írjuk át a helyi hálózatra csatlakozó # felület nevére. ################################################################# $cmd 005 allow all from any to any via xl0 ################################################################# # A rendszer belsõ felületét se szûrjük. ################################################################# $cmd 010 allow all from any to any via lo0 ################################################################# # Ellenõrizzük, hogy ez egy beérkezõ csomag és ha igen, akkor # fordítsuk a címét. ################################################################# $cmd 014 divert natd ip from any to any in via $pif ################################################################# # Ha ehhez a csomaghoz korábban már vettük fel dinamikus # szabályt a keep-state opció révén, akkor engedjük tovább. ################################################################# $cmd 015 check-state ################################################################# # Az internet felé forgalmazó felület (kimenõ kapcsolatok) # A saját hálózatunkról belülrõl vagy errõl az átjáróról # kezdeményezett kapcsolatokat vizsgáljuk az internet felé. ################################################################# # Kifelé engedélyezzük az internet-szolgáltatónk névszerverének # elérését. Az x.x.x.x a szolgáltató névszerverének IP-címe # lesz. Ha a szolgáltatónknak több névszervere is van, akkor # az /etc/resolv.conf állományból nézzük ki a címeiket és # másoljuk le az alábbi sor mindegyikükhöz. $cmd 020 $skip tcp from any to x.x.x.x 53 out via $pif setup keep-state # A kábeles és DSL kapcsolatok esetén engedélyezzük a szolgáltató # DHCP szerverének elérését. $cmd 030 $skip udp from any to x.x.x.x 67 out via $pif keep-state # Kifelé engedélyezzük a szabvány nem biztonságos WWW funkciót $cmd 040 $skip tcp from any to any 80 out via $pif setup keep-state # Kifelé engedélyezzük a biztonságos HTTPS funkciót a TLS SSL # használatával. $cmd 050 $skip tcp from any to any 443 out via $pif setup keep-state # Kifelé engedélyezzük az e-mailek küldését és fogadását. $cmd 060 $skip tcp from any to any 25 out via $pif setup keep-state $cmd 061 $skip tcp from any to any 110 out via $pif setup keep-state # Kifelé engedélyezzük a FreeBSD (make install és CVSUP) funkcióit. # Ezzel a rendszeradminisztrátornak ,,ISTENI'' jogokat adunk. $cmd 070 $skip tcp from me to any out via $pif setup keep-state uid root # Kifelé engedélyezzük a pinget. $cmd 080 $skip icmp from any to any out via $pif keep-state # Kifelé engedélyezzük az idõ szolgáltatást. $cmd 090 $skip tcp from any to any 37 out via $pif setup keep-state # Kifelé engedélyezzük az nntp news szolgáltatást (tehát a # hírcsoportokat). $cmd 100 $skip tcp from any to any 119 out via $pif setup keep-state # Kifelé engedélyezzük a biztonságos FTP, telnet és SCP # funkciókat az SSH (secure shell) használatával. $cmd 110 $skip tcp from any to any 22 out via $pif setup keep-state # Kifelé engedélyezzük ki a whois kéréseket. $cmd 120 $skip tcp from any to any 43 out via $pif setup keep-state # Kifelé engedélyezzük az NTP idõszerver elérését. $cmd 130 $skip udp from any to any 123 out via $pif keep-state ################################################################# # Az internet felõli felület (bejövõ kapcsolatok) # A saját hálózatunk felé vagy erre az átjáróra # nyitott kapcsolatokat vizsgáljuk az internet felõl. ################################################################# # Tiltsuk a fenntartott címtartományok felé haladó összes beérkezõ # forgalmat. $cmd 300 deny all from 192.168.0.0/16 to any in via $pif #RFC 1918: privát IP $cmd 301 deny all from 172.16.0.0/12 to any in via $pif #RFC 1918: privát IP $cmd 302 deny all from 10.0.0.0/8 to any in via $pif #RFC 1918: privát IP $cmd 303 deny all from 127.0.0.0/8 to any in via $pif #helyi $cmd 304 deny all from 0.0.0.0/8 to any in via $pif #helyi $cmd 305 deny all from 169.254.0.0/16 to any in via $pif #DHCP $cmd 306 deny all from 192.0.2.0/24 to any in via $pif #dokumentációs célokra fenntartott $cmd 307 deny all from 204.152.64.0/23 to any in via $pif #Sun klaszter -$cmd 308 deny all from 224.0.0.0/3 to any in via $pif #D és E osztályú többesküldés +$cmd 308 deny all from 224.0.0.0/3 to any in via $pif #D és E osztályú multicast # Az ident tiltása. $cmd 315 deny tcp from any to any 113 in via $pif # Blokkoljuk az összes Netbios szolgáltatást: 137=név, 138=datagram, # 139=session. A Netbios az MS Windows megosztását implementálja. # Blokkoljuk az MS Windows hosts2 névszerver kéréseit is a 81-es # porton. $cmd 320 deny tcp from any to any 137 in via $pif $cmd 321 deny tcp from any to any 138 in via $pif $cmd 322 deny tcp from any to any 139 in via $pif $cmd 323 deny tcp from any to any 81 in via $pif # Dobjuk el a késõn érkezõ csomagokat. $cmd 330 deny all from any to any frag in via $pif # Dobjuk el azokat az ACK csomagokat, amelyekre nincs # dinamikus szabály. $cmd 332 deny tcp from any to any established in via $pif # Engedélyezzük a szolgáltató DHCP szerverétõl érkezõ forgalmat. Ennek # a szabálynak tartalmaznia kell a DHCP szerver címét, mert csak tõle # fogadunk el ilyen típusú csomagokat. Egyedül csak kábeles vagy DSL # konfigurációk esetén használatos, a "felhasználói PPP" esetében # törölhetjük. Ez ugyanaz az IP-cím, amelyet a kimenõ kapcsolatoknál # megadtunk. $cmd 360 allow udp from x.x.x.x to any 68 in via $pif keep-state # Befelé engedélyezzük a szabvány WWW funkciót, mivel van # webszerverünk. $cmd 370 allow tcp from any to me 80 in via $pif setup limit src-addr 2 # Befelé engedélyezzük a biztonságos FTP, telnet és SCP # használatát az internetrõl. $cmd 380 allow tcp from any to me 22 in via $pif setup limit src-addr 2 # Befelé engedélyezzük a nem biztonságos telnet elérését az # internetrõl. Azért nem tekintjük biztonságosnak, mert az # azonosítókat és a jelszavakat az interneten titkosítatlanul # közvetíti. Ha nincs telnet szolgáltatásunk, akkor törölhetjük is ezt # a csoportot. $cmd 390 allow tcp from any to me 23 in via $pif setup limit src-addr 2 # Dobjuk el és naplózzuk az összes internetrõl érkezõ hitelesítetlen kapcsolatot. $cmd 400 deny log all from any to any in via $pif # Dobjuk el és naplózzuk az összes internetre menõ hitelesítetlen kapcsolatot. $cmd 450 deny log all from any to any out via $pif # Ez lesz a kimenõ szabályokhoz tartozó "skipto" célja. $cmd 800 divert natd ip from any to any out via $pif $cmd 801 allow ip from any to any # Minden mást alapértelmezés szerint tiltunk és naplózunk. $cmd 999 deny log all from any to any ############# Az IPFW szabályai itt fejezõdnek be ##################### diff --git a/hu_HU.ISO8859-2/books/handbook/mirrors/chapter.sgml b/hu_HU.ISO8859-2/books/handbook/mirrors/chapter.sgml index 69e87685fe..48642ea484 100644 --- a/hu_HU.ISO8859-2/books/handbook/mirrors/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/mirrors/chapter.sgml @@ -1,4112 +1,4117 @@ A &os; beszerzése CD és DVD kiadók Kiskereskedelmi dobozos termékek A &os; beszerezhetõ számos kiskereskedõtõl dobozos termék formájában is (&os; CD-k, egyéb szoftverek és nyomtatott dokumentáció):
CompUSA WWW:
Frys Electronics WWW:
CD- és DVD-készletek &os; CD- és DVD-készletek rengeteg helyrõl rendelhetõek:
BSD Mall (Daemon News) PO Box 161 Nauvoo, IL 62354 Egyesült Államok Telefon: +1 866 273-6255 Fax: +1 217 453-9956 e-mail: sales@bsdmall.com WWW:
FreeBSD Mall, Inc. 3623 Sanford Street Concord, CA 94520-1405 Egyesült Államok Telefon: +1 925 240-6652 Fax: +1 925 674-0821 e-mail: info@freebsdmall.com WWW:
Dr. Hinner EDV St. Augustinus-Str. 10 D-81825 München Németország Telefon: (089) 428 419 WWW:
Ikarios 22-24 rue Voltaire 92000 Nanterre Franciaország WWW:
JMC Software Írország Telefon: 353 1 6291282 WWW:
The Linux Emporium Hilliard House, Lester Way Wallingford OX10 9TA Egyesült Királyság Telefon: +44 1491 837010 Fax: +44 1491 837016 WWW:
Linux+ DVD Magazine Lewartowskiego 6 Warsaw 00-190 Lengyelország Telefon: +48 22 860 18 18 e-mail: editors@lpmagazine.org WWW:
Linux System Labs Australia 21 Ray Drive Balwyn North VIC - 3104 Ausztrália Telefon: +61 3 9857 5918 Fax: +61 3 9857 8974 WWW:
LinuxCenter.Ru Galernaya utca, 55 Szentpétervár 190000 Oroszország Telefon: +7-812-3125208 e-mail: info@linuxcenter.ru WWW:
Terjesztõk Ha viszonteladók vagyunk és szeretnénk CD-s &os; termékeket forgalmazni, akkor az alábbi terjesztõk valamelyikével vegyük fel a kapcsolatot:
Cylogistics 809B Cuesta Dr., #2149 Mountain View, CA 94040 Egyesült Államok Telefon: +1 650 694-4949 Fax: +1 650 694-4953 e-mail: sales@cylogistics.com WWW:
Ingram Micro 1600 E. St. Andrew Place Santa Ana, CA 92705-4926 Egyesült Államok Telefon: 1 (800) 456-8000 WWW:
Kudzu, LLC 7375 Washington Ave. S. Edina, MN 55439 Egyesült Államok Telefon: +1 952 947-0822 Fax: +1 952 947-0876 e-mail: sales@kudzuenterprises.com
LinuxCenter.Ru Galernaya utca, 55 Szentpétervár 190000 Oroszország Telefon: +7-812-3125208 e-mail: info@linuxcenter.ru WWW:
Navarre Corp 7400 49th Ave South New Hope, MN 55428 Egyesült Államok Telefon: +1 763 535-8333 Fax: +1 763 535-0341 WWW:
FTP oldalak A &os; hivatalos forrásai anonim FTP-n keresztül is elérhetõek különféle tükrözésekrõl. Az oldal ugyan jó minõségû kapcsolattal rendelkezik és rengeteg felhasználót is enged egyidejûleg kapcsolódni, azonban valószínûleg jobban járunk, ha egy hozzánk közelebbi tükrözést választunk (különösen abban az esetben, amikor mi magunk is egy tükrözést akarunk készíteni). A &os; tükrözések adatbázisában az itt megtalálhatónál sokkal pontosabb leltárt kaphatunk az elérhetõ tükrözésekrõl, mivel közvetlenül a névfeloldás segítségével állapítja meg a szükséges adatokat és nem egy rögzített listát tárol. Emellett az alábbi tükrözésekrõl a &os; elérhetõ anonim FTP-n keresztül is. Amennyiben az anonim FTP használata mellett döntenénk, igyekezzünk a hozzánk legközelebb levõ szervert használni. Az Elsõdleges tükrözésekként feltüntetett oldalak általában a teljes &os; archívumot tartalmazzák (az összes jelenleg elérhetõ változatot az összes architektúrára), de a környékünkön vagy országunkban elhelyezkedõ tükörszerverekrõl többnyire gyorsabban tudunk majd letölteni. A regionális oldalakon gyakorta csak a népszerûbb architektúrákon futó népszerûbb változatokat találjuk meg, nem a teljes &os; archívumot. Minden szerver elérhetõ anonim FTP-vel, de közülük néhány még további más módszereket is támogat. Az egyes oldalak által ismert konkrét módszereket a nevük után zárójelben közüljük. &chap.mirrors.ftp.inc; Anonim CVS <anchor id="anoncvs-intro">Bevezetés CVS anonim Az anonim CVS (vagy más néven anoncvs) a &os;-hez mellékelt CVS-es segédprogramok által nyújtott olyan lehetõség, amivel távoli CVS repositorykkal tudunk szinkronizálni. Több más dolog mellett lehetõvé teszi a &os; felhasználói számára, hogy kiemelt jogosultságok nélkül képesek legyenek olvasással kapcsolatos CVS mûveleteket végrehajtani a &os; Projekt hivatalos anoncvs szerverein. A használatához egyszerûen csak a kiválasztott anoncvs szervert kell beállítani a CVSROOT környezeti változó értékének, ahol aztán a cvs login parancsnak a szerver által ismert anoncvs jelszót kell megadni. Ezután a &man.cvs.1; paranccsal a többi CVS szerverhez hasonlóan lehetõségünk nyílik hozzáférni. A cvs login parancs a bejelentkezésekhez szükséges jelszavakat a HOME könyvtárunkban levõ .cvspass állományban tárolja. Ha ez az állomány nem létezik, akkor a cvs login elsõ használatakor hibát kapunk. Ilyenkor csak hozzunk létre egy üres .cvspass állományt, majd próbálkozzunk újra. Habár azt mondhatnánk, hogy a CVSup és az anoncvs lényegében egyazon feladatot oldják meg, mind a két esetben léteznek olyan kompromisszumok, amelyek befolyásolhatják a felhasználó választását a két szinkronizációs módszer között. Dióhéjban ezt úgy tudnánk összefoglalni, hogy a CVSup a hálózati erõforrásokat hatékonyabban kihasználja és kettejük közül ez a fejlettebb, azonban ennek meg kell fizetnünk az árát. A CVSup használatához elõször ugyanis telepítenünk kell és be kell állítanunk egy speciális klienst, illetve az adatokat a CVSup által gyûjteményeknek (collection) nevezett, viszonylag nagy méretû egyeségekben érhetjük el. Ezzel szemben az anoncvs használata során a megfelelõ CVS modul nevének felhasználásával tetszõlegesen megvizsgálhatunk önálló állományokat vagy akár programokat (mint az ls vagy a grep). Természetesen az anoncvs segítségével csupán az olvasást igénylõ CVS mûveleteket végezhetjük el, ezért ha a &os; Projekt keretein belül fejleszteni is szeretnénk, akkor inkább érdemes a CVSup alkalmazást választani. <anchor id="anoncvs-usage">Az anonim CVS használata A &man.cvs.1; parancsot nagyon könnyû beállítani az anonim CVS repositoryk használatához, hiszen mindössze annyit kell tennünk, hogy a CVSROOT környezeti változó értékének megadjuk a &os; Projekt valamelyik anoncvs szerverét. Ezen sorok írásának pillanatában a következõ szerverek érhetõek el: - - Ausztria: - :pserver:anoncvs@anoncvs.at.FreeBSD.org:/home/ncvs (a - cvs login használatával - tetszõleges jelszó megadható) - Franciaország: :pserver:anoncvs@anoncvs.fr.FreeBSD.org:/home/ncvs (pserver (a jelszó anoncvs), ssh (nincs jelszó)) - - Németország: - :pserver:anoncvs@anoncvs.de.FreeBSD.org:/home/ncvs (rsh, - pserver, ssh, ssh/2022) - Japán: :pserver:anoncvs@anoncvs.jp.FreeBSD.org:/home/ncvs (a cvs login használatánál a jelszó anoncvs.) Tajvan: :pserver:anoncvs@anoncvs.tw.FreeBSD.org:/home/ncvs (pserver (a cvs login használatával tetszõleges jelszó megadható), ssh (nincs jelszó)) SSH2 HostKey: 1024 e8:3b:29:7b:ca:9f:ac:e9:45:cb:c8:17:ae:9b:eb:55 /etc/ssh/ssh_host_dsa_key.pub Egyesült Államok: freebsdanoncvs@anoncvs.FreeBSD.org:/home/ncvs (csak ssh — nincs jelszó) SSH HostKey: 1024 a1:e7:46:de:fb:56:ef:05:bc:73:aa:91:09:da:f7:f4 root@sanmateo.ecn.purdue.edu SSH2 HostKey: 1024 52:02:38:1a:2f:a8:71:d3:f5:83:93:8d:aa:00:6f:65 ssh_host_dsa_key.pub Egyesült Államok: anoncvs@anoncvs1.FreeBSD.org:/home/ncvs (csak ssh2 — nincs jelszó) SSH2 HostKey: 2048 53:1f:15:a3:72:5c:43:f6:44:0e:6a:e9:bb:f8:01:62 /etc/ssh/ssh_host_dsa_key.pub Mivel a CVS használatával kikérhetjük (check out) tulajdonképpen a &os; forrásainak akármelyik eddigi (vagy majd ezután keletkezõ) változatát, érdemes megismerkednünk a &man.cvs.1; által alkalmazott revízió (revision) (az opcióval állítható) fogalmával és a &os; Projekt repositoryjain belül engedélyezett értékeivel. Címkéket (tag) két esetben használhatunk: a revíziók és az ágak esetén. A revíziós címkék mindig egy adott revízióra hivatkoznak, ami állandóan ugyanazt jelenti. Ezzel szemben az ágak címkéi a fejlesztés adott irányú menetének az adott pillanatban legfrissebb revízióját hivatkozzák. Mivel az ágak címkéi nem egy adott revízióra vonatkoznak, ezért elmondhatjuk róluk, hogy naponta változik a jelentésük. Az tartalmazza a felhasználók számára fontos revíziós címkéket. Ezek azonban nem igazak a Portgyûjteményre, mivel a Portgyûjteménynek nincs egyszerre több fejlesztési iránya. Egy ág címkéjének megadásával általában az adott irányhoz tartozó állományok legfrissebb változatát kapjuk meg. Ha viszont az állományok egy korábbi változatára lenne szükségünk, akkor a opció megadásával meg tudjuk adni annak idõpontját. Errõl részletesebben a &man.cvs.1; man oldalán olvashatunk. Példák Habár a továbbhaladáshoz mindenképpen javasoljuk a &man.cvs.1; man oldalának részletes áttanulmányozását, mutatunk néhány gyors példát az anonim CVS használatának tömör illusztrálására: Valami (az &man.ls.1;) kikérése a -CURRENT ágból &prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.tw.FreeBSD.org:/home/ncvs &prompt.user; cvs login Jelszóként ezután bármit megadhatunk. &prompt.user; cvs co ls Az <filename>src/</filename> fa kikérése SSH-n keresztül &prompt.user; cvs -d freebsdanoncvs@anoncvs.FreeBSD.org:/home/ncvs co src The authenticity of host 'anoncvs.freebsd.org (128.46.156.46)' can't be established. DSA key fingerprint is 52:02:38:1a:2f:a8:71:d3:f5:83:93:8d:aa:00:6f:65. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'anoncvs.freebsd.org' (DSA) to the list of known hosts. Az &man.ls.1; 6-STABLE ágban szereplõ változatának kikérése &prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.tw.FreeBSD.org:/home/ncvs &prompt.user; cvs login Amikor kéri, jelszóként bármit megadhatunk. &prompt.user; cvs co -rRELENG_6 ls Az &man.ls.1; változásainak (Unified Diff formátumú) listázása &prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.tw.FreeBSD.org:/home/ncvs &prompt.user; cvs login Itt jelszóként bármit megadhatunk. &prompt.user; cvs rdiff -u -rRELENG_5_3_0_RELEASE -rRELENG_5_4_0_RELEASE ls A használható modulok nevének kiderítése &prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.tw.FreeBSD.org:/home/ncvs &prompt.user; cvs login Ezután jelszóként bármit megadhatunk. &prompt.user; cvs co modules &prompt.user; more modules/modules Egyéb helyek A következõ helyeken találhatunk még hasznos információkat a CVS használatáról: A CVS bemutatása (írta: Cal Poly). A CVS honlapja, a CVS fejlesztésével és alkalmazásával foglalkozó közösség oldala. A CVSweb a &os; Projekt által használt CVS rendszerének webes felülete. A CTM használata CTM A CTM használatáva a távoli könyvtárakat tudunk egy központi változattal szinkronban tartani. Eredetileg a &os; forrásaihoz fejlesztették ki, de idõvel mások más célokra is alkalmasnak találhatják majd. Az eltérések (delták) feldolgozásával kapcsolatban kevéske dokumentáció áll rendelkezésre, ezért a &a.ctm-users.name; levelezési listát érdemes felkeresni, ha többet szeretnénk megtudni a CTM egyéb célú alkalmazásairól. Miért használnánk a <application>CTM</application>-et? A CTM segítségével a &os; forrásainak helyi másolatát hozhatjuk létre. A források több különbözõ kivitelben is hozzáférhetõek. A CTM minden esetben képes eleget tenni az igényeinknek, akár az egész CVS fát, akár annak egy részét kívánjuk csak figyelemmel követni. Ha netalán &os; fejlesztõk lennénk, és híján vagyunk vagy éppen gyenge TCP/IP kapcsolattal rendelkezünk, esetleg egyszerûen csak automatikusan értesülni szeretnénk a változásokról, a CTM-et nekünk találták ki. A leggyorsabban fejlõdõ ágakból is naponta legfeljebb három deltát fogunk kapni, azonban érdemes megfontolni a változások automatikus elküldését levélben. A szükséges frissítések méretét mindig igyekszünk minimalizálni. Ez egyébként általában alig 5 KB, de néha (tízbõl egyszer) elõfordul, hogy 10 és 50 KB között van, és idõnként 100 KB vagy afeletti mennyiségû frissítés is érkezhet. Amikor a fejlesztõk által használt forrásokat töltjük le, magunknak kell gondoskodnunk a menet közben felmerülõ különbözõ problémák megoldásáról. Ez kiváltképp igaz abban az esetben, amikor az aktuális, vagy hivatalos nevén CURRENT ágat követjük. Mielõtt azonban egy ilyenbe belevágnánk, érdemes fellapozni a &os; legfrissebb változatának használatáról szóló fejezetet. Mire van szükségünk a <application>CTM</application> használatához? A mûködéshez két komponens szükségeltetik: a CTM kliensprogramja és hozzá a kezdeti delták (amivel majd letöltjük a CURRENT forrásait). A CTM program már a 2.0 kiadástól kezdve a &os; része, és a források között a /usr/src/usr.sbin/ctm könyvtárban találjuk meg (amennyiben felraktuk). A CTM mûködéséhez kellõ deltákat két módon, FTP-n vagy e-mailen keresztül szerezhetjük be. Ha el tudunk érni interneten levõ FTP oldalakat, akkor az alábbi FTP helyeken találunk a CTM-hez használható adatokat: valamint lásd a tükrözéseket. FTP-n keresztül lépjünk be a könyvtárba, töltsük le a README nevû állományt és kövessük a benne szereplõ utasításokat. Ha viszont e-mailen keresztül akarjuk megszerezni a deltákat: Iratkozzunk fel a CTM terjesztési listáinak egyikére. A &a.ctm-cvs-cur.name; lista az egész CVS-fát, míg a &a.ctm-src-cur.name; a fõ fejlesztési ágat teszi elérhetõvé. A &a.ctm-src-4.name; a 4.X kiadásaihoz ágakat tartalmazza, és így tovább. (Ha nem tudjuk, hogyan kell feliratkozni egy levelezési listára, akkor kattintsunk a lista nevére vagy kövessük a &a.mailman.lists.link; linket, majd kattintsunk arra a listára, ahova fel akarunk iratkozni. Ezen az oldalon az összes, a feliratkozáshoz nélkülözhetetlen információnak szerepelnie kell.) Miután elkezdenek megérkezni a CTM-frissítéseket tartalmazó levelek, a tartalmukat a ctm_rmail programmal tudjuk kicsomagolni és felhasználni. Az /etc/aliases állományba akár közvetlenül is beírhatjuk a ctm_rmail programot, és ezzel a önállósítani tudjuk a levélben érkezõ frissítések feldolgozását. A ctm_rmail man oldalán olvashatjuk ennek részleteit. Nem számít, milyen módon jutunk hozzá a CTM által használt deltákhoz, minden esetben fel kell iratkoznunk a &a.ctm-announce.name; levelezési listára. Az elkövetkezendõkben ez lesz az egyetlen hely, ahová a CTM rendszer mûködtetésével kapcsolatos bejelentések beküldésre kerülnek. A feliratkozáshoz kattinsunk a fenti lista nevére és kövessük a mellette szereplõ utasításokat. A <application>CTM</application> elsõ használata Mielõtt nekilátnánk a CTM-hez tartozó delták használatának, elõször el kell jutnunk egy kiindulási ponthoz, ahonnan majd létre tudjuk hozni a rákövetkezõ deltákat. Ehhez elsõként vegyük számba, pontosan mink is van. Általában mindenki egy üres könyvtárral kezd. Ilyenkor egy kezdeti Empty (mint üres) elnevezésû deltával tudjuk megkezdeni az CTM által ismert fa szinkronizálását. Erre a célra lesznek majd szintén alkalmasak a megkezdett delták is, amelyek valamikor a CD-re fognak felkerülni. Mivel a fák maguk több tíz megabyte-nyi méretûek, ezért érdemes inkább valami kéznél levõ eszközzel megkezdeni a folyamatot. Ha van -RELEASE verziójú CD-nk, akkor másoljuk le róla és bontsuk ki a kiindulásként használt forrásokat. Ezzel jelentõs mennyiségû adat átvitelét takaríthatjuk meg. A kezdõ deltákat könnyen megismerjük a szám után X karakterrel leválasztott nevükrõl (például src-cur.3210XEmpty.gz). Az X után szereplõ megnevezés a kezdeti kiindulás (seed) fokának felel meg. Az Empty egy üres könyvtárra utal. A szabályok szerint az Empty állapotból 100 deltánként jön létre újabb (kiindulásra alkalmas) alapváltozat. Ezek azonban nagyon nagyok is lehetnek. A 70 vagy 80 megabyte-os gzippel csomagolt adatok gyakoriak az XEmpty delták esetén. Miután kiválasztottuk a számunkra megfelelõ alapváltozatot, szükségünk lesz a tõle nagyobb sorszámú összes deltára is. A <application>CTM</application> használata a hétköznapokban A delták felhasználásához egyszerûen csak ennyit kell tennünk: &prompt.root; cd /ahol/tárolni/akarjuk/az/adatokat &prompt.root; ctm -v -v /ahol/tároljuk/a/deltákat/src-xxx.* A CTM képes értelmezni a gzip által csomagolt adatokat, ezért nincs szükség a delták elõzetes kitömörítésére, amivel tárhelyet tudunk spórolni. Hacsak nem tekinti tökéletesen biztonságosnak az egész folyamatot, akkor a CTM nem fog módosítani a fán. A deltákat a CTM kapcsolójával is ellenõrizhetjük, aminek során egyáltalán nem fog módosulni a forrásfa. Ekkor egyszerûen csak ellenõrzi a delták sértetlenségét és megnézi, hogy minden rendben zajlana-e az alkalmazásuk során. A CTM-nek vannak még további kapcsolói is, melyekrõl bõvebben a man oldalakból és a forráskódokból tájékozódhatunk. Most már minden megvan, ami kellhet. Amikor kapunk egy újabb deltát, a forrásaink frissítéséhez csak futtassuk át a CTM-en. Ne töröljük le azokat a deltákat, melyeket nehezen tudtunk letölteni. Helyette érdemes inkább megtartani ezeket arra az esetre, ha valami rossz történne. Még ha csak floppylemezek is állnak rendelkezésünkre, mindenképpen másoljuk le ezeket az fdwrite paranccsal. A saját változtatásaink megtartása Fejlesztõként biztosan szeretnénk kísérletezni és állományokat megváltoztatni a forrásfában. A CTM a helyben elkövetett változtatásokat csak korlátozottan támogatja: az ize nevû állomány meglétének vizsgálata elõtt az ize.ctm állományt fogja keresni. Ha létezik, akkor a CTM az ize helyett ezen fog dolgozni. Ezzel a viselkedéssel nyerjük a saját változtatásaink megtartásának egyszerû módját: csak másoljuk le .ctm kiterjesztéssel a módosítani tervezett állományokat. Ezután már szabadon módosíthatjuk a forrásokat, miközben a CTM a .ctm kiterjesztésû állományokat folyamatosan szinkronban tartja. A <application>CTM</application> egyéb érdekes beállításai Derítsük ki pontosan miket is fog érinteni a frissítés A CTM által a forrásokon elvégzendõ változtatások listáját az kapcsolóval kérdezhetjük le. Ez akkor esik kézre, ha szeretnénk feljegyezni a bekövetkezõ változásokat, vagy bármilyen módon elõ- vagy utófeldolgozni a módosított állományokat, esetleg szimplán elõvigyázatosak akarunk lenni. Biztonsági másolat készítése a frissítés elõtt Néha egyszerûen csak szeretnénk az összes érintett állományról biztonsági másolatot készíteni a CTM által elvégzett frissítés elõtt. A beállítás megadásával az adott CTM delta által módosítandó összes állomány tárolásra kerül a mentés-állomány nevû állományba. A frissíthetõ állományok korlátozása Egyes esetekben érdekünkben állhat leszûkíteni a CTM által eszközölt frissítések hatáskörét, vagy egyszerûen csak néhány állomány szinkronizálására van szükségünk. A CTM számára feldolgozható állományok listáját reguláris kifejezés formájában az és opciók mentén határozhatjuk meg. Például ha a lib/libc/Makefile állomány az összegyûjtött CTM delták szerinti legfrissebb verziójához kívánunk hozzájutni, akkor futtassuk az alábbi parancsot: &prompt.root; cd /akarhova/ahova/ki/akarjuk/bontani/ &prompt.root; ctm -e '^lib/libc/Makefile' ~ctm/src-xxx.* A CTM deltákban megadott minden egyes állomány esetén az az opciók a parancssorban történt megadásuk sorrendjében kerülnek feldolgozásra. Egy állományt kizárólag csak akkor dolgoz fel a CTM, ha az az és opciók kiértékelése után is indokolt. További tervek a <application>CTM</application>-mel kapcsolatban Rengeteg van: Valamiféle hitelesítés bevezetése a CTM rendszerbe, amivel észlelhetõek a meghamisított CTM-frissítések. A CTM beállításainak letisztázása, mivel eléggé megtévesztõek és nehézkesen használhatóak. Egyebek Léteznek delták a portok gyûjteményéhez is, azonban még nem mutatkozott túlzottan nagy érdeklõdés irántuk. CTM tükrözések A CTM/FreeBSD anonim FTP-n keresztül elérhetõ az alábbi tüköroldalak valamelyikérõl. Amennyiben ezen a módon kívánjuk letölteni a CTM rendszerhez tartozó állományokat, elõször próbálkozzunk a hozzánk legközelebb levõ szerverrel. Ha bármilyen gond merülne fel, értesítsük a &a.ctm-users.name; levelezési listát. Kalifornia, Bay Area (hivatalos forrás) Dél-Afrika (a korábbi delták biztonsági másolatai) Tajvan/R.O.C. Ha nem találtunk volna hozzánk közel esõ tükrözést, vagy ha talált tükör nem elég friss, akkor próbálkozzunk egy olyan keresõmotor használatával, mint például az alltheweb. A CVSup használata Bevezetés A CVSup távoli szervereken található központi repositorykban levõ forrásfák terjesztésére és a rajtuk keresztüli frissítésre alkalmas programcsomag. A &os; forrásait egy CVS repositoryban tartják karban Kaliforniában egy fejlesztéseket tároló központi számítógépen. A CVSup segítségével a &os; felhasználói könnyen szinkronban tudják vele tartani a saját forrásaikat. A CVSup az ún. lehúzással frissít. Ilyenkor a kliensek csak akkor kérnek a szervertõl frissítéseket, amikor szükségük van rá, miközben a szerver passzívan várja a frissítési kérelmeket. Ennek megfelelõen tehát minden esetben a kliens kezdeményezi a frissítést, a szerver pedig önmagától sosem küld ilyeneket kéretlenül. A felhasználóknak így vagy maguknak kell meghívniuk a CVSup kliensét, vagy a frissítések rendszeres automatikus letöltéséhez be kell állítaniuk a cron rendszerprogramot. A CVSup kifejezés ebben az írásmódban az egész programcsomagra utal. Fõ alkotórészei a a felhasználó gépén futó cvsup nevû kliens, és a &os; tüköroldalain futó cvsupd nevû szerver. A &os; dokumentációjának és levelezési listáinak fürkészése során rengeteg hivatkozást találhatunk egy sup nevû alkalmazásra. A sup a CVSup elõdje volt, és hasonló célokat szolgált. A CVSup használat tekintetében nagyon hasonlít a sup-hoz, és ami azt illeti, a a sup konfigurációs állományaival visszafele kompatibilis formátumot használ. Mivel a CVSup sokkal gyorsabb és rugalmasabb, a supot már nem használja a &os; Projekt. A csup a CVSup C nyelven újraírt változata. Legnagyobb elõnye, hogy gyorsabb és nincs szüksége a Modula-3 nyelv futtató környezetére, ezért azt nem kell a használatához telepíteni. Ráadásul, ha a &os; 6.2 vagy annál késõbbi változatát használjuk, akkor minden további nélkül a rendelkezésünkre áll, hiszen az alaprendszer része. A &os; korábbi verzióinak alaprendszerei ugyan nem tartalmazzák a &man.csup.1; parancsot, viszont a net/csup port vagy csomag segítségével pillanatok alatt telepíteni tudjuk. Emellett a csup segédprogram nem támogatja a CVS módot sem. Teljes repositoryk tükrözéséhez ezért továbbra is a CVSup kell használnunk. Amennyiben a csup mellett tennénk le a voksunkat, a szakasz fennmaradó részében egyszerûen hagyjuk ki a CVSup telepítésérõl szóló lépéseket és a CVSup hivatkozásait helyettesítsük a csup programmal. Telepítés A CVSup telepítésének legegyszerûbb módja a &os; csomaggyûjteményében található elõrefordított net/cvsup csomag használata. Ha viszont inkább forrásból akarjuk telepíteni a CVSupot, akkor helyette használjuk a net/cvsup portot. De legyünk elõvigyázatosak: a net/cvsup portnak szüksége van a Modula-3 rendszerre, aminek letöltése és lefordítása pedig meglehetõsen sok idõt és tárhelyet igényel. Ha olyan gépen akarjuk használni a CVSupot, ahol nincs &xfree86;, &xorg; vagy bármilyen más ilyen szerver, akkor használjuk a net/cvsup-without-gui portot, ami nem tartalmazza a hozzátartozó grafikus felületet. Ha a &os; 6.1 vagy korábbi változatain szeretnénk telepíteni a csupot, használjuk a &os; csomaggyûjteményében megtalálható net/csup csomagot. Ha viszont forrásból kívánjuk telepíteni a csup programot, akkor helyette használjuk a net/csup portot. A CVSup beállítása A CVSup mûködését a supfile elnevezésû állomány vezérli. A /usr/share/examples/cvsup/ könyvárban találhatunk néhány példát a supfile állományokra. A supfile állományban szereplõ információk a CVSup használatával kapcsolatban a következõ kérdéseket válaszolják meg: Milyen állományokat akarunk letölteni? Milyen verzióikra van szükségünk? Honnan akarjuk ezeket beszerezni? Hova akarjuk rakni a számítógépünkön? Hova akarjuk rakni az állapotot tároló állományokat? Az imént feltett kérdésekre a következõ szakaszokban összeállítandó supfile segítségével fogunk válaszolni. Ehhez elõször bemutatjuk a supfile formátumú állományok általános szerkezetét. A supfile állományok szöveget tartalmaznak. A megjegyzések # karakterrel kezdõdnek és a sor végéig tartanak. A kizárólag csak megjegyzéseket tartalmazó vagy üres sorok nem kerülnek feldolgozásra. Az összes többi fennmaradó sorban pedig azokat az állományokat írjuk le, amelyeket a felhasználó le akar tölteni. Az ilyen fajtájú sorok egy gyûjtemény (collection) nevével kezdõdnek, ami állományok egy szerver által meghatározott logikai csoportjára utal. A gyûjtemény neve ennek megfelelõen elárulja a szervernek, hogy pontosan milyen állományokra van szükségünk. Ezután következik whitespace-szel elválasztva nulla vagy több mezõ, amelyek a korábban feltett kérdéseinket válaszolják meg rendre. Ezeknek a mezõknek két típusa létezik: a beállításokat és a konkrét értéket tároló mezõk. A beállításokat tároló mezõk különbözõ kulcsszavakat tartalmaznak, például a delete (törlés) vagy compress (tömörítés). Az értéket tároló mezõk is egy kulcsszóval kezdõdnek, azonban utána közvetlenül egy = (egyenlõségjel) jön, amelyet egy második szó követ szorosan. Így például a release=cvs pontosan egy ilyen értékmezõ lesz. Egy supfile általában egynél több gyûjtemény letöltését írja le. Ezért az ilyen állományok felépítésének egyik módja, ha az egyes gyûjteményhez explicite megadjuk a hozzátartozó mezõket. Azonban így a supfile állományok gyorsan megnövekednek és kényelmetlenné válnak, mivel a legtöbb gyûjtemény esetén szinte ugyanazokat a mezõket kellene megadnunk. A CVSup az ilyen típusú bonyodalmak elkerülésére egy alapértelmezési megoldást javasol. A *default nevû álgyûjteménnyel kezdõdõ sorok segítségével meg tudunk adni olyan beállításokat és értékeket, amelyek az utána következõ gyûjtemények számára alapértelmezésnek fognak számítani a supfile állományban. Az itt megadott alapértelmezések természetesen az egyes gyûjteményekben tetszõleges módon felülbírálhatóak, a mezõk magán a gyûjteményen belüli megadásával. Az állományban az alapértelmezések is megváltoztathatóak vagy bõvíthetõek további *default sorok hozzáadásával. Mindezek tudatában most már megkezdhetjük a FreeBSD-CURRENT ág tartalmának letöltésére és frissen tartására alkalmas supfile állomány összeállítását. Milyen állományokat akarunk letölteni? A CVSupon keresztül elérhetõ állományok gyûjteményeknek hívott nevesített csoportokra bontva érhetõek el. A hivatkozható gyûjtemények leírását a következõ szakaszban találjuk. Ebben a példában most szeretnénk letölteni az egész &os; rendszer forrását. Ezt a src-all nevû gyûjteményre hivatkozva érhetjük el. A supfile állományunk létrehozásának elsõ lépéseként soronként egyet megadva felsoroljuk a letölteni kívánt gyûjteményeket (jelen esetünkben csak egyetlen egyet): src-all Milyen verzióikra van szükségünk? A CVSup használatával tulajdonképpen a források összes valaha létezett verziójához hozzá tudunk férni. Ez annak köszönhetõ, hogy a cvsupd szerver közvetlenül a CVS repositoryból dolgozik, ami pedig az összes verziót tartalmazza. A tag= és date= értékmezõk segítségével adhatjuk meg az igényelt verziókat. Legyünk óvatosak azonban a tag= mezõk helyes megadásával. Egyes címkék ugyanis csak bizonyos állománygyûjtemények esetén élnek. Ha hibás vagy elírt címkét adunk meg, akkor a CVSup törölni fog olyan állományokat, amelyeket valószínûleg nem kellene. A ports-* gyûjtemények esetében pedig kifejezetten csak a tag=. mezõk használhatóak! A tag= mezõk a tárházban található szimbolikus címkéket nevezik meg. A címkéknek két típusa van: a revíziókhoz és az ágakhoz tartozó címkék. A revíziós címkék mindig egy adott revíziót hivatkoznak, jelentésük állandó. Ezzel szemben az ágak címkéi egy adott fejlesztési ág adott idõpontjában elérhetõ revíziót címkézi. Mivel az ágak címkéi nem egy konkrét revízióra vonatkoznak, ezért akár olyanra is utalhatnak, ami pillanatnyilag még nem is létezik. Az ban megtalálhatjuk a fontosabb ágak címkéit. A CVSup konfigurációs állományában a címkéket a tag= elõtaggal kell bevezetni (így tehát a RELENG_4 címke hivatkozása tag=RELENG_4 lesz). Ne felejtsük el, hogy a Portgyûjtemény esetében csak tag=. mezõ megadásának van értelme. Igyekezzünk pontosan lemásolni a címkék neveit, mivel a CVSup nem képes megkülönböztetni az érvényes és az érvénytelen címkéket. Ha véletlen elírjuk a címkét, akkor a CVSup úgy fog viselkedni, mintha olyan érvényes címkére hivatkozhatunk volna, amihez nem tartoznak állományok. Ennek következtében pedig egyszerûen letörli a már meglevõ forrásainkat. Egy ág címkéjének megadása során általában az adott fejlesztési vonal legfrissebb verzióját kapjuk meg. Ha viszont az adott ág valamelyik korábbi változatára lenne szükségünk, akkor a értékmezõ felhasználásával meg tudjuk adni a hozzátartozó dátumot. Ennek mûködésérõl a &man.cvsup.1; man oldala részletesebben értekezik. A példában mi most a &os;-CURRENT verziót akarjuk letölteni. Ezért a következõ sort tesszük a supfile állományunk elejére: *default tag=. Ha nem adunk meg sem tag=, sem pedig date= mezõket, akkor egy fontos eset következik be. Ilyenkor ugyanis egy konkrét verzió helyett közvetlenül a szerver CVS repositoryjából kapjuk meg az állományokat, az összes kiegészítõ információjukkal együtt. A fejlesztõk általában ezt a típusú megoldást kedvelik, mivel így a saját rendszerükön is könnyen karban tudnak tartani egy példányt, amiben tudnak keresni a revíziók között és ki tudják kérni akár az állományok korábbi változatait is. Természetesen ennek függvényében jóval több tárhelyre van szükségük. Honnan akarjuk ezeket beszerezni? A host= mezõ beállításával közöljük a cvsup klienssel, honnan töltse le a frissítéseket. A CVSup tükrözések közül bármelyik megfelel erre a célra, habár leginkább azt érdemes választani, ami a kibertérben a hozzánk legközelebb esik. A példában most egy kitalált &os; terjesztési oldalt választunk, a cvsup99.FreeBSD.org-ot: *default host=cvsup99.FreeBSD.org A CVSup futtatása elõtt tehát ne felejtsük el megváltoztatni ezt a létezõ számítógép hálózati nevére. A cvsup futtatásakor a opció megadásával lehetõségünk ennek felülbírálására. Hova akarjuk rakni a számítógépünkön? A prefix= mezõ adja meg a cvsup számára, hogy hova tegye a kapott állományokat. A példában a forrásokat közvetlenül a forrásokat tároló központi könyvtárba, a /usr/src könyvtárba tettük. Mivel a src könyvtár neve már hallgatólagosan benne foglaltatik a letöltésre kiválasztott gyûjtemény nevében, ezért itt csak ennyit kell megadnunk: *default prefix=/usr Hova akarjuk rakni az állapotot tároló állományokat? A CVSup kliens egy bázisnak (base) nevezett könyvtárban folyamatosan fenntart bizonyos állományokban állapotokat (status file). Ezek a már letöltött állományok nyilvántartásával segítik a CVSup hatékony munkavégzését. Mi most a szabványos bázist, a /var/db könyvtárat fogjuk használni: *default base=/var/db Amennyiben még nem létezne a bázisként használni kívánt könyvtár, ideje létrehoznunk. A cvsup ugyanis egy nem létezõ könyvtár esetén nem lesz hajlandó mûködni. További beállítások a supfile állományban: Általában még egy sor szokott szerepelni a supfile állományokban: *default release=cvs delete use-rel-suffix compress A release=cvs mezõ jelzi, hogy a szervernek a &os; fõ CVS repositoryból kell kikeresnie az információkat. Tulajdonképpen majdnem mindig errõl van szó, és az itt megadható többi lehetõség ismertetése most egyébként is meghaladná a szakasz határait. A delete hatására a CVSup képes lesz állományokat törölni. Mindig érdemes megadnunk, hiszen a CVSup csak így tudja teljes mértékben frissentartani a forrásokat. A CVSup természetesen csak azokat az állományokat igyekszik letörölni, amelyek miatt valóban felelõs. A kóbor állományokat nem fogja bántani. A use-rel-suffix hatása egy igazi... Rejtély. Ha tényleg érdekel minket a mûködése, lapozzuk fel bátran a &man.cvsup.1; man oldalát. Nyugodtan adjuk meg és különösebben ne törõdjünk vele. A compress beállítás segítségével a kommunikációs csatornán vándorló adatokat tudjuk gzip-szerû módon tömöríteni. Ha a hálózati kapcsolatunk sebessége meghaladja a 1,5 Mbitet másodpercenként (T1), akkor ezt már nem érdemes használni, viszont minden más esetben lényeges gyorsulást hozhat. Összegezzük az eddigieket: Íme a példaként összerakott supfile állományunk teljes tartalma: *default tag=. *default host=cvsup99.FreeBSD.org *default prefix=/usr *default base=/var/db *default release=cvs delete use-rel-suffix compress src-all A <filename>refuse</filename> állomány Ahogy arról már korábban szó esett, a CVSup lehúzással frissít. Ez alapvetõen annyit jelent, hogy feltárcsázunk egy CVSup szervert, aki a következõt mondja nekünk: A következõket tudod tõlem letölteni..., amire a kliensünk ezt válaszolja: Rendben, akkor nekem kell ez, ez, ez meg ez. Alapértelmezés szerint a CVSup kliense azokat az állományokat fogja letölteni, amelyeket a konfigurációs állományban szereplõ gyûjtemények és címkék által megneveztünk. Ez azonban nem mindig felel meg az igényeinknek, különösen akkor, amikor a doc, ports vagy www fákat akarjuk letölteni — az emberek többsége ugyanis nem beszél négy vagy öt nyelven, ezért nincs is szükségük a nyelvfüggõ állományok letöltésére. A Portgyûjtemény letöltése során a ports-all helyett egyszerûen egyenként is felsorolhatjuk a számunkra érdekes kategóriákat (például ports-astrology, ports-biology stb). Azonban mivel a doc és a www fákhoz nincsenek nyelvfüggõ gyûjtemények, ezért elõ kell halásznunk a CVSup egyik remek funkcióját, a refuse állományt. A refuse állománnyal lényegében arra utasítjuk a CVSup alkalmazást, hogy a gyûjteményekbõl ne töltse le az összes állományt. Úgy is fogalmazhatnánk, hogy javaslatára a kliens visszautasít (refuse) bizonyos szervertõl érkezõ állományokat. Ezeket a visszautasításokat tároló refuse állományt a bázis/sup/ könyvtárban találhatjuk meg (illetve ha még nincsenek, akkor ide kell rakunk ezeket). Itt a bázis a supfile állományban megadott base= mezõre utal, ami a példánkban a /var/db könyvtár volt. Ennek megfelelõen tehát a refuse állomány a /var/db/sup/refuse lesz. A refuse állomány felépítése igen egyszerû: a letölteni nem kívánt állományok és könyvtárak neveit tartalmazza. Például ha az angolul mellett esetleg még beszélünk egy kevés németet is, de nincs szükségünk az angol dokumentáció német fordítására sem, akkor a következõket írjuk a refuse állományba: doc/bn_* doc/da_* doc/de_* doc/el_* doc/es_* doc/fr_* doc/hu_* doc/it_* doc/ja_* doc/mn_* doc/nl_* doc/no_* doc/pl_* doc/pt_* doc/ru_* doc/sr_* doc/tr_* doc/zh_* és így tovább a többi nyelvre is (melyeket a &os; CVS repository böngészésével deríthetjük ki). Ezzel az alkalmas funkcióval a lassú vagy drága internetes kapcsolattal rendelkezõ felhasználók nagyon jól tudnak gazdálkodni, mivel így nem kell letölteniük az egyáltalán nem használt állományokat. A refuse állományokról és a CVSup más hasonlóan elegáns funkcióiról a saját man oldaláról tudhatunk meg többet. A <application>CVSup</application> futtatása Most már készen állunk egy próba frissítés elvégzésére. A parancssorban nem sok mindent kell beírnunk ehhez: &prompt.root; cvsup supfile ahol a supfile a frissen létrehozott supfile állományunk neve lesz. Feltételezve, hogy a parancsot X11 alatt adtunk ki, az cvsup erre feldob egy grafikus ablakot néhány gombbal. Nyomjuk meg a go feliratú gombot és dõljünk hátra. Mivel a példában a /usr/src könyvtárunk frissítését állítottuk be, az állományok aktualizálásához szükséges jogosultságok biztosításához a cvsup programot root felhasználóként kell elindítanunk. Teljesen érthetõ, ha egy kicsit izgatottak vagyunk ezekben a pillanatokban, hiszen az elõbb hoztunk létre egy általunk eddig ismeretlen programhoz egy konfigurációs állományt. Ezért megemlítenénk, hogy ilyenkor elõször mindig próbáljuk ki a konfigurációkat, mielõtt azok bármilyen módosítást végeznének a fontos állományainkon. Ehhez hozzunk létre valahol egy üres könyvtárat, majd adjuk meg a parancssorban ennek a nevét: &prompt.root; mkdir /var/tmp/proba &prompt.root; cvsup supfile /var/tmp/proba Az így megadott könyvtárba kerülnek a frissítés eredményeképpen keletkezõ állományok. A CVSup elõször megvizsgálja a /usr/src könyvtárban található állományokat, viszont egyiküket sem módosítja vagy törli. A frissítések ehelyett a /var/tmp/proba/usr/src könyvtárba fognak kerülni. A CVSup emellett még a báziskönyvtárában tárolt állapotokat sem fogja megváltoztatni. A módosított állományok új változatai a megadott könyvtárba jönnek létre. Mivel a /usr/src könyvtárt ehhez csak olvasni fogjuk, a próba lefuttatásához még root felhasználónak sem kell lennünk. Ha nem használunk X11-et vagy egyszerûen csak nincs szükségünk a grafikus felületre, a parancssorban pár további opció megadásával így is kiadhatjuk a cvsup parancsot: &prompt.root; cvsup -g -L 2 supfile A hatására a CVSup nem hozza be a grafikus felületét. Ha nem talál X11-et, akkor ez természetesen automatikus, de ellenkezõ esetben ezt is meg kell adnunk. Az megadásával a CVSup az összes elvégzendõ frissítésrõl részletes értesítést ad. A részletességnek három foka van, -tól indulva egészen -ig. Itt az alapértelmezett érték a 0, amivel a hibaüzenetek kivételével egyetlen üzenetet sem kapunk. Rengeteg egyéb beállítás adható még meg, ezeket a cvsup -H kiadásával kérdezhetjük le. A beállítások pontosabb leírását a man oldalon találjuk meg. Miután elégedetten tapasztaltuk, hogy a frissítés remekül mûködik, a &man.cron.8; segítségével próbáljuk meg az egész folyamatot önmûködövé tenni a CVSup szabályos idõközönkénti futtatásával. Ekkor viszont magától értetõdik, hogy a CVSup számára ne engedjük használni a grafikus felületet. A <application>CVSup</application> állománygyûjteményei A CVSup révén elérhetõ állománygyûjtemények egy hierarchikus rendszert alkotnak. Van néhány nagyobb állománygyûjtemény, amelyek kisebb al-állománygyûjteményekre bonthatóak. A nagyobb gyûjtemények letöltése ezért a kisebb algyûjtemények letöltésével egyenlõ. A gyûjtemények közt fennálló hierarchikus rendszer a lentebb szereplõ lista behúzásaiban érhetõ tetten. A leggyakrabban használt gyûjtemények a src-all és a ports-all neveket viselik. A többi gyûjteményt általában csak kevesen és csak speciális célokra használják, ezért egyes tükrözéseken nem feltétlenül találjuk meg mindegyiküket. cvs-all release=cvs A &os; fõ CVS repositoryja, beleértve a titkosításhoz tartozó kódokat is. distrib release=cvs A &os; terjesztéséhez és tükrözéséhez kapcsolódó állományok. doc-all release=cvs A &os; kézikönyvének és a többi dokumentáció forrásai. Nem tartalmazza a &os; honlapjának forrásait. ports-all release=cvs A &os; portgyûjteménye. Ha nem akarjuk a ports-all egészét (vagyis a teljes portfát) frissíteni, csak a lentebb szereplõ egyes algyûjteményeket letölteni, akkor soha ne feledkezzünk meg a ports-base megadásáról! Amikor valami változik a portok mûködésében, akkor a ports-base által képviselt algyûjteményben szereplõ állományokat igen gyorsan elkezdik használni a valódi portok. Ezért ha csak a valódi portokat frissítjük, amelyek viszont igényt tartanak néhány újabb funkcióra is, akkor könnyen fordítási hibára vagy különbözõ rejtélyes hibaüzenetekbe futhatunk. Emiatt legeslegelõször mindig tegyünk róla, hogy a ports-base algyûjteményünk a lehetõ legfrissebb legyen. Ha a ports/INDEX állomány egy saját példányát kívánjuk létrehozni, akkor ahhoz a ports-all gyûjteményt (tehát a teljes portfát) le kell kérnünk. A ports/INDEX állományt a portfa egy része alapján nem készíthetjük el. Errõl bõvebben lásd a GYIK-ot. ports-accessibility release=cvs A fogyatékos felhasználókat segítõ szoftverek. ports-arabic release=cvs Arab nyelvi támogatás. ports-archivers release=cvs Archiváló eszközök. ports-astro release=cvs Csillagászathoz tartozó portok. ports-audio release=cvs Hangtámogatás. ports-base release=cvs A Portgyûjtemény saját infrastruktúrája — az Mk/, Tools/ és /usr/ports különféle alkönyvtáraiban elhelyezkedõ állományok. Ne hagyjuk figyelmen kívül a fenti fontos figyelmeztetést sem: ezt az algyûjteményt mindig a &os; Portgyûjteményével együtt frissítsük! ports-benchmarks release=cvs Teljesítménytesztek. ports-biology release=cvs Biológia. ports-cad release=cvs Számítógépes tervezõeszközök (CAD). ports-chinese release=cvs Kínai nyelvi támogatás. ports-comms release=cvs Kommunikációs szoftverek. ports-converters release=cvs Karakterkódolások közti átalakítók. ports-databases release=cvs Adatbázisok. ports-deskutils release=cvs A számítógép feltalálása elõtt is már létezõ eszközök. ports-devel release=cvs Fejlesztõeszközök. ports-dns release=cvs Névfeloldással kapcsolatos szoftverek. ports-editors release=cvs Szövegszerkesztõk. ports-emulators release=cvs Más operációs rendszerek emulátorai. ports-finance release=cvs Pénzügyi, gazdasági és hasonló alkalmazások. ports-ftp release=cvs FTP kliensek és szerverek. ports-games release=cvs Játékok. ports-german release=cvs Német nyelvi támogatás. ports-graphics release=cvs Grafikus segédeszközök. ports-hebrew release=cvs Héber nyelvi támogatás. ports-hungarian release=cvs Magyar nyelvi támogatás. ports-irc release=cvs IRC-vel kapcsolatos programok. ports-japanese release=cvs Japán nyelvi támogatás. ports-java release=cvs &java; segédeszközök. ports-korean release=cvs Koreai nyelvi támogatás. ports-lang release=cvs Programozási nyelvek. ports-mail release=cvs Levelezõ programok. ports-math release=cvs Numerikus számításokkal foglalkozó programok. ports-mbone release=cvs MBone alkalmazások. ports-misc release=cvs Egyéb segédprogramok. ports-multimedia release=cvs Multimediás szoftverek. ports-net release=cvs Hálózati szoftverek. ports-net-im release=cvs Üzenetküldõ (Instant Messaging, IM) szoftverek. ports-net-mgmt release=cvs Hálózati karbantartó szoftverek. ports-net-p2p release=cvs Egyenrangú (Peer to Peer, P2P) hálózatok. ports-news release=cvs USENET hírszoftverek. ports-palm release=cvs A Palm sorozat szoftveres támogatása. ports-polish release=cvs Lengyel nyelvi támogatás. ports-ports-mgmt release=cvs A portok és csomagok karbantartását végzõ segédeszközök. ports-portuguese release=cvs Portugál nyelvi támogatás. ports-print release=cvs Nyomdai programok. ports-russian release=cvs Orosz nyelvi támogatás. ports-science release=cvs Tudományos programok. ports-security release=cvs Biztonsági segédprogramok. ports-shells release=cvs Parancsértelmezõk. ports-sysutils release=cvs Rendszerprogramok. ports-textproc release=cvs Szövegfeldolgozást segítõ eszközök (kivéve az asztali kiadványszerkesztést). ports-ukrainian release=cvs Ukrán nyelvi támogatás. ports-vietnamese release=cvs Vietnámi nyelvi támogatás. ports-www release=cvs A világhálóhoz tartozó szoftverek. ports-x11 release=cvs Az X Window System mûködését segítõ portok. ports-x11-clocks release=cvs X11 órák. ports-x11-drivers release=cvs X11 meghajtók. ports-x11-fm release=cvs X11 állománykezelõk. ports-x11-fonts release=cvs X11 betûtípusok és a hozzájuk tartozó segédprogramok. ports-x11-toolkits release=cvs X11 eszközrendszerek. ports-x11-servers release=cvs X11 szerverek. ports-x11-themes release=cvs X11 témák. ports-x11-wm release=cvs X11 ablakkezelõk. projects-all release=cvs A &os; projektek forrásainak repositoryja. src-all release=cvs A &os; fontosabb forrásai, a titkosításhoz tartozó kódokkal együtt. src-base release=cvs A /usr/src könyvtárban levõ egyéb állományok. src-bin release=cvs Az egyfelhasználós módban használható segédeszközök (/usr/src/bin). src-cddl release=cvs A CDDL licenc szerint terjesztett segédprogramok és függvénykönyvtárak (/usr/src/cddl). src-contrib release=cvs A &os; Projekten kívül fejlesztett segédprogramok és függvénykönyvtárak, viszonylag kevés módosítással (/usr/src/contrib). src-crypto release=cvs A &os; Projekten kívül fejlesztett, titkosítással kapcsolatos segédprogramok és függvénykönyvtárak, viszonylag kevés módosítással (/usr/src/crypto). src-eBones release=cvs Kerberos és DES (/usr/src/eBones). A &os; jelenlegi változatai nem használják. src-etc release=cvs A rendszer beállításait tartalmazó állományok (/usr/src/etc). src-games release=cvs Játékok (/usr/src/games). src-gnu release=cvs A GPL licenc szerint terjesztett segédprogramok (/usr/src/gnu). src-include release=cvs (C nyelvi) Header állományok (/usr/src/include). src-kerberos5 release=cvs A Kerberos5 biztonsági csomag (/usr/src/kerberos5). src-kerberosIV release=cvs A KerberosIV biztonsági csomag (/usr/src/kerberosIV). src-lib release=cvs Függvénykönyvtárak (/usr/src/lib). src-libexec release=cvs Más programok által futtatott rendszerprogramok (/usr/src/libexec). src-release release=cvs A &os; kiadások elkészítéséhez szükséges állományok (/usr/src/release). src-rescue release=cvs Statikusan linkelt programok vészhelyzet esetére, lásd &man.rescue.8; (/usr/src/rescue). src-sbin release=cvs Egyfelhasználós módban használható rendszereszközök (/usr/src/sbin). src-secure release=cvs Titkosítással foglalkozó függvénykönyvtárak és parancsok (/usr/src/secure). src-share release=cvs Több rendszer között megosztható állományok (/usr/src/share). src-sys release=cvs A rendszermag (/usr/src/sys). src-sys-crypto release=cvs A rendszermagban levõ titkosítással foglalkozó kód (/usr/src/sys/crypto). src-tools release=cvs A &os; karbantartására való különbözõ segédprogramok (/usr/src/tools). src-usrbin release=cvs Felhasználói segédprogramok (/usr/src/usr.bin). src-usrsbin release=cvs Rendszerszintû segédprogramok (/usr/src/usr.sbin). www release=cvs A &os; Projekt honlapjának forráskódja. distrib release=self A CVSup szerver saját konfigurációs állományai. A CVSup tükrözései használják. gnats release=current A GNATS hibanyilvántartó adatbázis. mail-archive release=current A &os; levelezési listáinak archívuma. www release=current A &os; Projekt honlapjának generált állományai (de nem a forrásai). A WWW tükrözések használják. Bõvebb információk A CVSup részletesebb bemutatását és a hozzátartozó GYIK-ot A CVSup honlapján találjuk meg. A CVSup &os;-re vonatkozó tárgyalása a &a.hackers;n történik. Itt és az &a.announce;n jelentik be a szoftver újabb változatait. A CVSup alkalmazással kapcsolatos kérdéseket és hibajelentéseket illetõen a CVSup GYIK-ot érdemes megnéznünk. CVSup oldalak A &os; CVSup szerverei az alábbi oldalakon érhetõek el: &chap.mirrors.cvsup.inc; A <application>Portsnap</application> használata Bevezetés A Portsnap a &os; portfájának biztonságos terjesztésére megalkotott rendszer. Hozzávetõleg óránként egyszer a portfa egy újabb pillanatképe jön létre, amit ezután tömörítenek és digitálisan aláírnak. Az így keletkezõ állományokat végül HTTP-n keresztül terjesztik. A CVSuphoz hasonlóan a Portsnap szintén lehúzással frissít. Ennek folyamán a becsomagolt és aláírt portfák egy webszerveren tároltan várják passzívan a kliensek kéréseit. A felhasználók így vagy a &man.portsnap.8; elindításával azonnal, vagy pedig a &man.cron.8; segítségével rendszeresen automatikusan kérhetnek frissítéseket. Technikai megfontolásokból a Portsnap nem közvetlenül a /usr/ports/ könyvtárban található éles portfát változtatja meg. Helyette alapértelmezés szerint a /var/db/portsnap/ könyvtárba kerülõ tömörített változatával dolgozik. A frissítés befejeztével ezzel a tömörített változattal módosítja az éles portfát. Ha a Portsnapet a &os; Portgyûjteményébõl telepítjük, akkor alapértelmezés szerint a tömörített pillanatképet a /var/db/portsnap/ könyvtár helyett a /usr/local/portsnap/ könyvtárban hozza létre. Telepítés A &os; 6.0 vagy késõbbi változataiban már a Portsnap az alaprendszer része. A &os; korábbi verzióra a ports-mgmt/portsnap porton keresztül telepíthetjük. A <application>Portsnap</application> beállítása A Portsnap mûködését az /etc/portsnap.conf konfigurációs állomány vezérli. A felhasználók többségének a benne helyet kapott alapbeállítások megfelelõek. Aki kíváncsi a részletekre, nézze meg a &man.portsnap.conf.5; man oldalt. Amennyiben a Portsnapet a &os; Portgyûjteményébõl telepítettük, a /etc/portsnap.conf helyett a /usr/local/etc/portsnap.conf konfigurációs állományt fogja használni. Ez az állomány a port telepítésekor ugyan nem jön létre automatikusan, de találhatunk belõle egy mintát, amit a következõ paranccsal tudunk a helyére másolni: &prompt.root; cd /usr/local/etc && cp portsnap.conf.sample portsnap.conf A <application>Portsnap</application> elsõ futtatása A &man.portsnap.8; elsõ futtatásakor le kell töltenünk a /var/db/portsnap/ (vagy /usr/local/portsnap/, ha a Portsnapet a Portgyûjteménybõl telepítettük) könyvtárba az egész portfa tömörített képét. Ez 2006 elejétõl nagyjából 41 MB méretûre dagadt. &prompt.root; portsnap fetch Miután sikerült letöltenünk a tömörített képet, az éles portfa egy példányát tudjuk kibontani a /usr/ports/ könyvtárba. Ez a lépés még abban az esetben is kötelezõ, ha már valamilyen módon feltöltöttük volna ezt a könyvtárat (például a CVSup segítségével), hiszen ekkor hozza létre a portsnap a mûködéséhez szükséges adatokat is, amelyek révén el tudja majd dönteni, hogy a portfa pontosan mely részeit kell frissítenie. &prompt.root; portsnap extract A telepítés során alapból nem jön létre a /usr/ports/ könyvtár. Ha a &os; 6.0-RELEASE kiadását használjuk, akkor a portsnap indítása elõtt ezt a könyvtárat el kell készítenünk. A &os; vagy a Portsnap újabb változataiban a portsnap elsõ használata során ez már azonban önmagától megtörténik. A portfa frissítése Miután letöltöttük a portfa kiinduló pillanatképét és kibontottuk a /usr/ports/ könyvtárba, a frissítése két lépésben végezhetõ el: elõször elkérjük (fetch) a tömörített kép frissítéseit, majd ezután az így nyert módosításokat érvényesítjük az éles portfán (update). Ez a két lépés egyetlen portsnap parancs kiadásával összefoglalható: &prompt.root; portsnap fetch update A portsnap némely régebbi változatai nem támogatják ezt a típusú felírást. Ha tehát nem mûködne az iménti parancs, akkor helyette próbáljuk meg ezt: &prompt.root; portsnap fetch &prompt.root; portsnap update A <application>Portsnap</application> automatikus futtatása A Portsnap szervereken keletkezõ hirtelen tömeg elkerülése érdekében a portsnap fetch nem fog &man.cron.8; feladatként futni. Ehelyett erre létezik egy külön portsnap cron parancs, amivel a frissítések letöltése elõtt véletlenszerûen vár legfeljebb 3600 másodpercet. Emellett a portsnap update parancs futtatását sem javasoljuk cron feladatként, mivel komoly problémákat képes okozni akkor, amikor egy port fordítása vagy telepítése során adjuk ki. Azonban az kapcsoló megadásával a portok INDEX állományát biztonságosan tudjuk frissíteni. (Ebbõl nyilvánvalóan következik, hogy a portsnap -I update lefutása után a portsnap update parancsot is ki kell majd adni az kapcsoló nélkül a fa többi részének frissítéséhez.) Ha felvesszük a következõ sort az /etc/crontab állományba, akkor a portsnap frissíteni fogja a tömörített felvételt és a /usr/ports/ könyvtárban levõ INDEX állományokat, és küld egy levelet az elavult feltelepített portokról: 0 3 * * * root portsnap -I cron update && pkg_version -vIL= Ha a rendszeróra nem helyi idõ szerint jár, akkor a 3 értéket cseréljük ki egy 0 és 23 között tetszõleges számra, így hozzájárulunk a a Portsnap szerverek terhelésének egyenletes elosztásához. A portsnap egyes korábbi változatai nem engednek meg egyszerre több parancsot (mint például a cron update). Ha az iménti felírásban hibát kapunk, akkor próbáljuk meg a portsnap -I cron update parancsot kicserélni a portsnap cron && portsnap -I update parancsra. CVS címkék Meg kell adnunk egy revízió címkéjét, amikor a cvs vagy CVSup használatával letöltjük vagy frissítjük a forrásokat. A revíziós címkék a &os; egyik fejlesztési irányát vagy egy adott idõpontbeli állapotát hivatkozzák. Az elõbbi egy ág címkéje, míg az utóbbi pedig egy kiadás címkéje. Az ágak címkéi A HEAD kivételével (amely mindig egy érvényes címke) az összes címke csak a src/ fára vonatkozik. A ports/, doc/ és www/ fák nem tartalmaznak ágakat. HEAD A fõ fejlesztési ág, avagy a &os;-CURRENT szimbolikus neve. Ha nem adunk meg revíziót, ez lesz az alapértelmezés. A CVSup számára ezt . címke jelzi (itt most nem mondatvégi pontot jelöli, hanem a . karaktert). A CVS számára ez lesz az alapértelmezett érték, ha nem adunk meg konkrét revíziós címkét. Többnyire nem túlzottan jó ötlet egy STABLE változatot használó gépen a CURRENT verziójú források kikérése, kivéve hacsak nem ez a szándékunk. RELENG_7 A FreeBSD-7.X fejlesztési ága, más néven a FreeBSD 7-STABLE RELENG_7_0 A FreeBSD-7.0 kiadás ága, ahová csak a biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_6 A FreeBSD-6.X fejlesztési ága, más néven a FreeBSD 6-STABLE RELENG_6_3 A FreeBSD-6.3 kiadás ága, ahová csak biztonsági frissítések és a ritikus hibajavítások kerülnek. RELENG_6_2 A FreeBSD-6.2 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_6_1 A FreeBSD-6.1 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_6_0 A FreeBSD-6.0 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_5 A FreeBSD-5.X fejlesztési ág, más néven a FreeBSD 5-STABLE. RELENG_5_5 A FreeBSD-5.5 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_5_4 A FreeBSD-5.4 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_5_3 A FreeBSD-5.3 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_5_2 A FreeBSD-5.2 és FreeBSD-5.2.1 kiadások ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_5_1 A FreeBSD-5.1 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_5_0 A FreeBSD-5.0 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_4 A FreeBSD-4.X fejlesztési ága, más néven a FreeBSD 4-STABLE. RELENG_4_11 A FreeBSD-4.11 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_4_10 A FreeBSD-4.10 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_4_9 A FreeBSD-4.9 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_4_8 A FreeBSD-4.8 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_4_7 A FreeBSD-4.7 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_4_6 A FreeBSD-4.6 és FreeBSD-4.6.2 kiadások ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_4_5 A FreeBSD-4.5 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_4_4 A FreeBSD-4.4 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_4_3 A FreeBSD-4.3 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_3 A FreeBSD-3.X fejlesztési ága, más néven a 3.X-STABLE. RELENG_2_2 A FreeBSD-2.2.X fejlesztési ága, más néven a 2.2-STABLE. Ez az ág manapság már elavult. A kiadások címkéi Ezek a címkék a &os; egyes kiadásainak dátumára hivatkoznak. Egy kiadás elõkészítésének és terjesztésének folyamatáról részleteiben a kiadásokat összefoglaló lapról és a kiadások építésérõl szóló cikkbõl tájékozódhatunk. Az src fában RELENG_ kezdetû címkéket találunk. A ports és doc fákban a címkék nevei a RELEASE elõtaggal kezdõdnek. Végezetül a www fában nincsenek kiadásokhoz tartozó címkék. RELENG_7_0_0_RELEASE FreeBSD 7.0 RELENG_6_3_0_RELEASE FreeBSD 6.3 RELENG_6_2_0_RELEASE FreeBSD 6.2 RELENG_6_1_0_RELEASE FreeBSD 6.1 RELENG_6_0_0_RELEASE FreeBSD 6.0 RELENG_5_5_0_RELEASE FreeBSD 5.5 RELENG_5_4_0_RELEASE FreeBSD 5.4 RELENG_4_11_0_RELEASE FreeBSD 4.11 RELENG_5_3_0_RELEASE FreeBSD 5.3 RELENG_4_10_0_RELEASE FreeBSD 4.10 RELENG_5_2_1_RELEASE FreeBSD 5.2.1 RELENG_5_2_0_RELEASE FreeBSD 5.2 RELENG_4_9_0_RELEASE FreeBSD 4.9 RELENG_5_1_0_RELEASE FreeBSD 5.1 RELENG_4_8_0_RELEASE FreeBSD 4.8 RELENG_5_0_0_RELEASE FreeBSD 5.0 RELENG_4_7_0_RELEASE FreeBSD 4.7 RELENG_4_6_2_RELEASE FreeBSD 4.6.2 RELENG_4_6_1_RELEASE FreeBSD 4.6.1 RELENG_4_6_0_RELEASE FreeBSD 4.6 RELENG_4_5_0_RELEASE FreeBSD 4.5 RELENG_4_4_0_RELEASE FreeBSD 4.4 RELENG_4_3_0_RELEASE FreeBSD 4.3 RELENG_4_2_0_RELEASE FreeBSD 4.2 RELENG_4_1_1_RELEASE FreeBSD 4.1.1 RELENG_4_1_0_RELEASE FreeBSD 4.1 RELENG_4_0_0_RELEASE FreeBSD 4.0 RELENG_3_5_0_RELEASE FreeBSD-3.5 RELENG_3_4_0_RELEASE FreeBSD-3.4 RELENG_3_3_0_RELEASE FreeBSD-3.3 RELENG_3_2_0_RELEASE FreeBSD-3.2 RELENG_3_1_0_RELEASE FreeBSD-3.1 RELENG_3_0_0_RELEASE FreeBSD-3.0 RELENG_2_2_8_RELEASE FreeBSD-2.2.8 RELENG_2_2_7_RELEASE FreeBSD-2.2.7 RELENG_2_2_6_RELEASE FreeBSD-2.2.6 RELENG_2_2_5_RELEASE FreeBSD-2.2.5 RELENG_2_2_2_RELEASE FreeBSD-2.2.2 RELENG_2_2_1_RELEASE FreeBSD-2.2.1 RELENG_2_2_0_RELEASE FreeBSD-2.2.0 AFS oldalak A &os; a következõ szerverein érhetõ el AFS: Svédország Az állományok a következõ helyen érhetõek el: /afs/stacken.kth.se/ftp/pub/FreeBSD/ stacken.kth.se # Stacken Computer Club, KTH, Svédország 130.237.234.43 #hot.stacken.kth.se 130.237.237.230 #fishburger.stacken.kth.se 130.237.234.3 #milko.stacken.kth.se Karbantartó: ftp@stacken.kth.se Rsync oldalak A most következõ oldalakon a &os;-t érhetjük el az rsync protokollal. Az rsync segédprogram mûködésében leginkább a &man.rcp.1; parancshoz hasonlít, de sokkal több beállítással rendelkezik, és az rsync távoli frissítéseket kezelõ protokollja segítségével csak az állományok csoportjai között levõ eltéréseket küldi át, amivel a hálózaton keresztüli szinkronizáció rendkívül felgyorsítható. Ez olyankor jelent számunkra a legtöbbet, ha a &os; FTP szerverének vagy CVS repositoryjának egyik tükrözését tartjuk karban. Az rsync több operációs rendszerre is elérhetõ, és &os;-n a net/rsync port vagy csomag tartalmazza. Cseh Köztársaság rsync://ftp.cz.FreeBSD.org/ Elérhetõ gyûjtemények: ftp: a &os; FTP szerverének részleges tükrözése. FreeBSD: a &os; FTP szerverének teljes tükrözése. Németország rsync://grappa.unix-ag.uni-kl.de/ Elérhetõ gyûjtemények: freebsd-cvs: a &os; teljes CVS tárháza. Ez a gép ezen kívül még tükrözi a NetBSD és OpenBSD CVS repositorykat is. Hollandia rsync://ftp.nl.FreeBSD.org/ Elérhetõ gyûjtemények: vol/4/freebsd-core: a &os; FTP szerverének teljes tükrözése. + + Oroszország + + + rsync://cvsup4.ru.FreeBSD.org + + Elérhetõ gyûjtemények: + + + FreeBSD-gnats: A GNATS + hibanyilvántartó + adatbázis. + + + + Tajvan rsync://ftp.tw.FreeBSD.org/ rsync://ftp2.tw.FreeBSD.org/ rsync://ftp6.tw.FreeBSD.org/ Elérhetõ gyûjtemények: FreeBSD: a &os; FTP szerverének teljes tükrözése. Egyesült Királyság rsync://rsync.mirror.ac.uk/ Elérhetõ gyûjtemények: ftp.FreeBSD.org: a &os; FTP szerverének teljes tükrözése. Amerikai Egyesült Államok rsync://ftp-master.FreeBSD.org/ Ezt a szervert csak az elsõdleges &os; tükrözéseknek szabad használniuk. Elérhetõ gyûjtemények: FreeBSD: a &os; FTP szerverének központi archívuma. acl: a &os; központi ACL listája. rsync://ftp13.FreeBSD.org/ Elérhetõ gyûjtemények: FreeBSD: a &os; FTP szerver teljes tükrözése. diff --git a/hu_HU.ISO8859-2/books/handbook/network-servers/chapter.sgml b/hu_HU.ISO8859-2/books/handbook/network-servers/chapter.sgml index 7f4636c0b7..13a60672c8 100644 --- a/hu_HU.ISO8859-2/books/handbook/network-servers/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/network-servers/chapter.sgml @@ -1,6695 +1,6696 @@ Murray Stokely Átdolgozta: Hálózati szerverek Áttekintés Ebben a fejezetben a &unix; típusú rendszerekben leggyakrabban alkalmazott hálózati szolgáltatások közül fogunk néhányat bemutatni. Ennek során megismerjük a hálózati szolgáltatások különbözõ típusainak telepítését, beállítását, tesztelését és karbantartását. A fejezet tartalmát folyamatosan példákkal igyekszünk illusztrálni. A fejezet elolvasása során megismerjük: hogyan dolgozzunk az inetd démonnal; hogyan állítsuk be a hálózati állományrendszereket; hogyan állítsunk be egy hálózati információs szervert a felhasználói hozzáférések megosztására; hogyan állítsuk be automatikusan a hálózati hozzáférésünket a DHCP használatával; hogyan állítsunk be névfeloldó szervereket; hogyan állítsuk be az Apache webszervert; hogyan állítsuk be az állományok átviteléért felelõs (FTP) szervert; a Samba használatával hogyan állítsunk be &windows;-os kliensek számára állomány- és nyomtatószervert; az NTP protokoll segítségével hogyan egyeztessük az idõt és dátumot, hogyan állítsunk be egy idõszervert. A fejezet elolvasásához ajánlott: az /etc/rc szkriptek alapjainak ismerete; az alapvetõ hálózati fogalmak ismerete; a külsõ szoftverek telepítésének ismerete (). Chern Lee Készítette: A &os; 6.1-RELEASE változatához igazította: A &os; Dokumentációs Projekt Az <application>inetd</application> <quote>szuperszerver</quote> Áttekintés Az &man.inetd.8; démont gyakran csak internet szuperszerverként nevezik, mivel a helyi szolgáltatások kapcsolatainak kezeléséért felelõs. Amikor az inetd fogad egy csatlakozási kérelmet, akkor eldönti róla, hogy ez melyik programhoz tartozik és elindít egy példányt belõle, majd átadja neki a socketet (az így meghívott program a szabvány bemenetéhez, kimenetéhez és hibajelzési csatornájához kapja meg a socket leíróit). Az inetd használatával úgy tudjuk csökkenteni a rendszerünk terhelését, hogy a csak alkalmanként meghívott szolgáltatásokat nem futtatjuk teljesen független önálló módban. Az inetd démont elsõsorban más démonok elindítására használjuk, de néhány triviális protokollt közvetlenül is képes kezelni, mint például a chargen, auth és a daytime. Ebben a fejezetben az inetd beállításának alapjait foglaljuk össze mind parancssoros módban, mind pedig az /etc/inetd.conf konfigurációs állományon keresztül. Beállítások Az inetd mûködése az &man.rc.8; rendszeren keresztül inicializálható. Az inetd_enable ugyan alapból a NO értéket veszi fel, vagyis tiltott, de a sysinstall használatával már akár a telepítés során bekapcsolható attól függõen, hogy a felhasználó milyen konfigurációt választott. Ha tehát a: inetd_enable="YES" vagy inetd_enable="NO" sort tesszük az /etc/rc.conf állományba, akkor azzal az inetd démont indíthatjuk el vagy tilthatjuk le a rendszer indítása során. Az &prompt.root; /etc/rc.d/inetd rcvar paranccsal lekérdezhetjük a pillanatnyilag érvényes beállítást. Emellett még az inetd démonnak az inetd_flags változón keresztül különbözõ parancssori paramétereket is át tudunk adni. Parancssori paraméterek Hasonlóan a legtöbb szerverhez, az inetd viselkedését is befolyásolni tudjuk a parancssorban átadható különbözõ paraméterekkel. Ezek teljes listája a következõ: inetd Ezek a paraméterek az /etc/rc.conf állományban az inetd_flags segítségével adhatóak meg az inetd részére. Alapértelmezés szerint az inetd_flags értéke -wW -C 60, ami az inetd által biztosított szolgáltatások TCP protokollon keresztüli wrappelését kapcsolja be, illetve egy IP-címrõl nem engedi a felkínált szolgáltatások elérését percenként hatvannál többször. A kezdõ felhasználók örömmel nyugtázhatják, hogy ezeket az alapbeállításokat nem szükséges módosítaniuk, habár a késõbbiekben majd fény derül arra, hogy a kiszolgálás gyakoriságának szabályozása remek védekezést nyújthat túlzottan nagy mennyiségû kapcsolódási kérelem ellen. A megadható paraméterek teljes listája az &man.inetd.8; man oldalán olvasható. -c maximum Az egyes szolgáltatásokhoz egyszerre felépíthetõ kapcsolatok alapértelmezett maximális számát adja meg. Alapból ezt a démont nem korlátozza. A beállítással ez akár szolgáltatásonként külön is megadható. -C arány Korlátozza, hogy egyetlen IP-címrõl alapból hányszor hívhatóak meg az egyes szolgáltatások egy percen belül. Ez az érték alapból korlátlan. A beállítással ez szolgáltatásonként is definiálható. -R arány Megadja, hogy egy szolgáltatást egy perc alatt mennyiszer lehet meghívni. Ez az érték alapértelmezés szerint 256. A 0 megadásával eltöröljük ezt a típusú korlátozást. -s maximum Annak maximumát adja meg, hogy egyetlen IP-címrõl egyszerre az egyes szolgáltatásokat mennyiszer tudjuk elérni. Alapból ez korlátlan. Szolgáltatásonként ezt a paraméterrel tudjuk felülbírálni. Az <filename>inetd.conf</filename> állomány Az inetd beállítását az /etc/inetd.conf konfigurációs állományon keresztül végezhetjük el. Amikor az /etc/inetd.conf állományban módosítunk valamit, az inetd démont a következõ paranccsal meg kell kérnünk, hogy olvassa újra: Az <application>inetd</application> konfigurációs állományának újraolvasása &prompt.root; /etc/rc.d/inetd reload A konfigurációs állomány minden egyes sora egy-egy démont ír le. A megjegyzéseket egy # jel vezeti be. Az /etc/inetd.conf állomány bejegyzéseinek formátuma az alábbi: szolgáltatás-neve socket-típusa protokoll {wait|nowait}[/max-child[/max-connections-per-ip-per-minute[/max-child-per-ip]]] felhasználó[:csoport][/bejelentkezési-osztály] szerver-program szerver-program-paraméterei Az IPv4 protokollt használó &man.ftpd.8; démon bejegyzése például így néz ki: ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l szolgáltatás-neve Ez az adott démon által képviselt szolgáltatást nevezi meg, amelynek szerepelnie kell az /etc/services állományban. Ez határozza meg, hogy az inetd milyen porton figyelje a beérkezõ kapcsolatokat. Ha egy új szolgáltatást hozunk létre, akkor azt elõször az /etc/services állományba kell felvennünk. csatlakozás-típusa Ennek az értéke stream, dgram, raw, vagy seqpacket lehet. A stream típust használja a legtöbb kapcsolat-orientált TCP démon, miközben a dgram típus az UDP szállítási protokollt alkalmazó démonok esetében használatos. protokoll Valamelyik a következõk közül: Protokoll Magyarázat tcp, tcp4 TCP IPv4 udp, udp4 UDP IPv4 tcp6 TCP IPv6 udp6 UDP IPv6 tcp46 TCP IPv4 és v6 udp46 UDP IPv4 és v6 {wait|nowait}[/max-child[/max-connections-per-ip-per-minute[/max-child-per-ip]]] A beállítás mondja meg, hogy az inetd démonból meghívott démon saját maga képes-e kezelni kapcsolatokat. A típusú kapcsolatok esetében egyértelmûen a beállítást kell használni, miközben a esetén, ahol általában több szálon dolgozunk, a megadása javasolt. A hatására általában egyetlen démonnak adunk át több socketet, míg a minden sockethez egy újabb példányt indít el. Az inetd által indítható példányokat a megadásával korlátozhatjuk. Ha tehát például az adott démon számára legfeljebb példány létrehozását engedélyezzük, akkor a után /10 beállítást kell megadnunk. A /0 használatával korlátlan mennyiségû példányt engedélyezhetünk. A mellett még további két másik beállítás jöhet számításba az egyes démonok által kezelhetõ kapcsolatok maximális számának korlátozásában. A az egyes IP-címekrõl befutó lekezelhetõ kapcsolatok percenkénti számát szabályozza, így például ha itt a tizes értéket adjuk meg, akkor az adott szolgáltatáshoz egy IP-címrõl percenként csak tízszer férhetünk hozzá. A az egyes IP-címekhez egyszerre elindítható példányok számára ír elõ egy korlátot. Ezek a paraméterek segítenek megóvni rendszerünket az erõforrások akaratos vagy akaratlan kimerítésétõl és a DoS (Denial of Service) típusú támadásoktól. Ebben a mezõben a vagy valamelyikét kötelezõ megadni. A , és paraméterek ellenben elhagyhatóak. A típusú több szálon futó démonok a , vagy korlátozása nélkül egyszerûen csak így adhatóak meg: nowait. Ha ugyanezt a démont tíz kapcsolatra lekorlátozzuk, akkor a következõt kell megadnunk: nowait/10. Amikor pedig IP-címenként 20 kapcsolatot engedélyezünk percenként és mindössze 10 példányt, akkor: nowait/10/20. Az iménti beállítások a &man.fingerd.8; démon alapértelmezett paramétereinél is megtalálhatóak: finger stream tcp nowait/3/10 nobody /usr/libexec/fingerd fingerd -s Végezetül engedélyezzük 100 példányt, melyek közül IP-címenként 5 használható: nowait/100/0/5. felhasználó Ezzel azt a felhasználót adjuk meg, akinek a nevében az adott démon futni fog. Az esetek túlnyomó részében a démonokat a root felhasználó futtatja. Láthatjuk azonban, hogy biztonsági okokból bizonyos démonok a daemon vagy a legkevesebb joggal rendelkezõ nobody felhasználóval futnak. szerver-program A kapcsolat felépülésekor az itt teljes elérési úttal megadott démon indul el. Ha ezt a szolgáltatást maga az inetd belsõleg valósítja meg, akkor ebben a mezõben az értéket adjuk meg. szerver-program-paraméterei Ez a beállítással együtt mûködik, és ebben a mezõben a démon meghívásakor alkalmazandó paramétereket tudjuk rögzíteni, amelyet a démon nevével kezdünk. Ha a démont a parancssorból a sajátdémon -d paranccsal hívnánk meg, akkor a sajátdémon -d lesz beállítás helyes értéke is. Természetesen, ha a démon egy belsõleg megvalósított szolgáltatás, akkor ebben a mezõben is az fog megjelenni. Védelem Attól függõen, hogy a telepítés során mit választottunk, az inetd által támogatott szolgáltatások egyes része talán alapból engedélyezett is. Amennyiben egy adott démont konkrétan nem használunk, akkor érdemes megfontolni a letiltását. A kérdéses démon sorába tegyünk egy # jelet az /etc/inetd.conf állományba, majd olvastassuk újra az inetd beállításait. Egyes démonok, mint például az fingerd használata egyáltalán nem ajánlott, mivel a támadók számára hasznos információkat tudnak kiszivárogtatni. Más démonok nem ügyelnek a védelemre, és a kapcsolatokhoz rendelt lejárati idejük túlságosan hosszú vagy éppen nincs is. Ezzel a támadónak lehetõsége van lassú kapcsolatokkal leterhelni az adott démont, ezáltal kimeríteni a rendszer erõforrásait. Ha úgy találjuk, hogy túlságosan sok az ilyen kapcsolat, akkor jó ötletnek bizonyulhat a démonok számára a , vagy korlátozások elrendelése. Alapértelmezés szerint a TCP kapcsolatok wrappelése engedélyezett. A &man.hosts.access.5; man oldalon találhatjuk meg az inetd által meghívható különféle démonok TCP-alapú korlátozásainak lehetõségeit. Egyéb lehetõségek A daytime, time, echo, discard, chargen és auth szolgáltatások feladatainak mindegyikét maga az inetd is képes ellátni. Az auth szolgáltatás a hálózati keresztül azonosítást teszi lehetõvé és bizonyos mértékig beállítható. A többit egyszerûen csak kapcsoljuk ki vagy be. A témában az &man.inetd.8; man oldalán tudunk még jobban elmerülni. Tom Rhodes Átdolgozta és javította: Bill Swingle Írta: A hálózati állományrendszer (NFS) NFS A &os; több állományrendszert ismer, köztük a hálózati állományrendszert (Network File System, NFS) is. Az NFS állományok és könyvtárak megosztását teszi lehetõvé a hálózaton keresztül. Az NFS használatával a felhasználók és a programok képesek majdnem úgy elérni a távoli rendszereken található állományokat, mintha helyben léteznének. Íme az NFS néhány legjelentõsebb elõnye: A helyi munkaállomások kevesebb tárterületet használnak, mivel a közös adatokat csak egyetlen számítógépen tároljuk és megosztjuk mindenki között. A felhasználóknak nem kell a hálózat minden egyes gépén külön felhasználói könyvtárral rendelkezniük. Ezek ugyanis az NFS segítségével akár egy szerveren is beállíthatóak és elérhetõvé tehetõek a hálózaton keresztül. A különbözõ háttértárak, mint például a floppy lemezek, CD-meghajtók és &iomegazip; meghajtók a hálózaton több számítógép között megoszthatóak. Ezzel csökkenteni tudjuk a hálózatunkban szükséges cserélhetõ lemezes eszközök számát. Ahogy az <acronym>NFS</acronym> mûködik Az NFS legalább két fõ részbõl rakható össze: egy szerverbõl és egy vagy több kliensbõl. A kliensek a szerver által megosztott adatokhoz képesek távolról hozzáférni. A megfelelõ mûködéshez mindössze csak néhány programot kell beállítani és futtatni. A szervernek a következõ démonokat kell mûködtetnie: NFS szerver állományszerver UNIX kliensek rpcbind mountd nfsd Démon Leírás nfsd Az NFS démon, amely kiszolgálja az NFS kliensektõl érkezõ kéréseket. mountd Az NFS csatlakoztató démonja, amely végrehajtja az &man.nfsd.8; által átküldött kéréseket. rpcbind Ez a démon lehetõvé teszi az NFS kliensek számára, hogy fel tudják deríteni az NFS szerver által használt portot. A kliensen is futnia kell egy démonnak, amelynek a neve nfsiod. Az nfsiod démon az NFS szerver felõl érkezõ kéréseket szolgálja ki. A használata teljesen opcionális, csupán a teljesítményt hívatott javítani, de a normális és helyes mûködéshez nincs rá szükségünk. Az &man.nfsiod.8; man oldalán errõl többet is megtudhatunk. Az <acronym>NFS</acronym> beállítása NFS beállítás Az NFS beállítása viszonylag egyértelmûen adja magát. A mûködéséhez szükséges programok automatikus elindítása csupán néhány apró módosítást igényel az /etc/rc.conf állományban. Az NFS szerveren gondoskodjunk róla, hogy az alábbi beállítások szerepeljenek az /etc/rc.conf állományban: rpcbind_enable="YES" nfs_server_enable="YES" mountd_flags="-r" A mountd magától el fog indulni, ha az NFS szervert engedélyezzük. A kliensen a következõ beállítást kell felvennünk az /etc/rc.conf állományba: nfs_client_enable="YES" Az /etc/exports állomány adja meg, hogy az NFS milyen állományrendszereket exportáljon (vagy másképpen szólva osszon meg). Az /etc/exports állományban tehát a megosztani kívánt állományrendszereket kell szerepeltetnünk, és azt, hogy melyik számítógépekkel tudjuk ezeket elérni. A gépek megnevezése mellett a hozzáférésre további megszorításokat írhatunk fel. Ezek részletes leírását az &man.exports.5; man oldalon találjuk meg. Lássunk néhány példát az /etc/exports állományban megjelenõ bejegyzésekre: NFS példák exportálásra A most következõ példákban az állományrendszerek exportálásának finomságait igyekszünk érzékeltetni, noha a konkrét beállítások gyakran a rendszerünktõl és a hálózati konfigurációtól függenek. Például, ha a /cdrom könytárat akarjuk három gép számára megosztani, akik a szerverrel megegyezõ tartományban találhatóak (ezért nem is kell megadnunk a tartományt) vagy mert egyszerûen megtalálhatók az /etc/hosts állományunkban. Az beállítás az exportált állományrendszereket írásvédetté teszi. Ezzel a beállítással a távoli rendszerek nem lesznek képesek módosítani az exportált állományrendszer tartalmát. /cdrom -ro gép1 gép2 gép3 A következõ sorban a /home könyvtárat három gép számára osztjuk meg, melyeket IP-címekkel adtunk meg. Ez olyan helyi hálózat esetén hasznos, ahol nem állítottunk be névfeloldást. Esetleg a belsõ hálózati neveket az /etc/hosts állományban is tárolhatjuk. Ezzel utóbbival kapcsolatban a &man.hosts.5; man oldalt érdemes fellapoznunk. Az beállítás lehetõvé teszi, hogy az alkönyvtárak is csatlakozási pontok lehessenek. Más szóval, nem fogja csatlakoztatni az alkönyvtárakat, de megengedi a kliensek számára, hogy csak azokat a könyvtárakat csatlakoztassák, amelyeket kell vagy amelyekre szükségünk van. /home -alldirs 10.0.0.2 10.0.0.3 10.0.0.4 A következõ sorban az /a könyvtárat úgy exportáljuk, hogy az állományrendszerhez két különbözõ tartományból is hozzá lehessen férni. A beállítás hatására a távoli rendszer root felhasználója az exportált állományrendszeren szintén root felhasználóként fogja írni az adatokat. Amennyiben a -maproot=root beállítást nem adjuk meg, akkor a távoli rendszeren hiába root az adott felhasználó, az exportált állományrendszeren nem lesz képes egyetlen állományt sem módosítani. /a -maproot=root gep.minta.com doboz.haz.org A kliensek is csak a megfelelõ engedélyek birtokában képesek elérni a megosztott állományrendszereket. Ezért a klienst ne felejtsük el felvenni a szerver /etc/exports állományába. Az /etc/exports állományban az egyes sorok az egyes állományrendszerekre és az egyes gépekre vonatkoznak. A távoli gépek állományrendszerenként csak egyszer adhatóak meg, és csak egy alapértelmezett bejegyzésük lehet. Például tegyük fel, hogy a /usr egy önálló állományrendszer. Ennek megfelelõen az alábbi bejegyzések az /etc/exports állományban érvénytelenek: # Nem használható, ha a /usr egy állományrendszer: /usr/src kliens /usr/ports kliens Egy állományrendszerhez, vagyis itt a /usr partícióhoz, két export sort is megadtunk ugyanahhoz a kliens nevû géphez. Helyesen így kell megoldani az ilyen helyzeteket: /usr/src /usr/ports kliens Az adott géphez tartozó egy állományrendszerre vonatkozó exportoknak mindig egy sorban kell szerepelniük. A kliens nélkül felírt sorok egyetlen géphez tartozónak fognak számítani. Ezzel az állományrendszerek megosztását tudjuk szabályozni, de legtöbbek számára nem jelent gondot. Most egy érvényes exportlista következik, ahol a /usr és az /exports mind helyi állományrendszerek: # Osszuk meg az src és ports könyvtárakat a kliens01 és kliens02 részére, de csak a # kliens01 férhessen hozzá rendszeradminisztrátori jogokkal: /usr/src /usr/ports -maproot=root kliens01 /usr/src /usr/ports kliens02 # A kliensek az /exports könyvtárban teljes joggal rendelkeznek és azon belül # bármit tudnak csatlakoztatni. Rajtuk kívül mindenki csak írásvédetten képes # elérni az /exports/obj könyvtárat: /exports -alldirs -maproot=root kliens01 kliens02 /exports/obj -ro A mountd démonnal az /etc/exports állományt minden egyes módosítása után újra be kell olvastatni, mivel a változtatásaink csak így fognak érvényesülni. Ezt megcsinálhatjuk úgy is, hogy küldünk egy HUP (hangup, avagy felfüggesztés) jelzést a már futó démonnak: &prompt.root; kill -HUP `cat /var/run/mountd.pid` vagy meghívjuk a mountd &man.rc.8; szkriptet a megfelelõ paraméterrel: &prompt.root; /etc/rc.d/mountd onereload Az ban tudhatunk meg részleteket az rc szkriptek használatáról. Ezek után akár a &os; újraindításával is aktiválhatjuk a megosztásokat, habár ez nem feltétlenül szükséges. Ha root felhasználónként kiadjuk a következõ parancsokat, akkor azzal minden szükséges programot elindítunk. Az NFS szerveren tehát: &prompt.root; rpcbind &prompt.root; nfsd -u -t -n 4 &prompt.root; mountd -r Az NFS kliensen pedig: &prompt.root; nfsiod -n 4 Ezzel most már minden készen áll a távoli állományrendszer csatlakoztatására. A példákban a szerver neve szerver lesz, valamint a kliens neve kliens. Ha csak ideiglenesen akarunk csatlakoztatni egy állományrendszert vagy egyszerûen csak ki akarjuk próbálni a beállításainkat, a kliensen root felhasználóként az alábbi parancsot hajtsuk végre: NFS csatlakoztatás &prompt.root; mount szerver:/home /mnt Ezzel a szerveren található /home könyvtárat fogjuk a kliens /mnt könyvtárába csatlakoztatni. Ha mindent jól beállítottunk, akkor a kliensen most már be tudunk lépni az /mnt könyvtárba és láthatjuk a szerveren található állományokat. Ha a számítógép indításával automatikusan akarunk hálózati állományrendszereket csatlakoztatni, akkor vegyük fel ezeket az /etc/fstab állományba. Erre íme egy példa: szerver:/home /mnt nfs rw 0 0 Az &man.fstab.5; man megtalálhatjuk az összes többi beállítást. Zárolások Bizonyos alkalmazások (például a mutt) csak akkor mûködnek megfelelõen, ha az állományokat a megfelelõ módon zárolják. Az NFS esetében az rpc.lockd használható az ilyen zárolások megvalósítására. Az engedélyezéséhez mind a szerveren és a kliensen vegyük fel a következõ sort az /etc/rc.conf állományba (itt már feltételezzük, hogy az NFS szervert és klienst korábban beállítottuk): rpc_lockd_enable="YES" rpc_statd_enable="YES" A következõ módon indíthatjuk el: - &prompt.root; /etc/rc.d/nfslocking start + &prompt.root; /etc/rc.d/lockd start +&prompt.root; /etc/rc.d/statd start Ha nincs szükségünk valódi zárolásra az NFS kliensek és az NFS szerver között, akkor megcsinálhatjuk azt is, hogy az NFS kliensen a &man.mount.nfs.8; programnak az paraméter átadásával csak helyileg végzünk zárolást. Ennek további részleterõl a &man.mount.nfs.8; man oldalon kaphatunk felvilágosítást. Gyakori felhasználási módok Az NFS megoldását a gyakorlatban rengeteg esetben alkalmazzák. Ezek közül most felsoroljuk a legelterjedtebbeket: NFS használata Több gép között megosztunk egy telepítõlemezt vagy más telepítõeszközt. Ez így sokkal olcsóbb és gyakorta kényelmes megoldás abban az esetben, ha egyszerre több gépre akarjuk ugyanazt a szoftvert telepíteni. Nagyobb hálózatokon sokkal kényelmesebb lehet egy központi NFS szerver használata, ahol a felhasználók könyvtárait tároljuk. Ezek a felhasználói könyvtárak aztán megoszthatóak a hálózaton keresztül, így a felhasználók mindig ugyanazt a könyvárat kapják függetlenül attól, hogy milyen munkaállomásról is jelentkeztek be. Több géppel is képes így osztozni az /usr/ports/distfiles könyvtáron. Ezen a módon sokkal gyorsabban tudunk portokat telepíteni a gépekre, mivel nem kell külön mindegyikre letölteni az ehhez szükséges forrásokat. Wylie Stilwell Készítette: Chern Lee Újraírta: Automatikus csatlakoztatás az <application>amd</application> használatával amd automatikus csatlakoztató démon Az &man.amd.8; (automatikus csatlakoztató démon, az automatic mounter daemon) önmûködõen csatlakoztatja a távoli állományrendszereket, amikor azokon belül valamelyik állományhoz vagy könyvtárhoz próbálunk hozzáférni. Emellett az amd az egy ideje már inaktív állományrendszereket is automatikusan leválasztja. Az amd használata egy remek alternatívát kínál az általában az /etc/fstab állományban megjelenõ állandóan csatlakoztatott állományrendszerekkel szemben. Az amd úgy mûködik, hogy kapcsolódik egy NFS szerver /host és /net könyvtáraihoz. Amikor egy állományt akarunk elérni ezeken a könyvtárakon belül, az amd kikeresi a megfelelõ távoli csatlakoztatást és magától csatlakoztatja. A /net segítségével egy IP-címrõl tudunk exportált állományrendszereket csatlakoztatni, miközben a /host a távoli gép hálózati neve esetében használatos. Ha tehát a /host/izemize/usr könyvtárban akarunk elérni egy állományt, akkor az amd démonnak ahhoz elõször az izemize nevû géprõl exportált /usr könyvtárat kell csatlakoztatnia. Egy exportált állományrendszer csatlakoztatása az <application>amd</application> használatával Egy távoli számítógép által rendelkezésre bocsátott megosztásokat a showmount paranccsal tudjuk lekérdezni. Például az izemize gépen elérhetõ exportált állományrendszereket így láthatjuk: &prompt.user; showmount -e izemize Exports list on izemize: /usr 10.10.10.0 /a 10.10.10.0 &prompt.user; cd /host/izemize/usr Ahogy a példában látjuk is, a showmount parancs a /usr könyvtárat mutatja megosztásként. Amikor tehát belépünk a /host/izemize/usr könyvtárba, akkor amd magától megpróbálja feloldani az izemize hálózati nevet és csatlakoztatni az elérni kívánt exportált állományrendszert. Az amd az indító szkripteken keresztül az /etc/rc.conf alábbi beállításával engedélyezhetõ: amd_enable="YES" Emellett még az amd_flags használatával további paraméterek is átadható az amd felé. Alapértelmezés szerint az amd_flags tartalmaz az alábbi: amd_flags="-a /.amd_mnt -l syslog /host /etc/amd.map /net /etc/amd.map" Az /etc/amd.map állomány adja meg az exportált állományrendszerek alapértelmezett beállításait. Az /etc/amd.conf állományban az amd további lehetõségeit konfigurálhatjuk.. Ha többet is szeretnénk tudni a témáról, akkor az &man.amd.8; és az &man.amd.conf.5; man oldalakat javasolt elolvasnunk. John Lind Készítette: Problémák más rendszerek használatakor Némely PC-s ISA buszos Ethernet kártyákra olyan korlátozások érvényesek, melyek komoly hálózati problémák keletkezéséhez vezethetnek, különösen az NFS esetében. Ez a nehézség nem &os;-függõ, de a &os; rendszereket is érinti. Ez gond általában majdnem mindig akkor merül fel, amikor egy (&os;-s) PC egy hálózatba kerül többek közt a Silicon Graphic és a Sun Microsystems által gyártott nagyteljesítményû munkaállomásokkal. Az NFS csatlakoztatása és bizonyos mûveletek még hibátlanul végrehajtódnak, azonban hirtelen a szerver látszólag nem válaszol többet a kliens felé úgy, hogy a többi rendszertõl folyamatosan dolgozza felfele a kéréseket. Ez a kliens rendszeren tapasztalható csak, amikor a kliens &os; vagy egy munkaállomás. Sok rendszeren egyszerûen rendesen le sem lehet állítani a klienst, ha a probléma egyszer már felütötte a fejét. Egyedüli megoldás gyakran csak a kliens újraindítása marad, mivel az NFS-ben kialakult helyzetet máshogy nem lehet megoldani. Noha a helyes megoldás az lenne, ha beszereznénk egy nagyobb teljesítményû és kapacitású kártyát a &os; rendszer számára, azonban egy jóval egyszerûbb kerülõút is található a kielégítõ mûködés eléréséhez. Ha a &os; rendszer képviseli a szervert, akkor a kliensnél adjuk meg a beállítást is a csatlakoztatásnál. Ha a &os; rendszer a kliens szerepét tölti be, akkor az NFS állományrendszert az beállítással csatlakoztassuk róla. Ezek a beállítások az fstab állomány negyedik mezõjében is megadhatóak az automatikus csatlakoztatáshoz, vagy manuális esetben a &man.mount.8; parancsnak a paraméterrel. Hozzá kell azonban tennünk, hogy létezik egy másik probléma, amit gyakran ezzel tévesztenek össze, amikor az NFS szerverek és kliensek nem ugyanabban a hálózatban találhatóak. Ilyen esetekben mindenképpen gyõzõdjünk meg róla, hogy az útválasztók rendesen továbbküldik a mûködéshez szükséges UDP információkat, különben nem sokat tudunk tenni a megoldás érdekében. A most következõ példákban a gyorsvonat lesz a nagyteljesítményû munkaállomás (felület) neve, illetve a freebsd pedig a gyengébb teljesítményû Ethernet kártyával rendelkezõ &os; rendszer (felület) neve. A szerveren az /osztott nevû könyvtárat fogjuk NFS állományrendszerként exportálni (lásd &man.exports.5;), amelyet majd a /projekt könyvtárba fogunk csatlakoztatni a kliensen. Minden esetben érdemes lehet még megadnunk a vagy , illetve opciókat is. Ebben a példában a &os; rendszer (freebsd) lesz a kliens, és az /etc/fstab állományában így szerepel az exportált állományrendszer: gyorsvonat:/osztott /projekt nfs rw,-r=1024 0 0 És így tudjuk manuálisan csatlakoztatni: &prompt.root; mount -t nfs -o -r=1024 gyorsvonat:/osztott /projekt Itt a &os; rendszer lesz a szerver, és a gyorsvonat /etc/fstab állománya így fog kinézni: freebsd:/osztott /projekt nfs rw,-w=1024 0 0 Manuálisan így csatlakoztathatjuk az állományrendszert: &prompt.root; mount -t nfs -o -w=1024 freebsd:/osztott /projekt Szinte az összes 16 bites Ethernet kártya képes mûködni a fenti írási vagy olvasási korlátozások nélkül is. A kíváncsibb olvasók számára eláruljuk, hogy pontosan miért is következik be ez a hiba, ami egyben arra is magyarázatot ad, hogy miért nem tudjuk helyrehozni. Az NFS általában 8 kilobyte-os blokkokkal dolgozik (habár kisebb méretû darabkákat is tud készíteni). Mivel az Ethernet által kezelt legnagyobb méret nagyjából 1500 byte, ezért az NFS blokkokat több Ethernet csomagra kell osztani — még olyankor is, ha ez a program felsõbb rétegeiben osztatlan egységként látszik — ezt aztán fogadni kell, összerakni és nyugtázni mint egységet. A nagyteljesítményû munkaállomások a szabvány által még éppen megengedett szorossággal képesek ontani magukból az egy egységhez tartozó csomagokat, közvetlenül egymás után. A kisebb, gyengébb teljesítményû kártyák esetében azonban az egymáshoz tartozó, késõbb érkezõ csomagok ráfutnak a korábban megkapott csomagokra még pontosan azelõtt, hogy elérnék a gépet, így az egységek nem állíthatóak össze vagy nem nyugtázhatóak. Ennek eredményeképpen a munkaállomás egy adott idõ múlva megint próbálkozik, de ismét az egész 8 kilobyte-os blokkot küldi el, ezért ez a folyamat a végtelenségig ismétlõdik. Ha a küldendõ egységek méretét az Ethernet által kezelt csomagok maximális mérete alá csökkentjük, akkor biztosak lehetünk benne, hogy a teljes Ethernet csomag egyben megérkezik és nyugtázódik, így elkerüljük a holtpontot. A nagyteljesítményû munkaállomások természetesen továbbra is küldhetnek a PC-s rendszerek felé túlfutó csomagokat, de egy jobb kártyával az ilyen túlfutások nem érintik az NFS által használt egységeket. Amikor egy ilyen túlfutás bekövetkezik, az érintett egységet egyszerûen újra elküldik, amelyet a rákövetkezõ alkalommal nagy valószínûséggel már tudunk rendesen fogadni, összerakni és nyugtázni. Bill Swingle Írta: Eric Ogren Írta: Udo Erdelhoff Hálózati információs rendszer (NIS/YP) Mi ez? NIS Solaris HP-UX AIX Linux NetBSD OpenBSD A hálózati információs szolgáltatást (Network Information Service, avagy NIS) a Sun Microsystems fejlesztette ki a &unix; (eredetileg &sunos;) rendszerek központosított karbantartásához. Mostanra már lényegében ipari szabvánnyá nõtte ki magát, hiszen az összes nagyobb &unix;-szerû rendszer (a &solaris;, HP-UX, &aix;, Linux, NetBSD, OpenBSD, &os; stb.) támogatja a NIS használatát. sárga oldalak NIS A NIS régebben sárga oldalak (Yellow Pages) néven volt ismert, de a különbözõ jogi problémák miatt késõbb ezt a Sun megváltoztatta. A régi elnevezést (és a yp rövidítést) azonban még napjainkban is lehet néhol látni. NIS tartományok Ez egy RPC alapján mûködõ, kliens/szerver felépítésû rendszer, amely az egy NIS tartomány belül levõ számítógépek számára teszi lehetõvé ugyanazon konfigurációs állományok használatát. Segítségével a rendszergazda a NIS klienseket a lehetõ legkevesebb adat hozzáadásával, eltávolításával vagy módosításával képes egyetlen helyrõl beállítani. Windows NT Hasonló a &windowsnt; tartományaihoz, és habár a belsõ implementációt tekintve már akadnak köztük jelentõs eltérések is, az alapvetõ funkciók szintjén mégis összevethetõek. A témához tartozó fogalmak és programok A NIS telepítése számos fogalom és fontos felhasználói program kerül elõ &os;-n, akár egy NIS szervert akarunk beállítani, akár csak egy NIS klienst: rpcbind portmap Fogalom Leírás NIS tartománynév A NIS központi szerverei és az összes hozzájuk tartozó kliens (beleértve az alárendelt szervereket) rendelkezik egy NIS tartománynévvel. Hasonló a &windowsnt; által használt tartománynevekhez, de a NIS tartománynevei semmilyen kapcsolatban nem állnak a névfeloldással. rpcbind Az RPC (Remote Procedure Call, a NIS által használt egyik hálózati protokoll) engedélyezéséhez lesz rá szükségünk. Ha az rpcbind nem fut, akkor sem NIS szervert, sem pedig NIS klienst nem tudunk mûködtetni. ypbind A NIS klienst köti össze a hozzátartozó NIS szerverrel. A NIS tartománynevet a rendszertõl veszi, és az RPC használatával csatlakozik a szerverhez. Az ypbind a NIS környezet kliens és szerver közti kommunikációjának magját alkotja. Ha az ypbind leáll a kliens gépén, akkor nem tudjuk elérni a NIS szervert. ypserv Csak a NIS szervereken szabad futnia, mivel ez maga a NIS szerver programja. Ha az &man.ypserv.8; leáll, akkor a szerver nem lesz képes tovább kiszolgálni a NIS kéréseket (szerencsére az alárendelt szerverek képesek átvenni ezeket). A NIS bizonyos változatai (de nem az, amelyik a &os;-ben is megjelenik) nem próbálnak meg más szerverekhez csatlakozni, ha bedöglik az aktuális használt szerver. Ezen gyakran egyedül csak a szervert képviselõ program (vagy akár az egész szerver) újraindítása segíthet, illetve az ypbind újraindítása a kliensen. rpc.yppasswdd Ez egy olyan program, amelyet csak a NIS központi szerverein kell csak futtatni. Ez a démon a NIS kliensek számára a NIS jelszavaik megváltoztatását teszi lehetõvé. Ha ez a démon nem fut, akkor a felhasználók csak úgy tudják megváltoztatni a jelszavukat, ha bejelentkeznek a központi NIS szerverre. Hogyan mûködik? A NIS környezetekben háromféle gép létezik: a központi szerverek, az alárendelt szerverek és a kliensek. A szerverek képezik a gépek konfigurációs információinak központi tárhelyét. A központi szerverek tárolják ezen információk hiteles másolatát, míg ezt az alárendelt szerverek redundánsan tükrözik. A kliensek a szerverekre támaszkodnak ezen információk beszerzéséhez. Sok állomány tartalma megosztható ezen a módon. Például a master.passwd, a group és hosts állományokat meg szokták osztani NFS-en. Amikor a kliensen futó valamelyik programnak olyan információra lenne szüksége, amely általában ezekben az állományokban nála megtalálható lenne, akkor helyette a NIS szerverhez fordul. A gépek típusai NIS központi szerver A központi NIS szerver. Ez a szerver, amely leginkább a &windowsnt; elsõdleges tartományvezérlõjéhez hasonlítható tartja karban az összes, NIS kliensek által használt állományt. A passwd, group, és összes többi ehhez hasonló állomány ezen a központi szerveren található meg. Egy gép akár több NIS tartományban is lehet központi szerver. Ezzel a lehetõséggel viszont itt most nem foglalkozunk, mivel most csak egy viszonylag kis méretû NIS környezetet feltételezünk. NIS alárendelt szerver Az alárendelt NIS szerverek. A &windowsnt; tartalék tartományvezérlõihez hasonlítanak, és az alárendelt NIS szerverek feladata a központi NIS szerveren tárolt adatok másolatainak karbantartása. Az alárendelt NIS szerverek a redundancia megvalósításában segítenek, aminek leginkább a fontosabb környezetekben van szerepe. Emellett a központi szerver terhelésének kiegyenlítését is elvégzik. A NIS kliensek elsõként mindig ahhoz a NIS szerverhez csatlakoznak, amelytõl elõször választ kapnak, legyen akár az egy alárendelt szerver. NIS kliens A NIS kliensek. A NIS kliensek, hasonlóan a &windowsnt; munkaállomásokhoz, a NIS szerveren (amely a &windowsnt; munkaállomások esetében a tartományvezérlõ) keresztül jelentkeznek be. A NIS/YP használata Ebben a szakaszban egy példa NIS környezetet állítunk be. Tervezés Tegyük fel, hogy egy aprócska egyetemi labor rendszergazdái vagyunk. A labor, mely 15 &os;-s gépet tudhat magáénak, jelen pillanatban még semmilyen központosított adminisztráció nem létezik. Mindegyik gép saját /etc/passwd és /etc/master.passwd állománnyal rendelkezik. Ezeket az állományokat saját kezûleg kell szinkronban tartani. Tehát ha most felveszünk egy felhasználót a laborhoz, akkor az adduser parancsot mind a 15 gépen ki kell adni. Egyértelmû, hogy ez így nem maradhat, ezért úgy döntöttük, hogy a laborban NIS-t fogunk használni, és két gépet kinevezünk szervernek. Az iméntieknek megfelelõen a labor most valahogy így néz ki: A gép neve IP-cím A gép szerepe ellington 10.0.0.2 központi NIS coltrane 10.0.0.3 alárendelt NIS basie 10.0.0.4 tanszéki munkaállomás bird 10.0.0.5 kliensgép cli[1-11] 10.0.0.[6-17] a többi kliensgép Ha még nincs tapasztalatunk a NIS rendszerek összeállításában, akkor elõször jó ötlet lehet végiggondolni, miként is akarjuk kialakítani. A hálózatunk méretétõl függetlenül is akadnak olyan döntések, amelyeket mindenképpen meg kell hoznunk. A NIS tartománynév megválasztása NIS tartománynév Ez nem az a tartománynév, amit megszokhattunk. Ennek a pontos neve NIS tartománynév. Amikor a kliensek kérnek valamilyen információt, akkor megadják annak a NIS tartománynak a nevét is, amelynek részei. Így tud egy hálózaton több szerver arról dönteni, hogy melyikük melyik kérést válaszolja meg. A NIS által használt tartománynévre tehát inkább úgy érdemes gondolni, mint egy valamilyen módon összetartozó gépek közös nevére. Elõfordul, hogy egyes szervezetek az interneten is nyilvántartott tartománynevüket választják NIS tartománynévnek. Ez alapvetõen nem ajánlott, mivel a hálózati problémák felderítése közben félreértéseket szülhet. A NIS tartománynévnek a hálózatunkon belül egyedinek kell lennie, és lehetõleg minél jobban írja le az általa csoportba sorolt gépeket. Például a Kis Kft. üzleti osztályát tegyük a kis-uzlet NIS tartományba. Ebben a példában most a proba-tartomany nevet választottuk. SunOS A legtöbb operációs rendszer azonban (köztük a &sunos;) a NIS tartománynevet használja internetes tartománynévként is. Ha a hálózatunkon egy vagy több ilyen gép is található, akkor a NIS tartomány nevének az internetes tartománynevet kell megadnunk. A szerverek fizikai elvárásai Nem árt néhány dolgot fejben tartani, amikor a NIS szervernek használt gépet kiválasztjuk. Az egyik ilyen szerencsétlen dolog az a szintû függõség, ami a NIS kliensek felõl megfigyelhetõ a szerverek felé. Ha egy kliens nem tudja a NIS tartományon belül felvenni a kapcsolatot valamelyik szerverrel, akkor az a gép könnyen megbízhatatlanná válhat. Felhasználói- és csoportinformációk nélkül a legtöbb rendszer egy idõre le is merevedik. Ennek figyelembevételével tehát olyan gépet kell szervernek választanunk, amelyet nem kell gyakran újraindítani, és nem végzünk rajta semmilyen komoly munkát. A célnak legjobban megfelelõ NIS szerverek valójában olyan gépek, amelyek egyedüli feladata csak a NIS kérések kiszolgálása. Ha a hálózatunk nem annyira leterhelt, akkor még a NIS szerver mellett más programokat is futtathatunk, de ne feledjük, hogy ha a NIS szolgáltatás megszûnik, akkor az az összes NIS kliensen éreztetni fogja kedvezõtlen hatását. A NIS szerverek A NIS rendszerben tárolt összes információ általános példánya egyetlen gépen található meg, amelyet a központi NIS szervernek hívunk. Az információk tárolására szánt adatbázis pedig NIS táblázatoknak (NIS map) nevezzük. &os; alatt ezek a táblázatok a /var/yp/tartománynév könyvtárban találhatóak, ahol a tartománynév a kiszolgált NIS tartományt nevezi meg. Egyetlen NIS szerver egyszerre akár több tartományt is kiszolgálhat, így itt több könyvtár is található, minden támogatott tartományhoz egy. Minden tartomány saját, egymástól független táblázatokkal rendelkezik. A központi és alárendelt NIS szerverek az ypserv démon segítségével dolgozzák fel a NIS kéréseket. Az ypserv felelõs a NIS kliensektõl befutó kérések fogadásáért, és a kért tartomány valamint táblázat nevébõl meghatározza az adatbázisban tárolt állományt, majd innen visszaküldi a hozzátartozó adatot a kliensnek. A központi NIS szerver beállítása NIS szerver beállítása A központi NIS szerver beállítása viszonylag magától értetõdõ, de a nehézségét az igényeink szabják meg. A &os; alapból támogatja a NIS használatát. Ezért mindössze annyit kell tennünk, hogy a következõ sorokat betesszük az /etc/rc.conf állományba, és a &os; gondoskodik a többirõl. nisdomainname="proba-tartomany" Ez a sor adja meg a hálózati beállítások (vagy például az újraindítás) során a NIS tartomány nevét, amely a korábbiak szerint itt most a proba-tartomany. nis_server_enable="YES" Ezzel utasítjuk a &os;-t, hogy a hálózati alkalmazások következõ indításakor a NIS szervert is aktiválja. nis_yppasswdd_enable="YES" Ezzel engedélyezzük az rpc.yppasswdd démont, amely a korábban említettek szerint lehetõvé teszi a felhasználók számára, hogy a közvetlenül a kliensekrõl változtassák meg a NIS jelszavukat. A konkrét NIS beállításainktól függõen további bejegyzések felvételére is szükségünk lehet. Erre késõbb még az olyan NIS szervereknél, amelyek egyben NIS kliensek, vissza fogunk térni. Most mindössze annyit kell tennünk, hogy rendszeradminisztrátorként kiadjuk az /etc/netstart parancsot. Az /etc/rc.conf állományban szereplõ adatok alapján mindent beállít magától. A NIS táblázatok inicializálása NIS táblázatok A NIS táblázatok lényegében a /var/yp könyvtárban tárolt adatbázisok. A központi NIS szerver /etc könyvtárában található konfigurációs állományokból állítódnak elõ, egyetlen kivétellel: ez az /etc/master.passwd állomány. Ennek megvan a maga oka, hiszen nem akarjuk a root és az összes többi fontosabb felhasználóhoz tartozó jelszót az egész NIS tartománnyal megosztani. Ennek megfelelõen a NIS táblázatok inicializálásához a következõt kell tennünk: &prompt.root; cp /etc/master.passwd /var/yp/master.passwd &prompt.root; cd /var/yp &prompt.root; vi master.passwd El kell távolítanunk az összes rendszerszintû (bin, tty, kmem, games, stb), és minden olyan egyéb hozzáférést, amelyeket nem akarjuk közvetíteni a NIS kliensek felé (például a root és minden más nullás, vagyis rendszeradminisztrátori azonosítóval ellátott hozzáférést). Gondoskodjunk róla, hogy az /var/yp/master.passwd állomány sem a csoport, sem pedig bárki más számára nem olvasható (600-as engedély)! Ennek beállításához használjuk az chmod parancsot, ha szükséges. Tru64 UNIX Ha végeztünk, akkor már tényleg itt az ideje inicializálni NIS táblázatainkat. A &os; erre egy ypinit nevû szkriptet ajánl fel (errõl a saját man oldalán tudhatunk meg többet). Ez a szkript egyébként a legtöbb &unix; típusú operációs rendszeren megtalálható, de nem az összesen. A Digital UNIX/Compaq Tru64 UNIX rendszereken ennek a neve ypsetup. Mivel most a központi NIS szerver táblázatait hozzuk létre, azért az ypinit szkriptnek át kell adnunk a opciót is. A NIS táblázatok elõállításánál feltételezzük, hogy a fentebb ismertetett lépéseket már megtettük, majd kiadjuk ezt a parancsot: ellington&prompt.root; ypinit -m proba-tartomany Server Type: MASTER Domain: proba-tartomany Creating an YP server will require that you answer a few questions. Questions will all be asked at the beginning of the procedure. Do you want this procedure to quit on non-fatal errors? [y/n: n] n Ok, please remember to go back and redo manually whatever fails. If you don't, something might not work. At this point, we have to construct a list of this domains YP servers. rod.darktech.org is already known as master server. Please continue to add any slave servers, one per line. When you are done with the list, type a <control D>. master server : ellington next host to add: coltrane next host to add: ^D The current list of NIS servers looks like this: ellington coltrane Is this correct? [y/n: y] y [ .. a táblázatok generálása .. ] NIS Map update completed. ellington has been setup as an YP master server without any errors. Az üzenetek fordítása: A szerver típusa: KÖZPONTI, tartomány: proba-tartomany Az YP szerver létrehozásához meg kell válaszolni néhány kérdést az eljárás megkezdése elõtt. Szeretnénk, ha az eljárás megszakadna a nem végzetes hibák esetén is? [i/n: n] n Rendben, akkor ne felejtsük el manuálisan kijavítani a hibát, ha valamivel gond lenne. Ha nem tesszük meg, akkor elõfordulhat, hogy valami nem fog rendesen mûködni. Most össze kell állítanunk egy listát a tartomány YP szervereirõl. Jelenleg a rod.darktech.org a központi szerver. Kérjünk, adjon meg további alárendelt szervereket, soronként egyet. Amikor ezt befejeztük, a <control D> lenyomásával tudunk kilépni. központi szerver : ellington következõ gép : coltrane következõ gép : ^D A NIS szerverek listája jelenleg a következõ: ellington coltrane Ez megfelelõ? [i/n: i] i [ .. a táblázatok generálása .. ] A NIS táblázatok sikeressen frissültek. Az elligon szervert minden hiba nélkül sikerült központi szerverként beállítani. Az ypinit a /var/yp/Makefile.dist állományból létrehozza a /var/yp/Makefile állományt. Amennyiben ez létrejött, az állomány feltételezi, hogy csak &os;-s gépek részvételével akarunk kialakítani egy egyszerveres NIS környezetet. Mivel a proba-tartomany még egy alárendelt szervert is tartalmaz, ezért át kell írnunk a /var/yp/Makefile állományt: ellington&prompt.root; vi /var/yp/Makefile Ezt a sort kell megjegyzésbe tennünk: NOPUSH = "True" (ha még nem lenne úgy). Az alárendelt NIS szerverek beállítása NIS alárendelt szerver Az alárendelt NIS szerverek beállítása még a központinál is egyszerûbb. Jelentkezzünk be az alárendelt szerverre és az eddigieknek megfelelõen írjuk át az /etc/rc.conf állományt. Az egyetlen különbség ezúttal csupán annyi lesz, hogy az ypinit lefuttatásakor a opciót kell megadnunk (mint slave, vagyis alárendelt). A opció használatához a központi NIS szerver nevét is át kell adnunk, ezért a konkrét parancs valahogy így fog kinézni: coltrane&prompt.root; ypinit -s ellington proba-tartomany Server Type: SLAVE Domain: test-domain Master: ellington Creating an YP server will require that you answer a few questions. Questions will all be asked at the beginning of the procedure. Do you want this procedure to quit on non-fatal errors? [y/n: n] n Ok, please remember to go back and redo manually whatever fails. If you don't, something might not work. There will be no further questions. The remainder of the procedure should take a few minutes, to copy the databases from ellington. Transferring netgroup... ypxfr: Exiting: Map successfully transferred Transferring netgroup.byuser... ypxfr: Exiting: Map successfully transferred Transferring netgroup.byhost... ypxfr: Exiting: Map successfully transferred Transferring master.passwd.byuid... ypxfr: Exiting: Map successfully transferred Transferring passwd.byuid... ypxfr: Exiting: Map successfully transferred Transferring passwd.byname... ypxfr: Exiting: Map successfully transferred Transferring group.bygid... ypxfr: Exiting: Map successfully transferred Transferring group.byname... ypxfr: Exiting: Map successfully transferred Transferring services.byname... ypxfr: Exiting: Map successfully transferred Transferring rpc.bynumber... ypxfr: Exiting: Map successfully transferred Transferring rpc.byname... ypxfr: Exiting: Map successfully transferred Transferring protocols.byname... ypxfr: Exiting: Map successfully transferred Transferring master.passwd.byname... ypxfr: Exiting: Map successfully transferred Transferring networks.byname... ypxfr: Exiting: Map successfully transferred Transferring networks.byaddr... ypxfr: Exiting: Map successfully transferred Transferring netid.byname... ypxfr: Exiting: Map successfully transferred Transferring hosts.byaddr... ypxfr: Exiting: Map successfully transferred Transferring protocols.bynumber... ypxfr: Exiting: Map successfully transferred Transferring ypservers... ypxfr: Exiting: Map successfully transferred Transferring hosts.byname... ypxfr: Exiting: Map successfully transferred coltrane has been setup as an YP slave server without any errors. Don't forget to update map ypservers on ellington. Most már lennie kell egy /var/yp/proba-tartomany nevû könyvtárunknak is. A központi NIS szerver táblázatainak másolata itt fognak tárolódni. Ezeket soha ne felejtsük el frissen tartani. Az alárendelt szervereken a következõ /etc/crontab bejegyzések pontosan ezt a feladatot látják el: 20 * * * * root /usr/libexec/ypxfr passwd.byname 21 * * * * root /usr/libexec/ypxfr passwd.byuid Ez a két sor gondoskodik róla, hogy az alárendelt szerverek ne felejtsék el egyeztetni a táblázataikat a központi szerver táblázataival. Habár ezek a bejegyzések nem nélkülözhetetlenek a megfelelõ mûködéshez, mivel a központi szerver mindig igyekszik az alárendelt szervereknek elküldeni a NIS táblázataiban létrejött változásokat. Mivel azonban a jelszavak létfontosságúak a szervertõl függõ rendszerek számára, ezért jó ötlet lehet explicit módon is elõírni a frissítést. Ez a forgalmasabb hálózatokon nagyobb jelentõséggel bír, mivel ott a táblázatok frissítése nem mindig fejezõdik be rendesen. Most pedig futassuk le a /etc/netstart parancsot az alárendelt szervereken is, amivel így elindul a NIS szerver. A NIS kliensek A NIS kliens az ypbind démon segítségével egy kötésnek (bind) nevezett kapcsolatot épít ki egy adott NIS szerverrel. Az ypbind ellenõrzi a rendszer alapértelmezett tartományát (ezt a domainname paranccsal állítottunk be), majd RPC kéréseket kezd szórni a helyi hálózaton. Ezek a kérések annak a tartománynak a nevét tartalmazzák, amelyhez az ypbind megpróbál kötést létrehozni. Ha az adott tartomány kiszolgálására beállított szerver észleli ezeket a kéréseket, akkor válaszol az ypbind démonnak, amely pedig feljegyzi a szerver címét. Ha több szerver is elérhetõ (például egy központi és több alárendelt), akkor az ypbind az elsõként válaszoló címét fogja rögzíteni. Innentõl kezdve a kliens közvetlenül ennek a szervernek fogja küldeni a NIS kéréseit. Az ypbind idõnként megpingeli a szervert, hogy meggyõzõdjön az elérhetõségérõl. Ha az ypbind egy adott idõn belül nem kap választ a ping kéréseire, akkor megszünteti a kötést a tartományhoz és nekilát keresni egy másik szervert. A NIS kliensek beállítása NIS a kliensek beállítása Egy &os;-s gépet NIS kliensként meglehetõsen egyszerûen lehet beállítani. Nyissuk meg az /etc/rc.conf állományt és a NIS tartománynév beállításához, valamint az ypbind elindításához a következõket írjuk bele: nisdomainname="proba-tartomany" nis_client_enable="YES" A NIS szerveren található jelszavak importálásához távolítsuk el az összes felhasználói hozzáférést az /etc/master.passwd állományunkból és a vipw segítségével adjuk hozzá az alábbi sort az állomány végéhez: +::::::::: Ez a sor beenged bárkit a rendszerünkre, akinek a NIS szervereken van érvényes hozzáférése. A NIS klienseket ezzel a sorral sokféle módon tudjuk állítani. A hálózati csoportokról szóló szakaszban találunk majd errõl több információt. A téma mélyebb megismeréséhez az O'Reilly Managing NFS and NIS címû könyvét ajánljuk. Legalább helyi hozzáférést (vagyis amit nem NIS-en keresztül importálunk) azonban mindenképpen hagyjunk meg az /etc/master.passwd állományunkban, és ez a hozzáférés legyen a wheel csoport tagja. Ha valami gond lenne a NIS használatával, akkor ezen a hozzáférésen keresztül tudunk a gépre távolról bejelentkezni, majd innen root felhasználóra váltva megoldani a felmerült problémákat. A NIS szerverrõl az összes lehetséges csoport-bejegyzést az /etc/group állományban így tudjuk importálni: +:*:: Miután elvégeztük ezeket a lépéseket, képesek leszünk futtatni az ypcat passwd parancsot, és látni a NIS szerver jelszavakat tartalmazó táblázatát. A NIS biztonsága Általában tetszõleges távoli felhasználó küldhet RPC kéréseket az &man.ypserv.8; számára és kérheti le a NIS táblázatok tartalmát, feltéve, hogy ismeri a tartomány nevét. Az ilyen hitelesítés nélküli mûveletek ellen az &man.ypserv.8; úgy védekezik, hogy tartalmaz egy securenets nevû lehetõséget, amellyel az elérhetõségüket tudjuk leszûkíteni gépek egy csoportjára. Az &man.ypserv.8; indításakor ezeket az információkat a /var/yp/securenets állományból próbálja meg betölteni. Az elérési útvonala megadható a opció használatával. Ez az állomány olyan bejegyzéseket tartalmaz, amelyekben egy hálózati cím és tõle láthatatlan karakterekkel elválasztva egy hálózati maszk szerepel. A # karakterrel kezdõdõ sorokat megjegyzésnek nyilvánítjuk. Egy minta securenets állomány valahogy így nézne ki: # Engedélyezzük önmagunkról a csatlakozást -- kell! 127.0.0.1 255.255.255.255 # Engedélyezzük a 192.168.128.0 hálózatról érkezõ csatlakozásokat: 192.168.128.0 255.255.255.0 # Engedélyezzük a laborban található 10.0.0.0 és 10.0.15.255 közti # címekkel rendelkezõ gépek csatlakozását: 10.0.0.0 255.255.240.0 Ha az &man.ypserv.8; olyan címrõl kap kérést, amely illeszkedik az elõírt címek valamelyikére, akkor a szokásos módon feldolgozza azt. Ellenkezõ esetben a kérést figyelmen kívül hagyja és egy figyelmeztetést vesz fel hozzá a naplóba. Ha a /var/yp/securenets állomány nem létezik, akkor az ypserv tetszõleges géprõl engedélyezi a csatlakozást. Az ypserv lehetõséget ad a Wietse Venema által fejlesztett TCP Wrapper csomag használatára is. Ezzel a rendszergazda a /var/yp/securenets állomány helyett a TCP Wrapper konfigurációs állományai alapján képes szabályozni az elérhetõséget. Miközben mind a két módszer nyújt valamilyen fajta védelmet, de a privilegizált portok teszteléséhez hasonlóan az IP álcázásával (IP spoofing) sebezhetõek. Ezért az összes NIS-hez tartozó forgalmat tûzfallal kell blokkolnunk. Az /var/yp/securenets állományt használó szerverek nem képesek az elavult TCP/IP implementációkat használó érvényes klienseket rendesen kiszolgálni. Egyes ilyen implementációk a címben a géphez tartozó biteket nullára állítják az üzenetszóráshoz, és/vagy ezért az üzenetszóráshoz használt cím kiszámításakor nem tudja észleli a hálózati maszkot. A legtöbb ilyen probléma megoldható a kliens konfigurációjának megváltoztatásával, míg más problémák megoldása a kérdéses kliensek nyugdíjazását kívánják meg, vagy a /var/yp/securenets használatának elhagyását. Egy régebbi TCP/IP implementációval üzemelõ szerveren pedig a /var/yp/securenets állomány használata kifejezetten rossz ötlet, és a hálózatunk nagy részében képes használhatatlanná tenni a NIS funkcióit. TCP wrapperek A TCP Wrapper csomag alkalmazása a NIS szerverünk válaszadáshoz szükséges idejét is segít csökkenteni. Az ilyenkor jelentkezõ plusz késlekedés mellesleg elég nagy lehet ahhoz, hogy a klienseknél idõtúllépés következzen be, különösen a terheltebb hálózatokon vagy a lassú NIS szerverek esetében. Ha egy vagy több kliensünk is ilyen tüneteket mutat, akkor érdemes a kérdéses kliens rendszereket alárendelt NIS szerverekké alakítani és önmagukhoz rendelni. Egyes felhasználók bejelentkezésének megakadályozása A laborunkban van egy basie nevû gép, amely a tanszék egyetlen munkaállomása. Ezt a gépet nem akarjuk kivenni a NIS tartományból, de a központi NIS szerver passwd állománya mégis egyaránt tartalmazza a hallgatók és az oktatók eléréseit. Mit lehet ilyenkor tenni? Adott felhasználók esetében le tudjuk tiltani a bejelentkezést a gépen még olyankor is, ha léteznek a NIS adatbázisában. Ehhez mindössze a kliensen az /etc/master.passwd állomány végére be kell tennünk egy -felhasználónév sort, ahol a felhasználónév annak a felhasználónak a neve, akit nem akarunk beengedni a gépre. Ezt leginkább a vipw használatán keresztül érdemes megtennünk, mivel a vipw az /etc/master.passwd állomány alapján végez némi ellenõrzést, valamint a szerkesztés befejeztével magától újragenerálja a jelszavakat tároló adatbázist. Például, ha a bill nevû felhasználót ki akarjuk tiltani a basie nevû géprõl, akkor: basie&prompt.root; vipw [vegyük fel a -bill sort a végére, majd lépjünk ki] vipw: rebuilding the database... vipw: done basie&prompt.root; cat /etc/master.passwd root:[jelszó]:0:0::0:0:The super-user:/root:/bin/csh toor:[jelszó]:0:0::0:0:The other super-user:/root:/bin/sh daemon:*:1:1::0:0:Owner of many system processes:/root:/sbin/nologin operator:*:2:5::0:0:System &:/:/sbin/nologin bin:*:3:7::0:0:Binaries Commands and Source,,,:/:/sbin/nologin tty:*:4:65533::0:0:Tty Sandbox:/:/sbin/nologin kmem:*:5:65533::0:0:KMem Sandbox:/:/sbin/nologin games:*:7:13::0:0:Games pseudo-user:/usr/games:/sbin/nologin news:*:8:8::0:0:News Subsystem:/:/sbin/nologin man:*:9:9::0:0:Mister Man Pages:/usr/share/man:/sbin/nologin bind:*:53:53::0:0:Bind Sandbox:/:/sbin/nologin uucp:*:66:66::0:0:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico xten:*:67:67::0:0:X-10 daemon:/usr/local/xten:/sbin/nologin pop:*:68:6::0:0:Post Office Owner:/nonexistent:/sbin/nologin nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/sbin/nologin +::::::::: -bill basie&prompt.root; Udo Erdelhoff Készítette: A hálózati csoportok alkalmazása hálózati csoportok Az elõzõ szakaszban ismertetett módszer viszonylag jól mûködik olyan esetekben, amikor nagyon kevés felhasználóra és/vagy számítógépre kell alkalmaznunk speciális megszorításokat. A nagyobb hálózatokban szinte biztos, hogy elfelejtünk kizárni egyes felhasználókat az érzékeny gépekrõl, vagy az összes gépen egyenként kell ehhez a megfelelõ beállításokat elvégezni, és ezzel lényegében elvesztjük a NIS legfontosabb elõnyét, vagyis a központosított karbantarthatóságot. A NIS fejlesztõi erre a problémára a hálózati csoportokat létrehozásával válaszoltak. A céljuk és mûködésük szempontjából leginkább a &unix;-os állományrendszerekben található csoportokhoz mérhetõek. A legnagyobb eltérés a numerikus azonosítók hiányában mutatkozik meg, valamint a hálózati csoportokat a felhasználókon kívül további hálózati csoportok megadásával is ki lehet alakítani. A hálózati csoportok a nagyobb, bonyolultabb, többszáz felhasználós hálózatok számára jöttek létre. Egy részrõl ez nagyon jó dolog, különösen akkor, ha egy ilyen helyzettel kell szembenéznünk. Másrészrõl ez a mértékû bonyolultság szinte teljesen lehetetlenné teszi a hálózati csoportok egyszerû bemutatását. A szakasz további részében használt példa is ezt a problémát igyekszik illusztrálni. Tételezzük fel, hogy laborunkban a NIS sikeres bevezetése felkeltette a fõnökeink figyelmét. Így a következõ feladatunk az lett, hogy terjesszük ki a NIS tartományt az egyetemen található néhány másik gépre is. Az alábbi két táblázatban az új felhasználók és az új számítógép neveit találjuk, valamint a rövid leírásukat. Felhasználók nevei Leírás alpha, beta az IT tanszék hétköznapi dolgozói charlie, delta az IT tanszék újdonsült dolgozói echo, foxtrott, golf, ... átlagos dolgozók able, baker, ... ösztöndíjasok Gépek nevei Leírás haboru, halal, ehseg, szennyezes A legfontosabb szervereink. Csak az IT tanszék dolgozói férhetnek hozzájuk. buszkeseg, kapzsisag, irigyseg, harag, bujasag, lustasag Kevésbé fontos szerverek. Az IT tankszék összes tagja el tudja érni ezeket a gépeket. egy, ketto, harom, negy, ... Átlagos munkaállomások. Egyedül csak a valódi dolgozók jelentkezhetnek be ezekre a gépekre. szemetes Egy nagyon régi gép, semmi értékes adat nincs rajta. Akár még az öszöndíjasok is nyúzhatják. Ha ezeket az igényeket úgy próbáljuk meg teljesíteni, hogy a felhasználókat egyenként blokkoljuk, akkor minden rendszer passwd állományába külön fel kell vennünk a -felhasználó sorokat a letiltott felhasználókhoz. Ha csak egyetlen bejegyzést is kihagyunk, akkor könnyen bajunk származhat belõle. Ez a rendszer kezdeti beállítása során még talán nem okoz gondot, de az új felhasználókat biztosan el fogjuk felejteni felvenni a megfelelõ csoportokba. Elvégre Murphy is optimista volt. A hálózati csoportok használata ilyen helyzetekben számos elõnyt rejt. Nem kell az egyes felhasználókat külön felvenni, egy felhasználót felveszünk valamelyik csoportba vagy csoportokba, és a csoportok összes tagjának egyszerre tudjuk tiltani vagy engedélyezni a hozzáféréseket. Ha hozzáadunk egy új gépet a hálózatunkhoz, akkor mindössze a hálózati csoportok bejelentkezési korlátozásait kell beállítani. Ha új felhasználót veszünk fel, akkor a felhasználót kell vennünk egy vagy több hálózati csoportba. Ezek a változtatások függetlenek egymástól, és nincs szükség minden felhasználó és minden gép összes kombinációjára. Ha a NIS beállításainkat elõzetesen körültekintõen megterveztük, akkor egyetlen központi konfigurációs állományt kell módosítani a gépek elérésének engedélyezéséhez vagy tiltásához. Az elsõ lépés a hálózati csoportokat tartalmazó NIS táblázat inicializálása. A &os; &man.ypinit.8; programja alapértelmezés szerint nem hozza létre ezt a táblázatot, de ha készítünk egy ilyet, akkor a NIS implementációja képes kezelni. Egy ilyen üres táblázat elkészítéséhez ennyit kell begépelni: ellington&prompt.root; vi /var/yp/netgroup Ezután elkezdhetjük felvenni a tartalmát. A példánk szerint legalább négy hálózati csoportot kell csinálnunk: az IT dolgozóinak, az IT új dolgozóinak, a normál dolgozóknak és az öszöndíjasoknak. IT_DOLG (,alpha,proba-tartomany) (,beta,proba-tartomany) IT_UJDOLG (,charlie,proba-tartomany) (,delta,proba-tartomany) FELHASZNALO (,echo,proba-tartomany) (,foxtrott,proba-tartomany) \ (,golf,proba-tartomany) OSZTONDIJAS (,able,proba-tartomany) (,baker,proba-tartomany) Az IT_DOLG, IT_UJDOLG stb. a hálózati csoportok nevei lesznek. Minden egyes zárójelezett csoport egy vagy több felhasználói hozzáférést tartalmaz. A csoportokban szereplõ három mezõ a következõ: Azon gépek neve, amelykre a következõ elemek érvényesek. Ha itt nem adunk meg neveket, akkor a bejegyzés az összes gépre vonatkozik. Ha megadjuk egy gép nevét, akkor jutalmunk a teljes sötétség, a rettegetés és totális megtébolyodás. A csoporthoz tartozó hozzáférés neve. A hozzáféréshez kapcsolódó NIS tartomány. A csoportba más NIS tartományokból is át tudunk hozni hozzáféréseket, ha netalán éppen olyan szerencsétlenek lennénk, hogy több NIS tartományt is felügyelnünk kell. A mezõk mindegyike tartalmazhat dzsókerkaraktereket. Errõl részletesebben a &man.netgroup.5; man oldalon olvashatunk. hálózati csoportok A hálózati csoportoknak lehetõleg ne adjunk 8 karakternél hosszabb nevet, különösen abban az esetben, ha a NIS tartományban más operációs rendszereket is használunk. A nevekben eltérnek a kis- és nagybetûk. Ha a hálózati csoportokat nevét nagybetûkkel írjuk, akkor könnyen különbséget tudunk tenni a felhasználók, gépek és hálózati csoportok nevei között. Egyes (nem &os; alapú) NIS kliensek nem képesek kezelni a nagyon sok bejegyzést tartalmazó hálózati csoportokat. Például a &sunos; néhány korábbi verziója fennakad rajta, ha egy hálózati csoport 15 bejegyzésnél többet tartalmaz. Az ilyen korlátozások alól úgy tudunk kibújni, ha 15 felhasználónként újabb hálózati csoportokat hozunk létre, amelyekkel az eredeti hálózati csoportot építjük fel: NAGYCSP1 (,joe1,tartomany) (,joe2,tartomany) (,joe3,tartomany) [...] NAGYCSP2 (,joe16,tartomany) (,joe17,tartomany) [...] NAGYCSP3 (,joe31,tartomany) (,joe32,tartomany) NAGYCSOPORT NAGYCSP1 NAGYCSP2 NAGYCSP3 Ugyanez a folyamat javasolt olyan esetekben is, ahol 225 felhasználónál többre lenne szükség egyetlen hálózati csoporton belül. Az így létrehozott új NIS táblázat szétküldése meglehetõsen könnyû feladat: ellington&prompt.root; cd /var/yp ellington&prompt.root; make Ez a parancs létrehoz három NIS táblázatot: netgroup, netgroup.byhost és netgroup.byuser. Az &man.ypcat.1; paranccsal ellenõrizni is tudjuk az új NIS táblázatainkat: ellington&prompt.user; ypcat -k netgroup ellington&prompt.user; ypcat -k netgroup.byhost ellington&prompt.user; ypcat -k netgroup.byuser Az elsõ parancs kimenete a /var/yp/netgroup állomány tartalmára emlékeztethet minket. A második parancsnak nincs semmilyen kimenete, hacsak nem adtunk meg valamilyen gépfüggõ hálózati csoportot. A harmadik parancs a hálózati csoportokat listázza ki a felhasználókhoz. A kliensek beállítása tehát nagyon egyszerû. A haboru nevû szerver beállításához indítsuk el a &man.vipw.8; programot, és cseréljük a +::::::::: sort erre: +@IT_DOLG::::::::: Innentõl kezdve kizárólag csak az IT_DOLG csoportban található felhasználók fognak bekerülni a haboru jelszó adatbázisába, és csak ezek a felhasználók tudnak ide bejelentkezni. Sajnos ez a korlátozás a parancsértelmezõ ~ funkciójára és összes olyan rutinra is vonatkozik, amelyet a felhasználói nevek és azok numerikus azonosító között képez le. Más szóval a cd ~felhasználó parancs nem fog mûködni, és az ls -l parancs kimenetében a felhasználói nevek helyett csak numerikus azonosítók jelennek meg, továbbá afind . -user joe -print No such user (Nincs ilyen felhasználó) hibát fog visszaadni. Ez úgy tudjuk megjavítani, ha úgy importáljuk a szerverre az összes felhasználó bejegyzését, hogy közben tiltjuk a hozzáférésüket. Ehhez vegyünk fel egy újabb sort az /etc/master.passwd állományba. A sor valahogy így fog kinézni: +:::::::::/sbin/nologin, amely annyit tesz, hogy importáljuk az összes bejegyzést, de a hozzájuk tartozó parancsértelmezõ a /sbin/nologin legyen. A passwd állományban tetszõleges mezõ tartalmát le tudjuk úgy cserélni, ha megadunk neki egy alapértelmezett értéket az /etc/master.passwd állományban. Vigyázzunk, hogy a +:::::::::/sbin/nologin sort az +@IT_DOLG::::::::: sor után írjuk. Ha nem így teszünk, akkor a NIS-bõl importált összes felhasználói hozzáférés a /sbin/nologin parancsértelmezõt kapja. Miután elvégeztük ezt a változtatást, minden újabb dolgozó felvétele után csupán egyetlen táblázatot kell megváltoztatnunk. Ugyanezt a taktikát követhetjük a kevésbé fontosabb szerverek esetében is, hogy ha a helyi /etc/master.passwd állományukban a korábbi +::::::::: bejegyzést valami ilyesmivel helyettesítjük: +@IT_DOLG::::::::: +@IT_UJDOLG::::::::: +:::::::::/sbin/nologin Az egyszerû munkaállomások esetében pedig ezekre a sorokra lesz szükségünk: +@IT_DOLG::::::::: +@FELHASZNALOK::::::::: +:::::::::/sbin/nologin Minden remekül üzemel egészen addig, amíg néhány múlva ismét változik a házirend: az IT tanszékre ösztöndíjasok érkeznek. Az IT ösztöndíjasai a munkaállomásokat és a kevésbé fontosabb szervereket tudják használni. Az új IT dolgozók már a központi szerverekre is bejelentkezhetnek. Így tehát létrehozunk egy új hálózati csoportot IT_OSZTONDIJAS néven, majd felvesszük ide az új IT ösztöndíjasokat, és nekilátunk végigzongorázni az összes gép összes konfigurációs állományát... Ahogy azonban egy régi mondás is tartja: A központosított tervezésben ejtett hibák teljes káoszhoz vezetnek. A NIS az ilyen helyzeteket úgy igyekszik elkerülni, hogy megengedi újabb hálózati csoportok létrehozását más hálózati csoportokból. Egyik ilyen lehetõség a szerep alapú hálózati csoportok kialakítása. Például, ha a fontosabb szerverek bejelentkezési korlátozásai számára hozzunk létre egy NAGYSRV nevû csoportot, valamint egy másik hálózati csoportot KISSRV néven a kevésbé fontosabb szerverekhez, végül MUNKA néven egy harmadik hálózati csoportot a munkaállomásokhoz. Mindegyik ilyen hálózati csoport tartalmazza azokat a csoportokat, amelyek engedélyezik a gépek elérését. A hálózati csoportok leírását tartalmazó NIS táblázat most valahogy így fog kinézni: NAGYSRV IT_DOLG IT_UJDOLG KISSRV IT_DOLG IT_UJDOLG IT_OSZTONDIJAS MUNKA IT_DOLG IT_OSZTONDIJAS FELHASZNALOK A bejelentkezési megszorítások ilyen típusú megadása viszonylag jól mûködik, hogy ha azonos korlátozások alá esõ gépek csoportjait akarjuk felírni. Bánatunk ez a kivétel, és nem a szabály. Az esetek nagy többségében ugyanis a bejelentkezésre vonatkozó korlátozásokat gépenként kell egyesével megadni. A hálózati csoportok gépfüggõ megadása tehát az iménti házirendhez társuló igények kielégítésének egyik módja. Ebben a forgatókönyvben az /etc/master.passwd állomány minden számítógépen két +-os sorral kezdõdik. Közülük az elsõ a gépen engedélyezett hozzáféréseket tartalmazó hálózati csoportra vonatkozik, a második pedig az összes többi hozzáféréshez az /sbin/nologin parancsértelmezõt kapcsolja hozzá. Itt jó ötlet, ha a gép nevének VÉGIG-NAGYBETÛS változatát adjuk meg a hozzátartozó hálózati csoport nevének: +@GÉPNÉV::::::::: +:::::::::/sbin/nologin Miután elvégeztük ezt a feladatot minden egyes gépen, az /etc/master.passwd állomány helyi változatait soha többé nem kell módosítanunk. Az összes többi változtatást a NIS táblázaton keresztül tudjuk keresztül vinni. Íme a felvázolt forgatókönyvhöz tartozó hálózati csoportok kiépítésének egyik lehetséges változata, egy-két finomsággal kiegészítve: # Elõször a felhasználók csoportjait adjuk meg: IT_DOLG (,alpha,proba-tartomany) (,beta,proba-tartomany) IT_UJDOLG (,charlie,proba-tartomany) (,delta,proba-tartomany) TANSZ1 (,echo,proba-tartomany) (,foxtrott,proba-tartomany) TANSZ2 (,golf,proba-taromany) (,hotel,proba-tartomany) TANSZ3 (,india,proba-taromany) (,juliet,proba-tartomany) IT_OSZTONDIJAS (,kilo,proba-tartomany) (,lima,proba-tartomany) D_OSZTONDIJAS (,able,proba-tartomany) (,baker,proba-tartomany) # # Most pedig hozzunk létre csoportokat szerepek szerint: FELHASZNALOK TANSZ1 TANSZ2 TANSZ3 NAGYSRV IT_DOLG IT_UJDOLG KISSRV IT_DOLG IT_UJDOLG IT_OSZTONDIJAS MUNKA IT_DOLG IT_OSZTONDIJAS FELHASZNALOK # # Következzenek a speciális feladatokhoz tartozó csoportok: # Az echo és a golf tudja elérni a vírusvédelemért felelõs gépet: VEDELEM IT_DOLG (,echo,proba-tartomany) (,golf,proba-tartomany) # # Gép alapú hálózati csoportok # A fõ szervereink: HABORU NAGYSRV EHSEG NAGYSRV # Az india nevû felhasználó hozzá szeretné ehhez férni: SZENNYEZES NAGYSRV (,india,proba-tartomany) # # Ez valóban fontos és komolyan szabályoznunk kell: HALAL IT_DOLG # # Az elõbb említett vírusvédelmi gép: EGY VEDELEM # # Egyetlen felhasználóra korlátozzuk le ezt a gépet: KETTO (,hotel,proba-tartomany) # [...és itt folytatódik a többi csoporttal] Ha a felhasználói hozzáféréseinket valamilyen adatbázisban tároljuk, akkor a táblázat elsõ részét akár az adatbázis lekérdezésein keresztül is elõ tudjuk állítani. Ezzel a módszerrel az új felhasználók automatikusan hozzáférnek a gépekhez. Legyünk viszont óvatosak: nem mindig javasolt gépeken alapuló hálózati csoportokat készíteni. Ha a hallgatói laborokba egyszerre több tucat vagy akár több száz azonos konfigurációjú gépet telepítünk, akkor a gép alapú csoportok helyett inkább szerep alapú csoportokat építsünk fel, mivel így a NIS táblázatok méretét egy elfogadható méreten tudjuk tartani. Amit feltétlenül észben kell tartanunk Még mindig akad néhány olyan dolog, amit másképpen kell csinálnunk azután, hogy most már NIS környezetben vagyunk. Amikor egy új felhasználót akarunk felvenni a laborba, akkor csak a központi NIS szerverre kell felvennünk, és újra kell generáltatnunk a NIS táblázatokat. Ha ezt elfelejtjük megtenni, akkor az új felhasználó a központi NIS szerveren kívül sehova sem lesz képes bejelentkezni. Például, ha fel akarjuk venni a jsmith nevû felhasználót a laborba, akkor ezt kell tennünk: &prompt.root; pw useradd jsmith &prompt.root; cd /var/yp &prompt.root; make proba-tartomany Vagy a pw useradd jsmith parancs helyett az adduser jsmith parancsot is használhatjuk. A rendszergazdai szintû hozzáféréseket ne tároljuk a NIS táblázatokban. Olyan gépekre egyáltalán ne is küldjünk olyan karbantartáshoz használt hozzáféréseket, amelynek a felhasználói hivatalosan nem is férhetnének hozzájuk. A központi NIS szervert és az alárendelt szervereket óvjuk minél jobban, és igyekezzünk minimalizálni a kieséseiket. Ha valaki feltöri vagy egyszerûen csak kikapcsolja ezeket a gépeket, akkor ezzel lényegében mindenkit megakadályoz abban, hogy be tudjon jelentkezni a laborban. Ezek a központosított vezérlésû rendszerek legfõbb gyengeségei. Ha nem védjük kellõen a NIS szervereinket, akkor azzal nagyon ellenséget szerezhetünk magunknak! Kompatibilitás a NIS elsõ változatával A &os;-ben megtalálható ypserv szolgáltatás valamennyire képes ellátni a NIS elsõ változatát használó klienseket is. A &os; NIS implementációja csak a NIS v2 protokollt használja, azonban mivel más implementációk kompatibilisek kívánnak maradni a régebbi rendszerekkel, ismerik a v1 protokollt is. Az ilyen rendszerekhez tartozó ypbind démonok még olyankor is megpróbálnak v1-es NIS szerverekhez kötést létrehozni, amikor valójában nincs is rá szükségük (és gyakran még akkor is ilyet keresnek, amikor az üzenetükre már válaszolt egy v2-es szerver). Hozzátennénk, hogy bár az ypserver ezen változata a normál klienshívásokat képes feldolgozni, a táblázatokat már nem tudja átküldeni a v1-es klienseknek. Ebbõl következik, hogy a központi vagy alárendelt szerverek nem tudnak együttmûködni olyan NIS szerverekkel, amelyek csak a v1-es protokollt beszélik. Szerencsére ilyen szervereket manapság már alig használnak. NIS szerverek, melyek egyben NIS kliensek Óvatosan kell bánnunk az ypserv elindításával olyan többszerveres tartományokban, ahol a szerverek maguk is NIS kliensek. Alapvetõen nincs abban semmi kivetnivaló, ha a szervereket saját magukhoz kötjük ahelyett, hogy engednénk nekik a kötési kérések küldését és így egymáshoz kötnénk ezeket. Különös hibák tudnak származni olyan helyzetekben, amikor az egyik szerver leáll, miközben a többiek pedig függenek tõle. Végül is ilyenkor minden kliens szépen kivárja a szükséges idõt, aztán megpróbál más szerverekhez kötõdni, de az itt fellépõ késlekedés jelentõs mennyiségû lehet, és ez a hibajelenség ismét fennállhat, mivel elõfordulhat, hogy a szerverek megint egymáshoz kapcsolódnak. A klienst úgy tudjuk egy adott szerverhez kötni, ha az ypbind parancsot a beállítással indítjuk. Ha mindezt nem akarjuk manuálisan megtenni a NIS szerver minden egyes újraindításakor, akkor vegyük fel a következõ sorokat az /etc/rc.conf állományba: nis_client_enable="YES" # elindítjuk a klienst is nis_client_flags="-S NIS tartomány,szerver" Részletesebb lásd az &man.ypbind.8; man oldalát. A jelszavak formátuma NIS jelszavak formátuma A NIS rendszerek kiépítése során az emberek leggyakrabban a jelszavak formátumával kapcsolatban tapasztalnak nehézségeket. Ha a szerverünk DES titkosítású jelszavakat használ, akkor csak olyan klienseket fog tudni támogatni, amelyek szintén így kódolják ezeket. Például, ha a hálózaton vannak &solaris; rendszerû NIS klienseink, akkor szinte biztos, hogy DES titkosítást kell használnunk. A szerverek és a kliensek által használt formátumokat az /etc/login.conf állományba tekintve deríthetjük ki. Ha a gépek többségén a DES titkosítást látjuk, akkor a default osztálynak egy ilyen bejegyzést kell tartalmaznia: default:\ :passwd_format=des:\ :copyright=/etc/COPYRIGHT:\ [a többit most nem mutatjuk] A passwd_format tulajdonság további lehetséges értékei lehetnek a blf és az md5 (melyek rendre a Blowfish és MD5 titkosítású jelszavakat adják meg). Ha változtattunk valamit az /etc/login.conf állományban, akkor a bejelentkezési tulajdonságok adatbázisát is újra kell generálni, melyet root felhasználóként a következõ módon tehetünk meg: &prompt.root; cap_mkdb /etc/login.conf Az /etc/master.passwd állományban jelenlevõ jelszavak formátuma azonban nem frissítõdik egészen addig, amíg a felhasználók a bejelentkezési adatbázis újragenerálása után meg nem változtatják a jelszavaikat. Úgy tudjuk még biztosítani, hogy a jelszavak megfelelõ formátumban kódolódjanak, ha az /etc/auth.conf állományban megkeressük a crypt_default sort, amelyben a választható jelszóformátumok felhasználásái sorrendjét találhatjuk meg. Itt tehát mindössze annyit kell tennünk, hogy a kiszemelt formátumot a lista elejére tesszük. Például, ha a DES titkosítású jelszavakat akarunk használni, akkor ez a bejegyzés így fog kinézni: crypt_default = des blf md5 Ha a fenti lépéseket követjük az összes &os; alapú NIS szervernél és kliensnél, akkor biztosra mehetünk abban, hogy a hálózatunkon belül ugyanazt a jelszóformátumot fogják használni. Ha gondunk akadna a NIS kliensek hitelesítésével, akkor itt érdemes kezdeni a hiba felderítését. Ne felejtsük: ha egy NIS szervert egy heterogén hálózatba akarunk telepíteni, akkor valószínûleg az összes rendszeren a DES titkosítást kell választani, mivel általában ez a közös nevezõ ebben a tekintetben. Greg Sutter Írta: A hálózat automatikus beállítása (DHCP) Mi az a DHCP? Dinamikus állomáskonfigurációs protokoll DHCP internetes szoftverkonzorcium (ISC) A Dinamikus állomáskonfigurációs protokoll, avagy Dynamic Host Configuration Protocol (DHCP) annak eszközeit írja le, hogy egy rendszer miként tud csatlakozni egy hálózathoz és miként tudja azon belül megszerezni a kommunikációhoz szükséges információkat. A &os; 6.0 elõtti változatai az ISC (Internet Software Consortium, vagyis az internetes szoftverkonzorcium) által kidolgozott DHCP kliens (&man.dhclient.8;) implementációját tartalmazzák. A késõbbi verziókban pedig az OpenBSD 3.7 verziójából átvett dhclient paranccsal dolgozhatunk. Ebben a szakaszban a dhclient parancsra vonatkozó összes információ egyaránt érvényes az ISC és az OpenBSD által fejlesztett DHCP kliensekre. A DHCP szerver az ISC-tõl származik. Mivel foglalkozik ez a szakasz Ebben a szakaszban az ISC és az OpenBSD DHCP klienseinek kliens- és szerver oldali komponsenseit mutatjuk be. A kliens oldali program neve a dhclient, amely a &os; részeként érkezik, és a szerver oldali elem pedig a net/isc-dhcp3-server porton keresztül érhetõ el. A lentebb említett hivatkozások mellett a témában még a &man.dhclient.8;, &man.dhcp-options.5; és a &man.dhclient.conf.5; man adhatnak bõvebb felvilágosítást a témában. Ahogyan mûködik UDP Amikor a dhclient, vagyis a DHCP kliens elindul egy kliensgépen, akkor a hálózaton üzenetszórással próbálja meg elkérni a konfigurációjához szükséges adatokat. Alapértelmezés szerint ezek a kérések a 68-as UDP porton keresztül mennek. A szerver ezekre a 67-es UDP porton válaszol, ahol visszaad a kliensnek egy IP-címet és a hálózat használatához szükséges további információkat, mint például a hálózati maszkot, az alapértelmezett átjáró és a névfeloldásért felelõs szerverek címét. Az összes ilyen jellegû adat egy DHCP bérlet (lease) formájában érkezik meg, amely csak egy adott ideig érvényes (ezt a DHCP szerver karbantartója állítja be). Így a hálózaton a kliens nélküli IP-címeket egy idõ után automatikusan visszanyerjük. A DHCP kliensek rengeteg információt képes elkérni a szervertõl. Ezek teljes listáját a &man.dhcp-options.5; man oldalán olvashatjuk el. Használat a &os;-n belül A &os; teljes egészében tartalmazza az ISC vagy az OpenBSD DHCP kliensét, a dhclient programot (attól függõen, hogy a &os; melyik változatát használjuk). A DHCP kliensek támogatása a telepítõben és az alaprendszerben is megtalálható, és ezzel mentesülünk minden konkrét hálózati beállítás alól a DHCP szervereket alkalmazó hálózatokon. A dhclient a &os; 3.2 változata óta megtalálható a rendszerben. sysinstall DHCP használatát a sysinstall is lehetõvé teszi. Amikor egy hálózati felületet a sysinstall programon belül állítunk be, akkor a második kérdés mindig ez szokott lenni: Do you want to try DHCP configuration of the interface? (Megpróbáljuk DHCP használatával beállítani a felületet?) Ha erre igennel válaszolunk, akkor azzal lényegében a dhclient parancsot indítjuk el, és ha mindez sikerrel zárul, akkor szinte magától kitöltõdik az összes hálózati beállításunk. A DHCP használatához két dolgot kell beállítanunk a rendszerünkön: DHCP követelmények Gondoskodjunk róla, hogy a bpf eszköz része a rendszermagunknak. Ha még nem lenne benne, akkor a rendszermag beállításait tartalmazó állományba vegyük fel a device bpf sort és fordítsuk újra a rendszermagot. A rendszermagok fordításáról a ben tudhatunk meg többet. A bpf eszköz alapból megtalálható a GENERIC rendszermagokban, így ha ezt használjuk, akkor nem kell saját verziót készítenünk a DHCP használatához. Azok számára viszont, akik biztonsági szempontból aggódnak a rendszerük miatt, meg kell említenünk, hogy a bpf egyben az az eszköz, amely a csomagok lehallgatását is lehetõvé teszi (habár az ilyeneket root felhasználóként lehet csak elindítani). A bpf kell a DHCP használatához, azonban ha nagyon fontos nekünk a rendszerünk biztonsága, akkor a bpf eszközt érdemes kivennünk a rendszermagból, ha még pillanatnyilag nem használunk ilyet. Az /etc/rc.conf állományunkat az alábbiak szerint kell módosítani: ifconfig_fxp0="DHCP" Az fxp0 eszközt ne felejtsük el kicserélni arra a felületre, amelyet automatikusan akarunk beállítani. Ennek mikéntje a ban olvasható. Ha a dhclient a rendszerünkben máshol található, vagy egyszerûen csak további beállításokat akarunk átadni a dhclient parancsnak, akkor adjuk meg a következõt is (változtassuk meg igényeink szerint): dhcp_program="/sbin/dhclient" dhcp_flags="" DHCP szerver A DHCP szerver, a dhcpd a net/isc-dhcp3-server port részeként érhetõ el. Az a port tartalmazza az ISC DHCP szerverét és a hozzátartozó dokumentációt. Állományok DHCP konfigurációs állományok /etc/dhclient.conf A dhclient mûködéséhez szükség lesz egy konfigurációs állományra, aminek a neve /etc/dhclient.conf. Ez az állomány általában csak megjegyzéseket tartalmaz, mivel az alapértelmezett értékek többnyire megfelelõek. Ezt a konfigurációs állományt a &man.dhclient.conf.5; man oldal írja le. /sbin/dhclient A dhclient statikusan linkelt és az /sbin könyvtárban található. A &man.dhclient.8; man oldal tud róla részletesebb felvilágosítást adni. /sbin/dhclient-script A dhclient-script a &os;-ben levõ DHCP kliens konfigurációs szkriptje. Mûködését a &man.dhclient-script.8; man oldal írja le, de a felhasználók részérõl semmilyen módosítást nem igényel. /var/db/dhclient.leases A DHCP kliens az érvényes bérleteket tartja nyilván ezekben az állományban és naplóként használja. A &man.dhclient.leases.5; man oldal ezt valamivel bõvebben kifejti. További olvasnivalók A DHCP protokoll mûködését az RFC 2131 mutatja be. A témához kapcsolódóan itt tudunk még leírásokat találni. A DHCP szerverek telepítése és beállítása Mirõl szól ez a szakasz Ebben a szakaszban arról olvashatunk, hogy miként kell egy &os; típusú rendszert DHCP szervernek beállítani, ha az ISC (internetes szoftverkonzorcium) DHCP szerverét használjuk. Ez a szerver nem része a &os;-nek, ezért a szolgáltatás elindításához elõször fel kell raknunk a net/isc-dhcp3-server portot. A Portgyûjtemény használatára vonatkozóan a lehet segítségünkre. A DHCP szerver telepítése DHCP telepítés Ha a &os; rendszerünket DHCP szerverként akarjuk beállítani, akkor ehhez elsõként a &man.bpf.4; eszköz jelenlétét kell biztosítani a rendszermagban. Ehhez vegyük fel a device bpf sort a rendszermagunk beállításait tartalmazó állományba, majd fordítsuk újra a rendszermagot. A rendszermag lefordításáról a ben olvashatunk. A bpf eszköz a &os;-hez alapból adott GENERIC rendszermag része, ezért a DHCP használatához nem kell feltétlenül újat fordítanunk. A biztonsági szempontok miatt aggódó felhasználók részére megjegyezzük, hogy a bpf eszköz egyben a csomagok lehallgatását is lehetõvé teszi (habár az ilyen témájú programok futtatásához megfelelõ jogokra is szükség van). A bpf használata kötelezõ a DHCP mûködtetéséhez, de ha nagyon kényesek vagyunk a biztonságot illetõen, akkor minden olyan esetben, amikor nem használjuk ki ezt a lehetõséget, távolítsuk el a rendszermagból. A következõ lépésben át kell szerkesztenünk a mintaként mellékelt dhcpd.conf állományt, amelyet a net/isc-dhcp3-server port rakott fel. Ez alapértelmezés szerint a /usr/local/etc/dhcpd.conf.sample néven található meg, és mielõtt bármit is változtatnánk rajta, másoljuk le /usr/local/etc/dhcpd.conf néven. A DHCP szerver beállítása DHCP dhcpd.conf A dhcpd.conf az alhálózatokat illetve a gépeket érintõ deklarációkat tartalmazza, és talán a legkönnyebben a következõ példa alapján mutatható be: option domain-name "minta.com"; option domain-name-servers 192.168.4.100; option subnet-mask 255.255.255.0; default-lease-time 3600; max-lease-time 86400; ddns-update-style none; subnet 192.168.4.0 netmask 255.255.255.0 { range 192.168.4.129 192.168.4.254; option routers 192.168.4.1; } host mailhost { hardware ethernet 02:03:04:05:06:07; fixed-address levelezes.minta.com; } Ez a beállítás adja meg a kliensek számára az alapértelmezett keresési tartományt (search domain). A &man.resolv.conf.5; tud ezzel kapcsolatban részletesebb információkat adni. Ez a beállítás adja meg a kliensek által használt névfeloldó szerverek vesszõvel elválasztott felsorolását. A kliensekhez tartozó hálózati maszk. A kliens egy adott idõre kérhet bérleti jogot, egyébként a szerver dönt a bérlet lejárati idejérõl (másodpercekben). Ez az a maximális idõ, amennyire a szerver hajlandó bérbe adni IP-címet. A kliens ugyan hosszabb idõre is kérheti és meg is kapja, de legfeljebb csak max-lease-time másodpercig lesz érvényes. Ez a beállítás határozza meg, hogy a DHCP szervernek frissítse-e a névoldási információkat a bérlések elfogadásánál vagy visszamondásánál. Az ISC implementációjánál ez a beállítás kötelezõ. Ezzel adjuk meg milyen tartományból tudunk IP-címeket kiosztani a kliensek számára. A kezdõ címet is beleértve, innen fogunk kiutalni egyet a klienseknek. A kliensek felé elküldött alapértelmezett átjáró címe. A gép hardveres MAC-címe (így a DHCP szerver képes felismerni a kérés küldõjét). Ennek megadásával a gépek mindig ugyanazt az IP-címet kapják. Itt már megadhatunk egy hálózati nevet, mivel a bérlethez tartozó információk visszaküldése elõtt maga a DHCP szerver fogja feloldani a gép nevét. Miután befejeztük a dhcpd.conf módosítását, a DHCP szerver az /etc/rc.conf állományban tudjuk engedélyezni, vagyis tegyük bele a következõt: dhcpd_enable="YES" dhcpd_ifaces="dc0" A dc0 felület nevét helyettesítsük annak a felületnek (vagy whitespace karakterekkel elválasztott felületeknek) a nevével, amelyen keresztül a DHCP szerver várni fogja a kliensek kéréseit. Ezután a következõ parancs kiadásával indítsuk el a szervert: &prompt.root; /usr/local/etc/rc.d/isc-dhcpd.sh start Amikor a jövõben valamit változtatunk a konfigurációs állományon, akkor ezzel kapcsolatban fontos megemlíteni, hogy ha csak egy SIGHUP jelzést küldünk a dhcpd démonnak, akkor az a többi démontól eltérõen önmagában még nem eredményezi a konfigurációs adatok újraolvasását. Helyette a SIGTERM jelzéssel kell leállítani a programot, majd újraindítani a fenti paranccsal. Állományok DHCP konfigurációs állományok /usr/local/sbin/dhcpd A dhcpd statikusan linkelt és a /usr/local/sbin könyvtárban található. A porttal együtt felkerülõ &man.dhcpd.8; man oldal ad részletesebb útmutatást dhcpd használatáról. /usr/local/etc/dhcpd.conf Mielõtt a dhcpd megkezdhetné mûködését, egy konfigurációs állományra is szükségünk lesz, amely a /usr/local/etc/dhcpd.conf. Ez az állomány tartalmazza az összes olyan információt, ami kell a kliensek megfelelõ kiszolgálásához valamint a szerver mûködéséhez. Ez a konfigurációs állomány porthoz tartozó &man.dhcpd.conf.5; man oldalon kerül ismertetésre. /var/db/dhcpd.leases A DHCP szerver ebben az állományba tartja nyilván a kiadott bérleteket, egy napló formájában. A porthoz kapcsolódó &man.dhcpd.leases.5; man oldalon errõl többet is megtudhatunk. /usr/local/sbin/dhcrelay A dhcrelay állománynak olyan komolyabb környezetekben van szerepe, ahol a DHCP szerver a kliensektõl érkezõ kéréseket egy másik hálózaton található DHCP szerverhez továbbítja. Ha szükség lenne erre a lehetõségre, akkor telepítsük fel a net/isc-dhcp3-relay portot. A porthoz tartozó &man.dhcrelay.8; man oldal ennek részleteit taglalja. Chern Lee Készítette: Tom Rhodes Daniel Gerzo Névfeloldás (<acronym>DNS</acronym>) Áttekintés BIND A &os; alapértelmezés szerint a BIND (Berkeley Internet Name Domain) egyik verzióját tartalmazza, amely a névfeloldási (Domain Name System, DNS) protokoll egyik elterjedt implementációja. A DNS protokollon keresztül tudunk az IP-címekhez neveket rendelni és fordítva. Például a www.FreeBSD.org névre a &os; Projekt webszerverének IP-címét kapjuk meg, miközben a ftp.FreeBSD.org pedig a hozzátartozó FTP szerver IP-címét fogja visszaadni. Ehhez hasonlóan a fordítottja is megtörténhet, vagyis egy IP-címhez is kérhetjük a hálózati név feloldását. A névfeloldási kérések kiszolgálásához nem feltétlenül szükséges névszervert futtatni a rendszerünkön. A &os; jelen pillanatban alapból a BIND9 névszervert tartalmazza. A benne szereplõ változata több biztonsági javítást, új állományrendszeri kiosztást és automatizált &man.chroot.8; beállítást is magában foglal. névfeloldás Az interneten keresztüli névfeloldást legfelsõ szintû tartományoknak (Top Level Domain, TLD) nevezett hitelesített tövek némileg bonyolult rendszerén alapszik, valamint más egyéb olyan névszervereken, amelyek további egyéni információkat tárolnak és táraznak. A BIND fejlesztését jelenleg az Internet Software Consortium () felügyeli. Alapfogalmak A leírás megértéséhez be kell mutatnunk néhány névfeloldással kapcsolatos fogalmat. névfeloldó inverz DNS gyökérzóna Fogalom Meghatározás Közvetlen névfeloldás (forward DNS) A hálózati nevek leképezése IP-címekre. Õs (origin) Egy adott zóna állományban szereplõ tartományra vonatkozik. named, BIND, névszerver (name server) A &os;-n belüli BIND névszerver különbözõ megnevezései. Névfeloldó (resolver) Az a program a rendszerben, amelyhez a hálózaton levõ gépek a zónák adatainak elérésével kapcsolatban fordulnak. Inverz névfeloldás (reverse DNS) A rendes névfeloldás ellentéte, vagyis az IP-címek leképzése hálózati nevekre. Gyökérzóna (root zone) Az interneten található zónák hierarchiájának töve. Minden zóna ebbe a gyökérzónába esik, ahhoz hasonlóan, ahogy egy állományrendszerben az állományok a gyökérkönyvtárba. Zóna (zone) Egy különálló tartomány, altartomány vagy a névfeloldás azon része, amelyet egyazon fennhatóság alatt tartanak karban. zónák példák Példák zónákra: A . gyökérzóna. A org. egy legfelsõ szintû tartomány (TLD) a gyökérzónán belül. A minta.org. a org. TLD tartomány alatti zóna. A 1.168.192.in-addr.arpa egy olyan zóna, amelyek a 192.168.1.* IP-tartományban szereplõ összes címet jelöli. Mint láthatjuk, a hálózati nevek balról kiegészülve pontosodnak. Tehát például a minta.org. sokkal pontosabb meghatározás, mint a org., ahogy az org. magánál a gyökérzónánál jelent többet. A hálózati nevek felosztása leginkább egy állományrendszerhez hasonlítható, például a /dev könyvtár a gyökéren belül található, és így tovább. Miért érdemes névszervert futtatni A névszerverek általában két alakban jelennek meg. Egyikük a hitelesített névszerver, a másikuk a gyorsítótárazó névszerver. Egy hitelesített névszerverre akkor van szükségünk, ha: a világ többi része felé akarunk hiteles névfeloldási információkat szolgáltatni; regisztráltunk egy tartományt (például minta.org) és az alatta levõ hálózati nevekhez is szeretnénk IP-címeket rendeltetni; a IP-címtartományunkban szükség van inverz névfeloldási bejegyzésekre (amely IP-címbõl ad meg hálózati nevet) is; a kérések teljesítéséhez egy tartalék avagy második, alárendelt (slave) névszerver kell. A gyorsítótárazó névszerverre akkor van szükségünk, ha: egy helyi névfeloldó szerver felhasználásával fel akarjuk gyorsítani az egyébként a külsõ névszerver felé irányuló kérések kiszolgálását. Amikor valaki lekérdezi a www.FreeBSD.org címét, akkor a névfeloldó elõször általában a kapcsolatot rendelkezésre bocsátó internet-szolgáltató névszerverét kérdezi meg és onnan kapja meg a választ. Egy helyi, gyorsítótárazó névszerver használata esetén azonban egy ilyen kérést csak egyszer kell kiadni a külsõ névszervernek. Ezután már minden további ilyen kérés el sem hagyja a belsõ hálózatunkat, mivel a válasz szerepel a gyorsítótárban. Ahogyan mûködik &os; alatt a BIND démon nyilvánvaló okokból named néven érhetõ el. Állomány Leírás &man.named.8; A BIND démon. &man.rndc.8; A névszervert vezérlõ segédprogram. /etc/namedb A BIND által kezelt zónák adatait tároló könyvtár. /etc/namedb/named.conf A démon konfigurációs állománya. Attól függõen, hogy miként állítjuk be az adott zónát a szerveren, a hozzátartozó állományok a /etc/namedb könyvtáron belül a master, slave vagy dynamic alkönyvtárban foglalnak helyet. Az itt tárolt állományokban levõ névfeloldási információk alapján válaszol a névszerver a felé intézett kérésekre. A BIND elindítása BIND elindítás Mivel a BIND alapból elérhetõ a rendszerben, viszonylag könnyen be tudjuk állítani. A named alapértelmezett beállítása szerint egy &man.chroot.8; környezetben futó egyszerû névfeloldást végzõ szerver. Ezzel a beállítással a következõ parancson keresztül tudjuk elindítani: &prompt.root; /etc/rc.d/named forcestart Ha engedélyezni akarjuk a named démont minden egyes rendszerindításkor, tegyük a következõ sort az /etc/rc.conf állományba: named_enable="YES" Értelemszerûen az /etc/namedb/named.conf tele van olyan beállítási lehetõségekkel, amelyek meghaladják ennek a leírásnak a kereteit. Ha viszont kíváncsiak vagyunk a &os;-ben a named indításához használt beállításokra, akkor az /etc/defaults/rc.conf állományban nézzük meg named_* változókat és olvassuk át az &man.rc.conf.5; man oldalt. Emellett még a t is hasznos lehet elolvasni. A konfigurációs állományok BIND konfigurációs állományok A named beállításait tartalmazó állományok pillanatnyilag az /etc/namedb könyvtárban találhatóak és hacsak nem egy egyszerû névfeloldóra tartunk igényt, akkor a használata elõtt módosítanunk is kell. Itt ejtjük meg a beállítások nagy részét. A <command>make-localhost</command> használata Ha a helyi gépen egy központi zónát akarunk beállítani, akkor lépjünk be az /etc/namedb könyvtárba és futtassuk le a következõ parancsot: &prompt.root; sh make-localhost Ha nem történt semmilyen hiba, akkor a master alkönyvtárban most meg kell jelennie egy új állománynak. A helyi tartománynévhez tartozó állomány a localhost.rev, valamint IPv6 környezetben a localhost-v6.rev. Alapértelmezett konfigurációs állományként a named.conf ehhez tartalmaz minden szükséges információt. <filename>/etc/namedb/named.conf</filename> // $FreeBSD$ // // Részletesebb leírást a named.conf(5) és named(8) man oldalakon, valamint // a /usr/share/doc/bind9 könyvtárban találhatunk. // // Ha egy hitelesített szervert akarunk beállítani, akkor igyekezzünk // a névfeloldás összes finom részletével pontosan tisztában lenni. // Ugyanis még a legkisebb hibákkal is egyrészt elvághatunk gépeket az // internet-lérésétõl, vagy másrészt felesleges forgalmat tudunk // generálni // options { directory "/etc/namedb"; pid-file "/var/run/named/pid"; dump-file "/var/dump/named_dump.db"; statistics-file "/var/stats/named.stats"; // Ha a named démont csak helyi névfeloldóként használjuk, akkor ez // egy biztonságos alapbeállítás. Ha viszont a named démon az egész // hálózatunkat is kiszolgálja, akkor ezt a beállítást tegyük // megjegyzésbe, vagy adjunk meg egy rendes IP-címet, esetleg // töröljük ki. listen-on { 127.0.0.1; }; // Ha rendszerünkön engedélyezett az IPv6 használata, akkor a helyi // névfeloldó használatához ezt a sort vegyük ki a megjegyzésbõl. // A hálózatunk többi részérõl pedig úgy lehet elérni, ha itt megadunk // egy IPv6 címet, vagy az "any" kulcsszót. // listen-on-v6 { ::1; }; // A "forwarders" blokk mellett a következõ sorral megkérhetjük a // névszervert, hogy önmagától soha nem kezdeményezzen kéréseket, // hanem mindig az iménti helyen megjelölt szerverekhez irányítsa // ezeket: // // forward only; // Ha a szolgáltatónk névszervert is elérhetõvé tett számunkra, akkor // itt adjuk meg annak az IP-címét és engedélyezzük az alábbi sort. // Ezzel egyben kihasználjuk a gyorsítótárat is, így mérsékeljük az // internet felé mozgó névfeloldásokat. /* forwarders { 127.0.0.1; }; */ Ahogy arról a megjegyzésekben is szó esik, úgy tudjuk aktiválni a gyorsítótárat, ha megadjuk a forwarders beállítást. Normális körülmények között a névszerver az interneten az egyes névszervereket rekurzívan fogja keresni egészen addig, amíg meg nem találja a keresett választ. Az iménti beállítás engedélyezésével azonban elõször a szolgáltató névszerverét (vagy az általa kijelölt névszervert) fogjuk megkérdezni, a saját gyorsítótárából. Ha a szolgáltató kérdéses névszervere egy gyakran használt, gyors névszerver, akkor ezt érdemes bekapcsolnunk. Itt a 127.0.0.1 megadása nem mûködik. Mindenképpen írjuk át a szolgáltatónk névszerverének IP-címére. /* * Ha köztünk és az elérni kívánt névszerverek között tûzfal * is található, akkor az alábbi "query-source" direktívát is * engedélyeznünk kell. A BIND korábbi változatait mindig az * 53-as porton keresztül küldték el a kéréseiket, de BIND * nyolcadik verziójától kezdve alapértelmezés szerint * erre a feladatra már egy véletlenszerûen választott, nem * privilegizált UDP portot használnak. */ // query-source address * port 53; }; // Ha engedélyezzük a helyi névszervert, akkor az /etc/resolv.conf // állományban elsõ helyen megadni a 127.0.0.1 címet. Sõt, az // /etc/rc.conf állományból se felejtsük ki. zone "." { type hint; file "named.root"; }; zone "0.0.127.IN-ADDR.ARPA" { type master; file "master/localhost.rev"; }; // RFC 3152 zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA" { type master; file "master/localhost-v6.rev"; }; // FONTOS: Ne használjuk ezeket az IP-címeket, mert nem valódiak, // csupán illusztrációs és dokumentációs célokból adtuk meg! // // Az alárendelt zónák beállításaira vonatkozó bejegyzések. Érdemes // ilyet beállítani legalább ahhoz a zónához, amelyhez a tartományunk is // tartozik. Az elsõdleges zónához tartozó IP-címet érdeklõdjük meg // az illetékes hálózati rendszergazdától. // // Soha ne felejtsünk el megadni zónát az inverz kereséshez // IN-ADDR.ARPA)! (A neve a IP-cím tagjainak fordított sorrendjébõl // származik, amelyhez hozzátoldunk még egy ".IN-ADDR.ARPA" részt.) // // Mielõtt nekilátnánk egy elsõdleges zóna beállításának, gondoljuk // végig, hogy tényleg a megfelelõ szinten ismerjük a névfeloldás és // a BIND mûködését. Gyakran ugyanis egyáltalán nem nyilvánvaló // csapdákba tudunk esni. Egy alárendelt zóna beállítása sokkal // egyszerûbb feladat. // // FONTOS: Ne kövessük vakon a most következõ példát :-) Helyette inkább // valódi neveket és címeket adjunk meg. /* Példa központi zónára zone "minta.net" { type master; file "master/minta.net"; }; */ /* Példa dinamikus zónára key "mintaorgkulcs" { algorithm hmac-md5; secret "sf87HJqjkqh8ac87a02lla=="; }; zone "minta.org" { type master; allow-update { key "mintaorgkulcs"; }; file "dynamic/minta.org"; }; */ /* Példa közvetlen és inverz alárendelt zónákra zone "minta.com" { type slave; file "slave/minta.com"; masters { 192.168.1.1; }; }; zone "1.168.192.in-addr.arpa" { type slave; file "slave/1.168.192.in-addr.arpa"; masters { 192.168.1.1; }; }; */ A named.conf állományban tehát így adhatunk meg közvetlen és inverz alárendelt zónákat. Minden egyes újabb kiszolgált zónához az egy új bejegyzést kell felvenni a named.conf állományban. Például a minta.org címhez tartozó legegyszerûbb ilyen bejegyzés így néz ki: zone "minta.org" { type master; file "master/minta.org"; }; Ez egy központi zóna, ahogy arról a mezõ, vagyis a típusa is árulkodik. Továbbá a mezõben láthatjuk, hogy a hozzátartozó információkat az /etc/namedb/master/minta.org állományban tárolja. zone "minta.org" { type slave; file "slave/minta.org"; }; Az alárendelt esetben a zónához tartozó információkat a zóna központi szerverétõl kapjuk meg és megadott állományban mentjük el. Ha valamiért a központi szerver leáll vagy nem érhetõ el, akkor az alárendelt szerver az átküldött zóna információk alapján képes helyette kiszolgálni a kéréseket. A zóna állományok BIND zóna állományok A minta.org címhez tartozó példa központi zóna állomány (amely az /etc/namedb/master/néven.org érhetõ el) tartalma az alábbi: $TTL 3600 ; 1 óra minta.org. IN SOA ns1.minta.org. admin.minta.org. ( 2006051501 ; sorozatszám 10800 ; frissítés 3600 ; ismétlés 604800 ; lejárat 86400 ; minimális TTL ) ; névszerverek IN NS ns1.minta.org. IN NS ns2.minta.org. ; MX rekordok IN MX 10 mx.minta.org. IN MX 20 levelezes.minta.org. IN A 192.168.1.1 ; a gépek nevei localhost IN A 127.0.0.1 ns1 IN A 192.168.1.2 ns2 IN A 192.168.1.3 mx IN A 192.168.1.4 levelezes IN A 192.168.1.5 ; álnevek www IN CNAME @ A .-ra végzõdõ hálózati nevek abszolút nevek, míg minden más . nélküli név az õsére vezehetõ vissza (tehát relatív). Például a www a www.õs. A kitalált zóna állományunkban itt most az õs a minta.org, így a www névbõl a www.minta.org név keletkezik. A zóna állományok felépítése a következõ: rekordnév IN rekordtípus érték névfeloldás rekordok A névfeloldásban leggyakrabban alkalmazott rekordok típusai: SOA a zóna fennhatóságának kezdete NS egy hitelesített névszerver A egy gép címe CNAME egy álnév kanonikus neve MX levélváltó PTR mutató a tartománynévre (az inverz feloldás használja) minta.org. IN SOA ns1.minta.org. admin.minta.org. ( 2006051501 ; sorozatszám 10800 ; 3 óránként frissítsünk 3600 ; 1 óra után próbálkozzunk újra 604800 ; 1 hét után jár le 86400 ) ; a minimális TTL 1 nap minta.org. a tartomány neve, amely egyben a zóna õse ns1.minta.org. a zóna elsõdleges/hitelesített névszervere admin.minta.org. a zónáért felelõs személy neve, akinek az e-mail címét a @ behelyettesítésével kapjuk meg. (Tehát a admin@example.org címbõl admin.example.org lesz.) 2006051501 az állomány sorozatszáma. Ezt a zóna állomány módosításakor mindig növelnünk kell. Manapság a rendszergazdák a sorozatszámot ééééhhnnvv alakban adják meg. A 2006051501 tehát azt jelenti, hogy az állományt 2006. május 15-én módosították utoljára, és a 01 pedig arra utal, hogy aznap elõször. A sorozatszám megadása fontos az alárendelt névszerverek számára, mivel így tudják megállapítani, hogy a zóna mikor változott utoljára. IN NS ns1.minta.org. Ez egy NS bejegyzés. A zónához tartozó minden hitelesített névszervernek lennie kell legalább egy ilyen bejegyzésének. localhost IN A 127.0.0.1 ns1 IN A 192.168.1.2 ns2 IN A 192.168.1.3 mx IN A 192.168.1.4 levelezes IN A 192.168.1.5 Az A rekord egy gép nevét adja meg. Ahogy a fenti példából is kiderül, az ns1.minta.org név a 192.168.1.2 címre képzõdik le. IN A 192.168.1.1 Ez a sor 192.168.1.1 címet rendeli az aktuális õshöz, amely jelen esetünkben az example.org. www IN CNAME @ A kanonikus neveket tároló rekordokat általában egy gép álneveihez használjuk. Ebben a példában a www a fõgép egyik álneve, amely itt a minta.org (192.168.1.1) tartomány. A CNAME rekordok tehát álnevek megadására használhatóak, vagy egyetlen állománynév körkörös rendszerû (round robin típusú) feloldására több gép között. MX rekord IN MX 10 levelezes.minta.org. Az MX rekord adja meg, hogy milyen levelezõ szerverek felelõsek a zónába érkezõ levelek fogadásáért. A levelezes.minta.org a levelezõ szerver hálózati neve, ahol a 10 az adott levelezõ szerver prioritása. Több levelezõ szerver is megadható 10-es, 20-as stb. prioritásokkal. A minta.org tartományon belül elõször mindig a legnagyobb MX prioritással rendelkezõ levelezõ szervernek próbáljuk meg továbbítani a leveleket (a legkisebb prioritási értékkel rendelkezõ rekord), majd ezután a második legnagyobbnak stb. egészen addig, amíg a levelet tovább nem küldtük. Az in-addr.arpa zóna állományok (inverz DNS) esetén ugyanez a felépítés, kivéve, hogy a PTR típusú bejegyzések szerepelnek az A és CNAME helyett. $TTL 3600 1.168.192.in-addr.arpa. IN SOA ns1.minta.org. admin.minta.org. ( 2006051501 ; sorozatszám 10800 ; frissítés 3600 ; ismétlés 604800 ; lejárat 3600 ) ; minimum IN NS ns1.minta.org. IN NS ns2.minta.org. 1 IN PTR minta.org. 2 IN PTR ns1.minta.org. 3 IN PTR ns2.minta.org. 4 IN PTR mx.minta.org. 5 IN PTR levelezes.minta.org. Ez az állomány írja le tehát a kitalált tartományunkon belül az IP-címek és hálózati nevek összerendelését. A gyorsítótárazó névszerver BIND gyorsítótárazó névszerver A gyorsítótárazó névszerver az a névszerver, amelyik egyik zónában sem hitelesített. Egyszerûen csak öncélú kéréseket küld, és a kapott válaszokat megjegyzi. A beállításához mindössze annyit kell tennünk, hogy az eddigiekhez hasonlóan, de zónák nélkül beállítunk egy névszervert. Biztonság Habár a névfeloldás szempontjából a BIND a legelterjedtebb, a biztonságosságával azért akadnak gondok. Gyakran találnak benne potenciális és kihasználható biztonsági réseket. A &os; azonban a named démont automatikusan egy &man.chroot.8; környezetbe helyezi. Emellett még léteznek további más védelmi mechanizmusok is, amelyek segítségével el tudjuk kerülni a névfeloldást célzó esetleges támadásokat. Sosem árt olvasgatni a CERT által kiadott biztonsági figyelmeztetéseket és feliratkozni a &a.security-notifications; címére, hogy folyamatosan értesüljünk az interneten és a &os;-ben talált különbözõ biztonsági hibákról. Ha valamilyen gondunk támadna, akkor esetleg próbálkozzunk meg a forrásaink frissítésével és a named újrafordításával. Egyéb olvasnivalók A BIND/named man oldalai: &man.rndc.8; &man.named.8; &man.named.conf.5; Az ISC BIND hivatalos honlapja (angolul) Az ISC BIND hivatalos fóruma (angolul) A BIND GYIK (angolul) O'Reilly DNS and BIND 5th Edition RFC1034 - Domain Names - Concepts and Facilities RFC1035 - Domain Names - Implementation and Specification Murray Stokely Készítette: Az Apache webszerver webszerverek beállítása Apache Áttekintés A &os; szolgálja ki a legforgalmasabb honlapok nagy részét szerte a világban. A mögöttük álló webszerverek általában az Apache webszervert alkalmazzák. Az Apache használatához szükséges csomagok megtalálhatóak a &os; telepítõlemezén is. Ha a &os; elsõ telepítésekor még nem telepítettük volna az Apache szerverét, akkor a www/apache13 vagy www/apache12 portból tudjuk feltenni. Az Apache szervert sikeres telepítését követõen be kell állítanunk. Ebben a szakaszban az Apache webszerver 1.3.X változatát mutatjuk be, mivel ezt használják a legtöbben &os; alatt. Az Apache 2.X rengeteg új technológiát vezetett be, de ezekkel itt most nem foglalkozunk. Az Apache 2.X változatával kapcsolatban keressük fel a oldalt. Beállítás Apache konfigurációs állományok Az Apache webszerver konfigurációs állománya &os; alatt /usr/local/etc/apache/httpd.conf néven található. Ez az állomány egy szokványos &unix;-os szöveges konfigurációs állomány, ahol a megjegyzéseket egy # karakterrel vezetjük be. Az itt használható összes lehetséges beállítási lehetõség átfogó ismertetése meghaladná az egész kézikönyv határait, ezért most csak a leggyakrabban módosított direktívákat fogjuk ismertetni. ServerRoot "/usr/local" Ez adja meg az Apache számára az alapértelmezett könyvtárat. A binárisai ezen belül a bin és sbin alkönyvtárakban, a konfigurációs állományai pedig az etc/apache könyvtárban tárolódnak. ServerAdmin saját@címünk.az.interneten Erre a címre küldhetik nekünk a szerverrel kapcsolatos hibákat. Ez a cím egyes szerver által generált oldalakon jelenik meg, például hibák esetében. ServerName www.minta.com A ServerName segítségével meg tudjuk adni, hogy milyen nevet küldjön vissza a szerver a klienseknek olyankor, ha az nem egyezne meg a jelenlegivel (vagyis a www nevet használjuk a gépünk valódi neve helyett). DocumentRoot "/usr/local/www/data" A DocumentRoot adja meg azt a könyvtárat, ahonnan kiszolgáljuk a dokumentumokat. Alapértelmezés szerint az összes kérés erre a könyvtárra fog vonatkozni, de a szimbolikus linkek és az álnevek akár más helyekre is mutathatnak. A változtatások végrehajtása elõtt mindig is jó ötlet biztonsági másolatot készíteni az Apache konfigurációs állományairól. Ahogy sikerült összerakni egy számunkra megfelelõ konfigurációt, készen is állunk az Apache futtatására. Az <application>Apache</application> futtatása Apache indítása és leállítása A többi hálózati szervertõl eltérõen az Apache nem az inetd szuperszerverbõl fut. A kliensektõl érkezõ HTTP kérések minél gyorsabb kiszolgálásának érdekében úgy állítottuk be, hogy önállóan fusson. Ehhez egy szkriptet is mellékeltünk, amellyel igyekeztünk a lehetõ legjobban leegyszerûsíteni a szerver indítását, leállítását és újraindítását. Az Apache elsõ indításához adjuk ki a következõ parancsot: &prompt.root; /usr/local/sbin/apachectl start Így pedig a szervert bármikor leállíthatjuk: &prompt.root; /usr/local/sbin/apachectl stop Ha valamilyen okból megváltoztattuk volna a szerver beállításait, akkor ezen a módon tudjuk újraindítani: &prompt.root; /usr/local/sbin/apachectl restart Ha a jelenleg megnyitott kapcsolatok felbontása nélkül akarjuk újraindítani az Apache szervert, akkor ezt írjuk be: &prompt.root; /usr/local/sbin/apachectl graceful Mindezekrõl az &man.apachectl.8; man oldalon találunk bõvebb leírást. Amennyiben szükségünk lenne az Apache elindítására a rendszer indításakor, akkor a következõ sort vegyünk fel az /etc/rc.conf állományba: apache_enable="YES" Az Apache 2.2 esetében: apache22_enable="YES" Amikor az Apache httpd nevû programjának szeretnénk további paranccsori paramétereket átadni a rendszer indítása során, akkor ezeket így tudjuk megadni az rc.conf állományban: apache_flags="" Most, miután a webszerverünk mûködik, a böngészõnkkel mindezt ellenõrizni is tudjuk a http://localhost/ cím beírásával. Ilyenkor az alapértelmezés szerinti /usr/local/www/data/index.html állomány tartalmát láthatjuk. Virtuális nevek Az Apache a virtuális nevek használatának két különbözõ módját ismeri. Ezek közül az elsõ módszer a név alapú virtualizáció (Name-based Virtual Hosting). Ilyenkor a kliens HTTP/1.1 fejlécébõl próbálja meg a szerver megállapítani a hivatkozási nevet. Segítségével több tartomány is osztozhat egyetlen IP-címen. Az Apache név alapú virtualizációjának beállításához az alábbi beállítást kell hozzátennünk a httpd.conf állományhoz: NameVirtualHost * Ha a webszerverünk neve www.tartomany.hu, és hozzá egy www.valamilyenmasiktartomany.hu virtuális nevet akarunk megadni, akkor azt a következõképpen tehetjük meg a httpd.conf állományon belül: <VirtualHost *> ServerName www.tartomany.hu DocumentRoot /www/tartomany.hu </VirtualHost> <VirtualHost *> ServerName www.valamilyenmasiktartomany.hu DocumentRoot /www/valamilyenmasiktartomany.hu </VirtualHost> A címek és elérési utak helyére helyettesítsük be a használni kívánt címeket és elérési utakat. A virtuális nevek beállításának további részleteivel kapcsolatosan keressük fel az Apache hivatalos dokumentációját a címen (angolul). Apache-modulok Apache modulok Az alap szerver képességeinek kiegészítéséhez több különbözõ Apache modul áll rendelkezésünkre. A &os; Portgyûjteménye az Apache telepítése mellett lehetõséget ad a népszerûbb bõvítményeinek telepítésére is. mod_ssl webszerverek biztonság SSL titkosítás A mod_ssl modul az OpenSSL könyvtár használatával valósít meg erõs titkosítást a biztonságos socket réteg második, illetve harmadik verziójával (Secure Sockets Layer, SSL v2/v3) és a biztonságos szállítási rétegbeli (Transport Layer Security v1) protokoll segítségével. Ez a modul mindent biztosít ahhoz, hogy a megfelelõ hatóságok által aláírt tanúsítványokat tudjunk kérni, és ezáltal egy védett webszervert futtassunk &os;-n. Ha még nem telepítettünk volna fel az Apache szervert, akkor a www/apache13-modssl porton keresztül a mod_ssl modullal együtt is fel tudjuk rakni az Apache 1.3.X változatát. Az SSL támogatása pedig már az Apache 2.X www/apache22 porton keresztül elérhetõ változataiban alapértelmezés szerint engedélyezett. Kapcsolódás nyelvekhez Mindegyik nagyobb szkriptnyelvhez létezik egy külön Apache-modul, amelyek segítségével komplett Apache-modulokat tudunk készíteni az adott nyelven. Gyakran a dinamikus honlapok is így próbálják a szerverbe épített belsõ értelmezõn keresztül a külsõ értelmezõ indításából és benne a szkriptek lefuttatásából fakadó költségeket megspórolni, ahogy errõl a következõ szakaszokban olvashatunk. Dinamikus honlapok webszerverek dinamikus Az utóbbi évtizedben egyre több vállalkozás fordult az internet felé bevételeik és részesedéseinek növelésének reményében, amivel egyre jobban megnõtt az igény a dinamikus honlapokra is. Miközben bizonyos cégek, mint például a µsoft;, a saját fejlesztésû termékeikbe építettek be ehhez támogatást, addig a nyílt forrásokkal foglalkozó közösség sem maradt tétlen és felvette a kesztyût. A dinamikus tartalom létrehozásához többek közt Django, Ruby on Rails, a mod_perl és a mod_php modulok használhatóak. Django Python Django A Django egy BSD típusú licensszel rendelkezõ keretrendszer, amelynek használatával nagy teljesítményû és elegáns webes alkalmazásokat tudunk gyorsan kifejleszteni. Tartalmaz egy objektum-relációs leképezõt, így az adattípusokat Python-objektumokként tudjuk leírni, és ezekhez az objektumokhoz egy sokrétû, dinamikus adatbázis hozzáférést nyújtó alkalmazásfejlesztõi felületet, így a fejlesztõknek egyetlen SQL utasítást sem kell megírniuk. Találhatunk még benne továbbá egy bõvíthetõ sablonrendszert, amelynek köszönhetõen az alkalmazás belsõ mûködése elválasztható a HTML-beli megjelenésétõl. A Django mûködéséhez a mod_python modulra, az Apache szerverre és egy tetszõlegesen választott SQL alapú adatbázisrendszerre van szükség. A hozzátartozó &os; port mindezeket automatikusan telepíti a megadott beállítások szerint. A Django telepítése az Apache, mod_python3 és a PostgreSQL használatával &prompt.root; cd /usr/ports/www/py-django; make all install clean -DWITH_MOD_PYTHON3 -DWITH_POSTGRESQL Miután a Django és a hozzá szükséges komponensek felkerültek rendszerünkre, hozzunk létre egy könyvtárat a leendõ Django projektünknek és állítsuk be az Apache szervert, hogy az oldalunk belül a megadott linkekre a saját alkalmazásunkat hívja meg a beágyazott Python-értelmezõn keresztül. Az Apache beállítása a Django és mod_python használatához A következõ sort kell hozzátennünk a httpd.conf állományhoz, hogy az Apache bizonyos linkeket a webes alkalmazás felé irányítson át: <Location "/"> SetHandler python-program PythonPath "['/a/django/csomagok/helye/'] + sys.path" PythonHandler django.core.handlers.modpython SetEnv DJANGO_SETTINGS_MODULE azoldalam.beallitasai PythonAutoReload On PythonDebug On </Location> Ruby on Rails Ruby on Rails A Ruby on Rails egy olyan másik nyílt forráskódú keretrendszer, amivel lényegében egy teljes fejlesztõi készletet kapunk és amelyet kifejezetten arra élezték ki, hogy segítségével a webfejlesztõk sokkal gyorsabban tudjanak haladni és a komolyabb alkalmazások gyorsabb elkészítése se okozzon nekik gondot. A Portrgyûjteménybõl pillanatok alatt telepíthetõ. &prompt.root; cd /usr/ports/www/rubygem-rails; make all install clean mod_perl mod_perl Perl Az Apache és Perl egyesítésén fáradozó projekt a Perl programozási nyelv és az Apache webszerver erejének összehangolásán dolgozik. A mod_perl modulon keresztül Perlben vagyunk képesek modulokat készíteni az Apache szerverhez. Ráadásul a szerverben egy belsõ állandó értelmezõ is található hozzá, ezzel igyekeznek megspórolni a külsõ értelmezõ és a Perl indításából keletkezõ többletköltségeket. A mod_perl több különbözõ módon állítható munkába. A mod_perl használatához nem szabad elfelejtenünk, hogy a mod_perl 1.0-ás verziója csak az Apache 1.3 változatával mûködik, és a mod_perl 2.0-ás változata pedig csak az Apache 2.X változataival. A mod_perl 1.0 a www/mod_perl portból telepíthetõ, valamint a statikusan beépített változata a www/apache13-modperl portban található. A mod_perl 2.0 a www/mod_perl2 portból rakható fel. Tom Rhodes Írta: mod_php mod_php PHP A PHP, vagy másik nevén PHP, a hipertext feldolgozó egy általános célú szkriptnyelv, amelyet kifejezetten honlapok fejlesztéséhez hoztak létre. A szabványos HTML ágyazható nyelv felépítésében a C, &java; és Perl nyelveket ötvözi annak elérése érdekében, hogy ezzel segítse a fejlesztõket a dinamikusan generált oldalak minél gyorsabb megírásában. A PHP5 támogatását úgy tudjuk hozzáadni az Apache webszerverhez, ha telepítjük a lang/php5 portot. Ha a lang/php5 portot most telepítjük elõször, akkor a vele kapcsolatos beállításokat tartalmazó OPTIONS menü automatikusan megjelenik. Ha ezzel nem találkoznánk, mert például valamikor korábban már felraktuk volna a lang/php5 portot, akkor a port könyvtárában következõ parancs kiadásával tudjuk újra visszahozni: &prompt.root; make config A beállítások között jelöljük be az APACHE opciót, amelynek eredményeképpen létrejön az Apache webszerverhez használható mod_php5 betölthetõ modul. A PHP4 modult még ma is rengeteg szerver használja több különbözõ okból (például kompatibilitási problémák vagy a már korábban kiadott tartalom miatt). Ha tehát a mod_php5 helyett inkább a mod_php4 modulra lenne szükségünk, akkor a lang/php4 portot használjuk. A lang/php4 portnál is megtalálhatjuk a lang/php5 fordítási idejû beállításainak nagy részét. Az iméntiek révén települnek és beállítódnak a dinamikus PHP alkalmazások támogatásához szükséges mouldok. Az /usr/local/etc/apache/httpd.conf állományban ellenõrizni is tudjuk, hogy az alábbi részek megjelentek-e: LoadModule php5_module libexec/apache/libphp5.so AddModule mod_php5.c <IfModule mod_php5.c> DirectoryIndex index.php index.html </IfModule> <IfModule mod_php5.c> AddType application/x-httpd-php .php AddType application/x-httpd-php-source .phps </IfModule> Ahogy befejezõdött a mûvelet, a PHP modul betöltéséhez mindösszesen az apachectl paranccsal kell óvatosan újraindítanunk a webszervert: &prompt.root; apachectl graceful A PHP jövõbeni frissítéseihez már nem lesz szükségünk a make config parancsra, mivel a korábban kiválasztott OPTIONS menün belüli beállítasainkat a &os; Portgyûjteményéhez tartozó keretrendszer automatikusan elmenti. A PHP &os;-ben megtalálható támogatása kifejezetten moduláris, ezért az alap telepítése igencsak korlátozott. A további elemek hozzáadásához a lang/php5-extensions portot tudjuk használni. A port egy menüvezérelt felületet nyújt a PHP különbözõ bõvítményeinek telepítéséhez. Az egyes bõvítményeket azonban a megfelelõ portok használatával is fel tudjuk rakni. Például PHP5 modulhoz úgy tudunk támogatást adni a MySQL adatbázis szerverhez, ha feltelepítjük a databases/php5-mysql portot. Miután telepítettünk egy bõvítményt, az Apache szerverrel újra be kell töltetnünk a megváltozott beállításokat: &prompt.root; apachectl graceful Murray Stokely Készítette: Állományok átvitele (FTP) FTP szerverek Áttekintés Az adatállomány átviteli protokoll (File Transfer Protocol, FTP) a felhasználók számára lehetõséget ad az ún. FTP szerverekre állományokat feltölteni, illetve onnan állományokat letölteni. A &os; alaprendszere is tartalmaz egy ilyen FTP szerverprogramot, ftpd néven. Ezért &os; alatt egy FTP szerver beállítása meglehetõsen egyszerû. Beállítás A beállítás legfontosabb lépése, hogy eldöntsük milyen hozzáféréseken át lehet elérni az FTP szervert. Egy hétköznapi &os; rendszerben rengeteg hozzáférés a különbözõ démonokhoz tartozik, de az ismeretlen felhasználók számára nem kellene megengednünk ezek használatát. Az /etc/ftpusers állományban szerepelnek azok a felhasználók, akik semmilyen módon nem érhetik el az FTP szolgáltatást. Alapértelmezés szerint itt találhatjuk az elõbb említett rendszerszintû hozzáféréseket is, de ide minden további nélkül felvehetjük azokat a felhasználókat, akiknél nem akarjuk engedni az FTP elérését. Más esetekben elõfordulhat, hogy csak korlátozni akarjuk egyes felhasználók FTP elérését. Ezt az /etc/ftpchroot állományon keresztül tehetjük meg. Ebben az állományban a lekorlátozni kívánt felhasználókat és csoportokat írhatjuk bele. Az &man.ftpchroot.5; man oldalán olvashatjuk el ennek részleteit, ezért ennek pontos részleteit itt most nem tárgyaljuk. FTP anonim Ha az FTP szerverünkhöz névtelen (anonim) hozzáférést is engedélyezni akarunk, akkor ahhoz elõször készítenünk kell egy ftp nevû felhasználót a &os; rendszerünkben. A felhasználók ezután az ftp vagy anonymous nevek, valamint egy tetszõleges jelszó (ez a hagyományok szerint a felhasználó e-mail címe) használatával is képesek lesznek bejelentkezni. Az FTP szerver ezután a névtelen felhasználók esetében meghívja a &man.chroot.2; rendszerhívást, és ezzel lekorlátozza hozzáférésüket az ftp felhasználó könyvtárára. Két szöveges állományban adhatunk meg a becsatlakozó FTP kliensek számára üdvözlõ üzeneteket. Az /etc/ftpwelcome állomány tartalmát még a bejelentkezés elõtt látni fogják a felhasználók, a sikeres bejelentkezést követõen pedig az /etc/ftpmotd állomány tartalmát látják. Vigyázzunk, mert ennek az állománynak már a bejelentkezési környezethez képest relatív az elérése, ezért a névtelen felhasználók esetében ez konkrétan az ~ftp/etc/ftpmotd állomány lesz. Ahogy beállítottuk az FTP szervert, az /etc/inetd.conf állományban is engedélyeznünk kell. Itt mindössze annyira lesz szükségünk, hogy eltávolítjuk a megjegyzést jelzõ # karaktert a már meglevõ ftpd sor elõl: ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l Ahogy arról már a szót ejtett, az inetd beállításait újra be kell olvastatunk a konfigurációs állomány megváltoztatása után. Most már be is tudunk jelentkezni az FTP szerverre: &prompt.user; ftp localhost Karbantartás syslog naplóállományok FTP Az ftpd démon a &man.syslog.3; használatával naplózza az üzeneteket. Alapértelmezés szerint a rendszernaplózó démon az FTP mûködésére vonatkozó üzeneteket az /var/log/xferlog állományba írja. Az FTP naplóinak helyét az /etc/syslog.conf állományban tudjuk módosítani: ftp.info /var/log/xferlog FTP anonim Legyünk körültekintõek a névtelen FTP szerverek üzemeltetésekor. Azt pedig kétszer is gondoljuk meg, hogy engedélyezzük-e a névtelen felhasználók számára állományok feltöltését, hiszen könnyen azon kaphatjuk magunkat, hogy az FTP oldalunk illegális állománycserék színterévé válik vagy esetleg valami sokkal rosszabb történik. Ha mindenképpen szükségünk lenne erre a lehetõségre, akkor állítsunk be olyan engedélyeket a feltöltött állományokra, hogy a többi névtelen felhasználó ezeket a tartalmuk tüzetes ellenõrzéséig ne is olvashassa. Murray Stokely Készítette: Állomány- és nyomtatási szolgáltatások µsoft.windows; kliensek számára (Samba) Samba szerver Microsoft Windows állományszerver windowszos kliensek nyomtatószerver windowszos kliensek Áttekintés A Samba egy olyan elterjedt nyílt forráskódú szoftver, ami µsoft.windows; kliensek számára tesz lehetõvé állomány- és nyomtatási szolgáltatásokat. Az ilyen kliensek általa helyi meghajtóként képesek elérni a &os; állományrendszerét, vagy helyi nyomtatóként a &os; általt kezelt nyomtatókat. A Samba csomagja általában megtalálható a &os; telepítõeszközén. Ha a &os;-vel együtt nem raktuk fel a Samba csomagját, akkor ezt késõbb net/samba3 port vagy csomag telepítésével pótolhatjuk. Beállítás A Samba konfigurációs állománya a telepítés után /usr/local/share/examples/samba/smb.conf.default néven található meg. Ezt kell lemásolnunk /usr/local/etc/smb.conf néven, amelyet aztán a Samba tényleges használata elõtt módosítanunk kell. Az smb.conf állomány a Samba futásához használt beállításokat tartalmazza, mint például &windows; kliensek számára felkínált a nyomtatók és megosztások adatait. A Samba csomagban ezen kívül találhatunk még egy swat nevû webes eszközt, amellyel egyszerû módon tudjuk az smb.conf állományt állítgatni. A Samba webes adminisztrációs eszköze (SWAT) A Samba webes adminisztrációs segédeszköze (Samba Web Administration Tool, SWAT) az inetd démonon keresztül fut démonként. Ennek megfelelõn az /etc/inetd.conf állományban a következõ sort kell kivennünk megjegyzésbõl, mielõtt a swat segítségével megkezdenénk a Samba beállítását: swat stream tcp nowait/400 root /usr/local/sbin/swat swat Ahogy azt a is mutatja, az inetd démont újra kell indítanunk a megváltozott konfigurációs állományának újbóli beolvasásához. Miután az inetd.conf állományban a swat engedélyezésre került, a böngészõnk segítségével próbáljunk meg a címre csatlakozni. Elõször a rendszer root hozzáférésével kell bejelentkeznünk. Miután sikeresen bejelentkeztünk a Samba beállításait tárgyaló lapra, el tudjuk olvasni a rendszer dokumentációját, vagy a Globals fülre kattintva nekiláthatunk a beállítások elvégzésének. A Globals részben található opciók az /usr/local/etc/smb.conf állomány [global] szekciójában található változókat tükrözik. Általános beállítások Akár a swat eszközzel, akár a /usr/local/etc/smb.conf közvetlen módosításával dolgozunk, a Samba beállítása során a következõkkel mindenképpen össze fogunk futni: workgroup A szervert elérni kívánó számítógépek által használt NT tartomány vagy munkacsoport neve. netbios name NetBIOS A Samba szerver NetBIOS neve. Alapértelmezés szerint ez a név a gép hálózati nevének elsõ tagja. server string Ez a szöveg jelenik meg akkor, ha például a net view paranccsal vagy valamilyen más hálózati segédprogrammal kérdezzük le a szerver beszédesebb leírását. Biztonsági beállítások A /usr/local/etc/smb.conf állományban a két legfontosabb beállítás a választott biztonsági modell és a kliensek felhasználói jelszavainak tárolásához használt formátum. Az alábbi direktívák vezérlik ezeket: security Itt a két leggyakoribb beállítás a security = share és a security = user. Ha a kliensek a &os; gépen található felhasználói neveiket használják, akkor felhasználói szintû védelemre van szükségünk (tehát a user beállításra). Ez az alapértelmezett biztonsági házirend és ilyenkor a klienseknek elõször be kell jelentkezniük a megosztott erõforrások eléréséhez. A megosztás (share) szintû védelem esetében, a klienseknek nem kell a szerveren érvényes felhasználói névvel és jelszóval rendelkezniük a megosztott erõforrások eléréséhez. Ez volt az alapbeállítás a Samba korábbi változataiban. passdb backend NIS+ LDAP SQL adatbázis A Samba számos különbözõ hitelesítési modellt ismer. A klienseket LDAP, NIS+, SQL adatbázis vagy esetleg egy módosított jelszó állománnyal is tudjuk hitelesíteni. Az alapértelmezett hitelesítési módszer a smbpasswd, így itt most ezzel foglalkozunk. Ha feltesszük, hogy az alapértelmezett smbpasswd formátumot választottuk, akkor a Samba úgy fogja tudni hitelesíteni a klienseket, ha elõtte létrehozzuk a /usr/local/private/smbpasswd állományt. Ha a &windows;-os kliensekkel is el akarjuk érni a &unix;-os felhasználói hozzáféréseinket, akkor használjuk a következõ parancsot: &prompt.root; smbpasswd -a felhasználónév A hivatalos Samba HOGYAN ezekrõl a beállításokról szolgál további információkkal (angolul). Viszont az itt vázolt alapok viszont már elegendõek a Samba elindításához. A <application>Samba</application> elindítása A net/samba3 port a Samba irányítására egy új indító szkriptet tartalmaz. A szkript engedélyezéséhez, tehát általa a Samba elindításának, leállításának és újraindításának lehetõvé tételéhez vegyük fel a következõ sort az /etc/rc.conf állományba: samba_enable="YES" Ha még finomabb irányításra vágyunk: nmbd_enable="YES" smbd_enable="YES" Ezzel egyben a rendszer indításakor automatikusan be is indítjuk a Samba szolgáltatást. A Samba a következõkkel bármikor elindítható: &prompt.root; /usr/local/etc/rc.d/samba start Starting SAMBA: removing stale tdbs : Starting nmbd. Starting smbd. Az rc szkriptekkel kapcsolatban a t ajánljuk elolvasásra. A Samba jelen pillanatban három különálló démonból áll. Láthatjuk is, hogy az nmbd és smbd démonokat elindította a samba szkript. Ha az smb.conf állományban engedélyeztük a winbind névfeloldási szolgáltatást is, akkor láthatjuk, hogy ilyenkor a winbindd démon is elindul. A Samba így állítható le akármikor: &prompt.root; /usr/local/etc/rc.d/samba stop A Samba egy összetett szoftercsomag, amely a µsoft.windows; hálózatokkal kapcsolatos széles körû együttmûködést tesz lehetõvé. Az általa felkínált alapvetõ lehetõségeken túl a többit a honlapon ismerhetjük meg (angolul). Tom Hukins Készítette: Az órák egyeztetése az NTP használatával NTP Áttekintés Idõvel a számítógép órája hajlamos elmászni. A hálózati idõ protokoll (Network Time Protocol, NTP) az egyik módja az óránk pontosan tartásának. Rengeteg internetes szolgáltatás elvárja vagy éppen elõnyben részesíti a számítógép órájának pontosságát. Például egy webszervertõl megkérdezhetik, hogy egy állományt adott ideje módosítottak-e. A helyi hálózatban az egyazon állományszerveren megosztott állományok ellentmondásmentes dátumozása érdekében szinte elengedhetetlen az órák szinkronizálása. Az olyan szolgáltatások, mint a &man.cron.8; is komolyan építkeznek a pontosan járó rendszerórára, amikor egy adott pillanatban kell lefuttatniuk parancsokat. NTP ntpd A &os; alapból az &man.ntpd.8; NTP szervert tartalmazza, amellyel más NTP szerverek segítségével tudjuk beállítani gépünk óráját, vagy éppen idõvel kapcsolatos információkat szolgáltatni másoknak. A megfelelõ NTP szerverek kiválasztása NTP a szerverek kiválasztása Az óránk egyeztetéséhez egy vagy több NTP szerverre lesz szükségünk. Elõfordulhat, hogy a hálózati rendszergazdánk vagy az internet-szolgáltatónk már beállított egy ilyen szervert erre a célra. Ezzel kapcsolatban olvassuk el a megfelelõ leírásokat. A nyilvánosan elérhetõ NTP szerverekrõl készült egy lista, ahonnan könnyedén ki tudjuk keresni a számunkra leginkább megfelelõ (hozzánk legközelebbi) szervert. Ne hagyjuk figyelmen kívül a szerverre vonatkozó házirendet és kérjünk engedélyt a használatához, amennyiben ez szükséges. Több, egymással közvetlen kapcsolatban nem álló NTP szerver választásával járunk jól, ha netalán az egyikük váratlanul elérhetetlenné vagy az órája pontatlanná válna. Az &man.ntpd.8; a visszakapott válaszokat intelligensen használja fel, mivel esetükben a megbízható szervereket részesíti elõnyben. A gépünk beállítása NTP beállítása Alapvetõ beállítások ntpdate Ha a számítógépünk indításakor akarjuk egyeztetni az óránkat, akkor erre az &man.ntpdate.8; nevû programot használhatjuk. Ez olyan asztali gépek számára megfelelõ választás, amelyeket gyakran indítanak újra és csak idõnként kell szinkronizálnunk. A legtöbb gépnek viszont az &man.ntpd.8; használatára van szüksége. Az &man.ntpdate.8; elindítása olyan esetekben is hasznos, ahol az &man.ntpd.8; is fut. Az &man.ntpd.8; az órát fokozatosan állítja, ellenben az &man.ntpdate.8; az eltérés mértékétõl és irányától függetlenül egyszerûen átállítja a gép óráját a pontos idõre. Az &man.ntpdate.8; elindítását úgy tudjuk engedélyezni a rendszer indításakor, ha az /etc/rc.conf állományba berakjuk az ntpdate_enable="YES" sort. Emellett még ntpdate_flags változóban meg kell adnunk az alkalmazott beállítások mellett azokat a szervereket, amelyekkel szinkronizálni akarunk. NTP ntp.conf Általános beállítások Az NTP az /etc/ntp.conf állományon keresztül állítható, amelyek felépítését az &man.ntp.conf.5; man oldal tárgyalja. Íme erre egy egyszerû példa: server ntplocal.minta.com prefer server timeserver.minta.org server ntp2a.minta.net driftfile /var/db/ntp.drift A server beállítás adja meg az egyeztetéshez használt szervereket, soronként egyet. Ha egy szerver mellett szerepel még a prefer paraméter is, ahogy azt a példában a ntplocal.minta.com mellett láthattuk, akkor a többivel szemben azt a szervert fogjuk elõnyben részesíteni. Az így kiemelt szervertõl érkezõ választ abban az esetben viszont eldobjuk, hogy a többi szervertõl kapott válasz jelentõs mértékben eltér tõle. Minden más esetben a õ válasza lesz a mérvadó. A prefer paramétert általában olyan NTP szerverekhez használják, amelyek közismerten nagy pontosságúak, tehát például külön erre a célra szánt felügyeleti eszközt is tartalmaznak. A driftfile beállítással azt az állományt adjuk meg, amiben a rendszeróra frekvencia eltolódásait tároljuk. Az &man.ntpd.8; program ezzel ellensúlyozza automatikusan az óra természetes elmászását, ezáltal lehetõvé téve, hogy egy viszonylag pontos idõt kapjuk még abban az esetben is, amikor egy kis idõre külsõ idõforrások nélkül maradnánk. A driftfile beállítással egyben azt az állományt jelöljük ki, amely az NTP szervertõl kapott korábbi válaszokat tárolja. Ez az NTP mûködéséhez szükséges belsõ adatokat tartalmaz, ezért semmilyen más programnak nem szabad módosítania. A szerverünk elérésének szabályozása Alapértelmezés szerint az NTP szerverünket bárki képes elérni az interneten. Az /etc/ntp.conf állományban szereplõ restrict beállítás segítségével azonban meg tudjuk mondani, milyen gépek érhetik el a szerverünket. Ha az NTP szerverünk felé mindenféle próbálkozást el akarunk utasítani, akkor az /etc/ntp.conf állományba a következõ sort kell felvennünk: restrict default ignore Ezzel egyben azonban a helyi beállításainkban szereplõ szerverek elérését is megakadályozzuk. Ha külsõ NTP szerverekkel is szeretnénk szinkronizálni, akkor itt is engedélyezünk kell ezeket. Errõl bõvebben lásd az &man.ntp.conf.5; man oldalon. Ha csak a belsõ hálózatunkban levõ gépek számára szeretnénk elérhetõvé tenni az órák egyeztetését, de sem a szerver állapotának módosítását nem engedélyezzük, sem pedig azt, hogy a vele egyenrangú szerverekkel szinkronizáljon, akkor az iménti helyett a restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap sort írjuk bele, ahol a 192.168.1.0 a belsõ hálózatunk IP-címe és a 255.255.255.0 a hozzátartozó hálózati maszk. Az /etc/ntp.conf több restrict típusú beállítást is tartalmazhat. Ennek részleteirõl az &man.ntp.conf.5; man oldalon, az Access Control Support címû szakaszban olvashatunk. Az NTP futtatása Úgy tudjuk az NTP szervert elindítani a rendszerünkkel együtt, ha az /etc/rc.conf állományban szerepeltetjük az ntpd_enable="YES" sort. Ha az &man.ntpd.8; számára további beállításokat is át akarunk adni, akkor az /etc/rc.conf állományban adjuk meg az ntpd_flags paramétert. Ha a gépünk újraindítása nélkül akarjuk elindítani a szerver, akkor az ntpd parancsot adjuk ki az /etc/rc.conf állományban a ntpd_flags változóhoz megadott paraméterekkel. Mint például: &prompt.root; ntpd -p /var/run/ntpd.pid Az ntpd használati idõleges internet csatlakozással Az &man.ntpd.8; program megfelelõ mûködéséhez nem szükséges állandó internet kapcsolat. Ha azonban igény szerinti tárcsázással építjünk fel ideiglenes kapcsolatot, akkor érdemes letiltani az NTP forgalmát, nehogy feleslegesen aktiválja vagy tartsa életben a vonalat. Ha PPP típusú kapcsolatunk van, akkor az /etc/ppp/ppp.conf állományban a filter direktívával tudjuk ezt leszabályozni. Például: set filter dial 0 deny udp src eq 123 # Nem engedjük az NTP által küldött adatoknak, hogy tárcsázást # kezdeményezzenek: set filter dial 1 permit 0 0 set filter alive 0 deny udp src eq 123 # Nem engedjük az NTP adatainak, hogy fenntartsák a kapcsolatot: set filter alive 1 deny udp dst eq 123 set filter alive 2 permit 0/0 0/0 Mindenezekrõl részletesebb felvilágosítást a &man.ppp.8; man oldal PACKET FILTERING címû szakaszában és a /usr/share/examples/ppp/ könyvtárban található példákban kaphatunk. Egyes internet-szolgáltatók blokkolják az alacsonyabb portokat, ezáltal az NTP nem használható, mivel a válaszok nem fogják elérni a gépünket. További olvasnivalók Az NTP szerver dokumentációja HTML formátumban a /usr/share/doc/ntp/ könyvtárban található. diff --git a/hu_HU.ISO8859-2/books/handbook/printing/chapter.sgml b/hu_HU.ISO8859-2/books/handbook/printing/chapter.sgml index e583357f8d..0d18b78aa5 100644 --- a/hu_HU.ISO8859-2/books/handbook/printing/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/printing/chapter.sgml @@ -1,6903 +1,6905 @@ 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ó stb. Soros portok A soros csatolófelületet használó nyomtatók beüzemeléséhez elõször egy soros kábel segítségével kapcsoljuk össze a számítógépünkkel. Ennek pontos részleteit a nyomtató és/vagy a számítógépünk kézikönyvében találhatjuk meg. Ha nem vagyunk benne biztosak, hogy milyen a megfelelõ soros kábel, próbáljunk az alábbiak alapján dönteni: A modem kábele a két oldalán levõ az egymásnak megfelelõ tüskéket közvetlenül összeköti. Ezt a típust nevezik DTE-DCE kábelnek. null-modem kábel A null-modem kábel bizonyos érintkezõket rendesen, másokat pedig fordítva köt össze (például a küldõt a fogadóval), illetve némelyeket rövidre zár közvetlenül a csatlakozón belül. Ez a típus a DTE-DTE kábel. Néhány speciális nyomtató esetén elõfordul még a soros nyomtatókábel, amelyek leginkább a null-modem kábelekez hasonlítanak, azonban az ott rövidre zárt csatornák itt a nekik megfelelõ érintkezõknek továbbítanak jeleket. jelváltási sebesség paritás forgalomirányítási protokoll Emellett még a nyomtató elõlapján vagy az alján található kapcsolók segítségével be kell állítanunk a nyomtatóhoz tartozó kommunikációs paramétereket is. Itt válasszuk azt a bps (a bitek száma másodpercenként) értéket, amelyet még a számítógépünk és a nyomtatónk is egyaránt képes támogatni. Válasszunk 7 vagy 8 adatbitet, páros, páratlan vagy kikapcsolt paritásbitet és 1 vagy 2 stopbitet. Ekkor tudjuk megadni a forgalomirányítási protokollt is: lehet kikapcsolt, XON/XOFF (ez az ún. sávon belüli vagy szoftveres) forgalomirányítás. Ne felejtsük el ezeket a beállításokat a most következõ szoftveres beállítások elvégzése során sem. Szoftveres beállítás Ebben a fejezetben tárgyaljuk a &os;-ben található LPD nyomtatási rendszer mûködéséhez és a nyomtatáshoz szükséges szoftveres beállításokat. Íme az elvégzendõ lépések rövid vázlata: Amennyiben szükséges, állítsuk be a rendszermagunkat nyomtató által használt portra. Ehhez A rendszermag beállítása szakaszban olvashatjuk mit is kell pontosan tenni. Ha párhuzamos portot használunk, akkor állítsuk be, hogy a párhuzamos port miként fog kommunikálni. A párhuzamos port kommunikációs módjának beállítása címû szakasz tárja fel ennek részleteit. Próbáljuk ki, hogy ezek után az operációs rendszer képes-e adatot küldeni a nyomtatónak. A nyomtató kommunikációjának ellenõrzése szakaszban kapunk erre pár javaslatot. Az /etc/printcap állomány felhasználásával állítsuk be a nyomtatónkhoz a LPD-t. Errõl a fejezet további részei adnak majd felvilágosítást. A rendszermag beállítása Az operációs rendszer magja eszközök egy adott csoportjával képes együttmûködni, amiben a soros és párhuzamos felületen csatlakozó nyomtatók is megtalálhatóak. Azonban ha a rendszermag nem ismeri fel még valamelyiket, akkor a soros vagy párhuzamos portok használatához külön támogatásra van szükség. Így tudjuk megnézni, hogy a jelenleg használt rendszermag támogatja-e a soros csatolófelületet: &prompt.root; grep sioN /var/run/dmesg.boot Itt az N nullától kezdõdõen adja meg a soros port sorszámát. Amennyiben látunk valami ilyesmit: sio2 at port 0x3e8-0x3ef irq 5 on isa sio2: type 16550A Ez azt jelenti, hogy a rendszermag sikeresen észlelte a portot. A párhuzamos csatolófelület támogatásáról így gyõzõdhetünk meg: &prompt.root; grep ppcN /var/run/dmesg.boot Itt az N nullától kezdõdõen sorszámozza a párhuzamos portot. Ha eredményül valami hasonlót kapunk: ppc0: <Parallel port> at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold Ez arra utal, hogy a rendszermagunk tud a portról. Elõfordulhat azonban, hogy az operációs rendszer csak akkor fogja észrevenni a nyomtatásra használt soros vagy párhuzamos portot, ha átállítjuk a rendszermagunkat. A soros port támogatásának beállításához olvassuk el a rendszermag beállításáról szóló szakaszt. A párhuzamos port támogatásához szintén olvassuk el ugyanazt a szakaszt és a most a következõt. A párhuzamos port kommunikációs módjának beállítása A párhuzamos csatolófelület használata esetén választhatunk, hogy a &os; milyen módon tartsa a kapcsolatot a nyomtatóval: megszakításokkal vezérelje (interrupt-driven) vagy esetleg folyamatosan kérdezgesse (polled). A &os; általános meghajtója (&man.lpt.4;) a &man.ppbus.4; alrendszert használja, ami a portot a &man.ppc.4; meghajtón keresztül vezérli. A megszakítás alapú módszer a GENERIC rendszermagban alapértelmezés. Ilyenkor az operációs rendszer egy megszakításkérés felhasználásával értesül arról, hogy a nyomtató mikor áll készen adatok fogadására. A lekérdezéses módszer használata során az operációs rendszer folyamatosan érdeklõdik a nyomtató rendelkezésre állásáról. Amikor erre pozitív megerõsítést kap, akkor a rendszermag újabb adatokat küld. A megszakításos módszer valamivel gyorsabb, azonban cserébe lefoglal egy értékes IRQ vonalat. A HP újabb nyomtatói állítólag nem mûködnek megfelelõen ilyen módban, valamilyen (pillanatnyilag még nem teljesen tisztázott) idõzítési probléma miatt. Ezért az ilyen nyomtatóknak is valószínûleg a lekérdezéses módszer kell használniuk. Más nyomtatók pedig habár mûködnek mind a két módszerrel, hihetetlenül lassúak a megszakításokkal. Kétféleképpen állíthatjuk be a kommunikációs módot: a rendszermagon keresztül, vagy az &man.lptcontrol.8; segédprogrammal. A rendszermagban így állíthatjuk be a kommunikációt: Írjuk át a rendszermag beállításait tartalmazó állományt. Keressük meg benne a használt párhuzamos portnak megfelelõen a ppc0, ppc1 (második párhuzamos port) vagy ppc2 (harmadik párhuzamos port) bejegyzést, és engedélyezzük. A megszakításos mód használatához nyissuk meg a /boot/device.hints állományt, és az N helyére írjuk be a hint.ppc.0.irq="N" sorba a megfelelõ IRQ számát. A rendszermag beállításait tartalmazó állománynak tartalmaznia kell a &man.ppc.4; meghajtót is: device ppc A lekérdezéses mód használatához a /boot/device.hints állományból távolítsuk el a következõ sort: hint.ppc.0.irq="N" Némely esetben azonban ennyi még nem lesz elég a port lekérdezéses beállításához. Ugyanis ha a hozzátartozó meghajtó az &man.acpi.4;, akkor ez fogja felismerni, kezelni és a nyomtatóhoz tartozó portok hozzáférési módját vezérelni. A problémát ezért gyakran érdemes a &man.acpi.4; beállításai között is keresni. Mentsük el az állományt. Konfiguráljuk be, fordítsuk le és telepítsük az új rendszermagot. Ennek pontos részleteit a rendszermag beállításáról szóló fejezetben olvashatjuk. A kommunikáció módjának beállítása az &man.lptcontrol.8; programmal: A megszakításos mód beállításához írjuk be: &prompt.root; lptcontrol -i -d /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 ahol az lptN a nyomtatóhoz tartozó eszköz neve. Ha ezeket a parancsokat berakjuk az /etc/rc.local állományunkba, akkor azzal a rendszer minden egyes indítása során beállítjuk a számunkra megfelelõ módot. Errõl többet az &man.lptcontrol.8; man oldaláról tudhatunk meg. A kommunikáció ellenõrzése Még mielõtt nekilátnánk a nyomtatási rendszer beállításának, bizonyosodjuk meg róla, hogy az operációs rendszer képes adatokat továbbítani a nyomtatónak. Sokkal könnyebb egymástól függetlenül megvizsgálni a kommunikáció és nyomtatási rendszer mûködését. A nyomtatót úgy tudjuk kipróbálni, ha küldünk neki valamilyen szöveget. Az &man.lptest.1; tökéletesen megfelelõ akkor, ha olyan nyomtatónk van, amely azonnal kinyomtatja a kapott szöveget. Ez a program 96 sorban létrehozza mind az összes 96 kinyomtatható ASCII karaktert. PostScript A &postscript; (vagy más egyéb nyelvet ismerõ) nyomtatóknak azonban ennél kifinomultabb próbára van szüksége. Erre a célra tökéletesen megfelel egy olyan kisebb &postscript; programocska, mint például ez: %!PS 100 100 moveto 300 300 lineto stroke 310 310 moveto /Helvetica findfont 12 scalefont setfont (Remek! Ez mukodik!) show showpage Ezt a &postscript; kódot nyugodtan elmenthetjük egy állományba, amelyet aztán a késõbbi szakaszokban megjelenõ példák szerint használni is tudunk majd. PCL A kézikönyvben a nyomtató nyelve alatt leginkább egy &postscript;-szerû nyelvet értünk, nem pedig a Hewlett Packard PCL típusú nyelvét. Habár a PCL nagyon sokra képes, hiszen keverhetjük még benne akár a programokat és a nyers szövegeket is. Ezzel szemben a &postscript; nem képes nyers szöveget kinyomtatni, ezért az ilyen típusú nyomtatók mûködtetéséhez külön támogatásra van szükségünk. A párhuzamos nyomtató ellenõrzése nyomtató párhuzamos Ebben a szakaszban megtudhatjuk, hogy &os; alatt miként ellenõrizzük a párhuzamos portra csatlakozó nyomtatók mûködését. A párhuzamos porton levõ nyomtató kipróbálásához: A &man.su.1; segítségével váljunk root felhasználóvá. Küldjünk a nyomtatónak valamilyen adatot. Ha a nyomtató képes nyers szöveget fogadni, akkor használjuk az &man.lptest.1; programot. Ehhez gépeljük be: &prompt.root; lptest > /dev/lptN ahol az N nullától kezdõdõen a párhuzamos port sorszáma. Ha a nyomtató &postscript; vagy más nyomtatási nyelvet ismer, akkor egy apró programot kell küldenünk neki. Ehhez írjuk be: &prompt.root; cat > /dev/lptN Ezután soronként írjuk be a programot, de vigyázzunk, mert az Enter vagy a Return lenyomása után már nem tudjuk kijavítani! A program begépelése után nyomjuk meg a CtrlD vagy bármely más olyan billentyûkombinációt, amivel ki tudunk lépni. Ezt a programot belerakhatjuk egy állományba is, amire aztán adjuk ki az alábbi parancsot: &prompt.root; cat állomány > /dev/lptN ahol az állomány a nyomtatóra küldendõ program neve lesz. Ezután a nyomtató megkezdi a nyomtatást. Ne aggódjunk, ha netalán valami furcsán nézne ki, mert a késõbbiekben ezt még úgyis rendbetesszük. A soros nyomtató ellenõrzése nyomtató soros Ebben a szakaszban megtudhatjuk, hogyan ellenõrizzük a &os; és soros portra kötött nyomtató kapcsolódását. Így tudjuk kipróbálni a soros porton csatlakozó nyomtatónkat: A &man.su.1; paranccsal váljunk root felhasználóvá. Nyissuk meg az /etc/remote állományt. Tegyük hozzá a következõ sort: printer:dv=/dev/port:br#bps:pa=paritás bit-per-másodperc soros port paritás ahol a port a soros porthoz tartozó eszközleíró neve (ttyd0, ttyd1, stb.), a bps a nyomtató által használt adatátviteli sebesség, végül a paritás a nyomtatóhoz használt paritás (ami lehet even (páros), odd (páratlan), none (nincs), vagy zero (nulla)). Íme egy olyan soros nyomtató beállítása (printer néven), amely sebessége 19 200 bps, a harmadik portra csatlakozik és nem használ paritást: printer:dv=/dev/ttyd2:br#19200:pa=none Kapcsolódjunk a nyomtatóhoz a &man.tip.1; segítségével. Ennek parancsa: &prompt.root; tip printer Ha az iménti lépés nem mûködne, próbálkozzunk az /etc/remote állomány újbóli módosításával, és a /dev/cuaaN eszköz helyett használjuk a /dev/ttydN eszközt! Küldjünk adatot a nyomtatónak. Ha a nyomtató képes nyers szöveget nyomtatni, akkor használjuk az &man.lptest.1; segédprogramot. Gépeljük be: &prompt.user; $lptest Ha a nyomtató a &postscript; vagy egy hozzá hasonló nyomtatási nyelven kommunikál, akkor a nyomtatónak egy rövid programot kell küldenünk. Soronként gépeljük be a programot, azonban vigyázzunk arra, hogy a törlés és minden más szerkesztésre használt billentyû a nyomtató számára is értelmes lehet. Az is elõfordulhat, hogy a program küldését egy speciális jelsorozattal tudjuk csak lezárni. A &postscript; nyomtatók esetén ilyenkor elegendõ a Ctrl D billentyûk együttes lenyomása. Vagy tehetjük az egész programot egy állományba, amihez aztán írjuk be ezt: &prompt.user; >állomány ahol az állomány a programot tartalmazó állomány neve. Miután a &man.tip.1; elküldte az állományt, nyomjuk le a lezáráshoz szükséges billentyûkombinációt. Most már meg kellene jelennie valaminek a nyomtatón. Az még nem számít, pontosan mi is lesz az — késõbb még majd úgyis beállítjuk. A nyomtatási rendszer aktiválása: a <filename>/etc/printcap</filename> állomány Csatlakoztattuk a nyomtatónkat, a mûködtetéséhez beállítottuk a rendszermagot (amennyiben erre szükségünk volt), és tudtunk neki adatokat küldeni. Most már készen állunk arra, hogy LDP alkalmazáson keresztül beállítsuk a nyomtató hozzáférésének vezérlését. Az LPD beállításait az /etc/printcap állományban találjuk. Az LPD nyomtatási rendszer minden egyes mûvelet elõtt beolvassa ezt az állományt, ezért a benne végzett módosítások szinte azonnal életbe is lépnek. nyomtató tulajdonságai A &man.printcap.5; tartalma könnyen érthetõ, a /etc/printcap állományt egyszerûen módosíthatjuk a kedvenc szövegszerkesztõnkkel. A felépítése teljesen megegyezik a többi hozzá hasonló állományéval: ilyenek például a /usr/share/misc/termcap és a /etc/remote. Az itt alkalmazott formátum teljes leírását a &man.cgetent.3; man oldalon találjuk. A nyomtatási rendszer egyszerû beállítása az alábbi lépésekbõl áll: Adjunk nevet (és még néhány álnevet) a nyomtatónak, írjuk ezeket az /etc/printcap állományba. A nevekrõl A nyomtató elnevezése címû szakaszban kapunk felvilágosítást. fejléclapok A(z alapból bekapcsolt) fejléclapokat az sh tulajdonság megadásával kapcsolhatjuk ki. A részleteket A fejléclapok letiltása címû szakaszban találjuk. Hozzunk létre egy nyomtatási könyvtárat, és adjuk meg a helyét az sd tulajdonság beállításával. A nyomtatási könyvtár létrehozása címû szakaszban fogunk errõl többet mondani. Állítsunk be egy nyomtató által használt /dev könyvtárbeli leírót, és az lp tulajdonsággal adjuk meg az /etc/printcap állományban. Errõl részletesebben A nyomtatóeszköz azonosítása címû szakaszban olvashatunk. Ha a nyomtató soros porton keresztül csatlakozik, az ms# tulajdonsággal még meg kell adnunk A nyomtatási rendszer kommunikációs paraméterei szakaszban tárgyaltakat is. Helyezzünk el egy szûrõt a beérkezõ nyers szövegek számára. Errõl A szövegszûrõ telepítése címû szakasz értekezik. Az &man.lpr.1; parancs segítségével próbáljuk ki a nyomtatást. Ennek pontos részleteit a Próbáljuk ki! és a Hibakeresés címû fejezetekben találhatjuk meg. A magasabb szintû nyomtatók, mint például a &postscript; nyomtatók nem képesek közvetlenül nyers szöveget nyomtatni. Az imént felvázolt egyszerû beállítási séma feltételezi, hogy csak olyan állományokat fogunk nyomtatni a nyomtatón, amelyeket meg is ért. A felhasználók gyakran arra számítanak, hogy bármelyik általuk elérhetõ nyomtatón képesek nyers szöveget kinyomtatni. Az LPD alkalmazással kapcsolatban álló programok is általában ugyanezt az elgondolást követik. Ha egy saját nyelvvel rendelkezõ nyomtatót akarunk telepíteni, de a nyomtató saját nyelvén és a nyers szöveg formájában érkezõ munkákat is rendesen ki akarjuk nyomtatni, akkor mindenképpen javasoljuk, hogy illeszünk még egy további lépést is ebbe a sorba: illesszünk a rendszerbe egy nyers szövegrõl automatikusan &postscript; (vagy más egyéb) nyelvre tolmácsoló programot. Errõ a Szöveges nyomtatási feladatok &postscript; nyomtatókon címû fejezetben olvashatunk. A nyomtató elnevezése Az elsõ (egyszerû) lépés a nyomtatónk nevének kiválasztása. Igazából nem számít, mennyire kifejezõ vagy éppen hóbortos nevet adunk neki, hiszen emellett még számos álnévvel is illethetjük. Az /etc/printcap állományban megtalálható nyomtatók egyikének legalább az lp álnévvel rendelkeznie kell, mivel ez lesz az alapértelmezett nyomtató neve. Tehát ha a felhasználó nem adja meg sem a PRINTER környezeti változót, sem pedig az LPD-vel kapcsolatban álló aktuális parancsban a használni kívánt nyomtató nevét, akkor a rendszer az lp nevût fogja keresni. Ezenkívül általában még gyakran adnak egy olyan álnevet is a nyomtatónak, ahol annak teljes leírása, többek közt a gyártmánya és a típusa szerepel. Ahogy sikerült nevet és álneveket adni a nyomtatónak, írjuk is be ezeket az /etc/printcap állományba. Itt a nyomtató neveit balról el kezdjük felsorolni, mindegyik álnevet egy függõleges vonallal válasszunk el, és az utolsó után pedig tegyünk pontosvesszõt. A most következõ példában egy olyan vázt mutatunk be az /etc/printcap állományhoz, amiben két nyomtatót (egy Diablo 630 márkájú sornyomtatót és egy Panasonic KX-P4455 típusú &postscript; lézernyomtatót) adunk meg: # # /etc/printcap (rose) # rattan|line|diablo|lp|Diablo 630 Line Printer: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4: Ebben a példában az elsõ nyomtató neve rattan, és ehhez tartozik még a line, diablo, lp, és Diablo 630 Line Printer álnév. Mivel itt soroltuk fel az lp álnevet is, ezért a rendszerben ez lesz az alapértelmezett nyomtató. A második nyomtató neve bamboo, és álnevei többek közt a ps, PS, S, panasonic, valamint a Panasonic KX-P4455 PostScript v51.4. A fejléclapok letiltása nyomtatás fejléclapok Az LPD nyomtatási rendszer alapértelmezés szerint minden egyes feladathoz fejléclapot készít. Ez a lap szép nagy betûkkel tartalmazza a munkát kiadó felhasználó nevét, a gépet, amirõl küldték, és a feladat nevét. Sajnálatos módon ez azonban inkább akadályozza a hibakeresést a nyomtató beállításában, ezért most inkább kapcsoljuk ki ezeket. Ha le akarjuk tiltani a fejléclapokat, az /etc/printcap állományban adjuk meg az sh (úgy mint suppress header pages) tulajdonságot. Íme egy példa az sh tulajdonsággal bõvített /etc/printcap állományra: # # /etc/printcap (rose) - sehol sem lesznek fejléclapok # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh: Ebben a példában megfigyelhetjük a helyes felírási módot: az elsõ sor a legbaloldalibb oszlopban kezdõdik, és az azt követõ sorok pedig bentebb. Minden bejegyzésben az utolsó kivételével mindegyik sor egy visszaper (backslash) karakterrel zárul. A nyomtatási könyvtár létrehozása nyomtatási rendszer nyomtatási munkák A nyomtatási rendszerünk beállításának következõ lépése a nyomtatási könyvtár létrehozása. Ez egy olyan könyvtár, ahová a különbözõ nyomtatási feladatok kerülnek a feldolgozásuk elõtt, valamint ahol a nyomtatási rendszer többi állománya lakozik. A nyomtatási rendszer adatait tároló könyvtárakat tartalmuk gyakori változása miatt általában a /var/spool könyvtárba szokás tenni. Ezen könyvtárak tartalmát nem szükséges menteni sem. Az &man.mkdir.1; parancs futtatásával egyszerûen újra létre tudjuk hozni. Általában minden nyomtatóhoz külön létre szoktak hozni egy könyvtárat az adott nyomtató nevén. Erre példa: &prompt.root; mkdir /var/spool/nyomtatónév Azonban ha a hálózatunkon rengeteg nyomtató található, akkor érdemes inkább egyetlen könyvtárat használni, amelyet az LPD számára tartunk fenn. &prompt.root; mkdir /var/spool/lpd &prompt.root; mkdir /var/spool/lpd/rattan &prompt.root; mkdir /var/spool/lpd/bamboo Amennyiben fontos nekünk a felhasználói nyomtatások titkosságának megóvása, érdemes levédenünk a nyomtatási könyvtárat, így az nem lesz mindenki által elérhetõ. A nyomtatási könyvtárak tulajdonosa egyedül és kizárólag a daemon felhasználó és a daemon csoport legyen, és hozzá olvasási, írási és keresési engedélyekkel rendelkezzen. Ezt fogjuk most beállítani a példáinkban szereplõ nyomtatóinkhoz is: &prompt.root; chown daemon:daemon /var/spool/lpd/rattan &prompt.root; chown daemon:daemon /var/spool/lpd/bamboo &prompt.root; chmod 770 /var/spool/lpd/rattan &prompt.root; chmod 770 /var/spool/lpd/bamboo Végezetül az /etc/printcap állományban ezeket a könyvtárakat se felejtsük el megadni az LPD-nek. Itt a nyomtatási könyvtár nevét az sd tulajdonsággal írjuk le: # # /etc/printcap (rose) - a nyomtatási könyvtárak hozzáadása # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo: Vegyük észre, hogy a nyomtató neve ugyan a sor elején kezdõdik, azonban a hozzátartozó összes többi sor mind bentebb kezdõdik és egy visszaper (backslash) karakterrel választjuk le. Ha az sd tulajdonsággal nem adunk meg semmilyen nyomtatási könyvtárat, akkor ennek az értéke alapértelmezés szerint a /var/spool/lpd lesz. A nyomtatóeszköz azonosítása - A portok beállításával - foglalkozó szakaszban már + A Hardveres beállítás + címû szakaszban már beazonosítottuk, hogy a &os; a /dev könyvtárban melyik eszközleírón keresztül fogja megszólítani a nyomtatót. Most ideje - ugyanezt tudatni az LPD-vel 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é). + ugyanezt tudatni az LPD + démonnal is. Így amikor a nyomtatási + rendszer ki szeretne nyomtatni egy munkát, a + szûrõprogram nevében ezt az eszközt + nyitja meg (ahol a szûrõn keresztül + továbbítjuk az adatokat a nyomtató + felé). Az lp tulajdonság segítségével a /etc/printcap állományban soroljuk fel a nyomtatók /dev könyvtárban található leíróit. Az eddig használt példánkban most tételezzük fel, hogy a rattan nevû nyomtató az elsõ párhuzamos porton található, míg a bamboo nevû a hatodik soros porton. Ebben a helyzetben így kellene kiegészítenünk az /etc/printcap állományunkat: # # /etc/printcap (rose) - a használni kívánt eszközök # beazonosítása # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:\ :lp=/dev/ttyd5: Az LPD alapértelmezés szerint a /dev/lp eszköz fogja használni, ha nem adjuk meg az lp tulajdonságot az /etc/printcap állományban. Az /dev/lp azonban a &os;-ben jelenleg nem létezik. Ha a telepítendõ nyomtatónk valamelyik párhuzamos portra csatlakozik, akkor innen akár tovább is léphetünk A szövegszûrõ telepítése címû szakaszra. Ha viszont nem, kövessük a most következõ szakaszban szereplõ utasításokat. A nyomtatási rendszer kommunikációs paraméterei nyomtató soros A soros portra csatlakozó nyomtatóknál az LPD képes beállítani az adatátviteli sebességet, a paritást, valamint más egyéb olyan kommunikációs paramétereket, amelyekkel a szûrõprogram adatokat tud továbbítani a nyomtató felé. Ez több szempontból is elõnyös, mivel: Egyszerûen az /etc/printcap állomány átírásával ki tudunk próbálni több kommunikációs beállítást, nem kell magát a szûrõprogramot újrafordítanunk. A nyomtatási rendszer képes ugyanazt a szûrõt több, különbözõ kommunikációs beállítást alkalmazó nyomtatóhoz is használni. Az /etc/printcap állományban az lp tulajdonsággal megadott eszközök soros kommunikációjának beállításait az alábbi tulajdonságok határozzák meg: br#sebesség Beállítja az eszköz adatátviteli sebességét a sebesség értékre, ahol a sebesség lehet 50, 75, 110, 134, 150, 200, 300, 600, 1200, 1800, 2400, 4800, 9600, 19 200, 38 400, 57 600 vagy 115 200 bit másodpercenként (bps). ms#stty-mód Beállítja az eszköz megnyitása után használt termináleszköz mûködésének paramétereit. Az &man.stty.1; man oldalon többet is megtudhatunk róluk. Miután az LPD megnyitja az lp tulajdonsággal megadott eszközt, beállítja az ms# tulajdonság értéke szerint annak jellemzõit. Itt a parenb, parodd, cs5, cs6, cs7, cs8, cstopb, crtscts, és ixon módok lehetnek lényegesek, melyekrõl az &man.stty.1; man oldalon többet is megtudhatunk. Állítsunk most akkor be az egyik képzeletbeli nyomtatónkat a hatodik soros portra. Az adatátviteli sebessége 38 400 bps lesz. A kommunikáció módjánál kapcsoljuk ki a paritást (-parenb), 8 bites karakterek legyenek (cs8), ne legyen modemes vezérlés (clocal) és a hardveres forgalomirányítás legyen crtscts: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:\ :lp=/dev/ttyd5:ms#-parenb cs8 clocal crtscts: A szövegszûrõ telepítése nyomtatás szûrõk Most már utasíthatjuk az LPD-t, hogy milyen szövegszûrõt használjon a munkák nyomtatóra küldéséhez. A szövegszûrõ (text filter), vagy más néven bemeneti szûrõ (input filter) egy olyan program, amelyet az LPD egy nyomtatási feladat elvégzésekor lefuttat. Amikor az LPD lefuttatja a nyomtatóhoz tartozó szövegszûrõt, a szûrõ szabványos bemenetére elküldi a kinyomtatandó munkát, és a szabványos kimenetét pedig átirányítja az lp tulajdonság által megadott nyomtatóeszközre. Ennek megfelelõen a szûrõnek a szabványos bemenetrõl kell olvasnia az elvégzendõ feladatot, a szabványos kimenetre pedig a ténylegesen nyomtatandót kell kiírnia. A szövegszûrõk részleteirõl a Hogyan mûködnek a szûrõk? szakasz szól. A mi esetünkben most szövegszûrõnek tökéletesen megfelel egy olyan rövid szkript, ami a nyomtatóra a munkát a /bin/cat paranccsal küldi ki. A &os;-ben még találhatunk egy másik szûrõt is, amelynek a neve lpf. Ez képes a törlést és aláhúzást jelzõ karaktereket érthetõvé tenni bizonyos nyomtatók számára. Természetesen itt használhatunk kedvünk szerinti szûrõt is. Az lpf szûrõ mûködésének részleteit Az lpf szövegszûrõ címû szakaszban fejtjük ki bõvebben. Elõször is készítsünk egy /usr/local/libexec/if-simple nevû egyszerû szövegszûrõ szkriptet. A kedvenc szövegszerkesztõnkkel írjuk bele a következõ sorokat: #!/bin/sh # # if-simple - egyszerû szövegszûrõ szkript az lpd-hez # Helye: /usr/local/libexec/if-simple # # Egyszerûen átmásolja a kimenetére a bemenetérõl érkezõ adatokat; nem # fogad el semmilyen paramétert. /bin/cat && exit 0 exit 2 Tegyük indíthatóvá: &prompt.root; chmod 555 /usr/local/libexec/if-simple Ezután tájékoztassuk róla az LPD-t az /etc/printcap állományban található if tulajdonság megadásával. Itt most a példánkban szereplõ mind a két nyomtatóhoz beillesztjük: # # /etc/printcap (rose) - a szövegszûrõ hozzáadása # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0:\ :if=/usr/local/libexec/if-simple: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:\ :lp=/dev/ttyd5:ms#-parenb cs8 clocal crtscts:\ :if=/usr/local/libexec/if-simple: Az if-simple szkript megtalálható a /usr/share/examples/printing könyvtárban. Az <application>LPD</application> elindítása Az &man.lpd.8; az /etc/rc szkriptbõl, az lpd_enable változó értékének megfelelõen indul el. Ennek értéke alapból NO, vagyis nem. Ha eddig még nem tettük volna meg, akkor az /etc/rc.conf állományba most vegyük fel a következõ sort: lpd_enable="YES" Ezután vagy indítsuk újra a számítógépünket, vagy pedig adjuk ki az &man.lpd.8; parancsot: &prompt.root; lpd Próbáljuk ki! Elérkeztünk az LPD egyszerû beállításának utolsó lépéséhez. Sajnos azonban még nem gratulálhatunk, hiszen hátra van még a nyomtató kipróbálása és az esetlegesen elõforduló hibák kijavítása. A beállítást úgy tudjuk a legegyszerûbben letesztelni, ha megpróbálunk valamit kinyomtatni. Az LPD rendszerben az &man.lpr.1; parancs használatával tudunk nyomtatási feladatokat kiadni. A kommunikáció ellenõrzése címû szakaszban megtalálhatjuk, hogy hozzunk létre tesztelésre alkalmas szövegeket az &man.lpr.1; és az &man.lptest.1; programok segítségével. Az LPD beállításainak egyszerû tesztelése: Írjuk be: &prompt.root; lptest 20 5 | lpr -Pnyomtatónév ahol a nyomtatónév az /etc/printcap állományban megadott egyik nyomtató neve (vagy álneve) lehet. Az alapértelmezett nyomtató kipróbálásához ne adjunk meg az &man.lpr.1; parancsnak semmilyen paramétert. Még egyszer megemlítenénk, hogy amennyiben &postscript; nyomtatót tesztelünk, az elõbbi helyett az &man.lptest.1; paranccsal küldjünk ki egy &postscript; programot. Ehhez tegyük a tesztelõ programunkat egy állományba, majd írjuk be az lpr állománynév parancsot. A &postscript; nyomtató esetén a kiküldött program eredményét kell látnunk. Amennyiben az &man.lptest.1; parancsot használjuk, valami ilyesmire kell számítanunk: !"#$%&'()*+,-./01234 "#$%&'()*+,-./012345 #$%&'()*+,-./0123456 $%&'()*+,-./01234567 %&'()*+,-./012345678 A nyomtató kimerítõbb teszteléséhez próbáljunk meg nagyobb programokat keríteni valahonnan (ha a nyomtatónk valamilyen nyelven kommunikál) vagy adjunk meg az &man.lptest.1; parancsnak más paramétereket. Például az lptest 80 60 soronként 80 karaktert írat ki 60 sorban. Amennyiben a nyomtató nem mûködne, nézzük meg a Hibakereséshez tartozó szakaszt. Magasszintû nyomtatóbeállítás Ebben a szakaszban olyan szûrõket mutatunk be, amelyek speciálisan formázott állományok, fejléclapok, hálózati nyomtatás, nyomtatási nyilvántartás vagy szabályozás esetén használhatóak. Szûrõk nyomtatás szûrõk Noha az LPD képes hálózati protokollokat, nyomtatási sorokat, hozzáférést és sok minden más nyomtatási feladatot kezelni, a tényleges munka legnagyobb része a szûrõkben (filter) történik. A szûrõk olyan programok, amelyek tartják a kapcsolatot a nyomtatóval és megbírkóznak annak eszközfüggõségeivel és különleges igényeivel. Az egyszerû beállítás során egy primitív szövegszûrõt állítottunk be (lásd A szövegszûrõ telepítése) — ami annyira egyszerû, hogy szinte minden nyomtatón mûködnie kell. Azonban mindahhoz, hogy ki tudjuk használni a különbözõ átalakítási, nyilvántartási lehetõségeket, valamint a nyomtatók különlegességeit és egyebeit, meg kell értenünk a szûrõk pontos mûködését. Az elõbb említett feladatok ugyanis teljesen a szûrõ kezében vannak. Ezzel kapcsolatban azonban rossz hír, hogy ezeket a szûrõket nekünk kell megírnunk. A jó hír ellenben az, hogy könnyen találunk ilyen szûrõket, vagy ha éppen nem lelnénk valamelyiket, akkor is gyorsan meg tudjuk ezeket írni. Sõt, a &os; alapból tartalmaz is egyet, amit a /usr/libexec/lpr/lpf helyen találunk meg, és sok olyan nyomtatóval képes együttmûködni, amelyek nyers szöveget tudnak nyomtatni. (Kezeli az állományokban felbukkanó törléseket és tabulalásokat, valamint képes nyilvántartást vezetni, de semmi többet.) Rajta kívül még számos szûrõt és szûrõelemet is találhatunk a &os; Portgyûjteményében. Lássuk, mit tartogat számunkra ez a rész: A Hogyan mûködnek a szûrõk? címû szakaszban megpróbálunk egyfajta áttekintést adni a szûrõk nyomtatási folyamatban betöltött szerepérõl. Mindenképpen érdemes elolvasnunk ezt a szakaszt, mivel ebben derül ki, hogy valójában mi is történik a függöny mögött, vagyis amikor az LPD használja ezeket a szûrõket. Ezzel a tudással el tudjuk kerülni vagy éppen nyakon tudjuk csípni azokat a problémákat, amelyek a nyomtatóinkhoz telepített szûrõk hozzáadása során adódhatnak. Az LPD alapból arra számít, hogy minden nyomtató képes nyers szöveget nyomtatni. Ez gondot okoz a &postscript; (és minden más nyelv alapú) nyomtatók esetén, mivel azok nem képesek nyers szöveget nyomtatni. Szöveges nyomtatási feladatok &postscript; nyomtatókon címû szakaszban viszont fény derül rá, hogyan kerekedjünk felül ezen. Feltétlenül olvassuk el, ha &postscript; nyomtatónk van. A &postscript; számos program közkedvelt kimeneti formátuma, sõt gyakran maguk a felhasználók is szeretnek ilyen programokat írni. Sajnos azonban a &postscript; nyomtatók egyáltalán nem olcsók. A &postscript; szimulációja nem &postscript; nyomtatókon címû szakaszban megtudhatjuk, miképp tudjuk úgy módosítani a szûrõt, hogy nem &postscript; nyomtatókon is tudjunk &postscript; programokkal nyomtatni. Ezt a szakaszt akkor érdemes elolvasni, ha nincs &postscript; nyomtatónk. A Konverziós szûrõk címû szakaszban eláruljuk, miként lehetséges automatizálni a különbözõ állományformátumok és a nyomtatók által érthetõ formátumok közti konverziókat, legyen az grafikus vagy betûszedésre vonatkozó adat. A szakasz elolvasása során megismerjük, hogyan tudjuk a nyomtatónkat képessé tenni az lpr -t paranccsal troff adatok, vagy a lpr -d 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 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) 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 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 behúzás mértéke, ami alapból 0 hozzáférés a nyomtatást végzõ felhasználó hozzáférésének megnevezése gépnév a gép neve, amirõl a nyomtatási munka érkezett nyilvántartás ez a nyilvántartást tároló állomány af tulajdonsággal definiált neve nyomtatás szûrõk A konverziós szûrõk (conversion filter) egy adott állományformátumot hoznak a nyomtató számára értelmes formára. Például ditroff adatok közvetlenül ugyan nem nyomtathatóak, azonban a ditroff állományokhoz tudunk telepíteni egy olyan szûrõt, amely a ditroff adatokat a nyomtató számára is emészthetõ és nyomtatható formájúvá teszi. A Konverziós szûrõk címû szakasz tud ezekrõl többet mondani. Ilyen esetekben kérhetünk nyilvántartást. A konverziós szûrõk az alábbi paraméterekkel indulhatnak: szûrõnév -x pixelszélesség -y pixelmagasság -n hozzáférés -h gépnév nyilvántartás ahol a pixelszélesség a px tulajdonság értékébõl (ami alapból 0), a pixelmagasság a py tulajdonság értékébõl (ami alapból szintén 0) származik. A kimeneti szûrõ (output filter), ami csak akkor aktív, ha a szövegszûrõ nem, vagy ha engedélyeztük fejléclapok nyomtatását. Tapasztalatom szerint az ilyen szûrõket ritkán használják. A Kimeneti szûrõk címû szakasz mutatja be a mûködésüket. Ekkor csupán két paraméterünk van: szûrõnév -w szélesség -l hosszúság amik rendre megegyeznek a szövegszûrõk és paramétereivel. A szûrõk ki is tudnak lépni a következõ kódokkal (exit status): 0 A szûrõ sikeresen kinyomtatta az állományt. 1 A szûrõnek nem sikerült kinyomtatnia az állományt, azonban szeretné, ha az LPD újból megpróbálkozna vele. Az LPD tehát ebben az esetben újraindítja a szûrõt. 2 A szûrõnek nem sikerült kinyomtatnia az állományt, és nem is kívánja újra megpróbálni. Ekkor az LPD eldobja az állományt. A &os; kiadásokban megtalálható /usr/libexec/lpr/lpf szövegszûrõ képes a kapott szélesség és hossz paraméterekkel megállapítani az oldaltöréseket és a nyomtató használatát nyilvántartani, amihez a hozzáférés, gépnév és nyilvántartás adatait használja fel. Amikor majd igyekszünk mellé újabb szûrõket beszerezni, ne felejtsük el ellenõrizni, hogy együtt tudnak-e mûködni az LPD-vel. Ha a válasz igen, akkor a fentebb említett paraméterek mindegyikét ismerniük kell. Az általános használatra készült szûrõk készítése során mi magunknak is be kell tartanunk ezeket az elvárásokat. Szöveges nyomtatási feladatok &postscript; nyomtatókon nyomtatsái munkák Ha csak egyedül dolgozunk a számítógépen és &postscript; (vagy bármilyen más nyelvet ismerõ) nyomtatónk van, valamint megígérjük, hogy soha nem küldünk sem mi, sem pedig nem küldetünk semmilyen más programmal nyers szöveget a nyomtatóra, akkor átléphetjük ezt a szakaszt. Ha viszont egyaránt akarunk küldeni &postscript; programot és nyers szöveget tartalmazó munkákat a nyomtatónak, akkor ehhez kénytelenek vagyunk a rendszerünket beállítani. Elõször is szükségünk van szövegszûrõre, ami megállapítja, hogy a frissen érkezett munka nyers szöveget vagy &postscript; programot tartalmaz-e. Minden &postscript;-alapú feladat a %! karaktersorozattal kezdõdik (a többi esetben olvassuk a nyomtató leírását). Szóval, ha a nyomtatandó állomány elsõ két karaktere ilyen, akkor egy &postscript; programmal van dolgunk és közvetlenül továbbküldhetjük a munkát a nyomtatónak. Minden más esetben a szûrõnek elõbb át kell alakítania a szöveget &postscript; nyelvre. Hogyan érhetjük el mindezt? nyomtató soros Ha soros nyomtatónk van, akkor erre a feladatra az lprps parancs tökéletes. Az lprps egy olyan &postscript; szûrõ, amely mind a két irányban képes közvetíteni. Folyamatosan rögzíti egy állományba a nyomtató állapotát, így a felhasználók és rendszergazdák pontosan látják a nyomtató jelenlegi állapotát (például toner low (a toner hamarosan kifogy) vagy paper jam (a papír beragadt)). Ami viszont sokkal lényegesebb, hogy a psif nevû program képes megmondani az érkezõ munka valódi típusát, és ennek megfelelõen meg tudja hívni nyers szöveg átalakítására a textps (egy másik program, amit a lprps mellé kapunk) parancsot. Ezután az lprps elküldi a feladatot a nyomtatónak. Az lprps a &os; Portgyûjteményének része (lásd A Portgyûjtemény), ezért a használni kívánt papír méretétõl függõen pillanatok alatt magunk is letölhetjük, fordíthatjuk és telepíthetjük a print/lprps-a4 és print/lprps-letter csomagok valamelyikét. Az lprps telepítése után egyszerûen csak adjuk meg a psif elérési útvonalát. Ha tehát telepítettük a Portgyûjteménybõl az lprps csomagot, akkor egy soros portra csatlakozó &postscript; nyomtató esetén ezt kell beírnunk az /etc/printcap állományba: :if=/usr/local/libexec/psif: Ezenkívül még az rw tulajdonsággal meg kell mondanunk az LPD-nek, hogy a nyomtatót írásra és olvasásra nyissa meg. Amennyiben a &postscript; nyomtatónk a párhuzamos porton csatlakozik (és amiért a nyomtatónk nem képes az lprps által igényelt kétirányú kommunikációra), szövegszûrõként a következõ szkriptet fogjuk használni: #!/bin/sh # # psif - PostScript vagy nyers szöveg nyomtatása PostScript nyomtatón # Ez a szkriptes változat, NEM pedig az lprps-hez mellékelt szûrõ # (a /usr/local/libexec/psif állomány)! # IFS="" read -r first_line first_two_chars=`expr "$first_line" : '\(..\)'` if [ "$first_two_chars" = "%!" ]; then # # PostScript: nyomtassuk ki. # echo "$first_line" && cat && printf "\004" && exit 0 exit 2 else # # Nyers szöveg: alakítsuk át, majd nyomtassuk ki. # ( echo "$first_line"; cat ) | /usr/local/bin/textps && printf "\004" && exit 0 exit 2 fi A fentebb szereplõ szkriptben a textps programot használjuk a nyers szövegek &postscript; programokra alakításához, de helyette bármilyen más konvertáló programot is igénybe vehetünk. A &os; Portgyûjteményében (lásd A Portgyûjtemény) találhatunk erre a célra egy a2ps nevû programot is, amit esetleg érdemes lehet közelebbrõl megnéznünk. &postscript; szimulációja nem &postscript; nyomtatókon PostScript emuláció Ghostscript A &postscript; a magas színvonalú betûszedés és nyomtatás de facto szabványa. Emellett azonban a &postscript; egy költséges szabvány is. Az Aladdin Enterprises-nak hála azonban létezik egy hozzá hasonló szabad szoftver, a Ghostscript, amely képes &os;-n is futni. A Ghostscript képes a legtöbb &postscript; állomány olvasására, megjelenítésére mindenféle eszközökön, beleértve a &postscript;et nem ismerõ nyomtatókat is. A Ghostscript és egy speciális szövegszûrõ telepítésével el tudjuk érni, hogy egy nem &postscript; nyomtató valódi &postscript; nyomtatóként viselkedjen. Ha telepíteni szeretnénk, a Ghostscript megtalálható a &os; Portgyûjteményében. Innen tehát magunk is könnyedén le tudjuk tölteni, fordítani és telepíteni. A &postscript; nyomtatás szimulációjához elõször egy szûrõ segítségével észre kell vennünk, hogy egy &postscript; formátumú állományt készülünk kinyomtatni. Ha nem ilyen a nyomtatandó munka, akkor egyenesen a nyomtatóra küldjük, azonban minden más esetben elõször a Ghostscript segítségével átalakítjuk egy olyan formátumba, amit a nyomtató is képes feldolgozni. Nézzünk erre egy példát: a most következõ szövegszûrõ a Hewlett Packard DeskJet 500-as nyomtatóihoz használható. Más nyomtató esetén cseréljük ki a gs (Ghostscript) parancs paraméterét a neki megfelelõre. (A telepített Ghostscript által ismert nyomtatók listáját a gs -h paranccsal kérdezhetjük le.) #!/bin/sh # # ifhp - Ghostscripttel szimulált Postscript nyomtatás DeskJet 500-on # Helye: /usr/local/libexec/ifhp # # LF karaktereket CR+LF-ként kezeljük (elkerülve ezzel a HP/PCL # nyomtatókon a "lépcsõzést"): # printf "\033&k2G" || exit 2 # # Az állomány elsõ két karakterének beolvasása # IFS="" read -r first_line first_two_chars=`expr "$first_line" : '\(..\)'` if [ "$first_two_chars" = "%!" ]; then # # Ez PostScript: küldjük át a Ghostscripten és nyomtassuk ki. # /usr/local/bin/gs -dSAFER -dNOPAUSE -q -sDEVICE=djet500 \ -sOutputFile=- - && exit 0 else # # Nyers szöveg vagy HP/PCL, ezért küldjük át közvetlenül. Az utolsó # lap kidobásához küldünk még egy lapdobást is. # echo "$first_line" && cat && printf "\033&l0H" && exit 0 fi exit 2 Befejezésül az if tulajdonságon keresztül értesítenünk kell errõl a szûrõrõl az LPD-t is: :if=/usr/local/libexec/ifhp: Készen is vagyunk! Most már nyugodtan - beírhatjuk, hogy lpr - sima.szöveg vagy - lpr - akármi.ps, mind a - kettõnek ki kell tudnia nyomtatódnia. + beírhatjuk, hogy + lpr sima.szöveg vagy + lpr akármi.ps, + mind a kettõnek ki kell tudnia + nyomtatódnia. Konverziós szûrõk Miután elvégeztük az Alacsonyszintû nyomtatóbeállítás címû szakaszban leírt beállításokat, a (nyers ASCII szöveg mellett) kedvenc állományformátumainkhoz is minden bizonnyal szeretnénk telepíteni néhány konverziós szûrõt. Miért használjunk konverziós szûrõket? &tex; DVI állományok nyomtatása A konverziós szûrõk segítségével állományok mindenféle formátumait könnyen ki tudjuk nyomtatni. Például tegyük fel, hogy a sokat dolgozunk a &tex; betûszedõ rendszerrel és egy &postscript; nyomtatónk van. Minden alkalommal, amikor egy DVI állományt hozunk létre a &tex; forrásból, azt közvetlenül még nem tudjuk a nyomtatóra küldeni. Ehhez a következõ parancsokat kell kiadnunk: &prompt.user; dvips hínár-elemzés.dvi &prompt.user; lpr hínár-elemzés.ps Ha telepítünk egy konverziós szûrõt a DVI állományokhoz, meg tudjuk spórolni ezt a manuális átalakítási lépést azzal, hogy átadjuk ezt a feladatot az LPD-nek. Így ezután mindig, amikor egy DVI állományt akarunk kinyomtatni, csupán egyetlen lépésre lesz szükségünk: &prompt.user; lpr -d 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 á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 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: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:\ :lp=/dev/ttyd5:ms#-parenb cs8 clocal crtscts:rw:\ :if=/usr/local/libexec/psif:\ :df=/usr/local/libexec/psdf: A DVI szûrõ ebben az esetben a /usr/local/libexec/psdf néven elérhetõ aprócska szkript. Ezt találhatjuk benne: #!/bin/sh # # psdf - DVI szûrõ PostScript nyomtatóhoz # Helye: /usr/local/libexec/psdf # # Az lpr -d parancs hatására hívódik meg # exec /usr/local/bin/dvips -f | /usr/local/libexec/lprps "$@" A szkript a dvips parancsot szûrõként futtatja (az paraméterrel) a szabványos bemenetrõl, ahova a nyomtatási munkát is kapja. Ezután elindítja az lprps &postscript; szûrõt (lásd a Szöveges nyomtatási feladatok &postscript; nyomtatókon címû szakaszt) az LPD által átadott paraméterekkel. Az lprps parancs ezekkel a paraméterekkel tartja nyilván az így kinyomtatott lapokat. További példák konverziós szûrõkre A konverziós szûrõk telepítésének nincs bevált receptje, ezért ebben a szakaszban bemutatunk rájuk néhány mûködõ illusztrációt. Ezeket tudjuk felhasználni saját szûrõk elkészítésére. Vagy ha megtehetjük, használjuk közvetlenül ezeket. Ebben a példa szkriptben Hewlett Packard LaserJet III-Si nyomtatókhoz hozunk létre raszteres (pontosabban GIF formátumú) konverziós szûrõt: #!/bin/sh # # hpvf - GIF állományokat konvertál át HP/PCL-be, majd kinyomtatja # Helye: /usr/local/libexec/hpvf PATH=/usr/X11R6/bin:$PATH; export PATH giftopnm | ppmtopgm | pgmtopbm | pbmtolj -resolution 300 \ && exit 0 \ || exit 2 Úgy mûködik, hogy a GIF állományt elõször PNM (portable anymap), utána PGM (portable graymap), majd PBM (portable bitmap) formátumúra alakítja, amibõl végül LaserJet/PCL-kompatibilis adat lesz. Ez lesz a hozzátartozó /etc/printcap állomány: # # /etc/printcap (orchid) # teak|hp|laserjet|Hewlett Packard LaserJet 3Si:\ :lp=/dev/lpt0:sh:sd=/var/spool/lpd/teak:mx#0:\ :if=/usr/local/libexec/hpif:\ :vf=/usr/local/libexec/hpvf: A most következõ szkript a groff betûszedû rendszerbõl érkezõ troff adatokat alakítja át a bamboo nevû &postscript; nyomtató számára: #!/bin/sh # # pstf - a groff troff adait alakítja PS-re, majd kinyomtatja # Helye: /usr/local/libexec/pstf # exec grops | /usr/local/libexec/lprps "$@" A szkript az lprps parancs segítségével kommunikál a nyomtatóval. Ha a nyomtatónk párhuzamos porton csatlakozik, akkor helyette ezt a szkriptet használjuk: #!/bin/sh # # pstf - a groff troff adatait alakítja PS-re, majd kinyomtatja # Helye: /usr/local/libexec/pstf # exec grops Kész is! A szûrõ éltrekeltéséhez mindössze ennyit kell beillesztenünk az /etc/printcap állományba: :tf=/usr/local/libexec/pstf: Most pedig jöjjön a FORTRAN szerelmeseinek szívét megmelengetõ szkript. Ez egy olyan szövegszûrõ, amely bármelyik nyers szöveget közvetlenül kezelni tudó nyomtató esetén mûködik. A teak nevû nyomtatóhoz helyezzük be: #!/bin/sh # # hprf - FORTRAN szövegszûrõ LaserJet 3si-hez # Helye: /usr/local/libexec/hprf # printf "\033&k2G" && fpr && printf "\033&l0H" && exit 0 exit 2 Az /etc/printcap állományban a teak nyomtatóhoz a következõ sor beírásával tudjuk engedélyezni ezt a szûrõt: :rf=/usr/local/libexec/hprf: Most pedig következzen egy utolsó, de az eddigieknél valamivel összetettebb példa. Ebben a korábban bemutatott teak nevû LaserJet nyomtatóhoz fogunk hozzáadni egy DVI szûrõt. Elõször is következzen a mûvelet egyszerûbb része: bõvítsük ki az /etc/printcap állományt a DVI szûrõ helyének megadásával: :df=/usr/local/libexec/hpdf: Ezután következzék a nehezebb rész: a szûrõ elkészítése. Ehhez szükségünk lesz egy DVI-rõl LaserJet/PCL-re alakító programra. A &os; Portgyûjteményében (lásd A Portgyûjtemény) találunk is egyet: a csomag neve print/dvi2xx. A csomag telepítésével megkapjunk a nekünk kellõ dvilj2p programot, ami képes DVI-t LaserJet IIp, LaserJet III és a LaserJet 2000 típusok által ismert kódokra fordítani. A dvilj2p felhasználásától függetlenül a hpdf néven létrehozni kívánt szûrõnk még így is bonyolult lesz, hiszen a dvilj2p nem tud olvasni a szabványos bemenetrõl, hanem minden áron egy állománnyal akar dolgozni. Sõt, olyan állománnyal, amelynek .dvi kiterjesztése van, ezért még a /dev/fd/0 (vagyis a szabványos bemenethez tartozó eszközleíró) használata is akadályokba ütközik. Üröm még az örömünkben, hogy a /tmp könyvtárat sem tudjuk felhasználni ideiglenes link létrehozására: a szimbolikus linkeket a bin felhasználó és csoport birtokolja, a szûrõt pedig a daemon felhasználó futtatja. A /tmp könyvtárban rááadásul csak a tulajdonosaik képesek állományokat átnevezni vagy törölni (sticky bit). Ezért a szûrõ ugyan létre tudna hozni egy linket, azonban ezt a munkája végeztével nem lesz majd képes törölni, mivel a link egy másik felhasználóhoz tartozik. Ezért a szûrõ az aktuális könyvtárban fogja létrehozni ezt a szimbolikus linket, ami jelen esetünkben a nyomtatási rendszer által használt könyvtár lesz (ezt az /etc/printcap állomány sd tulajdonságával adjuk meg). Itt remekül el tudják végezni a feladataikat a szûrõk, különösen mivel (néha) több hely van itt, mint a /tmp könyvtárban. Végül lássuk magát a szûrõt: #!/bin/sh # # hpdf - DVI adat nyomtatása HP/PCL nyomtatón # Helye: /usr/local/libexec/hpdf PATH=/usr/local/bin:$PATH; export PATH # # Létrehozunk egy függvényt az átmeneti állományok törlésére. Ezek # az aktuális könyvtárban jönnek létre, ami pedig a nyomtatási # rendszer adott nyomtatóhoz tartozó könyvtára lesz. # cleanup() { rm -f hpdf$$.dvi } # # Létrehozunk egy függvényt a súlyos hibák kezelésére: írassunk ki # egy adott üzenetet és lépjünk ki a 2-es hibakóddal. Ezzel üzenünk # az LPD-nek, hogy ne nyomtatassa újra a munkát. # fatal() { echo "$@" 1>&2 cleanup exit 2 } # # Ha a felhasználó eltávolítja a munkát a sorból, akkor az LPD egy SIGINT # jelzést fog küldeni, ezért próbáljuk meg azt elkapni (néhány más egyéb # jelzéssel együtt), így még tudjuk törölni az ideiglenesen # létrehozott állományokat. # trap cleanup 1 2 15 # # Gondoskodjunk róla, hogy a feladat megkezdésekor még egyetlen # használt állomány sem létezik. # cleanup # # Kössük össze a szabványos bemenetet egy DVI állománnyal (amit # majd nyomtatni akarunk). # ln -s /dev/fd/0 hpdf$$.dvi || fatal "Cannot symlink /dev/fd/0" # # LF = CR+LF # printf "\033&k2G" || fatal "Cannot initialize printer" # # Alakítsuk át az adatot és nyomtassunk. A dvilj2p által visszaadott érték # nem túlságosan megbízható, ezért ne is foglalkozzunk vele. # dvilj2p -M1 -q -e- dfhp$$.dvi # # Takarítsunk el magunk után és lépjünk ki szabályosan # cleanup exit 0 Automatikus konverziók: a konverziós szûrõk helyett A konverziós szûrõk sokat segítenek egy kényelmes nyomtatási környezet kialakításában, azonban a használatukhoz a felhasználóknak (az &man.lpr.1; parancson keresztül) egyenként hivatkozniuk kell rájuk. Ha a rendszerünk felhasználói nem eléggé mûveltek számítástechnikai téren, akkor még egy szûrõ megadása is zavaró lehet számukra. Ami még ennél is rosszabb, hogy egy rosszul megadott szûrõ hatására a nyomtató sem fogja jól kezelni az adott állomány formátumát és erre válaszul akár többszáz lapot is pillanatok alatt kiköphet magából. A konverziós szûrõk telepítése helyett gyakran csak egy (alapértelmezett) szövegszûrõre van szükségünk, amely kideríti a nyomtatandó állomány pontos formátumát és magától elindítja a neki megfelelõ konverziós szûrõt. Ilyen esetekben például a file parancs pont a hasznunkra válhat. Persze bizonyos állománytípusok közt nagyon nehéz különbséget tenni — de ezekre továbbra is adhatunk még külön konverziós szûrõket. apsfilter nyomtatás szûrõk apsfilter A &os; Portgyûjteményében találhatunk egy apsfilter elnevezésû szövegszûrõt (print/apsfilter), ami képes ilyen automatikus konverzióra. Képes felismerni a nyers szöveget, &postscript; programokat, DVI és szinte bármilyen formátumú állományokat, lefuttatni rájuk a megfelelõ átalakítástokat, majd kinyomtatni ezeket. Kimeneti szûrõk Az LPD nyomtatási rendszer kezel egy eddig még nem tárgyalt szûrõtípust is: ez a kimeneti szûrõ. A kimeneti szûrõ a szövegszûrõhöz hasonlóan csak nyers szöveg nyomtatására használatos, de tartalmaz néhány egyszerûsítést. Ha kizárólag csak kimeneti szûrõket alkalmazunk, akkor: Az LPD az egész nyomtatási feladathoz egyetlen kimeneti szûrõt fog használni, nem pedig minden állományhoz külön. Az LPD a kimeneti szûrõ számára nem nyújt semmilyen segítséget a munkán belül szereplõ állományok kezdetének vagy végének megállapításában. Az LPD a szûrõnek nem adja át sem a felhasználó hozzáférését, sem pedig gépnevét, ezért nyilvántartásra nem alkalmas. Mindent összegezve lényegében csak két paramétert kap meg: szûrõnév -wszélesség -lhossz ahol a szélesség a kérdéses nyomtató pw tulajdonságából, a hossz pedig a pl tulajdonságából származik. Ne bûvöljön el minket a szûrõ egyszerûsége! Ha például a munkában minden állományt újabb lapon szeretnénk kezdeni, akkor azt kimeneti szûrõvel nem tudjuk megoldani. Erre a célra használjunk szövegszûrõt (másik nevén bemeneti szûrõt), lásd A szövegszûrõ telepítése szakaszt. Hovatovább, a kimeneti szûrõ valójában sokkal bonyolultabb abban a tekintetben, hogy a beérkezõ adatok közül neki kell kikeresnie a speciális jelentéssel bíró karaktereket ugyanúgy, ahogy az LPD helyett saját magának kell küldenie a jelzéseket. Azonban a kimeneti szûrõk használata elkerülhetetlen, ha például fejléclapokat akarunk nyomtatni, és esetleg még különbözõ inicializálásra használatos speciális kódokat vagy karakterláncokat akarunk ez elõtt kiküldeni. (Ellenben badarság a fejléclapoktól követelni a felhasználó adatait, hiszen az LPD a kimeneti szûrõnek nem ad semmilyen erre vonatkozó információt.) Egyetlen nyomtató esetén az LPD egyaránt lehetõvé teszi kimeneti, szöveg- és más egyéb szûrõk használatát. Ilyenkor az LPD a kimeneti szûrõn keresztül csak a fejlécet tartalmazó oldal (lásd a Fejléclapok szakaszt) nyomtatását indítja el. Ezt követõen az LPD arra számít, hogy a kimeneti szûrõ két karakter, az ASCII 031 és az ezt követõ ASCII 001, hatására leállítja magát. Amikor tehát a kimeneti szûrõ érzékeli ezt a két karaktert (031, 001), akkor a SIGSTOP jelzéssel le kell állnia. Miután az LPD lefuttatta a többi szûrõt, a SIGCONT jelzéssel újraindítja a kimeneti szûrõt. Ha van kimeneti szûrõnk, de nincs szövegszûrõnk, akkor az LPD minden további feldolgozás nélkül továbbadja a munkát a kimeneti szûrõnek. Ahogy már korábban is említettük, a kimeneti szûrõ a munkában levõ összes állományt egymás után nyomtatja ki, lapdobások vagy bármilyen más papírmozgatás nélkül, ezért valószínûleg nem ez kell nekünk. Az esetek túlnyomó részében ehhez elég egy szövegszûrõ. A korábban szövegszûrõként beharangozott lpf program kimeneti szûrõként is képes funkcionálni. Ha szükségünk lenne egy gyorsan összecsapható kimeneti szûrõre, és nem akarunk a speciális karakterek valamint a jelzések küldésével elidõzni, akkor próbálkozzunk az lpf használatával. Az lpf parancsot mellesleg becsomagolhatjuk egy olyan szkriptbe is, amely elvégzi a nyomtató számára szükséges inicializálást. Az <command>lpf</command> szövegszûrõ A &os; bináris terjesztéséhez mellékelt /usr/libexec/lpr/lpf program egy szövegszûrõ (bemeneti szûrõ), amely képes (az lpr -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 elõforduló törlések és behúzások nyomtatási pozícióját igazítani és nyilvántartani a kinyomtatott lapokat. Kimeneti szûrõként is tud viselkedni. Az lpf szûrõ rengeteg nyomtatási környezetben felhasználható. Habár nem képes a nyomtatónak inicializáló jelsorozatokat küldeni, mégis könnyû olyan szkriptet írni, amely elvégzi ezeket a hiányzó kezdeti beállításokat, majd lefuttatja az lpf szûrõt. oldalak nyilvántartása nyilvántartás nyomtató Az lpf akkor lesz képes helyesen számolni a kinyomtatott lapokat, ha ehhez az /etc/printcap állományban jól töltjük ki a pw és pl tulajdonságokat. Ezen értékek segítségével határozható meg ugyanis, hogy mennyi szöveg fért rá egy lapra és így mennyi lapot emésztett fel az adott felhasználó által küldött munka. A nyomtatás nyilvántartásával kapcsolatban A nyomtató használatának nyilvántartása címû szakaszt érdemes elolvasni. Fejléclapok Ha nagyon sok felhasználónk van, és sok különbözõ nyomtatót is használnak, akkor elõbb vagy utóbb minden bizonnyal elkerülhetetlenné fog válni a fejléclapok használata. munkalapok fejléclapok fejléclapok A fejléc-, vagy más néven munka vagy elválasztó lapok segítik elõ a kinyomtatott munkák azonosítását. A többi dokumentumtól kirívó módon, általában dekoratív keretben, nagy, vastag betûkkel nyomtatódnak ki, hogy a halomnyi papír között a felhasználók könnyedén megtalálhassák az elküldött munkáik eredményét. Természetesen a fejléclapok nyilvánvaló hátulütõje, hogy így minden munkához még egy lappal többet kell elhasználni és mivel gyakorlatilag néhány percnél tovább nincs is rájuk szükség, meglehetõsen hamar a kukába kerülnek. (A fejléclapok munkánként jönnek létre, nem pedig az munkákban levõ állományokhoz egyenként, ezért nem is akkora pazarlás ez.) Az LPD rendszer képes magától fejléclapokat készíteni a nyomtatásokhoz, amennyiben a nyomtatónk képes közvetlenül nyers szöveget nyomtatni. Ha &postscript; nyomtatónk van, akkor ennek legyártásához egy külsõ programra van szükségünk, lásd a Fejléclapok &postscript; nyomtatókon szakaszt. A fejléclapok engedélyezése Az Alacsonyszintû nyomtatóbeállítás címû szakaszban az /etc/printcap állományban a sh (úgy mint suppress header) tulajdonsággal kikapcsoltuk a fejléclapokat. A fejléclapok engedélyezéséhez mindösszesen el kell távolítanunk ezt az sh tulajdonságot. Ez túl egyszerû, nemde? Igen, ez így van. Elõfordulhat, hogy szükségünk van még egy olyan kimeneti szûrõre is, amely inicializáló karaktereket küld a nyomtatónak. Íme egy példa ehhez a Hewlett Packard PCL-kompatibilis nyomtatói esetére: #!/bin/sh # # hpof - Kimeneti szûrõ Hewlett Packard PCL-kompatibilis nyomtatókhoz # Helye: /usr/local/libexec/hpof printf "\033&k2G" || exit 2 exec /usr/libexec/lpr/lpf Az of tulajdonsággal adjuk meg a kimeneti szûrõt. A Kimeneti szûrõk szakaszban errõl részletesebben is olvashatunk. A korábban ismertetett teak nevû nyomtatóhoz most az alábbi minta /etc/printcap állományt mellékeljük. Itt engedélyeztük a fejléclapokat és hozzátettük az iménti kimeneti szûrõt: # # /etc/printcap (orchid) # teak|hp|laserjet|Hewlett Packard LaserJet 3Si:\ :lp=/dev/lpt0:sd=/var/spool/lpd/teak:mx#0:\ :if=/usr/local/libexec/hpif:\ :vf=/usr/local/libexec/hpvf:\ :of=/usr/local/libexec/hpof: Mostantól kezdve, amikor a felhasználók a teak nyomtatón akarnak nyomtatni, minden munkához kapni fognak egy fejléclapot. Amennyiben a kedves felhasználók mégis keresgetni akarják a nyomtatásaikat, az lpr -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 szakaszban találjuk. Az LPD minden fejléclap után egy lapdobást küld. Ha erre a célra a nyomtatónk egy eltérõ karaktert vagy karaktersorozatot használ, akkor azt az /etc/printcap állomány ff tulajdonságával határozhatjuk meg. A fejléclapok vezérlése A fejléclapok engedélyezésével az LPD egy ún. hosszú fejlécet fog készíteni, vagyis a felhasználót, gépet és a munkát jól azonosító, egész lapot kitöltõ óriási betûket. Erre egy példa (amiben a rose nevû géprõl kelly nyomtatta ki az outline elnevezésû munkát): k ll ll k l l k l l k k eeee l l y y k k e e l l y y k k eeeeee l l y y kk k e l l y y k k e e l l y yy k k eeee lll lll yyy y y y y yyyy ll t l i t l oooo u u ttttt l ii n nnn eeee o o u u t l i nn n e e o o u u t l i n n eeeeee o o u u t l i n n e o o u uu t t l i n n e e oooo uuu u tt lll iii n n eeee r rrr oooo ssss eeee rr r o o s s e e r o o ss eeeeee r o o ss e r o o s s e e r oooo ssss eeee Job: outline Date: Sun Sep 17 11:04:58 1995 Ezt követõen az LPD elküld még egy lapdobást is, ezért maga a munka egy új oldalon fog kezdõdni (kivéve, ha az /etc/printcap állományban az adott nyomtatóhoz tartozó bejegyzésben megadtuk az sf (úgy mint suppress form feeds, vagyis a lapdobások letiltása) tulajdonságot. Ha úgy jobban tetszik, akkor az /etc/printcap állományban a sb tulajdonsággal az LPD utasítható rövid fejlécek készítésére is. Ilyenkor a fejléclap tartalma mindössze ennyi lesz: rose:kelly Job: outline Date: Sun Sep 17 11:07:51 1995 Alapértelmezés szerint az LPD elõször a fejléclapot majd a munkát nyomtatja ki. Ezt a sorrendet az /etc/printcap állományban a hl (header last) tulajdonsággal meg tudjuk fordítani. A nyomtató használatának nyilvántartása Az LPD által felkínált fejléclapok használata során egyetlen irányelv érvényesül a nyilvántartásukban: a fejléclapok költségmentesek. De miért? Azért, mert kizárólag csak a kimeneti szûrõ képes a fejléclapok viselkedését irányítani, ami viszont nem képes semmiféle nyilvántartásra, hiszen nem kapja meg az ehhez szükséges felhasználói- vagy gépnév információkat, illetve nyilvántartásokat. Emiatt fogalma sincs róla, hogy kit terhel az adott nyomtató használata. Úgy sem tudjuk megoldani a problémát, ha a szöveg- vagy konverziós szûrõkben (ahol már rendelkezésünkre állnak a felhasználó és a gépének adatai) hozzátoldunk még egy lapot a munkához, mivel a felhasználók az lpr -h 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 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. 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. Ha soros &postscript; nyomtatónk van, akkor használhatjuk a psof kimeneti szûrõhöz tartozó lprps parancsot is, ami pontosan az elõbbit végzi el. Hozzátennénk azonban, hogy a psof nem számolja a fejléclapokat. Hálózati nyomtatás nyomtató hálózati hálózati nyomtatás A &os; tud hálozaton is nyomtatni, vagyis tud távoli számítógépeknek is nyomtatási munkát küldeni. A hálózati nyomtatás kifejezés általánosságban véve két különbözõ dolgra utalhat: Egy távoli számítógéphez kapcsolt nyomtató hozzáférését. A géphez a nyomtató a hagyományos soros vagy párhuzamos csatolófelületen keresztül kapcsolódik, amit aztán az LPD alkalmas beállításával a hálózaton mindenki számára elérhetõvé teszünk. A Távoli számítógépekre csatlakoztatott nyomtatók címû szakasz errõl szól. Egy közvetlenül a hálózatra kapcsolt nyomtató hozzáférését. A nyomtató tehát rendelkezik még egy hálózati csatlakozással is a hagyományos soros vagy párhuzamos felület mellett (vagy éppen helyett). Egy ilyen nyomtató a következõképpen mûködhet: Elfogadja az LPD kéréseit, és még képes munkákat is tárolni. Ebben az esetben teljesen egyenértékû egy LPD alkalmazást futtató számítógéppel. Ekkor nincs más teendõnk, csak követnünk kell a Távoli számítógépeken telepített nyomtatók címû szakasz utasításait. Hálózati adatfolyamokkal dolgozik. Ebben az esetben a nyomtatót hozzá kell kapcsolnunk a hálózaton található egyik számítógéphez, ami majd a munkák tárolásáért és folyamatos küldéséért lesz felelõs. A Nyomtatók hálózati adatcsatlakozással szakasz az ilyen fajtájú nyomtatók telepítésére tesz néhány javaslatot. Távoli számítógépekre csatlakoztatott nyomtatók Az LPD nyomtatási rendszer alapból képes más, szintén LPD-t (vagy vele kompatibilis rendszert) futtató számítógépekre munkákat küldeni. Ezzel lényegében az egyik géphez hozzá tudunk kapcsolni egy nyomtatót, amit aztán a többiek számára elérhetõvé teszünk. Ez olyan nyomtatók esetében is mûködik, amelyek ismerik az LPD által alkalmazott protokollt. A távoli nyomtatáshoz elõször telepítsük a nyomtatót valamelyik számítógépre az Alacsonyszintû nyomtatóbeállítás szakaszban leírtak szerint, és ezzel az lesz a nyomtatószerverünk. Ezután, amennyiben szükségesnek találjuk, végezzünk magasabb szintû nyomtatóbeállításokat is. Ne felejtsük el kipróbálni a nyomtatón, hogy rendesen mûködik az LPD mindegyik olyan beállításával, amit engedélyeztünk. Emellett gondoskodjunk minden olyan jogosultságról is, amivel a helyi számítógéprõl el tudjuk érni a távoli számítógép által felkínált LPD szolgáltatást (lásd Távoli számítógépekrõl érkezõ kérések szabályozása). nyomtató hálózati hálózati nyomtatás Ha olyan nyomtatót használunk, aminek a hálózati felülete kompatibilis az LPD rendszerrel, akkor az elõbb említett nyomtatószerver lényegében maga lesz a nyomtató, valamint a nyomtató neve a rajta beállított név. Ezzel kapcsolatban olvassuk el a nyomtatóhoz és/vagy a hálózati csatolójához mellékelt dokumentációt. Amikor a Hewlett Packard Laserjet típusú nyomtatóit használjuk, a text nevû nyomtatónév magától elvégzi a LF és CRLF formátumú sortörések közti átalakítást, ezért ilyenkor nincs szükségünk a hpif szkriptre. Ezután ha szeretnénk más gépek részére is elérhetõvé tenni a frissen telepített nyomtatónkat, adjuk meg mindegyikük /etc/printcap állományában a következõket: Tetszõlegesen választott nevet, álneveket. Az egyszerûség kedvéért azonban itt érdemes ugyanazokat a neveket választani, mint amit a nyomtatószerveren is használunk. Szándékosan hagyjuk az lp tulajdonságot üresen (:lp=:). Hozzunk létre egy nyomtatási könyvtárat, és jelöljük meg a helyét az sd tulajdonsággal. Az LPD itt fogja összegyûjteni a munkákat, mielõtt elküldené azokat a nyomtatószervernek. Adjuk meg a nyomtatószerver nevét az rm tulajdonság segítségével. Az rp tulajdonsággal adjuk meg a nyomtatószerverre csatlakoztatott nyomtató nevét. Kész! Az /etc/printcap állományban már nem kell megadni konverziós szûrõket, oldalbeállításokat és semmi más egyebet. Lássunk mindezekre egy példát. A rose nevû számítógéphez két nyomtató csatlakozik, a bamboo és a rattan. Most pedig beállítjuk, hogy az orchid nevû gép felhasználói képesek legyenek ezekkel a nyomtatókkal dolgozni. Ekkor a most következõk szerint fog kinézni az orchid (a Fejléclapok engedélyezése szakaszban bemutatott) /etc/printcap állománya. Tartalmazza a teak nevû nyomtató beállításait is, és ehhez fogjuk hozzáadni a rose másik két nyomtatóját: # # /etc/printcap (orchid) - a rose két (távoli) nyomtatójának # hozzáadása # # # A "teak" egy helyi nyomtató, közvetlenül az orchidhoz # csatlakozik: # teak|hp|laserjet|Hewlett Packard LaserJet 3Si:\ :lp=/dev/lpt0:sd=/var/spool/lpd/teak:mx#0:\ :if=/usr/local/libexec/ifhp:\ :vf=/usr/local/libexec/vfhp:\ :of=/usr/local/libexec/ofhp: # # A "rattan" rose-hoz csatlakozik, így küldhetünk neki munkát: # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :lp=:rm=rose:rp=rattan:sd=/var/spool/lpd/rattan: # # A "bamboo" is a rose-hoz tartozik: # bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :lp=:rm=rose:rp=bamboo:sd=/var/spool/lpd/bamboo: Ezután más csak létre kell hoznunk a megfelelõ nyomtatási könyvtárakat az orchid nevû gépen: &prompt.root; mkdir -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 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 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õ összes állományból öt példányt kap. Ennek létjogosultságát azonban nekünk kell megítélni. Amennyiben úgy érezzük, hogy a további példányok készítése csupán felesleges papír- és tintapazarlás, akkor az sc tulajdonság megadásával az /etc/printcap állományban kikapcsolhatjuk az &man.lpr.1; lehetõség használatát. Így amikor a felhasználók a kapcsolóval küldenek el munkákat a nyomtatóra, a következõt fogják tapasztalni: lpr: multiple copies are not allowed Fordítása: lpr: másolatok nyomtatása nem engedélyezett Vigyázzunk arra, hogy ha távoli számítógépen zajlik a nyomtatás (lásd Távoli számítógépekre csatlakoztatott nyomtatók), akkor az sc tulajdonságot a távoli számítógép /etc/printcap állományában is be kell állítani, máskülönben a felhasználók egy másik számítógéprõl mindig képesek lesznek több példány nyomtatására. Nézzünk erre egy példát. Itt most a rose nevû számítógép /etc/printcap állományát vesszük szemügyre. Ebben a rattan egy nagyon szívélyes nyomtató lesz, ezért engedélyezi a másolatok nyomtatását, azonban a bamboo nevû lézernyomtató nála már sokkal válogatósabb lesz, ezért a beállításai közt az sc tulajdonsággal kikapcsoljuk a másodpéldányok nyomtatását: # # /etc/printcap (rose) - A másolatok korlátozása a "bamboo" # nevû nyomtatón # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0:\ :if=/usr/local/libexec/if-simple: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:sc:\ :lp=/dev/ttyd5:ms#-parenb cs8 clocal crtscts:rw:\ :if=/usr/local/libexec/psif:\ :df=/usr/local/libexec/psdf: Az sc tulajdonságot az orchid /etc/printcap állományában is meg kell adni (és ha már itt vagyunk, akkor tegyük meg ugyanezt a teak esetében is): # # /etc/printcap (orchid) - Nincsenek másodpéldányok sem a helyi # "teak" nyomtatón, sem pedig a távoli "bamboo" nyomtatón teak|hp|laserjet|Hewlett Packard LaserJet 3Si:\ :lp=/dev/lpt0:sd=/var/spool/lpd/teak:mx#0:sc:\ :if=/usr/local/libexec/ifhp:\ :vf=/usr/local/libexec/vfhp:\ :of=/usr/local/libexec/ofhp: rattan|line|diablo|lp|Diablo 630 Line Printer:\ :lp=:rm=rose:rp=rattan:sd=/var/spool/lpd/rattan: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :lp=:rm=rose:rp=bamboo:sd=/var/spool/lpd/bamboo:sc: Az sc tulajdonság használatával ugyan megakadályozzuk az lpr -# parancs teljesítését, azonban ez még mindig nem óv minket attól, hogy a felhasználók képesek legyenek többször egymás után lefuttatni az &man.lpr.1; parancsot, vagy éppen egyetlen munkában több állományt is elküldeni: &prompt.user; lpr forsale.sign forsale.sign forsale.sign forsale.sign forsale.sign Számos módszer kínálkozik az effajta visszaélések kivédésére (beleértve a figyelmen kívül hagyást is), lehet velük kísérletezgetni! A nyomtatók hozzáférésének szabályozása A &unix; csoportkezelésével és az /etc/printcap állományban található rg tulajdonság felhasználásával korlátozni tudjuk, ki milyen nyomtatón dolgozhat. Ehhez mindösszesen annyit kell tennünk, hogy besoroljuk egy csoportba azokat a felhasználókat, amelyek hozzáférhetnek a nyomtatóhoz, és az rg tulajdonsággal megnevezzük azt. A csoporton kívüli felhasználókat (köztük magát a root felhasználót is) pedig ezután így üdvözli a rendszer, ha megpróbálnak valamit kinyomtatni egy korlátozott felhasználású nyomtatón: lpr: Not a member of the restricted group Az üzenet fordítása: lpr: Nem jogosult felhasználó Ha erre a távoli számítógépek esetén szükségünk lenne (lásd Távoli számítógépekre csatlakoztatott nyomtatók), akkor tegyük ugyanazt, mint amit az sc (a másodpéldányok letiltása, suppress multiple copies) tulajdonság esetén is, vagyis az rg tulajdonságot adjuk meg azokon a távoli számítógépeken is, amelyek hozzá tudnak férni a megosztott nyomtatóhoz. Például megengedjük, hogy a rattan nevû nyomtatót bárki használhassa, azonban a bamboo nyomtatón csak az artists nevû csoport használhatja. Következzen hát akkor a rose korábbról már ismert /etc/printcap állománya: # # /etc/printcap (rose) - A bamboo hozzáférésének korlátozása # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0:\ :if=/usr/local/libexec/if-simple: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:sc:rg=artists:\ :lp=/dev/ttyd5:ms#-parenb cs8 clocal crtscts:rw:\ :if=/usr/local/libexec/psif:\ :df=/usr/local/libexec/psdf: Most ne bántsuk a másik (az orchid nevû gépen levõ) /etc/printcap állományt. Így persze az orchid bármelyik felhasználója nyomtathat a bamboo nyomtatón. De ez most egy olyan eset, ahol egyébként lekorlátozzuk a orchid elérését is, ezért az ott beengedett felhasználók már akár használhatják is a nyomtatót. Vagy sem. Minden nyomtatóhoz csak egy ilyen csoportot adhatunk meg. A beküldött munkák méretének szabályozása nyomtatási munkák Ha sok felhasználó szeretne a nyomtatóinkhoz hozzáférni, akkor minden bizonnyal meg akarunk adni egy felsõ határt a felhasználók által beküldhetõ nyomtatások méretére vonatkozóan. Mivel a nyomtatási könyvtáraknak otthont adó állományrendszer is egyszer betelhet, ezért mindenképpen érdemes gondoskodni arról, hogy mindenki munkáját el tudjuk rendesen tárolni. nyomtatási munkák szabályozása Az LPD az mx tulajdonsággal lehetõséget ad arra, hogy lekorlátozzuk a munkákban található egyes állományok méretét. Ennek mértékegysége egy BUFSIZ blokk, ami pedig 1024 byte. Ha értékül nullát adunk meg, akkor nincs korlátozás, viszont ha semmit sem rögzítünk, akkor az mx tulajdonság alapértéke, vagyis 1000 blokk lesz a határ. Ez az érték a munkákban levõ egyes állományok méretére vonatkozik, nem pedig a munkák teljes méretére. Fontos tudni, hogy az LPD nem dobja vissza a méreten felüli állományokat. Ehelyett a méret alatti részt szépen berakja a sorba és kinyomtatja, a többi pedig elhagyja. Lehetne rajta vitázni, hogy ez mennyire helyes cselekedet. Példaképpen definiáljunk a korábban használt rattan és bamboo nyomtatóinkhoz ilyen korlátokat. Mivel az artists csoport tagjai hajlamosak nagy &postscript; állományokat küldeni, ezért most lekorlátozzuk ezt öt megabyte-ra. A szöveges nyomtatónk esetén azonban nem lesz semmilyen határ: # # /etc/printcap (rose) # # # Itt nincs korlát a munkákra: # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:mx#0:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0:\ :if=/usr/local/libexec/if-simple: # # Öt megabyte a PostScript: # bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:sc:rg=artists:mx#5000:\ :lp=/dev/ttyd5:ms#-parenb cs8 clocal crtscts:rw:\ :if=/usr/local/libexec/psif:\ :df=/usr/local/libexec/psdf: Ismét hozzátesszük, hogy ezek a korlátok csak a helyi felhasználókra vonatkoznak. Amennyiben távolról is el lehet érni ezt a nyomtatót, a távoli felhasználókat nem fog semmilyen korlátozás érinteni. Azokon a számítógépeken is meg kell adnunk az /etc/printcap állományban az mx tulajdonságot. Ehhez a Távoli számítógépekre csatlakoztatott nyomtatók címû szakaszban találunk segítséget. Van még egy speciális módszer, amivel képesek vagyunk szabályozni a távolról érkezõ kérések méretét. Errõl a Távoli számítógépekrõl érkezõ kérések szabályozása szakaszban olvashatunk. Távoli számítógépekrõl érkezõ kérések szabályozása Az LPD nyomtatási rendszer több módot is szolgáltat a távolról érkezõ nyomtatási munkák szabályozására: Az elérés szabályozása Az /etc/hosts.equiv és /etc/hosts.lpd állományok segítségével beállíthatjuk, hogy mely távoli számítógépektõl fogadjon el kéréseket az LPD. Az LPD minden kérés elfogadásakor ellenõrzi, hogy a küldõ számítógép címe szerepel-e az említett állományok valamelyikében. Ha nem, akkor az LPD visszautasítja a kérést. A két állomány felépítése egyszerû, mert bennük minden sorban egy-egy hálózati nevet adunk meg. Hozzátennénk azonban, hogy legyünk óvatosak, mivel az /etc/hosts.equiv állományt az &man.ruserok.3; protokoll is használja, ezért ennek módosítása hatással van az &man.rsh.1; és &man.rcp.1; programok mûködésére. Például most nézzük meg a rose /etc/hosts.lpd állományát: orchid violet madrigal.fishbaum.de Ennek megfelelõen tehát a rose elfogadja az orchid, violet és madrigal.fishbaum.de nevû távoli számítógépek kéréseit. Ha bármilyen más gép próbál hozzáférni a rose által felkínált LPD szolgáltatáshoz, visszautasítja. A méret szabályozása Szabályozhatjuk többek közt azt is, hogy mennyi szabad területnek kell fennmaradnia a nyomtatási könyvtárnak otthont adó állományrendszeren. A helyi nyomtató könyvtárában ehhez hozzunk létre egy minfree nevû állományt. Ide írjuk be, mennyi szabad lemezblokk (512 byte-os egység a lemezen) szükségeltetik egy távolról beérkezõ munka fogásához. Így gondoskodhatunk róla, hogy a távoli felhasználók nem fogják eltömíteni az állományrendszerünket, illetve ezzel egyúttal adhatunk némi elõnyt a helyi felhasználóknak is: õk ugyanis még azután is képesek lesznek munkákat küldeni a nyomtatónak, miután az állományrendszeren található szabad terület mennyisége már rég a minfree állományban szereplõ érték alá csökkent. Példaként most a bamboo nevû nyomtatónkhoz adjunk meg egy ilyen minfree állományt. Ehhez az /etc/printcap állományból tudjuk kideríteni a hozzátartozó nyomtatási könyvtárat. Lássuk tehát belõle a bamboo bejegyzését: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:sc:rg=artists:mx#5000:\ :lp=/dev/ttyd5:ms#-parenb cs8 clocal crtscts:rw:mx#5000:\ :if=/usr/local/libexec/psif:\ :df=/usr/local/libexec/psdf: A nyomtatási könyvtárat az sd tulajdonság határozza meg. Úgy állítjuk most be, hogy az LPD számára a távoli munkák fogadásához ebben a könyvtárban legalább három megabyte (6144 blokk) szabad területnek mindig lennie kell: &prompt.root; echo 6144 > /var/spool/lpd/bamboo/minfree A felhasználók szabályozása Az /etc/printcap állományban megadható rs tulajdonság segítségével korlátozhatjuk a helyi nyomtatókhoz hozzáférni képes távoli felhasználókat. Amikor az rs tulajdonság szerepel egy helyben csatlakozó nyomtató leírásánál, akkor az LPD csak abban az esetben fogad el távoli felhasználóktól munkát, ha a munkát küldõ felhasználónak ugyanazon a néven van a helyi gépen is hozzáférése. Máskülönben az LPD vissza fogja utasítani a kérést. Ez a tulajdonság különösen fontos olyan környezetben, ahol (például) több szervezeti egység használ egyetlen közös hálózatot és bizonyos felhasználók képesek átlépni szervezeti egységük határait, mivel ha a hozzáférést adunk neki a rendszereinkhez, akkor képesek a saját helyükrõl használni ezeket. Ha ehelyett csupán a nyomtatóinkat és a számítógépünk összes erõforrását akarjuk megosztani, akkor létrehozhatunk a számukra olyan token hozzáféréseket is, amikhez nem tartozik sem felhasználói könyvtár, sem pedig parancsértelmezõ (pontosabban a /usr/bin/false). A nyomtató használatának nyilvántartása nyilvántartás nyomtató Tehát szükségünk lenne a nyomtatások költségének elszámolására. Miért is ne tennénk ilyet? A papír és a tinta bizony pénzbe kerül, amihez még hozzájárulnak más egyéb karbantartási költségek is — a nyomtatók dugig vannak mindenféle mozgó alkatrésszel, amelyek elõbb-utóbbi el is romlanak. Tegyük fel, hogy a nyomtatóink kapacitása, kihasználtsága és karbantartási költsége alapján már megállapítottunk egy elszámolási egységet (oldalanként, méterenként, akárminként). De hogyan lássunk hozzá a nyomtatások költségének tényleges nyilvántartásához? Van egy rossz hírünk: az LPD nyomtatási rendszer önmaga nem tud segíteni ebben a feladatban. A nyilvántartás nagyban függ a használt nyomtatóktól, a nyomtatott formátumoktól és nyomtató általunk kiszabott költségeitõl. A nyilvántartás létrehozásához át kell írnunk a nyomtatóhoz tartozó szûrõt (a nyers szövegek költségének felszámításához) és konverziós szûrõket (a különféle formátumok költségei miatt), amikkel aztán számolhatjuk vagy lekérdezhetjük a kinyomtatott lapokat. Egyetlen kimeneti szûrõ használatával szinte semmire se megyünk, mivel az nem képes nyilvántartás vezetésére. Errõl bõvebb útmutatást a Szûrõk szakaszban találhatunk. Általánosságban véve két módon vezethetünk nyilvántartást: Az idõszakos elszámolás a gyakoribb, mivel ez az egyszerûbb. Amikor valaki kinyomtat egy munkát, a szûrõ a nyilvántartást tároló állományba feljegyzi a felhasználó azonosítóját, a gépének nevét és a kinyomtatott oldalakat. Ezután minden hónapban, félévben, évben vagy akár tetszõleges idõközönként összegyûjtjük a nyomtatók nyilvántartásait és külön feljegyezzük az egyes felhasználók nyomtatásait, majd benyújtjuk róla a számlát. Töröljük az összes naplóállományt, és tiszta lappal kezdjük a következõ idõszakot. Az azonnali elszámolás már nem annyira népszerû, mivel nehezebb megvalósítani. Ekkor a felhasználók már közvetlenül a nyomtatás után megkapják a számlát, hasonlóan a lemezkvótákhoz. Meg tudjuk akadályozni ezzel azt is, hogy a felhasználók túlléphessék az elõre kiszabott nyomtatási kvótájukat, amit persze menet közben lehet ellenõrizni és állítgatni. A felhasználók és kvótájuk nyomonkövetéséhez viszont szükségünk lesz egy kis adatbáziskezelésre is. Az LPD nyomtatási rendszer mind a két módszer kivitelezéséhez tud segítséget nyújtani, hiszen amikor szûrõket állítunk be (vagyis szinte mindig), lehetõségünk van a nyilvántartást végzõ programrészleteket is beilleszteni. És ami feltétlenül elõnyös: óriási mértékû rugalmasságot ajánl fel a nyilvántartás megvalósításához. Például magunk választhatjuk ki, hogy idõszakos vagy azonnali elszámolást alkalmazunk. Meg tudjuk adni, milyen információkat rögzítsünk: felhasználói neveket, számítógépek neveit, a munkák típusát, vagy a kinyomtatott oldalakat, a felhasznált lapok területét, a nyomtatások idõbeli igényeit és így tovább. Ehhez mindössze csak a szûrõket kell módosítani. Nyilvántartás gyorsan és egyszerûen A &os;-ben egybõl találunk is két programot, amivel pillanatok alatt ki tudunk alakítani egy egyszerû idõszakos elszámolási rendszert. Ezek Az lpf szövegszûrõ címû szakaszban ismertetett lpf és a nyomtatók nyilvántartásait tartalmazó állományok adatainak összegyûjtését és kiértékelését végzõ &man.pac.8;. Ahogy korábban már leírtuk a szûrõkrõl szóló szakaszban (Szûrõk), az LPD a szöveg- és konverziós szûrõket parancssorból a nyilvántartást tároló állomány nevével indítja el. Ezt a paramétert a szûrõk aztán fel tudják használni a nyilvántartások feljegyzéséhez. Az állomány nevét az /etc/printcap állományban szereplõ af tulajdonsággal tudjuk megadni, vagy teljes elérési úttal, vagy pedig a nyomtatási könyvtárhoz viszonyítva. Az LPD az lpf szûrõt a lap szélességének és hosszának megadásával indítja el (ezeket az értékeket a pw és pl tulajdonságokból származtatja). Az lpf ezek felhasználásával meg tudja mondani, mennyi papírt használtunk el. Miután kiküldte az állományt a nyomtatóra, nyilvántartásba is veszi. Ezek a típusú bejegyzések valahogy így néznek ki: 2.00 rose:andy 3.00 rose:kelly 3.00 orchid:mary 5.00 orchid:mary 2.00 orchid:zhang Minden nyomtatóhoz érdemes külön nyilvántartást vezetni, mivel az lpf nem tartalmaz semmilyen beépített zárolási megoldást, ezért két lpf párhuzamos futtatása könnyen összezagyválhatja a közösen használt nyilvántartások tartalmát. Az /etc/printcap állományban az af=acct tulajdonság megadásával könnyen létre tudunk hozni minden nyomtatóhoz külön nyilvántartást. Ilyenkor minden nyomtató könyvtárában megjelenik egy acct nevû állomány. Amikor elérkezünk a nyomtatások kiszámlázásához, futtassuk le a &man.pac.8; programot. Ehhez mindössze annyit kell tennünk, hogy átlépünk az elszámolni kívánt nyomtató könyvtárába és begépeljük a pac parancsot. Ekkor kapunk egy ehhez hasonló, dollár alapú kimutatást: Login pages/feet runs price orchid:kelly 5.00 1 $ 0.10 orchid:mary 31.00 3 $ 0.62 orchid:zhang 9.00 1 $ 0.18 rose:andy 2.00 1 $ 0.04 rose:kelly 177.00 104 $ 3.54 rose:mary 87.00 32 $ 1.74 rose:root 26.00 12 $ 0.52 total 337.00 154 $ 6.74 A &man.pac.8; a következõ paramétereket várja: Az kiértékelendõ nyomtató neve. Ez a paraméter csak akkor használható, ha az /etc/printcap állományban az af tulajdonságnak teljes elérési utat adtunk meg. A felhasználók nevei helyett a fizetendõ összeg szerint rendezze a listát. Hagyja figyelmen kívül a nyilvántartásban szereplõ gépek hálózati neveit. Ennek hatására az alpha géprõl nyomtató smith meg fog egyezni a gamma géprõl nyomtatóval. A beállítás nélkül ez a két felhasználó el fog térni. A paraméterként megadott ár dollár értékkel számol oldalanként vagy lábanként az /etc/printcap állományban megadott pc tulajdonság értéke helyett (ami alapból két cent). Az ár lebegõpontos (valós) számként is megadható. A rendezési sorrend megfordítása. Hozzon létre egy elszámolást, majd törölje a hozzá kapcsolódó nyilvántartási adatokat. név … Csak az adott nevû felhasználók adatait értékelje ki. A &man.pac.8; által alapértelmezés szerint generált kimutatásban láthatjuk az egyes gépekrõl származó egyes felhasználók kinyomtatott oldalait. Ha nekünk viszont nem számít, hogy honnan küldték a kéréseket (mivel bárhonnan lehet küldeni), akkor a pac -m 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 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 külön állományba menti, amelynek a neve nagyjából megegyezik a nyilvántartást végzõével, de _sum-ra (mint summary, azaz elszámolás) végzõdik. Ezután nullázza a nyilvántartást. Amikor a &man.pac.8; programot újra lefuttatjuk, újból beolvassa a korábban elmentett elszámolásokat, majd hozzászámolja a többit a hagyományos nyilvántartási adatokból. Hogyan tudjuk számolni a kinyomtatott lapokat? A nyilvántartás pontos vezetéséhez még távolról is valamilyen módon meg kell tudnunk mondani, hogy mennyi lapot használt egy nyomtatási munka végrehajtása. Ez a nyomtatás nyilvántartásának egyik alapvetõ problémája. A nyers szövegek esetében ez nem is annyira bonyolult: egyszerûen számoljuk össze, hogy a munkában mennyi sor kinyomtatására lesz szükség és vessük össze ezt a nyomtató által lapoként kinyomtatott sorok számálva. Ne felejtsük el számításba venni a szövegben felbukkanó törlések hatását, vagy az olyan hosszú sorokat, amelyek a valóságban több sorban fognak megjelenni. Viszont (Az lpf szövegszûrõ címû szakaszban bemutatott) lpf program ezeket mind lekezeli a nyilvántartások készítése során. Ezért ha szintén egy nyilvántartást vezetni képes szövegszûrõt akarunk írni, akkor mindenképpen érdemes megnéznünk az lpf forráskódját. De hogyan bánjunk el a többi formátummal? Nos, a DVI-Laserjet és DVI-&postscript; közti átalakítások esetén a kinyomtatott lapok számának megállapításához meg kell tanítanunk a szûrõnket értelmezni a dvilj vagy dvips parancsok kimenetét. Ugyanezt meg tudjuk tenni más formátumok és más konverziós programok használata során is. Azonban ezek a módszerek nem veszik számításba, hogy a nyomtató egyáltalán ki is nyomtatta-e az összes elküldött oldalt. Sok minden történhet még addig, például beragadhat a papír, kifogyhat a tinta vagy akár felrobbanhat a nyomtató — a felhasználónak ettõl függetlenül még fizetnie kell. Mit lehet ilyenkor tenni? A precíz nyilvántartásnak csak egyetlen biztos módja létezik. Olyan nyomtatót szerezzünk be, amely képes megmondani, mennyi lapot használt el a nyomtatás során, majd egy ilyet csatlakoztassunk soros porton vagy hálózaton keresztül. Szinte majdnem az összes &postscript; nyomtató támogatja ezt a lehetõséget, ahogy sok más gyártmány és típus is (például a hálózati Imagen lézernyomtatók). A nyomtatóhoz tartozó szûrõt ehhez úgy kell módosítani, hogy lekérdezzük a kinyomtatott lapok számát a nyomtatás után és kizárólag erre az értékre alapozva készítünk nyilvántartást. Itt nincs szükség sem a sorok számolására, sem pedig az állományok (könnyen elhibázható) átvizsgálására. Természetesen lehetünk nagylelkûek és ne számítsunk fel semmit a nyomtatásért. A nyomtatók használata nyomtató használat Ebbõl a szakaszból megtudhatjuk, hogyan használjuk a &os;-n beállított nyomtatónkat. Röviden most itt foglaljuk össze az ide tartozó felhasználói parancsokat: &man.lpr.1; Munkákat nyomtat ki. &man.lpq.1; Ellenõrzi a nyomtatási sorokat. &man.lprm.1; Munkákat vesz ki a nyomtatási sorokból. Ezek mellett létezik még a nyomtatók és a hozzájuk tartozó sorok irányítására alkalmas parancs is, az &man.lpc.8;, amelyre a A nyomtatók vezérlése címû szakaszban fogunk részleteiben kitérni. A nyomtatók/sorok /etc/printcap állományban szereplõ nevük szerinti megadásához az &man.lpr.1;, &man.lprm.1; és &man.lpq.1; parancsok közül mindegyik elfogadja a paramétert. Ennek köszönhetõen képesek vagyunk munkákat küldeni, eltávolítani vagy felügyelni az egyes nyomtatók soraiban. Ha nem használjuk a kapcsolót, akkor az érintett nyomtató a PRINTER környezeti változó által meghatározott lesz. Végül, ha a PRINTER nevû környezeti változót sem állítottuk be, akkor a parancsok alapértelmezett módon az lp nevû nyomtatót fogják használni. A továbbiakban az alapértelmezett nyomtató kifejezés a PRINTER környezeti változó által megnevezett nyomtatóra fog utalni, illetve ha ezt nem definiáltuk, akkor az lp nevû nyomtatóra. Munkák nyomtatása Az állományok kinyomtatásához írjuk be: &prompt.user; lpr állománynév ... nyomtatás Ezzel kinyomtatjuk az összes felsorolt állományt az alapértelmezett nyomtatón. Ha nem adunk meg állományokat, akkor az &man.lpr.1; parancs a szabványos bemenetrõl várja a nyomtatandó adatokat. Például ezzel a paranccsal néhány igen fontos rendszerállományt tudunk kinyomtatni: &prompt.user; lpr /etc/host.conf /etc/hosts.equiv A nyomtató megválasztásához így adjuk ki a parancsot: &prompt.user; lpr -P 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 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. 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 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: waiting for bamboo to become ready (offline ?) kelly: 1st [job 009rose] /etc/host.conf 73 bytes /etc/hosts.equiv 15 bytes kelly: 2nd [job 010rose] (standard input) 1635 bytes mary: 3rd [job 011rose] /home/orchid/mary/research/venus/alpha-regio/mapping 78519 bytes Munkák eltávolítása Ha meggondoltuk volna magunkat egy munka kinyomtatásáról, az &man.lprm.1; paranccsal még törölni tudjuk a sorból. Az &man.lprm.1; gyakran még a nyomtatás alatt álló munkát is képes eltávolítani, azonban elõfordulhat, hogy a munka egy része már nyomtatásra került. Az alapértelmezett nyomtató sorából csak úgy tudunk munkákat törölni, ha elõször az &man.lpq.1; segítségével megkeressük a számukat. Ha ez megvan, írjuk be: &prompt.user; lprm munkaszám Adott nyomtatóról a kapcsoló segítségével tudunk munkákat törölni. A most következõ parancs a bamboo nevû nyomtatóról törli a 10-es számú munkát: &prompt.user; lprm -P 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 - 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 Rank Owner Job Files Total Size active seeyan 12 ... 49123 bytes 2nd kelly 13 myfile 12 bytes &prompt.user; lprm -P rattan 13 rose: Permission denied &prompt.user; logout &prompt.user; lprm -P 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 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 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 -m A rendszer küldjön levelet a munka teljesítése után. Ekkor az LPD a munka elvégzése után levelet küld a helyi postafiókunkba. A levélben kifejti, hogy sikeres volt-e a nyomtatás, vagy esetleg valamilyen hiba keletkezett, és ha hiba történt, akkor pontosan mi is volt az. -s Ne másolja közvetlenül az állományokat a nyomtatási könyvtárba, hanem készítsen hozzájuk szimbolikus linkeket. Egy nagyobb munka nyomtatása esetén javasolt használni ezt a kapcsolót. Ezzel a megoldással helyet tudunk spórolni a nyomtatási könyvtárban (amikor a munkánk könnyen megtelítheti a nyomtatási könyvtárat tároló állományrendszert). Emellett idõt is takarítunk meg, mivel az LPD-nek nem kell a munka minden egyes bitjét átmásolni a nyomtatási könyvtárba. Van azonban egy hátránya: mivel az LPD ekkor közvetlenül az eredeti állományra fog hivatkozni, ezért a nyomtatás befejezéséig azt nem módosíthatjuk vagy törölhetjük. Ha egy távoli nyomtatónak küldjük a munkát, akkor az LPD a helyi és a távoli számítógép között mégis kénytelen lesz átmásolni a munkát, így a kapcsoló egyedül csak a helyi nyomtatási könyvtárban fog helyet spórolni. Ettõl eltekintve még ilyenkor is hasznunkra válhat. -r Törölje a munkában szereplõ állományokat, miután átmásolta ezeket a nyomtatási könyvtárba, vagy miután a kapcsoló használatával kinyomtatta ezeket. Nagy körültekintéssel használjuk! A fejléclapok beállításai Az &man.lpr.1; most következõ beállításai a munkák fejlécében megjelenõ szövegekre vannak hatással. Így ha letiltottuk a fejléclapok használatát, akkor ezek a kapcsolók lényegében semmit sem állítanak. A Fejléclapok címû szakaszból tudhatunk meg többet ezek beállításáról. -C szöveg A fejléclapon megjelenõ hálózati név helyett a szöveg fog szerepelni. A hálózati név általában annak a gépnek a neve, ahonnan a munkát küldték. -J szöveg A fejléclapon megjelenõ munka neve helyett a szöveg fog megjelenni. A munka neve általában a benne szereplõ elsõ állomány nevével egyezik meg, ha a szabványos bemenetrõl nyomtatunk, akkor egyszerûen csak stdin. -h Ne nyomtasson fejléclapot. Bizonyos helyeken elõfordulhat, hogy ennek a kapcsolónak nincs semmilyen hatása a fejléclapok létrehozásának módszerébõl fakadóan. A részleteket lásd a Fejléclapok szakaszban. A nyomtatók vezérlése A nyomtatóink rendszergazdájaként nekünk kell telepítenük, üzembe helyeznünk és kipróbálnunk ezeket. Az &man.lpc.8; parancs használatával még jobban képesek vagyunk kapcsolatba lépni velük. Az &man.lpc.8; paranccsal: el tudjuk indítani és le tudjuk állítani a nyomtatókat; be- és ki tudjuk kapcsolni a nyomtatási soraikat; át tudjuk rendezni az egyes sorokban található munkákat. Elõször is essen pár a fogalmakról: ha a nyomtató leállt, akkor semmit sem fog kinyomtatni a sorából. A felhasználók továbbra is képesek munkákat küldeni, amik azonban egészen addig fognak várakozni, amíg a nyomtatót el nem indítjuk vagy a sorát ki nem ürítjük. Ha egy sort kikapcsolunk, akkor (a root kivételével) egyetlen felhasználó sem képes munkákat küldeni a nyomtatónak. A bekapcsolt sorok képesek csak munkát fogadni. A nyomtató elindítható kikapcsolt sorral is, ilyenkor egészen addig folytatja a munkák kinyomtatását, amíg a sor ki nem ürül. Általánosan elmondható, hogy az &man.lpc.8; parancs használatához a root felhasználó jogosultságaira van szükségünk. Az &man.lpc.8; parancsot minden más esetben csak a nyomtató állapotának ellenõrzésére vagy a megakadt nyomtató újraindítására használhatjuk. Foglaljuk röviden össze az &man.lpc.8; parancsait. A legtöbb parancs kiadásához még szükséges egy nyomtatónév paraméter megadása is, amivel megnevezzük az utasítani kívánt nyomtatót. Helyette használható az all szó is, amivel az /etc/printcap állományban szereplõ összes nyomtatót egyszerre utasíthatjuk. abort nyomtatónév Az aktuális munka megszakítása és a nyomtató leállítása. Ha a nyomtatási sort még nem kapcsoltuk ki, a felhasználók küldhetnek további munkákat. clean nyomtatónév A nyomtató könyvtárából töröljük a régi állományokat. Esetenként adódhat, hogy bizonyos munkák állományait nem takarította el az LPD, különösen abban az esetben, amikor a nyomtatás vagy az adminisztrálás során keletkezett valamilyen hiba. Ez a parancs segít megtalálni a nyomtatási könyvtárból már kikopott állományokat és törli ezeket. disable nyomtatónév Az újonnan érkezõ munkák besorolásának kikapcsolása. Ha a nyomtató még mûködik, akkor folytatni fogja a sorban még bennmaradt munkák nyomtatását. A rendszergazda (a root) még a kikapcsolt sorok esetén is küldhet munkákat. Ez a parancs valójában akkor hasznos, ha egy új nyomtató vagy egy új szûrõ mûködését próbálgatjuk: ilyenkor érdemes kikapcsolni a nyomtatási sort és root felhasználóként munkákat küldeni. A többi felhasználó a tesztelés befejezéséig nem tud majd munkákat küldeni, vagyis egészen addig, amíg a nyomtatási sort vissza nem kapcsoljuk az enable paranccsal. down nyomtatónév üzenet A nyomtató üzemen kívül helyezése. Lényegében megegyezik egy disable és utána egy stop parancs kiadásával. Az üzenet akkor jelenik meg, amikor a valaki megpróbálja lekérdezni a nyomtató állapotát az lpc status paranccsal, vagy amikor megnézi a nyomtatási sorát az &man.lpq.1; paranccsal. enable nyomtatónév A nyomtatóhoz tartozó nyomtatási sor bekapcsolása. A felhasználók ezután már képesek lesznek a nyomtatónak munkákat küldeni, azonban egészen addig nem nyomtatódik ki semmi, amíg a nyomtató el nem indítjuk. help parancsnév Megmutatja a parancsnév parancshoz tartozó súgót. A parancsnév megadása nélkül a rendelkezésre álló parancsok listáját kapjuk meg. restart nyomtatónév Elindítja a nyomtatót. A felhasználók ezt a parancsot tudják használni abban az esetben, amikor valamilyen megmagyarázhatatlan okból az LPD mûködése megáll, viszont ezzel nem tudják elindítani a stop vagy down parancsokkal leállított nyomtatót. A restart parancs megegyezik az abort és a start egymás utáni kiadásával. start nyomtatónév Elindítja a nyomtatót, és a nyomtató nekilát kinyomtatni a sorában levõ munkákat. stop nyomtatónév Leállítja a nyomtatót, és a nyomtató az aktuális munka befejezése után már nem kezd neki újabbnak. Ettõl függetlenül a felhasználók még továbbra is képesek munkákat küldeni a nyomtatási sorába. topq nyomtatónév munka-vagy-felhasználónév Átrendezi a nyomtatónév nevû nyomtató sorát úgy, hogy a megadott azonosítójú munkát vagy a megadott felhasználónévhez tartozó munkákat a sor elejére teszi. Ennél a parancsnál nyomtatónévnek nem adhatjuk meg az all értéket. up nyomtatónév Üzembe helyezi a nyomtatót, tulajdonképpen a down parancs ellentéte. Megegyezik egy egymás után kiadott start és enable paranccsal. Az &man.lpc.8; a fenti parancsokat a parancssorból fogadja el. Ha itt nem adunk meg neki semmilyen parancsot, akkor az &man.lpc.8; interaktív módba vált, ahol ugyanezeket a parancsokat adhatjuk ki, egészen az exit, quit parancsok vagy az állományvége jelzés begépeléséig. Más nyomtatási rendszerek Ha derekasan végigolvastuk eddig ezt a fejezetet, akkor mostanra már valószínûleg mindent tudunk a &os;-ben található LPD nyomtatási rendszerrõl. Ezzel együtt tisztában vagyunk a hiányosságaival is, aminek kapcsán természetes módon felmerülhet bennünk a kérdés: Milyen más (&os;-vel is mûködni képes) nyomtatási rendszerek léteznek még? LPRng LPRng Az LPRng, aminek jelentése LPR Next Generation (Az LPR következõ generációja), a PLP teljesen újraírt változata. Patrick Powell és Justin Mason (a PLP eredeti karbantartója) együttes munkájának gyümölcse az LPRng. Az LPRng honlapja: . CUPS CUPS A CUPS, vagy más néven a Common UNIX Printing System (Közös &unix;-os nyomtatási rendszer), egy hordozható nyomtatási réteg nyújt a &unix;-alapú operációs rendszerek számára. Az Easy Software Products fejlesztése és szinte az összes &unix; gyártó és felhasználó szemében elfogadott szabványos nyomtatási rendszer. A CUPS a nyomtatási munkák és sorok kezelését az internetes nyomtatási protokollon (Internet Printing Protocol, IPP) használatával oldja meg. Csökkentett képességekkel ugyan, de a sornyomtató démon (Line Printer Daemon, LPD), szerverüzenet-blokk (Server Message Block, SMB), és AppSocket (más néven JetDirect) protokollokat is ismeri. A CUPS a komolyabb &unix;-os nyomtatási feladatokhoz ezeken felül még a hálózati nyomtatók közti választást és PostScript nyomtatók leírásán (PostScript Printer Description, PPD) alapuló nyomtatási beállításokat is támogatja. A CUPS honlapja: . Hibakeresés Miután az &man.lptest.1; programmal elvégeztünk néhány egyszerû próbát, a várt helyett a következõk egyikét kaphatuk eredményül: Egy kis idõ után minden remekül mûködött, vagy nem dobta ki az egész lapot. A nyomtató nyomtatott egy keveset, aztán egy ideig csendben maradt és nem csinált semmit. Ilyenkor a nyomtatnivalók megjelenéséhez minden bizonnyal meg kell nyomnunk a nyomtatón levõ PRINT REMAINING vagy FORM FEED feliratú gombokat. Ebben az esetben a nyomtató valószínûleg még arra várt, hogy még a nyomtatás megkezdése elõtt érkezik valamilyen további adat. Ettõl a gondtól úgy szabadulhatunk meg, ha beállítunk egy szövegszûrõt, amely minden (szükséges) esetben küld egy FORM FEED (lapdobás) jelzést is a nyomtatónak. Ez kell általában ahhoz, hogy a szöveg a nyomtató belsõ pufferében megmaradt része azonnal kinyomtatódjon. Akkor is a javunkra válhat ez, ha minden egyes munkát külön lapon akarunk kezdeni, mivel így a következõ munka sosem közvetlenül ott kezdõdik, ahol az elõzõ munka befejezte a nyomtatást. A /usr/local/libexec/if-simple szûrõ helyett a következõ szkript használhatával tudunk minden munka után elküldeni egy lapdobást: #!/bin/sh # # if-simple - Egyszerû lpd szövegszûrõ # Helye: /usr/local/libexec/if-simple # # Egyszerûen átmásolja a szabvány bemenetet a szabvány kimenetre, # és figyelmen kívül hagyja az összes többi paramétert. # Minden nyomtatási munka után küld egy lapdobást (\f). /bin/cat && printf "\f" && exit 0 exit 2 Lépcsõsen jelentek meg a sorok. Ekkor a következõt látjuk a lapon: !"#$%&'()*+,-./01234 "#$%&'()*+,-./012345 #$%&'()*+,-./0123456 MS-DOS OS/2 ASCII Az ún. lépcsõhatás áldozatává váltunk, amelyet a sortörést jelzõ karakter eltérõ értelmezései okoznak. A &unix; stílusú operációs rendszerek erre mindössze egyetlen karaktert használnak: ez a 10-es kódú ASCII karakter (sordobás, Line Feed, LF). Az &ms-dos;, &os2; és mások pedig két karakterrel oldják meg ezt a feladatot: a 10-es és 13-as kódú (kocsivissza, Carriage Return, CR) ASCII karakterekkel. A sortöréseknél sok nyomtató az &ms-dos; szokásait követi. Amikor a &os;-vel nyomtatunk, akkor csak egyetlen karaktert használunk sortörésre. Ennek láttán a nyomtató lépteti a sort, azonban a fej vízszintes pozícióját nem változtatja meg a következõ sor nyomtatásának megkezdésekor. Erre lenne a kocsivissza karakter, vagyis ennek hatására fogja a nyomtató a papír bal oldalára visszaállítani a következõ nyomtatandó karakter pozícióját. A &os; így szeretné utasítani a nyomtatót: A nyomtató kocsivisszát kap A nyomtató visszalépteti a pozíciót A nyomtató sordobást kap A nyomtató új sort kezd Néhány módszer ennek kiváltására: A nyomtatón található kapcsolók vagy vezérlõpanel segítségével próbáljuk meg átállítani a vezérlõkarakterek nyomtató szerinti értelmezését. Keressük meg a nyomtató kézikönyvében, hogyan tudjuk ezt megcsinálni. Ha a &os; mellett más operációs rendszerekkel is használni akarjuk a nyomtatót, akkor azok indítása elõtt mindig át kell állítani a nyomtatót a megfelelõ értelmezés alkalmazására. Ilyenkor valószínûleg a lentebb szereplõ megoldásokat részesítjük majd inkább elõnyben. Állítsuk be úgy a &os; soros vonali meghajtóját, hogy magától alakítsa át az LF karaktereket CR+LF párokká. Természetesen ez a megoldás csak a soros portra csatlakozó nyomtatók esetében mûködhet. Ehhez az /etc/printcap állományban a nyomtató leírásánál az ms# tulajdonságnál adjuk meg az onlcr módot. Küldjünk olyan kódot a nyomtatónak, amelynek hatására ideiglenesen máshogy fogja kezelni az LF karaktereket. Nézzük meg a nyomtatóhoz mellékelt útmutatóban, hogy milyen kódokat tudunk ilyen célra használni. Ha találtunk ilyen kódot, akkor írjuk át úgy a hozzátartozó szövegszûrõt, hogy a munkák elõtt mindig elküldjük azt. PCL Most bemutatjuk egy olyan szövegszûrõ kódját, amely a Hewlett-Packard PCL kódjait ismerõ nyomtatókhoz készült. Ebben a szûrõben elõször kiadjuk, hogy az LF karaktereket LF és CR karakterek kombinációjának tekintse a nyomtató, majd elküldjük magát a munkát, és a munka utolsó lapja után pedig elküldünk egy lapdobást. Szinte az összes Hewlett Packard nyomtatóval mûködnie kell. #!/bin/sh # # hpif - Egyszerû lpd bemeneti szûrõ a HP-PCL alapú nyomtatókhoz # Helye: /usr/local/libexec/hpif # # Egyszerûen átmásolja a szabvány kimenetet a szabvány bemenetre, és # figyelmen kívül hagyja a paramétereket. Elküldi a nyomtatónak, hogy # az LF karaktereket CR+LF-ként kezelje, majd a feladat befejeztével # lapot dobat. printf "\033&k2G" && cat && printf "\033&l0H" && exit 0 exit 2 Példaként megadjuk még az orchid nevû számítógép /etc/printcap állományát is. Ebben egyetlen nyomtató csatlakozik a párhuzamos portra, amelynek a típusa LaserJet 3Si és a neve teak. Az elõbb bemutatott szövegszûrõt használja: # # /etc/printcap (orchid) # teak|hp|laserjet|Hewlett Packard LaserJet 3Si:\ :lp=/dev/lpt0:sh:sd=/var/spool/lpd/teak:mx#0:\ :if=/usr/local/libexec/hpif: Egymásra írja a sorokat. A nyomtató nem lépteti a sorokat, ezért az összes sor egymáson jelenik meg. Ez pontosan a ritka ellentéte a fentebb leírt lépcsõhatásnak. A &os; által sortörésre használt LF karakterek valamiért CR karakterekként viselkednek, ezért a nyomtató nem sort vált, hanem a lap bal szélére állítja a fejet. A nyomtatón található kapcsolókkal vagy vezérlõpanellel így állítsuk be az sordobás és kocsivissza karakterek értelmezését: Amit a nyomtató kap Arra a nyomtató nyomtat CR CR LF CR + LF A nyomtató elhagy karaktereket. Miközben nyomtatunk, a nyomtató bizonyos karaktereket nem hajlandó megjeleníteni. A probléma ennél nagyobb, ha a nyomtató mûködése közben egyre több és több karaktert hagy ki. Itt az a gond, hogy a nyomtató nem képes tartani az iramot a számítógép által a soros vonalon átküldött adatok sebességével (ez a probléma nem jelentkezhet a párhuzamos nyomtatók esetén). Két módon kerekedhetünk felül ezen: Ha a nyomtató ismeri a XON/XOFF típusú forgalomirányítást, akkor az ms# tulajdonságnál adjuk meg a &os; számára az ixon beállítást. Ha a nyomtató ismeri a vonali forgalomirányítást (carrier flow control), akkor az ms# tulajdonságnál a crtscts beállítást adjuk meg. Gondoskodjunk róla, hogy a számítógépet és a nyomtató összekötõ kábel meg tudjon majd bírkózni ezzel a típusú forgalomirányítással. Mindenféle szemetet nyomtat. A nyomtató nem a nyomtatni kívánt szöveget hozza létre, hanem össze-vissza nyomtat. Ez a soros nyomtatók helytelen kommunikációs beállításának egy másik jellemzõ tünete. Ellenõrizzük a br tulajdonságnál megadott adatátviteli sebességet és az ms# tulajdonságnál megadott paritási beállításokat. Egyeztessük a nyomtató saját és az /etc/printcap állományban tárolt beállításait. Semmi sem történik. Ha semmi sem történt, akkor a gond magával a &os;-vel lehet, nem pedig a hardverrel. Az /etc/printcap állományba a vizsgálni kívánt nyomtató leírásához (az lf tulajdonsággal) illesszünk be naplózást. Például így fog kinézni a rattan nevû nyomtató bejegyzése az lf tulajdonság megadásával kibõvítve: rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0:\ :if=/usr/local/libexec/if-simple:\ :lf=/var/log/rattan.log Miután ezt megcsináltuk, próbálkozzunk újra. Nézzük meg a naplóállományban (ami a példánkban a /var/log/rattan.log nevén érhetõ el), hogy látunk-e valamilyen hibaüzenetet. Az itt tapasztalt hibaüzenetek nyomán elindulva igyekezzünk megszüntetni a probléma forrását. Ha nem adjuk meg az lf tulajdonságot, akkor az LPD erre a célra alapértelmezés szerint a /dev/console állományt használja. diff --git a/hu_HU.ISO8859-2/books/handbook/security/chapter.sgml b/hu_HU.ISO8859-2/books/handbook/security/chapter.sgml index 3f1f3c87be..89b97e255e 100644 --- a/hu_HU.ISO8859-2/books/handbook/security/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/security/chapter.sgml @@ -1,6993 +1,6224 @@ 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ározattan + 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 szoftver képes erre, sõt - még többre is. A következõ + 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 burkolók számos + 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 + 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 + 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. + linkend="network-inetd">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 + 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 + 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õ lehet allow vagy - deny annak megfelelõen, hogy - engedélyezzük vagy tiltjuk a megadott - címrõl a csatlakozást. Nem szabad + 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 + 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. + 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 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. - - A &os;-ben Fast IPsec néven - találunk egy hardvergyorsítással - támogatott IPsec protokollkészletet is, - amelyet még az OpenBSD-bõl vettek át. Ez - (amikor lehetséges) a &man.crypto.4; alrendszeren - keresztül egy kriptográfiai célhardver - bevonásával igyekszik növelni az IPsec - teljesítményét. Ez az alrendszer - még új, és még nem is ismeri az - IPsec KAME változata által - felkínált összes lehetõséget. - A hardvergyorsítással kisegített IPsec - engedélyezéséhez a következõ - opciót kell hozzátennünk a rendszermag - beállításait tartalmazó - állományhoz: - - - a rendszermag - beállításai - FAST_IPSEC - - - -options FAST_IPSEC # az új IPsec (nem megy az IPSEC-kel együtt) - - - Vegyük észre, hogy jelen pillanatban a - Fast IPsec alrendszer nem - használható az IPsec KAME változata - helyett. Ennek részleteirõl a &man.fast.ipsec.4; - man oldalon tájékozódhatunk. - - - - A rendszermag beállításai - között az - opcióra is szükségünk lesz ahhoz, hogy - a tûzfalak megfelelõ módon követni - tudják a &man.gif.4; tunnelek - állapotát. - - -options IPSEC_FILTERGIF # a tunnelekbõl érkezõ IPsec csomagok szûrése - - - 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) 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: két, interneten - keresztül összekötött hálózat, - melyeket egyként akarunk használni + 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. Az átjárón - igény szerint végezhetünk - címfordítást (NAT) is; - - - a két hálózat belsõ - IP-címei nem fedik át - egymást. Habár elméletben - lehetséges a VPN és NAT - technológiák elegyítése, ezt a - típusú felállást itt most nem - preferáljuk. + 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. + - Ha belül mind a két hálózat - ugyanolyan tartományú IP-címeket - használ (például 192.168.1.x), akkor az egyiküket - át kell számozni. - - A hálózat felépítése - tehát valahogy így nézhet ki: - - - - - - - - 1. hálózat [ Belsõ gépek ] Privát hálózat: 192.168.1.2-254 - [ Win9x/NT/2K ] - [ UNIX ] - | - | - .---[fxp1]---. Privát IP: 192.168.1.1 - | FreeBSD | - `---[fxp0]---' Publikus IP: A.B.C.D - | - | - -=-=- Internet -=-=- - | - | - .---[fxp0]---. Publikus IP: W.X.Y.Z - | FreeBSD | - `---[fxp1]---' Privát IP: 192.168.2.1 - | - | -2. hálózat [ Belsõ gépek ] - [ Win9x/NT/2K ] Privát hálózat: 192.168.2.2-254 - [ UNIX ] - - - - Figyeljük meg a két publikus IP-címet. A - leírás további részében - betûkkel hivatkozunk rájuk, tehát ahol ezek - szerepelnek, oda kell behelyettesíteni a saját - publikus címeinket. A két - átjáró címében .1 az - utolsó szám, és hogy két - hálózat privát IP-címei - eltérnek (192.168.1.x - és 192.168.2.x). A - privát hálózatokon belül minden - számítógépet úgy - állítottunk be, hogy alapértelmezés - szerint a .1 számú - gépet használják - átjárónak. - - Hálózati szemszögbõl ez azért - fontos, mert így az egyes hálózatok - úgy látják egymás gépeit, - mintha közvetlenül ugyanahhoz az - útválasztóhoz csatlakoznának — - jóllehet ez egy kicsit lassúcska - útválasztó, ami idõnként - hajlamos eldobni a csomagokat. - - Ez tehát azt jelenti (például), hogy a - 192.168.1.20 címû - számítógépnek gond - nélküli megy a - - ping 192.168.2.34 - - parancs. Ugyanígy a &windows;-os gépek is - képesek látni a másik - hálózaton levõ - számítógépeket, belépni - egymás megosztásaiba és így - tovább, pontosan úgy, mint a helyi - hálózaton levõ gépek - esetében. - - Ne feledjük, hogy mindennek egyszerre - biztonságosnak is kell lennie. Vagyis a két - hálózat közti forgalmat titkosítanunk - kell. - - A VPN létrehozása a két - hálózat között egy - többlépcsõs folyamat. Ezek a - lépcsõk az alábbiak: - - - - Az interneten keresztül hozzunk létre egy - virtuális hálózati - összeköttetést a két - hálózat között. A &man.ping.8; - és hasonló segédprogramok - segítségével gyõzõdjünk - meg a - mûködõképességérõl. - - - - A hálózatok között zajló - forgalom akadálymentes - titkosításához szükség - esetén alkalmazzuk valamilyen biztonsági - házirendet. A &man.tcpdump.1; és - hasonló segédprogramok - használatával ellenõrizzük a - hálózati forgalom - titkosítását. - - - - A &os; átjárókon - állítsunk be olyan szoftvereket, amelyekkel a - &windows;-os számítógépek is - képesek látni egymást a - virtuális magánhálózaton - keresztül. - - - - - Az elsõ lépés: a - <quote>virtuális</quote> hálózati - összeköttetés kialakítása - és kipróbálása - - Tegyük fel, hogy a bejelentkeztünk az elsõ - hálózat átjárójára - (amelynek a publikus IP-címe A.B.C.D, a privát IP-címe - 192.168.1.1), és - kiadtunk a W.X.Y.Z - címû gép privát - IP-címére egy ping - 192.168.2.1 parancsot. Hogyan is - valósítható meg ez? - - - - Az átjárónak el kell tudnia - érnie valahogy a 192.168.2.1 címet. Vagy - úgy is mondhatjuk, hogy a 192.168.2.1 felé ismeri az - utat. - - - A privát IP-címek tartományainak, - amilyen például a 192.168.x, nem szabadna - megjelenniük az interneten. Ehelyett minden olyan - csomagot, amelyet a 192.168.2.1 címre - küldünk, be kell csomagolnunk egy másik - csomagba. Ezt a csomagot úgy kell - beállítani, mintha az A.B.C.D címrõl - küldtük volna a W.X.Y.Z címre. Ennek - folyamatát hívják - becsomagolásnak - (encapsulation). - - - Amikor ez a csomag megérkezik a W.X.Y.Z címre, ki - kell bontani és kézbesíteni a - 192.168.2.1 - címre. - - - - Erre úgy is gondolhatunk, mint egy - járatra a két - hálózat között. A járat - két szája lesz az A.B.C.D és W.X.Y.Z cím, és a - járatnak ismernie kell azokat a privát - IP-címeket, amiket átereszthet. Ezen a - járaton keresztül fog mozogni a privát - IP-címek között az adat az interneten. - - Ezt a járatot egy általános - felület (generic interface, avagy a - gif eszközök) - használatával hozzuk létre a &os;-k - között. Ahogy számíthattunk is - rá, az egyes átjárókon levõ - gif felületekhez négy - IP-címet kell beállítani: kettõt a - publikus címeknek, kettõt pedig a privát - címeknek. - - A gif eszköz támogatását be kell - építeni mind a két &os; gép - rendszermagjába. Ehhez mind a két gépen - a következõ sort kell hozzáadnunk a - rendszermag beállításait - tartalmazó állományhoz: - - device gif - - Ezután a megszokott menetben fordítani, - telepíteni és újraindítani a - rendszereiket. - - A járat beállítása két - lépésbõl áll. Elõször is - az &man.ifconfig.8; használatával a tunnelnek - meg kell mondanunk, hogy mik a külsõ (avagy - publikus) IP-címek. Ezután adjuk meg - ugyanígy a privát IP-címeket. - - Az elsõ hálózat - átjáróján az alábbi - parancsokat kell kiadni a tunnel - beállításához. - - &prompt.root; ifconfig gif0 create -&prompt.root; ifconfig gif0 tunnel A.B.C.D W.X.Y.Z -&prompt.root; ifconfig gif0 inet 192.168.1.1 192.168.2.1 netmask 0xffffffff - - - A másik átjárón is futtassuk - le ugyanezeket a parancsokat, de az IP-címek - sorrendjét ezúttal cseréljük - fel. - - &prompt.root; ifconfig gif0 create -&prompt.root; ifconfig gif0 tunnel W.X.Y.Z A.B.C.D -&prompt.root; ifconfig gif0 inet 192.168.2.1 192.168.1.1 netmask 0xffffffff - - - Ezután már jöhet ez a parancs: - - ifconfig gif0 - - Ezzel elénk tárulnak az iménti - beállításaink. Például az - elsõ hálózat - átjáróján nagyjából - ezt fogjuk látni: - - &prompt.root; ifconfig gif0 -gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280 - tunnel inet A.B.C.D --> W.X.Y.Z - inet 192.168.1.1 --> 192.168.2.1 netmask 0xffffffff - - - Remekül látszik, hogy létrejött - egy tunnel az A.B.C.D és - W.X.Y.Z fizikai címek - között, illetve hogy ezen a járaton - keresztül a 192.168.1.1 - és 192.168.2.1 - címek között engedélyezett a - kommunikáció. - - Ezzel együtt ki kell egészítenünk - mind a két gép útválasztási - táblázatát, amit a netstat - -rn paranccsal meg is tudunk vizsgálni. Most - az elsõ hálózat - átjáróján vagyunk. - - &prompt.root; netstat -rn -Routing tables - -Internet: -Destination Gateway Flags Refs Use Netif Expire -... -192.168.2.1 192.168.1.1 UH 0 0 gif0 -... - - - Ahogy a Flags oszlop értéke - is mutatja, ez egy módosítható - útvonal (host route), ami arra utal, hogy az - átjárók el tudják érni - egymást, de semmit sem tudnak a hozzájuk - tartozó hálózatokról. Ezt a - gondot hamarosan orvosoljuk. - - Valószínûleg használunk - tûzfalat mind a két gépen, így a VPN - forgalmát valahogy át kell tudnunk küldeni - rajta. Vagy engedélyezzük a két - hálózat közti forgalmazást, vagy - olyan szabályokat veszük fel a tûzfalba, ami - a VPN mind a két végét megvédi - egymástól. - - Nagyban egyszerûsíti a tesztelést, ha - úgy állítjuk be a tûzfalat, hogy - engedjen át minden forgalmat a VPN-en keresztül. - Ezt késõbb még úgy is lesz - lehetõségünk szigorítani. Ha az - átjárókon az &man.ipfw.8; tûzfalat - használjuk, akkor erre a parancsra lesz - szükségünk: - - ipfw add 1 allow ip from any to any via gif0 - - Engedélyezzük a VPN két pontja - közti forgalmat anélkül, hogy az - hatással lenne a tûzfal többi - szabályára. Értelemszerûen mind a - két átjárón ki kell ugyanezt a - parancsot. - - Ez már elegendõ ahhoz, hogy a két - átjáró képes legyen pingelni - egymást. A 192.168.1.1 - gépen így tehát mûködnie kell a - következõnek: - - ping 192.168.2.1 - - Erre kapunk egy választ, és - természetesen ugyanezt a másik gépen (a - címzetten) is meg tudjuk tenni - visszafelé. - - Azonban ilyenkor még nem tudjuk elérni egyik - hálózaton sem a belsõ gépeket. Ez - az utak beállítása miatt van — - habár az átjárók már el - tudják érni egymást, de a - mögöttük levõ hálózatot - még nem. - - A probléma megoldásához fel kell - vennünk egy-egy statikus utat az egyes - átjárókon. Az elsõ - átjárón ezt a következõ - módon tudjuk elvégezni: - - route add 192.168.2.0 192.168.2.1 netmask 0xffffff00 - - Jelentése: A 192.168.2.0 hálózatban - levõ számítógépek - eléréséhez küldjük - keresztül a csomagokat a 192.168.2.1 címen. A - másik átjárón egy ehhez - hasonló parancsot kell kiadnunk, ahol viszont 192.168.1.x címeket kell - használnunk. - - Ennek köszönhetõen az egyik - hálózatból érkezõ IP forgalom - most már el tudja érni a másik - hálózatot. - - Ezzel nagyjából létrehoztuk a - két hálózat közti virtuális - magánhálózat kétharmadát, - így már virtuális - és hálózat is. Viszont - most még nem magán-. Ezt a - &man.ping.8; és a &man.tcpdump.1; - segítségével ellenõrizhetjük. - Jelentkezzünk be az egyik átjáróra - és futtassuk le: - - tcpdump dst host 192.168.2.1 - - Jelentkezzünk be megint ugyanazon a gépen - és futtassuk le ezt is: - - ping 192.168.2.1 - - A kimenete valamilyen ilyesmi lesz: - - -16:10:24.018080 192.168.1.1 > 192.168.2.1: icmp: echo request -16:10:24.018109 192.168.1.1 > 192.168.2.1: icmp: echo reply -16:10:25.018814 192.168.1.1 > 192.168.2.1: icmp: echo request -16:10:25.018847 192.168.1.1 > 192.168.2.1: icmp: echo reply -16:10:26.028896 192.168.1.1 > 192.168.2.1: icmp: echo request -16:10:26.029112 192.168.1.1 > 192.168.2.1: icmp: echo reply - - - Jól megfigyelhetõ, hogy az ICMP üzenetek - csak úgy titkosítás nélkül - járkálnak ide-oda. Sõt, ha a - &man.tcpdump.1; parancsnak megadjuk a - paramétert, akkor még a csomagok - tartalmába is belenézhetünk. - - Ezt természetesen nem fogadhatjuk el. A - következõ szakaszban ezért arról - fogunk beszélni, hogy miként kell - levédeni a két hálózat közt - felépített összeköttetést - és ezáltal automatikusan titkosítani az - összes forgalmat. - - - Foglaljuk össze az eddigieket: - - - Állítsuk be mind a két - átjárón rendszermagjában a - device gif paramétert. - - - Az elsõ hálózat - /etc/rc.conf - állományába illesszük be a - következõ sorokat (miután - kicseréltük bennük a megfelelõ - értékeket). - - gif_interfaces="gif0" -gifconfig_gif0="A.B.C.D W.X.Y.Z" -ifconfig_gif0="inet 192.168.1.1 192.168.2.1 netmask 0xffffffff" -static_routes="vpn" -route_vpn="192.168.2.0 192.168.2.1 netmask 0xffffff00" - - - - - Szerkesszük át úgy a tûzfalunk - szkriptjét (/etc/rc.firewall - vagy más hasonló) mind a két - átjárón, és vegyük - hozzá a következõ sort: - - ipfw add 1 allow ip from any to any via gif0 - - - Ugyanezeket a módosításokat - ejtsük meg a második hálózat - /etc/rc.conf - állományában is, természetesen - az IP-címek felcserelésével. - - - - - - A második lépés: az - összeköttetés védelme - - Az imént létrehozott kapcsolatot az IPsec - használatával biztosítjuk. Az IPsec - segít megegyezni az átjáróknak a - titkosítás kulcsában és ezen kulcs - felhasználásával titkosítja a - két gép közt vándorló - adatokat. - - Az ehhez szükséges - beállítások két területre - oszlanak. - - - - A két gépnek valahogy meg kell tudnia - egyeznie a titkosításra közösen - használt kulcsban. Miután ez sikeresen - megtörtént, azt mondjuk, hogy - biztonsági összerendelés - van köztük. - - - Valahogy meg kell adnunk melyik forgalmat kell - titkosítani. Nyilvánvalóan nem - akarunk minden kimenõ forgalmat lekódolni - — csupán annyit, ami a VPN-hez tartozik. A - titkosítandó forgalom - meghatározásához megadott - szabályokat biztonsági - házirendnek nevezzük. - - - - A biztonsági összerendeléseket - és biztonsági házirendeket egyaránt - a rendszermag tartja karban, valamint ezeket a - felhasználói programok - módosíthatják. Azonban mielõtt ezt - megtehetnénk, úgy kell - beállítanunk a rendszermagunkat, hogy - támogassa az IPsec és az ESP protokoll - használatát. Ezt a következõ sorokkal - kell megadni a rendszermag beállításait - tároló állományban: - - - a rendszermag - beállításai - IPSEC - - - options IPSEC -options IPSEC_ESP - - - Fordítsuk újra, telepítsünk - és indítsuk újra a rendszert. - Természetesen az elõbbiekhez hasonlóan ezt - a mûveletsort el kell végeznünk mind a - két átjárón. - - IKE - - A biztonsági összerendelések - felállításakor két - választási lehetõségünk - adódik. A két gép között - beállíthatjuk kézzel, aminek során - kiválasztjuk a titkosításhoz - használt algoritmust, a titkosítás - kulcsát és így tovább, vagy az - internetes kulcscserélõ protokollt (Internet Key - Exchange, IKE) megvalósító - démonokat is használjuk erre a - célra. - - Az utóbbit javasoljuk, mivel egyrészt - könnyebb beállítani. - - - IPsec - biztonsági házirend - - - setkey - - A biztonsági házirendet a &man.setkey.8; - paranccsal tudjuk lekérni és - módosítani. A setkey olyan a - rendszermag biztonsági házirendeket - tároló táblázatainak, mint a - &man.route.8; az útválasztási - táblázatoknak. A setkey - ezenkívül még - láthatóvá tudja tenni a pillanatnyilag - aktív biztonsági összerendeléseket - is, és hogy továbbvigyük az iménti - hasonlatot, ez pedig a netstat -r - parancsnak felelne meg. - - A &os;-ben számos démont találunk a - biztonsági összerendelések - kezelésére. Ezek közül itt most a - racoont fogjuk ismertetni — - security/ipsec-tools - néven találjuk meg a &os; - Portgyûjteményében. - - racoon - - A racoont mind a két - átjáróra telepítenünk kell. - Az egyes számítógépeken a VPN - másik végén levõ IP-címet - kell megadnunk valamint a titkos kulcsot (ezt mi - választjuk meg és minden - átjárón egyeznie kell). - - A két démon ezután felveszi - egymással a kapcsolatot, megerõsítik, hogy - valóban azok, akinek állítják - magukat (az általunk megadott titkos kulcs - használatával). A démonok ezután - létrehoznak egy új titkos kulcsot, amivel a - VPN-en áthaladó forgalmat fogják - titkosítani. Ezt adott - idõközönként cserélik, így - a támadók még azzal sem érnek - túlságosan sokat, ha véletlenül - sikerül feltörniük a titkosítást - (ez elméletileg még így is szinte - lehetetlen) — tehát mire feltörnék a - kulcsot, addigra a két démon már egy - teljesen másikat használ. - - A racoon - beállításait a - ${PREFIX}/etc/racoon - állományban találjuk. Az alapból - itt található konfigurációt - különösebben nem szükséges - bolygatnunk. A racoon - beállításának másik - elemét kell valójában - megváltoztatnunk, ami az ún. ismert - kulcs (pre-shared key, psk) lesz. - - A racoon - alapértelmezés szerint ezt - ${PREFIX}/etc/racoon/psk.txt néven - keresi. Szeretnénk leszögezni, hogy az ismert - kulcs nem az kulcs, amivel a VPN - összeköttetés forgalmát fogjuk - titkosítani, hanem egy egyszerûen csak olyan - titkos jel, amirõl a démonok meg tudják - ismerni egymást. - - A psk.txt állományban - mindegyik távoli géphez tartozik egy sor. Mivel - ebben a példában csak két - géprõl van szó, ezért a rajtuk - található psk.txt - állományok csak egyetlen sort fognak tartalmazni - (mivel a VPN végein mindig csak a másik - végével kell foglalkoznunk). - - Az elsõ átjárón ez a sor - így néz ki: - - W.X.Y.Z titkos_jel - - Tehát itt szerepel a távoli végpont - publikus IP-címe, amitõl - láthatatlan karakterekkel választjuk a titkos - jelet szimbolizáló szöveget. Itt persze ne - a titkos_jel jelet használjuk — - ide inkább valami jelszószerûséget - képzeljünk el. - - A második átjárón ez a sor - szerepel: - - A.B.C.D titkos_jel - - Ez a másik távoli végpont publikus - IP-címe és ugyanaz a titkos jel. A - racoon futtatása elõtt - a psk.txt állománynak a - 0600 kódú engedélyeket - állítsuk be (vagyis csak a - root legyen képes írni - és olvasni). - - A racoonnak mind a két - átjárón futnia kell. Az IKE - akadálytalan közlekedéséhez a - tûzfalaikba is fel kell vennünk néhány - szabályt, ami általában UDP-n és - az internetes biztonsági összerendelések - kulcskezelõ protokolljának (Internet Security - Association Key Management Protocol, ISAKMP) portján - üzemel. Ezt rakjuk minél elõbbre a - tûzfalunkban. - - ipfw add 1 allow udp from A.B.C.D to W.X.Y.Z isakmp -ipfw add 1 allow udp from W.X.Y.Z to A.B.C.D isakmp - - - Miután mûködik a - racoon, próbáljuk meg - az egyik átjáróról pingelni a - másikat. A kapcsolat még mindig nem - titkosított, de a racoon - már felállítja a két gép - közti biztonsági összerendelést - — ez eltarthat egy ideig, amit a pingekre - érkezõ válaszok apró - késlekedésébõl észre is - vehetünk. - - Ahogy a biztonsági összerendelés - létrejött, a &man.setkey.8; paranccsal meg is - nézhetjük. Ehhez futtassuk a következõ - parancsot valamelyik gépen: - - setkey -D - - Ez a probléma egyik fele. A másik fele - pedig a biztonsági házirend - felállítása. - - Egy értelmes biztonsági házirend - kialakításához elõször - tekintsük át mit is állítottunk be - eddig. Ez az összefoglalás az - összeköttetés mindkét - végére vonatkozik. - - Mindegyik elküldött IP-csomagnak fejléce - van, ami adatokat tartalmaz a csomagról. A - fejléc tartalmazza a forrás és a - cél IP-címét. Korábbról - pedig már tudjuk, hogy a privát IP-címek, - mint mondjuk a 192.168.x.y, az - interneten nem jelenhet meg. Ehhez elõször be kell - csomagolnunk egy másik csomagba. Ennek a csomagnak a - privát címek helyett a publikus forrás - és cél IP-címét kell - tartalmaznia. - - Tehát a kimenõ csomagunk valahogy így - néz ki: - - - - - - - - - .----------------------. - | Forrás : 192.168.1.1 | - | Cél : 192.168.2.1 | - | <a fejléc többi része> | - +----------------------+ - | <a csomag adatai> | - `----------------------' - - - - Amelyet ezután egy ehhez hasonló csomagba - fogunk becsomagolni: - - - - - - - - - .--------------------------. - | Forrás : A.B.C.D | - | Cél : W.X.Y.Z | - | <a fejléc többi része> | - +--------------------------+ - | .----------------------. | - | | Forrás : 192.168.1.1 | | - | | Cél : 192.168.2.1 | | - | | <a fejléc többi része> | | - | +----------------------+ | - | | <a csomag adatai> | | - | `----------------------' | - `--------------------------' - - - - Az imént felvázolt csomagolást a - gif eszköz fogja végezni. - Most már láthatjuk azt is, hogy a csomag - kifelé valós IP-címmel rendelkezik, - miközben az eredeti csomag adatként becsomagoltuk - és feladtunk az interneten keresztül. - - Értelemszerûen a VPN teljes forgalmát - titkosítani akarjuk. Részletesebben - kifejtve: - - Amikor egy csomag elhagyja az A.B.C.D gépet a W.X.Y.Z gép felé, akkor a - szükséges biztonsági - összerendelések - felhasználásával - kódoljuk. - - Amikor az A.B.C.D - címrõl megérkezik egy csomag a W.X.Y.Z címre, akkor a - szükséges biztonsági - összerendelési - felhasználásával - kikódoljuk. - - Ez már majdnem jó, de nem teljesen pontos. - Ha csak ennyit csinálnánk, akkor a W.X.Y.Z címrõl - érkezõ forgalmat olyankor is - titkosítanánk, amikor az nem része a - VPN-nek. Mi viszont nem erre gondoltunk. Ezért a - megfelelõ házirend az alábbi: - - Amikor egy csomag elhagyja az A.B.C.D címet a W.X.Y.Z cím felé, - és ez a csomag egy másik csomagot tartalmaz, - akkor a szükséges biztonsági - összerendelések - felhasználásával - kódoljuk. - - Amikor az A.B.C.D - címrõl megérkezik egy csomag a W.X.Y.Z címre, és ez a - csomag egy másik csomagot tartalmaz, akkor a - szükséges biztonsági - összerendelések - felhasználásával - kikódoljuk. - - Finom de lényeges - különbség. - - A biztonsági házirendet a &man.setkey.8; - segítségével egy adott - konfigurációs nyelven leírva is be tudjuk - állítani. Ilyenkor vagy közvetlenül a - szabványos bemenetrõl adjunk - utasításokat vagy az - opció használatával megadjuk azt az - állományt, amely tartalmazza a - konfigurációs utasításokat. - - Az elsõ átjárón (amelynek a - publikus IP-címe A.B.C.D) így tudjuk az - összes W.X.Y.Z felé - haladó forgalom titkosítását - kikényszeríteni: - - -spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P out ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require; - - - Tegyük ezt a parancsot egy állományba - (például /etc/ipsec.conf) - és adjuk ki a következõ parancsot: - - &prompt.root; setkey -f /etc/ipsec.conf - - Az arra utasítja a - &man.setkey.8; programot, hogy egy szabályt akarunk - felvenni a biztonsági házirendeket - tároló adatbázisba. A sor többi - része a rendelkezésnek megfelelõ csomagokat - írja le. A A.B.C.D/32 - és W.X.Y.Z/32 - adják meg azokat az IP-címeket és - hálózati maszkokat, amelyekre az adott - rendelkezés vonatkozik. Ebben az esetben mi most a - két gép közti forgalomra vonatkoztatunk. - Az azt árulja el a - rendszermagnak, hogy ezt a rendelkezést csak a csomagok - tartalmazó csomagokra kell alkalmazni. A szerint pedig ez a rendelkezés csak a - kimenõ csomagokra értendõ, valamint az - miatt védeni kell az ilyen - csomagokat. - - Ezt követõen a csomag - titkosításáról nyilatkozunk. Erre - az protokollt használjuk, - miközben a jelzi, hogy a csomagot - beraktuk egy IPsec csomagba. A A.B.C.D és W.X.Y.Z címeket azért - adtuk meg ismét, mert ezzel azonosítjuk be a - használni kívánt biztonsági - összerendelést. Végezetül a - szabályozza, hogy a - feltételeknek megfelelõ csomagot - titkosítani kell. - - Ez a szabály csak a kimenõ csomagokra - illeszkedik. Egy hasonlóra van szükség a - bejövõ csomagok esetén is. - - spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P in ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require; - - Itt leginkább arra figyeljünk, hogy ebben az - utasításban szerepel az - helyett, és az IP-címeket - pedig felcseréltük. - - A másik átjárón (amely a - W.X.Y.Z publikus IP-címmel - rendelkezik) hasonló szabályokra lesz - szükségünk. - - spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P out ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require; -spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P in ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require; - - Végsõ lépésként a - tûzfalakban oda-vissza engedélyeznünk kell az - ESP és IPENCAP csomagokat. Ezeket a szabályokat - is fel kell vennünk mind a két - átjáró esetén. - - ipfw add 1 allow esp from A.B.C.D to W.X.Y.Z -ipfw add 1 allow esp from W.X.Y.Z to A.B.C.D -ipfw add 1 allow ipencap from A.B.C.D to W.X.Y.Z -ipfw add 1 allow ipencap from W.X.Y.Z to A.B.C.D - - - Mivel a szabályok szimmetrikusak, ezért mind - a két helyen használhatjuk ezeket. - - A kimenõ csomagok ennek megfelelõen így - fognak kinézni: - - - - - - - - - .------------------------------. --------------------------. - | Forrás : A.B.C.D | | - | Cél : W.X.Y.Z | | - | <a fejléc többi része> | | A titkosított - +------------------------------+ | csomag. A - | .--------------------------. | -------------. | tartalmát - | | Forrás : A.B.C.D | | | | teljesen - | | Cél : W.X.Y.Z | | | | levédtük az - | | <a fejléc többi része> | | | |- avatatlan - | +--------------------------+ | | A csoma- | szemek elõl. - | | .----------------------. | | -. | golt cso- | - | | | Forrás : 192.168.1.1 | | | | Eredeti |- mag, va- | - | | | Cél : 192.168.2.1 | | | | csomag, | lódi IP | - | | |<a fejléc többi része>| | | |- privát | | - | | +----------------------+ | | | IP | | - | | | <a csomag adatai> | | | | | | - | | `----------------------' | | -' | | - | `--------------------------' | -------------' | - `------------------------------' --------------------------' - - - - - Amikor a csomag megkérkezik a VPN másik - végére, akkor elõször feloldjuk a - titkosítását (a - racoon által - felállított biztonsági - összerendelésen használatával). - Ezután továbbhalad a - gif felületére, amely - kibontja a második réteget, ahonnan - távozik a legbelsõ csomag a belsõ - hálózat felé. - - A &man.ping.8; használatával a - korábban már bemutatott módon tudjuk - tesztelni a hálózat - biztonságosságát. Ehhez - elõször is jelentkezzünk be a A.B.C.D átjáróra - és gépeljük be: - - tcpdump dst host 192.168.2.1 - - Ugyanazon a gépen egy másik - parancsértelmezõbõl pedig futtassuk ezt - is: - - ping 192.168.2.1 - - Ezúttal a következõt kell - tapasztalnunk: - - ide kell még a tcpdump kimenete - - Most már &man.tcpdump.1; ESP csomagokat mutat. Ha - a opcióval megpróbálunk - nekiesni a csomagoknak, akkor a titkosítás miatt - (nyilvánvalóan) csak zagyvaságokat - kapunk. - - Gratulálunk! Sikerült VPN kapcsolatot - felépíteni két távoli - hálózat között. - - - Összefoglalás - - - Állítsuk be mind a két - rendszermag esetén: + + + + + Tom + Rhodes + +
trhodes@FreeBSD.org
+ + Írta: + + + - options IPSEC -options IPSEC_ESP - - - - Telepítsük a security/ipsec-tools portot. - Írjuk át a - ${PREFIX}/etc/racoon/psk.txt - állományt mind a két gépen - úgy, hogy kölcsönöesen - felvesszük bennüka távoli - számítógépek IP-címeit - és a közös titkos jelzésüket. - Ne felejtsük el az engedélyeit 0600-ra - állítani. - - - A gépek /etc/rc.conf - állományaihoz adjuk hozzá a - következõ sort: + 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 +# 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; + + 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 - ipsec_enable="YES" -ipsec_file="/etc/ipsec.conf" - - - - Mindegyik gépen hozzunk létre egy - /etc/ipsec.conf nevû - állományt, amelybe másoljuk be a - beüzemeléshez szükséges - spdadd sorokat. Az elsõ - hálózat - átjáróján ez így - néz ki: - - -spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P out ipsec - esp/tunnel/A.B.C.D-W.X.Y.Z/require; -spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P in ipsec - esp/tunnel/W.X.Y.Z-A.B.C.D/require; - - - A második hálózat - átjáróján pedig - így: - - -spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P out ipsec - esp/tunnel/W.X.Y.Z-A.B.C.D/require; -spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P in ipsec - esp/tunnel/A.B.C.D-W.X.Y.Z/require; - - - - Bõvítsük ki a tûzfal - gépek közti szabályait az IKE, ESP - és IPENCAP protokollok - engedélyezésével: - - -ipfw add 1 allow udp from A.B.C.D to W.X.Y.Z isakmp -ipfw add 1 allow udp from W.X.Y.Z to A.B.C.D isakmp -ipfw add 1 allow esp from A.B.C.D to W.X.Y.Z -ipfw add 1 allow esp from W.X.Y.Z to A.B.C.D -ipfw add 1 allow ipencap from A.B.C.D to W.X.Y.Z -ipfw add 1 allow ipencap from W.X.Y.Z to A.B.C.D - - - - - Ez a két lépés már - elegendõ egy VPN összerakásához - és mûködtetéséhez. Az egyes - hálózatokon levõ gépek most - már képesek IP-címekkel egymásra - hivatkozni, és a köztük levõ - összeköttetésen átfolyó - összes adat autmatikusan és biztonságosan - titkosításra kerül. + + 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 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/serialcomms/chapter.sgml b/hu_HU.ISO8859-2/books/handbook/serialcomms/chapter.sgml index cbe0933bdc..129463198d 100644 --- a/hu_HU.ISO8859-2/books/handbook/serialcomms/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/serialcomms/chapter.sgml @@ -1,3984 +1,3963 @@ Soros vonali kommunikáció Áttekintés soros kommunikáció A &unix; mindig is támogatta a soros vonali kommunikációt. Tulajdonképpen az elsõ &unix;-os gépek is soros vonalon kapták a felhasználóktól a bemenetet és ugyanígy küldték vissza a kimenetet. Az idõk azóta már sokat változtak, hogy egy átlagos terminál mindössze egy 10 karakter per másodperc sebességû soros nyomtatóból és egy billentyûzetbõl állt. Ebben a fejezetben ismertetünk néhány olyan megoldást, amellyel a &os; képes soros vonalon keresztül kommunikálni. A fejezet elolvasása során megismerjük: hogyan kapcsoljunk terminálokat a &os; rendszerünkre; hogyan tárcsázzunk modem segítségével távoli számítógépeket; hogyan tegyük lehetõvé gépünkre a bejelentkezést távoli felhasználók számára; hogyan indítsuk a rendszerünket soros konzolról. A fejezet elolvasásához ajánlott: egy új rendszermag beállításának és telepítésének ismerete (); a &unix;-os engedélyek és a &unix; alatt futtatott programok mûködtetésének megértése (); annak a soros vonali hardvernek (modemnek vagy többportos kártyának a) kézikönyve, amelyet a &os;-vel használni szeretnénk Bevezetés Alapfogalmak bit per másodperc bps Bit per másodperc — az adatátvitel sebessége DTE DTE Adatterminál eszköz (Data Terminal Equipment) — ez például a számítógépünk DCE DCE Adatkommunikációs eszköz (Data Communications Equipment) — ez a modem RS-232 RS-232C kábel a hardveres soros vonali kommunikációhoz szükséges EIA szabványú kábel Amikor ebben a fejezetben az adatátvitel sebességérõl beszélünk, akkor szándékosan nem használjuk a baud fogalmát. A baud ugyanis a kommunikációs eszközben adott idõ alatt lezajló jelváltások mennyiségét jelöli, miközben itt a bps (bit per másodperc) kifejezés használata a helyes (vagy legalább is a szõrszálhasogatók egyelõre megnyugodhatnak). Kábelek és portok Ha a &os; rendszerünkhöz egy modemet vagy egy terminált akarunk csatlakoztatni, akkor ahhoz a számítógépünkben szükség lesz egy szabad soros portra és egy megfelelõ típusú kábelre. Ha már tisztában vagyunk a rendelkezésre álló hardverrel és a hozzátartozó kábellel, akkor nyugodtan átléphetjük ezt a részt. A kábelek fajtái A soros kábeleknek több különbözõ típusa van. Közülük a céljainknak leginkább megfelelõ két legismertebb változatuk az ún. null-modem és a szabványos (egyenes) RS-232-es soros kábelek. A hardverhez tartozó dokumentációban megtaláljuk, hogy pontosan melyik típus tartozik hozzá. A null-modem kábelek null-modem kábel Egy null-modem kábel bizonyos jeleket, többek közt a földet (Signal Ground, SG), egyenesen küldi, másokat viszont felcserélten. Például az átküldött adat (Transmitted Data, TD) jelzésû tû a kábel másik végén a fogadott adat (Received Data, RD) tûhöz fut be. A terminálokhoz akár saját magunk is le tudunk gyártani egy null-modem kábelt (például ha a boltiakkal nem lennénk megelégedve). A következõ táblázatban az RS-232C jeleit és érintkezõinek számozását láthatjuk egy DB-25-ös csatlakozó esetében. A szabvány a kábel két 1-es tûjét összekapcsoló vonalat védõföldnek (Protective Ground, PD) nevezi, de ezt gyakran el is hagyják. Némely terminál remekül mûködik mindössze a 2-es, 3-as és 7-es tûk használatával, miközben mások az iménti példától eltérõ kiosztást igényelnek. A DB-25 DB-25 közti null-modem kábel Jel Tû Tû Jel SG 7 párja: 7 SG TD 2 párja: 3 RD RD 3 párja: 2 TD RTS 4 párja: 5 CTS CTS 5 párja: 4 RTS DTR 20 párja: 6 DSR DTR 20 párja: 8 DCD DSR 6 párja: 20 DTR DCD 8 párja: 20 DTR
Íme a mostanság elterjedt másik két séma. A DB-9 DB-9 közti null-modem kábel Jel Tû Tû Jel RD 2 párja: 3 TD TD 3 párja: 2 RD DTR 4 párja: 6 DSR DTR 4 párja: 1 DCD SG 5 párja: 5 SG DSR 6 párja: 4 DTR DCD 1 párja: 4 DTR RTS 7 párja: 8 CTS CTS 8 párja: 7 RTS
DB-9 DB-25 közti null-modem kábel Jel Tû Tû Jel RD 2 párja: 2 TD TD 3 párja: 3 RD DTR 4 párja: 6 DSR DTR 4 párja: 8 DCD SG 5 párja: 7 SG DSR 6 párja: 20 DTR DCD 1 párja: 20 DTR RTS 7 párja: 5 CTS CTS 8 párja: 4 RTS
Amikor egy tû az átellenes oldalon két másik tûhöz csatlakozik, akkor azt általában úgy valósítják meg, hogy a két tût a saját oldalukon összekötik, majd ezt kapcsolják hozzá a harmadik tûhöz. Ezek a megoldások a legnépszerûbbek. Természetesen a tûk összekötésének több más variációja is létezik (ezekrõl az RS-232 Made Easy c. könyvben olvashatunk bõvebben), ahol az SG párja az SG, a TD párja az RD, az RTS és a CTS párja az DCD, a DTR párja a DSR és ugyanezek fordítva. Szabványos RS-232C kábelek RS-232C kábel A szabványos soros kábel az összes RS-232C jelet közvetlenül átküldi. Vagyis a kábel egyik végén levõ átküldött adat tû a másik végén is az átküldött adat tûhöz csatlakozik. Az ilyen típusú kábeleket többnyire a számítógépek és a modemek között alkalmazzák, de egyes termináltípusok esetében is szükségünk lehet rá. A portok A soros port olyan eszköz, amelyen keresztül a &os;-s gép és a terminál között adatokat tudunk közvetíteni. Ebben a szakaszban az ilyen portok különféle típusait és ezek használatát ismertetjük &os; alatt. A portok típusai A soros portoknak több típusa létezik. Mielõtt vásárolnánk egy készítenénk egy soros kábelt, mindenképpen gyõzödjünk meg róla, hogy csatlakoztatni tudjuk majd a &os;-s rendszerünkhöz és a terminálhoz egyaránt. A legtöbb terminálon DB-25-ös portot találunk. A személyi számítógépek, köztük azok, amelyeken &os; fut, DB-25-ös és DB-9es portokkal rendelkeznek. Ha a gépünkben egy többportos soros kártya van, akkor ezeken kívül még RJ-12-es és RJ-45-ös portjaink is lehetnek. A hardverhez tartozó dokumentációból tudjuk kideríteni az adott port konkrét fajtáját, de gyakran a port vizuális vizsgálata is segíthet eldönteni a kérdést. A portok nevei &os; alatt az egyes soros portokat a /dev könyvtárban található eszközleírókon keresztül tudjuk elérni. Ezeknek két típusa van: A behíváshoz használt portok nevei /dev/ttydN alakúak, ahol az N a port sorszáma, ami nullától indul. A behívó portok alapvetõen a terminál esetében használatosak. A behívó portok használatához a soros vonalon az vonal észlelése (Data Carrier Detect, DCD) jelnek kell megbízhatóan mûködnie. A híváshoz használt portok nevei /dev/cuadN alakúak. A hívó portokat terminálok esetében ritkán alkalmazzák, helyettük inkább csak modemekhez használják. A hívó portokat akkor érdemes használni, ha a soros kábel vagy a terminál nem ismeri a DCD jelet. Ha a terminált az elsõ soros portra (ami &ms-dos;-ban a COM1) csatlakoztattuk, akkor a /dev/ttyd0 segítségével fogunk rá hivatkozni. Ha viszont a második soros porton (más néven COM2) található, akkor a /dev/ttyd1 eszközt használjuk, és így tovább. A rendszermag beállítása A &os; alapból négy soros portot támogat. Az &ms-dos; világban ezeket rendre COM1, COM2, COM3 és COM4 portoknak nevezik. A &os; jelen pillanatban ismeri még a butább többportos soros csatolókártyákat is, például a BocaBoard 1008 és 2016 típusokat, valamint több intelligensebb többportos kártyát, például a Digiboard és a Stallion Technologies gyártmányait. Az alap rendszermag azonban csak a szabványos COM portokat keresi. Ha ellenõrizni akarjuk, hogy a rendszermag rendben megtalálta a soros portokat, akkor figyelmesen olvassuk el a rendszerindítás során megjelenõ üzeneteket, vagy az /sbin/dmesg parancs kiadásával kérdezzük vissza a rendszermag üzeneteit. Különösen a sio kezdetû sorokra kell figyelnünk. Az alábbi paranccsal tudjuk leszûrni a sio szövegrészt tartalmazó sorokat: &prompt.root; /sbin/dmesg | grep 'sio' Például, ha négy soros port található a rendszerünkben, akkor a rájuk vonatkozó rendszerüzenetek a következõk lesznek: sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A sio2 at 0x3e8-0x3ef irq 5 on isa sio2: type 16550A sio3 at 0x2e8-0x2ef irq 9 on isa sio3: type 16550A Ha a rendszermagunk nem ismerte volna fel az összes soros portot, akkor valószínûleg a /boot/device.hints állományt kell módosítanunk. Tegyük megjegyzésbe vagy akár teljesen távolítsuk is el azokat az eszközöket, amelyekkel nem rendelkezünk. A soros portok és a többportos kártyák beállításával kapcsolatban a &man.sio.4; man oldalát olvassuk el. Óvatosan bánjunk a &os; megelõzõ változataiból származó konfigurációs állományokkal, mert az eszközök vonatkozó beállításokat és azok formátuma megváltozhatott azóta. Az port IO_COM1 a port 0x3f8, az IO_COM2 a 0x2f8, az IO_COM3 a 0x3e8 és az IO_COM4 a 0x2e8 beállítást helyettesíti. Ezek az adott porthoz tartozó gyakori címeket képviselik. A 4-es, 3-as, 5-ös és 9 megszakítások is igen általánosak ezeknél. A hagyományos soros portok viszont az ISA buszos PC-k esetében nem képesek a megszakításokon osztozni. (A többportos kártyák azonban lehetõvé teszik az 16550A számára, hogy mindössze egy vagy két megszakítást használjon.) Speciális eszközállományok A rendszermagban található legtöbb eszköz az ún. speciális eszközállományokon keresztül érhetõ el, melyek a /dev könyvtárban találhatóak. A sio eszközök a /dev/ttydN (behívó portok) és /dev/cuadN (hívó portok) állományok használatával érhetõek el. A &os; ezenkívül még külön eszközállományokat biztosít az inicializációhoz (/dev/cuadN.init) és a zároláshoz (/dev/cuadN.lock). Az inicializációs állományok a port megnyitásakor használhatóak a hozzátartozó paraméterek beállítására, például így tudjuk elküldeni a crtscts utasítást az olyan modemeknek, amelyek a forgalom irányítását RTS/CTS jelzéseken keresztül valósítják meg. A zároló állományokkal a portokra vonatkozó zárolásokat állíthatjuk be, így a felhasználók vagy a programok nem lesznek képesek bizonyos paramétereket megváltoztatni. A &man.termios.4;, &man.sio.4; és &man.stty.1; man oldalakon olvashatunk részletesebben a terminálok beállításairól, valamint az eszközök zárolásáról és inicializálásáról. A soros port beállítása ttyd cuad A ttydN (vagy cuadN) lesz az az eszköz, amit majd az alkalmazásainkból el akarunk érni. Amikor egy futó program megnyit egy ilyen eszközt, mindig tartoznak hozzá alapértelmezett terminál I/O beállítások. Ezeket a következõ paranccsal tudjuk lekérdezni: &prompt.root; stty -a -f /dev/ttyd1 Ha megváltoztatjuk az eszköz beállításait, akkor azok egészen addig érvényben is maradnak, amíg le nem zárjuk. Ha tehát ezután újra megnyitjuk, akkor minden visszaáll az alapértelmezett állapotra. Az alapértelmezett beállítások megváltoztatásához a kezdeti állapotot szimbolizáló eszközt kell megnyitnunk és átállítanunk. Például, ha alapból engedélyezni akarjuk a módot, a 8 bites kommunikációt és a típusú forgalomirányítást a ttyd5 eszközön, akkor a következõt gépeljük be: &prompt.root; stty -f /dev/ttyd5.init clocal cs8 ixon ixoff rc állományok rc.serial A soros eszközök rendszerszintû inicializálását az /etc/rc.d/serial állomány vezérli. Lényegében ez határozza meg az összes soros eszköz alapértelmezett beállítását. Ha bizonyos beállítások megváltoztatását tiltani szeretnénk az alkalmazások felé, akkor azt a zárolt állapotot tartalmazó eszközben kell rögzítenünk. Például, ha a ttyd5 eszköz sebességét fixen 57600 bps-ra akarjuk beállítani, akkor írjuk be ezt: &prompt.root; stty -f /dev/ttyd5.lock 57600 Ezután ha egy alkalmazás megnyitja a ttyd5 eszközt és megpróbálja a port sebességét átállítani, akkor az továbbra is 57600 bps marad. A kezdeti és a zárolt állapotot képezõ eszközöket általában csak a root felhasználó számára szabad írhatóvá tenni. Sean Kelly Készítette: Terminálok terminálok A terminálok olyankor kínálnak kényelmes és költséghatékony hozzáférést a &os; rendszerünkhöz, amikor sem a gép konzolját, sem pedig a hozzátartozó hálózatot nem érjük el. Ebben a szakaszban olvashatjuk, miként kell terminálokat használni &os; alatt. A terminálok alkalmazásai és típusai Az eredeti &unix; rendszereknek nem voltak konzoljaik. Ehelyett az emberek a soros portokra csatlakoztatott terminálokon keresztül jelentkeztek be és így futtattak rajtuk programokat. Ez nagyon hasonlít ahhoz, mint amikor egy modem és egy terminálprogram felhasználásával betárcsázunk egy távoli gépre és vele szöveges módban dolgozunk. Napjaink személyi számítógépein azonban találhatunk már akár nagy felbontású megjelenítéssel megáldott konzolokat is, habár a soros porton keresztüli bejelentkezés lehetõsége még mind a mai napig elérhetõ a legtöbb &unix;-alapú rendszerben. Ez alól a &os; sem kivétel. Ha rákötünk egy terminált a gépünk egyik üres soros portjára, akkor a megszokott módon képesek vagyunk bejelentkezni a rendszerbe és futtatni bármilyen szöveges programot, hasonlóan ahhoz, ahogy azt a konzolban vagy az X Window Systemben egy xterm ablakban megtehetjük. Ha egy irodában vagyunk, akkor egy &os; rendszerre több terminált is kapcsolhatunk, melyek az alkalmazottak asztalain foglalnak helyet. Otthoni használat esetén egy kiöregedett számítógép, például egy régi IBM PC vagy egy &macintosh; is ráköthetõ egy gyorsabb &os; rendszerre. Ennek segítségével az egyébként egyfelhasználós számítógépünket egy valódi többfelhasználós rendszerré alakíthatjuk. A &os; esetén háromféle terminálról beszélhetünk: A buta (dumb) terminálok A terminálként funkcionáló személyi számítógépek Az X terminálok A most következõ alszakaszokban ezeket fejtjük ki részletesebben. A buta terminálok A buta terminál alatt olyan speciálizált eszközt értünk, amellyel soros vonalon keresztül csatlakozunk számítógépekhez. Azért nevezik ezeket butának, mert csupán annyi számítási teljesítményt zsúfoltak beléjük, hogy szöveget legyenek képesek küldeni, fogadni és megjeleníteni. Semmilyen program nem képes rajtuk futni. Helyette az a számítógép fogja a szövegszerkesztõt, fordítóprogramot, levelezõ klienst, játékot és a többit futtatni, amelyre vele kapcsolódtunk. A buta termináloknak többszáz, különbözõ gyártmányú fajtája létezik. Ilyenek például a Digital Equipment VT-100 vagy a Wyse WY-75 típusú termináljai. A &os; szinte mindegyiküket ismeri. Egyes drágább terminálok még grafikus megjelenítésre is képesek, de ezeket a lehetõségeket csak bizonyos szoftverek tudják ténylegesen kihasználni. A buta terminálok leginkább olyan munkahelyeken terjedtek el, ahol az alkalmazottaknak nincs szükségük grafikus alkalmazások, tehát például az X Window System használatára. Személyi számítógépek mint terminálok Ha egy buta terminál csupán szöveg küldésére, fogadására és megjelenítésére képes, akkor bármelyik személyi számítógép utána tudja mindezt csinálni. Ehhez mindössze egy megfelelõ kábelre és az adott gépen futó terminál emulációs szoftverre van szükségünk. Az ilyen fajta megoldás nagyon elterjedt az otthoni használat esetén. Például, ha valamelyik családtagunk éppen szorgalmasan dolgozik a &os; rendszerkonzolján, akkor a rákapcsolt terminálon keresztül még mi magunk is el tudunk végezni valamennyi szöveges felületet igénylõ munkát. Az alap &os; rendszerben legalább két segédprogram használható a soros vonali kapcsolaton keresztüli munkára: a &man.cu.1; és a &man.tip.1;. Egy &os; rendszerû kliensrõl így tudunk csatlakozni egy másik rendszerre: &prompt.root; cu -l soros-vonali-eszköz Ahol a soros-vonali-eszköz a rendszerünkben a soros portot jelölõ speciális eszköz neve. Az ilyen eszközök neve /dev/cuadN. Az eszköz nevében az N-es rész a soros port sorszámát adja meg. A &os;-ben az eszközök sorszámozása nullától kezdõdik, nem pedig egytõl (ellentétben tehát azzal, ahogy azt az &ms-dos; rendszerekben és leszármazottaikban már megszokhattuk). Ez azt jelenti, hogy amit az &ms-dos; alapú rendszerekben COM1-nek hívnak, az a &os;-ben általában a /dev/cuad0. Egyes emberek más, többnyire a Portgyûjteménybõl is elérhetõ programokat szeretnek inkább használni. A portok között találhatunk elég sok olyan szoftvert, amely a &man.cu.1; és a &man.tip.1; programokhoz hasonlóan mûködik. Ilyen például a comms/minicom. Az X terminálok Az X terminálok a terminálok közül a legfejlettebbek. Általában nem is soros porton, hanem hálózaton, például Etherneten keresztül csatlakoznak. Természetesen nem csak szöveges alkalmazásokat, hanem lényegében bármilyen X alkalmazást képesek megjeleníteni. Az X terminálokról itt most csak a teljesség kedvéért szólunk, de ebben a fejezetben nem szándékozunk tárgyalni az X terminálok csatlakoztatását, beállítását és használatát. Beállítás Ebben a fejezetben ismertetjük mindazt, ami ahhoz kell, hogy a &os; rendszerünkön engedélyezni tudjuk a terminálon keresztüli bejelentkezéseket. Feltételezzük, hogy a rendszermagunk támogatja a terminálok által használt soros portokat, illetve, hogy ezeket már csatlakoztattuk is. Ha visszagondolunk a re, akkor eszünkbe juthat, hogy a rendszer indításakor az init nevû program felelõs az összes futó program irányításáért és inicializálódásáért. Az init egyik feladata, hogy beolvassa az /etc/ttys állományt és neki megfelelõen az elérhetõ terminálokon elindítsa a getty programot. A getty felelõs a bejelentkezéshez szükséges azonosító beolvasásáért és a login program elindításáért. Ennek megfelelõen tehát, ha a &os; rendszerünkön terminálokat akarunk beállítani, akkor ehhez a következõ lépéseket kell megtennünk root felhasználóként: Az /etc/ttys állományba vegyünk fel egy bejegyzést a soros porthoz tartozó /dev könyvtárbeli eszközhöz, ha még nem szerepelne benne. A porthoz adjuk meg a /usr/libexec/getty programot, majd hozzá az /etc/gettytab állományból válasszuk ki a megfelelõ getty típust. Adjuk meg a terminál alapértelmezett típusát. Állítsuk a portot on (bekapcsolt) állapotúra. Adjuk meg, hogy a port secure (biztonságos) legyen-e. Mondjuk meg az init programnak, hogy olvassa újra az /etc/ttys állományt. A másik lépés kiegészítõ lépéseként az /etc/gettytab állományban mi magunk is létrehozhatunk egy saját getty típust. A fejezetben ehhez ugyan nem adunk segítséget, de ha érdekel minket a téma, akkor ezzel kapcsolatban a &man.gettytab.5; és &man.getty.8; man oldalakat érdemes elolvasni. Egy bejegyzés felvétele az <filename>/etc/ttys</filename> állományba Az /etc/ttys állományban találhatjuk meg az összes portot, ahonnan a &os; rendszerünk engedélyezi a bejelentkezést. Például a ttyv0, az elsõ virtuális konzol is szerepel benne. Ezen a bejegyzésen keresztül tudunk bejelentkezni a konzolra. Ebben az állományban találjuk meg még a többi virtuális konzol, soros port és pszeudoterminál bejegyzéseit is. A rögzített terminálok esetén egyszerûen csak adjuk meg a soros porthoz tartozó /dev könyvtárbeli eszközt a /dev elõtag nélkül (így például a /dev/ttyv0 ttyv0 néven fog megjelenni). Az alap &os; telepítésben egy olyan /etc/ttys állomány található, amely tartalmazza az elsõ négy soros portot, a ttyd0 eszköztõl kezdve a ttyd3 eszközig. Ha tehát ezekre a portokra csatlakoztatnunk egy terminált, akkor már nem kell egy újabb bejegyzést felvennünk hozzájuk. Terminálok felvétele az <filename>/etc/ttys</filename> állományba Tegyük fel, hogy két eszközt szeretnénk a rendszerünkhöz csatlakoztatni: egy Wyse-50-es terminált és egy régi 286-os IBM PC-t, amelyen a Procomm terminálszoftverrel emulálunk egy VT-100-as terminált. A Wyse terminált a második soros portunkra kötjük, míg a 286-ost a hatodik soros portra (például egy többportos soros vonali kártyán). A nekik megfelelõ /etc/ttys állománybeli bejegyzések így fognak kinézni: ttyd1 "/usr/libexec/getty std.38400" wy50 on insecure ttyd5 "/usr/libexec/getty std.19200" vt100 on insecure Az elsõ mezõben általában a terminálhoz tartozó eszközt nevezzük meg, amely a /dev könyvtárban található. A második mezõ a vonalhoz tartozó végrehajtandó parancs, ami általában a &man.getty.8;. A getty mûködésbe helyezi és megnyitja a vonalat, beállítja a sebességét, bekéri a felhasználó nevét, majd elindítja a &man.login.1; programot. A getty program egy (opcionális) paramétert fogad el a parancssorában, ami a getty típusa. Egy ilyen getty típus szabja meg a terminálhoz tartozó vonal jellemzõit, például az adatátviteli sebességet és a paritást. A getty ezeket a jellemzõket az /etc/gettytab állományból olvassa be. A /etc/gettytab egyaránt tartalmaz bejegyzéseket a régi és új típusú terminálokhoz. Az std szöveggel kezdõdõ bejegyzések szinte majdnem minden esetben mûködnek a hardveres terminálokkal. Az ilyen bejegyzések figyelmen kívül hagyják a paritást. 110 és 115 200 bps között minden adatátviteli sebességhez tartozik egy-egy std bejegyzés. Természetesen ebbe az állományba akár a saját bejegyzéseinket is elkészíthetjük. A &man.gettytab.5; man oldal nyújt ehhez átfogó segítséget. Amikor az/etc/ttys állományban megadjuk a getty típusát, akkor ellenõrizzük, hogy a beállításai megfelelnek a terminálénak. A példánknál maradva: a Wyse-50 nem használ paritást és 38 400 bps-en üzemel. A 286-os gép szintén nem dolgozik paritással és 19200 bps-sel kapcsolódik. A harmadik mezõben adjuk meg általában a vonalra csatlakozó terminál típusát. Ez a betárcsázós portok esetében többnyire az unknown vagy a dialup, mivel ezeken keresztül a felhasználók gyakorlatilag szinte bármilyen típusú terminállal vagy szoftverrel be tudnak jelentkezni. A hardveres termináloknál a terminál típusa azonban nem változik, ezért a &man.termcap.5; adatbázisban keressük ki a nekik megfelelõt és adjuk meg ebben a mezõben. A példánkban a Wyse-50 egy valós termináltípust használ, miközben a 286-oson futó Procomm egy VT-100-as típusú terminált emulál. A negyedik mezõ azt mondja meg, hogy a port engedélyezett-e vagy sem. Ha itt a on értéket adjuk meg, akkor az init elindítja a második mezõben szereplõ getty programot. Ha viszont itt az off szerepel, akkor a getty nem fog elindulni, így ezen a porton be sem fogunk tudni jelentkezni. Az utolsó mezõben a port megbízhatóságát kell megjelölnünk. Ha biztonságosnak (secure) állítjuk be a portot, akkor rajta keresztül a root (vagy bármelyik nullás felhasználói azonosítóval rendelkezõ) felhasználó be tud jelentkezni. Amikor viszont nem biztonságos (insecure), akkor elõször egy normál felhasználóval kell bejelentkeznünk, majd a &man.su.1; programmal vagy egy hozzá hasonló megoldással kell rendszeradminisztrátorrá válnunk. Leginkább az insecure beállítást javasoljuk, még hét lakat alatt õrzött terminálok esetében is. Valójában sokkal egyszerûbb bejelentkezni, majd kiadni egy su parancsot, ha netalán rendszeradminisztrátori jogosultságokra lenne szükségünk. A <command>init</command> utasítása az <filename>/etc/ttys</filename> újraolvasására Miután az /etc/ttys állományban elvégeztük a megfelelõ módosításokat, a konfigurációs állomány újraolvasásához küldjünk egy SIGHUP (bontás) jelzést az init programnak. Mint például: &prompt.root; kill -HUP 1 Mivel mindig az init indul el elsõként a rendszerben, ezért a hozzátartozó azonosító az 1 lesz. Ha mindent jól állítottunk be, a kábelek is a helyükön vannak és a terminálokat is bekapcsoltuk, akkor minden terminálhoz elindul egy getty program, és mindegyikõjükön megjelenik a bejelentkezõ képernyõ. A terminálokkal kapcsolatos hibajelenségek Olykor hiába igyekszünk a lehetõ legaprólékosabban ügyelni minden apró részletre, könnyen elõfordulhat, hogy valamiért a terminál mégsem mûködik rendesen. Következzen most egy lista néhány ismert tünetrõl és azok javasolt gyógymódjairól. Nem jelenik meg a bejelentkezõ képernyõ Ellenõrizzük, hogy a terminált rendesen csatlakoztattuk és áram alá helyeztük. Amikor egy személyi számítógépet használunk terminálnak, akkor nézzük meg, hogy a terminál emulációs program a megfelelõ soros porton fut. Vizsgáljuk meg, hogy a kábel mind a két vége pontosan illeszkedik a portokba. Gyõzõdjünk meg róla, hogy valóban a megfelelõ típusú kábelt használjuk. Nézzük meg, hogy a terminál és a &os; is ugyanazon az adatátviteli sebességen és paritási beállítással megy. Ha képernyõvel rendelkezõ terminálunk van, akkor a kontrasztot és fényerõsséget is ellenõrizzük. Ha nyomtatós terminálunk van, akkor vizsgáljuk meg a papír és a tinta állapotát. Gyõzõdjünk meg róla, hogy a getty valóban fut és rendesen kiszolgálja a terminált. Például a ps paranccsal listázzuk ki az összes jelenleg futó programot és keressük meg köztük a getty programot: &prompt.root; ps -axww|grep getty Ekkor látnunk kell a terminálhoz tartozó bejegyzést. Például, ha a getty második soros portot jelképezõ ttyd1 eszközön fut, és az /etc/gettytab állományból az std.38400 nevû bejegyzést használja, akkor ez jelenik meg: 22189 d1 Is+ 0:00.03 /usr/libexec/getty std.38400 ttyd1 Amennyiben semmilyen getty nem fut, akkor ellenõrizzük, hogy valóban engedélyeztük-e a portot az /etc/ttys állományban. A ttys állomány átírása után ne felejtsük el kiadni a kill -HUP 1 parancsot sem. Ha a getty fut, de a terminálon továbbra sem látjuk a bejelentkezõ képernyõt, vagy megjelenik, de nem tudunk gépelni, akkor elõfordulhat, hogy a terminál vagy kábel nem támogatja a hardveres kézfogást (handshaking). Próbáljuk meg az /etc/ttys állományban levõ std.38400 bejegyzést az 3wire.38400 bejegyzésre kicserélni (de utána ne felejtsük el kiadni a kill -HUP 1 parancsot). A 3wire nagyon hasonlít az std bejegyzéshez, de elhagyja a hardveres kézfogást. A 3wire alkalmazásakor viszont a puffer telítõdésének megelõzése érdekében próbálkozzunk az adatátviteli sebesség csökkentésével vagy engedélyezzük a szoftveres forgalomirányítást. Amikor mindenféle szemét jelenik meg a képernyõn Ellenõrizzük, hogy a &os; és a terminál ugyanazt az adatátviteli sebességet és paritási beállítást használja. Nézzük meg a futó getty programokat, és hogy a megfelelõ getty típussal mennek-e. Ha nem, módosítsuk az /etc/ttys állományt és adjuk ki a kill -HUP 1 parancsot. A karakterek duplán jelennek meg, a jelszó begépelésekor látható Állítsuk át a terminált (vagy a terminál emulációs szofvert) half duplex vagy local echo módról full duplex módra. Guy Helmer Készítette: Sean Kelly Kiegészítette: Betárcsázós szolgáltatások betárcsázós szolgáltatás Amikor egy &os; rendszert akarunk betárcsázós szolgáltatásokhoz beállítani, akkor az nagyon hasonlít a terminálok csatlakoztatásához, azzal a eltéréssel, hogy ilyenkor a terminálok helyett modemekkel kell dolgoznunk. Külsõ kontra belsõ modemek A külsõ modemek sokkal kényelmesebbnek tûnnek betárcsázás szempontjából, mivel az ilyenek gyakran a statikus memóriájukban tárolt paraméterek révén tulajdonképpen félig elõre be vannak állítva és sok esetben a fontosabb RS-232 jeleket külön lámpácskákkal mutatják. A villogó lámpák könnyen elkápráztatják a laikusokat, de emellett igen fontosak a modem mûködõképességének megállapításában is. Ezzel szemben a belsõ modemeken nem található statikus memória, ezért a paramétereik csak DIP kapcsolókkal módosíthatóak. Még ha egy belsõ modemem látunk is lámpákat, akkor sem könnyû figyelni rájuk, mert a gépünk burkolata úgyis eltakarja ezeket. Modemek és kábelek modem Ha külsõ modemet használunk, akkor mindenképpen szükségünk lesz hozzá még egy megfelelõ kábelre is. Egy szabványos RS-232-es soros kábel erre tökéletesen megfelel egészen addig, amíg a normál jeleket így kötötték be rajta: A jelek neve Rövidítés Elnevezés RD Received Data (fogadott adat) TD Transmitted Data (küldött adat) DTR Data Terminal Ready (adatterminál kész) DSR Data Set Ready (adatbeállítás kész) DCD Data Carrier Detect (vonal észlése — az RS-232 fogadást érzékelõ vonala) SG Signal Ground (föld) RTS Request to Send (küldés kérése) CTS Clear to Send (küldés engedélyezése)
A &os;-nek 2400 bps felett a forgalom irányításához az RTS és CTS jelekre van szüksége. A CD jellel állapítja meg, hogy a hívás létrejött vagy a bontották a vonalat, és a DTR jel hozza alapállapotba a modemet a munkamenet befejezése után. Egyes kábelekben nem mindegyik jelet vezették át, így ha például gondjaink akadnak a bejelentkezõ képernyõvel amikor a vonalat bontjuk, akkor érdemes átnéznünk a kábelt. A többi &unix;-szerû operációs rendszerhez hasonlóan a &os; is hardveres jelek segítségével igyekszik kideríteni, hogy a hívás megvalósult vagy bontották a vonalat, valamint a hívás befejezése után így bontja a vonalat és állítja vissza a modemet. A &os; igyekszik elkerülni a parancsok küldését a modem felé, vagy a modem állapotának folyamatos ellenõrzését. Ha már van némi tapasztalatunk a PC-alapú BBS-ek modemes elérését illetõen, akkor valószínûleg értjük ezek okait. A soros vonali felülettel kapcsolatos megfontolások A &os; ismeri az NS8250-, NS16450-, NS16550- és NS16550A alapú EIA RS-232C (CCITT V.24) szabványú kommunikációs felületeket. A 8250-es és a 16450-es eszközök egykarakteres pufferrel rendelkeznek. A 16550-es eszközök 16 karakteres puffert tartalmaznak, amellyel jobb teljesítmény érhetõ el. (A sima 16550-esben levõ hibák miatt azonban ez a 16 karakteres puffer nem használható ki rendesen, ezért lehetõleg a 16550A verziót használjuk). Mivel az operációs rendszer részérõl az egykarakteres eszközök jóval több törõdést igényelnek, mint a 16 karakteres eszközök, ezért inkább a 16550A alapú soros felületi kártyákat ajánljuk. Amikor a rendszer egyszerre több soros portot is kezel, vagy erõs terhelés alatt áll, akkor a 16550A alapú kártyákról általában az is elmondható, hogy kisebb hibával dolgoznak. Egy gyors áttekintés getty Ahogy arról már a terminálok esetében szó esett, az init az összes betárcsázós kapcsolathoz tartozó soros porthoz elindít egy getty programot. Például, ha a modemet a /dev/ttyd0 eszközre kapcsoltuk, akkor a ps ax parancs kimenetében ezt láthatjuk: 4850 ?? I 0:00.09 /usr/libexec/getty V19200 ttyd0 Amikor egy felhasználó felhívja a modemet és az kapcsolódik, akkor a modem egy CD (Carrier Detect) jelet küld. A rendszermag ekkor tudomásul veszi a vonal észlelését és a getty segítségével megindítja a kommunikációt. A getty egy login: szöveget küld át a vonalhoz megadott sebességgel. A getty elkezdi figyelni, hogy a értelmes karakterek érkeznek-e vissza, és egy átlagos konfigurációban, ha ezt szemétnek találja (mert például a modem nem a getty számára beállított sebességgel csatlakozott), akkor megpróbálja egészen addig hangolni a vonal sebességét, amíg feldolgozásra alkalmas karaktereket nem kap. /usr/bin/login Miután a felhasználó megadta a felhasználói nevét, a getty elindítja a /usr/bin/login programot, amely befejezi a beléptetést a felhasználó jelszavának bekérésével és annak elfogadása esetén a hozzátartozó parancsértelmezõ elindításával. A konfigurációs állományok &os; rendszerünkben a betárcsázós kapcsolatok engedélyezéséhez az /etc könyvtárban három állomány módosítására lesz szükségünk. Közülük az elsõ, az /etc/gettytab a /usr/libexec/getty démon beállításait tartalmazza. A második, az /etc/ttys az /sbin/init számára mondja meg, hogy melyik tty eszközökhöz tartozik getty. Végezetül a portok inicializálásához kötõdõ beállításokat az /etc/rc.d/serial szkriptben kell megadnunk. Két iskola jött létre aszerint, hogy &unix; alatt hogyan használják a betárcsázós modemeket. Az egyik csoport úgy szereti beállítani a modemeit és rendszerit, hogy a távoli felhasználó által választott sebességtõl függetlenül a számítógép és a modem közti RS-232 felület egy fix sebességen fut. Ennek a beállításnak megvan az az elõnye, hogy a távoli felhasználó ilyenkor szinte azonnal megkapja a bejelentkezõ képernyõt. A hátránya viszont, hogy ebben az esetben a rendszer nem ismeri a felhasználó valódi adatátviteli sebességét, ezért az olyan teljes képernyõs alkalmazások, mint például az Emacs, nem lesznek képesek a lassabb kapcsolatokhoz szabni a megjelenítésüket. A másik csoport a modemek RS-232-es felületét a távoli felhasználó kapcsolódási sebessége szerint állítja be. Így például egy V.32bis (14,4 Kbps) kapcsolat esetén a modemhez tartozó RS-232 felület 19,2 Kbps-on fog menni, miközben a 2400 bps sebességû kapcsolatokhoz egy vele azonos sebességû RS-232-es felület fog tartozni. Mivel a getty nem képes kommunikálni a modemek által lejelentett csatlakozási sebességen, ezért úgy próbálja azt megállapítani, hogy elküldi a login: szöveget az alap sebességgel, majd figyeli a válaszul érkezõ karaktereket. Ha a felhasználó ilyenkor szemetet lát, akkor feltételezik, hogy addig fogja nyomkodni az Enter billentyût, amíg valami értelmes szöveget meg nem lát. Amikor az adatátviteli sebesség eltér, akkor a getty ebbõl csupán csak annyit vesz észre, hogy a felhasználó szemetet küld, ezért egy újabb sebességgel megpróbálja megint elküldeni a login: szöveget. Hivatalosan ez a folyamat ismétlõdik orrvérzésig, de általában csak egy-két billentyût kell leütni a megfelelõ beállításokhoz. Nyilvánvaló, hogy ilyenkor a bejelentkezés messze nem olyan zavartalan, mint a rögzített sebességû esetben, de így a lassabb kapcsolattal rendelkezõ felhasználók is jobb használatóságot kapnak a teljes képernyõs programokkal. Ebben a szakaszban egy valamennyire kiegyensúlyozott beállítást igyekszünk bemutatni, de részben elfogunk hajlani abban az irányba, amikor a modem a kapcsolat sebességét követi. <filename>/etc/gettytab</filename> /etc/gettytab A /etc/gettytab egy &man.termcap.5;-szerû állomány, amely a &man.getty.8; beállításait tartalmazza. A &man.gettytab.5; man oldalon olvashatunk az állomány pontos felépítésérõl és benne felsorolt beállításokról. A rögzített sebességû beállítás Ha a modem kommunikációs sebességét rögzíteni akarjuk, akkor ehhez többnyire semmit sem kell megváltoztatnunk az /etc/gettytab állományban. Az alkalmazkodó sebességû beállítás Az /etc/gettytab állományban létre kell hoznunk egy olyan bejegyzést, amelyen keresztül a getty tudni fogja, hogy milyen sebességeken akarjuk használni a modemet. Ha egy 2400 bps sebességû modemünk van, akkor hozzá a már meglevõ D2400-as bejegyzést kell használnunk. # # A gyors betárcsázós terminálokhoz íme egy 2400/1200/300-as váltás # (bárhonnan kezdõdhet): # D2400|d2400|Fast-Dial-2400:\ :nx=D1200:tc=2400-baud: 3|D1200|Fast-Dial-1200:\ :nx=D300:tc=1200-baud: 5|D300|Fast-Dial-300:\ :nx=D2400:tc=300-baud: Ha ennél gyorsabb modemünk van, akkor már mindenképpen fel kell vennünk hozzá egy új bejegyzést az /etc/gettytab állományba. Ezzel a beállítással egy 14,4 Kbps sebességû modemet tudunk legfeljebb 19,2 Kbps-en használni: # # Kiegészítések egy V.32bis modemhez: # um|V300|High Speed Modem at 300,8-bit:\ :nx=V19200:tc=std.300: un|V1200|High Speed Modem at 1200,8-bit:\ :nx=V300:tc=std.1200: uo|V2400|High Speed Modem at 2400,8-bit:\ :nx=V1200:tc=std.2400: up|V9600|High Speed Modem at 9600,8-bit:\ :nx=V2400:tc=std.9600: uq|V19200|High Speed Modem at 19200,8-bit:\ :nx=V9600:tc=std.19200: Ennek eredménye egy 8 bites, paritásmentes kapcsolat lesz. A fenti példában a kommunikációt 19,2 Kbps-en (V.32bis kapcsolaton) kezdjük, majd utána haladunk végig a 9600 bps (V.32), 2400 , 1200 bps és 300 bps sebességû kapcsolatokon, majd vissza ismét a 19,2 Kbps-re. Az adatátviteli sebesség ilyen típusú váltogatását az nx= (next table, azaz következõ táblázat) tulajdonság segítségével valósítják meg. Minden sorban látható még egy tc= (table continuation, vagyis a táblázat folytatása) bejegyzés is, amivel az adott adatátviteli sebesség szabványos beállításait adjuk meg. Ha egy 28,8 Kbps sebességû modemünk van és/vagy egy 14,4 Kbps sebességû modemen akarunk tömörítést használni, akkor a 19,2 Kbps-nél nagyobb kommunikációs sebességet kell használnunk. Íme egy olyan gettytab. ami 57,6 Kbps-rõl indít: # # A V.32bis vagy V.34 modemekhez kiegészítés, # 57,6 Kbps-rõl indulunk: # vm|VH300|Very High Speed Modem at 300,8-bit:\ :nx=VH57600:tc=std.300: vn|VH1200|Very High Speed Modem at 1200,8-bit:\ :nx=VH300:tc=std.1200: vo|VH2400|Very High Speed Modem at 2400,8-bit:\ :nx=VH1200:tc=std.2400: vp|VH9600|Very High Speed Modem at 9600,8-bit:\ :nx=VH2400:tc=std.9600: vq|VH57600|Very High Speed Modem at 57600,8-bit:\ :nx=VH9600:tc=std.57600: Ha lassú a processzorunk, vagy a rendszerünk túlságosan terhelt és nincs 16550A típusú soros portunk, akkor 57,6 Kbps-en sio silo hibák keletkezhetnek. <filename>/etc/ttys</filename> /etc/ttys Az /etc/ttys állomány beállításáról már a adott képet. Ez a modemek esetében sem tér el különösebben, habár a getty programnak más termináltípust és -beállításokat kell átadnunk. Akár rögzített, akár alkalmazkodó sebességet akarunk beállítani, ennek általános alakja az alábbi: ttyd0 "/usr/libexec/getty xxx" dialup on A sorban látható elsõ elem a megfelelõ speciális eszköz neve — jelen esetben ez a ttyd0, amely a /dev/ttyd0 eszközre vonatkozik és ezt fogja a getty figyelni. A második elem, vagyis a "/usr/libexec/getty xxx" (ahol a xxx helyére kell beírni a megfelelõ gettytab állománybeli bejegyzést nevét) lesz az a parancs, amelyet az init meghív. A harmadik elem, a dialup a terminálok alapértelmezett típusa. A negyedik paraméter, az on jelzi az init programnak, hogy aktiválja a vonalat. A sorban megjelenhetne továbbá még egy ötödik paraméter is, a secure, de ezt csak olyan terminálok esetében érdemes megadni, amelyek fizikailag megbízhatóak (például a rendszerkonzol). Az alapértelmezett termináltípus (vagyis a fenti példában a dialup) a helyi beállításoktól függ. A betárcsázós vonalak esetében hagyományosan a dialup a terminál alapértelmezett típusa, amit aztán a felhasználók a bejelentkezéskor lefutó szkriptjeiken keresztül a automatikusan át tudnak állítani a nekik megfelelõ terminálra. A szerzõ saját rendszerében azonban inkább a vt102 termináltípust volt érdemes megadni alapértelmezettként, mivel ott a felhasználók csak ilyen típusú terminálokat használnak. Miután az /etc/ttys állományban elvégeztük a szükséges módosításokat, egy HUP jelzéssel figyelmeztessük az init programot az újbóli beolvasására. Ehhez a következõ parancs ajánlott: &prompt.root; kill -HUP 1 Ha még csak állítjuk be elõször a rendszerünket, akkor az init figyelmeztetése elõtt legyünk türelmesek, és várjuk meg, amíg a modemek befejezik az inicializálást és kapcsolódnak a vonalakra. A rögzített sebességû beállítás A rögzített sebesség beállításánál a ttys állományban a getty paramétereként egy szintén rögzített sebességû bejegyzést kell megadnunk. Például az olyan modemeknél, ahol a sebességet 19,2 Kbps-re rögzítjük, a ttys így fog kinézni: ttyd0 "/usr/libexec/getty std.19200" dialup on Amennyiben a modemünk nem ezen a sebességen üzemelne, akkor az std.sebesség paramétert használjuk az std.19200 helyett. Elõtte azonban ne felejtsük el ellenõrizni, hogy a megadott típus szerepel-e az /etc/gettytab állományban. Az alkalmazkodó sebességû beállítás Az alkalmazkodó sebességû beállításnál a ttys állományban az /etc/gettytab állományból a megfelelõ auto-baud (sic) kell megadnunk. Például, ha modemünk kezdõsebessége 19,2 Kbps (és a gettytab ehhez tartalmaz egy V19200 nevû bejegyzést), akkor a ttys így fog kinézni: ttyd0 "/usr/libexec/getty V19200" dialup on <filename>/etc/rc.d/serial</filename> rc állományok rc.serial A gyorsabb, mint például a V.32, V.32bis és V.34 modemeknél meg kell adnunk a hardveres forgalomirányítás (RTS/CTS) használatát is. Az /etc/rc.d/serial állományban tudjuk megadni a &os; rendszermagban a vonal használatához szükséges vezérlési beállításokra vonatkozó stty parancsokat. Például állítsuk be az 1-es sorszámú (vagyis a COM2) soros porton a crtscts termios beállítást a behíváshoz és a híváshoz használt eszközök inicializálásakor. Ehhez a következõ sorokat kell felvennünk az /etc/rc.d/serial állományba: # A soros portok kezdeti beállításai: stty -f /dev/ttyd1.init crtscts stty -f /dev/cuad1.init crtscts A modemek beállításai Ha olyan modemeink vannak, amelyek paramétereit egy statikus memóriában tárolták le, akkor ezek beállításához egy terminálprogramot kell használnunk (amilyen például &ms-dos; alatt a Telix vagy &os; alatt a tip). A modemet a getty programnak megadott kezdeti sebességen csatlakoztassuk és az alábbi elvárások alapján állítsuk be a paramétereit: Kapcsolódáskor CD jelzése. Mûködéskor DTR jelzése. A DTR küldésekor bontsa a vonalat és hozza alapállapotba a modemet. CTS vezérlésû kimenõ adatforgalom. A XON/XOFF forgalomvezérlés tiltása. RTS vezérlésû bejövõ adatforgalom. Csendes mód (ne adjon értesítést az eredményekrõl). A parancsokat ne írja vissza. A modemhez tartozó dokumentációban kell utánajárnunk, hogy milyen parancsok és/vagy DIP kapcsolók átállításával lehet mindezeket elérni. Például, ha a fenti paramétereket egy &usrobotics; &sportster; 14400-as külsõ modem esetében a következõ neki kiküldött paranccsal lehet beállítani: ATZ AT&C1&D2&H1&I0&R2&W Ilyenkor még akár más egyéb paramétereket is beállíthatunk, például a V.42bis és/vagy az MNP5 tömörítést. Az &usrobotics; &sportster; 14400 külsõ modemen ezenkívül még találunk néhány DIP kapcsolót is. Az ilyen modemek esetében például ezeket a beállításokat tudjuk használni: 1. kapcsoló: FEL — normális DTR 2. kapcsoló: N/A (verbális/numerikus eredményjelzõ kódok) 3. kapcsoló: FEL — az eredményjelzõ kódok küldésének tiltása 4. kapcsoló: LE — nem küldi vissza a parancsokat 5. kapcsoló: FEL — automatikus válasz 6. kapcsoló: FEL — normális Carrier Detect 7. kapcsoló: FEL — a memóriában tárolt alapértelmezések betöltése 8. kapcsoló: N/A (intelligens/buta mód) A modemeknél az eredményjelzõ kódok kikapcsolása/letiltása ezért fontos, mert így el tudunk kerülni az olyan problémákat, hogy a getty tévesen egy login: promptot küld a parancs módban levõ modemnek, amikor az visszaküldi a parancsot és az eredmény kódját. Ennek eredménye egy hosszúra nyúló, zavaros társalgás lesz a getty és a modem között. A rögzített sebességû beállítás A rögzített sebességû konfiguráció használata esetén úgy kell beállítanunk a modemet, hogy a konkrét adatátviteli sebsségtõl függetlenül is egy állandó sebességû kapcsolat álljon fenn a számítógép és a modem között. A &usrobotics; &sportster; 14400-as külsõ modem esetében a most következõ parancsokkal tudjuk rögzíteni a kapcsolat sebességét: ATZ AT&B1&W Az alkalmazkodó sebességû beállítás Amikor változó sebességû konfigurációval dolgozunk, akkor a modemet úgy kell beállítani, hogy a bejövõ hívásnak megfelelõ adatátviteli sebességre váltson a soros portján. A &usrobotics; &sportster; 14400-as külsõ modem esetében az alábbi parancsokkal rögzítjük a modemnek küldött hibamentesített parancsok sebességét, miközben engedélyezzük, hogy a soros port sebessége változhasson a nem hibamentesített kapcsolatoknál: ATZ AT&B2&W A modem beállításainak ellenõrzése A legtöbb nagysebességû modem biztosít valamilyen lehetõséget arra, hogy emberi formában is le tudjuk kérdezni a belsõ mûködésének paramétereit. A &usrobotics; &sportster; 14400-as külsõ modem esetében az ATI5 parancs a statikus memóriában tárolt beállításokat mutatja meg. A modem valós mûködési paramétereit (amit ugyebár befolyásolnak a DIP kapcsolók állásai is) viszont az ATZ majd ATI4 parancsok küldésével tudjuk lekérni. Ha azonban másmilyen márkájú modemünk lenne, akkor a modem leírásában próbáljunk tájékozódni arról, miként tudjuk a modem beállításait ellenõrizni. Hibaelhárítás Ebben a szakaszban bemutatunk néhány lépést, amelyeken keresztül ellenõrizhetjük a rendszerünkhöz csatlakoztatott modemet. A &os; rendszer ellenõrzése Csatlakoztassuk a modemet a &os; rendszerre, indítsuk be a gépet, majd ezután figyeljük a modemünk állapotát jelzõ lámpákat, hogy közülük a DTR világít-e, amikor a login: felirat megjelenik a rendszerkonzolon. Amennyiben erre a válasz igen, akkor az arra utal, hogy a &os; a hozzátartozó kommunikációs porton elindította a megfelelõ getty programot és a modem várja a hívásokat. Amikor viszont a DTR lámpa nem világít, a konzolon keresztül jelentkezzünk be a &os; rendszerbe és adjuk ki egy ps ax parancsot, amivel így ellenõrizni tudjuk, hogy a porthoz tartozó getty elindult. A futó programok között tehát valami ilyesmit kell majd látnunk: 114 ?? I 0:00.10 /usr/libexec/getty V19200 ttyd0 115 ?? I 0:00.10 /usr/libexec/getty V19200 ttyd1 Ha viszont például ezt látjuk: 114 d0 I 0:00.10 /usr/libexec/getty V19200 ttyd0 és modem még nem fogadott hívást, akkor ez azt jelenit, hogy a getty megnyitotta a kommunikációs csatornát. Ez utalhat egyaránt egy hibás kábelre vagy a modem helytelen beállítására, mivel a getty egészen addig nem lesz képes megnyitni az adott portot, amíg a modem vissza nem küld neki egy CD (Carrier Detect) jelet. Ha a listában az adott ttydN eszközhöz semmilyen getty programot nem találunk, akkor újra nézzük át az /etc/ttys állományban szereplõ bejegyzéseket, mert elõfordulhat, hogy azokban vétettünk valamilyen hibát. Emellett még a /var/log/messages naplóban is érdemes utánanézni, hátha az init vagy a getty küldött valamilyen hibáról értesítést. Ha még ezek után sem találunk semmit, akkor megint kezdjük el keresni hibákat, hiányzó bejegyzéseket vagy eszközöket az /etc/ttys, /etc/gettytab és a megfelelõ /dev/ttydN állományokban. A betárcsázás kipróbálása Próbáljunk meg bejutni a rendszerünkbe. Ehhez a távoli rendszeren ne felejtsük el beállítani a 8 bites adatátvitelt és az 1 stopbitet, illetve a paritást kikapcsolni. Ha erre közvetlenül nem kapunk egy bejelentkezési képernyõt vagy csak szemét jelenik meg, akkor kb. másodpercenként egyszer nyomjuk le az Enter billentyût. Ha még ezután sem látjuk a bejelentkezési képernyõt felbukkani, akkor próbáljunk kiküldeni egy BREAK parancsot. Ha a híváshoz nagysebességû modemet használunk, akkor próbáljuk meg a modem sebességét rögzíteni és úgy tárcsázni (ezt például a &usrobotics; &sportster; modemnél az AT&B1 paranccsal tudjuk elérni): Ha viszont még ezek után sem kapjuk meg a bejelentkezõ képernyõt, akkor a /etc/gettytab állományban megint nézzük át az összes beállítást: Az /etc/ttys állományban megadott alaptulajdonság neve egyezik az /etc/gettytab állományban találhatóval. Mindegyik nx= bejegyzés után egy másik gettytab tulajdonság neve jön. Mindegyik tc= bejegyzés után egy másik gettytab tulajdonság neve következik. Ha hívunk, de a &os; rendszerünkre kapcsolt modem továbbra sem veszi fel, akkor a modem beállításai között ellenõrizzük, hogy a DTR jel küldésekor a modem fogadja-e a hívást. Ha úgy tûnik, hogy a modem minden ezzel kapcsolatos beállítása stimmel, akkor nézzük meg, hogy a modem lámpái közül a DTR világít-e (már ha van ilyen). Ha mindent többször is végignéztünk és még mindig nem leljük a megoldást, akkor tartsunk egy kis szünetet és térjünk vissza a problémához késõbb. Ha még ezután sem tudjuk mûködésre bírni, akkor küldjünk egy levelet a &a.questions; címére, amelyben leírjuk a modemünket és a vele kapcsolatos problémát, és a lista tagjai majd megpróbálnak nekünk segíteni. A betárcsázós szolgáltatások használata betárcsázós szolgáltatások használata A következõkben arra vonatkozóan igyekszünk tanácsokat adni, amikor mi magunk akarunk modemmel csatlakozni valamilyen számítógéphez. Ezek tehát olyan esetekben hasznosak, amikor egy távoli géppel akarunk terminálkapcsolatot létesíteni. A BBS-ek használatára is érvényes. Ez ilyen típusú kapcsolatok kifejezetten hasznosak tudnak lenni olyan esetekben, amikor az interneten el akarunk érni egy állományt, de gondjaink akadtak a PPP használatával. Ha például egy állományt akarunk letölteni, de a PPP valamiért nem mûködik, akkor ezt a terminál alapú kapcsolaton keresztül is meg tudjuk tenni. Ilyenkor egy zmodem segítségével tudjuk áttölteni a számítógépünkre. A gyári Hayes-modem erre nem alkalmas, mihez tudunk vele kezdeni? A tip man oldala valójában már nem is teljesen aktuális, ugyanis tartalmaz egy beépített Hayes-tárcsázót. Úgy tudjuk engedélyezni, ha az /etc/remote állományban megadjuk az at=hayes beállítást. A Hayes-eszközök meghajtója nem elég ügyes ahhoz, hogy felismerje az újabb modemek által felkínált fejlettebb lehetõségeket — például a BUSY, NO DIALTONE vagy a CONNECT 115200 üzenetek csak megzavarják. Ezért a tip használata során kapcsoljuk ki ezeket az üzeneteket (az ATXO&W paranccsal). Emellett még érdemes tudni, hogy a tip a híváskor 60 másodpercig vár. A modemünkön ennél kisebb idõt kell beállítanunk, máskülönben a tip azt hiszi, hogy valamilyen kommunikációs probléma merült fel. Ehhez próbálkozzunk az ATS7=45&W paranccsal. - - - Az alaprendszerben levõ tip nem - teljesen támogatja a Hayes-modemeket. Ezt úgy - orvosolhatjuk, ha a - /usr/src/usr.bin/tip/tip - könyvtárban található - tipconf.h állományt - némileg módosítjuk. A mûvelet - elvégzéséhez természetesen - szükségünk lesz a rendszer forrásaira - is. - - A #define HAYES 0 sor írjuk - át a #define HAYES 1 sorra. Ezt - követõen adjuk ki a make majd a - make install parancsot. Innentõl - kezdve már minden remekül - mûködik. - - Hogyan adjuk meg ezeket az AT parancsokat? /etc/remote Az /etc/remote állományban hozzunk létre egy direct bejegyzést. Például, ha a modemünk az elsõ soros porton, vagyis a /dev/cuad0 eszközön tanyázik, akkor a következõ sort kell beleírnunk: cuad0:dv=/dev/cuad0:br#19200:pa=none A br tulajdonságnál a modem által ismert legnagyobb adatátviteli sebességet adjuk meg. Ezután gépeljük be a tip cuad0 parancsot és már kapcsolódunk is a modemhez. Vagy root felhasználóként a cu parancsot is használhatjuk: &prompt.root; cu -lvonal -ssebesség Itt a vonal a soros port (például /dev/cuad0) és a sebesség annak sebessége (például 57600) lesz. Miután befejeztük az AT parancsok kiadását, az ~. begépelésével tudunk kilépni. A pn tulajdonságnál a <literal>@</literal> jel nem használható! A pn (phone number) tulajdonság értékében szereplõ @ jel segítségével az /etc/phones állományban tudunk hivatkozni egy telefonszámra. A @ a tulajdonságokat tároló állományok azonban, így például az /etc/remote állomány esetén is megkülönböztetett jelentéssel bírnak. Ezért itt csak egy visszaper jellel tudjuk beírni: pn=\@ Hogyan hívjunk fel egy számot parancssorból? Tegyünk egy általános bejegyzést az /etc/remote állományunkba. Például egy ilyet: tip115200|Dial any phone number at 115200 bps:\ :dv=/dev/cuad0:br#115200:at=hayes:pa=none:du: tip57600|Dial any phone number at 57600 bps:\ :dv=/dev/cuad0:br#57600:at=hayes:pa=none:du: Ezután már ilyet is tudni fogunk: &prompt.root; tip -115200 5551234 Ha viszont a tip helyett inkább a cu programot használnánk szívesen, akkor ehhez készítsünk egy általános bejegyzést: cu115200|Use cu to dial any number at 115200bps:\ :dv=/dev/cuad1:br#57600:at=hayes:pa=none:du: Majd gépeljük be ezt: &prompt.root; cu 5551234 -s 115200 Ehhez minden adandó alkalommal meg kell adnom a sebességet is? Hozzunk létre egy tip1200 vagy cu1200 nevû bejegyzést, de a br tulajdonságnál adjuk meg a használni kívánt sebességet. Mivel a tip szerint az 1200 bps egy megfelelõ alapértelmezés, ezért alapból a tip1200 bejegyzést fogja keresni. Ez természetesen nem jelenti azt, hogy ilyen sebsséggel is akarunk dolgozni. A terminálszerveren keresztül több más gépet is elérek Ahelyett, hogy minden alkalommal megvárnánk a kapcsolódás befejezést és begépelnénk a CONNECT gép parancsot, használjuk a cm tulajdonságát. Például nézzük meg ilyen bejegyzést az /etc/remote állományban: pain|pain.deep13.com|Forrester's machine:\ :cm=CONNECT pain\n:tc=deep13: muffin|muffin.deep13.com|Frank's machine:\ :cm=CONNECT muffin\n:tc=deep13: deep13:Gizmonics Institute terminal server:\ :dv=/dev/cuad2:br#38400:at=hayes:du:pa=none:pn=5551234: Ennek hatására elég csak annyit megadnunk, hogy tip pain vagy tip muffin, és már kapcsolódunk is a pain vagy muffin gépekhez. A tip deep13 paranccsal pedig egyenesen a terminálszerverhez jutunk el. Több vonalon is lehet egy géphez csatlakozni? Ez gyakran okoz gondot olyan esetekben, amikor egy egyetemnek több betárcsázó vonala van, és azokon keresztül többezer hallgató próbál meg dolgozni. Vegyük fel az egyetemet az /etc/remote állományba és használjuk a pn tulajdonság megadásánál a @ jelet: nagy-egyetem:\ :pn=\@:tc=dialout dialout:\ :dv=/dev/cuad3:br#9600:at=courier:du:pa=none: Ezután adjuk hozzá az /etc/phones állományhoz az egyetem telefonszámait: nagy-egyetem 5551111 nagy-egyetem 5551112 nagy-egyetem 5551113 nagy-egyetem 5551114 A tip mindegyik telefonszámot az adott sorrendben próbálja tárcsázni és végén feladja a próbálkozást. Ha folyamatosan akarjuk ezeket a számokat hívni, akkor tip parancsot tegyük egy ciklusba. Miért kell kétszer lenyomni a <keycombo action="simul"> <keycap>Ctrl</keycap> <keycap>P</keycap> </keycombo> gombokat, hogy egyszer elküldje a <keycombo action="simul"> <keycap>Ctrl</keycap> <keycap>P</keycap> </keycombo> kombinációt? A CtrlP billentyûkombináció alapértelmezés szerint a kikényszerítést jelenti, amivel a tip programnak tudunk szólni, hogy a következõ adat szó szerint értendõ. A ~s szekvenciával bármelyik másik karakternek át tudjuk adni ezt a szerepet, ami egy változó beállítását jelenti (set a variable). Gépeljük be, hogy ~sforce=egyetlen-karakter és zárjuk le egy újsorral. Az egyetlen-karakter helyére tetszõleges, egykarakteres szimbólumot megadhatunk. Ha itt nem adunk meg semmit, akkor a kikényszerítõ karakter a nul lesz, amit a Ctrl2 vagy a CtrlSzóköz lenyomásával tudunk elõhozni. Az egyetlen-karakter szerepére például tökéletes a Shift Ctrl 6 , amit csak nagyon kevés terminálszerver alkalmaz. A kikényszerítést végzõ karaktert az $HOME/.tiprc állományban tetszõleges karakterre át tudjuk állítani: force=egyetlen-karakter Miért lett hirtelen minden begépelt betû nagybetûs?? Valószínûleg sikerült lenyomnunk a Ctrl A gombkombinációt, ami a tip betûmód váltás funkciójának felel meg. Ezt olyanok számára dolgozták ki, akiknél nem mûködik a Caps Lock billentyû. Az elõbb bemutatott ~s használatával állítsuk át a raisechar változót valami másra. Tulajdonképpen akár ugyanarra is állíthatjuk, mint a kikényszerítõ karaktert, ha nem áll szándékunkban használni. Ebben a példában egy olyan .tiprc állomány szerepel, amely tökéletesen megfelel azon Emacs felhasználók számára, akik sokat használják a Ctrl2 és CtrlA kombinációkat: force=^^ raisechar=^^ A ^^ a ShiftCtrl6 billentyûkombinációt jelenti. Hogyan mozgassunk állományokat a <command>tip</command> használatával? Amikor más &unix; rendszerekkel vesszük fel a kapcsolatot, akkor állományokat a ~p (mint put, vagyis adni) és ~t (mint take, vagyis venni) használatával tudunk mozgatni. Ezek a parancsok a távoli rendszeren a cat és az echo felhasználásával fogadnak és küldenek állományokat. Alakjuk a következõ: ~p helyi-állomány távoli-állomány ~t távoli-állomány helyi-állomány Ilyenkor nincs hibaellenõrzés, ezért inkább egy másik protokollt, például zmodemet érdemes használnunk. Hogyan lehet zmodemet használni a <command>tip</command> programban? Állományokat úgy tudunk fogadni, ha elõtte a kapcsolat távolabbi végén elindítjuk a küldést végzõ programot. Ezután a ~C rz parancs kiadásával kezdhetjük meg helyben a fogadását. Állományokat úgy tudunk küldeni, ha elõtte a kapcsolat másik végén elindítjuk a fogadó programot. Ezután a ~C sz állományok parancs kiadásával tudjuk megkezdeni a küldést. Kazutaka YOKOTA Készítette: Bill Paul Az alapján szolgáló írást készítette: A soros vonali konzol beállítása soros konzol Bevezetés A &os; képes úgy is elindulni, ha konzolként mindössze egy buta terminált kapcsolunk rá soros porton keresztül. Az ilyen típusú konfigurációs alapvetõen két típus számára bizonyul hasznosnak: azon rendszergazdák számára, akik billentyûzettel és monitorral nem rendelkezõ gépekre akarnak &os;-t telepíteni, és olyan fejlesztõk számára, akik a rendszermag vagy különbözõ eszközmeghajtók mûködését akarják nyomon követni. Ahogy arról már a ben is szó esett, a &os; három indítási fokozattal rendelkezik. Az elsõ két fokozat a rendszerindító blokk kódjában foglal helyet, amely pedig a lemezen található &os; slice elején. A rendszer indulásakor ez a blokk betöltõdik és lefuttatja a harmadik fokozatot képviselõ rendszertöltõt (a /boot/loader állományt). Ha soros vonali konzol beállításához tehát be kell állítanunk a rendszerindító blokkot, a rendszertöltõt és a rendszermagot. A soros konzol beállítása, rövidített változat Ebben a szakaszban azt feltételezzük, hogy az alap beállításokkal dolgozunk és csupán egy gyors áttekintésre van szükségünk a soros vonali konzolról. Csatlakoztassunk egy soros kábelt a COM1 portra és a terminálra. Rendszeradminisztrátorként a következõ parancs kell kiadnunk ahhoz, hogy a soros konzolon láthassuk az összes rendszerindításhoz tartozó üzenetet: &prompt.root; echo 'console="comconsole"' >> /boot/loader.conf Nyissuk meg az /etc/ttys állományt, és a ttyd0 eszközhöz tartozó sorban írjuk át az off paramétert az on értékre és a dialup paramétert a vt100 értékre. Ha nem ezeket állítjuk be, akkor a soros konzol keresztül jelszó megadása nélkül is be tudunk jelentkezni, ami viszont egy biztonsági rés veszélyével fenyeget. A változtatások érvényesítéséhez indítsuk újra a rendszerünket. Ha ettõl eltérõ beállításokra lenne szükségünk, akkor a folyamat egyes lépéseibe a ban kaphatunk mélyebb betekintést. A soros vonali konzol beállítása Készítsük elõ a soros kábelt. null-modem kábel Vagy a null-modem kábelre vagy pedig egy szabványos soros kábelre és egy null-modem átalakítóra lesz szükségünk. A soros kábelekkel kapcsolatosan a t érdemes elolvasni. Húzzuk ki a billentyûzetet. A legtöbb személyi számítógép az indítása (vagyis a Power-On Self-Test, POST) során hibát jelez, ha nem érzékel billentyûzetet. Egyes gépek hangosan panaszolják a billentyûzet hiányát, és nem is hajlandóak egészen addig elindulni, amíg nem csatlakoztatunk egyet. Ha a számítógépünk hibát küld, de ennek ellenére mégis elindul, akkor semmit nem kell csinálnunk. (Némelyik Phonix BIOS-os gépen ilyenkor megjelenik a Keyboard failed hibaüzenet, de ettõl még rendesen elindul a gép.) Amennyiben a számítógépünk nem hajlandó billentyûzet nélkül elindulni, állítsuk be a BIOS-ban a hiba figyelmen kívül hagyását (már ha ez lehetséges). Az alaplap leírásában találhatjuk meg ennek pontos részleit. A BIOS paraméterei között a billentyûzetet állítsuk Not installed állapotúra. Ilyenkor még továbbra is használható a billentyûzet, ezzel mindössze csak a BIOS számára tiltjuk le az indításkori ellenõrzést, ezért nem fog panaszkodni a hiánya miatt. Tehát a billentyûzetet még a Not installed beállítása esetén is nyugodtan csatlakoztatjuk, mert mûködni fog. Ha a rendszerünkön &ps2;-es egér is található, akkor jó eséllyel a billentyûzettel együtt az egeret is ki tudjuk húzni. Mivel a &ps2;-es egér osztozik a billentyûzettel bizonyos hardvereken, ezért ha nem húzzuk ki az egeret is, akkor az alaplap még továbbra is képes azt gondolni, hogy a billentyûzet ott van. Például az AMI BIOS-os Gateway 2000-as 90 MHz-es Pentium rendszer pontosan így mûködik. Általában véve azonban ez nem szokott gondot okozni, mivel az egér billentyûzet nélkül úgy sem ér túlságosan sokat. Csatlakoztassunk egy buta terminált a COM1 (sio0) portra. Ha nem rendelkezünk buta terminállal, akkor erre célra ugyanúgy alkalmas egy régi XT-s PC valamilyen modemprogrammal vagy egy soros porton csatlakozó másik &unix;-os gép. Ha nincs COM1 (sio0) portunk, akkor szerezzünk egyet. Jelen pillanatban a rendszerindító blokk újrafordítása nélkül a COM1 porton kívül nem tudunk másikat választani. Ha a COM1 portra már raktunk valamilyen másik eszközt, akkor azt ideiglenesen húzzuk le, majd a &os; telepítése és elindítása után tegyünk fel egy másik rendszerindító blokkot. (Egyébként feltételezzük, hogy a COM1 elérhetõ egy állomány/számító/terminálszerveren — ha valóban valamilyen másik célra szükségünk lenne a COM1 portra (és semmiképpen sem tudjuk átrakni a COM2 (sio1) portra), akkor valószínûleg nem is ezzel kellene elsõként foglalkoznunk.) Gondoskodjunk róla, hogy a rendszermag beállításait tartalmazó állományban a COM1 (sio0) eszközhöz megadtuk a megfelelõ paramétereket. Ezek az alábbiak: 0x10 A konzolos mûködési mód engedélyezése az adott egységhez. Ha megadjuk ezt a paramétert, akkor a többit a rendszer figyelmen kívül hagyja. Pillanatnyilag legfeljebb egy egység birtokolhatja ezt a beállítást. Ha több ilyet adtunk volna meg, akkor (a felírás sorrendje szerint) az elsõ kap ilyen szerepet. Ez a beállítás önmagában még nem teszi a soros portot konzollá. Ehhez még szükségünk van a következõ beállításra, vagy a megadására is. 0x20 Az egység konzollá nyilvánítása (hacsak nincs egy tõle nagyobb prioritású konzol), függetlenül a lentebb ismertetendõ opciótól. A 0x20 értéket a értékkel együtt kell megadni. 0x40 (A 0x10 értékkel együtt) az egységet kivonja a normális elérés alól. Ezt a beállítást ne használjuk, ha soros vonali konzolt akarunk üzemeltetni az adott porton. Ezzel az egységet csak a rendszermag távoli nyomkövetéséhez tudjuk használni. A távoli nyomkövetésrõl a fejlesztõk kézikönyvében olvastunk bõvebben. Példa: device sio0 at isa? port IO_COM1 flags 0x10 irq 4 A további részletekrõl a &man.sio.4; man oldal tud felvilágosítást nyújtani. Ha nem állítottuk be a megfelelõ paramétereket, akkor (egy másik konzolon) futtassuk a UserConfig programot vagy fordítsuk újra a rendszermagot. Hozzunk létre egy boot.config állományt a rendszer indításához használt meghajtó a partíciójának gyökerében. Ez az állomány mondja meg a rendszerindító blokkban található kódnak, hogy miként akarjuk indítani a rendszerünket. A soros vonali konzol életrekeltéséhez a most következõ opciók közül kell megadnunk egyet vagy többet — amennyiben többet akarunk megadni, akkor mindegyiket egyetlen sorban szerepeltessük: A belsõ és a soros vonali konzolok közti átkapcsolás. Ezzel tudunk a konzolos eszközök között váltani. Például, ha egy belsõ (video) konzolról indítjuk a rendszert, akkor a rendszertöltõnek és a rendszermagnak átadott paraméterrel arra tudjuk ezeket utasítani, hogy konzolként a soros portot használják. Vagy ha soros porton keresztül indítjuk a rendszert, akkor megadásával megkérhetjük a rendszertöltõt és a rendszermagot, hogy ezután már a videokártyát használja konzolként. Az egy- és kétkonzolos beállítások közti váltás. Az egykonzolos konfigurációban a konzol lehet belsõ (video) vagy soros vonali, attól függõen, hogy miként használtuk a fenti opciót. A kétkonzolos konfigurációban azonban a videokártyán és a soros vonalon keresztül is egyszerre megjelenik a konzol, függetlenül a hatásától. Ilyenkor viszont vegyük figyelembe, hogy ez a kétkonzolos konfiguráció csak a rendszerindító blokk futása alatt él. Amint a rendszerindító megkapja a vezérlést, a által megadott konzol válik az egyedülivé. A rendszerindító blokk megpróbálja megkeresni a billentyûzetet. Ha nem találja, akkor magától beállítja a és opciókat. Tárbeli korlátozások miatt a rendszerindító blokk jelenlegi változata a paraméterrel csak a kiterjesztett billentyûzeteket képes kezelni. A 101 gombnál kevesebbel (tehát F11 és F12 gombokkal nem) rendelkezõ billentyûzeteket ezért nem feltétlenül fogja észlelni. Ugyanezen korlátozás miatt egyes laptopokon sem minden esetben sikerül érzékelni a billentyûzetet. Ha ez a rendszerünkön problémához vezetne, akkor egyszerûbb lesz elhagyni a használatát. Sajnos, jelenleg semmilyen megoldás nincs erre. Vagy a opcióval állítassuk be automatikusan a konzolt, vagy pedig a opcióval engedélyezzük a soros vonali konzolt. Természetesen itt a &man.boot.8; man oldalon szereplõ összes többi paramétert is megadhatjuk. A kivételével az összes opció a rendszertöltõnek (/boot/loader) kerül átadásra. A rendszertöltõ egyedül a állapotából dönti el, hogy mely belsõ videoeszközön vagy soros porton legyen a konzol. Ez azt jelenti, hogy a /boot.config állományban ha megadjuk a opciót, de mellette nem szerepel a , akkor a soros vonali konzolt csak a rendszerindító blokk futása alatt tudjuk elérni — a rendszertöltõ ugyanis alapból a videokártyát használja konzolként. Kapcsoljuk be a számítógépünket. Amikor elindítjuk a &os;-s gépünket, a rendszerindító blokk kiírja a /boot.config tartalmát a konzolra. Például így: /boot.config: -P Keyboard: no A második sor csak olyankor jelenik meg, ha a /boot.config állományban a beállítás is szerepel, és a billentyûzet jelenlétét (yes) vagy hiányát (no) jelzi. A /boot.config tartalmától függõen ezek az üzenetek vagy a soros vonali vagy a belsõ konzolon jelennek meg, esetleg mind a kettõn. Beállítás Ahol megjelenik nincs belsõ konzol soros vonali konzol soros vonali és belsõ konzol soros vonali és belsõ konzol , van billentyûzet belsõ konzol , nincs billentyûzet soros vonali konzol Az iménti üzenetek felbukkanása után a további konzolos üzenetek küldésében egy rövid szünet következik, amíg a rendszerindító blokk a rendszertöltõ betöltésével folytatja a rendszer indítását. Normális körülmények között ezt a folyamatot nem kell megszakítanunk, de esetleg olyankor mégis érdemes lehet, ha le akarjuk ellenõrizni a beállításainkat. A rendszerindítási folyamat félbeszakításához az Enter billentyûn kívül nyomjuk le valamelyik másikat. Ekkor a rendszerindító blokk megáll és várja a további parancsokat. Ekkor valami ilyesmit láthatunk: >> FreeBSD/i386 BOOT Default: 0:ad(0,a)/boot/loader boot: Nézzük meg, hogy /boot.config beállításainak megfelelõen a fenti üzenet a soros vonali konzolon vagy a belsõ konzolon, illetve mind a kettõn megjelenik-e. Ha az üzenet a megfelelõ konzolon megjelenik, akkor az Enter lenyomásával folytathatjuk a rendszer indítását. Ha nekünk a soros vonali konzolra lenne szükségünk, de semmi nem jelenik meg a soros terminálon, akkor valamit valószínûleg nem jól állítottunk be. A rendszerindító blokktól kapott parancssorban a begépelésével és az Enter vagy Return lenyomásával (ha lehetséges) jelezzük neki (és így a rendszertöltõnek és a rendszermagnak is) a soros vonali konzol kiválasztását. Miután befejezõdött a rendszer indítása, menjünk vissza és ellenõrizzük a megfelelõ paramétereket. Ahogy sikerült elindítani a rendszertöltõt és a rendszerindítás harmadik fokozatába léptünk, a rendszertöltõ megfelelõ környezeti változóin keresztül még mindig van lehetõségünk váltani a soros vonali és a belsõ konzol között, lásd . Összefoglalás Itt most röviden összefoglaljuk az eddig tárgyalt különbözõ beállításokat és ténylegesen kiválasztott konzolt. 1. eset: a <devicename>sio0</devicename> eszköznél a 0x10 beállítást adjuk meg device sio0 at isa? port IO_COM1 flags 0x10 irq 4 A /boot.config beállításai Konzol a rendszerindító blokk alatt Konzol a rendszertöltõ alatt Konzol a rendszermagban nincsenek belsõ belsõ belsõ soros vonali soros vonali soros vonali soros vonali és belsõ belsõ belsõ soros vonali és belsõ soros vonali soros vonali , van billentyûzet belsõ belsõ belsõ , nincs billentyûzet soros vonali és belsõ soros vonali soros vonali 2. eset: a <devicename>sio0</devicename> eszköznél 0x30 beállítása device sio0 at isa? port IO_COM1 flags 0x30 irq 4 A /boot.config beállításai Konzol a rendszerindító blokk alatt Konzol a rendszertöltõ alatt Konzol a rendszermagban nincsenek belsõ belsõ soros vonali soros vonali soros vonali soros vonali soros vonali és belsõ belsõ soros vonali soros vonali és belsõ soros vonali soros vonali , van billentyûzet belsõ belsõ soros vonali , nincs billentyûzet soros vonali és belsõ soros vonali soros vonali Tanácsok a soros vonali konzol használatához Nagyobb soros vonali sebesség beállítása A soros port alapértelmezései a következõk: 9600 baud, 8 bites átvitel, paritás nincs és 1 stopbit. Ha a konzol alapsebességét meg akarjuk változtatni, akkor ahhoz a következõket kell tennünk: Fordítsuk újra a rendszerindító blokkokat úgy, hogy a BOOT_COMCONSOLE_SPEED változóban a konzolnak egy másik sebességet adunk meg. Az új rendszerindító blokkok fordításáról és telepítésérõl a ban kapunk részletes leírást. Ha a soros vonali konzolt nem a opcióval állítottuk be, vagy ha a rendszermag a rendszerindító blokkoktól eltérõ módon éri el a soros vonali konzolt, akkor a rendszermag beállításai közé még az alábbit is fel kell vennünk, majd újra kell fordítanunk: options CONSPEED=19200 A rendszermagnak adjuk át a rendszerindítási paramétert. A parancssori opció a /boot.config állományban is megadható. A &man.boot.8; man oldalon tudhatjuk meg, hogy a /boot.config beállításai közé hogyan tudjuk felvenni és ott milyen további lehetõségeink vannak még. A /boot/loader.conf állományban engedélyezzük a comconsole_speed beállítást. Ez a beállítás a szintén a /boot/loader.conf állományban megadható console, boot_serial és boot_multicons változóktól függ. A soros vonali konzol sebességét tehát például így tudjuk megváltoztatni a comconsole_speed megadásával: boot_multicons="YES" boot_serial="YES" comconsole_speed="115200" console="comconsole,vidconsole" Soros vonali konzol a <devicename>sio0</devicename> porton kívül máshol Ha valamilyen okból kifolyólag nem a sio0 porton keresztül akarjuk használni a konzolt, akkor ahhoz a rendszerindító blokkok, a rendszertöltõ és a rendszermag forrásait újra kell fordítanunk az alábbiak szerint: Szerezzük be a rendszermag forrását. (Lásd ) Írjuk át a /etc/make.conf állományban a BOOT_COMCONSOLE_PORT címét az általunk használt porthoz tartozóéra (0x3F8, 0x2F8, 0x3E8 vagy 0x2E8). Itt csak a sio0 és sio3 (COM1 és COM4) közti portok használhatóak — a töbportos soros kártyák címei nem adhatóak meg. A megszakításokat nem kell beállítanunk. Készítsünk egy saját rendszermag beállításait tartalmazó állományt, és vegyük fel bele a használni kívánt soros port megfelelõ paramétereit. Például, ha a sio1 (COM2) eszközt akarjuk konzolként használni: device sio1 at isa? port IO_COM2 flags 0x10 irq 3 vagy device sio1 at isa? port IO_COM2 flags 0x30 irq 3 A konzolra vonatkozó beállításokat a többi soros portnál ne adjuk meg. Fordítsuk újra és telepítsük a rendszerindító blokkot és a rendszertöltõt: &prompt.root; cd /sys/boot &prompt.root; make clean &prompt.root; make &prompt.root; make install Fordítsuk és telepítsük újra a rendszermagot. A &man.bsdlabel.8; segítségével másoljuk az új rendszerindító blokkot a rendszer indítását végzõ lemezre és töltsük be az új rendszermagot. A DDB elérése a soros vonalról Ha a soros vonali konzolról akarjuk használni a rendszermagba épített nyomkövetõt (ami hasznos lehet távoli vizsgálódáskor, de egyben veszélyes is, ha a soros porton tévesen kiküldünk egy BREAK jelzést!), akkor a rendszermagot a következõ beállításokkal kell fordítanunk: options BREAK_TO_DEBUGGER options DDB A bejelentkezõ képernyõ elérése a soros vonali konzolról Habár erre nincs feltétlenül szükségünk, a rendszer üzeneteinek és a rendszermag nyomkövetõjének elérése után akár be is tudunk jelentkezni a soros vonalon keresztül. Íme! Nyissuk meg az /etc/ttys állományt a kedvenc szövegszerkesztõnkkel és keressük meg a következõ sorokat: ttyd0 "/usr/libexec/getty std.9600" unknown off secure ttyd1 "/usr/libexec/getty std.9600" unknown off secure ttyd2 "/usr/libexec/getty std.9600" unknown off secure ttyd3 "/usr/libexec/getty std.9600" unknown off secure A ttyd0 és ttyd3 közti sorok pontosan a COM1 és COM4 közti portoknak felelnek meg. A használni kívánt port sorában szereplõ off paramétert írjuk át az on értékre. Ha a soros port sebességét is megváltoztattuk, minden bizonnyal a std.9600 helyett is az adott sebességhez illeszkedõ paramétert kell megadnunk, például az std.19200 értékkel. Érdemes továbbá még az unknown helyett megadni az adott terminál típusát. Az állomány módosítását követõen a változatások érvényesítéséhez ki kell adnunk a kill -HUP 1 parancsot is. A konzol megváltoztatása a rendszertöltõbõl A korábbi szakaszokban arról beszéltünk, hogy miként állítsuk be a soros vonali konzolt a rendszerindító blokk megpiszkálásával. Ebben a szakaszban viszont azt mutatjuk meg, hogy különbözõ parancsokon és környezeti változókon keresztül miként tudjuk megadni a konzolt a rendszertöltõben. Mivel a rendszertöltõre a rendszerindítás harmadik fokozatában kerül sor, az ott megadott értékekkel felül tudjuk bírálni a rendszerindító blokk beállításait. A soros vonali konzol beállítása A rendszertöltõ és a rendszermag az /boot/loader.conf állományon keresztül elég könnyen rávehetõ a soros vonali konzol használatára: set console="comconsole" Ez a rendszerindító blokk elõzõ szakaszban tárgyalt beállításaitól függetlenül érvényesül. A fenti sort a /boot/loader.conf állomány elejére érdemes tennünk, így a soros vonali konzolon már a lehetõ leghamarabb megjelennek a rendszer üzenetei. Ehhez hasonló módon a belsõ konzolt is megadhatjuk: set console="vidconsole" Ha a rendszertöltõben nem adjuk meg a console környezeti változó értékét, akkor a rendszertöltõ, és így a rendszermag is, a rendszerindító blokkban a opció által meghatározott konzolt fogja használni. A konzol a /boot/loader.conf.local vagy a /boot/loader.conf állományokban adható meg. A részletekkel kapcsolatban lásd a &man.loader.conf.5; man oldalt. Jelen pillanatban a rendszertöltõnek nincs a paraméterrel ekvivalens értékû beállítása, ezért a billentyûzet jelenléte alapján nem képes magától választani a belsõ és a soros vonali konzol között. Soros vonali konzol a <devicename>sio0</devicename> porton kívül máshol A rendszertöltõt ne a sio0 eszközzel fordítsuk újra a soros vonali konzolhoz. Ehhez kövessük a ban leírt eljárás lépéseit. Figyelmeztetések A szakaszban szereplõ ötletek alapján sokan így most már könnyen be tudnak állítani egy billentyûzet és grafikus hardver nélküli dedikált szervert. Sajnos azonban a legtöbb rendszer nem engedi a billentyûzet nélküli indítást, és akad néhány olyan is, amely pedig a grafikus kártya hiányában nem is indul el. Az AMI BIOS-os gépeknél a grafikus kártya nélküli indításhoz elegendõ csupán a beállítások között a grafikus kártyát (graphics adapter) Not installed (nem telepített) állapotúra állítani. Ennek ellenére elõfordulhat azonban, hogy egyes gépeken egyáltalán nem találunk ilyen lehetõséget és videokártya nélkül nem indulnak el. Ezekben az esetekben tegyünk a gépbe valamilyen kártyát (ehhez elég egy egyszerû típus is), de monitort már ne kössünk rá. Esetleg megpróbálkozhatunk még AMI BIOS telepítésével is. diff --git a/hu_HU.ISO8859-2/share/sgml/mailing-lists.ent b/hu_HU.ISO8859-2/share/sgml/mailing-lists.ent index 691bd8be5b..13c996910d 100644 --- a/hu_HU.ISO8859-2/share/sgml/mailing-lists.ent +++ b/hu_HU.ISO8859-2/share/sgml/mailing-lists.ent @@ -1,453 +1,457 @@ FreeBSD lista szerver"> &a.mailman.listinfo;"> FreeBSD ACPI levelezési lista"> freebsd-acpi"> FreeBSD advocacy levelezési lista"> freebsd-advocacy"> FreeBSD AFS levelezési lista"> freebsd-afs"> FreeBSD Adaptec AIC7xxx levelezési lista"> freebsd-aic7xxx"> FreeBSD Alpha levelezési lista"> freebsd-alpha"> FreeBSD AMD64 levelezési lista"> freebsd-amd64"> FreeBSD announcements levelezési lista"> freebsd-announce"> FreeBSD Apache levelezési lista"> freebsd-apache"> FreeBSD architecture and design levelezési lista"> freebsd-arch"> FreeBSD ARM levelezési lista"> freebsd-arm"> FreeBSD ATM networking levelezési lista"> freebsd-atm"> FreeBSD source code audit levelezési lista"> freebsd-audit"> FreeBSD binary update levelezési lista"> freebsd-binup"> FreeBSD Bluetooth levelezési lista"> freebsd-bluetooth"> FreeBSD bugbusters levelezési lista"> freebsd-bugbusters"> FreeBSD problem reports levelezési lista"> freebsd-bugs"> FreeBSD chat levelezési lista"> freebsd-chat"> FreeBSD clustering levelezési lista"> freebsd-cluster"> &os.current; levelezési lista"> freebsd-current"> CTM announcements levelezési lista"> ctm-announce"> CTM distribution of CVS files levelezési lista"> ctm-cvs-cur"> CTM 4-STABLE src branch distribution levelezési lista"> ctm-src-4"> CTM -CURRENT src branch distribution levelezési lista"> ctm-src-cur"> CTM user discussion levelezési lista"> ctm-users"> FreeBSD CVS commit message levelezési lista"> cvs-all"> FreeBSD CVS doc commit lista"> cvs-doc"> FreeBSD CVS ports commit lista"> cvs-ports"> FreeBSD CVS projects commit lista"> cvs-projects"> FreeBSD CVS src commit lista"> cvs-src"> FreeBSD CVSweb maintenance levelezési lista"> freebsd-cvsweb"> FreeBSD based Databases levelezési lista"> freebsd-database"> FreeBSD documentation project levelezési lista"> freebsd-doc"> FreeBSD device drivers levelezési lista"> freebsd-drivers"> FreeBSD users of Eclipse IDE levelezési lista"> freebsd-eclipse"> FreeBSD-embedded levelezési lista"> freebsd-embedded"> FreeBSD-emulation levelezési lista"> freebsd-emulation"> FreeBSD-eol levelezési lista"> freebsd-eol"> FreeBSD FireWire (IEEE 1394) levelezési lista"> freebsd-firewire"> FreeBSD file system project levelezési lista"> freebsd-fs"> FreeBSD GEOM levelezési lista"> freebsd-geom"> FreeBSD GNOME and GNOME applications levelezési lista"> freebsd-gnome"> FreeBSD technical discussions levelezési lista"> freebsd-hackers"> FreeBSD hardware and equipment levelezési lista"> freebsd-hardware"> FreeBSD mirror sites levelezési lista"> freebsd-hubs"> FreeBSD internationalization levelezési lista"> freebsd-i18n"> FreeBSD i386 levelezési lista"> freebsd-i386"> FreeBSD IA32 levelezési lista"> freebsd-ia32"> FreeBSD IA64 levelezési lista"> freebsd-ia64"> FreeBSD IPFW levelezési lista"> freebsd-ipfw"> FreeBSD ISDN levelezési lista"> freebsd-isdn"> FreeBSD Internet service provider's levelezési lista"> freebsd-isp"> FreeBSD jails levelezési lista"> freebsd-jail"> FreeBSD Java Language levelezési lista"> freebsd-java"> FreeBSD related employment levelezési lista"> freebsd-jobs"> FreeBSD KDE/Qt and KDE applications levelezési lista"> freebsd-kde"> FreeBSD LFS porting levelezési lista"> freebsd-lfs"> FreeBSD libh installation and packaging system levelezési lista"> freebsd-libh"> FreeBSD MIPS levelezési lista"> freebsd-mips"> FreeBSD mirror site adminisztrátorok"> mirror-announce"> FreeBSD laptop computer levelezési lista"> freebsd-mobile"> FreeBSD port of the Mozilla browser levelezési lista"> freebsd-mozilla"> FreeBSD multimedia levelezési lista"> freebsd-multimedia"> FreeBSD networking levelezési lista"> freebsd-net"> FreeBSD new users levelezési lista"> freebsd-newbies"> FreeBSD new-bus levelezési lista"> freebsd-new-bus"> FreeBSD OpenOffice levelezési lista"> freebsd-openoffice"> FreeBSD performance levelezési lista"> freebsd-performance"> FreeBSD Perl levelezési lista"> freebsd-perl"> FreeBSD packet filter levelezési lista"> freebsd-pf"> FreeBSD non-Intel platforms levelezési lista"> freebsd-platforms"> FreeBSD core team policy decisions levelezési lista"> freebsd-policy"> FreeBSD ports levelezési lista"> freebsd-ports"> FreeBSD ports bugs levelezési lista"> freebsd-ports-bugs"> FreeBSD PowerPC levelezési lista"> freebsd-ppc"> FreeBSD on HP ProLiant server levelezési lista"> freebsd-proliant"> FreeBSD Python levelezési lista"> freebsd-python"> FreeBSD Quality Assurance levelezési lista"> freebsd-qa"> FreeBSD general questions levelezési lista"> freebsd-questions"> FreeBSD boot script system levelezési lista"> freebsd-rc"> FreeBSD realtime extensions levelezési lista"> freebsd-realtime"> FreeBSD Ruby levelezési lista"> freebsd-ruby"> FreeBSD SCSI subsystem levelezési lista"> freebsd-scsi"> FreeBSD security levelezési lista"> freebsd-security"> FreeBSD security notifications levelezési lista"> freebsd-security-notifications"> FreeBSD-small levelezési lista"> freebsd-small"> FreeBSD symmetric multiprocessing levelezési lista"> freebsd-smp"> FreeBSD SPARC levelezési lista"> freebsd-sparc64"> &os.stable; levelezési lista"> freebsd-stable"> FreeBSD C99 and POSIX compliance levelezési lista"> freebsd-standards"> FreeBSD sun4v levelezési lista"> freebsd-sun4v"> FreeBSD test levelezési lista"> freebsd-test"> FreeBSD performance and stability testing levelezési lista"> freebsd-testing"> FreeBSD threads levelezési lista"> freebsd-threads"> FreeBSD tokenring levelezési lista"> freebsd-tokenring"> FreeBSD USB levelezési lista"> freebsd-usb"> FreeBSD user group coordination levelezési lista"> freebsd-user-groups"> FreeBSD vendors pre-release coordination levelezési lista"> freebsd-vendors"> Discussion of various virtualization techniques supported by FreeBSD levelezési lista"> freebsd-virtualization"> FreeBSD VuXML levelezési lista"> freebsd-vuxml"> + +FreeBSD Work-In-Progress Status levelezési lista"> +freebsd-wip-status"> + FreeBSD Webmaster levelezési lista"> freebsd-www"> FreeBSD X11 levelezési lista"> freebsd-x11"> bug-followup@FreeBSD.org"> majordomo@FreeBSD.org">