Datenverlust, cpg neu aufsetzen.

[allibert]

Guten Tag,

also unser Hoster hatte irgendein Problem und dabei sind Daten von uns verloren gegangen.
Kein aktuelles Back-Up vorhanden - ja ich weiß, aber ist passiert, brauchen wir nun auch nciht drüber reden.... ist ja nicht mehr zu ändern.

Es gibt allesdings auf einem alten funpic sever noch eine alte version, die wollten wir aufspielen und dann die ganzen fehlenden Sachen neu hochladen.
Naja jetzt haben wir das alles wieder auf den neuen Server aufgespielt und bekommen leider folgende Fehlermeldung:

Internal Server Error

The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator, [no address given] and inform them of the time the error occurred, and anything you might have done that may have caused the error.

More information about this error may be available in the server error log.
Apache/2.2.3 (Debian) mod_python/3.2.10 Python/2.4.4 mod_ssl/2.2.3 OpenSSL/0.9.8c Server at pixxen.de Port 80

siehe: http://pixxen.de/cpg/

Allerdings ist es ja auch eine alte cpg version und ich wollte dann updaten, aber ich kann ja nichtmal updaten.

Würdet ihr empfehlen, eine komplett neue Version zu installieren und dann nur die Datenbank dort einzupflegen?!
Und wenn ja, dann wie?!

[Αndré]

Mit dieser Fehlermeldung kann ich gerade gar nicht so viel anfangen. Schlägt dir da eventuell eine .htaccess-Datei quer?

Würdet ihr empfehlen, eine komplett neue Version zu installieren und dann nur die Datenbank dort einzupflegen?!

Wenn ich den Fehler nicht finden würde, würde ich ein frisches CPG installieren, dort die alte Datenbank drüberbügeln, update.php ausführen und den albums-Ordner ersetzen.

[allibert]

Die alte Datenbank besteht quasi schon, aber ich kann coppermine nicht einfach auf die datenbank installieren und dann update.php ausführen, oder?!

oder wie meinst du "alte datenbank" drüberprügeln?!
Einfach neu installieren und dann die neue db durch die alte ersetzen und dann update.php drüber, ja?!

[Αndré]

Einfach neu installieren und dann die neue db durch die alte ersetzen und dann update.php drüber, ja?!

Genau. Im Endeffekt werden bei der Installation ja eigentlich nur die Verbindungsdaten zur Datenbank in die Config-Datei geschrieben und die Datenbank erstellt. Theoretisch könntest du auch gleich die "richtigen" Verbindungsdaten zur bestehenden Datenbank angeben. Aber ich bin mir nicht zu 100% sicher, ob bei der Installation nicht noch mehr passiert außer die beschriebenen Sachen. Von daher kann es ja nichts schaden, wenn du CPG vorher einfach mal installierst. Dann siehst du auch gleich ob es funktioniert oder nicht und kannst ggf. Fehler einschränken.

[allibert]

Okay, vielen Dank. Wir werden das erstmal ausprobieren.

[Joachim Müller]

Wenn ich den Fehler nicht finden würde, würde ich ein frisches CPG installieren, dort die alte Datenbank drüberbügeln, update.php ausführen und den albums-Ordner ersetzen.

Das ist die richtige Methode für jemanden, der sich einigermassen auskennt. Wenn aber eine bestehende Live-Installation repariert werden soll empfehle ich es genau anders herum: über den alten Scherben (vorher exaktes Backup sowohl der Dateien per FTP als auch der Datenbank erstellen!) würde ich ein Update laufen lassen wie in der Doku beschrieben, d.h. die Coppermine-Kerndateien ersetzen. Grund für diese Empfehlung ist: die Möglichkeiten, Fehler zu begehen sind für Anfänger etwas geringer.
Der Update-Ablauf, wie wir in in der Doku beschreiben ist nicht aus Zufall so, wie wir ihn beschreiben, sondern aufgrund langer Beobachtung der Fehler unserer Endbenutzer und der Beschreibung der Wehwehchen, mit denen sie so beim Support aufschlagen.
Natürlich ist es möglich, ,eine separate Neu-Installation durchzuführen und dann den Dump der "alten" Datenbank darüber zu stülpen, aber mal Hand aufs Herz: wer kann das? Leute, die erfahren im Umgang mit mySQL Datenbanken sind. Für unerfahrene Benutzer stellen unterschiedliche mySQL-Versionsstände, unterschiedliche phpMyAdmin-Versionsstände, unterschiedliche Sicherungsgoptionen (Vollständige 'INSERT's/Erweiterte 'INSERT's etc.), unterschiedliche Tabellen- und Datenbank-Kollationen absolut unüberbrückbare Hindernisse dar, so dass das "Überschreiben" der neu-installierten Datenbank mit dem alten Dump zu einem reinen Glücksspiel gerät.
Wie an diesem Thread besonders deutlich wird besteht ein direkter Zusammenhang zwischen Können und regelmäßigen Backups, nur leider ist das Verhältnis proportional und nicht umgekehrt proportional: je höher der Kenntnisstand eines Webseitenbetreibers, desto eher macht er auch häufige und korrekte Backups. Umgekehrt gilt: je schlechter der Kenntnisstand, desto weniger wahrscheinlich ist es, dass sich der Webseitenbetreiber jemals Gedanken über Backups macht. Da hilft es auch nicht, über den Webhost zu schimpfen (tut mir leid, das musste raus): das regelmäßige Erstellen von Backups ist nicht die Aufgabe des Webhosts, es sei denn, dass das explizit vertraglich vereinbart wurde. Allibert, bitte nicht falsch verstehen: ich will Dich hier nicht öffentlich zusammenfalten; mir ist klar, dass es allen Anfängern so geht (vielleicht tue ich Dir auch Unrecht mit der Behauptung, Du wärst ein Anfänger in Sachen mySQL). Mir geht es vielmehr um folgendes: ich will einmal im Detail erklären, warum wir immer wieder so Mantra-haft auf die exakte Einhaltung der Vorgehensweise laut Doku bestehen, was ein Update angeht: natürlich hätte eine Neu-Installation des Pakets und eine anschließende Übernahme des alten Datenbestandes den gleichen Effekt wie die von uns empfohlene Vorgehensweise des Überschreibens der bestehenden Alt-Installation mit neuen Paketdaten, nur gelingt eben die erstgenannte Option sehr selten. Die entsprechenden Support-Threads verlaufen sich dann in der Regel in endlose Details und der frustrierte Anwender fragt sich: warum muss das alles so kompliziert sein? Warum muss ich mich mit Kollationen und ähnlichem Datenbank-Murks herumschlagen, wo ich doch nur eine Fotogalerie betreiben will? Die stereotype Antwort klingt dem Benutzer in der Regel wie Hohn in den Ohren: falsche Vorgehensweise, benutze die von uns empfohlene Vorgehensweise laut Doku. Klingt lahm, ist aber echt der einzige Ausweg aus dem Dilemma.
Beim Umzug von einem Server auf den anderen oder wie im vorliegenden Fall beim Rücksichern einer Vor-Version von einem Server auf den anderen sind die Dinge natürlich sehr vertrackt, da der Benutzer sich so oder so mit dem Datenbank-Dump beschäftigen muss, und zwar nicht nur dem Backup, sondern auch dem Restore. Wenn es der Webhoster anbietet würde ich da echt ein bezahltes Support-Angebot von denen annehmen.

Aber ich bin mir nicht zu 100% sicher, ob bei der Installation nicht noch mehr passiert außer die beschriebenen Sachen.

Bei einer Installation passiert genau das von Dir beschriebene:

• Allerlei Tests, ob Verzeichnisse beschreibbar sind, die Minimal-Voraussetzungen erfüllt sind und eine Image Library zur Verfügung steht
• Anlegen der Datenbank-Tabellen
• Füllen der Konfigurations-Tabelle mit Standard-Werten
• Erzeugen der Datei include/config.inc.php, in der die mySQL-Verbindungseinstellungen gespeichert werden
• Erzeugen der Datei include/install.lock, die verhindert, dass der Installationsassistent ein zweites Mal ausgeführt werden kann
• Erzeugen des Admin-Kontos in der Benutzertabelle der Datenbank

Joachim

[Αndré]

natürlich hätte eine Neu-Installation des Pakets und eine anschließende Übernahme des alten Datenbestandes den gleichen Effekt wie die von uns empfohlene Vorgehensweise des Überschreibens der bestehenden Alt-Installation mit neuen Paketdaten

Da ich glaube, dass die Fehlermeldung aus einer fehlerhaften .htaccess-Datei resultiert (belehrt mich eines Besseren), würde der Fehler nach dem Überschreiben der Dateien trotzdem noch auftauchen, da im Installationspaket ja keine .htaccess-Dateien beiliegen (und die evtl. Vorhandenen somit bestehen bleiben).
Resultiert die Fehlermeldung aus den Coppermine-Dateien, würde es mit dem Überschreiben natürlich klappen und wäre zudem auch noch einfacher durchzuführen

Allibert wird uns diesbezüglich hoffentlich bald aufklären 

[Joachim Müller]

Der von Allibert gemeldete Fehler kann in der Tat auch durch eine fehlerhafte .htaccess-Datei veruracht werden. Genaue Einblicke würde (wie vom Erläuterungstext der Fehlermeldung auch vorgeschlagen) ein Blick in die Logs des Servers bringen.

Zum Thema .htaccess vielleicht noch ein paar Erklärungen für Dritte: es handelt sich dabei um eine Konfigurationsdatei für Apache-Server auf Posix-kompatiblen Betreibssystemen (also im wesentlichen Unix- und Linux-basierte Systeme, also der Löwenanteil der produktiven Webserver). Der vorangestellte Punkt im Namen bedeutet bei diesen Betriebssystemen, dass es sich um eine versteckte Systemdatei handelt. Sie wird normalerweise nicht angezeigt. Leider halten sich auch etliche FTP-Clients daran, solche versteckten Dateien nicht anzuzeigen (in manchen Fällen hat auch der Webhost Vorsorge getroffen und das Auflisten der .htaccess-Datei in der FTP-Applikation unmöglich gemacht). Sollte es also eine Frage der Einstellungen sein, dann kann es helfen, die entsprechende Konfiguration des FTP-Clients zu treffen. Wenn es nicht möglich ist, auf dem Server bestehende, möglicherweise fehlerhafte .htaccess-Dateien anzuzeigen, dann ist es aber in der Regel möglich, diese mit einer leeren Datei zu überschreiben und so den Fehler zu beseitigen. Dazu einfach auf dem Client eine leere Textdatei erzeugen, diese umbenennen in .htaccess (Windows zickt manchmal dabei) und per FTP auf den Server übertragen, wo die bestehende Datei dann überschrieben wird. Wahlweise kann der Webhost helfen: der ist auf jeden Fall in der Lage, eventuell vorhandene .htaccess-Dateien einzusehen und zu ändern oder löschen.

[Gonzales]

Zuviel der Worte. Vermutung: Versionsmix

http://pixxen.de/cpg/themes/classic/template.html

[Gonzales]

http://pixxen.de/cpg/docs/theme.htm

[Αndré]

Dass eine sehr alte Version von Coppermine verwendet wird (offenbar Version 1.3.3), ändert nichts an der Tatsache, dass die Galerie nicht funktioniert, sondern eine Fehlermeldung vom Server ausgespuckt wird.

Vermutung: Versionsmix

Was meinst du mit Versionsmix? Dateien von Version 1.3.x mit Datenbank von 1.4.x?

[Gonzales]

