Apache dit que DocumentRoot n'existe pas quand il existe

J'ai utilisé Webmin pour créer l'hôte virtuel suivant:

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

Et lors du redémarrage d'Apache, j'obtiens

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

Le fait est que le répertoire existe absolument. Je le regarde droit dans les yeux. pwdme montre que c'est mon répertoire actuel, etc. Ce n'est pas si difficile de l'orthographier correctement. Je ne trouve aucune autre erreur ou avertissement dans les journaux httpd. apache: apache est propriétaire du répertoire et de tous les sous-répertoires / fichiers. Il n'y a aucun lien symbolique ou quoi que ce soit impliqué ici. Que manque-t-il ou que dois-je regarder pour déterminer pourquoi?

Le système d'exploitation est CentOS 6.0

La première chose qui m'est venue à l'esprit est qu'Apache a-t-il la permission d'accéder à ce répertoire?

En outre, ceci: /programming/3948038/apache-says-my-documentroot-directory-doesnt-exist

Voici une approche didactique du cas SELinux:

Découvrez si SELinux est actif:

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

Dans l'affirmative, une vérification comparative pourrait être utile. Par exemple, un serveur a un DocumentRoot par défaut sur /var/www/html, mais nous le voulons ailleurs comme /path/to/document/root.

Si SELinux ne joue pas activement avec la ressource, ls -dZle répertoire affichera quelque chose comme:

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

En revanche, si des contextes SELinux sont appliqués, cela ls -dZressemble plus à:

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

Si nous comparons à un DocumentRoot fonctionnel, cela ressemblerait à quelque chose comme:

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

Les arguments _ret se _trapportent à -r( --roleet -t( --type) à chcon. Voici une page de manuel réduite:

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

À première vue, les éléments suivants peuvent sembler fonctionner, mais peuvent ne pas fonctionner.

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

Si le serveur Web ne peut toujours pas voir le DocumentRoot, notez que le contexte est important jusqu'à la racine:

$ 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

À ce stade, le serveur Web peut voir le répertoire.

Oui, j'ai appris à la dure ce soir.

REMARQUE: L'utilisation de chcon a conceptuellement un inconvénient selon la documentation RedHat ( 5.6.1. Modifications temporaires: chcon ) qui stipule:

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.

Utilisez semanage et restorecon pour apporter des modifications plus permanentes. Un bref exemple:

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

En ce qui concerne la restauration , notez que -F est requis pour affecter l'ensemble du contexte (c'est-à-dire l'utilisateur et le type). De plus, -R signifie apporter des modifications récursivement. Les arguments -v ou -p peuvent montrer la progression de façon verbeuse ou laconique. Utilisez -FRnv pour voir ce qui se passerait sans apporter de modifications.

Une fois le semanage utilisé de cette manière, il est possible de visualiser les modifications de sécurité locales avec une commande comme:

$ sudo semanage export

La sortie de l' exportation de semanage peut être enregistrée et utilisée par l' importation de semanage pour faciliter l'application d'un ensemble de modifications à divers systèmes.

REMARQUE: cette réponse fournit le contexte de type le plus basique pour un site. La sécurité peut être beaucoup plus granulaire. Par exemple, consultez une liste de types pouvant s'appliquer aux pages de serveur Web avec une commande comme:

$ seinfo -t | grep http

REMARQUE: les utilitaires tels que semanage et seinfo peuvent ne pas être installés par défaut. Au moins sur certaines distributions, les packages requis peuvent être nommés quelque chose comme ceci:

policycoreutils-python
setools-console

Cela ressemble à SELinux, je vous suggère de travailler avec. Regardez dans le répertoire / var / log / audit pour confirmer.

Pire cas, vous pouvez toujours désactiver selinux, comme indiqué précédemment, mais je vous suggère de travailler avec lui à la place. Par exemple, si je devais créer un répertoire à utiliser avec Apache, il n'aura pas le bon contexte, comme indiqué ici.

[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

Donc, si cela se produit, j'applique simplement le contexte d'un autre répertoire, qui dans ce cas, est 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

Utilisez cette commande en racine pour changer le contexte de sécurité de "httpd_sys_content_t" qui permet à Apache de s'exécuter.

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

Utilisez ls -dZ /var/www/whateverpour afficher les détails des rôles de sécurité