Wordpress Installation Error 500

Deex

Member
Guten Tag,

ich habe aufgrund eines Hardware Defektes meinen Server nach einigen Jahren neu initialisiert, also von Grund auf alles Neu- Installiert.
Dabei habe ich Debian 10 sowie NGINX mit Maria DB und PHP 7.3 verwendet (natürlich nach howtoforge). Ich wollte dann Wordpress (aktuelle Version) installieren und erhalte umgehend einen Internen Server Fehler bei Schritt zwei der Installation. Ich habe dann in den error.log sowie in den php7.3 Log und Pool log geschaut es gab hier überhaupt keine Angabe warum er diesen Fehler erzeugt. Ich habe daraufhin Nginx mit --debug kompiliert und sehe auch im Debug log keinerlei hinweise woher dieser Fehler stammt, auch habe ich es schon mit php 5.6 probiert und hier ebenso einen Internen Server fehler erhalten. Andere PHP Scripte gehen wie z.B. die info.php . Ich bin aufgrund des mangels an hinweisen woher der kommt echt ratlos und hoffe das ihr eine Idee habt woran es liegt. Der Error log liegt im Anhang da so ein Debug log doch recht groß ist.

Hier meine Nginx settings
Code:
--prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_stub_status_module --with-http_auth_request_module --with-threads --with-stream --with-stream_ssl_module --with-http_slice_module --with-mail --with-mail_ssl_module --with-file-aio --with-debug --with-http_v2_module --with-cc-opt='-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-z,relro -Wl,--as-needed' --add-module=/usr/local/src/ngx_cache_purge --add-module=/usr/local/src/nginx-rtmp-module --add-module=/usr/local/src/ngx_brotli --add-module=/usr/local/src/ngx_http_auth_pam_module


Nginx Conf.
Code:
server {
        listen *:80;
        listen [::]:80;
        listen *:443 ssl http2;

        brotli on;
        brotli_comp_level 6;
        brotli_static on;
        brotli_types application/atom+xml application/javascript application/json application/rss+xml
                     application/vnd.ms-fontobject application/x-font-opentype application/x-font-truetype
                     application/x-font-ttf application/x-javascript application/xhtml+xml application/xml
                     font/eot font/opentype font/otf font/truetype image/svg+xml image/vnd.microsoft.icon
                     image/x-icon image/x-win-bitmap text/css text/javascript text/plain text/xml;

    ssl_protocols TLSv1.3 TLSv1.2;
        listen [::]:443 ssl http2;
        ssl_certificate /var/www/clients/client1/web1/ssl/websiteurl.crt;
        ssl_certificate_key /var/www/clients/client1/web1/ssl/websiteurl.key;

        server_name websiteurl ;

        root   /var/www/websiteurl/web/;
        disable_symlinks if_not_owner from=$document_root;
        pagespeed on;


        index index.html index.htm index.php index.cgi index.pl index.xhtml;
      
       location /blog/ {
            try_files $uri $uri/ /blog/index.php?$args;
        }


        if ($http_x_forwarded_proto = "http") {
         return 301 https://$server_name$request_uri;
        }


        error_page 400 /error/400.html;
        error_page 401 /error/401.html;
        error_page 403 /error/403.html;
        error_page 404 /error/404.html;
        error_page 405 /error/405.html;
        error_page 500 /error/500.html;
        error_page 502 /error/502.html;
        error_page 503 /error/503.html;
        recursive_error_pages on;
        location = /error/400.html {

            internal;
            auth_basic off;
        }
        location = /error/401.html {

            internal;
            auth_basic off;
        }
        location = /error/403.html {

            internal;
            auth_basic off;
        }
        location = /error/404.html {

            internal;
            auth_basic off;
        }
        location = /error/405.html {

            internal;
            auth_basic off;
        }
        location = /error/500.html {

            internal;
            auth_basic off;
        }
        location = /error/502.html {

            internal;
            auth_basic off;
        }
        location = /error/503.html {

            internal;
            auth_basic off;
        }

        error_log /var/log/ispconfig/httpd/websiteurl/error.log debug;
        access_log /var/log/ispconfig/httpd/websiteurl/access.log combined;

        location ~ /\. {
            deny all;
        }

        location ^~ /.well-known/acme-challenge/ {
            access_log off;
            log_not_found off;
            auth_basic off;
            root /usr/local/ispconfig/interface/acme/;
            autoindex off;
            index index.html;
            try_files $uri $uri/ =404;
        }

        location = /favicon.ico {
            log_not_found off;
            access_log off;
            expires max;
            add_header Cache-Control "public, must-revalidate, proxy-revalidate";
        }

        location = /robots.txt {
            allow all;
            log_not_found off;
            access_log off;
        }

        location /stats/ {

            index index.html index.php;
            auth_basic "Members Only";
            auth_basic_user_file /var/www/clients/client1/web1/web//stats/.htpasswd_stats;
            add_header Content-Security-Policy "default-src * 'self' 'unsafe-inline' 'unsafe-eval' data:;";
        }

        location ^~ /awstats-icon {
            alias /usr/share/awstats/icon;
        }

        location ~ \.php$ {
            try_files /7412bfac069d992eac0d84b40a441684.htm @php;
        }

        location @php {
            try_files $uri =404;
            include /etc/nginx/fastcgi_params;
            fastcgi_pass unix:/var/lib/php7.3-fpm/web1.sock;
            fastcgi_index index.php;
            fastcgi_param DOCUMENT_ROOT /web;
            fastcgi_param HOME /web;
            fastcgi_param SCRIPT_FILENAME /web$fastcgi_script_name;
            fastcgi_intercept_errors on;
        }




}
 

Anhänge

  • error.zip
    34,3 KB · Aufrufe: 520

Till

Administrator
Der Fehler sollte im normalen nginx error.log bzw. dem error.log der website stehehen, nginx mit debug kompilieren kann man zwar machen, hilft da aber meiner Meinung nach nicht weiter, denn es wird sich vwemutlich um einen PHP und nicht Nginx Fehler handeln. Ich würde daher debug im nginx erstmalö wieder abschalten, so kann man es ja kaum lesen :) und dann in die php.ini schauen und dort den error level hoch schalten. wenn eine simple info.php geht, das cms aber nicht, dann spricht dass dafür dass entweder dateirechte nicht alle passen oder PHP Module fehlen.
 

Deex

Member
Hi Till,

In der Php.ini ist eingestellt
Code:
error_reporting =E_ALL
Bzw. noch zusätzlich

Code:
; log PHP errors to a file
log_errors = on
error_reporting = 32767
error_log = /var/log/joelphp.log

Der Log bleibt beim Fehler 500 leer, die letzten Einträge sind das er gestartet hat meine joelphp ist dauerhaft leer.

In der php-fpm.conf

Code:
log_level = debug

Log erneut von Fehlern leer. Ich sehe in PHP Gar nicht erst meine Anfrage.

Das einzige was mir bleibt ist der Access Log von Nginx bei dem es schlicht heißt
Code:
80.187.82.54- - [15/Apr/2021:21:10:21 +0200] "POST /blog/wp-admin/setup-config.php?step=2 HTTP/1.1" 500 1914 "https://my.site/blog/wp-admin/setup-config.php?step=1&language=de_DE" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.128 Safari/537.36"
 

Deex

Member
Also ein Update darauf, ich habe das ganze exakt nach Anleitung von

wiederholt, ohne irgendwo von der Anleitung abzuweichen. Keine Chance Wordpress erzeugt selbst bei einer völlig frischen Installation sofort Interne Server Fehler.
 

Till

Administrator
Sehr merkwürdig, habe selbst die letzten Tagen ISPConfig Nginx Server installiert mit WP, bei mir läuft alles einwandfrei. Schalte mal die eigenen Fehlerseiten in dem web aus und schau ob Du dann im Browser eine andere Fehlermeldung erhältst. Ansonsten mal in der php.ini aktivieren dass PHP die Fehler direkt im Browser ausgeben soll.
 
root /var/www/websiteurl/web/;
disable_symlinks if_not_owner from=$document_root;
pagespeed on;

location @php {
try_files $uri =404;
include /etc/nginx/fastcgi_params;
fastcgi_pass unix:/var/lib/php7.3-fpm/web1.sock;
fastcgi_index index.php;
fastcgi_param DOCUMENT_ROOT /web;
fastcgi_param HOME /web;
fastcgi_param SCRIPT_FILENAME /web$fastcgi_script_name;
fastcgi_intercept_errors on;
}

}[/CODE]
Du setzt das docroot auf
NGINX:
/var/www/websiteurl/web/;
und weiter unten die fastcgi_param auf
Code:
            fastcgi_param DOCUMENT_ROOT /web;
            fastcgi_param HOME /web;
            fastcgi_param SCRIPT_FILENAME /web$fastcgi_script_name;
Damit dürfte die URL auf .../web laufen weil du ja schon web als root angegeben hast. Und wenn du WP für /blog würde doch dann /web/blog/ lauten.
 

geschke

New Member
Hallo!

Ich bin auf denselben Fehler gestoßen, hier eine mögliche Lösung (auch aus mehreren Blog-Beiträgen etc. zusammen kopiert).
Installiert: ISPconfig 3.2.4 nach der "Perfect Server Automated"-Anleitung unter Ubuntu 20.04.2 LTS auf einer VM bei Netcup, als Web-Server sollte Nginx eingesetzt werden, PHP-Versionen 7.4 und 8.0.
Bislang alles prima, Umzug statischer Websites, Mail etc. klappte wunderbar, nur WordPress wollte partout nicht, d.h. es wurden ebenfalls jene 500er-Seiten angezeigt, die ISPconfig im Verzeichnis "error" standardmäßig angelegt hatte.
Es handelte sich um einen Umzug einer WordPress-Site, Datenbank war angelegt, Daten importiert, die Parameter hatte ich in der wp-config.php entsprechend angepasst (dachte ich, dazu gleich mehr :) ).
Installiert war das ganze als vhost-Subdomain, nur wurden jetzt diese 500er-Seiten angezeigt.

Meine erste Vermutung ging in Richtung WordPress-Cache-Plugin, daher diese alle per Commandline aus dem wp-plugin-Verzeichnis gelöscht. Noch immer Fehler 500.

Problem Nr. 1: Wo sind die (PHP-Error-)Logs?

Die suche ich irgendwie noch immer. Ich hätte sie im Logs-Verzeichnis des vhosts erwartet, also /var/www/subdomain.example.com/log/subdomain/error.log, genau wie die access.log. Die liegen auch dort, aber es sind keine PHP-Fehlerausgaben zu finden bzw. nicht einmal bei Anzeige der 500er-Fehler wird etwas dort aufgezeichnet. Der 500er wird brav im access.log mitgeschrieben, aber da sofort der Aufruf der HTML-Seite error/500.html erfolgt, generiert Nginx keine weitere Log-Ausgabe?
Merkwürdigerweise erschien im error.log nur ein einziges Mal eine Fehlermeldung von PHP, alle weiteren Requests zeigten sich hier nicht.

Ich wollte jedoch nicht in den php.ini-Dateien herum fummeln, schließlich möchte ich ISPconfig nutzen, um mir das manuelle Anlegen zu ersparen.
In der wp-config.php hatte ich zunächst WP_DEBUG auf true gesetzt, was aber ebenfalls nicht zur Anzeige der Fehler führte.

Lösung: Die Einstellung "Eigene Fehlerseiten" in der Webseiten-Konfiguration von ISPconfig deaktivieren, also Checkbox abwählen, speichern.

Danach zeigte WordPress (dank WP_DEBUG) immerhin den Fehler an.

Es handelte sich um einen simplen Schreibfehler beim Datenbanknamen in der wp-config.php, somit leicht zu beheben.

(WP_DEBUG danach wieder auf false setzen!)

Die Admin-UI von WordPress war somit schon mal erreichbar.

Der Besuch eines Artikels führte jedoch zu:

Problem Nr. 2: Seite nicht gefunden

WordPress war dahingehend konfiguriert, "schöne" URLs anzuzeigen, also /2021/04/bla-blubb-artikel , d.h. per entsprechender Einstellung im Bereich "Permalinks".
Zuvor war ein Apache-Webserver in Betrieb, die Einstellung erfolgte mittels .htaccess-Datei. Ging mit Nginx natürlich nicht, also mussten Direktiven geändert werden, aber siehe oben, mit wenig oder keinen manuellen Eingriffen, um das ISPconfig-Konzept nicht zu unterlaufen.

Letztlich habe ich folgendes getan:

Als Admin in ISPconfig unter "System -> Direktiven Schnipsel" ein Schnipsel angelegt. Name: WordPress-Konfiguration, Typ nginx, "sichbar für Kunden" -> ja (checked), Aktiv ja, Updates sites using this snippet ja.
Inhalt (schamlos kopiert von https://ww1.4hf.de/2014/06/ispconfig-nginx-webserver-wordpress-startschwierigkeiten.html ):

Code:
location / {
try_files $uri $uri/ /index.php?$args;
}

# Add trailing slash to */wp-admin requests.
rewrite /wp-admin$ $scheme://$host$uri/ permanent;

location ~*  \.(jpg|jpeg|png|gif|css|js|ico)$ {
expires max;
log_not_found off;
}

Vorteil dieses Codes im Vergleich zu anderen Hinweisen: Es ist recht wenig und er ändert die eigentliche PHP-Direktive nicht. Hier läuft PHP-FPM mittels Socket, während etwa andere Beiträge sich auf eine IP-Adresse beziehen, und dann auch nur einen speziellen Port, oder eben auf einen einzelnen Socket, der dann auch nur für eine Website gültig ist.
Das Snippet sollte auch universell für alle per ISPconfig eingerichteten Websites einsetzbar sein (wahrscheinlich wäre das auch per Variable möglich, aber in dem Fall letztlich gar nicht nötig).

Der Kunde muss dann noch zur Nutzung des Schnipsels befähigt werden, dazu als Admin einstellen: Kunde anwählen -> Reiter "Limits" -> "Webserver-Konfigurationsauswahl sichtbar": ja (checked).

Als Kunde eingeloggt habe ich dann die Möglichkeit, unter Webseiten -> Auswahl der jeweiligen Site -> "Webserver-Konfiguration" das zuvor konfigurierte Direktiven-Schnipsel mittels Selectbox auszuwählen (aber als Kunde auch nur wählen, nicht zu ändern).

Hat für mich so funktioniert, und somit könnte man die Möglichkeit auch einem tatsächlichen Kunden bieten, falls man nicht selbst alles in Personalunion ist.

Beste Gruesse,
Ralf

PS. Bin auch erst seit ein paar Tagen mit ISPconfig zugange, bislang gefällt es mir wirklich gut, immerhin hat sich bis jetzt alles lösen lassen. :-D
 

geschke

New Member
PHP logged standardmäßig in das Apache/nginx error.log und dieses findest Du im log Verzeichnis der Webseite, also /var/www/deinedomain.tld/log/error.log. Außer natürlich, Du hast das Logging via php.ini deaktiviert oder aber das verwendete CMS hat es deaktiviert.

Genau, dort bzw. im Log der Subdomain hätte ich sie erwartet, leider hatte WordPress hier ganze Arbeit geleistet... Und zugegebenermaßen war der Fehler recht speziell bzw. WordPress-spezifisch. Wäre ein PHP-Skript selbst fehlerhaft, würde das auch wie von Dir beschrieben im Error-Log stehen. Da das Problem hier jedoch in der Datenbank-Verbindung zu finden war, wurde ein 500er-Fehler erzeugt, der dann prompt durch Nginx auf die Fehlerseite verwiesen hat, und im Error-Log war keine Spur mehr davon zu finden.

Vielleicht liegt der Fall beim Ursprungs-Poster ja ähnlich, von der Beschreibung her hatte es sich für mich in etwa so angehört.
 

Werbung

Top