Nach Umzug geht nichts mehr, PHP 500 Error, Front- und Backend nicht erreichbar

Hallo,

 

wir besitzen bei Strato ein Webhosting Paket welches uns mit der Zeit viel zu langsam wurde.

Weiterhin reichten auch die Ressourcen nicht mehr aus (z.B. nur 128MB Ram Limit etc.) daher haben wir uns bei netcup einen VServer gemietet.

Auf dem VServer haben wir unter einer temporären Domain ein neues Shopwaresystem (gleiche Version wie Live-System (5.3.4)) aufgebaut und testweise ein paar hundert Artikel importiert.

Wir haben dann nach und nach verschiende Sachen am Server verändert, vorrangig um Shopware schneller aber z.T. auch sicherer zu machen, wie z.B.

PHP 5.X --> PHP 7.0

APCU Cache

Upgrade der MySQL Version

mod_rewrite aktiviert

 

Nach allen Änderungen lief der Server absolut flüssig und problemlos und wir haben einen Snapshot davon angefertig.

Am Wochenende dann der Umzug:

  1. Also Shop Offline gesetzt und Daten (bis auf /var/cache/production_xxx) herunter geladen.
  2. MySQL Datenbank exportiert
  3. neue MySQL Datenbank und Benutzer auf netcup erstellt und die Live-Shopware-Datenbank importiert
  4. Test-Shopware-Daten platt gemacht und Live-Shopware-Daten up-geloaded.
  5. Shopware/config.php zwecks MySQL Login bearbeitet

 

Wärend des Umzugs gab es ein paar (dabei schon gelöste) Stolpersteine:

  1. auf der verwendeten Partition war nicht genug Speicherplatz frei (viel mehr Bilder als im Testsystem) --> also über netcup (SCP) die GParted Live CD eingelegt und “freien Speicher” zur Partition hinzugefügt
  2. beim Upload der MySQL Datenbank war die Maximale Dateigröße auf 8MB eingestellt, was bei einer xxx.sql Datei von mehr als 20 MB blöd war, wurde dann über server config erhöht und musste später trotzdem nochmal mit (putty) SET GLOBAL max_allowed_packet=1000000000; gesetzt werden. --> Danach war der Upload erfolgreich.
  3. beim Anlegen (und Rechtevergabe) eines mySQL Benutzers wurde mir “MySQL Error #1558 - Column count of mysql.proc ist wrong” angezeigt. Wurde dann über (putty) mysql_upgrade --force -uroot -p behoben und danach funktionierte es.

 

Mein Plan war es das Live-System jetzt erstmal auf der temporären-Domain zum laufen zu bringen, dann die Live-Domain zu netcup umzuziehen und dann Plugin Lizenzen zu überarbeiten (falls notwendig - da es ja wieder die selbe Domain wäre).

Da bei unserem alten Live System (Webhosting auf Strato) die Mod_rewrite (RewriteEngine on und RewriteBase /) nicht funktionierte, während diese auf netcup notwendig ist (und auch auf dem Test_System aktiv war und funktionierte) wurde die Test_System . htaccess verwendet.

Aktuell gibt es anders als beim alten Live-System noch kein ssh (http s ) und auch Plugin Linzenzen wurden noch nicht geändert.

In den Shopware Log und Server Log Dateien habe ich keine aktuellen Einträge gefunden (hoffe ich habe nichts übersehen), daher stehe ich zugegebenermaßen ziemlich auf dem Schlauch.

Die Shopware/Config.php so zu modifizieren, dass ich irgendeinen Fehler angezeigt bekomme hat nichts bewirkt. (Siehe http://community.shopware.com/Fehlermeldungen-in-Shopware-debuggen_detail_1880.html und http://community.shopware.com/_detail_1801.html)

 

Alles was ich sehe ist kein Frontend und kein Backend sondern nur PHP 500 Error ohne konkreten Fehlercode.

config.php:

config.php

.htaccess:

.htaccess

Danke schon vorab für jeden Hinweis.

Erspare Dir den Ärger und ziehe zu: https://de.shopware.com/Partner/list/type/hosting

Ein 500er-Fehler sollte im Error-Log der Website auftauchen. Wenn nicht, kontaktiere mal Deinen Hoster.

Timme Hosting - schnelles nginx-Hosting

www.timmehosting.de

1 Like

@TimmeHosting schrieb:

Ein 500er-Fehler sollte im Error-Log der Website auftauchen. Wenn nicht, kontaktiere mal Deinen Hoster.

image

Timme Hosting - schnelles nginx-Hosting

www.timmehosting.de

In den Logs habe ich natürlich zuerst nachgesehen, da waren auch ein paar Sachen drin die ich aber inzwischen schon behoben habe.

z.B. konnte man wegen zu niedrigen Rechten nicht auf die /shopware/config.php zugreifen und ioncube wurde geladen obwohl es bereits lief.

Seit dem steht in /var/log/appache2/error.log nurnoch sowas (den Neustart habe ich manuell gemacht) :

[Tue Jan 30 11:28:00.944917 2018] [mpm_prefork:notice] [pid 19109] AH00169: caught SIGTERM, shutting down
[Tue Jan 30 11:28:40.887394 2018] [mpm_prefork:notice] [pid 699] AH00163: Apache/2.4.10 (Debian) configured – resuming normal operations
[Tue Jan 30 11:28:40.940300 2018] [core:notice] [pid 699] AH00094: Command line: ‘/usr/sbin/apache2’

Netcup habe ich dazu natürlich angeschrieben aber da war die Hilfe (verständlicher Weise) eher eingeschränkt da es ja nunmal kein “managed Server” ist.

Netcup Support:

 "Sie besitzen bei uns einen virtuellen Server. Wir stellen Ihnen die Laufzeitumgebung bereit. Zu individueller Software und zur Einrichtung können wir keinen Support geben. Nach Einrichtung haben wir keinen Zugriff mehr auf Ihr System. Die Einrichtung und Konfiguration Ihrer Dienste und Pflege obliegt Ihrer Verantwortung." 

Das Problem bleibt also erstmal wie es ist, weitersuchen oder neu machen … die Qual der Wahl.

 

Trotzdem erstmal danke für den Tipp Timme :wink:

 

Fehler sind gefunden.

Froxlor schreibt die Logs nicht nach ‚/var/log/apache2‘ sondern nach ‚/var/customers/logs‘ - mit dem Programm ‚fatrace‘ war das sehr schnell zu finden - auch wenn man (wie ich) keine große Ahnung von Froxlor hat!

 

Die Fehler waren dann einerseits Verzeichnisrechte (Apache/Shopware durfte keinen Cache schreiben) und danach noch ein Fehler in der Tabelle der shop-Core Daten. Da musste die main_id auf ‚1‘ gesetzt werden, sonst kann der Programmcode nicht die richtigen Daten fetchen. Ich hab ein paar Stunden dafür debuggen müssen, denn die Fehlermeldung

PHP Fatal error: Uncaught Doctrine\ORM\EntityNotFoundException: Entity of type ‚Shopware\Models\Shop\Shop‘ for IDs id(0) was not found

klingt erstmal sehr verwirrend. Der große Hint war dort das „for IDs id(0)“ denn der Hauptshop hatte die ID 1.

 

Thomas

1 Like