FreeBSD 11.1 auf alix2d3

Es laufen nicht mehr viele Linux-Distributionen auf einem ALIX-Board. Entweder sind sie uralt oder aktuelle Versionen kommen nicht mehr mit dem verbauten Prozessor klar. PFsense z.B. hat kürzlich die Unterstützung für x86 nanobsd eingestellt.
FreeBSD 11.1 funktioniert noch – mit ein paar Tricks kann man es auch auf einem ALIX-Board in Betrieb nehmen.
Für die Installation habe ich einen CF-Kartenleser über virsh an eine virtuelle Maschine angeschlossen und dann über das Installationsimage (i386) das System auf die Speicherkarte installiert.
Die CF-Karte wird mit

    <disk type='block' device='disk'>
      <driver name='qemu' type='raw'/>
      <source dev='/dev/sdd'/>
      <target dev='vdb' bus='virtio'/>
    </disk>

in libvrit eingebunden.
Nach erfolreicher Installation müssen noch die Bootparameter an das Board angepasst werden. Die CF-Karte erscheint als /dev/ada0 im System, entsprechende müssen die Einträge in /etc/fstab angepasst werden.
Damit hinterher eine Ausgabe über die Konsole erfolgt wird der Eintrag console=”comconsole” in /boot/loader.conf hinzugefügt.
Anschließend werden in /etc/ttys alle Einträge beginnend mit ttyv deaktiviert und ttyu0 aktiviert. FreeBSD nutzt für die serielle Ausgabe standardmäßig 9600 Baud. Diese Geschwindigkeit kann auch im Bios des Boards aktiviert werden, ist aber für den Betrieb nicht zwingend erforderlich.

J-Pilot und HotSync mit mehreren Geräten

Mit J-Pilot ist es (noch immer) möglich PalmOS-Geräte mit Linux zu synchronisieren. Allerdings unterstützt J-Pilot nur ein Profil. Mit einem Trick kann man aber trotzdem mehrere Geräte synchronisieren. Dazu erstellt man für jedes Gerät einen eigenen Ordner, in welchem J-Pilot später arbeiten soll. Meine Ordnerstruktur kennt die Ordner
/home/jonas/jpilot/treo und
/home/jonas/jpilot/tx
Standardmäßig nutzt J-Pilot den Ordner /home/jonas/.jpilot – dieser wird in diesem Szenario zu einem Symlink:
Für jedes Gerät gibt es ein Startscript, welches den Symlink löscht und anschließend je nach zu synchronisierendem Gerät neu erstellt und auf das jeweilige Verzeichnis zeigen lässt. Das Script um den Treo zu synchronisieren sieht z.B. so aus:


#!/bin/sh
rm /home/jonas/.jpilot
ln -s /home/jonas/jpilot/treo /home/jonas/.jpilot
jpilot

Dadurch bekommt jedes Gerät ein eigenes Arbeitsverzeichnis. Nachteil: Wenn man ein Gerät mit dem falschen Verzeichnis synchronisiert ist Chaos vorprogrammiert. Also immer aufpassen in welchem Kontext man gerade arbeitet.

Treo 650: Von den Toten auferstanden

2004 erschien der Treo 650 in den USA. Seitdem hat sich viel geändert: Palm gibt es nicht mehr, Technologien haben sich weiterentwickelt, mit welchen das Gerät nicht umgehen kann.

