IT-Blog

Seit Microsoft Office 2007 werden die Dokumente im neuen Dateiformat Office Open XML gespeichert. Bietet man diese auf einem Webserver, der mit Apache2 und Debian Lenny betrieben wird, zum Download an, werden diese von manchen Browsern (z.B. Internet Explorer) fälschlicherweise als Zip-Datei interpretiert. Dies liegt daran, dass der Webserver dieses Format nicht kennt und daher einen falschen MIME-Type (text/plain statt beispielsweise application/vnd.openxmlformats-officedocument.wordprocessingml.document) im Content-Type-Header einfügt. Da es sich bei dem Dateiformat an sich eigentlich tatsächlich um eine Zip-Datei handelt, erkennen dies manche Browser leider auch als solche. Dies lässt sich jedoch mit ein paar Anpassungen beheben.

Artikel vollständig lesen »

HowtoForge: Einrichten von Master-Master Replikation mit MySQL 5 auf Debian Etch
Dieses Tutorial beschreibt die Vorgehensweise zur Einrichtung einer Master-Master-Replikation zweier MySQL-5-Server. Auch wenn darin Debian Etch zum Einsatz kommt, funktioniert dies natürlich ebenso mit aktuellen Linux-Distributionen wie beispielsweise Debian Lenny oder Ubuntu Lucid Lynx.

adminlife.net: vim / vi Spickzettel
Wie bei den meisten Dingen, kann man sich bei Programmen i.d.R. auch nur die häufig verwendeten Befehle merken. Deshalb sind in diesem Artikel Links zu ein paar "Spickzetteln" für die Befehle von Vi/VIm aufgeführt.

www.preloaders.net | Free AJAX animated loading gif's | 3 dimensional (3D)
Immer mehr Websites verwenden heute AJAX um Inhalte dynamisch nachzuladen oder Benutzer-Interaktion zu ermöglichen. Damit für den Benutzer erkennbar ist, dass gerade eine Aktion ausgeführt wird, werden dabei oft animierte Grafiken angezeigt. Solche Grafiken kann man sich mit diesem Generator einfach und mit individuellen Vorgaben erstellen lassen.

Normalerweise werden die in einer Linux-Shell ausgeführten Befehle unter ~/.bash_history o.ä. dauerhaft gespeichert. Manchmal gibt es aber auch Gründe dafür, dies zu unterbinden (z.B. Sicherheit oder Datenschutz). Wie so oft, gibt es auch hierfür viele Möglichkeiten. Ich werde im Folgenden daher nur auf zwei davon eingehen. Artikel vollständig lesen »

Sicher ist es dem einen oder anderen schon einmal passiert: Man hat über crontab -e Cronjobs definiert und möchte an diesen etwas ändern. Nach der Änderung stellt man fest, dass es nicht so funktioniert, und möchte die Änderungen rückgängig machen. Unglücklicherweise hat man aber so viel geändert, dass man nicht mehr genau weiß, wie es davor war.
Aber zum Glück macht man ja regelmäßige Backups des Systems, weshalb die alte Version ja noch nicht ganz verloren sein dürfte. Doch dann stellt sich die Frage, wo die so definierten Cronjobs im Dateisystem abgelegt werden.
Die Antwort hierzu ist jedoch ganz einfach: Im Verzeichnis /var/spool/cron/crontabs/ gibt es für jeden User eine Datei, in der dessen Cronjobs hinterlegt sind. Stellt man die betreffende Datei dann aus dem Backup wieder her, so sind die Cronjobs wieder auf dem Stand vor den Änderungen.

Unter Ubuntu und anderen Linux-Distributionen werden für die Identifizierung von Festplatten-Partitionen mittlerweile meist so genannte UUIDs verwendet. Da dabei jeder Partition eine (zumindest theoretisch) eindeutige ID zugewiesen wird, vereinfacht dies oft die Arbeit. Dies macht sich insbesondere dann bemerkbar, wenn man Änderungen an der Hardware vornimmt, da UUIDs im Gegensatz zum herkömlichen Bezeichnung (z.B. /dev/sda3) stets gleich bleiben.

Doch so groß der Vorteil von UUIDs ist, so leicht kann es damit auch zu Problemen kommen. Vor einem Upgrade von Ubuntu 8.10 auf 9.04 wollte ich zur Sicherheit meine System-Partition duplizieren. Mittels dd war dies einfach und ohne Probleme möglich. Nach dem Upgrade wurde jedoch plötzlich wieder das alte System gestartet, obwohl diese Partition im Dateisystem nirgendwo gemountet oder im GRUB hinterlegt war. Nach langer Fehlersuche bin ich schließlich darauf gekommen, dass beim Kopieren der Partition auch deren UUID mitkopiert wurde, so dass ich zwei Partitionen mit der gleichen UUID hatte. Das musste natürlich unweigerlich zu Problemen führen.

Lösen lässt sich dies, indem man für eine der beiden Partitionen eine neue UUID vergibt. Dies kann mittels tune2fs folgendermaßen gemacht werden:

tune2fs -U random [Partition]

# Beispiel:
tune2fs -U random /dev/sda3

Dadurch gibt es die bisher doppelt vergebene UUID nur noch einmal, so dass das bisherige Fehlverhalten nicht mehr auftritt.