Für mein aktuelles Projekt in der Firma habe ich einige Raspberry’s bestellt, welche in Verbindung mit einem Monitor eine Webseite anzeigen sollen die sich regelmässig aktualisiert.

IMG_20140514_175442

Da schlägt das Techniker-Herz höher, wenn man die Lieferung dann in Händen hält:  🙂

IMG_20140515_092130

Zur Verwaltung dieser „Menge“ an Raspi’s habe ich einen Puppet-Server installiert, der es mir später ersparen soll bei Konfigurationsänderungen jeden einzelnen manuell zu warten. Die Installations-Anleitung auf der Homepage von PuppetLabs ist sehr ausführlich und kann ich jedem nur empfehlen.

Bei der Installation des Puppet-Agenten auf dem Raspberry gab es eine zusätzliche Hürde wegen einer fehlenden Abhängigkeit. Das Paket Facter wird in einer Version > 1.7.0 verlangt. Im eingebundenen Repository gab es aber nur die Version 1.6.6. Nach einer etwas intensiveren Internet-Recherche konnte ich das Paket von den Ubuntu-Quellen beziehen und einrichten.

Zusätzlich werden auch die folgenden Pakete benötigt:

1
host bind9-host lsb-release ruby-rgen
host bind9-host lsb-release ruby-rgen

Die Kommunikation zwischen Puppet-Agent und Server erfolgt verschlüsselt mit Private und Public-Key’s. Dazu müssen die Public-Key’s untereinander ausgetasucht werden. Beim ersten Start auf dem Client erzeugt der Agent das Zertifikat und reicht es bei der Puppet-CA (beim master) ein:

1
puppet agent --test
puppet agent --test

Das soeben generierte Zertifikat wird auf den Server übertragen und muss dort dann signiert werden:

1
puppet cert sign CLIENTHOSTNAME.FQDN
puppet cert sign CLIENTHOSTNAME.FQDN

Wenn man den Agent auf dem Client nun nochmal startet (puppet agent –test) übernimmt er bereits seine erste Konfiguration von Puppet.

Grundsätzlich schreibt man die zu setzenden Einstellungen in eine sogenannte Manifest-Datei /etc/puppet/manifest/site.pp welche dann für alle Clients gelten. Die Konfigurationen für Clients schreibt man am besten in jeweils eine eigene Datei (zB. im Unterverzeichnis nodes), welche dann mit einer Import-Anweisung in die Manifestdatei site.pp eingebunden werden:

1
2
3
node 'CLIENTHOSTNAME.FQDN' {
        import 'nodes/clienthostname.pp'
}
node 'CLIENTHOSTNAME.FQDN' {
        import 'nodes/clienthostname.pp'
}

Dieses Beispiel erstellt auf dem Client einen Cron-job, welcher den Puppet-Agenten regelmässig startet, um neue Einstellungen vom Master abzufragen und zu übernehmen:

1
2
3
4
5
6
7
cron { 'puppet-agent':
  ensure  => 'present',
  command => '/usr/bin/puppet agent --onetime --no-daemonize --splay',
  minute  => ['30'],
  target  => 'root',
  user    => 'root',
}
cron { 'puppet-agent':
  ensure  => 'present',
  command => '/usr/bin/puppet agent --onetime --no-daemonize --splay',
  minute  => ['30'],
  target  => 'root',
  user    => 'root',
}

Die detailierte Konfiguration von Puppet bzw. der Nodes gibts dann in einem späteren Artikel. Ein guter Einstieg ist die Puppet-Dokumentation (Node Definition) und die Ressource-Typen Referenz.

 

 

Da ich mit meinem bestehenden Raspberry Pi-Server schon länger an die Performance-Grenzen gestoßen bin (mit Seafile, Nagios, openVPN, etc..), habe ich mich auf die Suche nach einer leistungsstärkeren Alternative gemacht und das Cubieboard entdeckt, welches gestern geliefert wurde. 🙂

Das Cubieboard ist ähnlich wie der Raspberry Pi ein Einplatinencomputer, welcher etwa 30 Euro mehr kostet als der Raspberry Pi (Modell B). Dafür erhält man aber eine deutlich bessere Ausstattung. Ich habe mir die zweite Version (Cubieboard2) besorgt, welche im Vergleich zur ersten Version eine Dualcore-CPU hat. Zusammen mit Netzteil und Gehäuse hat mich mein Cubie etwa 100 Euro gekostet.

Hier die wichtigsten Spezifikationen:

AllWinner A20 mit zwei ARM-Cortex-A7-Kerne und zwei Mali-400 GPUs
1GB DDR3 RAM
4 GB NAND-Flash, 1x MicroSD-Steckplatz, 1x SATA-Anschluss
HDMI-1080p-Ausgabe
10/100-Ethernet-Anschluss
2x USB Host, 1x USB On-the-go, 1x CIR
96 Anschlußpins

Hier ein paar Bilder vom „unboxing“ und zusammenbauen des Gehäuses:

cubieboard2-1 (Medium)  cubieboard2-3 (Medium)  cubieboard2-2 (Medium)

Sehr schön finde ich das „eingebaute“ Lichtspiel der verschiedenfarbigen LED’s dank transparentem Gehäuse.

cubieboard2-5 (Medium)  cubieboard2-4 (Medium)

Beim ersten Einschalten startet die vorinstallierte Android-Portierung (4.2.2) vom NAND Speicher. Diese ist nur mit einer Maus vernünftig bedienbar und ich brauche für meine beabsichtigten Zwecke sowieso ein „sauberes“ Linux. Daher wird diese demnächst durch ein Debian-Derivat ersetzt werden. 😉

cubieboard2-android1 (Medium)  cubieboard2-android2 (Medium)

Auf den Seiten des Herstellers gibt es neben weiteren angepassten Android-Versionen und nützlichen Debug-Tools oder ImageWriter auch Links zu anderen Linux-Distributionen.

 

 

Mit meiner SMS-Gateway-Lösung bin ich eigentlich sehr zufrieden, sie funktioniert super zuverlässig. Jedoch ist sehr schnell der Wunsch gewachsen, auf die gesendeten SMS-Nachrichten reagieren/antworten zu können. Dafür reicht aber das Konsolen-Tool alleine nicht aus.

Speziell für den Automatisierungs-Zweck gibt es auch einen SMS-Daemon „gammu-smsd„. Dieser funktioniert ähnlich einfach.

Nach der Installation über das Paketmanagement des Raspberry PI’s sollte man die Konfigurations-Datei anpassen. Diese findet sich unter /etc/gammu-smsdrc. Wichtig ist eigentlich nur, dass die port-Directive richtig gesetzt ist. In meinem Fall sieht die Zeile so aus:

1
port = /dev/ttyUSB0
port = /dev/ttyUSB0

Ich bevorzuge eigene Log-Files für jeden Dienst, daher habe ich bei logfile noch den Pfad zum Logfile angegeben und den Wert debuglevel auf 1 gesetzt. Es können natürlich noch viele weitere Parameter definiert werden. Mehr Informationen dazu liefert die offizielle Dokumentation.

Ebenso kann bei service definiert werden, in welchem Backend die SMS-Nachrichten gespeichert werden. Auch hier stehen die gängigsten Formate zur Verfügung (Files, MySQL, PostgreSQL, etc..). Standardmässig werden die Nachrichten in Files gespeichert, was für mein kleines Gateway ausreichend ist.

Das Prinzip ist einfach: Es existieren vier Verzeichnisse. Ausgehende SMS-Nachrichten werden in dem Pfad von outboxpath abgelegt. Der Daemon prüft das Verzeichnis und verarbeitet eventuell vorhandene Dateien. War der Versand erfolgreich, wird diese in den sentssmspath verschoben, ansonsten in den errorsmspath. SMS-Nachrichten, welche empfangen werden, legt der Daemon im Verzeichnis bei inboxpath ab. Diese können dann mit einem anderen Programm verarbeitet werden.

Mit dem Befehl

1
gammu-smsd-inject TEXT MEINE-NUMMER -len 160 -text "Das ist \n ein Test"
gammu-smsd-inject TEXT MEINE-NUMMER -len 160 -text "Das ist \n ein Test"

können nun schon die ersten Nachrichten gesendet werden. Dabei werden die Nachrichten auch im outbox-Pfad abgelegt und erhalten speziell-formatierte Dateinamen. Man kann auch mit

1
echo "TEST" >> /var/spool/gammu/outbox/OUT20130912_140600_00_MEINE-NUMMER_sms0.txt
echo "TEST" >> /var/spool/gammu/outbox/OUT20130912_140600_00_MEINE-NUMMER_sms0.txt

selbst direkt SMS-Nachrichten zum Versand ablegen. Mehr Informationen über das Dateinamen-Format liefert die Doku auf der gammu-Projekt-Seite. Ich habe ein kleines Perl-Script geschrieben, welches die zu sendende SMS zusätzlich in ein schöneres Format bringt. Der Link zum Script findet ihr am Ende des Beitrags.

Das Nagios-Komando für die Service-Benachrichtigungen sieht nun so aus:

1
command_line    /usr/local/bin/sendsms.pl --type $NOTIFICATIONTYPE$ --servicedesc $SERVICEDESC$ --hostname $HOSTNAME$ --state $SERVICESTATE$ --datetime $SHORTDATETIME$ --info "$SERVICEOUTPUT$" --contact $CONTACTPAGER$
command_line    /usr/local/bin/sendsms.pl --type $NOTIFICATIONTYPE$ --servicedesc $SERVICEDESC$ --hostname $HOSTNAME$ --state $SERVICESTATE$ --datetime $SHORTDATETIME$ --info "$SERVICEOUTPUT$" --contact $CONTACTPAGER$

Für die Host-Benachrichtigungen entsprechend ohne die Option Service-Description und angepassten Variablen:

1
command_line    /usr/local/bin/sendsms.pl --type $NOTIFICATIONTYPE$ --hostname $HOSTNAME$ --state $HOSTSTATE$ --datetime $SHORTDATETIME$ --info "$HOSTOUTPUT$" --contact $CONTACTPAGER$
command_line    /usr/local/bin/sendsms.pl --type $NOTIFICATIONTYPE$ --hostname $HOSTNAME$ --state $HOSTSTATE$ --datetime $SHORTDATETIME$ --info "$HOSTOUTPUT$" --contact $CONTACTPAGER$

Der Nagios-Benutzer muss noch in die gammu-Gruppe, damit er in die Verzeichnisse schreiben darf, wenn er das Script ausführt:

1
usermod -aG gammu nagios
usermod -aG gammu nagios

nagios-sms

Und nun der Weg zurück:

Im Script „sendsms.pl“ wird beim Versand eine SMS-ID erzeugt und mit dem betroffenen Host und Service in ein File geschrieben. Mit dieser ID kann später der betroffene Host oder Service wieder identifiziert werden. Der Empfänger der SMS-Nachricht muss nur die SMS-ID in die Antwort-SMS schreiben. Den Rest übernimmt das Script.

Im einfachsten Fall wird einfach nur das Problem in Nagios bestätigt (möglich wären natürlich noch viele weitere Aktionen). Das übernimmt wieder ein kleines Perl-Script (receivesms.pl), welches regelmässig via cronjob das Inbox-Verzeichnis von gammu auf neue Nachrichten überprüft und die darin enthaltenen Dateien einliest.  Dann wird in der von sendsms.pl geschriebenen Events-Datei nach der per SMS gesendeten ID gesucht und „acknowledged“ den richtigen Service / Host in Nagios über das Command-File.

nagios-ack

Beide Scripts (sendsms.pl und receivesms.pl) sind auf der Projects Seite (unten) zu finden.

 

Auf meinem Raspberry PI läuft Nagios als Monitoring für die Dienste auf meinen vServer. Damit werden Erreichbarkeit des Servers, der Mail-Dienste, etc.. überwacht. Aber auch ob das Backup täglich auf meine NAS zuhause übertragen wurde.

Üblicherweise lässt man sich per Email über die Nichtverfügbarkeit eines Dienstes benachrichtigen. Doch wie erhält man die Information dass der Mail-Server „down“ ist, wenn genau dieser Mail-Server nicht erreichbar ist? Auf einen externen Email-Dienstleister wollte ich bewusst nicht zurückgreifen. Also musste eine andere Lösung her, die ich hier beschreibe:

Glücklicherweise muss man nicht mehr viel Geld investieren, um sich ein einfaches SMS-Gateway zu basteln:

  • einen Raspberry PI (schon vorhanden, bzw. ~70 Euro mit Netzteil, Gehäuse + Platine)
  • ein Huawei USB UMTS-Modem (gibt es auf Ebay auch schon gebraucht ab ~10 Euro)
  • eine PrePaid SIM-Karte (je nach Tarif kostet eine SMS 6-20 Cent, man kommt also mit 5 Euro Guthaben schon recht weit)

Auf der Software-Seite kommen OpenSource-Tools zum Einsatz. Ich verwende gammu aus dem Distributions-Repository, welches auf Anhieb mit meinem USB-Modem (Huawei E169) funktioniert hat. Nach der Installation kann gammu mit dem Befehl gammu-config an die eigenen Bedürfnisse konfiguriert werden. In der Regel muss hier nicht viel angepasst werden, außer der Port-Information des UMTS Modems. Dieser lässt sich zuvor mit dem Befehl dmesg | grep ttyUSB herausfinden.

gammu-config

Mit dem Befehl gammu-identify lässt sich dann prüfen, ob gammu mit dem UMTS-Modem auch zusammen arbeitet und liefert (hoffentlich) ein paar Informationen darüber. Wenn bis hierher alles ohne Probleme geklappt hat, kann bereits das erste SMS gesendet werden:

1
echo "Hello SMS" | gammu sendsms TEXT 01234564879
echo "Hello SMS" | gammu sendsms TEXT 01234564879

Kurz darauf sollte das SMS bei der angegebenen Nummer ankommen.

 

This site uses cookies. Find out more about this site’s impress.