Die Slug selber besitzt zwar keine Soundkarte, doch es gibt mittlerweile USB-Soundkarten die nicht mehr als ein paar Euro kosten. Ich hab auf gut Glück einen DIGITUS USB Audio Controller erstanden und siehe da, das Ding funktioniert bei Debian Lenny oder auch Ubuntu Intrepid Ibex…

root@nslu2:~$ tail -f /var/log/messages
Feb 17 18:02:09 nslu2 kernel: [43362489.130000] usb 2-1: new full speed USB device using ohci_hcd and address 2
Feb 17 18:02:09 nslu2 kernel: [43362489.320000] usb 2-1: configuration #1 chosen from 1 choice
Feb 17 18:02:09 nslu2 kernel: [43362489.350000] usb 2-1: New USB device found, idVendor=0d8c, idProduct=0103
Feb 17 18:02:09 nslu2 kernel: [43362489.350000] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Feb 17 18:02:09 nslu2 kernel: [43362489.360000] usb 2-1: Product: C-Media USB Audio       
Feb 17 18:02:09 nslu2 kernel: [43362489.370000] usb 2-1: Manufacturer: C-Media INC.
Feb 17 18:02:12 nslu2 kernel: [43362491.840000] usbcore: registered new interface driver snd-usb-audio

root@nslu2:~$ cat /proc/asound/cards 
 0 [default        ]: USB-Audio - C-Media USB Audio       
                      C-Media INC. C-Media USB Audio        at usb-0000:00:01.1-1, full speed

out-of-the-box, es wird also auch an der Slug funktionieren… Einen kleinen Hinweis am Rande. Ich habe meine Slug DeUnderclocked, also den Widerstand, der ältere Slugs auf die halbe Taktrate einbremst, entfernt. Da PulseAudio etwas Performance braucht und die Slug davon nicht gerade viel hat, ist dies ein wichtiger Punkt…

Im folgenden Versuche ich euch an die Hand zu nehmen und PulseAudio auf der Slug zu installieren, so dass ihr Sound von einem anderen Linux-Rechner über PA zur Slug, die ihr natürlich an eine Stereoanlage oder gute Boxen angeschlossen habt, umleiten könnt. Als erstes müssen eine Reihe von Paketen installiert werden…

root@nslu2:~$ apt-get install --no-install-recommends alsa-utils libasound2-plugins pulseaudio pulseaudio-module-zeroconf pulseaudio-utils alsa-utils libasound2-plugins hal pulseaudio-module-hal

Damit nicht halb GNOME mitinstalliert wird, benutze ich die Option --no-install-recommends, so werden die empfohlenen Abhängigkeiten nicht mit installiert. Als nächstes muss man den eigenen Benutzer auf der Slug zu den passenden Gruppen hinzufügen.

root@nslu2:~$ adduser $USER pulse
root@nslu2:~$ adduser $USER pulse-access
root@nslu2:~$ adduser $USER pulse-rt
root@nslu2:~$ adduser $USER audio

Danach muss man sich von der Slug abmelden und über SSH wieder einloggen, damit die Gruppenzugehörigkeiten auch aktiv werden. Im nächsten Schritt müssen Endgeräte für Pulseaudio angelegt werden. Dies erfolgt in der Datei /etc/asound.conf. In diese muss der Inhalt…

pcm.pulse {    
        type pulse
}    
ctl.pulse {
        type pulse
}
pcm.!default {
        type pulse
}
ctl.!default {
        type pulse
}

…eingefügt werden. Nun muss man PulseAudio etwas in die Schranken weisen. PA kann eine Menge Performance schlucken. Performance, die auf einer Slug gar nicht vorhanden ist. Würde man jetzt PA starten, so würde man gar keinen oder nur sehr stotternden Sound hören. PulseAudio kennt dazu Qualitätsstufen, die über /etc/pulse/daemon.conf eingestellt werden können. Mit

[...]
resample-method = speex-float-0
[...]

sollte PA beim Abspielen rund 20% Last erzeugen und somit die Slug nicht allzusehr auslasten. Wer immer noch stotternden Sound bekommt, der kann

[...]
resample-method = trivial
[...]

einstellen, was jedoch auch die geringste Qualität bedeutet. Nun kann man PA zum ersten mal starten.

me@nslu2:~$ pulseaudio
W: main.c: setrlimit(RLIMIT_NICE, (31, 31)) failed: Operation not permitted
W: main.c: setrlimit(RLIMIT_RTPRIO, (9, 9)) failed: Operation not permitted
ALSA lib control.c:909:(snd_ctl_open_noupdate) Invalid CTL front:0

Die Meldungen dabei kann man ignorieren. Spielt man jetzt einen Klang von einem zweiten SSH-Terminal aus ab…

me@nslu2:~$ aplay /usr/share/sounds/alsa/Front_Right.wav

…sollte man den Sound aus den angeschlossenen Boxen der Slug hören. Nun geht es weiter zur Netzwerkkonfiguration von PulseAudio. Wie eingangs erwähnt und in diesem Beitrag beschrieben kann PulseAudio den Audiostream einer Anwendung von einem PA-Server zum nächsten leiten. So kann man Musik auf dem kleinen Netbook abspielen und der PA-Server auf der Slug spielt diese dann über die angeschlossene Stereoanlage ab. Damit dies möglich ist, müssen in der /etc/pulse/default.pa die dafür nötigen Module module-zeroconf-publish und module-native-protocol-tcp aktiviert werden

[...]
### Network access (may be configured with paprefs, so leave this commented
### here if you plan to use paprefs)
#load-module module-esound-protocol-tcp 
load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1;192.168.0.0/16
load-module module-zeroconf-publish 
[...]

Bei module-native-protocol-tcp kann man gleich noch einen IP-Bereich festlegen, der den PA-Server ansprechen darf. Nun ist PA fertig konfiguriert, es fehlt nur noch eine Einstellung dass PA beim Starten der Slug anläuft. Dies macht man über die /etc/default/pulseaudio. Hier muss der Start als „Daemon“…

# Start the PulseAudio sound server in system mode.
# (enables the pulseaudio init script)
# System mode is not the recommended way to run PulseAudio as it has some
# limitations (such as no shared memory access) and could potentially allow
[...]
# System->Preferences->Sound). For other sessions, you can simply start
# PulseAudio with "pulseaudio --daemonize".
# 0 = don't start, 1 = start
PULSEAUDIO_SYSTEM_START=1
[...]

..aktiviert werden. Nun kann man PulseAudio über /etc/init.d/pulseaudio restart starten und stoppen. Ab jetzt kann man wie hier beschrieben Sounds vom eigenen Rechner auf die Slug umleiten und ordentlichen Sound auch aus der kleinsten Kiste bekommen.

Das war das „Howto“, aber wie gut funktioniert es? PulseAudio fordert die Slug schon deutlich. Solange die Slug sonst nichts zu tun hat funktioniert es auch richtig gut. Doch ist bspw. zur selben Zeit ein Dateitransfer via Samba oder NFS aktiv, so kommt der Sound schon ins Stocken. Als „reiner“ Soundserver ist die Slug schon so zu gebrauchen, doch wenn man eine Eierlegendevollmilchsau sucht, so liegt man mit der NLUS2 falsch.

DHCP

Vorweg eine Werbung für DHCP. Ich gehe mal vom typischen Heimanwender aus: Der Internetzugang wird über einen DSL-Router mit eingebauten WLAN-Access Point realisiert. Diese Dinger haben so gut wie immer einen DHCP-Server eingebaut, er ist eigentlich auch immer von Haus aus aktiv. D.h. im Normalfall muss die Netzwerkkonfiguration angeschlossener Computer überhaupt nicht angepasst werden.

Statische IPs? Willkommen im 21 Jahrhundert…

