10. fejezet - Rendszeradminisztráció
Vissza |  | Előre

## 10. fejezet - Rendszeradminisztráció

10.1. Hol vannak a rendszerindítás beállításáért felelős állományok?
10.2. Hogyan lehet felhasználókat egyszerűen létrehozni?
10.3. A crontab szerkesztése után miért jelennek meg a root: not found és a hozzá hasonló hibaüzenetek?
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?
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?
10.6. Miért nem sikerül beállítani a nyomtatót?
10.7. Hogyan lehet módosítani a rendszerünkhöz tartozó billentyűkiosztást?
10.8. Miért jelenik meg az unknown: <PNP0303> can't assign resources hibaüzenet a rendszer indulásakor?
10.9. Miért nem működnek rendesen a kvóták?
10.10. A FreeBSD tartalmazza a System V IPC alapeszközeit?
10.11. A sendmail helyett milyen más levelező szerver használható még?
10.12. Elveszett a root felhasználó jelszava! Mit tegyünk?
10.13. Hogyan akadályozható meg, hogy a Control+Alt+Delete billentyűkombináció újraindítsa a rendszert?
10.14. Hogyan lehet szöveges DOS állományokat UNIX® formátumúra alakítani?
10.15. Hogyan lehet futó programokat név szerint leállítani?
10.16. A su(1) miért írja folyton, hogy a felhasználó nincs a root ACL-jében?
10.17. Hogyan távolítható el a Kerberos?
10.18. Mi történt a /dev/MAKEDEV állománnyal?
10.19. Hogyan lehet még több pszeudoterminált létrehozni?
10.20. Hogyan lehet újraindítás nélkül az /etc/rc.conf tartalmát újraolvastatni és újraindítani az /etc/rc szkriptet?
10.21. A -STABLE rendszer frissítésekor -BETAx, -RC vagy -PRERELEASE verzió jelenik meg! Mi történt?
10.22. Az új rendszermag telepítése során a chflags(1) program hibát jelez. Hogyan javítható ez a hiba?
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?
10.24. Az rpc.statd parancsnak miért kell 256 MB memória?
10.25. Miért nem törölhető az schg állományjelző?
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?
10.27. Mi az a vnlru?
10.28. Mit jelentenek top parancs által megjelenített különböző memóriaállapotok?
10.29. Mekkora a rendelkezésre álló memória mérete?
10.30. Mi az a /var/empty? Nem lehet letörölni!

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 `/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`.

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 `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.

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® 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:

| 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 `<wollman@FreeBSD.org>`, 2001. április 24.

10.9. | Miért nem működnek rendesen a kvóták?

1. 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.

2. Az `/` állományrendszeren ne engedélyezzük a kvóták használatát.

3. Tegyünk kvótaállományokat azokra az állományrendszerekre, ahol be akarjuk vezetni a használatukat, például:

   Állományrendszer | Kvótaállomány
   --- | ---
   `/usr` | `/usr/admin/quotas`
   `/home` | `/home/admin/quotas`
   … | …

10.10. | A FreeBSD tartalmazza a System V IPC alapeszközeit?

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.

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 `root` felhasználó jelszava! Mit tegyünk?

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 Fixit 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

10.14. | Hogyan lehet szöveges DOS állományokat UNIX® formátumúra alakítani?

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.

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 `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.
10.17. | Hogyan távolítható el a Kerberos?
| 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.
10.18. | Mi történt a `/dev/MAKEDEV` állománnyal?
| 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.
10.19. | Hogyan lehet még több pszeudoterminált létrehozni?

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 -BETA`x`, -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.

10.24. | Az `rpc.statd` parancsnak miért kell 256 MB memória?

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.

10.25. | Miért nem törölhető az `schg` állományjelző?
| 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.

10.27. | Mi az a `vnlru`?
| 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.
10.28. | Mit jelentenek `top` parancs által megjelenített különböző memóriaállapotok?

- `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.

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 `/var/empty`? Nem lehet letörölni!

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).

Vissza |  | Előre
9. fejezet - Lemezek, állományrendszerek és rendszertöltők | Főoldal | 11. fejezet - 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): <questions@FreeBSD.org>.
Ha ezzel a dokumentummal kapcsolatban van kérdése, kérjük erre a címre írjon: <gabor@FreeBSD.org>.