web-dev-qa-db-fra.com

nginx - Impossible d'ouvrir le script principal

J'ai un message d'erreur:

FastCGI sent in stderr: "Unable to open primary script: /home/messi/web/wordpress/index.php (No such file or directory)" while reading response header from upstream, client: xxx.xxx.xxx.xxx, server: www.domain.com, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", Host: "www.domain.com

here are my configuration files:

/ etc/php5/fpm/php.ini

cgi.fix_pathinfo=0
doc_root =
user_dir =
....

/ etc/php5/fpm/php-fpm.conf

[global]
pid = /var/run/php5-fpm.pid
error_log = /var/log/php5-fpm.log
include=/etc/php5/fpm/pool.d/*.conf

/ etc/php5/fpm/pool.d/www.conf

[www]
user = www-data
group = www-data
listen = /var/run/php5-fpm.sock
listen.owner = www-data
listen.group = www-data
listen.mode = 0666
pm = dynamic
pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3
chdir = /
security.limit_extensions = .php .php3 .php4 .php5
php_flag[display_errors] = on
php_admin_value[error_log] = /var/log/fpm-php.www.log
php_admin_flag[log_errors] = on

/ etc/nginx/nginx.conf

user  nginx;
worker_processes  1;
error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;
events {
    worker_connections  1024;
}
http {
    include       /etc/nginx/mime.types;
    server_tokens off;
    default_type  application/octet-stream;
    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';
    access_log  /var/log/nginx/access.log  main;
    sendfile        on;
    #tcp_nopush     on;
    keepalive_timeout  65;
    #gzip  on;
    include /etc/nginx/sites-enabled/*;
}

/ etc/nginx/sites-enabled/wordpress

server {
    listen   80;
    server_name www.domain.com;
    root /home/messi/web/wordpress;
    error_log /var/log/nginx/err.wordpress.log;
    index index.php;
    location / {
        try_files $uri $uri/ /index.php?$args;
    }
    location = /favicon.ico {
        log_not_found off;
        access_log off;
    }
    location = /robots.txt {
        allow all;
        log_not_found off;
        access_log off;
    }
    location ~ /\. {
        deny all;
    }
    location ~* /(?:uploads|files)/.*\.php$ {
        deny all;
    }
    location ~ \.php$ {
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
            fastcgi_pass unix:/var/run/php5-fpm.sock;
            fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            include /etc/nginx/fastcgi_params;
    }
}

Configuration de l'autorisation utilisateur:

#adduser www-data messi
#chown -R www-data:www-data /home/messi/web
#chmod -R 664 /home/messi/web/wordpress

Comment puis-je résoudre ça? Merci

phpwordpressnginx
20
user3145965

SELinux provoquera cette erreur sur CentOS/RHEL 7+ par défaut :(

Pour tester si SELinux est la source de vos malheurs, faites

setenforce 0

... et voir si tout fonctionne. Si cela le corrige, vous pouvez laisser SELinux désactivé (faible, vous êtes meilleur que cela), ou vous pouvez le réactiver avec

setenforce 1

... puis corrigez correctement le problème.

Si tu fais

tail -f /var/log/audit/audit.log

... vous verrez le problème SELinux. Dans mon cas, il refusait l'accès PHP-FPM aux fichiers Web. Vous pouvez exécuter les directives suivantes pour le corriger:

setsebool -P httpd_can_network_connect_db 1
setsebool -P httpd_can_network_connect 1

En fait, cela ne m'a pas résolu au début, mais la restauration du contexte SELinux l'a fait

restorecon -R -v /var/www

J'espère que cela pourra aider.

34
siliconrockstar

Il s'agit probablement d'un problème d'autorisations.

  1. Assurez-vous que chaque répertoire parent possède des autorisations + x pour l'utilisateur (l'utilisateur nginx et/ou l'utilisateur php-fpm).

    Vous pouvez vérifier ces autorisations avec: namei -om /path/to/file.

  2. Si vous avez des liens symboliques, assurez-vous qu'ils pointent vers un chemin valide.

  3. Assurez-vous que les chroots ont accès aux bons chemins.

  4. Assurez-vous que SELinux (par exemple Fedora/Centos) ou AppArmor (par exemple Ubuntu) ou tout autre système de sécurité MAC n'interfèrent pas avec l'accès aux fichiers.

    Pour SeLinux: vérifiez /var/log/audit/audit.log ou/var/log/messages

    Pour AppArmor: Je ne suis pas un utilisateur d'Ubuntu et pour autant que je sache, la journalisation pour AppArmor n'est pas toujours facile à comprendre. Vous pouvez vérifier ici pour plus d'informations: http://ubuntuforums.org/showthread.php?t=1733231

7
ethanpil

C'était SELinux dans mon cas également. J'ai lu une documentation trouvée ici:

https://wiki.centos.org/HowTos/SELinux
https://linux.die.net/man/1/chcon

et a fini avec la commande:

chcon -R -v --type=httpd_sys_content_t html/

.... cela a changé le contexte des fichiers au type httpd qui est ce que mon serveur web (Nginx) fonctionnait comme.

Vous pouvez trouver dans quel contexte votre serveur Web s'exécute en utilisant:

ps axZ | grep nginx

.... qui dans mon cas m'a donné:

system_u:system_r:**httpd_t**:s0      6246 ?        Ss     0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
system_u:system_r:**httpd_t**:s0      6249 ?        S      0:00 nginx: worker process

Voyant le contexte du service en cours d'exécution était httpd_t J'ai changé le contexte du dossier racine de mon site Web en celui (récursivement)

Le but de SELinux est de permettre uniquement aux services et processus d'accéder aux fichiers du même type qu'eux. Étant donné que le serveur Web s'exécutait en tant que httpd_t, il était logique de définir le même contexte que les fichiers/dossiers du site.

Soit dit en passant, je suis nouveau dans ce domaine ... Mais cela semblait être la meilleure approche pour moi. Il a gardé SELinux activé, n'a pas diminué la sécurité de ce qu'il fait, et n'a pas fait correspondre le contexte des fichiers avec le processus/service.

2
Zack A