it-swarm.com.de

Der Apache-Neustart bewirkt, dass DocumentRoot ein Verzeichnis sein muss, obwohl es sich um ein Verzeichnis handelt und es offenbar keine Probleme mit Berechtigungen gibt

Ich habe was fast sicher eine Neulingfrage. Ich habe erwartet, das Problem beim Schreiben dieser Frage zu finden, aber ich bin immer noch festgefahren.

Ich möchte DocumentRoot für Apache ändern, erhalte aber weiterhin die Fehlermeldung "DocumentRoot muss ein Verzeichnis sein". 

Situation:

  • Der Code wird auf einer virtuellen VMWare-Maschine 4.0.4 build-744019 ausgeführt
  • Die Linux-Version ist Scientific Linux Version 6.4 (Carbon).
  • Die Version von Apache ist Apache/2.2.15 (Unix) (dies ist eine Yum-Installation mit nichts Special)

In der httpd.conf

DocumentRoot "/home/stave/www"

Beim Neustart erhalte ich die Nachricht

Starting httpd: Syntax error on line 292 of /etc/httpd/conf/httpd.conf:
DocumentRoot must be a directory

Schritte bisher:

Ich habe sichergestellt, dass das Verzeichnis existiert:

ls -asl /home/stave
4 drwxrwxrwx.  2 stave stave    4096 Feb  9 09:08 www
It even has a file in it "index.html", so I am very sure that the directory exists

Ich habe in Betracht gezogen, dass dies ein Problem mit Privilegien sein könnte (dies ist eine virtuelle Entwicklungsmaschine, die vom Internet isoliert ist, und ich habe Fehlerbehebung, daher bin ich nicht zu sehr um die Sicherheit besorgt), da Sie die Privilegien auf 777 setzen können.

Ich habe sogar den Benutzer, unter dem Apache ausgeführt wird, geändert (und bestätigt, dass die Änderung mit ps funktioniert), um sicherzustellen, dass Privilegien kein Problem sind.

Paketüberfluss

Es gibt ein paar Stapelüberlaufantworten, aber die meisten sagen "Lies die Fehlermeldung. Es sagt, dass das Verzeichnis nicht wirklich existiert". Andere deuteten an, dass es am Ende einen nachlaufenden Schrägstrich geben könnte, der schlecht wäre. 

Andere Websites

Das Nützlichste, das ich fand, war das das empfahl 

Sie haben wahrscheinlich die Fehlermeldung "DocumentRoot muss ein Verzeichnis sein", obwohl es sich bei SELinux-Erweiterungen tatsächlich um ein Verzeichnis handelt. Führen Sie system-config-securitylevel (oder redhat-config-securitylevel) aus, um SELinux für httpd zu deaktivieren oder SELinux-Berechtigungen dafür zu erteilen. chcon -R -h -t httpd_sys_content_t/pfad/zum/verzeichnis *

Meine Linux-Version ist nicht Security Enhanced Linux. Ohne Verständnis habe ich es trotzdem versucht: keine Auswirkung.

Momentane Situation

Ich habe keine Ideen mehr, um es auszuprobieren, daher würden wir uns sehr über diagnostische Fragen oder Ratschläge freuen

25
Stave Escura

Der Link, den Sie unter "Andere Websites" gepostet haben, zeigt die Hauptursache Ihres Problems auf, nämlich Selinux.

Wenn der Server nicht Teil einer äußerst sicheren Umgebung ist, würde ich Selinux einfach deaktivieren.

Unter RedHat/CentOS/Scientific Linux kann dies einfach durch Editieren von/etc/sysconfig/selinux erledigt werden - suchen Sie den Parameter "selinux" und ändern Sie die Option "erzwingen" in "disabled" (siehe unten)

# SELINUX= can take one of these three values:
#       enforcing - SELinux security policy is enforced.
#       permissive - SELinux prints warnings instead of enforcing.
#       disabled - No SELinux policy is loaded.
SELINUX=disabled

Es ist wahrscheinlich ratsam, den Server nach dieser Änderung neu zu starten.

21
artfuldodger

Sie sollten SELinux nicht einfach deaktivieren.

Sie müssen httpd_enable_homedirs auf on setzen. 

yum -y install policycoreutils-python
setsebool -P httpd_enable_homedirs on
9
Cedric

