Производство фотообоев в Новосибирске. Интернет магазин фотообоев. Изготовление - один день! Каталог 10 000 изображений!
15 Апрель 2016

Настройка кэширования в Битриксе — что если не работает ?

Случай конечно можно сказать уникальный!
Но тем не менее решил я поделиться и таким опытом.

Обращаются ко мне с определённым ТЗ (не имеет отношение к сабжу) … и я в процессе ознакомления с сайтом, замечаю приличные тормоза (до 10 сек) при открытии страниц.
А конктретно — страничка с компонентом видео потока ютуба. Посмотрел код — вызывается компонент step2use:youtube.subscribe.
Поковырял — смысл простой — тащит канал с ютуба, парсит, результат кэширует и выводит.
Ладно, 10 секунд для запроса канала с ютуба я ещё понимаю, но почему при повторномо открытии такие тормоза?
Проверил — кэш компонента включен! Чудеса!
Тут к бабке не ходи — кэш глючит!
Накинул самый простой скрипт для проверки кэша

InitCache(3600, '12356356gt' , '/' )) {
echo "cache";
$res = $cache->GetVars();
$arResult = $res['arResult'];
} elseif ($cache->StartDataCache()) {
echo "no cache";
$arResult = array(1,2,3,4,5);
$cache->EndDataCache(array("arResult"=>$arResult));
}
?>

и тот хоть ты тресни выводит «no cache» — что говорит о том, что кэш не работает!

Далее посмотрел в dbconn.php и .setting.php — кэш настроен на memcashed (кэширование в памяти)
Перенастроил на файловый кеш — скрипт отработал и всё залетало!
Страничка стала генерироваться за 0.2 секунды ! ускорение в 50 раз!

Но всё же решил кэш настроить как и задумано на memcached!
дал рутом
#service restart memcashed
а самого сервиса то и нет! 🙂

Ну далее, всё как в книжке
# yum -y install memcached

настройки я сделал как в статье (чуть увеличил)
в файле /etc/sysconfig/memcached

MAXCONN = «1024» — количество одновременных подключений (по умолчанию 1024) — больше думаю не понадобится
CACHESIZE=»2048″ — объем выделяемой памяти для кеша (по умолчанию 64MB) — я дал 2 гига
USER=»bitrix» — пользователь, от которого будет запущен memcache
OPTIONS=»-t 16 -s /tmp/memcached.sock» — количество потоков и путь к сокету — у меня один домен на сервер, можно и через сокет — быстрее вроде

# /etc/init.d/memcached start
# chkconfig memcached on

ВСЕ залетало!
Страничка с компонентом место 10 секунд стала открываться за 0.1 секунду — т.е. прирост в скорости в 100 раз! 🙂

После экспериментов с кэшами я подумал, что не помешало бы сделаать полную очистку кэша (чтоб все с нуля и в память! и лишнее место на диске почистить)
Запустил чистку и … сервер встал наглухо!
Смотрю top — 99% на mysqld
Поставил mytop — смотрю там удаление из таблицы b_cache_tag с параметром каким то (уже не помню)
Зашел в phpmyadmin — и охренел, таблица b_cache_tag — почти 30 миллионов записей и под 4 гигабайта размером!
Что это за наследие «прошлого» я разбираться не стал — очистил всю табличку
TRUNCATE TABLE b_cache_tag (таблица для управляемого кэша, а я все равно весь кэш чистить собрался)
и далее уже ещё раз из панели «очистить весь кэш» — на этот раз кэш нормально очистился, и теперь сайт живёт совсем другой жизнью 🙂

рубрики: Bitrix, Администрирование, Полезности | Комментарии (0)

15 Апрель 2016

Настройка почты

После очередного ТЗ по настройке почты, решил отдельный пост этому вопросу посвятить.
Итак, что же необходимо для того, чтобы почта нормально уходила, как это диагностировать и настраивать?

