Apache ne suivra pas les liens symboliques (403 interdit)
J'ai quelques difficultés à configurer Apache sur Ubuntu. J'ai suivi ce guide .
# /usr/sbin/Apache2 -v
Server version: Apache/2.2.17 (Ubuntu)
Server built: Feb 22 2011 18:33:02
Mon répertoire public,/var/www, peut avec succès servir et exécuter PHP les pages qui y sont placées. Cependant, je souhaite créer un lien symbolique dans/var/www qui pointe vers un répertoire dans mon dossier personnel et servir des pages là-bas.
[root /var/www]# ll
total 36
drwxr-xr-x 3 root root 4096 2011-09-11 14:22 .
drwxr-xr-x 14 root root 4096 2011-06-04 22:49 ..
lrwxrwxrwx 1 root root 16 2011-09-11 13:21 about -> /root/site/about
Lorsque j'essaie d'accéder à/sur le navigateur, je reçois
Forbidden
You don't have permission to access /about on this server.
Autant que je sache, j'ai accordé suffisamment de privilèges aux fichiers que je veux servir:
[root ~/site/about]# ll
total 24
drwxr-xr-x 5 root root 4096 2011-09-11 13:20 .
drwxr--r-- 3 root root 4096 2011-09-11 13:19 ..
drwxr-xr-x 2 root root 4096 2011-09-11 13:21 contact
-rwxr-xr-x 1 root root 1090 2011-09-11 13:19 index.php
drwxr-xr-x 2 root root 4096 2011-09-11 13:20 me
drwxr-xr-x 2 root root 4096 2011-09-11 13:21 resume
Je connais l'option FollowSymLinks et je pense qu'elle est définie dans mon fichier/etc/Apache2/sites-enabled/000-default:
DocumentRoot /var/www
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>
<Directory /var/www/>
Options FollowSymLinks Indexes MultiViews
AllowOverride None
Order allow,deny
allow from all
</Directory>
Une idée de ce que je pourrais manquer?
Vérifiez que Apache a les droits d’exécution pour /root, /root/site et /root/site/about.
Courir:
chmod o+x /root /root/site /root/site/about
L'erreur 403 peut également être provoquée par un système de fichiers crypté, par ex. un lien symbolique vers un dossier personnel crypté .
Si votre lien symbolique pointe vers le dossier chiffré, l'utilisateur Apache (par exemple, www-data) ne peut pas accéder au contenu, même si les autorisations Apache et fichier/dossier sont définies correctement. L’accès de l’utilisateur www-data peut être testé avec un tel appel:
Sudo -u www-data ls -l /var/www/html/<your symlink>/
Il existe des solutions de contournement/solutions à cela, par exemple ajouter l'utilisateur www-data à votre groupe privé (expose les données cryptées à l'internaute) ou en configurant un dossier rsynced non crypté (probablement plutôt sécurisé). Pour ma part, je rechercherai probablement une solution rsync pendant le développement.
https://askubuntu.com/questions/633625/public-folder-in-an-encrypted-home-directory
Un outil pratique pour mes besoins est lsyncd. Cela me permet de travailler directement dans mon dossier personnel chiffré et de voir les modifications presque instantanément dans la page Web Apache. La synchronisation est déclenchée par des modifications dans le système de fichiers, appelant un rsync. Comme je ne travaille que sur des pages Web et des scripts relativement petits, la synchronisation est très rapide. J'ai décidé d'utiliser un court délai de 1 seconde avant le démarrage de rsync, même s'il est possible de définir un délai de 0 secondes.
Installation de lsyncd (sous Ubuntu):
Sudo apt-get install lsyncd
Démarrage du service en arrière-plan:
lsyncd -delay 1 -rsync /home/<me>/<work folder>/ /var/www/html/<web folder>/
J'avais un problème similaire que je n'ai pas pu résoudre pendant longtemps sur mon nouveau serveur. Outre la réponse de palacsint, une bonne question à poser est la suivante: utilisez-vous Apache 2.4? Dans Apache 2.4, il existe un mécanisme différent pour définir les autorisations qui ne fonctionnent pas lorsque vous avez terminé avec la configuration ci-dessus. J'ai donc utilisé le solution expliquée dans cet article de blog .
En gros, je devais convertir mon fichier de configuration à partir de:
Alias /demo /usr/demo/html
<Directory "/usr/demo/html">
Options FollowSymLinks
AllowOverride None
Order allow,deny
allow from all
</Directory>
à:
Alias /demo /usr/demo/html
<Directory "/usr/demo/html">
Options FollowSymLinks
AllowOverride None
Require all granted
</Directory>
Notez comment les lignes Order et permettent ont été remplacées par Exiger que tous soient accordés
En lien avec cette question, je viens de comprendre pourquoi mon vhost me donnait ce 403.
J'avais testé TOUTES les possibilités sur cette question et d'autres sans chance. Cela me rend presque fou.
Je suis en train de configurer un serveur avec un déploiement de versions similaire à Capistrano via des liens symboliques et lorsque j'ai essayé d'accéder au dossier DocRoot (qui est maintenant un lien symbolique vers le dossier de la version actuelle), il m'a donné le fichier 403.
Mon vhost est:
DocumentRoot /var/www/site.com/html
<Directory /var/www/site.com/html>
AllowOverride All
Options +FollowSymLinks
Require all granted
</Directory>
et mon fichier principal httpd.conf était (installation par défaut d’Apache 2.4):
DocumentRoot "/var/www"
<Directory "/var/www">
Options -Indexes -FollowSymLinks -Includes
(...)
Il s’avère que la définition principale d’Options prenait le pas sur mon domaine vhosts (pour moi, il est contre-intuitif). Donc je l'ai changé pour:
DocumentRoot "/var/www"
<Directory "/var/www">
Options -Indexes +FollowSymLinks -Includes
(...)
et Eureka! (notez le signe plus avant FollowSymLinks dans le fichier MAIN httpd.conf. J'espère que cela aidera une autre âme perdue.
Commencez par désactiver selinux (vim/etc/selinux/config)
vim /etc/httpd/conf/httpd.conf modifie les lignes suivantes pour les liens symboliques et l'indexation de répertoires:
documentroot /var/www/html
<directory /var/www/html>
Options Indexes FollowSymLinks
AllowOverride None
</directory>
Si le fichier .htaccess, alors AllowOverride all
Les liens symboliques peuvent vous faire défaut d'une autre manière, comme je l'ai découvert dans ma situation. Si vous utilisez un système SELinux en tant que serveur et que les liens symboliques pointent vers un dossier monté sur NFS (d'autres systèmes de fichiers peuvent générer des symptômes similaires), httpd risque de voir les contextes incorrects et de refuser de diffuser le contenu de la cible. Dossiers.
Dans mon cas, le contexte SELinux de /var/www/html _ (que vous pouvez obtenir avec ls -Z) est unconfined_u:object_r:httpd_sys_content_t:s0. Les liens symboliques dans /var/www/html aura le même contexte, mais le contexte de leur cible, étant un dossier monté sur NFS, est system_u:object_r:nfs_t:s0.
La solution consiste à ajouter fscontext=unconfined_u:object_r:httpd_sys_content_t:s0 aux options mount (par exemple, # mount -t nfs -o v3,fscontext=unconfined_u:object_r:httpd_sys_content_t:s0 <IP address>:/<server path> /<mount point>). rootcontext n'est pas pertinent et defcontext est rejeté par NFS. Je n'ai pas essayé context seul.
Pour toute personne ayant des problèmes après la mise à niveau vers la version 14.04 https://askubuntu.com/questions/452042/why-is-my-Apache-not-working-after-upgrading-to-ubuntu-14-04 en tant que root modifié avant la mise à niveau =/var/www après la mise à niveau =/var/www/html