debianlogo.png
Etwas mehr als zwei Jahre nach dem letzten Release wurde Debian 7 alias Wheezy veröffentlicht. Neben einem Update der Standardsoftware unterstützt Wheezy eine sprachgeführte Installation und bietet ein ruhiges, modernes Design. Und: Debian wird nun auch im All genutzt.


Debian 7.0 alias Wheezy hat etwas mehr als zwei Jahre nach seinem Vorgänger Squeeze das Licht der Welt erblickt, und bietet umfangreiche Neuerungen.

Da ist zum einen die Liste aktualisierter Pakete: Gnome, der Debian-Standard-Desktop, wird nun in einer 3er-Version mitgeliefert, bietet also die neue Gnome-Shell. Auch die Desktops KDE und XFCE wurden aufgefrischt, und liegen jeweils in der Version 4.8 vor. Libreoffice ersetzt OpenOffice, PostgreSQL lässt mit 9.1 die Ära der 8 hinter sich und die Compiler-Suite GCC springt von 4.4 auf 4.7. Abgerundet werden die aktualisierten Pakete durch das ruhigere, aufgeräumtere Design des neuen Debian.

Gerade für Desktop-Anwender ist darüber hinaus interessant, dass Wheezy auch nahezu alle wichtigen Multimedia-Formate wie MP3 und x264 unterstützt. Die Zeiten, in denen diese umständlich nachinstalliert werden mussten, sind damit vorbei.

Doch auch abseits der Desktop-Anwender finden sich umfangreiche Neuerungen: Wheezy integriert die Cloud-Lösung OpenStack gebrauchsfertig! Es enthält out-of-the-box alle Komponenten, die Sie benötigen um einen beliebig großen Cloud-Cluster aufzubauen - egal ob mit zwei oder mit zweitausend Servern.

Für Server-Betrieb ebenfalls interessant ist die neue Unterstützung für Multiarch-Installationen: unter Wheezy können Pakete für verschiedene Prozessorarchitekturen direkt nebeneinander installiert und genutzt werden. Eine eigene chroot ist so für andere Architekturen nicht mehr notwendig, und auch proprietäre Software wie Skype oder unter Wine laufende Programme lassen sich so deutlich einfacher handhaben.

Doch auch abseits der Veröffentlichung von Wheezy feiert Debian noch einen ganz anderen Erfolg: die Laptops auf der internationalen Raumstation werden fortan unter Linux betrieben! Keith Chuvala, ein Mitarbeiter der der NASA zuarbeitenden United Space Alliance, sah Bedarf nach einer staiblen und verlässlichen Linux-Distribution, und wählte daher Debian:

Um allen Ansprüchen der Astronauten zu genügen suchte Chuvala nach einem moderneren, robusteren Enterprise Support, der mit der Migration von Scientific Linux nach Debian 6 erreicht wurde.
To manage all of the astronaut’s needs Chuvala was looking for newer, more robust enterprise support, which was achieved by moving from a Scientific Linux distribution to Debian 6.

Wir von der credativ GmbH beglückwünschen Debian zu beiden Erfolgen!

Alle Blog-Artikel zum Thema Debian werden auch als Kategorie Debian samt eigenem Feed angeboten - und bei Bedarf bieten wir auch gerne Support und Services rund um Debian.

[Howto] Zarafa Mailextraktion

| Keine Kommentare

zarafa_logo.jpgWer zur alltäglichen Spamabwehr Spamassassin mit Bayes-Filter einsetzt, wird das System regelmäßig trainieren wollen. Spamassassins sa-learn benötigt als Input eine vollständige Email samt Headern und Body. Im Folgenden sei eine Methode beschreiben, wie man vollständige Emails aus Zarafa extrahieren kann.

Eine Zarafa-Umgebung benötigt eine MySQL-Datenbank zur Verwaltung von Nutzern, Mailstores, Mailfoldern und sonstigen Email-Objekten. Für das Attachment-Storage gibt es dabei zwei Betriebsmodi:

  • Im Database-Modus sind sämtliche Informationen ("Objekte") in der MySQL-Datenbank enthalten, vor allem die Emails, Email-Header und -Anhänge.
  • Im Files-Modus hingegen werden die potenziell großen Objekte, nämlich Email-Anhänge und volle Emails - die ihre Anhänge als Multiparts einbetten - im Dateisystem abgelegt.

Für uns sind folgende Daten und deren Ablageort interessant:

  • Der reine Email-Header ist in der DB-Tabelle properties zu finden.
  • Daten bezüglich der Userkonten sind verteilt auf die DB-Tabellen users und stores.
  • Die vollständigen Emails sind gespeichert in
    • der lob Tabelle, falls Zarafa im Database-Modus arbeitet, beziehungsweise
    • im Dateisystem typischerweise unter /var/lib/zarafa/..., falls der Files-Modus genutzt wird.
  • Beziehungen zwischen zusammengehörigen Daten mehrerer Tabellen werden unter anderem über Instance_IDs (SQL Schlüsselattribut) hergestellt.

Im Files-Modus hat der volle Pfad der einzelnen, per gzip komprimierten vollständigen Emails die Form {attachment_path}/{INT}/{INT}/{Instance_ID}.gz, wobei der attachment_path in der Zarafa-Standardkonfiguration /var/lib/zarafa lautet. Deren Subverzeichnisse sind von der Instance_ID abgeleitet, ein konkreter Beispielpfad lautet /var/lib/zarafa/4/6/43664.gz.

Das folgende Skript liest einen String von der Standardeingabe und sucht passende Email-Header in der properties-Tabelle. Zu den gefundenen Treffern werden die vollen Emails aus der lob-Tabelle extrahiert, Zarafa muss also mit attachment_storage=database betrieben werden - die Suche nach den zugehörigen gz-Dateien im Files-Modus ist hier nicht implementiert. Es sei angemerkt, dass die SQL-Statements je nach Datenbankgröße eine hohe DB-Last erzeugen können. Getestet wurde Zarafa in Version 7.0.9. Ein Beispielaufruf wäre:

[root@zarafa ~]# cat needle.txt 
Subject: test Mon, 04 Feb 2013 15:05:12 +0100
[root@zarafa ~]# mkdir hackstack; ./zarafa-extract.pl zarafauser haystack < needle.txt
 Writing haystack/1359986776.0000.txt ...
