apache

Leave a comment Posted on Без рубрики

Установка Redmine 2.4.0

Redmine — это информационная система управления проектами с веб интерфейсом (онлайн), включающая в себя полный набор средств для совместной работы над проектами. Система позволяет вести одновременно несколько проектов, отслеживать их состояния, управлять шагами проекта, задачами, приоритетами, гибко назначать роли участникам. Распространяется по лицензии GNU. (Т.е. продукт бесплатен даже для коммерческого использования и не накладывает никаких ограничений на количество пользователей).  Это весомый аргумент для многих клиентов, так как лицензирование является существенной статьей бюджета для многих компаний. Наша компания занимается полным циклом внедрения систем управления проектами и №1 среди них, конечно же Redmine. Мы сами пользуемся этой системой управления проектами уже более 3х лет и она показала себя только с хороших сторон — как производительная, удобная в использовании и настройке и очень дружелюбная к пользователям.

Какие преимущества дает система Redmine и какие задачи она решает?

  • Организует единый центр ведения проектов, программ и портфелей проектов в компании с гибкими настройками ролей участников – один и тот же сотрудник может играть разные роли в разных проектах. Обеспечивается единый стандарт ведения проектов в организации.
  • Позволяет вовлечь участников проекта в процесс, обеспечить визуальное  представление задач, сроков, вех проекта. Все знают, что делать дальше и видят цель.
  • Гибкая отчетность по проектам: кто, что и когда делал, делает и будет делать. Видимость загруженности ресурсов, контроль сроков, история задач. Автоматическое построение диаграммы Ганта и отображения задач на календарном плане.
  • Простота доступа к информации из любой точки, в том числе для географически удаленных сотрудников и подразделений. Возможность доступа заинтересованных лиц, спонсоров и других участников проекта, явно не связанных с выполнением задач, к информации и отчетности в режиме просмотра.
  • Система решает задачу социального взаимодействия в проектах, предоставляя встроенные проектные форумы (средства для обсуждений), доски новостей, базы знаний и возможность комментировать и обсуждать задачи.
  • Возможность настройки продукта на любую предметную область бизнеса, путем введения новых справочников, дополнительных полей к задачам, схем обработки последовательности задач.
  • Инструмент не только для проектного менеджера, но и всех участников проектной команды, предоставляет доступ к проекту всем всегда и везде, в том числе с мобильных устройств.

Redmine — открытое серверное веб-приложение для управления проектами и задачами (в том числе для отслеживания ошибок). Redmine написан на Ruby и представляет собой приложение на основе широко известного веб-фреймворка Ruby on Rails. Распространяется согласно GNU General Public License.

Устанавливаем необходимые библиотеки

[root@localhost]# yum install make gcc gcc-c++ zlib-devel curl-devel openssl-devel httpd-devel apr-devel apr-util-devel mysql-devel
[root@localhost]# yum install zlib zlib-devel openssl-devel sqlite-devel gcc-c++ glibc-headers libyaml-devel readline readline-devel zlib-devel libffi-devel

Скачиваем исходники Ruby

[root@localhost]# cd ~
[root@localhost]# wget http://cache.ruby-lang.org/pub/ruby/2.1/ruby-2.1.5.tar.gz

Распаковываем

[root@localhost]# tar zxvf ruby-2.1.5.tar.gz

Компилируем и устанавливаем

[root@localhost]# cd ruby-2.1.5
[root@localhost]# ./configure
[root@localhost]# make
[root@localhost]# make install

Смотрим версию

[root@localhost]# ruby -v

Устанавливаем passenger:

[root@localhost]# gem install passenger
[root@localhost]# passenger-install-apache2-module

Создаем конфигурационный файл

[root@localhost]# nano /etc/httpd/conf.d/passenger.conf

LoadModule passenger_module /usr/local/lib/ruby/gems/2.1.0/gems/passenger-5.0.4/buildout/apache2/mod_passenger.so
<IfModule mod_passenger.c>
   PassengerRoot /usr/local/lib/ruby/gems/2.1.0/gems/passenger-5.0.4
   PassengerDefaultRuby /usr/local/bin/ruby
</IfModule>

Перезапускаем Apache

[root@localhost]# service httpd restart

Настройки хоста для Apache:

<VirtualHost *:80>
ServerName www.yourhost.com
# !!! Be sure to point DocumentRoot to 'public'!
DocumentRoot /somewhere/public 
<Directory /somewhere/public>
# This relaxes Apache security settings.
AllowOverride all
# MultiViews must be turned off.
Options -MultiViews
# Uncomment this if you're on Apache >= 2.4:
#Require all granted
</Directory>
</VirtualHost>

Качаем Redmine

[root@localhost]# cd ~
[root@localhost]# wget http://www.redmine.org/releases/redmine-2.4.0.tar.gz

Распаковываем

[root@localhost]# tar zxvf redmine-2.4.0.tar.gz

Переносим распакованные файлы в /var/www/html/redmine

[root@localhost]# mv redmine-2.4.0/* /var/www/redmine

