dysternis

Für einen neuen Server in unserer Rootserver-Kommune brauche ich eine Replik unseres LDAP-Servers. Wie sich herausstellte, ist das ziemlich einfach und in der umfangreichen Dokumentation exzellent erklärt.

Im zu replizierenden LDAP-Server (“Provider”) muss man lediglich dafür sorgen, dass das syncprov-Modul in der slapd.conf geladen wird:

modulepath      /usr/lib/ldap
moduleload      back_hdb
moduleload      syncprov

Im Zielserver (“Consumer”), wird so eine 1:1 Replikation des Quellservers konfiguriert:

# replication settings
syncrepl rid=001
    provider=ldaps://ldaps.yourdomain.de:636
    type=refreshAndPersist
    searchbase="dc=yourdomain,dc=de"
    schemachecking=on
    type=refreshAndPersist
    retry="60 +"
    bindmethod=simple
    binddn="cn=replicator,dc=yourdomain,dc=de"
    credentials=assword

Natürlich müssen im Quellserver entsprechende Credentials hinterlegt werden. Durch das Keyword refreshAndPersist bleibt die Verbindung dauerhaft bestehen und Änderungen im Quellserver werden sofort auf dem Zielserver repliziert.

Achtung: im Zielserver müssen natürlich die gleichen Schemata geladen sein, wie im Quellserver. Schaut euch also die Include-Section entsprechend an, sonst hagelt es Fehler.

Mit dieser Methode kann man den LDAP-Server super-komfortabel umziehen, einfach Replikation einschalten, DNS-umschwenken und dann die Replikation auf dem Zielserver ausschalten.

Das Alice Modem 1121 WLAN bzw. TV hat eine recht spartanische Administrationsoberfläche. Man kann wirklich nur das Nötigste einstellen, eine Möglichkeite den beliebten DynDNS-Dienst zu konfigurieren, sucht man vergeblich.

Die Modemsoftware bringt jedoch einen DynDNS-Client mit, allerdings ist der nur via Telnet zu konfigurieren. Das Modem ist vom LAN und WLAN aus unter seiner Standard-IP 192.168.1.1 erreichbar.

Die Zugangsdaten lauten:

• User: admin
• Passwort: AliceXXXXXX123

Die Zeichenfolge XXXXXX muss durch die letzten sechs Zeichen der LAN MAC-Adresse des Modems ersetzt werden. Lautet die MAC-Adresse des Modems z.B. 00:25:5E:AB:64:FE, so muss man als Passwort AliceAB64FE123 verwenden:

$ telnet 192.168.1.1
 
Entering character mode
Escape character is '^]'.
 
Alice Modem WLAN 1121
Login: admin
Password: AliceAB64FE123
 
>

Man findet sich auf einer kastrierten Linux(?)-Shell wieder. help liefert eine Liste der möglichen Kommandos. Mit ddns kann man den DynDNS-Client konfigurieren:

> ddns
ddns add hostname --username username --password password --interface interface --service tzo|dyndns
     remove hostname
     show
ddns --help>

Ok, mit add fügt man eine DynDNS-Konfiguration hinzu, mit remove wird sie wieder entfernt und mit show kann man alle anzeigen lassen.

Der folende Aufruf fügt eine Konfiguration für den Hostnamen myhomedsl.dyndns.org beim Dienst dyndns mit dem Usenamen user6 und dem Passwort 123456 hinzu:

dns add myhomedsl.dyndns.org --username user6 --password 123456 --interface ppp_0_1_32_1  --service dyndns

Wichtig: man muss im parameter --interface den Namen des WLAN-Interfaces eingeben. Den Namen bekommt man mit dem Kommando ifconfig heraus. Es listet alle Interfaces auf, gesucht ist das mit ppp im Namen:

ppp_0_1_32_1    Link encap:Point-Point Protocol  
                inet addr:85.178.209.191  P-t-P:213.191.89.4  Mask:255.255.255.255
                UP POINTOPOINT RUNNING NOARP ALLMULTI MULTICAST  MTU:1492  Metric:1
                RX packets:9540 errors:0 dropped:0 overruns:0 frame:0
                TX packets:7456 errors:0 dropped:0 overruns:0 carrier:0
                collisions:0 txqueuelen:3 
                RX bytes:6444034 (6.1 MiB)  TX bytes:1135835 (1.0 MiB)

In meinem Beispiel lautet der Name des Interfaces also ppp_0_1_32_1.

Server Name Indication (SNI) on Debian Lenny is easy to implement. OpenSSL is already SNI-capable, only the Apache Webserver is a bit outdated. So lets backport Apache >= 2.2.12 to Lenny. Here is my little step-by-step howto:

Install a compiler an the debian dpkg-Development Environment:

$ sudo aptitude install dpkg-dev build-essential fakeroot

To build apache, you will nee libcap2-dev and autoconf too:

$ sudo aptitude install libcap2-dev autoconf

…and the build dependencies for apache2:

$ sudo apt-get build-dep apache2

Download the Apache 2.2.14 sources for the current testing release from http://packages.debian.org/source/squeeze/apache2:

$ wget http://ftp.de.debian.org/debian/pool/main/a/apache2/apache2_2.2.14-1.dsc
$ wget http://ftp.de.debian.org/debian/pool/main/a/apache2/apache2_2.2.14.orig.tar.gz
$ wget http://ftp.de.debian.org/debian/pool/main/a/apache2/apache2_2.2.14-1.diff.gz

Extract the source packages:

$ dpkg-source -x apache2_2.2.14-1.dsc

Compile the package:

$ cd apache2-2.2.14/
$ dpkg-buildpackage -us -uc -rfakeroot

(-us and -uc supresses the digital signature, fakeroot allows to set the ownership of the archived files to root, even if you are not root currently)

Install the desired apache packets:

$ cd ../
$ dpkg -i apache2_2.2.14-1_i386.deb apache2.2-bin_2.2.14-1_i386.deb apache2.2-common_2.2.14-1_i386.deb apache2-mpm-prefork_2.2.14-1_i386.deb apache2-suexec_2.2.14-1_i386.deb apache2-utils_2.2.14-1_i386.deb

Finally, remove the packages you installed to build the apache2-packages.

Wenn man einen Rechner im öffentlichen Raum als Browserterminal bereitstellen will, gibt es hauptsächlich die Anforderung, dass die User keine privaten Daten hinterlassen und am System so wenig wie möglich verstellen.

Es gibt verschiedenste Lösungen für diesen Zweck, fertige Linux-Distributionen oder spezielle Internet-Café Software, die Windows-Rechner so abschottet, das man noch nicht mal einen Explorer aufbekommt.

Für die beiden vom Freifunk betriebenen Surfterminals habe ich eine extrem simple Lösung gewählt. Die Rechner verrichten seit etlichen Monaten ohne Probleme ihren Dienst, obwohl es in den Kneipen schon etwas rauher zugeht.

Zunächst wird auf den Rechner die Linux-Distribution der Wahl installiert. Ich verwende Ubuntu, aber darauf kommt es nicht an. Es werden zwei Benutzer eingerichtet: ein administrativer (“tresen”) und ein unpreviligierter (“gast”). Achtung, bei Ubuntu ist der erste, bei der Installation eingerichtete User ein previligierter User (mit sudo-Rechten). Also erst “tresen” und dann “gast” einrichten und hinterher nochmal die /etc/sudoers überprüfen.

Man loggt sich zunächst als “gast” ein und richtet den Browser so ein, wie man es gerne für die Gäste hätte: Adblocker, keine Cookies und Passwörter speichern, Startseite ect. Die Startseite für den Browser zeigt in unser Wiki, die Kneipengäste können dort dann eigene Links ablegen und so die Startseite etwas nach ihren Bedürfnissen anpassen. Der Webbrowser wird als Autostart-Applikation eingerichtet (System -> Preferences -> Sessions -> Startup Programs). Dann loggt man sich als “tresen” ein und richtet den Anmeldungsmanager so ein, dass “gast” beim Rechnerstart automatisch eingeloggt wird.

Jetzt kommt der interessante Teil: das Script pack_guest.sh verpackt das Home-Verzeichnis vom Gastuser in eine .tar-Datei:

#!/bin/sh
#
# Erstellt ein neues Template (gast_home.tar.gz) aus dem aktuellen gast
# Homeverzeichnis. Dieses Script sollte nur ausgeführt werden, wenn die
# Änderungem am gast-User dauerhaft gespeichert werden sollen.
#
# siehe http://wiki.freifunk-potsdam.de/index.php?title=Olga-Surfstation
if [ `whoami` != "root" ]; then
  echo "Du musst root sein, um das Script auszufuehren! Schau Dir bitte die"
  echo "Doku auf unserer Webseite an:"
  echo "http://wiki.freifunk-potsdam.de/index.php?title=Olga-Surfstation"
  exit 1
fi
 
#
DATE=`date +%Y%m%d_%H%M%S`
TARGET=/home/tresen/Surfstation/gast_home.tar.gz
 
# backup vom alten $HOME anlegen...
if [ -e $TARGET ]; then
  mv -v $TARGET  /home/tresen/Surfstation/gast_home_$DATE.tar.gz
fi
 
cd /
tar czf /home/tresen/Surfstation/gast_home.tar.gz /home/gast

Dieses Script ruft man einmalig auf und findet dann in /home/tresen/Surfstation die Datei gast_home.tar.gz. Dieses Template kann nun immer ausgepackt werden, wenn der Rechner startet. Das erledigt das Script unpack_guest.sh:

#!/bin/sh
#
# stellt den gast-user aus dem vorgefertigten Template (gast_home.tar.gz)
# wieder her. Das ist das Standard-Script, das bei jedem Booten ausgefuehrt
# wird. siehe
# http://wiki.freifunk-potsdam.de/index.php?title=Olga-Surfstation
#
if [ `whoami` != "root" ]; then
  echo "Du musst root sein, um das Script auszufuehren! Schau Dir bitte die"
  echo "Doku auf unserer Webseite an:"
  echo "http://wiki.freifunk-potsdam.de/index.php?title=Olga-Surfstation"
  exit 1
fi
 
rm -rf /home/gast
cd /
tar xzf  /home/tresen/Surfstation/gast_home.tar.gz
 
# falls das Passwort zurueck gesetzt wurde...
echo "gast:gast" | chpasswd

Jetzt muss man nur noch dafür sorgen, dass dieses Script bei jedem Bootvorgang ausgeführt wird. Eine Zeile in /etc/rc.local genügt:

/home/tresen/Surfstation/unpack_guest.sh

[Update] (12.11.09): Mir ist gerade aufgefallen, dass es mit Upstart zu einer Race-Condition kommt. Es ist einfach nicht definiert, wann das Script unpack_guest.sh ausgeführt wird und das führt zu sehr merkwürdigen Effekten.

Wenn man also eine Distribution mit Upstart verwendet (z.B. Ubuntu 9.10 “Karmic Koala” oder später), muss man den Aufruf des unpack_guest.sh Scriptes im Upstart-System vor den gdm legen. Entweder man definiert einen eigenen Dienst oder man fügt das Script als pre-start Script in /etc/init/gdm.conf ein:

pre-start script
    # unpack the guest account home directory
    /home/tresen/Surfstation/unpack_guest.sh
end script

[/Update]

Mir gefällt an diese Lösung, dass wir damit absolut keine Arbeit haben. Die einzigen Probleme sind Hardwareschäden, also wenn wiedermal Bier über die Tastatur gekippt wurde. Das System an sich läuft aber nahezu wartungsfrei. Man muss sich halt alle paar Monate (idealerweise remote) einloggen und die fälligen Updates einspielen.

Gelegentlich braucht man einen Stacktrace. Ich bin heute über ein Problem gestolpert, bei dessen Lösung mir ein Stacktrace sehr helfen würde.

Eine unserer Bibliotheken kümmert sich um Speichermanagement. Das sind kleine Wrapper um malloc / free, die Buchhaltung über den Speicher führen und bei Fehlern entsprechende Meldungen ausgeben. Also der übliche Weg für das Speichermanagementproblem in C, es gibt duzende Lösungen die ähnlich funktionieren.

Das Problem heute war, dass Speicher freigegeben werden sollte, der nie allokiert war oder schon einmal freigegeben wurde. Er war auf jeden Fall nicht mehr als belegt gekennzeichnet und konnte somit nicht freigegeben werden. Programme ohne solch ein Speichermanagement würden an dieser Stelle abstürzen, bei uns taucht nur eine Meldung im Log auf.

Diese Meldung war mein Startpunkt für die Suche. Die Aufrufe der free-Wrapperfunktion sind jedoch in vielen Sourcefiles auf tausenden Zeilen Code verstreut. Wie soll man dort den einen Aufruf finden, der die Ursache für die Meldung ist?

Genau: ein Stacktrace muss her. Der schmutzige Weg wäre, das Programm mutwillig zum Absturz zu bringen. Dann kann man sich aus dem core-File den Stack rauspopeln und weiss, woher der Aufruf kommt.

Es gibt jedoch etwas viel schöneres: backtrace() aus der glibc. Mit ein paar Zeilen Code kann man an jeder beliebigen Stelle des Programms einen Stacktrace erzeugen:

void *array[10];
size_t size;
char **strings;
size_t i;
 
size = backtrace (array, 10);
strings = backtrace_symbols (array, size);
 
printf ("Obtained %zd stack frames.\n", size);
 
for (i = 0; i < size; i++)
   printf ("%s\n", strings[i]);
 
free (strings);

Ich habe also in der free-Wrapperfunktion backtrace() eingebaut und konnte mir den Stacktrace für den Fehlerfall ausgeben. Im Log erhält man dann etwa diese Ausgabe:

yourbinary [0x80b9e0c]
yourbinary [0x80b9f02]
yourbinary [0x8054abd]
yourbinary [0x805124f]
yourbinary [0x8050078]
yourbinary [0x808d6f3]
yourbinary [0x804bd42]
yourbinary [0x804b04e]
libc.so.6(__libc_start_main+0xe5) [0xb7d0f775]
yourbinary [0x804a701]

Ok, das sieht schon mal gut aus Jetzt muss man nur noch yourbinary in den ddd laden um die Speicheradressen in Codezeilen umzuwandeln - et voilà: schon ist die bösartige Zeile Code identifiziert.

Ich habe heute zu meinem Erstaunen festgestellt, dass man HFS+Volumes – dem Fall meine externe USB-Platte – nicht unter Linux beschreiben kann. Nachdem ich google eine Weile mit Suchbegriffen (“Read only filesystem” “hfsplus”) beworfen hatte, kam auch ans Licht, woran das liegt.

Linux kann schon HFS+-Volumes beschreiben, allerdings nicht, wenn diese journaled sind. Die Lösung, das Journal abzuschalten, ist für mich akzeptabel. Unter Mac OS X geht das am schnellsten auf der Kommandozeile:

1

$ sudo /usr/sbin/diskutil disableJournal /Volumes/BACKUP

Frank hatte wohl recht, als er meinte, dass es heute ziemlich voll ist. Alle 4500 3800 Tickets sind verkauft, das BCC platzt aus allen Nähten und wer kein Ticket hat, sollte sich die Talks besser von der Couch aus ansehen.

After upgrading my server from debian etch to lenny, I discovered that the saslauthd was broken. The log looked like this:

SASL authentication failure: Password verification failed
SASL PLAIN authentication failed: generic failure
SASL authentication failure: cannot connect to saslauthd server: Permission denied
SASL LOGIN authentication failed: generic failure

The solution for this problem is documented in /usr/share/doc/sasl2-bin/README.Debian.gz:

• edit /etc/default/saslauthd and set OPTIONS like this:
  OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd"
• run this command as root:
  dpkg-statoverride --add root sasl 710 /var/spool/postfix/var/run/saslauthd
• add the postfix user to the sasl group:
  adduser postfix sasl
• restart saslauthd and postfix

Das schneeballartige Kartenverteilsystem des LinuxTag war wieder großzügig. Wer eine Karte haben möchte schreibts bitte in die Kommentare oder an melle (kringelchen) gmx (punkt) at.

OpenSSL auf Debian etch erzeugt vorhersagbare Schlüssel. Damit können alle seit September 2006 erzeugten Schlüsselpaare als kompromittiert angesehen werden. Betroffen sind Schlüssel für SSH, OpenVPN, DNSSEC, X.509 Zertifikate und Sitzungsschlüssel, die in SSL/TLS Verbindungen verwendet werden.
Besonders prickelnd ist, dass man möglicherweise seinen SSH-Schlüssel auf diversen Maschinen verteilt hat und jetzt erstmal überlegen darf, wo er überall rumgammelt.

Also los! Update einspielen, Keys neu erzeugen und verteilen! Spread the word!

