http://futurist.se/gldt/, Via Sysadmins Life

Würde sich doch bestimmt gut bei uns im Hackerspace machen

Ein Plugin ist schnell gefunden, da Icinga von Nagios abstammt: check_md_raid.
Die Installation des Plugins ist, wenn man schonmal Plugins installiert hat, sehr einfach. Man sollte aber noch eine Kleinigkeit anpassen, dazu später mehr. Zuerst kopiert man das Plugin zu den anderen und macht es ausführbar, normalerweise hierhin:

/usr/local/icinga/libexec

Dann muß man es noch in die commands.cfg und in die entsprechende Serverdatei eintragen. Bei mir ist das localhost, also localhost.cfg. Beide Dateien befinden sich im etc/objects Verzeichnis von Icinga. Mein localhost.cfg Eintrag sieht so aus:

define service{
        use                             local-service
        host_name                       localhost
        service_description             Raid
        check_command                   check_md_raid
        }

Das Skript benötigt keine Eingabeparameter. commands.cfg:

define command{
        command_name    check_md_raid
        command_line    $USER1$/sudo /usr/local/icinga/libexec/check_md_raid
}

Es gibt allerdings viele Möglichkeiten wie das aussehen könnte. Da das Script Root-Rechte benötigt (resp. der Aufruf von mdadm), kann man sudo benutzen um das Problem zu lösen. Ich rufe dabei das gesamte Skript mit Root-rechten auf, so wie es auch gedacht ist. Werft mal einen Blick hinein.

Man könnte aber natürlich auch das Skript verändern und nur den Aufruf von mdadm selbst mit administrativen Privilegien gestatten. Ich habs mir aber einfach gemacht . Natürlich braucht man dann auch einen Eintrag in der /etc/sudoers. Diesen kann man z.b. mit visudo hinzufügen. In meinem Fall:

icinga  ALL = NOPASSWD: /usr/local/icinga/libexec/check_md_raid

Wenn man diesen Weg wählt muß man natürlich dafür sorgen dass check_md_raid nicht von normalen Usern (auch nicht von Icinga) verändert werden kann. Das wäre sonst ein riesiges Sicherheitsrisiko.

Funktioniert das soweit kann man Icinga neustarten und im Browser aufrufen. Der Status sollte bereits korrekt angezeigt werden, jedoch steht was in der Statuszeile was dort nicht hingehört:

mdadm: metadata format 00.90 unknown, ignored.
mdadm: metadata format 00.90 unknown, ignored.

Es handelt sich hierbei um einen kleinen Bug, der auftritt da das Format in dem die Informationen über das Metadaten-Format geändert wurde. So zu sagen Meta-meta Daten Eliminiert kriegt man diese Meldung indem man in der

/etc/mdadm/mdadm.conf

eine Kleinigkeit ändert. So wird

metadata=00.90

zu

metadata=0.90

Ihr solltet nun funktionierendes Raid-Monitoring haben:

Ich hatte das gestern, als ich den Testserver herunterfahren wollte. Erwischt hab ich den Mailserver. Ouch! Also hab ich mich auf die Suche nach Möglichkeiten gemacht sowas in Zukunft zu vermeiden. Gefunden habe ich Molly-Guard.

Ein Molly-Guard ist normalerweise ein Schutz vor dem Netzschalter eines Servers. Er schützt vor dem unbeabsichtigten ausschalten des selben. Dieses kleine Script macht das gleiche in Software. Bei Debian Lenny z.b. ist es in den Repositories.

1

apt-get install molly-guard

Wenn man dann versucht den Server neuzustarten oder herunterzufahren muss man den richtigen hostnamen eingeben. Wenn nicht, sieht das so aus:

1
2
3
4
5
6

sapsop:~# shutdown -h now
W: molly-guard: SSH session detected!
Please type in hostname of the machine to shutdown: $someServer
Good thing I asked; I won't shutdown sapsop ...
W: aborting shutdown due to 30-query-hostname exiting with code 1.
sapsop:~#

Das Paket macht nichts anderes als einen Symlink für shutdown,halt,poweroff und reboot unter /usr/sbin/ anzulegen. Diese Zeigen auf das Molly-Script unter /usr/share/molly-guard/shutdown.
Natürlich sollte man weiterhin die Augen offen halten und sich nicht blind darauf verlassen dass molly-guard einem den Arsch rettet. Früher oder später stösst man auf einen Server der das nicht installiert hat und Zack hat man den Salat.