Weiß der Teufel, was der dort installiert hat.
Wenn bei Aufruf von http://pixxen.de/cpg/include/themes.inc.php kein 500-Error, sondern schlicht und einfach ein "NOT FOUND" erscheint, dann kann wohl kaum eine wie auch geartete CPG-Version starten.

Soweit kommts aber auch garnicht, denn bei der init.inc.php ist er wieder da, der 500er.

Werde mich aber nicht weiter einmischen.

Viel Spaß noch mit dem User

[Gonzales]

Was meinst du mit Versionsmix? Dateien von Version 1.3.x mit Datenbank von 1.4.x?

Ja, oder auch teilweise umgekehrt.

[JohnnyBolero]

Hallo,
ich bin derjenige, der für die Website verantwortlich und somit auch für das nicht erstellen des Back-Ups verantwortlich ist, also erstmal alle kritik runter von allibert, den ich um hilfe bat, und rauf auf mich.
das vorhin einige dateien nicht zu erreichen, bzw zu finden waren, lag an mir, da ich eure vorschläge ausprobiert habe.
und zwar beide:

jeweils back-up der daten & alter datenbank gemacht
neue datenbank erstellt
cpg1.3.3 hochgeladen
install.php aufgerufen
fehler 500

dann cpg1.4 hochgeladen mit config.inc und anycontent vom back-up
update.php aufgerufen
fehler 500

hat also beides nicht funktioniert, da ich mich an die tutorials gehalten habe

[Αndré]

neue datenbank erstellt
cpg1.3.3 hochgeladen
install.php aufgerufen
fehler 500

Also das haben wir hier nirgens empfohlen.

Bitte erstelle auf dem Server ein neues Verzeichnis und installiere dort ein frisches Coppermine 1.4.21 ohne irgendwelchen Modifikationen oder Altdaten.

[JohnnyBolero]

achso,
ich dachte ich sollte die version installieren, zu der die datenbank passt, da ich die ja später drüberbügeln soll, und anschließend auf die neuste version upgraden
aber gut, ich machs jetzt so

[Αndré]

ich dachte ich sollte die version installieren, zu der die datenbank passt [...] und anschließend auf die neuste version upgraden

Allerdings ist es ja auch eine alte cpg version und ich wollte dann updaten, aber ich kann ja nichtmal updaten.

Wir haben doch schon festgestellt, dass das nicht funktioniert

Wir haben auch mehrere Wege beschrieben, wie ihr zu einer Lösung kommen könntest. Ich bin davon ausgegangen, dass du das schon ausprobiert hast.

[Joachim Müller]

Zuviel der Worte.

Das geht Dich einen feuchten Ziegenkäse an, wieviele Worte ich benutze. Geh mit den anderen Kindern aus Rosenheim spielen und erspare mir weitere Wortwechsel mit Dir, OK?

also erstmal alle kritik runter von allibert, den ich um hilfe bat, und rauf auf mich.

Ist nicht passiert. Es wurde keine Kritik an seinem Verhalten geäußert.

das vorhin einige dateien nicht zu erreichen, bzw zu finden waren, lag an mir, da ich eure vorschläge ausprobiert habe.
und zwar beide:

keiner unserer Vorschläge hätte einen 404 not found zur Folge haben dürfen, da keiner besagte, dass Du irgend welche Dateien löschen sollst - da hast Du doch wohl etwas anderes gemacht.

Nochmal, ganz langsam: der Fehler "500 internal server error" ist genau das, was drauf steht: ein Fehler des Servers. Die Fehlermeldung ist auch so nett und gibt Anweisungen, wie weiter vorzugehen ist:

Internal Server Error

The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator,

Also: wir sind da die denkbar falschesten Ansprechpartner - wenn nicht mal eine Neuinstallation läuft, dann ist der Server verkorkst oder bringt nicht die Mindestvoraussetzungen mit. Ich schlage vor, dass ihr exakt das tut, was der liebe Onkel Apache Euch rät:

Please contact the server administrator

Das ist in der Regel der Webhost. Der sollte auch in der Lage sein, in die Server-Logs Einblick zu nehmen und zu verraten, was denn nun genau schief läuft.

[Gonzales]

keiner unserer Vorschläge hätte einen 404 not found zur Folge haben dürfen, da keiner besagte, dass Du irgend welche Dateien löschen sollst - da hast Du doch wohl etwas anderes gemacht.

Und genau das hättest du herausgefunden, wenn du mit Hirn an die Lösung des Problems herangegangen wärst.

Das geht Dich einen feuchten Ziegenkäse an, wieviele Worte ich benutze.

Lass deine Gegner nie erkennen, dass du erregt bist und dein Herz schneller als normal schlägt, sonst hast du schon verloren, bevors erst richtig losgeht.

Geh mit den anderen Kindern aus Rosenheim spielen und erspare mir weitere Wortwechsel mit Dir, OK?

München bitte. Das ist dort, wo der FCB so hervorragenden Fußball spielt.

Nochmal, ganz langsam: der Fehler "500 internal server error" ist genau das, was drauf steht: ein Fehler des Servers. Die Fehlermeldung ist auch so nett und gibt Anweisungen, wie weiter vorzugehen ist:

Kompletter Unsinn, die Schuld für einen 500er IMMER beim Server zu suchen. Im vorliegenden Falle war es jedenfalls so, dass Coppermine-Code im Zusammenspiel mit fehlenden und/oder unterschiedlichen Datei-Versionen beim Zugriff auf die Datenbank den "Internal server error" auslösten. Du musst eben noch viel lernen. Deine didaktischen (Un)fähigkeiten bedürfen dringend einer Aufbesserung.

Gonzales

[Joachim Müller]

Womit Du das geschafft hast, worauf Du es doch schon die ganze Zeit angelegt hast: Du hast hier Hausverbot. Geh zurück dahin, wo Du so gerne über anderer Leute lästerst und tue genau das: spiel Dich dort auf.

Lass deine Gegner nie erkennen, dass du erregt bist und dein Herz schneller als normal schlägt, sonst hast du schon verloren, bevors erst richtig losgeht.

Du empfindest Dich also als Gegner und redest von "verlieren"? So läuft also Dein Leben ab? Du tust mir leid.

Kompletter Unsinn, die Schuld für einen 500er IMMER beim Server zu suchen. Im vorliegenden Falle war es jedenfalls so, dass Coppermine-Code im Zusammenspiel mit fehlenden und/oder unterschiedlichen Datei-Versionen beim Zugriff auf die Datenbank den "Internal server error" auslösten. Du musst eben noch viel lernen. Deine didaktischen (Un)fähigkeiten bedürfen dringend einer Aufbesserung.

Ich habe auch nie etwas anderes behauptet: der Server ist nie alleine "schuld", und das habe ich auch nie behauptet. Es ist natürlich immer ein Zusammenspiel zwischen Skript, Benutzer-Interaktion und Server. Ich habe gesagt, dass ein "Internel Server Error" eine Fehlermeldung des Servers ist, im Gegensatz zu einer Fehlermeldung innerhalb der Anwendung (bei Coppermine beispielsweise "Leider gibt es kein Album, in das Du Bilder hochladen darfst"). Lege mir keine Worte in den Mund.
Es steht Dir nicht zu, in dem Ton mit mir zu sprechen, den Du anschlägst. Es handelt sich bei Deinem Geschreibsel nur um gezielte Provokationen, ganz gleich, ob Du mich herablassend als "Müllerchen" titulierst (eine Spitzenleistung von einem Typen, der sich hinter der Anonymität eines Spitznamens versteckt) oder über meine didaktischen Unfähigkeiten referierst. Aber das geht Dich ja jetzt Gott sei dank nichts mehr an - Du bist hier raus und kannst das für Deinesgleichen übliche Spielchen der Neuanmeldung unter anderen Namen starten. Viel Spaß noch.

Joachim