Braintower Gateways erben iSMS Features

braintower_logo Seit vielen Jahren setzen wir im Bereich SMS Alarmierung für Icinga sehr erfolgreich auf das MultiTech iSMS.
Neben der sehr simplen Einrichtung, der Netzwerkanbindungsmöglichkeit und dem Versenden von SMS über die Weboberfläche, bietet das Gerät eine HTTP-Schnittstelle für den Versand von SMS. Dadurch wird eine Integration in Monitoring Lösungen um ein vielfaches einfacher. Als weitere Option bietet das Gerät die Möglichkeit eingehende SMS an einen Webserver weiterzuleiten, was es in unserem Fall erlaubt, Alarmmeldungen von Icinga 2 mit einer simplen Antwort SMS zu Acknowledgen.
Für die Braintower Gateways gibt es seit letzter Woche die neue Firmware Version 3.3.0, welche das Gateway um einige interessante Funktionen erweitert. Eines dieser Features ist das SMS Routing, mit welchem SMS Nachrichten per Mail, SMS oder per Web-Call weitergereicht werden können.
Darüber hinaus wurde die API-Funktion des Gateways erweitert und ist nun vollständig kompatibel zu der MultiTech iSMS API. Wer bisher also ein iSMS sein eigen nennt, kann ohne Probleme auf ein Braintower Gateway umsteigen. Eine Erweiterung der Basis-Funktion (welche die API-Kompatibilität bereits inkludiert), ist über eine Vielzahl von Zusatz-Features möglich. Sofern das Gateway identisch eingerichtet wird (Benutzer, IP, etc.), kann eine nahtlose Alarmierung erfolgen – ohne Anpassungen an Skripten oder Software durchführen zu müssen.
Darüber hinaus ist unser iSMS Notification Plugin mit dem SMS Routing Feature zu 100% kompatibel mit Braintower. Somit ist nun neben einer Alarmierung auch ein Acknowledgen von Alarmmeldungen in Icinga möglich.
Übrigens: Wer bereits ein Braintower-Gateway mit dem SMS-Weiterleitungs-Feature erworben hat, kann ein Upgrade für das SMS Routing direkt nachkaufen.
Da wir auch immer wieder einmal diverse Kunden-Anfragen zum Thema GFI FaxMaker erhalten, ob wir passende Gateways anbieten können, ist die Antwort simpel: Ja!
Offiziell supportet wird seitens des Herstellers das MultiTech iSMS. Mit dem neuen Firmware-Update werden nun auch Braintower Gateways unterstützt.
Anbei noch ein kurzer Überblick zu den Änderungen zu Version 3.3.0:
Verbesserungen
[SMSGW-546] – Es ist möglich, die Scripts sendsms.pl und smsack.cgi aus dem NETWAYS iSMS Nagios / Icinga Plugin zu verwenden.
[SMSGW-606] – Es wurde eine Dokumentation zum Ersetzen von Geräten anderer Hersteller durch das Braintower SMS Gateway hinzugefügt.
[SMSGW-618] – Das Gateway ist zusätzlich auf Port 81 erreichbar.
[SMSGW-597] – Das Nachrichten-Routing kann nun Nachrichten auch an Ziele per HTTP weiterleiten.
[SMSGW-608] – HTTP-Ziele beim Nachrichten-Routing sind nun editierbar.
[SMSGW-612] – Es ist möglich, mehr als ein HTTP-Ziel pro Regel beim Nachrichten-Routing zu konfigurieren.
[SMSGW-624] – HTTP-Ziele sind bei Nachrichten-Routing auch auf eingehende Emails anwendbar.
[SMSGW-627] – Im Nachrichten-Routing wird nun ein Hinweis angezeigt, wenn kein SMTP Server konfiguriert wurde.
[SMSGW-634] – Das Feature Nachrichten-Routing kann nun kostenpflichtig lizenziert werden.
[SMSGW-607] – Das Feature SMS Weiterleitung ist nun Bestandteil des Nachrichten-Routings, jedoch mit verringerter Funktionalität. Kunden, die das Feature SMS Weiterleitung lizenziert haben, können eine Upgrade-Lizenz zur Nutzung des Nachrichten-Routings erwerben.
[SMSGW-619] – Die Gestaltung der Weboberfläche wurde verbessert.
[SMSGW-675] – Es wurden zahlreiche Übersetzungen verbessert.
[SMSGW-623] – Die Regeln zur Überprüfung gültiger Rufnummern bei der HTTP API wurden erweitert.
[SMSGW-641] – Es wurden neuen FAQ Artikel hinzugefügt (Syslog, API per HTTPS, SIM Karten Formfaktor, Einbindung in Centreon, Icinga 2 und WhatsUp Gold, Import und Export des Adressbuchs, Technische Daten).
Fehlerbehebungen
[SMSGW-604] – Beim Nachrichten-Routing wird die konfigurierte Absenderadresse nun korrekt gesetzt.
[SMSGW-614] – Die Whitelist der E-Mail-to-SMS Funktionalität wurde korrigiert.
[SMSGW-616] – Der Suchen und Ersetzen Bereich beim Nachrichten-Routing wird nicht mehr doppelt angezeigt.
[SMSGW-617] – Die E-Mail-Gruppen-Benachrichtigung beim Nachrichten-Routing wurde korrigiert.
[SMSGW-622] – Bei E-Mail-zu-SMS wurde die fehlende Online-Hilfe ergänzt.
[SMSGW-615] – Die Produktbezeichnung in Benachrichtigungs-Emails wurde korrigiert.
[SMSGW-628] – Nachrichten wurden teilweise sowohl über Email-zu-SMS als auch über das Nachrichten-Routing versendet.
Sie haben Interesse an unseren angebotenen Produkten oder wünschen eine Beratung? Nehmen Sie einfach direkt Kontakt mit uns auf oder besuchen Sie unseren Online-Shop für weitere Informationen. Wir stehen Ihnen gerne zur Verfügung!

