Nachdem gestern das Netzteil meiner externen HDD per Post kam und alle Daten noch da waren, ist meine SLUG jetzt wieder online. Natürlich habe ich die eineinhalb Wochen Leerlauf genutzt, um gleich mal auf Debian Lenny umzusteigen. Außerdem habe ich mir Gedanken darüber gemacht, wie die Slug in Zukunft funktionieren bzw. welche Dienste sie anbieten soll.

Meine bisherigen Gedanken als Mail-Server, Musik-Server, Mythbacken, etc. waren leider nicht praktikabel, da die Daten auf der HDD zu 99% der Zeit nur von einem Rechner aus genutzt wurden. Und da macht der extra Netzwerkzugriff auf die SLUG eigentlich nur Probleme. Außerdem halte ich es nicht gut für die Lebensdauer der Festplatte, wenn z.B. beim Mail-Server die externe Festplatte stündlich für den Mailcheck aufgeweckt wird. Und mittlerweile bin ich eh auf Google-Mail umgestiegen

Ab sofort wird die externe Festplatte nur sporadisch an der SLUG hängen, um erstens meine lokale Festplatte zu backupen (scheußliches denglisch, ich weiß) und zweitens als File-Server wie bisher zu dienen. Dies allerdings nur, wenn auch die externe Festplatte angeschlossen ist. Weitere Einsatzzwecke ohne HDD wären z.B. als Proxy- oder VPN-Server, aber das ist noch Zukunftsmusik.

Da die externe HDD jetzt nicht mehr dauerhaft an der SLUG hängen muss, habe ich mir gedacht, ein kleines Skript zum mounten/unmounten zu schreiben. Es sollte nach folgendem Mechanismus funktionieren: Wird die Taste an der Slug gedrückt, so sollte eine vorhandene HDD gemounted werden, falls sie dies schon ist, wird sie unmounted. Bei zweimaligem Tastendruck innerhalb von 2 Sekunden wird die Slug herunter gefahren.

Hier ist mal ein erster Entwurf mit reinem mounten und shutdown. Was noch fehlt, sind die Befehle zum Start der Services wie NFS, Samba etc. Dafür gibts schon einige beeps


#!/bin/bash

EXT_HDD_DEV=“/dev/sdb1″
PIDFILE=“/tmp/exthddmount.pid“

if [ -e $PIDFILE ]
then
leds beep -f 800 -l 200 -d 10 -r 2
rm $PIDFILE
/sbin/shutdown -t1 -a -h now
else
touch $PIDFILE
sleep 2
if [ -e $PIDFILE ]
then
if [ -e $EXT_HDD_DEV ]
then
mount $EXT_HDD_DEV
RESULT=$?
if [ $RESULT == 0 ]
then
echo „Mounted external HDD sdb1″
leds disk-2 flash
leds beep 1
else
umount $EXT_HDD_DEV
echo „Umounted external HDD sdb1″
leds disk-2 on
leds beep 2
fi
fi
rm $PIDFILE
fi
fi

indem mal wieder eine neue Client-ID verlangt wird, sollte man gleich zurückschießen

Seit letzter Woche funktionieren bei mir Kopete (KDE 4.1) und Pidgin nicht mehr. Ich bekomme nur die Nachricht, mein Client sei zu alt. Natürlich liegts wieder daran, dass die ICQ-Server die von mir geschickte Client-ID gesperrt haben, um alternative Clients auszuschließen. Doch Hilfe naht: Man muss nur in der Datei ~/.kde4/share/config/kopeterc den ICQ-Eintrag ändern. Bei mir half schon ein einfaches Inkrementieren der ClientID von 266 auf 267. Dann gehts wieder Hier noch der Auszug aus meiner kopeterc:


...
[ICQVersion]
Build=1042
ClientId=267
ClientString=ICQ Client
Country=us
Lang=en
Major=6
Minor=5
Other=0
Point=0
...


Wenn ich nicht zu viele ICQ-Kontakte hätte, wäre ich ja schon komplett auf Jabber und Skype umgestiegen. Wer will schon so einen mit Werbung verseuchten und schneckenlangsamen Messenger. Und das Protokoll ist nicht der Brüller. Aber die Altlasten halt wieder

