Apache dice que DocumentRoot no existe cuando existe

12

Usé Webmin para crear el siguiente host virtual:

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

Y cuando reinicio Apache me sale

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

La cuestión es que el directorio existe. Lo estoy mirando fijamente. pwdme muestra que es mi directorio actual, etc. No es tan difícil deletrearlo bien. No puedo encontrar ningún otro error o advertencia en los registros de httpd. apache: apache posee el directorio y todos los subdirectorios / archivos. No hay enlaces simbólicos ni nada involucrado aquí. ¿Qué me estoy perdiendo o qué más debo mirar para determinar por qué es esto?

El sistema operativo es CentOS 6.0

apache-2.2 centos Jake Wilson
fuente

Su para el usuario de Apache y ver si puede acceder al DocumentRoot, que podría darle una idea de lo que está viendo el servidor web. También es posible que desee verificar los otros directorios a lo largo de la ruta, aunque si realmente está debajo de /var/www/ellos no debería ser un problema

voretaq7

8

Lo primero que me vino a la mente es ¿Apache tiene permiso para acceder a ese directorio?

Además, esto: /programming/3948038/apache-says-my-documentroot-directory-doesnt-exist

Yrosen
fuente

1

Como dije, sí, el directorio es propiedad apache:apache, sin embargo, seguí ese enlace (¿está en SO por alguna razón?) Y de hecho SELinux fue el problema. SELinux causa más problemas que hace bien a la OMI.

Jake Wilson

al principio, selinux es molesto, pero si conoce los comandos para administrar el acceso, en realidad no es tan desalentador. Es una buena herramienta para usar una vez que te acostumbras.

Rilindo

Tuve el mismo problema (no existe en un enlace simbólico), y al ejecutarlo lo setenforce 0solucioné, pero mirando los permisos ls-laZ, el enlace simbólico tiene los mismos permisos que otros archivos a los que puede acceder, aparte de chmod. Los archivos son -rw-r - r--, y el enlace simbólico es lrwxrwxrwx. ¿Podría ser esa la razón por la que no funciona con setenforce 1?

TMH

@JakeWilson SELinux es bastante frustrante cuando te acostumbras por primera vez. Cuanto más aprenda a usarlo, le prometo que lo apreciará mucho más.

Spencer Williams

16

Aquí hay un enfoque tutorial para el caso de SELinux:

Averigüe si SELinux está activo:

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

Si es así, algunas comprobaciones comparativas podrían ayudar. Por ejemplo, un servidor tiene un DocumentRoot predeterminado en /var/www/html, pero lo queremos en otro lugar como /path/to/document/root.

Si SELinux no está jugando activamente con el recurso, ls -dZen el directorio se mostrará algo como:

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

Por otro lado, si se aplican los contextos SELinux, se ls -dZparece más a:

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

Si lo comparamos con un DocumentRoot en funcionamiento, se vería algo así:

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

El _ry se _trelacionan con -r( --roley -t( --type) argumentos parachcon . Aquí hay una página de manual reducida:

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

A primera vista, lo siguiente puede parecer que funciona, pero puede que no.

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

Si el servidor web todavía no puede ver DocumentRoot, tenga en cuenta que el contexto es importante desde la raíz:

$ 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

En este punto, el servidor web puede ver el directorio.

Sí, aprendí por las malas esta noche.

NOTA: El uso conceptual de chcon tiene una desventaja según la documentación de RedHat ( 5.6.1. Cambios temporales: chcon ) que establece:

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 y restorecon para hacer cambios más permanentes. Un breve ejemplo:

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

Con respecto a restorecon , tenga en cuenta que -F es necesario para afectar todo el contexto (es decir, usuario y tipo). Además, -R significa hacer cambios de forma recursiva. Los argumentos -v o -p pueden mostrar el progreso de manera detallada o concisa. Utilice -FRnv para ver qué sucedería sin hacer ningún cambio.

Una vez que se utiliza semanage de esta manera, es posible ver los cambios de seguridad local con un comando como:

$ sudo semanage export

El resultado de la exportación de semanage se puede guardar y utilizar mediante la importación de semanage para facilitar la aplicación de un conjunto de cambios a varios sistemas.

NOTA: Esta respuesta proporciona un contexto de tipo más básico para un sitio. La seguridad puede ser mucho más granular. Por ejemplo, vea una lista de tipos que se pueden aplicar a las páginas del servidor web con un comando como:

$ seinfo -t | grep http

NOTA: Las utilidades como semanage y seinfo pueden no estar instaladas por defecto. Al menos en algunas distribuciones, los paquetes requeridos pueden llamarse así:

policycoreutils-python
setools-console

kbulgrien
fuente

Detallado, funciona y ahorra mucho tiempo, ¡gracias!

NorthBridge

6

Suena como SELinux. Te sugiero que trabajes con él. Mire en el directorio / var / log / audit para confirmar.

En el peor de los casos, siempre puede desactivar selinux, como se señaló anteriormente, pero le sugiero que trabaje con él. Por ejemplo, si tuviera que crear un directorio para usar con Apache, no tendría el contexto correcto, como se señala aquí.

[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

Entonces, si eso sucede, simplemente aplico el contexto desde otro directorio, que en este caso es 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
fuente

0

Use este comando en la raíz para cambiar el contexto de seguridad de "httpd_sys_content_t" que permite que Apache se ejecute.

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

Use ls -dZ /var/www/whateverpara ver los roles de seguridad de detalles

user236790
fuente

Apache dice que DocumentRoot no existe cuando existe

Respuestas: