Hallöchen zusammen,

einige haben mitbekommen, dass es am 13. (ha…) kurz vor halb neun Uhr Abends einen Ausfall des gesamten Servers gegeben hat. Das Ding ist um 20:28 Uhr neu gestartet und war etwa zwölf Minuten nicht erreichbar. Die Neustartskripte haben zwar gegriffen, trotzdem sind wir noch am überprüfen, ob alles wieder läuft. Das Monitoring ist ebenfalls ausgelöst worden. Soweit so gut! Entgegen der ersten Anzeichen war dieses Mal nicht KernelCare „schuld“. Anscheinend gab’s ein Problem mit der USV und einer Phase.

Weitere Infos gibt es hier (Twitter) (von Linevast) und hier (PasteBin-Stellungnahme des RZ-Betreibers „First Colo GmbH“).

Alles Services sollten wieder laufen. Wenn nicht, kurze Info an mich.

Vielen Dank!

Gerade durch Zufall und langer Sucherei gefunden…

Der Let’s Encrypt-Certbot legt im Auto-Modus eine default-ssl.conf an und lässt diese auf den ersten Ordner unter /var/www lauschen. In meinem Fall ist das web1.

Dumm nur, wenn man eine eigene SSL-Config für diesen Ordner angelegt hat und sich wundert, warum die .htaccess partout nicht geladen wird. Dann kann das mit den WordPress-Perma-Links auch nicht funktionieren und schon gar nicht mit SEO oder Übersetzungstools.

Dementsprechend: Entweder Lets Encrypt nicht im automatischen Modus laufen lassen, da es dann immer wieder die default-ssl.conf überschreibt oder jedes Mal von Hand ändern.

Herr, lass Hirn vom Himmel regnen.

Diverses:

Einige Probleme traten während der ersten Tests von Icinga auf. Zum Einen dadurch, dass auf dem Raspberry Pi auch gleichzeitig ein Asterisk-PBXer läuft. Da ich augenscheinlich bei der Installation des Webinterfaces nicht richtig aufgepasst habe, läuft der Web-Teil von Icinga mit dem Asterisk-User. Das CMDlet ans welches Icinga Web die Befehle sendet, wird beim Neustart aber mit icinga:icingaweb angelegt.

Ein weiteres Problem ist der check_nwc_health, der unter /var/tmp/ ein Verzeichnis anlegt. Ebenfalls mit falschen Rechten. Aus diesem Grund schrieb ich mir eine kleine, dreckige (und wahrscheinlich total unnötige) Bash-Datei mit diesem Inhalt:

#!/bin/bash
service icinga2 restart
chown asterisk -R /var/run/icinga2/cmd/
chmod 0777 -R /var/tmp/check_nwc_health/

Erst wird der Daemon neu gestartet, dann wird das Ownership für den Ordner cmd und dessen Inhalts an asterisk weiter gegeben und zuguter letzt bekommt jeder User Schreib/Lese-Rechte auf den Ordner der temporären Dateien von check_nwc_health.

Auf check_nwc_health gehe ich an anderer Stelle ein, ich benutze es momentan nur für meine Fritz!Box; folgen werden aber wahrscheinlich die Soft-Managed Netgear-Switche und Firewall/CISCO-Router.

Icinga 2  Web – Ping: No such host

Nachdem jeder Host, selbst der Lokale, den ich im Monitoring anlegte als „Down“ angezeigt wurde, kopierte ich den String des hostalive-Tests aus dem Frontend in eine Shell. Komischerweise funktionierte das nicht. Wenn ich den Befehl aber per Hand eingab, lief der Ping durch. Nach einigem rumprobiere stellte ich fest, dass anscheinend die Punkte zwischen den Oktetten Probleme machten. Gesagt, getan. Ihr müsst die Locale zurücksetzen.

Zuerst überprüft ihr mit echo $LANG eure gesetzte Locale. Dort steht wahrscheinlich etwas wie

en_GB.UTF-8

Den Eintrag löscht ihr mit

LANG=

Dann startet ihr den Daemon neu. Damit dürfte sich das Problem der Hosts, die als „Down“ angezeigt werden, gelöst haben.

Ich werde diesen Post sukzessiv fortführen und alle Problemchen, die ich im Verlauf des Lebens meines Monitorings habe, aktualisieren.

— Temeraire

Hier geht es zum Hauptteil der Reihe: Networkmonitoring auf einem RPi3

