Marco Gabriel

.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?

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.

Auf dem Desktop meines Rechners habe ich nun mal von Ubuntu 8.04 auf die noch unfertige 8.10 aktualisiert.

Obwohl noch nicht alles rund läuft, bin ich davon recht begeistert. Die 3D Effekte funktionieren leider nach dem Upgrade noch nicht wieder, ansonsten hat mit Gnome 2.24 und etlichen Detailverbesserungen Ubuntu wieder mal einen gewaltigen Schritt nach vorne gemacht.

Mit jedem Release wird Linux auf dem Desktop brauchbarer, auch wenn ich vermutlich auf absehbare Zeit noch nicht komplett auf Windows werde verzichten können.

Was tun wenn die Festplatte lustige Geräusche macht oder bereits Daten verloren hat, weil die Harddisk defekte Sektoren hat?

Das allseits beliebte dd zum Erstellen von Festplattenimages tut bei funktionierenden Festplatten seinen Dienst, bei Platten mit defekten Sektoren jedoch führt dd zu unbrauchbaren images. Aber warum und was passiert dabei genau?

dd bs=4096 conv=noerror,sync if=/dev/hda of=/mnt/server/imagedatei.img

dd liest blockweise (4096 Bytes) die Daten von der Festplatte /dev/hda, macht auch weiter wenn es auf Fehler trifft, füllt den Block mit Nullbytes auf 4096 bytes auf, falls er kürzer ist, und schreibt diese Dateien gleichzeitig in 4096 Byte Blöcken nach /mnt/server/imagedatei.img. Fatal ist, wenn Blöcke nicht lesbar sind. In dem Falle bricht dd zwar nicht ab, weil conv=noerror angegeben wurde, aber es liest keine Daten ein und schreibt auch keine Daten in das Image.

Die Fehlerhaften Blöcke fehlen im Zielimage also komplett, weshalb die danach folgenden Sektoren nach vorne verschoben sind und das Filesystem somit Schwierigkeiten haben dürfte, die Daten richtig wieder zu finden.

Defekte Platten mit dd sichern funktioniert nicht.

Stattdessen sollte man für Festplatten mit defekten Sektoren GNU ddrescue nehmen (nicht zu verwechseln mit ddrescue). Je nach verwendeter Distribution ist GNU ddrescue direkt mit apt-get oder yum zu installieren. Bei Debian z.B. mit apt-get install gddrescue, bei anderen Distributionen auch als dd_rescue bezeichnet.

Auch GNU ddrescue erstellt ein Image von der Festplatte, geht dabei jedoch einen anderen Weg:

• Es liest zunächst alle problemlos lesbaren Daten, um so viel wie möglich zu retten bevor die Festplatte möglicherweise stirbt
• Danach liest es mehrfach die defekten Sektoren und versucht auch dort die Daten zu retten, sofern möglich
• Leere Bereiche der Festplatte werden übersprungen. Das sorgt dabei für eine deutlich schnellere Erstellung des Zielimages
• Das Zielimage ist hinterher vollständig, keine Sektoren fehlen. Sofern ein Sektor unlesbar war, fehlen an dieser Stelle jedoch die Originaldaten

Datenrettung in letzter Sekunde eben, aber wenn, dann wenigstens richtig. Aufschlußreich ist übrigens auch ein Interview mit dem Entwickler.

server# dd bs=65536 if=/dev/hda | ssh -o Compression=yes user@host "cat > image.img"

1. liest aus der shell von "server"
2. mit 64k Blöcken
3. den Festplatteninhalt von /dev/hda aus
4. meldet sich dann als user bei host an
5. und schickt das image via ssh komprimiert über die Leitung
6. und legt das Image im Homedir des Benutzers user als image.img ab.

Manchmal lohnt es sich, die Kommandozeilenparameter für Programme näher zu erforschen.

top -i zeigt nur noch die aktiven Prozesse an, was deutlich übersichtlicher ist. Probierbefehl .

Kürzlich überraschte mich mein interner Mailserver (Postfix) mit der Log-Meldung "No route to host". Alle E-Mails blieben in der Mailqueue und wurde nicht mehr zum Smarthost ausgeliefert, von wo aus sie dann an die Empfänger geleitet werden.

Die Lösung dafür lag darin, daß beim DSL-Zugangsprovider kürzlich alles auf Port 25 abgehende gesperrt wurde, damit die ganzen Spambots eben nicht mehr spammen. Somit war es nur für Verbindungen auf Port 25 unmöglich, irgendetwas da draussen noch zu erreichen.

Die Lösung dafür war einfach: Mein Postfix verschickt jetzt Mail auf Port 587 zum Smarthost. Dieser ist normalerweise nicht geblockt und alles funktioniert wieder.

Ich bin vor einiger Zeit auf Linux Mint gestoßen, eine Linux Distribution, die direkt auf Ubuntu basiert, aber speziell auf Desktops ausgerichtet ist und bereits viele in Ubuntu noch nicht enthaltene Plugins oder Erweiterungen enthält. Slogan von Linux Mint ist "from freedom came elegance" und der beschreibt die Ausrichtung der Distribution auch schon ganz treffend.

Beim Update eines Servers heute morgen:

Fetched 41.4MB in 3s (11.2MB/s)

So kann ein Tag beginnen .

• http://www.linuxhaven.de/dlhp/HOWTO/DE-LVM-HOWTO.html
• http://evms.sourceforge.net/
• http://www.tldp.org/HOWTO/LVM-HOWTO/
• http://sources.redhat.com/lvm2/
• http://www.howtoforge.com/linux_lvm