Aufgrund eines “kleinen” Schreibfehlers gibt es einen Patch der Mail-Extension für Icinga:
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
Weil ich gerade ein nicht richtig funktionierendes iPhone von einem der vielen Mods “befreien” musste.
Die Anleitung wurde mit einem iPhone 3 und 4 getestet und funktioniert.
Aktivierung “Restore mode” am iPhone
Voilà … Never touch a running closed source system …
Mal wieder ein bisschen Tech-Stuff zur Abwechslung.
Viele kennen vermutlich das ungute Gefühl, wenn man einen Server mit aktiviertem SSH-Login im Internet hängen hat. Man weiß trotz Absicherung der SSH-Konfiguration und dem Einsatz von Fail2Ban oder ähnlichem nie genau, ob nicht doch irgendwo etwas schief geht. Ein etwas ungutes Gefühl hinterlassen stellenweise auch so genannte VServer welche bei diversen Unternehmen bezogen werden können.
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.
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 ... |
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 |
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.
Wird mal wieder Zeit für ein bisschen Mountainbike fahren. Das Wetter passt ja … 
Manchmal ist es nützlich, wenn man einem HP Proliant Server einfach sagen kann, dass er beim nächsten Boot per PXE booten soll. Gerade wenn man ein Firmware-Update per PXE einspielen will, erleichtert das die Arbeit ungemein, da man nicht mehr den Zeitpunkt für die Eingabe von F11 oder F12 im Boot-Screen abwarten muss.
Der Server bootet also per PXE die Firmware, aktualisiert sich und bootet anschließend wieder normal per HDD. Feine Sache …
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 ] |
Wir haben ein Problem. Besser gesagt, wir hatten ein Problem. Seit einiger Zeit stieg die Latency in unserem Icinga-System kontinuierlich an. Zuerst hatten wir das Upgrade auf die Version 1.8.0 ein Stück weit im Verdacht. Mittlerweile hat sich aber herausgestellt, dass die Performance der Datenbank eine unmittelbare Auswirkung auf die Performance des gesamten Icinga-Systems hat.
Um das genauer zu erklären, muss erwähnt werden, dass wir für unsere Produktionsumgebung aus “Sicherheitsgründen” eine MySQL-Multi-Master Replikation einsetzen. Verwaltet wird diese Replikation über den Multi-Master Replication Manager
Dieser sorgt dafür, dass eine Writer-Rolle und 2 Reader-Rollen immer passend über 2 Datenbanken gemappt werden. Zusätzlich wir damit vermieden, dass gleichzeitig in beide Datenbank geschrieben werden kann. Da wir den “Slave” bewusst nur für den Notfall ausgelegt haben, verfügt dieser natürlich nicht mal annähernd über die Ressourcen des eigentlichen Master-Systems:
“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.
https://dev.icinga.org/issues/3313
Beschreibung
Configure of icinga-reports-1.8.0 throws the following error:
root@localhost:/usr/src/icinga-reports-1.8.0# ./configure –with-jasper-server=/opt/jasperreports-server-cp-4.7.0
./configure: line 1682: AM_INIT_AUTOMAKE: command not found
checking build system type… x86_64-unknown-linux-gnu
checking host system type… x86_64-unknown-linux-gnu
checking for jasperserver… configure: creating ./config.status
config.status: creating MakefileThe fix provided in Bug #2623 works here too -> https://git.icinga.org/?p=icinga-reports.git;a=commit;h=c4e2d2b686eada065066b36bf5080640e0f58cbf
root@localhost:/usr/src/icinga-reports-1.8.0# rm configure
root@localhost:/usr/src/icinga-reports-1.8.0# aclocal
root@localhost:/usr/src/icinga-reports-1.8.0# autoconf
root@localhost:/usr/src/icinga-reports-1.8.0# ./configure –with-jasper-server=/opt/jasperreports-server-cp-4.7.0
checking for a BSD-compatible install… /usr/bin/install -c
checking whether build environment is sane… yes
checking for a thread-safe mkdir -p… /bin/mkdir -p
checking for gawk… no
checking for mawk… mawk
checking whether make sets $(MAKE)… yes
checking build system type… x86_64-unknown-linux-gnu
checking host system type… x86_64-unknown-linux-gnu
checking for jasperserver… configure: creating ./config.status
config.status: creating MakefileMaybee it’s better to provide an install.sh for this which creates the configure script in the local environment.