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
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%.
Nun möchte ich in der Status-Zeile ein paar Telemetriedaten übermitteln, die vom Raspberry ausgelesen werden. Konkret sind das:
Core Temperatur
Core Spannung
Core Spannung der SDRAM_p
Clock Speeds von Core und ARM
Dazu habe ich ein Script erstellt, das alle 5 Minuten über cron gestartet wird und die vollständige Status-Zeile in der Datei /tmp/aprs-telemetrie.txt hinterlegt. pymultimonaprs versendet dann den Inhalt dieser Datei als Statusmeldung.
Dieses Script (abgelegt als /home/pi/aprs-telemetrie.sh) liest die Werte aus und erstellt die Datei:
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:
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.
Da ich über Funkfeuer ja auch IPv6 nutzen kann, möchte ich das nun in meinem LAN einrichten und offizielle IPv6-Adressen (ohne NAT) den Endgeräten zuweisen.
Die IPv6-Adressen an den Interfaces lassen sich ja problemlos über das Webinterface konfigurieren. Aber es gibt im Webinterface keine Möglichkeit zu stateless oder stateful IPv6-Adressvergabe (zB. über DHCPv6 oder radvd). Dazu muss man kurz über SSH einloggen und die Kommandos textbasiert eingeben.
Routing ist ja praktischerweise aufgedreht. Dass alles funktioniert, habe ich getestet, indem ich meinem PC eine IPv6-Adresse aus meinem LAN-Bereich statisch vergeben habe. Zugriff auf Webseiten über IPv6 hat sofort klaglos funktioniert.
Also habe ich mit diesen zwei Zeilen rasch radvd auf dem LAN-Interface (bei mir eth1) aktiviert:
configure
set interfaces ethernet eth1 ipv6 router-advert prefix ::/64
set interfaces ethernet eth1 ipv6 router-advert radvd-options "RDNSS 2001:4860:4860::8888 {};"
commit
save
…und schon bekommen Geräte (teilw. sogar ohne neu verbinden zu müssen) IPv6-Adressen vergeben und nutzen IPv6!
Testen kann man das schnell über einen Aufruf auf http://ip6.me – dort wird die IPv6-Adresse angezeigt, falls man über IPv6 hinsurft. Falls eine IPv4-Adresse aufscheint, funktioniert etwas mit dem IPv6 noch nicht und das Endgerät ist selbstständig zu IPv4 zurückgekehrt.
Mit dem Thema IPv6 Firewall sollte man sich noch auseinander setzen, falls man nicht möchte, dass intern plötzlich alles über öffentliche IPv6-Adressen erreichbar ist…
Einen Vorschlag dazu gibt es zB. hier: https://community.ubnt.com/t5/EdgeMAX/1-6-DHCPv6-PD-with-RDNSS-on-Telenet-in-Belgium/td-p/1100485 Dieses Beispiel hat bei mir einwandfrei funktioniert, um eingehende Verbindungen abzulehnen:
configure
set firewall ipv6-name WANv6_IN default-action drop
set firewall ipv6-name WANv6_IN description 'WAN inbound traffic forwarded to LAN'
set firewall ipv6-name WANv6_IN enable-default-log
set firewall ipv6-name WANv6_IN rule 10 action accept
set firewall ipv6-name WANv6_IN rule 10 description 'Allow established/related sessions'
set firewall ipv6-name WANv6_IN rule 10 state established enable
set firewall ipv6-name WANv6_IN rule 10 state related enable
set firewall ipv6-name WANv6_IN rule 20 action drop
set firewall ipv6-name WANv6_IN rule 20 description 'Drop invalid state'
set firewall ipv6-name WANv6_IN rule 20 state invalid enable
set firewall ipv6-name WANv6_IN rule 30 action accept
set firewall ipv6-name WANv6_IN rule 30 description 'Allow IPv6 icmp'
set firewall ipv6-name WANv6_IN rule 30 protocol ipv6-icmp
set firewall ipv6-name WANv6_LOCAL default-action drop
set firewall ipv6-name WANv6_LOCAL description 'WAN inbound traffic to the router'
set firewall ipv6-name WANv6_LOCAL enable-default-log
set firewall ipv6-name WANv6_LOCAL rule 10 action accept
set firewall ipv6-name WANv6_LOCAL rule 10 description 'Allow established/related sessions'
set firewall ipv6-name WANv6_LOCAL rule 10 state established enable
set firewall ipv6-name WANv6_LOCAL rule 10 state related enable
set firewall ipv6-name WANv6_LOCAL rule 20 action drop
set firewall ipv6-name WANv6_LOCAL rule 20 description 'Drop invalid state'
set firewall ipv6-name WANv6_LOCAL rule 20 state invalid enable
set firewall ipv6-name WANv6_LOCAL rule 30 action accept
set firewall ipv6-name WANv6_LOCAL rule 30 description 'Allow IPv6 icmp'
set firewall ipv6-name WANv6_LOCAL rule 30 protocol ipv6-icmp
set firewall ipv6-name WANv6_LOCAL rule 40 action accept
set firewall ipv6-name WANv6_LOCAL rule 40 description 'allow dhcpv6'
set firewall ipv6-name WANv6_LOCAL rule 40 destination port 546
set firewall ipv6-name WANv6_LOCAL rule 40 protocol udp
set firewall ipv6-name WANv6_LOCAL rule 40 source port 547
commit
save
Danach gehören die Einstellungen noch auf die Interfaces gebunden:
configure
set interfaces ethernet eth0 firewall in ipv6-name WANv6_IN
set interfaces ethernet eth0 firewall local ipv6-name WANv6_LOCAL
commit
save
Ein Test aus dem Internet (zB. Portscan vor dem Setzen der Regeln in Vergleich zu nachher) hat ergeben, dass die Ports nun von außen nicht angesprochen werden können.
Jetzt kann ich dank fhem und des Edimax 2101W den Stromverbrauch meiner Haushaltsgeräte messen. Und begonnen habe ich, wie ihr wisst, mit der Nespresso Kaffemaschine:
Die obere Grafik zeigt jeweils den Monatsverbrauch in kWh. Die untere Grafik zeigt den jeweils aktuellen Stromverbrauch in Watt. Die Granularität ist 30 Sekunden.
Hier eine detailliertere Ansicht (gezoomt):
Was können wir aus diesen zwei Grafiken ableiten:
das Aufheizen der Maschine benötigt weniger als 1 Minute und „zieht“ 1100-1200 Watt
für das Halten der Temperatur benötigt die Maschine immer wieder bis zu 400 Watt
wenn ich mir einen Kaffee mache, zeigt der Edimax 2101W kurz 45 Watt an, ich vermute hier die Pumpe, etc
Daraus ergibt sich in kWh:
für’s Aufheizen verbraucht die Maschine etwa 0,003-0,005 kWh (= 3-5 Wh)
inkl. Aufheizen und einer Stunde Betrieb verbraucht die Maschine zirka 0,016 kWh (16 Wh)
für jede weitere Stunde verbraucht die Maschine 0,0091 kWh (= 9,1 Wh
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.
