Veni, Vidi, VISA

Eigentlich keine grosse Sache: echo foo | mutt user@name.invalid und der Fall hat sich. Lustig wird es nur wenn man eine Datei anhängen will. Ein echo foo | mutt -a /tmp/jehova.txt user@name.invalid funktioniert normalerweise .. oder auch nicht. Weil wenn sich Mutt dann mit Can't stat user@name.invalid: No such file or directory verabschiedet, dann hat man (wie ich. Haha!) den Fehler gemacht und Mutt 1.5.20 installiert. Da muss das nämlich eine andere Reihenfolge verwendet werden. Nämlich echo foo | mutt -a /tmp/jehova.txt -- user@name.invalid und The -a option must be last in the option list..
Wenn mir das jemand gesagt hätte, dann hätte ich keine Panikattacken bekommen, weil ich seit fast 'ner Woche keine Backups mehr gemacht hab.

Ich mag sie ja irgendwie meine MCSEs, weil sie bei einem Vortrag immer wieder für Kurzweil sorgen.. auch wenns mir jedesmal schwerfällt sie nicht mit meinem Zippo zu bewerfen. Diesen Montag war es mal wieder soweit. Ich war bei einer mittelständischen Firma (~500 Mitarbeiter), weil die eine Lösung für einen Datenbank- und einen Backupserver incl. Netzwerkanbindung gesucht haben (ging nur um die beiden Server, weil die Workstations mit XP liefen und sich das auch nicht ändern sollte).
Die beiden MCSEs halten ihren Vortrag vor mir und labern letztendlich nur das Zeug runter, das auf der Homepage von Windows 7 steht und überlassen mir dann die Bühne mit den Worten "Wir sind gespannt ob Linux mit dieser Vielzahl der Features von Windows 7 mithalten kann"... und jetzt muss ich dazu sagen das die beiden mich noch nicht kannten und deshalb doch etwas aus dem Takt gekommen sind als mein erster Satz "80% der eben genannten Features benötigt ein Server nicht und die anderen 20% sind ohne Probleme mit Linux realisierbar. Der einzige Unterschied ist das unter Linux keine Lizenzkosten anfallen und das den Preis um weit über die Hälfte nach unten drückt!" war.
Das I-Tüpfelchen waren allerdings die Blicke der Vorstandsschaft zu den MCSEs als ich wissen wollte wieso man eine besondere Version von Windows braucht bzw. kostenpflichtig Upgraden muss, nur damit man zwischen mehreren Sprachen umstellen kann (die Frage blieb aber leider unbeantwortet).

Ich muss mir endlich mal eine Liste mit Totschlagargumenten gegen Windows XP/Vista/7 machen und die auswendig lernen. Nächste Woche hab ich ja Zeit, weil ich da 'n Datenbank- und Backupserver installieren :>

Es gibt nicht viele Dinge, die Männer noch als ihre alleinige Domäne reklamieren können. Als Produzenten von Sperma waren sie bisher aber unbestritten unersetzlich. Das hat jetzt ein Ende: Britische Forscher haben erstmals im Labor menschliches Sperma gezüchtet.
[Ganzer Artikel bei Der Tagesspiegel]

Zitat des Admins neben mir: Künstliche Spermien können keinen Spinnen töten oder Schränke verrücken..
Ich mag ihn irgendwie *g*


Wir sitzen noch im Serverraum, weil das "kleine Problem" mit dem Datenbankserver zu einer mittleren Katastrophe mutiert ist. Es gibt eine Datenbank mit sämtlichen Kundendaten, welche auch auf einem Backup vorhanden ist. Das Problem an der Sache ist nur, dass verschiedene MySQL-Dumps eingespielt wurden und jetzt sämtliche Kisten die Daten der alte Datenbank einlesen und abarbeiten. Gut das es nicht mein Backup-Script war, sonst wär ich wieder an allem schuld (aber das kommt sicher noch *sigh*).

