Schlagwort-Archive: Linux

speedtest.py für Ubiquiti EdgeRouter

Vor kurzem habe ich einen Beitrag über speedtest-cli verfasst, weil man damit Speedtests auf der Kommandozeile von Ubiquiti EdgeRoutern oder EdgePoints automatisieren kann.

Hinweis: im ursprünglichen Beitrag zu diesem Tool sind die Möglichkeiten genauer beschrieben. Ich empfehle, auch einen Blick dorthin zu riskieren.

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

Details zu speedtest.py sind weiterhin hier zu finden: https://github.com/sivel/speedtest-cli

Es kann über folgende Kommandos installiert werden (analog zur bisherigen Anleitung, aber natürlich von anderer Quelle):

curl -o /config/user-data/speedtest.py https://raw.githubusercontent.com/sivel/speedtest-cli/master/speedtest.py
chmod u+x /config/user-data/speedtest.py

gestartet wird ein Test entsprechend über folgenden Aufruf:

/config/user-data/speedtest.py

Es gibt einige praktische Kommandozeilenoptionen, die haben sich durch das Update nicht verändert und habe ich im ursprünglichen Blogbeitrag ausführlicher vorgestellt.

OLSRd (RFC3626) EdgeRouter Installation

olsrd-pinguinDamit 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.

Zum Download steht der Wizard auf github bereit. Die jeweils aktuellste Version findet ihr hier:
https://github.com/vchrizz/ER-wizard-OLSRd_V1/releases/latest

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.

olsrd-wizardNach 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.

olsrd-pluginÜ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.

Mehr zu dem Thema

gibt es hier:

Lösungsvorschläge für den Ubiquiti AirOS AiRMAX Hack vom Mai 2016 im Netz von Funkfeuer Wien

airoslogin-motherAm 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…
  • ubnt-hackManche 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:

Lösungsstrategien

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.

Es gibt ein Removal Tool, das auf Java basiert, von Ubiquiti zum dem Problem: https://community.ubnt.com/t5/airMAX-General-Discussion/Virus-attack-URGENT-UBNT/m-p/1563869

Alternativ gibt es auf Github ein Script, das aber auch den Standard-Port des Webserver auf 81 setzt: https://github.com/diegocanton/remove_ubnt_mf/

Update 16.5.2016: angeblich verbleiben ein paar ipks installiert, es ist somit ein Reset auf Werkseinstellungen (noch besser: per TFTP neu flashen) dem Entfernen/desinfect-Script zu bevorzugen, siehe auch: https://lists.funkfeuer.at/pipermail/wien/2016-May/012228.html

Update 17.5.2016: Ubiquiti stellt eine Android App – ein Virus Removal Tool – zur Verfügung: https://play.google.com/store/apps/details?id=virusfixer.ubnt.com.ubntvirusremoval

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!

Das angepasste Script findet ihr unten und zum Download hier:

#!/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

  1. keine Unterstützung für den Routing-Daemon OLSRd dort gibt,
  2. 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.

Ubuntu 16.04 LTS: Upgrade von 14.04 LTS und 15.10 für Server und Desktop

