PHP gibt "Access denied", Berechtigungsproblem?

Ah, verstehe! Dann versuche ich das mal mit einem anderen Hostname statt eines anderen Ports. Das mit dem hosts-file hat mir noch gefehlt, ich dachte, "localhost" ist die einzige Möglichkeit für einen lokalen Server, der keine richtige Domain hat.

Aber ich fürchte, das wird das Problem mit dem falschen Pfad nicht lösen...
 
Du kannst auch für ne Testinstallation beim Port 8000 bleiben, dann kannst du weiter mit localhost arbeiten. Ich würde nur die document-roots verschiedener vHosts nicht schachteln.

Also konkret:
Port 80 vHost -> /usr/share/nginx/html/
Port 8000 vHost -> /usr/share/nginx/GibbonEduCore-InstallBundle/
(und nicht /usr/share/nginx/html/GibbonEduCore-InstallBundle/)

Oder gleich besser unter /srv/www/GibbonEduCore-InstallBundle, wenn das der von AppArmor unterstützte Bereich für Webseiten sein soll.

Achso und was mir auffällt: Du hattest bei deiner Port 8000 vHost-Konfig das hier stehen:
Code:
root /usr/share/nginx/html/GibbonEduCore-InstallBundle;
Änder das mal auf
Code:
root /usr/share/nginx/html/GibbonEduCore-InstallBundle/;

Edit: Das mit dem / am Ende kann auch falsch sein, ist nur testweise. Ich weiß nicht genau, wie nginx das document-root haben will. Bei meinen Apache vHosts hab ich den / am Ende z.B. nicht gesetzt und das funktioniert wunderbar.
 
Zuletzt bearbeitet:
Bezüglich der Pfadproblematik würde ich einfach mal verschiedene URLs im Browser eingeben und schauen, was dann in der Log-Datei auftaucht. Also wenn du eingibst "localhost/a/b/c.php", taucht denn in der Log-File auf "/a/b/a/b/c.php"? Oder dupliziert er nur einen bestimmten Teil?

Und was für eine Log-File ist das überhaupt? Die von Nginx oder von FPM?
 
Gute Idee! Es hat sich rausgestellt, dass das Problem tatsächlich nur bei dieser ganz konkreten Datei auftritt, es ist also möglicherweise ein Problem in der App selbst....
 
Photon schrieb:
ich dachte, wenn nginx seine Beispieldatei index.html dort drin hat, kann es nicht falsch sein, andere Seiten auch dort reinzuschieben
Nicht ganz richtig. Programme, die über den Paketmanager installiert werden, legen grundsätzlich ihre Defautconfigs, Beispiele, Plugins oder auch Doku unter /usr/share ab.

In dem Verzeichnis ändert man aber nichts. Bei vielen Programmen kopiert man sich aus den Verzeichnissen in /usr/share die zu modifizierende Config und speichert die dann unter dem entsprechenden Verzeichnis in /etc ab.

Bei Webcontent, was über den Paketmanager installiert wird, z.b. Mediawiki oder Phpmyadmin werden die Programminhalte in /usr/share nach /var/www bzw. /srv/www verlinkt. Korrekterweise müsste man in der Webserverconfig eigentlich einen Alias erstellen, der als DocumentRoot angegeben wird.

Photon schrieb:
Bei Debian war die Beispieldatei unter /var/www
Die unterschiedlichen Verzeichnisse sind historisch bedingt. Webcontent liegt bei Suse und (anscheinend) Arch unter /srv/www, während das Standardverzeichnis für Debian, Redhat und Gentoo /var/www ist. Gilt auch für sämtliche Derivate. Siehe dazu auch FHS.

Genauso heißt der Apache-Webserver unter Redhat nicht Apache2 sondern httpd.

Photon schrieb:
In der Hauptkonfiguration nginx.conf ist ja schon das Verzeichnis /usr/share/nginx/html als root für Port 80 festgelegt. Beißt sich das nicht, wenn in einer zweiten Konfiguration ein anderer root für den gleichen Port definiert ist?
Arbeite mal das Vhosts-Tutorial von Digital Ocean durch.

Die Kurzerklärung:
Du kannst beliebig viele VHosts auf Port 80 legen. Die Unterscheidung, welche Server Section ausgelesen wird, findet über Namen in der URL statt. Auf dem DNS-Server macht man das über CNames. Einen DNS-Server brauchst du da nicht zwingend, du kannst auch die Vhost-Namen als Rechnernamen in die /etc/hosts eintragen. Dein Rechner muss halt einfach dem Namen eine IP zuordnen können.
 
Zurück
Oben