Archive for the 'Open Source' Category

Open Source Data Center Conference 23./24.Juni 2010 – jetzt noch Frühbucher nutzen!

Logo OSDC2010 weißer Rand1 300x77 Open Source Data Center Conference 23./24.Juni 2010   jetzt noch Frühbucher nutzen! Bereits zum zweitem Mal findet in Nürnberg vom 23. – 24. Juni 2010 die Open Source Datacenter Conference statt. Die Konferenz zum Einsatz von Open Source Lösungen in Rechenzentren und großen IT-Umgebungen konnte bereits bei der Premiere im April 2009 über 80 begeisterte Anwender und Referenten nach Nürnberg locken. Auch für 2010 erwartet uns ein spannendes Vortragsprogramm u.a. mit:

Die Anmeldung ist ab sofort auf der Konferenzwebsite http://www.netways.de/osdc noch zum attraktiven Frühbucherpreis möglich!

PS: Das Fußball WM Spiel Deutschland – Ghana am 23. Juni 2010 kann bei  Interesse verfolgt werden! ;-)

Bacula Monitoring Plugins

Auf der Bacula Konferenz letztes Jahr hatte ich einen Vortrag gehalten, wie sich Bacula und vor allem auch Bacula Jobs und Pools durch Nagios oder Icinga überwachen lassen. In diesem Vortrag habe ich auch zwei Monitoring Plugins vorgestellt, die wir zum internen Einsatz entwickelt haben. Die beiden Plugins stehen auf unserem Community Portal netways.org zum Download zur Verfügung.

Mit dem Plugin check_bacula lassen sich einzelne Jobs überwachen, insbesondere ob ein Job in den letzten x Stunden erfolgreich abgeschlossen werden konnte. Wenn man den Jobnamen in Bacula gleich dem Nagios/Icinga Hostnamen wählt, spart man sich gleichzeitig auch etwas Konfigurationsarbeit. So wird das ganze konfiguriert:

# Bacula Checkcommand
# -H: hours; -w: Warning; -c: Critical; -j: Job (Jobname=Hostname)
define command {
	command_name	check_bacula
	command_line	$USER1$/check_netways_bacula.pl -H $ARG1$ -w $ARG2$ -c $ARG3$ -j $HOSTNAME$"
}

# bacula jobs
define service {
	use						bacula-template
	hostgroup_name			bacula-win, bacula-linux
	host_name				another_client
	service_description		backup-jobs
	check_command			check_bacula!27!1!1
	servicegroups			backup
}

bacula1 Bacula Monitoring Plugins

Das zweite Plugin count_bacula dient der Überwachung von Poolauslastungen, bzw. Poolgrößen. Damit lässt sich automatisch feststellen, wenn der Platz in einem definierten Pool zur Neige geht. Das Ergebnis kann man dann auch sehr aussagekräftig mit NETWAYS Grapher visualisieren:

define command {
	command_name	check_backup_poolsize
	command_line	$USER1$/count_bacula -pool $ARG1$ -w 75 -c 90
}

define service {
	use			generic-service
	host_name			Bacula_Server
	service_description	backup-pool PoolName
	check_command		check_backup_poolsize!PoolName
}

bacula21 Bacula Monitoring Plugins

Serie NSClient++ – Teil 4: Eventlog und weiteres!

Teil 4 von 4 in der Blogserie NSClient++

Im vierten Teil der NSClient++ Serie geht es um die Überwachung des Windows Eventlogs und weitere kleine Features des NSClients wie z.B. check_multiple.

Die Prüfung des Windows Eventlogs kann über mehrere Wege stattfinden.
In unserer Serie erfolgt die Prüfung über CheckEventlog und die dazugehörige Filtersprache, durch Angabe verschiedener Filter sind auch hier komplexe Abfragen möglich. Beispielsweise kann mit folgender Abfrage auf vorkommen von Fehlermeldungen (nicht success) innerhalb des Systemlogs geprüft werden die einen Tag alt sind und von einem Service erzeugt wurden. Eine CRITICAL Meldung wird in diesem Fall ab dem ersten Treffer erzeugt.

$ ./check_nrpe -H srv-ts.int.netways.de -p 5666 -c CheckEventLog -a file=system filter=new filter=out filter-eventType==success filter+eventSource=substr:Service 'filter-generated=>1d' MaxCrit=1

