Gracefully restart Nginx after changes made in a config file

776px-Nginx-battleship.svgI know how to gracefully restart Apache web server under Unix like operating system. I made changes to nginx.conf. How do I gracefully restart Nginx web server? How do I make changes in a Nginx server config file to take effect without restarting the Nginx server itself without interrupting users’ current session?

From the nginx wiki pages

The master process can handle the following signals: TERM, INT Quick shutdown

  • QUIT Graceful shutdown
  • KILL Halts a stubborn process
  • HUP Configuration reload. Start the new worker processes with a new configuration. Gracefully shutdown the old worker processes
  • USR1 Reopen the log files
  • USR2 Upgrade Executable on the fly
  • WINCH Gracefully shutdown the worker processes

The syntax is as follows to

OR find nginx pid with the pgrep command or ps command:

Sample outputs:

Type the following command as root user:

If you are using Nginx version 0.7.53+
Pass the -s reload option:

OR

If you are using Debian / CentOS / RHEL / Fedora / Ubuntu Linux try

If you are using FreeBSD try

If you are using OpenBSD try

OR

How do I reload / gracefully restart chrooted nginx server?
Type the following command:

Защита Apache от DDOS-атак

Пару недель назад позвонил один знакомый и пожаловался, что плохо работает сайт и канал поменяли на FTTX с xDSL и тариф выбрали со скоростью повыше, но помогло мало — пользователи жалуются на HTTP/1.1 403 Forbidden. Сервер настраивал им не я, благо что установлена Ubuntu 10.04 LTS — люблю продукты семейства long time support — очень уж они хорошо. Получив доступ начал ковырять систему — первое что бросилось в глаза — практически пустой фаейр — десятка 2 правил на вход-выход ЛВС и сайта в мир. Набрав в консоли команду

— несколько секунд наблюдал строчки вида:

Сразу стало понятно — что сайт завален большим количеством syn-пакетов, потому так плохо и работает.


Удаленно ковырять файер не гут, потому ограничился минимумом — загнал в конфиг несколько дополнительных команд, заодно ограничил количество syn-пакетов до 500 в секунду, при превышении порога в 1500 — новые пакеты блокируются:

— выполняем с консоли и добавляем в /etc/rc.local на случай перезагрузки:

— добавляем в наш firewall-скрипт:

Портянка netstat стала существенно короче, но в логи все равно периодически выскакивала HTTP/1.1 403 Forbidden. Пришлось поковырять настройки apache2 — оказалось что подгружен mod_evasive — модуль для защиты от DOS/DDOS-атак, в принципе модуль неплохой, но для больших сайтов не годиться, потому решил что лучше его выключить и положиться на файер и настройки ядра, которые я сделал выше. Несколько дней понаблюдал за логами — HTTP/1.1 403 Forbidden выскочила раза 2-3, на том мы и остановились.

Вкратце о том что же за команды такие добавлены в настройки системы:

— tcp_syncookies — SYN cookies не использует очередь SYN, вместо этого ядро отвечает на каждый SYN пакет, как обычно SYN|ACK, но при этом в пакет будет включено специально сгенерированное число на основе IP адресов и портов источника и получателя, а также времени посылки пакета. Соответственно атакующий никогда не получит эти пакеты, а поэтому и не ответит на них. При реальном запросе, будет отправлен третий пакет, который содержащий число, а сервер проверит был ли это ответ на SYN cookie и, если да, то разрешит соединение даже в том случае, если в очереди SYN нет соответствующей записи. (З.Ы.: доступен только когда ядро собрано с CONFIG_SYNCOOKIES — тогда по умолчанию должен быть равен — 1)

— tcp_max_syn_backlog — размер очереди half-open connection (полуоткрытых соединений), по-умолчанию колеблется в диапазоне 1024-2048, лучше задавать от 15000 и выше.

— tcp_synack_retries — определяет сколько разрешено попыток повторной передачи пакетов SYNACK для пассивных соединений TCP. Не должно превышать 255. По-умолчанию значение 5 соответствует приблизительно 180 секундам на выполнение попыток организации соединения. Урезаем примерно до 9 секунд — присваиваем — 1.

— tcp_fin_timeout — определяет время сохранения сокета в состоянии FIN-WAIT-2 после его закрытия локальной стороной. Запрашивающая сторона может не закрыть это соединение никогда, поэтому следует закрыть его по своей инициативе по истечении тайм-аута. По умолчанию тайм-аут составляет 60 секунд, в некоторых старых ядрах linux — было 180 секунд. Если у WEB-сервера очень высокая нагрузкая смело поджимайте до 20-30.

— tcp_keepalive_probes — определяет keepalive-запросов, после которого соединение считается разорванным, По-умолчанию передается 9 запросов. Так как каналы у всех достаточно быстрые — жмем до 5, в принципе проблем не замечено и при 4, но когда из Нижних дыр юзеры лезут по диал-ап — могут быть проблемы.

— tcp_keepalive_intvl — определяет интервал передачи проб. Вычисляется как [tcp_keepalive_probes]*[tcp_keepalive_intvl] — результат дает нам время, по истечении которого соединение будет разорвано при отсутствии откликов. По умолчанию установлен интервал 75 секунд, таким образом разрыв соединения произойдет примерно через 675 секунд (больше 10 минут!!!!).

— netdev_max_backlog — определяет максимальное количество пакетов в очередь на обработку если интерфейс получает пакеты быстрее, чем ядро может их обработать. Для современного железа можно задавать высокие показатели, по-умолчанию 1000.