So hat z.B. der eingebaute Browser massive Probleme mit aktuellen, per TLS gesicherten Webseiten. Was mit einem aktuellen Smartphone ohne Probleme funktioniert, wirft auf dem Treo viele Fehlermeldungen oder die Webseite kann überhaupt nicht aufgerufen werden. Der Grund dafür sind aktuelle TLS-Implementationen, welche auf PalmOS nicht verfügbar sind. So wurde kürzlich SSLv3 in der Linux-Bibliothek OpenSSL deaktiviert – das Protokoll mit dem der Treo noch klar kommen würde. Weiterhin sind Hash- und Verschlüsselungsalgorithmen mit der Zeit geschwächt oder gebrochen worden, sodass viele Webseiten diese Verfahren über TLS nicht mehr anbieten. Dies betrifft die vom Treo beherrschten Standards SHA-1, MD5, 3DES und RC4. Hinzukommt, dass eine Überprüfung des TLS-Zertifikats nicht mehr durchgeführt werden kann. Mittlerweile sind viele neue Root-CAs entstanden (die dem Treo unbekannt und deshalb abgelehnt werden) bzw es haben sich auch im Zertifikatssystem Technologien verändert. Diese Veränderungen haben zur Folge, dass der Treo 650 zwar ins Internet gelangt, Webseiten aber nur sehr eingeschränkt nutzbar ist.

Beim E-Mail Abruf sieht es nicht viel besser aus. Auch hier machen aktuelle Technologien Schwierigkeiten. Einzig der bewusste Verzicht auf Verschlüsselung kann, wenn der Provider es unterstützt, zum Erfolg führen. Allerdings ist diese “Lösung” stark mit Vorsicht zu genießen, da man so mindestens seinen E-mail Verkehr im Klartext durch das Internet schickt. Die Zugangsdaten müssen nicht zwangsweise unverschlüsselt übertragen werden. Je nach Anbieter und verwendeter Mail-Software kann das CRAM-MD5-Verfahren zur Absicherung des Passwortes genutzt werden. Noch gilt das Verfahren als nicht gebrochen und wird beispielsweise von Snappermail Enterprise unterstützt.

Doch wie kann man dem Treo noch etwas mehr “Internet beibrigen”? Dazu muss auf die vorhandenen Möglichkeiten aufgesetzt und passende Infrastruktur (eigener vServer/Server oder Webspace) vorhanden sein. Am einfachsten ist der Zugriff auf das Internet per Browser. Statt sich direkt mit dem Palm-Browser zu der Webseite zu verbinden, wird ein Web-Proxy (installiert auf einem Webspace oder vServer/Server) wie z.B. Glype zwischengeschaltet. Der Proxy ruft die Webseite ab und leitet sie an den Palm weiter. Der Proxy selbst muss dazu über eine ungesicherte HTTP-Verbindung oder über eine unterstützte TLS-Verbindung vom Palm aus aufgerufen werden. Dabei sollte man beachten, das der Datenverkehr zwischen Palm und Proxy unverschlüsselt erfolgt, d.h. man sollte es tunlichst vermeiden, sensible Daten über diesen Weg auszutauschen.

Der E-Mail-Abruf gestaltet sich deutlich komplizierter und kann nicht so einfach reaktiviert werden, wenn E-Mail-Anbieter wie GMX, GMail, web.de etc genutzt werden. Nur bei einer self-hosted-Lösung ist dies umsetzbar.
Noch bis vor ein paar Monaten konnte ich mit nginx einen E-Mail Proxy betreiben, welcher die von PalmOS bzw. Snappermail beherrschten Protokolle unterstützte. Da diese Verfahren seit dem Update durch OpenSSL global deaktiviert wurden, funktionierte auch diese Lösung nicht mehr. Die aktuelle Lösung basiert auf einem VPN-Tunnel, welcher vom Treo zum Server aufgebaut wird. Hier kommen zwei VPN-Protokolle in Frage: PPTP und IPSec. Für beide Varianten existieren VPN-Clients für PalmOS: Movian VPN für IPSec und Mergic VPN für PPTP. PPTP ist dabei die schwächere Wahl, da das Protokoll als gebrochen gilt. Ich habe mich trotzdem für PPTP entschieden, da die Einrichtung am Server zunächst einfacher und unkomplizierter war und es dann doch nicht ganz trivial ist, die Verbindung anzugreifen was zumindest Script-Kiddies da Leben erschweren sollte. Sollte die VPN-Verbindung gebrochen werden, sind die Zugangsdaten noch immer per CRAM-MD5 gesichert. Vielleicht versuche ich mich demnächst noch an einer IPSec-Verbindung, welche noch als sicher und ungebrochen gilt.
Der Mailabruf im Mail-Client erfolgt dann nicht über die normale Adresse des Mailservers, sondern über die interne IP der VPN-Verbindung. Der Haken an der Sache ist, dass diese Art von VPN-Verbindung von Netzwerkgeräten unterstützt werden muss. Dies ist gerade in Heimnetzen manchmal nicht der Fall. So habe ich es (noch) nicht hinbekommen, einen PPTP-Tunnel durch den Bluetooth-Access-Point blue2net zu tunneln. GRE-Pakete, welche für PPTP essentiell sind, werden nicht durchgeleitet.

