Die Situation

Funfact vor weg: Notebooksbilliger.de hat zum CD-laufwerklosen Laptop eine Treiber-CD mitgeliefert. Der Sinn ergibt sich mir bis jetzt nicht. Zudem war auf dem „betriebssystemlosen“ Laptop ein Linpus-Linux (Chinalinux) vorinstalliert.

Nichtsdestotrotz war das Ziel ein Windows auf diesem Laptop zu installieren. Der Versuch eine Windows-ISO auf einem USB-Stick bootbar zu machen klappte zunächst, jedoch meldete die Installationsroutine der USB-Stick könne nicht gefunden werden.

Der Workaround

Da es schon spät abends war, hatte ich auch keine Lust mehrere solcher Windows-USB-Sticks zu erstellen. Eine alternative Lösung musste her.

Da erinnerte ich mich an den Google-CTF, in dem man mit dem NBD-Protokoll arbeiten musste.

Folgende Idee kam mir dabei in den Kopf:

• Auf beiden Laptops Linux starten
• Festplatte über NBD freigeben und einhängen
• Mit VirtualBox Windows auf die freigegebene Festplatte installieren

Das hört sich kompliziert an, hatte am Ende aber einige Vorteile, da Windows 7 leider keine passenden USB- bzw. Netzwerktreiber für den Laptop mitbrachte:

• USB-Zugriff über VirtualBox
• Netzwerk-Zugriff über VirtualBox
• CD-Zugriff über VirtualBox

Die Umsetzung

Zunächst bootet man auf zwei Rechnern Linux. In meinem Fall habe ich für den neuen Laptop (A) ein Archlinux-Livesystem genutzt, da auf meinem Laptop (B) bereits Archlinux läuft. Andere Distributionen sollten für dieses Vorhaben auch nutzbar sein, allerdings muss wahrscheinlich ein andersnamiges Paket installiert werden.

Der erste Schritt besteht darin, auf beiden Laptops NBD zu installieren. Unter Archlinux heißt das Paket „nbd“.

sudo pacman -S nbd

Als nächstes baut man ein Netzwerk zwischen beiden Rechnern auf. Dazu habe ich diese mit einem LAN-Kabel direkt verbunden. Es ist aber auch möglich einen Router und automatische IP-Konfiguration (DHCP) zu nutzen.

Auf Laptop B:

sudo ip a a 192.168.50.1/16 dev enp2s0f0

wobei „enp2s0f0“ euer Netzwerkinterface ist.

Auf Laptop A:

sudo ip a a 192.168.50.2/24 dev enp2s0
sudo ip r a 192.168.50.0/24 via 192.168.50.1 dev enp2s0

Danach sollten beide Geräte sich pingen können.

Als nächstes gibt man in diesem Netzwerk die Festplatte von A frei:

nbd-server -d -C /dev/null 1337 /dev/sda

Parameter:

• -d : Debugmodus, Prozess geht nicht in den Hintergrund
• -C /dev/null: Keine Konfigurationsdatei laden
• 1337: Port, auf dem die Freigabe läuft
• /dev/sda: Festplatte, die freigegeben werden soll

Auf B bindet man das Gerät entsprechend ein:

nbd-client -nofork 192.168.50.2 1337 /dev/nbd0

Parameter:

• -nofork: Nicht in den Hintergrund gehen
• 192.168.50.2: IP von A
• 1337: Port auf dem A die Freigabe hat
• /dev/nbd0: 1. Freigabe von A.

Als nächstes braucht man ein wenig VirtualBox-Magic, um VirtualBox die Netzwerkfreigabe als eigenständige Festplatte vorzugaukeln:

VBoxManage internalcommands createrawvmdk -filename /tmp/laptop-windows.vmdk -rawdisk /dev/nbd0 

Parameter:

• -filename: Pfad zur neuen vmdk-Datei („Symlink“)
• -rawdisk: Pfad zur echten Festplatte, nämlich der Netzwerkfreigabe, also der Festplatte auf A

Nun kann man in VirtualBox eine neue virtuelle Maschine anlegen. Dabei gibt man als „vorhandene Festplatte“ den Pfad „/tmp/laptop-window.vmdk“ an. Alle Änderungen die man in der virtuellen Maschine vornimmt, werden dann über das Netzwerk auf die Festplatte von Laptop A geschrieben.

Problem gelöst und Windows endlich installiert :)

~ Sebastian

Irgendwo auf Twitter oder einem anderen Medium habe ich ein Link zu dem Blogpost „[Tutorial] DS18S20 Temperatur Sensor an einem Raspberry Pi“ gefunden. Das hat mich so sehr fasziniert, dass ich das nachbauen wollte.

Dazu bestellte ich mir auf Amazon zunächst 10 solcher Sensoren mit entsprechend langem Kabel und Abdichtung: 10 x DS18B20 Digitale Temperaturfühler für ~15€. Dazu kamen noch ein paar 4.7k Ohm Widerstände. Nach ein paar Tagen war alles in meinem Briefkasten. Angeblich kann man sich von Maximintegrated ein kostenloses Sample zuschicken lassen. Allerdings kam bei mir bisher nichts an, vielleicht auch einfach Pech oder ein Fehler auf meiner Seite.

Aufbau

Für die Verkabelung des Sensors mit dem RaspberryPi bin ich den Schritten in dem oben genannten Blogpost gefolgt. Für mehr Informationen möchte ich dorthin verweisen.

Quelle: https://kopfkino.irosaurus.com/tutorial-ds18s20-temperatur-sensor-an-einem-raspberry-pi/

Wichtig ist scheinbar nur, dass man den GPIO-Pin 4 nutzt. Ich habe es selbst nicht mit anderen GPIO-Pins probiert. Wenn es bei euch mit anderen klappt, bitte einen kurzen Kommentar hinterlassen.

Konfiguration

Ich habe auf meinem RaspberryPi Archlinux mit einem halbwegs aktuellen Kernel am Laufen. Das führte dazu, dass die weiteren Schritte in dem oben genannten Blogpost nicht funktionierten. Nachdem ich ein wenig recherchiert habe, kam ich zu einer klein wenig modifizierten Lösung.

Zunächst muss man in die /boot/config.txt folgende Zeile anhängen:

dtoverlay=w1-gpio,gpiopin=4,pullup=on

Danach muss man noch Kernelmodule laden. Dies erledigt man am Besten direkt beim Booten, in dem man folgendes in die Datei /etc/modules einträgt:

w1-gpio pullup=1
w1_therm

Nach einem Neustart sollte der Sensor unter  „/sys/bus/w1/devices/<sensor-id>“ verfügbar sein. Mit folgendem Einzeiler kriegt man die aktuelle Temperatur heraus:

$> cat /sys/bus/w1/devices/28-041621eb50ff/w1_slave | grep -oP "t=(\d+)" | sed -e "s/t=//g"
21687

Automatisierung & Webseite

Ich wollte mir eine kleine grafische Ansicht über den Temperaturverlauf bauen. Dazu entschied ich mich, die Daten von zwei Sensoren (1x Indoor, 1x Outdoor) alle 30 Sekunden auszulesen und in eine SQLite3-Datenbank zu schreiben.

Dazu habe ich zwei Scripte unter „/opt/thermo/“ zu liegen. Das Erste kümmert sich nur um das Auslesen der Daten und heißt „data.sh“:

#!/bin/bash

outdoor=$(cat /sys/bus/w1/devices/28-041621eb50ff/w1_slave | grep -oP "t=(\d+)" | sed -e "s/t=//g")
indoor=$(cat /sys/bus/w1/devices/28-041621fadbff/w1_slave | grep -oP "t=(\d+)" | sed -e "s/t=//g")
seconds=$(TZ=Europe/Berlin date +"%s")

