Ошибка Nginx + Пассажир 403

У меня есть гибридное приложение php / Rails на одном сервере AWS ec2. Я размещаю установку Mediawiki и использую Rails в качестве внешнего интерфейса. Для приложения Rails я использую Passenger в качестве сервера. мне бы хотелось location / служить приложению Rails, и что угодно в location /w или любые файлы .php, которые будут обслуживаться Mediawiki (php5-fpm).

Раньше у меня была рабочая конфигурация, но она была взломана вместе, и я хотел бы ее изменить.

Моя текущая рабочая реализация выдает ошибку 403 Forbidden, когда я пытаюсь получить доступ к приложению Rails по адресу /,

Я получаю ошибку (от rails_error.log): 2017/10/24 20:08:31 [error] 14947#14947: *2 directory index of "/var/www/myapp/public/" is forbidden, client: xx.yy.zz.aa, server: myapp.amazonaws.com, request: "GET / HTTP/1.1", host: "myapp.amazonaws.com"

Я хотел бы иметь возможность получить доступ только приложение Rails в / теперь; Я пока не фокусируюсь на конфигурациях php5-fpm.

Вот мои файлы .conf:

сайты-доступны / myapp.conf:

fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=mw_cache:10m max_size=10g inactive=60m use_temp_path=off;
fastcgi_cache_key "$scheme$request_method$host$request_uri";

server {
listen 80;
listen [::]:80 ipv6only=on default_server;

server_name myapp.com;
charset utf-8;

location = /favicon.ico { access_log off; log_not_found off; }
location = /robots.txt  { access_log off; log_not_found off; }

root /var/www/myapp/public;
passenger_enabled on;

location /w {
alias /var/www/mediawiki-1.28.0;
index index.php index.html index.htm;
charset utf-8;

try_files $uri $uri/ /index.php?$query_string;
}

location ~ \.php$ {
fastcgi_cache mw_cache;
fastcgi_cache_valid 200 60m;
try_files $uri /index.php =404;
fastcgi_split_path_info ^(.+\.php)(/.+)$;
fastcgi_pass 127.0.0.1:7777;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;

error_log /var/log/nginx/mediawiki_error.log;
access_log /var/log/nginx/mediawiki_access.log;
}

error_log /var/log/nginx/rails_error.log;
access_log /var/log/nginx/rails_access.log;
}

nginx.conf:

user www-data;
worker_processes 4;
pid /run/nginx.pid;

events {
worker_connections 768;
# multi_accept on;
}

http {
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
types_hash_max_size 2048;

include /etc/nginx/mime.types;
default_type application/octet-stream;

access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;

gzip on;
gzip_disable "msie6";

passenger_root /home/ubuntu/.rvm/gems/ruby-2.3.1@myapp/gems/passenger-5.1.1;
passenger_ruby /home/ubuntu/.rvm/gems/ruby-2.3.1@myapp/wrappers/ruby;

include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
}

У меня есть подозрение, что это связано с тем, как установлен или запущен Passenger, или может быть, что я запускаю Passenger, а не как www-data но, как ubuntu,

/var/www/myapp/ также принадлежит Ubuntu, хотя я пытался chown -R www-data /var/www/myapp а также chown -R ubuntu:www-data /var/www/myapp но безрезультатно.

У кого-нибудь есть указатели отсюда?

Благодарю.

0

Решение

Ваш конфиг работает на меня: приложение запускается успешно, по крайней мере, если я запускаю Nginx от имени пользователя root (как это обычно делается).

Обратите внимание, что user Директива из вашей конфигурации сообщает Nginx, с каким пользователем запускать своих рабочих, она не указывает, с каким пользователем запускать ядро ​​Passenger (это унаследовано от того, с чего был запущен Nginx).

Мои указатели будут следующими:

  1. Обычно первое, что нужно сделать, это проверить логи.
    Ваша конфигурация объявляет файлы журнала, но не устанавливает журнал ошибок верхнего уровня, поэтому вы пропускаете вывод журнала Пассажира.

    Чтобы решить эту проблему, переместите error_log /var/log/nginx/error.log; выше http { линия в вашем nginx.conf,

    При необходимости вы также можете установить passenger_log_level 7;http блок), чтобы получить очень подробные журналы.

  2. Изменяя уровень журнала и наблюдая за результатом, вы также можете убедиться, что используемая конфигурация на самом деле используется для URL, который вы запрашиваете (т.е. вы можете видеть входящие запросы).

  3. Пассажир имеет несколько инструментов для устранения неполадок, например, passenger-status может использоваться для проверки, если он работает успешно. Обратите внимание, что вы не объявили passenger_pre_start url, так что ваше приложение не будет запущено Пассажиром, пока к нему не будет перенаправлен первый запрос.

1

Другие решения

Других решений пока нет …

По вопросам рекламы [email protected]