Mit diesen zwei Methoden ist der Treo wieder etwas mehr nutzbar geworden und muss nicht in der Ecke verstauben. ;)

Open vSwitch + SDN – aus dumm mach schlau

Verbindet man Open vSwitch mit einem SDN-Controller (z.B. OpenDaylight), ist das Netzwerk ersteinmal tot. Erst mit dem Hinzufügen von Regeln bekommt das Netz wieder in Gang. Für Basiskommunikation benötigt es Regeln, welche ARP- und IP-Traffic berücksichtigen. Dazu müssen folgende Fälle berücksichtigt werden:

  1. ARP-Traffic an die Broadcastdomain
  2. ARP-Traffic an einen bestimmten Host
  3. IP-Traffic an deinen bestimmten Host

Die Regel für den ersten Fall muss alle ARP-Pakete an die Broadcastdomain über alle Interfaces weiterleiten, damit es den Zielhost erreichen kann:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<flow xmlns="urn:opendaylight:flow:inventory">
    <flow-name>arp2broadcast</flow-name>
    <table_id>0</table_id>
    <id>0</id>
    <priority>100</priority>	
    <instructions>
        <instruction>
            <order>0</order>
	     <apply-actions>		
                <action>
                    <order>1</order>
                    <output-action>
                        <output-node-connector>ALL</output-node-connector>
                        <max-length>200</max-length>
                    </output-action>
                </action>    
	     </apply-actions>
        </instruction>
    </instructions>
    <match>
   <ethernet-match>
            <ethernet-type>
                <type>2054</type>
            </ethernet-type>
	   <ethernet-destination>
                <address>ff:ff:ff:ff:ff:ff</address>
            </ethernet-destination>
   </ethernet-match> 
  </match>
</flow>

Für Fall 2 muss die Ethernetzieladresse und der Output-Port angepasst werden. Jeder Host im Netzwerk benötigt einen solchen Eintrag, damit die Pakete entsprechend geroutet werden können:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<flow xmlns="urn:opendaylight:flow:inventory">
    <flow-name>arp2linuxadmin</flow-name>
    <table_id>0</table_id>
    <id>3</id>
    <priority>100</priority>	
    <instructions>
        <instruction>
            <order>0</order>
            <apply-actions>
                <action>
                    <order>1</order>
                    <output-action>
                        <output-node-connector>4</output-node-connector>
                        <max-length>200</max-length>
                    </output-action>
                </action>
            </apply-actions>
        </instruction>
    </instructions>
    <match>
   <ethernet-match>
            <ethernet-type>
                <type>2054</type>
            </ethernet-type>
	   <ethernet-destination>
                <address>52:54:00:34:85:00</address>
	   </ethernet-destination>
   </ethernet-match> 
  </match>
</flow>

Der Rechner mit der MAC-Adresse 52:54:00:34:85:00 ist über Port 4 erreichbar, der Ethernet-Type 2054 matcht ARP-Pakete. In diesem Fall wird das einfachste Szenario, die VMs sind direkt an den Switch angeschlossen, betrachtet. Sind VMs über einen weiteren Switch angeschlossen, muss der Output-Port der Regeln entsprechend angepasst werden.

