diff --git a/hu_HU.ISO8859-2/books/fdp-primer/book.sgml b/hu_HU.ISO8859-2/books/fdp-primer/book.sgml index 6966f04761..dd108bab42 100644 --- a/hu_HU.ISO8859-2/books/fdp-primer/book.sgml +++ b/hu_HU.ISO8859-2/books/fdp-primer/book.sgml @@ -1,318 +1,319 @@ %books.ent; %chapters; ]> A &os; Dokumentációs Projekt irányelvei kezdõknek A &os; Dokumentációs Projekt 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 + 2009 DocEng - $FreeBSD$ + $FreeBSD: doc/hu_HU.ISO8859-2/books/fdp-primer/book.sgml,v 1.3 2008/12/24 12:00:57 pgj Exp $ - $FreeBSD$ + $FreeBSD: doc/hu_HU.ISO8859-2/books/fdp-primer/book.sgml,v 1.3 2008/12/24 12:00:57 pgj Exp $ &bookinfo.legalnotice; Köszönjük a részvételt a &os; Dokumentációs Projektben! Minden segítség nagyon fontos számunkra. Ebben az ismertetõben megtalálható a &os; Dokumentációs Projekt munkáját segítõ (kötelezõ és ajánlott) szoftverek és segédeszközök leírásától kezdõdõen a Dokumentációs Projekt mögött álló elképzelések bemutatásáig minden olyan hasznos információ, amelyre szükségünk lehet a munkánk megkezdéséhez. A leíráson folyamatosan dolgozunk, nem tekinthetõ még véglegesnek. A befejezetlen szakaszokat a címükben csillaggal jelöltük meg. Fordította és a fordítást karbantartja: &a.hu.pgj; Bevezetés Parancssori promptok A következõ táblázatban láthatjuk a rendszer alapértelmezett promptját és a rendszeradminisztrátor promptját. A példákban ilyen elemek segítségével fogjuk jelezni, hogy milyen felhasználóként kell azokat lefuttatni. Felhasználó Prompt Egyszerû felhasználó &prompt.user; Rendszeradminisztrátor &prompt.root; Szedési szabályok Az alábbi táblázatban röviden összefoglaljuk a könyvben alkalmazott szedési irányelveket. Leírás Példa Parancsok A ls -l használatával listázzuk ki az összes állományt. Állománynevek Nyissuk meg a .login állományt. Képernyõn megjelenõ üzenetek You have mail. Felhasználói parancsok &prompt.user; su Password: Hivatkozások man oldalakra A &man.su.1; használatával váltsunk felhasználót. Felhasználói- és csoportnevek Ezt kizárólag csak a root felhasználó végezheti el. Kiemelések Ezt meg kell csinálni. Parancssori változók: helyettesítsük egy valódi névvel vagy változóval Az állomány törléséhez adjuk ki az rm állománynév parancsot. Környezeti változók A $HOME a saját felhasználói könyvtárunkat tartalmazza. Megjegyzések, tanácsok, fontosabb információk, figyelmeztetések és példák A szövegben elõfordulhatnak megjegyzések, figyelmeztetések és példák. Így jelennek meg a megjegyzések és általában ránk hatással levõ információkat tartalmaznak, amelyeket érdemes figyelembe vennünk. Így jelennek meg a gyakorta hasznos tanácsok, amelyek esetenként egy másik, gyakran egyszerûbb megoldást mutatnak be. Így jelennek meg a fontosabb információk. Általában még további elvégzendõ lépéseket adnak meg. Így jelennek meg a figyelmeztetések. Határozottan érdemes rájuk figyelni, mert ha nem követjük pontosan a bennük megadott utasításokat, akkor azzal kárt okozhatunk a rendszerünkben. Ez lehet fizikai, tehát a hardvereszközeink sérülését okozó probléma, vagy nem fizikai, tehát például egy fontos állomány akartlan törlése. Mintapélda Így jelennek meg a példák, amelyek jellemzõen valaminek a részletes bemutatását vagy egy konkrét mûvelet eredményét tartalmazzák. Köszönetnyilvánítás Szeretnénk megköszönni Sue Blake, Patrick Durusau, Jon Hamilton, Peter Flynn és Christopher Maden munkáját, akik kellõ fordítottak idõt arra, hogy átolvassák a könyv kezdeti változatait, majd azt számos értékes megjegyzéssel és javaslattal gazdagítsák. &chap.overview; &chap.tools; &chap.sgml-primer; &chap.sgml-markup; &chap.stylesheets; &chap.structure; &chap.doc-build; &chap.the-website; &chap.translations; &chap.writing-style; &chap.psgml-mode; &chap.see-also; &app.examples; diff --git a/hu_HU.ISO8859-2/books/fdp-primer/examples/appendix.sgml b/hu_HU.ISO8859-2/books/fdp-primer/examples/appendix.sgml index 42cdb579c5..c0a3ab43db 100644 --- a/hu_HU.ISO8859-2/books/fdp-primer/examples/appendix.sgml +++ b/hu_HU.ISO8859-2/books/fdp-primer/examples/appendix.sgml @@ -1,452 +1,452 @@ Példatár Ebben a függelékben bemutatunk néhány minta SGML forrást, illetve azokat a parancsokat, amelyekkel egyik formátumból a másikba lehet ezeket alakítani. Amennyiben sikeresen telepítettük rendszerünkre a Dokumentációs Projektben használt segédprogramokat, akkor az itt megadott minta forrásokat akár közvetlenül is fel tudjuk használni. A mintáképp mellékelt források nem fednek le mindent — nem tartalmazzák az összes korábban ismertetett elemet, és egyáltalán nem térnek ki a rövidebb részek, például bevezetés, elõszó, köszönetnyilvánítás stb. jelölésére. Ha konkrét jelölési megoldásokra lenne szükségünk, akkor kérjük le a repositoryból a doc CVSup gyûjteményt, és nézzük át a benne szereplõ SGML forrásokat, vagy böngésszük ezeket közvetlenül a honlapon keresztül. A félreértések elkerülése végett ezek a példák a szabvány DocBook 4.1 DTD szerint íródtak, mellõzik a &os; kiterjesztéseit. Ugyanúgy nem építkeznek a &os; Dokumentációs Projekt által módosított stíluslapokra sem, hanem a Norm Walsh eredetileg kiadott stíluslapjait használják. Ennek köszönhetõen általános DocBook mintáknak is tekinthetõek. DocBook könyv, a <sgmltag>book</sgmltag> elem DocBook <sgmltag>book</sgmltag> ]]>Könyvminta<![ CDATA [ ]]>Vezetéknév ]]>Keresztnév
]]>ize@minta.hu
 2008 ]]>A copyright szövege ]]>Ha tartozik a könyvhöz rövid tartalmi összefoglaló (absztrakt), akkor azt ide írjuk. ]]>Elõszó<![ CDATA [ ]]>A könyvhöz tartozhat elõszó is, amelyet itt kell szerepeltetnünk. ]]>Elsõ fejezet<![ CDATA [ ]]>Ez a könyv elsõ fejezetének tartalma. ]]>Az elsõ szakasz<![ CDATA [ ]]>Ez a könyv elsõ szakasza. ]]> DocBook cikk, az <sgmltag>article</sgmltag> elem DocBook <sgmltag>article</sgmltag>
]]>Cikkminta<![ CDATA [ ]]>Vezetéknév ]]>Keresztnév
ize@minta.hu
 2008 ]]>A copyright szövege ]]>Ha tartozik a cikkhez rövid tartalmi összefoglalás (absztrakt), akkor annak ide kell kerülnie. ]]>Elsõ szakasz<![ CDATA [ ]]>Ez a cikk elsõ szakasza. ]]>Elsõ alszakasz<![ CDATA [ ]]>Ez a cikk elsõ alszakasza.
]]> A formázott kimenet elõállítása Ebben a szakaszban feltételezzük, hogy már vagy kézzel vagy pedig a hozzátartozó port segítségével telepítettük a textproc/docproj portban szereplõ segédeszközöket. Emellett továbbá még feltesszük, hogy az összes eszközt a /usr/local könyvtár alá telepítettük és a binárisok elérési útvonala része a PATH környezeti változónak. Amennyiben ezektõl a feltételezésektõl valamilyen módon eltértünk, akkor a példákat értelemszerûen a saját környezetünkre alkalmazva kell végrehajtani. A Jade használata DocBook forrás átalakítása HTML formátumúra (egyetlen nagy állomány) &prompt.user; jade -V nochunks \ -c /usr/local/share/sgml/docbook/dsssl/modular/catalog \ -c /usr/local/share/sgml/docbook/catalog \ -c /usr/local/share/sgml/jade/catalog \ -d /usr/local/share/sgml/docbook/dsssl/modular/html/docbook.dsl \ -t sgml állomány.sgml > állomány.html A nochunks paramétert adja át a stíluslapoknak és az eredményt a szabványos kimenetre irányítattja át (Norm Walsh stíluslapjait használjuk). Megadjuk a Jade által feldolgozandó katalógusokat. Itt három katalógust kell megadni. Az elsõ katalógus a DSSSL stíluslapok, a második a DocBook DTD és a harmadik a Jade számára tartalmaz információkat. A Jade a dokumentum feldolgozásához az itt megadott DSSSL stíluslapot fogja felhasználni. A Jade itt kap utasítást arra, hogy az egyik DTD-ból a másikba alakítsa át a dokumentumot. Ebben a példában most a DocBook DTD-ból alakítunk át a HTML DTD-ba. Megadjuk a feldolgozandó állományt a Jade számára és átirányítjuk a kimenetet egy .html kiterjesztésû állományba. DocBook forrás átalakítása HTML formátumúra (több kisebb állomány) &prompt.user; jade \ -c /usr/local/share/sgml/docbook/dsssl/modular/catalog \ -c /usr/local/share/sgml/docbook/catalog \ -c /usr/local/share/sgml/jade/catalog \ -d /usr/local/share/sgml/docbook/dsssl/modular/html/docbook.dsl \ -t sgml állomány.sgml Megadjuk a Jade által feldolgozandó katalógusokat. Itt három katalógust kell megadni. Az elsõ katalógus a DSSSL stíluslapok, a második a DocBook DTD és a harmadik a Jade számára tartalmaz információkat. A Jade a dokumentum feldolgozásához az itt megadott DSSSL stíluslapot fogja felhasználni. A Jade itt kap utasítást arra, hogy az egyik DTD-ból a másikba alakítsa át a dokumentumot. Ebben a példában most a DocBook DTD-ból alakítunk át a HTML DTD-ba. Megadjuk a feldolgozandó állományt a Jade számára. A stíluslap fogja majd eldönteni, hogy mi legyen a neve a menet közben keletkezõ egyes HTML állományoknak, illetve a gyökérnek (ez az az állomány, ahonnan a dokumentum kezdõdik). Elõfordulhat, hogy ez a parancs szintén csak egyetlen HTML állományt generál. Ez függ a feldolgozandó dokumentum szerkezetétõl és a stíluslap feldarabolást vezérlõ szabályaitól. DocBook forrás átalakítása Postscript formátumúra Az SGML forrást &tex; állománnyá akarjuk alakítani. &prompt.user; jade -V tex-backend \ -c /usr/local/share/sgml/docbook/dsssl/modular/catalog \ -c /usr/local/share/sgml/docbook/catalog \ -c /usr/local/share/sgml/jade/catalog \ -d /usr/local/share/sgml/docbook/dsssl/modular/print/docbook.dsl \ -t tex állomány.sgml Felparaméterezzük a stíluslapot a &tex; formátumú kimenet elõállításához. Megadjuk a Jade által feldolgozandó katalógusokat. Itt három katalógust kell megadni. Az elsõ katalógus a DSSSL stíluslapok, a második a DocBook DTD és a harmadik a Jade számára tartalmaz információkat. A Jade a dokumentum feldolgozásához az itt megadott DSSSL stíluslapot fogja felhasználni. Megadjuk a Jade számára, hogy &tex; formátumú kimenetet készítsen. Az így keletkezõ .tex kiterjesztésû állomány aztán a &jadetex makrócsomaggal együtt átadható bemenetként a tex parancsnak. &prompt.user; tex "&jadetex" állomány.tex A tex parancsot legalább háromszor le kell futtatni. Elõször feldolgozza a dokumentumot, és szétválogatja az egyes részeit, hogy meg tudja állapítani részeit hivatkoztuk valahonnan máshonnan, hogyan indexelje stb. Ha ebben a fázbisban különbözõ figyelmeztetéseket látunk, mint például LaTeX Warning: Reference `136' on page 5 undefined on input line 728., akkor még ilyenkor ne foglalkozzunk különösebben velük. A második futtatás során újra feldolgozza a dokumentumot a korábbi feldolgozásból származó bizonyos elõismeretek (például a dokumentum oldalszámának) alapján. Ekkor az indexek és a kereszthivatkozások már gond nélkül feloldhatóak. A harmadik menetben elvégzi az utolsó simításokat, amennyiben szükség van rájuk. Ebben a fázisban egy állomány.dvi alakú eredményt kapunk. Végezetül az imént kapott .dvi állomány Postscript formátumúra alakításához futtassuk le a dvips parancsot: &prompt.user; dvips -o állomány.ps állomány.dvi DocBook forrás átalakítása PDF formátumúra A feldolgozási folyamat elsõ része hasonló ahhoz, amikor DocBook forrásból akarunk Postscript formátumú állományt készíteni, tehát elegendõ a jade parancsot az elõbb megadott paraméterekkel meghívni (lásd ). Amikor viszont megkaptuk a .tex állományt, akkor a pdfTeX programot futtassuk le rá. Ügyeljünk arra, hogy ekkor már a &pdfjadetex makrócsomagot kell használnunk: &prompt.user; pdftex "&pdfjadetex" állomány.tex Ebben az esetben is háromszor kell lefuttatnunk a parancsot. Ennek eredményeképpen aztán végül elõáll egy további feldolgozást már nem igénylõ állomány.pdf állomány. diff --git a/hu_HU.ISO8859-2/books/fdp-primer/psgml-mode/chapter.sgml b/hu_HU.ISO8859-2/books/fdp-primer/psgml-mode/chapter.sgml index 18a197292c..6587b0a93a 100644 --- a/hu_HU.ISO8859-2/books/fdp-primer/psgml-mode/chapter.sgml +++ b/hu_HU.ISO8859-2/books/fdp-primer/psgml-mode/chapter.sgml @@ -1,242 +1,242 @@ Az <literal>sgml-mode</literal> használata az <application>Emacs</application> szövegszerkesztõben Az Emacs és XEmacs újabb változataihoz tartozik egy psgml nevû, nagyon hasznos csomag (a Portgyûjteménybõl a editors/psgml portból + role="package">editors/psgml portból telepíthetjük fel). Ez a kiegészítés vagy az .sgml állományok megnyitásakor töltõdik be automatikusan, vagy pedig az M-x sgml-mode parancs begépelésével. Általánosságban véve ez az SGML állományok és a bennük található elemek és tulajdonságok szerkesztésére alkalmas mód. Az alábbiakban bemutatunk néhány olyan alapvetõ parancsot ebben a módban, amelyekkel könnyebbé válik a különbözõ SGML dokumentumok, többek közt a kézikönyv szerkesztése. C-c C-e Meghívja az sgml-insert-element függvényt. Ekkor meg kell adnunk az adott pontra beillesztendõ elem nevét. Itt a Tab lenyomásával kérhetjük a név kiegészítését, az adott ponton érvénytelen elemek neveit ilyenkor nem érhetjük el. A szövegbe ekkor bekerülnek az elemhez tartozó kezdõ- és zárócímkék. Amennyiben az elemhez még tartoznak más egyéb kötelezõ elemek is, akkor egyúttal ezek is beszúródnak. C-c = Meghívja az sgml-change-element-name függvényt. A parancs használatához álljunk a módosítandó elembe. A végrehajtáshoz meg kell még adnunk azt is, hogy mire akarjuk átírni az elem nevét. Ezután az érintett elem kezdõ- és zárócímkéi lecserélõdnek. C-c C-r Meghívja az sgml-tag-region függvényt. A használatához elõször jelöljük ki a szöveg egy részét (vigyük a kurzort a kijelölés kezdetéhez, adjuk ki a C-space billentyûparancsot, vigyük a kurzort a kijelölés végéhez és ismét adjuk ki a C-space parancsot). Ezután meg kell adnunk még a bejelölt rész jelöléséhez használni kívánt elemet. Ennek eredményeképpen végül a kijelölt szakasz elejére és végére bekerül az adott elem kezdõ- és zárócímkéje. C-c - Meghívja az sgml-untag-element függvényt. Álljunk a kurzorral az eltávolítani kívánt elem kezdõ- vagy zárócímkéjére és adjuk ki a parancsot. Ekkor az elem kezdõ- és zárócímkéi törlésre kerülnek. C-c C-q Meghívja az sgml-fill-element függvényt. Ennek hatására az elem, amelyben állunk a kurzorral rekurzívan feldolgozásra kerül (például újraformázódik). Ez a változtatás a tördelést is érinteni fogja, tehát például még programlisting elemek esetében is. Ezért mindig csak körültekintéssel alkalmazzuk! C-c C-a Meghívja az sgml-edit-attributes függvényt. Ekkor a legközelebbi befoglaló elemhez megnyílik egy másik szerkesztési pufferben az összes hozzátartozó tulajdonság, értékekkel együtt. Itt a Tab lenyomásával tudunk lépkedni az egyes elemek között, a C-k paranccsal lecserélni egy meglevõ értéket egy újra, illetve a C-c C-c paranccsal bezárni a puffert és visszatérni az eredeti dokumentum szerkesztéséhez. C-c C-v Meghívja az sgml-validate függvényt. Felajánlja a jelenleg megnyitott dokumentum mentését (amennyiben szükséges) és ellenõrzi az SGML szabvány szerinti érvényességét. A vizsgálat eredménye egy új pufferbe kerül, ahol szépen sorban végig tudjuk nézni az összes hibát és javítani ezeket menet közben. C-c / Meghívja az sgml-insert-end-tag függvényt. Bezárja a kurzor elõtt megkezdett elemet. Nyilvánvalóan ebben a módban még vannak további hasznos funkciók, de az említetteket használják a leggyakrabban. A Dokumentációs Projekten belüli munkához az .emacs állományban a következõ bejegyzéseket érdemes megadni a megfelelõ tördeléshez, elrendezéshez és sorszélességhez: (defun local-sgml-mode-hook (setq fill-column 70 indent-tabs-mode nil next-line-add-newlines nil standard-indent 4 sgml-indent-data t) (auto-fill-mode t) (setq sgml-catalog-files '("/usr/local/share/sgml/catalog"))) (add-hook 'psgml-mode-hook '(lambda () (local-psgml-mode-hook))) diff --git a/hu_HU.ISO8859-2/books/fdp-primer/see-also/chapter.sgml b/hu_HU.ISO8859-2/books/fdp-primer/see-also/chapter.sgml index 8b6316ae04..e3569df87f 100644 --- a/hu_HU.ISO8859-2/books/fdp-primer/see-also/chapter.sgml +++ b/hu_HU.ISO8859-2/books/fdp-primer/see-also/chapter.sgml @@ -1,148 +1,148 @@ Lásd még... Ez a dokumentum szándékosan nem törekszik az SGML és az említett DTD-k, valamint a &os; Dokumentációs Projekt részletes bemutatására. Ezekrõl részletesebb információkat az ebben a fejezetben összegyûjtött hivatkozások mentén kaphatunk. &os; Dokumentációs Projekt A &os; Dokumentációs Projekt honlapja A &os; kézikönyv SGML Az SGML/XML honlapja, minden, ami SGML Könnyed + url="http://www-sul.stanford.edu/tools/tutorials/html2.0/gentle.html">Könnyed bevezetés az SGML használatába (angolul) HTML A World Wide Web Consortium honlapja A HTML 4.0 specifikációja DocBook DocBook Mûszaki Bizottság, a DocBook DTD karbantartói DocBook: The Definitive Guide, a DocBook DTD interneten olvasható dokumentációja Nyílt DocBook Repository, különbözõ DSSSL stíluslapok és egyéb források a DocBook felhasználók számára Linux Dokumentációs Projekt - A Linux + A Linux Dokumentációs Projekt honlapja diff --git a/hu_HU.ISO8859-2/books/fdp-primer/structure/chapter.sgml b/hu_HU.ISO8859-2/books/fdp-primer/structure/chapter.sgml index f454408b71..d7bc408aee 100644 --- a/hu_HU.ISO8859-2/books/fdp-primer/structure/chapter.sgml +++ b/hu_HU.ISO8859-2/books/fdp-primer/structure/chapter.sgml @@ -1,412 +1,408 @@ A dokumentumok szervezése a <filename>doc/</filename> könyvtáron belül A doc/ könyvtár tartalma egy adott módon szervezõdik, és ennek megfelelõen a &os; Dokumentációs Projektben készített dokumentumok is adott módon kerülnek elrendezésre. Célunk ezzel megkönnyíteni az újabb dokumentációk felvételét, illetve: leegyszerûsíteni az új dokumentum automatikus átalakítását különbözõ formátumokba; megteremteni a különbözõ dokumentumok közti következetes elrendezést, így könnyebben lehet köztük váltani munka közben; segíteni az új dokumentumok helyének egyszerû eldöntésében. Mindezek mellett a dokumentációt tároló könyvtárnak olyan felépítésûnek kell lennie, amely lehetõvé teszi több különbözõ nyelven és több különbözõ kódolásban írt dokumentumok kényelmes elhelyezését. Fontos hozzátennünk, hogy a könyvtár szerkezete nem követel meg semmilyen különleges elõfeltételezést vagy kulturális berendezkedést. A legfelsõ szint: a <filename>doc/</filename> könyvtár A doc/ további két, különleges névvel és jelentéssel rendelkezõ könyvtárat rejt. Könyvtár Leírás share/ Ebben a könyvtárban találjuk azokat az állományokat, amelyek függetlenek az egyes fordításoktól és kódolásoktól. A benne található alkönyvtárakon keresztül tovább csoportosítódik a tartalmuk. Például a dokumentáció elõállításához kapcsolódó &man.make.1; infrastruktúra állományai a share/mk, miközben a SGML használatához szükséges további állományok (mint például a &os; kiterjesztéseit tartalmazó DocBook DTD) a share/sgml alkönyvtárban helyezkednek el. nyelv.kódolás/ Minden fordításhoz és annak kódolásához tartozik egy könyvtár, például en_US.ISO8859-1 vagy hu_HU.ISO8859-2. A nevek alapvetõen hosszúak, de pontosan meghatározzák az adott nyelvet és a dokumentáció írásához alkalmazott kódolást. Ezzel igyekszük felkészülni olyan esetekre, amikor a fordítócsapatok egy nyelven többféle kódolás szerint is szeretnének dokumentációt készíteni. Ez a megoldás egyben kiutat szolgáltat egy esetleges késõbbi, Unicode kódolásra váltás során felmerülõ problémák elõl. A <filename><replaceable>nyelv</replaceable>.<replaceable>kódolás</replaceable>/</filename> könyvtárak Ezek a könyvtárak tartalmazzák magukat a dokumentumokat. A dokumentumokat ezen a szinten a különbözõ könyvtárak neveinek megfelelõen három vagy több kategóriára osztjuk. Könyvtár Tartalom articles Az itt található dokumentumokat a DocBook article eleme szerint (vagy egy azzal egyenlõ megoldással) jelöltük. Viszonylag rövid, szakaszokra osztott dokumentumokat találhatunk itt. Általában egyetlen HTML állományként érhetõek el. books Ebben a könyvtárban a DocBook book eleme szerint (vagy egy azzal egyenlõ megoldással) jelöltük. Hosszabb, fejezetekre osztott dokumentum. Általában egyetlen nagyobb HTML állományként (a gyors internetkapcsolattal rendelkezõ, vagy a dokumentumot a böngészõbõl nyomtatni kívánó egyének számára), illetve több kisebb állományként együtteseként is elérhetõ. man A rendszerhez tartozó man oldalak fordításai. A lefordított szakaszoknak megfelelõen ebben a könyvtárban egy vagy több mann nevû alkönyvtárat találhatunk. Nem mindegyik nyelv.kódolás könyvtár tartalmazza ezeket az alkönyvtárakat. Az egyes fordítások tartalma mindig attól függ, hogy az adott fordítócsapatnak mennyit sikerült eddig lefordítania. Az egyes dokumentumokkal kapcsolatos tudnivalók Ebben a szakaszban a &os; Dokumentációs Projekt keretein belül gondozott különbözõ dokumentumokat ismerhetjük meg részletesebben. A kézikönyv books/handbook/ A kézikönyv a &os; kiterjesztéseit tartalmazó DocBook DTD szerint készült. A kézikönyv a DocBook book elemének megfelelõen szervezõdik. Több part elemmel jelölt részbõl áll, amelyek mindegyike több chapter elemmel jelölt fejezetet foglal magában. Ezek a fejezetek további szakaszokra (sect1) bomlanak, amelyek helyenként alszakaszokra (sect2, sect3) oszlanak, és így tovább. Fizikai szervezés A kézikönyv forrásai több különbözõ állományban és könyvtárban a handbook könyvtáron belül találhatóak. A kézikönyv szervezése idõrõl-idõre változik, ezért könnyen elõfordulhat, hogy ez a dokumentum csak kissé késve követi ezeket a változtatásokat. Ha további kérdéseink lennének a kézikönyv szervezésérõl, bátran írjunk a &a.doc; címére! <filename>Makefile</filename> A Makefile állományban definiálódnak olyan változók, amelyek a SGML források különbözõ formátumúra alakításának menetét befolyásolják, illetve hivatkozik a kézikönyv forrásaira. Ezután beemeli a doc.project.mk állományt, és így lényegében betölti a dokumentumok átalakításáért felelõs további utasításokat. <filename>book.sgml</filename> Ez a kézikönyv legfelsõ szintû dokumentuma. Ebben van a kézikönyv dokumentípus-deklarációja, illetve a szerkezetét leíró további elemek. A book.sgml az .ent kiterjesztésû állományokat paraméteregyedek segítségével tölti be. Ezek az állományok (amelyekrõl késõbb még szó lesz) aztán a kézikönyv további részeiben használt általános egyedeket definiálnak. <filename><replaceable>könyvtár</replaceable>/chapter.sgml</filename> A kézikönyv egyes fejezetei egymástól különálló könyvtárakban, chapter.sgml nevû állományokban tárolódnak. Ezeket a könyvtárakat az adott fejezetet jelölõ chapter id tulajdonsága szerint szokták elnevezni. Például ha az egyik fejezet forrásában a következõ sor olvasható: ... ]]> Ekkor a chapter.sgml nevû állományt tartalmazó könyvtár neve kernelconfig lesz. Egy ilyen állomány általában a teljes fejezetet tartalmazza. A kézikönyv HTML változatának készítése során ebbõl a kernelconfig.html állomány fog keletkezni. Ezt azonban az id értéke határozza meg, semmi köze nincs a könyvtár elnevezéséhez. A kézikönyv korábbi változataiban az összes forrás a book.sgml állománnyal volt egy szinten, és az adott chapter elemek id tulajdonságának megfelelõen került - elnevezésre. A könyvtárak - létrehozásával a kézikönyv - szervezésének további - átalakításait kívántuk - elõkészíteni. Itt - különösen gondolunk arra, hogy ezzel - szeretnénk lehetõvé tenni képek - hozzáadását az egyes fejezetekhez. - Véleményünk szerint sokkal több - értelme van ugyanis a képeket a fejezetek - forrásával együtt egy külön - könyvtárban tárolni, mintsem az - összes képet és szöveget egyetlen - nagy könyvtárban összeömleszteni. A + elnevezésre. Az egyes fejezetekhez most már + külön-külön tudunk képeket + csatolni, amelyeket a fejezeteknek megfelelõ + könyvtárban kell elhelyezni a share/images/books/handbook + könyvtáron belül. Ha honosítani + akarjuk a képeket, akkor viszont ügyeljünk + arra, hogy az adott fejezet könyvtárába, + az SGML források mellé tegyük a + lefordított képeket. A névütközés egy idõ után úgyis elkerülhetetlenné válik, és sok, kevés állományt tartalmazó könyvtárral egyébként is könnyebb dolgozni, mint egy sok állományt tartalmazó könyvtárral. A kézikönyv forrásaiban könnyen láthatjuk, hogy sok ilyen könyvtár van, bennük egy-egy chapter.sgml állománnyal. Például basics/chapter.sgml, introduction/chapter.sgml és printing/chapter.sgml. A fejezeteket és könyvtárakat nem szabad semmilyen sorrendiségre utaló módon elnevezni. A fejezetek elrendezése ugyanis változhat a kézikönyv egy esetleges átszervezése során. Az ilyen átszervezések során pedig (általában) nem lenne szabad állományokat átnevezni (hacsak komplett fejezeteket nem mozgatunk fentebb vagy lentebb a szerkezetben). Az egyes chapter.sgml állományok önmagukban teljes SGML dokumentumok. Különösen azért, mert semmilyen DOCTYPE sor nem található az elejükön. Ez abból a szempontból hátrányos, hogy ezeket az állományokat ezért nem tudjuk normál SGML állományokként kezelni. Emiatt ezeket nem lehet egyszerûen, a kézikönyvhöz hasonlóan módon HTML, RTF, PS vagy más egyéb formátumba átalakítani. Ezért tehát könnyen elõfordulhat, hogy a fejezetek megváltoztatásakor a teljes kézikönyvet elõ kell állítanunk. diff --git a/hu_HU.ISO8859-2/books/fdp-primer/the-website/chapter.sgml b/hu_HU.ISO8859-2/books/fdp-primer/the-website/chapter.sgml index b3ef3fa6dd..0502e3e1fd 100644 --- a/hu_HU.ISO8859-2/books/fdp-primer/the-website/chapter.sgml +++ b/hu_HU.ISO8859-2/books/fdp-primer/the-website/chapter.sgml @@ -1,534 +1,552 @@ A honlap Elõkészületek A honlap elõállításához elsõsorban elegendõ szabad területet kell keresnünk valamelyik merevlemezünkön. Ennek mennyisége a választott módszertõl függõen úgy nagyjából 200 MB-tól 500 MB-ig terjedhet. Ez a becslés magában foglalja az SGML eszközökhöz, a CVS repository megfelelõ részeihez, valamint a honlap generálásához szükséges lemezterületet. Mindig ellenõrizzük, hogy a dokumentáció elõállításához használt portok frissek legyenek. Ha nem vagyunk benne biztosak, akkor a portok telepítése elõtt a &man.pkg.delete.1; paranccsal töröljük a korábbi változatukat. Például ha a jade-1.2 csomagra van szükségünk és a rendszerünkön már megtalálható a jade-1.1, akkor a következõt kell tennünk: &prompt.root; pkg_delete jade-1.1 A honlap elõállításához ebben a fejezetben most két módszert adunk meg: A csup parancs használatával hozzuk létre és tartsunk karban a gépünkön a források helyi másolatát valamelyik CVSup szerverrõl. Ez a legegyszerûbb megoldás, mivel semmilyen további szoftver telepítését nem igényli. Ehhez a következõ szakaszban megadott supfile állomány mindig a szükséges állományok legfrissebb változatát kéri le. Ez abban az esetben tökéletesen megfelelõ, ha egyszerûen csak le akarjuk generálni a honlapokat és nem kívánunk a forrásokkal dolgozni. A &man.csup.1; a &os; 6.2-RELEASE kiadástól az alaprendszer része. Amennyiben még a &os; egy korábbi változatát használjuk, akkor ezt a programot a Portgyûjteménybõl a net/csup port telepítésével érhetjük el. A cvsup parancs használatával CVS módban hozzunk létre és tartsunk karban egy helyi CVS repositoryt a szükséges állományokkal. Ehhez például a net/cvsup-without-gui port telepítését kell elvégeznünk, ezáltal viszont egy sokkal rugalmasabb módszert nyerünk abban az esetben, ha gyorsan és könnyedén hozzá szeretnénk férni a doc és www repositorykban tárolt állományok különbözõ revízióihoz, elõzményeihez vagy éppen tárolni szeretnénk a &os; központi CVS repositoryjába. Az egyszerû megoldás: a <command>csup</command> használata A csup az alaprendszer része lett, de egy ideje már nagyon sokan használják, többek közt a saját portgyûjteményük frissítésére. A most következõ példa supfile állománnyal a honlapok elõállításához szükséges állományokat tudjuk elérni: # # Ezzel a konfigurációs állománnyal a &os; honlapjának # legenerálásához szükséges gyûjteményeket tudjuk elérni. # # A http://www.freebsd.org/doc/handbook/mirrors.html honlapon található # felsorolásból válasszuk ki a hozzánk legközelebb elhelyezkedõ CVSup # tükrözést. *default host=cvsup10.FreeBSD.org *default base=/var/db *default prefix=/usr/build *default release=cvs tag=. *default delete use-rel-suffix *default compress # A &os; repository teljes doc ágát lekérjük. doc-all # Lekérjük a honlap forrásait. www # A holnapok elõállításához szükséges néhány alapvetõ port lekérése. ports-base A default host helyére természetesen ne felejtsük el megadni a hozzánk legközelebb elhelyezkedõ CVSup tükrözést (például cvsup.hu.FreeBSD.org), illetve a default prefix bejegyzésnél azt a könyvtárat, ahová a lekért állományokat szeretnénk elhelyezni. Ezután az így kitöltött mintát mentsük el például doc-www-supfile néven és adjuk ki a következõ parancsot: &prompt.root; csup doc-www-supfile A parancs lefutásának eredményeképpen ekkor tehát a default prefix értékeként megadott könyvtáron belül létrejönnek a doc/, www/ és ports/ alkönyvtárak (amely a példánkban a /usr/build volt). Ebben a könyvtárban fogjuk egyébként létrehozni az állományokat, ezért ezt érdemes egy olyan állományrendszerre tenni, ahol tehát elegendõ szabad terület áll rendelkezésre. Remek! Most lépjünk tovább a honlap elõállításáról szóló részhez. A rugalmasabb megoldás: saját doc és www repositoryk létrehozása és karbantartása Ez a módszer több lehetõséget kínál, viszont cserébe telepítenünk kell hozzá a net/cvsup-without-gui portot vagy csomagot. A net/cvsup-without-gui port fordításához szükséges a lang/ezm3 port, vagyis egy Modula 3 fordító. Ennek a fordítása viszonylag sok idõt vesz igénybe és ráadásul a legtöbben nem is használják másra, ezért a CVSup telepítéséhez elsõsorban a csomagok használatát javasoljuk. A CVSup program rendelkezik egy speciális, ún. CVS móddal, amelynek köszönhetõen lehetõvé teszi a CVS repositoryt alkotó ,v állományok elérését. Ez a funkció jelenleg még nem érhetõ el a csup programban. A CVSup részletes bemutatását a &os; kézikönyv A források szinkronizálása címû részében olvashatjuk. A most következõ supfile állomány lekéri a holnapok elõállításához szükséges gyûjteményeket és létrehozza a CVS repository helyi másolatát: # # Ezzel az állománnyal létre tudjuk hozni a CVS repository egy olyan # helyi másolatát, amelyben csak a &os; holnapjának elõállításához # szükséges gyûjtemények találhatóak meg. Jelen pillanatban *kizárólag* # a cvsup paranccsal fog mûködni (a csup programmal tehát nem) *default host=cvsup10.FreeBSD.org *default base=/var/db *default prefix=/usr/dcvs *default release=cvs *default delete use-rel-suffix *default compress # A honlapok generálásához az alábbi gyûjteményekre lesz szükségünk: ports-base doc-all www # A CVS funkciókhoz még ezek a gyûjtemények is kelleni fognak: cvsroot-common cvsroot-ports cvsroot-doc A default host sorban értelemszerûen a hozzánk legközelebb elhelyezkedõ CVSup tükrözést adjuk meg (például cvsup.hu.FreeBSD.org), illetve a default prefix bejegyzésnél pedig azt a könyvtárat, ahol a repository állományait kívánjuk tárolni. Valamilyen, például doc-ww-cvsfile néven mentsük el ezt a mintát és adjuk ki a következõ parancsot: &prompt.root; cvsup doc-www-cvsfile Továbbá érdemes még a parancsértelmezõnk indítóállományaiban beállítani a CVSROOT környezeti változó értékét is. Például vegyük fel az alábbi sort a .cshrc állományunkba: setenv CVSROOT /usr/dcvs Ennek megadásával a repositoryval kapcsolatos mûveletek elvégzésekor a (lentebb látható) parancsból elhagyhatjuk a paraméter megadását. Jelenleg a repositoryban tárolt állományok befogadásához legalább 400 MB tárterületre lesz szükségünk. A honlapok elõállítása során ezen felül ideiglenesen még nagyjából további 200 MB hely kellhet. A cvsup parancs lefutása után már ki is kérhetjük a forrásokat a munkakönyvtárunkba: &prompt.root; mkdir /usr/build &prompt.root; cd /usr/build &prompt.root; cvs /usr/dcvs co doc www ports Ez a parancs lényegében ugyanannak felel meg, ahogy a csup kéri le az állományokat a CVSup szervertõl. A folyamat befejezõdése után a munkakönyvtárban tehát tulajdonképpen ugyanazokat fogjuk találni, mint az egyszerûbb, csup alapú módszer esetében. Az imént bemutatott cvsup parancs folyamatos használatával tudjuk rendszeresen karbantartani a CVS repository helyi másolatát. Az elsõ esetben még viszonylag sok állomány fog letöltõdni, azonban a késõbbiekben már viszont csak néhány percet vesz igénybe a frissítés. A honlapok elõállítása Miután az elõbb tárgyalt módszerek valamelyikével elõkészítettük rendszerünkön a honlapok forrásainak egy naprakész másolatát, készen állunk a honlapok létrehozására. A példánkban az ehhez használt munkakönyvtár a /usr/build volt, ahol már minden szükséges állomány megtalálható. Lépjünk be a munkakönyvtárba: &prompt.root; cd /usr/build A honlapok elõállítása a www/en könyvtárból indul, az all &man.make.1; cél végrehajtásával megkezdõdik a honlapok készítése. &prompt.root; cd www/en &prompt.root; make all A generált honlapok telepítése a webszerverre Ha nem az en könyvtárban állunk, akkor váltsunk vissza rá. &prompt.root; cd /usr/build/www/en A DESTDIR változóban állítsuk be a honlapok tényleges helyét, és futtassuk le vele a install &man.make.1; célt. &prompt.root; env DESTDIR=/usr/local/www make install Ha az elõbb megadott könyvtárba korábban már másoltunk honlapokat, akkor az újabb másolás során nem törlõdnek a régi vagy elavult lapok. Például ha a honlapokat napi rendszereséggel frissítjük, akkor a következõ paranccsal meg tudjuk keresni és törölhetjük azokat a lapokat, amelyeket már három napja nem frissítettünk. &prompt.root; find /usr/local/www 3 | xargs rm Környezeti változók CVSROOT A CVS állományait tároló könyvtár gyökere. Ha a CVSup alapú módszert alkalmazzuk, akkor érdemes a hozzátartozó változót beállítanunk: &prompt.root; CVSROOT=/usr/dcvs; export CVSROOT A CVSROOT egy környezeti változó. Vagy a paranccsorban, vagy pedig a parancsértelmezõnknek megfelelõ konfigurációs állományban (például .profile) kell beállítanunk. Ennek pontos mikéntjét maga a parancsértelmezõ határozza meg (a fenti parancsban például a bash és a hozzá hasonló parancsértelmezõk által alkalmazott megadási mód látható). ENGLISH_ONLY Ha beállítjuk és nem üres, akkor a folyamat során csak az angol nyelvû oldalak fognak elkészülni, a fordítások figyelmen kívül maradnak. Például: &prompt.root; make ENGLISH_ONLY=YES all install Ha le akarjuk tiltani az ENGLISH_ONLY hatását és az összes oldalt az összes elérhetõ fordítással létrehozni, akkor az ENGLISH_ONLY változónak adjunk üres értéket: &prompt.root; make ENGLISH_ONLY="" all install clean WEB_ONLY Ha beállítottuk és az értéke nem üres, akkor hatására csak a www könyvtárban található HTML oldalak állítódnak elõ és telepítõdnek. Ilyenkor a doc könyvtár teljes tartalma (kézikönyv, GYIK és egyéb leírások) figyelmen kívül marad. &prompt.root; make WEB_ONLY=YES all install + + WEB_LANG + + + Ha beállítottuk, akkor a www könyvtáron + belül csak a benne megadott nyelvekhez tartozó + könyvtárak fognak + elõállítódni. Az angol + kivétel tehát ilyenkor minden más nyelv + kimarad a feldolgozásból. + Például: + + &prompt.root; make WEB_LANG="el es hu nl" all install + + + NOPORTSCVS Ennek megadásakor a Makefile állományok nem kérnek ki állományokat a portokhoz tartozó repositoryból. Ehelyett a szükséges állományokat közvetlenül a /usr/ports könyvtárból (vagy ahova a PORTSBASE változó értéke mutat) fogják átmásolni. - A WEB_ONLY, ENGLISH_ONLY - és NOPORTSCVS változók a + A WEB_ONLY, WEB_LANG, + ENGLISH_ONLY és + NOPORTSCVS változók a make programhoz tartoznak. Ezek értékét az /etc/make.conf állományban, vagy környezeti változókhoz hasonlóan parancssorból, illetve a parancsértelmezõ konfigurációs állományaiban állíthatjuk be. diff --git a/hu_HU.ISO8859-2/books/fdp-primer/writing-style/chapter.sgml b/hu_HU.ISO8859-2/books/fdp-primer/writing-style/chapter.sgml index 6de288dd69..7b971d008c 100644 --- a/hu_HU.ISO8859-2/books/fdp-primer/writing-style/chapter.sgml +++ b/hu_HU.ISO8859-2/books/fdp-primer/writing-style/chapter.sgml @@ -1,664 +1,664 @@ A fogalmazás stílusa A &os; dokumentációját készítõ rengeteg író munkájának összehangolására ebben a fejezetben megadunk néhány követendõ alapelvet. Az angol nyelvû dokumentáció írásakor az amerikai angol szerinti helyesírást használjuk! A szavak helyesírását tekintve az angolnak több különbözõ változata létezik. Vitás helyzetekben az egységesség kedvéért ezért mindig az amerikai helyesírást tekintsük irányadónak. Ennek megfelelõen tehát color és nem colour, rationalize és nem rationalise, stb. A brit angol használata elfogadott lehet beküldött cikkek esetében, viszont ilyenkor a helyesírásnak egységesnek kell lennie a teljes dokumentumon belül. Az összes többi dokumentum, tehát könyvek, honlapok, man oldalak stb. esetén azonban mindig amerikai angolt kell alkalmazni. Ne rövidítsünk! Ne alkalmazzunk rövidítéseket a szövegben. Mindig minden kifejezést, szót írjunk ki teljes alakjában. Pl. ez a példa tehát nem helyes. Angol nyelven mindez az összevonások elkerülésére vonatkozik, tehát a formális fogalmazási stílusra. A rövidítések elhagyásával könnyebb a szövegnek formális jelleget adni, így sokkal precízebben megfogalmazott, a fordítók számára is érthetõbb mondatokat nyerünk. A felsorolásoknál tegyünk ki vesszõket! Angol nyelven, ha több elemet sorolunk fel egyetlen bekezdésben, akkor ezeket mindig vesszõkkel kell tagolnunk. Az utolsó elemnél mindezt egészítsük ki még egy and (és) szóval. A magyarban figyeljünk arra, hogy ez elé már nem kell vesszõ. Például tekintsük a következõ mondatot:
This is a list of one, two and three items.
Magyarul:
Ez a lista egy, két és három elembõl áll.
Az angol változat esetén felvetõdhet a kérdés, hogy ez a lista most egy, két és három elembõl áll, vagy egy, két és három elembõl. Ezért itt az utolsó tag elõtt is ki kell tenni a vesszõt:
This is a list of one, two, and three items.
Kerüljük a szóismétlést! Lehetõség szerint törekedjünk a szóismétlések elkerülésére. Ez konkrétan a a parancs, az állomány és man parancs jellegû kifejezések mellõzését jelenti, mert ezek sokszor feleslegesen szerepelnek a szövegben. A magyar fordításban azonban néha hasznosnak bizonyulnak, különösen a ragozásban. Most mutatunk két példát a parancsokra. Ezek közül a másodikban bemutatott stílust javasoljuk az angol szövegek esetén. Use the command cvsup to update your sources. Use cvsup to update your sources. A magyar szövegben viszont ennek tökéletesen elfogadott a következõ típusú fordítása, mivel így könnyebb ragozni a parancsot: A forrásainkat a cvsup paranccsal frissítsük. Ha a magyarban is el akarjuk kerülni minden áron az ilyen jellegû ismétléseket, akkor próbálkozhatunk úgy írni a mondatot, hogy ne kelljen az idegen szót ragoznunk: A cvsup segítségével frissítsük a forrásainkat. Az alábbi példákban az állományok neveire láthatunk példákat, amelyek közül ismét a másodikat javasoljuk az angol nyelv esetén: … in the filename /etc/rc.local… … in /etc/rc.local… A magyarban szintén a korábbiak érvényesek. A most következõ példákban man hivatkozásokat láthatunk. Közülük ismét a második lesz a javasolt: See man csh for more information. See &man.csh.1;. A magyar fordításban: Lásd &man.csh.1;. Vagy: Lásd a &man.csh.1; man oldalt. Mindig hagyjunk két szóközt a mondatok között! A mondatok végén mindig hagyjunk két szóköznyi helyet. Ezáltal javul a szöveg olvashatósága, valamint megkönnyíti az Emacs és a hozzá hasonló eszközök használatát. Habár vitatható, hogy ez a megkülönböztetés egyáltalán szükséges-e, bizonyos esetekben valóban hasznos lehet, különösen neveknél. Erre remek példa Jordan K. Hubbard. Ebben a névben középen található egy H, amelyet a mondat végéhez hasonlóan egy pont és egy szóköz követ, viszont jól látható, hogy itt nem ér véget a mondat. Az angol nyelvû fogalmazási stílus szabályairól részletesebb bemutatást William Strunk Elements of Style címû könyvébõl kaphatunk. A forráskód stílusa Mivel a dokumentáció forrását egyszerre többen szerkesztik, valamilyen módon egységes formában kell tartani. Ennek érdekében legyünk szívesek az alábbiakban megadott iránymutatások szerint dolgozni. Kis- és nagybetûk A címkéket soha ne nagybetûkkel, hanem mindig kisbetûkkel írjuk, például para és nem PARA. Az SGML környezetekben megjelenõ szövegeket viszont általában nagybetûvel kell írni, például <!ENTITY…>, <!DOCTYPE…>, és nem <!entity…> vagy <!doctype…>. Mozaikszavak A mozaikszavakat elsõ alkalommal általában illik rendesen kiírni, például: Network Time Protocol (NTP). Miután definiáltuk a mozaikszó mögött álló jelentést, elegendõ csak a rövidített alakot használni (nem kell tehát a teljes kifejezést, kivéve, ha az adott szövegkörnyezetben annak több értelme van). A mozaikszavakat dokumentumonként egyszer definiáljuk. Ha viszont nekünk jobban megfelel, akkor akár fejezetenként is kifejthetjük az egyes mozaikszavakat. A mozaikszavak elsõ három megjelenését az acronym elemmel kell jelölni, ahol egy role tulajdonságban megadjuk a mögött álló teljes kifejezést. Ennek köszönhetõen a dokumentumok feldolgozása során létre lehet hozni szószedetet az alkalmazott rövidítésékhez, illetve a honlapokon meg lehet oldani, hogy ha az egérrel felé visszük a kurzort, megjelenjen a teljes megnevezés. Tördelés Mindegyik forrás tördelése a nulladik oszloptól indul, függetlenül attól, hogy az adott állományt milyen más állomány fogja késõbb tartalmazni. A nyitócímkék után két szóközzel kell bentebb húzni a szöveget. Ennek megfelelõen a zárócímkék pedig két szóközzel csökkentik az aktuális behúzás mértékét. A sorok elején szereplõ szóközöket nyolcas csoportban cseréljünk tabulátorokra. Ne használjunk szóközöket a tabulátorok elõtt, és ne tegyünk további szóközöket a sorok végére. Ha az elemek tartalma egy sornál hosszabb, akkor a következõ sort az elem nyitócímkéjéhez képest mindig két szóközzel bentebb kell kezdeni. Például ennek a szakasznak így néz ki a szabályos tördelése: +--- Ez a nulladik oszlop V <chapter> <title>...</title> <sect1> <title>...</title> <sect2> <title>Tördelés</title> <para>Mindegyik forrás tördelése a nulladik oszloptól indul, <emphasis>függetlenül</emphasis> attól, hogy az adott állomány milyen más állomány fogja késõbb tartalmazni.</para> ... </sect2> </sect1> </chapter> Ha az Emacs vagy XEmacs szerkesztõkkel dolgozunk, akkor az állományok megnyitásakor automatikusan be kellene töltõdnie az sgml-mode kiegészítésnek, illetve az egyes források végén található változók pontosan a fenti szabályok betartatásáról gondoskodnak. A Vim szerkesztõvel dolgozóknak pedig a következõ beállításokat javasoljuk: augroup sgmledit autocmd FileType sgml set formatoptions=cq2l " Speciális formázási beállítások autocmd FileType sgml set textwidth=70 " Legfeljebb 70 oszlop széles sorok autocmd FileType sgml set shiftwidth=2 " Az automatikus behúzás mértéke autocmd FileType sgml set softtabstop=2 " A tabulátor 2 szóközzel visz bentebb autocmd FileType sgml set tabstop=8 " 8 szóköz cseréje egy tabulátorra autocmd FileType sgml set autoindent " Automatikus behúzás augroup END A címkék stílusa A címkék elrendezése Az egy behúzási szinten található címkéket mindig válasszuk el egy üres sorral, a többi esetben viszont ne: <article> <articleinfo> <title>NIS</title> <pubdate>1999 október</pubdate> <abstract> <para>... ... ...</para> </abstract> </articleinfo> <sect1> <title>...</title> <para>...</para> </sect1> <sect1> <title>...</title> <para>...</para> </sect1> </article> A címkék tagolása Bizonyos címkék, mint például az itemizedlist, amelyekben további címkék szerepelnek és nem karakteres adat, mindig egyedül állnak egy sorban. A para és term címkék esetén viszont szükség van további címkékre a karakteres adatok befoglalásához, ezért ilyenkor a tartalom közvetlenül a címke után következik, ugyanabban a sorban. Ugyanez érvényes az említett címketípusok zárásakor. A címketípusok keveredése egy nyilvánvaló problémát eredményez. Amikor egy karakteres adatot tárolni nem képes elemet nyitó címke közvetlenül követ egy karakteres adatokat bevezetõ címkét, külön sorba kell kerülniük. A második címkét a szabályok szerint kell behúzni. Amikor egy karakteres adatokat befoglaló címke záródik közvetlenül a karakteres adatokat tartalmazni nem képes címke után, szerepelhetnek ugyanabban a sorban. Változtatások a forrás tördelésén A források változtatása során ügyeljünk arra, hogy sose tároljunk egyszerre a repositoryba tartalmat és tördelést érintõ módosításokat. Ennek köszönhetõen a dokumentációt fordító csapatok könnyebben észreveszik, hogy mi változott a módosításunk nyomán. Így nem kell azon gondolkozniuk, hogy vajon most tényleg változott a tartalom, vagy csak újratördeltük a sorokat. Például ha felvettünk két mondatot még egy bekezdéshez, és ezzel az adott bekezdés sorainak hossza túlságosan megnõtt, akkor elõször tároljuk a hosszú sorokat tartalmazó változatot. Ezután végezzük el a szükséges tördelést és tároljuk azt a változatot is. Ez utóbbi esetben azonban ne felejtsük egyértelmûen jelezni a tároláshoz tartozó üzenetben, hogy csak a tördelésen változtattunk (whitespace-only change). Így a fordítók tudni fogják, hogy ezt figyelmen kívül kell hagyniuk. Nem törhetõ szóközök Lehetõleg kerüljük a sortöréseket olyan helyeken, ahol csúnyán néznének ki, vagy rontanának a szöveg olvashatóságán. A sortörések mindig a kimeneti formátum által alkalmazott sorszélességtõl függenek. Különösen a HTML oldalakon található formázott bekezdések jelennek meg ízléstelenül egy szöveges böngészõben, mint például ez is: Az adattároló kapacitása általában 40 MB és 15 GB között változik. Hardveres tömörítéssel … Az &nbsp; általános egyed viszont megtiltja az egymáshoz szorosan kötõdõ elemek közti sortörést. Az ilyen nem törhetõ szóközök használatát elsõsorban a következõ helyeken javasoljuk: mennyiségek és egységek között: program neve és verziószáma között: több szóból álló nevek esetén (óvatosan bánjunk ezzel viszont olyan hosszabb neveknél, mint például a The &os; Brazilian Portugese Documentation Project): Szólista Ebben a rövid szólistában összefoglalunk néhány angol szót a &os; Dokumentációs Projektben alkalmazandó írásmódjuk szerint. Ha a keresendõ szó nem szerepel ebben a felsorolásban, nézzük meg az O'Reilly-féle gyûjteményt. 2.2.X 4.X-STABLE CD-ROM DoS (Denial of Service) Ports Collection IPsec Internet MHz Soft Updates Unix disk label email file system manual page mail server name server null-modem web server 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 acddd7bf99..6c6500278b 100644 --- a/hu_HU.ISO8859-2/books/handbook/cutting-edge/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/cutting-edge/chapter.sgml @@ -1,3966 +1,3977 @@ 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 a CVSup 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 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: &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 ... 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: &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 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 adjuk ki az alábbi utasításokat: &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; 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/eresources/chapter.sgml b/hu_HU.ISO8859-2/books/handbook/eresources/chapter.sgml index 808c1b1d1c..1a8f994cc2 100644 --- a/hu_HU.ISO8859-2/books/handbook/eresources/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/eresources/chapter.sgml @@ -1,2556 +1,2585 @@ Források az interneten A &os; gyors ütemû fejlõdése a nyomtatott médiát alkalmatlanná teszi a legfrissebb fejlesztések nyomonkövetésére. Ezzel szemben az elektronikus erõforrások a biztos, ha gyakran nem is csak az egyetlen, módjai a legújabb elõrelépések figyelemmel követésének. Mivel a &os;-t többségében önkéntesek fejlesztik, az õt körülvevõ felhasználói közösség önmaga is egyfajta szakmai segélynyújtó egyletként funkcionál, amelyet leghatékonyabban elektronikus levélben, webes fórumokon vagy USENET hírcsoportokon keresztül érhetünk el. A továbbiakban a &os; felhasználók közösségének különbözõ fajtájú elérhetõségeit vázoljuk fel nagyvonalakban. Ha úgy érezzük, hogy ebbõl a felsorolásban kimaradt volna valami, akkor ne habozzunk róla értesítést küldeni a &a.doc; címére (angolul), hogy felvehessük a többi közé. Levelezési listák A &os; köré csoportosulókat levelezési listákon keresztül tudjuk közvetlenül elérni, ezen a módon tehetünk fel kérdéseket, vethetünk fel témákat. Ezek között több különbözõ területtel foglalkozó listát találhatunk. Ezért célszerû mindig a hozzászólásainkat a témánkhoz legközelebb álló listára küldeni, mert enélkül szinte biztos, hogy nem kapunk pontos vagy gyors választ. A különbözõ listák témájának rövid leírása a dokumentum alján olvasható. Szeretnénk mindenkit megkérni, hogy mielõtt feliratkozik vagy levelet küld valamelyik listára, figyelmesen olvassa el ezeket. Az egyes listák tagjai már így is naponta többszáz &os;-vel kapcsolatos üzenetet kapnak, miközben a listák tematikájának és szabályainak lefektetésével igyekszünk a jel-zaj arányt minél kedvezõbb szinten tartani. Ezek nélkül a levelezési listák a Projekt számára haszontalan kommunikációs eszközökké válnának. A &a.test.name; címet használjuk, ha ki akarjuk próbálni, hogy tudunk-e levelet küldeni a &os; listáira. A többi listára viszont lehetõleg ne küldjünk teszt jellegû üzeneteket. Ha nem tudjuk eldönteni, hogy pontosan melyik listát is kellene megcímeznünk kérdésünkkel, olvassuk el a Hogyan kapjunk értékelhetõ választ a &os;-questions levelezési listáról címû leírást (angolul). Mielõtt akármelyik listára is levelet küldenénk, olvassuk el a Levelezési listák Gyakran Ismételt Kérdéseit (angolul), amivel elkerülhetjük a gyakran feltett kérdések és témák ismételt felhozását. A levelezési listák tartalma folyamatosan archiválódik, és ezekben az archívumokban a &os; honlapján tudunk keresni. Az itt elérhetõ, kulcsszavak alapján történõ keresés remek módját nyújtja a gyakran felmerülõ kérdések egyszerû és gyors megválaszolásának, ezért ilyen esetekben elõször mindig ezt javasolt használni. Ez egyben mellesleg azt is jelenti, hogy a &os; levelezési listáira küldött üzenetek fennmaradnak az örökkévalóságig. Ha a beküldendõ üzenet bizalmas információkat tartalmaz, érdemes megfontolni egy eldobható anonim e-mail cím használatát és kizárólag csak a publikus részet beküldeni. A listák összefoglalása Általános listák: A következõ általános célú listákhoz szabadon (és nyugodtan) csatlakozhatunk: Lista Tartalom &a.advocacy.name; A &os; igéjének terjesztése &a.announce.name; Fontosabb események és elõrelépések a projektek életében &a.arch.name; Architekturális és tervezési kérdések tárgyalása &a.bugbusters.name; A &os; hibabejelentéseit tároló adatbázis és a kapcsolódó eszközök karbantartására vonatkozó megbeszélések &a.bugs.name; Hibajelentések &a.chat.name; A &os; közösség nem szakmai jellegû dolgai &a.current.name; A &os.current; használatának tárgyalása &a.isp.name; A &os;-t alkalmazó internet-szolgáltatók fóruma &a.jobs.name; &os;-s munkalehetõségek &a.policy.name; A &os; fejlõdését irányító csoport (Core Team) döntéseirõl tájékoztató lista. A forgalma kicsi, csak olvasható. &a.questions.name; A felhasználók kérdései és szakmai segítségnyújtás &a.security-notifications.name; Biztonsági figyelmeztetések &a.stable.name; A &os.stable; használatát illetõ kérdések &a.test.name; Ide lehet küldeni a próbaüzeneteket Szakmai listák: A következõ listák szakmai jellegû témákat képviselnek. Mielõtt bármelyikükre levelet küldenénk vagy feliratkoznánk, figyelmesen olvassuk el a tartalmukat és céljaikat bemutató rövid leírásukat. Lista Tartalom &a.acpi.name; Az ACPI és energiagazdálkodás támogatás fejlesztése &a.afs.name; Az AFS portolása &os;-re &a.aic7xxx.name; Az &adaptec; AIC 7xxx sorozat meghajtóinak fejlesztése &a.alpha.name; A &os; Alpha portja &a.amd64.name; A &os; AMD64 portja &a.apache.name; Az Apache és hozzátartozó portok tárgyalása &a.arm.name; A &os; &arm; portja &a.atm.name; &os; használata ATM hálózatokkal &a.audit.name; A forráskód ellenõrzésérõl szóló projekt &a.binup.name; A bináris frissítésekkel foglalkozó rendszer tervezése és fejlesztése &a.bluetooth.name; A &bluetooth; technológia használata a &os;-ben &a.cluster.name; A &os; klaszteres környezetben &a.cvsweb.name; A CVSweb karbantartása &a.database.name; Adatbázisok használata és fejlesztése &os; alatt &a.doc.name; &os;-rõl szóló leírások készítése &a.drivers.name; Eszközmeghajtók írása &os;-re &a.eclipse.name; Az Eclipse integrált fejlesztõi környezet, eszközeinek, gazdag kliens alkalmazásinak és portjainak &os; alatti használata &a.embedded.name; A &os; használata beágyazott alkalmazásokban &a.eol.name; Olyan &os;-s szoftverek független továbbfejlesztése, amelyeket hivatalosan már nem támogatnak &a.emulation.name; Linux/&ms-dos;/&windows; és hasonló rendszerek emulációja &a.firewire.name; A &os; és a &firewire; (iLink, IEEE 1394) kapcsolatának technikai kérdései &a.fs.name; Állományrendszerek &a.geom.name; A GEOM-hoz tartozó témák és implementációk &a.gnome.name; A GNOME és GNOME-alkalmazások portolása &a.hackers.name; Általános szakmai témák &a.hardware.name; A &os; futtatására szolgáló hardverekkel foglalkozó témák &a.i18n.name; A &os; honosítása &a.ia32.name; A &os; használata az IA-32 (&intel; x86) platformon &a.ia64.name; A &os; portolása az &intel; következõ IA64 rendszereire &a.ipfw.name; Az IP tûzfal kódjának újratervezését érintõ szakmai megbeszélések &a.isdn.name; ISDN fejlesztõk levelei &a.jail.name; A &man.jail.8; segédprogram &a.java.name; &java; fejlesztõk kérdései és a &jdk;-k átültetése &os;-re &a.kde.name; A KDE és KDE-alkalmazások portolása &a.lfs.name; Az LFS portolása &os;-re &a.libh.name; A második generációs telepítõ- és csomagrendszer &a.mips.name; A &os; portolása &mips;-re &a.mobile.name; A mobil számítógépekkel kapcsolatos megbeszélések + + &a.mono.name; + Mono és C# alkalmazások + &os; alatt + + &a.mozilla.name; A Mozilla átültetése &os;-re &a.multimedia.name; Multimédia alkalmazások &a.newbus.name; A buszarchitektúrával kapcsolatos szakmai megbeszélések &a.net.name; A TCP/IP forráskódjával és hálózatkezeléssel kapcsolatos kérdések &a.openoffice.name; A OpenOffice.org és &staroffice; alkalmazások portolása &os;-re &a.performance.name; Nagy terhelésû és teljesítményû rendszerek teljesítményhangolási kérdései &a.perl.name; A rengeteg Perl alapú port karbantársa &a.pf.name; A csomagszûrõ mûködésével kapcsolatos kérdések és megbeszélések &a.platforms.name; Portolás nem &intel; architektúrájú platformokra &a.ports.name; A Portgyûjtemény mûködése &a.ports-bugs.name; A portokhoz tartozó hibák és hibajelentések megbeszélése &a.ppc.name; A &os; portolása &powerpc;-re &a.proliant.name; HP ProLiant szerverek és a &os; kapcsolata &a.python.name; A Python &os;-n futó változatának problémái &a.qa.name; A minõségbiztosítás megbeszélése, különösen a kiadások közeledtével &a.rc.name; Az rc.d rendszer és annak fejlõdése &a.realtime.name; A &os; valósidejû kiterjesztéseinek fejlesztése &a.ruby.name; A Ruby használata &os; rendszereken &a.scsi.name; A SCSI alrendszer &a.security.name; A &os; mûködését fenyegetõ biztonsági problémák &a.small.name; A &os; használata beágyazott alkalmazásokban (elavult; helyette a &a.embedded.name; címét használjuk) &a.smp.name; Az [A]Szimmetrikus többszálú feldolgozáshoz ([A]Symmetric MultiProcessing) tartozó tervezési megbeszélések &a.sparc.name; A &os; portolása &sparc; alapú rendszerekre &a.standards.name; A &os; megfelelése a C99 és &posix; szabványoknak &a.sun4v.name; A &os; portolása &ultrasparc; T1 alapú rendszerekre &a.threads.name; A &os; szálkezelése &a.testing.name; A &os; teljesítmény- és megbízhatósági tesztjei &a.tokenring.name; A Token Ring támogatása a &os;-ben &a.usb.name; USB támogatás a &os;-ben &a.virtualization.name; A &os; részérõl támogatott különbözõ virtualizációs technológiák tárgyalása &a.vuxml.name; A VuXML infrastruktúra tárgyalása &a.x11.name; Az X11 karbantartása és támogata &os; alatt &a.xen.name; A &xen; &os; portjának (implementációk, használat) tárgyalása Korlátozott listák: (Limited lists) A következõ listák sokkal jobban specializálódótt (és igényesebb) közösségnek szólnak, nem a nagyközönségnek. Ezért mielõtt egy ilyen listára feliratkoznánk, érdemes némi tapasztalatot gyûjtenünk a szakmai témájú listákon, így megismerjük az itt alkalmazott kommunikációs szabályokat. Lista Tartalom &a.hubs.name; A tükrözések üzemeltetõi számára (infrastrukturális támogatás) &a.usergroups.name; A felhasználói csoportok összefogása &a.vendors.name; A forgalmazók koordinálása a kiadások elõtt &a.wip-status.name; A &os;-vel kapcsolatos folyamatban levõ fejlesztések helyzetjelentései &a.www.name; A www.FreeBSD.org karbantartói számára Kivonatolt listák: (Digest lists) Az eddig említett listák elérhetõek kivonatolt formában is. Miután feliratkoztunk egy listára, a hozzáférésünk beállításainál kiválaszthatjuk, hogy kivonatolt formátumban kívánjuk-e kapni a leveleket. CVS és SVN listák: (CVS & SVN lists) A következõ listák a forrásfa különbözõ részeinek változtatásáról és a hozzájuk tartozó üzenetekrõl adnak értesítést. Ezek a listák csak olvasásra vannak, nem szabad rájuk levelet küldeni. Lista Forráskód területe A terület leírása (minek a forrása) &a.cvsall.name; /usr/(CVSROOT|doc|ports) A fában végzett akármelyik módosítás (az összes CVS lista együtt) &a.cvs-doc.name; /usr/(doc|www) A doc és www ágak változásai &a.cvs-ports.name; /usr/ports A portfa változásai &a.cvs-projects.name; /usr/projects A projektek változásai &a.cvs-src.name; /usr/src A rendszer forrásának változásai (az svn és cvs közti importer mûködése alapján generálódik) &a.svn-src-all.name; /usr/src A Subversion repositoryk változásai (kivéve a user és a projects) &a.svn-src-head.name; /usr/src A Subversion repository fõágának (a &os;-CURRENT forrásainak) változásai &a.svn-src-projects.name; /usr/projects A projects változásai a forrásokat tároló Subversion repositoryn belül &a.svn-src-release.name; /usr/src A releases változásai a forrásokat tároló Subversion repositoryn belül &a.svn-src-releng.name; /usr/src A releng ágak (biztonsági frissítések és kiadások) változásai a forrásokat tároló Subversion repositoryn belül &a.svn-src-stable.name; /usr/src A stabil verziókhoz tartozó ágak változásai a forrásokat tároló Subversion repositoryn belüle &a.svn-src-stable-6.name; /usr/src A stable/6 ág változásai a forrásokat tároló Subversion repositoryn belül &a.svn-src-stable-7.name; /usr/src A stable/7 ág változásai a forrásokat tároló Subversion repositoryn belül &a.svn-src-stable-other.name; /usr/src A Subversion repositoryban található korábbi stable ágak változásai &a.svn-src-svnadmin.name; /usr/src A forrásokat tároló Subversion repositoryhoz tartozó szkriptek és egy konfigurációs állományok változásai &a.svn-src-user.name; /usr/src A user változásai a forrásokat tároló Subversion repositoryn belül &a.svn-src-vendor.name; /usr/src A vendor változásai a forrásokat tároló Subversion repositoryn belül Hogyan iratkozzunk fel Ha fel akarunk iratkozni valamelyik listára, kattintsunk a nevére, vagy menjünk a &a.mailman.lists.link; címre és a válasszuk ki onnan a keresett listát. A lista oldalán megtalálunk minden feliratkozással kapcsolatos utasítást. Ténylegesen úgy tudunk üzenni egy listára, ha levelet küldünk az listanév@FreeBSD.org címre, amely ezután a lista tagjai között kézbesítésre kerül a világban. A listáról úgy tudunk leiratkozni, ha a róla kapott valamelyik levél alján található URL-re kattintunk. Másik megoldás, ha magunk küldünk egy levelet a listanév-unsubscribe@FreeBSD.org címre. Még egyszer szeretnénk kérni, hogy a szakmai témájú levelezési listákon folyó társalgásokat igyekezzünk az adott témán belül tartani. Ha csupán a fontosabb bejelentésekre vagyunk kíváncsiak, akkor a kisforgalmú &a.announce; használatát válasszuk. A listák tematikája Minden &os;-s levelezési lista rendelkezik bizonyos alapszabályokkal, amelyek minden tagnak el kell fogadnia. Az ismeretett irányelvek elleni vétkezés a &os; postamesterének postmaster@FreeBSD.org két (2, azaz kettõ) írásos figyelmeztetését vonja maga után, amelyek figyelmen kívül hagyásával, tehát a harmadik szabálysértés alkalmával, a küldõ eltávolításra kerül a &os; összes levelezési listájáról és a továbbiakban szûrni fogják a leveleit. Sajnáljuk, hogy ilyen szabályokat és szankciókat kellett bevezetnünk, de napjaink internetes technológiái igen elvadultak és ahogy az látható is, sokan egyszerûen nem fogják fel, mennyire sérülékenyek egyes részei. Közlekedési szabályok: Minden beküldött levél témájának meg kell felelnie az adott lista tartalmának, tehát például a szakmai kérdésekkel foglalkozó listákon csak szakmai témájú leveleknek szabad megjelenniük. Az oda nem illõ cseverészés és értelmetlen vitázás csak a lista értékét csökkenti, ezért ezt senkitõl sem tûrjük. A kötetlenebb, konkrét téma nélküli megbeszéléseket inkább a &a.chat; címén folytassuk. 2 listánál többre ne küldjük be ugyanazt a levelet, és 2 listára is csak akkor küldjük, ha az egyértelmûen és nyilvánvalóan indokolt. A legtöbb listánál így is rengeteg az átfedés, kivéve a legtitkosabb kombinációkat (például -stable és -scsi), ezért nem túl sok értelme van egyszerre egynél több listát is értesíteni. Ha olyan üzenetet kapunk, amelynek a Cc (másolat) mezõjében több lista címe is szerepel, akkor továbbküldés vagy válaszadás során töröljük ezeket. Az általunk küldött levelekért továbbra is mi magunk vagyunk a felelõsek, függetlenül attól, hogy ki volt a levél eredeti feladója. Tilos (vita közben) személyeskedni vagy káromkodni, beleértve a felhasználókat és a fejlesztõket is. A netikett megszegését, például a privát levelezés elõzetes engedély nélküli továbbküldését vagy egyes részleteinek közlését, elítéljük, de nyíltan nem tiltjuk. Nagyon ritka esetekben azonban elõfordulhat, hogy a sértõ tartalom önmagában ellenkezik a lista elveivel és figyelmeztetést (esetleg kitiltást) von maga után. A &os;-hez nem kötõdõ termékek vagy szolgáltatások reklámozása szigorúan tilos, és ha bebizonyosodik, hogy a küldõ szándékosan küldte szét, akkor azonnali kitiltásban részesül. Az egyes listák tematikája: &a.acpi.name; Az ACPI és energiagazdálkodás támogatásának fejlesztése &a.afs.name; Andrew File System Ez a lista a CMU/Transarc AFS portolásáról szól &a.announce.name; Fontosabb események / nagyobb lépések Olyan emberek számára ajánlott ez a levelezési lista, akik csak a &os; jelentõsebb eseményei bejelentései iránt érdeklõdnek. Ide értendõk a különbözõ idõközi és egyéb kiadások, a &os; újításainak bejelentései. Idõnként önkéntesek toborzására stb. is használják. A forgalma nagyon kicsi, tartalma szigorúan ellenõrzõtt. &a.arch.name; Architekturális és tervezési kérdések Ez a lista a &os; architektúráját érintõ megbeszélések színtere. Az itt megjelenõ üzenetek szigorúan szakmai jellegûek. Néhány idevágó téma: Hogyan alakítsuk úgy át a fordítási rendszert, hogy egyszerre több különbözõ paraméterû fordítás is képes legyen futni. Mit kellene javítani a VFS-en a Heidemann-rétegek mûködéséhez. Hogyan tudnánk úgy átalakítani az eszközmeghajtók felületét, hogy ugyanazok a meghajtók minden gond nélkül képesek legyenek több buszon és architektúrán is mûködni. Hogyan írjunk meghajtót hálózati eszközökhöz. &a.audit.name; A forráskód vizsgálatát végzõ projekt Ez a levelezési lista a &os; forráskódjának vizsgálatával foglalkozik. Habár eredetileg csak a biztonságot érintõ változtatások ellenõrzésére jött létre, napjainkra már a forráskód mindenféle változását felülvizsgálja. Erre a listára rengeteg javítás érkezik, amelyek valószínûleg egy átlag &os; felhasználó számára nem túlzottan érdekesek. A kód változásától független biztonsági kérdések megvitatása a freebsd-security listán történik. Viszont az összes fejlesztõnek javasoljuk, hogy küldjék be felülvizsgálatra a javításaikat, különösen abban az esetben, amikor a forráskód olyan részéhez nyúlnak, ahol az adott hiba javítása a rendszer egészének mûködésére kihatással lehet. &a.binup.name; A &os; bináris frissítésével foglalkozó projekt Ez a lista ad otthont a binup vagy más néven a bináris frissítési rendszer (binary update system) körül felmerülõ problémák tárgyalásának. Tervezési kérdések, implementációs részletek, javítások, hiba- és állapotjelentések, funkciók igénylése, a kód változásainak naplózása és minden, ami a binuppal kapcsolatos. &a.bluetooth.name; &bluetooth; a &os;-ben Ez a &bluetooth;-os &os; felhasználók gyülekezõhelye. Tervezési és implementációs kérdések, javítások, hiba- és állapotjelentések, funkciók igénylése, minden, ami &bluetooth;. &a.bugbusters.name; A hibajelentések kezelésének összefogása A lista célja a Bugmeister és az õ Bugbustereinek, valamint a hibajelentések adatbázisai iránti kifejezetten érdeklõdõ személyek együttmûködésének és kapcsolattartásának elõsegítése. Ez a lista nem az egyes hibákról, javításokról vagy azok jelentésérõl szól. &a.bugs.name; Hibajelentések Ezen a levelezési listán lehet a &os; hibáit bejelenteni. Ha lehet, akkor a hibákat a &man.send-pr.1; paranccsal vagy a webes felületen keresztül küldjük be. &a.chat.name; A &os; közösség nem szakmai jellegû dolgai Erre a listára kerül minden olyan nem szakmai jellegû, társadalmi érintkezéssel kapcsolatos információ, ami a többi listáról kimaradt: Jordan mennyire hasonlít a rajzfilmeken látható vadászgörényre, kis- vagy nagybetûvel írjuk-e, ki iszik sok kávét, hol fõzik a legjobb söröket, ki fõz sört az alagsorában és így tovább. Elvétve felbukkannak olyan fontosabb események is (bulik, lakodalmak, gyermekáldás, új munkahely stb), amelyek ugyan szakmai témájúak, de a folyományaik már inkább a -chat listára tartoznak. &a.core.name; A &os; irányítását végzõ csapat Ezt a belsõ levelezési listát a Core Team tagjai használják. Akkor érdemes ide levelet küldeni, ha &os;-vel kapcsolatos fontos ügyekben lenne szükségünk döntésre vagy véleményre. &a.current.name; A &os.current; használatával kapcsolatos megbeszélések A &os.current; felhasználóinak levelezési listája. Itt értesülhetünk a -CURRENT felhasználókat érintõ friss újdonságairól, és azokról az utasításokról, amelyek követésével mûködéképesen tarthatjuk a -CURRENT rendszerünket. Aki a -CURRENT verziót használja, mindenképpen iratkozzon fel erre a listára. Ez is egy szakmai jellegû lista, ahová csak szigorúan ilyen témákat várnak. &a.cvsweb.name; A &os; CVSweb projekt A &os; CVSweb szolgáltatásának használatáról, fejlesztésérõl és karbantartásáról szóló megbeszélések. &a.doc.name; A dokumentációs projekt Ez a levelezési lista a &os;-rõl szóló különbözõ dokumentumok készítésével kapcsolatos problémák és projektek tárgyalásait öleli fel. A levelezési lista tagjait együttesen a &os; Dokumentációs Projekt-nek nevezik. Ez egy nyílt lista, csatlakozzunk hozzá bátran! &a.drivers.name; Eszközmeghajtók írása &os;-re A &os;-hez készülõ eszközmeghajtókról szóló szakmai fórum. Elsõsorban itt tehetik fel a meghajtók készítõi a &os; rendszermagjában megtalalálható API-kra vonatkozó kérdéseiket. &a.eclipse.name; Az Eclipse integrált fejlesztõi környezetének, segéprogramjainak, kliensalkalmazásainak és portjainak &os; felhasználók számára meghirdetett fóruma. A lista azzal a szándékkal jött létre, hogy kölcsönös támogatást nyújtson az Eclipse fejlesztõi környezet, a hozzátartozó segédeszközök, kliensalkalmazások &os; változatának megválasztásában, telepítésében és használatában. Emellett az Eclipse környezet és pluginjainak &os;-re történõ portolásáról is szó esik. Valamint igyekszik minél többet profitálni az Eclipse és a &os; köré csoportosuló közösségek kölcsönös információcseréjébõl. Habár a lista elsõdlegesen az Eclipse felhasználóinek igényeire koncentrál, azok számára is táptalajt ad, akik az Eclipse keretrendszer segítségével &os; specifikus alkalmazásokat szeretnének kifejleszteni. &a.embedded.name; A &os; használata beágyazott alkalmazásokban Ez a lista a &os; beágyazott rendszerekben történõ használatát igyekszik megvitatni. Ez egy szakmai jellegû lista, ezért ide szigorúan csak ilyen témájú leveleket várunk. A listán tárgyalt beágyazott rendszereknek tekintünk minden olyan számítási eszközt, amely az általános számítási környezetekkel szemben egyetlen feladatot lát el. Nem feltétlenül csak ilyenek, de például a különféle telefonok, illetve hálózati eszközök, mint például útválasztók, switchek, PBX-ek, távoli mérõeszközök, PDA-k, eladási rendszerek és így tovább. &a.emulation.name; A Linux/&ms-dos;/&windows; rendszerek emulációja Ezen a listán arról értekezhetünk és olvashatunk, hogy &os; alatt miként futtassunk más operációs rendszerekre írt programokat. &a.eol.name; Összefogás a &os; Projekt által tovább már támogatott, &os;-hez tartozó szoftverekért Ezen a listán kap vagy kaphat helyet a &os; Projekt által hivatalosan tovább már nem fejlesztett szoftverek felhasználói összefogáson alapuló támogatása (például biztonsági figyelmeztetések vagy javítások formájában). &a.firewire.name; &firewire; (iLink, IEEE 1394) Ez a levelezési lista foglalkozik a &os; &firewire; (azaz IEEE 1394, avagy iLink) alrendszerének implementációjával. Az itt felmerülõ témák többek közt a szabványok, buszos eszközök és a hozzájuk tartozó protokollok, vezérlõkártyák és chipkészletek, valamint a mûködtetésükre szánt programok felépítése és megvalósítása. &a.fs.name; Állományrendszerek A &os;-ben megjelenõ állományrendszerek kivesézése. Mivel ez egy szakmai jellegû lista, ide határozottan csak ilyen jellegû leveleket várunk. &a.geom.name; GEOM A GEOM és a vele kapcsolatos implementáció megbeszélései. Szakmai jellegû lista, ezért erre tekintettel csak ilyen témájú leveleket postázzunk ide. &a.gnome.name; GNOME A GNOME asztalkörnyezet &os; rendszereket érintõ használatáról szóló lista. Mûszaki jellegû, ezért szigorúan csak ilyen témákban társgalodjunk itt. &a.ipfw.name; IP tûzfalak A &os;-ben levõ IP tûzfal újratervezésével foglalkozó elgondolások és szakmai témájú megbeszélések otthona. Ide szigorúan csak ilyen témájú leveleket küldjünk! &a.ia64.name; A &os; portolása I64-re Ez a levelezési lista a &os; az &intel; IA-64 platformjára készített portjával foglalkozó egyének kommunikációs eszköze, ahol az ezzel kapcsolatos problémák és azok különbözõ megoldásai kerülnek terítékre. A téma iránt érdeklõdõket is szívesen látjuk. &a.isdn.name; ISDN kommunikáció Ez a levelezési lista a &os; ISDN támogatásáról szól. &a.java.name; &java; alapú fejlesztések A levelezési listán a nagyobb &java; alkalmazások &os; alapú fejlesztését, valamint a &jdk;-k portolásáról és karbantartását beszélik meg. &a.jobs.name; Munkát keres/kínál Erre a fórumra tudjuk beküldeni a kifejezetten &os;-hez kapcsolódó munkaajánlatokat és önéletrajzokat, tehát ez a megfelelõ hely, ha &os;-s munkát keresünk, vagy éppen &os; szakértõket. Ez azonban nem egy általános célú állásbörze, mert arra megvannak a megfelelõ helyek. Szeretnénk hozzátenni, hogy ez a lista, a többi FreeBSD.org levelezési listához hasonlóan, világméretekben mûködik. Ezért ne felejtsük sosem pontosan megjelölni a munkavégzés helyét, illetve hogy milyen kommunikációs és esetlegesen költözési lehetõségeket javaslunk. A leveleket csak nyílt formátumban küldjük — elsõsorban szöveges formátumban, de az egyszerûbb PDF, HTML vagy még néhány más hozzájuk hasonló formátumot is alkalmazhatunk. Az olyan zárt formátumok, mint például a µsoft; Word (.doc) azonban nem fognak továbbítódni. &a.kde.name; KDE A KDE és &os; kapcsolatáról szóló lista. Szigorúan szakmai jellegû, ezért csak ilyen témájú levelek küldése elfogadott. &a.hackers.name; Szakmai kérdések Ez a &os; szakmai jellegû kérdéseivel foglalkozó fórum. Ez az elsõ számû szakmai levelezési lista. A &os; fejlesztésével aktívan foglalkozó egyének számára ajánljuk, hiszen itt vethetik fel problémáikat, itt kereshetnek rájuk megoldásokat. Az ilyen típusú megbeszéléseket figyelemmel követõ egyéneket is szívesen fogadjuk. Mivel ez egy erõsen szakmai jellegû lista, ezért csak ilyen témájú leveleket várunk ide. &a.hardware.name; A &os; és a hardverek kapcsolatáról általában Ezen a listán kerül megvitatásra minden olyan hardver, amelyen a &os; mûködik: milyen gondok adódhatnak, milyen hardvereket érdemes beszereznünk vagy elkerülnünk. &a.hubs.name; Tükrözések A &os; tükrözéseit karbantartó egyének számára fontos bejelentések és megbeszélések. &a.isp.name; Az internet-szolgáltatók fóruma Ezen a levelezési listán a &os;-t használó internet-szolgáltatók tehetik fel kérdéseiket. Szigorúan csak szakmai jellegû kérdések engedélyezettek. + + &a.mono.name; + + + Mono és C# alkalmazások &os; + alatt + + Ezen a levelezési listán a Mono + fejlesztõi keretrendszer &os; alatt futó + változatával kapcsolatos + megbeszélések folynak. Ez egy szakmai + jellegû lista. Itt a Mono vagy más C# + alkalmazások &os; változatának + elkészítésén dolgozó + egyének tudnak problémákat felvetni + vagy megvitatni a különbözõ + megoldásokat. Rajtuk kívül viszont + szeretettel várunk minden + érdeklõdõt a téma + iránt. + + + &a.openoffice.name; OpenOffice.org Az OpenOffice.org és &staroffice; portolásával és karbantartásával kapcsolatos megbeszélések. &a.performance.name; A &os; hangolásának és gyorsításának tárgyalása Ezen a levelezési listán van lehetõségük a hackereknek, rendszergazdáknak és/vagy az érintett feleknek a &os; teljesítményével kapcsolatos témákban kifejteni a véleményüket. Leginkább nagy terhelés alatt levõ, vagy teljesítménybeli problémákkal küszködõ, esetleg még többet tudó &os; rendszerek tárgyalása a cél. Lehetõleg az érintett gyártókkal és szállítókkal együttesen próbáljuk kidolgozni a &os; teljesítményének növelésére tett kísérleteinket, ezért õket is szívesen látjuk ezen a listán. Ez a kifejezetten szakmai jellegû lista többségében a tapasztalt &os; felhasználók, hackerek vagy rendszergazdák számára tárja fel a gyors, megbízható és skálázható &os; rendszerek lehetõségeit. Ez alapvetõen nem egy kérdezgetõs lista, ahol a dokumentációk elolvasását tudjuk megspórolni, hanem egy olyan hely, ahol a teljesítményt érintõ megválaszolatlan kérdések és elõremutató fejlesztések nyernek teret. &a.pf.name; A csomagszûrõ tûzfalrendszerrel kapcsolatos kérdések A &os; csomagszûrõjéhez (packet filter, pf) tartozó tûzfalrendszer megbeszéléseit összefoglaló lista. Szakmai jellegû fejtegetések és felhasználói kérdések egyaránt jöhetnek. Továbbá ezen a listán foglalkozunk az ALTQ rendszer mûködésével is. &a.platforms.name; Portolás nem &intel; plaformokra A &os; különbözõ, nem az &intel; architektúrára építkezõ portjainak indítványozása és általános jellegû megvitatása. Ez egy kiemelten szakmai jellegû lista, ezért ide csak ilyen témájú leveleket várunk. &a.policy.name; Az Core Team szabályozásai Alacsony forgalmú, csak olvasható lista, ahol a &os; fejlesztését irányító csoport különbözõ döntéseirõl olvashatunk. &a.ports.name; A portok megbeszélése A &os; portgyûjteményével (/usr/ports), a portok infrastruktúrájával és a portok fejlesztésének irányításával kapcsolatos megbeszélések. Erõsen szakmai jellegû lista, ezért ide csak ilyen témában írjunk. &a.ports-bugs.name; A portok hibáinak tárgyalása A &os; portgyûjteményének (/usr/ports), a bejelentett portok és azok módosításához kötõdõ hibajelentésekkel foglalkozó lista. Ez egy szakmai jellegû lista, ahol csak ilyen jellegû témákra számítunk. &a.proliant.name; A &os; és a HP ProLiant szerverek kapcsolatát érintõ szakmai megbeszélések Ezen a levelezési listán a &os; HP ProLiant szervereken történõ használatát célozzuk meg, beleértve a ProLianthoz tartozó eszközmeghajtókat, karbantartó és konfigurációs szoftvereket és BIOS-frissítéseket. Ennek megfelelõen tehát a hpasmd, hpasmcli és hpacucli modulok is elsõsorban itt kerülnek felboncolásra. &a.python.name; A &os; és a Python A lista a &os; Python támogatásának fejlesztésérõl folytatott szakmai megbeszéléseket foglalja össze. Elsõsorban a Python portolásával foglalkozó egyének, valamint a külsõ fejlesztõk által készített modulok és a Zope &os;-s alkalmazásával foglalkozik. Az említett témák iránti érdeklõdõket is szeretettel várjuk. &a.questions.name; Felhasználói kérdések Ez a levelezési lista a &os;-vel kapcsolatos kérdésekrõl szól. Lehetõleg ne küldjünk hogyan témájú kérdéseket erre a szakmai listára, hacsak nem kifejezetten szakmai jellegûnek szánjuk. &a.ruby.name; A Ruby használata &os; rendszereken Ezen a listán a &os; Ruby támogatásával foglalkozunk, témáját tekintve teljesen szakmai jellegû. Elsõsorban a Ruby portokon, külsõ Ruby könyvtárakon és rendszereken dolgozó fejlesztõk figyelmébe ajánljuk. Mindenkit szeretettel várunk, aki ezekkel kapcsolatos szakmai tárgyú témákat szeretne megvitatni. &a.scsi.name; A SCSI alrendszer Ezt a levelezési listát a &os; alatt a SCSI alrendszerrel foglalkozók számára tarjuk fenn. Mivel ez egy erõsen szakmai jellegû lista, ezért rajta csak szakmai témák megengedettek. &a.security.name; Biztonsági problémák A &os; biztonságát illetõ kérdések (DES, Kerberos, biztonsági rések és javításaik, stb.) Szakmai jellegû lista, ezért ide csak a témához szorosan kapcsolódó leveleket szabad beküldeni. Alapvetõen nem kérdezz-felelek típusú a lista mûködése, habár a GYIK-hoz minden hozzájárulást (kérdést ÉS választ EGYARÁNT) szívesen veszünk. &a.security-notifications.name; Biztonsági figyelmeztetések A &os;-t érintõ biztonsági problémákról és javításaikról szóló értesítések. Megbeszélésekkel, vitákkal nem foglalkozik, mivel azok a &os;-security listán folynak. &a.small.name; A &os; használata beágyazott alkalmazásokban A szokatlanul kis méretû vagy beágyazott &os; rendszerekhez kapcsolódó megbeszélések színhelye. Szakmai jellegû lista, ezért szigorúan csak a témához tartozó leveleket fogad. Ezt a listát idõközben felváltotta a &a.embedded.name; lista. &a.stable.name; A &os.stable; használatáról szóló lista Ez a &os.stable; használóinak levelezési listája. Ide kerülnek beküldésre a -STABLE ágat futtató felhasználókat érintõ friss változások, valamint hozzájuk kötõdõen a -STABLE használatához szükséges elvégzendõ lépések. Aki a STABLE jelzésû változatot használja, mindenképpen iratkozzon fel rá. Szigorúan szakmai jellegû lista, ezért csak szakmai témájú leveleket vár. &a.standards.name; C99 és POSIX megfelelés Ez a fórum foglalkozik a &os; és a C99, valamint a POSIX szabványok szerinti megfelelésével. &a.usb.name; A &os; USB támogatása Ez a levelezési lista fogja összes a &os; USB támogatásával foglalkozó szakmai témákat. &a.usergroups.name; A felhasználói csoportokat irányító lista Ez a levelezési lista az egyes területeken mûködõ felhasználói csoportok az irányítást végzõ központi csoport tagjai általi összehangolásához tartozó problémák megbeszélésére való. Ez a lista leginkább a gyûlések letisztázására és a több csoporton átívelõ nagyobb projektek szervezéséhez használatos. &a.vendors.name; Gyártók A &os; projekt és a hozzá kötödõ hardver- és szoftvergyártók együttmûködését elõsegítõ lista. &a.virtualization.name; A &os; részérõl támogatott különbözõ virtualizációs technológiák Ezen a levelezési listán elsõsorban a &os; által támogatott virtualizációs megoldásokat vitatjuk meg. Ennek keretében egyrészt az ehhez kapcsolódó alapvetõ funkciók megvalósítása valamint további újítások kerülnek a középpontba, másrészt a felhasználók számára ezzel létrehoztunk egy fórumot a felmerülõ problémák megoldására és az alkalmazási lehetõségek megbeszelésére. &a.wip-status.name; A &os;-vel kapcsolatos folyamatban levõ fejlesztések helyzetjelentése Ezen a levelezési listán kerülnek bejelentésre a &os; továbbfejlesztéséhez fûzõdõ különbözõ munkák és azok haladásának menete. Az ide befutó üzeneteket moderálják. Javasoljuk, hogy elsõdlegesen az adott témához tartozó tematikus &os; listára küldjük a bejelentésünket és csak egy másolatot erre a listára. Ennek köszönhetõen a munkánk az adott témaspecifikus listán rögtön meg is vitatható, mivel ezen a listán semmi ilyen nem engedélyezett. A lista archívumába tekintve tájékozódhatunk arról, hogy pontosan milyen formai követelmények illene megfelelnie a beküldenõ üzenetünknek. A listára beérkezõ üzenetekbõl egy szerkesztett válogatás jelenik meg néhány havonta a &os; honlapján a Projekt helyzetjelentésének részeként . A korábban beküldött jelentések mellett itt még találhatunk további példákat. &a.xen.name; A &xen; &os; portjának (implementáció és használat) megvitatása A lista elsõsorban a &xen; &os;-re készült változatával foglalkozik. Elõreláthatólag elég kevesen fognak írni erre a listára ahhoz, hogy helyet kapjanak rajta az implementációt és a kialakítást érintõ szakmai jellegû megbeszélések és a telepítéssel kapcsolatos kérdések egyaránt. A levelezési listák szûrése A kéretlen reklámlevelek, vírusok és egyebek elleni védekezés céljából a &os; levelezési listáinak forgalmát több módon is szûrik. Az ebben a szakaszban bemutatott szûrési megoldások nem fedik le a levelezési listák védelme érdekében alkalmazott összes lehetõséget. A levelezési listákra csak bizonyos típusú csatolt állományokat küldhetünk be. Az alábbi listában nem található MIME típusú csatolt objektumokat még a listára érkezés elõtt törlik. application/octet-stream application/pdf application/pgp-signature application/x-pkcs7-signature message/rfc822 multipart/alternative multipart/related multipart/signed text/html text/plain text/x-diff text/x-patch Egyes levelezési listák ugyan megengedhetnek további csatolt MIME objektumokat is, habár a legtöbb lista esetében a fenti lista a mérvadó. Ha egy levélben a szöveg HTML és nyers szöveg formátumban is szerepel, a HTML változat automatikusan eltávolításra kerül. Ha az e-mail csak HTML formában tartalmazza a szöveget, akkor automatikusan nyers szövegre alakítódik át. Usenet hírcsoportok A két &os;-s hírcsoport mellett még akadnak olyan további csoportok is, ahol &os; témájú kérdéseket vitathatunk meg vagy hasznos lehet számunkra. Az itt felsorolt hírcsoportok kulcsszavakkal kereshetõ archívuma Warren Toomey tulajdona (wkt@cs.adfa.edu.au). BSD-s hírcsoportok comp.unix.bsd.freebsd.announce comp.unix.bsd.freebsd.misc de.comp.os.unix.bsd (német) fr.comp.os.bsd (francia) it.comp.os.freebsd (olasz) tw.bbs.comp.386bsd (hagyományos kínai) Egyéb érdekes &unix;-os hírcsoportok comp.unix comp.unix.questions comp.unix.admin comp.unix.programmer comp.unix.shell comp.unix.user-friendly comp.security.unix comp.sources.unix comp.unix.advocacy comp.unix.misc comp.bugs.4bsd comp.bugs.4bsd.ucb-fixes comp.unix.bsd X Window System comp.windows.x.i386unix comp.windows.x comp.windows.x.apps comp.windows.x.announce comp.windows.x.intrinsics comp.windows.x.motif comp.windows.x.pex comp.emulators.ms-windows.wine Világhálós szolgáltatások Fórumok, blogok és ismertségi hálózatok A &os; fórumok a &os; kapcsán felmerülõ kérdések és szakmai témák megvitatásához egy webes felületet kínálnak fel. A Planet &os; honlapján fejlesztõk által vezetett tucatnyi webes naplót és hozzájuk tartozó RSS feedeket találhatunk. Sok fejlesztõ ezen a módon készít rövid feljegyzéseket a jelenlegi munkájáról, az új javításokról és más egyéb terveirõl. A Youtube-on keresztül elérhetõ BSDConferences csatornán a világ minden táján tartott különbözõ BSD témájú konferenciák videoanyagait találhatjuk meg. Segítségével megtekinthetjük a fontosabb fejlesztõk által a saját munkájukról tartott különbözõ elõadásokat. Hivatalos tükrözések &chap.eresources.www.inc; E-mail címek A következõ felhasználói csoportok nyújtanak &os;-s e-mail címeket tagjaiknak. A rendszergazdák bármilyen visszaélés esetén fenntartják a visszavonás jogát. Címtartomány Lehetõségek Felhasználói csoport Rendszergazda ukug.uk.FreeBSD.org Csak továbbítás ukfreebsd@uk.FreeBSD.org Lee Johnston lee@uk.FreeBSD.org diff --git a/hu_HU.ISO8859-2/books/handbook/ports/chapter.sgml b/hu_HU.ISO8859-2/books/handbook/ports/chapter.sgml index 03c0a564f4..4886d91aaa 100644 --- a/hu_HU.ISO8859-2/books/handbook/ports/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/ports/chapter.sgml @@ -1,2169 +1,2169 @@ Alkalmazások telepítése: csomagok és portok Áttekintés portok csomagok A &os; rendszereszközök gazdag gyûjteményével érkezik az alaprendszer részeként. Azonban a külsõ alkalmazások telepítéséhez rengeteg teendõt kell elvégeznünk. A feladat elvégzésére ezért a &os; két, egymást kiegészítõ technológiát kínál fel: a &os; Portgyûjteményt (telepítés forráskódból) és a csomagokat (telepítés elõre elkészített bináris csomagokból). Mind a két módszerrel fel tudjuk telepíteni a kedvenc alkalmazásunk legújabb verzióját lokálisan vagy egyenesen a hálózatról. A fejezet elolvasása során megismerjük: hogyan telepítsünk külsõ fejlesztésû bináris szoftvercsomagokat; hogyan fordítsunk le a forrásukból külsõ fejlesztésû szoftvereket a Portgyûjtemény segítségével; hogyan távolítsunk el korábban már telepített csomagokat és portokat; hogyan bíráljuk felül a Portgyûjtemény által használt alapértelmezett értékeket; hogyan keressük meg a megfelelõ szoftvercsomagokat; hogyan frissítsük a telepített alkalmazásokat. Az alkalmazások telepítésének összefoglalása Ha korábban már használtunk &unix; rendszereket, valószínûleg ismerjük a külsõ alkalmazások telepítésének jellemezõ menetét: Töltsük le a szoftvert, amelyet vagy forráskód vagy pedig bináris formátumban érhetünk el. Bontsuk ki az alkalmazás letöltött változatát (ez általában a &man.compress.1;, &man.gzip.1; vagy a &man.bzip2.1; által tömörített tar állomány). Keressük meg dokumentációt (többnyire az INSTALL vagy a README állományban található, vagy a doc/ alkönyvtárban) és olvassuk el benne, hogyan tudjuk telepíteni a szoftvert. Ha a szoftver forrását töltöttük le, fordítsuk le. Elképzelhetõ, hogy ennek során szerkesztenünk kell a Makefile állományt vagy lefuttatnunk a configure szkriptet, illetve más lépéseket is el kell végeznünk. Próbáljuk a ki szoftvert, majd telepítsük. Ez annak a forgatókönyve, amikor minden hiba nélkül lezajlik. Megeshet azonban, ha olyan szoftvert telepítünk, amelyet nem kifejezetten a &os;-hez terveztek, akkor javítanunk kell a forráskódban a szoftver megfelelõ mûködéséhez. Ha sikerül mûködésre bírni, folytathatjuk &os;-n a szoftver telepítését a megszokott módon. Habár a &os; erre a célra két lehetõséget is felkínál, amivel rengeteg erõfeszítéstõl megkímélhet minket: ezek a csomagok és a portok. Az írás pillanatában közel &os.numports; külsõ alkalmazás érhetõ el ilyen formában. Egy adott alkalmazás esetén a hozzátartozó &os;-s csomag mindössze egyetlen letöltendõ állományt takar. A csomag tartalmazza az alkalmazás telepítéséhez szükséges összes parancs elõre lefordított változtatát, ugyanígy magát a dokumentációt is. A letöltött csomagokat a &os; csomagkezelõ parancsaival vehetjük használatba: ezek a &man.pkg.add.1;, &man.pkg.delete.1;, &man.pkg.info.1; és így tovább. Az új alkalmazások telepítése ennek köszönhetõen egyetlen paranccsal elvégezhetõ. Egy alkalmazás &os;-s portja mögött lényegében állományok gyûjteménye áll, amelyek abban segítenek, hogy automatikusan tudjunk telepíteni a forráskód felhasználásával. Ne felejtsük el, hogy normális esetben számos lépcsõt végig kell járnunk egy program sajátkezû lefordításához (letöltés, kitömörítés, javítgatás, fordítás, telepítés). A portot alkotó állományok tartalmazzák az összes olyan szükséges információt, amelyek átengedik ezt a feladatot a rendszernek. Kiadunk néhány egyszerû parancsot és az alkalmazás magától letöltõdik, kitömörítõdik, módosítja a forráskódját, lefordul és települ. Valójában a portrendszer használható olyan csomagok létrehozására is, amelyeket késõbb a pkg_add és többi hozzá hasonló, hamarosan részletesebben is bemutatandó csomagkezelõ paranccsal is kezelni tudunk. A csomagok és a portok egyaránt képesek függõségeket kezelni. Tegyük fel, hogy egy olyan alkalmazást akarunk telepíteni, amely egy adott függvénykönyvtár meglététõl függ a rendszeren. Az alkalmazás és a könyvtár is elérhetõ &os; portként és csomagként. Akár a pkg_add parancsot, akár a portrendszert használjuk az alkalmazás hozzáadására, mind a kettõ észre fogja venni, hogy a szükséges könyvtárt még nem telepítettük, ezért elõször azt fogja automatikusan telepíteni. Tudván, hogy a két említett megoldás szinte teljesen egyenértékû, felmerülhet a kérdés: a &os; mégis miért rendelkezik mindkettõvel? A csomagoknak és a portoknak is megvannak a maguk elõnyei, és hogy a kettõ közül melyiket használjuk, csak az egyéni ízlésünkön múlik. A csomagok használatának elõnyei Egy csomag általában kisebb, mint az alkalmazás forráskódját tartalmazó tömörített tar állomány. A csomagokat nem kell fordítani. Nagyobb alkalmazások, mint például a Mozilla, KDE vagy GNOME esetén ez kulcsfontosságú lehet, fõleg abban az esetben, ha a rendszerünk ehhez nem eléggé gyors. A csomagok használata nem várja el tõlünk, hogy behatóbban ismerjük miként is kell &os;-n szoftvereket lefordítani. A portok használatának elõnyei A csomagokat általános esetben igen óvatos beállításokkal készítik el, hiszen a lehetõ legtöbb rendszeren mûködõképesnek kell lenniük. Ha viszont portból telepítünk, nyugodtan hangolhatjuk úgy a beállításokat, hogy (például) a &pentium; 4 vagy az Athlon processzoroknak kedvezõ kódot hozzanak létre. Bizonyos alkalmazások fordítás idején állítandó beállításokkal rendelkeznek arról, hogy mire lesznek képesek és mire nem. Például az Apache beépített konfigurációs opciók széles kelléktárával rendelkezik. Amikor viszont portból hozzuk létre, nem kell elfogadnunk ezek alapértelmezett értékeit, hanem a saját igényeinknek megfelelõen átállíthatjuk ezeket. Egyes esetekben több különféle beállítást tükrözõ csomag is létezhet ugyanahhoz az alkalmazáshoz. Például a Ghostscript elérhetõ ghostscript és ghostscript-nox11 csomagként is attól függõen, hogy telepítettük-e az X11 szervert. Ez természetesen egy meglehetõsen durva kijátszása a csomagrendszernek, és gyorsan lehetetlenné is válik a használata, ha az adott alkalmazás egy-két fordítási idejû beállításnál többel rendelkezik. Néhány szoftver licencelése tiltja a bináris terjesztést. Ezért ezek a szoftverek kizárólag csak forráskód formájában továbbíthatóak. Néhányan nem bíznak meg a bináris verziókban. Ha látjuk a forráskódot is, akkor (elméletben) át tudjuk nézni, és mi magunk is megkereshetjük a benne lappangó hibákat. Ha vannak saját javításaink, csak a forráskód birtokában tudjuk ezeket felhasználni. Sokan szeretik, ha egyszerûen csak ott van a szoftverek forráskódja. Ha éppen unatkoznak, beléjük tudnak nézni, ötleteket és kódot tudnak belõlük meríteni (persze csak akkor, ha ezt a licenc megengedi), vagy tovább tudják ezeket fejleszteni, orvosolni tudják a hibáikat stb. A portok frissítésérõl a &a.ports; és a &a.ports-bugs; valamelyikérõl szerezhetünk naprakész információkat. Mielõtt bármelyik alkalmazást is telepítenénk, érdemes meglátogatnunk az oldalt, ahol a hozzátartozó ismert biztonsági problémákról olvashatunk. Telepíthetjük a ports-mgmt/portaudit programot is, amely automatikusan ellenõrzi a telepített alkalmazások ismert sebezhetõségeit. Ez az ellenõrzés egyébként megejthetõ minden port lefordítása elõtt is. Ezalatt a portaudit -F -a parancs kiadásával ellenõrizhetjük utólag a telepített csomagokat. A fejezet fennmaradó részében megmutatjuk, hogyan használjuk &os;-ben a csomagokat és portokat külsõ alkalmazások telepítésére és karbantartására. A számunkra szükséges alkalmazások felkutatása Mielõtt telepítenénk bármilyen alkalmazást, tudnunk kell, hogyan is nevezik. A &os;-hez elérhetõ alkalmazások listája folyamatosan növekszik. Szerencsére számos módja van annak, hogy utánajárjunk a keresett szoftvernek: A &os; honlapján találhatunk egy rendszeresen frissülõ listát az összes elérhetõ alkalmazásról, a http://www.FreeBSD.org/ports/ címen. Itt a portok különbözõ kategóriákba sorolva találhatóak meg, ahol név szerint megkereshetjük az alkalmazást (amennyiben ismerjük), vagy végigböngészhetjük az adott kategóriában elérhetõ alkalmazásokat is. FreshPorts Dan Langlille a címen karbantartja a FreshPorts nevû oldalt. Ezen az oldalon folyamatosan nyomon lehet követni a Portgyûjteményben megtalálható alkalmazások változásait, lehetõvé téve, hogy egy vagy több portot is figyeljünk, vagy e-mailt küldjünk a frissítésükrõl. FreshMeat Amennyiben nem ismerjük a keresett alkalmazás nevét, próbáljuk meg felkutatni a FreshMeaten () vagy hozzá hasonló oldalakon, majd nézzük a &os; honlapján, hogy az adott alkalmazást portolták-e már a rendszerre. Ha pontosan ismerjük a port nevét, és csak a kategóriáját kellene megkeresnünk, használjuk a &man.whereis.1; parancsot. Egyszerûen csak adjuk ki a whereis név parancsot, ahol az név a telepítendõ program neve. Ha sikerült megtalálni, részletes információt kapunk arról, hogy hol található, valahogy így: &prompt.root; whereis lsof lsof: /usr/ports/sysutils/lsof A fenti példában megtudhatjuk, hogy az lsof parancs a /usr/ports/sysutils/lsof könyvtárban található. Vagy egy egyszerû &man.echo.1; paranccsal is megkereshetjük a portfában a portokat. Mint például: &prompt.root; echo /usr/ports/*/*lsof* /usr/ports/sysutils/lsof Ez a módszer a /usr/ports/distfiles könyvtárba letöltött összes illeszkedõ állományt is kilistázza. Egy másik lehetõség egy adott port megtalálására, ha a Portgyûjtemény beépített keresési mechanizmusát használjuk. Ennek használatához a /usr/ports könyvtárban kell lennünk. Miután beléptünk ide, futtassuk le a make search name=programnév parancsot, ahol a programnév a keresendõ program neve. Például, ha az lsof programot keressük: &prompt.root; cd /usr/ports &prompt.root; make search name=lsof Port: lsof-4.56.4 Path: /usr/ports/sysutils/lsof Info: Lists information about open files (similar to fstat(1)) Maint: obrien@FreeBSD.org Index: sysutils B-deps: R-deps: A keresés eredményében leginkább a Path: kezdetû sorra kell odafigyelnünk, mivel ez árulja el, hol is találhatjuk meg a portot. Az itt szereplõ többi információ nem szükséges a port telepítéséhez, ezért azokkal itt most nem foglalkozunk. Mélyebb keresésekhez használhatjuk a make search key=szöveg parancsot is, ahol a szöveg a keresendõ szöveg(részlet) lesz. Ezt a rendszer keresni fogja a portok neveiben, megjegyzésekben, leírásokban és függõségekben. Amikor nem ismerjük a keresett program nevét, ez olyan portok keresésére alkalmas, amelyek egy adott témához kapcsolódnak. A fenti esetek mindegyikében a keresés nem különbözteti meg a kis- és nagybetûket. Tehát a LSOF keresése ugyanazt az eredményt adja, mint az lsof esetén. Chern Lee Írta: A csomagrendszer használata &os; alatt több különbözõ módon tudunk csomagokat használni: A sysinstall használatán keresztül a futó rendszeren tudjuk megnézni a telepített csomagokat, tudunk vele csomagokat telepíteni vagy törölni. Ezzel részletesebben a telepítés utáni teendõket tartalmazó része foglalkozik. A szakasz további részében ismertetett egyéb parancssoros csomagkezelõ segédprogramok. Csomagok telepítése csomagok telepítése pkg_add A &man.pkg.add.1; segédprogram segítségével telepíthetünk &os;-hez készült szoftvercsomagokat lokálisan vagy a hálózaton levõ egyik szerveren megtalálható állományokból: Csomagok letöltése manuálisan és telepítése lokálisan &prompt.root; ftp -a ftp2.FreeBSD.org Connected to ftp2.FreeBSD.org. 220 ftp2.FreeBSD.org FTP server (Version 6.00LS) ready. 331 Guest login ok, send your email address as password. 230- 230- This machine is in Vienna, VA, USA, hosted by Verio. 230- Questions? E-mail freebsd@vienna.verio.net. 230- 230- 230 Guest login ok, access restrictions apply. Remote system type is UNIX. Using binary mode to transfer files. ftp> cd /pub/FreeBSD/ports/packages/sysutils/ 250 CWD command successful. ftp> get lsof-4.56.4.tgz local: lsof-4.56.4.tgz remote: lsof-4.56.4.tgz 200 PORT command successful. 150 Opening BINARY mode data connection for 'lsof-4.56.4.tgz' (92375 bytes). 100% |**************************************************| 92375 00:00 ETA 226 Transfer complete. 92375 bytes received in 5.60 seconds (16.11 KB/s) ftp> exit &prompt.root; pkg_add lsof-4.56.4.tgz Ha nincsenek egyáltalán helyben csomagjaink (például egy &os; CD-készletben), akkor a legjobban úgy járunk, ha a használjuk a &man.pkg.add.1; kapcsolóját. Ennek hatására a segédprogram önmagától meghatározza a szükséges állományformátumot és verziót, majd FTP-n keresztül letölti és telepíti a csomagot. pkg_add &prompt.root; pkg_add -r lsof Az iménti példában a program mindenféle további beavatkozás nélkül letölti a megfelelõ csomagot és felteszi. Ha a központi helyett egy másik szervert szeretnénk használni, felül kell bírálnunk az alapértelmezett beállításokat és igényeinknek megfelelõen be kell állítanunk a PACKAGESITE környezeti változó értékét. A &man.pkg.add.1; a &man.fetch.3; programot használja az állományok letöltésére, amely pedig számos egyéb környezeti változót is figyel, mint például az FTP_PASSIVE_MODE, az FTP_PROXY és az FTP_PASSWORD. Ha tûzfal mögött vagyunk, ezek közül néhányat biztosan be kell majd állítanunk, vagy FTP/HTTP proxyt kell használnunk. A &man.fetch.3; man oldalán megtaláljuk ezen változók teljes felsorolását. Figyeljük meg, hogy az lsof-4.56.4 helyett csak lsof-ot adtunk meg. Amikor ugyanis kérjük a csomag letöltését is, nem szabad verziószámot megadnunk. A &man.pkg.add.1; mindig az alkalmazás legfrissebb verzióját fogja letöltetni. Ha a &os.current; vagy &os.stable; verziókat használjuk, a &man.pkg.add.1; mindig az alkalmazás elérhetõ legfrissebb verzióját fogja letölteni. Ha azonban valamelyik -RELEASE verziót használjuk, a csomagnak az adott kiadáshoz készült verzióját fogja leszedni. Ezt a mûködési módot a PACKAGESITE változó felülírásával viszont meg tudjuk változtatni. Például ha a &os; 5.4-RELEASE változatával dolgozunk, a &man.pkg.add.1; alapértelmezés szerint a ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-5.4-release/Latest/ címrõl fogja letölteni a csomagokat. Ha mi viszont a &os; 5-STABLE csomagok letöltését akarjuk elérni, állítsuk az PACKAGESITE értékét a ftp://ftp.freebsd.org/pub/FreeBSD/i386/packages-5-stable/Latest/ címre. A csomagok .tgz és .tbz formátumokban kerülnek terjesztésre. Ezek az címen, vagy pedig a &os; CD-ken találhatóak meg. A 4 CD-bõl álló készlet (illetve a PowerPak stb.) minden CD-jén találhatunk csomagokat a packages/ könyvtárban. A csomagokat tároló könyvtár struktúrája hasonló a /usr/ports könyvtárban kialakított könyvtárfához. Minden kategóriának saját könyvtára van, és minden csomag megtalálható az All (összes) kategóriában. A csomagrendszer könyvtárszerkezete tehát megegyezik a portok szétosztásával, ezáltal így képesek egymással összedolgozni a teljes csomag/port rendszer megformálásában. A csomagok kezelése csomagok kezelés A &man.pkg.info.1; egy olyan segédprogram, amellyel készíteni lehet egy listát a telepített csomagokról, és emellett még más egyéb információkat tudhatunk meg róluk. pkg_info &prompt.root; pkg_info cvsup-16.1 A general network file distribution system optimized for CV docbook-1.2 Meta-port for the different versions of the DocBook DTD ... A &man.pkg.version.1; összefoglalja az összes telepített csomag verzióját. Ezenkívül össze is hasonlítja a csomagok verzióját a portfában található aktuális verziókéval. pkg_version &prompt.root; pkg_version cvsup = docbook = ... A második oszlopban látható jelek utalnak a telepített verzió a helyi portfában található verzióéhoz viszonyított korára. Jel Jelentés = A telepített csomag verziója megegyzik a helyi portfában található verziójával. < A telepített verzió a portfában levõnél régebbi. > A telepített verzió újabb, mint a portfában található. (A helyi portfa valószínûleg nem lett frissítve.) ? A telepített csomag nem található a portok között. (Ez akkor történhet meg, amikor például egy portot eltávolítottak a Portgyûjteménybõl vagy átnevezték.) * A csomagnak több verziója is jelen van. ! A telepített csomag szerepel az indexben, de a pkg_version valamiért nem volt képes összehasonlítani a verziószámát az indexben levõ bejegyzéssel. Csomagok törlése pkg_delete csomagok törlés Egy korábban már telepített csomag eltávolításához használjuk a &man.pkg.delete.1; segédprogramot. &prompt.root; pkg_delete xchat-1.7.1 A &man.pkg.delete.1; használatánál szükség van a csomag teljes nevének és verziószámának megadására. A fenti parancs tehát nem mûködik, ha csak az xchat-et adjuk meg az xchat-1.7.1 helyett. A telepített csomag verzióját azonban könnyedén kitalálhatjuk a &man.pkg.version.1; alkalmazásával. Esetleg egyszerûen dzsókerkaraktereket is használhatunk: &prompt.root; pkg_delete xchat\* Ebben az esetben az összes xchat-tel kezdõdõ csomagot letörli. Egyebek A csomagokra vonatkozó összes információ a /var/db/pkg könyvtárban található. Az egyes csomagok leírása és hozzájuk telepített állományok listája az ezen a könyvtáron belül elhelyezkedõ állományokban tárolódik. A Portgyûjtemény használata A most következõ szakaszokban megismerhetjük azokat az alapvetõ utasításokat, amelyekkel a Portgyûjteményen keresztül tudunk programokat telepíteni és eltávolítani. Az ehhez használható make targetek és környezeti változók részletesebb leírását a &man.ports.7; man oldalán lelhetjük meg. A Portgyûjtemény beszerzése Mielõtt bármelyik portot is tudnánk telepíteni, elsõként magát a Portgyûjteményt kell megszereznünk — ez lényegében a /usr/ports könyvtárban megtalálható Makefile állományok, javítások és leírások gyûjteménye. A &os; telepítése közben a sysinstall rákérdez a Portgyûjtemény telepítésére is. Ha erre nemet válaszoltunk volna, a portok gyûjteményét az alábbi módokon szerezhetjük be: A CVSup használatával A CVSup protokoll használatával viszonylag gyorsan el tudjuk érni és naprakészen tudjuk tartani a Portgyûjtemény egy példányát. A CVSup használatát alaposabban a A CVSup használata címû függelékben ismerhetjük meg. A &os; 6.2 változatától kezdve az alaprendszerben a CVSup protokollt a csup valósítja meg. A &os; korábbi változatának használói ezt a programot a net/csup porton vagy csomagon keresztül tudják telepíteni. Gondoskodjunk róla, hogy a /usr/ports üres legyen a csup elsõ futtatása elõtt! Ha más forrásból raktuk ide a Portgyûjteményt, a csup nem fogja lenyesegetni az azóta eltávolított javításokat. Futtassuk a csup programot: &prompt.root; csup -L 2 -h cvsup.FreeBSD.org /usr/share/examples/cvsup/ports-supfile Itt írjuk át a cvsup.FreeBSD.org címét a hozzánk legközelebb levõ CVSup szerver címére. Az összes elérhetõ tükörszerver címét a CVSup tükrözések () címû részben olvashatjuk. Ha például el akarjuk kerülni a CVSup szerver megadását a parancssorban, akkor mindenképpen a ports-supfile állományból érdemes készíteni egy saját verziót. Ebben az esetben root felhasználóként másoljuk a /usr/share/examples/cvsup/ports-supfile állományt egy új helyre, például a /root könyvtárba vagy a saját felhasználói könyvtárunkba. Szerkesszük át a ports-supfile állományt. Írjuk át a CHANGE_THIS.FreeBSD.org értéket a hozzánk legközelebb található CVSup szerverére. A CVSup tükrözések () címû részben megtaláljuk az összes ilyen tükörszervert. És most indítsuk el a csup parancsot az alábbi módon: &prompt.root; csup -L 2 /root/ports-supfile A &man.csup.1; parancs késõbbi futása során már letölti és érvényesíti az észlelt változtatásokat a saját Portgyûjteményünkben, de a telepített portokat viszont nem fogja újrafordítani. A Portsnap használatával A Portsnap egy másik módszert képvisel a Portgyûjtemény terjesztésére, a lehetõségeinek részletesebb megismeréséhez tekintsük át A Portsnap használata címû szakaszt. Töltsük le a Portgyûjtemény tömörített pillanatképét a /var/db/portsnap könyvtárba. Ha akarjuk, ezután a lépés után már lekapcsolódhatunk az internetrõl. &prompt.root; portsnap fetch Ha még csak elõször futtatjuk a Portsnapet, bontsuk ki az imént letöltött állapotot a /usr/ports könyvtárba: &prompt.root; portsnap extract Ha viszont már korábban is létezett a /usr/ports könyvtárunk és most csak frissítjük, akkor helyette ezt a parancsot adjuk ki: &prompt.root; portsnap update A <application>sysinstall</application> használatával Ebben az esetben a sysinstall nevû programmal telepítjük a Portgyûjteményt valamilyen telepítõeszközrõl. Ilyenkor azonban a kiadás dátumának megfelelõ, valószínûlég régebbi változat kerül fel. Ha rendelkezünk internet-hozzáféréssel, akkor inkább az elõbb tárgyalt módszerek valamelyikét alkalmazzuk. root felhasználóként adjuk ki a sysinstall (vagy a &os; 5.2 elõtti verzióban a /stand/sysinstall) parancsot, ahogy itt is láthatjuk: &prompt.root; sysinstall Menjünk le és álljunk meg a Configure (Beállítások), menüpontnál, és nyomjunk Enter billentyût. Menjünk le és keressük meg a Distributions (Terjesztések) menüponot, majd nyomjunk meg az Enter billentyût. Menjünk le, válasszuk ki a ports elemet a Szóköz megnyomásával. Menjünk fel az Exit (Kilépés) ponthoz, nyomjunk meg az Enter billentyût. Válasszuk ki a telepítéshez használni kívánt eszközt, mint például CD, FTP stb. Menjünk fel az Exit (Kilépés) menüpontig, majd nyomjunk meg az Enter billentyût. Végezetül lépjünk ki a sysinstall programból, aminhez nyomjunk meg az X billentyût. Portok telepítése portok telepítés A váz fogalma az elsõ, amit a Portgyûjteménnyel kapcsolatban tisztázni kell. Dióhéjban összefoglalva, egy port váza azon állományok legszûkebb halmaza, amelyek elárulják a &os; számára, hogyan fordítsuk le hibamentesen és hogyan telepítsük az adott programot. Ehhez minden port vázában megtalálható: Egy Makefile nevû állomány. Ez tartalmazza azokat a különbözõ utasításokat, amelyek megmondják, hogyan kell lefordítani és hova kell telepíteni a rendszerünkben az adott alkalmazást. Egy distinfo nevû állomány. Ebben található információ a port lefordításához szükséges állományok letöltésérõl, valamint a letöltött állományok ellenõrzéséhez szükséges (az &man.md5.1; és &man.sha256.1; programokkal számolt) ellenõrzõösszegek. Egy files alkönyvtár. Itt találhatjuk meg azokat a javításokat, amelyek alkalmazásával le tudjuk fordítani a programot &os;-n is. Ezek a javítások többnyire bizonyos állományok módosításaira vonatkozó apró állományok formájában jelennek meg. Természetüknél fogva szöveges formátumúak, és általában olyanok szerepelnek bennük, hogy Töröld a 10. sort vagy Változtasd meg a 26. sort erre: .... Ezeket a javításokat eredetileg patcheknek (foltoknak) nevezik, vagy másképp diffeknek (eltéréseknek) is, mivel a &man.diff.1; program segítségével hozzák ezeket létre. Ez a könyvtár tartalmazhat további állományokat is portok elkészítéséhez. Egy pkg-descr nevû állomány. Ez a program részletesebb, gyakran többsoros bemutatása. Egy pkg-plist nevû állomány. Itt találjuk meg a port által telepítendõ összes állományt. Ez egyben közli a portrendszerrel is, hogy az eltávolítás során mely állományokat kell majd törölnie. Egyes portokban szereplhetnek még egyéb állományok is, mint például a pkg-message. Ezeket az állományokat a portrendszer különleges helyzetek kezelésére tartogatja. Ha még többet kívánunk megtudni ezekrõl az állományokról, vagy magukról a portokról általánosságban, lapozzuk fel a &os; porterek kézikönyvét. A port ugyan tartalmazza a forráskód lefordításához szükséges utasításokat, de konkrétan a forráskódot viszont nem. Ezt egy CD-rõl vagy az internetrõl tudjuk megszerezni. A forráskód általában a szerzõje által kedvelt formában jelenik meg: ez gyakran egy gzip-pel tömörített tar állomány, de lehet tömörítve mással is, vagy éppen lehet tömörítetlen. A program forráskódját, legyen akármilyen formában is, nevezik distfile-nak (terjesztési állománynak). A &os; portok telepítésének két módszerét tárjuk fel a következõkben. A portok telepítéséhez root felhasználóként kell bejelentkeznünk. Mielõtt telepítenénk bármelyik portot is, ajánlott frissíteni a Portgyûjteményünket és ellenõriznünk az adott portot a címen található biztonsági adatbázisban. Az újonnan telepítendõ alkalmazások biztonsági sebezhetõségeinek ellenõrzését automatikussá is tehetjük a portaudit használatával. Ez a segédeszköz is a Portgyûjteményben található (ports-mgmt/portaudit). Érdemes minden port telepítése elõtt letöltenünk a legfrissebb sebezhetõségi adatbázist a portaudit -F parancs kiadásával. Mellesleg az adatbázis rendszeres frissítése és ez a biztonsági felülvizsgálat a naponként elvégzendõ biztonsági ellenõrzések közt is megjelenik. Ezekrõl részletesebben a &man.portaudit.1; és &man.periodic.8; man oldalakon olvashatunk. A Portgyûjtemény feltételezi, hogy mûködõ internet-hozzáféréssel rendelkezünk. Amennyiben ez nem így lenne, a terjesztési állományokat, forráskódokat saját magunknak kell bemásolnunk a /usr/ports/distfiles könyvtárba. A kezdéshez lépjünk be a telepítendõ port könyvtárába: &prompt.root; cd /usr/ports/sysutils/lsof Miután beléptünk az lsof könyvtárába, láthatjuk a port vázát. A következõ lépés a fordítás avagy a port buildelése (elkészítése). Ezt egy szimpla make parancs kiadásával kezdeményezhetjük. Miután megtettük, valami ilyesmit kell tapasztalnunk: &prompt.root; make >> lsof_4.57D.freebsd.tar.gz doesn't seem to exist in /usr/ports/distfiles/. >> Attempting to fetch from ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/. ===> Extracting for lsof-4.57 ... [ide jön a kitömörítés kimenete] ... >> Checksum OK for lsof_4.57D.freebsd.tar.gz. ===> Patching for lsof-4.57 ===> Applying FreeBSD patches for lsof-4.57 ===> Configuring for lsof-4.57 ... [ide jön a configure szkript kimenete] ... ===> Building for lsof-4.57 ... [ide jön a fordítás kimenete] ... &prompt.root; A fordítás befejeztével visszakapjunk a parancssort. A soron következõ lépés a port telepítése lesz. Ehhez mindössze egyetlen szóval kell kiegészítenünk a make parancs meghívását: ez a szó pedig az install (telepít) lesz. &prompt.root; make install ===> Installing for lsof-4.57 ... [a telepítés kimenete kimarad] ... ===> Generating temporary packing list ===> Compressing manual pages for lsof-4.57 ===> Registering installation for lsof-4.57 ===> SECURITY NOTE: This port has installed the following binaries which execute with increased privileges. &prompt.root; Miután ismét visszakaptuk a parancssort, már futtatni is tudjuk a frissen telepített alkalmazásunkat. Mivel az lsof programnak tovább jogosultságokra is szüksége van, egy errõl szóló biztonsági figyelmeztetést is láthatunk. A portok létrehozása és telepítése során érdemes figyelnünk az ehhez hasonló figyelmeztetésekre. A telepítés befejeztével nem árt törölnünk a fordításhoz felhasznált alkönyvtárat (work) is. Ezzel nemcsak a drága lemezterületet spóroljuk meg, hanem megelõzzük a port késõbbi frissítése során felmerülõ esetleges problémákat is. &prompt.root; make clean ===> Cleaning for lsof-4.57 &prompt.root; Az eljárásból két lépést meg is tudunk takarítani, ha egyszerûen csak a make install clean parancsot adjuk ki az elõbb három lépésben tagolt make, make install és make clean parancsok helyett. Bizonyos parancsértelmezõk a PATH környezeti változóban felsorolt könyvtárakban található parancsokat gyorsítótárban tárolják, ezzel felgyorsítva a hozzájuk tartozó végrehajtható állományok keresését. Ha történetesen ilyen parancsértelmezõt használnánk, az új portok telepítése után szükségünk lehet a rehash parancs kiadására, mivel enélkül nem tudjuk elérni a frissen telepített parancsokat. Ezt a parancsot például a tcsh és a hozzá hasonló parancsértelmezõkben találhatjuk meg, az sh és rokonainál pedig a hash -r ennek a megfelelõje. A pontos információkat errõl a témáról a parancsértelmezõnk dokumentációjában lelhetjük meg. Némely külsõ DVD termék, mint például a &os; Malltól megrendelhetõ &os; Toolkit, tartalmazhatnak terjesztési állományokat. Ezek remekül használhatóak a Portgyûjteménnyel. Ehhez csatlakoztatnunk kell a DVD-t a /cdrom könyvtárba. Ettõl eltérõ csatlakozási pontok használata esetén ne felejtsük el átállítani a CD_MOUNTPTS változót sem a make számára. Ekkor a fordításhoz szükséges állományokat úgy fogja kezelni a rendszer, mintha a merevlemezünkön lennének. Vigyázzunk arra, hogy néhány portot nem lehet CD-n terjeszteni. Ez részben azért lehet, mert a szükséges állományok letöltéséhez, illetve újbóli terjesztéséhez ki kell tölteni valamilyen regisztrációs nyomtatványt, vagy pedig egyéb okok miatt. Tehát ha olyan portot akarunk telepíteni, ami nincs rajta a CD-n, mindenképpen rendelkeznünk kell internetkapcsolattal. A portrendszer a &man.fetch.1; segédprogramot használja az állományok letöltésére, amely figyelembevesz különféle környezeti változókat, ilyenek többek közt az FTP_PASSIVE_MODE, FTP_PROXY és az FTP_PASSWORD. Ha tûzfal mögött vagyunk, szükségünk lehet ezek némelyikének helyes beállítására, vagy FTP/HTTP proxyt kell használnunk. A &man.fetch.3; man oldala tartalmazza ezen változók teljes listáját. A make fetch azon felhasználók számára nyújt segítséget, akik nem csatlakoznak minden esetben a hálózatra. Egyszerûen csak futtassuk le a könyvtárszerkezet legtetejérõl (/usr/ports) ezt a parancsot és a szükséges állományok letöltõdnek nekünk. A parancs mûködik az alsóbb szinteken is, például a /usr/ports/net könyvtárban. Azonban legyünk tekintettel arra, hogy ha egy port függ más portoktól vagy függvénykönyvtáraktól, ez a parancs nem fogja letölteni a hozzájuk tartozó állományokat. Ilyenkor a fetch helyett használjuk a fetch-recursive targetet. Ha a make parancsot egy felsõbb szinten futtatjuk, akkor ezzel létre tudjuk hozni az összes vagy csak kategóriánként az összes portot, hasonlóan az elõbb említett make fetch módszerhez. Ez azonban veszélyes, mivel egyes portok kizárják mások használatát. Emellett elõfordulhat az is, hogy bizonyos portok ugyanazon a néven telepítenek több, tartalmukban különbözõ állományt. Nagyon ritkán adódhat, hogy a felhasználónak nem a MASTER_SITES által mutatott helyekrõl kell beszereznie a szükséges állományokat (innen töltõdnek ugyanis le). A MASTER_SITES beállítást az alábbi paranccsal bírálhatjuk felül: &prompt.root; cd /usr/ports/könyvtár &prompt.root; make MASTER_SITE_OVERRIDE= \ ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/ fetch Ebben a példában a MASTER_SITES értékét a ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/ címre változtattuk meg. A portok némelyike lehetõvé teszi (esetleg meg is követeli), hogy engedélyezzük vagy letiltsuk a készülõ program bizonyos elemeit hatékonysági, biztonsági vagy egyéb testreszabási irányelvek mentén. Ilyen többek közt a www/mozilla, a security/gpgme és a mail/sylpheed-claws. Ha elérhetõek ilyen beállítási lehetõségek, arról a rendszer egy üzenetben tájékoztat minket. Az alapértelmezett könyvtárak felülbírálása Néha hasznos (vagy kötelezõ) lehet eltérõ munka- és célkönyvtárak alkalmazása. A WRKDIRPREFIX és a PREFIX változókkal ezek alapértelmezéseit tudjuk megváltoztatni. Például a &prompt.root; make WRKDIRPREFIX=/usr/home/example/ports install parancs a portot a /usr/home/example/ports könyvtárban fogja lefordítani és az eredményét a /usr/local könyvtárba telepíti. A &prompt.root; make PREFIX=/usr/home/example/local install parancs hatására a port a /usr/ports könyvtárban készül el és a /usr/home/example/local könyvtárba települ. Természetesen a &prompt.root; make WRKDIRPREFIX=../ports PREFIX=../local install parancs ötvözi az elõbbi kettõt (amelyet most túlságosan is hosszú lenne kiírni, de vélhetõen sejthetõ belõle az alapötlet). Lehetõség van ezen változókat a saját környezetünkben is beállítani. Ha erre lenne szükségünk, nézzünk utána az ezzel kapcsolatos teendõnek a parancsértelmezõnk man oldalán. Az <command>imake</command> használatáról Bizonyos portok az (X Window System részeként megjelenõ) imake segédprogramra támaszkodnak, ahol viszont nem mûködik a PREFIX átállítása és mindenképpen a /usr/X11R6 könyvtárba akar telepíteni. Ehhez hasonlóan egyes Perl portok figyelmen kívül hagyják a PREFIX változót és közvetlenül a Perl fájába kerülnek. Az ilyen portok esetén nagyon nehéz vagy szinte lehetetlen betartatni a PREFIX használatát. A portok újrakonfigurálása Egyes portok lefordítása elõtt megjelenik egy ncurses alapú menü, ahol ki tudunk választani bizonyos fordítási beállításokat. Gyakran elõfordul, hogy a port lefordítása után a felhasználók szeretnék újra elõhozni ezt a menüt és megadni vagy kivenni bizonyos beállításokat. Erre több mód is kínálkozik. Egyik ilyen lehetõség az, ha belépünk a port könyvtárába és kiadjuk a make config parancsot, amivel lényegében ismét elõcsaljuk a beállításokat összefoglaló menüt. Másik ilyen lehetõség a make showconfig alkalmazása, amivel a porthoz tartozó összes beállítást tudjuk egyszerre megjeleníteni. Ezek mellett még használható a make rmconfig parancs is, amivel törölni tudjuk az összes eddigi beállítást és így újrakezdhetjük a port konfigurációját. Ezek és a többi ilyen opció a &man.ports.7; man oldalon kerül bõvebb kifejtésre. A portok eltávolítása portok eltávolítás Most már tudjuk, miként lehet portokat telepíteni, azonban valószínûleg még az is érdekelhet minket, hogy miként kell ezeket eltávolítani abban az esetben, ha például késõbb meggondolnánk magunkat velük kapcsolatban. A korábban telepített példaportot fogjuk eltávolítani (a figyelmetlenek kedvéért megemlítjük, hogy ez az lsof volt). A portok eltávolítása teljesen egybevág a csomagokéval (errõl a csomagokról szóló részben beszéltünk), mivel ekkor is használhatjuk a &man.pkg.delete.1; parancsot: &prompt.root; pkg_delete lsof-4.57 A portok frissítése portok frissítés Elõször is a &man.pkg.version.1; parancs felhasználásával listázzuk ki azokat a portokat, amik felett már eljárt az idõ és a Portgyûjteményben található belõlük újabb verzió: &prompt.root; pkg_version -v A <filename>/usr/ports/UPDATING</filename> állomány Miután frissítettük a Portgyûjteményünket, de még mielõtt megpróbálnánk akármelyik portot is frissíteni, érdemes egy pillantást vetnünk a /usr/ports/UPDATING állományra. Itt megtalálhatóak azok a problémák és a hozzájuk tartozó lépések, amelyekkel a felhasználóknak a portok frissítése során szembe kell nézniük, beleértve az állományformátumok, a konfigurációs állományok helyének megváltozását vagy egyéb olyan módosításokat, amik a korábbi verziókkal összeférhetetlenséget szülhetnek. Amennyiben az UPDATING állomány tartalma ellentmondana az itt olvasottakkal, mindig az UPDATING állományban leírtak az irányadóak. Portok frissítése a <application>portupgrade</application> használatával portupgrade A portupgrade nevû segédprogramot a portok egyszerûbb frissítésére találták ki, és a ports-mgmt/portupgrade portban található meg. A make install clean paranccsal bármelyik más porthoz hasonlóan telepíthetjük: &prompt.root; cd /usr/ports/ports-mgmt/portupgrade &prompt.root; make install clean A pkgdb -F paranccsal fésültessük át a telepített portok listáját, és javítsuk az általa jelentett ellentmondásokat. Érdemes rendszeresen elvégezni ezt, lehetõleg minden frissítés elõtt. Miután kiadtuk a portupgrade -a parancsot, a portupgrade nekilát frissíteni az összes elavult portot a rendszerünkben. Ha minden egyes frissítést külön meg szeretnénk erõsíteni, használjuk a kapcsolót is. &prompt.root; portupgrade -ai Ha nem akarjuk az összes portot frissíteni, csupán egy bizonyos alkalmazásét, használjuk a portupgrade pkgname paraméterezést. A kapcsoló megadásával a portupgrade elõször frissíti az adott alkalmazás függõségeit. &prompt.root; portupgrade -R firefox Ha a mûvelet során csomagokat kívánunk használni portok helyett, adjuk meg a kapcsolót. Ennek révén a portupgrade megkeresi a csomagokat a PKG_PATH környezeti változóban felsorolt könyvtárakban vagy ha itt nem találja, letölti ezeket egy távoli szerverrõl. Amennyiben a csomagokat sem helyben, sem pedig a távoli szerveren nem találja, a portupgrade helyettük portokat fog használni. Ilyenkor a portok használatát a kapcsoló beállításával lehet elkerülni: &prompt.root; portupgrade -PP gnome2 Csak a terjesztési állományok (vagy a esetén csomagok) letöltéséhez használjuk a kapcsolót. Mindezekrõl részletesebben a &man.portupgrade.1; man oldalon olvashatunk. Portok frisstse a <application>Portmanager</application> használatával portmanager A Portmanager egy másik hasznos segédprogram a portok könnyû frissítéséhez. A ports-mgmt/portmanager porton keresztül érhetõ el: &prompt.root; cd /usr/ports/ports-mgmt/portmanager &prompt.root; make install clean Használatával az összes telepített port egyetlen paranccsal frissíthetõ: &prompt.root; portmanager -u Ha a Portmanager minden egyes lépését külön meg kívánjuk erõsíteni, akkor a kapcsolókat se felejtsük el megadni. A Portmanager emellett új portok telepítésére is használható. Eltérõen a make install clean parancsban megszokottaktól, a kiválasztott port összes függõségét még a fordítás és a telepítés elõtt fogja frissíteni. &prompt.root; portmanager x11/gnome2 Ha bármilyen gondot tapasztalnánk a kiválasztott port függõségeit illetõen, a Portmanagert felkérhetjük az összes függõség helyes sorrendben történõ újrafordítására. Amikor befejezte, a problémás portot is újra létrehozza. &prompt.root; portmanager graphics/gimp -f Bõvebb információkért lásd &man.portmanager.1;. Portok frissítése a <application>Portmaster</application> használatával portmaster A Portmaster szintén a portok frissítésére alkalmas segédprogram. A Portmaster esetében a hangsúly az alaprendszerben is megtalálható eszközök használatán van (tehát nem függ semmilyen más porttól) és a /var/db/pkg/ könyvtárban található információk alapján dönti el, hogy milyen portokat kell frissítenie. A ports-mgmt/portmaster portból érhetõ el: &prompt.root; cd /usr/ports/ports-mgmt/portmaster &prompt.root; make install clean A Portmaster a portokat az alábbi négy kategória valamelyikébe sorolja be: Gyökér (root) portok (nem függenek semmitõl, semmi sem függ tõlük) Törzs (trunk) portok (nem függenek semmitõl, de mások függenek tõlük) Ág (branch) portok (vannak függõségeik és mások is függenek tõlük) Levél (leaf) portok (vannak függõségeik, de semmi sem függ tõlük) A következõ paranccsal le tudjuk kérni az összes telepített portot és az kapcsolóval frissítéseket keresni hozzájuk: &prompt.root; portmaster -L ===>>> Root ports (No dependencies, not depended on) ===>>> ispell-3.2.06_18 ===>>> screen-4.0.3 ===>>> New version available: screen-4.0.3_1 ===>>> tcpflow-0.21_1 ===>>> 7 root ports ... ===>>> Branch ports (Have dependencies, are depended on) ===>>> apache-2.2.3 ===>>> New version available: apache-2.2.8 ... ===>>> Leaf ports (Have dependencies, not depended on) ===>>> automake-1.9.6_2 ===>>> bash-3.1.17 ===>>> New version available: bash-3.2.33 ... ===>>> 32 leaf ports ===>>> 137 total installed ports ===>>> 83 have new versions available Az összes telepített port egyetlen egyszerû paranccsal frissíthetõ: &prompt.root; portmaster -a A Portmaster alapértelmezés szerint minden egyes törlendõ korábbi portról biztonsági másolatot készít. Amikor az új változat telepítése sikeresen lezajlott, akkor a Portmaster ezt a másolatot megsemmisíti. A paraméterrel azonban megkérhetjük, hogy ne törölje le a biztonsági mentést. Az megadásával a Portmaster interaktív módban indul el, és minden port frissítése elõtt a felhasználó megerõsítését fogja kérni. Amennyiben valamilyen hiba lép fel a frissítés folyamán, az opció megadásával kérhetjük az összes port frissítését és újrafordítását is: &prompt.root; portmaster -af A Portmaster használatával új portokat is fel tudunk telepíteni a rendszerre úgy, hogy azok függõségeit is igyekszik frissíteni a lefordításuk elõtt: &prompt.root; portmaster shells/bash A további részleteket a &man.portmaster.8; man oldalon találjuk. A portok tárigénye portok tárigény A Portgyûjtemény idõvel egyre több helyet fog elfoglalni a merevlemezünkön. Miután sikeresen létrehoztunk és telepítettünk egy szoftvert a hozzátartozó portból, érdemes mindig eltakarítanunk magunk után a work könyvtárban menet közben keletkezett átmeneti állományokat a make clean parancs használatával. Az egész Portgyûjteményt egyetlen mozdulattal ezzel a paranccsal tudjuk végigsepregetni: &prompt.root; portsclean -C Az idõ elõrehaladtával a distfiles könyvtárban is rengeteg régi forrás tud felhalmazódni. Ezeket eltávolíthatjuk kézzel, vagy az alábbi parancs segítségével törölhetjük az összes olyan terjesztési állományt, amelyekre már egyetlen port sem hivatkozik: &prompt.root; portsclean -D Vagy törölhetjük az összes olyan terjesztési állományt, amelyre egyetlen pillanatnyilag feltelepített port sem hivatkozik a rendszerünkben: &prompt.root; portsclean -DD A portsclean segédprogram a portupgrade programcsomag része. Ne felejtsük el eltávolítani azokat a portokat, amikre már nincs szükségünk a továbbiakban. Ebben a feladatban egy jól használható segédeszköz lehet a segítségünkre, a ports-mgmt/pkg_cutleaves port. Telepítés utáni teendõk Az új alkalmazás feltelepítése után minden bizonnyal szeretnénk elolvasni a hozzá társított dokumentációt, az egyedi beállításainknak megfelelõen módosítani a konfigurációs állományokat, engedélyezni a rendszerindítás során történõ automatikus indítását (ha démonról lenne szó) és így tovább. Az egyes alkalmazások beállításához elvégzendõ lépések nyilvánvalóan egyedenként eltérõek. Azonban tudunk szolgálni néhány általános tanáccsal válaszként az ilyenkor felmerülõ Na és akkor most mi legyen? kérdésre: Kérdezzük meg a &man.pkg.info.1; programtól, milyen állományok és hova kerültek fel a telepítés során. Például, ha a SzuperCsomag 1.0.0-át raktunk fel, akkor a &prompt.root; pkg_info -L SzuperCsomag-1.0.0 | less parancs kilistázza az összes állományt, amit a csomagból felraktunk. Ezek közül leginkább a man/ könyvtárban levõekre figyeljünk, mivel ezek lesznek az alkalmazás man oldalai. Ehhez hasonlóan a etc/ könyvtárban a konfigurációs állományok és a doc/ könyvtárban pedig a nagyobb lélegzetvételû dokumentációk foglalnak helyet. Ha nem emlékszünk pontosan rá, hogy az alkalmazások melyik verzióját is telepítettük, a &prompt.root; pkg_info | grep -i SzuperCsomag alakú parancs megkeresi az összes olyan csomagot, aminek a nevében szerepel a SzuperCsomag szövegrészlet. A fenti példában természetesen igény szerint változtassuk meg a SzuperCsomag szöveget a tényleges csomag nevére. Ahogy sikerült megtalálnunk az alkalmazáshoz tartozó man oldalakat, lapozzuk fel ezeket a &man.man.1; segítségével. Ugyanígy nézzük át a mellékelt minta konfigurációs állományokat és az összes elérhetõ dokumentációt. Ha az alkalmazásnak van saját honlapja, kutassunk ott is információk után, olvassuk el a gyakran ismételt kérdéseket és így tovább. Ha nem tudnánk pontosan a honlap címét, a &prompt.root; pkg_info SzuperCsomag-1.0.0 kimenetébõl könnyen elõkeríthetõ. Itt egy WWW: kezdetû sort kell keresnünk (már amennyiben létezik), amit az alkalmazás honlapjának címe kell kövessen. A rendszerrel együtt indítandó portok (ilyenek többek közt az internetes szolgáltatások), általában a /usr/local/etc/rc.d könyvtárba rakják a saját indítószkriptjüket. Érdemes leellenõrizni ezt a szkriptet és az igényeinknek megfelelõen módosítani, átnevezni. A Szolgáltatások indítása címû szakaszban ezt részleteiben is megismerhetjük. Teendõ a sérült portokkal Ha véletlenül ráakadnánk egy olyan portra, ami nem mûködik megfelelõen, nagyjából a következõket tudjuk tenni: Derítsük ki a Hibajelentések adatbázisából, hogy készül-e már javítás az adott porthoz. Ha igen, akkor annak befejezése után már képesek leszünk használni. Kérjük meg a port karbantartóját, hogy segítsen. A karbantartó elérhetõségének felderítéséhez gépeljük be a make maintainer parancsot, vagy keressük meg a Makefile állományban a karbantartó e-mail címét. Ne felejtsük el neki megemlíteni a levélben a port nevét és verzióját (vagyis mindenképpen küldjük el a $FreeBSD: sort a Makefile állományból) és a parancs kiadásától a hiba felbukkanásáig tartó kimenetet. Némely portokat nem egyedülálló személyek tartanak karban, hanem egy levelezési lista. A legtöbbjük neve, ha nem is mindé, nagyjából ilyen alakú: freebsd-listanév@FreeBSD.org. Egy ilyen jellegû kérdés megfogalmazása során ezt is vegyük figyelembe! Kifejezetten a freebsd-ports@FreeBSD.org + role="nolink">ports@FreeBSD.org karbantartóval rendelkezõ portoknak nincs rendes gazdája. A hozzájuk kapcsolódó javítások és mindenféle segítség, ötlet errõl a levelezési listáról érkeznek. Ilyen esetekben számítunk az önkéntes segítõkre! Ha nem kapunk semmilyen választ, a hiba bejelentésére használhatjuk a &man.send-pr.1; programot is (errõl bõvebben lásd a &os;-s hibajelentések írása címû cikket). Javítsuk meg mi magunk! A porterek kézikönyve részletesen taglalja a portok belsõ felépítését, így onnan elindulva akár magunktól is meg tudunk javítani egy esetlegesen sérült portot, vagy be is küldhetjük a sajátunkat! Töltsük le a porthoz tartozó csomagot a hozzánk legközelebb levõ FTP oldalról. A központi csomaggyûjtemény a ftp.FreeBSD.org címen, a packages nevû könyvtárban található, de mielõtt ide fordulnánk, nézzük meg a hozzánk legközelebb levõ tükörszervert is! Ha egy csomagot így telepítünk, akkor több eséllyel fog mûködni és ráadásul még jóval gyorsabb is. A csomag telepítésére használjuk a &man.pkg.add.1; programot. diff --git a/hu_HU.ISO8859-2/share/sgml/mailing-lists.ent b/hu_HU.ISO8859-2/share/sgml/mailing-lists.ent index 54cba11640..a1037ff583 100644 --- a/hu_HU.ISO8859-2/share/sgml/mailing-lists.ent +++ b/hu_HU.ISO8859-2/share/sgml/mailing-lists.ent @@ -1,509 +1,513 @@ FreeBSD lista szerver"> &a.mailman.listinfo;"> FreeBSD ACPI levelezési lista"> freebsd-acpi"> FreeBSD advocacy levelezési lista"> freebsd-advocacy"> FreeBSD AFS levelezési lista"> freebsd-afs"> FreeBSD Adaptec AIC7xxx levelezési lista"> freebsd-aic7xxx"> FreeBSD Alpha levelezési lista"> freebsd-alpha"> FreeBSD AMD64 levelezési lista"> freebsd-amd64"> FreeBSD announcements levelezési lista"> freebsd-announce"> FreeBSD Apache levelezési lista"> freebsd-apache"> FreeBSD architecture and design levelezési lista"> freebsd-arch"> FreeBSD ARM levelezési lista"> freebsd-arm"> FreeBSD ATM networking levelezési lista"> freebsd-atm"> FreeBSD source code audit levelezési lista"> freebsd-audit"> FreeBSD binary update levelezési lista"> freebsd-binup"> FreeBSD Bluetooth levelezési lista"> freebsd-bluetooth"> FreeBSD bugbusters levelezési lista"> freebsd-bugbusters"> FreeBSD problem reports levelezési lista"> freebsd-bugs"> FreeBSD chat levelezési lista"> freebsd-chat"> FreeBSD clustering levelezési lista"> freebsd-cluster"> &os.current; levelezési lista"> freebsd-current"> CTM announcements levelezési lista"> ctm-announce"> CTM distribution of CVS files levelezési lista"> ctm-cvs-cur"> CTM 4-STABLE src branch distribution levelezési lista"> ctm-src-4"> CTM -CURRENT src branch distribution levelezési lista"> ctm-src-cur"> CTM user discussion levelezési lista"> ctm-users"> FreeBSD CVS commit message levelezési lista"> cvs-all"> FreeBSD CVS doc commit lista"> cvs-doc"> FreeBSD CVS ports commit lista"> cvs-ports"> FreeBSD CVS projects commit lista"> cvs-projects"> FreeBSD CVS src commit lista"> cvs-src"> FreeBSD CVSweb maintenance levelezési lista"> freebsd-cvsweb"> FreeBSD based Databases levelezési lista"> freebsd-database"> &os; Dokumentációs Projekt levelezési lista"> freebsd-doc"> FreeBSD device drivers levelezési lista"> freebsd-drivers"> FreeBSD users of Eclipse IDE levelezési lista"> freebsd-eclipse"> FreeBSD-embedded levelezési lista"> freebsd-embedded"> FreeBSD-emulation levelezési lista"> freebsd-emulation"> FreeBSD-eol levelezési lista"> freebsd-eol"> FreeBSD FireWire (IEEE 1394) levelezési lista"> freebsd-firewire"> FreeBSD file system project levelezési lista"> freebsd-fs"> FreeBSD GEOM levelezési lista"> freebsd-geom"> FreeBSD GNOME and GNOME applications levelezési lista"> freebsd-gnome"> FreeBSD technical discussions levelezési lista"> freebsd-hackers"> FreeBSD hardware and equipment levelezési lista"> freebsd-hardware"> FreeBSD mirror sites levelezési lista"> freebsd-hubs"> FreeBSD internationalization levelezési lista"> freebsd-i18n"> FreeBSD i386 levelezési lista"> freebsd-i386"> FreeBSD IA32 levelezési lista"> freebsd-ia32"> FreeBSD IA64 levelezési lista"> freebsd-ia64"> FreeBSD IPFW levelezési lista"> freebsd-ipfw"> FreeBSD ISDN levelezési lista"> freebsd-isdn"> FreeBSD Internet service provider's levelezési lista"> freebsd-isp"> FreeBSD jails levelezési lista"> freebsd-jail"> FreeBSD Java Language levelezési lista"> freebsd-java"> FreeBSD related employment levelezési lista"> freebsd-jobs"> FreeBSD KDE/Qt and KDE applications levelezési lista"> freebsd-kde"> FreeBSD LFS porting levelezési lista"> freebsd-lfs"> FreeBSD libh installation and packaging system levelezési lista"> freebsd-libh"> FreeBSD MIPS levelezési lista"> freebsd-mips"> FreeBSD mirror site adminisztrátorok"> mirror-announce"> FreeBSD laptop computer levelezési lista"> freebsd-mobile"> + +FreeBSD Mono és C# alkalmazások levelezési lista"> +freebsd-mono"> + FreeBSD port of the Mozilla browser levelezési lista"> freebsd-mozilla"> FreeBSD multimedia levelezési lista"> freebsd-multimedia"> FreeBSD networking levelezési lista"> freebsd-net"> FreeBSD new users levelezési lista"> freebsd-newbies"> FreeBSD new-bus levelezési lista"> freebsd-new-bus"> FreeBSD OpenOffice levelezési lista"> freebsd-openoffice"> FreeBSD performance levelezési lista"> freebsd-performance"> FreeBSD Perl levelezési lista"> freebsd-perl"> FreeBSD packet filter levelezési lista"> freebsd-pf"> FreeBSD non-Intel platforms levelezési lista"> freebsd-platforms"> FreeBSD core team policy decisions levelezési lista"> freebsd-policy"> FreeBSD ports levelezési lista"> freebsd-ports"> FreeBSD ports bugs levelezési lista"> freebsd-ports-bugs"> FreeBSD PowerPC levelezési lista"> freebsd-ppc"> FreeBSD on HP ProLiant server levelezési lista"> freebsd-proliant"> FreeBSD Python levelezési lista"> freebsd-python"> FreeBSD Quality Assurance levelezési lista"> freebsd-qa"> FreeBSD general questions levelezési lista"> freebsd-questions"> FreeBSD boot script system levelezési lista"> freebsd-rc"> FreeBSD realtime extensions levelezési lista"> freebsd-realtime"> FreeBSD Ruby levelezési lista"> freebsd-ruby"> FreeBSD SCSI subsystem levelezési lista"> freebsd-scsi"> FreeBSD security levelezési lista"> freebsd-security"> FreeBSD security notifications levelezési lista"> freebsd-security-notifications"> FreeBSD-small levelezési lista"> freebsd-small"> FreeBSD symmetric multiprocessing levelezési lista"> freebsd-smp"> FreeBSD SPARC levelezési lista"> freebsd-sparc64"> &os.stable; levelezési lista"> freebsd-stable"> FreeBSD C99 and POSIX compliance levelezési lista"> freebsd-standards"> FreeBSD sun4v levelezési lista"> freebsd-sun4v"> A teljes src fa SVN commit üzenetei (kivéve user és projects)"> svn-src-all"> Az src fa head/-current ágának SVN commit üzenetei"> svn-src-head"> Az src projects fa SVN commit üzenetei"> svn-src-projects"> Az src fa kiadásokat tartalmazó ágainak SVN commit üzenetei"> svn-src-release"> Az src fa kiadásokkal és biztonsági javításokkal kapcsolatos SVN commit üzenetei"> svn-src-releng"> Az src fa -stable ágainak SVN commit üzenetei"> svn-src-stable"> Az src fa 6-stable ágának SVN commit üzenetei"> svn-src-stable-6"> Az src fa 7-stable ágának SVN commit üzenetei"> svn-src-stable-7"> Az src fa régebbi -stable ágainak SVN commit üzenetei"> svn-src-stable-other"> A repository szkriptjeihez és beállításaihoz tartozó SVN commit üzenetek"> svn-src-svnadmin"> Az src fa kísérleti jellegû user részének SVN commit üzenetei"> svn-src-user"> Az src fa vendor könyvtárának SVN commit üzenetei"> svn-src-vendor"> FreeBSD test levelezési lista"> freebsd-test"> FreeBSD performance and stability testing levelezési lista"> freebsd-testing"> FreeBSD threads levelezési lista"> freebsd-threads"> FreeBSD tokenring levelezési lista"> freebsd-tokenring"> FreeBSD USB levelezési lista"> freebsd-usb"> FreeBSD user group coordination levelezési lista"> freebsd-user-groups"> FreeBSD vendors pre-release coordination levelezési lista"> freebsd-vendors"> Discussion of various virtualization techniques supported by FreeBSD levelezési lista"> freebsd-virtualization"> FreeBSD VuXML levelezési lista"> freebsd-vuxml"> FreeBSD Work-In-Progress Status levelezési lista"> freebsd-wip-status"> FreeBSD Webmaster levelezési lista"> freebsd-www"> FreeBSD X11 levelezési lista"> freebsd-x11"> FreeBSD Xen port levelezési lista"> freebsd-xen"> bug-followup@FreeBSD.org"> majordomo@FreeBSD.org">