Seite wählen

NETWAYS Blog

Die Extrawurst

Icinga Web 2 bietet eine Reihe von Möglichkeiten, Gruppen-Mitgliedschaften zuzuweisen. Am häufigsten werden Gruppenmitgliedschaften entweder via Web angelegt oder aus einem LDAP-Verzeichnis gezogen. Der bekannteste Vertreter dabei ist Microsofts Active Directory.
Weniger bekannt ist, dass man in eigenen Modulen Benutzer- sowie Gruppenmitgliedschafts-Backends bereitstellen kann. Manchmal braucht man aber gar nicht ein volles Backend, sondern nur ein paar kleine Korrekturen. Aus einem solchen Grund entstand diese Woche in einem Kundenprojekt ein neues Icinga Web 2 Modul: Extragroups.

Zusätzliche Gruppen für jeden

Einmal installiert, lassen sich in der config.ini des Moduls flexible Regeln definieren.
[Jeder ist ein Mimimi]
add_groups = "Mimimi"

Das allein hat erst mal keinen Effekt, also hinterlegen wir in der /etc/icingaweb2/roles.ini eine Rolle, welche unseren Usern eine entsprechende Einschränkung verpasst:
[Mimimi Demo]
groups = "Mimimi"
monitoring/filter/objects = "host_name=*mi*"

Sobald wir uns neu anmelden sind wir Mitglied der Gruppe „Mimimi“ und sehen nur noch Hosts welche „mi“ enthalten. Dabei ist nebensächlich, ob eine Benutzergruppe namens „Mimimi“ existiert oder nicht.

Mustervergleich mit Benutzernamen

Lasst uns das Ganze ein wenig einschränken:
[Alle Heuler sollen Mimimis werden]
user_filter = "username=*heul*"
add_groups = "Mimimi"

Was hier passiert dürfte klar sein, wir machen nur noch unsere Heuler zu Mimimis.

Regeln basierend auf Umgebungsvariablen

Ihr möchtet alle Benutzer mit ein paar Ausnahmen in eine spezielle Gruppe geben, aber nur wenn diese remote arbeiten? Erstellt einfache eine auf deren IP-Range basierende Regel:
[Einschränkung wenn via VPN verbunden]
env_filter = "REMOTE_ADDR=192.0.2.*"
user_filter = "username!=tom&username!=admin"
add_groups = "Via VPN verbunden"

Ähnlich wie REMOTE_ADDR in diesem Beispiel können alle vom Web-Server bereitgestellten Umgebungsvariablen benutzt werden. Im nächsten Beispiel zeigen wir Netzwerk-Admins welche via Nagstamon angemeldet sind lediglich wirklich wichtige Hosts und Services:
[Filter für Nagstamon]
env_filter = "HTTP_USER_AGENT=Nagstamon*"
user_filter = "group=Network Admin"
add_groups = "VIP objects filter"

VORSICHT: Der User-Agent kann einfachst gefälscht werden. Dieses Beispiel dient dem Komfort unserer Benutzer: sie wollen in Nagstamon nicht mit allen Problemen belästigt werden. Für sicherheitskritische Regeln taugt der User-Agent nicht.

Mehrere Gruppen zuweisen

Manchmal will man mehrere Gruppen auf einmal zuweisen, ohne die ganze Regel zu klonen. Das lässt sich einfach bewerkstelligen, denn add_groups akzeptiert eine Komma-getrennte Liste:
[VPN-Benutzer einschränken]
; ..
add_groups = "Eingeschränkte Benutzer, Spezielle Dashboards, Business-Prozesse"

Soll die Gruppenliste noch dynamischer sein? Vorausgesetzt dass ein Webserver-Modul oder dessen Konfiguration diese Information bereitstellt, lässt sich jede Umgebungsvariable via {VARIABLE_NAME} nutzen:
[Gruppen des SSO-Moduls zuweisen]
add_groups = "{HTTP_AUTHZ_GROUPS}"