Nachdem ich schon die vierte Mail mit der identischen Frage bekommen habe, schreibe ich jetzt mal hier damit auch andere ggf. was davon haben. Ich habe mehrere Rechner rumstehen, wobei auf allen ein Backup gemacht wird. Die Kisten dienen unterschiedlichen Zwecken:
- Workstation
Darauf (Laptop und Desktop) erledige ich meine täglichen Arbeiten und dort ist die Aufteilung der Festplatte folgende:
/, /boot, /usr/*, /tmp und noch /var. Diese Verzeichnisse liegen auf unterschiedlichen Partitionen der gleichen (verschlüsselten) Festplatte und die Daten darauf werden nicht gesichert; /etc liegt zwar ebenfalls auf der gleichen Festplatte wie /, /boot und Konsorten, jedoch wird /etc täglich gesichert.
/home liegt auf einer anderen (ebenfalls verschlüsselten) Festplatte und wird zusätzlich täglich auf einem externen Host gesichert. Auf diesem Host installiere ich fast nur Software über das vorhandene Paketmanagementsystem mit dem ich auch eine Liste der bereits installierten Software erstellen lasse. Optionale Software, welche aus den Sourcen installiert wird, kompiliere ich mit ./configure --prefix=${HOME}/dev-bin. Im Falle eines Hardwarecrashes installiere ich das Grundsystem neu und anschließend wird mittels der Paketliste die Software wieder eingespielt; /home und /etc werden schlicht und einfach via rdiff-backup zurückgespielt und der Fall hat sich.

- Server
Das ist mein privater Mail-, Web-, FTP-, NNTP- und CVS/SVN/... - Server. Dort ist die Struktur ähnlich; auch hier wird /, /usr, .. nicht gesichert. /etc wird wie auf der Workstation ebenfalls täglich gesichert. Die unterschiedlichen Homedirectories der Server (Apache, vsftp, ..) liegen alle unter /home. Also

/home/www

/home/ftp

/home/cvs

/home/nntp

etc.

So bleibt es übersichtlich und ich kann die Backups einfacher erstellen. Im Falle eines Hardwarecrashes gilt das gleiche wie für meine Workstation. Ich installiere das Grundsystem neu und spiele die Paketlisten wieder ein und das Backup zurück.
Note: Das ist eine WFM-Lösung, weil ich mir Zeit lassen kann mit dem Backup und wenn die Kiste zwei Tage offline ist, dann spielt das auch keine Rolle.

- Backuprechner
Das ist etwas komplizierter. Auf der Kiste werden die Backups von allen anderen Rechnern gespeichert auf internen Festplatten gespeichert. Momentan ist die Kiste mit insg. vier HDs bestückt: 2x 500GB und 2x 300GB; außerdem sind noch zwei DVD-Brenner eingebaut, auf denen ich in regelmäßigen Abständen (zur Zeit einmal pro Woche) die Backups zusätzlich auf DVD+RW sichere. Aktiviert wird die Kiste entweder manuel oder via wake-on-lan.

- Testrechner
Backup?! Wozu? Wenn tot, dann tot!

Was allgemeines zu den Backups: Ich erstelle meine Backups mit rdiff-backup (kombiniert mit SSH. Guckst Du unter http://www.howtoforge.com/linux_rdiff_backup). Im Normalfall ist ein geschrotteter Server innerhalb von ~1h wieder einsatzbereit, wobei das aber stark von der installierten Pakete und Grösse des Backups abhängt.

Sollte jetzt noch was unklar sein, dann bitte hier im Kommentarbereich fragen.

Die Frage wurde mir heute gestellt, nachdem ich gesagt habe, dass die momentan eingesetzte Backuplösung Scheisse ist. Naja.. prinzipiell ist ein Backup via ftp(1) nicht unbrauchbar, aber in dem Fall schon.
Das Backup wurde aus einem Einzeiler mit tar(1) und find(1) erstellt und das gepackte Archiv anschließend aus dem Backupscript heraus via lftp -u username,password <ip-adresse> übertragen. Das Problem an der Sache ist nur, dass jeder User auf der Kiste mit einem ps ax | grep lftp an die Logindaten kommen kann. Immerhin war NcFTP installiert welches dann auch genutzt wurde. Das macht es nämlich besser

$ ps ax | grep ncftp

11724 pts/0    S+     0:00 ncftp -u **** -p ********** ftp.host.invalid

Wieso sie nicht einfach rsync(1) oder ähnliches einsetzen, wollte ich dann doch nicht wissen.

Nein. Kein Aprilscherz! Hab heut meinen guten Tag, weil ich heute mal wieder mit einem richtigen Arschloch (im positiven Sinne) zusammen arbeiten darf :>

rdiff-backup /home/username /Backups/username

Obiges erstellt im Verzeichnis /Backups/username ein Backup von /home/username. Der erste Aufruf von rdiff-backup dauert etwas länger, weil eine Dateiliste erstellt wird.

Will man bestimmte Dateien/Verzeichnisse nicht im Backup haben, kann man das auf zwei Arten erreichen. Die erste ist --exclude als Option und die Dateien/Verzeichnisse als Argument anzugeben; also

rdiff-backup --exclude '*.bak'

oder (was ich wegen der Übersichtlichkeit bevorzuge) die Option --exclude-globbing-filelist zu verwenden. Das sieht dann so aus:

rdiff-backup --exclude-globbing-filelist /home/username/exclude_home /home/username /Backups/username

In der Datei /home/username/exclude_home stehen dann z. B. Einträge wie

/home/username/tmp/*

/home/username/.cpan/*

/home/username/*.bak

Eine weitere nützliche Option von rdiff-backup ist --exclude-special-files, welche Devices, Sockes, Fifos und symbolische Links ausschließt. Man sollte diese allerdings auch wirklich nur verwenden, wenn man keine Symlinks benötigt (sonst schießt man sich in /etc gezielt ins Knie).

Das Restore geht genau so einfach wie das Backup selbst, aber man hat die Möglichkeit entweder das gesamte Backup oder nur einen Teil wieder herzustellen. Das letzte Backup kann man mit

rdiff-backup --restore-as-of now /Backups/username .

einspielen. now ist das zuletzt erstellte Backup und . sorgt dafür das die Dateien im $PWD landen. Hat man z. B. seine Kiste geschrottet und will das Backup von $HOME einspielen, dann legt man zuerst sein $HOME an (useradd, adduser, ..), wechselt in das Verzeichnis und gibt dann obiges Kommando ein. Wenn man versehentlich /home/username/p0rn gelöscht hat, reicht ein

cd p0rn && rdiff-backup --restore-as-of now /Backups/username/p0rn .

und das wars.

Bei Interesse kann ich mal mehr zum Thema Backup schreiben, maybe..

In memory of "Es kann nicht sein das Ihr Backup-Script nicht funktioniert!".
$Admin hat sich vorhin beschwert weil auf einem Server den ich installiert/konfiguriert habe, das Backupscript nicht funktioniert und es keine Backups anlegt. Ergo hab ich mir das Script angesehen ob es ggf. verändert, die Rechte entzogen oder es gelöscht wurde, aber nada. Nach einiger Zeit der Fehlersuche sprang mir dann folgendes ins Gesicht:

$ ls -l /etc/init.d/cron

-rw-r--r-- 1 root root 1510 2007-12-26 16:23 /etc/init.d/cron

und nach einem

$ pgrep -l cron

$ echo $?

1

war mir irgendwie klar wieso keine Backups angelegt wurden.

Das niemand was an dem Server geändert hat is ja wohl klar oder?!

".. weil wir auf dem ftp-Server zum einen unsere Backups speichern und zum anderen weil wir da auch mehrere Useraccounts haben die einen FTP-Zugang benötigen

$ lsof -i TCP | grep ftp

[...]

proftpd   14947     proftpd    1u  IPv6 1747813272      0t0  TCP *:ftp (LISTEN)

[...]

vsftpd    15233        root    3u  IPv4 1747816659      0t0  TCP *:180 (LISTEN)

öhm.. ja.
Wie kommt man eigentlich auf die wahnwitzige Idee die Backups auf einem "öffentlichem" Server zu speichern auf dem zudem noch Shellaccounts vergeben werden? Und vor allem: Wieso zwei ftpd's und nicht einfach 'n Virtual Host anlegen und dem dann auf einem anderem Port legen (so wie es bei den beiden bereits installierten ftpd's der Fall war)?
Manchmal glaub ich das die das alle mit Absicht machen weil ihnen mein WTF!?-Gesichtsausdruck so gefällt.

$ADMIN hat einen Webserver aufgesetzt und ein Perlscript unter ./cgi-bin abgelegt. Nach einiger Zeit tauchte fuer dieses Perlscript ein Exploit auf, welches das Auslesen/Ausfuehren von lokalen Dateien ermoeglicht. $MAINTAINER des Scripts hat keinen richtigen Patch rausgebracht, sondern lediglich eine kurze Anleitung mit Instruktionen was zu aendern ist. $ADMIN macht das und wundert sich nach einiger Zeit wieso sein Webserver gecrackt wurde. Er hat mir versichert das er das Script exakt nach den Vorgaben geaendert hat, was ja auch stimmte. Bringt nur relativ wenig wenn script~ noch mit 755 unter ./cgi-bin rumliegt.
Jetzt hab ich neben "Uebersichtlichkeit" wenigstens noch ein Argument fuer

if has("unix")

        if !isdirectory(expand("~/tmp/."))

                !mkdir -p ~/tmp/

        endif

endif

set bdir=~/tmp

...wurde mir heute am spaeten Nachmittag von einem Admin im Beiseins seines Chefs vorgeworfen. "Es funktioniert nach Einspielen des Backups durch Ihr unbrauchbares Backup-Script auf dem Host naemlich kein einziges Programm mehr!". Ich mich etwas verwirrt bzw. erstaunt an den Server gesetzt und wollte ihn hochfahren, was anhand 8.4 Millionen Zeilen an Fehlermeldungen nicht funktioniert hat. Also GRML rein, davon gebootet, die Partitionen gemountet und was mussten meine Augen nach einigem Rumhacken im System sehen?

$ file /bin/login

/bin/login:ELF 64-bit LSB executable, x86-64, version 1 (SYSV), [..]

Eigentlich auch in Ordnung wenn getconf LONG_BIT nicht 32 ausgegeben haette. Gut das ich die Dokumentationen/Scripte/Patche/.. immer auf CD gebrannt uebergebe (aber das habe ich ja hier schonmal geschrieben). So war er naemlich in Erklaerungsnot als auf dem System im Backup-Script die Zeilen

# WICHTIG: Dieses Backup-Script ist abhängig von der Architektur des Systems, 

#          da NICHT die Paketauswahl, sondern die bei der Installation

#          eingespielten und vorkompilierten Packages eingespielt werden!

#          Ergo MUSS die Architektur beider Systeme identisch sein!

SARCH="$(getconf LONG_BIT)"

if [ "${SARCH}" != "64" ];

    then

           echo 'Die Systemarchitektur stimmt nicht überein!'

           exit 1

    else

          [....]

kommentiert waren, waehrend das in dem auf CD gebrannten Script nicht der Fall war und der Probelauf im Beiseins einer dritten Person problemlos funktionierte.

Zur Erklaerung: Das Script lief auf einem Debian-Server (i686, 32Bit) den ich vor einiger Zeit mal aufgesetzt habe. Das die vorkompilierten Programme und nicht die Paketliste eingespielt wurde so gewuenscht. $ADMIN hat (wieso auch immer) das Backup-Script eines anderen von mir aufgesetzten Server (x86_64, 64Bit) auf dem i686, 32Bit - Server genutzt und im Script selbst die Zeilen kommentiert, die exakt das verhindern sollten. Ich hab auch keine Ahnung wie er es geschafft hat die Packages auf einer anderen Architektur zu installieren (Funktioniert das ueberhaupt einfach so? Hab ich noch nie ausprobiert. Anyone?!), geschweige denn wie er das anschliessend seinem Chef erklaert hat der waehrend der Fehlersuche hinter mir stand und mir auf die Finger gesehen hat.

Es sind halt die kleinen Dinge die das Leben erst lebenswert machen.