diff --git a/hu_HU.ISO8859-2/books/handbook/config/chapter.sgml b/hu_HU.ISO8859-2/books/handbook/config/chapter.sgml index 61c6c0f74a..db3dac14b5 100644 --- a/hu_HU.ISO8859-2/books/handbook/config/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/config/chapter.sgml @@ -1,4842 +1,4752 @@ Chern Lee Írta: Mike Smith Az alapjául szolgáló bemutatást írta: Matt Dillon Valamint az alapját képzõ tuning(7) oldalt írta: Beállítás és finomhangolás Áttekintés a rendszer beállítása a rendszer finomhangolása A &os; egyik fontos szempontja a rendszer megfelelõ beállítása, aminek segítségével elkerülhetjük a késõbbi frissítések során keletkezõ kellemetlenségeket. Ez a fejezet a &os; beállítási folyamatából kíván minél többet bemutatni, köztük a &os; rendszerek finomhangolására szánt paramétereket. A fejezet elolvasása során megismerjük: hogyan dolgozzunk hatékonyan az állományrendszerekkel és a lapozóállományokkal; az rc.conf beállításának alapjait és a /usr/local/etc/rc.d könyvtárban található indítási rendszert; hogyan állítsunk be és próbáljunk ki egy hálózati kártyát; hogyan állítsunk be virtuális címeket a hálózati eszközökeinken; hogyan használjuk az /etc könyvtárban megtalálható különféle konfigurációs állományokat; hogyan hangoljuk a &os; mûködését a sysctl változóinak segítségével; hogyan hangoljuk a lemezek teljesítményét és módosítsuk a rendszermag korlátozásait. A fejezet elolvasásához ajánlott: a &unix; és a &os; alapjainak megértése (); a rendszermag beállításához és fordításához kötõdõ alapok ismerete (). Kezdeti beállítások A partíciók kiosztása partíciókiosztás /etc /var /usr Alappartíciók Amikor a &man.bsdlabel.8; vagy a &man.sysinstall.8; segítségével állományrendszereket telepítünk, nem szabad figyelmen kívül hagynunk a tényt, hogy a merevlemezes egységekben a külsõ sávokból gyorsabban lehet hozzáférni az adatokhoz, mint a belsõkbõl. Emiatt a kisebb és gyakrabban elérni kívánt állományrendszereket a meghajtó lemezének külsejéhez közel kell létrehozni, míg például a /usr partícióhoz hasonló nagyobb partíciókat annak belsõ része felé. A partíciókat a következõ sorrendben érdemes kialakítani: gyökér (rendszerindító), lapozóállomány, /var és /usr. A /var méretének tükröznie kell a számítógép szándékolt használatát. A /var partíción foglalnak helyet a felhasználók postaládái, a naplóállományok és a nyomtatási sorok. A postaládák és a naplóállományok egészen váratlan mértékben is képesek megnövekedni attól függõen, hogy mennyi felhasználónk van a rendszerben és hogy mekkora naplókat tartunk meg. Itt a legtöbb felhasználónak soha nem lesz szüksége egy gigabyte-nál több helyre. Bizonyos esetekben a /var/tmp könyvtárban azért ennél több tárterület szükségeltetik. Amikor a &man.pkg.add.1; segítségével egy friss szoftvert telepítünk a rendszerünkre, akkor a program a /var/tmp könyvtárba tömöríti ki a hozzátartozó csomag tartalmát. Ezért a nagyobb szoftvercsomagok, mint például a Firefox vagy az OpenOffice esetén gondok merülhetnek fel, ha nem rendelkezünk elegendõ szabad területtel a /var/tmp könyvtárban. A /usr partíció tartalmaz a rendszer mûködéséhez elengedhetetlenül számos fontos állományt, többek közt a portok gyûjteményét (ajánlott, lásd &man.ports.7;) és a forráskódot (választható). A portok és az alaprendszer forrásai telepítés során választhatóak, de telepítésük esetén akkor ezen a partíción legalább két gigabyte-nyi hely ajánlott. Vegyük figyelembe a tárbeli igényeket, amikor megválasztjuk partíciók méretét. Igen kellemetlen lehet, amikor úgy futunk ki az egyik partíción a szabad helybõl, hogy a másikat alig használjuk. Egyes felhasználók szerint elõfordulhat, hogy a &man.sysinstall.8; Auto-defaults opciója a /var és / partíciók méretét túl kicsire választja. Partícionáljuk okosan és nagylelkûen! A lapozóállomány partíciója a lapozóállomány mérete a lapozóállomány partíciója Általános szabály, hogy a lapozóállományt tároló partíció mérete legyen a rendszer fizikai memóriájának (RAM) kétszerese. Például, ha a számítógépünk 128 megabyte memóriával rendelkezik, akkor a lapozóállomány méretének 256 megabyte-nak kell lennie. Az ennél kevesebb memóriát maguknak tudó rendszerek több lapozóállománnyal jobban teljesítenek. 256 megabyte-nál kevesebb lapozóállományt semmiképpen sem ajánlunk, és inkább a fizikai memóriát érdemes bõvítenünk. A rendszermag virtuális memóriát kezelõ lapozási algoritmusait úgy állították be, hogy abban az esetben teljesítsenek a legjobban, ha a lapozóállomány mérete legalább kétszerese a központi memória mennyiségének. A túl kicsi lapozóállomány beállítása rontja a virtuális memória lapkeresésési rutinjának hatékonyságát és a memória bõvítése esetén még további gondokat is okozhat. A több SCSI-lemezzel (vagy a különbözõ vezérlõkre csatlakoztatott több IDE-lemezzel) bíró nagyobb rendszerek esetében érdemes minden egyes (de legfeljebb négy) meghajtóra beállítani lapozóállományt. A lapozóállományoknak közel azonos méretûnek kell lenniük. A rendszermag tetszõleges méretûeket képes kezelni, azonban a belsejében alkalmazott adatszerkezetek a legnagyobb lapozóállomány méretének négyszereséig képesek növekedni. Ha a lapozóállományokat nagyjából ugyanazon a méreten tartjuk, akkor a rendszermag képes lesz a lapozáshoz felhasznált területet optimálisan elosztani a lemezek között. A nagyobb lapozóállományok használata még akkor is jól jön, ha nem is használjuk annyira. Segítségével sokkal könnyebben talpra tudunk állni egy elszabadult program tombolásából, és nem kell rögtön újraindítanunk a rendszert. Miért partícionáljunk? Egyes felhasználók úgy gondolják, hogy egyetlen nagyobb méretû partíció mindenre megfelel, ám ez a gondolat több okból is helytelennek tekinthetõ. Elõször is, minden egyes partíciónak eltér a mûködési jellemzõje, és különválasztásukkal lehetõvé válik az állományrendszerek megfelelõ behangolása. Például a rendszerindításhoz használt és a /usr partíciókat többségében csak olvasásra használják, és nem sokat írnak rájuk. Eközben a /var és /var/tmp könyvtárakban zajlik az írások és olvasások túlnyomó része. A rendszer megfelelõ felosztásával a kisebb, intenzívebben írt partíciókon megjelenõ töredezettség nem szivárog át a többségében csak olvasásra használt partíciókra. Ha a sokat írt partíciókat közel tartjuk a lemez széléhez, akkor azokon a partíciókon növekszik az I/O teljesítménye, ahol az a leggyakrabban megjelenik. Mivel mostanság az I/O teljesítményére inkább a nagyobb partíciók esetén van szükség, azzal nem érünk el ebben különösebb mértékû növekedést, ha a /var partíciót a lemez szélére toljuk. Befejezésképpen hozzátesszük, hogy ennek vannak biztonsági megfontolásai is. Egy kisebb és takarosabb rendszerindító partíció, ami többnyire írásvédett, nagyobb eséllyel él túl egy csúfos rendszerösszeomlást. A mag beállítása rc állományok rc.conf A rendszer beállításaira vonatkozó információk központi lelõhelye az /etc/rc.conf állomány. Ez az állomány tartalmazza a beállításokra vonatkozó adatok széles körét, amelyet elsõsorban a rendszer indulása során a rendszer beállítására használnak. Erre a neve is utal: ez az rc* állományok konfigurációs állománya. A rendszergazda az rc.conf állományban tudja felülbírálni az /etc/defaults/rc.conf állományban szereplõ alapértelmezett beállításokat. Az alapértelmezéseket tartalmazó állományt nem szabad közvetlenül átmásolni az /etc könyvtárba, hiszen alapértelmezett értékeket tartalmaz, nem pedig mintákat. Minden rendszerfüggõ beállítást magában az rc.conf állományban kell elvégezni. Számos stratégia létezik a tömegesen adminisztrált számítógépeknél a közös és rendszerfüggõ beállítások különválasztására, ezáltal a karbantartási költségek csökkentésére. A közös beállításokat ajánlott egy másik helyre, például az /etc/rc.conf.site állományba rakni, majd hivatkozni erre a kizárólag csak rendszerfüggõ információkat tartalmazó /etc/rc.conf állományból. Mivel az rc.conf állományt az &man.sh.1; dolgozza fel, ezt elég könnyen el tudjuk érni. Például: rc.conf: . /etc/rc.conf.site hostname="node15.example.com" network_interfaces="fxp0 lo0" ifconfig_fxp0="inet 10.1.1.1" rc.conf.site: defaultrouter="10.1.1.254" saver="daemon" blanktime="100" Az rc.conf.site állomány ezt követõen az rsync parancs használatával már szétszórható a rendszerben, miközben az rc.conf állomány mindenkinél egyedi marad. Ha a rendszert a &man.sysinstall.8; vagy a make world használatával frissítjük, akkor az rc.conf tartalma nem íródik felül, így a rendszer beállításairól szóló adatok nem vesznek el. Az alkalmazások beállítása A telepített alkalmazások általában saját konfigurációs állományokkal, amelyek pedig saját formátummal stb. rendelkeznek. Fontos, hogy ezeket az állományokat az alaprendszertõl elkülönítve tároljuk, ezáltal a csomagkezelõ eszközök könnyen rájuk tudjanak találni és dolgozni velük. /usr/local/etc Ezeket az állományokat általában a /usr/local/etc könyvtárban találjuk meg. Amennyiben egy alkalmazáshoz több konfigurációs állomány is tartozik, akkor ahhoz ezen belül egy külön alkönyvtár jön létre. Normális esetben, amikor egy portot vagy csomagot telepítünk, minta konfigurációs állományokat is kapunk. Ezek nevében többnyire a .default utótag szerepel. Ha még nincs konfigurációs állomány az adott alkalmazáshoz, akkor a .default jelzésû állományokból ez létrehozható. Példaképpen most tekintsük a /usr/local/etc/apache könyvtár tartalmát: -rw-r--r-- 1 root wheel 2184 May 20 1998 access.conf -rw-r--r-- 1 root wheel 2184 May 20 1998 access.conf.default -rw-r--r-- 1 root wheel 9555 May 20 1998 httpd.conf -rw-r--r-- 1 root wheel 9555 May 20 1998 httpd.conf.default -rw-r--r-- 1 root wheel 12205 May 20 1998 magic -rw-r--r-- 1 root wheel 12205 May 20 1998 magic.default -rw-r--r-- 1 root wheel 2700 May 20 1998 mime.types -rw-r--r-- 1 root wheel 2700 May 20 1998 mime.types.default -rw-r--r-- 1 root wheel 7980 May 20 1998 srm.conf -rw-r--r-- 1 root wheel 7933 May 20 1998 srm.conf.default Az állományok mérete jól mutatja, hogy csak az srm.conf változott meg. Az Apache késõbbi frissítései ezt az állományt nem fogják felülírni. Tom Rhodes Írta: Szolgáltatások indítása szolgáltatások A felhasználók közül sokan választják a &os; Portgyûjteményében található külsõ szoftverek telepítését. A telepített szoftvert gyakran ilyenkor úgy kell beállítani, hogy a rendszer indulásával együtt induljon. Az olyan szolgáltatások, mint például a mail/postfix vagy a www/apache13 csupán két olyan szoftvercsomag, amelyet a rendszerrel együtt kell elindítani. Ebben a szakaszban a külsõ szoftverek indítására használatos eljárásokkal foglalkozunk. A &os;-ben megjelenõ legtöbb szolgáltatás, mint például a &man.cron.8;, a rendszerindító szkripteken keresztül kel életre. Habár ezek a szkriptek a &os; egyes verziói vagy az egyes gyártók esetén különbözhetnek, azonban az mindegyikükben közös, hogy az elindításukra vonatkozó beállítások egyszerû indítószkriptekkel adhatóak meg. - Az rc.d eljövetele elõtt az - alkalmazások indításához be kellett - másolni egy egyszerû indítószkriptet a - /usr/local/etc/rc.d - könyvtárba, melyet aztán a rendszer - indításához használt szkriptek - olvastak be. Ezek a szkriptek aztán késõbb a - rendszer indítása során - végrehajtódtak. - - Miközben rengetegen próbálták - beolvasztani ezt a megszokott konfigurációs - stílust egy új rendszerbe, a külsõ - alkalmazások mûködtetéséhez - továbbra is az elõbb említett - könyvtárban elhelyezett szkriptekre van - szükség. A szkriptek közötti apró - eltérések leginkább abban nyilvánulnak - meg, hogy az rc.d könyvtárat - használják-e vagy sem. A &os; 5.1-es - verziója elõtt a régebbi - konfigurációs megoldást - használták, de az új szkriptek szinte az - összes esetben megfelelõnek bizonyultak. - - Jóllehet minden szkriptnek teljesítenie kell - minimális elvárásokat, ezek a legtöbb - esetben függetlenek a &os; konkrét - verziójától. Minden szkriptnek a rendszer - által végrehajthatónak kell lennie. Ezt - úgy érhetjük el, ha a chmod - parancs felhasználásával - beállítjuk a 555 - kódú engedélyeket. Ezen felül a - szkriptnek még tudnia kell kezelnie a - start és stop - paramétereket. - - A legegyszerûbb indítószkript valahogy - így nézhet ki: - - #!/bin/sh -echo -n ' utility' - -case "$1" in -start) - /usr/local/bin/utility - ;; -stop) - kill -9 `cat /var/run/utility.pid` - ;; -*) - echo "Usage: `basename $0` {start|stop}" >&2 - exit 64 - ;; -esac - -exit 0 - - Ez a szkript képes értelmezni a - start és stop - parancsokat az alkalmazás számára, ami itt - egyszerûen csak a utility nevet - kapta. - - Manuálisan így tudjuk elindítani: - - &prompt.root; /usr/local/etc/rc.d/utility start - - Habár nem mindegyik külsõ szoftvert kell - külön megadni az rc.conf - állományban, majdnem minden nap - módosítani kell egy portot a - beállítások elfogadásához. Az - egyes alkalmazásokra vonatkozó - kiegészítõ információkhoz - nézzük meg a telepítés után - keletkezõ üzeneteket. Egyes külsõ - szoftverekhez mellékelnek olyan - indítószkripteket, amelyek lehetõvé - teszik az alkalmazás meghívását az - rc.d - könyvtárból. Ezekrõl a - következõ szakaszban még szólni - fogunk. - Az alkalmazások részletesebb beállítása Most miután a &os; rendelkezik egy rc.d könyvtárral, az alkalmazások indításának beállítása is könnyebbé és ügyesebbé vált. Az rc.d mûködésérõl szóló szakaszban megismert kulcsszavak segítségével az alkalmazások mostantól kezdve a többi szolgáltatás, például a DNS után indulnak el, és az rc.conf állományon keresztül a szkriptekbe huzalozottak helyett most már tetszõleges paramétereket is átadhatunk stb. Egy egyszerû szkript ehhez hasonlóan néz ki: #!/bin/sh # # PROVIDE: utility # REQUIRE: DAEMON # KEYWORD: shutdown -# -# NE VÁLTOZTASSUK MEG AZ ITT LÉVÕ ALAPÉRTELMEZÉSEKET, -# INKÁBB AZ /etc/rc.conf ÁLLOMÁNYBAN ÁLLÍTSUK BE EZEKET -# -utility_enable=${utility_enable-"NO"} -utility_flags=${utility_flags-""} -utility_pidfile=${utility_pidfile-"/var/run/utility.pid"} - . /etc/rc.subr name="utility" rcvar=`set_rcvar` command="/usr/local/sbin/utility" load_rc_config $name -pidfile="${utility_pidfile}" +# +# NE VÁLTOZTASSUK MEG AZ ITT LÉVÕ ALAPÉRTELMEZÉSEKET, +# INKÁBB AZ /etc/rc.conf ÁLLOMÁNYBAN ÁLLÍTSUK BE EZEKET +# +utility_enable=${utility_enable-"NO"} +utility_pidfile=${utility_pidfile-"/var/run/utility.pid"} -start_cmd="echo \"Starting ${name}.\"; /usr/bin/nice -5 ${command} ${utility_flags} ${command_args}" +pidfile="${utility_pidfile}" run_rc_command "$1" Ez a szkript gondoskodik arról, hogy a utility nevû alkalmazás a - daemon szolgáltatás után + DAEMON szolgáltatás után induljon el. Emellett még felkínál egy módszert a PID avagy futó programok azonosítójának beállítására és nyomonkövetésére is. Ezt követõen az /etc/rc.conf állományból az alkalmazás elindítható az alábbi sor hozzáadásával: utility_enable="YES" Ez a módszer megkönnyíti a paranccsorban átadott paraméterek módosítását, az /etc/rc.subr állományban szereplõ alapértelmezett függvények használatát, az &man.rcorder.8; segédprogrammal szembeni kompatibilitást és az rc.conf állomány könnyebb beállítását. - Szolgáltatások indítása szolgáltatásokkal Más szolgáltatások, mint például a POP3 vagy IMAP szerverek démonai stb. az &man.inetd.8; segítségével indíthatóak el. Ez a Portgyûjteménybõl telepített szolgáltatások esetén magával vonja az adott segédprogram felvételét vagy a hozzátartozó sor engedélyezését az /etc/inetd.conf állományban. Az inetd mûködésével és annak beállításával mélyrehatóbban az inetd szakasza foglalkozik. A legtöbb esetben a &man.cron.8; démon használata kézenfekvõ a rendszerszintû szolgáltatások elindításában. Ez a megközelítés számos elõnyt tartogat, mivel a cron ezeket a programokat a felhasználó crontab állománya alapján futtatja. Ezzel a mezei felhasználók számára is lehetõvé válik, hogy elindítsanak és karbantsanak alkalmazásokat. A cron segédprogramnak van egy olyan speciális lehetõsége, hogy az idõ helyett a @reboot értéket adhatjuk meg. Ennek hatására a feladat a &man.cron.8; indításával együtt fut le, tehát megszokott esetben a rendszer indítása során. Tom Rhodes Írta: A <command>cron</command> segédprogram beállítása cron beállítása A &man.cron.8; a &os; egyik leghasznosabb segédprogramja. A cron segédprogram a háttérben fut és folyamatosan figyeli az /etc/crontab állományt. Emellett a cron új crontab állományok után kutatva folyamatosan ellenõrzi a /var/cron/tabs könyvtárat. Ezek a crontab állományok olyan feladatokról tárolnak adatokat, amelyeket a cron programnak egy adott pillanatban el kell végeznie. A cron a konfigurációs állományok két külön fajtáját, a rendszer- és felhasználói crontabokat használja. A két típus között levõ egyetlen különbség a hatodik mezõben található. A rendszerszintû crontabok esetében a hatodik mezõ annak a felhasználónak a nevét tartalmazza, amivel a program fut. Ezzel a rendszer szintjén mûködõ crontaboknak megadatott az a képesség, hogy tetszõleges felhasználó nevében futtassanak programokat. A felhasználók crontabjaiban a hatodik mezõ a futtatandó parancsot tartalmazza, és ilyenkor az összes parancs a crontabot létrehozó felhasználó nevében hajtódik végre. Ez utóbbi egy fontos biztonsági jellemzõ. A felhasználói crontabok lehetõvé teszik az egyes felhasználók számára, hogy a root felhasználó jogosultságai nélkül képesek legyenek feladatokat ütemezni, ugyanis a felhasználóhoz tartozó crontabban szereplõ parancsok mindegyike a tulajdonosának engedélyeivel fut. Az átlagos felhasználókhoz hasonlóan a root felhasználónak is lehet crontabja, ami nem ugyanazt, mint az /etc/crontab (a rendszer saját crontab állománya). De mivel a rendszernek külön crontabja van, ezért a root felhasználónak nem kell külön crontabot létrehozni. Vessünk egy pillanatást az /etc/crontab (a rendszer crontabjának) tartalmára: # /etc/crontab - a root crontabja &os; alatt # # $&os;: src/etc/crontab,v 1.32 2002/11/22 16:13:39 tom Exp $ # # SHELL=/bin/sh PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin HOME=/var/log # # #minute hour day month wday who command # # */5 * * * * root /usr/libexec/atrun A &os; legtöbb konfigurációs állományához hasonlóan itt is a # jelöli a megjegyzéseket. Az ilyen megjegyzések remekül használhatóak annak feljegyzésére, hogy mit és miért akarunk futtatni. A megjegyzések azonban nem szerepelhetnek a paranccsal egy sorban, mivel máskülönben a parancs részeként kerülnek értelmezésre. Tehát mindig új sorba kell raknunk ezeket. Az üres sorokat a program nem veszi figyelembe. Elõször is meg kell adnunk egy környezetet. Az egyenlõség (=) karakter használatos a környezeti beállítások meghatározására, ahogy mindezt az itteni példában is tapasztalhatjuk a SHELL, PATH és HOME értékek esetében. Ha nem adunk meg mást, akkor a cron az alapértelmezés szerinti sh parancsértelmezõt használja. Ha nem adjuk meg a PATH változó értékét, akkor minden állományra abszolút elérési úttal kell hivatkoznunk, mivel ennek nincs alapértelmezett értéke. Ha nem definiáljuk a HOME változó értékét, akkor a cron a parancshoz tartozó felhasználó könyvtárából fog dolgozni. Ez a sor írja le a megadható hét mezõt. Az itt szereplõ értékek a minute (perc), hour (óra), mday (a hónap napja), month (hónap), wday (a hét napja), who (ki) és command (mit). A mezõk szinte maguktól értetõdnek. A minute egy órán belül adja meg azokat a perceket, amikor az adott parancsot le kell futtatni. A hour hasonló a minute beállításhoz, csak az itt szereplõ értékét órákban kell értelmezni. Az mday a hónap napjaiban számol. A month hasonló a minute és hour opciókhoz, de ez hónapot jelöl. A wday a hét egy napját jelzi. Ezeknek a mezõknek numerikus, valamint a huszonnégy órás idõformátumnak megfelelõ értékeket kell tartalmazniuk. A who mezõ, a többiektõl eltérõ módon, csak az /etc/crontab állományban jelenik meg. Ez a mezõ adja meg, hogy a parancsot milyen felhasználóval kell futtatni. Ez az opció nem jelenik meg a felhasználók saját crontab állományainak telepítésekor. A sor végén láthatjuk még a command oszlopot is. Ez az utolsó mezõ, és ide kerül a végrehajtandó parancs. Ez az utolsó sor a fentebb tárgyalt értékeket határozza meg. Észrevehetjük, hogy a sor egy */5 alakú felírással kezdõdik, amelyet további * karakterek követnek. A * karakterek jelentése elsõ-utolsó, ami arra utal, hogy mindig. Ennek megfelelõen úgy értelmezhetjük ezt a sort, hogy a root felhasználóval le kell futtatni az atrun parancsot minden ötödik percben, függetlenül attól, hogy milyen nap vagy hónap van. Az atrun parancsról részletesebban az &man.atrun.8; man oldalán kapunk felvilágosítást. Az itt szereplõ parancsoknak tetszõleges mennyiségû paraméter átadható, azonban a több soron keresztül átívelõ parancsok tördelését a sor végén a \ karakterrel kell jelezni. Ez mindegyik crontab állomány alapbeállítása, habár ettõl általában egy dologban eltérnek. A hatodik mezõ, ahol a felhasználót adtuk meg, csak a rendszer /etc/crontab állományában jelenik meg. Ez a mezõ a felhasználók crontab állományaiból kimarad. Egy crontab telepítése Nem kötelezõ az itt ismertetésre kerülõ módon szerkeszteni vagy telepíteni a rendszer crontabját. Egyszerûen nyissuk meg a kedvenc szövegszerkesztõnkkel és a cron segédprogram majd észreveszi, hogy az állomány megváltozott, majd ennek megfelelõen neki is lát a módosított változat használatának. Errõl a GYIK-ban (angolul) többet is megtudhatunk. Egy frissen készített felhasználói crontab telepítéséhez elõször a kedvenc szövegszerkesztõnk segítségével létre kell hoznunk a megfelelõ formátumú állományt, majd használnunk a crontab segédprogramot. Ennek általános alakja: &prompt.user; crontab crontab_állomány Ebben a példában a crontab_állomány a korábban létrehozott crontab neve lesz. Lehetõségünk van lekérdezni a telepített crontab állományokat: egyszerûen adjuk át a kapcsolót a crontab parancsnak és nézzük meg mit ad vissza. A crontab -e használata olyan felhasználók számára ajánlott, akik sablon alkalmazása nélkül szeretnének teljesen maguktól megírni egy crontab állományt. Ennek hatására a kiválasztott szövegszerkesztõ egy üres állományt kap. Miután ezt az állományt elmentettük, a crontab programmal magától telepítésre kerül. Ha a késõbbiekben törölni akarjuk a felhasználónkhoz tartozó crontab állományt, akkor erre a célra használjuk a crontab kapcsolóját. Tom Rhodes Írta: Az rc használata &os; alatt A rendszer indítására a &os; 2002-ben átvette a NetBSD rc.d rendszerét. Ezt a felhasználók könnyen felismerhetik a /etc/rc.d könyvtárban található állományokról. A legtöbbjük olyan alapvetõ szolgáltatások, amelyeket a , és paraméterekkel lehet vezérelni. Például az &man.sshd.8; az alábbi paranccsal indítható újra: &prompt.root; /etc/rc.d/sshd restart Ez az eljárás hasonló a többi szolgáltatás esetén is. Természetesen ezek a szolgáltatások általában maguktól indulnak el a rendszer indítása során az &man.rc.conf.5; állományban megadott szerint. Például ha a rendszerünk indulásakor szeretnénk aktiválni a hálózati címfordítással foglalatoskodó démont, akkor csak adjuk hozzá az /etc/rc.conf állományhoz a következõ sort: natd_enable="YES" Amennyiben a sor már szerepel benne, akkor egyszerûen írjuk át a értéket -re. Ezután az rc szkriptek a a rendszer következõ indításakor a lentieknek megfelelõen automatikusan elindítják a hozzátartozó szolgáltatásokat is. Mivel az rc.d rendszert elsõsorban arra használják, hogy szolgáltatásokat indítsanak el vagy állítsanak le az operációs rendszerrel együtt, a szabványos , és paraméterek csak abban az esetben látják a feladatukat, ha a nekik megfelelõ változókat beállítottuk az /etc/rc.conf állományban. Tehát például a sshd restart csak abban az esetben fog bármit is csinálni, ha az /etc/rc.conf állományban az sshd_enable változót a értékre állítottuk. Ha az /etc/rc.conf beállításaitól függetlenül kívánunk egy szolgáltatásnak , vagy parancsot adni, akkor elé kell tennünk egy one szót. Például ha az sshd szolgáltatás újraindításához az /etc/rc.conf tartalmát figyelmen kívül akarjuk hagyni, akkor ezt a parancsot kell kiadnunk: &prompt.root; /etc/rc.d/sshd onerestart Könnyen le tudjuk ellenõrizni, hogy az adott szolgáltatás az /etc/rc.conf részérõl engedélyezett-e, ha a neki megfelelõ rc.d szkriptnek megadjuk az paramétert. Ennek segítségével például a rendszergazda így képes ellenõrizni, hogy a sshd szolgáltatást engedélyezi-e az /etc/rc.conf: &prompt.root; /etc/rc.d/sshd rcvar # sshd $sshd_enable=YES A második sor (# sshd) az sshd parancs kimenete, nem pedig a root parancssora. A paraméterrel kideríthetjük, hogy egy szolgáltatás aktív-e. Ezzel például így tudjuk ellenõrizni a sshd szolgáltatás mûködését: &prompt.root; /etc/rc.d/sshd status sshd is running as pid 433. Az üzenet: Az sshd a 433-as azonosítóval fut. Bizonyos esetekben a paraméter használatával lehetõségünk a szolgáltatások újraindítására is. Ilyenkor a rendszer megpróbál egy olyan jelzést küldeni a szolgáltatásnak, amivel a konfigurációs állományainak újraolvasását kéri. A legtöbbször lényegében ez a SIGHUP jelzést kiküldését rejti magában. Ez a lehetõség azonban nem mindegyik szolgáltatás esetén érhetõ el. Az rc.d rendszer nem csupán hálózati szolgáltatások esetén használatos, hanem nagyrészben hozzájárul a rendszer indításához is. Erre vegyük példának a bgfsck állományt. Amikor ez a szkript lefut, a következõ üzenetet jeleníti meg: Starting background file system checks in 60 seconds. Az üzenet fordítása: A háttérben 60 másodperc múlva megkezdõdik az állományrendszerek ellenõrzése. Ennek megfelelõen tehát ezt az állományt az állományrendszerek háttérben folyó ellenõrzésére használják, ami pedig a rendszer indítása során fut le. Számos rendszerszolgáltatás igényel a mûködéséhez további szolgáltatásokat. Például a NIS és más egyéb távoli eljáráshíváson alapú szolgáltatások egészen addig nem képesek elindulni, amíg az rpcbind (portmapper) szolgáltatást el nem indítjuk. Az ilyen jellegû gondok feloldására az indítószkriptek elején levõ megjegyzésekben található egy kevés metainformáció a szkript mûködéséhez szükséges elemekre (függõségeire) vonatkozóan. A rendszer indítása közben az &man.rcorder.8; nevû program képes a megjegyzések közt ezeket az információkat feldolgozni és ebbõl megállapítani, hogy a függõségi viszonyok betartásával milyen sorrendben kell elindítani a rendszer által felkínált szolgáltatásokat. Ehhez a következõ kulcsszavakat kell megadni az egyes indító szkriptek elején (az &man.rc.subr.8; így tudja engedélyezni az indító szkriptet): PROVIDE: segítségével megmondjuk, hogy ez az állomány milyen szolgáltatásokat nyújt. A következõ kulcsszavak az egyes indítóállományok elején szerepelhetnek. Nem kell feltétlenül használnunk ezeket, de velük az &man.rcorder.8; munkáját segíthetjük: REQUIRE: felsoroljuk azokat a szolgáltatásokat, amelyek a futásához kellenek. Az állomány tehát az itt megadott szolgáltatások után fog lefutni. BEFORE: felsoroljuk azokat a szolgáltatásokat, amelyek elõtt futtatni kell ezt az állományt. Az indító szkriptekben a kulcsszavak ügyes megválasztásával a rendszergazda nagyon finoman képes az indításkor végrehajtódó szkriptek sorrendjét szabályozni és a többi &unix; alapú operációs rendszerbõl ismert futtatási szintek használata nélkül vezérlelni a rendszerben megjelenõ szolgáltatásokat. Az rc.d rendszerrõl bõvebben az &man.rc.8; és &man.rc.subr.8; man oldalakon olvashatunk. Ha szeretnénk saját rc.d szkripteket írni vagy javítani a már meglevõeken, akkor ez a cikk (angolul) segítségünkre lehet. Marc Fonvieille Írta: A hálózati kártyák beállítása hálózati kártyák beállítása Manapság már el sem tudunk képzelni számítógépet hálózati csatlakozás nélkül. A hálózati csatolókártyák hozzáadása és beállítása egy &os; rendszergazda mindennapos feladata. A megfelelõ meghajtóprogram felderítése hálózati kártyák meghajtó Mielõtt bárminek is nekikezdenénk, érdemes tisztában lennünk azzal, hogy a rendelkezésünkre álló kártya milyen típusú, milyen chipet használ és hogy PCI vagy ISA buszon csatlakozik-e. A &os; a PCI és ISA csatolós kártyák széles spektrumát ismeri. Az egyes kiadásokhoz mellékelt Hardware Compatibility List (Hardverkompatibilitási lista) dokumentumokban tudjuk ellenõrizni, hogy a kártyákat ismeri a rendszer. Miután meggyõzõdtünk róla, hogy a kártyánkat ismeri a rendszer, meg kell keresnünk a hozzátartozó meghajtót. A /usr/src/sys/conf/NOTES és a /usr/src/sys/arch/conf/NOTES állományok tartalmazzák a hálózati kártyák meghajtóinak rövid leírását, benne a támogatott chipsetek és kártyák típusaival. Ha ez alapján nem tudjuk teljes biztosággal eldönteni, hogy melyik a számunkra megfelelõ meghajtó, nézzük meg a saját man oldalát. Ezen a man oldalon megtaláljuk az által ismert összes eszközt és velük kapcsolatban elõforduló jellemzõ problémákat. Ha egy elterjedt típust sikerült beszereznünk, akkor nem kell különösebben sokáig keresnünk a neki megfelelõ meghajtót. Az ismertebb hálózati kártyák meghajtói ugyanis alapból benne vannak a GENERIC rendszermagban, ezért a rendszer indítása során ehhez hasonlóan meg is jelennek a kártyák: dc0: <82c169 PNIC 10/100BaseTX> port 0xa000-0xa0ff mem 0xd3800000-0xd38 000ff irq 15 at device 11.0 on pci0 dc0: Ethernet address: 00:a0:cc:da:da:da miibus0: <MII bus> on dc0 ukphy0: <Generic IEEE 802.3u media interface> on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc1: <82c169 PNIC 10/100BaseTX> port 0x9800-0x98ff mem 0xd3000000-0xd30 000ff irq 11 at device 12.0 on pci0 dc1: Ethernet address: 00:a0:cc:da:da:db miibus1: <MII bus> on dc1 ukphy1: <Generic IEEE 802.3u media interface> on miibus1 ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto Ebben a példában láthatunk is két olyan kártyát, amelyek a &man.dc.4; meghajtót használják. Ha a hálózati kártyánk meghajtója nem szerepel a GENERIC konfigurációban, akkor a mûködéséhez be kell tölteni a megfelelõ meghajtót. Ezt alapvetõen kétféleképpen érhetjük el: Ennek legegyszerûbb módja, ha a &man.kldload.8; használatával alkalmanként vagy a /boot/loader.conf állományban a megfelelõ sor hozzáadásával a rendszer indításával együtt betöltjük a hálózati kártya meghajtójához tartozó modult. Nem mindegyik hálózati kártya meghajtója érhetõ el modul formájában. Erre konkrét például szolgálnak az ISA kártyákhoz tartozó modulok. Másik lehetõségünk, ha statikusan beépítjük a kártyánk támogatását a rendszermagba. A /usr/src/sys/conf/NOTES és az /usr/src/sys/arch/conf/NOTES állományok, valamint a meghajtóhoz tartozó man oldal elolvasásából megtudhatjuk a rendszermag beállításait tartalmazó állományban megadandó paramétereket. A rendszermag újrafordítását lásd . Ha a rendszermag (GENERIC) az indulás során észlelte a kártyánkat, nem kell újat készítenünk. A &windows; NDIS meghajtóinak használata NDIS NDISulator &windows; meghajtók Microsoft Windows Microsoft Windows eszközmeghajtók KLD (a rendszermag betölthetõ objektuma) Sajnos még mindig sok olyan gyártó akad, akik a nyílt forrású közösség számára nem adják ki a meghajtóik mûködésének alapjait, mivel az ilyen adatokat szakmai titkoknak tekintik. Ebbõl következik, hogy a &os; és más operációs rendszerek fejlesztõi számára két választás marad: vagy a gyári meghajtók visszafejtésének hosszú és fájdalmas útján haladva fejlesztik ki a saját meghajtójukat, vagy pedig a µsoft.windows; platformra kiadott meghajtók binárisait hasznosítják. A legtöbb fejlesztõ, köztük a &os; fejlesztõi is, ez utóbbi megközelítést választották. Bill Paul (wpaul) jóvoltából a &os; 5.3-RELEASE változatában megjelent a Network Driver Interface Specification (NDIS, avagy hálózati meghajtók szabványos felülete) natív támogatása. A &os; NDISulator (másnéven Project Evil, a Gonosz terve) nevû komponense fog egy &windows;-os meghajtót és elhiteti vele, hogy a &windows;-szal kommunikál. Mivel az &man.ndis.4; meghajtó &windows; binárisokat használ fel, ezért csak &arch.i386; és &arch.amd64; rendszerek esetén érhetõ el. Az &man.ndis.4; meghajtó leginkább a PCI, CardBus és PCMCIA csatolójú eszközök támogatására lett kitalálva, az USB eszközöket még nem ismeri. Az NDISulator használatához három tényezõre van szükségünk: A rendszermag forrása a &windowsxp; meghajtó binárisa (.SYS a kiterjesztése) a &windowsxp; meghajtó konfigurációs állománya (.INF a kiterjesztése) Keressük meg az említett állományokat az adott kártyához. Ezeket általában a mellékelt CD-n vagy a gyártó honlapján találjuk meg. A most következõ példákban a W32DRIVER.SYS és a W32DRIVER.INF neveket fogjuk használni. A &windows; i386 architektúrájú verziójához készült meghajtóprogramokat nem tudjuk a &os;/amd64 verziójával használni. A mûködéshez amd64-re készült &windows;-os meghajtókra van szükség. A következõ lépés a meghajtó binárisainak betölthetõ modulba fordítása. Ennek eléréséhez használjuk az &man.ndisgen.8; parancsot a root felhasználóval: &prompt.root; ndisgen /windowszos/meghajtó/W32DRIVER.INF /windowsos/meghajtó/W32DRIVER.SYS Az &man.ndisgen.8; egy interaktív segédprogram, amely mûködése közben még rákérdez néhány szükséges információra. Az aktuális könyvtárban létrehoz egy rendszermagmodult, amelyet az alábbi módon tudunk betölteni: &prompt.root; kldload ./W32DRIVER.ko Az elõállított modul mellé be kell töltenünk még az ndis.ko és az if_ndis.ko modulokat is. Ez általában minden olyan modul esetén megtörténik magától, amely függ az &man.ndis.4; használatától. Kézileg az következõ parancsokkal tudjuk ezeket betölteni: &prompt.root; kldload ndis &prompt.root; kldload if_ndis Itt az elsõ parancs betölti az NDIS miniport meghajtó burkolására szánt kódot, valamint a második a tényleges hálózati csatolófelületet. Most pedig a &man.dmesg.8; kimenetében ellenõrizzük, hogy történt-e valamilyen hiba a betöltés során. Ha minden jól ment, akkor az alábbiakhoz hasonló kimenetet produkált: ndis0: <Wireless-G PCI Adapter> mem 0xf4100000-0xf4101fff irq 3 at device 8.0 on pci1 ndis0: NDIS API version: 5.0 ndis0: Ethernet address: 0a:b1:2c:d3:4e:f5 ndis0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps ndis0: 11g rates: 6Mbps 9Mbps 12Mbps 18Mbps 36Mbps 48Mbps 54Mbps Innentõl kezdve az ndis0 nevû eszközt úgy tudjuk használni, mint bármelyik más hálózati felületet (például dc0). A többi modulhoz hasonló módon be tudjuk állítani, hogy a rendszer indulásával együtt betöltõdjenek az NDIS modulok. Ehhez elõször másoljuk az imént létrehozott modult, az W32DRIVER.ko állományt a /boot/modules könyvtárba. Ezután adjuk hozzá a következõ sort a /boot/loader.conf állomány tartalmához: W32DRIVER_load="YES" A hálózati kártya beállítása hálózati kártyák beállítása Ahogy betöltõdött a megfelelõ meghajtó a hálózati kártyánkhoz, be is kell állítanunk a kártyát. A hálózati kártyák sok más dologgal együtt beállíthatóak a telepítés során a sysinstall segítségével. A rendszerünkben beállított hálózati csatolófelületek megjelenítéséhez gépeljük be a következõ parancsot: &prompt.user; ifconfig dc0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet 192.168.1.3 netmask 0xffffff00 broadcast 192.168.1.255 ether 00:a0:cc:da:da:da media: Ethernet autoselect (100baseTX <full-duplex>) status: active dc1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255 ether 00:a0:cc:da:da:db media: Ethernet 10baseT/UTP status: no carrier lp0: flags=8810<POINTOPOINT,SIMPLEX,MULTICAST> mtu 1500 lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 inet 127.0.0.1 netmask 0xff000000 tun0: flags=8010<POINTOPOINT,MULTICAST> mtu 1500 A &os; korábbi változatainál az &man.ifconfig.8; parancsnak ehhez még meg kell adni az kapcsolót is. Az &man.ifconfig.8; érvényes paraméterezésével kapcsolatban legyünk szívesek elolvasni a hozzátartozó man oldalt. Hozzátennénk, hogy IPv6 (inet6 stb.) típusú bejegyzések nem szerepelnek a példában. Az elõbbi parancs kimenetében a következõ eszközök jelentek meg: dc0: az elsõ Ethernet felület dc1: a második Ethernet felület lp0: a párhuzamos port felülete lo0: a loopback eszköz tun0: a ppp által használt tunnelhez tartozó eszköz A &os; a kártyához tartozó meghajtó nevével és egy sorszámmal azonosítja a rendszermag indulása során talált eszközöket. Például az sis2 a rendszerben található harmadik olyan eszköz, amely a &man.sis.4; meghajtót használja. A példában a dc0 eszköz aktív és mûködõképes. Ennek legfontosabb jelei: Az UP szó mutatja, hogy a kártyát sikerült beállítani és készen áll a használatra. A kártya internet (inet) címe (jelen esetünkben ez 192.168.1.3). Érvényes hálózati maszkkal rendelkezik (netmask, ahol a 0xffffff00 a 255.255.255.0 címnek felel meg). Érvényes broadcast (üzenetszóró) címmel rendelkezik (ami itt most 192.168.1.255). A kártya MAC-címe (ether) 00:a0:cc:da:da:da. A hozzátartozó fizikai eszköz kiválasztása automatikus (media: Ethernet autoselect (100baseTX <full-duplex>)). Láthatjuk, hogy a dc1 eszközt egy 10baseT/UTP típusú fizikai eszközhöz állítottuk be. Az egyes meghajtókhoz tartozó fizikai módokról a nekik megfelelõ man oldalakon olvashatunk. A kapcsolat állapota (status) active értékû, tehát van vonal. A dc1 esetén láthatjuk, hogy a status: no carrier (nincs vonal). Ez teljesen normálisnak tekinthetõ minden olyan esetben, amikor a kártyába még nem dugtunk Ethernet-kábelt. Amennyiben az &man.ifconfig.8; kimenete valami ilyesmi: dc0: flags=8843<BROADCAST,SIMPLEX,MULTICAST> mtu 1500 ether 00:a0:cc:da:da:da akkor az arra utal, hogy a kártyát nem állítottuk be. A kártya beállításához a root felhasználó jogosultságaira van szükségünk. A hálózati kártyák beállítása az &man.ifconfig.8; segítségével elvégezhetõ parancssorból is, de a gép újraindításakor az így megadott értékek elvesznek. Ezért az /etc/rc.conf állományba kell felvennünk a hálózati kártyák érvényes beállításait. A kedvenc szövegszerkesztõnkben nyissuk meg az /etc/rc.conf állományt. Minden egyes hálózati csatolóhoz fel kell vennünk benne egy sort, ennek megfelelõen most a példához tartozó módon az alábbiakat: ifconfig_dc0="inet 192.168.1.3 netmask 255.255.255.0" ifconfig_dc1="inet 10.0.0.1 netmask 255.255.255.0 media 10baseT/UTP" A dc0 és dc1 neveket kell a rendszerünkben ténylegesen megtalálható eszközök neveire kicserélni, valamint megadni a nekik megfelelõ címeket. A kártya meghajtójának és az &man.ifconfig.8; man oldalának elolvasásával kideríthetjük az itt megadható további beállításokat, valamint az &man.rc.conf.5; man oldalán részletesebben megismerhetjük az /etc/rc.conf formai követelményeit. Ha a telepítés során beállítottuk volna a hálózati kapcsolatokat, akkor tapasztalhatjuk, hogy egyes hálózati kártyák sorai itt már szerepelnek. Ellenõrizzük le az /etc/rc.conf tartalmát mielõtt bõvítenénk! Mindezek mellett az /etc/hosts állományba is be kell írnunk a helyi hálózatunkon található különféle gépek neveit és IP-címeit, ha még nem szerepelnének ott. Errõl további részleteket a &man.hosts.5; man oldalról és az /usr/share/examples/etc/hosts állományból tudhatunk meg. Tesztelés és hibaelhárítás Miután az /etc/rc.conf állományban elvégeztük a szükséges változtatásokat, érdemes újraindítanunk a rendszerünket. Ennek révén érvényesítjük a csatolófelületekkel kapcsolatos változtatásainkat és ellenõrizzük, hogy így a rendszer mindenféle hibaüzenet nélkül képes elindulni. Ahogy a rendszerünk mûködõképessé vált, ki is tudjuk próbálni a hálózati felületeket. Az Ethernet kártyák tesztelése hálózati kártyák tesztelése Az Ethernet kártyák helyes beállításának vizsgálatához két dolgot kell kipróbálnunk. Elõször is pingeljük magát a felületet, majd ezután pingeljünk meg a helyi hálózaton egy másik számítógépet. Elsõként tehát próbáljuk meg a helyi felületet: &prompt.user; ping -c5 192.168.1.3 PING 192.168.1.3 (192.168.1.3): 56 data bytes 64 bytes from 192.168.1.3: icmp_seq=0 ttl=64 time=0.082 ms 64 bytes from 192.168.1.3: icmp_seq=1 ttl=64 time=0.074 ms 64 bytes from 192.168.1.3: icmp_seq=2 ttl=64 time=0.076 ms 64 bytes from 192.168.1.3: icmp_seq=3 ttl=64 time=0.108 ms 64 bytes from 192.168.1.3: icmp_seq=4 ttl=64 time=0.076 ms --- 192.168.1.3 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.074/0.083/0.108/0.013 ms Most pedig pingeljünk meg egy másik számítógépet a helyi hálózaton: &prompt.user; ping -c5 192.168.1.2 PING 192.168.1.2 (192.168.1.2): 56 data bytes 64 bytes from 192.168.1.2: icmp_seq=0 ttl=64 time=0.726 ms 64 bytes from 192.168.1.2: icmp_seq=1 ttl=64 time=0.766 ms 64 bytes from 192.168.1.2: icmp_seq=2 ttl=64 time=0.700 ms 64 bytes from 192.168.1.2: icmp_seq=3 ttl=64 time=0.747 ms 64 bytes from 192.168.1.2: icmp_seq=4 ttl=64 time=0.704 ms --- 192.168.1.2 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.700/0.729/0.766/0.025 ms Ha beállítottuk az /etc/hosts állományt, akkor a 192.168.1.2 helyett a gép nevét is megadhatjuk. A hibák elhárítása hálózati kártyák hibaelhárítása A hardverek és szoftverek beállításaiban mindig is valódi kín megtalálni a hibákat, és ezeket a kínokat többnyire úgy tudjuk enyhíteni, ha elõször az egyszerû hibaforrásokat szûrjük ki. Csatlakoztattuk a hálózati kábelt? Tisztességesen beállítottuk a hálózati szolgáltatásokat? Jól állítottuk be a tûzfalat? A &os; képes kezelni a kártyát? A hibajelentések elküldése elõtt mindig bújjuk át a támogatott hardvereszközök listáját. A &os; verziókat frissítsük a legújabb STABLE változatra. Olvassuk át a levelezési listák archívumait vagy legalább keressünk rá a témára az interneten. Ha a kártya mûködik, de a teljesítménye nem kielégítõ, érdemes ennek utánanézni a &man.tuning.7; man oldalon. Ilyenkor érdemes ellenõrizni a hálózati beállításainkat is, mivel a helytelen beállítások gyakran okoznak teljesítményvesztést. Bizonyos esetekben láthatunk egy vagy két device timeout típusú hibát is, ami a kártyák egyes fajtáinál elfogadható. Ha azonban folyamatosan megjelennek vagy zavaróvá válnak, érdemes utánanéznünk, hogy az eszköz nem ütközik-e valamelyik másikkal. Mindenképpen gyõzödjünk meg a kábelek épségérõl és csatlakoztatásáról. Még az is elképzelhetõ, hogy egyszerûen csak egy másik hálózati kártyára van szükségünk. Néha felbukkanak watchdog timeout jellegû hibák is. Ilyenkor elsõként mindig a hálózati kábelt ellenõrizzük. Egyes kártyáknak olyan PCI foglalatra van szükségük, ami támogatja a Bus Mastering opciót. Néhány régebbi alaplapon csak ilyen PCI bõvítõhely található (ami általában a 0. foglalat). Olvassunk utána a hálózati kártya és az alaplap dokumentációjában, hátha ezek okozzák a problémát. A No route to host üzenet akkor jelenik meg, ha a rendszer képtelen megállapítani, milyen úton jutassa el a csomagokat a megadott célhoz. Ez többnyire olyankor történik meg, amikor nem adtunk meg alapértelmezett kézbesítési irányt (default route) vagy nem dugtuk be a hálózati kábelt. A netstat -rn kimenetébõl meg tudjuk állapítani, hogy létezik-e érvényes út az elérni kívánt cél felé. Ha nincs, akkor haladjunk tovább a re. A ping: sendto: Permission denied jellegû üzeneteket többségében egy helytelenül beállított tûzfal okozza. Ha az ipfw mûködését engedélyeztük a rendszermagban, de nem adtunk meg hozzá szabályokat, akkor az alapértelmezett házirend szerint minden forgalmat blokkolni fog, tehát még a pingeket is! Ezzel kapcsolatban a elolvasását ajánljuk. Elõfordulhat, hogy a kártya teljesítménye igen gyenge vagy az átlagos alatt van. Ilyenkor a fizikai eszköz autoselect (automatikus) típusú kiválasztása helyett érdemes megadnunk a konkrét eszköznek megfelelõ típust. Habár ez a legtöbb hardver esetén beválik, nem mindenki számára jelent megoldást. Ismételten csak annyit tudunk ehhez hozzátenni, hogy ellenõrizzük a hálózati beállításainkat és olvassuk el a &man.tuning.7; man oldalt. Virtuális címek virtuális címek IP-álnevek A &os; alkalmazása során igen gyakori a virtuális címek használata, aminek segítségével egyetlen szerver több szerverként képes látszódni a hálózaton. Ezt úgy érik el, hogy egyetlen felülethez több hálózati címet rendelnek hozzá. Az adott hálózati csatolófelületnek van egy valódi címe és tetszõleges számú álcíme. Ezeket az álcímeket általában az /etc/rc.conf állományban kell feltüntetni. Az fxp0 felület esetén az álcímek megadása valahogy így néz ki: ifconfig_fxp0_alias0="inet xxx.xxx.xxx.xxx netmask xxx.xxx.xxx.xxx" Figyeljük meg, hogy az álcímekhez tartozó bejegyzések az alias0 névvel kezdõdnek és szám szerint növekvõleg következnek egymás után (például, _alias1, _alias2 és így tovább). A beállítás a sorozat elsõ kimaradó tagjánál megszakad. Az álcímek hálózati maszkjának pontos meghatározása nagyon fontos, de szerencsére nem különösebben bonyolult. Minden felület esetén lennie kell egy olyan címnek, ami helyesen reprezentálja a hálózat hálózati maszkját. Minden egyéb olyan címnek, ami ugyanabba az alhálózatba esik, végig 1-esekbõl álló hálózati maszkkal kell rendelkezniük (ami felírható 255.255.255.255 vagy 0xffffffff formájában is). Például vegyük azt, hogy az fxp0 felületen keresztül két hálózathoz csatlakozunk, melyek közül az egyik a 10.1.1.0, amelynek hálózati maszkja 255.255.255.0, és a 202.0.75.16, amelynek hálózati maszkja 255.255.255.240. Azt szeretnénk elérni, hogy a rendszerünk az 10.1.1.1 címtõl az 10.1.1.5 címig, valamint a 202.0.75.17 címtõl a 202.0.75.20 címig jelenjen meg a nekik megfelelõ hálózatokon. Ahogy arra már fentebb is utaltunk, az adott hálózati tartományban csak az elsõ címnek (ebben az esetben ez a 10.0.1.1 és a 202.0.75.17) kell valódi hálózati maszkkal rendelkeznie. Minden további címnek (a 10.1.1.2 és 10.1.1.5 között, valamint a 202.0.75.18 és 202.0.75.20 között) legyen 255.255.255.255 a hálózati maszkja. Az alábbi /etc/rc.conf bejegyzések ennek az elrendezésnek megfelelõen állítják be a kártyát: ifconfig_fxp0="inet 10.1.1.1 netmask 255.255.255.0" ifconfig_fxp0_alias0="inet 10.1.1.2 netmask 255.255.255.255" ifconfig_fxp0_alias1="inet 10.1.1.3 netmask 255.255.255.255" ifconfig_fxp0_alias2="inet 10.1.1.4 netmask 255.255.255.255" ifconfig_fxp0_alias3="inet 10.1.1.5 netmask 255.255.255.255" ifconfig_fxp0_alias4="inet 202.0.75.17 netmask 255.255.255.240" ifconfig_fxp0_alias5="inet 202.0.75.18 netmask 255.255.255.255" ifconfig_fxp0_alias6="inet 202.0.75.19 netmask 255.255.255.255" ifconfig_fxp0_alias7="inet 202.0.75.20 netmask 255.255.255.255" Konfigurációs állományok Az <filename class="directory">/etc</filename> felépítése A beállításokkal kapcsolatos információk számos könyvtárban tárolódnak. Többek közt: /etc Általános rendszerszintû beállítások. Az itt levõ adatok a rendszer egészére vonatkoznak. /etc/defaults A rendszer konfigurációs állományainak alapértelmezett változatait. /etc/mail A &man.sendmail.8; beállításához tartozó további állományok, egyéb levélküldéshez használt adatok. /etc/ppp A felhasználói és rendszermag szintû ppp programok beállításai. /etc/namedb A &man.named.8; mûködéséhez szükséges adatok alapértelmezett helye. Általában a named.conf és a zónák leírását tároló állományok kerülnek ide. /usr/local/etc A telepített alkalmazások konfigurációs állományai. Néha alkalmazásonként külön könyvtárakba kerülnek a benne található állományok. /usr/local/etc/rc.d A telepített alkalmazások indításával és leállításával kapcsolatos szkriptek. /var/db Automatikusan generált rendszerszintû adatbázisok a csomagokkal, a programok helyével stb. kapcsolatosan. Hálózati nevek hálózati név DNS <filename>/etc/resolv.conf</filename> resolv.conf Az /etc/resolv.conf határozza meg, hogy a &os; névfeloldója miként fér hozzá az internet tartománynév rendszeréhez (a DNS-hez). Az resolv.conf állományban leggyakrabban a következõ bejegyzések fordulnak elõ: nameserver Annak a névszernek az IP-címe, ahova a névfeloldó küldi a kéréseit. A névszervereket a felírás sorrendjében kérdezi meg, maximum hármat. search A hálózati nevek keresõlistája. Ezt általában a helyi hálózati nevek tartománya határozza meg. domain A helyi tartomány neve. Egy átlagos resolv.conf tartalma: search example.com nameserver 147.11.1.11 nameserver 147.11.100.30 Csak egy search és domain opciót szabad megadni. A DHCP használatakor a &man.dhclient.8; felül szokta írni a resolv.conf tartalmát a DHCP szervertõl kapott információkkal. <filename>/etc/hosts</filename> hosts Az /etc/hosts az internet kezdeti napjaira emlékeztetõ egyszerû szöveges adatbázis. A nevek és IP-címek közti leképzéseket a DNS és NIS rendszerekkel karöltve oldja fel. Ide a helyi hálózaton csatlakozó számítógépek neveit lehet beírni ahelyett, hogy erre a célra beállítanánk egy külön &man.named.8; szervert. Ezenkívül még az /etc/hosts állományba internetes nevek rekordját is felvehetjük, amivel így csökkenthetjük a gyakran használt nevek feloldására irányuló külsõ kéréseket. # $&os;$ # # # A hálózati nevek adatbázisa # # Ebbe az állományba rakjuk a helyi hálózaton található címeket és # a hozzájuk tartozó hálózati neveket, ahol szinte ugyanez az # adatbázis megtalálható. A 'my.domain' helyére a saját gépünk # nevét írjuk be. # # A DNS vagy NIS alkalmazása esetén ez az állomány nem feltétlenül kerül # felhasználásra. A névfeloldás sorrendjét az /etc/nsswitch.conf # állományban adhatjuk meg. # ::1 localhost localhost.my.domain 127.0.0.1 localhost localhost.my.domain # # Egy képzeletbeli hálózat. #10.0.0.2 myname.my.domain myname #10.0.0.3 myfriend.my.domain myfriend # # Az RFC 1918-nak megfelelõen a következõ IP-címekkel rendelkezõ # alhálózatok sosem csatlakozhatnak közvetlenül az internetre: # # 10.0.0.0 - 10.255.255.255 # 172.16.0.0 - 172.31.255.255 # 192.168.0.0 - 192.168.255.255 # # Amikor csatlakozunk az internethez, egy valódi, hivatalosan # kiosztott számra lesz szükségünk. Ne találjunk ki magunknak # hálózati címeket, hanem használjuk az internetszolgáltatótól # kapott címet (amennyiben rendelkezünk # ilyennel) vagy az # regionális internetes nyilvántartásban szereplõ címek közül # valamelyiket (ARIN, APNIC, LACNIC, RIPE NCC vagy AfriNIC). Az /etc/hosts formai felépítése igen egyszerû: [internetes cím] [hivatalos hálózati név] [álnév1] [álnév2] ... Tehát például: 10.0.0.1 azEnValodiNevem.aHalozaton.hu azEnValodiNevem izemize1 izemize2 A részletekért keressük fel a &man.hosts.5; man oldalt. A naplóállományok beállítása naplóállományok <filename>syslog.conf</filename> syslog.conf A syslog.conf állomány a &man.syslogd.8; program beállításait tartalmazza. Segítségével megadhatjuk, hogy a syslog által generált üzenetek egyes típusait milyen naplóállományokba mentsük. # $&os;$ # # Ebben az állományban HASZNÁLHATÓAK szóközök a mezõk elválasztására, # habár a többi *nix-típusú rendszer inkább tabulátorokat használ # erre a célra. Ha több rendszeren is használni akarjuk ezt az # állományt, akkor ne használjunk szóközöket. # # A többit lásd a syslog.conf(5) man oldalon. # .err;kern.debug;auth.notice;mail.crit /dev/console *.notice;kern.debug;lpr.info;mail.crit;news.err /var/log/messages security.* /var/log/security mail.info /var/log/maillog lpr.info /var/log/lpd-errs cron.* /var/log/cron *.err root *.notice;news.err root *.alert root *.emerg * # Tegyük vissza ezt a sort, ha a /dev/console eszközre kiírt # üzeneteket át akarjuk irányítani az /var/log/console.log állományba. #console.info /var/log/console.log # Ha az összes üzenetet a /var/log/all.log állományba akarjuk menteni, # akkor tegyük vissza ezt a sort. #*.* /var/log/all.log # Ha egy "loghost" nevû gépre szeretnénk naplózni, akkor tegyük vissza # ezt a sort. #*.* @loghost # Az inn használatakor tegyük vissza ezeket a sorokat. # news.crit /var/log/news/news.crit # news.err /var/log/news/news.err # news.notice /var/log/news/news.notice !startslip *.* /var/log/slip.log !ppp *.* /var/log/ppp.log A &man.syslog.conf.5; man oldalának elolvasásával tudhatunk meg többet ezekrõl. <filename>newsyslog.conf</filename> newsyslog.conf A newsyslog.conf a &man.newsyslog.8; beállításait tároló állomány. Ez egy olyan program, ami általában a &man.cron.8; futtat le. A &man.newsyslog.8; dönti el, hogy mikor van szükség a naplók archiválására és átrendezésére. Ennek során a logfile állományból logfile.0 lesz, a logfile.0 állományból pedig logfile.1 és így tovább. Beállíthatjuk úgy is, hogy a naplóállományokat archiválja &man.gzip.1; formátumban, aminek megfelelõen ezek logfile.0.gz, logfile.1.gz és ehhez hasonló névvel jönnek létre. A newsyslog.conf megadja, hogy melyik naplóállományokat kell felügyelni, mennyi példányt tartsunk meg belõlük és mikor kell velük foglalkozni. A naplóállományok átrendezhetõek és/vagy archiválhatóak egy adott méret elérésekor vagy egy adott idõ eltelte után. # A newsyslog konfigurációs állománya # $&os;$ # # állománynév [tulajdonos:csoport] mód darab méret mikor [ZB] [/pid_állomány] [jelzés] /var/log/cron 600 3 100 * Z /var/log/amd.log 644 7 100 * Z /var/log/kerberos.log 644 7 100 * Z /var/log/lpd-errs 644 7 100 * Z /var/log/maillog 644 7 * @T00 Z /var/log/sendmail.st 644 10 * 168 B /var/log/messages 644 5 100 * Z /var/log/all.log 600 7 * @T00 Z /var/log/slip.log 600 3 100 * Z /var/log/ppp.log 600 3 100 * Z /var/log/security 600 10 100 * Z /var/log/wtmp 644 3 * @01T05 B /var/log/daily.log 640 7 * @T00 Z /var/log/weekly.log 640 5 1 $W6D0 Z /var/log/monthly.log 640 12 * $M1D0 Z /var/log/console.log 640 5 100 * Z További információkat a &man.newsyslog.8; man oldaláról nyerhetünk. <filename>sysctl.conf</filename> sysctl.conf sysctl A sysctl.conf állomány leginkább az rc.conf állományhoz hasonlít, benne az értékeket változó=érték párokban adhatjuk meg. Az itt definiált értékek akkor kerülnek ténylegesen beállításra, amikor a rendszer többfelhasználós módba vált. Ezen a módon nem mindegyik változó értékét tudjuk átállítani. A sysctl.conf állományban az alábbi érték beállításával tudjuk beállítani, hogy a rendszer ne naplózza, amikor a programok végzetes jelzéssel fejezõdnek be, valamint azt, hogy a felhasználók láthassák egymás futó programjait: # Ne naplózzuk a végzetes jelzésekhez (például sig 11) tartozó kilépéseket. kern.logsigexit=0 # Ne engedjük a felhasználóknak, hogy lássák egy másik felhasználó # azonosítójával futó programokat. security.bsd.see_other_uids=0 Finomhangolás a sysctl használatával sysctl finomhangolás a sysctl használatával A &man.sysctl.8; egy olyan felület, amely lehetõséget biztosít egy mûködõ &os; rendszer megváltoztatására. Segítségével többek közt hozzáférhetünk a TCP/IP protokollkészlet és a virtuális memóriát kezelõ alrendszer rengeteg apró opciójához, melyek megfelelõ beállításával egy tapasztalt rendszergazda kezében drasztikusan növelhetõ a rendszer teljesítménye. A &man.sysctl.8; alkalmazásával több mint ötszáz rendszerszintû változó kérdezhetõ le és állítható be. A &man.sysctl.8; két funkciót rejt magában: a rendszer beállításainak lekérdezését és módosítását. Így nézhetjük meg az összes lekérdezhetó változót: &prompt.user; sysctl -a Így kérhetjük egy konkrét változó, például a kern.maxproc értékét: &prompt.user; sysctl kern.maxproc kern.maxproc: 1044 Egy adott változó értékének módosításához pedig használjuk a változó=érték felírást: &prompt.root; sysctl kern.maxfiles=5000 kern.maxfiles: 2088 -> 5000 A sysctl változók értékei lehetnek karakterláncok, számok és logikai értékek (ahol az 1 az igennek, a 0 a nemnek felel meg). Ha a számítógép indításakor automatikusan be akarunk állítani bizonyos változókat, akkor vegyük fel ezeket az /etc/sysctl.conf állományba. Ennek pontosabb részleteit a &man.sysctl.conf.5; man oldalon és a ban találhatjuk meg. Tom Rhodes Írta: A &man.sysctl.8; írásvédett értékei Egyes esetekben szükséges lehet a &man.sysctl.8; írásvédett változóinak módosítása. Habár gyakran elengedhetetlen, ezt kizárólag csak a rendszer (újra)indításakor tudjuk megtenni. Például egyes laptopoknál a &man.cardbus.4; eszköz nem próbálkozik több memóriaterület használatával, ezért egy ehhez hasonló hibával leáll: cbb0: Could not map register memory device_probe_and_attach: cbb0 attach returned 12 Az ilyen és ehhez hasonló esetekben gyakran olyan &man.sysctl.8; változók alapértelmezett értékeit kellene megváltoztatnunk, amelyek írásvédettek. Ilyenkor tegyük az érintett &man.sysctl.8; változó objektumazonosítóját (OID) és a hozzátartozó értéket a /boot/loader.conf állományunkba. Az alapértelmezéseket a /boot/defaults/loader.conf állományban találjuk meg. A fentebb tárgyalt probléma megoldásához a felhasználónak a értéket kell beállítania az elõbb említett állományban. Ezután már a &man.cardbus.4; megfelelõen fog mûködni. A lemezek finomhangolása Sysctl változók <varname>vfs.vmiodirenable</varname> vfs.vmiodirenable A vfs.vmiodirenable sysctl változó értéke lehet 0 (ki) vagy 1 (be, és ez az alapértelmezés is). Ez a változó vezérli a könyvtárak gyorsítótárazását a rendszerben. A könyvtárak többsége kis méretû, így az állományrendszerbõl csak egyetlen (általában 1 KB méretû) darabkát használnak és még ennél is kevesebbet (általában 512 byte-ot) a pufferben. A változó kikapcsolt (avagy 0) értéke mellett a puffer csak rögzített számú könyvtárat táraz be még abban az esetben is, amikor temérdek mennyiségû memória áll a rendelkezésére. Ha viszont (az 1 értékkel) engedélyezzük, akkor a rendszer a könyvtárak tárazására felhasználja a virtuális memóriában pufferelt lapokat is, amivel lényegében az összes elérhetõ memóriát a könyvtárak tárazására fordítja. Ilyenkor azonban az egyes könyvtárak tárazására használt legkisebb memóriaterület a fizikai lapmérettel egyezik meg (ami általában 4 KB) és nem 512 byte. Abban az esetben javasoljuk ennek a beállításnak a használatát, ha olyan szolgáltatásokkal dolgozunk, amelyek nagy számú állománnyal dolgoznak egyszerre. Ilyen szolgáltatások többek közt a webes gyorsítótárak, nagyobb levelezõrendszerek és hírrendszerek. Az opció engedélyezése alapvetõen nem veti vissza a rendszer teljesítményét még akkor sem, ha ezzel memóriát pazarlunk el, de ezt igazából érdemes kikísérletezni. <varname>vfs.write_behind</varname> vfs.write_behind A vfs.write_behind sysctl változó alapértelmezett értéke 1 (bekapcsolt). Ez arra utasítja az állományrendszert, hogy csak akkor küldje ki az adatokat az eszközre, ha belõlük teljes fürtök gyûltek össze. Ez jellemzõ módon nagyobb szekvenciális állományok írása esetén kedvezõ. Arra szolgál, hogy segítségével el lehessen kerülni az I/O túlságosan gyakori módosítások okozta terhelését. Bizonyos körülmények közt ez azonban lassíthatja a futó programok mûködését, ezért ilyenkor érdemes megfontolni a kikapcsolását. <varname>vfs.hirunningspace</varname> vfs.hirunningspace A vfs.hirunningspace sysctl változó értéke azt adja meg, hogy tetszõleges számú példánynál rendszerszinten mekkora mértékû írási mûvelet irányítható át a lemezvezérlõk soraiba. Az alapértelmezés többnyire elegendõ, de olyan gépeken, ahol sok lemez dolgozik egyszerre, ez az érték négy vagy öt megabyte-ra is felszökhet! Hozzátennénk, hogy ha ezt az értéket túlságosan nagyra állítjuk (és így túllépjük a puffer írási küszöbértékét), akkor ezzel hihetetlenül gyenge fürtözési teljesítményt nyerünk. Semmiképp se állítsuk túlzottan nagy értékre! A nagyobb írási értékek a velük párhuzamos olvasások számára késleltetést is jelentenek. Találhatunk még más egyéb pufferelési és gyorsítótárazási sysctl változókat, azonban ezek megváltoztatását egyáltalán nem javasoljuk, mivel a virtuális memória alrendszer kiválóan tudja önállóan állítani ezeket a paramétereit. <varname>vm.swap_idle_enabled</varname> vm.swap_idle_enabled A vm.swap_idle_enabled sysctl változó módosítása olyan nagyobb többfelhasználós rendszerekben bizonyulhat hasznosnak, ahol sok felhasználó lép be és lép ki a rendszerbe és sok az üresjáratban futó program. Az ilyen jellegû rendszerek hajlamosak nagy mennyiségû folyamatos terhelést mérni a tartalékolt szabad memóriára. A beállítás engedélyezésével, valamint a vm.swap_idle_threshold1 és a vm.swap_idle_threshold2 változókon keresztül a kilapozás reakcióidejének alkalmas behangolásával a megszokottnál gyorsabban lenyomhatjuk az üresjáratban dolgozó programokhoz tartozó memórialapok prioritását, amivel a kilapozásokat vezérlõ démon kezére játszunk. Azonban tényleg csak akkor engedélyezzük ezt a lehetõséget, ha valóban szükségünk van rá, mivel így a memóriát jóval elõbb lapozzuk ki és ezzel több lapozóállományt és lemezteljesítményt emésztünk fel. Kisebb rendszerekben jól behatárolható a hatása, azonban a nagyobb rendszerekben, ahol már eleve visszafogott mértékû lapozás történik, ez a beállítás lehetõvé teszi a virtuális memóriát kezelõ alrendszer számára, hogy könnyedén ki- és be rakosgasson komplett futó programokat a memóriába. <varname>hw.ata.wc</varname> hw.ata.wc A &os; 4.3 egyszer már kacérkodott a IDE-lemezek írási pufferének kikapcsolásával. Ez ugyan csökkentette az IDE-lemezek írási sávszélességét, azonban bizonyos merevlemezgyártók gondatlanságából eredõ súlyos adatvesztések miatt szükséges volt a használata. A gond ezzel kapcsolatban ott van, hogy egyes IDE-meghajtók hazudnak az írások teljesítésérõl. A lemezek írási gyorsítótárazásának bekapcsolásával az IDE-meghajtók nem csak az írások sorrendjét rendezik át, hanem nagyobb terhelés esetén egyes blokkokat jóval késõbb is rögzítenek. Ezért a rendszer esetleges összeomlása vagy egy áramkimaradás súlyos károkat okozhat az állományrendszerben. A &os; úgy döntött, hogy a megbízhatóságot választja. Sajnos ez olyan nagyságú teljesítményvesztést okozott, hogy a következõ kiadásban már kénytelenek voltunk alapértelmezés szerint is visszakapcsolni ezt a lehetõséget. A hw.ata.wc nevû sysctl változó vizsgálatával ellenõrizhetjük a rendszerünkön érvényes alapértelmezett beállítást. Amennyiben az IDE írások gyorsítótárazása nem engedélyezett, akkor ezt a változó értékének 1-re állításával állíthatjuk vissza. Ezt a rendszer indításakor a rendszerbetöltõben tehetjük meg. A rendszermag indítása után ennek már nincs hatása. A részleteket a &man.ata.4; man oldalon tudhatjuk meg. <literal>SCSI_DELAY</literal> (<varname>kern.cam.scsi_delay</varname>) kern.cam.scsi_delay a rendszermag beállításai SCSI_DELAY A rendszermag SCSI_DELAY nevû beállítása a rendszer indulásának idejét hivatott mérsékelni. Az alapértelmezett értéke viszonylag magas, innen származik a rendszer indítása során keletkezõ 15 másodperces csúszást. Általában az is megfelelõ, aa ezt visszavesszük az 5 értékre (fõleg a modernebb meghajtók számára). A &os; újabb (5.0 vagy késõbbi) változataiban ez az érték már a kern.cam.scsi_delay sysctl változó értékével is megadható a rendszer indításakor. Azonban ügyeljünk rá, hogy mind a finomhangoláshoz használt változó, mind pedig rendszermag beállítása ezredmásodpercben és nem másodpercben értelmezi ezt az értéket. Soft Updates Soft Updates tunefs A &man.tunefs.8; nevû program használható az állományrendszerek finomhangolására. Nagyon sok opciót találhatunk benne, de itt most csak a Soft Updates ki- és bekapcsolásával foglalkozunk, amit a következõ módon tehetünk meg: &prompt.root; tunefs -n enable /allomanyrendszer &prompt.root; tunefs -n disable /allomanyrendszer Amíg egy állományrendszer csatlakoztatott állapotban van, addig nem módosítható a &man.tunefs.8; paranccsal. A Soft Updates bekapcsolására ezért az a legalkalmasabb idõpont, amikor egyfelhasználós módban vagyunk és még egyetlen partíciót sem csatlakoztattunk. A Soft Updates beállítás engedélyezése a memóriában pufferelt gyorsítótáron keresztül jelentõs mértékben fokozza a metaadatok teljesítményét, elsõsorban az állományok létrehozását és törlését. A Soft Updates használatát ezért minden állományrendszer esetén ajánljuk. A Soft Updates alkalmazásának két rossz oldalára kell tekintettel lennünk. Elõször is a Soft Updates a rendszer összeomlása esetén ugyan garantálja az állományrendszer konzisztenciáját, de könnyen elképzelhetõ, hogy több másodperccel (vagy akár egy egész perccel!) hátrébb jár a fizikai lemez frissítésében. Másodszor a Soft Updates késlelteti az állományrendszer blokkjainak felszabadítását. Ha van egy olyan állományrendszerünk (mint például a rendszer indításához használt gyökér partíció), ami már majdnem betelt, akkor egy nagyobb frissítés, például a make installworld parancs kiadása, során az állományrendszer egyszerûen kifogy a helybõl és így a frissítés meghiúsul. Bõvebben a Soft Updates mûködésérõl Soft Updates részletei Két hagyományos megközelítés létezik az állományrendszerek metaadatainak visszaírására. (A metaadatok módosításakor olyan nem adatot tartalmazó blokkok változnak meg, mint például az állományokra vonatkozó információk vagy a könyvtárak.) Eredetileg alapértelmezés szerint a metaadatok változásait szinkron módon írták ki. Amikor egy könyvtár megváltozott, a rendszer egészen addig várt, amíg ez a változás a lemezre nem íródott. Ugyanekkor az állományok adatait tartalmazó pufferek (az állományok tartalma) átkerültek a pufferelt gyorsítótárba, hogy majd késõbb, aszinkron módon kerüljenek kiírásra. Ennek az implementációnak a biztonságos mûködés volt az elõnye, mivel így a metaadatok még akkor is konzisztens állapotban maradtak, amikor valamilyen hiba következett be. Tehát egy állomány vagy teljesen létrejött vagy egyáltalán nem. Ha az állományhoz tartozó blokkok már nem tudtak kijutni a gyorsítótárból az összeomlás ideje elõtt, akkor az &man.fsck.8; felismerte ezt a helyzetet és az állományrendszer ilyen jellegû hibáját úgy orvosolta, hogy az adott állomány méretét nullára állította. Ezenkívül még az implementációs részletek is tiszták és egyszerûek maradtak. Ennek viszont hátránya, hogy a metaadatok kezelése lassú. Ha például kiadunk egy rm -r parancsot, akkor az a könyvtárban levõ állományokat szekvenciálisan dolgozza fel, de minden egyes változtatást (az állományok törlését) csak szinkron módon rögzíti a lemezre. Ezek a frissítések érintik magát a könyvtárat, az állományokkal kapcsolatos információkat tároló táblázatot (az ún. inode táblát) és minden valószínûség szerint az állományok által lefoglalt blokkokat is közvetve. Hasonló megfontolások élnek a nagyobb könyvtárszerkezetek kibontása esetén is (tar -x). A második lehetõség a metaadatok aszinkron frissítése. Ez az alapértelmezés a Linux ext2fs és BSD-k mount -o async opcióval csatlakoztatott UFS állományrendszerei esetén. Ilyenkor minden metaadattal kapcsolatos aktualizálás egyszerûen bekerült a pufferelt gyorsítótárba, tehát az állományok adatai és ezek a típusú frissítések keverednek. Ennek a megvalósításnak az az elõnye, hogy nem kell megvárni, amíg a metaadatok is kiíródnak a lemezre, ezért a metaadatok óriási mennyiségû változásával járó mûveletek sokkal gyorsabban hajtódnak végre, mint a szinkron esetben. Sõt, maga az implementáció is tiszta és egyszerû marad, ezért a kódban megjelenõ hibák beszivárgásának kockázata alacsony. A módszer hátránya, hogy egyáltalán semmilyen garanciát nem kapunk az állományrendszer konzisztenciájára. Ha tehát egy rengeteg metaadat megváltozásával együttjáró mûvelet közben történik valamilyen probléma (áramkimaradás, vagy valaki egyszerûen megnyomja a reset gombot), akkor az állományrendszer elõre kiszámíthatatlan állapotba kerül. A rendszer újbóli indításakor ezért nincs lehetõségünk megvizsgálni az állományrendszer állapotát. Elképzelhetõ, hogy az állományokhoz tartozó adatok már kikerültek a lemezre, miközben a rá vonatkozó inode- vagy könyvtári bejegyzések még nem. Így lényegében lehetetlen olyan fsck implementációt készíteni, ami képes lenne eltüntetni ezt a káoszt (hiszen az ehhez szükséges adatok nem állnak rendelkezésre). Ha az állományrendszer helyrehozhatatlanul károsodott, akkor csak a &man.newfs.8; és a biztonsági mentés visszaállítása segíthet rajta. Ezt általában úgy küszöbölik ki, hogy az egészhez hozzáteszik még a módosított területek feljegyzését, amit gyakran csak naplózásnak (journaling) neveznek, habár ezt az elnevezést nem mindenhol ilyen értelemben használják, ezért a tranzakciók naplózásának más formáira is utalhat. A metaadatok frissítése ebben az esetben is csak szinkron módon történik, de csak a lemez egy kisebb területére. Késõbb ez a megfelelõ helyére kerül. Mivel a lemez naplózásra fordított része egy viszonylag kis méretû, folytonos terület, a lemez fejének még a megterhelõbb mûveletek esetén sem kell sokat mozognia, ezért valójában ez a megoldás gyorsabb, mint a mezei szinkron frissítések. Az implementáció bonyolultsága továbbra is jól behatárolható, a velejáró hibalehetõségek kockázata alacsony. Hátránya, hogy minden metaadat kétszer íródik ki (egyszer a naplózási területre, aztán a megfelelõ helyre), ezért ez a hétköznapi használat során visszaesés tapasztalható a teljesítményben. Másrészrõl azonban egy összeomlás esetén a naplózási terület segítségével minden függõben levõ metaadattal kapcsolatos mûvelet könnyen visszafordítható vagy lezárható a rendszer következõ indításakor, és ezzel így egy gyors helyreállítást nyerünk. Kirk McKusick, a Berkeley FFS fejlesztõje ezt a problémát a Soft Updates segítségével hidalta át: a metaadatokkal kapcsolatos minden függõben levõ frissítést a memóriában tart, majd ezeket rendezett sorrendben írja ki a lemezre (a metaadatok rendezett frissítése). Ennek következményeképpen a metaadatok komolyabb frissítése során a késõbb érkezõ módosításoknak lehetõségük van elkapni a memóriában levõ korábbi változataikat, ha azok még nem kerültek ki a lemezre. Így az összes, például könyvtárakon végzett, mûvelet a lemezre írás elõtt általában elõször a memóriában játszódik le (a adatblokkok a pozíciójuknak megfelelõen kerülnek rendezésre, ezért a rájuk vonatkozó metaadatok elõtt nem jutnak ki a lemezre). Ha eközben a rendszer összeomlik, akkor így implicit módon a napló visszalapozását eredményezi: minden olyan mûvelet, ami már nem tudott kijutni a lemezre, meg nem történtnek számít. Ezen a módon az állományrendszernek egy 30 és 60 másodperc közti korábbi állapota marad fenn. Az algoritmus garantálja, hogy az összes használt erõforrás a nekik megfelelõ bittérképekben helyesen jelölõdik, a blokkokban és az inode-okban. Az összeomlás után az erõforrások kiosztásával kapcsolatban csak egyetlen hiba léphet fel: amikor olyan erõforrások jelölõdnek használtnak amely igazából szabadok. Az &man.fsck.8; azonban képes felismerni ezeket a helyzeteket és felszabadítani a nem használt erõforrásokat. A mount -f parancs kiadásával minden további következmény nélkül figyelmen kívül hagyhatjuk az állományrendszer félkész állapotát és csatlakoztathatjuk az állományrendszereket. Az használatban már nem levõ erõforrások felszabadításához az &man.fsck.8; parancsot késõbb kell futtatni. Ez az alapötlet húzódik meg a háttérben végzett lemezellenõrzés mögött. A rendszer indításakor az állományrendszernek csupán egy pillanatképét rögzítjük, és az fsck tényleges lefuttatását késõbbre toljuk. Mivel mindegyik állományrendszer csatlakoztatható félkész állapotban, ezért a rendszer képes elindulni többfelhasználós módban. Eközben a háttérben az fsck beütemezhetõ minden olyan állományrendszer számára, ahol arra szükség van, hogy szabadítsa fel az esetlegesen már nem használt erõforrásokat. (Így a Soft Updates opciót nem alkalmazó állományrendszerek esetén továbbra is szükség van az elõtérben elvégzett fsck parancsra.) A módszer elõnye, hogy így a metaadatokkal kapcsolatos mûveletek közel olyan gyorsak, mint az aszinkron módon végzett frissítések (tehát gyorsabb mintha naplóznánk, ami ugye minden metaadatot kétszer ír ki). A hátránya a bonyolultabb kód (ami miatt növekszik az olyan hibák lehetõsége, amik érzékenyen befolyásolhatják a felhasználói adatok elvesztését) és a nagyobb memóriaigény. Ezenkívül még van néhány olyan egyéni jellemzõje, amit meg kell szokni. A rendszer összeomlása után az állományrendszer valamivel régebbi lesz. Amikor pedig megszokott szinkron megközelítés szerint az fsck lefutása után nulla méretû állományok jönnének létre, ezek az állományok a Soft Updates esetén egyáltalán meg sem jelennek, mivel sem a rájuk vonatkozó metaadatok, sem pedig a tartalmuk nem került ki a lemezre. Egy rm lefuttatása után a lemezterület addig nem kerül felszabadításra, amíg a frissítések teljesen rá nem kerülnek a lemezre. Ez nagyobb mennyiségû adat telepítésekor gondokat okozhat egy olyan állományrendszeren, ahol nincs elegendõ hely az állományok kétszeri tárolására. A rendszermag korlátainak finomhangolása finomhangolás a rendszermag korlátai Az állományok és a futó programok korlátozásai <varname>kern.maxfiles</varname> kern.maxfiles A kern.maxfiles értéke a rendszerünk igényeinek megfelelõen növelhetõ vagy csökkenthetõ. Ez a változó adja meg a rendszerünkben levõ állományleírók maximális számát. Amikor az állományleírókat tároló táblázat megtelik, a rendszer üzenetpufferében egy file: table is full üzenet jelenik meg, amit a dmesg paranccsal tudunk megnézni. Minden megnyitott állomány, csatlakozás vagy FIFO elhasznál egy állományleírót. Egy nagyméretû szerver könnyen felemészthet több ezernyi állományleírót attól függõen, hogy milyen és mennyi szolgáltatást futtat egymás mellett. A &os; korábbi kiadásaiban a kern.maxfiles a rendszermag beállításait tartalmazó állomány (a rendszerben egyszerre jelenlevõ felhasználók maximumának) értékébõl származott, tehát a kern.maxfiles a értékével arányosan növekszik. Amikor készítünk egy saját rendszermagot, mindig érdemes a rendszerünk használatának megfelelõen beállítani ezt az értéket, mivel a rendszermag ebbõl a számból határozza meg a legtöbb elõre meghatározott korlátait. Mivel még egy komoly szerveren sem jelentkeznek be egyszerre 256 felhasználónál többen, nagyjából ugyanannyi erõforrásra van szüksége, mint egy nagyobb webszervernek. A kern.maxusers értéke a rendelkezésre álló memóriának megfelelõen magától méretezõdik a rendszer indításakor, és amit futás közben csak a kern.maxusers sysctl változó írásvédett értékének lekérdezésébõl tudhatunk meg. Egyes oldalak üzemeltetése a kern.maxusers így megállapított értékétõl nagyobbat vagy éppen kisebbet igényel, ezért a betöltéskor minden gond nélkül át lehet állítani 64, 128 vagy 256 értékûre. Senkinek sem ajánljuk, hogy 256 felé menjen, hacsak tényleg nincs szüksége ekkora mennyiségû állományleíróra. A kern.maxusers függvényében beállított alapértelmezett értékek tetszõleges módon átállíthatóak a rendszer indításakor vagy futás közben a /boot/loader.conf módosításával (az ide kapcsolódó javaslatokról bõvebben lásd a &man.loader.conf.5; man oldalt vagy a /boot/defaults/loader.conf állományt) illetve a leírás más részén megadott módok szerint. A korábbi kiadásokban úgy lehet önszabályozóra állítani a maxusers beállítást, ha explicit módon 0 értéket adtunk meg neki Az önszabályozó algoritmus a maxusers értékét a rendszerben található memóriának megfelelõen legalább 32-re, legfeljebb 384-re állítja. . A maxusers paraméter beállításakor legalább érdemes 4-et megadni, különösen akkor, ha használjuk az X Window Systemet vagy szoftvereket fordítunk le. Azért van erre szükség, mert a maxusers értéke által szabályozott legfontosabb mennyiség az egyszerre futtatható programok táblázatának maximális mérete, amelyet így számolunk ki: 20 + 16 * maxusers. Tehát ha a maxusers értékét 1-re állítjuk be, akkor az elõbb képlet értelmében csak 36 programunk futhat egymással párhuzamosan, beleértve mindazt a kb. 18 programot, amik a rendszerrel együtt indulnak, illetve még azt a további 15 programot, amit az X Window System használatával indítunk el. Még egy olyan egyszerû dolog is, mint például egy man oldal megnézése legalább kilenc programot elindít a szûréshez, kitömörítéshez és megnézéshez. Azonban ha a maxusers értékét 64-re állítjuk, akkor egyszerre akár már 1044 programot futtathatunk, ami szinte mindenre elegendõ. Ha persze egy új program indításakor kapunk egy proc table full típusú üzenetet vagy nagy számú konkurens felhasználóval futtatunk szervert (ilyen például a ftp.FreeBSD.org), akkor érdemes növelni ezt a számot és újrafordítani a rendszermagot. A maxusers nem korlátozza a számítógépre egyszerre bejelentkezni képes felhasználók számát. Egyszerûen csak beállítja néhány táblázat méretét és az egyszerre futtatható programok mennyiségét a rendszert egyidejûleg használni kívánó felhasználók maximális számának figyelembevételével. <varname>kern.ipc.somaxconn</varname> kern.ipc.somaxconn Az kern.ipc.somaxconn sysctl változó a beérkezõ TCP kapcsolatokat fogadó sor hosszát határozza meg. Ennek az alapértelmezett értéke 128, ami az új kapcsolatok megbízható kezeléséhez általában kevés egy erõsen leterhelt webszerver számára. Ilyen helyzetekben ezt az értéket javasolt 1024-re vagy még annál is nagyobbra állítani. Az egyes szolgáltatások démonai ugyan szintén le szokták korlátozni a fogadósoruk méretét (például a &man.sendmail.8; vagy az Apache), de gyakran találunk a beállításai között olyat, amivel ennek a sornak a mérete növelhetõ. A nagyobb fogadósorok mellesleg jó szolgálatot tesznek a Denial of Service (DoS) típusú támadásokkal szemben is. Hálózati korlátozások A rendszermag NMBCLUSTERS nevû beállítása szab határt a rendszer részére elérhetõ memóriapufferek mennyiségének. Egy nagyobb forgalmú szerver esetén a pufferek alacsony száma gátat szabhat a &os; képességeinek. Minden klaszter nagyjából 2 KB memóriát takar, így az 1024-es érték azt jelenti, hogy a rendszermag memóriájából 2 megabyte-ot fordítunk a hálózati pufferelésre. Egyszerûen kiszámítható mennyire is van szükségünk: ha van egy webszerverünk, ami egyszerre legfeljebb 1000 párhuzamos kapcsolatot fogad, és minden kapcsolat lefoglal 16 KB-ot a fogadó-, valamint újabb 16 KB-ot a küldõpuffer számára, akkor megközelítõleg 32 MB-nyi hálózati pufferre lesz szükségünk a webszerver hatékony mûködéséhez. Ezt az értéket gyakran még érdemes megszorozni kettõvel, így 2 x 32 MB / 2 KB = 64 MB / 2 KB = 32768. Több memóriával rendelkezõ számítógépek esetén egy 4096 és 32768 közti értéket javaslunk. Semmilyen körülmények között ne adjunk meg ennél nagyobb értéket, mert ezzel a rendszer már az indítása során összeomolhat. A &man.netstat.1; beállításával ellenõrizhetjük a hálózati klaszterek kihasználtságát. A kern.ipc.nmbclusters változó értékét a rendszer indításakor érdemes megváltoztatni. A &os; korábbi változataiban ehhez a rendszermag NMBCLUSTERS nevû &man.config.8; paraméterének módosítására van szükségünk. Az olyan forgalmasabb szervereken, ahol sokat használják a &man.sendfile.2; rendszerhívást, szükségünk lehet a &man.sendfile.2; által használt pufferek számának növelésére a rendszermag NFSBUFS nevû konfigurációs paraméterén vagy a /boot/loader.conf állományon keresztül (lásd &man.loader.8;). Amikor a futó programok közül sokan vannak sfbufa állapotban, akkor az egyértelmûen annak a jele, hogy ezen a paraméteren állítanunk kell. A kern.ipc.nsfbufs egy írásvédett változót, amelyet a rendszermag állít be. Ez a paraméter névlegesen a kern.maxusers változó értékének megfelelõen változik, de bizonyos esetekben ettõl függetlenül önállóan kell behangolni. Annak ellenére, hogy egy socketet blokkolásmentesnek jelöltünk meg, a &man.sendfile.2; meghívása egy blokkolásmentes socketre blokkolódást eredményezhet egészen addig, amíg a használatához elegendõ struct sf_buf struktúra össze nem gyûlik. <varname>net.inet.ip.portrange.*</varname> net.inet.ip.portrange.* A net.inet.ip.portrange.* sysctl változók vezérlik a TCP és UDP csatlakozásokhoz automatikusan hozzárendelt portszámok tartományát. Három ilyen tartomány létezik: az alsó, az alapértelmezett és a felsõ tartomány. A legtöbb hálózati program a net.inet.ip.portrange.first és net.inet.ip.portrange.last változók által rendre az 1024-tõl 5000-ig kijelölt alapértelmezett tartományt használja. A kimenõ kapcsolatok is rögzített porttartományokat követnek, és adott körülmények mellett be lehet állítani úgy a rendszerünket, hogy ezen kívül osszon ki portokat. Ez a legtöbbször akkor fordul elõ, amikor egy erõsen leterhelt webproxyt mûködtetünk. A porttartományok nem okoznak gondot olyan szervereknél, ahol általában bejövõ kapcsolatokra lehet számítani, tehát például webszerverek esetén, vagy ahol korlátozott a kimenõ kapcsolatok száma, mint például a levelek továbbításánál. Ha olyan helyzetbe keverednénk, ahol már kifutunk a felhasználható portokból, a net.inet.ip.portrange.last mérsékelt növelésével javasolt kitörni. Ilyenkor a 10000, 20000 vagy 30000 értékek elfogadhatóak. Amikor megváltoztatjuk a porttartományok határait, elõtte mindig gondoljuk át, milyen hatással lehet ez a tûzfalra. Egyes tûzfalak blokkolhatnak bizonyos tartományokat (általában az alacsonyabbakat) és arra számítanak, hogy a rendszerek a kimenõ kapcsolatokhoz a nagyobb számú portokat használják — ebbõl kifolyólag nem ajánlott csökkenteni a net.inet.ip.portrange.first értékét. A TCP sávszélesség-késletetés szorzat A TCP sávszélesség-késleltetés szorzatának korlátozása net.inet.tcp.inflight.enable A TCP sávszélesség-késleltetés szorzat korlátozása hasonlít a NetBSD-ben megtalálható TCP/Vegas implementációhoz. A net.inet.tcp.inflight.enable sysctl változó 1-re állításával lehet engedélyezni. A rendszer ilyenkor minden egyes kapcsolathoz megpróbálja kiszámítani a sávszélesség-késleltetés szorzatot és az optimális átviteli sebesség fenntartásához illeszkedõen korlátozni a hálózat felé küldött adatok sorának hosszát. Ez a lehetõség még olyankor hasznosnak bizonyulhat, amikor modemen, Gigabit Etherneten vagy nagysebességû WAN (vagy bármilyen más nagy sávszélesség-késleltetés szorzattal bíró) összeköttetéseken keresztül küldünk át adatokat, különösen abban az esetben, amikor ablakméretezést is használnunk vagy nagy küldési ablakot állítottunk be. Az engedélyezésekor ne felejtsük el net.inet.tcp.infligt.debug változót sem beállítani 0-ra (amivel így kikapcsoljuk a nyomkövetést) és éles használat esetén pedig elõnyös lehet a net.inet.cp.inflight.min változót legalább 6144-re állítani. Azonban hozzátesszük, hogy összeköttetéstõl függõen a nagy minimum értékek tulajdonképpen kikapcsolják a sávszélességkorlátozást. Ez a korlátozási lehetõség csökkenti a közbensõ út adatinak és csomagváltásokhoz tartozó sorok méretét, miközben csökkenti a helyi számítógép felületén felépülõ sorok méretét is. Ha kevesebb csomagot rakunk be a sorba, akkor az interaktív kapcsolatok, különösen a lassabb modemek esetében, kisebb körbejárási idõvel (Round Trip Time) mûködnek. Továbbá megemlítenénk, hogy ez a lehetõség csak az adatok küldésére (feltöltésére, szerveroldalra) van hatással. Semmilyen befolyása nincs az adatok fogadására (letöltésére). A net.inet.tcp.inflight.stab állítgatása nem ajánlott. A paraméter értéke alapértelmezés szerint 20, ami legfeljebb 2 csomag hozzáadását jelenti a sávszélesség-késleltetés szorzat ablakának kiszámításakor. Erre a kiegészítõ ablakra azért van szükség, hogy stabilizálni tudjuk vele az algoritmust és javítani tudjuk a változó feltételekre adott reakciót, de lassabb összeköttetések esetében nagyobb ping idõket is eredményezhet (habár ezek még így kisebbek, mint ha nem használnánk az algoritmust). Ilyen esetekben megpróbálhatjuk 15-re, 10-re vagy esetleg 5-re visszavenni a paraméter értékét, de ekkor a kívánt hatás eléréséhez minden bizonnyal a net.inet.tcp.inflight.min értékét is redukálunk kell majd (például 3500-ra). Ezen paraméterek megváltoztatását csak végsõ esetben ajánljuk! Virtuális memória <varname>kern.maxvnodes</varname> A vnode egy állomány vagy könyvtár belsõ ábrázolása. Ennek megfelelõen a vnode-ok számának növelésével az operációs rendszer spórolni tud a lemezmûveletekkel. Ezt általában maga az operációs rendszer szabályozza, és nincs szükség a finomhangolására. Néhány esetben, amikor a lemezmûveletek jelentik a rendszerben a szûk keresztmetszetet és a kezdenek elfogyni a vnode-ok, szükség lehet ennek a számnak a növelésére. Ehhez az inaktív és szabad fizikai memória mennyiségét kell számításba vennünk. Így kérhetjük le a pillanatnyilag használatban levõ vnode-ok mennyiségét: &prompt.root; sysctl vfs.numvnodes vfs.numvnodes: 91349 Így tudhatjuk meg a vnode-ok maximális számát: &prompt.root; sysctl kern.maxvnodes kern.maxvnodes: 100000 Ha a vnode-ok aktuális kihasználtsága megközelíti a csúcsértéket, nagyjából ezerrel javasolt megnövelni a kern.maxvnodes értékét. Ezután figyeljük továbbra is a vfs.numvnodes változását. Ha ismét felkúszik a maximális értékre, akkor növeljük megint egy keveset a kern.maxvnodes értékén. Eközben a &man.top.1; használatával figyelhetjük a memória kihasználtságának növekedését is, ilyenkor tehát több memóriának kell használatban lennie. A lapozóterület bõvítése Nem számít mennyire tervezük jól elõre, mindig elõfordulhat, hogy a rendszerünk mégsem teljesíti a kitûzött elvárásokat. Amennyiben további lapozóterület hozzáadására lenne szükségünk, azt igen könnyen megtehetjük. Háromféleképpen növelhetjük a lapozásra szánt területet: hozzáadunk a rendszerhez egy újabb merevlemezes meghajtót, NFS-en keresztül lapozunk, vagy egy már meglevõ partíción hozunk létre lapozóállományt. A lapozóterület titkosításával, valamint annak lehetõségeivel és okaival kapcsolatban lapozzuk fel a kézikönyv át. Lapozás egy új merevlemezre A lapozóterület bõvítésének legjobb módja természetesen remek indok egy új merevlemez beszerzésére is. Elvégre egy merevlemezt mindig fel tudunk ilyen célra használni. Ha ezt a megoldást választjuk, elõtte ajánlott (újra) elolvasni a kézikönyv ában a lapozóterületek elrendezésére vonatkozó javaslatokat. Lapozás NFS-en keresztül NFS-en keresztül csak akkor lapozzunk, ha ezt helyi lemezek segítségével nem tudjuk megtenni. Az NFS alapú lapozás hatékonyságát erõsen behatárolja a rendelkezésre álló hálózati sávszélesség és további terheket ró az NFS szerverünkre is. Lapozóállományok Lapozóállománynak egy adott méretû állományt hozzunk létre. Ebben a példában erre egy /usr/swap0 nevû, 64 MB méretû állományt fogunk használni. Természetesen bármilyen más nevet is választhatunk. Lapozóállomány létrehozása &os;-ben Gyõzõdjünk meg róla, hogy a rendszermagunk beállításai között megtalálható a memórialemez meghajtójának (&man.md.4;) használata. Ez a GENERIC rendszermag alapból tartalmazza. device md # Memória "lemezek" Hozzunk létre egy lapozóállományt (/usr/swap0): &prompt.root; dd if=/dev/zero of=/usr/swap0 bs=1024k count=64 Állítsuk be rá a megfelelõ engedélyeket (/usr/swap0): &prompt.root; chmod 0600 /usr/swap0 Adjuk meg a lapozóállományt az /etc/rc.conf állományban: swapfile="/usr/swap0" # Állítsuk be swapfile értékét, ha külsõ lapozóállományra van szükségünk. Indítsuk újra a számítógépünket, vagy a lapozóállomány azonnali használtba vételéhez írjuk be: &prompt.root; mdconfig -a -t vnode -f /usr/swap0 -u 0 && swapon /dev/md0 Hiten Pandya Írta: Tom Rhodes Energia- és erõforrásgazdálkodás Fontos a hardveres erõforrásaink hatékony kihasználása. Az ACPI megjelenése elõtt az operációs rendszerek csak nehézkesen és rugalmatlanul tudták kezelni a rendszer energiafelhasználási és hõszabályzási lehetõségeit. A hardvert a BIOS kezelte, ezért a felhasználó kevesebbet tudott látni és irányítani az energiagazdálkodási beállításokból. Az Fejlett energiagazdálkodás (Advanced Power Management, APM) ehhez nyújtott egy erõsen korlátozott felületet. Napjaink operációs rendszereiben az energia- és erõforráskezelés az egyik legfontosabb alkotóelem. Például, ha az operációs rendszerrel folyamatosan figyelni akarjuk a rendszer hõmérsékletének váratlan növekedését (és errõl figyelmeztetést kérni). A &os; kézikönyvének ezen szakaszában az ACPI-rõl adunk egy átfogó áttekintést, a végén pedig összefoglaljuk a témához tartozó irodalmat. Mi az ACPI? ACPI APM A speciális energia- és konfigurációs illesztõ felület (Advanced Configuration and Power Interface, avagy ACPI) gyártók egy csoportja által létrehozott szabvány, amely hardveres erõforrások és az energiagazdálkodás egységes felületét rögzíti (innen a neve). Döntõ szerepet játszik a Beállítások és az energiagazdálkodás operációs rendszerek áltai vezérlésében, vagyis segítségével az operációs rendszer még nagyobb mértékben és rugalmassággal tudja irányítani ezeket a lehetõségeket. A modern operációs rendszerek az ACPI felbukkanásával kitolták a jelenleg meglevõ Plug and Play felületek korlátait. Az ACPI az APM közvetlen leszármazottja. A Fejlett energiagazdálkodás (APM) hiányosságai A Fejlett energiagazdálkodás (APM) a rendszer által felhasznált energiát annak elfoglaltsága alapján vezérli. Az APM-et támogató BIOS-t a (rendszert) gyártó állítja elõ és az adott hardverplatformra jellemzõ. Az APM operációs rendszerben levõ meghajtója hozzáférést biztosít az APM szoftveres felületéhez, amivel lehetõség nyílik az energiaszintek kezelésére. Az APM-et 2000 elõtt és körül még mindig használták egyes rendszerek gyártásánál. Az APM használata négy nagyobb gondot rejt magában. Elõször is, az energiagazdálkodást a (gyártófüggõ) BIOS végzi el, és az operációs rendszernek errõl semmilyen ismerete nincsen. Ennek egyik példája az, amikor a felhasználó az APM-et ismerõ BIOS-ban beállítja a merevlemezek automatikus kikapcsolásának idejét, majd amikor ez letelik, a BIOS az operációs rendszer tudta nélkül egyszerûen leállítja a lemezt. Másodszor: az APM mûködését a BIOS-ban programozták le, és teljesen az operációs rendszer hatáskörén túl tevékenykedik. Ez azt jelenti, hogy a felhasználó csak úgy tudjuk korrigálni az APM-es BIOS-ok problémáit, ha frissíti az alaplapi ROM-ot. Ez viszont egy nagyon kockázatos folyamat, aminek hibája révén a rendszerünk helyrehozhatatlan állapotba kerül. Harmadszor: az APM alapvetõen egy gyártófüggõ megoldás, ami azt vonja maga után, hogy sok az átfedés (ugyanazt valósítják meg több módon), és ha az egyik gyártó BIOS-ában hibát találnak, akkor a másikéban az nem feltétlenül javítható. Végül, de nem utolsó sorban, az APM alapú BIOS-okban nincs elég hely az igazán kifinomult energiagazdálkodási sémák vagy bármi más kialakítására, amivel a felhasználók képesek lennének az igényeikhez alakítani a számítógépet. A Plug and Play BIOS (PNPBIOS) sok szempontból megbízhatatlannak bizonyult. A PNPBIOS ráadásul egy 16 bites megoldás, ezért az operációs rendszereknek 16 bites emulációt kell használniuk a PNPBIOS eszközeinek eléréséhez. A &os; APM meghajtójának dokumentációját az &man.apm.4; man oldalon találjuk. Az <acronym>ACPI</acronym> beállítása Az acpi.ko meghajtó alapértelmezés szerint a &man.loader.8; segítségével töltõdik be, és ne is fordítsuk bele a rendszermagba. Ezt azzal tudnánk magyarázni, hogy modulokkal könnyebb dolgozni, például ha a rendszermag újrafordítása nélkül egy másik acpi.ko modult akarunk használni. Ezzel a lényegében tesztelés is egyszerûbbé válik. Másik magyarázat, hogy a rendszer ACPI támogatása nem minden esetben mûködik rendesen. Ha a rendszer indítása során valamilyen problémát tapasztalunk, akkor próbálkozzunk meg az ACPI kikapcsolásával. Ezt a meghajtót nem lehet és nem is szabad kidobni a memóriából, mivel a hardverrel a rendszerbuszon keresztül tartja a kapcsolatot. Az ACPI a hint.acpi.0.disabled="1" sor megadásával kapcsolható a /boot/loader.conf állományban vagy a &man.loader.8; parancssorában. Az ACPI és APM egyszerre nem használatóak. Közülük a késõbb betöltött magától kilép, ha észreveszi, hogy a másikuk már mûködésbe lépett. Az ACPI és az &man.acpiconf.8; használatával a rendszerünk készenléti módba helyezhetõ az valamint az 1-5 paraméterek megadásával. Ezek közül is csak a legtöbb felhasználó számára az 1 vagy a 3 (állapot mentése a fizikai memóriába) érdekes. Az 5 opció egy szoftveres kikapcsolást eredményez, ehhez hasonlóan: &prompt.root; halt -p A további opciók a &man.sysctl.8; man oldaláról érhetõek el. Ezen kívül még olvassuk el az &man.acpi.4; és &man.acpiconf.8; man oldalakat is. Nate Lawson Írta: Peter Schultz Segítségére volt még: Tom Rhodes A &os; <acronym>ACPI</acronym> támogatásának használata és nyomonkövetése ACPI problémák Az ACPI az eszközök felderítésének, energiagazdálkodásának és a korábban a BIOS által kezelt hardverek szabványosított hozzáférésének alapjaiban új módja. Az ACPI folyamatosan fejlõdik, de útját az egyes alaplapok ACPI Machine Language (AML) bytekód implementációjában megjelenõ hibák, a &os; rendszermag alrendszereinek befejezetlensége és az &intel; ACPI-CA értelmezõjében levõ hibák lassítják. Ez a leírás azzal a szándékkal készült, hogy segítsünk a felhasználóknak megtalálni az általuk tapasztalt problémák gyökerét és ezzel kisegíteni az ACPI fejlesztõket a nyomonkövetésében és kijavításában. Köszönjük, hogy ezt elolvassuk és segédkezünk a rendszerünkkel kapcsolatban felmerült problémák orvosolásában! A nyomkövetési információk beküldése Mielõtt beküldenénk bármilyen problémát is, gondoskodjunk róla, hogy a BIOS-unk, és ha lehetséges, akkor a beágyazott vezérlõk, legfrissebb verzióját használjuk. Megkérnénk azokat, akik hibát akarnak bejelenteni, hogy a következõ információkat küldjék a freebsd-acpi@FreeBSD.org címre: A hibás mûködés leírása, beleértve a rendszer típusát és gyártmányát, illetve minden olyat, aminek köze lehet a hibához. Ha eddig még nem tapasztaltuk, igyekezzünk minél pontosabban leírni a hiba keletkezésének folyamatát. A boot -v paranccsal indított rendszer &man.dmesg.8; kimenetét, beleértve a vizsgálni kívánt hiba által okoztt összes hibaüzenetet. A boot -v paranccsal és az ACPI használata nélkül indított rendszer &man.dmesg.8; kimenete abban az esetben, ha ez segít megoldani a problémát. A sysctl hw.acpi parancs kimenete. Ezzel egyébként kitûnõen kideríthetõ milyen lehetõségeket is kínál fel a rendszerünk. Az általunk használt ACPI forrásnyelvének (ACPI Source Language, ASL) elérhetõsége az interneten. Mivel ezek akár igen nagyok is lehetnek, ezért a listára közvetlenül ne küldjünk ASL kódokat! Az ASL másolatát az alábbi parancs kiadásával hozhatjuk létre: &prompt.root; acpidump -dt > név-rendszer.asl (Adjuk meg a név helyett a bejelentkezéshez használt nevünket és a rendszer helyett pedig a gyártót/típust. Például: njl-FooCo6000.asl) Habár a legtöbb fejlesztõ a &a.current;t figyeli, a problémáink leírását mindenképpen a &a.acpi.name; listára küldjük, hogy biztosan észrevegyék. Legyünk türelmesek, hiszen emellett mindannyiunk dolgozik. Ha az általunk felfedezett hiba nem teljesen egyértelmû, akkor a fejlesztõk valószínûleg meg fognak kérni arra, hogy a &man.send-pr.1; használatával hozzunk róla létre egy hivatalos hibajelentést. A hibajelentés készítésekor lehetõleg a fentebb megadott információkat ugyanúgy adjuk meg. Ez segít a probléma szemmel tartásában és elhárításában. Az &a.acpi.name; lista kihagyása nélkül közvetlenül ne küldjünk hibajelentést, mivel a hibabejelentõ rendszert elsõsorban emlékeztetõnek használjuk, nem pedig a hibák tényleges bejelentésére. Gyakran elõfordul, hogy valaki korábban már találkozott a problémánkkal. Háttér ACPI Az ACPI minden olyan modern számítógépben megtalálható, mely megfelel az ia32 (x86), ia64 (Itanium) vagy amd64 (AMD) architektúrának. A teljes szabvány rengeteg lehetõséget biztosít, többek közt a processzor teljesítményének kezelését, az energiaszintek vezérlését, hõzónákat, különféle akkumulátor rendszereket, beágyazott vezérlõk és a buszok felsorolását. A legtöbb rendszer általában nem a teljes szabványt valósítja meg. Például egy asztali rendszer általában csak a buszok felsorolásával kapcsolatos részeket tartalmazza, miközben egy laptop felajánlhatja a hûtés és az akkumulátor kezelését is. A laptopokban gyakorta találunk készenléti üzemmódot a maguk elbonyolított formájában. Egy ACPI-nak megfelelõ rendszert számos összetevõ alkot. A BIOS-ok és chipkészletek gyártói a memóriában egy elõre rögzített ponton elhelyeznek bizonyos táblázatokat (például FADT), amelyekkel megadják például az APIC összerendeléseit (ezt az SMP rendszerek használják), a konfigurációs regisztereket és az egyszerûbb konfigurációs értékeket. Itt ezenkívül még bytekódok egy táblázata (amit Differenciált rendszerleírtó táblának, Differentiated System Description Table, DSDT nevezünk) is megtalálható, ahol az eszközök és módszerek neveit szerepelnek faszerû elrendezésben. Az ACPI-hoz tartozó meghajtónak értelmeznie kell tudnia ezeket a rögzített táblázatokat, implementálnia egy bytekód-értelmezõt, módosítania az eszközmeghajtókat és a rendszermagot az ACPI alrendszerbõl érkezõ információk befogadásához. A Linuxszal és a NetBSD-vel közösen a &os; kapott egy ilyen értelmezõt az &intel;tõl (ACPI-CA). Az ACPI-CA forráskódja a rendszer forrásai között, a src/sys/dev/acpica könyvtárban találhatóak. A src/sys/dev/acpica/0sd könyvtárban található források pedig lehetõvé teszik, hogy az ACPI-CA mûködhessen &os;-n. Végezetül, az ACPI eszközöket megvalósító meghajtók a src/sys/dev/acpica könyvtárban találhatóak. Gyakori problémák ACPI problémák Az ACPI megfelelõ mûködéséhez minden alkotórésznek helyesen kell mûködnie. A most következendõkben elõfordulásuk gyakorisága szerint felsorolunk néhány ismert problémát, valamint a hozzájuk tartozó javításokat vagy elkerülésük módszerét. Gondok az egérrel Egyes esetekben felfüggesztett állapotból visszatérve az egerünk nem hajlandó mûködni. Ezt úgy lehet elkerülni, ha /boot/loader.conf állományba beírjuk a hint.psm.0.flags="0x3000" sort. Ha ez nem segít, akkor a fentieknek megfelelõen küldjünk be egy hibajelentést. Felfüggesztés/Folytatás Az ACPI három (STR) állapotban képes a fizikai memória segítségével készenléti módba váltani, ezek az S1-S3, és egy állapotban használja a lemezt (STD), amelyet S4-nek hívnak. Az S5 neve a szoftveres kikapcsolás, ami egy olyan állapotot takar, amikor a rendszerünk áram alatt van, de még nem üzemel. Az S4BIOS állapot a BIOS segítségével a lemezre menti a rendszert, az S4OS állapotot pedig teljes egészében az operációs rendszer valósítja meg. A rendszerünk által ismert készenléti módokat a sysctl hw.acpi paranccsal ellenõrizhetjük. Íme mindez egy Thinkpad esetén: hw.acpi.supported_sleep_state: S3 S4 S5 hw.acpi.s4bios: 0 Ez azt jelenti, hogy az acpiconf -s parancs kiadásával kipróbálhatjuk az S3, S4OS, és S5 állapotokat. Ha az értéke egy (1), akkor az S4BIOS támogatása helyett az S4 OS állapotot kapjuk. A felfüggesztés és folytatás kipróbálása során kezdjük az S1 állapottal, már amennyiben az támogatott a rendszerünkön. Ez az állapot többnyire használható, mivel nem igényel túlságosan sok támogatást a meghajtó részérõl. Eddig még senki sem implementálta az S2 állapotot, de ha ezt is tudja a rendszerünk, akkor az S1-hez hasonlót nyerünk vele. A következõ próba az S3 állapoté. Ez a legmélyebb STR állapot, és a hardver megfelelõ újraélesztéséhez rengeteg támogatás szükségeltetik a meghajtó részérõl. Ha gondjaink lennének a rendszerünk felébresztésével, nyugodtan írjunk egy levelet a &a.acpi.name; listára, ám a probléma gyors megoldódásában ne reménykedjünk, hiszen ehhez még temérdek meghajtón és hardveren kell tesztelni és kell dolgozni. A problémát nagy mértékben segíti különválasztani, ha igyekszünk minél több meghajtót kivenni a rendszermagból. Ha így javul a helyzet, akkor már könnyen le lehet szûkíteni arra a meghajtóra a kört, aminek betöltésével esetleg gondok akadhatnak. Általában ilyenek a bináris meghajtók, mint például az nvidia.ko, az X11 megjelenítésért felelõs és az USB eszközök meghajtói, miközben az Ethernet eszközök remekül szoktak mûködni. Ha különösebb gond nélkül képesek vagyunk betölteni és eltávolítani ezeket a meghajtókat, akkor ezt a folyamatot önállósítani is tudjuk úgy, hogy az /etc/rc.suspend és /etc/rc.resume szkriptekbe beillesztjük az ehhez szükséges parancsokat. Ezekben egyébként találunk is egy megjegyzésbe rakott példát a meghajtók betöltésérõl és eltávolításáról. Ha az ébresztés után elszemetelõdik a képernyõ tartalma, akkor állítsuk át a változó értékét nullára (0). Sokat segíthet meg az is, ha a értékét csökkentjük vagy növeljük. Megpróbálhatjuk azt is, hogy elindítunk egy frissebb Linux disztribúciót ACPI támogatással és ugyanazon a hardveren kipróbáljuk az általa felkínált felfüggesztési és folytatási lehetõséget. Ha Linux alatt ez megbízhatóan mûködik, akkor nagy a valószínûsége, hogy ez &os; alatt az egyik meghajtó hibájából fakadóan nem használható. Így fokozatosan le is tudjuk szûkíteni a pontosan melyikkel lehet a gond, és ezzel pedig a fejlesztõk munkáját segítjük. Megjegyeznénk, hogy az ACPI-t karbantartó fejlesztõk általában nem foglalkoznak más meghajtókkal (például hangkártya vagy ATA stb.), ezért az adott meghajtóval kapcsolatos hibáról javasolt értesíteni a &a.current.name; listát és a meghajtóért felelõs fejlesztõt is. Ha van egy kis kedvünk és idõnk, mi magunk is belebiggyeszthetünk a meghajtóba néhány &man.printf.3; függvényt annak kiderítésére, pontosan hol is fagy le a folytatási funkció. Végül megpróbálkozhatunk az ACPI kikapcsolásával is, és áttérhetünk helyette az APM használatára. Ha az APM-mel mûködnek a készenléti állapotok, akkor érdemes inkább azzal dolgozni, különösen a régebbi (2000 elõtti) hardverek esetében. A gyártóknak eltartott egy ideig, amíg rendes ACPI támogatást voltak képesek adni, ezért a régebbi hardvereknél inkább a BIOS-nak akadnak gondjai az ACPI-val. A rendszer lemerevedik (ideiglenesen vagy teljesen) A legtöbb rendszer olyankor akad meg, amikor sok megszakítás elveszik, vagy amikor éppen sok megszakítás érkezik egyszerre. A chipkészleteknek számos baja származik abból, hogy a BIOS milyen módon állítja be a rendszer indítása elõtt a megszakításokat, mennyire helyes az APIC (MADT) táblázata és hogyan vezérli a Rendszervezérlõ megszakítást (System Control Interrupt, SCI). megszakítás-viharok A megszakítás-viharok a vmstat -i parancs kimenetében szereplõ elveszett megszakításokból azonosíthatók be, ahol keressünk rá az acpi0 sorra. Ha ez a számláló másodpercenként kettõnél többel növekszik, akkor a megszakításaink viharba keveredtek. Ha a rendszer látszólag lefagyott, próbáljuk meg elõhívni a DDB-t (konzolban a CTRLALTESC ) és gépeljük be, hogy show interrupts. APIC kikapcsolása A megszakítási problémákkal kapcsolatban egyetlen reményünk az APIC támogatás kikapcsolása lehet a loader.conf állományban a hint.apic.0.disabled="1" sor hozzáadásával. Végzetes hibák Az ACPI-vel kapcsolatos végzetes hibák viszonylag ritkák, és javításuk a legfontosabb. Ilyenkor az elsõ teendõnk elkülöníteni a hiba reprodukálásának egyes lépéseit és (ha lehetséges) lekérni a hívási láncot. Kövessük az options DDB és a soros vonali konzol beállításához adott tanácsokat (lásd ) vagy hozzunk létre egy &man.dump.8; partíciót. A DDB-ben a hívási láncot a tr parancs segítségével kérhetjük le. Ha kézzel írjuk le láncot, akkor legalább az alsó öt (5) és a felsõ öt (5) sorát mindenképpen jegyezzük fel! Ezután próbáljuk meg úgy szûkíteni a probléma lehetõségét, hogy az ACPI használata nélkül indítjuk a rendszert. Ha ezzel nincs semmi gond, akkor a változó értékének megfelelõ beállításával egyenként meg tudjuk figyelni az ACPI alrendszer egyes részeit. Ehhez példákat az &man.acpi.4; man oldalon találunk. Felfüggesztés vagy leállítás után elindul a rendszer Elõször is próbáljuk meg a hw.acpi.disable_on_poweroff változó értékét 0-ra állítani a &man.loader.conf.5; állományban. Ezzel távoltartjuk az ACPI alrendszert a rendszer leállítási folyamatától. Egyes rendszereknek valamilyen okból kifolyólag szükségük van itt az 1 (az alapértelmezett) értékre. Ez többnyire megoldja a problémát, amikor a rendszer váratlanul elindul a készenléti mód aktiválásákor vagy kikapcsoláskor. Egyéb problémák Ha más gondjaink lennének az ACPI-val (dokkoló állomásunk van, egyes eszközöket nem vesz észre stb.), akkor természetesen errõl is küldjünk egy leírást a levelezési listára. Azonban vegyük figyelembe, hogy egyes problémák a ACPI alrendszer eddig még nem implementált, befejezetlen részeihez kötõdnek, ezért azok megoldása még várat magára. Kérünk mindenkit, hogy legyen türelemmel és álljon készen a kiküldött javítások tesztelésére! <acronym>ASL</acronym>, <command>acpidump</command> és <acronym>IASL</acronym> ACPI ASL A problémák leggyakoribb forrása, hogy a BIOS-gyártók rossz (vagy kifejezetten hibás!) bytekódokat adnak. Ez általában a következõhöz hasonló rendszerüzenetbõl derül ki: ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.FIGD._STA] \\ (Node 0xc3f6d160), AE_NOT_FOUND Az ilyen jellegû hibákat gyakran úgy lehet orvosolni, ha a BIOS-unkat frissítjük a legújabb verzióra. A legtöbb ilyen üzenet teljesen ártalmatlan, de ha vannak más problémáink is, például az akkumulátor állapota nem olvasható le, akkor elõször az AML környékén érdemes kutakodnunk. A bytekód, más néven AML, az ASL elnevezésû forrásnyelvbõl származik. Az AML egy DSDT néven ismert táblázatban található meg. Az ASL másolatát az &man.acpidump.8; paranccsal készíthetjük el. Paraméterként egyaránt adjuk meg a (megmutatja a rögzített táblák tartalmát) és (visszafejti az AML kódokat az ASL nyelvére) kapcsolókat. A felírás pontos formátumát a A nyomkövetési információk beküldése címû szakaszban olvashatjuk. Elsõként próbáljuk meg újrafordítani az így nyert ASL programot és keressünk benne hibákat. A figyelmeztetések általában nyugodtan figyelmen kívül hagyhatóak, azonban a hibák olyan implementációs hibákra utalnak, amelyek akadályozzák az ACPI helyes mûködését. Az ASL újrafordítását az alábbi paranccsal tudjuk elvégezni: &prompt.root; iasl saját.asl Az <acronym>ASL</acronym> kijavítása ACPI ASL Végeredményben az a célunk, hogy az ACPI megfelelõ mûködéséhez senkinek se kelljen hozzányúlnia semmihez. Azonban még mindig szükség van BIOS-gyártók által elkövetett gyakori hibák elkerülésének kifejlesztésére. A µsoft; értelmezõje (acpi.sys és acpiec.sys) nem ellenõrzi szigorúan a szabvány szerinti megfelelést, ezért számos olyan BIOS-gyártó, akik csak &windows; alatt tesztelik az ACPI implementációjukat, soha nem fogják kijavítani a ASL kódjukban ejtett hibáikat. Reménykedünk, hogy folyamatosan sikerül felderíteni és dokumentálni a µsoft; értelmezõje által eltûrt szabványon kívüli viselkedést és leutánozni &os; alatt is, hogy így ne kelljen a felhasználóknak kézzel a saját ASL forrásaikat javítgatni. Az ebbõl fakadó hibákat úgy tudjuk elkerülni és segíteni a fejlesztõknek azonosítani a hozzá társuló viselkedést, hogy magunk javítjuk az ASL-ben felfedezett hibákat. Ha ez beválik, akkor küldjük el a régi és új ASL közti &man.diff.1;-et a fejlesztõknek, akik így majd az ACPI-CA-ban ki tudnak dolgozni egy megoldást a hibás viselkedésre, ezzel a javításunk szükségtelenné válik. ACPI hibaüzenetek Most pedig következzenek a legismertebb hibaüzenetek, az okaik és javításuk: Operációs rendszeri függõségek Néhány AML úgy gondolja, hogy a világ csak a különbözõ &windows; verziókból áll. A &os;-nek megadható, hogy másik operációs rendszernek adja ki magát, és ezzel talán meg is szüntethetõ pár hiba. Ezt a legegyszerûbb úgy tudjuk megtenni, ha a /boot/loader.conf állományhoz hozzáfûzzük a hw.acpi.osname="Windows 2001" sort, vagy itt egy olyan karakterláncot adunk meg, amit az ASL forrásban láttunk. Hiányzó visszatérési érték Bizonyos módszerek a szabvány szerint elvártaktól eltérõen nem adnak vissza explicit módon értéket. Mivel az ACPI-CA ezt nem kezeli le, ezért a &os; részérõl tartalmaz egy olyan módosítást, amivel implicit módon is vissza lehet adni értéket. Ha biztosak akarunk lenni a visszaadni kívánt értékben, akkor helyezzünk el a megfelelõ helyekre explicit Return utasításokat. Az iasl a paraméterrel kényszeríthetõ az ilyen ASL források lefordítására. Az alapértelmezett <acronym>AML</acronym> felülbírálása Miután módosítottuk a saját.asl állományunkat, így tudjuk lefordítani: &prompt.root; iasl saját.asl Az kapcsoló megadásával kikényszeríthetjük az AML létrehozását még abban az esetben is, amikor hibákat tartalmaz. Ügyeljünk rá, hogy bizonyos hibákat (például a hiányzó visszatérési értékeket) a fordító magától kikerül. Az iasl alapértelmezett kimenete a DSDT.aml állomány. A /boot/loader.conf átírásával így tudjuk ezzel helyettesíteni a BIOS-unk hibás változatát (ami még mindig megtalálható a flash memóriában): acpi_dsdt_load="YES" acpi_dsdt_name="/boot/DSDT.aml" Ehhez ne felejtsük el a saját DSDT.aml állományunkat bemásolni a /boot könyvtárba. Nyomkövetési információk kinyerése az <acronym>ACPI</acronym>-bõl ACPI problémák ACPI nyomkövetés Az ACPI meghajtója nagyon rugalmas nyomkövetési lehetõségekkel rendelkezik. Ennek révén ugyanúgy megadhatjuk a nyomonkövetni kívánt alrendszert, mint ahogy annak mélységét is. A nyomkövetni kívánt alrendszereket rétegekként adjuk meg, valamint ezek ACPI-CA komponensekre (ACPI_ALL_COMPONENTS) és ACPI hardvertámogatásra (ACPI_ALL_DRIVERS) bomlanak le. A nyomkövetéskor keletkezõ kimenet részletességét a szintként adjuk meg, ami az ACPI_LV_ERROR-tól (csak a hibák) ACPI_LV_VERBOSE-ig (minden) terjedhet. A szint itt egy bitmaszk, ezért szóközzel elválasztva egyszerre több beállítás megadható. Ha túlságosan sok üzenet érkezik a konzol üzenetpufferébe, akkor szükségünk lehet a soros konzol keresztüli nyomkövetésre is. Az összes szint és réteg az &man.acpi.4; man oldalon található meg. A nyomkövetés alapértelmezés szerint nem engedélyezett. Az engedélyezéséhez hozzá kell adnunk az options ACPI_DEBUG sort a rendszermagunk beállításait tartalmazó állományhoz, amennyiben a rendszermagba fordítjuk az ACPI támogatást. Ha az /etc/make.conf állományba írjuk bele az ACPI_DEBUG=1 sort, akkor azt globális engedélyezhetjük. Ha modulként használjuk, elegendõ csak a következõ módon újrafordítani az acpi.ko modult: &prompt.root; cd /sys/modules/acpi/acpi && make clean && make ACPI_DEBUG=1 Telepítsük fel a acpi.ko modult a /boot/kernel könyvtárba és állítsuk be a számunkra megfelelõ szintet és réteget a loader.conf állományban. Az alábbi példában engedélyezzük az összes ACPI-CA komponens és az összes ACPI hardvermeghajtó (processzor, LID stb.) nyomkövetését. Csak a hibaüzeneteket írja ki részletesen. debug.acpi.layer="ACPI_ALL_COMPONENTS ACPI_ALL_DRIVERS" debug.acpi.level="ACPI_LV_ERROR" Ha az általunk keresett információt egy adott esemény váltja ki (például egy felfüggesztés vagy egy ébresztés), akkor nem is fontos átírnunk hozzá a loader.conf állományt, hanem helyette a rendszer indítása után használjuk a sysctl parancsot a réteg és a szint megadására akkor, amikor a rendszert felkészítjük az eseményre. A sysctl változókat ugyanúgy nevezték el, mint a loader.conf állományban található beállításokat. Hivatkozások Az ACPI-rõl az alábbi helyeken találunk részletesebb információkat: A &a.acpi; Az ACPI levelezési lista archívuma: A korábbi ACPI levelezési lista archívuma: Az ACPI 2.0 specifikációja: A &os; következõ man oldalai: &man.acpi.4;, &man.acpi.thermal.4;, &man.acpidump.8;, &man.iasl.8;, &man.acpidb.8; A DSDT nyomkövetése (angolul). (Példának a Compaqot hozza fel, de általánosságban véve hasznos.) diff --git a/hu_HU.ISO8859-2/books/handbook/mirrors/chapter.sgml b/hu_HU.ISO8859-2/books/handbook/mirrors/chapter.sgml index c64fda2d0e..6405602c2e 100644 --- a/hu_HU.ISO8859-2/books/handbook/mirrors/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/mirrors/chapter.sgml @@ -1,3912 +1,3923 @@ A &os; beszerzése CD és DVD kiadók Kiskereskedelmi dobozos termékek A &os; beszerezhetõ számos kiskereskedõtõl dobozos termék formájában is (&os; CD-k, egyéb szoftverek és nyomtatott dokumentáció):
CompUSA WWW:
Frys Electronics WWW:
CD- és DVD-készletek &os; CD- és DVD-készletek rengeteg helyrõl rendelhetõek:
&os; Mall, Inc. 700 Harvest Park Ste F Brentwood, CA 94513 Egyesült Államok Telefon: +1 925 240-6652 Fax: +1 925 674-0821 e-mail: info@freebsdmall.com WWW:
Dr. Hinner EDV St. Augustinus-Str. 10 D-81825 München Németország Telefon: (089) 428 419 WWW:
Ikarios 22-24 rue Voltaire 92000 Nanterre Franciaország WWW:
JMC Software Írország Telefon: 353 1 6291282 WWW:
The Linux Emporium Hilliard House, Lester Way Wallingford OX10 9TA Egyesült Királyság Telefon: +44 1491 837010 Fax: +44 1491 837016 WWW:
Linux+ DVD Magazine Lewartowskiego 6 Warsaw 00-190 Lengyelország Telefon: +48 22 860 18 18 e-mail: editors@lpmagazine.org WWW:
Linux System Labs Australia 21 Ray Drive Balwyn North VIC - 3104 Ausztrália Telefon: +61 3 9857 5918 Fax: +61 3 9857 8974 WWW:
LinuxCenter.Ru Galernaya utca, 55 Szentpétervár 190000 Oroszország Telefon: +7-812-3125208 e-mail: info@linuxcenter.ru WWW:
Terjesztõk Ha viszonteladók vagyunk és szeretnénk CD-s &os; termékeket forgalmazni, akkor az alábbi terjesztõk valamelyikével vegyük fel a kapcsolatot:
Cylogistics 809B Cuesta Dr., #2149 Mountain View, CA 94040 Egyesült Államok Telefon: +1 650 694-4949 Fax: +1 650 694-4953 e-mail: sales@cylogistics.com WWW:
Ingram Micro 1600 E. St. Andrew Place Santa Ana, CA 92705-4926 Egyesült Államok Telefon: 1 (800) 456-8000 WWW:
Kudzu, LLC 7375 Washington Ave. S. Edina, MN 55439 Egyesült Államok Telefon: +1 952 947-0822 Fax: +1 952 947-0876 e-mail: sales@kudzuenterprises.com
+ +
+ LinuxCenter.Kz + Uszty-Kamenogorszk + Kazahsztán + Telefon: +7-705-501-6001 + e-mail: info@linuxcenter.kz + WWW: +
+ +
LinuxCenter.Ru Galernaya utca, 55 Szentpétervár 190000 Oroszország Telefon: +7-812-3125208 e-mail: info@linuxcenter.ru WWW:
Navarre Corp 7400 49th Ave South New Hope, MN 55428 Egyesült Államok Telefon: +1 763 535-8333 Fax: +1 763 535-0341 WWW:
FTP oldalak A &os; hivatalos forrásai anonim FTP-n keresztül is elérhetõek különféle tükrözésekrõl. Az oldal ugyan jó minõségû kapcsolattal rendelkezik és rengeteg felhasználót is enged egyidejûleg kapcsolódni, azonban valószínûleg jobban járunk, ha egy hozzánk közelebbi tükrözést választunk (különösen abban az esetben, amikor mi magunk is egy tükrözést akarunk készíteni). A &os; tükrözések adatbázisában az itt megtalálhatónál sokkal pontosabb leltárt kaphatunk az elérhetõ tükrözésekrõl, mivel közvetlenül a névfeloldás segítségével állapítja meg a szükséges adatokat és nem egy rögzített listát tárol. Emellett az alábbi tükrözésekrõl a &os; elérhetõ anonim FTP-n keresztül is. Amennyiben az anonim FTP használata mellett döntenénk, igyekezzünk a hozzánk legközelebb levõ szervert használni. Az Elsõdleges tükrözésekként feltüntetett oldalak általában a teljes &os; archívumot tartalmazzák (az összes jelenleg elérhetõ változatot az összes architektúrára), de a környékünkön vagy országunkban elhelyezkedõ tükörszerverekrõl többnyire gyorsabban tudunk majd letölteni. A regionális oldalakon gyakorta csak a népszerûbb architektúrákon futó népszerûbb változatokat találjuk meg, nem a teljes &os; archívumot. Minden szerver elérhetõ anonim FTP-vel, de közülük néhány még további más módszereket is támogat. Az egyes oldalak által ismert konkrét módszereket a nevük után zárójelben közüljük. &chap.mirrors.ftp.inc; BitTorrent BitTorrent Az egyes kiadásokhoz tartozó alap CD-készletek BitTorrent segítségével is elérhetõek. A lemezek képeire hivatkozó torrent állományokat a címrõl tölthetjük le. A BitTorrent kliens telepíthetõ a net-p2p/py-bittorrent portból vagy csomagból. Miután sikeresen letöltöttük BitTorrenten keresztül a lemezképeket, a nyújthat segítséget abban, hogy kell ezeket lemezre írni. Anonim CVS <anchor id="anoncvs-intro">Bevezetés CVS anonim Az anonim CVS (vagy más néven anoncvs) a &os;-hez mellékelt CVS-es segédprogramok által nyújtott olyan lehetõség, amivel távoli CVS repositorykkal tudunk szinkronizálni. Több más dolog mellett lehetõvé teszi a &os; felhasználói számára, hogy kiemelt jogosultságok nélkül képesek legyenek olvasással kapcsolatos CVS mûveleteket végrehajtani a &os; Projekt hivatalos anoncvs szerverein. A használatához egyszerûen csak a kiválasztott anoncvs szervert kell beállítani a CVSROOT környezeti változó értékének, ahol aztán a cvs login parancsnak a szerver által ismert anoncvs jelszót kell megadni. Ezután a &man.cvs.1; paranccsal a többi CVS szerverhez hasonlóan lehetõségünk nyílik hozzáférni. A cvs login parancs a bejelentkezésekhez szükséges jelszavakat a HOME könyvtárunkban levõ .cvspass állományban tárolja. Ha ez az állomány nem létezik, akkor a cvs login elsõ használatakor hibát kapunk. Ilyenkor csak hozzunk létre egy üres .cvspass állományt, majd próbálkozzunk újra. Habár azt mondhatnánk, hogy a CVSup és az anoncvs lényegében egyazon feladatot oldják meg, mind a két esetben léteznek olyan kompromisszumok, amelyek befolyásolhatják a felhasználó választását a két szinkronizációs módszer között. Dióhéjban ezt úgy tudnánk összefoglalni, hogy a CVSup a hálózati erõforrásokat hatékonyabban kihasználja és kettejük közül ez a fejlettebb, azonban ennek meg kell fizetnünk az árát. A CVSup használatához elõször ugyanis telepítenünk kell és be kell állítanunk egy speciális klienst, illetve az adatokat a CVSup által gyûjteményeknek (collection) nevezett, viszonylag nagy méretû egyeségekben érhetjük el. Ezzel szemben az anoncvs használata során a megfelelõ CVS modul nevének felhasználásával tetszõlegesen megvizsgálhatunk önálló állományokat vagy akár programokat (mint az ls vagy a grep). Természetesen az anoncvs segítségével csupán az olvasást igénylõ CVS mûveleteket végezhetjük el, ezért ha a &os; Projekt keretein belül fejleszteni is szeretnénk, akkor inkább érdemes a CVSup alkalmazást választani. <anchor id="anoncvs-usage">Az anonim CVS használata A &man.cvs.1; parancsot nagyon könnyû beállítani az anonim CVS repositoryk használatához, hiszen mindössze annyit kell tennünk, hogy a CVSROOT környezeti változó értékének megadjuk a &os; Projekt valamelyik anoncvs szerverét. Ezen sorok írásának pillanatában a következõ szerverek érhetõek el: Franciaország: :pserver:anoncvs@anoncvs.fr.FreeBSD.org:/home/ncvs (pserver (a jelszó anoncvs), ssh (nincs jelszó)) Japán: :pserver:anoncvs@anoncvs.jp.FreeBSD.org:/home/ncvs (a cvs login használatánál a jelszó anoncvs.) Tajvan: :pserver:anoncvs@anoncvs.tw.FreeBSD.org:/home/ncvs (pserver (a cvs login használatával tetszõleges jelszó megadható), ssh (nincs jelszó)) SSH2 HostKey: 1024 e8:3b:29:7b:ca:9f:ac:e9:45:cb:c8:17:ae:9b:eb:55 /etc/ssh/ssh_host_dsa_key.pub Egyesült Államok: freebsdanoncvs@anoncvs.FreeBSD.org:/home/ncvs (csak ssh — nincs jelszó) SSH HostKey: 1024 a1:e7:46:de:fb:56:ef:05:bc:73:aa:91:09:da:f7:f4 root@sanmateo.ecn.purdue.edu SSH2 HostKey: 1024 52:02:38:1a:2f:a8:71:d3:f5:83:93:8d:aa:00:6f:65 ssh_host_dsa_key.pub Egyesült Államok: anoncvs@anoncvs1.FreeBSD.org:/home/ncvs (csak ssh2 — nincs jelszó) SSH2 HostKey: 2048 53:1f:15:a3:72:5c:43:f6:44:0e:6a:e9:bb:f8:01:62 /etc/ssh/ssh_host_dsa_key.pub Mivel a CVS használatával kikérhetjük (check out) tulajdonképpen a &os; forrásainak akármelyik eddigi (vagy majd ezután keletkezõ) változatát, érdemes megismerkednünk a &man.cvs.1; által alkalmazott revízió (revision) (az opcióval állítható) fogalmával és a &os; Projekt repositoryjain belül engedélyezett értékeivel. Címkéket (tag) két esetben használhatunk: a revíziók és az ágak esetén. A revíziós címkék mindig egy adott revízióra hivatkoznak, ami állandóan ugyanazt jelenti. Ezzel szemben az ágak címkéi a fejlesztés adott irányú menetének az adott pillanatban legfrissebb revízióját hivatkozzák. Mivel az ágak címkéi nem egy adott revízióra vonatkoznak, ezért elmondhatjuk róluk, hogy naponta változik a jelentésük. Az tartalmazza a felhasználók számára fontos revíziós címkéket. Ezek azonban nem igazak a Portgyûjteményre, mivel a Portgyûjteménynek nincs egyszerre több fejlesztési iránya. Egy ág címkéjének megadásával általában az adott irányhoz tartozó állományok legfrissebb változatát kapjuk meg. Ha viszont az állományok egy korábbi változatára lenne szükségünk, akkor a opció megadásával meg tudjuk adni annak idõpontját. Errõl részletesebben a &man.cvs.1; man oldalán olvashatunk. Példák Habár a továbbhaladáshoz mindenképpen javasoljuk a &man.cvs.1; man oldalának részletes áttanulmányozását, mutatunk néhány gyors példát az anonim CVS használatának tömör illusztrálására: Valami (az &man.ls.1;) kikérése a -CURRENT ágból &prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.tw.FreeBSD.org:/home/ncvs &prompt.user; cvs login Jelszóként ezután bármit megadhatunk. &prompt.user; cvs co ls Az <filename>src/</filename> fa kikérése SSH-n keresztül &prompt.user; cvs -d freebsdanoncvs@anoncvs.FreeBSD.org:/home/ncvs co src The authenticity of host 'anoncvs.freebsd.org (128.46.156.46)' can't be established. DSA key fingerprint is 52:02:38:1a:2f:a8:71:d3:f5:83:93:8d:aa:00:6f:65. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'anoncvs.freebsd.org' (DSA) to the list of known hosts. Az &man.ls.1; 6-STABLE ágban szereplõ változatának kikérése &prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.tw.FreeBSD.org:/home/ncvs &prompt.user; cvs login Amikor kéri, jelszóként bármit megadhatunk. &prompt.user; cvs co -rRELENG_6 ls Az &man.ls.1; változásainak (Unified Diff formátumú) listázása &prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.tw.FreeBSD.org:/home/ncvs &prompt.user; cvs login Itt jelszóként bármit megadhatunk. &prompt.user; cvs rdiff -u -rRELENG_5_3_0_RELEASE -rRELENG_5_4_0_RELEASE ls A használható modulok nevének kiderítése &prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.tw.FreeBSD.org:/home/ncvs &prompt.user; cvs login Ezután jelszóként bármit megadhatunk. &prompt.user; cvs co modules &prompt.user; more modules/modules Egyéb helyek A következõ helyeken találhatunk még hasznos információkat a CVS használatáról: A CVS bemutatása (írta: Cal Poly). A CVS honlapja, a CVS fejlesztésével és alkalmazásával foglalkozó közösség oldala. A CVSweb a &os; Projekt által használt CVS rendszerének webes felülete. A CTM használata CTM A CTM használatáva a távoli könyvtárakat tudunk egy központi változattal szinkronban tartani. Eredetileg a &os; forrásaihoz fejlesztették ki, de idõvel mások más célokra is alkalmasnak találhatják majd. Az eltérések (delták) feldolgozásával kapcsolatban kevéske dokumentáció áll rendelkezésre, ezért a &a.ctm-users.name; levelezési listát érdemes felkeresni, ha többet szeretnénk megtudni a CTM egyéb célú alkalmazásairól. Miért használnánk a <application>CTM</application>-et? A CTM segítségével a &os; forrásainak helyi másolatát hozhatjuk létre. A források több különbözõ kivitelben is hozzáférhetõek. A CTM minden esetben képes eleget tenni az igényeinknek, akár az egész CVS fát, akár annak egy részét kívánjuk csak figyelemmel követni. Ha netalán &os; fejlesztõk lennénk, és híján vagyunk vagy éppen gyenge TCP/IP kapcsolattal rendelkezünk, esetleg egyszerûen csak automatikusan értesülni szeretnénk a változásokról, a CTM-et nekünk találták ki. A leggyorsabban fejlõdõ ágakból is naponta legfeljebb három deltát fogunk kapni, azonban érdemes megfontolni a változások automatikus elküldését levélben. A szükséges frissítések méretét mindig igyekszünk minimalizálni. Ez egyébként általában alig 5 KB, de néha (tízbõl egyszer) elõfordul, hogy 10 és 50 KB között van, és idõnként 100 KB vagy afeletti mennyiségû frissítés is érkezhet. Amikor a fejlesztõk által használt forrásokat töltjük le, magunknak kell gondoskodnunk a menet közben felmerülõ különbözõ problémák megoldásáról. Ez kiváltképp igaz abban az esetben, amikor az aktuális, vagy hivatalos nevén CURRENT ágat követjük. Mielõtt azonban egy ilyenbe belevágnánk, érdemes fellapozni a &os; legfrissebb változatának használatáról szóló fejezetet. Mire van szükségünk a <application>CTM</application> használatához? A mûködéshez két komponens szükségeltetik: a CTM kliensprogramja és hozzá a kezdeti delták (amivel majd letöltjük a CURRENT forrásait). A CTM program már a 2.0 kiadástól kezdve a &os; része, és a források között a /usr/src/usr.sbin/ctm könyvtárban találjuk meg (amennyiben felraktuk). A CTM mûködéséhez kellõ deltákat két módon, FTP-n vagy e-mailen keresztül szerezhetjük be. Ha el tudunk érni interneten levõ FTP oldalakat, akkor az alábbi FTP helyeken találunk a CTM-hez használható adatokat: valamint lásd a tükrözéseket. FTP-n keresztül lépjünk be a könyvtárba, töltsük le a README nevû állományt és kövessük a benne szereplõ utasításokat. Ha viszont e-mailen keresztül akarjuk megszerezni a deltákat: Iratkozzunk fel a CTM terjesztési listáinak egyikére. A &a.ctm-cvs-cur.name; lista az egész CVS-fát, míg a &a.ctm-src-cur.name; a fõ fejlesztési ágat teszi elérhetõvé. A &a.ctm-src-4.name; a 4.X kiadásaihoz ágakat tartalmazza, és így tovább. (Ha nem tudjuk, hogyan kell feliratkozni egy levelezési listára, akkor kattintsunk a lista nevére vagy kövessük a &a.mailman.lists.link; linket, majd kattintsunk arra a listára, ahova fel akarunk iratkozni. Ezen az oldalon az összes, a feliratkozáshoz nélkülözhetetlen információnak szerepelnie kell.) Miután elkezdenek megérkezni a CTM-frissítéseket tartalmazó levelek, a tartalmukat a ctm_rmail programmal tudjuk kicsomagolni és felhasználni. Az /etc/aliases állományba akár közvetlenül is beírhatjuk a ctm_rmail programot, és ezzel a önállósítani tudjuk a levélben érkezõ frissítések feldolgozását. A ctm_rmail man oldalán olvashatjuk ennek részleteit. Nem számít, milyen módon jutunk hozzá a CTM által használt deltákhoz, minden esetben fel kell iratkoznunk a &a.ctm-announce.name; levelezési listára. Az elkövetkezendõkben ez lesz az egyetlen hely, ahová a CTM rendszer mûködtetésével kapcsolatos bejelentések beküldésre kerülnek. A feliratkozáshoz kattinsunk a fenti lista nevére és kövessük a mellette szereplõ utasításokat. A <application>CTM</application> elsõ használata Mielõtt nekilátnánk a CTM-hez tartozó delták használatának, elõször el kell jutnunk egy kiindulási ponthoz, ahonnan majd létre tudjuk hozni a rákövetkezõ deltákat. Ehhez elsõként vegyük számba, pontosan mink is van. Általában mindenki egy üres könyvtárral kezd. Ilyenkor egy kezdeti Empty (mint üres) elnevezésû deltával tudjuk megkezdeni az CTM által ismert fa szinkronizálását. Erre a célra lesznek majd szintén alkalmasak a megkezdett delták is, amelyek valamikor a CD-re fognak felkerülni. Mivel a fák maguk több tíz megabyte-nyi méretûek, ezért érdemes inkább valami kéznél levõ eszközzel megkezdeni a folyamatot. Ha van -RELEASE verziójú CD-nk, akkor másoljuk le róla és bontsuk ki a kiindulásként használt forrásokat. Ezzel jelentõs mennyiségû adat átvitelét takaríthatjuk meg. A kezdõ deltákat könnyen megismerjük a szám után X karakterrel leválasztott nevükrõl (például src-cur.3210XEmpty.gz). Az X után szereplõ megnevezés a kezdeti kiindulás (seed) fokának felel meg. Az Empty egy üres könyvtárra utal. A szabályok szerint az Empty állapotból 100 deltánként jön létre újabb (kiindulásra alkalmas) alapváltozat. Ezek azonban nagyon nagyok is lehetnek. A 70 vagy 80 megabyte-os gzippel csomagolt adatok gyakoriak az XEmpty delták esetén. Miután kiválasztottuk a számunkra megfelelõ alapváltozatot, szükségünk lesz a tõle nagyobb sorszámú összes deltára is. A <application>CTM</application> használata a hétköznapokban A delták felhasználásához egyszerûen csak ennyit kell tennünk: &prompt.root; cd /ahol/tárolni/akarjuk/az/adatokat &prompt.root; ctm -v -v /ahol/tároljuk/a/deltákat/src-xxx.* A CTM képes értelmezni a gzip által csomagolt adatokat, ezért nincs szükség a delták elõzetes kitömörítésére, amivel tárhelyet tudunk spórolni. Hacsak nem tekinti tökéletesen biztonságosnak az egész folyamatot, akkor a CTM nem fog módosítani a fán. A deltákat a CTM kapcsolójával is ellenõrizhetjük, aminek során egyáltalán nem fog módosulni a forrásfa. Ekkor egyszerûen csak ellenõrzi a delták sértetlenségét és megnézi, hogy minden rendben zajlana-e az alkalmazásuk során. A CTM-nek vannak még további kapcsolói is, melyekrõl bõvebben a man oldalakból és a forráskódokból tájékozódhatunk. Most már minden megvan, ami kellhet. Amikor kapunk egy újabb deltát, a forrásaink frissítéséhez csak futtassuk át a CTM-en. Ne töröljük le azokat a deltákat, melyeket nehezen tudtunk letölteni. Helyette érdemes inkább megtartani ezeket arra az esetre, ha valami rossz történne. Még ha csak floppylemezek is állnak rendelkezésünkre, mindenképpen másoljuk le ezeket az fdwrite paranccsal. A saját változtatásaink megtartása Fejlesztõként biztosan szeretnénk kísérletezni és állományokat megváltoztatni a forrásfában. A CTM a helyben elkövetett változtatásokat csak korlátozottan támogatja: az ize nevû állomány meglétének vizsgálata elõtt az ize.ctm állományt fogja keresni. Ha létezik, akkor a CTM az ize helyett ezen fog dolgozni. Ezzel a viselkedéssel nyerjük a saját változtatásaink megtartásának egyszerû módját: csak másoljuk le .ctm kiterjesztéssel a módosítani tervezett állományokat. Ezután már szabadon módosíthatjuk a forrásokat, miközben a CTM a .ctm kiterjesztésû állományokat folyamatosan szinkronban tartja. A <application>CTM</application> egyéb érdekes beállításai Derítsük ki pontosan miket is fog érinteni a frissítés A CTM által a forrásokon elvégzendõ változtatások listáját az kapcsolóval kérdezhetjük le. Ez akkor esik kézre, ha szeretnénk feljegyezni a bekövetkezõ változásokat, vagy bármilyen módon elõ- vagy utófeldolgozni a módosított állományokat, esetleg szimplán elõvigyázatosak akarunk lenni. Biztonsági másolat készítése a frissítés elõtt Néha egyszerûen csak szeretnénk az összes érintett állományról biztonsági másolatot készíteni a CTM által elvégzett frissítés elõtt. A beállítás megadásával az adott CTM delta által módosítandó összes állomány tárolásra kerül a mentés-állomány nevû állományba. A frissíthetõ állományok korlátozása Egyes esetekben érdekünkben állhat leszûkíteni a CTM által eszközölt frissítések hatáskörét, vagy egyszerûen csak néhány állomány szinkronizálására van szükségünk. A CTM számára feldolgozható állományok listáját reguláris kifejezés formájában az és opciók mentén határozhatjuk meg. Például ha a lib/libc/Makefile állomány az összegyûjtött CTM delták szerinti legfrissebb verziójához kívánunk hozzájutni, akkor futtassuk az alábbi parancsot: &prompt.root; cd /akarhova/ahova/ki/akarjuk/bontani/ &prompt.root; ctm -e '^lib/libc/Makefile' ~ctm/src-xxx.* A CTM deltákban megadott minden egyes állomány esetén az az opciók a parancssorban történt megadásuk sorrendjében kerülnek feldolgozásra. Egy állományt kizárólag csak akkor dolgoz fel a CTM, ha az az és opciók kiértékelése után is indokolt. További tervek a <application>CTM</application>-mel kapcsolatban Rengeteg van: Valamiféle hitelesítés bevezetése a CTM rendszerbe, amivel észlelhetõek a meghamisított CTM-frissítések. A CTM beállításainak letisztázása, mivel eléggé megtévesztõek és nehézkesen használhatóak. Egyebek Léteznek delták a portok gyûjteményéhez is, azonban még nem mutatkozott túlzottan nagy érdeklõdés irántuk. CTM tükrözések A CTM/FreeBSD anonim FTP-n keresztül elérhetõ az alábbi tüköroldalak valamelyikérõl. Amennyiben ezen a módon kívánjuk letölteni a CTM rendszerhez tartozó állományokat, elõször próbálkozzunk a hozzánk legközelebb levõ szerverrel. Ha bármilyen gond merülne fel, értesítsük a &a.ctm-users.name; levelezési listát. Kalifornia, Bay Area (hivatalos forrás) Dél-Afrika (a korábbi delták biztonsági másolatai) Tajvan/R.O.C. Ha nem találtunk volna hozzánk közel esõ tükrözést, vagy ha talált tükör nem elég friss, akkor próbálkozzunk egy olyan keresõmotor használatával, mint például az alltheweb. A CVSup használata Bevezetés A CVSup távoli szervereken található központi repositorykban levõ forrásfák terjesztésére és a rajtuk keresztüli frissítésre alkalmas programcsomag. A &os; forrásait egy CVS repositoryban tartják karban Kaliforniában egy fejlesztéseket tároló központi számítógépen. A CVSup segítségével a &os; felhasználói könnyen szinkronban tudják vele tartani a saját forrásaikat. A CVSup az ún. lehúzással frissít. Ilyenkor a kliensek csak akkor kérnek a szervertõl frissítéseket, amikor szükségük van rá, miközben a szerver passzívan várja a frissítési kérelmeket. Ennek megfelelõen tehát minden esetben a kliens kezdeményezi a frissítést, a szerver pedig önmagától sosem küld ilyeneket kéretlenül. A felhasználóknak így vagy maguknak kell meghívniuk a CVSup kliensét, vagy a frissítések rendszeres automatikus letöltéséhez be kell állítaniuk a cron rendszerprogramot. A CVSup kifejezés ebben az írásmódban az egész programcsomagra utal. Fõ alkotórészei a a felhasználó gépén futó cvsup nevû kliens, és a &os; tüköroldalain futó cvsupd nevû szerver. A &os; dokumentációjának és levelezési listáinak fürkészése során rengeteg hivatkozást találhatunk egy sup nevû alkalmazásra. A sup a CVSup elõdje volt, és hasonló célokat szolgált. A CVSup használat tekintetében nagyon hasonlít a sup-hoz, és ami azt illeti, a a sup konfigurációs állományaival visszafele kompatibilis formátumot használ. Mivel a CVSup sokkal gyorsabb és rugalmasabb, a supot már nem használja a &os; Projekt. A csup a CVSup C nyelven újraírt változata. Legnagyobb elõnye, hogy gyorsabb és nincs szüksége a Modula-3 nyelv futtató környezetére, ezért azt nem kell a használatához telepíteni. Ráadásul, ha a &os; 6.2 vagy annál késõbbi változatát használjuk, akkor minden további nélkül a rendelkezésünkre áll, hiszen az alaprendszer része. A &os; korábbi verzióinak alaprendszerei ugyan nem tartalmazzák a &man.csup.1; parancsot, viszont a net/csup port vagy csomag segítségével pillanatok alatt telepíteni tudjuk. Emellett a csup segédprogram nem támogatja a CVS módot sem. Teljes repositoryk tükrözéséhez ezért továbbra is a CVSup kell használnunk. Amennyiben a csup mellett tennénk le a voksunkat, a szakasz fennmaradó részében egyszerûen hagyjuk ki a CVSup telepítésérõl szóló lépéseket és a CVSup hivatkozásait helyettesítsük a csup programmal. Telepítés A CVSup telepítésének legegyszerûbb módja a &os; csomaggyûjteményében található elõrefordított net/cvsup csomag használata. Ha viszont inkább forrásból akarjuk telepíteni a CVSupot, akkor helyette használjuk a net/cvsup portot. De legyünk elõvigyázatosak: a net/cvsup portnak szüksége van a Modula-3 rendszerre, aminek letöltése és lefordítása pedig meglehetõsen sok idõt és tárhelyet igényel. Ha olyan gépen akarjuk használni a CVSupot, ahol nincs &xfree86;, &xorg; vagy bármilyen más ilyen szerver, akkor használjuk a net/cvsup-without-gui portot, ami nem tartalmazza a hozzátartozó grafikus felületet. Ha a &os; 6.1 vagy korábbi változatain szeretnénk telepíteni a csupot, használjuk a &os; csomaggyûjteményében megtalálható net/csup csomagot. Ha viszont forrásból kívánjuk telepíteni a csup programot, akkor helyette használjuk a net/csup portot. A CVSup beállítása A CVSup mûködését a supfile elnevezésû állomány vezérli. A /usr/share/examples/cvsup/ könyvárban találhatunk néhány példát a supfile állományokra. A supfile állományban szereplõ információk a CVSup használatával kapcsolatban a következõ kérdéseket válaszolják meg: Milyen állományokat akarunk letölteni? Milyen verzióikra van szükségünk? Honnan akarjuk ezeket beszerezni? Hova akarjuk rakni a számítógépünkön? Hova akarjuk rakni az állapotot tároló állományokat? Az imént feltett kérdésekre a következõ szakaszokban összeállítandó supfile segítségével fogunk válaszolni. Ehhez elõször bemutatjuk a supfile formátumú állományok általános szerkezetét. A supfile állományok szöveget tartalmaznak. A megjegyzések # karakterrel kezdõdnek és a sor végéig tartanak. A kizárólag csak megjegyzéseket tartalmazó vagy üres sorok nem kerülnek feldolgozásra. Az összes többi fennmaradó sorban pedig azokat az állományokat írjuk le, amelyeket a felhasználó le akar tölteni. Az ilyen fajtájú sorok egy gyûjtemény (collection) nevével kezdõdnek, ami állományok egy szerver által meghatározott logikai csoportjára utal. A gyûjtemény neve ennek megfelelõen elárulja a szervernek, hogy pontosan milyen állományokra van szükségünk. Ezután következik whitespace-szel elválasztva nulla vagy több mezõ, amelyek a korábban feltett kérdéseinket válaszolják meg rendre. Ezeknek a mezõknek két típusa létezik: a beállításokat és a konkrét értéket tároló mezõk. A beállításokat tároló mezõk különbözõ kulcsszavakat tartalmaznak, például a delete (törlés) vagy compress (tömörítés). Az értéket tároló mezõk is egy kulcsszóval kezdõdnek, azonban utána közvetlenül egy = (egyenlõségjel) jön, amelyet egy második szó követ szorosan. Így például a release=cvs pontosan egy ilyen értékmezõ lesz. Egy supfile általában egynél több gyûjtemény letöltését írja le. Ezért az ilyen állományok felépítésének egyik módja, ha az egyes gyûjteményhez explicite megadjuk a hozzátartozó mezõket. Azonban így a supfile állományok gyorsan megnövekednek és kényelmetlenné válnak, mivel a legtöbb gyûjtemény esetén szinte ugyanazokat a mezõket kellene megadnunk. A CVSup az ilyen típusú bonyodalmak elkerülésére egy alapértelmezési megoldást javasol. A *default nevû álgyûjteménnyel kezdõdõ sorok segítségével meg tudunk adni olyan beállításokat és értékeket, amelyek az utána következõ gyûjtemények számára alapértelmezésnek fognak számítani a supfile állományban. Az itt megadott alapértelmezések természetesen az egyes gyûjteményekben tetszõleges módon felülbírálhatóak, a mezõk magán a gyûjteményen belüli megadásával. Az állományban az alapértelmezések is megváltoztathatóak vagy bõvíthetõek további *default sorok hozzáadásával. Mindezek tudatában most már megkezdhetjük a FreeBSD-CURRENT ág tartalmának letöltésére és frissen tartására alkalmas supfile állomány összeállítását. Milyen állományokat akarunk letölteni? A CVSupon keresztül elérhetõ állományok gyûjteményeknek hívott nevesített csoportokra bontva érhetõek el. A hivatkozható gyûjtemények leírását a következõ szakaszban találjuk. Ebben a példában most szeretnénk letölteni az egész &os; rendszer forrását. Ezt a src-all nevû gyûjteményre hivatkozva érhetjük el. A supfile állományunk létrehozásának elsõ lépéseként soronként egyet megadva felsoroljuk a letölteni kívánt gyûjteményeket (jelen esetünkben csak egyetlen egyet): src-all Milyen verzióikra van szükségünk? A CVSup használatával tulajdonképpen a források összes valaha létezett verziójához hozzá tudunk férni. Ez annak köszönhetõ, hogy a cvsupd szerver közvetlenül a CVS repositoryból dolgozik, ami pedig az összes verziót tartalmazza. A tag= és date= értékmezõk segítségével adhatjuk meg az igényelt verziókat. Legyünk óvatosak azonban a tag= mezõk helyes megadásával. Egyes címkék ugyanis csak bizonyos állománygyûjtemények esetén élnek. Ha hibás vagy elírt címkét adunk meg, akkor a CVSup törölni fog olyan állományokat, amelyeket valószínûleg nem kellene. A ports-* gyûjtemények esetében pedig kifejezetten csak a tag=. mezõk használhatóak! A tag= mezõk a tárházban található szimbolikus címkéket nevezik meg. A címkéknek két típusa van: a revíziókhoz és az ágakhoz tartozó címkék. A revíziós címkék mindig egy adott revíziót hivatkoznak, jelentésük állandó. Ezzel szemben az ágak címkéi egy adott fejlesztési ág adott idõpontjában elérhetõ revíziót címkézi. Mivel az ágak címkéi nem egy konkrét revízióra vonatkoznak, ezért akár olyanra is utalhatnak, ami pillanatnyilag még nem is létezik. Az ban megtalálhatjuk a fontosabb ágak címkéit. A CVSup konfigurációs állományában a címkéket a tag= elõtaggal kell bevezetni (így tehát a RELENG_4 címke hivatkozása tag=RELENG_4 lesz). Ne felejtsük el, hogy a Portgyûjtemény esetében csak tag=. mezõ megadásának van értelme. Igyekezzünk pontosan lemásolni a címkék neveit, mivel a CVSup nem képes megkülönböztetni az érvényes és az érvénytelen címkéket. Ha véletlen elírjuk a címkét, akkor a CVSup úgy fog viselkedni, mintha olyan érvényes címkére hivatkozhatunk volna, amihez nem tartoznak állományok. Ennek következtében pedig egyszerûen letörli a már meglevõ forrásainkat. Egy ág címkéjének megadása során általában az adott fejlesztési vonal legfrissebb verzióját kapjuk meg. Ha viszont az adott ág valamelyik korábbi változatára lenne szükségünk, akkor a értékmezõ felhasználásával meg tudjuk adni a hozzátartozó dátumot. Ennek mûködésérõl a &man.cvsup.1; man oldala részletesebben értekezik. A példában mi most a &os;-CURRENT verziót akarjuk letölteni. Ezért a következõ sort tesszük a supfile állományunk elejére: *default tag=. Ha nem adunk meg sem tag=, sem pedig date= mezõket, akkor egy fontos eset következik be. Ilyenkor ugyanis egy konkrét verzió helyett közvetlenül a szerver CVS repositoryjából kapjuk meg az állományokat, az összes kiegészítõ információjukkal együtt. A fejlesztõk általában ezt a típusú megoldást kedvelik, mivel így a saját rendszerükön is könnyen karban tudnak tartani egy példányt, amiben tudnak keresni a revíziók között és ki tudják kérni akár az állományok korábbi változatait is. Természetesen ennek függvényében jóval több tárhelyre van szükségük. Honnan akarjuk ezeket beszerezni? A host= mezõ beállításával közöljük a cvsup klienssel, honnan töltse le a frissítéseket. A CVSup tükrözések közül bármelyik megfelel erre a célra, habár leginkább azt érdemes választani, ami a kibertérben a hozzánk legközelebb esik. A példában most egy kitalált &os; terjesztési oldalt választunk, a cvsup99.FreeBSD.org-ot: *default host=cvsup99.FreeBSD.org A CVSup futtatása elõtt tehát ne felejtsük el megváltoztatni ezt a létezõ számítógép hálózati nevére. A cvsup futtatásakor a opció megadásával lehetõségünk ennek felülbírálására. Hova akarjuk rakni a számítógépünkön? A prefix= mezõ adja meg a cvsup számára, hogy hova tegye a kapott állományokat. A példában a forrásokat közvetlenül a forrásokat tároló központi könyvtárba, a /usr/src könyvtárba tettük. Mivel a src könyvtár neve már hallgatólagosan benne foglaltatik a letöltésre kiválasztott gyûjtemény nevében, ezért itt csak ennyit kell megadnunk: *default prefix=/usr Hova akarjuk rakni az állapotot tároló állományokat? A CVSup kliens egy bázisnak (base) nevezett könyvtárban folyamatosan fenntart bizonyos állományokban állapotokat (status file). Ezek a már letöltött állományok nyilvántartásával segítik a CVSup hatékony munkavégzését. Mi most a szabványos bázist, a /var/db könyvtárat fogjuk használni: *default base=/var/db Amennyiben még nem létezne a bázisként használni kívánt könyvtár, ideje létrehoznunk. A cvsup ugyanis egy nem létezõ könyvtár esetén nem lesz hajlandó mûködni. További beállítások a supfile állományban: Általában még egy sor szokott szerepelni a supfile állományokban: *default release=cvs delete use-rel-suffix compress A release=cvs mezõ jelzi, hogy a szervernek a &os; fõ CVS repositoryból kell kikeresnie az információkat. Tulajdonképpen majdnem mindig errõl van szó, és az itt megadható többi lehetõség ismertetése most egyébként is meghaladná a szakasz határait. A delete hatására a CVSup képes lesz állományokat törölni. Mindig érdemes megadnunk, hiszen a CVSup csak így tudja teljes mértékben frissentartani a forrásokat. A CVSup természetesen csak azokat az állományokat igyekszik letörölni, amelyek miatt valóban felelõs. A kóbor állományokat nem fogja bántani. A use-rel-suffix hatása egy igazi... Rejtély. Ha tényleg érdekel minket a mûködése, lapozzuk fel bátran a &man.cvsup.1; man oldalát. Nyugodtan adjuk meg és különösebben ne törõdjünk vele. A compress beállítás segítségével a kommunikációs csatornán vándorló adatokat tudjuk gzip-szerû módon tömöríteni. Ha a hálózati kapcsolatunk sebessége meghaladja a 1,5 Mbitet másodpercenként (T1), akkor ezt már nem érdemes használni, viszont minden más esetben lényeges gyorsulást hozhat. Összegezzük az eddigieket: Íme a példaként összerakott supfile állományunk teljes tartalma: *default tag=. *default host=cvsup99.FreeBSD.org *default prefix=/usr *default base=/var/db *default release=cvs delete use-rel-suffix compress src-all A <filename>refuse</filename> állomány Ahogy arról már korábban szó esett, a CVSup lehúzással frissít. Ez alapvetõen annyit jelent, hogy feltárcsázunk egy CVSup szervert, aki a következõt mondja nekünk: A következõket tudod tõlem letölteni..., amire a kliensünk ezt válaszolja: Rendben, akkor nekem kell ez, ez, ez meg ez. Alapértelmezés szerint a CVSup kliense azokat az állományokat fogja letölteni, amelyeket a konfigurációs állományban szereplõ gyûjtemények és címkék által megneveztünk. Ez azonban nem mindig felel meg az igényeinknek, különösen akkor, amikor a doc, ports vagy www fákat akarjuk letölteni — az emberek többsége ugyanis nem beszél négy vagy öt nyelven, ezért nincs is szükségük a nyelvfüggõ állományok letöltésére. A Portgyûjtemény letöltése során a ports-all helyett egyszerûen egyenként is felsorolhatjuk a számunkra érdekes kategóriákat (például ports-astrology, ports-biology stb). Azonban mivel a doc és a www fákhoz nincsenek nyelvfüggõ gyûjtemények, ezért elõ kell halásznunk a CVSup egyik remek funkcióját, a refuse állományt. A refuse állománnyal lényegében arra utasítjuk a CVSup alkalmazást, hogy a gyûjteményekbõl ne töltse le az összes állományt. Úgy is fogalmazhatnánk, hogy javaslatára a kliens visszautasít (refuse) bizonyos szervertõl érkezõ állományokat. Ezeket a visszautasításokat tároló refuse állományt a bázis/sup/ könyvtárban találhatjuk meg (illetve ha még nincsenek, akkor ide kell rakunk ezeket). Itt a bázis a supfile állományban megadott base= mezõre utal, ami a példánkban a /var/db könyvtár volt. Ennek megfelelõen tehát a refuse állomány a /var/db/sup/refuse lesz. A refuse állomány felépítése igen egyszerû: a letölteni nem kívánt állományok és könyvtárak neveit tartalmazza. Például ha az angolul mellett esetleg még beszélünk egy kevés németet is, de nincs szükségünk az angol dokumentáció német fordítására sem, akkor a következõket írjuk a refuse állományba: doc/bn_* doc/da_* doc/de_* doc/el_* doc/es_* doc/fr_* doc/hu_* doc/it_* doc/ja_* doc/mn_* doc/nl_* doc/no_* doc/pl_* doc/pt_* doc/ru_* doc/sr_* doc/tr_* doc/zh_* és így tovább a többi nyelvre is (melyeket a &os; CVS repository böngészésével deríthetjük ki). Ezzel az alkalmas funkcióval a lassú vagy drága internetes kapcsolattal rendelkezõ felhasználók nagyon jól tudnak gazdálkodni, mivel így nem kell letölteniük az egyáltalán nem használt állományokat. A refuse állományokról és a CVSup más hasonlóan elegáns funkcióiról a saját man oldaláról tudhatunk meg többet. A <application>CVSup</application> futtatása Most már készen állunk egy próba frissítés elvégzésére. A parancssorban nem sok mindent kell beírnunk ehhez: &prompt.root; cvsup supfile ahol a supfile a frissen létrehozott supfile állományunk neve lesz. Feltételezve, hogy a parancsot X11 alatt adtunk ki, az cvsup erre feldob egy grafikus ablakot néhány gombbal. Nyomjuk meg a go feliratú gombot és dõljünk hátra. Mivel a példában a /usr/src könyvtárunk frissítését állítottuk be, az állományok aktualizálásához szükséges jogosultságok biztosításához a cvsup programot root felhasználóként kell elindítanunk. Teljesen érthetõ, ha egy kicsit izgatottak vagyunk ezekben a pillanatokban, hiszen az elõbb hoztunk létre egy általunk eddig ismeretlen programhoz egy konfigurációs állományt. Ezért megemlítenénk, hogy ilyenkor elõször mindig próbáljuk ki a konfigurációkat, mielõtt azok bármilyen módosítást végeznének a fontos állományainkon. Ehhez hozzunk létre valahol egy üres könyvtárat, majd adjuk meg a parancssorban ennek a nevét: &prompt.root; mkdir /var/tmp/proba &prompt.root; cvsup supfile /var/tmp/proba Az így megadott könyvtárba kerülnek a frissítés eredményeképpen keletkezõ állományok. A CVSup elõször megvizsgálja a /usr/src könyvtárban található állományokat, viszont egyiküket sem módosítja vagy törli. A frissítések ehelyett a /var/tmp/proba/usr/src könyvtárba fognak kerülni. A CVSup emellett még a báziskönyvtárában tárolt állapotokat sem fogja megváltoztatni. A módosított állományok új változatai a megadott könyvtárba jönnek létre. Mivel a /usr/src könyvtárt ehhez csak olvasni fogjuk, a próba lefuttatásához még root felhasználónak sem kell lennünk. Ha nem használunk X11-et vagy egyszerûen csak nincs szükségünk a grafikus felületre, a parancssorban pár további opció megadásával így is kiadhatjuk a cvsup parancsot: &prompt.root; cvsup -g -L 2 supfile A hatására a CVSup nem hozza be a grafikus felületét. Ha nem talál X11-et, akkor ez természetesen automatikus, de ellenkezõ esetben ezt is meg kell adnunk. Az megadásával a CVSup az összes elvégzendõ frissítésrõl részletes értesítést ad. A részletességnek három foka van, -tól indulva egészen -ig. Itt az alapértelmezett érték a 0, amivel a hibaüzenetek kivételével egyetlen üzenetet sem kapunk. Rengeteg egyéb beállítás adható még meg, ezeket a cvsup -H kiadásával kérdezhetjük le. A beállítások pontosabb leírását a man oldalon találjuk meg. Miután elégedetten tapasztaltuk, hogy a frissítés remekül mûködik, a &man.cron.8; segítségével próbáljuk meg az egész folyamatot önmûködövé tenni a CVSup szabályos idõközönkénti futtatásával. Ekkor viszont magától értetõdik, hogy a CVSup számára ne engedjük használni a grafikus felületet. A <application>CVSup</application> állománygyûjteményei A CVSup révén elérhetõ állománygyûjtemények egy hierarchikus rendszert alkotnak. Van néhány nagyobb állománygyûjtemény, amelyek kisebb al-állománygyûjteményekre bonthatóak. A nagyobb gyûjtemények letöltése ezért a kisebb algyûjtemények letöltésével egyenlõ. A gyûjtemények közt fennálló hierarchikus rendszer a lentebb szereplõ lista behúzásaiban érhetõ tetten. A leggyakrabban használt gyûjtemények a src-all és a ports-all neveket viselik. A többi gyûjteményt általában csak kevesen és csak speciális célokra használják, ezért egyes tükrözéseken nem feltétlenül találjuk meg mindegyiküket. cvs-all release=cvs A &os; fõ CVS repositoryja, beleértve a titkosításhoz tartozó kódokat is. distrib release=cvs A &os; terjesztéséhez és tükrözéséhez kapcsolódó állományok. doc-all release=cvs A &os; kézikönyvének és a többi dokumentáció forrásai. Nem tartalmazza a &os; honlapjának forrásait. ports-all release=cvs A &os; portgyûjteménye. Ha nem akarjuk a ports-all egészét (vagyis a teljes portfát) frissíteni, csak a lentebb szereplõ egyes algyûjteményeket letölteni, akkor soha ne feledkezzünk meg a ports-base megadásáról! Amikor valami változik a portok mûködésében, akkor a ports-base által képviselt algyûjteményben szereplõ állományokat igen gyorsan elkezdik használni a valódi portok. Ezért ha csak a valódi portokat frissítjük, amelyek viszont igényt tartanak néhány újabb funkcióra is, akkor könnyen fordítási hibára vagy különbözõ rejtélyes hibaüzenetekbe futhatunk. Emiatt legeslegelõször mindig tegyünk róla, hogy a ports-base algyûjteményünk a lehetõ legfrissebb legyen. Ha a ports/INDEX állomány egy saját példányát kívánjuk létrehozni, akkor ahhoz a ports-all gyûjteményt (tehát a teljes portfát) le kell kérnünk. A ports/INDEX állományt a portfa egy része alapján nem készíthetjük el. Errõl bõvebben lásd a GYIK-ot. ports-accessibility release=cvs A fogyatékos felhasználókat segítõ szoftverek. ports-arabic release=cvs Arab nyelvi támogatás. ports-archivers release=cvs Archiváló eszközök. ports-astro release=cvs Csillagászathoz tartozó portok. ports-audio release=cvs Hangtámogatás. ports-base release=cvs A Portgyûjtemény saját infrastruktúrája — az Mk/, Tools/ és /usr/ports különféle alkönyvtáraiban elhelyezkedõ állományok. Ne hagyjuk figyelmen kívül a fenti fontos figyelmeztetést sem: ezt az algyûjteményt mindig a &os; Portgyûjteményével együtt frissítsük! ports-benchmarks release=cvs Teljesítménytesztek. ports-biology release=cvs Biológia. ports-cad release=cvs Számítógépes tervezõeszközök (CAD). ports-chinese release=cvs Kínai nyelvi támogatás. ports-comms release=cvs Kommunikációs szoftverek. ports-converters release=cvs Karakterkódolások közti átalakítók. ports-databases release=cvs Adatbázisok. ports-deskutils release=cvs A számítógép feltalálása elõtt is már létezõ eszközök. ports-devel release=cvs Fejlesztõeszközök. ports-dns release=cvs Névfeloldással kapcsolatos szoftverek. ports-editors release=cvs Szövegszerkesztõk. ports-emulators release=cvs Más operációs rendszerek emulátorai. ports-finance release=cvs Pénzügyi, gazdasági és hasonló alkalmazások. ports-ftp release=cvs FTP kliensek és szerverek. ports-games release=cvs Játékok. ports-german release=cvs Német nyelvi támogatás. ports-graphics release=cvs Grafikus segédeszközök. ports-hebrew release=cvs Héber nyelvi támogatás. ports-hungarian release=cvs Magyar nyelvi támogatás. ports-irc release=cvs IRC-vel kapcsolatos programok. ports-japanese release=cvs Japán nyelvi támogatás. ports-java release=cvs &java; segédeszközök. ports-korean release=cvs Koreai nyelvi támogatás. ports-lang release=cvs Programozási nyelvek. ports-mail release=cvs Levelezõ programok. ports-math release=cvs Numerikus számításokkal foglalkozó programok. ports-mbone release=cvs MBone alkalmazások. ports-misc release=cvs Egyéb segédprogramok. ports-multimedia release=cvs Multimediás szoftverek. ports-net release=cvs Hálózati szoftverek. ports-net-im release=cvs Üzenetküldõ (Instant Messaging, IM) szoftverek. ports-net-mgmt release=cvs Hálózati karbantartó szoftverek. ports-net-p2p release=cvs Egyenrangú (Peer to Peer, P2P) hálózatok. ports-news release=cvs USENET hírszoftverek. ports-palm release=cvs A Palm sorozat szoftveres támogatása. ports-polish release=cvs Lengyel nyelvi támogatás. ports-ports-mgmt release=cvs A portok és csomagok karbantartását végzõ segédeszközök. ports-portuguese release=cvs Portugál nyelvi támogatás. ports-print release=cvs Nyomdai programok. ports-russian release=cvs Orosz nyelvi támogatás. ports-science release=cvs Tudományos programok. ports-security release=cvs Biztonsági segédprogramok. ports-shells release=cvs Parancsértelmezõk. ports-sysutils release=cvs Rendszerprogramok. ports-textproc release=cvs Szövegfeldolgozást segítõ eszközök (kivéve az asztali kiadványszerkesztést). ports-ukrainian release=cvs Ukrán nyelvi támogatás. ports-vietnamese release=cvs Vietnámi nyelvi támogatás. ports-www release=cvs A világhálóhoz tartozó szoftverek. ports-x11 release=cvs Az X Window System mûködését segítõ portok. ports-x11-clocks release=cvs X11 órák. ports-x11-drivers release=cvs X11 meghajtók. ports-x11-fm release=cvs X11 állománykezelõk. ports-x11-fonts release=cvs X11 betûtípusok és a hozzájuk tartozó segédprogramok. ports-x11-toolkits release=cvs X11 eszközrendszerek. ports-x11-servers release=cvs X11 szerverek. ports-x11-themes release=cvs X11 témák. ports-x11-wm release=cvs X11 ablakkezelõk. projects-all release=cvs A &os; projektek forrásainak repositoryja. src-all release=cvs A &os; fontosabb forrásai, a titkosításhoz tartozó kódokkal együtt. src-base release=cvs A /usr/src könyvtárban levõ egyéb állományok. src-bin release=cvs Az egyfelhasználós módban használható segédeszközök (/usr/src/bin). src-cddl release=cvs A CDDL licenc szerint terjesztett segédprogramok és függvénykönyvtárak (/usr/src/cddl). src-contrib release=cvs A &os; Projekten kívül fejlesztett segédprogramok és függvénykönyvtárak, viszonylag kevés módosítással (/usr/src/contrib). src-crypto release=cvs A &os; Projekten kívül fejlesztett, titkosítással kapcsolatos segédprogramok és függvénykönyvtárak, viszonylag kevés módosítással (/usr/src/crypto). src-eBones release=cvs Kerberos és DES (/usr/src/eBones). A &os; jelenlegi változatai nem használják. src-etc release=cvs A rendszer beállításait tartalmazó állományok (/usr/src/etc). src-games release=cvs Játékok (/usr/src/games). src-gnu release=cvs A GPL licenc szerint terjesztett segédprogramok (/usr/src/gnu). src-include release=cvs (C nyelvi) Header állományok (/usr/src/include). src-kerberos5 release=cvs A Kerberos5 biztonsági csomag (/usr/src/kerberos5). src-kerberosIV release=cvs A KerberosIV biztonsági csomag (/usr/src/kerberosIV). src-lib release=cvs Függvénykönyvtárak (/usr/src/lib). src-libexec release=cvs Más programok által futtatott rendszerprogramok (/usr/src/libexec). src-release release=cvs A &os; kiadások elkészítéséhez szükséges állományok (/usr/src/release). src-rescue release=cvs Statikusan linkelt programok vészhelyzet esetére, lásd &man.rescue.8; (/usr/src/rescue). src-sbin release=cvs Egyfelhasználós módban használható rendszereszközök (/usr/src/sbin). src-secure release=cvs Titkosítással foglalkozó függvénykönyvtárak és parancsok (/usr/src/secure). src-share release=cvs Több rendszer között megosztható állományok (/usr/src/share). src-sys release=cvs A rendszermag (/usr/src/sys). src-sys-crypto release=cvs A rendszermagban levõ titkosítással foglalkozó kód (/usr/src/sys/crypto). src-tools release=cvs A &os; karbantartására való különbözõ segédprogramok (/usr/src/tools). src-usrbin release=cvs Felhasználói segédprogramok (/usr/src/usr.bin). src-usrsbin release=cvs Rendszerszintû segédprogramok (/usr/src/usr.sbin). www release=cvs A &os; Projekt honlapjának forráskódja. distrib release=self A CVSup szerver saját konfigurációs állományai. A CVSup tükrözései használják. gnats release=current A GNATS hibanyilvántartó adatbázis. mail-archive release=current A &os; levelezési listáinak archívuma. www release=current A &os; Projekt honlapjának generált állományai (de nem a forrásai). A WWW tükrözések használják. Bõvebb információk A CVSup részletesebb bemutatását és a hozzátartozó GYIK-ot A CVSup honlapján találjuk meg. A CVSup &os;-re vonatkozó tárgyalása a &a.hackers;n történik. Itt és az &a.announce;n jelentik be a szoftver újabb változatait. A CVSup alkalmazással kapcsolatos kérdéseket és hibajelentéseket illetõen a CVSup GYIK-ot érdemes megnéznünk. CVSup oldalak A &os; CVSup szerverei az alábbi oldalakon érhetõek el: &chap.mirrors.cvsup.inc; CVS címkék Meg kell adnunk egy revízió címkéjét, amikor a cvs vagy CVSup használatával letöltjük vagy frissítjük a forrásokat. A revíziós címkék a &os; egyik fejlesztési irányát vagy egy adott idõpontbeli állapotát hivatkozzák. Az elõbbi egy ág címkéje, míg az utóbbi pedig egy kiadás címkéje. Az ágak címkéi A HEAD kivételével (amely mindig egy érvényes címke) az összes címke csak a src/ fára vonatkozik. A ports/, doc/ és www/ fák nem tartalmaznak ágakat. HEAD A fõ fejlesztési ág, avagy a &os;-CURRENT szimbolikus neve. Ha nem adunk meg revíziót, ez lesz az alapértelmezés. A CVSup számára ezt . címke jelzi (itt most nem mondatvégi pontot jelöli, hanem a . karaktert). A CVS számára ez lesz az alapértelmezett érték, ha nem adunk meg konkrét revíziós címkét. Többnyire nem túlzottan jó ötlet egy STABLE változatot használó gépen a CURRENT verziójú források kikérése, kivéve hacsak nem ez a szándékunk. RELENG_7 A FreeBSD-7.X fejlesztési ága, más néven a FreeBSD 7-STABLE RELENG_7_2 A FreeBSD-7.2 kiadás ága, ahová csak a biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_7_1 A FreeBSD-7.1 kiadás ága, ahová csak a biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_7_0 A FreeBSD-7.0 kiadás ága, ahová csak a biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_6 A FreeBSD-6.X fejlesztési ága, más néven a FreeBSD 6-STABLE RELENG_6_4 A FreeBSD-6.4 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_6_3 A FreeBSD-6.3 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_6_2 A FreeBSD-6.2 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_6_1 A FreeBSD-6.1 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_6_0 A FreeBSD-6.0 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_5 A FreeBSD-5.X fejlesztési ág, más néven a FreeBSD 5-STABLE. RELENG_5_5 A FreeBSD-5.5 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_5_4 A FreeBSD-5.4 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_5_3 A FreeBSD-5.3 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_5_2 A FreeBSD-5.2 és FreeBSD-5.2.1 kiadások ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_5_1 A FreeBSD-5.1 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_5_0 A FreeBSD-5.0 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_4 A FreeBSD-4.X fejlesztési ága, más néven a FreeBSD 4-STABLE. RELENG_4_11 A FreeBSD-4.11 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_4_10 A FreeBSD-4.10 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_4_9 A FreeBSD-4.9 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_4_8 A FreeBSD-4.8 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_4_7 A FreeBSD-4.7 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_4_6 A FreeBSD-4.6 és FreeBSD-4.6.2 kiadások ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_4_5 A FreeBSD-4.5 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_4_4 A FreeBSD-4.4 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_4_3 A FreeBSD-4.3 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_3 A FreeBSD-3.X fejlesztési ága, más néven a 3.X-STABLE. RELENG_2_2 A FreeBSD-2.2.X fejlesztési ága, más néven a 2.2-STABLE. Ez az ág manapság már elavult. A kiadások címkéi Ezek a címkék a &os; egyes kiadásainak dátumára hivatkoznak. Egy kiadás elõkészítésének és terjesztésének folyamatáról részleteiben a kiadásokat összefoglaló lapról és a kiadások építésérõl szóló cikkbõl tájékozódhatunk. Az src fában RELENG_ kezdetû címkéket találunk. A ports és doc fákban a címkék nevei a RELEASE elõtaggal kezdõdnek. Végezetül a www fában nincsenek kiadásokhoz tartozó címkék. RELENG_7_2_0_RELEASE FreeBSD 7.2 RELENG_7_1_0_RELEASE FreeBSD 7.1 RELENG_7_0_0_RELEASE FreeBSD 7.0 RELENG_6_4_0_RELEASE FreeBSD 6.4 RELENG_6_3_0_RELEASE FreeBSD 6.3 RELENG_6_2_0_RELEASE FreeBSD 6.2 RELENG_6_1_0_RELEASE FreeBSD 6.1 RELENG_6_0_0_RELEASE FreeBSD 6.0 RELENG_5_5_0_RELEASE FreeBSD 5.5 RELENG_5_4_0_RELEASE FreeBSD 5.4 RELENG_4_11_0_RELEASE FreeBSD 4.11 RELENG_5_3_0_RELEASE FreeBSD 5.3 RELENG_4_10_0_RELEASE FreeBSD 4.10 RELENG_5_2_1_RELEASE FreeBSD 5.2.1 RELENG_5_2_0_RELEASE FreeBSD 5.2 RELENG_4_9_0_RELEASE FreeBSD 4.9 RELENG_5_1_0_RELEASE FreeBSD 5.1 RELENG_4_8_0_RELEASE FreeBSD 4.8 RELENG_5_0_0_RELEASE FreeBSD 5.0 RELENG_4_7_0_RELEASE FreeBSD 4.7 RELENG_4_6_2_RELEASE FreeBSD 4.6.2 RELENG_4_6_1_RELEASE FreeBSD 4.6.1 RELENG_4_6_0_RELEASE FreeBSD 4.6 RELENG_4_5_0_RELEASE FreeBSD 4.5 RELENG_4_4_0_RELEASE FreeBSD 4.4 RELENG_4_3_0_RELEASE FreeBSD 4.3 RELENG_4_2_0_RELEASE FreeBSD 4.2 RELENG_4_1_1_RELEASE FreeBSD 4.1.1 RELENG_4_1_0_RELEASE FreeBSD 4.1 RELENG_4_0_0_RELEASE FreeBSD 4.0 RELENG_3_5_0_RELEASE FreeBSD-3.5 RELENG_3_4_0_RELEASE FreeBSD-3.4 RELENG_3_3_0_RELEASE FreeBSD-3.3 RELENG_3_2_0_RELEASE FreeBSD-3.2 RELENG_3_1_0_RELEASE FreeBSD-3.1 RELENG_3_0_0_RELEASE FreeBSD-3.0 RELENG_2_2_8_RELEASE FreeBSD-2.2.8 RELENG_2_2_7_RELEASE FreeBSD-2.2.7 RELENG_2_2_6_RELEASE FreeBSD-2.2.6 RELENG_2_2_5_RELEASE FreeBSD-2.2.5 RELENG_2_2_2_RELEASE FreeBSD-2.2.2 RELENG_2_2_1_RELEASE FreeBSD-2.2.1 RELENG_2_2_0_RELEASE FreeBSD-2.2.0 AFS oldalak A &os; a következõ szerverein érhetõ el AFS: Svédország Az állományok a következõ helyen érhetõek el: /afs/stacken.kth.se/ftp/pub/FreeBSD/ stacken.kth.se # Stacken Computer Club, KTH, Svédország 130.237.234.43 #hot.stacken.kth.se 130.237.237.230 #fishburger.stacken.kth.se 130.237.234.3 #milko.stacken.kth.se Karbantartó: ftp@stacken.kth.se Rsync oldalak A most következõ oldalakon a &os;-t érhetjük el az rsync protokollal. Az rsync segédprogram mûködésében leginkább a &man.rcp.1; parancshoz hasonlít, de sokkal több beállítással rendelkezik, és az rsync távoli frissítéseket kezelõ protokollja segítségével csak az állományok csoportjai között levõ eltéréseket küldi át, amivel a hálózaton keresztüli szinkronizáció rendkívül felgyorsítható. Ez olyankor jelent számunkra a legtöbbet, ha a &os; FTP szerverének vagy CVS repositoryjának egyik tükrözését tartjuk karban. Az rsync több operációs rendszerre is elérhetõ, és &os;-n a net/rsync port vagy csomag tartalmazza. Cseh Köztársaság rsync://ftp.cz.FreeBSD.org/ Elérhetõ gyûjtemények: ftp: a &os; FTP szerverének részleges tükrözése. FreeBSD: a &os; FTP szerverének teljes tükrözése. Hollandia rsync://ftp.nl.FreeBSD.org/ Elérhetõ gyûjtemények: FreeBSD: a &os; FTP szerverének teljes tükrözése. Oroszország rsync://cvsup4.ru.FreeBSD.org Elérhetõ gyûjtemények: FreeBSD-gnats: A GNATS hibanyilvántartó adatbázis. Tajvan rsync://ftp.tw.FreeBSD.org/ rsync://ftp2.tw.FreeBSD.org/ rsync://ftp6.tw.FreeBSD.org/ Elérhetõ gyûjtemények: FreeBSD: a &os; FTP szerverének teljes tükrözése. Egyesült Királyság rsync://rsync.mirrorservice.org/ Elérhetõ gyûjtemények: sites/ftp.freebsd.org: a &os; FTP szerverének teljes tükrözése. Amerikai Egyesült Államok rsync://ftp-master.FreeBSD.org/ Ezt a szervert csak az elsõdleges &os; tükrözéseknek szabad használniuk. Elérhetõ gyûjtemények: FreeBSD: a &os; FTP szerverének központi archívuma. acl: a &os; központi ACL listája. rsync://ftp13.FreeBSD.org/ Elérhetõ gyûjtemények: FreeBSD: a &os; FTP szerver teljes tükrözése.