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

  • Hallo,


    vorab möchte ich sagen, dass ich das gleiche Thema bereits im Shopware Forum gepostet habe, (-->Klick mich<--) da aber dort noch nicht viel hilfreiches geposted wurde möchte ich aufgrund der hier im Forum höheren Technik-affinität auch hier um Hilfe bitten.



    Wir besitzen (weil zensiert) "einem beliebigen anderem Hoster" ein Webhosting Paket welches uns mit dem wachsenden Shop viel zu langsam wurde.

    Weiterhin reichten auch die Ressourcen nicht mehr aus (z.B. nur 128MB memory_limit (wenn php Version < 7.1) usw) daher haben wir uns bei netcup einen VServer gemietet.

    Auf dem VServer haben wir unter einer temporären Domain ein neues Shopware-Shopwaresystem (gleiche Version wie Live-System (5.3.4)) aufgebaut und test-weise 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 war dann der Serverumzug zu netcup: (nur Server noch nicht Domain)

    1. Also Shop Offline gesetzt und Daten (bis auf shopware/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 (weil 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 (weil zensiert) "einem beliebigen anderem Hoster") 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 (https) 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/…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.



    /shopware/config.php:

    config.php.jpg


    /shopware/.htaccess:



    htaccess.jpg


    Im shopware Forum kam dann nochmal der Hinweis nach Server Logfiles, daher nochmal das was ich da geschrieben habe:


    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:


    [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:

    Code
    "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."


    Problem vorrangig, dass in keiner (mir bekannten) Log-Datei irgendwas (für mich) nützliches steht und ich damit keinen Ansatz finde.


    So, viel Text und (bei mir) wenig Ideen, für jede Hilfe bin ich sehr dankbar. :)


    Viele Grüße

    sgds-shop

    Jacob

  • Die /var/log/apache2/error.log ist das Error-Log des Apache-Dämon.

    Den einzelnen vHosts spendiert man ja in der Regel separate Logs (ErrorLog-Direktive).

    Was steht denn im Error-Log Deines vHosts? Ein 500er wird von Apache jedenfalls geloggt (ansonsten die LogLevel-Direktive prüfen).

  • 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

    Code
    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

  • Auch hier nochmal einen großen Dank an ThomasChr für die wirklich große und selbstlose Hilfe.

    Auf Basis der durch Ihn geleisteten (Vor)-arbeit läuft der Server und das Shopsystem in zwischen problemlos.

    Es gab zwar auch noch viel zutun (z.B. konnte man weder "themes" auswählen noch kompilieren u.ä. Fehler (lag auch an weiteren falschen Werten in der s_core_shops) aber dadurch, dass der Server und das Shopsystem wieder vernünftig geloggt haben, war das alles zu finden und auch zu beheben.


    Danke euch allen für die Tipps und die Mithilfe, vor allen anderen danke dir Thomas.:thumbup: