http://icinga-html-mail-template.googlecode.com/files/icinga_mail.pl

0.2.1a -> LASTSERVICEINKNOWN fixed and changed to LASTSERVICEUNKNOWN

Der Dank geht an Simon Meggle für finden und melden.

Wessen Icinga-Web bei der Auswahl der Servicegroup-Reports so ausschaut und wer folgende Zeilen dazu im Logifle hat

[Fri Feb 1 10:50:50 2013] [fatal] Uncaught AppKitPHPError: PHP Error array_key_exists() expects parameter 2 to be array, null given (/usr/local/icinga-web/app/modules/Reporting/models/JasperParameterStructModel.class.php:136) (/usr/local/icinga-web/app/modules/AppKit/lib/logging/AppKitExceptionHandler.class.php:59) 
[Fri Feb 1 10:50:50 2013] [fatal] Uncaught AppKitPHPError: PHP Error array_key_exists() expects parameter 2 to be array, null given (/usr/local/icinga-web/app/modules/Reporting/models/JasperParameterStructModel.class.php:136) (/usr/local/icinga-web/app/modules/AppKit/lib/logging/AppKitExceptionHandler.class.php:59)

der muss seine Datei

/usr/local/icinga-web/app/modules/Reporting/config/module.xml

patchen.
In Icinga-1.8.1 und in den Versionen davor, so ich es gesehen habe, fehlt der Block

ae:parameter name="p_servicegroup_object_id">
<ae:parameter name="className">Icinga.Reporting.inputControl.ApiSelectionField</ae:parameter>
<ae:parameter name="target">servicegroup</ae:parameter>
<ae:parameter name="columns">
<ae:parameter>SERVICEGROUP_OBJECT_ID</ae:parameter>
<ae:parameter>SERVICEGROUP_NAME</ae:parameter>
</ae:parameter>
<ae:parameter name="valueField">SERVICEGROUP_OBJECT_ID</ae:parameter>
<ae:parameter name="displayField">SERVICEGROUP_NAME</ae:parameter>
</ae:parameter>

Dies führt dazu, dass beim Aufruf des Reports aus Icinga keine Variablen übergeben werden und der oben genannte Fehler im Icinga-Web Log auftaucht.

Der Patch dazu sieht folgendermaßen aus:

--- module.xml    2013-02-01 11:03:02.000000000 +0100
+++ module_neu.xml    2013-02-01 11:04:28.000000000 +0100
@@ -99,6 +99,16 @@
                         <ae:parameter name="displayField">SERVICE_NAME</ae:parameter>
                         <ae:parameter name="tpl"><![CDATA[{HOST_NAME} - {SERVICE_NAME}]]></ae:parameter>
                     </ae:parameter>
+            <ae:parameter name="p_servicegroup_object_id">
+            <ae:parameter name="className">Icinga.Reporting.inputControl.ApiSelectionField</ae:parameter>
+            <ae:parameter name="target">servicegroup</ae:parameter>
+            <ae:parameter name="columns">
+            <ae:parameter>SERVICEGROUP_OBJECT_ID</ae:parameter>
+            <ae:parameter>SERVICEGROUP_ALIAS</ae:parameter>
+            </ae:parameter>
+            <ae:parameter name="valueField">SERVICEGROUP_OBJECT_ID</ae:parameter>
+            <ae:parameter name="displayField">SERVICEGROUP_ALIAS</ae:parameter>
+            </ae:parameter>
                 </setting>

                 <!-- Mapping for datatypes e.g. 4 == Date -->		    

Ein offizieller Fix ist wohl in Icinga 1.8.3 enthalten. Der Bug-Report dazu ist hier zu finden:

https://dev.icinga.org/issues/3503

Die Anleitung wurde mit einem iPhone 3 und 4 getestet und funktioniert.

Aktivierung “Restore mode” am iPhone

1. Das iPhone an den PC (USB) anschließen und iTunes öffnen
2. Power-Button (oben) und Home-Button (unten) gedrückt halten
3. Die Knöpfe gedrückt halten, damit das iPhone einen Neustart durchführt (Bildschirm schwarz)
4. Erst wenn das Apfel-Logo erscheint, den Power-Button (oben) loslassen. Den Home-Button (unten) weiterhin gedrückt halten.
5. Nach ein paar Sekunden (~ 10) sollte jetzt ein iTunes- und ein Connector-Symbol zu sehen sein.
6. Jetzt sollte es in Windows Bing machen und die Installation der Gerätetreiber beginnen.
7. Ist die Installation beendet, meldet iTunes, dass ein iPhone zur Wiederherstellung gefunden wurde. Nach dem bestätigen wird wieder die originale Apple Firmware geladen.

Voilà … Never touch a running closed source system …

Das folgende Skript bietet weder einen 100%igen Schutz noch kann es in allen Fällen einen Zugriff auf das System entdecken. Es bietet aber einen gute Basis um im Fall der Fälle vielleicht doch eine E-Mail zu bekommen um schnell zu reagieren.

Ich versuche mal die Einrichtung des Skripts anhand eines Debian-Servers und meiner QNAP zu beschreiben. In beiden Fällen funktioniert es bei mir problemlos. Kombiniert mit einem Dienst wie z.B. ifttt.com lassen sich aus den Mails auch SMS oder Telefonanrufe generieren.

Debian

Die Einrichtung unter Debian geht ziemlich einfach von statten. Normalerweise sollten alle benötigten Pakete (postfix, bsd-mailx) bereits installiert und funktionsfähig sein. Wenn nicht, kann auch die folgende Installation der QNAP mit nail als Mailer herangezogen werden.
Mehr Informationen zum einrichten eines Mail-Servers unter Debian gibts z.B. hier:

http://wiki.ubuntuusers.de/Postfix

Im ersten Schritt wird ein Skript welches die benötigten Informationen sammelt irgendwo im Filesystem abgelegt. Für dieses Beispiel hier nennen wir das Skript einfachmal “alert.sh” und legen es nach “/usr/local/bin/”

#!/bin/bash
echo "Login detected at $(hostname) / $(date +%d.%m.%Y) $(date +%H:%M:%S)"
FROM=`echo $SSH_CONNECTION | awk '{ print $1 }'`
echo "Benutzer: $USER@$FROM"
echo
echo -n "Uptime: "
uptime
echo
echo "Last Login Activity: "
last
echo
echo "Logged in Users: "
finger

Wer möchte kann dieses Skript natürlich nach seinen Wünschen anpassen und verbessern.
Das Skript bekommt jetzt noch die passenden Rechte, damit es auch jeder Benutzer beim Login ausführen kann.

chmod 755 /usr/local/bin/alert.sh

Im “Normalfall” werden bei jedem Login die Profil-Daten gelesen. Erste Anlaufstelle ist meistens die /etc/profile. Genau da setzt der 2.Schritt dann an. Die Datei /etc/profile wird um folgendes erweitert:

...
# send mail on successful login
/usr/local/bin/alert.sh | mailx -s "SSH Login at $(hostname) detected" mail@domain.de
...

QNAP

Auch auf den QNAP-Systemen lässt sich dieser Schritt vollziehen. Das Skript fällt an dieser Stelle aber etwas kürzer aus, da die Busybox der QNAP ziemlich sparsam bestückt ist und das IPKG-Paket z.B. Dinge wie “finger” oder “last” nicht mitliefert.
Zuallererst brauchen wir auf der QNAP einen mailer. Hier bietet sich im Gegensatz zum Debian-Server nail an. nail kommt als IPKG-Paket mit und kann einfach angepasst werden.

ipkg install nail

Das Skript selbst kommt hier in einer minimalen Version

#!/bin/bash
echo "Login detected at $(hostname) / $(date +%d.%m.%Y) $(date +%H:%M:%S)"
FROM=`echo $SSH_CONNECTION | awk '{ print $1 }'`
echo "Benutzer: $USER @ $FROM"
echo
echo -n "Uptime: "
uptime

Der Schritt mit der /etc/profile ist auch hier identisch, mit der Ausnahme, dass der Mailer mailx durch nail ersetzt wird.

# send mail on successful login
/opt/bin/catch | nail -s "SSH Login at $(hostname) detected" mail@domain.de

Damit nail auch noch ohne MTA den passenden Mailserver findet, kann dieser in der /opt/etc/nail.rc eingetragen werden:

...
set smtp=smtp://smtp.domain.de
set from="qnap@domain.de (QNAP <MODELL>)"
set smtp-auth=login
set smtp-auth-user=qnap
set smtp-auth-password=blubber123
...

Anschließend auch hier noch das Skript mit den passenden Rechten versorgen

chmod 775 /opt/bin/alert.sh

ACHTUNG

Wie gesagt. Das Skript bietet nur rudimentäre Sicherheit. Es geht an dieser Stelle nichts über eine sinnvolle Härtung des Systems und sicheren Passwörtern oder Schlüsseln.
Trotzdem bietet das Skript zumindest einen kleinen Informationswert und funktioniert auch bei Logins in virtuellen Umgebungen (z.B. “vzctl enter <vid> (OpenVZ)” oder “vserver <vid> enter”).
Erfolgt der Zugriff allerdings direkt auf das Filesystem, in dem z.B . über den Root-Server
auf das Verzeichnis oder Volume zugegriffen wird, passiert gar nichts.

hpasmcli -s "SET BOOT ONCE PXE"

Natürlich stehen auch andere Optionen noch zur Verfügung

	 SET BOOT FIRST [ CDROM | FLOPPY | HDD | PXE | USBKEY ]
	 SET BOOT ONCE [ CDROM | FLOPPY | HDD | PXE | RBSU ]

“Slave”

Smart Array P410i in Slot 0 (Embedded)
 
   array A
 
      physicaldrive 1I:1:1 (port 1I:box 1:bay 1, SAS, 300 GB, OK)
      physicaldrive 2I:1:5 (port 2I:box 1:bay 5, SAS, 300 GB, OK)

“Master”

Smart Array P400 in Slot 1
 
   array A
 
      physicaldrive 1I:1:5 (port 1I:box 1:bay 5, SAS, 146 GB, OK)
      physicaldrive 1I:1:6 (port 1I:box 1:bay 6, SAS, 146 GB, OK)
      physicaldrive 1I:1:7 (port 1I:box 1:bay 7, SAS, 146 GB, OK)
      physicaldrive 1I:1:8 (port 1I:box 1:bay 8, SAS, 146 GB, OK)
      physicaldrive 2I:1:1 (port 2I:box 1:bay 1, SAS, 146 GB, OK)
      physicaldrive 2I:1:2 (port 2I:box 1:bay 2, SAS, 146 GB, OK)
      physicaldrive 2I:1:3 (port 2I:box 1:bay 3, SAS, 146 GB, OK)
      physicaldrive 2I:1:4 (port 2I:box 1:bay 4, SAS, 146 GB, OK)

Was mit der Check-Latency passiert, wenn jetzt unbemerkt ein Switch der Writer-Adresse auf das eigentliche Slave-System passiert, kann man hier erkennen:

Deutlich wird das Dillema, da gleichzeitig mit dem Anstieg der Latency die Inserts in der Datenbank drastisch zurückgehen.

Beim Switch auf das leistungsschwächere System (2 Platten im RAID10-Verbund) reduziert sich die Anzahl der maximalen Inserts von ursprünglich konstanten 240 Inserts/Sekunde auf einen Wert zwischen 40 und maximal 120 Inserts/Sekunde.
Dies bedeutet eine Änderungen von den bisherigen ca. 7 Sekunden Check-Latency auf einen Wert um die 300 Sekunden.

Wir haben es jetzt sicherheitshalber einfach mal wieder zurückgestellt, da uns die Check-Latency von knapp 7 Sekunden im Schnitt besser gefällt.

Beschreibung