— somaxconn — определяет максимальное число открытых сокетов, ждущих соединения.

Источник: http://sysadminblog.ru/linux/2012/03/20/zaschita-ot-apache-ot-ddos-atak.html#comment921

Релиз стабильной версии Apache 2.4

Сегодня состоялся релиз стабильной версии http сервера Apache под номером 2.4.1. Первая стабильная версия ветки 2.2 была выпущена в далеком 2005 году. Не смотря на то, что в новом релизе большое множество нововведений он обратно совместим с API версии 2.2.х.

Основные нововведения:

  • Несколько МРМ могут быть собраны в виде динамически загружаемых модулей, которые возможно активировать без пересборки;
  • Модуль Event MPM теперь не является экспериментальным. Event MPM основан на коде модуля Worker и реализует гибридную модель обработки соединений, сочетающую многопоточность с пулом ожидающих соединения процессов;
  • Реализована поддержка асинхронных операций чтения и записи;
  • Директива LogLevel может быть сконфигурирована для каждого модуля и каждой директории отдельно. Поверх отладочного уровня логирования могут быть добавлены новые уровни от trace1 до trace8;
  • Появилась возможность определения через оператор If для блоков конфигурации;
  • Возможно указывать значение параметра KeepAliveTimeout в миллисекундах;
  • Директива NameVirtualHost объявлена устаревшей (deprecated);
  • Директива AllowOverrideList предоставляет более тонкую настройку .htaccess-файлов;
  • Возможность использовать переменные в конфигурационных файлах;
  • Потребление памяти по сравнению с веткой 2.2 снижено.

Новые модули:

  • mod_proxy_fcgi — бэкенд протокола FastCGI для mod_proxy;
  • mod_proxy_scgi — бэкенд протокола SCGI для mod_proxy;
  • mod_proxy_express — динамически конфигурируемые прокси для mod_proxy;
  • mod_remoteip — заменяет адрес IP и имя хоста клиента на запрос с IP-адреса списка представленных прокси или балансировки нагрузки с помощью заголовков запроса;
  • mod_heartmonitor, mod_lbmethod_heartbeat — позволяет mod_proxy_balancer распределять нагрузку основываясь на данных о количестве активных соединений на бэкенд-серверах;
  • mod_sed — улучшенная замена mod_substitute, позволяющая редактировать тело ответа посредством sed;
  • mod_allowmethods — модуль ограничения некоторых методов НТТР без помех для аутентификации и авторизации;
  • mod_lua — внедряет интерпретатор языка Lua в HTTPD для настройки и бизнес-логики;
  • mod_log_debug — позволяет добавлять настраиваемое отладочное логирование на различных фазах обработки запросов;
  • mod_buffer — обеспечивает буферизацию стеков фильтров ввода-вывода;
  • mod_ratelimit — обеспечивает ограничение пропускной способности для клиентов;
  • mod_reflector — обеспечивает отражение тела запроса через стек филтра вывода.

Изменения в модулях:

  • mod_ssl — добавлена поддержка проверки статуса клиентского сертификата на OCSP серверах, а также добавлена возможность совместного использования данных SSL сессии на нескольких http-серверах, через задействование memcached;
  • mod_proxy — значительно увеличена производительность работы директивы ProxyPass в блоках Location и LocationMatch;
  • mod_proxy_balancer — расширено число параметров BalancerMembers, которые можно менять через balancer-manager, добавлена возможность добавления новых параметров BalancerMembers через balancer-manager;
  • mod_cache — может теперь кэшировать запросы HEAD, директивы модуля могут быть установлены на отдельные каталоги, а не только для всего сервера (где это возможно), модуль может предоставлять старые данные из кэша, если сервер недоступен (ошибка 5хх);
  • mod_include — поддержка атрибута OnError в директиве include, что позволяет предоставлять документ ошибки вместо строки ошибки по умолчанию;
  • ]mod_cgi, mod_include, mod_isapi,… — более строгая проверка трансляций заголовков в переменные окружения, что позволяет снизить вероятность XSS-атак через подстановку скриптов в заголовки, теперь такие заголовки будут отбрасываться;
  • mod_authz_core — с помощью директивы Require можно использовать расширенную логику авторизации;
  • mod_ldap, mod_authnz_ldap — добавлена поддержка вложенных групп, улучшения в обработке таймаутов, возможность использования инструментария LDAP для отладки.

Расширения:

  • fcgistarter — новый инструмент запуска демона FastCGI;
  • htcacheclean — с его помощью могут быть указаны кэшируемые URL с опциональными метаданными, объём кэша может быть ограничен в дескрипторах;
  • rotatelogs — может создавать линк на текущий лог-файл.

Средства для разработчиков модулей:

  • Добавлен check_config для проверки конфигурации на ранней стадии загрузки. Он позволяет независимо проанализировать параметры определенных директив и при необходимости откорректировать их;
  • Добавлен парсер выражений общего назначения, API которого основан на ap_expr.h. Код парсера основан на ранее реализованном парсере для mod_ssl;
  • Добавлен интерфейс для кэширование небольших объектов, основанный на ранее созданном для mod_ssl кэше сессионных данных. В качестве хранилища можно использовать цикличный буфер в разделяемой памяти, dbm-базу на диске и memcached;
  • Для мониторинга статуса mod_cache добавлен cache_status, который вызывается после принятия решения о кэшировании. По умолчанию добавляет при ответе заголовки X-Cache в X-Cache-Detail.

Скачать продукт можно на официальном сайте
Список всех изменений в оригинале