[GELÖST] CMSMS 2.2.5+6: Extracted file checksum does not match original

antibart · 21. Februar 2018 11:46

Hi,

beim Versuch 2.2.5 oder 2.2.6 zu installieren erscheint bei Schritt 6 - also dem eigentlichen Installationsprozess:

"Extracted file checksum does not match original"

Und installiert wird nichts.

Upload-Methode ist FTP (Binär)
Hoster ist Strato
PHP-Versionen 5.6 bis 7.2 getestet

Kaputt dürften die Dateien nicht sein, da ich beide Versionen auf einem anderen Strato-Webspace installieren konnte. Einziger Unterschied ist, dass das eine Paket "PowerWeb Basic" ist, das andere "PowerWeb Pro". Die Einstellungen sind identisch.

Beitrag geändert von antibart (21. Februar 2018 11:51)

NaN · 21. Februar 2018 13:36

Hm. Klingt merkwürdig. Ein Fehler im CMS würde ich an dieser Stelle ausschließen.
Der Fehler tritt übrigens nach Schritt 6 auf. Also zu Beginn von Schritt 7. Vorher wird keine Checksumme geprüft (also laut PHP Code).

Bei welcher Datei tritt denn der Fehler auf? Der Dateiname sollte i.d.R. mit in der Fehlermeldung ausgegeben werden. Kannst Du die Datei mal hier hochladen bzw. selber mal mit der Installation vergleichen, bei der es funktioniert?

Sind die beiden Server wirklich identisch? Also auch, was Betrübssystem und PHP Module/Libs ageht?

Denn ich vermute, der Fehler entsteht beim Entpacken. Da werden vermutlich beim Erstellen der Dateien Zeilenumbrüche oder BOMs falsch erstellt. Bin mir nicht sicher, ob man da als Entwickler Einfluss drauf nehmen kann.

antibart · 21. Februar 2018 14:18

Danke schonmal für die Zeit.

NaN schrieb:

Hm. Klingt merkwürdig. Ein Fehler im CMS würde ich an dieser Stelle ausschließen.

Ich auch, da es ja bei einem der Server funktioniert. Mit beiden Versionen.

NaN schrieb:

Der Fehler tritt übrigens nach Schritt 6 auf. Also zu Beginn von Schritt 7.

Ich dachte, ich hätte das sogar nachträglich richtig editiert. Bin ich wohl von der Taste gerutscht. Ja - nach Schritt 6. Der macht ja nur Titel und Sprache.

NaN schrieb:

Bei welcher Datei tritt denn der Fehler auf? Kannst Du die Datei mal hier hochladen bzw. selber mal mit der Installation vergleichen, bei der es funktioniert?

Es gibt ja bis Schritt 7 nur eine einzige Datei - die Installationsdatei. Eine in .php umbenannte .PHAR-Datei. Und da dieser Schritt ja "misslingt", bleibt es auch bei dieser einen Datei. Daher kann ich auch nichts vergleichen.

Wenn ich die Meldung ignoriere und zum nächsten Schritt gehe, kommt;

"Could not find include.php file in destination"

NaN schrieb:

Sind die beiden Server wirklich identisch? Also auch, was Betrübssystem und PHP Module/Libs ageht?

EDIT: Ich habe nicht alle Zeilen der phpinfo genauestens überprüft - aber ich würde schon sagen: Ja, identisch. Auch bei der Produktbeschreibung unterscheiden sie sich nur in Zahlen, nicht im Funktionsumfang.

NaN schrieb:

Denn ich vermute, der Fehler entsteht beim Entpacken. Da werden vermutlich beim Erstellen der Dateien Zeilenumbrüche oder BOMs falsch erstellt.

Die Vermutung habe ich auch. Beim FTP-Transfer kommt bei beiden Servern die Meldung "Der Server unterstützt keine Nicht-ASCII-Zeichen." Funktionieren tut es aber zumindest bei einem trotzdem.

Beitrag geändert von antibart (21. Februar 2018 15:10)

antibart · 21. Februar 2018 15:02

Inhalt entfernt (oben als edit eingefügt), da Löschen nicht möglich.

Beitrag geändert von antibart (21. Februar 2018 15:12)

NaN · 21. Februar 2018 15:23

Es gibt ja bis Schritt 7 nur eine einzige Datei - die Installationsdatei. Eine in .php umbenannte .PHAR-Datei. Und da dieser Schritt ja "misslingt", bleibt es auch bei dieser einen Datei. Daher kann ich auch nichts vergleichen

