Ha tömören akarjuk összefoglalni, akkor a FreeBSD egy AMD64, Intel® EM64T, i386™, PC-98, IA-64, ARM®, PowerPC® és UltraSPARC® platformokra fejlesztett UNIX®-szerű operációs rendszer, amely a Kaliforniai Egyetem (Berkeley) rendszerének “4.4BSD-Lite” kiadására épül, valamint a “4.4BSD-Lite2” kiadásból tartalmaz még néhány továbbfejlesztést. Továbbá közvetett módon még felhasználja a Berkeley “Net/2” kiadásának i386 architektúrára készített portját, a “386BSD” forrásait is, amit annak idején William Jolitz készített, noha ebből ténylegesen már csak nagyon kevés található a rendszerben. A FreeBSD részletesebb bemutatása és annak tulajdonságai a FreeBSD honlapján találhatóak.

A FreeBSD-t munkához, oktatáshoz és szórakozáshoz rengeteg cég, internetszolgáltató, kutató, informatikus, diák és otthoni felhasználó használja a világ minden táján.

A FreeBSD bővebb bemutatásához olvassuk el a FreeBSD kézikönyvet.

A FreeBSD Projektnek az a célja, hogy olyan szoftvereket állítson elő, amelyek tetszőlegesen felhasználhatóak, mindenféle kötöttségek nélkül. A fejlesztők közül sokan nagyon sok időt és munkát fektetnek a forráskódba (és így a Projektbe), ami nyilván megérdemelne némi anyagi ellensúlyozást olykor, de egyáltalán nem ragaszkodunk hozzá. Úgy érezzük, mindenek előtt az a “küldetésünk”, hogy feltétel nélkül segítsünk mindenkit a munkánkkal, függetlenül annak szándékaitól, így a munkánk a lehető legnagyobb körben kerül felhasználására és így nyújtja a lehető legtöbb hasznot. Véleményünk szerint ez az egyik legalapvetőbb célja a szabad szoftvereknek és ezt a hozzáállást támogatjuk a leginkább.

A forrásaink között található, GNU General Public License (GPL) vagy a GNU Library General Public License (LGPL) licencelésű munkák azonban már valamivel több kötöttséggel járnak, habár ezek inkább a közzétételükre vonatkoznak, nem pedig annak ellenkezőjére, ahogy azt általában megszokhattuk. A GPL licencű szoftverek kereskedelmi célú felhasználásának további esetleges nehézségei miatt azonban lehetőségeink szerint igyekszünk ezeket olyan szoftverekkel felváltani, amelyek a kevésbé szigorúbb FreeBSD licencet alkalmazzák.

Igen. Ezek a megszorítások azonban nem az adott munka felhasználását szabályozzák, hanem csupán azt, hogy miként viszonyuljunk a FreeBSD Projekthez. Ha komoly kétségeink lennének a licenceléssel kapcsolatban, olvassuk a jelenleg érvényes licencet (angolul). Az egyszerű kíváncsiskodók kedvéért nagyjából így tudnánk összefoglalni a licencet:

• Ne állítsuk, hogy mi készítettük.

• Ne pereljük a Projektet, ha nem működik.

A legtöbb ember számára igen. A kérdés megválaszolása azonban természetesen nem ennyire egyértelmű.

Sokan nem is magát az operációs rendszert, hanem inkább az alkalmazásokat használják. Valójában pedig maguk az alkalmazások azok, amelyek az operációs rendszert használják. A FreeBSD-t úgy alakították ki, hogy az alkalmazások számára egy szilárd és mindentudó környezetet nyújtson. Támogatja a böngészők, irodai programcsomagok, levelező programok, grafikus programok, programozási környezetek, hálózati szerverek széles választékát, és szinte minden mást, amire csak szükségünk lehet. Az ilyen alkalmazások legnagyobb része elérhető a Portgyűjteményen keresztül.

Ha viszont olyan alkalmazást kívánunk használni, amely csak bizonyos operációs rendszereken érhető el, nem tudjuk magát az operációs rendszert egyszerűen lecserélni alatta. Bizonyos esetekben azonban előfordulhat, hogy FreeBSD alatt is találunk hozzá hasonló alkalmazásokat. Amikor egy stabil irodai vagy internet szerverre van szükségünk, esetleg egy megbízható munkaállomásra, vagy egyszerűen csak megszakítások nélkül szeretnénk végezni a munkánkat, a FreeBSD-ben igényeinkhez mérten szinte minden megtalálhatunk. A világon rengeteg felhasználó, beleértve a kezdőket és a tapasztalt UNIX rendszergazdákat egyaránt, asztali operációs rendszerként is a FreeBSD-t használja.

Ha egy másik UNIX környezetről akarunk FreeBSD-re váltani, akkor a legtöbb dolog már ismerős lehet számunkra. Amennyiben viszont valamilyen grafikus operációs rendszerről, például Windows®-ról vagy a Mac OS® valamelyik régebbi változatáról szándékozunk átállni, minden bizonnyal időt kell majd szánnunk a feladatok UNIX stílusú megvalósításának megismerésére. Ez a GYIK és a FreeBSD kézikönyv ehhez tökéletes kiindulási alapot biztosít.

Érdemes valamint rámutatni, hogy a “szabad” szót az imént két értelemben is használtuk: az egyik jelentése szerint “költségek nélkül”, míg a másik jelentése szerint “tetszés szerint”. Egy-két tiltott dologtól, például azt állítjuk, hogy mi írtuk, eltekintve tényleg bármit csinálhatunk vele.

James Howard The BSD Family Tree címmel (angolul) készített egy alapos leírást a különböző projektek közti eltérések bemutatására.

Jelen pillanatban a FreeBSD fejlesztése két párhuzamos ágon folyik, és mind a kettőből készülnek kiadások. A 7.X sorozat kiadásai a 7-STABLE ágból, míg a 8.X sorozat kiadásai a 8-STABLE ágból készülnek.

A 8.0-s kiadás megjelenéséig a 7.X sorozat volt a -STABLE. A 8.0 kiadás megjelenésével azonban a 7.X ág “meghosszabbított támogatást” kapott, és már csak a nagyobb hibákat, például a biztonsági hibákat javítják benne. Az 7-STABLE ágból még várhatóak további kiadások is, azonban ezt jelenleg már “örökségi” ágnak tekintjük, és a legtöbb munka már a 8-STABLE részeként jelenik meg.

A 8.1 változat a 8-STABLE ág legfrissebb kiadása, amely 2010 júliusban jelent meg. Az 7-STABLE ágból a 7.3 a legfrissebb kiadás, amely 2010 márciusban jelent meg.

Ha röviden össze akarjuk foglalni, akkor a -STABLE változatokat elsősorban az internet-szolgáltatók, vállalkozások számára ajánljuk, illetve minden olyan felhasználó számára, aki a legújabb (és minden bizonnyal még instabil) -CURRENT pillanatkiadásokhoz viszonyítottan a legkevesebb változtatással kívánnak egy megbízható, stabil verziót használni a rendszerből. Ugyan bármelyik ágból készülhetnek, azonban a -CURRENT esetében meglehetősen sok változásra kell felkészülnünk (a -STABLE ághoz képest) az egyes kiadások között.

A kiadások néhány havonta készülnek. Mivel a legtöbben ennél pontosabban követik a FreeBSD forrásait (lásd a FreeBSD-CURRENT és FreeBSD-STABLE változatokra vonatkozó kérdéseket), ennél valamire többre van szükségünk, hiszen a források folyamatosan változnak.

A FreeBSD egyes kiadásairól a Kiadások megjelentetését összefoglaló oldalon tájékozódhatunk a FreeBSD honlapján.

A FreeBSD-CURRENT az operációs rendszer aktív fejlesztés alatt álló változata, amely idővel az új FreeBSD-STABLE ággá válik. Ez a változat tulajdonképpen csak a rendszeren dolgozó fejlesztők és a megátalkodott hobbifelhasználók számára érdekes. A kézikönyv erre vonatkozó szakaszában olvashatunk részletesebben a -CURRENT használatáról.

Ha nem mozgunk otthonosan az operációs rendszerek világában, vagy ha nem tudjuk megmondani a különbséget egy valódi és egy ideiglenes probléma között, akkor nem javasoljuk a FreeBSD-CURRENT használatát. Ez a fejlesztési vonal nagyon gyorsan fejlődik és néha lefordíthatatlan állapotba kerül. A FreeBSD-CURRENT változat használóitól elvárjuk, hogy képesek legyenek felmérni a felbukkanó problémákat, és közülük csak azokat jelenteni, amelyek valóban hibákat takarnak és nem pedig csak apró “bökkenők”. Ezért a FreeBSD-CURRENT levelezési lista olvasói általában “A make world parancs valami csoportra panaszkodik” típusú kérdéseket általában figyelembe se veszik.

A -CURRENT és -STABLE ágak aktuális állapotáról minden hónapban pillanatkiadások készülnek. Célunk ezzel:

• A telepítő legfrissebb változatának tesztelése.

• Időt és sávszélességet szeretnénk megspórolni a -CURRENT vagy -STABLE változatok azon felhasználóinak, akik az iméntiek hiányából fakadóan nem tudják naponta frissíteni a rendszerüket.

• Kiindulási pontokat rögzítünk a kód aktuális állapota alapján, ha később netalán valamilyen szörnyűség történne. (Noha a CVS általában védelmet nyújt az ilyen rémisztő dolgok bekövetkezése ellen.)

• Az összes tesztelendő újítást és javítást ezen a módon kívánjuk a lehető legszélesebb körben elérhetővé tenni.

Egyik -CURRENT pillanatkiadás sem tekinthető “hétköznapi felhasználásra alkalmasnak”. Ha egy megbízható és széles körben tesztelt rendszerre van szükségünk, akkor vagy maradjunk a kiadásoknál vagy használjuk a -STABLE vonalból készült pillanatkiadásokat.

A pillanatkiadások innen érhetőek el.

Minden aktívan fejlesztett ághoz havonta készülnek hivatalos pillanatkiadások. A népszerűbb i386 és amd64 ágakból azonban napi kiadások is elérhetőek a http://snapshots.us.freebsd.org a címen.

Amikor a FreeBSD 2.0.5 megjelent, a FreeBSD fejlesztése kettévált. Az egyik ág neve -STABLE, a másiké pedig -CURRENT lett. A FreeBSD-STABLE az olyan internet-szolgáltatók és egyéb vállalkozások számára készült, ahol a fejlesztés alatt álló újítások vagy a hirtelen váltások által okozott problémák gyakran nem engedhetőek meg. Ide csak olyan hibajavítások és kisebb módosítások kerülnek, amelyeket alaposan leteszteltek. A FreeBSD-CURRENT ezzel szemben a 2.0 megjelenése óta egyetlen, szakadásmentes fejlesztési vonalat képvisel, amely a 8.1-RELEASE és az azon túli kiadások felé halad. Ha többet szeretnénk megtudni a jelenlegi ágak állapotáról és a következő kiadások ütemezéséről, akkor ezzel kapcsolatban olvassuk el a FreeBSD Release Engineering című cikk kiadások leágaztatásáról szóló részét (angolul). Az ágak jelenlegi állapota és a jövőbeni kiadások ütemterve a Kiadások információk oldalán található (angolul).

A 2.2-STABLE ág a 2.2.8 megjelenésével nyugdíjba vonult. A 3-STABLE ág a 3.5.1 mint az utolsó 3.X kiadás megjelenésével ért véget. A 4-STABLE ág a 4.11 mint az utolsó 4.X kiadással fejeződött be. Ezekbe az ágakban a legtöbb esetben már csak biztonsági javításokat végeznek. Az 5-STABLE ág fejlesztése az utolsó 5.X kiadás, az 5.5 megjelenésével lezárult. A 6-STABLE ág fejlesztése még folytatódik valameddig, de ez alatt leginkább már csak a biztonsági rések és egyéb komoly problémák javításait kell érteni.

A 8.1-STABLE a jelenleg fejlesztett -STABLE ág. A 8.1-STABLE ágból megjelent legfrissebb kiadás a 8.1-RELEASE, amely 2010 júliusban jelent meg.

A 9-CURRENT a -CURRENT ág legfrissebb változata, és ez a FreeBSD következő generációja. Erről az ágról a Mi az a FreeBSD-CURRENT? kérdésnél szolgálunk részletesebb információkkal.

A Release Engineering Team <re@FreeBSD.org> átlagosan a FreeBSD egy újabb nagyobb változatát 18 havonta, míg egy kisebb kiadását 8 havonta jelenteti meg. A kiadások dátumát előre kihirdetik, így a rendszeren dolgozó emberek pontosan tudják, hogy mikorra kell befejezniük a munkájukat és letesztelni azt. Minden kiadást egy tesztelési időszak előz meg, ahol megbizonyosodnak róla, hogy az elkészült újítások nem veszélyeztetik az új kiadás megbízhatóságát. A legtöbb felhasználó pontosan ezt a típusú elővigyázatosságot szereti legjobban a FreeBSD-ben, még annak árán is, hogy a legújabb finomságok bekerülésére még a -STABLE ág esetén gyakran sokat kell várni.

A kiadások szerkesztéséről (valamint a soronkövetkező kiadások ütemezéséről) a FreeBSD honlapján belül ezen az oldalon olvashatunk részletesebben (angolul).

Akik egy kicsivel több izgalomra vágynak, azok részére az előbb említett, naponta készített bináris pillanatkiadásokat ajánljuk.

A FreeBSD Projektre vonatkozó fontosabb döntéseket, mint például a Projekt haladási irányát vagy hogy vehet részt a forráskód fejlesztésében, egy 9 fős irányító csoport hozza. Rajtuk kívül még egy több mint 350 fős fejlesztői csapat jogosult közvetlenül módosítani a FreeBSD forrásait.

A legtöbb bonyolultabb változtatást általában azonban a megfelelő levelezési listákon is megvitatják, amiben bárki különösebb korlátozás nélkül részt vehet.

A FreeBSD összes fontosabb kiadása elérhető anonim FTP-n keresztül a FreeBSD FTP oldaláról:

• A legfrissebb 8-STABLE kiadás, a 8.1-RELEASE ebből a könyvtárból érhető el.

• Havonta készülnek pillanatkiadások a -CURRENT és a -STABLE ágakból, de ezek leginkább a legújabb változatot tesztelők és a fejlesztők számára fontosak.

• A legfrissebb 7-STABLE kiadás, a 7.3-RELEASE ebből a könyvtárból érhető el.

Ha a FreeBSD-t CD-n, DVD-n vagy más egyéb telepítőeszközön szeretnénk megkapni, akkor ezzel kapcsolatban nézzük meg a kézikönyvet.

A felhasználók kéréseit tartalmazó hibajelentések adatbázisát a honlap webes hibajelentésekkel foglalkozó felületén keresztül érhetjük el.

A send-pr(1) parancs segítségével tudunk e-mailen keresztül hibajelentéseket és egyéb változtatási kéréseket küldeni. Emellett még böngésző segítségével is tudunk hibajelentéseket küldeni a honlap webes hibabejelentő felületén.

Mielőtt beküldenénk egy hibajelentést, olvassuk el a Writing FreeBSD Problem Reports című cikket (angolul), amelyből megtudhatjuk, hogyan készítsünk jól hasznosítható hibajelentéseket.

Nézzük meg a FreeBSD Projekt honlapjáról elérhető dokumentációkat.

A Projekt igen széles körű dokumentációval rendelkezik, amely a következő linkről érhető el: http://www.FreeBSD.org/docs.html. Emellett a GYIK végén szereplő, valamint a kézikönyvben található irodalomjegyzék tartalmazza az ajánlott könyveket.

Igen. A dokumentáció több különböző állomány- és tömörítési formátumban elérhető az FreeBSD FTP oldalán belül a /pub/FreeBSD/doc/ könyvtárból.

A dokumentációt több különböző módon osztályozhatjuk. Többek közt:

• A dokumentum neve alapján, például faq (GYIK), vagy handbook (kézikönyv).

• A dokumentum nyelv és karakterkódolása alapján. Ezeket a FreeBSD rendszerekben, a /usr/share/locale könyvtárban megtalálható nyelvi beállítások nevei szerint adjuk meg. Jelenleg a következő nyelveken és kódolásokban érhető el a dokumentáció:

  Név	Leírás
  en_US.ISO8859-1	Angol (Egyesült Államok)
  bn_BD.ISO10646-1	Bengáli vagy bangla (Banglades)
  da_DK.ISO8859-1	Dán (Dánia)
  de_DE.ISO8859-1	Német (Németország)
  el_GR.ISO8859-7	Görög (Görögország)
  es_ES.ISO8859-1	Spanyol (Spanyolország)
  fr_FR.ISO8859-1	Francia (Franciaország)
  hu_HU.ISO8859-2	Magyar (Magyarország)
  it_IT.ISO8859-15	Olasz (Olaszország)
  ja_JP.eucJP	Japán (Japán, EUC kódolás)
  mn_MN.UTF-8	Mongol (Mongólia, UTF-8 kódolás)
  nl_NL.ISO8859-1	Holland (Hollandia)
  no_NO.ISO8859-1	Norvég (Norvégia)
  pl_PL.ISO8859-2	Lengyel (Lengyelország)
  pt_BR.ISO8859-1	Portugál (Brazília)
  ru_RU.KOI8-R	Orosz (Oroszország, KOI8-R kódolás)
  sr_YU.ISO8859-2	Szerb (Szerbia)
  tr_TR.ISO8859-9	Török (Törökország)
  zh_CN.GB2312	Egyszerűsített kínai (Kína, GB2312 kódolás)
  zh_TW.Big5	Hagyományos kínai (Tajvan, Big5 kódolás)

  Megjegyzés: Nem mindegyik dokumentum érthető el mindegyik nyelven.

• A dokumentum formátuma alapján. A dokumentumok több különböző formátumban állnak rendelkezésre. Mindegyik formátum használatának megvannak az előnyei és hátrányai. Egyes formátumok inkább az interneten keresztüli olvasgatásra megfelelőek, mások pedig nyomtatott formában nyújtanak esztétikus hatást. A több különböző formátumnak köszönhetően az olvasók igényeik szerint el tudják olvasni a dokumentáció különböző részeit akár a képernyőn, akár papíron. Jelenleg a következő formátumokban érhetőek el a dokumentumok:

  Formátum	Leírás
  html-split	Kis méretű, hiperhivatkozásokkal ellátott HTML állományok gyűjteménye
  html	Egyetlen óriási, az egész dokumentumot tartalmazó HTML állomány
  pdf	Az Adobe-féle Portable Document Format
  ps	PostScript
  rtf	A Microsoft Rich Text formátuma
  txt	Egyszerű szöveges állomány

  Megjegyzés: Amikor egy ilyen dokumentumot betöltünk a Wordbe, akkor az oldalszámok maguktól nem frissülnek. Ehhez a dokumentum betöltése után nyomjuk le a Ctrl+A, Ctrl+End, F9 billentyűket.

• A tömörítés és csomagolás típusa alapján. Ezek közül jelenleg hármat használunk.

  1. Ahol a formátum html-split, ott az állományokat a tar(1) segítségével csomagoltuk össze. Az így keletkező .tar állományt ezek után az alábbi részben szereplő tömörítési megoldásokkal tömörítettük.

  2. Az összes többi formátum esetén csak egyetlen állomány keletkezik, amelynek a neve típus.formátum (tehát például article.pdf, book.html és így tovább).

     Ezeket az állományokat azután két tömörítési eljárással tömörítjük.

     Eljárás	Leírás
     zip	A zip formátum. FreeBSD alatt ezt úgy tudjuk kitömöríteni, ha először telepítjük a archivers/unzip portot.
     bz2	A bzip2 formátum. Nem olyan elterjedt, mint a zip, de általában kisebb méretű állományokat készít. Ilyen állományokat akkor tudunk kitömöríteni, ha telepítjük a archivers/bzip2 portot.

     Ennek megfelelően tehát a kézikönyv bzip2-vel tömörített PostScript változata a handbook/ könyvtáron belül book.ps.bz2 néven található.

Miután kiválasztottuk a számunkra megfelelő letöltendő formátumot és tömörítési módszert, magunknak kell letölteni a kiválasztott tömörített állományokat, majd kibontani ezeket és átmásolni a megfelelő helyre.

Például, ha a GYIK fejezetekre darabolt, bzip2(1) segítségével tömörített változata a doc/en_US.ISO8859-1/books/faq/book.html-split.tar.bz2 állományban található meg. A letöltéséhez és kibontásához a következőket kell tennünk:

# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/en_US.ISO8859-1/books/faq/book.html-split.tar.bz2
# bzip2 -d book.html-split.tar.bz2
# tar xvf book.html-split.tar

A művelet befejeződésével kapunk néhány .html kiterjesztésű állományt. Ezek közül az egyik neve index.html, ebben található a tartalomjegyzék, a bevezetés és a dokumentum többi részére mutató hivatkozások. Ezeket az állományokat kell szükség szerint átmásolnunk vagy átmozgatnunk a megfelelő helyre.

Az összes velük kapcsolatos információt a kézikönyv levelezési listákról szóló részében találjuk.

Az összes rájuk vonatkozó információt a kézikönyv hírcsoportokról szóló részében találjuk meg.

Igen, a legtöbb nagyobb IRC hálózaton található FreeBSD-vel foglalkozó csatorna:

• Az EFNet hálózaton található #FreeBSD csatorna lényegében egy FreeBSD-vel foglalkozó fórum, de itt ne nagyon próbálkozzunk segítséget kérni a többiektől, ha netalán lusták lennénk elolvasni a man oldalakat vagy éppen kutatunk valamit. Ez a hely elsősorban csevegésre szolgál, ahol mindenféle téma felmerül, a szextől kezdve a sportokon keresztül a nukleáris fegyverekig éppen úgy, ahogy a FreeBSD-ről is. Mi szóltunk előre! A szerver a irc.efnet.org címen érhető el.

• Az EFNet hálózaton található #FreeBSDhelp csatorna kifejezetten a FreeBSD felhasználók megsegítését veszi célba. Az itt levők sokkal szívesebben válaszolnak a kérdéseinkre, mint a #FreeBSD csatornán.

• A Freenode hálózaton található ##FreeBSD csatornán mindig sokan vannak, itt bármilyen témában kérhetünk segítséget. A beszélgetések időnként ugyan kifutnak a szigorú szakmai témákból, de a FreeBSD-vel kapcsolatos kérdések itt mindig elsőbbséget élveznek. Szívesen segítünk bárkinek, és lehetőség szerint igyekszünk a kézikönyv megfelelő részeire hivatkozni, vagy adni valamilyen útmutatást arra vonatkozóan, hogy merre tájékozódhatunk részletesebben a problémánkkal kapcsolatban. Ez alapvetően egy angol nyelvű csatorna, habár a világ minden tájáról érkeznek tagjaink. Ha az anyanyelvünkön szeretnénk inkább csevegni, akkor először tegyük fel a kérdésünket angolul, aztán próbálkozzunk a megfelelő ##freebsd-nyelv csatornán.

• A DALNET hálózaton található #FreeBSD csatorna az Egyesült Államokból a irc.dal.net szerveren, Európából pedig az irc.eu.dal.net szerveren keresztül érhető el.

• A DALNET hálózaton található #FreeBSDHelp csatorna az Egyesült Államokból a irc.dal.net szerveren, Európából pedig a irc.eu.dal.net szerveren keresztül érhető el.

• Az UNDERNET hálózaton található #FreeBSD csatorna az Egyesült Államokból a us.undernet.org, Európából pedig a eu.undernet.org szerveren keresztül érhető el. Mivel ez a csatornát leginkább segítségnyújtásra tartjuk fenn, készüljünk fel arra, hogy a hivatkozott dokumentumokat is el kell olvasnunk.

• A RUSNET hálózaton található #FreeBSD csatorna az oroszul beszélő FreeBSD felhasználók számára igyekszik segítséget nyújtani. Emellett viszont remek hely a nem szakmai jellegű témák megvitatásához is.

• A Freenode hálózaton található #bsdchat csatorna a hagyományos kínai (UTF-8 kódolású) nyelvet beszélő FreeBSD felhasználókat igyekszik segíteni. A nem szakmai jellegű témák részére is egy remek hely.

Az említett csatornák mindegyike egymástól független, és nem állnak egymással kapcsolatban. Sőt, még a csevegési stílusuk is eltérő, ezért érdemes a saját stílusunkhoz leginkább illeszkedőt megkeresni. Mint ahogy az összes IRC csatorna esetében előfordul, itt is könnyedén érhetnek bennünket személyes sértések vagy egyszerűen csak sok szóbeli sárdobálást láthatunk (mivel jóval több az ilyen helyeken a balga ifjú, mint a higgadtabb idős) — ezekkel ne is törődjünk!

A FreeBSD Mall is nyújt keresdelmi támogatást a FreeBSD-hez. Erről a honlapjunkon tudhatunk meg többet.

A BSD Certification Group, Inc. DragonFly BSD, FreeBSD, NetBSD és OpenBSD rendszerekhez ad rendszergazdai képesítéseket. Amennyiben érdekel minket, látogassunk el a honlapjukra.

Kérünk minden olyan további szervezetet, amely tréninget vagy támogatást kíván nyújtani a Projektnek, hogy jelentkezzenek és felvesszük őket a listánkra!

Ehhez a következő három floppy image-re lesz alapvetően szükségünk: floppies/boot.flp, floppies/kern1.flp és floppies/kern2.flp. Ezeket az image-eket az fdimage vagy dd(1) segédprogramokkal kell rámásolnunk lemezekre.

Ha magukat a terjesztéseket akarjuk letölteni (mert például egy DOS típusú állományrendszerről akarunk telepíteni), akkor az alábbi terjesztéseket kell beszereznünk:

• base/

• manpages/

• compat*/

• doc/

• src/ssys.*

A teljes folyamatot, valamint a telepítéssel kapcsolatos általános tudnivalókat valamivel bővebben a kézikönyv FreeBSD telepítésével foglalkozó részéből ismerhetjük meg.

Egy 3,5 colos (1,44 MB kapacitású) lemezen 1 474 560 byte-nyi adat fér el. A rendszerindításhoz használt image mérete is pontosan 1 474 560 byte.

A rendszerindító lemezek előkészítése során elkövetett hibák általában a következők:

• Amikor az image-eket FTP-n keresztül töltjük le, elfelejtünk bináris (binary) átviteli módot használni.

  Egyes FTP kliensek alapértelmezés szerint szöveges (ascii) módban viszik át az állományokat, és ennek során megpróbálják a sorvége karaktereket az adott operációs rendszer konvenciói szerint átalakítani. Ilyenkor szinte kétségtelen, hogy ezzel tönkreteszik az image-et. Ezért ne felejtsük el ellenőrizni a letöltött image-eket: ha a méretük nem egyezik meg pontosan a szerveren levő változatukéval, akkor gyaníthatóan a letöltés közben történt velük valami.

  Megoldás: miután csatlakoztunk a szerverhez, de még mielőtt elkezdük volna a letöltést, az FTP kliens parancssorában gépeljük be, hogy binary.

• Az image lemezre másolása a DOS copy parancsának (vagy hasonló grafikus eszközök) használatával.

  A copy és a hozzá hasonló programok nem használhatóak erre a célra, mivel az image-eket közvetlenül a rendszeindításhoz hozták létre. Ennek megfelelően az egyes image-ek a lemezek teljes tartalmát sávról sávra tartalmazzák, és így nem hétköznapi állományként kell velük bánni. Ezeket a floppykra alacsonyszintű eszközök (például az fdimage vagy rawrite) segítségével, “nyers” módban kell felvinni, ahogy azt a FreeBSD telepítését leíró útmutatóban is olvashatjuk.

A telepítés részletes leírása a kézikönyv FreeBSD telepítéséről szóló részében olvasható.

A FreeBSD használatához egy 486-os vagy jobb processzorral rendelkező számítógépre, 24 MB vagy annál több memóriára, és legalább 150 MB tárhelyre lesz szükségünk.

A FreeBSD összes változata képes futni szinte bármilyen olcsó MDA típusú grafikus kártyával, de az Xorg használatához már VGA vagy annál jobb videokártya szükségeltetik.

Lásd 4 fejezet.

Jelen pillanatban ennek nincs egyszerű módja. Minden egyes kiadáshoz tartoznak telepítőfloppyk, használjuk ezeket.

Ha egy módosított kiadást akarunk készíteni, kövessük a(z angol nyelvű) Release Engineering cikk útmutatásait.

Először telepítsük a Windowst, majd a FreeBSD-t. A FreeBSD boot managere ekkor képes lesz a Windows és a FreeBSD indítására is. Vigyázzunk, mert ha a Windowst telepítjük fel másodikként, akkor az minden figyelmeztetés nélkül durván felülírja az aktuális boot managert. Ha ezt tapasztaljuk, akkor olvassuk el a következő szakaszt.

A FreeBSD-hez tartozó boot managert háromféleképpen tudjuk újratelepíteni:

• Indítsuk el a DOS-t, lépjünk be a FreeBSD terjesztéshez tartozó tools könyvtárba és keressük meg a bootinst.exe nevű állományt. Indítsuk el a következő módon:

  ...\TOOLS> bootinst.exe boot.bin

  Ekkor a boot manager visszakerül a helyére.

• Használjuk a FreeBSD-hez létrehozott rendszerindító lemezeket, és a telepítőben válasszuk a Custom (Egyéni telepítés) menüpontot, majd azon belül válasszuk a Partition (Partíció) pontot. Itt válasszuk ki azt a meghajtót, ahol korábban a boot managerünk volt (ez valószínűleg a felsorolásban az első lesz) és amikor belépünk a partíciószerkesztőbe, akkor egyből válasszuk a Write (W) opciót (tehát ne változtassunk semmit). Ez megerősítést fog kérni, amire válasszuk a [ Yes ] gombot, és amikor a boot manager kiválasztása rész jelenik meg, válasszuk a FreeBSD Boot Manager pontot. Ezzel a boot manager újra a lemezre íródik. Miután ezzel végeztünk, lépjünk ki a telepítőből és indítsuk újra a rendszerünket a megszokott módon.

• Indítsuk a rendszerünket a FreeBSD rendszerindító lemezéről (vagy CD-jéről), majd válasszuk a telepítőben a Fixit (Javítás) menüpontot. Ezután válasszuk a javítófloppy vagy a(z “élő” állományrendszerrel rendelkező) 2. CD használatát, majd lépjünk be a javításhoz elindított parancsértelmezőbe. Ezt követően adjuk ki az alábbi parancsot:

  Fixit# fdisk -B -b /boot/boot0 eszköz

  A parancsban az eszköz helyére annak az eszköznek a nevét adjuk meg, amelyről a rendszert szoktuk indítani, például ad0 (az első IDE-lemez), ad4 (az első IDE-lemez valamelyik vezérlőn), da0 (az első SCSI-lemez) stb.

Ezeken a gépeken az IBM BIOS-ának egy korai hibás változata található, amely a FreeBSD által használt partíciókat tévesen “suspend-to-disk” típusú partícióknak tekinti. Ennek következtében amikor a BIOS megpróbálja értelmezni a FreeBSD által létrehozott partíciót, megakad.

Az IBM [1] szerint az alábbi típus/BIOS változatokban található meg ez a hiba.

Úgy értesültünk, hogy az IBM BIOS-ok későbbi változataiban ismét felbukkant ez a típusú hiba. Ebben az üzenetben Jacques Vidrine <nectar@FreeBSD.org> a FreeBSD laptop computer levelezési lista tagjainak egy olyan módszert mutat be, ami segíthet, ha az újabb típusú IBM laptopunk nem tudja elindítani a FreeBSD-t, és így váltani tudunk a BIOS előző vagy következő verziójára.

Ha régebbi típusú BIOS-szal rendelkezünk és a frissítés nem megoldható, akkor a FreeBSD-t telepíthetjük úgy is, hogy megváltoztatjuk a FreeBSD által használt partíció azonosítóját és egy olyan rendszerindító blokkot telepítünk, amelyik képes ezt kezelni.

Ehhez először is a gépet egy olyan állapotba kell visszahoznunk, ahol már túl tudunk jutni a rendszerindító képernyőn. Ezt úgy tudjuk elérni, ha nem engedjük, hogy a gép indulása közben észrevegye az elsődleges lemezen található FreeBSD partíciót. Erre az egyik lehetséges megoldás, ha a gépből ideiglenesen eltávolítjuk a merevlemezt és átrakjuk egy régebbi ThinkPadba (például egy ThinkPad 600-as típusba) vagy a megfelelő átalakító használatával az asztali számítógépünkbe. Miután ezzel megvagyunk, töröljük le a FreeBSD partícióját és tegyük vissza a lemezt. Ekkor a ThinkPad újból működőképes lesz.

Ezt követően az alábbi utasításokat követve tudjuk telepíteni a FreeBSD-t:

A kedves Olvasónak meghagytuk azt az esetet, amikor ugyanezen a konfiguráción OpenBSD és FreeBSD rendszereket akarunk egyszerre használni.

Igen, ez lehetséges, de egyáltalán nem ajánlott.

Manapság ha egy IDE-meghajtón hibás szektorokat találunk, akkor az arra utal, hogy hamarosan tönkremegy (a meghajtó belső átképező funkciói már képesek megbirkózni a rossz szektorok növekvő számával, ami arra enged következtetni, hogy a lemez felülete jelentős mértékben sérült). Ezért inkább egy új merevlemezes meghajtó vásárlását javasoljuk.

Ha hibás SCSI-meghajtónk van, ezt a választ olvassuk el.

Ha olyan furcsa dolgokkal találkozunk a telepítőfloppy használata során, mint például a lemez állandó darálása vagy a rendszer váratlan újraindulása, akkor a következő három kérdést érdemes feltennünk magunknak:

1. Biztos, hogy új, frissen formázott, teljesen hibamentes floppykat használunk (tehát olyanokat, amelyeket egy frissen bontott dobozból vettünk ki, és nem olyanokat, amelyeket valamelyik magazin mellékletéből szedtük ki vagy éppen három évig az ágy alatt tároltunk)?

2. Biztos, hogy bináris (vagy image) módban töltöttük le a lemezek image-eit? (Ne szégyelljük, mindenki életében legalább egyszer töltött már le véletlenül bináris állományt szöveges formátumban!)

3. Windows 95 vagy Windows 98 alatt DOS módban használtuk az fdimage vagy rawrite parancsot? Ezek az operációs rendszerek általában nem férnek össze az olyan programokkal, amelyek közvetlenül a hardverrel akarnak kommunikálni, amire a lemezek írásához is szükség van. Ez a probléma leginkább akkor merülhet fel, amikor a grafikus felületen belül egy DOS ablakban futtatjuk ezeket a programokat.

Kaptunk olyan visszajelzést is, hogy gondjaink lehetnek, ha Netscape®-pel töltjük le a rendszerindító lemezeket, ezért lehetőség szerint igyekezzünk más FTP klienst használni.

Ezt a problémát általában egy rosszul beállított CD-meghajtó okozza. A CD-meghajtó rengeteg számítógépben a másodlagos IDE-vezérlő slave (szolga) portján található, a master (mester) port használata nélkül. Ez az ATAPI specifikációi szerint nem szabályos, de a Windows ezzel különösebben nem törődik, a BIOS pedig egyszerűen figyelmen kívül hagyja a rendszer indítása során. Ezért képes a BIOS ilyenkor látni a CD-meghajtót, és ezért nem képes a FreeBSD teljes telepítésnél használni.

Ezen úgy tudunk segíteni, ha a CD-meghajtónkat az IDE-vezérlőn átállítjuk masterre, vagy arra az IDE-vezérlőre teszünk egy master eszközt.

Igen. Ehhez csupán egy szabványos Laplink-kábel kell. Amennyiben szükséges, a párhuzamos vonali hálózatkezelés beállításához olvassuk el kézikönyv PLIP-ről szóló részét.

Megjegyzés: A lemez “geometriája” alatt a lemezen található cilinderek, fejek és a sávonkénti szektorok számát értjük. Ezt a továbbiakban csak CHS-értéknek nevezzük (mint Cylinder/Head/Sector). Ebből állapítja meg a PC-s BIOS, hogy a lemezen honnan kell olvasnia és hova kell írnia.

Ez rengeteg félreértést okoz az újdonsült rendszergazdák számára. Először is megemlítenénk, hogy egy SCSI-lemez fizikai geometriája ebben az esetben teljesen lényegtelen, mivel a FreeBSD lemezblokkokban gondolkozik. Igazából nem létezik “a” fizikai geometria fogalma, ugyanis a szektorok sűrűsége a lemezen felületén belül sem állandó. Amit a gyártók általában “fizikai geometriának” hívnak, az általában az a geometria, amely a legkevesebb helyveszteséggel jár. Az IDE-lemezek esetében a FreeBSD ugyan CHS-értékekkel dolgozik, de ezt minden modernebb meghajtó legbelül blokkhivatkozásokká alakítja.

Egyedül tehát a logikai geometria számít. Ez a válasz, amikor a BIOS megkérdezi a meghajtónkat: “Mik a geometriai beállításaid?”, és ennek felhasználásával kommunikál vele a későbbiekben. Mivel a FreeBSD is ezt az értéket használja fel a rendszer indításánál, fontos, hogy jól adjuk meg. Ez különösen abban az esetben számít, amikor több operációs rendszer is található a lemezen, hiszen mindegyiküknek azonos geometriai beállításokat kell használniuk. Ellenkező esetben komoly gondok léphetnek fel a rendszer indítása során!

A SCSI-lemezek esetében a beállítandó geometria értéke attól függ, hogy a vezérlőn használjuk-e a bővített fordítás támogatását (extended translation support, amelyet gyakran csak úgy neveznek, hogy “Support for DOS disks >1GB” vagy ehhez hasonlóan). Ha ezt letiltottuk, akkor használjuk az N cilinder, 64 fej és 32 szektor sávonkénti felírást, ahol N a lemez MB-okban számított mérete. Így például egy 2 GB méretű lemez geometriai beállítása 2048 cilinder, 64 fej és 32 szektor sávonként.

Ha viszont engedélyeztük (ami gyakran előfordul, mivel így lehet az MS-DOS® bizonyos korlátozásait megkerülni) és a lemez kapacitása 1 GB-nál több, adjunk meg M cilindert, 255 fejet, 63 (és nem 64) szektort sávonként, ahol az M a lemez MB-okban mért kapacitása osztva 7,844238-al (!). Tehát az iménti példában is említett 2 GB-os meghajtó esetében 261 cilindert, 255 fejet és sávonként 63 szektort kapunk.

Ha nem lennénk benne biztosak, vagy a FreeBSD-nek a telepítés közben nem sikerül megállapítania a lemez geometriai beállításait, mi magunk is könnyen meg tudjuk határozni, ha készítünk egy kis méretű DOS partíciót a lemezen. A BIOS ekkor észlelni fogja a megfelelő geometriai beállításokat, és ha már nincs rá tovább szükségünk, akkor a partíciószerkesztőben nyugodtan törölhetjük. Hálózati kártyák és hasonló hardverek programozásához azonban még a későbbiekben hasznos lehet.

Használhatjuk viszont a FreeBSD-hez mellékelt pfdisk.exe segédprogramot is. Ezt a FreeBSD CD vagy a FreeBSD FTP oldalainak tools könyvtárában találhatjuk meg. Ennek a programnak a segítségével ki tudjuk deríteni, hogy a lemezen levő többi operációs rendszer milyen geometriai beállításokat használ. Az így kapott értékeket fel tudjuk használni a partíciószerkesztőben.

Igen. A rendszerindításhoz használt (gyökér)partíciónak az 1024. cilinder alatt kell kezdődnie, mivel a BIOS csak így képes betölteni onnan a rendszermagot. (Ez a korlátozás a PC-s BIOS-ok miatt van, nem a FreeBSD miatt.)

A SCSI-lemezek esetében ez általában azt jelenti, hogy rendszerindításhoz használt partíciónak az első 1024 MB alatt kell kezdődnie (vagy az első 4096 MB alatt, ha a bővített fordítást is engedélyeztük — lásd az előző kérdést). Az IDE-lemezek esetében ez 504 MB-nak felel meg.

A FreeBSD felismeri az Ontrack Disk Managert és figyelembe veszi. A többi disk managert nem támogatja.

Ha egyedül csak a FreeBSD-t akarjuk használni, akkor nincs szükségünk disk managerre. Egyszerűen csak állítsunk be egy akkora méretű lemezt, amivel a BIOS képes még megbirkózni (a határ általában 504 MB) és majd a FreeBSD kideríti, hogy valójában mennyi hely áll a rendelkezésére. Ha régebbi gyártmányú merevlemezünk van MFM-vezérlővel, akkor a FreeBSD-nek konkrétan meg kell mondanunk, hogy mennyi cilindert használhat.

Ha a FreeBSD mellett más operációs rendszereket akarunk használni, akkor ezt disk manager nélkül is megtehetjük. Egyedül arra kell vigyáznunk, hogy a FreeBSD indításához használt partíció és a másik operációs rendszer slice-a az első 1024 cilinder alatt kezdődjön. Ha nagyon körültekintőek akarunk lenni, akkor erre a célra egy 20 MB méretű rendszerindító partíció tökéletesen megfelel.

Ez általában akkor fordul elő, amikor a FreeBSD és a DOS vagy más operációs rendszerek nem értenek egyet a lemez geometriai beállításaiban. Telepítsük újra a FreeBSD-t és ezúttal figyelmesen kövessük a fentebb adott utasításokat!

Ez az előbbi kérdéssel kapcsolatos probléma egy másik tünete: a BIOS és a FreeBSD által használt geometriai beállítások nem egyeznek! Amennyiben a vezérlő vagy a BIOS támogatja a cilinderek fordítását (amelyet gyakran “>1GB driver support” néven találhatunk meg), akkor próbáljuk meg átállítani és így újratelepíteni a FreeBSD-t.

Alapvetően nem. Ettől függetlenül azonban javasoljuk legalább a base források telepítését, ahol számos olyan állomány megtalálható, amelyekre a későbbiekben még hivatkozni fogunk, valamint a sys (rendszermag) források telepítését, amelyben a rendszermag forrásai találhatóak. A rendszeren belül azonban a működéshez semmi sem igényli közvetlenül a források jelenlétét, egyedül talán a rendszermag beállítását végző config(8) program. A rendszermag forrásainak kivételével a rendszerben a fordítás menetét úgy építettük fel, hogy akár egy írásvédett módon csatlakoztatott NFS állományrendszerről is képes legyen dolgozni (a rendszermag forrásaira vonatkozó megszorítások miatt azonban azt javasoljuk, hogy ezt közvetlenül ne a /usr/src könyvtárba csatlakoztassuk, hanem egy másik helyre, ahol aztán szimbolikus linkek segítségével másoljuk le a forráskód könyvtárszerkezetének legfelső szintjét).

Ha kéznél vannak a források és tisztában vagyunk a rendszerfordítás folyamatával, akkor a későbbiekben sokkal könnyebben tudjuk a FreeBSD rendszerünket frissíteni.

A források egyes részeinek kiválasztásához lépjünk be a telepítőprogram Custom (Egyéni telepítés), majd a Distributions (Terjesztések) menübe.

Egy új rendszermag fordítása korábban fontos része volt a FreeBSD telepítésének, de a legújabb kiadások már kihasználják a rendszermag beállításának sokkal baratságosabb módszereit is. A FreeBSD 5.X és az azt követő változatokban már a betöltőből könnyen be tudjuk állítani a rendszermagot a beépített “hints” (eszközökre vonatkozó útmutatások) módszere által felkínált rugalmasabb lehetőségeknek köszönhetően.

Egy új rendszermag készítése viszont olyan esetekben még továbbra is hasznos lehet, amikor csak azokat a meghajtókat akarjuk megtartani benne, amelyekre ténylegesen szükségünk van. Ezzel többnyire memóriát tudunk megspórolni, habár a legtöbb rendszer esetében erre igazából nincs szükségünk.

A FreeBSD alapértelmezés szerint MD5-alapú jelszavakat használ. Ezeket a DES algoritmuson alapuló hagyományos UNIX-os jelszavaknál sokkal megbízhatóbbnak tartják. A DES formátum természetesen továbbra is elérhető olyan esetekben, amikor a kevésbé biztonságos jelszavakat használó régi operációs rendszerekkel akarunk együttműködni. Emellett a FreeBSD-ben lehetőségünk van a sokkal biztonságosabb Blowfish jelszóformátum használatára is. Az új jelszavak formátumát az /etc/login.conf állományban található passwd_format bejelentkezési tulajdonság adja meg, amelynek értéke des, blf (amennyiben elérhető), illetve md5 lehet. A bejelentkezési tulajdonságokkal kapcsolatban a login.conf(5) man oldalt érdemes elolvasni.

Ha a rendszerünkhöz IDE-s Zip® vagy Jaz® meghajtót csatlakoztattunk, akkor próbálkozzunk újra az eltávolítása után. A rendszerindító floppy ugyanis hajlamos összekeverni a meghajtókat. A rendszer telepítése után természetesen újra csatlakoztathatjuk a meghajtót. Ezt remélhetőleg egy következő verzióban már kijavítják.

Ez a hiba a rendszerindító blokk és a rendszermag közti félreértésből, a lemezes eszközök helytelen kezeléséből fakad. Ilyen hibát általában olyan rendszerekben kapunk, ahol két masternek beállított IDE-lemez található vagy ha az egyes IDE-vezérlőkre csak egy-egy eszközt csatlakoztattunk és a FreeBSD-t a másodlagos IDE-vezérlőre kapcsolódó lemezre telepítettük. Ekkor a rendszerindító blokk szerint a rendszert az ad0 (de a BIOS-ban a második) lemezre telepítettük, miközben a rendszermag szerint ez a másodlagos IDE-vezérlőn elhelyezkedő első lemez, az ad2. Az eszközök felkutatása után a rendszermag megpróbálja a rendszerindító blokk által nyilvántartott eszközről, az ad0 lemezről csatlakoztatni a rendszerindító partíciót, ami viszont számára a ad2 eszköz lesz, így ez a próbálkozása meghiúsul.

Ezt a félreértést a következő módokon lehet helyretenni:

1. Indítsuk újra a rendszert és nyomjuk le az Enter billentyűt, amikor a Booting kernel in 10 seconds; hit [Enter] to interrupt szöveg megjelenik. Ezzel a rendszerbetöltő parancssorába kerülünk.

   Ezután gépeljük be a set root_disk_unit="lemezszám" sort. Itt a lemezszám értéke 0 lesz, ha a FreeBSD-t az elsődleges IDE-vezérlő master portján levő merevlemezre telepítettük, 1, ha az elsődleges IDE-vezérlő slave portjára, 2, ha a másodlagos IDE-vezérlő master portjára, és végül 3, ha a másodlagos IDE-vezérlő slave portjára.

   Most már begépelhetjük, hogy boot, és így a rendszernek el is kell indulnia.

   Ha ezt a változtatást véglegesíteni akarjuk (vagyis nem akarjuk ugyanezt eljátszani a FreeBSD minden egyes indítása során), akkor a /boot/loader.conf.local állományba vegyünk fel a root_disk_unit="lemezszám" sort.

2. Tegyük át a FreeBSD-t tartalmazó lemezt az elsődleges IDE-vezérlőre, és ezzel megszűnik az iménti félreértés.

A memóriára vonatkozó korlátozások platformonként változnak. Egy szabványos i386 telepítés esetén például ez a határ 4 GB, de pae(4) segítségével akár még ennél több is elérhető. Ehhez olvassuk el az i386 platformon 4 GB-nál több memória használatára vonatkozó utasításokat.

A FreeBSD/pc98 esetén a korlát szintén 4 GB, azonban itt a PAE nem használható. A FreeBSD által támogatott összes többi architektúra elméletileg ennél több memóriát képes kezelni (több terabyte-ot).

Az FFS állományrendszerek méretének elméleti határa 8 TB (2 milliárd blokk), illetve az alapértelmezett 8 KB-os blokkméret esetén 16 TB. A gyakorlatban azonban szoftveresen ebből 1 TB használható ki, de kisebb módosításokkal akár 4 TB-os állományrendszer is használható (és létezik).

Egyetlen FFS állományrendszerbeli állomány mérete megközelítőleg legfeljebb 1 milliárd blokk lehet, ami 4 KB-os blokkmérettel számolva 4 TB-ot jelent.

4 KB-os blokkméret esetén a háromszoros indirekcióval származtatott blokkok a gyakorlatban is kihasználhatóak, és az egészet elméletben egyedül csak az állományrendszerben így ábrázolható blokkok maximális száma korlátozná (ami kb. 1024³ + 1024² + 1024), azonban a gyakorlatban ezt az állományrendszeri blokkokra vonatkozó 1 GB - 1 méretű (rossz) határ korlátozza. Az állományrendszeri blokkok számát ugyanis ki kellene terjeszteni a 2 GB - 1 méretig. 2 GB - 1 számú blokk használata körül jelentkezik ugyan néhány hiba, de ezek 4 KB-os blokkméret esetén nem is érhetőek el.

A 8 KB-nál nagyobb blokkméretek esetén mindenre a blokkok 2 GB - 1 maximális mennyisége érvényes, de a gyakorlatban ezt a blokkok számának 1 GB - 1 határa korlátozza. Az eredeti 2 GB - 1 mennyiségű blokk használata gondokat okozhat.

Mert a rendszermag és a felhasználói programok verziója eltér. A rendszermag frissítésekor feltétlenül használjuk a make buildworld és a make buildkernel parancsokat is!

A rendszerindítás második fokozatában közvetlenül meg tudjuk adni a betöltendő rendszermagot, ha a betöltő indítása előtt, a | jel megjelenésekor lenyomunk egy billentyűt.

Próbáljuk meg letiltani az ACPI támogatást. Ezt úgy tudjuk megtenni, hogy amikor a rendszertöltő elindul, lenyomjuk a Szóköz billentyűt. Ekkor a következőt kapjuk:

OK

Itt gépeljük be az alábbi parancsot:

unset acpi_load

Majd ezt:

boot

A válasz nagy valószínűséggel a fizikai és virtuális memóriacímek közti különbségben rejlik.

A legtöbb PC-s hardvereszköz megegyezés szerint a 3,5 GB és 4 GB közti memóriaterületet speciális célokra tartja fenn (általában a PCI számára). Ezen a címterületen keresztül éri a PCI eszközöket. Ennek egyik következménye, hogy a fizikai memória ezen a részen nem érhető el.

Hogy pontosan mi történik az itt elhelyezkedő memóriával, teljesen a hardvertől függ. Sajnálatos módon bizonyos eszközök semmilyen megoldást nem nyújtanak a problémára, és így lényegében az utolsó 500 MB-nyi memória elveszik.

Szerencsére a legtöbb eszköz azonban képes ezt a területet egy felsőbb címre leképezni, így ki tudjuk használni. Ilyenkor azonban tapasztalhatunk némi félreértést, amikor megnézzük a rendszerindítás közben megjelenő üzeneteket.

A FreeBSD 32 bites változata esetén ez a memóriaterület elveszik, mivel a címe a 4 GB-os határ felé kerül, amelyet a 32 bites módban futó rendszermag már nem képes elérni. Ezen egy PAE támogatással rendelkező rendszermag használatával segíthetünk. A GYIK-on belül ebben a bejegyzésben olvashatunk bővebben a memóriakorlátokról, valamint ebben a részben láthatjuk a különböző platformokra vonatkozó memóriakorlátozásokat.

A FreeBSD 64 bites változata vagy a PAE használata esetén azonban a FreeBSD rendesen felismeri és leképezi a fennmaradó memóriaterületeket, így azok használhatóvá válnak. A rendszerindítás során azonban az előbb említett leképezés miatt látszólag úgy fog tűnni, mintha a FreeBSD több memóriát észlelne, mint amennyivel valójában rendelkezünk. Ez teljesen normálisnak tekinthető és a ténylegesen elérhető memória mennyisége a folyamat végén be fog állítódni.

A SCSI-meghajtók esetében a meghajtó általában képes önmagától átképezni az ilyen szektorokat. A legtöbb meghajtóban ez a lehetőség viszont alapból nem engedélyezett.

A hibás szektorok átképezéséhez az eszköz első lapmódját kell átírnunk, amelyet (root felhasználóként) így tehetünk meg:

# camcontrol modepage sd0 -m 1 -e -P 3

Változtassuk meg az AWRE (az írás automatikus átképzése) és ARRE (az olvasás automatikus átképzése) beállítások értékeit 0-ról 1-re:

AWRE (Auto Write Reallocation Enbld):  1
ARRE (Auto Read Reallocation Enbld):  1

A modernebb IDE-meghajtók is képesek a vezérlőjükkel nyilvántartani az időközben meghibásodott szektorokat, és ezt általában alapból engdélyezik.

Ha rossz szektorokra figyelmeztető hibaüzeneteket látunk (akármilyen típusú meghajtónk is legyen), az kétségtelenül arra utal, hogy ideje lecserélnünk a hardvert. A hibás szektorok használatát esetleg a gyártó saját diagnosztikai programjával le tudjuk tiltani, de hosszabb távon mindenképpen az lesz a legjobb, ha veszünk egy újat.

Ez tulajdonképpen egy ismert probléma. A HP Netserver gépekben egy integrált EISA buszos SCSI-vezérlő található, amely a 11-es EISA bővítőhelyen található, ezért az összes “valódi” EISA bővítőhely ez előtt helyezkedik el. Sajnos a 10 feletti EISA bővítőhelyek címei ütköznek a PCI eszközök számára kiosztott címekkel, ezért a FreeBSD önmagától nem tudja valami jól kezelni az ilyen helyzeteket.

Ezért a legjobban akkor járunk, ha egyszerűen letagadjuk a címterek ütközését :) Ezt úgy tudjuk megtenni, ha a rendszermag EISA_SLOTS nevű beállítását a 12 értékre állítjuk. Ezután már csak be kell konfigurálunk és újra kell fordítanunk a rendszermagot, ahogy azt a kézikönyv megfelelő része is tárgyalja.

Természetesen, amikor egy ilyen gépre akarunk telepíteni, a helyzet tovább bonyolódik. A telepítést úgy tudjuk megoldani, ha a UserConfig programon belül alkalmazunk egy apró trükköt. Most ne a “vizuális” felületét használjuk, hanem a parancssoros részt. Gépeljük be, majd a megszokottak szerint telepítsük a rendszert:

eisa 12
quit

Ettől függetlenül természetesen továbbra is javasolt egy, az előbbiek szerint módosított rendszermagot fordítanunk és telepítenünk.

A következő verziókban remélhetőleg már lesz valamilyen megoldás erre a problémára.

Ezt a hibát általában a megszakítások ütközése okozza (például két kártya ugyanazt a megszakítást akarja használni). Indítsuk a rendszerünket a -c beállítás használatával és az ed0/de0/... bejegyzéseket változtassuk meg a kártyáknak megfelelően.

Ha a hálózati kártyánkon BNC típusú csatlakozó található, akkor még előfordulhat, hogy azért látunk ilyen hibaüzeneteket, mert nem jól zártuk le a csatlakozást. Ezt úgy tudjuk könnyen ellenőrizni, ha a lezárót közvetlenül a kártyára dugjuk rá (kábel nélkül) és figyeljük, hogy továbbra is jönnek-e a hibaüzenetek.

Egyes NE2000-kompatibilis kártyák akkor adják ezt a hibát, ha az UTP portjukon nincs aktív összeköttetés vagy nem dugtuk be a kábelt.

Az ilyen típusú kártyák néha hajlamosak elfelejteni a beállításaikat. Frissítsük a kártya beállításait a 3c5x9.exe program segítségével.

Ha csupán annyi a problémánk, hogy a nyomtató irdatlanul lassan működik, akkor próbáljuk meg a kézikönyv nyomtatásról szóló részében leírtakhoz hasonlóan átállítani a nyomtató portkezelését.

Ezek a hibák akkor keletkeznek, amikor a futó programok olyan memóriaterülethez próbálnak meg hozzáférni, amihez eredetileg nem lenne szabad. Ha valami ehhez hasonló történik a rendszerünkben látszólag teljesen véletlenszerűen, akkor nagyon óvatosan kezdjünk el vizsgálódni.

A lehetséges okok az alábbiak lehetnek:

1. Ha csak olyan alkalmazások esetében jelentkezik ez a hiba, amelyeket mi magunk fejlesztünk, akkor az valószínűleg arra utal, hogy valamelyik része hibásan működik.

2. Ha a FreeBSD alaprendszerének valamelyik részében tapasztalunk ilyen hibákat, akkor azt szintén okozhatja hibás kód, de az ilyen hibákat általában hamarabb meg szokták találni és ki szokták javítani, mint ahogy a GYIK-ot olvasók többsége találkozna velük (a -CURRENT ág pontosan ezt a célt szolgálja).

Előfordulhat, hogy ez egy olyan furcsaság eredménye, amely nem a FreeBSD hibája: például ugyanazon program fordításakor mindig mást csinál a fordítóprogram.

Például tegyük fel, hogy a make buildworld parancsot futtatjuk, és a fordítás félbeszakad, amikor az ls.c állományból el akarja készíteni az ls.o állományt. Ha ezután megint megpróbáljuk kiadni a make buildworld parancsot, akkor a fordítás ugyanazon a helyen újból meghiúsul — valószínűleg hibás a forráskód, frissítsük a forrásainkat és próbáljuk meg ismét. Ha viszont a fordítás ilyenkor már egy másik helyen akad el, akkor szinte biztos, hogy hardverhibával akadtunk össze.

Amit ilyenkor tenni tudunk:

Az első esetben egy nyomkövető, például a gdb(1) segítségével keressük meg a program azon pontját, ahol rossz memóriaterülethez próbál meg hozzáférni és javítsuk ki.

A második esetben ellenőrizzük, hogy nem a hardver a hibás.

Ennek okai többek közt a következők lehetnek:

1. Túlmelegednek a merevlemezeink: ellenőrizzük, hogy a gépben található ventillátorok rendesen működnek-e (persze előfordulhat, hogy más eszközök melegednek túl).

2. A processzor túlmelegedett: lehet, hogy mert túlságosan nagy órajelen járatjuk, vagy mert egyszerűen leállt a hűtése. Akármelyik eset is következett be, legalább a hiba felderítéséig állítsuk vissza a hivatalos sebességére.

   Ha feltétlenül ragaszkodunk a rendszerünk tuningolásához, akkor érdemes elgondolkoznunk azon, hogy egy lassabb rendszerrel jobban járunk, mint egy állandóan cserélendő, ropogósra sült rendszerrel. Az emberek általában nem is nagyon szeretik az ilyen rendszereket, független attól, hogy szerintünk érdemes-e ilyet csinálni vagy sem.

3. Hibás memóriamodulok: ha több SIMM és DIMM modul is található a gépünkben, akkor vegyük ki az összeset és próbáljuk ki mindegyiket egyesével, ezzel is leszűkíthetjük a probléma felderítését a hibás DIMM/SIMM modulokra vagy azok kombinációjára.

4. Az alaplap túlbecslő értékei: a BIOS beállításai között vagy az alaplapon található jumperekkel szabályozni tudjuk a különböző időzítéseket, ahol általában az alapértelmezett értékek megfelelnek, de néha előfordulhat, hogy a memóriamodulok késleltetését lassúra, vagy éppen turbó sebességre állítják (“RAM Speed: Turbo” vagy ehhez hasonló néven keressük a BIOS-ban), ami szintén okozhat furcsa viselkedést. Próbáljuk meg visszaállítani az BIOS alapértelmezett értékeit, de előtte érdemes lejegyezni az aktuális beállításainkat.

5. Az alaplap zajos vagy kevés áramot kap: ha vannak használaton kívüli I/O kártyáink, merevlemezeink, CD-meghajtóink a rendszerünkben, akkor próbáljuk meg ideiglenesen eltávolítani ezeket vagy egyszerűen csak lehúzni róluk a tápkábelt. Ezzel tudjuk vizsgálni, hogy a számítógépünk tápegysége képes-e megbirkózni a kisebb terheléssel. Esetleg kipróbálhatunk egy másik tápegységet is, lehetőleg egy kicsivel erősebbet (például ha a jelenlegi tápegységünk teljesítménye 250 watt, akkor használjunk helyette egy 300 wattosat).

Továbbá érdemes lehet még elolvasnunk a SIG11 GYIK-ot (lásd lentebb), ahol mindezeket a problémákat részletesen kifejtik, noha a Linux® nézőpontjából. Arról is olvashatunk benne, hogy egy hibás memóriát miért nem képesek észlelni a szoftveres vagy hardveres tesztelőeszközök.

Végezetül, ha az egyik javaslat sem segített a probléma megoldásában, akkor valószínűleg sikerült hibát találnunk a FreeBSD kódjában, amiről nyugodtan írhatunk a fejlesztőknek egy hibajelentést.

A problémáról minden részletre kiterjedő módon A SIG11-es probléma GYIK-ja írásban olvashatunk (angolul).

A FreeBSD fejlesztői nagyon kíváncsiak az ilyen hibákra, de a felderítéséhez sajnos jóval több információra van szükségük, mint amennyit láthattunk. Másoljuk le az összeomláshoz tartozó teljes üzenetet. Ezután nézzük meg a GYIK-nak azt a részét, amely a rendszermag összeomlásáról szól, készítsünk egy nyomkövetési információkkal ellátott rendszermagot és kérjük le a hívási láncot. Ez elsőre talán bonyolultnak hangzik, de ehhez igazából nem igényel semmilyen programozási tudást, egyszerűen csak a megadott utasításokat kell követnünk.

