Az ezzel kapcsolatos beállítások elsősorban az /etc/defaults/rc.conf állományban találhatóak (lásd rc.conf(5)). A rendszer indításáért felelős szkriptek, mint például az /etc/rc vagy az /etc/rc.d könyvtár tartalma (lásd rc(8)) ezt használja. Ezt az állományt tilos közvetlenül szerkeszteni! Ha valamit meg akarunk változtatni az /etc/defaults/rc.conf állományban szereplő beállítások közül, akkor ehelyett egyszerűen csak másoljuk le az /etc/rc.conf állományba és állítsuk be ott az értékét.
Például, ha el akarjuk indítani a beépített névfeloldó szolgáltatást, a named(8) démont, akkor ennyit kell tennünk:
# echo 'named_enable="YES"' >> /etc/rc.conf
Ha helyi szolgáltatásokat akarunk futtatni, akkor tegyük a hozzá tartozó szkripteket az /usr/local/etc/rc.d könyvtárba. Ezek a szkriptek legyenek végrehajthatóak és az alapértelmezett állománymóduk legyen 555.
Használjuk a adduser(8), vagy bonyolultabb esetekben a pw(8) parancsot.
Felhasználókat törölni a rmuser(8), vagy amennyiben szükséges, a pw(8) paranccsal tudunk.
10.3. A crontab szerkesztése után miért jelennek meg a “root: not found” és a hozzá hasonló hibaüzenetek?
Ilyen általában olyankor történik, amikor a rendszerszintű crontab állományt módosítjuk (/etc/crontab), majd a crontab(1) használatával megpróbáljuk telepíteni:
# crontab /etc/crontab
Ezt nem így kell megoldani. A rendszerszintű crontab felépítése eltér a felhasználókhoz tartozó crontab állományokétól (a crontab(5) man oldal szemlélteti részletesebben ezeket az eltéréseket), amelyet a crontab(1) próbál meg ilyenkor telepíteni.
Ha így csináltuk, akkor a crontab nem lesz több, mint az /etc/crontab hibás formátumú változata. Töröljük le:
# crontab -r
Legközelebb, amikor az /etc/crontab állományt módosítjuk, nem kell értesítenünk a cron(8) démont, mivel magától észre fogja venni az elvégzett változtatásokat.
Ha valamit napi, heti vagy havi rendszerességgel akarunk futtatni, akkor ehelyett inkább másoljuk be az /usr/local/etc/periodic könyvtárba, és hagyjuk, hogy a cron hívja meg a periodic(8) parancson keresztül az összes többi rendszeresen elvégzendő feladattal együtt.
Ez a hiba egyébként onnan jön, hogy rendszerszintű crontab állomány esetén van még egy további mező, amely megadja, hogy az adott parancsot melyik felhasználóval kell futtatni. Az alapértelmezett rendszerszintű crontab állomány esetén ez mindenhol a root. Amikor ezt a crontab állományt a root crontab állományaként használjuk (amely nem ugyanaz, mint a rendszerszintű crontab), akkor a cron(8) a root szót a végrehajtandó parancs részének fogja tekinteni, amely viszont nem létezik.
10.4. Miért jelenik meg a “you are not in the correct group to su root” hibaüzenet, amikor a su paranccsal át akarunk váltani a root felhasználóra?
Ez egy biztonsági megszorítás. Csak úgy tudunk átváltani a root felhasználóra (vagy bármilyen más olyan hozzáférésre, amely rendszeradminisztrátori jogosultságokkal rendelkezik), ha a wheel csoport tagjai vagyunk. Ha nem létezne ez a korlátozás, akkor a rendszerben szinte bárki képes lenne rendszeradminisztrátori jogosultságokat szerezni csupán úgy, hogy ha megszerzi valahogy a root jelszavát. Ennek a korlátozásnak köszönhetően ez viszont már nem lesz feltétlenül helytálló. A su(1) még a jelszót sem engedi megadni azoknak, akik nem tagjai a wheel csoportnak.
Ha engedélyezni akarjuk valakinek a root felhasználóra váltást, akkor nincs más teendőnk, mint egyszerűen a hozzáadni a wheel csoporthoz.
10.5. Az rc.conf állományban vagy valamelyik másik konfigurációs állományban rosszul adtuk meg a beállításokat, és nem lehet módosítani ezeket, mert így írásvédett lett az állományrendszer. Mi a megoldás?
Indítsuk újra a rendszert és a rendszertöltő parancssorában adjuk ki a boot -s parancsot, amivel így egyfelhasználós módba váltunk. Amikor meg kell adnunk a használni kívánt parancsértelmező nevét, egyszerűen csak nyomjuk le az Enter billentyűt, majd a mount -urw / parancs kiadásával csatlakoztassuk újra írható módban rendszerindító állományrendszert. Emellett még valószínűleg a mount -a -t ufs paranccsal azokat az állományrendszereket is érdemes lesz csatlakoztatnunk, ahol a kedvenc szövegszerkesztőnk található. Amennyiben az érintett szövegszerkesztő egy hálózati állományrendszeren található, akkor helyette használjunk egy helyben elérhető szövegszerkesztőt, például az ed(1) programot, vagy manuálisan állítsuk be a hálózat elérését a hálózati állományrendszerek csatlakoztatásához.
Ha a vi(1) vagy emacs(1) programokhoz hasonló teljes képernyős szövegszerkesztőt akarunk használni, akkor előtte nem árt a export TERM=cons25 parancsot sem kiadnunk, így a termcap(5) adatbázisból elérhetővé válnak az ehhez szükséges adatok.
Miután megtettük ezeket a lépéseket, már a szokásos módon át tudjuk szerkeszteni az /etc/rc.conf állományt. A rendszermag indulása után közvetlenül megjelenő üzenetekben találhatjuk meg azon sorok számait, amelyeket a rendszer nem tudott értelmezni.
Olvassuk el a kézikönyv nyomtatókkal foglalkozó részét, minden bizonnyal választ ad a legtöbb kérdésünkre.
Bizonyos nyomtatókat azonban akkor tudunk használni, ha van hozzá meghajtónk. Ezeket gyakran csak “WinPrinter” néven emlegetik, amelyeket viszont a FreeBSD nem támogat. Ha a nyomtatónk nem használható DOS vagy Windows® alatt, akkor valószínűleg egy ilyen WinPrinterrel van dolgunk. Ebben az esetben egyedül abban reménykedhetünk, hogy a print/pnm2ppa port támogatja.
Olvassuk el a kézikönyv honosításssal foglalkozó részét, különös tekintettel a konzol beállításaira.
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:
A “can't assign resources” üzenetek rendszerünkben olyan ISA eszközök jelenlétére utalnak, amelyekhez a rendszermagban PnP támogatást nem tartalmazó meghajtók tartoznak. Ilyenek többek közt a billentyűzetvezérlők, a programozható megszakítás-vezérlő chip és sok más alapvető elem a gépünkben. Ezek az erőforrások nem oszthatóak ki, mivel már valamelyik meghajtó használatba vette ezeket. | ||
--Garrett Wollman <[email protected]>, 2001. április
24. | ||
Előfordulhat, hogy a rendszermag nem támogatja a kvóták használatát. Ha erről lenne szó, akkor vegyük fel az alábbi sort a rendszermag konfigurációs állományába és fordítsuk újra:
options QUOTA
Ennek részleteit a kézikönyv kvótákkal foglalkozó részében találjuk.
Az / állományrendszeren ne engedélyezzük a kvóták használatát.
Tegyünk kvótaállományokat azokra az állományrendszerekre, ahol be akarjuk vezetni a használatukat, például:
Igen, a FreeBSD a GENERIC típusú rendszermagban támogatja a System V típusú IPC megoldást, beleértve az osztott memória, az üzenetek és a szemaforok használatát. Ha saját rendszermagunk van, akkor az alábbi beállítások használatával engedélyezhetjük a használatukat:
options SYSVSHM # az osztott memória engedélyezése options SYSVSEM # a szemaforok engedélyeze options SYSVMSG # az üzenetek kezelése
Fordítsuk és telepítsük újra a rendszermagot.
A sendmail a FreeBSD-ben található alapértelmezett levelező szerver, de könnyen le tudjuk cserélni másikra (például amelyet a portok közül telepítettünk).
A Portgyűjteményben több különböző levelező szerver is megtalálható, amelyek közül a mail/exim, mail/postfix, mail/qmail és a mail/zmailer portok a leginkább népszerűek.
Szép dolog, hogy lehet válogatni a különböző megoldások között és hogy ilyen sok levelező szerver használható. Ezért lehetőleg a levelezési listákon ne kérdezzünk senkitől olyat, hogy “De a sendmail akkor most miért jobb, mint a qmail?” Ha ilyen kérdéseink vannak, akkor először inkább olvassuk át az archívumokat. Szinte biztos, hogy már szinte az összes levelező szerver előnyét és hátrányát kivesézték jó néhányszor.
Ne essünk kétségbe! Indítsuk újra a rendszerünket egyfelhasználós módban. Ehhez gépeljük be a boot -s parancsot a rendszertöltő Boot: parancssorában. Amikor a parancsértelmezőt kell megadnunk, egyszerűen csak nyomjuk le az Enter billentyűt. Ekkor kapunk egy # parancssort. A mount -urw / parancs begépelésével csatlakoztassuk újra a rendszerindító partíciónkat írható módban, majd a mount -a paranccsal csatlakoztassuk az összes többi állományrendszert. Ezt követően a passwd root parancs kiadásával változtassuk meg a root felhasználó jelszavát és a exit(1) futtatásával folytassuk a rendszer indítását.
Megjegyzés: Ha az egyfelhasználós módra váltás során a rendszer a root felhasználó jelszavát kérné, akkor az arra utal, hogy a konzol (/dev/console) az /etc/ttys állomány szerint insecure (nem biztonságos) típusú. Ebben az esetben szereznünk kell egy FreeBSD telepítőlemezt, elindítanunk róla a rendszert, majd a sysinstall(8) programban a menüponton keresztül indított parancsértelmezőben kiadni az előbb említett parancsokat.
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:
# sysctl hw.syscons.kbd_reboot=0
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 SC_DISABLE_REBOOT beállítással fordítjuk újra.
Ha viszont a pcvt(4) konzolt használjuk, akkor a következő konfigurációs beállítást kell megadnunk a rendszermag újrafordításakor:
options PCVT_CTRL_ALT_DEL
Használjuk a következő perl(1) parancsot:
% perl -i.bak -npe 's/\r\n/\n/g' állományok
ahol az állományok az átalakítandó állományok. A konverzió helyben történik, illetve az eredeti állományokról .bak kiterjesztéssel létrejön egy biztonsági mentés.
Erre a célra viszont ugyanígy megfelel a tr(1) parancs is:
% tr -d '\r' < dos-szöveges-állomány > unix-szöveges-állomány
Ekkor a dos-szöveges-állomány lesz a DOS formátumú szöveges állomány, miközben a unix-szöveges-állomány fogja az eredményt tartalmazni. Ez valamivel gyorsabb a perl megoldásánál.
Ez említett megoldásokon kívül a DOS szöveges állományait a Portgyűjteményben található converters/dosunix porttal is könnyedén át tudjuk alakítani. Ennek részleteit a hozzá tartozó dokumentációból tudjuk meg.
Lásd killall(1).
10.16. A su(1) miért írja folyton, hogy a felhasználó nincs a root ACL-jében?
Ezt a hibát az elosztott
hitelesítést végző
Kerberos rendszer adja. Maga a
probléma nem végzetes, viszont annál
inkább idegesítő. Ilyenkor vagy a
-K kapcsolóval kell futtatni a
su(1) programot, vagy a következő
kérdésben megadottak szerint el kell
távolítani a
Kerberos
alkalmazást.
A Kerberos úgy távolítható el a rendszerből, ha újratelepítjük a base terjesztés tartalmát. Ha CD-ről telepítettük a rendszert, akkor csatlakoztassuk (most tegyük fel, hogy a /cdrom könyvtárba) és futassuk a következő parancsot:
# cd /cdrom/base # ./install.sh
Másik lehetőség, ha hozzáadjuk a NO_KERBEROS beállítást a /etc/make.conf állományhoz és újrafordítjuk az alaprendszert.
A FreeBSD 5.X és a későbbi változatok már a devfs(8) által felkínált automatikus megoldást alkalmazzák. Ilyenkor az eszközmeghajtók igény szerint hoznak létre eszközleírókat, és ezzel lényegében szükségtelenné teszik a /dev/MAKEDEV használatát.
Ha sok telnet, ssh, X esetleg screen felhasználónk van, akkor könnyen előfordulhat, hogy kifogyunk a pszeudoterminálokból. A FreeBSD 6.2 és az azt megelőző változatokban alapértelmezés szerint 256 pszeudoterminál, a FreeBSD 6.3 és későbbi változatokban pedig 512 pszeudoterminál áll rendelkezésünkre.
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 /etc/ttys állományt. Például a http://www.freebsd.org/~jhb/patches/pty_1152.patch 1152 pszeudoterminál használatát teszi lehetővé. Ez a konkrét javítás viszont csak a FreeBSD 6.3 és későbbi változatok esetén alkalmazható zökkenőmentesen.
10.20. Hogyan lehet újraindítás nélkül az /etc/rc.conf tartalmát újraolvastatni és újraindítani az /etc/rc szkriptet?
Váltsunk egyfelhasználós módba, majd vissza többfelhasználós módba.
Konzolon ez így oldható meg:
# shutdown now (Megjegyzés: nincs -r vagy -h!) # return # exit
10.21. A -STABLE rendszer frissítésekor -BETAx, -RC vagy -PRERELEASE verzió jelenik meg! Mi történt?
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:
# sysctl kern.securelevel
A biztonsági szintet nem lehet csökkenteni. A rendszert egyfelhasználós módban kell újraindítani, mert csak úgy tudjuk újratelepíteni a rendszermagot. Másik lehetőségünk, ha átállítjuk a biztonsági szintet az /etc/rc.conf állományban és úgy indítjuk újra a rendszerünket. Az init(8) man oldalán olvashatunk bővebben a biztonsági szintek (securelevel) beállításáról, az rc.conf használatáról pedig az /etc/defaults/rc.conf állományból és a rc.conf(5) man oldalon tudhatunk meg többet.
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 (securelevel) minden bizonnyal egynél nagyobbra állították. Indítsuk újra a rendszert egyfelhasználós módban és változtassuk meg a dátumot.
Egy hosszabb válasz: A FreeBSD nem engedi egy másodpercnél többel megváltoztatni az időt, ha az aktuális biztonsági szint értéke egy felett van. Ezt a következő parancs kiadásával tudjuk ellenőrizni:
# sysctl kern.securelevel
A biztonsági szint futás közben nem csökkenthető. A dátum megváltoztatásához ezért a rendszert egyfelhasználós módban kell indítanunk, vagy az /etc/rc.conf állományban csökkentenünk kell a biztonsági szintet. Az init(8) man oldalon olvashatunk részletesebben a biztonsági szintek működéséről, illetve az /etc/defaults/rc.conf állományból és az rc.conf(5) man oldalról tudhatunk meg többet az rc.conf működéséről.
Nem, itt szó sincs semmiféle memóriaszivárgásról, és egyébként sem használ 256 MB memóriát. Az rpc.statd parancs egyszerűen csak kényelmi megfontolásokból iszonyatos mennyiségű memóriát képez le a címterébe. Ebben technikailag semmi kivetnivaló nincsen, ezzel egyedül a top(1), ps(1) és a hozzá hasonló programokat zavarja meg egy kicsit.
A rpc.statd(8) tehát leképezi az állapotát rögzítő állományt (amely a /var könyvtárban található a címterébe. Ilyenkor igyekszik egy kicsit előre gondolkodni és felkészülni a megnövekedésére, ezért viszonylag nagy méretben hozza létre ezt a leképezést. Ezt nagyon jól megfigyelhetjük a forráskódjából is, ahol látszik, hogy a mmap(2) függvényt a 0x10000000 értékkel hívja meg, tehát az 32 bites Intel architektúrán megcímezhető memória egytizenhatod részével, ami pontosan 256 MB.
Rendszerünkben a biztonsági szint (securelevel) nagyobb nullánál. Próbáljuk meg csökkenteni az értékét és próbálkozzunk ismét. Ezzel kapcsolatban részletesebb információkat a a biztonsági szintekről szóló kérdésből vagy az init(8) man oldalról tudhatunk meg.
10.26. Az .shosts állományon keresztül alapértelmezés szerint miért enged hitelesíteni a legújabb FreeBSD verziókban megtalálható SSH?
A legújabb FreeBSD verziókban azért nem tudjuk az .shosts állományon keresztül hitelesíteni magunkat, mert az ssh(1) alapértelmezés szerint rendszeradminisztrátori jogok nélkül kerül telepítésre. Ezt a “hibát” többféle módon ki tudjuk “javítani”:
Ha tartós megoldásra van szükségünk, akkor az /etc/make.conf állományban állítsuk az ENABLE_SUID_SSH változót a true értékre, majd fordítsuk újra az ssh(1) programot (vagy futtassuk le a make world parancsot).
Ha ideiglenesen akarjuk csak javítani, akkor az /usr/bin/ssh állomány engedélyeit root felhasználóként állítsuk a 4555 értékre a chmod 4555 /usr/bin/ssh parancs kiadásával. Ezután vegyük fel az ENABLE_SUID_SSH= true sort az /etc/make.conf állományt, így ez a változtatás a make world következő futtatásakor is megmarad.
A vnlru törli és
szabadítja fel a rendszerben keringő vnode-okat,
amikor a rendszermagban elérik a
kern.maxvnodes változó
által beállított határt. Ez a
rendszermagban futó szál többnyire csak
tétlenül ül a háttérben,
és csak olyankor lép
működésben, amikor rengeteg
memóriát használunk és
éppen több tízezernyi apró
állományhoz akarunk egyszerre
hozzáférni.
Active (Aktív): az utóbbi időben használt lapok.
Inactive (Inaktív): az utóbbi időben nem használt lapok.
Cache (Tárazott): (leginkább) azok a lapok, amelyeket még használnak, de gyakran azonnal újrafelhasználódnak (akár a régi, akár egy új hozzárendelésben). Egyes lapok az active állapotból közvetlenül a cache állapotba váltanak, ha tiszták (nem módosították), de ez az átmenet függ a házirendtől, vagyis a VM alrendszer karbantartója által kiválasztott algoritmustól.
Free (Szabad): effektív tartalom nélküli lapok, amelyek akár közvetlenül fel is használhatóak olyan esetekben, amikor a tárazott lapok erre nem alkalmasak. A szabad lapokat megszakításokban és a futó programokban is felhasználhatjuk.
Wired (Rögzített): olyan lapok, amelyek a memória egy rögzített pontján foglalnak helyet. Ezeket többnyire a rendszermag használja, de speciális esetekben a programoknak is szükségük lehet rá.
A lapok általában akkor kerülnek ki a lemezre (valamilyen VM alrendszerbeli szinkronizáció során), amikor inaktív állapotban vannak, de akár az aktív lapok is szinkronizálhatóak. Ez attól függ, hogy a processzor képes-e nyomkövetni a lapok módosítását, és némely helyzetekben előnyös lehet a rendszer számára, ha annak megfelelően szinkronizálja a VM lapjait, hogy azok aktívak vagy inaktívak. A legtöbb esetben itt egyszerűen csak egy olyan sort kell elképzelni, ahol a program számára viszonylag inaktív lapok találhatóak, amelyeket a rendszer tetszőlegesen a lemezre írhat. A tárazott lapok általában már eleve szinkronizáltak, nem leképzettek, közvetlenül a programok régi és új hozzárendelései használják ezeket. A szabad lapokat akár a megszakítások szintjén is lehet használni, miközben a tárazott vagy szabad lapokat a futó programokban érthetjük el. A tárazott lapok zárolása nem megfelelő ahhoz, hogy megszakításokban is el lehessen érni ezeket.
Vannak még bizonyos jelzések (például a foglaltságot vagy foglaltság mértékét jelző értékek), amelyek még hatással vannak a fentebb leírt szabályokra.
A “rendelkezésre álló memóriának” rengeteg típusa létezik. Ezek közül egyik az a memória, amely közvetlenül anélkül elérhető, hogy bármi mást ki kellene hozzá lapoznunk. Ennek a mérete nagyjából a tárazott és a szabad lapokat tároló sorok hosszával arányos (amelyet még a rendszer beállításaitól függő további tényezők is módosíthatnak). A “rendelkezésre álló memória” másik típusa a teljes VM terület mérete. Ezt nem olyan könnyű meghatározni, de leginkább a lapozóterület és a fizikai memória méretétől függ. A “rendelkezésre álló memória” több más lehetséges megfogalmazása is létezik, de szinte teljesen felesleges beszélni róluk. Egyedül az a fontos, hogy a igyekezzünk mérsékelni a lapozást és mindig legyen elegendő lapozóterületünk.
A /var/empty könyvtárat az sshd(8) program használja a privilégiumok elkülönítéséhez. A /var/empty könyvtárnak üresnek kell lennie, legyen a root tulajdonában és legyen rajta a schg állományjelző.
Noha semmiképpen sem javasoljuk a könyvtár törlését, úgy tudjuk elvégezni, ha először az schg állományjelzőt töröljük róla. A chflags(1) man oldalán olvashatunk ezzel kapcsolatban részletesebb információkat (azonban ne felejtsük el számításba venni az esetleges nehézségeket).
| Előző | Tartalom | Következő |
| Lemezek, állományrendszerek és rendszertöltők | Az X Window System és a virtuális konzolok használata |
Ha kérdése van a FreeBSD-vel kapcsolatban, a következő
címre írhat (angolul): <[email protected]>.
Ha ezzel a dokumentummal kapcsolatban van kérdése,
kérjük erre a címre írjon: <[email protected]>.