nginx

Протокол SSL и его преемник TLS - это криптографические протоколы, предназначенные для обеспечения безопасности сетевых соединений в интернет. Кроме распространенного HTTPS, предназначенного для веб-соединений, они используются и многими другими приложениями. SSLv1 никогда публично не выпускался, SSLv2 быстро оказался небезопасным.

Сервер на CentOS 6, панель ISPManager Lite. После установки через ISPManager, nginx не активируется, в том числе и через командную строку. В логах панели /usr/local/ispmgr/var/pkgctl.log записи:

Feb 18 13:48:24 [ 22115:0] ../../src/mgr/install/pkgctl.cpp:1000 TRACE ip= IP_ADDR 
Feb 18 13:48:24 [ 22115:0] FATAL code=4 Invalid value ip 

Решение прослемы с активацией nginx

Решение оказалось простым до банального.

В предыдущем материале был описан процесс установки и настройки медиа портала mediacore в режиме development.
Сейчас пришло время установить и настроить связку nginx uwsgi mediacore, для работы в production режиме.

Установка веб сервера nginx

Что такое nginx, дкмаю рассказывать никоому не нужно), если он еще не установлен, ставим.
Свежую версию можно получить, добавив репозитарий с официального сайта nginx.
В конец файла /etc/apt/sources.list добавляем:

deb http://nginx.org/packages/debian/ squeeze nginx  

Собственно зачем вообще запрещать доступ к сайту по географическому признаку ? Да просто 80% IP адресов участвующих в ddos атаке, как правило принадлежат странам, жители которых никогда не зайдут на данный сайт, естественно это сугубо индивидуально для каждого ресурса и если вы знаете что часть ваших посетителей приходит из Эфиопии или Чили, блокировать их, вы вряд-ли захотите. У большинства-же моих клиентов, географическое расположение посетителей, как правило ограничивается Европой и бывшим СССР, остальных можно смело игнорировать.

Думаю многие играли или играют или хотя-бы слышали о такой популярной игрухе как Counter Strike. Серверов с этой игрой в сети как грязи нынче.
В общем случилось поднимать игровой сервак + веб морду для модуля статистики Server Stat System.

По работе, периодически приходиться заниматься переносом уже работающих ресурсов с веб сервера Apache на связку nginx - fastcgi, или со старого сервера на новый с уже установленным веб сервером nginx. Ни в коем разе не допускаю мысли, что Apache плохой веб сервер, учитывая количество модулей, он очень универсален, можно решать практически любые задачи, но его монстрообразность предъявляет определенные требования к ресурсам системы.

Итак, имеем веб сервер Nginx в качестве фронтэнда, на бакэндах Apache и какой-нибудь fastcgi (spawn-fcgi или php-fpm). Функциональные возможности серверов, nginx и apache, несколько различаются, и одно из различий как раз в том, что nginx не поддерживает обработку файлов htaccess, которые в apache используются практически повсеместно. Большинство сайтовых движков (CMS), поддерживают возможность генерировать так называемые ЧПУ(человекопонятный урл, в оригинале, SEF - search engines friendly url), но для этого, веб сервер, должен обрабатывать строку запроса определенным образом, что apache и делает с помощью mod_rewrite и правил в файле .htaccess. Задача: заменить правила .htaccess, соответствующими директивами в конфигурационном файле nginx.conf.

301 Moved Permanently, редирект, говорящий что ресурс перемещен на постоянной основе. В интернетах пишут что мол типа архинеобходимо для SEO, мол поисковики это дюже уважают), спорить не буду, не вникал. В веб сервере Nginx 301 редирект настраивается в конфигурационном файле ( в apache можно через файл .htaccess ), таким образом:

Контролируемое скачивание, реализуемое в веб сервере Nginx с использованием заголовка X-Accel-Redirect, подразумевает следующий алгоритм при отдаче контента:

• Клиент нажимает на ссылку "скачать файл"
• Запрос передается веб серверу Nginx
• Nginx в свою очередь передает запрос некоему скрипту на проверку
• Скрипт, после проверки, например валидности запроса на скачивание, возвращает запрос в Nginx, устанавливая заголовок X-Accel-Redirect
• Запрос с заголовком X-Accel-Redirect попадает в специальный внутренний location, сервера Nginx, откуда и отдается клиенту

Код состояния HTTP - это часть строки заголовка, ответа веб сервера на запрос клиента, информирующая о результате запроса и о том, что клиент должен предпринять далее. Думаю не все знают как выглядит заголовок ответа сервера, зато уверен, каждый, пользующийся интернетом, не раз сталкивались, со страницей 404 Not Found или 403 Forbadden. Это и есть, видимый пользователю результат, выдачи сервером, того или иного кода статуса в строке заголовке.

Балансировка нагрузки и отказоустойчивость Nginx, реализуется с помощью специального модуля ngx_http_upstream. Директива upstream позволяют организовывать группы серверов ( upstream ), распределяя между ними запросы для проксирования в директивах proxy_pass и fastcgi_pass. Кроме того, это дает Nginx возможность, реагировать на нештатные ситуации в апстриме, например, в случае выхода из строя одного или нескольких серверов из группы, запрос будет отправлен на следующий, работающий сервер апстрима.

В предыдущей статье "Установка и настройка веб сервера Nginx в качестве проксирующего фронтэнда к Apache", был рассмотрен простой вариант установки и использования Nginx, с настройками по-умолчанию, в качестве проксирующего сервера, с сервером Apache в качестве проксиркемого бакэнда.

В данном материале хотелось-бы рассказать о более сложном варианте установки и настройки Nginx, для построения связки Nginx Apache FastCGI. Для организации FastCGI сервера, будет использована утилиты, spawn-fcgi, ранее входившая в состав веб сервера lighttpd, а теперь выделенная в отдельный порт.

В предыдущей статье, "Веб сервер Nginx, обзор функциональных возможностей", речь шла об основных функциональных возможностях сервера Nginx, а так-же затронут вопрос его использования в качестве проксирующего фронтенд-сервера в связке с веб сервером Apache. Здесь хотелось-бы рассказать о практической стороне вопроса, то есть перейти непосредственно к установке и настройке вышеупомянутой связки, Nginx - Apache. Так как всем остальным *nix системам, я предпочитаю FreeBSD, на ней и будем все это поднимать.

Nginx - небольшой по размерам, очень быстрый, достаточно функциональный веб сервер и почтовый прокси-сервер, разработчик ]]>Игорь Сысоев]]> ( rambler.ru ). Из-за очень маленького потребления ресурсов системы и скорости работы, а так-же гибкости конфигурирования, веб сервер Nginx часто используется в качестве фронтэнда к более тяжеловесным серверам, такими как Apache, в проектах с высокой нагрузкой. Классическим вариантом является связка, Nginx - Apache - FastCGI. Работая в такой схеме, сервер Nginx, принимает все запросы приходящие по HTTP, и в зависимости от конфигурации и собственно самого запроса, решает, обработать-ли запрос самому и отдать клиенту готовый ответ или отправить запрос на обработку, одному из бакэндов ( Apache или FastCGI ).