APRS Smartbeaconing bewährt sich bei mir nicht

AP510 mit SmartBeaconing, zu Fuß + mit Straßenbahn unterwegs
AP510 mit SmartBeaconing, zu Fuß + mit Straßenbahn unterwegs

SmartBeaconing ist eine gute Idee: statt per APRS seine Position alle x Sekunden auszusenden und damit das APRS-Netz unnötig zu belasten, wird die Position nur gesendet, sobald es das System “smart” findet: bei Richtungsänderungen, wesentlichen Geschwindigkeitsänderungen, etc.

Das entlastet das Netz hinsichtlich der Anzahl an Meldungen, die direkt oder über Digipeating übertragen werden und erhöht die Wahrscheinlichkeit für andere Benutzer, dass Airtime für deren Aussendung frei ist.

AP510 im Rucksack in der Straßenbahn (Antenne ist hier testweise eine Nagoya NA-771)
AP510 im Rucksack in der Straßenbahn (Antenne ist hier testweise eine Nagoya NA-771)

Ich habe überall SmartBeaconing verwendet. Schließlich bin ich großteils im Stadtgebiet von Wien und in der näheren Umgebung unterwegs und dort ist die Dichte an APRS-Empfängern & -Digipeatern sehr hoch.

AP510 APRS Tracker am Boot auf der Adria bei Kroatien im Juni 2015
AP510 APRS Tracker am Boot auf der Adria bei Kroatien im Juni 2015

Leider hat sich SmartBeaconing für mich nicht bewährt: obwohl ich mit 5 Watt über eine externe Magnetfußantenne (Nagoya UT-106UV) vom Autodach aus sende, werden nur 30-40% meiner Meldungen aufgenommen. Und das reicht nicht, um die Strecke annähernd korrekt abzubilden. Vor allem, wenn eine Richtungsänderung nur alle 1-2 Minuten passiert, hinterlasse ich nur alle 5 Minuten einen Punkt auf der Map bei dieser schlechten Erfolgsquote der Übertragung.

Ich habe daher SmartBeaconing deaktiviert und sende im Moment stur alle 30 Sekunden. Damit bekomme ich ausreichend Übertragungen zusammen, um die Route gut abzubilden. Gleichzeitig ist mir bewusst, dass dadurch das Netz stärker belastet wird. Da ich aber nicht viel mit dem Auto unterwegs bin, denke ich, dass es zumutbar ist

APRS Strecke mit Argent OpenTracker USB ohne SmartBeaconing
APRS Strecke mit Argent OpenTracker USB ohne SmartBeaconin

 

SainSonic AP510

Vor einigen Monaten habe ich mir ein SainSonic AP510 um knapp € 100,- über eBay aus DL gekauft. Ich bin total begeistert! Vielleicht ausnahmsweise mal weniger, weil es etwas Bestimmtes so gut kann. Sondern diesmal weil es so viel kann.

Das Ding wird als “APRS Tracker VHF GPS Bluetooth Thermometer TF Card APRSdroid” angepriesen. Man sieht schon: da steckt viel drinnen.

Ursprünglich dachte ich, ich kaufe einen APRS Tracker. Ich war froh, dass ein leistungsfähiger Akku (angeblich 3.300mAh LiPo) drinnen ist, der auch wirklich 2 Tage hält, und dass ich kein separates Funkgerät brauche (mit komplizierten und herstellerspezifischen Adapterkabeln), sondern ein Transceiver mit 1 Watt (manche behaupten 1,5 Watt) für VHF (2 Meter-Band) mit drinnen ist.

Auspacken & Inbetriebnahme

Ich möchte da ja nicht zu sehr auf andere Blogger verweisen. Aber lest mal, was die alles erlebt haben! Ich kann das großteils auch bestätigen, aber die zentrale Aussage bleibt: auspacken und gleich mal ein Firmware Upgrade machen. Damit erspart ihr euch diese Erfahrungen und mit der Firmware aus Oktober 2014 funktioniert das Gerät bei mir sehr gut.

Meine Erfahrungen habe ich mit der Software vom 8.10.2014 (20141008) gemacht. Generell kann ich den Thread des Herstellers empfehlen. Die Seite ist zwar 95% chinesisch, aber die Downloads sind zu erkennen und selbsterklärend: http://www.y027.com/dvbbs8/dispbbs.asp?boardid=5&Id=829

Falls das Update-Programm nach dem Start alles chinesisch darstellt, habe ich einen einfachen Trick gefunden: im Verzeichnis des Programms gibt es eine Datei “avrubd.ini”. Öffnet diese mit einem Texteditor und sucht im obersten Block “[last]” nach “language” und ändert diese auf “English”:

language=English

Ein paar Dateien werden für den Start der Programme benötigt, zB. mscomm32.ocx oder msstdfmt.dll. Diese Dateien findet ihr im Internet oder auf der Seite eines anderen Bloggers.

In der Version von Oktober 2014 hat sich das Konfigurationsprogramm einwandfrei bedienen lassen.

20150612 - Konfig StefanDie Einstellungen sind weitgehend selbsterklärend. Folgende Punkte möchte ich kurz beschreiben:

  • MIC-E aktiviert die Komrimierung der APRS-Daten. Ich habe damit in OE, S5, HA und 9A keine Probleme gehabt. Die Übertragungsdauer wird durch diese Funktion reduziert.
  • Smart beaconing: das ist ein lobenswertes Feature, mit dem nicht ununterbrochen periodisch Nachrichten gesendet werden, sondern Meldungen erst dann geschickt werden, wenn sich meine Fahrtrichtung ändert.
  • Busy-control: damit hört der AP510 kurz in den Kanal, ob dieser frei ist, bevor die eigene APRS-Aussendung beginnt.

Erfahrungen

AP510 im Rucksack in der Straßenbahn (Antenne ist hier testweise eine Nagoya NA-771)
AP510 im Rucksack in der Straßenbahn (Antenne ist hier testweise eine Nagoya NA-771)

In den nächsten Tagen habe ich das Gerät überall mitgenommen. Zum Testen natürlich.

SainSonic AP510 im Zug mit Antenne Diamond RH951S
SainSonic AP510 im Zug mit Antenne Diamond RH951S

Meine Positionsmeldungen wurden großteils gut übertragen, ich habe allerdings in Gebäuden (auch direkt hinter (vmtl. bedampften) Fenstern) oft keinen GPS Fix bekommen.

 

 

 

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.