NSLU2 als Backup-Server

Bereits vor einigen Monaten habe ich mir eine Linksys NSLU2 zugelegt, welche bisher jedoch mangels Idee für den Einsatz originalverpackt vor sich hin oxidierte. Erst mit dem Erwerb eines zweiten Mac-Rechners und dem Erscheinen der Apple Time Machine kristallisierte sich ein Anwendungsfall für das Gerät heraus: Ein Backup-Server. Die Idee war zunächst, via Time Machine die Backups der Macs dorthin zu schreiben, allerdings stellte sich während der Installation der NSLU2 heraus, daß netatalk bei mir darauf nicht unter OpenWrt lief. Als Alternative bot sich dann schnell ein rsync-Server an. Um die Installation und Konfiguration der NSLU2 als rsync-basierter Backup-Server soll es in diesem Artikel gehen.

Voraussetzungen

Für das Szenario sind folgende Dinge notwendig:

  • eine Linksys NSLU2
  • eine oder zwei externe Festplatten mit USB-Anschluß
  • ein lokales Netzwerk
  • ein zweiter Rechner für das Setup der NSLU2 und ggf. der externen Festplatte(n)

Zunächst sollte die NSLU2 ins lokale Netz integriert und schon einmal auf grundsätzliche Lauffähigkeit kontrolliert werden. Außerdem ist es notwendig, die IP- sowie MAC-Adresse zu ermitteln und für den späteren Zugriff zu notieren.

Schritt 1: Installation der notwendigen Software zum Flashen

Die NSLU2 wird bereits mit einer vollständig lauffähigen Firmware ausgeliefert, welche jedoch für das Szenario nicht ausreichend ist. Es existiert allerdings eine aktive Community, welche verschiedene alternative Betriebssysteme für das Gerät zur Verfügung stellt. Auf der Webseite findet man neben diversen How-Tos und einem Wiki auch eine Matrix mit allen verfügbaren Systemen. Meine Wahl fiel auf OpenWrt, da dies ohne zusätzlich notwendigen externen Speicher läuft, also vollständig in den verfügbaren Speicher von acht MB Größe paßt.
Der erste Schritt ist nun also das Flashen der NSLU2 mit einem neuen Betriebssystem. Hierfür wird ein zweiter Rechner benötigt, auf dem UpSlug2 installiert wird. Ich habe hierfür einen FreeBSD-Rechner verwendet und bin im wesentlichen der Anleitung im Wiki gefolgt. Das Tool benötigt die Bibliothek libpcap, welche zunächst über die Ports installiert werden muß. Nach dem Herunterladen und Entpacken des Archivs werden als root folgende Befehle ausgeführt, um UpSlug2 zu kompilieren und zu installieren:

cd upslug2-11
autoreconf -i
./configure --with-libpcap
make install 

Nun liegt die Anwendung unter /usr/local/sbin/upslug2 zur Verwendung bereit.

Schritt 2: Flashen der NSLU2

Um das Image aufspielen zu können, muß die NSLU2 in den Upgrade-Modus gebracht werden. Hierfür wird das Gerät zunächst ausgeschaltet. Anschließend hält man mit einem spitzen Gegenstand den Reset-Knopf auf der Geräterückseite gedrückt und schaltet das Gerät gleichzeitig wieder ein. Die „Ready/Status“-LED leuchtet zunächst gelb und ändert dann die Farbe zu orange. In diesem Moment muß der Reset-Knopf losgelassen werden. Blinkt die Status-LED abwechselnd orange und grün, befindet sich das Gerät im Upgrade-Modus.
Nun kann das gewünschte Image auf die NSLU2 aufgespielt werden. Die Aufruf-Syntax von UpSlug2 lautet wie folgt:

upslug2 -d  -t  -i 

Der Vorgang nimmt einige Zeit in Anspruch; nach ca. 90 Minuten wird das Gerät neu gebootet.

Schritt 3: Vorbereitung der externen Festplatte(n)

Die meisten externen Festplatten sind im Urzustand mit einem Windows-Dateisystem formatiert, also kaum für eine sinnvolle Datensicherung geeignet. Stattdessen greift man zum Beispiel auf das in der Linuxwelt verbreitete ext3 zurück. Die Formatierung der Festplatte(n) kann jedoch nicht an der NSLU2 direkt erfolgen, da OpenWrt keinen Swap-Speicher zur Verfügung stellt. Parallel zum Flashen der NSLU2 man also dem Zweitrechner die Zeit geben, die Festplatte vorzubereiten. Hierzu müssen im Falle eines FreeBSD über die Ports die sysutils/e2fsprogs installiert werden.
Mit Hilfe von fdisk <device> wird die Festplatte zunächst partitioniert (Typ 83 [linux native]) und anschließend mit folgendem Befehl formatiert, der Parameter „j“ steht hierbei für das Journaling:

mke2fs -j 

Schritt 4: Konfiguration der NSLU2

Sobald die NSLU2 durch UpSlug2 neu gestartet wurde und das Formatieren der externen Platte abgeschlossen ist, kann die Konfiguration beginnen. Dies kann entweder per SSH an der Konsole geschehen oder (mit einigen Abstrichen) auch über das mitgelieferte Web-Interface. Ich habe mich für die Konsole entschieden und sogar das Web-Interface deaktiviert, um Speicher zu sparen (dazu später mehr).
OpenWrt übernimmt nach dem Start die zuletzt eingestellte IP-Adresse des Gerätes vor dem Flashen, darüber sollte die NSLU2 also erreichbar sein. Wer mag, kann dem Gerät einen neuen Hostnamen und auch eine feste IP-Adresse vergeben, die Anlaufpunkte hierfür sind die Dateien /etc/config/network (Hostname, IP-Adresse, Protokoll 'static' oder 'dhcp') und /etc/config/system (Hostname).

Um ein Ausschalten der NSLU2 über den Schalter am Gehäuse zu ermöglichen, muß folgende Zeile in die Datei /etc/inittab eingetragen werden:

::ctrlaltdel:/bin/shutdown.sh

Das aufgerufene Skript muß im angegebenen Verzeichnis angelegt werden und mit folgendem Inhalt gefüllt werden:

#!/bin/sh /etc/rc.common

/etc/init.d/rcS K stop
/sbin/poweroff

Diese Zeilen sorgen dafür, daß zunächst alle aktivierten Dienste beendet werden und anschließend das Gerät ausgeschaltet wird.

Nun wird die Festplatte angeschlossen und geprüft, ob sie von der NSLU2 korrekt erkannt wird. Dies kann mit Hilfe des Befehls logread geschehen, nach dessen Aufruf Zeilen wie diese an der Konsole erscheinen sollten:

SCSI subsystem initialized
Initializing USB Mass Storage driver...
usb 3-1: new high speed USB device using ehci_hcd and address 2
usb 3-1: configuration #1 chosen from 1 choice
scsi0 : SCSI emulation for USB Mass Storage devices
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
usb-storage: device found at 2
usb-storage: waiting for device to settle before scanning
scsi 0:0:0:0: Direct-Access     WD       10EACS External  1.65 PQ: 0 ANSI: 4
SCSI device sda: 1953525168 512-byte hdwr sectors (1000205 MB)
sda: Write Protect is off
sda: Mode Sense: 21 00 00 00
sda: assuming drive cache: write through
SCSI device sda: 1953525168 512-byte hdwr sectors (1000205 MB)
sda: Write Protect is off
sda: Mode Sense: 21 00 00 00
sda: assuming drive cache: write through
 sda: sda1
sd 0:0:0:0: Attached scsi disk sda
usb-storage: device scan complete

Als nächstes muß geprüft werden, welche Software bereits installiert ist und welche ggf. nachinstalliert werden muß. OpenWrt basiert wie einige andere Embedded-Systeme auf dem iPKG-Paketsystem, die Verwaltung findet über den Befehl ipkg statt. Die wichtigsten Befehle lauten:

  • ipkg update – Initialisierung/Aktualisierung
  • ipkg list_installed – Auflistung aller installierten Pakete
  • ipk install <paketname> – Installation des angegebenen Pakets
  • ipkg remove <paketname> – Deinstallation des angegebenen Pakets

Die für den Umgang mit Massenspeichern notwendigen Pakete sollten bereits im Image enthalten sein, einzig das Paket e2fsprogs muß nachinstalliert werden.

Ich habe für die angeschlossene externe Festplatte ein Verzeichnis /mnt/disk1 als Mountpoint angelegt, zudem sollte man sich ein Skript erstellen, welches beim Hochfahren der NSLU2 die Festplatte prüft und einbindet:

#!/bin/sh /etc/rc.common

START=99
STOP=40

