Der, Anfang des Jahres aufgebaute, Homeserver Nibbler hat sich gut in die Gruppe integriert und ist stets hilfsbereit.

Das, oder so ähnlich, hätte auf seinem Zeugnis gestanden. Anfang des Jahres habe ich den Homeserver „nibbler“ aufgebaut (siehe hier, hier, hier, hier auch und hier) über den ich hier kurz ein Fazit abgeben möchte. In den letzten Monaten habe ich mal mehr und mal weniger an der Kiste herumgebastelt. FreeBSD als Betriebssystem fühlt sich sehr angenehm an und ich werde in nächster Zeit wohl auf kein anderes OS setzen. Es ist klar strukturiert, einfach zu administrieren und macht mir irgendwie mehr Spaß als der Ubuntu Server und der SuSE Enterprise Server.

Neben seinem eigentlichen Zweck, als redundantes Behältnis für meine Daten zu dienen, erfüllt Nibbler jetzt noch weitere nützliche Zwecke. Er dient als Datenzuspieler für die Plex Installation im Wohnzimmer. Plex läuft meinem MacBookPro, welches am TV via HDMI angeschlossen ist und greift über einen AFP Share auf den Server zu. Full-HD Inhalte jeglicher Art werden ohne Probleme abgespielt, die sich Plex über eine 1Gbit Leitung vom Server holt. Ich kann Plex an dieser Stelle uneingeschränkt empfehlen. In einem späteren Post über mein Heimkino werde ich noch einige Worte darüber verlieren.

Weiterhin dient der Server noch als OpenVPN Server mit dem ich von überall aus in mein heimisches Netzwerk komme und in unsicheren WLANs auch ungestört surfen kann. Praktisch ist der auch somit einfache Zugriff auf meine TimeCapsule. Einziger Wermutstropfen ist die langsame Internetverbindung zu Hause, was das Kopieren von größeren Dateien über das VPN eigentlich unmöglich macht. Zum Surfen reicht es aber noch aus.

Der Stromverbrauch liegt im Schnitt bei ca. 60W. Unter Volllast zeigt mir das Messgerät meist 80W – 100W an. Damit ich immer auf dem Laufenden bin, was auf dem Server passiert setze ich Munin ein. Ein nettes Tool was mir die verschiedensten Parameter als Graphen darstellt. Weiterhin berichtet mir Nibbler über Twitter, ob bei den regelmäßigen Portaudit Checks Probleme aufgetreten sind. Alles in allem bin ich sehr zufrieden.

Habt ihr einen Homeserver? Wofür setzt ihr ihn ein?

„You must use a Java 1.5 runtime to use GWT Hosted Mode on Mac OS X.“

Nun ja, mit Snow Leopard wird Java 1.6 ausgeliefert. Auch wenn in Eclipse zusätzlich Java Version 1.5 angezeigt wird, sollte man sich davon nicht täuschen lassen. Das sind Symlinks auf Java 1.6. Im Issue Tracker von GWT wird dieses Problem beschrieben und auch Quick Hacks zum Besten gegeben. Zusammenfassend gebe ich hier mal eine kleine Anleitung die auf einem Blogeintrag im Lombardi Development Blog basiert. Das Schöne ist, dass kein Nachinstallieren von Java 5 nötig ist.

Die Validierung, ob Java 1.5 vorhanden ist, geschieht in der BootStrapPlatform.class, speziell in der Methode isJava5(). Diese wird nun überschrieben, sodass sie immer „true“ zurückgibt. Dafür wird im GWT Projekt ebenfalls die Klasse BootStrapPlatform angelegt. Dabei ist zu beachten, auch das Paket beizubehalten (com.google.gwt.dev). Nun wird der Quellcode der Klasse aus der gwt-dev-mac.jar kopiert und ändert die Methode isJava5() so, dass sie immer „true“ zurückgibt. Anschließend wird in der Run Configuration des Projektes der VM das Argument „-d32″ mitgegeben. Nun sollte der Hosted Mode unter Mac OS X Snow Leopard mit Java 1.6 laufen.

Ich hatte vor dem Kauf meines Netbooks mal ein Auge auf verfügbare Distributionen die auf Netbooks ausgelegt sind angeschaut. Als erstes kam da Ubuntu Netbook Remix (UNR) auf den Plan. Also VirtualBox angeworfen, UNR runtergeladen und erstmal festgestellt, dass UNR als *.img Datei daherkommt um von Flash geladen zu werden, und in VirtualBox nicht eingebunden werden kann. Naja, eine kurze Suche brachte die Lösung.

Erstmal aus dem IMG ein VDI von dem gebootet werden kann erstellen:
VBoxManage convertfromraw ubuntu-9.04-netbook-remix-i386.img ubuntu-netbook-live.vdi