[root@zarafa ~]# cat haystack/1359986776.0000.txt
Date: Mon, 04 Feb 2013 15:05:12 +0100
To: zarafauser
From: zarafa.testsystem.intern
Subject: test Mon, 04 Feb 2013 15:05:12 +0100
X-Mailer: swaks v20100211.0 jetmore.org/john/code/swaks/
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_MIME_BOUNDARY_000_14806"

------=_MIME_BOUNDARY_000_14806
Content-Type: text/plain

This is a test mailing
------=_MIME_BOUNDARY_000_14806
Content-Type: application/octet-stream; name="test.xml"
Content-Description: test.xml
Content-Disposition: attachment; filename="test.xml"
Content-Transfer-Encoding: BASE64

SGVsbG8gV29ybGQK

Zur Nutzung des Perl-Skripts werden die DBI und DBD::mysql Module benötigt, welche unter Debian beispielsweise durch libdbd-mysql-perl bereitgestellt werden.

#!/usr/bin/perl -w

# Copyright (c) 2013, Damian Lukowski <damian.lukowski@credativ.de>
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions are met:
#    * Redistributions of source code must retain the above copyright
#      notice, this list of conditions and the following disclaimer.
#    * Redistributions in binary form must reproduce the above copyright
#      notice, this list of conditions and the following disclaimer in the
#      documentation and/or other materials provided with the distribution.
#    * Neither the name of the <organization> nor the
#      names of its contributors may be used to endorse or promote products
#      derived from this software without specific prior written permission.
#
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
# WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
# DISCLAIMED. IN NO EVENT SHALL <COPYRIGHT HOLDER> BE LIABLE FOR ANY
# DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
# (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
# LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
# ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
# SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

use strict;
use DBI;
use DBD::mysql;

my $DEBUG = 0;

# Fill in the MySQL server properties
my ($dbhost,$dbport,$dbname,$dbuser,$dbpass) = ('', 3306, 'zarafa', '', '');

if (@ARGV < 2)
{
	print "Usage:	$0 <zarafa-user> <outdir>\n
	$0 reads a mail header from STDIN and searches
	for zarafa-users's emails matching the given mail header.
	Each result is stored as a separate file within <outdir>.
	It is assumed that zarafa is configured with
	attachment_storage = database!\n";
	exit;
}

my ($username, $outdir) = @ARGV;

chomp(my $needle = join '', <STDIN>);
$needle = "%$needle%";
# RFC822 demands CR LF as a line separator.
$needle =~ s/(?!\r)\n/\r\n/g;

my $dbh = DBI->connect("dbi:mysql:$dbname:$dbhost:$dbport", $dbuser, $dbpass)
	  or die $DBI::errstr;

my ($qry, $ref, $sth, $uid);

if ($username ne '.')
{

	$qry = "SELECT user_id FROM stores WHERE user_name = '$username'";
	$ref = $dbh->selectall_arrayref($qry);

	if (@$ref > 1)
	{
		print "Ambiguous username. Matching userids: ",
		join ', ', map {$_->[0]} @$ref;
		exit;
	};

	die "Username not found\n" unless @$ref;
	$uid = $$ref[0][0];
	print "uid of $username: $uid\n" if $DEBUG;
};

if ($DEBUG && $username ne '.')
{
	$qry = "SELECT COUNT(*) FROM properties";
	printf "%d properties\n", ${$dbh->selectall_arrayref($qry)}[0][0];

	$qry = "SELECT COUNT(*) FROM lob";
	printf "%d large objects\n", ${$dbh->selectall_arrayref($qry)}[0][0];

	$qry = "SELECT COUNT(*) FROM properties WHERE tag = 125";
	printf "%d properties with tag 125 (headers)\n",
		${$dbh->selectall_arrayref($qry)}[0][0];

	$qry = "SELECT COUNT(*) FROM properties WHERE val_string LIKE ?";
	$sth = $dbh->prepare($qry);
	$sth->execute($needle);
	printf "%d tag-125 properties matching needle\n",
		${$sth->fetchrow_arrayref}[0];

        $qry = "SELECT h.owner, s.user_name, p.hierarchyid FROM "
             . "hierarchy h RIGHT JOIN properties p on h.id = p.hierarchyid "
             . "LEFT JOIN stores s ON s.user_id=h.owner WHERE p.tag = 125 "
             . "AND p.val_string LIKE ?";

	$sth = $dbh->prepare($qry);
	$sth->execute($needle);
	while (my @row = $sth->fetchrow_array())
	{
		printf " uid=%s, username=%s, hierarchyid=%s\n", @row;
	}

	$qry = "SELECT count(*) FROM hierarchy h JOIN properties p on "
	     . "h.id = p.hierarchyid LEFT JOIN singleinstances s on "
	     . "s.hierarchyid = h.id WHERE p.tag = 125 AND h.owner = $uid";
	printf "%d tag-125 properties of %s\n",
		${$dbh->selectall_arrayref($qry)}[0][0], $username;

	$qry = "SELECT h.owner, p.hierarchyid, s.instanceid FROM hierarchy h "
	     . "JOIN properties p on h.id = p.hierarchyid LEFT JOIN "
	     . "singleinstances s on s.hierarchyid = h.id WHERE "
	     . "h.owner = $uid AND p.val_string LIKE ?";
	$sth = $dbh->prepare($qry);
	$sth->execute($needle);
	$ref = $sth->fetchall_arrayref();
	printf "%d tag-125 properties of %s matching needle\n",
		(scalar @$ref), $username;

	for my $row (@$ref)
	{
		printf " uid=%s, hierarchyid=%s, instanceid=%s\n", @$row;
	}
}

# A tag value of 125 corresponds to the mapitag definition as found in zarafa's
# sources under mapi4linux/include/mapitags.h:
# define PR_TRANSPORT_MESSAGE_HEADERS          PROP_TAG(PT_TSTRING,    0x007D)
# define PR_TRANSPORT_MESSAGE_HEADERS_W        PROP_TAG(PT_UNICODE,    0x007D)
# define PR_TRANSPORT_MESSAGE_HEADERS_A        PROP_TAG(PT_STRING8,    0x007D)

if ($username ne '.')
{
	$qry	= '(SELECT s.instanceid FROM properties p JOIN hierarchy h '
		. 'ON h.id = p.hierarchyid JOIN singleinstances s ON '
		. "s.hierarchyid = h.id WHERE h.owner = $uid AND p.tag=125 AND "
		. 'p.val_string LIKE ?)';	
} else
{
	$qry	= '(SELECT s.instanceid FROM properties p '
		. 'JOIN singleinstances s ON '
		. "s.hierarchyid = p.hierarchyid WHERE p.tag=125 AND "
		. 'p.val_string LIKE ?)';
}

$sth = $dbh->prepare($qry);
$sth->execute($needle);

my $iid = undef;

# Hint:
# For zarafa deployments with attachment_storage = files, the requested mails
# are not stored in the lob table, but within /var/lib/zarafa/. Let iid be
# 54321, then the mail is stored in /var/lib/zarafa/1/12/54321.gz
# The extraction logic is not covered here ...

my $written = 0;

while (my @row = $sth->fetchrow_array())
{
	$iid = $row[0];
	$qry = "SELECT val_binary FROM lob WHERE instanceid = $iid";
	$ref = $dbh->selectall_arrayref($qry);

	print "Looking for full mail of iid=$iid\n" if $DEBUG;

	for my $row (@$ref)
	{
		print " Found full mail with iid=$iid\n" if $DEBUG;
		my $tmp_file = sprintf '%s/%s.%04d.txt', $outdir,
				time, $written++;
		open my $fh, "> $tmp_file";
		print " Writing $tmp_file ...\n";
		print $fh $row->[0];
		close $fh;
	};
};

unless (defined $iid)
{
	print "No iid found, probably because the header didn't match.\n";
	print "If you are sure that the header should be found, try to use ",
	      "'.' (dot) as the username.\nThe DB query will be slower but ",
	      "might find the email.\n" unless $username eq '.';
} elsif ($written == 0)
{
	print	"Instanceid(s) found, but no files written? ", 
		"Probably attachment_storage != database\n";
}

Alle Artikel zum Thema Groupware stehen auch als eigene Kategorie mit eigenem Feed zur Verfügung. Falls Ihr tiefergehende Fragen zu Support und Services für Zarafa habt seid Ihr bei uns ebenfalls richtig.

Customer Story: Landeshauptstadt München

| Keine Kommentare

LiMux.jpgIm Rahmen der Rubrik "Customer Stories" stellen wir unsere Kunden und die jeweils mit den Kunden verwirklichten Projekte vor. Diese Customer Story betrifft die Bayerische Landeshauptstadt München.

Die credativ GmbH unterstützt seit dem Jahr 2008 das LiMux-Projekt der Stadt München, in dessen Rahmen die meisten der ca. 15000 Arbeitsplatz-Rechner der Stadtverwaltung auf Linux umgestellt werden. Nach einer langjährigen Planungs- und Anlauf-Phase wurde die Migration in den letzten Jahren stark vorangetrieben.

Ende November 2012 wurde schließlich das Projektziel erreicht: Über 12000 migrierte LiMux-Basisclients sind im Betrieb. Inzwischen wird das LiMux-Projekt als "Erfolgs-Story" für eine erfolgreiche Migration im öffentlichen Sektor bezeichnet. Die Einsparungen gegenüber dem fortgesetzten Betrieb von Microsoft Windows und Microsoft Office betragen mehr als 10 Millionen Euro.

Die LiMux-Basisclients werden dabei in den einzelnen Referaten der Landeshauptstadt zentral von sogenannten Verteilservern durch die jeweiligen Administratoren installiert, konfiguriert und administriert. Die beiden Haupt-Komponenten sind dabei die LDAP-basierte Konfigurations- und Administrations-Management-Lösung GOsa² und das Installations-Management FAI (Fully Automatic Installation).

Diese Backend-Komponenten waren hauptsächlich der Schwerpunkt der bisherigen Arbeiten der credativ GmbH für die Landeshauptstadt München. Ein Teil dieser Arbeiten betraf dabei die Planung und Entwicklung neuer Features für die Erleichterung der täglichen Arbeiten der Administratoren in den Referaten. Ein anderer Schwerpunkt war die Verbesserung der Skalierbarkeit bei Masseninstallationen, wodurch der Massen-Rollout der Migration ermöglicht wurde. Darüberhinaus wurden viele kleine und große Fehler beseitigt und die Benutzeroberfläche vereinheitlicht.

LiMux-Projektleiter Peter Hoffmann meint:

"Die Zusammenarbeit mit der credativ GmbH über die letzten Jahre war zu unserer vollsten Zufriedenheit. Als ortsansässiger, Open-Source orientierter mittelständiger Dienstleiter verkörpert die credativ GmbH unser Bestreben, herstellerunabhängig und mit offenen Standards das LiMux-Projekt voranzutreiben".

Der Haupt-Grund für die benötigten Arbeiten ist die Art der Benutzung von GOsa² durch das LiMux-Projekt: GOsa² ist im Prinzip eine Web-Anwendung, mit der Benutzer und dazugehörige Dienste wie Email oder Datei-Freigaben administriert werden können. Die Stadt München benutzt GOsa² zwar nicht für das Anlegen von Benutzern und das Ändern der Nutzerdaten (hierfür wird ein schon vorher verwendetes Programm benutzt), wohl aber für die Konfiguration von Benutzern und die Administration von Basisclients. Darüberhinaus werden bei der Stadt München auch eine sehr große Anzahl an Clients und Benutzern mit GOsa² verwaltet.

GOsa_Screenshot_de.png
Das Hauptmenü von GOsa²

Größere Teile dieser Funktionalität wurden speziell für die Migrations-Anforderungen der Stadt München entwickelt und werden von anderen GOsa²-Benutzern gar nicht oder nur kaum verwendet. Die hauptsächlichen Bereiche des GOsa²-Einsatzes der Stadt München sind:

1. Die Konfiguration von Desktop-Einstellungen von Benutzern (oder Gruppen von Benutzern), wie Desktop-Shortcuts, Startmenü-Einträge, Login/Logoff-Skripte, Freigaben, Drucker usw. Diese Einstellungen werden beim Einloggen eines Benutzers an einem Basisclient im LDAP abgefragt und über entsprechende Skripte konfiguriert.

2. Die Konfiguration von Basisclients (oder Gruppen von Clients) und Verteilservern, wie verwendete LDAP/NTP-Server, System-weite Freigaben und Drucker. Für (Verteil-)Server können zusätzlich verschiedene Dienste, wie etwas LDAP-, NTP-, oder Logging-Server konfiguriert werden, sowie Software-Repositories.

3. Die Konfiguration von FAI-Klassen für die Software-Verteilung. FAI wird üblicherweise durch Text-Dateien verwaltet; durch die Speicherung der Daten im LDAP ist die komfortable Veränderung der verschiedenen Installations-Profile und deren Partitionierungs-Schemata, Paketlisten und Konfigurations-Skripte über die GOsa²-Webanwendung möglich.

4. Die Fernwartung von Basisclients und Verteilservern über das GOsa-SI genannte Client/Server-System, wodurch das Neustarten, Neuinstallieren oder An- und Abschalten von Systemen möglich ist. Über diese Client/Server-Kommunikation können außerdem auch Nachrichten an eingeloggte Benutzer versandt werden und der Installations-Fortschritt eines Systems überwacht werden.

Im Laufe der Jahre wurden umfangreiche Änderungen durch die credativ GmbH an den obigen Einsatzbereichen vorgenommen. Bis Mitte 2011 basierte die vom LiMux-Projekt eingesetzte Code-Basis auf Version 2.6 von GOsa² und war in einem 2.6-lhm-Zweig im Subversion-Repository von GOsa² öffentlich verfügbar. In diesem Zweig wurden seit 2008 über 250 Changesets von der credativ GmbH eingepflegt.

Im Herbst 2011 hat sich das LiMux-Projekt entschieden zur neuen Version 2.7 von Gosa² zu wechseln. Hierfür wurden zunächst bis Ende 2011 die noch nicht im Haupt-Entwicklungszweig eingeflossenen und weiterhin nötigen Änderungen des 2.6-lhm-Zweigs auf die 2.7 Code-Basis portiert, was in ca. 90 Changesets mündete.

Da in Version 2.7 von GOsa² die Software-Verteilung mit FAI und die System-Verwaltung mit GOsa-SI graduell durch neue Projekte abgelöst wurden, waren eine Reihe der von der Stadt München verwendeten Funktionalitäten nicht mehr komplett funktionsfähig. Seit Anfang 2012 wurden deshalb durch Tests neu gefundene Probleme in GOsa²-2.7 von der credativ GmbH behoben, sowie eine Reihe von neuen Features implementiert. Dies führte zu weiteren 200 Changesets, und 4000 neuen Code-Zeilen (wobei 1000 Code-Zeilen entfernt wurden) innerhalb von etwa vier Monaten. Diese Arbeiten wurden im Sommer 2012 in einem öffentlichen Git-Repository bereitgestellt und somit der Open-Source Community zurückgegeben.

Bezüglich der geleisteten Arbeiten sagt Michael Dusel, Leiter der Entwicklung Basisclient des LiMux-Projekts:

"Die langjährige erfolgreiche Zusammenarbeit mit den Mitarbeitern der credativ GmbH war stes überaus freundlich. Besonders während der Umstellung von GOsa² 2.6 nach 2.7 konnten wir uns die schnelle und professionelle Hilfe der credativ GmbH verlassen. So wurden während der Testphase neu in GOsa²-2.7 gefundene Probleme rasch durch die Entwickler der credativ GmbH beseitigt und erhebliche neue Funktionalität zu unserer Zufriedenheit implementiert".

Neben den Arbeiten an GOsa² hat die credativ GmbH auch noch weitere Unterstützungs-Leistungen für die Stadt München erbracht. So wurden verschiedene Probleme des Basisclients diagnostiziert, und die Debian-Spezialisten der credativ GmbH haben Paketierungs-Unterstützung zum Beispiel für das Paketieren und Backporting von verschiedenen Paketen (u.a. Firefox und dessen Erweiterungen) geliefert.

Zusammengefasst kann man sagen, dass das LiMux-Projekt auf einem sehr guten Weg ist und die credativ GmbH stolz ist, ihren Teil dazu beizutragen. Wir erwarten, dass die Erfolge der Stadt München auch andere Gemeinden oder öffentliche Verwaltungen zu ähnlichen Migrationen ermutigen. Wir unterstützen Sie dabei gerne mit unserem Know-How. Bei Interesse genügt eine Mail an limux@credativ.com.

eye.jpg
Bei der kommenden Open Source Monitoring-Konferenz wird Alexander Wirt, technischer Leiter bei der credativ GmbH, einen Vortrag über die Nutzung von Nagios und Icinga im Zusammenhang mit Debian halten.

Auf der am 17. und 18. Oktober 2012 stattfindenden Open Source Monitoring Conference wird Alexander Wirt seine mittlerweile seit 10 Jahren gesammelten Kenntnisse und Erfahrungen zum Einsatz von Icinga, Nagios, check_mk und verwandten Komponenten zum Besten geben.

Der Vortrag wird sich darauf konzentrieren, die Paketierung der Komponenten unter Debian, das dahinter stehende Debian-Team sowie die Nutzung der Komponenten auf Debian-Installationen und im typischen IT-Umfeld aufzuzeigen. Der Vortrag richtet sich insbesondere an Einsteiger, die wartbare Monitoring-Umgebungen auf der Basis von Nagios/Icinga möglichst zügig aufbauen und betriebsbereit bringen wollen.

Als Mitglied des Icinga Core-Teams verfügt Alexander Wirt dabei über einen umfangreichen Überblick über die Struktur und Geschichte des Projekts selbst, als Debian-Paketierer ist ihm aber auch die Perspektive des Administrators und desjenigen, der die Systeme letztendlich betreuen wird, bestens vertraut.

Die langjährige Erfahrung als technischer Leiter bei der credativ GmbH verleiht ihm darüber hinaus einen tiefen Einblick Einblick in den Alltag bei der Nutzung der verschiedenen Monitoring-Komponenten bei einer Vielzahl kleiner und großer IT-Systeme im Geschäftsumfeld.

Alle Blog-Artikel zu aktuellen Themen werden auch als Kategorie Monitoring samt eigenem Feed angeboten. Wir helfen auch gerne mit Open Source Support und Services für Monitoring-Lösungen.

FutureOfOpenSourceSurvey.jpg
Eine aktuelle Umfrage beschäftigt sich mit der Entwicklung und Zukunft von Open Source Software im Jahr 2012. Machen Sie mit und unterstützen auch Sie die aktuelle Open Source Studie 2012.

