Marco Gabriel

Neulich hatte ich eine Unterhaltung darüber, wie man die Laufzeit eines Programms möglichst einfach misst. Im konkreten Fall wollten wir wissen, wie lange ein mysqldump benötigt hat. Dazu gibts unter Linux den Befehl time, den man dem zu messenden Programm einfach voranstellt.

time <Programm und Parameter>
[...Ausgabe des Programms...]

real    0m56.754s
user    0m0.784s
sys    0m4.004s

Der Wert hinter real zeigt an, wie lange das Programm gelaufen ist, im obigen Beispiel 0 Minuten, 56 Sekunden und 754 Millisekunden.

Geht nicht? Geht doch. 

Und das Beste daran ist: "vimtutor" ist sehr wahrscheinlich schon installiert.

Einfach auf der Shell starten und den Anweisungen folgen:

vimtutor

vimtutor Screenshot

Eben habe ich einen schönen Artikel gefunden, der diff, kompare und meld mal im Detail beschreibt. Ich nutze diff beispielsweise immer um bei Upgrades zu sehen, welche Optionen bei einer neuen Konfigurationsdaten dazu gekommen sind.

python -m SimpleHTTPServer

Der Befehl startet einen Webserver, der das aktuelle Verzeichnis über Port 8000 freigibt.

~# python -m SimpleHTTPServer
Serving HTTP on 0.0.0.0 port 8000 ...

Man kann also nun über http://<adresse>:8000/ auf das Verzeichnis zugreifen. Da Python quasi überall vorhanden ist, werden keine weiteren Freigaben oder Software benötigt. Nicht einmal root Rechte braucht man dafür.

Wer einen anderen Port bevorzugt, kann diesen noch dahinter angeben:

python -m SimpleHTTPServer [port]

So etwas ähnliches gibt's auch in Bash, die obige Lösung finde ich aber einfacher.

Wenn man regelmäßig Daten transferieren oder abgleichen möchte, dann ist Rsync in der Regel das beste Mittel der Wahl. Rsync überträgt nur geänderte Dateien, tut dies sehr effizient, komprimiert dabei noch und verschlüsselt die Daten während des Transfers. Rsync funktioniert für regelmäßige Dateitransfers also extrem gut.

Schön wäre es nun, wenn man so etwas wie Rsync auch für sehr große Dateien oder Logical Volumes eines LVM verwenden könnte. Ein typischer Anwendungsfall ist die Sicherung von virtuellen Maschinen, bei denen diese Images auch schon mal mehrere hundert GB groß sind.

Neulich musste ich für die Umstellung eines Mailsystems ca. 3.300 Aliase umschreiben. Da diese Aliase aus mehreren Quellen stammen sollte das ganze auch automatisch und jederzeit wiederholbar sein. Ich kam irgendwann an den Punkt, an dem ich eine Datei lesen und mit jeder Zeile etwas tun musste. 

Der Klassiker in Bash ist einfach:

for LINE in $(cat /pfad/zur/datei)
do
    echo $LINE
done

Dazu gibt es jedoch eine meist bessere Alternative:

while read LINE
do
    echo $LINE
done < /pfad/zur/datei

Variante 2 nutzt das read Kommando unter Linux und liest die Datei wirkich zeilenweise, wogegen Version 1 wortweise liest.

Beispiel:

Quelldatei

zeile eins
zeile zwei

Ergebnis der Variante 1:

zeile
eins
zeile
zwei

Ergebnis der Variante 2:

zeile eins
zeile zwei

Mir gefällt mir die erste Variante durchaus besser von der Form, aber sie verhält sich eventuell nicht, wie man es erwarten würde.

Links:

• OpenRemote
• FHEM
• DomoTiga
• HCS
• Pythomation
• HCAN

Ab und an dauert ein rsync Job länger als geplant. Wenn man sicherstellen möchte, dass rsync in einem Cronjob nur ausgeführt wird, falls es nicht schon läuft, kann man folgendes Konstrukt verwenden:

pgrep -c rsync || rsync [options] quelle ziel

Ich hatte das vor einiger Zeit bei Serverfault schon mal als Antwort eingestellt, aber eigentlich ist es in meinem Blog auch gut aufgehoben. 

Ein bestimmter Server wurde in letzter Zeit immer unzuverlässiger und stürzte öfter mal ab, ohne dass wir eine genaue Ursache ausmachen konnten. Gestern habe ich mich dem Server noch mal angenommen und ein bisschen Ursachenforschung betrieben. Ein einfaches ls -la /var/log dauerte schon ewig. Ich spekulierte schon über einen Festplattenschaden bis ich dann irgendwann tatsächlich eine endlose Dateiliste zu sehen bekam.

Ein ls -la | wc -l brachte hervor, dass in diesem Ordner mehr als 1,3 Millionen Files lagen. Kein Wunder, dass  der Server dabei ab und an mal Schwierigkeiten hat. Die Ursache war, dass sich auf Debian/Ubuntu Systemen der sysklogd und logrotate gegenseitig in die Quere kommen. Aber dazu vielleicht ein anderes Mal mehr. Nun musste ich erst mal die ganzen überflüssigen Dateien löschen.

Das ist etwas leichter gesagt als getan, denn ein rm /var/log/mail.0.* brachte schon einen Fehler, dass die Liste der Dateien zu gross sei.

Lösung 1:

find /var/log -name "mail.0.*" -exec rm '{}' \;

find bearbeitet jede Datei einzeln, startet dann rm um die einzelne Datei zu löschen. Das funktionierte grundsätzlich, löschte allerdings nur ca. 150 Files pro Sekunde. Somit hätte der gesamte Vorgang 144 Stunden oder 6 ganze Tage gedauert. Ich brauchte eine andere Lösung.

Lösung 2:

find /var/log -name "mail.0.*" -delete -print

Damit übergibt find die Dateien nicht mehr an rm, sondern löscht sie gleich selbst. Damit erreichte ich ca. 2.000 Files pro Sekunde. Der gesamte Vorgang verkürzte sich somit auf ca. 10 Minuten. Das -print ist übrigens nur notwendig, wenn man sehen möchte, welche Dateien find löscht. Ohne Ausgabe dürfte es noch etwas schneller gehen. Na Also, geht doch. 

EDIT: Da der Artikel in einer früheren Version unfertig gespeichert wurde, habe ich die fehlenden Lösungen noch ergänzt . 

EDIT 2: "-name" ergänzt. Falscher Fehler in meiner Erinnerung. 

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.

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.

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

Ich mag Einzeiler...