Linux

Die vergangene Woche habe ich mich ein wenig mit OpenLDAP beschäftigt. Das ganze unter Debian.
Angefangen hat es mit einem Sarge-System und somit stand erstmal ein Upgrade auf etch an.
Bis auf ein paar Dependencies sah das dist-upgrade gut aus, allerdings scheiterte das Upgrade beim Wiedereinspielen des OpenLDAP-Backups (dies passiert automatisch):

Nach einigem Suchen war dann klar, dass hier das Backup nicht korrekt erstellt wurde. Hier ein Beispiel:

Ursache waren die zwei Minuszeichen bei der Telefonnummer...
Weil der LDAP sowieso gerade gewartet wurde, wurde gleich noch das Standard-Passworthash-Format auf SSHA geändert (Salted SHA). Es hat ein wenig gebraucht, bis ich begriffen hab, dass das Salt nicht pro Server ist (wie es manche Anwendungen machen) sondern pro Passwort. Ab da war das Umsetzen kein Problem - jetzt müssen nur noch die Benutzer das Passwort ändern und unsichere Hashes wie md5 oder bei manchen Benutzern noch crypt sind vergangen.

Somit verlängerte sich die Downtime auf fast zwei Stunden. Damit ist schon klar, warum der nächste geplante Schritt die redundante Auslegung des LDAP-Servers war. Nach einigem Lesen von Anleitungen stand dann am zweiten Abend die Push-Replikation vom Publisher zum Consumer mit syncprov. Änderungen können an beide Server geschickt werden, allerdings verweist der Consumer dann einfach auf den Publisher. Das DNS dann auf Round Robin umzustellen war eine Kleinigkeit
Am nächsten Morgen kamen dann die Beschwerden: einige Benutzer konnten sich nicht mehr einloggen. Schnell war klar, dass die betroffenen Benutzer alle auf einem anderen LDAP-Server liegen. Eingebunden wurde dieser Server über ein Referral. Das Problem ist aber, dass der Consumer-LDAP-Server versucht das Referral zu verfolgen. Dies klappt natürlich nicht, da die Zugangsdaten für die Replikation nur auf dem Publisher-LDAP-Server gültig sind. Davon war aber nichts in den Logdateien zu finden (eingestellt auf Loglevel sync). Dennoch setzt der Consumer die Replikation fort und steht dann auch komplett zur Verfügung - es fehlt halt nur eine OU...
Bislang habe ich dafür keine Lösung außer von Hand das Referral auf dem Consumer in die Datenbank zu schreiben und dem Replikationsbenutzer alle Rechte auf den Referraleintrag beim Publisher zu entziehen.

Mit dem Referraleintrag hatte ich aber noch mehr Spaß. Nächster Schritt war die Einrichtung von Samba. Komischerweise führte das Starten von Samba oder Benutzer von "net getlocalsid" zu einer Verzögerung. Erst ein erhöhtes Debugging-Level brachte an Licht, dass Samba im Referral-OU nach seinen Einträgen suchen will. Und wieder wird der konfigurierte Benutzer verwendet sich am anderen LDAP-Server anzumelden - was natürlich immer noch nicht klappt. Auch hier war wieder die Lösung dem Samba-Benutzer die Rechte auf das Referral zu entziehen.
Da kann man sich doch nur fragen wie selten ein Setup ist, bei denen ein LDAP-Server auf einen anderen verweist ohne das die LDAP-Server vom selben Administrator eingerichtet und gewartet werden?