Am 21. April 2016 ist die aktuelle LTS (= Long Term Support) Version 16.04 von Ubuntu Linux erschienen: Xenial Xerus xenial(“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

ubuntu-version-benachrichtigenAuf Desktop Systemen mit grafischer Oberfläche klickt man auf unity-syseinstellungenSystemeinstellungen” 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

update-manager-upgradeDer 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:

do-release-upgrade -d

 

Linux: GoPro Videos für einfache Bearbeitung mit ffmpeg konvertieren

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.

gopro-ffmpegEinen gute Strategie dafür habe ich auf Github von KonradIT gefunden: https://gist.github.com/KonradIT/ee685aee15ba1c3c44b4#file-convert-multiple-files-md

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.

Hier das angepasste Script:

for i in *.MP4;
  do name=`echo $i | cut -d'.' -f1`;
  echo $name;
  ffmpeg -i $i -sameq -strict experimental -vcodec mpeg4 $name.mov;
done

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%.

APRS iGate über HAMnet mit pymultimonaprs

Seit kurzem habe ich bei mir im 3. Wiener Gemeindebezirk am Dach meines Wohnhauses (ca. 8. Stock) – unter anderem – folgendes Equipment installiert:

IMG_4834Der 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.

Voraussetzung

Als Voraussetzung sollte die RTL-SDR-Software und Treiber am Raspberry bereits installiert sein. Der Vorgang ist unter anderem hier beschrieben: http://thardes.de/raspberry-pi-als-sdr-server/
(Update 2020: hier ein neuer Link zur Beschreibung: https://www.az-delivery.de/blogs/azdelivery-blog-fur-arduino-und-raspberry-pi/raspberry-headless-setup-rtl-sdr)

Weiters habe ich mittels GSM-Netz den Raspberry kalibriert und so die Ungenauigkeit meines Sticks festgestellt: 26 ppm. (vgl. ua. http://www.rtl-sdr.com/how-to-calibrate-rtl-sdr-using-kalibrate-rtl-on-linux/)

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 erstelle ein Startscript:

sudo cp pymultimonaprs.init /etc/init.d/pymultimonaprs
sudo chmod +x /etc/init.d/pymultimonaprs
sudo update-rc.d pymultimonaprs defaults

Um in das APRS-IS-Netzwerk Pakete zu übertragen, ist ein Passwort erforderlich, das sich aus dem Call ableitet und errechnet werden muss:

cd ~/pymultimonaprs
./keygen.py CALLSIGN
Key for CALLSIGN: 31983

Konfiguration

Nun passe ich die Konfigurationsdatei /etc/pymultimonaprs.json an. Fertig konfiguriert sieht sie so aus:

{
        "callsign": "OE1SCS-10",
        "passcode": "20123",
        "gateway": [
                "aprs.oe2xzr.ampr.at:14580", "44.143.40.90:14580",
                "aprs.oe1.ampr.at:14580", "44.143.10.90:14580",
                "aprs.oe6xrr.at.ampr.org:14580", "44.143.153.50:14580",
                "aprs.oe7xgr.ampr.at:14580", "44.143.168.68:14580",
                "44.225.41.232:14580",
                "44.225.42.181:14580",
                "euro.aprs2.net:14580"],
        "append_callsign": true,
        "source": "rtl",
        "rtl": {
                "freq": 144.800,
                "ppm": 26,
                "gain": 46,
                "offset_tuning": false,
                "device_index": 0
        },
        "alsa": {
                "device": "default"
        },
        "beacon": {
                "lat": 48.19060,
                "lng": 16.38670,
                "table": "/",
                "symbol": "-",
                "comment": "RXonly APRS iGate",
                "status": {
                        "text": "Raspberry Pi mit RTL Stick",
                        "file": false
                },
                "weather": false,
                "send_every": 1800,
                "ambiguity": 1
        }
}

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 gebe die eigenen GPS-Koordinaten an, wähle als Darstellungssymbol ein Haus, gemäß dieser Tabelle:
http://www.aprs-dl.de/?APRS_Detailwissen:SSID%2BSymbole
Ganz unten bei diesem Link kann man die Symboltabelle als PDF runterladen!

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:

aprs-ambiguous
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.

Ein anderer Benutzer hat ähnliches erlebt: “I was unable to scan both 144.39 and 145.825 and decode the packets reliably.” (http://www.algissalys.com/amateur-radio/raspberry-pi-sdr-dongle-aprs-igate)

Wetter- & Telemetriedaten übertragen

(Edit: ich habe in einem separaten Artikel hier mittlerweile die Übertragung von Telemetriedaten beschrieben…)

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": 1366148418,
    "wind": {
        "speed": 10,
        "direction": 240,
        "gust": 200
    },
    "temperature": 18.5,
    "rain": {
        "rainlast1h": 10,
        "rainlast24h": 20,
        "rainmidnight": 15
    },
    "humidity": 20,
    "pressure": 1013.25
}
  • 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

  • den aktuellen UNIX-Timestamp angebe,
  • bei temperature die Ausgabe von “vcgencmd measure_temp”
pi@roofpi ~ $ vcgencmd measure_temp
temp=27.2'C

Damit übertrage ich zwar nicht die Daten des Wetters, sondern die Temperatur der CPU, aber ich kann das zum Testen mal so machen.

Es würde sich auch anbieten, andere Telemetriedaten mitzusenden, wie zB. die Spannungen der Elemente des Raspberry:

pi@roofpi ~ $ vcgencmd measure_volts core
volt=1.2000V
pi@roofpi ~ $ vcgencmd measure_volts sdram_c
volt=1.2000V
pi@roofpi ~ $ vcgencmd measure_volts sdram_i
volt=1.2000V
pi@roofpi ~ $ vcgencmd measure_volts sdram_p
volt=1.2250V

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:

"status": {
 "text": false,
 "file": "/tmp/aprs-status.txt"
 },

In die Datei /tmp/aprs-status.txt schreibt man nun eine Zeile, die man als Status aussenden will, beispielsweise:

Raspberry Pi mit RTL Stick core_temp=27.2'C core_volt=1.2000V sdram_c_volt=1.2000V sdram_i_volt=1.2000V sdram_p_volt=1.2250V

Ideen für weitere Werte, die man aussenden könnte:

  • uptime
  • clock-speeds von core, arm und anderen Modulen im Raspberry
  • uvm…

Ich habe mittlerweile die Übertragung der Telemetriedaten in einem eigenen Artikel beschrieben.


	

Let’s encrypt: Zertifikat automatisch erneuern

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.

Testlauf

Zuerst muss ich das Kommando testen:

./letsencrypt-auto -c /etc/letsencrypt/cli.ini -d stefan.schultheis.at

Es funktioniert:

letsencrypt-headless

Cronjob

Um den Job am 20. des Monats um 6:10 auszuführen, habe ich als User root in der Datei /etc/crontab folgenden Eintrag erstellt:

$ sudo vi /etc/crontab

10 6   20 * *   root    /home/stefan/letsencrypt/letsencrypt-auto -c /etc/letsencrypt/cli.ini -d stefan.schultheis.at

Der Cron-Daemon muss die Änderung noch neu laden:

$ sudo service cron reload

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.

Let’s encrypt: Apache Webserver mit SSL-Zertifikat von letsencrypt für WordPress unter Ubuntu Linux

Kurze Einführung

SSL-Zertifikate für Webserver nach dem Standard X.509 haben – kurz gesagt – zwei Aufgaben:

  1. 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.
  2. 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.

Hinter Let’s Encrypt stehen namhafte Firmen und Organisationen wie Mozilla, Akamai, Cisco, EFF, Facebook, ISC uvm.

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:

apt-get update ; apt-get install git

Auf https://letsencrypt.org/howitworks/ werden die Schritte gut beschrieben, ich lade also zuerst den Client runter:

git clone https://github.com/letsencrypt/letsencrypt

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:

letsenc01

Nach der Bestätigung, werde ich nach meiner Email-Adresse gefragt:

letsenc02

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.

letsenc03-problem-email

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:

letsenc04

Und schon kommt die Meldung, dass letsencrypt fertig ist:

letenc05

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:

wpeinsthttps

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”:

wppluginhttps-redirection

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:

letsenc-blogzert01

Das Zertifikat ist als 2048 Bit RSA mit SHA-256 und Gültigkeit von 3 Monaten sichtbar:

letsenc-blogzert02

Die Zertifkatskette zeigt “DST Root CA X3” als Stammzertifizierungsstelle, danach die “Let’s Encrypt Authority X1”:

letsenc-blogzert03

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:

qualys

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.

Installation des XenServer 6.5 auf SD-Karte im HP MicroServer Gen8

hpmicroservergen8Fü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.

Fazit

Beider Hypervisor funktionieren einwandfrei und sehr performant auf dem Server. Wer mehr Performance möchte, kann den HP MicroServer Gen8 mittlerweile auch mit Intel Xeon E3-1220LV2 CPU inkl. 8 GB RAM kaufen.

HP MicroServer Gen8 Stromverbrauch

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)
  • geringer Stromverbrauch
  • einfach zu managen
  • vernünftiger Preis

hpmicroservergen8Mit diesen Anforderungen wurde mir von einem Freund der HP MicroServer Gen8 empfohlen. Das Gerät kostet aktuel zirka 210,- Euro und ist ein “echter” kleiner Server. ILO 4 (https://de.wikipedia.org/wiki/Integrated_Lights-Out) inklusive.

Wunderbare Sache! Ich habe den Server bestellt und noch um folgende Module erweitert:

  • ILO 4 Advanced Lizenz um € 18,12. (hier gekauft)
  • Kingston KVR1333D3E9S/8G Arbeitsspeicher 8GB (DDR3 ECC CL9 DIMM, 240-pin), um € 68,03 (hier gekauft)
  • 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:

  1. beim Starten: 45 Watt
    gen8watt01
  2. unter Last (beim Booten): 31 Watt
    gen8watt02
  3. und im Leerlauf: 27 Watt
    gen8watt03
  4. ausgeschaltet zieht die ILO-Funktion übrigens 5,5 Watt.