При переходе на нового провайдера обнаружил отсутствие доступа к репозиторию WebtaticEL. Роскомнадзор распорядился заблокировать ip адрес webtatic.com c 10.03.2017по инициативе ФНС. Вопрос решён и Россия может дальше пользоваться популярными репозиторием CentOS 7.
Введение
Репозиторий WebtaticEL один из самых востребованных при работе с операционной системой CentOS. Ресурс, как выяснилось, был заблокирован не у всех. О результат моих попыток получить доступ к ресурсу я и расскажу.
Определение блокировки WebtaticEL
Вот так выглядел вывод запроса к ресурсу:
ping -R webtatic.com
= вывод результата =
PING webtatic.com (104.24.6.38) 56(124) bytes of data.
64 bytes from 104.24.6.38: icmp_seq=1 ttl=57 time=16.8 ms
RR: hp.sevo44.loc (192.168.0.3)
192.168.1.106
access-46-228-96-223.kmtn.ru (46.228.96.223)
access-46-42-0-10.kmtn.ru (46.42.0.10)
kmtn.inet2.net (85.112.122.60)
ttk.inet2.net (85.112.122.11)
172.68.8.1
104.24.6.38
104.24.6.38
64 bytes from 104.24.6.38: icmp_seq=2 ttl=57 time=32.7 ms (same route)
64 bytes from 104.24.6.38: icmp_seq=3 ttl=57 time=33.0 ms (same route)
64 bytes from 104.24.6.38: icmp_seq=4 ttl=57 time=19.4 ms (same route)
64 bytes from 104.24.6.38: icmp_seq=5 ttl=57 time=24.0 ms (same route)
64 bytes from 104.24.6.38: icmp_seq=6 ttl=57 time=24.9 ms (same route)
64 bytes from 104.24.6.38: icmp_seq=7 ttl=57 time=23.3 ms (same route)
64 bytes from 104.24.6.38: icmp_seq=8 ttl=57 time=30.6 ms (same route)
64 bytes from 104.24.6.38: icmp_seq=9 ttl=57 time=21.2 ms (same route)
64 bytes from 104.24.6.38: icmp_seq=10 ttl=57 time=26.5 ms (same route)
^C
--- webtatic.com ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9014ms
rtt min/avg/max/mdev = 16.870/25.288/33.085/5.227 ms
ping webtatic.com
= вывод результата =
PING webtatic.com (104.24.6.38) 56(84) bytes of data.
From Filter-gw.transtelecom.net (188.43.30.34) icmp_seq=1 Destination Host Unreachable
From Filter-gw.transtelecom.net (188.43.30.34) icmp_seq=2 Destination Host Unreachable
From Filter-gw.transtelecom.net (188.43.30.34) icmp_seq=3 Destination Host Unreachable
From Filter-gw.transtelecom.net (188.43.30.34) icmp_seq=4 Destination Host Unreachable
From Filter-gw.transtelecom.net (188.43.30.34) icmp_seq=5 Destination Host Unreachable
From Filter-gw.transtelecom.net (188.43.30.34) icmp_seq=6 Destination Host Unreachable
From Filter-gw.transtelecom.net (188.43.30.34) icmp_seq=7 Destination Host Unreachable
^C
--- webtatic.com ping statistics ---
7 packets transmitted, 0 received, +7 errors, 100% packet loss, time
6010ms
Как видите срабатывает фильтр gw.transtelecom.net который и блокирует сайт.
Попытки получить доступ к WebtaticEL
После небольшой игры в футбол с провайдерами я получил ответ:
«104.24.6.38 заблокирован Роскомнадзором, тут уже ничего не поделать.»
Верить на слово я уже давно перестал.
Воспользовавшись сайтом https://rkn.gov.ru/ написал запрос разъяснить мне ситуацию с заблокированным ресурсом. Запрос отправил 14 апреля 2017 года. Наверно действие было поспешно так как можно было сразу проверить самому сайт на наличие блокировки но тут наверно больше был вопрос почему не у всех блокируется.
Параллельно написал письмо на почтовый адрес andy@webtatic.com с информацией о блокировке ресурса в России.
Результат
В понедельник 17 апреля получаю письмо о регистрации моего вопроса в Роскомнадзоре и письма с вопросом о работе ресурса от моего провайдера.
Проверяю:
ping webtatic.com= вывод команды =
PING webtatic.com (138.197.226.254) 56(84) bytes of data.64 bytes from 138.197.226.254: icmp_seq=1 ttl=53 time=129 ms64 bytes from 138.197.226.254: icmp_seq=2 ttl=53 time=123 ms^C64 bytes from 138.197.226.254: icmp_seq=5 ttl=53 time=130 ms--- webtatic.com ping statistics ---3 packets transmitted, 3 received, 0% packet loss, time 4394msrtt min/avg/max/mdev = 123.217/126.370/130.193/2.996 ms
Ресурс Webtatic.com стал доступен.
Вначале я подумал провайдеры произвели какие то действия и ресурс стал доступен, но выяснилось действия предпринял сам WebtaticEL.
Информация WebtaticEL о блокировке в России
Вот перевод статьи опубликованной на webtatic.com 16 апреля 2017 года:
Россия заблокировала доступ (косвенно), сейчас исправлено
В конце прошлого месяца в России начали блокировать Webtatic.com косвенно из-за сторонних онлайн-Валюта сайта, выступающей с одного IP-адреса.
Это сказалось на https://webtatic.com и https://mirror.webtatic.com/ сайты.
Это было связано в cloudflare (услугу cdn), которая, как это и что онлайн-Валюта сайта с помощью обмена IP-адресов через это бесплатный и профессиональный подписки между клиентами. Полный запрет был применен к IP-адресу заблокировать сайт нарушителя.
К сожалению, на cloudflare не удалось решить проблему, и Webtatic был не в состоянии получить новые разблокировали IP-адреса из них.
Благодаря этому, Webtatic больше не использовать сети cdn от cloudflare, а вместо этого перейдет на хостинг сайта в нескольких центрах обработки данных (в качестве репозиториев yum тоже себе сделать).
Posted on Author Andy ThompsonCategories Yum Repository
Видим что блокировка наступила с 10 марта 2017 года и доступ должен быть закрыт всеми провайдерами, что и вызывало моё недоумение.
Почему заблокировали ip адрес а не сам ресурс? Да, оказался на одном сервере с Webtatic.com «не хороший» ресурс и что… Даже написано «ограничивается к сайту», но ip это не сайт. Они к себе такой подход применяли бы… накосячил один и всех в отставку 🙂
Сейчас ресурс Webtatic.com работает на ip 138.197.226.254 который не заблокирован в РКН.
Ответ Роскомнадзора о блокировке webtatic.com
Вот официальное письмо полученное в ответ на мой запрос:
РОСКОМНАДЗОР
УПРАВЛЕНИЕ ФЕДЕРАЛЬНОЙ СЛУЖБЫ
ПО НАДЗОРУ В СФЕРЕ СВЯЗИ, ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ И МАССОВЫХ КОММУНИКАЦИЙ
ПО КОСТРОМСКОЙ ОБЛАСТИ
(Управление Роскомнадзора
по Костромской области)
мкр. Паново, д.36, г.Кострома, 156010
Справочная: (4942) 64 10 41; факс (4942) 64 10 51
E—mail: rsockanc44@rkn.gov.ru
17.04.2017 № 1444-01/44
На № от
О рассмотрении обращения
Долотову А.Н.
Эл. почта: dolotov44@yandex.ru
Уважаемый Алексей Николаевич!
Ваше обращение по вопросу блокировки интернет сайта по адресу https://webtatic.com поступившее в Управление Роскомнадзора по Костромской области с официального сайта Роскомнадзора 17.04.2017 (ID 1061561), рассмотрено.
С 1 ноября 2012 г. вступила в силу статья 15.1 Федерального закона от 27 июля 2006 г. № 149-ФЗ «Об информации, информационных технологиях и о защите информации», касающаяся создания, формирования и ведения Единого реестра доменных имен, указателей страниц сайтов в сети «Интернет» и сетевых адресов, позволяющих идентифицировать сайты в сети «Интернет», содержащие информацию, распространение которой в Российской Федерации запрещено (далее – Реестр запрещенных сайтов).
Получение доступа к полной выгрузке из Реестра запрещенных сайтов предоставляется операторам связи исключительно с использованием квалифицированной электронной подписи, выданной любым удостоверяющим центром, из числа аккредитованных Минкомсвязи России.
Данные о нахождении доменных имен, указателей страниц сайтов в сети «Интернет» и сетевых адресов, позволяющих идентифицировать сайты в сети «Интернет», содержащие информацию, распространение которой в Российской Федерации запрещено, в Реестре запрещенных сайтов можно получить через электронную форму, опубликованную по адресу http://eais.rkn.gov.ru
Для проверки ограничения доступа к сайтам и (или) страницам сайтов сети «Интернет» в рамках исполнения иных положений Федерального закона от 27.07.2006 года № 149-ФЗ «Об информации, информационных технологиях и защите информации», рекомендуем воспользоватьсяуниверсальным сервисом проверки ограничения доступа расположенному по адресу http://blocklist.rkn.gov.ru
В Реестре запрещенных сайтов действительно существует запись с ip‑адресом 104.24.6.38 , который совпадал с адресом хостинга сайта webtatic.com.
На данный момент сайтом webtatic.com приняты меры по устранения негативных последствий от блокировки стороннего ресурса.
Сайт изменил ip адрес хостинга (ip‑адрес 138.197.226.254) и организовал копию сайта доступного по ссылке https://mirror.webtatic.com/ (ip‑адрес 45.55.104.9).
Если сайт webtatic.com у Вас до сих пор недоступен, прошу обратиться в тех. поддержку оператора связи, а в случае непринятия мер по возобновлению доступа направить в наш адрес информацию об этом и договор на оказание телематических услуг связи с оператором связи для принятия к нему административных мер воздействия.
Данное решение, действие (бездействие) Вы вправе оспорить непосредственно в суде или в вышестоящем в порядке подчиненности органе государственной власти.
С уважением,
Руководитель
Документ подписан электронной подписью в системе электронного документооборота Роскомнадзора
СВЕДЕНИЯ О СЕРТИФИКАТЕ ЭП
Кому выдан:
Управление Роскомнадзора по Костромской области
Серийный№:
508663092886826981208179
Кем выдан:
ООО Спецоператор
Срок действия
01.06.2016 — 01.06.2017
С. Л. Корольков
Всё понятно. Осталось уточнить в каких случаях блокируют домен а в каких ip адрес. В каком документе указаны эти правила?
Вывод
В результате всех действий я удовлетворен возможностью опять пользоваться репозиторием WebtaticEL. Повлияло мое письмо в webtatic.com на решение проблемы или нет — не важно. Россия может дальше работать с этим ресурсом — это главное. Можно было послушать провайдера и подождать пока само всё разрешится. Возможно и разрешилось бы без моего участия, а возможно и нет, тут мы не узнаем ответ.
Применим удобное и эффективное средство для защиты сайта от подбора паролей с помощью популярного сервиса Fail2ban. Помогает для защиты от ботов и очень любопытных товарищей. Заблокируем назойливых роботов на уровне VDS хостинга.
Введение
Рано или поздно ваш сайт будут пробовать на прочность всякие роботы. Если движок сайта свободный, то роботы начинают проверять вас на прочность сразу.
Все бесплатные движки всегда надо обновлять и внимательно относиться ко всем дополнениям что устанавливайте. Обязательно держите резервные копии и тогда даже взлом не страшен.
Меня начали проверять почти сразу. Пользуясь случаем хочу передать привет товарищу Токарчуку Александру Степановичу с IP адреса которого упорно хотели попасть в админку моего сайта. Почему то пытаются войти, в моем случае, как правило с Украины.
Советую сразу смените путь к админке сайта с помощью iThemes Security. По умолчанию путь в WordPress домен/wp-admin и именно сюда все боты и лезут… Поленился я сразу сменить и боты стали ломится каждую минуту и причем в своем большинстве используя Российские ip адреса. Путь сменил, но они всё равно ломятся по стандартному пути…
Ошибка входа в админку
Для того чтобы понять пытаются к нам войти или нет надо посмотреть логи сайта. Если логи настроены правильно, то вы увидите все действия что происходят с вашим сайтам и ни одно событие не останется без внимания.
Посмотрим как выглядит лог неудачной попытки авторизации на популярном движке WordPress:
Согласно этим строчкам 2 раза неудачно авторизовались.
iThemes Security для WordPress
Для популярного движка WordPress существует свободный плагин iThemes Security для защиты сайта. Не буду останавливаться на рассмотрении настройки, покажу лишь как он показывает ошибки авторизации.
Согласно этих данных видим что регулярно производится по 2 попытки авторизации к административной панели сайта.
При нажатии на ip мы увидим информацию о координатах этого адреса:
У меня как обычно Украина. Нажмем на ISP: PP SKS-Lugan и увидим более детальную информацию:
Можно делать с этой информацией всё что угодно и тут всё в вашей власти.
Моя задача сделать так чтобы данные пользователи блокировались для всего моего VDS хостинга, а не только для сайта работающего на WordPress c защитой iThemes Security. Для этого и надо настроить Fail2ban.
Настройка Fail2ban
Установка
Устанавливать и настраивать будем для системы CentOS 7, хотя и для других систем, с учетом специфики операционной системы, данное описание подойдёт.
Установим:
yum install fail2ban
Конфигурационный файл настройки находится здесь — /etc/fail2ban/jail.conf, но, как сказано в комментариях файла, данный файл рекомендуется не изменять.
Чтобы при обновлении Fail2ban не удалялись наши настройки создадим локальную копию файла, именно с него и будет работать наша система защиты.
Отправка почты на внешний e-mail адрес
Настроим чтобы письма root пересылались на нужную нам внешнюю e-mail почту.
Открываем файл /etc/aliases и внесем изменения:
mcedit /etc/aliases
=необходимые изменения=
# Person who should get root's mail
root:info@sevo44.ru
Применим изменения выполнив команду:
newaliases
Отправим тестовое сообщение выполнив команду:
echo «test» | mail -s Testmail root
Если в выводе будет -bash: mail: команда не найдена то надо установить пакет:
= Для CentOS =
yum install mailx
= Для Debian =
apt-get install mailutils
Если на указанную почту пришло сообщение где в теле письма «test», то значит всё хорошо и теперь все сообщения что система создает для root будут переправлены на вашу почту.
Обязательно проверьте спам почты. Если в спаме нет то смотрите логи отправки почты. Всегда использую почтовый сервис yandex.ru и проблем с ними нет.
В случае если письмо не пришло то надо идти в файл лога и смотреть что там не так. В моем случае лог выглядит так:
cat /var/log/maillog
= вывод команды с необходимыми значениями =
Apr 10 22:57:03 ih378645 postfix/smtp[29844]: D56B64957: to=<info@sevo44.ru>, orig_to=<root>, relay=mx.yandex.ru[87.250.250.89]:25, delay=0.57, delays=0.02/0/0.03/0.52, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued on mxfront10g.mail.yandex.net as 1491854223-b3qP5cuV0Mf-v2CaUBlk)
Работа с почтой Postfix
Перестала приходить почта от f2b о блокировке желающих войти в админку сайта.
Вот количество ip которое стремительно увеличивалось:
В логах обнаружил сообщение о превышении лимита на отправку сообщений:
cat /var/log/maillog
= вывод команды с необходимыми значениями =
May 5 12:48:32 ih378656 postfix/smtp[12576]: 3111D5EE9: to=<dolotov44@yandex.ru>, orig_to=<root@localhost>, relay=mx.yandex.ru[93.158.134.89]:25, conn_use=23, delay=12862, delays=12859/3.1/0.07/0.06, dsn=4.5.1, status=deferred (host mx.yandex.ru[93.158.134.89] said: 451 4.5.1 The recipient <dolotov44@yandex.ru> has exceeded their message rate limit. Try again later. 1493977712-W6SydoLQur-mWE8thiK (in reply to end of DATA command))
May 5 12:48:32 ih378656 postfix/smtp[12563]: 2E9A05F20: host mx.yandex.ru[87.250.250.89] said: 451 4.5.1 The recipient <dolotov44@yandex.ru> has exceeded their message rate limit. Try again later. 1493977712-LwxkdR0eGu-mWD4A8YU (in reply to end of DATA command)
Посмотрим количество сообщений в очереди postfix:
mailq | grep Request
= вывод команды =
-- 5811 Kbytes in 1888 Requests.
Файл настройки большой, поэтому я покажу только настройки что я менял. Откроем файл и внесем нужные исправления и добавления:
mcedit /etc/fail2ban/jail.local
= вывод команды с необходимыми изменениями =
# "bantime" это количество секунд запрета
# 1 week = 604800
bantime = 604800
# Время работы параметра "maxretry"
# seconds.
findtime = 600
# "maxretry" количество попыток до бана
maxretry = 3
#
# ACTIONS
#
# Действия при срабатывании правил.
# Адрес электронной почты получателя
destemail = root@localhost
# Адрес отправителя
sender = f2b
# Выбрать действие по умолчанию. Чтобы изменить, просто переопределить значение 'действие' s
# Всего 3 вида действия
# action_ только запрет
# action_mw запретить и отправить по электронной почте с whois доклад destemail
# action_mwl запретить и отправить по электронной почте с whois отчет и соответствующие строки журнала
action = %(action_mwl)s
# Свои фильтры для защиты
# Название блока используемое при работе с сервисом
[sites-sevo44ru]
# Включение правила
enabled = true
# Какие порты блокируются
port = http,https
# Название файла фильтра
filter = sites-sevo44ru
# Путь до лог файла который анализируется
logpath = /web/sites/sevo44.ru/log/access.log
# Количество неудачных попыток до блокировки
maxretry = 3
# Период блокировки -- вечная. Иногда лучше использовать и такое :)
#bantime = -1
Обращаю особое внимание на строку action = %(action_mwl)s. Если хотите получать оповещения на почту обязательно правильно укажите этот параметр и настройте оповещение на необходимый почтовый ящик.
Мне пришлось отключить отправку сообщений на почту. Про перезагрузке сервиса на почту приходят сообщения о всех заблокированных ip. При большом количестве блокировок почтовый ящик на yandex отказывается их принимать. Если кто может подсказать как решить эту проблему подскажите.
Если укажите чтобы на почту приходила информация с whois докладом в письме можете увидеть missing whois program установите необходимое выполнив команду:
yum install jwhois
Теперь в сообщениях на почту будет приходить детальная информация об ip адресе блокируемого.
Файл фильтра
Создадим файл фильтра в необходимой папке с указанием нужных параметров:
Можно в новой строчке перечислять любые необходимые параметры.
В одном из фильтров я использую код ^<HOST> .*base64_decode который блокирует всех кто пытается использовать эту кодировальную хренодрянь.
Проверим наш фильтр выполнив команду:
fail2ban-regex /web/sites/sevo44.ru/log/access.log /etc/fail2ban/filter.d/sites-sevo44ru.conf
= вывод информации =
Running tests
=============
Use failregex filter file : sites-wpsevo44ru, basedir: /etc/fail2bаn
Use log file : /web/sites/wp.sevo44.ru/log/access.log
Use encoding : UTF-8
Results
=======
Failregex: 309 total
|- #) [# of hits] regular expression
| 1) [309] ^<HOST> .* "POST /wp-login.php
`-
Ignoreregex: 0 total
Date template hits:
|- [# of hits] date format
| [77612] Day(?P<_sep>[-/])MON(?P=_sep)Year[ :]?24hour:Minute:Second(?:\.Microseconds)?(?: Zone offset)?
`-
Lines: 77612 lines, 0 ignored, 309 matched, 77303 missed
[processed in 16.01 sec]
Missed line(s): too many to print. Use --print-all-missed to print all 77303 lines
Видим что в нашем логе 309 срабатываний правила.
Можно вывести информация обо всех этих строчках:
fail2ban-regex /web/sites/wp.sevo44.ru/log/access.log /etc/fail2ban/filter.d/sites-wpsevo44ru.conf --print-all-matched
= вывод информации =
Running tests
=============
Use failregex filter file : sites-wpsevo44ru, basedir: /etc/fail2ban
Use log file : /web/sites/sevo44.ru/log/access.log
Use encoding : UTF-8
Results
=======
Failregex: 309 total
|- #) [# of hits] regular expression
| 1) [309] ^<HOST> .* "POST /wp-login.php
`-
Ignoreregex: 0 total
Date template hits:
|- [# of hits] date format
| [77618] Day(?P<_sep>[-/])MON(?P=_sep)Year[ :]?24hour:Minute:Second(?:\.Microseconds)?(?: Zone offset)?
`-
Lines: 77618 lines, 0 ignored, 309 matched, 77309 missed
[processed in 15.31 sec]
|- Matched line(s):
| 185.34.244.250 - - [05/Mar/2017:13:11:24 +0300] "POST /wp-login.php HTTP/2.0" 200 2208 "https://sevo44.ru/wp-login.php?redirect_to=https%3A%2F%2Fsevo44.ru%2Fwp-admin%2F&reauth=1" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36" "2.27"
| 185.34.244.250 - - [05/Mar/2017:13:11:30 +0300] "POST /wp-login.php HTTP/2.0" 302 955 "https://sevo44.ru/wp-login.php" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36" "-"
= часть информации скрыта =
После последующих необходимых изменениях перезагружаем стандартной для CentOS 7 командой:
systemctl restart fail2ban
После перезагрузки на почту будут приходить сообщения об остановке, запуске всех работающих фильтров и всех заблокированных ip.
Для полной уверенности посмотрим статус:
systemctl status fail2ban
● fail2bаn.service - Fail2Bаn Service
Loaded: loaded (/usr/lib/systemd/system/fail2bаn.service; enabled; vendor preset: disabled)
Active: active (running) since Пн 2017-04-10 23:23:47 MSK; 2min 20s ago
Docs: man:fail2ban(1)
Process: 30794 ExecStop=/usr/bin/fail2bаn-client stop (code=exited, status=0/SUCCESS)
Process: 30830 ExecStart=/usr/bin/fail2bаn-client -x start (code=exited, status=0/SUCCESS)
Main PID: 30834 (fail2ban-server)
CGroup: /system.slice/fail2bаn.service
└─30834 /usr/bin/python2 -s /usr/bin/fail2bаn-server -s /var/run/fail2ban/fail2bаn.sock -p /var/run/fail2ban/fail2bаn.pid -x -b
апр 10 23:23:46 ih378645.vds.myihor.ru systemd[1]: Starting Fail2Ban Service...
апр 10 23:23:47 ih378645.vds.myihor.ru fail2ban-client[30830]: 2017-04-10 23:23:47,141 fail2bаn.server [30832]: INFO Starting ...v12.45.668
апр 10 23:23:47 ih378645.vds.myihor.ru fail2ban-client[30830]: 2017-04-10 23:23:47,141 fail2bаn.server [30832]: INFO Starting ...n mode
апр 10 23:23:47 ih378645.vds.myihor.ru systemd[1]: Started Fail2Ban Service.
Hint: Some lines were ellipsized, use -l to show in full.
Всё у нас хорошо. Работает и стартует при перезагрузке сервера.
Главный файл настройки
В главном файле настройки указывается куда будут складываться логи и другие параметры. Нам важно убедится в правильности пути до лог файлов. Откроем и посмотрим куда пишутся логи:
cat /etc/fail2ban/fail2ban.conf
= вывод команды с пояснениями =
# Где лежат логи
logtarget = /var/log/fail2ban.log
Ротация логов сервиса
Откроем файл ротации сервиса и сделаем необходимые изменения:
Мне удобней чтобы ротация проходила каждый день и хранилась 30 дней.
Сохраним и применим изменения без перезагрузки:
logrotate /etc/logrotate.conf
Работа с сервисом
Выведем информацию о работающих фильтрах:
fail2ban-client status
= вывод команды =
Status
|- Number of jail: 1
`- Jail list: sites-sevo44ru
Видим что активен один фильтр.
Выведем детальную информацию о фильтре:
fail2ban-client status sites-sevo44ru
= вывод команды =
Status for the jail: sites-sevo44ru
|- Filter
| |- Currently failed: 0
| |- Total failed: 4
| `- File list: /web/sites/sevo44.ru/log/access.log
`- Actions
|- Currently banned: 1
|- Total banned: 4
`- Banned IP list: 92.53.96.68
Видим что всего было 4 срабатывания и 1 IP что заблокирован.
Для ручного блокирования используем команду:
fail2ban-client set sites-sevo44ru banip 91.200.12.91
= вывод команды =
91.200.12.91
Для ручного разблокирование используем команду:
fail2ban-client set sites-sevo44ru unbanip 91.200.12.91
= вывод команды =
91.200.12.91
Осталось окончательно убедится что сервис работает. Посмотрим текущие правила iptables:
iptables -L -v -n
= вывод команды. только интересующая нас часть =
Chain f2b-sites-sevo44ru (1 references)
pkts bytes target prot opt in out source destination
0 0 REJECT all -- * * 91.200.12.91 0.0.0.0/0 reject-with icmp-port-unreachable
0 0 REJECT all -- * * 92.53.96.68 0.0.0.0/0 reject-with icmp-port-unreachable
18949 3413K RETURN all -- * * 0.0.0.0/0 0.0.0.0/0
Всё отлично. В выводе команды видим заблокированные ip адреса.
Результат
Хочется вам или нет, но периодически необходимо просматривать логи сайтов. Только так можно вовремя выявить проблемные места с сайтом и вовремя отреагировать на паразитирующую активность всякой интернет шушары. Хочется сразу сказать что иногда можно не успеть вовремя среагировать и ресурс будет взломан но для этого случая всегда держите в сохраняемости актуальные резервные копии сайта.
Virtual Hosts или добавление виртуального хоста на web-сервере под управлением NGINX для операционной системы CentOS 7. Возможность добавлять виртуальные хосты позволяет запускать несколько web-сайтов на одном физическом сервере. Рассмотрим основные моменты создания.
Введение
Начальную настройку Nginx в операционной системе CentOS 7 мы произвели в статье NGINX на web сервер CentOS 7. Все дальнейшие действия будем производить с учетом этой информации.
Не буду в качестве примера рассматривать установку какого либо движка сайта. Действия при добавлении виртуальных хостов для всех движков сайтов одинаковые! Настройка для конкретного движка это отдельная тема. Необходимую информацию вы всегда сможете найти в документации по нужному движку сайта.
Структура каталогов
Первое что необходимо сделать для последующей работы с web-сервером, это определится со структурой каталогов где будут лежать данные сайтов. В моем случае папка с данными сайта будет называться sevo44.ru по аналогии с доменным именем. Название папки может быть любое. В конфигурационном файле nginx прописывается путь до необходимой папки.
В моем случае структура выглядит так:
web — папка в корне сервера,
web/sites — папка где лежат все виртуальные хосты (сайты),
web/sites/sevo44.ru — папка где лежат файлы конкретного сайта,
web/sites/sevo44.ru/www — папка с файлами сайта,
web/sites/sevo44.ru/log — папка с логами сайта.
Создадим всю структуру выполнив команду в консоли:
Не забываем дать нужные права для файлов сайта! Это действие нужно выполнять каждый раз как только вы добавляете файлы не из под пользователя nginx!
Дадим необходимые права на созданные каталоги:
chown -R nginx:nginx /web/sites/sevo44.ru
Данные на месте. Осталось создать файл настройки для Nginx в котором будут указаны все параметры работы с сайтом.
Обработка сессий PHP
Без создания этой папки с необходимыми правами для Nginx, данные сайтов могут не обрабатываться и будет показана ошибка при попытке просмотра сайта с браузера.
Создадим необходимую папку с нужными правами:
cd /var/lib/php/
mkdir session
chown nginx:nginx session/
Virtual Hosts для NGINX
Настройка Virtual Hosts в Nginx подразумевает два варианта указания настроек для виртуальных сайтов:
Все правила для сайтов писать в конфигурационном файле /etc/nginx/nginx.conf,
Создать для каждого виртуального сайта свой файл в /etc/nginx/conf.d с названием имя сайта.conf.
Мне удобней работать с файлами настроек для каждого сайта. Чтобы такая возможность была необходимо в главном файлеприсутствие строки include /etc/nginx/conf.d/*.conf.
В создаваемом файле я намеренно не стал убирать некоторые строчки которые в последствии нам понадобятся для перевода сайта на сертификат ssl.
Как вы уже заметили логи для каждого сайта будут находится для каждого созданного виртуального хоста отдельно, что упрощает поиск и определение ошибок при работе.
Для всех своих сайтов я произвожу ротацию логов раз в сутки. Создадим файл для ротации где будем указывать все наши сайты:
Теперь каждый день файлы будут ротироваться и мы сможем просматривать логи за каждый день.
Результат
Настроили Virtual Hosts для Nginx с базовыми параметрами подходящими под большинство сайтов. Не так давно я стал использовать Nginx, но уже сейчас могу точно сказать, что работает он стабильно и очень шустро. Конечно есть некоторые неудобство, после перехода с Apach, но это лишь годами выработанная привычка.
Рассмотрим как установить и настроить последнюю версию PhpMyAdmin из исходных данных. Web сервер работает под управлением Nginx. Пожалуй это самый востребованный сервис для веб разработчиков.
Введение
В этой статье мы установим из исходников PhpMyAdmin работающий на веб сервере под управлением Nginx.
Во всех система можно установить этот пакет из репозиториев, но к сожалению версии там не всегда последние и бывают проблемы с настройкой. Вариант установки из исходников универсальный и подойдет практически для любой системы.
В данном примере за основу взять вариант настройки на системах CentOS.
Перед тем как устанавливать PhpMyAdmin необходимо что бы в системе были установлены сервисы Nginx, PHP и MariaDB.
Ссылки на статьи в который вы узнаете как можно настроить всё необходимое:
Дадим необходимые права для Nginx на все папки и файлы:
chown -R nginx:nginx /var/www/pma.sevo44.ru
Все данные готовы! Дальше необходимо настроить Nginx для работы PhpMyAdmin.
Настройка Nginx для PhpMyAdmin
Конфигурационый фал Nginx показан с учетом настройки сервисов PHP и Nginx описаных на данном сайте.
Для начала нам необходимо определится с доменным именем, на котором будет работать наша система управления базами данных. В нашем случае используется домен sevo44, где по адресу pma.sevo44.ru и будет работать PhpMyAdmin.
Конфигурационный файл pma.sevo44.ru.conf, для домена третьего уровня создаем в папке /etc/nginx/conf.d/ со следующим содержанием:
Обращаю внимание на то что в файле закоментированы параметры которые позволяют работать PhpMyAdmby c использованием сертификата ssl. Узнать про то как можно настроить работу сайта в защищеном режиме можно из статьи SSL бесплатный для сайта Nginx.
Создаем файл с логином и паролем для доступа:
=== Команда которая создаст пользователя pma ===
sh -c "echo -n 'pma:' >> /etc/nginx/.htpasswd"
=== Команда для создания пароля пользователю pma ===
sh -c "openssl passwd -apr1 >> /etc/nginx/.htpasswd"
= Вывод команды с пояснениями =
Password: пароль
Verifying - Password: повтор пароля
Проверим на правильность настройки и перезагрузим Nginx:
nginx -t
= вывод команды =
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
nginx -s reload
Настройка ротации логов
Все файлы правил для ротации находятся в папке /etc/logrotate.d. добавим туда необходимый нам файл с нужными параметрами:
vim /etc/logrotate.d/pma-sevo44
= необходимые данные для внесения =
/web/sites/pma.sevo44.ru/log/*.log {
daily
missingok
rotate 52
compress
delaycompress
notifempty
create 640 nginx adm
sharedscripts
postrotate
if [ -f /var/run/nginx.pid ]; then
kill -USR1 `cat /var/run/nginx.pid`
fi
endscript
}
Сохраним и применим изменения без перезагрузки:
logrotate /etc/logrotate.conf
По такому принципу настраивается ротация для любых данных, но обычно этот механизм настраивают для логов, хотя он может работать и с другими файлами.
Настройка папки для хранения сессий PHP
Без наличия этой папки с необходимыми правами для Nginx, данные не будут обрабатываться, о чем будет показывать страница с ошибкой при попытке зайти по адресу http://pma.sevo44.ru.
phpMyAdmin — Error
Error during session start; please check your PHP and/or webserver log file and configure your PHP installation properly. Also ensure that cookies are enabled in your browser.
session_start(): open(SESSION_FILE, O_RDWR) failed: No such file or directory (2)
Проверим наличие папки с нужными правами:
=== Переходим в папку ===
cd /var/lib/php/
=== Проверяем наличие и если нет создаем папку ===
ls
= Вывод команды =
opcache peclxml session wsdlcache
mkdir session
=== Назначаем нужны права ===
chown nginx:nginx session/
Предварительная подготовка закончена и осталось лишь настроить сам PhpMyAdmin.
Создание файла config.inc.php для PhpMyAdmin
Вариантов создать файл настроек несколько:
Переименовать файл config.sample.inc.php в config.inc.php и отредактировать параметры под свои нужды,
Средствами самого PMA войдя в панели управления под root.
Для меня оптимален второй вариант, так как он нагляден и после настройки блокирует механизм повторной попытки создать файл настроек.
После авторизации под пользователем root, который мы указали при настройке MariaDB, внизу мы увидим сообщение говорящее о необходимости выполнить действия для настройки.
Вначале разберемся с первым сообщением. Как и написано переходим в любую базу. Выберем базу mysgl в меню слева.
Жмем «Узнать причину» почему нет хранилища.
Нажимаем «Создать» и выполнятся все необходимые действия.
Теперь непосредственно создадим средствами панели управления PhpMyAdmin файл настроек config.inc.php.
Переходим по меню сверху «Настройки» и видим блок.
Нажимаем «Скрипт настройки»
Создаем сервер localhost, выбираем язык, и конец строки. Можете пройтись по остальным настройкам и указать всё на свой вкус и цвет.
Смотри результат настроек.
Скачиваем себе файл, закидываем в корневую папку PhpMyAdmin. Откроем посмотреть как он выглядит:
Последнее что нам осталось сделать, это дать права Nginx для этого файла. Так как все файлы должны иметь владельца Nginx повторим команду команду которую делали ранее:
chown -R nginx:nginx /var/www/pma.sevo44.ru
Настройка закончилась и теперь при попытке повторно создать этот файл будет выскакивать сообщение:
Один PhpMyAdmin для разных серверов
Обна из удобных возможностей программы это возможность имея одну версию подключатся к базам данных работающих на разных серверах.
В конфигурации выше был указан следующий код который отвечает за возможность подключатся к удаленым базам данных:
/* Server: wp [2] */
$i++;
$cfg['Servers'][$i]['verbose'] = 'wp'; - отображение в меню выбора$cfg['Servers'][$i]['host'] = '10.10.0.3'; - ip сервера с убаленой db
$cfg['Servers'][$i]['port'] = '';
$cfg['Servers'][$i]['socket'] = '';
$cfg['Servers'][$i]['auth_type'] = 'cookie';
$cfg['Servers'][$i]['user'] = '';
$cfg['Servers'][$i]['password'] = '';
Для реализации этой возможности необходимо сделать еще две вещи:
Добавить параметр bind-address=0.0.0.0 в конфигурационном файле самого сервера баз MariaDB разрешающий подключатся с любого адреса (или укажите конкретный IP) в разделе [mysqld] ;
Сделать необходимые права для пользователя баз данных.
Установим и настроим web сервер на базе операционной системы CentOS 7 со связкой Nginx, MariaDB и PHP. Коротко такая связка функционала называется LEMP и дает возможность работать с сайтами использующими эти технологии.
Введение
Долгое время лидирующие позиции занимал Apach, но новый продукт кардинально изменил подход к обработке команд и позволяет обслуживать высоконагруженные сайты на бюджетном железе. Более детально узнать про автора Игоря Сысоева и ознакомится с принципами работы вы можете на просторах сети интернет. От себя лишь скажу что теперь это моя основная и любимая связка при организации веб сервера по причине быстроты и удобства работы.
Компоненты web сервера
Для работы с веб сайтом как правило необходимо иметь три компонента.
Nginx — по сути это и есть сам веб сервер который будет обрабатывать все запросы и выдавать информацию пользователям,
MariaDB — база данных в которой будут хранится данные сайтов. MariaDB ответвление от популярной mysql и полностью с ней совместима,
PHP — язык программирования, который чаще всего применяется веб разработчиками.
Теперь обо всех этих компонентах расскажу подробно.
Дальнейшие действия производим с учетом начальной настройки сервера CetnOS 7 на Айхор Хостинге. Все действия будут правильны для других хостингов и серверов где необходимо развернуть данный функционал на операционной системе CentOS 7.
Настройка FirewallD
Установка и настройка
Проверим наличие firewalld:
systemctl status firewalld
= вывод команды =
Unit firewalld.service could not be found.
Если устанавливали с минимальной версии CentOS то Firewalld там не установлен.
Где убрать этот параметр решать вам. Мой выбор это комментирование параметра в файле /etc/nginx/nginx.conf.
Перезагружаем сервер:
reboot
Проверяем:
systemctl status nginx
= вывод команды =
● nginx.service - nginx - high performance web server
Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; vendor preset: disabled)
Active: active (running) since Чт 2017-04-13 23:33:19 MSK; 8s ago
Docs: http://nginх.org/en/docs/
Process: 1386 ExecStop=/bin/kill -s QUIT $MAINPID (code=exited, status=0/SUCCESS)
Process: 1368 ExecReload=/bin/kill -s HUP $MAINPID (code=exited, status=0/SUCCESS)
Process: 1390 ExecStart=/usr/sbin/nginx -c /etc/nginх/nginх.conf (code=exited, status=0/SUCCESS)
Process: 1389 ExecStartPre=/usr/sbin/nginх -t -c /etc/nginх/nginх.conf (code=exited, status=0/SUCCESS)
Main PID: 1394 (nginx)
CGroup: /system.slice/nginх.service
├─1394 nginх: master process /usr/sbin/nginх -c /etc/nginх/nginх.conf
└─1395 nginх: worker process
апр 13 23:33:19 ih378645.vds.myihor.ru systemd[1]: Starting nginх - high performance web server...
апр 13 23:33:19 ih378645.vds.myihor.ru nginх[1389]: nginх: the configuration file /etc/nginх/nginх.conf syntax is ok
апр 13 23:33:19 ih378645.vds.myihor.ru nginx[1389]: nginx: configuration file /etc/nginх/nginх.conf test is successful
апр 13 23:33:19 ih378645.vds.myihor.ru systemd[1]: Started nginх - high performance web server.
Видим что всё у нас хорошо. Сервис работает и стартует при перезагрузке.
Для окончательной проверки мы можем набрать в браузере http://ip сервера и увидеть приветственное сообщение.
Файлы для настройки
Все необходимые нам файлы для настройки находятся в папке /etc/nginx. По умолчанию корневая папка находится по пути usr/share/nginx/html и именно оттуда берется приветственное сообщение.
Работать мы будем с виртуальными сайтами и тут есть два варианта работы:
Все правила для сайтов писать в конфигурационном файле /etc/nginx/nginx.conf,
Создать для каждого виртуального сайта свой файл в /etc/nginx/conf.d с названием имя сайта.conf.
Мне удобней работать с файлами настроек для каждого сайта. Чтобы такая возможность была необходимо в главном файлеприсутствие строки include /etc/nginx/conf.d/*.conf.
Настройка nginx.conf
Сделаем резервную копию оригинала файла главных настроек Nginx:
Основное и главное отличие в работе по сравнению с Apach, это то что Nginx не работает с файлами .htaccess.
Ниже приведу пример настройки моего конфигурационного файла с пояснениями:
cat /etc/nginx/nginx.conf
= вывод команды с пояснениями =
# nginx version:1.14.0
# Пользователь и группа, от имени которых будет запущен процесс
user nginx nginx;
# Число воркеров в новых версиях рекомендовано устанавливать параметр auto
worker_processes auto;
# Уровни лога debug, info, notice, warn, error, crit, alert или emerg
# перечислены в порядке возрастания важности. При установке определённого уровня
# в лог попадают все сообщения указанного уровня и уровней большей важности.
# Например, при стандартном уровне error в лог попадают сообщения уровней error, crit, alert и emerg.
# Если параметр не задан, используется error.
error_log /var/log/nginx/error.log warn;
# Файл в котором будет храниться идентификатор основного процесса
# указывать если нет параметра в сервисе!
#pid /var/run/nginx.pid;
events {
# Максимальное количество соединений одного воркера
worker_connections 1024;
# Метод выбора соединений (для FreeBSD будет kqueue)
use epoll;
# Принимать максимально возможное количество соединений
multi_accept on;
}
http {
# Отключить вывод версии nginx в ответе
server_tokens off;
# Указываем файл с mime-типами и указываем тип данных по-умолчанию
include /etc/nginx/mime.types;
default_type application/octet-stream;
# Формат для лога доступа и путь к файлу
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log main;
# Метод отправки данных sendfile эффективнее чем read+write
sendfile on;
# Ограничивает объём данных, который может передан за один вызов sendfile().
# Нужно для исключения ситуации когда одно соединение может целиком захватить воркер
sendfile_max_chunk 128k;
# Отправлять заголовки и начало файла в одном пакете
tcp_nopush on;
tcp_nodelay on;
# Параметр задаёт таймаут, в течение которого keep-alive соединение с клиентом не будет закрыто со стороны сервера
keepalive_timeout 65;
# Сбрасывать соединение если клиент перестал читать ответ
reset_timedout_connection on;
# Разрывать соединение по истечению таймаута при получении заголовка и тела запроса
client_header_timeout 3;
client_body_timeout 5;
# Разрывать соединение, если клиент не отвечает в течение 3 секунд
send_timeout 3;
# Задание буфера для заголовка и тела запроса
client_header_buffer_size 2k;
client_body_buffer_size 256k;
# Ограничение на размер тела запроса
client_max_body_size 12m;
# Включение сжатия GZIP
# Если используется NGINX proxy надо настраивать на нём!!!
#gzip on;
#gzip_static on;
#gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript image/x-icon image/svg+xml application/x-font-ttf;
#gzip_comp_level 9;
#gzip_proxied any;
#gzip_min_length 1000;
#gzip_disable "msie6";
#gzip_vary on;
# Подключение дополнительных конфигов
include /etc/nginx/conf.d/*.conf;
}
Настройка default.conf
В папке conf.d находится файл default.conf в настройках которого и указаны параметры приветственной странницы, что нам показал запрос на ip адрес сервера. В случае неправильно указанного адреса будет показано именно это приветствие. Вы можете подправить файлы, пути до которых указанны в нём, по своему желанию.
cat /etc/nginx/conf.d/default.conf
= вывод команды с необходимыми изменениями =
server {
listen 80;
server_name localhost;
#charset koi8-r;
#access_log /var/log/nginx/log/host.access.log main;
location / {
# Путь до файлов
root /usr/share/nginx/html;
index index.php index.html index.htm;
}
#error_page 404 /404.html;
# redirect server error pages to the static page /50x.html
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /usr/share/nginx/html;
}
# proxy the PHP scripts to Apache listening on 127.0.0.1:80
#location ~ \.php$ {
# proxy_pass http://127.0.0.1;
#}
# pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
# Разрешим использование php
location ~ \.php$ {
root html;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param DOCUMENT_ROOT /usr/share/nginx/html/;
fastcgi_param SCRIPT_FILENAME /usr/share/nginx/html$fastcgi_script_name;
fastcgi_param PATH_TRANSLATED /usr/share/nginx/html$fastcgi_script_name;
include fastcgi_params;
}
# deny access to .htaccess files, if Apache's document root
# concurs with one
#location ~ /\.ht {
# deny all;
#}
}
Мы добавили index.php и отредактировали секцию location ~ \.php$ отвечающую за обработку файлов php.
Данные действия были сделаны для того чтобы не создавая виртуальный сайт произвести проверку работы php. В последствии лучше привести файл к изначальному виду.
Проверка и команды сервиса
После любых манипуляций с файлами у сервиса есть чудесный механизм проверки сделанных изменений.
Посмотрим как выглядит вывод результата правильных настроек конфигурационных файлов:
nginx -t
= вывод команды =
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
Для перезагрузки лучше использовать «reload» так как перезагрузка произойдет не прерывая работу сервиса.
В случае если что то пошло не так, вы всегда можете посмотреть логи находящиеся в папке /var/log/nginx.
Установка и настройка MariaDB
Установка
Для установки MariaDB без вопросов выполним команду со следующими параметрами:
yum install -y mariadb mariadb-server
Создадим ссылки на автозагрузку:
systemctl enable mariadb.service
= вывод команды =
Created symlink from /etc/systemd/system/multi-user.target.wants/mariadb.service to /usr/lib/systemd/system/mariadb.service.
Запустим службу:
systemctl start mariadb.service
Начальная настройка
Произведем начальную настройку базы данных:
mysql_secure_installation
Сразу при старте попросит указать пароль! Так как его просто нет нажимаем Enter. На все вопросы обычно отвечаю Y.
Проверка и команды сервиса
Проверим сервис MariaDB:
netstat -tap | grep mysql
= вывод команды =
tcp 0 0 0.0.0.0:mysql 0.0.0.0:* LISTEN 769/mysqld
Проверим статус:
systemctl status mariadb.service
= вывод команды =
● mariadb.service - MariaDB database server
Loaded: loaded (/usr/lib/systemd/system/mariadb.service; enabled; vendor preset: disabled)
Active: active (running) since Чт 2017-03-23 04:59:53 MSK; 1 day 16h ago
- часть вывода не указана -
Видим что всё хорошо и служба стартует при перезагрузке сервера.
В случае если что то пошло не так, вы всегда можете ознакомится посмотрев логи в папке /var/log/mariadb.
Установка и настройка PHP
Выбор версии PHP
Nginx готов к обслуживанию страниц, а MariaDB может хранить данные и управлять информацией. Осталось связать эти два компонента для этого нам и понадобится PHP.
Nginx не содержит PHP, необходимо установить php-fpm (менеджер процессов FastCGI). Nginx будет передавать PHP-запросы на обработку данному программному обеспечению. Обязательно необходим еще пакет php-mysql, позволяющий PHP взаимодействовать с бэкэндом базы данных.
По умолчанию в CentOS ставится версия PHP 5.4. Не понимаю почему до сих пор не обновили до версии 5.6 хотя во многих дистрибутивах она уже идёт по умолчанию.
Узнать актуальную версию вы всегда сможете перейдя по ссылке, которая тут указана. Версия 5.6 будет актуальная до 31 декабря 2018 года.
Установка PHP 5.6
После переезда на нового провайдера обнаружил что ресурс webtatic.com не доступен. После небольшого футбола с провайдерами получил ответ: «104.24.6.38 заблокирован Роскомнадзором, тут уже ничего не поделать». На слово верить я уже давно перестал. Задал вопрос Роскомнадзору. Жду ответ. Ну а пока жду ответа добавил как установить PHP 5.6 из репозитория Remi.
16.04.2017 года ресурс Webtatic.com переехал на новый IP адрес и снова доступен для России. Более подробно можете прочитать в статье WebtaticEL или блокировка в России.
Для репозитория WebtaticEL по ссылке вы можете ознакомиться с инструкцией по установке для операционной системы CentOS 7.
Для начала проверим чтобы в системе не присутствовал php:
php -v
-bash: php: command not found
Отлично php нет в системе.
Устанавливаем только из одного репозитория. Различий в работе я не обнаружил.
В дистрибутив PHP теперь входит opcode который называется ZendOPcache. Данное расширение сохраняет компилированный байт код скрипта и повышает производительность скриптов. Это дополнение необязательно, вы можете выбрать любое другое, но поскольку данное дополнение входит в состав исходного дистрибутива PHP, и оно поддерживается разработчиком, именно его мы и будем использовать. Скорость еще никому не вредила.
Установим необходимый нам вариант php вместе с opcache и всем необходимым для WebtaticEL:
php -v
= вывод команды =
PHP 5.6.30 (cli) (built: Jan 26 2017 00:22:46)
Copyright (c) 1997-2016 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies
Вся настройка осуществляется редактированием 3 файлов а именно:
/etc/php.ini — главный конфигурационный файл php,
/etc/php-fpm.conf — главный файл настройки php-fpm,
/etc/php-fpm.d/www.conf — наш файл настройки php-fpm.
Настройка файла php.ini
Настроим главный конфигурационный файл php:
mcedit /etc/php.ini
= необходимые изменения =
# Запрет на исполнение произвольного кода на сервере с правами php процесса при загрузке файла.
cgi.fix_pathinfo=0
# Избежим ошибок часового пояса в файле /var/log/php-fpm/www-error.log
date.timezone = "Europe/Moscow"
Остальные параметры можно не трогать, так как их настройка будет осуществлена средствами настройки Nginx.
Настройка файла /etc/php-fpm.conf
В этом файле указанны основные настройки которые мы не будем трогать, лишь проверим наличие необходимых нам параметров.
Откроем файл:
cat /etc/php-fpm.conf
= вывод команды и проверка необходимых параметров =
;;;;;;;;;;;;;;;;;;;;;
; FPM Configuration ;
;;;;;;;;;;;;;;;;;;;;;
; All relative paths in this configuration file are relative to PHP's install
; prefix.
; Include one or more files. If glob(3) exists, it is used to include a bunch of
; files from a glob(3) pattern. This directive can be used everywhere in the
; file.
; Разрешаем подгружать необходимые нам файлы настроек
include=/etc/php-fpm.d/*.conf
;;;;;;;;;;;;;;;;;;
; Global Options ;
;;;;;;;;;;;;;;;;;;
[global]
; Pid file
; Default Value: none
pid = /var/run/php-fpm/php-fpm.pid
; Error log file
; Default Value: /var/log/php-fpm.log
; Путь куда пишутся логи ошибок
error_log = /var/log/php-fpm/error.log
; Log level
; Possible Values: alert, error, warning, notice, debug
; Default Value: notice
;log_level = notice
; If this number of child processes exit with SIGSEGV or SIGBUS within the time
; interval set by emergency_restart_interval then FPM will restart. A value
; of '0' means 'Off'.
; Default Value: 0
;emergency_restart_threshold = 0
; Interval of time used by emergency_restart_interval to determine when
; a graceful restart will be initiated. This can be useful to work around
; accidental corruptions in an accelerator's shared memory.
; Available Units: s(econds), m(inutes), h(ours), or d(ays)
; Default Unit: seconds
; Default Value: 0
;emergency_restart_interval = 0
; Time limit for child processes to wait for a reaction on signals from master.
; Available units: s(econds), m(inutes), h(ours), or d(ays)
; Default Unit: seconds
; Default Value: 0
;process_control_timeout = 0
; Send FPM to background. Set to 'no' to keep FPM in foreground for debugging.
; Default Value: yes
daemonize = yes
;;;;;;;;;;;;;;;;;;;;
; Pool Definitions ;
;;;;;;;;;;;;;;;;;;;;
; See /etc/php-fpm.d/*.conf
Все остальные параметры мы будем делать в файле /etc/php-fpm.d/www.conf
Настройка файла /etc/php-fpm.d/www.conf
В этом файле мы и укажем все параметры необходимые нам для работы php-fpm.
Посмотрим файл:
cat /etc/php-fpm.d/www.conf
= вывод команды с пояснениями =
[www]
# Используем порт 9000 по адресу 127.0.0.1
listen = 127.0.0.1:9000;
listen.allowed_clients = 127.0.0.1
# Пользователь и группа от которой работает php
user = nginx
group = nginx
# Как будут создаваться новые рабочие процессы
pm = dynamic
# Максимальное количество рабочих процессов
pm.max_children = 20
# Число запущенных процессов при старте сервера
pm.start_servers = 6
# Минимальное и максимальное количество процессов в простое
pm.min_spare_servers = 4
pm.max_spare_servers = 8
# Логи работы
slowlog = /var/log/php-fpm/www-slow.log
php_admin_value[error_log] = /var/log/php-fpm/www-error.log
php_admin_flag[log_errors] = on
php_value[session.save_handler] = files
php_value[session.save_path] = /var/lib/php/session
php_value[soap.wsdl_cache_dir] = /var/lib/php/wsdlcache
pm.status_path = /status
Так как мы указали пользователя Nginx, то права на папки и файлы виртуальных сайтов должны быть именно такие!
Можно использование Unix сокет в PHP-FPM, но какие он дает преимущества я так и не понял. Для применения необходимо в файле /etc/php-fpm.d/www.conf вместо строчки listen = 127.0.0.1:9000 прописать строку listen = /var/run/php-fpm/php5-fpm.sock и не забыть применить этот параметр в файлах настройки виртуальных сайтов.
Также будет необходимо создать папку с правами где будут находится наши данные сессии:
cd /var/lib/php/
mkdir session
chown nginx:nginx session/
У меня не сложилась нормальная работа по сокету, в связи с тем что периодически он отказывался работать и помогала лишь ручная перезагрузка сервера.
Если вы используйте сокет то вывод проверки будет пустой и необходимо проверить работу выводом статуса php-fpm.
Выведем статус сервиса:
systemctl status php-fpm
● php-fpm.service - The PHP FastCGI Process Manager
Loaded: loaded (/usr/lib/systemd/system/php-fpm.service; enabled; vendor preset: disabled)
Active: active (running) since Чт 2017-03-23 04:59:50 MSK; 2 days ago
- часть вывода не указана -
Видим что сервис запущен и стартует при перезагрузки сервера.
Если пошло что то не так, всегда можно посмотреть логи находящиеся по адресу /var/log/php-fpm.
Вывод информации о версии PHP
Последнее что нам осталось это проверить как браузер обрабатывает php файлы и для этого в стандартной папке nginx мы создадим файл info.php который выведет нам информацию о версии php со всеми параметрами.
Создадим файл info.php указав в нем необходимый код:
mcedit /usr/share/nginx/html/info.php
= необходимый код =
<?php phpinfo(); ?>
Назначим необходимые права на папку и все файлы внутри:
chown -R nginx:nginx /usr/share/nginx/html
Откроем в браузере наш файл указав http://ip адрес сервера/info.php
Результат
После всех произведенных действий мы настроили для работы веб сервер с необходимыми нам параметрами. Конечно в тексте присутствуют неточности как в понимании некоторых технических процессов так и самой настройки. Внимательно выслушаю все дополнения, исправления и произведу изменения в тексте статьи.
Для тестирования работы RAID1 потребовалось физически отключить диск, но после подключения обнаружил что массив не работает. После сбоя он не включится сам собой, необходимо определить проблему и перезапустить массив в ручном режиме.
Информирование о неисправности RAID1 массива
В системе Proxmox, которую мы настроили, если массив дал сбой обязательно придёт сообщение на почту.
Обязательно настройте такое оповещение любыми удобными для Вас способами.
Определение проблемного раздела
Для определения проблемного раздела выполните команду:
cat /proc/mdstat
=вывод команды=
Personalities : [raid1]
md2 : active raid1 sda3[2](S) sdb3[1]
307683752 blocks super 1.2 [2/1] [_U]
md1 : active raid1 sda2[2] sdb2[1]
3902759 blocks super 1.2 [2/2] [UU]
md0 : active raid1 sda1[2] sdb1[1]
979921 blocks super 1.2 [2/2] [UU]
unused devices:
Видим что массив md2 развалился и раздел sda3 выпал.
Действия после исправления раздела
Допустим что мы исправили диск и он с физической точки зрения исправен.
Удаление раздела из массива
Удаление выполняется командой:
mdadm /dev/md2 -r /dev/sda3
Добавление раздела в массив
Добавляем выполнив команду:
mdadm /dev/md2 -a /dev/sda3
Проверка массива
Проверим правильность работы массива командой:
cat /proc/mdstat
=вывод команды=
Personalities : [raid1]
md2 : active raid1 sda3[2] sdb3[1]
307683752 blocks super 1.2 [2/1] [_U]
[>....................] recovery = 0.4% (1518592/307683752) finish=83.9min speed=60743K/sec
md1 : active raid1 sda2[2] sdb2[1]
3902759 blocks super 1.2 [2/2] [UU]
md0 : active raid1 sda1[2] sdb1[1]
979921 blocks super 1.2 [2/2] [UU]
unused devices:
Видим что пошла синхронизация разделов, а значит все прошло успешно.
Чтобы в реальном времени смотреть процесс сборки массива, достаточно ввести:
watch cat /proc/mdstat
Чтобы вывести более детальную информацию о необходимом массиве можно выполнить команду:
mdadm --detail /dev/md2
/dev/md2:
Version : 1.2
Creation Time : Thu Mar 29 19:10:24 2012
Raid Level : raid1
Array Size : 307683752 (293.43 GiB 315.07 GB)
Used Dev Size : 307683752 (293.43 GiB 315.07 GB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent
Update Time : Fri Mar 30 17:47:48 2012
State : clean, degraded, recovering
Active Devices : 1
Working Devices : 2
Failed Devices : 0
Spare Devices : 1
Rebuild Status : 1% complete
Name : debian:2 (local to host debian)
UUID : 44da8106:3d3c2f10:446517c7:b9b4d593
Events : 1028
Number Major Minor RaidDevice State
2 8 3 0 spare rebuilding /dev/sda3
1 8 19 1 active sync /dev/sdb3
Обслуживание компьютеров, ремонт, лечение вирусов, модернизация. Системы на ОС Linux. Создание и продвижение Интернет проектов. Бесплатные консультации. Офисные АТС. Видеонаблюдение.