Den Raspberry Pi in einen Airplay Server verwandeln

Selten gab es einen Embedded Computer so günstig wie den Raspberry Pi, also was liegt da näher sich einen solchen für den Heimeinsatz zu besorgen. Wenn man sich anschaut bei welchen Preisen Airplay Boxen anfangen, wird man merken das ein Raspberry Pi mit einem entsprechenden WLAN-Stick und einem Boxensystem immer noch günstiger ist. Airplay-Boxen, welche im Handel erhältlich sind beginnen ab 200 € mit einer nach oben offenen Grenze.

Für einen Raspberry Pi, Airplay Server benötigt man:

  • einen Rapsberry Pi
  • ein Gehäuse für den Pi
  • einen WLAN Stick
  • ein paar Boxen

Im ersten Schritt sollte man sich eine Raspberry Pi Distribution herunterladen, in diesem Fall wird Raspian benutzt. Dazu wird das Image heruntergeladen und entpackt. Anschließend hat man auf dem Rechner eine .img Datei. Diese muss nun auf die SD-Karte geflasht werden. Um herauszufinden, welches Volume geflasht werden muss, kann man sich auf dem Terminal unter Mac OS X mittels „df -h“ anschauen welches Gerät dazukommt. Eine andere Möglichkeit ist es die Karte über den Namen zu identifizieren, welcher bei neuen Karten meist „NO NAME“ oder „Untitled“ sein sollte.

Wenn das passende Gerät identifiziert wurde, sollte die gemountete Partition mittels:

diskutil unmount /dev/disk2s1

wieder freigegeben werden. Nun wechselt man im Terminal in den Ordner, in welchem die Imagedatei liegt und gibt dabei folgendes ein:

sudo dd bs=1m if=raspbian.img of=/dev/rdisk2

Zu beachten ist dabei das aus „disk2s1“ -> „rdisk2“ wird, womit das Gerät direkt angesprochen wird. Theoretisch würde auch „disk2“ funktionieren, allerdings geht die Übertragungsgeschwindigkeit hierbei drastisch in den Keller. Nach dem Flashen der Karte wird das Gerät mittels:

diskutil eject /dev/rdisk2

ausgeworfen. Die Karte kann nun in den ausgeschalteten Pi gelegt werden und dieser mit Strom versorgt werden. Beim ersten Start wird man vom Konfigurationsmenü „raspi-config“ begrüßt. Hier kann man das Tastaturlayout, den SSH Server und andere Dinge einstellen. Wir stellen ein deutsches Tastaturlayout ein und aktivieren den SSH Server. Des Weiteren sollte man das Passwort für den Nutzer Pi ändern und die root Partion auf den gesamten Bereich der SD-Karte ausdehnen. Anschließend kann man den Pi neu starten.

Für das drahtlose Netz wird der WLAN-Stick an den Raspberry Pi angeschlossen. Wenn man dies im laufenden Betrieb macht, kann es passieren, dass der Pi anschließend neu startet. Das ganze sieht etwas nach einer Brownout Detection aus, sprich der Raspberry hat für einen Moment zu wenig Strom und startet neu.

In der Konsole kann man jetzt mittels „ifconfig“ feststellen, ob ein weiteres Netzwerkgerät hinzugekommen ist. Dort sollten die Geräte „eth0“, „lo“ und „wlan0“ auftauchen. Nun geht es an die Konfiguration des WLANs. Dazu wird die „/etc/network/interfaces“ mittels „nano“ aufgerufen:

sudo nano /etc/network/interfaces

Dabei werden einige Änderungen in der Datei vorgenommen. Anschließend sollte die „interfaces“ Datei wie folgt aussehen:

auto lo

iface lo inet loopback
iface eth0 inet dhcp

allow-hotplug wlan0
auto wlan0
iface wlan0 inet dhcp
pre-up wpa_supplicant -B w -D wext -i wlan0 -c /etc/wpa_supplicant/wpa_supplicant.conf
iface default inet dhcp

Nun geht es an die Konfiguration der „/etc/wpa_supplicant/wpa_supplicant.conf“ Datei. Diese sollte nach der Konfiguration in etwa so aussehen:

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1

network={
  ssid="WLAN"
  scan_ssid=1
  proto=RSN
  key_mgmt=WPA-PSK
  pairwise=CCMP
  group=CCMP
  psk="geheim"
}

Im vorliegenden Beispiel wurde ein WPA 2 verschlüsseltes WLAN eingerichtet. Bei einem Neustart sollte das WLAN anschließend verfügbar sein. Ist dies nicht der Fall, so kann der Prozess mittels:

sudo wpa_supplicant -i wlan0 -D wext -c /etc/wpa_supplicant/wpa_supplicant.conf -d

manuell aktiviert werden. Dabei sieht man dann auch entsprechende Fehlermeldungen, welche auf Probleme hinweisen können. Wenn die WLAN-Schnittstelle aktiv ist, kann man auf einem anderen Terminal mittels „iwconfig“ sehen, ob die Schnittstelle funktioniert. Dies ist dann gegeben, wenn die Schnittstelle nicht mehr als „unassociated“ markiert ist.

Der letzte Punkt, der jetzt noch fehlt, ist die Unterstützung für Airplay. Hierfür wird Shairport installiert. Dazu werden im ersten Schritt die notwendigen Bibliotheken installiert, sowie der Quellcode von Shairport und dem SDP Modul auf den Pi geholt:

sudo apt-get install git libao-dev libssl-dev libcrypt-openssl-rsa-perl libio-socket-inet6-perl libwww-perl avahi-utils libmodule-build-perl
git clone git clone https://github.com/njh/perl-net-sdp.git
git clone git://github.com/abrasive/shairport.git

Bevor Shairport kompiliert wird, muss das SDP Modul installiert werden. Dazu wechseln wie in den Ordner und geben dort folgendes ein:

perl Build.PL
sudo ./Build
sudo ./Build test
sudo ./Build install

Danach wechseln wir in den Shairport Ordner und geben dort „make“ ein. Anschließend können wir ganze mittels „perl shairport.pl“ starten und einen ersten Test vornehmen. Nun müssen wir noch dafür sorgen das Shairport beim Start des Pi auch gestartet wird. Außerdem soll der Empfänger noch einen ordentlichen Namen bekommen. Dazu geben wir im Shairport Ordner folgendes ein:

sudo make install
sudo cp shairport.init.sample /etc/init.d/shairport
cd /etc/init.d
sudo chmod a+x shairport
sudo update-rc.d shairport defaults
sudo nano shairport

Nachdem wir die Datei „shairport“ in „nano“ geöffnet haben, ändert wir dort den Namen z.B. in Schlafzimmer oder Wohnzimmer. Damit bekommt der Empfänger einen eindeutigen Namen. Nach einem Neustart oder einem manuellen:

./shairport start

ist der eigene AirPlay Empfänger fertig.

Weitere Informationen gibt es unter:
http://wiki.ubuntuusers.de/WLAN
http://wiki.ubuntuusers.de/WLAN/wpa_supplicant
http://netz10.de/2010/02/13/wlan-wpa2-mit-psk-manuell-konfigurieren/

Firmware des Raspberry Pi updaten

Während das Linux auf einem Raspberry Pi ohne Probleme geupdatet werden kann, sieht dies bei der Firmware etwas anders aus. Hier ist Handarbeit gefragt. Dazu wird im ersten Schritt Git installiert:

sudo apt-get install git

Damit das Update der Firmware nicht in Arbeit ausartet, sollte man „rpi-update“ nutzen, welches unter https://github.com/Hexxeh/rpi-update/ zu finden ist. Mittels:

sudo wget http://goo.gl/1BOfJ -O /usr/bin/rpi-update && sudo chmod +x /usr/bin/rpi-update

wird das ganze auf dem Raspberry Pi installiert. Nun kann das Firmware Update mit:

sudo rpi-update

angestoßen werden. Die Dauer eines Updates beträgt etwa fünf Minuten. Nach dem erfolgreichen Update muss der Raspberry Pi neugestartet werden.

Git auf dem Server

Möchte man auf einem Ubuntusystem einen Git Server aufsetzen, so ist dies relativ schnell erledigt. Zuerst muss dafür „git“ mittels:

apt-get install git

installiert werden. Danach wird der passende Nutzer für die Git Repositories angelegt:

adduser git

Nun kann man ein bestehendes Repository zu diesem Server hochladen. Auf dem Server wird in den Kontext des Nutzers „git“ gewechselt und dort ein passender Ordner sowie ein „rohes“ Git Repository angelegt:

su git
mkdir testproject.git
cd testproject.git
git init --bare

Dem lokalen Git Repository wird mittels:

git remote add origin :testproject.git

ein neuer Remote zugewiesen. Sollte bereits ein „remote“ für „origin“ existieren, so wird dieser mit:

git remote rm origin

entfernt. Anschließend kann das lokale Repository an den Server übertragen werden und auf Updates überprüft werden:

git push origin master
git pull origin master