Die Sache ist die, die Checksum kann erst geprüft werden, nachdem die Datei aus dem PHAR-Archiv extrahiert und auf dem Server in das vorgesehene Verzeichnis kopiert wurde. Wenn die Checksum nicht übereinstimmt, dann liegt das daran, dass beim Entpacken/Schreiben der Datei ein Fehler aufgetreten ist. Der Fehler kann sein, dass aufgrund von falscher Kodierung, die Datei tatsächlich nicht 1:1 übereinstimmt. Das könnte man herausfinden, indem man schaut, was nach dem Fehler tatsächlich auf dem Server im Installationsverzeichnis existiert und dann mit einer anderen Installation vergleicht. D.h. wenn das der Fehler ist, dann müsste eine extrahierte Datei auf jeden Fall auf dem Server existieren. Welche das ist, sollte zumindest bei der Fehlermeldung mit ausgegeben werden.

Der Fehler kann aber auch sein, dass die Datei überhaupt nicht geschrieben werden konnte. D.h. man prüft die Checksum einer existierenden Datei gegen die einer nicht existierenden. Das kann logischerweise nicht klappen.

Wenn letzteres das Problem ist, dann müsste beim Installieren aber die Warnung erscheinen:

Warning: md5_file(...): failed to open stream: No such file or directory in ... on line ...

Du ahnst, worauf ich hinaus will? (Puntk 2)
Mach das mal vor der Installation.

"Could not find include.php file in destination"

Logisch, weil er ja im vorherigen Schritt abgebrochen hat.

antibart · 22. Februar 2018 11:18

NaN schrieb:

Mach das mal vor der Installation.

Mit der .htaccess kann ich die Einstellung nicht überschreiben, aber Strato stellt ein error-logfile zur Verfügung.

NaN schrieb:

Warning: md5_file(...): failed to open stream: No such file or directory in ... on line ..

Das passierte, nachdem ich versuchte, die funktionierende Installation zu kopieren und rübergeschaufelt habe. Trotz Anpassung der config, manuelle Leerung des Chaches und so weiter

Ausschlaggebend für den Abbruch während der Installation ist wohl das hier:

AH01215: PHP Fatal error: Uncaught exception 'PharException' with message 'phar "/mnt/.../htdocs/web2018/cmsms-2.2.6-install.php" SHA1 signature could not be verified: broken signature' in /mnt/../web2018/cmsms-2.2.6-install.php:8: /home/strato/http/premium/rid/.../htdocs/web2018/cmsms-2.2.6-install.php

Was mir auffällt ist, dass Strato erst den internen Systempfad (/mnt/...) ausgibt, aber vom empfohlenen Kundenpfad ausgeht (/home/...). Das gab es auch in der kopierten Version

(Uncaught --> Smarty: unable to write file /mnt/.../htdocs/web2018/tmp/templates_c/wrt5a8c51e65e7bd6_20340801 <-- : /home/.../htdocs/web2018/index.php)

Da ich im org-Forum wohl kaum Hilfe erwarten kann, wenn ich verrate, dass ich FTP benutzt habe, habe ich das Ganze noch mal über SSH gemacht. Auch wie empfohlen die ZIP-Datei erst auf dem Server über die Kommandozeile entpackt. Leider mit dem gleichen Ergebnis.

Beitrag geändert von antibart (22. Februar 2018 11:39)

NaN · 22. Februar 2018 11:43

Könnte an verschiedenen PHP Modulen liegen. (suhosin, zend guard, opcache, apc ...)
Aber wenn die beiden Pakete identisch sind, wirds wohl nicht viel Sinn machen, die alle durchzugehen. Weiß grad nicht, ob man die bei Strato ohne Weiteres deaktivieren kann.

antibart · 22. Februar 2018 13:14

Beide nutzen Zend Opcache.

NaN · 22. Februar 2018 14:24

Und lokal installieren und dann hochladen, ist keine Option?

Ich weiß, dass das keine echte Lösung ist, aber ich wäre da mit meinem Latein fürs erste am Ende. Die beiden Web-Hosting Pakete können meiner Meinung nach definitiv nicht identisch sein, sonst würde es ja gehen. Laut Beschreibung auf der Seite von Strato sind sie identisch. Das bezieht sich aber nur auf die angebotene Leistung, nicht auf technische Details hinter den Kulissen.

Weiß nicht wie der Support von Strato so drauf ist und ob die Dir evtl. mehr zum Thema PHAR auf ihren Systemen sagen können.

Ich verstehe nach wie vor nicht, wie man bei einem Installer auf eine Technologie setzen kann, die offenbar nicht ohne Probleme auf jedem Server funktioniert. Warum PHAR? Dadurch wurde nichts vereinfacht. Für niemanden.

antibart · 22. Februar 2018 15:38

NaN schrieb:

Und lokal installieren und dann hochladen, ist keine Option?

Naja, zur Not schon - aber du sagst es ja selbst: Eine Lösung ist das nicht gerade. Das muss ja funktionieren.

Zumal ich das ja bereits probiert habe. Da kam es auch zu Fehlern. Aber vielleicht kommt man denen schneller auf die Schliche.

Ich habs mal im Org-Forum probiert. Mal gucken, ob die Lösungen wieder gelöscht werden. smile

