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, 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ányrendszerKvó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 -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.

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

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