Zevo gibt es in drei Editionen mit unterschiedlich vielen Features. So wird in der Silver Edition nur das ZFS selbst bereit gestellt, die Gold Edition bietet dann auch Snapshots, Raidfunktionen und Kompression und in der Ultimate Variante bekommt man dann auch Deduplication, RAIDZ und eine GUI zur Verwaltung gestellt.

Die Frage nach der Version stellt sich derzeit allerdings noch nicht, da es derzeit nur die Silver Edition für knapp 20€ zu kaufen gibt. Aber man kann später jederzeit upgraden. Inwieweit dies notwendig ist wird sich zeigen, denn wahrscheinlich sind die Features unter der Haube schon eingebaut aber über die Oberfläche nicht erreichbar.

Der Einkauf ging sehr einfach per PayPal und anschließendem Download und so konnte ich nach 3 Minuten loslegen.

Man benötigt Mac OS X 10.6.6 oder 10.7.2 und neuer, 2GB RAM und 25 MB Plattenplatz auf dem Systemlaufwerk. Besser sind 4GB RAM und eine 64Bit CPU. Aber das wird auch bei anderen Betriebsystemen wie FreeBSD empfohlen. Und man benötigt eine einzelne Fesplatte oder USB-Stick, denn Zevo kann nicht auf der Systemplatte verwendet werden.

Die Installation ist soweit unspektakulär, als das man sie einfach nur durchklickt und anschießend den Mac neu startet.

Und schon kann man auf ZFS-Dateisysteme unter Mac OS X zugreifen. Ich sollte kurz erwähnen, dass sich die Entwickler mit ihrem Support sehr zurück halten und auch keinerlei Garantien für Fehlerfreiheit geben. Im Quick-Start-Guide steht dazu:

To ensure that your data is protected and to prevent any loss of data, we strongly recommend that you keep at least two copies of your data at all times. Keep one copy using your ZEVO storage and a second copy on another storage medium, such as another hard disk or a cloud backup service.

Dies sollte man sicher in einer so frühen Version ernst nehmen. Zum Testen habe ich einen leeren 8GB großen USB-Stick hergenommen und diesen über Zevo mit ZFS formatiert.

Dies geschieht über den neu hinzu gekommenen Menüpunkt in den Systemeinstellungen von Mac OS X. Man wird hierbei nur nach der zu formatierenden Fesplatte gefragt und ob man Groß- und Kleinschreibung bei Datei- und Verzeichnisnamen berücksichtigt werden soll.

Ich habe mich für die Unix-Variante entschieden, da ich den Stick ja auch unter FreeBSD testen möchte. Und aus Gewohnheit.

Und schon hat man ein ZFS-Dateisystem auf seinem Stick.

zfs list
NAME USED AVAIL REFER MOUNTPOINT
Zevo 428Ki 6,95Gi 366Ki /Volumes/Zevo

Dies sind die Standardoptionen des angelegten Dateisystems:

zfs get all Zevo
NAME PROPERTY VALUE SOURCE
Zevo type filesystem -
Zevo creation Di Jan 24 23:00 2012 -
Zevo used 428Ki -
Zevo available 6,95Gi -
Zevo referenced 366Ki -
Zevo compressratio 1.00x -
Zevo mounted yes -
Zevo quota none default
Zevo reservation none default
Zevo recordsize 128Ki default
Zevo mountpoint /Volumes/Zevo default
Zevo checksum on default
Zevo compression off local
Zevo atime on default
Zevo devices on default
Zevo exec on default
Zevo setuid on default
Zevo readonly off default
Zevo snapdir visible local
Zevo aclinherit restricted default
Zevo canmount on default
Zevo copies 1 local
Zevo version 5 -
Zevo utf8only off -
Zevo normalization none -
Zevo casesensitivity sensitive -
Zevo refquota none default
Zevo refreservation none default
Zevo primarycache all default
Zevo secondarycache all default
Zevo usedbysnapshots 0 -
Zevo usedbydataset 366Ki -
Zevo usedbychildren 63Ki -
Zevo usedbyrefreservation 0 -
Zevo logbias latency default
Zevo dedup off default
Zevo sync standard default

Es handelt sich hierbei um ZFS-Version 28:

zpool upgrade -v
This system is currently running ZFS pool version 28.


Und das ganze ist nativ, also ohne Umwege über FUSE gemountet.

mount
/dev/disk1 on / (hfs, local, journaled)
devfs on /dev (devfs, local, nobrowse)
map -hosts on /net (autofs, nosuid, automounted, nobrowse)
map auto_home on /home (autofs, automounted, nobrowse)
/dev/disk3 on /Volumes/Zevo (zfs, local, journaled)

Beim Trennen und Mounten wird man übrigens per Growl entsprechend informiert.

Nun aber zur Nutzbarkeit. Ich habe den Stick eingesteckt und wollte testweise einmal das Lion-Image von 4 GB Größe auf den Stick kopieren. Das habe ich dann aber abgebrochen, da es ungefähr 3 Stunden gedauert hätte. Hmpf.

OK, backen wir erstmal kleinere Brötchen. Also habe ich für meinen zweiten Anlauf eine ISO-Datei von nur 118 MB Größe hergenommen. Das war immerhin in drei Minuten erledigt.

Nun wollte ich mal Deduplication auf dem Stick testen.

sudo zfs set dedup=on Zevo
cannot set property for 'Zevo': data deduplication property requires a 64-bit kernel and 8 GB RAM

Schade, mein MacBook Air hat leider nur 4 GB.

Nun möchte ich die Daten aber auch unter anderen Bestriebssystemen nutzen. Also den Stick unter Windows angeschlossen – kleiner Scherz. Also den Stick unter FreeBSD angeschlossen und gemountet.

# zpool import -o rw Zevo


Und zum Test die eben auf den Stick kopierte Datei auf die Platte bewegt.

# mv /Zevo/mfsbsd-se-9.0-amd64.iso /usr/home/oliver/mfsbsd.iso


Deduplication hat mich allerdings dann doch nicht losgelassen. Ich wollte es haben. Also unter FreeBSD mal angeschaltet.

# zfs set dedup=on Zevo
# zfs set compression=on Zevo
# mkdir /Zevo/iso{1,2,3}
# time cp /usr/home/oliver/mfsbsd.iso /Zevo/iso1
# 0.000u 0.130s 1:41.97 0.1%
# time cp /usr/home/oliver/mfsbsd.iso /Zevo/iso2
# 0.0006u 0.085s 0:04.87 1.6%
# time cp /usr/home/oliver/mfsbsd.iso /Zevo/iso3
# 0.007u 0.308s 0:00.31 96.7%


Man sieht, dass ZFS sofort registriert, dass die Datei bzw. gleiche Blöcke im Dateisystem vorhanden sind und somit nicht kopiert werden müssen, was wiederum die Dauer des Kopiervorgangs von fast 2 Minuten auf wenige Sekunden drückt. Weil ja auch nichts kopiert wird.
Nun nochmal auf den Speicherverbrauch geschaut:

# df -h | grep Zevo
# Zevo 7.2G 338MB 6.9G 5% /Zevo

Mit df sieht alles noch aus wie immer. Man benötigt ja auch zpool um den wirklich verbrauchten Speicher zu ermitteln. Nähere Informationen dazu kann man bei Jeff Bonwick und bei Jörg Möllenkamp nachlesen.

# zpool list | grep Zevo
# Zevo 7.06G 114M 6.95G 1% 3.00x ONLINE -

Das sieht schon besser aus. Man sieht, dass in Wirklichkeit nur 114MB belegt sind, also das ISO-Image nur einmal auf dem Stick vorhanden ist.

Wieder zurück zum Mac. Also Stick umounten unter FreeBSD:

# zpool export Zevo


Auf dem Mac wird das Dateisystem sofort gemountet und auch richtig behandelt – also auch Deduplication bleibt aktiv.

zpool list
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT
Zevo 7,06Gi 123Mi 6,94Gi 1% 2.99x ONLINE -

Das ganze lief bei mir auch mit 4GB RAM stabil. Allerdings sind auch nicht wirklich viele Daten, die in diesem kleinen Test verarbeitet werden müssen.