NaN · 22. Februar 2018 16:35

Die kommen Dir dann mit Lösungen, die einen eigenen Root-Server vorraussetzen ... roll

antibart · 26. Februar 2018 10:27

Ich habe mal an den Strato Support geschrieben. Die Antwort enthielt alle Vorschläge, die ich bereits probiert habe: PHP vs, andere Upload Methode, im CMSMS Forum fragen. Danke smile

Was ich aber auch noch getestet habe, ist eine dritte Installation auf einem anderen Basic-Paket. Das sollten dann ja theoretisch identisch sein und auch zu diesem fehler führen.

Das hat aber reibungslos hingehauen. Es ist also davon auszugehen, dass auf speziell diesem Webserver, auf dem die Seite läuft, etwas nicht stimmt oder zumindest anders ist als bei anderen.

antibart · 26. Februar 2018 11:13

Lösung:

Bei Strato unter "Sicherheit" gibt es einen Unterpunkt "Siteguard" -> Dort findet man das Thema "Schreibschutz (de)aktivieren". Standardmäßig ist der nicht aktiviert. In diesem Fall hat ihn der Kunde oder mein Vorgänger aber aktiviert. Für einen Installtionsprozess, bei dem Dateien geschrieben werden, ist das natürlich ungünstig. Schreibschutz Deaktivieren brachte Hilfe.

Beitrag geändert von antibart (26. Februar 2018 11:53)

NaN · 26. Februar 2018 11:54

Man schaue sich dazu mal den Code des Installers an:

Hier klicken, um den Code zum Kopieren zu markieren

$cksum = md5_file($srcspec);
@copy($srcspec,$destname);
$cksum2 = md5_file($destname);

Da wird mit @ ein möglicher Fehler beim Kopieren zwar unterdrückt, aber nicht abgefangen, wodurch beim Einsatz von md5_file ein zweiter möglicher Fehler entstehen kann, der aber weder unterdrückt noch abgefangen wird. Wozu dann überhaupt den ersten Fehler unterdrücken? Mal abgesehen davon, dass das völlig inkonsequent ist, das wird einfach ungeprüft bis zur Exception durchgewunken, deren Fehlermeldung am Ende allerdings nichts mehr mit der Ursache zu tun hat. roll
Dass es sich hierbei um Schreibberechtigungsprobleme handelt, da muss man echt um die Ecke denken.

antibart · 26. Februar 2018 12:04

Ich hätte nur drauf kommen können, nachdem ich die bereits funktionierende Installation hochgeladen hatte. Die Meldungen gingen ja in diese Richtung. Allerdings wusste ich nicht, warum. Dass es da eine Einstellung im Kundenkonto bei Strato gibt, ahnte ich da noch nicht. Es war also ein Search, Trial and Error.

Beitrag geändert von antibart (26. Februar 2018 12:05)

Forum für CMS/made simple

#1 21. Februar 2018 11:46

[GELÖST] CMSMS 2.2.5+6: Extracted file checksum does not match original

#2 21. Februar 2018 13:36

Re: [GELÖST] CMSMS 2.2.5+6: Extracted file checksum does not match original

#3 21. Februar 2018 14:18

Re: [GELÖST] CMSMS 2.2.5+6: Extracted file checksum does not match original

#4 21. Februar 2018 15:02

Re: [GELÖST] CMSMS 2.2.5+6: Extracted file checksum does not match original

#5 21. Februar 2018 15:23

Re: [GELÖST] CMSMS 2.2.5+6: Extracted file checksum does not match original

#6 22. Februar 2018 11:18

Re: [GELÖST] CMSMS 2.2.5+6: Extracted file checksum does not match original

#7 22. Februar 2018 11:43

Re: [GELÖST] CMSMS 2.2.5+6: Extracted file checksum does not match original

#8 22. Februar 2018 13:14

Re: [GELÖST] CMSMS 2.2.5+6: Extracted file checksum does not match original

#9 22. Februar 2018 14:24

Re: [GELÖST] CMSMS 2.2.5+6: Extracted file checksum does not match original

#10 22. Februar 2018 15:38

Re: [GELÖST] CMSMS 2.2.5+6: Extracted file checksum does not match original

#11 22. Februar 2018 16:35

Re: [GELÖST] CMSMS 2.2.5+6: Extracted file checksum does not match original

#12 26. Februar 2018 10:27

Re: [GELÖST] CMSMS 2.2.5+6: Extracted file checksum does not match original

#13 26. Februar 2018 11:13

Re: [GELÖST] CMSMS 2.2.5+6: Extracted file checksum does not match original

#14 26. Februar 2018 11:54

Re: [GELÖST] CMSMS 2.2.5+6: Extracted file checksum does not match original

#15 26. Februar 2018 12:04

Re: [GELÖST] CMSMS 2.2.5+6: Extracted file checksum does not match original

Fußzeile des Forums