Fejezet 10. Rendszeradminisztráció

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

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

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

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

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

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

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

# crontab /etc/crontab

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

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

# crontab -r

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

options SC_DISABLE_REBOOT

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

# sysctl hw.syscons.kbd_reboot=0

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

options PCVT_CTRL_ALT_DEL

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

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

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

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

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

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

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

Lásd killall(1).

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

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

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

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

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

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

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

Konzolon ez így oldható meg:

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

# return
# exit

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

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

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

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

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

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

# sysctl kern.securelevel

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

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

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

# sysctl kern.securelevel

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

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

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

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

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

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

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

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

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

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

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

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

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