Alap beállítás szerint minden 20. újraindítást, illetőleg 20 napot követően a soron következő új-raindításnál a rendszer kényszeríteni fog egy fájlrendszer-ellenőrzést. Mivel jellemzően a szerve-reket távolról érjük el (SSH-val) ezért jellemzően nem vagyunk ot, amikor pl. egy kernel frissítés miat bekövetkezik az újraindítás utáni lemezellenőrzés. Normál esetben ez a lemezméret és a raj-ta tárolt állományok függvényében lehet 20 perc, de lehet 4,5 óra is. Ha pl. 100 kB-os képállomá-nyokból tárolunk 2 TB mennyiséget, akkor ez bizony 4,5 óra is lehet. Megszakítani nem érdemes, és nem is tanácsos. Viszont ha a rendszer talál sérült állományokat, amelyeket szeretne megjaví-tani, akkor átlép interaktív üzemmódba, és kérdezni fog. Igen ám, de az fsck programot a rendszer hálózat nélküli üzemmódban, alacsony init szinten indítja, így hacsak nem rendelkezünk a gépre fxen vagy ideiglenesen rákötöt IP-konzollal, akkor nem fogunk tudni beavatkozni. Ezért ha úgy gondoljuk, hogy jó mentést fogunk felépíteni és bízunk az fsck automatikus javító képességeiben, akkor célszerű megmondani az fsck-nak, hogy alapállapotban a feltet javító kérdésekre válaszol-jon igent, amelyet a /etc/default/rcS állományban az FSCKFIX=yes érték beállításával tudunk elérni.
Ha már beállítotuk az automatikus igent, célszerű a lemezeinkre beállítani egy vállalható idő-tartamot, azaz mondjuk meg mi az fsck számára, hogy mennyi időnként és hány
újraindításon-Egy szerver alapvető beállításai
ként szeretnénk kikényszeríteni az ellenőrzést. Erre a feladatra a tune2fs programot célszerű használni:
tune2fs -l /dev/sda3
A -l opcióval lekérdezhetjük az alapbeállításokat, és megtudhatjuk, mikor lesz a következő ter-vezet lemezellenőrzés – ebben a példában – a /dev/sda3 jelölésű partíción. Megváltoztatni pedig a tune2fs -c 40 -i 30d /dev/sda3 segítségével tudjuk, amikor is 40 csatolás vagy 30 nap eltelte után fogja követelni az ellenőrzést.
Szintén érdemes a tune2fs -m opciójával a csak rendszergazda számára fenntartot terület nagy-ságát az alapértelmezet 5%-ról alacsonyabbra, de még vállalható méretűre állítani – van, aki a 0,1%-ot tekinti megfelelőnek.
Most, hogy ezeken túl vagyunk, érdemes telepítenünk egy programot, amely fgyelni fog a leme-zeinkre helyetünk. Még a szerver tervezésénél eldöntötük, hogy hardveres vagy szofveres RAID-et alkalmazunk, vagy egyiket sem (ez nem javasolt!). Viszont akármelyik megoldást is vá-lasztotuk, a lemezeket fgyelni kell, hogy az esetleges meghibásodásról még időben értesülhes-sünk. Erre a feladatra a leginkább alkalmas program a smartmontools. Ez az eszköz a SMART adatokat biztosító merevlemezek megfgyelésére szolgál. A legtöbb ma kapható lemez már rendel-kezik azzal a képességgel, hogy folyamatosan és/vagy meghatározot időközönként önellenőrzése-ket futat le, fgyeli a lemezek környezeti paramétereit: melegedést, felpörgési időt, életartam időt, ki/be kapcsolások számát stb. Ezekből az adatokból következtet arra, hogy egy merevlemez lehetséges meghibásodása be fog-e következni. Felhasználói környezetben ezen adatok megtekin-tésére vagy a parancssori megoldás (smartctl -a /dev/sda1), vagy pedig a jobban átlátható GSmart-Control ajánlot. Beállítása viszonylag egyszerű, és a gyakorlati tapasztalat az, hogy a jól beállítot önellenőrzési ciklusokat is magában foglaló konfguráció képes lehet még az adatvesztést megelő-zően jelezni. Szerveroldalon képes együtműködni a gyártók saját platformos Linux RAID prog-ramjaival, de sajnos nem mindegyikkel.
Telepítése egyszerű:
apt-get install smartmontools
Ennek kiadása után a függőségekkel együt települ a smartmoontools. Első teendőnk, hogy el-döntsük, milyen lemezeket akarunk fgyeltetni vele. Célszerű az összes SMART-kompatibilis ren-delkezésre álló lemezt megfgyelni. Szofveres RAID esetén az összes fzikai lemezt egyenként be kell fűzni, hardveres RAID esetén pedig érdemes a gyártók hozzá adot szofverét is használni, il-letve megnézni, hogy az adot hardvervezérlő és a smartmon együt tud-e működni. Nézzük az egyszerű esetet, amikor 1-2 SATA vagy SAS lemez van a gépünkben, vagy SofRaid vagy single üzemmódban. Nézzük meg, hogy a lemezeink alkalmasak-e a SMART adatok kinyerésére:
smartctl -a /dev/sda smartctl -a /dev/sdb
Valami ilyesmit kellene kapnunk:
=== START OF INFORMATION SECTION ===
Device Model: ST91000640NS Serial Number:
LU WWN Device Id: 5 000c50 04ed10873 Firmware Version: FTA2
User Capacity: 1,000,204,886,016 bytes [1.00 TB]
Sector Size: 512 bytes logical/physical
Device is: Not in smartctl database [for details use: -P showall]
ATA Version is: 8
Egy szerver alapvető beállításai
ATA Standard is: ATA-8-ACS revision 4
Local Time is: Thu Aug 8 14:36:43 2013 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Disabled
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
Továbbá rengeteg olyan adatot, hogy hány fokos a lemez éppen, illetve hányszor volt ki- és be-kapcsolva, vagy hogy mennyi ideje pörög már. A lényeg, hogy a SMART adatok kiolvashatóak, te-hát állítsuk be a SMART fag-et ENABLED állásba a következőképpen:
smartctl -s on -a /dev/sda smartctl -s on -a /dev/sdb
Ha ezzel megvagyunk, akkor tudassuk a rendszerrel, hogy szeretnénk, ha bizonyos időközön-ként fgyelné a lemezeinket, szerkesszük a /etc/default/smartmontools állományt:
enable_smart="/dev/sda /dev/sdb"
Ebben adhatjuk meg, hogy a fzikai lemezeinket hogyan hívják, még akkor is ha valójában mi /dev/md1-ként hivatkozunk rá. Jelen példa mind a két szofveres RAID lemezt fgyelni fogja.
start_smartd=yes
Alapesetben of értékkel vagy kommentezve található, ha átraktuk on-ra, akkor a rendszer az in-dításától automatikusan fgyelni fogja a lemezeket is.
smartd_opts="--interval=1800"
Megadhatjuk másodpercben az ellenőrzés gyakoriságát. Figyeljünk oda, hogy ha a smartd-t en-gedélyezzük, akkor általában nem kell, sőt ellenjavallt felsorolni a fgyelendő lemezeket, ugyanis a smartd alapbeállítással automatikusan megkeresi.
Az alapbeállítások megadása után a service smartd restart kiadásával tudjuk root-ként (vagy sudo-val) érvényesíteni módosításainkat. A /var/log/syslog alat pedig már látható is lesz, hogy a smartd fgyeli a lemezeinket. Az alapbeállítások mellet a root fog levelet kapni, ha várható vagy bekövetkezet egy lemezmeghibásodás. Az alapbeállításokat a /etc/smartd.conf állományban tud-juk fnomítani, pl. ha másnak szeretnénk a fgyelmeztetéseket küldetni, vagy ha egy komplet tá-mogatot hardver RAID-et akarunk fgyelni.
Hardveres RAID fgyelése: számos hardveres RAID megoldás létezik a piacon. Szerencsére a gyár-tók is felismerték azon igényeket, hogy az eszközeiket nem csak használni szeretnénk, hanem megfgyelni is. Így számos gyártói szofvermegoldás születet, amely nem feltétlen szabad szofver (l. a Debian Wiki által karbantartot listát). Érdemes egyedileg megnézni ezeket a segédprogra-mokat, mert felhasználásukat tekintve ingyenesek, de a licencük alapján nem mindig szabad szof-verek.
Jellemzően mindegyik program igényel valamilyen minimális szkriptelést, amely segítségével au-tomatizálni tudjuk pl. az óránkénti állapotlekérdezést, illetve csak a hibák vagy hiba-előrejelzések megfgyelését, de ezek jellemzően 2-3 parancs 1 shell szkriptbe gyűjtése, illetve esetenként egy dif vagy egyéb alap parancs kombinációját jelentik. A szkript eredményét pedig e-mailben elküldve és/vagy naplószerverben feldolgozva kaphatunk értesítéseket a RAID aktuális állapotáról.
Egy szerver alapvető beállításai
Az idő kérdése
Fontos, hogy a szerverünknek be legyen állítva az időzóna paramétere, amit a tzconfi parancs segítségével tehetünk meg. A Magyarországon üzemeltetet és használt rendszereknél praktikus Budapest beállítást alkalmazni. A szerveren kliensként tehát a két leginkább elterjedt lehetőség közül választhatunk az idő szinkronizálásához: a napi rendszerességgel ki- és bekapcsolt gépek esetén, közelítőleg megfelelő eredményt érhetünk el egy a gép bekapcsolásakor automatikusan lefutó, a gép óráját a központi órához igazító parancs segítségével. Ez az ntpdate parancs, haszná-lata:
ntpdate -b time.kfki.hu
Míg a „-b” opció használata javasolt, addig a time.kfi.hu helyet inkább válasszunk valami ne-künk megfelelőt, ilyen lehet például a hu.pool.ntp.org (Magyarországról – más ország esetén java-solt azon ország országkódját használni a „hu” helyet). Amennyiben a gép folyamatos üzemben működik (a szerverek tipikusan ilyenek, de kényelmi okokból sokan a munkaállomásokat se kapcsolgatják), a bekapcsoláskor történő órabeállítás kevés lehet. Jellemzően a gépek órája sietni vagy késni fog egy idő után. Ebben az esetben a javasolt használat az, hogy az órát folyamatosan igazítsuk a központi órához. Ellenben az, hogy meghatározot időnként (például óránként, na-ponta) átállítjuk a gép óráját, felvet egy nagyon súlyos problémát – ilyen esetben elveszítjük az idő egy vagy több fontos jellemzőjét – a folytonosságot, illetve a monotonitást. Azaz vagy „luk”
keletkezik – kimaradó időpont – vagy ugyanaz az időpont többször is bekövetkezik. Ezért a bevált módszer a régi vekkerórákban alkalmazot „óralassítás” / „óragyorsítás”. Azaz lekérdezzük a köz-ponti gép óráját, és ha a miénk késést mutat, akkor felgyorsítjuk, ha pedig a miénk siet, akkor le-lassítjuk azt. Ezt szintén megtehetjük az ntpdate parancs segítségével, ekkor ki kell hagyni a fent említet „-b” opciót, helyete a „-B” használandó:
ntpdate -B time.kfki.hu
Majd ezt a parancsot kell óránként / napi rendszerességgel lefutatni (tipikusan cron-ból idő-zítve). Ily módon futatva az ntpdate-et, a gép szépen lassan „hozzákésik/hozzásiet” a központi időhöz. Komplexebb konfgurációt igényel az ntpd (régebben xntpd) nevű szofver, amely elindítá-sa után folyamatoelindítá-san fut, és rendszeresen (alapesetben 64 másodpercenként, ez 16 másodperc és 36,4 óra közöt változtatható) lekérdezi a pontos időt, majd az előbb tárgyalt módon, a gép belső órájának felgyorsításával / lelassításával hozza összhangba a gép óráját a külvilágéval. Működésé-hez viszont szükséges létrehozni egy konfgurációs fájlt (tipikusan /etc/ntp.conf néven létezik), amelyben minimálisan a lekérdezendő szerver(ek) nevét kell megadni, „server time.kfi.hu” for-mában. Nem árt tudni, hogy jó pár szofver (például a Dovecot IMAP-szerver, vagy általában az adatbázis-kezelők) rendkívül zokon veszi az „időugrást” – ezek miat szintén nem javasolt az a faj-ta óraállítás.
Megjegyzendő, hogy az óra folyamatos szinkronban tartásának két módja (ntpdate -B illetve ntpd) biztonsági szempontból is különbözik. Az ntpdate használatakor csak a parancs futatásakor lesz egy rövid ideig tartó hálózati forgalom, míg ntpd használata esetén az ntpd szerverprogram folya-matosan fut, és a 123-as UDP porton keresztül elérhető. Természetesen ez utóbbi használat esetén van lehetőség az engedélyezet kliensek korlátozására.
Egy szerver alapvető beállításai