Во первых конечно же необходимо настроить в принципе саму почтовую систему на сервере — я обычно использую MTA Sendmail или Exim
(непосредственно почтовый сервер на виртуальной машине не поднимаю)

PTR проверка

Далее необходимо настроить соответствие IP адреса сервера-отправителя почты, с обратной доменной записью — так называемая PTR проверка.
Для отладки я создаю простенький php скрипт отправляющий почту средствами штатной фукнции mail() себе же на почтовый ящик gmail и смотрю полученное письмо в исходных кодах («Показать оригинал»)
Received: from srv.mydomain.ru (srv.mydomain.ru. [123.123.123.123])

То есть доменное имя сервера отправителя и обратная запись должны совпадать!
Проверяется с консоли windows
nslookup srv.mydomain.ru
получаем IP адрес 123.123.123.123
далее делаем обратный запрос
nslookup 123.123.123.123
должны получить srv.mydomain.ru

Если несоответствие — необходимо настроить прямую и обратную зону DNS!

Чтобы не ждать пока обновится зона (часа 3-4) рекомендую проверить обратную запись linux командой
dig -x 123.123.123.123 @ns.server.ru
Предварительно узнав какие именно NS сервера обслуживают наш домен командой
whois mydomain.ru

SPF проверка
приведу пример из исходных кодов тестового письма отправленного на гугл
Received-SPF: pass (google.com: domain of info@srv.mydomain.ru designates 123.123.123.123 as permitted sender) client-ip=123.123.12.123;

В переводе на русский — SPF проверка пройдена, IP адрес отправителя считается разрешенным.
Для того, чтобы сервер проходил SPF проверку необходимо IP адрес сервера (или домен) внести в SPF запись зоны (это текстовая DNS запись определенного формата)
Например такой записи «v=spf1 +mx +ip4:123.123.123.123» вполне будет достаточно, чтобы пройти SPF проверку

Далее при настройке почты и изучении оригинала письма мне не понравилась сточка генерируемая моим же sendmail
X-Authentication-Warning: srv.mydomain.ru : bitrix set sender to info@mydomain.ru using -f

видите ли пользователь bitrix не является отправителем для домена srv.mydomain.ru!
Добавляю пользователя bitrix в доверенных пользователей для отправки почты в файл /etc/mail/trusted-users и перезапускаю sendmail — всё, ошибка ушла!

Ну и чтобы не было путаницы с доменными именами, hostname серверу я так же присваиваю srv.mydomain.ru
Правим /etc/sysconfig/network на предмет HOSTNAME=srv.mydomain.ru
и чтоб не ребутить для текущей сессии даём команду
hostname srv.mydomain.ru

Всё!
Обычно этого «набора» хватает для того, чтоб письма нормально доходили и не попадали в спам

P.S.
Бывает нужно ещё и цифровую подпись DKIM настроить для верности — мне не приходилось, но могу порекомендовать хорошую статью по настройке почты (в т.ч. dkim)

рубрики: Администрирование, Полезности | Комментарии (0)

11 Февраль 2016

Блокировка ботов по user-agent — blacklist список

Итак, имея инструмент блокировки по black-list и вручную ковыряя логи, обнаружил что практически DDOS устраивают куча всяких «левых» ботов.
Например «SemrushBot www.semrush.com/bot.html» — какой то иностранный SEO инструмент — думаю мой сайт ему вообще не пригодится, собирает всё на автомате создавая лишнюю нагрузку.
«megaindex.com» туда же — я на мегаиндексе ни ссылки ни статьи не закупаю, и не продаю.
«libcurl» — кто, то парсит curl-ом — тоже в сад
Анализ своих логов может проявить ещё много ненужных вам ботов.
Блокировать можно в 2 уровня — дописать в анализаторо логов по вхождению в user-agent, а так же непосредственно в nginx в начало секции server { … } добавляем:
if ($http_user_agent ~ SputnikBot|Crowsnest|PaperLiBot|peerindex|ia_archiver|Slurp|Aport|NING|JS-Kit|rogerbot|BLEXBot|MJ12bot|Twiceler|Baiduspider|Java|CommentReader|Yeti|discobot|BTWebClient|Tagoobot|Ezooms|igdeSpyder|AhrefsBot|Teleport|Offline|DISCo|netvampire|Copier|HTTrack|WebCopier) {
return 403;
}

