Nagios Eventhandler: Apache2

Wenn der Indianer mal wieder streikt …

Ab und an kommt es mal vor, dass der Indianer mal wieder nicht so will wie er soll. Gerade bei der älteren Installation eines Bekannten eher häufiger.

Jedesmal von unterwegs den Service neustarten ist also keine Option. Mein Eventhandler besteht wieder aus zwei Scripten. Eines läuft auf dem Nagios, das andere wird über ssh auf dem Remotehost gestartet. Die Authentifizierung läuft natürlich zeitgemäß über public keys.

1. Remoteserver konfigurieren:

1.1 Benutzerkonfiguration

der User Nagios muss auf dem Remotehost angelegt sein und auch ein Homedir besitzen. Die Datei ~/authorized_keys muss mit dem ssh-public-key des Nagios Users vom Nagios-Server befüllt sein.

1.2 Script ablegen

Das Script [ restart_apache ] zuerstmal in restart_apache.sh umbenennen und dann nach /usr/bin/ kopieren. Sicherstellen, dass der user nagios das script auch ausführen darf 🙂

1.3 SUDO konfigurieren

Da wir Nagios keinen Vollzugriff aufzwängen wollen, führt kein Weg an sudo vorbei. über visudo dann die folgende Zeile in die /etc/sudoer eintragen:

nagios  ALL=NOPASSWD: /etc/init.d/apache2, /usr/bin/killall apache2

2. Nagiosserver

2.1 Script ablegen

Das Script [evt_apache2 ] zuerst wieder in .sh umbenennen und dann nach /usr/local/nagios/libexec/eventhandlers/ kopieren, den User nagios zum owner machen und die rechte setzen.

wget http://www.christian-veith.de/wp-content/uploads/2010/04/evt_apache2.txt -O /usr/local/nagios/libexec/eventhandlers/evt_apache2.sh && chown nagios:nagios evt_apache2.sh && chmod 0755 evt_apache2.sh

2.3 Konfiguration

Dann noch in die Nagioskonfiguration einbinden. Aber die Infos gibts in der Nagios Dokumentation.

Veröffentlicht unter System Monitoring | Kommentare deaktiviert für Nagios Eventhandler: Apache2

MAC Tastatur unter Windows

Das schicke Mac Keyboard von Apple hat mich ja schon lange gereizt. Kurzhub Tasten und liegt flach auf dem Schreibtisch. einfach ein geniales Teil. Wenn doch nur eine standard Tastenbelegung drauf wäre…

Damit es richtig sauber läuft, muss man folgendes tun:

  1. Keyboardtreiber aus dem Bootcamp MSI extrahieren
  2. Keyboardmappings anpassen

Das MSI findet ihr im Downloadbereich von Apple oder auf euren Mac DVD´s. Das entsprechende Treiberpaket bekommt ihr am besten mit 7Zip aus dem MSI extrahiert. Installieren und fertig. Ohne Treiberpaket, ist die Tastatur ziemlich schlecht zu bedienen. Die Funktionstasten gehen dann nur in Kombination mit FN.

Die Mac Tastatur hat leider einen Nachteil. Die sogenannte Command Taste ist unter Windows die Windows-Taste. Somit sind auf Applekeyboards die Positionen von Alt und Windows-taste vertauscht. Dies muss nun über Keymappings geändert werden.

Hier sind die angepassten Tasten in Sharpkeys zu sehen.

  1. Linke ALT -> Windows Taste
  2. Linke Command -> Alt-Taste
  3. Rechte Alt -> Kontextmenü
  4. Rechte Windows -> Alt+GR
  5. F17 -> Leiser
  6. F18 -> Lautlos
  7. F19 -> Lauter

Leider hab ich es bis jetzt nicht geschafft die Auswurftaste für eben dieses zu verwenden.

Achso hier noch ein paar zusätzliche Tasten:

  1. F14: Print Screen
  2. F15: Scroll Lock
  3. F16: Num Lock
  4. FN+Enter: Insert (Um Strg+Alt+Entf in einer VMWare zu benutzen, muss man dann Strg+Alt+FN+Enter drücken)
Veröffentlicht unter Windows | Ein Kommentar

WSUS Clientstatus überwachen

Zum Testen hab ich einfach mal kurz einen WSUS bemüht. Die Idee hinter dem ganzen sah wiedermal so aus:

Warum soll ich ein Tool öffnen, wenn ich doch eh das Monitoring offen habe.

Im MSDN findet man zum Glück einige Codebeispiele mit denen man an die WSUS Api rankommt. Sicher man kann auch direkt an den SQL-Server ran aber wer weiß in wieweit sich die Datenbank bei einem Update ändert.

Den Quelltext findet ihr im Anhang. Einfach mit dem Visual Studio Express Edition kompilieren und weiter gehts.

Wenn es auf dem Wsus Server ausgeführt wird, generiert es für jeden Client zwei Zeilen Output im Nagios.cmd format.

  1. System – WSUS Reporttime: Diese Zeile liefert das letzte Reportdatum des Clients (letzter Statusreport)
  2. System – WSUS Status: Hier erscheinen Infos über den Paketstatus (Needed: 15, Failed: 0, Installed: 117)

Ist die Reporttime älter als 14 Tage, so geht der Check „System – WSUS Reporttime“ auf Warning

Ist die Anzahl der benötigten Pakete > 0, geht „System – WSUS Status“ auf Warning. Existieren Pakete mit Failed Status wird der Check auf Critical gesetzt.

[1270848916] PROCESS_SERVICE_CHECK_RESULT;CLIENTNAME;System - WSUS Reporttime;0;LETZTES_REPORT_DATUM
[1270848942] PROCESS_SERVICE_CHECK_RESULT;CLIENTNAME;System - WSUS Status;0;Needed: 0, Failed: 0, Installed: 0

