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.

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.

dnf und alte Metadaten

Dnf wird demnächst in FC22 den Paketmanager yum ersetzen. Dnf kann man jetzt schon im Parallelbetrieb testen. Dabei fiel mir auf, dass yum und dnf Updates ganz unterschiedlich finden:
Nicht selten hatte yum schon eine ganze Stange Aktualisierungen parat, während dnf noch meinte, alles sei aktuell. Der Grund liegt in den Metadaten, die bei yum öfters aktualisiert bzw schneller als veraltet angesehen werden.
dnf -refresh upgrade umgeht dieses Problem zwar, allerdings werden dann immer wieder die neusten Metadaten der Repos heruntergeladen, was u.U. etwas dauern kann.
Um dnf das Verhalten von yum beizubringen, reicht es das Timeout, wann die Metadaten als veraltet gelten, zu ändern. Bei yum sind die Daten nach 6 Stunden veraltet, bei dnf nach 48 Stunden! (Siehe https://www.mankier.com/8/dnf.conf und http://linux.die.net/man/5/yum.conf, jeweils unter “metadata_expire”)
Mit metadata_expire=21600 unter /etc/dnf/dnf.conf verhält sich dnf wieder genau wie von yum gewohnt.

Fedora und der Realtek RTS5139 Kartenleser…

Fedora bringt standardmäßig keinen Treiber für den Realtek RTS5139 Kartenleser mit, welcher in vielen Laptops verbaut ist.
Die Installation von kmod-staging löst dieses Problem, aber nur bis ein neuer Kernel veröffentlicht wird. Da es mir zu doof war, ein paar Tage ohne Kartenleser da zu stehen, habe ich einen anderen Weg gesucht. Dies führte dazu, dass ich mir den Kernel selbst kompiliere – MIT Treiber. Im Prinzip ist es auch gar nicht schwierig, die Fedora Docs bieten eine ganz gute Anleitung: https://fedoraproject.org/wiki/Building_a_custom_kernel?rd=Docs/CustomKernel

Da ich keine Lust hatte, die Befehle immer wieder manuell einzugeben sind die folgenden Scripte entstanden (die in oben verlinkter Anleitung genannten Tools müssen noch installiert werden):

1_prepare.sh

#!/bin/sh
cd ~
rpmdev-setuptree
yumdownloader --source kernel
rpm -Uvh kernel-*
cd ~/rpmbuild/SPECS
rpmbuild -bp --target=$(uname -m) kernel.spec
cd ~/rpmbuild/BUILD/

2_configure_kernel.sh

#!/bin/sh
#copy to BUILD/kernel-$ver.$subver.$fedver/linux-$ver.$arch/
make oldconfig
make xconfig
cp .config ~/rpmbuild/SOURCES/config-`uname -m`-generic

3_make_kernel.sh

#!/bin/sh
rpmbuild -bb --target=`uname -m` ~/rpmbuild/SPECS/kernel.spec

cleanup.sh

#!/bin/sh
rm -rf BU* S* ~/kernel-*.rpm

Zuerst habe ich in meinem Homeverzeichnis einen Ordner “rpmbuild” erstellt und alle Scripte dort hinein kopiert. Anschließend wird das erste Script ausgeführt. Es lädt den Quellcode des Kernels herunter und entpackt diesen. Danach wir das 2. Script in den Ordner BUILD/kernel-*/linux-*/ kopiert und darin ausgeführt. In dem sich anschließend öffnenden Dialog kann der Kernel konfiguriert werden. Hier sucht man über die Suchfunktion den entsprechenden Treiber, aktiviert das Häkchen und speichert die Konfiguration ab. Dann startet man den Kompiliervorgang mit dem 3. Script. Dies dauert je nach Rechner eine Weile. Ist der Kernel kompiliert finden sich die installierbaren rpms im Ordern RPMS.

Update 18.9.2014: Die neuen Treiber sind jetzt unter rtxs* (siehe https://bbs.archlinux.org/viewtopic.php?pid=1448633) zu finden.

Update 15.12.2014: Wie es scheint sind die Treiber unter Fedora 21 und Kernel 3.17 schon von Haus aus in den Kernel integriert. Zumindest funktionierte der Kartenleser ohne erneute Kompilierung.