diff --git a/hu_HU.ISO8859-2/books/handbook/cutting-edge/chapter.sgml b/hu_HU.ISO8859-2/books/handbook/cutting-edge/chapter.sgml index ce826fed69..8897736424 100644 --- a/hu_HU.ISO8859-2/books/handbook/cutting-edge/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/cutting-edge/chapter.sgml @@ -1,4595 +1,4605 @@ Jim Mock Átdolgozta, átrendezte és egyes részeit aktualizálta: Jordan Hubbard Eredetileg írta: Poul-Henning Kamp John Polstra Nik Clayton A &os; frissítése és frissen tartása Áttekintés A &os; a kiadások közt is állandó fejlõdésben van. Vannak felhasználók, akik a hivatalosan kiadott változatokat használják, és vannak, akik szeretik folyamatosan nyomonkövetni a fejlesztéseket. Emellett viszont a hivatalos kiadások esetében szükség lehet bizonyos biztonsági frissítések és kritikus javítások alkalmazására. Függetlenül a pillanatnyilag használt változattól, a &os; alaprendszerében megtalálható minden olyan eszköz, amellyel könnyedén frissíteni tudunk a különbözõ verziók között. Ebben a fejezetben segítünk dönteni a fejlesztõi változat és a kiadások használata között. Továbbá megismerhetjük a rendszer frissítéséhez használható alapvetõ eszközöket. A fejezet elolvasása során megismerjük: milyen segédprogramokkal tudjuk frissíteni az alaprendszert és a Portgyûjteményt; hogyan tartsuk naprakészen rendszerünket a freebsd-update, CVSup, CVS vagy CTM használatával; hogyan vessük össze a telepített rendszerünk aktuális állapotát egy ismert eredeti változattal; hogyan frissítsük a dokumentációt CVSup vagy dokumentációs portok segítségével. a két fejlesztõi ág, a &os.stable; és a &os.current; közti különbséget; a make buildworld (stb.) segítségével hogyan fordítsuk és telepítsük újra az egész alaprendszert. A fejezet elolvasásához ajánlott: a hálózati kapcsolatunk helyes beállítása (); a külsõ szoftverek telepítésének ismerete (). A fejezetben a &os; forrásainak frissítését a cvsup parancs segítségével fogjuk elvégezni. Ehhez telepítsük a net/cvsup-without-gui portot vagy csomagot, vagy ha már a &os; 6.2-RELEASE vagy késõbbi változatával rendelkezünk, akkor elegendõ csak az alaprendszer részeként elérhetõ &man.csup.1; programot használnunk. Tom Rhodes Írta: Colin Percival A megíráshoz felhasznált jegyzeteket készítette: A &os; frissítése frissítés és frissen tartás freebsd-update frissítés és frissen tartás A biztonsági javítások telepítése minden számítógépes szoftver, különösen az operációs rendszerek számára lényeges mozzanat. Nagyon hosszú ideig ez a &os; esetében nem volt könnyen megoldható: a javításokat közvetlenül a forráskódon kellett elvégezni, ezekbõl újrafordítani a rendszert, majd telepíteni. Ez a nehézség mostanra viszont már elhárult, mivel a &os; legfrissebb verziói már tartalmaznak egy freebsd-update nevû segédprogramot, amellyel mindez leegyszerûsödik. Ez a program két külön funkciót lát el. Elõször is, lehetõvé teszi, hogy a &os; alaprendszer újrafordítása és -telepítése nélkül javítsunk biztonsági és egyéb apró hibákat, valamint másodsorban támogatja a kisebb és nagyobb verziójú kiadások közti váltást. Ezek a bináris frissítések azonban csak a &os; biztonsági csapata által is felügyelt architektúrák és kiadások esetén érhetõek el. Emellett bizonyos lehetõségek használatához, például a &os; verziói közti átállás támogatásához a &man.freebsd-update.8; legújabb változata, valamint minimum a &os; 6.3 kiadása szükségeltetik. Ezért ne felejtsük el alaposan átolvasni a legújabb kiadásokról szóló bejelentéseket mielõtt frissítenénk rájuk, mivel ezzel kapcsolatban fontos információkat tartalmazhatnak. Az említett bejelentések a címen érhetõek el. Ha a crontab már hivatkozik a freebsd-update programra, akkor a most következõ mûvelet elkezdése elõtt tiltsuk le. A konfigurációs állományok Elõfordulhat, hogy változtatni akarunk valamin a frissítési folyamatban és ezért szeretnénk módosítani a programhoz tartozó konfigurációs állományt. Az opciók részletes ismertetéssel rendelkeznek, habár némelyiknél még további magyarázat kellhet: # Az alaprendszerben frissíteni kívánt komponensek Components src world kernel Ezzel a paraméterrel határozhatjuk meg, hogy a &os; mely részei kerüljenek frissítésre. Alapértelmezés szerint a program frissíti a forrásokat, a teljes alaprendszert és a rendszermagot. Komponensként a telepítésnél választható elemeket adhatjuk meg, például "world/games" hozzáadásakor a games kategória elemei is folyamatosan frissülni fognak. Az "src/bin" megadásakor pedig az src/bin könyvtár tartalma frissül. Ezt a beállítást a legjobb meghagyni az alapértelmezett értéken, mivel a további elemek megadásánál egyenként fel kell sorolni a frissítendõ komponenseket. Ha itt viszont kifelejtünk valamit, akkor könnyen megeshet, hogy a források és a binárisok verziója elcsúszik egymástól. # Az IgnorePaths beállítás után megadott szövegre illeszkedõ összes # bejegyzés frissítése kimarad IgnorePaths Ennél a beállításnál azokat a könyvtárakat kell megadnunk, amelyeket (és tartalmukat) ki szeretnénk hagyni a frissítés során. Ezek lehetnek például a /bin vagy az /sbin. Így meg tudjuk akadályozni, hogy freebsd-update esetleg felülírjon valamilyen helyi változtatást a rendszerünkben. # Az UpdateIfUnmodified beállítás után megadott elérési útvonalakon csak # a felhasználó által még nem módosított állományok fognak frissülni # (hacsak a módosításokat össze nem fésüljük, lásd lentebb) UpdateIfUnmodified /etc/ /var/ /root/ /.cshrc /.profile A megadott könyvtárakban csak azokat a konfigurációs állományokat fogja frissíteni, amelyeket nem változtattuk meg. Amennyiben bármelyikük eltér az eredetileg frissítendõ változattól, azt a program nem módosítja. Létezik egy másik hasonló beállítás, a KeepModifiedMetadata, amely hatására a freebsd-update az összefésülés során elmenti a változtatásokat. # A MergeChanges beállításnál szereplõ állományok helyi módosításait # automatikusan összefésüljük a &os; újabb verziójára frissítése közben MergeChanges /etc/ /var/named/etc/ Itt azokat a könyvtárakat adhatjuk meg, amelyekben a freebsd-update számára engedélyezzük a konfigurációs állományok új verziójának összefésülését a jelenlegi állapottal. Az összefésülés lényegében a &man.mergemaster.8; használatánál már megszokott módon, &man.diff.1; formátumban érkezõ módosítások sorozata alapján történik. Ekkor egy szövegszerkesztõ segítségével felügyelhetjük az összefésülés menetét vagy megállíthatjuk a freebsd-update futását. Ha kétségeink adódnak, akkor egyszerûen mentsük le az /etc könyvtárat és fogadjuk el mindegyik összefésülés eredményét. A mergemaster mûködésérõl a ad részletesebb tájékoztatást. # A &os; frissítésekor ezt a könyvtárat fogja a program használni a # letöltött módosítások és az egyéb ideiglenes állományok tárolására # WorkDir /var/db/freebsd-update Az itt megadott könyvtárba fognak kerülni az elvégzendõ módosítások és az egyéb ideiglenesen keletkezõ állományok. A verziók közti váltás során ebben a könyvtárban ajánlott legalább 1 GB szabad tárterületnek lennie. # A kiadások közti váltás során a Components beállításnál megadott # elemek kerüljenek csak frissítésre (StrictComponents yes), vagy a # program próbálja meg magától kitalálni, hogy milyen komponesek # *lehetnek* fenn a rendszeren és azokat frissítse (StrictComponents # no)? # StrictComponents no Ha ennél a beállításnál a yes értéket adjuk meg, akkor a freebsd-update feltételezni fogja, hogy a Components opciónál felsoroltunk minden frissítendõ komponenst és nem próbál meg mást is megváltoztatni. Ilyenkor tehát a freebsd-update tulajdonképpen egyedül csak a Components által meghatározott elemekhez tartozó állományokat fogja frissíteni. Biztonsági javítások A biztonsági javítások mindig egy távoli gépen tárolódnak, a következõ parancsok használatával tölthetõek le és telepíthetõek: &prompt.root; freebsd-update fetch &prompt.root; freebsd-update install Amennyiben a rendszermagot is érintik javítások, úgy a rendszert a mûvelet befejezõdésével újra kell indítanunk. Ha minden a megfelelõ módon történt, akkor a rendszerünk már tartalmazni fogja a korábban letöltött és telepített javításokat, és a freebsd-update akár beállítható egy naponta végrehajtandó &man.cron.8; feladatnak. Ehhez mindössze a következõ bejegyzést kell elhelyeznünk az /etc/crontab állományban: @daily root freebsd-update cron A bejegyzés szerint naponta egyszer le fog futni a freebsd-update. Ilyenkor, vagyis a paraméter megadásakor a freebsd-update csak ellenõrzi, hogy vannak-e telepítendõ frissítések. Ha talál, akkor automatikusan letölti ezeket a lemezre, de nem telepíti. Helyette levélben értesíti a root felhasználót, aki ezután bármikor manuálisan kérheti a telepítést. Probléma esetén az alábbi paranccsal megkérhetjük a freebsd-update programot a legutóbb telepített módosítások visszavonására: &prompt.root; freebsd-update rollback Ha ez a visszavonás a rendszermagra vagy annak moduljaira is vonatkozott, akkor a rendszert újra kell indítanunk a parancs futásának befejezõdésével. A &os; csak ilyenkor képes betölteni az új binárisokat betölteni a memóriába. A freebsd-update önmagától csak a GENERIC típusú rendszermagokat képes frissíteni. Ha saját rendszermagot használunk, akkor azt a rendszer többi komponensének frissítését követõen újra kell fordítanunk és telepítenünk. A freebsd-update azonban még akkor is érzekelni és frissíteni fogja a GENERIC rendszermagot (amennyiben az létezik), ha az éppen nem az aktuális(an futó) rendszermag. Mindig érdemes tartani egy másolatot a GENERIC rendszermagról a /boot/GENERIC könyvtárban. Rengeteg különbözõ probléma felderítésében tud segíteni, illetve ez a szakaszban leírt freebsd-update programmal végzett frissítéseknél is hasznos lehet. Hacsak nem változtatjuk meg az /etc/freebsd-update.conf állományt, a freebsd-update a rendszermag forrásait is frissíti a többivel együtt. A saját rendszermag újrafordítása és telepítése ezután a már a megszokott módon elvégezhetõ. A freebsd-update által terjesztett frissítések nem mindig érintik a rendszermagot. Ha a rendszermag forrásai nem változnak egy freebsd-update install parancs kiadása során, akkor nem kötelezõ újrafordítani a saját rendszermagot. A freebsd-update viszont mindig módosítani fogja a /usr/src/sys/conf/newvers.sh állományt. Itt az aktuális hibajavítás sorszáma szerepel (amelyet a -p (mint patch level elõtaggal kapcsolnak a rendszer verziójához, és a uname -r paranccsal lehet lekérdezni). Ennek megfelelõen tehát a saját rendszermag újrafordítása után, még ha semmi más nem is változott, a &man.uname.1; képes pontosan jelezni a rendszerhez készült hibajavítás sorszámát. Ez különösen fontos több rendszer karbantartása során, mivel így könnyen és gyorsan tájékozódhatunk azok naprakészségérõl. Váltás kisebb és nagyobb verziók között Verziók közti váltás során a külsõ alkalmazások mûkõdését akadályozó régi tárgykódok és függvénykönyvtárak törlõdni fognak. Ezért javasoljuk, hogy vagy töröljük le az összes portot és telepítsük újra, vagy az alaprendszer frissítése után hozzuk ezeket is naprakész állapotba a ports-mgmt/portupgrade segédprogram segítségével. Elõször minden bizonnyal szeretnék kipróbálni a frissítést, ezt a következõ paranccsal tehetjük meg: &prompt.root; portupgrade -af Ezzel gondoskodunk róla, hogy a minden a megfelelõen telepítõdjön újra. Ha a BATCH környezeti változót a yes értékre állítjuk, akkor a folyamat során megjelenõ összes kérdésre automatikusan a yes választ adjuk, ezáltal önállósítani tudjuk. Ha saját rendszermagot használunk, akkor ennél valamivel azért több feladatunk van. Szükségünk lesz a GENERIC rendszermagot egy példányára, amelyet másoljunk a /boot/GENERIC könyvtárba. Amennyiben nincs GENERIC típusú rendszermag a rendszerünkön, a következõ módok valamelyikén keresztül tudunk szerezni: Ha a saját rendszermagot még csak egyszer fordítottuk, akkor a /boot/kernel.old könyvtárban még megtalálható a GENERIC. Ezt nevezzük át egyszerûen /boot/GENERIC könyvtárra. Ha fizikailag hozzá tudunk férni az érintett géphez, akkor a GENERIC egy példányát akár CD-rõl is átmásolhatjuk. Helyezzük be a telepítõlemezt és adjuk ki a következõ parancsokat: &prompt.root; mount /cdrom &prompt.root; cd /cdrom/X.Y-RELEASE/kernels &prompt.root; ./install.sh GENERIC Itt a X.Y-RELEASE könyvtár nevében értelemszerûen helyettesítsük be az általunk használt változatot. A GENERIC rendszermag ekkor alapértelmezés szerint a /boot/GENERIC könyvtárba kerül. Ha az elõbbiek közül egyik sem lehetséges, akkor a GENERIC rendszermagot közvetlenül akár forrásból is lefordíthatjuk és telepíthetjük: &prompt.root; cd /usr/src &prompt.root; env DESTDIR=/boot/GENERIC make kernel &prompt.root; mv /boot/GENERIC/boot/kernel/* /boot/GENERIC &prompt.root; rm -rf /boot/GENERIC/boot A freebsd-update akkor fogja ezt GENERIC rendszermagként felismerni, ha a hozzátartozó konfigurációs állományt nem módosítjuk. Továbbá javasoljuk, hogy semmilyen speciális beállítást ne alkalmazzunk a fordítás során (érdemes üresen hagyni ehhez az /etc/make.conf állományt). Nem kötelezõ újraindítani a rendszert a GENERIC rendszermaggal. A freebsd-update képes frissíteni rendszerünket egy adott kiadásra. Például a következõ paraméterek megadásával válthatunk a &os; 6.4 használatára: &prompt.root; freebsd-update -r 6.4-RELEASE upgrade A parancs elindulása után nem sokkal, a váltáshoz szükséges információk összegyûjtéséhez a freebsd-update elemzi a konfigurációs állományában megadott beállításokat és a rendszer jelenleg használt verzióját. A képernyõn ekkor sorban megjelennek a program részérõl érzékelt és nem érzékelt komponensek. Mint például ahogy itt látható: Looking up update.FreeBSD.org mirrors... 1 mirrors found. Fetching metadata signature for 6.3-RELEASE from update1.FreeBSD.org... done. Fetching metadata index... done. Inspecting system... done. The following components of FreeBSD seem to be installed: kernel/smp src/base src/bin src/contrib src/crypto src/etc src/games src/gnu src/include src/krb5 src/lib src/libexec src/release src/rescue src/sbin src/secure src/share src/sys src/tools src/ubin src/usbin world/base world/info world/lib32 world/manpages The following components of FreeBSD do not seem to be installed: kernel/generic world/catpages world/dict world/doc world/games world/proflibs Does this look reasonable (y/n)? y Ekkor a freebsd-update megpróbálja letölteni a verziók közti váltáshoz szükséges összes állományt. Bizonyos esetekben kérdésekkel fordul a felhasználó felé arra vonatkozóan, hogy miket telepítsen fel vagy mit csináljon. A saját rendszermag használatakor az iménti lépés valamilyen ehhez hasonló figyelmeztetést fog adni: WARNING: This system is running a "SAJÁT RENDSZERMAG" kernel, which is not a kernel configuration distributed as part of FreeBSD 6.3-RELEASE. This kernel will not be updated: you MUST update the kernel manually before running "/usr/sbin/freebsd-update install" Ez a figyelmeztetés most nyugodtan figyelmen kívül hagyható. A folyamat során a frissített GENERIC rendszermagot fogjuk használni. A javítások letöltését követõen megkezdõdik a telepítésük. A váltás ezen lépése az adott gép aktuális terhelésétõl és sebességétõl függõen változó hosszúságú lehet. Ezután a konfigurációs állományok összefésülése zajlik le — itt általában a emberi felügyeletre is szükség van az állományok összefésülésének irányításához, amelynek folyamatosan láthatóak az eredményei. A meghiúsult vagy kihagyott összefésülések a teljes frissítési folyamat leállását vonják maguk után. Az /etc könyvtárban tárolt fontosabb állományokról, mint például a master.passwd vagy group javasolt elõzetesen biztonsági mentést készíteni és késõbb kézzel hozzájuk adni a változtatásaikat. A rendszerben ekkor még nem lesz jelen semmilyen konkrét változás, az összes említett javítás és összefésülés egy külön könyvtárban történik. A telepített javításokat és az összefésült konfigurációs állományokat a folyamat végén magának a felhasználónak kell véglegesíteni. A frissítési eljárás végén a következõ parancs kiadásával tudjuk ténylegesen érvényesíteni az eddig elvégzett módosításokat: &prompt.root; freebsd-update install Elõször mindig a rendszermag és a hozzátartozó modulok cserélõdnek le. Ahogy ez végrehajtódott, újra kell indítanunk a rendszert. Ha saját rendszermagot használunk, akkor a &man.nextboot.8; parancs segítségével állítsuk be a következõ rendszerindítás során betöltendõ rendszermagot a /boot/GENERIC könyvtárban levõre (ezt frissítettük): &prompt.root; nextboot -k GENERIC Mielõtt újraindítanánk a gépünket a GENERIC rendszermaggal, gyõzõdjünk meg róla, hogy szerepel benne minden olyan meghajtó, amely elengedhetetlen a rendszer hiánytalan indításához (és képes lesz újra csatlakozni a hálózathoz, ha éppen távolról adminisztráljuk). Ez különösen olyan esetben fontos, amikor a saját rendszermagunkban beépítetten szerepeltek bizonyos modulok. Ilyenkor a GENERIC rendszermag használatakor ezeket a /boot/loader.conf állományon keresztül töltethetjük be ideiglenesen. A frissítés befejezéséig érdemes viszont minden nem létfontosságú szolgáltatást leállítani, leválasztani lemezeket és hálózati megosztásokat stb. A rendszerünk most már újraindítható a frissített rendszermaggal: &prompt.root; shutdown -r now A rendszer sikeres újraindulása után ismét el kell indítanunk a freebsd-update programot, amely korábban már elmentette a frissítés állapotát, emiatt a legutóbbi pontról fog folytatódni, illetve törli az osztott könyvtárak és tárgykódok régebbi változatait. Innen az alábbi paranccsal léphetünk tovább: &prompt.root; freebsd-update install A függvénykönyvtárak verziói közti eltérések mértékétõl függõen elképzelhetõ, hogy a telepítés az említett három fázis helyett kettõben történik. Most pedig újra kell fordítanunk vagy telepítenünk az összes általunk korábban használt külsõ alkalmazást. Erre azért van szükségünk, mert bizonyos alkalmazások a verziók közti váltás során törölt programkönyvtáraktól függtek. Ennek automatizálásában a ports-mgmt/portupgrade lesz segítségünkre. Az alkalmazások frissítésének elindításához a következõ parancsokat használjuk: &prompt.root; portupgrade -f ruby &prompt.root; rm /var/db/pkg/pkgdb.db &prompt.root; portupgrade -f ruby18-bdb &prompt.root; rm /var/db/pkg/pkgdb.db /usr/ports/INDEX-*.db &prompt.root; portupgrade -af A parancsok lefutását követõen a freebsd-update utolsó hívásával zárjuk le a frissítést. Ezzel a paranccsal tudunk tehát pontot tenni a frissítési procedúra végére: &prompt.root; freebsd-update install Ha a GENERIC rendszermagot csak átmenetileg használtuk, akkor most már a megszokott módon fordíthatunk és telepíthetünk magunk egy saját rendszermagot. Indítsuk újra a rendszert a &os; frissített változatával. A folyamat ezzel véget ért. Rendszerek állapotainak összehasonlítása A freebsd-update ragyogóan felhasználható a &os; egy telepített változatának és egy általunk garantáltan megbízható példányának összevetésére. Ilyenkor a rendszerhez tartozó segédprogramokat, programkönyvtárakat és konfigurációs állományokat ellenõriztethetjük le. Az összehasonlítást ezzel a paranccsal kezdhetjük meg: &prompt.root; freebsd-update IDS >> eredmeny.idk Habár a parancs neve IDS (intrusion detection system), nem helyettesít semmilyen olyan behatolásjelzõ megoldást, mint amilyen például a security/snort. Mivel a freebsd-update adatokat tárol a lemezen, teljesen kézenfekvõ a hamisítás lehetõsége. Míg ennek eshetõsége adott mértékben visszaszorítható a kern.securelevel csökkentésével és a freebsd-update által használt adatok írásvédett állományrendszerre helyezésével, erre a problémára az ideális megoldást mégis egy teljes biztonságban tudható referencia rendszer jelentheti. Ennek tárolására alkalmas lehet például egy DVD vagy egy külsõ USB-egység. A parancs kiadása után megkezdõdik a rendszer vizsgálata, és az ellenõrzés során folyamatosan jelennek meg az átvizsgált állományok a hozzájuk tartozó ismert és kiszámított &man.sha256.1;-kódjukkal együtt. Mivel a képernyõn túlságosan gyorsan elúsznának az eredmények, ezért ezeket egy eredmeny.idk nevû állományba mentjük a késõbbi elemzésekhez. Az így keletkezõ állomány sorai ugyan meglehetõsen hosszúak, de szerencsére viszonylag könnyen értelmezhetõek. Például az adott kiadásban szereplõ állományoktól eltérõeket ezzel a paranccsal kérdezhetjük le: &prompt.root; cat eredmeny.idk | awk '{ print $1 }' | more /etc/master.passwd /etc/motd /etc/passwd /etc/pf.conf A példában most csak az elsõ néhány állományt hagytuk meg, gyakran tapasztalhatunk viszont ennél többet. Ezek közül bizonyos állományok értelemszerûen eltérnek, mint itt például az /etc/passwd, mert idõközben új felhasználókat adtunk a rendszerhez. Máskor egyéb állományok, például modulok nevei is felbukkanhatnak, mert tegyük fel, hogy a freebsd-update már frissítette ezeket. Ha ki szeretnénk zárni valamilyen állományokat vagy könyvtárakat az ellenõrzésbõl, egyszerûen csak soroljuk fel ezeket az /etc/freebsd-update.conf állományban megjelenõ IDSIgnorePaths beállításnál. A korábban tárgyaltaktól függetlenül ez a rendszer alkalmas bonyolultabb frissítési folyamatok kisegítésére is. Tom Rhodes Írta: Colin Percival A megíráshoz felhasznált jegyzeteket készítette: A Portgyûjtemény frissítése a Portsnap használatával frissítés és frissen tartás Portsnap frissítés és frissen tartás A &os; alaprendszer a Portgyûjtemény frissítéséhez is tartalmaz egy &man.portsnap.8; elnevezésû segédprogramot. Ez a program elindítása után csatlakozik egy távoli géphez, ellenõrzi a biztonsági kulcsát és letölti a portok legfrissebb változatait. A biztonsági kulcs feladata a frissítés közben letöltött állományok sértetlenségének szavatolása, ezzel gondoskodik róla, hogy az adatok átvitelük közben nem változtak meg. A Portgyûjtemény legújabb változatát így érhetjük el: &prompt.root; portsnap fetch Looking up portsnap.FreeBSD.org mirrors... 3 mirrors found. Fetching snapshot tag from portsnap1.FreeBSD.org... done. Fetching snapshot metadata... done. Updating from Wed Aug 6 18:00:22 EDT 2008 to Sat Aug 30 20:24:11 EDT 2008. Fetching 3 metadata patches.. done. Applying metadata patches... done. Fetching 3 metadata files... done. Fetching 90 patches.....10....20....30....40....50....60....70....80....90. done. Applying patches... done. Fetching 133 new ports or files... done. A példában látható, hogy a &man.portsnap.8; eltéréseket talált a helyi és a távoli rendszerekben fellelhetõ portok között, majd azokat ellenõrizte. Emellett az is megfigyelhetõ, hogy korábban már futtatuk a programot, mivel ha most indítottuk volna az elsõ alkalommal, akkor egyszerûen letöltötte volna a teljes Portgyûjteményt. Ahogy a &man.portsnap.8; sikeresen befejezi az imént kiadott fetch mûvelet végrehajtását, a helyi rendszeren már - telepítésre készen fog várakozni a + telepítésre készen fognak várakozni a Portgyûjtemény és az hozzátartozó ellenõrzött módosítások. A - tényleges telepítésüket a - következõképpen kérhetjük: + portsnap elsõ használatakor az + extract parancs + segítségével telepíthetjük a + frissített állományokat: &prompt.root; portsnap extract /usr/ports/.cvsignore /usr/ports/CHANGES /usr/ports/COPYRIGHT /usr/ports/GIDs /usr/ports/KNOBS /usr/ports/LEGAL /usr/ports/MOVED /usr/ports/Makefile /usr/ports/Mk/bsd.apache.mk /usr/ports/Mk/bsd.autotools.mk /usr/ports/Mk/bsd.cmake.mk ... + A portsnap fetch késõbbi + futtatásakor viszont már az update + parancsot kell használnunk: + + &prompt.root; portsnap update + Ezzel lezárult a portok frissítése, innentõl már az aktualizált Portgyûjtemény felhasználásával tetszõlegesen telepíthetõek vagy frissíthetõek az alkalmazások. - Az elõbb említett mûveleteket így - tudjuk egyetlen parancsba foglalni: + A fetch, extract vagy + update mûveletek egyetlen parancsba is + összefûzhetõek, ahogy ezt az alábbi + példában is láthatjuk: &prompt.root; portsnap fetch update A dokumentáció frissítése frissítés és frissen tartás dokumentáció frissítés és frissen tartás Az alaprendszer és a Portgyûjtemény mellett a dokumentáció is a &os; operációs rendszer szerves részét képezi. Noha a &os; dokumentációjának legfrissebb változata folyamatosan elérhetõ a &os; honlapjáról, egyes felhasználók ezt csak lassan vagy nem képesek folyamatosan elérni. Szerencsére egy helyi másolat megfelelõ karbantartásával az egyes kiadásokhoz tartozó dokumentáció is frissíthetõ. A dokumentáció frissítése CVSup használatával A &os; telepített dokumentációjának forrásai az alaprendszeréhez hasonlóan (lásd ) a CVSup segítségével frissíthetõek. Ebben a szakaszban megismerhetjük: hogyan telepítsük a dokumentáció elõállításához szükséges eszközöket, amelyekkel a forrásokból újra tudjuk generálni a &os; dokumentációját; hogyan töltsük le a dokumentáció forrását CVSup segítségével a /usr/doc könyvtárba; a dokumentáció elõállításához alkalmazott rendszer milyen beállításokkal rendelkezik, vagyis hogyan korlátozzuk a generálást bizonyos nyelvekre vagy formátumokra. A CVSup és a dokumentációs eszközök telepítése Viszonylag sokféle eszközre lesz szükségünk, ha a &os; dokumentációját a forrásokból akarjuk elõállítani. Ezek az segédprogramok nem részei a &os; alaprendszerének, mivel alapvetõen nagyon sok helyet foglalnak el, és leginkább olyan &os; felhasználók számára fontosak, akik folyamatosan a dokumentációval dolgoznak vagy gyakran frissítik azt forrásból. A feladathoz szükséges összes eszköz elérhetõ a Portgyûjteménybõl. Ebben a &os; Dokumentációs Projekt összeállított egy textproc/docproj nevû portot, amellyel az említett programok telepítését és frissítését igyekezték megkönnyíteni. Ha nem tartunk igényt a dokumentáció &postscript; vagy PDF változatára, akkor ehelyett inkább érdemes megfontolnunk a textproc/docproj-nojadetex port telepítését. Ebben a változatban a teTeX betûszedõ rendszer kivételével az összes segédprogram megtalálható. Mivel a teTeX önmagában nagyon sok segédeszköz telepítését jelenti, ezért amennyiben a PDF változat ténylegesen nem szükséges, érdemes eltekinteni a telepítésétõl. A CVSup telepítésével kapcsolatban pedig részletesebb információkat a CVSup használatával foglalkozó szakaszban olvashatunk. A dokumentáció forrásának frissítése A /usr/share/examples/cvsup/doc-supfile konfigurációs állomány segítségével a CVSup képes letölteni a dokumentáció forrásállományainak legfrissebb példányait. Itt a frissítést alapértelmezés szerint egy nem létezõ géptõl fogjuk kérni (mivel ezt kötelezõ kitölteni), azonban a &man.cvsup.1; programnak egy parancssori paraméter segítségével megadhatjuk melyik CVSup szerverrõl töltse le a forrásokat: &prompt.root; cvsup -h cvsup.FreeBSD.org -g -L 2 /usr/share/examples/cvsup/doc-supfile Ne felejtsük el a cvsup.FreeBSD.org helyére beírni a hozzánk földrajzilag legközelebb elhelyezkedõ CVSup szervert. Ezek teljes listáját a tartalmazza. Egy ideig eltarthat, amíg elõször letöltjük a forrásokat. Várjuk meg türelmesen, amíg befejezõdik a mûvelet. Késõbb a forrásokat ugyanezzel a paranccsal tudjuk frissíteni. A CVSup ugyanis mindig csak a legutóbbi futtatása óta történt változásokat tölti le, ezért késõbb már ez a lépés jelentõsen felgyorsulhat. A források letöltése után a dokumentációt például az ekkor keletkezett /usr/doc könyvtárban található Makefile használatával állíthatjuk elõ. Tehát miután az /etc/make.conf állományban beállítottuk a SUP_UPDATE, SUPHOST és DOCSUPFILE változókat, le tudjuk futtatni a következõ parancsot: &prompt.root; cd /usr/doc &prompt.root; make update Az előbb említett &man.make.1; változók jellemző értékei: SUP_UPDATE= yes SUPHOST?= cvsup.freebsd.org DOCSUPFILE?= /usr/share/examples/cvsup/doc-supfile Mivel a SUPHOST és a DOCSUPFILE változók értékét a ?= szimbólummal állítottuk be, lehetõségünk van a parancssorból ezeknek más értékeket adni. Az /etc/make.conf állományba általában így érdemes felvenni a változókat, így nem kell minden alkalommal módosítani, amikor valamilyen új beállítást akarunk kipróbálni. A dokumentáció különbözõ beállításai A &os; dokumentációjához tartozó, frissítést és elõállítást végzõ rendszernek van néhány olyan beállítása, amelyekkel kérhetjük kizárólag csak a dokumentáció egyes részeinek frissítését vagy bizonyos kimeneti formátumok használatát. Ezek vagy globálisan az /etc/make.conf állományban, vagy pedig a parancssorból, a &man.make.1; program paramétereként adhatóak meg. Ízelítõül néhány közülük: DOC_LANG Az elõállítandó és telepítendõ nyelvû dokumentáció felsorolása, tehát például csak az angol dokumentáció esetén ez en_US.ISO8859-1. FORMATS Az elõállítandó dokumentáció kimeneti formátumainak felsorolása. Itt pillanatnyilag értékként a html, html-split, txt, ps, pdf és rtf jelenhet meg. SUPHOST A frissítéshez használt CVSup szerver hálózati neve. DOCDIR Az elkészült dokumentáció telepítésének helye. Ez alapértelmezés szerint a /usr/share/doc. A folyamathoz kapcsolódóan további rendszerszintû &man.make.1; változókról a &man.make.conf.5; man oldalon olvashatunk. A &os; dokumentációjának elõállításáért felelõs rendszerben használható &man.make.1; további változók bemutatásával kapcsolatban pedig olvassuk el az A &os; Dokumentációs Projekt irányelvei kezdõknek címû könyvet. A &os; dokumentációjának telepítése forrásból Miután sikerült letöltenünk a /usr/doc könyvtárba a dokumentáció legfrissebb forrásait, készen állunk a rendszerünkön telepített példány frissítésére. A DOCLANG értékeként megadott nyelven készült dokumentációkat a következõ paranccsal tudjuk frissíteni: &prompt.root; cd /usr/doc &prompt.root; make install clean Ha a make.conf állományban korábban már megadtuk a DOCSUPFILE, SUPHOST és SUP_UPDATE változók értékeit, akkor a telepítés fázisa könnyedén össze is vonatható a források frissítésével: &prompt.root; cd /usr/doc &prompt.root; make update install clean Ha pedig csak bizonyos nyelvekhez tartozó dokumentációt szeretnénk frissíteni, akkor a &man.make.1; akár a /usr/doc könyvtáron belül az egyes nyelvekhez tartozó alkönyvtárakon belül is meghívható, például: &prompt.root; cd /usr/doc/en_US.ISO8859-1 &prompt.root; make update install clean A dokumentáció formátumát a FORMATS változó felhasználásával tudjuk meghatározni: &prompt.root; cd /usr/doc &prompt.root; make FORMATS='html html-split' install clean Marc Fonvieille A szóbanforgó megoldást fejlesztette: A dokumentációs portok használata frissítés és frissen tartás dokumentáció frissítés és frissen tartás Ez elõzõ szakaszban megmutattuk hogyan lehet a &os; dokumentációját a források felhasználásával frissíteni. A források használatával végzett frissítés azonban nem minden &os; rendszer esetében lehetséges vagy hatékony. Ha ugyanis a dokumentációs forrásból akarjuk elõállítani, viszonylag sok eszköz és segédprogram, az ún. dokumentációs eszközök használatával kell tisztában lennünk, valamint bizonyos mértékig ismernünk kell a CVS használatát, tudunk kell kikérni a legfrissebb változatot és elõállítatattnunk belõle a végleges változatot. Ezért ebben a szakaszban most szót ejtünk egy olyan módszerrõl, ahol a &os; dokumentációját a Portgyûjteményen keresztül tudjuk frissíteni, ezáltal: anélkül le tudjuk tölteni és telepíteni a dokumentáció adott pillanatban generált változatát, hogy a rendszerünkön bármi további teendõre szükség lenne (ennek köszönhetõen nem kell telepítenünk a dokumentációs eszközöket); letölthetjük a dokumentáció forrását és a Portgyûjtemény eszközeivel elõállíthatjuk belõle a megfelelõ változatot (ez a források beszerzésében és feldolgozásában segít valamelyest). A &os; dokumentáció frissítésének fentebb említett módjait támogatják tehát a dokumentációs portok, amelyeket a &a.doceng; havi rendszerességgel tart karban. Ezek a portok a &os; Portgyûjteményén belül a docs nevû virtuális kategóriában találhatóak meg. A dokumentációs portok fordítása és telepítése A dokumentáció könnyebb elõállításához a dokumentációs portok a Portgyûjtemény lehetõségeit veszik igénybe. Segítségükkel automatikussá teszik a dokumentáció forrásának letöltését, a &man.make.1; parancs meghívását a megfelelõ környezetben, beállításokkal és parancssori paraméterekkel. Rajtuk keresztül a dokumentáció eltávolítása ugyanolyan egyszerûen megtehetõ, mint akármelyik másik &os; port vagy csomag esetében. Továbbá, amikor a dokumentációs portokat a saját rendszerünkön fordítjuk, a dokumentációs eszközök függõségként automatikusan települni fognak. A dokumentációs portok a következõ módon szervezõdnek: Létezik egy ún. fõport, a misc/freebsd-doc-en, ahol az összes fontosabb állomány megtalálható. Ez lényegében a dokumentációs portok közös õse. Alapértelmezés szerint kizárólag csak az angol nyelvû dokumentációt állítja elõ. Létezik egy mindenes port, a misc/freebsd-doc-all, amely az összes elérhetõ nyelven és formátumban elõállítja a dokumentációt. Végezetül minden nyelvhez létezik egy-egy alport, ilyen például a magyar dokumentáció esetén a misc/freebsd-doc-hu port. Mindegyikük a fõporttól függ és az adott nyelvû dokumentációt telepítik. Az eddigi összefoglaltaknak megfelelõen a dokumentációs portokat forrásból a következõ paranccsal lehet telepíteni (root felhasználóként): &prompt.root; cd /usr/ports/misc/freebsd-doc-en &prompt.root; make install clean Ennek hatására elõáll és telepítõdik a /usr/local/share/doc/freebsd könyvtárba az angol nyelvû dokumentáció állományokra bontott HTML formátumban (hasonlóan a tartalmához). Gyakori beállítások A dokumentációs portok alapértelmezett viselkedése több különbözõ opció segítségével is befolyásolható. Ezek közül most összefoglalunk néhányat: WITH_HTML Minden dokumentum egyetlen HTML állományba kerüljön. A végeredmény ekkor az adott dokumentum típusának megfelelõen article.html (cikk) vagy book.html (könyv) néven keletkezik (képekkel együtt). WITH_PDF Minden dokumentum &adobe; Portable Document Format típusú állományban jön létre. Ezek az állományok a Ghostscript vagy más egyéb PDF nézegetõkkel nyithatóak meg. Ekkor a dokumentáció konkrét típusától függõen az állományok article.pdf (cikk) vagy book.pdf (könyv) néven állítódnak elõ. DOCBASE A dokumentáció telepítésének helye. Alapértelmezés szerint ez a /usr/local/share/doc/freebsd könyvtár. Ügyeljünk arra, hogy a telepítés alapértelmezett célkönyvtára eltér a CVSup módszerétõl. Ugyanis mivel ilyenkor egy portot telepítünk, a tartalma alapértelmezés szerint a /usr/local könyvtáron belülre kerül. Ez azonban a PREFIX változó átállításával tetszõleges megváltoztatható. Az elõbbieket most egy rövid példán keresztül összefoglaljuk. A következõ paranccsal tudjuk tehát a magyar nyelvû dokumentáció Portable Document Format változatát telepíteni: &prompt.root; cd /usr/ports/misc/freebsd-doc-hu &prompt.root; make -DWITH_PDF DOCBASE=share/doc/freebsd/hu install clean A dokumentációs csomagok használata A dokumentációs portok elõzõ szakaszban bemutatott forrásból telepítésével kapcsolatban már említettük, hogy szükséges hozzá a dokumentációs eszközök telepítése, valamint némi szabad tárterület. Ha a dokumentációs eszközök telepítéséhez nem elengedõek a rendelkezésre álló erõforrásaink vagy a források feldolgozása túlságosan sokat foglalna a rendszerünkön, akkor lehetõségünk van a dokumentációs portok elõre lefordított, csomagolt változatát használni. A &a.doceng; minden hónapban elõkészíti a &os; dokumentációs csomagok legfrissebb változatát. Az így karbantartott bináris csomagok azután tetszõlegesen használhatóak a szabványos csomagkezelõ eszközökkel, mint amilyen például a &man.pkg.add.1;, &man.pkg.delete.1; és így tovább. A bináris csomagok használata esetén a &os; dokumentációja az adott nyelvhez az összes elérhetõ formátumban telepítésre kerül. Például az alábbi paranccsal a magyar nyelvû dokumentációhoz tartozó legfrissebb bináris csomagot tudjuk telepíteni: &prompt.root; pkg_add -r hu-freebsd-doc A csomagok elnevezése eltér a hozzátartozó port nevétõl. Alakja a következõ: nyelv-freebsd-doc, ahol a nyelv az adott nyelv rövid kódja, vagyis a magyar esetén a hu, illetve az egyszerûsített kínai esetén a zh_ch. A dokumentációs portok frissítése Az elõzetesen telepített dokumentációs portok bármilyen portok frissítésére alkalmas eszközzel frissíthetõek. Például a telepített magyar nyelvû dokumentáció a ports-mgmt/portupgrade eszközön keresztül így frissíthetõ csomagok használatával: &prompt.root; portupgrade -PP hu-freebsd-doc Pav Lucistnik A szükséges információkat szolgáltatta: A Docsnap használata frissítés és frissen tartás Docsnap frissítés és frissen tartás A Docsnap a &os; dokumentációjának egy viszonylag gyors és könnyû frissítésére alkalmas &man.rsync.1; repository. Az ún. Docsnap szerver folyamatosan követi a dokumentáció forrásainak változásait, majd minden órában elõállítja a HTML változatukat. A Docsnap használatakor nincs szükségünk a textproc/docproj port telepítésére, mivel mindig csak a már elõállított dokumentációt frissítjük. A módszer használatához mindössze a net/rsync port vagy csomag telepítése szükségeltetik. Ezt a következõ paranccsal tudjuk elvégezni: &prompt.root; pkg_add -r rsync A Docsnap módszerét eredetileg a /usr/share/doc könyvtárban tárolt dokumentáció frissítésére fejlesztették ki, de a bemutatott példák tetszõleges könyvtárra alkalmazhatóak. Felhasználói könyvtárak esetén még rendszergazdai jogosultságokra sincs szükségünk a feladat elvégzéséhez. A dokumentáció így az alábbi paranccsal frissíthetõ: &prompt.root; rsync -rltvz docsnap.sk.FreeBSD.org::docsnap /usr/share/doc Jelenleg csak egyetlen Docsnap szerver érhetõ el, ez a fentebb is látható docsnap.sk.FreeBSD.org. Közvetlenül ne használjuk a paramétert, mert a make installworld parancs futása közben olyan elemeket is telepíthetett a /usr/share/doc könyvtárba, amelyek így törlõdnének. Helyette inkább így használjuk a parancsot: &prompt.root; rsync -rltvz --delete docsnap.sk.FreeBSD.org::docsnap/??_??\.\* /usr/share/doc Ha csak a dokumentáció egy részét akarjuk frissíteni, például csak az angol nyelvû változatát, akkor pedig ezt a parancsot használjuk: &prompt.root; rsync -rltvz docsnap.sk.FreeBSD.org::docsnap/en_US.ISO8859-1 /usr/share/doc ]]> A fejlesztõi ág követése -CURRENT -STABLE A &os;-nek két fejlesztési ága van: a &os;.current és a &os.stable;. Ebben a szakaszban mindegyikükrõl monduk pár szót, és megmutatjuk, miként lehet az adott ághoz igazítani a rendszerünk frissítését. Elõször a &os.current;, majd a &os.stable; változata kerül tárgyalásra. A &os; friss változatának használata Ahogy arról már az imént is szó esett, nem szabad elfelejtenünk, hogy a &os.current; a &os; fejlesztésének frontvonala. Emiatt a &os.current; használóinak szakmailag jólképzetteknek kell lenniük, és sosem szabad visszariadniuk a használat közben felmerülõ rendszerszintû problémák önálló megoldásától. Ha korábban még nem foglalkoztunk &os;-vel, kétszer is gondoljuk meg a telepítését! Mi a &os.current;? pillanatkép A &os.current; a &os; mögött álló legfrissebb forráskódot képviseli. Itt találkozhatunk különféle olyan fejlesztés alatt álló részekkel, kísérletezésekkel és átmeneti megoldásokkal, amelyek nem feltétlenül kerülnek bele a szoftver következõ hivatalos kiadásába. Noha a &os; fejlesztõi a &os.current; forráskódját naponta fordítják, adódhatnak olyan idõszakok, amikor a források mégsem használhatóak maradéktalanul. Az ilyen gondokat általában a lehetõ leggyorsabban igyekeznek megoldani, azonban attól függõen, hogy éppen a forráskód melyik verzióját sikerült kifogni, a &os.current; használata kész katasztrófa vagy akár a fejlõdésben igazi továbblépés is lehet. Kinek van szüksége a &os.current;-re? A &os.current; használata elsõsorban az alábbi 3 csoportot érinti: A &os; közösség azon tagjait, akik aktívan dolgoznak a forrásfa valamelyik részén, és mindazokat, akik számára a legfrissebb verzió használata feltétlen elvárás. A &os; közösség azon tagjait, akik aktívan tesztelnek, és a &os.current; kordában tartásához hajlandóak idõt áldozni a menet közben felbukkanó problémák megoldására. Vannak olyanok is, akik a &os; változásaival és fejlesztési irányával kapcsolatban kívánnak javaslatokat tenni, melyeket javítások és módosítások formájában tesznek közzé. Mindazokat, akik pusztán kíváncsiak a fejlesztésben zajló eseményekre, vagy hivatkozási szándékkal töltik le a legfrissebb forrásokat (például csak nézegetik, de nem futtatják). Az ilyen emberek esetenként megjegyzéseket fûznek a fejlesztéshez vagy kódot küldenek be. Mi <emphasis>nem</emphasis> a &os.current;? Az olyan kiadás elõtt álló funkciók kipróbálásának egyszerû módja, amelyekrõl hallottunk, hogy milyen remek újdonságokat hoznak és mi akarunk lenni az elsõk, akik ezt használni is fogják. Ne feledjük azonban, hogy amikor mindenki elõtt kezdünk el használni egy újítást, mi leszünk egyben az elsõk is, akik szembesülnek a benne rejlõ hibákkal. A gyors hibajavítások eszköze. A &os.current; szinte bármelyik változata pontosan ugyanakkora valószínûséggel hoz magával új hibákat, mint ahogy eltünteti a régieket. Akármilyen értelemben is hivatalosan támogatott. Képességeinktõl függõen õszintén igyekszünk a lehetõ legtöbbet megtenni a 3 törvényes &os.current; csoportba tartozó emberekért, azonban egyszerûen nincs idõnk komolyabb segítségnyújtást adni. Ez viszont nem azt jelenti, hogy komisz és fukar emberek vagyunk, akik utálnak segíteni a másiknak (de máskülönben nem tudna fejlõdni a &os;). Csupán a &os; fejlesztése közben fizikailag képtelenek vagyunk a naponta érkezõ ezernyi üzenetet rendre megválaszolni! A &os; elõremozdítása és a kísérleti stádiumban álló kóddal kapcsolatos kérdések megválaszolása közül a fejlesztõk általában az elsõt részesítik elõnyben. A &os.current; használata -CURRENT használata Iratkozzunk fel az &a.current.name; és &a.svn-src-head.name; listákra. Ez nem egyszerûen hasznos, hanem elengedhetetlen. Ha nem vagyunk a &a.current.name; listán, akkor nem fogjuk látni a rendszer aktuális állapotára vonatkozó megjegyzéseket, és így esetleg feleslegesen öljük az idõnket olyan problémák megoldásába, amelyeket mások már korábban megoldottak. Ami viszont ennél is fontosabb, hogy így elszalasztjuk a rendszerünk folyamatos életbentartására vonatkozó létfontosságú bejelentéseket. Az &a.svn-src-head.name; listán láthatjuk az a forráskód egyes változtatásaihoz tartozó naplóbejegyzéseket, a hozzájuk tartozó esetleges mellékhatások ismertetésével együtt. A listákra vagy a &a.mailman.lists.link; oldalon található többi lista valamelyikére úgy tudunk feliratkozni, ha rákattintunk a nevére. A további lépésekrõl ezt követõen itt kapunk értesítést. Amennyiben a teljes forrásfa változásai érdekelnek minket, javasoljuk az &a.svn-src-all.name; lista olvasását. A tükrözések egyikérõl töltsük le a &os; forrását. Erre két mód is kínálkozik: cvsup cron -CURRENT frissítés CVSuppal Használjuk a cvsup programot a /usr/share/examples/cvsup könyvtárban található standard-supfile állománnyal. Ez a leginkább ajánlott módszer, hiszen így csak egyszer kell letölteni az egész gyûjteményt, majd ezután már csak a változásokat. Sokan a cvsup parancsot a cron parancson keresztül adják ki, és ezzel mindig automatikusan frissítik a forrásaikat. A cvsup mûködését a fentebb említett minta supfile állomány megfelelõ módosításával tudjuk a saját környezetünkhöz igazítani. Az említett standard-supfile állomány eredetileg nem a &os.current;, hanem inkább a &os; biztonsági problémáit érintõ javítások követésére használatos. A &os.current; forrásainak eléréséhez a következõ sort kell kicserélnünk ebben az állományban: *default release=cvs tag=RELENG_X_Y Erre: *default release=cvs tag=. A tag paramétereként megadható egyéb címkékrõl a kézikönyv CVS címkék szakaszában olvashatunk. -CURRENT frissítés CTM-mel Használjuk a CTM alkalmazás nyújtotta lehetõségeket. Amennyiben nagyon rossz netkapcsolattal rendelkezünk (drága vagy csak levelezésre használható) a CTM megoldást jelenthet számunkra. Legyünk azonban tekintettel arra, hogy helyenként zûrös lehet a használata és néha hibás állományokat gyárt. Emiatt viszont csak ritkán használják, így elõfordulhat, hogy hosszabb ideig nem is mûködik. A 9600 bps vagy annál nagyobb sebességû kapcsolatok esetén ezért inkább a CVSup használatát javasoljuk. Ha nem csak böngészésre, hanem fordításra is szedjük a forrásokat, mindig töltsük le a &os.current; egészét, ne csak egyes részeit. Ez azzal magyarázandó, hogy a forráskód bizonyos részei más helyeken található részektõl is függenek, és ezért az önálló fordításuk szinte garantáltan gondot fog okozni. -CURRENT fordítása A &os.current; lefordítása elõtt figyelmesen olvassuk át a /usr/src könyvtárban található Makefile állományt. A frissítési folyamat részeként elõször mindenképpen érdemes telepíteni egy új rendszermagot és újrafordítani az alaprendszert. Olvassuk el a &a.current; üzeneteit és a /usr/src/UPDATING állományt, ahol megtalálhatjuk az ezzel kapcsolatos legújabb információkat, melyek egy-egy újabb kiadás közeledtével egyre fontosabbá válnak. Foglalkozzunk vele! Ha már a &os.current; változatát használjuk, ne legyünk restek véleményt formálni róla, különösen abban az esetben, ha továbbfejlesztésekrõl vagy hibákra van szó. Leginkább a forráskóddal együtt érkezõ javaslatoknak szoktak örülni a fejlesztõk! A &os; stabil változatának használata Mi a &os.stable;? -STABLE A &os.stable; az a fejlesztési ág, ahonnan az egyes kiadások származnak. Ebbe az ágba már más ütemben kerülnek a változások, mivel általánosan elfogadott, hogy ide a korábban már kipróbált módosítások vándorolnak át a &os.current; ágból. Ez azonban még mindig csak egy fejlesztési ág, ami arra utal, hogy a &os.stable; által adott pillanatban képviselt források nem feltétlenül felelnek meg bizonyos célokra. Ez csupán egy újabb fejlesztési nyomvonal, nem pedig a végfelhasználók kenyere. Kinek van szüksége a &os.stable;-re? Ha szeretnénk figyelemmel kísérni vagy valamilyen módon kiegészíteni a &os; fejlesztési folyamatát, különösen a &os; következõ nagyobb kiadását illetõen, akkor érdemes követnünk a &os.stable; forrásait. Habár a &os.stable; ágba is bekerülnek a biztonsági jellegû javítások, ettõl még nem kell feltétlenül ezt követnünk. A &os;-hez kiadott biztonsági figyelmeztetések mindig leírják, hogyan kell javítani a hibát az érintett kiadásokban Ez azért nem teljesen igaz. A régebbi &os; kiadásokat ugyan nem támogathatjuk a végtelenségig, de általában így is több évig foglalkozunk velük. A &os; régebbi kiadásaival kapcsolatos jelenleg érvényes biztonsági házirend részletes bemutatása a http://www.FreeBSD.org/security/ oldalon olvasható (angolul). , azonban az egész fejlesztési ágat felesleges csak biztonsági okból kifolyólag követni, mivel így olyan változások is kerülhetnek a rendszerbe, amire nincs szükségünk. Habár igyekszünk gondoskodni a &os.stable; ágban található források lefordíthatóságáról és mûködõképességérõl, nem minden esetben szavatolható. Ráadásul mivel a &os.stable; ágba kerülõ kódokat elõször a &os.current; ágban fejlesztik ki, és mivel a &os.stable; felhasználói többen vannak a &os.current; változaténál, ezért szinte elkerülhetetlen, hogy ilyenkor a &os.stable; változatban bizonyos hibák és szélsõséges esetek be ne következzenek, amelyek a &os.current; használata során még nem buktak ki. Ezért a &os.stable; ág vakon követését senkinek sem ajánljuk, és különösen fontos, hogy éles szervereken elõzetes kimerítõ tesztelések nélkül ne futassunk &os.stable; rendszert. Ha ehhez nem rendelkezünk elegendõ erõforrással, akkor egyszerûen használjuk a &os; legfrissebb kiadását, és az egyes kiadások között pedig bináris frissítéssel közlekedjünk. A &os.stable; használata -STABLE használata Iratkozzunk fel a &a.stable.name; listára. Ezen keresztül értesülhetünk a &os.stable; használata során felmerülõ fordítási függõségekrõl vagy más, külön figyelmet igénylõ problémákról. Gyakran ezen a levelezési listán elmélkednek a fejlesztõk a vitatott javításokról vagy frissítésekrõl, amibe a felhasználók is beleszólhatnak, ha a szóbanforgó változtatással kapcsolatban bármilyen problémájuk vagy ötletünk van. Iratkozzunk fel a követni kívánt ághoz tartozó SVN levelezési listára. Például ha a 7-STABLE ág változásait követjük, akkor az &a.svn-src-stable-7.name; listára érdemes feliratkoznunk. Ennek segítségével elolvashatjuk az egyes változtatásokhoz tartozó naplóbejegyzéseket, a rájuk vonatkozó esetleges mellékhatások ismertetésével együtt. Ezekre, valamint a &a.mailman.lists.link; címen elérhetõ listák valamelyikére úgy tudunk feliratkozni, ha a nevükre kattintunk. A további teendõk ezután itt jelennek meg. Amennyiben egy új rendszert akarunk telepíteni és a &os.stable; havonta készült pillanatképeit akarjuk rajta futtatni, akkor errõl bõvebb felvilágosítást a Pillanatképek honlapján találhatunk (angolul). Emellett a legfrissebb &os.stable; kiadást telepíthetjük a tükrözések valamelyikérõl is, majd innen a lentebb található utasítások szerint tudunk hozzáférni a &os.stable; forráskódjának legfrissebb változatához. Ha már fut a gépünkön a &os; egy korábbi kiadása, és ezt akarjuk forráson keresztül frissíteni, akkor ezt a &os; tükrözéseivel könnyedén megtehetjük. Két módon is: cvsup cron -STABLE frissítés CVSuppal Használjuk a cvsup programot a /usr/share/examples/cvsup könyvtárból származó stable-supfile állománnyal. Ez a leginkább ajánlott módszer, mivel így csak egyszer kell letölteni a teljes gyûjteményt, utána már csak a hozzátartozó változtatásokra van szükségünk. A cvsup parancsot sokan a cron segítségével futtatják, és ezzel automatikusan frissülnek a forrásainak. A cvsup mûködését környezetünkhöz az elõbb említett minta supfile megfelelõ módosításával tudjuk behangolni. -STABLE frissítés CTM-mel Használjuk a CTM programot. Ha nincs olcsó vagy gyors internetkapcsolatunk, akkor érdemes ezt a módszert választani. Alapvetõen azonban ha gyorsan szeretnénk hozzájutni a forrásokhoz és a sávszélesség nem meghatározó tényezõ, akkor helyette válasszuk a cvsup vagy az ftp használatát, és csak minden más esetben CTM-et. -STABLE fordítása Mielõtt lefordítanánk a &os.stable; változatát, figyelmesen olvassuk át a /usr/src könyvtárban levõ Makefile állományt. Az átállási folyamat részeként elõször minden bizonnyal telepítenünk kell egy új rendszermagot és újra kell fordítanunk az alaprendszert. A &a.stable; valamint a /usr/src/UPDATING elolvasásából értesülhetünk azokról az egyéb, gyakran nagyon fontos változásokról, melyek elengedhetetlenek lesznek a következõ kiadás használatához. A forrás szinkronizálása Az internet (vagy elektronikus levelek) használatán keresztül számos mód kínálkozik az &os; Projekthez tartozó források frissen tartásához egy adott, vagy éppen az összes területen attól függõen, hogy mik érdekelnek minket. Ehhez elsõsorban az Anonim CVS, CVSup és CTM szolgáltatásokat ajánljuk fel. Habár lehetséges csupán a forrásfa egyes részeit letölteni, a támogatott frissítési eljárás során azonban szükségünk lesz az egész fa szinkronizálására és a rendszerhez tartozó felhasználói programok (vagyis minden olyan program, amely a felhasználói térben fut, ilyeneket találhatunk többek közt a /bin és /sbin könyvtárakban) valamint rendszermag újrafordítására is. Ha csak a felhasználói programok forrásait, vagy csak a rendszermagot, esetleg csupán a forrásfa egyes részeit frissítjük, akkor az gondokat okozhat. Az itt elõforduló problémák fordítási hibáktól kezdve rendszerösszeomlásokon keresztül akár adatvesztésbe is torkollhatnak. CVS anonim Az Anonim CVS és a CVSup alkalmazások ún. lehúzással frissítik a forrásokat. A CVSup használatakor a felhasználó (vagy a cron szkript) meghívja a cvsup programot, amely az állományok aktualizálásához felveszi a kapcsolatot egy máshol megtalálható cvsupd szerverrel. Az így nyert frissítések az adott pillanatig visszemenõleg érkeznek meg, de csak akkor, ha igényeljük ezeket. A frissítést könnyedén le tudjuk szabályozni a számunkra érdekes egyes állományokra és könyvtárakra. A frissítéseket a szerver hozza létre menet közben annak megfelelõen, hogy milyen verziókkal rendelkezünk, és mihez akarunk szinkronizálni. Az Anonim CVS a CVSupnál valamivel egyszerûbb abban a tekintetben, hogy ez a CVS-nek egy olyan kiterjesztése, amely lehetõvé teszi a változtatások közvetlen lehúzását egy távoli CVS tárházból. Miközben a CVSup mindezt sokkal hatékonnyabb valósítja meg, addig az Anonim CVS jóval könnyebben használható. CTM Velük szemben a CTM nem hasonlítja össze interaktívan a saját és a központi szerveren tárolt forrásokat és nem is húzza át ezeket. Ehelyett egy olyan szkriptõl van szó, amely naponta többször megvizsgálja a központi CTM szerveren tárolt állományok a legutóbbi futtatás óta keletkezett változtatásait, majd az észlelt módosulásokat betömöríti, felcímkézi egy sorozatszámmal és (nyomtatható ASCII formátumban) elõkészíti ezeket az e-mailen keresztüli küldésre. Az így létrehozott CTM delták megérkezésük után a &man.ctm.rmail.1; segédprogrammal kerülnek feldolgozásra, amely magától visszaalakítja, ellenõrzi és alkalmazza a változtatásokat a forrásfa felhasználó birtokában levõ másolatára. Ez a megoldás hatékonyabb a CVSup használatánál, mert kisebb terhelést jelent a szerverek számára, hiszen a frissítéshez nem a lehúzást, hanem a küldést alkalmazzák. Természetesen minden említett eljárásnak megvannak a maga kompromisszumai. Ha véletlenül kitöröljük a forrásfánk egyes részeit, a CVSup képes ezt észrevenni és helyreállítani a sérült részeket. A CTM ezzel szemben ezt nem végzi el, szóval ha (biztonsági mentés nélkül) letöröljük a forrásainkat, akkor az egész szinkronizálást az elejérõl kell kezdenünk (pontosabban a legfrissebb CVS-es alapdeltától) és a CTM-mel újraépíteni az egészet, esetleg a Anonim CVS-sel letörölni a hibás adatokat és újraszinkronizálni. Az alaprendszer újrafordítása az alaprendszer újrafordítása Miután sikerült a helyi forrásfánkat a &os; egy nekünk szimpatikus (&os.stable;, &os.current; és így tovább) változatához igazítanunk, elérkezett az idõ, hogy a segítségével újrafordítsuk az egész rendszert. Készítsünk biztonsági mentést Nem tudjuk eléggé nyomatékosítani, hogy mielõtt nekikezdenénk, készítsünk egy biztonsági mentést a rendszerünkrõl. Míg az alaprendszer újrafordítása nem túlságosan bonyolult feladat (egészen addig, amíg a megadott utasításokat követjük), saját magunk vagy mások hibájából fakadóan kialakulhatnak olyan helyzetek, amikor a rendszer nem lesz képes elindulni. Mindenképpen gyõzödjünk meg róla, hogy tisztességesen elvégeztük a mentést és akad a kezünk ügyében egy javításra felhasználható rendszerindító floppy vagy CD. Valószínûleg soha nem lesz ténylegesen szükségünk rájuk, azonban jobb félni, mint megijedni! Iratkozzunk fel a megfelelõ levelezési listákra levelezési lista A &os.stable; és &os.current; ágak természetüknél fogva fejlesztés alatt állnak. A &os; fejlesztését is emberek végzik, ezért elõfordulhatnak benne tévedések. Ezek a tévedések gyakran csak ártalmatlan apróságok, amelyek hatására kapunk például egy ismeretlen diagnosztikai hibát. De ezzel szemben létrejöhetnek pusztító erejû hibák is, amelyek hatására a rendszerünk nem lesz képes elindulni, károsodnak az állományrendszerek (vagy még rosszabb). Ha ilyen történik, akkor egy felszólítást (egy heads up témájú üzenetet) küldenek az érintett változatokhoz tartozó listákra, amelyben igyekeznek kifejteni a probléma természetét és a rendszerre mért hatását. Miután minden rendbejött, a probléma megoldásáról is küldenek egy értesítést. Ha a &a.stable; vagy a &a.current; olvasása nélkül próbáljuk meg használni a &os.stable; és &os.current; verziókat, akkor csak magunknak keressük a bajt. Ne használjuk a <command>make world</command> parancsot Rengeteg régebben készült dokumentáció erre a feladatra a make world parancs kiadását javasolja. Ennek használatával azonban átlépünk olyan fontos lépéseket, amelyek valójában csak akkor lennének kihagyhatóak, ha pontosan tudjuk mit csinálunk. Ezért az esetek döntõ többségében nem a make world használatára van szükségünk, hanem a most bemutatandó eljárásra. A rendszer frissítése dióhéjban A frissítés megkezdése elõtt érdemes elolvasnunk a /usr/src/UPDATING állományt, ahol a letöltött források használatához elvégzendõ elõzetes intézkedésekrõl kaphatunk hírt. Ezután kövessük az alábbiakban körvonalazott módszer egyes lépéseit. Ezek a lépések feltételezik, hogy egy korábbi &os; verziót használunk, tehát a fordító, a rendszermag, az alaprendszer és a konfigurációs állományok valamelyik régebbi változatát. Alaprendszer alatt, amelyet sokszor csak a world néven hivatkozunk, a rendszer számára alapvetõ fontosságú binárisokat, programkönyvtárakat és programfejlesztéshez szükséges egyéb állományokat értjük. Maga a fordítóprogram is része ennek, azonban tartalmaz néhány speciális megszorítást. Mindezek mellett továbbá feltételezzük, hogy elõzetesen már valamilyen módon letöltöttük a friss forrásokat. Ha rendszerünkön ezt még nem tettük volna meg, akkor a segítségével tájékozódhatunk részletesen arról, hogyan tölthetjük le a legfrissebb verziót. A rendszer forráskódon keresztüli frissítése egy kicsivel körülményesebb, mint amennyire elsõre látszik. A &os; fejlesztõk az évek során fontosnak találták, hogy a folyamatosan felszínre bukkanó, elkerülhetetlen függõségek tükrében meglehetõsen drámai módon megváltoztassák az erre javasolt módszert. Ezért a szakasz további részében a pillanatnyilag javasolt frissítési megoldás nyomán fogunk haladni. A sikeres frissítések során az alábbi akadályokkal kell mindenképpen szembenéznünk: A fordító régebbi változata nem feltétlenül lesz képes lefordítani az új rendszermagot. (Illetve a régebbi fordítóprogramok tartalmazhatnak hibákat.) Ezért az új rendszermagot már a fordító új változatával kell elõállítanunk. Ebbõl következik, hogy az új rendszermag elkészítéséhez elõször a fordítóprogram újabb változatát kell lefordítanunk. Ez viszont nem feltétlenül jelenti azt, hogy az új rendszermag fordítása elõtt az új fordítóprogramot telepítenünk is kellene. Az új alaprendszer esetenként bizonyos új funkciókat igényelhet a rendszermagtól. Ezért a frissebb alaprendszer telepítése elõtt telepítenünk kell a frissebb rendszermagot. Ez az elõbb említett két akadály képzi az okát a következõ bekezdésekben bemutatott buildworld, buildkernel, installkernel, installworld sorozatnak. Természetesen léteznek további egyéb indokok is, amiért még érdemes az itt leírtak szerint frissíteni a rendszerünket. Ezek közül most vegyünk néhány kevésbé nyilvánvalóbbat: A régebbi alaprendszer nem minden esetben fog problémamentesen együttmûködni az új rendszermaggal, ezért az alaprendszer újabb változatát szinte azonnal az új rendszermagot követõen kell telepítenünk. Vannak olyan konfigurációs változtatások, amelyeket még az új alaprendszer telepítése elõtt el kell végeznünk, a többi viszont veszélyes lehet a korábbi alaprendszerre. Ezért a konfigurációs állományokat általában két külön lépésben kell frissíteni. A frissítés során nagyrészt csak állományok cserélõdnek el és újabbak érkeznek, a korábbiak nem törlõdnek. Ez bizonyos esetekben azonban gondokat okozhat. Ennek eredményeképpen a frissítés során idõnként elõfordulhat, hogy magunknak kell manuálisan némely megadott állományokat törölnünk. Elképzelhetõ, hogy ezt a jövõben még majd automatizálni fogják. Ezek a megfontolások vezettek tehát az ismertetendõ eljárás kialakításához. Ettõl függetlenül adódhatnak olyan helyzetek, amikor további lépéseket is be kell iktatnunk, viszont az itt bemutatott folyamat egy ideje már viszonylag elfogadottnak tekinthetõ: make buildworld Elõször lefordítja az új fordítóprogramot és néhány hozzátartozó eszközt, majd ennek felhasználásával elkészíti az alaprendszer többi részét. Az eredmény a /usr/obj könyvtárban keletkezik. make buildkernel Eltérõen a &man.config.8; és &man.make.1; programok korábban javasolt alkalmazásától, ezzel a paranccsal már a /usr/obj könyvtárban létrehozott új fordítót használjuk. Ez védelmet nyújt a fordító és rendszermag változatai közti eltérésekbõl fakadó problémák ellen. make installkernel Telepíti a lemezre az új rendszermagot és a hozzátartozó modulokat, ezáltal lehetõvé válik a frissített rendszermag betöltése. Átváltás egyfelhasználós módba. Egyfelhasználós módban a minimálisra csökkenthetjük a futó szoftverek frissítésébõl adódó bonyodalmakat. Ezzel együtt minimálissá válik a régi alaprendszer és az új rendszermag eltéréseibõl eredõ problémák elõfordulása is. mergemaster -p Az új alaprendszer telepítéséhez elvégzi a konfigurációs állományok részérõl szükséges frissítéseket. Például felvesz még nem létezõ csoportokat vagy felhasználókat. Ez gyakran elengedhetetlennek bizonyulhat, mivel ha a rendszer legutóbbi frissítése óta újabb csoportok vagy felhasználók kerültek be az alaprendszerbe, a installworld csak akkor tud hibamentesen lefutni, ha ezek már a futásakor is elérhetõek. make installworld Átmásolja a /usr/obj könyvtárból a korábban elkészített új alaprendszert. Lefutása után már mind az új rendszermag és az új alaprendszer a megfelelõ helyén található. mergemaster Feldolgozzuk a korábbi fázisból fennmaradó konfigurációs állományok frissítését, mivel most már elérhetõ az új alaprendszer. A rendszer újraindítása. Az új rendszermag és az új konfigurációs állományokkal futó alaprendszer használatához teljesen újra kell indítanunk a számítógépünket. Ha a &os; ugyanazon fejlesztési ágán belül frissítjük a rendszerünket, például a 7.0 kiadásról a 7.1 kiadásra, akkor értelemszerûen nem kell az iménti eljárás minden lépését szorosan követni, hiszen nagyon valószínûtlen, hogy komoly eltérések lennének a fordítóprogram, a rendszermag, az alaprendszer és a konfigurációs állományok között. Ilyenkor akár nyugodtan kiadhatjuk a make world parancsot, majd kérhetjük a rendszermag fordítását és telepítését. A fejlesztési ágak közti váltás során azonban könnyen érhetnek minket meglepetések, ha nem a megadottak szerint járunk el. Egyes váltásokhoz (például 4.X és 5.0 között) további lépések megtétele is szükséges lehet (például adott állományok törlése vagy átnevezése még az installworld elõtt). Ilyenkor mindig figyelmesen olvassuk át a /usr/src/UPDATING állományt, különös tekintettel a végére, mivel gyakran ott adják meg a konkrét verzióváltáshoz szükséges teendõket. A szakaszban összefoglalt lépések egyfajta evolúciós folyamat eredményei, melynek során a fejlesztõk felismerték, hogy nem tökéletesen kivédeni az összes frissítéssel járó problémát. A javasolt eljárás remélhetõleg viszont még sokáig érvényes marad. A &os; 3.X vagy annál is korábbi változatok frissítése még ennél is több ügyességet kíván. Ha ilyen verziót akarunk frissíteni, akkor feltétlenül olvassuk el az UPDATING állományt! Röviden tehát a &os; forráskódon keresztüli frissítését így foglalhatjuk össze: &prompt.root; cd /usr/src &prompt.root; make buildworld &prompt.root; make buildkernel &prompt.root; make installkernel &prompt.root; shutdown -r now Néhány ritka esetben a buildworld lépés elõtt szükségünk lehet a mergemaster -p parancs lefuttatására is. Errõl az UPDATING állományból tudakozódhatunk. Általában azonban nyugodt szívvel kihagyhatjuk ezt a lépést, kivéve, ha nem egy vagy több fõbb &os; változatot átívelõ frissítést végzünk. Miután az installkernel sikeresen befejezte a munkáját, indítsuk újra a számítógépet egyfelhasználós módban (a betöltõ parancssorában adjuk ki boot -s parancsot). Itt futtassuk a következõket: &prompt.root; adjkerntz -i &prompt.root; mount -a -t ufs &prompt.root; mergemaster -p &prompt.root; cd /usr/src &prompt.root; make installworld &prompt.root; mergemaster &prompt.root; reboot Olvassuk el a magyarázatokat Az iménti leírt folyamat csupán rövid összefoglalás, amivel némi gyorstalpalást igyekeztünk adni. Az egyes lépések megértéséhez azonban javasolt átolvasni a most következõ szakaszokat is, különösen abban az esetben, ha saját rendszermagot akarunk használni. Nézzük meg a <filename>/usr/src/UPDATING</filename> állományt Mielõtt bármihez is nekifognánk, keressük meg a /usr/src/UPDATING (vagy hasonló, a forráskód másolatunk tényleges helyétõl függõ) állományt. Ebben adják hírül az esetlegesen felmerülõ problémákra vonatkozó fontosabb információkat, vagy határozzák meg az egyes lefuttatandó parancsok pontos sorrendjét. Amennyiben az UPDATING ellentmondana az itt olvasottaknak, az UPDATING tartalma a mérvadó. A korábban tárgyaltak szerint az UPDATING elolvasása nem helyettesíti a megfelelõ levelezési listák figyelemmel kísérését. Ez a két elvárás nem kizárja, hanem kiegészíti egymást. Ellenõrizzük az <filename>/etc/make.conf</filename> állományt make.conf Vizsgáljuk át a /usr/share/examples/etc/make.conf és az /etc/make.conf állományokat. Az elõbbi tartalmaz néhány alapértelmezett beállítást – ezek javarészét megjegyzésbe rakták. Ha használni akarjuk a rendszer lefordítása során, tegyük bele ezeket az /etc/make.conf állományba. Ne felejtsük el azonban, hogy minden, amit megadunk az /etc/make.conf állományba, a make minden egyes elindításakor felhasználásra kerül. Éppen ezért olyanokat érdemes itt beállítani, amik az egész rendszerünket érintik. A legtöbb felhasználó számára az /etc/make.conf állományhoz a /usr/share/examples/etc/make.conf állományban található CFLAGS és NO_PROFILE sorokra lesz szüksége, melyeket kivehetünk a megjegyzésbõl. A többi definíció (COPTFLAGS, NOPORTDOCS és így tovább) használatáról már mindenki maga dönt. Frissítsük az <filename>/etc</filename> tartalmát Az /etc könyvtár tartalmazza a rendszer beállításaival kapcsolatos információk jelentõs részét, valamint a rendszer indítása során lefutó szkripteket. Egyes szkriptek a &os; verzióiról verzióira változnak. Némely konfigurációs állományok a rendszer hétköznapi mûködésében is szerepet játszanak. Ilyen például az /etc/group. Alkalmanként a make installworld parancs futása során igényt tart adott nevû felhasználókra és csoportokra. A frissítéskor azonban ezek a felhasználók vagy csoportok nem feltétlenül állnak rendelkezésre, ami gondokat okozhat. Ezért bizonyos esetekben a make buildworld elõzetesen ellenõrzi az igényelt felhasználók és csoportok meglétét. Erre például szolgálhat a smmsp felhasználó esete. Nélküle a felhasználók nem tudták telepíteni az új rendszert, mert hiányában az &man.mtree.8; nem volt képes létrehozni a /var/spool/clientmqueue könyvtárat. Ezt úgy lehetett megoldani, hogy még az alaprendszer lefordítása (a buildworld) elõtt meg kellett hívni a &man.mergemaster.8; parancsot a paraméterrel. Így csak azokat az állományokat fogja összehasonlítani, amelyek feltétlenül szükségesek a buildworld vagy az installworld sikeres mûködéséhez. Amennyiben a mergemaster egy olyan verziójával rendelkezünk, amely nem ismeri a paramétert, akkor az elsõ indításakor használjuk a forrásfában található újabb verzióját: &prompt.root; cd /usr/src/usr.sbin/mergemaster &prompt.root; ./mergemaster.sh -p Ha különösen paranoiásak vagyunk, akkor a csoport törlése vagy átnevezése elõtt az alábbi paranccsal ellenõrizni tudjuk az általa birtokolt állományokat: &prompt.root; find / -group GID -print Ez megmutatja GID (mely megadható numerikus vagy név formájában is) jelzésû csoporthoz tartozó összes állományt a rendszerünkben. Váltsunk egyfelhasználós módba egyfelhasználós mód A rendszert egyfelhasználós módban érdemes lefordítani. A nyilvánvalóan érezhetõ gyorsaság elõnyei mellett azért is jobban járunk, mert az új rendszer telepítése során számos rendszerszintû állomány is módosításra kerül, beleértve a szabványos rendszerszintû binárisokat, függvénykönyvtárakat, include állományokat és így tovább. Ha üzemelõ rendszeren végezzük el mindezen változtatásokat (különösen amikor rajtunk kívül még további felhasználók is tartózkodnak a rendszerben), az csak a bajt hozza ránk. többfelhasználós mód Másik lehetõség gyanánt a rendszert magát lefordíthatjuk többfelhasználós módban is, majd ezután csak a telepítést hajtjuk végre egyfelhasználós üzemmódban. Ha eszerint cselekszünk, egyszerûen várjunk addig, amíg az összes fordítás be nem fejezõdik, és az egyfelhasználósra váltást halasszuk a installkernel vagy installworld idejére. Egy mûködõ rendszerben rendszeradminisztrátorként az alábbi parancs kiadásával válthatunk át egyfelhasználós módba: &prompt.root; shutdown now Ezt elérhetjük úgy is, ha újraindítjuk a rendszert és a rendszer indításakor a single user pontot választjuk a menübõl. Ekkor a rendszer egyfelhasználós módban indul el. Miután ez megtörtént, adjuk ki a következõ parancsokat: &prompt.root; fsck -p &prompt.root; mount -u / &prompt.root; mount -a -t ufs &prompt.root; swapon -a Ezekkel a parancsokkal elõször ellenõrizzük az állományrendszereket, ezután újracsatlakoztatjuk a / állományrendszert írható módban, csatlakoztatjuk az /etc/fstab állományban megadott összes többi UFS típusú állományrendszert, majd bekapcsoljuk a lapozóállomány használatát. Ha a gépünk óráját nem a greenwich-i, hanem a helyi idõ szerint állítottuk be (ez akkor áll fenn, ha a &man.date.1; parancs nem a helyes idõt és idõzónát jelzi ki), akkor még erre is szükségünk lehet: &prompt.root; adjkerntz -i Ezzel a helyi idõzóna beállításait tudjuk jól beállítani — nélküle késõbb még gondjaink akadhatnak. Töröljük a <filename>/usr/obj</filename> könyvtárat A rendszer egyes részei fordításuk során a /usr/obj könyvtáron belülre kerülnek (alapértelmezés szerint). Az itt található könyvtárak a /usr/src könyvtárszerkezetét követik. Ha mindenestõl töröljük ezt a könyvtárat, akkor növeli tudjuk a make buildworld folyamat sebességét és megmenekülünk néhány függõségekkel kapcsolatos fejfájástól is. Egyes /usr/obj könyvtáron belüli állományoknál szerepelhet a megváltoztathatatlan (immutable) állományjelzõ (lásd &man.chflags.1;), amelyet a mûvelet elvégzéséhez elõször el kell távolítanunk. &prompt.root; cd /usr/obj &prompt.root; chflags -R noschg * &prompt.root; rm -rf * Fordítsuk újra az alaprendszert A kimenet elmentése Jól járunk azzal, ha a &man.make.1; futásának kimenetét elmentjük egy állományba, mivel így a hibák esetén lesz egy másolatunk a hibaüzenetrõl. Ha konkrétan nekünk nem is feltétlenül segít megtalálni a hiba tényleges okát, mások viszont többet tudnak róla mondani, ha beküldjük ezt a &os; egyik levelezési listájára. Ezt egyébként a legegyszerûbben a &man.script.1; parancs segítségével oldhatjuk meg, amelynek paraméteréül azt az állományt kell megadni, ahova menteni akarjuk a kimenetet. Ezt közvetlenül a rendszer újrafordítása elõtt kell kiadnunk, majd miután megállt, a exit paranccsal kiléphetünk belõle. &prompt.root; script /var/tmp/mw.out Script started, output file is /var/tmp/mw.out &prompt.root; make TARGET … fordít, fordít, fordít … &prompt.root; exit Script done, … Ilyenkor soha ne a /tmp könyvtárba mentsük a kimenetet, mert ennek a tartalma a következõ indítás során magától törlõdik. Sokkal jobban tesszük, ha a /var/tmp könyvtárba (ahogy tettük azt az elõbbi példában is) vagy a root felhasználó könyvtárába mentünk. Az alaprendszer fordítása A /usr/src könyvtárban kell állnunk: &prompt.root; cd /usr/src (kivéve természetesen, ha máshol van a forráskód, akkor abba a könyvtárba menjünk). make Az alaprendszert a &man.make.1; paranccsal fordíthatjuk újra. Ez a Makefile nevû állományból olvassa be a &os; programjainak újrafordítását leíró utasításokat, a fordításuk sorrendjét és így tovább. A begépelendõ paranccsor általános alakja tehát a következõképpen néz ki: &prompt.root; make -x -DVÁLTOZÓ target A fenti példában a egy olyan a paraméter, amelyet a &man.make.1; programnak adunk át. A &man.make.1; man oldalán megtalálhatjuk az összes neki átadható ilyen beállítást. A alakú paraméterek közvetlenül a Makefile állománynak adnak át olyan változókat, amelyek segítségével vezérelhetõ a viselkedése. Ezek ugyanazok a változók, mint amelyek az /etc/make.conf állományban is szerepelnek, és itt a beállításuk egy másik módját kapjuk. Így a &prompt.root; make -DNO_PROFILE target paranccsal is megadhatjuk, hogy ne profilozott függkönyvtárak jöjjenek létre, ami pontosan megfelel a NO_PROFILE= true # Avoid compiling profiled libraries sornak az /etc/make.conf állományban. A target árulja el a &man.make.1; programnak, hogy mi a teendõje. Minden egyes Makefile különbözõ targeteket definiál, és a kiválasztott target mondja meg, pontosan mi is fog történni. Egyes targetek ugyan megjelennek a Makefile állományban, azonban nem feltétlenül hivatkozhatunk rájuk közvetlenül. Ehelyett csupán arra valók, hogy a fordítás folyamatának lépéseit felbontsák még kisebb allépésekre. A legtöbb esetben azonban semmilyen paramétert nem kell átadnunk a &man.make.1; parancsnak, ezért a teljes formája így fog kinézni: &prompt.root; make target ahol a target az egyik fordítási lehetõséget képviseli. Az elsõ ilyen targetnek mindig a buildworld-nek kell lennie. Ahogy a neve is mutatja, a buildworld lefordítja az összes forrást a /usr/obj könyvtárba, majd a installworld mint másik target, telepíti az így létrehozott elemeket a számítógépre. A targetek szétválasztása két okból is elõnyös. Elõször is lehetõvé teszi, hogy az új rendszert biztonságban lefordíthassuk, miközben az a jelenleg futó rendszert nem zavarja. A rendszer tehát képes saját magát újrafordítani. Emiatt a buildworld target akár többfelhasználós módban is mindenféle nem kívánatos hatás nélkül használható. Ennek ellenére azonban továbbra is azt javasoljuk, hogy a installworld részt egyfelhasználós módban futtassuk le. Másodrészt ezzel lehetõségünk nyílik NFS állományrendszer alkalmazásával több számítógépre is telepíteni hálózaton keresztül. Ha például három frissítendõ számítógépünk van, az A, B és C, akkor az A gépen elõször adjuk ki a make buildworld, majd a make installworld parancsot. A B és C gépek ezután NFS segítségével csatlakoztatják az A /usr/src és /usr/obj könyvtárait, amelyet követõen a make installworld paranccsal telepíteni tudjuk a fordítás eredményét a B és C gépekre. Noha a world mint target még mindig létezik, használata határozottan ellenjavalt. A &prompt.root; make buildworld parancs kiadásakor a make parancsnak megadható egy paraméter is, amellyel párhuzamosíthatjuk a folyamat egyes részeit. Ez általában többprocesszoros számítógépeken nyer értelmet, azonban mivel a fordítás folyamatának haladását inkább az állománymûveletek mintsem a processzor sebessége korlátozza, ezért alkalmazható akár egyprocesszoros gépeken is. Tehát egy átlagos egyprocesszoros gépen így adható ki a parancs: &prompt.root; make -j4 buildworld Ennek hatására &man.make.1; egyszerre 4 szálon igyekszik mûködni. A levelezési listákra beküldött tapasztalati jellegû bizonyítékok azt igazolják, hogy általában ez a beállítás adja a legjobb teljesítményt. Ha többprocesszoros géppel rendelkezünk és rajta SMP támogatású rendszermagot indítottunk el, akkor érdemes 6 és 10 közötti értékekkel kísérleteznünk. Idõigény az alaprendszer újrafordítása idõigény Számos tényezõ befolyásolja a fordítás tényleges idõbeli hosszát, de a &os.stable; fa lefordítása mindenféle trükkök és rövidítések nélkül a legtöbb számítógépen olyan egy vagy két órára taksálható. A &os.current; fához ennél valamivel több idõre lesz szükségünk. Fordítsunk és telepítsünk egy új rendszermagot rendszermagot fordítása Az újdonsült rendszerünket csak akkor tudjuk igazán kihasználni, ha egy új rendszermagot is készítünk hozzá. Ez gyakorlati szinten tulajdonképpen elvárás, mivel könnyen elõfordulhat, hogy bizonyos memóriabeli adatszerkezetek felépítése megváltozott, ezért némely programok, mint például a &man.ps.1; és &man.top.1;, egészen addig nem lesznek képesek normálisan mûködni, amíg a rendszer és a rendszermag forráskódja nem illeszkedik egymáshoz. Ennek legegyszerûbb és egyben legbiztonságosabb módja, ha a GENERIC beállításai alapján gyártunk és telepítünk egy rendszermagot. Még ha a GENERIC beállításai nem is tartalmazzák a rendszerünkben fellelhetõ összes eszközt, minden megtalálható bennük ahhoz, hogy a rendszert sikeresen elindíthassuk legalább egyfelhasználós módban. Ez mellesleg remek próbája az új rendszer életképességének. Miután elindítottuk a rendszert a GENERIC típusú rendszermaggal és meggyõzõdtünk róla, hogy a rendszer tényleg mûködõképes, a megszokott rendszermagunk konfigurációs állománya alapján nyugodtan elkészíthetjük ezután azt is. &os; alatt egy új rendszermag építése elõtt fontos újrafordítani az alaprendszert. Ha saját beállításaink szerint akarunk rendszermagot létrehozni és már van is ehhez egy konfigurációs állományunk, akkor erre használhatjuk a KERNCONF=SAJÁTMAG paramétert is, valahogy így: &prompt.root; cd /usr/src &prompt.root; make buildkernel KERNCONF=SAJÁTMAG &prompt.root; make installkernel KERNCONF=SAJÁTMAG Hozzátennénk, hogy ha a kern.securelevel rendszerváltozó értékét 1 felé állítottuk és a rendszermag állományának beállítottunk noschg vagy hozzá hasonló állományjelzõt, akkor az installkernel lefuttatásához mindenképpen egyfelhasználós módba kell váltanunk. Minden más esetben további bonyodalmak nélkül ki tudjuk adni az említett parancsokat. A kern.securelevel részleteirõl az &man.init.8; oldalán, a különbözõ állományjelzõkrõl pedig a &man.chflags.1; oldalán olvashatunk. Indítsuk újra a rendszert egyfelhasználós módban egyfelhasználós mód Az új rendszermag mûködésének leteszteléséhez indítsuk újra a rendszert egyfelhasználós módban. Ennek pontos részleteit lásd . Telepítsük az új rendszer binárisait Ha a &os; friss változatát nemrég fordítottuk le a make buildworld paranccsal, akkor utána az installworld segítségével tudjuk telepíteni a keletkezett programokat. Tehát írjuk be ezeket: &prompt.root; cd /usr/src &prompt.root; make installworld Amennyiben a paranccsorban a make buildworld használata során adtunk meg változókat, akkor ne felejtsük el ugyanazokat megadni a make installworld kiadása során sem. Ez viszont a többi paraméterre már nem feltétlenül érvényes. Például a beállítást szigorúan tilos az installworld targettel együtt használni. Ennek megfelelõen tehát ha korábban ezt írtuk be: &prompt.root; make -DNO_PROFILE buildworld akkor így telepítsünk: &prompt.root; make -DNO_PROFILE installworld Máskülönben azokat a profilozott függvénykönyvtárakat próbáljuk meg telepíteni, amelyek a make buildworld futása során nem jöttek létre. Frissítsük a <command>make installworld</command> által kihagyott állományokat Az alaprendszer újrafordítása nem regisztrálja az új vagy megváltozott állományokat bizonyos könyvtárakban (különösen értendõ ez az /etc, /var és /usr esetén). Az ilyen állományokat a legegyszerûbben a &man.mergemaster.8; használatával tarthatjuk karban, de igény szerint akár kézzel is elvégezhetjük a szükséges aktualizálásokat. Függetlenül attól, hogy mit is választunk, mindenképpen készítsünk biztonsági mentést az /etc könyvtárról arra az esetre, ha bármilyen szörnyûség történne. Tom Rhodes Írta: A <command>mergemaster</command> mergemaster A &man.mergemaster.8; segédprogram valójában egy Bourne szkript, amely segít az /etc könyvtárunkban és a forrásfában levõ /usr/src/etc könyvtárban elhelyezkedõ konfigurációs állományok közti eltérések megállapításában. Ezt a módszert ajánljuk arra, hogy összevessük a konfigurációs állományainkat a forrásfában található változataikkal. A használatának megkezdéséhez egyszerûen írjuk be, hogy mergemaster, majd várjunk egy kicsit, amíg a mergemaster létrehoz magának egy átmeneti környezetet a / könyvtárból elindulva és megtölti azt a különbözõ rendszerszintû beállításokat tartalmazó állományokkal. Ezeket az állományokat aztán összehasonlítja a jelenleg érvényben levõ változataikkal. Ilyenkor a köztük talált eltéréseket a &man.diff.1; formátumának megfelelõen módon mutatja meg, ahol a jelöli a hozzáadott vagy módosított sorokat, a pedig a teljesen eltávolítandó vagy cserélendõ sorokat. Errõl a formátumról bõvebben a &man.diff.1; man oldalán találhatunk felvilágosítást. A &man.mergemaster.8; ezt követõen megmutatja az összes olyan állományt, ahol eltérést tapasztalt, és ezen a ponton van lehetõségünk letörölni (delete) az új állományokat (amelyekre itt most ideiglenes állományként hivatkozik), telepíteni (install) a módosítatlan ideiglenes (új) állományt, valamint összefésülni (merge) az ideiglenes (új) és a jelenlegi állományokat, vagy ismét átnézni (view) a &man.diff.1; által jelzett különbségeket. Ha az ideiglenes állomány törlését választjuk, akkor a &man.mergemaster.8; ezt úgy értelmezi, hogy változatlanul meg akarjuk tartani a jelenlegi változatot és törölni az újat. Ezt alapvetõen nem javasoljuk, hacsak tényleg nem látunk valamilyen okot erre. A &man.mergemaster.8; parancssorában a ? begépelésével bármikor kérhetünk segítséget. Ha az állomány kihagyását (skip) választjuk, akkor majd ismét felajánlja, amikor végeztünk az összes többivel. A módosítatlan ideiglenes állomány telepítésének választásával lecseréljük a jelenleg verziót az újra. Ha az aktuális verziót sem változtattuk meg, akkor számunkra ez a legjobb megoldás. Az állományok összefésülésének kiválasztásakor kapunk egy szövegszerkesztõt, benne a két állomány tartalmával. Ilyenkor tudjuk a képernyõn soronként egyeztetni a két állományt, majd a belõlük a megfelelõ részek összeválogatásával kialakítani az eredményt. Ebben a feldolgozási módban az l (mint left, vagyis bal) billentyû lenyomására a bal oldalon látható részt, az r (mint right, vagyis jobb) lenyomására pedig a jobb oldalon látható részt választjuk ki. Az így keletkezõ eredményt ezután egy állományba kerül, amelyet telepíteni tudunk. Ez a megoldás olyan állományok esetében használható, amikor a felhasználó módosított az alapértelmezett beállításokat. Ha a &man.diff.1; szerinti alakban akarjuk átnézni a különbségeket, akkor a &man.mergemaster.8; ugyanúgy megmutatja ezeket, mint a paranccsor megjelenítése elõtt. Miután a &man.mergemaster.8; végigment a rendszerszintû állományokon, további opciókat mutat. Megkérdezheti, hogy újra létre akarjuk-e hozni a jelszavakat tároló állományt (rebuild), illetve a folyamat végén a megmaradt ideiglenes állományok törlésére (remove) vár választ. Az állományok aktualizálása kézzel Ha inkább manuálisan szeretnénk frissíteni, akkor nem másolhatjuk csak egyszerûen át az állományokat a /usr/src/etc könyvtárból a /etc könyvtárba és nem hagyhatjuk ezeket sorsukra. Egyes állományokat elõször telepíteni kell. Ez azért van így, mert a /usr/src/etc könyvtár nem pusztán az /etc könyvtár egyszerû másolata. Ráadásul az /etc könyvtárban vannak olyan állományok, amelyek a /usr/src/etc könyvtárban nem is találhatóak meg. Ha (az ajánlottak szerint) a &man.mergemaster.8; segítségével dolgozunk, nyugodtan átléphetünk a következõ szakaszra. Saját magunk a legegyszerûbben ezt úgy tudjuk megoldani, ha telepítjük az állományokat egy új könyvtárba és ezután nekiállunk változásokat keresni. Az <filename>/etc</filename> meglevõ tartalmának mentése Habár elméletileg magától semmi sem fogja bántani ezt a könyvtárat, azért ettõl függetlenül mindig érdemes biztosra menni. Ezért másoljuk az /etc könyvtár tartalmát egy megbízható helyre. Például: &prompt.root; cp -Rp /etc /etc.old Az itt a rekurzív másolást jelenti, a pedig a dátumok, az állományok és egyebek tulajdoni viszonyainak megõrzését. Az /etc új változatának telepítéséhez szükségünk lesz még további könyvtárakra is. Erre a feladatra a /var/tmp/root tökéletesen megfelel, ahol még létre kell hoznunk néhány alkönyvtárat. &prompt.root; mkdir /var/tmp/root &prompt.root; cd /usr/src/etc &prompt.root; make DESTDIR=/var/tmp/root distrib-dirs distribution Ezzel létrejön a szükséges könyvtárszerkezet és települnek az állományok. Sok üres alkönyvtár is keletkezik a /var/tmp/root könyvtáron belül, ezeket töröljük. Ezt a legkönnyebben így tehetjük meg: &prompt.root; cd /var/tmp/root &prompt.root; find -d . -type d | xargs rmdir 2>/dev/null Ezzel törlõdnek az üres könyvtárak. (A szabvány hibakimenetet átirányítottuk a /dev/null eszközre, és ezzel elnyomtuk a nem üres könyvtárak esetén keletkezõ hibaüzeneteket.) A /var/tmp/root most már tartalmazza az összes olyan állományt, amelyek normális esetben a / könyvtáron belül foglalnak helyet. Ezt követõen nincs más dolgunk, csak végigmenni az itt található állományokon és megállapítani, miben térnek a meglévõektõl. Vegyük észre, hogy a /var/tmp/root könyvtárba telepített állományok némelyikének neve .-tal kezdõdik. Az írás pillanatában ezek csak a /var/tmp/root/ és /var/tmp/root/root/ könyvtárakban található parancsértelmezõhöz tartozó indító állományok lehetnek, habár adódhatnak még ilyenek (attól függõen, mikor olvassuk ezt). Ezért a feldolgozásukhoz ne felejtsük el a ls -a parancsot használni. A &man.diff.1; alkalmazásával legegyszerûbben így tudunk összehasonlítani két állományt: &prompt.root; diff /etc/shells /var/tmp/root/etc/shells Ennek hatására megjelennek az /etc/shells és az új /var/tmp/root/etc/shells állományok közti különbségek. A segítségével gyorsan el tudjuk dönteni, hogy összefésüljük-e a két állományt, vagy csak egyszerûen írjuk felül a régebbi verziót az újjal. Az új könyvtár (<filename>/var/tmp/root</filename>) nevébe írjuk bele a dátumot is, így könnyedén össze tudunk hasonlítani több verziót is A rendszer gyakori újrafordítása az /etc szintén gyakori aktualizálását is maga után vonja, ami viszont fárasztó lehet. Az iménti folyamatot fel tudjuk gyorsítani, hogy ha az /etc legutoljára összefésült változatát megtartjuk. A most következõ eljárás ennek mikéntjét vázolja fel. A megszokottak szerint fordítsuk le a rendszert. Majd amikor az /etc könyvtárat és a többit is frissíteni akarjuk, a célként megadott könyvtár nevében adjuk meg a dátumot. Ha tehát például 1998. február 14. van, akkor írjuk ezt: &prompt.root; mkdir /var/tmp/root-19980214 &prompt.root; cd /usr/src/etc &prompt.root; make DESTDIR=/var/tmp/root-19980214 \ distrib-dirs distribution Fésüljük össze a könyvtárban található az állományokat a fentiekben körvonalazottak szerint. Befejezés után õrizzük meg a /var/tmp/root-19980214 könyvtárat. Mikor újra letöltjük a legfrissebb forrásokat és megismételjük az elõbbi lépéseket, haladjunk megint az elsõ lépés szerint. Ekkor tehát létrejön egy újabb könyvtár, amelynek a neve ezúttal már /var/tmp/root-19980221 lesz (ha például hetente frissítünk). Most már meg tudjuk vizsgálni a közbeesõ héten született eltéréseket, ha a két könyvtárra kiadunk egy rekurzív &man.diff.1; hívást: &prompt.root; cd /var/tmp &prompt.root; diff -r root-19980214 root-19980221 Általában így kevesebb eltérést kapunk, mint amennyi például a /var/tmp/root-19980221/etc/ és az /etc összehasonlítása során elkerült volna. Mivel kisebb a keletkezett különbségek száma, ezért könnyebb lesz átvinnünk az /etc könyvtárunkba is a módosításokat. Ezután törölhetjük a régebbi /var/tmp/root-* könyvtárat: &prompt.root; rm -rf /var/tmp/root-19980214 Az /etc összefésülésekor mindig ismételjük meg ezeket a lépéseket. A &man.date.1; meghívásával akár automatikussá is tehetjük a könyvtárak névadását: &prompt.root; mkdir /var/tmp/root-`date "+%Y%m%d"` Újraindítás Ezzel készen is vagyunk. Miután ellenõriztük, hogy minden a megfelelõ helyére került, indítsuk újra a rendszert. Ehhez egy egyszerû &man.shutdown.8; is elegendõ: &prompt.root; shutdown -r now Befejeztük! Gratulálunk, sikerült frissítenünk a &os; rendszerünket. Ha mégis valami balul ütne ki, könnyen újra tudjuk fordítani a rendszer egyes részeit. Például, ha véletlenül letöröltük az /etc/magic állományt az /etc frissítése vagy összefésülése során, a &man.file.1; parancs nem fog tudni rendesen mûködni. Ilyenkor a következõket kell tennünk a hiba kijavításához: &prompt.root; cd /usr/src/usr.bin/file &prompt.root; make all install Kérdések Minden egyes változtatásnál újra kell fordítani a rendszert? Nem könnyû választ adni erre a kérdésre, mivel ez alapvetõen a változtatás jellegétõl függ. Például, ha elindítjuk a CVSup programot és csak az alábbi állományok frissülnek: src/games/cribbage/instr.c src/games/sail/pl_main.c src/release/sysinstall/config.c src/release/sysinstall/media.c src/share/mk/bsd.port.mk Ekkor valószínûleg nem éri meg újrafordítani a teljes rendszert. Elegendõ csupán belépni az érintett állományokat tartalmazó alkönyvtárakba és ott rendre kiadni a make all install parancsot. Ha viszont már valami komolyabb, például az src/lib/libc/stdlib változott meg, akkor vagy az egész rendszert, vagy legalább azon részeit fordítsuk újra, amely statikusan linkeltek (és minden más idõközben még hozzáadott statikusan linkelt dolgot). Hogy melyik megoldást választjuk, teljesen rajtunk áll. Újrafordíthatjuk az egész rendszert kéthetente, mondván, hadd gyüljenek fel szépen a módosítások, vagy a függõségek pontos kielemzésével csak azokat az elemeket fordítjuk újra, amelyek tényleg meg is változtak. Természetesen az egész attól függ, hogy milyen gyakran és melyik rendszert, a &os.stable;-t vagy a &os.current;-et frissítjük. A fordító rengeteg 11-es jelzést (signal 11) (vagy másfajta jelzéseket) dob hibával. Mi történhetett? signal 11 Ez általában hardveres meghibásodásra utal. A rendszer újrafordítása alapjaiban véve egy remek módszer számítógépünk alkatrészeinek terhelésére, ezért gyakorta elõhozza a memória már meglevõ hibáit. Ezek többnyire abban fogalmazódnak meg, hogy a fordító rejtélyes módon leáll mindenféle furcsa jelzések hatására. Errõl biztosan úgy tudunk meggyõzõdni, ha újraindítjuk a make programot és az a folyamat egy teljesen másik pontján vérzik el. Ilyenkor nem tudunk mást tenni, mint egymás után kicserélgetjük, kivesszük az alkatrészeket és így próbáljuk megállapítani, pontosan melyikük is okozza a gondokat. A fordítása befejezése után törölhetem a /usr/obj könyvtárat? Röviden: Igen. A /usr/obj tartalmazza a fordítás folyamata során keletkezõ összes tárgykódot. Ennek törlése általában a make buildworld elsõ lépései között szerepel. Ezért tulajdonképpen a /usr/obj megtartásának nincs túlságosan sok értelme, viszont elég sok (jelenleg úgy kb. 340 MB) helyet fel tudunk így szabadítani. Ha azonban értjük a dolgunkat, akkor megadhatjuk a make buildworld parancsnak, hogy hagyja ki ezt a lépést. Ennek hatására a fordítás sokkal hamarabb véget ér, mivel a legtöbb forrást így nem kell újrafordítani. Üröm az örömben, hogy ha netalán aprócska függõségi problémák merülnének fel, akkor az egész fordítás megfeneklik mindenfelé különös módokon. Emiatt gyakran írnak feleslegesen leveleket a &os; levelezési listáira, melyek a rendszer sikertelen újrafordításáról panaszkodnak, miközben kiderül, hogy az maguk az érintettek akarták lerövidíteni a folyamatot. Lehetséges a megszakadt fordítás folytatása? Ez attól függ, hogy a probléma bekövetkezése elõtt mennyire sikerült eljutni a fordításban. Általában (tehát nem feltétlenül minden esetben) a make buildworld lefordítja a fordításhoz szükséges eszközök (például a &man.gcc.1; és &man.make.1;) újabb változatait és a rendszer függvénykönyvtárait, majd ezeket telepíti. Ezután ezekkel az új eszközökkel lefordítattja saját magukat és ismét telepíti. Ezt követõen fordítja újra az új rendszerállományokkal az egész rendszert (így ezúttal már az olyan szokásos felhasználói programokat is, mint például az &man.ls.1; és a &man.grep.1;). Ha tudjuk, hogy az utolsó fázisban álltunk le (mivel megnéztük a fordításhoz tartozó kimenetet), akkor (minden további nélkül) elég ennyi: … kijavítjuk a hibát … &prompt.root; cd /usr/src &prompt.root; make -DNO_CLEAN all Ezzel megmarad a korábbi make buildworld munkájának eredménye. Ha ezt az üzenetet látjuk a make buildworld kimenetében: -------------------------------------------------------------- Building everything.. -------------------------------------------------------------- akkor különösebb gond nélkül megcsinálhatjuk. Amennyiben viszont nem látunk ilyen üzenetet, vagy nem vagyunk benne biztosak, akkor még mindig jobb elõvigyázatosnak lenni, ezért kénytelenek leszünk teljesen elölrõl kezdeni a fordítást. Hogyan tudjuk felgyorsítani a fordítást? Futtassuk egyfelhasználós módban. Tegyük a /usr/src és /usr/obj könyvtárakat külön állományrendszerekre, külön lemezekre. Sõt, ha lehetséges, akkor ezeket a lemezeket tegyük külön lemezvezérlõkre. Még mindig jobb, ha ezeket az állományrendszereket a &man.ccd.4; (lemezek összefûzését vezérlõ meghajtó) segítségével kiterjesztjük több lemezes eszközre. Kapcsoljuk ki a profilozást (az /etc/make.conf állományban a NO_PROFILE=true megadásával). Többnyire úgy sem lesz rá szükségünk. Az /etc/make.conf állományban a CFLAGS változót állítsuk az értékre. Az gyakran sokkal lassabb, az és alig tér el az optimalizálás mértékében. A paraméter hatására pedig a fordítóprogram átmeneti állományok helyett csöveket használ a kommunikációra, és így megtakarít némi lemezhasználatot (a memóriahasználat terhére). Ha a &man.make.1; parancsnak átadjuk a paramétert, akkor képes több mindent párhuzamosan futtatni. Ez sok esetben segít attól függetlenül, hogy egy- vagy többprocesszoros gépünk van. A /usr/src könyvtárat tartalmazó állományrendszert csatlakoztathatjuk (vagy újracsatlakoztathatjuk) a beállítással. Ilyenkor az állományrendszer nem rögzíti a hozzáférés idejét. Erre az információra sincs igazából szükségünk. &prompt.root; mount -u -o noatime /usr/src A fenti példa azt feltételezi, hogy a /usr/src könyvtárnak saját állományrendszere van. Ha ez nem így lenne (tehát például a /usr része), akkor itt azt kell megadnunk, nem pedig a /usr/src nevét. A /usr/obj könyvtárat tartalmazó állományrendszert csatlakoztathatjuk (vagy újracsatlakoztathatjuk) az beállítással. Ennek hatására a lemez írása aszinkron módon történik. Magyarul az írási mûveletek azonnal befejezõdnek, miközben az adat ténylegesen csak pár másodperccel késõbb kerül ki a lemezre. Ezzel az írási kérelmek gyönyörûen összegyûjthetõek, ami nagymértékû növekedést eredményez a teljesítményben. Ne felejtsük el azonban, hogy ezzel együtt az állományrendszerünk is sérülékenyebbé válik. Ezen beállítás használatával megnõ annak az esélye, hogy egy áramkimaradást követõ indításnál az állományrendszer helyreállíthatatlan állapotba kerül. Ha egyedül csak a /usr/obj található ezen az állományrendszeren, akkor ez nem jelent akkora veszélyt. Amikor viszont rajta kívül még értékes adat is található az állományrendszeren, a beállítás érvényesítése elõtt mindenképpen készítsünk róla friss mentéseket. &prompt.root; mount -u -o async /usr/obj Ahogy arról az elõbb is szó esett, ha a /usr/obj nem egy különálló állományrendszeren található, akkor a példában szereplõ csatlakozási pontot cseréljük ki a megfelelõre. Mi tegyünk, ha valami nem megy rendesen? Egyértelmûen bizonyosodjunk meg róla, hogy a korábbi fordításokból nem maradtak vissza semmiféle kóbor állományok. Ennyi sokszor pontosan elég. &prompt.root; chflags -R noschg /usr/obj/usr &prompt.root; rm -rf /usr/obj/usr &prompt.root; cd /usr/src &prompt.root; make cleandir &prompt.root; make cleandir Igen, a make cleandir parancsot tényleg kétszer kell kiadni. Ezután a make buildworld parancstól indulva kezdjük újra a fordítást. Ha még ezek után is fennáll a probléma, küldjük el a hibát tartalmazó kimenetet és a uname -a parancs eredményét a &a.questions; címére. Ne lepõdjünk meg, ha a beállításainkra vonatkozóan még kapunk további kérdéseket is! Mike Meyer Írta: A források követése több géppel NFS több gép telepítése Ha egyszerre több számítógéppel is szeretnénk követni ugyanannak a forrásfának a változásait és ezért mindegyikre letöltjük a forrásokat majd újrafordítjuk ezeket, akkor sok erõforrást, de leginkább lemezterületet, hálózati sávszélességet és processzoridõt, feleslegesen használunk. Ezekkel úgy tudunk spórolni, ha valójában csak egyetlen géppel végeztetjük el a munka legtöbb részét, miközben a többi NFS használatával dolgozik. Ez a szakasz ezt a módszert foglalja össze. Elõkészületek Elõször is szedjük össze az egyezõ binárisokat futtató gépeket, melyekre a továbbiakban csak fordítási csoport néven hivatkozunk. Minden gépnek lehet saját rendszermagja, viszont a felhasználói programok mindegyikõjük esetében ugyanazok. Ebbõl a csoportból válasszuk ki egy fordító gépet. Ez lesz az a gép, amelyen a rendszer és a rendszermag lefordításra kerül. Ideális esetben ez a leggyorsabb gép, amelynek elegendõ a processzorkapacitása arra, hogy lefuttassa a make buildworld és make buildkernel parancsokat. Érdemes még rajta kívül kiválasztanunk egy tesztelõ gépet is, ahol a véglegesítés elõtt kipróbálhatjuk a szoftverfrissítéseket. Ennek egy olyan gépnek kell lennie, amely akár hosszabb ideig is nélkülözhetõ a csoportból. Lehet akár maga a fordítást végzõ gép is, de nem elvárás. A fordítási csoportban levõ összes gépnek ugyanarról a géprõl és ugyanarra a pontra kell csatlakoztatnia a /usr/obj és /usr/src könyvtárakat. Ezek optimális esetben a fordítással foglalkozó gép két külön lemezmeghajtóján vannak, melyek egyaránt elérhetõek NFS-en keresztül. Ha több fordítási csoportunk is van, akkor az /usr/src könyvtárnak elegendõ csak egyetlen fordító gépen meglennie, a többi pedig csatlakoztassa NFS-en keresztül. Végül gyõzödjünk meg róla, hogy az /etc/make.conf és a /etc/src.conf állományok tartalma a fordítási csoport mindegyik gépénél megegyezik a fordító gépével. Ez azt jelenti, hogy a fordító gépnek az alaprendszer ugyanazon részeit és ugyanúgy kell létrehozni, mint amelyet a fordítási csoport akármelyik gépére telepíteni is akarunk. Ezenkívül még a fordítási csoportban levõ minden egyes gép /etc/make.conf állományában a KERNCONF értékének a saját rendszermagjára vonatkozó konfigurációt kell megadni, illetve a fordítással foglakozó gép KERNCONF változójánál pedig az együtt összeset, a sajátjával kezdve. Ennek megfelelõen a fordító gépnek a rendszermagok lefordításához rendelkeznie kell az egyes gépek /usr/src/sys/arch/conf könyvtárában meglevõ állományaival. Az alaprendszer Most, miután mindent megfelelõen elõkészítettünk, készen állunk a munkára. A ban leírtak szerint fordítsuk le a rendszermagokat és az alaprendszert a fordító gépen, de utána még nem telepítsünk semmit se. Ha befejezõdött a fordítás, lépjünk be a tesztelõ gépre és telepítsük a frissen fordított rendszermagot. Ha ez a gép NFS-en keresztül éri a /usr/src és /usr/obj könyvtárakat, akkor az egyfelhasználós módban aktiválni kell a hálózatot, majd csatlakoztatni ezeket. Ezt legkönnyebben úgy tudjuk megcsinálni, ha a gépet elõször elindítjuk többfelhasználós módban, majd a shutdown now paranccsal egyfelhasználós módba váltunk. Ha eljuttunk ide, telepítsünk az új rendszermagot és rendszert, illetve a megszokott módon futtassuk a mergemaster parancsot. Amikor ezt befejeztük, ezen a gépen térjünk vissza a hétköznapi többfelhasználós mûködési módba. Miután a tesztelésre szánt gépen ellenõriztük, hogy minden a megfelelõ módon mûködik, az elõbb tárgyalt eljárással telepítsük fel a fordítási csoportban levõ összes többi gépre is az új szoftvereket. Portok Ugyanezt a gondolatmenet alkalmazható a portfa esetében is. Az elsõ és egyben legfontosabb lépés a /usr/ports csatlakoztatása ugyanarról a géprõl a fordítási csoport minden gépére. Az /etc/make.conf megfelelõ beállításával még a terjesztési állományokat is meg tudjuk osztani. A DISTDIR értékét egy olyan közösen használt könyvtárra állítsuk, amely írható az NFS-en keresztül megosztott állományrendszerünkben a root felhasználóként tevékenykedõk számára. A WRKDIRPREFIX változót minden gépen egy helyi fordítási könyvtárra állítsuk. Zárásképpen még hozzátesszük, hogy ha csomagokat akarunk készíteni és mások számára is elérhetõvé tenni, akkor ne felejtsük el a PACKAGES változót a DISTDIR változóhoz hasonlóan beállítani. diff --git a/hu_HU.ISO8859-2/books/handbook/mac/chapter.sgml b/hu_HU.ISO8859-2/books/handbook/mac/chapter.sgml index e67cc6c468..d94585c0d1 100644 --- a/hu_HU.ISO8859-2/books/handbook/mac/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/mac/chapter.sgml @@ -1,2969 +1,2969 @@ Tom Rhodes Írta: Kötelezõ hozzáférés-vezérlés Áttekintés MAC kötelezõ hozzáférés-vezérlés MAC A &os; 5.X változata új biztonsági bõvítéseket vett át a TrustedBSD projektbõl a &posix;.1e nyomán. A két legjelentõsebb új biztonsági mechanizmus az állományrendszerekben megtalálható hozzáférés-vezérlési listák (Access Control List, ACL) és a kötelezõ hozzáférés-vezérlés (Mandatory Access Control, MAC). A kötelezõ hozzáférés-vezérlés segítségével olyan új hozzáférés-vezérlési modulok tölthetõek be, amelyek új biztonsági házirendeket implementálnak. Némelyek közülük védelmet nyújtanak a rendszer egy szûk részének, amivel így egy adott szolgáltatást bástyáznak alá. Mások minden részletre kiterjedõ címkézett biztonságot szolgáltatnak alanyokon és objektumokon keresztül. A meghatározás kötelezõ része onnan fakad, hogy a szabályok betartatását a rendszergazdák és a rendszer végzik, és nem bízzák a felhasználókra, ahogy azt a System V típusú rendszerekben a szabványos állományokra és IPC-re érvényes engedélyeken keresztül a tetszés szerinti hozzáférés-vezérlés (Discretionary Access Control, DAC) teszi. Ebben a fejezetben a kötelezõ hozzáférés-vezérlést övezõ keretrendszerre (MAC Framework) és a különbözõ biztonsági házirendeket megvalósító, beilleszthetõ modulokra fogunk összpontosítani. A fejezet elolvasása során megismerjük: hogy a &os; jelen pillanatban milyen modulokat tartalmaz a MAC rendszeren belül és milyen mechanizmusok tartoznak hozzájuk; hogy a MAC biztonsági házirendjeit képezõ modulok miket valósítanak meg, valamint mi a különbség a címkézett és címkézetlen házirendek között; hogyan kell hatékonyan beállítani és használni rendszerünkben a MAC rendszert; hogyan állítsuk be a MAC rendszerben található különféle biztonsági házirendeket képezõ modulokat; hogyan hozzunk létre a MAC rendszer segítségével egy biztonságosabb környezetet, amire példákat is mutatunk; hogyan teszteljük le a MAC rendszer beállításait és bizonyosodjunk meg mûködésének helyességérõl. A fejezet elolvasásához ajánlott: a &unix; és a &os; alapjainak ismerete () a rendszermag beállításának és lefordításának ismerete () tisztában lenni az alapvetõ biztonsági kérdésekkel és azok hatásával a &os;-n belül () Az itt ismertetésre kerülõ információk helytelen alkalmazása a rendszer hozzáférhetõségének teljes elvesztését, a felhasználók bosszantását vagy az X11 által felkínált lehetõségek kirekesztését eredményezheti. Ami viszont ennél is fontosabb, hogy a MAC rendszerre nem úgy kell tekinteni, mint amitõl a rendszerünk tökéletesen biztonságossá válik. A MAC segítségével csupán a meglevõ biztonsági házirendeket gyarapítjuk. A szilárd biztonsági rutin és a rendszeres ellenõrzések elvégzése nélkül a rendszerünk valójában sosem lesz teljesen biztonságos. Hozzá kell tennünk, hogy a fejezetben bemutatott példák tényleg csak példák. Senkinek sem tanácsoljuk, hogy az itt említett beállításokat egy éles rendszerre is kiterjessze. A különbözõ biztonsági modulok felépítése rengeteg gondolkodást és próbálgatást igényel. Aki nem érti meg az egész mûködését, könnyen azon kaphatja magát, hogy újra végig kell mennie a rendszeren és egyenként be kell állítania minden könyvtárat és állományt. Amivel itt nem foglalkozunk Ebben a fejezetben a MAC rendszerrel kapcsolatban rengeteg biztonsági kérdéssel foglalkozni fogunk. Az új MAC biztonsági modulok kifejlesztését azonban már nem érintjük. Számos olyan biztonsági modul található a MAC rendszerben, amelyek rendelkeznek az új modulok kialakításához és teszteléséhez szükséges jellemzõkkel. Ilyenek többek közt a &man.mac.test.4;, &man.mac.stub.4; és a &man.mac.none.4;. Ezekrõl a biztonsági modulokról és az általuk szolgáltatott mechnanizmusokról a man oldalaik tudnak bõvebb tájékoztatást adni. A fejezet fontosabb fogalmai A fejezet tartalmának kifejtéséhez szükségünk lesz néhány fontosabb alapfogalom tisztázására. Segítségükkel vélhetõen sikerül eloszlatni a téma feldolgozása során felmerülõ félreértéseket, illetve elkerülni az új fogalmak és információk váratlan felbukkanását. alany: Alanynak tekintünk a rendszerben minden olyan aktív egyedet, amely információt áramoltat az objektumok, tehát a felhasználók, a processzorok, a rendszerben futó programok stb. között. A &os;-ben majdnem minden esetben a felhasználók egy szálon keresztül vezérlik a futó programokat. címke: A címke egy olyan biztonsági tulajdonság, ami vonatkozhat állományokra, könyvtárakra vagy a rendszer más elemeire. Egy címke tekinthetõ a bizalmasságot jelzõ pecsétnek is: ha egy állományra címkét teszünk, akkor benne megadjuk a rá vonatkozó biztonsági jellemzõket, és csak a hozzá hasonló biztonsági beállításokkal rendelkezõ állományok, felhasználók, erõforrások stb. érhetik el. A címkék jelentését és értelmezését a házirendek beállítása határozza meg: míg egyes házirendek a címkéket egy objektum sértetlenségének vagy titkosságának tekintik, addig mások a hozzáféréssel kapcsolatos szabályokat rögzítik bennük. egycímkés: Egycímkés esetrõl akkor beszélünk, amikor az adat áramlásának szabályozására az egész állományrendszer egyetlen címkét alkalmaz. Ha ezt beállítjuk egy állományrendszernél, de nem adjuk meg vele együtt a opciót, akkor az összes állományra ugyanaz a címke érvényes. erõs vízjel: Az erõs vízjel házirendje szerint a biztonsági szint akkor növelhetõ, ha magasabb szintû információkhoz akarunk hozzájutni. A legtöbb esetben a folyamatok befejezõdése után visszaállítódik az eredeti szint. A &os; MAC rendszere pillanatnyilag ehhez nem tartalmaz házirendet, de a teljesség kedvéért megadtuk ennek a definícióját is. gyenge vízjel: A gyenge vízjel házirendje szerint a biztonsági szint csökkenthetõ az alacsonyabb szintû információk elérése érdekében. A legtöbb esetben a folyamatok befejezõdése után visszaállítódik az eredeti szint. A &os;-ben ezt a házirendet egyedül a &man.mac.lomac.4; alkalmazza. házirend: Szabályok olyan gyûjteménye, amely megadja, hogy miként kell a célokat teljesíteni. Egy házirend általában az egyes elemek kezelését rögzíti. Ebben a fejezetben a házirend kifejezés alatt a biztonsági házirendet értjük, tehát olyan szabályok gyûjteményét, amelyek az adatok és az információ áramlását határozzák meg, továbbá megadják, hogy közülük ki mihez férhet hozzá. kényesség: Általában az MLS tárgyalásakor kerül elõ. Az kényesség szintjével az adatok fontosságát vagy titkosságát szokták jelölni. A kényességi szint növekedésével növekszik az adat titkosságának vagy bizalmasságának szintje. objektum: Objektum vagy rendszerobjektum minden olyan egyed, amelyen információ folyik keresztül az alanyok irányításával. Ezek lehetnek többek közt könyvtárak, állományok, mezõk, képernyõk, billentyûzetek, a memória, mágneses tárolóeszközök, nyomtatók vagy bármilyen más adattároló/hordozó eszköz. Az objektumok alapvetõen adattárolók vagy a rendszer erõforrásai. Egy objektum elérésén gyakorlatilag az adatok elérését értjük. rekesz: Egy rekeszbe soroljuk az elrekeszteni vagy elkülöníteni kívánt programok és adatok összeségét, ahol a felhasználók explicit módon képesek hozzáférni a rendszer bizonyos komponenseihez. Emellett a rekesz utalhat egy tetszõleges csoportosításra is, például munkacsoportra, osztályra, projektre vagy témára. A rekeszek használata elengedhetetlen a biztonsági házirendek kialakításához. sértetlenség: A sértetlenség, mint kulcsfogalom, az adatok megbízhatóságának szintje. Minél sértetlenebb az adat, annál inkább tekinthetjük megbízhatónak. szint: Egy biztonsági tulajdonság megnövelt vagy lecsökkentett beállítása. A szint növekedésével együtt a biztonság mértéke is növekszik. többcímkés: A vagyis többcímkés jellemzõ az állományrendszerek esetén fordulhat elõ, és a &man.tunefs.8; segédprogrammal állítható be egyfelhasználós módban vagy a rendszer indítása során az &man.fstab.5; állományon keresztül, esetleg egy új állományrendszer létrehozásakor. Ezzel a beállítással a rendszergazda különféle MAC címkéket rendelhet különbözõ objektumokhoz. Ez a beállítás természetesen csak olyan biztonsági modulok esetén él, amelyek tudnak címkézni. A MAC ismertetése Az imént definiált új fogalmak tükrében most nézzük meg, hogy a MAC rendszer alkalmazásával miként javíthatunk rendszerünk biztonságán. A MAC rendszerhez készített különbözõ biztonsági modulok alkalmasak a hálózat és az állományrendszerek védelmére, valamint segítségükkel megakadályozhatjuk, hogy a felhasználók elérhessenek bizonyos portokat és socketeket stb. A házirendeket formázó modulokat talán együttesen tudjuk a leghatékonyabban alkalmazni, és ha egyszerre több modul betöltésével egy többrétegû védelmi rendszert alakítunk ki. Ez nem ugyanaz, mint a rendszer megerõsítése, ahol a rendszer összetevõit jellemzõ módon csak bizonyos célok tekintetében edzzük meg. A módszer egyedüli hátulütõi a többszörös állományrendszeri címkékkel, a felhasználónként beállítandó hálózati eléréssel stb. járó adminisztrációs költségek. Ezek a hátrányok azonban eltörpülnek a létrehozott rendszer tartósságával szemben. Például, ha képesek vagyunk megmondani, hogy az adott konfigurációban milyen házirendek alkalmazására van szükség, akkor ezzel az adminisztrációs költségek visszaszoríthatóak. A szükségtelen házirendek eltávolításával még növelhetjük is a rendszer összteljesítményét, valamint az így felkínált rugalmasságot. Egy jó kialakításban figyelembe kell venni az összes biztonsági elõírást, és hatékonyan megvalósítani ezeket a rendszer által felajánlott különféle biztonsági modulokkal. Ezért tehát a MAC lehetõségeit kihasználó rendszerekben legalább annyit meg kell tudni oldani, hogy a felhasználók ne változtathassák kedvükre a biztonsági tulajdonságokat. Az összes felhasználói segédprogramnak, programnak és szkriptnek a kiválasztott biztonsági modulokban szereplõ hozzáférési szabályokkal kifeszített kereten belül kell mozognia. A MAC totális irányítása pedig a rendszergazda kezében van. A rendszergazda így egyedül csak a megfelelõ biztonsági modulok gondos összeválogatásáért felelõs. Bizonyos környezetekben szükséges lehet a hálózaton keresztüli hozzáférések korlátozása is. Ilyen esetekben a &man.mac.portacl.4;, &man.mac.ifoff.4; vagy a &man.mac.biba.4; moduloktól érdemes elindulnunk. Más esetekben az állományrendszerek objektumainak bizalmasságát kell csupán megõriznünk. Erre a célra a &man.mac.bsdextended.4; és &man.mac.mls.4; modulok a legalkalmasabbak. A házirendekhez kapcsolódó döntések a hálózati beállítások alapján is meghozhatóak. Elképzelhetõ, hogy csak bizonyos felhasználók férhetnek hozzá az &man.ssh.1; szolgáltatásain keresztül a hálózathoz vagy az internethez. A &man.mac.portacl.4; pontosan ilyen helyzetekben tud a segítségünkre sietni. Mit tegyünk viszont az állományrendszerek esetén? Vágjunk el adott felhasználókat vagy csoportokat bizonyos könyvtáraktól? Vagy korlátozzuk a felhasználók vagy segédprogramok hozzáférését adott állományokhoz bizonyos objektumok bizalmassá tételével? Az állományrendszerek esetében az objektumokat néhány felhasználó elérheti, mások pedig nem. Például egy nagyobb fejlesztõcsapat kisebb csoportokra bontható. Az A projektben résztvevõ fejlesztõk nem férhetnek hozzá a B projektben dolgozó fejlesztõk munkájához. Ellenben szükségük lehet a C projekten munkálkodó fejlesztõk által létrehozott objektumokra. Ez egy igen érdekes helyzet. A MAC rendszer által felkínált különbözõ biztonsági modulokra építkezve azonban könnyedén csoportokba tudjuk szervezni a felhasználókat, és a megfelelõ területekhez az információ kiszivárgása nélkül hozzá tudjuk õket engedni. Ennek következtében minden egyes biztonsági modul a maga módján gondoskodik az egész rendszer biztonságáról. A céljainknak megfelelõ modulokat egy jól átgondolt biztonsági házirend alapján válasszuk ki. Sok esetben az egész házirendet át kell tekinteni és újra kell alkalmazni a rendszerben. A MAC által felajánlott különbözõ biztonsági modulok megértése segít a rendszergazdáknak megválasztani az adott helyzetben legjobban alkalmazható házirendeket. A &os; rendszermagja alapból nem tartalmazza a MAC rendszert. Ezért a fejezetben szereplõ példák vagy az itt leírtak kipróbálásához az alábbi beállítást kell hozzátennünk a rendszermag beállításait tartalmazó állományhoz: options MAC Majd fordítsuk és telepítsük újra a rendszermagot. Miközben a MAC rendszerhez készült különbözõ modulok a saját man oldalaik szerint igénylik a beépítésüket, vigyázzunk velük, mert ezzel a rendszerüket pillanatok alatt ki tudjuk zárni a hálózatból és így tovább. A MAC alapú védelem felépítése leginkább egy tûzfal összeállításához hasonlítható, ahol ugyanígy számolni kell azzal, hogy egy óvatlan paranccsal kizárhatjuk magunkat a rendszerbõl. Valamilyen módon mindig próbáljunk gondoskodni a rendszer elõzõ állapotának visszaállíthatóságáról, és a MAC távoli adminisztrációját mindig nagyfokú körültekintéssel végezzük. Bõvebben a MAC címkéirõl A MAC-címke egy olyan biztonsági tulajdonság, amelyet a rendszerben található alanyokhoz és objektumokhoz rendelhetünk. Egy címke beállításához a felhasználónak pontosan ismernie kell, hogy ilyenkor mi történik. Az objektumokhoz tartozó tulajdonságok a betöltött moduloktól függenek, és az egyes modulok eltérõ módon értelmezik ezeket a tulajdonságokat. Ha a precíz megértésük hiányában helytelenül állítjuk be ezeket, vagy nem vagyunk képesek tisztázni a velük járó következményeket, akkor az a rendszerünk kiszámíthatatlan és valószínûleg kedvezõtlen viselkedését eredményezi. A házirendek az objektumhoz rendelt biztonsági címkéket a hozzáféréssel kapcsolatos döntések meghozásában használják fel. Bizonyos házirendek esetében már maga a címke elegendõ információt tartalmaz a döntés megformálásához. Máshol viszont a címkék egy nagyobb szabályrendszer részeként dolgozódnak fel stb. Például, ha egy állományra beállítjuk a biba/low címkét, akkor az arra fog utalni, hogy a címkét a Biba nevû biztonsági modul kezeli és értéke low. Az a néhány modul, amely a &os;-ben támogatja a címkézés lehetõségét, három speciális címkét definiál elõre. Ezek rendre a low (alacsony), high (magas) és equal (egyezõ) címkék. Habár az egyes modulok esetén eltérõ módon képesek vezérelni a hozzáférést, azt mindig biztosra vehetjük, hogy a low a legalacsonyabb érték, az equal címke hatására az adott alanyt vagy objektumot érintetlenül hagyják, és a high értékû címke a Biba és MLS modulok esetében a legmagasabb beállítást jelenti. Az egycímkés állományrendszerek használata során az egyes objektumonkhoz csak egyetlen címkét rendelhetünk hozzá. Ezzel az egész rendszerben csak egyfajta engedélyt alkalmazunk, ami sok esetben pontosan elegendõ. Létezik néhány különleges eset, amikor az állományrendszerben levõ alanyokhoz vagy objektumokhoz egyszerre több címkét is hozzá kell rendelnünk. Ilyenkor a opciót kell átadnunk a &man.tunefs.8; segédprogramnak. A Biba és az MLS esetében elõfordulhat, hogy egy numerikus címkével fogjuk jelölni a hierarchikus irányítás pontos szintjét. A numerikus szintek használatával tudjuk az információt különbözõ csoportokba szétosztani vagy elrendezni, például úgy, hogy csak az adott szintû vagy a felette álló csoportok számára engedélyezzük a hozzáférést. Az esetek többségében a rendszergazdának csak egyetlen címkét kell beállítania az egész állományrendszerre. Hé, álljunk csak meg! Akkor ez viszont pont olyan, mint a DAC! Én azt hittem, hogy a MAC szigorúan a rendszergazda kezébe adja az irányítást. Ez az állítás továbbra is fennáll, mivel bizonyos értelemben a root lesz az, aki beállítja a házirendeket, tehát õ mondja meg, hogy a felhasználók milyen kategóriákba vagy hozzáférési szintekbe sorolódnak. Sajnos, sok biztonsági modul még magát a root felhasználót is korlátozza. Az objektumok feletti irányítás ilyenkor a csoportra száll, de a root bármikor visszavonhatja vagy módosíthatja a beállításokat. Ezzel a hierarchikus/engedély alapú modellel a Biba és az MLS nevû házirendek foglalkoznak. A címkék beállítása A címkézéshez kapcsolódó összes beállítást gyakorlatilag az alapvetõ rendszerprogramokkal végezhetjük el. Ezek a parancsok az objektumok és az alanyok szabályozásához, valamint a konfiguráció módosításához és ellenõrzéséhez adnak egy egyszerû kezelõfelületet. Az összes konfigurációs beállítást a &man.setfmac.8; és &man.setpmac.8; segédprogramokkal végezhetjük el. A setfmac segítségével a rendszerszintû objektumokhoz tudunk hozzárendelni a MAC-címkéket, míg a setpmac paranccsal a rendszerben levõ alanyokhoz tudunk címkéket rendelni. Vegyük például ezt: &prompt.root; setfmac biba/high próba Amennyiben az iménti parancs hibátlanul lefutott, visszakapjuk a paranccsort. Ezek a parancsok csak olyankor maradnak nyugodtan, amikor semmilyen hiba nem történt. Mûködésük hasonló a &man.chmod.1; és &man.chown.8; parancsokéhoz. Bizonyos esetekben Permission denied (A hozzáférés nem engedélyezett) hibát kapunk, ami általában akkor bukkan fel, ha egy korlátozott objektummal kapcsolatban próbálunk meg címkét beállítani vagy módosítani Más feltételek mellett másmilyen hibák keletkezhetnek. Például, ha egy olyan objektumot próbálunk újracímkézni, amely nincs a felhasználó birtokában, esetleg nem is létezik vagy írásvédett. Adódhat, hogy a kötelezõ házirend az állomány, a program, vagy az új címkeérték tulajdonságai miatt nem fogja lehetõvé tenni egy futó program számára egy állomány újracímkézését. Nézzük erre egy példát: egy kevésbé sértetlen felhasználó megpróbálja megváltoztatni egy sokkal sértetlenebb állomány címkéjét. Vagy egy kevésbé sértetlen felhasználó sokkal sértetlenebbre akarja állítani egy kevésbé sértetlen állomány címkéjét. . A rendszergazda a következõ paranccsal tudja feloldani az ilyen helyzeteket: &prompt.root; setfmac biba/high próba Permission denied &prompt.root; setpmac biba/low setfmac biba/high próba &prompt.root; getfmac próba próba: biba/high Ahogy az itt tetten is érhetõ, a setpmac használható a modul beállításainak felülbírálására úgy, hogy a meghívott programban egy másik címkét állít be. A getpmac segédprogram általában a sendmailhez hasonló háttérben futó programok esetében alkalmazható: ilyenkor a konkrét parancs helyett a futó program azonosítóját kell megadnunk, de mûködése ugyanaz. Ha a felhasználók a hatókörükön túl levõ állományokat próbálnak meg módosítani, akkor a betöltött modulok szabályainak megfelelõen a mac_set_link függvény Operation not permitted (A mûvelet nem engedélyezett) hibát fog adni. Gyakori címketípusok A &man.mac.biba.4;, &man.mac.mls.4; és &man.mac.lomac.4; moduloknál használhatunk címkéket. Értékük lehet high, equal vagy low, melyek rövid magyarázata a következõ: A low címke az objektumra vagy alanyra érvényes leggyengébb beállítást jelenti. Az ilyen címkéjû objektumok vagy alanyok nem érhetik el a high címkéjûeket. Az equal címke használható minden olyan objektum vagy alany esetében, amelyeket ki akarunk vonni az adott házirend hatálya alól. A high címke adja az objektumhoz vagy alanyhoz tartozó legerõsebb beállítást. Az egyes moduloktól függõen ezek az értékek az információ áramoltatásának különbözõ irányait írhatják le. A megfelelõ man oldalak elolvasásával még jobban megismerhetjük az egyes címketípusok beállításának jellegzetességeit. A címkék beállításáról részletesebben A numerikus osztályozó címkék összehasonlítás:rekesz+rekesz alakban használatosak, tehát a biba/10:2+3+6(5:2+3-20:2+3+4+5+6) kifejezés így értelmezhetõ: A Biba házirend címkéje/10 osztály :2, 3 és 6 rekeszek: (5 osztály...) Ebben a példában az elsõ osztály tekinthetõ valódi osztálynak, amely a valódi rekeszeket jelenti, a második osztály egy alacsonyabb besorolás, míg az utolsó egy magasabb szintû. A legtöbb konfigurációban nem lesz szükségünk ennyire összetett beállításokra, noha képesek vagyunk felírni ezeket. Ha ezt kivetítjük a rendszer objektumaira, akkor a rendszerben levõ alanyokat illetõen csupán az aktuális osztály/rekeszek számítanak, mivel a rendszerben és hálózati csatolófelületeken elérhetõ hozzáférés-vezérlési jogokat tükrözi. Az alany-objektum párokban megadott osztályzatok és rekeszek használhatóak fel egy olyan kapcsolat kiépítésére, amit dominanciának nevezünk. Ilyenkor egy alany ural egy objektumot, vagy egy objektum ural egy alanyt, vagy egyikük sem uralja a másikat, esetleg mind a kettõ uralja egymást. A kettõs dominancia esete akkor forog fenn, amikor a két címke megegyezik. A Biba információáramoltatási sajátosságaiból adódóan jogunk van rekeszeket létrehozni, tudunk kell, hogy ezek projekteknek feleltethetõek meg, de az objektumok is rendelkezhetnek rekeszekkel. A felhasználók ilyenkor csak úgy tudnak elérni egyes objektumokat, ha az su vagy a setpmac használatával leszûkítik a jogaikat egy olyan rekeszre, ahol már nem érvényesülnek rájuk korlátozások. A felhasználók és címkék kapcsolata Maguknak a felhasználóknak is szükségük van címkékre, mivel csak ezek segítségével tudnak az állományaik és programjaik megfelelõ módon együttmûködni a rendszerben érvényes biztonsági házirenddel. Ezt a login.conf állományban megadható bejelentkezési osztályokkal állíthatjuk be. Minden címkéket használó modulban a felhasználóknak is van címkéjük. Lentebb látható egy ilyen minta bejegyzés, amely minden modulhoz tartalmaz beállítást: default:\ :copyright=/etc/COPYRIGHT:\ :welcome=/etc/motd:\ :setenv=MAIL=/var/mail/$,BLOCKSIZE=K:\ :path=~/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:\ :manpath=/usr/share/man /usr/local/man:\ :nologin=/usr/sbin/nologin:\ :cputime=1h30m:\ :datasize=8M:\ :vmemoryuse=100M:\ :stacksize=2M:\ :memorylocked=4M:\ :memoryuse=8M:\ :filesize=8M:\ :coredumpsize=8M:\ :openfiles=24:\ :maxproc=32:\ :priority=0:\ :requirehome:\ :passwordtime=91d:\ :umask=022:\ :ignoretime@:\ :label=partition/13,mls/5,biba/10(5-15),lomac/10[2]: Itt a label opciót használtuk a felhasználói osztályhoz tartozó alapértelmezett címkék beállításához, amit majd a MAC betartat. A felhasználók nem módosíthatják ezt az értéket, ezért ez a felhasználók számára nem tekinthetõ tetszõlegesen elhagyható beállításnak. Egy valós konfigurációban azonban a rendszergazda valószínûleg nem akarja majd egyszerre az összes modult használni. Javasoljuk, hogy mielõtt egy ilyen jellegû konfigurációt adnánk meg, olvassuk el az egész fejezetet. A felhasználók ezt a címkét meg tudják változtatni az elsõ bejelentkezés után, de csak a házirend keretein belül. A fenti példában úgy állítjuk be a Biba házirendet, hogy a futó programok sértetlenségi foka legalább 5, legfeljebb 15 lehet, de az alapértéke 10. Tehát a programok egészen addig 10-es szinten futnak, amíg a programok a Biba bejelentkezéskor megadott tartományában meg nem változtatják ezt a címkét, feltehetõen a setpmac parancs hatására. Mindig, amikor megváltozatjuk a login.conf beállításait, a cap_mkdb paranccsal újra kell generálni a bejelentkezési osztályokhoz tartozó adatbázist, amire a késõbbi példákban vagy részekben igyekszünk is mindig felhívni a figyelmet. Nem árt hozzátennünk, hogy sok rendszerben kifejezetten sok felhasználót kell kezelnünk, amihez több különbözõ bejelentkezési osztályra is szükségünk lehet. Mivel késõbb már csak egyre jobban bonyolódni fog a felhasználók kezelése, ezért soha ne felejtsünk el komolyan elõre tervezni. A &os; következõ változataiban meg fognak jelenni más módszerek is a felhasználók és címkék közti kapcsolatok kezelésére. A &os; 5.3 elõtt azonban ez még semmiképpen sem várható. A hálózati csatolófelületek és a címkék kapcsolata A hálózati csatlakozások esetében is állíthatunk be címkéket, melyek a hálózaton keresztül folyó adatok áramlását határozzák meg. Minden esetben ugyanúgy mûködnek, mint ahogy a házirendek az objektumokra. Például a biba esetében a magas beállításokkal rendelkezõ felhasználók nem férhetnek hozzá az alacsonyabb címkéjû hálózati csatolófelületekhez. Ha MAC-címkéket akarunk rendelni egy hálózati felülethez, akkor az ifconfig parancsnak adjuk meg a paramétert. Például a &prompt.root; ifconfig bge0 maclabel biba/equal parancs beállítja a biba/equal MAC-címkét a &man.bge.4; felületre. A biba/high(low-high) alakú címkéket átadásukhoz idézõjelek közé kell tenni, különben hibát kapunk. Minden címkézést támogató modulhoz tartoznak futási idõben állítható paraméterek, amelyekkel akár le is tudjuk tiltani a MAC-címkéket a hálózati csatolófelületeken. Ugyanezt jelenti egyébként, ha értéket adunk meg a címkének. Ezt behatóbban úgy ismerhetjük meg, ha kielemezzük a sysctl parancs kimenetét, a megfelelõ modul man oldalát vagy a fejezetben további részében található, erre vonatkozó információkat. Egy címke vagy több címke? Alapértelmezés szerint a rendszer a beállítást használja. Ez vajon mit tartogat a rendszergazda számára? Számos olyan eltérést, aminek megvannak a saját elõnyei és hátrányai a rendszer védelmi modelljének rugalmassága szempontjából. A beállítás minden alany vagy objektum esetében csupán egyetlen címke, például a biba/high használatát engedi. Kevesebb adminisztrációs költséggel jár, azonban csökkenteni a címkézést támogató modulok testreszabhatóságát. Ezért sok rendszergazda inkább a beállítást választja a biztonsági házirend kialakítása során. A beállítás lehetõvé teszi, hogy mindegyik alanyhoz és objektumhoz a szabványos beállítás lehetõségeivel szemben egymástól függetlenül külön-külön rendelhessünk címkéket a partíciókon. Az egy- és többcímkés opciónak csak olyan modulok esetében van értelme, amelyek támogatják a címkézést, mint például a Biba, Lomac, MLS és a SEBSD házirendek. Sokszor egyáltalán nincs is szükségünk a használatára. Tekintsük például a következõ helyzetet és biztonsági modellt: Adott egy &os; webszerver, ahol a MAC rendszert több biztonsági házirenddel alkalmazzuk. A gépen egyedül csak a biba/high címkére van szükségünk mindenhez a rendszerben. Itt egyszerûen csak nem adjuk meg az állományrendszernek a beállítást, mivel az egycímkés rendszer mindig rendelkezésünkre áll. Mivel azonban erre a gépre telepíteni akarunk egy webszervert is, ilyenkor a biba/low címke használatával igyekszünk korlátozni a szerver feldolgozási képességeit. A Biba házirendrõl és annak mûködésérõl csak a késõbbiekben fogunk írni, ezért ha az elõbbi megjegyzést még nem teljesen értjük, akkor egyszerûen csak olvassunk tovább és térjünk vissza ide. A szerver futása alatt, vagy legalább is idejének nagy részében egy külön partíciót használhatna, amire a biba/low címkét állítanánk be. Természetesen ez a példa korántsem teljes, hiszen hiányoznak belõle az adatokra érvényes korlátozások, a konfigurációs és felhasználói beállítások. Ez csupán az iménti gondolatmenet gyors illusztrációja. Amennyiben címkézést nem támogató modulokat alkalmazunk, a beállításra szinte sosem lesz szükségünk. Ilyenek például a seeotheruids, portacl és partition házirendek. A opció használata és így speciális, többcímkés védelmi modell létrehozása képes elbonyolítani a rendszer karbantartását, mert ilyenkor az állományrendszerben mindennek lennie kell címkéjének: könyvtáraknak, állományok és még az eszközleíróknak is. A most következõ paranccsal beállítjuk az állományrendszerre a opciót. Ez csak egyfelhasználós módban tehetõ meg: &prompt.root; tunefs -l enable / A lapozópartíció esetében erre nincs szükség. Elõfordulhat, hogy néhány felhasználónak nem sikerül a opciót beállítania a rendszerindító partícióra. Ha ez történne, akkor olvassuk el a fejezet át. A védelem megtervezése Mindig hasznos idõt szánni a tervezésre, amikor nekilátunk egy új technológia alkalmazásához. A tervezés közben a rendszergazdának egyben kell látnia a képet, lehetõleg az alábbiak figyelembevételével: Elvárások a modell felé A modell célkitûzései Továbbá a MAC használata esetén: Miként osztályozzuk a célrendszeren rendelkezésre álló információt és erõforrásokat Milyen információt vagy erõforrást kell korlátoznunk és milyen típusú korlátozást alkalmazzunk rájuk A MAC melyik moduljain keresztül tudjuk elérni céljainkat Habár mindig módunkban áll megváltoztatni és újra konfigurálni a rendszerben található erõforrásokat és biztonsági beállításokat, sokszor azért igen kényelmetlen utánanézni a rendszerben és állítgatni az állományok, illetve felhasználói hozzáférések paramétereit. A beállításainkat valamint azok konfigurációját elõször külön próbáljuk ki, mielõtt a MAC alapú megvalósításunkat egy éles rendszeren kezdjük el használni. Ennek elhagyása szinte biztosan kudarcra ítél minket. A különbözõ környezetek igényei és elvárásai eltérnek. Egy alaposan és minden részletében átgondolt védelmi profil megalapozása csökkenti a rendszer üzembehelyezése után elvégzendõ módosítások számát. Mint olyanokra, a következõ szakaszokban kitérünk a rendszergazdák számára elérhetõ modulokra, bemutatjuk a használatukat és beállításukat és egyes esetekben betekintést is adunk olyan helyzetekbe, ahol a legjobban kiaknázhatóak a képességeik. Például egy webszerver esetén hasznos lehet a &man.mac.biba.4; és &man.mac.bsdextended.4; házirendek alkalmazása. Más esetekben, például egy kevés felhasználóval mûködõ számítógépen, a &man.mac.partition.4; modul lehet jó választás. A modulok beállítása A MAC rendszerben megtalálható összes modul a korábban leírtak szerint beépíthetõ a rendszermagba vagy menet közben is betölthetõ modulként. A használni kívánt modulokat a /boot/loader.conf állományba javasolt felvenni, így azok be tudnak töltõdni a rendszer indítása folyamán. A soron következõ szakaszokban a különbözõ MAC-modulokat dolgozzuk fel és foglaljuk össze a lehetõségeiket. Továbbá a fejezet szeretne szólni ezek alkalmazásáról speciális helyzetekben is. Egyes modulokkal címkézni is tudunk, aminek révén a hozzáféréseket címkékkel szabályozzuk, például úgy, hogy megmondjuk mit szabad és mit nem. A címkék beállításait tartalmazó állomány vezérli az állományok elérését, a hálózati kommunikációt és még sok minden mást. Az elõzõ szakaszban már megismerhettük, hogy a opció segítségével hogyan állíthatjuk be az állományonkénti vagy partíciónkénti hozzáférés-vezérlést. Az egycímkés konfigurációban az egész rendszerben csupán egyetlen címke használatára nyílik mód, ezért is hívják a tunefs beállítását nek. A seeotheruids MAC-modul Lássak másokatMAC-házirend A modul neve: mac_seeotheruids.ko A rendszermag konfigurációs beállítása: options MAC_SEEOTHERUIDS Rendszerindítási beállítás: mac_seeotheruids_load="YES" A &man.mac.seeotheruids.4; modul a security.bsd.see_other_uids és security.bsd.see_other_gids sysctl-változókat utánozza és terjeszti ki. A használatához semmilyen címkét nem kell beállítani és transzparens módon képes együttmûködni a többi modullal. A modult betöltése után az alábbi sysctl-változókkal tudjuk vezérelni: A security.mac.seeotheruids.enabled engedélyezi a modult és az alapértelmezett beállításokat használja. Alapértelmezés szerint egyik felhasználó sem láthatja a többiek futó programjait és csatlakozásait. A security.mac.seeotheruids.specificgid_enabled egy adott csoportot mentesít a házirend szabályozásai alól. Tehát ki akarunk vonni egy csoportot a házirend alkalmazásából, akkor állítsuk be a security.mac.seeotheruids.specificgid=XXX sysctl-változót, ahol az XXX a mentesíteni kívánt csoport numerikus azonosítója. A security.mac.seeotheruids.primarygroup_enabled segítségével adott elsõdleges csoportokat vonhatunk ki a házirend hatálya alól. Ezt a változót nem használhatjuk a security.mac.seeotheruids.specificgid_enabled változóval együtt. A bsdextended MAC-modul MAC Állományrendszeri tûzfal MAC-házirend A modul neve: mac_bsdextended.ko A rendszermag konfigurációs beállítása: options MAC_BSDEXTENDED Rendszerindítási beállítás: mac_bsdextended_load="YES" A &man.mac.bsdextended.4; modul segítségével egy állományrendszer szintjén mûködõ tûzfalat tudunk kialakítani. Ez a modul a szabványos állományrendszeri engedély alapú modelljét bõvíti ki, lehetõvé téve, hogy a rendszergazda tûzfalszerû szabályokkal nyújtson védelmet a könyvtárszerkezetben található állományoknak, segédprogramoknak és könyvtáraknak. Amikor egy állományrendszerbeli objektumhoz próbálunk meg hozzáférni, a modul illeszti ezt egy szabályrendszerre, amiben vagy talál egy hozzátartozó szabályt vagy kifut belõle. Ez a viselkedés a security.mac.bsdextended.firstmatch_enabled &man.sysctl.8; paraméter segítségével változtatható meg. Hasonlóan a &os;-ben található többi tûzfalmodulhoz, az állományok elérését definiáló szabályok a rendszerindítás során egy &man.rc.conf.5; változóból olvasódnak be. A szabályokat a &man.ugidfw.8; segédprogrammal adhatjuk meg, amelynek a formai szabályai hasonlóak az &man.ipfw.8; programéhoz. A &man.libugidfw.3; függvénykönyvtár felhasználásával azonban további segédprogramok is írhatóak hozzá. A modul használata során igyekezzünk minél jobban odafigyelni, mert helytelen alkalmazásával el tudjuk vágni magunkat az állományrendszer bizonyos részeitõl. Példák Miután sikerült betölteni a &man.mac.bsdextended.4; modult, a következõ paranccsal tudjuk lekérdezni a jelenleg érvényes szabályokat: &prompt.root; ugidfw list 0 slots, 0 rules Ahogy az várható is volt, pillanatnyilag még egyetlen szabályt sem adtunk meg. Ennek értelmében tehát mindent el tudunk érni. A következõ paranccsal tudunk olyan szabályt létrehozni, ahol a root kivételével elutasítjuk az összes felhasználó hozzáférését: &prompt.root; ugidfw add subject not uid root new object not uid root mode n Ez egyébként egy nagyon buta ötlet, mivel így a felhasználók még a legegyszerûbb parancsokat, mint például az ls-t, sem tudják rájuk kiadni. Ennél sokkal humánusabb lesz, ha: &prompt.root; ugidfw set 2 subject uid felhasználó1 object uid felhasználó2 mode n &prompt.root; ugidfw set 3 subject uid felhasználó1 object gid felhasználó2 mode n Ilyenkor a felhasználó1 nevû felhasználótól megvonjuk a felhasználó2 felhasználói könyvtárának összes hozzáférését, beleértve a listázhatóságot is. A felhasználó1 helyett megadhatjuk a opciót is. Ebben az esetben egy felhasználó helyett az összes felhasználóra ugyanaz a korlátozás fog érvényesülni. A root felhasználóra ezek a beállítások nem vonatkoznak. Ezzel felvázoltuk, miként lehet a &man.mac.bsdextended.4; modult felhasználni az állományrendszerek megerõsítésére. Részletesebb információkért járuljunk a &man.mac.bsdextended.4; és &man.ugidfw.8; man oldalakhoz. Az ifoff MAC-modul a csatolófelületek elfojtása MAC-házirend A modul neve: mac_ifoff.ko A rendszermag konfigurációs beállítása: options MAC_IFOFF Rendszerindítási beállítás: mac_ifoff_load="YES" A &man.mac.ifoff.4; modul kizárólag abból a célból készült, hogy segítségével menet közben le tudjuk tiltani bizonyos hálózati csatolófelületek beállítását a rendszerindítás közben. Sem címkékre, sem pedig a többi MAC-modulra nincs szükségünk a használatához. A vezérlést nagyrészt az alábbi sysctl-változókkal tudjuk megoldani. A security.mac.ifoff.lo_enabled engedélyezi vagy letiltja a (&man.lo.4;) helyi loopback felületen az összes forgalmat. A security.mac.ifoff.bpfrecv_enabled engedélyezi vagy letiltja a Berkeley csomagszûrõ (BPF, Berkeley Packet Filter) felületén az összes forgalmat. A security.mac.ifoff.other_enabled engedélyezi vagy letiltja az összes többi csatolófelületen az összes forgalmat. A &man.mac.ifoff.4; modult általában olyan környezetek monitorozásakor szokták használni, ahol a rendszer indítása során még nem szabad hálózati forgalomnak keletkeznie. Vagy például a security/aide porttal együtt használva automatikusan el tudjuk zárni a rendszerünket, ha a védett könyvtárakban új állományok keletkeznek vagy megváltoznak a régiek. A portacl MAC-modul Port hozzáférés-vezérlési lista MAC-házirend A modul neve: mac_portacl.ko A rendszermag konfigurációs beállítása: MAC_PORTACL Rendszerindítási beállítás: mac_portacl_load="YES" A &man.mac.portacl.4; modul a helyi TCP és UDP portok kiosztásának korlátozását teszi lehetõvé különféle sysctl-változókon keresztül. A &man.mac.portacl.4; segítségével lényegében a nem-root felhasználók is használhatnak privilegizált, tehát 1024 alatti portokat. Miután betöltöttük, a modul az összes csatlakozásra alkalmazza a MAC-házirendet. Ezután az alábbi változókkal hangolhatjuk a viselkedését: A security.mac.portacl.enabled totálisan engedélyezi vagy letiltja a házirend használatát. A security.mac.portacl.port_high megadja azt a legmagasabb portot, amelyre még kiterjed a &man.mac.portacl.4; védelme. Ha a security.mac.portacl.suser_exempt változónak nem nulla értéket adunk meg, akkor azzal a root felhasználót kivonjuk a szabályozások alól. A security.mac.portacl.rules az érvényes mac_portacl házirendet adja meg, lásd lentebb. A security.mac.portacl.rules változó által megadott aktuális mac_portacl házirend formátuma a következõ: szabály[,szabály,...], ahol ezen a módon tetszõleges számú szabályt adhatunk meg. Az egyes szabályok pedig így írhatóak fel: azonosítótípus: azonosító: protokoll: port. Az azonosítótípus értéke uid vagy gid lehet, amivel megadjuk, hogy az azonosító paraméter felhasználóra vagy csoportra hivatkozik. A protokoll paraméter adja meg, hogy a szabályt TCP vagy UDP típusú kapcsolatra értjük, és ennek megfelelõen az értéke is tcp vagy udp lehet. A sort végül a port paraméter zárja, ahol annak a portnak számát adjuk meg, amelyhez az adott felhasználót vagy csoportot akarjuk kötni. Mivel a szabályokat közvetlenül maga a rendszermag dolgozza fel, ezért a felhasználók illetve csoportok azonosítója, valamint a port értéke kizárólag numerikus érték lehet. Tehát a szabályokban név szerint nem hivatkozhatunk felhasználókra, csoportokra vagy szolgáltatásokra. A &unix;-szerû rendszereken alapértelmezés szerint az 1024 alatti portokat csak privilegizált programok kaphatják meg és használhatják, tehát a root felhasználó neve alatt kell futniuk. A &man.mac.portacl.4; azonban a nem privilegizált programok számára is lehetõvé teszi, hogy elfoglalhassanak 1024 alatti portokat, amihez viszont elõször le kell tiltani ezt a szabvány &unix;-os korlátozást. Ezt úgy érhetjük el, ha a net.inet.ip.portrange.reservedlow és net.inet.ip.portrange.reservedhigh változókat egyaránt nullára állítjuk. A &man.mac.portacl.4; mûködésének részleteirõl a példákon keresztül vagy a megfelelõ man oldalakból tudhatunk meg többet. Példák A következõ példák az iméntieket igyekeznek jobban megvilágítani: &prompt.root; sysctl security.mac.portacl.port_high=1023 &prompt.root; sysctl net.inet.ip.portrange.reservedlow=0 net.inet.ip.portrange.reservedhigh=0 Elsõként beállítjuk, hogy a &man.mac.portacl.4; vegye át a szabványos privilegizált portok vezérlését és letiltjuk a normál &unix;-os korlátozásokat. &prompt.root; sysctl security.mac.portacl.suser_exempt=1 A root felhasználót azonban nem akarjuk kitenni a házirendnek, ezért a security.mac.portacl.suser_exempt változónak egy nem nulla értéket adunk meg. A &man.mac.portacl.4; modul most pontosan ugyanúgy mûködik, mint a &unix;-szerû rendszerek alapértelmezés szerint. &prompt.root; sysctl security.mac.portacl.rules=uid:80:tcp:80 A 80-as azonosítóval rendelkezõ felhasználó (aki általában a www) számára engedélyezzük a 80-as port használatát. Így a www felhasználó anélkül képes webszervert futtatni, hogy szüksége lenne a root jogosultságaira. &prompt.root; sysctl security.mac.portacl.rules=uid:1001:tcp:110,uid:1001:tcp:995 Az 1001-es azonosítóval rendelkezõ felhasználónak megengedjük, hogy elfoglalhassa a 110-es (pop3) és 995-ös (pop3s) portokat. Ennek köszönhetõen az adott felhasználó el tud indítani egy szervert, amihez a 110-es és 995-ös portokon lehet kapcsolódni. A partition MAC-modul a futó programok felosztását megvalósító MAC-házirend A modul neve: mac_partition.ko A rendszermag konfigurációs beállítása: options MAC_PARTITION Rendszerindítási beállítás: mac_partition_load="YES" A &man.mac.partition.4; házirend a futó programokat címkéjük szerint adott partíciókra osztja szét. Ezt leginkább egy speciális &man.jail.8; megoldásként tudjuk elképzelni, noha teljesen felesleges összehasonlítani a kettõt. Ez egy olyan modul, amelyet a &man.loader.conf.5; állományba kell felvenni, hogy a rendszerindítása közben be tudjon töltõdni. Ezt a házirendet többségében a &man.setpmac.8; segédprogrammal tudjuk állítgatni, ahogy az majd lentebb látható lesz. A következõ sysctl-változó tartozik még a modulhoz: A security.mac.partition.enabled engedélyezi a futó programok MAC rendszeren keresztüli felosztását. A házirend engedélyezésével a felhasználók csak a saját programjaikat láthatják, illetve mindazokat, amelyek az övékével egy partícióba tartoznak, de a rajta kívül levõ programokkal már nem dolgozhatnak. Például, ha egy felhasználó az insecure (nem biztonságos) osztály tagja, akkor ne engedjük, hogy hozzáférhessen a top vagy bármilyen más olyan parancshoz, amely további futó programokat hoz létre. A setpmac használatával tudunk címkéket készíteni a partíciókhoz és programokat rendelni hozzájuk: &prompt.root; setpmac partition/13 top Így a top parancsot hozzáadjuk az insecure osztályban levõ felhasználókhoz rendelt címkéhez. Vegyük észre, hogy az insecure osztályba tartozó felhasználók által elindított összes program a partition/13 címkét fogja használni. Példák A következõ parancs megmutatja a partíciók címkéit és a futó programok listáját: &prompt.root; ps Zax Ezzel paranccsal pedig megnézhetjük egy másik felhasználó programjainak címkéit és a felhasználó által futtatott programokat: &prompt.root; ps -ZU trhodes A felhasználók látják a root címkéjével futó programokat is, hacsak be nem töltjük a &man.mac.seeotheruids.4; házirendet. Ezt a megoldást úgy tudnánk igazán ravaszul felhasználni, ha például az /etc/rc.conf állományban letiltanánk az összes szolgáltatást és egy olyan szkripttel indítanánk el ezeket, amely futtatásuk elõtt beállítja hozzájuk a megfelelõ címkét. A most következõ házirendek a három alapértelmezett címkeérték helyett egész számokat használnak. Ezekrõl, valamint a rájuk vonatkozó korlátozásokról a megfelelõ modulok man oldalain ismerhetünk meg többet. A többszintû biztonsági MAC-modul a többszintû biztonsági MAC-házirend A modul neve: mac_mls.ko A rendszermag konfigurációs beállítása: options MAC_MLS Rendszerindítási beállítás: mac_mls_load="YES" A &man.mac.mls.4; (MLS, Multi-Level Security) házirend az információ szigorú áramoltatásával vezérli a rendszerben található alanyok és objektumok közti elérést. A MLS megoldását alkalmazó környezetekben a rekeszek mellett minden alanyra és objektumra be kell még állítanunk egy adott szintû engedélyt is. Mivel az engedélyek avagy az érzékenység szintje akár a hatezret is meghaladhatja, egy rendszergazda számára valódi rémálommá válthat az egyes alanyok és objektumok precíz beállítása. Szerencsére a házirend erre a célra tartalmaz három elõre definiált instant címkét. Ezek az mls/low, mls/equal és mls/high. Mivel a man oldal elég részletesen kifejti ezeket, ezért itt csak érintõlegesen foglalkozunk velük: Az mls/low címke egy olyan alacsony szintû beállítást képvisel, amely lehetõvé teszi, hogy az összes többi objektum uralja. Tehát bárminek is adjuk az mls/low címkét, alacsony szintû engedéllyel fog rendelkezni és nem lesz képes elérni a magasabb szinten levõ információt. Ráadásul a címke a magasabb szintû objektumok számára se fogja engedni, hogy információt közöljön vagy adjon át az alacsonyabb szintek felé. Az mls/equal címke olyan objektumok esetében ajánlott, amelyeket ki akarunk hagyni a házirend szabályozásaiból. Az mls/high címke az elérhetõ legmagasabb szintû engedélyt ábrázolja. Az ilyen címkével ellátott objektumok a rendszer összes többi objektuma felett uralommal rendelkeznek, habár az alacsonyabb szintû objektumok felé nem képesek információt közvetíteni. Az MLS: Egy hierarchikus védelmi szinteket épít fel nem hierarchikus kategóriákkal. Szabályai rögzítettek: a felsõbb szintek olvasása és az alsóbb szintek írása egyaránt tiltott (az alanyok csak a saját vagy az alatta levõ szinteken levõ objektumokat képesek olvasni, de a felette állókat már nem. Ehhez hasonlóan az alanyok a velük egyezõ vagy a felsõbb szinteket tudják írni, de az alattuk levõket már nem). Megõrzi a titkokat (megakadályozza az adatok alkalmatlan közzétételét). Megadja mindazt az alapot, ami szükséges ahhoz, hogy az adatokat több kényességi szinten, párhuzamosan is kezelni tudjuk (anélkül, hogy titkos és bizalmas információkat szivárogtatnánk ki). A speciális szolgáltatások és felületek beállításához az alábbi sysctl-változók használhatóak: A security.mac.mls.enabled engedélyezi vagy tiltja le az MLS házirend alkalmazását. A security.mac.mls.ptys_equal hatására látja el mls/equal címkével az összes &man.pty.4; eszközt létrehozásuk során. A security.mac.mls.revocation_enabled használható az alacsonyabb szintre minõsített objektumok hozzáférésének megvonására. A security.mac.mls.max_compartments segítségével adható meg az objektumok által használt rekeszek szintjének maximális száma. Lényegében a rekeszek rendszerben engedélyezett maximuma. Az MLS címkéit a &man.setfmac.8; paranccsal tudjuk módosítani. Egy ehhez hasonló paranccsal tudunk egy objektumhoz címkét rendelni: &prompt.root; setfmac mls/5 próba A próba állomány MLS-címkéjét az alábbi paranccsal kérhetjük le: &prompt.root; getfmac próba Ezzel össze is foglaltuk az MLS házirend lehetõségeit. Az eddigiket úgy is megoldhatjuk, hogy létrehozunk egy központi házirendet az /etc könyvtárban, amelyben megadjuk az MLS házirendhez tartozó információkat, majd átadjuk a setfmac parancsnak. Erre a módszerre majd a házirendek bemutatása után kerül sor. A kényesség megállapítása A többszintû biztonsági házirend használatával a rendszergazda a kényes információk áramlásának irányát tudja befolyásolni. A megoldás felfele nem lehet olvasni, lefele nem lehet írni jellege folytán alapból mindent a legalacsonyabb szintre helyez. Így tehát kezdetben minden elérhetõ, és a rendszergazdának lassanként ebbõl az állapotból elindulva kell behangolnia az erre alapozó védelmi rendszert az információ bizalmasságának megfelelõen. A fentebb említett három alapvetõ címke mellett a rendszergazdának valószínûleg szüksége lesz a felhasználók csoportosítására és a csoportok közti információáramlás szabályozására. A információ bizalmasságának szintjeit minden bizonnyal könnyebb szavakkal beazonosítani, például Confidential (bizalmas), Secret (titkos) vagy Top Secret (szigorúan bizalmas). Bizonyos helyzetekben elég csak a futó projekteknek megfelelõen kialakítani csoportokat. Az osztályozás konkrét módszerétõl függetlenül azonban mindig elmondható, hogy elõzetes tervezés nélkül sose állítsunk össze ilyen fajsúlyú házirendet. Ezt a biztonsági modult például webes üzletek esetén érdemes használnunk, ahol egy állományszerver tárolja a cég fontos adatait és pénzügyi információit. Viszont egy két vagy három felhasználóval üzemelõ munkaállomás esetében szinte teljesen felesleges gondolkodni rajta. A Biba MAC-modul a Biba sértetlenségi MAC-házirend A modul neve: mac_biba.ko A rendszermag konfigurációs beállítása: options MAC_BIBA Rendszerindítási beállítás: mac_biba_load="YES" A &man.mac.biba.4; modul a MAC Biba elnevezésû házirendjét tölti be. Ez leginkább az MLS házirendhez hasonlít, azzal a kivétellel, hogy az információ áramoltatására vonatkozó szabályok némileg visszafelé mûködnek. Tehát míg az MLS házirend a kényes információ áramlását felfelé nem engedi, addig ez a lefelé irányuló áramlást állítja meg. Emiatt ez a szakasz tulajdonképpen mind a két házirendre érvényesül. A Biba alkalmazása során minden alany és objektum egy sértetlenséget jelképezõ címkét visel. Ezek a címkék hierarchikus osztályokból, nem peidg hiearchikus összetevõkbõl származnak. Egy objektum vagy alany sértetlensége a besorolásával növekszik. A modul a biba/low, biba/equal és biba/high címkéket ismeri, vagyis bõvebben: A biba/low címke tekinthetõ az alanyok és objektumok legkisebb sértetlenségének. Ha beállítjuk egy objektumra vagy alanyra, akkor ezzel megakadályozzuk, hogy nagyobb sértetlenségû objektumokat vagy alanyokat tudjanak írni. Ettõl függetlenül azonban még képesek olvasni ezeket. A biba/equal címke használata kizárólag olyan objektumok esetében javasolt, amelyeket ki akarunk vonni a házirend alól. A biba/high címke megengedi az alacsonyabb szinteken levõ objektumokat írását, de az olvasását viszont már nem. Ezt a címkét olyan objektumra érdemes ragasztani, amelyek hatással vannak az egész rendszer sértetlenségére. A Biba: Hierarchikus sértetlenségi szinteket épít fel nem hiearchikus sértetlenségi kategóriákkal kiegészítve. Szabályai rögzítettek: az felsõbb szintek írása és az alsóbb szintek olvasása egyaránt tilos (pontosan az MLS ellentéte). Egy alany csak a saját vagy az alatta álló szinteken szereplõ objektumokat tudja írni. Ehhez hasonló módon egy alany csak a saját vagy az afeletti szinten található objektumokat képes olvasni. Az adatok sértetlenségét biztosítja (megakadályozza az alkalmatlan módosításukat) Sértetlenségi szinteket határoz meg (szemben az MLS kényességi szintjeivel). Az alábbi sysctl-változókkal vezérlhetjük a Biba házirend mûködését: A security.mac.biba.enabled használható a célrendszeren a Biba házirend engedélyezére vagy letiltására. A security.mac.biba.ptys_equal segítségével kapcsolhatjuk ki a Biba házirend alkalmazását a &man.pty.4; eszközökön. A security.mac.biba.revocation_enabled hatására visszavonódik az objektumok hozzáférése, ha az rájuk vonatkozó címke megváltozik. A rendszer objektumain a Biba házirendet a setfmac és getfmac paranccsal állíthatjuk be: &prompt.root; setfmac biba/low próba &prompt.root; getfmac próba próba: biba/low A sértetlenség megállapítása A sértetlenség a kényességtõl eltérõen azt igyekszik szavatolni, hogy az információt illetéktelenek nem módosítják. Ez egyaránt vonatkozik az alanyok, objektumok és a kettõ között átadott adatokra. Gondoskodik róla, hogy a felhasználók csak olyan információkat változtathathassanak meg, sõt csak olyat érhessenek el, amire ténylegesen szükségük van. A &man.mac.biba.4; biztonsági modul megengedi a rendszergazda számára, hogy megmondja milyen állományokat és programokat láthat vagy hívhat meg a felhasználó vagy felhasználók egy csoportja, miközben biztosítja, hogy az állományok és a programok nincsenek kitéve semmilyen fenyegetésnek, és a rendszer az adott felhasználóban vagy felhasználói csoportban megbízik. A kezdeti tervezési fázis során a rendszergazdának fel kell készülnie arra, hogy a felhasználókat osztályokra, szintekre és területekre kell osztania. A felhasználók nem csak adatokhoz, hanem programokhoz és segédprogramokhoz sem lesznek képesek hozzáférni, mind az indításuk elõtt és után. A modul aktiválás után a rendszer alapból rögtön a legmagasabb címkét kapja meg, és teljesen a rendszergazdára hárul, hogy a felhasználókhoz beállítsa a különféle osztályokat és szinteket. A fentebb leírt engedélyszintek helyett akár témák alapján is tervezhetünk. Például kizárólag csak a fejlesztõk számára engedjük meg a forráskód módosítását, a forráskód lefordítását és a többi fejlesztõeszköz használatát. Eközben a többi felhasználót felosztjuk további csoportokba, például tesztelõkre és tervezõkre, vagy meghagyjuk ezeket átlagos felhasználóknak, akik csak olvasási joggal rendelkeznek. A megvalósított biztonsági modell természetébõl fakadóan egy kevésbé sértetlenebb alany nem írhatja a sokkal sértetlenebb alanyokat, a sokkal sértetlenebb alanyok pedig nem érhetik el vagy olvashatják a kevésbé sértetlen objektumokat. A lehetõ legkisebb osztályú címke beállításával gyakorlatilag elérhetetlenné teszük az alanyok számára. A modult valószínûleg egy korlátozott webszerver, fejlesztõi- és tesztgépek vagy forráskód tárolására szánt környezetben érdemes bevetni. Annál esélytelenebb a használata viszont egy munkaállomás, útválasztó vagy hálózati tûzfal esetében. A LOMAC MAC-modul a LOMAC MAC-házirend A modul neve: mac_lomac.ko A rendszermag konfigurációs beállítása: options MAC_LOMAC Rendszerindítás beállítás: mac_lomac_load="YES" Eltérõen a MAC Biba házirendjétõl, a &man.mac.lomac.4; egyedül csak azután engedi elérni az kevésbé sértetlenebb objektumokat, miután csökkentjük a sértetlenség szintjét és ezzel betartjuk a sértetlenségre vonatkozó szabályokat. A gyenge vízjeles sértetlenségi házirend MAC alapú változatát nem szabad összetéveszteni a korábbi &man.lomac.4; implementációval, amely majdnem ugyanúgy mûködik, mint a Biba, azzal az a kivétellel, hogy a lebegõ címkékkel támogatjuk az alanyok lefokozását egy kisegítõ osztály rekeszén keresztül. Ez a másodlagos rekesz [kisegítõ_osztály] alakú. Tehát amikor egy kisegítõ osztállyal adjuk meg a lomac házirendet, valahogy így néz ki: lomac/10[2], ahol a kettes (2) szám ez a kisegítésre használt osztály. A MAC LOMAC házirendje az összes rendszerszintû objektum esetében jelenlevõ sértetlenségi címkézésen alapszik, megengedve az alanyok számára, hogy az kevésbé sértetlen objektumokat olvasni tudják, majd a címke leminõsítésével az alany meg tudja akadályozni a sokkal sértetlenebbnek ítélt objektumok jövõbeni írását. Ez az a fentebb tárgyalt [kisegítõ_osztály] opció, ezért ez a modul a Bibáénál több kompatibilitást és kevesebb kezdeti beállítást igényel. Példák Hasonlóan a Biba és MLS házirendeknél megszokottakhoz, a setfmac és setpmac segédprogramok használhatóak a címkék hozzárendeléséhez: &prompt.root; setfmac /usr/home/trhodes lomac/high[low] &prompt.root; getfmac /usr/home/trhodes lomac/high[low] Itt a kisegítõ osztály a low. Ezt csak a LOMAC MAC-házirendnél adhatjuk meg. A Nagios elzárása a MAC rendszerrel a Nagios elzárása a MAC rendszerrel A most következõ bemutatóban a MAC moduljainak és a megfelelõen beállított házirendek használatával fogunk kialakítani egy biztonságos környezetet. Ne feledjük azonban, hogy ez csupán egy ártatlan próba és nem pedig a mindenki biztonsági aggályait kielégítõ legvégsõ megoldás. Ha egy házirendet vakon építünk fel és nem értjük meg a mûködését, az soha nem válik hasznunkra, és egy éles helyzetben katasztrofális hatással járhat. A folyamat megkezdése elõtt be kell állítanunk a multilabel opciót mindegyik állományrendszerre, a fejezet elején leírtaknak megfelelõen. Ha ezt a lépést kihagyjuk, akkor hibákat kapunk. Továbbá még az elõkészület részeként ne felejtsünk el gondoskodni a net-mngt/nagios-plugins, net-mngt/nagios és www/apache13 portok telepítésérõl, beállításáról és megfelelõ mûködésérõl sem. A nem megbízható felhasználók osztályának létrehozása Az eljárást kezdjük az alábbi (insecure) felhasználói osztály hozzáadásával az /etc/login.conf állományban: insecure:\ :copyright=/etc/COPYRIGHT:\ :welcome=/etc/motd:\ :setenv=MAIL=/var/mail/$,BLOCKSIZE=K:\ :path=~/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin :manpath=/usr/share/man /usr/local/man:\ :nologin=/usr/sbin/nologin:\ :cputime=1h30m:\ :datasize=8M:\ :vmemoryuse=100M:\ :stacksize=2M:\ :memorylocked=4M:\ :memoryuse=8M:\ :filesize=8M:\ :coredumpsize=8M:\ :openfiles=24:\ :maxproc=32:\ :priority=0:\ :requirehome:\ :passwordtime=91d:\ :umask=022:\ :ignoretime@:\ :label=biba/10(10-10): Valamint egészítsük ki az alapértelmezett (default) felhasználói osztályt a következõ sorral: :label=biba/high: Ahogy ezzel elkészültünk, az hozzátartozó adatbázis újbóli legyártásához a következõ parancsot kell kiadnunk: &prompt.root; cap_mkdb /etc/login.conf A rendszerindítással kapcsolatos beállítások Még ne indítsuk újra a számítógépet, csupán a szükséges modulok betöltéséhez bõvítsük ki a /boot/loader.conf állományt az alábbi sorokkal: mac_biba_load="YES" mac_seeotheruids_load="YES" A felhasználók beállítása Soroljuk be a root felhasználót a default osztályba: &prompt.root; pw usermod root -L default Az összes root felhasználón kívüli hozzáférésnek vagy rendszerfelhasználónak most kelleni fog egy bejelentkezési osztály. A bejelentkezési osztályra egyébként is szükség lesz, mert ennek hiányában a felhasználók még az olyan egyszerû parancsokat sem tudják kiadni, mint például a &man.vi.1;. A következõ sh szkript nekünk erre pontosan megfelel: &prompt.root; for x in `awk -F: '($3 >= 1001) && ($3 != 65534) { print $1 }' \ /etc/passwd`; do pw usermod $x -L default; done; Helyezzük át a nagios és www felhasználókat az insecure osztályba: &prompt.root; pw usermod nagios -L insecure &prompt.root; pw usermod www -L insecure A <filename>contexts</filename> állomány létrehozása Most csinálnunk kell egy contexts állományt. Ebben példában az /etc/policy.contexts állományt használjuk. # Ez a rendszer alapértelmezett BIBA házirendje. # Rendszer: /var/run biba/equal /var/run/* biba/equal /dev biba/equal /dev/* biba/equal /var biba/equal /var/spool biba/equal /var/spool/* biba/equal /var/log biba/equal /var/log/* biba/equal /tmp biba/equal /tmp/* biba/equal /var/tmp biba/equal /var/tmp/* biba/equal /var/spool/mqueue biba/equal /var/spool/clientmqueue biba/equal # Nagios: /usr/local/etc/nagios /usr/local/etc/nagios/* biba/10 /var/spool/nagios biba/10 /var/spool/nagios/* biba/10 # Apache: /usr/local/etc/apache biba/10 /usr/local/etc/apache/* biba/10 Ezzel a házirenddel az információ áramlását szabályozzuk. Ebben a konkrét konfigurációban a felhasználók, a root és társai, nem férhetnek hozzá a Nagioshoz. A Nagios beállításait tároló állományok és a neve alatt futó programok így teljesen különválnak vagyis elzáródnak a rendszer többi részétõl. Ez az iménti állomány a következõ parancs hatására kerül be a rendszerünkbe: &prompt.root; setfsmac -ef /etc/policy.contexts / &prompt.root; setfsmac -ef /etc/policy.contexts / A fenti állományrendszer felépítése a környezettõl függõen eltérhet, habár ezt minden egyes állományrendszeren le kell futtatni. Az /etc/mac.conf állományt törzsét a következõképpen kell még átírnunk: default_labels file ?biba default_labels ifnet ?biba default_labels process ?biba default_labels socket ?biba A hálózat engedélyezése Tegyük hozzá a következõ sort az /boot/loader.conf állományhoz: security.mac.biba.trust_all_interfaces=1 Ezt az alábbi beállítást pedig szúrjuk be az rc.conf állományba a hálózati kártya konfigurációjához. Amennyiben az internetet DHCP segítségével érjük el, ezt a beállítást manuálisan kell megtenni minden rendszerindítás alkalmával: maclabel biba/equal A konfiguráció kipróbálása a MAC beállításainak kipróbálása Gondoskodjunk róla, hogy a webszerver és a Nagios nem fog elindulni a rendszer indításakor, majd indítsuk újra a gépet. Ezenkívül még ellenõrizzük, hogy a root ne tudjon hozzáférni a Nagios beállításait tartalmazó könyvtárhoz. Ha a root képes kiadni egy &man.ls.1; parancsot a /var/spool/nagios könyvtárra, akkor valamit elronthattunk. Normális esetben egy permission denied üzenetet kell kapnunk. Ha minden jónak tûnik, akkor a Nagios, Apache és Sendmail most már elindítható a biztonsági házirend szabályozásai szerint. Ezt a következõ parancsokkal tehetjük meg: &prompt.root; cd /etc/mail && make stop && \ setpmac biba/equal make start && setpmac biba/10\(10-10\) apachectl start && \ setpmac biba/10\(10-10\) /usr/local/etc/rc.d/nagios.sh forcestart Kétszer is ellenõrizzük, hogy minden a megfelelõ módon viselkedik-e. Ha valamilyen furcsaságot tapasztalunk, akkor nézzük át a naplókat vagy a hibaüzeneteket. A &man.sysctl.8; használatával tiltsuk le a &man.mac.biba.4; biztonsági modult és próbáljunk meg mindent a szokott módon újraindítani. A root felhasználó különösebb aggodalom nélkül képes megváltoztatni a biztonsági rend betartatását és átírni a konfigurációs állományokat. Egy frissen indított parancsértelmezõ számára ezzel a paranccsal tudjuk csökkenteni a biztonsági besorolást: &prompt.root; setpmac biba/10 csh Ennek kivédésére a felhasználókat a &man.login.conf.5; beállításaival le kell korlátozni. Ha a &man.setpmac.8; megpróbál a rekesz határain túl futtatni egy parancsot, akkor hibát ad vissza és a parancs nem fut le. Ebben az esetben a root felhasználót tegyük a biba/high(high-high) értékek közé. A felhasználók korlátozása Ebben a példában egy viszonylag kicsi, nagyjából mindössze ötven felhasználós, adattárolásra használatos rendszert veszünk alapul. A felhasználók rendelkezhetnek bizonyos bejelentkezési tulajdonságokkal, és nem csak adatokat tudnak tárolni, hanem az erõforrásokhoz is hozzá tudnak férni. Itt most a &man.mac.bsdextended.4; és a &man.mac.seeotheruids.4; modulokat vetjük be együttesen, és nem csak a rendszer objektumainak elérését tudjuk megakadályozni, hanem az egyes felhasználók futó programjait is elrejtjük. A mûveletet kezdjük azzal, hogy a /boot/loader.conf állományt kibõvítjük a következõ módon: - mac_seeotheruids_enabled="YES" + mac_seeotheruids_load="YES" A &man.mac.bsdextended.4; biztonsági modul az alábbi rc.conf-változóval hozható mûködésbe: ugidfw_enable="YES" A hozzátartozó alapértelmezett szabálykészlet az /etc/rc.bsdextended állományban tárolódik, amely pedig a rendszer indítása során töltõdik be. Ezeket némileg módosítanunk kell majd. Mivel a példában szereplõ számítógép csak a felhasználók kiszolgálását hivatott ellátni, az utolsó kettõ kivételével mindent hagyhatunk megjegyzésben. Így kikényszerítjük felhasználók által birtokolt rendszerobjektumok alapértelmezés szerinti betöltését. Vegyük fel a szükséges felhasználókat a számítógépre és indítsuk újra. Tesztelési célból próbáljunk meg különbözõ felhasználókként bejelentkezni két konzolon. Futassuk le a ps aux parancsot, és így meg tudjuk figyelni, hogy mennyire látjuk a többi felhasználót. Amikor megpróbáljuk kiadni a &man.ls.1; parancsot a többiek felhasználói könyvtáraira, akkor hibát kell kapnunk. Ne próbálgassunk a root felhasználóval, hacsak a megfelelõ sysctl változókban be nem állítottuk az õ hozzáférésének blokkolását is. Amikor felveszük egy felhasználót a rendszerbe, a hozzátartozó &man.mac.bsdextended.4; szabály nem fog szerepelni a szabályrendszerben. A szabályrendszer gyors frissítését úgy tudjuk megoldani, ha a &man.kldunload.8; használatával egyszerûen eltávolítjuk a biztonsági modult a memóriából és újratöltjük a &man.kldload.8; paranccsal. A hibák elhárítása a MAC rendszerben MAC hibaelhárítás A fejlesztés fázisában bizonyos normál konfigurációval rendelkezõ felhasználók gondokat jeleztek. Ezeket foglaljuk most itt össze: A <option>multilabel</option> beállítás nem adható meg a <filename>/</filename> állományrendszerre A beállítás nem marad meg a rendszerindító (/) partíciómon! A tapasztalatok szerint körülbelül minden ötvenedik felhasználó szembesül ezzel a problémával, és mi is találkozunk vele a kezdeti konfigurációk kialakítása során. Ennek az úgynevezett hibának a behatóbb tanulmányozása során arra jutottunk, hogy ez többnyire vagy a hibás dokumentálásból vagy a dokumentáció félreértelmezésébõl ered. Független attól, hogy ez mitõl is következett be, a következõ lépések megtételével orvosolhatjuk: Nyissuk meg az /etc/fstab állományt és adjuk meg a rendszerindító partíciónak az , vagyis az írásvédett (read-only) beállítást. Indítsuk újra a gépet egyfelhasználós módban. A tunefs parancsot futtassuk le a / állományrendszeren. Indítsuk újra a rendszert normál módban. Adjuk ki a mount / parancsot, majd az /etc/fstab állományban írjuk át a beállítást az értékre és megint indítsuk újra a rendszert. Alaposan nézzük át a mount parancs kimenetét és gyõzödjünk meg róla, hogy a opció valóban beállítódott a rendszerindító állományrendszerre. A <acronym>MAC</acronym> után nem lehet indítani az X11 szervert Nem indul az X, miután MAC-kel kialakítottunk egy biztonságos környezetet! Ezt vagy a MAC partition házirendje okozza, vagy az egyik címkékeket használó házirend helytelen beállítása. A következõ módon deríthetjük ki az okát: Figyelmesen olvassuk el a hibaüzenetet: ha a felhasználó az insecure osztály tagja, akkor a partition házirend lesz a bûnös. Próbáljuk meg a felhasználót visszatenni a default osztályba és a cap_mkdb paranccsal újragenerálni az adatbázist. Ha ez nem segít a problémán, akkor haladjunk tovább. Alaposan ellenõrizzük a címkékhez tartozó házirendeket. Vizsgáljuk meg, hogy a kérdeses felhasználó esetében a házirendet és az X11 alkalmazást, valamint a /dev eszközöket tényleg jól állítottuk be. Ha az iméntiek egyik sem oldja meg gondunkat, küldjük el a hibaüzenetet és a környezetünk rövid leírását a a TrustedBSD honlapjáról elérhetõ TrustedBSD levelezési lista vagy a &a.questions; címére. Hiba: &man..secure.path.3; cannot stat <filename>.login_conf</filename> Amikor a rendszerben megpróbálok a root felhasználóról átváltani egy másik felhasználóra, a _secure_path: unable to state .login_conf hibaüzenet jelenik meg. Ez az üzenet általában akkor látható, amikor a felhasználó nagyobb értékû címkével rendelkezik annál, mint akivé válni akar. Például vegyük a joska nevû felhasználót a rendszerben, aki az alap biba/low címkével rendelkezik. A root felhasználó, akinek biba/high címkéje van, nem láthatja joska felhasználói könyvtárát. Ez attól függetlenül megtörténik, hogy a root a su paranccsal váltott át a joska nevû felhasználóra vagy sem. Egy ilyen helyzetben a Biba sértetlenségi modellje nem fogja engedni a root felhasználóra számára, hogy láthassa a kevésbé sértetlen objektumokat. A <username>root</username> felhasználó nem megy! A rendszer normál vagy egyfelhasználós módban sem ismeri fel a root felhasználót. A whoami parancs 0 (nullát) ad vissza és a su parancs pedig annyit mond: who are you? (ki vagy?). Mi történhetett? Ez csak olyankor történhet, ha a címkézési házirendet nem engedélyezzük, vagy a &man.sysctl.8; használatával, vagy pedig a modul eltávolításával. Ha a házirendet letiltjuk vagy ideiglenesen letiltódik, akkor a bejelentkezési tulajdonságokat tároló adatbázist a beállítás eltávolításával kell újrakonfigurálni. A login.conf állományból ne felejtsük el kivenni az összes beállítást és a cap_mkdb paranccsal újragenerálni az adatbázist. Ilyen akkor is elõfordulhat, amikor a házirend valamilyen módon korlátozza a master.passwd állomány vagy adatbázis elérhetõségét. Ezt általában az okozza, hogy a rendszergazda az állományt olyan címke alatt módosítja, amely ütközik a rendszerben alkalmazott általános házirenddel. Ebben az esetekben a rendszer próbálja meg beolvasni a felhasználók adatait, azonban mivel közben az állomány új címkét örökölt, nem fér hozzá. Ha a &man.sysctl.8; paranccsal letiltjuk a házirendet, minden vissza fog térni a rendes kerékvágásba. diff --git a/hu_HU.ISO8859-2/books/handbook/multimedia/chapter.sgml b/hu_HU.ISO8859-2/books/handbook/multimedia/chapter.sgml index e641e7fd05..d07dd08ce0 100644 --- a/hu_HU.ISO8859-2/books/handbook/multimedia/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/multimedia/chapter.sgml @@ -1,2509 +1,2510 @@ Ross Lippert Szerkesztette: Multimédia Áttekintés A &os; a hangkártyák széles választékát ismeri, ami által képesek vagyunk számítógépünkkel hi-fi minõségû hangzást létrehozni. Ennek részeként rögzíteni és visszajátszani tudunk többek közt MPEG Audio Layer 3 (MP3), WAV és Ogg Vorbis formátumokban. A &os; Portgyûjteménye ezenkívül tartalmaz még olyan alkalmazásokat is, amelyekkel szerkeszteni lehet a felvett hangokat, effekteket hozzátenni és vezérelni a hangkártyánkhoz csatlakoztatott MIDI eszközöket. Némi kísérletezéssel a &os; még videoállományok és DVD-k lejátszására is rávehetõ. A különféle videoanyagok kódolására, konvertálására és visszajátszására alkalmas programok száma azonban jóval kisebb, mint a hanganyagok esetén. Például az írás pillanatában nincs a &os; Portgyûjteményében a formátumok közti konvertálásra alkalmas, a videókat olyan jól újrakódolni tudó alkalmazás, amilyen az audio esetén az audio/sox. Azonban ezen a területen a szoftverek palettája gyorsan változik. Ebben a fejezetben bemutatjuk a hangkártyánk beállításához szükséges lépéseket. Az X11 telepítése és beállítása () során ugyan már foglalkoztunk a videokártyánkkal kapcsolatos hardveres problémákkal, azonban a jobb visszajátszás érdekében további cselfogásokat is be kell majd vetnünk. A fejezet elolvasása során megismerjük: hogyan állítsuk be úgy a rendszerünket, hogy felismerje a hangkártyánkat; hogyan bizonyosodjuk meg róla, hogy a kártyánk valóban mûködik; hogyan oldjuk meg a hangkártya beállítása során felmerülõ problémákat; hogyan játsszunk le és kódoljunk MP3-at vagy más egyéb hangformátumot; hogyan támogatja a videokat az X szerver; hogyan adnak az egyes lejátszók és kódolók még jobb eredményt hogyan játsszunk le DVD-ket, .mpg és .avi állományokat; hogyan mentsük a CD-k és DVD-k tartalmát állományokba; hogyan állítsuk be a TV kártyánkat hogyan állítsunk be egy scannert. A fejezet elolvasásához ajánlott: egy új rendszermag beállításának és telepítésének ismerete (). Ha zenei CD-ket próbálunk meg a &man.mount.8; paranccsal csatlakoztatni, akkor az hibával, vagy a legrosszabb esetben akár teljes rendszerösszeomlással is járhat. Az ilyen típusú lemezek az ISO szabványú állományrendszerekétõl eltérõ kódolással rendelkeznek. Moses Moore Írta: Marc Fonvieille A &os; 5.X verziójához igazította: A hangkártya beállítása A rendszer beállítása PCI ISA hangkártya A mûvelet megkezdése elõtt ki kell derítenünk, milyen típusú hangkártyánk van, milyen chip van rajta, PCI vagy ISA buszon csatlakozik-e. A &os; rengeteg PCI és ISA buszos kártyát ismer egyaránt. A sajátunk beazonosításához a támogatott hangeszközök listáját a Hardware Notes (Hardverjegyzék) oldalán találhatjuk meg. Ebbõl a jegyzékbõl mellesleg azt is megtudhatjuk, hogy melyik meghajtó kezeli a kártyánkat. rendszermag beállítás A hangeszközünk használatához be kell töltenünk a neki megfelelõ meghajtót. Ez két módon is megtehetõ. Ezek közül az a legkönnyebb, ha a &man.kldload.8; paranccsal egyszerûen betöltjük a rendszermag hangkártyánkhoz tartozó modulját. Ezt megtehetjük közvetlenül parancssorból: &prompt.root; kldload snd_emu10k1 vagy a /boot/loader.conf állományból az alábbihoz hasonló sor hozzáadásával: snd_emu10k1_load="YES" A fenti példák a Creative &soundblaster; Live! hangkártyára vonatkoznak. A többi betölthetõ hangkártya-modul felsorolása a /boot/defaults/loader.conf állományban található. Ha nem vagyunk benne biztosak, hogy melyik meghajtót is akarjuk pontosan használni, akkor próbálkozzunk az snd_driver modul betöltésével: &prompt.root; kldload snd_driver Ez egy olyan metameghajtó, ami egyszerre betölti az összes érintett eszközmeghajtót, és segítségével felgyorsíthatjuk a megfelelõ meghajtó megtalálását. A /boot/loader.conf használatával is be tudjuk ugyanígy tölteni az összes meghajtót. Az snd_driver metameghajtó betöltése után úgy kereshetjük meg a ténylegesen használatban levõ meghajtót, ha megnézzük a /dev/sndstat állományt a cat /dev/sndstat paranccsal. A második módszer szerint a hangkártyánk támogatását statikusan beépítjük a rendszermagba. A lentebb található szakaszban olvashatjuk mindazok az információkat, amikre szükségünk lehet ennek elvégzése közben. A rendszermag újrafordításával kapcsolatban forduljunk a hez. A hangkártya támogatásával rendelkezõ saját rendszermag összeállítása Elsõként hozzá kell adnunk a rendszermaghoz a hangeszközök alapmeghajtóját, a &man.sound.4; eszközt. Ezt a rendszermag beállításait tartalmazó állományban az alábbi sor felvételével tehetjük meg: device sound Ezután tegyük még hozzá a hangkártyánkhoz kapcsolódó támogatást is. Ehhez viszont pontosan tudunk kell, melyik meghajtó képes mûködtetni a kártyát. A hangkártyához tartozó meghajtót a Hardware Notes (Hardverjegyzék)-ben található eszközök listájából deríthetjük ki. Például a Creative &soundblaster; Live! hangkártyát a &man.snd.emu10k1.4; meghajtó kezeli. Ennek a hangkártyának a támogatását az alábbi sorral állíthatjuk be: device snd_emu10k1 Az itt használatos formátumot a meghajtó man oldalának átolvasásából tudhatjuk meg. Azonban az összes támogatott hangkártya meghajtó megadásának pontos formátuma megtalálható a /usr/src/sys/conf/NOTES állományban is. A PnP (Plug n Play)-t nem ismerõ ISA kártyák esetén az összes többi nem PnP-s ISA kártyához hasonlóan szükséges lehet a rendszermag számára megadnunk a kártya hardveres beállításait (IRQ, I/O port stb). Ezt a /boot/device.hints állományon keresztül tehetjük meg. A rendszerindítási folyamat során a &man.loader.8; beolvassa ezt az állományt, majd átadja a benne szereplõ információkat a rendszermagnak. Például a Creative &soundblaster; 16, nem PnP-s ISA kártya az snd_sb16 meghajtóval együtt az &man.snd.sbc.4; meghajtót használja. A kártya használatához a rendszermag beállításait tartalmazó állományba ezeket a sorokat kell megadni: device snd_sbc device snd_sb16 valamint a /boot/device.hints állományba ezeket: hint.sbc.0.at="isa" hint.sbc.0.port="0x220" hint.sbc.0.irq="5" hint.sbc.0.drq="1" hint.sbc.0.flags="0x15" Ekkor a kártya a 0x220 I/O portot és 5 IRQ-t használja. A /boot/device.hints állományban alkalmazott felírási módról bõvebben a &man.sound.4;, valamint a kérdéses meghajtó man oldalán tájékozódhatunk. A fentiekben bemutatott beállítások alapértelmezettek, néhány esetben azonban a kártyánknak megfelelõen meg kell változtatnunk az IRQ és egyéb értékeket. Errõl a kártyáról konkrétan a &man.snd.sbc.4; man oldalon olvashatunk részletesebben. A hangkártya kipróbálása Miután újraindítottuk a számítógépünket a módosított rendszermaggal, vagy miután betöltöttük a szükséges modult, a hangkártyának valahogy így kell megjelennie a rendszerünk üzenetpufferében (&man.dmesg.8;): pcm0: <Intel ICH3 (82801CA)> port 0xdc80-0xdcbf,0xd800-0xd8ff irq 5 at device 31.5 on pci0 pcm0: [GIANT-LOCKED] pcm0: <Cirrus Logic CS4205 AC97 Codec> A hangkártyánk állapota a /dev/sndstat állományon keresztül ellenõrizhetõ: &prompt.root; cat /dev/sndstat FreeBSD Audio Driver (newpcm) Installed devices: pcm0: <Intel ICH3 (82801CA)> at io 0xd800, 0xdc80 irq 5 bufsz 16384 kld snd_ich (1p/2r/0v channels duplex default) Ez a kiírás rendszerünként eltérhet. Ha nem látunk semmilyen pcm0 eszközt, akkor menjünk vissza és nézzük át újra, pontosan mit is csináltunk. Vizsgáljuk át a rendszermagunk beállításait tartalmazó állományt és gyõzõdjünk meg róla, hogy a megfelelõ meghajtót adtuk meg. Az itt felmerülõ gyakori gondokkal a foglalkozik. Ha azonban minden remekül haladt, akkor most már van egy mûködõ hangkártyánk. Ha rendesen összekapcsoltuk hangkártyánkat a CD- vagy DVD-meghajtónk audio csatlakozásával, akkor tegyünk egy CD-t a meghajtóba és kezdjük el játszani a &man.cdcontrol.1; paranccsal: &prompt.user; cdcontrol -f /dev/acd0 play 1 Az olyan alkalmazások, mint például az audio/workman, ehhez egy sokkal barátságosabb felületet nyújtanak. Az MP3 formátumú állományok meghallgatásához pedig minden bizonnyal jól fog jönni egy olyan alkalmazás is, mint például az audio/mpg123. A kártyát úgy is tesztelhetjük, ha az alábbihoz hasonló módon adatokat küldünk a /dev/dsp állományba: &prompt.user; cat állománynév > /dev/dsp ahol az állománynév tetszõleges állomány neve lehet. A parancs hatására valamilyen zajt kell hallanunk, és ez egyben meg is erõsíti, hogy a hangkártyánk mûködik. A hangkártyánk csatornáinak jellemzõit a &man.mixer.8; paranccsal állíthatjuk. Errõl további részleteket a &man.mixer.8; man oldalon olvashatunk. Gyakori problémák eszközleíró I/O port IRQ DSP Hiba Megoldás sb_dspwr(XX) timed out Nem állítottuk be jól az I/O portot. bad irq XX Nem állítottuk be jól az IRQ értékét. Gondoskodjunk róla, hogy a beállított érték megegyezik a hangkártyánkéval. xxx: gus pcm not attached, out of memory Nincs elég memória az eszköz használatához. xxx: can't open /dev/dsp! A fstat | grep dsp parancs kiadásával ellenõrizzük, hogy valamelyik alkalmazás használja-e már az eszközt. Gyakori bajkeverõ az esound és a KDE hangtámogatása. Munish Chopra Írta: Több hangforrás kihasználása Gyakoran szükségünk lehet több hangforrás egyidejû használatára, fõleg olyankor, amikor az esound vagy az artsd bizonyos alkalmazásokkal nem hajlandó megosztani a hangeszközt. A &os; ezt a virtuális hangcsatornák használatával oldja meg, amit a &man.sysctl.8; eszközön keresztül tudunk engedélyezni. Amikor a rendszermagban virtuális csatornák használatával keverünk, akkor lényegében képesek vagyunk a hangkártyánk által egyszerre játszható hangok számát megtöbbszörözni. A virtuális csatornák számának beállításához a sysctl két változóját kell módosítanunk, amelyet root felhasználóként így tehetünk meg: &prompt.root; sysctl dev.pcm.0.play.vchans=4 &prompt.root; sysctl dev.pcm.0.rec.vchans=4 &prompt.root; sysctl hw.snd.maxautovchans=4 A fenti példa négy virtuális csatornát hoz létre, ami egészen jellemzõ a mindennapi használatban. A dev.pcm.0.play.vchans és dev.pcm.0.rec.vchans a pcm0 eszköz lejátszásra és felvételre használt virtuális csatornáinak számát adja meg, amelyet az eszköz csatlakoztatása után tudunk beállítani. A hw.snd.maxautovchans az új eszközhöz tartozó virtuális csatornákat adja meg, ami akkor állítódik be, amikor a &man.kldload.8; paranccsal csatlakoztatjuk. Mivel a pcm modul a többi eszközmeghajtótól függetlenül töltõdik be, ezért a hw.snd.maxautovchans azt tárolja, hogy a késõbb hozzá csatlakozó eszközök mennyi virtuális csatornát fognak majd kapni. Errõl részletesebben a &man.pcm.4; man oldalon olvashatunk. A használatban levõ eszközöknél nem tudjuk megváltoztatni a virtuális csatornák számát. Ehhez elõször le kell állítanunk az eszközt használó összes programot, tehát a zenelejátszókat és hangdémonokat. Amennyiben nem használjuk ki a &man.devfs.5; által nyújtott lehetõségeket, az összes alkalmazásnak a /dev/dsp0.x eszközre kell mutatnia, ahol az x értéke 0-tól 3-ig terjedhet attól függõen, hogy a dev.pcm.0.rec.vchans értékét a fenti példához hasonlóan 4-re állítottuk-e. A &man.devfs.5; megoldását használó rendszerek esetén ez a folyamat automatikusan lezajlik, tehát az összes /dev/dsp eszközre irányuló kérés magától átirányítódik. Josef El-Rayes Írta: A keverõ alapértelmezett értékeinek beállítása A keverõben megjelenõ különbözõ csatornák alapértékei a &man.pcm.4; meghajtó forráskódjában huzalozottan találhatóak meg. Számos alkalmazás és démon segít két hívás közt megõrizni a keverõben beállított értékeket, azonban ez nem teljesen egy tiszta megoldás. A meghajtó szintjén is be tudjuk állítani a keverõ alapértékeit — ezt a /boot/device.hints állomány megfelelõ módosításával érhetjük el, például: hint.pcm.0.vol="50" Ezzel a &man.pcm.4; modul betöltése során a hangerõ (volume) csatorna alapértelmezett értéket 50-re állítjuk. Chern Lee Írta: MP3 Az MP3 (MPEG Layer 3 Audio) használatával közel CD minõségû hangot lehet elérni, ezért a mi &os; munkaállomásunk sem maradhat ki elõnyeinek élvezetébõl. MP3 lejátszók Az XMMS (X Multimedia System) kiemelkedõen a legnépszerûbb X11-es MP3 lejátszó. Mivel az XMMS grafikus felhasználói felülete szinte teljesen megegyezik a Nullsoft Winampjának felületével, ezért még a Winamp skinjeit is használhatjuk vele. Az XMMS-ben ezenkívül még a natív pluginek támogatását is megtalálhatjuk. Az XMMS a multimedia/xmms portból vagy csomagból telepíthetõ. Az XMMS használatára könnyû ráérezni: megtaláljuk benne a lejátszandó számok listáját, egy grafikus hangszínszabályzót és még sok minden mást. Akik már ismerik a Winamp mûködését, azok az XMMS-t is egyszerûnek érzik majd. Mellette az audio/mpg123 port egy másik, parancssoros MP3 lejátszót kínál fel. Az mpg123 futtatásához paraméterként meg kell adnunk a hangeszközt és lejátszandó MP3 állományt. Ha a hangeszközünk a /dev/dsp1.0 és a IzéMizé-Sláger.mp3 nevû MP3 állományt akarjuk rajta lejátszatni, akkor a következõt kell begépelnünk: &prompt.root; mpg123 -a /dev/dsp1.0 IzéMizé-Sláger.mp3 High Performance MPEG 1.0/2.0/2.5 Audio Player for Layer 1, 2 and 3. Version 0.59r (1999/Jun/15). Written and copyrights by Michael Hipp. Uses code from various people. See 'README' for more! THIS SOFTWARE COMES WITH ABSOLUTELY NO WARRANTY! USE AT YOUR OWN RISK! Playing MPEG stream from IzéMizé-Sláger.mp3 ... MPEG 1.0 layer III, 128 kbit/s, 44100 Hz joint-stereo Sávok lementése CD-rõl Mielõtt MP3 formátumba tömörítenénk egy CD-t vagy annak egy sávját, a CD-n található audio adatot valahogy le kell tudnunk szedni a merevlemezre. Ezt úgy tehetjük meg, ha a nyers CDDA (CD Digital Audio) adatot WAV formátumú állományokba mentjük. A sysutils/cdrtools csomag részeként elérhetõ cdda2wav segédprogrammal tudjuk a CD-ken levõ audio és a hozzájuk tartozó egyéb információkat leszedni. A meghajtóban levõ CD teljes tartalmát (root felhasználóként) a következõ parancs kiadásával lehet (sávonként) különálló WAV állományokba menteni: &prompt.root; cdda2wav -D 0,1,0 -B A cdda2wav ismeri az ATAPI (IDE) CD-meghajtókat, használatukhoz a SCSI egység sorszáma helyett az eszköz nevét kell megadni. Tehát például így szedjük le egy IDE-meghajtóról a 7. sávot: &prompt.root; cdda2wav -D /dev/acd0 -t 7 A a 0,1,0 sorszámú SCSI eszközre utal, ami megfelel cdrecord -scanbus parancs eredményének. Az egyes sávok lementéséhez a kapcsoló használható: &prompt.root; cdda2wav -D 0,1,0 -t 7 A példa szerint a zenei CD-rõl a hetedik sávot szedjük le. Egyszerre több sávot, például az elsõtõl a hetedikig, egy tartomány megadásával menthetünk le: &prompt.root; cdda2wav -D 0,1,0 -t 1+7 A &man.dd.1; segédprogram is használható ATAPI eszközökön levõ hangsávok kimentéséhez. Ennek lehetõségérõl részletesebben a ban olvashatunk. MP3 állományok tömörítése Az MP3 állomány tömörítésére manapság a legtöbben a lame elnevezésû kódolót választják. A portfában a lame az audio/lame helyen található meg. Az elõbb kimentett WAV állományok felhasználásával az alábbi paranccsal tudjuk átalakítani a audio01.wav állományt audio01.mp3 állománnyá: &prompt.root; lame -h -b 128 \ --tt "Izé dal címe" \ --ta "Izé-mizé elõadó" \ --tl "Izé-mizé album" \ --ty "2001" \ --tc "Leszedte és tömörítette: Izé" \ --tg "Mûfaj" \ audio01.wav audio01.mp3 A 128 kbites tömörítés a gyakorlatban leginkább használt kódolási arány, sokan azonban a sokkal jobb minõségû 160 vagy 192 kbites tömörítést szeretik. Minél nagyobb a kódolási arány, annál több helyet fog foglalni a keletkezõ MP3 állomány — habár a minõsége is jobb lesz. A kapcsoló alkalmazásával tudjuk aktivizálni a jobb minõségû de valamivel lassabb módot. A kezdetû paraméterek ID3 tageket adnak meg, amelyek segítségével az MP3 állományokba rájuk vonatkozó információkat tudunk beágyazni. A tömörítés további beállításairól a lame man oldalán tájékozódhatunk. MP3 állományok kitömörítése Ha MP3 formátumú állományokat szeretnénk audio CD-re írni, akkor ehhez elõször tömörítetlen WAV formátumba kell ezeket alakítanunk. Az XMMS és az mpg123 is egyaránt lehetõséged ad az MP3 állományok kitömörítésére. Lemezre írás az XMMS-sel: Indítsuk el az XMMS alkalmazást. Az XMMS menüjének felhozásához kattinsunk jobb gombbal az ablakjára. Válasszuk az Options almenüben található Preference menüpontot. Változtassuk meg az Output Plugin beállítást a Disk Writer Plugin értékre. Nyomjunk a Configure gombra. Írjuk be (vagy válasszuk ki a Browse gombbal) a könyvtárat, ahová majd a kitömörített állományok kerülnek. Az eddig megszokottak szerint töltsük be az XMMS-be az MP3 állományt, állítsuk 100%-ra a hangerõt és kapcsoljuk ki a hangszínszabályzót (EQ, equalizer). Nyomjuk le a Play gombot — úgy fog tûnni, mintha az XMMS játszaná az MP3 állományt, de nem hallunk semmit. Ekkor a tartalmát állományba menti. Mikor befejeztük a kitömörítést, ne felejtsük el visszaállítani az Output Plugin értékét az alapértelmezettre. Írás a szabványos kimenetre az mpg123-mal: Futtassuk le a mpg123 -s audio01.mp3 > audio01.pcm parancsot. Az XMMS az állományokat WAV formátumban írja, miközben az mpg123 nyers PCM hangadatokat képez belõlük. A cdrecord használata során mind a két formátumból hozhatóak létre audio CD-k. A nyers PCM a &man.burncd.8; programmal használható. Amikor WAV állományokkal dolgozunk, minden egyes sáv elején egy apró kattanást hallhatunk: ez a WAV állomány fejléce lesz. A (audio/sox portból vagy csomagból telepíthetõ) SoX segédprogrammal a WAV formátumú állományok fejléce pillanatok alatt eltávolítható: &prompt.user; sox -t wav -r 44100 -s -w -c 2 track.wav track.raw A CD-írók &os; alatti használatával kapcsolatban olvassuk el a t. Ross Lippert Írta: Videók lejátszása A videolejátszás egy nagyon friss és gyorsan fejlõdõ alkalmazási terület. Legyünk türelmesek, ez nem minden fog annyira könnyen menni, mint a hangok esetében. A kezdéshez nem árt tudnunk, hogy a videokártyánk milyen gyártmányú és milyen chipet használ. Míg az &xorg; és az &xfree86; számos különféle videokártyát ismer, csupán töredékükkel lehet jó lejátszási teljesítményt elõhozni. Az X11 futtatása közben az &man.xdpyinfo.1; parancs kiadásával kérdezhetjük le az X szervertõl a kártyánk használatával elérhetõ kiterjesztéseket. Érdemes a kezünk ügyében tartani egy rövidke MPEG formátumú állományt, amellyel majd ki tudjuk próbálni a különféle lejátszókat és azok beállításait. Mivel egyes DVD lejátszók alapértelmezés szerint a /dev/dvd helyen keresik a lejátszandó DVD eszközt, vagy egyszerûen csak így írták meg ezeket mindenképpen hasznos lehet, ha szimbolikus linkeket hozunk létre a megfelelõ eszközökre: &prompt.root; ln -sf /dev/acd0 /dev/dvd &prompt.root; ln -sf /dev/acd0 /dev/rdvd A &man.devfs.5; mûködése miatt azonban ezek a kézzel létrehozott linkek az újraindítás után már nem maradnak meg. A szimbolikus linkeket a rendszer minden egyes indulásakor úgy tudjuk automatikusan létrehozni, hogy ha az /etc/devfs.conf állományba felvesszük az alábbi sort: link acd0 dvd link acd0 rdvd Emellett a DVD-k titkosításának feloldása, mely a DVD-meghajtók speciális funkcióit igényli, a DVD eszközökön írási jogot is igényel. Az X11 osztott memóriát kezelõ felületének gyorsításához javasolt néhány &man.sysctl.8; változó értékének megnövelése is: kern.ipc.shmmax=67108864 kern.ipc.shmall=32768 A megjelenítõ képességeinek megállapítása XVideo SDL DGA Több különbözõ úton lehet X11 alatt videókat nézni, de ennek tényleges módját igazából a rendelkezésre álló hardver határozza meg. Az itt leírt módszerek által kihozható minõség hardverenkét eltérhet. Másodsorban a videók megjelenítése az X11-ben az utóbbi idõben igen nagy hangsúlyt kapott, ezért az &xorg; és az &xfree86; minden egyes változatával jelentõsen javulhat a helyzet ezen a téren. A videók megjelenítésére használt gyakori felületek: X11: az X11 normális kimenete osztott memórián keresztül XVideo: az X11 felületének kiterjesztése, ami tetszõleges X11 által kirajzolható objektum esetén támogat videót SDL: a Simple Directmedia Layer DGA: a Direct Graphics Access (közvetlen grafikus hozzáférés) SVGAlib: alacsonyszintû konzolos grafikus réteg XVideo Az &xorg; és az &xfree86; 4.X rendelkezik egy XVideo (avagy Xvideo, Xv, xv) elnevezésû kiterjesztéssel, amelyen keresztül egy speciális gyorsítás segítségével a kirajzolható objektumokban közvetlenül meg tudunk jeleníteni videókat. Ezzel a kiterjesztéssel még a gyengébb gépeken is nagyon jó minõségû lejátszást tudunk elérni. A kiterjesztés mûködésérõl az xvinfo parancs kiadásával gyõzõdhetünk meg: &prompt.user; xvinfo Ha a parancs eredménye ehhez hasonló, akkor a kártyánk támogatja az XVideót: X-Video Extension version 2.2 screen #0 Adaptor #0: "Savage Streams Engine" number of ports: 1 port base: 43 operations supported: PutImage supported visuals: depth 16, visualID 0x22 depth 16, visualID 0x23 number of attributes: 5 "XV_COLORKEY" (range 0 to 16777215) client settable attribute client gettable attribute (current value is 2110) "XV_BRIGHTNESS" (range -128 to 127) client settable attribute client gettable attribute (current value is 0) "XV_CONTRAST" (range 0 to 255) client settable attribute client gettable attribute (current value is 128) "XV_SATURATION" (range 0 to 255) client settable attribute client gettable attribute (current value is 128) "XV_HUE" (range -180 to 180) client settable attribute client gettable attribute (current value is 0) maximum XvImage size: 1024 x 1024 Number of image formats: 7 id: 0x32595559 (YUY2) guid: 59555932-0000-0010-8000-00aa00389b71 bits per pixel: 16 number of planes: 1 type: YUV (packed) id: 0x32315659 (YV12) guid: 59563132-0000-0010-8000-00aa00389b71 bits per pixel: 12 number of planes: 3 type: YUV (planar) id: 0x30323449 (I420) guid: 49343230-0000-0010-8000-00aa00389b71 bits per pixel: 12 number of planes: 3 type: YUV (planar) id: 0x36315652 (RV16) guid: 52563135-0000-0000-0000-000000000000 bits per pixel: 16 number of planes: 1 type: RGB (packed) depth: 0 red, green, blue masks: 0x1f, 0x3e0, 0x7c00 id: 0x35315652 (RV15) guid: 52563136-0000-0000-0000-000000000000 bits per pixel: 16 number of planes: 1 type: RGB (packed) depth: 0 red, green, blue masks: 0x1f, 0x7e0, 0xf800 id: 0x31313259 (Y211) guid: 59323131-0000-0010-8000-00aa00389b71 bits per pixel: 6 number of planes: 3 type: YUV (packed) id: 0x0 guid: 00000000-0000-0000-0000-000000000000 bits per pixel: 0 number of planes: 0 type: RGB (packed) depth: 1 red, green, blue masks: 0x0, 0x0, 0x0 Az XVideo nem mindegyik implementációjában vannak jelen a felsorolt formátumok (YUV2, YUV12 stb.), ami viszont néhány lejátszó számára akadályokat jelenthet. Amennyiben viszont ezt látjuk: X-Video Extension version 2.2 screen #0 no adaptors present Akkor a kártyánk nem rendelkezik XVideo támogatással. Ha az XVideo nem támogatott a kártyánk számára, akkor az csupán csak annyit jelent, hogy a gépünknek nehéz dolga lesz a videók megjelenítéséhez szükséges számítási kapacitás kiszolgálásában. Azonban a videokártyánktól és processzorunktól függõen még így is kielégítõ eredményt tudunk elõcsalni. Ekkor viszont minden bizonnyal érdemes lesz átolvasnunk ban, hogyan tudjuk növelni a teljesítményét. A Simple Directmedia Layer A Simple Directmedia Layer, vagy SDL, eredetileg a µsoft.windows;, BeOS és &unix; közti hordozhatóságot szándékozta megvalósítani, aminek segítségével a hangot és grafikát hatékonyan használni tudó alkalmazások hozhatóak létre. Az SDL által nyújtott réteg a hardver olyan alacsonyszintû absztrakcióját öleli fel, amely gyakran még az X11 felületénél is hatékonyabb. Az SDL a devel/sdl12 helyen található. Direct Graphics Access (Közvetlen grafikus hozzáférés) A közvetlen grafikus hozzáférés az X11 egy olyan kiterjesztése, ami lehetõvé teszi a programok számára az X szerver megkerülését és így közvetlenül a videokártya memóriáját képesek elérni. Mivel a megosztás hatékony megvalósításához ez nagyban építkezik alacsonyszintû leképzési mûveletekre, ezért az ilyet használó programokat root felhasználóként kell futtatni. A DGA kiterjesztés a &man.dga.1; segítségével tesztelhetõ és mérhetõ. A dga parancs kiadása után minden billentyû lenyomására megváltoztatja a képernyõn látható színeket. A kilépéshez a q billentyût kell lenyomni. A videókkal foglalkozó portok és csomagok videoportok videocsomagok Ebben a szakaszban a &os; Portgyûjteményébõl a videók lejátszására alkalmas programokat vesszük számba. A videolejátszás nagyon gyorsan fejlõdõ terület, ezért az itt említett különbözõ alkalmazások képességei az itt leírtaktól némileg eltérhetnek. Elõször is fontos tisztában lennünk azzal, hogy számos &os;-n futó videoalkalmazás eredetileg linuxos alkalmazásként indult, és közülük sokan még csak béta minõségûek. Íme a &os;-n is megtalálható videocsomagokkal kapcsolatos néhány olyan gond, amivel esetleg összefuthatunk: Az egyik alkalmazás nem képes visszajátszani olyan állományt, amit egy másik alkalmazás hozott létre. Az alkalmazás nem képes visszajátszani a saját maga által készített állományokat. Ugyanazon az alkalmazás két különbözõ gépen, amikor mind a kettõn az adott konfigurációra fordítjuk le, ugyanazt az állományt másképpen játssza vissza. Egy olyan látszólag egyértelmû szûrõ, mint például a kép átméretezése, a hibás átmértezõ rutin miatt nagyon csúnya eredményt produkál. Az alkalmazás gyakran elszáll. A porthoz nem találjuk a dokumentációt, egyedül csak az interneten vagy a port work könyvtárában van. Sok alkalmazás a linuxizmus jeleit is hordozza, vagyis gondok adódhatnak abból, hogy a szerzõk az alkalmazások mûködtetéséhez a Linux rendszermag és a különféle terjesztésekben megtalálható módosított szabványos könyvtárak különlegességeit használják ki. Ezeket a portok karbantartói nem mindig észlelik és javítják ki, ami miatt az alábbiak bármikor bekövetkezhetnek: A processzor jellemzõit a /proc/cpuinfo állományon keresztül állapítják meg. A szálak helytelen használatuk miatt a program befejezõdésekor összeakadnak. Az alkalmazással gyakran együtt használt egyéb alkalmazások még nem nincsenek benne a &os; Portgyûjteményében. Az ilyen alkalmazások fejlesztõi a hordozhatóság javításával és a problémák megoldásával kapcsolatban eddig mindig igyekeztek együttmûködni a portok karbantartóival. MPlayer Az MPlayer az utóbbi idõben felbukkant, gyorsan fejlõdõ videolejátszó. Fejlesztõinek célja a sebesség és rugalmasság a Linux, illetve más &unix; rendszereken. A kezdeményezés abból fakadt, hogy a fejlesztés mögött álló csapat alapítójának elege lett az akkoriban elérhetõ lejátszók teljesítményébõl. Mondhatnánk, hogy ez a program feláldozta a grafikus felületet az áramvonalas kialakításért, azonban ha hozzászokunk a parancssori beállításokhoz és a billentyûkön keresztüli vezérléshez, remekül mûködik. Az MPlayer lefordítása MPlayer fordítása Az MPlayer a multimedia/mplayer helyen található. A program a fordítási folyamat során elvégez számos hardverellenõrzést, aminek eredményeképpen az egyik rendszeren fordított program nem vihetõ a másikra. Ezért különösen fontos portból fordítani és nem pedig bináris csomagot használni. Mindezek mellett a Makefile állományban még számos, a make parancsnak a fordítás megkezdésekor átadható beállítást találhatunk: &prompt.root; cd /usr/ports/multimedia/mplayer &prompt.root; make N - O - T - E Take a careful look into the Makefile in order to learn how to tune mplayer towards you personal preferences! For example, make WITH_GTK1 builds MPlayer with GTK1-GUI support. If you want to use the GUI, you can either install /usr/ports/multimedia/mplayer-skins or download official skin collections from http://www.mplayerhq.hu/homepage/dload.html Az üzenet fordítása: F - I - G - Y - E - L - E - M Az mplayert személyes igényeinekhez úgy tudjuk igazítani, ha figyelmesen átnézzük a Makefile állományt! Például a WITH_GTK1 megadásával az MPlayer GTK1 alapú grafikus felülettel jön létre. A grafikus felület használatához telepítenünk kell a /usr/ports/multimedia/mplayer-skins portot is, vagy letölteni a hivatalos skingyûjteményt a http://www.mplayerhq.hu/homepage/dload.html oldalról. A port alapbeállításai a legtöbb felhasználó számára megfelelõek, habár az Xvid kódek használatához meg kell adnunk a WITH_XVID beállítást. Rajta kívül még az alapértelmezett DVD eszközt is érdemes megadni a WITH_DVD_DEVICE beállítással, amelynek alapértéke a /dev/acd0. A leírás elkészítésének idõpontjában az MPlayer portja létrehozza a HTML dokumentációt és a két végrehajtható állományt: az mplayer lejátszót és videók újrakódolásáért felelõs mencoder segédprogramot. Az MPlayer HTML dokumentációja nagyon közlékeny, és ha az olvasó nem találná valamelyik videohardver vagy felület leírását ebben a fejezetben, akkor ez a dokumentáció mindenképpen egy hasznos olvasnivalónak bizonyul. Ha a &unix;-ok alatt elérhetõ videotámogatás leírását keressük, határozottan megéri idõt szánni az MPlayer dokumentációjának alapos végigolvasására. Az MPlayer használata MPlayer használata Az MPlayer használatához a felhasználói könyvtárunkban rendelkeznünk kell egy .mplayer elnevezésû könyvtárral. Ezt a következõ paranccsal tudjuk létrehozni: &prompt.user; cd /usr/ports/multimedia/mplayer &prompt.user; make install-user Az mplayer parancssori paraméterei a hozzátartozó man oldalon találhatóak meg, valamint mindezek a HTML dokumentációban még részletesebben. Ebben a szakaszban csupán néhányukat mutatjuk be. Egy állomány, mint például a tesztvideo.avi, a beállításával játszható le a különbözõ felületeken: &prompt.user; mplayer -vo xv tesztvideo.avi &prompt.user; mplayer -vo sdl tesztvideo.avi &prompt.user; mplayer -vo x11 tesztvideo.avi &prompt.root; mplayer -vo dga tesztvideo.avi &prompt.root; mplayer -vo 'sdl:dga' tesztvideo.avi Érdemes az itt felsorolt konfigurációk mindegyikét kipróbálni, mivel az egymáshoz mért teljesítményük rengeteg tényezõn múlik, de közülük talán maga a hardver a legjelentõsebb. A DVD-k lejátszásához cseréljük ki a tesztvideo.avi paramétert a paraméterekkel, ahol az N a lejátszandó fejezet sorszáma, valamint az ESZKÖZ a DVD-hez tartozó eszközleíró. Például így tudjuk elkezdeni /dev/dvd eszközrõl a 3. fejezet lejátszását: &prompt.root; mplayer -vo xv dvd://3 -dvd-device /dev/dvd A port fordítása során a WITH_DVD_DEVICE paraméter segítségével megadható az alapértelmezett DVD eszköz, amely alapból a /dev/acd0. Errõl többet a port Makefile állományában találhatunk. A leállításhoz, szüneteltetéshez, továbblépéshez és többi hasonló funkcióhoz tartozó billentyûket a mplayer -h parancs kimenetébõl vagy a man oldal elolvasásából deríthetjük ki. A lejátszáshoz tartozó néhány viszonylag fontos beállítás: az teljesképernyõs módra vált, valamint a segít növeli a teljesítményt. A lejátszáskor kiadandó parancs túlburjánzását el tudjuk kerülni, ha létrehozunk egy .mplayer/config állományt és itt állítjuk be a gyakori opciókat: vo=xv fs=yes zoom=yes Végezetül megemlítjük, hogy az mplayer segítségével a DVD-n található fejezeteket ki tudjuk menteni .vob állományokba. A DVD második fejezetének kimentéséhez gépeljük be ezt: &prompt.root; mplayer -dumpstream -dumpfile out.vob dvd://2 -dvd-device /dev/dvd A parancs eredményeképpen keletkezõ out.vob állomány formátuma MPEG lesz, amit a fejezetben bemutatott további csomagokkal tudunk feldolgozni. mencoder mencoder A mencoder használatának megkezdése elõtt javasolt alaposan beleásnunk magunkat a HTML dokumentációba és megismerkednünk az alapvetõ beállításaival. Van külön man oldala is, azonban a HTML leírás nélkül önmagában ez nem túl sokat ér. Megszámlálhatatlan úton és módon növelhetõ benne a minõség, csökkenthetõ a kódolási arány, változtatható a formátum, és ezen apró finomságok felelõsek a jó vagy éppen a rossz teljesítményért. A témába néhány példa bemutatásával igyekszünk beavatni az olvasót. Elõször vegyünk egy egyszerû másolást: &prompt.user; mencoder bemenõ.avi -oac copy -ovc copy -o eredmény.avi A parancssori paraméterek helytelen kombinációja olyan állományokat eredményezhet, amelyeket még maga az mplayer sem képes lejátszani. Ezért ha csak le akarunk szedni egy állományt, akkor maradjunk meg az mplayer opciójánál. A bemenõ.avi állományt MPEG4 video- és MPEG3 hangtömörítéssel (amihez kell majd a audio/lame) így tudjuk lekódolni: &prompt.user; mencoder bemenõ.avi -oac mp3lame -lameopts br=192 \ -ovc lavc -lavcopts vcodec=mpeg4:vhq -o eredmény.avi Ezzel az mplayer és xine programok számára is egyaránt lejátszható állomány jön létre. A DVD fejezeteit úgy tudjuk közvetlenül kódolni, ha a parancssorban kicseréljük a bemenõ.avi állományt az beállításra, illetve ha a programot root felhasználóként futtatjuk. De mivel elsõre általában ritkán vagyunk elégedettek a kódolással, érdemes elõször inkább lementeni az egész fejezetet egy állományba, majd azon dolgozni. A xine videolejátszó A xine lejátszó mögött projekt célja nem egy mindenható alkalmazás létrehozása, hanem inkább olyan újrahasznosítható függkönyvtárak és egy moduláris felépítésû program kifejlesztése, amelyeket pluginekkel tudunk kiegészíteni. A multimedia/xine helyen portként, valamint csomagként is elérhetõ. A xine itt-ott még valamelyest durva, de mindenképpen egy dicséretes kezdeményezés. A xine a gyakorlatban egyaránt egy erõs processzort és gyors videokártyát kíván, vagy az XVideo kiterjesztés támogatását. A grafikus felhasználói felülete ugyan használható, de még kicsit esetlen. Az írás pillanatában az xine mellé még nem kapunk olyan modult, amivel le tudnánk játszani a CSS kódolású DVD-ket. Léteznek azonban olyan külsõs modulok, amelyekkel meg lehet valósítani ezt a feladatot, azonban a &os; Portgyûjteményében ezeket még nem találhatjuk meg. A xine az MPlayerhez képes többet tesz a felhasználóért, azonban ezzel egyidõben el is veszi tõle a finomhangolás lehetõségét. A xine legjobban az XVideót ismerõ felületeken teljesít. A xine alapértelmezés szerint grafikus felülettel indul, ahol a menük segítségével tudunk megnyitni egy adott állományt: &prompt.user; xine Vagy a grafikus felület használata nélkül kiadhatjuk közvetlenül is az állomány lejátszását: &prompt.user; xine -g -p kedvencmozim.avi A transcode A transcode nem egy újabb lejátszó, hanem a video- és audio állományok újratömörítésére használható programok gyûjteménye. A transcode segítségével a szabványos be- és kimeneten keresztül parancssoros programokkal képesek vagyunk videoállományokat összefûzni, megjavítani. A multimedia/transcode port fordítása során temérdek beállítást adhatunk meg, amelyek közül az alábbi parancsban foglaljuk össze az általunk javasolandókat: &prompt.root; make WITH_OPTIMIZED_CFLAGS=yes WITH_LIBA52=yes WITH_LAME=yes WITH_OGG=yes \ WITH_MJPEG=yes -DWITH_XVID=yes Ezek a beállítások a legtöbb felhasználó számára elegendõek. A transcode képességeinek illusztrálásához lássunk egy példát, amiben megmutatjuk, hogyan kell egy DivX állományt PAL szabványú MPEG-1 formátumú (PAL VCD) állománnyá alakítani: &prompt.user; transcode -i bemenõ.avi -V --export_prof vcd-pal -o output_vcd &prompt.user; mplex -f 1 -o eredmény_vcd.mpg eredmény_vcd.m1v eredmény_vcd.mpa Az eredményül keletkezõ eredmény_vcd.mpg MPEG állomány akár már játszható is MPlayerrel. Ha az állományt kiírjuk egy írható CD-re, akkor ezzel video CD-t is létre tudunk hozni, amihez viszont szükségünk van mind a multimedia/vcdimager és sysutils/cdrdao programokra. A transcode parancsnak van saját man oldala, azonban ehelyett a transcode wikiben érdemes inkább további információkat és példákat keresni. Ajánlott olvasmányok A &os;-hez tartozó videoszoftverek nagyon gyorsan fejlõdnek. Könnyen elképzelhetõ, hogy az imént tárgyalt problémák legtöbbje a közeljövõben hamarosan megoldódik. Addig viszont bárkinek, aki a legtöbbet szeretné kihozni a &os; audio- és video lehetõségeibõl, rengeteg leírás és dokumentáció elolvasása alapján kell összecsiszolnia a különbözõ beállításokat, és csak néhány alkalmazás mellett érdemes kitartania. Ebben a szakaszban igyekszünk segíteni az olvasónak megtalálni az ilyen jellegû információkat. Az MPlayer dokumentációja szakmai szempontból igen közlékeny. Ezt mindenkinek érdemes elolvasnia, aki a késõbbiekben magasabb szakmai szinten akar foglalkozni a &unix;-os videózással. Az MPlayer levelezési listája viszont alig tolerálja a dokumentációt rendesen el nem olvasó emberek kérdéseit, ezért minden egyes hiba bejelentése elõtt lehetõleg rendesen nézzük át a dokumentáció odavágó részeit. A xine HOGYAN egyik külön fejezetében az összes lejátszó esetén érvényesíthetõ teljesítménynövelési módszereket mutat be. Végül íme néhány ígéretes alkalmazás, amelyeket érdemes kipróbálnunk: Avifile, ami egyben a multimedia/avifile port Ogle, ami a multimedia/ogle port Xtheater multimedia/dvdauthor, egy nyílt forráskódú DVD-tartalom szerkesztõ Josef El-Rayes Eredetileg írta: Marc Fonvieille Kiegészítette, továbbfejlesztette: TV kártyák beállítása TV kártyák Bevezetés A TV kártyák segítségével kábeles vagy antennás televízióadásokat tudunk nézni a számítógépünkön. A legtöbbjük RCA vagy S-video bemenettel rendelkezik, valamint néhányukon még FM rádiókészülék is megtalálható. A &os; a &man.bktr.4; meghajtón keresztül a Brooktree Bt848/849/878/879, illetve a Conexant CN-878/Fusion 878a típusú, PCI-os videorögzító chipeket ismeri. Ügyelnünk kell arra, hogy a kártyánkon levõ vevõkészülék is használható legyen, amit pedig a &man.bktr.4; man oldalán megtalálható támogatott eszközök listájából ellenõrizhetünk. A meghajtó beállítása A kártyánk használatához be kell töltenünk a &man.bktr.4; meghajtót, ami csupán annyiból áll, hogy a /boot/loader.conf állományhoz hozzáadunk egy ilyen sort: bktr_load="YES" Másik lehetõségünk, ha a TV kártya támogatását statikusan beleépítjük a rendszermagba. Ha ezt a megoldást választjuk, a következõ sorokat kell elhelyeznünk a rendszermag beállításait tartalmazó állományba: device bktr device iicbus device iicbb device smbus A fentebb látható egyéb eszközök megadása azért szükséges, mert a kártya részegységei egy I2C buszon csatlakoznak egymáshoz. Miután beillesztettük a szükséges változtatásokat, fordítsuk le és telepítsük az új rendszermagot. A támogatás hozzáadása után újra kell indítanunk a számítógépünket. A rendszerindítási folyamat során meg kell jelennie a TV kártyánknak is, valahogy így: bktr0: <BrookTree 848A> mem 0xd7000000-0xd7000fff irq 10 at device 10.0 on pci0 iicbb0: <I2C bit-banging driver> on bti2c0 iicbus0: <Philips I2C bus> on iicbb0 master-only iicbus1: <Philips I2C bus> on iicbb0 master-only smbus0: <System Management Bus> on bti2c0 bktr0: Pinnacle/Miro TV, Philips SECAM tuner. Természetesen a fenti üzenetek az aktuális hardvereszközünknek megfelelõen némileg eltérhetnek. Ellenõrizzük, hogy a vevõkészüléket helyesen ismerte-e fel a rendszer. Ha nem sikerült volna, akkor a &man.sysctl.8; és a rendszermag beállításai segítségével még mindig van lehetõségünk állítani rajta. Például, ha egy Philips SECAM vevõkészüléket akarunk beállítani, akkor a rendszermag beállításaihoz még hozzá kell adni a következõ sort: options OVERRIDE_TUNER=6 vagy erre közvetlenül használhatjuk a &man.sysctl.8; programot is: &prompt.root; sysctl hw.bt848.tuner=6 A &man.bktr.4; man oldalán és a /usr/src/sys/conf/NOTES állományban megtalálhatjuk a többi beállítás részletes leírását is. Hasznos alkalmazások A TV kártyánk tényleges használatához azonban még a következõ alkalmazások valamelyikét is telepítenünk kell: A multimedia/fxtv használatával ablakban tévézhetünk, valamint lehetõségünk van kép/audio/video kimentésére is. A multimedia/xawtv az fxtv-hez hasonló lehetõségekkel bíró tévénézõ alkalmazás. A misc/alevt dekódolja és megjeleníti a mûsorhoz kapcsolódó Videotex/Teletext üzeneteket. Az audio/xmradio segítségével az egyes TV kártyákon megtalálható FM rádiókészülékeket tudjuk használatba venni. Az audio/wmtune a rádióvevõkhöz használható hasznos grafikus alkalmazás. Ebben a témában a &os; Portgyûjteményében további érdekes alkalmazások találhatóak még. Hibakeresés Ha bármilyen gond adódna a TV kártyánkkal kapcsolatosan, akkor elõször mindenképpen érdemes megnézni, hogy a rajta levõ videorögzítõ chipet és vevõkészüléket a &man.bktr.4; meghajtó ténylegesen ismeri-e, illetve hogy jól állítottuk-e be. A TV kártyákra irányuló különféle egyéb kérdések és segítség tekintetében érdemes lehet még levelet küldeni a &a.multimedia.name; címére is. Marc Fonvieille Írta: Lapolvasók lapolvasók Bevezetés A &os; lapolvasókhoz a SANE (Scanner Access Now Easy) elnevezésû API (alkalmazásfejlesztõi felület) segítségével képes hozzáférni, amelyet a Portgyûjteményben találhatunk meg. A lapolvasást végzõ hardvereszközök használatához a &os; a SANE mellett még néhány eszközmeghajtóra is támaszkodik. A &os; egyaránt ismeri az SCSI és USB csatlakoztatású lapolvasókat is. Még mielõtt nekikezdenénk a lapolvasó beállításához, bizonyosodjuk meg róla, hogy a SANE támogatja. A SANE által ismert eszközök felsorolásában ellenõrizhetjük a lapolvasónk támogatottságának állapotát. A &os; 8.X elõtti kiadásaiban ezenkívül még a &man.uscanner.4; man oldalon is láthatjuk az ismert USB-s lapolvasók listáját. A rendszermag beállítása A korábbiak értelmében tehát mind a SCSI, mind pedig a USB felületen csatlakozó eszközök támogatottak. A lapolvasónknak megfelelõen eltérõ eszközmeghajtók szükségesek. Beállítás USB felületen A GENERIC rendszermag alapértelmezés szerint tartalmazza az USB-s lapolvasók használatához szükséges eszközmeghajtókat. Ha valamiért azonban mégis saját rendszermagot akarunk használni, akkor ne felejtsük el ellenõrizni, hogy a rendszermag beállításai között megtalálhatóak a következõ sorok: device usb device uhci device ohci device ehci A &os; 8.X elõtti kiadásaiban még a következõ sorra is szükségünk lesz: device uscanner A &os; ezen változataiban a &man.uscanner.4; eszközmeghajtón keresztül tudjuk használni az USB csatolóval rendelkezõ lapolvasókat. A &os; 8.0 változatától kezdõdõen pedig ehhez a &man.libusb.3; függvénykönyvtár nyújt közvetlen támogatást. A megfelelõen elõkészített rendszermag elindítása után csatlakoztassuk az USB-s lapolvasónkat. Ez sor fog megjelenni a rendszer üzenetpufferében (&man.dmesg.8;): ugen0.2: <EPSON> at usbus0 Vagy &os; 7.X rendszerek esetében: uscanner0: EPSON EPSON Scanner, rev 1.10/3.02, addr 2 Ezek az üzenetek elárulják nekünk, hogy a lapolvasóhoz mostantól a használt &os; verziótól függõen a /dev/ugen0.2 vagy a /dev/uscanner0 eszközleíró tartozik. A fenti példában egy &epson.perfection; 1650 típusú USB lapolvasót láthatunk. Beállítás SCSI felületen Ha a lapolvasónk SCSI felületen csatlakozik, fontos tisztában lennünk azzal, hogy pontosan milyen SCSI-vezérlõn keresztül is érhetjük el, ugyanis a rajta található SCSI chipkészletnek megfelelõen kell majd hangolnunk a rendszermag beállításait. A GENERIC rendszermag alapból ismeri a leggyakrabban elõforduló SCSI-vezérlõket. Mindenképpen olvassuk át a NOTES nevû állományt és adjuk hozzá a rendszermag beállításaihoz a megfelelõ sort. A SCSI-kártya meghajtóján kívül még az alábbi beállításokat is meg kell adnunk a rendszermagunk számára: device scbus device pass Ahogy sikerült a rendszermagot sikeresen lefordítani és telepíteni, a rendszer indulása során az üzenetpufferben már láthatjuk is a felismert eszközt: pass2 at aic0 bus 0 target 2 lun 0 pass2: <AGFA SNAPSCAN 600 1.10> Fixed Scanner SCSI-2 device pass2: 3.300MB/s transfers Ha a rendszer indulásakor még nem kapcsoltuk volna be a lapolvasónkat, a &man.camcontrol.8; parancs segítségével késõbb külön kérhetjük a SCSI buszon található eszközök újbóli felderítését: &prompt.root; camcontrol rescan all Re-scan of bus 0 was successful Re-scan of bus 1 was successful Re-scan of bus 2 was successful Re-scan of bus 3 was successful Ekkor a lapolvasó megjelenik a SCSI eszközök felsorolásában: &prompt.root; camcontrol devlist <IBM DDRS-34560 S97B> at scbus0 target 5 lun 0 (pass0,da0) <IBM DDRS-34560 S97B> at scbus0 target 6 lun 0 (pass1,da1) <AGFA SNAPSCAN 600 1.10> at scbus1 target 2 lun 0 (pass3) <PHILIPS CDD3610 CD-R/RW 1.00> at scbus2 target 0 lun 0 (pass2,cd0) A SCSI eszközökrõl további leírásokat a &man.scsi.4; és &man.camcontrol.8; man oldalakon találhatunk. A SANE beállítása A SANE rendszere két részre oszlik: a backendekre (graphics/sane-backends) és a frontendekre (graphics/sane-frontends). Ezek közül maguk a backendek szolgáltatják a lapolvasó hozzáférhetõségét. A SANE által ismert eszközeinek listájából kifürkészhetjük, hogy lapolvasónkat melyik backenden keresztül érhetjük el. Az eszköz megfelelõ használatához döntõ fontosságú megállapítani a hozzátartozó backendet. A frontendek között találjuk meg a lapolvasást felügyelõ grafikus felületeket (mint például az xscanimage). Elsõként telepítsük a graphics/sane-backends portot vagy csomagot. Ezután ellenõrizzük, hogy a SANE felismeri a lapolvasót, és ehhez adjuk ki a sane-find-scanner parancsot: &prompt.root; sane-find-scanner -q found SCSI scanner "AGFA SNAPSCAN 600 1.10" at /dev/pass3 A kimenetében jelzi a felületet, amin a lapolvasó csatlakozik, valamint a hozzátartozó eszközleírót. A gyártó neve és a termék típusa nem minden esetben jelenik meg, de ez nem is annyira fontos. Némely USB-s lapolvasók esetén még egy firmware-t is be kell töltenünk, amirõl bõvebben a backendhez tartozó man oldalokon olvashatunk. Ajánlott még elolvasni a &man.sane-find-scanner.1; és &man.sane.7; man oldalakat is. Most pedig nézzük meg, hogy vajon a frontend is be tudja-e azonosítani a lapolvasónkat. Alapértelmezés szerint a SANE backendjéhez tartozik még egy &man.scanimage.1; nevû segédprogram is, aminek segítségével listázni tudjuk a használható eszközöket és képeket tudunk beolvasni parancssorból. Közülük a kapcsoló listáz: &prompt.root; scanimage -L device `snapscan:/dev/pass3' is a AGFA SNAPSCAN 600 flatbed scanner Vagy ha a ban szereplõ USB lapolvasóval nézzük: &prompt.root; scanimage -L device 'epson2:libusb:/dev/usb:/dev/ugen0.2' is a Epson GT-8200 flatbed scanner Ezt a kimenetet egy &os; 8.X rendszeren kaptuk, ahol a - epson2:libusb:/dev/usb:/dev/ugen0.2 az - eszközhöz tartozó backendet és + 'epson2:libusb:/dev/usb:/dev/ugen0.2' az + eszközhöz tartozó backendet + (epson2) és eszközleírót (/dev/ugen0.2) adja meg. Ha ennek eredményeképpen semmi sem jelenik meg, vagy a &man.scanimage.1; látszólag nem talált semmilyen eszközt, akkor a lapolvasó azonosítása nem sikerült. Ilyen esetekben valószínûleg módosítanunk kell a backend beállításait tartalmazó állományt a használni kívánt lapolvasó eszköz szerint. A backendek beállításait a /usr/local/etc/sane.d/ könyvtárban találjuk. Ez a probléma bizonyos USB-s lapolvasók esetében jelentkezik. Például, ha ban használt USB-s lapolvasónkat &os; 8.X alatt tökéletesen felismeri a rendszer, de a &os; korábbi változatai esetén (ahol a &man.uscanner.4; eszközmeghajtót használják) a sane-find-scanner parancs a következõket adja vissza: &prompt.root; sane-find-scanner -q found USB scanner (UNKNOWN vendor and product) at device /dev/uscanner0 Akkor a lapolvasót sikerült megtalálni, és láthatjuk, hogy USB-n keresztül csatlakozik és a /dev/uscanner0 eszközleíró tartozik hozzá. Most már ellenõrizhetjük a lapolvasó helyes beazonosítását is: &prompt.root; scanimage -L No scanners were identified. If you were expecting something different, check that the scanner is plugged in, turned on and detected by the sane-find-scanner tool (if appropriate). Please read the documentation which came with this software (README, FAQ, manpages). Az üzenet fordítása: Nincs azonosítható lapolvasó. Ha nem erre számítottunk, akkor ellenõrizzük, hogy az eszközt tényleg bekapcsoltuk, csatlakoztattuk és észlelte a sane-find-scanner segédprogram (amennyiben szükséges). Kérjük, olvassa el a szoftverhez tartozó dokumentumtációt (README, FAQ, man oldalak)! Mivel a lapolvasót nem sikerült azonosítani, át kell írnunk a /usr/local/etc/sane.d/epson2.conf állományt. A használt lapolvasó - típusa &epson.perfection; 1650, ezért + típusa &epson.perfection; 1650, ezért hozzá az epson2 backendet fogjuk használni. Ehhez feltétlenül olvassuk el a konfigurációs állományban található megjegyzéseket is. A sorokat igen könnyû átírni: tegyük megjegyzésbe az összes olyat, ahol a lapolvasónk számára nem megfelelõ felületek találhatóak (a mi esetünkben tehát megjegyzésbe fogjuk tenni az összes scsi szóval kezdõdõ sort, hiszen a nekünk USB-s eszközünk van), majd az állomány végére írjuk be a használni kívánt felületet és eszközleírót. Ez ebben a konkrét esetben ennyi lenne: usb /dev/uscanner0 A megfelelõ formátum és a további részletek leírásához ne felejtsük el azonban elolvasni a backend konfigurációs állományában felbukkanó megjegyzéseket és az ide tartozó man oldalt sem. Most már megpróbálkozhatunk újra a lapolvasó azonosításával: &prompt.root; scanimage -L device `epson:/dev/uscanner0' is a Epson GT-8200 flatbed scanner Láthatjuk, hogy az USB-s lapolvasónkat sikerült azonosítani. Nem számít, ha esetleg nem egyezne a valósággal a gyártó vagy a típus megjelölése. Itt a valóban lényeges elem az `epson:/dev/uscanner0' mezõ lesz, melynek a backend és az eszközleíró nevét kell helyesen tartalmaznia. A beállítást akkor zárhatjuk le, miután a scanimage -L parancs képes észlelni a lapolvasót. A eszköz ekkor már készen áll a beolvasásra. Míg a &man.scanimage.1; parancssorból teszi lehetõvé számunkra a lapolvasást, addig érdemesebb a képek olvasását egy grafikus felületen keresztül végeznünk. A SANE egy egyszerû, ám hatékony grafikus felületet ajánl fel ehhez, ez az xscanimage (graphics/sane-frontends). Az Xsane (graphics/xsane) egy másik népszerû grafikus frontend. Segítségével speciális lehetõségeket is kihasználhatunk, mint például többféle képolvasási mód (fénymásoló, fax stb.), színkorrekció, kötegelt beolvasás, stb. Mind a két említett alkalmazás elérhetõ a The GIMP bõvítményeként is. A lapolvasó használatának engedélyezése más felhasználók számára A korábban tárgyalt mûveletek mindegyikét root felhasználóként tudjuk csak végrehajtani. Azonban elõfordulhat, hogy más felhasználók számára is szeretnénk hozzáférést biztosítani a lapolvasóhoz. Ehhez az érintett felhasználóknak a lapolvasóhoz tartozó eszközleíróhoz olvasási és írás joggal kell rendelkezniük. Például az USB-s lapolvasónk a /dev/ugen0.2 eszközleírót használja, amely valójában csak a /dev/usb/0.2.0 eszközleíróra mutató szimbolikus link (ezt gyorsan le tudjuk ellenõrizni, ha megnézzük a /dev könyvtár tartalmát). Az eszközleíró és a rá mutató szimbolikus link rendre a wheel és operator csoportok birtokában van. Ha a pgj nevû felhasználót felvesszük ezekbe a csoportokba, akkor ezáltal hozzá tud majd férni a lapolvasóhoz. Nyilvánvaló biztonsági megfontolásokból azonban kétszer is javasolt meggondolni, mely felhasználókat mely csoportokba vesszük fel, különösen, ha wheel csoportról van szó. Ennél valamivel jobb megoldást kínál, ha létrehozunk külön az USB eszközök használatára vonatkozó csoportot és a lapolvasót ezen csoport tagjainak számára elérhetõvé tesszük. Tehát erre a célra például megalkotjuk a usb csoportot. Ehhez elsõ lépésként a &man.pw.8; parancs segítségével hozzuk létre magát a csoportot: &prompt.root; pw groupadd usb Ezután a /dev/usb/0.2.0 eszközleírót és a rá mutató /dev/ugen0.2 szimbolikus linket kell az usb csoport részére elérhetõvé tennünk, a megfelelõ írási engedélyekkel (0660 vagy 0664) együtt, mivel alapértelmezetten csak a tulajdonosuk (root) tudja írni ezeket. Mindezt úgy tudjuk megtenni, ha az /etc/devfs.rules állományhoz hozzáadjuk a megfelelõ sorokat: [system=5] add path ugen0.2 mode 0660 group usb add path usb/0.2.0 mode 0660 group usb A &os; 7.X változatok - esetén a következõ sorokra lesz - szükségünk (legtöbb esetben a + esetén valószínûleg a + következõ sorokra lesz szükségünk a /dev/uscanner0 - eszközleíróhoz): + eszközleíróhoz: [system=5] add path uscanner0 mode 0660 group usb Ezt követõen az /etc/rc.conf állományba írjuk be az alábbi sort és utána indítsuk újra a számítógépet: devfs_system_ruleset="system" Az itt szereplõ sorok pontos jelentésérõl a &man.devfs.8; man oldaláról tájékozódhatunk. Ezután már csak fel kell vennünk azokat a felhasználókat a usb csoportba, amelyeknek engedélyezzük a lapolvasó használatát: &prompt.root; pw groupmod usb -m pgj A további részletekrõl a &man.pw.8; man oldalon olvashatunk. diff --git a/hu_HU.ISO8859-2/books/handbook/x11/chapter.sgml b/hu_HU.ISO8859-2/books/handbook/x11/chapter.sgml index 794180dcd8..e788ff1477 100644 --- a/hu_HU.ISO8859-2/books/handbook/x11/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/x11/chapter.sgml @@ -1,2509 +1,2515 @@ Ken Tom Az X.Org X11 szerveréhez igazította: Marc Fonvieille Az X Window System Áttekintés A &os; az X11-en keresztül nyújt a felhasználók számára hatékony grafikus felhasználói felületet. Az X11 az X Window System szabadon elérhetõ változata, melyet az &xorg; és az &xfree86; egyaránt implementál (valamint más egyéb programcsomagok is, amelyeket itt viszont nem tárgyalunk). A &os; verziói a &os; 5.2.1-RELEASE kiadással bezárólag a The &xfree86; Project, Inc. által kiadott X11 szervert, az &xfree86;-ot tartalmazzák alapértelmezés szerint. A &os; 5.3-RELEASE kiadástól kezdve az X11 alapértelmezett és hivatalos változata az &xorg;, melyet az X.Org alapítvány a &os;-éhez nagyon hasonló licenc alatt fejleszt. A &os;-hez kereskedelmi X szerverek is elérhetõek. Ebben a fejezetben az X11 telepítését és beállítását járjuk végig, miközben a hangsúlyt az &xorg; &xorg.version; kiadására helyezzük. Az &xfree86; (vagyis a &os; olyan régebbi változata, ahol az &xfree86; az alapértelmezett X11 rendszer) vagy az &xorg; korábbi kiadásainak beállításával kapcsolatban mindig találhatunk információkat a &os; kézikönyv címen található archivált változataiban. Az X11 által támogatott megjelenítõkrõl bõvebben az &xorg; honlapján olvashatunk. A fejezet elolvasása során megismerjük: az X Window System különbözõ alkotóelemeit, és hogy ezek miként mûködnek együtt; hogyan telepítsük és állítsuk be az X11-et; hogyan telepítsük és használjuk a különféle ablakkezelõket; hogyan használjunk &truetype; betûtípusokat az X11-ben; hogyan állítsuk be rendszerünkön a grafikus bejelentkezést (XDM). A fejezet elolvasásához ajánlott: külsõ programok telepítésének ismerete (). Az X áttekintése Az X használata elsõre megdöbbentõ lehet azok számára, akik olyan más grafikus környezetekben járatosak, mint például a µsoft.windows; vagy a &macos;. Míg az X minden komponensének részleteit és azok kapcsolatát nem szükséges megérteni a használatukhoz, néhány alapvetõ ismeret velük kapcsolatban elõsegíti kiaknázni az X erõsségeit. Miért X? Az X ugyan nem az elsõ &unix;-ra íródott ablakozó rendszer, de fajtáját tekintve a legnépszerûbb. Az X eredeti fejlesztõcsapata az X elõtt egy másik ablakozó rendszeren dolgozott, aminek a neve W (mint Window, azaz ablak) volt. Az X pedig az arab ábécében pontosan ezt a betût követi. Az X-et hívhatjuk X-nek, X Window System-nek, és még sok más néven. Elõfordulhat azonban, hogy az X Windows elnevezés sértõ lehet egyes emberek számára. Errõl többet a &man.X.7; man oldalon tudhatunk meg többet. Az X kliens-szerver modellje Az X-et már az elejétõl kezdve hálózatközpontúnak tervezték, és ezért az ún. kliens-szerver modellt használja. Az X modelljében az X szerver egy olyan számítógépen fut, amelyhez billentyûzetet, monitort és egeret csatlakoztattunk. A szerver feladatai között találjuk a megjelenítés irányítását az egérrõl és a billentyûzetrõl, valamint a többi bemeneti és kimeneti eszközrõl érkezõ adatok felfeldolgozását és így tovább (például a digitális táblák is használhatóak beviteli eszközként, illetve egy projektor is lehet megjelenítõ). Mindegyik X alkalmazás (mint például az XTerm vagy a &netscape;) egy kliens. A kliens üzeneteket küld a szervernek, például Kérlek, rajzolj egy ablakot ezekre a koordinátákra, és a szerver pedig olyan üzeneteket küld, mint például A felhasználó az OK gombra kattintott. Az otthoni vagy a kisebb irodai környezetben az X szerver és az X kliensek általában ugyanazon a számítógépen futnak. Emellett azonban nagyon is lehetséges, hogy az X szerver egy kevésbé erõs gépen fusson, miközben az X alkalmazások (a kliensek) az irodát kiszolgáló erõsebb és drágább gépen fussanak. Egy ilyen konfigurációban az X kliensei és szerverei közti kommunikáció a hálózaton keresztül zajlik. Jegyezzük meg, hogy az X szerver az a számítógép, ahol a monitor és a billentyûzet található, az X kliensek pedig azok a programok, amelyek az ablakokat jelenítik meg. A protokollban semmi sem várja el, hogy a kliens és a szerver ugyanazon az operációs rendszeren vagy éppen ugyanolyan típusú számítógépen fusson. Ezért akár µsoft.windows;-on vagy &apple; &macos;-en is indíthatunk X szervert, és számos különbözõ szabad valamint kereskedelmi alkalmazás képes pontosan erre. Az ablakkezelõ Az X kialakításának filozófiája leginkább a &unix; kialakításának filozófiájához hasonlítható, vagyis eszközöket, ne szabályokat. Ez tehát azt jelenti, hogy az X nem köti meg miként oldjuk meg vele a feladatokat. Helyette különféle eszközeket ad a felhasználó kezébe, és onnantól a saját felelõssége eldönteni, hogyan használja ki ezeket. Ez a filozófia az X-ben egészen addig terjed, hogy nem rögzíti, hogyan nézzenek ki a képernyõn megjelenõ ablakok, miként kell ezeket mozgatni az egérrel, milyen billentyûk lenyomásával közlekedhetünk az ablakok között (ami a µsoft.windows; esetén az AltTab), hogyan nézzen ki az ablakok címsora, a bezárás funkciónak legyen-e rajtuk gombja és így tovább. Ehelyett az X az összes ezzel járó felelõsséget átadja az ablakkezelõ (window manager) részére. Tucatnyi ilyen ablakkezelõt találhatunk az X-hez: AfterStep, Blackbox, ctwm, Enlightement, fvwm, Sawfish, twm, Window Maker és még sok más. Ezen ablakkezelõk mindegyike más és más kinézetet és hangulatot kínál fel: némelyikük támogatja a virtuális munkaasztalok (virtual desktop) létrehozását; néhányuk pedig megengedi, hogy mi magunk állítsuk be az asztal irányításához használt gombkombinációkat; köztük találhatunk olyat is, amelynek van Start gombja vagy ehhez hasonló eszköze; némelyek közülük ismerik a témákat, aminek révén a kinézetük és hangulatuk teljesen megváltoztatható. Az említett ablakkezelõk és társaik a Portgyûjtemény x11-wm kategóriájában érhetõek el. Ráadásul a KDE és a GNOME munkakörnyezetek mindegyikének van saját integrált ablakkezelõje. Az egyes ablakkezelõk mellesleg eltérõ beállítási módszerrel rendelkeznek. Némelyikük kézzel összeállított konfigurációs állományt vár, mások pedig külön grafikus eszközöket tartalmaznak erre a feladatra is. Az egyikük (a Sawfish) konfigurációs állományát például a Lisp programozási nyelv egyik dialektuásban kell megírni. Az irányítás átadása Az ablakkezelõ másik fontos feladata lekezelni, hogy az egérrel miként tudjuk átadni az ablakok között az irányítást, vagyis a fókuszt (focus policy). Minden ablakkezelõ rendszerben el kell tudnunk valahogy dönteni, hogy a beérkezõ billentyûleütések melyik ablakhoz vándoroljanak, valamint az ilyen értelemben aktív ablakot valamilyen módon jeleznünk is kell. Ennek egyik ismert módszere a fókusz kattintásra megoldás, amely modellt a µsoft.windows; rendszerekben találhatjuk meg. Itt az ablakok akkor válnak aktívvá, amikor rájuk kattintunk az egérrel. Az X viszont nem kötelezi el magát egyik vezérlésátadási módszer mellett sem, helyette az ablakkezelõ fogja majd eldönteni, melyik ablak birtokolja a fókuszt az adott pillanatban. A különbözõ ablakkezelõk különbözõ fókuszvezérlési technikákat ismernek. Mindegyikük ismeri a kattintásos fókuszt, azonban a többségük emellett még sok más megoldást is felkínál. A legnépszerûbb fókuszvezérlési elvek: A fókusz az egeret követi (focus-follows-mouse) Az egérmutató alatt található ablak kapja meg fókuszt. Az érintett ablaknak nem kell feltétlenül az összes többi felett elhelyezkednie. Ilyenkor a fókuszt egyszerûen úgy vihetjük át egy másik ablakra, ha rámutatunk az egérrel, amihez még kattintanunk sem kell. Hanyag fókusz (sloppy-focus) Ez az elv az elõbbi apró kibõvítése. Amikor a fókusz az egérmutatót követi, és az egeret a leghátsó ablakra (vagy a háttérre) visszük, akkor valójában egyik ablak sem birtokolja az irányítást, ezért a leütött billentyûk elvesznek. A hanyag fókusz használatával azonban az irányítás csak abban az esetben kerül át máshová, amikor egy másik ablakba lépünk be, nem pedig akkor, amikor a jelenlegibõl lépünk ki. Fókusz kattintásra (click-to-focus) Az aktív ablakot egy egérkattintással választjuk ki. Ilyenkor a kiválasztott ablak felemelkedhet és a többi elõtt jelenhet meg. Ezt követõen az összes irányítás ebbe az ablakba vándorol, még abban az esetben is, amikor egy másik ablakra visszük az egérmutatót. Sok ablakkezelõ ismer ezekbõl különbözõ variációikat, valamint rajtuk kívül más egyéb vezérlési elvet is. Ezzel kapcsolatban az adott ablakkezelõ dokumentációjából deríthetünk ki a legtöbbet. Widgetek Az X megközelítése, vagyis az eszközök és nem a szabályok felsorakoztatása, kiterjed az egyes alkalmazásokban látható különféle widgetekre is. A widget (window gadget, vagyis widget, de magyarul sok helyen a mütyürke) elnevezést azokra a felhasználói felületen megjelenõ elemekre használjuk, amelyekkel valamilyen módon kapcsolatba léphetünk: kattinthatunk rájuk, piszkálhatjuk ezeket. Ilyenek többek közt a gombok, jelölõnégyzetek, rádiógombok, ikonok, listák és a többi. A µsoft.windows; nyelvén ezeket vezérlõknek (control) nevezzük. A µsoft.windows; és az &apple; &macos; ezen a téren nagyon merev. Az alkalmazások fejlesztõinek gondoskodniuk kell róla, hogy a programjaik az elterjedt kinézetet és kialakítást kövessék. Az X viszont nem várja az egységes vezérlõeszközök vagy grafikai stílus használatát. Ennek eredményeképpen az X cseppet sem kívánja meg az alkalmazásoktól, hogy közös kinézetben vagy viselkedésben osztozzanak. Természetesen léteznek népszerû eszközrendszerek és azoknak számos variációja is kialakult, beleértve az MIT Athenaját, a &motif;ot (amirõl a µsoft.windows; eszközeit is mintázták, az összes ferde élet és a három szürkeárnyalatot), az OpenLookot és társaikat. Napjaink X alkalmazásai a KDE fejlesztéséhez használt Qt, esetleg a GNOME-hoz használt GTK+ könyvtárból származó, korszerû kinézetû widgeteket tartalmaznak. Ebbõl a szempontból megfigyelhetõ egyfajta tendencia a grafikus &unix;-alkalmazások felépítésében, ami minden bizonnyal megkönnyíti a kezdõ felhasználók tájékozódását. Az X11 telepítése Az X11 &os;-n alapértelmezett implementációja az &xorg;. Az &xorg; az X.Org alapítvány által kiadott, az X Window Systemet megvalósító nyílt forráskódú X szerver. Az &xorg; az &xfree86; 4.4RC2 és X11R6.6 kódja alapján készült. A &os; Portgyûjteményében jelenleg az &xorg; &xorg.version; változata érhetõ el. Az &xorg;-ot a Portgyûjteménybõl így tudjuk lefordítani, majd telepíteni: &prompt.root; cd /usr/ports/x11/xorg &prompt.root; make install clean Az egész &xorg; lefordításához legalább 4 GB szabad helyre van szükségünk. Az X11-et természetesen telepíthetjük közvetlenül csomagok segítségével is. A &man.pkg.add.1; használatával telepíthetõ bináris csomagok is elérhetõek az X11-hez. Amikor a &man.pkg.add.1; programra bízzuk a csomag letöltését, ne adjunk meg verziószámot, a &man.pkg.add.1; ugyanis mindig automatikusan az alkalmazás legfrissebb verzióját tölti le. Az &xorg; csomagjának letöltéséhez és telepítéséhez egyszerûen csak ennyit írjunk be: &prompt.root; pkg_add -r xorg A fentebb megadott példák a teljes X11 rendszert telepíteni fogják, beleértve a szervereket, klienseket, betûtípusokat stb. Az X11 egyes részeihez külön találhatunk csomagokat és portokat. A fejezet további részében szót ejtünk az X11, valamint egy irodai használatra alkalmas munkakörnyezet beállításáról. Christopher Shunway Írta: Az X11 beállítása &xorg; X11 Mielõtt nekilátnánk Az X11 beállítása elõtt a célrendszer következõ adataira lesz szükségünk: A monitor jellemzõi A videokártya chipkészlete A videokártya memóriájának mérete függõleges frissítési frekvencia vízszintes frissítési frekvencia Az X11 a monitor jellemzõibõl állapítja meg, hogy milyen felbontásban és frissítési frekvenciával mûködtesse azt. Ezek általában a monitorhoz tartozó dokumentációból vagy a gyártó honlapjáról deríthetõek ki. Igazából két értékre van szükségünk: a függõleges és a vízszintes frissítési frekvenciára. A videokártya chipkészlete határozza meg, hogy az X11 melyik meghajtóján keresztül kommunikál a grafikus hardverrel. Ez a legtöbb chipkészlet esetén magától megállapítható, de ennek ellenére mégis jó tisztában lenni ezzel arra az esetre, ha az automatikus felismerés mégsem mûködne. A grafikus kártya memóriájának mérete határozza meg a rendszer által kihasználható felbontást és színmélységet. Ezt fontos tudunk ahhoz, hogy ismerjük a rendszerünk korlátait. Az X11 beállítása Az &xorg; 7.3-as változatában gyakran mindenféle konfigurációs állomány használata nélkül egyszerûen csak adjuk ki a következõ parancsot: &prompt.user; startx A &xorg; 7.4 verziójától kezdõdõen a számítógépünkhöz csatlakoztatott egerek és billentyûzetek HAL segítségével automatikusan felismerhetõek. Ennek megfelelõen a x11/xorg port függõségeként telepítõdni fognak a sysutils/hal és devel/dbus portok, viszont az /etc/rc.conf állományban a következõ sorok hozzáadásával külön engedélyeznünk kell még ezeket: hald_enable="YES" dbus_enable="YES" Ezeket a szolgáltatásokat még az &xorg; beállítása elõtt el kell indítanunk (a parancssorból manuálisan vagy a rendszer újraindításával). Bizonyos hardvereszközök esetén az automatikus felismerés még nem mûködik megbízhatóan vagy nem jól állítja be az értékeket. Ilyen esetekben kézzel kell megadnunk a szükséges beállításokat. A különbözõ munkakörnyezetek, mint például a GNOME, a KDE vagy éppen az Xfce általában tartalmaznak olyan segédprogramokat, amelyekkel a felhasználó könnyedén be tudja állítani a megjelenítés paramétereit, többek közt a képernyõ felbontását. Tehát ha az alapértelmezések nem megfelelõek, viszont használni akarunk majd valamilyen munkakörnyezetet is, akkor egyszerûen csak telepítsük az adott környezetet és a hozzátartozó eszközön keresztül állítsuk be a megjelenítést. Az X11 beállítása egy többlépcsõs folyamat. Elsõ lépésünk egy alap konfigurációs állomány összeállítása lesz. Rendszeradminisztrátorként adjuk ki az alábbi parancsot: &prompt.root; Xorg -configure Ennek segítségével az X11 xorg.conf.new néven létrehozza a konfigurációs állomány vázát a /root könyvtárban (akár a &man.su.1; parancsot használjuk, akár közvetlenül így jelentkezünk be, az így örökölt rendszeradminisztrátori szerepkör maga után vonja a $HOME könyvtár átállítását is). Az X11 megpróbálja megkeresni a célrendszerben elérhetõ grafikus eszközöket, és létrehozni egy olyan konfigurációs állományt, amely az észlelt eszközökhöz tartozó meghajtókat tölti be. A következõ lépésünk legyen az imént létrehozott beállítás kipróbálása, amin keresztül ellenõrizhetjük, hogy az &xorg; tényleg képes mûködni a célrendszer grafikus eszközén. Az &xorg; 7.3 és azt megelõzõ változataiban ezt így tehetjük meg: &prompt.root; Xorg -config xorg.conf.new A &xorg; 7.4 és késõbbi változataiban a próba eredménye egy fekete képernyõ lesz, amely meglehetõsen megnehezítheti az X11 helyes mûködésének megállapítását. A kapcsoló használatával azonban továbbra is elérhetjük a korábbi verziókban megszokott viselkedési módot: &prompt.root; Xorg -config xorg.conf.new -retro Ha ezután a képernyõn egy fekete-fehér rácsot látunk egy X alakú egérmutatóval a közepén, akkor jó a beállítás. A próbát a CtrlAltBackspace billentyûk együttes lenyomásával szakíthatjuk meg. Az &xorg; 7.3 és korábbi változataiban ez a billentyûkombináció alapértelmezés szerint engedélyezett. Amennyiben továbbra is szükségünk lenne rá, a 7.4 és késõbbi változatokban ezt úgy tudjuk engedélyezni, ha a begépeljük a következõ parancsot egy X terminálablakban: &prompt.user; setxkbmap -option terminate:ctrl_alt_bksp Egy másik lehetséges megoldás, ha a billenytûzet beállításához létrehozunk a /usr/local/etc/hal/fdi/policy könyvtárban egy konfigurációs állományt x11-input.fdi néven a hald számára. Ebben az állományban a következõknek kell szerepelnie: <?xml version="1.0" encoding="ISO-8859-2"?> <deviceinfo version="0.2"> <device> <match key="info.capabilities" contains="input.keyboard"> <merge key="input.x11_options.XkbOptions" type="string">terminate:ctrl_alt_bksp</merge> </match> </deviceinfo> A hald a számítógép újraindításával fogja majd beolvasni ezt az állományt. Ha az egér még nem mûködne, mindenképpen be kell állítanunk a továbblépés elõtt. Ezzel kapcsolatban a &os; telepítésérõl szóló fejezetben levõ t ajánljuk elolvasásra. Fontos megemlíteni, hogy az &xorg; 7.4 változatától kezdõdõen az xorg.conf InputDevice szekcióit az eszközök automatikusan észlelt beállításai felülbírálják. A régebbi változatok viselkedését úgy tudjuk visszanyerni, ha a ServerLayout és ServerFlags szekciók valamelyikéhez hozzáadjuk az alábbi sort: Option "AutoAddDevices" "false" Ezt követõen a beviteli eszközök a lehetséges beállítási opciók (például a billentyûzet-kiosztás váltása) mentén a korábbiakban megszokott módon konfigurálhatóak. Ahogy arról korábban szó esett, a 7.4 verziótól kezdõdõen a hald magától érzékelni fogja a számítógépre csatlakoztatott billentyûzetet. Elõfordulhat, hogy a billentyûzet típusa vagy éppen kiosztása nem lesz megfelelõ. Ennek beállítására többnyire a népszerûbb munkakörnyezetek, mint például a GNOME, KDE vagy Xfce tartalmaznak külön segédprogramot. A &man.setxkbmap.1; vagy a hald konfigurációs szabályával azonban akár közvetlenül is meg tudjuk változtatni a billentyûzhez társított tulajdonságokat. Például ha egy 102 gombos billentyûzetet szeretnénk használni francia kiosztással, akkor ehhez a /usr/local/etc/hal/fdi/policy könyvtárban kell létrehoznunk egy x11-input.fdi nevû állományt a hald részére. Ebben az állományban szerepeljenek az alábbi sorok: <?xml version="1.0" encoding="ISO-8859-2"?> <deviceinfo version="0.2"> <device> <match key="info.capabilities" contains="input.keyboard"> <merge key="input.x11_options.XkbModel" type="string">pc102</merge> <merge key="input.x11_options.XkbLayout" type="string">fr</merge> </device> </deviceinfo> Ha létezik már ilyen állományunk, akkor a billentyûzet megfelelõ beállításához egyszerûen csak másoljuk ki a fenti sorokat és adjuk hozzá. Indítsuk újra a számítógépet, hogy a hald beolvassa az állományt. Ugyanezt egy X terminálból is kényelmesen el tudjuk végezni: &prompt.user; setxkbmap -model pc102 -layout fr A paraméterként megadható billentyûzettípusokat és -kiosztásokat a /usr/local/share/X11/xkb/rules/base.lst állományban találhatjuk meg. Az X11 finomhangolása Ezután az ízlésünknek megfelelõen hangoljuk be az xorg.conf.new állományt, nyissuk meg egy szövegszerkesztõben, például az &man.emacs.1;-ben vagy az &man.ee.1;-ben. Elsõként adjuk meg a célrendszerhez csatlakoztatott monitor frekvenciájára vonatkozó adatokat. Ezek általában a függõleges és a vízszintes frissítés értékei, melyeket az xorg.conf.new állomány "Monitor" szakaszában (Section) kell feltüntetni: Section "Monitor" Identifier "Monitor0" VendorName "A monitor gyártója" ModelName "A monitor típusa" HorizSync 30-107 VertRefresh 48-120 EndSection A konfigurációs állományból valószínûleg csak a HorizSync és VertRefresh kulcsszavak fognak hiányozni. Amennyiben ez tényleg így lenne, a megfelelõ vízszintes frissítés értékét a HorizSync kulcsszó után, a hozzátartozó függõleges frissítés értékét pedig a VertRefresh kulcsszó után kell hozzátennünk a szakaszhoz. Az iménti példában már megadtuk a célrendszer monitorának frissítési értékeit. Az X megengedi, hogy DPMS (Energy Star) energiagazdálkodási szabványt ismerõ monitorok lehetõséget is kihasználjuk. A &man.xset.1; program vezérli a monitorok ki- és bekapcsolását, és segítségével készenléti vagy energiatakarékos üzemmódba tudjuk helyezni azokat. Ha engedélyezni kívánjuk a monitorunk DPMS lehetõségeit, egyszerûen csak tegyük hozzá az alábbi sort a monitorunkat leíró szakaszhoz: Option "DPMS" xorg.conf Ha már a xorg.conf.new konfigurációs állomány szerkesztésével vagyunk elfoglalva, válasszuk ki számunkra kedvezõ alapértelmezett felbontást és színmélységet is. Ezt a "Screen" (Képernyõ) nevû szakaszban tehetjük meg: Section "Screen" Identifier "Screen0" Device "Card0" Monitor "Monitor0" DefaultDepth 24 SubSection "Display" Viewport 0 0 Depth 24 Modes "1024x768" EndSubSection EndSection A DefaultDepth kulcsszó után adjuk meg a rendszer alapértelmezett színmélységét. Ezt késõbb az &man.Xorg.1; paraméterével bírálhatjuk felül a parancssorból. A Modes kulcsszó után jelennek meg azok a felbontások, amelyekben az adott színmélység elérhetõ. Itt csak olyan VESA szabványú módok jelenhetnek meg, amelyet a célrendszer grafikus eszköze is támogat. A fenti példában az alapértelmezett színmélység képpontonként huszonnégy bit, és ebben a színmélységben az elfogadott felbontás 1024-szer 768 pixel. Végezetül mentsük el a szerkesztett konfigurációs állományt és próbáljuk ki a korábban leírt módszer szerint. A hibakeresés során maguk az X11 naplóállományai is hasznos eszköznek bizonyulhatnak, mivel ezek minden olyan eszközrõl tartalmaznak információt, amelyekhez az X11 szervernek sikerült csatlakoznia. Az &xorg; naplóit a /var/log/Xorg.0.log elnevezést követõ állományokban találjuk meg. A konkrét naplók nevei Xorg.0.log-tól Xorg.8.log-ig és így tovább terjedhetnek. Ha minden a legnagyobb rendben haladt eddig, a konfigurációs állományt el kell tennünk egy olyan központi helyre, ahol az &man.Xorg.1; képes lesz majd megtalálni. Ez a hely általában az /etc/X11/xorg.conf vagy a /usr/local/etc/X11/xorg.conf. &prompt.root; cp xorg.conf.new /etc/X11/xorg.conf Az X11 beállítását ezzel befejeztük. Az &xorg; innentõl elindítható a &man.startx.1; segédprogram vagy az &man.xdm.1; használatával. Témák idõsebbeknek és haladóknak Az i810 grafikus chipkészlet beállítása Intel i810 grafikus chipkészlet Az &intel; i810 integrált chipkészletének meghajtásához szükségünk lesz az agpart nevû AGP programozási felületre az X11-ben. Errõl az &man.agp.4; meghajtó man oldalán olvashatuk többet. Ennek segítségével ezt a hardvert is a többi grafikus kártyához hasonlóan állíthatjuk be. Vegyük figyelmbe azonban, hogy az &man.agp.4; meghajtót beépítve nem tartalmazó rendszermaggal futó rendszerekben a &man.kldload.8; paranccsal utólag már nem tudjuk betölteni! Ezt a meghajtót már a rendszerindítás során be kell tudnunk tölteni: vagy a rendszermagba fordítjuk, vagy pedig a /boot/loader.conf állományban hivatkozunk rá. Widescreen Flat Panel monitorok használata widescreen flat panel beállítása Ebben a részben feltételezünk némi tapasztalatot a beállítások terén. Amennyiben a szabványos konfigurációs eszközök csõdöt mondtak a beállítás során, magukból a naplóállományokból is kinyerhetünk elegendõ információt ahhoz, hogy mûködésre bírjuk rendszerünket. Ehhez mindenképpen legyen kéznél egy szövegszerkesztõ! A jelenlegi szélesvásznú (WSXGA, WSXGA+, WUXGA, WXGA, WXGA+ és társai) formátumok a 16:10-es és 10:9-es képarányokat ismerik, amik néha gondot okozhatnak. Például a 16:10-es képarány felbontásai: 2560x1600 1920x1200 1680x1050 1440x900 1280x800 Bizonyos szempontból egyszerûen csak a fenti felbontások valamelyikét kell felvenni a "Screen" szakasz Mode sorába, valahogy így: Section "Screen" Identifier "Screen0" Device "Card0" Monitor "Monitor0" DefaultDepth 24 SubSection "Display" Viewport 0 0 Depth 24 Modes "1680x1050" EndSubSection EndSection Az &xorg; elég intelligens ahhoz, hogy a szélesvásznú megjelenítéssel kapcsolatos információkat lekérje a monitor I2C/DDC adatai közül, ezért meg tudja állapítani, hogy az eszköz milyen frissítési frekvenciákat és felbontásokat bír el. Ha az alábbi ModeLine értékek nem szerepelnének a meghajtókban, akkor velük kapcsolatban egy kicsit súgnunk kell az &xorg;-nak. A /var/log/Xorg.0.log átrágásával elegendõ információt tudunk gyûjteni ahhoz, hogy manuálisan vegyünk fel használható ModeLine értékeket. Nem kell mást tennünk, mint ehhez hasonló sorokat keresnünk: (II) MGA(0): Supported additional Video Mode: (II) MGA(0): clock: 146.2 MHz Image Size: 433 x 271 mm (II) MGA(0): h_active: 1680 h_sync: 1784 h_sync_end 1960 h_blank_end 2240 h_border: 0 (II) MGA(0): v_active: 1050 v_sync: 1053 v_sync_end 1059 v_blanking: 1089 v_border: 0 (II) MGA(0): Ranges: V min: 48 V max: 85 Hz, H min: 30 H max: 94 kHz, PixClock max 170 MHz Ezeket nevezik EDID-adatoknak (Extended display identification data, vagyis bõvített megjelenítési azonosító adatoknak). Belõlük a megfelelõ ModeLine sor létrehozása csupán annyiból áll, hogy a számértékeket a megfelelõ sorrendbe tesszük: ModeLine <name> <clock> <4 horiz. timings> <4 vert. timings> Ezáltal a példában látott "Monitor" szakasz ModeLine sora így fog kinézni: Section "Monitor" Identifier "Monitor1" VendorName "Bigname" ModelName "BestModel" ModeLine "1680x1050" 146.2 1680 1784 1960 2240 1050 1053 1059 1089 Option "DPMS" EndSection Miután végrehajtottuk ezeket az egyszerû beállítási lépéseket, az X most már valószínûleg el fog indulni az új szélesvásznú monitorunkon. Murray Stokely Írta: Betûtípusok használata az X11-ben Type1 betûtípusok Az X11-hez tartozó alap betûtípusok nem mondhatóak kifejezetten ideálisnak például egy átlagos asztali kiadványszerkesztõ alkalmazás számára. A nagyobb méretû bemutatókon a betûi szögletesen és idétlenül néznek ki, a &netscape;ben megjelenõ kisebb betûk pedig szinte teljességgel olvashatatlanok. Viszont manapság már rengeteg szabad, nagyon jó minõségû és könnyen használható Type1 (&postscript;) betûtípus érhetõ el az X11-hez. Például az URW betûtípus-gyûjtemény (x11-fonts/urwfonts) a szabványos Type1 betûtípusok (Times Roman, Helvetice, Palatino és még sok más) jó minõségû változatait tartalmazza. A Freefonts nevû gyûjtemény (x11-fonts/freefonts) is tartalmaz sok más betûtípust, de a legtöbbjüket inkább csak a Gimpben és a hozzá hasonló grafikai alkalmazásokban tudjuk használni, illetve nincsenek is még kellõ mértékben befejezve a hétköznapi munkákhoz. Ezeken felül az X11 minimális ügyeskedéssel beállítható a &truetype; betûtípusok használatára is. Errõl részleteket a &man.X.7; man oldalon, illetve a &truetype; betûtípusokról szóló szakaszban olvashatunk. A Portgyûjteménybõl az imént említett Type1 betûtípusokat az alábbi parancsok segítségével telepíthetjük: &prompt.root; cd /usr/ports/x11-fonts/urwfonts &prompt.root; make install clean Ugyanígy járjunk el a freefont és a többi gyûjtemény esetén is. Az X szerver akkor fogja észlelni ezeket a betûtípusokat, ha hozzáadjuk a következõ sort a konfigurációs állományához (/etc/X11/xorg.conf): FontPath "/usr/local/lib/X11/fonts/URW/" Vagy megtehetjük mindezt az X futtatása során is: &prompt.user; xset fp+ /usr/local/lib/X11/fonts/URW &prompt.user; xset fp rehash Ez utóbbi beállítás viszont el fog veszni az X leállításával, hacsak nem vesszük hozzá a indítószkriptjéhez (ez az ~/.xinitrc a startx használata esetén, illetve az ~/.xsession, amikor egy XDM-szerû grafikus bejelentkezést használunk). Ezek mellett használhatjuk a /usr/local/etc/fonts/local.conf állományt is: errõl az élsimítással foglalkozó szakaszban szólunk részletesebben. &truetype; betûtípusok TrueType betûtípusok betûtípusok TrueType Az &xorg; beépített támogatást tartalmaz a &truetype; betûtípusok rendereléséhez. Két különbözõ modul valósítja meg ezt a feladatot. Ebben példában a freetype nevû modult használjuk, mivel sokkal jobban illeszkedik a többi betûrenderelõhöz. A freetype modul használatához mindössze az /etc/X11/xorg.conf állomány "Module" szakaszába kell beírnunk a következõ sort: Load "freetype" Most pedig hozzunk létre egy könyvtárat a &truetype; betûtípusok számára (ez legyen például a /usr/local/lib/X11/fonts/TrueType), majd másoljuk az összes &truetype; betûtípusunkat ide. Vigyázzunk rá, hogy &macintosh;-ról &truetype; betûtípusok közvetlenül nem hozhatóak át, az X11 számára &unix;/&ms-dos;/&windows; formátumban kell lenniük. Miután sikerült átmásolnunk az állományokat ebbe a könyvtárba, használjuk a ttmkfdir parancsot a fonts.dir állomány létrehozására, aminek révén az X betûrenderelõje tudnia fogja, hogy új állományokat telepítettünk. A ttmkfdir x11-fonts/ttmkfdir néven elérhetõ a &os; Portgyûjteményébõl. &prompt.root; cd /usr/local/lib/X11/fonts/TrueType &prompt.root; ttmkfdir -o fonts.dir Ezután adjuk hozzá a &truetype; könyvtárat a betûtípusok könyvtáraihoz. Itt is a Type1 betûtípusoknál leírtak szerint kell eljárnunk, vagyis használjunk a &prompt.user; xset fp+ /usr/local/lib/X11/fonts/TrueType &prompt.user; xset fp rehash parancsot, vagy adjunk hozzá a xorg.conf állományhoz egy további FontPath sort. Ezzel végeztünk is. Innentõl kezdve a &netscape;, Gimp, a &staroffice; és mindegyik X alkalmazás fel fogja ismerni a frissen telepített &truetype; betûtípusokat. A nagyon kicsi betûk (egy honlap megtekintése során, nagyfelbontásban) és a nagyon nagy betûk (a &staroffice; használatakor) most már sokkal jobban fognak mutatni. Joe Marcus Clarke Frissítette: A betûk élsimítása élsimított betûk betûk élsimított Az X11-ben az &xfree86; 4.0.2-es változata óta érhetõ el az élsimítás, azonban az &xfree86; 4.3.0-at megelõzõen a betûk beállítása meglehetõsen körülményes volt. Az &xfree86; 4.3.0-as verziójával kezdõdõen az X11 által használt, a /usr/local/lib/X11/fonts/ és a ~/.fonts/ könyvtárakban található összes betûtípus élsimítása automatikusan elérhetõ az Xft-re felkészített alkalmazások számára. Nem mindegyik alkalmazás használja ki az Xft-t, de sokan kaptak hozzá támogatást. Ilyen Xft-alkalmazások a (KDE fejlesztéséhez használt) Qt 2.3 és késõbbi változatai, a (GNOME fejlesztéséhez használt) GTK+ 2.0 és késõbbi változatai, valamint a Mozilla 1.2 és késõbbi változatai. A betûtípusok élsimításának be- és kikapcsolásához, valamint élsimítási jellemzõinek beállításához hozzuk létre (vagy ha már létezne, módosítsuk) a /usr/local/etc/fonts/local.conf állományt. Az Xft betûrendszer számos kifinomult lehetõsége hangolható ezzel az állománnyal, amelyekbõl ebben a szakaszban csupán rövidke ízelítõt fogunk adni. A pontosabb részletekrõl a &man.fonts-conf.5; man oldalon tájékozódhatunk. XML Az állománynak XML formátumúnak kell lennie. Különösen ügyeljünk a kis- és nagybetûkre, illetve gyõzödjünk meg mindig róla, hogy lezártuk-e az összes taget. Az állomány a szokásos XML-fejléccel kezdõdik, amelyet egy DOCTYPE definíció követ, majd a <fontconfig> tag: <?xml version="1.0"?> <!DOCTYPE fontconfig SYSTEM "fonts.dtd"> <fontconfig> Ahogy azt már korábban is említettük, a /usr/local/lib/X11/fonts és a ~/.fonts/ könyvtárakban található összes betûtípus élsimítása elérhetõ az Xft-re felkészített alkalmazások számára. Amennyiben ezeken túl még további könyvtárakat is fel kívánunk venni, írjuk bele a /usr/local/etc/fonts/local.conf állományba, nagyjából ilyen alakban: <dir>/az/en/betu/tipusaim</dir> Az új betûtípusok, de legfõképpen az új betûtípusokat tartalmazó könyvtárak hozzáadása után a betûkkel kapcsolatos gyorsítótárak frissítéséhez mindenképpen javasolt lefuttatni az alábbi parancsot: &prompt.root; fc-cache -f Az élsimítás hatására a betûk kontúrjai egy kissé elmosódnak, aminek köszönhetõen a nagyon kis méretû szövegek sokkal olvashatóbbá válnak és eltûnnek a nagy méretû betûkrõl a lépcsõk, azonban a normál méretû betûknél megfájdulhat tõle a szemünk. A 14 pontnál kisebb méretû betûk esetén az alábbi sorok hozzáadásával tudjuk kikapcsolni az élsimítást: <match target="font"> <test name="size" compare="less"> <double>14</double> </test> <edit name="antialias" mode="assign"> <bool>false</bool> </edit> </match> <match target="font"> <test name="pixelsize" compare="less" qual="any"> <double>14</double> </test> <edit mode="assign" name="antialias"> <bool>false</bool> </edit> </match> betûk térköz Bizonyos egyenszélességû (monospaced) betûtípusok élsimítása esetén a betûk távolsága nem megfelelõ. Ez leginkább a KDE használata esetén merül fel. Ezt a problémát úgy is orvosolhatjuk, ha az ilyen betûtípusok térközét kézzel 100-ra állítjuk. Ehhez írjuk be a következõ sorokat: <match target="pattern" name="family"> <test qual="any" name="family"> <string>fixed</string> </test> <edit name="family" mode="assign"> <string>mono</string> </edit> </match> <match target="pattern" name="family"> <test qual="any" name="family"> <string>console</string> </test> <edit name="family" mode="assign"> <string>mono</string> </edit> </match> (ezzel lefedjük összes rögzített méretû (fixed) betûtípust "mono"-ként), majd vegyük hozzá ezt is: <match target="pattern" name="family"> <test qual="any" name="family"> <string>mono</string> </test> <edit name="spacing" mode="assign"> <int>100</int> </edit> </match> Egyes betûtípusoknál, mint például a Helveticánál, gondok akadhatnak az élsimítással. Ez általában egy függõlegesen kettévágottnak látszó betû képében jelenik meg. De ami a legrosszabb, hogy emiatt némely alkalmazás, mint például a Mozilla képes összeomlani. Ennek elkerülésére tegyük hozzá még az alábbi sorokat a local.conf állományhoz: <match target="pattern" name="family"> <test qual="any" name="family"> <string>Helvetica</string> </test> <edit name="family" mode="assign"> <string>sans-serif</string> </edit> </match> Miután befejeztük a local.conf szerkesztését, ellenõrizzük, hogy szerepel-e az állomány végén a </fontconfig> tag. Ha ugyanis nem zárjuk le rendesen, akkor a változtatásaink érvénytelenné válnak. Az X11-hez tartozó alap betûtípus nem éppen mutatós élsimított alakjában. Erre a célra sokkal jobb alap betûtípusok is találhatóak a x11-fonts/bitstream-vera portban. Ha még nem létezne /usr/local/etc/fonts/local.conf állományunk, akkor ezt a port létrehozza. Ellenkezõ esetben a port készít egy /usr/local/etc/fonts/local.conf-vera nevû állományt. Fésüljük össze ennek az állománynak a tartalmát a /usr/local/etc/fonts/local.conf tartalmával, és a Bitstream betûtípusok maguktól felváltják az X11 alapértelmezett talpas (serif), talpatlan (sans serif) és egyenszélességû (monospaced) betûtípusait. Végezetül a felhasználók is megadhatják a saját beállításaikat a saját .fonts.conf állományuk segítségével. Ehhez nem kell mást tenni, mindössze létrehozni egy ~/.fonts.conf XML-állományt. LCD képernyõ betûk LCD képernyõ Még egy utolsó ötlet: LCD képernyõk esetén szükségünk lehet az ún. sub-pixel sampling (részképpont mintavételezési) technikára. Ezzel lényegében a (vízszintesen elválasztott) vörös, zöld és kék összetevõket külön-külön kezeljük a horizontális felbontás javítására. Bámulatos eredményeket lehet elérni a segítségével! A bekapcsolásához a következõ sorokat kell beszúrnunk valahova a local.conf állományba: <match target="font"> <test qual="all" name="rgba"> <const>unknown</const> </test> <edit name="rgba" mode="assign"> <const>rgb</const> </edit> </match> A megjelenítõ fajtájától függõen lehet, hogy az rgb értéket bgr-re, vrgb-re vagy vbgr-re kell cserélnünk. Próbálgassuk és kiderül, hogy melyikkel mûködik jobban. Mozilla az élsimítás kikapcsolása Az élsimítás hatása az X következõ indításakor fog látszódni. Azonban a programoknak tudniuk is kell élni az általa felkínált elõnyökkel. A Qt pillanatnyilag képes erre, ezért az összes KDE-elem ki tudja használni a betûtípusok élsimítását. A GTK+ és a GNOME is használja az élsimítást a Font cappleten keresztül (errõl bõvebben ld. a t). A Mozilla 1.2 és késõbbi változatai már alapértelmezés szerint használják az élsimítást. Ennek kikapcsolásához a Mozillat a -DWITHOUT_XFT kapcsolóval fordítsuk újra. Seth Kingsley Írta: Az X bejelentkeztetõ képernyõje Összefoglalás X Display Manager Az X bejelentkeztetõ képernyõje (az X Display Manager vagy röviden csak XDM) az X Window System egyik kiegészítõ eleme, melyet a bejelentkezések lebonyolítására használunk. Számtalan helyzetben hasznosnak bizonyulhat, beleértve a legkisebb X terminálokat és a legnagyobb hálózati szervereket is. Mivel az X Window System független hálózattól és protokolltól, a hálózaton összekapcsolt, X klienseket és szervereket futtató különbözõ számítógépek széles kombinációja elõfordulhat. Az XDM egy grafikus felületen keresztül segít választani az elérhetõ szerverek között, valamint a felhasználók, például felhasználónév és jelszón keresztüli, hitelesítésében. Az XDM tulajdonképpen a felhasználó számára ugyanazokat a funkciókat nyújtja, mint a &man.getty.8; program (errõl bõvebben lásd ). Tehát: belépteti a felhasználót a szerverre, ahova csatlakozott, illetve elindítja helyette a hozzátartozó munkamenet kezelõjét (ami általában egy X-es ablakkezelõ). Az XDM megvárja ennek a programnak a befejezõdését, ami egyben jelzi számára, hogy a felhasználó elvégezte a dolgát, és kilépteti a szerverrõl. Ezután az XDM újra várakozni kezd a következõ felhasználóra, miközben a bejelentkezéshez és a szerver kiválasztásához szükséges képernyõket jeleníti meg. Az XDM használata - Az XDM-hez tartozó - démon a /usr/local/bin/xdm - állomány. Ezt programot root - felhasználóként bármikor tudjuk - futtatni, és ez veszi kezelésbe a helyi - gépen futó X szervert. Amennyiben az - XDM-et a + A XDM használatához + elõször telepítenünk kell rendszerünkre + a x11/xdm portot (mivel az + &xorg; újabb változatai + ezt alapértelmezés szerint már nem + telepítik). Ezt követõen az + XDM démon a + /usr/local/bin/xdm helyen + található meg. A programot + root felhasználóként + bármikor tudjuk futtatni, és ez veszi + kezelésbe a helyi gépen futó X szervert. + Amennyiben az XDM-et a számítógép minden egyes indulása során el akarjuk indítani, egyszerûen csak adjuk hozzá a megfelelõ bejegyzést az /etc/ttys állományhoz. Ennek a formai szabályairól és használatáról bõvebben lásd . Az /etc/ttys alapértelmezett változatában az XDM démont ebben a formában találjuk meg a virtuális terminálok között: ttyv8 "/usr/local/bin/xdm -nodaemon" xterm off secure Ez a bejegyzés alapból nem aktív. Az engedélyezéséhez írjuk át az ötödik mezõben szereplõ off (kikapcsolva) értéket on (bekapcsolvá)-ra, majd indítsuk újra az &man.init.8; programot a ban leírtak szerint. Az elsõ mezõben találhatjuk a program által kezelt terminált, ez jelen esetünkben a ttyv8. Ennek megfelelõen az XDM a 9. virtuális terminálon kezdi meg a futását. Az XDM beállítása Az XDM beállításait tartalmazó könyvtár a /usr/local/lib/X11/xdm. Itt találhatjuk meg azokat az állományokat, amelyek megváltoztatásával befolyásolhatjuk az XDM megjelenését és viselkedését. Általában a következõ állományok bukkannak fel ezen a helyen: Állomány Leírás Xaccess A kliens hitelesítésének szabályrendszere. Xresources Az X erõforrásainak alapértelmezett értékei. Xservers Az ismert távoli és helyi X szerverek listája. Xsession A bejelentkezések során lefutó alapértelmezett szkript. Xsetup_* A bejelentkezõ felület indítása elõtt indítandó alkalmazásokkal kapcsolatos szkript. xdm-config A gépen futó összes X szerver globális beállításai. xdm-errors A szerver által jelentett hibák. xdm-pid A jelenleg futó XDM-hez tartozó azonosító. Ebben a könyvtárban találunk még néhány olyan programot és szkriptet, amelyekkel be tudjuk állítani a munkaasztalunkat az XDM futása alatt. Ezen állományok céljait egyenként ismertetni fogjuk. A felépítésükrõl és használatukról az &man.xdm.1; man oldala árul el többet. Az alapértelmezett beállítás egy téglalap alakú bejelentkezõ ablak, aminek tetején nagy betûkkel a gép neve olvasható, valamint alatta a Login: (felhasználói név) és Password: (jelszó) mezõk várnak kitöltésre. Ez egy remek kiindulási alap az XDM-képernyõ kinézetének megváltoztatásához. Xaccess Az XDM-mel szabályozott X szerverek által használt protokoll az X Display Manager Connection Protocol (XDMCP). Ez az állomány tartalmazza a távoli számítógépekrõl érkezõ XDMCP-kapcsolatok vezérlésére vonatkozó szabályokat. Ezt a rendszer általában figyelmen kívül hagyja, hacsak az xdm-config állományban be nem állítottuk a távoli számítógépek csatlakoztathatóságát. Alapértelmezés szerint viszont semmilyen klienst nem enged csatlakozni. Xresources Ez tartalmazza a szerverválasztó és bejelentkezõ képernyõ alapértelmezéseit. Segítségével a bejelentkeztetést végzõ program kinézetét változtathatjuk meg. Formátuma hasonló az X11 dokumentációjában leírt app-defaults állományhoz. Xservers A szerverválasztó által felkínálandó távoli X szerverek felsorolását tartalmazza. Xsession A felhasználó bejelentkezése után ez az XDM-szkript fog lefutni. Általában minden felhasználóhoz tartozik egy saját ~/.xsession szkript, ami ezt felülbírálja. Xsetup_* Ezek fognak automatikusan lefutni a szerverválasztó vagy bejelentkeztetõ felületek megjelenése elõtt. Minden általunk használt X szerverhez tartozik egy ilyen szkript, amelyek neve Xsetup_-al kezdõdik és a helyi X szerver sorszámával folytatódik (például Xsetup_0). Ezek a szkriptek általában egy-két programot, mint például az xconsole, indítanak el a háttérben. xdm-config Az app-defaults nevû állományéhoz hasonló alakban tartalmaz beállításokat a program által kezelt minden egyes X szerverhez. xdm-errors Ebben található meg az XDM által futtatni próbált X szerverek kimenete. Itt érdemes hibaüzenetek után kutatni, ha az XDM által indított X szerver valamiért megállna. Ezek az üzenetek egyébként a felhasználó ~/.xsession-errors állományába is beíródnak. Hálózati X szerver futtatása Az X szerverünkhöz csak akkor tudnak kívülrõl más felhasználók is kapcsolódni, ha átírjuk a hozzáférésre vonatkozó szabályokat és engedélyezzük rajta a kapcsolódást. Az alapértelmezett szabályok nagyon óvatosak. Ha tehát engedélyezni akarjuk a kívülrõl érkezõ kapcsolódásokat, akkor ahhoz elõször az xdm-config állományból vegyük ki az alábbi sort: ! SECURITY: do not listen for XDMCP or Chooser requests ! Comment out this line if you want to manage X terminals with xdm DisplayManager.requestPort: 0 Ezután indítsuk újra az XDM-et. Ne felejtsük el, hogy az app-defaults állományokban a megjegyzések ! (felkiáltó)jellel kezdõdnek, nem pedig a megszokott # (kettõskereszt)tel. A fentieknél természetesen szigorúbb hozzáférési szabályok is szükségesek lehetnek — ezzel kapcsolatban nézzük meg Xaccess állományban szereplõ példákat, illetve lapozzuk fel az &man.xdm.1; man oldalt. Az XDM helyett Az alapértelmezett XDM feladatát számos más program is képes ellátni. Ezek közül az egyik a kdm (a KDE része), amire ebben a fejezetben még vissza fogunk térni. A kdm különféle vizuális effekteket és egyéb kozmetikázást ígér, valamint lehetõvé teszi a felhasználók számára, hogy a bejelentkezés elõtt kiválaszthassák a használni kívánt ablakkezelõt. Valentino Vaschetto Írta: Munkakörnyezetek Ebben a szakaszban a &os;-n futó X-hez elérhetõ különbözõ munkakörnyezetekrõl (desktop environment) lesz szó. Maga a munkakörnyezet elnevezés sok mindenre utalhat egy mezei ablakkezelõtõl kezdve az asztali alkalmazások teljes garmadájáig, ahogy igaz ez a KDE vagy a GNOME esetében is. A GNOME Röviden a GNOME-ról GNOME A GNOME egy felhasználóbarát munkakörnyezet, aminek segítségével a felhasználók számára gyerekjáték a számítógép használata és beállítása. A GNOME-ban találhatunk egy panelt (az alkalmazások indítására és különféle állapotjelzõk megjelenítéséhez), egy asztalt (ahova az alkalmazások és az adatok kerülnek), szabványos asztali eszközöket és alkalmazásokat, valamint számos konvenciót, aminek mentén az alkalmazások könnyen együtt tudnak mûködni és tartani egymással az összhangot. Más operációs rendszerek vagy környezetek ismerõi otthon érezhetik magukat ebben a GNOME által nyújtott vizuális környezetben. A &os; és a GNOME kapcsolatáról bõvebb információkat a &os; GNOME Projekt honlapján találhatunk. Ezen az oldalon a GNOME telepítésérõl, beállításáról és karbantartásáról egy meglehetõsen átfogó leírást olvashatunk. A GNOME telepítése A programot könnyen fel tudjuk telepíteni csomagból vagy a Portgyûjtemény segítségével: A hálózatról a GNOME csomagját mindössze ennek a sornak a beírásával fel tudjuk telepíteni: &prompt.root; pkg_add -r gnome2 A portfa felhasználásával pedig a GNOME-ot így tudjuk forrásból telepíteni: &prompt.root; cd /usr/ports/x11/gnome2 &prompt.root; make install clean Miután a GNOME-ot sikerült feltelepítenünk, meg kell mondanunk az X szervernek, hogy az alapértelmezett ablakkezelõ helyett a GNOME-ot indítsa el. A GNOME-ot legkönnyebben a GDM, vagyis a GNOME Display Manager használatával indíthatjuk el. A GDM a GNOME részeként települ (habár alapból nincs bekapcsolva), és úgy tudjuk aktiválni, ha /etc/rc.conf állományba beírjuk a gdm_enable="YES" sort. Újraindítás után a GNOME automatikusan elindul bejelentkezéskor — nincs szükség további beállításra. A GNOME-ot parancssorból is elindíthatjuk, ha hozzá megfelelõen beállítjuk az .xinitrc nevû állományt. Ha már van egy saját .xinitrc állományunk, akkor nincs más teendõnk, mint átírni az aktuális ablakkezelõnket hívó sort a /usr/local/bin/gnome-session sorra. Ha nem csináltunk elõtte semmilyen különleges dolgot az említett konfigurációs állománnyal, akkor elegendõ csak ennyit beírnunk: &prompt.user; echo "/usr/local/bin/gnome-session" > ~/.xinitrc Ezt követõen írjuk be a startx parancsot, és a GNOME munkakörnyezete fog elindulni. Ha az XDM-hoz hasonló régebbi bejelentkeztetõ képernyõt használunk, ez a módszer nem fog mûködni. Helyette hozzunk létre egy .xsession nevû futtatható állományt, amely ezt a parancsot tartalmazza. Ehhez nyissuk meg és cseréljük ki benne a korábbi ablakkezelõnk hívását a /usr/local/bin/gnome-session utasításra: &prompt.user; echo "#!/bin/sh" > ~/.xsession &prompt.user; echo "/usr/local/bin/gnome-session" >> ~/.xsession &prompt.user; chmod +x ~/.xsession Megcsinálhatjuk azt is, hogy a bejelentkezéskor választható legyen az ablakkezelõ. A KDE-rõl bõvebben címû szakaszban látni fogjuk, hogyan tudjuk ezt a a KDE bejelentkeztetõ képernyõje, a kdm esetén beállítani. Élsimított betûtípusok a GNOME-mal GNOME élsimított betûk Az X11 a RENDER kiterjesztésén keresztül ismeri az élsimítást. A (GNOME által használt) GTK+ 2.0 és késõbbi változatai is képesek ezt a lehetõséget kihasználni. Az élsimítás beállítása a ban olvasható. Így tehát a GNOME legfrissebb verzióiban már használhatjuk az élsimítást. Ehhez menjünk az Applications Desktop Preferences Font (a magyar változatban ez az Alkalmazások A munkaasztal beállításai Betûk ) menübe, majd válasszuk vagy a Best shapes (A legszebb betûforma), Best contrast (A legjobb kontraszt) vagy a Subpixel smoothing (LCDs) (Simítás a képponton belül (LCD)) menüpontot. A GTK+-ot használó, de közvetlenül a GNOME-hoz nem tartozó alkalmazások esetén pedig állítsuk be a GDK_USE_XFT környezeti változót 1 a program indítása elõtt. A KDE KDE Röviden a KDE-rõl A KDE egy könnyen használható modern munkakörnyezet. Ízelítõül a KDE felhasználók számára felkínált lehetõségei közül: Gyönyörû, korszerû munkafelület Az asztal hálózaton keresztüli transzparens kezelése A KDE asztal és alkalmazásainak használatában egy beépített súgórendszer segíti a kényelmes és összefüggõ közlekedést A KDE alkalmazásainak összehangolt kinézete és hangulata Szabványosított menük és eszköztárak, billentyû-hozzárendelések, színsémák stb. Honosítás: a KDE több, mint 40 nyelven elérhetõ Központosított, összehangolt, párbeszédablak alapú asztalbeállítás Számos hasznos KDE-alkalmazás A KDE-hez egy Konqueror nevû böngészõ is tartozik, mely a többi &unix;-os böngészõ komoly ellenfelének bizonyul. A KDE-rõl többet a KDE honlapján olvashatunk. A KDE &os;-re vonatkozó tudnivalóiról és a hozzátartozó anyagokról a &os; KDE csapat honlapján találhatunk információkat. &os; alatt a KDE két verziója érhetõ el: a harmadik változat már régóta használható, nagyon megbízható, amely mellett viszont a következõ generációt képviselõ negyedik változat is megtalálható a Portgyûjteményben. Akár egymás mellé is telepíthetõek. A KDE telepítése Ahogy a GNOME és a többi más munkakörnyezet esetében is, maga a program könnyen telepíthetõ csomagból vagy a Portgyûjtemény segítségével is: A KDE3 csomagját hálózaton keresztül így tudjuk telepíteni: &prompt.root; pkg_add -r kde A KDE4 csomagját pedig hálózaton keresztül így tudjuk telepíteni: &prompt.root; pkg_add -r kde4 A &man.pkg.add.1; magától letölti az alkalmazás legfrissebb verzióját. Ha a KDE3 környezetet forrásból akarjuk telepíteni, használjuk a portfát: &prompt.root; cd /usr/ports/x11/kde3 &prompt.root; make install clean Ha viszont a KDE4 környezetet akarjuk inkább a portfa felhasználásával forrásból telepíteni, akkor ezeket a parancsokat adjuk ki: &prompt.root; cd /usr/ports/x11/kde4 &prompt.root; make install clean Miután a KDE-t sikeresen telepítettük, tudatnunk kell az X szerverrel, hogy az alapértelmezett ablakkezelõ helyett ezt indítsa el. Ezt az .xinitrc állomány módosításával érhetjük el. KDE3 esetén: &prompt.user; echo "exec startkde" > ~/.xinitrc KDE4 esetén: &prompt.user; echo "exec /usr/local/kde4/bin/startkde" > ~/.xinitrc Mostantól pedig mindig KDE lesz az asztalunk, amikor az X Window Systemet elindítjuk a startx paranccsal. Ha az XDM-et használjuk bejelentkeztetõ képernyõként, a beállítást némileg máshogyan kell elvégeznünk. Ekkor az iménti helyett az .xsession állományt kell szerkesztenünk. A kdm-re vonatkozó utasítások a fejezet késõbbi részében találhatóak meg. A KDE-rõl bõvebben Most, miután telepítettük a KDE-t a rendszerünkre, a dolgok többsége felfedezhetõ a különféle súgók segítségével vagy egyszerûen a menükre történõ kattintással. A &windows;-hoz vagy &mac;-hez szokott felhasználók itt most már egészen otthonosan érezhetik magukat. A KDE-hez a legtöbb segítséget a saját internetes dokumentációjából nyerhetjük. A KDE a saját böngészõjét, a Konquerort tartalmazza, valamint tucatnyi ügyes alkalmazást és temérdek mennyiségû dokumentációt. A szakasz további részeiben ezért inkább olyan problémákkal foglalkozunk, amelyek megoldásai céltalan kóborlással már nem fedezhetõek fel olyan egyszerûen. A KDE bejelentkeztetõ képernyõje KDE bejelentkeztetõ képernyõ Egy többfelhasználós rendszer karbantartója minden bizonnyal szeretné üdvözölni rendszere felhasználóit egy grafikus bejelentkezõ képernyõn keresztül. A korábbiakban erre a célra az XDM-et javasoltuk. Azonban a KDE erre ajánl egy alternatívát, a kdm-et, amely jóval látványosabb és sokoldalúbb. Ez különösen abban merül ki, hogy a felhasználók (egy menün keresztül) ki tudják választani a bejelentkezés után használni kívánt munkakörnyezetet (legyen az KDE, GNOME vagy bármi más). A kdm használatához az /etc/ttys állományban található ttyv8 bejegyzést kell némileg átalakítanunk. KDE3 esetén: ttyv8 "/usr/local/bin/kdm -nodaemon" xterm on secure KDE4 esetén: ttyv8 "/usr/local/kde4/bin/kdm -nodaemon" xterm on secure Az Xfce Röviden az Xfce-rõl Az Xfce a GNOME által használt GTK+-ra épülõ munkakörnyezet, amely azonban sokkal könnyedebb és azoknak készült, akik egy szimpla, hatékony, mindazonáltal könnyen használható és beállítható munkafelületre vágynak. Látvány szempontjából leginkább a kereskedelmi rendszereken megtalálható CDE-hez hasonlítható. Íme az Xfce néhány jellemzõje: Egyszerû, könnyen kezelhetõ munkaasztal Tökéletesen konfigurálható egérrel, drag-and-droppal (vonszolás) stb. A menükkel, kisalkalmazásokkal és alkalmazásindítókkal tarkított fõpanelje hasonló a CDE paneljéhez Beépített ablak-, állomány- és hangkezelõvel, GNOME kompatibilitási modullal és még sok minden mással rendelkezik Használhatunk témákat (mivel GTK+-ra épül) Gyors, könnyû és hatékony: ideális régebbi vagy lassabb, esetleg kevés memóriával rendelkezõ számítógépekhez Az Xfce-rõl részletesebben az Xfce honlapján olvashatunk. Az Xfce telepítése Az Xfce-hez tartozik bináris csomag (legalább is az leírás készítésének pillanatában). Ezt a következõ módon tudjuk telepíteni: &prompt.root; pkg_add -r xfce4 Vagy a portgyûjtemény használatával forrásból is felrakhatjuk: &prompt.root; cd /usr/ports/x11-wm/xfce4 &prompt.root; make install clean Ezután világosítsuk fel az X szervert, hogy a következõ indulása során mi már az Xfce-t kívánjuk használni. Ehhez csak ennyit kell tennünk: &prompt.user; echo "/usr/local/bin/startxfce4" > ~/.xinitrc Így az X következõ indításakor már az Xfce lesz a munkakörnyezetünk. Ahogy azt már korábban is jeleztük, az XDM használata során a GNOMEban leírtak szerint létre kell hoznunk az .xsession állományt, azonban ezúttal a /usr/local/bin/startxfce4 parancs használatával. Vagy a kdm-rõl szóló szakaszban tárgyaltak mentén beállíthatjuk úgy a bejelentkeztetõ képernyõt, hogy a bejelentkezés elõtt válasszuk ki a munkakörnyezetet.