Auch in Strings die aus Umgebungsvariablen kommen funktioniert das Komma (,) als Trennzeichen. Und man kann natürlich Variablen-Platzhalter mit statischen Werten kombinieren:
[Eine Reihe von Gruppen]
add_groups = "Spezial-Gruppe, {REMOTE_GROUPS}, {HTTP_AUTHZ_GROUPS}"

Auf Gruppenmitgliedschaften basierende Regeln

Der user_filter erlaubt auch Regeln basierend auf bereits zugewiesene Gruppen. In unserem umfangreicheren letzten Beispiel erhalten alle Benutzer zusätzliche Gruppenmitgliedschaften via HTTP_AUTHZ_GROUPS. Na gut, jeder außer der guest und der admin-Benutzer.
Wenn sie Nagstamon nutzen während sie via VPN verbunden sind, sollen sie zusätzlich in die Gruppe Nagstamon Remote kommen.
Wird Nagstamon ohne VPN benutzt, sollen Mitglieder der Gruppen „Linux Benutzer“ und/oder „Unix Benutzer“ in die Gruppe „Nagstamon Lokal“ kommen. Alle außer dem admin:
[Gruppen des SSO-Moduls zuweisen]
add_groups = "{HTTP_AUTHZ_GROUPS}"
user_filter = "user_name!=guest&username!=admin"

[Nagstamon via VPN]
env_filter = "REMOTE_ADDR=192.0.2.*&HTTP_USER_AGENT=Nagstamon*"
add_groups = "Nagstamon Remote"

[Nagstamon ohne VPN]
env_filter = "REMOTE_ADDR!=192.0.2.*&HTTP_USER_AGENT=Nagstamon*"
user_filter = "username!=admin&(group=Linux Benutzer|group=Unix Benutzer)"
add_groups = "Nagstamon Local"

Dabei gilt es zu beachten, dass der Filter basierend auf die group-Eigenschaft nur Gruppen sieht, welche von vorhergehenden Regeln zugewiesen wurden. Von anderen Backends bereitgestellte Gruppenmitgliedschaften sind nicht zugänglich.
Das war’s auch schon, viel Spaß!

Thomas Gelf
Thomas Gelf
Principal Consultant

Der gebürtige Südtiroler Tom arbeitet als Principal Consultant für Systems Management bei NETWAYS und ist in der Regel immer auf Achse: Entweder vor Ort bei Kunden, als Trainer in unseren Schulungen oder privat beim Skifahren in seiner Heimatstadt Bozen. Neben Icinga und Nagios beschäftigt sich Tom vor allem mit Puppet.

Icinga 2 – Monitoring automatisiert mit Puppet Teil 4: Konfiguration I

Im ersten Teil zur Konfiguration von Objekten, die überwacht werden sollen, widmen wir statischen Dateien, die nicht von Define Resources des Moduls verwaltet werden. Zuerst beschäftigen wir uns jedoch mit dem Parameter confd der Main-Class icinga2. Als Werte werden die Boolean-Werte true und false akzeptiert oder auch eine Pfadangabe. Beim Defaultwert true wird das Verzeichnis /etc/icinga2/conf.d rekursiv in die Konfiguration in /etc/icinga2/icinga2.conf eingebunden. Bei der Verwendung von false entfällt diese Eintrag ersatzlos, hilfreich beim Konfigurieren von verteilten Szenarien der Überwachung.

class { '::icinga2':
  confd => '/etc/icinga2/local.d',
}

Die Angabe eines Pfades, wird das entsprechende Verzeichnis rekursiv als Konfiguration eingelesen. Um die Existenz müssen wir uns jedoch selber kümmern. In diesem Beispiel kopieren wir einmalig die im Paket mitgelieferte Beispielkonfiguration, als Grundlage für weitere Konfigurationen.

file { '/etc/icinga2/local.d':
  ensure  => directory,
  owner   => 'icinga',
  group   => 'icinga',
  mode    => '0750',
  recurse => true,
  replace => false,
  source  => '/etc/icinga2/conf.d',
  tag     => 'icinga2::config::file',
}