Die Exe kann man einfach per Scheduled Task laufen lassen und dann eine Ausgabeumleitung in eine Textdatei machen. Diese Datei sollte dann am besten im inetpub liegen, da wir sie dann vom Nagios server per wget abholen können.

Auf dem Nagiosserver kann die Datei dann über ein cat Textfile >> /usr/local/nagios/var/rw/nagios.cmd in die External Command Queue eingereiht und verarbeitet werden.

Die Clients benötigen zwei zusätzliche passive Servicechecks, diese weisst man am besten über eine Hostvorlage „Windows Client“ oder „Windows Server“ zu.

  1. System – WSUS Status
  2. System – WSUS Reporttime

[nagiosreporter]

Veröffentlicht unter System Monitoring | Kommentare deaktiviert für WSUS Clientstatus überwachen

Backup per rsync

So jetzt auch noch mein Backupverfahren.

Cron startet auf jedem Server zu den festgelegten Zeiten den Backupjob. Dieser besteht aus 2 Shellscripten und ein paar Konfigurationsdateien.

  1. /etc/cvbackup/basic.conf = Benutzernamen, Passwörter, welche ssh-keys genommen werden sollen usw.
  2. /etc/cvbackup/folder.conf = legt die zu sichernden Ordner fest
  3. /etc/cvbackup/folder_excludes.conf = Alle Ordner, die nicht gesichert werden sollen. relativ vom jeweiligen Startverzeichnis. Angegeben in rsync Manier.
  4. mysql_database.conf = enthält alle zu sichernden Datenbanknamen auf diesem Server.

Die Scripte:

  1. /root/backup/backup.sh = Das eigentliche Backupscript
  2. /root/backup/backup_sql.sh = Backupscript für die Mysql Datenbanken
  3. /root/backup/rotate.sh = wird auf dem Targetserver über die rc.local beim Boot gestartet und prüft alle 10 Minuten ob ein Backup beendet wurde und es dann rotiert werden muss.

Das Verfahren:

Die Backupscripte legen die Daten mit dem angegebenen User unterhalb von /srv/backup/HOSTNAME/current ab. Nach Ende aller Kopiervorgänge wird im Verzeichnis /srv/backup/HOSTNAME die Datei finished abgelegt. rotate.sh prüft alle 10 Minuten alle Unterverzeichnisse von /srv/backup auf dateien mit dem Namen finished. Ist diese vorhanden, so wird per „cp -al“ das Verzeichnis per Hardlinks kopiert in die folgende Struktur:

+– 2010
|   +– 01
|   +– 02
|   +– 03
|   +– 04
|       +– 2010_04_01__T__21_55
|       +– 2010_04_02__T__21_55
|       +– 2010_04_03__T__21_56
|       +– 2010_04_04__T__21_57
|       +– 2010_04_05__T__21_57
|       +– 2010_04_06__T__21_58
|       +– 2010_04_08__T__00_49
|       +– 2010_04_08__T__22_09
|       +– 2010_04_09__T__21_42
+– current

Die Inhalt der verzeichnisse 2010_04_09__T__21_42 und current sind nach Abschluss des Kopiervorganges identisch. Bei einem erneuten Rsync werden bei den veränderten Dateien die Hardlinks aufgebrochen und die Datei in current überschrieben.

Somit sind die Daten mit minimalen Platzbedarf gesichert und ich kann zusätzlich auf jeden einzelnen Backupstand wie auf ein Vollbackup zugreifen.

[Backup Scripte]

To-Do:

  1. Überwachung in Nagios/Opsview einbauen
  2. Backupstände automatisch verwerfen (Nach einem Jahr nur noch Monatsstände vorhalten, nach zwei Jahren nurnoch halbjahresstände usw.)
Veröffentlicht unter Linux | Kommentare deaktiviert für Backup per rsync

Automatisierung mit Nagios

Nagios als Monitoring ist schon klasse.

Ich verwende im Moment Opsview als Gesamtpaket. Dieses bietet einen Nagiosunterbau und eine einigermassen komfortable Weboberfläche.

Aber jetzt mal zum Kern des Themas. Was nutzt mir ein Monitoring wenn ich es nicht nutze ? Nichts. Man muss nicht darauf warten vom System eine Mail zu bekommen. Sinn und Zweck ist es ja eben keine Mails zu bekommen.

Skizzieren wir mal folgendes Szenario. Der Postfix auf BoxA ist abgestürtzt. Somit lauscht auf Port TCP/25 kein Daemon mehr. Also checkt Nagios nach 5 Minuten den Port, stellt einen Outtake fest und wechselt in den Status Critical / Soft / 1. Je nach Konfiguration checkt er nach einer Minute erneut und wechselt bei fehlschlag in dem Status Critical / Soft / 2. Und genau hier optimieren wir die Geschichte.

Nagios bietet die Möglichkeit Eventhandler einzusetzen. Diese werden bei jedem Statuswechsel ausgelöst Also beim Wechsel von OK auf Critical oder Warnung und auch bei Wechsel von Hard auf Soft. Bei Soft States wird nach jedem Check der Eventhandler angestossen.  [evt_postfix]. Dieser startet jetzt über das check_nrpe Plugin auf dem fehlerhaften Host ein Script zum postfix restart.

To-Do:

  1. Bei Erfolgsmeldung Recheck des SMTP Servicechecks anstossen
  2. Bei Misserfolg warnmeldung über Passivecheckresult melden
  3. Alternativen Restartweg über SSH einbauen
Veröffentlicht unter System Monitoring | Kommentare deaktiviert für Automatisierung mit Nagios