Christian Stein
Christian Stein
Lead Senior Account Manager

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Senior Sales Engineer und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".

Braintower SMS Gateways – Neue Firmware 3.1.1

Braintower SMS Gateway Desktop EditionBraintower hat für das Braintower SMS Gateway Desktop Edition und das Braintower SMS Gateway Rack Edition die Firmware-Version 3.1.1 entwickelt, welche viele Verbesserungen enthält.
Die Braintower Gateways können SMS über eine API versenden und fügen sich hervorragend in Monitoringumgebungen mit Icinga 2 ein. Über zahlreiche Erweiterungen lassen sich die Geräte auch für viele weitere Einsatzbereiche im SMS-Versand nutzen.
Verbesserungen

  • [SMSGW-326] – Die Lokalisierung des Webinterfaces wurde an zahlreichen Stellen verbessert.
  • [SMSGW-200] – Die Dokumentation wurde erweitert.
  • [SMSGW-300] – Es wurden Updates des Linux-Basis-OS installiert.
  • [SMSGW-330] – Der maximal konfigurierbare Timeout für Monitoring-Checks wurde angepasst, um mögliche Beeinträchtigungen zu vermeiden.
  • [SMSGW-438] – Die Statistik-Seite wurde überarbeitet.

Fehlerbehebungen

  • [SMSGW-321] – Es wurde ein Fehler beim Überprüfen der Berechtigungen behoben, der das Anlegen und Löschen von Monitoring-Checks verhindert hat.
  • [SMSGW-437] – SMS, die über das Feature E-Mail-zu-SMS versendet wurden, wurden nicht in der Statistik angezeigt.
  • [SMSGW-450] – Durch das Monitoring-Feature wurden keine Recovery-Benachrichtigungen versendet.

Der Download der aktuellen Version erfolgt nach Eingabe der Seriennummer des Geräts unter support.braintower.de.

Martin Krodel
Martin Krodel
Head of Sales

Der studierte Volljurist leitet bei NETWAYS die Sales Abteilung und berät unsere Kunden bei ihren Monitoring- und Hosting-Projekten. Privat reist er gerne durch die Weltgeschichte und widmet sich seinem ständig wachsenden Fuhrpark an Apple Hardware.

HW group STE2: Nachfolger zur HWg-STE Reihe

HW group STE2Unser erfolgreichstes Netzwerkthermometer von der HW group hat einen Nachfolger bekommen und vereint alle bisherigen Varianten des HWg-STE in einem Modell. Bisher konnte man sich entscheiden, ob man ein Modell mit oder ohne PoE und mit oder ohne digitale Eingänge einsetzen wollte. Das STE2 wurde im Vergleich zum Vorgänger komplett überarbeitet und hat neben dem neuen Gehäuse einige hoch interessante Features dazu bekommen.
Hier die neuen Features:

  • Unterstützung von drei Sensoren (statt bisher zwei)STE2 Lieferumfang
  • Stromversorgung per PoE oder Netzteil möglich
  • Netzwerk per LAN oder per WLAN (Wifi)
  • Anschluss für zwei digitale Eingänge
  • Unterstützung des HW group SMS Gateways
  • TLS Unterstützung für den E-Mail Versand
  • Neues Webinterface
  • HWg Push für das SensDesk Portal