Wenn gewünscht kann man nun noch verhindern das man sich mittels des „git“ Accounts auf dem Server anmelden kann. Dazu muss die Datei „/etc/passwd“ editiert werden. Für den Nutzer „git“ wird die Shell dabei von „/bin/bash“ in „/usr/bin/git-shell“ geändert. Anschließend kann man sich mit dem Account nicht mehr an der Shell anmelden.

Fujitsu Server und die CSS Led

Kaum nimmt man einen Server aus dem Serverschrank, zeigt der entsprechende Server einem welche interessanten Fehler er über die LEDs an der Front ausgeben kann. In diesem Fall leuchtete bei einem Fujitsu Server die CSS LED. CSS steht dabei laut Fujitsu für „Customer Self Service“.

Die leuchtende CSS LED

Der erste Schritt führt bei einem solchen Fehler (wenn ein Windows auf dem System läuft) in die „Computerverwaltung“ und dort in die „Ereignisanzeige“ in den Unterpunkt „Anwendung“. Dort sollte die Quelle „ServerView Agents“ einen Fehler geworfen haben:

A critical error happend while BIOS selftest in cabinet 0 of server EXAMPLE. See server management message log (recovery log) for detailed information.

Der Fehler an sich ist nicht sehr aussagekräftig, so das man hier den Fehlerspeicher des Servers auslesen muss. Dies geschieht über die „Fehlerspeicheranzeige“ welche Teil der „Fujitsu ServerView Suite“ ist. Dort sieht man dann auch das der Fehler in diesem Fall nicht wirklich dramatisch ist:

Ursachen:
• Keyboard error detected during Power-On Self-Test (POST)
Problemlösungen:
• Check in the case of headless mode (without local keyboard) that AVR license is enabled or keyboard check is disabled
• Check keyboard cable
• If problem persists replace keyboard / cable.

Die entsprechende Einstellung wird im BIOS geändert und schon läuft der Server wieder wie am Schnürchen.

Ubuntu 12.04 + Time Machine

Die Funktion „Time Machine“ welche unter Mac OS X zu finden ist funktioniert mittels einer USB Festplatte oder einer Time Capsule. Wer aber nun schon einen Linux Server (in diesem Fall ein Ubuntu 12.04) rumzustehen hat, der möchte diesen eventuell für die Sicherung mittels Time Machine benutzen. Dazu gibt man im der Konsole folgendes ein:

sudo apt-get install netatalk avahi-daemon libnss-mdns

Nachdem die entsprechenden Pakete installiert worden sind, konfigurieren wir den Avahi Service mittels „sudo nano /etc/avahi/services/afpd.services“. In die sich öffnende Datei tragen wir folgendes ein:

<?xml version="1.0" standalone='no'?><!--*-nxml-*-->
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">
<service-group>
<name replace-wildcards="yes">%h</name>
<service>
<type>_afpovertcp._tcp</type>
<port>548</port>
</service>
<service>
<type>_device-info._tcp</type>
<port>0</port>
<txt-record>model=TimeCapsule</txt-record>
</service>
</service-group>

Danach legen wir die entsprechende Freigabe an, in dem wir die Datei „/etc/netatalk/AppleVolumes.default“ mittels:

sudo nano /etc/netatalk/AppleVolumes.default

bearbeiten. Der Inhalt dieser Datei sieht dabei so aus:

/home/seeseekey/Backup TimeMachine allow:seeseekey cnidscheme:dbd options:usedots,upriv,tm

Nun muss noch einmal der Server neugestartet werden und schon kann die Freigabe mittels Time Machine benutzt werden. Sollte beim Start des ersten Backups folgende Fehlermeldung:

Fehler 30 beim ersten Backup mittels Time Machine

erhalten so muss man das Terminal öffnen und dort folgendes eingeben:

hdiutil create -size $500g -fs HFS+J -type SPARSEBUNDLE -volname “BACKUP” Amy_133713371337.sparsebundle

Damit erzeugen wir eine Sparsebundle-Datei. Der Parameter Size gibt dabei die maximale Größe an. Der Dateiname entspricht dem Schema „COMPUTERNAME_MACADRESSE.sparsebundle“. Die erzeugte Datei kopieren wir nun in das Wurzelverzeichnis der entsprechenden Freigabe. Danach sollte das Backup dann ohne Probleme funktionieren.

Weitere Informationen gibt es unter:
http://meetinx.de/tutorial-time-machine-auf-nas-netzwerk-laufwerk/
http://www.kvibes.net/2011/08/mac-os-x-lion-timemachine-und-linux/
http://meetinx.de/tutorial-time-machine-backup-sparsebundle-in-groesse-begrenzen/
http://blog.rotzoll.net/2010/07/linux-als-apple-afp-share-mit-timemachine-support-backups-uber-das-netzwerk/