{"id":654,"date":"2010-05-16T20:40:03","date_gmt":"2010-05-16T18:40:03","guid":{"rendered":"http:\/\/blog.benny-baumann.de\/?p=654"},"modified":"2010-05-25T00:08:34","modified_gmt":"2010-05-24T22:08:34","slug":"katastrophen-recovery-mit-ispcp","status":"publish","type":"post","link":"https:\/\/blog.benny-baumann.de\/?p=654","title":{"rendered":"Katastrophen-Recovery mit ispCP"},"content":{"rendered":"

Heute gibt es von meiner Seite einmal einen der Beitr\u00e4ge, die man am liebsten nie brauchen w\u00f6llte: Wie stelle ich aus minimalen Daten ein ispCP wieder her, falls es am alten Sytem zu Problemen kam. Und auch wenn ich schreibe, Katastrophen-Recovery: Alles, was \u00fcber einen gewissen Grad an Problemen hinaus geht, wird auch mit dieser Anleitung nicht zu beheben gehen. Von daher eine kurze Checkliste:<\/p>\n

    \n
  1. Habt ihr ein Backup ALLER Server-Dateien? Wenn ja, reicht im Wesentlichen die Migrationsanleitung von der ispCP-Homepage<\/a>. Dennoch empfehle ich einen Blick weiter unten zu Hinweisen w\u00e4hrend man dies erledigt.<\/li>\n
  2. Habt ihr ein Backup aller Userdaten UND folgenden Dinge:\n
      \n
    1. die Datenbank ispcp des alten Systems (Bin\u00e4rkopie ausreichend!)<\/li>\n
    2. die Datenbank mysql des alten Systems (Bin\u00e4rkopie ausreichend!)<\/li>\n
    3. die ispcp.conf des alten Systems<\/li>\n
    4. \/var\/www\/ispcp\/gui\/include\/ispcp-db-keys.php<\/li>\n
    5. \/var\/www\/ispcp\/engine\/ispcp-db-keys.pl<\/li>\n<\/ol>\n

      \t\tSollten von den letzten beiden Dateien nur eine verf\u00fcgbar sein, so kann die jeweils andere aus dieser Datei erzeugt werden. Fehlen beide, kann nur versucht werden, mit Hilfe des Howtos zum Setzen des MySQL-Passwortes f\u00fcr ispCP<\/a> diese Dateien zu erzeugen. Dies muss nach dem Wiederherstellen der MySQL-Nutzer-Datenbank und vor Aufruf des Setup-Skripts geschehen. DATABASE_USER und DATABASE_PASSWORD m\u00fcssen f\u00fcr diesen Fall nach Aufruf des Passwort-Skriptes aus der ispcp.conf in die ispcp.old.conf \u00fcbertragen werden, da ispCP sonst mit den falschen Schl\u00fcsseln ein Login probiert.<\/li>\n

    6. Habt ihr vom alten System genug Daten, um die im vorigen Punkt n\u00f6tigen Daten der zweiten Subliste zusammenzukratzen. Wenn nicht, gilt auch hier: Bei\u00dft in saure \u00c4pfel, der Todesgott eurer Installation mag die.<\/li>\n<\/ol>\n

      Okay: Eines vorweg: Wenn ihr mindestens einen Punkt der obigen Liste bejahen konntet, bestehen berechtigte Hoffnungen, dass ihr um eine vollst\u00e4ndige Neuinstallation<\/a> herumkommt. Eine Garantie gibt es hierbei aber nicht, da die n\u00e4chsten Schritte mit extrem vielen M\u00f6glichkeiten f\u00fcr Fehler verbunden sind und ich es selber beim Erarbeiten dieser Liste geschafft habe, so nahezu JEDE Fehlermeldung, die ispCP bietet auch einmal zu erhalten. Wer also nicht allzu frusttolerant ist, sollte es vor dem Fortfahren mit geeigneten Antidepressiva probieren. Ihr wurdet gewarnt.<\/p>\n

      Ferner noch eine kleine Anmerkung f\u00fcr Voreilige: Bitte fangt nicht gleich am Anfang an, wild Dateien umherzukopieren. Ich werde an den entsprechenden Stellen darauf hinweisen, wenn Daten zu Kopieren sind. Zus\u00e4tzlich sollte man w\u00e4hrend der gesamten Arbeit so flei\u00dfig mit Backups arbeiten, um Datenverlust so gut wie m\u00f6glich vermeiden zu k\u00f6nnen.<\/p>\n

      Fangen wir also an. Als ersten Schritt sollte dringend<\/strong> ein gerade neu installiertes, frisches und blankes System<\/strong> derjenigen Distribution installiert werden, die auch auf dem alten System lief. Weder die Neuinstallation noch die gleiche Distribution sind hierbei verpflichtend, vereinfachen aber die sp\u00e4tere Arbeit wesentlich. Wer also von Anfang an auf seinem System Seppuku begehen m\u00f6chte, darf sich auch eine Fremddistribution aus dem Gebrauchtinstallationsladen holen, sollte sich aber \u00fcber Nebeneffekte nicht wundern. Keinesfalls darf zu diesem Zeitpunkt aber ispCP installiert sein, da im Zuge dieser Anleitung eine bestehende ispCP-Installation r\u00fccksichtslos \u00fcberschrieben werden wird. Zum Zusammenf\u00fchren mehrerer Installationen ist diese Anleitung ausdr\u00fccklich nicht geeignet<\/strong>.<\/p>\n

      Der n\u00e4chste Schritt in dieser Anleitung betrifft eine Vorbereitung, die auch f\u00fcr eine normale Migration<\/a> von Vorteil ist, da sie eine Eigenheit der Installation des Postfix-Servers behandelt. Dieser ist sp\u00e4ter f\u00fcr die Installation von ispCP n\u00f6tig, f\u00fchrt aber unweigerlich zu Datenverlust beim Mailempfang<\/strong>, wenn er zu lange ohne Konfiguration verbleibt. Daher gibt es zwei M\u00f6glichkeiten, die je nach Situation unterschiedliche Vorz\u00fcge haben:<\/p>\n

        \n
      1. DNS-Eintr\u00e4ge f\u00fcr ALLE Domains, die das neue System zeigen ins Nirvana umleiten\/entfernen\n

        \t\tDiese Variante ist, wenn auch die bessere Wahl, die mit wesentlich mehr Aufwand verbundene Umsetzung. Damit diese Variante funktioniert, sollte man bereits im Vorfeld (etwa 24 bis 48 Stunden!) den Umzug der DNS-Records veranlassen. Zu beachten ist hierf\u00fcr insbesondere, dass hierbei keine Garantie f\u00fcr das korrekte Funktionieren gegeben ist, weil durch widersp\u00e4nstige DNS-Caches noch veraltete Daten ausgeliefert werden k\u00f6nnen. In jedem Fall reduziert dieser Schritt aber eindeutig die Last auf dem Mailserver und kann somit unterst\u00fctzend zum zweiten Schritt in Erw\u00e4gung gezogen werden.<\/li>\n

      2. Postfix bis zur Einrichtung seiner Konfiguration deaktiviert lassen\n

        \t\tOkay, diese Variante ist zwar Quick&Dirty, aber bietet gegen\u00fcber der vorigen Variante einen sehr gro\u00dfen Vorteil: Wenn die Last auf dem Mailserver klein genug ist, (<10 Mails\/min) hat man sehr gute Chancen mit sehr guter Reaktion die Anzahl verlorener Mails auf 0 zu halten. Zudem sind f\u00fcr diese Vorgehensweise keine externen Vorbereitungen n\u00f6tig, was das Recovery beschleunigen kann. Dennoch erfordert diese Methode eine gewisse Aufmerksamkeit, um das versehentliche Starten von Postfix schnell abstellen zu k\u00f6nnen.<\/li>\n<\/ol>\n

        Nach dem nun beide Vorgehensweisen aufgef\u00fchrt worden, eine Reihe von Details zu den Hintergr\u00fcnden. Bei der Auslieferung von Emails wird vom Absender einer Mail (oder besser gesagt dessen Mailserver) nachgeschaut, wohin diese Mail geliefert werden soll. Diese Information findet sich in den sogennannten MX-Resource-Records einer Domain. Fehlen diese, so wird alternativ die Liste der A-Resource-Records zum Versand von Mails herangezogen. Innerhalb eines MX-Records wird nun neben der Adresse eines Mailservers auch eine Priorit\u00e4t definiert. Diese wird genutzt, um eine Reihenfolge f\u00fcr das Anfragen der Mailserver zu definieren. F\u00e4llt nun ein Mailserver in dieser Liste aus, so wird ein weiterer Mailserver aus der Liste der Mailserver probiert. Gibt es keinen weiteren, geht es irgendwann einfach wieder beim ersten Mailserver los.<\/p>\n

        Dieser gut gemeinte Fallback-Mechanismus hat im Falle des Postfix nun einen kleinen Haken, da dieser in seiner Standard-Konfiguration jegliche eintreffende Mails mit einem Hard-Error (554 5.7.1: Relay Access Denied) ablehnt, da Postfix nur Mails f\u00fcr Domains annimmt, f\u00fcr die er beauftragt ist. In der Standard-Konfiguration sind das au\u00dfer localhost keine, was die Ablehnung zwar korrekt, aber f\u00fcr unseren Fall vollst\u00e4ndig kontraproduktiv macht. Denn w\u00e4hrend bei einem nicht erreichbaren Mailserver ein Softerror generiert wird (Mailserver nicht erreichbar; Mailversand wird sp\u00e4ter nochmals probiert), besagt ein Hard-Error, dass die Mail verworfen werden soll UND an den Absender eine unzustellbarkeitsmitteilung (DSN = Delivery Status Notification) gesendet werden soll.<\/p>\n

        Daher sollte die L\u00f6sung sein: Solange Postfix noch nicht konfiguriert ist, d\u00fcrfen ihn keine Mails erreichen. Und obige beiden Vorgehensweisen bieten ideale Erfolgsaussichten hierf\u00fcr. Wenn es schnellgehen muss und nicht viele Mails anliegen, reicht Variante 2, hat man einen High-Volume-Mailserver mit hohem Traffic, sollte man sich f\u00fcr 1. mit Absicherung durch 2. entscheiden und sofern verf\u00fcgbar, einen Backup-Mailserver verwenden (der jedoch vorerst noch keine Mails final zustellt).<\/p>\n

        Da wir nun Postfix abgehakt haben, k\u00f6nnen wir weiter voranschreiten und ispCP konfigurieren. Als Kurzbeschreibung hierf\u00fcr kann mit wenigen Worten „Neuinstall, Konfig wiederherstellen, Update“ verwendet werden, wobei aber auch hier der Teufel im Detail steckt. War bis hierhin alles ohne gro\u00dfe Konzentration m\u00f6glich, k\u00f6nnen alle nun folgenden Schritte zu extrem schwer zu lokalisierenden Fehlern f\u00fchren.<\/p>\n

        Setzen wir also erst einmal mit der Installation von MySQL fort, denn auch hier gibt es ein wenig was zu beachten. Oben habe ich ja bereits erw\u00e4hnt, dass wir von MySQL sowohl die Datenbank ispcp wie auch die Datenbank mysql ben\u00f6tigen. W\u00e4hrend dies Grundlegend erst einmal auch stimmt, ist es aber auch hier nicht die ganze Wahrheit, da die Datenbank mysql allein f\u00fcr die Authentifizierung der Datenbank-Nutzer zust\u00e4ndig ist. Fehlt einem diese Datenbank, ist zwar nicht partout Schluss, ABER man wird beim R\u00fcckspielen von ispCP erheblichen Aufwand bekommen. Wer also nicht allzu viel Erfahrung damit hat, in fremden Skripten sich Passw\u00f6rter rauszudebuggen, sei hiermit w\u00e4rmstens empfohlen, nach der mysql-Datenbank zu suchen, bevor er fortsetzt. Ist diese wirklich nicht auffindbar, buss anhand der ispCP-Keyfiles und einem Hack in den ispCP-Skripts im sp\u00e4teren Verlauf das entschl\u00fcsselte Passwort abgefangen werden. Gleiches gilt zudem f\u00fcr die Datei \/etc\/mysql\/debian.cnf (oder analoge, je nach Distribution), in der die Maintainer-Passw\u00f6rter f\u00fcr den Datenbank-Zugang enthalten sind. Auch hier gilt: Ist diese nicht auffindbar, muss man nach dem R\u00fcckspielen der mysql-Datenbank ein wenig mehr Aufwand treiben, indem man MySQL ohne Beachtung der Authentifikationstabellen startet<\/p>\n

        mysqld --skip-grant-tables<\/pre>\n
        und nach dem setzen eines neuen Passwortes f\u00fcr den Maintainer-Zugang die entsprechende Konfigurationsdatei von Hand ausf\u00fcllt. Der Inhalt sollte dabei wie Folgt aussehen:<\/p>\n
        # Automatically generated for Debian scripts. DO NOT TOUCH!\r\n[client]\r\nhost     = localhost\r\nuser     = debian-sys-maint\r\npassword = #password#\r\nsocket   = \/var\/run\/mysqld\/mysqld.sock\r\n[mysql_upgrade]\r\nuser     = debian-sys-maint\r\npassword = #password#\r\nsocket   = \/var\/run\/mysqld\/mysqld.sock\r\nbasedir  = \/usr<\/pre>\n
        Hierbei muss statt #password# das Klartext-Passwort verwendet werden, was soeben in der Datenbank gesetzt wurde. Ich werden nachher aber noch einmal auf diesen Punkt zur\u00fcckkommen.<\/p>\n
        Denn erst einmal k\u00f6nnen wir uns mit einer relativ einfachen Aufgabe besch\u00e4ftigen: eine „Dummy-Installation“ von ispCP. Diese ist notwendig, um ein lauff\u00e4higes ispCP auf das System zu bekommen. Dieser Schritt ist auch einer der Gr\u00fcnde, warum keine Installation vorhanden sein darf: Diese w\u00e4re durch diesen Schritt das erste Mail \u00fcberschrieben und wird nachher noch ein weiteres Mal \u00fcberschrieben. F\u00fcr die Installation von ispCP kann nach den ergangenen Vorbereitungen mit Postfix mit der normalen Anleitung f\u00fcr die Installation einer frischen Version von ispCP vorgegangen werden. Es empfiehlt sich in diesem Schritt, gleich mit einer aktuellen ispCP-Version anzufangen, selbst wenn auf dem alten Server nicht die aktuelle Version von ispCP lief. Dieser Schritt wird implizit durch einen sp\u00e4ter noch zu besprechenden Schritt nachgeholt. Vorsicht sollte aber auch hier wieder in Bezug auf Postfix gelten: Dieser sollte auch hier wieder vom Empfang  und Ablehnen von Mails abgehalten werden. Dies ist AFAIR am Ende des Setup-Prozesses der Fall; es kann aber auch nicht schaden, mit htop ein Auge auf die aktuelle Prozessliste des Servers w\u00e4hrend der gesamten Arbeiten zu werfen.<\/p>\n
        Ist man bis hierhin gekommen, hat man den Einfachen Teil der Arbeiten geschafft. Ab nun an beginnt ein wenig forensische Arbeit, die eine Menge Fingerspitzengef\u00fchl erfordert. Als n\u00e4chstes gilt es, die beiden Hauptdatenbanken von ispCP (n\u00e4mlich genau die bereits erw\u00e4hnten beiden) wieder einzupflegen. Hierzu beenden wir den MySQL-Server mit<\/p>\n
        \/etc\/init.d\/mysql stop<\/pre>\n
        bzw. mit einem nicht ganz so sanften<\/p>\n
        killall mysqld<\/pre>\n
        sollte sich dieser weigern auf Gehei\u00df des Startskriptes herunterzufahren.<\/p>\n
        Und nun kommt die angek\u00fcndigte forensische Arbeit: Im n\u00e4chsten Schritt m\u00fcssen die Datenbanken ispcp und mysql zur\u00fcckkopiert werden. Diese m\u00fcssen unter \/var\/lib\/mysql die beiden vorhandenen Ordner ersetzen. Wer Backups haben m\u00f6chte, braucht diese beiden Ordner lediglich umzubenennen und kann dann wie gehabt auf diese von MySQL aus zugreifen. Hat man die beiden Ordner aus seinem Backup wiederhergestellt, gilt es zudem, die Berechtigungen f\u00fcr alle Dateien unter \/var\/lib\/mysql zu korrigieren. Diese m\u00fcssen auf den Owner mysql mit Gruppe mysql lauten. Am besten man erledigt dies kurz von der Kommandozeile:<\/p>\n
        cd \/var\/lib\/mysql\r\nchown -R mysql:mysql *\/<\/pre>\n
        Womit wir auch wieder bei dem oben genannten Punkt w\u00e4ren: Hat man die Maintainer-Zug\u00e4nge des alten Systems, so m\u00fcssten diese jetzt<\/strong> unter \/etc\/mysql zur\u00fcckgespielt werden. Hat man diese nicht, muss jetzt<\/strong> die entsprechende Korrektur der Passworte vorgenommen werden. f\u00fcr ispCP kann man sich diesen Schritt jedoch noch etwas aufheben, weil zu einem sp\u00e4teren Zeitpunkt wir eh auf diese Zug\u00e4nge zur\u00fcckkommen werden.<\/p>\n
        Apropos Zug\u00e4nge: Dieser Moment ist glaube ein wundererbarer Moment, die Nutzer in der \/etc\/passwd, \/etc\/shadow sowie \/etc\/group und \/etc\/gshadow wiederherzustellen. Wer diese Dateien hat, muss aus jeder Datei folgende Dinge in sein neues System \u00fcbernehmen:<\/p>\n