Damit diese File- oder Concat-Resources im Zusammenhang mit den anderen Resources in der korrekten Reihenfolge abgearbeitet werden ist das Tag icinga2::config::file von entscheidender Bedeutung. Handelt es sich bei der File-Resource nicht um ein Verzeichnis, wird automatisch ein Reload von icinga2 veranlasst. Letzteres kann unterdrückt werden, indem in der Main-Class das Verwalten des Services ausgeschaltet (manage_service => false) wird, daraus folgt aber, dass man den Service gesondert selbst managen muss.

file { '/etc/icinga2/local.d/my_hosts.conf':
  ensure => file,
  owner  => 'icinga',
  group  => 'icinga',
  mode   => '0640',
  source => 'puppet:///modules/profile/icinga2/my_hosts.conf',
  tag    => 'icinga2::config::file',
}

Das selbe Vorgehen kann analog auch mit einer Concat-Resource aus dem Modul gleichen Namens benutzt werden.

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.

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
Manager Sales

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Manager Sales 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".

Letzter Aufruf für das Icinga Web 2 Webinar

icinga_logo_200x69 Nachdem letzte Woche erfolgreich die Open Source Monitoring Conference (OSMC) stattgefunden hat und aufgrund der vielen Info-Blogposts der ein oder andere vielleicht den Webinar-Reminder übersehen hat, möchte ich natürlich kurz vor dem Icinga Web 2 Webinar noch einmal darauf aufmerksam machen.
Morgen um 10:30 Uhr wollen wir die aktuelle Version von Icinga Web 2 inkl. der eingebauten Features und den Installer vorstellen. Eine Registrierung ist natürlich bis morgen Früh noch möglich.
Wer sich für die nächsten Webinare in diesem Jahr noch interessiert, kann sich natürlich auch gleich registrieren:

Webinar Thema Termin und Registrierung
Puppet: Windows Configuration Management 12. Dezember 2014 – 10:30 Uhr
NETWAYS: Jahresrückblick 2014 18. Dezember 2014 – 10:30 Uhr

In unserem Webinar-Archiv findet man auch noch die bisherigen Webinare, um die Wartezeit zu überbrücken.
Bis morgen!

Christian Stein
Christian Stein
Manager Sales

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Manager Sales 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".

Google-Analytics in Prestashop richtig verwenden

Seit nun fast 4 Monaten betreiben wir unseren Online-Shop nicht mehr mit Magento, sondern mit PrestaShop. Dies bringt bereits ein Google-Analytics Plugin mit. Man gibt nur die Web-Property-ID ein und los geht’s.
Nachdem wir die Daten nun auswerten wollten, sind uns zwar die Nutzerzahlen zu den Vormonaten plausibel erschienen, jedoch waren alle Aufrufe in die Systemeigenen URLs gepackt.
So waren alle Produktaufrufe in /product und alle Kategorieklicks in /category gebündelt eingeordnet. Dies nützt ein natürlich wenig, wenn man genau sehen will, welches Produkt sich gut verkauft und welches nicht.
before
Mit wenigen Änderungen am Sourcecode des Google-Analytics Moduls behebt man jedoch diesen „Fehler“:

  • auf den Shopserver verbinden
  • in das Verzeichnis von PrestaShop wechseln
  • in das Verzeichnis modules/ganalytics/ wechseln
  • die Datei ganalytics.php vorher sichern
  • ganalytics.php mit einem Editor der Wahl öffnen
  • folgenden Abschnitt suchen
$file = str_replace(array('.php', '-'), '', basename($_SERVER['SCRIPT_NAME']));
  • um folgenden Code ergänzen
if($file == "category" ||
$file == "product" ||
$file == "search" ||
$file == "cms" ||
$file == "index") {
$file = $_SERVER["REQUEST_URI"];
}
  • noch einmal kontrollieren
$file = str_replace(array('.php', '-'), '', basename($_SERVER['SCRIPT_NAME'])); 
if($file == "category" ||
$file == "product" ||
$file == "search" ||
$file == "cms" ||
$file == "index") {
$file = $_SERVER["REQUEST_URI"];
}
  • speichern
  • fertig

after
Schon am nächsten Tag sammelt Google-Analytics die richtigen URLs ein.