O Apache diz que o DocumentRoot não existe quando existe

12

Usei o Webmin para criar o seguinte host virtual:

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

E ao reiniciar o Apache eu recebo

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

O fato é que o diretório EXISTE absolutamente. Estou olhando direto para ele. pwdmostra que esse é o meu diretório atual, etc. Não é tão difícil escrever isso direito. Não consigo encontrar outros erros ou avisos nos logs httpd. apache: o apache possui o diretório e todos os subdiretórios / arquivos. Não há links simbólicos ou qualquer coisa envolvida aqui. O que estou perdendo ou o que mais devo olhar para determinar por que isso acontece?

O SO é o CentOS 6.0

apache-2.2 centos Jake Wilson
fonte
su para o usuário do Apache e veja se ele pode acessá-lo DocumentRoot, isso pode lhe dar uma ideia do que o servidor da web está vendo. Você também pode querer verificar os outros diretórios ao longo do caminho, embora se é realmente sob /var/www/aqueles que não deve ser um problema
voretaq7

Respostas:

8

A primeira coisa que me veio à mente é que o Apache tem permissão para acessar esse diretório?

Além disso, este: /programming/3948038/apache-says-my-documentroot-directory-doesnt-exist

yrosen
fonte
1
Como eu disse, sim, o diretório pertence apache:apache, no entanto, segui esse link (que está no SO por algum motivo?) E, de fato, o SELinux era o problema. O SELinux causa mais problemas do que faz um bom imo.
21411 Jake Wilson
O selinux é irritante no começo, mas se você conhece os comandos para gerenciar o acesso, na verdade não é tão assustador. É uma boa ferramenta para usar quando você se acostumar.
Rilindo
Eu tive o mesmo problema (não existe em um link simbólico) e a execução foi setenforce 0corrigida, mas, olhando as permissões ls-laZ, o link simbólico tem as mesmas permissões que outros arquivos que ele pode acessar, além do chmod. Os arquivos são -rw-r - r-- e o link simbólico é lrwxrwxrwx. Poderia ser esse o motivo pelo qual não funciona com o setenforce 1?
TMH 21/07
@JakeWilson O SELinux é bastante frustrante quando você está se acostumando. Quanto mais você aprender a usá-lo, prometo que o apreciará muito mais.
Spencer Williams
16

Aqui está uma abordagem tutorial do caso SELinux:

Descubra se o SELinux está ativo:

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

Nesse caso, algumas verificações comparativas podem ajudar. Por exemplo, um servidor tem um DocumentRoot padrão em /var/www/html, mas queremos em outro lugar /path/to/document/root.

Se o SELinux não estiver mexendo ativamente com o recurso, ls -dZo diretório mostrará algo como:

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

Por outro lado, se os contextos do SELinux forem aplicados, será ls -dZmais parecido com:

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

Se compararmos com um DocumentRoot de trabalho, seria algo como:

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

Os argumentos _rand _trelacionam-se aos -r( --rolee -t( --type) aos chcon. Aqui está uma página de manual cortada:

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

À primeira vista, o seguinte pode parecer funcionar, mas pode não funcionar.

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

Se o servidor da Web ainda não conseguir ver o DocumentRoot, observe que o contexto importa desde o início até a raiz:

$ 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

Neste ponto, o servidor da web pode ver o diretório.

Sim, eu aprendi da maneira mais difícil hoje à noite.

NOTA: O uso do chcon conceitualmente tem uma desvantagem conforme a documentação do RedHat ( 5.6.1. Alterações temporárias: chcon ) que afirma:

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.

Use semanage e restorecon para fazer mudanças mais permanentes. Um breve exemplo:

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

Com relação ao restorecon , observe que -F é necessário para afetar todo o contexto (isto é, usuário e tipo). Além disso, -R significa fazer alterações recursivamente. Os argumentos -v ou -p podem mostrar o progresso de maneira detalhada ou concisa. Use -FRnv para ver o que aconteceria sem realmente fazer alterações.

Depois que a semântica é usada dessa maneira, é possível visualizar as alterações de segurança local com um comando como:

$ sudo semanage export

A saída da exportação de semânticas pode ser salva e usada pela importação de semânticas para facilitar a aplicação de um conjunto de alterações em vários sistemas.

NOTA: Esta resposta fornece um contexto de tipo mais básico para um site. A segurança pode ser muito mais granular. Por exemplo, veja uma lista de tipos que podem ser aplicados às páginas do servidor da web com um comando como:

$ seinfo -t | grep http

NOTA: Utilitários como semanage e Seinfo não pode ser instalado por padrão. Pelo menos em algumas distribuições, os pacotes necessários podem ter o seguinte nome:

policycoreutils-python
setools-console
Kbulgrien
fonte
Detalhado, funciona e economiza muito tempo - obrigado!
NorthBridge 15/08/14
6

Parece o SELinux. Sugiro que você trabalhe com ele. Procure no diretório / var / log / audit para confirmar.

Na pior das hipóteses, você sempre pode desativar o selinux, conforme observado anteriormente, mas sugiro que você trabalhe com ele. Por exemplo, se eu criar um diretório para uso com o Apache, ele não terá o contexto correto, conforme observado aqui.

[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

Então, se isso acontecer, eu apenas aplico o contexto de outro diretório, que neste caso, é 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
fonte
0

Use este comando no root para alterar o contexto de segurança de "httpd_sys_content_t", que permite a execução do Apache.

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

Use ls -dZ /var/www/whateverpara visualizar os detalhes das funções de segurança

user236790
fonte