# ISP3 Neuinstallation nach fehlerhaftem Update



## Quest (18. Jan. 2010)

Mahlzeit zusammen
sollte eig. ein eigener Thread werden, habs aus Versehen als Antwort gepostet.
http://howtoforge.de/forum/showthread.php?p=15196#post15196

Ich hab mittlerweile die Setupfiles für ISPConfig 3 wieder herunter geladen und versuche gerade die install.php durchlaufen zu lassen, doch auch hier hab ich das Problem, dass MySQL nicht startet nachdem es vom Setup beendet wurde.
Was kann ich machen?
Das Skript hängt und ISPConfig lässt sich nicht mehr auf dem Server einrichten.

Zur Info:
System: Debian Lenny, aktuelle Pakete
einziger Unterschied: PHP 5.3 aus dotdeb Repository installiert.


----------



## Till (18. Jan. 2010)

Du musst erstmal rausfinden, warum mysql so instabil ist. ISPConfig ruft nur ein normales /etc/init.d/mysql restart nach Abschluss der Installation auf, daran darf eine mysql Installation nicht hängen. Ist das der mysql von debian oder der von dotdeb?


----------



## Quest (18. Jan. 2010)

MySQL ist von Debian. Von Dotdeb hab ich nur PHP installiert.
Dotdeb hab ich danach in der sources.list wieder auskommentiert.
Gibts eine Möglichkeit mit apt wieder ein downgrade auf 5.2 zu machen? Vielleicht macht beim Setup PHP 5.3 irgendwo Probleme.

Und zu deiner Frage in dem anderen Thread, Nein, Filebackup hab ich leider keines. Das Verzeichnis werde ich aber auf jeden Fall in meine Backup Liste aufnehmen.


----------



## Till (18. Jan. 2010)

> Gibts eine Möglichkeit mit apt wieder ein downgrade auf 5.2 zu machen?


Hab ich noch nicht probiert. Du könntest es mit einem

apt-get install --reinstall php5-..............

und dann die ganzen php Paketnamen, die Du installiert hast, versuchen.

Aber sowas kann halt auch immer mal schief gehen. hast Du mal nach Deinem mysql Fehler gegoogelt?


----------



## Quest (18. Jan. 2010)

Downgrade ist gemacht, Problem beim Neustarten der Services bleibt.
Die DB von ISPConfig wird also soweit erstellt, nur das Neustarten der Services hängt immer beim MySQL Server.
Wie ist das bei MySQL?
Steht alles was er für die DBs braucht in den Files in /var/lib/mysql?
Könnte ich also alle Datenbanken da einfach raus verschieben und später wieder reinverschieben und sie würden wieder funktionieren? (Inklusive information_schema für die Userinformationen auf die Datenbanken)


----------



## Quest (18. Jan. 2010)

Update zum MySQL Server
Ich hab grad nach einem Server-Neustart mal versucht ihn von Hand neu zu starten.
Das Problem ist nicht das Starten, das Problem ist das Stoppen!
Hier hängt er ewig:
Stopping MySQL database server: mysqld

Hast du eine Idee wie ich diesem lustigen Problem auf die Schliche kommen kann?


----------



## Till (18. Jan. 2010)

> Steht alles was er für die DBs braucht in den Files in /var/lib/mysql?


Ja.



> Könnte ich also alle Datenbanken da einfach raus verschieben und später wieder reinverschieben und sie würden wieder funktionieren?


Ja. zumindest myisam Datenbanken machen da kein Problem. Innodb kann da etwas hakelig sein. Aberw enn der mysql Server gestoppt ist, geht das normalerweise auch.



> Hast du eine Idee wie ich diesem lustigen Problem auf die Schliche kommen kann?


Hab ich so noch nicht gehabt. Hast Du mal debugging in mysql aktiviert. Vielleicht schreibt er dann ja was dazu in die logs. Ansonsten würde ich es mal in einer auf mysql spezialisierten Mailingliste versuchen, vielleicht haben die eine Idee dazu.


----------



## Quest (18. Jan. 2010)

Es gab wohl eine fehlerhafte Tabelle auf dem Server.
Ich hab ein paar nicht mehr benötigte Tabellen entfernt, jetzt gehts wieder.
Das Setup ist durchgelaufen, Mails und Domains wieder eingetragen.
Müssen meine Kunden eben ihre Passwörter wieder frisch setzen und auf die Verwaltung der bereits existierenden Datenbanken verzichten. Ist aber nicht so schlimm, hab guten Kontakt zu meinen Kunden.

Etwas anderes, das gerade aufgetaucht ist:
Während ich ein Backup einer Webseite zurückgespielt hab hat sich der Server komplett aufgehängt, jetzt kommt eine Info wegen Raid Resync:
Personalities : [raid0] [raid1] [raid6] [raid5] [raid4] 
md2 : active raid1 sda3[0] sdb3[1]
      482078400 blocks [2/2] [UU]
      [=>...................]  resync =  7.8% (37695552/482078400) finish=102.1min speed=72524K/sec

md1 : active raid1 sda2[0] sdb2[1]
      2104448 blocks [2/2] [UU]

md0 : active (auto-read-only) raid1 sda1[0] sdb1[1]
      4200896 blocks [2/2] [UU]

unused devices: 

Kann es sein, dass das SW Raid durch irgendwas kaputt gemacht wurde?


----------



## Till (18. Jan. 2010)

Wie Du vermutet hast stimmt da etwas mit dem raid nicht, aber es synchronisiert sich gerade neu. Das könnte vielleicht auch ein Grund für die defekte DB Tabelle gewesen sein.

Wenn die Synchronisation durch läuft, ist alles ok. Sollte sie nach dem Ende aber wieder von vorne anfangen, ist vielleicht eine der Festplatten nicht mehr ganz ok.


----------



## Quest (19. Jan. 2010)

Das Raid ist mit dem Resync fertig.
ISP3 läuft auch wieder problemlos.
Nur phpmyadmin streikt seit der Neuinstallation.
Neuinstallation von phpmyadmin über apt hat nix gebracht.
Konfiguriert ISP3 beim Updatelauf phpmyadmin automatisch?
Wenn ja warte ich auf das Update für 3.0.1.7.


----------



## Till (19. Jan. 2010)

> Konfiguriert ISP3 beim Updatelauf phpmyadmin automatisch?


Nein, phpmyadmin wird nicht durch ispconfig konfiguriert.


----------

