Szerzői jog (c) 1995-2010 A FreeBSD Dokumentációs Projekt
A dokumentum továbbadása forrás (SGML DocBook) és feldolgozott formában (SGML, HTML, PDF, PostScript, RTF, stb.) módosítással vagy anélkül a következő feltételek mellett lehetséges:
A forráskódnak (SGML DocBook) tartalmaznia kell a fenti copyright megjegyzést és a feltételek ezen listáját, valamint a következő jogi nyilatkozatot, bármiféle módosítás nélkül.
Feldolgozott dokumentum továbbadásakor (más DTD, PDF, PostScript, RTF és más formátumok) szintén meg kell tartani a fenti copyright megjegyzést, a feltételek listáját, valamint a következő jogi nyilatkozatot a dokumentumban, vagy a dokumentumot kísérő anyagokban.
EZT A DOKUMENTUMOT A FREEBSD DOKUMENTÁCIÓS PROJEKT A JELEN FORMÁJÁBAN BIZTOSÍTJA ÉS LEMOND MINDEN KIFEJEZETT VAGY TÖRVÉNYI SZAVATOSSÁGRÓL, BELEÉRTVE AZ ELADHATÓSÁG ÉS EGY ADOTT CÉLRA VALÓ ALKALMASSÁG SZAVATOSSÁGÁT. A FREEBSD DOKUMENTÁCIÓS PROJEKT SEMMILYEN ESETBEN SEM TEHETő FELELőSSÉ A DOKUMENTUM HASZNÁLATÁBÓL EREDő BÁRMILYEN KÖZVETLEN, KÖZVETETT JÁRULÉKOS, KÜLÖNLEGES, BÜNTETő VAGY KÖVETKEZMÉNYES KÁRÉRT (BELEFOGLALVA, DE NEM KORLÁTOZVA A HELYETTESÍTő JAVAK BESZERZÉSÉRE, HASZON, ADAT VAGY PROFIT ELVESZTÉSÉRE, ILLETVE ÜZLETI FORGALOM KIESÉSÉRE) VAGY EGYÉB MÁS ESETBEN SEM, AMIKOR ERőS TEHER VAGY KÍN (HANYAGSÁG VAGY EGYÉB) ERED A DOKUMENTUM AKÁRMIFÉLE FELHASZNÁLÁSÁBÓL, MÉG HA ERRE KÜLÖN FEL IS HÍVTUK a FIGYELMET.
A FreeBSD a FreeBSD Foundation bejegyzett védjegye.
A 3Com és HomeConnect a 3Com Corporation bejegyzett védjegyei.
Az Adobe, Acrobat, Acrobat Reader, és PostScript az Adobe Systems Incorporated bejegyzett védjegyei, vagy védjegyei az Egyesült Államokban és/vagy más országokban.
A Sound Blaster a Creative Technology Ltd. védjegye az Egyesült Államokban és/vagy más országokban.
A CVSup John D. Polstra bejegyzett védjegye.
Az IBM, AIX, OS/2, PowerPC, PS/2, S/390 és ThinkPad az International Business Machines Corporation védjegyei az Egyesült Államokban, más országokban, vagy mindkettőben.
Az IEEE, POSIX és 802 az Institute of Electrical and Electronics Engineers, Inc. bejegyzett védjegyei az Egyesült Államokban.
Az Intel, Celeron, EtherExpress, i386, i486, Itanium, Pentium és Xeon az Intel Corporation vagy leányvállalatainak védjegyei vagy bejegyzett védjegyei az Egyesült Államokban és más országokban.
Az Iomega, Zip és Jaz az Iomega bejegyzett védjegyei vagy védjegyei az Egyesült Államokban és/vagy más országokban.
A Linux Linus Torvalds bejegyzett védjegye.
A Microsoft, IntelliMouse, MS-DOS, Outlook, Windows, Windows Media és Windows NT a Microsoft Corporation bejegyzett veacute;djegyei, vagy védjegyei az Egyesült Államokban és/vagy más országokban.
A MIPS és R4000 a MIPS Technologies, Inc. bejegyzett védjegyei az Egyesült Államokban és más országokban.
A Netscape és a Netscape Navigator a Netscape Communications Corporation bejegyzett védjegyei az Egyesült Államokban és más országokban.
A Motif, OSF/1 és UNIX a The Open Group bejegyzett védjegyei, az IT DialTone és a The Open Group pedig védjegyei az Egyesült államokban és/vagy más országokban.
Az Oracle az Oracle Corporation bejegyzett védjegye.
A Silicon Graphics, SGI és OpenGL a Silicon Graphics, Inc. bejegyzett védjegyei az Egyesült Államokban és/vagy más országokban világszerte.
A SPARC, SPARC64, és UltraSPARC a SPARC International, Inc védjegyei az Egyesült államokban és más országokban. A SPARC International, Inc birtokolja az összes SPARC védjegyet és annak tagjai között teszi azok megfelelő használatát elérhetővé a licencelési megegyezések alapján.
A Sun, Sun Microsystems, Java, Java Virtual Machine, JDK, JRE, JSP, JVM, Netra, OpenJDK, Solaris, StarOffice, SunOS és VirtualBox a Sun Microsystems, Inc. védjegyei vagy bejegyzett védjegyei az Egyesült Államokban és más országokban.
A U.S. Robotics és Sportster a U.S. Robotics Corporation. bejegyzett védjegyei.
Az XFree86 az XFree86 Project, Inc. védjegye.
A gyártók és terjesztők által használt megnevezések közül sok védjegy jogot követel. Ahol ilyen megnevezés tűnik fel ebben a dokumentumban, és a FreeBSD Projektnek tudomása volt a védjegyről, a megnevezést a "TM" vagy a "(R)" szimbólum követi.
Ezek a gyakran ismételt kérdések a FreeBSD
6.X
, 7.X
és 8.X
változataira
vonatkoznak. Az összes bejegyzés a FreeBSD
6.X
vagy annál újabb
változataira vonatkozik, hacsak azt külön nem
jelezzük. Ha szeretnénk segíteni a
projektnek, akkor küldjünk egy levelet a FreeBSD Dokumentációs Projekt levelezési lista
címére! Ennek a dokumentumnak a legfrissebb
változata mindig elérhető a FreeBSD World Wide Web szerveréről.
HTTP-n keresztül letölthető egyetlen nagy HTML állományként,
vagy a FreeBSD
FTP szerveréről szöveges, PostScript(R)
PDF stb. formátumban. Továbbá keresni is tudunk a
GYIK-ban.
Fordította: Páli Gábor, utolsó ellenőrzés: 2010.11.28.
Üdvözöljük a FreeBSD
6.X
-8.X
Gyakran Ismételt Kérdéseiben!
Hasonlóan a Usenetes GYIK-okhoz, ennek a dokumentumnak is az a célja, hogy a FreeBSD operációs rendszerrel kapcsolatban feltegye a legyakrabban ismételt kérdéseket (és persze megválaszolja ezeket!). Habár eredetileg azért íródott, hogy megspórolja a feleslegesen elvesztegetett sávszélességet és hogy megelőzze a régóta ismert kérdések újbóli feltételét, a GYIK időközben egy értékes információforrássá is vált.
Igyekeztünk minden megtenni annak érdekében, hogy a GYIK a lehető legtöbb információt szolgáltassa. Ha szeretnénk javaslatokat tenni a továbbfejlesztésére, írjunk bátran a FreeBSD Dokumentációs Projekt levelezési lista címére!
1.1. | Mi az a FreeBSD? |
Ha tömören akarjuk összefoglalni, akkor a FreeBSD egy AMD64, Intel(R) EM64T, i386TM, PC-98, IA-64, ARM(R), PowerPC(R) és UltraSPARC(R) platformokra fejlesztett UNIX(R)-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 i386TM 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. | |
1.2. | Mi a FreeBSD Projekt célja? |
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. | |
1.3. | A FreeBSD licenc tartalmaz valamilyen megszorítást? |
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:
| |
1.4. | A FreeBSD képes kiváltani a jelenleg használt operációs rendszerünket? |
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(R) rendszergazdákat egyaránt, asztali operációs rendszerként is a FreeBSD-t használja. Ha egy másik UNIX(R) 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)-ról vagy a Mac OS(R) valamelyik régebbi változatáról szándékozunk átállni, minden bizonnyal időt kell majd szánnunk a feladatok UNIX(R) 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. | |
1.5. | Miért hívják FreeBSD-nek? |
É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. | |
1.6. | Mi a különbség a FreeBSD, a NetBSD, OpenBSD és a többi nyílt forráskódú BSD operációs rendszerek között? |
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. | |
1.7. | Melyik a FreeBSD legújabb változata? |
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. A 8.0-s kiadás megjelenéséig a
7. 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. | |
1.8. | Mi az a FreeBSD-CURRENT? |
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:
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 | |
1.9. | Mit takar a FreeBSD-STABLE? |
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. 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. | |
1.10. | Mikor készülnek FreeBSD kiadások? |
A Release Engineering Team 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. | |
1.11. | Ki felel a FreeBSD-ért? |
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. | |
1.12. | Honnan lehet a FreeBSD-t beszerezni? |
A FreeBSD összes fontosabb kiadása elérhető anonim FTP-n keresztül a FreeBSD FTP oldaláról:
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. | |
1.13. | Hogyan lehet elérni a hibajelentések adatbázisát? |
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. | |
1.14. | Honnan tudhatunk meg még többet? |
Nézzük meg a FreeBSD Projekt honlapjáról elérhető dokumentációkat. |
2.1. | Milyen jó könyvek szólnak a FreeBSD-ről? | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
A Projekt igen széles körű
dokumentációval rendelkezik, amely a
következő linkről érhető el:
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
2.2. | A dokumentáció elérhető más formátumokban is, például szöveges (ASCII) állományban vagy PostScript(R)-ben? | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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:
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
A művelet befejeződésével kapunk
néhány | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
2.3. | Hol található információ a FreeBSD levelezési listáiról? | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Az összes velük kapcsolatos információt a kézikönyv levelezési listákról szóló részében találjuk. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
2.4. | Milyen FreeBSD hírcsoportok léteznek? | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Az összes rájuk vonatkozó információt a kézikönyv hírcsoportokról szóló részében találjuk meg. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
2.5. | Vannak FreeBSD-s IRC (Internet Relay Chat) csatornák? | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Igen, a legtöbb nagyobb IRC hálózaton található FreeBSD-vel foglalkozó csatorna:
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! | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
2.6. | Hol kaphatok kereskedelmi szintű FreeBSD tréninget és támogatást? | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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! |
3.1. | Milyen állományokat kell letöltenünk a FreeBSD telepítéséhez? | ||||||||||||||||||
Ehhez a következő három floppy image-re
lesz alapvetően szükségünk:
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:
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. | |||||||||||||||||||
3.2. | Mit tegyünk, ha a floppy image-ek nem férnek rá egyetlen lemezre? | ||||||||||||||||||
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:
| |||||||||||||||||||
3.3. | Hol található leírás a FreeBSD telepítéséről? | ||||||||||||||||||
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ó. | |||||||||||||||||||
3.4. | Mire van szükség a FreeBSD használatához? | ||||||||||||||||||
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. | |||||||||||||||||||
3.5. | Hogyan lehet saját telepítőfloppyt készíteni? | ||||||||||||||||||
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. | |||||||||||||||||||
3.6. | Windows(R) mellé is telepíhető FreeBSD? | ||||||||||||||||||
Először telepítsük a Windows(R)t, majd a FreeBSD-t. A FreeBSD boot managere ekkor képes lesz a Windows(R) és a FreeBSD indítására is. Vigyázzunk, mert ha a Windows(R)t 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. | |||||||||||||||||||
3.7. | A Windows(R) letörölte a boot managert! Hogyan lehet visszaállítani? | ||||||||||||||||||
A FreeBSD-hez tartozó boot managert háromféleképpen tudjuk újratelepíteni:
| |||||||||||||||||||
3.8. | Az A, T és X sorozatú IBM Thinkpad laptopok lefagynak a FreeBSD telepítése utáni első indulásuk során. Hogy lehet ezen segíteni? | ||||||||||||||||||
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 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. | |||||||||||||||||||
3.9. | Lehet telepíteni hibás szektorokat tartalmazó lemezre is? | ||||||||||||||||||
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. | |||||||||||||||||||
3.10. | Furcsa dolgok történnek a telepítőfloppy használata közben! Mi okozhatja? | ||||||||||||||||||
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:
Kaptunk olyan visszajelzést is, hogy gondjaink lehetnek, ha Netscape(R)-pel töltjük le a rendszerindító lemezeket, ezért lehetőség szerint igyekezzünk más FTP klienst használni. | |||||||||||||||||||
3.11. | ATAPI CD-meghajtóról indult a rendszer, de a telepítő szerint nem található semmilyen CD-meghajtó. Hova tűnt? | ||||||||||||||||||
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(R) 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. | |||||||||||||||||||
3.12. | PLIP (Parallel Line IP) használatával lehet laptopra telepíteni? | ||||||||||||||||||
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. | |||||||||||||||||||
3.13. | A lemezmeghajtók esetében milyen geometriai beállításokat érdemes használni? | ||||||||||||||||||
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 Ha viszont
engedélyeztük (ami gyakran
előfordul, mivel így lehet az MS-DOS(R) bizonyos
korlátozásait megkerülni) és a
lemez kapacitása 1 GB-nál több,
adjunk meg 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
| |||||||||||||||||||
3.14. | Van valamilyen korlátozás a lemezek felosztására vonatkozóan? | ||||||||||||||||||
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. | |||||||||||||||||||
3.15. | A FreeBSD kompatibilis valamilyen disk managerrel? | ||||||||||||||||||
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. | |||||||||||||||||||
3.16. | Amikor a FreeBSD-t telepítése után először elindul, akkor egy Hiányzó operációs rendszer vagy egy Missing Operating System hiba jelenik meg. Mi történt? | ||||||||||||||||||
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! | |||||||||||||||||||
3.17. | Miért nem lehet továbblépni a boot
manager | ||||||||||||||||||
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. | |||||||||||||||||||
3.18. | Az összes forrást telepíteni kell? | ||||||||||||||||||
Alapvetően nem. Ettől függetlenül
azonban javasoljuk legalább a 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 (Egyéni telepítés), majd a (Terjesztések) menübe. | |||||||||||||||||||
3.19. | Kell rendszermagot fordítani? | ||||||||||||||||||
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. | |||||||||||||||||||
3.20. | A jelszavak tárolására használható-e DES, Blowfish vagy MD5, és ha igen, akkor hogyan lehet megadni? | ||||||||||||||||||
A FreeBSD alapértelmezés szerint
MD5-alapú jelszavakat
használ. Ezeket a DES
algoritmuson alapuló hagyományos UNIX(R)-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
| |||||||||||||||||||
3.21. | A rendszerindító lemez először
elindul, de aztán miért akad meg a
| ||||||||||||||||||
Ha a rendszerünkhöz IDE-s Zip(R) vagy Jaz(R) 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. | |||||||||||||||||||
3.22. | A rendszer telepítését követő újraindítás után miért jelenik meg a panic: can't mount root hibaüzenet? | ||||||||||||||||||
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 Ezt a félreértést a következő módokon lehet helyretenni:
| |||||||||||||||||||
3.23. | Mennyi memóriát tudunk használni? | ||||||||||||||||||
A memóriára vonatkozó korlátozások platformonként változnak. Egy szabványos i386TM 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 i386TM 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). | |||||||||||||||||||
3.24. | Mik az FFS állományrendszerek korlátai? | ||||||||||||||||||
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. 3.1. táblázat - Az állományok maximális
mérete
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. 10243 + 10242 + 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. | |||||||||||||||||||
3.25. | Egy új rendszermag fordítása után miért jelenik meg a archsw.readin.failed hibaüzenet az indítás során? | ||||||||||||||||||
Mert a rendszermag és a
felhasználói programok verziója
eltér. A rendszermag frissítésekor
feltétlenül használjuk a 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 | |||||||||||||||||||
3.26. | A telepítés megszakad a rendszer indítása közben, mit lehet ezzel kezdeni? | ||||||||||||||||||
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:
Majd ezt:
|
4.1.1. | A FreeBSD rendszerükhöz szeretnénk hardvert vásárolni. Melyik gyártmány/márka/típus a legjobb? |
Ez állandó téma a FreeBSD levelezési listákon. Mivel a hardverek gyorsan változnak, nem is számíthatunk másra. Továbbra is határozottan javasoljuk, hogy olvassuk át figyelmesen a FreeBSD 8.1 vagy 7.3 változatához tartozó hardverjegyzéket (Hardware Notes) és nézzünk után a levelezési listák archívumában mielőtt bármire is rákérdeznéünk a legfrissebb és legjobb hardverek ügyében. Könnyen előfordulhat, hogy éppen a múlt héten esett szó arról a típusú eszközről, amiről éppen érdeklődni szeretnénk. Ha laptoppal kapcsolatban lenne kérdésünk, akkor nézzük meg a FreeBSD laptop computer levelezési lista archívumát. Minden más esetben érdemes inkább a FreeBSD general questions levelezési lista archívumait megnézni vagy az adott hardverhez tartozó levelezési listát böngészni. |
4.2.1. | A FreeBSD képes 4 GB-nál, 16 GB-nál vagy akár 48 GB-nál több memóriát (RAM-ot) támogatni? |
Igen. A FreeBSD operációs rendszerként képes az adott platformon kihasználni az összes rendelkezésre álló fizikai memóriát. Ne felejtsük el azonban, hogy az egyes platformokon ennek határa eltér. Például az i386TM platformon a PAE használata nélkül legfeljebb csak 4 GB memóriát tudunk elérni (amely azonban a PCI számára fenntartott címtér miatt a valóságban némileg kevesebb), illetve a PAE használatával legfeljebb 64 GB memóriát. Az AMD64 platformokon viszont már egészen 1 TB memóriáig is elmehetünk. | |
4.2.2. | A FreeBSD miért jelez 4 GB-nál kevesebb memóriát i386TM architektúrájú számítógépeken? |
Az i386TM platformon a címtér 32 bites, ami azt jelenti, hogy itt legfeljebb 4 GB memória címezhető meg (és érhető el). Ráadásul a címtér bizonyos tartományait a hardvereszközök számára tartják fenn különböző célokra, például a PCI eszközök működtetésére és vezérlésére, a videomemória hozzáférésére stb. Ennélfogva az operációs rendszer és annak rendszermagja által felhasználható teljes memória mérete jelentősen kevesebb, mint 4 GB. Ezen a típusú konfigurációkon általában 3,2 GB és 3,7 GB között mozog a maximálisan kihasználható fizikai memória mérete. Ha mégis 3,2 vagy 3,7 GB-nál több memóriát szeretnénk elérni (4 GB-ot vagy akár annál is többet), akkor ahhoz a PAE nevű speciális módosításra lesz szükségünk. A PAE a "Physical Address Extension" ("Fizikai címkiterjesztés") rövidítése, és egy olyan módszerre utal, amellyel a 32 bites x86 típusú processzorokon tudunk 4 GB-nál több memóriát címezni. Lényegében nem csinál mást, csak 4 GB-os határ felé képezi le azokat a memóriaterületeket, amelyeket egyébként a hardverek részére tartanak fenn, ezzel kiegészíti a fizikai memóriát (pae(4)). A PAE használatának számos hátránya van: ebben a módban a megszokottnál (vagyis PAE nélkül) némileg lassabb a memória elérése, illetve ilyenkor a betölthető rendszermag-modulok (lásd kld(4)) sem támogatottak. Emiatt az összes meghajtót bele kell fordítanunk a rendszermagba. A PAE használatát
általában a options PAE A PAE alkalmazása napjainkban annyira már nem jellemző, mivel az újabb x86 hardverek mindegyike képes 64 bites (AMD64 vagy Intel(R) 64) módban futni. Ebben az esetben már lényegesen nagyobb címtér használatára nyílik lehetőségünk, így nincs szükségünk további trükkökre. A FreeBSD támogatja az AMD64 architektúrát, így ha 4 GB-nál több memóriát szeretnénk elérni, akkor inkább a FreeBSD ezen változatát érdemes alkalmazni. |
4.3.1. | A FreeBSD az x86-on kívül támogat más architektúrájú rendszereket is? |
Igen. A FreeBSD jelenleg az Intel x86 és az AMD64 architektúrákon működik. A Az Intel EM64T, IA-64, ARM(R), PowerPC(R), sun4v és SPARC64(R) architektúrák is támogatottak. A további tervezett platformok között van még a MIPS(R) és az S/390(R), a MIPS(R) aktuális állapotáról és FreeBSD MIPS levelezési lista segítségével értesülhetünk. Az újabb architektúrákhoz kapcsolódó általános jellegű megbeszéléseket a FreeBSD non-Intel platforms levelezési lista foglalja össze. Amennyiben a számítógépünk architektúrája nem szerepel a jelenleg támogatottak között, és valamilyen gyors megoldásra lenne szükségünk, akkor javasoljuk a NetBSD vagy az OpenBSD használatát. | |
4.3.2. | A FreeBSD támogatja a szimmetrikus többprocesszoros (SMP) rendszereket? |
A FreeBSD általánosságban véve támogatja a többprocesszoros rendszereket, noha egyes esetekben a BIOS vagy az alaplap hibájából fakadóan problémáink adódhatnak. A FreeBSD symmetric multiprocessing levelezési lista átolvasása segíthet tisztázni ezeket. A FreeBSD képes kihasználni az Intel
processzorai által felkínált
HyperThreading (HTT) támogatás előnyeit.
Az |
4.4.1. | A FreeBSD milyen típusú merevlemezes meghajtókat ismer? |
A FreeBSD ismeri az EIDE-, SATA-, SCSI- és SAS-meghajtókat (és a velük kompatibilis vezérlőket, erről bővebben lásd a következő szakaszt), valamint az összes olyan meghajtót, amely az eredeti "Western Digital" (MFM, RLL, ESDI és természetesen az IDE) interfészt használja. Néhány egyedi fejlesztésű ESDI vezérlő nem fog működni, ezért lehetőleg maradjunk a WD1002/3/6/7 interfészeknél és azok másolatainál. | |
4.4.2. | Milyen SCSI- vagy SAS-vezérlőket ismer? |
A teljes listát a FreeBSD hardverjegyzékében találhatjuk meg a 8.1 vagy 7.3 kiadásban. | |
4.4.3. | Milyen szalagos meghajtókat ismer? |
A FreeBSD a SCSI és QIC-36 (QIC-02 interfésszel) szabványokat ismeri. Ezek közé értendőek a 8 mm-es (más néven Exabyte) és DAT-meghajtók is. Bizonyos régebbi 8 mm-es meghajtók nem egészen kompatibilisek a SCSI-2 szabvánnyal, ezért a FreeBSD-vel sem feltétlenül képesek együttműködni. | |
4.4.4. | A FreeBSD támogatja a szalagok cseréjét? |
A FreeBSD ch(4) eszközön és a chio(1) parancson keresztül támogatja a SCSI szabványú szalagcserélőket. A használat pontos részleteiről a chio(1) man oldalán olvashatunk részletesebben. Ha nem az AMANDA vagy a hozzá hasonló programokat használjuk, amelyek alapból ismerik a szalagcserélés lehetőségét, akkor ne feledkezzünk meg arról, hogy a szalagot csak az egyik helyről a másikra tudjuk mozgatni, ezért nekünk kell figyelnünk arra, hogy melyik rekeszben vannak szalagok és a meghajtónak ezek közül melyiket kell használnia. | |
4.4.5. | A FreeBSD milyen CD-meghajtókat ismer? |
Bármilyen támogatott SCSI-vezérlőhöz csatlakoztatható SCSI-meghajtót ismer. Ezenkívül még az alábbi CD-interfészek ismertek:
Az összes ismert nem-SCSI kártya nagyon lassan működik a SCSI-meghajtókhoz képest, és bizonyos ATAPI CD-meghajtók nem használhatóak. A Daemon News-tól és a FreeBSD Mall-tól rendelhető hivatalos FreeBSD CD-kről akár közvetlenül el is tudjuk indítani a rendszert. | |
4.4.6. | A FreeBSD milyen CD-RW meghajtókat ismer? |
A FreeBSD bármilyen ATAPI-kompatibilis IDE CD-R vagy CD-RW meghajtót ismer. Ennek részleteit lásd a burncd(8) man oldalán. A FreeBSD ezeken kívül még
tetszőleges SCSI CD-R vagy CD-RW meghajtót
támogat. A használatukhoz
telepítsük a | |
4.4.7. | A FreeBSD ismeri az Zip(R) meghajtókat? |
A FreeBSD alapból ismeri a SCSI és ATAPI (IDE) interfészen kommunikáló Zip(R) meghajtókat. A SCSI ZIP-meghajtók ugyan egyedül az 5 és 6 target ID-kről hajlandóak működni, de ha a SCSI-kártyánk BIOS-a támogatja, akkor még a rendszert is el tudjuk indítani róluk. Egyelőre nem tisztázott, hogy milyen kártyák képesek a 0 és 1 ID-ken kívül máshonnan is rendszert indítani, ezért ennek a hozzá tartozó dokumentációben érdemes utánajárnunk. A FreeBSD ezenkívül még a
párhuzamos porton csatlakoztatható
ZIP-meghajtókat is ismeri. Ehhez
ellenőrizzük, hogy a rendszermagunkban
megtalálhatóak az
Emellett még érdemes a GYIK cserélhető lemezes meghajtókról szóló részét is elolvasnunk ebben a fejezetben, valamint a "formázásról" szóló megjegyzést az adminisztrációról szóló fejezetben. | |
4.4.8. | A FreeBSD ismeri a Jaz(R), EZ és a többi cserélhető lemezes meghajtót? |
Használhatóak. Ezek többsége SCSI eszköz, ezért a FreeBSD SCSI-lemezként látja, az IDE csatolós EZ pedig IDE-meghajtóként érhető el. A rendszer indítása előtt ne felejtsük el bekapcsolni a külső egységeket. Ha tárolóeszközt akarunk cserélni a rendszer működése közben, olvassuk el a mount(8), umount(8) és (SCSI eszközök esetén) a camcontrol(8) vagy (IDE eszközök esetén) a atacontrol(8) man oldalakat, valamint a GYIK egy későbbi részében található részt a cserélhető lemezes meghajtókról. |
4.5.1. | A FreeBSD ismeri az USB billentyűzeket? |
A FreeBSD alapból ismeri az USB billentyűzeket.
Miután engedélyeztük rendszerünkben
az USB billentyűzet támogatását,
az AT billentyűzet Ha az USB billentyűzetet konzolban akarjuk használni, akkor erre figyelmeztetnünk kell a konzolos meghajtót. Ezt úgy tudjuk megtenni, ha a következő parancsot lefuttatjuk a rendszer indítása közben:
Amikor viszont csak USB billentyűzetünk van,
akkor az
Megjegyzés:Ha véglegesíteni akarjuk ezt a
beállítást, akkor tegyük a
Miután ezt megcsináltuk, az USB billentyűzet X alatt is működni fog minden további beállítás nélkül. Ezzel a paranccsal tudunk visszaváltani az alapértelmezett billentyűzetre:
A kbdmux(4) meghajtón keresztül az alábbi parancsok kiadásával engedélyezhetjük az elsődleges AT billentyűzet és a másodlagos USB billentyűzet párhuzamos használatát a konzolon:
Részletesebb információkat az ukbd(4), kbdcontrol(1) és kbdmux(4) man oldalakon találhatunk. Megjegyzés:Az USB billentyűzet menet közbeni csatlakoztatása és leválasztása nem feltétlenül fog működni. Ezért a problémák elkerülése érdekében azt javasoljuk, hogy a rendszer indítása előtt mindenképpen csatlakoztassuk a billentyűzetet és hagyjuk egészen úgy, amíg le nem állítottuk. | |
4.5.2. | A nem szabványos buszos egereket hogyan lehet beállítani? |
A FreeBSD ismeri a buszos, illetve a Microsoft, Logitech
és az ATI által gyártott InPort buszos
egereket. A device mse0 at isa? port 0x23c irq5 A buszos egerekhez általában saját interfészkártya is tartozik. Ezeket a kártyákat a fentitől eltérő portcímre és IRQ megszakításra is beállíthatjuk. Részletesebb információkat az egerünk man oldalán és a mse(4) man oldalon olvashatunk. | |
4.5.3. | Hogyan lehet PS/2 ("egérportos" vagy "billentyűzetes") egeret használni? |
Az PS/2 egereket alapból támogatjuk. Az
ehhez szükséges Ha a saját magunk által összeállított rendszermagunk nem tartalmazza ezt a meghajtót, akkor a következő sort kell felvennünk a konfigurációs állományba: device psm0 at atkbdc? irq 12 Miután a rendszermag a rendszer
indítása során helyesen észlelte
a | |
4.5.4. | Az egeret az X Window Systemen kívül is lehet valamilyen módon használni? |
Ha az alapértelmezett konzolos syscons(4) meghajtót használjuk, akkor a szöveges felületű konzolokon az egérmutató segítségével tudunk szövegrészeket kijelölni és másolni. Ehhez nem kell mást tennünk, csupán elindítani a moused(8) egérdémont és engedélyezni az egérmutatót a virtuális konzolokon:
Itt az Ha PS/2 egerünk van, akkor egyszerűen csak
vegyük fel a Miután az egérdémon elindult, valamilyen módon koordinálni kell az egér hozzáférését az egérdémon és az összes többi program, például az X Window System között. Erről a problémáról a GYIK Miért nem működik X alatt az egér? kérdésében olvashatunk részletesebb. | |
4.5.5. | Hogyan lehet szöveget kijelölni és másolni a szöveges konzolban? |
Ahogy sikerült elindítanunk az egérdémont (lásd az előző szakaszt), tartsuk lenyomva az egér első (bal oldali) gombját és az egér mozgatásával jelöljük ki a szöveget. Ezután nyomjuk le a második (középső) gombját, amivel a kurzor mellett megjelenik az imént kijelölt szöveg. A harmadik (jobb oldali) gomb segítségével a szöveg kijelölését tudjuk "kiterjeszteni". Amennyiben az egerünkön nem található középső gomb, az egérdémon beállításainak segítségével megpróbálkozhatunk emulálni vagy áthelyezni a vele kapcsolatos funkciókat egy másik gombra. A moused(8) man oldalán olvashatunk erről részletesebben. | |
4.5.6. | Az egéren van mindenféle görgő és gomb. Ki lehet ezeket valahogy használni FreeBSD alatt is? |
A válaszunk erre sajnos csupán annyi, hogy "Attól függ". A különböző kiegészítőkkel rendelkező egerekhez általában egy külön meghajtó szükségeltetik. Hacsak az egér meghajtóprogramja vagy a hozzá tartozó felhasználói program nem nyújt valamilyen támogatást, az eszköz egyszerűen csak egy szabványos két- vagy háromgombos egérként fog funkcionálni. Ha az X Window környezetben akarunk görgőket használni, esetleg ezt a szakaszt érdemes elolvasnunk. | |
4.5.7. | A laptopokon megtalálható egér/trackball/touchpad hogyan használható? |
Olvassuk el az előző kérdésre adott választ. | |
4.5.8. | A Delete billentyű hogyan
használható a |
A Bourne Shell
esetében az alábbi sorokat kell megadnunk az
bind ^? ed-delete-next-char # a konzolhoz bind ^[[3~ ed-delete-next-char # az xtermhez A C Shell esetében a
következő soroknak kell az
bindkey ^? delete-char # a konzolhoz bindkey ^[[3~ delete-char # az xtermhez További információkat ezen az oldalon találhatunk. |
4.6.1. | A FreeBSD milyen hálózati kártyákat ismer? |
Ezek teljes listáját a FreeBSD egyes kiadásaihoz tartozó hardverjegyzékben találjuk meg. | |
4.6.2. | A FreeBSD ismer szoftveres modemeket, például winmodemeket? |
A FreeBSD különböző kiegészítő szoftvereken keresztül több szoftveres modemet is támogat. A comms/ltmdm port például a szélesebb körben elterjedt Lucent LT chipsetes modemekhez ad támogatást. A FreeBSD azonban nem telepíthető szoftveres modemen keresztül. A hozzá tartozó szoftvert csak az operációs rendszer telepítése után tudjuk telepíteni. | |
4.6.3. | Van natív meghajtó a Broadcom 43xx típusú kártyákhoz? |
Nem, és valószínűleg nem is lesz. A Broadcom nem hajlandó nyilvánossá tenni azokat az információkat, amik az általuk gyártott vezeték nélküli chipsetek programozásához lennének szükségesek, mivel szoftveresen vezérelt rádiót használnak. Az alkatrészeik FCC szintű engedélyeztetéséhez ugyanis valamilyen módon gondoskodniuk kell róla, hogy a felhasználók nem képesek bizonyos dolgokat módosítani vele kapcsolatban, például a működési frekvenciát, a modulációs paramétereket vagy a kimenő teljesítményt. A chipsetek programozásának ismerete nélkül azonban szinte lehetetlen elkészíteni hozzájuk a megfelelő meghajtót. | |
4.6.4. | A FreeBSD milyen többportos soros vonali kártyákat ismer? |
Ezek listáját a kézikönyv Soros vonali kommunikációról szóló része tartalmazza. Bizonyos névtelen másolatok is használhatók, különösen azok, amelyek magukat AST-kompatibilisnek nevezik. Az ilyen kártyák beállításáról a sio(4) man oldalon olvashatunk részletesebben. | |
4.6.5. | Hogyan lehet a |
Olvassuk el a kézikönyvben ezt a fejezetet. |
4.7.1. | A FreeBSD milyen hangkártyákat ismer? |
A FreeBSD rengeteg hangkártyát ismer, (ennek részleteit lásd a FreeBSD kiadásait tartalmazó honlapon és a snd(4) man oldalon). Korlátozott módon az MPU-401 és a vele kompatibilis MIDI-kártyákat is támogatja. A Microsoft(R) Sound System specifikációinak megfelelő kártyákat tudjuk használni. Megjegyzés:Ez azonban csak a hangra vonatkozik! Ez a meghajtó a SoundBlaster(R) kivételével nem támogatja a kártyákon található CD-, SCSI- és joystick csatlakozásokat. A SoundBlaster(R) SCSI csatlakozása és bizonyos nem-SCSI CD-meghajtókat ugyan támogat, de rendszert például nem tudunk róluk indítani. | |
4.7.2. | Miért nincs hang a pcm(4) által támogatott hangkártyán? |
Egyes hangkártyák esetében a hangerő minden indításkor nullára állítódik. Ezért ilyenkor mindig ki kell adni a következő parancsot:
|
4.8.1. | Képes a FreeBSD kihasználni az energiagazdálkodási lehetőségeket egy laptopon? |
A FreeBSD bizonyos gépeken képes az APM használatára. Erről az apm(4) man oldalon találunk pontosabb leírást. A FreeBSD ezenkívül még a legújabb hardverekben megtalálható ACPI lehetőségeit is igyekezik kihasználni. Erről részletesebben az acpi(4) man oldalon olvashatunk. Amennyiben a rendszerünk egyaránt tartalmazza az APM és az ACPI támogatását, bármelyiket használhatjuk. Ilyen esetben javasoljuk mind a kettő kipróbálását és az igényeinkhez leginkább illeszkedő megoldás kiválasztását. | |
4.8.2. | Hogy lehet letiltani az ACPI támogatását? |
Tegyük bele az alábbi sort az
hint.acpi.0.disabled="1" | |
4.8.3. | Miért fagynak le a Micron típusú rendszerek indulás közben? |
Egyes Micron gyártmányú alaplapokon olyan PCI BIOS található, amely nem felel meg az szabványoknak, és ezért a FreeBSD nem tud elindulni, mivel a PCI eszközök nem jelentik le az általuk használt címeket. Ezt a problémát úgy tudjuk
megoldani, ha a BIOS-ban kikapcsoljuk
( | |
4.8.4. | A rendszerindító lemez nem képes az ASUS K7V alaplapokkal működni. Hogyan lehet ezt orvosolni? |
Menjünk be a BIOS-ba és kapcsoljuk ki
(állítsuk | |
4.8.5. | Miért nem működnek a 3Com(R) PCI hálózati kártyák a Micron típusú számítógépekben? |
Nézzük meg az előző választ. |
5.1. | Miért állapítja meg rosszul a FreeBSD a memória mennyiségét i386TM hardveren? |
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. | |
5.2. | Mit tegyünk, ha meghibásodott szektorokat találunk a merevlemezünkön? |
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 (
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. | |
5.3. | A FreeBSD miért nem találja meg a HP Netserver SCSI-vezérlőjét? |
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 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. Megjegyzés:A HP Netserver esetén nem tudunk a
lemezeken | |
5.4. | Állandóan ed1: timeout és ahhoz hasonló üzenetek jelennek meg. Mi lehet velük kezdeni? |
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 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. | |
5.5. | Miért állnak le a 3Com(R) 3C509 kártyák minden különösebb ok nélkül? |
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
| |
5.6. | A párhuzamos nyomtató nevetségesen lassú. Mi lehet ezzel kezdeni? |
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. | |
5.7. | A programok miért állnak le időnként Signal 11 hibákkal? |
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:
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
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:
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(R) 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). | |
5.8. | A rendszer összeomlik vagy egy Fatal trap 12: page fault in kernel mode vagy pedig valamilyen panic: hibaüzenettel és egy halom számot ír ki. Mit tegyünk? |
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. | |
5.9. | A rendszer indulása közben miért sötétül a képernyő és megy el rajta a kép? |
Ez az ATI Mach 64 videokártyák
esetében jelentkező probléma. Ilyenkor az
a gond, hogy a kártya a A hibát kijavításáig így kerülhetjük meg:
Ha a soros portokat is használni akarjuk, akkor
következő módosításokkal
készítsünk egy új rendszermagot: a
| |
5.10. | A FreeBSD miért csak 64 MB memóriát használ, amikor 128 MB van a gépben? |
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= ahol | |
5.11. | A számítógépben több mint 1 GB memória van, de mégis kmem_map too small üzenetek jelennek meg. Mi a gond? |
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 | |
5.12. | A számítógépben nincs 1 GB memória, a FreeBSD mégis kmem_map too small hibával leáll! |
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. | |
5.13. | Miért jelenik meg a kernel: proc: table is full hibaüzenet? |
A FreeBSD rendszermagja egyszerre csak bizonyos
számú programot enged futni. Ezek
konkrét száma a
A 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
A sysctl változók
beállításait úgy is tudjuk
véglegesíteni, ha felvesszük ezeket az
| |
5.14. | Az új rendszermag indításakor miért keletkezik CMAP busy hibaüzenet? |
Az elavult Amikor ilyen történik, indítsuk újra a rendszert egyfelhasználós módban és gépeljük be:
| |
5.15. | Mit jelent az ahc0: brkadrint, Illegal Host Access at seqaddr 0x0 üzenet? |
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ó
| |
5.16. | Amikor elindul a rendszer, egy ahc0: illegal cable configuration hibaüzenet jelenik meg. A kábelek bekötésével semmilyen gond nincs. Mégis akkor mi a baj? |
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. | |
5.17. | Miért küld a sendmail mail loops back to myself hibaüzenetet? |
Erről részletesebben a kézikönyvben olvashatunk. | |
5.18. | A távoli gépeken miért viselkednek olyan furcsán a teljes képernyős alkalmazások? |
Előfordulhat, hogy az adott távoli
gépen a terminál típusa nem
Ezt a problémát többféle módon is meg tudjuk kerülni:
| |
5.19. | A Plug and Play kártyákat miért nem
találja meg (vagy |
Ennek az okait a következő levélben
fejtette ki Peter Wemm 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. Megjegyzés:Az eredeti szövegből készült idézetet frissítettü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:
[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 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
Ebből a Ezt az információt (a Ehhez először is készítsünk
egy biztonsági másolatát a
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
| |
5.20. | Miért keletkezik nlist
failed hiba például a
|
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:
| |
5.21. | Miért tart olyan sokáig
|
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
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
| |
5.22. | Mire utal a stray IRQ (kóbor megszakítási kérés) üzenet? |
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:
| |
5.23. | Miért jelenik meg folyamatosan a file: table is full üzenet a rendszernaplóban? |
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. | |
5.24. | Miért árasztják el calcru: negative runtime vagy calcru: runtime went backwards üzenetek a konzolt? |
Ismert egy olyan probléma, hogy a BIOS-ban engedélyezzük az Intel(R) 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(R) 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. | |
5.25. | Miért jár rosszul az óra a számítógépen? |
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
Erről a
Előfordulhat, hogy az ACPI-időzítő
hibás. Ilyenkor az a legegyszerűbb, ha az
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
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
kern.timecounter.hardware=i8254 | |
5.26. | A rendszer laptopon miért nem tudja rendesen megtalálni a PC-kártyákat? |
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. | |
5.27. | Miért ad a FreeBSD rendszertöltője Read error hibát és áll meg a BIOS képernyőn? |
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 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. | |
5.28. | Egy másik operációs rendszer letörölte a boot managert. Hogyan lehet visszaállítani? |
Indítsuk el a sysinstall(8) programot, majd válasszuk a és 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. | |
5.29. | Mit jelent a swap_pager: indefinite wait buffer: hibaüzenet? |
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
| |
5.30. | Mik azok a UDMA ICRC hibák és hogyan lehet ellenük tenni valamit? |
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 | |
5.31. | Mi az a lock order reversal? |
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. | |
5.32. | Mit jelent a Called ... with the following non-sleepable locks held üzenet? |
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. | |
5.33. | A
|
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
|
Ez a fejezet még nagyon rövid, de természetesen reméljük, hogy a különböző cégek hamarosan bővíteni fogják! :) A FreeBSD fejlesztőinek ezzel kapcsolatban semmilyen anyagi érdekük nincs, csupán szeretnék felsorolni a nyilvánosan is elérhető szolgáltatásokat (de úgy érezzük, hogy a FreeBSD kereskedelmi irányú megközelítése a FreeBSD fejlődésére is jó hatással lehet hosszabb távon). Javasoljuk minden kereskedelmi fejlesztőnek, hogy küldjék be ide is a saját kérdéseiket. A gyártók honlapján olvashatjuk a teljes listájukat.
6.1. | Honnan lehet a FreeBSD-hez irodai programcsomagokat szerezni? |
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. | |
6.2. | Honnan lehet a Motif(R)-ot szerezni a FreeBSD-hez? |
A The Open Group kiadta a Motif(R) 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. Megjegyzés:Az Open Motif(R) kizárólag csak nyílt forráskódú operációs rendszereken terjeszthető. Ezenkívül még használhatóak a Motif(R) 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(R) 2.1.20 ELF (i386TM) 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:
A megrendelés során ne felejtsük el megadni, hogy a Motif(R) 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.
| |
6.3. | Honnan lehet FreeBSD-re CDE-t szerezni? |
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. | |
6.4. | Használhatóak adatbázisrendszerek FreeBSD alatt? |
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. | |
6.5. | Az Oracle(R) fut FreeBSD alatt? |
Igen. A |
7.1. | Hol vannak a felhasználói programok? |
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. 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
menün belül)
található
menüpontban tudjuk telepíteni, vagy
meghívjuk meg a pkg_add(1) parancsot. A
csomagokat leginkább
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. | |
7.2. | Hogyan tudjuk beállítani az INN (Internet News) szolgáltatást a gépünkön? |
Telepítsük az news/inn csomagot vagy portot és utána kiindulásképpen nézzük meg az INN GYIK-ot. | |
7.3. | A FreeBSD rendelkezik JavaTM támogatással? |
Igen. Látogassunk el a http://www.FreeBSD.org/java/ oldalra. | |
7.4. | Miért nem fordul egy port a
6. |
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. | |
7.5. | A |
Elsőként mindig ellenőrizzük, hogy
a Portgyűjteményünk a lehető
legfrissebb. A legfrissebb változatnál
jelentkező Ha viszont egy friss verzióval rendelkezünk,
akkor elképzelhető, hogy egy másik
hibával kerültünk szembe. A
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
Néhány ritka esetben még
előfordulhat, hogy az | |
7.6. | A CVSup miért nincs a FreeBSD forrásai között? |
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 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). | |
7.7. | A forrásokon kívül a telepített portokat is lehet valahogy frissíteni? |
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. | |
7.8. | Minden nagyobb verziófrissítésnél újra kell fordítani az összes telepített portot a rendszeren? |
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. | |
7.9. | Minden kisebb verziófrissítésnél újra kell fordítani az összes telepített portot a rendszeren? |
Á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. | |
7.10. | A |
Mert a POSIX(R) 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(R) 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 | |
7.11. | A Netscape(R) és az Opera indítása miért tart olyan sokáig? |
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(R) é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. | |
7.12. | Ha a CVSup használatával frissítjük a Portgyűjteményt, akkor sok port nem fordul le mindenféle rejtélyes hibaüzenet kíséretében! Valami nagy baj van a Portgyűjteménnyel? |
Ha úgy korábban úgy
frissítettük a CVSup
használatával a Portgyűjteményt,
hogy nem adtuk meg a | |
7.13. | Hogyan lehet MIDI állományokból audio CD-t készíteni? |
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
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. |
8.1. | Nehéz testreszabni a rendszermagot? |
Egyáltalán nem! Ezzel kapcsolatban olvassuk el a FreeBSD kézikönyv rendszermag beállításairól szóló részét. Megjegyzés:Az új | |
8.2. | A rendszermag nem fordul le, mert a
|
Ez valószínűleg azért
következett be, mert eltávolítottuk az
| |
8.3. | Miért ilyen nagy a rendszermag mérete (közel 10 MB)? |
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:
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. | |
8.4. | Miért ütköznek a megszakítások, amikor többportos soros vonali kártyákat akarunk használni? |
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 | |
8.5. | Miért nem lehet lefordítani a
rendszermagot, még a |
Ennek több oka is lehet. Ezek közül néhány, de nem feltétlenül ebben a sorrendben:
| |
8.6. | Honnan tudhatjuk meg milyen ütemezővel dolgozik a rendszerünk? |
Nézzük meg, hogy a rendszerünkben
elérhető-e a
Ha létezik a
Az aktuálisan használt ütemező
neve közvetlenül elérhető a
| |
8.7. | Mi az a |
A |
9.1. | Hogyan adjunk lemezeket a FreeBSD rendszerünkhöz? |
Ezzel kapcsolatban olvassuk el a lemezek hozzáadásáról szóló részt a FreeBSD kézikönyvben. | |
9.2. | Hogyan lehet átteni a rendszert egy nagyobb lemezre? |
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 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
Például, ha a
További munkát igényel, ha a
Egy könyvtárat, például
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! | |
9.3. | A "Veszélyesen dedikált" ("Dangerously Dedicated") lemezek veszélyesek a felhasználóra? |
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 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:
A másik módszer egy hivatalosan nem dokumentált DOS-os "lehetőség" használata:
Ezzel egy új Master Boot Recordot tudunk telepíteni, ami ezzel együtt felülírja a BSD rendszertöltőjét is. | |
9.4. | Milyen partíciókon lehet Soft Updatest használni? A Soft Updates állítólag nem működik rendesen a gyökérpartíció esetén. |
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
A gyökérpartíció
hagyományosan az egyik legkisebb
partíció. Ha viszont az ideiglenes
állományok tárolására
szánt | |
9.5. | Mi történt a ccd(4) eszközzel? |
A hibajelenség:
Ez általában olyankor
történik, amikor olyan | |
9.6. | Miért nem lehet a ccd(4) eszköz lemezcímkéjét szerkeszteni? |
A hibajelenség:
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:
| |
9.7. | Lehet más operációs rendszerek állományrendszerét is csatlakoztatni FreeBSD alatt? |
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. | |
9.8. | Hogyan lehet másodlagos (logikai) DOS partíciókat csatlakoztatni? |
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
| |
9.9. | Használható titkosított állományrendszer FreeBSD alatt? |
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. | |
9.10. | A Windows NT(R) rendszertöltőjével is el lehet indítani a FreeBSD-t? |
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(R) partíción belül. Legyen
ez például a
[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(R) is indul, akkor egyszerűen csak
másoljuk át a A Figyelem:Ne másoljunk át csak
úgy egyszerűen a
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
| |
9.11. | A LILO-ból hogyan lehet FreeBSD-t és Linuxot is indítani? |
Ha a FreeBSD és a Linux(R) 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(R) 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
other=/dev/hda2 table=/dev/hda label=FreeBSD (A fentiekben feltételeztük, hogy a FreeBSD-t
tartalmazó slice a Linux(R) számára
Ha a FreeBSD egy másik lemezen
található, akkor a
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: 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(R) együttes használatáról további részleteket a Linux(R)+FreeBSD mini-HOWTO című írásból tudhatunk meg. | |
9.12. | Hogyan lehet a GRUB használatával FreeBSD-t és Linuxot is indítani? |
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
( title FreeBSD 6.1
root Itt a | |
9.13. | Hogyan lehet a BootEasy használatával elindítani a FreeBSD-t és a Linuxot? |
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(R) és Linux(R) 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(R)-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). | |
9.14. | A rendszerindításkor látható
|
Ez az szabványos boot managerrel csak úgy
lehet megoldani, ha újratelepítjük. A
portok között viszont a | |
9.15. | Cserélhető lemezes meghajtókat hogyan lehet használni? |
Legyen az akár egy Zip(R), 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:
vagy így, ha egy gyári beállításokkal rendelkező ZIP-lemez:
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
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:
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:
Csatlakoztassuk:
Emellett még hasznos lehet felvenni hozzá
egy sort az /dev/da2c /zip ffs rw,noauto 0 0 | |
9.16. | Miért ad a rendszer Incorrect super block hibát CD-k csatlakoztatásánál? |
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. | |
9.17. | Miért ad a rendszer Device not configured hibaüzenetet CD-k csatlakoztatásakor? |
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. | |
9.18. | Miért jelenik meg az összes nemzeti karakter helyén "?", amikor FreeBSD alatt csatlakoztatunk egy CD-t? |
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. | |
9.19. | A FreeBSD alatt készített CD-ket nem lehet más operációs rendszerekkel olvasni. Miért nem? |
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. | |
9.20. | Hogyan lehet lementeni egy adat CD tartalmát a merevlemezre? |
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. | |
9.21. | Miért nem lehet audio CD-ket csatlakoztatni a
|
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
| |
9.22. | Hogyan lehet többmenetes (multisession) CD-ket
csatlakoztatni a |
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
| |
9.23. | Hogyan képesek az egyszerű felhasználók floppykat, CD-ket és más egyéb cserélhető lemezes eszközöket használni? |
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
A
Az eszközök leválasztása is hasonlóan egyszerű:
A Megjegyzés:A példákban használt eszközneveket természetesen a konfigurációnknak megfelelően meg kell változtatnunk. | |
9.24. | A |
A válaszhoz meg kell értenünk a
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 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 | |
9.25. | Hogyan lehet növelni a lapozóterületet? |
A kézikönyv Beállítás és finomhangolás című fejezetében található egyik szakaszban olvashatunk erről. | |
9.26. | A FreeBSD miért látja kisebbnek a lemezeket mint amekkorának a gyártó mondja ezeket? |
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. | |
9.27. | Hogyan lehet egy partíció 100 százaléknál is jobban megtelt? |
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 A részleteket a tunefs(8) man oldalon
belül a |
10.1. | Hol vannak a rendszerindítás beállításáért felelős állományok? | ||||||||
Az ezzel kapcsolatos beállítások
elsősorban az
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:
Ha helyi szolgáltatásokat akarunk
futtatni, akkor tegyük a hozzá tartozó
szkripteket az | |||||||||
10.2. | Hogyan lehet felhasználókat egyszerűen létrehozni? | ||||||||
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. | |||||||||
10.3. | A | ||||||||
Ilyen általában olyankor
történik, amikor a rendszerszintű
Ezt nem így kell megoldani. A
rendszerszintű Ha így csináltuk, akkor a
Legközelebb, amikor az
Ha valamit napi, heti vagy havi rendszerességgel
akarunk futtatni, akkor ehelyett inkább másoljuk
be az Ez a hiba egyébként onnan jön, hogy
rendszerszintű | |||||||||
10.4. | Miért jelenik meg a you are not in the
correct group to su root hibaüzenet, amikor a
| ||||||||
Ez egy biztonsági megszorítás.
Csak úgy tudunk átváltani a
Ha engedélyezni akarjuk valakinek a
| |||||||||
10.5. | Az | ||||||||
Indítsuk újra a rendszert és a
rendszertöltő parancssorában adjuk ki a
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 Miután megtettük ezeket a
lépéseket, már a szokásos
módon át tudjuk szerkeszteni az
| |||||||||
10.6. | Miért nem sikerül beállítani a nyomtatót? | ||||||||
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(R) 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. | |||||||||
10.7. | Hogyan lehet módosítani a rendszerünkhöz tartozó billentyűkiosztást? | ||||||||
Olvassuk el a kézikönyv honosításssal foglalkozó részét, különös tekintettel a konzol beállításaira. | |||||||||
10.8. | Miért jelenik meg az unknown: <PNP0303> can't assign resources hibaüzenet a rendszer indulásakor? | ||||||||
Erre a FreeBSD-CURRENT levelezési lista címére postázott egyik levél adja meg a választ:
| |||||||||
10.9. | Miért nem működnek rendesen a kvóták? | ||||||||
| |||||||||
10.10. | A FreeBSD tartalmazza a System V IPC alapeszközeit? | ||||||||
Igen, a FreeBSD a 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. | |||||||||
10.11. | A sendmail helyett milyen más levelező szerver használható még? | ||||||||
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. | |||||||||
10.12. | Elveszett a | ||||||||
Ne essünk kétségbe! Indítsuk
újra a rendszerünket
egyfelhasználós módban. Ehhez
gépeljük be a Megjegyzés:Ha az egyfelhasználós módra
váltás során a rendszer a
Megjegyzés:Ha egyfelhasználós módban nem tudjuk csatlakoztatni a rendszerindító partíciót, akkor ennek könnyen az lehet az oka, hogy a partíciókat titkosították, ezért a megfelelő kulcsok nélkül nem tudjuk elérni ezeket. Ez leginkább adott implementációtól függ. A FreeBSD-ben előforduló lemeztitkosításokkal kapcsolatban a kézikönyv ad bővebb útmutatást. | |||||||||
10.13. | Hogyan akadályozható meg, hogy a Control+Alt+Delete billentyűkombináció újraindítsa a rendszert? | ||||||||
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:
Megjegyzés:Az előbb említett két
módszer kizárja egymást. A
sysctl(8) változó nem létezik,
ha a rendszermagot a 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 | |||||||||
10.14. | Hogyan lehet szöveges DOS állományokat UNIX(R) formátumúra alakítani? | ||||||||
Használjuk a következő perl(1) parancsot:
ahol az
Erre a célra viszont ugyanígy megfelel a tr(1) parancs is:
Ekkor a
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. | |||||||||
10.15. | Hogyan lehet futó programokat név szerint leállítani? | ||||||||
Lásd killall(1). | |||||||||
10.16. | A su(1) miért írja folyton, hogy a
felhasználó nincs a | ||||||||
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
| |||||||||
10.17. | Hogyan távolítható el a Kerberos? | ||||||||
A Kerberos úgy
távolítható el a rendszerből, ha
újratelepítjük a
Másik lehetőség, ha hozzáadjuk
a | |||||||||
10.18. | Mi történt a
| ||||||||
A FreeBSD 5. | |||||||||
10.19. | Hogyan lehet még több pszeudoterminált létrehozni? | ||||||||
Ha sok Tipp:Szükség esetén további
pszeudoterminálok is hozzáadhatóak a
rendszerhez. Ehhez azonban módosítanunk
kell a szabványos C
függvénykönyvtárakat, a
rendszermagot és az | |||||||||
10.20. | Hogyan lehet újraindítás
nélkül az | ||||||||
Váltsunk egyfelhasználós módba, majd vissza többfelhasználós módba. Konzolon ez így oldható meg:
| |||||||||
10.21. | A -STABLE rendszer
frissítésekor
-BETA | ||||||||
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). | |||||||||
10.22. | Az új rendszermag telepítése során a chflags(1) program hibát jelez. Hogyan javítható ez a hiba? | ||||||||
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:
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 | |||||||||
10.23. | A rendszeren nem lehet egyszerre egy másodpercnél többel megváltoztatni az időt! Hogyan lehet megkerülni ezt a korlátozást? | ||||||||
A rövid válasz: A rendszerünkben a
biztonsági szintet ( 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:
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 | |||||||||
10.24. | Az | ||||||||
Nem, itt szó sincs semmiféle
memóriaszivárgásról, és
egyébként sem használ 256 MB
memóriát. Az A rpc.statd(8) tehát leképezi az
állapotát rögzítő
állományt (amely a | |||||||||
10.25. | Miért nem törölhető az
| ||||||||
Rendszerünkben a biztonsági szint
( | |||||||||
10.26. | Az | ||||||||
A legújabb FreeBSD verziókban azért
nem tudjuk az
| |||||||||
10.27. | Mi az a | ||||||||
A | |||||||||
10.28. | Mit jelentenek | ||||||||
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. | |||||||||
10.29. | Mekkora a rendelkezésre álló memória mérete? | ||||||||
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. | |||||||||
10.30. | Mi az a | ||||||||
A Noha semmiképpen sem javasoljuk a
könyvtár törlését, úgy
tudjuk elvégezni, ha először az
|
11.1. | Mi az X Window System? |
Az X Window System (vagy gyakran csak
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. | |
11.2. | FreeBSD alatt milyen X implementációk használhatóak? |
Kezdetben a FreeBSD alapértelmezett X implementációja az XFree86TM 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ó XFree86TM 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 2004 júliusától kezdődően a FreeBSD-CURRENT változatban az XFree86TM 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. | |
11.3. | Mégis miért vált szét a két X projekt? |
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. | |
11.4. | A FreeBSD miért az Xorg változatát választotta alapértelmezettnek? |
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 XFree86TM licence ettől némileg eltér. | |
11.5. | Hogyan lehet használni az X-et? |
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:
Emellett az Xorg a sysinstall(8) használatával is telepíthető: válasszuk a (Beállítások), (Terjesztések), végül a (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. | |
11.6. | Az X indításakor egy KDENABIO
failed (Operation not permitted) hiba
keletkezik, közvetlenül a
|
A rendszerünkön
valószínűleg túlságosan
magas a biztonsági szint
( 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
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. | |
11.7. | Miért nem működik X alatt az egér? |
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
Ezt követően nyissuk meg az
Section "InputDevice" Option "Protocol" "SysMouse" Option "Device" "/dev/sysmouse" ..... Az Xorg 7.4 változatától
kezdődően az Option "AutoAddDevices" "false" Néhányan inkább a
link sysmouse mouse A link maga közvetlenül a devfs(5)
újraindításával keletkezik. Ehhez
(
| |
11.8. | X alatt lehet használni görgős egeret? |
Igen. Jelezni kell az X-nek, hogy ötgombos egerünk
van. Ezt úgy tudjuk megcsinálni, ha az
11.1. példa - Egy példa Xorg konfigurációs
állomány "InputDevice" szakasza
görgős egerekhez Section "InputDevice" Identifier "Mouse1" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/sysmouse" Option "Buttons" "5" Option "ZAxisMapping" "4 5" EndSection 11.2. példa - Egy egyszerű példa ".emacs"
állomány görgős egerek
(opcionális) használatához ;; görgős egér (global-set-key [mouse-4] 'scroll-down) (global-set-key [mouse-5] 'scroll-up) | |
11.9. | Hogyan lehet távoli X szervereket elérni? |
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
| |
11.10. | Mi az a virtuális konzol és hogyan lehet belőle többet létrehozni? |
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
# Í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
Fontos:Ha X szervert is akarunk futtatni, akkor legalább egy virtuális konzolt szabadon (vagy kikapcsolva) kell hagynunk a számára. Így tehát, ha mind a tizenkét funkcióbillentyűre szeretnénk elindítani egy-egy virtuális konzolt, nos, akkor nincs szerencsénk - ha X szervert is akarunk használni a gépen, akkor legfeljebb csak tizenegyet használhatunk belőlük. 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
(
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
| |
11.11. | Hogyan lehet elérni a virtuális konzolokat X-ből? |
A virtuális konzolokra a
Ctrl+Alt+F Ahogy visszajutottunk a szöveges konzolra, az
Alt+F 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 | |
11.12. | Hogyan indítható el az XDM a rendszer indításakor? |
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
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
Ha az rc(8) állományból
töltöttük be, akkor az Amennyiben az :0 local /usr/local/bin/X vt4 A fenti példában az X szervert a
| |
11.13. | Az |
Ha az X-et a 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
/dev/ttyv0 0600 /dev/console Ennek köszönhetően bárki, aki az
| |
11.14. | Régebben egyszerű
felhasználóként is el lehetett
indítani az XFree86TM szervert. Most miért
kell |
Az X szerverek csak úgy képesek
közvetlenül elérni a
videokártyát, ha Értelemszerűen az a megoldás nem
fogadható el és nem is annyira
biztonságos, hogy az X szervert
Az Az | |
11.15. | Miért viselkednek furcsán a PS/2-es egerek X alatt? |
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
boot: Ezután a UserConfig parancssorában gépeljük be a következőt: UserConfig> | |
11.16. | Miért nem működnek a MouseSystems által gyártott PS/2-es egerek? |
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 boot: Ahogy bejön a UserConfig parancssora, gépeljük be a következőt: UserConfig> Az előző részben olvashatunk egy másik hasonló egeres problémáról. | |
11.17. | Hogyan lehet megcserélni a gombokat az egéren? |
Futtassuk le a | |
11.18. | Hogyan lehet betöltőképet telepíteni és hol találhatóak ilyen képek? |
Erre a kérdésre részletes választ a FreeBSD kézikönyv Rendszerbetöltő képernyők című szakaszában kapunk. | |
11.19. | X alatt lehet használni a billentyűzeten található Windows billentyűket? |
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:
Például így lehet beállítani a bal oldali Windows billentyűt vesszőre:
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 $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
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
Key F13 FTIWS A Iconify Key F14 FTIWS A RaiseLower Key F15 A A Menu Workplace Nop | |
11.20. | Hogyan lehet hardveres 3D gyorsítást használni az OpenGL(R)-hez? |
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:
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: 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. |
12.1. | Honnan lehet többet megtudni a "lemez nélküli működésről"? | ||||||||||||||||||||||||||||||||||
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. | |||||||||||||||||||||||||||||||||||
12.2. | A FreeBSD használható kizárólag csak hálózati útválasztóként? | ||||||||||||||||||||||||||||||||||
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. | |||||||||||||||||||||||||||||||||||
12.3. | FreeBSD-n keresztül lehet Windows(R) operációs rendszerrel internetre csatlakozni? | ||||||||||||||||||||||||||||||||||
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(R) 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 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. | |||||||||||||||||||||||||||||||||||
12.4. | A FreeBSD támogatja a SLIP és a PPP használatát? | ||||||||||||||||||||||||||||||||||
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. | |||||||||||||||||||||||||||||||||||
12.5. | A FreeBSD támogat hálózati címfordítást (NAT) vagy maszkolást? | ||||||||||||||||||||||||||||||||||
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. | |||||||||||||||||||||||||||||||||||
12.6. | A PLIP segítségével hogyan tudok két FreeBSD rendszert összekapcsolni párhuzamos porton keresztül? | ||||||||||||||||||||||||||||||||||
Ezt illetően a kézikönyv PLIP-ről szóló szakaszát érdemes megnéznünk. | |||||||||||||||||||||||||||||||||||
12.7. | Hogyan lehet álneveket megadni az Ethernet eszközöknek? | ||||||||||||||||||||||||||||||||||
Amennyiben az álnév ugyanazon az
alhálózaton található, mint a
hozzá tartozó interfész, akkor
egyszerűen csak adjuk meg a
Minden más esetben a hagyományos módon adjunk meg egy hálózati címet és egy hálózati maszkot:
Erről bővebben a FreeBSD kézikönyvben olvashatunk. | |||||||||||||||||||||||||||||||||||
12.8. | A 3C503 kártya hogyan állítható másik hálózati portra? | ||||||||||||||||||||||||||||||||||
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 | |||||||||||||||||||||||||||||||||||
12.9. | Miért okoz gondot az NFS használata FreeBSD alatt? | ||||||||||||||||||||||||||||||||||
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. | |||||||||||||||||||||||||||||||||||
12.10. | Miért nem lehet hálózati állományrendszereket csatlakoztatni Linux(R) alól? | ||||||||||||||||||||||||||||||||||
A Linux(R) 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:
| |||||||||||||||||||||||||||||||||||
12.11. | Miért nem lehet hálózati állományrendszereket csatlakoztatni SunTM típusú rendszerek alól? | ||||||||||||||||||||||||||||||||||
A SunOSTM 4.
| |||||||||||||||||||||||||||||||||||
12.12. | A | ||||||||||||||||||||||||||||||||||
Ez leginkább azért történik,
mert nem jól adtuk meg az
| |||||||||||||||||||||||||||||||||||
12.13. | A NeXTStep gépekkel miért nem sikerül PPP-n keresztül kommunikálni? | ||||||||||||||||||||||||||||||||||
Próbáljuk meg az
tcp_extensions=NO A Xylogic által gyártott Annex típusú gépek esetén is javasolt megtenni a fenti változtatást. | |||||||||||||||||||||||||||||||||||
12.14. | Hogyan lehet engedélyezni a multicast használatát az IP-n belül? | ||||||||||||||||||||||||||||||||||
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
Megjegyzés:A FreeBSD újabb változataiban az mrouted(8) multicast útválasztó démon, a map-mbone(8) valamint az mrinfo(8) segédprogramok már nem szerepelnek az alaprendszerben. Ezek a programok már a FreeBSD Portgyűjteményében az net/mrouted portban találhatóak meg. 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 | |||||||||||||||||||||||||||||||||||
12.15. | Milyen hálózati kártyák épülnek a DEC PCI chipkészletére? | ||||||||||||||||||||||||||||||||||
Glen Foster ( 12.1. táblázat - A DEC PCI chipkészletére
épülő hálózati
kártyák
| |||||||||||||||||||||||||||||||||||
12.16. | Miért kell teljes hálózati neveket megadni? | ||||||||||||||||||||||||||||||||||
Erre a FreeBSD kézikönyvben találjuk meg a választ. | |||||||||||||||||||||||||||||||||||
12.17. | Miért jelenik meg a Permission denied hibaüzenet minden egyes hálózati művelet esetén? | ||||||||||||||||||||||||||||||||||
Amennyiben a rendszermagot az
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
Az 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. | |||||||||||||||||||||||||||||||||||
12.18. | Az | ||||||||||||||||||||||||||||||||||
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 Amikor egy csomag az 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. | |||||||||||||||||||||||||||||||||||
12.19. | Hogyan lehet egyik gépről a másikra szolgáltatásokat átirányítani? | ||||||||||||||||||||||||||||||||||
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 ftp stream tcp nowait nobody /usr/local/bin/socket socket ahol az | |||||||||||||||||||||||||||||||||||
12.20. | Hogyan lehet a sávszélességet szabályozni? | ||||||||||||||||||||||||||||||||||
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. | |||||||||||||||||||||||||||||||||||
12.21. | Miért jelenik meg a /dev/bpf0: device not configured hibaüzenet? | ||||||||||||||||||||||||||||||||||
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 | |||||||||||||||||||||||||||||||||||
12.22. | Hogyan lehet a hálózaton elérhető Windows(R) típusú partíciókat csatlakoztatni, mint ahogy az smbmount csinálja Linux(R) alatt? | ||||||||||||||||||||||||||||||||||
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. | |||||||||||||||||||||||||||||||||||
12.23. | Mik azok az Limiting icmp/open port/closed port response üzenetek a naplókban? | ||||||||||||||||||||||||||||||||||
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:
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
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
Végezetül, ha teljesen ki akarjuk kapcsolni
a válaszküldés
korlátozását, akkor
állítsuk a
| |||||||||||||||||||||||||||||||||||
12.24. | Mik azok az arp: unknown hardware address format hibaüzenetek? | ||||||||||||||||||||||||||||||||||
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. | |||||||||||||||||||||||||||||||||||
12.25. | Miért jelennek meg 192.168.0.10 is on fxp1 but got reply from 00:15:17:67:cf:82 on rl0 üzenetek a konzolon és hogyan lehet ezeket kikapcsolni? | ||||||||||||||||||||||||||||||||||
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
| |||||||||||||||||||||||||||||||||||
12.26. | A CVSup programot telepítése után nem lehet elindítani, mert hibákat jelez. Mi a gond? | ||||||||||||||||||||||||||||||||||
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. |
13.1. | Mi az a "járóka" (sandbox)? |
A járóka alapvetően egy biztonsági szakkifejezés. Két dolgot jelenthet:
A UNIX(R) 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(R) program teljesen elszigetelt minden más UNIX(R) programtól, így az egyik nem képes módosítani a másik memóriában tárolt adatait. A Windows(R)-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(R) alatt futó programok mindig egy adott
felhasználóhoz tartoznak. Ha ez nem a
| |
13.2. | Mi az a biztonsági szint (securelevel)? |
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
A jelenleg futó rendszer biztonsági szintjét a következő parancs segítségével lehet lekérdezni:
A parancs eredménye az adott sysctl(8)
változó (vagyis esetünkben a
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
A biztonsági szintekkel és rájuk vonatkozó információkkal kapcsolatban olvassuk el az init(8) man oldalt. Figyelem:A biztonsági szintek nem feltétlenül jelentenek minden problémára tökéletes megoldást. Rentegeg ismert hátulütővel rendelkeznek, és gyakran a biztonság hamis érzetét keltik. Ezzel kapcsolatban az egyik legnagyobb gond, hogy csak abban az esetben működik rendesen a rendszer, ha a rendszerindítás során a biztonsági szintek beállításáig minden állományt levédünk. Ha a támadó képes lefuttatni a saját programját még a biztonsági szint beállítása előtt (amely viszont elég későn történik meg, hiszen a rendszerindítás során számos olyan dolog feladat van, amely nem végezhető el magasabb biztonsági szinteken), akkor azzal az egész védelmi módszer hatástalanítható. Habár a rendszerindítás folyamán felhasznált állományok biztonságba helyezése technikailag egyáltalán nem lehetetlen, nehezebbé válik tőle a rendszer karbantartása, mivel ilyenkor az egész rendszert át kell állítanunk legalább egyfelhasználós módba és úgy módosítani a konfigurációs állományokat. Ezt és az ehhez hasonló problémák gyakran felmerülnek a levelezési listákon, különösen a FreeBSD security levelezési lista archívumaiban. Ezen a funkción keresztül nézhetünk után a téma részletesebb tárgyalásának. Néhányan reménykednek, hogy a biztonsági szinteket hamarosan leváltja valami sokkal finomabb beállítási lehetőségekkel rendelkező megoldás, azonban a dolgok még eléggé homályosak ebből a szempontból. Figyelmeztettünk mindenkit! | |
13.3. | A BIND ( |
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
Figyelem:Ha ezt a portot (mint például az 53) az
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. | |
13.4. | A sendmail a szabványos 25-ös port mellett az 587-es portot használja! Miért? |
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. | |
13.5. | Kié az a nullás felhasználói
azonosítójú |
Ne aggódjunk! A Egyesek nem szabványos
parancsértelmezőn keresztül a
| |
13.6. | A |
Biztonsági okokból a
|
14.1. | Nem működik a ppp(8). Mit lehet a gond? |
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 !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. | |
14.2. | A ppp(8) miért bontja a vonalat, amikor elindul? |
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
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
| |
14.3. | A ppp(8) miért nem tárcsáz
|
Először is ellenőrizzük, hogy
létezik az alapértelmezett útvonal. A
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
Az alapértelmezett útvonal
hiányának másik oka lehet még, ha
az 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. | |
14.4. | Mit jelent a No route to host hibaüzenet? |
Általában azért jelentkezik, mert
az 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. | |
14.5. | Miért szakad meg a kapcsolat 3 perc után? |
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 ahol az | |
14.6. | A kapcsolat miért szakad meg nagyobb terhelést alatt? |
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 | |
14.7. | A kapcsolat miért szakad meg véletlenszerűen? |
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(R) Sportster(R)
esetén ezt tizedmásodpercekben mérik az
set dial "...... ATS10=10 OK ......" További részleteket a modem kézikönyvéből tudhatunk meg. | |
14.8. | A kapcsolat miért fullad le véletlenszerűen? |
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
Miután sikeresen kiderítettük, hogy az adott probléma helyi vagy távoli, két lehetőségünk van: | |
14.9. | A vonal túlsó végéről nem érkezik válasz. Mi lehet tenni? |
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(R)
operációs rendszert használjuk. A
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(R) 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 címére vagy kérjük meg a szolgáltatónkat, hogy közvetlenül vele tárgyaljon. | |
14.10. | A ppp(8) teljesen megállt. Mi lehet tenni? |
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:
Ezt követően a gdb
parancssorában a Végezetül az elmentett eredményeket küldjük el Brian Somers címére. | |
14.11. | Miért nem történik semmi a "Login OK!" üzenet után? |
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 Megjegyzés:Általában semmilyen gond nem
származik abból, ha a mind a két
oldal kezdeményez, így az
| |
14.12. | Folyamatosan Magic is same hibák jelennek meg. Ez mire utal? |
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
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. | |
14.13. | Az LCP beállítása egészen a kapcsolat befejeződéséig folytatódik. Mi lehet a probléma? |
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 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 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 Használhatjuk viszont ezt a parancsot is (ahol
set openmode active Az ezzel kapcsolatos további részleteket a man oldalon olvashatjuk. | |
14.14. | Miért akad meg a ppp(8), ha egy külső parancsot adunk ki alatta? |
A Ha nem akarjuk megvárni a parancs
befejeződését, akkor inkább
használjuk a | |
14.15. | A ppp(8) null-modem kábel használatakor miért nem lép ki soha? |
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. | |
14.16. | A ppp(8) miért tárcsáz
látszólag minden különösebb ok
nélkül |
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
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
| |
14.17. | Mit jelentenek a CCP hibák? |
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
disable pred1 | |
14.18. | A ppp(8) miért nem naplózza a kapcsolat sebességét? |
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 set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 4 \ \"\" ATZ OK-ATZ-OK ATDT\\T TIMEOUT 60 CONNECT \\c \\n" Itt most megkapjuk a | |
14.19. | A ppp(8) miért hagyja figyelmen
kívül a |
A ppp a
konfigurációs állományokból
minden sort külön beolvas, ezért a
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 Ha tehát egy 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 | |
14.20. | A ppp(8) miért küld
Segmentation Fault hibát,
miközben nem is keletkezik
|
A ppp (vagy más
hasonló program) elméletileg soha nem hoz
létre
A fenti parancsokkal telepíteni tudjuk a
ppp(8) egy nyomonkövethető
változatát. A ppp(8)
futtatásához Innentől kezdve, amikor a ppp(8) kap egy
szegmentációs hibára vonatkozó
jelzést, létre fog hozni egy
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
| |
14.21. | Miért nem csatlakozik soha az a program, amely a
hívást kezdeményezte
|
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 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ó 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
| |
14.22. | A legtöbb játék miért nem
működik a |
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 ( 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
nat port ahol a 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:
| |
14.23. | Valaki összeírta már a hasznosabb portok sorszámait? |
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
| |
14.24. | Mik azok az FCS hibák? |
Az FCS jelentése 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
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 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. | |
14.25. | A Mac OS(R) és Windows(R) 98 alól indított kapcsolatok miért állnak le, ha PPPoE fut az átjárón? |
A probléma megoldását Michael
Wozniak ( Ennek oka az ún. útválasztási "fekete lyuk". A Mac OS(R) és a Windows(R) 98 (de valószínűleg az összes többi Microsoft(R) 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(R) 95/98 rendszerekben megtalálható
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\NetTrans\0000\MaxMTU A karakterlánc értéke legyen
A Windows(R) 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(R) . Windows(R) 2000 alatt a regisztrációs
adatbázisban érdemes még a
Sajnos a Mac OS(R) 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 A ppp(8) újabb (2.3 vagy afeletti)
változatai már tartalmaznak egy
| |
14.26. | Ezek közül egyik sem használt - segítség! Mit lehetne még tenni? |
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 |
Ebben a szakaszban a FreeBSD alatti soros vonali kommunikációval kapcsolatos kérdéseket tárgyaljuk. A PPP és SLIP használatáról a Hálózatok című részben esik szó.
15.1. | Honnan deríthető ki, hogy a FreeBSD felismerte a soros portokat a gépben? |
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:
Í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
A | |
15.2. | Honnan deríthető ki, hogy a FreeBSD felismerte a modemkártyát a gépben? |
Olvassuk el az előző kérdésre adott választ. | |
15.3. | Hogyan lehet a soros portokat elérni FreeBSD alatt? |
A harmadik soros port, a A
| |
15.4. | Hogyan lehet engedélyezi a többportos soros vonali kártyák támogatását? |
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 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 | |
15.5. | A FreeBSD képes több többportos soros vonali kártyát ugyanazon a megszakításon keresztül használni? |
Sajnos még nem. Minden kártyához másik megszakítást kell megadni. | |
15.6. | Hogyan lehet beállítani a portok alapértelmezett paramétereit? |
Ezzel kapcsolatban olvassuk el a FreeBSD kézikönyv soros kommunikációt tárgyaló részét. | |
15.7. | Hogyan lehet a modemen betárcsázást beállítani? |
Erre vonatkozóan olvassuk el a FreeBSD kézikönyv betárcsázós szolgáltatásokkal kapcsolatos részét. | |
15.8. | Hogyan lehet "buta" terminálokat FreeBSD-re csatlakoztatni? |
Az ezzel kapcsolatos információkat a FreeBSD kézikönyv terminálokról szóló részében találhatjuk meg. | |
15.9. | Miért nem indul el a |
Előfordulhat, hogy rendszerünkön a
tip(1) és cu(1) programok csak az
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:
| |
15.10. | A rendszerhez csatlakozó Hayes szabványú modem támogatott - mi ilyenkor teendő? |
A FreeBSD kézikönyvben lásd ezt a választ. | |
15.11. | Hogyan adjuk meg az AT parancsokat? |
A FreeBSD kézikönyvben lásd ezt a választ. | |
15.12. | A |
A FreeBSD kézikönyvben lásd ezt a választ. | |
15.13. | Hogyan lehet telefonszámokat tárcsázni parancssorból? |
A FreeBSD kézikönyvben lásd ezt a választ. | |
15.14. | Minden alkalommal meg kell adni az adatátviteli sebességet? |
A FreeBSD kézikönyvben lásd ezt a választ. | |
15.15. | Terminálszerver segítségével hogyan lehet könnyen elérni egyszerre több gépet is? |
A FreeBSD kézikönyvben lásd ezt a választ. | |
15.16. | A tip(1) képes több vonalat is használni az egyes gépek eléréséhez? |
A FreeBSD kézikönyvben lásd ezt a választ. | |
15.17. | Miért kell kétszer lenyomni a Ctrl+P billentyűket, hogy egyszer elküldjük ezeket? |
A FreeBSD kézikönyvben lásd ezt a választ. | |
15.18. | Miért lett hirtelen minden NAGYBETűS? |
A FreeBSD kézikönyvben lásd ezt a választ. | |
15.19. | Hogyan lehet állományokat mozgatni a
|
A FreeBSD kézikönyvben lásd ezt a választ. | |
15.20. | Hogyan használható a zmodem protokoll a
|
A FreeBSD kézikönyvben lásd ezt a választ. |
16.1. | A FreeBSD miért használ sokkal több lapozóállományt, mint a Linux(R)? | ||||||
A FreeBSD csupán látszólag használ több helyet a lapozásra, mint a Linux(R), valójában egyébként nem. A FreeBSD és a Linux(R) közt az egyik leglényegesebb különbség, hogy a FreeBSD valamivel előre gondolkodik, és az összes pillanatnyilag nem használt lapot kilapozza a központi memóriából a lapozóterületre. Ezzel igyekszik minél több memóriát előkészíteni az aktív használatra. A Linux(R) ezzel szemben a lapozást csak végső esetben használja. Ennek megfelelően a lapozóterület gyakoribb használatát remekül ellensúlyozza a fizikai memória hatékonyabb kihasználása. Habár a FreeBSD igyekszik ebben a tekintetben előrelátó lenni, nem minden esetben tudja pontosan eldönteni, hogy a rendszerben mely lapokat nem használják éppen. Emiatt nem fogja az összes memóriát kilapozni, ha például egész éjszakára futni hagyjuk a gépünket. | |||||||
16.2. | A | ||||||
Röviden úgy válaszolhatnánk
meg ezt a kérdést, hogy a szabad memória
igazából elvesztegetett memória. A
programok által szabadon hagyott
memóriát a FreeBSD rendszermagja többnyire a
lemez gyorsítótárazására
használja fel. A top(1) kimenetében
olvasható | |||||||
16.3. | A | ||||||
A szimbolikus linkekhez alapértelmezés
szerint nem tartoznak engedélyek, ezért a
chmod(1) ilyen esetekben az eredeti
állomány engedélyeit változtatja
meg. Ezért például, ha adott egy
Ennek ellenére az Ha egy adott könyvtárszerkezetben
elhelyezkedő állományok engedélyeit
akarjuk egyszerre módosítani, akkor a
Figyelem:A chmod(1)
A név végén szereplő
perjelből a chmod(1) tudni fogja, hogy
követnie kell a | |||||||
16.4. | A FreeBSD képes DOS programokat futtatni? | ||||||
Igen, a Portgyűjteményben található emulators/doscmd, vagyis egy DOS emulációs program segítségével. Amennyiben a doscmd önmagában még nem lenne elegendő, egy másik segédprogram, a emulators/pcemu segítségével emulálni tudunk egy 8088-as processzort, valamint a BIOS annyi részét, hogy futtatni tudjunk szöveges DOS alkalmazásokat. A használatához az X Window Systemre is szükségünk lesz. Érdemes ezenkívül még megpróbálnunk a FreeBSD Portgyűjteményében található emulators/dosbox portot is. Ez az alkalmazás elsősorban a régi DOS-os játékok futtatásához szükséges környezet emulációjára koncentrál, a helyi állományrendszerben található állományok felhasználásával. | |||||||
16.5. | Hogyan tudjuk az anyanyelvünkre lefordítani a FreeBSD dokumentációját? | ||||||
Olvassuk el a FreeBSD Dokumentációs Projekt bevezetőjében található Fordítói GYIK-ot. | |||||||
16.6. | A | ||||||
A
| |||||||
16.7. | Hogyan lehet egyszerűen FreeBSD rendszereket elérni? | ||||||
Habár a FreeBSD maga nem nyújt akárki számára hozzáférést a saját szervereihez, mások viszont kínálnak bárki által elérhető UNIX(R) rendszereket. Ennek költsége és minősége szolgáltatónként változik. Az Arbornet, Inc, vagy másik nevén M-Net 1983 óta szolgáltat nyílt hozzáférést UNIX(R) típusú rendszerekhez. Egy System III alapokon működő Altos rendszerről a 1991-ben BSD/OS-re váltottak, majd 2000 júliusában aztán FreeBSD-re váltottak. Az M-Net telnet és SSH szolgáltatásokon keresztül is elérhető, és lényegében a FreeBSD alatt elérhető összes programhoz enged egy alapvető hozzáférést. A hálózati hozzáférés azonban csak a tagok és a támogatók számára engedélyezett. Ez egy non-profit szervezet. Az M-Net rendelkezik üzenőfallal (bulletin board system, BBS) és interaktív csevegőrendszerrel is. A Grex az M-Net szolgáltatásához hasonlóan ugyanúgy kínál üzenőfalat és csevegési lehetőséget. Többségében azonban SunTM 4M gépeik vannak, amelyen SunOSTM fut. | |||||||
16.8. | Mi az a | ||||||
A SUP mozaikszó mögött a "Software Update Protocol" ("Szoftverfrissítési protokoll") áll, amelyet fejlesztési fák szinkronban tartására dolgoztak ki a Carnegie-Mellon Egyetemen. Régebben ennek segítségével tartották frissítették magukat a fejlesztői források különböző tükrözései a FreeBSD Projekten belül. A SUP nem kifejezetten egy sávszélesség-takarékos megoldás, és egy ideje már nyugdíjba vonult. A forrásainkat jelen pillanatban a CVSup használatával tudjuk frissíteni. | |||||||
16.9. | Hogy hívják azt a cuki kis vörös fickót? | ||||||
Igazából nincs neve, mindenki egyszerűen csak "BSD démonnak" nevezi. Ha mégis hívni szeretnénk valahogy, akkor szólítsuk csak "beastie"-nek, ugyanis a "beastie" kiejtése megegyezik a "BSD" szóéval ("bíeszdi"). A BSD démonról a saját honlapján tudhatunk meg többet. | |||||||
16.10. | Felhasználható a BSD démon képe? | ||||||
Talán. A BSD démon jogait Marshall Kirk McKusick birtokolja. A felhasználás pontos lehetőségeivel kapcsolatban olvassuk el Statement on the Use of the BSD Daemon Figure című írást. Röviden úgy foglalhatnánk össze, hogy ízléses stílusban a saját céljainkra mindaddig nyugodtan felhasználhatjuk a képet, amíg megemlítjük az eredeti szerzőt. Ha kereskedelmi céljaink vannak, akkor írjunk Kirk McKusick címére. A pontosabb részleteket a BSD démon honlapján olvashatjuk. | |||||||
16.11. | Található valahol felhasználható kép a BSD démonról? | ||||||
EPS és XFig formátumú rajzok a
| |||||||
16.12. | A levelezési listákon szerepeltek ismeretlen kifejezések vagy rövidítések. Hol lehet ezeknek utánanézni? | ||||||
Olvassuk el a FreeBSD szakkifejezéseinek gyűjteményét. | |||||||
16.13. | Miért fontos annyira a biciklitároló színe? | ||||||
Erre röviden úgy adhatnánk választ, hogy ezzel igazából nem kell annyira törődnünk. Ha viszont valamivel terjedelmesebben akarunk válaszolni, akkor azt mondhatnánk, hogy azért, mert egy biciklitároló megépítése még nem tántorít el senkit sem a válaszott szín kritizálásától és az átfestésének fontolgatásától. Ez a metafora alapvetően arról szól, hogy nem kell feltétlenül minden apró részletről vitatkoznunk csupán azért, mert jobban értünk hozzá. Sokak tapasztalata szerint ugyanis a változtatásokhoz kapcsolódó megjegyzések által gerjesztett zaj fordítottan arányos az adott változtatás bonyolultságával. A még hosszabb és teljesebb válasz eredetileg egy nagyon hosszú és fárasztó vita eredményeképpen keletkezett, amikor arról esett szó, hogy a sleep(1) törtekkel dolgozzon-e vagy sem. Erre válaszul küldte Poul-Henning Kamp az azóta híressé vált "A bike shed (any color will do) on greener grass..." ("(Bármilyen színű) biciklitároló megfelelne egy zöldebb gyepen...") című levelét. Ebből szeretnénk most idézni:
|
17.1. | Mennyire hűsít a FreeBSD? |
Kérdés: Mérte már valaki, hogy a FreeBSD futása közben mennyire melengeti meg a számítógépet? Úgy hírlik, a Linux(R) ebben a tekintetben sokkal jobb, mint a DOS, de FreeBSD-ről még nem ismert ezzel kapcsolatban semmi. Mondjuk, elég tüzesnek tűnik. Válasz: Nem, de korábban már számos tesztet végeztünk bekötött szemű önkénteseken, akiknek előzetesen 250 mikrogram LSD-25-öt adagoltak. A tesztalanyok 35 százaléka szerint a FreeBSD kissé narancsos ízű volt, míg a Linux(R) inkább a rózsaszín ködhöz hasonlított. A hőmérséklettel kapcsolatban azonban egyik csoport sem észlelt komolyabb változást. Végül aztán teljesen el kellett vetnünk a kísérlet eredményeit, mert menet közben túlságosan sok önkéntes kóborolt el, és ezzel torzították a mérések eredményeit. A legtöbb önkéntes azóta is Apple-nél van, és azóta is egy új "színes, szagos" grafikus felületen dolgoznak. Szép kis felfordulás! Komolyan: a FreeBSD és a Linux(R) is egyaránt a processzorokban található HLT (halt) utasítást használja arra, hogy az üresjáratban levő rendszer energiafogyasztását és ezáltal hőtermelését is valamennyire mérsékelje. Emellett még az APM (Advanced Power Management) is támogatott, így a FreeBSD akár tetszés szerint alacsonyabb energiafogyasztású módba is tudja tenni a processzort. | |
17.2. | Mi mocorog a memóriamodulokban? |
Kérdés: A FreeBSD csinál valami "szokatlan" a rendszermag fordítása közben, ami miatt a memóriák felől mocorgást lehet hallani? Amikor fordítok (vagy egy rövid ideig, amikor az indításkor a rendszer keresi a floppymeghajtót) valamilyen furcsa mocorgásszerű hang jön a memóriamodulokból. Válasz: Igen! Gyakran utalnak a BSD rendszerek dokumentációiban mindenféle "démonokra", és ezzel kapcsolatban a legtöbb ember nem is tudja, hogy ezek valójában apró, öntudatos, fizikailag nem létező lények, amelyek a rendszer indulása után megszállják a számítógépünket. A memóriából kiszűrődő mocorgás hangja igazából a démonok közti magas frekvenciás beszélgetésből ered, amikor éppen arról egyeztetnek, hogy miként birkózzanak meg a különböző rendszeradminisztrációs feladatokkal. Ha teljesen megőrjít minket ez a
zajongás, akkor úgy tudunk tőlük
megszabadulni, ha kiadjuk DOS-ból a jó
öreg | |
17.3. | Hány FreeBSD fejlesztő kell egy villanykörte kicseréléséhez? |
Ezeregyszázhatvankilenc: Huszonhárman panaszkodnak a -current listán, hogy már megint kiment a villany. Négyen erre azt válaszolják, hogy ez csak konfigurációs probléma, ezért ennek a -questions listán a helye. Hárman írnak róla
hibajelentést, de ezek közül az egyik
ráadásul tévesen a
Erre az egyikük beszerel egy kipróbálatlan villanykörtét, amitől nem működik a rendszer többi része, így öt perc múlva ki is szereli. Nyolcan leszidják a hibajelentések íróit, hogy nem mellékelték a javítást a jelentéseik mellé. Öten siránkoznak, hogy nem működik a rendszer. Harmincegyen erre azt válaszolják, hogy nekik minden remekül működik, és az érintettek minden bizonnyal pont rosszkor frissítettek. Egy küld egy új villanykörtét a -hackers listára. Erre egy rászól, hogy ő már három évvel ezelőtt megcsinálta ugyanezt, de amikor beküldte a -current listára, akkor senki sem foglalkozott vele, és egyébként sem szereti a hibajelentéseket. Emellett ráadásul az új villanykörte egyébként sem tetszik. Huszonheten nekiállnak skandálni, hogy a villanykörték nem tartoznak az alaprendszerbe, ezért a committerek a közösség megkérdezése nélkül nem csinálhatnak semmit, és különben is: Mi erről a -core véleménye? Kétszázan eközben megvitatják, milyen színű legyen a biciklitároló. Hárman jelzik, hogy a javítás nem felel meg a style(9) előírásainak. Tizenheten megjegyzik, hogy az újonnan javasolt villanykörte GPL licenccel rendelkezik. Ötszázhatvankilencen valóságos vitaözönt indítanak a GPL, a BSD, MIT és NPL licencek előnyeit illetően, majd megjegyzéseket tesznek különféle meg nem nevezett FSF alapítók személyes higéniajára. Heten a vita bizonyos részeit átviszik a -chat és -advocacy listákra. Egy végül beszereli a javasolt villanykörtét, de az valamivel mintha halványabban világítani, mint az előző. Ketten leszólják a szerelést, és összekapnak azon, hogy most akkor a FreeBSD inkább maradjon sötétségben vagy érje be a halványabb világítással. Negyvenhárman rikácsolva követelik a halványan világító villanykörte kiszerelését és panaszukat megírják a -core listára. Tizenegyen egy kisebb villanykörtét kérnek, mert ha majd portolni akárják a Tamagotchijukra a rendszert, akkor ott is használható legyen. Hetvenhárman felemelik a szavukat a -hackers és -chat listákon felerősödött zaj miatt, és tiltakozásul leiratkoznak ezekről a listákról. Tizenhárman erre egy "leiratkozom", " Hogyan kell innen leiratkozni?" vagy "Kérlek, vegyetek le erről a listáról" témájú levelet küldenek a megszokott stílusban. Egy eközben beszerel végre egy működő villanykörtét, miközben mindenki azzal van elfoglalva, hogy szidja a másikat, így szinte észre sem veszik. Harmincegy ezután hozzáteszi, hogy az új villanykörte 0,364 százalékkal jobban világítana, ha TenDRA-val csinálták volna (akkor viszont kocka alakú lenne) és a FreeBSD-nek ezért a GCC helyett TenDRA-t kellene használnia. Egy valaki megemlíti, hogy az új villanykörtén nincs is burkolat. Kilencen (beleértve a hibajelentések íróit) azt kérdezgetik folyton, hogy "Mi az az MFC?". Ötvenheten két hét múlva kezdenek el panaszkodni, hogy a villanykörte kiment. Nik Clayton hozzáteszi: Nagyon jót nevettem ezen. Közben az jutott az eszembe, hogy "Várjunk csak, nem kellene valahol a felsorolásban lennie egy >>egy, aki pedig ledokumentálja<< résznek?" És akkor végre megértettem :-) Thomas Abthorpe szerint: "Egy sem, mert a valódi FreeBSD fejlesztők nem félnek a sötétben!" | |
17.4. | Hova kerül a |
A processzoron található speciális
adatsüllyesztőbe kerül, majd hővé
alakul és elszállítja a felszerelt
hűtőborda és ventillátor.
Ezért is annyira fontos a processzor
hűtése: az emberek minél gyorsabb
géppel rendelkeznek, annál inkább
gondatlanná válnak és annál
több adat köt ki a Paul Robinson hozzáteszi: Vannak még más módszerek is. Minden jó rendszergazda tudja, hogy szokás a képernyőre is folyamatosan adatot küldeni, mert így a pixik is vidámabbak lesznek. A képernyőt formázó pixik (melyek gyakran tévesen és hibásan "pixeleknek" hívnak) a fejükön viselt kalapok szerint három csoportba sorolhatóak (vörös, zöld vagy kék), és annak megfelelően bújnak elő (illetve mutatják meg a kalapjukat), hogy kapnak-e enni. A videokártyák felelősek azért, hogy a kapott adatokból pixiétel készüljön és hogy az eljusson a pixikhez - minél drágább a kártya, annál jobb minőségű az előállított étel, és annál fegyelmezettebben viselkednek a pixik. Állandó cirogatásra is szükségük van - ez a képernyővédők feladata. Az előbbi javaslatot azzal tudnám még
kiegészíteni, hogy a
Mellesleg mint az egyik nagy szolgáltató egykori rendszergazdája elmondhatom, hogy mivel tapasztalatom szerint a szerverszobában nehéz tartani a megfelelő hőmérsékletet, ezért nem ajánlom senkinek a felesleges adatok átküldését a hálózaton. A csomagok közvetítésével és irányításával foglalkozó tündérek sem különösebben szoktak örülni ennek. |
18.1. | Honnan lehet többet megtudni a FreeBSD belső felépítéséről? |
Jelen pillanatban csak egyetlen mű foglalkozik az
operációs rendszerek
felépítésével a FreeBSD
szemszögéből, név szerint a Marshall
Kirk McKusick és George V. Neville-Neil által
írt "The Design and Implementation of the
FreeBSD Operating System" című könyv
(ISBN 0-201-70245-2), amely a FreeBSD
5. Emellett a UNIX(R) típusú rendszerek használatával kapcsolatos ismeret remekül alkalmazható a FreeBSD esetén is. A témához tartozó többi könyvet a kézikönyv Az operációs rendszerek belső működésével foglalkozó irodalomjegyzékben találhatjuk meg. | |
18.2. | Hogyan lehet bekapcsolódni a FreeBSD fejlesztésébe? |
Pontosabb tanácsokat akkor kapunk, ha elolvassuk a FreeBSD fejlesztéséről szóló cikket. Nagyon is számítunk mindenki segítségére! | |
18.3. | Mik azok a pillanatkiadások és kiadások? |
Jelenleg három aktív és félig aktív ág van a FreeBSD CVS repositoryjában. (A korábbi ágakat már csak nagyon ritkán módosítják, ezért is csak három aktív fejlesztési ágon fejlesztenek):
A Jelen pillanatban a -CURRENT a
9. | |
18.4. | Hogyan lehet saját kiadást készíteni? |
Olvassuk el a kiadások készítéséről szóló cikket. | |
18.5. | A |
Mert alapvetően ez lenne a cél: ahogy a neve
is sugallja, a rendszer újrafordítása,
vagyis a
Ha a | |
18.6. | Miért nem forgó ("round robin") névfeloldással lehet elérni a CVSup szervereket és így megosztani köztük a terhelést? |
Habár a CVSup
tükrözések óránként
frissítik magukat a központi
CVSup szerverről, maga a
frissítés azonban bármikor
megtörténhet. Ennek
következményeképpen egyes szervereken
frissebb kód található, miközben a
többin még az egy órával
ezelőtti állapot szerepel. Ha a | |
18.7. | A -CURRENT forrásait korlátozott interneteléréssel is lehet követni? |
Igen, ezt a CTM használatával anélkül is megtudjuk tenni, hogy le kellene töltenünk az egész forrásfát. | |
18.8. | Hogyan lehet 1392 KB-os darabokra felosztani az egyes terjesztéseket? |
Az újabb BSD alapú rendszerekben a
split(1) parancsnak már van egy
Íme erre egy példa a
ZIPNSPLIT= gzip --no-name -9 -c | split -b 1392k - | |
18.9. | Hova lehet küldeni a rendszermaghoz írt kiegészítéseket? |
Erre vonatkozóan vessünk egy pillantást a FreeBSD továbbfejlesztéséről szóló cikkre. Köszönjük, hogy gondolt ránk! | |
18.10. | A rendszer hogyan érzékeli és inicializálja a Plug and Play ISA kártyákat? |
Frank Durda IV
( Dióhéjban úgy tudnám ezt
elmagyarázni, hogy van néhány I/O port,
amelyet lekérdezve a PnP kártya képes
válaszolni, hogy elérhető-e.
Ezért a PnP eszközök keresése azzal
kezdődik, hogy a rendszer felteszi a
kérdést, van-e PnP kártya a
számítógépben. Erre
aztán a különböző
kártyák a típusuk
megjelölésével válaszolnak,
amelyet ugyanezen az I/O porton kell visszaolvasni,
így ha már legalább egy bitet
beállít valaki, akkor folytatható a
keresés. Ezután a keresést
végző kódrész letiltja az
Az azonosítók két 32 bit hosszúságú mezőből (ezért írtunk az előbb 264 lépést) és egy 8 bites ellenőrzőösszegből állnak. Az első 32 bit a gyártót azonosítja. Ugyan soha nem vallják be, de úgy tűnik, hogy még ugyanannak a gyártónak is lehetnek eltérő gyártóazonosítóval rendelkező kártyái. A gyártók számára fenntartott 32 bites mező ezért valamennyire túlzás. A második 32 bit lehet a kártya sorozatszáma vagy bárki más, amely alapján egyértelműen beazonosítható. A gyártó ugyanazzal a 32 bites értékkel nem gyárthat egy másik kártyát, csak abban az esetben, ha a másik 32 bit is eltér. Ennek köszönhetően egy gépen belül még az azonos típusú kártyák is el fognak térni 64 biten. Az iménti 32 bites csoportok nem lehetnek teljesen nullák, ezért lehetséges, hogy a bináris keresés során a válaszban legalább egy bit mindig aktív lesz. Miután a rendszer sikeresen beazonosította a rendelkezésre álló kártyákat, egyenként újra elindítja ezeket (ugyanazon az I/O porton keresztül), és megpróbálja kitalálni, hogy az adott eszközöknek milyen erőforrásokra van szüksége, milyen megszakítást akarnak használni stb. Az összes kártyától lekérdezi ezeket az információkat. Az így megszerzett információkat aztán még kiegészíti a merevlemezen vagy az MLB BIOS-ban található ECU állományok tartalmával. Az ECU és az MLB BIOS PnP támogatása általában viszont nem valódi, és az ilyen eszközök igazából nem is állítanak be semmit maguktól. A BIOS és az ECU átvizsgálása azonban segít a felderítést végző rutinnak értesíteni a tényleges PnP eszközöket, hogy ne foglaljanak el olyan erőforrásokat, amelyeket a rendszer nem tud áthelyezni. Ezután a PnP eszközöket a kód még egyszer végigjárja és átadja nekik a működésükhöz szükséges I/O, DMA, IRQ és memóracímek hozzárendeléseit. Az eszközök ekkor a megadott helyeken elérhetővé válnak és úgy is maradnak a rendszer következő indításáig, de igazából semmi sem rögzíti ezeket. Talán túlságosan is egyszerűsítettem a fentieket, de szerintem már ennyi is elegendő az alapok megértéséhez. A Microsoft(R) néhány elsődleges
nyomtatási állapotot jelző portot
átrakott PnP-re, azzal a címszóval,
hogy egyik kártya sem kódolta át ezeket
a címeket az ellenkező I/O ciklusok
számára. Találtam is egy eredeti IBM
nyomtatókártyát, amely valóban
át tudta írni az állapotjelző
portot a PnP kezdeti változataiban, de arra a
Microsoft(R) csak annyit mondott, hogy
"fogós". Ezért a
nyomtatási állapotot jelző portot a
címek beállítására
használja, illetve még a
| |
18.11. | Hogyan lehet főeszközazonosítót rendelni egy általunk fejlesztett meghajtóhoz? |
2003 februárja óta a FreeBSD képes dinamikusan és önműködően futás közben lefoglalni főeszközazonosítókat a meghajtóknak (lásd devfs(5)), ezért erre tulajdonképpen már nincs szükség. | |
18.12. | A könyvtárakra vonatkozóan milyen más kiosztási házirendek léteznek még? |
A könyvtárak más fajta
kiosztására vonatkozóan annyit tudok
válaszolni, hogy a jelenleg is alkalmazott
sémát az 1983-ban megalkotott változata
óta változatlanul használjuk.
Eredetileg a gyors állományrendszerhez
készítettem, de soha nem ragaszkodtam
hozzá. Remekül megoldja a cilindercsoportok
betelésének problémáját,
azonban sokan megjegyezték már, hogy a
find(1) esetén gyengén működik.
A legtöbb állományrendszert
mélységi bejárással
hozzák létre, így a
könyvtárak szétszóródnak a
cilindercsoportok közt és ezzel a
későbbi mélységi keresések
számára a lehető legrosszabb helyzetet
alakítják ki. Ha valaki például
tudja előre a létrehozni kívánt
könyvtárak számát, akkor ezt
úgy lehet megoldani, ha a művelet során
Kirk McKusick, 1998 szeptembere | |
18.13. | Hogyan lehet kinyerni a legtöbb információt a rendszermag összeomlásából? |
Általában így néz ki a rendszermag összeomlása: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x40 fault code = supervisor read, page not present instruction pointer = 0x8:0xf014a7e5 stack pointer = 0x10:0xf4ed6f24 frame pointer = 0x10:0xf4ed6f28 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 80 (mount) interrupt mask = trap number = 12 panic: page fault Amikor egy ilyen üzenetet látunk, akkor nem
elegendő újra előcsalni a hibát
és beküldeni. Az
utasításszámláló
("instruction pointer") értéke
ugyan nagyon fontos, de sajnos konfigurációk
szerint eltérhet. Más szóval
úgy fogalmazhatnék, hogy ennek az
értéke a használatban levő
rendszermag értékétől
függően változhat. Ha a
Ezért a javaslatom a következő:
A legjobb viszont mégis az, amikor sikerül lementeni a hiba bekövetkezésekor a memória tartalmát, majd a kgdb(1) használatával előbányászni belőle egy hívási láncot. Ehhez többnyire a következő módszer javasolt:
Megjegyzés:A A make(1) programnak a folyamat
végeredményeként két rendszermagot
kell készítenie: a
A rendszer csak akkor fogja elmenteni
összeomláskor a memória tartalmát,
ha az Megjegyzés:A FreeBSD által létrehozott
memóriamentések mérete
általában a
számítógépünkben
levő fizikai memória
mennyiségével egyezik meg. Tehát
ha 512 MB RAM van a gépünkben, akkor
egy 512 MB méretű mentést fogunk
kapni. Ezért gondoskodjunk róla, hogy a
Ahogy sikerült hozzájutnunk a memóriamentéshez, azonnal is kérhetünk a kgdb(1) használatával egy hívási láncot belőle:
Előfordulhat, hogy ilyenkor több oldalnyi információ özönlik hirtelen a képernyőre, ezért javasolt ezeket lementeni a script(1) programmal. A nyomkövetési szimbólumokat is tartalmazó rendszermag esetén még akár azt a sort is megkapjuk a rendszermagon belül, ahol a hiba történt. A hívási láncot általában alulról felfelé kell olvasni, és ebből deríthető, hogy pontosan milyen események is vezettek az összeomláshoz. A kgdb(1) használatával még a különböző változók és struktúrák értékeit is meg tudjuk vizsgálni, így még többet megtudhatunk a rendszer állapotáról az összeomlás pillanatában. Tipp:Ha az iméntiek mentén nagyon fellelkesültünk volna és van egy másik számítógépünk is, akkor a kgdb(1) akár távoli nyomkövetésre is beállítható, aminek köszönhetően a kgdb(1) használatával az egyik rendszeren meg tudjuk állítani a másikon futó rendszermagot, ellenőrizhetjük a viselkedését, akárcsak bármelyik más felhasználói program esetében. Ha netalán engedélyeztük volna a
| |
18.14. | A |
Az ELF állományokhoz tartozó
segédprogramok alapértelmezés szerint nem
teszik láthatóvá a dinamikus linker
számára a végrehajtható
állományban definiált
szimbólumokat. Ennek eredményeképpen a
Ha szükségünk lenne ilyen
keresésekre a | |
18.15. | Hogyan növelhető vagy csökkenthető a rendszermag címtere i386TM architektúrán? |
Az i386TM platformon a rendszermag címtere alapértelmezés szerint 1 GB (PAE esetén 2 GB). Ha komolyabb hálózati forgalmat bonyolító szerverünk van (például egy nagyobb FTP vagy HTTP szerver) vagy rendszerükön használni akarjuk a ZFS állományrendszert, akkor könnyen kifuthatunk a címtérből. A címtér méretének megváltoztatásához vegyük fel a következő sort a rendszermag konfigurációs állományába, majd fordítsuk újra a rendszermagot: options KVA_PAGES= Az |
Ezt a szegény kis ártatlan GYIKocskát több százan, ha nem is éppen több ezren írták, újraírták, szerkesztették, hajtogatták, tekergették, csonkítgatták, kibelezték, nézegették, összekutyulták, emlegették, felöklendezték, újraépítették, javítgatták és felpezsdítették az utóbbi években. Folyamatosan.
Ezúton is szeretnénk köszönetet mondani mindazoknak, akik gondozásukba vették, és mindenkit csak bátorítani tudunk, hogy csatlakozzon hozzájuk a GYIK továbbfejlesztésében.
[biblio-unleashed] FreeBSD Unleashed. Sams. első kiadás. 992 oldal. 2001 október. ISBN 0-67232-206-4.
[biblio-44sysman] 4.4BSD System Manager's Manual. O'Reilly and Associates. első kiadás. 1994 június. 804 oldal. ISBN 1-56592-080-5.
[biblio-44userman] 4.4BSD User's Reference Manual. O'Reilly and Associates. első kiadás. 1994 június. 905 oldal. ISBN 1-56592-075-9.
[biblio-44suppman] 4.4BSD User's Supplementary Documents. O'Reilly and Associates. első kiadás. 1994 június. 712 oldal. ISBN 1-56592-076-7.
[biblio-44progman] 4.4BSD Programmer's Reference Manual. O'Reilly and Associates. első kiadás. 1994 június. 866 oldal. ISBN 1-56592-078-3.
[biblio-44progsupp] 4.4BSD Programmer's Supplementary Documents. O'Reilly and Associates. első kiadás. 1994 június. 596 oldal. ISBN 1-56592-079-1.
[biblio-44kernel] The Design and Implementation of the 4.4BSD Operating System. Addison-Wesley. Reading MA . 1996. ISBN 0-201-54979-4.
[biblio-freebsdkernel] The Design and Implementation of the FreeBSD Operating System. Addison-Wesley. Boston MA . 2004. ISBN 0-201-70245-2.
[biblio-nemeth3rd] Unix System Administration Handbook. Prentice-Hall. harmadik kiadás. 2000. ISBN 0-13-020601-6.
[lehey3rd] The Complete FreeBSD. Walnut Creek. harmadik kiadás. 1999 június. 773 oldal. ISBN 1-57176-246-9.
[biblio-handbook] The FreeBSD Handbook. BSDi. első kiadás. 1999 június. 489 oldal. ISBN 1-57176-241-8.
[biblio-ja-fbsdpc98] FreeBSD for PC 98'ers (Japánul). SHUWA System Co, LTD.. ISBN 4-87966-468-5 C3055 P2900E.
[biblio-ja-compintro] Complete Introduction to FreeBSD (Japánul). Shoeisha Co., Ltd. ISBN 4-88135-473-6 P3600E.
[biblio-ja-unixstarterkit] Personal UNIX Starter Kit FreeBSD (Japánul). ASCII. ISBN 4-7561-1733-3 P3000E.
[biblio-ge-fbsdmitmeth] FreeBSD mit Methode (Németül). Computer und Literature Verlag/Vertrieb Hanser. 1998. ISBN 3-932311-31-0.
[biblio-ja-fbsdinstandutil] FreeBSD install and Utilization Manual (Japánul). Mainichi Communications Inc..
[biblio-indo-intserv] Building Internet Server with FreeBSD (Indonéz nyelven). Elex Media Komputindo.
[biblio-cantfindadmin] What You Need To Know When You Can't Find Your Unix System Administrator. O'Reilly & Associates, Inc.. 1995. ISBN 1-56592-104-6.
[biblio-ja-fbsdusrrefman] FreeBSD User's Reference Manual (Japán fordítás). Mainichi Communications Inc.. 1998. ISBN 4-8399-0088-4 P3800E.
[biblio-newcomeunix] "Online Guide for newcomers to the UNIX environment". Edinburgh University.
[biblio-dnsandbind] DNS and BIND. O'Reilly & Associates, Inc. ISBN 1-56592-512-2. 1998. harmadik kiadás.
[biblio-esssysadmin] Essential System Administration. második kiadás. O'Reilly & Associates. 1995. ISBN 1-56592-127-5.
[biblio-tcpipnetworkadministration] TCP/IP Network Administration. második kiadás. O'Reilly & Associates, Inc. 1997. ISBN 1-56592-322-7.
[biblio-managingnfsandnis] Managing NFS and NIS. O'Reilly & Associates, Inc. 1991. ISBN 0-937175-75-7.
[biblio-jpmanprojectjfug] FreeBSD System Administration's Manual. Mainichi Communications Inc.. 1998. ISBN 4-8399-0109-0 P3300E.
[biblio-portingunixsoft] Porting UNIX Software. O'Reilly & Associates, Inc.. 1995. ISBN 1-56592-126-7.
[biblio-advprogintheunixenv] Advanced Programming in the UNIX Environment. Addison-Wesley. 1992. ISBN 0-201-56317-7.
[biblio-unixnetprog] UNIX Network Programming. Prentice Hall. 1998. második kiadás. ISBN 0-13-490012-X.
[biblio-writeserialdriverforunix] Writing Serial Drivers for UNIX. 1994 december. Dr. Dobb's Journal. 68-71, 97-99.
[biblio-portingunixtothe386] Porting UNIX to the 386. Dr. Dobb's Journal. 1991 január - 1992 július.
[biblio-tcpipillv1theprotocols] TCP/IP Illustrated, Volume 1: The Protocols. Addison-Wesley. 1996. ISBN 0-201-63346-9.
[biblio-unixsysformodrnarch] Unix Systems for Modern Architectures. Addison-Wesley. 1994. ISBN 0-201-63338-8.
[biblio-tcpipillvol3] TCP/IP Illustrated, Volume 3: TCP for Transactions, HTTP, NNTP and the UNIX Domain Protocols. Addison-Wesley. 1996. ISBN 0-201-63495-3.
[biblio-unixinternthenewfrontiers] UNIX Internals -- The New Frontiers. Prentice Hall. 1996. ISBN 0-13-101908-2.
[biblio-tcpipillvol2theimplementation] TCP/IP Illustrated, Volume 2: The Implementation. 1995. Addison-Wesley. ISBN 0-201-63354-X.
[biblio-firewallsandinternetsecurity] Firewalls and Internet Security: Repelling the Wily Hacker. Addison-Wesley. 1995. ISBN 0-201-63357-4.
[biblio-practicalunixsecurity] Practical UNIX Security. 1996. második kiadás. O'Reilly & Associates, Inc. ISBN 1-56592-148-8.
[biblio-pgpprettygoodprivacy] PGP Pretty Good Privacy. O'Reilly & Associates, Inc. 1995. ISBN 1-56592-098-8.
[biblio-pentiumprocarch] Pentium Processor System Architecture. Addison-Wesley. 1995. második kiadás. ISBN 0-201-40992-5.
[biblio-progguidetothesvgacards] Programmer's Guide to the EGA, VGA, and Super VGA Cards. harmadik kiadás. Addison-Wesley. 1995. ISBN 0-201-62490-7.
[biblio-80486] 80486 System Architecture. Addison-Wesley. 1995. harmadik kiadás. ISBN 0-201-40994-1.
[biblio-isasysarch] ISA System Architecture. Addison-Wesley. harmadik kiadás. 1995. ISBN 0-201-40996-8.
[biblio-pcisysarch] PCI System Architecture. Addison-Wesley. 1995. harmadik kiadás. ISBN 0-201-40993-3.
[biblio-bellsystemtechnicaljournal] Bell System Technical Journal, Unix Time-Sharing System. American Telephone & Telegraph Company. 1978 július - augusztus. Vol 57, No 6, Part 2. ISSN0005-8580.
[biblio-commentaryonunix] Lion's Commentary on UNIX. ITP Media Group. 1996. hatodik kiadás. ISBN 1573980137.
[biblio-newhackerdict] The New Hacker's Dictionary. MIT Press. 1996. harmadik kiadás. ISBN 0-262-68092-0.
[biblio-unixhatershandbook] The UNIX-HATERS Handbook. IDG Books Worldwide, Inc. 1994. ISBN 1-56884-203-1.
[biblio-bsdfamilytree] The BSD Family Tree. 1997.