Dabei wird ausgegeben welche Services den Fehler verursacht haben, zur genaueren Diagnose sollte dann das Eventlog herangezogen werden.
Die Ausgabe kann je nach Gusto noch mit verschiedenen Parametern angereichert werden. Zu finden ist die Dokumentation der Filtersprache unter http://www.nsclient.org/nscp/wiki/CheckEventLog/CheckEventLog

Ein weiterer interessanter Check des NSClients ist im Modul CheckHelpers enthalten. Das Kommando CheckMultiple ermöglicht es ähnlich zu check_multi unter Linux/Unix in einem Connect mehrere Abfragen auszuführen. CheckMultiple erwartet als Argumente die auszuführenden Checks, um Beispielsweise die Festplattenauslastung sowohl auf prozentualer als auch auf absoluter Basis zu messen kann beispielsweise dieses Kommando verwendet werden:

$ ./check_nrpe -H srv-ts.int.netways.de -p 5666 -c CheckMultiple -a command=CheckDriveSize Drive=c MaxWarnUsed=80% MaxCritUsed=95% ShowAll=long command=CheckDriveSize Drive=c MinWarnFree=2G MinCritFree=1G ShowAll=long
WARNING: c:: Total: 40G - Used: 36G (90%) - Free: 3.99G (10%) > warning, OK: c:: Total: 40G - Used: 36G (90%) - Free: 3.99G (10%)|'c:'=90%;80;95; 'c:'=36.00G;37.99;38.99;

Die Verknüpfung der von CheckMultiple ausgeführten Prüfungen ist immer oder, d.h. der schlechteste Status der ausgeführten Subprüfungen wird immer in das Ergebniss übernommen. In unserem Testfall ist die Prüfung also ein WARNING Status. Die Textuelle Ausgabe der beiden Prüfungen wird ausschließlich bei den Performancedaten kombiniert, so bleibt jede Information der eigentlichen Prüfungen erhalten.

Serie NSClient++ – Teil 3: Basisüberwachung

Teil 3 von 4 in der Blogserie NSClient++

Nachdem in Teil eins und zwei der Blogserie über den NSClient++ die Grundlagen und Installation durchgeführt wurden kann es nun ans Überwachen der ersten Komponenten gehen. Ziel dieses Teils ist es eine Basisüberwachung des Betriebssystems abzudecken, daraus ableiten lässt sich dann auch eine erweiterte Überwachung diverser Dienste, Festplattten oder Prozesse.

Die Kommunikation hin zum Client erfolgt über das Plugin check_nrpe, wichtig hierbei ist NRPE mit aktivierten Kommandoargumenten übersetzt zu haben. Die benötigte Option hierfür heißt “–enable-command-args” und muss zur Kompilezeit angegeben werden.

Generell funktionieren die verschiedenen Abfragen ähnlich, einzig das auszuführende Kommando (Parameter “-c”) und die dazugehörigen Argumente (Parameter “-a” für check_nrpe) unterscheiden sich je nach Prüfung.

Ein Beispielhafter Aufruf für die Prüfung der CPU Auslastung über einen Zeitraum von 5 Minuten sieht wie folgt aus:

$ ./check_nrpe -H srv-app.int.netways.de -p 5666 -c CheckCPU -a warn=80% crit=95% time=5m ShowAll=long

Sieht das Ergebnis wie gewünscht aus können wir uns den weiteren Checks widmen. Als Basisüberwachung werden folgende Prüfungen auf jedem Windowssystem eingerichtet:

  • CPU Auslastung (80% Warning, 95% Critical, 5 Minuten Messintervall)
  • Festplattenauslastung (80% Warning, 95% Critical)
  • Speicherauslastung (70% Warning 85% Critical)
  • Uptime
  • Server Dienst

Die Kommandozeilen für die genannten Prüfungen:

$ ./check_nrpe -H srv-app.int.netways.de -p 5666 -c CheckCPU -a warn=80% crit=95% time=5m ShowAll=long
OK: 5m: average load 1%|'5m'=1%;80;95; 

$ ./check_nrpe -H srv-app.int.netways.de -p 5666 -c CheckDriveSize -a Drive=c MaxWarnUsed=80% MaxCritUsed=95% ShowAll=long
OK: c:: Total: 40G - Used: 24.6G (61%) - Free: 15.4G (39%)|'c:'=61%;80;95; 

