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.

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

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.

Youtube mit HTML5 unter FC22 + Firefox

Kürzlich hatte ich Flash von meinem System komplett heruntergeschmissen, um zu sehen ob es nicht auch ohne geht. Mit Youtube gab es allerdings kleine Probleme, so funktionierte die Video-Wiedergabe mit HTML5 nicht sofort, da der H.264 nicht mitgeliefert wurde.
Mit dnf install gstreamer1-libav gstreamer1-vaapi gstreamer1-plugins-{good,good-extras,ugly} und einem Neustart von Firefox wurde die H.264-Unterstützung unter https://www.youtube.com/html5 angezeigt und Videos liefen wieder wie gewohnt.

via http://martin.preisler.me/2014/08/h264-html5-video-in-firefox-on-fedora-20/

OpenStack schnell und einfach auf einem Host installieren

OpenStack auf einem einzigen Host aufzusetzen kann viel Handarbeit bedeuten, muss aber nicht. Über packstack des RDO-Projekts lässt sich OpenStack schnell und einfach installieren und konfigurieren. Zwar bringt Ferdora 22 Packstack von Haus aus mit sich, das Skript scheint aber noch nicht angepasst zu sein. Auf CentOS 7 lief die Installation ohne Probleme durch – nach 30 Minuten war OpenStack installiert und einsatzbereit.

Von den Toten auferstanden – Linux auf einem MacBook 2.1

Durch Zufall bin ich recht günstig an ein MacBook älteren Semesters (2.1, Ende 2006) gekommen. Da die Hardware doch schon etwas betagt ist, laufen aktuelle Versionen von OS X nicht bzw mehr schlecht als recht. Und naja, an OS X bin ich eh nicht interessiert ;-).
Also sollte als Betriebssystem Linux ins Spiel kommen, komplett ohne Dualboot. Das am MacBook verbaute UEFI macht die Sache dabei nicht einfacher.
Es beginnt beim booten des Installationsmediums:
Meine, auf verschiedenste Weisen, erstellten USB-Sticks wurden nicht erkannt. Erst Installations DVDs/CDs wurden erkannt und von ihnen gestartet. Meine erste Distribution, welche ich testete, war Fedora 21 64 Bit. Das Problem kam später, als die Installation fertig und das System sich selbst neu startete. Weil die UEFI-Firmare des MacBook unter 32 Bit läuft, Fedora aber nur 64 Bit Varianten unterstützt, schlägt der Bootvorgang fehl. Die 32 Bit Version startete im Live-System ohne Probleme. Auch die Installation lief ohne Probleme durch. Allerdings hatte ich Anaconda die Festplatte automagisch partitionieren lassen. Dadurch wurde auch die EFI-Partition getötet, welche den Bootloader enthielt. Das Reslutat war ein System, welches nicht mehr booten wollte. Die Lösung war schließlich ein alternativer Bootloader, welcher das System nach OS-Installationen durchsucht und diese auch starten kann. Um rEFInd zu installieren, musste ich die Platte neu partitionieren (GPT, kein MBR) und eine ESP erstellen, auf welcher später der Bootloader landen sollte. Die Partition habe ich an den Anfang der Platte gesetzt (/dev/sda1), 500MB groß, FAT32 mit aktiviertem Boot-Flag. Dies kann man sehr gut mit einem Fedora Live-System erledigen. Auch die anschließende Installation des Bootloaders erfolgte aus dem System:
1. Mounten der ESP nach /boot/efi
2. Ausführen des Installationscripts aus uder rEFInd-Paket
3. Fertig
Wichtig bei der Installation von Linux-Distris ist jetzt, dass /dev/sda1 nicht als Boot-Partition genutzt wird, sondern eine eigene erstellt werden. Bei mir hat es so regelmäßig wieder das System zerschossen.
Danach habe ich mehrer Distributionen ausprobiert ob sie auf dem MacBook überhaupt laufen. Letztendlich bin ich bei Debian 7 hängen geblieben. Die Installation dauerte zwar vergeleichsweise lange, aber im Moment scheint es am stabilsten zu sein. Auch die Performance ist um einiges besser als ich erwartet hatte.