Annotations in Grafana

Im Zuge der diesjährigen Open Source Monitoring Conference durfte ich mit Timeseries & Analysis with Graphite and Grafana einen der Workshops am Vortag der eigentlichen Konferenz halten. Wie man dem Titel unschwer entnehmen kann spielte dabei auch Grafana eine besondere Rolle. Grafana ist vielen als schöneres Dashboard für Graphite bekannt und unterstützt mit Elasticsearch, CloudWatch, InfluxDB, OpenTSDB, Prometheus, MySQL als auch Postgres in der aktuellen Version 4.6.2 allerdings noch eine ganze Reihe weiterer Datensourcen nativ. Zusätzlich können diese herkömmlichen Datensourcen auch noch durch Community Plugins ergänzt werden.

Ganz besonders hilfreich ist es wenn man die Informationen aus verschiedenen Datensourcen miteinander vereint. So lassen sich beispielsweise Zusammenhänge besser erkennen und Rückschlüsse auf bestimmte Ereignisse ziehen, die ansonsten vielleicht unentdeckt blieben. Metriken, die z.B. aus Graphite stammen, können bei Grafana nun durch sogenannte Annotations um zusätzliche Informationen angereichert werden. Neben Annotations aus den unterstützten Datensourcen können solche Events seit v4.6 übrigens auch direkt in der eigenen Grafana-Datenbank gespeichert werden, ob man das wiederum möchte ist allerdings eine ganz andere Frage…

Als Praxisbeispiel habe ich für meinen Workshop im Rahmen der OSMC überraschenderweise Icinga gewählt. Hier ist es möglich über die Icinga 2 API verschiedene Daten wie Checkergebnisse, Statusänderungen, Benachrichtigungen, Bestätigungen, Kommentare oder auch Downtimes mit dem Icingabeat direkt an Elasticsearch oder wenn man möchte alternativ auch an Logstash zu senden. Über das Annotation-Feature von Grafana lassen sich so die Benachrichtigungen aus Icinga über die Elasticsearch Datasource passend zu den jeweiligen Statusänderungen der Host- oder Serivcechecks einblenden:

Wer dazu mehr erfahren möchte dem kann ich unsere Graphite + Grafana Schulung ans Herz legen, neben vielen anderen Themen werden dort auch Grafana und Annotations in aller Ausführlichkeit behandelt. Und wer’s nicht schafft, für den findet sich vielleicht der ein oder andere passende Workshop im Rahmen unserer Konferenzen.

Markus Waldmüller

Autor: Markus Waldmüller

Markus war bereits mehrere Jahre als Systemadministrator in Neumarkt i.d.OPf. und Regensburg tätig. Nach Technikerschule und Selbständigkeit ist er nun Anfang 2013 bei NETWAYS als Lead Senior Consultant gelandet. In seiner Freizeit ist der sportbegeisterte Neumarkter mit an Sicherheit grenzender Wahrscheinlichkeit auf dem Mountainbike oder am Baggersee zu finden.

Unternehmensfortbildung NETWAYS-Style

Als ich am 01. September meine Ausbildung bei NETWAYS begonnen habe, bemerkte ich sofort die kollegiale und angenehme Atmosphäre unter den Kollegen. Diese positive Ausstrahlung hält noch bis heute an, dennoch kommt sie nicht von Ungefähr. Viele Events und Abendveranstaltungen werden immer als Team besucht. Um den Zusammenhalt noch weiter zu stärken gab es vom 30.11 – 01.12 die Premiere der ersten „NETWAYS Startupdays“, welche eine teamübergreifende Zusammenarbeit in den Vordergrund stellen soll.

Im Vorfeld wurden zahlreiche Ideen gesammelt und am Donnerstag vom jeweiligen Ideengeber als Pitch vorgestellt:

  • NWS Marketing, neue Unternehmensbroschüre
  • Interner Shop
  • NETWAYS Konferenz Ticket Plattform
  • Control Panel Raspberry PIs, Dashing Container
  • Icinga 2 SNMP Monitoring
  • Chatbot
  • Donation Backend / Platform based on Blockchain