Ez az ATI Mach 64 videokártyák esetében jelentkező probléma. Ilyenkor az a gond, hogy a kártya a 0x2e8 címet használja, akárcsak a negyedik soros port. A sio(4) meghajtóban levő hiba (vagy netalán beállítás?) miatt azonban a negyedik soros portot még akkor is használni fogja, ha kikapcsoljuk a sio3 (a negyedik soros port) eszközt.

A hibát kijavításáig így kerülhetjük meg:

1. A betöltő parancssorában adjuk meg a -c paramétert. (Így elő tudjuk hozni a rendszermag konfigurációs módját.)

2. Kapcsoljuk ki a sio0, sio1, sio2 és sio3 eszközöket (tehát mindegyiket). Emiatt a sio(4) meghajtó nem indul el, és így nem okoz problémát.

3. Lépjünk ki és folytassuk a rendszer indítását.

Ha a soros portokat is használni akarjuk, akkor következő módosításokkal készítsünk egy új rendszermagot: a /usr/src/sys/dev/sio/sio.c (vagy pc98 esetén a /usr/src/sys/pc98/cbus/sio.c) állományban keressük meg a 0x2e8 karakterláncot és az azt megelőző vesszőt távolítsuk el (de az utána következőt tartsuk meg). Miután végrehajtottuk ezt a módosítást, a megszokott módon fordítsuk újra a rendszermagot.

Mivel FreeBSD a BIOS-tól próbálja megtudni a rendelkezésre álló memória méretét, ezért csak 16 biten képes lekérdezni a KB-okban (vagyis 65 535 KByte = 64 MB, vagy még ennél is kevesebb, mivel egyes BIOS-ok legfeljebb 16 MB memóriát engednek látni). Tehát ha 64 MB-nál több memóriával rendelkezünk, akkor a FreeBSD ugyan megpróbálja azt felderíteni, de nem feltétlenül fog sikerülni.

Ezt úgy tudjuk megoldani, ha a rendszermag alábbi beállítását használjuk. Alapvetően ugyanis létezik egy módszer, amivel le lehet kérdezni a memória teljes méretét a BIOS-tól, de a hozzá tartozó rutin nem fért el a rendszerindító blokkban. Ha egyszer majd sikerül neki helyet csinálni, akkor a rendszer képes lesz kizárólag ezzel a módszerrel dolgozni. Amíg viszont ez nem így van, addig kénytelenek leszünk a most következő megoldást választani:

options MAXMEM=N

ahol N a memória Kilobyte-okban megadott mérete. Tehát egy 128 MB memóriával rendelkező számítógép esetén ez 131072.

A FreeBSD általában a rendszermag néhány fontos paraméterét, mint például az egyszerre megnyitható állományok maximális számát a számítógépben található memória méretéből származtatja. Az 1 GB memóriánál több esetén azonban elképzelhető, hogy ez az “automatikus méretezés” túlságosan is nagy értékeket választ. Így a rendszer indításakor a rendszermag olyan nagy méretű táblázatokat és egyéb struktúrákat foglal le, amelyek betöltik a rendelkezésére bocsátott terület nagy részét. Később, a rendszer futása közben pedig a rendszermag szépen lassan kifogy a dinamikus memóriaterületekből és összeomlik.

Készítsünk egy olyan saját rendszermagot, ahol a VM_KMEM_SIZE_MAX beállítást megnöveljük egészen a maximális 400 MB-os értékig (options VM_KMEM_SIZE_MAX=419430400). 400 MB használata valószínűleg elég lesz egészen 6 GB memóriáig.

Ez a hibaüzenet arra utal, hogy a rendszer kifogyott a hálózati pufferek (különösen az mbuf klaszterek) számára kiosztott virtuális memóriából. Az mbuf klaszterek részére fenntartott virtuális memória méretének beállításáról a kézikönyv Hálózati korlátozások című szakaszában olvashatunk.

A FreeBSD rendszermagja egyszerre csak bizonyos számú programot enged futni. Ezek konkrét száma a kern.maxusers sysctl(8)-változótól függ. A kern.maxusers ezenkívül még hatással van más belső korlátokra is, például a hálózati pufferekre (lásd ezt a korábbi kérdést). Ha a számítógépünk túlságosan leterhelt, akkor érdemes megpróbálkoznunk a kern.maxusers értékének növelésével. Ennek átállítása a rendszerben egyszerre futtatható maximális programok számával együtt sok más rendszerszintű korlátozást is finomít.

A kern.maxusers értékének beállításához nézzük meg a kézikönyv Az állományok és futó programok korlátozásairól szóló szakaszát. (Miközben ez a rész a megnyitható állományok maximális számáról szól, addig ugyanez érvényes a futó programokra is.)

Ha viszont a számítógépünk nem éri akkora terhelés, de mégis szeretnénk egyszerre nagyobb számú programot is futtatni rajta, akkor ehhez elegendő csak kern.maxproc változót átállítanunk. Ezt úgy tudjuk megtenni, ha felvesszük a /boot/loader.conf állományba. Ez az érték természetesen addig nem beállítódni, amíg a rendszerünket újra nem indítjuk. Ezekről a változókról a loader.conf(5) és sysctl.conf(5) man oldalakon tájékozódhatunk részletesebben. Ha az összes programot egyetlen felhasználóval akarjuk futtatni, akkor a kern.maxprocperuid változót értékét is át kell állítanunk, méghozzá a kern.maxproc új értékénél eggyel kisebbre. (Ezért kell így csinálni, mert egy rendszerprogram, az init(8) mindig fut.)

A sysctl változók beállításait úgy is tudjuk véglegesíteni, ha felvesszük ezeket az /etc/sysctl.conf állományba. A kézikönyv A rendszermag korlátainak finomhangolása című szakaszában részletesebb is olvashatunk róla, hogy miként állítsuk be a rendszerünket.

Az elavult /var/db/kvm_*.db állományokat összegyűjtő rutin időnként nem működik megfelelően, és a nem egyező állományok esetén össze is omolhat.

Amikor ilyen történik, indítsuk újra a rendszert egyfelhasználós módban és gépeljük be:

# rm /var/db/kvm_*.db

Ez az Ultrastor SCSI vezérlőkártya ütközésére utal.

A rendszerindítás közben lépjünk be a rendszermag konfigurációs menüjébe és tiltsuk le a gondot okozó uha0 eszközt.

Az alaplapon nem található olyan áramkör, amely támogatja az automatikus lezárást (“automatic termination”). A SCSI BIOS-ban az automatikus lezárás helyett adjuk meg a megfelelő lezárást. Az ahc(4) meghajtója nem képes rendesen érzékelni a kábeleket, ha az alaplapon van ilyen érzékelés (és így automatikus lezárás). A meghajtó egyszerűen annyit feltételez, hogy ennek támogatása csak akkor érhető el, ha az EEPROM-ban megadtuk az “automatic termination” beállítást. A megfelelő kábeldetektáló eszköz nélkül a meghajtó gyakran rosszul állapítja meg a lezárást, ami pedig így veszélyezteti a SCSI busz megbízhatóságát.

Erről részletesebben a kézikönyvben olvashatunk.

Előfordulhat, hogy az adott távoli gépen a terminál típusa nem cons25, amire viszont a FreeBSD konzolnak a megfelelő működéshez szüksége lenne.

Ezt a problémát többféle módon is meg tudjuk kerülni:

• Mikor bejelentkezünk a távoli gépre, állítsuk a TERM környezeti változót az ansi vagy sco értékre, amiből kiderül, hogy egyáltalán ismeri ezeket a termináltípusokat.

• A FreeBSD konzolban használjunk VT100 emulátort, például a screen alkalmazást. A screen segítségével egyetlen terminálról egyszerre több munkamenetet is tudunk indítani, de egyébként is egy nagyon jó program. Minden screen által létrehozott ablak VT100-as terminálként működik, ezért a távoli gépen a TERM környezeti változó nyugodtan beállítható a vt100 értékre.

• Tegyük hozzá a cons25 bejegyzést a távoli gép terminálokat tároló adatbázisához. Ez pontos módszere jelentős mértékben függ az adott gépen található operációs rendszertől. Ebben leginkább az adott gépen található man oldalak tudnak segíteni.

• Indítsunk el a FreeBSD rendszert futtató gépen egy X szervert és a távoli gépről egy X rendszerre íródott terminálemulátorral, például az xterm vagy az rxvt programmal jelentkezzük be. A távoli gépen ekkor a TERM változó értéke vagy xterm, vagy pedig vt100 lesz.

Ennek az okait a következő levélben fejtette ki Peter Wemm <peter@FreeBSD.org> a FreeBSD general questions levelezési lista tagjainak, amelyben arra válaszolt, hogy egy belső modemet miért nem észlel a rendszer miután frissítették FreeBSD 4.X-re (az érthetőség kedvéért szögletes zárójelek között hozzáadtunk néhány kiegészítést is).

A PNP BIOS beállította [a modemet] és magára hagyta valahol a portok számára fenntartott címtérben, így az ISA eszközök régi típusú [3.X-ben levő] eszközpróbálgatásai ott “találták” meg.

A 4.0 esetében azonban az ISA eszközöket kezelő kód már sokkal inkább a PnP támogatására koncentrál. Korábban [a 3.X verziókban] előfordulhatott az is, hogy az ISA eszközök keresése során a rendszer egy “kóbor” eszközt talált, majd ugyanazt megtalálta PnP eszközként és ütköztek az így duplán lefoglalni kívánt erőforrások. Ennek kivédésére először tehát letiltjuk a programozható kártyák felderítését, így ez a típusú kettős detektálás nem történhet meg. Ez továbbá azt is jelenti, hogy a támogatott PnP hardverek azonosítóit előre ismerni kell. Ennek hangolhatóságát már tervbevettük.

Tehát egy ilyen eszköz működtetéséhez szükségünk lesz a PnP azonosítójára, valamint arra, hogy felvegyük a felderítendő PnP eszközök ISA eszközök közé. Ezt a pnpinfo(8) segítségével kérhetjük le, amely például egy belső modem esetén a következő kimenetet fogja adni:

# pnpinfo
Checking for Plug-n-Play devices...

Card assigned CSN #1
Vendor ID PMC2430 (0x3024a341), Serial Number 0xffffffff
PnP Version 1.0, Vendor Version 0
Device Description: Pace 56 Voice Internal Plug & Play Modem

Logical Device ID: PMC2430 0x3024a341 #0
        Device supports I/O Range Check
TAG Start DF
    I/O Range 0x3f8 .. 0x3f8, alignment 0x8, len 0x8
        [16-bit addr]
    IRQ: 4  - only one type (true/edge)

[a többi részt kihagytuk]

TAG End DF
End Tag

Successfully got 31 resources, 1 logical fdevs
-- card select # 0x0001

CSN PMC2430 (0x3024a341), Serial Number 0xffffffff

Logical device #0
IO:  0x03e8 0x03e8 0x03e8 0x03e8 0x03e8 0x03e8 0x03e8 0x03e8
IRQ 5 0
DMA 4 0
IO range check 0x00 activate 0x01

Innen a Vendor ID kezdetű sorra lesz szükségünk. A zárójelek között szereplő hexadecimális szám (ami a példában a 0x3024a341) lesz az eszköz PnP azonosítója, valamint a közvetlenül ez előtt szereplő karakterlánc az egyedi ASCII azonosítója (PMC2430).

Ha a pnpinfo(8) lefuttatásának eredményeképpen megjelenő lista nem tartalmazza a kérdéses eszközt, akkor helyette a pciconf(8) használatával is próbálkozhatunk. Íme a pciconf -vl parancs kimenete egy integrált hangkártya esetében:

# pciconf -vl
chip1@pci0:31:5:        class=0x040100 card=0x00931028 chip=0x24158086 rev=0x02 hdr=0x00
    vendor   = 'Intel Corporation'
    device   = '82801AA 8xx Chipset AC'97 Audio Controller'
    class    = multimedia
    subclass = audio

Ebből a chip változót, vagyis a 0x24158086 értéket kell felhasználnunk.

Ezt az információt (a Vendor ID vagy a chip értékét) ezután a /usr/src/sys/dev/sio/sio_isa.c állományba kell felvennünk.

Ehhez először is készítsünk egy biztonsági másolatát a sio_isa.c állományról arra az esetre, ha véletlenül valami rossz történne. Ez azért is hasznunkra fog válni, mert így tudunk egy javítást mellékelni a hibajelentésünk mellé (mert ugye írni fogunk róla hibajelentést, ugye?). Szóval, keressük meg a sio_isa.c állományban a következő sort:

static struct isa_pnp_id sio_ids[] = {

Menjük lentebb egészen addig, amíg nem találunk egy helyet, ahova be tudunk szúrni egy bejegyzést az eszközünkhöz. A bejegyzések megadásának módja lentebb látható, és a jobb oldalt megjegyzésbe tett ASCII Vendor ID szerint rendezettek, amelyek mellett még megtalálható (amennyiben kifér) a pnpinfo(8) Device Description kimenetében kapott érték is:

{0x0f804f3f, NULL},     /* OZO800f - Zoom 2812 (56k Modem) */
{0x39804f3f, NULL},     /* OZO8039 - Zoom 56k flex */
{0x3024a341, NULL},     /* PMC2430 - Pace 56 Voice Internal Modem */
{0x1000eb49, NULL},     /* ROK0010 - Rockwell ? */
{0x5002734a, NULL},     /* RSS0250 - 5614Jx3(G) Internal Modem */

A megfelelő helyre ezután vegyük fel az eszközünkhöz tartozó hexadecimális Vendor ID értéket, mentsük el az állományt, fordítsuk újra a rendszermagot és indítsuk újra vele a rendszerünket. Ha mindent jól csináltunk, akkor az eszköz sio eszközként fog megjelenni.

A gondot alapvetően az okozza, hogy a kérdéses alkalmazás valamiért egy olyan rendszermagbeli szimbólumot keres, amit nem talál. Ez a típusú hiba a következőkből eredhet:

• A rendszermag és a hozzá tartozó programok nincsenek szinkronban (vagyis fordítottunk egy új rendszermagot, de nem volt installworld vagy fordítva) és emiatt a szimbólumokat tároló táblázat nem teljesen úgy épül fel, ahogy azt az alkalmazás gondolja. Ha erről lenne szó, akkor egyszerűen nincs más teendőnk, mint befejezni a frissítést (ennek pontos részleteit lásd a /usr/src/UPDATING állományban).

• Nem a /boot/loader, hanem közvetlenül a boot2 (lásd boot(8)) segítségével töltjük be a rendszermagot. Noha alapvetően semmilyen problémát nem nem okoz a /boot/loader kihagyása, általánosságban véve azért mégis jobban elérhetővé tudja tenni a rendszermagban található szimbólumokat a felhasználói programok felé.

A tünet: nagyon sok idő telik aközött, amíg a TCP kapcsolat felépül és a kliens bekéri a jelszót (vagy a telnet(1) esetében amíg a bejelentkező képernyő megjelenik).

A betegség: nagyon valószínű, hogy a késlekedést az okozza, amikor a szerver megpróbálja a kliens IP-címét feloldani hálózati névvé. Sok szerver, köztük a FreeBSD-ben is megtalálható Telnet és SSH szerver is ezt csinálja, többek közt azért, hogy a rendszergazda számára el tudja tárolni egy naplóban ezt a hálózati nevet.

Az orvosság: ha az említett jelenség minden olyan esetben jelentkezik, amikor a számítógépről (mint kliensről) valamilyen szerverhez csatlakozni akarunk, akkor a kliens oldalán lesz a gond. Ehhez hasonlóan, ha csak egy adott szervernél tapasztaljuk, akkor azzal a számítógéppel történhetett valami.

Amennyiben a problémákat a kliens okozza, nem tehetünk mást, a névoldáson kell úgy javítanunk, hogy a szerver normálisan fel tudja oldani. Ha helyi hálózaton tapasztaljuk mindezt, akkor ez már a szerver problémája és olvassunk tovább. Ellenkező esetben az internet a felelős, ezért nagyon valószínű, hogy fel kell vennünk a kapcsolatot az internet-szolgáltatónkkal és segítséget kérni tőlük a hiba elhárításában.

Ha a problémát viszont a helyi hálózaton található szerver okozza, akkor úgy kell azt beállítanunk, hogy a helyi neveket képes legyen rendesen feloldani. Ezzel kapcsolatban a hosts(5) és named(8) man oldalakat érdemes elolvasnunk. Ha a probléma viszont az interneten jelenik meg, akkor valószínű, hogy a szerver névfeloldása nem üzemel rendesen. Nézzünk meg egy másik gépet — például a www.yahoo.com címet. Ha ez sem működik, akkor nálunk van a gond.

A FreeBSD friss telepítését követően az is elképzelhető, hogy egyszerűen csak hiányoznak a tartományokkal és névszerverekkel kapcsolatos megfelelő adatok az /etc/resolv.conf állományból. Ez gyakran okoz késlekedést az SSH működésében, mivel az /etc/ssh könyvtárban található sshd_config állományban alapértelmezés szerint a UseDNS beállítás értéke yes (tehát a névfeloldás használata engedélyezett). Ha valóban ez okozza a problémát, akkor a pótoljuk az /etc/resolv.conf állományból hiányzó adatokat vagy az sshd_config állományban a UseDNS értéke ideiglenesen legyen no.

A kóbor megszakítási kéréseket jelző üzenetek általában a hardveres megszakítási kérések egyenletlenségeire utalnak, ezen belül is leginkább olyan esetekre, amikor az eszköz egy megszakítási kérés nyugtázása közepén eltávolítja az adott kérést.

Három dolgot tehetünk ezzel kapcsolatban:

• Elviseljük ezeket a figyelmeztetéseket. Megszakítási kérésenként az első öt üzenet után amúgy sem jelez többet a rendszer.

• Ha platformunkhoz (mint például i386) tartozó intr_machdep.c állományban található MAX_STRAY_LOG értékét átírjuk 5-ről 0-ra és így újrafordítjuk a rendszermagot, akkor ezzel teljesen letilthatjuk a figyelmeztetéseket.

• Megszüntetjük az üzeneteket úgy, hogy csatlakoztatunk a rendszerhez egy olyan párhuzamos vonali eszközt, amely a 7-es IRQ-t használja, és rakunk fel hozzá egy PPP meghajtót (a legtöbb helyen egyébként ezzel lesz a gond), valamint a 15-ös IRQ-ra pedig rakunk egy IDE-meghajtót vagy más hasonló eszközt és telepítjük hozzá a megfelelő meghajtót.

Ha ilyen hibaüzenetet látunk, akkor az arra utal, hogy kifogytunk a rendszerünkben egyszerre használható állományleírókból. A probléma leírásával és megoldásával kapcsolatban olvassuk el a kézikönyvben a kern.maxfiles változóról szóló részt A rendszermag korlátainak finomhangolása című szakaszban.

Ismert egy olyan probléma, hogy a BIOS-ban engedélyezzük az Intel Enhanced SpeedStep technológiáját, akkor a rendszermag ehhez hasonló “calcru” üzeneteket kezd el küldözgetni:

calcru: runtime went backwards from 6 usec to 3 usec for pid 37 (pagezero)
calcru: runtime went backwards from 6 usec to 3 usec for pid 36 (vmdaemon)
calcru: runtime went backwards from 170 usec to 138 usec for pid 35 (pagedaemon)
calcru: runtime went backwards from 553 usec to 291 usec for pid 15 (swi6: task queue)
calcru: runtime went backwards from 15521 usec to 10366 usec for pid 2 (g_event)
calcru: runtime went backwards from 25 usec to 12 usec for pid 11 (swi1: net)
calcru: runtime went backwards from 4417 usec to 3960 usec for pid 1 (init)
calcru: runtime went backwards from 2084385 usec to 1793542 usec for pid 1 (init)
calcru: runtime went backwards from 408 usec to 204 usec for pid 0 (swapper)

Ennek oka, hogy az Intel SpeedStep (EIST) egyes alaplapokkal nem kompatibilis.

Megoldás: Tiltsuk le a BIOS-ban az EIST használatát. Ekkor még az ACPI-alapú processzorfrekvencia-szabályozás továbbra is elérhető a powerd(8) használatán keresztül.

A számítógépnek kettő vagy több időmérő eszköze van, és a FreeBSD pont a rosszabbikat választotta.

Adjuk ki a dmesg(8) parancsot és vizsgáljuk meg a Timecounter kezdetű sorokat. Ezek közül a FreeBSD a legnagyobb “quality” értékkel rendelkezőt választotta.

# dmesg | grep Timecounter
Timecounter "i8254" frequency 1193182 Hz quality 0
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
Timecounter "TSC" frequency 2998570050 Hz quality 800
Timecounters tick every 1.000 msec

Erről a kern.timecounter.hardware sysctl(3) változó lekérdezésével tudunk ténylegesen megbizonyosodni:

# sysctl kern.timecounter.hardware
kern.timecounter.hardware: ACPI-fast

Előfordulhat, hogy az ACPI-időzítő hibás. Ilyenkor az a legegyszerűbb, ha az /etc/loader.conf állományban letiltjuk az ACPI-időzítő használatát:

debug.acpi.disabled="timer"

Vagy a BIOS is tudja módosítani a TSC időzítőt — például azért, hogy csökkentse a processzor sebességét, amikor merül az akkumulátor vagy energiatakarékos módra vált. A FreeBSD sajnos nem figyel ezekre a változtatásokra és elcsúszik az időméréssel.

Ahogy viszont az iménti példában is látható, itt még az i8254 időzítő is használható, méghozzá úgy, hogy a kern.timecounter.hardware sysctl(8) változó értékét átállítjuk erre az értékre:

# sysctl -w kern.timecounter.hardware=i8254
kern.timecounter.hardware: TSC -> i8254

Innentől kezdve a számítógépünk már sokkal pontosabban mutatja az időt.

Ezt a változtatást úgy tudjuk minden rendszerindítás során automatikusan megtenni, ha felvesszük a következő sort az /etc/sysctl.conf állományba:

kern.timecounter.hardware=i8254

Ez a probléma gyakran megjelenik olyan laptopokon, amelyek egynél több operációs rendszert is futtatnak, egyes nem-BSD típusú rendszerek ugyanis hajlamosak a hardvert inkonzisztens állapotban hagyni. Emiatt a pccardd(8) parancs az adott kártyát “"(null)""(null)"” néven észleli a valós típusa helyett.

A hardvert innen teljesen csak úgy tudjuk alapállapotába hozni, ha a PC-kártya foglalatát áramtalanítjuk. Ehhez ki kell kapcsolnunk a laptopot. (Tehát ne tegyük se készenléti, se pedig hibernált állapotba — teljesen ki kell kapcsolni.) A PC-kártya ezután várhatóan már működni fog.

Némely laptopok hazudnak arról, hogy rendesen ki vannak-e kapcsolva. Amennyiben az előbbi módszer nem válna be, próbáljuk meg úgy, hogy kikapcsoljuk a gépet, kivesszük az akkumulátort, várunk egy keveset, visszarakjuk és újra bekapcsoljuk.

A FreeBSD rendszertöltője rosszul ismerte fel a merevlemez geometriáját. Ezt a FreeBSD slice-ok létrehozásakor és módosításakor külön meg kell adni az fdisk(8) használatakor.

A meghajtóhoz tartozó megfelelő geometriai beállítások a számítógép BIOS-ában találhatóak. Keressük meg az adott meghajtó cilinder-fej-szektor (Cylinder/Head/Sector) értékét.

A sysinstall(8) partíciószerkesztőjében a G billentyű lenyomásával tudjuk beállítani ezt.

Ekkor egy párbeszédablak jelenik meg, ahol meg tudjuk adni a cilinderek, fejek és a sávonkénti szektorok számát. Ide perjelekkel elválasztva gépeljük e a BIOS-ban talált értékeket. Például ha a merevlemez geometriája 5000 cilinder, 250 fej és sávonként 60 szektor, akkor a 5000/250/60 értéket kell megadnunk.

Az Enter billentyű lenyomására ezek az értékek beállítódnak, és a W lenyomására pedig az új partíciós tábla kiíródik a lemezre.

Indítsuk el a sysinstall(8) programot, majd válasszuk a Configure és Fdisk menüpontokat. A partíciószerkesztőben a Space billentyűvel tudjuk kiválasztani azt a partíciót, amelyen korábban a boot manager volt. Ezután az W billentyű lenyomásával tudjuk a változtatásainkat lemezre menteni. Ekkor egy menü jelenik meg, ahol a telepíteni kívánt rendszertöltőt választhatjuk ki. Adjuk meg és ekkor visszakerül a helyére.

Ez arra utal, hogy egy futó program megpróbált kiírni egy lapot a memóriából a lemezre, azonban 20 másodperce már nem tudott hozzáférni a lemezhez. Ezt okozhatják hibás szektorok a lemezen, a lemez hibás kábelezése vagy esetleg valamilyen lemezműveletekkel kapcsolatos hardver meghibásodása. Amennyiben maga a meghajtó a rossz, akkor az ilyen hibaüzenetek mellett még más, a lemez hibás működésére utaló üzenetet is látnunk kell a /var/log/messages állományban vagy a dmesg kimenetében. Minden más esetben érdemes a meghajtó csatlakozásait és kábelezését ellenőrizni.

A ata(4) meghajtó jelenti ezeket a “UDMA ICRC” hibákat olyan esetekben, amikor a merevlemezre vagy a merevlemezről érkező DMA átvitel hibás. A meghajtó ilyenkor még párszor megpróbálja megismételni a műveletet. Amennyiben ezek a műveletek is meghiúsulnak, a DMA átvitel helyett a lassabb PIO átviteli módra állítja át a merevlemez felé irányuló kommunikációt.

Ezt a problémát több tényező is okozhatja, habár ennek a leggyakoribb oka a hibás vagy rossz kábelezés. Ilyenkor mindig ellenőrizzük, hogy a merevlemezhez csatlakozó ATA-kábelek sértetlenek és a használni kívánt Ultra DMA átviteli módra alkalmasak. Ha cserélhető lemezes meghajtót használunk, akkor kompatibilisnek is kell lenniük. Ez a gond akkor jelentkezhet, amikor ugyanarra az ATA-csatornára egy Ultra DMA 66-os (vagy annál is gyorsabb) és egy régebbi meghajtót csatlakoztatunk. Végezetül ezek a hibaüzenetek arra is utalhatnak, hogy a meghajtó meghibásodott. A legtöbb gyártó külön szoftver ajánl fel ennek vizsgálatára, ezért ilyenkor érdemes letesztelnünk az érintett meghajtót, illetve amennyiben szükséges, biztonsági másolatot készíteni az adatainkról és kicserélni az eszközt.

Az atacontrol(8) segédprogram használatával ellenőrizni tudjuk, hogy jelenleg az egyes ATA-eszközök milyen DMA vagy PIO módban működnek. Erre a célra különösen az atacontrol mode csatorna parancsot javasoljuk, amivel képesek vagyünk megnézni az adott ATA-csatornára csatlakozó eszközök átviteli módjait. Itt a csatorna értéke nullától indul.

Erre a kérdésre a választ a FreeBSD-s szakkifejezések gyűjteményében találjuk meg a LOR címszó alatt.

Ez az üzenet arra utalhat, hogy egy függvény lepihent miközben nála volt egy mutex (vagy más, nem pihentethető) típusú zárolás.

Azért keletkezik ilyen hiba, mert a mutexeket nem úgy tervezték, hogy hosszabb ideig is meg lehessen tartani, kizárólag csak rövid időtartamra vonatkozó szinkronizációt lehet velük végezni. Ez a programozói megegyezés lehetővé teszi az eszközmeghajtók számára, hogy a megszakítások közben mutexek segítségével képesek legyenek szinkronizálni a rendszermag többi részével. A megszakítások (FreeBSD alatt) pedig nem pihenhetnek. Ezért a rendszermagon belül semmilyen olyan alrendszer nem blokkolódhat huzamosabb ideig, amelyik mutexet tart magánál.

Ezeket a hibákat úgy tudjuk elcsípni, ha olyan ellenőrzéseket teszünk a rendszermagba, amelyek jeleznek a witness(4) alrendszernek, hogy küldjön figyelmeztetést vagy akár végzetes hibát (a rendszer konfigurációjától függően) azokban a helyzetekben, amikor egy sejthetően hosszabb ideig blokkolt hívás tart magánál egy mutexet.

Röviden úgy foglalhatnánk össze, hogy ezek a hibák alapvetően nem végzetesek, de egy kis balszerencsével az egyszerű kis megakadásoktól kezdve a teljes lefagyásig szinte bármilyen hibáért felelősek lehetnek.

Ez a hibaüzenet nem azt jelenti, hogy a touch(1) segédprogram nem található, hanem inkább azt, hogy az érintett állományok dátuma a jövőre állítódott be. Ha a CMOS óránkat a helyi idő szerint állítottuk be, akkor egyfelhasználós módban indítsuk újra a rendszert és a adjkerntz -i parancs kiadásával állítsuk be a rendszermag óráját.

A nyílt forráskódú OpenOffice.org irodai programcsomag FreeBSD alatt natívan is futtatható. Oracle Open Office linuxos változata, amely az OpenOffice.org zárt forráskódú, továbbfejlesztett változata, szintén működik FreeBSD alatt.

A FreeBSD ezeken kívül még számos szövegszerkesztőt, táblázatkezelőt és rajzprogramot is tartalmaz a Portgyűjteményében.

A The Open Group kiadta a Motif 2.2.2 változatának forráskódját. Ez az x11-toolkits/open-motif csomagból vagy portból érhető el. A telepítésével kapcsolatban olvassuk el a kézikönyv portokról szóló részét.

Ezenkívül még használhatóak a Motif kereskedelmi változatai is. Ezek viszont már nem ingyenesek, de a licencük megengedi azt, hogy zárt forráskódú szoftverekben is felhasználhassuk. Az Apps2gonál érdeklődjünk a FreeBSD-re elérhető legolcsóbb Motif 2.1.20 ELF (i386) típusú terjesztésekkel kapcsolatban.

Kétfajta terjesztés létezik, a “fejlesztői változat” és a “futásidejű változat” (valamivel olcsóbb). Az egyes terjesztésekben a következők találhatóak:

• OSF/Motif manager, xmbind, panner, wsm

• Fejlesztői készlet: uil, mrm, xm, xmcxx, include és Imake állományok

• Statikus és dinamikus ELF könyvtárak

• Példa alkalmazások

A megrendelés során ne felejtsük el megadni, hogy a Motif melyik FreeBSD verzióhoz készített változatát kérjük (valamint az architektúrát se)! Az Apps2go NetBSD és OpenBSD rendszerekkel is foglalkozik, ezeket a változatokat jelenleg csak FTP-n keresztül lehet elérni.

A Xi Graphics korábban kínált fel CDE-t FreeBSD-hez, de manapság már nem foglalkoznak ezzel.

A KDE a CDE-hez nagyon sok tekintetben hasonló nyílt forráskódú X11 munkakörnyezet, de érdemes pillanatást vetnünk az xfce-re is. A KDE és az xfce egyaránt megtalalálható a portok között.

Igen! A FreeBSD hivatalos honlapján megtaláljuk ezeket a kereskedelmi gyártók között.

Érdemes még megnéznünk a Portgyűjteményeben a adatbázisokat tartalmazó szekciót.

Igen. A http://www.shadowcom.net/freebsd-oracle9i/ oldalon találunk arról információt, hogyan telepíthetjük FreeBSD-re az Oracle Linux változatát.

Nézzünk szét a portok között és láthatjuk, hogy milyen szoftvereket portoltak eddig FreeBSD-re. A listában pillanatnyilag 20 000 port található és naponta növekszik, ezért érdemes folyamatosan figyelni vagy az új portokról úgy is értesülhetünk rendszeresen, ha feliratkozunk a FreeBSD announcements levelezési lista címére.

A legtöbb portnak működnie kell a 6.X, 7.X és 8.X ágak használata esetén is. Mindegyik FreeBSD kiadás elkészítésekor készül egy pillanatfelvétel a portokat tartalmazó könyvtárról és bekerül a ports/ könyvtárba.

Ezenkívül még “csomagok” is rendelkezésünkre állnak, amelyek lényegében egy tömörített bináris terjesztési formát takarnak, némi plusz információval kiegészítve az egyéni telepítésekhez elvégzéséhez. A csomagok könnyen telepíthetőek és eltávolíthatóak anélkül, hogy pontosan ismernénk a benne található állományok összes apró részletét.

A különböző csomagokat a sysinstall(8) programban (a Configure menün belül) található Packages menüpontban tudjuk telepíteni, vagy meghívjuk meg a pkg_add(1) parancsot. A csomagokat leginkább .tbz kiterjesztésükről lehet megismerni, valamint a telepítő CD-ken a packages/All könyvtárban találhatóak. Az interneten keresztül is le tudjuk tölteni ezek közül a FreeBSD különböző verzióihoz tartozó változatukat a hozzánk legközelebbi tükrözésekről:

Nem mindegyik port érhető el csomagként, mivel folyamatosan készülnek az újabbak. Ezért mindig érdemes bizonyos időközönként ellenőrizni a központi ftp.FreeBSD.org oldalon található csomagokat.

Telepítsük az news/inn csomagot vagy portot és utána kiindulásképpen nézzük meg az INN GYIK-ot.

Igen. Látogassunk el a http://www.FreeBSD.org/java/ oldalra.

Ha olyan FreeBSD verziónk van, amely egy kicsit lemaradt az aktuális -CURRENT vagy -STABLE ágak mögött, akkor valószínűleg frissítenünk kell a Portgyűjteményünket. Ennek részleteiről a Porterek kézikönyvében, a Keeping Up című részben olvashatunk (angolul). Ha viszont rendszerünkben minden a lehető legfrissebb, akkor előfordulhat, hogy valaki olyan változtatást rakott fel a porthoz, amely a -CURRENT esetén működik, de a -STABLE változatban már nem. Ilyenkor feltétlenül küldjünk egy hibajelentést a send-pr(1) paranccsal, hiszen a Portgyűjteménynek a -CURRENT és -STABLE ágak esetén egyaránt működnie kell.

Elsőként mindig ellenőrizzük, hogy a Portgyűjteményünk a lehető legfrissebb. A legfrissebb változatnál jelentkező INDEX készítési hibák mindig szem előtt vannak, ezért általában gyorsan megjavulnak.

Ha viszont egy friss verzióval rendelkezünk, akkor elképzelhető, hogy egy másik hibával kerültünk szembe. A make index parancsnak van egy olyan hibája, amely miatt nem képes a Portgyűjtemény hiányos példányával dolgozni. Feltételezi ugyanis, hogy az összes olyan port megtalálható a rendszerünkben, amely telepítése szükséges az adott porthoz. Ennek megértéséhez most képzeljük el, hogy megvan az ize/mize port a lemezen, amely függ az aze/maze porttól, és emiatt az aze/maze portnak és függőségeinek is rajta kell lennie a lemezünkön. Minden más esetben a make index nem tud összegyűjteni elegendő információt ahhoz, hogy létre tudja hozni a függőségi gráfot.

Ez különösen olyan FreeBSD felhasználókkal fordul elő, akik a cvsup(1) (vagy csup(1)) használatával frissítik a Portgyűjteményüket, de a refuse állományokban kizártak néhány kategóriát. Elméletben természetesen ki lehet zárni akármilyen kategóriát, azonban a gyakorlat azt mutatja, hogy ez szinte lehetetlen, mivel túlságosan sok port függ más kategóriákban található portoktól. Amíg valaki meg nem oldja ezt a problémát, addig fogadjuk el általános szabálynak, hogy az INDEX létrehozásához a teljes Portgyűjteménnyel rendelkeznünk kell.

Néhány ritka esetben még előfordulhat, hogy az INDEX azért nem jön létre, mert a make.conf állományban megadtunk valamilyen WITH_* vagy WITHOUT_* változót. Ha úgy érezzük, hogy ez okozhatja a problémát, akkor próbáljuk meg először ezen változók nélkül létrehozatni az INDEX állományt és csak utána jelenteni a hibát a FreeBSD ports levelezési lista címére.

A FreeBSD alaprendszerét úgy állították össze, hogy saját magát legyen képes legyen lefordítani, vagyis az egész operációs rendszer előállítható legyen néhány alapvető eszköz használatával. Ezért a források között leginkább csak az található meg, ami feltétlenül kell a források lefordításához. Ilyen például a C fordító (gcc(1)), a make(1), awk(1) és a többi.

Mivel a CVSup a Modula-3 programozási nyelven íródott, csak úgy tudnánk beletenni a FreeBSD alaprendszerbe, ha hozzávennénk és karbantartanánk egy Modula-3 fordítót is. Ezzel együtt viszont növekedne a FreeBSD forrása, amelyet aztán karban is kellene tartani. Ezért mind a fejlesztők, mind pedig a felhasználók számára egyszerűbb, ha a CVSup egy külön portként érhető el a rendszerhez. Ez viszont gyorsan telepíthető a FreeBSD telepítő CD-ken található csomagokból.

Azonban a FreeBSD 6.2-RELEASE megjelenésétől kezdve a FreeBSD felhasználók nem maradnak integrált CVSup kliens nélkül. Maxime Henrion <mux@FreeBSD.org> munkájának köszönhetően a CVSup alkalmazásnak elkészült a C nyelven újraírt változata, a csup(1), amely most már az alaprendszer része. Noha jelenleg nem még nem képes mindarra, amire a CVSup, elegendő (és nagyon gyors!) ahhoz, hogy a forrásainkat frissen tartsuk. A 6.2 előtt kiadott rendszerek esetében ezt portból vagy csomagból is felrakhatjuk (lásd net/csup).

A FreeBSD alaprendszere ehhez nem kínál fel semmilyen eszközt, de léteznek olyan segédeszközök, amelyekkel valamennyire meg tudjuk könnyíteni a frissítés folyamatát. További segédprogramok telepítésével pedig a portok kezelését tudjuk tovább egyszerűsíteni, amiről a FreeBSD kézikönyv A portok frissítése című szakaszában olvashatunk bővebben.

Mindenképpen! Noha látszólag a frissített rendszeren is remekül futnak a korábbi verzióra telepített alkalmazások, könnyen előfordulhat, hogy az újabb portok telepítésékor vagy a meglevőek frissítésekor véletlenszerű összeomlásokat vagy egyéb hibákat tapasztalunk.

Ne felejtsük el, hogy a rendszer frissítésekor a különféle osztott könyvtárak, betölthető modulok és a rendszer egyéb komponensei is lecserélődnek. Ezért a régebbi változataikhoz fordított alkalmazások egyáltalán nem fognak elindulni vagy nem működnek rendesen.

Ezzel kapcsolatban olvassuk el a FreeBSD kézikönyvének frissítéről szóló szakaszát.

Általánosságban véve nem. A FreeBSD fejlesztői ugyanis mindent megtesznek azért, hogy ugyanazon a fő fejlesztési ágon belüli verziók között megmaradjon a bináris szintű kompatibilitás. Az esetleges kivételeket pedig dokumentálni szokták a kiadásokhoz tartozó jegyzetekben, ahol többnyire megadják az adott változtatáshoz tartozóan a követendő tanácsokat.

Mert a POSIX® szerint lennie kell egy ilyen parancsértelmezőnek.

A valamivel bonyolultabb válasz: sokan szeretnének olyan szkripteket írni, amelyek több rendszer közt is átvihetőek. Ezért a POSIX a parancsértelmezőkre és a segédprogramokra vonatkozó parancsokat igen részletesen tárgyalja. A legtöbb ilyen szkriptet a Bourne-féle parancsértelmezőben készítik, és több fontos programozói felület (make(1), system(3), popen(3) és ezek magasabb szintű, például Perl és Tcl nyelvi megfelelői) a Bourne-parancsértelmező használatán alapszik. Mivel a Bourne-parancsértelmező használata ilyen széles körben elterjedt, fontos, hogy gyorsan induljon, előre megjósolható legyen a működése és ne foglaljon túlságosan sok memóriát.

A jelenlegi implementáció igyekszik ezek közül az elvárások közül egyszerre a lehető legtöbbet teljesíteni. A /bin/sh programot csak úgy tudjuk a megfelelő méreten tartani, ha nem tesszük bele az összes többi parancsértelmezőben megtalálható kényelmi funkciót. Pontosan ezért találhatjuk meg viszont a Portgyűjteményben a többi, például a bash, scsh, tcsh és zsh parancsértelmezőket. (Ezek konkrét memóriahasználatát össze is tudjuk vetni, ha a ps -u parancs kimenetének “VSZ” és “RSS” oszlopait megnézzük.)

Erre az az általános válasz, hogy a névfeloldás valószínűleg rosszul működik a rendszerünkön. A Netscape és az Opera is ellenőrzi a névfeloldást az indulásakor. Ezért a böngésző egészen addig nem jelenik meg az asztalon, amíg választ nem kap vagy rá nem jön, hogy nincs aktív hálózati kapcsolat.

Ha úgy korábban úgy frissítettük a CVSup használatával a Portgyűjteményt, hogy nem adtuk meg a ports-all CVSup algyűjteményt, akkor a ports-base algyűjteményt is mindig frissítenünk kell! Ennek okairól a kézikönyvben olvashatunk.

Ha MIDI állományokból akarunk audio CD-t készíteni, akkor először telepítsük fel a Portgyűjteményből a audio/timidity++ portot, majd kézzel tegyük hozzá Eric A. Welsh GUS patch-eit, melyek a http://alleg.sourceforge.net/digmid.html címről tölthetőek le. Miután a TiMidity++ sikeresen felkerült a rendszerünkre, a MIDI állományokat a következő paranccsal tudjuk átkonvertálni WAV állományokra:

% timidity -Ow -s 44100 -o /tmp/juke/01.wav 01.mid

A WAV állományok ezek után tetszőleges formátumba konvertálhatóak tovább vagy készíthető belőlük egy audio CD, ahogy azt a FreeBSD kézikönyvben is olvashatjuk.

Egyáltalán nem! Ezzel kapcsolatban olvassuk el a FreeBSD kézikönyv rendszermag beállításairól szóló részét.

Ez valószínűleg azért következett be, mert eltávolítottuk az npx0 (lásd npx(4)) támogatást a rendszermag beállításai közül, mert a rendszerünkben nincs matematikai társprocesszor. Az npx0 eszköz jelenléte azonban kötelező. Valahol a gépünkben lennie kell olyan eszköznek, amely a lebegőpontos számok hardveres kezelését végzi, annak ellenére, hogy nem egy különálló eszköz, ahogy régen a 386-osoknál volt. A rendszermagban szerepelnie kell az npx0 eszköznek. Ha netalán még sikerülne is npx0 támogatás nélkül fordítanunk egy rendszermagot, akkor sem tud elindulni.

Nagyon valószínű, hogy a rendszermagunk debug módban készült el. A debug módú rendszermagokban rengeteg olyan szimbólum található, amely hasznos lehet a hibák keresése és a rendszer vizsgálata során, ezért emiatt jelentős mértékben növekszik a mérete. Emiatt nem kell aggódnunk, mert egy hibakeresésre felkészített rendszermag egyáltalán nem vagy csak egy kicsivel lassabb, mint a hagyományos változat, illetve a rendszer összeomlásakor mindig mindig szükségünk lehet ezekre a debug információkra.

Ha viszont kevés a lemezterület vagy egyszerűen csak nem akarunk debug módú rendszermagot akarunk futtatni, akkor a következőkre kell figyelnünk:

• Vegyük ki a rendszermag konfigurációs állományából a következő sort:

  makeoptions DEBUG=-g

• A config(8) használata során ne használjuk a -g beállítást.

A fentiek közül akármelyiket is választjuk, a rendszermagunk debug módban jön létre. Ha azonban sikerült betartani a fentebb javasolt lépéseket, akkor egy normál rendszermagot kapunk, amely mérete ilyenkor jelentős mértékben visszaesik: a legtöbbjük olyan 1,5 és 2 MB körül van.

Ha a rendszermagot a többportos soros vonali kártyák támogatásával fordítjuk le, akkor a rendszertől azt az üzenetet kapjuk, hogy csak az első megszakítást fogja használni, a többit pedig ütközés miatt (interrupt conflict) kihagyja. Hogyan lehet ezen javítani?

A gondot alapvetően az okozza, hogy a FreeBSD a rendszermagban fixen letárolja ezeket, nehogy valamilyen hardveres vagy szoftveres ütközés miatt elkallódjanak. Ezen úgy tudunk segíteni, ha egyetlen IRQ vonal kivételével az összes többi beállítását szabadon hagyjuk. Íme erre egy példa:

#
# Többportos nagysebességű soros vonali eszközök - 16550 UART
#
device sio2 at isa? port 0x2a0 tty irq 5 flags 0x501 vector siointr
device sio3 at isa? port 0x2a8 tty flags 0x501 vector siointr
device sio4 at isa? port 0x2b0 tty flags 0x501 vector siointr
device sio5 at isa? port 0x2b8 tty flags 0x501 vector siointr

Ennek több oka is lehet. Ezek közül néhány, de nem feltétlenül ebben a sorrendben:

• Nem a make buildkernel és make installkernel parancsokat használtuk és valószínűleg a forrásaink sem egyeznek meg a jelenleg futó rendszerével (például egy 8.1-RELEASE rendszert akarunk fordítani egy 7.3-RELEASE rendszeren). Ha frissíteni akarunk, akkor olvassuk el a /usr/src/UPDATING állományt, különös tekintettel a végén található “COMMON ITEMS” című szakaszra.

• A make buildkernel és make installkernel parancsokat használtuk, de előtte nem futott le rendesen a make buildworld parancs. A make buildkernel parancs ugyanis erősen támaszkodik a make buildworld által végzett munkára.

• Gyakran a FreeBSD-STABLE változat használata esetén is előfordulhat, hogy olyan pillanatban töltöttük le a forrásokat, amikor módosítás alatt voltak vagy valamiért nem működtek rendesen. Kizárólag a kiadások esetén tudjuk szavatolni a hibátlan fordítást, noha a FreeBSD-STABLE verzióból készült változatok is többnyire megfelelőek. Próbáljuk meg újra letölteni a forrásokat, ha eddig még nem próbálkoztunk volna vele, és nézzük meg, hogy ez segít-e megoldani a problémát. Keressük másik szervert, ha gondjaink vannak a frissítéssel.

Nézzük meg, hogy a rendszerünkben elérhető-e a kern.sched.quantum változó. Ha van ilyenünk, akkor valami ilyesmit kell tapasztalnunk:

% sysctl kern.sched.quantum
kern.sched.quantum: 99960

Ha létezik a kern.sched.quantum nevű sysctl változó, akkor a 4BSD ütemező fut (lásd sched_4bsd(4)). Ha nem, akkor egy ilyen hibát kapunk a sysctl(8) parancstól (ezt nyugodtan figyelmen kívül hagyhatjuk):

% sysctl kern.sched.quantum
sysctl: unknown oid 'kern.sched.quantum'

Az aktuálisan használt ütemező neve közvetlenül elérhető a kern.sched.name sysctl változó lekérdezésén keresztül:

% sysctl kern.sched.name
kern.sched.name: 4BSD

A kern.sched.quantum értéke határozza meg, hogy egy futó program legfeljebb mennyi órajelet futhat egyszerre, megszakítás nélkül. Ezt az értéket a 4BSD ütemező használja, ezért a jelenlétéből vagy hiányából következtetni tudunk a pillanatnyilag használatban levő ütemezőre.

Ezzel kapcsolatban olvassuk el a lemezek hozzáadásáról szóló részt a FreeBSD kézikönyvben.

Ezt legegyszerűbben úgy tudjuk megcsinálni, ha újratelepítjük az operációs rendszert az új lemezre és külön áttesszük a felhasználói adatokat. Ez különösen ajánlott abban az esetben, ha már több kiadás óta követjük a -STABLE változatot, vagy ha korábban már frissítettük a kiadásunkat. A boot0cfg(8) segítségével fel tudjuk rakni a booteasyt mind a két lemezre és így egészen addig váltogatni tudjuk a kettőt, amíg teljesen át nem álltunk. Ugorjuk át a következő bekezdést, és olvassuk el, hogy rakjuk át az adatokat.

Úgy is dönthetünk, hogy nem telepítjük újra a rendszert. Ekkor vagy a sysinstall(8), vagy pedig a fdisk(8) és a disklabel(8) használatával osszuk fel és címkézzük meg az új lemezt. Érdemes még a boot0cfg(8) segítségével felraknunk a booteasyt mind a két lemezre, így miután átmásoltuk a régi rendszerünket az új lemezre, ennek megtartásával ki tudjuk próbálni az új rendszert.

Most, miután sikeresen beállítottuk az új lemezt, készen állunk az adatok átmásolására. Sajnos nem lehet csak úgy vakon átmásolni ezeket egyik lemezről a másikra. Ilyenkor ugyanis bizonyos dolgok (például a /dev könyvtárban található eszközleírók, az állományjelzők és a linkek stb.) hajlamosak elromlani. Ezért ehhez olyan eszközökre lesz szükségünk, amelyek ismerik ezeket a dolgokat, mint például a dump(8). Továbbá javasoljuk, hogy egyfelhasználós módban végezzük el az átvitelt, noha ez nem feltétlenül szükséges.

A rendszerindító állományrendszer átmozgatásához egyedül a dump(8) és restore(8) segédprogramokra lesz szükségünk. Esetleg a tar(1) parancs is használható, de nem minden esetben. A dump(8) és restore(8) páros akkor is remekül használható, ha egy partíció tartalmát egy üres partícióra akarjuk átvinni. A következő lépések szükségesek ahhoz, hogy a dump parancs segítségével átvigyük egyik partícióról a másikra az adatokat:

Például, ha a /mnt könyvtárba csatlakoztatott /dev/ad1s1a eszközről akarjuk átvinni a jelenlegi gyökérpartíciónkat, akkor ezeket a parancsokat kell kiadnunk:

# newfs /dev/ad1s1a
# mount /dev/ad1s1a /mnt
# cd /mnt
# dump 0af - / | restore rf -

További munkát igényel, ha a dump parancs segítségével a partícióinkat is át akarjuk szervezni. Például a /var partíciót úgy tudjuk beleolvasztani a tövébe, ha létrehozunk egy olyan partíciót, amely mind a kettő számára elegendő nagy, majd a fentebb leírt módszerrel először átmozgatjuk a tövét, utána pedig átmozgatjuk az alpartíció tartalmát az első mozgatás során létrejött egyik üres könyvtárba:

# newfs /dev/ad1s1a
# mount /dev/ad1s1a /mnt
# cd /mnt
# dump 0af - / | restore rf -
# cd var
# dump 0af - /var | restore rf -

Egy könyvtárat, például /var tartalmát pedig úgy tudunk leválasztani a tövéről, vagyis átrakni egy korábban nem létező partícióra, ha először létrehozzuk mind a két partíciót, csatlakoztatjuk a leendő alpartíciót az ideiglenes csatlakozási ponton belül a megfelelő könyvtárba és mindkettőre átmozgatjuk a régi partíció teljes tartalmát:

# newfs /dev/ad1s1a
# newfs /dev/ad1s1d
# mount /dev/ad1s1a /mnt
# mkdir /mnt/var
# mount /dev/ad1s1d /mnt/var
# cd /mnt
# dump 0af - / | restore rf -

A felhasználói adatok esetén a cpio(1), pax(1), tar(1) és dump(8) eszközöket ajánljuk. Az írás pillanatában még úgy tudjuk, hogy nem tartják meg az állományjelzőkkel kapcsolatos információkat, ezért csak óvatosan használjuk ezeket!

A telepítés során két különböző módon tudjuk partícionálni a lemezeinket. Alapértelmezés szerint a rendszer igyekszik kompatbilis maradni a gépünkön található többi operációs rendszerrel. Ilyenkor normális partíciós táblabeli bejegyzéseket készít (amelyeket FreeBSD alatt “slice”-oknak hívnak), és egy ilyen slice-ba teszi az összes saját partícióját. Emellé még telepíteni tudjuk az operációs rendszerek választásának lehetőségét is a rendszer indításakor. A másik lehetőség választása esetén azonban a FreeBSD teljesen kisajátítja a lemezt és nem is próbál meg kompatibilis maradni a többi operációs rendszerrel.

Miért is nevezzük ezt “veszélyesnek”? A lemez ebben az esetben nem tartalmaz semmi olyat, amelyet a hétköznapi programok partíciós táblaként tudnának beazonosítani. Attól függően, hogy mennyire illedelmes, egy ilyen program panaszkodni fog, amikor megpróbálja értelmezni a lemez tartalmát, de rosszabb esetben anélkül felülírja a rendszerbetöltőt, hogy bármit is jelzett volna. Ráadásul a “veszélyesen dedikált módon” kiosztott lemezek még bizonyos BIOS-okat is képesek megzavarni, többek közt az Award (például amelyek a HP NetServer, Micronics és hasonló rendszerekben találhatóak) vagy Symbios/NCR (népszerű 53C8xx SCSI-vezérlők) típusúak esetén találkozhatunk ezzel a problémával. Ez a lista persze nem teljes, más gyártók termékeivel is gondok akadhatnak. Ennek a hibának jellemző tünete a “read error” hibaüzenet, amely arra utal, hogy a FreeBSD betöltője nem találja saját magát a lemezen, vagy éppen az egész rendszer megáll a rendszer indítása közben.

Akkor mégis mi értelme van ennek? Csak néhány kilobyte-tot spórolunk vele, miközben komoly gondokat okozhat egy frissen telepített rendszer esetében. A “veszélyesen dedikált mód” eredetileg az új FreeBSD telepítőket veszélyeztető egyik komoly hibát szeretné kiküszöbölni: a merevlemezek BIOS és lemez önmaga által ismert geometriai beállításainak egyeztetése.

A “lemezgeometria” fogalma tulajdonképpen már egy elavult fogalom, de a PC-k BIOS-a legbelül még mind a mai napig így kommunikál a lemezekkel. Amikor a FreeBSD telepítőjével slice-okat hozunk létre, olyan módon kell rögzítenünk a lemezre ezek pozícióját, hogy a BIOS képes legyen megtalálni. Ha ez nem sikerül, akkor nem tudjuk elindítani a rendszert.

A “veszélyesen dedikált” mód ezt a problémát az egyszerűsítésén keresztül próbálja megoldani, és néha sikerül is neki. Ezt azonban csak akkor javasoljuk, ha semmi más nem működik, hiszen az esetek túlnyomó részében más megoldás is létezik.

Hogy tudjuk tehát akkor elkerülni a “veszélyesen dedikált” mód használatát a telepítés során? Jegyezzük fel, hogy mik a BIOS szerint a merevlemezünk geometriai beállításai. Ezt a rendszerindítás közben a rendszermagtól is megkérdezhetjük úgy, hogy a boot: paranccsorába megadjuk a -v beállítást, vagy a betöltőben a boot -v parancsot használjuk. Így pontosan a telepítő indítása előtt a rendszermag ki fogja írni a BIOS által ismert geometriai beállításokat. Ne essünk pánikba, várjuk meg, amíg a telepítő elindul, tekerjünk vissza a számokhoz és olvassuk le ezeket. A lemezek általában a BIOS sorrendjében jelennek meg, tehát először az IDE aztán a SCSI típusúak.

A lemez partícionálásakor ellenőrizzük, hogy az FDISK képernyőjén megjelenő geometriai beállítások megfelelőek (tehát egyeznek a BIOS által ismert értékekkel). Ha eltérést tapasztalunk, akkor a G billentyű lenyomásával tudjuk átjavítani. Erre leginkább akkor lesz szükségünk, ha a lemez teljesen üres, vagy ha a lemezt egy másik rendszerből hoztuk át. Ez egyébként csak azoknál a lemezeknél okoz gondot, amelyekről a rendszert akarjuk indítani, a FreeBSD a többi lemezzel már remekül elboldogul.

Miután sikerült egyeztetnünk a BIOS és a FreeBSD geometriai beállításait, szinte biztos, hogy nem kell már emiatt aggódnunk, így a “veszélyesen dedikált” módra sincs szükségünk. Ha viszont mégis egy “read error” hibaüzenetet kapnánk a rendszer indítása közben, akkor tegyünk egy próbát. Semmit sem veszíthetünk.

Ha a “veszélyesen dedikált” mód használatáról szeretnénk visszatérni a megszokottra, akkor két lehetőségünk van. Először is teljesen le kell nulláznunk az MBR-t, így biztosra vehetjük, hogy az ezután következő telepítések során egy teljesen üres lemezt látunk. Ezt például így lehet megtenni:

# dd if=/dev/zero of=/dev/rda0 count=15

A másik módszer egy hivatalosan nem dokumentált DOS-os “lehetőség” használata:

C:\> fdisk /mbr

Ezzel egy új Master Boot Recordot tudunk telepíteni, ami ezzel együtt felülírja a BSD rendszertöltőjét is.

A rövid válasz: A Soft Updates bármelyik partíción minden további nélkül használható.

A hosszabb válasz: Korábban voltak bizonyos kétségek afelől, hogy a Soft Updates jól működik a rendszerindító partíciókon is. Ez alapvetően a Soft Updates két jellemzőjére vezethető vissza. Először is, a Soft Updatest alkalmazó partíciók esetén előfordulhat, hogy a rendszerösszeomlás során elveszik valamennyi adat (maga a partíció nem lesz hibás, csupán némi adat tűnik el), illetve a Soft Updates ideiglenesen kifogyhat a tárhelyből.

A Soft Updates használata során a rendszermag legfeljebb harminc másodperc múlva írja ki fizikailag a változtatásokat a lemezre. Tehát amikor egy nagyobb állományt törlünk, akkor ez az állomány egészen addig a lemezen marad, amíg a rendszermag ténylegesen el nem végzi ezt a törlést. Ezzel viszont nagyon egyszerűen létrehozható egy “ütközés” (race condition) az állományrendszeren. Tegyük fel, hogy letörlünk egy nagyobb állományt és utána közvetlenül létrehozunk egy másik nagyobb állományt. Mivel az első állomány ilyenkor még nem törlődik le valójában a lemezről, ezért a második számára már nem lesz elegendő helyünk. A rendszer ekkor egy hibaüzenetben fog figyelmeztetni minket, miközben pontosan az imént töröltünk le egy óriási állományt! Ha néhány másodperccel később újra megpróbáljuk létrehozni ezt az állományt, akkor már minden a megfelelő módon fog zajlani. Ezt régebben sok FreeBSD felhasználó nem tudta mire vélni.

Ha a rendszerünk olyankor omlik össze, amikor a rendszermag már elkezdte egy nagyobb mennyiségű adat kiírását a lemezre, de még nem fejeződött be, akkor könnyen előfordulhat, hogy ez az adat elveszik vagy meghibásodik. Ennek kockázata nagyon kicsi, és általában kezelhető, viszont az IDE-meghajtókban található írási gyorsítótár használata jelentősen növeli ezt. Ezért a Soft Updates alkalmazása során nem javasoljuk ennek használatát.

Ezek a problémák az összes Soft Updates partíciót veszélyeztetik. Mennyiben vonatkoznak viszont ezek a gyökérpartícióra?

A gyökérpartíción nagyon ritkán változnak fontos információk. A /boot/kernel/kernel és az /etc egyedül a rendszer karbantartása során frissül, vagy például amikor a felhasználók jelszót változtatnak. Ha a rendszer egy ilyen változtatás harminc másodperces idején belül omlik össze, akkor megvan rá az esélyünk, hogy elvesznek az adataink. Ez a kockázat a legtöbb alkalmazás számára elfogadható, de semmiképpen sem szabad figyelmen kívül hagynunk. Ha a rendszerünk nem képes vállalni még ennyi kockázatot sem, akkor a rendszerindító partíción tiltsuk le a Soft Updates használatát!

A gyökérpartíció hagyományosan az egyik legkisebb partíció. Ha viszont az ideiglenes állományok tárolására szánt /tmp könyvtárat is ezen belülre tesszük és gyakran használjuk, akkor ebből időszakosan tárhelyproblémáink adódhatnak. Könnyen megoldhatjuk azonban ezt a problémát, ha a /tmp könyvtárhoz létrehoznunk egy szimbolikus linket a /var/tmp könyvtárra.

A hibajelenség:

# ccdconfig -C
ccdconfig: ioctl (CCDIOCSET): /dev/ccd0c: Inappropriate file type or format

Ez általában olyankor történik, amikor olyan c partíciókat próbálunk meg összefűzni, amelyek alapértelmezés szerint unused (“nem használt”) típusúak. A ccd(4) meghajtó azonban megköveteli, hogy az érintett partíciók FS_BSDFFS típusúak legyenek. Szerkesszük át a lemezeken található címkéket és változtassuk meg a partíciók típusát a 4.2BSD értékre.

A hibajelenség:

# disklabel ccd0
(itt valami gondot ír ki, ezért megpróbáljuk szerkeszteni a címkét)
# disklabel -e ccd0
(edit, save, quit)
disklabel: ioctl DIOCWDINFO: No disk label on disk;
use "disklabel -r" to install initial label

Ezt általában azért kapjuk, mert a ccd(4) által visszaadott lemezcímke valójában “nem létezik” a lemezen. Ezen úgy tudunk segíteni, ha explicit módon visszaírjuk, valahogy így:

# disklabel ccd0 > /tmp/lemezcimke.tmp
# disklabel -Rr ccd0 /tmp/lemezcimke.tmp
# disklabel -e ccd0
(most már működni fog)

A FreeBSD több más állományrendszert is ismer.

A FreeBSD hálózati állományrendszereket is támogat, többek közt az NFS-t (lásd mount_nfs(8)), a NetWare-t (lásd mount_nwfs(8)), és Microsoft-féle SMB állományrendszereket (lásd mount_smbfs(8)). Más egyéb FUSE-alapú állományrendszer (sysutils/fusefs-kmod) támogatását is megtalálhatjuk a portok között.

A logikai DOS partíciók az elsődleges partíciók után találhatóak. Például, ha van egy “E” betűjelű logikai partíciónk a második SCSI-meghajtónkon, akkor lennie kell egy “ötödik slice-nak” a /dev könyvtárban, amelyet majd csatlakoztatni tudunk:

# mount -t msdosfs /dev/da1s5 /dos/e

Igen. Erre a célra a gbde(8) és a geli(8) is tökéletesen alkalmas. A részleteket lásd a FreeBSD kézikönyv A lemezpartíciók titkosítása című fejezetében.

Ehhez tulajdonképpen csak annyit kell csinálnunk, hogy átmásoljuk a FreeBSD rendszerindító partíciójának az első szektorát egy állományba a DOS/Windows NT partíción belül. Legyen ez például a C:\BOOTSECT.BSD állomány (a C:\BOOTSECT.DOS mintájára), amelyhez aztán így igazítjuk a c:\boot.ini állományt:

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows NT"
C:\BOOTSECT.BSD="FreeBSD"
C:\="DOS"

Ha a FreeBSD ugyanazon a lemezen található, ahonnan a Windows NT is indul, akkor egyszerűen csak másoljuk át a /boot/boot1 állományt C:\BOOTSECT.BSD néven. Ha viszont a FreeBSD egy másik lemezen található, akkor a /boot/boot1 önmagában már nem elegendő, hanem helyette a /boot/boot0 állományra lesz szükségünk.

A /boot/boot0 állományt a sysinstall(8) használatával kell telepíteni abból a menüből, ahol a FreeBSD boot managerét kell kiválasztani. Erre azért van szükség, mert a /boot/boot0 állományon belül a partíciós tábla teljesen üres, azonban a sysinstall(8) át fogja másolni a partíciós táblát mielőtt a /boot/boot0 állományt az MBR-be tenné.

Amikor a FreeBSD boot managere lefut, az utoljára indított operációs rendszert a partíciós táblában aktívként jelöli meg (ezzel lényegében megjegyzi), majd ezután beírja magát az MBR-be. Emiatt, hogy ha csak egyszerűen átmásoljuk a /boot/boot0 állományt a C:\BOOTSECT.BSD állományba, akkor csak egy egyetlen aktív bejegyzést tartalmazó üres partíciós táblát fog visszaírni az MBR-be.

Ha a FreeBSD és a Linux is ugyanazon a lemezen helyezkedik el, akkor nincs más teendőnk, mint követni a LILO telepítési útmutatójában a nem-Linux típusú operációs rendszerek indítására vonatkozó utasításokat. Ezek röviden összefoglalva a következők:

Indítsuk el a Linuxot és vegyük fel a következő sort az /etc/lilo.conf állományba:

other=/dev/hda2
        table=/dev/hda
        label=FreeBSD

(A fentiekben feltételeztük, hogy a FreeBSD-t tartalmazó slice a Linux számára /dev/hda2 néven érhető el. Ez természetesen a saját konfigurációnkhoz kell szabni.) Ezután egyszerűen csak futtassuk le a lilo parancsot root felhasználóként és már készen is vagyunk.

Ha a FreeBSD egy másik lemezen található, akkor a loader=/boot/chain.b LILO-bejegyzést kell használnunk. Például:

other=/dev/dab4
        table=/dev/dab
        loader=/boot/chain.b
        label=FreeBSD

Bizonyos helyzetekben előfordulhat, hogy a FreeBSD rendszertöltőjének át kell adnunk a meghajtó BIOS szerinti sorszámát, mert csak így tudjuk rendesen elindítani a második lemezről. Például, ha a FreeBSD szerint a SCSI-lemezünk a BIOS-ban az 1-es lemez, akkor ezt kell megadnunk a FreeBSD rendszertöltőjének:

Boot: 1:da(0,a)/boot/kernel/kernel

A boot(8) beállítható úgy, hogy a rendszer indításakor automatikusan mindig ezt a beállítást használja.

A FreeBSD és Linux együttes használatáról további részleteket a Linux+FreeBSD mini-HOWTO című írásból tudhatunk meg.

A FreeBSD-t nagyon könnyű elindítani a GRUB segítségével. Ehhez csupán annyit kell tennünk, hogy felvesszük a következő sorokat a GRUB konfigurációs állományába (/boot/grub/menu.lst, vagy bizonyos, például Red Hat-típusú rendszerekben a /boot/grub/grub.conf):

title FreeBSD 6.1
	root (hd0,a)
	kernel /boot/loader
	  

Itt a hd0,a az első lemezen található rendszerindító partícióra mutat. Ha a lemezen belül a slice számát is szeretnénk megadni, akkor írhatjuk így is: (hd0,2,a). Ha ezt nem adjuk meg, akkor a GRUB alapértelmezés szerint a lemezen levő első a partícióval rendelkező slice-ot keresi meg.

A LILO-t ne a Master Boot Recordba, hanem a linuxos partíciónk elejére telepítsük. Ezután a BootEasyből már el tudjuk indítani a LILO-t.

Abban az esetben is ezt javasoljuk, ha Windows és Linux is van a gépünkön, mivel így szintén egyszerűbb lesz elindítani a Linuxot, ha netalán valamikor újra kellene telepíteni a Windows-t (ami viszont egy “irigy” operációs rendszer, mert nem tűr meg semmilyen más operációs rendszert maga mellett a Master Boot Recordban).

Ez az szabványos boot managerrel csak úgy lehet megoldani, ha újratelepítjük. A portok között viszont a sysutils kategóriában rengeteg olyan más boot managert találhatunk, amely tud ilyet is.

Legyen az akár egy Zip, EZ drive meghajtó (esetleg egy floppy, ha így akarjuk használni), vagy éppen egy új merevlemez, miután már telepítettük és felismerte a rendszert, illetve behelyeztük a lemezt, kártyát vagy akármit, minden esetben szinte ugyanaz a teendő.

(Ez a válasz leginkább Mark Mayo ZIP GYIK című írásán alapszik.)

Ha tehát egy ZIP meghajtóról vagy floppylemezről beszélünk, amelyen egy DOS-os állományrendszer található, akkor azt parancssorból így érhetjük el, ha floppy:

# mount -t msdosfs /dev/fd0c /floppy

vagy így, ha egy gyári beállításokkal rendelkező ZIP-lemez:

# mount -t msdosfs /dev/da2s4 /zip

A többi lemez esetén a fdisk(8) vagy a sysinstall(8) segítségével nézzük meg, hogy milyen partíciók és hogyan találhatóak meg rajtuk.

A következő példákban egy da2 eszközként, vagyis egy harmadik SCSI-lemezként megjelenő ZIP-meghajtót fogunk használni.

Hacsak nem floppyval van dolgunk, illetve nem tervezzük másoknak is odaadni a cserélhető médiumot, akkor érdemes inkább BSD típusú állományrendszert telepíteni rá. Így támogatottak lesznek a hosszú állománynevek, és legalább egy kétszer gyorsabb és egy sokkal megbízhatóbb megoldást kapunk. Ehhez először is le kell szednünk a DOS-szintű partíciókat és állományrendszereket. Erre a célra egyaránt megfelel a fdisk(8) vagy a sysinstall(8), illetve kisebb lemezek esetén valószínűleg nem is lesz szükségünk több operációs rendszer támogatására, így aztán közvetlenül is törülhetjük ezeket:

# dd if=/dev/zero of=/dev/rda2 count=2
# disklabel -Brw da2 auto

A disklabel(8) vagy a sysinstall(8) használatával ezután létre tudunk hozni BSD típusú partíciókat. Valószínűleg erre lesz szükségünk, ha lapozóállományt is tenni akarunk a lemezre, noha ennek nem sok értelme van például egy ZIP-meghajtó esetén.

Végezetül hozzunk létre egy új állományrendszert. Itt most ez egész ZIP-lemezen egyetlen partíció lesz:

# newfs /dev/rda2c

Csatlakoztassuk:

# mount /dev/da2c /zip

Emellett még hasznos lehet felvenni hozzá egy sort az /etc/fstab állományba is (lásd fstab(5)), így a jövőben elegendő csak a mount /zip parancsot kiadnunk a csatlakoztatásához:

/dev/da2c /zip ffs rw,noauto 0 0

Fel kell világosítanunk a mount(8) parancsot a csatlakoztatandó eszköz típusáról. Erről a kézikönyv lézeres tárolóeszközökről szóló részében olvashatunk, innen is különösen a Adat CD-k használata című szakaszt ajánljuk.

Ez általában arra utal, hogy nincs CD a meghajtóban, vagy a meghajtó nem érhető el a buszon. Ezzel kapcsolatban a kézikönyv Adat CD-k használata című szakaszát javasoljuk elolvasásra.

A CD-n valószínűleg a “Joliet” kiterjesztés használatával tárolják az állományok és könyvtárak adatait. Erre vonatkozóan a kézikönyvben a Lézeres tárolóeszközök (CD-k) létrehozása és használata című rész elolvasását javasoljuk, különös tekintettel az Adat CD-k használata című szakaszra.

Ez minden bizonnyal abból fakad, hogy nem egy ISO 9660 állományrendszert vettük fel rá, hanem közvetlenül maguk az állományokat. Olvassuk el a kézikönyvben a Lézeres tárolóeszközök (CD-k) létrehozása és használata című fejezetet, de különösen a Nyers adat CD-k írása című részt.

Erről a kézikönyvben találunk hasznos információkat, azon belül is az Adat CD-k másolása című szakaszban. A CD-kkel végezhető további műveletekről a kézikönyv Lézeres tárolóeszközök (CD-k) létrehozása és használata című részében találhatunk részletes útmutatásokat.

Ha zenei CD-ket próbálunk meg csatlakoztatni, akkor például egy “cd9660: /dev/acd0c: Invalid argument” hibát fogunk kapni a rendszertől. Ez azért történik, mert a mount parancs csak állományrendszerekkel használható. A zenei CD-ken viszont semmilyen állományrendszer nincs, egyszerűen csak maga az adat. Az olvasásukhoz olyan programra lesz szükségünk, amely képes zenei CD-kkel dolgozni, mint például az audio/xmcd port.

A mount(8) alapértelmezés szerint az CD-n található utolsó adatsávot (menetet, vagy sessiont) próbálja meg olvasni. Ha viszont egy korábbi menetet szeretnénk vele betöltetni, akkor erre használjuk a -s paranccsori paramétert. Erre a mount_cd9660(8) man oldalon találhatunk különböző példákat.

A normál felhasználók számára engedélyezni tudjuk az eszközök csatlakoztatását. Íme:

Most már mindegyik felhasználó képes csatlakoztatni a /dev/fd0 eszközleírón keresztül elérhető lemezt a saját könyvtárába:

% mkdir ~/az-én-csatlakozási-pontom
% mount -t msdosfs /dev/fd0 ~/az-én-csatlakozási-pontom

A operator csoport tagjai is képesek most már az /dev/acd0c eszközleírón keresztül elérhető CD-ket csatlakoztatni a saját könyvtárukba:

% mkdir ~/az-én-csatlakozási-pontom
% mount -t cd9660 /dev/acd0c ~/az-én-csatlakozási-pontom

Az eszközök leválasztása is hasonlóan egyszerű:

% umount ~/az-én-csatlakozási-pontom

A vfs.usermount engedélyezésével azonban együttjár némi biztonsági kockázat is. Az MS-DOS formátumú lemezek csatlakoztatására ezért inkább a Portgyűjteményben található emulators/mtools csomagot javasoljuk.

A válaszhoz meg kell értenünk a du és a df működését. A du végigmegy a könyvtárszerkezeten és megnézi, hogy mekkorák az egyes állományok, majd megjeleníti a végösszegüket. A df ezzel szemben egyszerűen csak lekérdezi az állományrendszertől, hogy mennyi szabad hely maradt rajta. Ezek látszólag ugyanazt a módszer fedik, azonban miközben a könyvtár nélkül állományok befolyásolják a df parancsot, addig a du parancsot nem.

Amikor egy program használ egy olyan állományt, amelyet eközben letörlünk, egészen addig létezni fog, amíg a program be nem fejezi a használatát. Ettől függetlenül viszont az állomány azonnal eltűnik a könyvtárból. Ezt nagyon könnyen ki is tudjuk próbálni egy olyan programmal, mint például a more. Tegyük fel, hogy van akkora állományunk, amely elég nagy ahhoz, hogy feltűnjön a du és a df kimenetében. (Mivel manapság már nagyok a tárolóeszközök, ennek egy igen nagy állománynak kell lennie!) Ha letöröljük ezt az állományt, miközben a more paranccsal még használjuk, a more nem fog rögtön leállni és panaszkodni az állomány hiányára. Egyedül csak az állományhoz tartozó bejegyzés tűnik el a könyvtárból, így más program már nem tud hozzáférni. A du erre már azt mondja, hogy nem létezik — bejárta a könyvtárat és nem találta. A df szerint azonban még mindig ott van, hiszen az állományrendszer tudja, hogy a more parancsnak még szüksége van rá. Ahogy a more befejezte a dolgát, a du és a df által mutatott értékek ismét egyezni fognak.

Azt sem szabad elfelejtenünk, hogy a Soft Updates használata esetén akár 30 másodpercet is várnunk kell, hogy a változtatásaink láthatóvá váljanak!

Ez a helyzet nagyon gyakori webszerverek esetén. Sokan úgy állítanak be a FreeBSD rendszerükön webszervert, hogy elfelejtik beállítani hozzá a naplók archiválását és váltását. Ilyenkor a hozzáférések naplózása gyorsan meg tudja tölteni a /var könyvtárat. Ekkor a rendszergazda törli az adott állományt, de a rendszer még mindig panaszkodik a szabad hely hiánya miatt. A webszerver leállítása és újraindítása ekkor segít felszabadítani az állományt, így az állományrendszerről is törlődhet. Ennek megelőzésére használjuk a newsyslog(8) programot.

A kézikönyv Beállítás és finomhangolás című fejezetében található egyik szakaszban olvashatunk erről.

A merevlemezek gyártói általában a gigabyte-okat egy milliárd byte-ként számolják, miközben a FreeBSD pedig 1 073 741 824 byte-nak. Ez remekül megmagyarázza, hogy a FreeBSD rendszerüzenetei között egy elméletileg 80 GB méretű lemez miért 76 319 MB-osnak jelenik meg.

Emellett érdemes még tisztában lennünk azzal is, hogy a FreeBSD (alapértelmezés szerint) fenntartja a lemezterület 8 százalékát.

Az UFS partíciók egy részét (amely alapértelmezés szerint a teljes kapacitás 8 százaléka) az operációs rendszer fenntartja a saját és a root felhasználó számára. A df(1) ezt a területet nem számolja a Capacity oszlopban megjelenő értékhez, ezért tudja átlépni a 100 százalékos arányt. Sőt még azt is láthatjuk, hogy a blokkok számát jelző Blocks oszlopban megjelenő érték mindig, általában pontosan 8 százalékkal nagyobb, mint a használt blokkokat jelző Used és a rendelkezésre álló blokkokat jelző Avail oszlopokban szereplő értékek összege.

A részleteket a tunefs(8) man oldalon belül a -m opció bemutatásánál olvashatjuk.

Az ezzel kapcsolatos beállítások elsősorban az /etc/defaults/rc.conf állományban találhatóak (lásd rc.conf(5)). A rendszer indításáért felelős szkriptek, mint például az /etc/rc vagy az /etc/rc.d könyvtár tartalma (lásd rc(8)) ezt használja. Ezt az állományt tilos közvetlenül szerkeszteni! Ha valamit meg akarunk változtatni az /etc/defaults/rc.conf állományban szereplő beállítások közül, akkor ehelyett egyszerűen csak másoljuk le az /etc/rc.conf állományba és állítsuk be ott az értékét.

Például, ha el akarjuk indítani a beépített névfeloldó szolgáltatást, a named(8) démont, akkor ennyit kell tennünk:

# echo 'named_enable="YES"' >> /etc/rc.conf

Ha helyi szolgáltatásokat akarunk futtatni, akkor tegyük a hozzá tartozó szkripteket az /usr/local/etc/rc.d könyvtárba. Ezek a szkriptek legyenek végrehajthatóak és az alapértelmezett állománymóduk legyen 555.

Használjuk a adduser(8), vagy bonyolultabb esetekben a pw(8) parancsot.

Felhasználókat törölni a rmuser(8), vagy amennyiben szükséges, a pw(8) paranccsal tudunk.

Ilyen általában olyankor történik, amikor a rendszerszintű crontab állományt módosítjuk (/etc/crontab), majd a crontab(1) használatával megpróbáljuk telepíteni:

# crontab /etc/crontab

Ezt nem így kell megoldani. A rendszerszintű crontab felépítése eltér a felhasználókhoz tartozó crontab állományokétól (a crontab(5) man oldal szemlélteti részletesebben ezeket az eltéréseket), amelyet a crontab(1) próbál meg ilyenkor telepíteni.

Ha így csináltuk, akkor a crontab nem lesz több, mint az /etc/crontab hibás formátumú változata. Töröljük le:

# crontab -r

Legközelebb, amikor az /etc/crontab állományt módosítjuk, nem kell értesítenünk a cron(8) démont, mivel magától észre fogja venni az elvégzett változtatásokat.

Ha valamit napi, heti vagy havi rendszerességgel akarunk futtatni, akkor ehelyett inkább másoljuk be az /usr/local/etc/periodic könyvtárba, és hagyjuk, hogy a cron hívja meg a periodic(8) parancson keresztül az összes többi rendszeresen elvégzendő feladattal együtt.

Ez a hiba egyébként onnan jön, hogy rendszerszintű crontab állomány esetén van még egy további mező, amely megadja, hogy az adott parancsot melyik felhasználóval kell futtatni. Az alapértelmezett rendszerszintű crontab állomány esetén ez mindenhol a root. Amikor ezt a crontab állományt a root crontab állományaként használjuk (amely nem ugyanaz, mint a rendszerszintű crontab), akkor a cron(8) a root szót a végrehajtandó parancs részének fogja tekinteni, amely viszont nem létezik.

Ez egy biztonsági megszorítás. Csak úgy tudunk átváltani a root felhasználóra (vagy bármilyen más olyan hozzáférésre, amely rendszeradminisztrátori jogosultságokkal rendelkezik), ha a wheel csoport tagjai vagyunk. Ha nem létezne ez a korlátozás, akkor a rendszerben szinte bárki képes lenne rendszeradminisztrátori jogosultságokat szerezni csupán úgy, hogy ha megszerzi valahogy a root jelszavát. Ennek a korlátozásnak köszönhetően ez viszont már nem lesz feltétlenül helytálló. A su(1) még a jelszót sem engedi megadni azoknak, akik nem tagjai a wheel csoportnak.

Ha engedélyezni akarjuk valakinek a root felhasználóra váltást, akkor nincs más teendőnk, mint egyszerűen a hozzáadni a wheel csoporthoz.

Indítsuk újra a rendszert és a rendszertöltő parancssorában adjuk ki a boot -s parancsot, amivel így egyfelhasználós módba váltunk. Amikor meg kell adnunk a használni kívánt parancsértelmező nevét, egyszerűen csak nyomjuk le az Enter billentyűt, majd a mount -urw / parancs kiadásával csatlakoztassuk újra írható módban rendszerindító állományrendszert. Emellett még valószínűleg a mount -a -t ufs paranccsal azokat az állományrendszereket is érdemes lesz csatlakoztatnunk, ahol a kedvenc szövegszerkesztőnk található. Amennyiben az érintett szövegszerkesztő egy hálózati állományrendszeren található, akkor helyette használjunk egy helyben elérhető szövegszerkesztőt, például az ed(1) programot, vagy manuálisan állítsuk be a hálózat elérését a hálózati állományrendszerek csatlakoztatásához.

Ha a vi(1) vagy emacs(1) programokhoz hasonló teljes képernyős szövegszerkesztőt akarunk használni, akkor előtte nem árt a export TERM=cons25 parancsot sem kiadnunk, így a termcap(5) adatbázisból elérhetővé válnak az ehhez szükséges adatok.

Miután megtettük ezeket a lépéseket, már a szokásos módon át tudjuk szerkeszteni az /etc/rc.conf állományt. A rendszermag indulása után közvetlenül megjelenő üzenetekben találhatjuk meg azon sorok számait, amelyeket a rendszer nem tudott értelmezni.

Olvassuk el a kézikönyv nyomtatókkal foglalkozó részét, minden bizonnyal választ ad a legtöbb kérdésünkre.

Bizonyos nyomtatókat azonban akkor tudunk használni, ha van hozzá meghajtónk. Ezeket gyakran csak “WinPrinter” néven emlegetik, amelyeket viszont a FreeBSD nem támogat. Ha a nyomtatónk nem használható DOS vagy Windows alatt, akkor valószínűleg egy ilyen WinPrinterrel van dolgunk. Ebben az esetben egyedül abban reménykedhetünk, hogy a print/pnm2ppa port támogatja.

Olvassuk el a kézikönyv honosításssal foglalkozó részét, különös tekintettel a konzol beállításaira.

Erre a FreeBSD-CURRENT levelezési lista címére postázott egyik levél adja meg a választ:

Igen, a FreeBSD a GENERIC típusú rendszermagban támogatja a System V típusú IPC megoldást, beleértve az osztott memória, az üzenetek és a szemaforok használatát. Ha saját rendszermagunk van, akkor az alábbi beállítások használatával engedélyezhetjük a használatukat:

options    SYSVSHM          # az osztott memória engedélyezése
options    SYSVSEM          # a szemaforok engedélyeze
options    SYSVMSG          # az üzenetek kezelése

Fordítsuk és telepítsük újra a rendszermagot.

A sendmail a FreeBSD-ben található alapértelmezett levelező szerver, de könnyen le tudjuk cserélni másikra (például amelyet a portok közül telepítettünk).

A Portgyűjteményben több különböző levelező szerver is megtalálható, amelyek közül a mail/exim, mail/postfix, mail/qmail és a mail/zmailer portok a leginkább népszerűek.

Szép dolog, hogy lehet válogatni a különböző megoldások között és hogy ilyen sok levelező szerver használható. Ezért lehetőleg a levelezési listákon ne kérdezzünk senkitől olyat, hogy “De a sendmail akkor most miért jobb, mint a qmail?” Ha ilyen kérdéseink vannak, akkor először inkább olvassuk át az archívumokat. Szinte biztos, hogy már szinte az összes levelező szerver előnyét és hátrányát kivesézték jó néhányszor.

Ne essünk kétségbe! Indítsuk újra a rendszerünket egyfelhasználós módban. Ehhez gépeljük be a boot -s parancsot a rendszertöltő Boot: parancssorában. Amikor a parancsértelmezőt kell megadnunk, egyszerűen csak nyomjuk le az Enter billentyűt. Ekkor kapunk egy # parancssort. A mount -urw / parancs begépelésével csatlakoztassuk újra a rendszerindító partíciónkat írható módban, majd a mount -a paranccsal csatlakoztassuk az összes többi állományrendszert. Ezt követően a passwd root parancs kiadásával változtassuk meg a root felhasználó jelszavát és a exit(1) futtatásával folytassuk a rendszer indítását.

Ha a syscons(4) (vagyis az alapértelmezett) konzolt használjuk, akkor ehhez a következő beállításokkal kell fordítanunk és telepítenünk egy rendszermagot:

options SC_DISABLE_REBOOT

Mindezt a rendszermag újrafordítása és a újraindítása nélkül is le tudjuk tiltani, ha beállítjuk az alábbi sysctl(8)-változót:

# sysctl hw.syscons.kbd_reboot=0

Ha viszont a pcvt(4) konzolt használjuk, akkor a következő konfigurációs beállítást kell megadnunk a rendszermag újrafordításakor:

options PCVT_CTRL_ALT_DEL

Használjuk a következő perl(1) parancsot:

% perl -i.bak -npe 's/\r\n/\n/g' állományok

ahol az állományok az átalakítandó állományok. A konverzió helyben történik, illetve az eredeti állományokról .bak kiterjesztéssel létrejön egy biztonsági mentés.

Erre a célra viszont ugyanígy megfelel a tr(1) parancs is:

% tr -d '\r' < dos-szöveges-állomány > unix-szöveges-állomány

Ekkor a dos-szöveges-állomány lesz a DOS formátumú szöveges állomány, miközben a unix-szöveges-állomány fogja az eredményt tartalmazni. Ez valamivel gyorsabb a perl megoldásánál.

Ez említett megoldásokon kívül a DOS szöveges állományait a Portgyűjteményben található converters/dosunix porttal is könnyedén át tudjuk alakítani. Ennek részleteit a hozzá tartozó dokumentációból tudjuk meg.

Lásd killall(1).

Ezt a hibát az elosztott hitelesítést végző Kerberos rendszer adja. Maga a probléma nem végzetes, viszont annál inkább idegesítő. Ilyenkor vagy a -K kapcsolóval kell futtatni a su(1) programot, vagy a következő kérdésben megadottak szerint el kell távolítani a Kerberos alkalmazást.

A Kerberos úgy távolítható el a rendszerből, ha újratelepítjük a base terjesztés tartalmát. Ha CD-ről telepítettük a rendszert, akkor csatlakoztassuk (most tegyük fel, hogy a /cdrom könyvtárba) és futassuk a következő parancsot:

# cd /cdrom/base
# ./install.sh

Másik lehetőség, ha hozzáadjuk a NO_KERBEROS beállítást a /etc/make.conf állományhoz és újrafordítjuk az alaprendszert.

A FreeBSD 5.X és a későbbi változatok már a devfs(8) által felkínált automatikus megoldást alkalmazzák. Ilyenkor az eszközmeghajtók igény szerint hoznak létre eszközleírókat, és ezzel lényegében szükségtelenné teszik a /dev/MAKEDEV használatát.

Ha sok telnet, ssh, X esetleg screen felhasználónk van, akkor könnyen előfordulhat, hogy kifogyunk a pszeudoterminálokból. A FreeBSD 6.2 és az azt megelőző változatokban alapértelmezés szerint 256 pszeudoterminál, a FreeBSD 6.3 és későbbi változatokban pedig 512 pszeudoterminál áll rendelkezésünkre.

Váltsunk egyfelhasználós módba, majd vissza többfelhasználós módba.

Konzolon ez így oldható meg:

# shutdown now
(Megjegyzés: nincs -r vagy -h!)

# return
# exit

Röviden: Ez csak egy elnevezés. Az RC jelentése “Release Candidate”, vagyis “kiadásra jelölt”. Ez egy küszöbön álló kiadásra utal. A FreeBSD-ben a -PRERELEASE elnevezés általában egyenlő a kiadások előtt bekövetkező kódfagyasztással. (Bizonyos kiadások esetén pedig a -BETA címkét a -PRERELEASE megjelöléshez hasonlóan használják.)

Valamivel bővebben: A FreeBSD fejlesztésében a kiadások általában két helyről származnak. A nagyobb, ún. “nullás” kiadások, mint például 7.0-RELEASE és 8.0-RELEASE, a fejlesztési ág legfrissebb állapotából készülnek, amelyet gyakran csak -CURRENT néven emlegetnek. A kisebb kiadások, mint például a 6.3-RELEASE vagy az 5.2-RELEASE, az aktív -STABLE ágból származnak. A 4.3-RELEASE kiadástól kezdődően mindegyik kiadás saját ággal rendelkezik, amelyet elsősorban olyanoknak ajánlunk, akiknek csak nagyon visszafogott változtatásokra van szükségük a rendszerben (ezek általában csak különböző biztonsági javításokat takarnak).

Amikor a fejlesztők készíteni akarnak egy újabb kiadást, az alapjául szolgáló fejlesztési ágon elvégeznek bizonyos műveleteket. Ennek egy része a források “befagyasztása”. Amikor ez megkezdődik, az ág neve megváltozik, és ezzel jelzik, hogy hamarosan kiadás készül belőle. Például, ha egy ág a 6.2-STABLE nevet viseli, akkor a 6.3-PRERELEASE névre vált arra az időszakra, amíg tart a kódfagyasztás és lezajlik a kiadások megjelentetéséhez szükség további tesztelés. Hibajavítások ekkor továbbra is rakhatóak bele. Ahogy a források elérik a kiadáshoz szükséges szintet, az ág neve 6.3-RC-re vált, és ezzel jelzik, hogy a kiadás előkészítése hamarosan befejeződik. Az RC állapotban csak a legfontosabb hibákat keresik meg és javítják. Miután a kiadás (jelen esetünkben a 6.3-RELEASE kiadás) és a hozzá tartozó ág elkészült, az ág neve ismét 6.3-STABLE lesz.

A verziószámokról és a CVS-ben található különböző ágakról a Release Engineering című cikkben olvashatunk (angolul).

Rövid válasz: A rendszerünk valószínűleg nullánál nagyobb biztonsági szinten fut. Indítsuk újra a rendszerünket egyfelhasználós módban és úgy telepítsük a rendszermagot.

A hosszabb válasz: A FreeBSD nem engedi megváltoztatni a rendszerszintű állományjelzőket nullától a nagyobb biztonsági szinteken. A jelenleg érvényben levő biztonsági szintet a következő paranccsal lehet lekérdezni:

# sysctl kern.securelevel

A biztonsági szintet nem lehet csökkenteni. A rendszert egyfelhasználós módban kell újraindítani, mert csak úgy tudjuk újratelepíteni a rendszermagot. Másik lehetőségünk, ha átállítjuk a biztonsági szintet az /etc/rc.conf állományban és úgy indítjuk újra a rendszerünket. Az init(8) man oldalán olvashatunk bővebben a biztonsági szintek (securelevel) beállításáról, az rc.conf használatáról pedig az /etc/defaults/rc.conf állományból és a rc.conf(5) man oldalon tudhatunk meg többet.

A rövid válasz: A rendszerünkben a biztonsági szintet (securelevel) minden bizonnyal egynél nagyobbra állították. Indítsuk újra a rendszert egyfelhasználós módban és változtassuk meg a dátumot.

Egy hosszabb válasz: A FreeBSD nem engedi egy másodpercnél többel megváltoztatni az időt, ha az aktuális biztonsági szint értéke egy felett van. Ezt a következő parancs kiadásával tudjuk ellenőrizni:

# sysctl kern.securelevel

A biztonsági szint futás közben nem csökkenthető. A dátum megváltoztatásához ezért a rendszert egyfelhasználós módban kell indítanunk, vagy az /etc/rc.conf állományban csökkentenünk kell a biztonsági szintet. Az init(8) man oldalon olvashatunk részletesebben a biztonsági szintek működéséről, illetve az /etc/defaults/rc.conf állományból és az rc.conf(5) man oldalról tudhatunk meg többet az rc.conf működéséről.

Nem, itt szó sincs semmiféle memóriaszivárgásról, és egyébként sem használ 256 MB memóriát. Az rpc.statd parancs egyszerűen csak kényelmi megfontolásokból iszonyatos mennyiségű memóriát képez le a címterébe. Ebben technikailag semmi kivetnivaló nincsen, ezzel egyedül a top(1), ps(1) és a hozzá hasonló programokat zavarja meg egy kicsit.

A rpc.statd(8) tehát leképezi az állapotát rögzítő állományt (amely a /var könyvtárban található a címterébe. Ilyenkor igyekszik egy kicsit előre gondolkodni és felkészülni a megnövekedésére, ezért viszonylag nagy méretben hozza létre ezt a leképezést. Ezt nagyon jól megfigyelhetjük a forráskódjából is, ahol látszik, hogy a mmap(2) függvényt a 0x10000000 értékkel hívja meg, tehát az 32 bites Intel architektúrán megcímezhető memória egytizenhatod részével, ami pontosan 256 MB.

Rendszerünkben a biztonsági szint (securelevel) nagyobb nullánál. Próbáljuk meg csökkenteni az értékét és próbálkozzunk ismét. Ezzel kapcsolatban részletesebb információkat a a biztonsági szintekről szóló kérdésből vagy az init(8) man oldalról tudhatunk meg.

A legújabb FreeBSD verziókban azért nem tudjuk az .shosts állományon keresztül hitelesíteni magunkat, mert az ssh(1) alapértelmezés szerint rendszeradminisztrátori jogok nélkül kerül telepítésre. Ezt a “hibát” többféle módon ki tudjuk “javítani”:

• Ha tartós megoldásra van szükségünk, akkor az /etc/make.conf állományban állítsuk az ENABLE_SUID_SSH változót a true értékre, majd fordítsuk újra az ssh(1) programot (vagy futtassuk le a make world parancsot).

• Ha ideiglenesen akarjuk csak javítani, akkor az /usr/bin/ssh állomány engedélyeit root felhasználóként állítsuk a 4555 értékre a chmod 4555 /usr/bin/ssh parancs kiadásával. Ezután vegyük fel az ENABLE_SUID_SSH= true sort az /etc/make.conf állományt, így ez a változtatás a make world következő futtatásakor is megmarad.

A vnlru törli és szabadítja fel a rendszerben keringő vnode-okat, amikor a rendszermagban elérik a kern.maxvnodes változó által beállított határt. Ez a rendszermagban futó szál többnyire csak tétlenül ül a háttérben, és csak olyankor lép működésben, amikor rengeteg memóriát használunk és éppen több tízezernyi apró állományhoz akarunk egyszerre hozzáférni.

A lapok általában akkor kerülnek ki a lemezre (valamilyen VM alrendszerbeli szinkronizáció során), amikor inaktív állapotban vannak, de akár az aktív lapok is szinkronizálhatóak. Ez attól függ, hogy a processzor képes-e nyomkövetni a lapok módosítását, és némely helyzetekben előnyös lehet a rendszer számára, ha annak megfelelően szinkronizálja a VM lapjait, hogy azok aktívak vagy inaktívak. A legtöbb esetben itt egyszerűen csak egy olyan sort kell elképzelni, ahol a program számára viszonylag inaktív lapok találhatóak, amelyeket a rendszer tetszőlegesen a lemezre írhat. A tárazott lapok általában már eleve szinkronizáltak, nem leképzettek, közvetlenül a programok régi és új hozzárendelései használják ezeket. A szabad lapokat akár a megszakítások szintjén is lehet használni, miközben a tárazott vagy szabad lapokat a futó programokban érthetjük el. A tárazott lapok zárolása nem megfelelő ahhoz, hogy megszakításokban is el lehessen érni ezeket.

Vannak még bizonyos jelzések (például a foglaltságot vagy foglaltság mértékét jelző értékek), amelyek még hatással vannak a fentebb leírt szabályokra.

A “rendelkezésre álló memóriának” rengeteg típusa létezik. Ezek közül egyik az a memória, amely közvetlenül anélkül elérhető, hogy bármi mást ki kellene hozzá lapoznunk. Ennek a mérete nagyjából a tárazott és a szabad lapokat tároló sorok hosszával arányos (amelyet még a rendszer beállításaitól függő további tényezők is módosíthatnak). A “rendelkezésre álló memória” másik típusa a teljes VM terület mérete. Ezt nem olyan könnyű meghatározni, de leginkább a lapozóterület és a fizikai memória méretétől függ. A “rendelkezésre álló memória” több más lehetséges megfogalmazása is létezik, de szinte teljesen felesleges beszélni róluk. Egyedül az a fontos, hogy a igyekezzünk mérsékelni a lapozást és mindig legyen elegendő lapozóterületünk.

A /var/empty könyvtárat az sshd(8) program használja a privilégiumok elkülönítéséhez. A /var/empty könyvtárnak üresnek kell lennie, legyen a root tulajdonában és legyen rajta a schg állományjelző.

Noha semmiképpen sem javasoljuk a könyvtár törlését, úgy tudjuk elvégezni, ha először az schg állományjelzőt töröljük róla. A chflags(1) man oldalán olvashatunk ezzel kapcsolatban részletesebb információkat (azonban ne felejtsük el számításba venni az esetleges nehézségeket).

Az X Window System (vagy gyakran csak X11) a UNIX és UNIX-szerű operációs rendszereken, így többek közt a FreeBSD-n is az egyik leginkább elterjedt ablakozórendszer. A The X.Org Foundation felügyeli az X protokoll szabványait, azok aktuális referencia implementációival együtt. Ezek hivatalos megnevezése “Version 11 Release 7.5”, de ezt gyakran csak X11 néven rövidítik.

Számos implementációja is elérhető több különböző architektúrára és operációs rendszerre. A protokoll szerver oldali funkcióit megvalósító programokat hivatalosan “X szervereknek” nevezik.

Kezdetben a FreeBSD alapértelmezett X implementációja az XFree86™ volt, amelyet a The XFree86 Project, Inc. tartott karban. Ez a változat volt használatban alapértelmezés szerint egészen a FreeBSD 4.10 és 5.2 verziójáig. Habár eközben az Xorg maga is karbantartotta a saját változatát, kizárólag csak referencia célokat használt és az évek során teljesen leromlott az állapota.

2004 elején azonban az XFree86 néhány korábbi fejlesztője elhagyta a projektjüket, mivel nem értettek egyet bizonyos kérdésekben, például a forráskód ütemét, a jövőbeni irányokat és egyéb személyes konfliktusokat illetően, és helyette közvetlenül az Xorg kódját kezdték el fejleszteni. Ekkor az Xorg hozzáigazította forrásait az utolsó XFree86 kiadás forrásaihoz (XFree86 4.3.99.903), majd megváltoztatta a licencelését. és beolvasztott több, korábban külön karbantartott változtatást, aminek eredményeképpen végül megszületett az X11R6.7.0. Egy különálló, de velük együttműködő projekt, a freedesktop.org (vagy röviden csak fd.o) jelenleg is az eredeti XFree86 források újraszervezésén dolgozik, aminek célja a napjainkban megjelenő grafikus kártyák minél nagyobb mértékű kihasználása (és ezáltal a rendszer gyorsítása), a rendszer modularisabbá tétele (ezáltal a rendszer karbantarthatóságának javítása, ami a kiadások gyorsabb előkészítését és könnyebb beállíthatóságát teszi lehetővé). Az Xorg a jövőben tervezi a freedesktop.org fejlesztéseit is átvenni.

2004 júliusától kezdődően a FreeBSD-CURRENT változatban az XFree86 helyett az Xorg lett az alapértelmezett X implementáció. A FreeBSD-ben azóta is alapból az Xorg X11 implementációja található meg.

A témával kapcsolatban a kézikönyv X11-ről szóló fejezetében kaphatunk részletesebb felvilágosítást.

Ezt a kérdést ez a GYIK nem tudja megválaszolni. Ezzel kapcsolatban viszont érdemes elolvasnunk a különböző levelezési listák archívumait szerte az interneten. Keressünk rá a válaszra a kedvenc keresőnkben, de ezzel a kérdéssel ne a FreeBSD levelezési listáit zavarjuk. Az is elképzelhető, hogy ennek a valós okait csak néhányan ismerik egész teljesen.

Az Xorg fejlesztői azt ígérték, hogy gyorsabban fognak újabb verziókat kiadni, amelyek sokkal több újítást is fognak tartalmazni. Nos, amennyiben tényleg állják a szavukat, azzal mindenki jól jár. Emellett az ő változatuk továbbra is a hagyományos X licenc alatt érhető el, miközben az XFree86 licence ettől némileg eltér.

Amennyiben már egy meglévő rendszerre szeretnénk telepíteni az X-et, úgy érdemes a x11/xorg metaportot választanunk, amely magától feltelepíti az összes szükséges komponenst, vagy egyszerűen telepítsük az Xorg alkalmazást csomagból:

# pkg_add -r xorg

Emellett az Xorg a sysinstall(8) használatával is telepíthető: válasszuk a Configure (Beállítások), Distributions (Terjesztések), végül a The X.Org Distribution (Az X.Org terjesztés) menüpontokat.

Az Xorg sikeres telepítése után kövessük a kézikönyv X11 beállításával foglalkozó szakaszában leírtakat.

A rendszerünkön valószínűleg túlságosan magas a biztonsági szint (securelevel) értéke. Ilyenkor az X-et nem tudjuk elindítani, mivel a működéséhez szüksége van a io(4) eszköz írására. Ezzel kapcsolatban az init(8) man oldal ad részletesebb útmutatást.

A kérdés tehát az, hogy mit kellene ezzel csinálni. Alapvetően két lehetőségünk van: vagy visszaállítjuk a biztonsági szintet nullára (ezt általában az /etc/rc.conf állományon keresztül lehet megtenni), vagy az xdm(1) programot még a rendszerindítás során elindítjuk (mielőtt a biztonsági szintet magasabbra állítanánk).

A K: 11.12. szolgál arról bővebb információval, hogy miként tudjuk használni az xdm(1) programot a rendszer indítása során.

Ha a syscons(4) (vagyis az alapértelmezett konzol) meghajtót használjuk, akkor be tudjuk úgy állítani a FreeBSD-t, hogy minden virtuális képernyőn látható legyen az egérkurzor. A syscons(4) egy /dev/sysmouse nevű virtuális eszköz támogatásával igyekszik elkerülni azt, hogy összeakadjon az X-szel. A valós egértől érkező összes eseményt a moused(8) démon írja folyamatosan a sysmouse(4) eszközre. Amennyiben az egerünket egy vagy több virtuális konzolon is használni akarjuk az X-szel együtt, akkor nézzük meg a K: 4.5.4. válaszát és állítsuk be annak megfelelően a moused(8) démont.

Ezt követően nyissuk meg az /etc/X11/xorg.conf állományt és gondoskodjunk róla, hogy a következő sorok feltétlenül szerepeljenek benne:

Section "InputDevice"
   Option          "Protocol" "SysMouse"
   Option          "Device" "/dev/sysmouse"
.....

Az Xorg 7.4 változatától kezdődően az xorg.conf állomány InputDevice szekciói nem kerülnek feldolgozásra a csatlakoztatott eszközök automatikus érzékelése esetén. A korábbi viselkedési mód visszaállításához vegyük fel a következő sort a ServerLayout vagy ServerFlags szekciók valamelyikébe:

Option "AutoAddDevices" "false"

Néhányan inkább a /dev/mouse eszközt szeretik használni X alatt. Ha mi is így akarjuk használni, akkor a /dev/mouse eszközhöz hozzunk létre egy szimbolikus linket a /dev/sysmouse eszközre (lásd sysmouse(4)). Ezt úgy tudjuk megtenni, ha az /etc/devfs.conf állományba (lásd devfs.conf(5)) felvesszük a következő sort:

link    sysmouse    mouse

A link maga közvetlenül a devfs(5) újraindításával keletkezik. Ehhez (root felhasználóként) a következő parancsot kell kiadnunk:

# /etc/rc.d/devfs restart

Igen.

Jelezni kell az X-nek, hogy ötgombos egerünk van. Ezt úgy tudjuk megcsinálni, ha az /etc/X11/xorg.conf állományba felvesszük a Buttons 5 és ZAxisMapping 4 5 sorokat az “InputDevice” szakaszba. Vegyük például, hogy az /etc/X11/xorg.conf állományunkban a következő “InputDevice” szakasz található.

Section "InputDevice"
   Identifier      "Mouse1"
   Driver          "mouse"
   Option          "Protocol" "auto"
   Option          "Device" "/dev/sysmouse"
   Option          "Buttons" "5"
   Option          "ZAxisMapping" "4 5"
EndSection

;; görgős egér
(global-set-key [mouse-4] 'scroll-down)
(global-set-key [mouse-5] 'scroll-up)

Biztonsági okokból a szerver alapértelmezés szerint nem engedélyezi, hogy egy távoli gépről ablakot lehessen nyitni rajta.

Ha szükségünk lenne erre a lehetőségre, akkor nem kell mást tennünk, mint az X-et a -listen_tcp paraméterrel indítani:

% startx -listen_tcp

A virtuális konzolok röviden szólva arra alkalmasak, hogy egyetlen gépen is több párhuzamos munkamenetben tudjunk dolgozni, hálózat vagy X beállítása nélkül.

Amikor a rendszer elindul, a rendszerüzenetek után általában egy bejelentkező képernyő jelenik meg. Ekkor az első virtuális konzolon keresztül tudjuk megadni a felhasználói nevünket és jelszavunkat, majd nekilátni a munkának (vagy éppen a játszadozásnak).

Később aztán előfordulhat, hogy egy másik munkamenetet is szeretnénk elindítani, például előkeresni az éppen használt program dokumentációját vagy elolvasni a leveleinket, amíg FTP-n keresztül letöltünk egy állományt. Ehhez nem kell mást csinálnunk, csak le kell nyomni az Alt+F2 (tartsuk lenyomva az Alt billentyűt miközben megnyomjuk az F2 billentyűt) billentyűkombinációt és máris egy másik virtuális konzolon találjuk magunkat! Ha innen vissza szeretnénk térni az előző munkamenetbe, akkor nyomjuk le az Alt+F1 billentyűkombinációt.

A frissen telepített FreeBSD rendszerekben alapértelmezés szerint nyolc virtuális konzol engedélyezett. Az Alt+F1, Alt+F2, Alt+F3, stb. lenyomásával tudunk váltogatni köztük.

Ha ennél többet szeretnénk egyszerre használni, akkor nyissuk meg az /etc/ttys állományt (lásd ttys(5)) és a “Virtual terminals” részben vegyünk még fel a ttyv8 eszköz után továbbiakat, egészen a ttyvc eszközig:

# Írjuk át az eredeti ttyv8 bejegyzést az /etc/ttys
# állományban és engedélyezzük.
ttyv8   "/usr/libexec/getty Pc"         cons25  on secure
ttyv9   "/usr/libexec/getty Pc"         cons25  on secure
ttyva   "/usr/libexec/getty Pc"         cons25  on secure
ttyvb   "/usr/libexec/getty Pc"         cons25  on secure

Akármennyit használhatunk belőlük. Ne felejtsük el azonban, hogy minél több virtuális terminálunk van, annál több erőforrásra lesz hozzájuk szükségünk. Ezt leginkább akkor érdemes megfontolni, ha 8 MB memóriánál kevesebbel rendelkezünk. Emellett még érdemes a secure értéket is az insecure értékre átállítani.

Az egyes konzolokat legegyszerűbben úgy tudjuk letiltani, ha kikapcsoljuk ezeket. Például, ha az előbb említettek szerint tizenkét terminálunk van, és X-et akarunk futtatni, akkor a tizenkettedik terminál beállításait meg kell változtatnunk erről:

ttyvb   "/usr/libexec/getty Pc"         cons25  on  secure

erre:

ttyvb   "/usr/libexec/getty Pc"         cons25  off secure

Amennyiben a billentyűzetünkön csak tíz funkcióbillentyű található, elengedő ennyi is:

ttyv9   "/usr/libexec/getty Pc"         cons25  off secure
ttyva   "/usr/libexec/getty Pc"         cons25  off secure
ttyvb   "/usr/libexec/getty Pc"         cons25  off secure

(Ezeket a sorokat akár ki is törölhetjük.)

Ezt követően a legegyszerűbben (és egyben a legtisztábban) úgy tudjuk aktiválni a virtuális konzolokat, ha újraindítjuk a rendszerünket. Ha viszont nem akarjuk ezt feltétlenül megtenni, akkor állítsuk le az X szervert, majd (root felhasználóként) adjuk ki az alábbi parancsot:

# kill -HUP 1

Fontos, hogy a parancs végrehajtás előtt teljesen leállítsuk az X szervert, amennyiben az fut. Ha nem tesszük meg, akkor könnyen előfordulhat, hogy a kill parancs hatására lemerevedik vagy megáll a rendszerünk.

A virtuális konzolokra a Ctrl+Alt+FN billentyűkombinációval lehet visszaváltani. Ennek megfelelően tehát a Ctrl+Alt+F1 kombinációval az első virtuális konzolra tudunk visszaváltani.

Ahogy visszajutottunk a szöveges konzolra, az Alt+Fn billentyűkombinációval a megszokott módon tudunk váltani köztük.

Ha innen az X szerverre akarunk visszaváltani, akkor egyszerűen csak váltsunk arra a virtuális konzolra, ahol az X fut. Ha az X-et a paranccsorból indítottuk el (például a startx paranccsal), akkor az X nem arra a virtuális konzolra kapcsolódik automatikusan, amelyen a parancsot kiadtuk, hanem az utána következő, használatban még nem levő konzolra. Ha nyolc aktív virtuális terminálunk van, akkor az X a kilencediken fog futni, ezért ide az Alt+F9 lenyomásával tudunk visszatérni.

Alapvetően kétféle megközelítés létezik az xdm(1) elindításával kapcsolatban. Az egyik megközelítés szerint az xdm parancsot az /etc/ttys állományból (lásd ttys(5)) tudjuk megadni a megadott példa alapján, a másikban pedig egyszerűen az rc.local állományból (lásd rc(8)) vagy a /usr/local/etc/rc.d könyvtárban megadható X szkripttel. Mind a kettő ugyanazt képviseli, de vannak bizonyos helyzetek, ahol a kettő közül csak az egyik működik. Az eredmény mind a két esetben azonos, hatásukra az X egy grafikus bejelentkező képernyővel jelentkezik.

A ttys(5) módszernek van egy olyan előnye, hogy pontosan megadja, melyik virtuális terminálon fog futni az X és a szerver elindítását az init(8) programra bízza. Az rc(8) használata esetén viszont könnyű leállítani az xdm programot, ha netalán valamilyen gondunk adódna az X szerver indításakor.

Ha az rc(8) állományból töltöttük be, akkor az xdm futtatásához semmilyen paramétert nem kell megadni (például, hogy démonként fusson). Az xdm(1) azonban csak az összes getty(8) elindulása után indítható, máskülönben a két program ütközni fog és a konzol nem tud létrejönni. Ezt a legkönnyebben úgy lehet megakadályozni, ha az xdm indítása előtt várunk kb. 10 másodpercet a szkriptben.

Amennyiben az /etc/ttys állományból adjuk ki az xdm parancsot, úgy továbbra is fennáll az xdm(1) és a getty(8) ütközésének veszélye. Ezt például úgy tudjuk elkerülni, ha felvesszük a megfelelő virtuális terminál sorszámát a /usr/local/lib/X11/xdm/Xservers állományba:

:0 local /usr/local/bin/X vt4

A fenti példában az X szervert a /dev/ttyv3 eszközre irányitjuk. A számozást azonban eggyel el kell tolnunk, mert míg az X szerver egytől számozza a virtuális konzolokat, addig a FreeBSD rendszermagja nullától.

Ha az X-et a startx paranccsal indítottuk el, akkor a /dev/console eszközre nem állítódnak be a szükséges engedélyek, ezért az xterm -C és az xconsole parancsok nem fognak működni.

Ez a konzolok engedélyeinek alapértelmezett beállítási módjától függ. Egy többfelhasználós rendszer esetén nem feltétlenül van szükségünk arra, hogy bármelyik felhasználó kedvére írhasson a rendszerkonzolra. Az fbtab(5) állomány segítségével engedélyezni tudjuk azon felhasználók számára, akik a helyi gépen, virtuális konzolon keresztül jelentkeznek be.

Dióhéjban az /etc/fbtab állományban (lásd fbtab(5)) kell kivennünk a következő sort a megjegyzésből:

/dev/ttyv0 0600 /dev/console

Ennek köszönhetően bárki, aki az /dev/ttyv0 eszközön keresztül jelentkezik be a rendszerbe, el tudja érni a konzolt.

Az X szerverek csak úgy képesek közvetlenül elérni a videokártyát, ha root felhasználóként futtatjuk ezeket. Az XFree86 régebbi (3.3.6 előtti) változatai az összes szervert úgy telepítették fel automatikusan, hogy a root felhasználó jogaival fussanak (setuid bittel). Ennek viszont megvan a maga nyilvánvaló biztonsági kockázata, hiszen az X szerverek általában nagy és bonyolult programok. Az XFree86 újabb változatai azonban már pontosan ebből kifolyólag nem állítanak be setuid root bitet a szerverekre.

Értelemszerűen az a megoldás nem fogadható el és nem is annyira biztonságos, hogy az X szervert root felhasználóként futtassuk. Kétféleképpen tudjuk egyszerű felhasználóként futtatni az X-et. Használhatjuk az xdm vagy más egyéb bejelentkeztető képernyő (mint például a kdm) megoldását, vagy az Xwrapper programot.

Az xdm egy grafikus bejelentkeztetésért felelős démon. Általában a rendszer indításakor aktiválódik, feladata a felhasználók hitelesítése és a hozzájuk tartozó munkamenetek elindítása. Lényegében a getty(8) és a login(1) grafikus megfelelője. Az xdm démonnal kapcsolatban még az XFree86 dokumentációját, illetve a GYIK-ban ezt a kérdést érdemes elolvasnunk.

Az Xwrapper az X szerverhez tartozó burkolóprogram (wrapper). Ez egy apró segédprogram, amely lehetővé teszi az X szerver manuális indítását miközben igyekszik ügyelni a biztonságra is. Elvégez néhány alapvető ellenőrzést a paramétereken, és ha megfelelőnek találja ezeket, akkor elindítja a megfelelő X szervert. Ha valamiért nem akarunk bejelentkeztető képernyőt indítani, akkor ezt pontosan nekünk találták ki! Ha telepítettük a teljes Portgyűjteményt, akkor a /usr/ports/x11/wrapper portban találjuk meg.

Valószínűleg az egér és az egérmeghajtó kiesett a szinkronból.

Nagyon ritkán előfordul, hogy a meghajtó hibásan szinkronizációs hibát jelez, és ekkor a rendszermag a következő üzenetet küldi:

psmintr: out of sync (xxxx != yyyy)

Közben természetesen azt tapasztaljuk, hogy az egerünk nem működik rendesen.

Ha ilyen történne velünk, akkor tiltsuk le a meghajtó szinkronizáció ellenőrzéséért felelős rutinjait. Ezt úgy tudjuk megtenni, ha a meghajtónak beállítjuk a 0x100 értéket. Ehhez a rendszertöltő parancssorában a -c kapcsolóval tudjuk behozni a UserConfig részt:

boot: -c

Ezután a UserConfig parancssorában gépeljük be a következőt:

UserConfig> flags psm0 0x100
UserConfig> quit

Kaptunk néhány visszajelzést arra vonatkozóan, hogy a MouseSystems által gyártott PS/2-es egerek bizonyos típusai csak abban az esetben működnek rendesen, ha “nagy felbontású” módban használjuk ezeket. Minden más esetben az egér néha fel-felugrik a képernyő bal felső sarkába.

Úgy tudjuk nagy felbontású módban használni az egerünket, ha a PS/2-es egérmeghajtónak a 0x04 beállítást adjuk meg. Ehhez a rendszertöltő parancssorában gépeljük be a -c kapcsolót:

boot: -c

Ahogy bejön a UserConfig parancssora, gépeljük be a következőt:

UserConfig> flags psm0 0x04
UserConfig> quit

Az előző részben olvashatunk egy másik hasonló egeres problémáról.

Futtassuk le a xmodmap -e "pointer = 3 2 1" parancsot az .xinitrc vagy .xsession állományunkból.

Erre a kérdésre részletes választ a FreeBSD kézikönyv Rendszerbetöltő képernyők című szakaszában kapunk.

Igen. Ehhez mindössze az xmodmap(1) használatával meg kell adni a hozzájuk tartozó funkciót.

Feltéve, hogy mindegyik “Windows” billentyűzet szabványos, a következő billentyűkódok tartoznak ehhez a három plusz gombhoz:

• 115 — Windows billentyű, a bal oldali Ctrl és Alt billentyűk között

• 116 — Windows billentyű, az AltGr mellett jobbra

• 117 — Menü gomb, a jobb oldali Ctrl mellett balra

Például így lehet beállítani a bal oldali Windows billentyűt vesszőre:

# xmodmap -e "keycode 115 = comma"

A változatatások valószínűleg csak akkor fognak életbelépni, ha újraindítjuk az ablakkezelőnket.

Ha azt szeretnénk, hogy a Windows billentyűkhöz rendelt funkciók az X indításakor automatikusan beállítódjanak, akkor tegyük az xmodmap parancs hívását az ~/.xinitrc állományunkba. Sokkal jobban járunk viszont, ha ehelyett inkább az ~/.xmodmaprc állományunkba vesszük fel az xmodmap beállításait, soronként egyesével, és a következő sor tesszük az ~/.xinitrc állományunkba:

xmodmap $HOME/.xmodmaprc

Például ezeket a gombokat be lehet állítani az F13, F14 és F15 billentyűkre is. Ezekre aztán az alkalmazásokban vagy az ablakkezelőben további hasznos funkciókat tudunk beállítani.

Ehhez a következőt kell megadnunk az ~/.xmodmaprc állományban:

keycode 115 = F13
keycode 116 = F14
keycode 117 = F15

Ha például az x11-wm/fvwm2 ablakkezelőt használjuk, akkor az F13 gombra be tudjuk állítani a kurzor alatt álló ablak lekicsinyítésére (vagy visszanagyítására); az F14 billentyűvel az előtérbe tudjuk hozni a kurzor alatt levő ablakot, vagy ha már elöl van, akkor hátra tudjuk rakni; az F15 gomb előhozza a munkakörnyezet (alkalmazás) menüjét még olyankor is, amikor a kurzor nincs is az asztalon. Ez utóbbi abban az esetben lehet hasznos, amikor az asztal egyáltalán nem látható (és a billentyűn látható rajz pontosan is ezt mutatja).

A következő beállítások valósítják meg az imént említett funkciókat az ~/.fvwmrc állományon belül:

Key F13        FTIWS    A        Iconify
Key F14        FTIWS    A        RaiseLower
Key F15        A        A        Menu Workplace Nop

Az Xorg pillanatnyilag használt verziójától és a videokártyánktól függ, hogy tudunk-e 3D gyorsítást alkalmazni. Ha nVidia kártyánk van, akkor a portok közül telepíteni tudjuk a FreeBSD-hez készített bináris meghajtót:

• A legújabb nVidia-kártyákat az x11/nvidia-driver port támogatja.

• A GeForce2 MX/3/4 sorozatú nVidia-kártyákat a meghajtó 96XX változata támogatja, amely az x11/nvidia-driver-96xx portból telepíthető.

• Az ettől is régebbi kártyák, például a GeForce vagy Riva TNT esetén a meghajtó 71XX változata javasolt, amely az x11/nvidia-driver-71xx porton keresztül érhető el.

Az nVidia honlapján részletes leírást találhatunk arról, hogy melyik kártyát melyik meghajtó ismeri. Ez az információ a következő címen érhető el: http://www.nvidia.com/object/IO_32667.htm.

A Matrox G200/G400 esetén az x11-servers/mga_hal portot érdemes megnéznünk.

ATI Rage 128 és Radeon kártyák számára a ati(4), r128(4) és radeon(4) man oldalakat ajánljuk.

3dfx Voodoo 3, 4, 5 és Banshee kártyák számára az x11-servers/driglide port áll rendelkezésre.

A “lemez nélküli működés” kifejezés arra utal, hogy a FreeBSD rendszerünk hálózaton keresztül indul el, valamint a működéséhez szükséges állományokat nem merevlemezről, hanem egy szerverről olvassa be. Ennek részleteiről kézikönyv lemez nélküli működésről szóló részében olvashatunk.

Igen. Ezzel kapcsolatban a kézikönyv Egyéb haladó hálózati témák című fejezetét javasoljuk elolvasásra, különös tekintettel az útválasztás és az átjárók bemutatására.

Ezt a kérdést általában olyanok teszik fel, akiknek két számítógépük van otthon, és ezek közül az egyiken a FreeBSD, a másikon pedig a Windows valamelyik változata fut. A FreeBSD rendszer fog az internethez csatlakozni, és ezen keresztül szeretnénk a windowsos gépről is elérni azt. Ez tulajdonképpen az előző kérdés egy speciális esete, és remekül megoldható.

Ha betárcsázós kapcsolattal csatlakozunk az internethez, akkor érdemes tudnunk, hogy a felhasználói módban futó ppp(8) tartalmaz egy -nat kapcsolót. A ppp(8) programot úgy tudjuk a -nat kapcsolóval futtatni, ha az /etc/rc.conf állományban a gateway_enable beállítást a YES értékre állítjuk. Ezután állítsuk be a windowsos gépünket ennek megfelelően és minden működni fog. A további részletekről a ppp(8) man oldalán vagy a kézikönyv felhasználói PPP-ről szóló bejegyzésében olvashatunk.

Amennyiben rendszerszintű PPP-t használunk vagy Ethernettel csatlakozunk az internethez, akkor a natd(8) démonra lesz szükségünk. Erre vonatkozóan a kézikönyv natd démonról szóló szakaszában találhatunk részletesebb információkat.

Igen. Érdemes elolvasnunk az slattach(8), sliplogin(8), ppp(8) és pppd(8) man oldalakat. A ppp(8) és a pppd(8) egyaránt támogatja a beérkező és kimenő kapcsolatokat, miközben a sliplogin(8) kizárólag csak beérkező kapcsolatokkal dolgozik, valamint a slattach(8) pedig csak kimenő kapcsolatokkal.

Ezek pontos használatáról olvassuk el a kézikönyv PPP-ről és a SLIP-ről szóló fejezetét.

Ha viszont csak egy “shellen” keresztül érjük el az internetet, akkor hasznos lehet megnéznünk a net/slirp csomagot. Segítségével a helyi gépről (korlátozott módon) hozzá tudunk férni különböző FTP és HTTP szolgáltatásokhoz.

Igen. Ha egy felhasználói PPP kapcsolat esetén szeretnénk hálózati címfordítást alkalmazni, akkor olvassuk el a kézikönyv felhasználói PPP-vel foglalkozó részét. Ha viszont más típusú hálózati kapcsolatok esetén kívánunk címfordítást használni, akkor ahhoz a kézikönyv natd démonnal kapcsolatos részét kell fellapoznunk.

Ezt illetően a kézikönyv PLIP-ről szóló szakaszát érdemes megnéznünk.

Amennyiben az álnév ugyanazon az alhálózaton található, mint a hozzá tartozó interfész, akkor egyszerűen csak adjuk meg a netmask 0xffffffff paramétert az ifconfig(8) parancs meghívásakor, például így:

# ifconfig ed0 alias 192.0.2.2 netmask 0xffffffff

Minden más esetben a hagyományos módon adjunk meg egy hálózati címet és egy hálózati maszkot:

# ifconfig ed0 alias 172.16.141.5 netmask 0xffffff00

Erről bővebben a FreeBSD kézikönyvben olvashatunk.

Ha a kártyán egy másik portot szeretnénk használni, akkor ahhoz meg kell adnunk egy további paramétert a ifconfig(8) meghívásakor. Itt az alapértelmezett port a link0. Ha a BNC helyett az AUI portot akarjuk használni, akkor ennek a link2 értéket kell megadnunk. Az ilyen típusú beállítások az /etc/rc.conf állomány (lásd rc.conf(5)) ifconfig_* változóival adhatóak meg.

A személyi számítógépekben található bizonyos hálózati kártyák (szépen szólva) ügyesebbek a többieknél, ami az olyan komolyabb hálózati alkalmazások, mint például az NFS esetén gondokat okozhat.

Ezzel kapcsolatban kézikönyv NFS-ről szóló részét érdemes megnéznünk.

A Linux egyes változataiban található NFS kód csak bizonyos privilegizált portokról fogad el kéréseket. Próbáljuk meg a következőt:

# mount -o -P linux:/valami /mnt

A SunOS™ 4.X változatait futtató munkaállomások csak privilegizált portokról fognak el kéréseket. Próbálkozzunk az alábbi paranccsal:

# mount -o -P sun:/valami /mnt

Ez leginkább azért történik, mert nem jól adtuk meg az /etc/exports állomány tartalmát. Olvassuk át a exports(5) man oldalt és a kéziköny NFS-ről szóló részét, különös tekintettel az NFS beállítására.

Próbáljuk meg az /etc/rc.conf állományban (lásd rc.conf(5)) kikapcsolni a TCP kiterjesztések használatát úgy, hogy az alábbi változót a NO értékre állítjuk:

tcp_extensions=NO

A Xylogic által gyártott Annex típusú gépek esetén is javasolt megtenni a fenti változtatást.

A FreeBSD alapértelmezés szerint támogatja a multicast műveleteket. Amennyiben egy multicast küldéseket közvetítő útválasztót szeretnénk beállítani, akkor újra kell fordítanunk a rendszermagunkat a MROUTING beállítás használatával és elindítani a mrouted(8) démont. Ez a démon úgy aktiválható a rendszer minden egyes indításakor, ha az /etc/rc.conf állományban az mrouted_enable változót YES értékűre állítjuk.

Az MBONE használatához további eszközök találhatóak a külön mbone kategóriában a Portgyűjeményen belül. Ha a vic és vat nevű konferenciaszervező eszközöket keressük, akkor itt érdemes szétnéznünk!

Glen Foster (<gfoster@driver.nsta.org>) a következő listát állította össze róluk, amelyet kiegészítettünk még néhány további elemmel:

Erre a FreeBSD kézikönyvben találjuk meg a választ.

Amennyiben a rendszermagot az IPFIREWALL beállítással fordítottuk le, akkor nem szabad elfelejtenünk, hogy ez alapértelmezés szerint minden olyan csomagot eldob, amelyet külön nem engedélyeztünk.

Ha véletlenül rosszul állítottuk volna be a rendszerünkön futó tűzfalat, akkor a hálózat működését úgy tudjuk visszaállítani, ha root felhasználóként kiadjuk a következő parancsot:

# ipfw add 65534 allow all from any to any

Az /etc/rc.conf állományban is megadhatjuk ehhez a firewall_type="open" sort.

Ha a tűzfalak beállításáról szeretnénk többet megtudni FreeBSD alatt, akkor olvassuk el a kézikönyv erre vonatkozó fejezetét.

Valószínűleg azért, mert nem egyszerűen a csomagok továbbítására (forward) van szükségünk, hanem hálózati címfordításra. Az “fwd” szabály pontosan azt csinálja, amiről a nevét kapta: csomagokat továbbít, de azokon belül semmit sem változtat meg. Tegyük fel, hogy van egy ilyen szabályunk:

01000 fwd 10.0.0.1 from any to ize 21

Amikor egy csomag az ize célcímmel megérkezik a 10.0.0.1 gépre, akkor benne a cél címe továbbra is az ize lesz! A csomag célcíme nem fog magától megváltozni a 10.0.0.1 címre. A legtöbb gép általában eldobja azokat a csomagokat, amelyeket nem egyenesen neki címeztek. Emiatt a “fwd” szabály használata nem minden esetben úgy működik, ahogy arra a felhasználó számít. Ez viszont ilyen, semmilyen hiba nincs benne.

Részletesebb információkat a szolgáltatások átirányításával foglalkozó GYIK-ban, a natd(8) man oldalán vagy a Portgyűjtemény valamelyik port átirányítással foglalkozó portjának dokumentációjában találhatunk.

Az FTP (vagy más egyéb szolgáltatás-) kéréseket a Portgyűjteményen belül található sysutils/socket porttal tudunk átirányítani. Az adott szolgáltatás helyett egyszerűen csak adjuk meg a socket parancsot és annak paramétereit, valahogy így:

ftp stream tcp nowait nobody /usr/local/bin/socket socket ftp.minta.com ftp

ahol az ftp.minta.com az a gép, ahová át akarjuk irányítani a szolgáltatást, az ftp pedig a konkrét szolgáltatás.

FreeBSD alatt alapvetően három eszköz szolgál erre a célra. A dummynet(4) a FreeBSD részeként megtalálható ipfw(4) egyik komponense. Az ALTQ a FreeBSD-ben található pf(4) rendszer része, az Emerging Technologies által fejlesztett Bandwith Manager pedig egy kereskedelmi termék.

Olyan programot akarunk futtatni, amelynek szüksége van a Berkeley Packet Filter (bpf(4)) használatára, azonban a rendszermag ezt nem tartalmazza. Úgy tudjuk aktiválni, ha a rendszermag konfigurációs állományába felvesszük a következő sort, majd fordítunk egy új rendszermagot:

device bpf        # Berkeley Packet Filter

Erre az SMBFS eszközeit használhatjuk, amely tartalmazza az ehhez szükséges rendszermagbeli módosításokat és a hozzá tartozó felhasználói programokat. Ezek a programok és a hozzájuk tartozó mount_smbfs(8) man oldal az alaprendszer részei.

Ilyen üzeneteket akkor kapunk a rendszermagtól, ha valaminek a hatására több ICMP vagy TCP reset (RST) választ küld, mint amennyit kellene. Az ICMP válaszok sokszor olyankor generálódnak, amikor használaton kívüli UDP portokat akarnak elérni a rendszerünkön. A TCP reset pedig általában olyankor keletkezik, amikor meg nem nyitott TCP porthoz akarnak csatlakozni. Többek közt ilyenek okozhatják:

• A rendszer túlterhelését célzó, nyers erővel indított Denial of Service (Dos) támadások (ellentétben az egycsomagos, adott sebezhetőség kihasználó támadásokkal).

• A portok szisztematikus letapogatása, amelynek során egyszerre nagy mennyiségű portot próbálnak meg átvizsgálni (ellentétben azzal, amikor csak néhány jól ismert portot nyitnak meg).

Az üzenetben olvasható első szám azt mondja meg, hogy a rendszermag mennyi csomagot küldött volna, ha nem korlátoztuk volna, a második pedig magát a határt jelzi. Ezt a net.inet.icmp.icmplim sysctl változó segítségével tudjuk beállítani, ahogy például most megnöveljük az értékét 300-ra:

# sysctl -w net.inet.icmp.icmplim=300

Amennyiben le szeretnénk tiltani az ilyen jellegű üzeneteket a naplókban, viszont még továbbra is szükségünk lenne a válaszküldés korlátozására, a net.inet.icmp.icmplim_output sysctl változó segítségével így tudjuk ezt megtenni:

# sysctl -w net.inet.icmp.icmplim_output=0

Végezetül, ha teljesen ki akarjuk kapcsolni a válaszküldés korlátozását, akkor állítsuk a net.inet.icmp.icmplim sysctl változót (lásd az előbbi példában) a 0 nulla értékre. A korlát törlése azonban a fenti okok miatt egyáltalán nem ajánlott.

Ez arra utal, hogy valamelyik gép a helyi Ethernet-alapú hálózatunkon olyan MAC-címet használ, amelynek a FreeBSD nem ismeri a formátumát. Valószínűleg olyankor kapjuk ezt a hibaüzenetet, amikor valaki más kísérletezik az Ethernet kártyája beállításaival valahol a hálózaton. Leggyakrabban kábelmodemes hálózatokon tapasztalhatunk ilyet. Megnyugodhatunk, teljesen veszélytelen, semmilyen hatással nincs a FreeBSD gépünk teljesítményére.

Ilyen üzeneteket akkor kapunk, amikor a hálózaton kívülről érkezik hozzánk váratlanul egy csomag. A letiltásukhoz állítsuk a net.link.ether.inet.log_arp_wrong_iface értékét 0-ra.

Először is nézzük meg, hogy az iménti hibaüzenet mellett nem látunk-e valami hasonlót:

/usr/libexec/ld-elf.so.1: Shared object "libXaw.so.6" not found

Az ilyen jellegű hibák általában olyankor keletkeznek, amikor olyan gépre telepítjük a net/cvsup portot, amelyen viszont nem található meg a Xorg programcsomag. Amennyiben szükségünk lenne CVSup programhoz mellékelt grafikus felületre, akkor kénytelenek leszünk mellé az Xorg programjait is telepíteni. Ha viszont egyszerűen csak parancssorból szeretnénk használni a CVSup lehetőségeit, töröljük le a korábban telepített csomagot, majd helyette rakjuk fel a net/cvsup-without-gui vagy a net/csup portot. A FreeBSD újabb változataiban megpróbálkozhatunk a csup(1) használatával is. Ezzel a témával részletesebban a kézikönyv CVSup használatáról szóló része foglalkozik.

A járóka alapvetően egy biztonsági szakkifejezés. Két dolgot jelenthet:

• Egy virtuális falak között futó programot, melyeket azért emeltek a program köré, hogy a feltörését követően megakadályozzák a rendszer többi részének elérését.

  A program csak a falon belül “játszhat”. Ilyenkor semmilyen olyan kódot nem képes futtatni, amellyel át tudna lépni a falakon, így a használatához nem kell előzetesen átvizsgálni a forrásait ahhoz, hogy meg tudjuk győződni a biztonságosságáról.

  Ez a fal lehet például egy felhasználói azonosító. A security(7) és named(8) man oldalakon is ezt a definíciót találjuk meg.

  Vegyük például az ntalk szolgáltatást (lásd inetd(8)). Ezt a szolgáltatást korábban a root felhasználó azonosítójával futtatták, de manapság viszont már a tty felhasználóval fut. A tty felhasználó lényegében egy olyan járóka, amely az ntalk szolgáltatás feltörésekor nem engedi, hogy a rendszer többi részéhez is hozzá lehessen férni.

• A valódi gépet utánzó rendszerben futó programot. Ez már egy sokkal kifinomultabb megoldás. Ha ilyenkor valakinek sikerül betörnie a programba, akkor könnyen azt hiheti, hogy sikerült a rendszer többi részét is elérnie, de valójában csak egy szimulált gépen van, és semmilyen valós adatot nem képes módosítani.

  Leggyakrabban ezt úgy szokták elérni, hogy egy könyvtárban létrehoznak egy szimulált környezetet, majd itt futtatják az adott programot a chroot(8) segítségével. (Ekkor az iménti könyvtár lesz a gyökérkönyvtár az adott folyamat számára, nem pedig a rendszer igazi gyökere.)

  Másik szintén gyakori megoldás a használt állományrendszerek írásvédett csatlakoztatása, amely felett aztán kialakítanak a program számára egy látszólag írható réteget. Ilyenkor a program teljesen úgy érzékeli, hogy képes a rendszerben elérhető állományokat módosítani, azonban egyedül csak saját maga látja ezeket, a rendszerben futó többi program viszont nem feltétlenül.

  Ezeket a járókákat általában úgy szokták felépíteni, hogy a felhasználók (vagy a támadók) számára teljesen észrevétlenek legyenek.

A UNIX két alapvető járókát valósít meg. Az egyik a futó programok, a másik pedig a felhasználói azonosítók szintjén működik.

Futása közben minden UNIX program teljesen elszigetelt minden más UNIX programtól, így az egyik nem képes módosítani a másik memóriában tárolt adatait. A Windows-tól eltérően, ahol ugyebár az egyik program könnyedén el tudja érni egy másik memóriaterületét, ezért a program nem képesek egymásban kárt tenni.

A UNIX alatt futó programok mindig egy adott felhasználóhoz tartoznak. Ha ez nem a root felhasználó, akkor azzal lényegében egy tűzfalat hozunk létre a különböző felhasználók által birtokolt folyamatok között. A felhasználók azonosítói emellett segítenek a lemezen tárolt adatokat is elszigetelni egymástól.

A biztonsági szintek egy rendszermagon belül megvalósított védelmi módszert képviselnek. A pozitív értékű biztonsági szintek esetén a rendszermag korlátoz bizonyos feladatokat, amelyeket ilyenkor még a rendszeradminisztrátor (vagyis a root felhasználó) sem képes elvégezni. Az írás pillanatában a biztonsági szintek, több más dolog mellett, a következők szabályozására alkalmasak:

• a különböző állományjelzők, például az schg (a “system immutable” jelzés) törlése;

• a rendszermag memóriájának elérése a /dev/mem és /dev/kmem eszközökön keresztül;

• a rendszermag moduljainak betöltése;

• a tűzfal szabályainak módosítása.

A jelenleg futó rendszer biztonsági szintjét a következő parancs segítségével lehet lekérdezni:

# sysctl kern.securelevel

A parancs eredménye az adott sysctl(8) változó (vagyis esetünkben a kern.securelevel) és annak értéke lesz, amely egy szám. Ez utóbbi adja meg a biztonsági szint aktuális értékét. Amennyiben ez pozitív (vagyis nullánál nagyobb), akkor érvényben vannak a biztonsági szintekhez kapcsolódó bizonyos korlátozások.

Egy működő rendszer biztonsági szintjét nem lehet csökkenteni, hiszen ezzel tulajdonképpen hatástalanná tennénk. Ha olyan feladatot akarunk végrehajtani, amely nem pozitív biztonsági szintet igényel (például az alaprendszer frissítése vagy a dátum átállítása), akkor ahhoz először módosítanunk kell az /etc/rc.conf állományt (lásd kern_securelevel és kern_securelevel_enable változók), majd újraindítani a rendszert.

A biztonsági szintekkel és rájuk vonatkozó információkkal kapcsolatban olvassuk el az init(8) man oldalt.

A BIND a kimenő kérésekhez véletlenszerűen kiválaszt egy nagyobb sorszámú portot. A legújabb változataiban már minden egyes kéréshez külön véletlenszerűen keres új UDP portot. Ez bizonyos hálózati konfigurációk esetén problémákhoz vezethet, különösen olyankor, amikor a beérkező UDP csomagokat egy tűzfal megállítja. A tűzfalak által blokkolt porttartományok használatát az avoid-v4-udp-ports vagy az avoid-v6-udp-ports beállítással tilthatjuk le a program számára.

Mindenesetre örülünk, hogy ezt is valaki megkérdezte! Hiába, nem árt néha nézegetni a sockstat(1) kimenetét és észrevenni benne néhány furcsaságot.

A sendmail újabb verzióiban felfedezhető levélküldési lehetőségek az 587-es portot használják. Jelenleg ezt még nem sokan használják ki, de növekszik a népszerűsége.

Ne aggódjunk! A toor egy “alternatív” rendszergazdai hozzáférés (a “toor” a “root” visszafelé). Korábban csak a bash(1) parancsértelmező telepítésekor jött létre, azonban manapság már alapértelmezés szerint létrejön. A nem szabványos parancsértelmezők számára találták ki, így nem a root alapértelmezett parancsértelmezőjét kell megváltoztatnunk. Ez különösen olyan parancsértelmezők esetén fontos, amelyek nem részei az alaprendszernek (például a portként vagy csomagként telepített parancsértelmezők esetén) és ezért a /usr/local/bin könyvtárba fognak kerülni. Ez a könyvtár alapértelmezés szerint azonban egy külön állományrendszeren található. Ha a root parancsértelmezője viszont a /usr/local/bin könyvtárban lenne, miközben a /usr (vagy bármelyik más állományrendszer, amely az imént említett könyvtárat tartalmazza) nem csatlakoztatható valamilyen oknál fogva, akkor a root nem lenne képes bejelentkezni és kijavítani a problémát. (Noha amikor újraindítjuk a rendszerünket egyfelhasználós módban, akkor a rendszer rá fog kérdezni, hogy melyik parancsértelmezőt akarjuk használni.)

Egyesek nem szabványos parancsértelmezőn keresztül a toor felhasználóval végzik el a root mindennapi teendőit, így a szabványos parancsértelmezőt csak a vészhelyzetekre tartogatják. Alapértelmezés szerint a toor felhasználóval nem tudunk bejelentkezni, mivel nincs jelszava, ezért ha használni akarjuk, akkor először jelentkezzünk be a root felhasználóval, majd állítsunk be neki egy jelszót.

Biztonsági okokból a suidperl parancs alapértelmezés szerint nem kerül telepítésre. Ha forrásból frissítjük rendszerünket és azt szeretnénk, hogy ennek során a suidperl is leforduljon, akkor a perl fordításának megkezdése előtt vegyük fel a ENABLE_SUIDPERL=true sort az /etc/make.conf állományba.

Elsőként mindenképpen olvassuk el a ppp(8) man oldalt és a kézikönyv PPP-vel foglalkozó részét. A következő paranccsal engedélyezzük a naplózást:

set log Phase Chat Connect Carrier lcp ipcp ccp command

Ezt a parancsot a ppp(8) parancssorában vagy az /etc/ppp/ppp.conf konfigurációs állományban kell megadnunk (leginkább a default szakasz elejére érdemes betennünk). Gondoskodjunk róla, hogy az /etc/syslog.conf állomány (lásd syslog.conf(5)) tartalmazza az alábbi sort, illetve az /var/log/ppp.log állomány létezzen:

!ppp
*.*        /var/log/ppp.log

A napló segítségével már több mindent ki tudunk deríteni a ppp(8) működéséről. Ne aggódjunk, ha nem értünk belőle semmit. Kérjünk segítséget másoktól, nekik minden bizonnyal segíteni fog a probléma felderítésében.

Ilyen általában azért történik, mert nem tudta feloldani a hálózati nevet. Ezt a legkönnyebben úgy tudjuk orvosolni, ha az /etc/host.conf állományba előre rakjuk a hosts sort, így a névfeloldó először az /etc/hosts állománnyal fog próbálkozni. Ezután a /etc/hosts állományba vegyük fel a helyi gépet. Ha nincs helyi hálózatunk, akkor így írjuk át a localhost sort:

127.0.0.1        ize.minta.com ize localhost

Minden más esetben egyszerűen csak vegyünk fel egy újabb bejegyzést a gépünkhöz. Ennek pontosabb részleteivel kapcsolatban nézzük meg a megfelelő man oldalakat.

Ha mindent jól csináltunk, akkor a ping -c1 `hostname` parancs hiba nélkül tér vissza.

Először is ellenőrizzük, hogy létezik az alapértelmezett útvonal. A netstat -rn parancs (lásd netstat(1)) kiadása után nagyjából a következő két bejegyzést kell látnunk:

Destination        Gateway            Flags     Refs     Use     Netif Expire
default            10.0.0.2           UGSc        0        0      tun0
10.0.0.2           10.0.0.1           UH          0        0      tun0

Feltételezzük, hogy a kézikönyvből, a man oldalról vagy ppp.conf.sample állományból másoltuk ki ezeket a címeket. Ha nincs alapértelmezett útvonalunk, akkor annak az lehet az oka, hogy a ppp.conf állományba elfelejtettük felvenni a HISADDR kulcsszót.

Az alapértelmezett útvonal hiányának másik oka lehet még, ha az /etc/rc.conf állományban (lásd rc.conf(5)) beállítottunk egy alapértelmezett átjárót, de elfelejtettük az ppp.conf állományba betenni a következő sort:

delete ALL

Ebben az esetben menjünk vissza a kézikönyv A rendszer végső beállítása című részéhez.

Általában azért jelentkezik, mert az /etc/ppp/ppp.linkup állományban nem adtuk meg az alábbiakat:

MYADDR:
  delete ALL
  add 0 0 HISADDR

Erre csak akkor van szükségünk, ha dinamikus IP-címünk van, vagy nem ismerjük az átjáró címét. Ha az interaktív módot használjuk, akkor ehhez a következőket kell begépelni csomag módba lépés után (a csomag módot a csupa nagybetűs PPP jelzi a parancssorban):

delete ALL
add 0 0 HISADDR

A kézikönyv A PPP és a dinamikus IP-címek című részében olvashatunk erről bővebben.

A PPP alrendszer alapértelmezett lejárati ideje 3 perc. Ezt a beállítást a következő sor megadásával tudjuk módosítani:

set timeout NNN

ahol az NNN másodpercekben megadja a kapcsolat lezárása előtti inaktivitás maximális idejét. Ha az NNN értéke nulla, akkor a kapcsolat időtúllépés miatt soha nem fog magától megszakadni. Ezt a parancsot a ppp.conf állományba tudjuk felvenni, vagy interaktív módban a parancssorban gépelhetjük be. Emellett menet közben is állítani tudjuk ezt az értéket, ha a ppp szerverre a telnet(1) vagy a pppctl(8) segítségével rácsatlakozunk. Erről a ppp(8) man oldal ad részletesebb tájékoztatást.

Ha beállítottuk a Link Quality Reporting (LQR) használatát, akkor előfordulhat, hogy túlságosan sok csomag veszik el a gépünk és a másik oldal között. A ppp(8) ezért a vonalat rossznak érzékeli és bontja. A FreeBSD 2.2.5 változata előtt az LQR alapértelmezés szerint engedélyezett volt. Az LQR így tiltható le:

disable lqr

Néha előfordulhat, hogy a zajos telefonvonal esetén vagy a hívásvárakoztatás használatakor a modem bontja a vonalat, mivel (helytelenül) azt hiszi, hogy nincs kapcsolat.

Manapság a legtöbb modemen általában be lehet valahogy állítani, hogy mennyire legyenek elnézőek a kapcsolat ideiglenes megszakadásával szemben. Például egy U.S. Robotics® Sportster® esetén ezt tizedmásodpercekben mérik az S10 regiszter segítségével. A modemünk ilyenkor tehát úgy tehető sokkal toleránsabbá, ha a következő hívási beállítást adjuk:

set dial "...... ATS10=10 OK ......"

További részleteket a modem kézikönyvéből tudhatunk meg.

Sokan tapasztalják, hogy a kapcsolat minden különösebb magyarázat nélkül lefullad. Ilyenkor elsőként azt érdemes tisztázni, hogy az összeköttetés melyik oldalán történt a vonal bontása.

Ha belső modemet használunk, akkor próbáljuk meg a ping(8) paranccsal ellenőrizni, hogy a modem TD lámpája villog-e az adatok küldésekor. Amennyiben igen (miközben az RD lámpa viszont nem), akkor a gond a vonal másik végén lesz. Ha viszont a TD nem villog, akkor a probléma a mi oldalunkon áll fenn. A belső modemek esetében a ppp.conf állományban a set server parancsot is érdemes megadnunk, így amikor a kapcsolat leállását tapasztaljuk, a pppctl(8) segítségével rá tudunk csatlakozni a ppp(8) démonra. Ha a hálózati kapcsolat ekkor hirtelen erőre kapna (mivel rácsatlakoztunk kívülről) vagy egyáltalán nem tudunk csatlakozni (feltételezve, hogy a set socket parancs sikeresen lefutott az induláskor), akkor a probléma még mindig nálunk lesz. Ha viszont sikerül csatlakoznunk és a vonallal még mindig gondok vannak, akkor próbáljuk a set log local async parancs használatával engedélyezni a helyi aszinkron naplózást, majd egy másik konzolból a ping(8) parancs segítségével kezdjük el használni az összeköttetést. Az aszinkron naplózás jelezni fogja, ha sikerül adatokat átvinni és fogadni a kapcsolaton keresztül. Ha ilyenkor nem látunk visszafele érkező adatokat, akkor az arra utal, hogy a gond a vonal távoli végén van.

Miután sikeresen kiderítettük, hogy az adott probléma helyi vagy távoli, két lehetőségünk van:

• Amennyiben távoli, olvassuk el a K: 14.9. válaszát.

• Amennyiben helyi, olvassuk el a K: 14.10. válaszát.

Ezzel szemben nagyon keveset tudunk mi, felhasználók tenni. A legtöbb internetszolgáltató egyszerűen nem hajlandó segítséget nyújtani abban az esetben, ha nem valamelyik Microsoft operációs rendszert használjuk. A ppp.conf állományunkban a enable lqr sor megadásával engedélyezni tudjuk a ppp(8) számára, hogy észlelhesse a távoli hibákat és bontsa a vonalat, de ez a vizsgálat viszonylag időigényes és ennélfogva nem túlságosan hasznos. A szolgáltatónknak pedig ne nagyon emlegessük, hogy felhasználói PPP-t futtatunk.

Először próbáljunk meg letiltani mindenféle tömörítést a következő sor megadásával:

disable pred1 deflate deflate24 protocomp acfcomp shortseq vj
deny pred1 deflate deflate24 protocomp acfcomp shortseq vj

Kapcsolódjunk újra és ellenőrizzük, hogy továbbra is működőképes a kapcsolat. Ha ennek hatására javul a helyzet vagy a probléma teljesen megoldódik, akkor a beállítások egyenkénti próbálgatásával keressük meg, hogy melyik okozta a gondot. Ez már elegendő lesz ahhoz, hogy komolyabban felvegyük a kapcsolatot a szolgáltatónkkal (habár ebből gyorsan ki fog derülni, hogy nem Microsoft terméket használunk).

Mielőtt szólnánk a szolgáltatónknak, a gépünkön engedélyezzük az aszinkron naplózást és várjuk meg, amíg a kapcsolat újra megszakad. Erre nem árt felkészülnünk, mert viszonylag sok tárhelyet igényel. Innen majd a portról utoljára olvasott adat lesz a lényeges. Ez általában szöveges adat és akár a probléma konkrét okára is utalhat (“Memory fault”, “Core dumped”?).

Ha segítőkész szolgáltatót választottuk, akkor a naplózást akár az ő oldalunkon is engedélyezhetjük, így amikor a vonal megszakad, az ő szemszögükből is képesek leszünk elemezni a problémát. Ilyen esetben nyugodtan küldjünk egy levelet Brian Somers <brian@FreeBSD.org> címére vagy kérjük meg a szolgáltatónkat, hogy közvetlenül vele tárgyaljon.

A legjobban úgy járunk, ha a ppp(8) programot nyomkövetési információkkal fordítjuk újra, majd a gdb(1) segítségével lekérünk egy hívási láncot az éppen megakadt ppp példánytól. A ppp alkalmazást a következő parancsokkal tudjuk úgy újrafordítani, hogy tartalmazza a kívánt információkat:

# gdb ppp `pgrep ppp`

Ezt követően a gdb parancssorában a bt és where parancsok segítségével hozzá tudunk jutni a hívási lánchoz. Mentsük el valahova a gdb által kinyert adatokat, majd a detach paranccsal váljunk le a futó programról és a quit begépelésével lépjünk ki a gdb programból.

Végezetül az elmentett eredményeket küldjük el Brian Somers <brian@FreeBSD.org> címére.

A FreeBSD 2.2.5 előtti kiadásaiban a ppp(8) az összeköttetés létrejötte után megvárta, hogy a távoli pont kezdeményezze a kapcsolatvezérlő protokoll (Line Control Protocol, LCP) használatát. Sok szolgáltató azonban nem csinál ilyet, ehelyett inkább a klienstől várják mindezt. Az LCP kezdeményezését így kényszeríthetjük ki a ppp(8) használata során:

set openmode active

Csatlakozás után időnként előfordulhat, hogy “magic is the same” hibaüzeneteket látunk a naplóban. Ezek az üzenetek bizonyos esetekben teljesen ártalmatlanok, máskor viszont akár komolyabb problémákat is jelezhet. A legtöbb PPP implementáció nem él túl egy ilyen hibát, és még ha látszólag létre is jön ilyenkor a kapcsolat, folyamatosan konfigurációs kérések és válaszok jönnek-mennek a naplóban egészen addig, amíg a ppp(8) végül fel nem adja és lezárja a kapcsolatot.

Ez általában olyan szervereken jelenik meg, ahol nem elég gyorsak a lemezek és minden kapcsolathoz elindítanak egy getty(8) és a bejelentkezéskor vagy azt következő elindítják a ppp(8) programot. Egyes visszajelzések szerint ilyen egyébként gyakran előfordul a slirp használatakor. A problémát egyébként a getty(8) és a ppp(8) indítása között eltelt idő okozza, amikor a kliens oldalán futó ppp(8) elkezdi küldeni a kapcsolatvezérlő (Line Control Protocol, LCP) csomagokat. Mivel ilyenkor az ECHO még mindig aktív a szerver adott portján, a kliens ppp(8) a saját csomagjainak “tükröződését” fogja látni.

Az LCP beállításának része az összeköttetés két oldalán egy-egy bűvös szám (“magic number”) megállapítása, amellyel ezután észlelhetőek az ilyen “tükröződések”. A protokoll szerint amikor a két pont megpróbálja ugyanazt a bűvös számot használni, akkor visszautasítja (NAK jelzést küld) és egy másikat választ. Ha ilyenkor még a szerver portján aktív az ECHO, akkor a kliens oldali ppp(8) azt tapasztalja, hogy elkezd LCP csomagokat küldeni, majd mivel ugyanazt kapja vissza, erre egy NAK jelzést válaszol. Ugyanígy látja magát a NAK jelzést (aminek hatására a ppp(8) megváltoztatja a bűvös számát) is. Ennek eredményeképpen hirtelen nagy mennyiségű bűvösszám-váltás keletkezik, ami pedig szépen felhalmozódik a szerver terminálpufferében. Ahogy a ppp(8) végre elindul a szerveren, elönti ez a rengeteg információ, aminek alapján sikertelennek ítéli meg az LCP beállítását és feladja a további próbálkozást. Eközben a kliens számára megszűnnek a visszaverődő csomagok és csak annyit lát, hogy a szerver bontja a kapcsolatot.

Ezt úgy tudjuk elkerülni, ha a ppp.conf állományban a távoli pontra bízzuk az beállítás kezdeményezését:

set openmode passive

Ennek hatására a ppp(8) megvárja, hogy a szerver kezdeményezze az LCP beállítását. Egyes szerverek azonban sosem teszik meg ezt. Ilyenkor valami ilyesmit tudunk tenni:

set openmode active 3

Így a ppp(8) 3 másodpercig passzív marad, majd csak ezután kezd el LCP kérésket küldeni. Ha a távoli pont eközben küld valamilyen kérést, az ppp(8) azonnal válaszol rá és nem várja végig a 3 másodperces időtartamot.

A ppp(8) programban jelenleg van egy olyan hibásan implementált jellemző, ahol az LCP, CCP és IPCP válaszokat nem társítja az eredeti kérésekhez. Ennek következményeképpen, ha az egyik PPP implementáció 6 másodperccel lassabb a másik oldalnál, akkor az még két további LCP konfigurációs kérést is küld, ami viszont végzetesnek bizonyul.

Vegyünk például két implementációt, az A és a B pontokat. Az A már közvetlenül a csatlakozás után LCP kéréseket kezd el küldeni, miközben a B csak 7 másodperc múlva tud elindulni. Mire végre a B pont is elindul, addigra az A már kiküldött 3 LCP kérést. Most feltételezzük, hogy nincs ECHO, máskülönben az előző szakaszban leírt, bűvös számokkal kapcsolatos problémába ütköznénk. A B ekkor tehát küld egy kérést, majd nyugtázza az A ponttól kapott korábbi kérést. Ennek hatására az A pont OPENED állapotba megy át, újra küld és nyugtázza az előző kérést B felé. Eközben a B további két nyugtázást küld az A pontról kapott további két kérésre, a B indulása előttről. A B ekkor megkapja az A első nyugtáját és átvált OPENED állapotba. Az A ekkor megkapja a második nyugtát a B ponttól és visszavált REQ-SENT állapotba, majd az RFC szerint elküld (előre) egy újabb kérést. Ekkor megkapja a harmadik nyugtát és OPENED állapotba vált. Eközben a B megkapja előre küldött kérést a A ponttól, amelynek hatására ACK-SENT állapotba vált vissza, és az RFC szerint ismét küld egy (második) kérést és egy nyugtázást. Az A erre megkapja a kérést, visszavált REQ-SENT állapotban és küld egy újabb kérést. Ekkor közvetlenül megkapja a rákövetkező nyugtázást és átvált OPENED állapotba.

Ez egészen addig folytatódik, amíg az egyik oldal rá nem eszmél, hogy ennek nincs túlságosan sok értelme és feladja a próbálkozást.

Ez legkönnyebben úgy kerülhető el, ha ilyenkor az egyik oldalt passive típusúra állítjuk, vagyis az egyik oldalon várunk egy keveset a beállítás kezdeményezésére. Ezt a következő paranccsal lehet megoldani:

set openmode passive

Óvatosan bánjunk ezzel a paraméterrel! A beállítás kezdeményezésének várakoztatási idejét a következő paraméterrel tudjuk megadni:

set stopped N

Használhatjuk viszont ezt a parancsot is (ahol N adja meg, hogy mennyi másodperc teljen el a beállítás megkezdése előtt):

set openmode active N

Az ezzel kapcsolatos további részleteket a man oldalon olvashatjuk.

A shell vagy ! parancsok végrehajtásakor a ppp(8) elindít egy parancsértelmezőt (illetve ha paramétereket is adtunk meg, akkor a ppp(8) átadja azokat is), majd megvárja annak befejeződését. Ha a parancs futtatása közben éppen egy PPP kapcsolatot akartunk használni, akkor erre az időre az előbbiek miatt látszólag meg fog állni. Ez tehát azért történik, mert a ppp(8) megvárja a parancs lefutását.

Ha nem akarjuk megvárni a parancs befejeződését, akkor inkább használjuk a !bg parancsot. Ennek hatására az adott parancs a háttérben fog lefutni és a ppp(8) képes lesz folyamatosan szemmel tartani az összeköttetést.

A ppp(8) ilyen esetekben nem képes magától megállapítani, hogy mikor bontották a vonalat. Ennek oka a tűk null-modem kábelben kiosztott szerepében keresendő. Amikor ilyen típusú kapcsolattal dolgozunk, a következő sor megadásával ne felejtsük el engedélyezni az LQR használatát:

enable lqr

Ha a távoli pont LQR csomagokat küld, akkor a ppp(8) alapértelmezés szerint fogadja azokat.

Amennyiben a ppp(8) szándékainkkal szemben váratlanul kezdene el tárcsázni, akkor keressük meg kiváltó okát és használjunk hívási szűrést (Dial filter, dfilter) ennek megelőzésére.

A tárcsázás okát a következő sor használatával tudjuk kideríteni:

set log +tcp/ip

Ennek hatására a kapcsolaton keresztüláramló összes forgalmat naplózni fogjuk. Így a legközelebb, amikor a vonal hirtelen aktív lesz, a hozzá tartozó időbélyegek alapján könnyen elő tudjuk keresni, hogy pontosan miért is történt.

Az automatikus tárcsázást bizonyos esetekben le tudjuk tiltani. Ez általában egy olyan probléma, amely a névfeloldások miatt keletkezik. Úgy tudjuk megakadályozni, hogy a névfeloldások felépítsék a kapcsolatot (ami viszont nem gátolja abban a ppp(8) programot, hogy egy már meglevő kapcsolaton keresztül küldjön ilyen csomagokat), ha az alábbi beállításokat adjuk meg:

set dfilter 1 deny udp src eq 53
set dfilter 2 deny udp dst eq 53
set dfilter 3 permit 0/0 0/0

Ezek az értékek nem minden esetben megfelelőek számunkra, hiszen ezzel együtt az igény szerinti tárcsázás kényelmét is szűkítjük, mivel a legtöbb program közvetlenül névfeloldással kezd, mielőtt komolyabb hálózati forgalmat bonyolítana le.

A névfeloldás esetében igyekezzünk kideríteni, hogy pontosan melyik program is próbál hálózati neveket feloldatni. Az esetek többségében valószínűleg a sendmail(8) lesz a bűnös. Amennyiben ez a helyzet, akkor az sendmail démonnak a saját konfigurációs állományában kell beállítanunk, hogy ne oldasson fel hálózati neveket. Az érintett konfigurációs állomány módosításának pontos részleteiről a kézikönyv Levelezés betárcsázós kapcsolattal című szakszában olvashatunk bővebben. Továbbá az .mc állományunkba a következő sort is érdemes felvennünk:

define(`confDELIVERY_MODE', `d')dnl

Ezzel a sendmail beindításáig mindent egy sorban fog eltárolni (általában a sendmail démont a -bd -q30m paraméterekkel szokták meghívni, ami arra utasítja, hogy 30 percenként dolgozza fel a sorát) vagy amíg a sendmail -q parancs le nem fut (például a ppp.linkup állományból).

A naplóban folyamatosan a következő üzeneteket lehet látni:

CCP: CcpSendConfigReq
CCP: Received Terminate Ack (1) state = Req-Sent (6)

Ilyenek azért keletkeznek, mert a ppp(8) a Predictor1 tömörítési eljárást próbálja meg beállítani, azonban a távoli pont egyáltalán semmilyen tömörítést nem akar használni. Az ilyen üzenetek többnyire ártalmatlanok, de ha el akarjuk tüntetni ezeket, akkor próbáljuk meg a következő módon kikapcsolni a Predictor1 tömörítés használatát:

disable pred1

A modemmel végzett teljes “beszélgetés” szövegének rögzítéséhez a következőket kell engedélyezni:

set log +connect

Ennek eredményeképpen a ppp(8) egészen az utolsóként lekért karakterláncig naplóz mindent.

Ha PAP vagy CHAP hitelesítést használunk (ezért a CONNECT parancs kiadása után már nincs semmi “mondanivalónk” a hívószkriptben, tehát nincs set login szkript), és szeretnénk látni a csatlakozási sebességet, ne felejtsük el utasítani a ppp(8) programot, hogy a teljes CONNECT sort kérje le, valahogy így:

set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 4 \
  \"\" ATZ OK-ATZ-OK ATDT\\T TIMEOUT 60 CONNECT \\c \\n"

Itt most megkapjuk a CONNECT sort, ezután nem küldünk semmit, majd várunk egy soremelést, aminek hatására a ppp(8) arra kényszerül, hogy a teljes CONNECT választ beolvassa.

A ppp a konfigurációs állományokból minden sort külön beolvas, ezért a set phone "123 456 789" és hozzá hasonló karakterláncok esetén képes felismerni, hogy a megadott számok valójában egyetlen paramétert formáznak. A " megadásához a visszaper karaktert (\) kell használnunk.

Amikor tárcsázásért felelős értelmező beolvassa az egyes paramétereket, újraértelmezi ezeket olyan speciális helyettesítési szekvenciák után kutatva, mint például a \P vagy \T (részletesebben lásd a man oldalon). A kettős elemzés miatt nekünk is a megfelelő számban kell megadnunk ezeket a helyettesítendő karaktereket.

Ha tehát egy \ karaktert szeretnénk átküldeni a modemünknek, akkor nagyjából valami ilyesmit kellene írnunk:

set dial "\"\" ATZ OK-ATZ-OK AT\\\\X OK"

Ennek az eredménye a következő lesz:

ATZ
OK
AT\X
OK

Vagy:

set phone 1234567
set dial "\"\" ATZ OK ATDT\\T"

Ez pedig a következő szekvenciát adja:

ATZ
OK
ATDT1234567

A ppp (vagy más hasonló program) elméletileg soha nem hoz létre .core állományt. Mivel a ppp(8) tulajdonképpen a nullás felhasználói azonosítóval fut, az operációs rendszer soha nem fogja a ppp(8) memórialenyomatát leállítása előtt a lemezre menteni. Ha viszont ppp(8) működése valóban leáll egy szegmentációs hiba vagy bármilyen más .core állományt eredményező jelzés miatt, és valóban a legfrissebb változatát használjuk (lásd a fejezet elejét), akkor a következőt tehetjük:

# cd /usr/src/usr.sbin/ppp
# echo STRIP= >> /etc/make.conf
# echo CFLAGS+=-g >> /etc/make.conf
# make install clean

A fenti parancsokkal telepíteni tudjuk a ppp(8) egy nyomonkövethető változatát. A ppp(8) futtatásához root felhasználónak kell lennünk, mivel minden korábbi engedélyét felülírtuk az előbbiek során. A ppp(8) indításakor ne felejtsük el megjegyezni pontosan az aktuális könyvtárat sem.

Innentől kezdve, amikor a ppp(8) kap egy szegmentációs hibára vonatkozó jelzést, létre fog hozni egy ppp.core nevű állományt. Ennek birtokában a következőt kell csinálnunk:

% su
# gdb /usr/sbin/ppp ppp.core
(gdb) bt
.....
(gdb) f 0
....
(gdb) i args
....
(gdb) l
.....

Az így beszerzett információkat mellékelve nagyobb valószínűséggel kaphatunk választ az ezzel kapcsolatos kérdésünkre.

Ha járatosak vagyunk a gdb(1) használatában, akkor a .core állományban további részletek és információk utáni is kutathatunk, például mi okozta a hibát, milyen változóknak ekkor milyen értékei voltak stb.

Ez korábban egy ismert probléma volt a ppp(8) használatával kapcsolatban, amikor dinamikus helyi IP-címet akart beállítani -auto módban. Ez a hiba az újabb változatokban már nem nincs meg (a man oldalon keressünk rá az iface részre).

A gondot az okozta, hogy amikor a tárcsázást elindító program meghívja a connect(2) rendszerhívást, akkor a tun(4) interfészhez tartozó IP-cím a végpontot képviselő sockethez társul. A rendszermag létrehozza az első kimenő csomagot és kiírja a tun(4) eszközre. A ppp(8) ekkor beolvassa a csomagot és felépíti a kapcsolatot. Ha a ppp(8) dinamikus IP-cím kiosztásának eredményeképpen ilyenkor az interfész címe megváltozik, akkor azzal egyidőben az eredeti socket végpont érvénytelenné válik. Így a távoli végpont felé küldött további csomagok általában eldobódnak. Ha valahogy mégis eljutnának a céljukhoz, a válasz már semmiképpen sem érkezhet meg, mivel a küldéshez használt IP-címnek már nem az adott gép a tulajdonosa.

Számos elméleti megközelítés létezik az imént felvázolt probléma megoldására. A legszebb az lenne, ha a távoli pont lehetőség szerint a korábban használt IP-címet osztaná ki újra. A ppp(8) jelenlegi változata pontosan ugyanezt teszi, viszont a legtöbbi implementáció már nem.

Részünkről az bizonyulna a legegyszerűbb megoldásnak, ha a tun(4) intefész IP-címe egyáltalán nem változhatna meg, hanem helyette menet közben az összes kimenő csomag, köztük természetesen a forrás IP-címe az interfész IP-címéről az időközben beállított IP-címre változna. Ez lényegében az, amit a ppp(8) legújabb változataiban felbukkanó iface-alias opció is csinál (a libalias(3) és a ppp(8) -nat kapcsolója segítségével): karbantartja az összes korábban használt interfész címét és átfordítja ezeket az utoljára beállított címre.

A másik (és valószínűleg a sokkal megbízhatóbb) lehetőség egy olyan rendszerhívás implementálása lenne, amely képes az összes használatban levő socketet egyik IP-címről a másik IP-címre átállítani. A ppp(8) ekkor fel tudná használni ezt arra, hogy módosítsa az összes addig futó program socketjét az új IP-cím beállításakor. Ugyanezzel a rendszerhívással a DHCP kliensek is képesek lennének átállítani a socketjeiket.

Lehetőségünk van még IP-cím nélkül is létrehozni interfészeket. A kimenő csomagok ekkor a 255.255.255.255 IP-címet használnák egészen addig, amíg az első SIOCAIFADDR ioctl(2) rendszerhívás le nem zajlik. A ppp(8) feladata ilyenkor a forrás IP-cím megváltoztatása, de ha ez 255.255.255.255, akkor egyedül csak az IP-címnek és az ellenőrzőösszegnek kell megváltoznia. Ez viszont már valamilyen mértékben trükközést a rendszermagon belül, mivel így könnyen tudunk csomagokat küldeni egy rosszul beállított interfészre is, feltételezve, hogy valamilyen módon képesek vagyunk ilyeneket visszamenőleg helyreállítani.

A játékok és a hozzájuk hasonló alkalmazások általában azért nem működnek, amikor a libalias(3) könyvtárat használjuk, mert a távoli gép megpróbál kapcsolódni a belső hálózatunkon levő géphez és kéretlen UDP csomagokat kezd el küldeni neki. A címfordítást végző programnak fogalma sincs róla, hogy ezeket a csomagokat egy belső gépnek kell továbbküldenie.

Akkor lehetünk biztosak ebben, ha egyedül csak azt a szoftvert indítjuk el, amellyel gondjaink akadtak, majd a vagy az átjáró tun(4) interfészét kezdjük el a tcpdump(1) segítségével, vagy pedig engedélyezzük az átjárón a ppp(8) TCP/IP naplózó funkcióját (set log +tcp/ip).

Ahogy elindítjuk a gondokat okozó programot, látnunk kell a csomagjait, ahogy megpróbálnak keresztüljutni az átjárón. Az erre érkező válaszolok eldobódnak (ez jelenti a problémát). Jegyezzük fel a csomagokhoz társuló portszámokat és állítsuk el a programot. Csináljuk meg néhányszor ezt a vizsgálatot, így ellenőrizni tudjuk, hogy mindig ugyanazokat a portokat használja-e. Amennyiben úgy tapasztaljuk, hogy igen, akkor az /etc/ppp/ppp.conf állományba a következő sort kell betenni a megfelelő helyre a működés helyreállításához:

nat port protokoll belső-gép:port port

ahol a protokoll lehet tcp vagy udp, a belső-gép annak a gépnek a címe, ahova tovább akarjuk küldeni a csomagokat, valamint a port a csomagok célportját adja meg.

A fenti parancs megváltoztatása nélkül nem tudjuk ugyanezt a szoftvert más gépeken is használni, és itt azzal most nem is foglalkozunk, hogy miként lehet két belső gépről használni ugyanazt a programot. Mindenesetre annyi biztos, hogy a külvilág felé a belső hálózatunk csupán egyetlen gépnek fog látszani.

Ha azt látjuk, hogy az alkalmazás nem mindig ugyanazt a portot használja, akkor három választási lehetőségünk van:

1. Készítsük el a támogatását a libalias(3) függvénykönyvtárhoz. A különböző “szélsőséges esetekre” a /usr/src/sys/netinet/libalias/alias_*.c állományokban találhatunk példákat (az alias_ftp.c tökéletes kiindulási alap). Ez általában annyit jelent, hogy beolvasunk bizonyos ismert kimenő csomagokat, beazonosítjuk benne azt az utasítást, amelynek hatására a külső gép csatlakozni próbál a belső géphez egy adott (véletlenszerűen választott) porton, majd beállítunk hozzá egy “útvonalat”, így a rákövetkező csomagok már tudni fogják, hogy merre menjenek.

   Ez ugyan a legnehezebb megoldás, de egyben ez is a legjobb, ráadásul így a szoftver több gépen is működtethető.

2. Proxy használata. Előfordulhat, hogy az alkalmazás támogatja a socks5 protokollt vagy (mint ahogy a cvsup is csinálja) rendelkezik “passzív” móddal, és így lehetőleg igyekszik elkerülni azt, hogy a távoli gépről kapcsolatot próbáljanak meg indítani a helyi gépre.

3. A nat addr használatával irányítsunk át mindent a belső gépre. Ez viszont egy nagyon durva megközelítés.

Egyelőre még nem, de szándékunkban áll összeállítani egy ilyen listát (már amennyiben igény lesz rá). Minden itt szereplő példában az belső helyett mindig annak a gépnek a belső IP-címét írjuk, amelyről játszani akarunk.

• Asheron's Call

  nat port udp belső :65000 65000

  Manuálisan változtassuk meg a játékon belül a portszámot 65000-re. Ha a belső hálózatunkról több gépen is szeretnénk játszni, akkor mindegyiknek adjuk meg egy egyedi portot (vagyis 65001, 65002 stb.), majd vegyünk fel mindegyikhez egy-egy nat port sort.

• Half Life

  nat port udp belső:27005 27015

• PCAnywhere 8.0

  nat port udp belső:5632 5632

  nat port tcp belső:5631 5631

• Quake

  nat port udp belső:6112 6112

• Quake 2

  nat port udp belső:27901 27910

  nat port udp belső:60021 60021

  nat port udp belső:60040 60040

• Red Alert

  nat port udp belső:8675 8675

  nat port udp belső:5009 5009

Az FCS jelentése Frame Check Sequence, vagyis az “Adatkeret ellenőrzésének sorozata”. Mindegyik PPP csomaghoz tartozik egy ellenőrzőösszeg, amely arról gondoskodik, hogy ugyanaz az adat érkezzen meg, mint amit elküldtek. Amennyiben egy bejövő csomag FCS értéke érvénytelennek minősül, a csomag eldobódik és a HDLC FCS számláló értékkel eggyel növekszik. A HDLC hibaszámlálói a show hdlc parancs segítségével tekinthetőek meg.

Ha rosszul működik az összeköttetés (vagy a soros vonali meghajtónk folyamatosan eldobja a csomagokat), akkor láthatunk helyenként FCS hibákat. Többnyire nem érdemes az ilyenek miatt aggódni, habár ez jelentős mértékben lassítja a tömörítést végző protokollok munkáját. Ha külső modemünk van, akkor ne felejtsük el a megfelelő módon leárnyékolni, mivel ebből is származhat a probléma.

Ha a vonal a kapcsolódást követően szinte azonnal lemerevedik és hirtelen nagy mennyiségű FCS hiba jelentkezik, akkor az arra is utalhat, hogy az összeköttetés nem tisztán 8 bites. Gondoskodjunk róla, hogy a modem ne a szoftveres forgalomirányítást (XON/XOFF) használja. Ha viszont az adatok közvetítéséhez mégis szoftveres forgalomirányítást kell használnunk, akkor a set accmap 0x000a0000 parancs kiadásával jelezzük a ppp(8) felé, hogy a ^Q és ^S karaktereket helyettesítse.

Nagy mennyiségű FCS hibát olyan esetekben is tapasztalhatunk, amikor a távoli pont abbahagyta a PPP üzenetek küldését. Ilyenkor javasolt engedélyezni az aszinkron naplózás használatát, aminek segítségével gyorsan meg tudjuk állapítani, hogy a beérkező adatok bejelentkező vagy shell üzeneteket. Ha a másik oldalon egy shell parancssorát kapjuk meg, akkor a ppp(8) a close lcp megadásával a vonal eldobása nélkül leállítható (az utána következő term paranccsal pedig a távoli gépen futó shellre tudunk csatlakozni).

Ha a naplókban látszólag semmi sem indokolja az összeköttetés leállását, próbáljunk meg erre rákérdezni a távoli pont (talán a szolgáltató?) karbantartójánál.

A probléma megoldását Michael Wozniak (<mwozniak@netcom.ca>) adta meg, valamint Dan Flemming (<danflemming@mac.com>) alkalmazta ugyanezt Macre:

Ennek oka az ún. útválasztási “fekete lyuk”. A Mac OS és a Windows 98 (de valószínűleg az összes többi Microsoft operációs rendszer) olyan nagy méretű TCP csomagokat küld, amelyek már nem férnek bele egy PPPoE keretbe (amely mérete Ethernet estén 1500 byte alapértelmezés szerint) és beállítja hozzá a darabolás letiltását jelző (“do not fragment”) bitet (TCP esetén ez alapértelmezett), és a Telco útválasztó pedig nem küldi el a “must fragment” (“darabolni kell”) ICMP csomagot a letölteni kívánt oldal szolgáltatója felé. (Másik lehetőség, hogy az útválasztó ugyan küld egy ilyen ICMP csomagot, de ezt a tartalomszolgáltatónál található tűzfal eldobja.) Amikor válaszul a szolgáltató olyan kereteket kezd el küldeni, amelyek nem illeszkednek a PPPoE keresztmetszetébe, a Telco útválasztó egyszerűen eldobja ezeket és a lap nem pedig nem lesz elérhető (egyes képek és oldalak esetén előfordul). Úgy tűnik, ez az alapbeállítás a legtöbb Telco PPPoE konfiguráció esetében.

Ezt a hibát úgy javíthatjuk, ha a Windows 95/98 rendszerekben megtalálható regedit segítségével felvesszük a következő regisztrációs bejegyzést:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\NetTrans\0000\MaxMTU

A karakterlánc értéke legyen 1436, mivel bizonyos ADSL útválasztók állítólag nem képesek ennél nagyobb méretű csomagokat kezelni. Windows 2000 esetén ezt a beállítást a Tcpip\Parameters\Interfaces\a hálózati kártya azonosítója\MTU helyen kell keresni és típusa duplaszó (DWORD).

A Windows MTU beállításaival kapcsolatban olvassuk el a Microsoft Knowledge Base címén található dokumentumokat: Q158474 - Windows TCPIP Registry Entries és Q120642 - TCPIP & NBT Configuration Parameters for Windows NT .

Windows 2000 alatt a regisztrációs adatbázisban érdemes még a Tcpip\Parameters\Interfaces\a hálózati kártya azonosítója\EnablePMTUBHDetect duplaszó értékét 1-re állítani, ahogy arra az imént említett 120642-es Microsoft dokumentum is hivatkozik.

Sajnos a Mac OS nem nyújt semmilyen beállítási lehetőséget a TCP/IP beállítások megváltoztatására. Léteznek viszont kereskedelmi termékek, amelyek lehetővé teszi a felhasználók számára, hogy igényeik szerint módosítsák rendszerük TCP/IP beállításait. A hálózati címfordítást használók keressék meg az MTU beállításaikat és adják meg az 1450 értéket az eredeti 1500 helyett.

A ppp(8) újabb (2.3 vagy afeletti) változatai már tartalmaznak egy enable tcpmssfixup parancsot, amellyel az MSS értéke tetszőlegesen átállítható. Ez alapértelmezés szerint engedélyezett. Ha valamiért mégis a ppp(8) egy korábbi változatával kellene dolgoznunk, akkor érdemes megnéznünk net/tcpmssd portot.

Ha eddig minden más csődött mondott, akkor próbáljuk meg elküldeni az összes beszerezhető információt, beleértve a konfigurációs állományokat, hogyan indítjuk el a ppp(8) programot, a naplók fontosabb részeit és a netstat -rn parancs kimenetét (a csatlakozás előtt és után) a FreeBSD general questions levelezési lista címére vagy a comp.unix.bsd.freebsd.misc hírcsoportba, és valaki talán majd megmutatja a helyes irányt.

Ahogy a FreeBSD rendszermagja az elindulása után azokat a soros portokat fogja keresni, amelyeket a konfigurációs állományban beállítottunk. Figyeljük a rendszer indulása közben megjelenő üzeneteket vagy adjuk ki a következő parancsot a rendszer indulásának befejeztével:

% dmesg | grep -E "^sio[0-9]"

Íme egy példa az iménti parancs kimenetére:

sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
sio0: type 16550A
sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0
sio1: type 16550A

Ezen két soros portot láthatunk. Az első a negyedik megszakítást és a 0x3f8 címet használja és egy 16550A típusú UART chip. A második ugyanolyan chip, de a harmadik megszakítást és a 0x2f8 címet használja. A belső modemeket a rendszer úgy kezeli, mintha soros portok lennének, azzal a kivétellel, hogy a modem mindig “kapcsolódik” az adott porthoz.

A GENERIC rendszermag alapértelmezés szerint két soros portot támogat, a példában szereplő megszakítási- és memóriaértékek felhasználásával. Ha ezek a beállítások nem felelnek meg a rendszerünk számára, esetleg modemet raktunk a gépünkbe vagy a rendszermagban több soros portot is támogatni szeretnénk, akkor nincs más teendőnk, mint ennek megfelelően megváltoztatni a rendszermag paramétereit. A rendszermag fordításáról szóló rész tárgyalja ennek részleteit.

Olvassuk el az előző kérdésre adott választ.

A harmadik soros port, a sio2 (lásd sio(4), DOS alatt COM3) a /dev/cuad2 eszközön keresztül érhető el tárcsázó eszközként, és a /dev/ttyd2 eszközön keresztül behívó eszközként. Mi a különbség a két eszközosztály között?

A ttydX eszközöket behívásra használjuk. Amikor tehát a /dev/ttydX eszközt blokkoló módban nyitjuk meg, akkor a hívó program egészen addig várni fog, amíg a megfelelő cuadX eszköz inaktívvá nem válik, majd kivárja, hogy megérkezzen a hívás fogadását tolmácsoló jelzés. Amikor megnyitjuk a cuadX eszközt, gondoskodik róla, hogy a soros portot ekkor ne használja a ttydX eszköz. Ha a port szabaddá válik, egyszerűen “ellopja” a ttydX eszköztől. Sőt, a cuadX eszközt egyáltalán nem érdekli a hívás fogadása jelzés. Ezzel a megoldással és egy automata modem segítségével a távoli felhasználók bármikor be tudnak jelentkezni a rendszerünkbe, hogy közben ugyanezzel a modemmel továbbra is tudunk tárcsázni, mivel a rendszer elintézi a többit.

Ismét megemlítjük, hogy a rendszermag beállításával foglalkozó részben olvashatunk bővebben a rendszermag paraméterezésének mikéntjéről. A többportos soros vonali kártyák esetén a kártyán található mindegyik soros porthoz vegyünk fel egy-egy sio(4) bejegyzést a device.hints(5) állományába. Az IRQ és vektor értékeket azonban csak az egyiknél adjuk meg, mivel a kártyán található összes port egyetlen megszakításon fog osztozni. A következetesség kedvéért az utolsó porthoz adjuk meg a megszakítást. Ne felejtsük el még megadni a rendszermag konfigurációs állományában az alábbi opciót sem:

options COM_MULTIPORT

Az alábbi /boot/device.hints egy AST típusú négyportos soros vonali kártyát láthatunk a tizenkettedik megszakításon:

hint.sio.4.at="isa"
hint.sio.4.port="0x2a0"
hint.sio.4.flags="0x701"
hint.sio.5.at="isa"
hint.sio.5.port="0x2a8"
hint.sio.5.flags="0x701"
hint.sio.6.at="isa"
hint.sio.6.port="0x2b0"
hint.sio.6.flags="0x701"
hint.sio.7.at="isa"
hint.sio.7.port="0x2b8"
hint.sio.7.flags="0x701"
hint.sio.7.irq="12"

A flags paraméterrel megadott értékek azt jelzik, hogy a főport 7 alszámmal rendelkezik (0x700), valamint az összes port ugyanazon a megszakításon osztozik (0x001).

Sajnos még nem. Minden kártyához másik megszakítást kell megadni.

Ezzel kapcsolatban olvassuk el a FreeBSD kézikönyv soros kommunikációt tárgyaló részét.

Erre vonatkozóan olvassuk el a FreeBSD kézikönyv betárcsázós szolgáltatásokkal kapcsolatos részét.

Az ezzel kapcsolatos információkat a FreeBSD kézikönyv terminálokról szóló részében találhatjuk meg.

Előfordulhat, hogy rendszerünkön a tip(1) és cu(1) programok csak az uucp felhasználón és a dialer csoporton keresztül tudnak hozzáférni a működésükhöz szükséges /var/spool/lock könyvtárhoz. A dialer csoport segítségével lehet szabályozni, hogy ki férhessen hozzá a modemekhez vagy a távoli rendszerekhez. Ilyenkor egyszerűen csak vegyük fel magunkat a dialer csoportba.

A következő parancs kiadásával viszont ettől függetlenül is engedélyezhetjük a rendszerünkön belül, hogy bárki használhassa a tip(1) vagy cu(1) parancsokat:

# chmod 4511 /usr/bin/cu
# chmod 4511 /usr/bin/tip