Список проверяем вручную!
Как видно в списке присутствуют программы качающие сайт целеком — они так же создают сильную нагрузку! Вот ещё Список ботов и программ качающих сайт целиком.

рубрики: security, Администрирование | Комментарии (1)

10 Февраль 2016

Защита от DDOS — анализ логов nginx и блокировка IP по blacklist фаерволом

В посте Защита от DDOS — первые шаги я закончил фразой «Теперь вот жду второго пришествия» — собственно, второе пришествие недавно заглянуло в виде очень дохленького DDOSa который все же забил канал так, что провайдерам пришлось отрубили порт.
Кэширование nging вообще тут не участвовало т.к. ддосили POST запросами.
Ограничение зоны на количество запросов с одного IP NGINX — защита от DDOS с одного IP. Параметры limit_zone и limit_req тоже не спасли!

Принял решение — полностью задействовать фаервол в связке с nginx, в моём случае фаервол ipfw т.к. операционная система FreeBSD, но это не суть, т.к. смысл остаётся тем же:
Анализируем логи, вычисляем злодеев, загоняем IP злодеев в blacklist который кушает фаервол.
Читать полностью »

рубрики: NIX, security, Администрирование | Комментарии (1)

9 Февраль 2016

Полезные мелочи nginx

# Закрываем доступ к файлам начинающимся с точки
location ~ /\.
{
deny all;
access_log off;
log_not_found off;
}
# Закрываем доступ к файлам заканчивающиеся old
location ~ \. old
{
deny all;
access_log off;
log_not_found off;
}

# Отключаем логи для favicon и robots.txt
location = /favicon.ico
{
log_not_found off;
access_log off;
}
location = /robots.txt
{
allow all;
log_not_found off;
access_log off;
}

рубрики: NIX, Администрирование | Комментарии (0)

14 Январь 2016

Быстрый файловый бэкап RSync с исключением по маске

Для локального бэкап копирования раньше использовал просто cp, сегодня переделал на rsync и понял как я был неправ ранее 🙂
Переделать пришлось из-за отсутствия возможности в копировании прикрутить скип-лист, куда запихать кэши, темпы и прочее «барахло»,
и помимо задуманного бонусом получил супер фишку!
rsync то, что не изменилось не копирует! соответственно процесс бэкапа ускорился в десятки раз и существенно снизилась нагрузка на дисковую подсистему, соответственно на хостинг в целом!

всё в одну строку 🙂
rsync --exclude-from rsync.exclude.cfg --log-file rsync.1.log -auptrgo --delete-before /source_dir /backup_dir