$ ./check_nrpe -H srv-app.int.netways.de -p 5666 -c CheckMEM -a MaxWarn=70% MaxCrit=85% type=physical ShowAll=long
OK: physical memory: Total: 2G - Used: 840M (41%) - Free: 1.18G (59%)|'physical memory'=41%;70;85; 

$ ./check_nrpe -H srv-app.int.netways.de -p 5666 -c CheckUpTime -a ShowAll=long
OK: uptime: 0:13

$ ./check_nrpe -H srv-app.int.netways.de -p 5666 -c CheckServiceState -a Server
OK: All services are in their apropriate state.

Funktionieren diese Abfragen können dazu noch passende Nagios bzw. Icinga Kommandos definiert werden:

define command {
        command_name    check_win_load
        command_line    $USER1$/check_nrpe -H $HOSTADDRESS$ -p 5666 -c CheckCPU -a warn=$ARG1$ crit=$ARG2$ time=$ARG3$ ShowAll=long
}

define command {
        command_name    check_win_drive
        command_line    $USER1$/check_nrpe -H $HOSTADDRESS$ -p 5666 -c CheckDriveSize -a Drive=$ARG1$ MaxWarnUsed=$ARG2$ MaxCritUsed=$ARG3$ ShowAll=long
}

define command {
        command_name    check_win_mem
        command_line    $USER1$/check_nrpe -H $HOSTADDRESS$ -p 5666 -c CheckMEM -a MaxWarn=$ARG1$ MaxCrit=$ARG2$ type=physical ShowAll=long
}

define command {
        command_name    check_win_uptime
        command_line    $USER1$/check_nrpe -H $HOSTADDRESS$ -p 5666 -c CheckUpTime -a ShowAll=long
}

define command {
        command_name    check_win_service
        command_line    $USER1$/check_nrpe -H $HOSTADDRESS$ -p 5666 -c CheckServiceState -a $ARG1$
}

Jasper Reporting im Technical Review

jasper reporting Jasper Reporting im Technical Review

Vor einigen Tagen ist im Linux Technical Review ein Artikel zum Thema Jasper Reporting von mir erschienen. In dem Artikel geht es um den allgemeinen Aufbau des Reporting-Frameworks, sowie Tipps & Tricks rund um iReport und Auswahl der verwendeten Daten. Ich freu mich, dass es nach langer Zeit mal wieder geklappt hat einen Artikel zu vervollständigen und arbeite schon am nächsten.

Alle Interessierten sei die Online-Ausgabe des Technical Review als Quelle für detailreiche Berichte und Artikel wärmstens empfohlen.

Artikel zu Bacula in der Computerwoche

cw logo Artikel zu Bacula in der ComputerwocheAm letzten Montag ist in der Online Ausgabe der Computerwoche ein kleiner Artikel von mir zu Bacula erschienen. Bacula ist eine sehr professionelle Open Source Backup Lösungen. Soweit ich weiss, soll der Artikel auch in einer der nächsten Druckausgaben kommen. Freut mich natürlich.

Dazu passt auch sehr gut die Meldung von Bacula Systems, dass die Software inzwischen mehr als eine Million mal bei Sourceforge heruntergeladen wurde.

Serie NSClient++ – Teil 2: Installation

Teil 2 von 4 in der Blogserie NSClient++

Für die Installation des NSClient++ zur Windowsüberwachung gibt es generell zwei Möglichkeiten.

Variante eins ist die Installation auf Basis von zum Download bereitstehenden MSI Paketen. Bei dieser Installationsweise werden während des Installationsvorgangs die benötigten Parameter abgefragt.

Bei der zweiten Installationsvariante wird das ZIP Archiv heruntergeladen und auf die Systeme ausgerollt. Vorab sollte allerdings eine Anpassung der globalen Konfigurationsdatei “nsc.ini” erfolgen um die gewünschten Parameter zu setzen. Danach kann dieses Archiv einfach auf beliebig viele Rechner verteilt werden, wobei nach Entpacken des Archives manuell der Windows-Dienst registriert und gestartet werden muss.

Die Registrierung und der Start des Dienstes erfolgt in einer Kommandozeile mit den Befehlen:

# nsclientpp.exe -install
# net start nsclientpp

Beiden Installationswegen gemein ist jedoch der automatische Start des “nsclientpp” genannten Dienstes beim nächsten Neustart des Systems. Wer sich für den manuellen Installationsweg entscheidet muss in der NSC.ini folgende Parameter an die vorhandene Umgebung

Aktivieren der gewünschten Checks in derr [modules] Sektion:

FileLogger.dll
CheckSystem.dll
CheckDisk.dll
NRPEListener.dll
CheckEventLog.dll
CheckHelpers.dll

Durch die Aktivierung der oben genannten DLL’s wird die Funktionalität des NSClient++ bestimmt, eine Erklärung der Funktionen innerhalb der Bibliotheken findet sich in der Dokumentation unter http://www.nsclient.org/nscp/wiki/CheckCommands

Anpassungen im [settings] Abschnitt:

allowed_hosts=<Kommaseparierte IP Adressliste der Monitotingserver>
use_file=1

Die Direktive use_file weist den NSClient an die Konfigurationsdatei anstatt von Registryeinträgen zu verwenden. Bei der Installation wird also lediglich der Dienst registriert, weitere Einstellungen werden nicht in die Windows Registrierung geschrieben.

Zusätzlich müssen noch Kommandoargumente und Sonderzeichen für diese freigeschalten werden, dazu gibt es in der Sektion [NRPE] folgende Parameter die jeweils auf 1 zu setzen sind:

allow_arguments=1
allow_nasty_meta_chars=1

Werden Änderungen an der Konfiguration durchgeführt muss der Dienst durchgestartet werden. Dies erfolgt entweder über den Dienste-Manager oder durch die Kommandozeile:

# net stop nsclientpp
# net start nsclientpp

Ist die Installation und Konfiguration abgeschlossen und der Dienst erfolgreich gestartet kann vom Monitoringserver aus ein erster Test erfolgen:

# /usr/local/nagios/libexec/check_nrpe -H srv-app.int.netways.de -p 5666 -c CheckVersion

Als Antwort des Clients wird hierbei die Versionsnummer der aktuell Installierten NSClient Version zurückgegeben. Sollten hier Fehler auftreten bietet der NSClient die Möglichkeit den Dienst über eine Kommandozeilenoption in den Debugmodus zu schalten und so eventuell auftretenden Fehler zu lokalisieren. Dazu wird als erstes der Dienst gestoppt und der NSClient manuell mit der Option “-test” gestartet.

# net stop nsclientpp
# nsclientpp.exe -test

Julian Hein wird Vorstand bei der Open Source Business Foundation

osbf Julian Hein wird Vorstand bei der Open Source Business FoundationJulian Hein ist zum Mitglied des Vorstandes der Open Source Business Foundation e.V. (OSBF) gewählt worden. Die OSBF ist ein europäisches Netzwerk der Open Source Branche, mit einem klaren Fokus auf den geschäftlichen Einsatz der freien Software. Unter den mehr als 150 Mitgliedern befinden sich namhafte Software- und IT Service-Unternehmen, aber auch Hochschulen oder andere Organisationen.

jh3 Julian Hein wird Vorstand bei der Open Source Business FoundationNETWAYS ist schon seit kurz nach der Gründung im Jahre 2006 Mitglied. Damals hatte das Netzwerk noch den Namen Linux Business Campus Nürnberg (LBCN). Durch die thematische und regionale Verbreiterung der Mitgliederbasis entschied man sich Ende 2007 zur Umbenennung in OSBF.

Zusammen mit der Arbeit im Vorstand übernimmt Julian auch die Leitung der Projektgruppe Website.

Jahr 2000-Problem die Zweite: Spamassassin und das Jahr 2010

In den Postfächern der meisten Admins sind seit dem Jahreswechsel sicher viele Anfragen zu verschollenen Mails eingegangen. So wurden seit dem Jahreswechsel viele Mails durch den Spamfilter Spamassassin aufgrund des Datums ausgefiltert. Schuld daran ist die Filterregel FH_DATE_PAST_20XX, der eigentlich Mails ausfiltern sollte die zu weit in der Zukunft liegen. Das Problem wurde von den Spamassassin-Machern schon relativ zeitig erkannt und bereits vor ca. 6 Monaten durch einen Patch “behoben”. In der aktuellen Fassung trifft uns dieses Problem jedoch am 1.1.2020 wieder, d.h. hier können sich die leidgeplagten Admins schonmal einen Kalendereintrag machen ;-)

Trotz dem frühen Patch waren viele Systeme von diesem Fehler betroffen, unter anderem auch große Mail-Provider wie GMX und 1&1. Die Beseitigung des Fehlers ist relativ einfach durchzuführen, die Filterregel FH_DATE_PAST_20XX muss wie folgt modifiziert werden:

Alte Regel:

mailserver:/usr/share/spamassassin# grep DATE_PAST *
50_scores.cf:score FH_DATE_PAST_20XX 2.075 3.384 3.554 3.188 # n=2
72_active.cf:##{ FH_DATE_PAST_20XX
72_active.cf:header   FH_DATE_PAST_20XX    Date =~ /20[1-9][0-9]/ [if-unset: 2006]
72_active.cf:describe FH_DATE_PAST_20XX    The date is grossly in the future.
72_active.cf:##} FH_DATE_PAST_20XX

Neue Regel:

mailserver:/usr/share/spamassassin# grep DATE_PAST *
50_scores.cf:score FH_DATE_PAST_20XX 2.075 3.384 3.554 3.188 # n=2
72_active.cf:##{ FH_DATE_PAST_20XX
72_active.cf:header FH_DATE_PAST_20XX Date =~ /20[2-9][0-9]/ [if-unset: 2006]
72_active.cf:describe FH_DATE_PAST_20XX The date is grossly in the future.
72_active.cf:##} FH_DATE_PAST_20XX

In den nächsten Tagen sollten entsprechend aktualisierte Distributions-Pakete verfügbar sein. Bis dahin lässt sich die oben beschriebene Änderung selbst durchführen oder das Spamassassin-eigene Tool sa-update verwenden. Mit diesem Tool werden die Spamassassin-Dateien auf den aktuellsten Release-Stand gebracht.

MySQL Daten nach XML exportieren

Immer wieder findet man in Foren und verschiedenen Websites kleine Scripts, die eine MySQL-Tabelle in XML konvertieren. Bereits seit frühen 4er Versionen bietet MySQL dafür die Option –xml/ -X an, welche Ergebnisse der übergebenen Select-Anweisungen in standardkonforme XML-Dateien verwandelt, welche für viele Bedürfnisse ausreichen dürften.

Ein Beispiel:

mysql --xml -e "select alias, display_name, address from nagios.nagios_hosts limit 1,2"

gibt folgendes Ergebnis:

<?xml version="1.0"?>

<resultset statement="select alias, display_name, address from nagios.nagios_hosts limit 1,2
" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <row>
	<field name="alias">Business Processe</field>
	<field name="display_name">business_processes</field>
	<field name="address">10.6.255.99             # dummy IP</field>
  </row>

  <row>
	<field name="alias">untergeordnete Business Processe</field>
	<field name="display_name">business_processes_detail</field>
	<field name="address">10.6.255.99             # dummy IP</field>
  </row>
</resultset>

Auch mysqldump unterstützt die Ausgabe in XML, exportiert die Informationen jedoch aufgabengemäß in zusätzlichen Elementen mit Datenbank- und Tabelleninformationen.

Ein Beispiel:

mysqldump nagios nagios_dbversion --xml

gibt folgendes Ergebnis:

<?xml version="1.0"?>
<mysqldump xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<database name="nagios">
	<table_structure name="nagios_dbversion">
		<field Field="name" Type="varchar(10)" Null="NO" Key="" Default="" Extra="" />
		<field Field="version" Type="varchar(10)" Null="NO" Key="" Default="" Extra="" />
		<options Name="nagios_dbversion" Engine="InnoDB" Version="10" Row_format="Compact" Rows="1" Avg_row_length="16384" Data_length="16384" Max_data_length="0" Index_length="0" Data_free="0" Create_time="2009-09-11 12:04:09" Collation="latin1_swedish_ci" Create_options="" Comment="InnoDB free: 11264 kB" />
	</table_structure>
	<table_data name="nagios_dbversion">
	<row>
		<field name="name">ndoutils</field>
		<field name="version">1.4b7</field>
	</row>
	</table_data>
</database>
</mysqldump>