Сообщение русским фашистам: Идите нах#й!!!
diff.org.ua
Linux/BSD Проще не бывает!
Купил авто — BMW E46 320D
Сбылась мечта идиота, я купил себе BMW. Не E36 как когдато хотел и не E21 как хотел недавно, а семейный универсал BMW E46. Время тикает, семья расширяется и приходит понимание что машина должна возить не только попу владельца но еще и много всякой ерунды — детские каляски, велосипеды и тому подобный семейный инвентарь. Решение покупки было довольно спонтанным, давно присматривал машину в Европе «под растаможку». Последний закон с льготным акцизом (нижайший поклон евробляхерам!) меня всетаки подбил на авантюру с пригоном авто. Изначальная идея была пригнать самому, темболее что в Вильнюсе у меня живут хорошие друзья, можно спокойно пожить у них хоть неделю, пока не найдется достойный кандидат. Но изучив подробнее механизм пригона авто я понял что это весьма сложная и запутанная процедура, требующая и знаний и опыта. Узнав что за услугу выбор-пригон берут всего 500$ я понял что это мой вариант. А что растаможка? Тот же человек после пригона пообещал и растаможить через своего брокера — услуги брокера 320$. Авто выбирали BMW E46 320D рестайл (2001 — 2005 год) в диапазоне от 2500 до 3000 евро. Таможенных платежей при таких параметрах должно было получиться от 60.000 до 75.000 грн. Также не забываем о доп засходах на человека который будет пригонять — проезд, проживание, питание, европейская страховка авто, заправка — 200$
Итого, в теории машина на укр номерах будет стоить около 7000$
Смысл покупать в Европе есть даже в случае небольшого увеличения расходов (до 10%) так как аналогичные варианты на рынке Украины начинаются от 8000$
Искали, смотрели, подбирали и выбрали такую машинку:
BMW_E46_320D_Outside
BMW E46 320D Inside
BMW E46 320D Panel
Цена на укр номерах получилась 7160$
Радости нет предела, есть несколько некритичных косяков — устраним потихоньку, в остальном машинка огонь.
Хай шастить!
Полезные «однострочники»
Иногда мы очень ждем какогото события, например добавления записи в DNS, чтобы оперативно получить информацию и не долбить без конца одну и ту же команду по клавиатуре можно сделать так:
while [ $? -eq 0 ];do host site.com.ua;sleep 3;done
Сравнить 2 столбика, и вывести только те строки, содержание которых не совпадает
awk '{if ($1 != $2)print $1,$2}' < aliases.txt
Вывести список установленных пакетов по маске (без версий):
root@srv:~# dpkg -l |grep php |awk '{print $2}' |sed '{:q;N;s/\n/\ /g;t q}'
libapache2-mod-php5 php-pear php5 php5-cgi php5-cli php5-common php5-curl php5-dbg php5-gd php5-imagick php5-json php5-mcrypt php5-memcache php5-mhash php5-mysql php5-readline php5-sasl php5-tidy php5-xmlrpc php5-xsl
root@srv:~#
libapache2-mod-php5 php-pear php5 php5-cgi php5-cli php5-common php5-curl php5-dbg php5-gd php5-imagick php5-json php5-mcrypt php5-memcache php5-mhash php5-mysql php5-readline php5-sasl php5-tidy php5-xmlrpc php5-xsl
root@srv:~#
Восстановить заархивированный архив SQL дампа:
gunzip -c xxx.sql.gz |mysql -u root -p db
Бекап всего блочного устройства удаленно с помощью ssh и dd.
С удаленного хоста:
$ dd if=/dev/sda | gzip -1 - | ssh user@local dd of=image.gz
С локального хоста на удаленный:
$ ssh user@remote "dd if=/dev/sda | gzip -1 -" | dd of=image.gz
Найти файлы и которые содержат «MY PATTERN» и скопировать в /dest/dir :
find . -type f -exec grep -ilR "MY PATTERN" {} \; | xargs -I % cp % /dest/dir/
Проверка FTP, или просто коннект в active mode с debug:
lftp -e 'debug 10;set ftp:passive-mode off; set ftp:auto-passive-mode no; ls; bye;' -u user,password ftp://ftp.site.com
Построить рейтинг стран источников пакетов из дамп-файла (должны быть установлены пакеты geoip-bin geoip-database):
tcpdump -ntr somedump.out |sed -e 's/IP\ //g' -e 's/\ .*//'|cut -d'.' -f1-4 |uniq | xargs -n 1 geoiplookup { } |sort | uniq -c | sort -n
Отрезать кусочек видео от (время 00:00:00) до (время 00:39:03) без перекодирования:
ffmpeg -i VIDEO.mp4 -vcodec copy -acodec copy -ss 00:00:00 -t 00:39:03 VIDEO_Cutted.mp4
Будет дополняться …
Хай щастить!
Debian Jessie: WEB-сервер — ускоряемся … (memcached, xcache)
Это заметка из цикла стетей моего небольшого HowTo по Debian Jessie.
Попробуем немного ускорить выдачу сервером web-контента. Начнем с простого пятиминутного тюнинга … сессии. По умолчанию сессии пользователей на сервере хранятся в виде отдельных файликов на файловой системе в директории /var/lib/php5/sessions Это вполне отлично при малом количестве посетителей ресурса, но становится проблемой при увеличении посещаемости, так как дисковые операции очень «дорогие» и «тяжелые» с точки зрения сервера. Такой способ хранения сессий порождает излишнюю нагрузку на дисковую подсистему сервера и замедляет выдачу контента пользователям. Выход придуман давным давно — перенести сессии в RAM-у сервера. Простейшим решением является сервис memcached который представляет из себя key value базу данных работающую исключительно в оперативной памяти. Это, кстати, таит в себе и побочный неприятный момент — в случае перезапуска сервиса memcached или сервера целяком — база очищается, а значит пользователям придется «перелогиниться». Если это критичный для вас момент — тогда лучше использовать сервис который синкает базу данных на диск, например couchbase или redis. Но я не дорожу своими сессиями, потому что пользователей у меня чуть больше чем 1 🙂 поэтому буду использовать memcached
Установим необходимые пакеты:
gw:~$ sudo apt-get install memcached php5-memcached
Открываем основной конфиг memcached:
gw:~$ sudo vim /etc/memcached.conf
По умолчанию сервис запускается с базой в 64MB, для меня это мало (чуть позже расскажу почему) — ставлю 128 MB:
-m 128
Запускаем службу memcached:
gw:~$ sudo systemctl start memcached
Проверяем что служба «слушает» порт 11211:
gw:~$ sudo netstat -lnp |grep mem
tcp 0 0 127.0.0.1:11211 0.0.0.0:* LISTEN 3187/memcached
udp 0 0 127.0.0.1:11211 0.0.0.0:* 3187/memcached
gw:~$
tcp 0 0 127.0.0.1:11211 0.0.0.0:* LISTEN 3187/memcached
udp 0 0 127.0.0.1:11211 0.0.0.0:* 3187/memcached
gw:~$
Теперь перестроим php таким образом чтобы он хранил сессии в memcached, а не в файлах на диске. Открываем конфиг php.ini для fpm:
gw:~$ sudo vim /etc/php5/fpm/php.ini
Ищем там секцию [Session] и настраиваем ее вот так (привожу только те параметры что поменял, остальные оставляем по дефолту):
session.save_handler = memcached
session.save_path = "127.0.0.1:11211"
session.gc_probability = 1
session.save_path = "127.0.0.1:11211"
session.gc_probability = 1
Перезапускаем сервис php5-fpm:
gw:~$ sudo systemctl restart php5-fpm.service
Если вы используете в 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, он достаточно стабилен и продолжает развиваться. Достаточно часто встречал в сети лестные отзывы о нем. Пробую прикрутить …
Установим необходимые пакеты:
gw:~$ sudo apt-get install php5-xcache
Приятной особенностью данного модуля является наличие web-админки где можно посмотреть текущие настройки, статистику, очистить кеш и тп Это не обязательная фича данного модуля, можно не заморачиваться, но мне было интересно — решил настроить.
Генерим пароль в админку XCache (иначе никак):
gw:~$ echo -n "_mypassword_" | md5sum
34819d7beeabb9260a5c854bc85b3e44 -
gw:~$
34819d7beeabb9260a5c854bc85b3e44 -
gw:~$
Для настройки модуля xcache открываем его конфиг:
gw:~$ sudo vim /etc/php5/fpm/conf.d/20-xcache.ini
Вот такой конфиг получился (только то что поменял от дефолта):
[xcache.admin]
xcache.admin.enable_auth = On
; Configure this to use admin pages
xcache.admin.user = "xcache_admin"
; xcache.admin.pass = md5($your_password)
xcache.admin.pass = "34819d7beeabb9260a5c854bc85b3e44"
xcache.size = 64M
xcache.count = 2
xcache.gc_interval = 86400
xcache.var_size = 8M
xcache.var_count = 2
xcache.var_gc_interval = 86400
xcache.optimizer = On
xcache.admin.enable_auth = On
; Configure this to use admin pages
xcache.admin.user = "xcache_admin"
; xcache.admin.pass = md5($your_password)
xcache.admin.pass = "34819d7beeabb9260a5c854bc85b3e44"
xcache.size = 64M
xcache.count = 2
xcache.gc_interval = 86400
xcache.var_size = 8M
xcache.var_count = 2
xcache.var_gc_interval = 86400
xcache.optimizer = On
Перезапускаем сервис php5-fpm:
gw:~$ sudo systemctl restart php5-fpm.service
Про настройку WEB-интерфейса данного модуля расскажу чуть позже, настроим его вместе с другими популярными WEB-приложениями (PHPMyAdmin, PostfixAdmin, Roundcube).
Теоретически такой вариант кеширования должен работать быстрее чем основанный на memcached, чтобы убедиться в этом нужно тестировать, но это уже отдельная тема. Модуль работает сразу после его включения в php5. Для большей эффективности можно использовать плагины со стороны CMS, например для WordPress можно попробовать вот этот модуль. Устанавливается он не сложно, по инструкции. Дополнительных действий никаких, просто ждем пока наполнится кеш и наступит нирвана 🙂 Напомню что в данном варианте кеш очищается при рестарте сервиса php5-fpm
Незнаю будет ли кому полезно, получилось несколько сумбурно …
Хай щастить!
Debian Jessie: Установка и настройка bacula
Это заметка из цикла стетей моего небольшого 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 …)
С ролями определились, вперед к настройке! Читать полностью
Debian Jessie: Настройка mysql-server (MariaDB Server)
Это заметка из цикла стетей моего небольшого HowTo по Debian Jessie.
Для меня тюнинг mysql — это такой себе постоянный вялотекущий процесс который не имеет ни начала ни конца. Базы данных вцелом — это огромный кусок IT-индустрии в котором нужно вариться постоянно чтобы быть специалистом. Признаюсь честно, я не очень интересуюсь базами данных, поэтому настройку обычно свожу к соблюдению общих рекомендаций, не более …
Тут сделаю еще небольшую ремарку, особенно полезную новичкам. Настройка любой БД — это очень индивидуальный процесс, поэтому если вы видите на какомто ресурсе четкие рекомендации как и что нужно тюнить — не стоить этому верить. Разбираться нужно всеравно самому, анализировать конкретный сервер с конкретной нагрузкой на конкретном железе. Львиная доля оптимизации лежит также и на грамотной постройке самой базы, наличию правильных индексов и тд и тп Тут нам здорово помогает фича сбора статистики самим mysql-сервером, о ней чуть позже. Читать полностью
Debian Jessie: настройка бэкапа баз MySQL
Это заметка из цикла стетей моего небольшого HowTo по Debian Jessie.
Бэкапы и тормоза придумали трусы … это понятно. Непонятно только что делать когда железка померла или сайт похакали. Чтобы не попадать в такую непонятную и неприятную ситуацию — настроим автобэкап. Сразу скажу, что это только первый этап бэкапа, он делается на тот же хост где расположен mysql, следующим этапом будет настройка bacula — она заберет и файлы баз и директории с сайтами на удаленное хранилище … что обеспечит сохранность данных даже в случае поломки сервера.
У меня LVM, поэтому директорию для хранения бэкапов баз я решил расположить на отдельном LV.
Примерно прикиньте размер своих баз, учтите что храниться будет несколько бэкапов в заархивированном виде. В моем случае вполне хватит 2GB.
Создаем LV размером 2GB:
gw:~$ sudo lvcreate -L 2g -n lv_backup vgraid1
Logical volume "lv_backup" created
gw:~$
Logical volume "lv_backup" created
gw:~$
Форматируем новый LV в ext4:
gw:~$ sudo mkfs.ext4 -L BACKUP /dev/mapper/vgraid1-lv_backup
mke2fs 1.42.12 (29-Aug-2014)
Creating filesystem with 524288 4k blocks and 131072 inodes
Filesystem UUID: b75fc3b1-4089-445b-8077-0840ad049348
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912
Allocating group tables: done
Writing inode tables: done
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: done
gw:~$
mke2fs 1.42.12 (29-Aug-2014)
Creating filesystem with 524288 4k blocks and 131072 inodes
Filesystem UUID: b75fc3b1-4089-445b-8077-0840ad049348
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912
Allocating group tables: done
Writing inode tables: done
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: done
gw:~$
Создаем директорию для бэкапов:
gw:~$ sudo mkdir /backup
Для автомонтирования раздела при старте сервера прописываем в /etc/fstab
gw:~$ sudo vim /etc/fstab
Вот такую строчку:
/dev/mapper/vgraid1-lv_backup /backup ext4 noatime,nodiratime,nodev,nosuid,noexec 1 2
Монтируем новый раздел:
gw:~$ sudo mount -a
Создаем директорию на lv_backup для будущих бэкапов mysql баз:
gw:~$ sudo mkdir /backup/mysql
Не забываем что это бэкапы баз, там есть много разной инфы, в том числе и приватной, поэтому не забываем урезать права на директорию. Доступ только тем что имеет sudo:
gw:~$ sudo chmod 0700 /backup/mysql
Создаем директорию для админских скриптов:
gw:~$ sudo mkdir /root/scripts
Создаем скрипт который будет бекапить базы:
gw:~$ sudo vim /root/scripts/mysql_db_backup.sh
С вот таким содержимым (не забываем сменить BASES_FOR_BACKUP и mysql_root_passwd_here на свои значения):
#!/bin/bash
# Script for BackUP MySQL bases
# Wrote at night 12.07.2010
# By Black_13
DATE=`date +%F`
BACKUP_DIR="/backup/mysql"
BASES_FOR_BACKUP="wordpress drupal6 evedb bmwdb"
# <Clean Old Archives> #
find ${BACKUP_DIR} -ctime +15 -exec rm -f '{}' \;
cd ${BACKUP_DIR}
for DATABASE in ${BASES_FOR_BACKUP}
do
mysqldump --user='root' --password='mysql_root_passwd_here' ${DATABASE} > ${DATABASE}-${DATE}.sql
bzip2 -9 ${DATABASE}-${DATE}.sql
done
# Script for BackUP MySQL bases
# Wrote at night 12.07.2010
# By Black_13
DATE=`date +%F`
BACKUP_DIR="/backup/mysql"
BASES_FOR_BACKUP="wordpress drupal6 evedb bmwdb"
# <Clean Old Archives> #
find ${BACKUP_DIR} -ctime +15 -exec rm -f '{}' \;
cd ${BACKUP_DIR}
for DATABASE in ${BASES_FOR_BACKUP}
do
mysqldump --user='root' --password='mysql_root_passwd_here' ${DATABASE} > ${DATABASE}-${DATE}.sql
bzip2 -9 ${DATABASE}-${DATE}.sql
done
Также обратите внимание на команду find в скрипте:
find ${BACKUP_DIR} -ctime +15 -exec rm -f '{}' \;
Это очистка архивов старше 15-ти дней. Если вам нужно больше/меньше — просто исправьте данную циферку на нужную.
Даем скрипту права на выполнение:
gw:~$ sudo chmod +x /root/scripts/mysql_db_backup.sh
Итак, на данный момент директория с бекапами пуста, проверим это:
gw:~$ sudo ls -l /backup/mysql/
total 0
gw:~$
total 0
gw:~$
Пробуем запустить скрипт (не делайте это если база в активном использовании, лучше это делать когда база в минимальной нагрузке):
gw:~$ sudo /root/scripts/mysql_db_backup.sh
В случае корректного выполнения никакого вывода скрипт не дает, только если есть ошибки. У меня отработал без ошибок, вот листинг директории /backup/mysql после выполнения скрипта:
gw:~$ sudo ls -l /backup/mysql/
total 1324
-rw-r--r-- 1 root root 1257639 Oct 14 10:37 wordpress-2015-10-14.sql.bz2
-rw-r--r-- 1 root root 92233 Oct 14 10:38 evedb-2015-10-14.sql.bz2
...
gw:~$
total 1324
-rw-r--r-- 1 root root 1257639 Oct 14 10:37 wordpress-2015-10-14.sql.bz2
-rw-r--r-- 1 root root 92233 Oct 14 10:38 evedb-2015-10-14.sql.bz2
...
gw:~$
Теперь добавим скрипт бэкапа в root-овый crontab чтобы он выполнялся автоматически каждый день в 03:00 ночи:
gw:~$ sudo crontab -e
Пишем вот следующее (не забывайте в конце оставлять пустую строку):
# m h dom mon dow command
0 3 * * * /root/scripts/mysql_db_backup.sh
0 3 * * * /root/scripts/mysql_db_backup.sh
Завтра проверяйте содержимое директории /backup/mysql, там должны быть свежие бекапы …
Хай щастить!
Debian Jessie: Трюки вокруг доступа к sshd (iptables, ipset, geoip)
Это заметка из цикла стетей моего небольшого 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 и его база:
gw:~$ sudo apt-get install geoip-bin geoip-database
В Debian модуль TARPIT находится в пакете дополнительных модулей iptables. Установим их:
gw:~$ sudo apt-get install xtables-addons-dkms
Ставим необходимый пакет для добавления ipset:
gw:~$ sudo apt-get install ipset
Одной из приятных фишек таблиц ipset является опция timeout. Она задает количество времени (в секундах) которое элемент содержится в таблице. По истечении timeout-а — элемент автоматически удаляется из таблицы.
Пример борьбы с ssh брутфорсерами:
1. Создаем таблицу, в нее скриптом проверки geoip будем добавлять ботов, timeout ставим 2 часа:
gw:~$ sudo ipset create ssh_bots hash:ip hashsize 16384 timeout 7200
2. Загрузим модуль ядра для действия iptables TARPIT:
gw:~$ sudo modprobe xt_TARPIT
3. Напомню что вот здесь мы базово настроили iptables. Сразу перед правилом розрешающим конект на port 22 добавим правило для блокировки ssh ботов из таблицы ssh_bots. Должно получиться вот так:
...
# Allow DNS connections from anywhere
-A INPUT -p udp --dport 53 -j ACCEPT
-A INPUT -p tcp --dport 53 -j ACCEPT
# TARPIT ssh_bots table
-A INPUT -m set --match-set ssh_bots src -p TCP --dport 22 -j TARPIT
# Allows SSH connections
# The --dport number is the same as in /etc/ssh/sshd_config
-A INPUT -p tcp -m state --state NEW --dport 22 -j ACCEPT
...
# Allow DNS connections from anywhere
-A INPUT -p udp --dport 53 -j ACCEPT
-A INPUT -p tcp --dport 53 -j ACCEPT
# TARPIT ssh_bots table
-A INPUT -m set --match-set ssh_bots src -p TCP --dport 22 -j TARPIT
# Allows SSH connections
# The --dport number is the same as in /etc/ssh/sshd_config
-A INPUT -p tcp -m state --state NEW --dport 22 -j ACCEPT
...
4. Теперь сооружаем чуть модифицированный скрипт проверки geoip — /usr/local/bin/ssh_geoip.sh:
gw:~$ sudo vim /usr/local/bin/ssh_geoip.sh
Вставляем туда следующее …
#!/usr/bin/env bash
PATH="/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin"
ALLOW_COUNTRIES="UA"
if [ $# -ne 1 ]; then
echo "Usage: `basename $0` <ip>" 1>&2
exit 0 # return true in case of config issue
fi
COUNTRY=`geoiplookup $1 |sed -e 's/^.*Edition\:\ //' -e 's/\,.*$//'`
if [[ ${COUNTRY} =~ ${ALLOW_COUNTRIES} ]]; then
logger "sshd ALLOW connection from IP $1 - [${COUNTRY}]"
exit 0
else
logger "sshd DENY connection from IP $1 - [${COUNTRY}]"
ipset add ssh_bots $1
exit 1
fi
PATH="/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin"
ALLOW_COUNTRIES="UA"
if [ $# -ne 1 ]; then
echo "Usage: `basename $0` <ip>" 1>&2
exit 0 # return true in case of config issue
fi
COUNTRY=`geoiplookup $1 |sed -e 's/^.*Edition\:\ //' -e 's/\,.*$//'`
if [[ ${COUNTRY} =~ ${ALLOW_COUNTRIES} ]]; then
logger "sshd ALLOW connection from IP $1 - [${COUNTRY}]"
exit 0
else
logger "sshd DENY connection from IP $1 - [${COUNTRY}]"
ipset add ssh_bots $1
exit 1
fi
Это же скрипт, не забываем дать права на выполнение:
gw:~$ sudo chmod +x /usr/local/bin/ssh_geoip.sh
5. Теперь подправим конфиг /etc/hosts.deny добавив туда:
sshd: ALL
6. Теперь подправим конфиг /etc/hosts.allow добавив туда:
# Whitelist for LAN network 192.168.0.0/16
sshd: 192.168.
# Check Access by GeoIP
sshd: ALL: aclexec /usr/local/bin/ssh_geoip.sh %a
sshd: 192.168.
# Check Access by GeoIP
sshd: ALL: aclexec /usr/local/bin/ssh_geoip.sh %a
Итак, теперь соединение к 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 в таком виде:
удачные:
Nov 22 14:14:11 gw logger: sshd ALLOW connection from IP 77.91.130.111 - [UA]
неудачные:
Nov 22 11:30:44 gw logger: sshd DENY connection from IP 123.151.42.61 - [CN]
Посмотреть листинг таблицы ssh_bots:
gw:~$ sudo ipset list ssh_bots
Name: ssh_bots
Type: hash:ip
Revision: 3
Header: family inet hashsize 16384 maxelem 65536 timeout 7200
Size in memory: 295304
References: 1
Members:
222.186.34.74 timeout 2075
43.229.53.69 timeout 3998
gw:~$
Name: ssh_bots
Type: hash:ip
Revision: 3
Header: family inet hashsize 16384 maxelem 65536 timeout 7200
Size in memory: 295304
References: 1
Members:
222.186.34.74 timeout 2075
43.229.53.69 timeout 3998
gw:~$
Хай щастить!
Debian Jessie: Настройка WEB сервера (Apache2/Nginx/PHP-FPM)
Это статья из цикла стетей моего небольшого 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
Поехали … Читать полностью
Debian Jessie: Установка и настройка PHP5-FPM
Это статья из цикла стетей моего небольшого HowTo по Debian Jessie.
Современный Интернет трудно представить без языка PHP, но возможностей работать с PHP из коробки нет ни у кого среди WEB-серверов. С Apache2 мы уже разобрались, установив для него модуль php, а вот с Nginx не так просто — он умеет работать с PHP по протоколу CGI. Наиболее прогрессивной вариацией CGI на сегодняшний день является FastCGI, а менеджер процессов для него — PHP-FPM. Он есть в стандартных репозиториях Debian под именем php5-fpm.
Установим:
gw:~$ sudo apt-get install php5-fpm
Также для PHP наверняка понадобятся некоторые модули, если чегото не хватит — доустановим в процессе разворачивания сайтов:
gw:~$ sudo apt-get install php5-curl php5-mcrypt php5-mysql
Не забываем добавить сервис в автозагрузку:
gw:~$ sudo systemctl enable php5-fpm.service
Теперь к настройкам.
После установки пакетов у вас появится отдельная директория для настроек php-fpm — /etc/php5/fpm
В ней расположен основной конфиг сервиса — /etc/php5/fpm/php-fpm.conf Настраивать я там особо ничего не стал, просто проверил чтобы была настройка с инклудами пулов:
...
include=/etc/php5/fpm/pool.d/*.conf
...
include=/etc/php5/fpm/pool.d/*.conf
...
Хорошим правилом на хостинге где много сайтов под каждый сайт настраивать отдельного системного пользователя и отдельный php пул. Это дает возможность гибко настраивать php для каждого отдельного сайта, а также, «изолировать» на уровне php сайты друг от друга. Настройка пулов совсем несложная. Конфиги расположены в директории /etc/php5/fpm/pool.d По умолчанию в php-fpm есть один пул — www с конфигом — /etc/php5/fpm/pool.d/www.conf Я обычно выключаю данный конфиг простым переименованием файла в example или default:
gw:~$ sudo mv /etc/php5/fpm/pool.d/www.conf /etc/php5/fpm/pool.d/default
и потом использую в качетсве шаблона при создании своих пулов. Как и обещал, в следующей статье про WEB я приведу примеры конфигов двух вариантов запуска пулов php-fpm: в chroot и без него. А сейчас хочу просто перечислить основные настройки пулов и коротко их описать.
Название пула. В самом верху конфига в квадратных скобках пишут название пула, например:
[www] или [somepool] и тп
Пользователь и группа:
user =
group =
group =
Это очень важный параметр, имя пользователя и группа от которого будут запускаться php-процессы. Например:
user = www-data
group = www-data
Где слушаем подключения:
listen =
Может быть как 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.allowed_clients =
Используется в случае listen TCP сокета на всех интерфейсах. Я бы рекомендовал закрывать фаерволом, но тем не менее на уровне сервиса можно контроллировать доступ к сокету просто перечислив необходимые ip — остальные «идут лесом» Например розрешим доступ только с двух ip:
listen.allowed_clients = 192.168.1.100, 192.168.1.200
Настройка менеджера процессов, это очень важная часть конфига:
pm =
pm.max_children =
pm.start_servers =
pm.min_spare_servers =
pm.max_spare_servers =
pm.max_children =
pm.start_servers =
pm.min_spare_servers =
pm.max_spare_servers =
Тут трудно описать лучше чем в официальной документации, поэтому лучше прочтите сами и настраивайте с понимаением дела.
Время в секундах после которого простаивающие процессы будут убиты, работает только при pm = ondemand:
pm.process_idle_timeout =
Количество реквестов после которого fastcgi процесс полностью перезапустится:
pm.max_requests =
Это очень полезная опция, реально может помочь при работе с проектом в котором есть баги с утечками памяти. Конечно же это не решает проблему кривого кода, но зато существенно сокращает количество сегфолтов.
Вцелом хочу подитожить — грамотная настройка pm* опций в пуле php-fpm помогает «держать на плаву» даже самые безнадежные php поделия 🙂
Статистика пула:
pm.status_path =
Полезная опция для мониторинга и статистики, включить можно например так:
pm.status_path = /$pool-status
после чего настраиваем проксирование некоторого локейшена в домене localhost на данный URL. Пример:
server {
listen 127.0.0.1:901;
location = /backend-status {
access_log off;
fastcgi_pass 127.0.0.1:9001;
fastcgi_param SCRIPT_FILENAME $fastcgi_script_name;
include fastcgi_params;
allow 127.0.0.1;
deny all;
}
}
listen 127.0.0.1:901;
location = /backend-status {
access_log off;
fastcgi_pass 127.0.0.1:9001;
fastcgi_param SCRIPT_FILENAME $fastcgi_script_name;
include fastcgi_params;
allow 127.0.0.1;
deny all;
}
}
после перезапуска nginx мы можем посмотреть что же там за статистика пула:
gw:~$ curl http://localhost:901/fpm-status
pool: backend
process manager: dynamic
start time: 05/Nov/2015:18:19:39 +0000
start since: 40412
accepted conn: 5378
listen queue: 0
max listen queue: 0
listen queue len: 65535
idle processes: 9
active processes: 1
total processes: 10
max active processes: 3
max children reached: 0
slow requests: 0
gw:~$
pool: backend
process manager: dynamic
start time: 05/Nov/2015:18:19:39 +0000
start since: 40412
accepted conn: 5378
listen queue: 0
max listen queue: 0
listen queue len: 65535
idle processes: 9
active processes: 1
total processes: 10
max active processes: 3
max children reached: 0
slow requests: 0
gw:~$
эти данные можно анализировать системой мониторинга, накапливать статистику, рисовать графики, обложить триггерами и оповещать ответственных в случай беды … но это уже совсем другая история.
Также для мониторинга доступности можно использовать более простой механизм ping-pong:
ping.path =
Значение по умолчанию /ping. Если данный URI спроксировать nginx-ом по образу и подобию приведенному выше, то в ответ будем получать 200-ку и некоторый ответ, который по умолчанию pong но можно задать кастомный следующей опцией:
ping.response =
Очень полезная фишка для простейшего мониторинга доступности сервиса.
Лог запросов, для дебага незаменимая опция:
access.log =
Просто задаем путь к логу, например так:
access.log = /var/log/php-fpm/$pool_access.log
Формат лога доступа:
access.format =
Огромный выбор различных параметров, смотрите сами в дефолтном конфиге для пула www.
Чаще на практике бывает что весь лог доступа не нужен, нужны только заведомо проблемные запросы. Таковыми являются те что долго выполняются. Для таких случаев есть отдельная опция — slowlog:
slowlog =
задает путь к файлу, например:
slowlog = /var/log/php-fpm/$pool_slow.log
а следующая опция задает время выполнения, после которого мы считаем запрос «медленным»:
request_slowlog_timeout =
А это опция для особо злых запросов:
request_terminate_timeout =
медленные запросы могут быть реальной проблемой. К тому же в какойто момент компиляция php файла по неким причинам может вообще затянуться на века … создавая никому ненужную нагрузку на сервер. Для таких случаев придумана данная опция, если выставить ее к примеру 10 секунд, то все запросы обрабатывающиеся fastcgi процессом более 10 секунд будут просто убиваться pm-ом.
Максимальное количество открытых файлов, глобально задано операционной системой, но можно и явно задать для пула:
rlimit_files =
Корневая директория для процессов пула, очень полезная опция для повышения безопасности. Особенно для shared-хостингов.
chroot =
Перенаправлять с воркеров stdout и stderr в родительский процесс.
catch_workers_output =
Это дает возможность логировать результаты работы процессов. Существенно помогает в дебаге, но уменьшает производительность, по умолчанию выключено, для включения задайте значение yes
Розширения принимаемые для обработки можно задать явно:
security.limit_extensions =
Например:
security.limit_extensions = .php .php5
Файлы с другими розширениями обрабатываться не будут.
Также в каждом пуле можно отдельно задать любые нужные вас переменные окружения. Например:
env[HOSTNAME] = $HOSTNAME
env[PATH] = /usr/local/bin:/usr/bin:/bin
env[TMP] = /tmp
env[TMPDIR] = /tmp
env[TEMP] = /tmp
env[PATH] = /usr/local/bin:/usr/bin:/bin
env[TMP] = /tmp
env[TMPDIR] = /tmp
env[TEMP] = /tmp
Ну и напоследок — переназначение глобальных настроек php.ini. Например:
php_flag[display_errors] = off
php_admin_value[error_log] = /var/log/fpm-php.www.log
php_admin_flag[log_errors] = on
php_admin_value[memory_limit] = 16M
php_admin_value[error_log] = /var/log/fpm-php.www.log
php_admin_flag[log_errors] = on
php_admin_value[memory_limit] = 16M
Конкретные примеры будут приведены в следующей статье, а на данный момент все …
Хай щастить!
Cogito ergo sum!
«Існую, оскільки нікому невідомий»