Пользователь
0,0
рейтинг
3 февраля 2011 в 20:39

Администрирование → Установка и настройка: Nginx + php5-fpm

В данной заметке, будет показано как поставить связку Nginx + php5-fpm (php5.3) на Debian Lenny и настроить безопасную конфигурацию.

Установка и настройка

Важно: все команды от root'а.

Добавляем репозитарии и генерируем ключи:
echo "deb http://backports.debian.org/debian-backports lenny-backports main" >> /etc/apt/sources.list
echo "deb http://php53.dotdeb.org stable all" >>   /etc/apt/sources.list
gpg --keyserver keys.gnupg.net --recv-key 89DF5277 && gpg -a --export 89DF5277 | apt-key add -
Обновляем:
aptitude update
Устанавливаем nginx и php5-fpm:
aptitude install -t lenny-backports "nginx"
apt-get install php5-cli php5-common php5-suhosin 
apt-get install php5-fpm php5-cgi
Приводим конфиг /etc/nginx/nginx.conf к виду:
user www-data;
worker_processes  1; # Ставим число по количеству ядер

timer_resolution 100ms;
worker_rlimit_nofile 8192;
worker_priority -5; #Увеличитвваем приоритет

error_log  /var/log/nginx/error.log;
pid        /var/run/nginx.pid;
events {
    worker_connections  1024;
}
http {
    include       /etc/nginx/mime.types;
    access_log	/var/log/nginx/access.log;

    sendfile        on;
    keepalive_timeout  65;
    tcp_nodelay        on;

    gzip	on;
    gzip_min_length	1100;
    #gzip_disable	"msie6";  #Быстрее, но работает только на новых версиях nginx
    gzip_disable "MSIE [1-6]\.(?!.*SV1)";
    gzip_proxied	any;
    gzip_comp_level	4;
    gzip_types 		text/plain text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript;
    gzip_vary		on;

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

Удаляем /etc/nginx/sites-available/default

Пример конфига

Конфиг для использования с CMS WordPress, с учетом использования chroot/etc/nginx/sites-enabled/example.ru:
server {
	listen  80;
	server_name  www.example.ru;
	rewrite ^ http://example.ru$request_uri? permanent; #301 redirect
}
server {
    listen  80;
	server_name  example.ru; 
	root   /var/www/example.ru;
	index  index.php;

	location / {
		try_files $uri $uri/ /index.php?q=$uri&$args;
	}
	location ~* ^.+.(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    /example.ru;
		fastcgi_param  SCRIPT_FILENAME  /example.ru$fastcgi_script_name;
		fastcgi_param  PATH_TRANSLATED  /example.ru$fastcgi_script_name;

		include fastcgi_params;
		fastcgi_param  QUERY_STRING     $query_string;
		fastcgi_param  REQUEST_METHOD   $request_method;
		fastcgi_param  CONTENT_TYPE     $content_type;
		fastcgi_param  CONTENT_LENGTH   $content_length;
		fastcgi_intercept_errors        on;
		fastcgi_ignore_client_abort     off;
		fastcgi_connect_timeout 60;
		fastcgi_send_timeout 180;
		fastcgi_read_timeout 180;
		fastcgi_buffer_size 128k;
		fastcgi_buffers 4 256k;
		fastcgi_busy_buffers_size 256k;
		fastcgi_temp_file_write_size 256k;
	}
	
	location = /favicon.ico {
		log_not_found off;
		access_log off;
	}
	location = /robots.txt {
		allow all;
		log_not_found off;
		access_log off;
	}
	## Disable viewing .htaccess & .htpassword 
	location ~ /\.ht {
		deny  all;
	}
}
Устанавливаем mysql:
apt-get install mysql-server mysql-client php5-mysql
mkdir -p /var/www/var/run/mysqld
mount --bind /var/run/mysqld/ /var/www/var/run/mysqld/
Создадим каталог и файл index.php:
mkdir -p /var/www/example.ru
echo "<?php phpinfo(); ?>" >/var/www/example.ru/index.php
Перезапускаем nginx и php5-fpm:
/etc/init.d/nginx restart
/etc/init.d/php5-fpm restart

Безопасность

Проставим правильные права каталогам:
chown -R www-data /var/www/example.ru && chmod -R 750 /var/www/example.ru
Исправляем уязвимость связанную с
location ~ .php$ {
, для этого прописываем в /etc/php5/fpm/php.ini
cgi.fix_pathinfo=0
Включим использование chroot, для ограничения доступа PHP к системе. Для этого редактируем файл /etc/php5/fpm/php5-fpm.conf, прописываем:
chroot = /var/www
chdir = /
Далее мы столкнемся с проблемой что PHP не сможет отрезолвить адрес, исправляем:
mkdir /var/www/{etc,lib};
cp /etc/hosts /var/www/etc/hosts;
cp /etc/resolv.conf /var/www/etc/resolv.conf;
cp /lib/libnss_dns.so.2 /var/www/lib/libnss_dns.so.2 //ваша система 32 битная
cp /lib64/libnss_dns.so.2  /var/www/lib64/libnss_dns.so.2 //ваша система 64 битная
Перезапускаем php5-fpm:
/etc/init.d/php5-fpm restart

Заходим на страницу нашего сайта example.ru и любуемся на вовод phpinfo() нашего сайта.
P.S. C настройками мне помог разобраться inkvizitor68sl автор блога Debian.pro.
NEW:

Установка Nginx 0.8.54

apt-get update
apt-get install libxml2-dev libbz2-dev libcurl4-openssl-dev libmcrypt-dev libmhash2 libmhash-dev libpcre3 libpcre3-dev make

wget http://sysoev.ru/nginx/nginx-0.8.54.tar.gz
tar zxf nginx-0.8.54.tar.gz
cd nginx-0.8.54
 
./configure \
--conf-path=/etc/nginx/nginx.conf \
--error-log-path=/var/log/nginx/error.log \
--http-client-body-temp-path=/var/lib/nginx/body \
--http-fastcgi-temp-path=/var/lib/nginx/fastcgi \
--http-log-path=/var/log/nginx/access.log \
--http-proxy-temp-path=/var/lib/nginx/proxy \
--lock-path=/var/lock/nginx.lock \
--pid-path=/var/run/nginx.pid \
--with-debug --with-http_dav_module \
--with-http_gzip_static_module \
--with-http_realip_module \
--with-http_stub_status_module \
--with-http_sub_module

make && make install 

Debian «Squeeze»

Для установки пакета php-fpm понадобится:
echo "deb http://packages.dotdeb.org squeeze all" >>   /etc/apt/sources.list
wget http://www.dotdeb.org/dotdeb.gpg && cat dotdeb.gpg | apt-key add - && aptitude update
UPD: Добавил пару строк в установку mysql, указание в настройках localhost теперь работает. Спасибо inkvizitor68sl.
Danillab @Danillab
карма
14,8
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Администрирование

Комментарии (129)

  • 0
    Толково вроде. А почему не кэшируете сгенерированные страницы или у Вас для каждого посетителя свои плюшки имеюются?
    • 0
      Для этого проще php-apc накатить пакет.
      • 0
        это далеко не одно и то же
        • 0
          Для человека, которому необходим этот мануал лезть в кеширование nginx'ом мягко говоря не резонно. Поэтому тем, кто его читает, лучше все же сделать aptitude install php5-apc php-apc и не мучаться до прочтения всего мануала по кешированию у Сысоева.
          • 0
            APC, eAccelerator или XCache необходимы в любом случае, но они не имеют ни малейшего отношения к кешированию контента. APC кеширует сам opcode в памяти, чтобы ускорить загрузку скриптов, а fastcgi_cache_* кеширует генерированные страницы, позволяя для обслуживания части запросов вообще не обращаться к php.
            • +1
              APC etc позволяют не только кэшировать опкод, но и имеют API для кэшиования данных, типа memcashed
              • +1
                Ребят, вы о разных вещах говорите. Вот, о чем шла речь в первом посте. Хотя к большинству проектов с регистрацией и «всякими плюшками для каждого пользователя» она сложно реализуема. Но, как говорится, сложно — не невозможно.
                • 0
                  Про это я в курсе, но мне просто глаз резануло «они не имеют ни малейшего отношения к кешированию контента».
                  • 0
                    Тут рецепт настройки сервера. Каким боком к администраторской работе относится API для пользовательской программы? Какое отношение это имеет к кешированию контента, кроме косвенного (через него тоже можно кешировать)? Так и через Mongo можно кешировать и через файлы и через memcached, но это требует уже программирования, а не администрирования.
                    • 0
                      Самое непосредственное отношение имеет. Например:

                      set $memcached_key "$host$uri";
                      memcached_pass 127.0.0.1:11211;
                      error_page 404 500 502 503 504 = @fallback;

                      Это все равно к админу, а не к программеру.
                      • 0
                        Где здесь про APC?
                • 0
                  да вроде не особо сложно-то.
                  • 0
                    Я пробовал — не понял как инвалидировать кэш при изменении данных, не из php же скрипта удалять файлы из кэша?
                    • 0
                      Инвалидировать при добавлении контента? Не ставьте слишком большое время кэша.
                      • 0
                        При изменении, скажем так. Вряд ли стоит ожидать от одного пользователя (зарегистрированного) запросы чаще чем раз в секунду (если это не (D)DOS), а большее время вызовет неудовольствие.
                        • 0
                          Ну зарегистрированным пользователям можно кэш и отключить. Хотя вот с комментариями анонимусов проблема, да.
                          • 0
                            если поставить систему комментирования на ajax, вроде disqus.com, то этой проблемы не будет на при каком кэше.
                    • 0
                      Если у вас сайт с высокой оперативностью (например новостной, как у меня), то инвалидировать кеш nginx можно удаляя файл, имя и путь к которому легко расчитать через md5, как это делает сам nginx. Если позволит производительность, то кеш на ключевых страницах, вроде главной и фидов, можно отключить или снизить время его жизни до 1 минуты (предпочтительнее всех остальных вариантов). Если сайт вроде блога, то кеш на пол часа и не надо париться с инвалидизацией — самые прыткие найдут новый контент через rss и twitter.
                      • 0
                        «но это требует уже программирования, а не администрирования» ;)
                        • 0
                          Конечно. А у вас есть сомнения, что правила выборочной инвалидизации данных, подчиненных архитектуре конкретной системы относятся к компетенции разработчика, а не админа?
                          • 0
                            Так я про это сразу написал, только про APC
                            • 0
                              Только к текущему топику это не относится. А fastcgi_cache_* в nginx относится напрямую.
                              • 0
                                В начале треда сразу было отвечено, что проще установить APC, который будет хотя бы опкоды кэшировать, чем заморачиваться с fastcgi_cache_*. И в том, и в другом случае будем теоретически иметь прирост производительности, но в первом не будет значимых для типичных приложений побочных эффектов, а во втором будут, если не изменять код скриптов. Самsй оптимальный, вариант, конечно, использовать и то, и другое — APC для кэширования опкодов и данных, fastcgi_cache_* для уже сгенерированных страниц. Главное инвалидацию реализовать правильно и для данных в кэше APC, и для страниц в кэше nginx.

                                Закончим на этом? :)
                                • 0
                                  Давайте я уточню свое мнение и больше не буду претендовать.

                                  1. Заморачиваться с fastcgi_cache_* в рамках этой статьи логично и не выходит за них, чего не скажешь про APC. Все заморачивание с fastcgi_cache_* состоит из дополнительных 5-10 строк к уже написанному конфигу nginx. говорить, что установка APC проще в данном контексте просто нелепо.

                                  2. Разница в ускорении работы сайта при fastcgi_cache_* и при простом opcode-cache настолько существенная, что про APC вообще можно было не вспоминать. это как сравнить для автомобиля прирост скорости от установки в 10 раз более мощного двигателя и изменение аэродинамики кузова на 0.1 Это решения разных порядков эффективности.

                                  3. Для большинства сайтов вопрос инвалидизации кеша стоит не сильнее, чем установка допустимого времени задержки обновления. 10 минут можно считать идеальным для подавляющего большинства часто обновляемых сайтов. А для редко обновляемых можно кешировать и на час. Только новостные сайты требуют более оперативного обновления, но там в механизме инвалидизации кеша нет надобности из-за очень короткого кеширования основных страниц и фидов.
                                  • 0
                                    Не могу не возразить :)
                                    1. Установка APC — одна строчка в консоли
                                    2. При условии, что есть попадания в кэш
                                    3. Простой пример неновостного часто обновляемого сайта: браузерная ((M)M)OG. Ещё пример: соцсети (а предыдущий пункт может быть и в них), ещё — веб-морды к, например, мылу. Не знаю как в абсолютном количестве сайтов, но по количеству хитов, имхо, сайты, кэш страниц которых не может быть инвалидирован только по времени без нарушения ожидаемой пользователем функциональности, сейчас составляют большинство. Почему-то придумалось выражение «Users's Content Driven Behavior of User» :) (sorry for my English)
                                    • 0
                                      1. Если по сценарию, приведенному здесь, то не одна. Если по принципу «меньше эффекта, за то меньше строчек», то я не могу разделить таких оснований для гордости. В любом случае APC и eAccelerator полезные вещи, но не повод отказываться от статического кеширования на популярном сайте.

                                      2. Без этого условия сайту не нужна оптимизация средствами системного администрирования.

                                      3. Такие сайты относятся к подавляющему меньшинству. При этом как раз в широко популярных социальных сетях статическое кеширование определенных частей контента выполняется наиболее часто, поскольку это самый дешевый метод повышения производительности. Конечно оно не применяется для частей, требующих мгновенной реакции, но, повторяю — статическое кеширование применимо на подавляющем большинстве сайтов. Если ваш сайт не имеет возможности пользоваться статическим кешированием, отдавая 100% пользовательской нагрузки на движок, то для такого проекта появляется слишком много ограничений. php с его cgi-архитектурой обнуления состояний между запросами, mysql c его нелинейной регрессией производительности при увеличении объемов данных в реляционных соединениях и блокировками делают производительность измеряемой десятками запросов в секунду. И это на фоне производительности в тысячи запросов в секунду для fastcgi_cache_*

                                      Всё, что я хочу сказать, что те 5-10 строчек конфига nginx, которые отвечают за кеширование являются важной частью для большого числа сайтов, к которым относится эта статья и вы зря от них отмахнулись.
                    • 0
                      Если речь о WordPress, то я сделал так.

                      За валидность кеша отвечает WP Super Cache. Если файл есть, то nginx берет его прямо в кеше, если нет, то отправляет запрос PHP.

                      Если в админке поменять пост, то его файл с кешем стирается и при следующем заходе генерируется новый файл.
    • 0
      А nginx представленный в офф. репозитариях debian'а (версии 0.6.32) о нём еще не догадывается :)
      • 0
        Пардон:
        — вместо «debian'а» следует читать lenny;
        — вместо «о нём» следует читать «о кешировании».
      • +1
        А есть маньяки ставящие nginx из репозитария? o_O
        • 0
          А что, сейчас снова модно собирать из сорцов?
          • 0
            А что, сейчас модно ставить старые версии nginx из репозитория?
            • 0
              Срезал)
              • 0
                Чуть не перешло в танец в такидатую дуэль =)
                • 0
                  Есть два решения, и оба через жопу неудобны:
                  — ставить из неофициального репа
                  — из сорцов
                  • +3
                    Есть третье решение, самое православное — собрать пакет и поставить.
                    • 0
                      А можно не использовать дефолтные репы.
                      В CentALT лежит версия 0.9.4
            • +1
              0.8.54 в sid у debian (в статье lenny-backports — 0.7.63 там)
            • +1
              А что, алтернативные репозитории уже отменили?
          • –1
            а что там собирать? за то можно приточить к процессору и собрать epoll или aio на выбор.
        • 0
          В статье как раз такой путь описан :)
  • +5
    У меня дежавю)
    • +1
      У меня тоже, но по статьям годовалой давности тупой копи-пастой уже ничего не поставишь, а новичкам полезно будет)

      *единственное негативное дежавю — «все комманды под рутом»)
      • 0
        А это не с тобой мы последние пару дней чинили chroot? )
        • +1
          Мы, добавил в пост :)
      • +1
        Если статья для установки копи-пастой, то логичнее было бы оформить всё в скрипт.
  • +1
    Только php-frm поменять на php-fpm еще бы по тексту и в теге
    • +1
      готово
  • +7
    Кто-нибудь из многочисленных копипастеров конфигов nginx может объяснить зачем нужны gzip_disable «msie6» и аналоги? Да, этот браузер не поддерживает gzip, и честно об этом сообщает, не передавая заголовок Accept-Encoding.
    • +1
      Вы еще не встречали ситуацию когда на экран вместо страницы выпадает абракадабра?
      • 0
        Какой информативный ответ.
        Какая разница, встречал ли я, я же не пользователь ие6. При каких условиях появляется абракадабра? Почему она появляется? Почему вы считаете, что именно эта строчку поможет от нее избавится?
        • 0
          Я уже имел опыт появления этой ошибки в IE на довольно популярном ресурсе. Исправил этой строчкой. Уже полтора года никто не заявляет, что у него сломана страница. Если вам этого мало, то поищите ответов в документации nginx и на форуме разработчика.
          • 0
            Вы разбирались в чем была проблема? IE действительно посылал заголовок Accept-Encoding: gzip?

            В документации сказано, что есть такой фильтр по юзерагенту, и то у него есть некоторое значение. Там не сказано, почему вдруг может понадобиться его использовать. Еще сказано, что данный параметр was introduced in Nginx 0.6.23. А до этой версии как жили?
            • 0
              Разбирался, IE слал заголовки, но не всегда понимал Encoding в ответе. Эта строчка устранила проблему, копать глубже не стало нужды.
    • +3
      Кандидат на причину данного явления: support.microsoft.com/kb/837251
      «some compressed files were not parsed correctly over a Security Sockets Layer (SSL) connection while the Do not save encrypted pages to a disk security option in Internet Explorer was selected
      APPLIES TO
      Microsoft Internet Explorer 6.0 Service Pack 1»

      Т.е. при загрузке контента по ssl (который не используется на 95% сайтов) в одной конкретной версии браузера при включении выключенной по-умолчанию (я проверил) настройки происходил глюк. И из-за этого большинство копипастеров предлагается резать gzip в проблемной версии и ниже для всех типов соединения, а не только для проблемного.

      Ну в общем, как-то примерно так я и предполагал, да.
      • +1
        Когда я исследовал этот вопрос, я находил целый сонм глюков в IE6 (до версии SP2), так что проще выключить gzip там, чем «лечить».
      • +1
        Отрицаю. Абракадабра была на обычном http и не устойчиво — то нормально показывает, то ломает.
    • +3
      MSIE 6 не выдаёт gzip в Accept-Encoding? Вы ошибаетесь, выдаёт (с четвёртой версии браузера). Я специально исследовал этот вопрос для книги «Реактивные веб-сайты». Брал «чистую Windows XP» без SP, смотрел под IE6.

      Под IE6SP2 проблемы исправлены (именно я посоветовал Сысоеву добавить исключение SV1, который является флагом, что в IE6 есть SP2).
      • 0
        Заинтриговал, пойду тоже поставлю.
        Если этот так, возникает еще больше вопросов:
        Зачем же он слал, если не поддерживал?
        А как же было возможно использовать gzip в nginx до версии 0.6.23, в которой этот gzip_disable и был добавлен?
        Если проблема действительно имеет место быть, почему это не зашитая в nginx логика, а отдельная опция, да еще и не включенная по-умолчанию?
        • +1
          Нет, он поддерживал. Просто глючил.
          > А как же было возможно использовать gzip в nginx до версии 0.6.23, в которой этот gzip_disable и был добавлен?
          Потому что глюки проявлялись в разных условиях. Где-то IE не «расшифровывал» gzip, если прокси отсылал ответ HTTP/1.0, где-то не кешировал такие ответы и так далее.

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

          > Если проблема действительно имеет место быть, почему это не зашитая в nginx логика, а отдельная опция, да еще и не включенная по-умолчанию?
          Проблема имеет место, опция не включена по-умолчанию, потому что, вообще-то, помимо msie6 там ещё должны быть значения, не дело автору веб-сервера заморачиваться с исследованием на эту тему.
          • 0
            Спасибо за развернутый ответ.
            Вот только с последним пунктом, прости, я не согласен :) Помоему как раз логично одному человеку разобраться в вопросе досконально и сделать затычку «по-умолчанию», чем предлагать сделать то же самое тысячам людей, использующим nginx.
            • 0
              На мой взгляд nginx имеет набор средств программирования, позволяющий организовать исключение для отдельного браузера и без опции gzip_disable. То что она вообще появилась я относил на счет оптимизации производительности столь необходимого функционала. Ну и большое спасибо автору за отключаемость этой опции на случай последующего уменьшения доли ie6
            • 0
              Ерудненюшка-то в том, что браузеры появляются, появляются новые глюки. Не все могут позволить себе обновлять nginx на каждый чих, но каждый может сменить конфигурацию.

              Кроме того, перебрать все версии браузеров на всех платформах — это огромный труд. Пусть лучше nginx улучшает :)
      • –1
        Поставил, посмотрел трафик. Действительно шлет заголовок и действительно есть какие-то проблемы с недогрузкой css на одном сайте, которые исчезли сразу как включил gzip_disable.
        Теперь не могу понять, откуда у меня был твердая уверенность что до второго сервиспака IE вообще не поддерживал gzip. Видимо, так говорили люди, имевшие ввиду, что он настолько глючит, что gzip ему все равно никто не отдает.
        • 0
          Если честно, то после массовых жалоб реальных пользователей эксперименты на сферической теории не вдохновляют. Но вы, конечно, развлекайтесь. Сделайте экспериментальную выборку побольше — глюк с непониманием заголовка сжатия, если я правильно помню, проявлялся где-то в 10-15% по отношению к случайным страницам. У меня в тот момент было всего 4000-5000 хитов из которых на IE6 приходилось где-то 60% Это давало 20-30 писем и 10-15 звонков с жалобами на поломку страницы.
  • +1
    Для резолвинга лучше, имхо, не копировать файлы, а делать симлинки. Уж на библиотеку точно, чтобы при обновлении не использовалась старая. На hosts и resolv.conf — тоже, если не нужны разные конфигурации.

    По самой установке ничего нового не узнал, но вот конфиг nginx интересен, спасибо :)
    • +3
      Симлинки из chroot? Ну-ну…
      • 0
        Да, про симлинки прогнал что-то, забыл, что я ставил хардлинки. Для hosts и resolf.conf они пойдут, для библиотеки, увы, нет :(
        • 0
          И для библиотеки должны пойти, если etc, lib и www находятся на одном разделе. А это крайне нежелательно с точи зрения стабильности системы, почему во многих рецептах и советуют копировать, а не линковать.
          • 0
            Для библиотеки, по-моему, не пойдёт, т. к. после обновления физически это будет уже другой файл
            • 0
              И как это противоречит цели держать два файла синхронизированными?
              • 0
                Хардлинк нужно будет обновлять или ручками, или писать скрипт, запускающий создание хардлинка после apt-get upgrade
                • 0
                  Можете указать цитату в мануале, где это написано?
                  • 0
                    Нет, общее представление о работе ФС (ext*), хардлинков на ней и процесса обновления:
                    — запись файла в каталоге ссылается на какой-то инод
                    — хардлинк ссылается на тот же инод
                    — при обновлении создаётся временный файл, оригинал сначала переименовывается во что-то временное, временный файл с новой версией переименовывается в оригинал (то есть файл библиотеки ссылается уже на другой инод), переименованный оригинал удаляется.

                    Если не прав — поправьте, пожалуйста, одним заблуждением будет у меня меньше.
                    • +1
                      Только что проверил.

                      ~$ echo "this is 1" > file1
                      ~$ ln ./file1 file2
                      ~$ cat file2
                      this is 1
                      ~$ echo "this is 3" > file3
                      ~$ mv file3 file1
                      ~$ cat file2
                      this is 1
                      ~$ cat file1
                      this is 3

                      Вы правы. Спасибо. Век живи, век учись, дураком помрешь.
                      • 0
                        Не убедили, что я прав :) Из трёх пунктов для меня самый сомнительный последний — утилит для Linux типа FileMon (логирование операций с файлами) не знаю, в исходниках apt-get вряд ли разберусь. Если разработчики ставили целью обновление и хардлинков на обновляемые файлы, то, исходя из тех же первых двух общих соображений, могли это реализовать. Прямо сейчас проверить не могу — недавно обновился.
  • +2
    А вот за cgi.fix_pathinfo=0 спасибо, не знал.
    • 0
      Тоже не знал, одно время начали вылавливать в user-uploads файлах всякие интересности в виде картинок с php-кодом внутри, долго думали, как они исполняются, в итоге завернули все запросы на index.php.
  • 0
    Только вчера этим занимался :) Спасибо за статью! Ловите плюсик.
  • 0
    Пытался настроить nginx на работу с несколькими сайтами, и столкнулся с проблемой: как предотвратить доступ одного сайта к другому? Т.е. если при Apache используют php open_basedir, то при nginx, это вроде бесполезно. Существуют ли решения этой проблемы, или в этих конфигах уже есть таковое?
    • +1
      Знаю что можно для PHP-fpm каждый процесс PHP запускать от разных юзеров (но на практике не сталкивался).
      • +1
        Надо запускать php-fpm с разными конфиг файлами, где указаны разные php.ini с разными пользователями и разными chroot. Это решение не для массового применения и на мой взгляд — только лишняя трата ресурсов.
        • +1
          разный chroot не обязательно, можно папкам пользователей просто права доступа поставить построже типа rwx r-- ---
          • +1
            Да, конечно. А можно даже спрятать чужие папки sticky-битом. Тут действительно много вариантов. А ключевое выше.
            • +1
              Во, WST извне хабра попросил добавить альтернативный вариант open_basedir для php-fpm

              Суть в том, что запрос передается не пользовательскому скрипту. а скрипту-диспетчеру, который смотрит к какому домену обратились и выставляет соответствующий open_basedir через ini_set, отключает функцию ini_set и инклюдит уже пользовательский скрипт. Вот ссылка: averkov.web.id/articles/admin/nginx/open_basedir/
              • 0
                Интересное решение, хотя и не без изъянов. Спасибо.
  • 0
    Мое имхо: данная статья в блоге PHP не очень смотрится…, ее б в Linux для всех или Системное администрирование
    • +1
      перенес в Системное администрирование
      • 0
        правильно ))
  • +2
    > chmod -R 750 /var/www/example.ru
    лучше заменить на find /var/www/example.ru -type f -exec chmod 640 {} \; && find /var/www/example.ru -type d -exec chmod 750 {} \;
    потому что файлам права на запуск не нужны.
    • +5
      А не проще использовать
      chmod u=rwX,g=rX,o= -Rv /var/www/example.ru
      он будет учитывать каталоги и файлы отдельно.
      chmod соотв. из утилит GNU
  • –2
    Зачем копировать в chroot, если для такого существуют симлинки?
    • 0
      chroot, если вы посмотрите в документацию, по определению не может ходить по симлинкам. Его прямая обязанность оберегать от таких операций.
  • 0
    try_files $uri $uri/ /index.php?q=$uri&$args;

    Выделенное — чушь, не несущая смысловой нагрузки в try_files.

    В случае с:
    location = /favicon.ico {
    log_not_found off;
    access_log off;
    }


    Лучше сделать так:
    • 0
      Пардон,
      location = /favicon.ico {
      empty_gif;
      access_log off;
      }
      • 0
        Это не то будет, в оригинале:
        1) если фавикон есть, то он отдастся, но в лог не запишется
        2) фавикона нет — отдастся 404, но в лог тоже не запишется

        У вас в любом случае отдастся empty.gif
        • +2
          Тогда так:
          location = /favicon.ico {
          try_files $uri @emptygif;
          }
          location @emptygif {
          internal;
          empty_gif;
          }
          • –2
            А собственно зачем его отдавать? :)
            • 0
              Чтобы клиент 404 не получал. Не люблю, знаете ли, красные строчки в фаербаге.
              • 0
                На вкус и цвет… Но идеологически правильно, если файла нет отдавать 404
                • 0
                  С другой стороны, если почти каждый браузер запрашивает favicon.ico и каждый поисковый бот — robots.txt, то идеологически правильно их создать и предоставить.
                  • 0
                    robots.txt — да, favicon.ico рисовать надо — я не умею :( но подсовывать вместо него прозрачный пиксель — извращение, по-моему.
                    • 0
                      favicon generator вам поможет, их много разных сервисов.
          • 0
            Internal в именнованом location не нужен
    • 0
      Почему чушь? Ну ка обоснуй. Неужто все движки сами uri разбирают?
      • 0
        Не путайте try_files и rewrite.
        try_files'у насрать на аргументы — он делает то, что и должен делать с таким названием — пробует найти файлы по списку.
        • 0
          В случае, если ни один файл не найден, то делается внутренний редирект на последний параметр.
        • 0
          а теперь ещё раз читаем по приведённой ссылке и прекращаем умничать
        • 0
          Извиняюсь, я ошибался.
          Действительно работает.
  • +5
    squeeze на дворе. какой нафиг ленни?
    • 0
      Кстати никто не в курсе когда squeeze уже stable будет? судя по wiki вроде как со дня на день.
      • +1
        5-6 февраля. Завтра.
  • +3
    100500-я статья на эту тему…
  • 0
    А можно всё то же самое, но только под Squeeze?
    • +2
      Можно, разрешаю.
  • 0
    Как показала практика в репах очень старый nginx. deb-файлы нужные тоже найти не просто. Приходится компилить из исходников. А тогда уж лучше последний брать. Спросите, а какая разница? Например, я на домашнем серваке поднимал rtorrent в связке с rutorrent, а ему scgi нужен, который есть в nginx, начиная с 0.8.42. Поднимать апача на машине с 512 метрами оперативы, большую часть которой занимают rtorrent и xbmc — не вариант.
    • 0
      packages.debian.org/sid/nginx — Пакет: nginx (0.8.54-3 и другие)

      sysoev.ru/nginx/ — Версию nginx-0.8.54 я рассматриваю как стабильную с точки зрения надёжности.
  • +2
    Если nginx + fpm то где про акселератор загрузки файлов?
  • +3
    При использовании HTTPS в настройки нужно внести некоторые плюшечки:
    # SSL Trick
    fastcgi_param HTTPS on;


    Да, ещё несколько плюшечек нужно внести чтобы корректно работала авторизация…
    # for authentication to work
    fastcgi_param AUTH_USER $remote_user;
    fastcgi_param REMOTE_USER $remote_user;


    А ещё не забываем про проблему .svn и .cvs (.git и т.д. — кто на что богат)

    ПСы: в отличии от автора использую файловые сокеты… Ну, наверное из-за чисто религиозных соображений.

    Собственно, выходит как-то так:
    server {
        listen 10.20.30.40:443;
        server_name mail.mylocal.info;
        access_log /web/http/mail.mylocal.info/logs/access.log;
        error_log  /web/http/mail.mylocal.info/logs/error.log;
    
        # Enable SSL Engine
        ssl                         on;
        ssl_certificate             /etc/nginx/keys/mail.mylocal.info.crt;
        ssl_certificate_key         /etc/nginx/keys/mail.mylocal.info.key;
        ssl_client_certificate      /etc/nginx/keys/ca.crt;
    
        ssl_session_timeout         5m;
        ssl_verify_client           off;
    
        ssl_protocols               SSLv3 TLSv1;
        ssl_ciphers                 AES128-SHA:AES256-SHA:RC4-SHA:DES-CBC3-SHA:RC4-MD5;
        ssl_prefer_server_ciphers   on;
    
        location ~ /.svn/ {
            deny all;
        }
    
        location ~ /.cvs/ {
            deny all;
        }
    
        location ~ ^/.*\.php$ {
            root           /web/http/mail.mylocal.info/httpdocs;
    
            fastcgi_pass    unix:/var/spool/php/mail.sock;
            fastcgi_send_timeout 600;
    
            fastcgi_index  index.php;
            fastcgi_param  SCRIPT_FILENAME    /web/http/mail.mylocal.info/httpdocs$fastcgi_script_name;
            fastcgi_param  CONTENT_TYPE       $content_type;
            fastcgi_param  CONTENT_LENGTH     $content_length;
            fastcgi_param  QUERY_STRING       $query_string;
            # for authentication to work
            fastcgi_param  AUTH_USER          $remote_user;
            fastcgi_param  REMOTE_USER        $remote_user;
            #
            include        /etc/nginx/fastcgi_params;
            # Auth
            auth_basic "Restricted Area";
            auth_basic_user_file /web/http/.passwd-mail.mylocal.info;
            # SSL Trick
            fastcgi_param HTTPS on;
        }
    
        # Root dir
        location / {
            root /web/http/mail.mylocal.info/httpdocs;
            index index.php;
    
            # Auth
            auth_basic "Restricted Area";
            auth_basic_user_file /web/http/.passwd-mail.mylocal.info;
        }
    }
    
    


    • 0
      А в чём проблема .svn и .cvs, .git?
      • 0
        Например тут: SVN: Полгода спустя
        • 0
          Нет слов, как говорится, одни буквы
      • 0
        А в чем надобность делиться ими с посетителями? По-хорошему их на сайт не надо закачивать вообще.
        • 0
          Вот я и удивился, что за проблема — у меня в svn/hg при коммите срабатывает хук, который деплоит на продакшен только то, что нужно (а-ля Капистрано)
        • +1
          проблема не в .svn а в админе.
          если админ выложит на сайт password.txt с паролями — то это проблема не текстового редактора
  • 0
    У меня такой вопрос, на сервере крутится nginx+apache2+php+mysql… и еще несколько игровых серверов. Иногда в браузер Opera «как бы долго думает» перед тем как перейти на нажатую ссылку, тут я не знаю на кого грешить или на роутер, или на браузер или на nginx.

    Если дописать в конфиг: «worker_priority -5; #Увеличитвваем приоритет», nginx сможет быстрее откликаться когда требуется, или будет как обычно? Или не сыграет роли.

    З.Ы. ушел пробовать, но хочу услышать ваше мнение.

    З.Ы2. тут есть подобная статья.
  • 0
    Новайсам: не нужно пытаться запускать /usr/share/phpmyadmin прописав chroot /var/www
  • 0
    на тему уязвимости можно попробовать использовать location ~* \w+\.php$ {, nginx стабильно выдает 404.
  • 0
    Не хватает слеша:

    Нужно location ~ \.php$ {

    Вместо location ~ .php$ {

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.