Da ich mein Webmail sowieso nicht oft benutze, und außerdem noch Horde habe ist das mir sehr lange nicht aufgefallen. Und ich wußte auch nicht mehr wirklich was ich geändert haben könnte.Backup-Roulette kam auch nicht in Frage . Also flugs auf den Server gessh’d, und die Apache Logs durchwühlt. Segmentation fault. Eine gefürchtete, und noch unaussagekräftigere Fehlermeldung. Jedesmal wenn ich Roundcube öffnen wollte, ging ein Child über den Jordan.

Nach langem Testen und Suchen fand ich dann die “Lösung”: Ich hab einfach mal den eAccelerator Cache geleert, und hab mich gefreut. Es funktionierte. Ein mal. Argh.. Jetzt hab ich den eAccelerator bis auf weiteres deaktiviert. So als Workaround, bis ich den Auslöser al gefunden hab. Sollte ich mir doch jede Änderung am System notieren? So ne Art Changelog vielleicht?

Danke an das Debian Team für diese grandiose Distribution.

Ein klick auf “Details” offenbart folgendes:

“RuntimeFault: Database temporarily unavailable or has network problems.”

Hä? Sonst hat das doch immer funktioniert, dachte ich. Nur war sonst auch nur ein Mal. Und dazu noch so eine unheimlich aussagekräftige Fehlermeldung. Juhu.
Bei der einen VM und dem einen Benutzer funktionierts, bei allen anderen nicht. Die Logs gaben auch nichts sehr aufschlußreiches. Nach kurzem Googlen fand ich allerdings eine sehr einfache und ebenso effektive Lösung für das Problem.

Zuerst stoppt man VMware Management.

1

/etc/init.d/vmware-mgmt stop

Dann editiert man die Datei /etc/vmware/hostd/authorization.xml als root.

Dort sucht man nach einer Stelle die so aussieht:

1

<nextAceId>11</nextAceId>

Wenn man die Stelle gefunden hat, inkrementiert man die 11 z.b. um 1. Man kann allerdings auch höhere Werte verwenden. Danach siehts z.b. so aus:

1

<nextAceId>12</nextAceId>

Das wars eigentlich schon. Ich hab außerdem <NextRoleId>11</NextRoleId> noch auskommentiert, da es anscheinend nirgendwo verwendet wird. Nun nur noch VMware Management wieder starten und sich freuen dass man Rechte vergeben kann. Warum das allerdings so ist kann ich nicht sagen. Vielleicht ein Bug?

Nach einiger zeit, als der Opera DS Browser rauskam, mußte ich doch zuschlagen. Wifi? – So billig mit Touchscreen? JA! Im Endeffekt hat mich das Teil 40 Euro gekostet, und ich hab es nur ein paar mal benutzt. Unter anderem um eine miese E-bay Transaktion durchzuführen, die etwa 200 Euro gekostet hat

Naja wie auch immer, ich hab mir von meiner Freundin zu Weihnachten ein CycloDS gewünscht. Eigentlich hatte ich es schon bestellt, und es geschickt als Weihnachtsgeschenk hingestellt. Jetzt hab ichs, und bin vollends zufrieden! Meine erste Amtshandlung war natürlich Linux da drauf zu kriegen. Kein Problem, denn wie liest man so schön in den Foren: “Unix runs on pretty much everything!” Das kann ich vollends bestätigen. Und dass ich den Opera Browser gekauft hab, war dann doch nicht umsonst. Un Linux benutzbarer zu machen braucht man nämlich noch extra Ram. Der DS hat 4 mb eingebaut, und mit dem Browser kamen nochmal 8 mb.


Es gibt ein Projekt namens DSLinux, das das Ziel hat Linux auf die arm Prozessor-architektur zu portieren. …Und es auch ziemlich gut hingekriegt hat. Jetzt könnte ich natürlich ein fertiges DSLinux nehmen, doch ich wollte es selber kompilieren. Das ist einfach nerdiger. Sonst würde es ja gar keinen Spaß machen… Also flux mit Subversion ausgecheckt, Toolchain installiert und freudig drauf los kompiliert. – Heraus kam ein ziemlich geiles Linux für den DS! Leider wird das Projekt nicht mehr aktiv weiterentwickelt. Da kommt wohl noch ne Menge Arbeit auf mich zu. – Schöne Arbeit.


Ich kann das nur empfehlen, endlich einen Handheld wo Linux drauf läuft und mit dem man noch so nebenbei spielen kann! Übrigens finde ich es super dass ich sehr sehr viele Spiele auf einer Mikro-SD speichern kann (Mit Originalkopie of course!). Wenn ich die original Karten nehmen würde, müßte ich immer haufenweise Karten mitschleppen. Zumal die Roms ja im Verhältniss zur Kartengröße ziemlich klein sind.


Ich werde morgen noch ein paar Fotos und Screenshots machen, heute ist leider der Akku des Fototeils leer. Das passiert einem eben immer dann wenn man es nicht gebrauchen kann…