echo "$seconds,$indoor,$outdoor"

Die IDs müssen natürlich entsprechend angepasst werden.

Das zweite Script „insertdata.sh“ ruft „data.sh“ auf und schreibt die Daten in eine SQLite3-Datenbank.

#!/bin/bash
olddir=$(pwd)
cd /opt/thermo/
sqlite3 thermo.sqlite3 "insert into temperatures VALUES ($(./data.sh));"
cd "$olddir"

Da Archlinux mit Systemd kommt, können wir dessen Timer nutzen, um die Aufgabe alle 30 Sekunden abzufeuern. Dazu legen wir zunächst den Service unter „/etc/systemd/system/thermo.service“ an:

[Unit]
Description=Thermometer data collector

[Service]
Type=oneshot
ExecStart=/bin/bash /opt/thermo/insertdata.sh

Der Timer „/etc/systemd/system/thermo.timer“ führt diesen Service dann periodisch aus:

[Unit]
Description=Thermo data collector timer

[Timer]
Persistent=true
OnUnitActiveSec=30s
OnBootSec=30s

[Install]
WantedBy=timers.target

Diesen muss man mit einem kurzem Kommando aktivieren:

sudo systemctl enable thermo.timer

Zuletzt fehlte nur noch eine kleine Webseite, die die Daten aus der SQLite-Datenbank ausliest und anzeigt. Dazu habe ich einfach Apache + PHP installiert und folgende „index.php“ im DocumentRoot abgelegt.

<html>
<head>
<!-- Latest compiled and minified CSS -->
<link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.6/css/bootstrap.min.css" integrity="sha384-1q8mTJOASx8j1Au+a5WDVnPi2lkFfwwEAa8hDDdjZlpLegxhjVME1fgjWPGmkzs7" crossorigin="anonymous">

<!-- Optional theme -->
<link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.6/css/bootstrap-theme.min.css" integrity="sha384-fLW2N01lMqjakBkx3l/M9EahuwpSfeNvV63J5ezn3uZzapT0u7EYsXMjQV+0En5r" crossorigin="anonymous">

<!-- Latest compiled and minified JavaScript -->
<script src="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.6/js/bootstrap.min.js" integrity="sha384-0mSbJDEHialfmuBBQP6A4Qrprq5OVfW37PRR3j5ELqxss1yVqOtnepnHVP9aJ7xS" crossorigin="anonymous"></script>

<script src="https://cdnjs.cloudflare.com/ajax/libs/Chart.js/2.0.0/Chart.js"></script>
</head>
<body class="container">
<?php
$db = new SQLite3('/opt/thermo/thermo.sqlite3');
$beginOfDay = strtotime("midnight", time());

$current = $db->query('SELECT * FROM temperatures order by timestamp desc limit 1');
$row = $current->fetchArray();

$currentDate = date("H:i:s - d.m.Y", $row['timestamp']);
$currentIndoor = round($row['indoor']/1000,3);
$currentOutdoor = round($row['outdoor']/1000,3);

$minmax = $db->query("SELECT MIN(indoor) as minIndoor, MIN(outdoor) as minOutdoor, MAX(indoor) as maxIndoor, MAX(outdoor) as maxOutdoor FROM temperatures where timestamp >= $beginOfDay order by timestamp desc");
$row = $minmax->fetchArray();

$minIndoor = round($row['minIndoor']/1000,3);
$maxIndoor = round($row['maxIndoor']/1000,3);
$minOutdoor = round($row['minOutdoor']/1000,3);
$maxOutdoor = round($row['maxOutdoor']/1000,3);

echo "<h1>Last measurement: $currentDate</h1>";
echo "<table class='table'><tr><th>Location</th><th>Current °C</th><th>Todays Min °C</th><th>Todays Max °C</th></tr>";
echo "<tr><td>Indoor</td><td>$currentIndoor</td><td>$minIndoor</td><td>$maxIndoor</td>";
echo "<tr><td>Outdoor</td><td>$currentOutdoor</td><td>$minOutdoor</td><td>$maxOutdoor</td>";
echo "</table>";

?>
<canvas id="myChart" width="300" height="100"></canvas>

<?php
$minmax = $db->query("SELECT * FROM temperatures where timestamp >= $beginOfDay order by timestamp asc");
$labels = array();
$indoor = array();
$outdoor = array();
$diff = array();
while($row = $minmax->fetchArray()) {
    $labels[] = date("H:i:s", $row['timestamp']);
    $indoor[] = round($row['indoor']/1000,3);
    $outdoor[] = round($row['outdoor']/1000,3);
    $diff[] = abs(round((abs($row['indoor']) - abs($row['outdoor']))/1000,3));
}
?>

<script>
var data = {
    labels: <?php echo json_encode($labels); ?>,
    datasets: [
        {
            label: "Indoor",
            fill: false,
            lineTension: 0.1,
            backgroundColor: "rgb(209,12,8)",
            borderColor: "rgb(209,12,8)",
            borderCapStyle: 'butt',
            borderDash: [],
            borderDashOffset: 0.0,
            borderJoinStyle: 'miter',
            pointBorderColor: "rgb(209,12,8)",
            pointBackgroundColor: "#fff",
            pointBorderWidth: 1,
            pointHoverRadius: 5,
            pointHoverBackgroundColor: "rgb(209,12,8)",
            pointHoverBorderColor: "rgba(220,220,220,1)",
            pointHoverBorderWidth: 2,
            pointRadius: 1,
            pointHitRadius: 10,
            data: <?php echo json_encode($indoor);?>,
        },
        {
            label: "Outdoor",
            fill: false,
            lineTension: 0.1,
            backgroundColor: "rgb(8,209,8)",
            borderColor: "rgb(8,209,8)",
            borderCapStyle: 'butt',
            borderDash: [],
            borderDashOffset: 0.0,
            borderJoinStyle: 'miter',
            pointBorderColor: "rgb(8,209,8)",
            pointBackgroundColor: "#fff",
            pointBorderWidth: 1,
            pointHoverRadius: 5,
            pointHoverBackgroundColor: "rgb(8,209,8)",
            pointHoverBorderColor: "rgba(220,220,220,1)",
            pointHoverBorderWidth: 2,
            pointRadius: 1,
            pointHitRadius: 10,
            data: <?php echo json_encode($outdoor);?>,
        },
        {
            label: "Difference",
            fill: false,
            lineTension: 0.1,
            backgroundColor: "rgba(75,192,192)",
            borderColor: "rgba(75,192,192)",
            borderCapStyle: 'butt',
            borderDash: [],
            borderDashOffset: 0.0,
            borderJoinStyle: 'miter',
            pointBorderColor: "rgba(75,192,192)",
            pointBackgroundColor: "#fff",
            pointBorderWidth: 1,
            pointHoverRadius: 5,
            pointHoverBackgroundColor: "rgba(75,192,192)",
            pointHoverBorderColor: "rgba(220,220,220,1)",
            pointHoverBorderWidth: 2,
            pointRadius: 1,
            pointHitRadius: 10,
            data: <?php echo json_encode($diff);?>,
        }
    ]
};

var ctx = document.getElementById("myChart");
var myLineChart = new Chart(ctx, {
    type: 'line',
    data: data,
});
</script>
</body>
</html>

~ Sebastian

Ich nutze das Plugin „Vicious“ für den Batteriestatus in Awesome. Eine beispielhafte Implementierung für das Battery-Widget findet man in der README, allerdings bei mir im Textmodus:

batwidget = wibox.widget.textbox()
vicious.register(batwidget, vicious.widgets.bat, "⚡: $2%/$3", 30, "BAT0")

Der 3. Parameter kann netterweise eine Funktion sein, sodass man einfach den Batteriestatus prüfen und entsprechend eine Meldung ausgeben kann:

vicious.register(batwidget, vicious.widgets.bat, function(widget, args) 
 if args[2] <= 15 then
 naughty.notify({
 title="BATTERY!!",
 text="Battery left: "..args[2].."%",
 bg="#ff0000",
 fg="#000",
 timeout=5,
 border_width=5,
 font="Arial 25" 
 })
 end
 return "⚡: "..args[2].."%/".. args[3]
 end, 30, "BAT0")

In meinem Fall wird die Meldung angezeigt, wenn weniger als 15% Akku verbleiben. Das sieht dann so aus (100% nur, da es ein Test ist):

Damit sollten sich die unbemerkten Abschaltungen meines Laptops in Zukunft drastisch reduzieren.

~ Sebastian

Was ist Iodine?

Iodine ist ein IP-over-DNS Tunnel. Das bedeutet, dass man seinen normalen IP-Traffic in viele kleine Stückchen zerhackt und dann über das DNS-Protocol verschickt. Ein Server dient dabei als Proxy. Viele Hotspots blockieren TCP und UDP Traffic, um die Zahlung einer Gebühr zu fordern. Allerdings besteht diese Beschränkung oft nicht für den DNS-Verkehr (Port 53 UDP), sodass Hotspots ‚umgangen‘ werden können. ‚Umgangen‘ ist hier jedoch die falsche Bezeichnung, denn das Relayen des DNS-Traffics könnte genauso deaktiviert bzw. nur für zahlende Kunden konfiguriert werden.

Voraussetzungen

Damit das ganze System korrekt funktioniert, benötigt man folgende Voraussetzungen:

• (virtuellen) Server:
  • Rootrechte
  • Iptables
  • Port 53 udp frei
• Domain-Registrar, bei dem man eigene NS-Einträge setzen kann
• Für Nutzung auf dem Handy:
  • Rootrechte
  • AndIodine
  • Proxydroid
• Für Nutzung auf dem PC:
  • Rootrechte
  • Tsocks

Folgende Annahmen gelten für diesen Blogpost:

• Euer Server hat die IP: 127.0.0.1
• Eure Domain lautet: domain.tld
• Eine Subdomain lautet: iodns.domain.tld
• Die Subdomain zeigt auf den Server: 127.0.0.1
• Iodine-Subdomain ist: iod.domain.tld

Einrichtung des DNS

Damit Iodine funktioniert, muss es einen Nameserver emulieren. Dazu müsst ihr euch bei eurem DNS-Registrar anmelden und dort einige neue Einträge anlegen:

• A-Record: iodns.domain.tld -> 127.0.0.1
• NS-Record: iod.domain.tld -> iodns.domain.tld

Nun werden alle DNS-Anfragen, welche auf iod.domain.tld enden, an den Server geschickt, auf dem wir später Iodine laufen lassen werden.

Einrichtung von Iodine

Man loggt sich auf seinem Server ein und lädt den Iodine-Sourcecode herunter:

curl http://code.kryo.se/iodine/iodine-0.7.0.tar.gz -o /tmp/iodine.tgz

Man entpackt das Archiv:

cd /tmp/
tar xfv iodine.tgz

Zuletzt dann noch kompilieren und installieren:

cd /tmp/iodine-*/
make
sudo make install

Ihr solltet daraufhin zwei Binaries im Ordner ‚/usr/local/sbin/‘ finden:

ls /usr/local/sbin/
iodine iodined

Die Binary mit dem ‚d‘ hinten ist der Daemon, welchen wir auf dem Server laufen lassen werden. Am Besten legt man dazu einen neuen Nutzer an:

sudo useradd -m -s /bin/nologin iodine

Danach führt man folgenden Befehl aus:

sudo /usr/local/sbin/iodined -f -c -u iodine -P geheimesPW 192.168.99.1 iod.domain.tld

Die Parameter erklärt:

• -f: Behält das Programm im Vordergrund. Sollte nach einem Testlauf deaktiviert werden bzw. muss in Kombination mit Daemontools genutzt werden.
• -c: Verhindert das IP-Checking, welches ansonten zu Verbindungsproblemen führen kann.
• -u: Ändert den Nutzer, mit dem der Daemon läuft
• -P: Setzt ein Passwort
• 192.168.99.1 ist das Subnetz für den Tunnel.

Als nächstes muss man noch einige Einstellungen an der Firewall ändern:

• Port 53 UDP muss geöffnet werden, damit Pakete zu Iodine durchkommen
• Port 8080 TCP muss auf dem virtuellen Interface von Iodine (dns0/192.168.99.1) geöffnet werden, um den Socks-Server laufen zu lassen.

Im nächsten Schritt richten wir noch einen simplen Socks-Server ein, welcher auf dem dns0-Interface lauschen wird. Alle Clients werden später ihren Traffic über den Socks-Server tunneln.

An dieser Stelle sei erwähnt, dass man mittels IP-Forwarding den gesamten Traffic über Iodine tunneln lassen könnte, jedoch wollte ich in meinem Anwendungsszenario nur bestimmte Programme über den Tunnel telefonieren lassen.

Wir werden das kleine Tool Ssocks nutzen. Man lädt die Quellen herunter:

curl http://netassist.dl.sourceforge.net/project/ssocks/ssocks-0.0.14.tar.gz -o /tmp/ssocks.tgz

Danach werden diese entpackt und gebaut:

cd /tmp/
tar xfv ssocks.tgz
cd ssocks-*
./configure
make
sudo make install

Man legt wieder einen neuen User an:

sudo useradd -m -s /bin/nologin ssocks

Danach kann man den Socks-Proxy ganz einfach starten:

sudo -u "ssocks" /usr/local/bin/ssocksd -b 192.168.99.1 --port 8080

Nun sollte die Konfiguration des Servers abgeschlossen sein.

Nutzung auf dem Handy

Um Iodine auf dem Handy nutzen zu können, muss dieses gerootet sein. Danach installiert man sich aus dem F-Droid Store die App AndIodine.

In der App legt man ein neues Profil an und setzt folgende Optionen:

• Tunnel Topdomain: iod.domain.tld
• Password: geheimesPw
• Lazy mode: Häkchen
• Raw mode: Häkchen
• Default route: Kein Häkchen

Die restlichen Einstellungen können so gelassen werden. Hilfestellung bekommt man über die Fragezeichen neben den Optionsfeldern.

Dann benötigt man noch eine App aus dem Playstore, nämlich ‚Proxydroid‚. [appbox googleplay org.proxydroid ]

In dieser App legt man folgende Optionen fest:

• Host: 192.168.99.1
• Port: 8080
• Type: SOCKS5
• Global Proxy: Häkchen

Um über Iodine ins Internet zu kommen, wird folgender Algorithmus angewendet:

1. Verbindung zum Hotspot herstellen
2. AndIodine öffnen und eine Verbindung zum Iodine-Server herstellen
3. Proxydroid starten und Proxy aktivieren
4. Fertig

Danach sollte man über den Proxy surfen können.

Nutzung mit dem PC

Zunächst installiert man sich, ähnlich wie oben aufgeführt, Iodine. Danach kann man sich folgendermaßen zum Server verbinden:

/usr/local/sbin/iodine -f 127.0.0.1 iod.domain.tld

Die Parameter erklärt:

• -f: Im Vordergrund bleiben
• 127.0.0.1: IP eures (Name)servers
• iod.domain.tld: Iodine-Subdomain

Danach solltet ihr den Server pingen können:

ping 192.168.99.1

Der letzte Schritt besteht darin, einen kleinen Socks-Proxy zu installieren bzw. ein Tool, welches den Traffic einer Applikation transparent durch unseren Iodine-Socks-Proxy schiebt. Ich nutze dafür ‚tsocks‘. Unter Archlinux gibt es dazu ein Paket:

sudo pacman -S tsocks

Danach kopiert man sich die Beispielkonfiguration nach /etc/:

cp /usr/share/tsocks/tsocks.conf.simple.example /etc/tsocks.conf

Darin ändert man die entsprechenden Einträge folgendermaßen ab:

# We can access 192.168.0.* directly
local = 192.168.99.0/255.255.255.0

# Otherwise we use the server
server = 192.168.99.1
server_port = 8080
server_type = 5

Nun kann man einem Programm einfach ‚tsocks‘ voranstellen. Zum Vergleich:

$> curl ip.gehaxelt.in
91.9.YY.XX
$> tsocks curl ip.gehaxelt.in
87.106.YY.XX

Fertig!

Geschwindigkeit

Je nachdem welche Fragmentsize der DNS-Relay durchlässt, schwankt die Übertragungsgeschwindigkeit enorm. Am Besten ist natürlich der ‚Raw mode‘, denn dann können die Pakete direkt an unseren Nameserver geschickt werden. Zusätzlich fällt ins Gewicht, dass DNS auf UDP basiert und dadurch viele Vorteile gegenüber TCP fehlen. Beispielsweise die Retransmission, wenn ein Paket im Internet verloren geht.

Meine Erfahrungen zeigen, dass die Geschwindigkeit von 1 Megabyte/10 Minuten (13Kbit/s ~ 2KB/s) bis hin zu 600KB/s schwankt. Es ist also weniger zum richtigen Surfen, als zum ‚Notfall‘-Emailabrufen geeignet.

~ Sebastian

in diesem Blogpost möchte ich beschreiben wie man mit Hilfe einer udev-Regel und Systemd eine mit luks verschlüsselte SD-Karte automatisch mounten lassen kann.

Vorwort: SD-Karte verschlüsseln

Damit man die SD-Karte automatisch entschlüsseln lassen kann, bietet es sich an, diese mit einem Keyfile zu verschlüsseln. Dazu erstellt man zunächst ein Keyfile:

sudo dd bs=512 count=4 if=/dev/urandom of=/etc/sdkey iflag=fullblock

Damit nicht jeder diesen Schlüssel lesen kann, verpasst man ihm noch die korrekten Rechte und einen Änderungsschutz:

sudo chmown root:root /etc/sdkey
sudo chmod 500 /etc/sdkey
sudo chattr +i /etc/sdkey

Danach kann man auch schon mit cryptsetup die SD-Karte verschlüsseln:

sudo cryptsetup luksFormat /dev/mmcblk0p1 /etc/sdkey

• /dev/mmcblk0p1 ist die zu verschlüsselnde Partition auf der SD-Karte
• /etc/sdkey ist das Keyfile, dass zur Verschlüsselung genutzt wird

Zuletzt öffnet man die SD-Karte und erstellt ein Dateisystem:

sudo cryptsetup --key-file=/etc/sdkey luksOpen /dev/mmcblk0p1 sdcard
sudo mkfs.ext4 /dev/mapper/sdcard

Fertig.

Automatische Entschlüsselung und Einbindung

Zum automatischen Entschlüsseln und Mounten der SD-Karte müssen wir eine neue udev-Regel und ein passendes Systemd Unitfile schreiben.

Systemd Unitfile

Wir beginnen mit dem Systemd Unitfile, da dieses relativ straight forward ist. Man legt eine neue Datei an: ‚/etc/systemd/system/sdcardencrypt.service‘. Der Inhalt kann so aussehen:

[Unit]
Description=Automount encrypted sdcard

[Service]
Type=oneshot
ExecStart=/usr/bin/cryptsetup --key-file=/etc/sdkey luksOpen /dev/sdcard sdcard
ExecStart=/usr/bin/mount /dev/mapper/sdcard /sdcard

Möchte man in dem Unitfile mehere ‚ExecStart‘-Kommandos ausführen, so ist ‚Type=oneshot‘ zu setzen.

Das erste Kommando ist bereits von oben bekannt und öffnet den luks-Container. Neu ist hier, dass als Device ‚/dev/sdcard‘ statt ‚/dev/mmcblk0p1‘ angegeben wird. Das erklärt sich aber später mit unserer udev-Regel.

Der zweite Befehl mountet den luks-Container in ‚/sdcard‘. Der Mountpoint muss einmalig davor erstellt werden und/oder geändert werden.

Damit Systemd das neue Unitfile korrekt ausführt, müssen wir einen kurzen Reload durchführen:

sudo systemctl daemon-reload

Udev-Regel

Als nächstes machen wir uns an die udev-Regel, welche den Symlink zu ‚/dev/sdcard‘ erstellt und das unser Unitfile aufruft. Dazu erstellen wir eine Datei in ‚/etc/udev/rules.d/‘ mit dem Namen ’10-sdcard.rules‘ und folgendem Inhalt:

ACTION=="add", KERNEL=="mmcblk0p1", SUBSYSTEM=="block", ATTR{size}=="124702720", ATTR{start}=="32768", SYMLINK+="sdcard", ENV{SYSTEMD_WANTS}="sdcardencrypt.service"

Hier passieren mehrere Dinge:

• ACTION: Nur wenn das neue Gerät eingesteckt wird, soll die Regel ausgeführt werden
• KERNEL, SUBSYSTEM, ATTR: Verundete Kriterien; Nur wenn alle matchen, wird die Regel ausgeführt
• SYMLINK: Erzeuge ein Symlink von der gematchten Partition ‚/dev/mmcblk0p1‘ zu ‚/dev/sdcard‘
• ENV: Führe danach das ’sdcardencrypt.service‘ Unitfile aus.

Das einzige, was ihr an der Regel ändern müsst, sind die Werte hinter KERNEL, ATTR{size}, ATTR{start}. Da wir hier von einer SD-Karte reden, wird SUBSYSTEM wahrscheinlich den Wert beibehalten. Alle anderen Werte nutze ich, um meine verschlüsselte SD-Karte (eindeutig) zu identifizieren.

An die entsprechenden Attribute gelangt man die SD-Karte einsteckt und danach das folgende Kommando ausführt:

udevadm info -a -p (udevadm info -q path -n /dev/mmcblk0p1)

Dabei ersetzt man ‚/dev/mmcblk0p1‘ mit der entsprechenden Partition der SD-Karte. Die Ausgabe kann so ähnlich aussehen:

udevadm info -a -p (udevadm info -q path -n /dev/mmcblk0p1)

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

 looking at device '/devices/pci0000:00/0000:00:1c.0/0000:02:00.1/mmc_host/mmc0/mmc0:aaaa/block/mmcblk0/mmcblk0p1':
 KERNEL=="mmcblk0p1"
 SUBSYSTEM=="block"
 DRIVER==""
 ATTR{alignment_offset}=="0"
 ATTR{discard_alignment}=="8388608"
 ATTR{inflight}==" 0 0"
 ATTR{partition}=="1"
 ATTR{ro}=="0"
 ATTR{size}=="124702720"
 ATTR{start}=="32768"
 ATTR{stat}==" 38 0 1099 136 0 0 0 0 0 56 136"

 looking at parent device '/devices/pci0000:00/0000:00:1c.0/0000:02:00.1/mmc_host/mmc0/mmc0:aaaa/block/mmcblk0':
 KERNELS=="mmcblk0"
 SUBSYSTEMS=="block"
 DRIVERS==""
 ATTRS{alignment_offset}=="0"
 ATTRS{capability}=="10"
 ATTRS{discard_alignment}=="0"
 ATTRS{ext_range}=="8"
 ATTRS{force_ro}=="0"
 ATTRS{inflight}==" 0 0"
 ATTRS{range}=="8"
 ATTRS{removable}=="0"
 ATTRS{ro}=="0"
 ATTRS{size}=="124735488"
 ATTRS{stat}==" 52 0 2155 206 0 0 0 0 0 96 206"

 looking at parent device '/devices/pci0000:00/0000:00:1c.0/0000:02:00.1/mmc_host/mmc0/mmc0:aaaa':
 KERNELS=="mmc0:aaaa"
 SUBSYSTEMS=="mmc"
 DRIVERS=="mmcblk"
 ATTRS{cid}=="035344534c36344780295762d200f800"
 ATTRS{csd}=="400e00325b590001dbd37f800a404000"
 ATTRS{date}=="08/2015"
 ATTRS{erase_size}=="512"
 ATTRS{fwrev}=="0x0"
 ATTRS{hwrev}=="0x8"
 ATTRS{manfid}=="0x000003"
 ATTRS{name}=="SL64G"
 ATTRS{oemid}=="0x5344"
 ATTRS{preferred_erase_size}=="25165824"
 ATTRS{scr}=="0245800300000000"
 ATTRS{serial}=="0x295762d2"
 ATTRS{type}=="SD"

 looking at parent device '/devices/pci0000:00/0000:00:1c.0/0000:02:00.1/mmc_host/mmc0':
 KERNELS=="mmc0"
 SUBSYSTEMS=="mmc_host"
 DRIVERS==""

 looking at parent device '/devices/pci0000:00/0000:00:1c.0/0000:02:00.1':
 KERNELS=="0000:02:00.1"
 SUBSYSTEMS=="pci"
 DRIVERS=="sdhci-pci"
 ATTRS{broken_parity_status}=="0"
 ATTRS{class}=="0x080501"
 ATTRS{consistent_dma_mask_bits}=="32"
 ATTRS{d3cold_allowed}=="1"
 ATTRS{device}=="0x16bc"
 ATTRS{dma_mask_bits}=="64"
 ATTRS{driver_override}=="(null)"
 ATTRS{enable}=="1"
 ATTRS{irq}=="17"
 ATTRS{local_cpulist}=="0-3"
 ATTRS{local_cpus}=="0f"
 ATTRS{msi_bus}=="1"
 ATTRS{numa_node}=="-1"
 ATTRS{subsystem_device}=="0x0504"
 ATTRS{subsystem_vendor}=="0x1025"
 ATTRS{vendor}=="0x14e4"

 looking at parent device '/devices/pci0000:00/0000:00:1c.0':
 KERNELS=="0000:00:1c.0"
 SUBSYSTEMS=="pci"
 DRIVERS=="pcieport"
 ATTRS{broken_parity_status}=="0"
 ATTRS{class}=="0x060400"
 ATTRS{consistent_dma_mask_bits}=="32"
 ATTRS{d3cold_allowed}=="0"
 ATTRS{device}=="0x1c10"
 ATTRS{dma_mask_bits}=="32"
 ATTRS{driver_override}=="(null)"
 ATTRS{enable}=="1"
 ATTRS{irq}=="17"
 ATTRS{local_cpulist}=="0-3"
 ATTRS{local_cpus}=="0f"
 ATTRS{msi_bus}=="1"
 ATTRS{numa_node}=="-1"
 ATTRS{subsystem_device}=="0x0504"
 ATTRS{subsystem_vendor}=="0x1025"
 ATTRS{vendor}=="0x8086"

 looking at parent device '/devices/pci0000:00':
 KERNELS=="pci0000:00"
 SUBSYSTEMS==""
 DRIVERS==""

Am Besten nimmt man die Attribute von weiter oben. Es stellt allerdings auch kein Problem dar, wenn man Attribute nutzt, die weiter unten stehen, nur sind diese etwas genereller und könnten gegebenenfalls auf andere SD-Karten matchen. Allerdings darf man nur Attribute von einem ‚Parent‘ des Devices nutzen. Für bessere Robustheit könnte man noch zusätzliche folgende Attribute einführen:

• ATTRS{manfid}==“0x000003″
• ATTRS{name}==“SL64G“
• ATTRS{oemid}==“0x5344″
• ATTRS{serial}==“0x295762d2″
• ATTRS{type}==“SD“

Zuletzte sollte man noch die Regeln neu einlesen. Das klappt einfach mit einem:

sudo udevadm trigger

Fazit

Es braucht nicht viel Bastelei, um eine verschlüsselte SD-Karte automatisch einzubinden. Möglicherweise möchte man sich aber noch Gedanken darüber machen, dass der Mountpoint bzw. Luks-Container geschlossen wird, wenn die SD-Karte ausgehängt wird. Da ich das nicht häufig/wirklich benötige, ist dies dem interessierten Leser überlassen.

~ Sebastian

heute habe ich nach einer Möglichkeit gesucht, herauszufinden, welche Pakete welche Abhängigkeiten haben. Am Ende meiner Recherche wurden mir schöne bunte Graphen erzeugt. Dabei benötigt man dazu eigentlich nur zwei kleine Programme: Pactree und Graphviz.

Pactree

Pactree beschreibt sich selbst als „A simple dependency tree viewer.“ für Arch Linux. Man kann sich zum Beispiel ausgeben lassen, welche Abhängigkeiten das Paket „glibc“ hat:

> pactree glibc
glibc
├─linux-api-headers
├─tzdata
└─filesystem
 └─iana-etc

Die folgenden Switches werden wir gleich verwenden, um aus diesen Informationen schöne Grafiken zu bauen:

-c, --color          colorize output
-g, --graph          generate output for graphviz's dot

Die Abhängigkeiten von Oben ergeben folgende „dot“-Beschreibung:

> pactree -c -g glibc
digraph G { START [color=red, style=filled];
node [style=filled, color=green];
 "START" -> "glibc";
"glibc" -> "linux-api-headers" [color=chocolate4];
"glibc" -> "tzdata" [color=chocolate4];
"glibc" -> "filesystem" [color=chocolate4];
"filesystem" -> "iana-etc" [color=chocolate4];
}

Interessant kann auch die Verwendung des Switches „-r“ sein.

 -r, --reverse        list packages that depend on the named package

Graphviz

Graphviz ist eine kleine Toolsammlung, welche genutzt werden kann, um schöne Graphen zu erzeugen. Zum Beispiel aus dem o.g. Code.

Um die Umwandlung durchzuführen, führt man folgendes Kommando aus:

dot -Tgif deps.graph -o deps.gif

Wobei „deps.graph“ für den Eingabegraphen in dot-Notation und deps.gif für die Ausgabe im GIF-Format steht. Eine Liste mit weiteren Formaten gibt es natürlich auch. Man muss nur entsprechend „-Tgif“ durch „-TFORMAT“ ersetzen.

Die Aufrufe lassen sich natürlich verketten:

pactree -c -g glibc | dot -Tgif -o /tmp/glibc.gif

Das Ergebnis sieht dann so aus:

Oder etwas komplexer, wie z.B. für das „Gimp“-Programm.

~ Sebastian