Werbinterface für Icinga 2

Nachdem Icinga 2 erfolgreich auf dem Pi installiert wurde, geht es mit der Einrichtung des aktuellen Webinterfaces von Icinga weiter.

Voraussetzungen

Um das Webinterface von Icinga 2 voll nutzen zu können, müssen vorher noch einige Pakete nachinstalliert werden.

Falls noch nicht geschehen, wird ein SQL-Server benötigt (ob PostgreSQL oder MySQL ist da einerlei. Ich verwende klassisch einen MySQLer).

Getan werden kann das mit:

# apt install mysql-server icinga2-ido-mysql apache2 libapache2-mod-php5

Das installiert sowohl den Datenbankserver, als auch Icinga Data Output-Modul für den Server, als auch einen Webserver (Apache, NGINX ist ebenso möglich) und weitere PHP5-Module auf dem Pi.

Sollte weder ein Datenbankserver noch ein Webserver auf dem Pi installiert worden sein, sollte man sich dringend und unbedingt alle hier getätigten Eingaben aufschreiben!

Danach wird das IDO-Interface aktiviert und eingerichtet. Aktivieren könnt ihr Icinga-Module mit dem feature enable-Tool, welches Icinga 2 direkt mitliefert.

# icinga2 feature enable ido-mysql

Ein weiteres Modul muss für die Befehlsweitergabe der Befehle aus dem Webinterface an das Icinga2-Backend noch aktiviert werden. Das heißt einfach command und wird mit

# icinga2 feature enable command 

aktiviert. Alle aktiven Features kann man sich mit

# icinga2 feature list

anzeigen lassen.

Nun dürfte der Installationdes Webinterfaces nichts mehr im Wege stehen.

Icinga 2 Web – Die Installation

Angestoßen wir die Installation durch ein

# apt install icingaweb2

Die Paketinstallation könnt ihr getrost beantworten und euch einen Kaffee zapfen.

Nun müssen wir die Rechte auf die, im Schritt vorher erstellte, Datenbank anpassen. Benutzername und Passwort könnt ihr, falls vergessen, unter /etc/icinga2/features-available/ido-mysql.conf nachlesen.

Loggt euch mit mysql -u root -p in den MySQL-Daemon ein.

Aktualisiert die Datenbankrechte mit

mysql> GRANT SELECT, INSERT, UPDATE, DELETE, DROP, CREATE VIEW, INDEX, EXECUTE ON icinga2.* TO 'icinga2'@'localhost' IDENTIFIED BY '';

Sollte, aus welchem Grund auch immer, keine Datenbank erstellt worden sein, können wir die Standard-Datenbank importieren. Dafür erstellen wir zuerst eine neue, leere Datenbank:

mysql> CREATE DATABASE icinga2;

und aktualisieren auch bei dieser die Datenbankrechte mit dem Befehl von oben. Ausloggen tun wir uns aus dem MySQL-Daemon mit quit;

Um nun das Schema in die gerade erstellte Datenbank zu importieren können wir in der normalen Bash einen Import in eine Datenbank auslösen. Das geht so:

mysql -u root -p icinga2 < /usr/share/icinga2-ido-mysql/schema/mysql.sql

Wir authentifizieren uns am Server und pipen die Datei mysql.sql in die Datenbank icinga2

Das wärs! Jedenfalls hier. Wir starten noch fix den SQLer und Icinga selbst mit den Befehlen service mysql restart && sudo service icinga2 restart neu und machen uns an die Konfiguration und Einrichtung des Webinterfaces.

Icinga 2 Web – Konfiguration

Die eigentliche Konfiguration erfolgt über euren Browser, sodass ein http://<IP/Hostname>/icingaweb2/setup schon reichen sollte.

Den Alias, also das icingaweb2 könnt ihr herausfinden und ändern. Festgehalten wird er in der icingaweb2.conf.

cat /etc/apache2/conf-available/icingaweb2.conf | grep Alias 

spuckt dann sowas wie das hier aus:

Alias /icingaweb2 "/usr/share/icingaweb2/public"

Um euch eingangs authentifizieren zu können, müsst ihr einen Token anlegen, den ihr im Webinterface eingeben müsst.

Den Token erstellt ihr mit diesem Befehl:

icingacli setup token create;

Icinga 2 Web – Webinterface

Die eigentliche Konfiguration erfolgt, wie gesagt, im Webinterface:

Das wärs. Viel Spaß mit dem Webinterface von Icinga 2. 🙂

Bei Fragen, gerne in die Kommentare.

— Temeraire

Quellen:

1. GitHub Installation Icingaweb2
2. Icinga2/Web auf dem RPi
3. Thomas Krenn – Icinga Web 2 mit Icinga 2 verwenden

Die eigentliche Installation von Icinga ist selbsterklärend nur wird der findige User die Installationspakete ohne Anpassungen auf seinem Pi schwerlich finden. Die befinden sich nämlich im Debmon^[1]http://debmon.org/packages#.

Stellt sicher, dass ihr als root auf eurem Pi eingeloggt seid. (zur Sicherheit: sudo -s) Dann erstellt ihr unter /etc/apt/sources.list.d/ die Datei debmon.list mit dem Inhalt

deb http://debmon.org/debmon debmon-wheezy main 

für Debian Wheezy und

deb http://debmon.org/debmon debmon-jessie main

für Debian Jessie. Speichert und ladet den Schlüssel der Paketquelle runter.

wget -O - http://debmon.org/debmon/repo.key 2>/dev/null | apt-key add -

fügt ihn direkt eurer Schlüsselverwaltung hinzu.

Jetzt müsst ihr die Pakete aktualisieren. Klassisch benutzt man dafür apt-get update, ein apt update macht das Selbe und sieht sogar noch schicker aus. (Bargraphen for the win!)

Nach dem Update der Pakete könnt ihr ganz einfach Icinga2 mit Abhängigkeiten via apt installieren:

apt install icinga2

Zudem sollten die Standardplugins von Icininga, bzw. Nagios nachinstalliert werden:

apt-get install nagios-plugins

— Temeraire

Was folgt: Die Icinga-Web-Einrichtung. Denn ohne Dashboard ist Icinga…kompliziert.

Eine Odyssee. Tierisch und nervig.

Am 27.08. waren die guten, alten Let’s Encrypt-Zertifikate für meine Subdomains fällig. Gesagt, getan, den alten CertBot (das originale…total performante Ding von LE) angeworfen und versucht die in Bälde auslaufenden Zertifikate zu aktualisieren. Konnte es denn so einfach sein?

Es konnte nicht.

Zwei der drei eingereichten Zertifikate waren nicht fällig und wurden übersprungen. Soweit so gut. Beim Dritten passierte einfach gar nichts. Nichts. Nada. Keine Fehlermeldung, kein gar nichts. Nur durch einen beherzten Griff auf Strg+C konnte das laufende Programm abgebrochen werden und zeigte mir ominöse Fehlermeldungen im dahinter liegenden Code, die bis auf ein augenscheinliches SSL-Problem nicht hilfreich waren. Großes Tennis. Selbst im Log, welches der Bot anlegte, war nichts. Ich löschte also den LE-Ordner im Verzeichnisbaum, weil ich davon ausging, dass das Ding die letzten Updates nicht verkraftet hatte.

Erst da fiel mir auf, dass es den „alten“ Bot schon gar nicht mehr gab, richtete CertBot ein und versuchte erneut mein Glück.

Ich wurde enttäuscht. Die gleiche Fehlermeldung, keine Antworten im Log. Nur die Tatsache, dass die Zertifikate fällig wurden und er versuchte mit dem ACME von LE Kontakt aufzunehmen.

Lange Rede, kurzer Sinn: IPv6. Nach einem Dist-Upgrade hat sich anscheinend meine Anpassung der sysctl.conf verflüchtigt.

Darauf gekommen bin ich recht umständlich. Ich benutzte curl:

root@host:/opt/certbot# sudo curl -v https://acme-v01.api.letsencrypt.org/directory
* Hostname was NOT found in DNS cache
* Trying 2a02:26f0:10:28d::3d5...
* Connected to acme-v01.api.letsencrypt.org (2a02:26f0:10:28d::3d5) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* Unknown SSL protocol error in connection to acme-v01.api.letsencrypt.org:443
* Closing connection 0
curl: (35) Unknown SSL protocol error in connection to acme-v01.api.letsencrypt.org:443

Da sieht man auch wieder den ominösen SSL-Error, der mich stutzig machte. Das weiter zu verfolgen erwies sich aber als Sackgasse. Das normale curl benutzt anscheinend ohne Flag die IPv6-Einstellung. Wie man an dem * Trying 2a02:26f0:10:28d::3d5... sehen kann. Soweit so gut. Irgendwann überkam mich also die Einsicht mal zu testen, ob es mit einem IPv4-Flag funktioniert.