Wer schonmal Samba aufgesetzt hat, kennt das Passwort-Problem: Samba braucht eine eigene Passwortverwaltung. Eigentlich kein Problem - immerhin sieht das Samba-Schema im LDAP ja die passenden Felder dazu vor. Nur müsste so der Benutzer zwei Passwörter pflegen bzw. darf nicht mehr passwd auf den Linux-Servern benutzen sondern nur noch smbpasswd. Aber dafür gibt es eine Lösung: ein OpenLDAP-Modul namens smbk5pwd was automatisch bei der Passwortänderung auch die Samba-Felder updatet. Eigentlich sollte das Verwenden kein Problem sein. Das Modul besteht aus drei Dateien: Makefile, README sowie die eigentliche Sourcecode-Datei. Da das Modul gegen die entsprechende Serverversion gebaut werden muss, habe ich per apt-get source slapd mir die Sources des Debian-Pakets geholt und wollte das Modul bauen. Nachdem ich erstmal die Makefile angepasst hatte, ging es an die Compile-Fehler. Mit Hilfe einer aktuelleren Version konnte ich alles ändern und bekam schließlich das Modul. Nur leider ließ es sich nicht fehlerfrei einbinden:


Ich gebe also auf die Passwörter über das OpenLDAP-Modul auf gleichen Stand zu halten und werde eine andere Lösung suchen. Wahrscheinlich einfach auf dem Shell-Server für die Benutzer den Zugriff auf passwd auf smbpasswd verbiegen.

Ich habe heute meinen Abend (neben dem TV-Programm) damit verbracht, den Vanilla-Kernel als Xen domU laufen zu lassen. Eigentlich dachte ich das kann doch kein Problem sein: nur einen neuen Kernel bauen, Xen domU neu anlegen und fertig. Aber weit gefehlt.
Das erste Problem war, dass der Kernel nicht booten wollte: das boot device wurde nicht gefunden ("VFS: Unable to mount root fs"). Aber immerhin gibt es eine Liste der gefundenen Devices: xvda1 sowie ein paar mehr.
Also erstmal das root-Device in der domU-config geändert und die fstab angepasst. Nächstes Problem: die Devices xvda1, xvda2 und xvda3 existieren nicht (ja, ich verwende kein udev für domUs). Also per mknod angelegt und schon konnte das System wieder booten. Nur blieb die Ausgabe einfach nach dem Start der Daemons stehen - kein Loginprompt und auch keine Reaktion auf Sysrq-Befehle (Strg+O). Nach einiger Suche (und einigen Fehlinfos zum Thema xencons) war dann klar: das Konsolendevice ist hvc0. Dies muss erstmal wieder per mknod angelegt werden und dann noch in inittab und securetty eingetragen werden (danke an ganto für den Hinweis/Anleitung).

Warum ich das ganze trotzdem machen will: die Xen-Sources von Gentoo sind hoffnungslos veraltet. Weiterhin kann ich so die GRSec-Patches verwenden.

Ich weiß nicht welche Drogen die Cups-Entwickler da genommen haben, aber man kann doch nicht etwas zuerst dokumentieren und erst in einer sehr viel späteren Version implementieren!?

Als gültige Option für BrowseProtocols (sowie BrowseLocalProtocols und BrowseRemoteProtocols) ist in der Dokumentation dns-sd angegeben.

Ein Grep auf den Source-Code von Debian-Stable zeigt aber, dass das nirgendwo implementiert ist:


Im Changelog findet man dann für Version 1.3:


Da kann ich lange per querylog/tcpdump drauf warten, dass sich der Cups im DNS registriert

Ich habe gerade eine Stunde damit verbracht herauszubekommen warum ich mit Grub keinen Bootsektor auf meine neue Hardware schreiben konnte.

Als Fehlermeldung bei setup (hd0) kam immer nur


Ansonsten wurde alles richtig erkannt (also hd0,0 als ext3 etc).

Die Ursache ist eigentlich trivial, aber wohl bislang nicht so verbreitet im Netz.
Erst bei Ubuntu in der Bug-Database fand ich einen Hinweis (ID 20700):