Ставим

[root@localhost]# gem install bundle

Меняем владельца директории

[root@localhost]# chown -R apache:apache /var/www/html/redmine

Доустанавливаем библиотеки

[root@localhost]# yum install ImageMagick-devel
[root@localhost]# gem install rmagick -v '2.13.2'

Устанавливаем redmine

[root@localhost]# cd /var/www/redmine
[root@localhost]# bundle install --without postgresql sqlite test development

Настройка подключения к базе

[root@localhost]# mysql -u root -p
mysql> create database redmine character set utf8;
mysqk> grant all privileges on redmine.* to 'redmine'@'localhost' identified by 'redmine';
mysql> flush privileges;
mysql> quit;

Конфигурируем redmine для подключения к базе

[root@localhost]# cd /var/www/html/redmine/config
[root@localhost]# cp database.yml.example database.yml

Открываем database.yml и прописываем логин/пароль от базы

[root@localhost]# nano database.yml

переходим в каталог и доустанавливаем

[root@localhost]# cd /var/www/html/redmine
[root@localhost]# bundle install
[root@localhost]# rake generate_secret_token

Первичное заполнение базы

[root@localhost]# rake db:migrate RAILS_ENV="production"
[root@localhost]# rake redmine:load_default_data RAILS_ENV="production"

Установка плагинов

[root@localhost]# cd /var/www/html/redmine/plugins

# redmine_multiprojects_issue

[root@localhost]# wget https://github.com/nanego/redmine_multiprojects_issue/archive/master.zip
[root@localhost]# unzip masters.zip
[root@localhost]# bundle install
[root@localhost]# rake redmine:plugins:migrate RAILS_ENV=production
[root@localhost]# rm master.zip

# redmine_base_select2

[root@localhost]# wget https://github.com/jbbarth/redmine_base_select2/archive/master.zip
[root@localhost]# unzip masters.zip
[root@localhost]# bundle install
[root@localhost]# rake redmine:plugins:migrate RAILS_ENV=production
[root@localhost]# rm master.zip

# redmine_base_deface

[root@localhost]# wget https://github.com/jbbarth/redmine_base_deface/archive/master.zip
[root@localhost]# unzip masters.zip
[root@localhost]# bundle install
[root@localhost]# rake redmine:plugins:migrate RAILS_ENV=production
[root@localhost]# rm master.zip

Перезапускаем Apache

[root@localhost]# service httpd restart

 

 

Установка Redmine 2.4.0

Leave a comment Posted on Tech articles

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

  kill -HUP $( cat /path/to/nginx.pid )

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

pgrep nginx
ps aux | grep [n]ginx

Sample outputs:

root      4333  0.0  0.4  70776  9352 ?        Ss   Nov24   0:00 nginx: master process /usr/local/nginx/sbin/nginx
nginx     9921  1.0  0.5  70776  9888 ?        S    Dec05  19:24 nginx: worker process
nginx     9922  1.0  0.5  70776 10240 ?        S    Dec05  19:42 nginx: worker process
nginx     9923  0.0  0.4  70776  8724 ?        S    Dec05   0:00 nginx: cache manager process

Type the following command as root user:

kill -HUP 4333

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

# nginx -s reload

OR

# /usr/local/nginx/sbin -s reload

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

# /etc/init.d/nginx reload

If you are using FreeBSD try

# /usr/local/etc/rc.d/nginx reload

If you are using OpenBSD try

# /usr/sbin/nginx -s reload

OR

# /etc/rc.d/nginx reload

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

/usr/sbin/chroot /jail /usr/local/nginx/sbin/nginx -s reload
Leave a comment Posted on Tech articles

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

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

netstat -n --tcp | grep SYN_RECV

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

tcp     0   0 xxx.xxx.xxx.xxx:80    206.192.175.100:1084    SYN_RECV tcp     0   0 xxx.xxx.xxx.xxx:80    206.192.175.100:1228    SYN_RECV tcp     0   0 xxx.xxx.xxx.xxx:80    206.192.175.100:2652    SYN_RECV tcp     0   0 xxx.xxx.xxx.xxx:80    206.192.175.100:3446    SYN_RECV

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


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

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

echo "20000" > /proc/sys/net/ipv4/tcp_max_syn_backlog echo "1" > /proc/sys/net/ipv4/tcp_synack_retries echo "30" > /proc/sys/net/ipv4/tcp_fin_timeout echo "5" > /proc/sys/net/ipv4/tcp_keepalive_probes echo "15" > /proc/sys/net/ipv4/tcp_keepalive_intvl echo "20000" > /proc/sys/net/core/netdev_max_backlog echo "20000" > /proc/sys/net/core/somaxconn

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

iptables -N syn_flood $IPT -A INPUT -p tcp --syn -j syn_flood $IPT -A syn_flood -m limit --limit 500/s --limit-burst 1500 -j RETURN $IPT -A syn_flood -j DROP

Портянка 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

Leave a comment Posted on Tech articles

Релиз стабильной версии 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.

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