Сбылась мечта идиота, я купил себе BMW. Не E36 как когдато хотел и не E21 как хотел недавно, а семейный универсал BMW E46. Время тикает, семья расширяется и приходит понимание что машина должна возить не только попу владельца но еще и много всякой ерунды — детские каляски, велосипеды и тому подобный семейный инвентарь. Решение покупки было довольно спонтанным, давно присматривал машину в Европе «под растаможку». Последний закон с льготным акцизом (нижайший поклон евробляхерам!) меня всетаки подбил на авантюру с пригоном авто. Изначальная идея была пригнать самому, темболее что в Вильнюсе у меня живут хорошие друзья, можно спокойно пожить у них хоть неделю, пока не найдется достойный кандидат. Но изучив подробнее механизм пригона авто я понял что это весьма сложная и запутанная процедура, требующая и знаний и опыта. Узнав что за услугу выбор-пригон берут всего 500$ я понял что это мой вариант. А что растаможка? Тот же человек после пригона пообещал и растаможить через своего брокера — услуги брокера 320$. Авто выбирали BMW E46 320D рестайл (2001 — 2005 год) в диапазоне от 2500 до 3000 евро. Таможенных платежей при таких параметрах должно было получиться от 60.000 до 75.000 грн. Также не забываем о доп засходах на человека который будет пригонять — проезд, проживание, питание, европейская страховка авто, заправка — 200$
Итого, в теории машина на укр номерах будет стоить около 7000$
Смысл покупать в Европе есть даже в случае небольшого увеличения расходов (до 10%) так как аналогичные варианты на рынке Украины начинаются от 8000$
Искали, смотрели, подбирали и выбрали такую машинку:
Иногда мы очень ждем какогото события, например добавления записи в DNS, чтобы оперативно получить информацию и не долбить без конца одну и ту же команду по клавиатуре можно сделать так:
Сравнить 2 столбика, и вывести только те строки, содержание которых не совпадает
Вывести список установленных пакетов по маске (без версий):
Восстановить заархивированный архив SQL дампа:
Бекап всего блочного устройства удаленно с помощью ssh и dd.
С удаленного хоста:
С локального хоста на удаленный:
Найти файлы и которые содержат «MY PATTERN» и скопировать в /dest/dir :
Проверка FTP, или просто коннект в active mode с debug:
Построить рейтинг стран источников пакетов из дамп-файла (должны быть установлены пакеты geoip-bin geoip-database):
Отрезать кусочек видео от (время 00:00:00) до (время 00:39:03) без перекодирования:
Будет дополняться …
Хай щастить!
Это заметка из цикла стетей моего небольшого HowTo по Debian Jessie.
Попробуем немного ускорить выдачу сервером web-контента. Начнем с простого пятиминутного тюнинга … сессии. По умолчанию сессии пользователей на сервере хранятся в виде отдельных файликов на файловой системе в директории /var/lib/php5/sessions Это вполне отлично при малом количестве посетителей ресурса, но становится проблемой при увеличении посещаемости, так как дисковые операции очень «дорогие» и «тяжелые» с точки зрения сервера. Такой способ хранения сессий порождает излишнюю нагрузку на дисковую подсистему сервера и замедляет выдачу контента пользователям. Выход придуман давным давно — перенести сессии в RAM-у сервера. Простейшим решением является сервис memcached который представляет из себя key value базу данных работающую исключительно в оперативной памяти. Это, кстати, таит в себе и побочный неприятный момент — в случае перезапуска сервиса memcached или сервера целяком — база очищается, а значит пользователям придется «перелогиниться». Если это критичный для вас момент — тогда лучше использовать сервис который синкает базу данных на диск, например couchbase или redis. Но я не дорожу своими сессиями, потому что пользователей у меня чуть больше чем 1 🙂 поэтому буду использовать memcached
Установим необходимые пакеты:
Открываем основной конфиг memcached:
По умолчанию сервис запускается с базой в 64MB, для меня это мало (чуть позже расскажу почему) — ставлю 128 MB:
Запускаем службу memcached:
Проверяем что служба «слушает» порт 11211:
Теперь перестроим php таким образом чтобы он хранил сессии в memcached, а не в файлах на диске. Открываем конфиг php.ini для fpm:
Ищем там секцию [Session] и настраиваем ее вот так (привожу только те параметры что поменял, остальные оставляем по дефолту):
Перезапускаем сервис php5-fpm:
Если вы используете в apache2 модуль php5 то у него есть отдельный конфиг ( /etc/php5/apache2/php.ini ), операцию по перестройке его на memcached сессионное хранилище нужно повторить по аналогии с php5-fpm, после чего перегрузить сервис apache2
Поскольку memcached давно откатанный и стабильный вариант работы с RAM хранилищем в PHP (и не только) в различных WEB проектах его используют не только для хранения сессий, но и как хранилку кеша. Для популярных CMS есть готовые модули которые умеют запихивать в memcache куски страниц или даже целые страницы готового скомпилированного HTML-я. Это позволяем в разы увеличить скорость выдачи контента и при этом уменьшить нагрузку на сервер (магия?) но требует серьезной проработки кода проекта под фичу кеширования вцелом.
Вот примеры среди популярных бесплатных CMS:
— Drupal 6/7 — тыц
— WordPress — тыц
— Joomla — тыц
и тд.
Я отдал memcached-у 128MB RAM именно для этого варианта кеширования.
Ставим модуль, настраиваем, пользуемся и радуемся дикому приросту скорости отдачи контента. Имейте ввиду что кеш очищается при рестарте сервиса memcached.
С memcached вроде как все ясно, неясно одно — почему решение вопроса «кешировать или компилить» должен решать программист конкретного продукта с помощью сторонних приложений, а не сам php? Это вполне логичный вопрос и он имеет решение в виде модулей для php которые призваны этим заниматься. Их много, почитать коротко о них можно здесь, ИМХО — достаточно вменяемый на сегодняшний день XCache, он достаточно стабилен и продолжает развиваться. Достаточно часто встречал в сети лестные отзывы о нем. Пробую прикрутить …
Установим необходимые пакеты:
Приятной особенностью данного модуля является наличие web-админки где можно посмотреть текущие настройки, статистику, очистить кеш и тп Это не обязательная фича данного модуля, можно не заморачиваться, но мне было интересно — решил настроить.
Генерим пароль в админку XCache (иначе никак):
Для настройки модуля xcache открываем его конфиг:
Вот такой конфиг получился (только то что поменял от дефолта):
Перезапускаем сервис php5-fpm:
Про настройку WEB-интерфейса данного модуля расскажу чуть позже, настроим его вместе с другими популярными WEB-приложениями (PHPMyAdmin, PostfixAdmin, Roundcube).
Теоретически такой вариант кеширования должен работать быстрее чем основанный на memcached, чтобы убедиться в этом нужно тестировать, но это уже отдельная тема. Модуль работает сразу после его включения в php5. Для большей эффективности можно использовать плагины со стороны CMS, например для WordPress можно попробовать вот этот модуль. Устанавливается он не сложно, по инструкции. Дополнительных действий никаких, просто ждем пока наполнится кеш и наступит нирвана 🙂 Напомню что в данном варианте кеш очищается при рестарте сервиса php5-fpm
Незнаю будет ли кому полезно, получилось несколько сумбурно …
Хай щастить!
Это заметка из цикла стетей моего небольшого HowTo по Debian Jessie.
Напомню что я описывал свою небольшую сетку и ее составляющие тут.
Настройка будет проводится на двух серверах nas.my.local и gw.my.local, я постараюсь указывать на каком сервере что выполнятеся, но также будет видно и в приветствии шела. Роли у них будут такие:
nas.my.local — основной менеджер (bacula-dir), хранилище (bacula-sd), консоль (bacula-console) и клиент (bacula-fd)
gw.my.local — основной клиент (bacula-fd) для бекапа (настройки, сайты, базы mysql …)
С ролями определились, вперед к настройке! Читать полностью
Это заметка из цикла стетей моего небольшого HowTo по Debian Jessie.
Для меня тюнинг mysql — это такой себе постоянный вялотекущий процесс который не имеет ни начала ни конца. Базы данных вцелом — это огромный кусок IT-индустрии в котором нужно вариться постоянно чтобы быть специалистом. Признаюсь честно, я не очень интересуюсь базами данных, поэтому настройку обычно свожу к соблюдению общих рекомендаций, не более …
Тут сделаю еще небольшую ремарку, особенно полезную новичкам. Настройка любой БД — это очень индивидуальный процесс, поэтому если вы видите на какомто ресурсе четкие рекомендации как и что нужно тюнить — не стоить этому верить. Разбираться нужно всеравно самому, анализировать конкретный сервер с конкретной нагрузкой на конкретном железе. Львиная доля оптимизации лежит также и на грамотной постройке самой базы, наличию правильных индексов и тд и тп Тут нам здорово помогает фича сбора статистики самим mysql-сервером, о ней чуть позже. Читать полностью
Это заметка из цикла стетей моего небольшого HowTo по Debian Jessie.
Бэкапы и тормоза придумали трусы … это понятно. Непонятно только что делать когда железка померла или сайт похакали. Чтобы не попадать в такую непонятную и неприятную ситуацию — настроим автобэкап. Сразу скажу, что это только первый этап бэкапа, он делается на тот же хост где расположен mysql, следующим этапом будет настройка bacula — она заберет и файлы баз и директории с сайтами на удаленное хранилище … что обеспечит сохранность данных даже в случае поломки сервера.
У меня LVM, поэтому директорию для хранения бэкапов баз я решил расположить на отдельном LV.
Примерно прикиньте размер своих баз, учтите что храниться будет несколько бэкапов в заархивированном виде. В моем случае вполне хватит 2GB.
Создаем LV размером 2GB:
Форматируем новый LV в ext4:
Создаем директорию для бэкапов:
Для автомонтирования раздела при старте сервера прописываем в /etc/fstab
Вот такую строчку:
Монтируем новый раздел:
Создаем директорию на lv_backup для будущих бэкапов mysql баз:
Не забываем что это бэкапы баз, там есть много разной инфы, в том числе и приватной, поэтому не забываем урезать права на директорию. Доступ только тем что имеет sudo:
Создаем директорию для админских скриптов:
Создаем скрипт который будет бекапить базы:
С вот таким содержимым (не забываем сменить BASES_FOR_BACKUP и mysql_root_passwd_here на свои значения):
Также обратите внимание на команду find в скрипте:
Это очистка архивов старше 15-ти дней. Если вам нужно больше/меньше — просто исправьте данную циферку на нужную.
Даем скрипту права на выполнение:
Итак, на данный момент директория с бекапами пуста, проверим это:
Пробуем запустить скрипт (не делайте это если база в активном использовании, лучше это делать когда база в минимальной нагрузке):
В случае корректного выполнения никакого вывода скрипт не дает, только если есть ошибки. У меня отработал без ошибок, вот листинг директории /backup/mysql после выполнения скрипта:
Теперь добавим скрипт бэкапа в root-овый crontab чтобы он выполнялся автоматически каждый день в 03:00 ночи:
Пишем вот следующее (не забывайте в конце оставлять пустую строку):
Завтра проверяйте содержимое директории /backup/mysql, там должны быть свежие бекапы …
Хай щастить!
Это заметка из цикла стетей моего небольшого HowTo по Debian Jessie.
Тут я уже описывал ранее вариант фильтрации доступа к ssh по GeoIP. На этот раз покажу вам более интересный вариант с ipset и модуль TARPIT для IPTABLES. Сразу скажу пару слов об этих новых сущностях:
— ipset — модуль поддержки таблиц для iptables с сопутствующей обвязкой для управления этими самими таблицами: создание, удаление, работа с элементами таблицы и тп. Сам по себе модуль весьма хорош и здорово повышает эффективность работы iptables с большим количеством ip-адресов и сетей. Но если разсметривать реализацию iptables + ipset вцелом — то оно мне напоминает пятиколесный велосипед с деревянными спицами. Уж простите за такую ассоциацию у человека несколько лет админившего всякие там pf/ipfw в BSD-ях. На High-Load юзать можно и нужно!
— TARPIT модуль для IPTABLES — это модуль для it-весельчаков. Суть работы этого модуля заключается в том что он какбы держит открытым указанный TCP порт, но при попытке клиента соединиться — не шлет в ответ абсолютно ничего. Это такой себе blackhole или nullroute на уровне фаервола. Это приводит к «зависшему» соединению с возможностью закрыть его только автоматически по истечению таймаута. Задумка модуля в том чтобы не просто блокировать бота, а истощать его ресурсы на соединение, мизерные, конечно, но всеже … На High-Load юзать не желательно, лучше пользуйте DROP!
Ранее при настройке proftpd мы уже установили geoip, но для тех кто не делал этого понадобится установленный geoip и его база:
В Debian модуль TARPIT находится в пакете дополнительных модулей iptables. Установим их:
Ставим необходимый пакет для добавления ipset:
Одной из приятных фишек таблиц ipset является опция timeout. Она задает количество времени (в секундах) которое элемент содержится в таблице. По истечении timeout-а — элемент автоматически удаляется из таблицы.
Пример борьбы с ssh брутфорсерами:
1. Создаем таблицу, в нее скриптом проверки geoip будем добавлять ботов, timeout ставим 2 часа:
2. Загрузим модуль ядра для действия iptables TARPIT:
3. Напомню что вот здесь мы базово настроили iptables. Сразу перед правилом розрешающим конект на port 22 добавим правило для блокировки ssh ботов из таблицы ssh_bots. Должно получиться вот так:
4. Теперь сооружаем чуть модифицированный скрипт проверки geoip — /usr/local/bin/ssh_geoip.sh:
Вставляем туда следующее …
Это же скрипт, не забываем дать права на выполнение:
5. Теперь подправим конфиг /etc/hosts.deny добавив туда:
6. Теперь подправим конфиг /etc/hosts.allow добавив туда:
Итак, теперь соединение к ssh-серверу проходит так:
— конект на 22-й порт
— если ip клиента из сети 192.168.0.0/16 — пускаем сразу (см. whitelist в файле /etc/hosts.allow)
— проверка прав дотупа через скрипт /usr/local/bin/ssh_geoip.sh (розрешено только для UA ip-адресов)
— если права даны — приглашение к авторизации
— если права не даны — добавление ip бота в таблицу ssh_bots и сброс соединения
— следующая попытка соединения на порт 22 ведет в модуль TARPIT iptables-а
спустя 7200 секунд (2 часа) ip бота автоматически удаляется из таблицы ssh_bots и может коннектиться снова
Все прохождения через скрипт логируются в /var/log/messages в таком виде:
удачные:
неудачные:
Посмотреть листинг таблицы ssh_bots:
Хай щастить!
Это статья из цикла стетей моего небольшого HowTo по Debian Jessie.
Чуть раньше я коротенько описал процесс установки и базовой настройки всех необходимых компонентов для WEB сервера:
Debian Jessie: Настройка apache2 + libapache2-mod-php5
Debian Jessie: Установка и настройка Nginx
Debian Jessie: Установка и настройка PHP5-FPM
Из этих компонентов мы сложим несколько вариантов настройки WEB сервера:
1. Nginx -> Apache2 -> libapache2-mod-php5
2. Nginx -> PHP5-FPM
3. Nginx -> PHP5-FPM в chroot
Поехали … Читать полностью
Это статья из цикла стетей моего небольшого HowTo по Debian Jessie.
Современный Интернет трудно представить без языка PHP, но возможностей работать с PHP из коробки нет ни у кого среди WEB-серверов. С Apache2 мы уже разобрались, установив для него модуль php, а вот с Nginx не так просто — он умеет работать с PHP по протоколу CGI. Наиболее прогрессивной вариацией CGI на сегодняшний день является FastCGI, а менеджер процессов для него — PHP-FPM. Он есть в стандартных репозиториях Debian под именем php5-fpm.
Установим:
Также для PHP наверняка понадобятся некоторые модули, если чегото не хватит — доустановим в процессе разворачивания сайтов:
Не забываем добавить сервис в автозагрузку:
Теперь к настройкам.
После установки пакетов у вас появится отдельная директория для настроек php-fpm — /etc/php5/fpm
В ней расположен основной конфиг сервиса — /etc/php5/fpm/php-fpm.conf Настраивать я там особо ничего не стал, просто проверил чтобы была настройка с инклудами пулов:
Хорошим правилом на хостинге где много сайтов под каждый сайт настраивать отдельного системного пользователя и отдельный php пул. Это дает возможность гибко настраивать php для каждого отдельного сайта, а также, «изолировать» на уровне php сайты друг от друга. Настройка пулов совсем несложная. Конфиги расположены в директории /etc/php5/fpm/pool.d По умолчанию в php-fpm есть один пул — www с конфигом — /etc/php5/fpm/pool.d/www.conf Я обычно выключаю данный конфиг простым переименованием файла в example или default:
и потом использую в качетсве шаблона при создании своих пулов. Как и обещал, в следующей статье про WEB я приведу примеры конфигов двух вариантов запуска пулов php-fpm: в chroot и без него. А сейчас хочу просто перечислить основные настройки пулов и коротко их описать.
Название пула. В самом верху конфига в квадратных скобках пишут название пула, например:
[www] или [somepool] и тп
Пользователь и группа:
Это очень важный параметр, имя пользователя и группа от которого будут запускаться php-процессы. Например:
user = www-data
group = www-data
Где слушаем подключения:
Может быть как TCP сокет, так и Unix сокет. Если указать только номер TCP порта, значит слушать этот порт на всех интерфейсах. Например:
listen = /var/run/php5-fpm.sock
listen = 127.0.0.1:9001
listen = 9001
Если в качетве listen используется Unix сокет — то нужны дополнительные параметры по правам доступа и владельцу, также обращаю внимание на то что user от которого запущен процесс пула должен иметь права записи на сокет, иначе работать не будет:
listen.owner = www-data
listen.group = www-data
listen.mode = 0660
С каких ip принимать запросы:
Используется в случае listen TCP сокета на всех интерфейсах. Я бы рекомендовал закрывать фаерволом, но тем не менее на уровне сервиса можно контроллировать доступ к сокету просто перечислив необходимые ip — остальные «идут лесом» Например розрешим доступ только с двух ip:
listen.allowed_clients = 192.168.1.100, 192.168.1.200
Настройка менеджера процессов, это очень важная часть конфига:
Тут трудно описать лучше чем в официальной документации, поэтому лучше прочтите сами и настраивайте с понимаением дела.
Время в секундах после которого простаивающие процессы будут убиты, работает только при pm = ondemand:
Количество реквестов после которого fastcgi процесс полностью перезапустится:
Это очень полезная опция, реально может помочь при работе с проектом в котором есть баги с утечками памяти. Конечно же это не решает проблему кривого кода, но зато существенно сокращает количество сегфолтов.
Вцелом хочу подитожить — грамотная настройка pm* опций в пуле php-fpm помогает «держать на плаву» даже самые безнадежные php поделия 🙂
Статистика пула:
Полезная опция для мониторинга и статистики, включить можно например так:
pm.status_path = /$pool-status
после чего настраиваем проксирование некоторого локейшена в домене localhost на данный URL. Пример:
после перезапуска nginx мы можем посмотреть что же там за статистика пула:
эти данные можно анализировать системой мониторинга, накапливать статистику, рисовать графики, обложить триггерами и оповещать ответственных в случай беды … но это уже совсем другая история.
Также для мониторинга доступности можно использовать более простой механизм ping-pong:
Значение по умолчанию /ping. Если данный URI спроксировать nginx-ом по образу и подобию приведенному выше, то в ответ будем получать 200-ку и некоторый ответ, который по умолчанию pong но можно задать кастомный следующей опцией:
Очень полезная фишка для простейшего мониторинга доступности сервиса.
Лог запросов, для дебага незаменимая опция:
Просто задаем путь к логу, например так:
access.log = /var/log/php-fpm/$pool_access.log
Формат лога доступа:
Огромный выбор различных параметров, смотрите сами в дефолтном конфиге для пула www.
Чаще на практике бывает что весь лог доступа не нужен, нужны только заведомо проблемные запросы. Таковыми являются те что долго выполняются. Для таких случаев есть отдельная опция — slowlog:
задает путь к файлу, например:
slowlog = /var/log/php-fpm/$pool_slow.log
а следующая опция задает время выполнения, после которого мы считаем запрос «медленным»:
А это опция для особо злых запросов:
медленные запросы могут быть реальной проблемой. К тому же в какойто момент компиляция php файла по неким причинам может вообще затянуться на века … создавая никому ненужную нагрузку на сервер. Для таких случаев придумана данная опция, если выставить ее к примеру 10 секунд, то все запросы обрабатывающиеся fastcgi процессом более 10 секунд будут просто убиваться pm-ом.
Максимальное количество открытых файлов, глобально задано операционной системой, но можно и явно задать для пула:
Корневая директория для процессов пула, очень полезная опция для повышения безопасности. Особенно для shared-хостингов.
Перенаправлять с воркеров stdout и stderr в родительский процесс.
Это дает возможность логировать результаты работы процессов. Существенно помогает в дебаге, но уменьшает производительность, по умолчанию выключено, для включения задайте значение yes
Розширения принимаемые для обработки можно задать явно:
Например:
security.limit_extensions = .php .php5
Файлы с другими розширениями обрабатываться не будут.
Также в каждом пуле можно отдельно задать любые нужные вас переменные окружения. Например:
Ну и напоследок — переназначение глобальных настроек php.ini. Например:
Конкретные примеры будут приведены в следующей статье, а на данный момент все …
Хай щастить!