Nach dem Pitch konnte sich jeder Mitarbeiter einem „Ideenteam“ anschließen, dabei war es wichtig, dass sich Teams aus unterschiedlichen Abteilungen bilden um neue, frische Ideen zu generieren. Gleich nach der Teambildung verteilten sich die Arbeitsgruppen im Büro und haben mit der Arbeit begonnen. Was mir sehr gut gefallen hat, war die interdisziplinäre Arbeit zwischen den technischen und nicht technischen Abteilungen. Durch diesen Mix konnten Ideen gefunden werden welche man durch eventuelle festgefahrene Denkweisen nicht generieren hätte können. Zum Mittagessen gab es eine bayerische Spezialität: Weißwurst mit Breze.  Am zweiten Tag wurde engagiert weitergearbeitet, bis es „NETWAYS-typisch“ ein zünftiges Mittagessen gab. Gut gestärkt ging es in die finale Phase und das NETWAYS-Team hat sich im Schulungs- und Trainingszentrum eingefunden um anschließend die ausgearbeiteten Ideen und bis dahin umgesetzten Themen vorzustellen.

This slideshow requires JavaScript.

 

Philipp Dorschner

Autor: Philipp Dorschner

Philipp hat im September 2017 seine Ausbildung zum Fachinformatiker gestartet. Er hat sogar schon eine Ausbildung im Gepäck und zwar zum technischen Assistenten für Informatik. Danach hat hat er sein Abi nachgeholt und anschließend begonnen Wirtschaftswissenschaften zu studieren. Da sein Herz während des Studiums ständig nach technischen Inhalten geschrien hat, wechselte er zu Verfahrenstechnik. Aber auch dieses Studium konnte Ihn nicht erfüllen, weshalb er sich für die Ausbildung bei NETWAYS entschieden hat, “back to the roots” quasi!

12 years of OSMC – The conference is open

***For English Version please scroll down.***

Nachdem der erste Tag mit vier ausgebuchten Workshops erfolgreich zu Ende ging, gab es beim ersten gemeinsamen Abendessen bereits die Möglichkeit, sich kennen zu lernen und auszutauschen. Zu späterer Stunde wurde die Runde zwar kleiner, aber keinesfalls langweiliger. Weiter ging es in der gemütlich eingerichteten Konferenzlounge, wo der erste Abend seinen fröhlichen Ausklang fand.
Nach der ersten Nacht in den renovierten Hotelzimmern im Holiday Inn, kamen am Mittwoch Morgen die restlichen Teilnehmer gut in Nürnberg an und mit Bernd’s Opening fiel auch endlich der Startschuss für die Vorträge der 12. OSMC. 16 spannende, witzige und lehrreiche Vorträge waren geboten. Hierzu erfahrt ihr alle Details von Dirk und selbstverständlich – wie gewohnt – nach der Konferenz auf unserem YouTube Channel und auf Slideshare.
Neben den Vorträgen ist die OSMC auch für das reichliche Essen bekannt was freilich in diesem Jahr auch nicht zu kurz kam. Nach den gesunden Pausensnacks, konnte beim Mittagessen nach Belieben ausgiebig geschlemmt werden, um sich von den Vorträgen des Vormittags zu erholen und Kraft für den langen Tag zu tanken.
Heute Abend findet schließlich ein weiteres Highlight statt. Die OSMC Abendveranstaltung im Nachtkind meets Guilia. Freut euch schon jetzt auf ein außergewöhnliches Get Together im Herzen Nürnbergs mit einigen spaßigen Überraschungen.  Wer nun an die Evening Events der letzten OSMC’s denkt, wird sich auch auf den traditionellen nächtlichen Marsch von der Abendveranstaltungslocation zum berühmt berüchtigten “Checkpoint Jenny”(*). Die alten Hasen haben bereits entdeckt, dass an besagtem Platz kein Schild mit der Aufschrift “Checkpoint Jenny” zu finden war. Stattdessen prangte hier nun ein “Lambada” Schild. “Häää, wo ist die Jenny?!?”, dachten sich wohl viele. Unsere geliebte Jenny musste den Laden leider verkaufen. Nun gut, selbe Location, neuer Name, aber wir werden bleiben. Und da wir damals eh schon einen 20 Jahresvertrag (mindestens 20) abgeschlossen haben, werden wir auch den neuen Namen akzeptieren und wie gewohnt unsere Tradition fortführen, das wäre doch gelacht!
Wir jedenfalls sind schon voller Vorfreude auf das Event und gespannt, was die nächsten Tage noch so bringen werden. Wir halten euch wie immer auf dem neuesten Stand. 🙂

*: Anm. der Redaktion: Weltberühmte, erstklassige” Late Night Lounge” gegenüber des Konferenzhotels, welche all denjenigen, die von der Abendveranstaltung nicht genug kriegen konnten, stets eine herzliche, gemütliche Atmosphäre bis tief in die Nacht bietet.

___________________________________________________________________________________________________________________________________________________________

After the four fully booked workshops on the first conference day, our first dinner was the perfect setting for getting to know each other and for exchanging experiences. The group shrunk throughout the evening, but our mood didn`t! After dinner we ended the day in the comfortable and cozy conference lounge.

The first night was spent in the newly refurbished rooms of the Holiday Inn, and on Wednesday morning the rest of the attendees arrived in Nuremberg. Bernd`s opening launched the talks in the 12th OSMC. 16 exciting, fun and informative talks awaited us. Dirk will give you all the details on them, and you will of course- as usual- find them on our YouTube channel and on our slide-share after the conference.

Beside the talks the OSMC is known for lots of food, and this year is no exception. After healthy snacks in the breaks, everyone could feast on the generous lunch buffet, and gain strength for the afternoon talks.

Tonight, another highlight takes place. The OSMC evening event at Nachtkind meets Guilia. You can look forward to an extraordinary get together in the heart of Nuremberg with several fun surprises.

But the ones` who look back upon the evening events of the last OSMC`s will remember the nightly walk from the evening event to our notorious “Checkpoint Jenny” (*). Our “regulars” have already noticed that the “Checkpoint Jenny” sign is missing and that a “Lambada” sign hangs in its´ place.  Many attendees thought (and twittered) about the missing Jenny. Unfortunately our beloved Jenny had to sell her bar. So, same location, different name, but we are staying.  And since we “signed” a contract for at least 20 years back then, we will accept the new name and stick with our tradition. We are looking forward to the event, and are excited to see what awaits us in the next few days. We will of course keep you posted!

*: World famous, first class “Late night lounge” vis-à-vis the conference hotel, that offers a welcoming atmosphere for those who didn`t get enough of the evening event.

Julia Hackbarth

Autor: Julia Hackbarth

Julia hat 2017 ihre Ausbildung zum Office Manager bei NETWAYS absolviert und währenddessen das Events&Marketing Team kennen und lieben gelernt. Besondere Freude bereiten ihr bei NETWAYS die tolle Teamarbeit und vielseitige Herausforderungen. Privat nutzt Julia ihre freie Zeit, um so oft wie möglich über’s Handballfeld zu flitzen und sich auszutoben. In ihrer neuen Rolle als Marketing Managerin freut sie sich auf spannende Aufgaben und hofft, dass ihr die Ideen für kreative Texte nicht so schnell ausgehen.

Der NETWAYS-Monitor – neu

Mit Stolz konnten wir Anfang Oktober die ersten Seriengeräte unserer ersten selbst entwickelten Hardware in Empfang nehmen – unseren Monitor – und sie umfangreichen Tests unterziehen.
Als bekannter Spezialist nutzen wir hierfür natürlich unser umfassendes Know-how über Icinga 2
An diesen Monitor lassen sich, quasi per Plug & Play, bis zu 4 Sensoren anschließen, die die Temperatur und Feuchtigkeit in beliebigen Umgebungen messen und an den Monitor melden – bis zu einer Entfernung von je rund 300 Meter. Die Anbindung erfolgt dabei mit Handelsüblichen CAT5/6/7 Kabeln.
Ein einfaches, ebenfalls von uns entwickeltes Web-GUI zeigt die jeweiligen Werte an und erlaubt darüber hinaus die Einstellung von Alarmierungswerten.

 

 

 

 

 

Inzwischen konnten auch bereits die ersten Systeme – mit der neuesten Firmware – an verschiedene Kunden ausgeliefert werden.
Die aktuelle Nachfrage übersteigt erfreulicherweise unsere Erwartungen. Wobei wir auch über die Anwendungsideen überrascht sind. Wir haben nicht nur Anfragen aus dem IT-typischen Bereich, also Temperatur- und Feuchtigkeitsüberwachung in Rechenzentren, Serverräumen und für -Racks, sondern auch z.B. von Speditionen zur Lagerraumüberwachung.
Besonders interessant empfanden wir die Anfrage eines renommierten Weinhändlers, der mit unserem Monitoring-System seine Weinlagerkühlschränke überwachen möchte – und damit ein zusätzliches Verkaufsargument gegenüber seinen Kunden erhält.
Insofern fragen wir uns jetzt, wann sich der erste Tabakhändler in Bezug auf die Feuchtigkeitsmessung meldet.

Wir hier im Sales-Team der NETWAYS GmbH freuen uns jedenfalls auf Ihre für uns spannenden Anfragen oder Kommentare – zögern Sie bitte nicht, mit uns Kontakt aufzunehmen.

Manfred Schlutz

Autor: Manfred Schlutz

Manfred ist seit Oktober 2017 als Senior Account Manager bei NETWAYS tätig. Schon seit 1981 kümmert er sich bei verschiedenen Firmen um vertriebliche Angelegenheiten, zuletzt war er elf Jahre im Hardwaregeschäft als Key Accounter tätig. Besonders gut an seinem Job gefällt ihm, dass er jeden Tag auf’s Neue andere Menschen kennenlernt. In seiner Freizeit genießt es der gebürtige Münsterländer besonders, sich seinem Hobby, dem Modellbau zu widmen. Weitere heiße Diskussionsthemen für eure Unterhaltung mit Manfred sind Politik, Geschichte und IT!

Postfix – SPF, DKIM und DMARC

In der heutigen Zeit werden E-Mails oftmals nicht mehr über einen einzelnen Server verschickt. Wie sollten große Anbieter es sonst schaffen alle E-Mails Ihrer Millionen Nutzer zeitnah abzuhandeln? Spätestens wenn es zu Versand von Newslettern kommt, wird auf mehrere Server zurückgegriffen, damit zum Beispiel E-Mails der Mitarbeiter nicht in einer Warteschlange landen mit 100.000 Newslettern.

Damit diese Server vom Empfänger verifiziert werden können wurden die Mechanismen SPF, sowie DKIM eingeführt. Basierend auf diesen beiden kam später noch DMARC hinzu. Im folgenden möchte ich beschreiben, wie man diese Mechanismen mit Postfix verbindet und entsprechende Informationen publiziert.

 

SPF – Sender Policy Framework

Fangen wir mit SPF an. Bei SPF wird im DNS einer Domain ein TXT-Record hinterlegt. Dort gibt man in einer bestimmten Syntax an, welche Server für diese Domain verifiziert sind. Beispielhaft sieht ein SPF Record in etwa so aus:

v=spf1 ip4:1.2.3.4 ip4:1.2.3.5 a:mx.domain.tld include:other-domain.tld ?all

Dieser sagt aus, dass Mails von der IPv4 Adresse 1.2.3.4 und 1.2.3.5 verschickt werden dürfen, sowie vom Server hinter dem A-Record mx.domain.tld. Zudem sollen die Einstellungen der Domain other-domain.tld included werden und über alle anderen soll keine weiter Aussage getroffen werden mit ?all. Mit “-all” würde man den Versand über alle anderen Mailserver verbieten. Dies kann jedoch zu Problemen führen in Szenarien, wie Beispielsweise bei der Weiterleitung von Mails. Bitte beim include aufpassen, hier gibt man einiges aus der Hand, wenn “other-domain.tld” nicht von einem selbst verwaltet wird.

SPF mit Postfix verbinden

apt-get install postfix-policyd-spf-python

Anschließend öffnen wir die Datei /etc/postfix/master.cf und fügen folgendes hinzu:

postfix-policyd-spf unix – n n – 0 spawn user=policyd-spf argv=/usr/bin/policyd-spf

Und um die policy auch zu verwenden, editieren wir die smtpd_recipient_restrictions in /etc/postfix/main.cf. Bitte beachtet, dass ihr diese unbedingt NACH reject_unauth_destination einfügt.

smtpd_recipient_restrictions = … reject_unauth_destination check_policy_service unix:private/postfix-policyd-spf …

Danach restarten wir postfix. Bei eingehenden Mails sollte nun ein Header enthalten sein, der in etwa wie folgt aussieht:

Received-SPF: Pass (sender SPF authorized) …

Weitere Einstellungen kann man noch unter /etc/postfix-policyd-spf-python/policyd-spf.conf vornehmen.

 

DKIM – DomainKeys Iidentified Mail

DKIM verfolgt ebenfalls das Ziel den Absender zu verifizieren, jedoch mit anderem Ansatz. Dabei werden Headerdaten, die man auch selbst definieren kann mittels eines privaten Schlüssels signiert, während sich der öffentliche Schlüssel im DNS der jeweiligen Domain befindet. Wo dieser genau zu finden ist, bestimmt der Selector – dazu aber gleich noch mehr. Sollte man die Headerdaten, welche signiert werden sollen, selbst definiert, sollte man unbedingt darauf achten, dass es Header sind, die im Verlauf des Versands nicht verändert werden, mehr dazu aber auch im RFC6376 – Abschnitt 5.4.

Beide Verfahren dienen nur dazu den Absender zu verifizieren, es bietet daher keinen Spamschutz im eigentlichen Sinn, wie manche sich vielleicht erhoffen. Sie sind aber relativ schnell eingerichtet und manche Mailserver und Dienste bewerten Mails mit gültigem SPF und DKIM besser, daher ist die Einrichtung kein absolutes “Muss”, aber dennoch ein “Nice-to-have”.

OpenDKIM mit Postfix verbinden

apt-get install opendkim opendkim-tools

Bevor wir nun mit opendkim und postfix weiter machen generieren wir erst einmal Keys, die wir verwenden möchten:

mkdir -p /etc/opendkim/keyfiles/domain1.tld
cd /etc/opendkim/keyfiles/domain1.tld
opendkim-genkey -s mail -d domain1.tld

Damit werden zum einen die Datei mail.private generiert, die den privaten Schlüssel beinhaltet, sowie mail.txt. welche den öffentlichen Schlüssel beinhaltet. Der oben genannte Selector ist “mail”. Den öffentlichen Schlüssel können wir daher schon im DNS der Domain domain1.tld hinterlegen. Dabei handelt es sich um einen Textrecord, der in unserem Beispiel unter mail._domainkey.domain.tld hinterlegt sein muss. Ist dies erledigt geht es weiter in der Konfiguration.

Anschließend ist die Datei /etc/opendkim.conf wichtig, hier wird die zentrale Konfiguration von opendkim vorgenommen. Beispielsweise so kann eine Konfiguration aussehen:

Mode sv
AutoRestart Yes
AutoRestartRate 10/1h
UMask 002
UserID opendkim:opendkim
Syslog yes
KeyTable /etc/opendkim/KeyTable
SigningTable refile:/etc/opendkim/SigningTable
Canonicalization relaxed/relaxed
LogResults yes
LogWhy yes
SyslogSuccess yes
Socket inet:10080@localhost
SignatureAlgorithm rsa-sha256

Wichtig sind hier zum einen der Port, zum anderen aber natürlich die beiden Parameter KeyTable und SigningTable. Weitere Konfigurationsparameter kann man in der Dokumentation der offiziellen Seite von opendkim nachlesen. Gehen wir aber weiter in unserem Beispiel. Ein Keytable kann z.B. wie folgt aussehen:

mail._domainkey.% %:mail:/etc/opendkim/keyfiles/domain.tld/mail.private

Das “%” in diesem Beispiel ist ein Platzhalter für die jeweilige Domain. Es werden daher alle Domains mit dem privaten Schlüssel signiert, welcher unter /etc/opendkim/keyfiles/domain.tld/mail.private liegt. Als selector wird “mail” verwendet. Sollte man für jede Domain einen anderen Key verwenden, was auch im Normalfall so ist, dann kann man einfach folgende Änderungen vornehmen:

mail._domainkey.domain1.tld domain1.tld:mail:/etc/opendkim/keyfiles/domain1.tld/mail.private
mail._domainkey.domain2.tld domain2.tld:mail:/etc/opendkim/keyfiles/domain2.tld/mail.private

Kommen wir zum SigningTable. Hier wird festgelegt, welche Mails mit welchem Eintrag im KeyTable signiert werden.

*@domain1.tld mail._domainkey.domain1.tld
*@domain2.tld mail._domainkey.domain2.tld

Auch hier kann man aber mit Wildcards und Platzhaltern arbeiten und Beispielsweise folgenden Eintrag setzen.

* mail._domainkey.%

Damit wird jede Mail signiert, mit mail._domainkey.<Name der Domain>

Will man nun noch postfix mit opendkim verbinden, ist es relativ einfach. Hier werden einfach entsprechende Einträge in der /etc/postfix/main.cf angehängt:

milter_protocol = 6
milter_default_action = accept
smtpd_milters = inet:localhost:10080
non_smtpd_milters = inet:localhost:10080

Danach einfach noch beide Services restarten und schon werden alle Mails entsprechend signiert.

 

DMARC – Domain-based Message Authentication, Reporting & Conformance

Mit DKIM und SPF haben wir schon zwei Mechanismen, mit denen ich als Absender gewisse Informationen weitergeben kann. Was der Empfänger damit anstellt ist jedoch ihm selbst überlassen. Lehnt Mailserver A eine Mail ab, weil der SPF Check fehlschlägt, lässt Mailserver B die Mail mit höherem Spamscore vielleicht durch. Die Bewertung liegt beim Empfänger, der neben SPF und DKIM noch viele weitere Checks implementiert hat um Spam entsprechend abzuwehren. Die Entscheidung, was nun mit der Mail im besten Fall passieren soll, soll DMARC dem Empfänger erleichtern und dem Sender ein wenig mehr Möglichkeiten geben.

Als Absender hinterlege ich im DNS einen entsprechenden Eintrag. Hier gibt es einige Variablen und zugehörige Optionen, die man setzen kann. Der Empfänger hingegen kann diese Empfehlung, die vom wirklichen Inhaber der Domain kommt nutzen um zu entscheiden was er mit der Mail passieren soll. Der DMARC Eintrag von Google sieht Beispielsweise wie folgt aus:

v=DMARC1; p=quarantine; sp=quarantine; rua=mailto:mailauth-reports@google.com

Dies dient lediglich als Beispiel, wer mehr über die Parameter und Optionen lesen möchte sollte den zugehröigen RFC7489 genauer ansehen

Damit ist auch schon alles getan, was man als Absender machen kann. Wichtig dabei ist der p-Parameter, der auf none (keine Aussage, Entscheidung liegt weiter beim Empfänger), quarantine (Dem Empfänger wird geraten bei einem fehlerhaften Check die Mail als Spam zu betrachten und ggf. in einen Spamordner zu verschieben), oder reject (Die Mail soll auf SMTP Ebene bereits abgelehnt werden) gesetzt werden kann. Es ist schwer hierbei eine Empfehlung oder ähnliches auszusprechen, da es immer auf den Fall an sich ankommt, welche Features man von DMARC im gegebenen Szenario verwenden möchte.

OpenDMARC mit Postfix verbinden

apt-get install opendmarc

Anschließend editieren wir die Datei /etc/default/opendmarc. Hier sind schon einige Beispiele angegeben und sind auch sehr selbsterklärend. Wir tragen folgendes ein:

SOCKET=”inet:12345@localhost”

Nun editieren wir noch die Konfiguration von DMARC, welche unter /etc/opendmarc.conf zu finden ist.

AuthservID mx.domain.tld
PidFile /var/run/opendmarc.pid
RejectFailures false
Syslog true
SyslogFacility mail
TrustedAuthservIDs localhost,mx.domain.tld
IgnoreHosts /etc/opendmarc/ignore.hosts
UMask 002
UserID
FailureReports false
AutoRestart true
HistoryFile /var/log/opendmarc.log
RecordAllMessages true
SoftwareHeader true

Danach editieren wir noch /etc/opendmarc/ignore.hosts

127.0.0.1

Die Option “SoftwareHeader true” ist eher für eure ersten Tests von Vorteil, da ihr in einem weiteren Header die verwendete Version und verarbeitete E-Mail sehen könnt:

DMARC-Filter: OpenDMARC Filter v1.3.1 mx.domain.tld A3DF6FFB75

Anschließend geht es an die Integration von OpenDMARC in Postfix. Da es sich hierbei um einen Mailfilter handelt, wird er an der bereits bekannten Stelle in der main.cf nach unserem DKIM Milter eingetragen.

smtpd_milters = inet:localhost:10080, inet:localhost:12345
non_smtpd_milters = inet:localhost:10080, inet:localhost:12345

Danach starten wir OpenDMARC und restarten Postfix. Nun sollten E-Mails einen Header enthalten, der in etwa so aussieht, falls der DMARC-Check erfolgreich war:

Authentication-Results: mx.domain.tld; dmarc=pass header.from=sender-domain.tld

Angemerkt sei, dass opemdmarc seit Version 1.3 auch selbst SPF Checks ausführen kann, falls es also bei jemandem Probleme geben sollte mit postfix-policyd-spf, kann auch der eigene SPF Check verwendet werden.

Fabian Rothlauf

Autor: Fabian Rothlauf

Fabian kehrte nach seinem fünfjährigen Ausflug nach Weimar zurück in seine Geburtsstadt Nürnberg und hat im September 2016 bei NETWAYS als Systems Engineer im Hosting Support angefangen. Der Mopsliebhaber, der schon seit seinem 16. Lebensjahr ein Faible für Adminaufgaben hat, liebt außerdem Grillen, Metal und Computerspiele. An seinem Beruf reizt ihn vor allem die Abwechslung, gute Weiterentwicklungsmöglichketen und dass es selten mal einen Stillstand gibt. Nachdem er die Berufsschulzeit bereits mit Eric und Georg genießen durfte, freut er sich bei NETWAYS nun auf weitere nette Kollegen, interessante Aufgaben und neue Blickwinkel.

Ungewöhnliche Überwachungen

Kuh auf WieseBei meinen Einsätzen als Consultant bei Netways bin ich oft bei Kunden vor Ort und darf mich immer wieder von der Unterschiedlichkeit der Monitoring Installationen überzeugen. Dabei fallen mir immer wieder kreative und ungewöhnliche Methoden auf neue Dinge zu überwachen. Über den Sinn und Unsinn dieser Checks darf zwar gerne gestritten werden, dennoch wollte ich euch ein paar Ideen nicht vorenthalten.

Check boss / Schwiegermutter

Dieser Check ist perfekt wenn du nicht von einem plötzlichen Besuch deines Chefs im Büro oder der Schwiegermutter zu Hause überrascht werden willst. Da heutzutage ja alle ein Smartphone mit sich herumtragen kann man einfach checken, ob bzw. auf welchem Accesspoint jemand eingeloggt ist um Frühzeitig über sein erscheinen informiert zu sein. Wie ich aus zuverlässiger Quelle gehört habe geht das zu Hause bequem mit einem Raspberry und einem Check, der den arp table überwacht. Im Unternehmen hat man häufig bessere Accesspoints, die per snmp auf angemeldete devices geprüft werden können. Hier kann man die Daten auch noch mit Geo Koordinaten versehen und anzeigen wo der Boss sich auf dem Betriebsgelände versteckt 😉

Check bitcoin/pool

In einem Unternehmen mit bitcoin affiner IT-Abteilung haben mehrere Admin’s zu Hause ein paar mining Server stehen. Hier hat es sich angeboten, die mining Rate mit check_btcpool zu überwachen und bei einem Abfall zu informieren.
Da hier sowieso schon gebastelt wurde haben die Herren gleich noch eine flotte Überwachung der bitcoin Kurse auf Basis der bitcoin.de API hinzugefügt. Bei Ausbruch aus einem bestimmten Korridor wird auch hier informiert.

Check bot

Überraschenderweise kann man sogar Pflanzen monitoren. Ein Botanik-Check überwacht EC, PH und Feuchtigkeit im Boden und setzt im Eventfall 5 Sekunden lang eine Pumpe in Gang die das Beet bewässert. Auf Grund der Langzeitdaten über EC und PH Wert kann man das Gießwasser mit Dünger und anderen Stoffen vorbehandeln und hat so eine perfekte Nährlösung. Allerdings ist die Ausrüstung hierfür wohl nicht ganz günstig. Das Ganze bietet sich also wohl nur für den professionellen Gemüsebauer an.

Check meat

In der Landwirtschaft geht es weiter. Der moderne Bauer hat schon einiges an IT bei sich herumstehen. Das Rind ist überwacht, der Biogastank blubbert. Doch wer überwacht die Überwacher dieser Prozesse? Natürlich Icinga. Neben der Überwachung der eigentlichen IT sowie der Melk und Futtersysteme bin ich hier auf die Idee gestoßen die Rinder mit Hilfe des maps moduls für icinga2 zu lokalisieren. Hierfür war es natürlich nützlich, dass alle Rinder ein RFID Halsband tragen und sich an den Trinkstellen selbst “anmelden”. Einer interessanter Einsatz des Netways Monitors war hier die Temperaturüberwachung der Ställe. Dabei ging es vor allem um ein Überschreiten der Temperatur im Sommer.

Wenn ihr noch ungewöhnliche Checks kennt oder eine irre Idee habt schreibt es gerne in die Kommentare.

Christoph Niemann

Autor: Christoph Niemann

Christoph hat bei uns im Bereich Managed Service begonnen und sich dort intensiv mit dem internen Monitoring auseinandergesetzt. Seit 2011 ist er nun im Consulting aktiv und unterstützt unsere Kunden vor Ort bei größeren Monitoring-Projekten und PERL-Developer-Hells.