heute möchte ich ein kleines Tool vorstellen mit dem man direkt aus einem Ordner heraus einen DLNA Server aufsetzen kann. So kann man ohne umständliche Konfiguration oder Indexierung Videos auf den Fernseher streamen.

Ich hatte früher zum Streamen die Software „miniDLNA“ genutzt. Leider musste man bei einem neuen Titel die komplette Datenbank erneut aufbauen. Das war inbesondere auf dem Pi ein zeitaufwendiger und entsprechend langweiliger Prozess.

Zunächst wollte ich die Lösung als kleines Projekt in Python implementieren, jedoch gibt es keine wirklich tollen Bibliotheken für das DLNA-Protokoll.

Zufälligerweise bin ich beim Googlen auf das Programm „DMS“ von anacrolix gestoßen. Dieses erfüllt genau meine Anforderungen:

• Ohne Indexierung direkt aus einem Ordner heraus Daten streamen
• Keine Konfiguration nötig

Unter Arch-Linux kann man sich das von bitwave erstellte, gleichnamige AUR-Package installieren.

yaourt dms

Ansonsten können folgende Befehle zur Installation verwendet werden. Voraussetzung dafür ist, dass man Go installiert hat.

> go get bitbucket.org/anacrolix/dms
> $GOPATH/bin/dms

Um einen bestimmten Pfad bzw. Ordner zu streamen, muss man nur den Parameter „-path“ angeben:

dms -path="/mnt/usbStick"

Dann wird auf Port 1338 ein HTTP Server geöffnet, dessen Nutzen habe ich allerdings noch nicht ganz verstanden. Wichtiger ist dann wohl, dass Port 1900 (UDP) belegt wird.

Man sollte natürlich nicht vergessen, die beiden Ports in der Firewall freizuschalten.

~ Sebastian

Mit den Programmen hostapd, dnsmasq und Arch-Linux lässt sich das ohne größere Schwierigkeiten umsetzen.

Hardware & Betriebssystem

Wie schon angedeutet, handelt es sich um ein Banana Pi. Das Ding ist so ähnlich wie ein Raspberry Pi, nur kommt es mit einer DualCore CPU und 1 GB RAM, sowie einer 1GBit Netzwerkschnitstelle.

Die Wahl des Betriebssystems fiel auf das Arch Linux v2.0 Image. Dieses kann man, wie gewohnt, einfach herunterladen und auf die SD Karte spielen.

Des Weiteren benötigt man noch einen USB-Ethernet Adapter, sowie einen USB-WLAN Adapter. Die folgenden Produkte hatte ich bei mir noch rumliegen und können out-of-the-box genutzt werden.

• LogiLink UA0025C
• TP Link TL-WN722N

Ziel

Wenn wir die folgende Konfiguration annehmen:

• eth0 : Schnittstelle zum Internet (WAN)
• eth1 : Schnittstelle zum LAN
• wlan0 : Schnittstelle zum WLAN

Dann möchten wir folgendes Setup erreichen:

• eth0 bekommt seine IP per DHCP
• eth1 & wlan0 teilen sich das Subnet 192.168.4.0/24
• Die IPs aus dem Subnet werden per DHCP verteilt
• Dem Subnet wird ein DNS Server zur Verfügung gestellt

Um das zu erreichen, werden wir das Setup in drei größere Konfigurationsabschnitte unterteilen:

• Netzwerkschnittstellen konfigurieren (systemd-networkd)
• Iptables konfigurieren
• Dnsmasq & Hostapd konfigurieren

Kernel vs. Systemd

Die Kernelversion des Images ist bisher bei 3.4.x stehen geblieben. Jedoch werden die Systemd Pakete weiter aktualisiert. Ab systemd-216 führt dies zu Problemen beim Laden von Treibern. Systemd erwartet, dass der Kernel diese Funktion übernimmt, jedoch ist diese in dieser älteren Version noch nicht implementiert.

Folgende Fehler können auf dieses Problem hinweisen:

[ 119.592292] usb 1-1.2: ath9k_htc: Firmware htc_9271.fw requested
[ 180.172266] usb 1-1.2: ath9k_htc: Failed to get firmware htc_9271.fw
[ 180.302130] usb 1-1.2: ath9k_htc: USB layer deinitialized

Natürlich sollte die Datei „htc_9271.fw“ in „/lib/firmware“ bzw. „/usr/lib/firmware“ vorhanden sein.

Die Lösung des Problems besteht darin, dass man Updates für folgende drei Pakete zurückhält:

• libsystemd
• systemd
• systemd-sysvcompat

Diese drei Paketenamen trägt man hinter „IgnorePkg=“ in der „/etc/pacman.conf“ ein.

Danach kann man sich von Archlinux-Rollback die drei Pakete in der Version „216-3“ herunterladen und mittels „pacman -U <Paket>“ installieren.

Netzwerkschnittstellen konfigurieren

Der erste Schritt besteht darin dem System mitzuteilen, wie wir unsere Interfaces konfiguriert haben möchten. Ein Interface soll eine dynamische IP haben und die zwei verbleibenden Schnittstellen sollen ein virtuelles Device bilden.

Hierzu stellen wir erstmal sicher, dass die Voraussetzungen gegeben sind, in dem wir „systemd-networkd“ aktivieren und „netctl“ (ggf. andere Netzwerkmanager) deaktivieren.

systemctl enable systemd-networkd
systemctl stop netctl
systemctl disable netctl

Für die dynamischen IP Adressen benötigen wir dann noch das Paket „dhcpcd“ und entsprechend den aktivierten Dienst:

pacman -S dhcpcd
systemctl enable dhcpcd.service
systemctl start dhcpcd.service

Als nächstes wechselt man in das Verzeichnis „/etc/systemd/network/“. Dort legen wir die Datei für unser WAN-Interface an. Die Datei nennt man „eth0.network“.

[Match]
Name=eth0

[Network]
DHCP=yes

Als nächstes ist unser WLAN-Device dran. Dieses bekommt keine IP zugewiesen, da sich hostapd darum kümmern wird. Die Datei „wlan0.network“ enthält folgendes:

[Match]
Name=wlan0

[Network]
DHCP=no

Als nächstes definieren wirin der Datei „br0.netdev“ die virtuelle Netzwerkbrücke:

[NetDev]
Name=br0
Kind=bridge

Dieser weisen wir unser Subnetz zu (br0.network):

[Match]
Name=br0

[Network]
Address=192.168.4.1/24
DHCP=no

Zuletzt wird noch direkt unser LAN-Interface an die virtuelle Netzwerkschnittstelle gebunden (eth1.network):

[Match]
Name=eth1

[Network]
Bridge=br0

Nun sollte die Konfiguration soweit abgeschlossen sein. Das lässt sich so überprüfen:

systemctl restart systemd-networkd #Netzwerk neustarten

Die Ausgabe von „ip a s“ sollte so ähnlich aussehen:

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
 link/ether 02:86:08:82:75:2e brd ff:ff:ff:ff:ff:ff
 inet 192.168.2.208/24 brd 192.168.2.255 scope global eth0

4: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UNKNOWN group default qlen 1000
 link/ether 00:60:6e:42:57:d9 brd ff:ff:ff:ff:ff:ff

5: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br0 state UP group default qlen 1000
 link/ether f8:1a:67:17:66:e5 brd ff:ff:ff:ff:ff:ff

6: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
 link/ether 00:60:6e:42:57:d9 brd ff:ff:ff:ff:ff:ff
 inet 192.168.4.1/24 brd 192.168.4.255 scope global br0