Ich bin auch heute auf dieses Problem gestoßen und es lag daran, dass ich mein DocumentRoot von/var/www/html nach/srv/www/html verschoben habe. Als Teil unserer Sicherheitsrichtlinien haben wir nicht die Möglichkeit, SELinux einfach zu deaktivieren. 

SO war mein Fix, wie ich herausfand, den SELinux-Dateikontext für/srv so zu ändern, dass er/var entspricht. Ein Kompromiss ja, aber immer noch besser als das Deaktivieren. Abgesehen davon ... Ich habe sichergestellt, dass/srv/www und alle Unterordner den httpd_sys_content_t hatten, um die Ordner unter/var/www zu finden, und alles ist jetzt gut.

7
David

Dies ist im Grunde die gleiche Antwort wie Davids, aber ein wenig klarer ist, dass das http-Serving-Verzeichnis einen falschen SELinux-Sicherheitskontext hat.

Die vollständige Erklärung für dieses Problem finden Sie hier: http://mybroadband.co.za/vb/showthread.php/588183-Fix-403-Forbidden-on-newly-configured-CentOS-6-5-httpd-server - (oder -13-10-Ubuntu-LAMP)

Mein Problem war, dass ich meine Websites in einem anderen Verzeichnis als dem documentroot-Pfad von/var/www/beherbergte. Daher musste ich zur Korrektur die 3. Option im obigen Link verwenden. Ich habe den gleichen Dateikontext in meinem/websites/-Verzeichnis so eingestellt, dass er mit dem von/var/www/übereinstimmt. Seltsam ist, dass frühere Versionen von CentOS 5.5 SELinux nicht installiert/aktiviert haben mussten, da meine anderen Server damit kein Problem hatten und wenn sie ls -Z an der Eingabeaufforderung ausführen, diese Ordner als "unbenannt" angezeigt werden.

Ich verwende CentOS 6.5 unter AWS von der offiziellen Marktplatz-Minimalinstallation. Als ich also den Befehl ls -Z in meinen Ordnern ausgeführt habe, habe ich genau das gesehen, was der Link oben als mögliches Problem zeigt.

Mit dem Befehl chcon wurde mein Problem behoben!

Ersetzen Sie einfach html/durch das Verzeichnis, das Sie verwenden möchten!

chcon -Rv --type = httpd_sys_content_t html /

chcon -Rv --user = system_u html /

Nebenbei musste ich auch iptables deaktivieren, damit das Routing funktioniert. Die Standardeinstellungen waren leere Seiten.

dienst iptables stoppt

Hoffe das hilft jedem bei dem gleichen Problem.

5

Erstens gibt es keinen Grund, selinux zu deaktivieren, um dieses Problem zu beheben. Ändern Sie einfach den Kontext der selinux-Datei.

Zweitens sollten Sie beim Ändern des Selinux-Dateikontexts eine permanente -Regel für diesen Pfad einrichten, sodass beim Kopieren neuer Dateien und/oder Ersetzen vorhandener Dateien restorecon tatsächlich korrigiert wird das Problem, anstatt es zu brechen, wie es der Fall ist, wenn Sie nur chcon verwenden.

Führen Sie für ein symbolisch verknüpftes DocumentRoot-Objekt (geben Sie für dieses Beispiel den tatsächlichen vollständigen Pfad zum Verzeichnis als '/ media/myDoc' an) die folgenden beiden Befehle aus:

semanage fcontext -a -t httpd_sys_content_t "/media/myDoc(/.*)?"

restorecon -R /media/myDoc

Beachten Sie, dass der vollständige Pfad erforderlich ist, wenn Sie Semanage auf diese Weise verwenden. Sie werden das Problem nicht nur beheben, sondern es wird auch nicht mehr unterbrochen, wenn Sie in Zukunft restorecon (oder die automatische Neubenennung) ausführen.

0
Andrew

Umgebung: Linux - Root-Dateisystem auf einer SSD DocumentRoot auf einer Festplatte und über fstab eingehängt Neustarten von Apache2 nach dem Booten - kein Problem Es scheint ein Timing-Problem zu sein, dass Apache gestartet wird, bevor die fstab-Einstellungen abgeschlossen sind.

Problemumgehung: Definieren Sie das DocumentRoot-Verzeichnis im Root-Dateisystem mit dem richtigen Eigentümer, der richtigen Gruppe und den richtigen Berechtigungen. Das Verzeichnis ist möglicherweise leer.

0
G. C. Davis