Seit meine SLUG läuft beschäftige ich mich nun intensiv damit, wie ich sie sinnvoll für Backups nutzen kann. Ziel wäre, dass das Home-Verzeichnis meines Arbeitsrechners automatisiert auf der SLUG „gebackupt“ wird. Ich habe jetzt schon mehrere Lösungen betrachtet, doch irgendwie stellen mich die nicht zufrieden.

• rsync: Dieses Programm ermöglicht ein einfaches Spiegeln eines Verzeichnisses in ein anderes. Mit einem speziellen Algorithmus werden bei mehrmaligem synchronisieren nur die Änderungen von Dateien übertragen, was Übertragungskapazitäten und Zeit spart. Allerdings wird das Quellverzeichnis nur gespiegelt. Inkrementelle Backups sind nicht möglich, außer man speichert das Zielverzeichnis noch per Hand z.B. in eine tar-File. Das ist jedoch dann wieder Speicherintensiv. Außerdem überträgt rsync Dateinamen als Bytefolgen, es kann also Probleme geben, wenn man die Dateien im Zielverzeichnis betrachten will und der Zielrechner unterschiedliche Dateisysteme oder Kodierungen benutzt.
• rdiff-backup: Dieses Programm setzt auf rsync auf und fügt ein inkrementelles Backup hinzu. Leider kommt mir dieses Programm etwas verbuggt vor. So kann es nicht auf gemountete Samba-Shares sichern, sondern nur über eine Remote-Verbindung, die mir wesentlich langsamer als Samba vorkommt. Auch übernimmt rdiff-backup alle Probleme, die schon rsync mitbringt. Beim Backup auf meine SLUG kam es zudem zu abstürzen, weil rdiff-backup mit bestimmten Dateinamen nicht umgehen konnte oder weil ominöse „Security Exceptions“ geworfen wurden.
• Samba-Backup: Eine Lösung, die ich gerade verfolge ist das Backup per Samba, wie in diesem Artikel beschrieben. Ich hab es noch nicht ausprobiert, doch mir schweben schon jetzt einige Nachteile im Kopf umher. Um zu sicher, muss auf dem Quellrechner das Verzeichnis freigegeben sein, also bei mir mein ganzes Home-Verzeichnis, was ich nicht unbedingt will. Ein Backup angestoßen vom Client zum Server wäre die Lösung. Allerdings gibt es dann hier das Problem, dass immer alle Daten übertragen werden und dass inkrementelle Backups nur händisch möglich sind. Die Probleme mit den Dateinamen sollten aber nicht mehr auftreten. Dafür werden bei Samba bestimmt Neue hinzukommen
• Professionelle Backup-Lösungen: Nach etwas Suche bin ich auf diesen Artikel gestoßen. Hier werden professionelle Backup-Lösungen für Linux beschrieben. Die Nicht-Open-Source-Programme bleiben bei mir sowieso außen vor. Die anderen freien Programme kommen mir alle etwas groß und komplex vor. Die Einarbeitungszeit ist bei mir doch mittlerweile ein bestimmender Faktor, außerdem sind die Hardware-Ressourcen der SLUG begrenzt.

Nach der Betrachtung dieser Lösungen bin ich zu dem Schluss gekommen, dass rsync für meine Zwecke völlig ausreicht. Im Moment wird mein Home-Verzeichnis von meinem Arbeitsrechner per Skript auf die SLUG gespiegelt. Dieser  Vorgang wird vom Client aus angestoßen und nicht von der SLUG.

Nachdem meine SLUG nun fleißig Daten schaufelt und speichert gehts gleich an das nächste Projekt:

Da es für Debian Lenny nun Backports für KDE 4.1 gibt, hab ich mich entschlossen, KDE 4 gleich mal wieder zu testen. KDE 4.0 hatte ich kurz nach dem Release schon auf meinem damaligen Gentoo System am laufen, es hat da aber fast nix funktioniert und meine parallele KDE 3.5.7 war auch irgendwie verschandelt