Wie man sieht, hat eth0 automatisch eine IP von meinem Router bekommen. Das virtuelle Interface br0 hat das Subnetz 192.168.4.1/24 zugewiesen bekommen. Eth0 ist bereits ein Teil vom virtuellen Interface.

Iptables konfigurieren

Damit der Traffic nicht unkontrolliert zwischen den Interfaces fließt bzw. das NAT konfiguriert werden kann, müssen die Iptables genutzt werden.

Normalerweise sind diese schon installiert. Ansonsten muss man das gleichnamige Paket nachinstallieren.

Die im Arch Wiki vorgestellte Konfiguration sieht ungefähr so aus:

# Generated by iptables-save v1.4.21 on Sat Feb 28 02:05:21 2015
*nat
:PREROUTING ACCEPT [5:231]
:INPUT ACCEPT [1:61]
:OUTPUT ACCEPT [2:122]
:POSTROUTING ACCEPT [2:122]
-A POSTROUTING -s 192.168.4.0/24 -o eth0 -j MASQUERADE
COMMIT
# Completed on Sat Feb 28 02:05:21 2015
# Generated by iptables-save v1.4.21 on Sat Feb 28 02:05:21 2015
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [55:4554]
:TCP - [0:0]
:UDP - [0:0]
:fw-interfaces - [0:0]
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -p icmp -m icmp --icmp-type 8 -m conntrack --ctstate NEW -j ACCEPT
-A INPUT -p udp -m conntrack --ctstate NEW -j UDP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j TCP
-A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable
-A INPUT -p tcp -j REJECT --reject-with tcp-reset
-A INPUT -j REJECT --reject-with icmp-proto-unreachable
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -j fw-interfaces
-A FORWARD -j REJECT --reject-with icmp-host-unreachable
-A TCP -p tcp -m tcp --dport 22 -j ACCEPT
-A TCP -i br0 -p tcp -m tcp --dport 53 -j ACCEPT
-A TCP -i br0 -p tcp -m tcp --dport 67 -j ACCEPT
-A UDP -i br0 -p udp -m udp --dport 53 -j ACCEPT
-A UDP -i br0 -p udp -m udp --dport 67 -j ACCEPT
-A fw-interfaces -i br0 -j ACCEPT
COMMIT
# Completed on Sat Feb 28 02:05:21 2015

Das speichert man sich in „/etc/iptables/iptables.rules“ und lädt die Regeln neu:

systemctl restart iptables.service
systemctl enable iptables.service

Die Iptables kann man bei diesem Schritt direkt für den Autostart markieren.

Die Regeln sind so aufgebaut, dass in der Input-Chain der Traffic in UDP/TCP unterteilt wird. In diesen Unter-Chains kann man dann Traffic zulassen oder ablehnen. Wir werden später udp/tcp Port 53,67 nutzen, um darüber DHCP/DNS zu verschicken.

Die Forward-Chain „fw-interfaces“ regelt, von welchen Netzwerken Traffic wohin weitergeleitet werden darf. Hier sagen wir ganz grob, dass alles vom br0 weitergeleitet werden darf.

Ansonsten kümmert sich das conntrack-Modul um die Verwaltung der Verbindungen, in dem es die Pakete zu einer „neuen/ähnlichen/verbundenen“ Verbindung zugeordnet wird.

Ganz wichtig ist die POSTROUTING-Regel im oberen Bereich. Diese kümmert sich um das NAT, in dem alle ausgehenden Pakete vom Subnetz 192.168.4.0/24 die IP vom eth0 verpasst bekommen.

Eine relativ gute Übersicht über alle Regeln bekommt man mit:

sudo iptables -L -vn

Zusätzlich muss das IP-Forwarding im System aktiviert werden:

sudo sysctl -w net.ipv4.ip_forward=1

Dnsmasq & Hostapd konfigurieren

Kommen wir nun zum letzten Teil. Zunächst installieren wir die nötigen Pakete:

sudo pacman -S dnsmasq hostapd

Dnsmasq ist ein kleiner DHCP/DNS Server und hostapd ein Tool zum Erstellen von Access Points.

Dnsmasq

Für Dnsmasq editieren wir die Datei „/etc/dnsmasq.conf“ und setzen dort diese Optionen:

interface=br0
dhcp-range=192.168.4.100,192.168.4.200,24h

Für einen erfolgreichen Betrieb reichen die o.g. Einstellungen aus. Allerdings sollte man sich die Konfigurationsdatei durchlesen, um ggf. Sicherheitsvorkehrungen zu treffen oder weitere Features zu aktivieren.

Mit der ersten Zeile wird festgelegt, dass nur Anfragen vom Interface br0 verarbeitet werden. Die zweite Zeile legt den zu vergebenden IP-Bereich bzw. die Leasetime fest.

Danach muss man dnsmasq neustarten und im Autostart verankern:

systemctl enable dnsmasq.service
systemctl restart dnsmasq.service

Hostapd

