Apache diz DocumentRoot não existe quando isso acontece

Question

Eu 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, recebo

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

A coisa é, o diretório absolutamente existe. Estou olhando direto para isso. pwd me mostra que é meu diretório atual, etc. Não é tão difícil soletrar corretamente. Não consigo encontrar nenhum outro erro ou aviso nos logs do httpd. apache: o apache possui o diretório e todos os subdiretórios / arquivos. Não há nenhum link simbólico ou qualquer coisa envolvida aqui. O que eu estou perdendo ou o que mais devo olhar para determinar por que isso acontece?

o SO é o CentOS 6.0

    

Answer 1

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

Além disso, isso: link

    

Answer 2

Aqui está uma abordagem tutorial para o caso do 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, alguma verificação comparativa pode ajudar. Por exemplo, um servidor tem um DocumentRoot padrão em /var/www/html , mas queremos em outro lugar como /path/to/document/root .

Se o SELinux não estiver mexendo ativamente com o recurso, ls -dZ no 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, ls -dZ será mais 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 a um DocumentRoot funcional, 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 _r e _t estão relacionados aos argumentos -r ( --role e -t ( --type ) para chcon . Aqui está uma página de manual reduzida:

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

No começo, 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 puder ver o DocumentRoot, observe que o contexto é importante até o root:

$ 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, aprendi do jeito difícil hoje à noite.

NOTA: O uso de chcon conceitualmente tem uma desvantagem por documentação do RedHat (5.6.1 Mudanças 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 a restorecon , observe que -F é necessário para afetar todo o contexto (por exemplo, usuário e tipo). Além disso, -R significa fazer alterações recursivamente. Argumentos -v ou -p podem mostrar progresso em um modo detalhado ou conciso. Use -FRnv para ver o que aconteceria sem fazer nenhuma alteração.

Uma vez que semanage é usado desta forma, é possível visualizar as alterações de segurança locais com um comando como:

$ sudo semanage export

A saída de semanage export pode ser salva e usada por semanage import 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 a páginas do servidor da web com um comando como:

$ seinfo -t | grep http

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

policycoreutils-python
setools-console

    

Answer 3

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

Caso pior, você pode desligar o selinux, como mencionado anteriormente, mas sugiro que você trabalhe com ele. Por exemplo, se eu fosse criar um diretório para uso com o Apache, ele não teria o contexto correto, como 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, basta aplicar 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

    

Answer 4

Use esse comando na raiz para alterar o contexto de segurança de “httpd_sys_content_t”, que permite que o Apache seja executado.

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

Use ls -dZ /var/www/whatever para ver os detalhes das funções de segurança