Icinga Reporting Bug – Servicegroup-Reports können nicht ausgewählt werden

Bildschirmfoto-3

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

 

 

iPhone Recovery-Modus

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

  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 …

(SSH-)Login überwachen / QNAP / Debian

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.

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 &lt;MODELL&gt;)"
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 boot to PXE

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 ]

Icinga Check-Latency und die Rolle der idotuils, bzw. Datenbank

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.

BUG: Icinga Reporting 1.8.0 (./configure: line 1682: AM_INIT_AUTOMAKE: command not found)

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 Makefile

The 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 Makefile

Maybee it’s better to provide an install.sh for this which creates the configure script in the local environment.