OK, nun wollt ihr einen Serverdienst wie bspw. einen Webserver hinter dem Router betreiben. Dazu müssen Ports an diesen weitergeleitet werden. Da sich dafür die IP nicht ändern darf, muss man trotzdem wieder mit einer fest eingetragenen IP arbeiten. Nicht zwangsläufig! Jeder ordentliche Router bietet die Möglichkeit eine IP fest einem Rechner zuzuordnen. Dies geschieht über die MAC-Adresse der Netzwerkkarte. Man muss die Nummer einfach nur auslesen und im Router dann mit einer IP verknüpfen. Ab dann bekommt der Rechner immer die selbe IP.

Achtung. Nicht jeder Router kann das. Wenn ihr so einen habt, dann kompostiert ihn. Es gibt zig billige Alternativen, die das können. Ausserdem schafft man sich einen Singe Point of Failure. Fällt der Router aus, so bekomme die Rechner keine IPs mehr. Dennoch halte ich diese Problematik – gerade im SoHo-Bereich – für sehr irrelevant.

Lokale Namensauflösung mit Avahi

Nun zum Kern dieses Beitrages: moderne Techniken. Computer kommunizieren in Netzwerken über IPs und nicht über Rechnernamen. Ohne einen zentralen Nameserver (oder manuell angepassten host-Dateien) weiß ein Computer nicht unter welcher IP er einen anderen Rechner erreichen kann. Hat man beispielsweise einen Webserver mit dem Namen „rechenknecht“ im LAN und möchte diesen von einem anderen Rechner ansprechen, so kann man nicht einfach http:\\rechenknecht im Browser eingeben und so die Webseiten des Webservers aufrufen. Man müsste zuvor die Verknüpfung IP Rechnername erst in die hosts-Datei eintragen oder einen Nameserver einrichten, der dann den Namen auflösen könnte.

Beide „Lösungen“ sind nicht ideal. Befinden sich weitere Rechner im LAN, so müsste überall die hosts-Datei angepasst werden. Gibt es eine Änderung, so muss wieder an allen Rechner Hand angelegt werden. Bringt ein Bekannter einen Rechner mit, so müssten hier Konfigurationen vorgenommen werden, die man später wieder rückgängig machen muss. Und ein Nameserver ist auch nicht in wenigen Minuten eingerichtet und letztendlich für ein kleines LAN mit Kanonen auf Spatzen geschossen.

Die Lösung für dieses Problem nennt sich Avahi / Zeroconf. Zeroconf verspricht „Zero Configuration Networking“ und kommt dem auch sehr nahe… Avahi wird schon seit längerer Zeit bei vielen Linuxen vorinstalliert und ist voll kompatibel zu Bonjour von MacOS X, das es auch für Windows gibt. Was macht nun Avahi? Über Avahi gibt ein Rechner seine Präsenz und seine angebotenen Dienste im lokalen Netzwerk bekannt. Dazu muss Avahi nicht konfiguriert werden, es funktioniert „Out-of-the-box“. Auf einem Ubuntu System ist Avahi von Haus aus installiert, wie afaik auf bei OpenSuse und Fedora. Bei Debian muss die Namensauflösung über…

$ apt-get install libnss-mdns

nachinstallieren. Ist dies geschehen, kann man jeden Rechner über seinen Namen und ein angehängtes .local ansprechen. So kann man bspw. nun den Rechner rechenknecht über…

$ ping rechenknecht.local

…anpingen oder über…

$ ssh rechenknecht.local

…auf den SSH-Server des Rechners gehen oder über http:\\rechenknecht.local den Webserver des Rechners öffnen oder oder… Hat man auf dem Server Apache mit mod-dnssd laufen, dann gibt der Server seine Existenz über Avahi bekannt und Browser wie Epiphany zeigen ihn sofort an.

Dabei muss man sich auch keine Gedanken machen, dass die Information das eigene LAN verlässt. Avahi ignoriert sämtlichen Traffic, der nicht aus dem eigenen LAN kommt.

Serverlos im LAN chatten und Daten austauschen

Rechner über ihren Namen anzupingen ist jetzt nicht sonderlich aufregend, wo steckt nun der eigentlich größte nutzen? Über Avahi können Programme sich publik machen. So kann man bspw. dank Avahi/Zeroconf ohne einen zentralen Server im LAN chatten oder Daten austauschen, Medien streamen, Voip-Gespräche führen usw. ohne dass man auch nur einen Serverdienst einrichten müsste.