Im Lieferumfang des STE2 ist wie gewohnt ein 3m Temperatursensor und das Netzteil enthalten. Die bisher eingesetzten 1-Wire Sensoren der HW group passen auch an dieses Modell. Und natürlich haben wir das Plugin angepasst, die Integration in Icinga und Nagios läuft also problemlos.
STE2 Webinterface
Das STE2 ist ab sofort bei uns im Shop erhältlich und ersetzt die komplette STE-Baureihe. Und wenn es mehr als drei Sensoren pro Messgerät sein sollen, empfehlen wir den Einsatz des HW group Poseidon2 4002 mit bis zu 12 Sensoren.

Andreas Wienkop
Andreas Wienkop
Office Manager

Andreas ist seit 2015 bei NETWAYS. Im November 2018 hat er seine Ausbildung zum IT-Systemkaufmann erfolgreich abgeschlossen und ist nun im Bereich Finance & Administration tätig. In seiner Freizeit widmet er sich dem Reisen und dem Boxen.

SMS Eagle: SMS Gateways mit HTTP API

SMSEagleDa wir seit langem SMS Gateways verkaufen, sind wir immer auf der Suche nach neuen Lösungen, die verschiedene Anwendungsfälle abbilden können. Dabei sind wir auf den SMSEagle gestoßen. Zur Erklärung: SMS Gateways können in Netzwerke eingebunden und zum Versenden und Empfangen von SMS genutzt werden. Das Versenden von SMS kann in vielen Bereichen hilfreich sein. Klassisch in unserem Business: Die Alarmierung über SMS durch Einbindung in ein Monitoringsystem wie Icinga und Nagios. Passt etwas im Netzwerk oder der Serverumgebung nicht, wird ein Alarm per SMS versendet.

SMSEagle 3G

SMSEagle 3G


Eine weitere Anwendung finden die SMS Gateways in der Versendung von Massen-SMS. Man denke dabei nur an das SMS-TAN-Verfahren oder auch Massen-SMS zu Werbezwecken. Der neue SMSEagle, den es in 3 Varianten gibt, verfügt dazu über eine HTTP API für die Integration in eure Applikationen.

Das sind die 3 SMSEagle Modelle:

Für Nutzer, die das SMS Gateway für Massen-SMS nutzen, sind folgende Funktionen besonders interessant:

  • Senden an einzelne User und Gruppen
  • Senden von SMS zu einer speziellen Uhrzeit / an einem speziellen Datum (Scheduling möglich)
  • Auto-Reply an eingehende SMS (z.B. für ein TAN-Verfahren)
  • SMS zu E-Mail Weiterleitung bzw. E- Mail zu SMS
  • Importieren von Kontakten aus CSV Dateien

