Базовый Debian «на борту» по умолчанию имеет крайне скупой набор необходимых утилит. Убедиться в этом все вы можете, на примере добавления к PHP очень важного модуля для кеширования — Opcache Продолжить чтение
Как исправить ошибку импорта БД size of BLOB/TEXT data greater than 10% of redo log size
При импорте базы данных нередко можно столкнуться с ошибкой:
#1118 — The size of BLOB/TEXT data inserted in one transaction is greater than 10% of redo log size. Increase the redo log size using innodb_log_file_size.
Как исправить эту ошибку?
Стандартный htaccess для OpenCart
Не впервые сталкиваюсь с тем, что движок сам не генерирует файл .htaccess при включении ЧПУ(Seo-url).
В дистрибутиве этот файл также может отсутствовать. Продолжить чтение
Как исправить ошибку action_err_ns в ModX
Если у Вас после настроек редиректов, сео-ссылок и ЧПУ в CMS ModX при авторизации в админ-панели или же при любых действиях в админ панели возникает ошибка
action_err_ns, то для ее исправления нужно отключить редиректы (mod_rewrite) в системных папках движка.
Итак, чтобы исправить ошибку action_err_ns в ModX нужно Продолжить чтение
Борьба с син-флудом
На серверах, которые я обслуживаю часто и остро всплывает проблема с син-флуд атаками разной мощности. Не имея аппаратной защиты от DDOS приходится изощряться с IPTables.
Ранее, когда системы мониторинга оповещали о возросшей нагрузке целый ряд действий диагностически-карательного характера приходилось делать вручную. Перечислю ниже:
- Для проверки количества SynRequest использовал команду netstat -n -p|grep SYN_REC | wc -l — тут, как мне кажется, расшифровывать ничего не нужно.
- Для получения списка IP-адресов, с которых идут эти запроы использовал netstat -n -p | grep SYN_REC | sort -u | awk {‘print $5’} | cut -d : -f1 — тут уже чуть сложнее, с помощью awk получаем 5й аргумент — IP-адрес, с которого идут запросы, отсеивая протокол, IP самого сервера и прочий мусор.
- И слишком грубый метод, от которого пришлось отказаться — etstat -n -p | grep SYN_REC | sort -u | awk {‘print $5’} | cut -d : -f1 | xargs -t -l iptables -A INPUT -p tcp -j DROP -s предыдущая команда, с передачей IP-адресов в IPTables с их последующей блокировкой.
- Следующим шагом стало улучшение команды блокировки, команда получилась уж больно объемной, зато более правильно построенной в плане логики борьбы с синфлудом — netstat -n -p | grep SYN_REC | sort -u | awk {‘print $5’} | cut -d : -f1 |uniq -cd |sort -nr| head -n 3|awk {‘print $2’}| xargs -t -l iptables -A INPUT -p tcp -j DROP -s -тут чуть подробней: с помощью uniq -cd отсортированы только повторы (-d) и указано их количество(-c), с помощью sort -nr сортируем их по кол-ву в убывающем порядке, с помощью head -n 3 получаем только трёх “лидеров”, а с помощью awk {‘print $2’} удаляем кол-во коннектов из списка “лидеров”, получая только второй аргумент — собственно сам IP-адрес. А далее это все вновь передается в IPTables.
- И, чтобы понять, как часто срабатывает защита, какие IP-адреса попали под блокировку, и, чтоб после проверить по логам на какой сайт велась атака, чуть-чуть видоизменяем последнюю строку и добавляем еще одно echo с записью в файл: exec («date >> synstat.txt»);
exec («netstat -n -p | grep SYN_REC | sort -u | awk {‘print $5’} | cut -d : -f1 |uniq -cd |sort -nr| head -n 5|awk {‘print $2’}| xargs -t -l echo >> synstat.txt»);
Оставалось это автоматизировать. Так как количество Syn-запросов практически всегда больше нуля нужно было определить порог, при котором настает время запускать карающий инструмент, иначе IPTables оказался бы забит тысячами адресов уже за пару часов работы. Потому порогом, при котором срабатывает скрипт было выбрано число в 100 одновременных syn rec.
Оговорюсь сразу — я люблю большие и сложные построения команд в shell и считаю их гораздо более практичными, чем использование десятков библиотек и модулей в других языках программирования, но я не люблю писать на чистом Bash. Потому мною был порожден гибрид shell с php, который не претендует на красоту, лаконичность, образцовый код и т.д., но который делает свою работу верно и быстро, чем меня полностью устраивает.
<?php
function killemall() {
exec («netstat -n -p | grep SYN_REC | sort -u | awk {‘print $5’} | cut -d : -f1 |uniq -cd |sort -nr| head -n 3|awk {‘print $2’}| xargs -t -l iptables -A INPUT -p tcp -j DROP -s»);
exec («date >> synstat.txt»);
exec («netstat -n -p | grep SYN_REC | sort -u | awk {‘print $5’} | cut -d : -f1 |uniq -cd |sort -nr| head -n 5|awk {‘print $2’}| xargs -t -l echo >> synstat.txt»);
}
$syncount = exec (‘netstat -n -p|grep SYN_REC | wc -l’);
if ($syncount > 100) {
killemall ();
}
Далее сие чудо было добавлено в крон на выполнение каждую минуту способом, который не попадал под проверку моим прошлым мини-скриптом — выполнение каждую минуту было задано не символом *, а интервалом 0-59.
Если не применяется кодировка .htaccess
Сегодня, разворчачиая реселлерскую панель рег.ру столкнулся с тем, что нисмотря на наличие в .htaccess строки
AddDefaultCharset WINDOWS-1251
кодировка оставалась UTF-8, как настроено для сервера по умолчанию и, соответсвенно, весь кириллический текст отображался кракозябрами. Продолжить чтение
Modx — главная страница отдает только надпись Error
При публикации на хостинге сайта на движке ModX, разработанного на локальном сервере или же при переносе с хостинга на хостинг может и, очень вероятно, возникнет ошибка:
на главной странице сайта будет высвечиваться одинокое слово «Error» и более ничего. Лог ошибок веб-сервера будет пуст.
Связано это с тем, что разработчики ModX отличаются умом и сообразительностью и системные настройки хранят в базе данных.
При переезде сайта с вероятностью в 99.9% сменятся пути к системным папкам, а в ModX принято указывать пути абсолютные, вместо относительных.
Итак, требуется отредактировать таблицу modx_system_settings, а именно поля rb_base_dir, а также filemanager_path (это поле не влияет на ошибку на главной, но исправить его следует). Важно: указывать нужно путь не просто к каталогу, сайта, а включая каталог assets.
Кроме этого в каталоге /assets/cache/ файл siteCache.idx.php необходимо удалить или переименовать.
Устранение ошибки при установке ShopCMS
При установке популярного движка ShopCMS на сервер хостинга у Вас может возникнуть подобная ошибка:
«Возникла ошибка! Обратитесь к разработчикам» при том, что все пункты проверки соответствуют требования. Продолжить чтение
Рекурсивное изменение прав и владельца в *nix системах
При переносе данных, в частности сайтов, с хостинга на хостинг или между серверами может возникнуть необходимость сменить права доступа к файлам и/или папкам, а также, возможно, и владельца файлов. Не каждая панель управления, если она конечно есть, позволит это сделать. Продолжить чтение
503 ответ сервера CMS Magento
Разработчики и владельцы сайтов, разработанных на движке Magento часто сталкиваются с 503 ошибкой.
И это не связано с проблемами на стороне сервера, как для абсолютного большинства аналогичных ответов сервера, но при другом установленном движке.
При возрастающей нагрузке, к примеру в процессе обновлений, Magento создает в корневом каталоге сайта файл maintenance.flag c единственной строкой:
«maintenance». Продолжить чтение