rsync.exclude.cfg — файлик со списком исключений
*/cache/*
*/temp/*
и т.д.

рубрики: NIX, Администрирование, Полезности | Комментарии (0)

23 Сентябрь 2015

wget — скачиваем сайт целиком

Репост для себя. Источник.

С помощью wget можно скачивать сайты, включая картинки, всего лишь указав адрес сайта и определенные параметры. wget будет автоматически переходить по ссылкам на сайте и скачивать страницу за страницей. Рассмотрим несколько примеров от простых к более сложным использования wget для скачивания сайтов.

Чтобы скачать сайт целиком с помощью wget нужно выполнить команду:

После выполнения данной команды в директорию site.com будет загружена локальная копия сайта http://site.com. Чтобы открыть главную страницу сайта нужно открыть файл index.html.

Рассмотрим используемые параметры:

-r указывает на то, что нужно рекурсивно переходить по ссылкам на сайте, чтобы скачивать страницы.
-k используется для того, чтобы wget преобразовал все ссылки в скаченных файлах таким образом, чтобы по ним можно было переходить на локальном компьютере (в автономном режиме).
-p указывает на то, что нужно загрузить все файлы, которые требуются для отображения страниц (изображения, css и т.д.).
-l определяет максимальную глубину вложенности страниц, которые wget должен скачать (по умолчанию значение равно 5, в примере мы установили 7). В большинстве случаев сайты имеют страницы с большой степенью вложенности и wget может просто «закопаться», скачивая новые страницы. Чтобы этого не произошло можно использовать параметр -l.
-E добавлять к загруженным файлам расширение .html.
-nc при использовании данного параметра существующие файлы не будут перезаписаны. Это удобно, когда нужно продолжить загрузку сайта, прерванную в предыдущий раз.

 

Мы рассмотрели лишь одно из возможных применений утилиты wget. На самом деле область применения wget значительно шире и wget обладает большим числом дополнительных параметров. За более подробной информацией обращайтесь к руководству, выполнив в командной строке: man wget.

Для записи результата в лог файл -o logfile

рубрики: Администрирование, Полезности | 2 комментария

4 Сентябрь 2015

NGINX — запрещаем доступ к служебным файлам .git .bak .old .htaccess и других по расширению

Нередко, в движках используют в скриптах подключаемые файлы с расширением отличным от php, что имхо очень неправильно и опасно.
Например в одном из движков (не буду тыкать пальцем каком именно) в темлейте подключают файлы с расширением .tpl которые не являясь активкой по умолчанию (интерпретатор настроен по умолчанию как правило на htm html php php5 и подобные), которые спокойно открываются в браузере в исходных кодах! а там уже есть чего поанализировать «плохим парням» 🙂
Другой пример — служебные файлы .git, старые резервные копии .bak .old … всё это часто забывают запретить в настройках аппача или nginx-а.

Соответственно, добавляем в nginx следующие строки, и спим спокойно

404

рубрики: security, Администрирование | Комментарии (0)

15 Июль 2015

Как перенести настройки iptables через файл

Сегодня с ужасом обнаружил, что на одном из моих серверов iptables пустая (был уверен, что настроено).
Соответственно, рецепт по переносу настроек с одного сервера на другой прост:
1. service iptables save на тот откуда тащим
2. перетаскиваем /etc/sysconfig/iptables
3. service iptables reload на том куда перетащили

P.S.
Отличная статейка по iptables

рубрики: security, Администрирование, Полезности | Комментарии (1)

10 Июль 2015

Взлом сайта по FTP — разрешаем доступ по IP

Вчера ломанули группу сайтов тупо по FTP — законнектились и сделали инжекты во все скрипты php и в html тоже …
Благо сработал скрипт сравнения версий файлов — вовремя отреагировал, всё восстановил.
Причём подозреваю в этом себя т.к. ломанули сайты разные и ко всем у меня был прописан доступ в FAR-е 🙁 (хотя не факт)
Итак:
1. Не храним доступ в открытом виде, не ленимся вводить пароль (очень для меня трудно-исполнимый пункт)
2. Меняем стандартный порт доступа FTP на нестандартный (в конфиге сервера listen).
3. Ограничиваем доступ FTP по IP адресу (заливали файло в левых IP) — в моём случае VSFTPD не позволяет прописывать доступ по IP, поэтому сделаем боле правильно — запретим/разрешим доступ на уровне фаервола iptables

сначала посмотрим текущие
iptables -L INPUT —line-numbers
находим и убираем старое правило
iptables -D INPUT номер
добавляем новое iptables -A INPUT -p tcp -s 192.168.0.0/24 —dport 22 -j ACCEPT
(IP и маску пишем свои — откуда будем цепляться)
service iptables save
service iptables restart

у меня не сработало, т.к. правило добавилось в конец, после запрета всех
пришлось поправить порядок вручную
/etc/sysconfig/itrables.save
service iptables restart

рубрики: security, Администрирование, Полезности | Комментарии (0)