Apache sagt, dass DocumentRoot nicht existiert, wenn es existiert

Ich habe mit Webmin den folgenden virtuellen Host erstellt:

<VirtualHost *:80>
        DocumentRoot "/var/www/whatever"
        ServerName whatever.ourdomain
        <Directory "/var/www/whatever">
                allow from all
                Options +Indexes
        </Directory>
</VirtualHost>

Und beim Neustart von Apache bekomme ich

Starting httpd: Warning: DocumentRoot [/var/www/whatever] does not exist

Die Sache ist, das Verzeichnis existiert absolut. Ich starre genau hin. pwdzeigt mir, dass dies mein aktuelles Verzeichnis ist usw. Es ist nicht so schwer, es richtig zu buchstabieren. Ich kann keine anderen Fehler oder Warnungen in den httpd-Protokollen finden. apache: apache besitzt das Verzeichnis und alle Unterverzeichnisse / Dateien. Hier sind keine Symlinks oder irgendetwas involviert. Was fehlt mir oder worauf sollte ich noch achten, um festzustellen, warum das so ist?

Betriebssystem ist CentOS 6.0

Das erste, was mir in den Sinn kam, ist, dass Apache die Berechtigung hat, auf dieses Verzeichnis zuzugreifen.

Außerdem: /programming/3948038/apache-says-my-documentroot-directory-doesnt-exist

Hier ist ein Tutorial-Ansatz für den SELinux-Fall:

Finden Sie heraus, ob SELinux aktiv ist:

 $ sestatus
 SELinux status:                 enabled
 SELinuxfs mount:                /selinux
 Current mode:                   enforcing
 Mode from config file:          enforcing
 Policy version:                 24
 Policy from config file:        targeted

In diesem Fall kann eine vergleichende Überprüfung hilfreich sein. Zum Beispiel hat ein Server einen Standard-DocumentRoot unter /var/www/html, aber wir möchten ihn woanders haben /path/to/document/root.

Wenn SELinux nicht aktiv mit der Ressource kommuniziert, wird ls -dZim Verzeichnis Folgendes angezeigt:

$ ls -dZ /path/to/document/root
? /path/to/document/root/

Wenn SELinux-Kontexte angewendet werden, ls -dZsieht dies eher so aus:

$ ls -dZ /path/to/document/root
drwxrws--x+ cfgadm cfgadmin system_u:object_r:file_t:s0 /path/to/document/root

Wenn wir es mit einem funktionierenden DocumentRoot vergleichen, würde es ungefähr so ​​aussehen:

$ ls -dZ /var/www/html
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 /var/www/html

Die Argumente _rund _tbeziehen sich auf -r( --roleund -t( --type) auf chcon. Hier ist eine reduzierte Manpage:

NAME
   chcon - change file security context

SYNOPSIS
   chcon [OPTION]... CONTEXT FILE...
   chcon [OPTION]... [-u USER] [-r ROLE] [-l RANGE] [-t TYPE] FILE...
   chcon [OPTION]... --reference=RFILE FILE...

DESCRIPTION
   Change the security context of each FILE to CONTEXT.  With --reference,
   change the security context of each FILE to that of RFILE.

   --reference=RFILE
          use RFILE's security context rather than  specifying a CONTEXT value

   -R, --recursive
          operate on files and directories recursively

Auf den ersten Blick scheint das Folgende zu funktionieren, aber möglicherweise nicht.

$ sudo chcon -R -t httpd_sys_content_t /path/to/document/root

Wenn der Webserver den DocumentRoot weiterhin nicht sehen kann, beachten Sie, dass der Kontext bis zum Root-Verzeichnis von Bedeutung ist:

$ sudo chcon -R -t httpd_sys_content_t /path/to/document
$ sudo chcon -R -t httpd_sys_content_t /path/to
$ sudo chcon -R -t httpd_sys_content_t /path

Zu diesem Zeitpunkt kann der Webserver das Verzeichnis sehen.

Ja, ich habe heute Abend auf die harte Tour gelernt.

HINWEIS: Die konzeptionelle Verwendung von chcon hat laut RedHat-Dokumentation ( 5.6.1. Temporäre Änderungen: chcon ) folgende Nachteile :

The chcon command changes the SELinux context for files. However, changes
made with the chcon command do not survive a file system relabel, or the
execution of the restorecon command.

Verwenden Sie semanage und restorecon , um dauerhaftere Änderungen vorzunehmen. Ein kurzes Beispiel:

 $ sudo semanage fcontext --add -t httpd_sys_content_t -s system_u \
     "/path/to/document/root(/.*)?"
 $ sudo restorecon -FR /path/to/document/root

Beachten Sie in Bezug auf restorecon , dass -F erforderlich ist, um den gesamten Kontext (dh Benutzer und Typ) zu beeinflussen. Auch -R Mittel , um Änderungen rekursiv zu machen. Die Argumente -v oder -p können den Fortschritt entweder ausführlich oder knapp anzeigen. Verwenden Sie -FRnv, um zu sehen, was passieren würde, ohne Änderungen vorzunehmen.

Sobald semanage auf diese Weise verwendet wird, können lokale Sicherheitsänderungen mit einem Befehl wie dem folgenden angezeigt werden :

$ sudo semanage export

Die Ausgabe des Semanage-Exports kann gespeichert und vom Semanage-Import verwendet werden, um das Anwenden einer Reihe von Änderungen auf verschiedene Systeme zu vereinfachen.

HINWEIS: Diese Antwort bietet einen grundlegendsten Typkontext für eine Site. Sicherheit kann viel detaillierter sein. Eine Liste der Typen, die auf Webserverseiten angewendet werden können, finden Sie beispielsweise mit folgenden Befehlen:

$ seinfo -t | grep http

HINWEIS: Dienstprogramme wie semanage und seinfo werden möglicherweise nicht standardmäßig installiert. Zumindest bei einigen Distributionen können erforderliche Pakete wie folgt benannt werden:

policycoreutils-python
setools-console

Es klingt wie SELinux. Ich würde vorschlagen, dass Sie damit arbeiten. Suchen Sie im Verzeichnis / var / log / audit nach einer Bestätigung.

Schlimmer noch, Sie können Selinux immer ausschalten, wie bereits erwähnt, aber ich schlage vor, Sie arbeiten stattdessen damit. Wenn ich zum Beispiel ein Verzeichnis zur Verwendung mit Apache erstellen würde, hätte es nicht den richtigen Kontext, wie hier angegeben.

[root@amp23140 www]# ls -Z
drwxr-xr-x. root root system_u:object_r:httpd_sys_script_exec_t:s0 cgi-bin
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 error
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 html
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 icons
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_content_t:s0 whatever

In diesem Fall wende ich einfach den Kontext aus einem anderen Verzeichnis an, in diesem Fall HTML:

[root@amp23140 www]# chcon whatever --reference=html
[root@amp23140 www]# ls -lZ
drwxr-xr-x. root root system_u:object_r:httpd_sys_script_exec_t:s0 cgi-bin
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 error
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 html
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 icons
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 whatever

Verwenden Sie diesen Befehl in root, um den Sicherheitskontext von "httpd_sys_content_t" zu ändern, der die Ausführung von Apache ermöglicht.

chcon -R -h -t httpd_sys_content_t /var/www/whatever

Hiermit können Sie ls -dZ /var/www/whateverdie Details der Sicherheitsrollen anzeigen