Die Open Source Studie 2012 evaluiert die Entwicklung und die erwartete Zukunft von Open Source im Unternehmenseinsatz in diesem Jahr. Die Ergebnisse dieser Studie werden sicher auch für Ihr Unternehmen einen wichtigen Beitrag für die zukünftige Open Source Strategie liefern.

Gerne sind Sie dazu eingeladen, die Umfrage auch anderen Interessierten mitzuteilen, oder sich mit dem Hash-Tag #FutureOSS darüber auszutauschen. Die Ergebnisse werden Ihnen kostenfrei zur Verfügung gestellt. Alle Angaben können anonym erfolgen.

Alle Blog-Artikel zu aktuellen Themen werden auch als Kategorie News samt eigenem Feed angeboten. Wir bieten zu nahezu allen angesprochenen Open-Source-Themen auch unseren gewohnten Open Source Support.

debianlogo.pngDebian Entwickler arbeiten mit vereinten Kräften an Debian GNU/Linux „Wheezy“.

Auch in diesem Jahr bietet das deutsche Open Source Support Centers der credativ GmbH in seinem Räumen in Mönchengladbach dem Debian-Projekt die Möglichkeit, im Rahmen einer "Bug Squashing Party" an der nächsten Debian-Version "Wheezy" zu arbeiten. Die Debian-Entwickler der credativ GmbH und zahlreiche Gäste aus dem In- und Ausland werden sich am Wochenende vom 2. bis 4. März treffen, um konzentriert an offenen Problemen zu arbeiten. Aus Italien werden in diesem Jahr auch Enrico Zini und Francesca Ciceri vom Debian Press Team erwartet.

Auf der Bug Squashing Party wird auch an Piuparts gearbeitet werden, einem Tool das automatische Upgrade-Tests für die nächste Debian-Version Wheezy durchführt. Fehler können so rechtzeitig vor dem Release erkannt und beseitigt werden.

Ein weiteres Ziel ist verbesserte Ipv6-Unterstützung. Debian-Entwickler Alexander Wirt: "Die Umstellung auf das neue Internet-Protokoll ist sehr wichtig, zu viele Programme in Debian unterstützen bisher nur das alte IPv4-Protokoll."

Außerdem soll der Mailinglisten-Server des Debian-Projekts auf neue und schnellere Hardware umgezogen werden, damit der ansteigende Mailverkehr bewältigt werden kann. Parallel zur Bug Squashing Party trifft sich das Debian New Member Team, um an der Infrastruktur zu arbeiten, mit der das Debian-Projekt seine Benutzerkonten verwaltet und neue Mitglieder aufnimmt. Debian Account Manager Christoph Berg: "Wir arbeiten seit zwei Jahren an der Umstellung der alten PHP-Webseite auf ein modernes Web-Framework in Python, wir wollen das Wochenende nutzen, um die neue Version endlich fertig zu stellen."

Weitere Informationen über die Bug Squashing Party bei credativ stehen auf den Seiten von debian.org zur Verfügung.

Alle Blog-Artikel zu unserer Firma werden auch als Kategorie credativ samt eigenem Feed angeboten - und falls ihr nach Support und Services für Debian sucht, seid ihr bei uns ebenfalls richtig.

Deutsche PostgreSQL Konferenz

| Keine Kommentare

postgreslogo.png


Im Rahmen der alljährlichen OpenRheinRuhr, einer jährlichen Konferenz rund um Freie Software, wird die deutschsprachige PGConf.DE am 11. November 2011 in Oberhausen das Rheinland besuchen.

Als Fortsetzung des sehr erfolgreichen PGDay.EU im letzten Jahr, werden auch in diesem Jahr interessante und informative Vorträge rund um PostgreSQL angeboten. Entwickler und Anwender, aber auch Interessierte anderer Bereiche, treffen auf PostgreSQL-Entwickler, -Spezialisten oder erfahrene Anwender zum Erfahrungsaustausch und um die neuesten Entwicklungen rund um das freie Datenbanksystem zu erfahren.

Das Vortragsprogramm ist online verfügbar, ebenso wie die Registrierung der Konferenz bereits möglich ist. Besucher, die sich vorab registrieren erhalten einen Kostenvorteil von 10 € gegenüber dem Eintrittspreis an der Tageskasse. Der Eintrittspreis berechtigt gleichzeitig auch zum Besuch der OpenRheinRuhr für das ganze Wochenende.

Mitarbeiter der credativ GmbH, die die PGConf.DE als Goldsponsor unterstützt, werden selbstverständlich ebenfalls anwesend sein und in ihren Vorträgen von ihren Erfahrungen berichten.

Alle Blog-Artikel zum Thema PostgreSQL werden auch als Kategorie PostgreSQL samt eigenem Feed angeboten. Wir helfen auch gerne mit Support und Services für PostgreSQL.

VACUUM FULL - Viel hilft viel?

| Keine Kommentare

postgreslogo.png


VACUUM in PostgreSQL ist seit jeher mit Mythen und falschen Informationen behaftet. Besonders verbreitet ist offenbar die Einstellung, VACUUM FULL helfe vorbeugend. Das genaue Gegenteil ist häufig der Fall.

VACUUM - Der Staubsauger

Seit der Einführung von MVCC (Multi Version Concurrency Control) in PostgreSQL 6.5 im Jahr 1999 gibt es das Kommando VACUUM. Mit Hilfe dieses Kommandos wird der sogenannte Heap, also die Dateien, die die Tabellendaten enthalten, defragmentiert und nicht mehr belegter Speicherplatz freigegeben. Dies ist notwendig, da PostgreSQL Zeilen bei UPDATE oder DELETE nicht etwa physikalisch löscht, sondern eine neue Version der Zeile anlegt bzw. die Zeile einfach als gelöscht markiert. Die alte Version muss noch so lange beibehalten werden, wie es auch Transaktionen gibt, die diese Zeilenversion noch "sehen" können. Ist eine Tabelle sehr stark durch UPDATE oder DELETE/INSERT frequentiert, und passiert VACUUM zu selten (beispielsweise weil Autovacuum nicht verwendet wird), so kann der sogenannte "tote" Speicherplatz in einer Tabelle sehr stark anwachsen.

VACUUM FULL - Vorbeugende Reorganisation?

Viele Administratoren sind daher der Auffassung, dass es aus diesem Grund angebracht ist, dies im Vorfeld durch nächtliche VACUUM FULL Jobs dem Anwachsen der Tabelle vorzubeugen. Dies ist eine schlechte Strategie, aus mehreren Gründen:

  1. VACUUM FULL benötigt im Gegensatz zu normalem VACUUM eine exklusive Tabellensperre, d.h. der Zugriff ist für alle nebenläufigen Transaktionen nicht möglich (auch reine Leseanfragen).
  2. VACUUM FULL führt eine komplette physische Reorganisation der Tabelle durch, nicht jedoch der Indexe. Dies hat sich mit PostgreSQL 9.0 geändert. Eine exklusive Tabellensperre ist weiterhin notwendig.
  3. Läuft eine Datenbank mit WAL-Archiving, so kommt es durch VACUUM FULL zu massiv erhöhtem Datenaufkommen im Transaktionslog. Dies kann Probleme mit dem Backuparchiv nach sich ziehen.
  4. Man benötigt auf jeden Fall ein Wartungsfenster für exklusiven Zugriff der Tabellen.
  5. Im Gegensatz zu normalen VACUUM ist VACUUM FULL daher nicht für den Einsatz in 24/7-Datenbanken geeignet.

Während sich die meisten Nachteile durch ein Wartungsfenster umschiffen lassen, sind die Nachteile durch sehr häufiges VACUUM FULL gravierender. Besonders PostgreSQL-Versionen bis einschließlich 8.4 sind davon betroffen. Um das zu verstehen, muss man sich die Funktionsweise des VACUUM FULL Kommandos in diesen Versionen ansehen:

  1. VACUUM FULL untersucht die Tabelle sequentiell nach totem Speicherplatz. Hierzu werden die gefundenen toten Bereiche während VACUUM FULL in einem Array im Hauptspeicher gespeichert. Ist das Array voll (begrenzt durch maintenance_work_mem), so werden sichtbare (also aktive) Zeilen von unten her in die gefundenen toten Bereiche verlagert (sofern Platz hierfür ausreichend zur Verfügung steht).
  2. Sind Indexe auf der Tabelle vorhanden, so müssen diese ebenfalls aktualisiert werden.
  3. Ist das Array abgearbeitet, beginnt der Algorithmus wieder von vorne, solange, bis das Ende der Tabelle erreicht ist.
  4. Anschließend wird die Tabelle physisch verkleinert.

Das Hauptproblem ist das Umsortieren der Zeilen in den freigewordenen Speicherplatz. Dies sorgt für massive I/O auf dem Speichersystem. Noch schwerwiegender ist jedoch die Tatsache, dass beim Umsortieren der Index ebenfalls aktualisiert werden muss. Passiert das sehr häufig, so kann es passieren, dass der Index selbst sehr stark fragmentiert. In diesem Fall wächst der Index selbst an, man spricht dann vom sogenannten Index Bloat. Daher kann es erforderlich sein, direkt nach dem VACUUM FULL ein REINDEX auf die Tabellen auszuführen, insbesondere wenn Tabellen sehr stark fragmentiert waren und viele Tupel umsortiert wurden. Dies alles sorgt bei sehr großen Tabellen auch für sehr lange Laufzeiten.

Ab PostgreSQL 9.0 verhält sich VACUUM FULL wie das CLUSTER Kommando, d.h. die Tabelle wird sequentiell gelesen und parallel komplett neu aufgebaut. Dies hat den Vorteil, dass man nur die Zeilen liest, die aktiv sind und die "toten" Zeilen außen vor lässt. Anschließend werden die Indexe neu erzeugt. Dies eliminiert viele Nachteile des alten Algorithmus, vermeidet jedoch nicht die Notwendigkeit exklusiver Tabellensperren. Ferner benötigt die Reorganisation der Tabelle im schlechtesten Falle nochmal soviel Speicherplatz, wie die aktuell zu bearbeitende Tabelle.

VACUUM und Autovacuum für tägliche oder sehr granulare Wartung

VACUUM bzw. Autovacuum sind für die tägliche oder dauerhafte Wartung von PostgreSQL-Datenbanken ausgelegt.

  1. Wer sich eine sorgfältige VACUUM-Policy mit normalem VACUUM oder, noch besser, Autovacuum zurechtlegt, benötigt kein VACUUM FULL.
  2. Autovacuum sollte auf jeden Fall in Betracht gezogen werden, muss jedoch an den Workload angepasst werden.
  3. Ist dennoch mal eine Tabelle sehr stark aufgebläht, so kann mit aktuellen 8er PostgreSQL-Versionen mit CLUSTER die Tabelle häufiger deutlich schneller verkleinert werden, ohne das Problem der Indexfragmentierung. Da CLUSTER anhand eines Index die Tabelle reorganisiert, benötigt man mindestens einen Index. Ferner sollte unbedingt danach die Optimizerstatistiken mit ANALYZE aktualisiert werden.
  4. Bis einschließlich PostgreSQL 8.3 ist es unbedingt notwendig, sich vor Inbetriebnahme die Parameter max_fsm_pages und max_fsm_relations anzuschauen. Die Werte dieser Parameter kann nur durch einen Neustart der Datenbank geändert werden und beeinflussen die Anzahl an erfassten fragmentierten Speicherplatz in Tabellen und Indexe sowie die Anzahl an Tabellen und Indexe die durch VACUUM erfasst werden können (VACUUM FULL benutzt die sogenannte Free Space Map nicht). Ab PostgreSQL 8.4 werden die FSM pro Tabelle automatisch angepasst.
  5. Auch VACUUM kann unter günstigen Umständen eine Tabelle verkleinern. Wenn die Tabelle am Ende nur noch leere Blöcke enthält und aktuell keine Transaktion neue Zeilen in diese Bereiche einlagern möchte, dann kann auch normales VACUUM die Tabelle entsprechend eindampfen.

Warum dann überhaupt noch VACUUM FULL?

VACUUM FULL ist ein Kommando, das nicht für die tägliche Wartung ausgelegt ist. Ist das Kind einmal in den sprichwörtlichen Brunnen gefallen und eine Tabelle stark aufgebläht, so ist es je nach PostgreSQL-Version unausweichlich mit VACUUM FULL den Speicherplatz freizugeben. Bei älteren PostgreSQL-Versionen sollte sich der Administrator besonders bei sehr großen Speicherbedarf der Tabelle besser überlegen, auf das CLUSTER-Kommando auszuweichen. Möchte man dennoch VACUUM FULL benutzen, so sollte man bei älteren PostgreSQL-Versionen mit REINDEX ebenfalls die Indexe neu erzeugen. Weitere Infos zu diesem Thema finden sich im PostgreSQL Wiki.

Weitere Informationen

Alle Blog-Artikel zum Thema PostgreSQL werden auch als Kategorie PostgreSQL samt eigenem Feed angeboten. Wir helfen auch gerne mit Support und Services für PostgreSQL.

credativ beim PGDay Europe 2010

| Keine Kommentare

postgreslogo.png
Letzten Monat fand die alljährliche europäische PostgreSQL-Konferenz in Stuttgart statt. Die credativ GmbH war nicht nur Sponsor der Veranstaltung, sondern auch mit vier Mitarbeitern vor Ort, welche mehrere Vorträge gehalten haben. Die Folien der Vorträge sind nun verfügbar.


Die Konferenz fand im Stuttgarter Millennium-Hotel statt und wurde professionell und effizient von PostgreSQL Europe organisiert. Durch zahlreiche Kaffee-Pausen und die Konferenz-Party am Montag Abend war ein reger Austausch zwischen den Teilnehmern möglich.

Die Vorträge von credativ waren im einzelnen:

  • "Migration auf Freie Software in unternehmenskritischen Bereichen" (Folien)

    Dr. Michael Meskes fasste in diesem Vortrag die langjährige Erfahrung der credativ GmbH bei der Migration von kritischen Unternehmens-Bereichen auf Freie Software im allgemeinen und PostgreSQL für Datenbanken im speziellen zusammen.

  • "Embedded SQL für PostgreSQL" (Folien)

    In seinem zweiten Vortrag befasste sich Dr. Michael Meskes mit dem von ihm im PostgreSQL-Projekt als ECPG betreuten Embedded SQL, eine Datenbankschnittstelle in der Programmiersprache C. Da sie im SQL-Standard definiert ist und schon sehr lange und für alle Datenbanksysteme existiert, wird sie vielfach verwendet, so dass in dem Vortrag vor allem auch auf Migrationen eingegangen wurde.

  • "Die PostgreSQL Community" (Folien)

    Bernd Helmle, der technische Leiter der credativ GmbH für den Bereich Datenbanken, stellte in seinem Vortrag die Geschichte und den momentanen Stand der PostgreSQL-Community und deren Prozesse und Organisation vor und erläuterte zusätzlich die verschiedenen Möglichkeiten der Mitarbeit durch neue Mitglieder.

  • "Advanced Analytics with PL/R" (Folien)

    Schließlich hielt Joe Conway, CEO der US-amerikanischen credativ LLC einen (englisch-sprachigen) Vortrag über die PostgreSQL-Erweiterung PL/R, eine Zusammenführung von PostgreSQL mit R, der im Bereich Freier Software führenden Umgebung für mathematische und statistische Berechnungen und deren Visualisierung).

Das nächste PostgreSQL-Event der credativ GmbH ist die Schulung im Linux-Hotel vom 23. bis 25. Februar 2011.

Alle Blog-Artikel zum Thema PostgreSQL werden auch als Kategorie PostgreSQL samt eigenem Feed angeboten. Wir helfen auch gerne mit Support und Services für PostgreSQL.

migration.pngDies ist der zweite Teil unseres Migrations-Howtos für Netzwerk-Überwachungs-Systeme von Nagios nach OpenNMS. Nachdem im ersten Teil die Integration von aktiven Nagios-Checks via NRPE (Nagios Remote Plugin Executor) diskutiert wurde, wenden wir uns in diesem zweiten Teil den passiven Nagios-Checks durch NSCA (Nagios Service Check Acceptor) zu.

Passive Nagios-Checks

Da es momentan keine spezielle OpenNMS-Unterstützung für passive NSCA-Checks gibt, müssen diese durch andere Mechanismen abgebildet werden. In diesem Howto verwenden wir für jeden passiven NSCA-Check einen eigenen Service, dessen Status durch externe Benachrichtigung geändert wird und der durch den PassiveStatusKeeper-Mechanismus von OpenNMS überwacht wird.

Einbinden der Nagios SNMP-Trap Informationen

Für die sinnvolle Behandlung von SNMP-Traps wird eine Registrierung des jeweiligen MIBs (Management Information Base) als OpenNMS-Event benötigt. OpenNMS kennt zwar von Haus aus eine Vielzahl von SNMP-Traps, die aus dem Nagios-MIB sind jedoch nicht darunter. Die benötigte Nagios.events.xml Datei wurde aus dem MIB erstellt und muss in das events/-Unterverzeichnis der OpenNMS Konfiguration kopiert werden und in der eventconf.xml Datei via <event-file>events/Nagios.events.xml </event-file> eingebunden werden. Der in der Nagios-MIB definierte SNMP-Trap für Service-Events ist nSvcEvent, welcher als numerische OID (Object Identifier) den Code .1.3.6.1.4.1.20006.1.7 besitzt.

Benachrichtigungen via SNMP-Trap

Das für passive NSCA-Checks verwendete Programm send_nsca kann etwa durch folgendes Shell-Skript ersetzt werden, welches die Benachrichtigung von OpenNMS via snmptrap durchführt:
  #!/bin/bash

  SNMPTRAP=/usr/bin/snmptrap
  COMMUNITY=public

  while getopts "H:d:p:" OPTION; do
    case $OPTION in
      H) HOST=$OPTARG;;
      d) DELIM=$OPTARG;;
      p) PORT=$OPTARG;;
      *) ;;
    esac
  done

  if [ "x$DELIM" == "x" ]; then
    DELIM="\t"
  fi

  if [ "x$HOST" == "x" ]; then
    echo "No host defined, exiting"
    exit
  fi

  array=(`awk -F"$DELIM" '{for(i=1;i<=3;i++){print $i};
                    for(i=4;i<=NF;i++){gsub(/ /,"_",$i); print $i}}'`);
  NODE=${array[0]}
  SERVICE=${array[1]}
  STATUS=${array[2]}
  REASON=`echo ${array[3]} | sed s/_/\ /g`"'"

  $SNMPTRAP -v 2c -c $COMMUNITY $HOST '' NAGIOS-NOTIFY-MIB::nSvcEvent \
    NAGIOS-NOTIFY-MIB::nHostname s "$NODE" \
    NAGIOS-NOTIFY-MIB::nHostStateID i 0 \
    NAGIOS-NOTIFY-MIB::nSvcDesc s "$SERVICE" \
    NAGIOS-NOTIFY-MIB::nSvcStateID i "$STATUS" \
    NAGIOS-NOTIFY-MIB::nSvcAttempt i 1 \
    NAGIOS-NOTIFY-MIB::nSvcDurationSec i 1 \
    NAGIOS-NOTIFY-MIB::nSvcGroupName s "" \
    NAGIOS-NOTIFY-MIB::nSvcLastCheck i 0 \
    NAGIOS-NOTIFY-MIB::nSvcLastChange i 0 \
    NAGIOS-NOTIFY-MIB::nSvcOutput s "$REASON"
