Apache twierdzi, że DocumentRoot nie istnieje

Użyłem Webmina do utworzenia następującego wirtualnego hosta:

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

A po ponownym uruchomieniu Apache dostaję

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

Chodzi o to, że katalog absolutnie NIE istnieje. Wpatruję się w to. pwdpokazuje mi, że to mój bieżący katalog itp. Nie jest tak trudno poprawnie to przeliterować. Nie mogę znaleźć żadnych innych błędów ani ostrzeżeń w dziennikach httpd. apache: apache jest właścicielem katalogu i wszystkich podkatalogów / plików. Nie ma tu żadnych dowiązań symbolicznych ani niczego związanego. Czego mi brakuje lub na co jeszcze powinienem spojrzeć, aby ustalić, dlaczego tak jest?

System operacyjny to CentOS 6.0

Pierwszą rzeczą, która przyszła mi do głowy, jest to, czy Apache ma uprawnienia dostępu do tego katalogu?

Ponadto: /programming/3948038/apache-says-my-documentroot-directory-doesnt-exist

Oto samouczek dotyczący przypadku SELinux:

Sprawdź, czy SELinux jest aktywny:

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

Jeśli tak, pomocne może być sprawdzenie porównawcze. Na przykład serwer ma domyślny DocumentRoot w /var/www/html, ale chcemy go gdzie indziej /path/to/document/root.

Jeśli SELinux nie aktywnie bawi się z zasobem, ls -dZw katalogu pojawi się coś takiego:

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

Z drugiej strony, jeśli zastosowane zostaną konteksty SELinux, ls -dZwygląda to bardziej jak:

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

Jeśli porównamy do działającego DocumentRoot, będzie to wyglądać mniej więcej tak:

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

Argumenty _ri _todnoszą się do -r( --rolei -t( --type)) chcon. Oto strona podręcznika:

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

Na pierwszy rzut oka może wydawać się, że poniższe działania działają, ale mogą nie.

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

Jeśli serwer WWW nadal nie widzi DocumentRoot, zauważ, że kontekst ma znaczenie aż do rootowania:

$ 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

W tym momencie serwer WWW może zobaczyć katalog.

Tak, nauczyłem się dziś trudnej drogi.

UWAGA: Zastosowanie chcon koncepcyjnie ma wadę w dokumentacji RedHat ( 5.6.1. Zmiany tymczasowe: chcon ), która stwierdza:

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.

Użyj semanage i restorecon, aby wprowadzić bardziej trwałe zmiany. Krótki przykład:

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

W odniesieniu do restorecon , zauważ, że -F jest wymagany, aby wpływać na cały kontekst (tj. Użytkownika i typ). Ponadto -R oznacza rekurencyjne wprowadzanie zmian. Argumenty -v lub -p mogą pokazywać postępy w sposób pełny lub zwięzły. Użyj -FRnv, aby zobaczyć, co się stanie, bez wprowadzania żadnych zmian.

Po użyciu semanage w ten sposób można wyświetlić lokalne zmiany bezpieczeństwa za pomocą polecenia:

$ sudo semanage export

Dane wyjściowe eksportu semanage mogą zostać zapisane i wykorzystane przez import semanage, aby ułatwić zastosowanie zestawu zmian w różnych systemach.

UWAGA: Ta odpowiedź zapewnia najbardziej podstawowy kontekst typu dla witryny. Bezpieczeństwo może być znacznie bardziej szczegółowe. Na przykład zobacz listę typów, które można zastosować do stron serwera WWW za pomocą polecenia:

$ seinfo -t | grep http

UWAGA: Narzędzia takie jak semanage i seinfo mogą nie być domyślnie instalowane. Przynajmniej w niektórych dystrybucjach wymagane pakiety mogą mieć takie nazwy:

policycoreutils-python
setools-console

Brzmi jak SELinux. Sugerowałbym, żebyś z nim pracował. Zajrzyj do katalogu / var / log / audit, aby potwierdzić.

Co gorsza, zawsze możesz wyłączyć selinux, jak wspomniano wcześniej, ale sugeruję, abyś zamiast niego pracował. Na przykład, jeśli utworzę katalog do użytku z Apache, nie będzie on miał odpowiedniego kontekstu, jak zaznaczono tutaj.

[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

Jeśli tak się stanie, po prostu zastosuję kontekst z innego katalogu, którym w tym przypadku jest 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

Użyj tego polecenia w katalogu głównym, aby zmienić kontekst zabezpieczeń „httpd_sys_content_t”, który pozwala na uruchomienie Apache.

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

Służy ls -dZ /var/www/whateverdo wyświetlania szczegółowych ról zabezpieczeń