Ich erstelle beispielsweise jeden Tag in der Früh einen Report über die Geschwindigkeiten auf meinen Funkfeuer-Standorten. Den Report erhalte ich per Email und kann daran die Performance der weit entfernten Standorte erkennen.
Seit kurzem ist speedtest-cli allerdings durch speedtest.py abgelöst worden. Das Tool speedtest.py wurde vom gleichen Developer entwickelt. Es erscheint beim Aufruf von speedtest-cli folgende Meldung:
The file speedtest_cli.py has been deprecated in favor of speedtest.py
Damit man Ubiquiti EdgeRouter und Ubiquiti EdgePoint-Geräte im Netz von Funkfeuer Wien als Router betreiben kann, ist es notwendig, einen dynamischen Routing Daemon zu installieren. Bei Funkfeuer Wien ist das aktuell OLSRd (Open Link State Routing Daemon in Version 1). Dieser erkennt über zB. Funkstrecken die Router an den Gegenstellen und tauscht IP-Adressdaten aus, damit man selbst erreichbar ist und auch das Internet oder andere Standorte erreichen kann. Dieser Routing Daemon funktioniert sowohl für IPv4 als auch IPv6. Nähere Informationen zur Funktionsweise von dynamischem bzw. adaptivem Routing findet man bei Wikipedia.
Installation
Um die Installation möglichst einfach zu gestalten, hat Christoph Lösch, ein engagierter Kollege von Funkfeuer Wien, einen Wizard erstellt. Dieser Wizard kann über das Webinterface der EdgeRouters installiert und konfiguriert werden und stellt alle benötigten Funktionen und Optionen zur Verfügung.
Installiert wird der Wizard, indem man am EdgeRouter auf den Tab “Wizards” klickt und danach das “+” bei “Feature Wizards” klickt. Dort kann man die Version hochladen, die man bei Github gefunden hat und als Namen zB. “OLSRd_V1” vergeben. Unter diesem Namen scheint der Wizard dann auch auf.
Seit Version 1.3 (Update 3, u3 vom Oktober 2016) enthält der Wizard auch die olsrd-Pakete. Davor musste man diese separat hochladen, oder den Router online bringen, damit der Wizard die Pakete selbst vom Internet nachlädt.
Nach der Installation sieht man beim “Package Status” hoffentlich zwei “Success”-Meldungen: eine für den Routing Daemon selbst (olsrd) und eine für die Plugins (olsrd-plugins). Mit den Plugins ist es möglich, Informationen über das Routingprotokoll zB. per http abzurufen.
Sofern alles geklappt hat, kann man nun folgende Optionen anhaken:
Setup Script,
Enable OLSR daemon,
Run OLSR daemon (on boot, if enabled)
und das bzw. die Interface(s) wählen, bei denen OLSRd aktiv sein soll. Das sind in der Regel die Interfaces mit den öffentlichen IP-Adressen.
Bitte aktiviert OLSRd nicht auf den privaten IPs, da diese sonst auch im Netz geroutet werden.
Die gleichen Optionen wählt man (bei Bedarf) auch für IPv6.
Danach klickt man auf “Restart OLSR daemon(s) on ‘Apply'”, damit die Änderungen auch vom Routingprozess übernommen werden und wählt “Apply”. Kurze Zeit später sollte der Router online sein.
Überprüfen kann man das über die OLSRd Plugins, zB. httpinfo (wenn aktiviert) über die IP des Routers und Port 8080 für IPv4 oder Port 8081 für IPv6. Falls dort nichts antwortet, prüft bei den Einstellungen des Wizards, ob die entsprechenden Plugins auch aktiviert sind.
Setup Script
Im Zuge der Installation haben wir die Option “Setup Script” aktiviert. Ich empfehle, das dauerhaft aktiviert zu lassen. Dadurch prüft der Wizard bei jedem Reboot, ob die olsrd-Pakete ordentlich installiert sind bzw. würde sie ggf. neu installieren. Das ist zum Beispiel bei einem Upgrade des Images des EdgeRouters nötig – der Wizard bleibt nach einem Upgrade erhalten, aber die olsrd-Pakete sind nicht mehr installiert; das erledigt das Setup-Script beim ersten Bootvorgang mit der neuen EdgeOS-Version.
Wizard updaten
Da Christoph und die Community fleißig neue Funktionen integrieren und ggf. auch neue Versionen von olsrd mit Bugfixes oder sicherheitsrelevante Updates erscheinen, könnte es sinnvoll sein, den Wizard zu aktualisieren und damit die Umgebung up-to-date zu halten.
Der Vorgang dafür ist sehr einfach: den Wizard mittels des Buttons “Delete From List” ganz unten in den Wizard-Optionen entfernen und gleich darauf die neue Version installieren.
Modelle
Getestet habe ich den Wizard mit folgenden EdgeRoutern:
Der Wizard soll auch auf anderen EdgeRouter-Modellen funktionieren, da er die Plattform (mips vs. mipsel) selbstständig erkennt und korrekt installiert.
Am 13. +14. Mai 2016 wurde eine Sicherheitslücke (vmtl. im Webserver) der Ubiquiti Airmax Antennen mit AirOS Software ausgenutzt. Die Gesamtzahl der Standorte ist von etwa 230 aktiven Knoten auf knapp mehr als 150 Nodes zurückgegangen, die unmittelbar nach der Attacke noch online waren. Mittlerweile geht die Zahl zum Glück wieder nach oben.
Aus jetziger Sicht platziert der Hack einige Dateien unter /etc/persistent. Außerdem werden die Login-Daten überschrieben und SSH-Keys installiert, mit denen ein Hacker von außen weiterhin auf die Antenne zugreifen kann.
Sollten Spuren des Hacks auf einer Antenne auftauchen, ist es jedenfalls empfehlenswert, per TFTP ein Image neu zu laden und die Antenne neu zu konfigurieren. Die Vorschläge weiter unten in diesem Text sind eher als Sofortmaßnahme gedacht, um die Antennen rasch wieder online zu bekommen.
Auswirkungen / Festellen des Hacks
Ich habe zwei Auswirkungen des Problems auf meinen Antennen festgestellt:
Großteils sind die Antennen auf Werkseinstellungen zurückgesetzt und daher über 192.168.1.20 mit Username “ubnt” und Passwort “ubnt” erreichbar. Eine Veränderung an den Antennen konnte ich nicht feststellen, wodurch das Einspielen eines Backups bzw. eine Neukonfiguration das Problem rasch löst. Idealerweise flasht man die Antenne per TFTP neu. Leider muss man diese Schritte vmtl. vor Ort durchführen, also hinfahren…
Manche Antennen sind noch online, aber ich kann mich nicht mehr mit dem bekannten Passwort anmelden. Wenn die Antenne “erfolgreich” gehackt ist, wurden Username + Passwort auf “mother” und “fucker” geändert. Mein “ubnt”-User hat nicht mehr funktioniert, obwohl er in der /etc/passwd noch enthalten ist. Seit dem Entfernen des Hacks funktioniert mein ubnt-User wieder normal. Das Passwort ändert man zur Sicherheit trotzdem.
Im Verzeichnis /etc/persistent/ findet man außerdem mehrere Files als Hinweis auf den Hack. Diese Antenne ist somit vom Virus befallen und muss gesäubert werden!
Details zum Hack
Details findet ihr im Forum von Ubiquiti Networks. Aktuell beginnen auch erste Händler entsprechende Hinweise zu posten:
Zuerst muss man feststellen, ob sich die Antenne im Werkszustand befindet oder nicht. Wenn sie über 192.168.1.20 mit Username “ubnt” und Passwort “ubnt” per Webbrowser erreichbar ist, kann man wie gewohnt die Konfiguration durchführen bzw. ein Backup einspielen. Besser ist es, zur Sicherheit per TFTP neu zu flashen. Dann kann man wirklich davon ausgehen, dass kein Schadcode erhalten bleibt.
Wichtig: zum Abschluss muss die Firewall konfiguriert werden, sodass Zugriffe über http und https nur von vertrauenswürdigen IP-Adressen möglich sind. Siehe dazu “Konfiguration der Firewall”.
Entfernen des Virus
Falls die Antenne erreichbar ist, gehört unbedingt geprüft, ob der bisherige Login noch funktioniert. Wenn die Antenne gehackt wurde, muss man ab sofort mit den Daten des Hackers, Username “mother” und Passwort “fucker”, einloggen.
Ich habe mir erlaubt, das desinfect.sh-Script (Ausgangspunkt ist commit #c841d87) von Github zu übernehmen und einige Funktionen anzupassen, damit es für meine Zwecke passt.
Funktionsübersicht:
das Script wird lokal auf der Antenne über SSH ausgeführt.
das Script überprüft, ob die Antenne infiziert ist.
die infizierten/veränderten Files werden gelöscht
die Accounts für “mcad”, “mcuser” und “mother” in /etc/inittab und /etc/passwd werden gelöscht
die Änderungen werden persistent gespeichert
Prozesse des Hacks werden gekillt
wichtig: danach muss die Firewall (siehe unten) konfiguriert und rebootet werden!
#!/bin/sh
# This script removes the Ubiquiti AirOS hack
# Script is based on this work:
# https://github.com/diegocanton/remove_ubnt_mf
# Colaboration: Alexandre Jeronimo Correa - Onda Internet, PVi1 (Git user)
# modified 2016/05/16 by Stefan Schultheis
FILE=/etc/persistent/mf.tar
# Check virus
if [ -e "$FILE" ] ; then
echo "Infected :("
#Access folder
cd /etc/persistent
#Remove the virus
rm mf.tar
rm -Rf .mf
rm -Rf mcuser
rm rc.poststart
rm rc.prestart
#Remove mcuser in passwd - by Alexandre
sed -ir '/mcad/ c ' /etc/inittab
sed -ir '/mcuser/ c ' /etc/passwd
sed -ir '/mother/ c ' /etc/passwd
#Write new config
cfgmtd -w -p /etc/
#Kill process - by Alexandre
kill -HUP `/bin/pidof init`
kill -9 `/bin/pidof mcad`
kill -9 `/bin/pidof init`
kill -9 `/bin/pidof search`
kill -9 `/bin/pidof mother`
kill -9 `/bin/pidof sleep`
echo "Clear Completed :)"
else
echo "Clear :) No actions"
exit
fi
Wichtig: zum Abschluss muss die Firewall konfiguriert werden, sodass Zugriffe über http, https und ssh nur von vertrauenswürdigen IP-Adressen möglich sind. Siehe dazu “Konfiguration der Firewall”.
Achtung bei Upgrade zu AirOS 5.6.5
Ubiquiti scheint ein Upgrade zu AirOS 5.6.5 zu empfehlen. Hier ist zu beachten, dass es
keine Unterstützung für den Routing-Daemon OLSRd dort gibt,
keine Custom Scripts (/etc/persistent/rc.*) mehr gibt! Dadurch kann die bestehende Funktion eingeschränkt sein!
Konfiguration der Firewall
Ich schalte mir nur einzelne IP-Adressen für den Zugriff auf die Webinterfaces frei, das mache ich mit folgenden iptables-Regeln. Hier werden künftig nur mehr Zugriffe aus 78.41.113.x und 78.41.113.y zugelassen (bitte eigene IPs einsetzen).
touch /etc/persistent/rc.poststart
echo "iptables -F" >> /etc/persistent/rc.poststart
echo "iptables -A INPUT -s 78.41.113.x -j ACCEPT" >> /etc/persistent/rc.poststart
echo "iptables -A INPUT -s 78.41.113.y -j ACCEPT" >> /etc/persistent/rc.poststart
echo "iptables -A INPUT -p tcp --dport 80 -j DROP 2>/dev/null" >> /etc/persistent/rc.poststart
echo "iptables -A INPUT -p tcp --dport 443 -j DROP 2>/dev/null" >> /etc/persistent/rc.poststart
echo "iptables -A INPUT -p tcp -i lo --dport 443 -j DROP 2>/dev/null" >> /etc/persistent/rc.poststart
cfgmtd -w -p /etc/
Ich empfehle darüber nachzudenken, ob man nicht die Erreichbarkeit von SSH ebenfalls auf ein paar weniger IPs beschränken möchte.
Nach einem Reboot ist die Antenne nur mehr von den oben eingetragenen IPs erreichbar.
Am 21. April 2016 ist die aktuelle LTS (= Long Term Support) Version 16.04 von Ubuntu Linux erschienen: Xenial Xerus (“gastfreundliches Borstenhörnchen”). Der Hinweis “LTS” verspricht Updates und Support während der nächsten 5 Jahre.
Nach Möglichkeit versuche ich meine Systeme immer auf LTS-Versionen von Ubuntu zu betreiben. Dadurch drängt sich aktuell natürlich ein Update aller Server und Desktops zu 16.04 LTS auf. Hier beschreibe ich, wie der Vorgang für die Upgrades funktioniert.
Upgrade auf Desktop Systemen
Auf Desktop Systemen mit grafischer Oberfläche klickt man auf “Systemeinstellungen” im Unity-Menü links. Dort findet man “Anwendungen und Aktualisierungen” und wählt dort in der Auswahl “Über neue Ubuntu-Versionen benachrichtigen” den Punkt “Für Langzeitunterstützungsversionen“. Danach aktiviere ich die Einstellung durch klick auf “Schließen”.
In einem Terminal-Fenster starte ich nun
update-manager
, um die Installation zu starten. Zuerst werden die Paketquellen aktualisiert, danach beginnt die Installation bzw. das Upgrade.
Upgrade auf Server Systemen
Auf Server Systemen findet man üblicherweise keine grafische Oberfläche, daher muss das Update rein über die Kommandozeile ausgeführt werden.
Bei physischen oder virtuellen Systemen ist es vorteilhaft, über die Console verbunden zu sein anstatt über SSH. Bei virtuellen Systemen empfehle ich einen Snapshot am Hypervisor vor dem Upgrade zu erstellen (oder einen Sicherungspunkt, wie es bei manchen Virtualisierungsplattformen heißt).
Für das Upgrade wird das Paket “update-manager-core” benötigt. Falls es nicht installiert ist, kann es mit
apt-get install update-manager-core
als root nachinstalliert werden.
Die Konfiguration des Update-Manager findet man in /etc/update-manager/release-upgrades.
Gültige Konfigurationen in dieser Datei sind zB.
Prompt=lts
Dabei werden nur Upgrade zu LTS-Versionen angeboten. Es wäre auch möglich, jedes neue Release als Upgrade anzubieten über Prompt=normal. Oder nie bzgl. Upgrades gefragt zu werden: Prompt=never
Danach kann das Update über
do-release-upgrade
gestartet werden.
Meldung: No new release found
Der update-manager schlägt von selbst die Upgrades erst vor, wenn die “first point release” veröffentlicht wurde, also Ubuntu 16.04.1 LTS.
Das wurde von Ubuntu Engineering Foundations scheinbar aus Gründen der Zuverlässigkeit so festgelegt.
Um das Upgrade dennoch bereits mit 16.04 LTS durchzuführen, fügt man die Option “-d” dem Installationskommando hinzu:
Ich habe mir vor ein paar Wochen eine GoPro Hero 4 Black Edition gekauft und natürlich muss ich seither bei jeder Gelegenheit filmen. Da ich zu Hause nur Linux-Systeme verwende, kann ich zur Verarbeitung der Videos nicht auf das GoPro-Studio zurückgreifen. Auch die von GoPro verwendeten Codecs machen die Sache nicht einfacher.
Ich musste das Script bei mir etwas abändern, damit es funktioniert, aber mit dem Ergebnis bin ich sehr zufrieden. Das Script konvertiert mittels ffmpeg alle .MP4-Dateien aus dem lokalen Verzeichnis in .mov-Dateien mit mpeg4, die von gängigen Programmen angezeigt oder weiterbearbeitet werden können.
Nachtrag Juli 2020: ich habe obiges Script nun im Sommer 2020 probiert. Die Option “-sameq” wurde mittlerweile von ffmpeg entfernt. Ich habe es durch “-qscale 0” ersetzt. Für mich hat diese abgeänderte Version des Scripts gut funktioniert:
for i in *.MP4;
do name=`echo $i | cut -d'.' -f1`;
echo $name;
ffmpeg -i $i -qscale 0 -strict experimental -vcodec mpeg4 $name.mov;
done
Dieser Konvertierungsvorgang dauert zwar ziemlich lange – bei mir zirka die 6-7fache Spieldauer des Videos, aber es kann im Hintergrund laufen und beseitigt meine Probleme mit fast allen Programmen.
Mein Beispielvideo habe ich mit 2,7k Auflösung (2704×1520) und 50 fps erstellt. Es hat eine Länge von 40,58 Sekunden und ist 305 MB groß.
Der Konvertierungsvorgang hat 4 Minuten 35 Sekunden gedauert (Prozessor Quad Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz). Die Ergebnisdatei (.mov-Datei) ist 210 MB groß.
Durch hinzufügen des Parameters “-threads 8” lassen sich mehrere Prozesse zur Konvertierung von ffmpeg nutzen, also mehrere CPU-Kerne, falls verfügbar. Auf meinem System reduziert sich die Dauer damit um ca. 20%-23%.
Der Raspberry und DVB-T-Stick sind in einem Outdoor-Gehäuse verbaut.
Mit diesem Setup möchte ich einen APRS iGate realisieren, also eine Konfiguration, mit der APRS-Pakete auf der europäischen APRS-Frequenz 144.800 MHz empfangen und dann weitergeleitet werden. Die Weiterleitung soll primär über HAMnet erfolgen und nur im Fehlerfall oder bei nicht-Verfügbarkeit meiner HAMnet-Anbindung direkt ans einen APRS-IS-Tier2-Server (vgl. http://www.aprs2.net/) ins Internet übertragen werden.
Da pymultimonaprs die Messages nicht selbst dekodiert, müssen wir noch multimon-ng installieren:
cd ~
sudo apt-get install cmake
git clone https://github.com/EliasOenal/multimon-ng.git cd multimon-ng mkdir build cd build cmake .. make sudo make install
Installation
Die iGate-Software pymultimonaprs installiere und hole ich von GIT:
cd ~
sudo apt-get install python2.7 python-pkg-resources
git clone https://github.com/asdil12/pymultimonaprs.git
cd pymultimonaprs
sudo python2 setup.py install
Ich habe für meinen Call OE1SCS den Suffix -10, auch SSID genannt, gewählt, der lt. APRS SSID-Erklärung für “internet, Igates, echolink, winlink, AVRS, APRN, etc” gedacht ist.
Im Eintrag “gateway” habe ich eine Liste an APRS-IS Gateways eingetragen. Die Liste wird bei jedem Neustart von pymultimonaprs vom ersten Eintrag neu abgearbeitet. Ich habe also die Gateways, die ich bevorzuge, an den Anfang geschrieben. Die meisten iGates besitzen sprechende DNS-Namen. Ich will jedoch nicht von einem funktionierenden DNS-Dienst abhängig sein, daher trage ich die IP-Adressen ein. Damit dort nicht nur kryptische HAMnet-IP-Adressen (beginnen mit 44.) stehen habe, habe ich in der gleichen Zeile den DNS-Namen zusätzlich hinterlegt, zB.: “aprs.oe2xzr.ampr.at:14580”, “44.143.40.90:14580”
Der Dienst versucht 120 Sekunden die APRS-iGates zu erreichen. Nach 120 Sekunden meldet er ein Timeout und probiert den nächsten iGate. Sollte das Netzwerk nicht verfügbar sein oder der iGate-Server am eingestellten Port nicht antworten, wartet pymultimonaprs das Timeout nicht ab, sondern probiert unmittelbar den nächsten iGate in der Liste.
Hier ein Beispiel aus meinem Logfile:
Jan 2 10:53:42 roofpi pymultimonaprs: connecting... 44.225.42.181:14580
Jan 2 10:53:42 roofpi pymultimonaprs: Error when connecting to 44.225.42.181:14580: '[Errno 101] Network is unreachable'
Jan 2 10:53:51 roofpi pymultimonaprs: connecting... 78.47.75.201:14580
Jan 2 10:53:51 roofpi pymultimonaprs: connected
Jan 2 10:53:51 roofpi pymultimonaprs: # aprsc 2.0.18-ge7666c5
Jan 2 10:53:51 roofpi pymultimonaprs: login OE1SCS-10 (PyMultimonAPRS 1.2.0)
Jan 2 10:53:51 roofpi pymultimonaprs: # logresp OE1SCS-10 verified, server T2EISBERG
Jan 2 10:53:51 roofpi pymultimonaprs: sending: OE1SCS-10>APRS,TCPIP*:=4811.4 N/01623.2 E-RXonly APRS iGate
Jan 2 10:53:51 roofpi pymultimonaprs: sending: OE1SCS-10>APRS,TCPIP*:>Raspberry Pi mit RTL Stick
Mittels “append_callsign”: true, gebe ich an, dass mein Call in den APRS-Pfad bei der Weiterleitung ans iGates dazugefügt werden soll.
im Abschnitt “rtl” wähle ich die Frequenz 144.800 MHz als europäische APRS-QRG, gebe meine Ungenauigkeit des Sticks (26 ppm) an, die ich vorher gemessen habe und wähle einen Gain von 46. Offset-Tuning lasse ich unbenutzt und da ich nur einen DVB-T-Stick am Raspberry habe, lasse ich den device-index bei 0.
im Abschnitt “beacon” konfiguriere ich die eigene, regelmäßige, Aussendung meiner “Station”:
Ich wähle einen statischen Text für “comment” und “status“, außerdem übertrage ich im Moment keine Wetter-Informationen. Ich möchte, dass meine Aussendung alle 30 Minuten übertragen wird (30 Minuten * 60 Sekunden = 1800 Sekunden).
Um meine Positionen nicht 100%ig genau im APRS darzustellen, habe ich die “ambiguity” auf “1” gesetzt. Das verringert die Genauigkeit meiner GPS-Position um 1/10 Grad-Minute. Dadurch wird meine APRS-Position auf aprs.fi mit dem Hinweis “Position ambiguous: Precision reduced at transmitter by 1 digits, position resolution approximately 185.2 m.” zB. so dargestellt:
meine Station wird bewusst mit einer Ungenauigkeit von ca. 185 Metern in dem violetten Feld angezeigt. Das Feld weist darauf hin, dass die Position nicht exakt ist.
Damit wäre alles konfiguriert und über das Kommando
/etc/init.d/pymultimonaprs start
habe ich den Dienst gestartet.
Die Funktion kann man über das Logfile /var/log/syslog rasch prüfen. Unmittelbar nach dem ersten Start war meine Station auf aprs.fi sichtbar: http://aprs.fi/info/a/OE1SCS-10
Erfahrungen, Tipps & Tricks
Zuverlässigkeit des USB-Sticks
Ich habe den Dienst einige Tage laufen gelassen. Nach zirka zwei Tagen habe ich folgende Fehlermeldung im Logfile gehabt. Auch über “dmesg” war das Problem sichtbar:
Dec 30 21:23:34 roofpi kernel: [ 2139.021653] usb 1-1.3: usbfs: usb_submit_urb returned -121
Dec 30 21:23:34 roofpi kernel: [ 2139.022123] usb 1-1.3: usbfs: usb_submit_urb returned -121
Dec 30 21:23:34 roofpi kernel: [ 2139.022580] usb 1-1.3: usbfs: usb_submit_urb returned -121
Dec 30 21:23:34 roofpi kernel: [ 2139.023041] usb 1-1.3: usbfs: usb_submit_urb returned -121
Dec 30 21:23:34 roofpi kernel: [ 2139.023968] usb 1-1.3: USB disconnect, device number 4
Dec 30 21:23:34 roofpi kernel: [ 2139.260292] usb 1-1.3: new high-speed USB device number 6 using dwc_otg
Dec 30 21:23:34 roofpi kernel: [ 2139.372309] usb 1-1.3: New USB device found, idVendor=0bda, idProduct=2832
Dec 30 21:23:34 roofpi kernel: [ 2139.372335] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Dec 30 21:23:34 roofpi kernel: [ 2139.372353] usb 1-1.3: Product: RTL2832U
Dec 30 21:23:34 roofpi kernel: [ 2139.372369] usb 1-1.3: Manufacturer: Generic
Dec 30 21:23:34 roofpi kernel: [ 2139.372386] usb 1-1.3: SerialNumber: 77771111153705700
Es hat sich also der USB-Stick verabschiedet “usb 1-1.3: USB disconnect, device number 4” und sofort wieder neu verbunden. Damit war natürlich ein Neustart des pymultimonaprs nötig, damit dieses wieder korrekt lauscht. Leider war es damit nicht getan und der Fehler ist wenige Minuten später wieder gekommen. Ich habe das ein paar Mal wiederholt und schon befürchtet, dass der Stick vielleicht kaputt ist. Ein Reboot hat die Situation aber entschärft und nun läuft der Stick wieder seit 2 Tagen stabil.
APRS-Meldungen der ISS
Mit einem einfachen Hack, der unter anderem hier beschrieben wird, soll es möglich sein, neben der primären APRS-Frequenz 144.800 MHz auch die APRS-Frequenz der Raumstation ISS zu empfangen. Diese sendet auf 145.825 MHz. Natürlich können diese Meldungen nur gehört werden, wenn sich die ISS in Reichweite befindet. Es gibt zahlreiche Webseiten im Internet, mit denen der Zeitpunkt der nächsten Überflüge der ISS am eigenen Standorts berechnet werden kann.
Leider hat sich dieser Hack bei mir nicht bewährt: mein Stick schafft es kaum noch APRS-Meldungen zu decoden, wenn er auf beide Frequenzen hört. Die Qualität nimmt rapide ab. Woran es genau liegt, kann ich schwer sagen. Ich habe aber die Vermutung, dass es am Squelch liegt, der bei dieser Konfiguration genutzt werden muss: das Programm rtl_fm, das dem Empfang der Pakete übernimmt, funktioniert ohne Squelch, sofern man nur auf einer QRG hört. Wenn man mehrere QRGs angibt (144.8, 145.825, …) muss ein Squelch-Wert angegeben werden. Ich habe zwar 1 als kleinsten möglichen Wert konfiguriert, vermute aber, dass der Squelch bei APRS-Paketen zu spät reagiert und daher viele Pakete nicht vollständig gehört werden. Sobald ich nur auf 144.8 ohne Squelch höre, empfange ich wieder viel mehr Pakete und alles scheint zu funktionieren.
pymultimonaprs kann auch Wetterdaten mitsenden. Ich habe leider keine Wetterstation, möchte aber Telemetriedaten meines Raspberry Pi 2 übermitteln. Dazu kann man ein JSON-File erstellen, das diesem Format entspricht (Quelle: https://github.com/asdil12/pymultimonaprs/blob/master/README.md):
You can set weather to a json-file. eg: "weather": "/path/to/weather.json",
If you don’t want do send weather date, just leave it on false. This will be read in like the status-file and can look like that:
timestamp is seconds since epoch – must be included
wind
speed is in km/h
direction is in deg
gust is in km/h
temperature is in °C
rain
rainlast1h is in mm
rainlast24h is in mm
rainmidnight is in mm
humidity is in %
pressure is in hPa
The timestamp must be included – everything else is optional.
Meine Idee wäre, die Temperatur & Spannung des Raspberry Core zu übermitteln, die mittels des Kommandos “vcgencmd” ermittelt werden können. Details siehe hier: http://elinux.org/RPI_vcgencmd_usage
Ich müsste also ein JSON-File erstellen, in das ich
Für die Spannungen ist kein Feld in den Wetterdaten vorgesehen. Man könnte diese Daten also über die “status“-Aussendung übermitteln. Dazu ändert man im Konfig file (/etc/pymultimonaprs.json) im Bereich “status” folgendes:
Im vorigen Beitrag habe ich für diesen Blog ein Zertifikat von Let’s encrypt! erstellt. Dieses ist 3 Monate gültig. Es ist vorgesehen, dass das Erneuern des Zertifikats automatisch passiert.
Konkret werde ich einen Cronjob erstellen, der monatlich ein neues Zertifikat mit Hilfe des “letsencrypt-auto” Python-Script bezieht.
Konfiguration
Um mir eine Menge Kommandozeilenoptionen zu ersparen, erstelle ich eine Konfigurationsdatei /etc/letsencrypt/cli.ini, die meine Standardwerte enthält:
rsa-key-size = 4096
text
redirect
renew-by-default
agree-tos
email = meine.email@adresse.at
Hier sind die Parameter kurz erklärt:
rsa-key-size
entweder 2048 (Standard) oder sicherer mit 4096 Bit. Ich möchte meine Zertifikate mit 4096 Bit RSA erstellen.
text
nur im Text-Modus starten (ohne Menüführung). Schließlich soll der Client automatisch im Hintergrund funktionieren.
redirect
ich wurde immer gefragt:
Please choose whether HTTPS access is required or optional.
-------------------------------------------------------------------------------
1: Easy - Allow both HTTP and HTTPS access to these sites
2: Secure - Make all requests redirect to secure HTTPS access
-------------------------------------------------------------------------------
Select the appropriate number [1-2] then [enter] (press 'c' to cancel):
Um diese Frage vorab zu beantworten, fügt man entweder die CLI-Option “–redirect” an, oder eben in der cli.ini den Ausdruck “redirect”. Damit wird die Option 2 gewählt: make all requests redirect to secure HTTPS access.
renew-by-default
Erneuert das Zertifikat standardmäßig.
agree-tos
Damit stimmt man den Regeln von let’s encrypt! zu. Schließlich wollen wir den Vorgang ja per Cronjob automatisieren und nicht die Regeln manuell bestätigen müssen.
email
Die Email-Adresse, mit der ich bei let’s encrypt! registiert bin.
Damit bekomme ich jedes Monat am 20. Tag das Zertifikat erneuert. Da derzeit das Zertifikat für 90 Tage gültig ist, bin ich damit auf der sicheren Seite und habe immer ein Zertifikat, das maximal 31 Tage alt ist.
SSL-Zertifikate für Webserver nach dem Standard X.509 haben – kurz gesagt – zwei Aufgaben:
sie verschlüsseln die Verbindung zwischen Webserver und Client bzw. Browser am Client (Internet Explorer, Firefox, Chrome, Safari, …). Das ist erkennbar am https:// zu Beginn einer Webseitenadresse.
sie bestätigen, dass der aufgerufene Webdienst zu der Organisation gehört, die man aufgerufen hat. Das ist zB. beim Online Banking wichtig. Da will man ja wirklich nur bei der eigenen Bank einloggen und die Kennworte eingeben und nicht auf einer Fishing-Seite, die vorgibt, die Seite der Bank zu sein und in Wirklichkeit die Zugangsdaten an Betrüger übergibt.
Bisher habe ich meine SSL-Zertifikate für Webserver über CACert erhalten. Damit diese ohne Warnung bzw. Fehlermeldung von den Clients/Browsern akzeptiert werden, muss man jedoch erst manuell dem Root-Zertifikat von CACert vertrauen. Nur wenige Distributationen, zB. Debian, vertrauen CACert standardmäßig.
Der neue Internet-Dienst Let’s Encrypt bietet kostenlose SSL-Zertifikate an, die von gängigen Browsern akzeptiert werden. Seit 3. Dezember 2015 ist dieser Dienst in einer Public Beta Phase und kann nun von jedermann genutzt werden.
Besonders spannend finde ich, dass Let’s Encrypt einen Client bereitstellt, mit dem die Zertifikate erzeugt/beantragt werden und der sie auch gleich im Webserver installiert. Die gängigen Methoden über Certificate Signing Requests (CSR) werden nicht angeboten.
Das Ziel
Um den neuen Dienst auszuprobieren, möchte ich meinen WordPress-Blog, der aktuell unter http:// und https:// (mit CACert-SSL-Zertifikat) erreichbar ist, nur mehr über https:// anbieten und mit einem Let’s Encrypt-Zertifikat versehen.
Die Standard-URL meines Blogs ist derzeit http://, also unverschlüsselt. Das möchte ich auch ändern und somit in Zukunft den Inhalt nur mehr verschlüsselt ausliefern.
Let’s go!
Mein Blog läuft unter Ubuntu 14.04 LTS. Hier muss ich zuerst “git” installieren, damit der letsencrypt-Client geladen werden kann:
Danach kann ich ins Verzeichnis “letsencrypt” wechseln und dort das Programm “letsencrypt” mit dem Parameter “auto” ausführen. Mein Webserver (apache) ist ein häufig verwendeter Webserver und sollte vom Programm erkannt werden:
cd letsencrypt/
./letsencrypt-auto
Es erscheint ein praktisches ncurses-geführtes Menü, das nach der Webseite bzw. dem Domainnamen fragt, für den ein Zertifkat erstellt werden soll. Der Dienst hat also meine Konfiguration korrekt erkannt:
Nach der Bestätigung, werde ich nach meiner Email-Adresse gefragt:
Hier erhalte ich leider eine Fehlermeldung: “There seem to be a problem with that address.”. Ich habe das leider nicht lösen können. Lt. Recherche im Internet wird überprüft, ob zu der Email-Adresse entsprechende MX bzw. A-Records bei DNS eingerichtet sind. In meinem Fall gibt es gültige MX-Records. Trotzdem akzepiert letsencrypt die Adresse nicht. Es gibt zwei Möglichkeiten fortzusetzen;
entweder man startet den letsencrypt-Client mit dem Parameter –register-unsafely-without-email oder
ich verwende eine andere Email-Adresse.
Da in Foren davon abgeraten wird, keine Email-Adresse anzuführen, habe ich einfach eine GMX-Adresse von mir genutzt. Damit war das Problem “gelöst”.
Im nächsten Schritt hat mich der letsencrypt-Client gefragt, ob ich in der Webserver-Konfiguration auch http-Verbindungen zulassen möchte, oder nur https. Die Varianten heißen “Easy” und “Secure”. Ich habe ja als Ziel im Auge, alle Verbindungen mit dem Zertifikat zu versehen, also habe ich “Secure” gewählt:
Und schon kommt die Meldung, dass letsencrypt fertig ist:
Ich habe sofort die Webseite in meinem Browser neu geladen und sofort das letsencrypt-Zertifikat gesehen. Die Seite wurde ohne Fehler angezeigt.
Der letzte Schliff in WordPress
Weil mein Blog bisher über http:// angeboten wurde, habe ich im WordPress Backend die Hauptadresse und Webseiten-Adresse angepasst und von https://stefan.schultheis.at auf https://stefan.schultheis.at geändert:
Um sicher zu gehen, dass keine Inhalte mehr über http geladen werden, habe ich ein WordPress Plugin installiert: Easy HTTPS (SSL) Redirection. Dieses Plugin sendet bei http-Aufrufen ein Redirect (http 301, Moved Permanently) zu https. Damit stelle ich sicher, dass künftig alle Aufrufe über https beantwortet werden.
Die Konfiguration des Plugins war wirklich einfach. Ich habe die “Automatic redirection to the HTTPS” aktiviert und für “The whole domain” gewählt. Weiters erzwinge ich https mittels “Force resources to use HTTPS URL”:
Es gibt eine Warnung, die am Screenshot oben rot sichtbar ist, was zu tun wäre, wenn es zu Problemen kommt. Diese Warnung habe ich ignoriert, ich hatte auch keine Probleme nach der Aktivierung.
Prüfung des Zertifikats
Ab sofort ist mein Blog also unter https:// erreichbar. Wenn man mit http:// aufruft, wird man sofort mittels 301-Redirect auf die verschlüsselte Version verwiesen.
Das Zertifikat wird in Firefox (Version 42.0) problemlos angezeigt:
Das Zertifikat ist als 2048 Bit RSA mit SHA-256 und Gültigkeit von 3 Monaten sichtbar:
Die Zertifkatskette zeigt “DST Root CA X3” als Stammzertifizierungsstelle, danach die “Let’s Encrypt Authority X1”:
Nach der Installation des Zertifikats empfiehlt übrigens auch Let’s Encrypt, dass man die Konfiguration mittels eines Gratisdiensts von Qualys SSL Labs prüft: https://www.ssllabs.com/ssltest/
In meinem Fall habe ich Grade A bekommen, also die Bestnote. Das spricht für die saubere Implementierung durch den Let’s Encrypt Client und für eine saubere Konfiguration der Sicherheitseinstellungen des Webservers:
Der Qualys-Test überprüft eine große Anzahl an Werten und Konfigurations-Einstellungen. Unter anderem beispielsweise die angebotenen Verschlüsselungsstärken, die Konfiguration von Perfect Forward Secrecy, die Kompatibiltät zu Endgeräten und Browsern uvm.
Falls bei euch hier Einschränkungen angezeigt werden, helfen vielleicht die Empfehlungen von bettercrypto.org. Dort findet ihr ein “Paper”, in dem für zahlreiche gängige Webvserver Konfigurationen empfohlen werden, um die Sicherheit zu verbessern und unsichere Methoden zu beseitigen. Ich gehe mittlerweile bei der Installation von neuen Webserver immer nach deren Anleitung vor, auch beim gegenständlichen Blog.
Mein Fazit
Die Installation war super-einfach und hat super funktioniert, bis auf meine Email-Adresse, die vom Client nicht akzeptiert wurde (wie oben beschrieben). Da diese Email-Adresse aber sowieso nicht im Zertifikat zu sehen ist, sehe ich da kein großes Problem – Hauptsache, es ist eine gültige Email-Adresse verknüpft. Der übrige Teil der Installation und das Zertifikat selbst waren einwandfrei.
Für mich stellt sich noch eine Frage: vertraue ich dem Zertifikat für sensible Kommunikation?
Hier bin ich noch vorsichtig. Vielleicht bin ich zu Paranoid und es ist hier gar nicht angebracht, aber die bisher gängige Methode mittels CSR war mir schon sympathisch. Der private Schlüsselteil ist dabei nämlich immer bei mir geblieben. Ich vermute, dass auch bei Let’s Encrypt der private Teil des Schlüssels meinen Server nicht verlässt. Auch aufgrund der Tatsache, dass der Quellcode des Programms offen ist (Open Source) und jeder im Internet überprüfen kann, was bei der Installation genau passiert.
Trotzdem: ich werde Let’s Encrypt auf meinen Webseiten verwenden, die für die Öffentlichkeit gedacht sind. Auf Webseiten, die private und schützenswerte Inhalte liefern (zB. OwnCloud oder VPNs) werde ich wohl derweil noch bei selbstsignierten Zertifikaten bleiben oder CACert nutzen, wo man über CSR die Zertifikate beantragt.
Für meine Anwendungen zu Hause habe ich einen HP MicroServer Gen8 erstanden und um RAM (2 GB zu 10 GB), SD-Karte, ILO-Lizenz ua. um insgesamt rund € 300,- erweitert.
SD-Karte? Ja, am Motherboard ist ein SD-Karten-Slot. Ich habe dort die 16 GB Micro SD-Karte eingelegt. Das Ziel ist ein Virtualisierungs-Host, der von SD-Karte bootet und somit “diskless” (also ohne Festplatten (HDD/SSD)) funktioniert. Die Daten kommen über iSCSI oder NFS von meinem Synology NAS (DiskStation DS214play).
Mittlerweile habe ich den VMWare ESXi 6 U1 probiert und auch XenServer 6.5 SP1. Beide Versionen sind frei erhältlich und bieten viele Funktionen in der kostenfreien Variante. Über eine kostenpflichte Lizenz sind weitere Funktionen verfügbar. Ich habe hier die freien Versionen getestet.
SD Karte = USB Gerät
Als Installationsgerät wählt man jeweils “USB”. Sowohl im BIOS als auch bei der Installation eines Hypervisors wird die SD-Karte als 14 bzw. 16 GB Speichermedium angezeigt.
Dieses Konzept birgt eine Gefahr: wenn am Server glzg. ein USB-Stick angeschlossen ist, kann es ein, dass dieser versucht, vom Stick anstatt von der SD-Karte zu booten.
Im Internet wird dieses Thema mehrfach behandelt. Ggf. einfach mal danach suchen…
VMWare ESXi 6
Ich habe natürlich zuerst das spzielle HP Image für VMWare ESXi 6 U1 genommen. Dieses Image verspricht aktuellere und umfangreichere Treiber für HP Server. Dabei fiert das System jedoch bei der Installation ein.
Mit der von VMWare bereitsgestellten ISO hat die Installation problemlos geklappt. Auch im Betrieb hat sich das System in einer Testwoche bewährt und vorhandene VMs von meinem älteren ESXi (5) betrieben.
XenServer 6.5
Ich habe bisher wenig Erfahrung mit XenServer. Aber ich habe mittlerweile Vertrauen in die Zuverlässigkeit der Lösung gewonnen und bin auch an den kostenfreien Featues interessiert, die bei VMWare kostenpflichtig sind (allen voran VMotion bzw. eine andere Out-of-the-box Migrationsmethode).
Der XenServer war problemlos installiert. Ich habe ein paar meiner VMWare-VMs konvertiert (bzw. importiert) und auch ein paar neue Ubuntu VMs angelegt. Alles hat wunderbar funktioniert und auch mit der Performance war ich sehr zufrieden.
Zum Herumprobieren und für ein paar Anwendungen zu Hause (Interface zur Hausautomatisierung, ua.) habe ich einen neuen kleinen Server gesucht. Meine wesentlichen Anforderungen sind:
Unterstützung von Virtualisierung (VMWare ESXi, XenServer oder Hyper-V)
MicroSD-Karte als Storage für die Virtualisierungsplattform (war vorhanden)
In Summe bin ich unter 300 Euro geblieben. Damit habe ich mein Ziel vorerst erreicht:
Der HP MicroServer wurde bei mir mit 2 GB RAM geliefert, durch das Upgrade habe ich nun 10 GB zur Verfügung. (Im Link oben verweise ich auf das neuere Modell, das bei etwa dem gleichen Preis mit 4 GB ausgeliefert wird.) In Zukunft kann ich das 2 GB Modul gegen ein weiteres 8 GB Modul tauschen und hätte dann 16 GB zur Verfügung. Das ist auch das Maximum, das der HP MicroServer Gen8 unterstützt.
Das Installieren des Betriebssystems (in meinem Fall habe ich zu Beginn Citrix XenServer probiert) funktioniert über ILO Advanced mit der Remote Console ohne Probleme und auch ohne Datenträger. Das ISO Image muss nur in der Remote Console gemountet werden und die Installation erfolgt superschnell über das Netzwerk.
In diesem Setup möchte ich nun den Stromverbrauch überprüfen. Das mache ich mit meinen bewährten Edimax2101W (hier gekauft).
Das Ergebnis:
beim Starten: 45 Watt
unter Last (beim Booten): 31 Watt
und im Leerlauf: 27 Watt
ausgeschaltet zieht die ILO-Funktion übrigens 5,5 Watt.
Diese Website verwendet Cookies, damit wir dir die bestmögliche Benutzererfahrung bieten können. Cookie-Informationen werden in deinem Browser gespeichert und führen Funktionen aus, wie das Wiedererkennen von dir, wenn du auf unsere Website zurückkehrst, und hilft unserem Team zu verstehen, welche Abschnitte der Website für dich am interessantesten und nützlichsten sind.
Ich erstelle beispielsweise jeden Tag in der Früh einen Report über die Geschwindigkeiten auf meinen Funkfeuer-Standorten. Den Report erhalte ich per Email und kann daran die Performance der weit entfernten Standorte erkennen.