Auch hier müssen wir eine Konfigurationsdatei bearbeiten. Beispiele und eine ausführliche Dokumentation finden sich diesmal hier: „/usr/share/doc/hostapd/*“

Die Einstellungen landen dann in der „/etc/hostapd/hostapd.conf“. Diese kann zum Beispiel so aussehen:

interface=wlan0
bridge=br0
driver=nl80211
ssid=PiWiFi
channel=1
ignore_broadcast_ssid=0
country_code=DE
ieee80211d=1
hw_mode=g
beacon_int=100
dtim_period=2
macaddr_acl=0
max_num_sta=20
rts_threshold=2347
fragm_threshold=2346
logger_syslog=-1
logger_syslog_level=2
logger_stdout=-1
logger_stdout_level=2
dump_file=/tmp/hostapd.dump
ctrl_interface=/var/run/hostapd
ctrl_interface_group=0
auth_algs=3
wmm_enabled=0
wpa=2
rsn_preauth=1
rsn_preauth_interfaces=wlan0
wpa_key_mgmt=WPA-PSK
rsn_pairwise=CCMP
wpa_group_rekey=600
wpa_ptk_rekey=600
wpa_gmk_rekey=86400
wpa_passphrase=DASPASSWORT!

Wichtig hierbei ist nur, dass der „Interface=wlan0“ und der „Bridge=br0“ Eintrag vorhanden sind.

Zuletzt muss hostapd noch neugestartet und im Autostart verankert werden:

systemctl restart hostapd.service
systemctl enable hostapd.service

Abschließende Worte

Das von uns definierte Ziel ist nun erreicht. Wir haben einen funktionierenden kleinen Router.

Ich hatte noch probiert „traffic shaping“ umzusetzen, jedoch schien das der Treiber bzw. der Kernel nicht zu unterstützen.

~ Sebastian

This leaves a good trace wherever you go. Simply by the fact that the MAC-Address being used every time you do a connection to any wlan. This is often stored, but How long? There are good example where this information is begin havest for money.

Beside, You never know who else listen and might want uses this data. To mitigate this problem I do following: I generate a random mac address for each new connection.

Keep reading here

ich habe vor einigen Tagen erfolgreich meine erste Android App in den alternativen Appstore „F-Droid“ hochgeladen. F-Droid ist ein Appstore, in dem freie Software (FOSS) zur Verfügung gestellt wird.

Personen, die ihre selbstentwickelte FOSS App in den F-Droid-Store hochladen möchten, können sich hier eine Schritt-für-Schritt Anleitung anschauen.

Bevor man die folgenden Schritte befolgt, sollte man sich noch die zwei Artikel zum Einstellen von Apps durchlesen:

• Inclusion Policy
• Inclusion How-To

1. Anmeldung auf Gitlab.com

Das F-Droid Repository, welches die Informationen zu allen Apps enthält, wird auf GitLab.com verwaltet. Das bedeutet, dass ihr euch bei diesem kostenlosen Dienst anmelden müsst.

2. Repository forken

Das Repository „F-Droiddata“ muss geforkt werden. Nach dem Login auf GitLab.com und dem öffnen des Links, solltet ihr auf der rechten Seite im Menu einen Button „Fork“ finden.

Es kann einige Sekunden dauern bis das Repository in eurem Account auftaucht.

3. Repository clonen und konfigurieren

Für die nächsten Schritte müsst ihr das Program „git“ installiert haben. Erstellt ein neues Verzeichnis, in dem ihr eure Apps verwalten möchtet. Zum Beispiel:

mkdir ~/Coding/Android/

Dann klont ihr euer geforktes Repository dorthin.

cd ~/Coding/Android
git clone git@gitlab.com:USERNAME/fdroiddata.git

Wenn der Prozess abgeschlossen ist, wechselt ihr in das Verzeichnis hinein und erstellt einen weiteren Remote-Eintrag, welcher auf das originelle Repository zeigt.

cd ~/fdroiddata
git remote add upstream https://gitlab.com/fdroid/fdroiddata.git

Möchte man später Updates vom originellen (Upstream) Repository in euer eigenes übernehmen, also sein Repository auf den neusten Stand bringen, so genügt der folgende Befehl:

git pull --rebase upstream master

Damit ist die grundlegende Konfiguration des Repositories fertig.

4. App-Daten eintragen

Für jede im F-Droid Store erhältliche App gibt es eine Datei package.id.txt im Ordner „metadata„.

Der erste Schritt ist demnach eine Datei mit dem Namen „package.id“ im Ordner „metadata“ anzulegen. Dabei steht „package.id“ für den Namen des Packages, in dem die App lebt. Ein Beispiel wäre: „com.google.android.diskusage.txt“

Nun gilt es die Datei mit Leben zu füllen. Glücklicherweise gibt es dafür eine Templatedatei „template“, welche man für eine grundlegende Einführung übernehmen kann.

Die Beschreibung meiner App sieht ungefähr so aus:

Categories:Office,Internet
License:MIT
Web Site:http://DOMAIN.TLD
Source Code:https://github.com/USER/PROJECT
Issue Tracker:https://github.com/USER/PROJECT/issues
Bitcoin: BTCADRESSE

Auto Name:APPNAME
Summary:ZUSAMMENFASSUNG
Description:
BESCHREIBUNG
.

Repo Type:git
Repo:https://github.com/USER/PROJECT.git

Build:1.0,1
 commit=v1.0
 target=android-21

Auto Update Mode:Version v%v
Update Check Mode:Tags .*[0-9]$
Current Version:1.0
Current Version Code:1

Wichtig ist, dass die Werte der Optionen direkt hinter dem Doppelpunkt, ohne Leerzeichen dazwischen, stehen.

Die initiale Build-Version muss angegeben werden. Dabei kann auf Tags zurückgegriffen werden, was die automatischen Updates auch vereinfacht.

Der Update-Mechanismus ist in diesem Beispiel so gestaltet, dass der Updater von F-Droid alle Tags, welche „vx.y“ matchen, auscheckt und in den Commits die AndroidManifest.xml ausliest. Die neuste Version ist dann die, mit dem höhsten „versionCode“. Ihr dürft also nicht vergessen bei jedem Update die „versionName“ „versionCode“ Parameter in der AndroidManifest.xml anzupassen.

Für mehr Informationen kann man sich im Handbuch unter http://f-droid.org/manual umschauen.

5. Build lokal testen

Bevor wir unsere App in den F-Droid-Store zum Review geben, sollten wir schauen, ob sich diese mit den Fdroid-Tools lokal bauen lässt.

Dazu müsst ihr euch die Fdroidserver-Tools installieren. Die Schritte in der Readme-Datei:

git clone https://gitlab.com/fdroid/fdroidserver.git 
cd fdroidserver 
virtualenv env/ 
. env/bin/activate 
pip install -e . 
python2 setup.py install

Alternativ gibt es im AUR das Paket „fdroidserver-git„.

Um den Build-Prozess auszuführen benötigen wir ein lokales F-Droid Repository. Dazu erstellt man sich einen weiteren Ordner:

mkdir ~/Coding/Android/fdroid-build

Nachdem man in den Ordner gewechselt ist, führt man „fdroid init“ aus.

cd ~/Coding/Android/fdroid-build
fdroid init

Dabei kann es passieren, dass folgende Meldung auftritt:

No Android SDK found!
You can use ANDROID_HOME to set the path to your SDK, i.e.:
 export ANDROID_HOME=/opt/android-sdk
Enter the path to the Android SDK (/opt/android-sdk) here:

Ich hab fdroid beendet und danach die Umgebungsvariable entsprechend gesetzt (Fish-Syntax):

set -x ANDROID_HOME "/home/gehaxelt/Coding/Android/Sdk"

Führt man den Initialisierungsprozess erneut aus, so sollte folgende Erfolgsmeldung ausgegeben werden:

Built repo based in "/tmp/foo"
with this config:
 Android SDK: /home/gehaxelt/Coding/Android/Sdk
 Android SDK Build Tools: /home/gehaxelt/Coding/Android/Sdk/build-tools/21.1.2
 Android NDK r10d (optional): $ANDROID_NDK
 Keystore for signing key: /home/gehaxelt/.local/share/fdroidserver/keystore.jks

Es fehlen jetzt immer noch einige wichtige Ordner, welche wir mit einem Aufruf erstellen lassen können:

fdroid build --all
Creating log directory
Creating temporary directory
Creating output directory
Creating build directory
No apps to process.

Im nächsten Schritt bietet es sich an einen Symlink unserer „package.id.txt“ aus dem „fdroiddata/metadata/“ in den „fdroid-build/metadata/“ zu erstellen:

ln -s ~/Coding/Android/fdroiddata/metadata/package.id.txt ~/Coding/Android/fdroid-build/metadata/package.id.txt

Nun können wir den Build-Prozess starten:

cd ~/Coding/Android/fdroid-build/
fdroid build -v -t -l --no-tarball package.id

Läuft der Build-Prozess erfolgreich durch,so sollte man noch den Update-Prozess überprüfen:

fdroid checkupdates package.id

Wenn alles erfolgreich verläuft, kann man sich freuen und einen Merge Request stellen. Andernfalls sollte man solange die „package.id.txt“ anpassen, bis es passt.

6. App veröffentlichen

Kommen wir nun zum letzten Schritt. Zunächst müssen wir unsere Änderungen in einem Commit festhalten:

git add metadata/package.id.txt
git commit -m 'Adding package.id'
git push

Danach loggt man sich wieder auf der GitLab.com Webseite ein und müsste unter seinen Aktivitäten den Commit wiederfinden.

Normalerweise steht direkt daneben eine Aufforderung zum Eröffnen eines Merge Requests. Ist das nicht der Fall, so muss man den Buttons auf der rechten Seite selbst betätigen und die Branches korrekt setzen.

In den Merge Request sollte man noch einen kleinen Grund angeben, weshalb die App in den Store aufgenommen werden sollte. Es bietet sich ausßerdem an die Lizenz + ggf. benutzte Bibliotheken/Abhängigkeiten angeben.

Zuletzt muss man noch ein wenig Geduld mitbringen, bis eine Person des F-Droid-Teams sich den Merge Reqeuest anschaut und die App „durchwinkt“ bzw. konstruktives Feedback abgibt.

~ Sebastian