Um IP-Pakete zu erfassen, wird der Ethernet-Type entsprechend angepasst:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<flow xmlns="urn:opendaylight:flow:inventory">
    <flow-name>linuxadmin</flow-name>
    <table_id>0</table_id>
    <id>102</id>
    <priority>100</priority>
    <instructions>
        <instruction>
            <order>0</order>
            <apply-actions>
            	<action>
		    <order>1</order>
                    <output-action>
                        <output-node-connector>4</output-node-connector>
                        <max-length>200</max-length>
                    </output-action>
                </action>
            </apply-actions>
        </instruction>
    </instructions>
    <match>
   <ethernet-match>
            <ethernet-type>
                <type>2048</type>
            </ethernet-type>
            <ethernet-destination>
                <address>52:54:00:34:85:00</address>
            </ethernet-destination>
   </ethernet-match>
   </match>
</flow>

Damit ist eine Grundkommunikation im Netzwerk hergestellt. Weitere, tiefer greifende Konfigurationsmöglichkeiten – wie das setzen von VLAN-Tags oder filtern von bestimmten Pakettypen – ist möglich: https://wiki.opendaylight.org/view/Editing_OpenDaylight_OpenFlow_Plugin:End_to_End_Flows:Example_Flows

HTTP-BASIC-AUTH nach Umleitung auf HTTPS

Eine HTTP-BASIC-AUTH-Authentifizierung sollte man nicht unverschlüsselt durchs Netz jagen. Doof ist es, wenn die Umleitung per .htaccess erst nach der Authentifizierung greift, da die erste Anfrage über HTTP läuft, von der Authentifizierung abgefangen wird und erst danach umgeleitet wird.
Eine Möglichkeit dies zu umgehen sieht so aus:

SetEnvIf %{SERVER_PORT} ^80$ IS_NON_SSL

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

AuthUserFile /pfad/zur/.htpasswd
AuthName "HTTP-BASIC-AUTH über TLS"
AuthType Basic
require valid-user
Allow from env=IS_NON_SSL

via http://stackoverflow.com/questions/10267102/apache-htaccess-redirect-to-https-before-asking-for-user-authentication

Note to self: selbstsignierte Zertifikate mit OpenSSL

Selbstsignierte Zertifikate mit eigener CA über OpenSSL:

Erstellen des CA-Keys:
openssl genrsa -out ca.key 4096 
openssl req -new -x509 -days 1825 -key ca.key -out ca.crt 

Erstellen und signieren eines CSR:
openssl genrsa -out server.key 4096 
openssl req -new -key server.key -out server.csr 
openssl x509 -req -days 1824 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out server.crt

Fast 14000 km

Noch wenige Tage, dann ist das Rad zwei Jahre alt und hat schon gut 14000 Kilometer auf dem Buckel. Jeden Tag zur Uni, mal hier hin, mal da hin, in den Urlaub (Nordsee, Luxemburg, Belgien, Rhein, Mosel, Elsass…), CMs, CTFs – da kommt gut was zusammen. Nur die Temperaturen halten mich im Moment ab das Rad zu nutzen – im Moment ist das Zweitrad, der Panzer (es fährt sich so), mit Spikebereifung im Einsatz. Trotz der 14000 km sind bis jetzt verhältnismäßig wenig passier. Als letztes ist mir der Schalthebel des Umwerfers kaputt gegangen, die Rückholfeder war gerissen.

1.2.2014 Kauf
28.2.2014 Erstinspektion, 450km
9.7.2014 Wechsel Bremsbeläge vorne+hinten, 2888km
17.7.2014 Wechsel Kette, 3270km
14.2.2014 Wechsel Mäntel, 6087km
8.1.2015 Wechsel kompletter Antrieb (Kassete hinten, Kette, Kurbeln), Wartung Bremsen, 6990km
11.11.2015 Wechsel Bremsbeläge vorne und hinten, 12777km
5.12.2015 Wechsel Schaltzug Umwerfer, 12095km
7.1.2016 Wechsel Schalthebel Umwerfer, 13685km