Das Skript versteht die beiden nsca_send Optionen -H (Host) und -d (Feldtrenner). $HOST ist dabei der OpenNMS-Server, für den die Benachrichtigung vorgesehen ist. Der awk-Befehl zerteilt den per Feldtrenner separierten NSCA-String (z.B. „postgres-test; Vaccuum;0;Vaccuum OK 1276511175“) in seine Bestandteile, welche den Variablen $NODE, $SERVICE, $STATUS und $REASON zugeteilt werden. Diese werden schließlich beim Aufruf von snmptrap den nSvcEvent Parametern nHostname, nSvcDesc, nSvcStateID und nSvcOutput zugeteilt. Den übrigen Parametern nHosteStateID, nSvcAttempt, nSvcDurationSec, nSvcGroupName, nSvcLastCheck und nSvcLastChange werden allgemeine Werte zugeteilt, da sie bei der Umsetzung des nSvcEvent-Traps in ein OpenNMS-Event keine Rolle spielen und auch beim Aufruf von send_nsca nicht bekannt sind. Damit die Parameter des nSvcEvent-Traps von snmptrap aufgelöst werden können, muss das NAGIOS-MIB der Net-SNMP-Installation bekannt sein.

Umwandlung von Traps in Events

Die eingehenden SNMP-Traps werden in OpenNMS-Events vom Typ nSvcEvent umgewandelt. Um diese nun einzelnen Nagios-Checks bzw. OpenNMS-Services zzuuweisen, müssen sie vom translatord-Dämon in passiveServiceStatus Events umgewandelt werden. Folgender Abschnitt ist hierfür in der Datei translator-configuration.xml nötig:
<event-translation-spec 
  uei="uei.opennms.org/vendor/nagios/traps/nSvcEvent">
    <mappings>
      <mapping>
        <assignment type="parameter" name="passiveNodeLabel">
          <value type="parameter" 
            name=".1.3.6.1.4.1.20006.1.1.1.2" 
            matches=".*" 
            result="${0}" 
          />
        </assignment>
        <assignment type="parameter" name="passiveIpAddr">
          <value type="field" 
            name="interface" 
            matches=".*" 
            result="${0}"
          />
        </assignment>
        <assignment type="parameter" name="passiveServiceName">
          <value type="parameter" 
            name=".1.3.6.1.4.1.20006.1.3.1.6" 
            matches=".*" 
            result="${0}" 
          />
        </assignment>
        <assignment type="parameter" name="passiveStatus">
          <value type="sql" 
            result="SELECT CASE WHEN ?::integer = 0  
                                     THEN 'Up'        
                                     ELSE 'Down' 
                                     END;" >  
            <value type="parameter" 
              name=".1.3.6.1.4.1.20006.1.3.1.7" 
              matches=".*" 
              result="${0}" 
            />
          </value>
        </assignment>
        <assignment type="parameter" name="passiveReasonCode">
          <value type="parameter" 
            name=".1.3.6.1.4.1.20006.1.3.1.17" 
            matches=".*" 
            result="${0}" 
          />
        </assignment>
        <assignment type="field" name="uei">
          <value type="constant" 
            result="uei.opennms.org/services/passiveServiceStatus" 
          />
        </assignment>
      </mapping>
    </mappings>
</event-translation-spec>
Die uei in der zweiten Zeile bezeichnet dabei den SNMP-Trap, wie er in der jeweiligen events-XML Datei angegeben ist. Die Parameter passiveNodeLabel, passiveServiceName, passiveStatus und passiveReasonCode werden aus den jeweiligen Parametern $NODE, $SERVICE, $STATUS und $REASON des SNMP-Traps übernommen. Für die Ermittlung von passiveStatus ist dabei eine SQL-Abfrage nötig, um je nach Nagios-Status ein "Up" oder "Down" zu senden. Die IP-Adresse kann direkt aus dem "interface"-Feld des Events übernommen werden. Schließlich wird in der letzten Zuordnung die OpenNMS UEI (Unique Event Identifier) von nSvcEvent nach passiveServiceStatus umgewandelt.

Einbinden von Passiven Checks als Services

Passive NSCA-Checks können naturgemäß nicht mit capsd entdeckt werden, deshalb müssen sie per LoopPlugin für jede betreffende Node per ip-match Property in der capsd-configuration.xml Datei aktiviert werden:
    <protocol-plugin 
      protocol="NSCA-check1" 
      class-name="org.opennms.netmgt.capsd.plugins.LoopPlugin"
      scan="on">
        <property key="ip-match" value="192.168.178.158" />
        <property key="ip-match" value="172.16.17.213" />
        <property key="is-supported" value="true" />
    </protocol-plugin>
Dabei bezeichnet protocol den Namen des betreffenen OpenNMS-Service.

Zusätzlich ist auch ein entsprechender Poller in poller-configuration.xml nötig, zum einen der <service>-Anker:

    <service name="NSCA-check1" 
      interval="30000" 
      user-defined="false" 
      status="on">
    </service>
Sowie schließlich ein PassiveServiceMonitor:
<monitor service="NSCA-check1" 
  class-name="org.opennms.netmgt.poller.monitors.PassiveServiceMonitor"
/>
Mit diesen Änderungen und nach einem Neustart von OpenNMS sollten die NSCA-Checks für die entsprechende Node im OpenNMS-Webinterface erscheinen und sich wie normale OpenNMS Dienste in Bezug auf Ausfälle etc. verhalten.