(proxy_fcgi: Fehler) AH01071: Fehler 'Primärskript kann nicht geöffnet werden:' (Keine solche Datei oder kein solches Verzeichnis)

Question

X-Post von StackOverflow

Ich habe unzählige Forenbeiträge darüber gelesen, aber keine der Antworten scheint meiner Situation zu helfen. Hier ist der Protokollauszug:

[proxy_fcgi:error] [pid XXXX] [client redacted] AH01071: Got error 'Unable to open primary script: /home/user-account/public_html/www/index.php (No such file or directory)'

Ich habe manuell überprüft, ob diese Datei über SSH lesbar ist. Auf andere Nicht-PHP-Dateien kann auch über den Browser zugegriffen werden.

Meine Verzeichnisstruktur ist wie folgt:

/home/user-account
/home/user-account/apps
/home/user-account/apps/old
/home/user-account/apps/current
/home/user-account/public_html
/home/user-account/public_html/old > symlink to > /home/user-account/apps/old
/home/user-account/public_html/test > symlink to > /home/user-account/apps/current
/home/user-account/public_html/www > symlink to > /home/user-account/apps/current

Ich habe 2 Subdomains auf 'domain.com':

old.domain.com
test.domain.com

Aufgrund der Art und Weise, wie cPanel / WHM / Apache ihre virtuellen Hosts ausgibt (unter Berücksichtigung der ServerAlias-Direktive), lautet die resultierende Domänenstruktur:

old.domain.com
www.old.domain.com (I ignore this)
test.domain.com
www.test.domain.com (I ignore this)
domain.com (.htaccess redirects to www.domain.com)
www.domain.com (This is the domain with the issue; also domain.com would be an issue if not for the redirect)

Bis jetzt habe ich meine WordPress-Website unter einem echten Verzeichnis entwickelt /home/user-account/public_html/test. Die Seite ist in einwandfreiem Zustand. Dann habe ich beschlossen, live zu gehen. Ich habe den realen Ordner an seinen aktuellen Speicherort /home/user-account/apps/currentverschoben ( ) und ihn /home/user-account/public_html/testmit ihm verknüpft . Ich habe Apache neu gestartet und überprüft, ob die test.domain.comSite weiterhin wie erwartet funktioniert (Testen des Symlinks). Ich fühlte mich im Symlink-Setup sicher, entfernte meinen ursprünglichen Symlink von /home/user-account/public_html/www(zeigte auf meine alte Rails-App unter /home/user-account/apps/old) und erstellte einen neuen, auf den ich zeigte /home/user-account/apps/current. Zu diesem Zeitpunkt begann das Problem.

httpd.conf:

Der einzige nennenswerte Unterschied zwischen der Test-Subdomain und der Hauptdomäne (mit www-Alias) besteht darin, dass die automatisch generierten Anweisungen der Test-Subdomain auf den tatsächlichen Speicherort des Alias-Ordners verweisen (DocumentRoot / Directory / ScriptAlias ​​werden alle verwendet /home/user-account/public_html/test). Ich glaube, das lag daran, dass ich mit cPanel eine Subdomain erstellt hatte, die auf ein Verzeichnis innerhalb verweisen musste /home/user-account/public_html. Die automatisch generierten Direktiven der Hauptdomäne verweisen jedoch alle auf /home/user-account/public_htmlstatt /home/user-account/public_html/www.

Mit Apache 2.4 kann ich jedoch benutzerdefinierte Konfigurationsoptionen für virtualhost einfügen, indem ich meine custom.conf-Dateien in den entsprechenden Verzeichnissen ablege. Ich brauche also keine für die Test-Subdomain, aber ich musste sie für die Hauptdomain verwenden. Ich weiß, dass sie funktionieren, weil das Fehlerprotokoll (oben in diesem Beitrag) zeigt, dass es den richtigen DocumentRoot verwendet. Hier ist ein Auszug aus der std custom.conf, um zu zeigen, dass ich neben dem Festlegen von DocumentRoot auch die anderen automatisch generierten Anweisungen explizit überschreibe:

DocumentRoot /home/user-account/public_html/www
<IfModule mod_include.c>
  <Directory "/home/user-account/public_html/www">
    SSILegacyExprParser On
  </Directory>
</IfModule>
<IfModule alias_module>
  ScriptAlias /cgi-bin/ /home/user-account/public_html/www/cgi-bin/
</IfModule>
<IfModule ssl_module>
  <Directory "/home/user-account/public_html/www/cgi-bin">
    SSLOptions +StdEnvVars
  </Directory>
</IfModule>

Dateiberechtigungen:

Ich habe die Dateiberechtigungen gegenüber dem ursprünglichen Setup nicht geändert und bereits überprüft, ob sie korrekt sind. Wieder test.domain.comfunktionierte wie erwartet. Es ist nur (www.?)domain.comso nicht.

Andere 'Korrekturen', die nichts bewirkt haben:

• Neuerstellung / Neustart von PHP-FPM (ineffektiv)
• SetHandler / ProxyOverride (SetHandler wird automatisch von rebildhttpdconf für mich erstellt und ich erwarte nicht, dass es das Problem ist, da es für die Test-Subdomain funktioniert; ProxyOverride scheint nichts zu tun)
• Richten Sie WordPress .htaccess ein (bereits vorhanden und entspricht den hier gezeigten. Auch hier funktioniert die Test-Subdomain und es ist ein Alias ​​wie www).

Serverstatistiken:

• EasyApache 4 mit
  • Apache 2.4.43
    • mod_proxy_fcgi
  • PHP 7.3
    • php73-php-fpm

Was auch immer Sie berücksichtigen, denken Sie daran, dass es praktisch keinen Unterschied zwischen den Dateien in der Test-Subdomain und der Hauptdomäne gibt (einschließlich .htaccess). Sie sind beide auf dasselbe Verzeichnis ausgerichtet. Der einzige Unterschied, den ich sehen kann, ist, dass test eine registrierte Subdomain ist und daher von httpd.conf etwas anders behandelt wird als von der Hauptdomain. Ich kann jedoch nicht einfach eine 'www'-Subdomain über cPanel hinzufügen - das lässt mich nicht - wahrscheinlich, weil es sowieso einen Aliase für www gibt.

Ich habe versucht, dies zu beheben, und meine öffentliche Website ist seit mehr als 24 Stunden nicht mehr verfügbar. Daher würde ich mich über jede Hilfe, die Sie leisten können, sehr freuen!

Nachtrag:

Ich weiß nicht, ob es relevant ist (es schien meine alte Rails-App nicht zu beeinträchtigen), aber unter WHM> SSL-Hosts verwalten verweisen meine Hauptdomäne und meine www-Unterdomäne auf ein Dokumentstammverzeichnis von /home/user-account/public_html, während meine Unterdomänen auf das Richtige verweisen entsprechende Verzeichnisse.

Ich habe auch versucht, den vhost in der Hauptdomäne so einzustellen, dass er das Testverzeichnis verwendet (wie die Test-Subdomäne), aber es gibt mir den gleichen Fehler. Ich denke nicht, dass es sich um ein Berechtigungs- / Dateiproblem handelt.

Ich habe auch eine test.php-Datei im /public_htmlVerzeichnis erstellt, um einen direkten Zugriff zu testen. Es ist immer noch fehlerhaft und protokolliert:

AH01071: Got error 'Unable to open primary script: /home/user-account/public_html/www/index.php (No such file or directory)', referer: https:// domain.com/test.php

Answer 1

Und die Antwort ist, dass ich doc_root über die PHP-FPM-Konfiguration für die angegebene Domäne festlegen musste. Warum? Ich weiß nicht - wenn jemand etwas Licht ins Dunkel bringen kann, muss ich die Dinge lieber nicht über die FPM-Konfiguration erledigen und wenn möglich über Apache einstellen. Ich muss das nicht für Subdomains tun ...