diff --git a/hu_HU.ISO8859-2/books/handbook/disks/chapter.sgml b/hu_HU.ISO8859-2/books/handbook/disks/chapter.sgml index 3431c0b110..4ebf552aae 100644 --- a/hu_HU.ISO8859-2/books/handbook/disks/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/disks/chapter.sgml @@ -1,5893 +1,5908 @@ Háttértárak Áttekintés Ez a fejezet arról szól, hogy miként használjuk a lemezeinket a &os;-vel. Itt többek közt szó esik a memória (alapú) lemezekrõl, a hálózaton keresztül csatlakoztatott meghajtókról, a szabványos SCSI/IDE tárolóeszközökrõl és az USB felületet használó eszközökrõl. A fejezet elolvasása során megismerjük: a &os; által alkalmazott terminológiát, amivel a fizikai lemezeken elhelyezkedõ adatokat írja le (partíciók és slice-ok); hogyan bõvítsük rendszerünket további merevlemezekkel; hogyan állítsuk be a &os;-t USB tárolóeszközök használatára; hogyan állítsunk be virtuális állományrendszereket, például memórialemezeket; hogyan használjuk a kvótákat a lemezterület használatának korlátozására; hogyan védjüket meg lemezeinket titkosítással az illetéktelenektõl; &os; alatt hogyan készítsünk és írjuk CD-ket, DVD-ket; a biztonsági mentések készítésének különbözõ lehetõségeit; hogyan használjuk a &os; alatt rendelkezésünkre álló, biztonsági mentést készítõ programokat; hogyan mentsünk floppy lemezekre; mik az állományrendszerek pillanatképei és hogyan kell ezeket hatékonyan használni. A fejezet elolvasásához ajánlott: a &os; rendszermag beállításának és telepítésének ismerete () Az eszközök elnevezései A most következõ listában felsoroljuk a &os; által ismert fizikai tárolóeszközöket és a hozzájuk tartozó elnevezéseket. A fizikai lemezek elnevezésének szabályai A meghajtó típusa A meghajtóeszköz neve IDE merevlemezek ad IDE CD-meghajtók acd SCSI merevlemezek és USB tárolóeszközök da SCSI CD-meghajtók cd Különbözõ nem szabványos CD-meghajtók mcd (Mitsumi CD-ROM) és scd (Sony CD-ROM) Floppy meghajtók fd SCSI szalagos meghajtók sa IDE szalagos meghajtók ast Flash meghajtó fla (&diskonchip; Flash eszköz) RAID meghajtók aacd (&adaptec; AdvancedRAID), mlxd és mlyd (&mylex;), amrd (AMI &megaraid;), idad (Compaq Smart RAID), twed (&tm.3ware; RAID).
David O'Brien Eredetileg írta: Lemezek hozzáadása lemezek hozzáadás Ebben a szakaszban arról lesz szó, hogy a jelenleg egyetlen meghajtót tartalmazó rendszerünket hogyan tudjuk bõvíteni egy új SCSI-lemez hozzáadásával. Ehhez elsõként kapcsoljuk ki a számítógépünket és szereljük be a helyére az új meghajtót a számítógép, a lemezvezérlõ és a meghajtó gyártójának utasításai alapján. Mivel ezt a mûveletet rengeteg módon lehet elvégezni, ezért ennek pontos részleteivel ez a leírás most nem foglalkozik. Jelentkezzünk be root felhasználóként. Miután beszereltük a meghajtót, a /var/run/dmesg.boot állomány végignézésével bizonyosodjuk meg róla, hogy a rendszer valóban megtalálta a lemezt. A példánk szerint ez a meghajtó tehát a da1 nevet fogja viselni, amelyet a /1 könyvtárba akarunk csatlakoztatni (ha IDE-meghajtót telepítünk, akkor a hozzátartozó eszköz neve ad1 lesz). partíciók slice-ok fdisk Mivel a &os; IBM PC kompatibilis számítógépeken fut, ezért nem szabad figyelmen kívül hagynunk a PC BIOS partícióit is. Ezek eltérnek a hagyományos BSD partícióktól. Egy PC-s lemeznek négy BIOS-os partícióbejegyzése lehet. Ha egy lemezt tényleg csak a &os;-nek szánunk, akkor használhatjuk az ún. dedikált módot. Minden más esetben a &os;-nek egy PC BIOS partícióban kell elhelyezkednie. A &os; a PC BIOS partícióit slice-nak nevezi, ezzel különbözteti ezeket a hagyományos BSD partícióktól. Dedikált esetekben is használhatjuk, de elsõsorban akkor kap fontosabb szerepet, amikor a &os;-nek más operációs rendszerekkel kell megosztani a helyet. Ezzel el tudjuk kerülni, hogy a más operációs rendszerekben megtalálható, nem &os; alapú fdisk parancs megzavarodjon. A slice-ok használatakor a meghajtó /dev/da1s1e néven kerül hozzáadásra. Így kell olvasni: egyes SCSI lemezes egység (második SCSI lemez), elsõ slice (elsõ PC BIOS partíció) és e BSD partíció. A dedikált esetben a meghajtó neve viszont egyszerûen csak /dev/da1e. Mivel a &man.bsdlabel.8; 32 bites egész számokat használ a szektorok számának tárolására, ezért lemezenként csak 2^32-1 szektort tud ábrázolni, ami az esetek többségében 2 TB méretû címezhetõ területet jelent. Az &man.fdisk.8; formátuma szerint sem a kezdõszektor, sem a hossz nem lehet 2^32-1-nél több, amivel így a partíciókat 2 TB, a lemezeket pedig 4 TB méretûre korlátozza. A &man.sunlabel.8; formátuma partíciónként 2^32-1 szektort enged meg és összesen 8 partíciót, amely ezáltal 16 TB terület lefedését teszi lehetõvé. Nagyobb lemezekhez &man.gpt.8; partíciók használatosak. A &man.sysinstall.8; használatával sysinstall lemezek hozzáadása su Közlekedés a <application>sysinstall</application> programban A sysinstall könnyen használható menüinek segítségével az új lemezen pillanatok alatt létre tudunk hozni partíciókat és megcímkézni ezeket. Ehhez vagy root felhasználóként jelentkezzünk be a rendszerbe, vagy adjuk ki a su parancsot. A sysinstall parancs kiadása után lépjünk be a Configure (Beállítások) menübe. A &os; Configuration Menu menüben ezután keressük meg és válasszuk ki az Fdisk menüpontot. Az <application>fdisk</application> partíciószerkesztõ Miután eljutottunk az fdisk alkalmazáshoz, az A lenyomásával felajánlhatjuk az egész lemezt a &os; számára. Amikor elõkerül a kérdés, hogy remain cooperative with any future possible operating systems (mûködõképes maradjon-e a késõbbiekben telepítendõ operációs rendszerekkel), akkor válaszoljuk rá YES-szel (tehát igen). A W gomb lenyomásával írjuk a lemezre a most elvégzett változtatásokat. Ezután már a Q használatával ki is léphetünk az FDISK szerkesztõbõl. A következõ lépésben a Master Boot Record-ról fognak minket megkérdezni. Mivel most egy már mûködõ rendszert bõvítünk, ezért a válaszunk erre None lesz. A lemezcímkék szerkesztése BSD partíciók Most lépjünk ki a sysinstall alkalmazásból és indítsuk el újra. Kövessük az iménti útmutatásokat, de ezúttal a Label menüpontot válasszuk ki. Ezzel a Disk Label Editor-ba vagyis a lemezcímkék szerkesztõjéhez jutunk. Itt fogjuk létrehozni a hagyományos BSD partíciókat. Egy lemezen nyolc ilyen partíció lehet, a-tól h-ig. Közülük néhány partíció címkéjét megkülönböztetjük. Az a partíció jelöli a rendszer indításához használt partíciót, a gyökérpartíciót (/). Tehát a partíció csak a rendszerlemezünkön szerepelhet (tehát ahonnan indul a rendszer). A b partíció a lapozáshoz használt partíciókat jelöli és több lemezen is szerepelhet. A c partíción keresztül lehet elérni az egészt lemezt dedikált módban vagy az egész &os; slice-ot slice módban. A többi partíció tetszõlegesen felhasználható. A sysinstall címkeszerkesztõje az e betûvel szereti megjelölni a sem nem rendszerindító, sem nem lapozó partíciókat. A címkeszerkesztõben egyetlen állományrendszert a C lenyomásával lehet készíteni. Amikor erre válaszul megkérdezi a típusát (FS (állományrendszer) vagy swap (lapozóterület) legyen), akkor válasszuk az FS beállítást és adjuk meg a csatlakozási pontját (például /mnt). Amikor a lemezt telepítés után (post-install) adjuk hozzá, akkor a sysinstall valójában nem hoz létre hozzá bejegyzéseket az /etc/fstab állományban, ezért a csatlakozási pont megadása nem is feltétlenül fontos. Most már készen állunk arra, hogy rögzítsük az új címkét a lemezre és létrehozzunk vele egy állományrendszert. Ehhez nyomjuk le a W gombot. Ne foglalkozzunk vele, ha a sysinstall nem képes csatlakoztatni az új partíciót. Ha ezzel megvagyunk, akkor lépjünk ki a címkeszerkesztõbõl és a sysinstallból is. Befejezés Most már csak annyi teendõnk maradt, hogy felvegyük az /etc/fstab állományba az új lemezhez tartozó bejegyzést. Parancssoros eszközök használatával Slice módban Ezzel a beállítással a lemezünkre késõbb más operációs rendszereket is telepíthetünk, és nem okoz gondot a saját fdisk segédprogramjaik mûködésében. Az új lemezek telepítésénél ezt a módszer ajánlatos követni. A dedikált módot viszont csak abban az esetben használjuk, ha erre nyomós okunk van! &prompt.root; dd if=/dev/zero of=/dev/da1 bs=1k count=1 &prompt.root; fdisk -BI da1 # inicializáljuk az új lemezt &prompt.root; bsdlabel -B -w da1s1 auto # címkézzük meg &prompt.root; bsdlabel -e da1s1 # szerkeszzük át a frissen létrehozott címkét és vegyünk fel egy új partíciót &prompt.root; mkdir -p /1 &prompt.root; newfs /dev/da1s1e # ismételjük meg minden létrehozott partícióhoz &prompt.root; mount /dev/da1s1e /1 # csatlakoztassuk a partíció(ka)t &prompt.root; vi /etc/fstab # vegyük fel a megfelelõ bejegyzés(eke)t az /etc/fstab állományba IDE-lemezek esetén azad eszközt a da eszközzel helyettesítsük. Dedikált módban OS/2 Amennyiben az új meghajtót nem akarjuk megosztani egyetlen más operációs rendszerrel sem, használhatjuk a dedicated (dedikált) módot. Ne felejtsük el azonban, hogy ez képes összezavarni a Microsoft operációs rendszereit, habár ebbõl semmilyen kárunk nem fog származni. Az IBM &os2; operációs rendszere azonban kisajátít minden olyan partíciót, amelyet nem tud olvasni. &prompt.root; dd if=/dev/zero of=/dev/da1 bs=1k count=1 &prompt.root; bsdlabel -Bw da1 auto &prompt.root; bsdlabel -e da1 # létrehozzuk az `e' partíciót &prompt.root; newfs /dev/da1e &prompt.root; mkdir -p /1 &prompt.root; vi /etc/fstab # felvesszük a /dev/da1e partíciót &prompt.root; mount /1 Egy másik megoldás: &prompt.root; dd if=/dev/zero of=/dev/da1 count=2 &prompt.root; bsdlabel /dev/da1 | bsdlabel -BR da1 /dev/stdin &prompt.root; newfs /dev/da1e &prompt.root; mkdir -p /1 &prompt.root; vi /etc/fstab # felvesszük a /dev/da1e partíciót &prompt.root; mount /1 RAID Szoftveres RAID Christopher Shumway Eredetileg készítette: Jim Brown Ellenõrizte: RAIDszoftveres RAIDCCD Összefûzött lemezek beállítása A nagyobb méretû háttértárolók kiválasztásánál a legfontosabb tényezõk a sebesség, megbízhatóság és a költség. Nagyon ritkán lehet csak ezt a hármat egyensúlyba hozni: általában a gyors és megbízható tárolóeszközök sok pénzbe kerülnek, valamint a költségek megtakarításához vagy a sebességet vagy pedig a megbízhatóságot kell feláldoznunk. A továbbiakban egy olyan rendszert mutatunk be, ahol a elsõsorban a költségek, majd csak ezután a sebesség és megbízhatóság kerültek elõtérben. A rendszer adatátviteli sebességét a hálózat korlátozza. Habár emellett a megbízhatóság is nagyon fontos, a tárgyalt összefûzött meghajtó (Concenated Disk, CCD) csak adatokat szolgáltat és a teljes tartalma bármikor visszaállítható, mivel rendelkezésre áll CD-n. A feladat elvégzésére alkalmas háttértároló kiválasztásában elsõként a saját elvárásainkat kell tudnunk megfogalmazni. Ha nekünk jobban számít az árnál a sebesség vagy a megbízhatóság, akkor a mostaniaktól némileg eltérõ konfigurációt kell majd építenünk. A hardver telepítése A rendszert tartalmazó IDE-lemez mellett három darab, egyenként 30 GB-os 5400-as percenkénti fordulatszámú Western Digital gyártmányú merevlemez alkotja majd a létrehozni kívánt, kb. 90 GB összméretû összefûzött lemezt. Ideális esetben minden IDE-lemez saját külön vezérlõn és kábelen van, de a költségek csökkentése miatt nem használtunk további IDE-vezérlõket. Ehelyett inkább jumperekkel úgy állítottuk be a lemezeket, hogy minden vezérlõre egy mester (master) és egy szolga (slave) módú merevlemez kapcsolódjon. A beszerelés után beállítottuk a rendszer BIOS-át, hogy automatikusan felismerje a csatlakoztatott lemezeket. De ami még fontosabb, hogy a &os; is észlelte ezeket az indítás során: ad0: 19574MB <WDC WD205BA> [39770/16/63] at ata0-master UDMA33 ad1: 29333MB <WDC WD307AA> [59598/16/63] at ata0-slave UDMA33 ad2: 29333MB <WDC WD307AA> [59598/16/63] at ata1-master UDMA33 ad3: 29333MB <WDC WD307AA> [59598/16/63] at ata1-slave UDMA33 Ha a &os; nem látná az összes lemezt, akkor ellenõrizzük a jumperek helyes beállítását. Napjainkban a legtöbb IDE-meghajtón találunk egy Cable Select jumpert is. Ezzel nem a mester/szolga módot állítjuk be! A megfelelõ jumper beazonosításához olvassuk el a meghajtóhoz tartozó dokumentációt. A következõ lépésben azt vesszük nagyító alá, hogyan lehet ezeket az állományrendszer részévé tenni. Ezzel kapcsolatban a &man.vinum.8; () és a &man.ccd.4; elolvasása ajánlatos. Erre a célra itt most a &man.ccd.4; használatát választottuk. A CCD beállítása A &man.ccd.4; meghajtó segítségével több ugyanolyan lemezt tudunk összefûzni egyetlen logikai állományrendszerré. A &man.ccd.4; használatához arra is szükségünk van, hogy a &man.ccd.4; támogatása jelen legyen a rendszermagban. A következõ sor tegyük bele a rendszermag konfigurációs állományába, fordítsuk újra és telepítsük a rendszermagot: device ccd A &man.ccd.4; támogatása modulként is betölthetõ. A &man.ccd.4; beállításához elõször a &man.bsdlabel.8; programmal meg fel kell címkéznünk a lemezeket: bsdlabel -w ad1 auto bsdlabel -w ad2 auto bsdlabel -w ad3 auto Így létrejön egy-egy BSD típusú címke a ad1c, ad2c és ad3c eszközökre, amely így lefedi a lemez egész területét. Most pedig változtassuk meg a lemezcímke típusát. Ehhez használjuk ismét a &man.bsdlabel.8; programot: bsdlabel -e ad1 bsdlabel -e ad2 bsdlabel -e ad3 Az EDITOR környezeti változóban megadott szövegszerkesztõvel (ez általában a &man.vi.1;) megnyílik minden egyes lemezhez a jelenlegi lemezcímke. Egy módosítatlan lemezcímke valahogy így néz ki: 8 partitions: # size offset fstype [fsize bsize bps/cpg] c: 60074784 0 unused 0 0 0 # (Cyl. 0 - 59597) A &man.ccd.4; számára hozzunk létre egy új e partíciót. Ezt lényegében a c partíció lemásolásával keletkezik, de nála az (az állományrendszer típusa) oszlopban mindenképpen 4.2BSD szerepeljen! A lemezcímke most már valahogy így fog kinézni: 8 partitions: # size offset fstype [fsize bsize bps/cpg] c: 60074784 0 unused 0 0 0 # (Cyl. 0 - 59597) e: 60074784 0 4.2BSD 0 0 0 # (Cyl. 0 - 59597) Az állományrendszer kiépítése Most, miután felcímkéztük az összes lemezünket, lássunk neki a &man.ccd.4; kiépítésének. Ezt a &man.ccdconfig.8; meghívásával és az alábbihoz hasonló paraméterek átadásával tehetjük meg: ccdconfig ccd0 32 0 /dev/ad1e /dev/ad2e /dev/ad3e A paraméterek rövid leírása és használata: Az elsõ paraméter a létrehozandó eszköz, ami jelen esetünkben a /dev/ccd0c. A /dev/ részt nem kötelezõ megadni. A kihagyás nagysága az állományrendszerben. A kihagyás határozza meg a lemezblokkban alkalmazott csíkozás (striping) vastagságát, ami általában 512 byte. Ennek megfelelõen a 32-es kihagyás 16 384 byte-os csíkokat ad meg. A &man.ccdconfig.8; beállításai. Ha engedélyezni akarjuk a lemezek tükrözését, akkor itt megadhatjuk. Mivel ez a konfiguráció most nem nyújt tükrözést a &man.ccd.4; számára, ezért állítsuk nullára (0). A &man.ccdconfig.8; parancsnak utolsóként azokat az eszközöket kell felsorolni, amelyeket tömbbe akarunk fûzni. Minden eszközt teljes elérési úttal adjuk meg. A &man.ccdconfig.8; futtatása után a &man.ccd.4; beállítódik. Most már állományrendszert is rakhatunk rá. A &man.newfs.8; man oldalról szedjük össze a szükséges paraméterezést, vagy egyszerûen csak gépeljünk be ennyit: newfs /dev/ccd0c Az egész önmûködõvé tétele A &man.ccd.4; eszközt általában minden egyes indítás után használni akarjuk. Ennek eléréséhez elõször ezt be kell állítanunk. Az alábbi parancs kiadásával írassuk be a jelenlegi beállítasainkat tükrözõ /etc/ccd.conf állományt: ccdconfig -g > /etc/ccd.conf Az újraindítás során az /etc/rc parancs futtatja le a ccdconfig -C parancsot, ha az /etc/ccd.conf állomány létezik. Ez automatikusan beállítja a &man.ccd.4; eszközöket, így ilyenkor tudjuk csatlakoztatni is ezeket. Ha egyfelhasználós módban indítjuk a rendszert, mielõtt még a &man.mount.8; paranccsal csatlakoztatni tudnánk a &man.ccd.4; eszközt, a tömb beállításához meg kell hívnunk a következõ parancsot: ccdconfig -C Ha a rendszerindításkor automatikusan csatlakoztatni akarjuk a &man.ccd.4; eszközt, akkor az /etc/fstab állományba helyezzünk el egy hozzátartozó bejegyzést: /dev/ccd0c /media ufs rw 2 2 A Vinum kötetkezelõ RAID szoftveres RAID Vinum A Vinum kötetkezelõ egy blokkos eszközmeghajtó, ami virtuális lemezes meghajtókat valósít meg. Elkülöníti a lemezes hardvereszközöket a blokkos eszközmeghajtók felületétõl és a kettõ között úgy képezi le az adatokat, hogy a hagyományos lemezes tárolással szemben megnövekedett rugalmasságot, teljesítményt és megbízhatóságot kapunk. A &man.vinum.8; ismeri a RAID-0, RAID-1 és RAID-5 modelleket egyaránt, melyeket önmagukban és együttesen kombinálva is használhatunk. A bõvebben ismerteti a &man.vinum.8; rendszerét. Hardveres RAID RAID hardveres A &os; rengeteg különbözõ típusú hardveres RAID-vezérlõt ismer. Ezek az eszközök a &os; külön erre a célra szánt támogatása nélkül képesek vezérelni a RAID-alrendszert. A rajta levõ BIOS segítségével a kártya a legtöbb lemezmûveletet egyedül kezeli. A következõkben egy Promise IDE RAID vezérlõt alkalmazó rendszert fogunk beállítani. Miután telepítettük a kártyát és indítjuk a rendszert, bekéri a szükséges információkat. Kövessük az utasításokat és lépjünk be a kártya beállító képernyõjére. Itt tudjuk kombinálni az összes csatlakoztatott meghajtónkat. Amikor ezzel a végeztünk, a lemezek egyetlen lemezként fognak a &os; számára viselkedni. A többi RAID-szint is ehhez hasonlóan állítható be. Az ATA RAID-1 tömbök újraszervezése A &os; lehetõséget a tömbben levõ meghibásodott eszközök menet közben elvégezhetõ cseréjére. Ehhez arra van szükségünk, hogy még újraindítás elõtt elcsípjük a hibát. Hiba esetén valami hasonlót fogunk látni a /var/log/messages állományban vagy a &man.dmesg.8; kimenetében: ad6 on monster1 suffered a hard error. ad6: READ command timeout tag=0 serv=0 - resetting ad6: trying fallback to PIO mode ata3: resetting devices .. done ad6: hard error reading fsbn 1116119 of 0-7 (ad6 bn 1116119; cn 1107 tn 4 sn 11)\\ status=59 error=40 ar0: WARNING - mirror lost További információkat az &man.atacontrol.8; programtól szerezhetünk: &prompt.root; atacontrol list ATA channel 0: Master: no device present Slave: acd0 <HL-DT-ST CD-ROM GCR-8520B/1.00> ATA/ATAPI rev 0 ATA channel 1: Master: no device present Slave: no device present ATA channel 2: Master: ad4 <MAXTOR 6L080J4/A93.0500> ATA/ATAPI rev 5 Slave: no device present ATA channel 3: Master: ad6 <MAXTOR 6L080J4/A93.0500> ATA/ATAPI rev 5 Slave: no device present &prompt.root; atacontrol status ar0 ar0: ATA RAID1 subdisks: ad4 ad6 status: DEGRADED A lemez biztonságos eltávolításához elõször válasszuk le (detach) a meghibásodott lemezhez tartozó csatornát: &prompt.root; atacontrol detach ata3 Cseréljük ki a lemezt. Csatlakoztassuk újra (attach) az ATA csatornát: &prompt.root; atacontrol attach ata3 Master: ad6 <MAXTOR 6L080J4/A93.0500> ATA/ATAPI rev 5 Slave: no device present Tartalékként (spare) adjuk hozzá az új lemezt a tömbhöz: &prompt.root; atacontrol addspare ar0 ad6 Szervezzük újra (rebuild) a tömböt: &prompt.root; atacontrol rebuild ar0 A folyamat elõrehaladását a következõ parancs begépelésével tudjuk figyelni: &prompt.root; dmesg | tail -10 [a kimenet többi része] ad6: removed from configuration ad6: deleted from ar0 disk1 ad6: inserted into ar0 disk1 as spare &prompt.root; atacontrol status ar0 ar0: ATA RAID1 subdisks: ad4 ad6 status: REBUILDING 0% completed Várjunk a mûvelet befejezõdéséig. Marc Fonvieille Írta: USB tárolóeszközök USB lemezek Manapság már számos külsõ tárolóeszköz az USB (Universal Serial Bus) közvetítésével csatlakozik a számítógéphez: merevlemezek, pen drive-ok, CD-írók stb. A &os; ezeket az eszközöket is ismeri. Beállítás A USB tárolóeszközöket kezelõ meghajtó, az &man.umass.4; felelõs az USB alapú tárolóeszközök támogatásáért. Ha a GENERIC rendszermagot használjuk, akkor semmit sem kell változtatnunk. Ha saját rendszermagunk van, akkor gondoskodjunk róla, hogy a következõ sorokat beraktuk a rendszermag beállításait tartalmazó állományba: device scbus device da device pass device uhci device ehci device usb device umass Az &man.umass.4; meghajtó a SCSI alrendszeren keresztül éri el az USB tárolóeszközöket, tehát az USB eszközeinket a rendszer SCSI eszközként látja. Az alaplapon található USB chipkészlet típusától függõen vagy csak a device uhci, vagy USB 1.X esetén pedig a device ohci bejegyzésre lesz szükségünk. De abból sem származik kárunk, ha mind a kettõt meghagyjuk. Az USB 2.0 szabványú vezérlõket a &man.ehci.4; meghajtó (device ehci) támogatja. Ha módosítani kellett a konfigurációs állományt, akkor ne felejtsük el újrafordítani és telepíteni sem a rendszermagot. Ha az USB eszközünk egy CD- vagy DVD-író, akkor a következõ sorral a SCSI CD-meghajtók meghajtóját, a &man.cd.4; eszközt kell beépítenünk a rendszermagba: device cd Mivel az író is SCSI eszközként látszik, ezért az &man.atapicam.4; nem szerepelhet a rendszermag beállításai között. A beállítások kipróbálása A beállításaink készen állnak a kipróbálásra: csatlakoztassuk a számítógéphez az USB eszközünket és a rendszerüzeneteket tároló pufferben (&man.dmesg.8;) hamarosan meg is jelenik a hozzátartozó meghajtó: umass0: USB Solid state disk, rev 1.10/1.00, addr 2 GEOM: create disk da0 dp=0xc2d74850 da0 at umass-sim0 bus 0 target 0 lun 0 da0: <Generic Traveling Disk 1.11> Removable Direct Access SCSI-2 device da0: 1.000MB/s transfers da0: 126MB (258048 512 byte sectors: 64H 32S/T 126C) Természetesen a gyártóra, márkára, az eszköz leírójára (da0) és egyebekre vonatkozó részletek eltérhetnek. Mivel az USB eszköz SCSI eszközként látszik, ezért a camcontrol parancs használható a rendszerhez csatlakoztatott USB tárolóeszközök listázásához: &prompt.root; camcontrol devlist <Generic Traveling Disk 1.11> at scbus0 target 0 lun 0 (da0,pass0) Ha a meghajtón állományrendszer is található, akkor képesek vagyunk csatlakoztatni. A elolvasása segíthet az USB meghajtón partíciókat kialakítani és formázni, amennyiben szükséges. + + A rendszer biztonsága szempontjából + nem tekinthetõ megbízhatónak, ha olyan + felhasználók számára is + engedélyezzük tetszõleges meghajtók + csatlakoztatását (például a + vfs.usermount + engedelyézesével), amelyekben nem bízunk + meg. A &os; által támogatott + állományrendszerek döntõ + többsége nem nyújt védelmet a + káros szándékkal telepített + eszközök ellen. + + Ha az eszközt normál felhasználókkal is csatlakoztathatóvá akarjuk tenni, akkor további lépések megtételére is szükségünk lesz. Elõször is a felhasználóknak valahogy el kell tudniuk érniük az USB tárolóeszköz csatlakoztatásakor keletkezõ eszközöket. Ezt úgy tudjuk megoldani, ha az érintett felhasználókat felvesszük az operator csoportba. Ebben a &man.pw.8; lehet a segítségünkre. Másodsorban amikor ezek az eszközök létrejönnek, az operator csoportnak tudniuk kell ezeket olvasniuk és írniuk. Ezt úgy tudjuk megvalósítani, ha felvesszük a következõ sorokat az /etc/devfs.rules állományba: [localrules=5] add path 'da*' mode 0660 group operator Ha viszont vannak SCSI lemezeink is rendszerben, akkor a helyzet egy kicsit megváltozik. Tehát például a rendszerben már eleve vannak da0, da1 és da2 néven lemezek, akkor a második sort ennek megfelelõen változtassuk meg: add path 'da[3-9]*' mode 0660 group operator Ezzel kizárunk minden, korábban már létezõ lemezt az operator csoportból. Emellett még az /etc/rc.conf állományban engedélyeznünk kell a saját &man.devfs.rules.5; szabályrendszerünket is: devfs_system_ruleset="usb_rules" Ezt követõen be kell állítanunk a rendszermagban, hogy a hagyományos felhasználók képesek legyenek állományrendszereket csatlakoztatni. Ezt a legkönnyebb úgy tudjuk megtenni, ha az /etc/sysctl.conf állományba felvesszük a következõ sort: vfs.usermount=1 Azonban ne felejtsük el, hogy ez csak a rendszer következõ indításától él. De a &man.sysctl.8; parancs használatával is beállíthatjuk ezt az értéket. Az utolsó lépésben hozzunk létre egy könyvtárat az állományrendszer csatlakoztatásához. Ezt a könyvtárat az a felhasználó fogja birtokolni, aki az állományrendszert csatlakoztatnia akarja. Ez például root felhasználóként úgy tudjuk megtenni, ha a felhasználónak létrehozunk egy könyvtárat /mnt/felhasználó néven (ahol a felhasználó nevet cseréljük a tényleges felhasználó nevére, a csoport nevet pedig a felhasználóhoz tartozó elsõdleges csoport nevére): &prompt.root; mkdir /mnt/felhasználó &prompt.root; chown felhasználó:csoport /mnt/felhasználó Most tegyük fel, hogy csatlakoztatnuk egy USB pen drive-ot és ennek megfelelõen megjelenik a /dev/da0s1 eszköz. Mivel az ilyen eszközökre általában gyárilag FAT állományrendszert tesznek, ezért így kell ezeket csatlakoztatni a &man.mount.8; paranccsal: &prompt.user; mount -t msdosfs -o -m=644,-M=755 /dev/da0s1 /mnt/felhasználó Ha leválasztjuk az eszközt (miután kiadtuk a &man.umount.8; parancsot), akkor a rendszerüzenetek között valami ilyesmit fogunk látni: umass0: at uhub0 port 1 (addr 2) disconnected (da0:umass-sim0:0:0:0): lost device (da0:umass-sim0:0:0:0): removing device entry GEOM: destroy disk da0 dp=0xc2d74850 umass0: detached A témáról bõvebben A Lemezek hozzáadása és az Állományrendszerek csatlakoztatása és leválasztása címû szakaszok elolvasása mellett a következõ man oldalakat is ajánljuk: &man.umass.4;, &man.camcontrol.8; és &man.usbconfig.8; &os; 8.X esetében, vagy &man.usbdevs.8; a &os; korábbi változatainál. Mike Meyer Írta: Lézeres tárolóeszközök (CD-k) létrehozása és használata CD-k létrehozása Bevezetés A CD-k számos lehetõségünkben eltérnek a hagyományos lemezektõl. Kezdetben a felhasználók nem is voltak képesek írni ezeket. Olyannak tervezték, hogy a fejek sávok közti mozgásából fakadó késleltetés nélkül lehessen folyamatosan olvasni. A szállítása a maga idejében sokkal könnyebb volt minden vele egyforma méretû eszköznél. A CD-ken is találhatunk sávokat, azonban ez csak a folyamatosan olvasható adat egy szakaszát jelenti, nem pedig a lemez fizikai tulajdonságát. Ha &os;-n akarunk CD-t készíteni, akkor ehhez elõször össze kell állítanunk a CD egyes sávjaira kerülõ adatokat és ezután rögzíteni ezeket a sávokat a CD-n. ISO 9660 állományrendszerek ISO 9660 Az ISO 9660 állományrendszert úgy tervezték, hogy megbirkózzon ezekkel az eltérésekkel. Sajnos ezzel együtt kõbe vésték az állományrendszerek akkoriban érvényes korlátozásait is. Szerencsére lehetõséget ad bõvítésre, ezáltal a helyesen megírt CD-k képesek úgy átlépni ezeket a határokat, hogy közben az általuk alkalmazott kiterjesztéseket nem ismerõ rendszerekkel is együtt tudnak mûködni. sysutils/cdrtools A sysutils/cdrtools port tartalmaz egy &man.mkisofs.8; nevû programot, amellyel létre tudunk hozni ISO 9660 típusú állományrendszert tartalmazó adatállományt. Többféle kiterjesztést is ismer, amit majd a lentebb ismertett opciókkal érhetünk el. CD-író ATAPI A CD írásához használt konkrét segédeszköz attól függ, hogy ATAPI vagy esetleg másmilyen írónk van. Az ATAPI CD-írók az alaprendszer részeként elérhetõ burncd programon keresztül használhatóak. A SCSI és USB CD-írók esetén pedig a sysutils/cdrtools portban megtalálható cdrecord programot használhatjuk. Az ATAPI/CAM modul segítségével a cdrecord és más SCSI-írókra készült programokat is tudunk használni ATAPI hardvereken. Ha a CD-író szoftverünket grafikus felhasználói felületen keresztül szeretnénk használni, akkor az X-CD-Roast vagy a K3b alkalmazásokat érdemes szemügyre vennünk. Ezek az eszközök elérhetõek csomagként vagy a sysutils/xcdroast és sysutils/k3b portokból. ATAPI hardver esetén az X-CD-Roast és a K3b alkalmazások használatához szükségünk lesz az ATAPI/CAM modulra. mkisofs A sysutils/cdrtools port részeként elérhetõ &man.mkisofs.8; program képes a &unix; típusú állományrendszer könyvtárszerkezete alapján egy ISO 9660 típusú állományrendszert tartalmazó image-et készíteni. Legegyszerûbb módon így használhatjuk: &prompt.root; mkisofs -o image.iso /az/elérési/út állományrendszerek ISO 9660 Ezzel a paranccsal egy olyan image.iso nevû állományt hozunk létre, amely /az/elérési/út által megadott helyen található könyvtárszerkezetet mintázza ISO 9660 állományrendszer formájában. A folyamat során minden olyan állományt leképez szabványos ISO 9660 állományrendszerbeli névre, amely megfelel a szabvány elvárásainak, és kihagy minden olyan állományt, amely nem jellemzõ az ISO állományrendszerekre. állományrendszerek HFS állományrendszerek Joliet Számos opció lehet segítségünkre az ilyenkor felbukkanó akadályok leküzdésében. Ezek közül különösen fontos az , amely a &unix; rendszerek számára megszokott Rock Ridge kiterjesztéseket, valamint a , amely a Microsoft rendszerekben használt Joliet kiterjesztéseit, és végül a , amely a &macos; alatt létrehozott HFS állományrendszerek kiterjesztéseit engedélyezi. A kizárólag csak &os; rendszereken használt CD-k esetében a megadásával kapcsolhatjuk ki az állománynevek mindenféle korlátozását. Az beállítás használatával olyan állományrendszer képét hozzuk létre, amely teljesen megegyezik a parancsban megadott könyvtárból induló fa tartalmával, habár több módon is sérti az ISO 9660 szabvány elõírásait. CD-k rendszerindításhoz Az utolsó általános jelleggel használható beállítás a . Ezzel lehet megadni az El Torito szabványnak megfelelõ rendszerindító CD készítéséhez szükséges rendszerindító image elérését. Ennél a beállításnál tehát meg kell adni a rendszerindításhoz használt lemez image-ét, amely a CD tartalmát magában foglaló könyvtárszerkezetben található valahol. A &man.mkisofs.8; alapértelmezés szerint egy ún. floppy emulációs módban hozza létre az ISO image-et, ezért a rendszerindításhoz használatos lemez image-ének pontosan 1200, 1440 vagy 2880 KB méretûnek kell lennie. Egyes rendszerbetöltõk, mint amilyen például a &os; terjesztéséhez használt lemezeken található, nem használják ezt az emulációt. Ilyen helyzetekben a kapcsolót kell megadni. Tehát ha a /tmp/sajátboot könyvtárban van egy indítható &os; rendszerünk, amelyben a /tmp/sajátboot/boot/cdboot a rendszerindító lemez image-e, akkor egy /tmp/indítható.iso nevû ISO 9660 formátumú állományrendszert tartalmazó image-et például így tudunk elkészíteni: &prompt.root; mkisofs -R -no-emul-boot -b boot/cdboot -o /tmp/indítható.iso /tmp/sajátboot Miután ezt megtettük, és a rendszermagunkban benne van az md eszköz támogatása, csatlakoztathatjuk is az állományrendszert: &prompt.root; mdconfig -a -t vnode -f /tmp/indítható.iso -u 0 &prompt.root; mount -t cd9660 /dev/md0 /mnt Ezután már össze tudjuk vetni az /mnt és /tmp/sajátboot könyvtárak egyezõségét. A &man.mkisofs.8; viselkedését több más opcióval tudjuk finomhangolni, mint például az ISO 9660 kiosztás módosítása vagy a Joliet és HFS lemezek készítése. A &man.mkisofs.8; man oldalon mindezekrõl bõvebben olvashatunk. burncd CD-k írása Ha ATAPI CD-írónk van, akkor a burncd paranccsal írhatjuk az ISO image-et a lemezre. A burncd az alaprendszer része, és /usr/sbin/burncd néven érhetõ el. A használata igen egyszerû, csupán pár paramétere van: &prompt.root; burncd -f eszköz data image.iso fixate Ezzel a paranccsal rámásoljuk az image.iso állományt az eszköz eszközre. Az alapértelmezett eszköz a /dev/acd0. A &man.burncd.8; man oldalán találjuk meg az írási sebességgel, a CD írás utáni kiadásával és az audio lemezek írásával kapcsolatos beállításokat. cdrecord Ha nincs ATAPI CD-írónk, akkor az íráshoz a cdrecord parancsot kell használnunk. A cdrecord nem az alaprendszer része: vagy a sysutils/cdrtools portból vagy a neki megfelelõ csomagból kell telepítenünk. Az alaprendszerben végbemenõ változások miatt a program bináris változatai hibázhatnak, aminek következtében csak poháralátéteket fogunk tudni gyártani. Ezért a rendszerrel együtt érdemes frissíteni ezt a portot is. Vagy ha a -STABLE verziót használjuk, akkor mindig érdemes a port elérhetõ legújabb verziójára frissíteni. Miközben a cdrecord számos paraméterrel rendelkezik, az alapvetõ használata mégis egyszerûbb a burncd parancsénál. Egy ISO 9660 formátumú image-et ugyanis a következõ módon tudunk felírni lemezre: &prompt.root; cdrecord dev=eszköz image.iso A cdrecord használatának trükkös része a megfelelõ eszköz megtalálása, tehát a beállítás helyes megadása. Ehhez használjuk a cdrecord paraméterét, amely az alábbihoz hasonló eredményt fog produkálni: CD-k írása &prompt.root; cdrecord -scanbus Cdrecord-Clone 2.01 (i386-unknown-freebsd7.0) Copyright (C) 1995-2004 Jörg Schilling Using libscg version 'schily-0.1' scsibus0: 0,0,0 0) 'SEAGATE ' 'ST39236LW ' '0004' Disk 0,1,0 1) 'SEAGATE ' 'ST39173W ' '5958' Disk 0,2,0 2) * 0,3,0 3) 'iomega ' 'jaz 1GB ' 'J.86' Removable Disk 0,4,0 4) 'NEC ' 'CD-ROM DRIVE:466' '1.26' Removable CD-ROM 0,5,0 5) * 0,6,0 6) * 0,7,0 7) * scsibus1: 1,0,0 100) * 1,1,0 101) * 1,2,0 102) * 1,3,0 103) * 1,4,0 104) * 1,5,0 105) 'YAMAHA ' 'CRW4260 ' '1.0q' Removable CD-ROM 1,6,0 106) 'ARTEC ' 'AM12S ' '1.06' Scanner 1,7,0 107) * Itt felsorolásra kerülnek a beállítás értékeként felhasználható eszközök. Keressük meg köztük a CD írónkat és a értékének a három vesszõvel elválasztott számot adjuk meg. Ebben az esetben a CD-író eszköz most az 1,5,0 lesz, tehát itt a helyes paraméterezés . Ezt az értékét könnyebben is meg lehet adni. Ennek részleteirõl a &man.cdrecord.1; man oldalán olvashatunk. Abban az esetben is érdemes fellapoznunk, ha az audio sávok írásáról, az írási sebesség korlátozásáról vagy más hasonló dolgokról akarunk olvasni. Audio CD-k másolása Audio CD-t úgy tudunk másolni, ha elõször állományok sorozatába mentjük a lemez tartalmát, majd ezeket az állományokat egy üres CD-re írjuk. Ennek konkrét folyamata azonban némileg eltér az ATAPI- és SCSI-meghajtók használata során. SCSI-meghajtók esetén A cdda2wav programmal mentsük le a lemez tartalmát. &prompt.user; cdda2wav -v255 -D2,0 -B -Owav A cdrecord paranccsal írjuk fel a .wav kiterjesztésû állományokat. &prompt.user; cdrecord -v dev=2,0 -dao -useinfo *.wav Gondoskodjunk róla, hogy a 2,0 értéket a nak megfelelõen helyesen állítottuk be. ATAPI-meghajtók esetén Az ATAPI CD meghajtója az egyes sávokat /dev/acddtnn néven teszi elérhetõvé, ahol a d a meghajtó sorszáma, a nn a sáv két számjeggyel kiírt sorszáma, amelyet szükség szerint balról nullával egészítenek ki. Így tehát az elsõ meghajtó elsõ sávja a /dev/acd0t01, a második a /dev/acd0t02, a harmadik a /dev/acd0t03 és így tovább. Ellenõrizzük, hogy ezek az eszközök jelen vannak a /dev könyvtárban. Amennyiben hiányoznának, kényszerítsük ki a lemez újbóli beolvasását: &prompt.root; dd if=/dev/acd0 of=/dev/null count=1 Szedjük le az egyes sávokat a &man.dd.1; használatával. A parancs kiadásakor meg kell adnunk egy blokkméretet is: &prompt.root; dd if=/dev/acd0t01 of=track1.cdr bs=2352 &prompt.root; dd if=/dev/acd0t02 of=track2.cdr bs=2352 ... A burncd használatával írjuk fel a lemezre az imént lementett állományokat. Meg kell adnunk, hogy ezek audio állományok, és hogy a burncd a munka befejeztével zárja le (fixate) a lemezt. &prompt.root; burncd -f /dev/acd0 audio track1.cdr track2.cdr ... fixate Adat CD-k másolása Az adatot tartalmazó CD-ket le tudjuk másolni egy olyan image-be, amely funkcionálisan megegyezik egy &man.mkisofs.8; által létrehozott image-dzsel és amivel le tudunk másolni bármilyen adat CD-t. Az itt megadott példa azt feltételezi, hogy a CD-meghajtónk neve acd0. Helyére a saját CD-meghajtónk nevét kell behelyettesíteni. &prompt.root; dd if=/dev/acd0 of=állomány.iso bs=2048 Most miután lementettük az image-et, írjuk fel CD-re a fentiek szerint. Adat CD-k használata Most, hogy már készítettünk egy szabványos adat CD-t, valószínûleg szeretnénk is valamilyen csatlakoztatni és elérni a rajta levõ adatokat. Alapértelmezés szerint a &man.mount.8; mindig azt feltételezi, hogy az állományrendszerek ufs típusúak. Ezért ha valami ilyesmivel próbálkozunk: &prompt.root; mount /dev/cd0 /mnt akkor egy Incorrect super block szövegû hibaüzenetet lesz a jutalmunk, és természetesen nem tudjuk csatlakoztatni a CD-t. Mivel a CD nem UFS állományrendszert tartalmaz, ezért az ilyen jellegû kísérleteink mind kudarcba fognak fulladni. Valahogy fel kell világosítanunk a &man.mount.8; parancsot arról, hogy itt most egy ISO9660 típusú állományrendszert akarunk csatlakoztatni, és akkor minden a helyére kerül. Ezt úgy tudjuk megtenni, ha a &man.mount.8; parancsnak megadjuk a paramétert. Például, ha a /dev/acd0 néven elérhetõ CD-meghajtóban levõ lemezt akarjuk a /mnt könyvtárba csatlakoztatni, akkor ezt kell begépelnünk: &prompt.root; mount -t cd9660 /dev/cd0 /mnt Vegyük észre, hogy az eszköz neve (ez ebben a példában most /dev/cd0) lehet más is attól függõen, hogy milyen csatolófelületet használ a CD-meghajtónk. Sõt, a valójában csak a &man.mount.cd9660.8; parancsot indítja el. Ennek tükrében tehát az elõbbi példát így rövidíthetjük le: &prompt.root; mount_cd9660 /dev/cd0 /mnt Ezen a módon bármilyen gyártmányú adat CD-t képesek vagyunk csatlakoztatni. Egyes ISO 9660 kiterjesztéseket használó lemezek azonban esetleg furcsán mûködhetnek. Például Joliet lemezek az összes állomány nevét kétbyte-os Unicode karakterben tárolják. A &os; rendszermagja ugyan nem beszéli a Unicode-ot, de a &os; CD9660 meghajtója képes menetközben átkonvertálni a Unicode karaktereket. Ha bizonyos nem angol karakterek kérdõjelekként jelennének meg, akkor a beállítás használatával még egy helyi kódlapot is meg kell adnunk. Ezzel kapcsolatban bõvebb tájékoztatásért forduljunk a &man.mount.cd9660.8; man oldalhoz. A beállítás segítségével csak akkor lesz képes a rendszermag elvégezni ezt az átalakítást, ha elõtte betöltjük a cd9660_iconv.ko modult. Ezt megtehetjük úgy, hogy ha felvesszük a következõ sort a loader.conf állományba: cd9660_iconv_load="YES" Indítsuk újra a számítógépünket, vagy közvetlenül töltsük be a modult a &man.kldload.8; használatával. Estenként elõfordulhat, hogy kapunk egy Device not configured hibaüzenetet a CD-k csatlakoztatásakor. Ez általában arra utal, hogy a CD-meghajtó nem érzékeli a berakott lemezt, vagy éppen a meghajtó nem látható a buszon. A CD-meghajtók esetében pár másodpercig eltarthat, amíg felismeri a berakott lemezt, ilyenkor mindig legyünk türelemmel. Néha a SCSI CD-meghajtó nem látható, mert nem volt elég ideje válaszolni busz újraindítása elõtt. Ha SCSI CD-meghajtónk van, akkor a következõ beállítást tegyük hozzá a rendszermagunk konfigurációjához és fordítsuk újra a rendszermagukat. options SCSI_DELAY=15000 Ezzel utasítjuk a SCSI buszunkat egy 15 másodperces várakozásra a rendszer indítása során, és így ezzel elég esélyt adunk arra, hogy a CD-meghajtó válaszolni tudjon a busz újraindítása elõtt. Nyers adat CD-k írása Írhatunk közvetlenül is állományokat a CD-re, ISO 9660 formátumú állományrendszer használata nélkül. Sokan így oldják meg a mentést. Ezt sokkal gyorsabban lebonyolítható egy szabványos CD esetében: &prompt.root; burncd -f /dev/acd1 -s 12 data archive.tar.gz fixate Az ezen a módon megírt CD-ket szintén nyers módon kell olvasnunk: &prompt.root; tar xzvf /dev/acd1 Az ilyen lemezeket nem tudjuk a normális CD-khez hasonlóan csatlakoztatni. Sõt, az ilyen CD-ket csak &os; alatt tudjuk olvasni. Ha csatlakoztathatóvá akarjuk tenni a lemezt, vagy más operációs rendszerek alól is szeretnénk olvasni, akkor erre a célra a fentebb bemutatott &man.mkisofs.8; parancsot kell használnunk. Marc Fonvieille Írta: CD-írók ATAPI/CAM meghajtó Az ATAPI/CAM meghajtó használata Ez a meghajtó lehetõvé teszi az ATAPI eszközök (CD-ROM, CD-RW, DVD meghajtók stb...) számára, hogy a SCSI alrendszeren keresztül legyenek elérhetõek, így esetünkben is használhatóvá válnak olyan alkalmazások, mint például sysutils/cdrdao vagy a &man.cdrecord.1;. A meghajtó használatához a következõ sort kell a /boot/loader.conf állományba illeszteni: atapicam_load="YES" Indítsuk újra a számítógépet. Amennyiben a rendszermagban az &man.atapicam.4; statikus támogatását szeretnénk használni, úgy a következõ sort kell a rendszermag konfigurációs állományába felvenni: device atapicam Továbbá a következõ sorokra lesz még szükségünk: device ata device scbus device cd device pass Ezeknek már eleve ott kell szerepelnie. Ezután fordítsuk újra és telepítsük a rendszermagot, majd indítsuk újra a számítógépet. A rendszer indulásakor az írónak ehhez hasonló módon kell megjelennie: acd0: CD-RW <MATSHITA CD-RW/DVD-ROM UJDA740> at ata1-master PIO4 cd0 at ata1 bus 0 target 0 lun 0 cd0: <MATSHITA CDRW/DVD UJDA740 1.00> Removable CD-ROM SCSI-0 device cd0: 16.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed A meghajtó most már elérhetõ a /dev/cd0 eszközön keresztül, és például ennyi begépelésével csatlakoztatni tudunk róla egy CD-t a /mnt könyvtárba: &prompt.root; mount -t cd9660 /dev/cd0 /mnt root felhasználóként a következõ paranccsal tudjuk lekérdezi az író SCSI címét: &prompt.root; camcontrol devlist <MATSHITA CDRW/DVD UJDA740 1.00> at scbus1 target 0 lun 0 (pass0,cd0) Eszerint a 1,0,0 lesz az eszköz SCSI címe, amelyet a &man.cdrecord.1; és más SCSI alkalmazások esetén adunk meg. Az ATAPI/CAM és SCSI rendszerek tekintetében olvassuk el az &man.atapicam.4; és &man.cam.4; man oldalakat. Marc Fonvieille Írta: Andy Polyakov Segítséget nyújtott benne: Lézeres tárolóeszközök (DVD-k) létrehozása és használata DVD írása Bevezetés A DVD a CD-hez képest a lézeres tárolóeszközök technológiájának újabb generációját képviseli. A DVD bármelyik CD-nél több adatot képes tárolni és napjaink ez a videók kiadásának szabványa. Öt fizikailag írható formátummal határozhatjuk meg az írható DVD fogalmát: DVD-R: Ez volt az elsõ elérhetõ írható DVD formátum. A DVD-R szabványát a DVD Fórum fektette le. Ez a formátum csak egyszer írható. DVD-RW: Ez a DVD-R szabvány újraírható változata. A DVD-RW körülbelül 1000 alkalommal írható újra. DVD-RAM: Ez is a DVD Fórum által támogatott újraírható formátum. A DVD-RAM cserélhetõ merevlemeznek látzsik. Azonban ez típusú adathordozó nem kompatibilis legtöbb DVD-ROM hajtóval és DVD-Video lejátszóval. Csupán csak néhány DVD-író ismeri a DVD-RAM formátumot. A DVD-RAM használatáról a ban találunk bõvebben információkat. DVD+RW: Ezt az újraírható formátumot a DVD+RW szövetség alkotta meg. A DVD+RW lemezek nagyjából 1000 alkalommal írhatóak újra. DVD+R: Ez a formátum a DVD+RW formátum egyszer írható változata. Az egyrétegû írható DVD-k összesen 4 700 000 000 byte-ot képesek rögzíteni, ami 4,38 GB vagy 4 485 MB (1 kilobyte itt 1024 byte). Meg kell különböztetnünk fizikai tárolóeszközt és az alkalmazást. Például a DVD-Video állományok olyan jellegû elrendezését írja elõ, ami bármelyik írható fizikai DVD eszközön megjelenhet: DVD-R, DVD+R, DVD-RW stb. Mielõtt kiválasztanánk az eszköz típusát, biztosnak kell lennünk benne, hogy az író és a DVD-Video lejátszó (ez lehet egy önálló lejátszó vagy egy számítógép DVD-ROM meghajtója) kompatibilis a szóbanforgó lemezzel. Beállítás A &man.growisofs.1; programot fogjuk a DVD rögzítésére használni. Ez a program a dvd+rw-tools segédprogramok (sysutils/dvd+rw-tools) gyûjteményének része. A dvd+rw-tools az összes DVD médium típusát ismeri. Ezek a segédprogramok a SCSI alrendszeren keresztül érik az eszközöket, ezért a használhatukhoz a rendszermagban szükségünk lesz az ATAPI/CAM támogatásra. Ha az írónk USB felületen csatlakozik, akkor mindez szükségtelen, és ehelyett a t kell elolvasnunk az USB eszközök beállításához. Engedélyeznünk kell az ATAPI eszközök DMA hozzáférését is, amit a /boot/loader.conf állományban a következõ sor hozzáadásával tudunk megtenni: hw.ata.atapi_dma="1" A dvd+rw-tools használatának megkezdése elõtt a DVD-írónkkal kapcsolatban érdemes átolvasnunk a dvd+rw-tools hardverkompatibilitási jegyzeteit (angolul). Ha grafikus felületet szeretnénk használni, akkor érdemes egy pillanatást vetnünk a K3bre (sysutils/k3b), amely egy felhasználóbarát felületet ad a &man.growisofs.1; és sok más íróprogram felé. Adat DVD-k írása A &man.growisofs.1; a mkisofs parancs elõlapja, tehát az állományrendszer létrehozásához a &man.mkisofs.8; programot fogja meghívni és ezt írja fel a DVD-re. Ez azt jelenti, hogy az írási folyamat megkezdése elõtt nem kell semmilyen image-et létrehoznunk. A /az/elérési/út könyvtárból a következõ paranccsal tudjuk kiírni az adatokat DVD+R vagy DVD-R lemezre: &prompt.root; growisofs -dvd-compat -Z /dev/cd0 -J -R /az/elérési/út A beállítások a &man.mkisofs.8; programhoz kerülnek át az állományrendszer létrehozásakor (itt most egy ISO 9660 állományrendszert hozunk létre, Joliet és Rock Ridge kiterjesztésekkel), használatának részleteit lásd &man.mkisofs.8;. A beállítást a kezdõmenetek létrehozásakor használjuk: több menetben akarjuk írni a lemezt vagy sem. A DVD eszközt, amely itt most a /dev/cd0, a saját konfigurációnknak megfelelõen kell megadni. A paraméterrel lezárjuk a lemezt, így ezután további írás már nem lehetséges. Ezért cserébe jobb kompatibilitást kapunk a DVD-ROM meghajtókkal. Elõre legyártott image-dzsel is dolgozhatunk, tehát például, ha az image.iso állományt akarjuk kiírni, akkor ezt kell lefuttatnunk: &prompt.root; growisofs -dvd-compat -Z /dev/cd0=image.iso Az írási sebességet magától beállítja a lemez és meghajtó képességeinek megfelelõen. Az írási sebesség felülbírálásához használjuk a paramétert. A paraméterek lehetõségeirõl a &man.growisofs.1; man oldaláról tudhatunk meg többet. 4,38 GB-nál több adat írásához egy hibrid UDF/ISO-9660 típusú állományrendszert kell létrehoznunk. Ezt úgy tudjuk elérni, ha &man.mkisofs.8; és a többi hasonló program (például &man.growisofs.1;) hívásakor még hozzátesszük az paramétereket. Ezekre csak lemezképek készítésekor vagy az állományok közvetlen lemezre írásakor van szükségünk. Az így létrehozott lemezeket a &man.mount.udf.8; segédprogram segítségével UDF állományrendszerként tudjuk csatlakoztatni. Ezért csak olyan operációs rendszereken használható, amelyek ismerik ezt a formátumot, ellenkezõ esetben csak hibás állományokat fogunk látni a lemezen. Példa ilyen lemezkép létrehozására: &prompt.root; growisofs -dvd-compat -udf -iso-level 3 -Z /dev/cd0 -J -R /az/új/adat/helye Ha a lemezkép már eleve nagyobb méretû állományokat tartalmaz, a lemez írásakor a &man.growisofs.1; programnak már nem kell további paramétereket átadnunk. Lehetõleg mindig a sysutils/cdrtools legfrissebb verzióját használjuk (amely a &man.mkisofs.8; programot is tartalmazza), mivel a régebbi verziók nem támogatják a nagyobb méretû állományokat. Ha problémák adódnak a programok használata során, akkor próbálkozzunk a fejlesztõi változattal (sysutils/cdrtools-devel) és olvassuk el a &man.mkisofs.8; man oldalát. DVD DVD-Video DVD-Video írása A DVD-Video az állományok speciális szervezésére utal, amely az ISO 9660 és az mikró UDF (M-UDF) specifikációkon alapszik. A DVD-Video emellett egy adott adatszerkezeti hierarchiát is takar, ezért kell egy külön programmal, például a multimedia/dvdauthor segítségével összeállítani egy DVD-t. Ha már a birtokunkban van egy DVD-Video állományrendszer képe, akkor az eddigiek szerint egyszerûen csak írjuk fel egy lemezre, ahogy azt az elõzõ szakaszban is láthattuk. Ha összeállítottuk a DVD anyagát és például a /a/videó/elérési/útja könyvtárba raktuk, akkor a következõ paranccsal írathatjuk ki a DVD-Video formátumú lemezt: &prompt.root; growisofs -Z /dev/cd0 -dvd-video /a/videó/elérési/útja A paramétert kell átadni a &man.mkisofs.8; programnak, amelynek hatására létrehoz egy DVD-Video formátumú állományrendszert. Emellett a beállítás maga után vonja a &man.growisofs.1; beállítását is. DVD DVD+RW A DVD+RW használata Eltérõen a CD-RW-tõl, egy érintetlen DVD+RW-t az elsõ használat elõtt meg kell formázni. A &man.growisofs.1; program errõl az elsõ adandó alkalommal gondoskodik, és ez az ajánlott. Azonban a DVD+RW formázására használhatjuk a dvd+rw-format parancsot is: &prompt.root; dvd+rw-format /dev/cd0 Ezt a mûveletet csak egyszer kell elvégezni, hiszen ne feledjük, hogy csak a szûz DVD+RW lemezeket kell megformázni. Ezután a DVD+RW-t a korábbi szakaszoknak megfelelõen tudjuk írni. Ha a DVD+RW-re új adatot akarunk írni (egy teljesen új állományrendszert, nem pedig adatokat hozzáfûzni), akkor nem kell üressé tenni a lemezt, egyszerûen csak elegendõ felülírni az elõzõeket (egy új kezdõmenet létrehozásával) valahogy így: &prompt.root; growisofs -Z /dev/cd0 -J -R /az/új/adat/helye A DVD+RW formátum felajánlja annak lehetõségét is, hogy könnyedén hozzá lehessen fûzni adatokat az elõzõ íráshoz. A mûvelet során az új menetet összefûzi a meglévõvel, tehát ez nem egy többmenetes írás, hanem a &man.growisofs.1; megnöveli a lemezen található ISO 9660 állományrendszert. Például, ha egy korábban megírt DVD+RW lemezen levõ adatokhoz akarunk hozzáírni, akkor a következõ parancsot kell kiadnunk: &prompt.root; growisofs -M /dev/cd0 -J -R /az/új/adat/helye A &man.mkisofs.8; beállításainál a kezõmenetnél megadottakat érdemes ismét megadni. Ha kompatibilisek akarunk maradni a többi DVD-meghajtóval, akkor adjuk meg paramétert. Ez a DVD+RW esetében annyit jelent, hogy nem tudunk további adatokat hozzáfûzni. Ha valamilyen okból mégis üressé szeretnénk tenni a lemez, akkor ír járhatunk el: &prompt.root; growisofs -Z /dev/cd0=/dev/zero DVD DVD-RW A DVD-RW használata A DVD-RW két lemezformátumot fogad el: a inkrementális soros hozzáférést és a korlátozott felülírást. Alapértelmezés szerint a DVD-RW lemezek soros elérésûek. A még fel nem használt DVD-RW lemezek közvetlenül írhatóak külön formázás nélkül, habár a korábban már soros formátumban használt DVD-RW lemezeket egy új kezdõmenet létrehozása elõtt üressé kell tenni. Soros módban így kell letörölni egy DVD-RW lemezt: &prompt.root; dvd+rw-format -blank=full /dev/cd0 A teljes törlés () egy 1x média esetén körülbelül egy órát vesz igénybe. A beállítással egy gyorsított törlés zajlik le, amennyiben a DVD-RW lemezt Disk-At-Once (DAO) módban írjuk. A DVD-RW lemezeket az alábbi paranccsal tudjuk DAO módban írni: &prompt.root; growisofs -use-the-force-luke=dao -Z /dev/cd0=image.iso A beállítást nem kötelezõ megadni, mivel a &man.growisofs.1; igyekszik a lehetõ leggyorsabban törölni a lemezt és megkezdeni a DAO módú írást. A DVD-RW esetében valójában a korlátozott felülírást lenne érdemes használnunk, mivel ez a formátum sokkal rugalmasabb az alapértelmezés szerint felkínált inkrementális soros elérésnél. A soros DVD-RW lemezekre ugyanúgy tudunk adatokat rögzíteni, mint az összes többi formátum esetében: &prompt.root; growisofs -Z /dev/cd0 -J -R /az/adat/helye Ha az elõzõ íráshoz akarunk még hozzáfûzni adatokat, akkor ehhez a &man.growisofs.1; beállítását kell használnunk. Azonban ha a DVD-RW lemezhet inkrementális soros módban adunk hozzá adatot, akkor ezzel egy új menetet hozunk létre a lemezen és így egy többmenetes lemezt kapunk. A korlátozott felülírású DVD-RW formátum használata esetén nem kell mindegyik kezdõmenet elõtt törölni a lemezt, egyszerûen csak felül kell írni a beállítással, hasonlóan a DVD+RW esetéhez. A DVD+RW beállításához hasonlóan lehetõségünk van a lemezen található ISO 9660 formátumú állományrendszer növelésére. Ennek az eredménye egy egymenetes DVD. A következõ paranccsal tudjuk a DVD-RW lemezt korlátozott felülírású módba tenni: &prompt.root; dvd+rw-format /dev/cd0 Így tudunk visszaváltani a soros formátum használatára: &prompt.root; dvd+rw-format -blank=full /dev/cd0 Több menet használata Nagyon kevés DVD-ROM meghajtó ismeri a többmenetes DVD-ket, és legtöbbször is csak általában az elsõ menetet olvassák. A DVD+R, DVD-R és DVD-RW formátumok soros formátumban képesek több mentetet is befogadni, viszont a DVD+RW és DVD-RW korlátozott felülírású formátuma esetén nem létezik több menet. Az alábbi parancs egy újabb menetet ad hozzá egy megkezdett (le nem zárt) DVD+R, DVD-R vagy DVD-RW soros formátumú lemezhez: &prompt.root; growisofs -M /dev/cd0 -J -R /az/új/adat/helye Ha ezt a parancsot egy korlátozott felülírású DVD+RW vagy DVD-RW lemez esetén adjuk ki, akkor az új adatokat úgy fûzi hozzá, hogy egy új menetet összefésüli a meglévõvel. Ezzel egy egymenetes lemez keletkezik. Ilyenkor így bõvítik a megkezdett lemezeket. A menetek kezdése és befejezése általában felhasznál valamennyi helyet a lemezen. Ezért úgy tudjuk optimalizálni a lemez helykihasználtságát, hogy kevés menetben sok adatot viszünk fel rá. A DVD+R esetén 154, a DVD-R-nél körülbelül 2000, és a dupla rétegû DVD+R lemezeknél 127 menetet tudunk létrehozni. További olvasnivalók A DVD lemezrõl részletesebb információkat a dvd+rw-mediainfo /dev/cd0 parancs kiadásával tudunk lekérdezni. A dvd+rw-tools használatáról a &man.growisofs.1; man oldalon találunk információt, valamint a dvd+rw-tools honlapján (angolul) és a cdwrite levelezési lista archívumaiban (angolul). Futassuk dvd+rw-mediainfo parancsot minden olyan esetben, amikor gondunk akad valamilyen lemez írásával. A kimenete nélkül szinte lehetetlen segítenünk bárkinek is. A DVD-RAM használata DVD DVD-RAM Beállítás A DVD-RAM írók SCSI vagy ATAPI csatolófelülettel rendelkeznek. Az ATAPI eszközök esetén engedélyezni kell a DMA elérését, amit a /boot/loader.conf állományban az alábbi sor hozzáadásával tudunk megtenni: hw.ata.atapi_dma="1" A lemez elõkészítése Ahogy arra már korábban utaltunk a fejezet bevezetésében, a DVD-RAM úgy látható, mint egy cserélhetõ merevlemez. A hagyományos merevlemezekhez hasonlóan a DVD-RAM-ot is elõ kell készíteni az elsõ használatához. Ebben a példában a lemez teljes területét egy szabványos UFS2 állományrendszerrel töltjük fel: &prompt.root; dd if=/dev/zero of=/dev/acd0 bs=2k count=1 &prompt.root; bsdlabel -Bw acd0 &prompt.root; newfs /dev/acd0 A DVD eszköz nevét, vagyis az acd0 eszközt a saját rendszerünknek megfelelõen kell módosítani. A lemez használata Miután az elõbbi mûveletet elvégeztük a DVD-RAM lemezen, már tudjuk is normális merevlemezként csatlakoztatni: &prompt.root; mount /dev/acd0 /mnt Ezt követõen a DVD-RAM egyaránt olvasható és írható. Julio Merino Eredetileg készítette: Martin Karlsson Átdolgozta: Hajlékonylemezek létrehozása és használata Néha hasznos lehet, ha az adatokat floppy lemezeken tároljuk, például olyankor, amikor más cserélhetõ tárolóeszköz már nem jöhet számításba, vagy amikor kis mennyiségû adatot kell átvinnünk az egyik számítógéprõl a másikra. Ebben a szakaszban bemutatjuk hogyan kell &os; alatt floppy lemezeket használni. Elsõsorban a 3,5 colos DOS lemezek formázásával és használatával foglalkozik, de ezek fogalmak a többi hajlékonylemezes formátum esetében is hasonlóak. A hajlékonylemezek formázása Az eszköz A floppy lemezek a többi eszközhöz hasonlóan a /dev könyvtárban érhetõek el. A nyers floppy lemezek eléréséhez egyszerûen csak használjuk a /dev/fdN hivatkozást. A formázás Használat elõtt a floppy lemezeket alacsony szinten meg kell formázni. Ezt általában maga a gyártó végzi el, de a formázás gyakran hasznos lehet a lemez sértetlenségének ellenõrzésére. A legtöbb floppy lemez hivatalos kapacitása 1440 KB, de használhatjuk nagyobb (és kisebb) méretekben is. A floppy lemezek alacsony szintû formázására az &man.fdformat.1; parancsot használhatjuk. Ez a segédprogram paraméterként az eszköz nevét várja. Figyeljünk a menetközben megjelenõ hibaüzenetekre, mivel ezek segítik eldönteni, hogy a lemez használható vagy sem. A hajlékonylemezek formázása A /dev/fdN eszközök segítségével tudunk megformázni egy floppy lemezt. Tegyünk be egy 3,5 colos floppy lemezt a meghajtóba, majd adjuk ki a következõ parancsot: &prompt.root; /usr/sbin/fdformat -f 1440 /dev/fd0 A lemez címkézése Miután alacsony szinten formáztuk a lemezt, tennünk kell rá egy lemezcímkét is. Ez a lemezcímke késõbb meg fog semmisülni, de a rendszernek szüksége van rá, hogy pontosan meg tudja állapítani a lemez méretét és geometriáját. Az új lemezcímke lefedi az egész lemezt, és tartalmazni fogja az összes információt a floppy geometriájáról. A lemezcímkék geometriaértékeit az /etc/disktab állományban találjuk meg felsorolva. Most már futtathatjuk is a &man.bsdlabel.8; parancsot: &prompt.root; /sbin/bsdlabel -B -w /dev/fd0 fd1440 Az állományrendszer A hajlékonylemez most már készen áll a magas szintû formázásra. Ennek során egy új állományrendszert teszünk rá, amelyet a &os; képes írni és olvasni. Miután létrejött ez az új állományrendszer, a lemezcímke megsemmisül, így tehát ha újra meg akarjuk formázni a lemezt, akkor újra létre kell majd hoznunk a lemezcímkét. A floppy állományrendszere lehet UFS vagy FAT. A FAT általánosságban véve jobb választás a floppy lemezek számára. Az alábbi módon tudunk új állományrendszert tenni a floppyra: &prompt.root; /sbin/newfs_msdos /dev/fd0 A lemez most már készen áll a használatra. A hajlékonylemezek használata A floppy lemezt használatához a &man.mount.msdosfs.8; paranccsal kell csatlakoztatnunk. Ugyanerre a célra használhatjuk a Portgyûjteménybõl elérhetõ emulators/mtools portot is. Szalagok létrehozása és használata szalagos adathordozó A legfontosabb szalagos adathordozók a 4 mm-es, 8 mm-es, QIC, a minikazettás és a DLT. 4 mm-es (Digitális adattároló, avagy DDS: Digital Data Storage) szalagos adathordozó (4 mm-es) DDS-szalagok szalagos adathordozó QIC-szalagok A 4 mm-es szalagok a QIC-szalagokat váltják fel a munkaállomások biztonsági mentésének eszközeként. Ez a tendencia csak tovább növekedett, ahogy a Conner felvásárolta az Archive-ot, a QIC típusú meghajtók legnagyobb gyártóját, majd leállított a QIC-meghajtók gyártását. A 4 mm-es meghajtók mérete kicsi és csendben is dolgoznak, de a megbízhatóság terén nem tudhatják maguknak mindazt a sikert, amit a 8 mm-es társaiknál könyvelhettünk el. A kazetták is sokkal olcsóbbak és kisebbek (3 x 2 x 0,5 col, ami 76 x 51 x 12 mm) a 8 mm-es kiadásénál. A 4 mm-es feje, hasonlóan a 8 mm-eséhez, valamilyen okból szintén viszonylag rövid ideig bírja, és mind a kettõ spirális pásztázást használ. Ezeknél a meghajtóknál az adatátvitel nagyjából 150 KB/mp-nél kezdõdik és 500 KB/mp-nél végzõdik. Az adattárolási képességük 1,3 GB-tól indul és 2,0 GB-ig tart. A hardveres tömörítés, ami a legtöbb ilyen típusú meghajtónál elérhetõ, közel megduplázza a kapacitást. A többmeghajtós szalagos könyvtár egységek egyetlen szekrényben 6 meghajtót képes befogadni, a szalagok automatikus cserélgetésével. Az ilyen könyvtárak kapacitása a 240 GB-ot is elérheti. A DDS-3 szabvány most már akár 12 GB (vagy tömörítve 24 GB) kapacitást is elérhetõvé tesz. A 4 mm-es meghajtók, hasonlóan a 8 mm-es meghajtókhoz, spirális pásztázást alkalmaznak. A spirális pásztázás összes elõnye és hátránya ezért egyaránt él a 4 mm-es és 8 mm-es meghajtók esetén. A szalagok 2 000 menet vagy 100 teljes mentes után kopnak el. 8 mm-es (Exabyte) szalagos adathordozó (8 mm-es) Exabyte szalagok A 8 mm-es szalagok a legelterjedtebb szalagos SCSI-meghajtók. A szalagok használatára ez a legjobb választás. Szinte mindegyik rendszerben egy 2 GB-os 8 mm-es Exabyte szalagos meghajtót használnak. A 8 mm-es meghajtók megbízhatóak, kényelmesek és csendesek. A kazetták olcsók és kicsik (4,8 x 3,3 x 0,6 col, azaz 122 x 84 x 15 mm). A 8 mm-es szalagok feje viszonylag csak rövid ideig bírja a szalag nagy mértékû oda-vissza mozgása miatt. Az adatátvitel sebessége 250 KB/mp-tõl 500 KB/mp-ig terjed, valamint a 300 MB-tól egészen 7 GB-os méretig találkozhatunk velük. A meghajtókban elérhetõ hardveres tömörítés képes közel megduplázni a kapacitást. Ezek a meghajtók önálló egységként is beszerezhetõek vagy egy 6 egységbõl álló és 120 szalagos szalagos könyvtár részeként. Ezek az egységek önállóan váltják a szalagokat. Az ilyen könyvtárak kapacitása eléri a közel 840 GB-ot. Az Exabyte Mammoth modellje szalagonként 12 GB (tömörítéssel pedig 24 GB) adatot képes tárolni, viszont a hagyományos szalagos meghajtóknál nagyjából kétszer többe kerül. Az adatok spirális pásztázással kerülnek a szalagra, és a fejek adott (nagyjából 6 fokos) szögben állnak a szalag felett. A szalag a fejeket tartó orsó köré tekeredik, körülbelül 270 fokban. Ennek eredményképpen nagyobb adatsûrûség és szorosan zárt sávok jönnek létre, ahogy ebben a szögben a fej eljut a szalag egyik élérõl a másikra. QIC szalagos adathordozó QIC-150 A QIC-150 meghajtók és szalagok talán a legelterjedtebb szalagos egységek és adathordozók. A QIC szalagos meghajtók a legolcsóbb komolynak tekinthetõ biztonsági mentésre alkalmas meghajtók. Az olcsóság azonban megköveteli a maga árát. A QIC-szalagok a 4 és 8 mm-es szalagokkal szemben akár ötször is drágábbak lehetnek gigabyte-onként. De ha megelégszünk csupán féltucat szalaggal is, akkor a QIC jó vásárnak tûnhet. A QIC a leginkább elterjedtebb szalagos meghajtó. Minden rendszerben biztonsan találunk valamilyen minõségben QIC-meghajtót. A QIC fizikailag hasonló (és gyakran azonos) felépítésû szalagokat gyárt rengeteg különbözõ adatsûrûséggel. Az ilyenkor keletkezõ súrlódások miatt a QIC-meghajtók egyáltalán nem nevezhetõek csendesnek. Az ilyen típusú meghajtók az adatok rögzítése elõtt külön hangjelenség kíséretében keresik meg a megfelelõ pozíciót és tisztán hallható, ahogy olvasnak, írnak és keresnek. A QIC-szalagok mérete 6 x 4 x 0,7 col (avagy 152 x 102 x 17 mm). Az adatátviteli sebesség nagyjából 150 KB/mp-tõl 500 KB/mp-ig terjedhet. A kapacitás szalagonként 40 MB és 15 GB között változhat. A legtöbb újabb QIC-meghajtó támogatja a hardveres tömörítést. QIC-meghajtókat azonban egyre kevésbé találhatunk, helyüket szépen lassan mindenhol átveszik a DAT-meghajtók. A szalagokra sávokban rögzítik az adatokat. Ezek a sávok szalag felületének hosszanti tengelyén futnak az egyik végétõl a másikig. A sávok száma valamint a sávok vastagsága a szalagok kapacitásától függõen változnak. Ha nem is összes legújabb, de a legtöbb meghajtó legalább olvasás szintjén kompatibilis a régebbi típusokkal (de gyakran írásban is). A QIC híresen megbízható az adatbiztonság tekintetében (a mechanikája sokkal egyszerûbb és strapabíróbb a spirális pásztázással mûködõ meghajtókénál). A szalagokat 5000 mentés után érdemes lecserélni. DLT szalagos adathordozó DLT A DLT rendelkezik a legnagyobb adatátviteli sebességgel az itt összefoglalt mezõnyben. A 1/2 colos (12,5 mm-es) szalag egy egyorsós tokban foglal helyet (mérete 4 x 4 x 1 col, azaz 100 x 100 x 25 mm). A tok egyik oldalán végig egy csúszó kapu található. A meghajtó ezt a kaput nyitja ki és ezen keresztül húzza be a szalagot. A szalag elején található egy ovális lyuk, amibe a meghajtó bele tud akaszkodni. A feszítõ orsó a szalagos meghajtóban foglal helyet. Az összes többi szalag esetén (kivéve egyedül a 9 sávos szalagokat) mind a segéd- és feszítõ orsók magában a kazettában találhatóak. Az adatátviteli sebessége megközelítõleg 1,5 MB/mp, tehát háromszor nagyobb bármelyik 4 mm-es, 8 mm-es vagy QIC-szalagos egységénél. Az adattároló képessége kazettánként 10 GB-tól 20 GB-ig terjedhet. A meghajtók egyaránt elérhetõek többkazettás, cserélgetõs és többkazettás, többmeghajtós könyvtárakban is, melyek 5 kazettától egészen 900 kazettáig, illetve 1 meghajtótól 20 meghajtóig képesek befogadni, így teljes tárterületük 50 GB-tól 9 TB-ig terjed. A DLT Type V formátum tömörítéssel közel 70 GB-os kapacitást képes elérni. A szalagra az adatok a haladási iránnyal párhuzamosan kerülnek fel (akárcsak a QIC-szalagok esetében). Egyszerre két sávot rögzít. A író/olvasó fejek élettartama viszonylag nagy. Ahogy a szalag megáll, a fej és a szalag között nincs szükség további relatív mozgásra. AIT szalagos adathordozó AIT Az AIT a Sony új formátuma, ami egészen 50 GB mennyiségû adatot képes tárolni (tömörítéssel) egyetlen szalagon. A szalagokat memóriachipekkel látják el, melyek a szalag tartalmát indexelik. Az indexek felhasználásával aztán a szalagos meghajtó villámgyorsan képes meghatározni a szalagon található állományok helyét, szemben az ilyenkor megszokott többperces mûvelettel. A SAMS:Alexandria és a hozzá hasonló szoftverek negyven vagy több AIT-szalagos könyvtárral is képesek egyszerre dolgozni, és közvetlenül a szalagok memóriájával veszik fel a kapcsolatot a tartalmuk megjelenítéséhez, a mentett állományok rendszerezéséhez, a helyes szalag megkereséséhez, betöltéséhez és visszatöltéséhez. Az ilyen könyvtárak a 20 000 dolláros (kb. 3,5 millió forintos) árkategóriába tartoznak, ami miatt csak egy kicsivel csúsznak ki a hobbi kategóriából. Az új szalagok elsõ használata Amikor az elsõ alkalommal akarunk beolvasni vagy írni egy új, teljesen üres szalagot, hibára fogunk futni. Egy ehhez hasonló konzolüzenet fog megjelenni: sa0(ncr1:4:0): NOT READY asc:4,1 sa0(ncr1:4:0): Logical unit is in process of becoming ready A szalag nem tartalmaz azonosító blokkot (Identifier Block) a nulladik blokkban. A QIC-525 szabvány átvétele óta mindegyik QIC szalagos meghajtó létrehozza ezt az azonosító blokkot. Tehát két megoldás létezik: Az mt fsf 1 paranccsal felírunk egy ilyen azonosító blokkot a szalagra. A meghajtó elõlapján található gomb segítségével dobassuk ki a szalagot. Rakjuk vissza a szalagot és hajtsunk végre rajta egy dump parancsot. A dump parancs erre egy DUMP: End of tape detected (szalag vége) hibaüzenetet ad, majd a következõ jelenik meg a konzolon: HARDWARE FAILURE info:280 asc:80,96. Tekertessük vissza a szalagot az mt rewind paranccsal. A szalag következõ mûvelete most már sikeres lesz. Biztonsági mentés hajlékonylemezekre Hajlékonylemezre is lehet biztonsági mentést készíteni? biztonsági floppyk floppy lemezek A floppy lemezek nem igazán felelnek meg biztonsági mentés készítésére, mivel: Nem megbízható adathordozók, különösen hosszabb idõre. Esetükben a mentés és visszaállítás nagyon lassú. Kapacitásuk erõsen korlátozott (annak már régen elmúlt az ideje, amikor egész merevlemezeket tudtunk lementeni egy tucat floppyra). Habár ha máshogy nem tudunk biztonsági mentést készíteni, akkor a floppy lemezekkel még mindig jobban járunk, mint nélkülük. Ha már mindenképpen floppy lemezeket kell használnunk, akkor igyekezzünk minél jobb minõségûeket beszerezni. Tehát az olyan floppyk, amik már évek óta kavarognak az irodában, erre a célra nem éppen bizonyulnak a legjobb választásnak. Ideális esetben egy megbízható gyártótól származó új floppykat használunk. Tehát akkor hogyan mentsük az adatokat hajlékonylemezre? Legegyszerûbban a &man.tar.1; (többkötetes) opciójával tudunk floppy lemezre menteni, aminek használatával több floppyra kiterjedõ mentéseket is készíthetünk. Az aktuális könyvtár és a benne levõ alkönyvtárak tartalmát (root) felhasználóként a következõ paranccsal tudjuk lementeni: &prompt.root; tar Mcvf /dev/fd0 * Amikor az elsõ floppy megtelik, a &man.tar.1; kérni fogja a következõ kötetet (volume) (mivel a &man.tar.1; adathordozótól független módon hivatkozik a kötetekre, tehát ebben a környezetben a kötet egy floppy lemezt jelent): Prepare volume #2 for /dev/fd0 and hit return: Az üzenet fordítása: Készítse elõ a 2. kötetet a /dev/fd0 eszközön és nyomja le a return billentyût A folyamat egészen addig ismétlõdik (a kötetek számának növekedésével), amíg az összes állomány lementésre nem kerül. Lehet tömöríteni a mentéseket? tar gzip tömörítés Sajnos a &man.tar.1; többkötetes mentések esetén nem engedi a beállítás használatát. Természetesen ettõl függetlenül a &man.gzip.1; segítségével még be tudjuk tömöríteni az összes állományt, a &man.tar.1; paranccsal floppyra menteni ezeket, majd a &man.gunzip.1; paranccsal kitömöríteni. Hogyan állítsuk vissza a biztonsági mentéseket? Az egész mentés visszaállításához adjuk ki a következõ parancsot: &prompt.root; tar Mxvf /dev/fd0 Két módon tudunk csak bizonyos állományokat visszaállítani. Elõször is, tegyük be a mentés elsõ lemezét és adjuk ki a következõ parancsot: &prompt.root; tar Mxvf /dev/fd0 állomány A &man.tar.1; segédprogram ezután sorban kérni fogja a többi lemezt egészen addig, amíg meg nem találja a keresett állományt. Vagy ha pontosan tudjuk, hogy melyik lemezen található a keresett állomány, akkor az iménti parancs használatát azzal a lemezzel kezdjük. Vigyázzunk, mert ha a lemezen található elsõ állomány az elõzõ lemezen kezdõdik, akkor a &man.tar.1; figyelmeztetni fog minket, hogy nem állítja vissza még akkor sem, ha erre nem is kértük! Lowell Gilbert Eredetileg készítette: Mentési stratégiák Egy biztonsági mentés kidolgozása során az elsõ követelmény gondoskodnunk az alábbi problémákról: Lemezhiba Az állományok véletlen törlése Az állományok véletlenszerû károsodása Számítógépek teljes megsemmisülése (például tûz által), belértve a közelében tárolt összes biztonsági mentést Tökéletesen megoldható, hogy egyes rendszerek a fentebb felsorolt problémák mindegyikét teljesen eltérõ technikával oldják meg. A nagyon személyes rendszerektõl és a nagyon értéktelen adatoktól eltekintve szinte egyértelmûen kizárt, hogy egyetlen technika képes lefedni az összes problémát. Kelléktárunk néhány alapvetõ eszköze: Az egész rendszer mentése, amit egy megbízható helyre elzárt, tartós adattárolóra készítünk. Ez tulajdonképpen védelmet biztosít a fentebb megemlített összes probléma esetében, de lassú és kényelmetlen róla visszaállítani az adatokat. A közelben és/vagy neten is tarthatunk errõl másolatokat, de még így is kényelmetlen az állományok visszaállítása, különösen az egyszerû felhasználók számára. Pillanatképek készítése az állományrendszerrõl. Ez valójában csak olyan esetekben lehet a segítségünkre, amikor véletlenül töröltünk állományokat, ám ilyenkor határozottan jól jön, mivel igen gyorsan és könnyen lehet vele dolgozni. Az egész állományrendszer és/vagy az összes lemez másolata (például az &man.rsync.1; idõszakos alkalmazása a komplett gépre). Az általában az egyedi igényekkel bíró hálózatok esetében eshet a kezünkre. A lemezhiba ellen védelemben ez a megoldás általában a RAID alatt áll. A véletlenül törölt állományok visszaállításának tekintetében az UFS pillanatképeivel mérhetõ össze, de ez leginkább a saját igényeinktõl függ. RAID alkalmazása. A lemezek meghibásodása esetén segíti minimalizálni vagy elkerülni a kiesést, ugyan gyakori lemezhibák árán (mivel ilyenkor több lemezt használunk) de kisebb sürgõsséggel. Az állományok ujjlenyomatának ellenõrzése. Az &man.mtree.8; segédprogram nagyon hasznos tud lenni ebben az esetben. Habár ez nem egy mentési technika, mégis segít megállapítani, hogy mikor kell nyugdíjba küldenünk a biztonsági mentéseinket. Ez különösen az aktív nem használt mentésekre vonatkozik, ezeket bizonyos idõ elteltével mindig érdemes ellenõrizni. Nagyon könnyû lenne további technikákat is felsorolni, melyek legtöbbje az iméntiek valamilyen kombinációja lenne. A speciális igények általában speciális technikákat eredményeznek (például egy éles adatbázis biztonsági mentése általában az adott adatbáziskezelõ rendszer közremûködését is elvárja). Mindig fontos tudni, hogy milyen veszélyek ellen védekezünk és hogyan kezeljük le ezeket. Alapvetõ tudnivalók a biztonsági mentésrõl A &man.dump.8;, &man.tar.1; és &man.cpio.1; a három legfontosabb biztonsági mentésekkel kapcsolatos program. Mentés és helyreállítás biztonsági mentést végzõ szoftverek mentés / helyreállítás dump restore A &unix; típusú rendszerekben a biztonsági mentést hagyományosan a dump és restore programok végzik. A meghajtókat lemezblokkok összeségeként kezelik, az állományrendszerek által létrehozott állományok, linkek és könyvtárak szintje alatt. Eltérõen más, biztonsági mentést végzõ szoftverektõl, a dump az adott eszközön egy egész állományrendszert képes lementeni. Nem képes csak az állományrendszer vagy egy több állományrendszerre kiterjedõ könyvtárszerkezet egy részét lementeni. A dump nem állományokat és könyvtárakat ír a szalagra, hanem nyers adatblokkokat, amelyek állományokat és könyvtárakat formáznak. A restore parancs az adatokat alapértelmezés szerint a /tmp könyvtárba tömöríti ki. Ha nem lenne elegendõ helyünk a /tmp könyvtárban, akkor a TMPDIR környezeti változó átállításával ehelyett megadhatunk egy olyat, ahol már kellõ mennyiségû terület áll rendelkezésre a restore akadálytalan lefutásához. Ha a dump parancsot a gyökér könyvtárban adjuk ki, akkor nem fogja lementeni a /home vagy /usr vagy bármilyen más könyvtárat, mivel ezek jellemzõ módon más állományrendszerek csatlakozási pontja vagy más állományrendszerekre mutató szimbolikus linkek. A dump parancsnak vannak olyan rigolyái, amelyek még az AT&T UNIX 6. verziójából (1975 környékérõl) maradtak vissza. Az alapértelmezett paraméterezése 9 sávos szalagokat feltételezi (6250 bpi), nem pedig a napjainkban elterjedt nagy írássûrûsségû (egészen 62 182 ftpi-s) adathordozókat. Ezek az alapértelmezések természetesen paranccsorból felülbírálhatóak, és így a manapság alkalmazott szalagos meghajtók teljes kapacitása is kihasználható vele. .rhosts Emellett az rdump és rrestore programok segítségével hálózaton keresztül is le tudjuk menteni az adatainkat egy másik számítógépre csatlakoztatott szalagos egységre. Mind a két program az &man.rcmd.3; és a &man.ruserok.3; parancsokat használja a távoli szalagos meghajtó eléréséhez. Az rdump és rrestore paramétereinek a távoli számítógép használatához kell illeszkedniük. Amikor egy &os; rendszerû számítógépet az rdump paranccsal egy Sun rendszerû, komodo nevû számítógépre mentünk, amelyhez egy Exabyte szalagos meghajtó csatlakozik, akkor ezt a írjuk be: &prompt.root; /sbin/rdump 0dsbfu 54000 13000 126 komodo:/dev/nsa8 /dev/da0a 2>&1 Figyelem: az .rhosts állományon keresztül hitelesítésnek megvannak a maga biztonsági kockázatai. Ne felejtsük el felmérni ezt a saját környezetünkben sem. A dump és restore parancsokat az ssh használatával még biztonságosabbá tehetjük. A <command>dump</command> használata az <application>ssh</application> alkalmazással &prompt.root; /sbin/dump -0uan -f - /usr | gzip -2 | ssh -c blowfish \ célfelhasználó@cél.gép.hu dd of=/nagyállományok/dump-usr-l0.gz Vagy az RSH környezeti változó megfelelõ beállításával használhatjuk a dump beépített módszerét: A <command>dump</command> használata az <application>ssh</application> alkalmazással, az <envar>RSH</envar> környezeti változó beállításával &prompt.root; RSH=/usr/bin/ssh /sbin/dump -0uan -f célfelhasználó@cél.gép.hu:/dev/sa0 /usr <command>tar</command> biztonsági mentést végzõ szoftverek tar A &man.tar.1; is az AT&T UNIX 6. verziójáig nyúlik vissza (tehát nagyjából 1975-ig). A tar az állományrendszerrel szoros együttmûködésben dolgozik, állományokat és könyvtárakat ír a szalagra. A tar ugyan nem ismeri a &man.cpio.1; által felkínált összes lehetõséget, de nincs is szüksége olyan szokatlan paranccsoros összekapcsolásokra, mint a cpio parancsnak. tar A &os; 5.3 vagy késõbbi változataiban a GNU tar és az alapértelmezés szerinti bsdtar egyaránt elérhetõ. A GNU változat a gtar paranccsal hívható meg. Az rdump parancshoz hasonló felírásban képes kezelni a távoli eszközöket. Tehát így tudjuk használni a tar parancsot a komodo nevû Sun számítógép Exabíte szalagos meghajtójának elérésére: &prompt.root; /usr/bin/gtar cf komodo:/dev/nsa8 . 2>&1 Ugyanez eltérhetõ a bsdtar használatával is, amikor az rsh programmal összekapcsolva küldünk át a távoli szalagos egységre. &prompt.root; tar cf - . | rsh hálózati-név dd of=szalagos-eszköz obs=20b Ha a hálózaton keresztül mentés során fontos számunkra a biztonság, akkor az rsh parancs helyett az ssh parancsot használjuk. <command>cpio</command> biztonsági mentést végzõ szoftverek cpio A &man.cpio.1; eredetileg a &unix; szalagos programjai és szalagos egységei között közvetített. A cpio parancs (többek közt) képes a byte-ok sorrendjének felcserélésére, több különbözõ archívum formátuma szerint írni és adatokat közvetíteni más programok felé. Ez utóbbi lehetõsége miatt a cpio kíválóan alkalmas a telepítõeszközök számára. A cpio nem képes bejárni a könyvtárszerkezetet, és az állományok listáját a szabványos bemeneten keresztül kell megadni neki. cpio A cpio nem támogatja a biztonsági mentés átküldését a hálózaton. Programok összekapcsolásával és az rsh használatával tudunk adatokat küldeni távoli szalagos meghajtókra. &prompt.root; for f in könyvtár_lista; do find $f >> mentési.lista done &prompt.root; cpio -v -o --format=newc < backup.list | ssh felhasználó@gép "cat > mentõeszköz" Ahol a könyvtár_lista a menteni kívánt könyvtárak listája, a felhasználó@gép a mentést végzõ gép felhasználójának és hálózati nevének együttese, valamint a mentõeszköz, ahova a mentés kerül (például /dev/nsa0). <command>pax</command> biztonsági mentést végzõ szoftverek pax pax POSIX IEEE A &man.pax.1; az IEEE/&posix; válasza a tar és cpio programokra. Az évek során a tar és a cpio különbözõ változatai egy kissé inkompatibilissé váltak. Ezért a szabványosításuk kiharcolása helyett inkább a &posix; létrehozott egy új archiváló segédprogramot. A pax megpróbálja írni és olvasni a cpio és tar formátumok legtöbb változatát, valamint emellett további saját formátumokat is kezel. A parancskészlete inkább a cpio parancséra emlékeztet, mintsem a tar parancséra. <application>Amanda</application> biztonsági mentést végzõ szoftverek Amanda Amanda Az Amanda (Advanced Maryland Network Disk Archiver) egy kliens-szerver alapú mentési rendszer, nem pedig egy önálló program. Az Amanda szerver menti tetszõleges számú számítógép adatát egyetlen szalagra, melyek az Amanda klienst futtatják és hálózaton keresztül hozzá csatlakoznak. A nagy mennyiségû és nagy kapacitású lemezekkel rendelkezõ rendszerekben közvetlenül a mentéshez szükséges idõ nem áll rendelkezésre a feladat elvégzéséhez. Az Amanda viszont képes megoldani ezt a problémát. Az Amanda képes egy saját lemez használatával egyszerre több állományrendszerrõl is biztonsági mentést készíteni. Az Amanda archívumkészleteket hoz létre: az Amanda konfigurációs állományában megadott állományrendszerekrõl készít teljes mentést egy adott idõ alatt egy adott mennyiségû szalagra. Az archívumkészlet ezenkívül még tartalmaz egy napi inkrementális (vagy különbözeti) mentést is minden egyes állományrendszerrõl. A sérült állományrendszerek visszaállításához mindig a legújabb teljes biztonsági mentésre és a hozzátartozó inkrementális mentésekre van szükségünk. A konfigurációs állomány segítségével precíz irányítást gyakorolhatunk a létrehozott mentések és az Amanda által keltett hálózati forgalom felett. Az Amanda a fentiek közül bármelyik programmal képes az adatokat szalagra rögzíteni. Az Amanda portként vagy csomagként is elérhetõ, alapértelmezés szerint nem települ. Ne csináljunk semmit A Ne csináljunk semmit nem egy újabb számítógépes program, hanem egy igen gyakran alkalmazott mentési stratégia. Nem kell beruházni. Nem kell semmilyen biztonsági mentési rendet követni. Egyszerûen semmit se csinálunk. Ha véletlenül valami történne az adatainkkal, akkor csak mosolyogjunk és törõdjünk bele! Amennyiben az idõnk és adataink keveset vagy éppen semmit se érnek, akkor a Ne csináljunk semmit az elérhetõ legjobb biztonsági mentési megoldás számítógépünk számára. De legyünk óvatosak, mert a &unix; egy igen hasznos eszköz, és fél éven belül könnyen úgy találhatjuk magunkat, hogy mégis csak vannak értékes adataink. A Ne csináljunk semmit tökéletesen megfelelõ mentési módszer a /usr/obj és a hozzá hasonló módon a számítógépen automatikusan generált könyvtárak és állományok esetében. Ugyanilyen példa lehetne a kézikönyv HTML vagy &postscript; változata. Ezek a formátumok ugyanis az SGML források alapján keletkeznek, így a HTML vagy &postscript; állományok mentése nem életbevágó. Az SGML állományokat viszont már annál inkább mentsük! Melyik a legjobb? LISA &man.dump.8; Pont. Elizabeth D. Zwicky komolyan letesztelte az itt felsorolt összes programot. A &unix; állományrendszerek jellegzetességeinek és rajtuk az összes adatunk megõrzésének egyértelmûen a dump felel meg a legjobban. Elizabeth a minden egyes program tesztjéhez olyan állományrendszereket hozott létre, amelyek rengeteg különféle szokatlan helyzetet tartalmaztak (valamint néhány nem annyira szokatlant). Az érintett jellegzetességek: lyukas állományok, lyukas állományok és egy halom nulla, állományok érdekes karakterekkel a nevükben, olvashatatlan és írhatatlan állományok, eszközök, a mentés közben méretüket változtató állományok, a mentés közben keletkezõ és megszûnõ állományok és még sok minden más. Az eredményeit a LISA V-ben jelentette meg 1991. októberében. Lásd A biztonsági mentéshez és archiváláshoz használt programok tesztje (angolul). Az adatok helyreállítása vészhelyzetben A katasztrófa elõtt Csupán négy lépést kell megtennünk az esetleges katasztrófák bekövetkezésének esetére. bsdlabel Elõször is két példányban nyomtassuk ki az egyes lemezek lemezcímkéjét (például a bsdlabel da0 | lpr paranccsal) valamint az állományrendszerek táblázatát (az /etc/fstab állományt) és az összes rendszerindításkor megjelenõ üzenetet. helyreállító lemezek Másodsorban gondoskodjunk róla, hogy a helyreállító lemezek (boot.flp és fixit.flp) használatakor minden eszközünk látható. Ezt a legkönnyebben úgy tudjuk ellenõrizni, hogy újraindítjuk a gépet a lemezrõl és átnézzük a rendszerindítás során megjelenõ üzeneteket. Ha szerepel bennük minden eszköz és a rendszer indulása után mûködõképesek, akkor jöhet a következõ lépés. Ellenkezõ esetben létre kell hoznunk két saját rendszerindító lemezt, amelyeken a rendszermag olyan változata található, amely képes csatlakoztatni az összes lemezünket és el tudja érni a szalagos egységünket. A floppykon a következõknek kell meglennie: fdisk, bsdlabel, newfs, mount és a program, amellyel a biztonsági mentéseinket kezeljük. Az összes program legyen statikusan linkelt. Ha a dump programot használjuk, akkor a lemezekrõl ne felejtsük le a restore programot sem. A harmadik lépésben igyekezzünk minél gyakrabban szalagra menteni. Mindig gondoljuk arra, hogy a legutolsó mentés óta létrehozott változatásaink teljesen el fognak veszni. A mentéseket tartalmazó szalagokat tegyük írásvédetté. A negyedik lépésben ellenõrizzük a helyreállító lemezeket (vagy a boot.flp és fixit.flp állományokat, vagy a második lépésben készített saját lemezeinket) és mentéseket tartalmazó szalagokat. Jegyezzük le az eljárást. Ezeket a jegyzeteket is rakjuk el rendszerindító lemezekkel, a kinyomtatott adatokkal és a mentéseket tartalmazó szalagokkal együtt. Ezek a jegyzetek megvédenek minket attól, hogy a helyreállítás közbeni kétségbeesésünkben nehogy véletlenül tönkretegyük a biztonsági mentéseinket. (Hogy miként is? Például ha a tar xvf /dev/sa0 parancs helyett izgalmunkban a tar cvf /dev/sa0 parancsot gépeljük be, akkor azzal felülírjuk a biztonsági mentéseinket). A fokozott biztonság kedvéért minden alkalommal készítsünk rendszerindító lemezeket és legalább két mentést. Az egyiket valamilyen távoli helyen tároljuk. Ez a távoli hely NE ugyanannak az épületnek az alagsora legyen! Számos cég alaposan megtanulta ezt a szabályt a Világkereskedelmi központ tragédiája kapcsán. Ez a távoli hely számítógépeinkbõl és merevlemezes meghajtóinkól is fizikailag jól elkülöníthetõ, jelentõs távolságban legyen. A rendszerindító lemezek létrehozásához használható szkript /mnt/sbin/init gzip -c -best /sbin/fsck > /mnt/sbin/fsck gzip -c -best /sbin/mount > /mnt/sbin/mount gzip -c -best /sbin/halt > /mnt/sbin/halt gzip -c -best /sbin/restore > /mnt/sbin/restore gzip -c -best /bin/sh > /mnt/bin/sh gzip -c -best /bin/sync > /mnt/bin/sync cp /root/.profile /mnt/root chmod 500 /mnt/sbin/init chmod 555 /mnt/sbin/fsck /mnt/sbin/mount /mnt/sbin/halt chmod 555 /mnt/bin/sh /mnt/bin/sync chmod 6555 /mnt/sbin/restore # # Egy minimális állományrendszeri táblázat létrehozása. # cat > /mnt/etc/fstab < /mnt/etc/passwd < /mnt/etc/master.passwd < A katasztrófa után Az alapvetõ kérdés: a hardver túlélte? Ha rendszeresen készítettünk biztonsági mentéseket, akkor a szoftverek miatt egyáltalán nem kell aggódnunk. Ha a hardver megsérült, akkor a számítógép használatának újból megkezdése elõtt javasolt cserélni a meghibásodott alkatrészeket. Ha a hardverrel minden rendben találtunk, akkor nézzük meg a floppykat. Ha saját rendszerindító lemezt használunk, akkor indítsuk el egyfelhasználós módban (a boot: parancssornál írjuk be, hogy -s) és ugorjuk át a következõ bekezdést. Amennyiben viszont a boot.flp és fixit.flp állományok alapján készítettük a lemezeket, olvassunk tovább. Helyezzük a boot.flp tartalmú lemezt az elsõdleges floppy meghajtóba és indítsuk el vele a számítógépet. Az eredeti telepítõmenü jelenik meg ezután a képernyõn. Innen válasszuk ki a Fixit -- Repair mode with CDROM or floppy (Helyreállítás -- A rendszer helyreállítása CD-rõl vagy floppyról) menüpontot. Amikor kéri a telepítõ, tegyük be a fixit.flp alapján készült lemezt. A restore és az összes többi számunkra fontos program a /mnt2/rescue könyvtárban található (vagy a &os; 5.2-nél korábbi változatai esetén a /mnt2/stand könyvtárban). Egyenként állítsuk vissza az egyes állományrendszereket. mount gyökér partíció bsdlabel newfs A mount paranccsal próbáljuk meg csatlakoztatni az elsõ lemezünk rendszerindító partícióját (például mount /dev/da0a /mt). Ha a lemezcímke megsérült, akkor bsdlabel alkalmazásával partícionáljuk újra a lemezt és címkézzük meg a korábban kinyomtatott címke adatainak megfelelõen. A newfs segítségével újra hozzuk létre az állományrendszereket. Írható-olvasható módban csatlakoztassuk újra a floppy rendszerinító partícióját (mount -u -o rw /mnt). A biztonság mentést végzõ program és a biztonsági mentést tartalmazó szalagok használatával állítsuk helyre az állományrendszer tartalmát (például restore vrf /dev/sa0). Válasszuk le az állományrendszert (például umount /mnt). Mindegyik sérült állományrendszerre ismételjük a folyamatot. Ahogy mûködõképessé vált a rendszerünk, mentsük az adatainkat új szalagokra. Akármi is okozta a rendszer összeomlását vagy az adatvesztést, ismét lecsaphat. Ha most áldozunk erre még egy órát, akkor azzal a késõbbiekben számos kellemetlenségtõl óvhatjuk meg magunkat. * Mit tegyek, ha nem készültem fel a katasztrófára? ]]> Marc Fonvieille Átdolgozta és feljavította: Hálózat, memória és állomány alapú állományrendszerek virtuális lemezek lemezek virtuális A számítógépünkben létezõ fizikai lemezek, például floppyk, CD-k, merevlemezek és egyebek mellett a lemezek egy másik formáját is képes megérteni a &os; — a virtuális lemezeket. NFS Coda lemezek memória A virtuális lemeznek tekinthetõek többek közt az olyan hálózati állományrendszerek, mint például a Hálózati állományrendszer (Network File System, NFS) és a Coda, valamint a memóriában és állományokban létrehozott állományrendszerek. Attól függõen, hogy a &os; melyik változatát használjuk, az állomány és memória alapú állományrendszerek létrehozásához, illetve használatához különbözõ segédprogramokra lesz szükségünk. A &man.devfs.5; a felhasználó számára láthatatlan módon hozza létre az eszközök leíróit. Állomány alapú állományrendszerek lemezek állomány alapú &os; alatt az &man.mdconfig.8; segédprogram segítségével tudunk memórialemezeket (&man.md.4;) beállítani és engedélyezni. Az &man.mdconfig.8; használatához be kell töltenünk az &man.md.4; modult vagy hozzá kell tennünk a rendszermagunk beállításait tartalmazó állományhoz: device md Az &man.mdconfig.8; parancs háromféle memória alapú virtuális lemezt ismer: a &man.malloc.9;, állományok vagy lapozóterület használatával létrehozott memórialemezeket. Így lehet például csatlakoztatni a floppyk vagy CD-k állományokban tárolt image-eit. Egy meglevõ állományrendszer image-ének csatlakoztatása: Egy meglevõ állományrendszer image-ének csatlakoztatása az <command>mdconfig</command> paranccsal &prompt.root; mdconfig -a -t vnode -f image -u 0 &prompt.root; mount /dev/md0 /mnt Új állományrendszer létrehozása az &man.mdconfig.8; használatával: Új állomány alapú lemez létrehozása az <command>mdconfig</command> paranccsal &prompt.root; dd if=/dev/zero of=új-image bs=1k count=5k 5120+0 records in 5120+0 records out &prompt.root; mdconfig -a -t vnode -f új-image -u 0 &prompt.root; bsdlabel -w md0 auto &prompt.root; newfs md0a /dev/md0a: 5.0MB (10224 sectors) block size 16384, fragment size 2048 using 4 cylinder groups of 1.25MB, 80 blks, 192 inodes. super-block backups (for fsck -b #) at: 160, 2720, 5280, 7840 &prompt.root; mount /dev/md0a /mnt &prompt.root; df /mnt Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/md0a 4710 4 4330 0% /mnt Ha az beállítással nem adjuk meg az egység számát, akkor az &man.mdconfig.8; az &man.md.4; automatikus kiosztásán keresztül fog egy használatban még nem levõ eszközt kiválasztani. Az így kiosztott egység neve az md4 névhez hasonlóan jelenik meg a szabványos kimeneten. Az &man.mdconfig.8; használatának részleteirõl olvassuk el a hozzátartozó man oldalt. Az &man.mdconfig.8; egy nagyon sokoldalú segédeszköz, habár használatakor viszonylag sok parancsot kell kiadni egy állomány alapú állományrendszer létrehozásához. A &os; azonban alapból tartalmaz még egy &man.mdmfs.8; nevû segédprogramot is, ami az &man.md.4; lemezeket az &man.mdconfig.8; segítségével állítja be, létrehoz rajtuk egy UFS típusú állományrendszert a &man.newfs.8; segítségével és csatlakoztatja a &man.mount.8; paranccsal. Így például, ha az iménti állományrendszert akarjuk létrehozni és csatlakoztatni, akkor egyszerûen csak gépeljünk be ennyit: Állomány alapú lemezek beállítása és csatlakoztatása az <command>mdmfs</command> paranccsal &prompt.root; dd if=/dev/zero of=új-image bs=1k count=5k 5120+0 records in 5120+0 records out &prompt.root; mdmfs -F új-image -s 5m md0 /mnt &prompt.root; df /mnt Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/md0 4718 4 4338 0% /mnt Ha az paramétert az egység száma nélkül adjuk meg, akkor &man.mdmfs.8; az &man.md.4; automatikus kiosztására támaszkodva fog egy addig még nem használt eszközt kiválasztani. A &man.mdmfs.8; használatának pontos részleteivel kapcsolatban lásd a hozzátartozó man oldalt. Memória alapú állományrendszerek lemezek memória állományrendszer A memória alapú állományrendszerek esetében általában a lapozóállomány alapú megközelítést alkalmazzák. A lapozóállomány alapúság nem arra utal, hogy a memórialemezt alapból kilapozzák lemezre, hanem inkább arra, hogy a memórialemez olyan területen jön létre, amelyet szükség esetén lemezre lehet lapozni. Memória alapú lemezeket a (rendszermag szintû) &man.malloc.9; használatával is létre lehet hozni, de a malloc alapú memórialemezeknél, különösen a nagyon nagyok esetében, a rendszer könnyen össze tud omlani, ha kifut a rendelkezésére álló memóriából. Új memória alapú lemez létrehozása az <command>mdconfig</command> paranccsal &prompt.root; mdconfig -a -t swap -s 5m -u 1 &prompt.root; newfs -U md1 /dev/md1: 5.0MB (10240 sectors) block size 16384, fragment size 2048 using 4 cylinder groups of 1.27MB, 81 blks, 192 inodes. with soft updates super-block backups (for fsck -b #) at: 160, 2752, 5344, 7936 &prompt.root; mount /dev/md1 /mnt &prompt.root; df /mnt Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/md1 4718 4 4338 0% /mnt Új memória alapú lemez létrehozása az <command>mdmfs</command> paranccsal &prompt.root; mdmfs -s 5m md2 /mnt &prompt.root; df /mnt Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/md2 4846 2 4458 0% /mnt Memórialemezek leválasztása a rendszerrõl lemezek egy memórialemez leválasztása Amikor már nem akarunk tovább használni egy memória vagy állomány alapú állományrendszert, érdemes visszaadnunk az általuk felhasznált erõforrásokat a rendszernek. Elsõként válasszuk le magát az állományrendszert, majd az &man.mdconfig.8; segítségével kapcsoljuk le a lemezt a rendszerrõl és szabadítsuk fel az általa felhasznált erõforrásokat. Például az /dev/md4 eszközt így lehet lekapcsolni és felszabadítani: &prompt.root; mdconfig -d -u 4 A beállított &man.md.4; eszközökkel kapcsolatos többi információt az mdconfig -l paranccsal tudjuk lekérdezni. Tom Rhodes Írta: Az állományrendszerek pillanatképei állományrendszerek pillanatképek A &os; a Soft Updates mellett felkínál egy másik lehetõséget: az állományrendszerekrõl készíthetõ pillanatfelvételeket. Ezek a pillanatképek lehetõvé teszik a felhasználók számára, hogy adott állományrendszerekrõl képeket hozzanak létre és azt állományként kezeljék. A pillanatképeket az adott állományrendszerben kell létrehozni, és a felhasználók állományrendszerenként húsznál többet nem hozhatnak belõlük létre. Az aktív pillanatképek a szuperblokkban kerülnek rögzítésre, ezért az állományrendszerek leválasztása és újracsatlakoztatása esetén is megmaradnak, még újraindítás után is. Amikor egy pillanatképre már nincs tovább szükségünk, egy szimpla &man.rm.1; paranccsal eltávolítható. A pillanatképek tetszõleges sorrendben eltávolíthatóak, habár ilyenkor az összes általuk lefoglalt hely nem szabadul fel, mivel más pillanatképeknek még szüksége lehet bizonyos blokkjaira. Miután az &man.mksnap.ffs.8; paranccsal létrehoztunk egy pillanatképet tartalmazó állományt, beállítódik rá a módosíthatatlanságot jelentõ állományjelzõ. Egyedül az &man.unlink.1; parancs képez ez alól kivételt, mivel segítségével a pillanatképek eltávolíthatóak. A pillanatképek a &man.mount.8; paranccsal hozhatóak létre. A következõ módon tudjuk a /var egy pillanatképét elkészíteni a /var/snapshot/snap állományban: &prompt.root; mount -u -o snapshot /var/snapshot/snap /var Vagy a &man.mksnap.ffs.8; meghívásával is készíthetünk pillanatképeket: &prompt.root; mksnap_ffs /var /var/snapshot/snap Az állományrendszeren (például /var) a pillanatképeket tartalmazó állományokat a &man.find.1; paranccsal kereshetjük meg: &prompt.root; find /var -flags snapshot Ahogy elkészítettünk egy pillanatképet, több mindenre is felhasználhatjuk: Egyes rendszergazdák a pillanatképeket biztonsági mentésekhez használják, mivel ezek gond nélkül áttehetõek CD-re vagy szalagra. Az állományrendszerek sértetlenségét ellenõrzõ program, az &man.fsck.8; is lefuttatható egy ilyen pillanatképen. Feltéve, hogy az állományrendszer csatlakoztatásakor tiszta volt, mindig egy tiszta (és változásokat nem tartalmazó) eredményt kell kapnunk. Ennek megléte elengedhetetlen a háttérben futtatható &man.fsck.8; mûködéséhez. Futassuk le a &man.dump.8; segédprogramot a pillanatképen. Az így létrehozott mentés megegyezik az állományrendszer adott pillanatban felvett állapotával. Az beállítás megadásával maga a &man.dump.8; is képes egyetlen parancsban pillanatfelvételt készíteni, ebbõl létrehozni a mentést, majd eltávolítani. A pillanatképet képesek vagyunk a &man.mount.8; paranccsal az állományrendszer befagyasztott változataként csatlakoztatni: &prompt.root; mdconfig -a -t vnode -f /var/snapshot/snap -u 4 &prompt.root; mount -r /dev/md4 /mnt Így már a /mnt könyvtárba csatlakoztatva be tudjuk járni a befagyasztott /var állományrendszert. Minden a pillanatfelvétel készítésének idõpontjának megfelelõ állapotban fog maradni. Az egyetlen kivétel talán annyi, hogy korábbi pillanatképek nulla méretû állományként fognak megjelenni. Mikor befejeztük a pillanatképek használatát, a &man.umount.8; paranccsal le tudjuk választani: &prompt.root; umount /mnt &prompt.root; mdconfig -d -u 4 A és az állományrendszerek pillanatképeinek használatával, illetve mûszaki leírásukkal kapcsolatban látogassuk meg Marshall Kirk McKusick honlapját a címen (angolul). Az állományrendszerek kvótái nyilvántartás lemezterület lemezkvóták A kvóták használata az operációs rendszerben egy olyan választható lehetõség, aminek segítségével állományrendszerenként korlátozni tudjuk az egyes felhasználók vagy csoporttagok által elhasznált lemezterület és/vagy állományok mennyiségét. Ezt leggyakrabban olyan idõosztásos rendszerekben használják ki, ahol szükség lehet az egyes felhasználókra vagy csoportokra esõ erõforrások mennyiségének szabályozására. Ezzel tudjuk megakadályozni, hogy a felhasználók vagy csoportok elfogyasszák az összes rendelkezésre álló lemezterületet. A kvóták használatának beállítása Mielõtt nekilátnánk a kvóták használatának, meg kell gyõzõdnünk róla, hogy a rendszermagunkban megvan hozzá a szükséges támogatás. A kvótákat a következõ sorral lehet engedélyezni a rendszermag beállításait tartalmazó állományban: options QUOTA A gyári GENERIC rendszermag ezt alapból nem engedélyezi, ezért ehhez mindenképpen be kell állítani, le kell fordítani és telepíteni egy kell saját rendszermagot. A saját rendszermag létrehozásához kövessük a utasításait. Ha ezzel megvagyunk, akkor a következõ sorral bõvítsük ki az /etc/rc.conf állományt: enable_quotas="YES" lemezkvóták ellenõrzése A kvótákat kezelõ rendszer indításának finomabb szabályozására létezik még egy további beállítási lehetõség is. A rendszer indítása során általában az egyes állományrendszerek kvótáját a &man.quotacheck.8; program ellenõrzi. A &man.quotacheck.8; gondoskodik róla, hogy a kvótákat tároló adatbázis ténylegesen az állományrendszeren található adatokat tükrözi. Ez egy nagyon idõigényes folyamat, ami rányomja bélyegét a rendszer elindulásához szükséges idõ mennyiségére is. Amennyiben szeretnénk megtakarítani ezt a lépést, tegyük bele az /etc/rc.conf állományba a direkt erre a célra kialakított beállítást: check_quotas="NO" Végezetül az állományrendszereken az /etc/fstab megfelelõ módosításával tudjuk egyenként engedélyezni a lemezkvóták használatát. Itt lehet bekapcsolni az állományrendszerek felhasználókra vagy csoportokra, esetleg mind a kettõjükre vonatkozó kvótáikat. Ha felhasználói szintû kvótákat akarunk engedélyezni egy állományrendszeren, akkor az /etc/fstab állományban az állományrendszer beállításai közé vegyük fel a opciót. Például így: /dev/da1s2g /home ufs rw,userquota 1 2 Ehhez hasonlóan tudjuk engedélyezni a helyett a opció használatával a csoportszintû kvótákat is. A felhasználói- és csoportszintû kvóták együttes engedélyezéséhez így kell átírni az állományrendszer bejegyzését: /dev/da1s2g /home ufs rw,userquota,groupquota 1 2 Alapértelmezés szerint az állományrendszerekhez tartozó kvóták a gyökerükben található quota.user valamint quota.group állományokban tárolódnak. Errõl részletesebben az &man.fstab.5; man oldalon olvashatunk. Noha még az &man.fstab.5; man oldala szerint is megadható más elérési út a kvótákat tároló állományokhoz, semmiképpen sem javasoljuk ezt, mert úgy tûnik, hogy a kvótákat kezelõ különbözõ segédprogramok ezzel nem képesek rendesen megbirkózni. Most kell újraindítani a rendszerünket az új rendszermaggal. Az /etc/rc magától le fogja futtatni a kezdeti kvótaállományok létrehozásához szükséges parancsokat az /etc/fstab állományban megadott állományrendszereken. Ennek megfelelõen tehát nem nekünk kell kézzel létrehoznunk ezeket az állományokat. Hétköznapi esetben egyáltalán nem kell manuális futtatnunk a &man.quotacheck.8;, &man.quotaon.8; vagy &man.quotaoff.8; parancsokat. Habár ha tisztában szeretnénk lenni a pontos mûködésükkel, akkor mindenképpen lapozzuk fel a hozzájuk tartozó man oldalakat. A kvóták beállítása lemezkvóták korlátok Ahogy sikerült beállítani a kvóták használatát, egybõl ellenõrizzük is a mûködõképességüket. Ezt legegyszerûbben a következõ paranccsal tehetjük meg: &prompt.root; quota -v Itt egy sorban összefoglalva láthatjuk a jelenlegi lemezhasználatot és az egyes állományrendszereken engedélyezett kvóták korlátait. Most már készenállunk arra, hogy az &man.edquota.8; paranccsal végre korlátokat is beállítsunk a kvótákhoz. Számos beállítás áll rendelkezésünkre a felhasználók vagy csoportok által lefoglalható lemezterület vagy a létrehozható állományok számának korlátozását illetõen. A helyfoglalást szabályozhatjuk lemezterület alapján (blokk kvóta) vagy az állományok száma szerint (állományleíró kvóta), esetleg a kettõ kombinációjával. A korlátok további két kategóriára bonthatóak: erõsre és gyengére. erõs korlát Az erõs korlátot (hard limit) nem lehet túllépni. Ahogy a felhasználó eléri a számára kiszabott erõs korlátot, semmilyen további területet nem használhat fel a kérdéses állományrendszeren. Például, ha a felhasználónak az állományrendszeren 500 kilobyte-os erõs korlátot állítottunk be, és éppen 490 kilobyte-nál tart, akkor a felhasználó innen már csak 10 kilobyte-nyi helyet foglalhat le. 11 kilobyte lefoglalása már nem fog sikerrel járni. gyenge korlát Ezzel szemben a gyenge korlátok (soft limit) egy adott ideig átléphetõek. Ezt az idõt türelmi idõnek (grace period) nevezik, ami alapértelmezés szerint egy hét. Ha a felhasználó a gyenge korláton felül marad a türelmi idõ után is, akkor ezt a gyenge korlát erõssé válik és semmilyen további helyfoglalásra nem lesz lehetõsége. Amikor a felhasználók újra a gyenge korlát alá kerül, a türelmi idõ is visszaáll a beállított értékére. A most következõ példában az &man.edquota.8; parancsot mutatjuk be. Amikor meghívjuk az &man.edquota.8; parancsot, akkor elindul az EDITOR környezeti változónak megfelelõ szövegszerkesztõ, illetve ennek hiányában a vi, és lehetõségünk nyílik a kvóta korlátainak módosítására. &prompt.root; edquota -u teszt Quotas for user teszt: /usr: kbytes in use: 65, limits (soft = 50, hard = 75) inodes in use: 7, limits (soft = 50, hard = 60) /usr/var: kbytes in use: 0, limits (soft = 50, hard = 75) inodes in use: 0, limits (soft = 50, hard = 60) Normális esetben minden kvótával rendelkezõ állományrendszerhez két sort kapunk. Közülük az egyik sorban szerepelnek a blokkok korlátai, a másikban az állományleírók korlátai. Ha valamelyiküket meg akarjuk változtatni, akkor egyszerûen csak át kell írnunk az adott korlát értékét. Például növeljük meg a felhasználók 50-es gyenge és 75-ös erõs blokk korlátját 500-as gyenge és 600-as erõs korlátra. Ehhez szerkesszük át a /usr: kbytes in use: 65, limits (soft = 50, hard = 75) sort erre: /usr: kbytes in use: 65, limits (soft = 500, hard = 600) Az új korlátok akkor fognak érvénybe lépni, miután kiléptünk a szövegszerkesztõbõl. Néha hasznos lehet a korlátokat adott felhasználói azonosítókhoz beállítani. Ezt az &man.edquota.8; parancs paraméterével tudjuk elvégezni. Elõször is állítsuk be egy felhasználónak a beállítani kívánt korlátokat, majd futtassuk le az edquota -p teszt kezdõuid-véguid parancsot. Például ha a teszt nevû felhasználónak állítottuk be a számunkra megfelelõ korlátokat, akkor a következõ paranccsal lehet a rá vonatkozó korlátokat kiterjeszteni a 10 000 és 19 999 közötti azonosítójú felhasználókra: &prompt.root; edquota -p teszt 10000-19999 Errõl bõvebben az &man.edquota.8; man oldalán kaphatunk felvilágosítást. A kvóták korlátainak és a lemezhasználat ellenõrzése lemezkvóták ellenõrzése A kvóták korlátait és a lemez jelenlegi kihasználtságát a &man.quota.1; vagy &man.repquota.8; parancsokkal is ellenõrizhetjük. A &man.quota.1; parancs segítségével ellenõrizhetõ az egyes felhasználók vagy csoportok kvótája és lemezhasználata. A felhasználók csak a saját adataikhoz férhetnek hozzá, illetve mindazon csoportokéhoz, aminek tagjai. Egyedül a rendszeradminisztrátor képes látni az összes felhasználó és csoport kvótáját. A &man.repquota.8; paranccsal kérdezhetõ le az összes kvóta és lemezhasználat rövid kimutatása minden olyan állományrendszeren, ahol azok engedélyezettek. A következõ kimenet a quota -v parancstól származik, ahol a felhasználónak két állományrendszeren is vannak kvótái: Disk quotas for user teszt (uid 1002): Filesystem usage quota limit grace files quota limit grace /usr 65* 50 75 5days 7 50 60 /usr/var 0 50 75 0 50 60 türelmi idõ A fenti példában látható, hogy a felhasználó a /usr állományrendszeren pillanatnyilag 15 kilobyte-tal van az 50 kilobyte-os gyenge korlátja felett és 5 napja van hátra a türelmi idõbõl. Vegyük észre a szám mellett levõ csillagot (*), amivel a rendszer jelzi, hogy a felhasználó túllépte a korlátját. A &man.quota.1; parancs kimenetében általában nem jelennek meg azok az állományrendszerek, amelyeken a felhasználónak ugyan vannak kvótái, de nem foglal rajtuk lemezterületet. A beállítás megadásával ezek az állományrendszerek is láthatóvá válnak, mint ahogy azt a fenti példában is megfigyelhettük a /usr/var esetében. Kvóták NFS-en keresztül NFS A kvóták az NFS szerver kvótákért felelõs alrendszerében is engedélyezhetõek. Az &man.rpc.rquotad.8; démon teszi az NFS klienseken futtatott &man.quota.1; parancsok számára elérhetõvé a kvótákkal kapcsolatos információkat, aminek köszönhetõen a felhasználók távolról is képesek lekérdezni a kvótáikat. Az rpc.rquotad aktivilásához a következõt kell beállítani az /etc/inetd.conf állományban: rquotad/1 dgram rpc/udp wait root /usr/libexec/rpc.rquotad rpc.rquotad Majd ne felejtsük el újraindítani az inetd démont sem: &prompt.root; /etc/rc.d/inetd restart Lucky Green Írta:
shamrock@cypherpunks.to
 A lemezpartíciók titkosítása lemezek titkosítása A &os; kitûnõ futásközbeni védelmet ajánl fel az adatok illetéktelen hozzáférése ellen. Az állományok engedélyei és a kötelezõ hozzáférés-vezérlés (Mandatory Access Control, MAC, lásd ) segítenek megvédeni érzékeny adatainkat az illéktelenek ellen az operációs rendszer futása és a számítógép mûködése során. Azonban az operációs rendszerben kezelt engedélyek teljesen hatástalanok abban az esetben, ha a támadó fizikailag is képes hozzáférni a számítógépünkhöz, eltávolítani a merevlemezt és egy másik operációs rendszer segítségével kielemezni a rajta található fontos adatainkat. Függetlenül attól, hogy a támadó valójában miként is férkõzött hozzá a merevlemezünkhöz, vagy miként kapcsolta le a számítógépünket, a &os; megtalálható GEOM alapú lemeztitkosítás (gbde) és a geli titkosítási alrendszer egyaránt képes védelmet nyújtani a számítógépen található állományrendszerek számára az értékes adatok után kutató igen motivált betörõk ellen. A csupán egyes állományokra kiterjedõ körmönfont titkosítási módszerekkel szemben a gbde és a geli az egész állományrendszert észrevétlen módon titkosítja. Titkosítatlan adat nem is kerül a merevlemezre. A lemez titkosítása a <application>gbde</application> használatával Váljunk <username>root</username> felhasználóvá A gbde beállításához rendszeradminisztrátori jogosultságokra lesz szükségünk. &prompt.user; su - Password: Adjuk hozzá a &man.gbde.4; támogatását a rendszermag konfigurációs állományához Tegyük a következõ sort a rendszermag beállításait tartalmazó állományba: options GEOM_BDE Fordítsuk újra a rendszermagot a ben leírtak szerint. Indítsuk el a számítógépet az új rendszermaggal. A rendszermag újrafordítása helyett a kldload paranccsal is betölthetjük a &man.gbde.4; modulját: &prompt.root; kldload geom_bde A titkosított merevlemez elõkészítése A következõ példa azt feltételezi, hogy a rendszerünkhöz egy új merevlemezt adunk hozzá, amin egyetlen titkosított partíció foglal helyet. Ezt a partíciót a /private könyvtárba fogjuk csatlakoztatni. A gbde használható a /home és a /var/mail titkosítására is, de ennek megvalósítása olyan bonyolult utasításokat igényel, amelyek meghaladják ennek a bevezetésnek a kereteit. Az új merevlemez hozzáadása A ban bemutatottak szerint adjuk hozzá a rendszerünkhöz az új merevlemezt. A példában az új lemez partícióját a /dev/ad4s1c néven fogjuk tudni elérni. A /dev/ad0s1* eszközök a példában szereplõ &os; rendszer szabványos partícióit jelölik. &prompt.root; ls /dev/ad* /dev/ad0 /dev/ad0s1b /dev/ad0s1e /dev/ad4s1 /dev/ad0s1 /dev/ad0s1c /dev/ad0s1f /dev/ad4s1c /dev/ad0s1a /dev/ad0s1d /dev/ad4 Hozzunk létre egy könyvtárat a gbde zárolásainak tárolásához &prompt.root; mkdir /etc/gbde A gbdenek azért van szüksége a zárolásokat rögzítõ állományokra, hogy hozzá tudjon férni a titkosított partíciókhoz. Amennyiben ezt nem tudja megtenni, a gbde anélkül nem lesz képes visszafejteni a titkosított partíciókon tárolt adatokat, hogy az ezeket elérni akaró szoftvereknek ne kelljen jelentõsebb mértékben manuálisan beavatkoznia. Mindegyik titkosított partíció külön zároló állományt használ. A gbde partíció inicializálása A gbde által használt partíciókat használatuk elõtt inicializálni kell. Ezt a mûveletet azonban csak egyszer kell elvégezni: &prompt.root; gbde init /dev/ad4s1c -i -L /etc/gbde/ad4s1c.lock A &man.gbde.8; ekkor elindít egy szövegszerkesztõt és benne egy sablon segítségével be tudjuk állítani a különbözõ konfigurációs értékeket. Az UFS1 vagy UFS2 használata esetén állítsuk a szektorméretet 2048-ra: $FreeBSD: src/sbin/gbde/template.txt,v 1.1 2002/10/20 11:16:13 phk Exp $ # # Sector size is the smallest unit of data which can be read or written. # Making it too small decreases performance and decreases available space. # Making it too large may prevent filesystems from working. 512 is the # minimum and always safe. For UFS, use the fragment size # sector_size = 2048 [...] A megjegyzés fordítása: A szektorméret az adatok írásának és olvasásának legkisebb egysége. Ha túlságosan kicsire választjuk meg, akkor csökken a teljesítmény és csökken a rendelkezésre álló hely. Ha viszont túlságosan nagyra hagyjuk, akkor azzal akadályozzuk az állományrendszerek munkáját. 512 a legkisebb érték, amely mindig megbízható. Az UFS esetén használjuk a fragmensek méretét. A &man.gbde.8; kétszer is rá fog kérdeni az adatok titkosítására használt jelmondatra. A jelmondatnak természetesen mind a kétszer ugyanannak kell lennie. A gbde védelmének hatékonysága teljesen mértékben az általunk választott jelmondat minõségétõl függ A könnyen megjegyezhetõ ám mégis biztonságos jelmondatok megválasztásához a Diceware Passphrase honlapján találunk egy kis segítséget (angolul). . A gbde init parancs létrehoz egy zároló állományt a gbde partícióhoz, amely ebben a példában az /etc/gbde/ad4s1c.lock néven keletkezett. A gbde zároló állományainak .lock névre kell végzõdniük, mivel az /etc/rc.d/gbde indítószkript csak ebben az esetben észleli rendesen. A gbde zároló állományait a titkosított partíciók tartalmával együtt kell lementeni. Miközben a zároló állomány törlése nem tudja megakadályozni, hogy az elszánt támadó visszafejtse a gbde által titkosított partíciót, addig a zároló állomány nélkül a jogos tulajdonos órási mennyiségû munka befektetése nélkül képtelen lesz hozzáférni a rajta levõ adatokhoz. Ez utóbbitól egyébként a &man.gbde.8; és a rendszer tervezõje is totálisan elhatárolja magát. A titkosított partíció illesztése a rendszermaghoz &prompt.root; gbde attach /dev/ad4s1c -l /etc/gbde/ad4s1c.lock Ekkor a titkosított partíció illesztéséhez a rendszer kérni fogja az inicializálás során választott jelmondatot. Ezután az új titkosított eszköz megjelenik a /dev könyvtárban /dev/eszköznév.bde néven: &prompt.root; ls /dev/ad* /dev/ad0 /dev/ad0s1b /dev/ad0s1e /dev/ad4s1 /dev/ad0s1 /dev/ad0s1c /dev/ad0s1f /dev/ad4s1c /dev/ad0s1a /dev/ad0s1d /dev/ad4 /dev/ad4s1c.bde Állományrendszer kialakítása egy titkosított eszközön Ahogy sikerült a titkosított eszközt illeszteni a rendszermaghoz, létre is tudunk hozni egy állományrendszert rajta. Erre a célra a &man.newfs.8; remekül használható. Mivel egy új UFS2 állományrendszerek inicializálása sokkal gyorsabb a régi UFS1 állományrendszerek inicializálásánál, ezért a &man.newfs.8; használata esetén az beállítás megadása ajánlott. &prompt.root; newfs -U -O2 /dev/ad4s1c.bde A &man.newfs.8; parancsot egy illesztett gbde partíción kell végrehajtani, amit onnan ismerhetünk meg, hogy az eszköz nevében szerepel a *.bde kiterjesztés. A titkosított partíció csatlakoztatása Hozzunk létre egy csatlakozási pontot a titkosított állományrendszer számára. &prompt.root; mkdir /privát Csatlakoztassuk a titkosított állományrendszert. &prompt.root; mount /dev/ad4s1c.bde /privát Ellenõrizzük a titkosított állományrendszer mûködõképességét A titkosított állományrendszert most már látja a &man.df.1; program és készen áll a használatra. &prompt.user; df -H Filesystem Size Used Avail Capacity Mounted on /dev/ad0s1a 1037M 72M 883M 8% / /devfs 1.0K 1.0K 0B 100% /dev /dev/ad0s1f 8.1G 55K 7.5G 0% /home /dev/ad0s1e 1037M 1.1M 953M 0% /tmp /dev/ad0s1d 6.1G 1.9G 3.7G 35% /usr /dev/ad4s1c.bde 150G 4.1K 138G 0% /private Létezõ titkosított állományrendszerek csatlakoztatása A rendszer minden egyes indítása után az összes titkosított állományrendszert tényleges használata elõtt újra illeszteni kell a rendszermaghoz, ellenõrizni az épségét és csatlakoztatni. Az ehhez szükséges parancsokat root felhasználóként kell kiadni. A gbde partíció illesztése a rendszermaghoz &prompt.root; gbde attach /dev/ad4s1c -l /etc/gbde/ad4s1c.lock A gbde partíció inicializálása során megadott jelmondatot kell megadnunk a mûvelet elvégzéséhez. Az állományrendszer épségének ellenõrzése Mivel a titkosított állományrendszerek az automatikus csatlakoztatáshoz még nem szerepeltethetõek az /etc/fstab állományban, ezért az ilyen állományrendszereket csatlakoztatásuk elõtt manuálisan ellenõriztetni kell a &man.fsck.8; lefuttatásával. &prompt.root; fsck -p -t ffs /dev/ad4s1c.bde A titkosított állományrendszer csatlakoztatása &prompt.root; mount /dev/ad4s1c.bde /privát A titkosított állományrendszer most már készen áll a használatra. A titkosított partíciók önálló csatlakoztatása Lehet írni olyan szkriptet, amely a titkosított partíciókat magától illeszti, ellenõrzi és csatlakoztatja, de biztonsági megfontolásokból semmi esetben sem szabad tartalmaznia a &man.gbde.8; jelszavát. Ehelyett azt javasoljuk, hogy az ilyen szkripteknek külön meg kelljen adni a jelszót konzolon vagy az &man.ssh.1; használatán keresztül. De használhatjuk a mellékelt rc.d szkriptet is. A szkript paramétereit az &man.rc.conf.5; állományon keresztül adhatjuk meg, például: gbde_autoattach_all="YES" gbde_devices="ad4s1c" gbde_lockdir="/etc/gbde" Ilyenkor a gbde által használt jelmondatot a rendszer indításakor kell megadni. Miután begépeltük a megfelelõ jelmondatot, a titkosított gbde partíció magától csatlakoztatásra kerül. Ez akkor lehet hasznos, ha a gbde megoldását hordozható számítógépeken alkalmazzuk. A gbde által alkalmazott titkosítási módszerek A &man.gbde.8; a szektorok tartalmát 128 bites AES használatával CBC módban titkosítja. A lemezen található minden egyes szektort eltérõ AES kulccsal kódolja. A gbde kriptográfiai felépítését, valamint mindazt, hogy az egyes szektorok kulcsai miként származtathatóak a felhasználó által megadott jelmondatból, a &man.gbde.4; man oldalán olvashatjuk. Kompatibilitási problémák A &man.sysinstall.8; nem kompatibilis a gbde által titkosított eszközökkel. A &man.sysinstall.8; indítása elõtt minden *.bde eszközt ki kell iktatni a rendszermagból, különben az eszközök keresése során össze fog omlani. A példánkban használt titkosított eszközt a következõ paranccsal kell lekapcsolni: &prompt.root; gbde detach /dev/ad4s1c Továbbá megjegyezzük azt is, hogy a &man.vinum.4; nem használja a &man.geom.4; alrendszert, ezért a gbde alkalmazása során nem használhatunk Vinum-köteteket. Daniel Gerzo Írta: A lemezek titkosítása a <command>geli</command> használatával A &os; 6.0 változatától kezdve egy új kriptográfiai GEOM osztály is a rendelkezésünkre áll, melyet pillanatnyilag &a.pjd; fejleszt. A geli segédprogram némileg különbözõ a gbde megoldásától — más lehetõségeket kínál fel és a titkosítást is egy eltérõ séma mentén valósítja meg. A &man.geli.8; legfontosabb jellemzõi a következõk: A &man.crypto.9; keretrendszerét használja — tehát ha rendelkezünk kriptográfiai hardverrel, akkor a geli automatikusan használni fogja. Több kriptográfiai algoritmust is ismer (melyek jelenleg az AES, Blowfish és a 3DES). Segítségével a rendszerindításhoz használt (gyökér) partíció is titkosítható. Ilyenkor a szükséges jelmondatot a rendszer indításakor kell megadni. Két független kulcsot (például egy kulcsot és egy céges kulcsot) is használhatunk vele. A geli gyors — egyszerûen csak szektorról szektorra titkosít. Lehetõvé teszi a mesterkulcsok mentését is visszaállítását. Ha a felhasználó véletlenül megsemmisítené a kulcsát, akkor a biztonsági mentésbõl helyreállított kulcsok segítségével vissza tudjuk szerezni az adatainkat is. Segítségével a lemezeket véletlenszerû, egyszeri jelszavakkal is illeszthetjük — ez különösen fontos lapozóterületek és ideiglenes állományrendszerek esetében. A geli által felkínált lehetõségekrõl a &man.geli.8; man oldalán találhatunk többet. A következõ lépések bemutatják, hogyan lehet a &os; rendszermagjában engedélyezni a geli támogatását, és hogyan lehet létrehozni és használni egy geli titkosítással rendelkezõ adathordozót. A geli alkalmazásához legalább a &os; 6.0-RELEASE vagy késõbbi változatára van szükségünk. Mivel a rendszermagot is módosítanunk kell, ezért rendszeradminisztrátori jogosultságok kellenek a mûveletek elvégzéséhez. A <command>geli</command> támogatásának hozzáadása a rendszermaghoz Vegyük hozzá a következõ sorokat a rendszermag beállításait tartalmazó állományhoz: options GEOM_ELI device crypto Fordítsuk újra a rendszermagot a ben leírtak szerint. Betölthetjük a geli modulját is a rendszer indításakor. Ehhez a következõ sort kell betenni a /boot/loader.conf állományba: geom_eli_load="YES" A &man.geli.8; most már használható a rendszermagban. A mesterkulcs legenerálása A most következõ példában egy kulcsot tartalmazó állomány létrehozását illusztráljuk, amit a /privát könyvtárba csatlakoztatott titkosított adathordozó mesterkulcsához fogunk használni. A kulcs állomány a mesterkulcs titkosításához felhasznált véletlenszerû adatot fogja tartalmazni, valamint rajta kívül még a mesterkulcsot egy jelmondattal is védjük. Az adathordozó szektormérete 4 kilobyte-os lesz. Emellett még bemutatjuk, hogyan kell illeszteni egy geli-adathordozót, állományrendszert létrehozni rajta, csatlakoztatni, dolgozni vele és lekapcsolni. A nagyobb teljesítmény érdekében javasolt nagyobb szektorméretet választani (mint például 4 kilobyte). A mesterkulcsot egy jelmondattal fogjuk védeni és a kulcsok készítéséhez használt adatforrás a /dev/random lesz. A /dev/da2.eli, amelyet mit csak adathordozónak fogunk csak hívni, szektorainak mérete 4 kilobyte lesz. &prompt.root; dd if=/dev/random of=/root/da2.key bs=64 count=1 &prompt.root; geli init -s 4096 -K /root/da2.key /dev/da2 Enter new passphrase: Reenter new passphrase: Nem kötelezõ egyszerre használni a jelmondatot és a kulcs állományt. A mesterkulcs elzárásának bebiztosítására bármelyik módszer alkalmas. Ha a kulcs állomány a - paraméterrel adjuk meg, akkor a szabványos bemenetrõl olvassa be a program. Ez a példa több kulcs használatát mutatja be. &prompt.root; cat kulcs1 kulcs2 kulcs3 | geli init -K - /dev/da2 Az adathordozó illesztése a generált kulccsal &prompt.root; geli attach -k /root/da2.key /dev/da2 Enter passphrase: Az új titkosítatlan eszköz neve /dev/da2.eli lesz. &prompt.root; ls /dev/da2* /dev/da2 /dev/da2.eli Az új állományrendszer kialakítása &prompt.root; dd if=/dev/random of=/dev/da2.eli bs=1m &prompt.root; newfs /dev/da2.eli &prompt.root; mount /dev/da2.eli /privát A titkosított állományrendszer most már &man.df.1; számára is látszik és használható: &prompt.root; df -H Filesystem Size Used Avail Capacity Mounted on /dev/ad0s1a 248M 89M 139M 38% / /devfs 1.0K 1.0K 0B 100% /dev /dev/ad0s1f 7.7G 2.3G 4.9G 32% /usr /dev/ad0s1d 989M 1.5M 909M 0% /tmp /dev/ad0s1e 3.9G 1.3G 2.3G 35% /var /dev/da2.eli 150G 4.1K 138G 0% /private Az adathordozó leválasztása és lekapcsolása Miután befejeztük a munkát a titkosított partíción, és a /privát partícióra már nincs tovább szükségünk, érdemes leválasztanunk és kiiktatnunk a geli titkosítású partíciót a rendszermagból. &prompt.root; umount /privát &prompt.root; geli detach da2.eli A &man.geli.8; használatáról bõvebben a saját man oldalán tájékozódhatunk. A <filename>geli</filename> <filename>rc.d</filename> szkriptjének használata A geli mellett találhatunk egy saját rc.d szkriptet, amely jelentõsen leegyszerûsíti a geli használatát. A geli például így paraméterezhetõ az &man.rc.conf.5; állományon keresztül: geli_devices="da2" geli_da2_flags="-p -k /root/da2.key" Ennek segítségével a /dev/da2 eszközt geli adathordozóként állítjuk be a /root/da2.key állományban található mesterkulcs felhasználásával, de az illesztéskor a geli nem kér jelmondatot (ezt csak akkor fogja tenni, ha a geli init parancs kiadásához hozzátesszük a beállítást). A rendszer leállítása elõtt pedig a geli adathordozó így automatikusan leválasztásra kerül. Az rc.d beállításával kapcsolatos tudnivalókat a kézikönyv rc.d szkriptekrõl szóló szakaszában ismerhetjük meg. Christian Brüffer Írta: A lapozóterület titkosítása lapozóterület titkosítása A &os;-ben a lapozóterület titkosítása nagyon könnyen beállítható és már a &os; 5.3-RELEASE változata óta elérhetõ. Attól függõen, hogy konkrétan a &os; melyik verzióját használjuk, a konfigurációhoz kapcsolódó beállítások némileg eltérhetnek. A &os; 6.0-RELEASE változatától kezdõdõen a &man.gbde.8; és a &man.geli.8; alrendszerek is használhatóak a lapozóterület titkosítására. A korábbi verziókban egyedül csak a &man.gbde.8; érhetõ el. Mind a két rendszer az encswap rc.d szkriptet használja. Az elõzõ szakaszban, vagyis a A lemezpartíciók titkosításában már röviden összefoglaltuk a különbözõ titkosítással foglalkozó alrendszereket. Miért kellene titkosítanunk a lapozóterületet? Hasonlóan a lemezpartíciók titkosításához, a lapozóterület titkosításának is az a célja, hogy védjük az érzékeny információkat. Képzeljük el, hogy egy olyan alkalmazással dolgozunk, amely jelszavakat kezel. Amíg ezek a jelszavak a memóriában maradnak, addig minden a legnagyobb rendben van. Azonban amikor az operációs rendszer nekilát a fizikai memória felszabadításához kilapozni ezeket az adatokat, a jelszavak titkosítatlanul kerülnek a lemez felületére és egy támadó számára könnyû prédává válnak. Ilyen helyzetekben csak lapozóterület titkosítása jelenthet megoldást. Elõkészületek A szakasz további részében a ad0s1b lesz a lapozásra használt partíció. Egészen mostanáig nem titkosítottuk a lapozóterületet. Így elképzelhetõ, hogy a lemezre már titkosítatlanul kikerültek jelszavak vagy bármilyen más érzékeny adatok. A csorba kiköszörülésére a lapozóterületen található összes adatot írjuk felül véletlenszerûen generált szeméttel: &prompt.root; dd if=/dev/random of=/dev/ad0s1b bs=1m A lapozóterület titkosítása a &man.gbde.8; használatával Ha a &os; 6.0-RELEASE vagy újabb változatát használjuk, akkor az /etc/fstab állományban tegyük hozzá a .bde utótagot az a lapozóterülethez tartozó eszköz nevéhez. # Device Mountpoint FStype Options Dump Pass# /dev/ad0s1b.bde none swap sw 0 0 A &os; 6.0-RELEASE elõtti kiadások esetében a következõ sort is hozzá kell tennünk az /etc/rc.conf állományhoz: gbde_swap_enable="YES" A lapozóterület titkosítása a &man.geli.8; használatával A &man.gbde.8; használatához hasonlóan a &man.geli.8; által felajánlott titkosítást is alkalmazhatjuk a lapozóterület védelmére. Ilyenkor az /etc/fstab állományban az .eli utótagot kell hozzátenni a lapozóterülethez tartozó eszköz névhez. # Device Mountpoint FStype Options Dump Pass# /dev/ad0s1b.eli none swap sw 0 0 Az &man.geli.8; az AES algoritmust alapértelmezés szerint 256 bites kulccsal használja. Ezek az alapértelmezések megváltoztathatóak az /etc/rc.conf állományban a geli_swap_flags beállítás használatával. A következõ sor arra utasítja az encswap rc.d szkriptet, hogy a &man.geli.8; és a Blowfish algoritmus használatával hozzon létre egy lapozópartíciót 128 bites kulccsal, 4 kilobyte-os szektormérettel és a detach on last close (lekapcsolás használat után) beállítással: geli_swap_flags="-e blowfish -l 128 -s 4096 -d" A &os; 6.2-RELEASE verzió elõtti rendszerekben a következõ sort kell használni: geli_swap_flags="-a blowfish -l 128 -s 4096 -d" A többi beállításhoz a &man.geli.8; man oldalán a onetime parancs leírását érdemes áttanulmányozni. Ellenõrizzük a mûködését Miután újraindítottuk a rendszert, a titkosított lapozóterület helyes mûködését a swapinfo paranccsal ellenõrizhetjük le. A &man.gbde.8; esetében: &prompt.user; swapinfo Device 1K-blocks Used Avail Capacity /dev/ad0s1b.bde 542720 0 542720 0% Valamint a &man.geli.8; esetében: &prompt.user; swapinfo Device 1K-blocks Used Avail Capacity /dev/ad0s1b.eli 542720 0 542720 0% diff --git a/hu_HU.ISO8859-2/books/handbook/mirrors/chapter.sgml b/hu_HU.ISO8859-2/books/handbook/mirrors/chapter.sgml index e4ce8892ce..f3b3b635cb 100644 --- a/hu_HU.ISO8859-2/books/handbook/mirrors/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/mirrors/chapter.sgml @@ -1,3970 +1,3970 @@ 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 02:ed:1b:17:d6:97:2b:58:5e:5c:e2:da:3b:89:88:26 /etc/ssh/ssh_host_rsa_key.pub 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 + url="http://users.csc.calpoly.edu/~gfisher/classes/308/handouts/cvs-basics.html">A CVS bemutatása (forrás: Kaliforna Állami Mûszaki Egyetem). 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/&os; 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. 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 &os;-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_8 A &os;-8.X fejlesztési ága, más néven a &os; 8-STABLE RELENG_8_0 A &os;-8.0 kiadás ága, ahová csak a biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_7 A &os;-7.X fejlesztési ága, más néven a &os; 7-STABLE RELENG_7_3 A &os;-7.3 kiadás ága, ahová csak a biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_7_2 A &os;-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 &os;-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 &os;-7.0 kiadás ága, ahová csak a biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_6 A &os;-6.X fejlesztési ága, más néven a &os; 6-STABLE RELENG_6_4 A &os;-6.4 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_6_3 A &os;-6.3 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_6_2 A &os;-6.2 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_6_1 A &os;-6.1 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_6_0 A &os;-6.0 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_5 A &os;-5.X fejlesztési ág, más néven a &os; 5-STABLE. RELENG_5_5 A &os;-5.5 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_5_4 A &os;-5.4 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_5_3 A &os;-5.3 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_5_2 A &os;-5.2 és &os;-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 &os;-5.1 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_5_0 A &os;-5.0 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_4 A &os;-4.X fejlesztési ága, más néven a &os; 4-STABLE. RELENG_4_11 A &os;-4.11 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_4_10 A &os;-4.10 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_4_9 A &os;-4.9 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_4_8 A &os;-4.8 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_4_7 A &os;-4.7 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_4_6 A &os;-4.6 és &os;-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 &os;-4.5 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_4_4 A &os;-4.4 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_4_3 A &os;-4.3 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_3 A &os;-3.X fejlesztési ága, más néven a 3.X-STABLE. RELENG_2_2 A &os;-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_3_0_RELEASE &os; 7.3 RELENG_7_2_0_RELEASE &os; 7.2 RELENG_7_1_0_RELEASE &os; 7.1 RELENG_7_0_0_RELEASE &os; 7.0 RELENG_6_4_0_RELEASE &os; 6.4 RELENG_6_3_0_RELEASE &os; 6.3 RELENG_6_2_0_RELEASE &os; 6.2 RELENG_6_1_0_RELEASE &os; 6.1 RELENG_6_0_0_RELEASE &os; 6.0 RELENG_5_5_0_RELEASE &os; 5.5 RELENG_5_4_0_RELEASE &os; 5.4 RELENG_4_11_0_RELEASE &os; 4.11 RELENG_5_3_0_RELEASE &os; 5.3 RELENG_4_10_0_RELEASE &os; 4.10 RELENG_5_2_1_RELEASE &os; 5.2.1 RELENG_5_2_0_RELEASE &os; 5.2 RELENG_4_9_0_RELEASE &os; 4.9 RELENG_5_1_0_RELEASE &os; 5.1 RELENG_4_8_0_RELEASE &os; 4.8 RELENG_5_0_0_RELEASE &os; 5.0 RELENG_4_7_0_RELEASE &os; 4.7 RELENG_4_6_2_RELEASE &os; 4.6.2 RELENG_4_6_1_RELEASE &os; 4.6.1 RELENG_4_6_0_RELEASE &os; 4.6 RELENG_4_5_0_RELEASE &os; 4.5 RELENG_4_4_0_RELEASE &os; 4.4 RELENG_4_3_0_RELEASE &os; 4.3 RELENG_4_2_0_RELEASE &os; 4.2 RELENG_4_1_1_RELEASE &os; 4.1.1 RELENG_4_1_0_RELEASE &os; 4.1 RELENG_4_0_0_RELEASE &os; 4.0 RELENG_3_5_0_RELEASE &os; 3.5 RELENG_3_4_0_RELEASE &os; 3.4 RELENG_3_3_0_RELEASE &os; 3.3 RELENG_3_2_0_RELEASE &os; 3.2 RELENG_3_1_0_RELEASE &os; 3.1 RELENG_3_0_0_RELEASE &os; 3.0 RELENG_2_2_8_RELEASE &os; 2.2.8 RELENG_2_2_7_RELEASE &os; 2.2.7 RELENG_2_2_6_RELEASE &os; 2.2.6 RELENG_2_2_5_RELEASE &os; 2.2.5 RELENG_2_2_2_RELEASE &os; 2.2.2 RELENG_2_2_1_RELEASE &os; 2.2.1 RELENG_2_2_0_RELEASE &os; 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. &os;: a &os; FTP szerverének teljes tükrözése. Hollandia rsync://ftp.nl.FreeBSD.org/ Elérhetõ gyûjtemények: &os;: a &os; FTP szerverének teljes tükrözése. Oroszország rsync://ftp.mtu.ru Elérhetõ gyûjtemények: &os;: A &os; FTP szerver teljes tartalma. &os;-gnats: A GNATS hibanyilvántartó adatbázis. &os;-Archive: A &os; archívumait tároló FTP szerver tükrözése. Tajvan rsync://ftp.tw.FreeBSD.org/ rsync://ftp2.tw.FreeBSD.org/ rsync://ftp6.tw.FreeBSD.org/ Elérhetõ gyûjtemények: &os;: 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: &os;: 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: &os;: a &os; FTP szerver teljes tükrözése. diff --git a/hu_HU.ISO8859-2/share/sgml/trademarks.ent b/hu_HU.ISO8859-2/share/sgml/trademarks.ent index a178130b2a..135eef1223 100644 --- a/hu_HU.ISO8859-2/share/sgml/trademarks.ent +++ b/hu_HU.ISO8859-2/share/sgml/trademarks.ent @@ -1,436 +1,448 @@ A 3Com és HomeConnect a 3Com Corporation bejegyzett védjegyei."> 3Com"> A 3ware és Escalade a 3ware Inc. bejegyzett védjegyei."> 3ware"> Escalade"> A Adaptec az Adaptec, Inc. bejegyzett védjegye."> Adaptec"> Az Adobe, Acrobat, Acrobat Reader, és PostScript az Adobe Systems Incorporated bejegyzett védjegyei, vagy védjegyei az Egyesült Államokban és/vagy más országokban."> Acrobat"> Acrobat Reader"> Adobe"> PostScript"> Az AMD, Am486, Am5X86, AMD Athlon, AMD Duron, AMD Opteron, AMD-K6, Athlon, Élan, Opteron és PCnet az Advanced Micro Devices, Inc. védjegyei."> Am486"> Am5x86"> AMD Athlon"> AMD Duron"> AMD-K6"> AMD Opteron"> AMD Sempron"> AMD Turion"> Athlon"> Élan"> Opteron"> Az Apple, AirPort, FireWire, Mac, Macintosh, Mac OS, Quicktime, és TrueType az Apple Computer, Inc., bejegyzett védjegyei az Egyesült Államokban és más országokban."> AirPort"> Apple"> FireWire"> iMac"> Mac"> Macintosh"> Mac OS"> Quicktime"> TrueType"> Az ARM az ARM Limited bejegyzett védjegye."> ARM"> A Bluetooth világmárka a Bluetooth SIG, Inc. tulajdona."> Bluetooth"> A Broadcom a Broadcom Corporation és/vagy leányvállalatainak a bejegyzett védjegye."> Broadcom"> A Check Point, Firewall-1 és VPN-1 a Check Point Software Technologies Ltd. bejegyzett védjegyei."> A Cisco, Catalyst és IOS a Cisco Systems, Inc. és/vagy társvállalatainak bejegyzett védjegyei az Egyesült Államokban és néhány más országban."> Cisco"> Catalyst"> EtherChannel"> IOS"> A Corel és WordPerfect a Corel Corporation és/vagy leányvállalatainak bejegyzett védjegye Kanadában, az Egyesült Államokban és/vagy más országokban."> WordPerfect"> A Coverity bejegyzett védjegye, a Coverity Extend, Coverity Prevent és Coverity Prevent SQS pedig védjegyei a Coverity, Inc.-nek."> Coverity"> Coverity Prevent"> A Sound Blaster a Creative Technology Ltd. védjegye az Egyesült Államokban és/vagy más országokban."> SoundBlaster"> A CVSup John D. Polstra bejegyzett védjegye."> A Dell, Dell Precision, Latitude, Optiplex, PowerEdge a Dell Computer Corporation védjegyei, vagy bejegyzett védjegyei."> Dell"> PowerEdge"> Az EPSON és EPSON Perfection a Seiko Epson Corporation bejegyzett védjegyei."> EPSON"> EPSON Perfection"> A FreeBSD a FreeBSD Foundation bejegyzett védjegye."> + +Fujitsu, a Fujitsu logo, LifeBook, + Stylistic, PRIMEPOWER, PRIMEQUEST, PRIMECLUSTER, ETERNUS, TRIOLE, + ESPRIMO, BioMedCAChe, CAChe, CELLINJECTOR, isS, Materials Explorer, + SystemWalker és az Interstage a Fujitsu Limited + védjegyei vagy bejegyzett védjegyei az Egyesült + Államokban és egyéb országokban."> +Fujitsu"> +PRIMEPOWER"> + A Heidelberg, Helvetica, Palatino, és Times Roman a Heidelberger Druckmaschinen AG bejegyzett védjegyei, vagy védjegyei az Egyesült Államokban és más országokban."> Az IBM, AIX, EtherJet, Netfinity, OS/2, PowerPC, PS/2, S/390 és ThinkPad az International Business Machines Corporation védjegyei az Egyesült Államokban, más országokban, vagy mindkettõben."> AIX"> EtherJet"> Netfinity"> OS/2"> PowerPC"> PS/2"> S/390"> ThinkPad"> Az IEEE, POSIX és 802 az Institute of Electrical and Electronics Engineers, Inc. bejegyzett védjegyei az Egyesült Államokban."> IEEE"> POSIX"> Az Intel, Celeron, EtherExpress, i386, i486, Itanium, Pentium és Xeon az Intel Corporation vagy leányvállalatainak védjegyei vagy bejegyzett védjegyei az Egyesült Államokban és más országokban."> Celeron"> EtherExpress"> i386"> i486"> Intel"> Itanium"> Pentium"> Xeon"> Core"> Az Intuit és Quicken az Intuit Inc., vagy valamely leányvállalatának bejegyzett védjegyei és/vagy bejegyzett szervizmárkái az Egyesült Államokban és más országokban."> Az Iomega, Zip és Jaz az Iomega bejegyzett védjegyei vagy védjegyei az Egyesült Államokban és/vagy más országokban."> Zip"> Jaz"> A Lantronix és EasyIO a Lantronix Corporation védjegyei."> EasyIO"> A Linux Linus Torvalds bejegyzett védjegye."> Linux"> Az LSI Logic, AcceleRAID, eXtremeRAID, MegaRAID és Mylex az LSI Logic Corp. védjegyei vagy bejegyzett védjegyei."> AcceleRAID"> MegaRAID"> Mylex"> A Macromedia, Flash és Shockwave a Macromedia, Inc. védjegyei és/vagy bejegyzett védjegyei az Egyesült Államokban és/vagy más országokban."> Flash"> Macromedia"> Shockwave"> A Microsoft, IntelliMouse, MS-DOS, Outlook, Windows, Windows Media és Windows NT a Microsoft Corporation bejegyzett veacute;djegyei, vagy védjegyei az Egyesült Államokban és/vagy más országokban."> IntelliMouse"> Microsoft"> MS-DOS"> Outlook"> Windows"> Windows Media"> Windows NT"> A MIPS és R4000 a MIPS Technologies, Inc. bejegyzett védjegyei az Egyesült Államokban és más országokban."> MIPS"> A MySQL a MySQL AB bejegyzett védjegye az Egyesült Államokban, az Európai Unióban és más országokban."> MySQL"> Az M-Systems és DiskOnChip az M-Systems Flash Disk Pioneers, Ltd. védjegyei vagy bejegyzett védjegyei."> DiskOnChip"> A NetBSD a NetBSD Foundation bejegyzett védjegye."> A Netscape és a Netscape Navigator a Netscape Communications Corporation bejegyzett védjegyei az Egyesült Államokban és más országokban."> Netscape"> Netscape Navigator"> A GateD és NextHopa NextHop bejegyzett és nem bejegyzett védjegyei az Egyesült Államokban és más országokban."> GateD"> A NetWare, NetWare Loadable Module és NLM a Novell, Inc. bejegyzett védjegyei vagy védjegyei az Egyesült Államokban és más országokban."> A Motif, OSF/1 és UNIX a The Open Group bejegyzett védjegyei, az IT DialTone és a The Open Group pedig védjegyei az Egyesült államokban és/vagy más országokban."> A UNIX a The Open Group bejegyzett védjegye az Egyesült Államokban és más országokban."> Motif"> UNIX"> Az Oracle az Oracle Corporation bejegyzett védjegye."> Oracle"> A Parallels a Parallels Software International Inc. védjegye."> A PowerQuest és PartitionMagic a PowerQuest Corporation bejegyzett védjegyei az Egyesült Államokban és/vagy más országokban."> PartitionMagic"> A QUALCOMM és Eudora a QUALCOMM Incorporated bejegyzett védjegyei."> Eudora"> A RealNetworks, RealPlayer és RealAudio a RealNetworks, Inc. bejegyzett védjegyei."> RealPlayer"> A Red Hat és RPM a Red Hat, Inc. védjegyei vagy bejegyzett védjegyei az Egyesült Államokban és más országokban."> A SAP, R/3 és mySAP a SAP AG védjegyei vagy bejegyzett védjegyei Németországban é sok más országban is világszerte."> R/3"> SAP"> A Silicon Graphics, SGI és OpenGL a Silicon Graphics, Inc. bejegyzett védjegyei az Egyesült Államokban és/vagy más országokban világszerte."> OpenGL"> A Slackware Patrick Volkerding és a Slackware Linux, Inc. bejegyzett védjegye."> -A Sparc, Sparc64, SPARCEngine és - UltraSPARC a SPARC International, Inc védjegyei az Egyesült - államokban és más országokban. A SPARC - védjegyet hordozó termékek a Sun Microsystems, Inc. - által kifejlesztett architektúrára - épülnek."> -Sparc"> -Sparc64"> +A SPARC, SPARC64, SPARCEngine és + UltraSPARC a SPARC International, Inc védjegyei az + Egyesült államokban és más + országokban. A SPARC International, Inc birtokolja az + összes SPARC védjegyet és annak tagjai + között teszi azok megfelelõ használatát + elérhetõvé a licencelési megegyezések + alapján."> +SPARC"> +SPARC64"> SPARCEngine"> UltraSPARC"> A Sun, Sun Microsystems, Java, Java Virtual Machine, JavaServer Pages, JDK, JRE, JSP, JVM, Netra, OpenJDK, Solaris, StarOffice, Sun Blade, Sun Enterprise, Sun Fire, SunOS, Ultra és VirtualBox a Sun Microsystems, Inc. védjegyei vagy bejegyzett védjegyei az Egyesült Államokban és más országokban."> Java"> Java Virtual Machine"> JavaServer Pages"> JDK"> JRE"> JSP"> JVM"> Netra"> OpenJDK"> Solaris"> StarOffice"> Sun"> Sun Blade"> Sun Enterprise"> Sun Fire"> Ultra"> SunOS"> VirtualBox"> A Symantec és Ghost a Symantec Corporation bejegyzett védjegyei az Egyesült Államokban és más országokban."> A MATLAB a The MathWorks, Inc. bejegyzett védjegye."> MATLAB"> A SpeedTouch a Thomson védjegye."> SpeedTouch"> A Transmeta és Crusoe a Transmeta Corporation védjegyei vagy bejegyzett védjegyei az Egyesült Államokban és/vagy más országokban."> Crusoe"> Transmeta"> A U.S. Robotics és Sportster a U.S. Robotics Corporation. bejegyzett védjegyei."> Sportster"> U.S. Robotics"> A Waterloo Maple és Maple a Waterloo Maple Inc. védjegyei vagy bejegyzett védjegyei."> Maple"> A Mathematica a Wolfram Research, Inc. védjegye."> Mathematica"> A VMware a VMware, Inc. védjegye."> A Xen a XenSource, Inc. védjegye az Egyesült Államokban és más országokban."> Xen"> Az XFree86 az XFree86 Project, Inc. védjegye."> XFree86"> Az Ogg Vorbis és Xiph.Org a Xiph.Org védjegyei."> A gyártók és terjesztõk által használt megnevezések közül sok védjegy jogot követel. Ahol ilyen megnevezés tûnik fel ebben a dokumentumban, és a FreeBSD Projektnek tudomása volt a védjegyrõl, a megnevezést a ™ vagy a ® szimbólum követi.">