Chatten

Instant-Messaging Programmen laufen üblicherweise immer über einen zentralen Server im Internet ab, an dem man sich einloggen muss. Doch man kann auch ohne Internetzugang im lokalen Netzwerk chatten. Moderne IM Clients wie Gajim oder Pidgin können dank Avahi/Zeroconf/Bonjour im LAN kommunizieren ohne dass man einen Server braucht.

Exemplarisch gehe ich auf Gajim und Pidgin sowie Miranda für Windows ein. In Pidgin muss man ein neues Konto anlegen. Als Protokoll stellt man Bonjour ein. Bei Gajim ist das Konto von Haus aus vorhanden, jedoch nach der Installation des Programms noch nicht aktiv. Um also Avahi/Zeroconf mit Gajim zu nutzen, muss man in den Konteneinstellungen das Konto Local aktivieren. Sollte das nicht möglich sein, so muss man das Paket python-avahi nachinstallieren.

$ sudo apt-get install python-avahi

Letztendlich möchte ich die Fans von Windows nicht außen vor lassen. Für den wohl populärsten Multi-Messenger auf Windows-Plattformen Miranda gibt es mit iChat ein Plugin, das Miranda Avahi/Zeroconf fähig macht.

Daten austauschen

Ähnlich wie Gajim oder Pidgin arbeitet Giver. Auch hier sieht man eine Kontaktliste vergleichbar wie bei einem Instant-Messaging Programm. Allerdings kann man mit den im LAN aktiven Kontakten nicht chatten. Giver dient ausschließlich zum Austausch von Dateien oder Ordnern. Per Drag&Drop zieht man eine Datei/einen Ordner auf den Kontakt. Akzeptiert der Empfänger die Übertragung, so startet der Versand der Daten.

Ein wunderbares Anwendungsbeispiel ist der Austausch von Screenshots, wenn man etwas in einer virtuellen Maschine ausprobiert. Ich installiere mir öfters mal eine Entwicklungsversion von $DISTRIBUTION. Mit Giver bekommt man Screenshots oder Konfigurationsdateien in Nullkommanix aus der VM auf den realen Desktop, ohne dass man dafür mit Freigaben hantieren muss.

Medien streamen

Ein weiteres Beispiel ist das Streamen von Medien. Man kennt dies von iTunes. Dort kann man die Musik, die sich auf einem Rechner befindet via iTunes auch auf einem anderen Rechner mit iTunes verfügbar machen. Das ganze funktioniert plattformübergreifend mit vielen Programmen. Egal ob man nun iTunes, Rhythmbox, Banshee oder Amarok benutzt. Sobald ein Programm DAAP als Protokoll beherrscht, kann es die Freigaben im lokalen Netzwerk automatisch einbinden. Möchte die Verteilung der eigenen Musik in Rhythmbox aktivieren, so muss man dies Bearbeiten | Plugins | DAAP-Musikverteilung | Konfigurieren | Eigene Musik verteilen erst einstellen.

Danach taucht die eigene Musik automatisch in iTunes, Banshee und Co. der anderen Mitglieder des eigenen LANs auf.

Weiteres zu Avahi

In vielen anderen „Produkten“ steckt mittlerweile ebenfalls Avahi. Gibt man einen Drucker über CUPS im Netzwerk frei, so finden die weiteren Installation von CUPS im Netzwerk automatisch den freigegeben Drucker. Über Ekiga lassen sich im lokalen Netzwerk VoIP- oder Video-Gespräche serverlos führen. Gibt man seinen GNOME-Desktop über Vino frei, so findet bspw. Vinagre über Avahi diese Desktopfreigabe. Über Pulseaudio lässt sich der Sound einer Anwendung gezielt zu einem Rechner leiten, der bspw. an die Stereoanlage angeschlossen ist, dabei findet sich PulseAudio ebenfalls wieder über Avahi/Zeroconf und so weiter und so fort.