start()
{
    sleep 5
    e2fsck -p /dev/sda1 &
    sleep 5
    mount -t ext3 /dev/sda1 /mnt/disk1
}
stop()
{
    sync
    sync
    umount /mnt/disk1
}
restart()
{
    stop
    sleep 1
    start
}

Dieses Skript wird unter /etc/init.d gespeichert (z.B. /etc/init.d/usbdisk1), ausführbar gemacht und zuletzt in den Startprozeß über folgenden Befehl eingebunden:

/etc/init.d# ./usbdisk1 enable

Dienste, die nicht benötigt werden (z.B. webif* oder httpd können auf die gleiche Art deaktiviert, also aus dem Startprozeß entfernt werden:

/etc/init.d# ./webif disable

Schritt 5: Installation zusätzlicher Software

Nachdem nun das System selbst, als auch die externe Festplatte für den Einsatz vorbereitet sind, kann rsync mit Hilfe des Paketmanagers installiert werden. Um rsync als Daemon laufen zu lassen und auch schon beim Hochfahren des Geräts diesen zu starten, wird ein weiteres Startskript benötigt:

#!/bin/sh /etc/rc.common

START=99
STOP=40

start()
{
    echo -n "Starting rsyncd... "
    /usr/bin/rsync --daemon
    echo "done."
}
stop()
{
    echo -n "Shutting down rsyncd... "
    killall rsync
    echo "done."
}
restart()
{
    stop
    sleep 1
    start
}

Auch dieses Skript wird z.B. als rsnycd unter /etc/init.d gespeichert und aktiviert.

Die Konfiguration von rsync im Daemon-Modus findet in der Datei /etc/rsynd.conf statt. Darin werden u.a. die verfügbaren Module sowie Zugangsberechtigungen kontrolliert. Am Beginn der Datei stehen globale Parameter, gefolgt von den einzelnen Modulkonfigurationen.

Die folgende Konfiguration stellt ein Modul namens „disk1“ für den Zugriff zur Verfügung. Die Parameter müssen den jeweiligen Gegebenheiten angepaßt werden.

pid file = /var/run/rsyncd.pid
log file=/tmp/log/rsyncd.log

[disk1]
path=/mnt/disk1
comment=USB disk 1
use chroot=true
read only=false
uid=foo
gid=foos
auth users=foo
secrets file=/etc/rsyncd.secrets
max connections=8

Der Parameter path gibt den lokalen Pfad an, unter dem die bereitgestellten Daten liegen, die Parameter uid und gid legen fest, unter welcher Nutzer/Gruppen-Kombination die Daten abgelegt werden. auth users legt fest, welche Nutzer Zugriff auf das Modul haben. secrets file spezifiziert die Datei, in der zeilenweise die Zugangsdaten für die berechtigten Nutzer enthalten sind, das Format ist <nutzername>:<passwort> (z.B. foo:bar). Da die Daten im Klartext in dieser Datei stehen, muß sie entsprechend gegen unberechtigten Zugriff gesichert werden.

Eine genaue Beschreibung aller Parameter findet sich in der Manpage.

Schritt 5: Zugriff auf den Backup-Server

Um von einem anderen Rechner im Netzwerk auf den rsync-Daemon zugreifen und lokale Daten dorthin sichern zu können, muß rsync auf dem Client in folgender Weise aufgerufen werden:

rsync -axv [--password-file \
    ] [--delete]  @::

Der Parameter quelle gibt hierbei die lokale Datenquelle an, nutzername den auf der Daemon-Seite festgelegten Benutzer, zielhost den Namen oder die IP-Adresse des rsync-Daemons und modul schließlich das dort konfigurierte Modul, auf das zugegriffen werden soll. Das Paßwort wird interaktiv abgefragt oder kann bspw. für die Nutzung als Cronjob mit Hilfe des Parameters password-file angegeben werden. Die Datei enthält das Paßwort des Benutzers im Klartext und muß auch hier entsprechend gesichert werden.

Beispiel für den Aufruf:

rsync -axv /mnt/data foo@rsync-host::disk1

11 Kommentare zu “NSLU2 als Backup-Server

  1. Netter Artikel … und recht ausführlich. Leider scheiterts bei mir am Gerät – denn das hatte ich vor einem jahr bereits aus den Händen gegeben. Derzeit reicht mir mein „Server“ … ich denke ich werde dazu auch mal einen kleinen Bericht schreiben 🙂

  2. Nun ja, ich habe die ganzen Flüche ausgespart, von daher… nicht ganz soo ausführlich 🙂
    Langsam kann ich verstehen, warum manche Leute Linux als Frickelei bezeichnen. Man, ist das schlimm, die richtigen Stellen für die Konfiguration zu finden. Ich sag nur: Hostnamen an zwei Stellen ändern…
    Da lob ich mir mein FreeBSD-System, da weiß man genau, wo man drehen muß, damit alles klappt. Und dabei handelt es sich um genau zwei mögliche Orte mit Konfigurationsdateien und nicht zig verschiedene…

  3. Netter Artikel!

    @Firefox: Ich weiss zufällig wem du das Teil gegeben hast 😉
    Ich kanns dir gern wiedergeben wenn du willst, hab bisher auch keine Verwendung dafür.

  4. @Marcus: Wie jetzt? Nicht mal nach dem Lesen dieses Artikels?? 😉

  5. Hi,

    neben dem reinen Backup-Server ist eine SLUG noch für andere Sachen zu gebrauchen: NFS, Samba, iTunesServer (mt-dappd).

    Ich habe allerdings als Firmware Debian Etch verwendet und da muss man nirgenswo den Hostnamen zweimal eingeben und die Einrichtung erschien mir einfacher als bei deinem Artikel.

  6. Mein Problem bestand zumindest bei der originalen NSLU2 darin, dass sie nicht zuverlässig war. Ständiger Verlust beim Schreiben, wenn etwas mehr an Daten übertragen wurde und auch die Limitierung an bestimmte Dateisysteme (von wegen schnell mal Anschließen, Dateien schreiben und wieder an PC anschliessen).
    Hat sich in der Sache schon was getan mit der SLUG? Ist das USB dort zuverlässiger?

  7. @André: Für alle anderen Dienste ist mein „dicker“ Server zuständig, mt-daapd, MusicPD, netatalk (das lööft da wenigstens 😉 ), Samba, OpenVPN, usw. Damit wollte ich die kleine Kiste jetzt nicht auch noch belasten. 🙂
    Ich habe mich bewußt gegen Debian entschieden, damit nicht der zweite USB-Port für das System (bzw. Teile davon auf ner externen Platte) verloren geht. So habe ich ohne Zusatzgerümpel ein vollständiges, lauffähiges System auf der NSLU2.

    @Firefox: Also ich kann bisher nichts Negatives berichten, was das Schreiben angeht, ich erwarte jedoch, daß rsync mich darüber auch ggf. informiert… Ansonsten schnurrt die Kiste. Sie ist nur an Wochenenden an, um das wöchentliche Backup in Empfang zu nehmen. Und sowohl die NSLU2 als auch die angeschlossene Platte verrichten ihren Dienst bisher ohne Probleme.
    Das mit den Dateisystemen stört mich derzeit nicht wirklich. Auf der Platte ist ein ext3 drauf, ansonsten bräuchte ich ja nur UFS2 (FreeBSD) bzw. HFS+ (Apple). Das Windows-Zeug läßt mich mittlerweile sowas von kalt… Und sowohl der Server als auch die Macs kommen mit ext3 klar, also alles kein Problem, wenn ich mal die Platte umstöpseln muß…

  8. Sehr ausführlicher Bericht. Ich habe auch ein NSLU2 mal mit einem Linux aufgespielt, aber hatte die Festplatte anderweitig verwenden müssen und werde demnächst mal mein Gerät wieder flashen. Hab es diese Woche wieder auf Auslieferungszustand geflasht um bei Null anfangen zu können.

  9. Hallo,

    ich bin durch Zufall auf Deinen Bericht gestoßen, weil ich meine NSLU mir rsync ausrüsten wollte.

    Das Openwrt und kamikaze konnte ohnen Probleme installiert werden, ein webinterface ist ja auch dabei.
    Aber kann es sein, dass das Webinterface nicht speziell für die NSLU gedacht ist und mehr anbietet, als die NSLU kann?

    Ich werde mal versuchen mich durchzulesen, würde mich aber über eine kurze Erklärung freuen :-).

    Gruss,
    Andre

  10. Das Webinterface habe ich deaktiviert, da der Webserver – auch wenn er winzig ist – Performance frißt, die man auf dem Gerät woanders gebrauchen kann. Ich bin an der Stelle etwas fetischistisch veranlagt und mache alles per SSH-Login an der Konsole. 🙂

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

*