Was aber, wenn doch mal etwas schief geht? Man kann die Daten der ZFS-Dateisysteme mittels dem mitgelieferten Checkup prüfen, welcher ebenfalls unter den Systemeinstellungen zu finden ist. Und siehe da, es hatte auch direkt einen Fehler gefunden, der leider auch nicht korrigiert werden konnte. Ok ich hatte etwas nachgeholfen.

Diesen Check kann man übringens auch in der Konsole mit folgendem Befehl starten.

sudo zpool scrub Zevo

Mehr Informationen liefert auch zpool status:

sudo zpool status -v
pool: Zevo
state: ONLINE
status: One or more devices has experienced an error resulting in data corruption. Applications may be affected.
action: Restore the file in question if possible. Otherwise restore the entire pool from backup.
scan: scrub repaired 0 in 0h0m with 1 errors on Wed Jan 25 09:32:33 2012
config:
NAME STATE READ WRITE CKSUM
Zevo ONLINE 0 0 2
GPTE_857D267E-575C-4CF8-A737-B06AC37BFB20 ONLINE 0 0 4 at disk2s2
errors: Permanent errors have been detected in the following files:
Zevo:/mfsbsd-se-9.0-amd64.iso

Soweit ein erster Rundgang durch ZFS unter Mac OS X. Und wie man sieht, sind einige Features unter der Haube vorhanden, welche nur durch die GUIs nicht abgedeckt werden. Die kommenden Editionen sind somit eventuell überflüssig, wenn man mit dem Terminal umgehen kann. Auf jeden Fall eine schöne Sache, dass es endlich eine ordentliche Unterstützung unter Mac OS X für ZFS gibt. Wie sind eure Erfahrungen und Eindrücke mit Zevo?

Man kann die Panel aber durch Zurücksetzen per Konsole wiederherstellen ohne sich aus- und wieder einloggen zu müssen. Dazu öffnet man unter Debian oder Ubuntu die Konsole mittels der Tastenkombination Strg+Alt+T und gibt den folgenden Befehl ein.

pkill gnome-panel

Und schon ist wieder alles an seinem Platz. Weitere hilfreiche Tipps gibt es im Wikieintrag zu Gnome von ubuntuusers.de.

Nur so als Vorschlag.

• ZFS in Version 28 mit Deduplikation und RAIDZ3
• Fast Filesystem mit Softupdates
• Trim-Funktion für SSDs
• Unterstützung von LLVM wurde hinzugefügt
• High Performance SSH
• USB 3.0 wird unterstützt und es gibt einen USB-Paketfilter
• DTrace für Anwenderprogramme
• neues Installationsprogramm (noch ohne ZFS-Unterstützung)

RCTL, Capsicum, HAST und vieles andere mehr, was man in den Release-Notes nachlesen kann. Das Wochenende kann also kommen.

(via f!xmbr | pl | heise| bsdmag)

Auf der zsh vom GRML angekommen habe ich erstmal die Partitionen gemäß des zu klonenden Systems angelegt.

fdisk /dev/sda

Also eigentlich war es nur eine Systempartition und eine Swap-Partition. Da es um eine Kopie der Daten und nicht der Dateisysteme ging konnte ich die Datenpartition auch größer anlegen. An dieser Stelle kann man die gesamte Partitionsstruktur ändern und Partitionen weglassen oder neue hinzufügen. Man muss nur darauf achten, dass die Daten auch noch in die jeweiligen Ziel-Partitionen passen.

Nun erzeugt man in den erstellten Partitionen die Dateisysteme. In meinem Fall war dies nur die eine Systempartition.

mkfs.ext4 /dev/sda1

Das erzeugte Dateisystem habe ich anschließend gemountet und in dieses gewechselt. Bei mehreren Partitionen müssen diese natürlich entsprechend unterhalb der neuen Root-Partition gemountet werden.

mkdir -p /mnt/sda1
mount /dev/sda1 /mnt/sda1
cd /mnt/sda1

Nun kam der eigentlich wichtige Schritt: das kopieren der Daten. Man sollte auf dem zu klonenden System möglichst alle wichtigen Dienste stoppen, um Inkonsistenzen in den Daten zu vermeiden. Also schaltet man alle laufenden Webserver, Mailserver, etc. ab. Nur der SSH-Server muss noch laufen. Und schon kann der Kopiervorgang aus der GRML-Instanz heraus gestartet werden.

ssh root@OriginalSystem "tar czf - --exclude /proc /" | tar xvzf -

Dieser Aufruf kopiert alle Daten außer das /proc-Pseudo-Dateisystem in das aktuelle Verzeichnis, also auf die neue Platte. Zeit für einen Kaffee. Oder zwei – je nach Plattengröße und Netzwerk.

Wieder zurück, muss das kopierte Linuxsystem noch an die neue Hardwareumgebung angepasst werden. Dafür begeben wir uns in eine chroot-Umgebung innerhalb der gerade kopierten Daten. Doch zuerst müssen wir noch einige wichtige Dateisysteme aus der Live-Umgebung in die chroot-Umgebung einhängen.

mount -o bind /dev /mnt/sda1/dev
mount -o bind /sys /mnt/sda1/sys
mkdir -p /mnt/sda1/proc
mount -t proc /proc /mnt/sda1/proc

Jetzt aber rein in die gute Stube.

chroot /mnt/sda1 /bin/bash

Als erstes sollte man den Bootloader neu installieren und konfigurieren, damit man anschließend auch in das neue System booten kann.

grub-install /dev/sda
update-grub

Nun sollte man sich noch die UUIDs der neuen  Partitionen anzeigen lassen und die /etc/fstab entsprechend anpassen.

blkid
vi /etc/fstab

Und schon ist man fertig. Man kann die chroot-Umgebung verlassen, alle Dateisysteme wieder aushängen und neu starten.

exit
cd
umount /mnt/sda1{/dev,/proc,/sys,}
reboot

Hat man nichts vergessen oder falsch gemacht sollte das neue System booten – logisch. Nun kann man sich daran machen, den Hostnamen, das Netzwerk und so weiter anzupassen. Und wer meint, dies sei jetzt aber kompliziert gewesen, der sollte sich mal etwas tiefer mit den Aufbauten und Funktionsweisen von Unix- und Linux-Systemen beschäftigen und dann das gleiche mal mit einem Windows-System probieren.

Und ja, es gibt auch andere schicke Lösungen wie ZFS und Snapshots aber es ging mir ja um den Fall, dass man gerade ein Standard-Linux vor der Nase hat und muss dieses Umziehen. Weitere Fragen, Hinweise und Fehlerkorrekturen bitte in die Kommentare. Und das Backup nicht vergessen!

Sichere Festplattenverschlüsselung, Kernel-Patch, das musste ich mir genauer anschauen. Und natürlich verbloggen. 

Voraussetzung für die Patches sind Linux-Kernel in den Versionen 2.6.36 oder 3.0.9 und ein 64-bit Core-i-Prozessor mit AES-NI. Es funktioniert wohl auch mit einer 32-bittigen SSE2-fähigen CPU aber nur unter Geschwindigkeitseinbußen. Außerdem braucht ihr noch ein aktuelles Backup, denn ich übernehme natürlich keinerlei Haftung, wenn etwas bei euch schief läuft.

In diesem Howto verwende ich den Kernel 3.0.9 auf einem Core i5 unter Ubuntu 11.10 und halte mich vorwiegend an die Anweisungen und Hinweise in der Readme zu Tresor.

Zu Beginn habe ich erst einmal alle Tools installiert, die man zum Bauen eines eigenen Kernels unter Ubuntu benötigt.

sudo apt-get install fakeroot build-essential kernel-package libncurses5-dev

Und natürlich auch gleich den Source-Code des zu kompilierenden Kernels herunter geladen.

wget http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.0.9.tar.bz2

Um an die Standard-Konfiguration von Ubuntu für den unveränderten Linux-Kernel zu kommen, habe ich mir noch den passenden Mainline-Kernel von Ubuntu besorgt. 

wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.0.9-oneiric/linux-image-3.0.9-030009-generic_3.0.9-030009.201111111635_amd64.deb

Und zu guter Letzt natürlich noch den eigentlichen Patch von der Tresor-Webseite.

wget http://www1.informatik.uni-erlangen.de/filepool/projects/tresor/tresor-patch-3.0.9_aesni

Mit den folgenden Befehlen habe ich mir die Ubuntu-Kernel-Konfiguration aus dem Mainline-Kernel extrahiert und in meinem Homeverzeichnis unter kconfig gespeichert.

mkdir ubuconf
cd ubuconf
ar -x ../*.deb data.tar.bz2
tar xf data.tar.bz2 ./boot/config-3.0.9-030009-generic
cp ./boot/config-3.0.9-030009-generic ../kconfig
cd ..
rm -r ubuconf

Wem das zu anstrengend ist, der kann sich die extrahierte Konfiguration auch hier laden und entsprechend speichern.

Jetzt habe ich den Source-Code des neuen Kernels entpackt und ihn mit dem Tresor-Patch versehen.

cd /usr/src
sudo tar xf ~/linux-3.0.9.tar.bz2
sudo patch --directory /usr/src/linux-3.0.9/ -p1 < ~/tresor-patch-3.0.9_aesni

Die vorhin extrahierte Kernelkonfiguration habe ich in das Kernelverzeichnis kopiert und anschließend die Konfigurationsoberfläche gestartet.

cd linux-3.0.9
sudo cp ~/kconfig .config
sudo make menuconfig

Der Tresor-Patch hat einen entsprechenden Konfigurationseintrag (Cryptographic API -> AES cipher, cold boot resistant (TRESOR)) hinzugefügt, welchen man aktivieren muss. Beim Verlassen der Konfigurationsoberfläche wird die Konfiguration in der Datei .config gespeichert.

Ich habe mich für die Kompilierung und anschließender automatischer Erstellung eines Debian-Paketes entschlossen, da man so den Kernel einfach über die Paketverwaltung installieren und auch wieder deinstallieren kann.

sudo make-kpkg kernel_image --initrd --revision 1337

Nun hatte ich Zeit. Viel Zeit. Und anschließend ein sauberes Kernelpaket mit integriertem Tresor-Patch. Das könnt ihr euch übrigens auch hier herunter laden.

Doch bevor ich dies installierte habe ich die Grub-Konfiguration dahingehend abgeändert, dass das Boot-Menü beim starten des Rechners erscheint und man einen Kernel zum Booten auswählen kann und man natürlich die Meldungen vom Tresor-System beim Booten auch zu Gesicht bekommt.

sudo sed -i -e 's/\(GRUB_HIDDEN_TIMEOUT\)/#\1/' /etc/default/grub
sudo sed -i -e 's/splash/nosplash/g' /etc/default/grub
sudo bash -c 'echo "GRUB_GFXPAYLOAD_LINUX=text" >> /etc/default/grub'

Nun noch das Paket installiert und neu gestartet.

sudo dpkg -i ../linux-image-3.0.9_1337_amd64.deb
sudo reboot

Der neue Kernel sollte nun an erster Stelle im Bootmenü auftauchen und wird auch gleich gestartet.

Während des Bootvorgangs wird nun nach einem Passwort gefragt. Dieses ist das Passwort für alle Tresor-basierten Verschlüsselungen. Außerdem wird noch der entsprechende Hash des Passwortes angezeigt. Dieses dient der Verifikation der Eingabe. Dies ist wichtig, da dies die einzige Möglichkeit ist, die Korrektheit der Eingabe zu prüfen. Das System bootet mit jeder Eingabe. Man sollte sich den Hash also irgendwo sichern und sich ein paar Zeichen merken, damit man erkennt, wenn man sich vertippt hat. Sollte man seine Festplatte mit dem Tresor-Patch verschlüsselt haben droht sonst, unter bestimmten Umständen, auch Datenverlust. Deshalb habe ich ein paar kleine Tests mit dem System durchgeführt um ein Gespür für das Verhalten und die Funktionsweise zu erhalten.

Dafür habe ich cryptsetup installiert.

sudo apt-get install cryptsetup

Und eine 256MB große Container-Datei erstellt. Sie dient als Ersatz für eine echte Partition.

dd if=/dev/zero bs=1M count=256 of=container

Die Containerdatei habe ich dann als loop-Device gemountet.

sudo losetup /dev/loop0 container

Nun kann man den Container bzw. die entsprechende Partition mit Tresor und 256-Bit langen Schlüsseln verschlüsseln. Auf 32-Bit-Systemen gehen nur Schlüssel mit 128 Bit Länge. Das abgefragte Passwort ist nicht weiter von Bedeutung, da bei der Verschlüsselung das Tresor-Passwort zum Tragen kommt.

sudo cryptsetup create tresor /dev/loop0 --cipher tresor --key-size 256

Auf der verschlüsselten Partition habe ich nun noch ein Dateisystem angelegt, dieses gemountet und eine Testdatei angelegt. Und anschließend alles wieder verschlossen.

sudo mkfs.ext2 /dev/mapper/tresor
sudo mkdir -p /media/tresor
sudo mount /dev/mapper/tresor /media/tresor
chown oliver /media/tresor
echo "test" >> /media/tresor/test.txt
sudo umount /media/tresor
sudo cryptsetup remove tresor
sudo losetup -d /dev/loop0

Ein erneutes mounten zeigt, dass alles geklappt hat.

sudo losetup /dev/loop0 container
sudo cryptsetup create tresor /dev/loop0 --cipher tresor --key-size 256
sudo mount /dev/mapper/tresor /media/tresor

Hat man beim Booten ein falsches Passwort eingegeben, wird das mounten mit einem Fehler quittiert, da er das Dateisystem nicht erkennen kann, da es ja nicht entschlüsselt werden kann.

mount: you must specify the filesystem type

Das generelle unmounten funktioniert wie oben bereits beschrieben.

sudo umount /media/tresor
sudo cryptsetup remove tresor
sudo losetup -d /dev/loop0

Damit steht nun weiteren Tests im praktischen Einsatz nichts mehr im Wege. Nach dem Backup versteht sich. 

Laut diesem Foren-Thread scheint dieses Problem auch in der Kombination Virtualbox 4.0.10 und Ubuntu 11.04 zu bestehen. Zum Glück wird auch gleich die Lösung des Problems erraten.

Nachdem ich das Netzwerkinterface in den Einstellungen auf nicht verbunden gesetzt hatte, lief die Installation problemfrei durch.

Nach dem Boot ins frisch installierte Ubuntu 11.10 habe ich das Netzwerkinterface wieder virtuell über die Einstellungen verbunden und alles lief wie gewünscht und die System-Updates wurden erfolgreich eingespielt.

Zuerst fügt man die Launchpad-Repositories des Mozilla Teams zur Paketverwaltung hinzu.

sudo add-apt-repository ppa:mozillateam/firefox-stable
sudo add-apt-repository ppa:mozillateam/thunderbird-stable

Anschließend aktualisiert man noch die Paketverwaltung und spielt die Updates und damit auch die neuen Versionen von Firefox und Thunderbird ein.

sudo apt-get update
sudo apt-get dist-upgrade

Funktionierte bei mir problemlos. Dennoch sei an dieser Stelle die Warnung vor externen Paketquellen zitiert:

Zusätzliche Fremdquellen können das System gefährden.

Soweit das kleine Howto, welches wohl eher eine öffentliche Notiz an mich selber darstellt.

Ganz nach meinem Geschmack ist aber die Überarbeitung der Upload-Funktion. Mit der bisherigen Funktion hatte ich immer wieder Probleme. Wenig Probleme hingegen bereitete das Update. Das lief ohne Zwischenfälle durch. Aber man sollte vor dem Update natürlich immer ein Backup machen.

Weitere Neuerungen findet ihr im offiziellen Changelog zu Version 3.3 und in diesem Video.

Ich hoffe ich komme in nächster Zeit auch wieder mal zum bloggen. Habe schon einige Howtos in der Queue…

Wer es selbst mal ausprobieren möchte, der kann bei Mashable über einen Link eine  Einladung zu privaten Beta bekommen.