Als nächstes steht die Kette auf dem Plan, mittlerweile macht die Lehre Anstalten in die Zwischenräume zu rutschen.
Mal gucken, wie lange das Rad insgesamt durchhält. Mein Ziel sind mindestens 42000 km, bis dahin dauert es noch etwas :-)

Wenn der Drucker Mist ausspuckt…

Plötzlich meinte der Drucker statt des normalen Dokuments wahllos irgendwelche ASCII-Zeichen drucken zu müssen. Der Grund war, dass der Rechner plötzlich die Druckdaten komprimiert an den Drucker schickte. Die Lösung war, die Kompression mit ‘?compression=none’ in der URI abzuschalten.

via https://bbs.archlinux.org/viewtopic.php?pid=1407886#p1407886

Mausbeschleunigung über die Konsole einstellen

Manchmal ist es ganz praktisch, Dinge über die Konsole einzustellen – ich suchte letztens eine Möglichkeit die Mausbeschleunigung zu beeinflussen.
Script am Beispiel des Logitech Trackman Wheel:

#!/bin/sh
id=`xinput | grep "Logitech Trackball" | awk '{ print $5 }' | cut -f2 -d"="`
echo "Found Trackball at ID" $id
field=`xinput list-props $id | grep "Accel Speed (" | awk '{ print $4 }' | cut -f2 -d"(" | cut -f1 -d")"`
echo "Field is" $field
xinput set-prop $id $field 1

So muss man keine statischen IDs ins Script einbauen, das Script findet die benötigten Felder selbst.

Let’s encrypt!

Seit einiger Zeit bietet “Let’s encrypt” seine SSL-Zertifikate in einer geschlossenen Beta-Phase an.
Die CA möchte schnell und einfach Zertifikate für jeden anbieten. Dies geschieht über ein Tool, welches über die Shell ausgeführt wird. Es kümmert sich um die Erstellung des Private-Keys, des CSR, die Validierung der Domain und die Erzeugung des Zertifikates.
“Let’s encrypt” wird direkt aus den GIT-Repos heruntergeladen und ausgeführt. Dabei werden z.T. noch benötigte Pakete nachinstalliert.
Zertifikate werden anschließend über
systemctl stop httpd
cd letsencrypt
./letsencrypt-auto --agree-dev-preview --rsa-key-size 4096 --server https://acme-v01.api.letsencrypt
.org/directory certonly
systemctl start httpd

angefragt. Dabei wird über Port 80 des Servers kommuniziert, was ich etwas unschön finde, da man vorher einen laufenden Webserver beenden muss.
Die Zertifikate sind nur 90 Tage lang gültig, danach müssen sie erneuert werden. Dies kann automatisch über einen Cronjob geschehen, ein weiteres Eingreifen durch den Benutzer ist nicht mehr nötig.
./letsencrypt-auto --agree-dev-preview --renew-by-default --server https://acme-
v01.api.letsencrypt.org/directory -d johnassel.de -d www.johnassel.de certonly
erneuert schon vorhandene Zertifikate. Auch hier muss ein laufender Webserver für den Vorgang beendet werden.
Leider kann man “Let’s encrypt” nicht schon vorhandene CSRs signieren lassen. Diese Schritte übernimmt die Software. Mir wäre es lieber, wenn ich Key und CSR selbst generieren könnte, einen Einfluss kann man aktuell auf die Länge des Schlüssels wohl noch nicht haben.
Auch bietet “Let’s encrypt” die Möglichkeit, direkt die Konfiguration von Apache etc für die generierten Schlüssel und Zertifikate anzupassen. Irgendwie habe ich dabei Bauchschmerzen, wenn eine Software versucht meine Konfiguration anzupassen.
Mit entsprechenden Scripten sollte es aber kein Problem sein, den Vorgang der Zertifikaterstellung so zu scripten, dass “Let’s encrypt” nicht noch in der Konfiguration rumwurschteln muss.