Folgend hab ich auf Debian Testing gewechselt und das seither betrieben (wohl eher aus Faulheit, Gentoo dauert einfach zu lange zum Kompilieren und Einstellen, wenns aber mal rennt, dann rennts richtig). Nun stehe ich wieder vor der Entscheidung, KDE 4 gleich zu installieren oder noch auf das endgültige Release von Lenny im stable Zweig zu warten. Wahrscheinlich wird aber die Ungeduld wieder mal siegen

Zum Ausprobieren von KDE 4 hab ich KDE-four-live entdeckt, eine Live-Distribution, welche auf openSUSE basiert. Ich war erstaunt, wie stabil KDE 4 nun läuft und nach einigem Rumprobieren hab ich auch endlich kapiert, wie das Panel und die Widgets zusammenhängen und wie man ein entferntes Panel wieder herstellt. Was irgendwie noch fehlt ist, dass man Panel-Elemente beliebig verschieben kann, so wie in KDE 3.5, aber das kommt sicher auch noch.

Ansonsten nervt mich persönlich das von SUSE übernommene K-Menü, man kanns aber mit einem Klick auf das alte Menü umstellen. Genial sind dagegen die SVG-Widgets, stufenloser Zoom und super Bildqualität (sowas hätte Window$ Vi$ta eigenlich auch können sollen, aber dann wärs wohl noch unbedienbarer).

Neben diesen ungewohnten Dingen haben mich die Anwendungen angenehm überrascht, besonders Kontact und Kopete unterscheiden sich auf den ersten Blick nur im Oberflächen-Design. Die Beta 2 von Amarok ist bei KDE-four-live ebenfalls enthalten, macht aber einen sehr unfertigen Eindruck, Musik spielt sie aber schon.

Die in KDE 4 enthaltenen Compositing-Effekte habe ich noch nicht getestet, dazu fehlt KDE-four-live leider der proprietäre Nvidia-Treiber.

Als Schlusswort gibts nur zu sagen, dass mich KDE 4 nach anfänglicher Abschreckung immer mehr begeistert, wahrscheinlich werde ich es schon nächstes Wochende auf meinem Debian installieren, dann gibts auf diesem Blog auch eine kleine Anleitung dafür.

Am Samstag kam die NLU2 per Paketdienst und seitdem hab ich den Rechner nur zum Essen und Schlafen verlassen

Nach anfänglichen kleinen Problemen hab ich das Gerät nun mit einem Debian/NSLU2 neu geflasht. Das System läuft auf der ebenfalls neu gekauften externen Festplatte (Western Digital MyBook Essential 500GB). Zusätzlich hab ich einen alten USB-Stick (128MB) am USB-Port 2, auf der eine SWAP-Partition enthält. Diese Konfiguration gefällt mir aber noch nicht besonders, ich werde mir wohl in den nächsten Tagen noch einen neuen, großen USB-Stick kaufen, auf dem dann das gesamte Debian-System laufen soll.

Zum Warmwerden hab ich als erstes einen NTP-Server auf der SLUG installiert, der nun klaglos seinen Dienst für Linux- und Windows-Clients erbringt. Als nächstes sollte die SLUG um einen Fileserver-Dienst erweitert werden. Dieser läuft nach einigen Basteleien nun auch. Positives Detail der Debian Software ist, dass jetzt Datentransfers via SMB fast doppelt so schnell laufen als mit der Linksys Firmware:

• Linksys Firmware: 2-3 MB/s
• Debian/NSLU2:     4-7 MB/s

Keine Ahnung woran das liegt, ich hätte eigentlich erwartet, dass die nicht so stark auf die NSLU2 optimierte Debian Software langsamer läuft. Die Messungen habe ich mit dem „Kopieren“-Dialog des KDE-Konquerors gemacht.

Was läuft schon:

• NTP für Zeitsynchronisation von Clients
• Samba als Fileserver für Linux- und Windows-Clients

Was wäre noch zu überlegen:

• NFS: eigentlich weniger, für Linux-Clients nutze ich auch SMB
• SVN: auf jeden Fall für meine kleinen 3D- und Java-Basteleien
• iTunes: ich hab schon ein bisschen mit Firefly rumgespielt, hat aber noch funktioniert
• UPnP: als Alternative zu iTunes, näher an der Microsoft-Welt, allerdings gibts nur wenige gute Linux-Clients dafür
• DHCP: brauch ich nicht, nutz ich nicht (und die Fritz Box machts auch)
• DNS wäre zu überlegen, bei 4 Rechnern aber sicher verschwendete Rechenleistung
• Webserver: bin noch am überlegen, ob Apache, LighTTP(?), Cherokee, etc. Vielleicht zieht dieser Blog bald darauf um
• Java: Für meine Basteleien mit OSGI, RCP, Equinox … Allerdings scheints nur die GNU-JVM für Debian/NSLU2 zu geben.
• Firewall/Paketfilter: auf jeden Fall, aber erst, wenn alle Dienste fehlerfrei laufen
• TV-Recorder: wäre super, leider gibts immer noch keine Linux-Treiber für meine TV-Karte
• VPN: eher weniger, zieht wahrscheinlich zu viel Leistung (außer die alten Zocker-Tage kommen wieder)
• VOIP: da müsste ich erst mal suchen, was es so gibt
• Jabber: ein eigener Jabber Server wäre lustig, aber auch zu viel des Guten

Und hier noch ein kleines Bild von der Hardware:

The SLUG

Nachdem ich in den letzten Tagen verstärkt nach einer NAS-Lösung für mein Heimnetzwerk gesucht habe, bin ich auf die NSLU2 von Linksys gestoßen. Dieses kleine Gerät kann eigentlich nicht viel mehr, als eine externe USB-Festplatte in ein Netzwerk einzubinden, so dass alle Computer via SMB darauf zugreifen können. Die Produktseite ist hier zu finden.

Das Besondere an diesem Gerät ist, dass die vorhandene Linux-Firmware durch andere, frei verfügbare Versionen ersetzt werden kann. Mittlerweile kann man auf dem Gerät ein vollwertiges Debian- oder Gentoo-Linux installieren. Dadurch sind nun auch weitere Einsatzmöglichkeiten wie Webserver, automatisierte Backups, SVN-Dienste, Telefonsteuerung, Media- oder UPnP-Server und noch viel mehr möglich.

Warum aber das ganze auf dieser schwachbrüstigen Hardware installieren (266 Mhz ARM CPU, 32 MB RAM). Nun, in einem Heimnetzwerk kommt es wohl weniger auf die Performance der Dienste als vielmehr auf den Stromverbrauch an. Und da ist das Gerät im Vergleich zu einem Server unschlagbar. Die im Netz herumgeisternden Verbrauchszahlen bewegen sich zwischen 2 und 15 Watt, je nach Art der angeschlossenen Geräte. Auf der NSLU2-Homepage gibt es noch viele Anwendungs-Beispiele, Howtos und Tips für Troubleshooting. Ein sehr gutes und deutschsprachiges NSLU2-Forum ist hier zu finden.

P.S. Gerade hab ich das Gerät bei Reichelt bestellt, bin mal gespannt, was es alles leistet.

So, um die Hitrate meines Blogs etwas zu erhöhen, gibts hier mal ein kleines Bash-Skript, das *.wav-Dateien in *.mp3 konvertiert. „Howto convert…“ wird glaub ich sehr häufig auf Google gesucht

Das Skript füllt auch ID3-Tags aus, wenn vorher die Variablenalbum, artist, genre und year ausgefüllt werden. Diese Daten sind im Skript für das Album „Cult“ von „Apocalyptica“ eingetragen. Titelnummer und -name werden ebenfalls beachtet, wenn der Dateiname der *.wav-Datei der Form „Nummer – Name.wav“ ist, also z.B. „15 – Nothing else matters.wav“.

album='Cult'
artist='Apocalyptica'
genre='Metal'
year='2001'
for file in ls *.wav
do
number=$(echo $file | sed -r 's/.* - ([0-9]{2}) - .*/\1/')
title=$(echo $file | sed -r 's/.* - (.+).wav/\1/' | sed -r 's/%2F/\//')
newfile=$(echo "$number - $title.mp3")
lame -h -V 2 --vbr-new --tt "$title" --ta "$artist" --tl "$album" --tn "$track" --tg "$genre" --ty "$year" "$file" "$newfile"
done

Es ist zwar nicht das Nonplusultra, aber vielleicht doch noch etwas verständlicher als die vielen anderen Skripte, die im Netz herumgeistern.