From http://sidux.com/Article416.html :
"...
- e2fsprogs ≥ 1.40.5 creates ext3 filesystems with 256 byte large inodes by default (in contrast to 128 byte used before), to accommodate for further ext4 related changes ( http://e2fsprogs.sourceforge.net/e2fsprogs-release.html#1.40.5 )
...

Grub ist bei Gentoo noch nicht aktuell genug - dort ist der Patch zwar schon vorhanden, aber die Version 0.97-r5 ist immer noch maskiert:

*grub-0.97-r5 (25 Mar 2008)

25 Mar 2008; Robin H. Johnson +grub-0.97-r5.ebuild:
New version of the Gentoo grub patchset. Provides support for 256-byte
ext3 inodes per bug #214563. Fixes unhide bugs with GPT patch per bug
#211584. Long commandlines per bug #183443. Xen memorysize fix per bug
#188312.

Lösung: entweder die neuste Grub-Version nehmen (unmask der Version 0.97-r5) oder einfach beim Anlegen der (Boot-)Partition den Parameter -I nutzen:
mkfs.ext3 -I 128 /dev/[bootdevice]

Wer einen schnellen Mirror für Ubuntu sucht:
ftp://ftp.fbihome.de und http://ftp.fbihome.de

Der Server taucht nicht in der offiziellen Liste auf ist aber sehr schnell angebunden.

Bei uns im studentischen Netzwerk hatten wir letztens das Problem, dass ein infiziertes Notebook massenweise Spam-Mails in die Welt geschickt hat. Innerhalb von 15 Minuten waren das 2.500 ausgehende Spam-Verbindungen.

Da wir nicht komplett Port 25 sperren wollten (wie beispielsweise die TU Darmstadt), habe ich eine Anpassung der Firewall vorgenommen, die den normalen Benutzer nicht einschränken sollte aber solch Spam-Versender effektiv behindert.

Das ganze basiert auf dem IPTables-Modul recent.


In der Chain auth_out landen nur ausgehende, neue Verbindungen (-m state --state NEW).

In Zeile eins wird jede ausgehende Verbindung im Chain auth_out auf Port 25 gespeichert (unter dem Namen SMTP_OUT). Recent speichert das ganze automatisch in der Defaulteinstellung unter der Abenderadresse.
In Zeile zwei wird dann bei jeder weiteren SMTP-Verbindung geprüft ob innerhalb von 180 Sekunden mehr als 20 Verbindungen aufgebaut wurden und falls es zutrifft in spam_warn gesprungen.
In der Zeile drei wird dann der gesamte Internetzugang für eine Absender-IP gesperrt falls weitere SMTP-Verbindungen aufgebaut wurden. Andere Pakete zählen aber nicht zu dem Hitcount dazu (deswegen nur rcheck anstatt von update).

In /proc/net/ipt_recent/SMTP_OUT kann man die Liste der gespeicherten Absender-IPs und deren Timestamp anschauen bzw. sogar modifizeren

Weitere Möglichkeiten sind online bei Linux Magazin beschrieben: Hausverbot

Seitdem die Regeln aktiv sind, wurde eine weitere Spam-Welle eines verseuchten Notebooks verhindert - 65227 verhinderte SMTP-Verbindungen innerhalb von ein paar Stunden!
Wer also nicht Port 25 komplett sperren will, sollte eine solche Sperre benutzen um den Katastrophenfall zu verhindern.

Xen und GRSec?
Das wäre eine schöne Sache aber die beiden Patches sind leider nicht miteinander kompatibel.
Da ich aber für einen studentischen Server ein Feature ganz besonders verwenden will, habe ich mir eben die Mühe gemacht dies aus den GRSec-Patch in meinen Xen-Kernel zu patchen: jetzt sehen Benutzer nur noch ihre eigene Prozesse (CONFIG_GRKERNSEC_PROC_USER)

Keine Ahnung warum die GRSec-Crew einen Megapatch produziert hat anstatt das ein wenig modularer zu machen.

Man sollte sich fragen, warum man den Rechner länger nicht mehr benutzt hat, wenn man folgendes in der Kernelausgabe liegt:

md: raidstart(pid 5907) used deprecated START_ARRAY ioctl. This will not be supported beyond July 2006

Da denkt man, es wäre kein Problem mit pam_ldap sich gegen mehrere LDAP-Server zu authentifizieren. Aber man wird schnell eines besseren belehrt...

Mein erster Ansatz: einfach die "auth"-Zeile in der passenden pam-config duplizieren und als Parameter einfach eine weitere Config-Datei angeben. Theoretisch wäre das ja möglich - immerhin gibt es einen config= Parameter für das PAM-Modul. In der Doku steht aber auch:

Configuring multiple instances of pam_ldap for the same service with different configuration files is not supported, because the configuration information is cached.

Blöd - aber es gibt ja auch noch den LDAP-Weg: Referrals.
Nachdem der Referral auf den zweiten Server eingerichtet war, wollte es aber nicht so ganz funktionieren. Aus dem Log-File war ersichtlich, dass der Referral wohl verfolgt wird, aber das Binden danach nicht klappt:

pam_ldap: error trying to bind as user "uid=1234567,dc=testsystem,dc=de" (Invalid credentials)

Eine genaue Analyse brachte dann die Ursache heraus - hier die Schritte vereinfacht dargestellt:
C1: pam_ldap verbindet sich anonym gegen ersten LDAP (S1)
S1: antwortet mit referral
C1: ldap client lib ruft die rebind_proc Methode in pam_ldap auf und bindet sich erfolgreich anonym gegen den zweiten Server (S2)
C1: sendet aufgelöste UserDN und Passwort an S1

Hier liegt natürlich der Fehler. Der Client verfolgt den Referral erfolgreich aber bindet dann gegen den ersten Server!?

Der andere LDAP-Weg ist leider nicht umsetzbar - auf den zweiten LDAP-Server bekomme ich kaum einen authorativen Benutzer mit dem der erste LDAP-Server gegen den zweiten verbinden könnte (dann müsste nicht mehr der Client den Referral verfolgen sondern der erste LDAP-Server selber).



Also bleibt jetzt die einzige Lösung zu warten auf die Reaktion des "Herstellers" PADL - Bug 357

Was passiert, wenn man ein Debian-System (unstable) lange auf Platte hat und nicht aufräumt?
Richtig: man hat ca. 80 Kerneleinträge in der grub.conf.

Was probiert der Hacker dann aus?
Richtig: wann bekommt Grub zuviel?
Ergebnis: bei 600 Einträgen lädt Grub zwar noch aber der Rechner rebootet vor der Anzeige des Bootmenüs..

Aus der Doku:

Menu Interface: A menu-interface listing the preset boot commands, with a programmable timeout, is available. There is no fixed limit on the number of boot command-set entries, and should have space for several hundred.

Jetzt wissen wir was "several hundred bedeutet

Ich dachte eigentlich, dass es so langsam keine Speichergrenzen mehr geben sollte.
Dann versuchte ich eine 2,2 TB Festplatte (so gibt der Raid-Controller es weiter) einzurichten.

Fazit: cfdisk und fdisk in die Tonne geworfen. Jedes mal wenn ich eine 2,2 TB Partition anlegen wollte, war zwar die Anzeige in Ordnung aber beim Neuöffnen des Programms war ersichtlich, dass nur eine 50GB Partition angelegt wurde Einzige Lösung: parted
In parted selber muss der Partitionstabellentype auf gpt geändert werden. Danach kann endlich eine Partition angelegt werden..

Endlich ist es soweit: Apache 2.2 ist unter Gentoo stable

Da weiß ich schon was ich das Wochenende vor habe..

Nach ein wenig Vorbereitung habe ich soeben innerhalb von einer Stunde die Migration von Courier-Imap auf Dovecot erfolgreich beendet.

Nicht nur die Folien von Ralf Hildebrandt haben mich schnell überzeugt zu wechseln. Die Config ist leicht lesbar und ich fand mich gut darin zurecht. Das zeigte sich dann auch an der schnellen Migration - einfach 1A

Der einzige Courier-Überrest ist jetzt nur noch maildrop - aber das will ich auch noch behalten.

Heute habe ich mal wieder schnell ein Linux gebraucht. Ich wollte keine Zeit mit aufwändigen Config-Änderungen verbringen und entschied mich somit für Ubuntu Version 7.04. Da ich für das Projekt Rechenpower benötigte, war das Ziel mein Gaming Rechner.
Nachdem endlich die Live-CD gebootet war (irgendwas hat ewig lang gebraucht und es war kein Hinweis wie man den blöden Bootscreen ausschalten kann ohne es direkt beim Booten einzustellen. Die mir bekannten Tastaturkombinationen gingen auch nicht) ging die Installation schnell über die Bühne. Nach dem obligatorischem Reboot war erstmal Patchen angesagt (immerhin gab es hiervor eine direkte Aufforderung). Wenn man dann gerade mal wieder über eine langsame Internetverbindung online ist, merkt man welche Datenmengen da anfallen - über 175 MB bedeuten quasi eine ebenso lange Installationszeit wie Download/Patch-Zeit
Gerade bei OpenSource würde ich erwarten, dass ein Server die Installations-CD immer wieder aktuell hält - da steckt ja quasi kein Aufwand dahinter.
Wobei mir heute wieder mal negativ aufgefallen ist, dass unter Debian (und somit auch Ubuntu) immer noch ein Programm gleichzeitig Pakete managen darf. Blöderweise wird das Lock schon während des Downloads gesetzt. Also eine halbe Stunde lang keine anderen Pakete parallel installieren Da lobe ich mir doch emerge.

Nachdem ich mir dann endlich dvdrip installiert hatte und meine ersten Schritte unternahm, stolperte ich über eine fehlende Abhängigkeit: die vorbis-tools fehlten. Ein Bugreport dazu existiert schon seit knapp zwei Monaten.
Das VIDEO_TS Verzeichnis wollte ich mir noch von meinem Notebook saugen. Dank integrierten SMB-Client sollte das kein Problem sein: einfach mit Server verbinden, Freigabe auswählen und den passenden Ordner kopieren. Aber dann wurde es komisch: ich konnte den Ordner markieren und per Rechtsklick Kopieren anwählen aber ein Einfügen im Lokalen Ordner hatte keine Wirkung. Nur verschwand dann auf einmal der Ordner in der Auflistung der Ordner unter der Freigabe - ohne jede Fehlermeldung.
Also versuchte ich den umgekehrten Weg: eine Freigabe auf dem Rechner einrichten. Schnell dafür Samba installiert und über die grafische Oberfläche ein Share angelegt. Nur steht dort kein Hinweis auf den User. Da ich mich mit Samba auskenne, war das kein Problem - einfach mit smbpasswd einen neuen Benutzer angelegt.. So funktionierte dann auch das Kopieren der DVD-Dateien..

Besonder ärgerlich war jedoch die fehlerhafte Auflösung. Auch nach der (löblicherweisen sehr einfachen) Installation der Nvidia-Treiber (inkl. anschließendem Reboot) war das höchste der Gefühle nur eine 1280er Auflösung. Das sieht auf einem 1680er Widescreen TFT natürlich nicht gerade berauschend aus. Dadurch entsteht das Gefühl, dass man irgendwas beim DVD-Konvertieren falsch gemacht hat, wenn man statt einem Kreis ein Oval sieht

Als Spielerei habe ich dann mal die Desktop Effects ausprobiert. Leider wurden alle Fensterinhalte nach Aktivierung unscharf. Also schnell wieder aus geschaltet.


Fazit: Ubuntu wird so langsam immer besser. Für ein "Out of the Box alles korrekt" ist aber noch ein gutes Stück Weg übrig

Wenn das mal kein Memory-Leak ist:



und ich wundere mich, warum mein Server anfängt über 500 MB Swapspeicher zu benutzen..

Seit langem habe ich den Plan mir einen HTPC zu bauen.

Bislang nutze ich dafür meine alte, gemoddete Xbox. Die hat jedoch einige Nachteile und fehlende Features. Am nervigsten: die fehlende Erdung - man bekommt ein starkes Brummen sobald man das LAN-Kabel einsteckt
Auch die langen Bootzeiten durch den fehlenden Standby-Support hindern des öftern die Xbox anzuwerfen.

Ziel ist es nun mehr als nur ein Videoabspielgerät zusammenzubasteln. Es soll ein Festplattenrekorder her, der mindestens zwei Programme gleichzeitig handeln kann (Beispielsweise eins aufnehmen und eins wiedergeben).
Da die Werbung in der letzten Zeit immer mehr stört, sollte das temporäre Speichern auf Festplatte bei Pause und das Überspringen von Werbung funktionieren.

Derzeit kommt das TV-Programm bei mir über einen iesy-Kabelanschluß ins Haus. Dank der wirklich bescheuerten "Wir verschlüsseln alles Digitale"-Einstellung und den zusätzlichen Extrakosten ist Digital-TV über Kabelanschluß keine Option (leider)..
Da aber noch auf dem Dach eine Sat-Schüssel mit Universal-LNB ist, lag es nah, sich die Totale Verdummung per DVB-S zu holen - besser noch: DVB-S2 mit HD-Material


Schritt 1: Grundsätzliche Anforderungen
Die große Frage: Linux oder Windows?
Bekannte Software für beide Systeme: MythTV und das Windows Media Center.
Beide bieten die gewünschten Funktionen und Extras wie EPG, Anzeige von RSS-Feeds usw.
Ein grundsätzliches Problem ist jedoch die Hardwareunterstützung. Zwar besserte sich die Unterstützung diverser DVB-Karten durch den aktuellsten Linux-Kernel in den letzten Monaten aber beim DVB-S2-Support sieht es doch recht mager aus
Das Windows Media Center wurde zwar für XP mit zwei großen Patches wesentlich verbessert, State of the Art ist aber das Vista Media Center. Dort bekommt man meistens nur BDA-Treiber für die 32bit Variante.
DVB-S2-Karten werden generell unter Windows unterstützt, aber einige Probleme stehen noch aus
Windows hat aber einen entscheidenen Vorteil: ausgereifter Standby-Support. Ich will zwar nicht mit der Öko-Masche kommen aber die Stromrechnung sollte nicht exorbitant hoch ausfallen
Außerdem weiß ich so, dass der Grafikkartentreiber meine CPU auf jedenfall entlasten wird.


Schritt 2: Test-Ausrüstung besorgen.
Da ich nicht sinnlos Geld in den Sand setzen will, muss natürlich alles vorher getestet werden. Das dies nötig war, zeigte sich kurz später - aber dazu komme ich noch.

Empfohlen wurden mir Technisat-Karten. Problem: das noch vorhandene Kabel-TV kann nicht genutzt werden ohne eine weitere (analoge) Karte.
Also fiel meine Wahl nach längerem Suchen auf die Hauppauge HVR-4000 - Unterstützung für Analog, DVB-T, DVB-S und natürlich DVB-S2. Nachteil: Linux-Treiber sind gerade erst im Entstehen.

Die Installation klappte wunderbar. Das Kabel-TV ließ sich unter MCE allerdings erst nach der Installation des SoftMCE-Encoders in Gang setzen. Dann klappte aber alles wunderbar
Nach etwas Kabelverlegen gab es dann nun auch Sat-Anschluß am Testrechner. Wiederrum musste ein Patch installiert werden, damit alles klappte: DVBS_as_DVBT - ein Emulator, der dem Media Center eine DVB-S-Karte als DVB-T vormacht.
Problem: DVB-S2 wird vom DVB-T-Mapper nicht unterstützt. Ob das nur vorzeitig so ist, ist mir bislang nicht bekannt
Also gerade das Ziel, HDTV zu bekommen nicht erfüllt
Man kann zwar die mitgelieferten Anwendungen benutzen aber an das Media Center kommen die Programme bei weitem nicht dran.
Wunderbar funktioniert die StandBy-Funktion: wenn eine Aufnahme geplant ist, wacht der Rechner dank ACPI automatisch wieder auf - so soll das sein

Jetzt muss ich mir erstmal meine Ziele neu überdenken. U.a. auch weil HDTV natürlich eine viel stärkere Hardware als HTPC braucht als einfache DVB-S- bzw Analog- Aufnahme und Wiedergabe.

Manchmal bin ich echt froh, dass ich in Punkto Sicherheit ein wenig mehr Aufwand reinstecke.
So wurde gestern abend einer meiner Apache-Vhosts gehackt und eine Remote-Shell hochgeladen (Ursache: eine alte PHP-Software, die eigentlich schon geupdatet wurde aber von einem Sicherungs-Restore wieder auf die alte Version zurückgesetzt wurde )

Dank sauberer Trennung der Vhosts (jeder Vhosts hat einen eigenen Systembenutzer) und Hardened-PHP ist nichts passiert.
Jetzt muss ich nur den Inhalt des Vhosts noch komplett löschen und neu aufsetzen.

Ohne Netz und doppeltem Boden? Ohne mich

Ich habe nun endlich qpsmtpd am Laufen. Problem war weniger das Skripten eines MySQL-Plugins sondern eher die Zeit bzw die Muße zu finden sich mal dranzusetzen

Ab sofort gehen Mails an meine beiden Haupt-Domains über qpsmtpd ein. Virenmails sowie Spammails mit einem Rating über 7 werden ab sofort direkt abgewiesen
Auch vom Earlytaker-Plugin erhoffe ich mir weniger Spam. Zwar wird einiges direkt in den Junk-Mail-Ordner sortiert aber warum Ressourcen dafür verschwenden?

Leider kann ich aufgrund der rechtlichen Lage nicht gleich alle Domains umstellen - dafür müsste ich meinen Benutzern eine Auswahl der Filterung anbieten. Also das Spamassassin-Modul um ein MySQL-Lookup erweitern. Aber erstmal muss ich weiter für Klausuren lernen

Wie vielleicht einige festgestellt habe, war mein Server dieses Wochenende down.
Ursache: ein Skript welches durch ein Programmierfehler Amok gelaufen ist. Dadurch wurde quasi alles auf dem Server gelöscht.
Aber das war Murphy noch nicht genug.
Erst musste ich feststellen, dass das per Duplicity erstelle Backup nicht allzu neu war. Gleich danach kam die Erkenntnis, dass das Backup teilweise korrupt war:

Invalid data - SHA1 hash mismatch:
Calculated hash: ac1777d8b234e84e828f9f6a217d19efeea25520
Manifest hash: 6ba474192fe73f4bced06fff403f29e36ecae7a4

sowie

gpg: [don't know]: invalid packet (ctb=14)

Das die Backuplösung nicht robust gegen solche Fehler ist und beim Fehler damit komplett abbricht, spricht nicht gerade für die Lösung.
Wobei mich duplicity schon länger genervt hat: wenn beispielsweise das Passwort falsch ist, bekommt man nur einen gnupg Fehler 2 - den eigentlichen Fehler bekommt man erst raus, wenn man das Debuglevel höher setzt

Aber das war Murphy immer noch nicht genug..
Nachdem mich das Backup schon in einem Zustand des Dauerkotzens brachte, verabschiedete sich auch noch meine /var/www-Partition. Selbst ein fsck.ext3 konnte nichts mehr reparieren. Nach jedem fsck wurde es quasi schlimmer. Selbst nach dem zehnten Durchgang crashte der komplette Server beim Zugriff auf diverse Dateien.
Ein physikalischen Defekt würde ich ausschließen, da die Partition auf einem Mirror-RAID liegt.


Nun ja, mein Blog ist nach zwei Tagen Arbeit wiederhergestellt - zum einen Dank einem lokalen Datenbank-Backup und zum anderen Dank des Google-Caches
Leider sind dadurch zehn Kommentare verloren gegangen - eventl. ziehe ich die demnächst nach.

Mmh, wie soll man da ordentlich eine MySQL optimieren können?
Die meisten Angaben von show status werden durch das Backup verfälscht
Klar, dass beim Backup tausende von Tabellen geöffnet werden und etliche Table-Scans gemacht werden.
mysqlhotcopy ist leider keine Alternative, da ich auch einige InnoDB-Tabellen habe.