sudo curl -v -4 https://acme-v01.api.letsencrypt.org/directory

* Hostname was NOT found in DNS cache
*   Trying 23.0.33.82...
* Connected to acme-v01.api.letsencrypt.org (23.0.33.82) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using ECDHE-RSA-AES256-GCM-SHA384
* Server certificate:
*        subject: CN=*.api.letsencrypt.org; O=INTERNET SECURITY RESEARCH GROUP;                                    L=Mountain View; ST=California; C=US
*        start date: 2015-06-26 17:05:45 GMT
*        expire date: 2018-06-25 17:05:45 GMT
*        subjectAltName: acme-v01.api.letsencrypt.org matched
*        issuer: C=US; O=IdenTrust; OU=TrustID Server; CN=TrustID Server CA A52
*        SSL certificate verify ok.
> GET /directory HTTP/1.1
> User-Agent: curl/7.35.0
> Host: acme-v01.api.letsencrypt.org
> Accept: */*
>
< HTTP/1.1 200 OK
* Server nginx is not blacklisted
< Server: nginx
< Content-Type: application/json
< Content-Length: 280
< Boulder-Request-Id: DtR_dWdAimq7NP4Kppw6beNPRu6vfNbplKb-o1_M2bs
< Replay-Nonce: HT8EzQuvnEcqfPJYTuDQJnDkt4hpewKj0ziD5kYcZLc
< X-Frame-Options: DENY
< Strict-Transport-Security: max-age=604800
< Expires: Tue, 19 Jul 2016 10:33:23 GMT
< Cache-Control: max-age=0, no-cache, no-store
< Pragma: no-cache
< Date: Tue, 19 Jul 2016 10:33:23 GMT
< Connection: keep-alive
<
{
  "new-authz": "https://acme-v01.api.letsencrypt.org/acme/new-authz",
  "new-cert": "https://acme-v01.api.letsencrypt.org/acme/new-cert",
  "new-reg": "https://acme-v01.api.letsencrypt.org/acme/new-reg",
  "revoke-cert": "https://acme-v01.api.letsencrypt.org/acme/revoke-cert"
* Connection #0 to host acme-v01.api.letsencrypt.org left intact

Und ja; tuts. Mit einem explizit aufgerufenen curl -4 bekommt man einen 200er zurück. Perfekt. Was nun? Anscheinend funktioniert das IPv6 in LE immer noch nicht (zuverlässig)

Also mussten meine Anpassungen wieder in die /etc/sysctl.conf :

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1

Testen, ob nun wirklich IPv6 deaktiviert ist, kann man mit einem cat /proc/sys/net/ipv6/conf/all/disable_ipv6 welches dann hoffentlich eine 1 ausgibt. Danach lief auf CertBot wieder ohne Probleme durch.

Anscheinend soll mittlerweile das Problem mit dem IPv6-Stack gelöst worden sein.

Nachlesen kann man den Fall auf GitHub hier^[1]CertBot Issue #2615

Den Blogeintrag im DevBlog zur vollen Unterstützung von IPv6 findet ihr hier^[2]LE Full IPv6 Support

Unglaublich dekadent. Bei einem abendlichen Ausflug vor meinem wohlverdienten Urlaub in Bayern überkam mich der Hunger auf Ungesundes. Die Wahl fiel dieses eine Mal nicht auf meine Lieblingspizzeria, die entfernt an Käse erinnert, sondern auf das Haus der Burgerkönigs. Moment. Burger King? Auf der Seite der liefernden Helden? Irgendwas stimmt doch da nicht. Gut, der Burger King ist am anderen Ende der Stadt, gute 20 ÖPNV-Minuten entfernt, aber das die liefern war selbst mir neu. Das musste man einfach testen. Der Traum eines jeden prä-pubertären Jünglings gewar wahr zu werden, ein einfacher Anruf des Nachts von einer LAN-Party aus konnte den Hunger so vieler stillen. Gabs das doch nur schon zu meiner prä-pubertären LAN-Party-Zeit. Ziemlich gut.

Kaum das Essen bestellt, bekam der Hungrige einen Link mit der Karte seiner Stadt in der er den Boten live verfolgen konnte. Auch wenn die Route, die die junge Dame nahm, sehr eigenwillig schien, kam sie tatsächlich sogar VOR der angegebenen Zeit an und übergab mir lächelnd meine ungesunden Fleischbrötchen. Die Frage, wie die Coke transportiert wurde erübrigte sich, als ich die PET-Flasche sah. Schlau… Genüsslich machte ich mich also an mein Mahl und schüttelte immer noch erstaunt über diesen „Fortschritt“ meinen Kopf.

Ende vom Lied:  Jap, Burger King liefert. Und das wohl schon seit Anfang 2016^[1]Lieferheld Burgerking liefert! 14.01.2016. Was man nicht alles verpasst.

— Temeraire

PS: Natürlich könnt ihr auch gucken, ob sie schon zu euch liefern^[2]Burger King Lieferservice.

Gestern Nachmittag war meine freundliche Nachbarin so nett und hat einen haufen (!) Kartons, Päckchen und Krimskramslieferungen für mich angenommen. Ich hatte die Bestellungen so aufgegeben, dass möglichst alles zusammen an einem Tag kommt. Entgegen der „Ich brauch alles jetzt sofort“-Mentalität ganz entspannt.

Im Folgenden die BoM ohne das Plexiglas und Holzlatten für das eigentliche Gewächshaus. Außerdem bin ich mir noch nicht über die Möglichkeit zum Entlüften schlüssig. Entweder ich nehme einen Servo und drücke damit eine Scheibe hoch, oder brauche eine Alternative.

Bestellt habe ich, wie man auch der BoM entnehmen kann, eine 8-Port-Relais-Karte (für die vier 12V-Ventile, einen 12V-Lüfter, die 12V-Wasserpumpe und zwei 12V-Halogenstrahler), die Fotowiderstände, DeDupont-Kabel (Davon kann man nie genug haben!), Schläuche für die Bewässerungsanlage, die Pumpe, zwei DHT22-Sensoren und die eigentliche Wanne in der das Gemüse angepflanzt wird. Es fehlt momentan nur noch das Holz, Plexiglasscheiben und wasserfestes Silikon, da ich die Wanne in vier etwa gleich große Teile unterteilen möchte. Außerdem habe ich noch keine Bodenfeuchtesensoren. Diese möchte ich eventuell selbst bauen. Außer der Ali hat ein Angebot für mich, welches ich nicht ausschlagen kann. Mal schauen. 

Hier noch mal die einzelnen Teile genauer:

Die Tage werde ich mich an den grundlegenden Schaltplan der Elektronik kümmern. Ein 12V/5V-Netzteil muss ebenfalls noch angeschafft werden, da ich bei solch einem Projekt nur bedingt auf Steckernetzteile und Kabelgefiddel stehe. Ebenso wird ein Sicherungsautomat (eventuell auch noch ein FI-Schutzschalter, weil Wasser+Strom = Rot-Blauer-Partybus) vor das Netzteil geschaltet. Parallel werde ich anfangen das Frontend vorzubereiten, ich habe da an Bootstrap gedacht. Eventuell aber auch einfaches, hässliches Plain-HTML mit JQuery-Buttons. 😀

— Temeraire

Hier geht es zum ersten Teil der GreenhousePi-Reihe und hier zum Projektarchiv.

Etwas, was ich noch machen muss, damit Google aufhört zu nerven und generell Sender Policies und weitere Schutzmaßnahmen für den Server und die Benutzer zu schaffen. Gerade diesen Beitrag im Netz gefunden, werde ich ihn schnellstmöglich durcharbeiten und übersetzen. Die Pointer und DNS-Anpassungen habe ich in weiser Voraussicht bereits getätigt.

Schritt 1: Sender Policy Framework installieren und einrichten

Installiert wird das Postfix-Derivat von SPF hiermit:

<code>sudo apt-get install postfix-policyd-spf-python</code> Nachdem das Postfix-Plugin herunter geladen und mit den aufgelösten Abhängigkeiten installiert wurde, können wir die Postfix master.cf, die unter /etc/postfix/master.cf liegt, anpassen und folgendes hinzufügen:

policy-spf  unix  -       n       n       -       -       spawn
     user=nobody argv=/usr/bin/policyd-spf

Dafür benutzt einfach den Texteditor eures Vertrauens. Ich werde nicht auf die unterschiedlichen Varianten eingehen 😉

Speichert die master.cf und öffnet die main.cf, die im selben Ordner liegt. Wir müssen den Konfigurationspunkt check_policy_service unix:private/policy-spf noch dem smtpd_recipient_restrictions-Block in ebendieser Datei hinzufügen.

Meine smtpd_recipient_restrictions sieht so aus:

smtpd_recipient_restrictions =
    permit_sasl_authenticated,
    reject_invalid_hostname,
    reject_unknown_recipient_domain,
    reject_unauth_destination,
    reject_rbl_client sbl.spamhaus.org,
    check_policy_service unix:private/policy-spf,
    permit

Die SPF-Überprüfung sollte immer nach der allgemeinen Abweisung von unauthentifizierten Benutzern stattfinden, da es sonst zu false positives führen kann, die aus dem Mailserver ein open relay machen.

Zu guter Letzt muss für SPF noch ein TXT-Pointer auf eure Domain in den DNS-Einstellungen eures Providers vorgenommen werden.

"v=spf1 a mx ip4:<IPv4-Adresse> ip6:<IPv6-Adresse> ~all"

Die Angabe der IP-Adressen ist nicht notwendig, sollte aber vorgenommen werden, damit Google eure Mails nicht mit einem Softfail versieht.

Sollte es zu Timeouts während der Aushandlung kommen, könnt ihr noch ein

policy-spf_time_limit = 3600s

in die main.cf schreiben.

Schritt 2: Installation und Einrichtung der DomainKeys Identified Mail Signatures

Der zweite Schritt darin, nicht (mehr) als Spammer von großen E-Mail-Anbietern gekennzeichnet zu werden, sind die DKIM Signaturen. Diese verbinden euren Mail-Server mit eurem Hostname. Somit kann nach vollzogen werden, ob die Mail auch wirklich von diesem Server kommt.

Starten kann man die Installation mit

apt-get install opendkim opendkim-tools

Damit DKIM korrekt angeboten wird, müssen wir ein Schlüsselpaar erzeugen (DKIM verwendet zur Autorisation assymetrische Verschlüsselungen). Den öffentlichen Schlüssel legen wir in den DNS-Eintrag des Servers. Nach der Installation editieren wir die /etc/opendkim.conf und stellen sicher, dass sie folgende Werte enthält:

KeyTable            /etc/opendkim/KeyTable
SigningTable       /etc/opendkim/SigningTable
ExternalIgnoreList /etc/opendkim/TrustedHosts
InternalHosts      /etc/opendkim/TrustedHosts
LogWhy yes

Erstellt das Verzeichnis /etc/opendkim wenn es noch nicht existiert. In diesem Verzeichnes erstellt die Datei TrustedHosts und tragt alle Domains oder die IP-Adressen ein. Das Ganze sieht dann in etwa so aus:

127.0.0.1
 localhost
 example.com
 123.123.123.123
 231.231.231.23

Danach editiert ihr folgende Zeile

SOCKET="inet:12345@localhost" # listen on loopback on port 12345

in der Datei /etc/default/opendkim.

Um openDKIM nun mit eurem Postfix-Server sprechen zu lassen, fügen wir folgenden Block in die /etc/postfix/main.cf an:

# DKIM
milter_default_action = accept
milter_protocol = 6
smtpd_milters = inet:localhost:12345
non_smtpd_milters = inet:localhost:12345

Nun müssen wir ein Schlüsselpaar für den Mail-Server erstellen. Dazu verwenden wir den mitgelieferten Keygenerator von openDKIM. Diese Befehle sind ebenso selbsterklärend.

root@excontinuum:~# mkdir -p /etc/opendkim/keys/excontinuum.de
root@excontinuum:~# cd /etc/opendkim/keys/excontinuum.de/
root@excontinuum:/etc/opendkim/keys/excontinuum.de# opendkim-genkey -s default -d excontinuum.de
root@excontinuum:/etc/opendkim/keys/excontinuum.de# chown opendkim:opendkim default.private 

Danach müssen die erstellten Keys der Datei /etc/opendkim/KeyTable hinzugefügt werden. Im Folgenden für die Domain dieses Servers:

default._domainkey.excontinuum.de excontinuum.de:default:/etc/opendkim/keys/excontinuum.de/default.private

Und der folgende Teil in die /etc/opendkim/SigningTable:

excontinuum.de default._domainkey.excontinuum.de

Eure erstellten Keys könnt ihr mit

cat /etc/opendkim/keys/mydomain.com/default.txt

einsehen. Den String, den ihr durch den Befehl zurück kommt, müsst ihr als TXT Record eurer Domain hinzufügen. Mit dem langen Hash, etc.
Mit Dig könnt ihr überprüfen, ob der Record korrekt gesetzt wurde. Die Suche von Dig müsste einen „Answer“-Bereich enthalten, der den selben Inhalt hat, wie die default.txt.

Schritt 3: DKIM-Konfiguration testen

Zum einen kann man an check-auth@verifier.port25.com eine leere E-Mail schreiben, in der man einen SPF/DKIM-Report zurückbekommen soll. Das hat bei mir nicht funktioniert. Zum Anderen kann man mail-tester.com verwenden. Das funktioniert ziemlich gut!

DMARC konfigurieren:

Wenn SPF und DKIM konfiguriert sind, sollte man den einfachen und von vielen E-Mail-Providern bevorzugten DMARC-Eintrag dem DNS-Eintrag hinzufügen.

Erstellt dafür einfach einen neuen TXT-Eintrag mit

_dmarc IN TXT "v=DMARC1; p=none"

als Inhalt.

Reverse DNS:

Zu guter Letzt überprüfen wir, ob es bereits einen rDNS-Eintrag für die IP-Adresse gibt, auf der euer Mail-Server hört. (dig -x +short <IP-Adresse>)

Sollte das nicht der Fall sein, fügt einen PTR-Record eurer DNS-Konfiguration mit der gedrehten IP hinzu.

Schritt 4: SpamAssassin

Da der SpammAssassin bereits installiert und konfiguriert war, entfällt dieser Teil.

Das wars. Wenn alles funktioniert hat, müsstet ihr nun per SPF und DKIM authentifizierte E-Mails versenden können!

— Temeraire

Schon seit einiger Zeit wächst in mir der Wunsch nach ein wenig Grünzeug in meiner Wohnung. Als Informatiker kennt man das ja; Kabel, Computer, Kram und einen grünen Daumen habe ich ebenso wenig. Eher Grau-braun. 

Welche Alternativen gibt es nun zu einem Gärtner für die eigenen vier Wände? chirp! Nettes, kleines Gerät. Aber für meine Verhältnisse zu teuer und was bringt mir ein Alarm, wenn ich nicht daheim bin? Genervte Nachbarn und eine lange Rechnung der Feuerwehr. Wahrscheinlich… Andere Versionen benutzen einen Arduino, ein paar Servomotoren und eine Pumpe. Sportlich und für einen Balkon bestimmt das Richtige. Innerhalb der eigenen vier Wände fällt das wohl ins Wasser, wenn man nicht nach jedem Bewässerungsvorgang den Boden wischen will. Die Instructable zu diesem Projekt findet ihr hier.

Das geht schon in die richtige Richtung, Sensoren die die Bodenfeuchte messen und eine automatische Bewässerung, auch wenn man gerade nicht im Hause ist. 

Dann habe ich genau das gefunden, was sich auch innerhalb einer Wohnung sehr gut umsetzen lässt. Das „Automated Greenhouse“ von ViDes. Abfragen von Bodenfeuchtigkeit? Check. Temperaturüberprüfung innerhalb und außerhalb des Gewächshauses? Auch vorhanden. Summa Samarium genau das, was ich in mein Wohnzimmer stellen kann und ein gutes Projekt um mein Wissen und den Umgang mit dem RPi und verschiedenen Sensoren zu vertiefen.

Geplant habe ich eine etwas andere Konfiguration, aber grundlegend nach dem Prinzip des Automated Greenhouse. Anbauen möchte ich Gewürze, Pfefferminze, Chilli und Ähnliches. Da aber alle diese Pflanzenarten etwas andere Anforderungen haben, werde ich vier gleich große Areale aufteilen, die eigene Sensoren bekommen. Auch können diese Areale einzeln, abhängig von den Sensorwerten, bewässert werden. Dabei will ich noch zwei 12 Volt Halogenstrahler, die (wie die Ventile) über eine Relais-Karte gesteuert werden, anbringen um in Kaltperioden die Pflanzen mit Wärme und Licht zu versorgen.

Grundlegend wird die Steuerung aus zwei großen Hardware und zwei großen Software-Modulen bestehen. Die Hauptkomponente, auf der der Großteil der Software laufen wird, ist ein Raspberry Pi 2 B. Mit USB verbunden wird ein Arduino Mini, der die Sensorwerte auswertet und bereinigt an den RPi sendet. Da ich mehr analoge Eingänge benötige, als mir der Arduino bieten kann, verwende ich einen (oder auch mehrere) 4051er die analoge Eingänge an den Arduino multiplexen. Bei fünf analogen Eingängen am Arduino könnte ich mir auch vorstellen, das komplette System modular aufzubauen und direkt an alle Analogpins die Plexer zu hängen. 

Die Bodenfeuchte wird pro Areal gemessen, die Temperatur, sowie die Luftfeuchte nur an zwei Stellen. Innerhalb und Außerhalb des Gewächshauses. Die Lichtmenge wird nur im Gewächshaus gemessen.

Softwareseitig wird die eine Komponente aus einem Python-Daemon bestehen, der die Relais und den Servo-Motor ansteuert und Sensorwerte über die USB-Konsole des Arduino bezieht und über ein recht simplen Programmablaufplan die Aktoren des Gewächshaussystems steuert. Ebenso soll das Pythonprogramm die empfangenen Sensordaten tageweise in eine csv-Datei hängen, um die Vorgänge nachvollziehen zu können. Außerdem sehen Diagramme klasse aus! Gesammelt werden sollen die Daten durch den Daemon alle zwei Sekunden (Häufiger bringt nichts, der verwendete Temperatur- und Luftfeuchtemesser DHT22 sampled nur alle 1,7 Sekunden). Wie oft und wie viele Werte der Daemon in die csv-Datei wegschreibt, weiß ich noch nicht. Bei neun Werten plus Steuerzeichen (Bezeichner, Trenner und dreistelliger Wert für neun Sensoren sind 45 Zeichen, plus 45 Steuerzeichen sind 90 Zeichen á 8 Bit (erweiterter ASCII-Zeichensatz) sind 720 Bit oder 90 Byte) alle 2 Sekunden sind das pro Tag etwa 3,8 Megabyte. Vernachlässigbar, läppert sich aber schon. Außerdem ist die Auflösung bei 2 Sekunden wohl etwas zu hoch.

Dazu kommen noch einige Funktionen für den Daemon die nach und nach hinzugefügt werden sollen (Mailversand mit Statuswerten/Graphen, Neustart des Pi bei Sensorfehler/Plausibilitätsfehler, etc). Fürs Erste reicht aber eine funktionierende Variante des Automaten.

Die zweite große Softwarekomponente ist eigentlich das Frontend des Daemons, bequem erreichbar über einen Apachen mit PHP. Darstellen soll er den Status der Aktoren, die Sensordaten und die letzten X Minuten der Aufzeichnungen. Über das Frontend soll man den automatischen Modus konfigurieren und deaktivieren können. (Einige Sicherheitsfunktionen wie, zum Beispiel „Wenn der Innenraum über X Grad Celsius heiß wird, deaktivieren sich die Halogenstrahler“, lassen sich nicht deaktivieren.) Die Kommunikation von Frontend mit dem Backend wird (äußerst schmutzig) über Dateiex und -importe laufen. Der Daemon checkt alle zwei Sekunden nach Updates in der Austauschdatei und überschreibt gegebenenfalls seine eigenen Werte. Momentan weiß ich noch nicht so recht, wie ich die Sensorwerte in den Apachen hereingeschustert bekomme, wenn die USB-Konsole durch den Daemon belegt wird. Vielleicht mit einem exec() und einer Python-Methode. Mal schauen.

Um klein anzufangen, gliedere ich das Projekt in mehrere Stufen.

• Zuerst, das wird wohl das Einfachste sein, wird der GPIO-Python-Teil geschrieben, der die Relais für eine variable Anzahl von Sekunden oder immer an oder aus stellt
• Danach kommt der Arduino, der die analogen Sensordaten der Shiftregister bereit hält und über die Konsole in den Äther bläst
• Wieder auf dem Pi schreibe ich die Klasse, die den Arduino-String in Variablen (oder gleich ein Array) zerbricht, in die csv-Datei exportiert und die Daten für den Daemon bereit stellt.
• WENN (großes Wenn) das dann irgendwann alles so funktioniert (Auswerten der Daten, setzen der Relais, Pumpe, Ventile, etc), DANN mache ich mich an den Automaten, der das Gewächshaus steuert
• Zukunftsvisionen, et al.

Die gröbsten Teile sind bestellt, wenn alles da ist, poste ich die BoM.

To be continued…wahrscheinlich als Portfolio eingegliedert in die Projekte 🙂