Marco Gabriel

Btrfs, so könnte man meinen, ist der kommende Star unter den Linux Filesystemen. Bis dahin ist es zwar noch ein weiter weg, denn auch btrfs hat noch einige Baustellen, aber es werden permanent weniger und die Entwicklung schreitet mit großen Schritten voran. Noch 2012 wird Oracle, als Arbeitgeber des Hauptentwicklers Chris Mason, das Filesystem als stabil kennzeichnen und es in der kommenden Version ihres Oracle Linux ganz offiziell supporten. Das alles lässt hoffen. 

Btrfs  hat einige wirklich überzeugende Features und ich möchte einige dieser Features und konkrete Anwendungen dafür in der nächsten Zeit näher vorstellen. Den Anfang mache ich mit den btrfs Snapshots.

Ich habe kürzlich gesehen, wie jemand mit yum unter Oracle Linux vor jeder Installation einen automatischen Snapshot anlegte, um jederzeit wieder darauf zurücksetzen zu können. Das wollte ich für meine Ubuntu Installation ebenfalls. Die Umsetzung war dabei sehr leicht:

/etc/apt/apt.conf.d/70debconf

Dpkg::Pre-Invoke {"mkdir -p /snapshots; ROOTFS=`mount | grep ' on / ' | \
cut -f1 -d' '`; mount $ROOTFS /snapshots; \
/sbin/btrfs subvolume snapshot /snapshots/@ /snapshots/@_snapshot_apt_`date +%Y-%m-%d_%H-%M-%S`; \
umount /snapshots";};

Apt (oder Aptitude) stellt eine Schnittstelle zur Verfügung um Befehle vor einer Paketinstallation auszuführen. Das können auch mehrere Befehle sein, so wie oben angegeben. 

Die Vorgehensweise ist wie folgt:

1. Es wird ein Ordner /snapshots angelegt, sofern dieser noch nicht existiert.
2. Wir finden heraus, welches Device als root gemounted ist
3. Wir schneiden uns den Device Teil heraus und hängen diesen unter /snapshots noch mal ein (btrfs kann das)
4. Ein Snapshot von / wird in /snapshot/@_snapshot_apt_(datum) erzeugt
5. Der Mountpoint /snapshots wird wieder ausgehängt um eine unbeabsichtigte Änderung zu vermeiden.

Da ein solcher btrfs Snapshop nur Sekundenbruchteile dauert, merkt man es bei einer Installation gar nicht, aber der Systemzustand wird festgehalten. Sollte man nach der Installation nun feststellen, dass etwas nicht läuft oder es sich nur um einen Test gehandelt hat, den man nun wieder rückgängig machen möchte, geht man wie folgt vor:

1. Das Root Device hängen wir noch mal unter /snapshots ein: mount <root device> /snapshots
2. Ein btrfs subvolumes list /snapshots zeigt uns alle angelegten Snapshots
3. Mittels mv @ @_oldroot und einem anschließenden mv @_snapshot_apt_(datum) @ aktivieren wir den früheren Snapshot wieder als root
4. reboot

Nach einem Reboot des Systems sind nun alle nach dem Snapshot installierten Pakete und alle Veränderungen am Filesystem wieder zurückgesetzt worden, so als wäre es nie geschehen.

So kann man beliebig mit den Snapshots hin- und herwandern. Alle Snapshots sind übrigens auch regulär beschreibbar. Nicht mehr benötigte Snapshots kann man einfach mit einem btrfs subvolume delete /snapshots/<snapshot-name> entfernen.

Zum Ende noch eine Warnung: Da Ubuntu btrfs als root Filesystem zwar unterstützt, aber von der Standardimplementierung abweicht, funktioniert die oben angegebene Vorgehensweise nur auf Ubuntu, nicht aber auf Debian Systemen. Bei Debian Systemen ab Squeeze funktioniert dies zwar grundsätzlich schon, man muss jedoch mit den Subvolumes etwas anders umgehen. Debian hält sich an den Weg, wie ihn btrfs eigentlich vorgibt, Ubuntu weicht dagegen ab.

Wer in Debian 6 eine Möglichkeit sucht, ein ISO Image auf einen Rohling zu brennen, wird cdrecord vermissen. Dies ist in Debian mittlerweile nicht mehr enthalten. Stattdessen kann man aber auf wodim zurückgreifen.

aptitude install wodim

wodim tolles-image.iso

Es kommt immer wieder mal vor, dass ein Server installiert werden muss, der einen alten Server ersetzen soll. So lange nur wenige Dienste oder Pakete auf dem alten Server installiert waren, lässt sich das auch schnell aus dem Kopf erledigen. Pakete auf dem neuen Server installieren, Config übernehmen, Config anpassen, läuft.

Allerdings gibt es auch Server, auf denen viele Pakete installiert sind und die mehrere Dienste anbieten. Hier eine Vorgehensweise, um sich das Leben einfacher zu machen:

Auf dem alten Server:

dpkg --get-selections | grep -v deinstall > package_list.txt

Auf dem neuen Server:

dpkg --set-selections < package_list.txt

dselect

3. [I]nstall

4. [C]onfig

5. [R]emove (optional)

6. [Q]uit

neuer-server~# ssh user@alter-server dpkg --get-selections | grep -v deinstall | \
dpkg --set-selections && dselect update && dselect install && dselect config

Danach sind die auf dem alten Server installierten Pakete auf dem neuen Server ebenfalls installiert. Die Konfiguration muss dann natürlich noch übernommen und angepasst werden, denn in der Regel kommen auf dem neuen Server auch neuere Versionen der Pakete zum Einsatz.

Teil 2: Duply und Duplicity

Im ersten Teil habe ich ja bereits die Unterschiede zwischen Duply / Duplicity und Rdiff-Backup geschildert. In diesem Teil gehe ich also davon aus, dass man Duplicity verwendet, weil man vom Provider einen FTP Backup Space zur Verfügung gestellt bekommen hat oder Amazons S3 nutzt.

Installation

Unter Ubuntu 10.04 LTS / Lucid Lynx könnte es kaum einfacher sein. Die Pakete sind bereits im Repository vorhanden und können direkt mittels aptitude installiert werden.

aptitude install duply duplicity

Wer ältere Ubuntu Versionen oder andere Distributionen nutzt, kann Duply auch direkt von der Downloadsite nehmen und das Python Script unter /usr/bin legen und als ausführbar markieren (chmod +x /usr/bin/duply). Duplicity sollte in jedem halbwegs aktuellen Repository jedoch vorhanden sein.

Same procedure as every year, James!

Der neue Rootserver ist fertig, aber benötigt noch ein Backup. Hat man nun nicht gerade ein Rechenzentrum im Keller und kann dort Bänder wechseln gehen, bietet sich für Rootserver ein Backup auf verfügbaren Onlinespeicher an. Das kann in einigen Fällen ein weiterer Rootserver mit noch reichlich Platz sein, aber auch ein vom Provider zur Verfügung gestellter FTP Server oder auch Amazons S3 sind gute Alternativen.

Diverse Tools machen einem das Leben deutlich leichter und Backups zum Vergnügen. Im Folgenden gehe ich auf Duply/Duplicity und Rdiff-Backup in Verbindung mit einem weiteren Backup-Server, FTP Server und Amazon S3 ein und zeige wie man sichere Backups erstellt, die man hinterher auch wieder brauchen kann.

find /path/to/files* -mtime +30 -exec rm {} \;

Ich mag Einzeiler...

irgendwie bleibt immer ein seltsames Gefühl, wenn nach einem einfachen Reboot der Hardware Controller für eine Weile auf "Initializing" steht. Auch wenn's laut Handbuch bei 3ware Controllern im RAID1 nichts ungewöhliches ist.

Ein Blick in's gut versteckte Handbuch auf die Seiten 150 bis 158 hilft beim Beruhigen.

Auf einem schlanken, schmalen, stromsparenden Atom 230 Rechner installierte ich kürzlich Ubuntu. Zunächst die 8.10, danach per Upgrade die 9.04. Alles lief soweit zufriedenstellend, aber so richtig glücklich war ich mit der Performance nicht. Ich dachte länger, dass es wohl so sei, wenn man einen Atom230 mit einer 1920x1080er Auflösung beauftragt, denn Hubraum lässt sich nur durch mehr Hubraum ersetzen und man daher auch damit leben müsse. Muss man aber nicht.

Nach einigen Änderungen ist mein Atom-Ubuntu nun deutlich flotter als vorher und die Arbeit macht ebenfalls mehr Spass. Hier die Punkte, an die man als leidgeplagter Performance-Junkie Hand anlegen sollte:

• Remote Desktop abschalten
• Pulseaudio durch esound ersetzen
• Python 2.5 deinstallieren, sofern es nicht mehr benötigt wird (Standard ist sowieso Python 2.6)
• Xorg beschleunigen (hier habe ich das meiste rausholen können)
• Prozessortaktung beeinflussen
• "Swappiness" konfigurieren

.cue und .bin Dateien sind keine .iso Dateien. Nicht einmal annähernd. Unter Windows verstehen viele Brennprogramme das Format trotzdem und brennen es anstandslos auf eine Silberscheibe. Unter Linux sieht das nicht ganz so aus. Ich habe mich auch immer wieder darüber geärgert, bis ich über bchunk gestolpert bin.

Dieses Programm ist in der Lage, aus .cue und .bin mal eben eine .iso zu erstellen:

bchunk -v image.bin image.cue image 

Nach ein wenig auf der Platte rödeln findet man eine fertige image.iso Datei. Und die kann man problemlos brennen, auch unter Linux.

bchunk ist übrigens in vielen Repositories bereits vorhanden, so dass man es unter Ubuntu mit einem aptitude install bchunk problemlos installieren kann.

Wer von irgendeinem Linux Filesystem auf eine externe Festplatte mit FAT(32) Filesystem Daten sichern möchte, kann ein Lied davon singen. Nicht, dass man unbedingt FAT32 haben möchte, aber die meisten externen Festplatten sind ab Werk damit vorformatiert und laufen daher an den meisten Betriebssystemen out-of-the-box.

FAT32 beschränkt die maximale Dateigröße jedoch auf 4 GB pro Datei. Für eine Datensicherung ist das heutzutage nicht mehr besonders viel.

Linux selbst bringt die Lösung in Form der Kombination aus den beiden Kommandos tar und split bereits mit:

tar cpf - /home | split -a 3 -d -b 1G - /mnt/backuphd/meinbackup.tar.

tar packt den Inhalt des Ordners /home zusammen und sendet ihn an die Standardausgabe ("-"), wo split die Daten entgegen nimmt, in 1 GB grosse Stückchen zerteilt, und nach /mnt/backuphd/meinbackup.tar.000  bis /mnt/backuphd/meinbackup.tar.xxx  speichert. Die letzten drei Ziffern werden jeweils hochgezählt.

Aus diesem Archiv rekonstruieren ist ebenso einfach:

cat /mnt/backuphd/meinbackup.tar.* | tar xvf - /home

Man sollte mit sensiblen Daten immer zuerst einen Testdurchlauf machen. Es wäre schade, wenn das Backup später unbrauchbar wäre, weil man irgendeine falsche Option oder einen falschen Pfad angegeben hat.

Gerade eben stellte ich fest, dass auf einem Ubuntu 8.04 Server die Cron-Jobs nicht mehr ausgeführt werden. Also machte ich mich auf die Suche nach dem Grund, konnte ihn aber zunächst nicht finden. In der /var/log/syslog dann der erste Hinweis:

Error: bad minute; while reading /etc/crontab

Die /etc/crontab sah allerdings sehr normal aus. Da gab es keine falschen Einträge oder fehlende Angaben. Nach einigem auskommentieren und testen bin ich dann auf die Lösung gekommen. In der crontab fand ich folgende Zeile, bei der ich mir erst mal nichts dachte:

MAILTO= 

Allerdings interpretiert cron diese Zeile so, dass er MAILTO= für die Angabe der Minuten hält und danach nichts mehr kommt. Und MAILTO= ist auch keine gültige Angabe für Minuten . Also entweder eine Mailadresse dahinter schreiben oder wie in meinem Falle mit einem # auskommentieren. Dann cron neustarten und schon funktionierts auch wieder.

RDP, das Remote Desktop Protocol, macht seine Arbeit beim Zugriff auf entfernte Server soweit ja ganz ordentlich. Mittlerweile liegt RDP in Version 6 vor und es gibt sogar unter Linux einen funktionierenden Client und auch einen funktionierenden RDP Server. Steht der zu steuernde Server allerdings hinter einer nicht ganz so breitbandigen Verbindung, lahmt RDP gelegentlich auch mal dahin. Selbst wenn man die Performance optimiert, fliesst es so la la, abhängig eben von der Upload-Bandbreite des Anschlusses an dem der Server hängt. Da auch ich oft auf RDP Server zugreife(n muss), die hinter einem normalen DSL Anschluss hängen kenne ich das Problem also auch aus erster Hand.

Interessant wird's, wenn man über den RDP Tellerrand hinausschaut. Dort gibt es zum Beispiel für den Betrieb von Linux Terminalservern von Nomachine ein Produkt namens NX, welches eine ordentliche Performance an den Tag legt und über normales SSH gefahren wird. NX kann aber auch mehr. Mit NX' Hilfe lassen sich beispielsweise auch RDP Connections beschleunigen.

Zum Beispiel baue ich eine Verbindung mit NX über eine DSL Leitung zu einem Linux Server auf, der im gleichen LAN wie der RDP Server steht. Auf diesem Linux Server starte ich nun meinen RDP Client und verbinde mich auf den RDP Server. Das alleine sorgt schon für einen ordentlichen Performancegewinn, mit dem die Arbeit auf einem Windows Terminal Server über RDP deutlich flüssiger von der Hand geht.

Ausprobieren empfohlen. Ich könnte vielleicht auch mal ein Video vom Unterschied machen, was allerdings Zeit kostet, die ich momentan in andere Dinge stecke. Weshalb sonst sollte ich auch RDP beschleunigen wollen?

...und die macht nen ziemlich schlanken Fuss. Überraschend und gut: Schnelleres Booten, etwas flüssiger beim Arbeiten auf einem Atom230 und auf Anhieb bei mir ohne Schwierigkeiten. Hinweise und Download wie üblich.

Jetzt noch die übliche Warnung: BETA! BETA! BETA! - Also noch nichts für Produktivumgebungen.

Hatte ich schon mal erwähnt, wie begeistert ich von SNOM Telefonen bin?

Ich staune gelegentlich mal, dass man dort eben alles so macht, wie's ein vernünftiger Mensch auch tun würde.