nginx не открывает php
Подскажите пожалуйста, в чем может быть проблема.
Ubuntu Server 18.04
Установил Nginx 1.14 и PHP 7.2 FPM
php.ini стандартный
Поменял в нем только вот это
cgi.fix_pathinfo=0 (было 1)
Его я не трогал тоже, стандартный.
Конфиг www.conf тоже стандартный
В директории сайта все папки и файлы выставил владельца www-data, до этого был root
В чем может быть проблема, что я не доконфигурировал?
Естественно я каждый раз при изменении конфигов перезагружал и nginx и php-fpm
systemctl restart nginx && systemctl restart php7.2-fpm
Попробуйте такой конф:
Вчера уже не получилось проверить, вот сейчас проверил.
Потом еще раз глянул в конфиг и обнаружил что когда на тостер закидывал конфиг я домен подменил на site.ru, балбес блин )))
В общем я проверил и с Вашим конфигом теперь работает все!
За что огромное спасибо!
Отмечу решением.
А еще лучше если Вы мне подскажете как вообще для каждого сайта свой юзер и группа или так не делают по феншую и просто я загоняюсь? Как правильно делать? Или оставить родную группу www-data?
Я понял Вас, оставлю как есть группу и пользователя.
Не получается подружить nginx и php
чтобы установка php не тащила httpd?
Не ставить пакет php.
У тебя же по ссылке есть Отключение Httpd
скорее всего php-fpm не настроено в /etc/php-php.d/www.conf или listen не совпадает с настройкой fastcgi_pass nginx
так там для c7 не предлагают php ставить, только php-fpm. ошибся, пора спать.
Паставить, а потом отключить. Нахуа?
Ставь «nginx php5». Есть подозрение, что по зависимостям вылезают какие-то апачевские либы и модули.
В пакете php идет mod_php для апача, ну и явно указан в зависимостях httpd. Ставить надо nginx php-fpm.
а если телнетом на порт php-fpm стукануть, то что потдается?
Ну, если даже инструкция с самого РУСЛИНУКСНЕТ не работает, то совершенно очевидно, что способов запустить лемп-стек на центоси не существует.
Стартуешь демон php-fpm и проверяешь результат 🙂
Тогда еще в конфиге пула php-fpm надо на этот сокет поменять, по дефолту там 9000 порт.
а если телнетом на порт php-fpm стукануть, то что потдается?
В подходе. Для начала разберись в общих чертах как эта связка должна работать, а потом уже настраивай её. Тебе ведь её потом эксплуатировать.
Не надо пытаться слепо повторить инструкцию.
В общих чертах понимаю, что к nginx php привязывается через fastcgi-интерфейс php-fpm, а к apache с помощью модуля mod_php.
В /etc/php-fpm.conf есть строки:
В /etc/nginx/nginx.conf есть:
У меня до php-fpm клиентские запросы кажется на доходят?
Покажи весь конфиг.
nginx обращается к демону php-fpm по протоколу FastCGI через unix или обычный сетевой сокет. Домен php-fpm запускает воркеры которые исполняют php-скрипты.
А вот это вот что такое:
fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name;
И почему директория логов php-fpm находится внутри директории логов nginx?
Опечатка
/var/log/php-fpm/error.log
Это было в /etc/nginx/nginx.conf.default Я это перенёс в /etc/nginx/nginx.conf и раскоментировал.
Вообще-то ошибка возникает на виртуальном хосте описанном в файле /etc/nginx/conf.d/mycoolhost.ru.conf такого содержания:
\.php$ но nginx ругаясь в логах на неправильный конфиг. Тогда я добавил location
\.php$ в default_server
И ты ожидаешь что php будет работать на mycoolhost.ru?
Ладно, буду дальше курить доки по nginx. Я думал, что «_» (default_server) это глобальные настройки всех виртуальных хостов.
А может в jobs? За два килорубля настрою тебе LEMP. Ну или за килорубль, если на дебиане
Демпингую на 500 WMR 😀
А чё не сразу до одного доширака?
Так неинтересно. Должен быть аукцион дух состязания.
А вообще: не получится настроить php-fpm, повесь на бекенд Апач.
Ладно, ладно) Ты если чё пиши, не стесняйся, мы тут.
Ты опять все усложнил.
Ну ок, читай документацию дальше. Пока-что ты прочёл явно недостаточно. Или понял недостаточно.
Держи конфиг, не мучайся
Можно указать server_name yourdomain.ru для твоего домена.
Для каждого домена я делал свой конфиг.
Centos 7 стоит php7 + php-fpm + nginx + owncloud + mariadb и т.п., без httpd
Подключаешь:
Закомментируй стандартные настройки (все секции server) в
. Почистить кеш в браузере.
Зайти на example.com/info.php
Конфиг owncloud, может кстати кому то еще пригодиться:
Так,
Если другие версии (сборки) ngninx и php-fpm данная инструкция сработает?
У меня установлены nginx 1.10.2 из epel, php и php-fpm 5.4.16 из base.
То что у тебя в nginx.conf в директиве listen не стоит default_server это нормально?
Нормально, зависит от конфигурации.
Да должно сработать конечно. Про кеш в браузере не забывайте очистить.
Потом решил ещё одну проверку сделать, обратился к серверу не по имени хоста, а по ip-адресу, в этом случае обращение должно идти к default_server, который отображает заглушку. Положил в корневые директории как default_server, так и хоста mycoolhost.ru файл ttt.php с содержанием:
Для тех кто не читал переписку, любые попытки добавить директивы fastcgi_* куда-либо кроме default_server приводят к тому, что nginx отказывается запускаться.
Не работает php в связке nginx + php5-fpm
Добрый вечер, даже не знаю что не работает, html работает, а при заходе на страницу php в хроме: Ошибка. Ссылка не работает. в логах php5-fpm все нормально, в nginx пусто в логах ошибок, php5-fpm слушает 9000 порт, было установлено: nginx/1.0.11 PHP 5.3.3-7+squeeze3 with Suhosin-Patch (cgi-fcgi) с подменой зависимостей на него поставил php5-fpm_5.3.3-1(плохо но может лучше, чем из репозиториев dotdeb и т.д.) все настроено. Даже не знаю куда копать, помогите пожалуйста.
events <
worker_connections 768;
# multi_accept on;
>
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
types_hash_max_size 2048;
# server_tokens off;
server_names_hash_bucket_size 64;
# server_name_in_redirect off;
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»;
gzip_min_length 1100;
# gzip_vary on;
gzip_proxied any;
gzip_comp_level 9;
gzip_buffers 4 8k;
gzip_http_version 1.1;
gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
>
root /var/www;
index index.html index.htm;
server_name localhost;
error_page 500 502 503 504 /50x.html;
location = /50x.html <
root /usr/share/nginx/www;
>
\.php$ <
# fastcgi_split_path_info ^(.+\.php)(/.+)$;
# # NOTE: You should have «cgi.fix_pathinfo = 0;» in php.ini
#
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME /var/www$fastcgi_script_name;
>
/sites-enabled/site.ru (изменил свой сайт на site.ru)
server <
listen 80;
server_name site.ru;
root /var/www/site.ru;
index index.php;
* ^.+.(js|css|png|jpg|jpeg|gif|ico)$ <
access_log off;
expires max;
>
location
.php$ <
# fastcgi_split_path_info ^(.+\.php)(.*)$
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param DOCUMENT_ROOT /site.ru;
fastcgi_param SCRIPT_FILENAME /site.ru$fastcgi_script_name;
fastcgi_param PATH_TRANSLATED /site.ru$fastcgi_script_name;
в настройках php5-fpm в файле /pool.d/ww(w).conf (добавил скобки, а то в ссылку преобразует) поменял только:
pm.max_children = 10
pm.start_servers = 1
pm.min_spare_servers = 1
pm.max_spare_servers = 10
[www]
listen = 127.0.0.1:9000
user = www-data
group = www-data
Частые ошибки в настройках Nginx, из-за которых веб-сервер становится уязвимым
Nginx — это веб-сервер, на котором работает треть всех сайтов в мире. Но если забыть или проигнорировать некоторые ошибки в настройках, можно стать отличной мишенью для злоумышленников. Detectify Crowdsource подготовил список наиболее часто встречающихся ошибок, делающих сайт уязвимым для атак.
Nginx — один из наиболее часто используемых веб-серверов в Интернете, поскольку он модульный, отзывчивый под нагрузкой и может масштабироваться на минимальном железе. Компания Detectify регулярно сканирует Nginx на предмет неправильных настроек и уязвимостей, из-за которых могут пострадать пользователи. Найденные уязвимости потом внедряются в качестве теста безопасности в сканер веб-приложений.
Мы проанализировали почти 50 000 уникальных файлов конфигурации Nginx, загруженных с GitHub с помощью Google BigQuery. С помощью собранных данных удалось выяснить, какие ошибки в конфигурациях встречаются чаще всего. Эта статья прольёт свет на следующие неправильные настройки Nginx:
Отсутствует корневой каталог
Небезопасное использование переменных
Чтение необработанного ответа сервера
Отсутствует корневой каталог
Из почти 50 000 файлов конфигурации Nginx, которые мы проанализировали, наиболее распространёнными корневыми путями были следующие:
Потерявшийся слеш
Одним из признаков того, что сервер Nginx имеет неправильную конфигурацию, является возврат сервером одинакового же ответа при удалении косой черты в URL-адресе. То есть, если http://server/api/user и http://server/apiuser возвращают один и тот же ответ, сервер может быть уязвимым. Он позволяет отправлять следующие запросы:
Небезопасное использование переменных
Некоторые фреймворки, скрипты и конфигурации Nginx небезопасно используют переменные, хранящиеся в Nginx. Это может привести к таким проблемам, как XSS, обход HttpOnly-защиты, раскрытие информации и в некоторых случаях даже RCE.
SCRIPT_NAME
С такой конфигурацией, как эта:
XSS возможен, если PHP-скрипт попытается определить базовый URL на основе SCRIPT_NAME ;
Пример уязвимой конфигурации Nginx:
Произвольные переменные
В некоторых случаях данные, предоставленные пользователем, можно рассматривать как переменную Nginx. Непонятно, почему это происходит, но это встречается не так уж редко, а проверяется довольно-таки сложным путём, как видно из этого отчёта. Если мы поищем сообщение об ошибке, то увидим, что оно находится в модуле фильтра SSI, то есть это связано с SSI.
Одним из способов проверки является установка значения заголовка referer:
Мы просканировали эту неправильную конфигурацию и обнаружили несколько случаев, когда пользователь мог получить значение переменных Nginx. Количество обнаруженных уязвимых экземпляров уменьшилось, что может указывать на то, что уязвимость исправлена.
Чтение необработанного ответа сервера
С proxy_pass Nginx есть возможность перехватывать ошибки и заголовки HTTP, созданные бэкендом (серверной частью). Это очень полезно, если вы хотите скрыть внутренние сообщения об ошибках и заголовки, чтобы они обрабатывались Nginx. Nginx автоматически предоставит страницу пользовательской ошибки, если серверная часть ответит ей. А что происходит, когда Nginx не понимает, что это HTTP-ответ?
Если клиент отправляет недопустимый HTTP-запрос в Nginx, этот запрос будет перенаправлен на серверную часть как есть, и она ответит своим необработанным содержимым. Тогда Nginx не распознает недопустимый HTTP-ответ и просто отправит его клиенту. Представьте себе приложение uWSGI, подобное этому:
И со следующими директивами в Nginx:
proxy_intercept_errors будет обслуживать пользовательский ответ, если бэкенд имеет код ответа больше 300. В нашем приложении uWSGI выше мы отправим ошибку 500, которая будет перехвачена Nginx.
proxy_hide_header почти не требует пояснений; он скроет любой указанный HTTP-заголовок от клиента.
Если мы отправим обычный GET-запрос, Nginx вернёт:
Но если мы отправим неверный HTTP-запрос, например:
То получим такой ответ:
merge_slashes отключены
Мы нашли 33 Nginx-файла, в которых для параметра merge_slashes установлено значение «off».
Попробуйте сами
Мы создали репозиторий GitHub, где вы можете использовать Docker для настройки своего собственного уязвимого тестового сервера Nginx с некоторыми ошибками конфигурации, обсуждаемыми в этой статье, и попробуйте найти их самостоятельно!
Вывод
Nginx — это очень мощная платформа веб-серверов, и легко понять, почему она широко используется. Но с помощью гибкой настройки вы даёте возможность совершать ошибки, которые могут повлиять на безопасность. Не позволяйте злоумышленнику взломать ваш сайт слишком легко, не проверяя эти распространённые ошибки конфигурации.
Вторая часть будет позднее.
Что ещё интересного есть в блоге Cloud4Y
Подписывайтесь на наш Telegram-канал, чтобы не пропустить очередную статью. Пишем не чаще двух раз в неделю и только по делу.
nginx + php-fpm = File not found
When i try accessing info.php I get a File not found. error.
I tried some Tutorials to no avail.
8 Answers 8
If that info.php is in /var/www, then it’s wrong to instruct fast_cgi to look for
Use the same root for html and php. Also, root and index parameters should be outside a particular location except for very specific uses.
needless to say, you still need to make sure your php-fpm service is listening at port 7777. Common case is to have it listening at port 9000.
If you checked every thing and it’s correct configured, then there is last point i got:
Nginx & Symlinks
Note, if root /var/www; is a symlink, change it to root /var/www/; otherwise nginx won’t go past the symlink and you’ll get a File not found error
Documentation for variables above:
file path for the current request, based on the root or alias directives, and the request URI
root or alias directive’s value for the current request
request URI or, if a URI ends with a slash, request URI with an index file name configured by the fastcgi_index directive appended to it. This variable can be used to set the SCRIPT_FILENAME and PATH_TRANSLATED parameters that determine the script name in PHP. For example, for the “/info/” request with the following directives