Diese eingebauten Features dürften alle Nutzer interessieren:

  • HTTP API für die Integration in eure Anwendung
  • Modernes, responsive Interface
  • Failover Support (HA Cluster von zwei Geräten möglich – nur bei SMSEagle NXS-9700 3G und SMSEagle NXS-9750 3G (dual modem)
  • Überwachungsdienste (z.B. Web Server, Mail Server) und SMS Alarmierung

Dies ist nur ein kleiner Auszug der Funktionen. Schaut doch einfach in unserem Online-Store vorbei. Wenn Ihr Lösungen sucht, die ins Rack eingebaut werden können, dann empfehlen wir das Braintower Rack Edition, optional mit dem Cluster Feature.

Andreas Wienkop
Andreas Wienkop
Office Manager

Andreas ist seit 2015 bei NETWAYS. Im November 2018 hat er seine Ausbildung zum IT-Systemkaufmann erfolgreich abgeschlossen und ist nun im Bereich Finance & Administration tätig. In seiner Freizeit widmet er sich dem Reisen und dem Boxen.

Blacklists prüfen mit check_rbl

The_Blacklist_logo.svgBlacklists sind prinzipiell nichts schlechtes. Sie helfen zu verhindern, dass ein Unternehmen oder eine Privatperson mit Spam oder ähnlichem Übel gestört werden oder vielleicht sogar Schaden davon tragen.
Gelegentlich kommt es jedoch vor, dass ein Unternehmen oder eine Privatperson auf einer Blacklist landen, obwohl sie keine negativen Absichten verfolgen. Ein Grund hierfür kann zum Beispiel das Versenden von Newslettern sein, wodurch ein erhöhtes Mailaufkommen von bestimmten Systemen verzeichnet wird und Mails als “Spam” markiert werde. Als Folge dessen wird für die versendenden Server ein Eintrag auf einer Blacklist angelegt. Der Nachteil für den Betroffenen ist, dass er keine Benachrichtigung bekommt, mit dem Hinweis, auf einer Blacklist markiert worden zu sein.
Wir bei NETWAYS wollen aber kontrollieren, ob unsere Server oder die von unseren Kunden bei gewissen Systemen einen Eintrag besitzen und können dies auch überprüfen. Eine sehr elegante Möglichkeit wird hierfür mit dem check_rbl gegeben. Dieser Check durchforstet gegebene Blacklists von Servern nach einem gefragten Server.
Ein kleines Beispiel wird die Funktionsweise aufzeigen:
check_rbl -t 60 -H netways.de \
-s cbl.abuseat.org \
-s dnsbl.cyberlogic.net \
-s bl.deadbeef.com \

So würde der Check überprüfen, ob Einträge für den Host “netways.de” auf den Servern, die mit dem “-s” Parametern übergeben wurden, vohanden sind und ein “warning” beziehungsweise “critical” auslösen. Eine weitere gute Erläuterung der Funktionsweise dieses Checks findet man auf GitHub oder auf dem Icinga-exchange.

Marius Gebert
Marius Gebert
Systems Engineer

Marius ist seit 2013 bei NETWAYS. Er hat 2016 seine Ausbildung zum Fachinformatiker für Systemintegration absolviert und ist nun im Web Services Team tätig. Hier kümmert er sich mit seinen Kollegen um die NWS Plattform und alles was hiermit zusammen hängt. 2017 hat Marius die Prüfung zum Ausbilder abgelegt und kümmert sich in seiner Abteilung um die Ausbildung unserer jungen Kollegen. Seine Freizeit verbringt Marius gerne an der frischen Luft und ist für jeden Spaß zu...

Perl-Plugins standardisieren

Im Icinga- bzw. Nagios-Umfeld wird für Plugins gerne Perl eingesetzt. Das Monitoring Plugins Projekt stellt mit dem Monitoring Perl-Modul eine standardisierte Schnittstelle zur Verfügung mit der sich schnell und einfach eigene Plugins programmieren lassen, die den Richtlinien für Plugins entsprechen.
Auszüge aus einem Plugin zum Abfragen des Status eines Apache-Webservers soll den generellen Aufbau verdeutlichen. Das komplette Skript ist auf Github veröffentlicht.

$plugin = Monitoring::Plugin->new;

Zuerst instantiert man neues Objekt und bereitet mit der Methode Getopt->new die Verarbeitung von Optionen vor.

$options = Monitoring::Plugin::Getopt->new(
  usage   => 'Usage: %s [OPTIONS]',
  version => $VERSION,
  url     => 'https://github.com/lbetz/nagios-plugins',
  blurb   => 'Check apache server status',
);

Optionen mit beschreibenden Text für den Aufruf des Plugins werden dem Objekt mit der Methode arg hinzugefügt. Mit spec wird die Variable festgelegt in der, der Wert der Option abgelegt wird. Die Variable lautet hier hostname. Nach der Pipe folgt die Option für das Plugin, hier ein H. Die Zuweisung des Buchstabens s bedeutet, dass hier ein String übergeben wird.

$options->arg(
  spec     => 'hostname|H=s',
  help     => 'hostname or ip address to check',
  required => 1,
);

Weitere Typen sind i für einen Integer oder das als Suffix angehängte + für einen Schalter. Mit -s wird also gesteuert, dass die Anfrage via HTTPS zu erfolgen hat. getopts erledigt dann die Übernahme der Optionen in Variablen.

$options->arg(
  spec     => 'port|p=i',
  help     => 'port, default 80 (http) or 443 (https)',
  required => 0,
);
$options->arg(
  spec     => 'ssl|s+',
  help     => 'use https instead of http',
  required => 0,
);
$options->getopts();

Ausgehend davon, dass auch die üblichen Optionen für Schwellwerte implementiert sind, kann ein Threshold-Objekt erzeugt werden. Dieses wird später für die Status-Ermittlung herangezogen.

$threshold = Monitoring::Plugin::Threshold->set_thresholds(
  warning  => $warning,
  critical => $critical,
);

Die aus den Optionen ermittelten Variablen lassen sich nun für den HTTP-Request benutzen.

$request = HTTP::Request->new(GET => 'http://'.$options->hostname.'/server-status/?auto');

Nachfolgend ist der HTTP-Response auszuwerten. Hier ist in $OpenSlots die Anzahl der noch zur freien Verfügung stehen Slots abgelegt.

$plugin->add_perfdata(
  label => 'OpenSlots',
  value => $OpenSlots,
  uom   => q{},
  threshold => $threshold,
);

Performance-Daten lassen sich mit der Methode add_perfdata dem Pluginoutput hinzufügen, hier OpenSlots=n. Abschließend wird in Abhängigkeit der Schwellwerte der Return Code berechnet und das Plugin mittels exit beendet.

$plugin->nagios_exit($threshold->get_status($OpenSlots), 'some plugin output');
Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.