Umzug ISPConfig 2 auf neuen Server (Debian)

oxxmoxx

New Member
Hallo zusammen,

mir stehen in Kürze zwei Serverumzüge bevor, die ich schon lange vor mir her schiebe. Die zwei Server sind noch ein Sarge- und ein Etch-Server jeweils mit ISPConfig 2 (2.2.6), die neuen Server haben ein Lenny am Start (Perfect Setup) und das ISPConfig bleibt die 2er Version.

Jetzt habe ich mich schon durch das englische und deutsche Forum gelesen. Den Umzugsmaster-Thread (http://www.howtoforge.com/forums/showthread.php?t=2717) habe ich natürlich auch gelesen, dennoch bleiben mir Fragen, die ich heute mal stellen möchte (in der Hoffnung nicht gesteinigt zu werden, weil die Fragen, vielleicht doch schon irgendwo beantwortet wurden...).

Es heißt, auf beiden Servern muss die selbe ISPConfig-Version installiert sein. Ich will ungern auf dem "alten" Server jetzt noch ein Update durchführen. Das heißt im Umkehrschluss, dass ich auf dem neuen Lenny-Server eine ISPConfig 2.2.6 installieren muss (ist auf sourceforge noch zu finden) und nach dem Umzug das ISPConfig auf die 2.2.38 aktualisiere. Spricht gegen diese Vorgehensweise etwas und ist ein Update auf dem neuen Server dann von 2.2.6 auf 2.2.38 problemlos möglich?

Kann ich mit den beschriebenen Dateien (passwd, shadow, group, vhosts_ispconfig.conf etc.) problemlos von einem 3er bzw. 4er auf ein 5er Debian umziehen? Und wie verhält sich das mit den mySQL-Dumps von einem 4er auf einen 5er mySQL-Server?

Die ISPConfig Datenbank: Im o.a. Link steht, die ISPConfig Datenbank auf dem neuen Server ist durch die alte Datenbank zu ersetzen - ist ja logisch, weil dort alle Informationen drin stehen ;). Hier: http://www.howtoforge.de/forum/showthread.php?t=821&highlight=umzug&page=2 im Beitrag #17 lese ich von der "isp_server"-Tabelle, die distributionsspezifisch ist. Ist die Tabelle bei einem Umzug von Sarge bzw. Etch auf Lenny von Relevanz?

Und die letzte Frage: Die mySQL-Datenbank. Was muss ich damit genau machen? Wenn ich aus ich einem kompletten SQL-Dump alle DBs wieder herstelle, dann wird doch auch diese DB überschrieben. In einem anderen Thread (den ich grad nicht mehr finde) habe ich gelesen, dass man auch die Files aus /var/mysql von "alt" nach "neu" kopieren kann, außer die MYSQL. Und den Satz aus dem Umzugsmaster-Thread "Regarding the mysql database: have a look at the users and db table and add the user /db lines that don't exist on the new server but on the old server" verstehe ich um ehrlich zu sein nicht so richtig.

Ich hoffe, die Menge der Fragen erschlägt Euch nicht, aber ich plane lieber im voraus etwas zu viel, als dass ich nachher mitten im Umzug "die Brille aufhabe". Ich habe auch echt Respekt vor den Umzügen, auch wenn es ja relativ leicht sein soll.

Ich freue mich auf Eure Antworten. Vielen Dank dafür im voraus.

Viele Grüße
Alex
 

oxxmoxx

New Member
So, ich habe mir jetzt mal etwas Luft verschafft und habe die Server vorbereitet. Die neuen Server mit Debian 5.0.8 (analog dem Perfect Setup) sind installiert und bereit. Und schon habe ich das erste Problem:

Um die identische ISPConfig-Version zu haben, wollte ich auf dem Lenny-Server die 2.2.6 installieren - wie befürchtet geht das nicht. Es muss mindestens die 2.2.37 sein.

Auf den alten Servern läuft wie gesagt jeweils die 2.2.6 (mit einem Sarge und einem Etch als Distribution). Ich vermute / befürchte diese Konstellation lässt sich nicht ohne weiteres auf 2.2.37 updaten :confused:. Ich kann das auch nicht einfach ausprobieren und damit ggfs. den Server lahm legen.

Hat damit jemand Erfahrungen? @Till: kannst Du abschätzen, auf welche Version ich die alte 2.2.6 ohne Probleme auf den alten Debian-Systemen hochziehen kann, ohne dass mir die Systeme um die Ohren fliegen? Und kannst Du mir sagen, welche die niedrigste ISPConfig Version ist, mit der die 2.2.37 abwärtskompatibel ist?

Danke für Eure Antworten im voraus.
 
Zuletzt bearbeitet:

Till

Administrator
Du kannst das ISPConfig auch umziehen, ohne die Version auf den alten Servern zu aktualisieren. Dabei musst Du nur beachten, dass Du nach dem Umzug der ISPConfig mysql Datenbank (und bevor Du irgendwelche Änderungen in ISPConfig durchführst) auf dem neuen system nochmal das ISPConfig Update durchlaufen lässt, damit der Updater die DB Struktur anpassen kann.
 

oxxmoxx

New Member
cool, das sieht sehr gut aus :). Hmmm, ich frag' mal so: Hätte ich VOR dem ISPConfig-Update auch schon die ganzen anderen notwendigen Dateien (/etc/passwd, /etc/shadow, /etc/group, Vhosts_ispconfig.conf etc.) auf den neuen Server packen müssen? Ich habe gesehen, dass nach der Update-Installation vom ISPConfig diese Dateien angefasst und geändert worden sind - oder kann ich auch jetzt im Nachgang die obigen Daten von "alt" nach "neu" umziehen ...?
 

Till

Administrator
An sich hättest Du es besser vorher gemacht. Du kannst Die Dateien aber auch jetzt noch umziehen, Du musst jetzt nur darauf achten dass Du die Zeilen die ISPConfig jetzt angelegt hat mit den Zeilen aus der alten datei überschreiubts. Aber nicht die kompletten /etc/passwd, shadow, group und gshadow Dateien am Stück ersetzen, sonst wird Dein Linux möglicherweise nicht mehr laufen. Du musst nur die Zeilen der webseiten User und Gruppen kopieren.
 

oxxmoxx

New Member
ok, verstehe. Bin jetzt dabei, nochmal bei der ISPConfig Installation zu beginnen, werde dann die besagtem Files rüber schieben (bzw. die entsprechenden Zeilen ergänzen) und dann das Update durchführen (ist ja jetzt zum Glück alles als VM installiert). Wenn das erledigt und lauffähig ist, kann ich mich dranmachen und die Webs (inkl. der User-DB) rüber schieben.
 

oxxmoxx

New Member
Ich habe jetzt in der Tat noch mal gestartet und erst die Config-Files auf den neuen Server geschoben bzw. die fehlenden Zeilen ergänzt und habe dann das ISPConfig-Update vorgenommen. Zum Test habe ich danach mir wahllos ein paar dokumentierte ftp-Zugänge heraus gesucht: funktioniert; dann habe ich mir ein Web ausgesucht (inkl. IMAP) und habe das auf den neuen Server geschoben: funktioniert ebenfalls bestens.

Dann habe ich mich an die Datenbanken gemacht: Habe also aus den Tabellen "db" und "user" der "mysql"-DB die entsprechenden User-DB Einträge exportiert und in einiger Handarbeit in das neue System importiert. Und jetzt habe ich ein Problem: Die Datenbanken werden mir als "root" im phpmyadmin nicht angezeigt. Auch kann ich mich mit den User-Daten nicht am phpmyadmin anmelden. Versuche ich den Dump einer DB via Konsole einzuspielen, bekomme ich den Hinweis das die DB nicht existiert.

Erst wenn ich im jeweiligen Web im ISPConfig unter "Optionen" die vorhandene DB aufrufe, das Passwort händisch eingebe wird die DB im phpmyadmin angezeigt, ich kann mich einloggen und auch via Konsole den Dump zurück sichern. Es sind ja "nur" 128 DBs, so könnte ich ja relativ fix durch die Webs huschen, aber: mir sind leider nicht alle Passwörter bekannt :(.

War ich wieder mit der Reihenfolge falsch, will sagen: hätte ich vor dem ISPConfig-Update auch die Tabellen "db" und "user" überarbeitet am Start haben müssen? Oder ist die Ursache woanders zu suchen? Ich habe ja noch einen zweiten Server zu migrieren, so dass ich dort die gleichen Fehler nicht noch mal machen will.

Ich freue mich auf Antwort ...
 

Till

Administrator
Und jetzt habe ich ein Problem: Die Datenbanken werden mir als "root" im phpmyadmin nicht angezeigt. Auch kann ich mich mit den User-Daten nicht am phpmyadmin anmelden. Versuche ich den Dump einer DB via Konsole einzuspielen, bekomme ich den Hinweis das die DB nicht existiert.

Hast Du denn auch die Datenbanken selbst migriert? Wenn es sich um myisam Datenbanken handelt, kannst Du einfach die Unterverzeichnisse mit den Namen der datenbanken in /var/lib/mysql/ auf den neuen Server verschieben. Wenn es InnoDB Datenbanken sind, müsstest Du stattdessen mysqldump benutzen, um die Datenbanken auf dem alten Server zu exportieren.
 

oxxmoxx

New Member
Nachdem ich heute Stunden damit verbracht habe, alle Datenbanken vom alten Server ohne Fehler in ein Dumpfile zu packen und diese dann inkl. Fehlerbereinigung auf dem neuen Server zu importieren, waren auch alle Datenbanken im phpmyadmin verfügbar ... Asche auf mein Haupt :eek:.

Ganz schlüssig empfinde ich das Verhalten nicht, aber ist egal - hat ja am Ende funktioniert. Und ganz nebenbei habe ich heute, was den MySQL-Server betrifft, viele neue Dinge dazu gelernt. Und für die nächste anstehende Migration, habe ich auch einen Plan (vor allem, wie ich bestimmte Dinge nicht mache ;)).
 

Till

Administrator
Ganz schlüssig empfinde ich das Verhalten nicht, aber ist egal - hat ja am Ende funktioniert.

Wieso das? Der mysql Server funktioniert wie die meisten Computersysteme. Es gibt zum einen die Daten "also den Inhalt der Datenbanken" und dann die Authentifizierungsinformationen, also Logins. Wenn Du Dir einen neuen Windows Rechner einrichtest und dort ein neues Konto mit Deinen Nutzerdaten nalgest, sind ja auch nicht Automatisch Deine Photos vom alten Rechner dort? Da das Anlegen eines Benutzerkontos ja nicht irgendwelche Daten rekonstruieren kann. Eine Datnbank in Mysql kannst Du in etwa mit einem Ordner vergleichen und die Rechte in den Tabellen der "mysql" Datenbank entsprechen den User Logins.
 

oxxmoxx

New Member
Wenn Du Dir einen neuen Windows Rechner einrichtest und dort ein neues Konto mit Deinen Nutzerdaten nalgest, sind ja auch nicht Automatisch Deine Photos vom alten Rechner dort? Da das Anlegen eines Benutzerkontos ja nicht irgendwelche Daten rekonstruieren kann.

Hi Till, ja ist schon klar, dass die eigentlichen Inhalte erst mit dem Dump kommen. War vielleicht etwas quer von mir ausgedrückt: Ich hatte erwartet, dass nach Einfügen der "db"- und "user"-Informationen in der mysql-DB, die (leeren) Datenbanken schon angezeigt werden bzw. der Login funktionieren würde, freilich die Datenbanken ohne Inhalt (so wie es einem neu angelegten Benutzer an einem Rechner auch ist ;)). Das war nicht der Fall, sondern erst nachdem ich bei einer DB im ISPConfig das Kennwort nochmals eingegeben hatte, wurde diese eine DB dann überhaupt, natürlich auch noch ohne Inhalte (weil noch ohne SQL-Dump), angezeigt.

Deswegen war ich etwas aufgeregt und sagen wir mal verwundert - oder auch etwas übervorsichtig bzw. (zu oft) hinterfragend :rolleyes:
 

Werbung

Top