diff --git a/hu_HU.ISO8859-2/books/faq/book.sgml b/hu_HU.ISO8859-2/books/faq/book.sgml index 068d2f9f7e..1bffd62aa6 100644 --- a/hu_HU.ISO8859-2/books/faq/book.sgml +++ b/hu_HU.ISO8859-2/books/faq/book.sgml @@ -1,15395 +1,15410 @@ %books.ent; ]> Gyakran Ismételt Kérdések a &os; - 6.<replaceable>X</replaceable> és - 7.<replaceable>X</replaceable> változatairól + 6.X, 7.X + és 8.X + változatairól A &os; Dokumentációs Projekt $FreeBSD$ 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 + 2010 A &os; Dokumentációs Projekt &bookinfo.legalnotice; &tm-attrib.freebsd; &tm-attrib.3com; &tm-attrib.adobe; &tm-attrib.creative; &tm-attrib.cvsup; &tm-attrib.ibm; &tm-attrib.ieee; &tm-attrib.intel; &tm-attrib.iomega; &tm-attrib.linux; &tm-attrib.microsoft; &tm-attrib.mips; &tm-attrib.netscape; &tm-attrib.opengroup; &tm-attrib.oracle; &tm-attrib.sgi; &tm-attrib.sparc; &tm-attrib.sun; &tm-attrib.usrobotics; &tm-attrib.xfree86; &tm-attrib.general; Ezek a gyakran ismételt kérdések a &os; - 6.X és - 7.X változataira vonatkoznak. - Az összes bejegyzés a &os; + 6.X, 7.X + és 8.X változataira + vonatkoznak. Az összes bejegyzés a &os; 6.X vagy annál újabb változataira vonatkozik, hacsak azt külön nem jelezzük. Ha szeretnénk segíteni a projektnek, akkor küldjünk egy levelet a &a.doc; címére! Ennek a dokumentumnak a legfrissebb változata mindig elérhetõ a &os; World Wide Web szerverérõl. HTTP-n keresztül letölthetõ egyetlen nagy HTML állományként, vagy a &os; FTP szerverérõl szöveges, &postscript; PDF stb. formátumban. Továbbá keresni is tudunk a GYIK-ban. Fordította és a fordítást karbantartja: &a.hu.pgj; Bevezetés Üdvözöljük a &os; - 6.X-7.X + 6.X-8.X Gyakran Ismételt Kérdéseiben! Hasonlóan a Usenetes GYIK-okhoz, ennek a dokumentumnak is az a célja, hogy a &os; operációs rendszerrel kapcsolatban feltegye a legyakrabban ismételt kérdéseket (és persze megválaszolja ezeket!). Habár eredetileg azért íródott, hogy megspórolja a feleslegesen elvesztegetett sávszélességet és hogy megelõzze a régóta ismert kérdések újbóli feltételét, a GYIK idõközben egy értékes információforrássá is vált. Igyekeztünk minden megtenni annak érdekében, hogy a GYIK a lehetõ legtöbb információt szolgáltassa. Ha szeretnénk javaslatokat tenni a továbbfejlesztésére, írjunk bátran a &a.doc; címére! Mi az a &os;? Ha tömören akarjuk összefoglalni, akkor a &os; egy AMD64, &intel; EM64T, &i386;, PC-98, IA-64, &arm;, &powerpc; és &ultrasparc; platformokra fejlesztett &unix;-szerû operációs rendszer, amely a Kaliforniai Egyetem (Berkeley) rendszerének 4.4BSD-Lite kiadására épül, valamint a 4.4BSD-Lite2 kiadásból tartalmaz még néhány továbbfejlesztést. Továbbá közvetett módon még felhasználja a Berkeley Net/2 kiadásának &i386; architektúrára készített portját, a 386BSD forrásait is, amit annak idején William Jolitz készített, noha ebbõl ténylegesen már csak nagyon kevés található a rendszerben. A &os; részletesebb bemutatása és annak tulajdonságai a &os; honlapján találhatóak. A &os;-t munkához, oktatáshoz és szórakozáshoz rengeteg cég, internetszolgáltató, kutató, informatikus, diák és otthoni felhasználó használja a világ minden táján. A &os; bõvebb bemutatásához olvassuk el a &os; kézikönyvet. Mi a &os; Projekt célja? A &os; Projektnek az a célja, hogy olyan szoftvereket állítson elõ, amelyek tetszõlegesen felhasználhatóak, mindenféle kötöttségek nélkül. A fejlesztõk közül sokan nagyon sok idõt és munkát fektetnek a forráskódba (és így a Projektbe), ami nyilván megérdemelne némi anyagi ellensúlyozást olykor, de egyáltalán nem ragaszkodunk hozzá. Úgy érezzük, mindenek elõtt az a küldetésünk, hogy feltétel nélkül segítsünk mindenkit a munkánkkal, függetlenül annak szándékaitól, így a munkánk a lehetõ legnagyobb körben kerül felhasználására és így nyújtja a lehetõ legtöbb hasznot. Véleményünk szerint ez az egyik legalapvetõbb célja a szabad szoftvereknek és ezt a hozzáállást támogatjuk a leginkább. A forrásaink között található, GNU General Public License (GPL) vagy a GNU Library General Public License (LGPL) licencelésû munkák azonban már valamivel több kötöttséggel járnak, habár ezek inkább a közzétételükre vonatkoznak, nem pedig annak ellenkezõjére, ahogy azt általában megszokhattuk. A GPL licencû szoftverek kereskedelmi célú felhasználásának további esetleges nehézségei miatt azonban lehetõségeink szerint igyekszünk ezeket olyan szoftverekkel felváltani, amelyek a kevésbé szigorúbb &os; licencet alkalmazzák. A &os; licenc tartalmaz valamilyen megszorítást? Igen. Ezek a megszorítások azonban nem az adott munka felhasználását szabályozzák, hanem csupán azt, hogy miként viszonyuljunk a &os; Projekthez. Ha komoly kétségeink lennének a licenceléssel kapcsolatban, olvassuk a jelenleg érvényes licencet (angolul). Az egyszerû kíváncsiskodók kedvéért nagyjából így tudnánk összefoglalni a licencet: Ne állítsuk, hogy mi készítettük. Ne pereljük a Projektet, ha nem mûködik. A &os; képes kiváltani a jelenleg használt operációs rendszerünket? A legtöbb ember számára igen. A kérdés megválaszolása azonban természetesen nem ennyire egyértelmû. Sokan nem is magát az operációs rendszert, hanem inkább az alkalmazásokat használják. Valójában pedig maguk az alkalmazások azok, amelyek az operációs rendszert használják. A &os;-t úgy alakították ki, hogy az alkalmazások számára egy szilárd és mindentudó környezetet nyújtson. Támogatja a böngészõk, irodai programcsomagok, levelezõ programok, grafikus programok, programozási környezetek, hálózati szerverek széles választékát, és szinte minden mást, amire csak szükségünk lehet. Az ilyen alkalmazások legnagyobb része elérhetõ a Portgyûjteményen keresztül. Ha viszont olyan alkalmazást kívánunk használni, amely csak bizonyos operációs rendszereken érhetõ el, nem tudjuk magát az operációs rendszert egyszerûen lecserélni alatta. Bizonyos esetekben azonban elõfordulhat, hogy &os; alatt is találunk hozzá hasonló alkalmazásokat. Amikor egy stabil irodai vagy internet szerverre van szükségünk, esetleg egy megbízható munkaállomásra, vagy egyszerûen csak megszakítások nélkül szeretnénk végezni a munkánkat, a &os;-ben igényeinkhez mérten szinte minden megtalálhatunk. A világon rengeteg felhasználó, beleértve a kezdõket és a tapasztalt &unix; rendszergazdákat egyaránt, asztali operációs rendszerként is a &os;-t használja. Ha egy másik &unix; környezetrõl akarunk &os;-re váltani, akkor a legtöbb dolog már ismerõs lehet számunkra. Amennyiben viszont valamilyen grafikus operációs rendszerrõl, például &windows;-ról vagy a &macos; valamelyik régebbi változatáról szándékozunk átállni, minden bizonnyal idõt kell majd szánnunk a feladatok &unix; stílusú megvalósításának megismerésére. Ez a GYIK és a &os; kézikönyv ehhez tökéletes kiindulási alapot biztosít. Miért hívják &os;-nek? Szabadon (mint free) felhasználható, akár kereskedelmi célokra is. Az operációs rendszer teljes forráskódja bárki által szabadon elérhetõ, minimális megkötésekkel arra vonatkozóan, hogy miként használható és más (kereskedelmi vagy nem kereskedelmi) munkák részeként miként építhetõ be, terjeszthetõ. Bárki, akinek fejlesztési vagy hibajavítási javaslata van a rendszerrel kapcsolatban, szabadon benyújthatja azt, amely aztán bekerül a források közé (egy-két nyilvánvaló ellenõrzést követõen). Érdemes valamint rámutatni, hogy a szabad szót az imént két értelemben is használtuk: az egyik jelentése szerint költségek nélkül, míg a másik jelentése szerint tetszés szerint. Egy-két tiltott dologtól, például azt állítjuk, hogy mi írtuk, eltekintve tényleg bármit csinálhatunk vele. Mi a különbség a &os;, a NetBSD, OpenBSD és a többi nyílt forráskódú BSD operációs rendszerek között? James Howard The BSD Family Tree címmel (angolul) készített egy alapos leírást a különbözõ projektek közti eltérések bemutatására. Melyik a &os; legújabb változata? Jelen pillanatban a &os; fejlesztése két párhuzamos ágon folyik, és mind a kettõbõl készülnek kiadások. A - 6.X sorozat kiadásai a - 6-STABLE ágból, - míg a 7.X sorozat - kiadásai a 7-STABLE + 7.X sorozat kiadásai a + 7-STABLE ágból, + míg a 8.X sorozat + kiadásai a 8-STABLE ágból készülnek. - Az 7.0-s kiadás megjelenéséig a - 6.X sorozat volt a - -STABLE. Az 7.0 kiadás + A 8.0-s kiadás megjelenéséig a + 7.X sorozat volt a + -STABLE. A 8.0 kiadás megjelenésével azonban a - 6.X ág + 7.X ág meghosszabbított támogatást kapott, és már csak a nagyobb hibákat, például a biztonsági hibákat javítják benne. Az - 6-STABLE ágból még + 7-STABLE ágból még várhatóak további kiadások is, azonban ezt jelenleg már örökségi ágnak tekintjük, és a legtöbb munka már a - 7-STABLE részeként + 8-STABLE részeként jelenik meg. A &rel.current; - változat a 7-STABLE ág + változat a 8-STABLE ág legfrissebb kiadása, amely &rel.current.date;ban - jelent meg. Az 6-STABLE + jelent meg. Az 7-STABLE ágból a &rel2.current; a legfrissebb kiadás, amely &rel2.current.date;ban jelent meg. Ha röviden össze akarjuk foglalni, akkor a -STABLE változatokat elsõsorban az internet-szolgáltatók, vállalkozások számára ajánljuk, illetve minden olyan felhasználó számára, aki a legújabb (és minden bizonnyal még instabil) -CURRENT pillanatkiadásokhoz viszonyítottan a legkevesebb változtatással kívánnak egy megbízható, stabil verziót használni a rendszerbõl. Ugyan bármelyik ágból készülhetnek, azonban a -CURRENT esetében meglehetõsen sok változásra kell felkészülnünk (a -STABLE ághoz képest) az egyes kiadások között. A kiadások néhány havonta készülnek. Mivel a legtöbben ennél pontosabban követik a &os; forrásait (lásd a &os.current; és &os.stable; változatokra vonatkozó kérdéseket), ennél valamire többre van szükségünk, hiszen a források folyamatosan változnak. A &os; egyes kiadásairól a Kiadások megjelentetését összefoglaló oldalon tájékozódhatunk a &os; honlapján. Mi az a &os;-CURRENT? A &os.current; az operációs rendszer aktív fejlesztés alatt álló változata, amely idõvel az új &os.stable; ággá válik. Ez a változat tulajdonképpen csak a rendszeren dolgozó fejlesztõk és a megátalkodott hobbifelhasználók számára érdekes. A kézikönyv erre vonatkozó szakaszában olvashatunk részletesebben a -CURRENT használatáról. Ha nem mozgunk otthonosan az operációs rendszerek világában, vagy ha nem tudjuk megmondani a különbséget egy valódi és egy ideiglenes probléma között, akkor nem javasoljuk a &os.current; használatát. Ez a fejlesztési vonal nagyon gyorsan fejlõdik és néha lefordíthatatlan állapotba kerül. A &os.current; változat használóitól elvárjuk, hogy képesek legyenek felmérni a felbukkanó problémákat, és közülük csak azokat jelenteni, amelyek valóban hibákat takarnak és nem pedig csak apró bökkenõk. Ezért a &a.current; olvasói általában A make world parancs valami csoportra panaszkodik típusú kérdéseket általában figyelembe se veszik. A -CURRENT és -STABLE ágak aktuális állapotáról minden hónapban pillanatkiadások készülnek. Célunk ezzel: A telepítõ legfrissebb változatának tesztelése. Idõt és sávszélességet szeretnénk megspórolni a -CURRENT vagy -STABLE változatok azon felhasználóinak, akik az iméntiek hiányából fakadóan nem tudják naponta frissíteni a rendszerüket. Kiindulási pontokat rögzítünk a kód aktuális állapota alapján, ha késõbb netalán valamilyen szörnyûség történne. (Noha a CVS általában védelmet nyújt az ilyen rémisztõ dolgok bekövetkezése ellen.) Az összes tesztelendõ újítást és javítást ezen a módon kívánjuk a lehetõ legszélesebb körben elérhetõvé tenni. Egyik -CURRENT pillanatkiadás sem tekinthetõ hétköznapi felhasználásra alkalmasnak. Ha egy megbízható és széles körben tesztelt rendszerre van szükségünk, akkor vagy maradjunk a kiadásoknál vagy használjuk a -STABLE vonalból készült pillanatkiadásokat. A pillanatkiadások innen érhetõek el. Minden aktívan fejlesztett ághoz havonta készülnek hivatalos pillanatkiadások. A népszerûbb &arch.i386; és &arch.amd64; ágakból azonban napi kiadások is elérhetõek a a címen. Mit takar a &os;-STABLE? Amikor a &os; 2.0.5 megjelent, a &os; fejlesztése kettévált. Az egyik ág neve -STABLE, a másiké pedig -CURRENT lett. A &os;-STABLE az olyan internet-szolgáltatók és egyéb vállalkozások számára készült, ahol a fejlesztés alatt álló újítások vagy a hirtelen váltások által okozott problémák gyakran nem engedhetõek meg. Ide csak olyan hibajavítások és kisebb módosítások kerülnek, amelyeket alaposan leteszteltek. A &os;-CURRENT ezzel szemben a 2.0 megjelenése óta egyetlen, szakadásmentes fejlesztési vonalat képvisel, amely a &rel.current;-RELEASE és az azon túli kiadások felé halad. Ha többet szeretnénk megtudni a jelenlegi ágak állapotáról és a következõ kiadások ütemezésérõl, akkor ezzel kapcsolatban olvassuk el a &os; Release Engineering címû cikk kiadások leágaztatásáról szóló részét (angolul). Az ágak jelenlegi állapota és a jövõbeni kiadások ütemterve a Kiadások információk oldalán található (angolul). A 2.2-STABLE ág a 2.2.8 megjelenésével nyugdíjba vonult. A 3-STABLE ág a 3.5.1 mint az utolsó 3.X kiadás megjelenésével ért véget. A 4-STABLE ág a 4.11 mint az utolsó 4.X kiadással fejezõdött be. Ezekbe az ágakban a legtöbb esetben már csak biztonsági javításokat végeznek. Az 5-STABLE ág fejlesztése az utolsó 5.X kiadás, az 5.5 megjelenésével lezárult. A 6-STABLE ág fejlesztése még folytatódik valameddig, de ez alatt leginkább már csak a biztonsági rések és egyéb komoly problémák javításait kell érteni. A &rel.current;-STABLE a jelenleg fejlesztett -STABLE ág. A &rel.current;-STABLE ágból megjelent legfrissebb kiadás a &rel.current;-RELEASE, amely &rel.current.date;ban jelent meg. - A 8-CURRENT a -CURRENT ág + A 9-CURRENT a -CURRENT ág legfrissebb változata, és ez a &os; következõ generációja. Errõl az ágról a Mi az a &os;-CURRENT? kérdésnél szolgálunk részletesebb információkkal. Mikor készülnek &os; kiadások? A &a.re; átlagosan a &os; egy újabb nagyobb változatát 18 havonta, míg egy kisebb kiadását 8 havonta jelenteti meg. A kiadások dátumát elõre kihirdetik, így a rendszeren dolgozó emberek pontosan tudják, hogy mikorra kell befejezniük a munkájukat és letesztelni azt. Minden kiadást egy tesztelési idõszak elõz meg, ahol megbizonyosodnak róla, hogy az elkészült újítások nem veszélyeztetik az új kiadás megbízhatóságát. A legtöbb felhasználó pontosan ezt a típusú elõvigyázatosságot szereti legjobban a &os;-ben, még annak árán is, hogy a legújabb finomságok bekerülésére még a -STABLE ág esetén gyakran sokat kell várni. A kiadások szerkesztésérõl (valamint a soronkövetkezõ kiadások ütemezésérõl) a &os; honlapján belül ezen az oldalon olvashatunk részletesebben (angolul). Akik egy kicsivel több izgalomra vágynak, azok részére az elõbb említett, naponta készített bináris pillanatkiadásokat ajánljuk. Ki felel a &os;-ért? A &os; Projektre vonatkozó fontosabb döntéseket, mint például a Projekt haladási irányát vagy hogy vehet részt a forráskód fejlesztésében, egy 9 fõs irányító csoport hozza. Rajtuk kívül még egy több mint 350 fõs fejlesztõi csapat jogosult közvetlenül módosítani a &os; forrásait. A legtöbb bonyolultabb változtatást általában azonban a megfelelõ levelezési listákon is megvitatják, amiben bárki különösebb korlátozás nélkül részt vehet. Honnan lehet a &os;-t beszerezni? A &os; összes fontosabb kiadása elérhetõ anonim FTP-n keresztül a &os; FTP oldaláról: - A legfrissebb 7-STABLE kiadás, a + A legfrissebb 8-STABLE kiadás, a &rel.current;-RELEASE ebbõl a könyvtárból érhetõ el. Havonta készülnek pillanatkiadások a -CURRENT és a -STABLE ágakból, de ezek leginkább a legújabb változatot tesztelõk és a fejlesztõk számára fontosak. - A legfrissebb 6-STABLE kiadás, a + A legfrissebb 7-STABLE kiadás, a &rel2.current;-RELEASE ebbõl a könyvtárból érhetõ el. Ha a &os;-t CD-n, DVD-n vagy más egyéb telepítõeszközön szeretnénk megkapni, akkor ezzel kapcsolatban nézzük meg a kézikönyvet. Hogyan lehet elérni a hibajelentések adatbázisát? A felhasználók kéréseit tartalmazó hibajelentések adatbázisát a honlap webes hibajelentésekkel foglalkozó felületén keresztül érhetjük el. A &man.send-pr.1; parancs segítségével tudunk e-mailen keresztül hibajelentéseket és egyéb változtatási kéréseket küldeni. Emellett még böngészõ segítségével is tudunk hibajelentéseket küldeni a honlap webes hibabejelentõ felületén. Mielõtt beküldenénk egy hibajelentést, olvassuk el a Writing &os; Problem Reports címû cikket (angolul), amelybõl megtudhatjuk, hogyan készítsünk jól hasznosítható hibajelentéseket. Honnan tudhatunk meg még többet? Nézzük meg a &os; Projekt honlapjáról elérhetõ dokumentációkat. Dokumentációs és támogatás Milyen jó könyvek szólnak a &os;-rõl? A Projekt igen széles körû dokumentációval rendelkezik, amely a következõ linkrõl érhetõ el: . Emellett a GYIK végén szereplõ, valamint a kézikönyvben található irodalomjegyzék tartalmazza az ajánlott könyveket. A dokumentáció elérhetõ más formátumokban is, például szöveges (ASCII) állományban vagy &postscript;-ben? Igen. A dokumentáció több különbözõ állomány- és tömörítési formátumban elérhetõ az &os; FTP oldalán belül a /pub/FreeBSD/doc/ könyvtárból. A dokumentációt több különbözõ módon osztályozhatjuk. Többek közt: A dokumentum neve alapján, például faq (GYIK), vagy handbook (kézikönyv). A dokumentum nyelv és karakterkódolása alapján. Ezeket a &os; rendszerekben, a /usr/share/locale könyvtárban megtalálható nyelvi beállítások nevei szerint adjuk meg. Jelenleg a következõ nyelveken és kódolásokban érhetõ el a dokumentáció: Név Leírás en_US.ISO8859-1 Angol (Egyesült Államok) bn_BD.ISO10646-1 Bengáli vagy bangla (Banglades) da_DK.ISO8859-1 Dán (Dánia) de_DE.ISO8859-1 Német (Németország) el_GR.ISO8859-7 Görög (Görögország) es_ES.ISO8859-1 Spanyol (Spanyolország) fr_FR.ISO8859-1 Francia (Franciaország) hu_HU.ISO8859-2 Magyar (Magyarország) it_IT.ISO8859-15 Olasz (Olaszország) ja_JP.eucJP Japán (Japán, EUC kódolás) mn_MN.UTF-8 Mongol (Mongólia, UTF-8 kódolás) nl_NL.ISO8859-1 Holland (Hollandia) no_NO.ISO8859-1 Norvég (Norvégia) pl_PL.ISO8859-2 Lengyel (Lengyelország) pt_BR.ISO8859-1 Portugál (Brazília) ru_RU.KOI8-R Orosz (Oroszország, KOI8-R kódolás) sr_YU.ISO8859-2 Szerb (Szerbia) tr_TR.ISO8859-9 Török (Törökország) zh_CN.GB2312 Egyszerûsített kínai (Kína, GB2312 kódolás) zh_TW.Big5 Hagyományos kínai (Tajvan, Big5 kódolás) Nem mindegyik dokumentum érthetõ el mindegyik nyelven. A dokumentum formátuma alapján. A dokumentumok több különbözõ formátumban állnak rendelkezésre. Mindegyik formátum használatának megvannak az elõnyei és hátrányai. Egyes formátumok inkább az interneten keresztüli olvasgatásra megfelelõek, mások pedig nyomtatott formában nyújtanak esztétikus hatást. A több különbözõ formátumnak köszönhetõen az olvasók igényeik szerint el tudják olvasni a dokumentáció különbözõ részeit akár a képernyõn, akár papíron. Jelenleg a következõ formátumokban érhetõek el a dokumentumok: Formátum Leírás html-split Kis méretû, hiperhivatkozásokkal ellátott HTML állományok gyûjteménye html Egyetlen óriási, az egész dokumentumot tartalmazó HTML állomány pdb A Palm Pilot adatbázisának formátuma, amelyet az iSilo segítségével tudunk olvasni pdf Az Adobe-féle Portable Document Format ps &postscript; rtf A Microsoft Rich Text formátuma txt Egyszerû szöveges állomány Amikor egy ilyen dokumentumot betöltünk a Wordbe, akkor az oldalszámok maguktól nem frissülnek. Ehhez a dokumentum betöltése után nyomjuk le a CtrlA, CtrlEnd, F9 billentyûket. A tömörítés és csomagolás típusa alapján. Ezek közül jelenleg hármat használunk. Ahol a formátum html-split, ott az állományokat a &man.tar.1; segítségével csomagoltuk össze. Az így keletkezõ .tar állományt ezek után az alábbi részben szereplõ tömörítési megoldásokkal tömörítettük. Az összes többi formátum esetén csak egyetlen állomány keletkezik, amelynek a neve típus.formátum (tehát például article.pdf, book.html és így tovább). Ezeket az állományokat azután két tömörítési eljárással tömörítjük. Eljárás Leírás zip A zip formátum. &os; alatt ezt úgy tudjuk kitömöríteni, ha elõször telepítjük a archivers/unzip portot. bz2 A bzip2 formátum. Nem olyan elterjedt, mint a zip, de általában kisebb méretû állományokat készít. Ilyen állományokat akkor tudunk kitömöríteni, ha telepítjük a archivers/bzip2 portot. Ennek megfelelõen tehát a kézikönyv bzip2-vel tömörített &postscript; változata a handbook/ könyvtáron belül book.ps.bz2 néven található. Miután kiválasztottuk a számunkra megfelelõ letöltendõ formátumot és tömörítési módszert, magunknak kell letölteni a kiválasztott tömörített állományokat, majd kibontani ezeket és átmásolni a megfelelõ helyre. Például, ha a GYIK fejezetekre darabolt, &man.bzip2.1; segítségével tömörített változata a doc/en_US.ISO8859-1/books/faq/book.html-split.tar.bz2 állományban található meg. A letöltéséhez és kibontásához a következõket kell tennünk: &prompt.root; fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/en_US.ISO8859-1/books/faq/book.html-split.tar.bz2 &prompt.root; bzip2 -d book.html-split.tar.bz2 &prompt.root; tar xvf book.html-split.tar A mûvelet befejezõdésével kapunk néhány .html kiterjesztésû állományt. Ezek közül az egyik neve index.html, ebben található a tartalomjegyzék, a bevezetés és a dokumentum többi részére mutató hivatkozások. Ezeket az állományokat kell szükség szerint átmásolnunk vagy átmozgatnunk a megfelelõ helyre. Hol található információ a &os; levelezési listáiról? Az összes velük kapcsolatos információt a kézikönyv levelezési listákról szóló részében találjuk. Milyen &os; hírcsoportok léteznek? Az összes rájuk vonatkozó információt a kézikönyv hírcsoportokról szóló részében találjuk meg. Vannak &os;-s IRC (Internet Relay Chat) csatornák? Igen, a legtöbb nagyobb IRC hálózaton található &os;-vel foglalkozó csatorna: Az EFNet hálózaton található #FreeBSD csatorna lényegében egy &os;-vel foglalkozó fórum, de itt ne nagyon próbálkozzunk segítséget kérni a többiektõl, ha netalán lusták lennénk elolvasni a man oldalakat vagy éppen kutatunk valamit. Ez a hely elsõsorban csevegésre szolgál, ahol mindenféle téma felmerül, a szextõl kezdve a sportokon keresztül a nukleáris fegyverekig éppen úgy, ahogy a &os;-rõl is. Mi szóltunk elõre! A szerver a irc.efnet.org címen érhetõ el. Az EFNet hálózaton található #FreeBSDhelp csatorna kifejezetten a &os; felhasználók megsegítését veszi célba. Az itt levõk sokkal szívesebben válaszolnak a kérdéseinkre, mint a #FreeBSD csatornán. A Freenode hálózaton található ##FreeBSD csatornán mindig sokan vannak, itt bármilyen témában kérhetünk segítséget. A beszélgetések idõnként ugyan kifutnak a szigorú szakmai témákból, de a &os;-vel kapcsolatos kérdések itt mindig elsõbbséget élveznek. Szívesen segítünk bárkinek, és lehetõség szerint igyekszünk a kézikönyv megfelelõ részeire hivatkozni, vagy adni valamilyen útmutatást arra vonatkozóan, hogy merre tájékozódhatunk részletesebben a problémánkkal kapcsolatban. Ez alapvetõen egy angol nyelvû csatorna, habár a világ minden tájáról érkeznek tagjaink. Ha az anyanyelvünkön szeretnénk inkább csevegni, akkor elõször tegyük fel a kérdésünket angolul, aztán próbálkozzunk a megfelelõ ##freebsd-nyelv csatornán. A DALNET hálózaton található #FreeBSD csatorna az Egyesült Államokból a irc.dal.net szerveren, Európából pedig az irc.eu.dal.net szerveren keresztül érhetõ el. A DALNET hálózaton található #FreeBSDHelp csatorna az Egyesült Államokból a irc.dal.net szerveren, Európából pedig a irc.eu.dal.net szerveren keresztül érhetõ el. Az UNDERNET hálózaton található #FreeBSD csatorna az Egyesült Államokból a us.undernet.org, Európából pedig a eu.undernet.org szerveren keresztül érhetõ el. Mivel ez a csatornát leginkább segítségnyújtásra tartjuk fenn, készüljünk fel arra, hogy a hivatkozott dokumentumokat is el kell olvasnunk. A RUSNET hálózaton található #FreeBSD csatorna az oroszul beszélõ &os; felhasználók számára igyekszik segítséget nyújtani. Emellett viszont remek hely a nem szakmai jellegû témák megvitatásához is. A Freenode hálózaton található #bsdchat csatorna a hagyományos kínai (UTF-8 kódolású) nyelvet beszélõ &os; felhasználókat igyekszik segíteni. A nem szakmai jellegû témák részére is egy remek hely. Az említett csatornák mindegyike egymástól független, és nem állnak egymással kapcsolatban. Sõt, még a csevegési stílusuk is eltérõ, ezért érdemes a saját stílusunkhoz leginkább illeszkedõt megkeresni. Mint ahogy az összes IRC csatorna esetében elõfordul, itt is könnyedén érhetnek bennünket személyes sértések vagy egyszerûen csak sok szóbeli sárdobálást láthatunk (mivel jóval több az ilyen helyeken a balga ifjú, mint a higgadtabb idõs) — ezekkel ne is törõdjünk! Hol kaphatok kereskedelmi szintû &os; tréninget és támogatást? A DaemonNews nyújt kereskedelmi szintû támogatást és tréninget a &os;-hez. Errõl részletesebb információkat a BSD Mall honlapján kaphatunk. A &os; Mall is nyújt keresdelmi támogatást a &os;-hez. Errõl a honlapjunkon tudhatunk meg többet. A BSD Certification Group, Inc. DragonFly BSD, &os;, NetBSD és OpenBSD rendszerekhez ad rendszergazdai képesítéseket. Amennyiben érdekel minket, látogassunk el a honlapjukra. Kérünk minden olyan további szervezetet, amely tréninget vagy támogatást kíván nyújtani a Projektnek, hogy jelentkezzenek és felvesszük õket a listánkra! Nik Clayton
nik@FreeBSD.org
 Telepítés Milyen állományokat kell letöltenünk a &os; telepítéséhez? Ehhez a következõ három floppy image-re lesz alapvetõen szükségünk: floppies/boot.flp, floppies/kern1.flp és floppies/kern2.flp. Ezeket az image-eket az fdimage vagy &man.dd.1; segédprogramokkal kell rámásolnunk lemezekre. Ha magukat a terjesztéseket akarjuk letölteni (mert például egy DOS típusú állományrendszerrõl akarunk telepíteni), akkor az alábbi terjesztéseket kell beszereznünk: base/ manpages/ compat*/ doc/ src/ssys.* A teljes folyamatot, valamint a telepítéssel kapcsolatos általános tudnivalókat valamivel bõvebben a kézikönyv &os; telepítésével foglalkozó részébõl ismerhetjük meg. Mit tegyünk, ha a floppy image-ek nem férnek rá egyetlen lemezre? Egy 3,5 colos (1,44 MB kapacitású) lemezen 1 474 560 byte-nyi adat fér el. A rendszerindításhoz használt image mérete is pontosan 1 474 560 byte. A rendszerindító lemezek elõkészítése során elkövetett hibák általában a következõk: Amikor az image-eket FTP-n keresztül töltjük le, elfelejtünk bináris (binary) átviteli módot használni. Egyes FTP kliensek alapértelmezés szerint szöveges (ascii) módban viszik át az állományokat, és ennek során megpróbálják a sorvége karaktereket az adott operációs rendszer konvenciói szerint átalakítani. Ilyenkor szinte kétségtelen, hogy ezzel tönkreteszik az image-et. Ezért ne felejtsük el ellenõrizni a letöltött image-eket: ha a méretük nem egyezik meg pontosan a szerveren levõ változatukéval, akkor gyaníthatóan a letöltés közben történt velük valami. Megoldás: miután csatlakoztunk a szerverhez, de még mielõtt elkezdük volna a letöltést, az FTP kliens parancssorában gépeljük be, hogy binary. Az image lemezre másolása a DOS copy parancsának (vagy hasonló grafikus eszközök) használatával. A copy és a hozzá hasonló programok nem használhatóak erre a célra, mivel az image-eket közvetlenül a rendszeindításhoz hozták létre. Ennek megfelelõen az egyes image-ek a lemezek teljes tartalmát sávról sávra tartalmazzák, és így nem hétköznapi állományként kell velük bánni. Ezeket a floppykra alacsonyszintû eszközök (például az fdimage vagy rawrite) segítségével, nyers módban kell felvinni, ahogy azt a &os; telepítését leíró útmutatóban is olvashatjuk. Hol található leírás a &os; telepítésérõl? A telepítés részletes leírása a kézikönyv &os; telepítésérõl szóló részében olvasható. Mire van szükség a &os; használatához? A &os; használatához egy 486-os vagy jobb processzorral rendelkezõ számítógépre, 24 MB vagy annál több memóriára, és legalább 150 MB tárhelyre lesz szükségünk. A &os; összes változata képes futni szinte bármilyen olcsó MDA típusú grafikus kártyával, de az &xorg; használatához már VGA vagy annál jobb videokártya szükségeltetik. Lásd . Hogyan lehet saját telepítõfloppyt készíteni? Jelen pillanatban ennek nincs egyszerû módja. Minden egyes kiadáshoz tartoznak telepítõfloppyk, használjuk ezeket. Ha egy módosított kiadást akarunk készíteni, kövessük a(z angol nyelvû) Release Engineering cikk útmutatásait. A számítógépre lehet egynél több operációs rendszert is telepíteni? Olvassuk el a A &os; telepítése és használata más operációs rendszerekkel együtt címû cikket. &windows; mellé is telepíhetõ &os;? Elõször telepítsük a &windows;t, majd a &os;-t. A &os; boot managere ekkor képes lesz a &windows; és a &os; indítására is. Vigyázzunk, mert ha a &windows;t telepítjük fel másodikként, akkor az minden figyelmeztetés nélkül durván felülírja az aktuális boot managert. Ha ezt tapasztaljuk, akkor olvassuk el a következõ szakaszt. A &windows; letörölte a boot managert! Hogyan lehet visszaállítani? A &os;-hez tartozó boot managert háromféleképpen tudjuk újratelepíteni: Indítsuk el a DOS-t, lépjünk be a &os; terjesztéshez tartozó tools könyvtárba és keressük meg a bootinst.exe nevû állományt. Indítsuk el a következõ módon: ...\TOOLS> bootinst.exe boot.bin Ekkor a boot manager visszakerül a helyére. Használjuk a &os;-hez létrehozott rendszerindító lemezeket, és a telepítõben válasszuk a Custom (Egyéni telepítés) menüpontot, majd azon belül válasszuk a Partition (Partíció) pontot. Itt válasszuk ki azt a meghajtót, ahol korábban a boot managerünk volt (ez valószínûleg a felsorolásban az elsõ lesz) és amikor belépünk a partíciószerkesztõbe, akkor egybõl válasszuk a Write (W) opciót (tehát ne változtassunk semmit). Ez megerõsítést fog kérni, amire válasszuk a &gui.yes; gombot, és amikor a boot manager kiválasztása rész jelenik meg, válasszuk a FreeBSD Boot Manager pontot. Ezzel a boot manager újra a lemezre íródik. Miután ezzel végeztünk, lépjünk ki a telepítõbõl és indítsuk újra a rendszerünket a megszokott módon. Indítsuk a rendszerünket a &os; rendszerindító lemezérõl (vagy CD-jérõl), majd válasszuk a telepítõben a Fixit (Javítás) menüpontot. Ezután válasszuk a javítófloppy vagy a(z élõ állományrendszerrel rendelkezõ) 2. CD használatát, majd lépjünk be a javításhoz elindított parancsértelmezõbe. Ezt követõen adjuk ki az alábbi parancsot: Fixit# fdisk -B -b /boot/boot0 eszköz A parancsban az eszköz helyére annak az eszköznek a nevét adjuk meg, amelyrõl a rendszert szoktuk indítani, például ad0 (az elsõ IDE-lemez), ad4 (az elsõ IDE-lemez valamelyik vezérlõn), da0 (az elsõ SCSI-lemez) stb. Az A, T és X sorozatú IBM Thinkpad laptopok lefagynak a &os; telepítése utáni elsõ indulásuk során. Hogy lehet ezen segíteni? Ezeken a gépeken az IBM BIOS-ának egy korai hibás változata található, amely a &os; által használt partíciókat tévesen suspend-to-disk típusú partícióknak tekinti. Ennek következtében amikor a BIOS megpróbálja értelmezni a &os; által létrehozott partíciót, megakad. Az IBM Ahogy Keith Frechette (kfrechet@us.ibm.com) írta levelében. szerint az alábbi típus/BIOS változatokban található meg ez a hiba. Típus BIOS T20 IYET49WW vagy késõbbi T21 KZET22WW vagy késõbbi A20p IVET62WW vagy késõbbi A20m IWET54WW vagy késõbbi A21p KYET27WW vagy késõbbi A21m KXET24WW vagy késõbbi A21e KUET30WW Úgy értesültünk, hogy az IBM BIOS-ok késõbbi változataiban ismét felbukkant ez a típusú hiba. Ebben az üzenetben &a.nectar; a &a.mobile; tagjainak egy olyan módszert mutat be, ami segíthet, ha az újabb típusú IBM laptopunk nem tudja elindítani a &os;-t, és így váltani tudunk a BIOS elõzõ vagy következõ verziójára. Ha régebbi típusú BIOS-szal rendelkezünk és a frissítés nem megoldható, akkor a &os;-t telepíthetjük úgy is, hogy megváltoztatjuk a &os; által használt partíció azonosítóját és egy olyan rendszerindító blokkot telepítünk, amelyik képes ezt kezelni. Ehhez elõször is a gépet egy olyan állapotba kell visszahoznunk, ahol már túl tudunk jutni a rendszerindító képernyõn. Ezt úgy tudjuk elérni, ha nem engedjük, hogy a gép indulása közben észrevegye az elsõdleges lemezen található &os; partíciót. Erre az egyik lehetséges megoldás, ha a gépbõl ideiglenesen eltávolítjuk a merevlemezt és átrakjuk egy régebbi ThinkPadba (például egy ThinkPad 600-as típusba) vagy a megfelelõ átalakító használatával az asztali számítógépünkbe. Miután ezzel megvagyunk, töröljük le a &os; partícióját és tegyük vissza a lemezt. Ekkor a ThinkPad újból mûködõképes lesz. Ezt követõen az alábbi utasításokat követve tudjuk telepíteni a &os;-t: Töltsük le a boot1 és boot2 állományokat a címrõl. Olyan helyre tegyük ezeket, ahol késõbb is még el tudjuk érni. A megszokott módon telepítsük a &os;-t a ThinkPadre. Ilyenkor ne használjuk a Veszélyesen dedikált (Dangerously Dedicated) módot. A telepítés befejezése után ne indítsuk újra a gépet. Váltsunk át a vészhelyzetekben használatos parancsértelmezõre (Emergency Holographic Shell, Alt F4) vagy indítsuk el egy javításhoz használt (fixit) parancsértelmezõt. Az &man.fdisk.8; segítségével változtassuk meg a &os;-s partíció azonosítóját a 165 értékrõl a 166 értékre (ezt a típust az OpenBSD használja). Másoljuk át az imént letöltött boot1 és boot2 állományokat a helyi állományrendszerre. A &man.disklabel.8; segítségével rögzítsük a boot1 és boot2 tartalmát a &os; slice-unkra. &prompt.root; disklabel -B -b boot1 -s boot2 ad0sn ahol az n annak a slice-nak a sorszáma, ahová a &os;-t telepítettük. Indítsuk újra a gépet. A rendszerindító parancssorban ekkora megjelenik az OpenBSD indításának lehetõsége. Ezen keresztül tudjuk a &os;-t elindítani. A kedves Olvasónak meghagytuk azt az esetet, amikor ugyanezen a konfiguráción OpenBSD és &os; rendszereket akarunk egyszerre használni. Lehet telepíteni hibás szektorokat tartalmazó lemezre is? Igen, ez lehetséges, de egyáltalán nem ajánlott. Manapság ha egy IDE-meghajtón hibás szektorokat találunk, akkor az arra utal, hogy hamarosan tönkremegy (a meghajtó belsõ átképezõ funkciói már képesek megbirkózni a rossz szektorok növekvõ számával, ami arra enged következtetni, hogy a lemez felülete jelentõs mértékben sérült). Ezért inkább egy új merevlemezes meghajtó vásárlását javasoljuk. Ha hibás SCSI-meghajtónk van, ezt a választ olvassuk el. Furcsa dolgok történnek a telepítõfloppy használata közben! Mi okozhatja? Ha olyan furcsa dolgokkal találkozunk a telepítõfloppy használata során, mint például a lemez állandó darálása vagy a rendszer váratlan újraindulása, akkor a következõ három kérdést érdemes feltennünk magunknak: Biztos, hogy új, frissen formázott, teljesen hibamentes floppykat használunk (tehát olyanokat, amelyeket egy frissen bontott dobozból vettünk ki, és nem olyanokat, amelyeket valamelyik magazin mellékletébõl szedtük ki vagy éppen három évig az ágy alatt tároltunk)? Biztos, hogy bináris (vagy image) módban töltöttük le a lemezek image-eit? (Ne szégyelljük, mindenki életében legalább egyszer töltött már le véletlenül bináris állományt szöveges formátumban!) &windows; 95 vagy &windows; 98 alatt DOS módban használtuk az fdimage vagy rawrite parancsot? Ezek az operációs rendszerek általában nem férnek össze az olyan programokkal, amelyek közvetlenül a hardverrel akarnak kommunikálni, amire a lemezek írásához is szükség van. Ez a probléma leginkább akkor merülhet fel, amikor a grafikus felületen belül egy DOS ablakban futtatjuk ezeket a programokat. Kaptunk olyan visszajelzést is, hogy gondjaink lehetnek, ha &netscape;-pel töltjük le a rendszerindító lemezeket, ezért lehetõség szerint igyekezzünk más FTP klienst használni. ATAPI CD-meghajtóról indult a rendszer, de a telepítõ szerint nem található semmilyen CD-meghajtó. Hova tûnt? Ezt a problémát általában egy rosszul beállított CD-meghajtó okozza. A CD-meghajtó rengeteg számítógépben a másodlagos IDE-vezérlõ slave (szolga) portján található, a master (mester) port használata nélkül. Ez az ATAPI specifikációi szerint nem szabályos, de a &windows; ezzel különösebben nem törõdik, a BIOS pedig egyszerûen figyelmen kívül hagyja a rendszer indítása során. Ezért képes a BIOS ilyenkor látni a CD-meghajtót, és ezért nem képes a &os; teljes telepítésnél használni. Ezen úgy tudunk segíteni, ha a CD-meghajtónkat az IDE-vezérlõn átállítjuk masterre, vagy arra az IDE-vezérlõre teszünk egy master eszközt. PLIP (Parallel Line IP) használatával lehet laptopra telepíteni? Igen. Ehhez csupán egy szabványos Laplink-kábel kell. Amennyiben szükséges, a párhuzamos vonali hálózatkezelés beállításához olvassuk el kézikönyv PLIP-rõl szóló részét. A lemezmeghajtók esetében milyen geometriai beállításokat érdemes használni? A lemez geometriája alatt a lemezen található cilinderek, fejek és a sávonkénti szektorok számát értjük. Ezt a továbbiakban csak CHS-értéknek nevezzük (mint Cylinder/Head/Sector). Ebbõl állapítja meg a PC-s BIOS, hogy a lemezen honnan kell olvasnia és hova kell írnia. Ez rengeteg félreértést okoz az újdonsült rendszergazdák számára. Elõször is megemlítenénk, hogy egy SCSI-lemez fizikai geometriája ebben az esetben teljesen lényegtelen, mivel a &os; lemezblokkokban gondolkozik. Igazából nem létezik a fizikai geometria fogalma, ugyanis a szektorok sûrûsége a lemezen felületén belül sem állandó. Amit a gyártók általában fizikai geometriának hívnak, az általában az a geometria, amely a legkevesebb helyveszteséggel jár. Az IDE-lemezek esetében a &os; ugyan CHS-értékekkel dolgozik, de ezt minden modernebb meghajtó legbelül blokkhivatkozásokká alakítja. Egyedül tehát a logikai geometria számít. Ez a válasz, amikor a BIOS megkérdezi a meghajtónkat: Mik a geometriai beállításaid?, és ennek felhasználásával kommunikál vele a késõbbiekben. Mivel a &os; is ezt az értéket használja fel a rendszer indításánál, fontos, hogy jól adjuk meg. Ez különösen abban az esetben számít, amikor több operációs rendszer is található a lemezen, hiszen mindegyiküknek azonos geometriai beállításokat kell használniuk. Ellenkezõ esetben komoly gondok léphetnek fel a rendszer indítása során! A SCSI-lemezek esetében a beállítandó geometria értéke attól függ, hogy a vezérlõn használjuk-e a bõvített fordítás támogatását (extended translation support, amelyet gyakran csak úgy neveznek, hogy Support for DOS disks >1GB vagy ehhez hasonlóan). Ha ezt letiltottuk, akkor használjuk az N cilinder, 64 fej és 32 szektor sávonkénti felírást, ahol N a lemez MB-okban számított mérete. Így például egy 2 GB méretû lemez geometriai beállítása 2048 cilinder, 64 fej és 32 szektor sávonként. Ha viszont engedélyeztük (ami gyakran elõfordul, mivel így lehet az &ms-dos; bizonyos korlátozásait megkerülni) és a lemez kapacitása 1 GB-nál több, adjunk meg M cilindert, 255 fejet, 63 (és nem 64) szektort sávonként, ahol az M a lemez MB-okban mért kapacitása osztva 7,844238-al (!). Tehát az iménti példában is említett 2 GB-os meghajtó esetében 261 cilindert, 255 fejet és sávonként 63 szektort kapunk. Ha nem lennénk benne biztosak, vagy a &os;-nek a telepítés közben nem sikerül megállapítania a lemez geometriai beállításait, mi magunk is könnyen meg tudjuk határozni, ha készítünk egy kis méretû DOS partíciót a lemezen. A BIOS ekkor észlelni fogja a megfelelõ geometriai beállításokat, és ha már nincs rá tovább szükségünk, akkor a partíciószerkesztõben nyugodtan törölhetjük. Hálózati kártyák és hasonló hardverek programozásához azonban még a késõbbiekben hasznos lehet. Használhatjuk viszont a &os;-hez mellékelt pfdisk.exe segédprogramot is. Ezt a &os; CD vagy a &os; FTP oldalainak tools könyvtárában találhatjuk meg. Ennek a programnak a segítségével ki tudjuk deríteni, hogy a lemezen levõ többi operációs rendszer milyen geometriai beállításokat használ. Az így kapott értékeket fel tudjuk használni a partíciószerkesztõben. Van valamilyen korlátozás a lemezek felosztására vonatkozóan? Igen. A rendszerindításhoz használt (gyökér)partíciónak az 1024. cilinder alatt kell kezdõdnie, mivel a BIOS csak így képes betölteni onnan a rendszermagot. (Ez a korlátozás a PC-s BIOS-ok miatt van, nem a &os; miatt.) A SCSI-lemezek esetében ez általában azt jelenti, hogy rendszerindításhoz használt partíciónak az elsõ 1024 MB alatt kell kezdõdnie (vagy az elsõ 4096 MB alatt, ha a bõvített fordítást is engedélyeztük — lásd az elõzõ kérdést). Az IDE-lemezek esetében ez 504 MB-nak felel meg. A &os; kompatibilis valamilyen disk managerrel? A &os; felismeri az Ontrack Disk Managert és figyelembe veszi. A többi disk managert nem támogatja. Ha egyedül csak a &os;-t akarjuk használni, akkor nincs szükségünk disk managerre. Egyszerûen csak állítsunk be egy akkora méretû lemezt, amivel a BIOS képes még megbirkózni (a határ általában 504 MB) és majd a &os; kideríti, hogy valójában mennyi hely áll a rendelkezésére. Ha régebbi gyártmányú merevlemezünk van MFM-vezérlõvel, akkor a &os;-nek konkrétan meg kell mondanunk, hogy mennyi cilindert használhat. Ha a &os; mellett más operációs rendszereket akarunk használni, akkor ezt disk manager nélkül is megtehetjük. Egyedül arra kell vigyáznunk, hogy a &os; indításához használt partíció és a másik operációs rendszer slice-a az elsõ 1024 cilinder alatt kezdõdjön. Ha nagyon körültekintõek akarunk lenni, akkor erre a célra egy 20 MB méretû rendszerindító partíció tökéletesen megfelel. Amikor a &os;-t telepítése után elõször elindul, akkor egy Hiányzó operációs rendszer vagy egy Missing Operating System hiba jelenik meg. Mi történt? Ez általában akkor fordul elõ, amikor a &os; és a DOS vagy más operációs rendszerek nem értenek egyet a lemez geometriai beállításaiban. Telepítsük újra a &os;-t és ezúttal figyelmesen kövessük a fentebb adott utasításokat! Miért nem lehet továbblépni a boot manager F? menüjénél? Ez az elõbbi kérdéssel kapcsolatos probléma egy másik tünete: a BIOS és a &os; által használt geometriai beállítások nem egyeznek! Amennyiben a vezérlõ vagy a BIOS támogatja a cilinderek fordítását (amelyet gyakran >1GB driver support néven találhatunk meg), akkor próbáljuk meg átállítani és így újratelepíteni a &os;-t. Az összes forrást telepíteni kell? Alapvetõen nem. Ettõl függetlenül azonban javasoljuk legalább a base források telepítését, ahol számos olyan állomány megtalálható, amelyekre a késõbbiekben még hivatkozni fogunk, valamint a sys (rendszermag) források telepítését, amelyben a rendszermag forrásai találhatóak. A rendszeren belül azonban a mûködéshez semmi sem igényli közvetlenül a források jelenlétét, egyedül talán a rendszermag beállítását végzõ &man.config.8; program. A rendszermag forrásainak kivételével a rendszerben a fordítás menetét úgy építettük fel, hogy akár egy írásvédett módon csatlakoztatott NFS állományrendszerrõl is képes legyen dolgozni (a rendszermag forrásaira vonatkozó megszorítások miatt azonban azt javasoljuk, hogy ezt közvetlenül ne a /usr/src könyvtárba csatlakoztassuk, hanem egy másik helyre, ahol aztán szimbolikus linkek segítségével másoljuk le a forráskód könyvtárszerkezetének legfelsõ szintjét). Ha kéznél vannak a források és tisztában vagyunk a rendszerfordítás folyamatával, akkor a késõbbiekben sokkal könnyebben tudjuk a &os; rendszerünket frissíteni. A források egyes részeinek kiválasztásához lépjünk be a telepítõprogram Custom (Egyéni telepítés), majd a Distributions (Terjesztések) menübe. Kell rendszermagot fordítani? Egy új rendszermag fordítása korábban fontos része volt a &os; telepítésének, de a legújabb kiadások már kihasználják a rendszermag beállításának sokkal baratságosabb módszereit is. A &os; 5.X és az azt követõ változatokban már a betöltõbõl könnyen be tudjuk állítani a rendszermagot a beépített hints (eszközökre vonatkozó útmutatások) módszere által felkínált rugalmasabb lehetõségeknek köszönhetõen. Egy új rendszermag készítése viszont olyan esetekben még továbbra is hasznos lehet, amikor csak azokat a meghajtókat akarjuk megtartani benne, amelyekre ténylegesen szükségünk van. Ezzel többnyire memóriát tudunk megspórolni, habár a legtöbb rendszer esetében erre igazából nincs szükségünk. A jelszavak tárolására használható-e DES, Blowfish vagy MD5, és ha igen, akkor hogyan lehet megadni? A &os; alapértelmezés szerint MD5-alapú jelszavakat használ. Ezeket a DES algoritmuson alapuló hagyományos &unix;-os jelszavaknál sokkal megbízhatóbbnak tartják. A DES formátum természetesen továbbra is elérhetõ olyan esetekben, amikor a kevésbé biztonságos jelszavakat használó régi operációs rendszerekkel akarunk együttmûködni. Emellett a &os;-ben lehetõségünk van a sokkal biztonságosabb Blowfish jelszóformátum használatára is. Az új jelszavak formátumát az /etc/login.conf állományban található passwd_format bejelentkezési tulajdonság adja meg, amelynek értéke des, blf (amennyiben elérhetõ), illetve md5 lehet. A bejelentkezési tulajdonságokkal kapcsolatban a &man.login.conf.5; man oldalt érdemes elolvasni. A rendszerindító lemez elõször elindul, de aztán miért akad meg a Probing Devices... képernyõn? Ha a rendszerünkhöz IDE-s &iomegazip; vagy &jaz; meghajtót csatlakoztattunk, akkor próbálkozzunk újra az eltávolítása után. A rendszerindító floppy ugyanis hajlamos összekeverni a meghajtókat. A rendszer telepítése után természetesen újra csatlakoztathatjuk a meghajtót. Ezt remélhetõleg egy következõ verzióban már kijavítják. A rendszer telepítését követõ újraindítás után miért jelenik meg a panic: can't mount root hibaüzenet? Ez a hiba a rendszerindító blokk és a rendszermag közti félreértésbõl, a lemezes eszközök helytelen kezelésébõl fakad. Ilyen hibát általában olyan rendszerekben kapunk, ahol két masternek beállított IDE-lemez található vagy ha az egyes IDE-vezérlõkre csak egy-egy eszközt csatlakoztattunk és a &os;-t a másodlagos IDE-vezérlõre kapcsolódó lemezre telepítettük. Ekkor a rendszerindító blokk szerint a rendszert az ad0 (de a BIOS-ban a második) lemezre telepítettük, miközben a rendszermag szerint ez a másodlagos IDE-vezérlõn elhelyezkedõ elsõ lemez, az ad2. Az eszközök felkutatása után a rendszermag megpróbálja a rendszerindító blokk által nyilvántartott eszközrõl, az ad0 lemezrõl csatlakoztatni a rendszerindító partíciót, ami viszont számára a ad2 eszköz lesz, így ez a próbálkozása meghiúsul. Ezt a félreértést a következõ módokon lehet helyretenni: Indítsuk újra a rendszert és nyomjuk le az Enter billentyût, amikor a Booting kernel in 10 seconds; hit [Enter] to interrupt szöveg megjelenik. Ezzel a rendszerbetöltõ parancssorába kerülünk. Ezután gépeljük be a set root_disk_unit="lemezszám" sort. Itt a lemezszám értéke 0 lesz, ha a &os;-t az elsõdleges IDE-vezérlõ master portján levõ merevlemezre telepítettük, 1, ha az elsõdleges IDE-vezérlõ slave portjára, 2, ha a másodlagos IDE-vezérlõ master portjára, és végül 3, ha a másodlagos IDE-vezérlõ slave portjára. Most már begépelhetjük, hogy boot, és így a rendszernek el is kell indulnia. Ha ezt a változtatást véglegesíteni akarjuk (vagyis nem akarjuk ugyanezt eljátszani a &os; minden egyes indítása során), akkor a /boot/loader.conf.local állományba vegyünk fel a root_disk_unit="lemezszám" sort. Tegyük át a &os;-t tartalmazó lemezt az elsõdleges IDE-vezérlõre, és ezzel megszûnik az iménti félreértés. Mennyi memóriát tudunk használni? A memóriára vonatkozó korlátozások platformonként változnak. Egy szabványos &i386; telepítés esetén például ez a határ 4 GB, de &man.pae.4; segítségével akár még ennél több is elérhetõ. Ehhez olvassuk el az &i386; platformon 4 GB-nál több memória használatára vonatkozó utasításokat. A &os;/pc98 esetén a korlát szintén 4 GB, azonban itt a PAE nem használható. A &os; által támogatott összes többi architektúra elméletileg ennél több memóriát képes kezelni (több terabyte-ot). Mik az FFS állományrendszerek korlátai? Az FFS állományrendszerek méretének elméleti határa 8 TB (2 milliárd blokk), illetve az alapértelmezett 8 KB-os blokkméret esetén 16 TB. A gyakorlatban azonban szoftveresen ebbõl 1 TB használható ki, de kisebb módosításokkal akár 4 TB-os állományrendszer is használható (és létezik). Egyetlen FFS állományrendszerbeli állomány mérete megközelítõleg legfeljebb 1 milliárd blokk lehet, ami 4 KB-os blokkmérettel számolva 4 TB-ot jelent. Az állományok maximális mérete Blokkméret Gyakorlatban Elméletben 4 KB > 4 GB 4 TB - 1 8 KB > 32 GB 32 TB - 1 16 KB > 128 GB 32 TB - 1 32 KB > 512 GB 64 TB - 1 64 KB > 2048 GB 128 TB - 1
4 KB-os blokkméret esetén a háromszoros indirekcióval származtatott blokkok a gyakorlatban is kihasználhatóak, és az egészet elméletben egyedül csak az állományrendszerben így ábrázolható blokkok maximális száma korlátozná (ami kb. 10243 + 10242 + 1024), azonban a gyakorlatban ezt az állományrendszeri blokkokra vonatkozó 1 GB - 1 méretû (rossz) határ korlátozza. Az állományrendszeri blokkok számát ugyanis ki kellene terjeszteni a 2 GB - 1 méretig. 2 GB - 1 számú blokk használata körül jelentkezik ugyan néhány hiba, de ezek 4 KB-os blokkméret esetén nem is érhetõek el. A 8 KB-nál nagyobb blokkméretek esetén mindenre a blokkok 2 GB - 1 maximális mennyisége érvényes, de a gyakorlatban ezt a blokkok számának 1 GB - 1 határa korlátozza. Az eredeti 2 GB - 1 mennyiségû blokk használata gondokat okozhat. Egy új rendszermag fordítása után miért jelenik meg a archsw.readin.failed hibaüzenet az indítás során? Mert a rendszermag és a felhasználói programok verziója eltér. A rendszermag frissítésekor feltétlenül használjuk a make buildworld és a make buildkernel parancsokat is! A rendszerindítás második fokozatában közvetlenül meg tudjuk adni a betöltendõ rendszermagot, ha a betöltõ indítása elõtt, a | jel megjelenésekor lenyomunk egy billentyût. A telepítés megszakad a rendszer indítása közben, mit lehet ezzel kezdeni? Próbáljuk meg letiltani az ACPI támogatást. Ezt úgy tudjuk megtenni, hogy amikor a rendszertöltõ elindul, lenyomjuk a Szóköz billentyût. Ekkor a következõt kapjuk: OK Itt gépeljük be az alábbi parancsot: unset acpi_load Majd ezt: boot Hardverkompatibilitás Általános kérdések A &os; rendszerükhöz szeretnénk hardvert vásárolni. Melyik gyártmány/márka/típus a legjobb? Ez állandó téma a &os; levelezési listákon. Mivel a hardverek gyorsan változnak, nem is számíthatunk másra. Továbbra is határozottan javasoljuk, hogy olvassuk át figyelmesen a &os; &rel.current; vagy &rel2.current; változatához tartozó hardverjegyzéket (Hardware Notes) és nézzünk után a levelezési listák archívumában mielõtt bármire is rákérdeznéünk a legfrissebb és legjobb hardverek ügyében. Könnyen elõfordulhat, hogy éppen a múlt héten esett szó arról a típusú eszközrõl, amirõl éppen érdeklõdni szeretnénk. Ha laptoppal kapcsolatban lenne kérdésünk, akkor nézzük meg a &a.mobile; archívumát. Minden más esetben érdemes inkább a &a.questions; archívumait megnézni vagy az adott hardverhez tartozó levelezési listát böngészni. Memória A &os; képes 4 GB-nál, 16 GB-nál vagy akár 48 GB-nál több memóriát (RAM-ot) támogatni? Igen. A &os; operációs rendszerként képes az adott platformon kihasználni az összes rendelkezésre álló fizikai memóriát. Ne felejtsük el azonban, hogy az egyes platformokon ennek határa eltér. Például az &i386; platformon a PAE használata nélkül legfeljebb csak 4 GB memóriát tudunk elérni (amely azonban a PCI számára fenntartott címtér miatt a valóságban némileg kevesebb), illetve a PAE használatával legfeljebb 64 GB memóriát. Az AMD64 platformokon viszont már egészen 1 TB memóriáig is elmehetünk. A &os; miért jelez 4 GB-nál kevesebb memóriát &i386; architektúrájú számítógépeken? Az &i386; platformon a címtér 32 bites, ami azt jelenti, hogy itt legfeljebb 4 GB memória címezhetõ meg (és érhetõ el). Ráadásul a címtér bizonyos tartományait a hardvereszközök számára tartják fenn különbözõ célokra, például a PCI eszközök mûködtetésére és vezérlésére, a videomemória hozzáférésére stb. Ennélfogva az operációs rendszer és annak rendszermagja által felhasználható teljes memória mérete jelentõsen kevesebb, mint 4 GB. Ezen a típusú konfigurációkon általában 3,2 GB és 3,7 GB között mozog a maximálisan kihasználható fizikai memória mérete. Ha mégis 3,2  vagy 3,7 GB-nál több memóriát szeretnénk elérni (4 GB-ot vagy akár annál is többet), akkor ahhoz a PAE nevû speciális módosításra lesz szükségünk. A PAE a Physical Address Extension (Fizikai címkiterjesztés) rövidítése, és egy olyan módszerre utal, amellyel a 32 bites x86 típusú processzorokon tudunk 4 GB-nál több memóriát címezni. Lényegében nem csinál mást, csak 4 GB-os határ felé képezi le azokat a memóriaterületeket, amelyeket egyébként a hardverek részére tartanak fenn, ezzel kiegészíti a fizikai memóriát (&man.pae.4;). A PAE használatának számos hátránya van: ebben a módban a megszokottnál (vagyis PAE nélkül) némileg lassabb a memória elérése, illetve ilyenkor a betölthetõ rendszermag-modulok (lásd &man.kld.4;) sem támogatottak. Emiatt az összes meghajtót bele kell fordítanunk a rendszermagba. A PAE használatát általában a PAE nevû, a rendszermaghoz gyárilag mellékelt konfigurációs állománnyal engedélyezhetjük. Ezt eleve úgy állították össze, hogy gond nélkül készíteni tudjuk egy ilyen rendszermagot. Érdemes azonban megemlíteni, hogy a konfigurációs állomány bizonyos tekintetben egy kissé konzervatív, mivel egyes PAE esetén használhatatlannak megjelölt meghajtók valójában mégis minden gond nélkül hozzáadhatóak a konfigurációhoz. Ezzel kapcsolatban azt javasoljuk, hogy ha az adott meghajtó használható valamelyik 64 bites architektúrán (például AMD64-en), akkor nagy valószínûséggel PAE-vel is mûködni fog. Amennyiben saját magunk szeretnénk egy PAE-rendszermagot készíteni, akkor a következõ sort tegyük bele a konfigurációs állományba: options PAE A PAE alkalmazása napjainkban annyira már nem jellemzõ, mivel az újabb x86 hardverek mindegyike képes 64 bites (AMD64 vagy &intel; 64) módban futni. Ebben az esetben már lényegesen nagyobb címtér használatára nyílik lehetõségünk, így nincs szükségünk további trükkökre. A &os; támogatja az AMD64 architektúrát, így ha 4 GB-nál több memóriát szeretnénk elérni, akkor inkább a &os; ezen változatát érdemes alkalmazni. Architektúrák és processzorok A &os; az x86-on kívül támogat más architektúrájú rendszereket is? Igen. A &os; jelenleg az Intel x86 és az AMD64 architektúrákon mûködik. A Az Intel EM64T, IA-64, &arm;, &powerpc;, sun4v és &sparc64; architektúrák is támogatottak. A további tervezett platformok között van még a &mips; és az &s390;, a &mips; aktuális állapotáról és &a.mips; segítségével értesülhetünk. Az újabb architektúrákhoz kapcsolódó általános jellegû megbeszéléseket a &a.platforms; foglalja össze. Amennyiben a számítógépünk architektúrája nem szerepel a jelenleg támogatottak között, és valamilyen gyors megoldásra lenne szükségünk, akkor javasoljuk a NetBSD vagy az OpenBSD használatát. A &os; támogatja a szimmetrikus többprocesszoros (SMP) rendszereket? A &os; általánosságban véve támogatja a többprocesszoros rendszereket, noha egyes esetekben a BIOS vagy az alaplap hibájából fakadóan problémáink adódhatnak. A &a.smp; átolvasása segíthet tisztázni ezeket. A &os; képes kihasználni az Intel processzorai által felkínált HyperThreading (HTT) támogatás elõnyeit. Az options SMP beállítással fordított rendszermagok alapból maguktól felismerik a rendszerünkben található logikai processzorokat. A &os; alapértelmezett ütemezõje ezeket a logikai processzorokat a többivel teljesen egyenrangúnak tekinti, vagyis semmilyen ütemezési kérdés eldöntésénél nem fogja figyelembevenni az egy processzoron belül elhelyezkedõ logikai processzorokat. Ezen naív ütemezési felfogás miatt bizonyos esetekben a rendszerünk teljesítménye nem tökéletesen optimális, ezért adódhatnak olyan helyzetek, amikor a machdep.hlt_logical_cpus sysctl-változó segítségével szükséges lehet a logikai processzorok használatának letiltása. Ezenkívül még a machdep.hlt_logical_cpus sysctl-változón keresztül lehetõségünk van leállítani az üresjáratban mûködõ processzorokat. Ennek részleteirõl bõvebben a &man.smp.4; man oldalon olvashatunk. Merevlemezes, szalagos, CD- és DVD-meghajtók A &os; milyen típusú merevlemezes meghajtókat ismer? A &os; ismeri az EIDE-, SATA-, SCSI- és SAS-meghajtókat (és a velük kompatibilis vezérlõket, errõl bõvebben lásd a következõ szakaszt), valamint az összes olyan meghajtót, amely az eredeti Western Digital (MFM, RLL, ESDI és természetesen az IDE) interfészt használja. Néhány egyedi fejlesztésû ESDI vezérlõ nem fog mûködni, ezért lehetõleg maradjunk a WD1002/3/6/7 interfészeknél és azok másolatainál. Milyen SCSI- vagy SAS-vezérlõket ismer? A teljes listát a &os; hardverjegyzékében találhatjuk meg a &rel.current; vagy &rel2.current; kiadásban. Milyen szalagos meghajtókat ismer? A &os; a SCSI és QIC-36 (QIC-02 interfésszel) szabványokat ismeri. Ezek közé értendõek a 8 mm-es (más néven Exabyte) és DAT-meghajtók is. Bizonyos régebbi 8 mm-es meghajtók nem egészen kompatibilisek a SCSI-2 szabvánnyal, ezért a &os;-vel sem feltétlenül képesek együttmûködni. A &os; támogatja a szalagok cseréjét? A &os; &man.ch.4; eszközön és a &man.chio.1; parancson keresztül támogatja a SCSI szabványú szalagcserélõket. A használat pontos részleteirõl a &man.chio.1; man oldalán olvashatunk részletesebben. Ha nem az AMANDA vagy a hozzá hasonló programokat használjuk, amelyek alapból ismerik a szalagcserélés lehetõségét, akkor ne feledkezzünk meg arról, hogy a szalagot csak az egyik helyrõl a másikra tudjuk mozgatni, ezért nekünk kell figyelnünk arra, hogy melyik rekeszben vannak szalagok és a meghajtónak ezek közül melyiket kell használnia. A &os; milyen CD-meghajtókat ismer? Bármilyen támogatott SCSI-vezérlõhöz csatlakoztatható SCSI-meghajtót ismer. Ezenkívül még az alábbi CD-interfészek ismertek: Mitsumi LU002 (8 bites), LU005 (16 bites) és FX001D (16 bites, dupla sebességû). Sony CDU 31/33A Sound Blaster nem-SCSI CD-meghajtók Matsushita/Panasonic CD-meghajtók ATAPI kompatibilis IDE CD-meghajtók Az összes ismert nem-SCSI kártya nagyon lassan mûködik a SCSI-meghajtókhoz képest, és bizonyos ATAPI CD-meghajtók nem használhatóak. A Daemon News-tól és a &os; Mall-tól rendelhetõ hivatalos &os; CD-krõl akár közvetlenül el is tudjuk indítani a rendszert. A &os; milyen CD-RW meghajtókat ismer? A &os; bármilyen ATAPI-kompatibilis IDE CD-R vagy CD-RW meghajtót ismer. Ennek részleteit lásd a &man.burncd.8; man oldalán. A &os; ezeken kívül még tetszõleges SCSI CD-R vagy CD-RW meghajtót támogat. A használatukhoz telepítsük a cdrecord programot a portok vagy csomagok közül, és gondoskodjunk róla, hogy a pass eszköz támogatása benne legyen a rendszermagban. A &os; ismeri az &iomegazip; meghajtókat? A &os; alapból ismeri a SCSI és ATAPI (IDE) interfészen kommunikáló &iomegazip; meghajtókat. A SCSI ZIP-meghajtók ugyan egyedül az 5 és 6 target ID-krõl hajlandóak mûködni, de ha a SCSI-kártyánk BIOS-a támogatja, akkor még a rendszert is el tudjuk indítani róluk. Egyelõre nem tisztázott, hogy milyen kártyák képesek a 0 és 1 ID-ken kívül máshonnan is rendszert indítani, ezért ennek a hozzátartozó dokumentációben érdemes utánajárnunk. A &os; ezenkívül még a párhuzamos porton csatlakoztatható ZIP-meghajtókat is ismeri. Ehhez ellenõrizzük, hogy a rendszermagunkban megtalálhatóak az scbus0, da0, ppbus0 és vp0 meghajtók (a GENERIC rendszermagban a vp0 kivételével mindegyik szerepel). Segítségükkel a párhuzamos vonalon csatlakozó meghajtó a da0s4 eszközön keresztül érhetõ el. Ennek megfelelõen az állományrendszerek a mount /dev/da0s4 /mnt vagy (DOS esetén) a mount -t msdosfs /dev/da0s4 /mnt parancs kiadásával csatlakoztathatóak. Emellett még érdemes a GYIK cserélhetõ lemezes meghajtókról szóló részét is elolvasnunk ebben a fejezetben, valamint a formázásról szóló megjegyzést az adminisztrációról szóló fejezetben. A &os; ismeri a &jaz;, EZ és a többi cserélhetõ lemezes meghajtót? Használhatóak. Ezek többsége SCSI eszköz, ezért a &os; SCSI-lemezként látja, az IDE csatolós EZ pedig IDE-meghajtóként érhetõ el. A rendszer indítása elõtt ne felejtsük el bekapcsolni a külsõ egységeket. Ha tárolóeszközt akarunk cserélni a rendszer mûködése közben, olvassuk el a &man.mount.8;, &man.umount.8; és (SCSI eszközök esetén) a &man.camcontrol.8; vagy (IDE eszközök esetén) a &man.atacontrol.8; man oldalakat, valamint a GYIK egy késõbbi részében található részt a cserélhetõ lemezes meghajtókról. Egér és billentyûzet A &os; ismeri az USB billentyûzeket? A &os; alapból ismeri az USB billentyûzeket. Miután engedélyeztük rendszerünkben az USB billentyûzet támogatását, az AT billentyûzet /dev/kbd0 lesz és az USB billentyûzet pedig /dev/kbd1, már amennyiben mind a kettõt csatlakoztattuk a számítógépünkhöz. Ha viszont csak USB billentyûzetünk van, akkor az a /dev/ukbd0 lesz. Ha az USB billentyûzetet konzolban akarjuk használni, akkor erre figyelmeztetnünk kell a konzolos meghajtót. Ezt úgy tudjuk megtenni, ha a következõ parancsot lefuttatjuk a rendszer indítása közben: &prompt.root; kbdcontrol -k /dev/kbd1 < /dev/console > /dev/null Amikor viszont csak USB billentyûzetünk van, akkor az /dev/ukbd0 eszközön keresztül tudjuk elérni, ezért a parancsnak ilyenkor így kell kinéznie: &prompt.root; kbdcontrol -k /dev/ukbd0 < /dev/console > /dev/null Ha véglegesíteni akarjuk ezt a beállítást, akkor tegyük a keyboard="/dev/ukbd0" sort az /etc/rc.conf állományba. Miután ezt megcsináltuk, az USB billentyûzet X alatt is mûködni fog minden további beállítás nélkül. Ezzel a paranccsal tudunk visszaváltani az alapértelmezett billentyûzetre: &prompt.root; kbdcontrol -k /dev/kbd0 > /dev/null A &man.kbdmux.4; meghajtón keresztül az alábbi parancsok kiadásával engedélyezhetjük az elsõdleges AT billentyûzet és a másodlagos USB billentyûzet párhuzamos használatát a konzolon: &prompt.root; kbdcontrol -K < /dev/console > /dev/null &prompt.root; kbdcontrol -a atkbd0 < /dev/kbdmux0 > /dev/null &prompt.root; kbdcontrol -a ukbd1 < /dev/kbdmux0 > /dev/null &prompt.root; kbdcontrol -k /dev/kbdmux0 < /dev/console > /dev/null Részletesebb információkat az &man.ukbd.4;, &man.kbdcontrol.1; és &man.kbdmux.4; man oldalakon találhatunk. Az USB billentyûzet menet közbeni csatlakoztatása és leválasztása nem feltétlenül fog mûködni. Ezért a problémák elkerülése érdekében azt javasoljuk, hogy a rendszer indítása elõtt mindenképpen csatlakoztassuk a billentyûzetet és hagyjuk egészen úgy, amíg le nem állítottuk. A nem szabványos buszos egereket hogyan lehet beállítani? A &os; ismeri a buszos, illetve a Microsoft, Logitech és az ATI által gyártott InPort buszos egereket. A GENERIC rendszermag azonban ehhez nem tartalmaz meghajtót. A rendszermag konfigurációs állományába a következõ sort kell megadni, ha egy buszos egereket támogató rendszermagot akarunk készíteni: device mse0 at isa? port 0x23c irq5 A buszos egerekhez általában saját interfészkártya is tartozik. Ezeket a kártyákat a fentitõl eltérõ portcímre és IRQ megszakításra is beállíthatjuk. Részletesebb információkat az egerünk man oldalán és a &man.mse.4; man oldalon olvashatunk. Hogyan lehet PS/2 (egérportos vagy billentyûzetes) egeret használni? Az PS/2 egereket alapból támogatjuk. Az ehhez szükséges psm meghajtó megtalálható a rendszermagban. Ha a saját magunk által összeállított rendszermagunk nem tartalmazza ezt a meghajtót, akkor a következõ sort kell felvennünk a konfigurációs állományba: device psm0 at atkbdc? irq 12 Miután a rendszermag a rendszer indítása során helyesen észlelte a psm0 eszközt, magától létrejön. Az egeret az X Window Systemen kívül is lehet valamilyen módon használni? Ha az alapértelmezett konzolos &man.syscons.4; meghajtót használjuk, akkor a szöveges felületû konzolokon az egérmutató segítségével tudunk szövegrészeket kijelölni és másolni. Ehhez nem kell mást tennünk, csupán elindítani a &man.moused.8; egérdémont és engedélyezni az egérmutatót a virtuális konzolokon: &prompt.root; moused -p /dev/xxxx -t yyyy &prompt.root; vidcontrol -m on Itt az xxxx az egeret leképezõ eszköz neve és az yyyy az egérhez használt protokoll típusa. Az egérdémon a legtöbb egér esetén képes magától megállapítani az alkalmazott protokoll típusát, kivéve a régebbi soros egereket. Az auto érték megadásával tudjuk aktiválni ezt az automatikus felderítést. Amennyiben ez nem mûködik, a &man.moused.8; man oldalán nézhetünk után a támogatott protokolloknak. Ha PS/2 egerünk van, akkor egyszerûen csak vegyük fel a moused_enable="YES" sor az /etc/rc.conf állományba, és az egérdémon elindul a rendszer indítása közben. Valamint hogy ha az egérdémont a konzol helyett az összes virtuális konzolon is használni akarjuk, akkor az /etc/rc.conf állományba tegyük bele a allscreens_flags="-m on" sort. Miután az egérdémon elindult, valamilyen módon koordinálni kell az egér hozzáférését az egérdémon és az összes többi program, például az X Window System között. Errõl a problémáról a GYIK Miért nem mûködik X alatt az egér? kérdésében olvashatunk részletesebb. Hogyan lehet szöveget kijelölni és másolni a szöveges konzolban? Ahogy sikerült elindítanunk az egérdémont (lásd az elõzõ szakaszt), tartsuk lenyomva az egér elsõ (bal oldali) gombját és az egér mozgatásával jelöljük ki a szöveget. Ezután nyomjuk le a második (középsõ) gombját, amivel a kurzor mellett megjelenik az imént kijelölt szöveg. A harmadik (jobb oldali) gomb segítségével a szöveg kijelölését tudjuk kiterjeszteni. Amennyiben az egerünkön nem található középsõ gomb, az egérdémon beállításainak segítségével megpróbálkozhatunk emulálni vagy áthelyezni a vele kapcsolatos funkciókat egy másik gombra. A &man.moused.8; man oldalán olvashatunk errõl részletesebben. Az egéren van mindenféle görgõ és gomb. Ki lehet ezeket valahogy használni &os; alatt is? A válaszunk erre sajnos csupán annyi, hogy Attól függ. A különbözõ kiegészítõkkel rendelkezõ egerekhez általában egy külön meghajtó szükségeltetik. Hacsak az egér meghajtóprogramja vagy a hozzátartozó felhasználói program nem nyújt valamilyen támogatást, az eszköz egyszerûen csak egy szabványos két- vagy háromgombos egérként fog funkcionálni. Ha az X Window környezetben akarunk görgõket használni, esetleg ezt a szakaszt érdemes elolvasnunk. A laptopokon megtalálható egér/trackball/touchpad hogyan használható? Olvassuk el az elõzõ kérdésre adott választ. A Delete billentyû hogyan használható a sh és csh parancsértelmezõkben? A Bourne Shell esetében az alábbi sorokat kell megadnunk az .shrc állományunkban. Lásd &man.sh.1; és &man.editrc.5;. bind ^? ed-delete-next-char # a konzolhoz bind ^[[3~ ed-delete-next-char # az xtermhez A C Shell esetében a következõ soroknak kell az .cshrc állományba kerülnie. Lásd &man.csh.1;. bindkey ^? delete-char # a konzolhoz bindkey ^[[3~ delete-char # az xtermhez További információkat ezen az oldalon találhatunk. Hálózati és soros eszközök A &os; milyen hálózati kártyákat ismer? Ezek teljes listáját a &os; egyes kiadásaihoz tartozó hardverjegyzékben találjuk meg. A &os; ismer szoftveres modemeket, például winmodemeket? A &os; különbözõ kiegészítõ szoftvereken keresztül több szoftveres modemet is támogat. A comms/ltmdm port például a szélesebb körben elterjedt Lucent LT chipsetes modemekhez ad támogatást. A &os; azonban nem telepíthetõ szoftveres modemen keresztül. A hozzátartozó szoftvert csak az operációs rendszer telepítése után tudjuk telepíteni. Van natív meghajtó a Broadcom 43xx típusú kártyákhoz? Nem, és valószínûleg nem is lesz. A Broadcom nem hajlandó nyilvánossá tenni azokat az információkat, amik az általuk gyártott vezeték nélküli chipsetek programozásához lennének szükségesek, mivel szoftveresen vezérelt rádiót használnak. Az alkatrészeik FCC szintû engedélyeztetéséhez ugyanis valamilyen módon gondoskodniuk kell róla, hogy a felhasználók nem képesek bizonyos dolgokat módosítani vele kapcsolatban, például a mûködési frekvenciát, a modulációs paramétereket vagy a kimenõ teljesítményt. A chipsetek programozásának ismerete nélkül azonban szinte lehetetlen elkészíteni hozzájuk a megfelelõ meghajtót. A &os; milyen többportos soros vonali kártyákat ismer? Ezek listáját a kézikönyv Soros vonali kommunikációról szóló része tartalmazza. Bizonyos névtelen másolatok is használhatók, különösen azok, amelyek magukat AST-kompatibilisnek nevezik. Az ilyen kártyák beállításáról a &man.sio.4; man oldalon olvashatunk részletesebben. Hogyan lehet a boot: parancssort elõhozni soros vonali konzolon? Olvassuk el a kézikönyvben ezt a fejezetet. Hang A &os; milyen hangkártyákat ismer? A &os; rengeteg hangkártyát ismer, (ennek részleteit lásd a &os; kiadásait tartalmazó honlapon és a &man.snd.4; man oldalon). Korlátozott módon az MPU-401 és a vele kompatibilis MIDI-kártyákat is támogatja. A µsoft; Sound System specifikációinak megfelelõ kártyákat tudjuk használni. Ez azonban csak a hangra vonatkozik! Ez a meghajtó a &soundblaster; kivételével nem támogatja a kártyákon található CD-, SCSI- és joystick csatlakozásokat. A &soundblaster; SCSI csatlakozása és bizonyos nem-SCSI CD-meghajtókat ugyan támogat, de rendszert például nem tudunk róluk indítani. Miért nincs hang a &man.pcm.4; által támogatott hangkártyán? Egyes hangkártyák esetében a hangerõ minden indításkor nullára állítódik. Ezért ilyenkor mindig ki kell adni a következõ parancsot: &prompt.root; mixer pcm 100 vol 100 cd 100 Egyéb eszközök Képes a &os; kihasználni az energiagazdálkodási lehetõségeket egy laptopon? A &os; bizonyos gépeken képes az APM használatára. Errõl az &man.apm.4; man oldalon találunk pontosabb leírást. A &os; ezenkívül még a legújabb hardverekben megtalálható ACPI lehetõségeit is igyekezik kihasználni. Errõl részletesebben az &man.acpi.4; man oldalon olvashatunk. Amennyiben a rendszerünk egyaránt tartalmazza az APM és az ACPI támogatását, bármelyiket használhatjuk. Ilyen esetben javasoljuk mind a kettõ kipróbálását és az igényeinkhez leginkább illeszkedõ megoldás kiválasztását. Hogy lehet letiltani az ACPI támogatását? Tegyük bele az alábbi sort az /boot/device.hints állományba: hint.acpi.0.disabled="1" Miért fagynak le a Micron típusú rendszerek indulás közben? Egyes Micron gyártmányú alaplapokon olyan PCI BIOS található, amely nem felel meg az szabványoknak, és ezért a &os; nem tud elindulni, mivel a PCI eszközök nem jelentik le az általuk használt címeket. Ezt a problémát úgy tudjuk megoldani, ha a BIOS-ban kikapcsoljuk (Disabled értékûre állítjuk) a Plug and Play Operating System beállítást. A rendszerindító lemez nem képes az ASUS K7V alaplapokkal mûködni. Hogyan lehet ezt orvosolni? Menjünk be a BIOS-ba és kapcsoljuk ki (állítsuk Disabled értékre) a Boot Virus Protection beállítást. Miért nem mûködnek a &tm.3com; PCI hálózati kártyák a Micron típusú számítógépekben? Nézzük meg az elõzõ választ. Hibaelhárítás Miért állapítja meg rosszul a &os; a memória mennyiségét &i386; hardveren? A válasz nagy valószínûséggel a fizikai és virtuális memóriacímek közti különbségben rejlik. A legtöbb PC-s hardvereszköz megegyezés szerint a 3,5 GB és 4 GB közti memóriaterületet speciális célokra tartja fenn (általában a PCI számára). Ezen a címterületen keresztül éri a PCI eszközöket. Ennek egyik következménye, hogy a fizikai memória ezen a részen nem érhetõ el. Hogy pontosan mi történik az itt elhelyezkedõ memóriával, teljesen a hardvertõl függ. Sajnálatos módon bizonyos eszközök semmilyen megoldást nem nyújtanak a problémára, és így lényegében az utolsó 500 MB-nyi memória elveszik. Szerencsére a legtöbb eszköz azonban képes ezt a területet egy felsõbb címre leképezni, így ki tudjuk használni. Ilyenkor azonban tapasztalhatunk némi félreértést, amikor megnézzük a rendszerindítás közben megjelenõ üzeneteket. A &os; 32 bites változata esetén ez a memóriaterület elveszik, mivel a címe a 4 GB-os határ felé kerül, amelyet a 32 bites módban futó rendszermag már nem képes elérni. Ezen egy PAE támogatással rendelkezõ rendszermag használatával segíthetünk. A GYIK-on belül ebben a bejegyzésben olvashatunk bõvebben a memóriakorlátokról, valamint ebben a részben láthatjuk a különbözõ platformokra vonatkozó memóriakorlátozásokat. A &os; 64 bites változata vagy a PAE használata esetén azonban a &os; rendesen felismeri és leképezi a fennmaradó memóriaterületeket, így azok használhatóvá válnak. A rendszerindítás során azonban az elõbb említett leképezés miatt látszólag úgy fog tûnni, mintha a &os; több memóriát észlelne, mint amennyivel valójában rendelkezünk. Ez teljesen normálisnak tekinthetõ és a ténylegesen elérhetõ memória mennyisége a folyamat végén be fog állítódni. Mit tegyünk, ha meghibásodott szektorokat találunk a merevlemezünkön? A SCSI-meghajtók esetében a meghajtó általában képes önmagától átképezni az ilyen szektorokat. A legtöbb meghajtóban ez a lehetõség viszont alapból nem engedélyezett. A hibás szektorok átképezéséhez az eszköz elsõ lapmódját kell átírnunk, amelyet (root felhasználóként) így tehetünk meg: &prompt.root; camcontrol modepage sd0 -m 1 -e -P 3 Változtassuk meg az AWRE (az írás automatikus átképzése) és ARRE (az olvasás automatikus átképzése) beállítások értékeit 0-ról 1-re: AWRE (Auto Write Reallocation Enbld): 1 ARRE (Auto Read Reallocation Enbld): 1 A modernebb IDE-meghajtók is képesek a vezérlõjükkel nyilvántartani az idõközben meghibásodott szektorokat, és ezt általában alapból engdélyezik. Ha rossz szektorokra figyelmeztetõ hibaüzeneteket látunk (akármilyen típusú meghajtónk is legyen), az kétségtelenül arra utal, hogy ideje lecserélnünk a hardvert. A hibás szektorok használatát esetleg a gyártó saját diagnosztikai programjával le tudjuk tiltani, de hosszabb távon mindenképpen az lesz a legjobb, ha veszünk egy újat. A &os; miért nem találja meg a HP Netserver SCSI-vezérlõjét? Ez tulajdonképpen egy ismert probléma. A HP Netserver gépekben egy integrált EISA buszos SCSI-vezérlõ található, amely a 11-es EISA bõvítõhelyen található, ezért az összes valódi EISA bõvítõhely ez elõtt helyezkedik el. Sajnos a 10 feletti EISA bõvítõhelyek címei ütköznek a PCI eszközök számára kiosztott címekkel, ezért a &os; önmagától nem tudja valami jól kezelni az ilyen helyzeteket. Ezért a legjobban akkor járunk, ha egyszerûen letagadjuk a címterek ütközését :) Ezt úgy tudjuk megtenni, ha a rendszermag EISA_SLOTS nevû beállítását a 12 értékre állítjuk. Ezután már csak be kell konfigurálunk és újra kell fordítanunk a rendszermagot, ahogy azt a kézikönyv megfelelõ része is tárgyalja. Természetesen, amikor egy ilyen gépre akarunk telepíteni, a helyzet tovább bonyolódik. A telepítést úgy tudjuk megoldani, ha a UserConfig programon belül alkalmazunk egy apró trükköt. Most ne a vizuális felületét használjuk, hanem a parancssoros részt. Gépeljük be, majd a megszokottak szerint telepítsük a rendszert: eisa 12 quit Ettõl függetlenül természetesen továbbra is javasolt egy, az elõbbiek szerint módosított rendszermagot fordítanunk és telepítenünk. A következõ verziókban remélhetõleg már lesz valamilyen megoldás erre a problémára. A HP Netserver esetén nem tudunk a lemezeken Veszélyesen dedikált (Dangerously Dedicated) módot használni. Errõl itt olvashatunk bõvebben. Állandóan ed1: timeout és ahhoz hasonló üzenetek jelennek meg. Mi lehet velük kezdeni? Ezt a hibát általában a megszakítások ütközése okozza (például két kártya ugyanazt a megszakítást akarja használni). Indítsuk a rendszerünket a beállítás használatával és az ed0/de0/... bejegyzéseket változtassuk meg a kártyáknak megfelelõen. Ha a hálózati kártyánkon BNC típusú csatlakozó található, akkor még elõfordulhat, hogy azért látunk ilyen hibaüzeneteket, mert nem jól zártuk le a csatlakozást. Ezt úgy tudjuk könnyen ellenõrizni, ha a lezárót közvetlenül a kártyára dugjuk rá (kábel nélkül) és figyeljük, hogy továbbra is jönnek-e a hibaüzenetek. Egyes NE2000-kompatibilis kártyák akkor adják ezt a hibát, ha az UTP portjukon nincs aktív összeköttetés vagy nem dugtuk be a kábelt. Miért állnak le a &tm.3com; 3C509 kártyák minden különösebb ok nélkül? Az ilyen típusú kártyák néha hajlamosak elfelejteni a beállításaikat. Frissítsük a kártya beállításait a 3c5x9.exe program segítségével. A párhuzamos nyomtató nevetségesen lassú. Mi lehet ezzel kezdeni? Ha csupán annyi a problémánk, hogy a nyomtató irdatlanul lassan mûködik, akkor próbáljuk meg a kézikönyv nyomtatásról szóló részében leírtakhoz hasonlóan átállítani a nyomtató portkezelését. A programok miért állnak le idõnként Signal 11 hibákkal? Ezek a hibák akkor keletkeznek, amikor a futó programok olyan memóriaterülethez próbálnak meg hozzáférni, amihez eredetileg nem lenne szabad. Ha valami ehhez hasonló történik a rendszerünkben látszólag teljesen véletlenszerûen, akkor nagyon óvatosan kezdjünk el vizsgálódni. A lehetséges okok az alábbiak lehetnek: Ha csak olyan alkalmazások esetében jelentkezik ez a hiba, amelyeket mi magunk fejlesztünk, akkor az valószínûleg arra utal, hogy valamelyik része hibásan mûködik. Ha a &os; alaprendszerének valamelyik részében tapasztalunk ilyen hibákat, akkor azt szintén okozhatja hibás kód, de az ilyen hibákat általában hamarabb meg szokták találni és ki szokták javítani, mint ahogy a GYIK-ot olvasók többsége találkozna velük (a -CURRENT ág pontosan ezt a célt szolgálja). Elõfordulhat, hogy ez egy olyan furcsaság eredménye, amely nem a &os; hibája: például ugyanazon program fordításakor mindig mást csinál a fordítóprogram. Például tegyük fel, hogy a make buildworld parancsot futtatjuk, és a fordítás félbeszakad, amikor az ls.c állományból el akarja készíteni az ls.o állományt. Ha ezután megint megpróbáljuk kiadni a make buildworld parancsot, akkor a fordítás ugyanazon a helyen újból meghiúsul — valószínûleg hibás a forráskód, frissítsük a forrásainkat és próbáljuk meg ismét. Ha viszont a fordítás ilyenkor már egy másik helyen akad el, akkor szinte biztos, hogy hardverhibával akadtunk össze. Amit ilyenkor tenni tudunk: Az elsõ esetben egy nyomkövetõ, például a &man.gdb.1; segítségével keressük meg a program azon pontját, ahol rossz memóriaterülethez próbál meg hozzáférni és javítsuk ki. A második esetben ellenõrizzük, hogy nem a hardver a hibás. Ennek okai többek közt a következõk lehetnek: Túlmelegednek a merevlemezeink: ellenõrizzük, hogy a gépben található ventillátorok rendesen mûködnek-e (persze elõfordulhat, hogy más eszközök melegednek túl). A processzor túlmelegedett: lehet, hogy mert túlságosan nagy órajelen járatjuk, vagy mert egyszerûen leállt a hûtése. Akármelyik eset is következett be, legalább a hiba felderítéséig állítsuk vissza a hivatalos sebességére. Ha feltétlenül ragaszkodunk a rendszerünk tuningolásához, akkor érdemes elgondolkoznunk azon, hogy egy lassabb rendszerrel jobban járunk, mint egy állandóan cserélendõ, ropogósra sült rendszerrel. Az emberek általában nem is nagyon szeretik az ilyen rendszereket, független attól, hogy szerintünk érdemes-e ilyet csinálni vagy sem. Hibás memóriamodulok: ha több SIMM és DIMM modul is található a gépünkben, akkor vegyük ki az összeset és próbáljuk ki mindegyiket egyesével, ezzel is leszûkíthetjük a probléma felderítését a hibás DIMM/SIMM modulokra vagy azok kombinációjára. Az alaplap túlbecslõ értékei: a BIOS beállításai között vagy az alaplapon található jumperekkel szabályozni tudjuk a különbözõ idõzítéseket, ahol általában az alapértelmezett értékek megfelelnek, de néha elõfordulhat, hogy a memóriamodulok késleltetését lassúra, vagy éppen turbó sebességre állítják (RAM Speed: Turbo vagy ehhez hasonló néven keressük a BIOS-ban), ami szintén okozhat furcsa viselkedést. Próbáljuk meg visszaállítani az BIOS alapértelmezett értékeit, de elõtte érdemes lejegyezni az aktuális beállításainkat. Az alaplap zajos vagy kevés áramot kap: ha vannak használaton kívüli I/O kártyáink, merevlemezeink, CD-meghajtóink a rendszerünkben, akkor próbáljuk meg ideiglenesen eltávolítani ezeket vagy egyszerûen csak lehúzni róluk a tápkábelt. Ezzel tudjuk vizsgálni, hogy a számítógépünk tápegysége képes-e megbirkózni a kisebb terheléssel. Esetleg kipróbálhatunk egy másik tápegységet is, lehetõleg egy kicsivel erõsebbet (például ha a jelenlegi tápegységünk teljesítménye 250 watt, akkor használjunk helyette egy 300 wattosat). Továbbá érdemes lehet még elolvasnunk a SIG11 GYIK-ot (lásd lentebb), ahol mindezeket a problémákat részletesen kifejtik, noha a &linux; nézõpontjából. Arról is olvashatunk benne, hogy egy hibás memóriát miért nem képesek észlelni a szoftveres vagy hardveres tesztelõeszközök. Végezetül, ha az egyik javaslat sem segített a probléma megoldásában, akkor valószínûleg sikerült hibát találnunk a &os; kódjában, amirõl nyugodtan írhatunk a fejlesztõknek egy hibajelentést. A problémáról minden részletre kiterjedõ módon A SIG11-es probléma GYIK-ja írásban olvashatunk (angolul). A rendszer összeomlik vagy egy Fatal trap 12: page fault in kernel mode vagy pedig valamilyen panic: hibaüzenettel és egy halom számot ír ki. Mit tegyünk? A &os; fejlesztõi nagyon kíváncsiak az ilyen hibákra, de a felderítéséhez sajnos jóval több információra van szükségük, mint amennyit láthattunk. Másoljuk le az összeomláshoz tartozó teljes üzenetet. Ezután nézzük meg a GYIK-nak azt a részét, amely a rendszermag összeomlásáról szól, készítsünk egy nyomkövetési információkkal ellátott rendszermagot és kérjük le a hívási láncot. Ez elsõre talán bonyolultnak hangzik, de ehhez igazából nem igényel semmilyen programozási tudást, egyszerûen csak a megadott utasításokat kell követnünk. A rendszer indulása közben miért sötétül a képernyõ és megy el rajta a kép? Ez az ATI Mach 64 videokártyák esetében jelentkezõ probléma. Ilyenkor az a gond, hogy a kártya a 0x2e8 címet használja, akárcsak a negyedik soros port. A &man.sio.4; meghajtóban levõ hiba (vagy netalán beállítás?) miatt azonban a negyedik soros portot még akkor is használni fogja, ha kikapcsoljuk a sio3 (a negyedik soros port) eszközt. A hibát kijavításáig így kerülhetjük meg: A betöltõ parancssorában adjuk meg a paramétert. (Így elõ tudjuk hozni a rendszermag konfigurációs módját.) Kapcsoljuk ki a sio0, sio1, sio2 és sio3 eszközöket (tehát mindegyiket). Emiatt a &man.sio.4; meghajtó nem indul el, és így nem okoz problémát. Lépjünk ki és folytassuk a rendszer indítását. Ha a soros portokat is használni akarjuk, akkor következõ módosításokkal készítsünk egy új rendszermagot: a /usr/src/sys/dev/sio/sio.c (vagy pc98 esetén a /usr/src/sys/pc98/cbus/sio.c) állományban keressük meg a 0x2e8 karakterláncot és az azt megelõzõ vesszõt távolítsuk el (de az utána következõt tartsuk meg). Miután végrehajtottuk ezt a módosítást, a megszokott módon fordítsuk újra a rendszermagot. A &os; miért csak 64 MB memóriát használ, amikor 128 MB van a gépben? Mivel &os; a BIOS-tól próbálja megtudni a rendelkezésre álló memória méretét, ezért csak 16 biten képes lekérdezni a KB-okban (vagyis 65 535 KByte = 64 MB, vagy még ennél is kevesebb, mivel egyes BIOS-ok legfeljebb 16 MB memóriát engednek látni). Tehát ha 64 MB-nál több memóriával rendelkezünk, akkor a &os; ugyan megpróbálja azt felderíteni, de nem feltétlenül fog sikerülni. Ezt úgy tudjuk megoldani, ha a rendszermag alábbi beállítását használjuk. Alapvetõen ugyanis létezik egy módszer, amivel le lehet kérdezni a memória teljes méretét a BIOS-tól, de a hozzátartozó rutin nem fért el a rendszerindító blokkban. Ha egyszer majd sikerül neki helyet csinálni, akkor a rendszer képes lesz kizárólag ezzel a módszerrel dolgozni. Amíg viszont ez nem így van, addig kénytelenek leszünk a most következõ megoldást választani: options MAXMEM=N ahol N a memória Kilobyte-okban megadott mérete. Tehát egy 128 MB memóriával rendelkezõ számítógép esetén ez 131072. A számítógépben több mint 1 GB memória van, de mégis kmem_map too small üzenetek jelennek meg. Mi a gond? A &os; általában a rendszermag néhány fontos paraméterét, mint például az egyszerre megnyitható állományok maximális számát a számítógépben található memória méretébõl származtatja. Az 1 GB memóriánál több esetén azonban elképzelhetõ, hogy ez az automatikus méretezés túlságosan is nagy értékeket választ. Így a rendszer indításakor a rendszermag olyan nagy méretû táblázatokat és egyéb struktúrákat foglal le, amelyek betöltik a rendelkezésére bocsátott terület nagy részét. Késõbb, a rendszer futása közben pedig a rendszermag szépen lassan kifogy a dinamikus memóriaterületekbõl és összeomlik. Készítsünk egy olyan saját rendszermagot, ahol a beállítást megnöveljük egészen a maximális 400 MB-os értékig (). 400 MB használata valószínûleg elég lesz egészen 6 GB memóriáig. A számítógépben nincs 1 GB memória, a &os; mégis kmem_map too small hibával leáll! Ez a hibaüzenet arra utal, hogy a rendszer kifogyott a hálózati pufferek (különösen az mbuf klaszterek) számára kiosztott virtuális memóriából. Az mbuf klaszterek részére fenntartott virtuális memória méretének beállításáról a kézikönyv Hálózati korlátozások címû szakaszában olvashatunk. Miért jelenik meg a kernel: proc: table is full hibaüzenet? A &os; rendszermagja egyszerre csak bizonyos számú programot enged futni. Ezek konkrét száma a kern.maxusers &man.sysctl.8;-változótól függ. A kern.maxusers ezenkívül még hatással van más belsõ korlátokra is, például a hálózati pufferekre (lásd ezt a korábbi kérdést). Ha a számítógépünk túlságosan leterhelt, akkor érdemes megpróbálkoznunk a kern.maxusers értékének növelésével. Ennek átállítása a rendszerben egyszerre futtatható maximális programok számával együtt sok más rendszerszintû korlátozást is finomít. A kern.maxusers értékének beállításához nézzük meg a kézikönyv Az állományok és futó programok korlátozásairól szóló szakaszát. (Miközben ez a rész a megnyitható állományok maximális számáról szól, addig ugyanez érvényes a futó programokra is.) Ha viszont a számítógépünk nem éri akkora terhelés, de mégis szeretnénk egyszerre nagyobb számú programot is futtatni rajta, akkor ehhez elegendõ csak kern.maxproc változót átállítanunk. Ezt úgy tudjuk megtenni, ha felvesszük a /boot/loader.conf állományba. Ez az érték természetesen addig nem beállítódni, amíg a rendszerünket újra nem indítjuk. Ezekrõl a változókról a &man.loader.conf.5; és &man.sysctl.conf.5; man oldalakon tájékozódhatunk részletesebben. Ha az összes programot egyetlen felhasználóval akarjuk futtatni, akkor a kern.maxprocperuid változót értékét is át kell állítanunk, méghozzá a kern.maxproc új értékénél eggyel kisebbre. (Ezért kell így csinálni, mert egy rendszerprogram, az &man.init.8; mindig fut.) A sysctl változók beállításait úgy is tudjuk véglegesíteni, ha felvesszük ezeket az /etc/sysctl.conf állományba. A kézikönyv A rendszermag korlátainak finomhangolása címû szakaszában részletesebb is olvashatunk róla, hogy miként állítsuk be a rendszerünket. Az új rendszermag indításakor miért keletkezik CMAP busy hibaüzenet? Az elavult /var/db/kvm_*.db állományokat összegyûjtõ rutin idõnként nem mûködik megfelelõen, és a nem egyezõ állományok esetén össze is omolhat. Amikor ilyen történik, indítsuk újra a rendszert egyfelhasználós módban és gépeljük be: &prompt.root; rm /var/db/kvm_*.db Mit jelent az ahc0: brkadrint, Illegal Host Access at seqaddr 0x0 üzenet? Ez az Ultrastor SCSI vezérlõkártya ütközésére utal. A rendszerindítás közben lépjünk be a rendszermag konfigurációs menüjébe és tiltsuk le a gondot okozó uha0 eszközt. Amikor elindul a rendszer, egy ahc0: illegal cable configuration hibaüzenet jelenik meg. A kábelek bekötésével semmilyen gond nincs. Mégis akkor mi a baj? Az alaplapon nem található olyan áramkör, amely támogatja az automatikus lezárást (automatic termination). A SCSI BIOS-ban az automatikus lezárás helyett adjuk meg a megfelelõ lezárást. Az &man.ahc.4; meghajtója nem képes rendesen érzékelni a kábeleket, ha az alaplapon van ilyen érzékelés (és így automatikus lezárás). A meghajtó egyszerûen annyit feltételez, hogy ennek támogatása csak akkor érhetõ el, ha az EEPROM-ban megadtuk az automatic termination beállítást. A megfelelõ kábeldetektáló eszköz nélkül a meghajtó gyakran rosszul állapítja meg a lezárást, ami pedig így veszélyezteti a SCSI busz megbízhatóságát. Miért küld a sendmail mail loops back to myself hibaüzenetet? Errõl részletesebben a kézikönyvben olvashatunk. A távoli gépeken miért viselkednek olyan furcsán a teljes képernyõs alkalmazások? Elõfordulhat, hogy az adott távoli gépen a terminál típusa nem cons25, amire viszont a &os; konzolnak a megfelelõ mûködéshez szüksége lenne. Ezt a problémát többféle módon is meg tudjuk kerülni: Mikor bejelentkezünk a távoli gépre, állítsuk a TERM környezeti változót az ansi vagy sco értékre, amibõl kiderül, hogy egyáltalán ismeri ezeket a termináltípusokat. A &os; konzolban használjunk VT100 emulátort, például a screen alkalmazást. A screen segítségével egyetlen terminálról egyszerre több munkamenetet is tudunk indítani, de egyébként is egy nagyon jó program. Minden screen által létrehozott ablak VT100-as terminálként mûködik, ezért a távoli gépen a TERM környezeti változó nyugodtan beállítható a vt100 értékre. Tegyük hozzá a cons25 bejegyzést a távoli gép terminálokat tároló adatbázisához. Ez pontos módszere jelentõs mértékben függ az adott gépen található operációs rendszertõl. Ebben leginkább az adott gépen található man oldalak tudnak segíteni. Indítsunk el a &os; rendszert futtató gépen egy X szervert és a távoli géprõl egy X rendszerre íródott terminálemulátorral, például az xterm vagy az rxvt programmal jelentkezzük be. A távoli gépen ekkor a TERM változó értéke vagy xterm, vagy pedig vt100 lesz. A Plug and Play kártyákat miért nem találja meg (vagy unknown típusúként látja) a &os;? Ennek az okait a következõ levélben fejtette ki &a.peter; a &a.questions; tagjainak, amelyben arra válaszolt, hogy egy belsõ modemet miért nem észlel a rendszer miután frissítették &os; 4.X-re (az érthetõség kedvéért szögletes zárójelek között hozzáadtunk néhány kiegészítést is). Az eredeti szövegbõl készült idézetet frissítettük.
A PNP BIOS beállította [a modemet] és magára hagyta valahol a portok számára fenntartott címtérben, így az ISA eszközök régi típusú [3.X-ben levõ] eszközpróbálgatásai ott találták meg. A 4.0 esetében azonban az ISA eszközöket kezelõ kód már sokkal inkább a PnP támogatására koncentrál. Korábban [a 3.X verziókban] elõfordulhatott az is, hogy az ISA eszközök keresése során a rendszer egy kóbor eszközt talált, majd ugyanazt megtalálta PnP eszközként és ütköztek az így duplán lefoglalni kívánt erõforrások. Ennek kivédésére elõször tehát letiltjuk a programozható kártyák felderítését, így ez a típusú kettõs detektálás nem történhet meg. Ez továbbá azt is jelenti, hogy a támogatott PnP hardverek azonosítóit elõre ismerni kell. Ennek hangolhatóságát már tervbevettük.
Tehát egy ilyen eszköz mûködtetéséhez szükségünk lesz a PnP azonosítójára, valamint arra, hogy felvegyük a felderítendõ PnP eszközök ISA eszközök közé. Ezt a &man.pnpinfo.8; segítségével kérhetjük le, amely például egy belsõ modem esetén a következõ kimenetet fogja adni: &prompt.root; pnpinfo Checking for Plug-n-Play devices... Card assigned CSN #1 Vendor ID PMC2430 (0x3024a341), Serial Number 0xffffffff PnP Version 1.0, Vendor Version 0 Device Description: Pace 56 Voice Internal Plug & Play Modem Logical Device ID: PMC2430 0x3024a341 #0 Device supports I/O Range Check TAG Start DF I/O Range 0x3f8 .. 0x3f8, alignment 0x8, len 0x8 [16-bit addr] IRQ: 4 - only one type (true/edge) [a többi részt kihagytuk] TAG End DF End Tag Successfully got 31 resources, 1 logical fdevs -- card select # 0x0001 CSN PMC2430 (0x3024a341), Serial Number 0xffffffff Logical device #0 IO: 0x03e8 0x03e8 0x03e8 0x03e8 0x03e8 0x03e8 0x03e8 0x03e8 IRQ 5 0 DMA 4 0 IO range check 0x00 activate 0x01 Innen a Vendor ID kezdetû sorra lesz szükségünk. A zárójelek között szereplõ hexadecimális szám (ami a példában a 0x3024a341) lesz az eszköz PnP azonosítója, valamint a közvetlenül ez elõtt szereplõ karakterlánc az egyedi ASCII azonosítója (PMC2430). Ha a &man.pnpinfo.8; lefuttatásának eredményeképpen megjelenõ lista nem tartalmazza a kérdéses eszközt, akkor helyette a &man.pciconf.8; használatával is próbálkozhatunk. Íme a pciconf -vl parancs kimenete egy integrált hangkártya esetében: &prompt.root; pciconf -vl chip1@pci0:31:5: class=0x040100 card=0x00931028 chip=0x24158086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801AA 8xx Chipset AC'97 Audio Controller' class = multimedia subclass = audio Ebbõl a chip változót, vagyis a 0x24158086 értéket kell felhasználnunk. Ezt az információt (a Vendor ID vagy a chip értékét) ezután a /usr/src/sys/dev/sio/sio_isa.c állományba kell felvennünk. Ehhez elõször is készítsünk egy biztonsági másolatát a sio_isa.c állományról arra az esetre, ha véletlenül valami rossz történne. Ez azért is hasznunkra fog válni, mert így tudunk egy javítást mellékelni a hibajelentésünk mellé (mert ugye írni fogunk róla hibajelentést, ugye?). Szóval, keressük meg a sio_isa.c állományban a következõ sort: static struct isa_pnp_id sio_ids[] = { Menjük lentebb egészen addig, amíg nem találunk egy helyet, ahova be tudunk szúrni egy bejegyzést az eszközünkhöz. A bejegyzések megadásának módja lentebb látható, és a jobb oldalt megjegyzésbe tett ASCII Vendor ID szerint rendezettek, amelyek mellett még megtalálható (amennyiben kifér) a &man.pnpinfo.8; Device Description kimenetében kapott érték is: {0x0f804f3f, NULL}, /* OZO800f - Zoom 2812 (56k Modem) */ {0x39804f3f, NULL}, /* OZO8039 - Zoom 56k flex */ {0x3024a341, NULL}, /* PMC2430 - Pace 56 Voice Internal Modem */ {0x1000eb49, NULL}, /* ROK0010 - Rockwell ? */ {0x5002734a, NULL}, /* RSS0250 - 5614Jx3(G) Internal Modem */ A megfelelõ helyre ezután vegyük fel az eszközünkhöz tartozó hexadecimális Vendor ID értéket, mentsük el az állományt, fordítsuk újra a rendszermagot és indítsuk újra vele a rendszerünket. Ha mindent jól csináltunk, akkor az eszköz sio eszközként fog megjelenni. Miért keletkezik nlist failed hiba például a top vagy systat parancsok futtatásakor? A gondot alapvetõen az okozza, hogy a kérdéses alkalmazás valamiért egy olyan rendszermagbeli szimbólumot keres, amit nem talál. Ez a típusú hiba a következõkbõl eredhet: A rendszermag és a hozzátartozó programok nincsenek szinkronban (vagyis fordítottunk egy új rendszermagot, de nem volt installworld vagy fordítva) és emiatt a szimbólumokat tároló táblázat nem teljesen úgy épül fel, ahogy azt az alkalmazás gondolja. Ha errõl lenne szó, akkor egyszerûen nincs más teendõnk, mint befejezni a frissítést (ennek pontos részleteit lásd a /usr/src/UPDATING állományban). Nem a /boot/loader, hanem közvetlenül a boot2 (lásd &man.boot.8;) segítségével töltjük be a rendszermagot. Noha alapvetõen semmilyen problémát nem nem okoz a /boot/loader kihagyása, általánosságban véve azért mégis jobban elérhetõvé tudja tenni a rendszermagban található szimbólumokat a felhasználói programok felé. Miért tart olyan sokáig ssh vagy telnet használatával csatlakozni a számítógéphez? A tünet: nagyon sok idõ telik aközött, amíg a TCP kapcsolat felépül és a kliens bekéri a jelszót (vagy a &man.telnet.1; esetében amíg a bejelentkezõ képernyõ megjelenik). A betegség: nagyon valószínû, hogy a késlekedést az okozza, amikor a szerver megpróbálja a kliens IP-címét feloldani hálózati névvé. Sok szerver, köztük a &os;-ben is megtalálható Telnet és SSH szerver is ezt csinálja, többek közt azért, hogy a rendszergazda számára el tudja tárolni egy naplóban ezt a hálózati nevet. Az orvosság: ha az említett jelenség minden olyan esetben jelentkezik, amikor a számítógéprõl (mint kliensrõl) valamilyen szerverhez csatlakozni akarunk, akkor a kliens oldalán lesz a gond. Ehhez hasonlóan, ha csak egy adott szervernél tapasztaljuk, akkor azzal a számítógéppel történhetett valami. Amennyiben a problémákat a kliens okozza, nem tehetünk mást, a névoldáson kell úgy javítanunk, hogy a szerver normálisan fel tudja oldani. Ha helyi hálózaton tapasztaljuk mindezt, akkor ez már a szerver problémája és olvassunk tovább. Ellenkezõ esetben az internet a felelõs, ezért nagyon valószínû, hogy fel kell vennünk a kapcsolatot az internet-szolgáltatónkkal és segítséget kérni tõlük a hiba elhárításában. Ha a problémát viszont a helyi hálózaton található szerver okozza, akkor úgy kell azt beállítanunk, hogy a helyi neveket képes legyen rendesen feloldani. Ezzel kapcsolatban a &man.hosts.5; és &man.named.8; man oldalakat érdemes elolvasnunk. Ha a probléma viszont az interneten jelenik meg, akkor valószínû, hogy a szerver névfeloldása nem üzemel rendesen. Nézzünk meg egy másik gépet — például a www.yahoo.com címet. Ha ez sem mûködik, akkor nálunk van a gond. A &os; friss telepítését követõen az is elképzelhetõ, hogy egyszerûen csak hiányoznak a tartományokkal és névszerverekkel kapcsolatos megfelelõ adatok az /etc/resolv.conf állományból. Ez gyakran okoz késlekedést az SSH mûködésében, mivel az /etc/ssh könyvtárban található sshd_config állományban alapértelmezés szerint a UseDNS beállítás értéke yes (tehát a névfeloldás használata engedélyezett). Ha valóban ez okozza a problémát, akkor a pótoljuk az /etc/resolv.conf állományból hiányzó adatokat vagy az sshd_config állományban a UseDNS értéke ideiglenesen legyen no. Mire utal a stray IRQ (kóbor megszakítási kérés) üzenet? A kóbor megszakítási kéréseket jelzõ üzenetek általában a hardveres megszakítási kérések egyenletlenségeire utalnak, ezen belül is leginkább olyan esetekre, amikor az eszköz egy megszakítási kérés nyugtázása közepén eltávolítja az adott kérést. Három dolgot tehetünk ezzel kapcsolatban: Elviseljük ezeket a figyelmeztetéseket. Megszakítási kérésenként az elsõ öt üzenet után amúgy sem jelez többet a rendszer. Ha platformunkhoz (mint például &i386;) tartozó intr_machdep.c állományban található MAX_STRAY_LOG értékét átírjuk 5-rõl 0-ra és így újrafordítjuk a rendszermagot, akkor ezzel teljesen letilthatjuk a figyelmeztetéseket. Megszüntetjük az üzeneteket úgy, hogy csatlakoztatunk a rendszerhez egy olyan párhuzamos vonali eszközt, amely a 7-es IRQ-t használja, és rakunk fel hozzá egy PPP meghajtót (a legtöbb helyen egyébként ezzel lesz a gond), valamint a 15-ös IRQ-ra pedig rakunk egy IDE-meghajtót vagy más hasonló eszközt és telepítjük hozzá a megfelelõ meghajtót. Miért jelenik meg folyamatosan a file: table is full üzenet a rendszernaplóban? Ha ilyen hibaüzenetet látunk, akkor az arra utal, hogy kifogytunk a rendszerünkben egyszerre használható állományleírókból. A probléma leírásával és megoldásával kapcsolatban olvassuk el a kézikönyvben a kern.maxfiles változóról szóló részt A rendszermag korlátainak finomhangolása címû szakaszban. Miért árasztják el calcru: negative runtime vagy calcru: runtime went backwards üzenetek a konzolt? Ismert egy olyan probléma, hogy a BIOS-ban engedélyezzük az &intel; Enhanced SpeedStep technológiáját, akkor a rendszermag ehhez hasonló calcru üzeneteket kezd el küldözgetni: calcru: runtime went backwards from 6 usec to 3 usec for pid 37 (pagezero) calcru: runtime went backwards from 6 usec to 3 usec for pid 36 (vmdaemon) calcru: runtime went backwards from 170 usec to 138 usec for pid 35 (pagedaemon) calcru: runtime went backwards from 553 usec to 291 usec for pid 15 (swi6: task queue) calcru: runtime went backwards from 15521 usec to 10366 usec for pid 2 (g_event) calcru: runtime went backwards from 25 usec to 12 usec for pid 11 (swi1: net) calcru: runtime went backwards from 4417 usec to 3960 usec for pid 1 (init) calcru: runtime went backwards from 2084385 usec to 1793542 usec for pid 1 (init) calcru: runtime went backwards from 408 usec to 204 usec for pid 0 (swapper) Ennek oka, hogy az &intel; SpeedStep (EIST) egyes alaplapokkal nem kompatibilis. Megoldás: Tiltsuk le a BIOS-ban az EIST használatát. Ekkor még az ACPI-alapú processzorfrekvencia-szabályozás továbbra is elérhetõ a &man.powerd.8; használatán keresztül. Miért jár rosszul az óra a számítógépen? A számítógépnek kettõ vagy több idõmérõ eszköze van, és a &os; pont a rosszabbikat választotta. Adjuk ki a &man.dmesg.8; parancsot és vizsgáljuk meg a Timecounter kezdetû sorokat. Ezek közül a &os; a legnagyobb quality értékkel rendelkezõt választotta. &prompt.root; dmesg | grep Timecounter Timecounter "i8254" frequency 1193182 Hz quality 0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 Timecounter "TSC" frequency 2998570050 Hz quality 800 Timecounters tick every 1.000 msec Errõl a kern.timecounter.hardware &man.sysctl.3; változó lekérdezésével tudunk ténylegesen megbizonyosodni: &prompt.root; sysctl kern.timecounter.hardware kern.timecounter.hardware: ACPI-fast Elõfordulhat, hogy az ACPI-idõzítõ hibás. Ilyenkor az a legegyszerûbb, ha az /etc/loader.conf állományban letiltjuk az ACPI-idõzítõ használatát: debug.acpi.disabled="timer" Vagy a BIOS is tudja módosítani a TSC idõzítõt — például azért, hogy csökkentse a processzor sebességét, amikor merül az akkumulátor vagy energiatakarékos módra vált. A &os; sajnos nem figyel ezekre a változtatásokra és elcsúszik az idõméréssel. Ahogy viszont az iménti példában is látható, itt még az i8254 idõzítõ is használható, méghozzá úgy, hogy a kern.timecounter.hardware &man.sysctl.8; változó értékét átállítjuk erre az értékre: &prompt.root; sysctl -w kern.timecounter.hardware=i8254 kern.timecounter.hardware: TSC -> i8254 Innentõl kezdve a számítógépünk már sokkal pontosabban mutatja az idõt. Ezt a változtatást úgy tudjuk minden rendszerindítás során automatikusan megtenni, ha felvesszük a következõ sort az /etc/sysctl.conf állományba: kern.timecounter.hardware=i8254 A rendszer laptopon miért nem tudja rendesen megtalálni a PC-kártyákat? Ez a probléma gyakran megjelenik olyan laptopokon, amelyek egynél több operációs rendszert is futtatnak, egyes nem-BSD típusú rendszerek ugyanis hajlamosak a hardvert inkonzisztens állapotban hagyni. Emiatt a &man.pccardd.8; parancs az adott kártyát "(null)""(null)" néven észleli a valós típusa helyett. A hardvert innen teljesen csak úgy tudjuk alapállapotába hozni, ha a PC-kártya foglalatát áramtalanítjuk. Ehhez ki kell kapcsolnunk a laptopot. (Tehát ne tegyük se készenléti, se pedig hibernált állapotba — teljesen ki kell kapcsolni.) A PC-kártya ezután várhatóan már mûködni fog. Némely laptopok hazudnak arról, hogy rendesen ki vannak-e kapcsolva. Amennyiben az elõbbi módszer nem válna be, próbáljuk meg úgy, hogy kikapcsoljuk a gépet, kivesszük az akkumulátort, várunk egy keveset, visszarakjuk és újra bekapcsoljuk. Miért ad a &os; rendszertöltõje Read error hibát és áll meg a BIOS képernyõn? A &os; rendszertöltõje rosszul ismerte fel a merevlemez geometriáját. Ezt a &os; slice-ok létrehozásakor és módosításakor külön meg kell adni az &man.fdisk.8; használatakor. A meghajtóhoz tartozó megfelelõ geometriai beállítások a számítógép BIOS-ában találhatóak. Keressük meg az adott meghajtó cilinder-fej-szektor (Cylinder/Head/Sector) értékét. A &man.sysinstall.8; partíciószerkesztõjében a G billentyû lenyomásával tudjuk beállítani ezt. Ekkor egy párbeszédablak jelenik meg, ahol meg tudjuk adni a cilinderek, fejek és a sávonkénti szektorok számát. Ide perjelekkel elválasztva gépeljük e a BIOS-ban talált értékeket. Például ha a merevlemez geometriája 5000 cilinder, 250 fej és sávonként 60 szektor, akkor a 5000/250/60 értéket kell megadnunk. Az Enter billentyû lenyomására ezek az értékek beállítódnak, és a W lenyomására pedig az új partíciós tábla kiíródik a lemezre. Egy másik operációs rendszer letörölte a boot managert. Hogyan lehet visszaállítani? Indítsuk el a &man.sysinstall.8; programot, majd válasszuk a Configure és Fdisk menüpontokat. A partíciószerkesztõben a Space billentyûvel tudjuk kiválasztani azt a partíciót, amelyen korábban a boot manager volt. Ezután az W billentyû lenyomásával tudjuk a változtatásainkat lemezre menteni. Ekkor egy menü jelenik meg, ahol a telepíteni kívánt rendszertöltõt választhatjuk ki. Adjuk meg és ekkor visszakerül a helyére. Mit jelent a swap_pager: indefinite wait buffer: hibaüzenet? Ez arra utal, hogy egy futó program megpróbált kiírni egy lapot a memóriából a lemezre, azonban 20 másodperce már nem tudott hozzáférni a lemezhez. Ezt okozhatják hibás szektorok a lemezen, a lemez hibás kábelezése vagy esetleg valamilyen lemezmûveletekkel kapcsolatos hardver meghibásodása. Amennyiben maga a meghajtó a rossz, akkor az ilyen hibaüzenetek mellett még más, a lemez hibás mûködésére utaló üzenetet is látnunk kell a /var/log/messages állományban vagy a dmesg kimenetében. Minden más esetben érdemes a meghajtó csatlakozásait és kábelezését ellenõrizni. Mik azok a UDMA ICRC hibák és hogyan lehet ellenük tenni valamit? A &man.ata.4; meghajtó jelenti ezeket a UDMA ICRC hibákat olyan esetekben, amikor a merevlemezre vagy a merevlemezrõl érkezõ DMA átvitel hibás. A meghajtó ilyenkor még párszor megpróbálja megismételni a mûveletet. Amennyiben ezek a mûveletek is meghiúsulnak, a DMA átvitel helyett a lassabb PIO átviteli módra állítja át a merevlemez felé irányuló kommunikációt. Ezt a problémát több tényezõ is okozhatja, habár ennek a leggyakoribb oka a hibás vagy rossz kábelezés. Ilyenkor mindig ellenõrizzük, hogy a merevlemezhez csatlakozó ATA-kábelek sértetlenek és a használni kívánt Ultra DMA átviteli módra alkalmasak. Ha cserélhetõ lemezes meghajtót használunk, akkor kompatibilisnek is kell lenniük. Ez a gond akkor jelentkezhet, amikor ugyanarra az ATA-csatornára egy Ultra DMA 66-os (vagy annál is gyorsabb) és egy régebbi meghajtót csatlakoztatunk. Végezetül ezek a hibaüzenetek arra is utalhatnak, hogy a meghajtó meghibásodott. A legtöbb gyártó külön szoftver ajánl fel ennek vizsgálatára, ezért ilyenkor érdemes letesztelnünk az érintett meghajtót, illetve amennyiben szükséges, biztonsági másolatot készíteni az adatainkról és kicserélni az eszközt. Az &man.atacontrol.8; segédprogram használatával ellenõrizni tudjuk, hogy jelenleg az egyes ATA-eszközök milyen DMA vagy PIO módban mûködnek. Erre a célra különösen az atacontrol mode csatorna parancsot javasoljuk, amivel képesek vagyünk megnézni az adott ATA-csatornára csatlakozó eszközök átviteli módjait. Itt a csatorna értéke nullától indul. Mi az a lock order reversal? Erre a kérdésre a választ a &os;-s szakkifejezések gyûjteményében találjuk meg a LOR címszó alatt. Mit jelent a Called ... with the following non-sleepable locks held üzenet? Ez az üzenet arra utalhat, hogy egy függvény lepihent miközben nála volt egy mutex (vagy más, nem pihentethetõ) típusú zárolás. Azért keletkezik ilyen hiba, mert a mutexeket nem úgy tervezték, hogy hosszabb ideig is meg lehessen tartani, kizárólag csak rövid idõtartamra vonatkozó szinkronizációt lehet velük végezni. Ez a programozói megegyezés lehetõvé teszi az eszközmeghajtók számára, hogy a megszakítások közben mutexek segítségével képesek legyenek szinkronizálni a rendszermag többi részével. A megszakítások (&os; alatt) pedig nem pihenhetnek. Ezért a rendszermagon belül semmilyen olyan alrendszer nem blokkolódhat huzamosabb ideig, amelyik mutexet tart magánál. Ezeket a hibákat úgy tudjuk elcsípni, ha olyan ellenõrzéseket teszünk a rendszermagba, amelyek jeleznek a &man.witness.4; alrendszernek, hogy küldjön figyelmeztetést vagy akár végzetes hibát (a rendszer konfigurációjától függõen) azokban a helyzetekben, amikor egy sejthetõen hosszabb ideig blokkolt hívás tart magánál egy mutexet. Röviden úgy foglalhatnánk össze, hogy ezek a hibák alapvetõen nem végzetesek, de egy kis balszerencsével az egyszerû kis megakadásoktól kezdve a teljes lefagyásig szinte bármilyen hibáért felelõsek lehetnek. A buildworld/installworld miért áll le touch: not found hibával? Ez a hibaüzenet nem azt jelenti, hogy a &man.touch.1; segédprogram nem található, hanem inkább azt, hogy az érintett állományok dátuma a jövõre állítódott be. Ha a CMOS óránkat a helyi idõ szerint állítottuk be, akkor egyfelhasználós módban indítsuk újra a rendszert és a adjkerntz -i parancs kiadásával állítsuk be a rendszermag óráját. Kereskedelmi alkalmazások Ez a fejezet még nagyon rövid, de természetesen reméljük, hogy a különbözõ cégek hamarosan bõvíteni fogják! :) A &os; fejlesztõinek ezzel kapcsolatban semmilyen anyagi érdekük nincs, csupán szeretnék felsorolni a nyilvánosan is elérhetõ szolgáltatásokat (de úgy érezzük, hogy a &os; kereskedelmi irányú megközelítése a &os; fejlõdésére is jó hatással lehet hosszabb távon). Javasoljuk minden kereskedelmi fejlesztõnek, hogy küldjék be ide is a saját kérdéseiket. A gyártók honlapján olvashatjuk a teljes listájukat. Honnan lehet a &os;-hez irodai programcsomagokat szerezni? A nyílt forráskódú OpenOffice.org irodai programcsomag &os; alatt natívan is futtatható. StarOffice linuxos változata, amely az OpenOffice.org zárt forráskódú, továbbfejlesztett változata, szintén mûködik &os; alatt. A &os; ezeken kívül még számos szövegszerkesztõt, táblázatkezelõt és rajzprogramot is tartalmaz a Portgyûjteményében. Honnan lehet a &motif;-ot szerezni a &os;-hez? A The Open Group kiadta a &motif; 2.2.2 változatának forráskódját. Ez az x11-toolkits/open-motif csomagból vagy portból érhetõ el. A telepítésével kapcsolatban olvassuk el a kézikönyv portokról szóló részét. Az Open &motif; kizárólag csak nyílt forráskódú operációs rendszereken terjeszthetõ. Ezenkívül még használhatóak a &motif; kereskedelmi változatai is. Ezek viszont már nem ingyenesek, de a licencük megengedi azt, hogy zárt forráskódú szoftverekben is felhasználhassuk. Az Apps2gonál érdeklõdjünk a &os;-re elérhetõ legolcsóbb &motif; 2.1.20 ELF (&i386;) típusú terjesztésekkel kapcsolatban. Kétfajta terjesztés létezik, a fejlesztõi változat és a futásidejû változat (valamivel olcsóbb). Az egyes terjesztésekben a következõk találhatóak: OSF/&motif; manager, xmbind, panner, wsm Fejlesztõi készlet: uil, mrm, xm, xmcxx, include és Imake állományok Statikus és dinamikus ELF könyvtárak Példa alkalmazások A megrendelés során ne felejtsük el megadni, hogy a &motif; melyik &os; verzióhoz készített változatát kérjük (valamint az architektúrát se)! Az Apps2go NetBSD és OpenBSD rendszerekkel is foglalkozik, ezeket a változatokat jelenleg csak FTP-n keresztül lehet elérni. További információk Az Apps2go honlapja illetve sales@apps2go.com vagy support@apps2go.com vagy telefonon: (817) 431 8775 és +1 817 431-8775 Honnan lehet &os;-re CDE-t szerezni? A Xi Graphics korábban kínált fel CDE-t &os;-hez, de manapság már nem foglalkoznak ezzel. A KDE a CDE-hez nagyon sok tekintetben hasonló nyílt forráskódú X11 munkakörnyezet, de érdemes pillanatást vetnünk az xfce-re is. A KDE és az xfce egyaránt megtalalálható a portok között. Használhatóak adatbázisrendszerek &os; alatt? Igen! A &os; hivatalos honlapján megtaláljuk ezeket a kereskedelmi gyártók között. Érdemes még megnéznünk a Portgyûjteményeben a adatbázisokat tartalmazó szekciót. Az &oracle; fut &os; alatt? Igen. A következõ oldalakon találunk arról információt, hogyan telepíthetjük &os;-re az &oracle; &linux; változatát: http://www.unixcities.com/oracle/index.html http://www.shadowcom.net/freebsd-oracle9i/ Felhasználói alkalmazások Hol vannak a felhasználói programok? Nézzünk szét a portok között és láthatjuk, hogy milyen szoftvereket portoltak eddig &os;-re. A listában pillanatnyilag &os.numports; port található és naponta növekszik, ezért érdemes folyamatosan figyelni vagy az új portokról úgy is értesülhetünk rendszeresen, ha feliratkozunk a &a.announce; címére. A legtöbb portnak mûködnie kell a 6.X, 7.X és 8.X ágak használata esetén is. Mindegyik &os; kiadás elkészítésekor készül egy pillanatfelvétel a portokat tartalmazó könyvtárról és bekerül a ports/ könyvtárba. Ezenkívül még csomagok is rendelkezésünkre állnak, amelyek lényegében egy tömörített bináris terjesztési formát takarnak, némi plusz információval kiegészítve az egyéni telepítésekhez elvégzéséhez. A csomagok könnyen telepíthetõek és eltávolíthatóak anélkül, hogy pontosan ismernénk a benne található állományok összes apró részletét. A különbözõ csomagokat a &man.sysinstall.8; programban (a Configure menün belül) található Packages menüpontban tudjuk telepíteni, vagy meghívjuk meg a &man.pkg.add.1; parancsot. A csomagokat leginkább .tbz kiterjesztésükrõl lehet megismerni, valamint a telepítõ CD-ken a packages/All könyvtárban találhatóak. Az interneten keresztül is le tudjuk tölteni ezek közül a &os; különbözõ verzióihoz tartozó változatukat a hozzánk legközelebbi tükrözésekrõl: 6.X-RELEASE/6-STABLE esetén: ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-6-stable/ 7.X-RELEASE/7-STABLE esetén: ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-7-stable - 8-CURRENT esetén: + 8.X-RELEASE/8-STABLE + esetén: - ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-8-current + url="ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-8-stable/"> + ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-8-stable + + + + + 9-CURRENT esetén: + + + ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-9-current Nem mindegyik port érhetõ el csomagként, mivel folyamatosan készülnek az újabbak. Ezért mindig érdemes bizonyos idõközönként ellenõrizni a központi ftp.FreeBSD.org oldalon található csomagokat. Hogyan tudjuk beállítani az INN (Internet News) szolgáltatást a gépünkön? Telepítsük az news/inn csomagot vagy portot és utána kiindulásképpen nézzük meg Dave Barr INN oldalát, ahol (angolul) találhatunk egy INN GYIK-ot. A &os; rendelkezik &java; támogatással? Igen. Látogassunk el a http://www.FreeBSD.org/java/ oldalra. Miért nem fordul egy port a - 6.X-STABLE vagy a - 7.X-STABLE változatot + 6.X-STABLE, + 7.X-STABLE vagy + 8.X-STABLE változatot futtató gépeken? Ha olyan &os; verziónk van, amely egy kicsit lemaradt az aktuális -CURRENT vagy -STABLE ágak mögött, akkor valószínûleg frissítenünk kell a Portgyûjteményünket. Ennek részleteirõl a Porterek kézikönyvében, a Keeping Up címû részben olvashatunk (angolul). Ha viszont rendszerünkben minden a lehetõ legfrissebb, akkor elõfordulhat, hogy valaki olyan változtatást rakott fel a porthoz, amely a -CURRENT esetén mûködik, de a -STABLE változatban már nem. Ilyenkor feltétlenül küldjünk egy hibajelentést a &man.send-pr.1; paranccsal, hiszen a Portgyûjteménynek a -CURRENT és -STABLE ágak esetén egyaránt mûködnie kell. A make index paranccsal nem sikerült létrehozni az INDEX állomyánt. Mi a gond? Elsõként mindig ellenõrizzük, hogy a Portgyûjteményünk a lehetõ legfrissebb. A legfrissebb változatnál jelentkezõ INDEX készítési hibák mindig szem elõtt vannak, ezért általában gyorsan megjavulnak. Ha viszont egy friss verzióval rendelkezünk, akkor elképzelhetõ, hogy egy másik hibával kerültünk szembe. A make index parancsnak van egy olyan hibája, amely miatt nem képes a Portgyûjtemény hiányos példányával dolgozni. Feltételezi ugyanis, hogy az összes olyan port megtalálható a rendszerünkben, amely telepítése szükséges az adott porthoz. Ennek megértéséhez most képzeljük el, hogy megvan az ize/mize port a lemezen, amely függ az aze/maze porttól, és emiatt az aze/maze portnak és függõségeinek is rajta kell lennie a lemezünkön. Minden más esetben a make index nem tud összegyûjteni elegendõ információt ahhoz, hogy létre tudja hozni a függõségi gráfot. Ez különösen olyan &os; felhasználókkal fordul elõ, akik a &man.cvsup.1; (vagy &man.csup.1;) használatával frissítik a Portgyûjteményüket, de a refuse állományokban kizártak néhány kategóriát. Elméletben természetesen ki lehet zárni akármilyen kategóriát, azonban a gyakorlat azt mutatja, hogy ez szinte lehetetlen, mivel túlságosan sok port függ más kategóriákban található portoktól. Amíg valaki meg nem oldja ezt a problémát, addig fogadjuk el általános szabálynak, hogy az INDEX létrehozásához a teljes Portgyûjteménnyel rendelkeznünk kell. Néhány ritka esetben még elõfordulhat, hogy az INDEX azért nem jön létre, mert a make.conf állományban megadtunk valamilyen WITH_* vagy WITHOUT_* változót. Ha úgy érezzük, hogy ez okozhatja a problémát, akkor próbáljuk meg elõször ezen változók nélkül létrehozatni az INDEX állományt és csak utána jelenteni a hibát a &a.ports; címére. A CVSup miért nincs a &os; forrásai között? A &os; alaprendszerét úgy állították össze, hogy saját magát legyen képes legyen lefordítani, vagyis az egész operációs rendszer elõállítható legyen néhány alapvetõ eszköz használatával. Ezért a források között leginkább csak az található meg, ami feltétlenül kell a források lefordításához. Ilyen például a C fordító (&man.gcc.1;), a &man.make.1;, &man.awk.1; és a többi. Mivel a CVSup a Modula-3 programozási nyelven íródott, csak úgy tudnánk beletenni a &os; alaprendszerbe, ha hozzávennénk és karbantartanánk egy Modula-3 fordítót is. Ezzel együtt viszont növekedne a &os; forrása, amelyet aztán karban is kellene tartani. Ezért mind a fejlesztõk, mind pedig a felhasználók számára egyszerûbb, ha a CVSup egy külön portként érhetõ el a rendszerhez. Ez viszont gyorsan telepíthetõ a &os; telepítõ CD-ken található csomagokból. Azonban a &os; 6.2-RELEASE megjelenésétõl kezdve a &os; felhasználók nem maradnak integrált CVSup kliens nélkül. &a.mux; munkájának köszönhetõen a CVSup alkalmazásnak elkészült a C nyelven újraírt változata, a &man.csup.1;, amely most már az alaprendszer része. Noha jelenleg nem még nem képes mindarra, amire a CVSup, elegendõ (és nagyon gyors!) ahhoz, hogy a forrásainkat frissen tartsuk. A 6.2 elõtt kiadott rendszerek esetében ezt portból vagy csomagból is felrakhatjuk (lásd net/csup). A forrásokon kívül a telepített portokat is lehet valahogy frissíteni? A &os; alaprendszere ehhez nem kínál fel semmilyen eszközt, de léteznek olyan segédeszközök, amelyekkel valamennyire meg tudjuk könnyíteni a frissítés folyamatát. További segédprogramok telepítésével pedig a portok kezelését tudjuk tovább egyszerûsíteni, amirõl a &os; kézikönyv A portok frissítése címû szakaszában olvashatunk bõvebben. Minden nagyobb verziófrissítésnél újra kell fordítani az összes telepített portot a rendszeren? Mindenképpen! Noha látszólag a frissített rendszeren is remekül futnak a korábbi verzióra telepített alkalmazások, könnyen elõfordulhat, hogy az újabb portok telepítésékor vagy a meglevõek frissítésekor véletlenszerû összeomlásokat vagy egyéb hibákat tapasztalunk. Ne felejtsük el, hogy a rendszer frissítésekor a különféle osztott könyvtárak, betölthetõ modulok és a rendszer egyéb komponensei is lecserélõdnek. Ezért a régebbi változataikhoz fordított alkalmazások egyáltalán nem fognak elindulni vagy nem mûködnek rendesen. Ezzel kapcsolatban olvassuk el a &os; kézikönyvének frissítérõl szóló szakaszát. Minden kisebb verziófrissítésnél újra kell fordítani az összes telepített portot a rendszeren? Általánosságban véve nem. A &os; fejlesztõi ugyanis mindent megtesznek azért, hogy ugyanazon a fõ fejlesztési ágon belüli verziók között megmaradjon a bináris szintû kompatibilitás. Az esetleges kivételeket pedig dokumentálni szokták a kiadásokhoz tartozó jegyzetekben, ahol többnyire megadják az adott változtatáshoz tartozóan a követendõ tanácsokat. A /bin/sh miért ilyen egyszerû? A &os;-ben miért nincs bash vagy valamilyen más rendes parancsértelmezõ? Mert a &posix; szerint lennie kell egy ilyen parancsértelmezõnek. A valamivel bonyolultabb válasz: sokan szeretnének olyan szkripteket írni, amelyek több rendszer közt is átvihetõek. Ezért a &posix; a parancsértelmezõkre és a segédprogramokra vonatkozó parancsokat igen részletesen tárgyalja. A legtöbb ilyen szkriptet a Bourne-féle parancsértelmezõben készítik, és több fontos programozói felület (&man.make.1;, &man.system.3;, &man.popen.3; és ezek magasabb szintû, például Perl és Tcl nyelvi megfelelõi) a Bourne-parancsértelmezõ használatán alapszik. Mivel a Bourne-parancsértelmezõ használata ilyen széles körben elterjedt, fontos, hogy gyorsan induljon, elõre megjósolható legyen a mûködése és ne foglaljon túlságosan sok memóriát. A jelenlegi implementáció igyekszik ezek közül az elvárások közül egyszerre a lehetõ legtöbbet teljesíteni. A /bin/sh programot csak úgy tudjuk a megfelelõ méreten tartani, ha nem tesszük bele az összes többi parancsértelmezõben megtalálható kényelmi funkciót. Pontosan ezért találhatjuk meg viszont a Portgyûjteményben a többi, például a bash, scsh, tcsh és zsh parancsértelmezõket. (Ezek konkrét memóriahasználatát össze is tudjuk vetni, ha a ps parancs kimenetének VSZ és RSS oszlopait megnézzük.) A &netscape; és az Opera indítása miért tart olyan sokáig? Erre az az általános válasz, hogy a névfeloldás valószínûleg rosszul mûködik a rendszerünkön. A &netscape; és az Opera is ellenõrzi a névfeloldást az indulásakor. Ezért a böngészõ egészen addig nem jelenik meg az asztalon, amíg választ nem kap vagy rá nem jön, hogy nincs aktív hálózati kapcsolat. Ha a CVSup használatával frissítjük a Portgyûjteményt, akkor sok port nem fordul le mindenféle rejtélyes hibaüzenet kíséretében! Valami nagy baj van a Portgyûjteménnyel? Ha úgy korábban úgy frissítettük a CVSup használatával a Portgyûjteményt, hogy nem adtuk meg a ports-all CVSup algyûjteményt, akkor a ports-base algyûjteményt is mindig frissítenünk kell! Ennek okairól a kézikönyvben olvashatunk. Hogyan lehet MIDI állományokból audio CD-t készíteni? Ha MIDI állományokból akarunk audio CD-t készíteni, akkor elõször telepítsük fel a Portgyûjteménybõl a audio/timidity++ portot, majd kézzel tegyük hozzá Eric A. Welsh GUS patch-eit, melyek a címrõl tölthetõek le. Miután a TiMidity++ sikeresen felkerült a rendszerünkre, a MIDI állományokat a következõ paranccsal tudjuk átkonvertálni WAV állományokra: &prompt.user; timidity -Ow -s 44100 -o /tmp/juke/01.wav 01.mid A WAV állományok ezek után tetszõleges formátumba konvertálhatóak tovább vagy készíthetõ belõlük egy audio CD, ahogy azt a &os; kézikönyvben is olvashatjuk. A rendszermag beállítása Nehéz testreszabni a rendszermagot? Egyáltalán nem! Ezzel kapcsolatban olvassuk el a &os; kézikönyv rendszermag beállításairól szóló részét. Az új kernel állomány a hozzátartozó modulokkal együtt a /boot/kernel könyvtárba települ, míg a rendszermag korábbi változata és a moduljai a /boot/kernel.old könyvtárba kerül át, így ha netalán valamit elrontottunk volna, akkor a rendszermag korábbi változatának betöltésével lehetõségünk lesz kijavítani a hibát. A rendszermag nem fordul le, mert a _hw_float nem található. Hogyan lehet megoldani ezt a problémát? Ez valószínûleg azért következett be, mert eltávolítottuk az npx0 (lásd &man.npx.4;) támogatást a rendszermag beállításai közül, mert a rendszerünkben nincs matematikai társprocesszor. Az npx0 eszköz jelenléte azonban kötelezõ. Valahol a gépünkben lennie kell olyan eszköznek, amely a lebegõpontos számok hardveres kezelését végzi, annak ellenére, hogy nem egy különálló eszköz, ahogy régen a 386-osoknál volt. A rendszermagban szerepelnie kell az npx0 eszköznek. Ha netalán még sikerülne is npx0 támogatás nélkül fordítanunk egy rendszermagot, akkor sem tud elindulni. Miért ilyen nagy a rendszermag mérete (közel 10 MB)? Nagyon valószínû, hogy a rendszermagunk debug módban készült el. A debug módú rendszermagokban rengeteg olyan szimbólum található, amely hasznos lehet a hibák keresése és a rendszer vizsgálata során, ezért emiatt jelentõs mértékben növekszik a mérete. Emiatt nem kell aggódnunk, mert egy hibakeresésre felkészített rendszermag egyáltalán nem vagy csak egy kicsivel lassabb, mint a hagyományos változat, illetve a rendszer összeomlásakor mindig mindig szükségünk lehet ezekre a debug információkra. Ha viszont kevés a lemezterület vagy egyszerûen csak nem akarunk debug módú rendszermagot akarunk futtatni, akkor a következõkre kell figyelnünk: Vegyük ki a rendszermag konfigurációs állományából a következõ sort: makeoptions DEBUG=-g A &man.config.8; használata során ne használjuk a beállítást. A fentiek közül akármelyiket is választjuk, a rendszermagunk debug módban jön létre. Ha azonban sikerült betartani a fentebb javasolt lépéseket, akkor egy normál rendszermagot kapunk, amely mérete ilyenkor jelentõs mértékben visszaesik: a legtöbbjük olyan 1,5 és 2 MB körül van. Miért ütköznek a megszakítások, amikor többportos soros vonali kártyákat akarunk használni? Ha a rendszermagot a többportos soros vonali kártyák támogatásával fordítjuk le, akkor a rendszertõl azt az üzenetet kapjuk, hogy csak az elsõ megszakítást fogja használni, a többit pedig ütközés miatt (interrupt conflict) kihagyja. Hogyan lehet ezen javítani? A gondot alapvetõen az okozza, hogy a &os; a rendszermagban fixen letárolja ezeket, nehogy valamilyen hardveres vagy szoftveres ütközés miatt elkallódjanak. Ezen úgy tudunk segíteni, ha egyetlen IRQ vonal kivételével az összes többi beállítását szabadon hagyjuk. Íme erre egy példa: # # Többportos nagysebességû soros vonali eszközök - 16550 UART # device sio2 at isa? port 0x2a0 tty irq 5 flags 0x501 vector siointr device sio3 at isa? port 0x2a8 tty flags 0x501 vector siointr device sio4 at isa? port 0x2b0 tty flags 0x501 vector siointr device sio5 at isa? port 0x2b8 tty flags 0x501 vector siointr Miért nem lehet lefordítani a rendszermagot, még a GENERIC beállításaival sem? Ennek több oka is lehet. Ezek közül néhány, de nem feltétlenül ebben a sorrendben: Nem a make buildkernel és make installkernel parancsokat használtuk és valószínûleg a forrásaink sem egyeznek meg a jelenleg futó rendszerével (például egy &rel.current;-RELEASE rendszert akarunk fordítani egy &rel2.current;-RELEASE rendszeren). Ha frissíteni akarunk, akkor olvassuk el a /usr/src/UPDATING állományt, különös tekintettel a végén található COMMON ITEMS címû szakaszra. A make buildkernel és make installkernel parancsokat használtuk, de elõtte nem futott le rendesen a make buildworld parancs. A make buildkernel parancs ugyanis erõsen támaszkodik a make buildworld által végzett munkára. Gyakran a &os;-STABLE változat használata esetén is elõfordulhat, hogy olyan pillanatban töltöttük le a forrásokat, amikor módosítás alatt voltak vagy valamiért nem mûködtek rendesen. Kizárólag a kiadások esetén tudjuk szavatolni a hibátlan fordítást, noha a &os;-STABLE verzióból készült változatok is többnyire megfelelõek. Próbáljuk meg újra letölteni a forrásokat, ha eddig még nem próbálkoztunk volna vele, és nézzük meg, hogy ez segít-e megoldani a problémát. Keressük másik szervert, ha gondjaink vannak a frissítéssel. Honnan tudhatjuk meg milyen ütemezõvel dolgozik a rendszerünk? Nézzük meg, hogy a rendszerünkben elérhetõ-e a kern.sched.quantum változó. Ha van ilyenünk, akkor valami ilyesmit kell tapasztalnunk: &prompt.user; sysctl kern.sched.quantum kern.sched.quantum: 99960 Ha létezik a kern.sched.quantum nevû sysctl változó, akkor a 4BSD ütemezõ fut (lásd &man.sched.4bsd.4;). Ha nem, akkor egy ilyen hibát kapunk a &man.sysctl.8; parancstól (ezt nyugodtan figyelmen kívül hagyhatjuk): &prompt.user; sysctl kern.sched.quantum sysctl: unknown oid 'kern.sched.quantum' Az aktuálisan használt ütemezõ neve közvetlenül elérhetõ a kern.sched.name sysctl változó lekérdezésén keresztül: &prompt.user; sysctl kern.sched.name kern.sched.name: 4BSD Mi az a kern.sched.quantum? A kern.sched.quantum értéke határozza meg, hogy egy futó program legfeljebb mennyi órajelet futhat egyszerre, megszakítás nélkül. Ezt az értéket a 4BSD ütemezõ használja, ezért a jelenlétébõl vagy hiányából következtetni tudunk a pillanatnyilag használatban levõ ütemezõre. Lemezek, állományrendszerek és rendszertöltõk Hogyan adjunk lemezeket a &os; rendszerünkhöz? Ezzel kapcsolatban olvassuk el a lemezek hozzáadásáról szóló részt a &os; kézikönyvben. Hogyan lehet átteni a rendszert egy nagyobb lemezre? Ezt legegyszerûbben úgy tudjuk megcsinálni, ha újratelepítjük az operációs rendszert az új lemezre és külön áttesszük a felhasználói adatokat. Ez különösen ajánlott abban az esetben, ha már több kiadás óta követjük a -STABLE változatot, vagy ha korábban már frissítettük a kiadásunkat. A &man.boot0cfg.8; segítségével fel tudjuk rakni a booteasyt mind a két lemezre és így egészen addig váltogatni tudjuk a kettõt, amíg teljesen át nem álltunk. Ugorjuk át a következõ bekezdést, és olvassuk el, hogy rakjuk át az adatokat. Úgy is dönthetünk, hogy nem telepítjük újra a rendszert. Ekkor vagy a &man.sysinstall.8;, vagy pedig a &man.fdisk.8; és a &man.disklabel.8; használatával osszuk fel és címkézzük meg az új lemezt. Érdemes még a &man.boot0cfg.8; segítségével felraknunk a booteasyt mind a két lemezre, így miután átmásoltuk a régi rendszerünket az új lemezre, ennek megtartásával ki tudjuk próbálni az új rendszert. A lemezek formázásáról szóló cikkben olvashatunk ennek pontosabb részleteirõl. Most, miután sikeresen beállítottuk az új lemezt, készen állunk az adatok átmásolására. Sajnos nem lehet csak úgy vakon átmásolni ezeket egyik lemezrõl a másikra. Ilyenkor ugyanis bizonyos dolgok (például a /dev könyvtárban található eszközleírók, az állományjelzõk és a linkek stb.) hajlamosak elromlani. Ezért ehhez olyan eszközökre lesz szükségünk, amelyek ismerik ezeket a dolgokat, mint például a &man.dump.8;. Továbbá javasoljuk, hogy egyfelhasználós módban végezzük el az átvitelt, noha ez nem feltétlenül szükséges. A rendszerindító állományrendszer átmozgatásához egyedül a &man.dump.8; és &man.restore.8; segédprogramokra lesz szükségünk. Esetleg a &man.tar.1; parancs is használható, de nem minden esetben. A &man.dump.8; és &man.restore.8; páros akkor is remekül használható, ha egy partíció tartalmát egy üres partícióra akarjuk átvinni. A következõ lépések szükségesek ahhoz, hogy a dump parancs segítségével átvigyük egyik partícióról a másikra az adatokat: Hozzunk létre egy új partíciót. Ideiglenesen csatlakoztassuk egy könyvtárba. Lépjünk be abba a könyvtárba. Mentsük le a régi partíciót és az eredményt küldjük át az újra. Például, ha a /mnt könyvtárba csatlakoztatott /dev/ad1s1a eszközrõl akarjuk átvinni a jelenlegi gyökérpartíciónkat, akkor ezeket a parancsokat kell kiadnunk: &prompt.root; newfs /dev/ad1s1a &prompt.root; mount /dev/ad1s1a /mnt &prompt.root; cd /mnt &prompt.root; dump 0af - / | restore rf - További munkát igényel, ha a dump parancs segítségével a partícióinkat is át akarjuk szervezni. Például a /var partíciót úgy tudjuk beleolvasztani a tövébe, ha létrehozunk egy olyan partíciót, amely mind a kettõ számára elegendõ nagy, majd a fentebb leírt módszerrel elõször átmozgatjuk a tövét, utána pedig átmozgatjuk az alpartíció tartalmát az elsõ mozgatás során létrejött egyik üres könyvtárba: &prompt.root; newfs /dev/ad1s1a &prompt.root; mount /dev/ad1s1a /mnt &prompt.root; cd /mnt &prompt.root; dump 0af - / | restore rf - &prompt.root; cd var &prompt.root; dump 0af - /var | restore rf - Egy könyvtárat, például /var tartalmát pedig úgy tudunk leválasztani a tövérõl, vagyis átrakni egy korábban nem létezõ partícióra, ha elõször létrehozzuk mind a két partíciót, csatlakoztatjuk a leendõ alpartíciót az ideiglenes csatlakozási ponton belül a megfelelõ könyvtárba és mindkettõre átmozgatjuk a régi partíció teljes tartalmát: &prompt.root; newfs /dev/ad1s1a &prompt.root; newfs /dev/ad1s1d &prompt.root; mount /dev/ad1s1a /mnt &prompt.root; mkdir /mnt/var &prompt.root; mount /dev/ad1s1d /mnt/var &prompt.root; cd /mnt &prompt.root; dump 0af - / | restore rf - A felhasználói adatok esetén a &man.cpio.1;, &man.pax.1;, &man.tar.1; és &man.dump.8; eszközöket ajánljuk. Az írás pillanatában még úgy tudjuk, hogy nem tartják meg az állományjelzõkkel kapcsolatos információkat, ezért csak óvatosan használjuk ezeket! A Veszélyesen dedikált (Dangerously Dedicated) lemezek veszélyesek a felhasználóra? A telepítés során két különbözõ módon tudjuk partícionálni a lemezeinket. Alapértelmezés szerint a rendszer igyekszik kompatbilis maradni a gépünkön található többi operációs rendszerrel. Ilyenkor normális partíciós táblabeli bejegyzéseket készít (amelyeket &os; alatt slice-oknak hívnak), és egy ilyen slice-ba teszi az összes saját partícióját. Emellé még telepíteni tudjuk az operációs rendszerek választásának lehetõségét is a rendszer indításakor. A másik lehetõség választása esetén azonban a &os; teljesen kisajátítja a lemezt és nem is próbál meg kompatibilis maradni a többi operációs rendszerrel. Miért is nevezzük ezt veszélyesnek? A lemez ebben az esetben nem tartalmaz semmi olyat, amelyet a hétköznapi programok partíciós táblaként tudnának beazonosítani. Attól függõen, hogy mennyire illedelmes, egy ilyen program panaszkodni fog, amikor megpróbálja értelmezni a lemez tartalmát, de rosszabb esetben anélkül felülírja a rendszerbetöltõt, hogy bármit is jelzett volna. Ráadásul a veszélyesen dedikált módon kiosztott lemezek még bizonyos BIOS-okat is képesek megzavarni, többek közt az Award (például amelyek a HP NetServer, Micronics és hasonló rendszerekben találhatóak) vagy Symbios/NCR (népszerû 53C8xx SCSI-vezérlõk) típusúak esetén találkozhatunk ezzel a problémával. Ez a lista persze nem teljes, más gyártók termékeivel is gondok akadhatnak. Ennek a hibának jellemzõ tünete a read error hibaüzenet, amely arra utal, hogy a &os; betöltõje nem találja saját magát a lemezen, vagy éppen az egész rendszer megáll a rendszer indítása közben. Akkor mégis mi értelme van ennek? Csak néhány kilobyte-tot spórolunk vele, miközben komoly gondokat okozhat egy frissen telepített rendszer esetében. A veszélyesen dedikált mód eredetileg az új &os; telepítõket veszélyeztetõ egyik komoly hibát szeretné kiküszöbölni: a merevlemezek BIOS és lemez önmaga által ismert geometriai beállításainak egyeztetése. A lemezgeometria fogalma tulajdonképpen már egy elavult fogalom, de a PC-k BIOS-a legbelül még mind a mai napig így kommunikál a lemezekkel. Amikor a &os; telepítõjével slice-okat hozunk létre, olyan módon kell rögzítenünk a lemezre ezek pozícióját, hogy a BIOS képes legyen megtalálni. Ha ez nem sikerül, akkor nem tudjuk elindítani a rendszert. A veszélyesen dedikált mód ezt a problémát az egyszerûsítésén keresztül próbálja megoldani, és néha sikerül is neki. Ezt azonban csak akkor javasoljuk, ha semmi más nem mûködik, hiszen az esetek túlnyomó részében más megoldás is létezik. Hogy tudjuk tehát akkor elkerülni a veszélyesen dedikált mód használatát a telepítés során? Jegyezzük fel, hogy mik a BIOS szerint a merevlemezünk geometriai beállításai. Ezt a rendszerindítás közben a rendszermagtól is megkérdezhetjük úgy, hogy a boot: paranccsorába megadjuk a beállítást, vagy a betöltõben a boot -v parancsot használjuk. Így pontosan a telepítõ indítása elõtt a rendszermag ki fogja írni a BIOS által ismert geometriai beállításokat. Ne essünk pánikba, várjuk meg, amíg a telepítõ elindul, tekerjünk vissza a számokhoz és olvassuk le ezeket. A lemezek általában a BIOS sorrendjében jelennek meg, tehát elõször az IDE aztán a SCSI típusúak. A lemez partícionálásakor ellenõrizzük, hogy az FDISK képernyõjén megjelenõ geometriai beállítások megfelelõek (tehát egyeznek a BIOS által ismert értékekkel). Ha eltérést tapasztalunk, akkor a G billentyû lenyomásával tudjuk átjavítani. Erre leginkább akkor lesz szükségünk, ha a lemez teljesen üres, vagy ha a lemezt egy másik rendszerbõl hoztuk át. Ez egyébként csak azoknál a lemezeknél okoz gondot, amelyekrõl a rendszert akarjuk indítani, a &os; a többi lemezzel már remekül elboldogul. Miután sikerült egyeztetnünk a BIOS és a &os; geometriai beállításait, szinte biztos, hogy nem kell már emiatt aggódnunk, így a veszélyesen dedikált módra sincs szükségünk. Ha viszont mégis egy read error hibaüzenetet kapnánk a rendszer indítása közben, akkor tegyünk egy próbát. Semmit sem veszíthetünk. Ha a veszélyesen dedikált mód használatáról szeretnénk visszatérni a megszokottra, akkor két lehetõségünk van. Elõször is teljesen le kell nulláznunk az MBR-t, így biztosra vehetjük, hogy az ezután következõ telepítések során egy teljesen üres lemezt látunk. Ezt például így lehet megtenni: &prompt.root; dd if=/dev/zero of=/dev/rda0 count=15 A másik módszer egy hivatalosan nem dokumentált DOS-os lehetõség használata: C:\> fdisk /mbr Ezzel egy új Master Boot Recordot tudunk telepíteni, ami ezzel együtt felülírja a BSD rendszertöltõjét is. Milyen partíciókon lehet Soft Updatest használni? A Soft Updates állítólag nem mûködik rendesen a gyökérpartíció esetén. A rövid válasz: A Soft Updates bármelyik partíción minden további nélkül használható. A hosszabb válasz: Korábban voltak bizonyos kétségek afelõl, hogy a Soft Updates jól mûködik a rendszerindító partíciókon is. Ez alapvetõen a Soft Updates két jellemzõjére vezethetõ vissza. Elõször is, a Soft Updatest alkalmazó partíciók esetén elõfordulhat, hogy a rendszerösszeomlás során elveszik valamennyi adat (maga a partíció nem lesz hibás, csupán némi adat tûnik el), illetve a Soft Updates ideiglenesen kifogyhat a tárhelybõl. A Soft Updates használata során a rendszermag legfeljebb harminc másodperc múlva írja ki fizikailag a változtatásokat a lemezre. Tehát amikor egy nagyobb állományt törlünk, akkor ez az állomány egészen addig a lemezen marad, amíg a rendszermag ténylegesen el nem végzi ezt a törlést. Ezzel viszont nagyon egyszerûen létrehozható egy ütközés (race condition) az állományrendszeren. Tegyük fel, hogy letörlünk egy nagyobb állományt és utána közvetlenül létrehozunk egy másik nagyobb állományt. Mivel az elsõ állomány ilyenkor még nem törlõdik le valójában a lemezrõl, ezért a második számára már nem lesz elegendõ helyünk. A rendszer ekkor egy hibaüzenetben fog figyelmeztetni minket, miközben pontosan az imént töröltünk le egy óriási állományt! Ha néhány másodperccel késõbb újra megpróbáljuk létrehozni ezt az állományt, akkor már minden a megfelelõ módon fog zajlani. Ezt régebben sok &os; felhasználó nem tudta mire vélni. Ha a rendszerünk olyankor omlik össze, amikor a rendszermag már elkezdte egy nagyobb mennyiségû adat kiírását a lemezre, de még nem fejezõdött be, akkor könnyen elõfordulhat, hogy ez az adat elveszik vagy meghibásodik. Ennek kockázata nagyon kicsi, és általában kezelhetõ, viszont az IDE-meghajtókban található írási gyorsítótár használata jelentõsen növeli ezt. Ezért a Soft Updates alkalmazása során nem javasoljuk ennek használatát. Ezek a problémák az összes Soft Updates partíciót veszélyeztetik. Mennyiben vonatkoznak viszont ezek a gyökérpartícióra? A gyökérpartíción nagyon ritkán változnak fontos információk. A /boot/kernel/kernel és az /etc egyedül a rendszer karbantartása során frissül, vagy például amikor a felhasználók jelszót változtatnak. Ha a rendszer egy ilyen változtatás harminc másodperces idején belül omlik össze, akkor megvan rá az esélyünk, hogy elvesznek az adataink. Ez a kockázat a legtöbb alkalmazás számára elfogadható, de semmiképpen sem szabad figyelmen kívül hagynunk. Ha a rendszerünk nem képes vállalni még ennyi kockázatot sem, akkor a rendszerindító partíción tiltsuk le a Soft Updates használatát! A gyökérpartíció hagyományosan az egyik legkisebb partíció. Ha viszont az ideiglenes állományok tárolására szánt /tmp könyvtárat is ezen belülre tesszük és gyakran használjuk, akkor ebbõl idõszakosan tárhelyproblémáink adódhatnak. Könnyen megoldhatjuk azonban ezt a problémát, ha a /tmp könyvtárhoz létrehoznunk egy szimbolikus linket a /var/tmp könyvtárra. Mi történt a &man.ccd.4; eszközzel? A hibajelenség: &prompt.root; ccdconfig -C ccdconfig: ioctl (CCDIOCSET): /dev/ccd0c: Inappropriate file type or format Ez általában olyankor történik, amikor olyan c partíciókat próbálunk meg összefûzni, amelyek alapértelmezés szerint unused (nem használt) típusúak. A &man.ccd.4; meghajtó azonban megköveteli, hogy az érintett partíciók FS_BSDFFS típusúak legyenek. Szerkesszük át a lemezeken található címkéket és változtassuk meg a partíciók típusát a 4.2BSD értékre. Miért nem lehet a &man.ccd.4; eszköz lemezcímkéjét szerkeszteni? A hibajelenség: &prompt.root; disklabel ccd0 (itt valami gondot ír ki, ezért megpróbáljuk szerkeszteni a címkét) &prompt.root; disklabel -e ccd0 (edit, save, quit) disklabel: ioctl DIOCWDINFO: No disk label on disk; use "disklabel -r" to install initial label Ezt általában azért kapjuk, mert a &man.ccd.4; által visszaadott lemezcímke valójában nem létezik a lemezen. Ezen úgy tudunk segíteni, ha explicit módon visszaírjuk, valahogy így: &prompt.root; disklabel ccd0 > /tmp/lemezcimke.tmp &prompt.root; disklabel -Rr ccd0 /tmp/lemezcimke.tmp &prompt.root; disklabel -e ccd0 (most már mûködni fog) Lehet más operációs rendszerek állományrendszerét is csatlakoztatni &os; alatt? A &os; több más állományrendszert is ismer. UFS Az UFS formátumú CD-k &os; alatt közvetlenül csatlakoztathatóak. A Digital UNIX és más rendszerek UFS partícióit nem már annyira könnyû csatlakoztatni, ez leginkább a kérdéses operációs rendszer partícionálási megoldásaitól függ. ext2/ext3 A &os; támogatja az ext2fs és ext3fs partíciókat. Errõl bõvebben lásd a &man.mount.ext2fs.8; man oldalt. NTFS A &os; csak olvasni képes az NTFS partíciókat. Ezzel kapcsolatban a &man.mount.ntfs.8; man oldalán találunk részletesebb információkat. Az írhatóság használatához az ntfs-3g portolt változatát javasoljuk (lásd sysutils/fusefs-ntfs). FAT A &os; egyaránt képes írni és olvasni a FAT típusú partíciókat. Errõl a &man.mount.msdosfs.8; man oldalán tudhatunk meg többet. ReiserFS A &os; tudja olvasni a ReiserFS partíciókat. Ezt a &man.mount.reiserfs.8; man oldalon olvashatjuk. ZFS A &os; jelen pillanatban a &sun; ZFS meghajtójának átiratát is tartalmazza. Jelenleg azonban csak elegendõ memóriával rendelkezõ &arch.amd64; platformokon javasoljuk a használatát. Részletesebb információkért lásd a &man.zfs.8; man oldalt. A &os; hálózati állományrendszereket is támogat, többek közt az NFS-t (lásd &man.mount.nfs.8;), a NetWare-t (lásd &man.mount.nwfs.8;), és Microsoft-féle SMB állományrendszereket (lásd &man.mount.smbfs.8;). Más egyéb FUSE-alapú állományrendszer (sysutils/fusefs-kmod) támogatását is megtalálhatjuk a portok között. Hogyan lehet másodlagos (logikai) DOS partíciókat csatlakoztatni? A logikai DOS partíciók az elsõdleges partíciók után találhatóak. Például, ha van egy E betûjelû logikai partíciónk a második SCSI-meghajtónkon, akkor lennie kell egy ötödik slice-nak a /dev könyvtárban, amelyet majd csatlakoztatni tudunk: &prompt.root; mount -t msdosfs /dev/da1s5 /dos/e Használható titkosított állományrendszer &os; alatt? Igen. Erre a célra a &man.gbde.8; és a &man.geli.8; is tökéletesen alkalmas. A részleteket lásd a &os; kézikönyv A lemezpartíciók titkosítása címû fejezetében. A &windowsnt; rendszertöltõjével is el lehet indítani a &os;-t? Ehhez tulajdonképpen csak annyit kell csinálnunk, hogy átmásoljuk a &os; rendszerindító partíciójának az elsõ szektorát egy állományba a DOS/&windowsnt; partíción belül. Legyen ez például a C:\BOOTSECT.BSD állomány (a C:\BOOTSECT.DOS mintájára), amelyhez aztán így igazítjuk a c:\boot.ini állományt: [boot loader] timeout=30 default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS [operating systems] multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows NT" C:\BOOTSECT.BSD="&os;" C:\="DOS" Ha a &os; ugyanazon a lemezen található, ahonnan a &windowsnt; is indul, akkor egyszerûen csak másoljuk át a /boot/boot1 állományt C:\BOOTSECT.BSD néven. Ha viszont a &os; egy másik lemezen található, akkor a /boot/boot1 önmagában már nem elegendõ, hanem helyette a /boot/boot0 állományra lesz szükségünk. A /boot/boot0 állományt a &man.sysinstall.8; használatával kell telepíteni abból a menübõl, ahol a &os; boot managerét kell kiválasztani. Erre azért van szükség, mert a /boot/boot0 állományon belül a partíciós tábla teljesen üres, azonban a &man.sysinstall.8; át fogja másolni a partíciós táblát mielõtt a /boot/boot0 állományt az MBR-be tenné. Ne másoljunk át csak úgy egyszerûen a /boot/boot0 állományt a /boot/boot1 helyett! Ezzel felülíródik a partíciós táblánk és így a számítógépet nem tudjuk elindítani! Amikor a &os; boot managere lefut, az utoljára indított operációs rendszert a partíciós táblában aktívként jelöli meg (ezzel lényegében megjegyzi), majd ezután beírja magát az MBR-be. Emiatt, hogy ha csak egyszerûen átmásoljuk a /boot/boot0 állományt a C:\BOOTSECT.BSD állományba, akkor csak egy egyetlen aktív bejegyzést tartalmazó üres partíciós táblát fog visszaírni az MBR-be. A LILO-ból hogyan lehet &os;-t és Linuxot is indítani? Ha a &os; és a &linux; is ugyanazon a lemezen helyezkedik el, akkor nincs más teendõnk, mint követni a LILO telepítési útmutatójában a nem-&linux; típusú operációs rendszerek indítására vonatkozó utasításokat. Ezek röviden összefoglalva a következõk: Indítsuk el a Linuxot és vegyük fel a következõ sort az /etc/lilo.conf állományba: other=/dev/hda2 table=/dev/hda label=&os; (A fentiekben feltételeztük, hogy a &os;-t tartalmazó slice a &linux; számára /dev/hda2 néven érhetõ el. Ez természetesen a saját konfigurációnkhoz kell szabni.) Ezután egyszerûen csak futtassuk le a lilo parancsot root felhasználóként és már készen is vagyunk. Ha a &os; egy másik lemezen található, akkor a loader=/boot/chain.b LILO-bejegyzést kell használnunk. Például: other=/dev/dab4 table=/dev/dab loader=/boot/chain.b label=&os; Bizonyos helyzetekben elõfordulhat, hogy a &os; rendszertöltõjének át kell adnunk a meghajtó BIOS szerinti sorszámát, mert csak így tudjuk rendesen elindítani a második lemezrõl. Például, ha a &os; szerint a SCSI-lemezünk a BIOS-ban az 1-es lemez, akkor ezt kell megadnunk a &os; rendszertöltõjének: Boot: 1:da(0,a)/boot/kernel/kernel A &man.boot.8; beállítható úgy, hogy a rendszer indításakor automatikusan mindig ezt a beállítást használja. A &os; és &linux; együttes használatáról további részleteket a &linux;+&os; mini-HOWTO címû írásból tudhatunk meg. Hogyan lehet a GRUB használatával &os;-t és Linuxot is indítani? A &os;-t nagyon könnyû elindítani a GRUB segítségével. Ehhez csupán annyit kell tennünk, hogy felvesszük a következõ sorokat a GRUB konfigurációs állományába (/boot/grub/menu.lst, vagy bizonyos, például Red Hat-típusú rendszerekben a /boot/grub/grub.conf): title &os; 6.1 root (hd0,a) kernel /boot/loader Itt a hd0,a az elsõ lemezen található rendszerindító partícióra mutat. Ha a lemezen belül a slice számát is szeretnénk megadni, akkor írhatjuk így is: (hd0,2,a). Ha ezt nem adjuk meg, akkor a GRUB alapértelmezés szerint a lemezen levõ elsõ a partícióval rendelkezõ slice-ot keresi meg. Hogyan lehet a BootEasy használatával elindítani a &os;-t és a Linuxot? A LILO-t ne a Master Boot Recordba, hanem a linuxos partíciónk elejére telepítsük. Ezután a BootEasybõl már el tudjuk indítani a LILO-t. Abban az esetben is ezt javasoljuk, ha &windows; és &linux; is van a gépünkön, mivel így szintén egyszerûbb lesz elindítani a Linuxot, ha netalán valamikor újra kellene telepíteni a &windows;-t (ami viszont egy irigy operációs rendszer, mert nem tûr meg semmilyen más operációs rendszert maga mellett a Master Boot Recordban). A rendszerindításkor látható ??? hogyan írható át valami értelmesre? Ez az szabványos boot managerrel csak úgy lehet megoldani, ha újratelepítjük. A portok között viszont a sysutils kategóriában rengeteg olyan más boot managert találhatunk, amely tud ilyet is. Cserélhetõ lemezes meghajtókat hogyan lehet használni? Legyen az akár egy &iomegazip;, EZ drive meghajtó (esetleg egy floppy, ha így akarjuk használni), vagy éppen egy új merevlemez, miután már telepítettük és felismerte a rendszert, illetve behelyeztük a lemezt, kártyát vagy akármit, minden esetben szinte ugyanaz a teendõ. (Ez a válasz leginkább Mark Mayo ZIP GYIK címû írásán alapszik.) Ha tehát egy ZIP meghajtóról vagy floppylemezrõl beszélünk, amelyen egy DOS-os állományrendszer található, akkor azt parancssorból így érhetjük el, ha floppy: &prompt.root; mount -t msdosfs /dev/fd0c /floppy vagy így, ha egy gyári beállításokkal rendelkezõ ZIP-lemez: &prompt.root; mount -t msdosfs /dev/da2s4 /zip A többi lemez esetén a &man.fdisk.8; vagy a &man.sysinstall.8; segítségével nézzük meg, hogy milyen partíciók és hogyan találhatóak meg rajtuk. A következõ példákban egy da2 eszközként, vagyis egy harmadik SCSI-lemezként megjelenõ ZIP-meghajtót fogunk használni. Hacsak nem floppyval van dolgunk, illetve nem tervezzük másoknak is odaadni a cserélhetõ médiumot, akkor érdemes inkább BSD típusú állományrendszert telepíteni rá. Így támogatottak lesznek a hosszú állománynevek, és legalább egy kétszer gyorsabb és egy sokkal megbízhatóbb megoldást kapunk. Ehhez elõször is le kell szednünk a DOS-szintû partíciókat és állományrendszereket. Erre a célra egyaránt megfelel a &man.fdisk.8; vagy a &man.sysinstall.8;, illetve kisebb lemezek esetén valószínûleg nem is lesz szükségünk több operációs rendszer támogatására, így aztán közvetlenül is törülhetjük ezeket: &prompt.root; dd if=/dev/zero of=/dev/rda2 count=2 &prompt.root; disklabel -Brw da2 auto A &man.disklabel.8; vagy a &man.sysinstall.8; használatával ezután létre tudunk hozni BSD típusú partíciókat. Valószínûleg erre lesz szükségünk, ha lapozóállományt is tenni akarunk a lemezre, noha ennek nem sok értelme van például egy ZIP-meghajtó esetén. Végezetül hozzunk létre egy új állományrendszert. Itt most ez egész ZIP-lemezen egyetlen partíció lesz: &prompt.root; newfs /dev/rda2c Csatlakoztassuk: &prompt.root; mount /dev/da2c /zip Emellett még hasznos lehet felvenni hozzá egy sort az /etc/fstab állományba is (lásd &man.fstab.5;), így a jövõben elegendõ csak a mount /zip parancsot kiadnunk a csatlakoztatásához: /dev/da2c /zip ffs rw,noauto 0 0 Miért ad a rendszer Incorrect super block hibát CD-k csatlakoztatásánál? Fel kell világosítanunk a &man.mount.8; parancsot a csatlakoztatandó eszköz típusáról. Errõl a kézikönyv lézeres tárolóeszközökrõl szóló részében olvashatunk, innen is különösen a Adat CD-k használata címû szakaszt ajánljuk. Miért ad a rendszer Device not configured hibaüzenetet CD-k csatlakoztatásakor? Ez általában arra utal, hogy nincs CD a meghajtóban, vagy a meghajtó nem érhetõ el a buszon. Ezzel kapcsolatban a kézikönyv Adat CD-k használata címû szakaszát javasoljuk elolvasásra. Miért jelenik meg az összes nemzeti karakter helyén ?, amikor &os; alatt csatlakoztatunk egy CD-t? A CD-n valószínûleg a Joliet kiterjesztés használatával tárolják az állományok és könyvtárak adatait. Erre vonatkozóan a kézikönyvben a Lézeres tárolóeszközök (CD-k) létrehozása és használata címû rész elolvasását javasoljuk, különös tekintettel az Adat CD-k használata címû szakaszra. A &os; alatt készített CD-ket nem lehet más operációs rendszerekkel olvasni. Miért nem? Ez minden bizonnyal abból fakad, hogy nem egy ISO 9660 állományrendszert vettük fel rá, hanem közvetlenül maguk az állományokat. Olvassuk el a kézikönyvben a Lézeres tárolóeszközök (CD-k) létrehozása és használata címû fejezetet, de különösen a Nyers adat CD-k írása címû részt. Hogyan lehet lementeni egy adat CD tartalmát a merevlemezre? Errõl a kézikönyvben találunk hasznos információkat, azon belül is az Adat CD-k másolása címû szakaszban. A CD-kkel végezhetõ további mûveletekrõl a kézikönyv Lézeres tárolóeszközök (CD-k) létrehozása és használata címû részében találhatunk részletes útmutatásokat. Miért nem lehet audio CD-ket csatlakoztatni a mount paranccsal? Ha zenei CD-ket próbálunk meg csatlakoztatni, akkor például egy cd9660: /dev/acd0c: Invalid argument hibát fogunk kapni a rendszertõl. Ez azért történik, mert a mount parancs csak állományrendszerekkel használható. A zenei CD-ken viszont semmilyen állományrendszer nincs, egyszerûen csak maga az adat. Az olvasásukhoz olyan programra lesz szükségünk, amely képes zenei CD-kkel dolgozni, mint például az audio/xmcd port. Hogyan lehet többmenetes (multisession) CD-ket csatlakoztatni a mount paranccsal? A &man.mount.8; alapértelmezés szerint az CD-n található utolsó adatsávot (menetet, vagy sessiont) próbálja meg olvasni. Ha viszont egy korábbi menetet szeretnénk vele betöltetni, akkor erre használjuk a paranccsori paramétert. Erre a &man.mount.cd9660.8; man oldalon találhatunk különbözõ példákat. Hogyan képesek az egyszerû felhasználók floppykat, CD-ket és más egyéb cserélhetõ lemezes eszközöket használni? A normál felhasználók számára engedélyezni tudjuk az eszközök csatlakoztatását. Íme: root felhasználóként állítsuk be a vfs.usermount sysctl változót az 1 értékre: &prompt.root; sysctl -w vfs.usermount=1 A cserélhetõ eszközöket képviselõ eszközleírókra állítsuk be root felhasználóként a megfelelõ engedélyeket. Például a felhasználóknak így tudjuk engedélyezni az elsõ floppymeghajtó használatát: &prompt.root; chmod 666 /dev/fd0 Az operator csoportban levõ felhasználók pedig így fognak tudni CD-ket csatlakoztatni: &prompt.root; chgrp operator /dev/acd0c &prompt.root; chmod 640 /dev/acd0c Fel kell vennünk ezeket a módosításokat az /etc/devfs.conf állományba is, mivel csak így maradnak meg a következõ rendszerindítás után. Ehhez root felhasználóként a vegyük fel a megfelelõ sorokat az /etc/devfs.conf állományba. Például, ha a felhasználóknak engedélyezni akarjuk az elsõ floppymeghajtó használatát, akkor: # Bármelyik felhasználó képes floppykat csatlakoztatni. own /dev/fd0 root:operator perm /dev/fd0 0666 Így engedélyezhetjük az operator csoport tagjainak a CD-k csatlakoztatását: # Az operator csoport tagjai csatlakoztathatnak CD-ket. own /dev/acd0 root:operator perm /dev/acd0 0660 Végezetül tegyük a vfs.usermount=1 sort az /etc/sysctl.conf állományba, így a rendszer következõ indításakor is megmarad ez a beállítás. Most már mindegyik felhasználó képes csatlakoztatni a /dev/fd0 eszközleírón keresztül elérhetõ lemezt a saját könyvtárába: &prompt.user; mkdir ~/az-én-csatlakozási-pontom &prompt.user; mount -t msdosfs /dev/fd0 ~/az-én-csatlakozási-pontom A operator csoport tagjai is képesek most már az /dev/acd0c eszközleírón keresztül elérhetõ CD-ket csatlakoztatni a saját könyvtárukba: &prompt.user; mkdir ~/az-én-csatlakozási-pontom &prompt.user; mount -t cd9660 /dev/acd0c ~/az-én-csatlakozási-pontom Az eszközök leválasztása is hasonlóan egyszerû: &prompt.user; umount ~/az-én-csatlakozási-pontom A vfs.usermount engedélyezésével azonban együttjár némi biztonsági kockázat is. Az &ms-dos; formátumú lemezek csatlakoztatására ezért inkább a Portgyûjteményben található emulators/mtools csomagot javasoljuk. A példákban használt eszközneveket természetesen a konfigurációnknak megfelelõen meg kell változtatnunk. A du és a df parancsok eltérõ mennyiségû szabad helyet mutatnak. Mi okozza ezt? A válaszhoz meg kell értenünk a du és a df mûködését. A du végigmegy a könyvtárszerkezeten és megnézi, hogy mekkorák az egyes állományok, majd megjeleníti a végösszegüket. A df ezzel szemben egyszerûen csak lekérdezi az állományrendszertõl, hogy mennyi szabad hely maradt rajta. Ezek látszólag ugyanazt a módszer fedik, azonban miközben a könyvtár nélkül állományok befolyásolják a df parancsot, addig a du parancsot nem. Amikor egy program használ egy olyan állományt, amelyet eközben letörlünk, egészen addig létezni fog, amíg a program be nem fejezi a használatát. Ettõl függetlenül viszont az állomány azonnal eltûnik a könyvtárból. Ezt nagyon könnyen ki is tudjuk próbálni egy olyan programmal, mint például a more. Tegyük fel, hogy van akkora állományunk, amely elég nagy ahhoz, hogy feltûnjön a du és a df kimenetében. (Mivel manapság már nagyok a tárolóeszközök, ennek egy igen nagy állománynak kell lennie!) Ha letöröljük ezt az állományt, miközben a more paranccsal még használjuk, a more nem fog rögtön leállni és panaszkodni az állomány hiányára. Egyedül csak az állományhoz tartozó bejegyzés tûnik el a könyvtárból, így más program már nem tud hozzáférni. A du erre már azt mondja, hogy nem létezik — bejárta a könyvtárat és nem találta. A df szerint azonban még mindig ott van, hiszen az állományrendszer tudja, hogy a more parancsnak még szüksége van rá. Ahogy a more befejezte a dolgát, a du és a df által mutatott értékek ismét egyezni fognak. Azt sem szabad elfelejtenünk, hogy a Soft Updates használata esetén akár 30 másodpercet is várnunk kell, hogy a változtatásaink láthatóvá váljanak! Ez a helyzet nagyon gyakori webszerverek esetén. Sokan úgy állítanak be a &os; rendszerükön webszervert, hogy elfelejtik beállítani hozzá a naplók archiválását és váltását. Ilyenkor a hozzáférések naplózása gyorsan meg tudja tölteni a /var könyvtárat. Ekkor a rendszergazda törli az adott állományt, de a rendszer még mindig panaszkodik a szabad hely hiánya miatt. A webszerver leállítása és újraindítása ekkor segít felszabadítani az állományt, így az állományrendszerrõl is törlõdhet. Ennek megelõzésére használjuk a &man.newsyslog.8; programot. Hogyan lehet növelni a lapozóterületet? A kézikönyv Beállítás és finomhangolás címû fejezetében található egyik szakaszban olvashatunk errõl. A &os; miért látja kisebbnek a lemezeket mint amekkorának a gyártó mondja ezeket? A merevlemezek gyártói általában a gigabyte-okat egy milliárd byte-ként számolják, miközben a &os; pedig 1 073 741 824 byte-nak. Ez remekül megmagyarázza, hogy a &os; rendszerüzenetei között egy elméletileg 80 GB méretû lemez miért 76 319 MB-osnak jelenik meg. Emellett érdemes még tisztában lennünk azzal is, hogy a &os; (alapértelmezés szerint) fenntartja a lemezterület 8 százalékát. Hogyan lehet egy partíció 100 százaléknál is jobban megtelt? Az UFS partíciók egy részét (amely alapértelmezés szerint a teljes kapacitás 8 százaléka) az operációs rendszer fenntartja a saját és a root felhasználó számára. A &man.df.1; ezt a területet nem számolja a Capacity oszlopban megjelenõ értékhez, ezért tudja átlépni a 100 százalékos arányt. Sõt még azt is láthatjuk, hogy a blokkok számát jelzõ Blocks oszlopban megjelenõ érték mindig, általában pontosan 8 százalékkal nagyobb, mint a használt blokkokat jelzõ Used és a rendelkezésre álló blokkokat jelzõ Avail oszlopokban szereplõ értékek összege. A részleteket a &man.tunefs.8; man oldalon belül a opció bemutatásánál olvashatjuk. Rendszeradminisztráció Hol vannak a rendszerindítás beállításáért felelõs állományok? Az ezzel kapcsolatos beállítások elsõsorban az /etc/defaults/rc.conf állományban találhatóak (lásd &man.rc.conf.5;). A rendszer indításáért felelõs szkriptek, mint például az /etc/rc vagy az /etc/rc.d könyvtár tartalma (lásd &man.rc.8;) ezt használja. Ezt az állományt tilos közvetlenül szerkeszteni! Ha valamit meg akarunk változtatni az /etc/defaults/rc.conf állományban szereplõ beállítások közül, akkor ehelyett egyszerûen csak másoljuk le az /etc/rc.conf állományba és állítsuk be ott az értékét. Például, ha el akarjuk indítani a beépített névfeloldó szolgáltatást, a &man.named.8; démont, akkor ennyit kell tennünk: &prompt.root; echo named_enable="YES" >> /etc/rc.conf Ha helyi szolgáltatásokat akarunk futtatni, akkor tegyük a hozzátartozó szkripteket az /usr/local/etc/rc.d könyvtárba. Ezek a szkriptek legyenek végrehajthatóak és az alapértelmezett állománymóduk legyen 555. Hogyan lehet felhasználókat egyszerûen létrehozni? Használjuk a &man.adduser.8;, vagy bonyolultabb esetekben a &man.pw.8; parancsot. Felhasználókat törölni a &man.rmuser.8;, vagy amennyiben szükséges, a &man.pw.8; paranccsal tudunk. A crontab szerkesztése után miért jelennek meg a root: not found és a hozzá hasonló hibaüzenetek? Ilyen általában olyankor történik, amikor a rendszerszintû crontab állományt módosítjuk (/etc/crontab), majd a &man.crontab.1; használatával megpróbáljuk telepíteni: &prompt.root; crontab /etc/crontab Ezt nem így kell megoldani. A rendszerszintû crontab felépítése eltér a felhasználókhoz tartozó crontab állományokétól (a &man.crontab.5; man oldal szemlélteti részletesebben ezeket az eltéréseket), amelyet a &man.crontab.1; próbál meg ilyenkor telepíteni. Ha így csináltuk, akkor a crontab nem lesz több, mint az /etc/crontab hibás formátumú változata. Töröljük le: &prompt.root; crontab -r Legközelebb, amikor az /etc/crontab állományt módosítjuk, nem kell értesítenünk a &man.cron.8; démont, mivel magától észre fogja venni az elvégzett változtatásokat. Ha valamit napi, heti vagy havi rendszerességgel akarunk futtatni, akkor ehelyett inkább másoljuk be az /usr/local/etc/periodic könyvtárba, és hagyjuk, hogy a cron hívja meg a &man.periodic.8; parancson keresztül az összes többi rendszeresen elvégzendõ feladattal együtt. Ez a hiba egyébként onnan jön, hogy rendszerszintû crontab állomány esetén van még egy további mezõ, amely megadja, hogy az adott parancsot melyik felhasználóval kell futtatni. Az alapértelmezett rendszerszintû crontab állomány esetén ez mindenhol a root. Amikor ezt a crontab állományt a root crontab állományaként használjuk (amely nem ugyanaz, mint a rendszerszintû crontab), akkor a &man.cron.8; a root szót a végrehajtandó parancs részének fogja tekinteni, amely viszont nem létezik. Miért jelenik meg a you are not in the correct group to su root hibaüzenet, amikor a su paranccsal át akarunk váltani a root felhasználóra? Ez egy biztonsági megszorítás. Csak úgy tudunk átváltani a root felhasználóra (vagy bármilyen más olyan hozzáférésre, amely rendszeradminisztrátori jogosultságokkal rendelkezik), ha a wheel csoport tagjai vagyunk. Ha nem létezne ez a korlátozás, akkor a rendszerben szinte bárki képes lenne rendszeradminisztrátori jogosultságokat szerezni csupán úgy, hogy ha megszerzi valahogy a root jelszavát. Ennek a korlátozásnak köszönhetõen ez viszont már nem lesz feltétlenül helytálló. A &man.su.1; még a jelszót sem engedi megadni azoknak, akik nem tagjai a wheel csoportnak. Ha engedélyezni akarjuk valakinek a root felhasználóra váltást, akkor nincs más teendõnk, mint egyszerûen a hozzáadni a wheel csoporthoz. Az rc.conf állományban vagy valamelyik másik konfigurációs állományban rosszul adtuk meg a beállításokat, és nem lehet módosítani ezeket, mert így írásvédett lett az állományrendszer. Mi a megoldás? Indítsuk újra a rendszert és a rendszertöltõ parancssorában adjuk ki a boot -s parancsot, amivel így egyfelhasználós módba váltunk. Amikor meg kell adnunk a használni kívánt parancsértelmezõ nevét, egyszerûen csak nyomjuk le az Enter billentyût, majd a mount -urw / parancs kiadásával csatlakoztassuk újra írható módban rendszerindító állományrendszert. Emellett még valószínûleg a mount -a -t ufs paranccsal azokat az állományrendszereket is érdemes lesz csatlakoztatnunk, ahol a kedvenc szövegszerkesztõnk található. Amennyiben az érintett szövegszerkesztõ egy hálózati állományrendszeren található, akkor helyette használjunk egy helyben elérhetõ szövegszerkesztõt, például az &man.ed.1; programot, vagy manuálisan állítsuk be a hálózat elérését a hálózati állományrendszerek csatlakoztatásához. Ha a &man.vi.1; vagy &man.emacs.1; programokhoz hasonló teljes képernyõs szövegszerkesztõt akarunk használni, akkor elõtte nem árt a export TERM=cons25 parancsot sem kiadnunk, így a &man.termcap.5; adatbázisból elérhetõvé válnak az ehhez szükséges adatok. Miután megtettük ezeket a lépéseket, már a szokásos módon át tudjuk szerkeszteni az /etc/rc.conf állományt. A rendszermag indulása után közvetlenül megjelenõ üzenetekben találhatjuk meg azon sorok számait, amelyeket a rendszer nem tudott értelmezni. Miért nem sikerül beállítani a nyomtatót? Olvassuk el a kézikönyv nyomtatókkal foglalkozó részét, minden bizonnyal választ ad a legtöbb kérdésünkre. Bizonyos nyomtatókat azonban akkor tudunk használni, ha van hozzá meghajtónk. Ezeket gyakran csak WinPrinter néven emlegetik, amelyeket viszont a &os; nem támogat. Ha a nyomtatónk nem használható DOS vagy &windows; alatt, akkor valószínûleg egy ilyen WinPrinterrel van dolgunk. Ebben az esetben egyedül abban reménykedhetünk, hogy a print/pnm2ppa port támogatja. Hogyan lehet módosítani a rendszerünkhöz tartozó billentyûkiosztást? Olvassuk el a kézikönyv honosításssal foglalkozó részét, különös tekintettel a konzol beállításaira. Miért jelenik meg az unknown: <PNP0303> can't assign resources hibaüzenet a rendszer indulásakor? Erre a &a.current; címére postázott egyik levél adja meg a választ:
&a.wollman;, 2001. április 24. A can't assign resources üzenetek rendszerünkben olyan ISA eszközök jelenlétére utalnak, amelyekhez a rendszermagban PnP támogatást nem tartalmazó meghajtók tartoznak. Ilyenek többek közt a billentyûzetvezérlõk, a programozható megszakítás-vezérlõ chip és sok más alapvetõ elem a gépünkben. Ezek az erõforrások nem oszthatóak ki, mivel már valamelyik meghajtó használatba vette ezeket.
Miért nem mûködnek rendesen a kvóták? Elõfordulhat, hogy a rendszermag nem támogatja a kvóták használatát. Ha errõl lenne szó, akkor vegyük fel az alábbi sort a rendszermag konfigurációs állományába és fordítsuk újra: options QUOTA Ennek részleteit a kézikönyv kvótákkal foglalkozó részében találjuk. Az / állományrendszeren ne engedélyezzük a kvóták használatát. Tegyünk kvótaállományokat azokra az állományrendszerekre, ahol be akarjuk vezetni a használatukat, például: Állományrendszer Kvótaállomány /usr /usr/admin/quotas /home /home/admin/quotas … … A &os; tartalmazza a System V IPC alapeszközeit? Igen, a &os; a GENERIC típusú rendszermagban támogatja a System V típusú IPC megoldást, beleértve az osztott memória, az üzenetek és a szemaforok használatát. Ha saját rendszermagunk van, akkor az alábbi beállítások használatával engedélyezhetjük a használatukat: options SYSVSHM # az osztott memória engedélyezése options SYSVSEM # a szemaforok engedélyeze options SYSVMSG # az üzenetek kezelése Fordítsuk és telepítsük újra a rendszermagot. A sendmail helyett milyen más levelezõ szerver használható még? A sendmail a &os;-ben található alapértelmezett levelezõ szerver, de könnyen le tudjuk cserélni másikra (például amelyet a portok közül telepítettünk). A Portgyûjteményben több különbözõ levelezõ szerver is megtalálható, amelyek közül a mail/exim, mail/postfix, mail/qmail és a mail/zmailer portok a leginkább népszerûek. Szép dolog, hogy lehet válogatni a különbözõ megoldások között és hogy ilyen sok levelezõ szerver használható. Ezért lehetõleg a levelezési listákon ne kérdezzünk senkitõl olyat, hogy De a sendmail akkor most miért jobb, mint a qmail? Ha ilyen kérdéseink vannak, akkor elõször inkább olvassuk át az archívumokat. Szinte biztos, hogy már szinte az összes levelezõ szerver elõnyét és hátrányát kivesézték jó néhányszor. Elveszett a root felhasználó jelszava! Mit tegyünk? Ne essünk kétségbe! Indítsuk újra a rendszerünket egyfelhasználós módban. Ehhez gépeljük be a boot -s parancsot a rendszertöltõ Boot: parancssorában. Amikor a parancsértelmezõt kell megadnunk, egyszerûen csak nyomjuk le az Enter billentyût. Ekkor kapunk egy &prompt.root; parancssort. A mount -urw / parancs begépelésével csatlakoztassuk újra a rendszerindító partíciónkat írható módban, majd a mount -a paranccsal csatlakoztassuk az összes többi állományrendszert. Ezt követõen a passwd root parancs kiadásával változtassuk meg a root felhasználó jelszavát és a &man.exit.1; futtatásával folytassuk a rendszer indítását. Ha az egyfelhasználós módra váltás során a rendszer a root felhasználó jelszavát kérné, akkor az arra utal, hogy a konzol (/dev/console) az /etc/ttys állomány szerint insecure (nem biztonságos) típusú. Ebben az esetben szereznünk kell egy &os; telepítõlemezt, elindítanunk róla a rendszert, majd a &man.sysinstall.8; programban a Fixit menüponton keresztül indított parancsértelmezõben kiadni az elõbb említett parancsokat. Ha egyfelhasználós módban nem tudjuk csatlakoztatni a rendszerindító partíciót, akkor ennek könnyen az lehet az oka, hogy a partíciókat titkosították, ezért a megfelelõ kulcsok nélkül nem tudjuk elérni ezeket. Ez leginkább adott implementációtól függ. A &os;-ben elõforduló lemeztitkosításokkal kapcsolatban a kézikönyv ad bõvebb útmutatást. Hogyan akadályozható meg, hogy a ControlAltDelete billentyûkombináció újraindítsa a rendszert? Ha a &man.syscons.4; (vagyis az alapértelmezett) konzolt használjuk, akkor ehhez a következõ beállításokkal kell fordítanunk és telepítenünk egy rendszermagot: options SC_DISABLE_REBOOT Mindezt a rendszermag újrafordítása és a újraindítása nélkül is le tudjuk tiltani, ha beállítjuk az alábbi &man.sysctl.8;-változót: &prompt.root; sysctl hw.syscons.kbd_reboot=0 Az elõbb említett két módszer kizárja egymást. A &man.sysctl.8; változó nem létezik, ha a rendszermagot a SC_DISABLE_REBOOT beállítással fordítjuk újra. Ha viszont a &man.pcvt.4; konzolt használjuk, akkor a következõ konfigurációs beállítást kell megadnunk a rendszermag újrafordításakor: options PCVT_CTRL_ALT_DEL Hogyan lehet szöveges DOS állományokat &unix; formátumúra alakítani? Használjuk a következõ &man.perl.1; parancsot: &prompt.user; perl -i.bak -npe 's/\r\n/\n/g' állományok ahol az állományok az átalakítandó állományok. A konverzió helyben történik, illetve az eredeti állományokról .bak kiterjesztéssel létrejön egy biztonsági mentés. Erre a célra viszont ugyanígy megfelel a &man.tr.1; parancs is: &prompt.user; tr -d '\r' < dos-szöveges-állomány > unix-szöveges-állomány Ekkor a dos-szöveges-állomány lesz a DOS formátumú szöveges állomány, miközben a unix-szöveges-állomány fogja az eredményt tartalmazni. Ez valamivel gyorsabb a perl megoldásánál. Ez említett megoldásokon kívül a DOS szöveges állományait a Portgyûjteményben található converters/dosunix porttal is könnyedén át tudjuk alakítani. Ennek részleteit a hozzátartozó dokumentációból tudjuk meg. Hogyan lehet futó programokat név szerint leállítani? Lásd &man.killall.1;. A &man.su.1; miért írja folyton, hogy a felhasználó nincs a root ACL-jében? Ezt a hibát az elosztott hitelesítést végzõ Kerberos rendszer adja. Maga a probléma nem végzetes, viszont annál inkább idegesítõ. Ilyenkor vagy a kapcsolóval kell futtatni a &man.su.1; programot, vagy a következõ kérdésben megadottak szerint el kell távolítani a Kerberos alkalmazást. Hogyan távolítható el a Kerberos? A Kerberos úgy távolítható el a rendszerbõl, ha újratelepítjük a base terjesztés tartalmát. Ha CD-rõl telepítettük a rendszert, akkor csatlakoztassuk (most tegyük fel, hogy a /cdrom könyvtárba) és futassuk a következõ parancsot: &prompt.root; cd /cdrom/base &prompt.root; ./install.sh Másik lehetõség, ha hozzáadjuk a NO_KERBEROS beállítást a /etc/make.conf állományhoz és újrafordítjuk az alaprendszert. Mi történt a /dev/MAKEDEV állománnyal? A &os; 5.X és a késõbbi változatok már a &man.devfs.8; által felkínált automatikus megoldást alkalmazzák. Ilyenkor az eszközmeghajtók igény szerint hoznak létre eszközleírókat, és ezzel lényegében szükségtelenné teszik a /dev/MAKEDEV használatát. Hogyan lehet még több pszeudoterminált létrehozni? Ha sok telnet, ssh, X esetleg screen felhasználónk van, akkor könnyen elõfordulhat, hogy kifogyunk a pszeudoterminálokból. A &os; 6.2 és az azt megelõzõ változatokban alapértelmezés szerint 256 pszeudoterminál, a &os; 6.3 és késõbbi változatokban pedig 512 pszeudoterminál áll rendelkezésünkre. Szükség esetén további pszeudoterminálok is hozzáadhatóak a rendszerhez. Ehhez azonban módosítanunk kell a szabványos C függvénykönyvtárakat, a rendszermagot és az /etc/ttys állományt. Például a 1152 pszeudoterminál használatát teszi lehetõvé. Ez a konkrét javítás viszont csak a &os; 6.3 és késõbbi változatok esetén alkalmazható zökkenõmentesen. Hogyan lehet újraindítás nélkül az /etc/rc.conf tartalmát újraolvastatni és újraindítani az /etc/rc szkriptet? Váltsunk egyfelhasználós módba, majd vissza többfelhasználós módba. Konzolon ez így oldható meg: &prompt.root; shutdown now (Megjegyzés: nincs -r vagy -h!) &prompt.root; return &prompt.root; exit A -STABLE rendszer frissítésekor -BETAx, -RC vagy -PRERELEASE verzió jelenik meg! Mi történt? Röviden: Ez csak egy elnevezés. Az RC jelentése Release Candidate, vagyis kiadásra jelölt. Ez egy küszöbön álló kiadásra utal. A &os;-ben a -PRERELEASE elnevezés általában egyenlõ a kiadások elõtt bekövetkezõ kódfagyasztással. (Bizonyos kiadások esetén pedig a -BETA címkét a -PRERELEASE megjelöléshez hasonlóan használják.) Valamivel bõvebben: A &os; fejlesztésében a kiadások általában két helyrõl származnak. A nagyobb, ún. nullás kiadások, mint - például 6.0-RELEASE és 7.0-RELEASE, a + például 7.0-RELEASE és 8.0-RELEASE, a fejlesztési ág legfrissebb állapotából készülnek, amelyet gyakran csak -CURRENT néven emlegetnek. A kisebb kiadások, mint például a 6.3-RELEASE vagy az 5.2-RELEASE, az aktív -STABLE ágból származnak. A 4.3-RELEASE kiadástól kezdõdõen mindegyik kiadás saját ággal rendelkezik, amelyet elsõsorban olyanoknak ajánlunk, akiknek csak nagyon visszafogott változtatásokra van szükségük a rendszerben (ezek általában csak különbözõ biztonsági javításokat takarnak). Amikor a fejlesztõk készíteni akarnak egy újabb kiadást, az alapjául szolgáló fejlesztési ágon elvégeznek bizonyos mûveleteket. Ennek egy része a források befagyasztása. Amikor ez megkezdõdik, az ág neve megváltozik, és ezzel jelzik, hogy hamarosan kiadás készül belõle. Például, ha egy ág a 6.2-STABLE nevet viseli, akkor a 6.3-PRERELEASE névre vált arra az idõszakra, amíg tart a kódfagyasztás és lezajlik a kiadások megjelentetéséhez szükség további tesztelés. Hibajavítások ekkor továbbra is rakhatóak bele. Ahogy a források elérik a kiadáshoz szükséges szintet, az ág neve 6.3-RC-re vált, és ezzel jelzik, hogy a kiadás elõkészítése hamarosan befejezõdik. Az RC állapotban csak a legfontosabb hibákat keresik meg és javítják. Miután a kiadás (jelen esetünkben a 6.3-RELEASE kiadás) és a hozzátartozó ág elkészült, az ág neve ismét 6.3-STABLE lesz. A verziószámokról és a CVS-ben található különbözõ ágakról a Release Engineering címû cikkben olvashatunk (angolul). Az új rendszermag telepítése során a &man.chflags.1; program hibát jelez. Hogyan javítható ez a hiba? Rövid válasz: A rendszerünk valószínûleg nullánál nagyobb biztonsági szinten fut. Indítsuk újra a rendszerünket egyfelhasználós módban és úgy telepítsük a rendszermagot. A hosszabb válasz: A &os; nem engedi megváltoztatni a rendszerszintû állományjelzõket nullától a nagyobb biztonsági szinteken. A jelenleg érvényben levõ biztonsági szintet a következõ paranccsal lehet lekérdezni: &prompt.root; sysctl kern.securelevel A biztonsági szintet nem lehet csökkenteni. A rendszert egyfelhasználós módban kell újraindítani, mert csak úgy tudjuk újratelepíteni a rendszermagot. Másik lehetõségünk, ha átállítjuk a biztonsági szintet az /etc/rc.conf állományban és úgy indítjuk újra a rendszerünket. Az &man.init.8; man oldalán olvashatunk bõvebben a biztonsági szintek (securelevel) beállításáról, az rc.conf használatáról pedig az /etc/defaults/rc.conf állományból és a &man.rc.conf.5; man oldalon tudhatunk meg többet. A rendszeren nem lehet egyszerre egy másodpercnél többel megváltoztatni az idõt! Hogyan lehet megkerülni ezt a korlátozást? A rövid válasz: A rendszerünkben a biztonsági szintet (securelevel) minden bizonnyal egynél nagyobbra állították. Indítsuk újra a rendszert egyfelhasználós módban és változtassuk meg a dátumot. Egy hosszabb válasz: A &os; nem engedi egy másodpercnél többel megváltoztatni az idõt, ha az aktuális biztonsági szint értéke egy felett van. Ezt a következõ parancs kiadásával tudjuk ellenõrizni: &prompt.root; sysctl kern.securelevel A biztonsági szint futás közben nem csökkenthetõ. A dátum megváltoztatásához ezért a rendszert egyfelhasználós módban kell indítanunk, vagy az /etc/rc.conf állományban csökkentenünk kell a biztonsági szintet. Az &man.init.8; man oldalon olvashatunk részletesebben a biztonsági szintek mûködésérõl, illetve az /etc/defaults/rc.conf állományból és az &man.rc.conf.5; man oldalról tudhatunk meg többet az rc.conf mûködésérõl. Az rpc.statd parancsnak miért kell 256 MB memória? Nem, itt szó sincs semmiféle memóriaszivárgásról, és egyébként sem használ 256 MB memóriát. Az rpc.statd parancs egyszerûen csak kényelmi megfontolásokból iszonyatos mennyiségû memóriát képez le a címterébe. Ebben technikailag semmi kivetnivaló nincsen, ezzel egyedül a &man.top.1;, &man.ps.1; és a hozzá hasonló programokat zavarja meg egy kicsit. A &man.rpc.statd.8; tehát leképezi az állapotát rögzítõ állományt (amely a /var könyvtárban található a címterébe. Ilyenkor igyekszik egy kicsit elõre gondolkodni és felkészülni a megnövekedésére, ezért viszonylag nagy méretben hozza létre ezt a leképezést. Ezt nagyon jól megfigyelhetjük a forráskódjából is, ahol látszik, hogy a &man.mmap.2; függvényt a 0x10000000 értékkel hívja meg, tehát az 32 bites Intel architektúrán megcímezhetõ memória egytizenhatod részével, ami pontosan 256 MB. Miért nem törölhetõ az schg állományjelzõ? Rendszerünkben a biztonsági szint (securelevel) nagyobb nullánál. Próbáljuk meg csökkenteni az értékét és próbálkozzunk ismét. Ezzel kapcsolatban részletesebb információkat a a biztonsági szintekrõl szóló kérdésbõl vagy az &man.init.8; man oldalról tudhatunk meg. Az .shosts állományon keresztül alapértelmezés szerint miért enged hitelesíteni a legújabb &os; verziókban megtalálható SSH? A legújabb &os; verziókban azért nem tudjuk az .shosts állományon keresztül hitelesíteni magunkat, mert az &man.ssh.1; alapértelmezés szerint rendszeradminisztrátori jogok nélkül kerül telepítésre. Ezt a hibát többféle módon ki tudjuk javítani: Ha tartós megoldásra van szükségünk, akkor az /etc/make.conf állományban állítsuk az ENABLE_SUID_SSH változót a true értékre, majd fordítsuk újra az &man.ssh.1; programot (vagy futtassuk le a make world parancsot). Ha ideiglenesen akarjuk csak javítani, akkor az /usr/bin/ssh állomány engedélyeit root felhasználóként állítsuk a 4555 értékre a chmod 4555 /usr/bin/ssh parancs kiadásával. Ezután vegyük fel az ENABLE_SUID_SSH= true sort az /etc/make.conf állományt, így ez a változtatás a make world következõ futtatásakor is megmarad. Mi az a vnlru? A vnlru törli és szabadítja fel a rendszerben keringõ vnode-okat, amikor a rendszermagban elérik a kern.maxvnodes változó által beállított határt. Ez a rendszermagban futó szál többnyire csak tétlenül ül a háttérben, és csak olyankor lép mûködésben, amikor rengeteg memóriát használunk és éppen több tízezernyi apró állományhoz akarunk egyszerre hozzáférni. Mit jelentenek top parancs által megjelenített különbözõ memóriaállapotok? Active (Aktív): az utóbbi idõben használt lapok. Inactive (Inaktív): az utóbbi idõben nem használt lapok. Cache (Tárazott): (leginkább) azok a lapok, amelyeket még használnak, de gyakran azonnal újrafelhasználódnak (akár a régi, akár egy új hozzárendelésben). Egyes lapok az active állapotból közvetlenül a cache állapotba váltanak, ha tiszták (nem módosították), de ez az átmenet függ a házirendtõl, vagyis a VM alrendszer karbantartója által kiválasztott algoritmustól. Free (Szabad): effektív tartalom nélküli lapok, amelyek akár közvetlenül fel is használhatóak olyan esetekben, amikor a tárazott lapok erre nem alkalmasak. A szabad lapokat megszakításokban és a futó programokban is felhasználhatjuk. Wired (Rögzített): olyan lapok, amelyek a memória egy rögzített pontján foglalnak helyet. Ezeket többnyire a rendszermag használja, de speciális esetekben a programoknak is szükségük lehet rá. A lapok általában akkor kerülnek ki a lemezre (valamilyen VM alrendszerbeli szinkronizáció során), amikor inaktív állapotban vannak, de akár az aktív lapok is szinkronizálhatóak. Ez attól függ, hogy a processzor képes-e nyomkövetni a lapok módosítását, és némely helyzetekben elõnyös lehet a rendszer számára, ha annak megfelelõen szinkronizálja a VM lapjait, hogy azok aktívak vagy inaktívak. A legtöbb esetben itt egyszerûen csak egy olyan sort kell elképzelni, ahol a program számára viszonylag inaktív lapok találhatóak, amelyeket a rendszer tetszõlegesen a lemezre írhat. A tárazott lapok általában már eleve szinkronizáltak, nem leképzettek, közvetlenül a programok régi és új hozzárendelései használják ezeket. A szabad lapokat akár a megszakítások szintjén is lehet használni, miközben a tárazott vagy szabad lapokat a futó programokban érthetjük el. A tárazott lapok zárolása nem megfelelõ ahhoz, hogy megszakításokban is el lehessen érni ezeket. Vannak még bizonyos jelzések (például a foglaltságot vagy foglaltság mértékét jelzõ értékek), amelyek még hatással vannak a fentebb leírt szabályokra. Mekkora a rendelkezésre álló memória mérete? A rendelkezésre álló memóriának rengeteg típusa létezik. Ezek közül egyik az a memória, amely közvetlenül anélkül elérhetõ, hogy bármi mást ki kellene hozzá lapoznunk. Ennek a mérete nagyjából a tárazott és a szabad lapokat tároló sorok hosszával arányos (amelyet még a rendszer beállításaitól függõ további tényezõk is módosíthatnak). A rendelkezésre álló memória másik típusa a teljes VM terület mérete. Ezt nem olyan könnyû meghatározni, de leginkább a lapozóterület és a fizikai memória méretétõl függ. A rendelkezésre álló memória több más lehetséges megfogalmazása is létezik, de szinte teljesen felesleges beszélni róluk. Egyedül az a fontos, hogy a igyekezzünk mérsékelni a lapozást és mindig legyen elegendõ lapozóterületünk. Mi az a /var/empty? Nem lehet letörölni! A /var/empty könyvtárat az &man.sshd.8; program használja a privilégiumok elkülönítéséhez. A /var/empty könyvtárnak üresnek kell lennie, legyen a root tulajdonában és legyen rajta a schg állományjelzõ. Noha semmiképpen sem javasoljuk a könyvtár törlését, úgy tudjuk elvégezni, ha elõször az schg állományjelzõt töröljük róla. A &man.chflags.1; man oldalán olvashatunk ezzel kapcsolatban részletesebb információkat (azonban ne felejtsük el számításba venni az esetleges nehézségeket). Az X Window System és a virtuális konzolok használata Mi az X Window System? Az X Window System (vagy gyakran csak X11) a &unix; és &unix;-szerû operációs rendszereken, így többek közt a &os;-n is az egyik leginkább elterjedt ablakozórendszer. A The X.Org Foundation felügyeli az X protokoll szabványait, azok aktuális referencia implementációival együtt. Ezek hivatalos megnevezése Version 11 Release &xorg.version;, de ezt gyakran csak X11 néven rövidítik. Számos implementációja is elérhetõ több különbözõ architektúrára és operációs rendszerre. A protokoll szerver oldali funkcióit megvalósító programokat hivatalosan X szervereknek nevezik. &os; alatt milyen X implementációk használhatóak? Kezdetben a &os; alapértelmezett X implementációja az &xfree86; volt, amelyet a The XFree86 Project, Inc. tartott karban. Ez a változat volt használatban alapértelmezés szerint egészen a &os; 4.10 és 5.2 verziójáig. Habár eközben az &xorg; maga is karbantartotta a saját változatát, kizárólag csak referencia célokat használt és az évek során teljesen leromlott az állapota. 2004 elején azonban az XFree86 néhány korábbi fejlesztõje elhagyta a projektjüket, mivel nem értettek egyet bizonyos kérdésekben, például a forráskód ütemét, a jövõbeni irányokat és egyéb személyes konfliktusokat illetõen, és helyette közvetlenül az &xorg; kódját kezdték el fejleszteni. Ekkor az &xorg; hozzáigazította forrásait az utolsó &xfree86; kiadás forrásaihoz (XFree86 4.3.99.903), majd megváltoztatta a licencelését. és beolvasztott több, korábban külön karbantartott változtatást, aminek eredményeképpen végül megszületett az X11R6.7.0. Egy különálló, de velük együttmûködõ projekt, a freedesktop.org (vagy röviden csak fd.o) jelenleg is az eredeti &xfree86; források újraszervezésén dolgozik, aminek célja a napjainkban megjelenõ grafikus kártyák minél nagyobb mértékû kihasználása (és ezáltal a rendszer gyorsítása), a rendszer modularisabbá tétele (ezáltal a rendszer karbantarthatóságának javítása, ami a kiadások gyorsabb elõkészítését és könnyebb beállíthatóságát teszi lehetõvé). Az &xorg; a jövõben tervezi a freedesktop.org fejlesztéseit is átvenni. 2004 júliusától kezdõdõen a &os.current; változatban az &xfree86; helyett az &xorg; lett az alapértelmezett X implementáció. A &os;-ben azóta is alapból az &xorg; X11 implementációja található meg. A témával kapcsolatban a kézikönyv X11-rõl szóló fejezetében kaphatunk részletesebb felvilágosítást. Mégis miért vált szét a két X projekt? Ezt a kérdést ez a GYIK nem tudja megválaszolni. Ezzel kapcsolatban viszont érdemes elolvasnunk a különbözõ levelezési listák archívumait szerte az interneten. Keressünk rá a válaszra a kedvenc keresõnkben, de ezzel a kérdéssel ne a &os; levelezési listáit zavarjuk. Az is elképzelhetõ, hogy ennek a valós okait csak néhányan ismerik egész teljesen. A &os; miért az &xorg; változatát választotta alapértelmezettnek? Az &xorg; fejlesztõi azt ígérték, hogy gyorsabban fognak újabb verziókat kiadni, amelyek sokkal több újítást is fognak tartalmazni. Nos, amennyiben tényleg állják a szavukat, azzal mindenki jól jár. Emellett az õ változatuk továbbra is a hagyományos X licenc alatt érhetõ el, miközben az &xfree86; licence ettõl némileg eltér. Hogyan lehet használni az X-et? Amennyiben már egy meglévõ rendszerre szeretnénk telepíteni az X-et, úgy érdemes a x11/xorg metaportot választanunk, amely magától feltelepíti az összes szükséges komponenst, vagy egyszerûen telepítsük az &xorg; alkalmazást csomagból: &prompt.root; pkg_add -r xorg Emellett az &xorg; a &man.sysinstall.8; használatával is telepíthetõ: válasszuk a Configure (Beállítások), Distributions (Terjesztések), végül a The X.Org Distribution (Az X.Org terjesztés) menüpontokat. Az &xorg; sikeres telepítése után kövessük a kézikönyv X11 beállításával foglalkozó szakaszában leírtakat. Az X indításakor egy KDENABIO failed (Operation not permitted) hiba keletkezik, közvetlenül a startx parancs kiadása után. Mi lehet ezzel kezdeni? A rendszerünkön valószínûleg túlságosan magas a biztonsági szint (securelevel) értéke. Ilyenkor az X-et nem tudjuk elindítani, mivel a mûködéséhez szüksége van a &man.io.4; eszköz írására. Ezzel kapcsolatban az &man.init.8; man oldal ad részletesebb útmutatást. A kérdés tehát az, hogy mit kellene ezzel csinálni. Alapvetõen két lehetõségünk van: vagy visszaállítjuk a biztonsági szintet nullára (ezt általában az /etc/rc.conf állományon keresztül lehet megtenni), vagy az &man.xdm.1; programot még a rendszerindítás során elindítjuk (mielõtt a biztonsági szintet magasabbra állítanánk). A szolgál arról bõvebb információval, hogy miként tudjuk használni az &man.xdm.1; programot a rendszer indítása során. Miért nem mûködik X alatt az egér? Ha a &man.syscons.4; (vagyis az alapértelmezett konzol) meghajtót használjuk, akkor be tudjuk úgy állítani a &os;-t, hogy minden virtuális képernyõn látható legyen az egérkurzor. A &man.syscons.4; egy /dev/sysmouse nevû virtuális eszköz támogatásával igyekszik elkerülni azt, hogy összeakadjon az X-szel. A valós egértõl érkezõ összes eseményt a &man.moused.8; démon írja folyamatosan a &man.sysmouse.4; eszközre. Amennyiben az egerünket egy vagy több virtuális konzolon is használni akarjuk az X-szel együtt, akkor nézzük meg a válaszát és állítsuk be annak megfelelõen a &man.moused.8; démont. Ezt követõen nyissuk meg az /etc/X11/xorg.conf állományt és gondoskodjunk róla, hogy a következõ sorok feltétlenül szerepeljenek benne: Section "InputDevice" Option "Protocol" "SysMouse" Option "Device" "/dev/sysmouse" ..... Néhányan inkább a /dev/mouse eszközt szeretik használni X alatt. Ha mi is így akarjuk használni, akkor a /dev/mouse eszközhöz hozzunk létre egy szimbolikus linket a /dev/sysmouse eszközre (lásd &man.sysmouse.4;). Ezt úgy tudjuk megtenni, ha az /etc/devfs.conf állományba (lásd &man.devfs.conf.5;) felvesszük a következõ sort: link sysmouse mouse A link maga közvetlenül a &man.devfs.5; újraindításával keletkezik. Ehhez (root felhasználóként) a következõ parancsot kell kiadnunk: &prompt.root; /etc/rc.d/devfs restart X alatt lehet használni görgõs egeret? Igen. Jelezni kell az X-nek, hogy ötgombos egerünk van. Ezt úgy tudjuk megcsinálni, ha az /etc/X11/xorg.conf állományba felvesszük a Buttons 5 és ZAxisMapping 4 5 sorokat az InputDevice szakaszba. Vegyük például, hogy az /etc/X11/xorg.conf állományunkban a következõ InputDevice szakasz található. Egy példa &xorg; konfigurációs állomány <quote>InputDevice</quote> szakasza görgõs egerekhez Section "InputDevice" Identifier "Mouse1" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/sysmouse" Option "Buttons" "5" Option "ZAxisMapping" "4 5" EndSection Egy egyszerû példa <quote>.emacs</quote> állomány görgõs egerek (opcionális) használatához ;; görgõs egér (global-set-key [mouse-4] 'scroll-down) (global-set-key [mouse-5] 'scroll-up) Hogyan lehet távoli X szervereket elérni? Biztonsági okokból a szerver alapértelmezés szerint nem engedélyezi, hogy egy távoli géprõl ablakot lehessen nyitni rajta. Ha szükségünk lenne erre a lehetõségre, akkor nem kell mást tennünk, mint az X-et a paraméterrel indítani: &prompt.user; startx -listen_tcp Mi az a virtuális konzol és hogyan lehet belõle többet létrehozni? A virtuális konzolok röviden szólva arra alkalmasak, hogy egyetlen gépen is több párhuzamos munkamenetben tudjunk dolgozni, hálózat vagy X beállítása nélkül. Amikor a rendszer elindul, a rendszerüzenetek után általában egy bejelentkezõ képernyõ jelenik meg. Ekkor az elsõ virtuális konzolon keresztül tudjuk megadni a felhasználói nevünket és jelszavunkat, majd nekilátni a munkának (vagy éppen a játszadozásnak). Késõbb aztán elõfordulhat, hogy egy másik munkamenetet is szeretnénk elindítani, például elõkeresni az éppen használt program dokumentációját vagy elolvasni a leveleinket, amíg FTP-n keresztül letöltünk egy állományt. Ehhez nem kell mást csinálnunk, csak le kell nyomni az AltF2 (tartsuk lenyomva az Alt billentyût miközben megnyomjuk az F2 billentyût) billentyûkombinációt és máris egy másik virtuális konzolon találjuk magunkat! Ha innen vissza szeretnénk térni az elõzõ munkamenetbe, akkor nyomjuk le az AltF1 billentyûkombinációt. A frissen telepített &os; rendszerekben alapértelmezés szerint nyolc virtuális konzol engedélyezett. Az AltF1, AltF2, AltF3, stb. lenyomásával tudunk váltogatni köztük. Ha ennél többet szeretnénk egyszerre használni, akkor nyissuk meg az /etc/ttys állományt (lásd &man.ttys.5;) és a Virtual terminals részben vegyünk még fel a ttyv8 eszköz után továbbiakat, egészen a ttyvc eszközig: # Írjuk át az eredeti ttyv8 bejegyzést az /etc/ttys # állományban és engedélyezzük. ttyv8 "/usr/libexec/getty Pc" cons25 on secure ttyv9 "/usr/libexec/getty Pc" cons25 on secure ttyva "/usr/libexec/getty Pc" cons25 on secure ttyvb "/usr/libexec/getty Pc" cons25 on secure Akármennyit használhatunk belõlük. Ne felejtsük el azonban, hogy minél több virtuális terminálunk van, annál több erõforrásra lesz hozzájuk szükségünk. Ezt leginkább akkor érdemes megfontolni, ha 8 MB memóriánál kevesebbel rendelkezünk. Emellett még érdemes a secure értéket is az insecure értékre átállítani. Ha X szervert is akarunk futtatni, akkor legalább egy virtuális konzolt szabadon (vagy kikapcsolva) kell hagynunk a számára. Így tehát, ha mind a tizenkét funkcióbillentyûre szeretnénk elindítani egy-egy virtuális konzolt, nos, akkor nincs szerencsénk — ha X szervert is akarunk használni a gépen, akkor legfeljebb csak tizenegyet használhatunk belõlük. Az egyes konzolokat legegyszerûbben úgy tudjuk letiltani, ha kikapcsoljuk ezeket. Például, ha az elõbb említettek szerint tizenkét terminálunk van, és X-et akarunk futtatni, akkor a tizenkettedik terminál beállításait meg kell változtatnunk errõl: ttyvb "/usr/libexec/getty Pc" cons25 on secure erre: ttyvb "/usr/libexec/getty Pc" cons25 off secure Amennyiben a billentyûzetünkön csak tíz funkcióbillentyû található, elengedõ ennyi is: ttyv9 "/usr/libexec/getty Pc" cons25 off secure ttyva "/usr/libexec/getty Pc" cons25 off secure ttyvb "/usr/libexec/getty Pc" cons25 off secure (Ezeket a sorokat akár ki is törölhetjük.) Ezt követõen a legegyszerûbben (és egyben a legtisztábban) úgy tudjuk aktiválni a virtuális konzolokat, ha újraindítjuk a rendszerünket. Ha viszont nem akarjuk ezt feltétlenül megtenni, akkor állítsuk le az X szervert, majd (root felhasználóként) adjuk ki az alábbi parancsot: &prompt.root; kill -HUP 1 Fontos, hogy a parancs végrehajtás elõtt teljesen leállítsuk az X szervert, amennyiben az fut. Ha nem tesszük meg, akkor könnyen elõfordulhat, hogy a kill parancs hatására lemerevedik vagy megáll a rendszerünk. Hogyan lehet elérni a virtuális konzolokat X-bõl? A virtuális konzolokra a Ctrl Alt FN billentyûkombinációval lehet visszaváltani. Ennek megfelelõen tehát a Ctrl Alt F1 kombinációval az elsõ virtuális konzolra tudunk visszaváltani. Ahogy visszajutottunk a szöveges konzolra, az Alt Fn billentyûkombinációval a megszokott módon tudunk váltani köztük. Ha innen az X szerverre akarunk visszaváltani, akkor egyszerûen csak váltsunk arra a virtuális konzolra, ahol az X fut. Ha az X-et a paranccsorból indítottuk el (például a startx paranccsal), akkor az X nem arra a virtuális konzolra kapcsolódik automatikusan, amelyen a parancsot kiadtuk, hanem az utána következõ, használatban még nem levõ konzolra. Ha nyolc aktív virtuális terminálunk van, akkor az X a kilencediken fog futni, ezért ide az Alt F9 lenyomásával tudunk visszatérni. Hogyan indítható el az XDM a rendszer indításakor? Alapvetõen kétféle megközelítés létezik az &man.xdm.1; elindításával kapcsolatban. Az egyik megközelítés szerint az xdm parancsot az /etc/ttys állományból (lásd &man.ttys.5;) tudjuk megadni a megadott példa alapján, a másikban pedig egyszerûen az rc.local állományból (lásd &man.rc.8;) vagy a /usr/local/etc/rc.d könyvtárban megadható X szkripttel. Mind a kettõ ugyanazt képviseli, de vannak bizonyos helyzetek, ahol a kettõ közül csak az egyik mûködik. Az eredmény mind a két esetben azonos, hatásukra az X egy grafikus bejelentkezõ képernyõvel jelentkezik. A &man.ttys.5; módszernek van egy olyan elõnye, hogy pontosan megadja, melyik virtuális terminálon fog futni az X és a szerver elindítását az &man.init.8; programra bízza. Az &man.rc.8; használata esetén viszont könnyû leállítani az xdm programot, ha netalán valamilyen gondunk adódna az X szerver indításakor. Ha az &man.rc.8; állományból töltöttük be, akkor az xdm futtatásához semmilyen paramétert nem kell megadni (például, hogy démonként fusson). Az &man.xdm.1; azonban csak az összes &man.getty.8; elindulása után indítható, máskülönben a két program ütközni fog és a konzol nem tud létrejönni. Ezt a legkönnyebben úgy lehet megakadályozni, ha az xdm indítása elõtt várunk kb. 10 másodpercet a szkriptben. Amennyiben az /etc/ttys állományból adjuk ki az xdm parancsot, úgy továbbra is fennáll az &man.xdm.1; és a &man.getty.8; ütközésének veszélye. Ezt például úgy tudjuk elkerülni, ha felvesszük a megfelelõ virtuális terminál sorszámát a /usr/local/lib/X11/xdm/Xservers állományba: :0 local /usr/local/bin/X vt4 A fenti példában az X szervert a /dev/ttyv3 eszközre irányitjuk. A számozást azonban eggyel el kell tolnunk, mert míg az X szerver egytõl számozza a virtuális konzolokat, addig a &os; rendszermagja nullától. Az xconsole indításakor miért jelenik meg a Couldn't open console hibaüzenet? Ha az X-et a startx paranccsal indítottuk el, akkor a /dev/console eszközre nem állítódnak be a szükséges engedélyek, ezért az xterm -C és az xconsole parancsok nem fognak mûködni. Ez a konzolok engedélyeinek alapértelmezett beállítási módjától függ. Egy többfelhasználós rendszer esetén nem feltétlenül van szükségünk arra, hogy bármelyik felhasználó kedvére írhasson a rendszerkonzolra. Az &man.fbtab.5; állomány segítségével engedélyezni tudjuk azon felhasználók számára, akik a helyi gépen, virtuális konzolon keresztül jelentkeznek be. Dióhéjban az /etc/fbtab állományban (lásd &man.fbtab.5;) kell kivennünk a következõ sort a megjegyzésbõl: /dev/ttyv0 0600 /dev/console Ennek köszönhetõen bárki, aki az /dev/ttyv0 eszközön keresztül jelentkezik be a rendszerbe, el tudja érni a konzolt. Régebben egyszerû felhasználóként is el lehetett indítani az &xfree86; szervert. Most miért kell root felhasználóként indítani? Az X szerverek csak úgy képesek közvetlenül elérni a videokártyát, ha root felhasználóként futtatjuk ezeket. Az &xfree86; régebbi (3.3.6 elõtti) változatai az összes szervert úgy telepítették fel automatikusan, hogy a root felhasználó jogaival fussanak (setuid bittel). Ennek viszont megvan a maga nyilvánvaló biztonsági kockázata, hiszen az X szerverek általában nagy és bonyolult programok. Az &xfree86; újabb változatai azonban már pontosan ebbõl kifolyólag nem állítanak be setuid root bitet a szerverekre. Értelemszerûen az a megoldás nem fogadható el és nem is annyira biztonságos, hogy az X szervert root felhasználóként futtassuk. Kétféleképpen tudjuk egyszerû felhasználóként futtatni az X-et. Használhatjuk az xdm vagy más egyéb bejelentkeztetõ képernyõ (mint például a kdm) megoldását, vagy az Xwrapper programot. Az xdm egy grafikus bejelentkeztetésért felelõs démon. Általában a rendszer indításakor aktiválódik, feladata a felhasználók hitelesítése és a hozzájuk tartozó munkamenetek elindítása. Lényegében a &man.getty.8; és a &man.login.1; grafikus megfelelõje. Az xdm démonnal kapcsolatban még az &xfree86; dokumentációját, illetve a GYIK-ban ezt a kérdést érdemes elolvasnunk. Az Xwrapper az X szerverhez tartozó burkolóprogram (wrapper). Ez egy apró segédprogram, amely lehetõvé teszi az X szerver manuális indítását miközben igyekszik ügyelni a biztonságra is. Elvégez néhány alapvetõ ellenõrzést a paramétereken, és ha megfelelõnek találja ezeket, akkor elindítja a megfelelõ X szervert. Ha valamiért nem akarunk bejelentkeztetõ képernyõt indítani, akkor ezt pontosan nekünk találták ki! Ha telepítettük a teljes Portgyûjteményt, akkor a /usr/ports/x11/wrapper portban találjuk meg. Miért viselkednek furcsán a PS/2-es egerek X alatt? Valószínûleg az egér és az egérmeghajtó kiesett a szinkronból. Nagyon ritkán elõfordul, hogy a meghajtó hibásan szinkronizációs hibát jelez, és ekkor a rendszermag a következõ üzenetet küldi: psmintr: out of sync (xxxx != yyyy) Közben természetesen azt tapasztaljuk, hogy az egerünk nem mûködik rendesen. Ha ilyen történne velünk, akkor tiltsuk le a meghajtó szinkronizáció ellenõrzéséért felelõs rutinjait. Ezt úgy tudjuk megtenni, ha a meghajtónak beállítjuk a 0x100 értéket. Ehhez a rendszertöltõ parancssorában a kapcsolóval tudjuk behozni a UserConfig részt: boot: -c Ezután a UserConfig parancssorában gépeljük be a következõt: UserConfig> flags psm0 0x100 UserConfig> quit Miért nem mûködnek a MouseSystems által gyártott PS/2-es egerek? Kaptunk néhány visszajelzést arra vonatkozóan, hogy a MouseSystems által gyártott PS/2-es egerek bizonyos típusai csak abban az esetben mûködnek rendesen, ha nagy felbontású módban használjuk ezeket. Minden más esetben az egér néha fel-felugrik a képernyõ bal felsõ sarkába. Úgy tudjuk nagy felbontású módban használni az egerünket, ha a PS/2-es egérmeghajtónak a 0x04 beállítást adjuk meg. Ehhez a rendszertöltõ parancssorában gépeljük be a kapcsolót: boot: -c Ahogy bejön a UserConfig parancssora, gépeljük be a következõt: UserConfig> flags psm0 0x04 UserConfig> quit Az elõzõ részben olvashatunk egy másik hasonló egeres problémáról. Hogyan lehet megcserélni a gombokat az egéren? Futtassuk le a xmodmap -e "pointer = 3 2 1" parancsot az .xinitrc vagy .xsession állományunkból. Hogyan lehet betöltõképet telepíteni és hol találhatóak ilyen képek? Erre a kérdésre részletes választ a &os; kézikönyv Rendszerbetöltõ képernyõk címû szakaszában kapunk. X alatt lehet használni a billentyûzeten található Windows billentyûket? Igen. Ehhez mindössze az &man.xmodmap.1; használatával meg kell adni a hozzájuk tartozó funkciót. Feltéve, hogy mindegyik Windows billentyûzet szabványos, a következõ billentyûkódok tartoznak ehhez a három plusz gombhoz: 115 — Windows billentyû, a bal oldali Ctrl és Alt billentyûk között 116 — Windows billentyû, az AltGr mellett jobbra 117 — Menü gomb, a jobb oldali Ctrl mellett balra Például így lehet beállítani a bal oldali Windows billentyût vesszõre: &prompt.root; xmodmap -e "keycode 115 = comma" A változatatások valószínûleg csak akkor fognak életbelépni, ha újraindítjuk az ablakkezelõnket. Ha azt szeretnénk, hogy a Windows billentyûkhöz rendelt funkciók az X indításakor automatikusan beállítódjanak, akkor tegyük az xmodmap parancs hívását az ~/.xinitrc állományunkba. Sokkal jobban járunk viszont, ha ehelyett inkább az ~/.xmodmaprc állományunkba vesszük fel az xmodmap beállításait, soronként egyesével, és a következõ sor tesszük az ~/.xinitrc állományunkba: xmodmap $HOME/.xmodmaprc Például ezeket a gombokat be lehet állítani az F13, F14 és F15 billentyûkre is. Ezekre aztán az alkalmazásokban vagy az ablakkezelõben további hasznos funkciókat tudunk beállítani. Ehhez a következõt kell megadnunk az ~/.xmodmaprc állományban: keycode 115 = F13 keycode 116 = F14 keycode 117 = F15 Ha például az x11-wm/fvwm2 ablakkezelõt használjuk, akkor az F13 gombra be tudjuk állítani a kurzor alatt álló ablak lekicsinyítésére (vagy visszanagyítására); az F14 billentyûvel az elõtérbe tudjuk hozni a kurzor alatt levõ ablakot, vagy ha már elöl van, akkor hátra tudjuk rakni; az F15 gomb elõhozza a munkakörnyezet (alkalmazás) menüjét még olyankor is, amikor a kurzor nincs is az asztalon. Ez utóbbi abban az esetben lehet hasznos, amikor az asztal egyáltalán nem látható (és a billentyûn látható rajz pontosan is ezt mutatja). A következõ beállítások valósítják meg az imént említett funkciókat az ~/.fvwmrc állományon belül: Key F13 FTIWS A Iconify Key F14 FTIWS A RaiseLower Key F15 A A Menu Workplace Nop Hogyan lehet hardveres 3D gyorsítást használni az &opengl;-hez? Az &xorg; pillanatnyilag használt verziójától és a videokártyánktól függ, hogy tudunk-e 3D gyorsítást alkalmazni. Ha nVidia kártyánk van, akkor a portok közül telepíteni tudjuk a &os;-hez készített bináris meghajtót: A legújabb nVidia-kártyákat az x11/nvidia-driver port támogatja. A GeForce2 MX/3/4 sorozatú nVidia-kártyákat a meghajtó 96XX változata támogatja, amely az x11/nvidia-driver-96xx portból telepíthetõ. Az ettõl is régebbi kártyák, például a GeForce vagy Riva TNT esetén a meghajtó 71XX változata javasolt, amely az x11/nvidia-driver-71xx porton keresztül érhetõ el. Az nVidia honlapján részletes leírást találhatunk arról, hogy melyik kártyát melyik meghajtó ismeri. Ez az információ a következõ címen érhetõ el: . A Matrox G200/G400 esetén az x11-servers/mga_hal portot érdemes megnéznünk. ATI Rage 128 és Radeon kártyák számára a &man.ati.4x;, &man.r128.4x; és &man.radeon.4x; man oldalakat ajánljuk. 3dfx Voodoo 3, 4, 5 és Banshee kártyák számára az x11-servers/driglide port áll rendelkezésre. Hálózatok Honnan lehet többet megtudni a lemez nélküli mûködésrõl? A lemez nélküli mûködés kifejezés arra utal, hogy a &os; rendszerünk hálózaton keresztül indul el, valamint a mûködéséhez szükséges állományokat nem merevlemezrõl, hanem egy szerverrõl olvassa be. Ennek részleteirõl kézikönyv lemez nélküli mûködésrõl szóló részében olvashatunk. A &os; használható kizárólag csak hálózati útválasztóként? Igen. Ezzel kapcsolatban a kézikönyv Egyéb haladó hálózati témák címû fejezetét javasoljuk elolvasásra, különös tekintettel az útválasztás és az átjárók bemutatására. &os;-n keresztül lehet &windows; operációs rendszerrel internetre csatlakozni? Ezt a kérdést általában olyanok teszik fel, akiknek két számítógépük van otthon, és ezek közül az egyiken a &os;, a másikon pedig a &windows; valamelyik változata fut. A &os; rendszer fog az internethez csatlakozni, és ezen keresztül szeretnénk a windowsos géprõl is elérni azt. Ez tulajdonképpen az elõzõ kérdés egy speciális esete, és remekül megoldható. Ha betárcsázós kapcsolattal csatlakozunk az internethez, akkor érdemes tudnunk, hogy a felhasználói módban futó &man.ppp.8; tartalmaz egy kapcsolót. A &man.ppp.8; programot úgy tudjuk a kapcsolóval futtatni, ha az /etc/rc.conf állományban a gateway_enable beállítást a YES értékre állítjuk. Ezután állítsuk be a windowsos gépünket ennek megfelelõen és minden mûködni fog. A további részletekrõl a &man.ppp.8; man oldalán vagy a kézikönyv felhasználói PPP-rõl szóló bejegyzésében olvashatunk. Amennyiben rendszerszintû PPP-t használunk vagy Ethernettel csatlakozunk az internethez, akkor a &man.natd.8; démonra lesz szükségünk. Erre vonatkozóan a kézikönyv natd démonról szóló szakaszában találhatunk részletesebb információkat. A &os; támogatja a SLIP és a PPP használatát? Igen. Érdemes elolvasnunk az &man.slattach.8;, &man.sliplogin.8;, &man.ppp.8; és &man.pppd.8; man oldalakat. A &man.ppp.8; és a &man.pppd.8; egyaránt támogatja a beérkezõ és kimenõ kapcsolatokat, miközben a &man.sliplogin.8; kizárólag csak beérkezõ kapcsolatokkal dolgozik, valamint a &man.slattach.8; pedig csak kimenõ kapcsolatokkal. Ezek pontos használatáról olvassuk el a kézikönyv PPP-rõl és a SLIP-rõl szóló fejezetét. Ha viszont csak egy shellen keresztül érjük el az internetet, akkor hasznos lehet megnéznünk a net/slirp csomagot. Segítségével a helyi géprõl (korlátozott módon) hozzá tudunk férni különbözõ FTP és HTTP szolgáltatásokhoz. A &os; támogat hálózati címfordítást (NAT) vagy maszkolást? Igen. Ha egy felhasználói PPP kapcsolat esetén szeretnénk hálózati címfordítást alkalmazni, akkor olvassuk el a kézikönyv felhasználói PPP-vel foglalkozó részét. Ha viszont más típusú hálózati kapcsolatok esetén kívánunk címfordítást használni, akkor ahhoz a kézikönyv natd démonnal kapcsolatos részét kell fellapoznunk. A PLIP segítségével hogyan tudok két &os; rendszert összekapcsolni párhuzamos porton keresztül? Ezt illetõen a kézikönyv PLIP-rõl szóló szakaszát érdemes megnéznünk. Hogyan lehet álneveket megadni az Ethernet eszközöknek? Amennyiben az álnév ugyanazon az alhálózaton található, mint a hozzátartozó interfész, akkor egyszerûen csak adjuk meg a netmask 0xffffffff paramétert az &man.ifconfig.8; parancs meghívásakor, például így: &prompt.root; ifconfig ed0 alias 192.0.2.2 netmask 0xffffffff Minden más esetben a hagyományos módon adjunk meg egy hálózati címet és egy hálózati maszkot: &prompt.root; ifconfig ed0 alias 172.16.141.5 netmask 0xffffff00 Errõl bõvebben a &os; kézikönyvben olvashatunk. A 3C503 kártya hogyan állítható másik hálózati portra? Ha a kártyán egy másik portot szeretnénk használni, akkor ahhoz meg kell adnunk egy további paramétert a &man.ifconfig.8; meghívásakor. Itt az alapértelmezett port a link0. Ha a BNC helyett az AUI portot akarjuk használni, akkor ennek a link2 értéket kell megadnunk. Az ilyen típusú beállítások az /etc/rc.conf állomány (lásd &man.rc.conf.5;) ifconfig_* változóival adhatóak meg. Miért okoz gondot az NFS használata &os; alatt? A személyi számítógépekben található bizonyos hálózati kártyák (szépen szólva) ügyesebbek a többieknél, ami az olyan komolyabb hálózati alkalmazások, mint például az NFS esetén gondokat okozhat. Ezzel kapcsolatban kézikönyv NFS-rõl szóló részét érdemes megnéznünk. Miért nem lehet hálózati állományrendszereket csatlakoztatni &linux; alól? A &linux; egyes változataiban található NFS kód csak bizonyos privilegizált portokról fogad el kéréseket. Próbáljuk meg a következõt: &prompt.root; mount -o -P linux:/valami /mnt Miért nem lehet hálózati állományrendszereket csatlakoztatni &sun; típusú rendszerek alól? A &sunos; 4.X változatait futtató munkaállomások csak privilegizált portokról fognak el kéréseket. Próbálkozzunk az alábbi paranccsal: &prompt.root; mount -o -P sun:/valami /mnt A mountd miért küld folyton can't change attributes hibaüzenetet és miért jelenik meg a bad exports list hibaüzenet a &os; alapú NFS szerveren? Ez leginkább azért történik, mert nem jól adtuk meg az /etc/exports állomány tartalmát. Olvassuk át a &man.exports.5; man oldalt és a kéziköny NFS-rõl szóló részét, különös tekintettel az NFS beállítására. A NeXTStep gépekkel miért nem sikerül PPP-n keresztül kommunikálni? Próbáljuk meg az /etc/rc.conf állományban (lásd &man.rc.conf.5;) kikapcsolni a TCP kiterjesztések használatát úgy, hogy az alábbi változót a NO értékre állítjuk: tcp_extensions=NO A Xylogic által gyártott Annex típusú gépek esetén is javasolt megtenni a fenti változtatást. Hogyan lehet engedélyezni a multicast használatát az IP-n belül? A &os; alapértelmezés szerint támogatja a multicast mûveleteket. Amennyiben egy multicast küldéseket közvetítõ útválasztót szeretnénk beállítani, akkor újra kell fordítanunk a rendszermagunkat a MROUTING beállítás használatával és elindítani a &man.mrouted.8; démont. Ez a démon úgy aktiválható a rendszer minden egyes indításakor, ha az /etc/rc.conf állományban az mrouted_enable változót YES értékûre állítjuk. A &os; újabb változataiban az &man.mrouted.8; multicast útválasztó démon, a &man.map-mbone.8; valamint az &man.mrinfo.8; segédprogramok már nem szerepelnek az alaprendszerben. Ezek a programok már a &os; Portgyûjteményében az net/mrouted portban találhatóak meg. Az MBONE használatához további eszközök találhatóak a külön mbone kategóriában a Portgyûjeményen belül. Ha a vic és vat nevû konferenciaszervezõ eszközöket keressük, akkor itt érdemes szétnéznünk! Milyen hálózati kártyák épülnek a DEC PCI chipkészletére? Glen Foster (gfoster@driver.nsta.org) a következõ listát állította össze róluk, amelyet kiegészítettünk még néhány további elemmel: A DEC PCI chipkészletére épülõ hálózati kártyák Gyártó Típus ASUS PCI-L101-TB Accton ENI1203 Cogent EM960PCI Compex ENET32-PCI D-Link DE-530 Dayna DP1203, DP2100 DEC DE435, DE450 Danpex EN-9400P3 JCIS Condor JC1260 Linksys EtherPCI Mylex LNP101 SMC EtherPower 10/100 (Model 9332) SMC EtherPower (Model 8432) TopWare TE-3500P Znyx (2.2.x) ZX312, ZX314, ZX342, ZX345, ZX346, ZX348 Znyx (3.x) ZX345Q, ZX346Q, ZX348Q, ZX412Q, ZX414, ZX442, ZX444, ZX474, ZX478, ZX212, ZX214 (10mbps/hd)
Miért kell teljes hálózati neveket megadni? Erre a &os; kézikönyvben találjuk meg a választ. Miért jelenik meg a Permission denied hibaüzenet minden egyes hálózati mûvelet esetén? Amennyiben a rendszermagot az IPFIREWALL beállítással fordítottuk le, akkor nem szabad elfelejtenünk, hogy ez alapértelmezés szerint minden olyan csomagot eldob, amelyet külön nem engedélyeztünk. Ha véletlenül rosszul állítottuk volna be a rendszerünkön futó tûzfalat, akkor a hálózat mûködését úgy tudjuk visszaállítani, ha root felhasználóként kiadjuk a következõ parancsot: &prompt.root; ipfw add 65534 allow all from any to any Az /etc/rc.conf állományban is megadhatjuk ehhez a firewall_type="open" sort. Ha a tûzfalak beállításáról szeretnénk többet megtudni &os; alatt, akkor olvassuk el a kézikönyv erre vonatkozó fejezetét. Az ipfw fwd szabálya miért nem irányít át más gépekre szolgáltatásokat? Valószínûleg azért, mert nem egyszerûen a csomagok továbbítására (forward) van szükségünk, hanem hálózati címfordításra. Az fwd szabály pontosan azt csinálja, amirõl a nevét kapta: csomagokat továbbít, de azokon belül semmit sem változtat meg. Tegyük fel, hogy van egy ilyen szabályunk: 01000 fwd 10.0.0.1 from any to ize 21 Amikor egy csomag az ize célcímmel megérkezik a 10.0.0.1 gépre, akkor benne a cél címe továbbra is az ize lesz! A csomag célcíme nem fog magától megváltozni a 10.0.0.1 címre. A legtöbb gép általában eldobja azokat a csomagokat, amelyeket nem egyenesen neki címeztek. Emiatt a fwd szabály használata nem minden esetben úgy mûködik, ahogy arra a felhasználó számít. Ez viszont ilyen, semmilyen hiba nincs benne. Részletesebb információkat a szolgáltatások átirányításával foglalkozó GYIK-ban, a &man.natd.8; man oldalán vagy a Portgyûjtemény valamelyik port átirányítással foglalkozó portjának dokumentációjában találhatunk. Hogyan lehet egyik géprõl a másikra szolgáltatásokat átirányítani? Az FTP (vagy más egyéb szolgáltatás-) kéréseket a Portgyûjteményen belül található sysutils/socket porttal tudunk átirányítani. Az adott szolgáltatás helyett egyszerûen csak adjuk meg a socket parancsot és annak paramétereit, valahogy így: ftp stream tcp nowait nobody /usr/local/bin/socket socket ftp.minta.com ftp ahol az ftp.minta.com az a gép, ahová át akarjuk irányítani a szolgáltatást, az ftp pedig a konkrét szolgáltatás. Hogyan lehet a sávszélességet szabályozni? &os; alatt alapvetõen három eszköz szolgál erre a célra. A &man.dummynet.4; a &os; részeként megtalálható &man.ipfw.4; egyik komponense. Az ALTQ a &os;-ben található &man.pf.4; rendszer része, az Emerging Technologies által fejlesztett Bandwith Manager pedig egy kereskedelmi termék. Miért jelenik meg a /dev/bpf0: device not configured hibaüzenet? Olyan programot akarunk futtatni, amelynek szüksége van a Berkeley Packet Filter (&man.bpf.4;) használatára, azonban a rendszermag ezt nem tartalmazza. Úgy tudjuk aktiválni, ha a rendszermag konfigurációs állományába felvesszük a következõ sort, majd fordítunk egy új rendszermagot: device bpf # Berkeley Packet Filter Hogyan lehet a hálózaton elérhetõ &windows; típusú partíciókat csatlakoztatni, mint ahogy az smbmount csinálja &linux; alatt? Erre az SMBFS eszközeit használhatjuk, amely tartalmazza az ehhez szükséges rendszermagbeli módosításokat és a hozzátartozó felhasználói programokat. Ezek a programok és a hozzájuk tartozó &man.mount.smbfs.8; man oldal az alaprendszer részei. Mik azok az Limiting icmp/open port/closed port response üzenetek a naplókban? Ilyen üzeneteket akkor kapunk a rendszermagtól, ha valaminek a hatására több ICMP vagy TCP reset (RST) választ küld, mint amennyit kellene. Az ICMP válaszok sokszor olyankor generálódnak, amikor használaton kívüli UDP portokat akarnak elérni a rendszerünkön. A TCP reset pedig általában olyankor keletkezik, amikor meg nem nyitott TCP porthoz akarnak csatlakozni. Többek közt ilyenek okozhatják: A rendszer túlterhelését célzó, nyers erõvel indított Denial of Service (Dos) támadások (ellentétben az egycsomagos, adott sebezhetõség kihasználó támadásokkal). A portok szisztematikus letapogatása, amelynek során egyszerre nagy mennyiségû portot próbálnak meg átvizsgálni (ellentétben azzal, amikor csak néhány jól ismert portot nyitnak meg). Az üzenetben olvasható elsõ szám azt mondja meg, hogy a rendszermag mennyi csomagot küldött volna, ha nem korlátoztuk volna, a második pedig magát a határt jelzi. Ezt a net.inet.icmp.icmplim sysctl változó segítségével tudjuk beállítani, ahogy például most megnöveljük az értékét 300-ra: &prompt.root; sysctl -w net.inet.icmp.icmplim=300 Amennyiben le szeretnénk tiltani az ilyen jellegû üzeneteket a naplókban, viszont még továbbra is szükségünk lenne a válaszküldés korlátozására, a net.inet.icmp.icmplim_output sysctl változó segítségével így tudjuk ezt megtenni: &prompt.root; sysctl -w net.inet.icmp.icmplim_output=0 Végezetül, ha teljesen ki akarjuk kapcsolni a válaszküldés korlátozását, akkor állítsuk a net.inet.icmp.icmplim sysctl változót (lásd az elõbbi példában) a 0 nulla értékre. A korlát törlése azonban a fenti okok miatt egyáltalán nem ajánlott. Mik azok az arp: unknown hardware address format hibaüzenetek? Ez arra utal, hogy valamelyik gép a helyi Ethernet-alapú hálózatunkon olyan MAC-címet használ, amelynek a &os; nem ismeri a formátumát. Valószínûleg olyankor kapjuk ezt a hibaüzenetet, amikor valaki más kísérletezik az Ethernet kártyája beállításaival valahol a hálózaton. Leggyakrabban kábelmodemes hálózatokon tapasztalhatunk ilyet. Megnyugodhatunk, teljesen veszélytelen, semmilyen hatással nincs a &os; gépünk teljesítményére. Miért jelennek meg 192.168.0.10 is on fxp1 but got reply from 00:15:17:67:cf:82 on rl0 üzenetek a konzolon és hogyan lehet ezeket kikapcsolni? Ilyen üzeneteket akkor kapunk, amikor a hálózaton kívülrõl érkezik hozzánk váratlanul egy csomag. A letiltásukhoz állítsuk a net.link.ether.inet.log_arp_wrong_iface értékét 0-ra. A CVSup programot telepítése után nem lehet elindítani, mert hibákat jelez. Mi a gond? Elõször is nézzük meg, hogy az iménti hibaüzenet mellett nem látunk-e valami hasonlót: /usr/libexec/ld-elf.so.1: Shared object "libXaw.so.6" not found Az ilyen jellegû hibák általában olyankor keletkeznek, amikor olyan gépre telepítjük a net/cvsup portot, amelyen viszont nem található meg a &xorg; programcsomag. Amennyiben szükségünk lenne CVSup programhoz mellékelt grafikus felületre, akkor kénytelenek leszünk mellé az &xorg; programjait is telepíteni. Ha viszont egyszerûen csak parancssorból szeretnénk használni a CVSup lehetõségeit, töröljük le a korábban telepített csomagot, majd helyette rakjuk fel a net/cvsup-without-gui vagy a net/csup portot. A &os; újabb változataiban megpróbálkozhatunk a &man.csup.1; használatával is. Ezzel a témával részletesebban a kézikönyv CVSup használatáról szóló része foglalkozik. Biztonság Mi az a járóka (sandbox)? A járóka alapvetõen egy biztonsági szakkifejezés. Két dolgot jelenthet: Egy virtuális falak között futó programot, melyeket azért emeltek a program köré, hogy a feltörését követõen megakadályozzák a rendszer többi részének elérését. A program csak a falon belül játszhat. Ilyenkor semmilyen olyan kódot nem képes futtatni, amellyel át tudna lépni a falakon, így a használatához nem kell elõzetesen átvizsgálni a forrásait ahhoz, hogy meg tudjuk gyõzõdni a biztonságosságáról. Ez a fal lehet például egy felhasználói azonosító. A &man.security.7; és &man.named.8; man oldalakon is ezt a definíciót találjuk meg. Vegyük például az ntalk szolgáltatást (lásd &man.inetd.8;). Ezt a szolgáltatást korábban a root felhasználó azonosítójával futtatták, de manapság viszont már a tty felhasználóval fut. A tty felhasználó lényegében egy olyan járóka, amely az ntalk szolgáltatás feltörésekor nem engedi, hogy a rendszer többi részéhez is hozzá lehessen férni. A valódi gépet utánzó rendszerben futó programot. Ez már egy sokkal kifinomultabb megoldás. Ha ilyenkor valakinek sikerül betörnie a programba, akkor könnyen azt hiheti, hogy sikerült a rendszer többi részét is elérnie, de valójában csak egy szimulált gépen van, és semmilyen valós adatot nem képes módosítani. Leggyakrabban ezt úgy szokták elérni, hogy egy könyvtárban létrehoznak egy szimulált környezetet, majd itt futtatják az adott programot a &man.chroot.8; segítségével. (Ekkor az iménti könyvtár lesz a gyökérkönyvtár az adott folyamat számára, nem pedig a rendszer igazi gyökere.) Másik szintén gyakori megoldás a használt állományrendszerek írásvédett csatlakoztatása, amely felett aztán kialakítanak a program számára egy látszólag írható réteget. Ilyenkor a program teljesen úgy érzékeli, hogy képes a rendszerben elérhetõ állományokat módosítani, azonban egyedül csak saját maga látja ezeket, a rendszerben futó többi program viszont nem feltétlenül. Ezeket a járókákat általában úgy szokták felépíteni, hogy a felhasználók (vagy a támadók) számára teljesen észrevétlenek legyenek. A &unix; két alapvetõ járókát valósít meg. Az egyik a futó programok, a másik pedig a felhasználói azonosítók szintjén mûködik. Futása közben minden &unix; program teljesen elszigetelt minden más &unix; programtól, így az egyik nem képes módosítani a másik memóriában tárolt adatait. A &windows;-tól eltérõen, ahol ugyebár az egyik program könnyedén el tudja érni egy másik memóriaterületét, ezért a program nem képesek egymásban kárt tenni. A &unix; alatt futó programok mindig egy adott felhasználóhoz tartoznak. Ha ez nem a root felhasználó, akkor azzal lényegében egy tûzfalat hozunk létre a különbözõ felhasználók által birtokolt folyamatok között. A felhasználók azonosítói emellett segítenek a lemezen tárolt adatokat is elszigetelni egymástól. Mi az a biztonsági szint (securelevel)? A biztonsági szintek egy rendszermagon belül megvalósított védelmi módszert képviselnek. A pozitív értékû biztonsági szintek esetén a rendszermag korlátoz bizonyos feladatokat, amelyeket ilyenkor még a rendszeradminisztrátor (vagyis a root felhasználó) sem képes elvégezni. Az írás pillanatában a biztonsági szintek, több más dolog mellett, a következõk szabályozására alkalmasak: a különbözõ állományjelzõk, például az schg (a system immutable jelzés) törlése; a rendszermag memóriájának elérése a /dev/mem és /dev/kmem eszközökön keresztül; a rendszermag moduljainak betöltése; a tûzfal szabályainak módosítása. A jelenleg futó rendszer biztonsági szintjét a következõ parancs segítségével lehet lekérdezni: &prompt.root; sysctl kern.securelevel A parancs eredménye az adott &man.sysctl.8; változó (vagyis esetünkben a kern.securelevel) és annak értéke lesz, amely egy szám. Ez utóbbi adja meg a biztonsági szint aktuális értékét. Amennyiben ez pozitív (vagyis nullánál nagyobb), akkor érvényben vannak a biztonsági szintekhez kapcsolódó bizonyos korlátozások. Egy mûködõ rendszer biztonsági szintjét nem lehet csökkenteni, hiszen ezzel tulajdonképpen hatástalanná tennénk. Ha olyan feladatot akarunk végrehajtani, amely nem pozitív biztonsági szintet igényel (például az alaprendszer frissítése vagy a dátum átállítása), akkor ahhoz elõször módosítanunk kell az /etc/rc.conf állományt (lásd kern_securelevel és kern_securelevel_enable változók), majd újraindítani a rendszert. A biztonsági szintekkel és rájuk vonatkozó információkkal kapcsolatban olvassuk el az &man.init.8; man oldalt. A biztonsági szintek nem feltétlenül jelentenek minden problémára tökéletes megoldást. Rentegeg ismert hátulütõvel rendelkeznek, és gyakran a biztonság hamis érzetét keltik. Ezzel kapcsolatban az egyik legnagyobb gond, hogy csak abban az esetben mûködik rendesen a rendszer, ha a rendszerindítás során a biztonsági szintek beállításáig minden állományt levédünk. Ha a támadó képes lefuttatni a saját programját még a biztonsági szint beállítása elõtt (amely viszont elég késõn történik meg, hiszen a rendszerindítás során számos olyan dolog feladat van, amely nem végezhetõ el magasabb biztonsági szinteken), akkor azzal az egész védelmi módszer hatástalanítható. Habár a rendszerindítás folyamán felhasznált állományok biztonságba helyezése technikailag egyáltalán nem lehetetlen, nehezebbé válik tõle a rendszer karbantartása, mivel ilyenkor az egész rendszert át kell állítanunk legalább egyfelhasználós módba és úgy módosítani a konfigurációs állományokat. Ezt és az ehhez hasonló problémák gyakran felmerülnek a levelezési listákon, különösen a &a.security; archívumaiban. Ezen a funkción keresztül nézhetünk után a téma részletesebb tárgyalásának. Néhányan reménykednek, hogy a biztonsági szinteket hamarosan leváltja valami sokkal finomabb beállítási lehetõségekkel rendelkezõ megoldás, azonban a dolgok még eléggé homályosak ebbõl a szempontból. Figyelmeztettünk mindenkit! A BIND (named) különféle nagyobb sorszámú portokat használ. Miért? A BIND a kimenõ kérésekhez véletlenszerûen kiválaszt egy nagyobb sorszámú portot. A legújabb változataiban már minden egyes kéréshez külön véletlenszerûen keres új UDP portot. Ez bizonyos hálózati konfigurációk esetén problémákhoz vezethet, különösen olyankor, amikor a beérkezõ UDP csomagokat egy tûzfal megállítja. A tûzfalak által blokkolt porttartományok használatát az avoid-v4-udp-ports vagy az avoid-v6-udp-ports beállítással tilthatjuk le a program számára. Ha ezt a portot (mint például az 53) az /etc/namedb/named.conf állományban a query-source vagy a query-source-v6 beállításokkal adjuk meg explicit módon, akkor a program nem fogja véletlenszerûen váltogatni a portokat. Határozottan javasoljuk, hogy ezekkel az opciókkal ne adjunk meg elõre rögzített portokat. Mindenesetre örülünk, hogy ezt is valaki megkérdezte! Hiába, nem árt néha nézegetni a &man.sockstat.1; kimenetét és észrevenni benne néhány furcsaságot. A sendmail a szabványos 25-ös port mellett az 587-es portot használja! Miért? A sendmail újabb verzióiban felfedezhetõ levélküldési lehetõségek az 587-es portot használják. Jelenleg ezt még nem sokan használják ki, de növekszik a népszerûsége. Kié az a nullás felhasználói azonosítójú toor fiók? Betörtek a gépre? Ne aggódjunk! A toor egy alternatív rendszergazdai hozzáférés (a toor a root visszafelé). Korábban csak a &man.bash.1; parancsértelmezõ telepítésekor jött létre, azonban manapság már alapértelmezés szerint létrejön. A nem szabványos parancsértelmezõk számára találták ki, így nem a root alapértelmezett parancsértelmezõjét kell megváltoztatnunk. Ez különösen olyan parancsértelmezõk esetén fontos, amelyek nem részei az alaprendszernek (például a portként vagy csomagként telepített parancsértelmezõk esetén) és ezért a /usr/local/bin könyvtárba fognak kerülni. Ez a könyvtár alapértelmezés szerint azonban egy külön állományrendszeren található. Ha a root parancsértelmezõje viszont a /usr/local/bin könyvtárban lenne, miközben a /usr (vagy bármelyik más állományrendszer, amely az imént említett könyvtárat tartalmazza) nem csatlakoztatható valamilyen oknál fogva, akkor a root nem lenne képes bejelentkezni és kijavítani a problémát. (Noha amikor újraindítjuk a rendszerünket egyfelhasználós módban, akkor a rendszer rá fog kérdezni, hogy melyik parancsértelmezõt akarjuk használni.) Egyesek nem szabványos parancsértelmezõn keresztül a toor felhasználóval végzik el a root mindennapi teendõit, így a szabványos parancsértelmezõt csak a vészhelyzetekre tartogatják. Alapértelmezés szerint a toor felhasználóval nem tudunk bejelentkezni, mivel nincs jelszava, ezért ha használni akarjuk, akkor elõször jelentkezzünk be a root felhasználóval, majd állítsunk be neki egy jelszót. A suidperl parancs miért nem mûködik rendesen? Biztonsági okokból a suidperl parancs alapértelmezés szerint nem kerül telepítésre. Ha forrásból frissítjük rendszerünket és azt szeretnénk, hogy ennek során a suidperl is leforduljon, akkor a perl fordításának megkezdése elõtt vegyük fel a ENABLE_SUIDPERL=true sort az /etc/make.conf állományba. PPP Nem mûködik a &man.ppp.8;. Mit lehet a gond? Elsõként mindenképpen olvassuk el a &man.ppp.8; man oldalt és a kézikönyv PPP-vel foglalkozó részét. A következõ paranccsal engedélyezzük a naplózást: set log Phase Chat Connect Carrier lcp ipcp ccp command Ezt a parancsot a &man.ppp.8; parancssorában vagy az /etc/ppp/ppp.conf konfigurációs állományban kell megadnunk (leginkább a default szakasz elejére érdemes betennünk). Gondoskodjunk róla, hogy az /etc/syslog.conf állomány (lásd &man.syslog.conf.5;) tartalmazza az alábbi sort, illetve az /var/log/ppp.log állomány létezzen: !ppp *.* /var/log/ppp.log A napló segítségével már több mindent ki tudunk deríteni a &man.ppp.8; mûködésérõl. Ne aggódjunk, ha nem értünk belõle semmit. Kérjünk segítséget másoktól, nekik minden bizonnyal segíteni fog a probléma felderítésében. A &man.ppp.8; miért bontja a vonalat, amikor elindul? Ilyen általában azért történik, mert nem tudta feloldani a hálózati nevet. Ezt a legkönnyebben úgy tudjuk orvosolni, ha az /etc/host.conf állományba elõre rakjuk a hosts sort, így a névfeloldó elõször az /etc/hosts állománnyal fog próbálkozni. Ezután a /etc/hosts állományba vegyük fel a helyi gépet. Ha nincs helyi hálózatunk, akkor így írjuk át a localhost sort: 127.0.0.1 ize.minta.com ize localhost Minden más esetben egyszerûen csak vegyünk fel egy újabb bejegyzést a gépünkhöz. Ennek pontosabb részleteivel kapcsolatban nézzük meg a megfelelõ man oldalakat. Ha mindent jól csináltunk, akkor a ping -c1 `hostname` parancs hiba nélkül tér vissza. A &man.ppp.8; miért nem tárcsáz -auto módban? Elõször is ellenõrizzük, hogy létezik az alapértelmezett útvonal. A netstat -rn parancs (lásd &man.netstat.1;) kiadása után nagyjából a következõ két bejegyzést kell látnunk: Destination Gateway Flags Refs Use Netif Expire default 10.0.0.2 UGSc 0 0 tun0 10.0.0.2 10.0.0.1 UH 0 0 tun0 Feltételezzük, hogy a kézikönyvbõl, a man oldalról vagy ppp.conf.sample állományból másoltuk ki ezeket a címeket. Ha nincs alapértelmezett útvonalunk, akkor annak az lehet az oka, hogy a ppp.conf állományba elfelejtettük felvenni a HISADDR kulcsszót. Az alapértelmezett útvonal hiányának másik oka lehet még, ha az /etc/rc.conf állományban (lásd &man.rc.conf.5;) beállítottunk egy alapértelmezett átjárót, de elfelejtettük az ppp.conf állományba betenni a következõ sort: delete ALL Ebben az esetben menjünk vissza a kézikönyv A rendszer végsõ beállítása címû részéhez. Mit jelent a No route to host hibaüzenet? Általában azért jelentkezik, mert az /etc/ppp/ppp.linkup állományban nem adtuk meg az alábbiakat: MYADDR: delete ALL add 0 0 HISADDR Erre csak akkor van szükségünk, ha dinamikus IP-címünk van, vagy nem ismerjük az átjáró címét. Ha az interaktív módot használjuk, akkor ehhez a következõket kell begépelni csomag módba lépés után (a csomag módot a csupa nagybetûs PPP jelzi a parancssorban): delete ALL add 0 0 HISADDR A kézikönyv A PPP és a dinamikus IP-címek címû részében olvashatunk errõl bõvebben. Miért szakad meg a kapcsolat 3 perc után? A PPP alrendszer alapértelmezett lejárati ideje 3 perc. Ezt a beállítást a következõ sor megadásával tudjuk módosítani: set timeout NNN ahol az NNN másodpercekben megadja a kapcsolat lezárása elõtti inaktivitás maximális idejét. Ha az NNN értéke nulla, akkor a kapcsolat idõtúllépés miatt soha nem fog magától megszakadni. Ezt a parancsot a ppp.conf állományba tudjuk felvenni, vagy interaktív módban a parancssorban gépelhetjük be. Emellett menet közben is állítani tudjuk ezt az értéket, ha a ppp szerverre a &man.telnet.1; vagy a &man.pppctl.8; segítségével rácsatlakozunk. Errõl a &man.ppp.8; man oldal ad részletesebb tájékoztatást. A kapcsolat miért szakad meg nagyobb terhelést alatt? Ha beállítottuk a Link Quality Reporting (LQR) használatát, akkor elõfordulhat, hogy túlságosan sok csomag veszik el a gépünk és a másik oldal között. A &man.ppp.8; ezért a vonalat rossznak érzékeli és bontja. A &os; 2.2.5 változata elõtt az LQR alapértelmezés szerint engedélyezett volt. Az LQR így tiltható le: disable lqr A kapcsolat miért szakad meg véletlenszerûen? Néha elõfordulhat, hogy a zajos telefonvonal esetén vagy a hívásvárakoztatás használatakor a modem bontja a vonalat, mivel (helytelenül) azt hiszi, hogy nincs kapcsolat. Manapság a legtöbb modemen általában be lehet valahogy állítani, hogy mennyire legyenek elnézõek a kapcsolat ideiglenes megszakadásával szemben. Például egy &usrobotics; &sportster; esetén ezt tizedmásodpercekben mérik az S10 regiszter segítségével. A modemünk ilyenkor tehát úgy tehetõ sokkal toleránsabbá, ha a következõ hívási beállítást adjuk: set dial "...... ATS10=10 OK ......" További részleteket a modem kézikönyvébõl tudhatunk meg. A kapcsolat miért fullad le véletlenszerûen? Sokan tapasztalják, hogy a kapcsolat minden különösebb magyarázat nélkül lefullad. Ilyenkor elsõként azt érdemes tisztázni, hogy az összeköttetés melyik oldalán történt a vonal bontása. Ha belsõ modemet használunk, akkor próbáljuk meg a &man.ping.8; paranccsal ellenõrizni, hogy a modem TD lámpája villog-e az adatok küldésekor. Amennyiben igen (miközben az RD lámpa viszont nem), akkor a gond a vonal másik végén lesz. Ha viszont a TD nem villog, akkor a probléma a mi oldalunkon áll fenn. A belsõ modemek esetében a ppp.conf állományban a set server parancsot is érdemes megadnunk, így amikor a kapcsolat leállását tapasztaljuk, a &man.pppctl.8; segítségével rá tudunk csatlakozni a &man.ppp.8; démonra. Ha a hálózati kapcsolat ekkor hirtelen erõre kapna (mivel rácsatlakoztunk kívülrõl) vagy egyáltalán nem tudunk csatlakozni (feltételezve, hogy a set socket parancs sikeresen lefutott az induláskor), akkor a probléma még mindig nálunk lesz. Ha viszont sikerül csatlakoznunk és a vonallal még mindig gondok vannak, akkor próbáljuk a set log local async parancs használatával engedélyezni a helyi aszinkron naplózást, majd egy másik konzolból a &man.ping.8; parancs segítségével kezdjük el használni az összeköttetést. Az aszinkron naplózás jelezni fogja, ha sikerül adatokat átvinni és fogadni a kapcsolaton keresztül. Ha ilyenkor nem látunk visszafele érkezõ adatokat, akkor az arra utal, hogy a gond a vonal távoli végén van. Miután sikeresen kiderítettük, hogy az adott probléma helyi vagy távoli, két lehetõségünk van: Amennyiben távoli, olvassuk el a válaszát. Amennyiben helyi, olvassuk el a válaszát. A vonal túlsó végérõl nem érkezik válasz. Mi lehet tenni? Ezzel szemben nagyon keveset tudunk mi, felhasználók tenni. A legtöbb internetszolgáltató egyszerûen nem hajlandó segítséget nyújtani abban az esetben, ha nem valamelyik µsoft; operációs rendszert használjuk. A ppp.conf állományunkban a enable lqr sor megadásával engedélyezni tudjuk a &man.ppp.8; számára, hogy észlelhesse a távoli hibákat és bontsa a vonalat, de ez a vizsgálat viszonylag idõigényes és ennélfogva nem túlságosan hasznos. A szolgáltatónknak pedig ne nagyon emlegessük, hogy felhasználói PPP-t futtatunk. Elõször próbáljunk meg letiltani mindenféle tömörítést a következõ sor megadásával: disable pred1 deflate deflate24 protocomp acfcomp shortseq vj deny pred1 deflate deflate24 protocomp acfcomp shortseq vj Kapcsolódjunk újra és ellenõrizzük, hogy továbbra is mûködõképes a kapcsolat. Ha ennek hatására javul a helyzet vagy a probléma teljesen megoldódik, akkor a beállítások egyenkénti próbálgatásával keressük meg, hogy melyik okozta a gondot. Ez már elegendõ lesz ahhoz, hogy komolyabban felvegyük a kapcsolatot a szolgáltatónkkal (habár ebbõl gyorsan ki fog derülni, hogy nem µsoft; terméket használunk). Mielõtt szólnánk a szolgáltatónknak, a gépünkön engedélyezzük az aszinkron naplózást és várjuk meg, amíg a kapcsolat újra megszakad. Erre nem árt felkészülnünk, mert viszonylag sok tárhelyet igényel. Innen majd a portról utoljára olvasott adat lesz a lényeges. Ez általában szöveges adat és akár a probléma konkrét okára is utalhat (Memory fault, Core dumped?). Ha segítõkész szolgáltatót választottuk, akkor a naplózást akár az õ oldalunkon is engedélyezhetjük, így amikor a vonal megszakad, az õ szemszögükbõl is képesek leszünk elemezni a problémát. Ilyen esetben nyugodtan küldjünk egy levelet &a.brian; címére vagy kérjük meg a szolgáltatónkat, hogy közvetlenül vele tárgyaljon. A &man.ppp.8; teljesen megállt. Mi lehet tenni? A legjobban úgy járunk, ha a &man.ppp.8; programot nyomkövetési információkkal fordítjuk újra, majd a &man.gdb.1; segítségével lekérünk egy hívási láncot az éppen megakadt ppp példánytól. A ppp alkalmazást a következõ parancsokkal tudjuk úgy újrafordítani, hogy tartalmazza a kívánt információkat: &prompt.root; gdb ppp `pgrep ppp` Ezt követõen a gdb parancssorában a bt és where parancsok segítségével hozzá tudunk jutni a hívási lánchoz. Mentsük el valahova a gdb által kinyert adatokat, majd a detach paranccsal váljunk le a futó programról és a quit begépelésével lépjünk ki a gdb programból. Végezetül az elmentett eredményeket küldjük el &a.brian; címére. Miért nem történik semmi a Login OK! üzenet után? A &os; 2.2.5 elõtti kiadásaiban a &man.ppp.8; az összeköttetés létrejötte után megvárta, hogy a távoli pont kezdeményezze a kapcsolatvezérlõ protokoll (Line Control Protocol, LCP) használatát. Sok szolgáltató azonban nem csinál ilyet, ehelyett inkább a klienstõl várják mindezt. Az LCP kezdeményezését így kényszeríthetjük ki a &man.ppp.8; használata során: set openmode active Általában semmilyen gond nem származik abból, ha a mind a két oldal kezdeményez, így az openmode alapértelmezés szerint active értékû. A következõ szakaszban azonban bemutatjuk mikor gondot okoz a használata. Folyamatosan Magic is same hibák jelennek meg. Ez mire utal? Csatlakozás után idõnként elõfordulhat, hogy magic is the same hibaüzeneteket látunk a naplóban. Ezek az üzenetek bizonyos esetekben teljesen ártalmatlanok, máskor viszont akár komolyabb problémákat is jelezhet. A legtöbb PPP implementáció nem él túl egy ilyen hibát, és még ha látszólag létre is jön ilyenkor a kapcsolat, folyamatosan konfigurációs kérések és válaszok jönnek-mennek a naplóban egészen addig, amíg a &man.ppp.8; végül fel nem adja és lezárja a kapcsolatot. Ez általában olyan szervereken jelenik meg, ahol nem elég gyorsak a lemezek és minden kapcsolathoz elindítanak egy &man.getty.8; és a bejelentkezéskor vagy azt következõ elindítják a &man.ppp.8; programot. Egyes visszajelzések szerint ilyen egyébként gyakran elõfordul a slirp használatakor. A problémát egyébként a &man.getty.8; és a &man.ppp.8; indítása között eltelt idõ okozza, amikor a kliens oldalán futó &man.ppp.8; elkezdi küldeni a kapcsolatvezérlõ (Line Control Protocol, LCP) csomagokat. Mivel ilyenkor az ECHO még mindig aktív a szerver adott portján, a kliens &man.ppp.8; a saját csomagjainak tükrözõdését fogja látni. Az LCP beállításának része az összeköttetés két oldalán egy-egy bûvös szám (magic number) megállapítása, amellyel ezután észlelhetõek az ilyen tükrözõdések. A protokoll szerint amikor a két pont megpróbálja ugyanazt a bûvös számot használni, akkor visszautasítja (NAK jelzést küld) és egy másikat választ. Ha ilyenkor még a szerver portján aktív az ECHO, akkor a kliens oldali &man.ppp.8; azt tapasztalja, hogy elkezd LCP csomagokat küldeni, majd mivel ugyanazt kapja vissza, erre egy NAK jelzést válaszol. Ugyanígy látja magát a NAK jelzést (aminek hatására a &man.ppp.8; megváltoztatja a bûvös számát) is. Ennek eredményeképpen hirtelen nagy mennyiségû bûvösszám-váltás keletkezik, ami pedig szépen felhalmozódik a szerver terminálpufferében. Ahogy a &man.ppp.8; végre elindul a szerveren, elönti ez a rengeteg információ, aminek alapján sikertelennek ítéli meg az LCP beállítását és feladja a további próbálkozást. Eközben a kliens számára megszûnnek a visszaverõdõ csomagok és csak annyit lát, hogy a szerver bontja a kapcsolatot. Ezt úgy tudjuk elkerülni, ha a ppp.conf állományban a távoli pontra bízzuk az beállítás kezdeményezését: set openmode passive Ennek hatására a &man.ppp.8; megvárja, hogy a szerver kezdeményezze az LCP beállítását. Egyes szerverek azonban sosem teszik meg ezt. Ilyenkor valami ilyesmit tudunk tenni: set openmode active 3 Így a &man.ppp.8; 3 másodpercig passzív marad, majd csak ezután kezd el LCP kérésket küldeni. Ha a távoli pont eközben küld valamilyen kérést, az &man.ppp.8; azonnal válaszol rá és nem várja végig a 3 másodperces idõtartamot. Az LCP beállítása egészen a kapcsolat befejezõdéséig folytatódik. Mi lehet a probléma? A &man.ppp.8; programban jelenleg van egy olyan hibásan implementált jellemzõ, ahol az LCP, CCP és IPCP válaszokat nem társítja az eredeti kérésekhez. Ennek következményeképpen, ha az egyik PPP implementáció 6 másodperccel lassabb a másik oldalnál, akkor az még két további LCP konfigurációs kérést is küld, ami viszont végzetesnek bizonyul. Vegyünk például két implementációt, az A és a B pontokat. Az A már közvetlenül a csatlakozás után LCP kéréseket kezd el küldeni, miközben a B csak 7 másodperc múlva tud elindulni. Mire végre a B pont is elindul, addigra az A már kiküldött 3 LCP kérést. Most feltételezzük, hogy nincs ECHO, máskülönben az elõzõ szakaszban leírt, bûvös számokkal kapcsolatos problémába ütköznénk. A B ekkor tehát küld egy kérést, majd nyugtázza az A ponttól kapott korábbi kérést. Ennek hatására az A pont OPENED állapotba megy át, újra küld és nyugtázza az elõzõ kérést B felé. Eközben a B további két nyugtázást küld az A pontról kapott további két kérésre, a B indulása elõttrõl. A B ekkor megkapja az A elsõ nyugtáját és átvált OPENED állapotba. Az A ekkor megkapja a második nyugtát a B ponttól és visszavált REQ-SENT állapotba, majd az RFC szerint elküld (elõre) egy újabb kérést. Ekkor megkapja a harmadik nyugtát és OPENED állapotba vált. Eközben a B megkapja elõre küldött kérést a A ponttól, amelynek hatására ACK-SENT állapotba vált vissza, és az RFC szerint ismét küld egy (második) kérést és egy nyugtázást. Az A erre megkapja a kérést, visszavált REQ-SENT állapotban és küld egy újabb kérést. Ekkor közvetlenül megkapja a rákövetkezõ nyugtázást és átvált OPENED állapotba. Ez egészen addig folytatódik, amíg az egyik oldal rá nem eszmél, hogy ennek nincs túlságosan sok értelme és feladja a próbálkozást. Ez legkönnyebben úgy kerülhetõ el, ha ilyenkor az egyik oldalt passive típusúra állítjuk, vagyis az egyik oldalon várunk egy keveset a beállítás kezdeményezésére. Ezt a következõ paranccsal lehet megoldani: set openmode passive Óvatosan bánjunk ezzel a paraméterrel! A beállítás kezdeményezésének várakoztatási idejét a következõ paraméterrel tudjuk megadni: set stopped N Használhatjuk viszont ezt a parancsot is (ahol N adja meg, hogy mennyi másodperc teljen el a beállítás megkezdése elõtt): set openmode active N Az ezzel kapcsolatos további részleteket a man oldalon olvashatjuk. Miért akad meg a &man.ppp.8;, ha egy külsõ parancsot adunk ki alatta? A shell vagy ! parancsok végrehajtásakor a &man.ppp.8; elindít egy parancsértelmezõt (illetve ha paramétereket is adtunk meg, akkor a &man.ppp.8; átadja azokat is), majd megvárja annak befejezõdését. Ha a parancs futtatása közben éppen egy PPP kapcsolatot akartunk használni, akkor erre az idõre az elõbbiek miatt látszólag meg fog állni. Ez tehát azért történik, mert a &man.ppp.8; megvárja a parancs lefutását. Ha nem akarjuk megvárni a parancs befejezõdését, akkor inkább használjuk a !bg parancsot. Ennek hatására az adott parancs a háttérben fog lefutni és a &man.ppp.8; képes lesz folyamatosan szemmel tartani az összeköttetést. A &man.ppp.8; null-modem kábel használatakor miért nem lép ki soha? A &man.ppp.8; ilyen esetekben nem képes magától megállapítani, hogy mikor bontották a vonalat. Ennek oka a tûk null-modem kábelben kiosztott szerepében keresendõ. Amikor ilyen típusú kapcsolattal dolgozunk, a következõ sor megadásával ne felejtsük el engedélyezni az LQR használatát: enable lqr Ha a távoli pont LQR csomagokat küld, akkor a &man.ppp.8; alapértelmezés szerint fogadja azokat. A &man.ppp.8; miért tárcsáz látszólag minden különösebb ok nélkül módban? Amennyiben a &man.ppp.8; szándékainkkal szemben váratlanul kezdene el tárcsázni, akkor keressük meg kiváltó okát és használjunk hívási szûrést (Dial filter, dfilter) ennek megelõzésére. A tárcsázás okát a következõ sor használatával tudjuk kideríteni: set log +tcp/ip Ennek hatására a kapcsolaton keresztüláramló összes forgalmat naplózni fogjuk. Így a legközelebb, amikor a vonal hirtelen aktív lesz, a hozzátartozó idõbélyegek alapján könnyen elõ tudjuk keresni, hogy pontosan miért is történt. Az automatikus tárcsázást bizonyos esetekben le tudjuk tiltani. Ez általában egy olyan probléma, amely a névfeloldások miatt keletkezik. Úgy tudjuk megakadályozni, hogy a névfeloldások felépítsék a kapcsolatot (ami viszont nem gátolja abban a &man.ppp.8; programot, hogy egy már meglevõ kapcsolaton keresztül küldjön ilyen csomagokat), ha az alábbi beállításokat adjuk meg: set dfilter 1 deny udp src eq 53 set dfilter 2 deny udp dst eq 53 set dfilter 3 permit 0/0 0/0 Ezek az értékek nem minden esetben megfelelõek számunkra, hiszen ezzel együtt az igény szerinti tárcsázás kényelmét is szûkítjük, mivel a legtöbb program közvetlenül névfeloldással kezd, mielõtt komolyabb hálózati forgalmat bonyolítana le. A névfeloldás esetében igyekezzünk kideríteni, hogy pontosan melyik program is próbál hálózati neveket feloldatni. Az esetek többségében valószínûleg a &man.sendmail.8; lesz a bûnös. Amennyiben ez a helyzet, akkor az sendmail démonnak a saját konfigurációs állományában kell beállítanunk, hogy ne oldasson fel hálózati neveket. Az érintett konfigurációs állomány módosításának pontos részleteirõl a kézikönyv Levelezés betárcsázós kapcsolattal címû szakszában olvashatunk bõvebben. Továbbá az .mc állományunkba a következõ sort is érdemes felvennünk: define(`confDELIVERY_MODE', `d')dnl Ezzel a sendmail beindításáig mindent egy sorban fog eltárolni (általában a sendmail démont a paraméterekkel szokták meghívni, ami arra utasítja, hogy 30 percenként dolgozza fel a sorát) vagy amíg a sendmail parancs le nem fut (például a ppp.linkup állományból). Mit jelentenek a CCP hibák? A naplóban folyamatosan a következõ üzeneteket lehet látni: CCP: CcpSendConfigReq CCP: Received Terminate Ack (1) state = Req-Sent (6) Ilyenek azért keletkeznek, mert a &man.ppp.8; a Predictor1 tömörítési eljárást próbálja meg beállítani, azonban a távoli pont egyáltalán semmilyen tömörítést nem akar használni. Az ilyen üzenetek többnyire ártalmatlanok, de ha el akarjuk tüntetni ezeket, akkor próbáljuk meg a következõ módon kikapcsolni a Predictor1 tömörítés használatát: disable pred1 A &man.ppp.8; miért nem naplózza a kapcsolat sebességét? A modemmel végzett teljes beszélgetés szövegének rögzítéséhez a következõket kell engedélyezni: set log +connect Ennek eredményeképpen a &man.ppp.8; egészen az utolsóként lekért karakterláncig naplóz mindent. Ha PAP vagy CHAP hitelesítést használunk (ezért a CONNECT parancs kiadása után már nincs semmi mondanivalónk a hívószkriptben, tehát nincs set login szkript), és szeretnénk látni a csatlakozási sebességet, ne felejtsük el utasítani a &man.ppp.8; programot, hogy a teljes CONNECT sort kérje le, valahogy így: set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 4 \ \"\" ATZ OK-ATZ-OK ATDT\\T TIMEOUT 60 CONNECT \\c \\n" Itt most megkapjuk a CONNECT sort, ezután nem küldünk semmit, majd várunk egy soremelést, aminek hatására a &man.ppp.8; arra kényszerül, hogy a teljes CONNECT választ beolvassa. A &man.ppp.8; miért hagyja figyelmen kívül a \ karaktereket a szkriptekben? A ppp a konfigurációs állományokból minden sort külön beolvas, ezért a set phone "123 456 789" és hozzá hasonló karakterláncok esetén képes felismerni, hogy a megadott számok valójában egyetlen paramétert formáznak. A " megadásához a visszaper karaktert (\) kell használnunk. Amikor tárcsázásért felelõs értelmezõ beolvassa az egyes paramétereket, újraértelmezi ezeket olyan speciális helyettesítési szekvenciák után kutatva, mint például a \P vagy \T (részletesebben lásd a man oldalon). A kettõs elemzés miatt nekünk is a megfelelõ számban kell megadnunk ezeket a helyettesítendõ karaktereket. Ha tehát egy \ karaktert szeretnénk átküldeni a modemünknek, akkor nagyjából valami ilyesmit kellene írnunk: set dial "\"\" ATZ OK-ATZ-OK AT\\\\X OK" Ennek az eredménye a következõ lesz: ATZ OK AT\X OK Vagy: set phone 1234567 set dial "\"\" ATZ OK ATDT\\T" Ez pedig a következõ szekvenciát adja: ATZ OK ATDT1234567 A &man.ppp.8; miért küld Segmentation Fault hibát, miközben nem is keletkezik ppp.core állomány? A ppp (vagy más hasonló program) elméletileg soha nem hoz létre .core állományt. Mivel a &man.ppp.8; tulajdonképpen a nullás felhasználói azonosítóval fut, az operációs rendszer soha nem fogja a &man.ppp.8; memórialenyomatát leállítása elõtt a lemezre menteni. Ha viszont &man.ppp.8; mûködése valóban leáll egy szegmentációs hiba vagy bármilyen más .core állományt eredményezõ jelzés miatt, és valóban a legfrissebb változatát használjuk (lásd a fejezet elejét), akkor a következõt tehetjük: &prompt.root; cd /usr/src/usr.sbin/ppp &prompt.root; echo STRIP= >> /etc/make.conf &prompt.root; echo CFLAGS+= >> /etc/make.conf &prompt.root; make install clean A fenti parancsokkal telepíteni tudjuk a &man.ppp.8; egy nyomonkövethetõ változatát. A &man.ppp.8; futtatásához root felhasználónak kell lennünk, mivel minden korábbi engedélyét felülírtuk az elõbbiek során. A &man.ppp.8; indításakor ne felejtsük el megjegyezni pontosan az aktuális könyvtárat sem. Innentõl kezdve, amikor a &man.ppp.8; kap egy szegmentációs hibára vonatkozó jelzést, létre fog hozni egy ppp.core nevû állományt. Ennek birtokában a következõt kell csinálnunk: &prompt.user; su &prompt.root; gdb /usr/sbin/ppp ppp.core (gdb) bt ..... (gdb) f 0 .... (gdb) i args .... (gdb) l ..... Az így beszerzett információkat mellékelve nagyobb valószínûséggel kaphatunk választ az ezzel kapcsolatos kérdésünkre. Ha járatosak vagyunk a &man.gdb.1; használatában, akkor a .core állományban további részletek és információk utáni is kutathatunk, például mi okozta a hibát, milyen változóknak ekkor milyen értékei voltak stb. Miért nem csatlakozik soha az a program, amely a hívást kezdeményezte módban? Ez korábban egy ismert probléma volt a &man.ppp.8; használatával kapcsolatban, amikor dinamikus helyi IP-címet akart beállítani módban. Ez a hiba az újabb változatokban már nem nincs meg (a man oldalon keressünk rá az iface részre). A gondot az okozta, hogy amikor a tárcsázást elindító program meghívja a &man.connect.2; rendszerhívást, akkor a &man.tun.4; interfészhez tartozó IP-cím a végpontot képviselõ sockethez társul. A rendszermag létrehozza az elsõ kimenõ csomagot és kiírja a &man.tun.4; eszközre. A &man.ppp.8; ekkor beolvassa a csomagot és felépíti a kapcsolatot. Ha a &man.ppp.8; dinamikus IP-cím kiosztásának eredményeképpen ilyenkor az interfész címe megváltozik, akkor azzal egyidõben az eredeti socket végpont érvénytelenné válik. Így a távoli végpont felé küldött további csomagok általában eldobódnak. Ha valahogy mégis eljutnának a céljukhoz, a válasz már semmiképpen sem érkezhet meg, mivel a küldéshez használt IP-címnek már nem az adott gép a tulajdonosa. Számos elméleti megközelítés létezik az imént felvázolt probléma megoldására. A legszebb az lenne, ha a távoli pont lehetõség szerint a korábban használt IP-címet osztaná ki újra. A &man.ppp.8; jelenlegi változata pontosan ugyanezt teszi, viszont a legtöbbi implementáció már nem. Részünkrõl az bizonyulna a legegyszerûbb megoldásnak, ha a &man.tun.4; intefész IP-címe egyáltalán nem változhatna meg, hanem helyette menet közben az összes kimenõ csomag, köztük természetesen a forrás IP-címe az interfész IP-címérõl az idõközben beállított IP-címre változna. Ez lényegében az, amit a &man.ppp.8; legújabb változataiban felbukkanó iface-alias opció is csinál (a &man.libalias.3; és a &man.ppp.8; kapcsolója segítségével): karbantartja az összes korábban használt interfész címét és átfordítja ezeket az utoljára beállított címre. A másik (és valószínûleg a sokkal megbízhatóbb) lehetõség egy olyan rendszerhívás implementálása lenne, amely képes az összes használatban levõ socketet egyik IP-címrõl a másik IP-címre átállítani. A &man.ppp.8; ekkor fel tudná használni ezt arra, hogy módosítsa az összes addig futó program socketjét az új IP-cím beállításakor. Ugyanezzel a rendszerhívással a DHCP kliensek is képesek lennének átállítani a socketjeiket. Lehetõségünk van még IP-cím nélkül is létrehozni interfészeket. A kimenõ csomagok ekkor a 255.255.255.255 IP-címet használnák egészen addig, amíg az elsõ SIOCAIFADDR &man.ioctl.2; rendszerhívás le nem zajlik. A &man.ppp.8; feladata ilyenkor a forrás IP-cím megváltoztatása, de ha ez 255.255.255.255, akkor egyedül csak az IP-címnek és az ellenõrzõösszegnek kell megváltoznia. Ez viszont már valamilyen mértékben trükközést a rendszermagon belül, mivel így könnyen tudunk csomagokat küldeni egy rosszul beállított interfészre is, feltételezve, hogy valamilyen módon képesek vagyunk ilyeneket visszamenõleg helyreállítani. A legtöbb játék miért nem mûködik a kapcsoló megadásával? A játékok és a hozzájuk hasonló alkalmazások általában azért nem mûködnek, amikor a &man.libalias.3; könyvtárat használjuk, mert a távoli gép megpróbál kapcsolódni a belsõ hálózatunkon levõ géphez és kéretlen UDP csomagokat kezd el küldeni neki. A címfordítást végzõ programnak fogalma sincs róla, hogy ezeket a csomagokat egy belsõ gépnek kell továbbküldenie. Akkor lehetünk biztosak ebben, ha egyedül csak azt a szoftvert indítjuk el, amellyel gondjaink akadtak, majd a vagy az átjáró &man.tun.4; interfészét kezdjük el a &man.tcpdump.1; segítségével, vagy pedig engedélyezzük az átjárón a &man.ppp.8; TCP/IP naplózó funkcióját (set log +tcp/ip). Ahogy elindítjuk a gondokat okozó programot, látnunk kell a csomagjait, ahogy megpróbálnak keresztüljutni az átjárón. Az erre érkezõ válaszolok eldobódnak (ez jelenti a problémát). Jegyezzük fel a csomagokhoz társuló portszámokat és állítsuk el a programot. Csináljuk meg néhányszor ezt a vizsgálatot, így ellenõrizni tudjuk, hogy mindig ugyanazokat a portokat használja-e. Amennyiben úgy tapasztaljuk, hogy igen, akkor az /etc/ppp/ppp.conf állományba a következõ sort kell betenni a megfelelõ helyre a mûködés helyreállításához: nat port protokoll belsõ-gép:port port ahol a protokoll lehet tcp vagy udp, a belsõ-gép annak a gépnek a címe, ahova tovább akarjuk küldeni a csomagokat, valamint a port a csomagok célportját adja meg. A fenti parancs megváltoztatása nélkül nem tudjuk ugyanezt a szoftvert más gépeken is használni, és itt azzal most nem is foglalkozunk, hogy miként lehet két belsõ géprõl használni ugyanazt a programot. Mindenesetre annyi biztos, hogy a külvilág felé a belsõ hálózatunk csupán egyetlen gépnek fog látszani. Ha azt látjuk, hogy az alkalmazás nem mindig ugyanazt a portot használja, akkor három választási lehetõségünk van: Készítsük el a támogatását a &man.libalias.3; függvénykönyvtárhoz. A különbözõ szélsõséges esetekre a /usr/src/sys/netinet/libalias/alias_*.c állományokban találhatunk példákat (az alias_ftp.c tökéletes kiindulási alap). Ez általában annyit jelent, hogy beolvasunk bizonyos ismert kimenõ csomagokat, beazonosítjuk benne azt az utasítást, amelynek hatására a külsõ gép csatlakozni próbál a belsõ géphez egy adott (véletlenszerûen választott) porton, majd beállítunk hozzá egy útvonalat, így a rákövetkezõ csomagok már tudni fogják, hogy merre menjenek. Ez ugyan a legnehezebb megoldás, de egyben ez is a legjobb, ráadásul így a szoftver több gépen is mûködtethetõ. Proxy használata. Elõfordulhat, hogy az alkalmazás támogatja a socks5 protokollt vagy (mint ahogy a cvsup is csinálja) rendelkezik passzív móddal, és így lehetõleg igyekszik elkerülni azt, hogy a távoli géprõl kapcsolatot próbáljanak meg indítani a helyi gépre. A nat addr használatával irányítsunk át mindent a belsõ gépre. Ez viszont egy nagyon durva megközelítés. Valaki összeírta már a hasznosabb portok sorszámait? Egyelõre még nem, de szándékunkban áll összeállítani egy ilyen listát (már amennyiben igény lesz rá). Minden itt szereplõ példában az belsõ helyett mindig annak a gépnek a belsõ IP-címét írjuk, amelyrõl játszani akarunk. Asheron's Call nat port udp belsõ :65000 65000 Manuálisan változtassuk meg a játékon belül a portszámot 65000-re. Ha a belsõ hálózatunkról több gépen is szeretnénk játszni, akkor mindegyiknek adjuk meg egy egyedi portot (vagyis 65001, 65002 stb.), majd vegyünk fel mindegyikhez egy-egy nat port sort. Half Life nat port udp belsõ:27005 27015 PCAnywhere 8.0 nat port udp belsõ:5632 5632 nat port tcp belsõ:5631 5631 Quake nat port udp belsõ:6112 6112 Quake 2 nat port udp belsõ:27901 27910 nat port udp belsõ:60021 60021 nat port udp belsõ:60040 60040 Red Alert nat port udp belsõ:8675 8675 nat port udp belsõ:5009 5009 Mik azok az FCS hibák? Az FCS jelentése Frame Check Sequence, vagyis az Adatkeret ellenõrzésének sorozata. Mindegyik PPP csomaghoz tartozik egy ellenõrzõösszeg, amely arról gondoskodik, hogy ugyanaz az adat érkezzen meg, mint amit elküldtek. Amennyiben egy bejövõ csomag FCS értéke érvénytelennek minõsül, a csomag eldobódik és a HDLC FCS számláló értékkel eggyel növekszik. A HDLC hibaszámlálói a show hdlc parancs segítségével tekinthetõek meg. Ha rosszul mûködik az összeköttetés (vagy a soros vonali meghajtónk folyamatosan eldobja a csomagokat), akkor láthatunk helyenként FCS hibákat. Többnyire nem érdemes az ilyenek miatt aggódni, habár ez jelentõs mértékben lassítja a tömörítést végzõ protokollok munkáját. Ha külsõ modemünk van, akkor ne felejtsük el a megfelelõ módon leárnyékolni, mivel ebbõl is származhat a probléma. Ha a vonal a kapcsolódást követõen szinte azonnal lemerevedik és hirtelen nagy mennyiségû FCS hiba jelentkezik, akkor az arra is utalhat, hogy az összeköttetés nem tisztán 8 bites. Gondoskodjunk róla, hogy a modem ne a szoftveres forgalomirányítást (XON/XOFF) használja. Ha viszont az adatok közvetítéséhez mégis szoftveres forgalomirányítást kell használnunk, akkor a set accmap 0x000a0000 parancs kiadásával jelezzük a &man.ppp.8; felé, hogy a ^Q és ^S karaktereket helyettesítse. Nagy mennyiségû FCS hibát olyan esetekben is tapasztalhatunk, amikor a távoli pont abbahagyta a PPP üzenetek küldését. Ilyenkor javasolt engedélyezni az aszinkron naplózás használatát, aminek segítségével gyorsan meg tudjuk állapítani, hogy a beérkezõ adatok bejelentkezõ vagy shell üzeneteket. Ha a másik oldalon egy shell parancssorát kapjuk meg, akkor a &man.ppp.8; a close lcp megadásával a vonal eldobása nélkül leállítható (az utána következõ term paranccsal pedig a távoli gépen futó shellre tudunk csatlakozni). Ha a naplókban látszólag semmi sem indokolja az összeköttetés leállását, próbáljunk meg erre rákérdezni a távoli pont (talán a szolgáltató?) karbantartójánál. A &macos; és &windows; 98 alól indított kapcsolatok miért állnak le, ha PPPoE fut az átjárón? A probléma megoldását Michael Wozniak (mwozniak@netcom.ca) adta meg, valamint Dan Flemming (danflemming@mac.com) alkalmazta ugyanezt Macre: Ennek oka az ún. útválasztási fekete lyuk. A &macos; és a &windows; 98 (de valószínûleg az összes többi µsoft; operációs rendszer) olyan nagy méretû TCP csomagokat küld, amelyek már nem férnek bele egy PPPoE keretbe (amely mérete Ethernet estén 1500 byte alapértelmezés szerint) és beállítja hozzá a darabolás letiltását jelzõ (do not fragment) bitet (TCP esetén ez alapértelmezett), és a Telco útválasztó pedig nem küldi el a must fragment (darabolni kell) ICMP csomagot a letölteni kívánt oldal szolgáltatója felé. (Másik lehetõség, hogy az útválasztó ugyan küld egy ilyen ICMP csomagot, de ezt a tartalomszolgáltatónál található tûzfal eldobja.) Amikor válaszul a szolgáltató olyan kereteket kezd el küldeni, amelyek nem illeszkednek a PPPoE keresztmetszetébe, a Telco útválasztó egyszerûen eldobja ezeket és a lap nem pedig nem lesz elérhetõ (egyes képek és oldalak esetén elõfordul). Úgy tûnik, ez az alapbeállítás a legtöbb Telco PPPoE konfiguráció esetében. Ezt a hibát úgy javíthatjuk, ha a &windows; 95/98 rendszerekben megtalálható regedit segítségével felvesszük a következõ regisztrációs bejegyzést: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\NetTrans\0000\MaxMTU A karakterlánc értéke legyen 1436, mivel bizonyos ADSL útválasztók állítólag nem képesek ennél nagyobb méretû csomagokat kezelni. &windows; 2000 esetén ezt a beállítást a Tcpip\Parameters\Interfaces\a hálózati kártya azonosítója\MTU helyen kell keresni és típusa duplaszó (DWORD). A &windows; MTU beállításaival kapcsolatban olvassuk el a Microsoft Knowledge Base címén található dokumentumokat: Q158474 - Windows TCPIP Registry Entries és Q120642 - TCPIP & NBT Configuration Parameters for &windowsnt; . &windows; 2000 alatt a regisztrációs adatbázisban érdemes még a Tcpip\Parameters\Interfaces\a hálózati kártya azonosítója\EnablePMTUBHDetect duplaszó értékét 1-re állítani, ahogy arra az imént említett 120642-es µsoft; dokumentum is hivatkozik. Sajnos a &macos; nem nyújt semmilyen beállítási lehetõséget a TCP/IP beállítások megváltoztatására. Léteznek viszont kereskedelmi termékek, amelyek lehetõvé teszi a felhasználók számára, hogy igényeik szerint módosítsák rendszerük TCP/IP beállításait. A hálózati címfordítást használók keressék meg az MTU beállításaikat és adják meg az 1450 értéket az eredeti 1500 helyett. A &man.ppp.8; újabb (2.3 vagy afeletti) változatai már tartalmaznak egy enable tcpmssfixup parancsot, amellyel az MSS értéke tetszõlegesen átállítható. Ez alapértelmezés szerint engedélyezett. Ha valamiért mégis a &man.ppp.8; egy korábbi változatával kellene dolgoznunk, akkor érdemes megnéznünk net/tcpmssd portot. Ezek közül egyik sem használt — segítség! Mit lehetne még tenni? Ha eddig minden más csõdött mondott, akkor próbáljuk meg elküldeni az összes beszerezhetõ információt, beleértve a konfigurációs állományokat, hogyan indítjuk el a &man.ppp.8; programot, a naplók fontosabb részeit és a netstat -rn parancs kimenetét (a csatlakozás elõtt és után) a &a.questions; címére vagy a comp.unix.bsd.freebsd.misc hírcsoportba, és valaki talán majd megmutatja a helyes irányt. Soros vonali kommunikáció Ebben a szakaszban a &os; alatti soros vonali kommunikációval kapcsolatos kérdéseket tárgyaljuk. A PPP és SLIP használatáról a Hálózatok címû részben esik szó. Honnan deríthetõ ki, hogy a &os; felismerte a soros portokat a gépben? Ahogy a &os; rendszermagja az elindulása után azokat a soros portokat fogja keresni, amelyeket a konfigurációs állományban beállítottunk. Figyeljük a rendszer indulása közben megjelenõ üzeneteket vagy adjuk ki a következõ parancsot a rendszer indulásának befejeztével: &prompt.user; dmesg | grep -E "^sio[0-9]" Íme egy példa az iménti parancs kimenetére: sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A Ezen két soros portot láthatunk. Az elsõ a negyedik megszakítást és a 0x3f8 címet használja és egy 16550A típusú UART chip. A második ugyanolyan chip, de a harmadik megszakítást és a 0x2f8 címet használja. A belsõ modemeket a rendszer úgy kezeli, mintha soros portok lennének, azzal a kivétellel, hogy a modem mindig kapcsolódik az adott porthoz. A GENERIC rendszermag alapértelmezés szerint két soros portot támogat, a példában szereplõ megszakítási- és memóriaértékek felhasználásával. Ha ezek a beállítások nem felelnek meg a rendszerünk számára, esetleg modemet raktunk a gépünkbe vagy a rendszermagban több soros portot is támogatni szeretnénk, akkor nincs más teendõnk, mint ennek megfelelõen megváltoztatni a rendszermag paramétereit. A rendszermag fordításáról szóló rész tárgyalja ennek részleteit. Honnan deríthetõ ki, hogy a &os; felismerte a modemkártyát a gépben? Olvassuk el az elõzõ kérdésre adott választ. Hogyan lehet a soros portokat elérni &os; alatt? A harmadik soros port, a sio2 (lásd &man.sio.4;, DOS alatt COM3) a /dev/cuad2 eszközön keresztül érhetõ el tárcsázó eszközként, és a /dev/ttyd2 eszközön keresztül behívó eszközként. Mi a különbség a két eszközosztály között? A ttydX eszközöket behívásra használjuk. Amikor tehát a /dev/ttydX eszközt blokkoló módban nyitjuk meg, akkor a hívó program egészen addig várni fog, amíg a megfelelõ cuadX eszköz inaktívvá nem válik, majd kivárja, hogy megérkezzen a hívás fogadását tolmácsoló jelzés. Amikor megnyitjuk a cuadX eszközt, gondoskodik róla, hogy a soros portot ekkor ne használja a ttydX eszköz. Ha a port szabaddá válik, egyszerûen ellopja a ttydX eszköztõl. Sõt, a cuadX eszközt egyáltalán nem érdekli a hívás fogadása jelzés. Ezzel a megoldással és egy automata modem segítségével a távoli felhasználók bármikor be tudnak jelentkezni a rendszerünkbe, hogy közben ugyanezzel a modemmel továbbra is tudunk tárcsázni, mivel a rendszer elintézi a többit. Hogyan lehet engedélyezi a többportos soros vonali kártyák támogatását? Ismét megemlítjük, hogy a rendszermag beállításával foglalkozó részben olvashatunk bõvebben a rendszermag paraméterezésének mikéntjérõl. A többportos soros vonali kártyák esetén a kártyán található mindegyik soros porthoz vegyünk fel egy-egy &man.sio.4; bejegyzést a &man.device.hints.5; állományába. Az IRQ és vektor értékeket azonban csak az egyiknél adjuk meg, mivel a kártyán található összes port egyetlen megszakításon fog osztozni. A következetesség kedvéért az utolsó porthoz adjuk meg a megszakítást. Ne felejtsük el még megadni a rendszermag konfigurációs állományában az alábbi opciót sem: options COM_MULTIPORT Az alábbi /boot/device.hints egy AST típusú négyportos soros vonali kártyát láthatunk a tizenkettedik megszakításon: hint.sio.4.at="isa" hint.sio.4.port="0x2a0" hint.sio.4.flags="0x701" hint.sio.5.at="isa" hint.sio.5.port="0x2a8" hint.sio.5.flags="0x701" hint.sio.6.at="isa" hint.sio.6.port="0x2b0" hint.sio.6.flags="0x701" hint.sio.7.at="isa" hint.sio.7.port="0x2b8" hint.sio.7.flags="0x701" hint.sio.7.irq="12" A flags paraméterrel megadott értékek azt jelzik, hogy a fõport 7 alszámmal rendelkezik (0x700), valamint az összes port ugyanazon a megszakításon osztozik (0x001). A &os; képes több többportos soros vonali kártyát ugyanazon a megszakításon keresztül használni? Sajnos még nem. Minden kártyához másik megszakítást kell megadni. Hogyan lehet beállítani a portok alapértelmezett paramétereit? Ezzel kapcsolatban olvassuk el a &os; kézikönyv soros kommunikációt tárgyaló részét. Hogyan lehet a modemen betárcsázást beállítani? Erre vonatkozóan olvassuk el a &os; kézikönyv betárcsázós szolgáltatásokkal kapcsolatos részét. Hogyan lehet buta terminálokat &os;-re csatlakoztatni? Az ezzel kapcsolatos információkat a &os; kézikönyv terminálokról szóló részében találhatjuk meg. Miért nem indul el a tip vagy cu parancs? Elõfordulhat, hogy rendszerünkön a &man.tip.1; és &man.cu.1; programok csak az uucp felhasználón és a dialer csoporton keresztül tudnak hozzáférni a mûködésükhöz szükséges /var/spool/lock könyvtárhoz. A dialer csoport segítségével lehet szabályozni, hogy ki férhessen hozzá a modemekhez vagy a távoli rendszerekhez. Ilyenkor egyszerûen csak vegyük fel magunkat a dialer csoportba. A következõ parancs kiadásával viszont ettõl függetlenül is engedélyezhetjük a rendszerünkön belül, hogy bárki használhassa a &man.tip.1; vagy &man.cu.1; parancsokat: &prompt.root; chmod 4511 /usr/bin/cu &prompt.root; chmod 4511 /usr/bin/tip A rendszerhez csatlakozó Hayes szabványú modem támogatott — mi ilyenkor teendõ? A &os; kézikönyvben lásd ezt a választ. Hogyan adjuk meg az AT parancsokat? A &os; kézikönyvben lásd ezt a választ. A pn tulajdonságnál miért nem lehet @ jelet megadni? A &os; kézikönyvben lásd ezt a választ. Hogyan lehet telefonszámokat tárcsázni parancssorból? A &os; kézikönyvben lásd ezt a választ. Minden alkalommal meg kell adni az adatátviteli sebességet? A &os; kézikönyvben lásd ezt a választ. Terminálszerver segítségével hogyan lehet könnyen elérni egyszerre több gépet is? A &os; kézikönyvben lásd ezt a választ. A &man.tip.1; képes több vonalat is használni az egyes gépek eléréséhez? A &os; kézikönyvben lásd ezt a választ. Miért kell kétszer lenyomni a CtrlP billentyûket, hogy egyszer elküldjük ezeket? A &os; kézikönyvben lásd ezt a választ. Miért lett hirtelen minden NAGYBETÛS? A &os; kézikönyvben lásd ezt a választ. Hogyan lehet állományokat mozgatni a tip használatával? A &os; kézikönyvben lásd ezt a választ. Hogyan használható a zmodem protokoll a tip programmal? A &os; kézikönyvben lásd ezt a választ. Egyéb kérdések A &os; miért használ sokkal több lapozóállományt, mint a &linux;? A &os; csupán látszólag használ több helyet a lapozásra, mint a &linux;, valójában egyébként nem. A &os; és a &linux; közt az egyik leglényegesebb különbség, hogy a &os; valamivel elõre gondolkodik, és az összes pillanatnyilag nem használt lapot kilapozza a központi memóriából a lapozóterületre. Ezzel igyekszik minél több memóriát elõkészíteni az aktív használatra. A &linux; ezzel szemben a lapozást csak végsõ esetben használja. Ennek megfelelõen a lapozóterület gyakoribb használatát remekül ellensúlyozza a fizikai memória hatékonyabb kihasználása. Habár a &os; igyekszik ebben a tekintetben elõrelátó lenni, nem minden esetben tudja pontosan eldönteni, hogy a rendszerben mely lapokat nem használják éppen. Emiatt nem fogja az összes memóriát kilapozni, ha például egész éjszakára futni hagyjuk a gépünket. A top miért jelez kevés szabad memóriát, miközben csak néhány program fut? Röviden úgy válaszolhatnánk meg ezt a kérdést, hogy a szabad memória igazából elvesztegetett memória. A programok által szabadon hagyott memóriát a &os; rendszermagja többnyire a lemez gyorsítótárazására használja fel. A &man.top.1; kimenetében olvasható Inact, Cache és Buf értékek a lényegében különbözõ öregedési szintek szerint kategorizált tárazott adatok. A tárazás lényegében arra utal, hogy a rendszernek így nem a lassú elérésû lemezen kell a gyakran elérni kívánt adatok után kutatni, aminek köszönhetõen növekszik az összteljesítmény. A &man.top.1; kimenetében tehát Free kategória alacsony értéke alapvetõen jót jelent, feltéve, ha nem nagyon kevés. A chmod miért nem változtatja meg a szimbolikus linkek engedélyeit? A szimbolikus linkekhez alapértelmezés szerint nem tartoznak engedélyek, ezért a &man.chmod.1; ilyen esetekben nem követi nyomon az eredeti állomány engedélyeinek megváltozását. Ezért például, ha adott egy ize nevû állomány, valamint erre egy mize nevû szimbolikus link, akkor a következõ parancs mindig mûködni fog: &prompt.user; chmod g-w mize Ennek ellenére az ize engedélyei nem fognak megváltozni. Ez csak akkor fog mûködni, ha a opció mellett a vagy opciókat is megadjuk. Errõl részletesebb információkat a &man.chmod.1; és a &man.symlink.7; man oldalairól tudhatunk meg. A &man.chmod.1; opciója rekurzív mûködést tesz lehetõvé. Óvatosan bánjunk a könyvtárakkal vagy a könyvtárakra mutató szimbolikus linkekkel a &man.chmod.1; használata során. Ha egy szimbolikus link által hivatkozott könyvtár engedélyeit akarjuk megváltoztatni, akkor a &man.chmod.1; parancsnak ne adjunk meg semmilyen paramétert és a nevet zárjuk perjellel (/). Például, ha az ize a mize könyvtárra mutató szimbolikus link, és meg akarjuk változtatni az ize engedélyeit (ami valójában a mize engedélyeit jelenti), akkor valami ilyesmit kellene megadnunk: &prompt.user; chmod 555 ize/ A név végén szereplõ perjelbõl a &man.chmod.1; tudni fogja, hogy követnie kell a foo szimbolikus linket és így az általa hivatkozott könyvtár, a mize engedélyeit fogja megváltoztatni. A &os; képes DOS programokat futtatni? Igen, a Portgyûjteményben található emulators/doscmd, vagyis egy DOS emulációs program segítségével. Amennyiben a doscmd önmagában még nem lenne elegendõ, egy másik segédprogram, a emulators/pcemu segítségével emulálni tudunk egy 8088-as processzort, valamint a BIOS annyi részét, hogy futtatni tudjunk szöveges DOS alkalmazásokat. A használatához az X Window Systemre is szükségünk lesz. Érdemes ezenkívül még megpróbálnunk a &os; Portgyûjteményében található emulators/dosbox portot is. Ez az alkalmazás elsõsorban a régi DOS-os játékok futtatásához szükséges környezet emulációjára koncentrál, a helyi állományrendszerben található állományok felhasználásával. Hogyan tudjuk az anyanyelvünkre lefordítani a &os; dokumentációját? Olvassuk el a &os; Dokumentációs Projekt bevezetõjében található Fordítói GYIK-ot. A FreeBSD.org tartományon belüli e-mail címekre küldött levelek miért pattannak vissza? A FreeBSD.org levelezõrendszere a bejövõ levelekre vonatkozóan átvett néhány szigorúbb ellenõrzést a Postfix alkalmazástól, és ezért eldobja azokat a leveleket, amelyek formátuma hibás vagy feltehetõen szemét. A leveleink az alábbi okok miatt pattanhatnak vissza: A levelet olyan név- vagy IP-tartományból küldtük, ahonnan korábban levélszemetet küldtek, ezért feketelistára került. A &os; levelezõ szerverei eldobnak minden olyan levelet, amelyek feketelistás tartományokból érkeznek. Ha olyan cégen vagy tartományon keresztül akarunk küldeni, amelyik levélszemetet gyárt vagy továbbít, akkor váltsunk szolgáltatót. A levél törzse csak HTML kódot tartalmaz. A leveleinket egyszerû szöveges formátumban küldjük. Állítsuk be a levelezõ kliensünket erre. A FreeBSD.org címen üzemelõ levelezõ szerver nem tudta a csatlakozó gép IP-címét szimbolikus névre feloldani. Az ellenkezõ irányú névfeloldás sikeressége alapvetõ követelmény a levelek fogadásához. Gondoskodjunk róla, hogy a levelezõ szerverünk IP-címével mûködjön az inverz névfeloldás, Sok otthoni szolgáltatás (DSL, kábel, betárcsázós stb. kapcsolat) erre nem ad lehetõséget. Ilyenkor a leveleinket próbáljuk meg a szolgáltatónk levelezõ szerverein keresztül küldeni. Az SMTP protokoll EHLO/HELO részében megadott hálózati név nem oldható fel valós IP-címre. Egy teljes, feloldható hálózati név elegendhetetlen a levél elfogadásához szükséges SMTP párbeszéd érvényességéhez. Ha nincs hivatalosan bejegyzett hálózati nevünk, akkor a szolgáltató levelezõ szervereit kell használnunk a levél elküldéséhez. A küldött üzenet azonosítója (Message ID) végén a localhost szerepel. Egyes levelezõ kliensek rossz azonosítónak hoznak létre az üzenetekhez, ezért a rendszer nem hajlandó elfogadni ezeket. Ilyenkor vagy rávesszük valahogy a levelezõ kliensünket, hogy rendes azonosítókat készítsen, vagy úgy állítjuk be a levéltovábbítónkat, hogy érvényes azonosítókra írja át. Hogyan lehet egyszerûen &os; rendszereket elérni? Habár a &os; maga nem nyújt akárki számára hozzáférést a saját szervereihez, mások viszont kínálnak bárki által elérhetõ &unix; rendszereket. Ennek költsége és minõsége szolgáltatónként változik. Az Arbornet, Inc, vagy másik nevén M-Net 1983 óta szolgáltat nyílt hozzáférést &unix; típusú rendszerekhez. Egy System III alapokon mûködõ Altos rendszerrõl a 1991-ben BSD/OS-re váltottak, majd 2000 júliusában aztán &os;-re váltottak. Az M-Net telnet és SSH szolgáltatásokon keresztül is elérhetõ, és lényegében a &os; alatt elérhetõ összes programhoz enged egy alapvetõ hozzáférést. A hálózati hozzáférés azonban csak a tagok és a támogatók számára engedélyezett. Ez egy non-profit szervezet. Az M-Net rendelkezik üzenõfallal (bulletin board system, BBS) és interaktív csevegõrendszerrel is. A Grex az M-Net szolgáltatásához hasonlóan ugyanúgy kínál üzenõfalat és csevegési lehetõséget. Többségében azonban &sun; 4M gépeik vannak, amelyen &sunos; fut. Mi az a sup és hogyan lehet használni? A SUP mozaikszó mögött a Software Update Protocol (Szoftverfrissítési protokoll) áll, amelyet fejlesztési fák szinkronban tartására dolgoztak ki a Carnegie-Mellon Egyetemen. Régebben ennek segítségével tartották frissítették magukat a fejlesztõi források különbözõ tükrözései a &os; Projekten belül. A SUP nem kifejezetten egy sávszélesség-takarékos megoldás, és egy ideje már nyugdíjba vonult. A forrásainkat jelen pillanatban a CVSup használatával tudjuk frissíteni. Hogy hívják azt a cuki kis vörös fickót? Igazából nincs neve, mindenki egyszerûen csak BSD démonnak nevezi. Ha mégis hívni szeretnénk valahogy, akkor szólítsuk csak beastie-nek, ugyanis a beastie kiejtése megegyezik a BSD szóéval (bíeszdi). A BSD démonról a saját honlapján tudhatunk meg többet. Felhasználható a BSD démon képe? Talán. A BSD démon jogait Marshall Kirk McKusick birtokolja. A felhasználás pontos lehetõségeivel kapcsolatban olvassuk el Statement on the Use of the BSD Daemon Figure címû írást. Röviden úgy foglalhatnánk össze, hogy ízléses stílusban a saját céljainkra mindaddig nyugodtan felhasználhatjuk a képet, amíg megemlítjük az eredeti szerzõt. Ha kereskedelmi céljaink vannak, akkor írjunk &a.mckusick; címére. A pontosabb részleteket a BSD démon honlapján olvashatjuk. Található valahol felhasználható kép a BSD démonról? EPS és XFig formátumú rajzok a /usr/share/examples/BSD_daemon/ könyvtárban vannak. A levelezési listákon szerepeltek ismeretlen kifejezések vagy rövidítések. Hol lehet ezeknek utánanézni? Olvassuk el a &os; szakkifejezéseinek gyûjteményét. Miért fontos annyira a biciklitároló színe? Erre röviden úgy adhatnánk választ, hogy ezzel igazából nem kell annyira törõdnünk. Ha viszont valamivel terjedelmesebben akarunk válaszolni, akkor azt mondhatnánk, hogy azért, mert egy biciklitároló megépítése még nem tántorít el senkit sem a válaszott szín kritizálásától és az átfestésének fontolgatásától. Ez a metafora alapvetõen arról szól, hogy nem kell feltétlenül minden apró részletrõl vitatkoznunk csupán azért, mert jobban értünk hozzá. Sokak tapasztalata szerint ugyanis a változtatásokhoz kapcsolódó megjegyzések által gerjesztett zaj fordítottan arányos az adott változtatás bonyolultságával. A még hosszabb és teljesebb válasz eredetileg egy nagyon hosszú és fárasztó vita eredményeképpen keletkezett, amikor arról esett szó, hogy a &man.sleep.1; törtekkel dolgozzon-e vagy sem. Erre válaszul küldte &a.phk; az azóta híressé vált A bike shed (any color will do) on greener grass... ((Bármilyen színû) biciklitároló megfelelne egy zöldebb gyepen...) címû levelét. Ebbõl szeretnénk most idézni:
&a.phk;, &a.hackers.name;, 1999. október 2. Mirõl is szól ez a biciklitároló? — kérdezték tõlem sokan. Ez egy hosszú, vagy még inkább régi történet, amely azonban valójában meglehetõsen rövid. C. Northcote Parkinson Parkinson törvénye címmel írt egy könyvet az 1960-as évek elején, amelyben elég nagy betekintést adott a vezetés dinamikájába. [a könyv részletes bemutatását most kihagyjuk] A konkrét példában egy biciklitároló szerepel egy atomerõmûvel szemben, szóval ez is eléggé jól érzékelteti a könyv korát. Parkinson ezen keresztül bemutatja, hogyan kell egy igazgatói tanács elé járulni egy több millió vagy akár milliárd dolláros atomerõmû megépítéséhez, azonban egy egyszerû biciklitároló megépítésekor könnyen véget nem érõ vitatkozásba bonyolódhatunk. Parkinson elmagyarázza, mindez azért van, mert egy atomerõmû annyira óriási, drága és bonyolult, hogy az emberek egyszerûen nem értik meg. Ezért nem szólnak semmit és megnyugtatják magukat a feltételezéssel, hogy valaki más korábban már biztosan utánajárt a részleteknek. Richard P. Feynmann is könyveiben rengeteg érdekes és nagyon találó példát ad ezekre Los Alamossal kapcsolatban. Vegyünk ezzel szemben most egy biciklitárolót. Bárki képes egy hétvége alatt összetákolni egy ilyet és még így is marad ideje megnézni a meccset. Ezért nem számít, mennyire jól megfogalmazott, elõkészített és logikus is a javaslatunk, valaki biztosan meg fogja ragadni a lehetõséget, hogy az orrunk elõtt fitogtassa a képességeit és megmutassa magát: õ bizony itt járt. Dániában ezt mi úgy hívjuk, hogy otthagyjuk a kezünk nyomát. Ez mindössze a személyes büszkeségrõl és tekintélyrõl szól, vagyis hogy végre elmondhassuk: Ezt nézd! Én csináltam. Ez ugyan leginkább a politikusokra jellemzõ, de alapvetõen minden emberben ott él. Gondoljunk csak a friss betonban hagyott lábnyomokra.
Mókás dolgok a &os;-vel kapcsolatban Mennyire hûsít a &os;? Kérdés: Mérte már valaki, hogy a &os; futása közben mennyire melengeti meg a számítógépet? Úgy hírlik, a &linux; ebben a tekintetben sokkal jobb, mint a DOS, de &os;-rõl még nem ismert ezzel kapcsolatban semmi. Mondjuk, elég tüzesnek tûnik. Válasz: Nem, de korábban már számos tesztet végeztünk bekötött szemû önkénteseken, akiknek elõzetesen 250 mikrogram LSD-25-öt adagoltak. A tesztalanyok 35 százaléka szerint a &os; kissé narancsos ízû volt, míg a &linux; inkább a rózsaszín ködhöz hasonlított. A hõmérséklettel kapcsolatban azonban egyik csoport sem észlelt komolyabb változást. Végül aztán teljesen el kellett vetnünk a kísérlet eredményeit, mert menet közben túlságosan sok önkéntes kóborolt el, és ezzel torzították a mérések eredményeit. A legtöbb önkéntes azóta is Apple-nél van, és azóta is egy új színes, szagos grafikus felületen dolgoznak. Szép kis felfordulás! Komolyan: a &os; és a &linux; is egyaránt a processzorokban található HLT (halt) utasítást használja arra, hogy az üresjáratban levõ rendszer energiafogyasztását és ezáltal hõtermelését is valamennyire mérsékelje. Emellett még az APM (Advanced Power Management) is támogatott, így a &os; akár tetszés szerint alacsonyabb energiafogyasztású módba is tudja tenni a processzort. Mi mocorog a memóriamodulokban? Kérdés: A &os; csinál valami szokatlan a rendszermag fordítása közben, ami miatt a memóriák felõl mocorgást lehet hallani? Amikor fordítok (vagy egy rövid ideig, amikor az indításkor a rendszer keresi a floppymeghajtót) valamilyen furcsa mocorgásszerû hang jön a memóriamodulokból. Válasz: Igen! Gyakran utalnak a BSD rendszerek dokumentációiban mindenféle démonokra, és ezzel kapcsolatban a legtöbb ember nem is tudja, hogy ezek valójában apró, öntudatos, fizikailag nem létezõ lények, amelyek a rendszer indulása után megszállják a számítógépünket. A memóriából kiszûrõdõ mocorgás hangja igazából a démonok közti magas frekvenciás beszélgetésbõl ered, amikor éppen arról egyeztetnek, hogy miként birkózzanak meg a különbözõ rendszeradminisztrációs feladatokkal. Ha teljesen megõrjít minket ez a zajongás, akkor úgy tudunk tõlük megszabadulni, ha kiadjuk DOS-ból a jó öreg fdisk /mbr parancsot. Ekkor viszont ne lepõdjünk meg, ha netalán visszalõnének és próbálnak minket megállítani. Ha eközben a hangszóróinkból Bill Gates sátáni kacaja harsanna fel, akkor rohanjunk és ne is nézzünk többet vissza! A BSD démonok támogatásától mentesen a &windows; és a DOS ikerördögei ilyenkor gyakran visszaszerzik gépünk felett a teljes irányítást és ezzel örök szenvedésre kárhoztatják gyarló lelkünket. Ennek tudatában lehet, hogy mégis csak jobb lenne, ha egyszerûen csak hozzászoknánk azokhoz a furcsa hangokhoz, nem? Hány &os; fejlesztõ kell egy villanykörte kicseréléséhez? Ezeregyszázhatvankilenc: Huszonhárman panaszkodnak a -current listán, hogy már megint kiment a villany. Négyen erre azt válaszolják, hogy ez csak konfigurációs probléma, ezért ennek a -questions listán a helye. Hárman írnak róla hibajelentést, de ezek közül az egyik ráadásul tévesen a doc kategóriába kerül, és csak annyi áll benne, hogy sötét van. Erre az egyikük beszerel egy kipróbálatlan villanykörtét, amitõl nem mûködik a rendszer többi része, így öt perc múlva ki is szereli. Nyolcan leszidják a hibajelentések íróit, hogy nem mellékelték a javítást a jelentéseik mellé. Öten siránkoznak, hogy nem mûködik a rendszer. Harmincegyen erre azt válaszolják, hogy nekik minden remekül mûködik, és az érintettek minden bizonnyal pont rosszkor frissítettek. Egy küld egy új villanykörtét a -hackers listára. Erre egy rászól, hogy õ már három évvel ezelõtt megcsinálta ugyanezt, de amikor beküldte a -current listára, akkor senki sem foglalkozott vele, és egyébként sem szereti a hibajelentéseket. Emellett ráadásul az új villanykörte egyébként sem tetszik. Huszonheten nekiállnak skandálni, hogy a villanykörték nem tartoznak az alaprendszerbe, ezért a committerek a közösség megkérdezése nélkül nem csinálhatnak semmit, és különben is: Mi errõl a -core véleménye? Kétszázan eközben megvitatják, milyen színû legyen a biciklitároló. Hárman jelzik, hogy a javítás nem felel meg a &man.style.9; elõírásainak. Tizenheten megjegyzik, hogy az újonnan javasolt villanykörte GPL licenccel rendelkezik. Ötszázhatvankilencen valóságos vitaözönt indítanak a GPL, a BSD, MIT és NPL licencek elõnyeit illetõen, majd megjegyzéseket tesznek különféle meg nem nevezett FSF alapítók személyes higéniajára. Heten a vita bizonyos részeit átviszik a -chat és -advocacy listákra. Egy végül beszereli a javasolt villanykörtét, de az valamivel mintha halványabban világítani, mint az elõzõ. Ketten leszólják a szerelést, és összekapnak azon, hogy most akkor a &os; inkább maradjon sötétségben vagy érje be a halványabb világítással. Negyvenhárman rikácsolva követelik a halványan világító villanykörte kiszerelését és panaszukat megírják a -core listára. Tizenegyen egy kisebb villanykörtét kérnek, mert ha majd portolni akárják a Tamagotchijukra a rendszert, akkor ott is használható legyen. Hetvenhárman felemelik a szavukat a -hackers és -chat listákon felerõsödött zaj miatt, és tiltakozásul leiratkoznak ezekrõl a listákról. Tizenhárman erre egy leiratkozom, Hogyan kell innen leiratkozni? vagy Kérlek, vegyetek le errõl a listáról témájú levelet küldenek a megszokott stílusban. Egy eközben beszerel végre egy mûködõ villanykörtét, miközben mindenki azzal van elfoglalva, hogy szidja a másikat, így szinte észre sem veszik. Harmincegy ezután hozzáteszi, hogy az új villanykörte 0,364 százalékkal jobban világítana, ha TenDRA-val csinálták volna (akkor viszont kocka alakú lenne) és a &os;-nek ezért a GCC helyett TenDRA-t kellene használnia. Egy valaki megemlíti, hogy az új villanykörtén nincs is burkolat. Kilencen (beleértve a hibajelentések íróit) azt kérdezgetik folyton, hogy Mi az az MFC?. Ötvenheten két hét múlva kezdenek el panaszkodni, hogy a villanykörte kiment. &a.nik; hozzáteszi: Nagyon jót nevettem ezen. Közben az jutott az eszembe, hogy Várjunk csak, nem kellene valahol a felsorolásban lennie egy egy, aki pedig ledokumentálja résznek? És akkor végre megértettem :-) &a.tabthorpe; szerint: Egy sem, mert a valódi &os; fejlesztõk nem félnek a sötétben! Hova kerül a /dev/null eszközre küldött adat? A processzoron található speciális adatsüllyesztõbe kerül, majd hõvé alakul és elszállítja a felszerelt hûtõborda és ventillátor. Ezért is annyira fontos a processzor hûtése: az emberek minél gyorsabb géppel rendelkeznek, annál inkább gondatlanná válnak és annál több adat köt ki a /dev/null eszközben. Ha sikerül letörölnünk a /dev/null eszközt (amivel így lényegében letiltjuk a processzor adatsüllyesztõjét), akkor a processzorunk ugyan kevésbé fog melegedni, viszont gyorsan eldugul a sok adattól és furcsán kezd el viselkedni. Ha nagyon gyors hálózati kapcsolattal rendelkezünk, akkor úgy is le tudjuk hûteni a processzorunkat, ha folyamatosan olvassuk a /dev/random eszközt és valahova elküldjük az eredményt. Ekkor viszont vigyázzunk arra, hogy ezzel a módszerrel könnyen túlmelegedhet a hálózati kártyánk és a gyökér állományrendszerünk, valamint a szolgáltató sem fog örülni ennek, mert akkor a felesleges hõ náluk keletkezik. Általában viszont jó a hûtésük, ezért ha okosan csináljuk, akkor semmi gondunk nem származik belõle. Paul Robinson hozzáteszi: Vannak még más módszerek is. Minden jó rendszergazda tudja, hogy szokás a képernyõre is folyamatosan adatot küldeni, mert így a pixik is vidámabbak lesznek. A képernyõt formázó pixik (melyek gyakran tévesen és hibásan pixeleknek hívnak) a fejükön viselt kalapok szerint három csoportba sorolhatóak (vörös, zöld vagy kék), és annak megfelelõen bújnak elõ (illetve mutatják meg a kalapjukat), hogy kapnak-e enni. A videokártyák felelõsek azért, hogy a kapott adatokból pixiétel készüljön és hogy az eljusson a pixikhez — minél drágább a kártya, annál jobb minõségû az elõállított étel, és annál fegyelmezettebben viselkednek a pixik. Állandó cirogatásra is szükségük van — ez a képernyõvédõk feladata. Az elõbbi javaslatot azzal tudnám még kiegészíteni, hogy a /dev/random eszköztõl származó adatokat akár a konzolra is küldhetjük, így a pixiket is jól tudjuk lakatni. Ezzel együtt nem jár semmilyen hõtermelés, viszont a pixik boldogok lesznek és így könnyen meg tudunk szabadulni a felesleges adatoktól is, még úgy is, ha kissé zavarosnak tûnik közben a kép. Mellesleg mint az egyik nagy szolgáltató egykori rendszergazdája elmondhatom, hogy mivel tapasztalatom szerint a szerverszobában nehéz tartani a megfelelõ hõmérsékletet, ezért nem ajánlom senkinek a felesleges adatok átküldését a hálózaton. A csomagok közvetítésével és irányításával foglalkozó tündérek sem különösebben szoktak örülni ennek. Témák haladóknak Honnan lehet többet megtudni a &os; belsõ felépítésérõl? Jelen pillanatban csak egyetlen mû foglalkozik az operációs rendszerek felépítésével a &os; szemszögébõl, név szerint a Marshall Kirk McKusick és George V. Neville-Neil által írt The Design and Implementation of the &os; Operating System címû könyv (ISBN 0-201-70245-2), amely a &os; 5.X változatára koncentrál. Emellett a &unix; típusú rendszerek használatával kapcsolatos ismeret remekül alkalmazható a &os; esetén is. A témához tartozó többi könyvet a kézikönyv Az operációs rendszerek belsõ mûködésével foglalkozó irodalomjegyzékben találhatjuk meg. Hogyan lehet bekapcsolódni a &os; fejlesztésébe? Pontosabb tanácsokat akkor kapunk, ha elolvassuk a &os; fejlesztésérõl szóló cikket. Nagyon is számítunk mindenki segítségére! Mik azok a pillanatkiadások és kiadások? Jelenleg három aktív és félig aktív ág van a &os; CVS repositoryjában. (A korábbi ágakat már csak nagyon ritkán módosítják, ezért is csak három aktív fejlesztési ágon fejlesztenek): - RELENG_6 avagy - 6-STABLE + RELENG_7 avagy + 7-STABLE - RELENG_7 avagy - 7-STABLE + RELENG_8 avagy + 8-STABLE HEAD avagy -CURRENT avagy - 8-CURRENT + 9-CURRENT A HEAD nem olyan ág, mint a másik kettõ. Ez egyszerûen csak a jelenlegi, még el nem ágaztatott fejlesztési irány jelentéssel bír, amire pedig sokszor röviden csak -CURRENT néven hivatkoznak. Jelen pillanatban a -CURRENT a - 8.X fejlesztési + 9.X fejlesztési irányát képviseli; az 6-STABLE ág, a - RELENG_6, 2005 novemberében, - míg a 7-STABLE ág, a - RELENG_7, 2008 februárjában + RELENG_6, 2005 novemberében, a + 7-STABLE ág, a + RELENG_7, 2008 februárjában, + míg a 8-STABLE ág, a + RELENG_8, 2009 novemberében vált le a -CURRENT ágból. Hogyan lehet saját kiadást készíteni? Olvassuk el a kiadások készítésérõl szóló cikket. A make world parancs miért írja felül a korábban telepített binárisokat? Mert alapvetõen ez lenne a cél: ahogy a neve is sugallja, a rendszer újrafordítása, vagyis a make world parancs feladata a rendszerben található összes bináris újrafordítása, aminek eredményeképpen egy tiszta és összefüggõ környezetet kapunk (ezért is tart ilyen sokáig). Ha a make world vagy a make install parancs futtatása elõtt megadjuk a DESTDIR környezeti változót, akkor a frissen létrehozott binárisok az általa mutatott könyvtárba fognak kerülni pontosan úgy, ahogy az eredeti rendszer. Az osztott könyvtárak bizonyos módosításai és egyes programok fordítása azonban könnyen térdre kényszerítheti a make world futását. Miért nem forgó (round robin) névfeloldással lehet elérni a CVSup szervereket és így megosztani köztük a terhelést? Habár a CVSup tükrözések óránként frissítik magukat a központi CVSup szerverrõl, maga a frissítés azonban bármikor megtörténhet. Ennek következményeképpen egyes szervereken frissebb kód található, miközben a többin még az egy órával ezelõtti állapot szerepel. Ha a cvsup.FreeBSD.org forgó névfeloldással mûködne, akkor a felhasználók mindig egy véletlenszerûen választott CVSup szervert kapnának, és ezért a CVSup egymás utáni futtatásakor könnyen elõfordulhatna, hogy a rendszer régebbi forrásait kapjuk vissza. A -CURRENT forrásait korlátozott interneteléréssel is lehet követni? Igen, ezt a CTM használatával anélkül is megtudjuk tenni, hogy le kellene töltenünk az egész forrásfát. Hogyan lehet 1392 KB-os darabokra felosztani az egyes terjesztéseket? Az újabb BSD alapú rendszerekben a &man.split.1; parancsnak már van egy paramétere, amellyel tetszõleges méretûre fel tudunk darabolni állományokat. Íme erre egy példa a /usr/src/release/Makefile állományból: ZIPNSPLIT= gzip --no-name -9 -c | split -b 1392k - Hova lehet küldeni a rendszermaghoz írt kiegészítéseket? Erre vonatkozóan vessünk egy pillantást a &os; továbbfejlesztésérõl szóló cikkre. Köszönjük, hogy gondolt ránk! A rendszer hogyan érzékeli és inicializálja a Plug and Play ISA kártyákat? Frank Durda IV (uhclem@nemesis.lonestar.org) válasza: Dióhéjban úgy tudnám ezt elmagyarázni, hogy van néhány I/O port, amelyet lekérdezve a PnP kártya képes válaszolni, hogy elérhetõ-e. Ezért a PnP eszközök keresése azzal kezdõdik, hogy a rendszer felteszi a kérdést, van-e PnP kártya a számítógépben. Erre aztán a különbözõ kártyák a típusuk megjelölésével válaszolnak, amelyet ugyanezen az I/O porton kell visszaolvasni, így ha már legalább egy bitet beállít valaki, akkor folytatható a keresés. Ezután a keresést végzõ kódrész letiltja az X alatti (a µsoft; és az &intel; által kiosztott) azonosítóval rendelkezõ kártyákat, majd ismét megnézi, hogy valaki továbbra is válaszol-e. Amennyiben a válasz 0, az arra utal, hogy már nincs aktív kártya az X azonosító felett. Ezt követõen a rendszer megpróbálkozik az X alatti azonosítók lekérdezésével. Végül folytatja az X alatti keresést az X -(korlát / 4) feletti azonosítók letiltásával, majd megismétli az iménti kérdést. Ezzel a félig-meddig bináris keresési módszerrel aztán képes 264 lépésnél jóval kevesebbõl felderíteni a rendszerünkben megtalálható PnP kártyákat. Az azonosítók két 32 bit hosszúságú mezõbõl (ezért írtunk az elõbb 264 lépést) és egy 8 bites ellenõrzõösszegbõl állnak. Az elsõ 32 bit a gyártót azonosítja. Ugyan soha nem vallják be, de úgy tûnik, hogy még ugyanannak a gyártónak is lehetnek eltérõ gyártóazonosítóval rendelkezõ kártyái. A gyártók számára fenntartott 32 bites mezõ ezért valamennyire túlzás. A második 32 bit lehet a kártya sorozatszáma vagy bárki más, amely alapján egyértelmûen beazonosítható. A gyártó ugyanazzal a 32 bites értékkel nem gyárthat egy másik kártyát, csak abban az esetben, ha a másik 32 bit is eltér. Ennek köszönhetõen egy gépen belül még az azonos típusú kártyák is el fognak térni 64 biten. Az iménti 32 bites csoportok nem lehetnek teljesen nullák, ezért lehetséges, hogy a bináris keresés során a válaszban legalább egy bit mindig aktív lesz. Miután a rendszer sikeresen beazonosította a rendelkezésre álló kártyákat, egyenként újra elindítja ezeket (ugyanazon az I/O porton keresztül), és megpróbálja kitalálni, hogy az adott eszközöknek milyen erõforrásokra van szüksége, milyen megszakítást akarnak használni stb. Az összes kártyától lekérdezi ezeket az információkat. Az így megszerzett információkat aztán még kiegészíti a merevlemezen vagy az MLB BIOS-ban található ECU állományok tartalmával. Az ECU és az MLB BIOS PnP támogatása általában viszont nem valódi, és az ilyen eszközök igazából nem is állítanak be semmit maguktól. A BIOS és az ECU átvizsgálása azonban segít a felderítést végzõ rutinnak értesíteni a tényleges PnP eszközöket, hogy ne foglaljanak el olyan erõforrásokat, amelyeket a rendszer nem tud áthelyezni. Ezután a PnP eszközöket a kód még egyszer végigjárja és átadja nekik a mûködésükhöz szükséges I/O, DMA, IRQ és memóracímek hozzárendeléseit. Az eszközök ekkor a megadott helyeken elérhetõvé válnak és úgy is maradnak a rendszer következõ indításáig, de igazából semmi sem rögzíti ezeket. Talán túlságosan is egyszerûsítettem a fentieket, de szerintem már ennyi is elegendõ az alapok megértéséhez. A µsoft; néhány elsõdleges nyomtatási állapotot jelzõ portot átrakott PnP-re, azzal a címszóval, hogy egyik kártya sem kódolta át ezeket a címeket az ellenkezõ I/O ciklusok számára. Találtam is egy eredeti IBM nyomtatókártyát, amely valóban át tudta írni az állapotjelzõ portot a PnP kezdeti változataiban, de arra a µsoft; csak annyit mondott, hogy fogós. Ezért a nyomtatási állapotot jelzõ portot a címek beállítására használja, illetve még a 0x800-as portot és egy harmadik I/O portot valahol a 0x200 és a 0x3ff környékén. Hogyan lehet fõeszközazonosítót rendelni egy általunk fejlesztett meghajtóhoz? 2003 februárja óta a &os; képes dinamikusan és önmûködõen futás közben lefoglalni fõeszközazonosítókat a meghajtóknak (lásd &man.devfs.5;), ezért erre tulajdonképpen már nincs szükség. A könyvtárakra vonatkozóan milyen más kiosztási házirendek léteznek még? A könyvtárak más fajta kiosztására vonatkozóan annyit tudok válaszolni, hogy a jelenleg is alkalmazott sémát az 1983-ban megalkotott változata óta változatlanul használjuk. Eredetileg a gyors állományrendszerhez készítettem, de soha nem ragaszkodtam hozzá. Remekül megoldja a cilindercsoportok betelésének problémáját, azonban sokan megjegyezték már, hogy a &man.find.1; esetén gyengén mûködik. A legtöbb állományrendszert mélységi bejárással hozzák létre, így a könyvtárak szétszóródnak a cilindercsoportok közt és ezzel a késõbbi mélységi keresések számára a lehetõ legrosszabb helyzetet alakítják ki. Ha valaki például tudja elõre a létrehozni kívánt könyvtárak számát, akkor ezt úgy lehet megoldani, ha a mûvelet során (összes / cilindercsoportok) mennyiségû könyvtárat hozunk létre az egyes cilindercsoportokban. Ennek meghatározására nyilvánvalóan lehet adni valamilyen heurisztikát. Már egy kisebb elõre rögzített szám, mint például a 10 kiválasztása is legalább egy nagyságrendnyi javulást jelent. Ha szeretnénk megkülönböztetni az állományrendszerek visszaállítását a hagyományos mûködéstõl (amire a jelenlegi algoritmus sokkal érzékenyebb), akkor érdemes tizes csoportokba összefogni a könyvtárakat, feltéve, hogy 10 másodpercen belül hoztuk létre ezeket. Mindenesetre elmondható, hogy ezzel nyugodtan lehet kísérletezni. &a.mckusick;, 1998 szeptembere Hogyan lehet kinyerni a legtöbb információt a rendszermag összeomlásából? Általában így néz ki a rendszermag összeomlása: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x40 fault code = supervisor read, page not present instruction pointer = 0x8:0xf014a7e5 stack pointer = 0x10:0xf4ed6f24 frame pointer = 0x10:0xf4ed6f28 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 80 (mount) interrupt mask = trap number = 12 panic: page fault Amikor egy ilyen üzenetet látunk, akkor nem elegendõ újra elõcsalni a hibát és beküldeni. Az utasításszámláló (instruction pointer) értéke ugyan nagyon fontos, de sajnos konfigurációk szerint eltérhet. Más szóval úgy fogalmazhatnék, hogy ennek az értéke a használatban levõ rendszermag értékétõl függõen változhat. Ha a GENERIC rendszermagot használjuk valamelyik kiadásból, akkor viszont már elképzelhetõ, hogy valaki más is le tudja nyomozni a hibát okozó függvényt. Ha viszont egy saját beállításokkal rendelkezõ rendszermagot használunk, akkor egyedül csak mi vagyunk képesek megmondani a hiba pontos helyét. Ezért a javaslatom a következõ: Jegyezzük le az utasításszámláló értékét. A 0x8: rész ebben az esetben annyira nem fontos, egyedül csak a 0xf0xxxxxx részre van szükségünk. A rendszer újraindításakor írjuk be a következõt: &prompt.user; nm /a.hibát.okozó.rendszermag | grep f0xxxxxx ahol az f0xxxxxx az utasításszámláló értéke. Könnyen elõfordulhat, hogy ilyenkor még nem találunk egyezést, mivel a rendszermag szimbólumtáblájában csak az egyes függvények belépési pontjai találhatóak, és ha az utasításszámláló általában valamelyikük belsejébe mutat, nem az elejükre. Ha tehát nem még látunk semmit, akkor egyszerûen hagyjuk el az utolsó számjegyet és próbálkozzunk így: &prompt.user; nm /a.hibát.okozó.rendszermag | grep f0xxxxx Ha még ez sem hoz eredményt, akkor vágjunk le a végérõl egy újabb számjegyet. Egészen addig csináljuk, amíg nem kapunk valami értékelhetõ eredményt. Ilyennek tekintjük például azokat a függvényeket, amelyek a hibát okozhatták. Ez ugyan egy nem annyira pontos felderítési eszköz, viszont még ez is jobb a semminél. A legjobb viszont mégis az, amikor sikerül lementeni a hiba bekövetkezésekor a memória tartalmát, majd a &man.kgdb.1; használatával elõbányászni belõle egy hívási láncot. Ehhez többnyire a következõ módszer javasolt: A rendszermag konfigurációs állományába (/usr/src/sys/arch/conf/RENDSZERMAGKONFIG) vegyük fel a következõ sort: makeoptions DEBUG=-g # A rendszermag fordítása gdb(1) szimbólumokkal Lépjünk be a /usr/src könyvtárba: &prompt.root; cd /usr/src Fordítsuk le a rendszermagot: &prompt.root; make buildkernel KERNCONF=RENDSZERMAGKONFIG Várjuk meg, amíg a &man.make.1; befejezi a fordítást. &prompt.root; make installkernel KERNCONF=RENDSZERMAGKONFIG Indítsuk újra a gépet. A KERNCONF használata nélkül a GENERIC rendszermag fordul és telepítõdik. A &man.make.1; programnak a folyamat végeredményeként két rendszermagot kell készítenie: a /usr/obj/usr/src/sys/RENDSZERMAGKONFIG/kernel és a /usr/obj/usr/src/sys/RENDSZERMAGKONFIG/kernel.debug. Ezek közül a kernel /boot/kernel/kernel néven mentõdik el, miközben a kernel.debug használható nyomonkövetésre a &man.kgdb.1; programmal. A rendszer csak akkor fogja elmenteni összeomláskor a memória tartalmát, ha az /etc/rc.conf állományban beállítjuk a dumpdev értékét a lapozóállományt tároló partícióra (vagy az AUTO értékre). Ennek hatására az &man.rc.8; szkriptek a &man.dumpon.8; paranccsal képesek engedélyezni a memória lementését. A &man.dumpon.8; természetesen manuálisan is elindítható. Az összeomlást követõen a memória lementett tartalmához a &man.savecore.8; programmal férhetünk hozzá. Amikor viszont az /etc/rc.conf állományban megadjuk a dumpdev értékét, az &man.rc.8; szkriptek maguktól lefuttatják a &man.savecore.8; parancsot és átrakják a mentést a /var/crash könyvtárba. A &os; által létrehozott memóriamentések mérete általában a számítógépünkben levõ fizikai memória mennyiségével egyezik meg. Tehát ha 512 MB RAM van a gépünkben, akkor egy 512 MB méretû mentést fogunk kapni. Ezért gondoskodjunk róla, hogy a /var/crash könyvtárban mindig legyen elegendõ hely az állomány tárolásához. A &man.savecore.8; kézzel is lefuttathazó, és ilyenkor a memóriát akár egy másik könyvtárba is menthetjük. A mentés méretét options MAXMEM=N beállítással is korlátozhatjuk, ahol az N értéke a rendszermag által használható memória mérete KB-okban. Például, ha 1 GB RAM van a gépünkben, de a rendszermag által használható memóriát lekorlátozzuk 128 MB-ra, akkor a mentés mérete sem 1 GB lesz, hanem csak 128 MB. Ahogy sikerült hozzájutnunk a memóriamentéshez, azonnal is kérhetünk a &man.kgdb.1; használatával egy hívási láncot belõle: &prompt.user; kgdb /usr/obj/usr/sys/RENDSZERMAGKONFIG/kernel.debug /var/crash/vmcore.0 (kgdb) backtrace Elõfordulhat, hogy ilyenkor több oldalnyi információ özönlik hirtelen a képernyõre, ezért javasolt ezeket lementeni a &man.script.1; programmal. A nyomkövetési szimbólumokat is tartalmazó rendszermag esetén még akár azt a sort is megkapjuk a rendszermagon belül, ahol a hiba történt. A hívási láncot általában alulról felfelé kell olvasni, és ebbõl deríthetõ, hogy pontosan milyen események is vezettek az összeomláshoz. A &man.kgdb.1; használatával még a különbözõ változók és struktúrák értékeit is meg tudjuk vizsgálni, így még többet megtudhatunk a rendszer állapotáról az összeomlás pillanatában. Ha az iméntiek mentén nagyon fellelkesültünk volna és van egy másik számítógépünk is, akkor a &man.kgdb.1; akár távoli nyomkövetésre is beállítható, aminek köszönhetõen a &man.kgdb.1; használatával az egyik rendszeren meg tudjuk állítani a másikon futó rendszermagot, ellenõrizhetjük a viselkedését, akárcsak bármelyik más felhasználói program esetében. Ha netalán engedélyeztük volna a DDB beállítást, és a rendszermag beleáll a nyomkövetõbe, akkor a rendszert mi magunk is össze tudjuk omlasztani (és így a memóriát elmenteni) a ddb parancssorában a panic parancs kiadásával. Ilyenkor a nyomkövetõ általában még egyszer megáll az összeomláskor. Ekkor a continue paranccsal fejeztethetjük be a memória lementését. A dlsym() függvény miért nem mûködik már az ELF állományokra? Az ELF állományokhoz tartozó segédprogramok alapértelmezés szerint nem teszik láthatóvá a dinamikus linker számára a végrehajtható állományban definiált szimbólumokat. Ennek eredményeképpen a dlsym() a dlopen(NULL, flags) függvénytõl kapott információk alapján nem találja meg a keresett szimbólumokat. Ha szükségünk lenne ilyen keresésekre a dlsym() használata során a program végrehajtható állományán belül, akkor az adott programot a opció megadásával kell linkelni (lásd &man.ld.1;). Hogyan növelhetõ vagy csökkenthetõ a rendszermag címtere &i386; architektúrán? Az &i386; platformon a rendszermag címtere alapértelmezés szerint 1 GB (PAE esetén 2 GB). Ha komolyabb hálózati forgalmat bonyolító szerverünk van (például egy nagyobb FTP vagy HTTP szerver) vagy rendszerükön használni akarjuk a ZFS állományrendszert, akkor könnyen kifuthatunk a címtérbõl. A címtér méretének megváltoztatásához vegyük fel a következõ sort a rendszermag konfigurációs állományába, majd fordítsuk újra a rendszermagot: options KVA_PAGES=N Az N megfelelõ értékének megállapításához osszuk el a beállítani kívánt címtér (MB-okban megadott) méretét néggyel. (Tehát például 2 GB esetén ez 512 lesz.) Köszönetnyilvánítás Ezt a szegény kis ártatlan GYIKocskát több százan, ha nem is éppen több ezren írták, újraírták, szerkesztették, hajtogatták, tekergették, csonkítgatták, kibelezték, nézegették, összekutyulták, emlegették, felöklendezték, újraépítették, javítgatták és felpezsdítették az utóbbi években. Folyamatosan. Ezúton is szeretnénk köszönetet mondani mindazoknak, akik gondozásukba vették, és mindenkit csak bátorítani tudunk, hogy csatlakozzon hozzájuk a GYIK továbbfejlesztésében. &bibliography; 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 8b344be7a1..23ac3a56d2 100644 --- a/hu_HU.ISO8859-2/books/handbook/network-servers/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/network-servers/chapter.sgml @@ -1,7260 +1,7265 @@ Murray Stokely Átdolgozta: Hálózati szerverek Áttekintés Ebben a fejezetben a &unix; típusú rendszerekben leggyakrabban alkalmazott hálózati szolgáltatások közül fogunk néhányat bemutatni. Ennek során megismerjük a hálózati szolgáltatások különbözõ típusainak telepítését, beállítását, tesztelését és karbantartását. A fejezet tartalmát folyamatosan példákkal igyekszünk illusztrálni. A fejezet elolvasása során megismerjük: hogyan dolgozzunk az inetd démonnal; hogyan állítsuk be a hálózati állományrendszereket; hogyan állítsunk be egy hálózati információs szervert a felhasználói hozzáférések megosztására; hogyan állítsuk be automatikusan a hálózati hozzáférésünket a DHCP használatával; hogyan állítsunk be névfeloldó szervereket; hogyan állítsuk be az Apache webszervert; hogyan állítsuk be az állományok átviteléért felelõs (FTP) szervert; a Samba használatával hogyan állítsunk be &windows;-os kliensek számára állomány- és nyomtatószervert; az NTP protokoll segítségével hogyan egyeztessük az idõt és dátumot, hogyan állítsunk be egy idõszervert; a szabványos naplózó démon, a syslogd beállítását hálózati keresztüli naplózásra. A fejezet elolvasásához ajánlott: az /etc/rc szkriptek alapjainak ismerete; az alapvetõ hálózati fogalmak ismerete; a külsõ szoftverek telepítésének ismerete (). Chern Lee Készítette: A &os; 6.1-RELEASE változatához igazította: A &os; Dokumentációs Projekt Az <application>inetd</application> <quote>szuperszerver</quote> Áttekintés Az &man.inetd.8; démont gyakran csak internet szuperszerverként nevezik, mivel a helyi szolgáltatások kapcsolatainak kezeléséért felelõs. Amikor az inetd fogad egy csatlakozási kérelmet, akkor eldönti róla, hogy ez melyik programhoz tartozik és elindít egy példányt belõle, majd átadja neki a socketet (az így meghívott program a szabvány bemenetéhez, kimenetéhez és hibajelzési csatornájához kapja meg a socket leíróit). Az inetd használatával úgy tudjuk csökkenteni a rendszerünk terhelését, hogy a csak alkalmanként meghívott szolgáltatásokat nem futtatjuk teljesen független önálló módban. Az inetd démont elsõsorban más démonok elindítására használjuk, de néhány triviális protokollt közvetlenül is képes kezelni, mint például a chargen, auth és a daytime. Ebben a fejezetben az inetd beállításának alapjait foglaljuk össze mind parancssoros módban, mind pedig az /etc/inetd.conf konfigurációs állományon keresztül. Beállítások Az inetd mûködése az &man.rc.8; rendszeren keresztül inicializálható. Az inetd_enable ugyan alapból a NO értéket veszi fel, vagyis tiltott, de a sysinstall használatával már akár a telepítés során bekapcsolható attól függõen, hogy a felhasználó milyen konfigurációt választott. Ha tehát a: inetd_enable="YES" vagy inetd_enable="NO" sort tesszük az /etc/rc.conf állományba, akkor azzal az inetd démont indíthatjuk el vagy tilthatjuk le a rendszer indítása során. Az &prompt.root; /etc/rc.d/inetd rcvar paranccsal lekérdezhetjük a pillanatnyilag érvényes beállítást. Emellett még az inetd démonnak az inetd_flags változón keresztül különbözõ parancssori paramétereket is át tudunk adni. Parancssori paraméterek Hasonlóan a legtöbb szerverhez, az inetd viselkedését is befolyásolni tudjuk a parancssorban átadható különbözõ paraméterekkel. Ezek teljes listája a következõ: inetd Ezek a paraméterek az /etc/rc.conf állományban az inetd_flags segítségével adhatóak meg az inetd részére. Alapértelmezés szerint az inetd_flags értéke -wW -C 60, ami az inetd által biztosított szolgáltatások TCP protokollon keresztüli wrappelését kapcsolja be, illetve egy IP-címrõl nem engedi a felkínált szolgáltatások elérését percenként hatvannál többször. A kezdõ felhasználók örömmel nyugtázhatják, hogy ezeket az alapbeállításokat nem szükséges módosítaniuk, habár a késõbbiekben majd fény derül arra, hogy a kiszolgálás gyakoriságának szabályozása remek védekezést nyújthat túlzottan nagy mennyiségû kapcsolódási kérelem ellen. A megadható paraméterek teljes listája az &man.inetd.8; man oldalán olvasható. -c maximum Az egyes szolgáltatásokhoz egyszerre felépíthetõ kapcsolatok alapértelmezett maximális számát adja meg. Alapból ezt a démont nem korlátozza. A beállítással ez akár szolgáltatásonként külön is megadható. -C arány Korlátozza, hogy egyetlen IP-címrõl alapból hányszor hívhatóak meg az egyes szolgáltatások egy percen belül. Ez az érték alapból korlátlan. A beállítással ez szolgáltatásonként is definiálható. -R arány Megadja, hogy egy szolgáltatást egy perc alatt mennyiszer lehet meghívni. Ez az érték alapértelmezés szerint 256. A 0 megadásával eltöröljük ezt a típusú korlátozást. -s maximum Annak maximumát adja meg, hogy egyetlen IP-címrõl egyszerre az egyes szolgáltatásokat mennyiszer tudjuk elérni. Alapból ez korlátlan. Szolgáltatásonként ezt a paraméterrel tudjuk felülbírálni. Az <filename>inetd.conf</filename> állomány Az inetd beállítását az /etc/inetd.conf konfigurációs állományon keresztül végezhetjük el. Amikor az /etc/inetd.conf állományban módosítunk valamit, az inetd démont a következõ paranccsal meg kell kérnünk, hogy olvassa újra: Az <application>inetd</application> konfigurációs állományának újraolvasása &prompt.root; /etc/rc.d/inetd reload A konfigurációs állomány minden egyes sora egy-egy démont ír le. A megjegyzéseket egy # jel vezeti be. Az /etc/inetd.conf állomány bejegyzéseinek formátuma az alábbi: szolgáltatás-neve socket-típusa protokoll {wait|nowait}[/max-child[/max-connections-per-ip-per-minute[/max-child-per-ip]]] felhasználó[:csoport][/bejelentkezési-osztály] szerver-program szerver-program-paraméterei Az IPv4 protokollt használó &man.ftpd.8; démon bejegyzése például így néz ki: ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l szolgáltatás-neve Ez az adott démon által képviselt szolgáltatást nevezi meg, amelynek szerepelnie kell az /etc/services állományban. Ez határozza meg, hogy az inetd milyen porton figyelje a beérkezõ kapcsolatokat. Ha egy új szolgáltatást hozunk létre, akkor azt elõször az /etc/services állományba kell felvennünk. csatlakozás-típusa Ennek az értéke stream, dgram, raw, vagy seqpacket lehet. A stream típust használja a legtöbb kapcsolat-orientált TCP démon, miközben a dgram típus az UDP szállítási protokollt alkalmazó démonok esetében használatos. protokoll Valamelyik a következõk közül: Protokoll Magyarázat tcp, tcp4 TCP IPv4 udp, udp4 UDP IPv4 tcp6 TCP IPv6 udp6 UDP IPv6 tcp46 TCP IPv4 és v6 udp46 UDP IPv4 és v6 {wait|nowait}[/max-child[/max-connections-per-ip-per-minute[/max-child-per-ip]]] A beállítás mondja meg, hogy az inetd démonból meghívott démon saját maga képes-e kezelni kapcsolatokat. A típusú kapcsolatok esetében egyértelmûen a beállítást kell használni, miközben a esetén, ahol általában több szálon dolgozunk, a megadása javasolt. A hatására általában egyetlen démonnak adunk át több socketet, míg a minden sockethez egy újabb példányt indít el. Az inetd által indítható példányokat a megadásával korlátozhatjuk. Ha tehát például az adott démon számára legfeljebb példány létrehozását engedélyezzük, akkor a után /10 beállítást kell megadnunk. A /0 használatával korlátlan mennyiségû példányt engedélyezhetünk. A mellett még további két másik beállítás jöhet számításba az egyes démonok által kezelhetõ kapcsolatok maximális számának korlátozásában. A az egyes IP-címekrõl befutó lekezelhetõ kapcsolatok percenkénti számát szabályozza, így például ha itt a tizes értéket adjuk meg, akkor az adott szolgáltatáshoz egy IP-címrõl percenként csak tízszer férhetünk hozzá. A az egyes IP-címekhez egyszerre elindítható példányok számára ír elõ egy korlátot. Ezek a paraméterek segítenek megóvni rendszerünket az erõforrások akaratos vagy akaratlan kimerítésétõl és a DoS (Denial of Service) típusú támadásoktól. Ebben a mezõben a vagy valamelyikét kötelezõ megadni. A , és paraméterek ellenben elhagyhatóak. A típusú több szálon futó démonok a , vagy korlátozása nélkül egyszerûen csak így adhatóak meg: nowait. Ha ugyanezt a démont tíz kapcsolatra lekorlátozzuk, akkor a következõt kell megadnunk: nowait/10. Amikor pedig IP-címenként 20 kapcsolatot engedélyezünk percenként és mindössze 10 példányt, akkor: nowait/10/20. Az iménti beállítások a &man.fingerd.8; démon alapértelmezett paramétereinél is megtalálhatóak: finger stream tcp nowait/3/10 nobody /usr/libexec/fingerd fingerd -s Végezetül engedélyezzük 100 példányt, melyek közül IP-címenként 5 használható: nowait/100/0/5. felhasználó Ezzel azt a felhasználót adjuk meg, akinek a nevében az adott démon futni fog. Az esetek túlnyomó részében a démonokat a root felhasználó futtatja. Láthatjuk azonban, hogy biztonsági okokból bizonyos démonok a daemon vagy a legkevesebb joggal rendelkezõ nobody felhasználóval futnak. szerver-program A kapcsolat felépülésekor az itt teljes elérési úttal megadott démon indul el. Ha ezt a szolgáltatást maga az inetd belsõleg valósítja meg, akkor ebben a mezõben az értéket adjuk meg. szerver-program-paraméterei Ez a beállítással együtt mûködik, és ebben a mezõben a démon meghívásakor alkalmazandó paramétereket tudjuk rögzíteni, amelyet a démon nevével kezdünk. Ha a démont a parancssorból a sajátdémon -d paranccsal hívnánk meg, akkor a sajátdémon -d lesz beállítás helyes értéke is. Természetesen, ha a démon egy belsõleg megvalósított szolgáltatás, akkor ebben a mezõben is az fog megjelenni. Védelem Attól függõen, hogy a telepítés során mit választottunk, az inetd által támogatott szolgáltatások egyes része talán alapból engedélyezett is. Amennyiben egy adott démont konkrétan nem használunk, akkor érdemes megfontolni a letiltását. A kérdéses démon sorába tegyünk egy # jelet az /etc/inetd.conf állományba, majd olvastassuk újra az inetd beállításait. Egyes démonok, mint például az fingerd használata egyáltalán nem ajánlott, mivel a támadók számára hasznos információkat tudnak kiszivárogtatni. Más démonok nem ügyelnek a védelemre, és a kapcsolatokhoz rendelt lejárati idejük túlságosan hosszú vagy éppen nincs is. Ezzel a támadónak lehetõsége van lassú kapcsolatokkal leterhelni az adott démont, ezáltal kimeríteni a rendszer erõforrásait. Ha úgy találjuk, hogy túlságosan sok az ilyen kapcsolat, akkor jó ötletnek bizonyulhat a démonok számára a , vagy korlátozások elrendelése. Alapértelmezés szerint a TCP kapcsolatok wrappelése engedélyezett. A &man.hosts.access.5; man oldalon találhatjuk meg az inetd által meghívható különféle démonok TCP-alapú korlátozásainak lehetõségeit. Egyéb lehetõségek A daytime, time, echo, discard, chargen és auth szolgáltatások feladatainak mindegyikét maga az inetd is képes ellátni. Az auth szolgáltatás a hálózati keresztül azonosítást teszi lehetõvé és bizonyos mértékig beállítható. A többit egyszerûen csak kapcsoljuk ki vagy be. A témában az &man.inetd.8; man oldalán tudunk még jobban elmerülni. Tom Rhodes Átdolgozta és javította: Bill Swingle Írta: A hálózati állományrendszer (NFS) NFS A &os; több állományrendszert ismer, köztük a hálózati állományrendszert (Network File System, NFS) is. Az NFS állományok és könyvtárak megosztását teszi lehetõvé a hálózaton keresztül. Az NFS használatával a felhasználók és a programok képesek majdnem úgy elérni a távoli rendszereken található állományokat, mintha helyben léteznének. Íme az NFS néhány legjelentõsebb elõnye: A helyi munkaállomások kevesebb tárterületet használnak, mivel a közös adatokat csak egyetlen számítógépen tároljuk és megosztjuk mindenki között. A felhasználóknak nem kell a hálózat minden egyes gépén külön felhasználói könyvtárral rendelkezniük. Ezek ugyanis az NFS segítségével akár egy szerveren is beállíthatóak és elérhetõvé tehetõek a hálózaton keresztül. A különbözõ háttértárak, mint például a floppy lemezek, CD-meghajtók és &iomegazip; meghajtók a hálózaton több számítógép között megoszthatóak. Ezzel csökkenteni tudjuk a hálózatunkban szükséges cserélhetõ lemezes eszközök számát. Ahogy az <acronym>NFS</acronym> mûködik Az NFS legalább két fõ részbõl rakható össze: egy szerverbõl és egy vagy több kliensbõl. A kliensek a szerver által megosztott adatokhoz képesek távolról hozzáférni. A megfelelõ mûködéshez mindössze csak néhány programot kell beállítani és futtatni. A szervernek a következõ démonokat kell mûködtetnie: NFS szerver állományszerver UNIX kliensek rpcbind mountd nfsd Démon Leírás nfsd Az NFS démon, amely kiszolgálja az NFS kliensektõl érkezõ kéréseket. mountd Az NFS csatlakoztató démonja, amely végrehajtja az &man.nfsd.8; által átküldött kéréseket. rpcbind Ez a démon lehetõvé teszi az NFS kliensek számára, hogy fel tudják deríteni az NFS szerver által használt portot. A kliensen is futnia kell egy démonnak, amelynek a neve nfsiod. Az nfsiod démon az NFS szerver felõl érkezõ kéréseket szolgálja ki. A használata teljesen opcionális, csupán a teljesítményt hívatott javítani, de a normális és helyes mûködéshez nincs rá szükségünk. Az &man.nfsiod.8; man oldalán errõl többet is megtudhatunk. Az <acronym>NFS</acronym> beállítása NFS beállítás Az NFS beállítása viszonylag egyértelmûen adja magát. A mûködéséhez szükséges programok automatikus elindítása csupán néhány apró módosítást igényel az /etc/rc.conf állományban. Az NFS szerveren gondoskodjunk róla, hogy az alábbi beállítások szerepeljenek az /etc/rc.conf állományban: rpcbind_enable="YES" nfs_server_enable="YES" mountd_flags="-r" A mountd magától el fog indulni, ha az NFS szervert engedélyezzük. A kliensen a következõ beállítást kell felvennünk az /etc/rc.conf állományba: nfs_client_enable="YES" Az /etc/exports állomány adja meg, hogy az NFS milyen állományrendszereket exportáljon (vagy másképpen szólva osszon meg). Az /etc/exports állományban tehát a megosztani kívánt állományrendszereket kell szerepeltetnünk, és azt, hogy melyik számítógépekkel tudjuk ezeket elérni. A gépek megnevezése mellett a hozzáférésre további megszorításokat írhatunk fel. Ezek részletes leírását az &man.exports.5; man oldalon találjuk meg. Lássunk néhány példát az /etc/exports állományban megjelenõ bejegyzésekre: NFS példák exportálásra A most következõ példákban az állományrendszerek exportálásának finomságait igyekszünk érzékeltetni, noha a konkrét beállítások gyakran a rendszerünktõl és a hálózati konfigurációtól függenek. Például, ha a /cdrom könytárat akarjuk három gép számára megosztani, akik a szerverrel megegyezõ tartományban találhatóak (ezért nem is kell megadnunk a tartományt) vagy mert egyszerûen megtalálhatók az /etc/hosts állományunkban. Az beállítás az exportált állományrendszereket írásvédetté teszi. Ezzel a beállítással a távoli rendszerek nem lesznek képesek módosítani az exportált állományrendszer tartalmát. /cdrom -ro gép1 gép2 gép3 A következõ sorban a /home könyvtárat három gép számára osztjuk meg, melyeket IP-címekkel adtunk meg. Ez olyan helyi hálózat esetén hasznos, ahol nem állítottunk be névfeloldást. Esetleg a belsõ hálózati neveket az /etc/hosts állományban is tárolhatjuk. Ezzel utóbbival kapcsolatban a &man.hosts.5; man oldalt érdemes fellapoznunk. Az beállítás lehetõvé teszi, hogy az alkönyvtárak is csatlakozási pontok lehessenek. Más szóval, nem fogja csatlakoztatni az alkönyvtárakat, de megengedi a kliensek számára, hogy csak azokat a könyvtárakat csatlakoztassák, amelyeket kell vagy amelyekre szükségünk van. /home -alldirs 10.0.0.2 10.0.0.3 10.0.0.4 A következõ sorban az /a könyvtárat úgy exportáljuk, hogy az állományrendszerhez két különbözõ tartományból is hozzá lehessen férni. A beállítás hatására a távoli rendszer root felhasználója az exportált állományrendszeren szintén root felhasználóként fogja írni az adatokat. Amennyiben a -maproot=root beállítást nem adjuk meg, akkor a távoli rendszeren hiába root az adott felhasználó, az exportált állományrendszeren nem lesz képes egyetlen állományt sem módosítani. /a -maproot=root gep.minta.com doboz.haz.org A kliensek is csak a megfelelõ engedélyek birtokában képesek elérni a megosztott állományrendszereket. Ezért a klienst ne felejtsük el felvenni a szerver /etc/exports állományába. Az /etc/exports állományban az egyes sorok az egyes állományrendszerekre és az egyes gépekre vonatkoznak. A távoli gépek állományrendszerenként csak egyszer adhatóak meg, és csak egy alapértelmezett bejegyzésük lehet. Például tegyük fel, hogy a /usr egy önálló állományrendszer. Ennek megfelelõen az alábbi bejegyzések az /etc/exports állományban érvénytelenek: # Nem használható, ha a /usr egy állományrendszer: /usr/src kliens /usr/ports kliens Egy állományrendszerhez, vagyis itt a /usr partícióhoz, két export sort is megadtunk ugyanahhoz a kliens nevû géphez. Helyesen így kell megoldani az ilyen helyzeteket: /usr/src /usr/ports kliens Az adott géphez tartozó egy állományrendszerre vonatkozó exportoknak mindig egy sorban kell szerepelniük. A kliens nélkül felírt sorok egyetlen géphez tartozónak fognak számítani. Ezzel az állományrendszerek megosztását tudjuk szabályozni, de legtöbbek számára nem jelent gondot. Most egy érvényes exportlista következik, ahol a /usr és az /exports mind helyi állományrendszerek: # Osszuk meg az src és ports könyvtárakat a kliens01 és kliens02 részére, de csak a # kliens01 férhessen hozzá rendszeradminisztrátori jogokkal: /usr/src /usr/ports -maproot=root kliens01 /usr/src /usr/ports kliens02 # A kliensek az /exports könyvtárban teljes joggal rendelkeznek és azon belül # bármit tudnak csatlakoztatni. Rajtuk kívül mindenki csak írásvédetten képes # elérni az /exports/obj könyvtárat: /exports -alldirs -maproot=root kliens01 kliens02 /exports/obj -ro A mountd démonnal az /etc/exports állományt minden egyes módosítása után újra be kell olvastatni, mivel a változtatásaink csak így fognak érvényesülni. Ezt megcsinálhatjuk úgy is, hogy küldünk egy HUP (hangup, avagy felfüggesztés) jelzést a már futó démonnak: &prompt.root; kill -HUP `cat /var/run/mountd.pid` vagy meghívjuk a mountd &man.rc.8; szkriptet a megfelelõ paraméterrel: &prompt.root; /etc/rc.d/mountd onereload Az ban tudhatunk meg részleteket az rc szkriptek használatáról. Ezek után akár a &os; újraindításával is aktiválhatjuk a megosztásokat, habár ez nem feltétlenül szükséges. Ha root felhasználónként kiadjuk a következõ parancsokat, akkor azzal minden szükséges programot elindítunk. Az NFS szerveren tehát: &prompt.root; rpcbind &prompt.root; nfsd -u -t -n 4 &prompt.root; mountd -r Az NFS kliensen pedig: &prompt.root; nfsiod -n 4 Ezzel most már minden készen áll a távoli állományrendszer csatlakoztatására. A példákban a szerver neve szerver lesz, valamint a kliens neve kliens. Ha csak ideiglenesen akarunk csatlakoztatni egy állományrendszert vagy egyszerûen csak ki akarjuk próbálni a beállításainkat, a kliensen root felhasználóként az alábbi parancsot hajtsuk végre: NFS csatlakoztatás &prompt.root; mount szerver:/home /mnt Ezzel a szerveren található /home könyvtárat fogjuk a kliens /mnt könyvtárába csatlakoztatni. Ha mindent jól beállítottunk, akkor a kliensen most már be tudunk lépni az /mnt könyvtárba és láthatjuk a szerveren található állományokat. Ha a számítógép indításával automatikusan akarunk hálózati állományrendszereket csatlakoztatni, akkor vegyük fel ezeket az /etc/fstab állományba. Erre íme egy példa: szerver:/home /mnt nfs rw 0 0 Az &man.fstab.5; man megtalálhatjuk az összes többi beállítást. Zárolások Bizonyos alkalmazások (például a mutt) csak akkor mûködnek megfelelõen, ha az állományokat a megfelelõ módon zárolják. Az NFS esetében az rpc.lockd használható az ilyen zárolások megvalósítására. Az engedélyezéséhez mind a szerveren és a kliensen vegyük fel a következõ sort az /etc/rc.conf állományba (itt már feltételezzük, hogy az NFS szervert és klienst korábban beállítottuk): rpc_lockd_enable="YES" rpc_statd_enable="YES" A következõ módon indíthatjuk el: &prompt.root; /etc/rc.d/lockd start &prompt.root; /etc/rc.d/statd start Ha nincs szükségünk valódi zárolásra az NFS kliensek és az NFS szerver között, akkor megcsinálhatjuk azt is, hogy az NFS kliensen a &man.mount.nfs.8; programnak az paraméter átadásával csak helyileg végzünk zárolást. Ennek további részleterõl a &man.mount.nfs.8; man oldalon kaphatunk felvilágosítást. Gyakori felhasználási módok Az NFS megoldását a gyakorlatban rengeteg esetben alkalmazzák. Ezek közül most felsoroljuk a legelterjedtebbeket: NFS használata Több gép között megosztunk egy telepítõlemezt vagy más telepítõeszközt. Ez így sokkal olcsóbb és gyakorta kényelmes megoldás abban az esetben, ha egyszerre több gépre akarjuk ugyanazt a szoftvert telepíteni. Nagyobb hálózatokon sokkal kényelmesebb lehet egy központi NFS szerver használata, ahol a felhasználók könyvtárait tároljuk. Ezek a felhasználói könyvtárak aztán megoszthatóak a hálózaton keresztül, így a felhasználók mindig ugyanazt a könyvárat kapják függetlenül attól, hogy milyen munkaállomásról is jelentkeztek be. Több géppel is képes így osztozni az /usr/ports/distfiles könyvtáron. Ezen a módon sokkal gyorsabban tudunk portokat telepíteni a gépekre, mivel nem kell külön mindegyikre letölteni az ehhez szükséges forrásokat. Wylie Stilwell Készítette: Chern Lee Újraírta: Automatikus csatlakoztatás az <application>amd</application> használatával amd automatikus csatlakoztató démon Az &man.amd.8; (automatikus csatlakoztató démon, az automatic mounter daemon) önmûködõen csatlakoztatja a távoli állományrendszereket, amikor azokon belül valamelyik állományhoz vagy könyvtárhoz próbálunk hozzáférni. Emellett az amd az egy ideje már inaktív állományrendszereket is automatikusan leválasztja. Az amd használata egy remek alternatívát kínál az általában az /etc/fstab állományban megjelenõ állandóan csatlakoztatott állományrendszerekkel szemben. Az amd úgy mûködik, hogy kapcsolódik egy NFS szerver /host és /net könyvtáraihoz. Amikor egy állományt akarunk elérni ezeken a könyvtárakon belül, az amd kikeresi a megfelelõ távoli csatlakoztatást és magától csatlakoztatja. A /net segítségével egy IP-címrõl tudunk exportált állományrendszereket csatlakoztatni, miközben a /host a távoli gép hálózati neve esetében használatos. Ha tehát a /host/izemize/usr könyvtárban akarunk elérni egy állományt, akkor az amd démonnak ahhoz elõször az izemize nevû géprõl exportált /usr könyvtárat kell csatlakoztatnia. Egy exportált állományrendszer csatlakoztatása az <application>amd</application> használatával Egy távoli számítógép által rendelkezésre bocsátott megosztásokat a showmount paranccsal tudjuk lekérdezni. Például az izemize gépen elérhetõ exportált állományrendszereket így láthatjuk: &prompt.user; showmount -e izemize Exports list on izemize: /usr 10.10.10.0 /a 10.10.10.0 &prompt.user; cd /host/izemize/usr Ahogy a példában látjuk is, a showmount parancs a /usr könyvtárat mutatja megosztásként. Amikor tehát belépünk a /host/izemize/usr könyvtárba, akkor amd magától megpróbálja feloldani az izemize hálózati nevet és csatlakoztatni az elérni kívánt exportált állományrendszert. Az amd az indító szkripteken keresztül az /etc/rc.conf alábbi beállításával engedélyezhetõ: amd_enable="YES" Emellett még az amd_flags használatával további paraméterek is átadható az amd felé. Alapértelmezés szerint az amd_flags tartalmaz az alábbi: amd_flags="-a /.amd_mnt -l syslog /host /etc/amd.map /net /etc/amd.map" Az /etc/amd.map állomány adja meg az exportált állományrendszerek alapértelmezett beállításait. Az /etc/amd.conf állományban az amd további lehetõségeit konfigurálhatjuk.. Ha többet is szeretnénk tudni a témáról, akkor az &man.amd.8; és az &man.amd.conf.5; man oldalakat javasolt elolvasnunk. John Lind Készítette: Problémák más rendszerek használatakor Némely PC-s ISA buszos Ethernet kártyákra olyan korlátozások érvényesek, melyek komoly hálózati problémák keletkezéséhez vezethetnek, különösen az NFS esetében. Ez a nehézség nem &os;-függõ, de a &os; rendszereket is érinti. Ez gond általában majdnem mindig akkor merül fel, amikor egy (&os;-s) PC egy hálózatba kerül többek közt a Silicon Graphic és a Sun Microsystems által gyártott nagyteljesítményû munkaállomásokkal. Az NFS csatlakoztatása és bizonyos mûveletek még hibátlanul végrehajtódnak, azonban hirtelen a szerver látszólag nem válaszol többet a kliens felé úgy, hogy a többi rendszertõl folyamatosan dolgozza felfele a kéréseket. Ez a kliens rendszeren tapasztalható csak, amikor a kliens &os; vagy egy munkaállomás. Sok rendszeren egyszerûen rendesen le sem lehet állítani a klienst, ha a probléma egyszer már felütötte a fejét. Egyedüli megoldás gyakran csak a kliens újraindítása marad, mivel az NFS-ben kialakult helyzetet máshogy nem lehet megoldani. Noha a helyes megoldás az lenne, ha beszereznénk egy nagyobb teljesítményû és kapacitású kártyát a &os; rendszer számára, azonban egy jóval egyszerûbb kerülõút is található a kielégítõ mûködés eléréséhez. Ha a &os; rendszer képviseli a szervert, akkor a kliensnél adjuk meg a beállítást is a csatlakoztatásnál. Ha a &os; rendszer a kliens szerepét tölti be, akkor az NFS állományrendszert az beállítással csatlakoztassuk róla. Ezek a beállítások az fstab állomány negyedik mezõjében is megadhatóak az automatikus csatlakoztatáshoz, vagy manuális esetben a &man.mount.8; parancsnak a paraméterrel. Hozzá kell azonban tennünk, hogy létezik egy másik probléma, amit gyakran ezzel tévesztenek össze, amikor az NFS szerverek és kliensek nem ugyanabban a hálózatban találhatóak. Ilyen esetekben mindenképpen gyõzõdjünk meg róla, hogy az útválasztók rendesen továbbküldik a mûködéshez szükséges UDP információkat, különben nem sokat tudunk tenni a megoldás érdekében. A most következõ példákban a gyorsvonat lesz a nagyteljesítményû munkaállomás (felület) neve, illetve a freebsd pedig a gyengébb teljesítményû Ethernet kártyával rendelkezõ &os; rendszer (felület) neve. A szerveren az /osztott nevû könyvtárat fogjuk NFS állományrendszerként exportálni (lásd &man.exports.5;), amelyet majd a /projekt könyvtárba fogunk csatlakoztatni a kliensen. Minden esetben érdemes lehet még megadnunk a vagy , illetve opciókat is. Ebben a példában a &os; rendszer (freebsd) lesz a kliens, és az /etc/fstab állományában így szerepel az exportált állományrendszer: gyorsvonat:/osztott /projekt nfs rw,-r=1024 0 0 És így tudjuk manuálisan csatlakoztatni: &prompt.root; mount -t nfs -o -r=1024 gyorsvonat:/osztott /projekt Itt a &os; rendszer lesz a szerver, és a gyorsvonat /etc/fstab állománya így fog kinézni: freebsd:/osztott /projekt nfs rw,-w=1024 0 0 Manuálisan így csatlakoztathatjuk az állományrendszert: &prompt.root; mount -t nfs -o -w=1024 freebsd:/osztott /projekt Szinte az összes 16 bites Ethernet kártya képes mûködni a fenti írási vagy olvasási korlátozások nélkül is. A kíváncsibb olvasók számára eláruljuk, hogy pontosan miért is következik be ez a hiba, ami egyben arra is magyarázatot ad, hogy miért nem tudjuk helyrehozni. Az NFS általában 8 kilobyte-os blokkokkal dolgozik (habár kisebb méretû darabkákat is tud készíteni). Mivel az Ethernet által kezelt legnagyobb méret nagyjából 1500 byte, ezért az NFS blokkokat több Ethernet csomagra kell osztani — még olyankor is, ha ez a program felsõbb rétegeiben osztatlan egységként látszik — ezt aztán fogadni kell, összerakni és nyugtázni mint egységet. A nagyteljesítményû munkaállomások a szabvány által még éppen megengedett szorossággal képesek ontani magukból az egy egységhez tartozó csomagokat, közvetlenül egymás után. A kisebb, gyengébb teljesítményû kártyák esetében azonban az egymáshoz tartozó, késõbb érkezõ csomagok ráfutnak a korábban megkapott csomagokra még pontosan azelõtt, hogy elérnék a gépet, így az egységek nem állíthatóak össze vagy nem nyugtázhatóak. Ennek eredményeképpen a munkaállomás egy adott idõ múlva megint próbálkozik, de ismét az egész 8 kilobyte-os blokkot küldi el, ezért ez a folyamat a végtelenségig ismétlõdik. Ha a küldendõ egységek méretét az Ethernet által kezelt csomagok maximális mérete alá csökkentjük, akkor biztosak lehetünk benne, hogy a teljes Ethernet csomag egyben megérkezik és nyugtázódik, így elkerüljük a holtpontot. A nagyteljesítményû munkaállomások természetesen továbbra is küldhetnek a PC-s rendszerek felé túlfutó csomagokat, de egy jobb kártyával az ilyen túlfutások nem érintik az NFS által használt egységeket. Amikor egy ilyen túlfutás bekövetkezik, az érintett egységet egyszerûen újra elküldik, amelyet a rákövetkezõ alkalommal nagy valószínûséggel már tudunk rendesen fogadni, összerakni és nyugtázni. Bill Swingle Írta: Eric Ogren Írta: Udo Erdelhoff Hálózati információs rendszer (NIS/YP) Mi ez? NIS Solaris HP-UX AIX Linux NetBSD OpenBSD A hálózati információs szolgáltatást (Network Information Service, avagy NIS) a Sun Microsystems fejlesztette ki a &unix; (eredetileg &sunos;) rendszerek központosított karbantartásához. Mostanra már lényegében ipari szabvánnyá nõtte ki magát, hiszen az összes nagyobb &unix;-szerû rendszer (a &solaris;, HP-UX, &aix;, Linux, NetBSD, OpenBSD, &os; stb.) támogatja a NIS használatát. sárga oldalak NIS A NIS régebben sárga oldalak (Yellow Pages) néven volt ismert, de a különbözõ jogi problémák miatt késõbb ezt a Sun megváltoztatta. A régi elnevezést (és a yp rövidítést) azonban még napjainkban is lehet néhol látni. NIS tartományok Ez egy RPC alapján mûködõ, kliens/szerver felépítésû rendszer, amely az egy NIS tartomány belül levõ számítógépek számára teszi lehetõvé ugyanazon konfigurációs állományok használatát. Segítségével a rendszergazda a NIS klienseket a lehetõ legkevesebb adat hozzáadásával, eltávolításával vagy módosításával képes egyetlen helyrõl beállítani. Windows NT Hasonló a &windowsnt; tartományaihoz, és habár a belsõ implementációt tekintve már akadnak köztük jelentõs eltérések is, az alapvetõ funkciók szintjén mégis összevethetõek. A témához tartozó fogalmak és programok A NIS telepítése számos fogalom és fontos felhasználói program kerül elõ &os;-n, akár egy NIS szervert akarunk beállítani, akár csak egy NIS klienst: rpcbind portmap Fogalom Leírás NIS tartománynév A NIS központi szerverei és az összes hozzájuk tartozó kliens (beleértve az alárendelt szervereket) rendelkezik egy NIS tartománynévvel. Hasonló a &windowsnt; által használt tartománynevekhez, de a NIS tartománynevei semmilyen kapcsolatban nem állnak a névfeloldással. rpcbind Az RPC (Remote Procedure Call, a NIS által használt egyik hálózati protokoll) engedélyezéséhez lesz rá szükségünk. Ha az rpcbind nem fut, akkor sem NIS szervert, sem pedig NIS klienst nem tudunk mûködtetni. ypbind A NIS klienst köti össze a hozzátartozó NIS szerverrel. A NIS tartománynevet a rendszertõl veszi, és az RPC használatával csatlakozik a szerverhez. Az ypbind a NIS környezet kliens és szerver közti kommunikációjának magját alkotja. Ha az ypbind leáll a kliens gépén, akkor nem tudjuk elérni a NIS szervert. ypserv Csak a NIS szervereken szabad futnia, mivel ez maga a NIS szerver programja. Ha az &man.ypserv.8; leáll, akkor a szerver nem lesz képes tovább kiszolgálni a NIS kéréseket (szerencsére az alárendelt szerverek képesek átvenni ezeket). A NIS bizonyos változatai (de nem az, amelyik a &os;-ben is megjelenik) nem próbálnak meg más szerverekhez csatlakozni, ha bedöglik az aktuális használt szerver. Ezen gyakran egyedül csak a szervert képviselõ program (vagy akár az egész szerver) újraindítása segíthet, illetve az ypbind újraindítása a kliensen. rpc.yppasswdd Ez egy olyan program, amelyet csak a NIS központi szerverein kell csak futtatni. Ez a démon a NIS kliensek számára a NIS jelszavaik megváltoztatását teszi lehetõvé. Ha ez a démon nem fut, akkor a felhasználók csak úgy tudják megváltoztatni a jelszavukat, ha bejelentkeznek a központi NIS szerverre. Hogyan mûködik? A NIS környezetekben háromféle gép létezik: a központi szerverek, az alárendelt szerverek és a kliensek. A szerverek képezik a gépek konfigurációs információinak központi tárhelyét. A központi szerverek tárolják ezen információk hiteles másolatát, míg ezt az alárendelt szerverek redundánsan tükrözik. A kliensek a szerverekre támaszkodnak ezen információk beszerzéséhez. Sok állomány tartalma megosztható ezen a módon. Például a master.passwd, a group és hosts állományokat meg szokták osztani NFS-en. Amikor a kliensen futó valamelyik programnak olyan információra lenne szüksége, amely általában ezekben az állományokban nála megtalálható lenne, akkor helyette a NIS szerverhez fordul. A gépek típusai NIS központi szerver A központi NIS szerver. Ez a szerver, amely leginkább a &windowsnt; elsõdleges tartományvezérlõjéhez hasonlítható tartja karban az összes, NIS kliensek által használt állományt. A passwd, group, és összes többi ehhez hasonló állomány ezen a központi szerveren található meg. Egy gép akár több NIS tartományban is lehet központi szerver. Ezzel a lehetõséggel viszont itt most nem foglalkozunk, mivel most csak egy viszonylag kis méretû NIS környezetet feltételezünk. NIS alárendelt szerver Az alárendelt NIS szerverek. A &windowsnt; tartalék tartományvezérlõihez hasonlítanak, és az alárendelt NIS szerverek feladata a központi NIS szerveren tárolt adatok másolatainak karbantartása. Az alárendelt NIS szerverek a redundancia megvalósításában segítenek, aminek leginkább a fontosabb környezetekben van szerepe. Emellett a központi szerver terhelésének kiegyenlítését is elvégzik. A NIS kliensek elsõként mindig ahhoz a NIS szerverhez csatlakoznak, amelytõl elõször választ kapnak, legyen akár az egy alárendelt szerver. NIS kliens A NIS kliensek. A NIS kliensek, hasonlóan a &windowsnt; munkaállomásokhoz, a NIS szerveren (amely a &windowsnt; munkaállomások esetében a tartományvezérlõ) keresztül jelentkeznek be. A NIS/YP használata Ebben a szakaszban egy példa NIS környezetet állítunk be. Tervezés Tegyük fel, hogy egy aprócska egyetemi labor rendszergazdái vagyunk. A labor, mely 15 &os;-s gépet tudhat magáénak, jelen pillanatban még semmilyen központosított adminisztráció nem létezik. Mindegyik gép saját /etc/passwd és /etc/master.passwd állománnyal rendelkezik. Ezeket az állományokat saját kezûleg kell szinkronban tartani. Tehát ha most felveszünk egy felhasználót a laborhoz, akkor az adduser parancsot mind a 15 gépen ki kell adni. Egyértelmû, hogy ez így nem maradhat, ezért úgy döntöttük, hogy a laborban NIS-t fogunk használni, és két gépet kinevezünk szervernek. Az iméntieknek megfelelõen a labor most valahogy így néz ki: A gép neve IP-cím A gép szerepe ellington 10.0.0.2 központi NIS coltrane 10.0.0.3 alárendelt NIS basie 10.0.0.4 tanszéki munkaállomás bird 10.0.0.5 kliensgép cli[1-11] 10.0.0.[6-17] a többi kliensgép Ha még nincs tapasztalatunk a NIS rendszerek összeállításában, akkor elõször jó ötlet lehet végiggondolni, miként is akarjuk kialakítani. A hálózatunk méretétõl függetlenül is akadnak olyan döntések, amelyeket mindenképpen meg kell hoznunk. A NIS tartománynév megválasztása NIS tartománynév Ez nem az a tartománynév, amit megszokhattunk. Ennek a pontos neve NIS tartománynév. Amikor a kliensek kérnek valamilyen információt, akkor megadják annak a NIS tartománynak a nevét is, amelynek részei. Így tud egy hálózaton több szerver arról dönteni, hogy melyikük melyik kérést válaszolja meg. A NIS által használt tartománynévre tehát inkább úgy érdemes gondolni, mint egy valamilyen módon összetartozó gépek közös nevére. Elõfordul, hogy egyes szervezetek az interneten is nyilvántartott tartománynevüket választják NIS tartománynévnek. Ez alapvetõen nem ajánlott, mivel a hálózati problémák felderítése közben félreértéseket szülhet. A NIS tartománynévnek a hálózatunkon belül egyedinek kell lennie, és lehetõleg minél jobban írja le az általa csoportba sorolt gépeket. Például a Kis Kft. üzleti osztályát tegyük a kis-uzlet NIS tartományba. Ebben a példában most a proba-tartomany nevet választottuk. SunOS A legtöbb operációs rendszer azonban (köztük a &sunos;) a NIS tartománynevet használja internetes tartománynévként is. Ha a hálózatunkon egy vagy több ilyen gép is található, akkor a NIS tartomány nevének az internetes tartománynevet kell megadnunk. A szerverek fizikai elvárásai Nem árt néhány dolgot fejben tartani, amikor a NIS szervernek használt gépet kiválasztjuk. Az egyik ilyen szerencsétlen dolog az a szintû függõség, ami a NIS kliensek felõl megfigyelhetõ a szerverek felé. Ha egy kliens nem tudja a NIS tartományon belül felvenni a kapcsolatot valamelyik szerverrel, akkor az a gép könnyen megbízhatatlanná válhat. Felhasználói- és csoportinformációk nélkül a legtöbb rendszer egy idõre le is merevedik. Ennek figyelembevételével tehát olyan gépet kell szervernek választanunk, amelyet nem kell gyakran újraindítani, és nem végzünk rajta semmilyen komoly munkát. A célnak legjobban megfelelõ NIS szerverek valójában olyan gépek, amelyek egyedüli feladata csak a NIS kérések kiszolgálása. Ha a hálózatunk nem annyira leterhelt, akkor még a NIS szerver mellett más programokat is futtathatunk, de ne feledjük, hogy ha a NIS szolgáltatás megszûnik, akkor az az összes NIS kliensen éreztetni fogja kedvezõtlen hatását. A NIS szerverek A NIS rendszerben tárolt összes információ általános példánya egyetlen gépen található meg, amelyet a központi NIS szervernek hívunk. Az információk tárolására szánt adatbázis pedig NIS táblázatoknak (NIS map) nevezzük. &os; alatt ezek a táblázatok a /var/yp/tartománynév könyvtárban találhatóak, ahol a tartománynév a kiszolgált NIS tartományt nevezi meg. Egyetlen NIS szerver egyszerre akár több tartományt is kiszolgálhat, így itt több könyvtár is található, minden támogatott tartományhoz egy. Minden tartomány saját, egymástól független táblázatokkal rendelkezik. A központi és alárendelt NIS szerverek az ypserv démon segítségével dolgozzák fel a NIS kéréseket. Az ypserv felelõs a NIS kliensektõl befutó kérések fogadásáért, és a kért tartomány valamint táblázat nevébõl meghatározza az adatbázisban tárolt állományt, majd innen visszaküldi a hozzátartozó adatot a kliensnek. A központi NIS szerver beállítása NIS szerver beállítása A központi NIS szerver beállítása viszonylag magától értetõdõ, de a nehézségét az igényeink szabják meg. A &os; alapból támogatja a NIS használatát. Ezért mindössze annyit kell tennünk, hogy a következõ sorokat betesszük az /etc/rc.conf állományba, és a &os; gondoskodik a többirõl. nisdomainname="proba-tartomany" Ez a sor adja meg a hálózati beállítások (vagy például az újraindítás) során a NIS tartomány nevét, amely a korábbiak szerint itt most a proba-tartomany. nis_server_enable="YES" Ezzel utasítjuk a &os;-t, hogy a hálózati alkalmazások következõ indításakor a NIS szervert is aktiválja. nis_yppasswdd_enable="YES" Ezzel engedélyezzük az rpc.yppasswdd démont, amely a korábban említettek szerint lehetõvé teszi a felhasználók számára, hogy a közvetlenül a kliensekrõl változtassák meg a NIS jelszavukat. A konkrét NIS beállításainktól függõen további bejegyzések felvételére is szükségünk lehet. Erre késõbb még az olyan NIS szervereknél, amelyek egyben NIS kliensek, vissza fogunk térni. - Most mindössze annyit kell tennünk, hogy - rendszeradminisztrátorként kiadjuk az + Miután ezeket beállítottuk, + rendszeradminisztrátorként adjuk ki az /etc/netstart parancsot. Az /etc/rc.conf állományban szereplõ adatok alapján mindent - beállít magától. + beállít magától. Még + mielõtt inicializálnánk a NIS + táblázatokat, indítsuk el + manuálisan az ypserv + démont: + &prompt.root; /etc/rc.d/ypserv start A NIS táblázatok inicializálása NIS táblázatok A NIS táblázatok lényegében a /var/yp könyvtárban tárolt adatbázisok. A központi NIS szerver /etc könyvtárában található konfigurációs állományokból állítódnak elõ, egyetlen kivétellel: ez az /etc/master.passwd állomány. Ennek megvan a maga oka, hiszen nem akarjuk a root és az összes többi fontosabb felhasználóhoz tartozó jelszót az egész NIS tartománnyal megosztani. Ennek megfelelõen a NIS táblázatok inicializálásához a következõt kell tennünk: &prompt.root; cp /etc/master.passwd /var/yp/master.passwd &prompt.root; cd /var/yp &prompt.root; vi master.passwd El kell távolítanunk az összes rendszerszintû (bin, tty, kmem, games, stb), és minden olyan egyéb hozzáférést, amelyeket nem akarjuk közvetíteni a NIS kliensek felé (például a root és minden más nullás, vagyis rendszeradminisztrátori azonosítóval ellátott hozzáférést). Gondoskodjunk róla, hogy az /var/yp/master.passwd állomány sem a csoport, sem pedig bárki más számára nem olvasható (600-as engedély)! Ennek beállításához használjuk az chmod parancsot, ha szükséges. Tru64 UNIX Ha végeztünk, akkor már tényleg itt az ideje inicializálni NIS táblázatainkat. A &os; erre egy ypinit nevû szkriptet ajánl fel (errõl a saját man oldalán tudhatunk meg többet). Ez a szkript egyébként a legtöbb &unix; típusú operációs rendszeren megtalálható, de nem az összesen. A Digital UNIX/Compaq Tru64 UNIX rendszereken ennek a neve ypsetup. Mivel most a központi NIS szerver táblázatait hozzuk létre, azért az ypinit szkriptnek át kell adnunk a opciót is. A NIS táblázatok elõállításánál feltételezzük, hogy a fentebb ismertetett lépéseket már megtettük, majd kiadjuk ezt a parancsot: ellington&prompt.root; ypinit -m proba-tartomany Server Type: MASTER Domain: proba-tartomany Creating an YP server will require that you answer a few questions. Questions will all be asked at the beginning of the procedure. Do you want this procedure to quit on non-fatal errors? [y/n: n] n Ok, please remember to go back and redo manually whatever fails. If you don't, something might not work. At this point, we have to construct a list of this domains YP servers. rod.darktech.org is already known as master server. Please continue to add any slave servers, one per line. When you are done with the list, type a <control D>. master server : ellington next host to add: coltrane next host to add: ^D The current list of NIS servers looks like this: ellington coltrane Is this correct? [y/n: y] y [ .. a táblázatok generálása .. ] NIS Map update completed. ellington has been setup as an YP master server without any errors. Az üzenetek fordítása: A szerver típusa: KÖZPONTI, tartomány: proba-tartomany Az YP szerver létrehozásához meg kell válaszolni néhány kérdést az eljárás megkezdése elõtt. Szeretnénk, ha az eljárás megszakadna a nem végzetes hibák esetén is? [i/n: n] n Rendben, akkor ne felejtsük el manuálisan kijavítani a hibát, ha valamivel gond lenne. Ha nem tesszük meg, akkor elõfordulhat, hogy valami nem fog rendesen mûködni. Most össze kell állítanunk egy listát a tartomány YP szervereirõl. Jelenleg a rod.darktech.org a központi szerver. Kérjünk, adjon meg további alárendelt szervereket, soronként egyet. Amikor ezt befejeztük, a <control D> lenyomásával tudunk kilépni. központi szerver : ellington következõ gép : coltrane következõ gép : ^D A NIS szerverek listája jelenleg a következõ: ellington coltrane Ez megfelelõ? [i/n: i] i [ .. a táblázatok generálása .. ] A NIS táblázatok sikeressen frissültek. Az elligon szervert minden hiba nélkül sikerült központi szerverként beállítani. Az ypinit a /var/yp/Makefile.dist állományból létrehozza a /var/yp/Makefile állományt. Amennyiben ez létrejött, az állomány feltételezi, hogy csak &os;-s gépek részvételével akarunk kialakítani egy egyszerveres NIS környezetet. Mivel a proba-tartomany még egy alárendelt szervert is tartalmaz, ezért át kell írnunk a /var/yp/Makefile állományt: ellington&prompt.root; vi /var/yp/Makefile Ezt a sort kell megjegyzésbe tennünk: NOPUSH = "True" (ha még nem lenne úgy). Az alárendelt NIS szerverek beállítása NIS alárendelt szerver Az alárendelt NIS szerverek beállítása még a központinál is egyszerûbb. Jelentkezzünk be az alárendelt szerverre és az eddigieknek megfelelõen írjuk át az /etc/rc.conf állományt. Az egyetlen különbség ezúttal csupán annyi lesz, hogy az ypinit lefuttatásakor a opciót kell megadnunk (mint slave, vagyis alárendelt). A opció használatához a központi NIS szerver nevét is át kell adnunk, ezért a konkrét parancs valahogy így fog kinézni: coltrane&prompt.root; ypinit -s ellington proba-tartomany Server Type: SLAVE Domain: test-domain Master: ellington Creating an YP server will require that you answer a few questions. Questions will all be asked at the beginning of the procedure. Do you want this procedure to quit on non-fatal errors? [y/n: n] n Ok, please remember to go back and redo manually whatever fails. If you don't, something might not work. There will be no further questions. The remainder of the procedure should take a few minutes, to copy the databases from ellington. Transferring netgroup... ypxfr: Exiting: Map successfully transferred Transferring netgroup.byuser... ypxfr: Exiting: Map successfully transferred Transferring netgroup.byhost... ypxfr: Exiting: Map successfully transferred Transferring master.passwd.byuid... ypxfr: Exiting: Map successfully transferred Transferring passwd.byuid... ypxfr: Exiting: Map successfully transferred Transferring passwd.byname... ypxfr: Exiting: Map successfully transferred Transferring group.bygid... ypxfr: Exiting: Map successfully transferred Transferring group.byname... ypxfr: Exiting: Map successfully transferred Transferring services.byname... ypxfr: Exiting: Map successfully transferred Transferring rpc.bynumber... ypxfr: Exiting: Map successfully transferred Transferring rpc.byname... ypxfr: Exiting: Map successfully transferred Transferring protocols.byname... ypxfr: Exiting: Map successfully transferred Transferring master.passwd.byname... ypxfr: Exiting: Map successfully transferred Transferring networks.byname... ypxfr: Exiting: Map successfully transferred Transferring networks.byaddr... ypxfr: Exiting: Map successfully transferred Transferring netid.byname... ypxfr: Exiting: Map successfully transferred Transferring hosts.byaddr... ypxfr: Exiting: Map successfully transferred Transferring protocols.bynumber... ypxfr: Exiting: Map successfully transferred Transferring ypservers... ypxfr: Exiting: Map successfully transferred Transferring hosts.byname... ypxfr: Exiting: Map successfully transferred coltrane has been setup as an YP slave server without any errors. Don't forget to update map ypservers on ellington. Most már lennie kell egy /var/yp/proba-tartomany nevû könyvtárunknak is. A központi NIS szerver táblázatainak másolata itt fognak tárolódni. Ezeket soha ne felejtsük el frissen tartani. Az alárendelt szervereken a következõ /etc/crontab bejegyzések pontosan ezt a feladatot látják el: 20 * * * * root /usr/libexec/ypxfr passwd.byname 21 * * * * root /usr/libexec/ypxfr passwd.byuid Ez a két sor gondoskodik róla, hogy az alárendelt szerverek ne felejtsék el egyeztetni a táblázataikat a központi szerver táblázataival. 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 hét múlva ismét változik a házirend: az IT tanszékre ösztöndíjasok érkeznek. Az IT ösztöndíjasai a munkaállomásokat és a kevésbé fontosabb szervereket tudják használni. Az új IT dolgozók már a központi szerverekre is bejelentkezhetnek. Így tehát létrehozunk egy új hálózati csoportot IT_OSZTONDIJAS néven, majd felvesszük ide az új IT ösztöndíjasokat, és nekilátunk végigzongorázni az összes gép összes konfigurációs állományát... Ahogy azonban egy régi mondás is tartja: A központosított tervezésben ejtett hibák teljes káoszhoz vezetnek. A NIS az ilyen helyzeteket úgy igyekszik elkerülni, hogy megengedi újabb hálózati csoportok létrehozását más hálózati csoportokból. Egyik ilyen lehetõség a szerep alapú hálózati csoportok kialakítása. Például, ha a fontosabb szerverek bejelentkezési korlátozásai számára hozzunk létre egy NAGYSRV nevû csoportot, valamint egy másik hálózati csoportot KISSRV néven a kevésbé fontosabb szerverekhez, végül MUNKA néven egy harmadik hálózati csoportot a munkaállomásokhoz. Mindegyik ilyen hálózati csoport tartalmazza azokat a csoportokat, amelyek engedélyezik a gépek elérését. A hálózati csoportok leírását tartalmazó NIS táblázat most valahogy így fog kinézni: NAGYSRV IT_DOLG IT_UJDOLG KISSRV IT_DOLG IT_UJDOLG IT_OSZTONDIJAS MUNKA IT_DOLG IT_OSZTONDIJAS FELHASZNALOK A bejelentkezési megszorítások ilyen típusú megadása viszonylag jól mûködik, hogy ha azonos korlátozások alá esõ gépek csoportjait akarjuk felírni. Bánatunk ez a kivétel, és nem a szabály. Az esetek nagy többségében ugyanis a bejelentkezésre vonatkozó korlátozásokat gépenként kell egyesével megadni. A hálózati csoportok gépfüggõ megadása tehát az iménti házirendhez társuló igények kielégítésének egyik módja. Ebben a forgatókönyvben az /etc/master.passwd állomány minden számítógépen két +-os sorral kezdõdik. Közülük az elsõ a gépen engedélyezett hozzáféréseket tartalmazó hálózati csoportra vonatkozik, a második pedig az összes többi hozzáféréshez az /sbin/nologin parancsértelmezõt kapcsolja hozzá. Itt jó ötlet, ha a gép nevének VÉGIG-NAGYBETÛS változatát adjuk meg a hozzátartozó hálózati csoport nevének: +@GÉPNÉV::::::::: +:::::::::/sbin/nologin Miután elvégeztük ezt a feladatot minden egyes gépen, az /etc/master.passwd állomány helyi változatait soha többé nem kell módosítanunk. Az összes többi változtatást a NIS táblázaton keresztül tudjuk keresztül vinni. Íme a felvázolt forgatókönyvhöz tartozó hálózati csoportok kiépítésének egyik lehetséges változata, egy-két finomsággal kiegészítve: # Elõször a felhasználók csoportjait adjuk meg: IT_DOLG (,alpha,proba-tartomany) (,beta,proba-tartomany) IT_UJDOLG (,charlie,proba-tartomany) (,delta,proba-tartomany) TANSZ1 (,echo,proba-tartomany) (,foxtrott,proba-tartomany) TANSZ2 (,golf,proba-taromany) (,hotel,proba-tartomany) TANSZ3 (,india,proba-taromany) (,juliet,proba-tartomany) IT_OSZTONDIJAS (,kilo,proba-tartomany) (,lima,proba-tartomany) D_OSZTONDIJAS (,able,proba-tartomany) (,baker,proba-tartomany) # # Most pedig hozzunk létre csoportokat szerepek szerint: FELHASZNALOK TANSZ1 TANSZ2 TANSZ3 NAGYSRV IT_DOLG IT_UJDOLG KISSRV IT_DOLG IT_UJDOLG IT_OSZTONDIJAS MUNKA IT_DOLG IT_OSZTONDIJAS FELHASZNALOK # # Következzenek a speciális feladatokhoz tartozó csoportok: # Az echo és a golf tudja elérni a vírusvédelemért felelõs gépet: VEDELEM IT_DOLG (,echo,proba-tartomany) (,golf,proba-tartomany) # # Gép alapú hálózati csoportok # A fõ szervereink: HABORU NAGYSRV EHSEG NAGYSRV # Az india nevû felhasználó hozzá szeretné ehhez férni: SZENNYEZES NAGYSRV (,india,proba-tartomany) # # Ez valóban fontos és komolyan szabályoznunk kell: HALAL IT_DOLG # # Az elõbb említett vírusvédelmi gép: EGY VEDELEM # # Egyetlen felhasználóra korlátozzuk le ezt a gépet: KETTO (,hotel,proba-tartomany) # [...és itt folytatódik a többi csoporttal] Ha a felhasználói hozzáféréseinket valamilyen adatbázisban tároljuk, akkor a táblázat elsõ részét akár az adatbázis lekérdezésein keresztül is elõ tudjuk állítani. Ezzel a módszerrel az új felhasználók automatikusan hozzáférnek a gépekhez. Legyünk viszont óvatosak: nem mindig javasolt gépeken alapuló hálózati csoportokat készíteni. Ha a hallgatói laborokba egyszerre több tucat vagy akár több száz azonos konfigurációjú gépet telepítünk, akkor a gép alapú csoportok helyett inkább szerep alapú csoportokat építsünk fel, mivel így a NIS táblázatok méretét egy elfogadható méreten tudjuk tartani. Amit feltétlenül észben kell tartanunk Még mindig akad néhány olyan dolog, amit másképpen kell csinálnunk azután, hogy most már NIS környezetben vagyunk. Amikor egy új felhasználót akarunk felvenni a laborba, akkor csak a központi NIS szerverre kell felvennünk, és újra kell generáltatnunk a NIS táblázatokat. Ha ezt elfelejtjük megtenni, akkor az új felhasználó a központi NIS szerveren kívül sehova sem lesz képes bejelentkezni. Például, ha fel akarjuk venni a jsmith nevû felhasználót a laborba, akkor ezt kell tennünk: &prompt.root; pw useradd jsmith &prompt.root; cd /var/yp &prompt.root; make proba-tartomany Vagy a pw useradd jsmith parancs helyett az adduser jsmith parancsot is használhatjuk. A rendszergazdai szintû hozzáféréseket ne tároljuk a NIS táblázatokban. Olyan gépekre egyáltalán ne is küldjünk olyan karbantartáshoz használt hozzáféréseket, amelynek a felhasználói hivatalosan nem is férhetnének hozzájuk. A központi NIS szervert és az alárendelt szervereket óvjuk minél jobban, és igyekezzünk minimalizálni a kieséseiket. Ha valaki feltöri vagy egyszerûen csak kikapcsolja ezeket a gépeket, akkor ezzel lényegében mindenkit megakadályoz abban, hogy be tudjon jelentkezni a laborban. Ezek a központosított vezérlésû rendszerek legfõbb gyengeségei. Ha nem védjük kellõen a NIS szervereinket, akkor azzal nagyon ellenséget szerezhetünk magunknak! Kompatibilitás a NIS elsõ változatával A &os;-ben megtalálható ypserv szolgáltatás valamennyire képes ellátni a NIS elsõ változatát használó klienseket is. A &os; NIS implementációja csak a NIS v2 protokollt használja, azonban mivel más implementációk kompatibilisek kívánnak maradni a régebbi rendszerekkel, ismerik a v1 protokollt is. Az ilyen rendszerekhez tartozó ypbind démonok még olyankor is megpróbálnak v1-es NIS szerverekhez kötést létrehozni, amikor valójában nincs is rá szükségük (és gyakran még akkor is ilyet keresnek, amikor az üzenetükre már válaszolt egy v2-es szerver). Hozzátennénk, hogy bár az ypserver ezen változata a normál klienshívásokat képes feldolgozni, a táblázatokat már nem tudja átküldeni a v1-es klienseknek. Ebbõl következik, hogy a központi vagy alárendelt szerverek nem tudnak együttmûködni olyan NIS szerverekkel, amelyek csak a v1-es protokollt beszélik. Szerencsére ilyen szervereket manapság már alig használnak. NIS szerverek, melyek egyben NIS kliensek Óvatosan kell bánnunk az ypserv elindításával olyan többszerveres tartományokban, ahol a szerverek maguk is NIS kliensek. Alapvetõen nincs abban semmi kivetnivaló, ha a szervereket saját magukhoz kötjük ahelyett, hogy engednénk nekik a kötési kérések küldését és így egymáshoz kötnénk ezeket. Különös hibák tudnak származni olyan helyzetekben, amikor az egyik szerver leáll, miközben a többiek pedig függenek tõle. Végül is ilyenkor minden kliens szépen kivárja a szükséges idõt, aztán megpróbál más szerverekhez kötõdni, de az itt fellépõ késlekedés jelentõs mennyiségû lehet, és ez a hibajelenség ismét fennállhat, mivel elõfordulhat, hogy a szerverek megint egymáshoz kapcsolódnak. A klienst úgy tudjuk egy adott szerverhez kötni, ha az ypbind parancsot a beállítással indítjuk. Ha mindezt nem akarjuk manuálisan megtenni a NIS szerver minden egyes újraindításakor, akkor vegyük fel a következõ sorokat az /etc/rc.conf állományba: nis_client_enable="YES" # elindítjuk a klienst is nis_client_flags="-S NIS tartomány,szerver" Részletesebb lásd az &man.ypbind.8; man oldalát. A jelszavak formátuma NIS jelszavak formátuma A NIS rendszerek kiépítése során az emberek leggyakrabban a jelszavak formátumával kapcsolatban tapasztalnak nehézségeket. Ha a szerverünk DES titkosítású jelszavakat használ, akkor csak olyan klienseket fog tudni támogatni, amelyek szintén így kódolják ezeket. Például, ha a hálózaton vannak &solaris; rendszerû NIS klienseink, akkor szinte biztos, hogy DES titkosítást kell használnunk. A szerverek és a kliensek által használt formátumokat az /etc/login.conf állományba tekintve deríthetjük ki. Ha a gépek többségén a DES titkosítást látjuk, akkor a default osztálynak egy ilyen bejegyzést kell tartalmaznia: default:\ :passwd_format=des:\ :copyright=/etc/COPYRIGHT:\ [a többit most nem mutatjuk] A passwd_format tulajdonság további lehetséges értékei lehetnek a blf és az md5 (melyek rendre a Blowfish és MD5 titkosítású jelszavakat adják meg). Ha változtattunk valamit az /etc/login.conf állományban, akkor a bejelentkezési tulajdonságok adatbázisát is újra kell generálni, melyet root felhasználóként a következõ módon tehetünk meg: &prompt.root; cap_mkdb /etc/login.conf Az /etc/master.passwd állományban jelenlevõ jelszavak formátuma azonban nem frissítõdik egészen addig, amíg a felhasználók a bejelentkezési adatbázis újragenerálása után meg nem változtatják a jelszavaikat. Úgy tudjuk még biztosítani, hogy a jelszavak megfelelõ formátumban kódolódjanak, ha az /etc/auth.conf állományban megkeressük a crypt_default sort, amelyben a választható jelszóformátumok felhasználásái sorrendjét találhatjuk meg. Itt tehát mindössze annyit kell tennünk, hogy a kiszemelt formátumot a lista elejére tesszük. Például, ha a DES titkosítású jelszavakat akarunk használni, akkor ez a bejegyzés így fog kinézni: crypt_default = des blf md5 Ha a fenti lépéseket követjük az összes &os; alapú NIS szervernél és kliensnél, akkor biztosra mehetünk abban, hogy a hálózatunkon belül ugyanazt a jelszóformátumot fogják használni. Ha gondunk akadna a NIS kliensek hitelesítésével, akkor itt érdemes kezdeni a hiba felderítését. Ne felejtsük: ha egy NIS szervert egy heterogén hálózatba akarunk telepíteni, akkor valószínûleg az összes rendszeren a DES titkosítást kell választani, mivel általában ez a közös nevezõ ebben a tekintetben. Greg Sutter Írta: A hálózat automatikus beállítása (DHCP) Mi az a DHCP? Dinamikus állomáskonfigurációs protokoll DHCP internetes rendszerkonzorcium (ISC) A Dinamikus állomáskonfigurációs protokoll, avagy Dynamic Host Configuration Protocol (DHCP) annak eszközeit írja le, hogy egy rendszer miként tud csatlakozni egy hálózathoz és miként tudja azon belül megszerezni a kommunikációhoz szükséges információkat. A &os; 6.0 elõtti változatai az ISC (Internet Systems Consortium, vagyis az internetes rendszerkonzorcium) által kidolgozott DHCP kliens (&man.dhclient.8;) implementációját tartalmazzák. A késõbbi verziókban pedig az OpenBSD 3.7 verziójából átvett dhclient paranccsal dolgozhatunk. Ebben a szakaszban a dhclient parancsra vonatkozó összes információ egyaránt érvényes az ISC és az OpenBSD által fejlesztett DHCP kliensekre. A DHCP szerver az ISC-tõl származik. Mivel foglalkozik ez a szakasz Ebben a szakaszban az ISC és az OpenBSD DHCP klienseinek kliens- és szerver oldali komponsenseit mutatjuk be. A kliens oldali program neve a dhclient, amely a &os; részeként érkezik, és a szerver oldali elem pedig a net/isc-dhcp31-server porton keresztül érhetõ el. A lentebb említett hivatkozások mellett a témában még a &man.dhclient.8;, &man.dhcp-options.5; és a &man.dhclient.conf.5; man adhatnak bõvebb felvilágosítást a témában. Ahogyan mûködik UDP Amikor a dhclient, vagyis a DHCP kliens elindul egy kliensgépen, akkor a hálózaton üzenetszórással próbálja meg elkérni a konfigurációjához szükséges adatokat. Alapértelmezés szerint ezek a kérések a 68-as UDP porton keresztül mennek. A szerver ezekre a 67-es UDP porton válaszol, ahol visszaad a kliensnek egy IP-címet és a hálózat használatához szükséges további információkat, mint például a hálózati maszkot, az alapértelmezett átjáró és a névfeloldásért felelõs szerverek címét. Az összes ilyen jellegû adat egy DHCP bérlet (lease) formájában érkezik meg, amely csak egy adott ideig érvényes (ezt a DHCP szerver karbantartója állítja be). Így a hálózaton a kliens nélküli IP-címeket egy idõ után automatikusan visszanyerjük. A DHCP kliensek rengeteg információt képes elkérni a szervertõl. Ezek teljes listáját a &man.dhcp-options.5; man oldalán olvashatjuk el. Használat a &os;-n belül A &os; teljes egészében tartalmazza az ISC vagy az OpenBSD DHCP kliensét, a dhclient programot (attól függõen, hogy a &os; melyik változatát használjuk). A DHCP kliensek támogatása a telepítõben és az alaprendszerben is megtalálható, és ezzel mentesülünk minden konkrét hálózati beállítás alól a DHCP szervereket alkalmazó hálózatokon. A dhclient a &os; 3.2 változata óta megtalálható a rendszerben. sysinstall DHCP használatát a sysinstall is lehetõvé teszi. Amikor egy hálózati felületet a sysinstall programon belül állítunk be, akkor a második kérdés mindig ez szokott lenni: Do you want to try DHCP configuration of the interface? (Megpróbáljuk DHCP használatával beállítani a felületet?) Ha erre igennel válaszolunk, akkor azzal lényegében a dhclient parancsot indítjuk el, és ha mindez sikerrel zárul, akkor szinte magától kitöltõdik az összes hálózati beállításunk. A DHCP használatához két dolgot kell beállítanunk a rendszerünkön: DHCP követelmények Gondoskodjunk róla, hogy a bpf eszköz része a rendszermagunknak. Ha még nem lenne benne, akkor a rendszermag beállításait tartalmazó állományba vegyük fel a device bpf sort és fordítsuk újra a rendszermagot. A rendszermagok fordításáról a ben tudhatunk meg többet. A bpf eszköz alapból megtalálható a GENERIC rendszermagokban, így ha ezt használjuk, akkor nem kell saját verziót készítenünk a DHCP használatához. Azok számára viszont, akik biztonsági szempontból aggódnak a rendszerük miatt, meg kell említenünk, hogy a bpf egyben az az eszköz, amely a csomagok lehallgatását is lehetõvé teszi (habár az ilyeneket root felhasználóként lehet csak elindítani). A bpf kell a DHCP használatához, azonban ha nagyon fontos nekünk a rendszerünk biztonsága, akkor a bpf eszközt érdemes kivennünk a rendszermagból, ha még pillanatnyilag nem használunk ilyet. Az /etc/rc.conf állományunkat az alábbiak szerint kell módosítani: ifconfig_fxp0="DHCP" Az fxp0 eszközt ne felejtsük el kicserélni arra a felületre, amelyet automatikusan akarunk beállítani. Ennek mikéntje a ban olvasható. Ha a dhclient a rendszerünkben máshol található, vagy egyszerûen csak további beállításokat akarunk átadni a dhclient parancsnak, akkor adjuk meg a következõt is (változtassuk meg igényeink szerint): dhclient_program="/sbin/dhclient" dhclient_flags="" DHCP szerver A DHCP szerver, a dhcpd a net/isc-dhcp31-server port részeként érhetõ el. Az a port tartalmazza az ISC DHCP szerverét és a hozzátartozó dokumentációt. Állományok DHCP konfigurációs állományok /etc/dhclient.conf A dhclient mûködéséhez szükség lesz egy konfigurációs állományra, aminek a neve /etc/dhclient.conf. Ez az állomány általában csak megjegyzéseket tartalmaz, mivel az alapértelmezett értékek többnyire megfelelõek. Ezt a konfigurációs állományt a &man.dhclient.conf.5; man oldal írja le. /sbin/dhclient A dhclient statikusan linkelt és az /sbin könyvtárban található. A &man.dhclient.8; man oldal tud róla részletesebb felvilágosítást adni. /sbin/dhclient-script A dhclient-script a &os;-ben levõ DHCP kliens konfigurációs szkriptje. Mûködését a &man.dhclient-script.8; man oldal írja le, de a felhasználók részérõl semmilyen módosítást nem igényel. /var/db/dhclient.leases A DHCP kliens az érvényes bérleteket tartja nyilván ezekben az állományban és naplóként használja. A &man.dhclient.leases.5; man oldal ezt valamivel bõvebben kifejti. További olvasnivalók A DHCP protokoll mûködését az RFC 2131 mutatja be. A témához kapcsolódóan itt tudunk még leírásokat találni. A DHCP szerverek telepítése és beállítása Mirõl szól ez a szakasz Ebben a szakaszban arról olvashatunk, hogy miként kell egy &os; típusú rendszert DHCP szervernek beállítani, ha az ISC (internetes rendszerkonzorcium) DHCP szerverét használjuk. Ez a szerver nem része a &os;-nek, ezért a szolgáltatás elindításához elõször fel kell raknunk a net/isc-dhcp31-server portot. A Portgyûjtemény használatára vonatkozóan a lehet segítségünkre. A DHCP szerver telepítése DHCP telepítés Ha a &os; rendszerünket DHCP szerverként akarjuk beállítani, akkor ehhez elsõként a &man.bpf.4; eszköz jelenlétét kell biztosítani a rendszermagban. Ehhez vegyük fel a device bpf sort a rendszermagunk beállításait tartalmazó állományba, majd fordítsuk újra a rendszermagot. A rendszermag lefordításáról a ben olvashatunk. A bpf eszköz a &os;-hez alapból adott GENERIC rendszermag része, ezért a DHCP használatához nem kell feltétlenül újat fordítanunk. A biztonsági szempontok miatt aggódó felhasználók részére megjegyezzük, hogy a bpf eszköz egyben a csomagok lehallgatását is lehetõvé teszi (habár az ilyen témájú programok futtatásához megfelelõ jogokra is szükség van). A bpf használata kötelezõ a DHCP mûködtetéséhez, de ha nagyon kényesek vagyunk a biztonságot illetõen, akkor minden olyan esetben, amikor nem használjuk ki ezt a lehetõséget, távolítsuk el a rendszermagból. A következõ lépésben át kell szerkesztenünk a mintaként mellékelt dhcpd.conf állományt, amelyet a net/isc-dhcp31-server port rakott fel. Ez alapértelmezés szerint a /usr/local/etc/dhcpd.conf.sample néven található meg, és mielõtt bármit is változtatnánk rajta, másoljuk le /usr/local/etc/dhcpd.conf néven. A DHCP szerver beállítása DHCP dhcpd.conf A dhcpd.conf az alhálózatokat illetve a gépeket érintõ deklarációkat tartalmazza, és talán a legkönnyebben a következõ példa alapján mutatható be: option domain-name "minta.com"; option domain-name-servers 192.168.4.100; option subnet-mask 255.255.255.0; default-lease-time 3600; max-lease-time 86400; ddns-update-style none; subnet 192.168.4.0 netmask 255.255.255.0 { range 192.168.4.129 192.168.4.254; option routers 192.168.4.1; } host mailhost { hardware ethernet 02:03:04:05:06:07; fixed-address levelezes.minta.com; } Ez a beállítás adja meg a kliensek számára az alapértelmezett keresési tartományt (search domain). A &man.resolv.conf.5; tud ezzel kapcsolatban részletesebb információkat adni. Ez a beállítás adja meg a kliensek által használt névfeloldó szerverek vesszõvel elválasztott felsorolását. A kliensekhez tartozó hálózati maszk. A kliens egy adott idõre kérhet bérleti jogot, egyébként a szerver dönt a bérlet lejárati idejérõl (másodpercekben). Ez az a maximális idõ, amennyire a szerver hajlandó bérbe adni IP-címet. A kliens ugyan hosszabb idõre is kérheti és meg is kapja, de legfeljebb csak max-lease-time másodpercig lesz érvényes. Ez a beállítás határozza meg, hogy a DHCP szervernek frissítse-e a névoldási információkat a bérlések elfogadásánál vagy visszamondásánál. Az ISC implementációjánál ez a beállítás kötelezõ. Ezzel adjuk meg milyen tartományból tudunk IP-címeket kiosztani a kliensek számára. A kezdõ címet is beleértve, innen fogunk kiutalni egyet a klienseknek. A kliensek felé elküldött alapértelmezett átjáró címe. A gép hardveres MAC-címe (így a DHCP szerver képes felismerni a kérés küldõjét). Ennek megadásával a gépek mindig ugyanazt az IP-címet kapják. Itt már megadhatunk egy hálózati nevet, mivel a bérlethez tartozó információk visszaküldése elõtt maga a DHCP szerver fogja feloldani a gép nevét. Miután befejeztük a dhcpd.conf módosítását, a DHCP szerver az /etc/rc.conf állományban tudjuk engedélyezni, vagyis tegyük bele a következõt: dhcpd_enable="YES" dhcpd_ifaces="dc0" A dc0 felület nevét helyettesítsük annak a felületnek (vagy whitespace karakterekkel elválasztott felületeknek) a nevével, amelyen keresztül a DHCP szerver várni fogja a kliensek kéréseit. Ezután a következõ parancs kiadásával indítsuk el a szervert: &prompt.root; /usr/local/etc/rc.d/isc-dhcpd start Amikor a jövõben valamit változtatunk a konfigurációs állományon, akkor ezzel kapcsolatban fontos megemlíteni, hogy ha csak egy SIGHUP jelzést küldünk a dhcpd démonnak, akkor az a többi démontól eltérõen önmagában még nem eredményezi a konfigurációs adatok újraolvasását. Helyette a SIGTERM jelzéssel kell leállítani a programot, majd újraindítani a fenti paranccsal. Állományok DHCP konfigurációs állományok /usr/local/sbin/dhcpd A dhcpd statikusan linkelt és a /usr/local/sbin könyvtárban található. A porttal együtt felkerülõ &man.dhcpd.8; man oldal ad részletesebb útmutatást dhcpd használatáról. /usr/local/etc/dhcpd.conf Mielõtt a dhcpd megkezdhetné mûködését, egy konfigurációs állományra is szükségünk lesz, amely a /usr/local/etc/dhcpd.conf. Ez az állomány tartalmazza az összes olyan információt, ami kell a kliensek megfelelõ kiszolgálásához valamint a szerver mûködéséhez. Ez a konfigurációs állomány porthoz tartozó &man.dhcpd.conf.5; man oldalon kerül ismertetésre. /var/db/dhcpd.leases A DHCP szerver ebben az állományba tartja nyilván a kiadott bérleteket, egy napló formájában. A porthoz kapcsolódó &man.dhcpd.leases.5; man oldalon errõl többet is megtudhatunk. /usr/local/sbin/dhcrelay A dhcrelay állománynak olyan komolyabb környezetekben van szerepe, ahol a DHCP szerver a kliensektõl érkezõ kéréseket egy másik hálózaton található DHCP szerverhez továbbítja. Ha szükség lenne erre a lehetõségre, akkor telepítsük fel a net/isc-dhcp31-relay portot. A porthoz tartozó &man.dhcrelay.8; man oldal ennek részleteit taglalja. Chern Lee Készítette: Tom Rhodes Daniel Gerzo Névfeloldás (<acronym>DNS</acronym>) Áttekintés BIND A &os; alapértelmezés szerint a BIND (Berkeley Internet Name Domain) egyik verzióját tartalmazza, amely a névfeloldási (Domain Name System, DNS) protokoll egyik elterjedt implementációja. A DNS protokollon keresztül tudunk az IP-címekhez neveket rendelni és fordítva. Például a www.FreeBSD.org névre a &os; Projekt webszerverének IP-címét kapjuk meg, miközben a ftp.FreeBSD.org pedig a hozzátartozó FTP szerver IP-címét fogja visszaadni. Ehhez hasonlóan a fordítottja is megtörténhet, vagyis egy IP-címhez is kérhetjük a hálózati név feloldását. A névfeloldási kérések kiszolgálásához nem feltétlenül szükséges névszervert futtatni a rendszerünkön. A &os; jelen pillanatban alapból a BIND9 névszervert tartalmazza. A benne szereplõ változata több biztonsági javítást, új állományrendszeri kiosztást és automatizált &man.chroot.8; beállítást is magában foglal. névfeloldás Az interneten keresztüli névfeloldást legfelsõ szintû tartományoknak (Top Level Domain, TLD) nevezett hitelesített tövek némileg bonyolult rendszerén alapszik, valamint más egyéb olyan névszervereken, amelyek további egyéni információkat tárolnak és táraznak. A BIND fejlesztését jelenleg az Internet Systems Consortium () felügyeli. Alapfogalmak A leírás megértéséhez be kell mutatnunk néhány névfeloldással kapcsolatos fogalmat. névfeloldó inverz DNS gyökérzóna Fogalom Meghatározás Közvetlen névfeloldás (forward DNS) A hálózati nevek leképezése IP-címekre. Õs (origin) Egy adott zóna állományban szereplõ tartományra vonatkozik. named, BIND A &os;-n belüli BIND névszerver különbözõ megnevezései. Névfeloldó (resolver) Az a program a rendszerben, amelyhez a hálózaton levõ gépek a zónák adatainak elérésével kapcsolatban fordulnak. Inverz névfeloldás (reverse DNS) Az IP-címek leképzése hálózati nevekre. Gyökérzóna (root zone) Az interneten található zónák hierarchiájának töve. Minden zóna ebbe a gyökérzónába esik, ahhoz hasonlóan, ahogy egy állományrendszerben az állományok a gyökérkönyvtárba. Zóna (zone) Egy különálló tartomány, altartomány vagy a névfeloldás azon része, amelyet egyazon fennhatóság alatt tartanak karban. zónák példák Példák zónákra: A gyökérzónára a leírásokban általában . néven szoktak hivatkozni. A org. egy legfelsõ szintû tartomány (TLD) a gyökérzónán belül. A minta.org. a org. TLD tartomány alatti zóna. A 1.168.192.in-addr.arpa egy olyan zóna, amelyek a 192.168.1.* IP-címtartományban szereplõ összes címet jelöli. Mint láthatjuk, a hálózati nevek balról kiegészülve pontosodnak. Tehát például a minta.org. sokkal pontosabb meghatározás, mint a org., ahogy az org. magánál a gyökérzónánál jelent többet. A hálózati nevek felosztása leginkább egy állományrendszerhez hasonlítható, például a /dev könyvtár a gyökéren belül található, és így tovább. Miért érdemes névszervert futtatni A névszerverek általában két alakban jelennek meg. Egyikük a hitelesített névszerver, a másikuk a gyorsítótárazó névszerver. Egy hitelesített névszerverre akkor van szükségünk, ha: a világ többi része felé akarunk hiteles névfeloldási információkat szolgáltatni; regisztráltunk egy tartományt (például minta.org) és az alatta levõ hálózati nevekhez is szeretnénk IP-címeket rendeltetni; a IP-címtartományunkban szükség van inverz névfeloldási bejegyzésekre (amely IP-címbõl ad meg hálózati nevet) is; a kérések teljesítéséhez egy tartalék avagy második, alárendelt (slave) névszerver kell. A gyorsítótárazó névszerverre akkor van szükségünk, ha: egy helyi névfeloldó szerver felhasználásával fel akarjuk gyorsítani az egyébként a külsõ névszerver felé irányuló kérések kiszolgálását. Amikor valaki lekérdezi a www.FreeBSD.org címét, akkor a névfeloldó elõször általában a kapcsolatot rendelkezésre bocsátó internet-szolgáltató névszerverét kérdezi meg és onnan kapja meg a választ. Egy helyi, gyorsítótárazó névszerver használata esetén azonban egy ilyen kérést csak egyszer kell kiadni a külsõ névszervernek. Ezután már minden további ilyen kérés el sem hagyja a belsõ hálózatunkat, mivel a válasz szerepel a gyorsítótárban. Ahogyan mûködik &os; alatt a BIND démon nyilvánvaló okokból named néven érhetõ el. Állomány Leírás &man.named.8; A BIND démon. &man.rndc.8; A névszervert vezérlõ segédprogram. /etc/namedb A BIND által kezelt zónák adatait tároló könyvtár. /etc/namedb/named.conf A démon konfigurációs állománya. Attól függõen, hogy miként állítjuk be az adott zónát a szerveren, a hozzátartozó állományok a /etc/namedb könyvtáron belül a master, slave vagy dynamic alkönyvtárban foglalnak helyet. Az itt tárolt állományokban levõ névfeloldási információk alapján válaszol a névszerver a felé intézett kérésekre. A BIND elindítása BIND elindítás Mivel a BIND alapból elérhetõ a rendszerben, viszonylag könnyen be tudjuk állítani. A named alapértelmezett beállítása szerint egy &man.chroot.8; környezetben futó egyszerû névfeloldást végzõ szerver, amely a helyi IPv4 interfészen (127.0.0.1) fogadja a kéréseket. Ezzel a beállítással a következõ parancson keresztül tudjuk elindítani: &prompt.root; /etc/rc.d/named onestart Ha engedélyezni akarjuk a named démont minden egyes rendszerindításkor, tegyük a következõ sort az /etc/rc.conf állományba: named_enable="YES" Értelemszerûen az /etc/namedb/named.conf tele van olyan beállítási lehetõségekkel, amelyek meghaladják ennek a leírásnak a kereteit. Ha viszont kíváncsiak vagyunk a &os;-ben a named indításához használt beállításokra, akkor az /etc/defaults/rc.conf állományban nézzük meg named_* változókat és olvassuk át az &man.rc.conf.5; man oldalt. Emellett még a t is hasznos lehet elolvasni. A konfigurációs állományok BIND konfigurációs állományok A named beállításait tartalmazó állományok pillanatnyilag az /etc/namedb könyvtárban találhatóak és hacsak nem egy egyszerû névfeloldóra tartunk igényt, akkor a használata elõtt módosítanunk is kell. Itt ejtjük meg a beállítások nagy részét. <filename>/etc/namedb/named.conf</filename> // $FreeBSD$ // // Részletesebb leírást a named.conf(5) és named(8) man oldalakon, valamint // a /usr/share/doc/bind9 könyvtárban találhatunk. // // Ha egy hitelesített szervert akarunk beállítani, akkor igyekezzünk // a névfeloldás összes finom részletével pontosan tisztában lenni. // Ugyanis még a legkisebb hibákkal is egyrészt elvághatunk gépeket az // internet-lérésétõl, vagy másrészt felesleges forgalmat tudunk // generálni // options { // A chroot könyvtárhoz relatív elérési út, amennyiben létezik directory "/etc/namedb"; pid-file "/var/run/named/pid"; dump-file "/var/dump/named_dump.db"; statistics-file "/var/stats/named.stats"; // Ha a named démont csak helyi névfeloldóként használjuk, akkor ez // egy biztonságos alapbeállítás. Ha viszont a named démon az egész // hálózatunkat is kiszolgálja, akkor ezt a beállítást tegyük // megjegyzésbe, vagy adjunk meg egy rendes IP-címet, esetleg // töröljük ki. listen-on { 127.0.0.1; }; // Ha rendszerünkön engedélyezett az IPv6 használata, akkor a helyi // névfeloldó használatához ezt a sort vegyük ki a megjegyzésbõl. // A hálózatunk többi részérõl pedig úgy lehet elérni, ha itt megadunk // egy IPv6 címet, vagy az "any" kulcsszót. // listen-on-v6 { ::1; }; // Az alábbi zónákat már a lentebb található üres zónák eleve lefedik. // Ha tehát a lenti üres zónákat kivesszük a konfigurációból, akkor // ezeket a sorokat is tegyük megjegyzésbe. disable-empty-zone "255.255.255.255.IN-ADDR.ARPA"; disable-empty-zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA"; disable-empty-zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA"; // Ha a szolgáltatónk névszervert is elérhetõvé tett számunkra, akkor // itt adjuk meg annak az IP-címét és engedélyezzük az alábbi sort. // Ezzel egyben kihasználjuk a gyorsítótárat is, így mérsékeljük az // internet felé mozgó névfeloldásokat. /* forwarders { 127.0.0.1; }; * // Ha a 'forwarders' rész nem üres, akkor alapértelmezés szerint a // 'forward first' értékkel rendelkezik. Ekkor a kérést a helyi szerver // kapja abban az esetben, amikor a 'forwarders' részben megadott // szerverek nem tudják megválaszolni. Emellett a névszerverben a // következõ sor hozzáadásával letilthatjuk, hogy önmagától ne // kezdeményezzen kéréseket: // forward only; // Ha a kérések továbbítását az /etc/resolv.conf állományban megadott // bejegyzések mentén szeretnénk automatikusan konfigurálni, akkor vegyük // ki a megjegyzésbõl az alábbi sort és adjuk hozzá az /etc/rc.conf // állományhoz a name_auto_forward=yes sort. Emellett használható még a // named_auto_forward_only beállítás is (amely fentebb leírt funkciót // valósítja meg). // include "/etc/namedb/auto_forward.conf"; Ahogy arról a megjegyzésekben is szó esik, úgy tudjuk aktiválni a gyorsítótárat, ha megadjuk a forwarders beállítást. Normális körülmények között a névszerver az interneten az egyes névszervereket rekurzívan fogja keresni egészen addig, amíg meg nem találja a keresett választ. Az iménti beállítás engedélyezésével azonban elõször a szolgáltató névszerverét (vagy az általa kijelölt névszervert) fogjuk megkérdezni, a saját gyorsítótárából. Ha a szolgáltató kérdéses névszervere egy gyakran használt, gyors névszerver, akkor ezt érdemes bekapcsolnunk. Itt a 127.0.0.1 megadása nem mûködik. Mindenképpen írjuk át a szolgáltatónk névszerverének IP-címére. /* A BIND legújabb változataiban alapértelmezés szerint minden egyes kimenõ kérésnél más, véletlenszerûen választott UDP portot használnak, ezáltal jelentõs mértékben csökkenthetõ a gyorsítótár meghamisíthatóságának (cache poisoning) esélye. Javasoljuk mindenkinek, hogy használják ki ezt a lehetõséget és eszerint állítsák be a tûzfalakat. Ha nem sikerül a tûzfalat hozzáigazítani ehhez a viselkedéshez AKKOR ÉS CSAK IS AKKOR engedélyezzük a lenti beállítást. Alkalmazásával sokkal kevésbé lesz ellenálló a névszerver a különbözõ hamisítási kísérletekkel szemben, ezért lehetõség szerint kerüljük el. Az NNNNN helyére egy 49160 és 65530 közti számot kell beírnunk. */ // query-source address * port NNNNN; }; // Ha engedélyezzük a helyi névszervert, akkor az /etc/resolv.conf // állományban elsõ helyen megadni a 127.0.0.1 címet. Sõt, az // /etc/rc.conf állományból se felejtsük ki. // A hagyományos "root-hints" megoldás. Használjuk ezt VAGY a lentebb // megadott alárendelt zónákat. zone "." { type hint; file "named.root"; }; /* Több szempontból is elõnyös, ha a következõ zónákat alárendeljük a gyökér névfeloldó szervereknek: 1. A helyi felhasználók kéréseit gyorsabban tudjuk feloldalni. 2. A gyökérszerverek felé nem megy semmilyen hamis forgalom. 3. A gyökérszerverek meghibásodása vagy elosztott DoS támadás esetén rugalmasabban tudunk reagálni. Másfelöl azonban ez a módszer a "hints" állomány alkalmazásával szemben több felügyeletet igényel, mivel figyelnünk kell, nehogy egy váratlan meghibásodás mûködésképtelenné tegye a szerverünket. Ez a megoldás leginkább a sok klienst kiszolgáló névszerverek esetén bizonyulhat jövedelmezõbbnek. Óvatosan bánjunk vele! A módszer alkalmazásához vegyük ki a megjegyzésbõl a következõ bejegyzéseket és tegyük megjegyzésbe a fenti hint zónát. */ zone "." { type slave; file "slave/root.slave"; masters { 192.5.5.241; // F.ROOT-SERVERS.NET. }; notify no; }; zone "arpa" { type slave; file "slave/arpa.slave"; masters { 192.5.5.241; // F.ROOT-SERVERS.NET. }; notify no; } zone "in-addr.arpa" { type slave; file "slave/in-addr.arpa.slave"; masters { 192.5.5.241; // F.ROOT-SERVERS.NET. }; notify no; }; */ /* Az alábbi zónák helyi kiszolgálásával meg tudjuk akadályozni, hogy a belõlük indított kérések elhagyják a hálózatunkat és a elérjük a gyökér névfeloldó szervereket. Ez a megközelítés két komoly elõnnyel rendelkezik: 1. A helyi felhasználók kéréseit gyorsabban tudjuk megválaszolni. 2. A gyökérszerverek felé nem továbbítódik semmilyen hamis forgalom. */ // RFC 1912 zone "localhost" { type master; file "master/localhost-forward.db"; }; zone "127.in-addr.arpa" { type master; file "master/localhost-reverse.db"; }; zone "255.in-addr.arpa" { type master; file "master/empty.db"; }; // A helyi IPv6 címek részére létrehozott RFC 1912-szerû zóna zone "0.ip6.arpa" { type master; file "master/localhost-reverse.db"; }; // "Ez" a hálózat (RFC 1912 és 3330) zone "0.in-addr.arpa" { type master; file "master/empty.db"; }; // Magáncélú hálózatok (RFC 1918) zone "10.in-addr.arpa" { type master; file "master/empty.db"; }; zone "16.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "17.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "18.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "19.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "20.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "21.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "22.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "23.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "24.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "25.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "26.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "27.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "28.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "29.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "30.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "31.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "168.192.in-addr.arpa" { type master; file "master/empty.db"; }; // Helyi link/APIPA (RFC 3330 és 3927) zone "254.169.in-addr.arpa" { type master; file "master/empty.db"; }; // Dokumentációs próbahálózat (RFC 3330) zone "2.0.192.in-addr.arpa" { type master; file "master/empty.db"; }; // Útválasztási teljesítmény tesztelésére (RFC 3330) zone "18.198.in-addr.arpa" { type master; file "master/empty.db"; }; zone "19.198.in-addr.arpa" { type master; file "master/empty.db"; }; // Az IANA részére fentartott - a régi E osztályú címtér zone "240.in-addr.arpa" { type master; file "master/empty.db"; }; zone "241.in-addr.arpa" { type master; file "master/empty.db"; }; zone "242.in-addr.arpa" { type master; file "master/empty.db"; }; zone "243.in-addr.arpa" { type master; file "master/empty.db"; }; zone "244.in-addr.arpa" { type master; file "master/empty.db"; }; zone "245.in-addr.arpa" { type master; file "master/empty.db"; }; zone "246.in-addr.arpa" { type master; file "master/empty.db"; }; zone "247.in-addr.arpa" { type master; file "master/empty.db"; }; zone "248.in-addr.arpa" { type master; file "master/empty.db"; }; zone "249.in-addr.arpa" { type master; file "master/empty.db"; }; zone "250.in-addr.arpa" { type master; file "master/empty.db"; }; zone "251.in-addr.arpa" { type master; file "master/empty.db"; }; zone "252.in-addr.arpa" { type master; file "master/empty.db"; }; zone "253.in-addr.arpa" { type master; file "master/empty.db"; }; zone "254.in-addr.arpa" { type master; file "master/empty.db"; }; // Hozzárendelés nélküli IPv6-címek (RFC 4291) zone "1.ip6.arpa" { type master; file "master/empty.db"; }; zone "3.ip6.arpa" { type master; file "master/empty.db"; }; zone "4.ip6.arpa" { type master; file "master/empty.db"; }; zone "5.ip6.arpa" { type master; file "master/empty.db"; }; zone "6.ip6.arpa" { type master; file "master/empty.db"; }; zone "7.ip6.arpa" { type master; file "master/empty.db"; }; zone "8.ip6.arpa" { type master; file "master/empty.db"; }; zone "9.ip6.arpa" { type master; file "master/empty.db"; }; zone "a.ip6.arpa" { type master; file "master/empty.db"; }; zone "b.ip6.arpa" { type master; file "master/empty.db"; }; zone "c.ip6.arpa" { type master; file "master/empty.db"; }; zone "d.ip6.arpa" { type master; file "master/empty.db"; }; zone "e.ip6.arpa" { type master; file "master/empty.db"; }; zone "0.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "1.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "2.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "3.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "4.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "5.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "6.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "7.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "8.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "9.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "a.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "b.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "0.e.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "1.e.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "2.e.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "3.e.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "4.e.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "5.e.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "6.e.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "7.e.f.ip6.arpa" { type master; file "master/empty.db"; }; // IPv6 ULA (RFC 4193) zone "c.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "d.f.ip6.arpa" { type master; file "master/empty.db"; }; // IPv6 helyi link (RFC 4291) zone "8.e.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "9.e.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "a.e.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "b.e.f.ip6.arpa" { type master; file "master/empty.db"; }; // Elavult IPv6 helyi címek (RFC 3879) zone "c.e.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "d.e.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "e.e.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "f.e.f.ip6.arpa" { type master; file "master/empty.db"; }; // Az IP6.INT már elavult (RFC 4159) zone "ip6.int" { type master; file "master/empty.db"; }; // FONTOS: Ne használjuk ezeket az IP-címeket, mert nem valódiak, // csupán illusztrációs és dokumentációs célokból adtuk meg! // // Az alárendelt zónák beállításaira vonatkozó bejegyzések. Érdemes // ilyet beállítani legalább ahhoz a zónához, amelyhez a tartományunk is // tartozik. Az elsõdleges névszerverhez tartozó IP-címet érdeklõdjük meg // az illetékes hálózati rendszergazdától. // // Soha ne felejtsünk el megadni zónát az inverz kereséshez! A neve az IP-cím // tagjainak fordított sorrendjébõl // származik, amelyhez hozzátoldunk még egy // ".IN-ADDR.ARPA" (illetve IPv6 esetén ".IP6.ARPA") részt. // // Mielõtt nekilátnánk egy elsõdleges zóna beállításának, gondoljuk // végig, hogy tényleg a megfelelõ szinten ismerjük a névfeloldás és // a BIND mûködését. Gyakran ugyanis egyáltalán nem nyilvánvaló // csapdákba tudunk esni. Egy alárendelt zóna beállítása általában sokkal egyszerûbb feladat. // // FONTOS: Ne kövessük vakon a most következõ példát :-) Helyette inkább // valódi neveket és címeket adjunk meg. /* Példa dinamikus zónára key "mintaorgkulcs" { algorithm hmac-md5; secret "sf87HJqjkqh8ac87a02lla=="; }; zone "minta.org" { type master; allow-update { key "mintaorgkulcs"; }; file "dynamic/minta.org"; }; */ /* Példa inverz alárendelt zónákra zone "1.168.192.in-addr.arpa" { type slave; file "slave/1.168.192.in-addr.arpa"; masters { 192.168.1.1; }; }; */ A named.conf állományban tehát így adhatunk meg közvetlen és inverz alárendelt zónákat. Minden egyes újabb kiszolgált zónához az egy új bejegyzést kell felvenni a named.conf állományban. Például a minta.org címhez tartozó legegyszerûbb ilyen bejegyzés így néz ki: zone "minta.org" { type master; file "master/minta.org"; }; Ez egy központi zóna, ahogy arról a mezõ, vagyis a típusa is árulkodik. Továbbá a mezõben láthatjuk, hogy a hozzátartozó információkat az /etc/namedb/master/minta.org állományban tárolja. zone "minta.org" { type slave; file "slave/minta.org"; }; Az alárendelt esetben a zónához tartozó információkat a zóna központi szerverétõl kapjuk meg és megadott állományban mentjük el. Ha valamiért a központi szerver leáll vagy nem érhetõ el, akkor az alárendelt szerver az átküldött zóna információk alapján képes helyette kiszolgálni a kéréseket. A zóna állományok BIND zóna állományok A minta.org címhez tartozó példa központi zóna állomány (amely az /etc/namedb/master/néven.org érhetõ el) tartalma az alábbi: $TTL 3600 ; alapértelmezés szerint 1 óra minta.org. IN SOA ns1.minta.org. admin.minta.org. ( 2006051501 ; sorozatszám 10800 ; frissítés 3600 ; ismétlés 604800 ; lejárat 300 ; TTL negatív válasz ) ; névszerverek IN NS ns1.minta.org. IN NS ns2.minta.org. ; MX rekordok IN MX 10 mx.minta.org. IN MX 20 levelezes.minta.org. IN A 192.168.1.1 ; a gépek nevei localhost IN A 127.0.0.1 ns1 IN A 192.168.1.2 ns2 IN A 192.168.1.3 mx IN A 192.168.1.4 levelezes IN A 192.168.1.5 ; álnevek www IN CNAME minta.org. A .-ra végzõdõ hálózati nevek abszolút nevek, míg minden más . nélküli név az õsére vezehetõ vissza (tehát relatív). Például az ns1 névbõl az ns1.minta.org keletkezik. A zóna állományok felépítése a következõ: rekordnév IN rekordtípus érték névfeloldás rekordok A névfeloldásban leggyakrabban alkalmazott rekordok típusai: SOA a zóna fennhatóságának kezdete NS egy hitelesített névszerver A egy gép címe CNAME egy álnév kanonikus neve MX levélváltó PTR mutató a tartománynévre (az inverz feloldás használja) minta.org. IN SOA ns1.minta.org. admin.minta.org. ( 2006051501 ; sorozatszám 10800 ; 3 óránként frissítsünk 3600 ; 1 óra után próbálkozzunk újra 604800 ; 1 hét után jár le 300 ) ; TTL negatív válasz minta.org. a tartomány neve, amely egyben a zóna õse ns1.minta.org. a zóna elsõdleges/hitelesített névszervere admin.minta.org. a zónáért felelõs személy neve, akinek az e-mail címét a @ behelyettesítésével kapjuk meg. (Tehát a admin@example.org címbõl admin.example.org lesz.) 2006051501 az állomány sorozatszáma. Ezt a zóna állomány módosításakor mindig növelnünk kell. Manapság a rendszergazdák a sorozatszámot ééééhhnnvv alakban adják meg. A 2006051501 tehát azt jelenti, hogy az állományt 2006. május 15-én módosították utoljára, és a 01 pedig arra utal, hogy aznap elõször. A sorozatszám megadása fontos az alárendelt névszerverek számára, mivel így tudják megállapítani, hogy a zóna mikor változott utoljára. IN NS ns1.minta.org. Ez egy NS bejegyzés. A zónához tartozó minden hitelesített névszervernek lennie kell legalább egy ilyen bejegyzésének. localhost IN A 127.0.0.1 ns1 IN A 192.168.1.2 ns2 IN A 192.168.1.3 mx IN A 192.168.1.4 levelezes IN A 192.168.1.5 Az A rekord egy gép nevét adja meg. Ahogy a fenti példából is kiderül, az ns1.minta.org név a 192.168.1.2 címre képzõdik le. IN A 192.168.1.1 Ez a sor 192.168.1.1 címet rendeli az aktuális õshöz, amely jelen esetünkben az example.org. www IN CNAME @ A kanonikus neveket tároló rekordokat általában egy gép álneveihez használjuk. Ebben a példában a www a fõgép egyik álneve, amely itt éppenséggel a minta.org (192.168.1.1) tartományneve. A CNAME rekordok mellé más típusú rekordokat ugyanarra a hálózati névre soha ne adjunk meg. MX rekord IN MX 10 levelezes.minta.org. Az MX rekord adja meg, hogy milyen levelezõ szerverek felelõsek a zónába érkezõ levelek fogadásáért. A levelezes.minta.org a levelezõ szerver hálózati neve, ahol a 10 az adott levelezõ szerver prioritása. Több levelezõ szerver is megadható 10-es, 20-as stb. prioritásokkal. A minta.org tartományon belül elõször mindig a legnagyobb MX prioritással rendelkezõ levelezõ szervernek próbáljuk meg továbbítani a leveleket (a legkisebb prioritási értékkel rendelkezõ rekord), majd ezután a második legnagyobbnak stb. egészen addig, amíg a levelet tovább nem küldtük. Az in-addr.arpa zóna állományok (inverz DNS) esetén ugyanez a felépítés, kivéve, hogy a PTR típusú bejegyzések szerepelnek az A és CNAME helyett. $TTL 3600 1.168.192.in-addr.arpa. IN SOA ns1.minta.org. admin.minta.org. ( 2006051501 ; sorozatszám 10800 ; frissítés 3600 ; ismétlés 604800 ; lejárat 300 ) ; TTL negatív válasz IN NS ns1.minta.org. IN NS ns2.minta.org. 1 IN PTR minta.org. 2 IN PTR ns1.minta.org. 3 IN PTR ns2.minta.org. 4 IN PTR mx.minta.org. 5 IN PTR levelezes.minta.org. Ez az állomány írja le tehát a kitalált tartományunkon belül az IP-címek és hálózati nevek összerendelését. Érdemes megemlíteni, hogy a PTR rekordok jobb oldalán álló nevek mindegyikének teljes hálózati névnek kell lennie (vagyis . karakterrel kell végzõdnie). A gyorsítótárazó névszerver BIND gyorsítótárazó névszerver A gyorsítótárazó névszerver az a névszerver, amely elsõdleges feladata a rekurzív kérések kiszolgálása. Egyszerûen továbbítja a beérkezõ kéréseket, majd megjegyzi azokat, így késõbb közvetlenül tud válaszolni. Biztonság Habár a névfeloldás szempontjából a BIND a legelterjedtebb, a biztonságosságával azért akadnak gondok. Gyakran találnak benne potenciális és kihasználható biztonsági réseket. A &os; azonban a named démont automatikusan egy &man.chroot.8; környezetbe helyezi. Emellett még léteznek további más védelmi mechanizmusok is, amelyek segítségével el tudjuk kerülni a névfeloldást célzó esetleges támadásokat. Sosem árt olvasgatni a CERT által kiadott biztonsági figyelmeztetéseket és feliratkozni a &a.security-notifications; címére, hogy folyamatosan értesüljünk az interneten és a &os;-ben talált különbözõ biztonsági hibákról. Ha valamilyen gondunk támadna, akkor esetleg próbálkozzunk meg a forrásaink frissítésével és a named újrafordításával. Egyéb olvasnivalók A BIND/named man oldalai: &man.rndc.8; &man.named.8; &man.named.conf.5; Az ISC BIND hivatalos honlapja (angolul) Az ISC BIND hivatalos fóruma (angolul) O'Reilly DNS and BIND 5th Edition RFC1034 - Domain Names - Concepts and Facilities RFC1035 - Domain Names - Implementation and Specification Murray Stokely Készítette: Az Apache webszerver webszerverek beállítása Apache Áttekintés A &os; szolgálja ki a legforgalmasabb honlapok nagy részét szerte a világban. A mögöttük álló webszerverek általában az Apache webszervert alkalmazzák. Az Apache használatához szükséges csomagok megtalálhatóak a &os; telepítõlemezén is. Ha a &os; elsõ telepítésekor még nem telepítettük volna az Apache szerverét, akkor a www/apache13 vagy www/apache12 portból tudjuk feltenni. Az Apache szervert sikeres telepítését követõen be kell állítanunk. Ebben a szakaszban az Apache webszerver 1.3.X változatát mutatjuk be, mivel ezt használják a legtöbben &os; alatt. Az Apache 2.X rengeteg új technológiát vezetett be, de ezekkel itt most nem foglalkozunk. Az Apache 2.X változatával kapcsolatban keressük fel a oldalt. Beállítás Apache konfigurációs állományok Az Apache webszerver konfigurációs állománya &os; alatt /usr/local/etc/apache/httpd.conf néven található. Ez az állomány egy szokványos &unix;-os szöveges konfigurációs állomány, ahol a megjegyzéseket egy # karakterrel vezetjük be. Az itt használható összes lehetséges beállítási lehetõség átfogó ismertetése meghaladná az egész kézikönyv határait, ezért most csak a leggyakrabban módosított direktívákat fogjuk ismertetni. ServerRoot "/usr/local" Ez adja meg az Apache számára az alapértelmezett könyvtárat. A binárisai ezen belül a bin és sbin alkönyvtárakban, a konfigurációs állományai pedig az etc/apache könyvtárban tárolódnak. ServerAdmin saját@címünk.az.interneten Erre a címre küldhetik nekünk a szerverrel kapcsolatos hibákat. Ez a cím egyes szerver által generált oldalakon jelenik meg, például hibák esetében. ServerName www.minta.com A ServerName segítségével meg tudjuk adni, hogy milyen nevet küldjön vissza a szerver a klienseknek olyankor, ha az nem egyezne meg a jelenlegivel (vagyis a www nevet használjuk a gépünk valódi neve helyett). DocumentRoot "/usr/local/www/data" A DocumentRoot adja meg azt a könyvtárat, ahonnan kiszolgáljuk a dokumentumokat. Alapértelmezés szerint az összes kérés erre a könyvtárra fog vonatkozni, de a szimbolikus linkek és az álnevek akár más helyekre is mutathatnak. A változtatások végrehajtása elõtt mindig is jó ötlet biztonsági másolatot készíteni az Apache konfigurációs állományairól. Ahogy sikerült összerakni egy számunkra megfelelõ konfigurációt, készen is állunk az Apache futtatására. Az <application>Apache</application> futtatása Apache indítása és leállítása A többi hálózati szervertõl eltérõen az Apache nem az inetd szuperszerverbõl fut. A kliensektõl érkezõ HTTP kérések minél gyorsabb kiszolgálásának érdekében úgy állítottuk be, hogy önállóan fusson. Ehhez egy szkriptet is mellékeltünk, amellyel igyekeztünk a lehetõ legjobban leegyszerûsíteni a szerver indítását, leállítását és újraindítását. Az Apache elsõ indításához adjuk ki a következõ parancsot: &prompt.root; /usr/local/sbin/apachectl start Így pedig a szervert bármikor leállíthatjuk: &prompt.root; /usr/local/sbin/apachectl stop Ha valamilyen okból megváltoztattuk volna a szerver beállításait, akkor ezen a módon tudjuk újraindítani: &prompt.root; /usr/local/sbin/apachectl restart Ha a jelenleg megnyitott kapcsolatok felbontása nélkül akarjuk újraindítani az Apache szervert, akkor ezt írjuk be: &prompt.root; /usr/local/sbin/apachectl graceful Mindezekrõl az &man.apachectl.8; man oldalon találunk bõvebb leírást. Amennyiben szükségünk lenne az Apache elindítására a rendszer indításakor, akkor a következõ sort vegyünk fel az /etc/rc.conf állományba: apache_enable="YES" Az Apache 2.2 esetében: apache22_enable="YES" Amikor az Apache httpd nevû programjának szeretnénk további paranccsori paramétereket átadni a rendszer indítása során, akkor ezeket így tudjuk megadni az rc.conf állományban: apache_flags="" Most, miután a webszerverünk mûködik, a böngészõnkkel mindezt ellenõrizni is tudjuk a http://localhost/ cím beírásával. Ilyenkor az alapértelmezés szerinti /usr/local/www/data/index.html állomány tartalmát láthatjuk. Virtuális nevek Az Apache a virtuális nevek használatának két különbözõ módját ismeri. Ezek közül az elsõ módszer a név alapú virtualizáció (Name-based Virtual Hosting). Ilyenkor a kliens HTTP/1.1 fejlécébõl próbálja meg a szerver megállapítani a hivatkozási nevet. Segítségével több tartomány is osztozhat egyetlen IP-címen. Az Apache név alapú virtualizációjának beállításához az alábbi beállítást kell hozzátennünk a httpd.conf állományhoz: NameVirtualHost * Ha a webszerverünk neve www.tartomany.hu, és hozzá egy www.valamilyenmasiktartomany.hu virtuális nevet akarunk megadni, akkor azt a következõképpen tehetjük meg a httpd.conf állományon belül: <VirtualHost *> ServerName www.tartomany.hu DocumentRoot /www/tartomany.hu </VirtualHost> <VirtualHost *> ServerName www.valamilyenmasiktartomany.hu DocumentRoot /www/valamilyenmasiktartomany.hu </VirtualHost> A címek és elérési utak helyére helyettesítsük be a használni kívánt címeket és elérési utakat. A virtuális nevek beállításának további részleteivel kapcsolatosan keressük fel az Apache hivatalos dokumentációját a címen (angolul). Apache-modulok Apache modulok Az alap szerver képességeinek kiegészítéséhez több különbözõ Apache modul áll rendelkezésünkre. A &os; Portgyûjteménye az Apache telepítése mellett lehetõséget ad a népszerûbb bõvítményeinek telepítésére is. mod_ssl webszerverek biztonság SSL titkosítás A mod_ssl modul az OpenSSL könyvtár használatával valósít meg erõs titkosítást a biztonságos socket réteg második, illetve harmadik verziójával (Secure Sockets Layer, SSL v2/v3) és a biztonságos szállítási rétegbeli (Transport Layer Security v1) protokoll segítségével. Ez a modul mindent biztosít ahhoz, hogy a megfelelõ hatóságok által aláírt tanúsítványokat tudjunk kérni, és ezáltal egy védett webszervert futtassunk &os;-n. Ha még nem telepítettünk volna fel az Apache szervert, akkor a www/apache13-modssl porton keresztül a mod_ssl modullal együtt is fel tudjuk rakni az Apache 1.3.X változatát. Az SSL támogatása pedig már az Apache 2.X www/apache22 porton keresztül elérhetõ változataiban alapértelmezés szerint engedélyezett. Kapcsolódás nyelvekhez Mindegyik nagyobb szkriptnyelvhez létezik egy külön Apache-modul, amelyek segítségével komplett Apache-modulokat tudunk készíteni az adott nyelven. Gyakran a dinamikus honlapok is így próbálják a szerverbe épített belsõ értelmezõn keresztül a külsõ értelmezõ indításából és benne a szkriptek lefuttatásából fakadó költségeket megspórolni, ahogy errõl a következõ szakaszokban olvashatunk. Dinamikus honlapok webszerverek dinamikus Az utóbbi évtizedben egyre több vállalkozás fordult az internet felé bevételeik és részesedéseinek növelésének reményében, amivel egyre jobban megnõtt az igény a dinamikus honlapokra is. Miközben bizonyos cégek, mint például a µsoft;, a saját fejlesztésû termékeikbe építettek be ehhez támogatást, addig a nyílt forrásokkal foglalkozó közösség sem maradt tétlen és felvette a kesztyût. A dinamikus tartalom létrehozásához többek közt Django, Ruby on Rails, a mod_perl és a mod_php modulok használhatóak. Django Python Django A Django egy BSD típusú licensszel rendelkezõ keretrendszer, amelynek használatával nagy teljesítményû és elegáns webes alkalmazásokat tudunk gyorsan kifejleszteni. Tartalmaz egy objektum-relációs leképezõt, így az adattípusokat Python-objektumokként tudjuk leírni, és ezekhez az objektumokhoz egy sokrétû, dinamikus adatbázis hozzáférést nyújtó alkalmazásfejlesztõi felületet, így a fejlesztõknek egyetlen SQL utasítást sem kell megírniuk. Találhatunk még benne továbbá egy bõvíthetõ sablonrendszert, amelynek köszönhetõen az alkalmazás belsõ mûködése elválasztható a HTML-beli megjelenésétõl. A Django mûködéséhez a mod_python modulra, az Apache szerverre és egy tetszõlegesen választott SQL alapú adatbázisrendszerre van szükség. A hozzátartozó &os; port mindezeket automatikusan telepíti a megadott beállítások szerint. A Django telepítése az Apache, mod_python3 és a PostgreSQL használatával &prompt.root; cd /usr/ports/www/py-django; make all install clean -DWITH_MOD_PYTHON3 -DWITH_POSTGRESQL Miután a Django és a hozzá szükséges komponensek felkerültek rendszerünkre, hozzunk létre egy könyvtárat a leendõ Django projektünknek és állítsuk be az Apache szervert, hogy az oldalunk belül a megadott linkekre a saját alkalmazásunkat hívja meg a beágyazott Python-értelmezõn keresztül. Az Apache beállítása a Django és mod_python használatához A következõ sort kell hozzátennünk a httpd.conf állományhoz, hogy az Apache bizonyos linkeket a webes alkalmazás felé irányítson át: <Location "/"> SetHandler python-program PythonPath "['/a/django/csomagok/helye/'] + sys.path" PythonHandler django.core.handlers.modpython SetEnv DJANGO_SETTINGS_MODULE azoldalam.beallitasai PythonAutoReload On PythonDebug On </Location> Ruby on Rails Ruby on Rails A Ruby on Rails egy olyan másik nyílt forráskódú keretrendszer, amivel lényegében egy teljes fejlesztõi készletet kapunk és amelyet kifejezetten arra élezték ki, hogy segítségével a webfejlesztõk sokkal gyorsabban tudjanak haladni és a komolyabb alkalmazások gyorsabb elkészítése se okozzon nekik gondot. A Portrgyûjteménybõl pillanatok alatt telepíthetõ. &prompt.root; cd /usr/ports/www/rubygem-rails; make all install clean mod_perl mod_perl Perl Az Apache és Perl egyesítésén fáradozó projekt a Perl programozási nyelv és az Apache webszerver erejének összehangolásán dolgozik. A mod_perl modulon keresztül Perlben vagyunk képesek modulokat készíteni az Apache szerverhez. Ráadásul a szerverben egy belsõ állandó értelmezõ is található hozzá, ezzel igyekeznek megspórolni a külsõ értelmezõ és a Perl indításából keletkezõ többletköltségeket. A mod_perl több különbözõ módon állítható munkába. A mod_perl használatához nem szabad elfelejtenünk, hogy a mod_perl 1.0-ás verziója csak az Apache 1.3 változatával mûködik, és a mod_perl 2.0-ás változata pedig csak az Apache 2.X változataival. A mod_perl 1.0 a www/mod_perl portból telepíthetõ, valamint a statikusan beépített változata a www/apache13-modperl portban található. A mod_perl 2.0 a www/mod_perl2 portból rakható fel. Tom Rhodes Írta: mod_php mod_php PHP A PHP, vagy másik nevén PHP, a hipertext feldolgozó egy általános célú szkriptnyelv, amelyet kifejezetten honlapok fejlesztéséhez hoztak létre. A szabványos HTML ágyazható nyelv felépítésében a C, &java; és Perl nyelveket ötvözi annak elérése érdekében, hogy ezzel segítse a fejlesztõket a dinamikusan generált oldalak minél gyorsabb megírásában. A PHP5 támogatását úgy tudjuk hozzáadni az Apache webszerverhez, ha telepítjük a lang/php5 portot. Ha a lang/php5 portot most telepítjük elõször, akkor a vele kapcsolatos beállításokat tartalmazó OPTIONS menü automatikusan megjelenik. Ha ezzel nem találkoznánk, mert például valamikor korábban már felraktuk volna a lang/php5 portot, akkor a port könyvtárában következõ parancs kiadásával tudjuk újra visszahozni: &prompt.root; make config A beállítások között jelöljük be az APACHE opciót, amelynek eredményeképpen létrejön az Apache webszerverhez használható mod_php5 betölthetõ modul. A PHP4 modult még ma is rengeteg szerver használja több különbözõ okból (például kompatibilitási problémák vagy a már korábban kiadott tartalom miatt). Ha tehát a mod_php5 helyett inkább a mod_php4 modulra lenne szükségünk, akkor a lang/php4 portot használjuk. A lang/php4 portnál is megtalálhatjuk a lang/php5 fordítási idejû beállításainak nagy részét. Az iméntiek révén települnek és beállítódnak a dinamikus PHP alkalmazások támogatásához szükséges mouldok. Az /usr/local/etc/apache/httpd.conf állományban ellenõrizni is tudjuk, hogy az alábbi részek megjelentek-e: LoadModule php5_module libexec/apache/libphp5.so AddModule mod_php5.c <IfModule mod_php5.c> DirectoryIndex index.php index.html </IfModule> <IfModule mod_php5.c> AddType application/x-httpd-php .php AddType application/x-httpd-php-source .phps </IfModule> Ahogy befejezõdött a mûvelet, a PHP modul betöltéséhez mindösszesen az apachectl paranccsal kell óvatosan újraindítanunk a webszervert: &prompt.root; apachectl graceful A PHP jövõbeni frissítéseihez már nem lesz szükségünk a make config parancsra, mivel a korábban kiválasztott OPTIONS menün belüli beállítasainkat a &os; Portgyûjteményéhez tartozó keretrendszer automatikusan elmenti. A PHP &os;-ben megtalálható támogatása kifejezetten moduláris, ezért az alap telepítése igencsak korlátozott. A további elemek hozzáadásához a lang/php5-extensions portot tudjuk használni. A port egy menüvezérelt felületet nyújt a PHP különbözõ bõvítményeinek telepítéséhez. Az egyes bõvítményeket azonban a megfelelõ portok használatával is fel tudjuk rakni. Például PHP5 modulhoz úgy tudunk támogatást adni a MySQL adatbázis szerverhez, ha 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ítsuk a megjegyzést jelzõ # karaktert a már meglevõ ftpd sor elõl: ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l Ahogy arról már a szót ejtett, az inetd beállításait újra be kell olvastatnunk a konfigurációs állomány megváltoztatása után. A írja le az inetd engedélyezésének részleteit. Az ftpd önálló szerverként is elindítható. Ehhez mindössze elegendõ csak a megfelelõ változót beállítani az /etc/rc.conf állományban: ftpd_enable="YES" Miután megadtuk az iménti változót, a szerver el fog indulni a rendszer következõ indítása során. Szükség esetén természetesen root felhasználóként a következõ paranccsal is közvetlenül elindítható: &prompt.root; /etc/rc.d/ftpd start Most már be is tudunk jelentkezni az FTP szerverre: &prompt.user; ftp localhost Karbantartás syslog naplóállományok FTP Az ftpd démon a &man.syslog.3; használatával naplózza az üzeneteket. Alapértelmezés szerint a rendszernaplózó démon az FTP mûködésére vonatkozó üzeneteket az /var/log/xferlog állományba írja. Az FTP naplóinak helyét az /etc/syslog.conf állományban tudjuk módosítani: ftp.info /var/log/xferlog FTP anonim Legyünk körültekintõek a névtelen FTP szerverek üzemeltetésekor. Azt pedig kétszer is gondoljuk meg, hogy engedélyezzük-e a névtelen felhasználók számára állományok feltöltését, hiszen könnyen azon kaphatjuk magunkat, hogy az FTP oldalunk illegális állománycserék színterévé válik vagy esetleg valami sokkal rosszabb történik. Ha mindenképpen szükségünk lenne erre a lehetõségre, akkor állítsunk be olyan engedélyeket a feltöltött állományokra, hogy a többi névtelen felhasználó ezeket a tartalmuk tüzetes ellenõrzéséig ne is olvashassa. Murray Stokely Készítette: Állomány- és nyomtatási szolgáltatások µsoft.windows; kliensek számára (Samba) Samba szerver Microsoft Windows állományszerver windowszos kliensek nyomtatószerver windowszos kliensek Áttekintés A Samba egy olyan elterjedt nyílt forráskódú szoftver, ami µsoft.windows; kliensek számára tesz lehetõvé állomány- és nyomtatási szolgáltatásokat. Az ilyen kliensek általa helyi meghajtóként képesek elérni a &os; állományrendszerét, vagy helyi nyomtatóként a &os; általt kezelt nyomtatókat. A Samba csomagja általában megtalálható a &os; telepítõeszközén. Ha a &os;-vel együtt nem raktuk fel a Samba csomagját, akkor ezt késõbb net/samba3 port vagy csomag telepítésével pótolhatjuk. Beállítás A Samba konfigurációs állománya a telepítés után /usr/local/share/examples/samba/smb.conf.default néven található meg. Ezt kell lemásolnunk /usr/local/etc/smb.conf néven, amelyet aztán a Samba tényleges használata elõtt módosítanunk kell. Az smb.conf állomány a Samba futásához használt beállításokat tartalmazza, mint például &windows; kliensek számára felkínált a nyomtatók és megosztások adatait. A Samba csomagban ezen kívül találhatunk még egy swat nevû webes eszközt, amellyel egyszerû módon tudjuk az smb.conf állományt állítgatni. A Samba webes adminisztrációs eszköze (SWAT) A Samba webes adminisztrációs segédeszköze (Samba Web Administration Tool, SWAT) az inetd démonon keresztül fut démonként. Ennek megfelelõn az /etc/inetd.conf állományban a következõ sort kell kivennünk megjegyzésbõl, mielõtt a swat segítségével megkezdenénk a Samba beállítását: swat stream tcp nowait/400 root /usr/local/sbin/swat swat Ahogy azt a is mutatja, az inetd démont újra kell indítanunk a megváltozott konfigurációs állományának újbóli beolvasásához. Miután az inetd.conf állományban a swat engedélyezésre került, a böngészõnk segítségével próbáljunk meg a címre csatlakozni. Elõször a rendszer root hozzáférésével kell bejelentkeznünk. Miután sikeresen bejelentkeztünk a Samba beállításait tárgyaló lapra, el tudjuk olvasni a rendszer dokumentációját, vagy a Globals fülre kattintva nekiláthatunk a beállítások elvégzésének. A Globals részben található opciók az /usr/local/etc/smb.conf állomány [global] szekciójában található változókat tükrözik. Általános beállítások Akár a swat eszközzel, akár a /usr/local/etc/smb.conf közvetlen módosításával dolgozunk, a Samba beállítása során a következõkkel mindenképpen össze fogunk futni: workgroup A szervert elérni kívánó számítógépek által használt NT tartomány vagy munkacsoport neve. netbios name NetBIOS A Samba szerver NetBIOS neve. Alapértelmezés szerint ez a név a gép hálózati nevének elsõ tagja. server string Ez a szöveg jelenik meg akkor, ha például a net view paranccsal vagy valamilyen más hálózati segédprogrammal kérdezzük le a szerver beszédesebb leírását. Biztonsági beállítások A /usr/local/etc/smb.conf állományban a két legfontosabb beállítás a választott biztonsági modell és a kliensek felhasználói jelszavainak tárolásához használt formátum. Az alábbi direktívák vezérlik ezeket: security Itt a két leggyakoribb beállítás a security = share és a security = user. Ha a kliensek a &os; gépen található felhasználói neveiket használják, akkor felhasználói szintû védelemre van szükségünk (tehát a user beállításra). Ez az alapértelmezett biztonsági házirend és ilyenkor a klienseknek elõször be kell jelentkezniük a megosztott erõforrások eléréséhez. A megosztás (share) szintû védelem esetében, a klienseknek nem kell a szerveren érvényes felhasználói névvel és jelszóval rendelkezniük a megosztott erõforrások eléréséhez. Ez volt az alapbeállítás a Samba korábbi változataiban. passdb backend NIS+ LDAP SQL adatbázis A Samba számos különbözõ hitelesítési modellt ismer. A klienseket LDAP, NIS+, SQL adatbázis vagy esetleg egy módosított jelszó állománnyal is tudjuk hitelesíteni. Az alapértelmezett hitelesítési módszer a smbpasswd, így itt most ezzel foglalkozunk. Ha feltesszük, hogy az alapértelmezett smbpasswd formátumot választottuk, akkor a Samba úgy fogja tudni hitelesíteni a klienseket, ha elõtte létrehozzuk a /usr/local/private/smbpasswd állományt. Ha a &windows;-os kliensekkel is el akarjuk érni a &unix;-os felhasználói hozzáféréseinket, akkor használjuk a következõ parancsot: &prompt.root; smbpasswd -a felhasználónév A Samba a 3.0.23c verziójától kezdõdõen a hitelesítéshez szükséges állományokat a /usr/local/etc/samba könyvtárban tárolja. A felhasználói hozzáférések hozzáadására innentõl már a tdbsam parancs használata javasolt: &prompt.root; pdbedit felhasználónév A hivatalos Samba HOGYAN ezekrõl a beállításokról szolgál további információkkal (angolul). Viszont az itt vázolt alapok viszont már elegendõek a Samba elindításához. A <application>Samba</application> elindítása A net/samba3 port a Samba irányítására egy új indító szkriptet tartalmaz. A szkript engedélyezéséhez, tehát általa a Samba elindításának, leállításának és újraindításának lehetõvé tételéhez vegyük fel a következõ sort az /etc/rc.conf állományba: samba_enable="YES" Ha még finomabb irányításra vágyunk: nmbd_enable="YES" smbd_enable="YES" Ezzel egyben a rendszer indításakor automatikusan be is indítjuk a Samba szolgáltatást. A Samba a következõkkel bármikor elindítható: &prompt.root; /usr/local/etc/rc.d/samba start Starting SAMBA: removing stale tdbs : Starting nmbd. Starting smbd. Az rc szkriptekkel kapcsolatban a t ajánljuk elolvasásra. A Samba jelen pillanatban három különálló démonból áll. Láthatjuk is, hogy az nmbd és smbd démonokat elindította a samba szkript. Ha az smb.conf állományban engedélyeztük a winbind névfeloldási szolgáltatást is, akkor láthatjuk, hogy ilyenkor a winbindd démon is elindul. A Samba így állítható le akármikor: &prompt.root; /usr/local/etc/rc.d/samba stop A Samba egy összetett szoftvercsomag, amely a µsoft.windows; hálózatokkal kapcsolatos széles körû együttmûködést tesz lehetõvé. Az általa felkínált alapvetõ lehetõségeken túl a többit a honlapon ismerhetjük meg (angolul). Tom Hukins Készítette: Az órák egyeztetése az NTP használatával NTP Áttekintés Idõvel a számítógép órája hajlamos elmászni. A hálózati idõ protokoll (Network Time Protocol, NTP) az egyik módja az óránk pontosan tartásának. Rengeteg internetes szolgáltatás elvárja vagy éppen elõnyben részesíti a számítógép órájának pontosságát. Például egy webszervertõl megkérdezhetik, hogy egy állományt adott ideje módosítottak-e. A helyi hálózatban az egyazon állományszerveren megosztott állományok ellentmondásmentes dátumozása érdekében szinte elengedhetetlen az órák szinkronizálása. Az olyan szolgáltatások, mint a &man.cron.8; is komolyan építkeznek a pontosan járó rendszerórára, amikor egy adott pillanatban kell lefuttatniuk parancsokat. NTP ntpd A &os; alapból az &man.ntpd.8; NTP szervert tartalmazza, amellyel más NTP szerverek segítségével tudjuk beállítani gépünk óráját, vagy éppen idõvel kapcsolatos információkat szolgáltatni másoknak. A megfelelõ NTP szerverek kiválasztása NTP a szerverek kiválasztása Az óránk egyeztetéséhez egy vagy több NTP szerverre lesz szükségünk. Elõfordulhat, hogy a hálózati rendszergazdánk vagy az internet-szolgáltatónk már beállított egy ilyen szervert erre a célra. Ezzel kapcsolatban olvassuk el a megfelelõ leírásokat. A nyilvánosan elérhetõ NTP szerverekrõl készült egy lista, ahonnan könnyedén ki tudjuk keresni a számunkra leginkább megfelelõ (hozzánk legközelebbi) szervert. Ne hagyjuk figyelmen kívül a szerverre vonatkozó házirendet és kérjünk engedélyt a használatához, amennyiben ez szükséges. Több, egymással közvetlen kapcsolatban nem álló NTP szerver választásával járunk jól, ha netalán az egyikük váratlanul elérhetetlenné vagy az órája pontatlanná válna. Az &man.ntpd.8; a visszakapott válaszokat intelligensen használja fel, mivel esetükben a megbízható szervereket részesíti elõnyben. A gépünk beállítása NTP beállítása Alapvetõ beállítások ntpdate Ha a számítógépünk indításakor akarjuk egyeztetni az óránkat, akkor erre az &man.ntpdate.8; nevû programot használhatjuk. Ez olyan asztali gépek számára megfelelõ választás, amelyeket gyakran indítanak újra és csak idõnként kell szinkronizálnunk. A legtöbb gépnek viszont az &man.ntpd.8; használatára van szüksége. Az &man.ntpdate.8; elindítása olyan esetekben is hasznos, ahol az &man.ntpd.8; is fut. Az &man.ntpd.8; az órát fokozatosan állítja, ellenben az &man.ntpdate.8; az eltérés mértékétõl és irányától függetlenül egyszerûen átállítja a gép óráját a pontos idõre. Az &man.ntpdate.8; elindítását úgy tudjuk engedélyezni a rendszer indításakor, ha az /etc/rc.conf állományba berakjuk az ntpdate_enable="YES" sort. Emellett még ntpdate_flags változóban meg kell adnunk az alkalmazott beállítások mellett azokat a szervereket, amelyekkel szinkronizálni akarunk. NTP ntp.conf Általános beállítások Az NTP az /etc/ntp.conf állományon keresztül állítható, amelyek felépítését az &man.ntp.conf.5; man oldal tárgyalja. Íme erre egy egyszerû példa: server ntplocal.minta.com prefer server timeserver.minta.org server ntp2a.minta.net driftfile /var/db/ntp.drift A server beállítás adja meg az egyeztetéshez használt szervereket, soronként egyet. Ha egy szerver mellett szerepel még a prefer paraméter is, ahogy azt a példában a ntplocal.minta.com mellett láthattuk, akkor a többivel szemben azt a szervert fogjuk elõnyben részesíteni. Az így kiemelt szervertõl érkezõ választ abban az esetben viszont eldobjuk, hogy a többi szervertõl kapott válasz jelentõs mértékben eltér tõle. Minden más esetben a õ válasza lesz a mérvadó. A prefer paramétert általában olyan NTP szerverekhez használják, amelyek közismerten nagy pontosságúak, tehát például külön erre a célra szánt felügyeleti eszközt is tartalmaznak. A driftfile beállítással azt az állományt adjuk meg, amiben a rendszeróra frekvencia eltolódásait tároljuk. Az &man.ntpd.8; program ezzel ellensúlyozza automatikusan az óra természetes elmászását, ezáltal lehetõvé téve, hogy egy viszonylag pontos idõt kapjuk még abban az esetben is, amikor egy kis idõre külsõ idõforrások nélkül maradnánk. A driftfile beállítással egyben azt az állományt jelöljük ki, amely az NTP szervertõl kapott korábbi válaszokat tárolja. Ez az NTP mûködéséhez szükséges belsõ adatokat tartalmaz, ezért semmilyen más programnak nem szabad módosítania. A szerverünk elérésének szabályozása Alapértelmezés szerint az NTP szerverünket bárki képes elérni az interneten. Az /etc/ntp.conf állományban szereplõ restrict beállítás segítségével azonban meg tudjuk mondani, milyen gépek érhetik el a szerverünket. Ha az NTP szerverünk felé mindenféle próbálkozást el akarunk utasítani, akkor az /etc/ntp.conf állományba a következõ sort kell felvennünk: restrict default ignore Ezzel egyben azonban a helyi beállításainkban szereplõ szerverek elérését is megakadályozzuk. Ha külsõ NTP szerverekkel is szeretnénk szinkronizálni, akkor itt is engedélyezünk kell ezeket. Errõl bõvebben lásd az &man.ntp.conf.5; man oldalon. Ha csak a belsõ hálózatunkban levõ gépek számára szeretnénk elérhetõvé tenni az órák egyeztetését, de sem a szerver állapotának módosítását nem engedélyezzük, sem pedig azt, hogy a vele egyenrangú szerverekkel szinkronizáljon, akkor az iménti helyett a restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap sort írjuk bele, ahol a 192.168.1.0 a belsõ hálózatunk IP-címe és a 255.255.255.0 a hozzátartozó hálózati maszk. Az /etc/ntp.conf több restrict típusú beállítást is tartalmazhat. Ennek részleteirõl az &man.ntp.conf.5; man oldalon, az Access Control Support címû szakaszban olvashatunk. Az NTP futtatása Úgy tudjuk az NTP szervert elindítani a rendszerünkkel együtt, ha az /etc/rc.conf állományban szerepeltetjük az ntpd_enable="YES" sort. Ha az &man.ntpd.8; számára további beállításokat is át akarunk adni, akkor az /etc/rc.conf állományban adjuk meg az ntpd_flags paramétert. Ha a gépünk újraindítása nélkül akarjuk elindítani a szerver, akkor az ntpd parancsot adjuk ki az /etc/rc.conf állományban a ntpd_flags változóhoz megadott paraméterekkel. Mint például: &prompt.root; ntpd -p /var/run/ntpd.pid Az ntpd használati idõleges internet csatlakozással Az &man.ntpd.8; program megfelelõ mûködéséhez nem szükséges állandó internet kapcsolat. Ha azonban igény szerinti tárcsázással építjünk fel ideiglenes kapcsolatot, akkor érdemes letiltani az NTP forgalmát, nehogy feleslegesen aktiválja vagy tartsa életben a vonalat. Ha PPP típusú kapcsolatunk van, akkor az /etc/ppp/ppp.conf állományban a filter direktívával tudjuk ezt leszabályozni. Például: set filter dial 0 deny udp src eq 123 # Nem engedjük az NTP által küldött adatoknak, hogy tárcsázást # kezdeményezzenek: set filter dial 1 permit 0 0 set filter alive 0 deny udp src eq 123 # Nem engedjük az NTP adatainak, hogy fenntartsák a kapcsolatot: set filter alive 1 deny udp dst eq 123 set filter alive 2 permit 0/0 0/0 Mindenezekrõl részletesebb felvilágosítást a &man.ppp.8; man oldal PACKET FILTERING címû szakaszában és a /usr/share/examples/ppp/ könyvtárban található példákban kaphatunk. Egyes internet-szolgáltatók blokkolják az alacsonyabb portokat, ezáltal az NTP nem használható, mivel a válaszok nem fogják elérni a gépünket. További olvasnivalók Az NTP szerver dokumentációja HTML formátumban a /usr/share/doc/ntp/ könyvtárban található. Tom Rhodes Készítette: Távoli gépek naplózása <command>syslogd</command> használatával A rendszernaplókkal kapcsolatos mûveletek egyaránt fontosak a biztonság és a karbantartás szempontjából. Ha közepes vagy nagyobb méretû, esetleg különbözõ típusú hálózatokban adminisztrálunk több gépet, akkor könnyen átláthatatlanná válhat a naplók rendszeres felügyelete. Ilyen helyzetekben a távoli naplózás beállításával az egész folyamatot sokkal kényelmesebbé tehetjük. Némileg képesek vagyunk enyhíteni a naplóállományok kezelésének terhét, ha egyetlen központi szerverre küldjük át az adatokat. Ekkor a &os; alaprendszerében megtalálható alapeszközökkel, mint például a &man.syslogd.8; vagy a &man.newsyslog.8; felhasználásával egyetlen helyen be tudjuk állítani a naplók összegyûjtését, összefésülését és cseréjét. A most következõ példa konfigurációban az A gép, a naploszerver.minta.com fogja gyûjteni a helyi hálózatról érkezõ naplóinformációkat. A B gép, a naplokliens.minta.com pedig a szervernek küldi a naplózandó adatokat. Éles környezetben mind a két gépnek rendelkeznie kell megfelelõ DNS bejegyzésekkel, vagy legalább szerepelniük kell egymás /etc/hosts állományaiban. Ha ezt elmulasztjuk, a szerver nem lesz hajlandó adatokat fogadni. A naplószerver beállítása A naplószerverek olyan gépek, amelyeket úgy állítottunk be, hogy naplózási információkat tudjanak fogadni távoli számítógépekrõl. A legtöbb esetben így egyszerûsíteni tudunk a konfiguráción, vagy olykor egyszerûen csak hasznos, ha ezt a megoldást alkalmazzuk. Függetlenül attól, hogy miért használjuk, a továbblépés elõtt néhány elõkészületet meg kell tennünk. Egy rendesen beállított naplószervernek legalább a következõ követelményeknek kell eleget tennie: az 514-es UDP portot engedélyezni kell mind a kliensen, mind pedig a szerveren futó tûzfal szabályrendszerében; a &man.syslogd.8; képes legyen a távoli kliens gépekrõl érkezõ üzeneteket fogadni; a &man.syslogd.8; szervernek és az összes kliensnek rendelkeznie kell érvényes DNS (közvetlen és inverz) bejegyzésekkel vagy szerepelnie kell az /etc/hosts állományban. A naplószerver beállításához mindegyik klienst fel kell vennünk az /etc/syslog.conf állományba, valamint meg kell adnunk a megfelelõ funkciót (facility): +naplokliens.minta.com *.* /var/log/naplokliens.log A &man.syslog.conf.5; man oldalán megtalálhatjuk a különbözõ támogatott és elérhetõ funkciókat. Miután beállítottuk, az összes adott funkcióhoz tartozó üzenet az elõbb megadott állományba (/var/log/naplokliens.log) fog kerülni. A szerveren továbbá meg kell adnunk a következõ sort az /etc/rc.conf állományban: syslogd_enable="YES" syslogd_flags="-a naplokliens.minta.com -vv" Az elsõ sorral engedélyezzük a syslogd elindítását a rendszerindítás során, majd a második sorral engedélyezzük, hogy a kliens naplózni tudjon a szerverre. Itt még látható a opció, amellyel a naplózott üzenetek részletességét tudjuk növelni. Ennek nagyon fontos a szerepe a naplózási funkciók behangolásakor, mivel így a rendszergazdák pontosan láthatják milyen típusú üzenetek milyen funkcióval kerültek rögzítésre a naplóban. Befejezésképpen hozzuk létre a naplóállományt. Teljesen mindegy, hogy erre milyen megoldást alkalmazunk, például a &man.touch.1; remekül megfelel: &prompt.root; touch /var/log/naplokliens.log Ezután indítsuk újra és ellenõrizzük a syslogd démont: &prompt.root; /etc/rc.d/syslogd restart &prompt.root; pgrep syslog Ha válaszul megkapjuk a futó démon azonosítóját, akkor sikerült újraindítanunk, elkezdhetjük a kliens beállítását. Ha valamiért nem indult volna újra a szerver, az /var/log/messages állományból próbáljuk meg kideríteni az okát. A naplókliens beállítása A naplókliens az a gép, amely egy helyi naplópéldány karbantartása mellett továbbküldni a naplózandó információkat egy naplószervernek. Hasonlóan a naplószerverekhez, a klienseknek is teljesítenie bizonyos alapvetõ elvárásokat: a &man.syslogd.8; démon küldjön bizonyos típusú üzeneteket a naplószervernek, amely ezeket pedig képes legyen fogadni; a hozzátartozó tûzfal engedje át a forgalmat az 514-es UDP porton; rendelkezzen mind közvetlen, mind pedig inverz DNS bejegyzéssel, vagy szerepeljenek az /etc/hosts állományban. A kliens beállítása sokkal egyszerûbb a szerverhez képest. A kliensen adjuk hozzá a következõ sorokat az /etc/rc.conf állományhoz: syslogd_enabled="YES" syslogd_flags="-s -vv" A szerver beállításaihoz hasonlóan itt is engedélyezzük a syslogd démont és megnöveljük a naplózott üzenetek részletességét. A kapcsolóval pedig megakadályozzuk, hogy a kliens más gépekrõl is hajlandó legyen naplóüzeneteket elfogadni. A funkciók a rendszernek azon részét írják le, amelyhez létrejön az adott üzenet. Tehát például az ftp és ipfw egyaránt ilyen funkciók. Amikor keletkezik egy naplóüzenet valamelyikükhöz, általában megjelenik a nevük. A funkciókhoz tartozik még egy prioritás vagy szint is, amellyel az adott üzenet fontosságát jelzik. Ezek közül a leggyakoribb a warning (mint figyelmeztetés) és info (mint információ). A használható funkciók és a hozzájuk tartozó prioritások teljes listáját a &man.syslog.3; man oldalán olvashatjuk. A naplószervert meg kell adnunk a kliens /etc/syslog.conf állományában. Itt a @ szimbólummal jelezzük, hogy az adatokat egy távoli szerverre szeretnénk továbbküldeni, valahogy így: *.* @naploszerver.minta.com Ezután a beállítás érvényesítéséhez újra kell indítanunk a syslogd démont: &prompt.root; /etc/rc.d/syslogd restart A &man.logger.1; használatával próbáljuk ki a kliensrõl a aplóüzenetek hálózaton keresztüli küldését, és küldjünk valamit a syslogd démonnak: &prompt.root; logger "Udvozlet a naplokliensrol" A parancs kiadása után az üzenetnek mind a kliens, mind pedig a szerver /var/log/messages állományában meg kell jelennie. Hibakeresés Elõfordulhat, hogy a naplószerver valamiért nem kapja meg rendesen az üzeneteket, ezért valamilyen módon meg kell keresnünk a hiba okát. Ez több minden lehet, de általában két leggyakoribb ok valamilyen hálózati kapcsolódási vagy DNS beállítási hiba. Ezek teszteléséhez gondoskodjunk róla, hogy a gépek kölcsönösen elérhetõek egymásról az /etc/rc.conf állományban megadott hálózati nevük szerint. Ha ezzel látszólag minden rendben van, akkor próbáljuk meg módosítani a syslogd_flags értékét az /etc/rc.conf állományban. A most következõ példában a /var/log/naplokliens.log teljesen üres, illetve a /var/log/messages állomány semmilyen hibára utaló okot nem tartalmaz. A hibakereséshez még több információt a syslogd_flags átírásával tudunk kérni: syslogd_flags="-d -a naploklien.minta.com -vv" Természetesen ne felejtsük el újraindítani a szervert: &prompt.root; /etc/rc.d/syslogd restart A démon újraindítása után közvetlenül az alábbiakhoz hasonló üzenetek árasztják el a képernyõt: logmsg: pri 56, flags 4, from naploszerver.minta.com, msg syslogd: restart syslogd: restarted logmsg: pri 6, flags 4, from naploszerver.minta.com, msg syslogd: kernel boot file is /boot/kernel/kernel Logging to FILE /var/log/messages syslogd: kernel boot file is /boot/kernel/kernel cvthname(192.168.1.10) validate: dgram from IP 192.168.1.10, port 514, name naplokliens.minta.com; rejected in rule 0 due to name mismatch. A diagnosztikai üzeneteket végigolvasva nyilvánvaló válik, hogy azért dobja el az üzeneteket a szerver, mert nem megfelelõ a gép neve. Miután átnézzük a beállításainkat, felfedezhetünk az /etc/rc.conf állományban egy apró hibát: syslogd_flags="-d -a naploklien.minta.com -vv" Láthatjuk, hogy ebben a sorban a naplokliens névnek kellene szerepelni, nem pedig a naploklien névnek. Miután elvégeztük a szükséges javításokat, indítsuk újra a szervert és vizsgáljuk meg az eredményt: &prompt.root; /etc/rc.d/syslogd restart logmsg: pri 56, flags 4, from naploszerver.minta.com, msg syslogd: restart syslogd: restarted logmsg: pri 6, flags 4, from naploszerver.minta.com, msg syslogd: kernel boot file is /boot/kernel/kernel syslogd: kernel boot file is /boot/kernel/kernel logmsg: pri 166, flags 17, from naploszerver.minta.com, msg Dec 10 20:55:02 <syslog.err> naploszerver.minta.com syslogd: exiting on signal 2 cvthname(192.168.1.10) validate: dgram from IP 192.168.1.10, port 514, name naplokliens.minta.com; accepted in rule 0. logmsg: pri 15, flags 0, from naplokliens.minta.com, msg Dec 11 02:01:28 pgj: Masodik teszt uzenet Logging to FILE /var/log/naplokliens.log Logging to FILE /var/log/messages Itt már minden üzenet rendben megérkezett és a megfelelõ állományokba került (a /var/log/messages a kliensen, és a /var/log/naplokliens.log a szerveren)). Biztonsági megfontolások Mint minden hálózati szolgáltatás esetén, ilyenkor is figyelembe kell vennünk bizonyos biztonsági megfontolásokat a tényleges konfiguráció kiépítése elõtt. Olykor elõfordulhat, hogy a naplók különbözõ kényes információkat tartalmaznak, mint például a helyi rendszeren futó szolgáltatások nevei, felhasználói nevek vagy egyéb konfigurációs adatok. A kliens és a szerver között hálózaton utazó adatok viszont se nem titkosítottak, se nem jelszóval védettek. Ha titkosítást szeretnénk használni, akkor javasoljuk például a security/stunnel portot, amellyel egy titkosított tunnelen keresztül tudunk adatokat küldeni a hálózaton. A helyi rendszer biztonságának szavatolása is fontos lehet. A naplók sem a használat során, sem pedig a lecserélésük után nem kerülnek titkosításra. Emiatt a helyi rendszerhez hozzáférõ felhasználók kedvükre nyerhetnek ki belõlük a rendszerünket érintõ konfigurációs információkat. Ezért ilyenkor nagyon fontos, hogy mindig a megfelelõ engedélyeket állítsuk be a naplókra. A &man.newsyslog.8; segédprogrammal be tudjuk állítani a frissen létrehozott és a lecserélt naplók engedélyeit. Tehát könnyen megakadályozhatjuk a helyi felhasználók kíváncsiskodását, ha itt a naplók engedélyeit például a 600 kóddal adjuk meg. diff --git a/hu_HU.ISO8859-2/books/handbook/security/chapter.sgml b/hu_HU.ISO8859-2/books/handbook/security/chapter.sgml index 8f1b7d6bff..bbeae50559 100644 --- a/hu_HU.ISO8859-2/books/handbook/security/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/security/chapter.sgml @@ -1,6296 +1,6296 @@ 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 + á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 egyes szinten. A rendszermag védelmi szintjét több különbözõ módon lehet állítani. A védelmi szintet úgy lehet a legegyszerûbben növelni, ha a sysctl paranccsal beállítjuk a kern.securelevel nevû, rendszerszintû változó értékét: &prompt.root; sysctl kern.securelevel=1 A &os; rendszermag alapértelmezés szerint a -1 védelmi szinten indul. Ez egészen addig -1 marad, amíg a rendszergazda vagy valamelyik &man.init.8; során hívott rendszerindító szkript ezt meg nem változtatja. A rendszer indítása során úgy tudjuk beállítani a megfelelõ védelmi szintet, ha az /etc/rc.conf állományban megadjuk a kern_securelevel_enable változót a YES értékkel, illetve kern_securelevel értékeként a kívánt védelmi szintet. A &os; alapértelmezett védelmi szintje közvetlenül a rendszerindító szkriptek lefutása után -1. Ezt nem biztonságos módnak nevezik, mivel az állományok írásáért felelõs állományjelzõk nem feltétlenül mûködnek, mindegyik eszköz írható, olvasható és a többi. Miután a védelmi szintet 1 vagy annál magasabb értékre állítottuk, akkor a rendszer figyelembe veszi a csak hozzáfûzést (append-only) és módosíthatatlanságot (immutable) megszorító állományjelzõket, nem engedélyezi a tiltásukat és az eszközök közvetlenül nem érhetõek el. A különbözõ védelmi szintek részletesebb bemutatását a &man.security.7; man oldalon olvashatjuk (vagy a &os; 7.0 elõtti változataiban a &man.init.8; man oldalon). Az 1 és az afeletti védelmi szinteken többek közt az X11 nem feltétlenül lesz futtatható (mivel a /dev/io eszköz elérése blokkolt), illetve a rendszer frissítése is akadályokba fog ütközni (a installworld futtatása során ideiglenesen ki kell kapcsolni az append-only és immutable állományjelzõket). Az X11 esetében ezt valahogy még ki lehet kerülni úgy, hogy ha az &man.xdm.1; démont még a rendszerindítás elején aktiváljuk (amikor a védelmi szint még kellõen alacsony). Az összes védelmi szint és megszorítás esetén azonban nem mindig adható ilyen jellegû javaslat, ezért ilyenkor mindig érdemes elõre tervezni egy keveset. Emellett fontos alaposan megismerni a különbözõ védelmi megszorításokat, mivel jelentõs mértékben visszafoghatják a rendszer használhatóságát. Ez segít az adott helyzetben az egyszerûbb megoldást választani és ezáltal elkerülni a kellemetlen meglepetéseket. Ha a rendszermag védelmi szintjét az 1 érték vagy afelé emeljük, akkor hasznos lehet a fontosabb (lényegében minden olyan programnak, amely a védelmi szint helyes beállítódása elõtt lefut) programoknak, könyvtáraknak és szkripteknek beállítani az schg állományjelzõt. Ilyenkor azonban vegyük figyelembe, hogy a rendszer frissítése is nehezebbé válik a magasabb védelmi szinteken. Egy mûködõképesebb megoldás lehet, ha rendszerünket egy magasabb védelmi szinten használjuk, de nem állítjuk be mindegyik rendszerszintû állományra az schg állományjelzõt. Másik lehetõség még a / és /usr partíciók írásvédett csatlakoztatása. Ne felejtsük el azonban, hogy ha túlságosan szigorúak vagyunk magunkhoz, akkor azzal egyúttal a behatolás észlelését is meg tudjuk nehezíteni! Az állományok sértetlenségének ellenõrzése: binárisok, konfigurációs állományok stb. Ha arról van szó, csak a legfontosabb rendszerszintû konfigurációs- és vezérlõállományokat tudjuk megvédeni, még mielõtt a korábban emlegetett kényelmi tényezõ kimutatná a foga fehérjét. Például, ha a chflags paranccsal beállítjuk az schg állományjelzõt a / és /usr állományrendszereken található legtöbb állományra, akkor az minden bizonnyal csökkenti a hatékonyságunkat, hiszen az állományok védelmének növekedésével csökken az észlelés lehetõsége. A védelmi vonalaink közül ugyanis az utolsó talán az egyik legfontosabb — a detektálás. A felépített biztonsági rendszerünk legnagyobb része szinte teljesen hasztalan (vagy ami még rosszabb, a biztonság hamis érzetét kelti), ha nem vagyunk képesek észrevenni a betörési kísérleteket. A védelmi rendszer egyik részére nem a támadó megállításához, hanem a lelassításához van szükség, hogy így majd munka közben érhessük tetten. A betörés tényét legjobban a megváltozott, hiányzó vagy éppen váratlanul felbukkanó állományok utáni kutatással tudjuk felismerni. A módosított állományokat általában egy másik (gyakran központosított) korlátozott hozzáférésû rendszerbõl ellenõrizhetjük a legjobban. Fontos, hogy ha egy korlátozott hozzáférésû, kiemelten védett rendszeren írjuk a védelemért felelõs szkripteket, akkor azok szinte teljesen láthatlanok lesznek a támadó számára. A legjobb kihasználás érdekében a korlátozott hozzáférésû gépnek jelentõs mértékû rálátással kell rendelkeznie az összes többi gépre, amit írásvédett NFS exportok vagy ssh kulcspárok felhasználásával érhetünk el. A hálózati forgalmat leszámítva az NFS látszik a legkevésbé — segítségével lényegében észrevétlenül tudjuk figyelni az egyes gépek állományrendszereit. Ha a megfigyelésre használt szerver a kliensekhez switchen keresztül csatlakozik, akkor az NFS gyakran jobb választásnak bizonyul. Ha a szerver hubon vagy több hálózati elemen keresztül éri el a megfigyelni kívánt klienseket, akkor az NFS nem eléggé biztonságos (és hatékony), ezért ilyen esetekben az ssh választása lehet a kedvezõ még az ssh által hagyott nyomokkal együtt is. Miután a korlátozott hozzáférésû gépünk legalább látja a hozzátartozó kliensek rendszereit, el kell készítenünk a tényleges monitorozást végzõ szkripteket. Ha NFS csatlakozást tételezünk fel, akkor az olyan egyszerû rendszereszközökkel, mint például a &man.find.1; és &man.md5.1; képesek vagyunk összerakni ezeket. A szemmel tartott kliensek állományait naponta legalább egyszer érdemes ellenõrizni md5-tel, valamint még ennél gyakrabban is tesztelni az /etc és /usr/local/etc könyvtárakban található konfigurációs és vezérlõállományokat. Ha valamilyen eltérést tapasztal az ellenõrzést végzõ szerverünk és a rajta levõ md5 információk is helyesek, akkor értesítenie kell a rendszergazdát. Egy jó védelmi szkript képes megkeresni az oda nem illõ suid binárisokat, valamint az új vagy törölt állományokat a / és a /usr partíciókon. A védelmi szkriptek megírása valamivel nehezebb feladat, ha ssh-t használunk az NFS helyett. A futtatásukhoz a szkripteket és az általuk használt eszközöket (például find) az scp paranccsal lényegében át kell másolni a kliensekre, amivel így láthatóvá válnak. Ne feledjük továbbá, hogy az ssh kliens már eleve feltört lehet. Szó, ami szó, ha nem megbízható összeköttetésekrõl beszélünk, akkor az ssh használata elkerülhetetlen, de nem feltétlenül egyszerû. Egy jó védelmi szkript észreveszi a felhasználók és a személyzet tagjainak hozzáférését vezérlõ állományokban, mint például az .rhosts, .shosts, .ssh/authorized_keys és társaiban keletkezett változásokat is, amelyek esetleg elkerülhetik egy MD5 alapú ellenõrzés figyelmét. Ha netalán órási mennyiségû tárterületettel rendelkeznénk, akkor eltarthat egy ideig, amíg végigsöprünk az összes partíció összes állományán. Ebben az esetben érdemes olyan beállításokat megadni az állományrendszerek csatlakoztatásánál, amivel le tudjuk tiltani a suid engedéllyel rendelkezõ binárisok futtatását. Ezzel kapcsolatban a &man.mount.8; parancs nosuid opcióját nézzük meg. Hetente legalább egyszer azért mégis érdemes átnézni az ilyen partíciókat is, mivel ez a réteg a betörési kísérletek felderítésével foglalkozik, függetlenül a sikerességüktõl. A futó programok nyilvántartása (lásd &man.accton.8;) egy olyan viszonylag kevés költséggel járó lehetõség az operációs rendszerben, ami segítségünkre lehet a betörés utáni események kiértékelésében. Különösen hasznos olyankor, amikor megpróbáljuk modellezni, miképp is sikerült a támadónak bejutnia a rendszerünkbe, természetesen feltételezve, hogy az ehhez felhasznált feljegyzések a betörés után is érintetlenek maradtak. Végül a védelmet ellátó szkripteknek javasolt feldolgozni a naplóállományokat is, valamint a naplókat magukat is a lehetõ legbiztonságosabb formában generálni — ilyenkor nagyon hasznos lehet, ha egy távoli gépre naplózunk. A behatoló megpróbálja majd eltüntetni a nyomait, a naplóállományok viszont nagyon fontosak a rendszergazda számára a betörési kísérletek idejének és módjának megállapításában. A naplókat úgy tudjuk tartósan rögzíteni, ha a rendszerkonzol üzeneteit soros porton keresztül gyûjtjük össze a konzolok felügyeletéért felelõs biztonságos gépen. Állandó paranoia Egy kis paranoia sosem árt. Elmondható, hogy a rendszergazda tetszõleges számú biztonsági intézkedéssel élhet egészen addig, amíg az nincs hatással a kényelmére, és a kényelmet befolyásoló biztonsági intézkedéseket pedig megfelelõ mérlegelés mellett tegye meg. Ami még ennél is fontosabb, hogy mindig változtassunk valamit a biztonsági hálónkon — mivel ha egy az egyben követjük a dokumentumban leírtakat, akkor ezzel együtt kiadjuk a bejutás receptjét annak a leendõ támadónknak, aki szintén elolvasta ugyanezt. A szolgáltatások mûködésképtelenné tételét célzó támadások Denial of Service (DoS) Ez a szakasz a szolgáltatások mûködésképtelenségét elérni kívánó, más néven Denial of Service típusú támadásokkal foglalkozik. Noha nem tudunk túlságosan sokat tenni a manapság felbukkanó álcázott, a hálózatunk totális leterhelését célbavevõ támadások ellen, akadnak olyan általános érvényû eszközök, amelyekkel elejét vehetjük a szervereink szétbomzásának: A létjövõ szerverpéldányok korlátozása. Az ugródeszkaszerû támadások (támadás ICMP-válasszal, pingszórás stb.) korlátozása. A rendszermag útválasztási gyorsítótárának túlterhelése. A DoS támadások egyik jellemzõ sémája szerint egy sokszorozódni képes szervert támadnak meg, amelynek igyekeznek minél több példányát legyártatni, míg végül az ezt futtató rendszer ki nem fogy a memóriából, állományleíróból satöbbibõl és megállásra nem kényszerül. Az inetd (lásd &man.inetd.8;) számos lehetõséget kínál fel ennek megakadályozására. Ezzel kapcsolatban szeretnénk megjegyezni, hogy bár ezzel el tudjuk kerülni a gépünk leállását, semmilyen garanciát nem ad arra, hogy a szolgáltatás a támadás során is zavartalanul üzemel tovább. Alaposan olvassuk el az inetd man oldalát és legyünk különös tekintettel a , és kapcsolóira. Vigyázzunk, hogy az inetd kapcsolóját képesek kijátszani az álcázott IP-vel érkezõ támadások, ezért inkább az elõbbi kapcsolók valamilyen kombinációja az ajánlott. Egyes szerverprogramoknál be lehet állítani a példányainak maximális számát. A Sendmail rendelkezik egy beállítással, ami a terhelésben levõ késleltetése miatt néha mintha jobban beválna, mint a Sendmail terheléskorlátozó paraméterei. A Sendmail indításakor tehát a MaxDaemonChildren paramétert javasolt megadni egy olyan értékkel, amely elegendõ a Sendmail számára betervezett terhelés kiszolgálására, de még kevés ahhoz, hogy a Sendmail fûbe harapjon tõle. Továbbá bölcs dolog a Sendmailt várakozási sorral () és démonként (sendmail -bd), külön feldolgozási menetekkel (sendmail -q15m) futtatni. Ha továbbra is valós idejû kézbesítést akarunk, akkor a feldolgozást kisebb idõközökkel is lefuttathatjuk (például ), de arra mindig ügyeljünk, hogy a MaxDaemonChildren beállítása ne okozzon kaszkádosítási hibákat a Sendmail mûködésében. A Syslogd közvetlenül is támadható, ezért határozottan javasoljuk a használatát, amikor csak lehet, minden más esetben pedig a beállítást. Fordítsunk kellõ figyelmet a TCP kapcsolatok burkolását végzõ TCP Wrapper reverse-ident lehetõségére, ami szintén közvetlenül támadható. Ebbõl az okból kifolyólag valószínûleg nem is akarjuk a TCP Wrapper által felkínált reverse-ident-et használni. Jól járunk el abban az esetben, ha a belsõ szolgáltatásainkat az útválasztóink mentén tûzfal segítségével védjük meg a külsõ hozzáféréstõl. Ezzel lényegében a helyi hálózatunkat kívülrõl fenyegetõ támadások ellen védekezünk, de ez nem nyújt elegendõ védelmet a belsõ szolgáltatásaink esetén a root hozzáférés megszerzésére irányuló kísérletek ellen. Mindig egy exkluzív, tehát zárt tûzfalat állítsunk be, vagyis tûzfalazzunk mindent kivéve az A, B, C, D és M-Z portokat. Ezen a módon ki tudjuk szûrni az összes alacsonyabb portot, kivéve bizonyos eseteket, mint például a named (ha az adott zónában ez az elsõdleges gép), ntalkd, sendmail vagy más interneten keresztül elérhetõ szolgáltatásokat. Ha másképpen állítjuk a tûzfalat — inkluzív, nyílt avagy megengedõ módon, akkor jó eséllyel elfelejtünk lezárni egy csomó szolgáltatást, vagy úgy adunk hozzá egy új belsõ szolgáltatást, hogy közben elfelejtjük frissíteni a tûzfalat. Ennél még azon is jobb, ha a tûzfalon nyitunk egy magasabb portszámú tartományt, és ott valósítjuk meg ezt a megengedõ jellegû mûködést, az alacsonyabb portok veszélybe sodrása nélkül. Vegyük azt is számításba, hogy a &os;-ben a kiosztott portokat dinamikusan állíthatjuk a net.inet.ip.portrange sysctl változókon keresztül (sysctl -a | fgrep portrange), ami nagyságrendekkel megkönnyíti a tûzfal beállítását. Ennek megfelelõen például meg tudjuk adni, hogy a 4000-tõl 5000-ig terjedõ porttartomány a 49152-tõl 65535-ig húzódó tartományba kerüljön át, majd a 4000 alatti összes portot blokkoljuk (természetesen az internetrõl szándékosan hozzáférhetõ portok kivételével). A DoS támadások másik elterjedt fajtája az ún. ugródeszka támadás — ilyenkor a szervert úgy próbálják túlterhelni, hogy folyamatosan válaszokat kérnek tõle a helyi hálózatról vagy egy másik számítógéprõl. Az ilyen természetû támadások közül is a legnépszerûbb az ICMP pingszórásos támadás. A támadó olyan ping csomagokat küld szét a helyi hálózaton, amelyek forrásának azt a gépet jelöli meg, amelyiket meg akarja támadni. Ha a hálózatokat elválasztó útválasztók nem fogják meg a pingszórást, akkor a helyi hálózatról összes gépe nekilát válaszolgatni a meghamisított forrás címére, amivel így teljesen leterhelik az áldozatot. Ez különösen akkor hatásos, amikor a támadó ugyanezt a trükköt eljátssza egyszerre több tucat különbözõ hálózatban is. Az üzenetszórással járó támadások akár százhúsz megabitnyi forgalmat is képesek generálni másodpercenként. A második legelterjedtebb ugródeszkás támadás az ICMP hiba-visszajelzési rendszere ellen irányul. Ilyenkor a támadó ICMP hibaüzeneteket kiváltó csomagok készítésével képes eltömíteni egy szerver bejövõ hálózati kapcsolatát és az ICMP válaszokkal pedig a szerver maga dugítja el a kimenõ hálózati kapcsolatát. Ez a fajtájú támadás képes kinyomni az összes memóriát a szerverbõl és ezzel összeomlasztani, különösen olyankor, amikor a szerver nem tudja elég gyorsan elnyelni az általa generált ICMP válaszokat. A net.inet.icmp.icmplim sysctl változóval tudunk gátat szabni a támadások ezen fajtájának. Az ugródeszkás támadások utolsó nagyobb osztálya az inetd olyan szolgáltatásait szemeli ki, mint például az udp echo. A támadó ilyenkor egyszerûen küld a helyi hálózatunkon található A és B szerverünknek egy olyan UDP csomagot, ahol forrásként az A szerver echo portját adja meg, célnak pedig a B szerver echo portját. Ezután a két szerver elkezdi egymás között passzolgatni ezt az egyetlen csomagot. A támadó még több ilyen csomag befecskendezésével pillanatok alatt képes leterhelni a két szervert és helyi hálózatot. Hasonló problémák vannak a belsõ chargen portjával is. Egy hozzáértõ rendszergazda ezért kikapcsolja az összes ilyen inetd-alapú belsõ tesztelõ szolgáltatást. Az álcázott csomagok felhasználhatóak a rendszermag útválasztó gyorsítótárának túlterhelésére is. Ezzel kapcsolatban nézzük meg a net.inet.ip.rtexpire, rtminexpire és rtmaxcache sysctl változókat. A véletlenszerû IP-címekkel megcímzett álcázott csomagok hatására a rendszermag létrehoz mindegyikõjükhöz egy ideiglenesen pufferelt utat az útválasztó táblázatában, amelyet a netstat -rna | fgrep W3 paranccsal tudunk lekérdezni. Az ilyen útvonalak nagyjából 1600 másodperc múlva elévülnek. Ha a rendszermag észleli, hogy a gyorsítótárazott útválasztási táblázat mérete túlságosan megnövekedett, akkor automatikusan csökkenti az rtexpire értékét, de soha nem megy a rtminexpire alá. Ebbõl két probléma adódik: A rendszermag nem reagál elég gyorsan amikor egy alig terhelt szervert hirtelen megtámadnak. Az rtminexpire nem elég kicsi ahhoz, hogy a rendszermag túléljen egy tartósabb rohamot. Ha a szervereink az internethez T3 (kb. 45 Mbit/s) vagy gyorsabb összeköttetésen keresztül csatlakoznak, akkor határozottan javasolt kézileg behangolni a &man.sysctl.8; segítségével az rtexpire és az rtminexpire értékeket. Soha ne állítsuk egyiket sem nullára (hacsak nem akarjuk összeomlasztani a gépünket). Ha például mind a kettõt 2 másodpercre állítjuk, akkor az többnyire elegendõ az útválasztási táblázat megvédéséhez. Hozzáférés Kerberosszal és SSH-val ssh KerberosIV Van néhány dolog, amit a Kerberos és az ssh esetén ajánlatos tisztázni, mielõtt használjuk ezeket. A Kerberos 5 egy kifogástalan hitelesítési protokoll. A telnet és rlogin Kerberos által módosított változatában vannak olyan hibák, amelyek alkalmatlanná teszik ezeket a bináris adatfolyamok helyes kezelésére. Sõt, alapértelmezés szerint a Kerberos nem titkosítja a kapcsolatot, csak ha megadjuk neki a kapcsolót. Az ssh alapértelmezés szerint mindent titkosít. Az ssh minden szempontból nagyon jól teljesít kivéve, hogy alapértelmezés szerint átküldi a kulcsokat is. Ez azt jelenti, hogy ha van egy olyan biztonságos munkaállomásunk, ahol a rendszer többi részéhez tartozó kulcsainkat tartjuk és egy nem biztonságos gépre akarunk vele ssh-n keresztül belépni, akkor a kulcsaink használatóvá válnak. A tényleges kulcsokat ugyan nem látja senki, de a bejelentkezés során az ssh megnyit egy közvetítéshez használt portot, amit a nem biztonságos gépen a támadó egy feltört root hozzáférés birtokában ki tud használni úgy, hogy a kulcsaink segítségével hozzá tudjon férni egy másik olyan géphez, amelyet a kulcsok nyitnak. Ha lehetséges, akkor a személyzet bejelentkeztetéséhez az ssh-t és Kerberost együttesen használjuk. Az ssh lefordíható Kerberos támogatással. Ezzel csökkentjük a potenciálisan kiszivárgó ssh kulcsok esélyét, miközben jelszavainkat a Kerberosszal védjük. Az ssh kulcsokat csak biztonságos gépekrõl és csak automatizált feladatok esetén használjuk (amire a Kerberos lényegében nem alkalmas). Emellett javasoljuk azt is, hogy az ssh beállításai között tiltsuk le a kulcsok átküldését (key forwarding) vagy használjuk az from=IP/DOMAIN opciót, amivel az ssh csak a megadott gépekrõl engedi az authorized_keys állomány és a így benne levõ kulcsok használatát. Bill Swingle Egyes részeit újraírta és aktualizálta: DES, Blowfish, MD5 és a Crypt biztonság crypt crypt Blowfish DES MD5 Minden &unix; rendszer használójához tartozik egy jelszó is a hozzáféréséhez. Teljesen nyilvánvalónak tûnik, hogy ezt a jelszót csak az adott felhasználó és az adott operációs rendszer ismeri. A jelszavakat a titokban tartásukhoz ún. csapóajtó függvényekkel titkosítják, amelyeket könnyû titkosítani, ám nehéz visszafejteni. Tehát amit egy perccel ezelõtt még nyilvalónak tituláltunk, az mostanra már nem is teljesen igaz: valójában az operációs rendszer sem ismeri a jelszót. Az operációs rendszer csak a jelszó titkosított változatát ismeri. A jelszó titkosítatlan formáját csak nyers erõ igényebevételével tudjuk megkeresni az összes lehetséges jelszó szénakazlában. Sajnos, annak idején, amikor a jelszavak titkosítása bekerült a &unix;-ba, egyedül a DES, vagy más néven a Data Encryption Standard (Adattitkosítási szabvány) jött szóba. Ez alapvetõen nem jelentett problémát az Egyesült Államok állampolgárai számára, de mivel a DES forráskódját nem lehetett kivinni az Egyesült Államokból, a &os;-nek találnia kellett valami olyasmit, ami mind megfelel az Egyesült Államok törvényeinek, mind pedig kompatibilis marad az összes többi DES-t használó &unix; variánssal. Ezt úgy oldották meg, hogy felosztották a titkosítással foglalkozó függvénykönyvtárakat, így az Egyesült Államokban élõ felhasználók tudtak DES könyvtárakat telepíteni és használni, miközben a többi nemzet felhasználói olyan más titkosítási módszert tudtak választani, amit kinn is lehetett alkalmazni. Ennek tulajdonítható, hogy a &os; alapértelmezés szerint az MD5 segítségével titkosít. Az MD5-öt a DES-nél sokkalta biztonságosabbnak tartják, ezért a DES telepítésének lehetõségét leginkább csak kompatibilitási okokból ajánlották fel. A titkosítási mechanizmus azonosítása Jelenleg a könyvtár ismeri a DES, MD5 és Blowfish függvényeit. A &os; a jelszavak titkosításához alapból az MD5-öt használja. Nagyon könnyen meg tudjuk mondani, hogy a &os; éppen melyik titkosítási módszert alkalmazza. Ennek egyik lehetõsége, ha az /etc/master.passwd állományt vizsgáljuk meg. Az MD5 függvényével titkosított jelszavak hosszabbak, mint a DES függvényével titkosítottak és a $1$ karakterekkel kezdõdnek. A $2a$ karakterekkel kezdõdõ jelszavakat Blowfish-sel titkosították. A DES kódolású jelszavaknak nincs semmilyen különleges ismertetõjelük, de általánosságban elmondható róluk, hogy rövidebbek az MD5 jelszavaknál és olyan 64 karakteres ábécével kódolják ezeket, amelyek nem tartalmazzák a $ karaktert, így tehát a viszonylag rövid, nem dollárjellel kezdõdõ karakterláncok minden bizonnyal DES kódolású jelszavak. Az új jelszavak kódolásához használt formátumot az /etc/login.conf állományban tárolt passwd_format bejelentkezési tulajdonság adja meg, amelynek értékei des, md5 vagy blf lehetnek. A &man.login.conf.5; man oldalon tájékozódhatunk bõvebben a bejelentkezési tulajdonságokról. Egyszeri jelszavak egyszeri jelszavak biztonság egyszeri jelszavak A &os; alapértelmezés szerint támogatja az OPIE-t (One-time Passwords In Everything, azaz Egyszeri jelszavak mindenben), ami alapból az MD5 függvényét használja. A jelszavak három fajtáját fogjuk a továbbiakban tárgyalni. Az elsõ a megszokott &unix; stílusú avagy Kerberos jelszó. Ezt a továbbiakban &unix; jelszónak nevezzük. A második fajtában az OPIE &man.opiekey.1; nevû segédprogramja által generált és a bejelentkezésnél a &man.opiepasswd.1; által elfogadott jelszavak tartoznak. Ezeket egyszeri jelszavaknak fogjuk nevezni. A jelszavak utolsó típusa az a titkos jelszó, amit az opiekey programnak (és néha a opiepasswd programnak) adunk meg, ami ebbõl egyszer használatos jelszavakat állít elõ. Ezt innentõl titkos jelszónak vagy csak egyszerûen jelszónak hívjuk. A titkos jelszónak semmi köze sincs a &unix; jelszavunkhoz. Természetesen megegyezhetnek, de ezt nem ajánljuk. Az OPIE által használt titkos jelszavaknak nem kell a régi &unix; jelszavakhoz hasonlóan legfeljebb 8 karakteresnek lenniük &os; alatt a bejelentkezéshez használt szabványos jelszavak akár 128 karakteresek is lehetnek. , bármekkorát használhatunk. A hat vagy hét szóból álló jelszavak ilyenkor igen gyakoriak. Az OPIE jobbára a &unix; jelszórendszerétõl teljesen függetlenül mûködik. A jelszavak mellett két másik fajta adat fontos az OPIE számára. Közülük az egyiket magnak vagy kulcsnak nevezik, ami két betûbõl és öt számjegybõl áll. A másik az iterációk száma, ami egy 1 és 100 közötti számot takar. Az OPIE úgy hozza létre az egyszeri jelszavakat, hogy egymás után fûzi a magot és a titkos jelszót, majd az iterációk megadott számának megfelelõ mennyiségben kiszámolja rá az MD5 függvény értékét és az eredményt hat rövid angol szóba önti. Ez a hat angol szó lesz a mi egyszeri jelszavunk. A hitelesítéssel foglalkozó rendszer (elsõsorban a PAM) figyelemmel kíséri a legutoljára használt egyszeri jelszavunkat, és csak akkor engedi a felhasználót hitelesíteni, ha az általa megadott jelszó kódolt változata megegyezik az elõzõleg megadott jelszaváéval. A csapóajtó függvények használata miatt lehetetlen legenerálni a következõ egyszeri jelszót, ha a sikerült megszereznünk az egyiket. Az iterációk száma minden egyes sikeres bejelentkezés után csökken eggyel, amivel a felhasználót és a bejelentkeztetõ programot szinkronban tartja. Amikor így az iterációk száma eléri az egyet, az OPIE-t újra kell inicializálni. Az említésre kerülõ rendszerek mindegyikéhez tartozik néhány program. Az opiekey bekéri az iterációk számát, a magot és a titkos jelszót, majd elõállít egy egyszer használatos jelszót vagy azok folytonos listáját. Az opiepasswd az OPIE inicializálásért, a jelszavak, az iterációk számának és a mag megváltoztatásáért felelõs. Egyaránt elfogad titkos jelmondatot, iterációs számot vagy magot és egy egyszeri jelszót. Az opieinfo megvizsgálja a felhasználókra vonatkozó adatbázist (/etc/opiekeys) és kiírja az adott felhasználó által használt iterációs számot és magot. Négyféle különbözõ mûveletrõl fogunk most itt beszélni. Az elsõben egy biztonságos kapcsolaton keresztül elsõként inicializáljuk az egyszeri jelszavakat, vagy megváltoztatjuk a jelszót vagy a magot az opiepasswd segítségével. A második mûveletben ugyanarra adjuk ki az opiepasswd parancsot egy nem biztonságos kapcsolaton keresztül az opiekey paranccsal együtt egy biztonságos kapcsolaton keresztül. A harmadikban az opiekey használatával nem biztonságos kapcsolaton keresztül jelentkezünk be. A negyedikben az opiekey paranccsal létrehozunk egy adott mennyiségû kulcsot, amelyeket aztán leírhatunk vagy kinyomtathatunk, hogy magunkkal tudjuk vinni olyan helyre, ahonnan nem tudnk biztonságos módon csatlakozni. Inicializálás biztonságos kapcsolattal Az OPIE elsõ inicializálásához adjuk ki az opiepasswd parancsot: &prompt.user; opiepasswd -c [grimreaper] ~ $ opiepasswd -f -c Adding unfurl: Only use this method from the console; NEVER from remote. If you are using telnet, xterm, or a dial-in, type ^C now or exit with no password. Then run opiepasswd without the -c parameter. Using MD5 to compute responses. Enter new secret pass phrase: Again new secret pass phrase: ID unfurl OTP key is 499 to4268 MOS MALL GOAT ARM AVID COED A figyelmeztetés fordítása: Ezt a módszert csak konzolról alkalmazzuk, SOHA ne távoli kapcsolaton keresztül! Ha telnetet, xtermet vagy betárcsázós kapcsolatot használunk, akkor azonnal nyomjunk ^C-t vagy ne adjunk meg jelszót. Az Enter new secret pass phrase: vagy Enter secret password: kérdések után adjunk meg egy jelmondatot, illetve jelszót. Ne felejtsük el, hogy ez nem bejelentkezéshez használt jelszó lesz, hanem ebbõl jönnek majd létre az egyszeri kulcsaink. Az ID sor adja meg az aktuális példányunk paramétereit: a bejelentkezéshez használt nevünket, az iterációk számát és a magot. Amikor a bejelentkezések során a rendszer emlékszik a paraméterekre és megjeleníti ezeket, nem kell megjegyeznünk. Az utolsó sor adja meg a paramétereinknek és a titkos jelszavunknak megfelelõ egyszeri jelszót. Ha most azonnal akarnánk bejelentkezni, akkor ezt az egyszeri jelszót kellene hozzá használnunk. Inicializálás nem biztonságos kapcsolattal Ha egy nem biztonságos kapcsolaton keresztül akarjuk inicializálni vagy megváltoztatni a jelszavunkat, akkor szükségünk lesz valahol egy megbízható kapcsolatra, ahol le tudjuk futtatni az opiekey parancsot. Ez lehet egy számunkra biztonsági szempontból elfogadható gép parancssora. Emellett ki kell találnunk egy iterációs számot (erre a 100 egy jó választás) és adnunk egy magot vagy használni egy véletlenszerûen generáltat. Az inicializálás színtere felé vezetõ nem biztonságos kapcsolaton keresztül adjuk ki az opiepasswd parancsot: &prompt.user; opiepasswd Updating unfurl: You need the response from an OTP generator. Old secret pass phrase: otp-md5 498 to4268 ext Response: GAME GAG WELT OUT DOWN CHAT New secret pass phrase: otp-md5 499 to4269 Response: LINE PAP MILK NELL BUOY TROY ID mark OTP key is 499 gr4269 LINE PAP MILK NELL BUOY TROY Az alapértelmezett mag elfogadásához nyomjuk le a Return billentyût. Mielõtt megadnánk a hozzáférés jelszavát, menjünk át a biztonságos kapcsolatra és adjuk meg neki ugyanezeket a paramétereket: &prompt.user; opiekey 498 to4268 Using the MD5 algorithm to compute response. Reminder: Don't use opiekey from telnet or dial-in sessions. Enter secret pass phrase: GAME GAG WELT OUT DOWN CHAT Most váltsunk vissza a nem biztonságos kapcsolatra és másoljuk be az így generált egyszeri jelszót a megfelelõ programba. Egyetlen egyszeri jelszó létrehozása Miután sikeresen inicializáltuk az OPIE-t és bejelentkezünk, a következõket láthatjuk: &prompt.user; telnet example.com Trying 10.0.0.1... Connected to example.com Escape character is '^]'. FreeBSD/i386 (example.com) (ttypa) login: felhasználói_név otp-md5 498 gr4269 ext Password: Mellékesen megjegyezzük, hogy az OPIE paranccsorának van egy (itt nem látható) hasznos képessége: ha Return billentyût nyomunk a jelszó bekérésekor, akkor a program megmutatja a begépelt betûket, így láthatjuk pontosan mit is írunk be. Ez nagyon kényelmes lehet olyankor, amikor valahonnan, például egy lapról olvassuk a jelszót. MS-DOS Windows MacOS A bejelentkezéshez ekkor le kell valahogy generálnunk az egyszeri jelszavunkat. Ezt egy megbízható rendszeresen tudjuk megtenni az opiekey lefuttatásával. (Ennek vannak DOS-os, &windows;-os és &macos;-es változatai is.) Paraméterként az iterációs számot és a magot kell megadnunk. Ezt akár közvetlenül át is másolhatjuk annak a gépnek a bejelentkezési képernyõjérõl, ahova be akarunk jelentkezni. A megbízható rendszeren tehát: &prompt.user; opiekey 498 to4268 Using the MD5 algorithm to compute response. Reminder: Don't use opiekey from telnet or dial-in sessions. Enter secret pass phrase: GAME GAG WELT OUT DOWN CHAT Most már megvan a bejelentkezéshez szükséges egyszeri jelszavunk. Több egyszeri jelszó létrehozása Néha olyan helyekre kell mennünk, ahol se egy megbízható gép, sem pedig biztonságos kapcsolat nem található. Ilyen esetekben megadhatjuk az opiekey parancsnak, hogy elõre gyártson le több egyszer használatos jelszót, amit késõbb aztán ki tudunk nyomtatni. Például: &prompt.user; opiekey -n 5 30 zz99999 Using the MD5 algorithm to compute response. Reminder: Don't use opiekey from telnet or dial-in sessions. Enter secret pass phrase: <secret password> 26: JOAN BORE FOSS DES NAY QUIT 27: LATE BIAS SLAY FOLK MUCH TRIG 28: SALT TIN ANTI LOON NEAL USE 29: RIO ODIN GO BYE FURY TIC 30: GREW JIVE SAN GIRD BOIL PHI Az öt kulcsot kér egymás után, a pedig megadja az utolsó iterációs számot. Vegyük észre, hogy a kulcsokat a felhasználás sorrendjével ellentétes sorrendben írja ki a program. Ha igazán paranoiások vagyunk, akkor írjuk le kézzel a jelszavakat. Ha viszont annyira nem, akkor egyszerûen küldjük át ezeket az lpr parancsnak. Megfigyelhetjük, hogy minden sorban látható az iterációs szám és a hozzátartozó egyszeri jelszó. Hasznos lehet a felhasználás szerinti felírni a jelszavakat. A &unix; jelszavak használatának leszûkítése Az OPIE képes a bejelentkezéshez használt IP-címek alapján leszûkíteni a &unix; jelszavak használatát. Ehhez az /etc/opieaccess használható, amely alapból megtalálható a rendszerünkön. Az &man.opieaccess.5; man oldalán találhatjuk meg a rá vonatkozó információkat és az összes vele kapcsolatos biztonsági megfontolást. Íme egy példa az opieaccess állományra: permit 192.168.0.0 255.255.0.0 Ezzel a sorral megengedjük a &unix; jelszavak használatát minden olyan felhasználó számára, akinek az IP-je illeszkedik a megadott címre és maszkra (ez viszont álcázással kijátszható). Ha az opieaccess állományból egyetlen szabály sem illeszkedik, akkor alapértelmezés szerint nem engedélyezettek a nem OPIE típusú jelszavak. Tom Rhodes Írta: TCP burkolók A TCP kapcsolatok burkolása Aki ismeri az &man.inetd.8; programot, az már biztosan hallott a TCP kapcsolatok burkolásáról, eredeti nevén a a TCP wrapperekrõl. Azonban csak kevesek képesek felfogni ezek valódi hasznát. Úgy néz ki, mindenki csak tûzfalakon keresztül akarja megoldani a hálózati kapcsolatot kezelését. Habár a tûzfalakat sok mindenre fel lehet ugyan használni, egyetlen tûzfal nem képes például szövegesen válaszolni a kapcsolatok kezdeményezõinek. Ellenben bármelyik TCP-wrapper szoftver képes erre, sõt még többre is. A következõ néhány szakaszban szemügyre vesszük a TCP wrapperek számos lehetõségét, és ahol lehetséges, ott konfigurációs állományokkal is illusztráljuk ezek használatát. A TCP burkoló szoftverek kiterjesztik az inetd képességeit minden alatta dolgozó szerverdémon támogatására. Ezzel a módszerrel meg lehet oldani a naplózást, üzenetek küldését a kapcsolatokhoz, a démonok elérhetõségének korlátozását stb. Noha ezen lehetõségek közül néhány tûzfallal is megvalósítható, ezzel nem csupán egy további védelmi réteget húzunk fel a rendszerünk köré, hanem túllépjük mindazt, amit egy tûzfallal irányítani lehet. A TCP burkolók használatával hozzáadott funkcionalitás azonban nem helyettesít egy jó tûzfalat. A TCP kapcsolatok burkolását tûzfallal vagy más egyéb biztonsági megoldással együtt tudjuk csak eredményesen használni, viszont a rendszerünk biztonságában egy újabb remek védelmi vonalat képvisel. Mivel lényegében ez az inetd beállításának kibõvítése, ezért a szakasz elolvasásához feltételezzük az inetd beállításával kapcsolatos tudnivalók ismeretét. Bár az &man.inetd.8; által indított programok nem egészen tekinthetõen démonoknak, hagyományosan démonnak hívják ezeket. Ezért rájuk ebben a szakaszban is ezt a kifejezést használjuk. Kezdeti beállítások &os; alatt a TCP burkolók használatának egyetlen feltétele csupán annyi, hogy az inetd parancsot a paraméterrel indítsuk az rc.conf állományból. Az egyébként az alapbeállítás. Természetesen nem árt, ha helyesen állítjuk be az /etc/hosts.allow állományt is, ellenkezõ esetben a &man.syslogd.8; egyébként dobálni fogja errõl az üzeneteket. Eltérõen a TCP burkolók egyéb implementációitól, a hosts.deny állományt itt már nem használjuk. Minden beállítást az /etc/host.allow állományba kell raknunk. A legegyszerûbb konfiguráció esetén a démonok kapcsolódását egyszerûen engedélyezhetjük vagy letilthatjuk az /etc/hosts.allow állományban szereplõ beállításokkal. A &os; alapértelmezett beállításai szerint minden inetd által indított démonhoz lehet kapcsolódni. Ennek megváltoztatásával az alapkonfiguráció áttekintése után foglalkozunk. Az alapkonfiguráció általában démon : cím : cselekvés alakú. Itt a démon egy olyan démonra utal, amelyet az inetd indított el. A cím egy érvényes hálózati név, IP-cím vagy szögletes zárójelek ([ ]) között megadott IPv6 formátumú cím. A cselekvést tartalmazó mezõ (action) lehet allow vagy deny annak megfelelõen, hogy engedélyezzük vagy tiltjuk a megadott címrõl a csatlakozást. Nem szabad elfelejtenünk, hogy az így megadott beállítások közül mindig az elsõként illeszkedõ érvényesül, ami arra utal, hogy a konfigurációs állományban szereplõ szabályok egymás után növekvõ sorrendben értékelõdnek ki. Ha valamelyikük illeszkedik, akkor a keresés megáll. Rengeteg egyéb opció is megadható még, de ezekrõl csak a késõbbi szakaszokban fogunk szólni. Egy egyszerû konfigurációs állomány már ennyi információból is könnyedén összeállítható. Például, ha engedélyezni szeretnénk a POP3 kapcsolatokat a mail/qpopper démonon keresztül, akkor a következõ sorral kell kiegészítenünk a hosts.allow állományt: # Ez a sor kell a POP3 kapcsolatokhoz: qpopper : ALL : allow Miután hozzáadtuk ezt a sort, az inetd szervert újra kell indítanunk. Ezt vagy a &man.kill.1; paranccsal, vagy pedig az /etc/rc.d/inetd szkript restart paraméterével tehetjük meg. Komolyabb beállítások A TCP kapcsolatok burkolásánál is meg lehet adni további opciókat. Segítségükkel még jobban irányítani tudjuk a kapcsolatok kezelésének módját. Néhány esetben az is hasznos lehet, ha küldünk valamilyen választ az egyes gépeknek vagy démonoknak. Máskor szükségünk lehet a csatlakozások naplózására vagy e-mailen keresztüli jelzésére a rendszergazda felé. Teljesen más helyezetekben csak a helyi hálózatunkról engedjük meg a csatlakozást. Ez mind lehetséges a helyettesítõ jelekként ismert beállítási opciók, kiterjesztõ karakterek és külsõ parancsok végrehajtásának használatával. A következõ két szakasz az ilyen és ehhez hasonló szituációk megoldására íródott. Külsõ parancsok Tegyük fel, hogy olyan helyezetben vagyunk, amikor a kapcsolatot tiltani akarjuk, de közben azért szeretnénk errõl értesíteni a kapcsolatot kezdeményezõ felet is. Hogyan tudjuk ezt megcsinálni? Ezt a nevû opcióval tehetjük meg. Amikor megpróbál valaki csatlakozni, akkor a hívódik meg és végrehajt egy megadott parancsot vagy szkriptet. Erre találunk is egy példát a hosts.allow állományban: # The rest of the daemons are protected. ALL : ALL \ : severity auth.info \ : twist /bin/echo "You are not welcome to use %d from %h." Ez a példa a következõ üzenetet jeleníti meg: You are not allowd to use a démon neve from hálózati név. (Jelentése: A démon neve démont nem érheti el a hálózati név helyrõl!) Ez minden olyan démon esetén megjelenik, amirõl nem nyilatkoztunk korábban az állományban. Ezzel nagyon könnyen vissza tudunk küldeni egy választ a kapcsolat kezdményezõje felé, miután a kapcsolatot eldobtuk. Vegyük észre, hogy a visszaküldendõ üzenetet " karakterek közé kell tennünk, ez alól semmi sem kivétel. DoS támadást lehet elõidézni azzal, ha egy támadó vagy támadók egy csoportja csatlakozási kérelmekkel kezdi el bombázni a démonainkat. Ilyen esetekben használhatjuk a opciót is. A a opcióhoz hasonlóan implicit módon tiltja a kapcsolódást és arra használható, hogy lefuttassunk vele egy parancsot vagy szkriptet. A azonban a opciótól eltérõen nem küld vissza semmilyen választ a kapcsolatot létrehozni kívánó egyénnek. Ehhez példaként vegyük a következõ sort a konfigurációs állományban: # We do not allow connections from example.com: ALL : .example.com \ : spawn (/bin/echo %a from %h attempted to access %d >> \ /var/log/connections.log) \ : deny Ezzel a *.example.com címtartományból érkezõ összes kapcsolódási kísérlet sikertelen lesz, miközben ezzel egyidõben a /var/log/connections.log állományba rögzítjük a csatlakozni akaró egyén hálózati nevét, IP-címét és a démont. A korábban már kifejtett helyettesítõ karakterek túl, mint például az %a, még léteznek továbbiak is. Róluk a &man.hosts.access.5; man oldalon találhatjuk meg a teljes listát. Helyettesítõ jelek Az eddigi példákban folyamatosan csak az ALL opciót adtuk meg. Azonban rajta kívûl léteznek mások is, amivel a megoldás funkcionalitását még egy kicsivel tovább növelhetjük. Például az ALL használható egy démon, egy tartomány vagy egy IP-cím illesztésére. A másik ilyen helyettesítõ jel a PARANOID, amelyet olyan gépek IP-címének illesztésekor alkalmazhatunk, ami feltételezhetõen hamis. Más szóval a PARANOID olyan cselekvések megadását teszi lehetõvé, amelyek akkor hajtódnak végre, amikor a kapcsolatot létrehozó gép IP-címe eltér a hálózati nevétõl. A most következõ példa valószínûleg segít fényt deríteni ennek lényegére: # Block possibly spoofed requests to sendmail: sendmail : PARANOID : deny A példában minden olyan kapcsolatkérést elutasítunk, ami a sendmail felé a hálózati névtõl eltérõ IP-címrõl irányul. Ha rossz DNS beállításokat használunk, a PARANOID megadásá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; kdestroy 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. Az IPsec beállításához elengedhetetlen, hogy tisztában legyünk egy saját rendszermag fordításának alapjaival (lásd ). Az IPsec egy olyan protokoll, amely az Internet Protocol (IP) rétegére épül. Segítségével két vagy több számítógép képes biztonságos módon tartani egymással a kapcsolatot (innen ered a neve). A &os; IPsec hálózati protokollkészlete a KAME implementációjára épül, mely egyaránt támogatja az IPv4 és IPv6 protokollcsaládokat. IPsec ESP IPsec AH Az IPsec két alprotokollból tevõdik össze: A hasznos adat biztonságos becsomagolása (Encapsulated Security Payload, ESP) során egy szimmetrikus kriptográfiai algoritmussal (mint például Blowfish, 3DES) titkosítjuk az IP-csomagok tartalmát, ezáltal megvédjük ezeket az illetéktelenektõl. A Hitelesítési fejléc (Authentication Header, AH) használatával megakadályozzuk, hogy az illetéktelenek meghamisítsák az IP csomagok fejlécét. Ezt úgy érjük el, hogy kiszámolunk egy kriptográfiai ellenõrzõ összeget és az IP-csomagok fejlécének mezõire egy biztonságos függvénnyel generálunk valamilyen ujjlenyomatot. Az ez után következõ kiegészítõ fejléc tartalmazza ezt az ujjlenyomatot, amellyel a csomag hitelesíthetõ. Az ESP és az AH az alkalmazástól függõen használható együtt vagy külön-külön. VPN virtuális magánhálózat VPN Az IPsec akár közvetlenül is használható két számítógép forgalmának titkosítására (ezt Szállítási módnak (Transport Mode) nevezik), vagy két alhálózat között építhetünk ki vele virtuális tunneleket, ami remekül alkalmas két vállalati hálózat kommunikációjának bebiztosítására (ez a Tunnel mód (Tunnel Mode)). Ez utóbbit egyszerûen csak Virtuális magánhálózatként (Virtual Private Network, VPN) emlegetik. A &os; IPsec alrendszerérõl az &man.ipsec.4; man oldalon találhatunk további információkat. A rendszermag IPsec támogatásának aktiválásához a következõ paramétereket kell beletennünk a konfigurációs állományba: a rendszermag beállításai IPSEC options IPSEC # IP biztonság device crypto a rendszermag beállításai IPSEC_DEBUG Ha szükségünk van a IPsec nyomkövetésére, a következõ beállítást is hozzátehetjük: options IPSEC_DEBUG # az IP biztonság nyomkövetése A probléma Semmilyen szabvány nem fogalmazza meg mi is számít VPN-nek. A virtuális magánhálózatok tucatnyi különbözõ technológiával valósíthatóak meg, de mindegyiknek megvan a maga erõssége és gyengesége. Ebben a szakaszban körvonalazunk egy ilyen helyzetet, valamint a benne felépített VPN megvalósításához alkalmazott stratégiákat. A forgatókönyv: adott egy otthoni és egy vállalati hálózat, amelyek külön-külön csatlakoznak az internetre, és <acronym>VPN</acronym> használatával ezeket egyetlen hálózatként szeretnénk használni VPN létrehozása Elõfeltételezéseink a következõek: legalább két hálózatunk van; magán belül mind a két hálózat IP-t használ; mind a két hálózat egy &os; átjárón keresztül csatlakozik az internethez; a hálózatok átjárói legalább egy publikus IP-címmel rendelkeznek; a hálózatok belsõ címei lehetnek publikus vagy privát IP-címek, nem számít. Fontos viszont, hogy ezek ne ütközzenek, vagyis ne használja egyszerre mind a kettõ a 192.168.1.x címtartományt. Tom Rhodes
trhodes@FreeBSD.org
 Írta: Az IPsec beállítása &os; alatt Kezdésképpen a Portgyûjteménybõl telepítenünk kell a security/ipsec-tools portot. Ez a programcsomag rengeteg olyan alkalmazást tartalmaz, amely segítségünkre lehet a beállítások elvégzése során. A következõ lépésben létre kell hoznunk két &man.gif.4; típusú pszeudoeszközt, melyeken keresztül a két hálózat között egy tunnel segítségével ki tudjuk építeni a szükséges kapcsolatot. Ehhez root felhasználóként futtassuk a következõ parancsokat (a belsõ és külsõ megnevezésû paramétereket cseréljük ki a valós belsõ és külsõ átjárók címeire): &prompt.root; ifconfig gif0 create &prompt.root; ifconfig gif0 belsõ1 belsõ2 &prompt.root; ifconfig gif0 tunnel külsõ1 külsõ2 Tekintsük például, hogy a vállalati LAN publikus IP-címe 172.16.5.4, valamint a privát IP-címe 10.246.38.1. Az otthoni LAN publikus IP-címe legyen most 192.168.1.12, valamint a belsõ privát IP-címe pedig 10.0.0.5. Elsõre ez talán még nem teljesen érthetõ, ezért az &man.ifconfig.8; parancs használatával is nézzük meg a példában szereplõ hálózatok konfigurációját: Az elsõ átjáró: gif0: flags=8051 mtu 1280 tunnel inet 172.16.5.4 --> 192.168.1.12 inet6 fe80::2e0::81ff:fe02:5881%gif0 prefixlen 64 scopeid 0x6 inet 10.246.38.1 --> 10.0.0.5 netmask 0xffffff00 A második átjáró: gif0: flags=8051 mtu 1280 tunnel inet 192.168.1.12 --> 172.16.5.4 inet 10.0.0.5 --> 10.246.38.1 netmask 0xffffff00 inet6 fe80::250:bfff:fe3a:c1f%gif0 prefixlen 64 scopeid 0x4 Miután elvégeztük az iménti beállításokat, a &man.ping.8; paranccsal már mind a két privát IP-tartománynak elérhetõnek kell lennie, ahogy azt az alábbi példa is érzékeltetni kívánja: otthoni-halo# ping 10.0.0.5 PING 10.0.0.5 (10.0.0.5): 56 data bytes 64 bytes from 10.0.0.5: icmp_seq=0 ttl=64 time=42.786 ms 64 bytes from 10.0.0.5: icmp_seq=1 ttl=64 time=19.255 ms 64 bytes from 10.0.0.5: icmp_seq=2 ttl=64 time=20.440 ms 64 bytes from 10.0.0.5: icmp_seq=3 ttl=64 time=21.036 ms --- 10.0.0.5 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 19.255/25.879/42.786/9.782 ms vallalati-halo# ping 10.246.38.1 PING 10.246.38.1 (10.246.38.1): 56 data bytes 64 bytes from 10.246.38.1: icmp_seq=0 ttl=64 time=28.106 ms 64 bytes from 10.246.38.1: icmp_seq=1 ttl=64 time=42.917 ms 64 bytes from 10.246.38.1: icmp_seq=2 ttl=64 time=127.525 ms 64 bytes from 10.246.38.1: icmp_seq=3 ttl=64 time=119.896 ms 64 bytes from 10.246.38.1: icmp_seq=4 ttl=64 time=154.524 ms --- 10.246.38.1 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 28.106/94.594/154.524/49.814 ms Az elvárásainknak megfelelõen tehát a privát címeken mind a két oldalnak képesnek kell lennie ICMP csomagokat küldenie és fogadnia. A következõ lépésben meg kell mondanunk az átjáróknak hogyan irányítsák a csomagokat a két hálózat közti forgalom megfelelõ áramlásához. Ezt az alábbi paranccsal elérhetjük el: &prompt.root; vallalati-halo# route add 10.0.0.0 10.0.0.5 255.255.255.0 &prompt.root; vallalati-halo# route add net 10.0.0.0: gateway 10.0.0.5 &prompt.root; otthoni-halo# route add 10.246.38.0 10.246.38.1 255.255.255.0 &prompt.root; otthoni-halo# route add host 10.246.38.0: gateway 10.246.38.1 Itt már a belsõ gépeket az átjárókról és az átjárók mögül egyaránt el tudjuk érni. A következõ példa alapján errõl könnyedén meg is tudunk gyõzõdni: vallalati-halo# ping 10.0.0.8 PING 10.0.0.8 (10.0.0.8): 56 data bytes 64 bytes from 10.0.0.8: icmp_seq=0 ttl=63 time=92.391 ms 64 bytes from 10.0.0.8: icmp_seq=1 ttl=63 time=21.870 ms 64 bytes from 10.0.0.8: icmp_seq=2 ttl=63 time=198.022 ms 64 bytes from 10.0.0.8: icmp_seq=3 ttl=63 time=22.241 ms 64 bytes from 10.0.0.8: icmp_seq=4 ttl=63 time=174.705 ms --- 10.0.0.8 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 21.870/101.846/198.022/74.001 ms otthoni-halo# ping 10.246.38.107 PING 10.246.38.1 (10.246.38.107): 56 data bytes 64 bytes from 10.246.38.107: icmp_seq=0 ttl=64 time=53.491 ms 64 bytes from 10.246.38.107: icmp_seq=1 ttl=64 time=23.395 ms 64 bytes from 10.246.38.107: icmp_seq=2 ttl=64 time=23.865 ms 64 bytes from 10.246.38.107: icmp_seq=3 ttl=64 time=21.145 ms 64 bytes from 10.246.38.107: icmp_seq=4 ttl=64 time=36.708 ms --- 10.246.38.107 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 21.145/31.721/53.491/12.179 ms A tunnelek beállítása volt igazából a könnyebb rész, egy biztonságos összeköttetés kialakítása azonban már valamivel komolyabb folyamatot rejt magában. A most következõ konfigurációban erre elõre ismert (vagyis pre-shared, PSK) RSA-kulcsokat fogunk használni. A konkrét IP-címektõl eltekintve az átjárókon a /usr/local/etc/racoon/racoon.conf állományok hasonlóan fognak kinézni, nagyjából valahogy így: path pre_shared_key "/usr/local/etc/racoon/psk.txt"; # az ismert kulcsot tartalmazó állomány helye log debug; # a naplózás részletességének beállítása: ha végeztünk a teszteléssel és a hibakereséssel, akkor állítsuk át a 'notify' értékre padding # ezeket ne nagyon változtassuk meg { maximum_length 20; randomize off; strict_check off; exclusive_tail off; } timer # idõzítési beállítások, állítsuk be igény szerint { counter 5; interval 20 sec; persend 1; # natt_keepalive 15 sec; phase1 30 sec; phase2 15 sec; } listen # cím [port], ahol a racoon majd válaszolni fog { isakmp 172.16.5.4 [500]; isakmp_natt 172.16.5.4 [4500]; } remote 192.168.1.12 [500] { exchange_mode main,aggressive; doi ipsec_doi; situation identity_only; my_identifier address 172.16.5.4; peers_identifier address 192.168.1.12; lifetime time 8 hour; passive off; proposal_check obey; # nat_traversal off; generate_policy off; proposal { encryption_algorithm blowfish; hash_algorithm md5; authentication_method pre_shared_key; lifetime time 30 sec; dh_group 1; } } sainfo (address 10.246.38.0/24 any address 10.0.0.0/24 any) # address $hálózat/$hálózati_maszk $típus address $hálózat/$hálózati_maszk $típus # (a $típus lehet "any" vagy "esp") { # a $hálózat a két összekapcsolni kívánt belsõ hálózat legyen pfs_group 1; lifetime time 36000 sec; encryption_algorithm blowfish,3des,des; authentication_algorithm hmac_md5,hmac_sha1; compression_algorithm deflate; } A példában szereplõ összes opció részletes kifejtése jóval meghaladná ezen leírás kereteit, ezért a bõvebb információkkal kapcsolatban inkább a racoon beállításaihoz tartozó man oldal elolvasását javasoljuk. A gépek közti hálózati forgalom titkosításához be kell még állítanunk egy SPD házirendet is, így a &os; és a racoon képes kódolni és dekódolni a csomagokat. Ezt a most következõ, a vállalati átjárón találhatóhoz hasonló egyszerû shell szkripttel tudjuk elvégezni. Ezt az állományt a rendszer indításakor fogjuk felhasználni, melyet /usr/local/etc/racoon/setkey.conf néven mentsünk el: flush; spdflush; # Az otthoni hálózati felé spdadd 10.246.38.0/24 10.0.0.0/24 any -P out ipsec esp/tunnel/172.16.5.4-192.168.1.12/use; spdadd 10.0.0.0/24 10.246.38.0/24 any -P in ipsec esp/tunnel/192.168.1.12-172.16.5.4/use; Ahogy ezzel megvagyunk, a racoon az egyes átjárókon a következõ paranccsal indítható el: &prompt.root; /usr/local/sbin/racoon -F -f /usr/local/etc/racoon/racoon.conf -l /var/log/racoon.log A parancs eredménye ennek megfelelõen nagyjából a következõ lesz: vallalati-halo# /usr/local/sbin/racoon -F -f /usr/local/etc/racoon/racoon.conf Foreground mode. 2006-01-30 01:35:47: INFO: begin Identity Protection mode. 2006-01-30 01:35:48: INFO: received Vendor ID: KAME/racoon 2006-01-30 01:35:55: INFO: received Vendor ID: KAME/racoon 2006-01-30 01:36:04: INFO: ISAKMP-SA established 72.16.5.4[500]-192.168.1.12[500] spi:623b9b3bd2492452:7deab82d54ff704a 2006-01-30 01:36:05: INFO: initiate new phase 2 negotiation: 72.16.5.4[0]192.168.1.12[0] 2006-01-30 01:36:09: INFO: IPsec-SA established: ESP/Tunnel 92.168.1.12[0]->172.16.5.4[0] spi=28496098(0x1b2d0e2) 2006-01-30 01:36:09: INFO: IPsec-SA established: ESP/Tunnel 172.16.5.4[0]->192.168.1.12[0] spi=47784998(0x2d92426) 2006-01-30 01:36:13: INFO: respond new phase 2 negotiation: 172.16.5.4[0]192.168.1.12[0] 2006-01-30 01:36:18: INFO: IPsec-SA established: ESP/Tunnel 192.168.1.12[0]->172.16.5.4[0] spi=124397467(0x76a279b) 2006-01-30 01:36:18: INFO: IPsec-SA established: ESP/Tunnel 172.16.5.4[0]->192.168.1.12[0] spi=175852902(0xa7b4d66) A tunnel megfelelõ mûködését úgy tudjuk ellenõrizni, ha átváltunk egy másik konzolra és a &man.tcpdump.1; program segítségével figyeljük a hálózati forgalmat. A példában szereplõ em0 interfészt természetesen ne felejtsük el kicserélni a megfelelõ eszköz nevére. &prompt.root; tcpdump -i em0 host 172.16.5.4 and dst 192.168.1.12 Ennek hatására az alábbiakhoz hasonló adatoknak kellene megjelennie a konzolon. Amennyiben nem ez történik, valamilyen hiba történt, ezért meg kell keresnünk azt a visszakapott adatok alapján. 01:47:32.021683 IP vallalatihalozat.com > 192.168.1.12.otthonihalozat.com: ESP(spi=0x02acbf9f,seq=0xa) 01:47:33.022442 IP vallalatihalozat.com > 192.168.1.12.otthonihalozat.com: ESP(spi=0x02acbf9f,seq=0xb) 01:47:34.024218 IP vallalatihalozat.com > 192.168.1.12.otthonihalozat.com: ESP(spi=0x02acbf9f,seq=0xc) Itt már mind a két hálózatnak elérhetõnek kell lennie és egyként kell látszódnia. A hálózatokat ezen felül még érdemes külön védeni egy tûzfallal is. Ilyenkor a csomagok két hálózati közti zavartalan oda-vissza vándorlásához további szabályokat kell még felvennünk a tûzfal szabályrendszerébe. A &man.ipfw.8; tûzfal esetén ez a következõ sorok hozzáadását jelenti a tûzfal konfigurációs állományához: ipfw add 00201 allow log esp from any to any ipfw add 00202 allow log ah from any to any ipfw add 00203 allow log ipencap from any to any ipfw add 00204 allow log udp from any 500 to any A szabályok számozását mindig az adott gép aktuális beállításainak megfelelõen kell módosítani. A &man.pf.4; és &man.ipf.8; felhasználók számára ehhez a következõ parancsot javasoljuk: pass in quick proto esp from any to any pass in quick proto ah from any to any pass in quick proto ipencap from any to any pass in quick proto udp from any port = 500 to any port = 500 pass in quick on gif0 from any to any pass out quick proto esp from any to any pass out quick proto ah from any to any pass out quick proto ipencap from any to any pass out quick proto udp from any port = 500 to any port = 500 pass out quick on gif0 from any to any Végezetül a következõ sor hozzáadásával engedélyezzük az /etc/rc.conf állományban a VPN indítását a rendszer indítása során: ipsec_enable="YES" ipsec_program="/usr/local/sbin/setkey" ipsec_file="/usr/local/etc/racoon/setkey.conf" # engedélyezzük az spd házirend beállítását a rendszer indításakor racoon_enable="yes" Chern Lee Írta: OpenSSH OpenSSH biztonság OpenSSH Az OpenSSH olyan hálózati kapcsolódási eszközök összessége, amivel biztonságos módon érhetünk el távoli számítógépeket. Az rlogin, rsh, rcp és a telnet direkt kiváltására használható. Emellett SSH-n keresztül TCP/IP kapcsolatok is biztonságosan bújtathatóak vagy küldhetõek tovább. Az OpenSSH-t az OpenBSD projekt tartja karban, és az SSH 1.2.12 verziójára épül hibajavításokkal és frissítésekkel egyetemben. Az SSH 1 és 2 protokollokkal egyaránt kompatibilis. Az <application>OpenSSH</application> használatának elõnyei A hétköznapi esetben, vagyis amikor a &man.telnet.1; vagy &man.rlogin.1; alkalmazásokat használjuk, az adatok titkosítatlan formában közlekednek a hálózaton. A szerver és a kliens közé bárhova becsatlakozó hálózati kíváncsiskodók így könnyedén el tudják lopni a felhasználói nevünket és jelszavunkat, vagy lényegében bármilyen adatot, ami az adott munkamenetben megfordul. Az OpenSSH ennek kivédésére kínál fel különféle hitelesítési és titkosítási eszközöket. Az sshd engedélyezése OpenSSH engedélyezés Az sshd a &os; telepítésekor jelentkezõ Standard lehetõségek egyike. Az sshd engedélyezését úgy tudjuk kideríteni, ha az rc.conf állományban megkeressük a következõ sort: sshd_enable="YES" Ez tölti be a rendszer indításakor az &man.sshd.8;-t, az OpenSSH démonát. Vagy az /etc/rc.d/sshd &man.rc.8; szkript segítségével is elindíthatjuk az OpenSSH-t: /etc/rc.d/sshd start Az SSH kliens OpenSSH kliens Az &man.ssh.1; segédprogram az &man.rlogin.1; programhoz hasonlóan mûködik. &prompt.root; ssh felhasználó@gép.hu Host key not found from the list of known hosts. Are you sure you want to continue connecting (yes/no)? yes Host 'gép.hu' added to the list of known hosts. felhasználó@gép.hu's password: ******* Az üzenetek fordítása: Nem találtam meg a gépet az ismert gépek között. Biztosan csatlakozni akarunk hozzá (igen/nem)? igen A 'gép.hu' felkerült az ismert gépek közé. Adja meg a felhasználó@gép.hu jelszavát: Bejelentkezés után minden ugyanolyan, mintha az rlogin vagy a telnet programokat használtuk volna. Az SSH egy kulcs segítségével próbálja azonosítani a számítógépeket, ezzel ellenõrzi a szerver hitelességét a kliensek csatlakozásakor. A felhasználónak ilyenkor elõször mindig yes választ kell adnia. A késõbbi bejelentkezési kísérletek pedig majd mindig az így kapott kulccsal történnek. Ha eltérne a kulcs, akkor az SSH kliens erre figyelmeztetni fog minket. A kulcsok a ~/.ssh/known_hosts vagy az SSH v2 protokoll esetén a ~/.ssh/known_hosts2 állományba kerülnek elmentésre. Alapértelmezés szerint az OpenSSH szerverek csak SSH v2 kapcsolatokat fogadnak el. Lehetõség szerint a kliens is ezt a változatot fogja használni, de ha nem sikerül, akkor megpróbálkozik a v1-el. A kliensnek a vagy opciók segítségével elõ is lehet írni, hogy az elsõ vagy a második változatot használja. A kliensben az elsõ változat támogatását csupán a régebbi verziók kompatibilitása miatt tartják karban. Biztonságos másolás OpenSSH biztonságos másolás scp Az &man.scp.1; parancs az &man.rcp.1; parancshoz hasonlóan mûködik: egyik géprõl másol a másikra, biztonságosan. &prompt.root; scp felhasználó@gép.hu:/COPYRIGHT COPYRIGHT felhasználó@gép.hu's password: ******* COPYRIGHT 100% |*****************************| 4735 00:00 &prompt.root; Mivel a kulcsot már ismerjük ehhez a távoli géphez (az elõbbi példából), ezért az &man.scp.1; használatakor már ezzel hitelesítünk. Az &man.scp.1; paraméterei hasonlóak a &man.cp.1; parancséhoz: elsõ helyen az állomány vagy állományok neveit adjuk meg, a másodikon pedig a célt. Mivel az állományokat a hálózaton SSH-n keresztül küldik át, ezért az állományok neveit formában kell megadni. Beállítások OpenSSH beállítások Az OpenSSH démon és kliens rendszerszintû konfigurációs állományai az /etc/ssh könyvtárban találhatóak. Az ssh_config tartalmazza a kliens beállításait, miközben az sshd_config tartalmazza a démonét. Emellett az rc.conf állományban megadható (ez alapból a /usr/sbin/sshd) és opciókkal további beállítási szinteket nyújtanak. ssh-keygen Jelszavak helyett az &man.ssh-keygen.1; programmal a felhasználók azonosítására DSA- vagy RSA-kulcsokat tudunk készíteni: &prompt.user; ssh-keygen -t dsa Generating public/private dsa key pair. Enter file in which to save the key (/home/felhasználó/.ssh/id_dsa): Created directory '/home/felhasználó/.ssh'. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/felhasználó/.ssh/id_dsa. Your public key has been saved in /home/felhasználó/.ssh/id_dsa.pub. The key fingerprint is: bb:48:db:f2:93:57:80:b6:aa:bc:f5:d5:ba:8f:79:17 felhasználó@gép.hu Az &man.ssh-keygen.1; ekkor a hitelesítésre létrehoz egy publikus és egy privát kulcsból álló párt. A privát kulcs a ~/.ssh/id_dsa vagy ~/.ssh/id_rsa állományba kerül, miközben a publikus kulcs a ~/.ssh/id_dsa.pub vagy ~/.ssh/id_rsa.pub lesz attól függõen, hogy DSA vagy RSA a kulcs típusa. A módszer mûködéséhez a publikus DSA- vagy RSA-kulcsot a távoli számítógép ~/.ssh/authorized_keys állományába kell bemásolni. Így tehát a távoli számítógépre jelszavak alkalmazása helyett SSH-kulccsal tudunk belépni. Ha az &man.ssh-keygen.1; parancsnak megadunk egy jelmondatot is, akkor a felhasználó a privát kulcsát csak ennek megadásával tudja használni. A hosszú jelmondatok állandó beirogatásától a szakaszban hamarosan bemutatásra került &man.ssh-agent.1; igyekszik megkímélni minket. A különbözõ opciók és állományok eltérhetnek a számítógépünkre telepített OpenSSH verziójától függõen. Ilyen esetben javasolt felkeresni az &man.ssh-keygen.1; man oldalát. Az ssh-agent és az ssh-add Az &man.ssh-agent.1; és &man.ssh-add.1; segédprogramokkal be tudjuk tölteni az SSH-kulcsokat a memóriába, amivel elkerülhetjük a jelmondat állandó begépelését. A hitelesítést az &man.ssh-agent.1; program kezeli a betöltött privát kulcsok alapján. Az &man.ssh-agent.1; használatával egy másik programot is elindhatunk, egy parancsértelmezõtõl kezdve egy ablakkezelõig szinte bármit. Az &man.ssh-agent.1; programot úgy tudjuk egy parancsértelmezõben használni, hogy elõször is elindítjuk vele az adott parancsértelmezõt. Ezután az &man.ssh-add.1; lefuttatásával hozzá kell adnunk egy identitást, annak jelmondatának megadásával. Miután ezeket megtettük, a felhasználó bármelyik olyan távoli gépre be tud jelentkezni, ahol a publikus kulcsát ismerik. Például: &prompt.user; ssh-agent csh &prompt.user; ssh-add Enter passphrase for /home/felhasználó/.ssh/id_dsa: Identity added: /home/felhasználó/.ssh/id_dsa (/home/felhasználó/.ssh/id_dsa) &prompt.user; Az &man.ssh-agent.1; programot X11-el úgy tudjuk használni, ha az ~/.xinitrc állományba tesszük bele. Ezzel az &man.ssh-agent.1; az összes X11-ben indított program számára rendelkezésre áll. Példának vegyük ezt az ~/.xinitrc állományt: exec ssh-agent startxfce4 Így az X11 indulásakor mindig elindul az &man.ssh-agent.1;, amely pedig elindítja az XFCE alkalmazást. Miután átírtuk a saját állományunkat, a rendszer életbeléptetéséhez indítsuk újra az X11-et, az &man.ssh-add.1; futtatásával pedig töltsük be az összes SSH-kulcsunkat. Tunnelezés SSH-val OpenSSH tunnelezés Az OpenSSH-val létre tudunk hozni egy tunnelt, amellyel egy másik protokoll adatait tudjuk titkosított módon becsomagolni. Az alábbi parancs arra utasítja az &man.ssh.1; programot, hogy hozzon létre egy tunnelt a telnet használatához: &prompt.user; ssh -2 -N -f -L 5023:localhost:23 felhasználó@izé.mizé.hu &prompt.user; Az ssh parancsnak a következõ kapcsolókat adtuk meg: Az ssh parancs a protokoll második változatát használja. (Ne adjuk meg, ha régi SSH szerverekkel dolgozunk.) Tunnel létrehozása. Ha nem adjuk meg, akkor az ssh egy hagyományos munkamenet felépítését kezdi meg. Az ssh a háttérben fusson. Egy helyi tunnel a helyiport:távoligép:távoliport felírásban. A távoli SSH szerver. Az SSH által létrehozott járatok úgy mûködnek, hogy létrehozunk egy csatlakozást a localhost (a helyi gép) megadott portján. Ezután minden olyan kapcsolatot, ami a helyi gép adott portjára érkezik, SSH-n keresztül átirányítunk a távoli gép portjára. Ebben a példában a helyi gép 5023 portját átirányítjuk a helyi gép 23 portjára. Mivel a 23 a telnet portja, ezért az így definiált SSH járattal egy biztonságos telnet munkamenetet hozunk létre. Ezen a módon tetszõleges nem biztonságos TCP protokollt, például SMTP-t, POP3-at, FTP-t stb. be tudunk csomagolni. Biztonságos tunnel létrehozása SSH-val SMTP-hez &prompt.user; ssh -2 -N -f -L 5025:localhost:25 felhasználó@levelezõ.szerver.hu felhasználó@levelezõ.szerver.hu's password: ***** &prompt.user; telnet localhost 5025 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 levelezõ.szerver.hu ESMTP Az &man.ssh-keygen.1; és további felhasználói hozzáférések alkalmazásával ezen a módon ki tudunk alakítani egy minden további problémától és zûrtõl mentes SSH tunnelezési környezetet. A jelszavak helyett kulcsokat használunk és minden tunnel külön felhasználóként is futtatható. Gyakorlati példák a tunnelek használatára Egy POP3 szerver biztonságos elérése Tegyük fel, hogy a munkahelyünkön van egy SSH szerver, amire kívülrõl lehet csatlakozni, illetve vele egy hálózatban van egy POP3 levelezõ szerver is. A munkahelyünk és az otthonunk között levõ hálózati útvonalat részben vagy teljesen nem tartjuk megbízhatónak. Ezért az e-mailjeinket valamilyen biztonságos módon szeretnénk elérni. Ezt úgy tudjuk megvalósítani, ha otthonról csatlakozunk a munkahelyen levõ SSH szerverre és ezen keresztül érjük a levelezõ szervert. &prompt.user; ssh -2 -N -f -L 2110:levél.gép.hu:110 felhasználó@ssh-szerver.gép.hu felhasználó@ssh-szerver.gép.hu's password: ****** Miután a tunnel létrejött és mûködõképes, állítsuk be a levelezõ kliensünkben, hogy a POP3 kéréseket a localhost 2110 portjára küldje. Innen pedig biztonságos módon megy tovább a levél.gép.hu címre. Egy szigorú tûzfal megkerülése Egyes hálózati adminisztrátorok túlságosan szigorú szabályokat adnak meg a tûzfalban, és nem csak a bejövõ kapcsolatokat szûrik, hanem a kimenõket is. A távoli gépekhez csak a 22 (SSH) és 80 (böngészés) portjaikon tudunk csatlakozni. Mi viszont szeretnénk más (nem egészen a munkánkkal kapcsolatos) szolgáltatásokat is elérni, például egy Ogg Vorbis szerverrõl zenét hallgatni. Ehhez a szerverhez viszont csak akkor tudnánk csatlakozni, ha a 22 vagy 80 portokon üzemelne. Ezt a problémát úgy oldhatjuk meg, ha felépítünk egy SSH kapcsolatot a hálózatunk tûzfalán kívül levõ számítógéppel és segítségével átbújunk az Ogg Vorbis szerverhez. &prompt.user; ssh -2 -N -f -L 8888:zene.gép.hu:8000 felhasználó@tûzfalazatlan-rendszer.gép.org felhasználó@tûzfalazatlan-rendszer.gép.org's password: ******* A zenelejátszó kliensüknek adjuk meg a localhost 8888 portját, amely pedig a tûzfal sikeres kijátszásával továbbítódik a zene.gép.hu 8000-res portjára. Az <varname>AllowUsers</varname> felhasználói beállítás Gyakran nem árt korlátozni a felhasználók bejelentkezését. Az AllowUsers erre tökéletesen megfelel. Például, ha csak 192.168.1.32 címrõl engedjük bejelentkezni a root felhasználót, akkor ehhez valami ilyesmit kell beírnunk az /etc/ssh/sshd_config állományba: AllowUsers root@192.168.1.32 Ezzel pedig csupán nevének megadásával engedélyezzük az admin felhasználó bejelentkezését (bárhonnan): AllowUsers admin Egy sorban több felhasználó is megadható, mint például: AllowUsers root@192.168.1.32 admin Ilyenkor ne felejtsük el megadni az összes bejelentkezésre (valamilyen formában) jogosult felhasználót megadni, máskülönben kizárjuk ezeket. Miután elvégeztük a szükséges változtatásokat az /etc/ssh/sshd_config állományban, utasítsuk az &man.sshd.8; démont a konfigurációs állományok újraolvasására: &prompt.root; /etc/rc.d/sshd reload Ajánlott olvasnivalók (angolul) OpenSSH &man.ssh.1; &man.scp.1; &man.ssh-keygen.1; &man.ssh-agent.1; &man.ssh-add.1; &man.ssh.config.5; &man.sshd.8; &man.sftp-server.8; &man.sshd.config.5; Tom Rhodes Írta: ACL Az állományrendszerek hozzáféréseit vezérlõ listák A &os; 5.0 és késõbbi változatai különbözõ fejlesztéseket hoztak az állományrendszerekben, például a pillanatképek készítése vagy a hozzáférés-vezérlési listák (Access Control List, ACL-ek) támogatása. A hozzáférés-vezérlési listák a szabványos &unix;-os engedély modellt bõvítik ki egy igen kompatibilis (&posix;.1e) módon. Használatával a rendszergazdák egy sokkal kifinomultabb biztonsági modellt tudhatnak a kezük ügyében. Az UFS állományrendszerek ACL támogatását úgy tudjuk engedélyezni, ha a rendszermagot az options UFS_ACL paraméterrel fordítjuk le. Amennyiben ezt nem fordítottuk bele, akkor az ACL támogatással rendelkezõ állományrendszerek csatlakoztatása során egy figyelmeztetést kapunk. Ez az opció a GENERIC rendszermag része. Az ACL az állományrendszeren engedélyezett kiterjesztett tulajdonságokra támaszkodik. Ezeket a kiterjesztett tulajdonságokat a következõ generációs &unix; állományrendszer, az UFS2 már alapból ismeri. UFS1 típusú állományrendszereken sokkal nagyobb a kiterjesztett tulajdonságok kezelésének költsége, mint az UFS2 esetében. Az UFS2 jóval nagyobb teljesítménnyel képes dolgozni a kiterjesztett tulajdonságokkal. Emiatt a hozzáférés-vezérlési listák használatához az UFS2 sokkal inkább ajánlott, mint az UFS1. Az ACL használatát a csatlakoztatáskor megadott beállítással engedélyezhetjük, amelyet érdemes felvennünk az /etc/fstab állományba. Ha a &man.tunefs.8; segédprogrammal az állományrendszer fejlécében levõ szuperblokk ACL kapcsolóját átírjuk, akkor ez a beállítás automatikussá tehetõ. A szuperblokk használata több okból is ajánlatos: A csatlakoztatáskor megadott ACL beállítás nem változtatható egy egyszerû újracsatlakoztatással (&man.mount.8; ), csak egy teljes leválasztással (&man.umount.8;) és egy friss csatlakoztatással (&man.mount.8;). Ennek értelmében az ACL-ek a rendszerindító állományrendszeren a rendszer indulása után nem engedélyezhetõek. Ám ez azt is jelenti, hogy egy már használatban levõ állományrendszer beállításai sem változtathatóak meg. Ha a kapcsolót a szuperblokkban állítjuk be, akkor az állományrendszert még akkor is ACL támogatással csatlakoztatja a rendszer, ha azt nem adtuk meg az fstab állományban vagy az eszközeink átrendezõdtek. Így az állományrendszereket még véletlenül sem tudjuk ACL használata nélkül csatlakoztatni, ami egyébként így komoly biztonsági problémákat okozhatna. Beállíthatjuk úgy is ACL kezelését, hogy egy friss csatlakoztatás nélkül is bekapcsolható legyen, azonban az ilyen állományrendszerek ACL nélküli csatlakoztatását nem ajánljuk senkinek, mivel ha egyszer már engedélyeztük a használatukat, majd kikapcsoljuk ezeket és végül a kiterjesztett tulajdonságok törlése nélkül újra engedélyezzük, akkor nagyon könnyen pórul járhatunk. Ha elkezdtük használni az ACL-eket egy állományrendszeren, akkor ne tiltsuk le ezeket, mert az így keletkezõ állományvédelem nem feltétlenül lesz kompatibilis a felhasználók által beállítottakkal, és az ACL újraengedélyezése a változásaik elõtti korábbi ACL engedélyeket fogja visszaállítani az állományokra, aminek hatása kiszámíthatatlan. A hozzáférés-vezérlési listákat használó állományrendszerek esetén egy + (plusz) jellel ábrázolják a kiterjesztett engedélyeket. Például: drwx------ 2 robert robert 512 Dec 27 11:54 private drwxrwx---+ 2 robert robert 512 Dec 23 10:57 könyvtár1 drwxrwx---+ 2 robert robert 512 Dec 22 10:20 könyvtár2 drwxrwx---+ 2 robert robert 512 Dec 27 11:57 könyvtár3 drwxr-xr-x 2 robert robert 512 Nov 10 11:54 public_html Láthatjuk, hogy a könyvtár1, könyvtár2 és könyvtár3 könyvtárakhoz tartoznak ACL típusú engedélyek, míg a public_html könyvtárhoz nem. Az <acronym>ACL</acronym>-ek használata Az állományrendszerben található ACL engedélyeket a &man.getfacl.1; segédprogrammal nézhetjük meg. Például a próba állomány ACL engedélyeit a következõ paranccsal tudjuk megnézni: &prompt.user; getfacl próba #file:próba #owner:1001 #group:1001 user::rw- group::r-- other::r-- Egy állomány ACL engedélyeit a &man.setfacl.1; segédprogrammal tudjuk megváltoztatni. Figyeljük meg: &prompt.user; setfacl -k próba A opció törli az összes ACL alapú engedélyt egy állományról vagy állományrendszerrõl. Ennél viszont sokkal hasznosabb a opció használata, mivel az meghagyja az ACL mûködéséhez szükséges alapvetõ mezõket. &prompt.user; setfacl -m u:trhodes:rwx,group:web:r--,o::--- próba Ebben a fenti parancsban a opciót pedig arra használtuk, hogy módosítsuk az alapértelmezett ACL bejegyzéseket. Mivel az ezt megelõzõ parancsban teljesen töröltük még az elõredefiniált bejegyzéseket is, ez a parancs a megadott paraméterekkel kiegészítve ezeket vissza fogja állítani. Ügyeljünk arra, hogy ha olyan felhasználót vagy csoportot adunk meg, ami nem létezik a rendszerben, akkor a szabvány kimenetre egy Invalid argument hibaüzenetet kapunk. Tom Rhodes Írta: Portaudit A külsõ programok biztonsági problémáinak figyelése Az utóbbi években a biztonsági kérdésekkel foglalkozó világban számos fejlesztésre került sor a sebezhetõségi figyelmeztetések feldolgozásában. Manapság tulajdonképpen bármilyen operációs rendszer fokozott veszélynek teszik ki magát a külsõ programok telepítésével és használatával. A sebezhetõségekrõl beszámoló értesítések a biztonság egyik alapköve, azonban a &os; projekt nem tud ilyen jelentéseket kiadni a &os; alaprendszerén kívül minden egyes külsõ alkalmazáshoz. Azonban lehetõségünk van enyhíteni a külsõ csomagok sebezhetõségén és figyelmeztetni a rendszergazdákat az ismert biztonsági problémákra. A &os;-nek van egy Portaudit nevû segédprogramja, amit kizárólag erre a célra hoztak létre. A ports-mgmt/portaudit port 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.