diff --git a/documentation/content/hu/articles/explaining-bsd/_index.adoc b/documentation/content/hu/articles/explaining-bsd/_index.adoc index f78b377133..b2cb04bc6e 100644 --- a/documentation/content/hu/articles/explaining-bsd/_index.adoc +++ b/documentation/content/hu/articles/explaining-bsd/_index.adoc @@ -1,169 +1,179 @@ --- title: A BSD bemutatása authors: - author: Greg Lehey email: grog@FreeBSD.org releaseinfo: "$FreeBSD$" trademarks: ["freebsd", "amd", "apple", "intel", "xfree86", "linux", "opengroup", "sparc", "sun", "unix", "general"] --- = A BSD bemutatása :doctype: article :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :source-highlighter: rouge :experimental: :toc-title: Tartalom :table-caption: Táblázat :figure-caption: Ábra :example-caption: Példa +ifeval::["{backend}" == "html5"] include::shared/authors.adoc[] +endif::[] + +ifeval::["{backend}" == "pdf"] +include::../../../../shared/authors.adoc[] +endif::[] + +ifeval::["{backend}" == "epub3"] +include::../../../../shared/authors.adoc[] +endif::[] [.abstract-title] Kivonat A nyílt forrású világban a "Linux(R)" szó majdnem az "operációs rendszer" szinonimájává vált, pedig nem ez az egyetlen nyílt forrású UNIX(R)-szerû operációs rendszer. Az http://www.leb.net/hzo/ioscount/data/r.9904.txt[Internet Operating System Counter] szerint 1999 áprilisában a világ hálózatra kapcsolt számítógépeinek 31,3%-a Linux(R)ot futtat. 14,6% használ BSD UNIX(R)-ot. A világ legnagyobb webes szolgáltatásai közül néhány, mint például a http://www.yahoo.com/[Yahoo!] is BSD-t használ. A világ legforgalmasabb FTP szervere 1999-ben (már halott), az link:ftp://ftp.cdrom.com/[ftp.cdrom.com], BSD-t használt a napi 1,4 TB adatforgalom biztosításához. Ez egyértelmûen nem egy szûk piaci réteg: a BSD egy jól megõrzött titok. Tehát mi is a titok? Miért nem ismert jobban a BSD? Ez a dokumentum többek között ezt a kérdést hivatott megvizsgálni. A dokumentumban a BSD és Linux(R) közötti különbségeket __így olvashatja__. _Fordította: `{gabor}`_ ''' toc::[] [[what-is-bsd]] == Mi az a BSD? A BSD "Berkeley Software Distribution" rövidítése, amely annak a disztribúciónak a neve, amit a berkeley-i egyetemen fejlesztettek ki Californiában az AT&T UNIX(R) operációs rendszerének a kiterjesztéseként. Számos nyílt forású operációs rendszer épül a 4.4BSD-Lite néven ismertté vált kiadásra. Ráadásul tartalmaznak több csomagot más nyílt forrású projektekbõl, különösen a GNU projektbõl. A teljes operációs rendszer a következõket tartalmazza: * A BSD kernel, amely a processzütemezést, illetve a memóriakezelést végzi, kezeli a szimmetrikus többprocesszoros rendszereket (SMP), az eszközmeghajtókat, stb. + __A Linux(R) kernellel ellentétben, BSD kernelbõl több van, különbözõ adottságokkal.__ * A C könyvtár, a rendszer alapvetõ API-ja. + __A BSD C könyvtár a Berkeley kódon alapszik, nem a GNU projekten.__ * Segédprogramok, mint shellek, fájlkezelõ eszközök, fordítók és linkerek. + __Néhány segédprogram a GNU projektbõl származik, mások nem.__ * Az X Window rendszer, amely a grafikus megjelenítést kezeli. + Az X Window rendszert, amelyet a legtöbb BSD rendszer használ, két különbözõ projekt fejleszti, az http://www.XFree86.org/[projekt] és az http://www.X.org/[X.Org projekt]. A Linux(R) is ezeket használja. A BSD általában nem jelöl ki egy "grafikus felületet", mint például a GNOME, vagy KDE, de ennek ellenére ezek is elérhetõek. * Sok egyéb program és segédeszköz. [[what-a-real-unix]] == Micsoda? Egy igazi UNIX(R)? A BSD operációs rendszerek nem klónok, hanem az AT&T's Research UNIX(R) operációs rendszer nyílt forráskódú leszármazottai, amely a modern UNIX(R) System V õse. Talán meglepõnek találja, hogy hogyan lehetséges ez, amikor az AT&T soha nem tette nyílt forrásúvá a kódját? Igaz, hogy az AT&T UNIX(R) nem nyílt forrású és jogi szempontból a BSD határozottan _nem_ UNIX(R), de az AT&T átvett kódot más projektekbõl is, különösen a kaliforniai Berkeley egyetemen mûködõ Computer Sciences Research Group (CSRG)-tól. 1976-tól a CSRG szalagokon kiadta a szoftverét, amelynek neve __Berkeley Software Distribution__, avagy _BSD_ volt. A BSD kezdeti kiadásai leginkább felhasználói programokból álltak, de a helyzet drámaian megváltozott, amint a CSRG szerzõdött az Advanced Research Projects Agency-vel (DARPA) a hálózataik ARPANET-re történõ aktualizálásával kapcsolatban. Az új protokollok, mint _Internet Protokollok_ voltak ismertek, késõbb mint __TCP/IP__, a protokollcsalád két legfontosabb protokollja után. A legelsõ szélesebb körben használt implementáció a 4.2BSD része volt, 1982-ben. Az 1980-as években számos új munkaállomásokkal foglalkozó cég tûnt fel. Sokuk a UNIX(R) licencelését részesítette elõnyben egy saját operációs rendszer fejlesztésével szemben. Különösen a Sun Microsystems licencelte a UNIX(R)-ot és megvalósította a 4.2BSD egy új verzióját, amelyet SunOS(TM)-nak nevezett. Amikor az AT&T jogosulttá vált arra, hogy maguk árusítsák a UNIX(R)-ot kereskedelmi forgalomban, a valamelyest mérföldkõnek számító System III rendszerüket hamarosan a System V követte. A System V kódja nem tartalmazott hálózatkezelést, így minden implementációjukhoz a BSD-bõl vettek át szoftvereket, ideértve a TCP/IP szoftvert és egyéb más programokat is, mint például a _csh_ shell és a _vi_ editor. Ezek az eszközök kollektívan a _Berkeley Extensions_ (berkeley-i kiegészítések) néven váltak ismertté. A BSD szalagok az AT&T tulajdonában lévõ kódot is tartalmaztak, így használatuk UNIX(R) source licencet igényelt. 1990-re a CSRG kifogyott a támogatásokból, így be kellett szüntetniük a munkát. A csoport néhány tagja úgy döntött, hogy kiadja a BSD kódját, amely nyílt forráskódú volt az AT&T kód nélkül. Ez végül a _Networking Tape 2_ kiadással valósult meg, amely általában mint _Net/2_ ismert. A Net/2 nem volt komplett operációs rendszer, a kernel kódjának kb. 20%-a hiányzott. A CSRG tagok egyike, William F. Jolitz megírta a hiányzó kódrészeket és 1992 elején kiadta a _386BSD_ rendszert. Ezzel egyidõben a volt CSRG tagok egy másik csoportja létrehozott egy kereskedelmi céget http://www.bsdi.com/[Berkeley Software Design Inc.] néven és kiadtak egy béta verziójú operációs rendszert, a http://www.bsdi.com/[BSD/386]-ot, amely ugyanarra a kódra épült. Az operációs rendszer neve késõbb BSD/OS-re változott. A 386BSD soha nem vált stabil rendszerré. Ehelyett két másik projekt nõtt ki belõle 1993-ban: a http://www.NetBSD.org/[NetBSD] és a link:https://www.FreeBSD.org/[FreeBSD]. A két projekt akkor vált szét, amikor a 386BSD fejlõdését várták: a NetBSD az év elején startolt, a FreeBSD elsõ kiadása pedig csak az év végére készült el. Eközben a kód eléggé más irányba fejlõdött ahhoz, hogy könnyen egyesíhessék azt. Ezen kívül a projektek küönbözõ célokat tûztek ki, ahogyan majd lentebb látni fogjuk. 1996-ban az http://www.OpenBSD.org/[OpenBSD] kivált a NetBSD-bõl, 2003-ban pedig a http://www.dragonflybsd.org/[DragonFlyBSD] a FreeBSD-bõl. [[why-is-bsd-not-better-known]] == Miért nem ismert jobban a BSD? Számos ok miatt, a BSD relatíve ismeretlen: . A BSD fejlesztõit gyakran jobban érdekli, hogy a kódot javítgassák, minthogy marketinget szervezzenek köré. . A Linux(R) ismertsége a projekten kívüli okoknak köszönhetõ, mint a sajtó vagy a cégek, amelyek linuxos szolgáltatásokat kínálnak. Ezidáig a nyílt forrású BSD-k nem rendelkeznek ilyen kiváltságokkal. . A BSD fejlesztõi gyakran több tapasztalattal rendelkeznek, mint a Linux(R) fejlesztõi, így kevésbé érdekeltek abban, hogy a rendszert könnyen használhatóvá tegyék. Az új felhasználók általában kényelmesebbnek találják a Linux(R)ot. . 1992-ben az AT&T beperelte a http://www.bsdi.com/[BSDI]-t, a BSD/386 terjesztõjét azzal az indokkal, hogy a termék az AT&T tulajdonában lévõ kódrészleteket tartalmaz. A bíróság 1994-ben lezárta az ügyet, de a per szelleme továbbra is kísérti az embereket. Mostanában, 2000 márciusában egy webes cikk is azt állította, hogy a bírósági ügy "nemrég fejezõdött be". + A név volt az egyik kérdés, amit a per tisztázott: az 1980-as években a BSD mint "BSD UNIX(R)" volt ismert. Az AT&T birtokolta kódok utolsó nyomainak eltávolításával a BSD elvesztette a UNIX(R) névhez való jogát. Ennek eredményeképp olyan hivatkozások olvashatók a könyvcímekben, mint "4.3BSD UNIX(R) operációs rendszer" és "4.4BSD operációs rendszer". . Egyes megfigyelések szerint a BSD projektek szétdarabolódtak és ellenségesek egymással. A http://interactive.wsj.com/bin/login?Tag=/&URI=/archive/retrieve.cgi%253Fid%253DSB952470579348918651.djm&[Wall Street Journal] a BSD projektek "balkánizációjáról" beszél. A perhez hasonlóan, ez is nagyrészt õsi történetekre épül. [[comparing-bsd-and-linux]] == A BSD és a Linux(R) összehasonlítása Tehát valójában mi is a különbség mondjuk a Debian Linux(R) és a FreeBSD közt? Az átlag felhasználó számára a különbség meglepõen csekély: mindkettõ UNIX(R)-szerû operációs rendszer. Mindkettõt non-profit projektek fejlesztik. (Természetesen ez nem igaz sok más Linux(R) disztribúcióra.) A következõ fejezetben a BSD és a Linux(R) közötti különbségeket tekintjük át. A leírás leginkább a FreeBSD-re illik, amely a BSD telepítések kb. 80%-át teszi ki, de a NetBSD, OpenBSD és DragonflyBSD nem sokban különbözik tõle. === Kinek a birtokában van a BSD? A BSD nem egy személy vagy egy vállalat tulajdona. Egy magasan képzett és elkötelezett közösség fejleszti és terjeszti világszerte. A BSD néhány összetevõje különálló nyílt forrású projekt, amelyet más fejlesztõk tartanak karban. === Hogyan fejlesztik és aktualizálják a BSD-t? A BSD kerneleket a nyílt forrású fejlesztési modell szerint fejlesztik és tartják naprakészen. Mind a négy projekt fenntart egy publikusan elérheõ _forrásfát_ a http://www.cvshome.org/[Concurrent Versions System] (CVS) verziókezelõ rendszer segítségével, amely a projekt minden forrásfájlját tartalmazza a dokumentációval és egyéb fontos fájlokkal együtt. A CVS segítségével a felhasználók lekérhetik ("check out") a rendszer bármely óhajtott verzióját. Világszerte sok fejlesztõ járul hozzá a BSD fejlõdéséhez. Három kategóriába soroljuk õket: * A _contributor-ok_ ("külsõ munkatársak") kódot vagy dokumentációt írnak. Nincs jogosultságuk a forráskódban közvetlenül változtatásokat végrehajtani. Ahhoz, hogy a munkájuk bekerüjön a rendszerbe, egy hivatalos fejlesztõnek - _committernek_ - kell azt átnéznie és a kódbázishoz adnia. * A _Committerek_ azok a fejlesztõk, akiknek írási jogosultságuk van a forráskódhoz. Ahhoz, hogy valaki committerré váljon, be kell bizonyítania, hogy megfelelõ tudással rendelkezik azon a területen, amelyen dolgozik. + A committer egyéni döntése, hogy él-e a felhatalmazásával, mielõtt változtatást hajt végre a forráskódon. Általában, egy tapasztalt committer végrehajthat olyan változtatásokat, amelyek nyilvánvalóan helyesek, anélkül, hogy ehhez más beleegyezését kérné. Példál egy dokumentáción dolgozó committer kijavíthat helyesírási, vagy nyelvtani hibákat, anélkül, hogy azt más megvizsgálná. Másrészt, azoktól a fejlesztõktõl, akik messzemenõ vagy összetett változtatásokon dolgoznak, elvárt, hogy átnézésre közzétegyék a kódot a tényleges változtatások elõtt. Extrém esetekben a core team egy tagja, mint elöljáró tervezõ, elrendelheti a változtatások törlését a forráskódból, azon a folyamaton keresztül, amelynek neve _backing out_. Minden committer kap értesítést minden változásról, így nem lehet titokban változtatásokat eszközölni. * A _Core team_ ("projektvezetõk"). A FreeBSD és a NetBSD is rendelkezik egy core csapattal, amely a projektet menedzseli. A core csapatok a projekt elõremenetele során alakultak ki, és a szerepük nem mindig pontosan meghatározott. Nem szükséges fejlesztõnek lenni ahhoz, hogy valaki a core csapat tagja legyen, habár ez a megszokott. A core csapat feladata egyik projektrõl a másikra változik, de általában több beleszólásuk van a projekt menetébe, mint a nem core tagoknak. Ez a rendszer számos pontban eltér a Linux(R)étól: . Nem egyetlen ember irányítja a rendszert. A gyakorlatban ez az eltérés túlértékelt, hiszen az elöljáró tervezõ kérheti a kód visszaállítását és még a Linux(R) projektben is több embernek van jogosultsága változtatni. . Másrészt, _van_ egy központi repository, azaz a teljes operációs rendszer forráskódja egy helyen érhetõ el, beleértve a régi verziókat is. . A BSD projektek az egész "operációs rendszert" karbantartják, nemcsak a kernelt. Ez a megkülönböztetés csak részben hasznos: a BSD és a Linux(R) is haszontalan alkalmazások nélkül. A BSD alatt használt alkalmazások gyakran azonosak a Linux(R)on használtakkal. . A központilag karbantartott CVS forrásfának köszönhetõen a BSD fejlesztése áttekinthetõ, továbbá lehetõség van arra, hogy bármely verziót elérjünk a kiadási verzió vagy a dátum alapján. A CVS segítségével növekményesen is frissíthetjük rendszerünket: például a FreeBSD repositoryja kb. 100 alkalommal frissül naponta. Ezek közül a változások közül a legtöbb kicsi. === A BSD kiadások A FreeBSD, NetBSD és OpenBSD háromféle "kiadáson" keresztül teszi elérhetõvé a rendszert. Ahogyan a Linux(R) esetében is, a kiadások kapnak egy verziószámot, mint pl. 1.4.1 vagy 3.5. Továbbá, a verziószám rendelkezik egy utótaggal, amelyik a kiadás célját jelöli: . A rendszer fejlesztõi verziójának neve _CURRENT_. A FreeBSD egy számot rendel ehhez, pl. 5.0-CURRENT. A NetBSD egy kicsit más elnevezési konvenciót alkalmaz, egy egybetûs utótagot fûz a névhez, amely azt jelzi, hogy csak a belsõ interfészeket érinti a változás, ilyen pl. a NetBSD 1.4.3G. Az OpenBSD nem használ számokat ("OpenBSD-current"). Minden új fejlesztés elõször ebbe az ágba kerül bele. . Meghatározott idõnként, 2-4 alkalommal évente, a projekt kiad egy _RELEASE_ (kiadás) verziót, amely elérhetõ CD-ROM-on és szabadon letölthetõ az FTP szerverekrõl, ilyen pl. az OpenBSD 2.6-RELEASE vagy a NetBSD 1.4-RELEASE. A RELEASE verzió végfelhasználók számára készül és ez a rendszer normális verziója. A NetBSD ezen kívül _patch release_ kiadásokat is kínál egy harmadik számjeggyel, pl. NetBSD 1.4.2. . Ahogy hibák bukkannak fel a RELEASE verzióban és javításra kerülnek, a javítások bekerülnek a CVS fába. Az így létrejövõ verzió neve a FreeBSD-nél _STABLE_, de a NetBSD és az OpenBSD továbra is RELEASE néven hívja ezt a verziót. Kisebb új funkciók szintén bekerülhetnek ebbe az elágazásba, miután a CURRENT ágban már egy ideje stabilnak bizonyultak. __Ezzel ellentében a Linux(R) két különbözõ forrásfát tart fenn: a stabil- és a fejlesztõi verziót. A stabil verzióknak egy páros minor számuk van, mint pl. 2.0, 2.2 vagy 2.4. A fejlesztõi verziók minor száma páratlan, mint pl. 2.1, 2.3 vagy 2.5. Ezt a verziószámot minden esetben egy harmadik szám követi, ez adja meg a pontos verziót. Ezen kívül, minden terjesztõ saját programokat és segédeszközöket mellékel, így a disztribúció neve is meghatározó. Minden disztribútor külön verziószámmal látja el a disztribúciót is, tehát egy teljes meghatározás valahogy így hangzana: "TurboLinux 6.0 2.2.14-es kernellel"__. === Milyen BSD verziók vannak? A rengeteg Linux(R) disztribúcióval ellentétben csak négy jelentõsebb nyílt forrású BSD van. Minden BSD projekt karbantartja a saját forrásfáját és saját kernelét. A gyakorlatban azonban kevesebb az eltérés a userland kódokban, mint a Linux(R) esetében. Nehéz kategorizálni a projektek céljait, mert a különbségek nagyon szubjektívak. Alapvetõen a következõek érvényesek: * A FreeBSD a nagy teljesítményt és a könnyû használhatóságot célozza meg, a webszolgáltatók kedvence. Számos platformon fut, ide értve az i386(TM) alapú rendszereket ("PC-ket"), az AMD 64-bites processzorait, az UltraSPARC(R) rendszereket, a Compaq Alpha rendszereit, illetve a NEC PC-98 specifikációján alapuló rendszereket. A FreeBSD Projekt jelentõsen több felhasználóval rendelkezik, mint más projektek. * A NetBSD a lehetõ legnagyobb hordozhatóságra törekszik, ahogyan az idézet is mutatja: "of course it runs NetBSD". Elfut a palmtopokon és a nagy szervereken egyaránt, és a NASA is használja az ûrkutatásai során. Különösen jó választás régi, nem Intel(R) alapú hardverhez. * Az OpenBSD a biztonságra és a kód egyszerûségére koncentrál: a nyílt forrású koncepciót kombinálják a szigorú ellenõrzésekkel, hogy így egy bizonyítottan korrekt rendszert hozzanak létre, megoldást kínálva ezzel a biztonságot megkövetelõ szervezeteknek, mint például bankoknak, tõzsdéknek és amerikai kormányügyi szervezeteknek. Ahogyan a NetBSD, az OpenBSD is több platformon fut. * A DragonFlyBSD a nagy teljesítményt és a skálázhatóságot célozza meg az egyszerû UP rendszerektõl kezdve a hatalmas, fürtözött rendszerekig. Számos hosszútávú technikai célja van, de a legfontosabb, hogy egy olyan SMP-képes infrastruktúrát hozzon létre, amely könnyen érthetõ és karbantartható, valamint könnyû rá fejleszteni. Létezik még két másik BSD UNIX(R), amelyek azonban nem nyílt forrásúak: a BSD/OS és az Apple Mac OS(R) X: * A BSD/OS volt a legrégebbi leszármazottja a 4.4BSD-nek. Nem volt ugyan nyílt forrású, de viszonylag alacsony áron lehetett licencet vásárolni a forráskódhoz. Sok tekintetben hasonlított a FreeBSD-hez. Két évvel azután, hogy a Wind River Systems megvette a BSDi-t, a BSD/OS, mint önálló termék megszûnt létezni. Támogatás és a forráskód még mindig elérhetõ a Wind Rivernél, de az új fejlesztések már a VxWorks beágyazott operációs rendszerre irányulnak. * A http://www.apple.com/macosx/server/[Mac OS(R) X] az http://www.apple.com/[Apple Computer Inc.] operációs rendszerének legújabb verziója a Macintosh(R) termékvonalhoz. Ennek a rendszernek a BSD magja, a http://developer.apple.com/darwin/[Darwin] egy teljes értékû nyílt forrású operációs rendszerként érhetõ el x86 és PPC számítógépekhez. Az Aqua/Quartz grafikus rendszer és a Mac OS(R) X pár egyéb saját fejlesztése zárt forrású maradt. Számos Darwin fejlesztõ egyben FreeBSD committer is, és fordítva. === Hogyan tér el a BSD licenc a GNU General Public licenctõl? A Linux(R) a http://www.fsf.org/copyleft/gpl.html[GNU General Public Licenc] (GPL) alatt érhetõ el, amely azért jött létre, hogy felszámolja a zárt forráskódú szoftverfejlesztést. Konkrétan, minden olyan munkának, amely GPL licenc alatt kiadott termékre épül, szintén nyílt forrásúnak kell lennie. Ezzel szemben a http://www.opensource.org/licenses/bsd-license.html[BSD licenc] kevésbé korlátozó: tisztán bináris terjesztést is megenged. Ez különösen vonzó a beágyazott alkalmazások számára. === Mi mást kell még tudnom? Mivel a BSD-hez kevesebb alkalmazás érhetõ el, mint a Linux(R)hoz, ezért a BSD fejlesztõi készítettek egy Linux(R) kompatibilitási csomagot, amellyel Linux(R) programok futtathatók BSD rendszeren. A csomag egyaránt tartalmaz kernel módosításokat a Linux(R) rendszerhívások megfelelõ végrehajtásához, és kompatibilitási fájlokat, mint például a C könyvtár. A BSD rendszeren futtatott Linux(R) alkalmazások és a natív Linux(R) környezetben futó Linux(R) alkalmazások között nincs észrevehetõ sebességkülönbség. A BSD "mindent együtt" természetének köszönhetõen a frissítések sokszor sokkal könnyebben kezelhetõek, mint a Linux(R) esetében. A BSD úgy kezeli a könyvtárak verzióit, hogy kompatibilitási modulokat bizosít a régebbi könyvtárakhoz, így több éves programok is probléma nélkül futtathatóak. === Melyiket használjam, a BSD-t, vagy a Linux(R)ot? Mit jelent mindez a gyakorlatban? Kinek való a BSD és kinek a Linux(R)? Ezt a kérdést nagyon nehéz megválaszoli. Pár irányelv: * "Ha nem romlott el, ne javítsd meg": Ha már egy olyan nyílt forrású operációs rendszert használ, amellyel elégedett, várhatóan nincs semmi nyomós oka, hogy váltson. * A BSD rendszerek, különösen a FreeBSD jelentõsen nagyobb teljesítményt produkálhatnak, mint a Linux(R). Ez azonban nem mindenkire érvényes. Sok esetben kicsi a különbség, vagy egyáltalán nincs különbség a teljesítményben. Néhány esetben pedig a Linux(R) teljesít jobban a FreeBSD-nél. * Általában a BSD rendszerek nagyobb tiszteletnek örvendenek a megbízhatóság terén, amely leginkább a kiforrottabb kód eredménye. * A BSD projektek nagyobb tiszteletnek örvendenek a minõségi és átfogó dokumentációjukért. A különbözõ dokumentációs projektek célja, hogy jól karbantartott dokumentációt biztosítsanak sok nyelven és a rendszer minden területét tárgyalják. * A BSD licenc vonzóbb lehet, mint a GPL. * A BSD a legtöbb Linux(R) programot képes futtatni, amíg a Linux(R) nem képes BSD programokat futtatni. Ezenkívül sok BSD implementáció más UNIX(R)-szerû operációs rendszerek programjait is képes futtatni, így a BSD rendszerekre könnyebb migrálni más rendszereket, mint a Linux(R)ra. === Ki kínál terméktámogatást és tréninget a BSD-hez? A BSDi / http://www.freebsdmall.com[FreeBSD Mall, Inc.] közel egy évtizede kínál terméktámogatási szerzõdéseket a FreeBSD-hez. Ezen kívül minden projekt rendelkezik egy listával a konzultánsairól: link:https://www.FreeBSD.org/commercial/consult_bycat/[FreeBSD], http://www.netbsd.org/gallery/consultants.html[NetBSD], és http://www.openbsd.org/support.html[OpenBSD]. diff --git a/documentation/content/hu/articles/gjournal-desktop/_index.adoc b/documentation/content/hu/articles/gjournal-desktop/_index.adoc index 2f116389a0..aade9b35ca 100644 --- a/documentation/content/hu/articles/gjournal-desktop/_index.adoc +++ b/documentation/content/hu/articles/gjournal-desktop/_index.adoc @@ -1,436 +1,442 @@ --- title: Naplózó UFS használata asztali számítógépeken authors: - author: Manolis Kiagias email: manolis@FreeBSD.org - author: Kiagias releaseinfo: "$FreeBSD$" trademarks: ["freebsd", "general"] --- = Naplózó UFS használata asztali számítógépeken :doctype: article :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :source-highlighter: rouge :experimental: :toc-title: Tartalom :table-caption: Táblázat :figure-caption: Ábra :example-caption: Példa ifeval::["{backend}" == "html5"] +include::shared/authors.adoc[] +include::shared/hu/mailing-lists.adoc[] +include::shared/hu/urls.adoc[] :imagesdir: ../../../images/articles/gjournal-desktop/ endif::[] ifeval::["{backend}" == "pdf"] +include::../../../../shared/authors.adoc[] +include::../../../../shared/hu/mailing-lists.adoc[] +include::../../../../shared/hu/urls.adoc[] :imagesdir: ../../../../static/images/articles/gjournal-desktop/ endif::[] ifeval::["{backend}" == "epub3"] +include::../../../../shared/authors.adoc[] +include::../../../../shared/hu/mailing-lists.adoc[] +include::../../../../shared/hu/urls.adoc[] :imagesdir: ../../../../static/images/articles/gjournal-desktop/ endif::[] -include::shared/authors.adoc[] -include::shared/hu/mailing-lists.adoc[] -include::shared/hu/urls.adoc[] [.abstract-title] Kivonat A naplózó állományrendszerek egy napló segítségével rögzítik az összes bennük lezajlott tranzakciót, ezzel igyekszenek megõrizni egy rendszeromlást vagy áramkimaradást követõen a rajtuk tárolt adatok épségét. Noha még így is elõfordulhat, hogy elveszítjük az adott pillanatban el nem mentett változtatásainkat, a naplózás viszont az állományrendszer számára tökéletes védelmet nyújt a rendszer szabálytalan leállása során keletkezõ sérülések ellen. Alkalmazása továbbá jelentõs mértékben lerövidíti a helyreállításhoz szükséges ellenõrzés idejét. A FreeBSD alaprendszerben megtalálható UFS állományrendszer önmagában nem tartalmaz naplózást, azonban a FreeBSD 7._X_ változataiban már megjelent egy olyan GEOM-osztály, amellyel az állományrendszertõl független módon ezt meg tudjuk valósítani. Ebben a cikkben bemutatjuk miként alakítsunk ki UFS alapú naplózást egy hétköznapi asztali számítógépen. _Fordította: Páli Gábor, utolsó ellenõrzés: 2010.11.28._ ''' toc::[] [[introduction]] == Bevezetés Míg az ipari szervereket általában alaposan felkészítik az esetlegesen bekövetkezõ váratlan leállásokra, addig egy átlagos asztali számítógép teljesen kiszolgáltatott az áramkimaradások, a véletlen újraindítások és minden más olyan beavatkozás számára, amelyek a rendszer nem szabályos leállását eredményezik. A Soft Updates ilyen helyzetekben általában hatékonyan védelmezi az állományrendszert, ez azonban a legtöbb esetben egy hosszadalmasabb háttérbeli ellenõrzést von maga után. Nagyon ritkán viszont az állományrendszer olyan mértékben károsodik, hogy a helyreállításához már felhasználói beavatkozás szükségeltetik és gyakran adatvesztéssel is jár. A GEOM alrendszerhez nemrég hozzáadott új naplózási képesség az ilyen szituációkban remekül alkalmazható, és ennek köszönhetõen szinte egyáltalán nem igényel idõt a sérült állományrendszer ellenõrzése, illetve gondoskodik a legutolsó stabil állapot villámgyors visszaállításáról. Ebben a cikkben bemutatunk egy eljárást, amely segítségével UFS állományrendszerekhez tudunk naplózást beállítani hagyományos asztali számítógépeken (feltételezzük, hogy az operációs rendszer és az adatok egyetlen merevlemezen helyezkednek el). A folyamatot a FreeBSD telepítésén keresztül ismertetjük, és olyan lépesekre bontottuk, hogy lehetõleg kerüljük a bonyolultabb parancssori mûveleteket. A cikk elolvasása során megismerjük: * a FreeBSD telepítése során hogyan hagyjunk helyet a napló számára; * hogyan töltsük be és engedélyezzük a `geom_journal` modult (vagy építsük be egy saját rendszermagba); * hogyan alakítsuk át a már meglevõ állományrendszereinket naplózóvá, az [.filename]#/etc/fstab# állományban milyen beállításokat kell megadnunk a csatlakoztatásukhoz; * hogyan állítsuk be a naplózást új (üres) partíciókon; * hogyan oldjuk meg a naplózással kapcsolatban leggyakrabban jelentkezõ problémákat. A cikk elolvasásához ajánlott: * a UNIX(R) és a FreeBSD alapvetõ fogalmainak ismerete; * a FreeBSD telepítés menetének és a Sysinstall alkalmazás ismerete. [WARNING] ==== Az itt megadott eljárás alapvetõen egy új rendszer telepítésének esetére vonatkozik, ahol még semmilyen felhasználói adatot nem tárolunk a lemezen. Természetesen ez a módszer átültethetõ mûködõ, éles rendszerekre is, azonban ilyenkor mindig készítsünk _biztonsági mentést_ mielõtt nekikezdenénk. Ugyanis amikor ilyen alacsony szinten dolgozunk lemezekkel és partíciókkal, bármilyen hiba könnyedén végzetesnek bizonyulhat az adatainkra nézve. ==== [[understanding-journaling]] == Naplózás FreeBSD alatt A FreeBSD 7._X_ változataiban a GEOM részérõl felkínált naplózási lehetõség (eltérõen például a Linux(R) típusú rendszerekben található ext3 állományrendszertõl) nem kötõdik konkrét állományrendszerhez, de blokkok szintjén üzemel. Habár ez arra utal, hogy különbözõ állományrendszerek esetén is használható, a FreeBSD 7.0-RELEASE kiadásában még csak az UFS2 felett mûködik. Ezt a funkciót a [.filename]#geom_journal.ko# modul betöltésével (vagy rendszermagba építésével) tudjuk aktiválni, majd a `gjournal` paranccsal érjük el az állományrendszerek konfigurációjához szükséges felületet. Általában nagyobb állományrendszereken, például a [.filename]#/usr# partíción érdemes engedélyezni a naplózást. Nem szabad elfelejtenünk, hogy ehhez azonban fenn kell tartanunk némi szabad területet a lemezen (errõl a következõ szakaszban lesz szó). Amikor egy állományrendszeren bekapcsoljuk a naplózást, magát a naplót is tárolnunk kell valahol a lemezen. A tényleges adatokat tároló lemezterületet __adatterületnek__, míg a naplót tároló területet pedig _naplóterületnek_ nevezzük. Ha egy meglevõ (nem üres) partícióhoz akarunk naplózást társítani, akkor az adat- és naplóterületeknek külön partíciókon kell lenniük. Amikor viszont egy teljesen új partícióhoz kapcsolunk naplózást, lehetõségünk van egyetlen területen tárolni az adatokat és a naplót. Bármelyik esettel is van dolgunk, a `gjournal` parancs a naplózó állományrendszer véglegesített változatát ezen két fajta terület egyesítésébõl hozza létre. Például: * A [.filename]#/dev/ad0s1f# eszközön található [.filename]#/usr# állományrendszeren szeretnénk naplózást használni (amely már eleve tartalmaz hasznos adatokat). * A partíciók létrehozása során a [.filename]#/dev/ad0s1g# eszközön lefoglaltunk valamennyi helyet. * A `gjournal` parancs segítségével készítünk egy [.filename]#/dev/ad0s1f.journal# eszközt, ahol a [.filename]#/dev/ad0s1f# eszközön tároljuk az adatokat és a [.filename]#/dev/ad0s1g# eszközön a naplót. A továbbiakban ezt az új eszközt fogjuk használni. A napló számára fenntartott hely mennyisége nem az adatok méretétõl, hanem az állományrendszer terheltségétõl függ. Például egy átlagos irodai számítógép esetén a [.filename]#/usr# állományrendszerhez nagyjából egy 1 GB méretû naplózási terület remekül megfelel, viszont egy terheltebb rendszer (amellyel például videoanyagok vágását végezzük) számára ennél több kellhet. A naplóterület idõ elõtti kimerülése a rendszermag összeomlásával jár. [NOTE] ==== A cikkben javasolt méretek használatával nagyon valószínûtlen, hogy hétköznapi feladataink (böngészés az interneten, szövegszerkesztés, különbözõ multimédia anyagok lejátszása) közben bármilyen problémát észlelnénk. Ha viszont a lemezünk tartósabb terhelés alatt van, a következõ szabály betartásával érhetjük el a legjobb eredményt: a számítógépünkben levõ központi memória teljes tartalmának mindig el kell tudnia férni a naplóterület egyharmadán. Tehát például ha a rendszerünk 1 GB memóriával rendelkezik, akkor egy közel 3,3 GB méretû naplóterület ajánlott. (Általánosan: Úgy kapjuk meg a naplóterület méretét, ha megszorozzuk a memória méretet 3,3-mal.) ==== A naplózásról részleteiben a man:gjournal[8] man oldalon olvashatunk. [[reserve-space]] == A FreeBSD telepítése során elvégzendõ lépések === Lemezterület lefoglalása a naplónak Az asztali számítógépekben többnyire csupán egyetlen merevlemez található, amelyen maga az operációs rendszer és az adatok helyezkednek el. A Sysinstall által felajánlott alapértelmezett partícionálási séma alkalmassága vitatható: egy asztali gép esetén például nincs szükségünk akkora [.filename]#/var# partícióra, viszont a [.filename]#/usr# foglalja el a merevlemez legnagyobb részét, hiszen a felhasználók adatai és a rendszerre telepített csomagok ide fognak kerülni. Az alapértelmezés szerinti felosztás (amely a Disklabel partíciószerkesztõben az kbd:[A] billentyûvel érhetõ el) nem hagy semennyi lemezterületet szabadon. Ahány partíciót naplózással akarunk ellátni, annyi további partícióra lesz szükségünk a naplókhoz. Mivel a [.filename]#/usr# lesz közülük a legnagyobb, próbáljuk meg ezen partíció méretének csökkentésével helyet csinálni a naplónak. A példában most egy 80 GB méretû lemezt láthatunk. Az ábrán most a telepítés közben a Disklabel szerint alapértelmezetten kiosztott partíciókat láthatjuk: image::disklabel1.png[] Amennyiben ez körülbelül megfelelõ a számunkra, akkor innen már nagyon egyszerû elõkészíteni a napló helyét. A nyilak használatával válasszuk ki a [.filename]#/usr# partíciót és a kbd:[D] billentyû lenyomásával töröljük le. Ezután válasszuk ki a képernyõ felsõ részében a lemez nevét, majd a kbd:[C] billentyû lenyomásával hozzunk létre egy új partíciót a [.filename]#/usr# számára. Ez viszont legyen most 1 GB-tal (ha napló csak a [.filename]#/usr# mellé lesz) vagy 2 GB-tal (ha egyaránt naplózni akarjuk a [.filename]#/usr# és [.filename]#/var# partíciókat is) kisebb. A felbukkanó ablakban válasszuk az állományrendszer létrehozását és a [.filename]#/usr# könyvtárat adjuk meg csatlakozási pontként. [NOTE] ==== Szükségünk van-e naplóra a [.filename]#/var# partícióhoz? A naplózásnak alapvetõen csak óriási méretû partíciók esetében van értelme. Ennek megfelelõen nem kell feltétlenül engedélyeznünk a naplózást a [.filename]#/var# partíción is, habár egy asztali gép esetében ez sosem árthat. Ha ezt az állományrendszert alig használjuk (ami nagyon valószínû egy asztali gépnél), kevesebb területet is rendelhetünk a naplóhoz. A példánkban a [.filename]#/usr# és [.filename]#/var# partíciókhoz is kapcsoltunk naplókat. Természetesen a módszer ezen lépése igény szerint megváltoztatható. ==== Mivel továbbra sem szeretnénk elbonyolítani a lépéseket, ezért a naplózás bevezetéséhez szükséges partíciók létrehozását szintén a Sysinstall segítésével végezzük. A telepítés közben a Sysinstall feltétlenül ragaszkodik ahhoz, hogy minden létrehozott partícióhoz csatlakozási pontot is megadjunk. A naplókat tároló partíciókhoz viszont ilyen nem tartozik, sõt, __egyáltalán nem is kell__. Ezek ugyanis nem olyan hétköznapi partíciók, amelyeket bármikor is csatlakoztatni fogunk. A Sysinstall használata során ezt a problémát úgy tudjuk elkerülni, ha a naplózásnak szánt partíciókat lapozóterületként adjuk meg. A lapozóterületet sem kell soha csatlakoztatni, és a Sysinstall ezekbõl tetszõleges mennyiségût képes készíteni. A telepítést követõ újraindítás után természetesen majd át kell szerkesztenünk az [.filename]#/etc/fstab# állományban az így létrehozott partíciók jellemzõit. Lapozóterület kialakításához ismét a nyílbillentyûk használatával navigáljunk a Disklabel alkalmazáshoz tartozó képernyõ felsõ részébe és válasszuk ki a lemez nevét. Ezután nyomjuk le az kbd:[N] billentyût, majd adjuk meg a kívánt méretet (_1024M_) és a következõ menübõl válasszuk a "swap space" (lapozóterület) típust. Ismételjük meg az iménti mûveletet az összes napló esetén. A példánkban ezen a módon készítettünk egy naplót a [.filename]#/usr#, és még egyet a [.filename]#/var# állományrendszer számára. A végeredmény a következõ képen látható: image::disklabel2.png[] Javasoljuk, ahogy befejeztük a partíciók létrehozását, jegyezzük fel a neveiket és a hozzá tartozó csatlakozási pontokat, így a soron következõ konfigurációs lépésekben könnyebben tudunk majd velük dolgozni. Ez egyben segít mérsékelni a telepítést károsító hibák elkövetésének esélyét. A következõ táblázatban a példában említett konfigurációhoz vettük fel ezeket az adatokat: .Partíciók és naplók [cols="1,1,1", options="header"] |=== | Partíció | Csatlakozási pont | Napló |ad0s1d |/var |ad0s1h |ad0s1f |/usr |ad0s1g |=== Ezután a megszokott módon folytassuk a telepítést. Javasoljuk azonban, hogy a külsõ alkalmazásokat (csomagokat) addig még ne tegyünk fel a rendszerünkre, amíg teljesen be nem fejeztük a naplózás beállítását. [[first-boot]] === A rendszer elsõ indítása A rendszerünk a szokásos módon fog indulni, de a naplók számára hozzáadott plusz lapozóterületekhez tartozó bejegyzéseket el kell távolítanunk az [.filename]#/etc/fstab# állományból. A lapozóterületek közül ténylegesen lapozásra általában a "b" (tehát a példánkban az [.filename]#ad0s1b#) partíciót érdemes meghagyni. Az összes többit egyszerûen töröljük ki, indítsuk újra a rendszerünket és a FreeBSD már nem fogja tovább használni ezeket. Ahogy a rendszer újra elindul, készen is állunk a naplózás beállítására. [[configure-journal]] == A naplózás beállítása [[running-gjournal]] === A `gjournal` futtatása A naplózást nagyon könnyû lesz beállítani miután már elõkészítettük az ehhez szükséges partíciókat. Váltsunk át egyfelhasználós módba, tehát jelentkezzünk be `root` felhasználóként és gépeljük be: [source,shell] .... # shutdown now .... Ezután az kbd:[Enter] billentyû lenyomásával megkapjuk az alapértelmezett parancsértelmezõt. Válasszuk le azokat a partíciókat, amelyeken engedélyezni kívánjuk a naplózást. Ezek a példánkban a [.filename]#/usr# és [.filename]#/var# partíciók voltak: [source,shell] .... # umount /usr /var .... Töltsük be a naplózáshoz szükséges modult: [source,shell] .... # gjournal load .... Most pedig a korábbi feljegyzéseink alapján állapítsuk meg melyik naplóhoz melyik partíciót fogjuk rendelni. A példánkban a [.filename]#/usr# csatlakozási ponthoz az [.filename]#ad0s1f# eszköz tartozik, és ennek a naplója az [.filename]#ad0s1g# eszköz lesz, miközben a [.filename]#/var# ponthoz az [.filename]#ad0s1d# eszközt rendeltük, és ezt az [.filename]#ad0s1h# eszközön naplózzuk. Ennek megfelelõen a következõ parancsokat kell kiadnunk: [source,shell] .... # gjournal label ad0s1f ad0s1g GEOM_JOURNAL: Journal 2948326772: ad0s1f contains data. GEOM_JOURNAL: Journal 2948326772: ad0s1g contains journal. # gjournal label ad0s1d ad0s1h GEOM_JOURNAL: Journal 3193218002: ad0s1d contains data. GEOM_JOURNAL: Journal 3193218002: ad0s1h contains journal. .... [NOTE] ==== A `gjournal` hibát fog jelezni, ha bármelyik partíció utolsó szektora már használatban van. Ilyen helyzetekben az `-F` kapcsoló segítségével felülírásra tudjuk kényszeríteni a parancsot, mint például: [source,shell] .... # gjournal label -f ad0s1d ad0s1h .... Mivel most telepítettük a rendszerünket, elég kicsi a valószínûsége, hogy így bármit is ténylegesen felülírnánk. ==== Létrejött két új eszköz, név szerint az [.filename]#ad0s1d.journal# és az [.filename]#ad0s1f.journal#. Ezek képviselik azokat a [.filename]#/var# és [.filename]#/usr# partíciókat, amelyeket valójában csatlakoztatnunk kell. A csatlakoztatásuk elõtt azonban állítsuk be hozzájuk a naplózást és tiltsuk le a Soft Updates használatát: [source,shell] .... # tunefs -J enable -n disable ad0s1d.journal tunefs: gjournal set tunefs: soft updates cleared # tunefs -J enable -n disable ad0s1f.journal tunefs: gjournal set tunefs: soft updates cleared .... Ezt követõen parancssorból csatlakoztassuk az új eszközöket a nekik megfelelõ pontokra (itt most már használhatjuk az `async` beállítást): [source,shell] .... # mount -o async /dev/ad0s1d.journal /var # mount -o async /dev/ad0s1f.journal /usr .... Nyissuk meg az [.filename]#/etc/fstab# állományt, és az elõbbiek szerint javítsuk ki a [.filename]#/usr# és a [.filename]#/var# állományrendszerekhez tartozó bejegyzéseket: [.programlisting] .... /dev/ad0s1f.journal /usr ufs rw,async 2 2 /dev/ad0s1d.journal /var ufs rw,async 2 2 .... [WARNING] ==== Figyelmesen ellenõrizzük a bejegyzéseket, mert ha hibásan adjuk meg ezeket, akkor az újraindítás után gondok lehetnek a rendszer indításával! ==== Végezetül gondoskodjunk róla, hogy a man:gjournal[8] modul minden egyes indítás során betöltõdjön. Ehhez nyissuk meg a [.filename]#/boot/loader.conf# állományt és adjuk hozzá a következõ sort: [.programlisting] .... geom_journal_load="YES" .... Gratulálunk, sikeresen beállítottuk a rendszerünkön a naplózást! Innen vagy az `exit` begépelésével lépjünk vissza a többfelhasználós módba, vagy egy újraindítással próbáljuk ki a konfiguráció eredményét (mi ezt javasoljuk). A rendszerindítás során a következõhöz hasonló üzeneteket kell majd látnunk: [source,shell] .... ad0: 76293MB XEC XE800JD-00HBC0 08.02D08 at ata0-master SATA150 GEOM_JOURNAL: Journal 2948326772: ad0s1g contains journal. GEOM_JOURNAL: Journal 3193218002: ad0s1h contains journal. GEOM_JOURNAL: Journal 3193218002: ad0s1d contains data. GEOM_JOURNAL: Journal ad0s1d clean. GEOM_JOURNAL: Journal 2948326772: ad0s1f contains data. GEOM_JOURNAL: Journal ad0s1f clean. .... Szabálytalan leállások esetén az iménti üzenetek némileg változhatnak, például: [source,shell] .... GEOM_JOURNAL: Journal ad0s1d consistent. .... Ez általában arra utal, hogy a man:gjournal[8] a naplóterületen tárolt információk segítségével helyreállította az állományrendszert. [[gjournal-new]] === A naplózás engedélyezése frissen létrehozott partíciókon Míg az elõbbiekben tárgyalt megoldást leginkább olyan partíciók esetén alkalmazhatjuk, amelyek már eleve tartalmaznak adatokat, addig egy újonnan létrehozott partíciót némileg könnyebb naplózással ellátni, mivel ilyenkor az adat- és a naplóterület egyazon partíción is kialakítható. Például most tegyük fel, hogy hozzáadtunk egy újabb lemezt a rendszerünkhöz, amelyen készítettünk egy új [.filename]#/dev/ad1s1d# nevû partíciót. A napló létrehozása ekkor csupán ennyi: [source,shell] .... # gjournal label ad1s1d .... A napló mérete alapértelmezés szerint 1 GB lesz, amelyet viszont a `-s` opció használatával tetszés szerint átállíthatunk. Az értéket megadhatjuk byte-okban, vagy a `K`, `M`, illetve `G` hozzáfûzésével kilobyte-okban, megabyte-okban, illetve gigabyte-okban is. Arra azonban figyeljünk, hogy a `gjournal` nem enged túlságosan kis méretû naplót létrehozni. Például egy 2 GB méretû napló az alábbi paranccsal hozható létre: [source,shell] .... # gjournal label -s 2G ad1s1d .... Mellé hozzunk létre egy állományrendszert az új partíción, ahol a `-J` kapcsolóval engedélyezzük a naplózást: [source,shell] .... # newfs -J /dev/ad1s1d.journal .... [[configure-kernel]] === A naplózás támogatásának beépítése a rendszermagba Amennyiben nem kívánjuk betölteni a `geom_journal` modult, lehetõségünk van közvetlenül a rendszermagba beépíteni a hozzá tartozó funkcionalitást. Ehhez nyissunk meg (vagy hozzunk létre) egy saját rendszermag-konfigurációs állományt, és vegyük fel benne a következõ két sort: [.programlisting] .... options UFS_GJOURNAL # Megjegyzés: Ez része a GENERIC rendszermagnak options GEOM_JOURNAL # Ezt se felejtsük ki .... A link:{handbook}#kernelconfig[FreeBSD kézikönyvben] szereplõ utasítások mentén fordítsuk le és telepítsük az új rendszermagot. Ha korábban használtuk volna a modult, akkor ezzel együtt ne felejtsük el kivenni a [.filename]#/boot/loader.conf# állományból sem a hozzá tartozó sort. [[troubleshooting-gjournal]] == A naplózás használata során felmerülõ hibák kezelése Ebben a szakaszban a naplózás alkalmazásakor jelentkezõ gondokra vonatkozó gyakran ismételt kérdéseket foglaljuk össze. === A rendszer folyamatosan összeomlik komolyabb lemezterhelés mellett. Van ennek valamilyen köze a naplózáshoz? A napló ilyenkor valószínûleg gyorsabban betelik, mint ahogy kiíródhatna a lemezre. Nem szabad elfeledkeznünk róla, hogy a napló méretének sosem az adatterület méretével kell arányosnak lennie, hanem a lemez terheltségével. Ha tehát a lemezeink nagyobb terhelés alatt vannak, akkor egy nagyobb területet kell hozzárendelnünk a naplóhoz. Ezzel kapcsolatban lásd a <> címû szakaszt. === Valamit nem sikerült rendesen beállítani a konfiguráció során, ezért most nem indul a rendszer. Meg lehet valahogy javítani? Ilyenkor vagy elfelejtettük (vagy netalán elírtuk) a [.filename]#/boot/loader.conf# állományban szükséges bejegyzést, vagy az [.filename]#/etc/fstab# állományunk hibákat tartalmaz. Az ilyen jellegû problémákat viszonylag könnyû helyrehozni. Az kbd:[Enter] billentyû lenyomásával hozzuk elõ az egyfelhasználós módhoz tartozó parancsértelmezõt. Ha ez sikerült, akkor kutassuk fel a probléma okát: [source,shell] .... # cat /boot/loader.conf .... Ha innen hiányzik vagy nem helyesen szerepel a `geom_journal_load` bejegyzés, akkor a naplózás használatához szükséges eszközök nem fognak létrejönni. Töltsük be a modult manuálisan, csatlakoztassuk az összes partíciót és folytassuk a többfelhasználós mód indítását: [source,shell] .... # gjournal load GEOM_JOURNAL: Journal 2948326772: ad0s1g contains journal. GEOM_JOURNAL: Journal 3193218002: ad0s1h contains journal. GEOM_JOURNAL: Journal 3193218002: ad0s1d contains data. GEOM_JOURNAL: Journal ad0s1d clean. GEOM_JOURNAL: Journal 2948326772: ad0s1f contains data. GEOM_JOURNAL: Journal ad0s1f clean. # mount -a # exit (a rendszerindítás folytatódik) .... Ha viszont ezzel a bejegyzéssel kapcsolatban semmilyen hibát nem találtunk, akkor nézzük meg az [.filename]#/etc/fstab# állományt. Akkor valószínûleg itt fogunk találni egy hibásan beírt vagy éppen hiányzó bejegyzést. Amennyiben errõl lenne szó, csatlakoztassuk kézzel a fennmaradó partíciókat és folytassuk a többfelhasználós mód indítását. === Visszavonható a naplózás, vissza lehet valahogy térni a Soft Updates használatához? Hogyne. A most következõ módszer segítségével megfordítható az egész folyamat. Miután végeztünk, a naplózás részére korábban kialakított partíciók tetszés szerint felhasználhatóak. Jelentkezzük be `root` felhasználóként és váltsunk egyfelhasználós módba: [source,shell] .... # shutdown now .... Válasszuk le a naplózást alkalmazó partíciókat: [source,shell] .... # umount /usr /var .... Írassuk ki lemezre a naplók tartalmát: [source,shell] .... # gjournal sync .... Állítsuk le a naplózóterületek használatát: [source,shell] .... # gjournal stop ad0s1d.journal # gjournal stop ad0s1f.journal .... Töröljük le az eszközökön tárolt összes naplózási metainformációt: [source,shell] .... # gjournal clear ad0s1d # gjournal clear ad0s1f # gjournal clear ad0s1g # gjournal clear ad0s1h .... Tiltsuk le az állományrendszer naplózását és állítsuk vissza a Soft Updates használatát: [source,shell] .... # tunefs -J disable -n enable ad0s1d tunefs: gjournal cleared tunefs: soft updates set # tunefs -J disable -n enable ad0s1f tunefs: gjournal cleared tunefs: soft updates set .... Manuálisan csatlakoztassuk újra a régi eszközöket: [source,shell] .... # mount -o rw /dev/ad0s1d /var # mount -o rw /dev/ad0s1f /usr .... Az [.filename]#/etc/fstab# állományban állítsunk vissza mindent az eredeti állapotába: [.programlisting] .... /dev/ad0s1f /usr ufs rw 2 2 /dev/ad0s1d /var ufs rw 2 2 .... Végül a [.filename]#/boot/loader.conf# állományból távolítsuk el a `geom_journal` modul betöltésére vonatkozó bejegyzést és indítsuk újra a rendszert. [[further-reading]] == Ajánlott olvasmányok A naplózás még viszonylag újdonságnak számít a FreeBSD esetében, ezért nem feltétlenül találunk róla túlságosan sok dokumentációt. Ettõl függetlenül azonban a következõ források elolvasása azért hasznosnak bizonyulhat: * A FreeBSD kézikönyv naplózással foglalkozó link:{handbook}#geom-gjournal[szakasza]. * `{pjd}`, a man:gjournal[8] fejlesztõjének a {freebsd-current} levelezési listára küldött http://lists.freebsd.org/pipermail/freebsd-current/2006-June/064043.html[levele]. * `{ivoras}` a {freebsd-questions} levelezési listára küldött http://lists.freebsd.org/pipermail/freebsd-questions/2008-April/173501.html[levele]. * A man:gjournal[8] és man:geom[8] man oldalak. diff --git a/documentation/content/hu/articles/linux-users/_index.adoc b/documentation/content/hu/articles/linux-users/_index.adoc index 6833f37223..12b023c7de 100644 --- a/documentation/content/hu/articles/linux-users/_index.adoc +++ b/documentation/content/hu/articles/linux-users/_index.adoc @@ -1,387 +1,397 @@ --- title: FreeBSD gyorstalpaló Linux® felhasználók számára authors: - author: Ferrell, John copyright: 2008 A FreeBSD Dokumentációs Projekt releaseinfo: "$FreeBSD$" trademarks: ["freebsd", "intel", "redhat", "linux", "unix", "general"] --- = FreeBSD gyorstalpaló Linux(R) felhasználók számára :doctype: article :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :source-highlighter: rouge :experimental: :toc-title: Tartalom :table-caption: Táblázat :figure-caption: Ábra :example-caption: Példa +ifeval::["{backend}" == "html5"] include::shared/hu/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "pdf"] +include::../../../../shared/hu/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "epub3"] +include::../../../../shared/hu/urls.adoc[] +endif::[] [.abstract-title] Kivonat Ez a cikk azért íródott, hogy röviden megismertesse a FreeBSD alapjait a középhaladó-haladó Linux(R) felhasználókkal. _Fordította: Páli Gábor, utolsó ellenõrzés: 2010.11.28._ ''' toc::[] [[intro]] == Bevezetés Ebben a leírásban a FreeBSD és a Linux(R) közti alapvetõ eltéréseket igyekszünk szemléltetni, aminek révén a középhaladó és haladó Linux(R) felhasználók pillanatok alatt bepillantást nyerhetnek a FreeBSD alapjaiba. Ez egyszerûen csak egy szakmai jellegû bevezetés, és nem foglalkozik a két rendszer felépítése közti "filozófiai" különbségekkel. A leírás feltételezi, hogy korábban már telepítettük a FreeBSD rendszert. Amennyiben ezt még nem tettük volna meg, vagy segítségre lenne szükségünk a telepítésben, akkor olvassuk el a FreeBSD kézikönyv link:{handbook}#install[A FreeBSD telepítése] címû fejezetét. [[shells]] == Parancsértelmezõk: hova tûnt a Bash? A Linuxról áttérõ felhasználók gyakran meglepõdnek azon, hogy a FreeBSD-ben nem a Bash az alapértelmezett parancsértelmezõ. Sõt, a Bash még az alaprendszerben sem található meg. Helyette a man:tcsh[1] az alapértelmezett parancsértelmezõ a FreeBSD-ben. Természetesen a Bash, a többi szintén közkedvelt parancsértelmezõhöz hasonlóan megtalálható a FreeBSD <>. Ha más parancsértelmezõket is telepítettünk, akkor a man:chsh[1] parancs segítségével tudjuk megváltoztatni az alapértelmezett parancsértelmezõnket. A `root` felhasználó alapértelmezett parancsértelmezõjének megváltoztatását azonban nem javasoljuk. Ennek oka, hogy azok a parancsértelmezõk, amelyek nem részei az alaprendszernek, általában a [.filename]#/usr/local/bin# vagy a [.filename]#/usr/bin# könyvtárakban találhatóak, és bizonyos vészhelyzetekben elõfordulhat, hogy ezeket az állományrendszereket nem tudjuk csatlakoztatni. Ilyen esetekben a `root` sem lesz képes elérni a saját alapértelmezett parancsértelmezõjét, amivel lényegében megakadályozzuk, hogy be tudjon jelentkezni. Erre a célra a `root` felhasználó egy alternatíváját, a `toor` felhasználót hozták létre, amelyet az alaprendszeren kívül található parancsértelmezõkkel is használhatunk. A link:{faq}#TOOR-ACCOUNT[toor hozzáférésérõl] a GYIK biztonsági kérdésekkel foglalkozó részében tudhatunk meg többet (angolul). [[software]] == Csomagok és portok: szoftverek telepítése FreeBSD alatt A szoftverek telepítésének hagyományos UNIX(R)-os megoldásain (a forrás letöltésén, kitömörítésén, a forráskód módosításán és lefordításán) túl az alkalmazások telepítésének további két módját is felkínálja a FreeBSD: ezek a csomagok és a portok. A rendszerhez elérhetõ összes port és csomag teljes listáját http://www.freebsd.org/ports/[ezen] a címen érhetjük el. [[packages]] === Csomagok A csomagok lényegében elõre lefordított alkalmazások, amelyek megfelelnek a Debian/Ubuntu rendszerekben megtalálható [.filename]#.deb#, vagy a Red Hat/Fedora rendszerekben megtalálható [.filename]#.rpm# állományoknak. A csomagok a man:pkg_add[1] segítségével telepíthetõek. Például az alábbi parancs az Apache 2.2 alkalmazást rakja fel: [source,shell] .... # pkg_add /tmp/apache-2.2.6_2.tbz .... Az `-r` kapcsolóval arra utasítjuk a man:pkg[add] programot, hogy magától töltse le és telepítse a csomagot, valamint annak függõségeit: [source,shell] .... # pkg_add -r apache22 Fetching ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-6.2-release/Latest/apache22.tbz... Done. Fetching ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-6.2-release/All/expat-2.0.0_1.tbz... Done. Fetching ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-6.2-release/All/perl-5.8.8_1.tbz... Done. [nyissz] To run apache www server from startup, add apache22_enable="YES" in your /etc/rc.conf. Extra options can be found in startup script. .... [NOTE] ==== Ha a FreeBSD valamelyik kiadását használjuk (6.2, 6.3, 7.0 stb., tehát CD-rõl telepítettük), akkor a `pkg_add -r` az adott kiadáshoz tartozó csomagokat fogja letölteni. Ezek a csomagok azonban _nem feltétlenül_ az alkalmazás legújabb verziójához tartoznak. Ezt az alapértelmezett viselkedést felül tudjuk bírálni, ha a `PACKAGESITE` környezeti változót az link:ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-6-stable/Latest/[ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-6-stable/Latest/] értékre állítjuk, és így például a 6.X sorozathoz készült legfrissebb csomagokat tölthetjük le. A FreeBSD különbözõ változatairól a link:{version-guide}[Válasszuk ki a nekünk igazán megfelelõ FreeBSD verziót!] címû cikkben olvashatunk bõvebben. ==== A csomagok használatával kapcsolatban a FreeBSD kézikönyvében kaphatunk részletesebb felvilágosítást, lásd link:{handbook}#packages-using[A csomagrendszer használata]. [[ports]] === Portok A FreeBSD-ben az alkalmazások telepítésének másik módja a Portgyûjtemény használata. A Portgyûjtemény lényegében [.filename]#Makefile# állományok és javítások gyûjteménye, amelyek a különféle alkalmazások forráskódját készítik fel arra, hogy a FreeBSD-n is használhatóak legyenek. Amikor telepítünk egy portot, akkor a rendszer elõször letölti az alkalmazás forráskódját, elvégzi a szükséges módosításokat, lefordítja a forrást és végül telepíti az alkalmazást (valamint mindezt megteszi az összes függõsége esetében). A Portgyûjtemény, vagy gyakran egyszerûen csak a "portfa", a [.filename]#/usr/ports# könyvtárban található. Itt nyilván feltételezzük, hogy a Portgyûjteményt is kiválasztottuk a FreeBSD telepítése során. Amennyiben a Portgyûjteményt még nem telepítettük volna, a man:sysinstall[8] segítségével feltehetjük a telepítõlemezrõl, vagy esetleg a man:csup[1], illetve man:portsnap[8] használatával letölthetjük a FreeBSD Projekt valamelyik szerverérõl. A Portgyûjtemény telepítésének részletes bemutatása megtalálható a kézikönyv link:{handbook}#ports-using[4.5.1. szakaszában]. A telepítéshez (általában) csak be kell lépnünk az adott port könyvtárába és el kell indítanunk a fordítást. A következõ példában az Apache 2.2 alkalmazást telepítjük a Portgyûjteménybõl: [source,shell] .... # cd /usr/ports/www/apache22 # make install clean .... A portok alkalmazásának egyik legnagyobb elõnye, hogy a szoftverek telepítése során testre tudjuk szabni azok beállításait. Például amikor az Apache 2.2 alkalmazást portként telepítjük, a `WITH_LDAP` man:make[1] változó megadásával engedélyezhetjük a mod_ldap használatát: [source,shell] .... # cd /usr/ports/www/apache22 # make WITH_LDAP="YES" install clean .... A Portgyûjteménnyel kapcsolatos további információk tekintetében olvassuk el a FreeBSD kézikönyv link:{handbook}#ports-using[A Portgyûjtemény használata] címû szakaszát. [[which]] === Portok vagy csomagok, mégis melyiket használjam? A csomagok tulajdonképpen elõre lefordított portok, ezért igazából csak abban van köztük különbség, hogy forrásból (portok) vagy binárisan telepítjük-e az alkalmazásokat. Mindegyik módszernek megvannak a maga elõnyei: .Csomagok (bináris) * Gyorsabb telepítés (a nagyobb alkalmazások lefordítása viszont nagyon sokáig is eltarthat). * Nem szükséges megértenünk a szoftverek lefordításának mikéntjét. * Nem kell fordítóprogramokat telepítenünk a rendszerünkre. .Portok (forrás) * A telepítés beállításait tetszõlegesen szabályozhatjuk. (A csomagok általában szabványos beállításokkal készülnek. A portok esetében azonban lehetõségünk van ezeket kedvünk szerint megváltoztatni, mint például további modulok fordítását kérni, vagy átállítani a telepítés alapértelmezett helyét.) * Ha késztetést érzünk, akkor akár a saját javításainkat is beletehetjük a forráskódba. Ha nincsenek különös igényeink, akkor a csomagok minden bizonnyal tökéletesen megfelelnek számunkra. Amikor viszont valamit külön be szeretnénk állítani, akkor ahhoz a portokat érdemes választanunk. (Ne felejtsük el azonban, hogy ha elsõsorban a csomagokhoz ragaszkodunk, de mégis módosítanunk kell valamit bennük, akkor a `make package` parancs kiadásával a portokból is tudunk csomagot készíteni, majd átmásolni azokat más szerverekre.) [[startup]] == A rendszer indítása: hova lettek a futási szintek? A Linux(R) a SysV rendszerindítási sémáját alkalmazza, miközben a FreeBSD a hagyományos BSD típusú man:init[8] megoldást. A BSD típusú man:init[8] esetén nincsenek futási szintek és nem létezik [.filename]#/etc/inittab# állomány. Helyette az man:rc[8] vezérli a rendszer indítását. Az [.filename]#/etc/rc# szkript beolvassa az [.filename]#/etc/defaults/rc.conf# és [.filename]#/etc/rc.conf# állományokat, amelyekbõl megállapítja, hogy milyen szolgáltatásokat indítson el. A megadott szolgáltatásokat ezután az [.filename]#/etc/rc.d# és a [.filename]#/usr/local/etc/rc.d# könyvtárakban található megfelelõ indítószkriptek segítségével indítja el. Ezek a szkriptek hasonlóak a Linux(R) rendszereken az [.filename]#/etc/init.d# könyvtárban található szkriptekhez. **** _A szolgáltatások indításáért felelõs szkriptek miért két különbözõ helyen találhatóak?_ Az [.filename]#/etc/rc.d# könyvtárban található szkriptek az "alaprendszer" részei (mint például a man:cron[8], man:sshd[8], man:syslog[3] és a többi). A [.filename]#/usr/local/etc/rc.d# könyvtárban pedig a felhasználó által telepíthetõ alkalmazások, például az Apache, Squid stb. szkriptjei találhatóak. _Mi a különbség az "alaprendszerben" található és a felhasználó által telepített alkalmazások között?_ A FreeBSD-t egy összefüggõ operációs rendszerként fejlesztik. Ezt másképpen úgy lehetne fogalmazni, hogy a rendszermagot, a rendszerszintû függvénykönyvtárakat és a hozzájuk tartozó programokat (mint például a man:ls[1], man:cat[1], man:cp[1] stb.) együtt fejlesztik és adják ki. Ezt nevezzük az "alaprendszernek". A felhasználó által telepíthetõ alkalmazások lényegében azok, amelyek nem részei ennek az "alaprendszernek", például az Apache, X11, Mozilla Firefox stb. Ezek általában a FreeBSD <> telepíthetõek. Mivel a felhasználók által telepített alkalmazásokat igyekszünk elkülöníteni az "alaprendszertõl", ezért ezek a [.filename]#/usr/local/# könyvtárba kerülnek. Ennek következtében a felhasználók által telepített binárisok a [.filename]#/usr/local/bin# könyvtárban, míg a hozzájuk tartozó konfigurációs állományok a [.filename]#/usr/local/etc# könyvtárban találhatóak, és így tovább. **** A szolgáltatásokat az [.filename]#/etc/rc.conf# állományban (lásd man:rc.conf[5]) tudjuk engedélyezni a `SzolgáltatásNév_enable="YES"` sor megadásával. A rendszer alapértelmezett beállításait az [.filename]#/etc/defaults/rc.conf# állományban találhatjuk meg, ezeket az [.filename]#/etc/rc.conf# állományban tudjuk felülbírálni. Az alkalmazásokhoz tartozó szolgáltatások engedélyezésének lépéseihez pedig a telepítésük után ne felejtsük el átolvasni a hozzájuk tartozó dokumentációt. Az [.filename]#/etc/rc.conf# állományból származó most következõ rövid kódrészlet az man:sshd[8] és Apache 2.2 szolgáltatásokat engedélyezi, valamint az Apache számára beállítja az SSL használatát. [.programlisting] .... # az SSHD engedélyezése sshd_enable="YES" # az Apache és benne az SSL támogatásának engedélyezése apache22_enable="YES" apache22_flags="-DSSL" .... Miután az [.filename]#/etc/rc.conf# állományban engedélyeztük a szolgáltatásokat, a parancssorból el is tudjuk indítani ezeket (a rendszer újraindítása nélkül): [source,shell] .... # /etc/rc.d/sshd start .... Ha egy szolgáltatást nem engedélyeztünk, akkor a parancssorból a `forcestart` paraméter megadásával tudjuk elindítani: [source,shell] .... # /etc/rc.d/sshd forcestart .... [[network]] == A hálózat beállítása [[interfaces]] === Hálózati interfészek A hálózati csatolófelületekre a Linux esetén alkalmazott általános _ethX_ alakú azonosítók helyett a FreeBSD az adott hálózati kártya meghajtójának nevével és utána egy sorszámmal hivatkozik. Az man:ifconfig[8] itt látható kimenetében két Intel(R) Pro 1000 hálózati kártya jelenik meg (em0 és em1): [source,shell] .... % ifconfig em0: flags=8843 mtu 1500 options=b inet 10.10.10.100 netmask 0xffffff00 broadcast 10.10.10.255 ether 00:50:56:a7:70:b2 media: Ethernet autoselect (1000baseTX ) status: active em1: flags=8843 mtu 1500 options=b inet 192.168.10.222 netmask 0xffffff00 broadcast 192.168.10.255 ether 00:50:56:a7:03:2b media: Ethernet autoselect (1000baseTX ) status: active .... [[ipaddress]] === Az IP-cím beállítása Az interfészekhez az man:ifconfig[8] paranccsal tudunk IP-címet rendelni. Az IP-címek beállítása azonban csak akkor marad meg az újraindítást követõen is, ha felvesszük az [.filename]#/etc/rc.conf# állományba. A most következõ példában megadunk egy hálózati nevet, IP-címet és egy alapértelmezett átjárót: [.programlisting] .... hostname="szerver1.minta.com" ifconfig_em0="inet 10.10.10.100 netmask 255.255.255.0" defaultrouter="10.10.10.1" .... DHCP esetén használjuk a következõt: [.programlisting] .... hostname="szerver1.minta.com" ifconfig_em0="DHCP" .... [[firewall]] == Tûzfalak Hasonlóan a Linuxban található IPTABLES megoldáshoz, a FreeBSD is kínál fel rendszermagszintû tûzfalazást. A FreeBSD jelen pillanatban három tûzfalat támogat: * link:{handbook}#firewalls-ipfw[IPFIREWALL] * link:{handbook}#firewalls-ipf[IPFILTER] * link:{handbook}#firewalls-pf[PF] Az IPFIREWALL, avagy IPFW (az IPFW szabályrendszereit az man:ipfw[8] paranccsal tudjuk kezelni) a FreeBSD fejlesztõi által készített és karbantartott tûzfal. A forgalomszabályozás megvalósításához és különbözõ típusú hálózati kapcsolatok szimulációjához az IPFW kiegészíthetõ a man:dummynet[4] használatával. Ez az IPFW szabály engedélyezi a beérkezõ SSH-kapcsolatokat: [.programlisting] .... ipfw add allow tcp from any to me 22 in via $ext_if .... Az IPFILTER tûzfalat Darren Reed dolgozta ki. Nem csak FreeBSD alatt találkozhatunk vele, több operációs rendszerre is portolták, többek közt NetBSD-re, OpenBSD-re, SunOS-re, HP/UX-ra és Solarisra. Ez az IPFILTER parancs engedélyezi a beérkezõ SSH-kapcsolatokat: [.programlisting] .... pass in on $ext_if proto tcp from any to any port = 22 .... Az utolsó tûzfal, a PF, az OpenBSD Projekt fejlesztése. A PF eredetileg az IPFILTER leváltására készült. Emiatt a PF szabályainak megadási módja nagyon hasonlít az IPFILTER esetében megismertekhez. A minõségalapú (QoS) forgalomszabályozás létrehozásához a PF az man:altq[4] megoldásával egészíthetõ ki. Ez a PF parancs engedélyezi a beérkezõ SSH-kapcsolatokat: [.programlisting] .... pass in on $ext_if inet proto tcp from any to ($ext_if) port 22 .... [[updates]] == A FreeBSD frissítése A FreeBSD rendszer háromféleképpen frissíthetõ: forráskódból, binárisan és telepítõlemezek használatával. A forráskódon keresztüli frissítés ugyan a legbonyolultabb ezek közül, azonban ez kínálja fel egyben a legnagyobb rugalmasságot is. Ennek során szinkronizálnunk kell a FreeBSD forráskódjának nálunk levõ (helyi) másolatát a FreeBSD CVS (Concurrent Versioning System) szervereivel. Miután ez megtörtént, le tudjuk fordítani a rendszermagot és a hozzá tartozó programokat. A források frissítésével kapcsolatban olvassuk el a FreeBSD kézikönyv link:{handbook}#updating-upgrading[frissítésrõl szóló fejezetét]. A bináris frissítés a Linux(R) típusú rendszereken elérhetõ `yum` vagy `apt-get` parancsok esetén megszokottakhoz hasonló. A man:freebsd-update[8] parancs letölti a frissítéseket és telepíti ezeket. Ez a frissítési folyamat a man:cron[8] használatával ütemezhetõ. [NOTE] ==== Amikor a man:cron[8] segítségével ütemezzük a frissítéseket, a man:crontab[1] állományban lehetõség szerint a `freebsd-update cron` parancsot használjuk, ezáltal igyekezzünk csökkenteni annak valószínûségét, hogy egyszerre több számítógép is ugyanakkor terhelje a szervert. [.programlisting] .... 0 3 * * * root /usr/sbin/freebsd-update cron .... ==== Az utolsó frissítési módszer, a telepítõlemezek használata lényegében egy egyértelmû folyamat. Indítsuk el számítógépünket a telepítõlemezrõl, és a telepítõben válasszuk a frissítés (upgrade) opciót. [[procfs]] == procfs: eltûnt, de nem nyomtalanul A Linux(R) alatt a [.filename]#/proc/sys/net/ipv4/ip_forward# használatával tudjuk megmondani, hogy az IP-csomagok továbbítása engedélyezett-e rendszerünkben. Mivel a man:procfs[5] a FreeBSD jelenlegi verzióiban már elavultnak számít, ezért ezt a man:sysctl[8] paranccsal nézhetjük meg a rendszer egyéb beállításai mellett. (A `sysctl` viszont Linux(R) alatt is egyaránt megtalálható.) Ha az IP-csomagok továbbításáról szóló példánál maradunk, akkor az alábbi módon kérdezhetjük le, hogy engedélyezett-e a FreeBSD rendszerünkön: [source,shell] .... % sysctl net.inet.ip.forwarding net.inet.ip.forwarding: 0 .... Az `-a` paraméter megadásával a rendszer összes jelenlegi beállítását le tudjuk kérdezni: [source,shell] .... % sysctl -a kern.ostype: FreeBSD kern.osrelease: 6.2-RELEASE-p9 kern.osrevision: 199506 kern.version: FreeBSD 6.2-RELEASE-p9 0: Thu Nov 29 04:07:33 UTC 2007 root@i386-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC kern.maxvnodes: 17517 kern.maxproc: 1988 kern.maxfiles: 3976 kern.argmax: 262144 kern.securelevel: -1 kern.hostname: server1 kern.hostid: 0 kern.clockrate: { hz = 1000, tick = 1000, profhz = 666, stathz = 133 } kern.posix1version: 200112 ... .... [NOTE] ==== Bizonyos `sysctl`-értékek írásvédettek. ==== Adódhatnak olyan alkalmak, amikor mégis szükségünk lehet a procfs használatára, mint például régi szoftverek futtatása, a rendszerhívások nyomkövetése a man:truss[1] segítségével, vagy a link:{handbook}#linuxemu[bináris Linux kompatibilitás] használata. (Noha a bináris Linux kompatibilitás egy saját procfs állományrendszert, egy man:linprocfs[5] rendszert használ.) A procfs típusú állományrendszerek csatlakoztatásához a következõt kell megadnunk az [.filename]#/etc/fstab# állományban: [source,shell] .... proc /proc procfs rw,noauto 0 0 .... [NOTE] ==== A `noauto` beállítás megadásával megakadályozzuk, hogy a [.filename]#/proc# a rendszerindítás során magától csatlakoztatódjon. ==== A procfs típusú állományrendszereket így lehet csatlakoztatni: [source,shell] .... # mount /proc .... [[commands]] == Gyakori parancsok [[packageCommands]] === A csomagok kezelése [.informaltable] [cols="1,1,1", frame="none", options="header"] |=== | Linuxos parancs (Red Hat/Debian) | A FreeBSD-s megfelelõje | Leírás |`yum install csomag` / `apt-get install csomag` |`pkg_add -r csomag` |A _csomag_ telepítése egy távoli számítógéprõl |`rpm -ivh csomag` / `dpkg -i csomag` |`pkg_add -v csomag` |Csomag telepítése |`rpm -qa` / `dpkg -l` |`pkg_info` |A telepített csomagok megjelenítése |=== [[systemCommands]] === A rendszer kezelése [.informaltable] [cols="1,1,1", frame="none", options="header"] |=== | Linuxos parancs | A FreeBSD-s megfelelõje | Leírás |`lspci` |`pciconf` |A PCI-os eszközök megjelenítése |`lsmod` |`kldstat` |A betöltött rendszermagmodulok felsorolása |`modprobe` |`kldload` / `kldunload` |Modulok betöltése és eltávolítása |`strace` |`truss` |A rendszerhívások nyomkövetése |=== [[conclusion]] == Lezárás Bízunk benne, hogy ez a leírás eleget mutatott be ahhoz, hogy elkezdjünk ismerkedni a FreeBSD-vel. Ha az érintett témák még jobban érdekelnek minket, vagy olyanról szeretnénk többet megtudni, ami itt nem szerepelt, akkor mindenképpen olvassunk bele a link:{handbook}[FreeBSD kézikönyvbe].