CC::Blog

Wem Nagios schon immer etwas zu komplex zum konfigurieren war, der versuche sich doch mal an Monit.
Das Teil muss zwar auf jedem einzelnen Rechner laufen, den es Monitoren soll, und es hat auch nicht ganz so viele Einstellungen wie Nagios, aber es kann Prozesse, TCP-Ports, ICMP-Pings uvm. monitoren und sogar bei bedarf von alleine restarten.
Zusätzlich informiert es einen per Mail was so gerade passiert. Als Extra-Bonbon gibt es ein (minimalistisches) Webinterface das einen schnell und zuverlässig über den Gesundheitszustand des zu monitorenden Rechners informiert.
Ist auf jeden Fall einen Blick wert, das Tool…

Wer schon immer mal überzeugende Argumente GEGEN php suchte, ist bei helmboldt.de richtig aufgehoben. Wusste garnicht das PHP soooo (!) gruselig ist…

gefunden bei roothausen.de

Update: Unter verplant.org gibt es einen objektiven Vergleich zwischen Perl und PHP – in jedem Falle Lesenswert

Angenommen man möchte unter Linux ein Script / Programm abfeuern lassen, sobald ein File in einem Directory abgelegt wird. Wenn man z.B. ein Spoolverzeichnis bauen will, könnte das recht hilfreich sein.
Die Lösung bieten die “inotify-tools”. Flux per “apt-get install inotify-tools” installiert, verfügt man anschliessend über zwei Programme, mit den hübschen Namen inotifywait und inotifywatch.
Diese sind gemäss manpage zu bedienen. Hier ein kleines Beispiel:

Situation: Sobald Im Directory “/spool” eine Datei abgelegt und final geschlossen wird, soll ein kleines Perl-Script aufgerufen werden, dass die Datei verarbeitet. Als Parameter sollen dem Script das Directory sowie die Datei zur Verfügung gestellt werden.
So gehts:

#!/bin/sh
inotifywait -mrq -e close_write /spool/ –format ‘%w %f’ |while read dir file; do
./perlscript.pl ${dir} ${file}
done

Hier eine Erklärung der, im Beispiel benutzten, Schalter / Variablen:
-m = Monitored das Directorie kontinuierlich – ohne den Schalter hört inotifywatch nach dem ersten “Trigger” auf zu laufen
-r = Subdirectories sollen auch gemonitored werden
-q = Das Tool soll “Quiet” laufen – also keinerlei unnötiges “gedöns” ausgeben

%w = Filename mit Directory
%f = Filename

Viel Spass damit

[Update]: Leider funktioniert das ganze nicht mit Directories auf die ein Samba-Share gemounted wurde…

Ein schickes Board das fein mit Debian läuft ist das Gigabyte GA-X38-DQ6. Allerdings hat das gute Stück einen Schönheitsfehler. Unter Debian Etch werden funktionieren das Hardwaremonitoring nicht. Hier kann Abhilfe geschaffen werden. Auf dem Board befindet sich der it8718-isa-0290 Chip(satz) der für die Environmentdaten zuständig ist. Dummerweise wird der Chip erst ab Kernel 2.6.20 über das Kernelmodule “coretemp” unterstützt. Debian Etch selbst verwendet aber als letzten Kernel den 2.6.18er. Also updaten ! Wie geht das ? Wie folgt:

in der /etc/apt/sources.list folgende Zeile hinzufügen:

deb http://www.backports.org/debian etch-backports main contrib non-free

Nun via apt-get update die Quellen aktualisieren. Und anschliessend per apt-get install linux-image-2.6.22-xxx  (wobei xxx der Architektur entspricht die man sich wünscht) den neuen Kernel installieren.
Ein wenig Vorsicht ist allerdings geboten, wenn man sich vorher selbst einen (älteren) Kernel gebacken hat, hier sollte man die Sourcen mitinstallieren, und den 2.6.22er dann auch neu basteln.

Nach dem neu gebootet worden ist kann man sich per apt-get install lm-sensors das sensors Packet installieren. Von nun an ist es nicht mehr weit 😉
Folgende Zeilen gehören nach einem sensors-detect in die /etc/sensors3.conf:

chip “it8718-*”

# Voltages

compute in3 @ * (6.8/10+1), @ / (6.8/10+1)
compute in7 @ * ( 30/10+1), @ / ( 30/10+1)

label in0 “VCore”
label in1 “VDDR”
label in2 “+3.3V” # VCC3
label in3 “+5 V VCC” # VCC
ignore in4
ignore in5
ignore in6
label in7 “+12V” # VCCH
label in8 “VBat”
label fan1 “CPUFan”
label fan2 “FrontFan”
label fan2 “XXX Fan ?”
label temp1 “NB Temp”
label temp2 “Coretemp”
ignore temp3

set in0_min vid * 0.95
set in0_max vid * 1.05
set in1_min 1.8 * 0.95
set in1_max 1.8 * 1.05
set in2_min 3.3 * 0.95
set in2_max 3.3 * 1.05
set in3_min 5 * 0.95
set in3_max 5 * 1.05
set in7_min 12 * 0.95
set in7_max 12 * 1.05

ignore cpu0_vid

Danach sollte ein Aufruf von sensors ein paar Werte ausspucken. Wer richtig mitgelesen hat, dem fält auf, dass ich noch keine genaue Bezeichnung fuer Fan3 finden konnte. Wenn jemand an der Stelle weiterkommt – gerne per Kommentar…. Bis auf Fan3 wird dann aber auch alles vernünftig angezeigt.

Viel Spass

Alles nicht so einfach mit den Platten. Daher hier ein weiteres Mini-Howto. Diesesmal zum Thema, wie erstelle ich unter LINUX einen Soft-RAID-Verbund, der sich beliebig erweitern lässt.

Ausgangssituation wäre folgende:
3 Eingebaute Festplatten:
hda: Boot-Platte (XXX GB)
hdb: 1. RAID1-Platte (1GB – lässt sich leichter rechnen 😉
hdc: 2. RAID1-Platte (1GB)

1. Mithilfe von fdisk / cfdisk die Partitionen /dev/hdc1 und /dev/hdb1 auf den jeweiligen Platten als Primärpartition vom Typ FD erstellen.

2. Raid 1 aus hdb1 und hdc1 anlegen:

mdadm –create /dev/md1 –level 1 –raid-devices=2 /dev/hdb1 /dev/hdc1

3. Physical Volume anlegen:

pvcreate /dev/md1

4. Volume Group anlegen (mit einem Device) – vol ist hier mal der Name der Gruppe

vgcreate vol /dev/md1

5. Logisches Volume mit Namen “root” auf der VolumeGroup anlegen (Wir nehmen mal 800MB, da ein wenig Overhead anfaellt – 900 sollten aber auch gehen)

lvcreate -n root -L 800M vol

6. Filesystem auf dem neuen Volume anlegen

mkfs.ext3 /dev/vol/root

7. Mounten:

mount /dev/vol/root /mnt

8. Ueberpruefen
– PhysicalVolumes lassen sich mit pvdisplay, VolumeGroups mit vgdisplay und LogicalVolumes mit lvdisplay anzeigen
– Ein “df . -h” bringt nun 800 MB auf die Waage

Fertig …

Wenn man nun eine weitere Platte (Raid-Volume über mdadm geht natürlich auch) “hinzubekommt” und die an das RAID-1 stripen möchte, geht das wie folgt:
(Wir nennen die Platte mal hdd)

1. Primary Partition über FDISK anlegen (Typ FD)

2. Physical Volume anlegen:

pvcreate /dev/hdd1

3. VolumeGroup erweitern:

vgextend vol /dev/hdd1

4. LogicalVolume erweitern

lvextend /dev/vol/root -L +800M /dev/hdd1

5. Überprüfen (siehe oben)
– Ein “df . -h” in /mnt bringt nun einen um 800MB erweiterten Mountpunkt zum vorschein. Halt … wohl doch noch nicht. Dem Filesystem muss erst noch mitgeteilt werden dass hier eine Grössenänderung stattgefunden hat. Also:

6. Filesystem umounten:

umount /mnt

7. Filesystem überprüfen (sonst motzt der Resizer)

fsck.ext3 -vv -f /dev/vol/root

8. Fileystem schliesslich resizen

resize2fs /dev/vol/root

9. Wieder mounten

mount /dev/vol/root /mnt

10.Jetzt haben wir es geschafft…

Allen die “mal eben schnell” ein Backup benötigen, sei Netcat in Verbindung mit tar ans Herz gelegt. Die Methode ist alt, da ich aber dennoch immer suchen muss wie man tar jetzt zu stdout bewegt, sei das ganze hier noch einmal aufgeführt:

Auf dem Zielrechner (der das Backup entgegennimmt):
netcat -vvl -p 9988 >./[Backupdateiname].tar

Auf dem Quellrechner (von dem das Backup gezogen werden soll):
tar cv – . | netcat [Server-IP] 9988

Achja, evtl. muss so ein Backup ja auch mal restored werden 😉 Dann wie folgt:

Auf dem Zielrechner (wo das Backup wieder eingespielt werden soll):
netcat -vvl -p 9988 |tar -xv

Auf dem Quellrechner (wo das Backup liegt):
cat [Backupdateiname].tar |netcat [Server-IP] 9988

Bei Bedarf kann man das ganze noch mit “z” zum on-the-fly-Zippen oder mit –exclude tunen…
Und nun – viel Spass beim Backuppen

[Update 10.11]: Für alle die es ganz genau wissen wollen: Bei der Rhoener Linux User Group gibts ein feines Tutorial

ImageMagick ist fein, das hatten wir hier im Blog ja schon. Allerdings bedient es sich beim Konvertieren von Bildern, PDFs oder sonstigem Krams des random-Devices unter Linux. Und das kann mit unter sehr imperformant sein. Allerdings gibt es Abhilfe. Der Schalter “-seed n” teilt dem convert nämlich mit, das es statt der Zufallszahlen einfach nur die “1” nehmen soll. Problem gelöst. Jetzt rennt convert wieder und muss nicht ewig auf das Random-Device warten.

…Und ich war schon am überlegen ob man nicht /dev/urandom nehmen könnte.