Здравейте,

 

Необходима ми е малко помощ за пускането на сайт с WEB сървър NGINX 1.2.6, PHP-FPM 5.4.9 и MYSQL 5.5.28, операционната система е Gentoo Linux 64 бита.

Положението е следното:

WEB сървъра работи и сервира статични HTML страници, но при PHP файл излиза текста "ACCESS denied." на бяла страница и нищо друго. Няма съобщения в логовете.

Доста се рових в Интернет за възможни причини и пробвах всички предложени решения, но проблема си остана. Тестовата PHP страница е само от една функция ECHO, така че в нея няма проблеми.

Връзката между трите сървъра е чрез домейн сокети, които са с необходимите права според мен.

Ако някой има идея какво още да проверя ще съм му благодарен.

 

 

Следвай документацията, повече от подробна е. В логовете пише защо е грешката.

 

Също така си update Gentoo. Последния stable Nginx е 1.3.5, който е добавен в portage преди 2-3 месеца още. Ако не пускаш emerge --sync и после не ъпдейтваш повече от ме сец убиваш целия смисъл в използването на Gentoo. Да не говорим и че ще ти се налага да го преинсталираш, защото при следващия ъпдейт ще се счупят половината пакети.

Редактирано 31 декември 201213 г. от arzhar (преглед на промените)

Следвай документацията, повече от подробна е. В логовете пише защо е грешката.

 

Също така си update Gentoo. Последния stable Nginx е 1.3.5, който е добавен в portage преди 2-3 месеца още. Ако не пускаш emerge --sync и после не ъпдейтваш повече от ме сец убиваш целия смисъл в използването на Gentoo. Да не говорим и че ще ти се налага да го преинсталираш, защото при следващия ъпдейт ще се счупят половината пакети.

 

Нещо не мога да намеря нито едно вярно твърдение в твоя отговор.

Нещо не мога да намеря нито едно вярно твърдение в твоя отговор.

Отворете логовете на nginx и вижте защо получавате тази грешка. И само да попитам: при условие че апаш е много по-добър от nginx в сервиране на динамично съдържание имате ли много сериозна причина да ползвате nginx?

Отворете логовете на nginx и вижте защо получавате тази грешка. И само да попитам: при условие че апаш е много по-добър от nginx в сервиране на динамично съдържание имате ли много сериозна причина да ползвате nginx?

 

Я пусни апаче при 10 000 000 request-а на vps от $10-15. Два сайта с хидялди посещения, които използват Nginx + php-fpm: wordpress.com и wordpress.org Nginx е лек и удобен. Има 2 или 3 модула, които липсват, а Апаче има. Хиляди уеб мастъри са на мнение, че Nginx и другите lightweight сървъри ще изместят Апаче съвсем скоро.

 

Нещо не мога да намеря нито едно вярно твърдение в твоя отговор.

 

Опа, прав си, в момента е 1.2.6, не 1.3

 

http://packages.gentoo.org/package/www-servers/nginx

 

Но това не променя съвета ми да прочетеш в лога на php-fpm къде ти е грешката. А ако не се оправиш, просто го пусни през TCP, не Unix Socket, по-лесно е и разликата е абсолютно минимална. Сокет е по-сигурно разбира се.

 

Ето пример за nginx директиви при tcp конфигурация. За съжаление не пазя нито един конф и тов е по спомени, но в конфа за php-fpm всичко е обяснено подробно:

 

 

             

 

index index.php; location ~ .php$ {                include /etc/nginx/fastcgi.conf;                fastcgi_pass  127.0.0.1:55523;                fastcgi_index index.php;

 

Редактирано 31 декември 201213 г. от arzhar (преглед на промените)

  Я пусни апаче при 10 000 000 request-а на vps от $10-15. Два сайта с хидялди посещения, които използват Nginx + php-fpm: wordpress.com и wordpress.org Nginx е лек и удобен. Има 2 или 3 модула, които липсват, а Апаче има. Хиляди уеб мастъри са на мнение, че Nginx и другите lightweight сървъри ще изместят Апаче съвсем скоро.

....

10М рикуеста за година? или за 10 години? И кой идиот ще иска да пусне услуга с много рикуести на евтина виртуалка. Архитектите имат много по-елегантни решения на подобни казуси, но за да ги осмислите трябва да излезете от дребния си мащаб и да можете да погледнете нещата отгоре

10М рикуеста за година? или за 10 години? И кой идиот ще иска да пусне услуга с много рикуести на евтина виртуалка. Архитектите имат много по-елегантни решения на подобни казуси, но за да ги осмислите трябва да излезете от дребния си мащаб и да можете да погледнете нещата отгоре

 

10м на ден. Еми явно от Wordpress са идиоти, защото до скоро техния сървър беше точно такъв, а в момента използват Nginx.

 

Eто и друг пример:

 

http://www.ewanleith.com/blog/900/10-million-hits-a-day-with-wordpress-using-a-15-server

Редактирано 31 декември 201213 г. от arzhar (преглед на промените)

10м на ден. (requests, не hits). Еми явно от Wordpress са идиоти, защото до скоро техния сървър беше точно такъв.

Да, но не се хоства на виртуалка, която вие предлагате. И това че фромденд е такъв не означава че отзад не е друг сървър, примерно омразния ви апаш

http://worpress.com was running nginx on unknown when last queried at 31-Dec-2012 15:40:55 GMT - refresh now Site Report 

Try out the Netcraft Toolbar! FAQ

 

OS Server Last changed IP address Netblock Owner unknown nginx 31-Dec-2012 76.74.254.123  Automattic, Inc Linux nginx 23-Oct-2011 72.233.2.58  Layered Technologies, Inc.

http://worpress.com was running nginx on unknown when last queried at 31-Dec-2012 15:40:55 GMT - refresh now Site Report 

Try out the Netcraft Toolbar! FAQ

 

OS Server Last changed IP address Netblock Owner unknown nginx 31-Dec-2012 76.74.254.123  Automattic, Inc Linux nginx 23-Oct-2011 72.233.2.58  Layered Technologies, Inc.

Вие осмисляте ли поне нещо от това, което ви пиша? Да сте чувал нещо за многослойни архитектури?

Да, но не се хоства на виртуалка, която вие предлагате. И това че фромденд е такъв не означава че отзад не е друг сървър, примерно омразния ви апаш

 

А не предлагам нищо. Просто отбелязвам факти. След като работи мен лично друго не ме интересува. На всичкото отгоре работи по-бързо и излиза по-рентабилно. Вместо да дам $200 за сървър, ще дам $20 и ще върши същата работа без :многослойните: архитектури.

Редактирано 31 декември 201213 г. от arzhar (преглед на промените)

А не предлагам нищо. Просто отбелязвам факти. След като работи мен лично друго не ме интересува. На всичкото отгоре работи по-бързо и излиза по-рентабилно.

Да, заради мащаба. КОгато успеете да го надскочите и да се грижите за два 42 инчови шкафа, които правят един уеб сървър тогава ще говорим

Да, заради мащаба. КОгато успеете да го надскочите и да се грижите за два 42 инчови шкафа, които правят един уеб сървър тогава ще говорим

 

Ние говорехме за скорост и производителност, не мащаби. 

 

Но понеже спомена, какво му е на red hat клъстъра с Nginx И Апаче? Нещо, което да не мога да постигна?  Апаче обработва htaccess директивите само като седи отпред или отзад.

 

Моят сетъп в момента е от 4 сървъра:

 

Ако S1 е down, заявките отиват към S2 и има други два, които играят ролята на reverse proxy и backup. Всичко се синхронизира в реално време. Проблема е нулев бройката да не е 4 а 400. Всичко това с минимален бюджет.

 

Живот и здраве и до големи шкафове ще стигнем.

...

 

Но понеже спомена, какво му е на red hat клъстъра с Nginx И Апаче? Нещо, което да не мога да постигна?  Апаче обработва htaccess директивите само като седи отпред или отзад.

...

Точно това се опитвам да обясня, Nginx прекрасно играе ролята на прокси, апаша на приложен сървър

Точно това се опитвам да обясня, Nginx прекрасно играе ролята на прокси, апаша на приложен сървър

 

A защо не Apache просто да се грижи само за htaccess и другите 2-3 модула, които липсват на Nginx? Трябва ли сега да вадя актуални статистики да видиш какво става с load-a на няколко от по-натоварените ми сайтове след като минаха изцяло на Nginx и ако пусна обратно Apache в играта (и не, не е default конфигурация с всичкия бълвоч на Apache)? Има причина тези два сайта, които споменах да не използват Apache. Свържи се с developer-ите и ще разбереш защо. Правили са не един и два опита, а не може да кажеш, че не си знаят работата.

 

Nginx не е просто прокси. Освен htaccess и няколко модула (скоро и тях ще ги има) какво друго не можеш да постигнеш с него?

 

С две думи - защо инвестирам в още сървъри след като на текущия мога да сложа 10000 потребителя, вместо 2000 (примерно) само като сменя софтуера

 

А защо един средно статистически юзер да плаща за по-голям VPS или за Dedicated след като отново само със смяна на web сървъра и php handler-a ще постигне х4 резултати?

Редактирано 31 декември 201213 г. от arzhar (преглед на промените)

A защо не Apache просто да се грижи само за htaccess и другите 2-3 модула, които липсват на Nginx? Трябва ли сега да вадя актуални статистики да видиш какво става с load-a на няколко от по-натоварените ми сайтове след като минаха изцяло на Nginx и ако пусна обратно Apache в играта (и не, не е default конфигурация с всичкия бълвоч на Apache)? Има причина тези два сайта, които споменах да не използват Apache. Свържи се с developer-ите и ще разбереш защо. Правили са не един и два опита, а не може да кажеш, че не си знаят работата.

 

Nginx не е просто прокси. Освен htaccess и няколко модула (скоро и тях ще ги има) какво друго не можеш да постигнеш с него?

Не, аз съм се свързвал с едни други разработчици, които използват апаш. и знам защо те го ползват. Какво вие ползвате е нещо което си остава ваш проблем и ваша грижа

С две думи - защо инвестирам в още сървъри след като на текущия мога да сложа 10000 потребителя, вместо 2000 (примерно) само като сменя софтуера

 

А защо един средно статистически юзер да плаща за по-голям VPS или за Dedicated след като отново само със смяна на web сървъра и php handler-a ще постигне х4 резултати?

Айде да се върнем на първоначалната тема!

 

В логовете на NGINX и PHP-FPM не излиза никаква грешка. Затова питам тук. Съобщението излиза в WEB браузъра като задам някой PHP файл със стандартно .php разширение.

Предпочитам да ползвам сокети заради по-високата сигурност и производителност. Двата сървъра са на една машина.

 

Айде да се върнем на първоначалната тема!

 

В логовете на NGINX и PHP-FPM не излиза никаква грешка. Затова питам тук. Съобщението излиза в WEB браузъра като задам някой PHP файл със стандартно .php разширение.

Предпочитам да ползвам сокети заради по-високата сигурност и производителност. Двата сървъра са на една машина.

 

Pastebin nginx.conf и php-fpm.conf

 

Разликата между tcp и unix сокет няма да я видиш освен ако нямаш хиляди requests. Иначе да, по-сигурно е.

 

emerge wgetpaste

 

wgetpaste /etc/nginx/nginx.conf и т.н. ако не знаеш как.

Редактирано 31 декември 201213 г. от arzhar (преглед на промените)

Айде да се върнем на първоначалната тема!

 

В логовете на NGINX и PHP-FPM не излиза никаква грешка. Затова питам тук. Съобщението излиза в WEB браузъра като задам някой PHP файл със стандартно .php разширение.

Предпочитам да ползвам сокети заради по-високата сигурност и производителност. Двата сървъра са на една машина.

Опитайте да стартирате някой от php файловете през php интерпретатора, но бидейки потребителя който стартира NGINX. Освен това мисля имаше някаква опция да дебъг съобщения на php, пробвайте да я активирате

Опитайте да стартирате някой от php файловете през php интерпретатора, но бидейки потребителя който стартира NGINX. Освен това мисля имаше някаква опция да дебъг съобщения на php, пробвайте да я активирате

  Проблема си е все същия. В браузъра излиза съобщение "Access denied." В лога на NGINX за php файла излиза отговор 403, а за html 200. Правата на root директорията на сървъра са 0777, както и на самите файлове. Собственика и групата на файловете и директорията са тези зададени за NGINX и PHP-FPM. Файловия сокет е със същите потребител и група и права 0666. Двата сървъра тръгват нормално. без грешки в логовете.   Остава проблема да е в конфига на NGINX за работа с PHP. Ето го него:  

server {...root /server/online;location ~* .php$ {include fastcgi_params;fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;fastcgi_index index.php;fastcgi_pass unix:/run/php.socket;}}

CLI версията на PHP не е компилирана.

Редактирано 1 януари 201313 г. от supervas (преглед на промените)

  Проблема си е все същия. В браузъра излиза съобщение "Access denied." В лога на NGINX за php файла излиза отговор 403, а за html 200. Правата на root директорията на сървъра са 0777, както и на самите файлове. Собственика и групата на файловете и директорията са тези зададени за NGINX и PHP-FPM. Файловия сокет е със същите потребител и група и права 0666. Двата сървъра тръгват нормално. без грешки в логовете.   Остава проблема да е в конфига на NGINX за работа с PHP. Ето го него:  

server {...root /server/online;location ~* .php$ {include fastcgi_params;fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;fastcgi_index index.php;fastcgi_pass unix:/run/php.socket;}}

CLI версията на PHP не е компилирана.

Какъв е резултата от тази команда:

 

ls -ld /run/php.socket

Какъв е резултата от тази команда:

 

ls -ld /run/php.socket

 

srw-rw-rw- 1 nginx nginx 0 Jan 1 15:24 /run/php.socket

Помолих те да пуснеш и php-fpm. Така мога да ти кажа конфа на nginx правилен ли е или не.

 

Конфигурираш php-fpm да създава файл за сокета *.socket според името на pool-a или там както си решиш, оправяш си правата на сокет директорията и готов. Ето ти още един примерен server block за nginx.conf:

 

 

server {

                server_name sreburnite-grivni.rstefanov.com www.sreburnite-grivni.rstefanov.com;

                root /var/www/sreburnite-grivni.rstefanov.com/html;

                index index.html index.php;

 

location /404.html {

                root /var/www/localhost/htdocs/html;

 

charset off;

 

                }

 

 

                charset windows-1251;

 

 

                access_log /var/log/nginx/sreburnite-grivni.rstefanov.com.access_log main;

                error_log /var/log/nginx/sreburnite-grivni.rstefanov.com_log info;

 

                index index.php; location ~ .php$ {

                include /etc/nginx/fastcgi.conf;

              fastcgi_pass unix:/var/php5-fpm/lig.socket;

                fastcgi_index index.php;

 

                }

}

Редактирано 1 януари 201313 г. от arzhar (преглед на промените)

Помолих те да пуснеш и php-fpm. Така мога да ти кажа конфа на nginx правилен ли е или не.

 

Конфигурираш php-fpm да създава файл за сокета *.socket според името на pool-a или там както си решиш, оправяш си правата на сокет директорията и готов. Ето ти още един примерен server block за nginx.conf:

 

 

server {

                server_name sreburnite-grivni.rstefanov.com www.sreburnite-grivni.rstefanov.com;

                root /var/www/sreburnite-grivni.rstefanov.com/html;

                index index.html index.php;

 

location /404.html {

                root /var/www/localhost/htdocs/html;

 

charset off;

 

                }

 

 

                charset windows-1251;

 

 

                access_log /var/log/nginx/sreburnite-grivni.rstefanov.com.access_log main;

                error_log /var/log/nginx/sreburnite-grivni.rstefanov.com_log info;

 

                index index.php; location ~ .php$ {

                include /etc/nginx/fastcgi.conf;

              fastcgi_pass unix:/var/php5-fpm/lig.socket;

                fastcgi_index index.php;

 

                }

}

 

Коя точно директива те интересува от PHP-FPM. Там потребителите са същите.

/run е с друг собственик и група, но с права 0777.