Dann eine Festplatte erstellen auf der genügend Platz ist:
VBoxManage createhd -filename ubuntu-netbook-hd.vdi -size 8000 -register

Als nächstes in VirtualBox eine VM erstellen, die als Primary Master die Live VDI hat (ubuntu-netbook-live.vdi) und als Primary Slave die ‘normale’ HD (ubuntu-netbook-hd.vdi). Beim booten der VM wird dann auf den Slave installiert. Ich habe dazu eine Partition auf dem Slave mit ext4, und eine swap erstellt.

Das war es auch schon.

#!/usr/local/bin/bash
process="foo"
user="you"
password="your_password"
message="@$user $process is done!"
twitter_url="http://twitter.com/statuses/update.xml"

num_procs=`ps ax | grep $process | grep -v grep | wc -l`
if [ $num_procs -eq 0 ]; then
  curl --basic --user "$user:$password" \\
       --data status="$message" $twitter_url -o /dev/null
fi

Kurz zur Erklärung: num_procs enthält die Anzahl der Prozesse in denen im Aufrufbefehl der Inhalt von process vorkommt. Ist die Anzahl 0 wird curl benutzt um mit der Twitter API einen Tweet über basic authentication (--basic) und im Klartext (--data) abzuschicken. Die Logindaten sind dabei in user und password einzutragen.

Das Skript dann noch in die cron eintragen und fertig.

In Gebieten mit vielen Bäumen, wo das iPhone keine „direkte Sichtverbindung“ zum Firmament hatte war der Empfang eher spärlich und der blaue Punkte wanderte im Umkreis von 50 Metern auf der Karte herum. Suboptimal. Zurück zu Hause war dann eigentlich schon klar was passieren würde. Ich schaute mir etliche GPS Empfänger an. Ich landete relativ schnell bei Garmin und mir entging natürlich auch nicht der Wink mit dem Marketing-Zaunpfahl „Geocaching-ready“ bei fast allen Geräten. So weit so gut.

Was den Entscheidungsfindungsprozess beschleunigte war die Tatsache, dass man anstatt der kommerziellen kostenpflichtigen Karten von Garmin auch freies Kartenmaterial vom OpenStreetMap Projekt benutzen kann. Also hab ich ein GPS Empfänger noch schnell auf die „Things-a-geek-should-have“-Liste geschrieben und mir ein Garmin eTrex Vista HCx schon mal vorab zum Geburtstag geschenkt. Und mit ein bisschen Shoprecherche hab sogar noch 40% Prozent vom Herstellerpreis gespart. Jetzt gilt es abzuwarten bis der Postbote ein Paket vorbeibringt.

Ich kann jedem nur empfehlen Geocaching mal auszuprobieren. Ihr seht nicht nur eure Umgebung aus einem ganz anderen Blickwinkel, es wird euch garantiert der Ehrgeiz packen von einem Ort an dem ein Schatz liegen soll abzuziehen ohne ihn gefunden zu haben. Ich spreche aus Erfahrung.

# cd /usr/ports/net/netatalk && make install clean

Dann den AFP Dienst für den Start beim Boot anschalten, in der /etc/rc.conf:

slpd_enable="YES"
netatalk_enable="YES"
atalkd_enable="YES"
papd_enable="NO"
cnid_metad_enable="YES"
afpd_enable="YES"
timelord_enable="NO"

Nach einem Neustart wurde ich dann mit der Fehlermeldung „main: atp_open: Protocol not supported“ konfrontiert. Damit netatalk funktionert muss der FreeBSD Kernel mit einer zusätzlichen Option neu kompiliert werden.

Kernel rekompilieren

Um den Kernel zu kompilieren werden die Sources benötigt: Am schnellsten geht das über sysinstall -> Distribution -> src -> All. Für den Kernel gibt es für jede Architektur eine Konfigurationsdatei. In meinem Fall auf einem 64 Bit System befindet sich die Konfiguration des Standardkernels unter /usr/src/sys/amd64/conf. Um nun den Kernel zu kompilieren wird die Standardkonfiguration GENERIC kopiert und angepasst.

# mkdir /root/kernels
# cd /usr/src/sys/amd64/conf
# cp GENERIC /root/kernels/GENERICMOD
# ln -s /root/kernels/GENERICMOD

Der Konfiguration GENERICMOD wird nun folgender options Eintrag hinzugefügt:

options   NETATALK   # AppleTalk

Bevor ich den Kernel neu kompiliere und installiere, habe ich noch eine Sicherung des aktuellen Kernels angelegt. Für alle Fälle.

# cp -r /boot/kernel /boot/kernel.working

Und nun noch den Kernel kompilieren und installieren:

# cd /usr/src
# make buildkernel KERNCONF=GENERICMOD
# make installkernel KERNCONF=GENERICMOD
# reboot

Der neue Kernel sollte nun beim Booten verwendet worden sein und netatalk dürfte nun auch laufen.

Share für Netatalk konfigurieren

Zu diesem Zeitpunkt sollte der AFP Dienst laufen.

# slptool findsrvs afp
afp://192.168.0.30/?NAME=nibbler&ZONE=,65535

Ja macht er.

Unter /usr/local/etc/AppleVolumes.default werden die Freigabe definiert, die über AFP zugreifbar sein sollen.

/tank tank options:usedot,noadouble,nohex cnidscheme:cdb

Da ich auch ein SVN betreiben werde, ist die option „usedot“ hilfreich, da somit auch .files möglich sind. Der cnidscheme ist zwar der Standardname, verhindert aber unnötige Fehlermeldungen.

Nun lässt sich der ZFS pool schonmal über den Finder mounten (CMD+K): afp://nibbler/tank

Share über Bonjour

Da ich nicht jeden Tag Lust habe über den Finder den pool zu mounten, wäre es ja schön wenn der Home Server direkt im Finder unter Freigaben auftauchen würde. So wie die TimeCapsule auch.

Für FreeBSD habe ich da in den Ports „howl“ und „avahi“ als Bonjour Implementationen gefunden. Ich habe jetzt erstmal zu avahi gegriffen:

cd /usr/ports/avahi && make install clean

Nach der Installation noch in der /etc/rc.conf einschalten:

dbus_enable="YES"
avahi_enable="YES"

Im Ordner /usr/local/etc/avahi/services befinden sich, im XML Format, Definitionen für Dienste die über Bonjour veröffentlich werden sollen. Für AFP (afpd) einfach eine weitere Definition hinzufügen (afpd.service):

<?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=Xserve</txt-record>
  </service>
</service-group>

Mit _device-info kann man angeben als was sich der Dienst ausgeben soll. Da macht sich das Icon des Xserve im Finder natürlich recht schick. Interessant wäre irgendwie ein eigenes Icon an diese Stelle zu zaubern. (Das Icon des Xserver austauschen zählt nicht.)

Das ist eine sehr komfortable Lösung bis jetzt. Die Schreibgeschwindigkeiten bewegen sich mit netatalk im Rahmen von 30-50MB/sec. Das ist zwar nicht Weltklasse, aber wenn man bedenkt, dass ZFS gleichzeitig noch die Paritätsdaten schreibt, bin ich für mehr Sicherheit bereit ein wenig Geschwindigkeit einzubüßen.

Dann den raidz Pool aus den drei 1TB Platten gemacht:

# zpool create tank raidz ad6 ad8 ad12

Jetzt werden die Daten auf zwei von den drei Platten abgelegt, und die Paritätsdaten für das RAID auf der dritten Platte. Somit bleiben von den insgesamt 2,72TB effektiv 1,8TB übrig.

Die Filesystems:

# zfs create tank/backup
# zfs create tank/backup/timecapsule
# zfs set reservation=500GB tank/backup/timecapsule
# zfs set atime=off tank

Durch die Reservierung von 500GB auf dem Dateisystem „timecapsule“ bleiben dem Elterndateisystem „tank“ noch 1,3TB zugesicherter Speicherplatz übrig. Dies bedeutet, dass im „df -h“ „tank“ mit 1,3TB verfügbarem Platz angezeigt wird, als auch für dessen Kinder, und für „timecapsule“ 1,8TB. Das Property „atime“ habe ich erstmal für den gesamten pool abgeschaltet, da es nach ZFS Admin Guide unnötige Schreibzyklen verhindert und somit zu, wenn auch minimalen, Performanceverbessungen kommen kann.

Ja wie man an der Länge dieses Beitrags sieht, ist der Administrationsaufwand für einen ZFS pool nicht sonderlich hoch.

Bei einem ersten schnellem Test, habe ich per scp Dateien auf den pool kopiert. Bei einem 1GBit Netzwerk hatte ich mit ca. 60MB/sec gerechnet. Raus kam aber 10-20 MB/sec. Die erste Ernüchterung. Über NFS ging es auch nicht sonderlich schneller (zwischen 10 und 30 MB/sec). Im Netzwerkbenchmark mit iperf kam ich auf 740Mbit/1000Mbit und einer theoretischen Übertragungsrate von 89MB/sec. Da ich hier im Netzwerk eigentlich nur Macs habe habe ich mich entschieden es dann noch mit AFP zu versuchen. Doch dazu mehr im nächsten Beitrag.

Den aktuellen Netzwerktraffic kann man sich unter FreeBSD übrigens mit

# systat -ifstat 1

anzeigen lassen.

Links:

• http://wiki.freebsd.org/ZFSQuickStartGuide
• http://wiki.freebsd.org/ZFSTuningGuide
• http://docs.sun.com/app/docs/doc/819-5461?l=de

Nach dem ersten Boot, schaute ich gleich ins BIOS um sicherzustellen, dass alle Platten korrekt erkannt wurden und sonst alles okay ist. Die SATA Konfiguration stand auf „SATA“ (es gibt noch RAID und AHCI als Auswahlmöglichkeiten) und alle Platten, sowie Laufwerk wurden korrekt an ihren SATA Ports erkannt. Also FreeBSD Boot CD rein und los gehts.

Pustekuchen. Beim Starten der Boot CD ging es nach „run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config“ nicht mehr weiter. Nach etwas googeln auf der FreeBSD Mailingliste stellte sich heraus, dass es ein spezifisches Problem mit genau diesem Asus Board ist. Abhilfe schaffte nur das Abschalten von Firewire im BIOS. Nach einem Reboot konnte ich dann von der CD starten und die Installation beginnen.

Pustekuchen mit Streusel. Der Kernel, der für die Installationsroutine benutzt wird, fand beim ersten Anlauf nur zwei der vier Platten (2x 1TB), was mich stutzig machte. Je nach dem wie ich die Platten auf dem Board anschloß bekam ich immer andere Plattenkombinationen im sysinstall. Jedoch nie alle vier Platten. So zurück im BIOS habe ich mir die SATA Konfiguration noch mal angeschaut. Zu AHCI gab es den Hinweis: „When enabled BIOS finds only SATA ports 1-4. Install AHCI drivers in OS to use all six ports.“. Deshalb habe ich darauf verzichtet, weil ich dachte, wenn ich nicht mal im BIOS alle SATA Ports benutzen kann, wird das bei der Installation nicht hilfreich sein. Da aber FreeBSD mit Sicherheit AHCI Treiber hat, habe ich im SATA Modus (mit nur zwei Platten) installiert und danach auf AHCI umgestellt, und (TADA!) alle vier Platten waren da: ad4, ad6, ad8 und ad12.

Na dann kann es ja losgehen.

Mein erster Gedanke war, dass das Netzteil kaputt sein könnte. Also Netzteil raus und an einem anderen PC getestet. Funktioniert. Ok (Den genauen Wortlaut meiner Gedanken zu dem Zeitpunkt erspare ich mir hier)! Nachdem auf dem Mainboard nur noch die CPU und ein RAM Riegel drauf waren ging der Server immer noch nicht an. (Ohne RAM ebenfalls nicht.)

Meine Schlussfolgerung ist jetzt, dass das Mainboard kaputt ist. RMA ist eingeleitet.

Hmpf.

Die Ausgangssituation:

freebsd# df -h
Filesystem Size Used Avail Capacity Mounted on
/dev/ad4s2a 3.9G 1.7G 1.8G 49% /
devfs 1.0K 1.0K 0B 100% /dev
tank 9.8G 365M 9.4G 4% /tank

freebsd# zpool list
NAME SIZE USED AVAIL CAP HEALTH ALTROOT
tank 9.94G 365M 9.58G 3% ONLINE -

freebsd# ls /tank
test.sparsebundle

Wie man sieht, habe ich ein FreeBSD welches auf der Festplatte ad4s2a läuft und einen pool (mirror aus zwei Festplatten) der unter /tank gemountet ist und mit 365MB belegt ist. Diesen exportieren wir nun, damit er abgemountet und als exportiert markiert wird:

freebsd# zpool export tank

freebsd# zpool list
no pools available

Der ZFS mirror ist nun nicht mehr im System gemountet. Nun kann man die Festplatten herausnehmen und woanders platzieren.

Zurück im OpenSolaris suchen wir nun nach zpools die importiert werden können:

root@opensolaris:~# zpool import
pool: tank
id: 13746911421668436261
state: UNAVAIL
status: One or more devices contains corrupted data.
action: The pool cannot be imported due to damaged devices or data.
see: http://www.sun.com/msg/ZFS-8000-5E
config:
tank UNAVAIL insufficient replicas
mirror UNAVAIL insufficient replicas
c5t0d0s8 UNAVAIL corrupted data
c5t1d0s8 UNAVAIL corrupted data

Oops. Was ist hier passiert? Also das FreeBSD läuft unter Version 7.1 mit ZFS in Version 6. OpenSolaris in Version 2008.11 und ZFS Version 13. Könnte hier das Problem liegen? Ein erzwungener Import (zpool import -f) funktionierte ebenfalls nicht. Ich werde mal ein FreeBSD 8.0 aufsetzen, welches ebenfalls ZFS in Version 13 hat, um zu sehen ob es dann klappt.

Wenn jemand eine Idee hat wie es unter FreeBSD 7.1 / OpenSolaris 08.11 geht, immer her mit den Tipps!

Links:

• Migrating ZFS Storage Pools (sun.com)