diff --git a/hu_HU.ISO8859-2/articles/dialup-firewall/Makefile b/hu_HU.ISO8859-2/articles/dialup-firewall/Makefile index 91fdd00d2b..93c2dae7e7 100644 --- a/hu_HU.ISO8859-2/articles/dialup-firewall/Makefile +++ b/hu_HU.ISO8859-2/articles/dialup-firewall/Makefile @@ -1,24 +1,24 @@ # $FreeBSD$ # # Article: Dialup firewalling with FreeBSD # # Tidy messes up iso-8859-2 characters # NO_TIDY= yes -MAINTAINER= pali.gabor@gmail.com +MAINTAINER= pgj@FreeBSD.org DOC?= article FORMATS?= html INSTALL_COMPRESSED?= gz INSTALL_ONLY_COMPRESSED?= SRCS= article.sgml URL_RELPREFIX?= ../../../.. DOC_PREFIX?= ${.CURDIR}/../../.. .include "${DOC_PREFIX}/share/mk/doc.project.mk" diff --git a/hu_HU.ISO8859-2/articles/dialup-firewall/article.sgml b/hu_HU.ISO8859-2/articles/dialup-firewall/article.sgml index 6fa0d72216..a515726a86 100644 --- a/hu_HU.ISO8859-2/articles/dialup-firewall/article.sgml +++ b/hu_HU.ISO8859-2/articles/dialup-firewall/article.sgml @@ -1,410 +1,410 @@ %articles.ent; ]> + Translated by: PALI, Gabor + Original Revision: 1.42 -->
Tûzfal létrehozása betárcsázós kapcsolatokhoz &os;-vel Marc Silver
marcs@draenor.org
 $FreeBSD$ &tm-attrib.freebsd; &tm-attrib.general; Ebben a cikkben bemutatjuk, hogyan lehet beállítani tûzfalat a PPP-típusú kapcsolatokhoz a &os; valamint az IPFW segítségével, különös tekintettel az olyan esetekre, ahol dinamikusan kiosztott IP-címmel használjuk a rendszert. Ez a leírás azonban nem tartalmazza magának a PPP-kapcsolatnak a beállítását. A PPP-kapcsolatok létrehozásához kérjük tekintse át a &man.ppp.8; man oldalt. Fordította: &a.hu.pgj; Bevezetés A leírásban felvázoljuk azokat a lépéseket, amelyek szükségesek az Internet szolgáltatónk által dinamikusan kiosztott IP címmel rendelkezõ rendszerünk tûzfalának kiépítéséhez. Habár ezen cikk szerzõje minden megtett, hogy ez a leírás minél hasznosabb és pontosabb legyen, örömmel várja az esetleges megjegyzéseket és javaslatokat a marcs@draenor.org címen. Beállítások a rendszermagban Az IPFW használatához bele kell fordítani némi támogatást a rendszer magjába. Ha többet szeretne tudni a rendszermag újrafordításáról, kérjük, olvassa el a a rendszermag beállításáról szóló fejezetet a Kézikönyvben. Az IPFW támogatásához az alábbi sorokat kell még hozzáírni a rendszermag konfigurációs állományához: options IPFIREWALL Elérhetõvé teszi a rendszermag tûzfalért felelõs rutinjait. A cikk a &os; 5.X-es verziójának használatát feltételezi. Azoknak a felhasználóknak, akik még a &os; 4.X-es verzióját használják, a rendszermagjukat a IPFW2 támogatással kell újrafordítaniuk. A &os; 4.X felhasználóknak továbbá javasolt elolvasniuk ezzel kapcsolatosan a &man.ipfw.8; man oldalt, kiemelten odafigyelve a IPFW2 HASZNÁLATA A &os;-STABLE-ben fejezetre. options IPFIREWALL_VERBOSE Naplózott csomagok küldése a rendszernaplóba. options IPFIREWALL_VERBOSE_LIMIT=500 Korlátozza az egyezõ tartalmú sorok naplózásának mennyiségét. Ezzel lehetõvé válik, hogy a rendszernapló elárasztásának kockázata nélkül naplózzuk a tûzfal minden egyes tevékenységét, például egy "denial of service" (DoS) típusú támadás esetén. Itt az 500 egy viszonylag jó kiindulási érték lehet, de nyugodtan változtathajuk igényeink szerint. Amikor a rendszermag újrafordítása befejezõdött, ne indítsuk újra egybõl a rendszerünket. Ha így cselekszünk, könnyedén kizárhatjuk magunkat belõle! Csak azután szabad újraindítanunk és ezzel mûködésbe hozni a tûzfalat, miután a hozzátartozó szabályok a megfelelõ helyre kerültek és minden hozzájuk kapcsolódó konfigurációs állományt megfelelõen beállítottunk. Az <filename>/etc/rc.conf</filename> módosítása a tûzfal betöltéséhez Az /etc/rc/rc.conf konfigurációs állományt kell némileg átírnunk a tûzfal betöltéséhez, valamint a hozzátartozó szabályokat tartalmazó állomány helyének megadásához. Adjuk tehát hozzá az alábbi sorokat a /etc/rc/rc.conf-hoz: firewall_enable="YES" firewall_script="/etc/firewall/fwrules" Ha többet szeretne tudni ezeknek a soroknak a jelentésérõl, akkor nézze át a /etc/defaults/rc.conf állományt és olvassa el a &man.rc.conf.5; man oldalt. A PPP-ben levõ címfordítás bekapcsolása Amennyiben a helyi hálózatunkban fellelhetõ további kliensek számára is szeretnénk elérhetõvé tenni az Internetet az átjárónkon át, szükségünk lesz a PPP-ben található hálózati címfordítás (Network Address Translation, NAT) beindítására. Ezt az /etc/rc.conf-ben a következõ sorok hozzáadásával tehetjük meg: ppp_enable="YES" ppp_mode="auto" ppp_nat="YES" ppp_profile="internet_beallitasok" Ne felejtsük el kicserélni az internet_beallitasok-at saját betárcsázós beállításait tartalmazó állomány nevére! A tûzfal szabályai Most fogjuk megadni a rendszerünk tûzfalának szabályait. Az itt ismertetésre kerülõ szabályok egy olyan általános sablont kívánnak bemutatni, amely a legtöbb betárcsázós felhasználó számára megfelelnek. Habár kétségtelen, hogy nem fogja mindenki igényeit tökéletesen kielégíteni, azonban segít megmutatni az IPFW mûködésének alapelveit és könnyedén tovább is fejleszthetõ. Elsõként kezdjük a "zárt tûzfal" alapjaival. A zárt tûzfal lényegében azon a feltevésen alapszik, hogy alapvetõen mindent kizárunk a rendszerbõl. Ezt követõen a rendszergazda egyesével megadhatja azokat szabályokat, amelyeket engedélyezni kíván valamit. A szabályok közül elöszõr mindig azokat adjuk meg, amikkel engedélyezünk, majd azokat, amikkel tiltunk. Az alapfeltételezés szerint tehát a szabályokkal megadunk mindent, amit engedélyezünk a tûzfalon, és minden más pedig automatikusan tiltásra kerül. Ezt követõen hozzunk létre egy könyvtárat, ahol majd tárolni a fogjuk a tûzfalunk beállításait. Ebben a példában a /etc/firewall/ könyvtárat fogjuk használni erre a célra. Lépjünk be ebbe a könyvtárba és hozzunk létre egy fwrules nevû állományt, ahogy azt az rc.conf-ban is megadtuk. Természetesen ez az elnevezés sem kötött, nyugodtan megváltoztathatjuk bármire. A leírás pusztán csak egy példát ad erre. Most pedig nézzünk egy megjegyzésekkel tûzdelt szabályokat tartalmazó állományt: # Definiálunk egy parancsot a tûzfalat összeállító program elérésére # (ld. /etc/rc.firewall). Remélhetõleg így könnyebb is lesz olvasni. fwcmd="/sbin/ipfw" # Megadjuk a külsõ hálózati csatolót. Ha felhasználói ppp-t használunk, # akkor ez valószínûleg a tun0 lesz. oif="tun0" # Megadjuk a belsõ hálózati csatolót. Ez többnyire (a helyi hálózaton # is elerhetõ) hálózati kártyánk lesz. Mindenképpen ellenõrizzük, hogy # jól adtuk-e meg! iif="fxp0" # Töröltessünk a rendszerben jelenleg érvényben levõ össze szabályt, # még mielõtt betöltenénk a sajátjainkat. $fwcmd -f flush # Ellenõrizzük az összes csomag állapotát. $fwcmdl add check-state # Tiltsuk le az elrejtést a külsõ csatolón. $fwcmd add deny ip from any to any in via $oif not verrevpath # Engedélyezzünk minden általunk kezdeményezett kapcsolatot és # tartsuk is meg az állapotukat. Ellenben tiltsunk minden olyat, # amihez nincs semmilyen dinamikus szabály. $fwcmd add allow ip from me to any out via $oif keep-state $fwcmd add deny tcp from any to any established in via $oif # Engedélyezzünk minden kapcsolatot a helyi hálózaton. $fwcmd add allow ip from any to any via $iif # Engedélyezzük a helyi (gépen belüli) forgalmat. $fwcmd add allow all from any to any via lo0 $fwcmd add deny all from any to 127.0.0.0/8 $fwcmd add deny ip from 127.0.0.0/8 to any # Engedélyezzük az Internetrõl hozzánk látogatóknak, hogy elérhessék # a 22-es ill. a 80-as portokat. Így ez a példa kifejezetten az SSH # (sshd) es HTTP (webszerver) típusú kapcsolatokat engedélyezi. $fwcmd add allow tcp from any to me dst-port 22,80 in via $oif setup keep-state # Engedélyezzük az ICMP csomagokat: vegyük ki a 8-as típust, ha nem # szeretnénk a gépünket pingek által elérhetõvé tenni. $fwcmd add allow icmp from any to any via $oif icmptypes 0,3,8,11,12 # Tiltsunk és naplózzunk minden mást. $fwcmd add deny log ip from any to any Most már van egy teljesen mûködõképes tûzfalunk, amely csak és kizárólag a 22-es, 80-es portokon enged kapcsolatot létesíteni, és minden egyéb próbálkozást naplóz. Így már nyugodtan újraindíthatjuk a rendszerünket, és ezt követõen a tûzfalunk magától elindul és a hozzá tartozó szabályrendszer betöltõdik. Ha bármilyen hibát találna benne vagy problémába ütközne a használata során, esetleg valamilyen építõ jellegû javaslata van, kérem, keressen meg e-mailben! Kérdések limit 500 reached on entry 2800. Ilyen és ehhez hasonló hibaüzeneteket kapok, miután a számítógépem abbahagyja a szabályhoz tartozó eldobott csomagok naplózását. Mûködik még ilyenkor ea tûzfalam? Ez csupán annyit jelent, hogy az adott szabályt elérte a hozzátartozó maximális naplóbejegyzést. A szabály maga még mindig aktív, viszont addig nem fog tudni naplózni, amíg nem töröljük valahogy a bejegyzésszámlálóját. Például így lehet törölni az említett számlálót: &prompt.root; ipfw resetlog Vagy úgy is elkerülhetjük ezt a hibaüzenetet, ha növeljük a szabályhoz tartozó naplóbejegyzések számát a rendszermag konfigurációs állományában, az beállítás megváltoztatásával, a fentebb leírt módon. A rendszermag újrafordítása eacute;s a rendszer újraindítása nélkül is megváltoztatható ez a korlát, a net.inet.ip.fw.verbose_limit &man.sysctl.8; használatával. Valami nem stimmel. Követtem a leírásban szereplõ utasításokat pontról pontra, de kizártam magamat. A leírás feltételezi, hogy felhasználói ppp-t használunk, és ezért a megadott szabályok a tun0 (amely megfelel a &man.ppp.8; (azaz felhasználói ppp, user-ppp) által létrehozott elsõ kapcsolatnak) felületen keresztül mûködnek. A további kapcsolatok rendre a tun1, tun2 stb. neveket használják. Továbbá érdemes megjegyezni, hogy a &man.pppd.8; ehelyett a ppp0 felületet használja, így tehát ha a PPP-kapcsolatot a &man.pppd.8;-al indítottuk el, akkor a tun0 neveket mindenhol ppp0 nevekre kell cserélni. Íme egy példa arra, hogyan írjuk át gyorsan a szabályainkat ilyen alakúra (az eredeti szabályokat pedig fwrules_tun0 néven elmentjük): &prompt.user; cd /etc/firewall /etc/firewall&prompt.user; su Password: /etc/firewall&prompt.root; mv fwrules fwrules_tun0 /etc/firewall&prompt.root; cat fwrules_tun0 | sed s/tun0/ppp0/g > fwrules Legkönnyebben úgy tudjuk kideríteni, hogy van &man.ppp.8;-t vagy éppen &man.pppd.8;-t használunk, hogy átnézzük az &man.ifconfig.8; kimenetét, amikor már van aktív kapcsolatunk. Például, ha a kapcsolatot a &man.pppd.8;-vel hoztuk létre, akkor valami ilyesmit kellene látnunk (csak a lényeget mutatjuk): &prompt.user; ifconfig (kimarad...) ppp0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1524 inet xxx.xxx.xxx.xxx --> xxx.xxx.xxx.xxx netmask 0xff000000 (kimarad...) Másrészt viszont a &man.ppp.8;-vel (vagyis felhasználói ppp-vel) létesített kapcsolatok esetén nagyjából ezt: &prompt.user; ifconfig (kimarad...) ppp0: flags=8010<POINTOPOINT,MULTICAST> mtu 1500 (kimarad...) tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1524 (IPv6 kimarad...) inet xxx.xxx.xxx.xxx --> xxx.xxx.xxx.xxx netmask 0xffffff00 Opened by PID xxxxx (kimarad...)
diff --git a/hu_HU.ISO8859-2/articles/laptop/Makefile b/hu_HU.ISO8859-2/articles/laptop/Makefile index 9d1a032e48..f0105dc108 100644 --- a/hu_HU.ISO8859-2/articles/laptop/Makefile +++ b/hu_HU.ISO8859-2/articles/laptop/Makefile @@ -1,24 +1,24 @@ # $FreeBSD$ # # Article: FreeBSD on Laptops # # Tidy messes up iso-8859-2 characters # NO_TIDY= yes -MAINTAINER= pali.gabor@gmail.com +MAINTAINER= pgj@FreeBSD.org DOC?= article FORMATS?= html INSTALL_COMPRESSED?= gz INSTALL_ONLY_COMPRESSED?= SRCS= article.sgml URL_RELPREFIX?= ../../../.. DOC_PREFIX?= ${.CURDIR}/../../.. .include "${DOC_PREFIX}/share/mk/doc.project.mk" diff --git a/hu_HU.ISO8859-2/articles/laptop/article.sgml b/hu_HU.ISO8859-2/articles/laptop/article.sgml index 0149dccf54..69b4d6d67e 100644 --- a/hu_HU.ISO8859-2/articles/laptop/article.sgml +++ b/hu_HU.ISO8859-2/articles/laptop/article.sgml @@ -1,441 +1,441 @@ %articles.ent; ]> + Translated by: PALI, Gabor + Original Revision: 1.25 -->
&os; laptopon $FreeBSD$ A &os; néhány buktatótól eltekintve remekül mûködik a legtöbb laptopon. A következõkben nagyító alá vesszük azokat a problémákat, amelyek a &os; laptopon történõ futtatását akadályozhatják, az asztali számítógépektõl eltérõ hardverkövetelményekre vonatkozóan. Fordította: &a.hu.pgj; &tm-attrib.freebsd; &tm-attrib.linux; &tm-attrib.microsoft; &tm-attrib.general; A &os;-t gyakran az Internetes kiszolgálók operációs rendszerének vélik, ám éppen ugyanolyan jól alkalmazható egy asztali számítógépre is, és ha egy laptopon kívánjuk használni, továbbra is élvezhetjük a korábban megszokott elõnyeit: rendszerezett felépítés, könnyû karbantarthatóság és frissíthetõség, a programok telepítéséhez kidolgozott port- és csomagkezelõ rendszer, és így tovább. (Az egyéb elõnyei, mint mondjuk a megbízhatóság, kiemelkedõ hálózati teljesítmény, nagy terhelés alatti teljesítmény, természetesen nem feltétlenül szembetûnõek egy laptopon.) Azonban a laptopokra történõ telepítése gyakran felvet olyan gondokat, amelyek az asztali számítógépek esetén nem jelennek meg, és ezért általában nem is kerülnek szóba (a laptopok ugyanis az asztali számítógépekénél jóval nagyobb mértékben µsoft.windows;-ra vannak tervezve). Ebben a leírásban szeretnénk megtárgyalni ezeket a problémákat. Néhányan ugyan már elõzetesen feljegyezték a &os;-vel kapcsolatos tapasztalataikat bizonyos modellek esetén olyan oldalakon, amelyek nem részei a &os; hivatalos dokumentációjának. Emiatt könnyen elõfordulhat, hogy úgy is találhatunk hasznos információkat a témában, ha egyszerûen rákeresünk valamelyik népszerû keresõben a laptopunk modelljére és a &os; szóra. Ezen kívül létezik még egy külön &os;-hez kialakított Internetes adatbázis, ahol a különféle laptopok hardveres problémáihoz találhatunk segítséget: ez A &os; laptop kompabilitási lista. Amennyiben szeretnénk felvenni a kapcsolatot más &os; laptop felhasználókkal, érdeklõdjünk a &a.mobile.name; listán. Valamint megéri még ellátogatni erre a &os;-s laptopokkal foglalkozó oldalra is. &xorg; Az &xorg; legújabb változatai képesek együttmûködni a napjainkban kapható laptopok videóvezérlõivel. Habár a hardveres gyorsítás nem feltétlenül támogatott, az általános SVGA módnak használhatónak kell lennie. Keressük meg a laptopunk kézikönyvében, hogy milyen videóvezérlõ található benne, majd vessük össze ezt az &xorg; dokumentációjával, amibõl kiderül, mennyire támogatja. Ha kiemelten nem támogatná, használjuk az általános eszközt (generic device, de ne hagyjuk megtéveszteni magunkat semmi hasonlóval). Mellesleg szerencsét próbálhatunk az &xorg; -configure paranccsal is, amely magától képes felderíteni konfigurációnk nagy részét. A legtöbb gondot egyébként a monitor beállítása okozza. Az &xorg;-ra vonatkozó források többnyire kizárólag csak katódsugárcsöves megjelenítõkre összepontosítanak, így egy folyadékkristályos megjelenítõ esetén némileg trükkös lehet eltalálni a megfelelõ modeline beállításokat. Elképzelhetõ egyébként, hogy szerencsénk van, és egyáltalán nem is kell megadni modeline-t, vagy egyszerûen csak a megfelelõ HorizSync és VertRefresh értéktartományokat kell behangolni. Ha azonban ezek sem mûködnének, a legjobb, amit ilyenkor tehetünk, hogy további forrásokat nézünk át az Interneten a helyes beállítások után keresve (ezek gyakorta &linux;-os oldalak, de ez a mi esetünkben most nem számít, hiszen ugyanazt az &xorg;-ot használja mind a két rendszer) és bemásoljuk a konfigurációs állományba a mienkhez hasonló hardverre talált modeline beállításokat. A laptopok legtöbbjét a pozícionáló eszközeiken két gombbal szállítják, ami eléggé problémás tud lenni az X esetén (tekintettel arra, hogy a középsõ gombot bevett módon szövegek másolására használják), ennek feloldására be lehet állítani úgy az X-et, hogy a bal és jobb gomb egyszerre történõ lenyomása helyettesítse a középsõ gombot. Ehhez adjuk meg a Option "Emulate3Buttons" sort az xorg.conf állományban, az InputDeviceszekcióban. Modem A laptopokba általában szerelnek belsõ (beépített, integrált) modemeket is. Sajnos, ez az esetek döntõ részében valamilyen winmodem, ahol a tényleges funkciókat szoftveres úton valósítják meg és csak a &windows;-hoz fejlesztett meghajtók képesek ezeket elérhetõvé tenni (ámbár néhány ilyen meghajtó már szárnyra kapott más operációs rendszerekhez is: például, ha Lucent LT chipsetes modemmel rendelkezünk, akkor elõfordulhat, hogy támogatja a comms/ltmdm port). Ilyenkor kénytelenek vagyunk egy külsõ modemet vásárolni: erre az egyik legjobb megoldás egy PC-kártyás (PCMCIA) modem (ld. lentebb), de a soros vagy USB-s modemek esetlegesen olcsóbbnak bizonyulhatnak. Általánosságban elmondható, hogy a hagyományos modemek (a nem winmodemek) minden nehézség nélkül használhatóak. PCMCIA (PC-kártyás) eszköz A laptopokon általában találhatóak PCMCIA (vagy más néven PC-kártya) bõvítõhelyek, ezek &os; alatt eléggé jól támogatottak. Ellenõrizzük le a rendszerindulás során megjelenõ üzenetek között (a &man.dmesg.8; segítségével), hogy ezeket a rendszer megfelelõen észlelte-e (pccard0, pccard1 stb. neveken kell megjelenniük a bõvítõhelyeknek, valamint az így csatlakoztatott eszközöknek pcic0 stb. néven). A &os; 4.X a 16 bites PCMCIA-kártyákat támogatja, a &os; 5.X pedig már ismeri a 16 és 32 bites (CardBus) kártyákat is. A jelenleg támogatott kártyák adatbázisa fellelhetõ a /etc/defaults/pccard.conf állományban. Vásárlás elõtt az itt szereplõ kártyákban érdemes gondolkodni. Az itt nem szereplõ kártyák mûködhetnek általános (generic) eszközként: a legtöbb (16 bites) modem ragyogóan használható, feltéve, hogy nem winmodem (ezek gyakran PC-kártya formájában is megjelennek, legyünk óvatosak). Érdemes megemlíteni, hogy ha a kártyánkat általános modemként ismerte fel a rendszer, a pccard.conf állományban alapértelmezés szerinti található egy 10 másodperces késleltetés (hogy elkerüljük a fagyást egyes modemeken), ami sok esetben túlzott óvatosságra vall, így ha nem érezzük szükségét és van kedvünk állítgatni, csökkentsük ezt az idõt vagy akár teljesen ki is kapcsolhatjuk. Elõfordulhat, hogy a pccard.conf egyes részei átírásra szorulnak. Nézzük meg, hogy rendszerünkben melyik megszakítások (IRQ) vannak már használatban és töröljük õket. Tehát ha mondjuk van egy hangkártyánk, amely az 5-ös IRQ-t használja, vegyük ki a felsorolásból a számát (máskülönben a rendszer lefagyásába futhatunk bele egy kártya behelyezése során). Ellenõrizzük továbbá a szabad memória bõvítõhelyeket; ha a kártyánkat nem ismerte még fel a rendszer, próbáljuk meg átállítani egy másik megengedett értékre (ezek megtalálhatóak a &man.pccardc.8; kézikönyvében). Ha még nem futna, indítsuk el a &man.pccardd.8; daemont. (Ha minden indításkor szeretnénk aktiválni, akkor tegyük bele az /etc/rc.conf állományba a pccard_enable="YES" sort.) Innentõl kezdve minden behelyezett és kivett kártyát észlel a rendszerünk, amirõl a naplóban értesítést is ad. A &os; 4.4 kiadása elõtt komolyabb változások történtek a pccard forrásában (pl. a megszakítások ISA-n keresztüli közvetítése olyan számítógépek esetén, ahol a &os; nem tudja használni a PCI BIOS-t). Ha ezzel kapcsolatosan felmerülne bármilyen probléma, érdemes frissíteni a rendszert. Energiagazdálkodás Sajnálatos módon ezek a funkciók egyáltalán nem mondhatóak jól támogatottnak &os; alatt. Ha szerencsénk van, akkor egyes funkciók jól mûködnek, mások pedig egyáltalán nem. Hogy még bonyolultabb legyen a helyzet, két szabvány is létezik az energiagazdálkodásra: az APM és az ACPI, ahol az utóbbi bõvebb és kiterjedtebb szabvány, mint az elõbbi, de több problémát is felvet. Egyes laptopok az APM-et és az ACPI-t is támogatják (adott mértékig), mások pedig csak az egyik szabványt ismerik. Emiatt mind a kettõvel kísérletezni kell egy elfogadható energiagazdálkodási séma kialakításához. Egyszerre nem lehet bekapcsolni az APM-et és az ACPI-t, még akkor sem, ha a laptop mind a kettõt támogatja. APM Az APM (Advanced Power Management) BIOS támogatást ad a különféle energiagazdálkodási jellemzõkhöz, mint mondjuk a készenléti állapot, hibernálás, a processzor órajelének csökkentése stb., amelyek el is érhetõek &os; 4.X és &os; 5.X alatt. Az APM támogatás bekapcsolásához fordíthatunk energiagazdálkodásra felkészített rendszermagot (device apm0 &os; 4.X esetén és device apm &os; 5.X esetén) is, de a &os; 5.X vonal rendszermagjához már létezik külön APM modul is, amelyet az indítás során tudunk betöltetni úgy, hogy /boot/loader.conf állományhoz hozzávesszük az apm_load="YES" sort. Ezen felül &os; 5.X esetén még be kell írni a hint.apm.0.disabled="0" sort is a /boot/device.hints állományba. Az APM-et minden indítással együtt aktivizálhatjuk, ha megadjuk az apm_enable="YES" sort a /etc/rc.conf állományban. Ezen kívül még hasznos lehet elindítani a &man.apmd.8; daemont is, méghozzá a apmd_enable="YES" sor hozzávételével. Ez a daemon felügyeli a BIOS-nak küldött különbözõ APM-eseményeket, így készenléti állapotba tudjuk helyezni a laptopunkat gombnyomásra, vagy akár összecsukással is. A APM-parancsok a &man.apm.8; kézikönyvében szerepelnek. Például, az apm -b paranccsal le lehet kérdezni az akkumulátor töltöttségét (vagy 255-öt ad vissza, ha nem támogatott ez funkció), a apm -Z energiatakarékos állapotba, ill. a apm -z (vagy a zzz) parancs készenléti állapotba helyezi a laptopot. A számítógép kikapcsolásához és áramtalanításához a shutdown -p parancsot kell használni. Még egyszer megemlítjük, hogy a tárgyalt funkciók közül nem mindegyik mûködik megfelelõen vagy akár egyáltalán nem mûködik. Esetenként tapasztalhatjuk, hogy a laptop energiatakarékos vagy készenléti állapotba helyezése ugyan mûködik konzolon, de X alatt viszont nem (vagyis nem kapjuk vissza a képet). Ha &os; 5.X-et használunk, erre egy megoldás lehet, ha beletesszük a options SC_NO_SUSPEND_VTYSWITCH sort a rendszermagunk konfigurációs állományába és újrafordítjuk azt. Másik lehetõség, hogy átváltunk egy virtuális konzolra (a Ctrl Alt F1 lenyomásával, vagy ugyanígy egy másik funkcióbillentyûvel), majd elindítjuk az &man.apm.8;-et. Ha &man.apmd.8;-t használunk, automatizálhatjuk is ezt a rendszert a &man.vidcontrol.1; segítségével. Ehhez nem kell mást tennünk, csupán átírni a /etc/apmd.conf állományt az alábbiak szerint: apm_event SUSPENDREQ { exec "vidcontrol -s 1 < /dev/console"; exec "/etc/rc.suspend"; } apm_event USERSUSPENDREQ { exec "vidcontrol -s 1 < /dev/console"; exec "sync && sync && sync"; exec "sleep 1"; exec "apm -z"; } apm_event NORMRESUME, STANDBYRESUME { exec "/etc/rc.resume"; exec "vidcontrol -s 9 < /dev/console"; } ACPI Az ACPI (Advanced Configuration and Power Management Interface) nem csak energiagazdálkodást tesz lehetõvé, hanem hardver-felderítést is (ezzel szinte feleslegessé téve a PnP-t és a PCI BIOS-t). Az ACPI támogatása csak &os; 5.X alatt érhetõ el, és alapértelmezés szerint aktív. Ilyenkor tehát nem kell semmit se csinálni, hogy mûködésre bírjuk. Az ACPI viselkedését az &man.acpiconf.8;-al tudjuk vezérelni. Sajnos azonban, a gyártók gyakorta hibás ACPI-implementációval szállítják a laptopokat, aminek következtében az ACPI bekapcsolása több gondot okoz, mint hasznot, egészen annyira, hogy akár a &os; bizonyos gépeken képtelen elindulni aktív ACPI támogatással. Ha az ACPI használata gondokat okoz, ajánlott érdeklõdni a laptopunk gyártójánál, hogy vajon készült-e ACPI-vel kapcsolatos BIOS-frissítés az utóbbi idõben. Mivel a &os; ACPI implementációja is még gyerekcipõben jár, ezért érdemes még frissíteni a rendszerünket is, elképzelhetõ ugyanis, hogy a problémánkat azóta már megoldották. Az ACPI kikapcsolásához egyszerûen ki kell bõvíteni a /boot/device.hints állományt a hint.acpi.0.disabled="1" sorral. Ha gondunk lenne egy ACPI-t használó gép indításával, ideiglenesen ki tudjuk kapcsolni az ACPI-t az indítás során aktiválható paranccsoron keresztül is, az unset acpi_load parancs kiadásával. A &os; 5.1-RELEASE kiadásától kezdve már egy rendszerindító menüben is kiválaszthatjuk, hogyan induljon a rendszer: itt az egyik menüpont az ACPI kikapcsolása. Ekkor tehát az ACPI kikapcsolásához válasszuk a 2. Boot &os; with ACPI disabled (2. A &os; indítása ACPI támogatás nélkül) pontot a menüben. A monitor energiagazdálkodása Az X ablakkezelõ rendszer (&xorg;) is tartalmaz energiagazdálkodást a megjelenítõ eszközök számára (ajánlott ezzel kapcsolatosan megnézni a &man.xset.1; man oldalt, rákeresve a dpms szóra). Valószínûleg ezt is hasznos lesz megismerni. Azonban vegyük figyelembe, hogy sokszor nem következetesen mûködik a laptopokon: elõfordulhat, hogy kikapcsolja ugyan a megjelenítõt, de nem kapcsolja ki a háttérvilágítást.
diff --git a/hu_HU.ISO8859-2/articles/multi-os/Makefile b/hu_HU.ISO8859-2/articles/multi-os/Makefile index 2c6f0766ab..4fe26b438c 100644 --- a/hu_HU.ISO8859-2/articles/multi-os/Makefile +++ b/hu_HU.ISO8859-2/articles/multi-os/Makefile @@ -1,24 +1,24 @@ # $FreeBSD$ # # Article: Installing and Using FreeBSD With Other Operating Systems # # Tidy messes up iso-8859-2 characters # NO_TIDY= yes -MAINTAINER= pali.gabor@gmail.com +MAINTAINER= pgj@FreeBSD.org DOC?= article FORMATS?= html INSTALL_COMPRESSED?= gz INSTALL_ONLY_COMPRESSED?= SRCS= article.sgml URL_RELPREFIX?= ../../../.. DOC_PREFIX?= ${.CURDIR}/../../.. .include "${DOC_PREFIX}/share/mk/doc.project.mk" diff --git a/hu_HU.ISO8859-2/articles/multi-os/article.sgml b/hu_HU.ISO8859-2/articles/multi-os/article.sgml index aaa20ce16f..f53ccde1c5 100644 --- a/hu_HU.ISO8859-2/articles/multi-os/article.sgml +++ b/hu_HU.ISO8859-2/articles/multi-os/article.sgml @@ -1,968 +1,968 @@ %articles.ent; ]> + Translated by: PALI, Gabor + Original Revision: 1.39 -->
A &os; telepítése és használata más operációs rendszerekkel együtt Jay Richmond
jayrich@sysc.com
1996. augusztus 6. &tm-attrib.freebsd; &tm-attrib.ibm; &tm-attrib.linux; &tm-attrib.microsoft; &tm-attrib.powerquest; &tm-attrib.general; Ez a leírás azt tárgyalja, miképpen lehet a &os;-t olyan más népszerû operációs rendszerek, mint mondjuk a &linux; &ms-dos;, &os2; és &windows; 95 mellé telepíteni és használni. Külön köszönet: Annelise Anderson andrsn@stanford.edu, Randall Hopper rhh@ct.picker.com és &a.jkh;. Fordította: &a.hu.pgj; Áttekintés A legtöbben nem tudják az említett operációs rendszereket kényelmesen egymás mellé rakni egy kisebb méretû merevlemezen, ezért a nagyobb EIDE-meghajtókkal kapcsolatos ismeretekrõl is szó fog esni. Mivel rengeteg kombinációja létezik a különféle operációs rendszereknek és merevlemezeknek, valószínûleg az fog a leírás leghasznosabb részének bizonyulni. Itt találhatóak meg ugyanis azok a speciális beállítási sémák, amelyek több operációs rendszer használata esetén alkalmazhatóak. Ez a cikk feltételezi, hogy a merevlemezünkön már elõkészítettünk kellõ mennyiségû szabad helyet az újabb operációs rendszer(ek) számára. Minden egyes alkalommal, amikor újra felosztjuk a merevlemezünket, egyúttal kockára tesszük a meglevõ partícióinkon levõ adataink épségét is. Viszont ha a merevlemezünkön teljes egészében csak a DOS található, akkor a FIPS nevû segédprogramot hasznosnak fogjuk találni (megtalálható a &os; CDROM-on, a \TOOLS alkönyvtárban, vagy FTP-n. Segítségével anélkül tudjuk partícionálni a merevlemezünket, hogy kockára tennénk a rajta levõ adatainkat biztonságát. Valamint létezik még egy &partitionmagic; nevû kereskedelmi alkalmazás is, amellyel minden komoly következmény nélkül tudunk partíciókat átméretezni és törölni. A boot managerek áttekintése Csak röviden bemutatnánk néhány elterjedt boot managert. Közülük, a számítógépünk kiépítésétõl függõen, egyet vagy többet jó eséllyel tudunk majd használni. Boot Easy Ez a &os; alapértelmezett boot managere. Szinte bármilyen rendszert képes indítani, többek közt a BSD, &os2; (HPFS), &windows; 95 (FAT és FAT32) és &linux; típusú rendszereket. Az indítandó partíciót a funkcióbillentyûkkel választhatjuk ki. &os2; Boot Manager Elindítja a FAT, FAT32, HPFS, FFS (&os;) és EXT2 (&linux;) partíciókat, amelyet a nyilakkal választhatunk ki. Az &os2; Boot Manager az egyetlen az itt felsoroltak közül, amely a saját partícióját használja, miközben az összes többi a Master Boot Record (MBR)-ot. Ennek következtében az 1024. cilinder elé kell telepítenünk, hogy elkerüljük az ezzel kapcsolatos esetleges indítási problémákat. LILO-val telepített &linux;-ot csak akkor képes indítani, amikor az a boot szektorban található, nem pedig az MBR-ben. Az Interneten található &linux; hogyanok között további információkat találhatunk az &os2; boot manager és a &linux; kapcsolatáról. OS-BS Ez egy másik boot manager a Boot Easy mellett. Valamivel több kontrollt ad a rendszerindítási folyamat felett, például beállítható benne az alapértelmezett indított partíció és egy várakozási idõ. A program béta változatában már a nyilak segítségével lehet kiválasztani az indítandó operációs rendszert. Szintén megtalálható a &os; CD-jén a \TOOLS könyvtárban vagy FTP-n. LILO, avagy LInux LOader Ez egy korlátozott képességû boot manager. Képes elindítani a &os;-t, habár ehhez szükség van némi finomhangolásra a hozzátartozó konfigurációs állományban. Röviden FAT32-rõl A FAT32 a FAT állományrendszer kiváltására szolgál, amelyet a Microsoft 1996 végén, a &windows; 95 OSR2 béta változatától kezdõdõen indított útjának, ezzel lecserélve a &windows; 95-tel telepített számítógépek alapértelmezett FAT típusú állományrendszerét. Úgy alakítja át a megszokott FAT-ot, hogy lehetõvé teszi a kisebb kiosztási egységek használatát nagyobb merevlemezeken is. Továbbá a FAT32-ben megváltoztatták a hagyományos FAT boot szektorát és kiosztási táblázatát is, összeférhetetlenné téve ezáltal néhány boot managerrel. Egy átlagos telepítés Tegyük fel, hogy van két nagyobb EIDE merevlemezünk és szeretnénk rájuk &os;-t, &linux;-ot és &windows; 95-öt telepíteni. Íme, hogyan tennénk mindezt az alábbi merevlemezekkel: /dev/wd0 (az elsõ fizikai lemez) /dev/wd1 (második fizikai lemez) Mindkét lemeznek 1416 cilindere van. Elsõként indítsunk az &ms-dos; vagy &windows; 95 rendszerindító lemezével, amelyen az FDISK.EXE segédprogram található. Ennek segítségével készítünk egy kis, nagyjából 50 MB méretû elsõdleges partíciót (35-40-et a &windows; 95-nek, meg hagyunk egy kis helyet levegõzni is) az elsõ lemezen. Ezen kívül még készítsünk egy nagyobb partíciót a második merevlemezen, ahol a &windows;os alkalmazásaink és az adataink foglalnak majd helyet. Indítsuk újra a gépet és telepítsük fel a &windows; 95-öt a C: partícióra (amit egyébként könnyebb mondani, mint megtenni). Következõként a &linux;-ot telepítsük fel. Nem vagyok benne biztos, hogy ez mindegyik &linux;-disztribúcióra igaz, de a Slackware tartalmazza a LILO-t (ld. ). A &linux;-os fdisk parancsával tovább partíciónálva én a &linux;-ot az elsõ lemezre tenném (nagyjából 300 MB elegendõ egy kövérebb rendszerpartíciónak és némi lapozóállománynak). Miután feltelepítettük a &linux;-ot és éppen a LILO elhelyezése elõtt állunk, mindenképpen ellenõrizzük, hogy a &linux;-os rendszerpartíció boot szektorába telepítjük, nem pedig az MBR-be! A fennmaradó hely mehet mind a &os;-nek. Vigyázzunk, hogy a &os; rendszerslice-a ne kerüljön az 1024. cilinderen túlra. (Az 1024. cilinder az 528. MB-nál található a most feltételezett 720 MB-os lemezükön.) A merevlemez többi részét (nagyjából 270 MB) az /usr és / slice-okra is fel lehet használni. A második lemez fennmaradó részén (aminek a mérete az 1. lépésben kialakított, &windows;-os alkalmazásoknak és adatoknak szánt partíció méretétõl függ) még elfér a /usr/src slice és a lapozóállomány. Ha most megnézzük a &windows; 95 fdisk programjával, a merevlemezeket valahogy így láthatjuk: --------------------------------------------------------------------- Partíció információinak megjelenítése Aktuális merevlemezes meghajtó: 1 Partíció Állapot Típus Kötetcímke Megabájt Rendszer Felhasznált C: 1 A PRI DOS 50 FAT** 7% 2 A Non-DOS (Linux) 300 43% Teljes lemezterület: 696 megabájt (1 megabájt = 1048576 bájt) A folytatáshoz nyomja meg az Esc billentyût. --------------------------------------------------------------------- Partíció információinak megjelenítése Aktuális merevlemezes meghajtó: 2 Partíció Állapot Típus Kötetcímke Megabájt Rendszer Felhasznált D: 1 A PRI DOS 420 FAT** 60% Teljes lemezterület: 696 megabájt (1 megabájt = 1048576 bájt) A folytatáshoz nyomja meg az Esc billentyût. --------------------------------------------------------------------- ** Ez FAT16 vagy FAT32 lehet attól függõen, hogy OSR2-t használunk-e. Lásd . Telepítsük fel a &os;-t. Mindenképpen az elsõ merevlemezrõl indítsuk el a számítógépet, ezért a BIOS-ban állítsuk NORMAL-ra. Ha nem az lenne, adjuk meg a lemez valós geometriáját indításkor (a lekérdezéséhez indítsuk el &windows; 95-öt, majd a Microsoft Diagnostics-ot (MSD.EXE, esetleg nézzük meg a BIOS-ban) a hd0=1416,16,63 paraméterrel, ahol a 1416 megadja a merevlemez cilindereinek számát, a 16 a fejek számát sávonként, valamint a 63 a szektorok számát sávonként. A merevlemez partícionálása során a Boot Easy-t mindenképpen az elsõ lemezre tegyük. A második lemez miatt különösebben ne aggódjunk, semmi bootolni való nincs rajta. Újraindítás után a Boot Easy várhatóan felismeri mind a három indítható partíciót: DOS (&windows; 95), &linux; és BSD (&os;) néven. Különösen megfontolandók A legtöbb operációs rendszer meglehetõsen kényes abban a tekintetben, hogy hova helyezzük õket a merevlemezen. A &windows; 95-öt és DOS-t az elsõ merevlemez elsõ elsõdleges partíciójára kell telepítenünk. Az &os2; innen nézve kívételnek számít, mivel egyaránt telepíthetõ az elsõ vagy a második merevlemezre is, tetszõleges elsõdleges vagy kiterjesztett partícióra. Ha nem vagyunk benne biztosak, az indítható partíciókat tegyük mindig az 1024. cilinder elé. Ha a &windows; 95-öt egy már meglévõ BSD rendszer mellé telepítjük, tönkre fogja tenni az MBR-t, és ezért újra kell telepítenünk a korábbi boot managerünket. A Boot Easy-t a &os; telepítõ CDROM-jának \TOOLS könyvtárában található, vagy az FTP-n letölthetõ BOOTINST.EXE segítségével tudjuk visszarakni. Másik lehetõség gyanánt elindíthatjuk a telepítõt is, és megkereshetjük benne a partíciószerkesztõt. Itt jelöljük meg &os;-t tartalmazó partíciót indíthatónak (bootable), majd válasszuk a Boot Managert és nyomjuk le a W-t (mint (W)rite out) a boot manager tényleges MBR-be írásához. Most már újraindíthatjuk a számítógépet és a Boot Easy pedig felismeri a &windows; 95-öt mint DOS. Nem szabad elfelejtenünk, hogy az &os2; ugyan képes FAT és HPFS partíciókat olvasni, viszont FFS-t (&os;) és EXT2-t (&linux;) nem! Ehhez hasonlóan a &windows; 95 csak FAT és FAT32 partícókat (ld. ) tud írni és olvasni. A &os; ismeri a legtöbb állományrendszert, de jelenleg nem tud HPFS partíciókat olvasni. A &linux; képes HPFS partíciókat olvasni, de nem tudja írni õket. A &linux; kernel legújabb (2.x-es) változatai már képesek írni és olvasni a &windows; 95 VFAT partícióit (a VFAT az, aminek a segítségével a &windows; 95 képes hosszú állományneveket kezelni — egyébként teljesen olyan, mint a FAT). A &linux; tehát képes írni és olvasni a legtöbb állományrendszert. Érthetõ? Remélem! Példák (ennek a szakasznak szüksége van még némi átdolgozásra, várjuk a hozzászólásokat a témában a jayrich@sysc.com címre). &os; + &windows; 95: Ha a &os;-t a &windows; 95 után telepítettük, akkor a &windows; 95-öt a Boot Easy menüjében DOS-ként kell látnunk. Ha viszont a &windows; 95-öt a &os; után telepítettük, olvassuk el a fenti t. Amíg nincsenek olyan merevlemezeink, amelyek mérete meghaladná az 1024 cilindert, nem kell különösebben aggódnunk a bootolás miatt. Amikor azonban valamelyik partíciónk az 1024. cilinder fölé merészkedik és DOS (vagy &windows; 95) alatt olyan hibaüzeneteket kapunk, mint mondjuk a Rossz rendszerlemez, valamint a &os; sem képes elindulni, keressünk meg a BIOS-unk beállításai között > 1024 cylinder support-ot (1024-nél több cilinder támogatása) vagy a NORMAL/LBA nevezetû módot. A DOS-nak ebben az esetben ugyanis szüksége lehet az LBA (Logical Block Addressing) bekapcsolására a bootoláshoz. Ha nem akarjunk minden egyes rendszerindításkor eljátszani ezt, a CD-n található FBSDBOOT.EXE segítségével akár a DOS-on keresztül is el tudjuk indítani a &os;-t. (Ez ugyanis megkeresi a &os;-s partíciót és elindítja azt). &os; + &os2; + &windows; 95: Nincs új a nap alatt. Az &os2; boot managere képes elindítani mindezen operációs rendszereket, ez a kombináció tehát nem okozhat problémát. &os; + &linux;: A Boot Easy segítségével mind a két rendszer elindítható. &os; + &linux; + &windows; 95: (ld. ) Egyéb hasznos helyek Számtalan &linux; hogyan foglalkozik az egy merevlemezre telepíthetõ operációs rendszerek problémájával. A &linux;+DOS+Win95+OS2 mini-hogyan az &os2; boot managerével kapcsolatosan nyújt némi segítséget, valamint a &linux;+&os; mini-hogyan is érdekes olvasmány lehet. A &linux;-hogyan is fontos információkat tartalmazhat. A &windowsnt; Loader Hacking Guide-ban sok érdekesség megtalálható a &windowsnt;, &windows; 95 és DOS más operációs rendszerekkel együtt történõ használatáról. Hale Landis Hogyan is mûködik? c. leírása is rengeteg hasznos apróságot árul el a különfél lemez geometriákról és a rendszerindítással kapcsolatos egyéb tudnivalókról. Ezt itt találhatjuk meg. Végezetül, erõsen javallott tüzetesen átnézni a &os; rendszermag rendszerindításáról szóló dokumentációját is, amely megtalálható a rendszermag forrásában (alapértelmezés szerint a /usr/src/sys/i386/boot/biosboot/README.386BSD helyre kerül). Technikai részletek (Köszönet érte Randall Hoppernek rhh@ct.picker.com) Ebben a szakaszban megpróbálunk kellõ mennyiségû alapvetõ ismeretet átadni a használatban levõ merevlemezekrõl, valamint ezen lemezek rendszerindítási folyamatáról, elegendõt ahhoz, hogy le tudjuk küzdeni azokat a leggyakoribb problémákat, amelyek több operációs rendszer indítása során leselkednek ránk. Teljesen a kezdetektõl indul, ezért javasolt egészen addig a pontig ugrani az olvasásban, ahol már ismeretlen dolgok is kezdenek feltûnni. Amit tudni érdemes a lemezekrõl Három alapvetõ jellemzõ írja le a merevlemezen található adatok pontos helyét: cilinder, fej, szektor. Igazából nem teljesen lényeges tudni, hogy ezek milyen viszonyban is állnak egymással, kivéve annyit, hogy ezek együttesen azonosítják be fizikailag a lemezen található adatokat. Egy merevlemeznek van adott számú cilindere, feje és szektora az egyes cilinder-fej párosok mentén (amelyet egyébként sávnak is neveznek). Ezek az információk adják meg együttesen a merevlemez fizikai geometriáját. Általában 512 byte található szektoronként valamint 63 szektor fejenként, azonban a cilinderek és a fejek száma jelentõsen változik lemezenként. Ezért a merevlemezen maximálisan tárolható adatok mennyiségét a következõképpen lehet kiszámítani ezek ismeretében: (a cilinderek száma) × (a fejek száma) × (63 szektor/sáv) × (512 byte/szektor) Például, ez egy 1,6 gigabyte-os Western Digial AC31600 EIDA merevlemez esetén: (3148 cilinder) × (16 fej) × (63 szektor/sáv) × (512 byte/szektor) amely 1 624 670 208 byte-nak felel meg, ami pedig nagyjából 1,6 gigabyte. Az egyes merevlemezek fizikai geometriáját (a cilinderek, fejek és a sávonkénti szektorok számát) az ATAID és az Interneten megtalálható egyéb hasonló programokkal lehet lekérdezni. De valószínûleg magán a merevlemezen is megtalálható ez az adat. Azonban nem árt óvatosnak lennünk: ha a BIOS-ban LBA-t állítottunk be (ld. ), az említett programok egyikét sem tudjuk használni. Ezért sem képes sok más program (pl. az MSD.EXE vagy a &os; fdisk) megállapítani a fizikai lemez geometriát; helyette az átértelmezett geometriát (a LBA-ból származó virtuális azámadatokat) adják vissza. Errõl még beszélni fogunk. Még egy apróság ezzel kapcsolatban. A 3 szám — nevezetesen a cilinderek, a fejek és a szektorok sávonkénti száma — ismeretében képesek vagyunk betájolni egy konkrét abszolút szektort (vagyis egy 512 byte-os adatblokkot) a lemezünkön. A cilindereket és fejeket 0-tól, míg a szektorokat 1-tõl szokták számozni. Azok számára, akik még jobban el akarnak mélyedni a technikai részletekben, a lemezek geometriájában, a boot szektorok és BIOS-ok stb. titkaiban, mindent megtalálhatnak róluk az Interneten. Keressenek rá bátran a Lycos, Yahoo stb. szolgáltatásokban a boot sector vagy master boot record szavakra. A sok hasznos ismeret között esetleg találkozni fogunk Hale Landis Hogyan is mûködik? c. leírásgyûjteményével is. Ezzel kapcsolatban ld. a t. Rendben, ennyi elég is lesz a terminológiáról. Beszéljük a bootolásról! A rendszerindítás folyamata A merevlemez elsõ szektorában (azaz a 0. cilinder, 0. fej, 1. szektor) lakozik a Master Boot Record (MBR). Ez tartalmazza lényegében a teljes lemez térképét. Legfeljebb 4 partíciót képes tárolni, amelyek mindegyike a lemez egy-egy folytonos darabkája. A &os; ezeket a partíciókat egyébként slice-oknak hívja annak érdekében, hogy elkerülje a saját partícióival történõ összetévesztésüket, habár mi most nem így fogunk tenni. Minden egyes partícióra telepíthetõ egy-egy operációs rendszer is. Az MBR-ben található összes partíciós bejegyzésnek van egy ún. partíció azonosítója, egy kezdõ cilinder/fej/szektor értéke és egy befejezõ cilinder/fej/szektor értéke. A partíció azonosítója megadja, hogy az adott partíció milyen típusú (milyen operációs rendszer használja), a kezdõ/befejezõ értéke pedig azt, hol található. A ban a teljesség igénye nélkül felsoroltunk néhány ismertebb azonosítót. Partíció azonosítók Az. (hex) Leírás 01 Elsõdleges DOS12 (12 bites FAT) 04 Elsõdleges DOS16 (16 bites FAT) 05 Kiterjesztett DOS 06 Elsõdleges nagy DOS (> 32MB) 0A &os2; 83 &linux; (EXT2FS) A5 &os;, NetBSD, 386BSD (UFS)
Megjegyezzük, hogy nem mindegyik partíció indítható (ilyen pl. a kiterjesztett DOS). Egyesek igen — mások pedig nem. Amitõl egy partíció bootolhatóvá válik, az a partíció boot szektora, amely az egyes partíciók elején található. Amikor beállítjuk a kedvenc boot managerünket, az tulajdonképpen átnézi az összes merevlemez MBR-jeinek partíciós táblájában található bejegyzéseket és lehetõvé teszi számunkra, hogy elnevezgessük õket. Majd amikor elindítjuk a számítógépet, a boot manager az elsõként próbált merevlemez Master Boot Recordjában elhelyezett speciális program segítségével életre kel. Felkeresi a választásunknak megfelelõ partíciót az MBR partíciós táblájában, és felhasználva az így megismert kezdõ cilinder/fej/szektor adatokat, betölti az adott partíció boot szektorát, majd átadja neki a vezérlést. A partíció boot szektora ezek után már elegendõ információt tartalmaz a rajta levõ operációs rendszer indításához. Egyetlen fontos tudnivalót nem említettünk meg még: minden merevlemezen található MBR. Azonban ezek közül csak az tekinthetõ fontosnak, amely a BIOS által elsõként próbált lemezen található. Ha csak IDE csatolós merevlemezeink vannak, ez általában az elsõ IDE lemez (pl. az elsõdleges lemez az elsõ vezérlõn). Ugyanez a helyzet a csak SCSI-t tartalmazó rendszerekben. Ha viszont van IDE és SCSI merevlemezünk is, a BIOS általában az IDE lemezeket próbálja elõször elindítani, így az elsõként elindított lemez az elsõ IDE lemez. A boot managert tehát az elsõként elinduló merevlemez MBR-jébe kell elhelyeznünk a fentiekben leírtak szerint. A rendszerindítás korlátai és veszélyei Most pedig következzen mindaz, amire nagyon oda kell figyelnünk. A rettegett 1024 cilinderes korlát és hogyan segít ezen az LBA A bootolás folyamatának elsõ része a BIOS-on keresztül megy végbe (ha még nem ismernénk: a BIOS az az alaplapon található chip, amely a számítógép indításához nélkülözhetetlen rutinokat tárolja). Mint olyan, a folyamat elsõ része tehát a BIOS interfészének korlátozásaitól függ. Ezen idõtartam alatt a BIOS által nyújtott interfészt használjuk a merevlemez olvasására (13H megszakítás, 2-es funkció), amely 10 bitet használ a cilinderek, 8 bitet a fejek és 6 bitet a szektorok számozására. Ezzel lekorlátozza használóját (tehát az MBR-bõl induló boot managereket és a boot szektorokban található betöltõket) az alábbiakra: legfejlebb 1024 cilinderre legfejlebb 256 fejre legfejlebb 64 szektorra sávonként (ami ténylegesen 63, mivel a 0. nem használható) Mostanában azonban a nagyobb merevlemezeknek tengernyi cilinderük van, de nem túl sok fejük, ezért ezek a lemezek szinte kivétel nélkül átlépik az 1024 cilinderes határt. Ha vesszük ezt a tényt és összevetjük a BIOS által kínált interfésszel, rájöhetünk, hogy nem bootolhatunk akárhonnan a lemezrõl. A rendszerindító kódnak (tehát a boot managernek és az összes indítható partícióban található betöltõnek) az 1024. cilinder alatt kell lennie. Tényekre fordítva a szót, ha van egy átlagos merevlemezünk, aminek 16 feje van, ez nagyjából: 1024 cilinder/lemez × 16 fej/lemez × 63 szektor/(cilinder - fej) × 512 byte/szektor, ami megfelel a sokszor emlegetett 528 MB-os határnak. Itt jön a képbe a BIOS LBA (Logical Block Addressing). Ennek segítségével ugyanis a BIOS-hívások használója képes hozzáférni az 1024. feletti fizikai cilinderekhez is a BIOS-on keresztül, méghozzá a cilinderek átdefiniálásával. Vagyis újraértelmezi a cilinderek és a fejek számát, és ezzel olyan képzetet ad, mintha a merevlemeznek kevesebb cilindere de több feje lenne, mint a valóságban. Másképp fogalmazva, kihasználja azt a helyzetet, hogy a modern merevlemezekben viszonylag kevés fej és sok cilinder található, ezért eltolja a kettõ között nyugvó osztást, aminek köszönhetõen mind a két érték az imént említett határok (1024 cilinder, 256 fej) alatt tud maradni. A BIOS LBA használatával a merevlemezek ezen korlátozása virtuálisan el is tûnik (nos, valójában csak 8 gigabyte-nyival arrébb kerül). Ha LBA-t támogató BIOS-unk van, akkor a &os;-t és minden más operációs rendszert bárhova pakolhatunk, hiszen így nem fogunk az 1024 cilinderes korlátba ütközni. Az elõbb példaként felhozott 1,6 gigabyte-os Western Digital esetén tehát a fizikai geometria: (3148 cilinder, 16 fej, 63 szektor/sáv, 512 byte/szektor) Azonban a BIOS LBA ezt így fordítja át: (787 cilinder, 64 fej, 63 szektor/sáv, 512 byte/szektor), ami ugyanazt a tényleges lemezméretet eredményezi, azonban a cilinder- és fejadatok a BIOS-hívások által kezelhetõ tartományba esnek. (Mellékesen megjegyzem, hogy nekem pont egy &linux; és egy &os; partícióm van az egyik merevlemezemen, éppen az 1024. cilinder felett, és mind a kettõ remekül bootol, hála az LBA-nak). Boot managerek és a lemez kiosztása Egy másik fontos dolog, amire figyelnünk kell a boot managerek telepítése során, az éppen a boot managernek foglalt hely a lemezen. A legjobb erre már elõre gondolni, és ezzel elkerüljük egy vagy több operációs rendszerünk újratelepítését. Ha nyomonkövettük a Master Boot Recordról (avagy hol is található az MBR), a partíciók boot szektoráról és a rendszerindítási folyamatról szóló t, felmerülhet bennünk a kérdés, hogy a merevlemezükön hova is fog kerülni maga a boot manager. Nos, egyes boot managerek kellõen kis méretûek ahhoz, hogy teljes egészében elférjenek a Master Boot Recordban (0. cilinder, 0. fej, 1. szektor), a partíciós tábla mellett. Másoknak ellenben valamivel több helyre van szüksége és tulajdonképpen a 0. cilinder 0. fejének sávjában nyúlnak túl az MBR-en néhány szektornyival, mivel azok általában szabadon maradnak… általában. És itt jön a csel! Egyes operációs rendszerek (köztük a &os; is) megengedik, hogy a partíciójuk akár közvetlenül a Master Boot Record után kezdõdjön a 0. cilinder 0. fejének 2. szektorában. Tulajdonképpen, ha a &os; telepítõjének egy olyan lemezt adunk meg, amelynek az eleje vagy a teljes egésze éppenséggel üres, a &os; partícióját alapértelmezés szerint közvetlenül ide rakja (legalább is így tette, amikor megpróbáltam telepíteni). Ezután szépen felrakjuk a boot managert, és ha az éppenséggel hajlamos elfoglalni az MBR után következõ néhány szektort, akkor ezzel együtt felül is írja az elsõ partíció adatait. A &os; esetében így felülírja a lemezcímkét, amitõl a &os; partíció ezáltal bootolhatatlanná válik. Ha egyszerûen el akarjuk kerülni ezt a problémát (és megadni az esélyt más, kevésbé rugalmas boot managerek számára), akkor hagyjuk szabadon a lemezen található elsõ sávot. Vagyis ne tegyünk semmilyen partíciót a 0. cilinder, 0. fej, 2. szektorától kezdõdõen egészen a 0. cilinder, 0. fej 63. szektoráig, hanem helyezzük azt a 0. cilinder 1. fejének 1. szektorára. Ugyan nem mernék rá megesküdni, de ha létrehozunk egy DOS partíciót a lemez elején, a DOS alapértelmezés szerint ezt a területet szabadon hagyja (ezért is gondolja úgy néhány boot manager, hogy szabad). Ezt inkább magam szeretem csinálni, ezért létrehozok egy 1 megás DOS partíciót a lemez elején, mivel ezzel ráadásul meg tudom akadályozni, hogy elsõleges DOS meghajtónevek felcserélõdjenek egy újrapartícionálást követõen. Hivatkozásképpen, a következõ boot managerek használják a Master Boot Recordot az adataik és kódjuk tárolására: OS-BS 1.35 Boot Easy LILO Ezek a boot managerek használnak további szektorokat a Master Boot Record után: OS-BS 2.0 Beta 8 (2-5. szektorok) Az &os2; boot managere Mit tegyünk, ha nem indul el a rendszer a számítógépünkön? Egyes esetekben elõfordulhat, hogy a boot managerek telepítése során az MBR-t olyan állapotba sikerül hozni, ahonnan a számítógépünk nem képes elindulni. Ugyan nem valószínû, de megtörténhet, amikor ismételten használjuk az FDISK-et egy már meglevõ boot manager alatt. Ha van a lemezen egy bootolható DOS partíció, akkor indítsuk el azt egy DOS-os rendszerlemezrõl, és írjuk be: A:\> FDISK /MBR Ennek segítségével vissza tudunk rakni egy egyszerû DOS rendszerbetöltõ kódot az MBR-be, ami után be tudjuk tölteni a DOS-t (de csak a DOS-t) a merevlemezrõl. Másik megoldás lehet, hogy simán újra felrakjuk a boot managerünket egy rendszerindító lemezrõl.
diff --git a/hu_HU.ISO8859-2/articles/version-guide/Makefile b/hu_HU.ISO8859-2/articles/version-guide/Makefile index 152fafc672..e68ad9ccb1 100644 --- a/hu_HU.ISO8859-2/articles/version-guide/Makefile +++ b/hu_HU.ISO8859-2/articles/version-guide/Makefile @@ -1,24 +1,24 @@ # $FreeBSD$ # # Article: FreeBSD Version Guide # # Tidy messes up iso-8859-2 characters # NO_TIDY= yes -MAINTAINER= pali.gabor@gmail.com +MAINTAINER= pgj@FreeBSD.org DOC?= article FORMATS?= html INSTALL_COMPRESSED?= gz INSTALL_ONLY_COMPRESSED?= SRCS= article.sgml URL_RELPREFIX?= ../../../.. DOC_PREFIX?= ${.CURDIR}/../../.. .include "${DOC_PREFIX}/share/mk/doc.project.mk" diff --git a/hu_HU.ISO8859-2/articles/version-guide/article.sgml b/hu_HU.ISO8859-2/articles/version-guide/article.sgml index 10ce3a21a1..a9064f5bdc 100644 --- a/hu_HU.ISO8859-2/articles/version-guide/article.sgml +++ b/hu_HU.ISO8859-2/articles/version-guide/article.sgml @@ -1,526 +1,526 @@ %articles.ent; ]> + Translated by: PALI, Gabor + Original Revision: 1.11 -->
Válasszuk ki a nekünk igazán megfelelõ &os; verziót! A &os; Dokumentációs Projekt $FreeBSD$ &tm-attrib.freebsd; 2005 A &os; Dokumentációs Projekt Ön a &os; telepítését választotta. Üdvözöljük! Ezt a leírást annak szellemében készítettük, hogy segítsünk eligazodni a telepíthetõ verziók között. Fordította: &a.hu.pgj; Háttér A leginkább megfelelõ verzió kiválasztásához fontos megértenünk néhány alapvetõ fogalmat a &os; fejlesztési modelljével és az ún. Release Engineering (RE, kiadásépítés) folyamatával kapcsolatosan. A &os;-t nagyrészt független önkéntesek hatalmas csoportja fejleszti. A rendszermag, a legalapvetõbb függvénykönyvtárak, valamint a hozzájuk tartozó segédprogramok forrásait egy verziókövetõ rendszerben tárolják, amely bárki által és bármikor tetszõlegesen letölthetõ. Ettõl függetlenül ezek lefordított változatai (binárisai) is rendszeresen elérhetõek. Néhány ilyen binárist alapos és széleskörû tesztelési folyamatnak vetnek alá, majd kiadásnak címkézik fel õket. Kiadások A kiadások (release) általában rendelkeznek egy fõverziószámmal és egy alverziószámmal. A fõverziószámok feladata, hogy jelezze az újabb, nagyobb változtatásokat a rendszerben. Ilyenkor természetesen elkerülhetetlen, hogy ennek következtében komolyabb átszervezéseken menjen át a &os;, vagy éppen a régebbi, már hasztalannak tekintett részei eltûnjenek. Emiatt gyakran még a korábbi fõbb kiadásokkal kapcsolatban is elveszhet bizonyos mértékû kompatibilitás. Az alverziószámok jelzik a megbízhatóságot és a teljesítményt érintõ kisebb hibajavításokat. Ebben az esetben mind a forráskód-, mind pedig a bináris szintû kompatibilitás megtartása egyik elsõdleges feladatunk. Alkalmanként az alverziókba is kerülhetnek újítások, de csak akkor, ha ezek nem fenyegetik a velük szemben kitûzött összes többi célt. Azonban sose szabad elfelejtenünk, hogy egy kiadott verzió nem több, mint a forrásról egy adott idõben és egy adott néven (címkével ellátott) készített pillanatfelvétel. (Például az 5.4-es kiadáshoz a kiadásépítõk a RELENG_5_4_0_RELEASE címkét tették.) A fejlesztés a HEAD néven ismert címkével azonban mindig halad tovább. Fejlesztési ágak Minden kiadás alkalmával létrehoznak egy fejlesztési ágat, mint mondjuk a RELENG_5_4. Habár a RELENG_5_4_0_RELEASE címkével ellátott források már nem fognak a továbbiakban változni, a RELENG_5_4 címkével rendelkezõk ellenben még igen, méghozzá a HEAD ágból származó biztonsági vagy egyéb javítások, esetleg kisebb változtatások nyomán. Egy-egy fõbb kiadáshoz még egy másik címkét is létrehoznak, mint mondjuk a RELENG_5. A biztonsági és egyéb javításokon túl más módosítások is áthozhatóak a HEAD ágból, így tulajdonképpen ez lesz az aktív ág, amikor a következõ kiadást készítik elõ az adott vonalban. <firstterm>STABLE</firstterm> vagy <firstterm>CURRENT</firstterm>? Minden egyes nagyobb kiadás életciklusában létrejön még egy további fejlesztési ág, amelyet STABLE-nek (megbízhatónak) neveznek. Ezzel jelzi a &os; Projekt, hogy véleménye szerint az adott ágban szereplõ módosítások minõsége elegendõ a szélesebb körû használathoz. Azokat az ágakat pedig, amelyeknek további tesztelésre van szükségük a komolyabb használathoz, CURRENT-nek (aktuálisnak) nevezik. A &os; Projekt nem tudja garantálni, hogy stable-ként szállított szoftverek elegendõek egy telepítéshez. Ezt mindenkinek magának kell eldöntenie. Nem szabad elfelejteni, hogy ez a projekt elsõsorban önkéntesekbõl áll és nem képes a mûködésre semminemû szavatosságot vállalni. <firstterm>Portok</firstterm> vagy <firstterm>csomagok</firstterm>? Az említett állományokon kívül a &os; még több ezernyi, külsõ fejlesztõk által készített alkalmazásokat is támogat. (Ilyenek a különbözõ ablakkezelõ rendszerek, böngészõk, levelezõ kliensek, irodai programcsomagok, és így tovább.) Általánosságban véve nem a projekt maga fejleszti ezeket a szoftvereket, csupán egy keretrendszert biztosít a telepítésükhöz (amelyet Ports Collection-nek (portgyûjtemények) neveznek). Attól függõen, ahogy ezt a licenszelésük megengedi, ezek az alkalmazások telepíthetõek forrásból (ezeket nevezik portoknak), vagy elõre lefordított binárisokból (ezeket nevezik csomagoknak). Ahogy eddig ütemeztük a kiadásokat A &os; 5.X verziójának fejlesztése és kiadása során sok-sok olyan tapasztalatot szereztünk, amelyek csak utólag váltak világossá számunkra. Az 5.X-es vonal célkitûzései meglehetõsen agresszívek voltak és magukban foglalták a következõket: Az SMP (Symmetric MultiProcessing) rendszerek támogatása A teljesítmény növelése a kernelen belüli erõforrás-kiosztás egy új stratégia szerinti átdolgozásával Számos új processzor architektúra támogatása Egy új szálkezelési modell bevezetése Egy új ütemezõ bevezetése Új technológiák, mint például az energiagazdálkodás, támogatása (különösen laptopok esetén); és ami a legfontosabb: Addig nem tekintjük ezt a vonalt STABLE-nek, amíg az imént felsorolt feladatok be nem fejezõdnek. Ez egy olyan helyzet kialakulásához vezetett, ahol évek teltek el a 4.X vonal STABLE és az 5.X vonal STABLE kiadásai között. Ez magával hozott néhány tényleges kellemetlenséget: Az egyszerre kivitelezendõ újításokhoz kapcsolódó módosítások nagy száma jelentõs mértékben megnehezítette az egyes módosítások elkülönítését és beolvasztását a STABLE ágba. Ez pedig azt jelentette, hogy azok a felhasználók, akiknek igazán szüksége volt bizonyos újításokra (például, hogy képesek legyenek futattni a rendszer egy modern hardveren), kényszerûen átálltak (mondjuk) a &os; 5.2.1-es verziójára, annak ellenére, hogy az kifejezetten egy fejlesztõi kiadás volt, és hogy CURRENT kiadás lévén nem felelt meg teljes egészében minden igényüknek. A beolvasztások során a fejlesztõk néha olyan helyzetbe kerültek, ahol olyan verzión kellett az újításaikat támogatniuk, amelyeket nem elsõdleges fejlesztõi platformként használtak. A késés továbbá azt jelentette, hogy mire az 5.3 végre STABLE szintû kiadássá válhatott, az idõközben felgyülemlett módosítások terhe kínszenvedéssé tette a frissítési folyamatot. Úgy szólván senki sem volt elégedett ezzel az eredménnyel. A következõket tanultuk mindezekbõl: A fõbb kiadásoknak kevesebb újítást kell tartalmazniuk és gyakrabban kell megjelenniük. A lehetõ legjobban el kell szigetelni egymástól a különbözõ újításokhoz kapcsolódó módosításokat. (Ez egyben arra is utal, hogy bizonyos fejlesztéseket nem az aktív forrásokon belül végezni, és majd csak akkor beolvasztani õket, ha már nem veszélyeztetik egyik párhuzamos fejlesztést sem.) A fõbb kiadások határidejét inkább idõben kell megszabni, nem pedig az újítások mértékében. Ha az egyes újítások nem készülnek el idõre, akkor ki kell õket kapcsolni és meghagyni egy késõbbi kiadásra. Kevesebb újítással és gyakoribb megjelenéssel remélhetõleg csökkeni fog az egyes módosítások beolvasztásához szükséges idõ a HEAD ágból a legfrissebb STABLE ágba (és ezáltal nem csak egyetlen fejlesztési vonalban maradnak támogathatók). Továbbá, mivel ezek az módosítások kellõképpen elszigeltek egymástól, az integrálás során keletkezõ hibák kockázata is csökken. Sõt, az idõben megkötött határidõknek köszönhetõen végre könnyebben tervezhetnek elõre a felhasználók, a külsõ alkalmazások fejlesztõi és maguk a &os; fejlesztõi is egyaránt. Nem más operációs rendszerek verzióival történõ versenyfutás, hanem ezek a megfontolások indokolják a szándékot, hogy a jövõben az ütemezésünket átszervezzük. Ahogyan majd szeretnénk ütemezni a kiadásokat Íme a Projekt jelenlegi céljai az ütemezésben: Minden 18 hónapban új fõbb kiadás megjelentetése; Minden 4 hónapban új kisebb kiadás megjelentetése; Minden fõbb kiadás legfrissebb kiadásához elõkészített csomagokat nyújtani; Minden fõbb kiadás legutóbbi néhány kiadásához biztonsági frissítéseket és kritikus hibajavításokat (biztonsági fejlesztõi ágak) nyújtani; Tekintettel a telepíthetõ verziók kombinációjának nagy számára, nem lehet minden egyes verziót korlátlanul támogatni; ezt részben a rendelkezésre álló gépi erõforrások korlátozzák, de leginkább a projektben résztvevõ önkéntesek által nyújtott segítség mennyisége. Az érdeklõdõk figyelmébe ajánljuk továbbá: The Release Engineering Schedule The Security Branch Schedule Az említett dokumentumok még nagyobb mélységben részletezik a tárgyalt hátteret, és feltárják azokat folyamatokat, amelyek a támogatott fejlesztõi ágakat és azok élettartalmát illetõ döntéseket befolyásolják. Hogyan befolyásolják ezek a tényezõk a döntésünket? Az alábbi kérdések megválaszolása határozhatja meg a döntést a megfelelõ verzió kiválasztásában: Milyen mértékû megbízhatóságot várunk el a rendszertõl? Mennyire vagyunk hajlandóak frissíteni a rendszerünket? Mennyire gyakran szeretnénk frissíteni a rendszerünket? Mennyire fontos számunkra a biztonság? Forráskódból vagy bináris állományokból akarunk telepíteni? Szeretnénk részt venni a &os; fejlesztésében? Néhány további vázlatos útmutatás a döntéshez: Ha rövid idõn belül az elérhetõ legnagyobb mértékû megbízhatóságból szeretnénk profitálni, viszont nincs lehetõségünk frissíteni, akkor minden bizonnyal a legfrissebb STABLE jelzésû kiadást lenne hasznos feltelepítenünk és használnunk. Biztonsági igényeinknek megfelelõen érdemes követni az adott kiadáshoz megjelenõ javításokat. Ha rövid idõn belül vagy szükségünk van a legfrissebb újításokra vagy pedig a biztonsági javításokra, valamint az idõt és erõforrást sem sajnáljuk a frissítésre, érdemes a legújabb STABLE ágat követnünk. Ha nem kívánjuk közvetlenül élesben használni a rendszert és csak bizonyos problémák érdekelnek minket, valamint a következõ nagyobb kiadás néhány hónapon belül megjelenik, valószínûleg érdemes elgondolkodni annak az ágnak telepítésén, ezzel is segítve a projektet a kiadás tesztelésében, megbízhatóvá tételében és úgy egyáltalán jobbá tenni a hosszú távú használatra. Ha csak forrásból szeretnénk telepíteni és hibákat keresni az alaprendszerben, vagy éppen utánajárni az ismert hibáknak, illetve nyomon követni õket az ezzel kapcsolatos levelezõlistán, érdemes a HEAD fejlesztési ágat használnunk. Végszó Reméljük, ez a leírás hasznos kiindulásnak szolgált a &os; fejlesztési modelljének megértésében és az igényeinknek legjobban megfelelõ verzió kiválasztásában!