Apache говорит, что DocumentRoot не существует, когда он существует

12

Я использовал Webmin для создания следующего виртуального хоста:

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

И при перезапуске Apache я получаю

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

Дело в том, что каталог абсолютно существует. Я смотрю прямо на это. pwdпоказывает мне, что это мой текущий каталог, и т. д. Это не так сложно, чтобы написать это правильно. Я не могу найти другие ошибки или предупреждения в журналах httpd. apache: apache владеет каталогом и всеми подкаталогами / файлами. Здесь нет никаких символических ссылок или чего-либо еще. Чего мне не хватает или на что еще мне посмотреть, чтобы определить, почему это так?

ОС CentOS 6.0

apache-2.2 centos Джейк Уилсон
источник
su для пользователя Apache и посмотрите, сможет ли он получить доступ к нему DocumentRoot, что может дать вам некоторое представление о том, что видит веб-сервер. Вы также можете проверить другие каталоги по пути, хотя, если он действительно под ними, /var/www/проблем не должно быть
voretaq7

Ответы:

8

Первое, что пришло мне на ум, - имеет ли Apache разрешение на доступ к этому каталогу?

Кроме того, это: /programming/3948038/apache-says-my-documentroot-directory-doesnt-exist

yrosen
источник
1
Как я уже сказал, да, каталог принадлежит apache:apache, однако я перешел по этой ссылке (то есть по SO по какой-то причине?), И действительно проблема была в SELinux. SELinux вызывает больше проблем, чем хорошо.
Джейк Уилсон
selinux поначалу раздражает, но если вы знаете команды для управления доступом, на самом деле это не так страшно. Это хороший инструмент для использования, когда вы привыкнете к нему.
Рилиндо
У меня была та же проблема (не существует в символической ссылке), и я setenforce 0исправил ее, но, глядя на разрешения ls-laZ, символическая ссылка имеет те же разрешения, что и другие файлы, к которым она может получить доступ, кроме chmod. Файлы -rw-r - r--, а символическая ссылка - lrwxrwxrwx. Может ли это быть причиной того, что он не работает с Setenforce 1?
TMH
@JakeWilson SELinux довольно разочаровывает, когда вы впервые к этому привыкли. Чем больше вы узнаете, как его использовать, я обещаю, что вы оцените его гораздо больше.
Спенсер Уильямс
16

Вот учебный подход к делу SELinux:

Узнайте, активен ли SELinux:

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

Если это так, некоторые сравнительные проверки могут помочь. Например, на сервере установлен DocumentRoot по умолчанию /var/www/html, но мы хотим, чтобы он был где-то еще, например /path/to/document/root.

Если SELinux не активно возится с ресурсом, ls -dZв каталоге будет показано что-то вроде:

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

С другой стороны, если применяются контексты SELinux, это ls -dZвыглядит примерно так:

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

Если мы сравним с рабочим DocumentRoot, это будет выглядеть примерно так:

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

_rИ _tотносятся к -r( --roleи -t( --type) аргументы chconВот сокращенная страницы человека.:

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

На первый взгляд может показаться, что следующее работает, но может и не работать.

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

Если веб-сервер по-прежнему не видит DocumentRoot, обратите внимание, что контекст имеет значение вплоть до корня:

$ 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

На этом этапе веб-сервер может видеть каталог.

Да, я научился трудному пути сегодня вечером.

ПРИМЕЧАНИЕ: использование chcon концептуально имеет недостаток в документации RedHat ( 5.6.1. Временные изменения: chcon ), которая гласит:

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.

Используйте semanage и restorecon для внесения более постоянных изменений. Краткий пример:

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

Что касается restorecon , обратите внимание, что -F требуется для воздействия на весь контекст (т. Е. На пользователя и тип). Кроме того, -R означает делать изменения рекурсивно. Аргументы -v или -p могут показывать прогресс как многословно, так и кратко. Используйте -FRnv, чтобы увидеть, что произойдет, без внесения каких-либо изменений.

После того, как semanage используется таким образом, можно просмотреть локальные изменения безопасности с помощью команды вроде:

$ sudo semanage export

Результаты экспорта semanage могут быть сохранены и использованы при импорте semanage, чтобы упростить применение набора изменений к различным системам.

ПРИМЕЧАНИЕ. Этот ответ предоставляет базовый контекст типа для сайта. Безопасность может быть гораздо более гранулированной. Например, посмотрите список типов, которые могут применяться к страницам веб-сервера, с помощью команды, например:

$ seinfo -t | grep http

ПРИМЕЧАНИЕ. Такие утилиты, как semanage и seinfo, могут быть не установлены по умолчанию. По крайней мере, в некоторых дистрибутивах требуемые пакеты могут быть названы примерно так:

policycoreutils-python
setools-console
kbulgrien
источник
Подробно, работает и экономит много времени - спасибо!
Северный мост
6

Это звучит как SELinux. Я бы посоветовал вам поработать с ним. Посмотрите в каталоге / var / log / audit для подтверждения.

В худшем случае вы всегда можете отключить selinux, как отмечалось ранее, но я предлагаю вам поработать с ним. Например, если бы я создал каталог для использования с Apache, у него не было бы правильного контекста, как отмечено здесь.

[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

Так что, если это произойдет, я просто применяю контекст из другого каталога, который в данном случае является 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
Rilindo
источник
0

Используйте эту команду в корне, чтобы изменить контекст безопасности «httpd_sys_content_t», который позволяет выполнять Apache.

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

Используйте ls -dZ /var/www/whateverдля просмотра сведений о ролях безопасности

user236790
источник