Seit einem Jahr stapeln sich hinter meinem Rücken die ausgedienten Monitore. Natürlich verschmäht man die, weil der LCD-Bildschirm um Welten schärfer ist. Bis der Scheff jedoch einen richtig großes Display spendiert, muss man mühevoll Fenster hin- und her schubsen oder einen wundersamen Fenstermanager bändigen um den Überblick zu behalten.
Nach einem Gespräch mit dem hochgeschätzten Kollegen ist es mir dann endlich wie Schuppen von den Augen gefallen. Auf das Naheliegende kommt man immer zum Schluss: der Rechner hat zwei Monitoranschlüsse, warum schließe ich Dussel nicht einfach einen Zweitmonitor an?
Die Umsetzung war dann mehr oder weniger Trivial, im Ubuntu Forum gibt es ein exzellentes Howto, wie man Xinerama einrichtet.
Der komplizierte Teil ist jetzt zu entscheiden, welches Eclipse-Fenster wo hin kommt und ob man nicht noch mit einer brachliegenden VGA-Karte einen dritten Monitor anschließen könnte…

Das schon an anderer Stelle hochgelobte Script IEs4Linux kann in der aktuellen Beta-Version sogar den Internet Explorer 7 unter Linux installieren. Zwar ist die Lösung etwas schmutzig, weil eigentlich einem IE 6 die Rendering Engine des IE 7 untergeschoben wird, es funktioniert aber sehr zufriedenstellend und man kann endlich alle Versionen des Internet Explorers nebeneinander benutzen.

Safari fehlt leider noch in meiner Sammlung. Falls jemand einen Installer auf der Platte liegen hat, der älter ist als Version 3.522.15.5, würde ich mich darüber sehr freuen. Die letzte Version der Beta zickt nämlich wieder unter Wine herum

Wenn man den Fingerprint eines SSH Public Keys überprüfen will, muss man natürlich wissen, wie der Fingerprint lautet. Mit ssh-keygen findet man schnell den Fingerprint des Schlüssels der eigenen Maschine heraus:

$ ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub
2048 93:f0:3b:3a:c4:0b:ee:f6:b2:47:e0:57:d9:64:0b:55 /etc/ssh/ssh_host_rsa_key.pub

Man muss nur einen sicheren, verifizierten Weg zum Server finden (z.B. über eine Maschine, die den korrekten Fingerprint gecached hat) und schon kann man sich auf diesem Weg auch den Fingerprint des Servers anzeigen lassen.

Es kam gerade die Frage auf, wie man auf chaoshaltigen Veranstaltungen sicher bloggt. Die beste Idee ist natürlich ein VPN. Wenn man kein VPN hat, muss man sich mit der Materie auseinander setzen. Punk

Wenn man diese Option jedoch nicht zur Verfügung hat, kann man sich zumindest einen SSH-Tunnel nach draußen bohren.

Ein erster Wurf würde so aussehen:

ssh your.trusted.server.outside.com -L 8080:blog.mellenthin.de:80

Den Browser könnte man jetzt nach http://localhost:8080 lenken. Leider verwendet Wordpress massiv absolute URLs (die mit http:// anfangen) und umgeht damit unseren Tunnel. Wir müssen also dafür sorgen, dass alle http-Anfragen an http://blog.mellenthin.de/ durch diesen Tunnel gehen.

Das klappt mit einem ziemlich schmutzigen Trick: in /etc/hosts wird einfach folgender Eintrag hinzugefügt:

127.0.0.1       blog.mellenthin.de

Jetzt wird blog.mellenthin.de mit localhost aufgelöst und alle Anfragen gehen an den eigenen Rechner. Der lokale Port des SSH-Tunnels muss noch von 8080 in 80 geändert werden, weil globale URLs den Suffix :8080 nicht enthalten. Das SSH-Kommando sieht dann so aus:

sudo ssh you@your.trusted.server.outside.com -L 80:blog.mellenthin.de:80

Weil man einen lokalen Port 80 öffnen möchte, muss man sudo benutzen. Das führt dazu, dass ssh eine Verbindung als root@your.trusted.server.outside.com aufbaut, deswegen muss man seinen Useraccount auf dem vertrauenswürdigen Server mit you@ vor den Servernamen setzen.

Sobald man via SSH eingeloggt ist, steht der Tunnel. Aufgrund des Eintrags in /etc/hosts klappt eine Verbindung zum Webserver auch nur, wenn der Tunnel steht. Wenn man der Sache nicht traut, kann man mit traceroute und die Route überprüfen:

melle@euphoria:~$ tracepath blog.mellenthin.de
 1:  localhost (127.0.0.1)                                  0.173ms pmtu 16436
 1:  localhost (127.0.0.1)                                  0.056ms reached
     Resume: pmtu 16436 hops 1 back 1

Obacht: der Webbrowser könnte die IPs cachen, also den Browser beenden und neu starten, bevor man bloggt. Außerdem kann das Bash-Timeout zuschlagen (wenn konfiguriert), man sollte in diesem Fall die Umgebungsvariable TMOUT setzen oder eine Anwendung starten (z.B. top), die ein Timeout der Shell verhindert.

Update: der Hinweis von Michael ist natürlich richtig und bringt wesentlich mehr Komfort. Danke für den Hinweis Also wenn man auf dem SSH-Server einen Proxy installieren kann, genügt schon ein simples

ssh your.trusted.server.outside.com -L 3128:localhost:3128

Um sich mit dem Squid seiner Wahl zu verbinden. Am Browser wird als Proxy localhost:3128 eingestellt und fertig ist die Laube. Man sollte aus dem Feld “No proxy for” alle Einträge löschen.

Je länger ich mich mit dem Thema e-Mail beschäftige, desto übler wird mir. Die Prohphezeihungen, dass dieses Medium dank Spam tot ist, halte ich für untertrieben.

Das Problem ist, dass es keinen gleichwertigen Ersatz gibt, so lange alle noch denken “ach es geht schon, 90% Spamquote sind nicht schlimm, das meiste wird ja ausgefiltert…“.

Leider ist überhaupt nicht mehr sicher, ob eine Mail zugestellt wird. Den Satz “Oh, die Mail ist in meinem Spam-Ordner gelandet.” kennt jeder. Instant Messaging ist auch kein gleichwertiger Ersatz.

Keine 24 Stunden zeigt der MX-Record für eine meiner Domains auf den eigenen Server und schon sehe ich das ganze Elend in den Logfiles. In der Mailqueue ist auch gleich folgendes hängen geblieben:

# mailq
-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient-------
3F9CB330079    24400 Mon Jul 30 00:28:37  MAILER-DAEMON
                         (connect to 127.0.0.1[127.0.0.1]: Connection refused)
                                         vcsspa.com@pasaportemexico.com

Huh?

# dig -t MX pasaportemexico.com
(...)
;; ANSWER SECTION:
pasaportemexico.com.    3600    IN      MX      10 127.0.0.1.

Alles klar? Der MX-Record für diese Domain zeigt auf localhost Postfix beschwert sich auch darüber:

warning: numeric domain name in resource data of MX record for pasaportemexico.com: 127.0.0.1

Klar kann man die Mail einfach aus der Queue schmeißen, aber wie man solchen Quatsch für die Zukunft verhindert, schlägt man am besten im Postfix Anti-UCE Cheat Sheet nach.

Falls man sich über merkwürdige Meldungen wie diese

imapd-ssl: malloc: Input/output error

im Syslog wundert, verschaffen folgende Worte Linderung:

/etc/init.d/portmap restart
/etc/init.d/fam restart
/etc/init.d/courier-authdaemon restart
/etc/init.d/courier-imap restart
/etc/init.d/courier-imap-ssl restart
/etc/init.d/courier-ldap restart
/etc/init.d/courier-pop restart
/etc/init.d/courier-pop-ssl restart

Nicht fragen warum, hat mir google ausgespuckt

Falls ich es mal wieder vergesse: Passwörter kann man so generieren:

dd if=/dev/random bs=16384 count=1 2>&1 | openssl enc -base64 | cut -c 1-10 | head -n 1

Wie versprochen die “rundum glücklich”-Lösung für das Backup. Ein grundlegendes Problem ist das Backup im laufenden Betrieb. Noch während das Backup läuft, verändern laufende Prozesse Dateien. Im Allgemeinen ist die /var-Partition und im Besonderen sind Datenbanken und Mailqueues problematisch. Man kann sich nie sicher sein, ob der Stand im Backup wirklich konsistent ist.

Es gibt verschiedene Ansätze dem Problem Herr zu werden. Eine Datenbank könnte man in ein SQL-File dumpen, der Mailserver könnte kurz angehalten werden um die Mailqueue zu sichern. Das sind jedoch alles nur 99%-Lösungen. Eigentlich müsste man das System für den Zeitpunkt des Backups komplett einfrieren, das Backup durchführen und es danach weiterlaufen lassen.

Snapshots implementieren diese Technik und verhindern so eine Downtime des betroffenen Services. Zunächst in Datenbanken wie z.B. Oracle populär, finden sich Snapshots jetzt auch in Dateisystemen (LVM, Windows Vista Shadow Copies). Der Snapshot selbst ist eine atomare Aktion, die lediglich den Snapshot-Zeitpunkt (t) festhält. Alle nach diesem Zeitpunkt (t+x) geschriebenen Blöcke werden separat gespeichert, so dass nun in aller Ruhe alle Blöcke des Zeitpunkt (t) ins Backup wandern können. Ist das Backup beendet, kann der Snapshot verworfen werden.

Mehr…

Viele Hoster stellen Backup-Speicherplatz via FTP bereit. Ärgerlich ist es, dass man zunächst sein Backup lokal erstellen muss um es dann via FTP auf den Backup-Server zu übertragen. Man muss also den Speicherplatz, den man auf dem FTP-Server nutzen will, auch lokal vorhalten.

Für dieses Problem gibt es zum Glück eine elegante Lösung: curlftpfs bindet via FTP erreichbare Resourcen ins Dateisystem ein.

Zunächst braucht man einen Kernel mit FUSE-Unterstützung. Den bringt Debian etch zum Glück gleich mit. Das Modul fuse muss geladen werden. Wenn das Gerät /dev/fuse existiert, ist alles gut gegangen:

# modprobe fuse && ls -la /dev/fuse

Dann brauchen wir die fuse-utils und curlftpfs:

# sudo aptitude install fuse-utils curlftpfs

Damit wäre der schwierige Teil erledigt Jetzt kann man einen kleinen Test wagen:

$ mkdir sunet
# curlftpfs ftp://ftp.sunet.se/ sunet/
# cd sunet/
# ls -l
total 0
Dr-xr-xr-x   3 root root        96 Feb 23  2004 bin
dr-xr-xr-x   2 root root        72 Mar  2  2004 dev
dr-xr-xr-x   2 root root        48 Feb 23  2004 etc
dr-xr-xr-x   2 root root       120 Feb 23  2004 lib
-rw-r--r--   1 root root 622187310 Mar 11 06:13 ls-lR
-rw-r--r--   1 root root  76389037 Mar 11 06:15 ls-lR.gz
drwxrwxr-x  37 root root      1272 Feb 27 14:17 pub
dr-xr-xr-x   3 root root        72 Feb 23  2004 usr
# cd ..
# fusermount -u sunet/

Prima, dann kann also der zugewiesene FTP-Space ins Dateisystem eingebunden werden. Der folgende Eintrag in der /etc/fstab erledigt das automatisch zum Systemstart:

curlftpfs#user:password@11.22.33.44 /media/ftp-backup fuse rw,uid=1000,user,auto 0 0

Der einzige Nachteil ist, dass jetzt das FTP-Passwort in /etc/fstab steht. In dem Fall muss man sie mit

# chmod 640 /etc/fstab

schützen. Wir mounten und testen kurz:

# sudo mount /media/ftp-backup
# sudo ls /media/ftp-backup -la
total 4
drwxr-xr-x 1 melle root 1024 Jan  1  1970 .
drwxr-xr-x 4 root  root 4096 Jul 12 22:04 ..
# mount | grep ftp
curlftpfs on /media/ftp-backup type fuse (rw,nosuid,nodev,noexec)

Das Problem wäre gelöst, das Backup-Programm kann jetzt direkt nach /media/ftp-backup scheiben. Wie man vernünftige Backups anfertigt, wird Inhalt des nächsten Artikels in dieser kleinen Serie sein.

Zum nächsten Teil: Niemand will Backup, alle wollen Restore! »
Zum ersten Teil: Debian Etch auf einem Rootserver mit Raid-1 und LVM »

Es gibt zwar viele gute Anleitungen (wie z.B. diese) zur Einrichtung eines Rootservers mit RAID-1, howtos, wie man dort noch LVM ins Spiel bringt, sind jedoch spärlich gesäht. Deswegen nun die rundum-sorglos copy&paste-Anleitung zur Einrichtung von

Debian Etch auf einem Rootserver mit Raid-1 und LVM

Mehr…