Read-only_filerendszer

Szkriptek: Python, Perl, Bash, ...

Sziasztok!

Olyan kérdéssel fordulok hozzátok, hogy lenne-e ötletek annak megoldására, hogy minél előbb észrevegyem ha a file rendszerem valamelyik gépen átáll read-only-ra. Pár hét alatt két szerver is volt amelyikben tönkrement a winchester és átállt read-only-ra, jó lett volna, ha mondjuk egyből kapok ilyenkor egy emailt, de bármilyen más megoldás érdekel.

  • 1385 megtekintés

( janoszen v | 2011. 09. 05., h – 12:50 )

Sztem, amire Te vágysz, az egy logmonitorozó szoftver. A logokban ugyanis benne lesz, ha valami bekakil. Ha több szervert üzemeltetsz, nyilván célszerű központi syslog szervert is csinálni, akkor a gép meggebedése nem érinti a logokat.

Gondoltam én is ilyenre, hogy mondjuk touch-al bizonyos időkönként tesztelgetem, de akkor megint nem azonnal veszem észre.

A syslog szerver jó ötlet, azt kell csak kipróbálnom, hogy mi van ha mondjuk nem tud logolni hálózati hiba miatt, akkor ez miatt nem lesz-e read-only.

Nem touch, hanem syslog-ot nyálazod per komplette folyamatában, és ha a "rídonli lett a fájlrendszer" string szerepel benne, akkor xyz tevékenységet (pl. e-mail, sms küldése, akármi) végző scriptet lefuttat és kész.

Én mondjuk megkerülném a problémát azzal, hogy RAID10-et raknék a cumó alá, és a raid állapotát monitoroznám.

Az a baj, hogy mar nem tudja kiirni a logba, hogy "readonly lett a fajlrendszer", mert readonly lett a fajlrendszer. En inkabb a 

/proc/mounts

-ot olvasgatnam egy szkripttel.

Az egy masik erdekes kerdes, hogy hogyan tud ertesitest kuldeni, mert az MTA szinte biztos nem fog mukodni readonly fajlrendszerrel.

Miért kéne kiírni bármit is a fájlrendszerbe? A syslog-ng "röptében" csócsálhatja a logot

Nem kell, sot valoszinuleg nem is lehet majd. Viszont ahogy elnezem, az 

errors=remount-ro

opciot minden filerendszer sajat maga kezeli, tehat elkepzelheto, hogy a logba is mindegyik masfelekeppen irja majd bele. Akkor mar inkabb a 

/proc/mounts

olvasgatasa szkripttel.

A levélküldést meg meg lehet oldani nc-vel is :-P

Akkor mar inkabb 

ssmtp

(bar nem tudom, hogy akar-e irni a diszkre, gyanitom, hogy nem).

( gyorik v | 2011. 09. 05., h – 17:52 )

Én inkább a smartctl/hdsentinel kimenetét dolgoznám fel egy scripttel(így is csinálom egyébként). Amikor a legapróbb hibát észreveszem a diszkekkel kapcsolatban, azonnal cserélem a bűnösöket.

( uid_2716 | 2011. 09. 05., h – 18:40 )

Nem azonosítottad az fs-t, de ha ext2-származék, akkor a tune2fs-sel átállíthatod az "error behavior"-t (

-e

kapcsoló) "panic"-ra. (Ezt mount opcióval is megteheted a superblock módosítása nélkül, csak az adott mount idejére, a 

errors=panic

opcióval.) A panic egyrészt szintén nem fog továbbí írást engedélyezni a diszkre, másrészt garantáltan észre fogod venni, mert égni fognak a telefonvonalak :)

( Fisher v | 2011. 09. 05., h – 18:53 )

Én inkább csinálnék valami rendes monitoringot, ami akár jelezhetné is a hibát.

Nomeg mirrort az egy disk helyett.

Köszönöm a segítséget, a raid lesz a legegyszerűbb megoldás, végül is ott is be tudom állítani az email küldést ha elszáll valamelyik vinyó. Bár vannak olyan szerverek amelyek nem annyira fontosak a hálózatban vagy problémás lenne megoldani, csak azért is kérdeztem meg itt, mert habár be tudtam ssh-ni de egy uptime parancsot nem engedett lefuttatni, ezért is gondoltam, hogy ha már read-only akkor lehet problémás akár egy scriptet is futtatni.