Unix notes

Установка простой системы мониторинга Munin

admin — Thu, 11 Aug 2011 12:13:28 +0000

Мунин идеально подойдет для тех администраторов, которым надо мониторить нагрузку (именно нагрузку, а не доступность!) одного-двух-трех серверов и не хочется заморачиваться с такими монстрами как Cacti.

Мунин состоит из двух частей: Munin-node – демон, который ставится на хост, который надо мониторить – она собирает всю информацию о системе. Вторая часть – пакет munin – он уже рисует графики по данным с одной или нескольких машин и генерит из них статические странички и картинки.
Итак, сначала установим пакет munin, к слову, это перловый скрипт и ставит с собой несколько перловых библиотек:

yum install munin

Он пропишется в /etc/cron.d для запуска раз в 5 минут, создаст /var/www/html/munin – туда будет генериться статика, которую можно отдавать любым веб-сервером. Конфиги мунина лежат в /etc/munin. Прописываем мунин в Апаче, можно просто алиасом к каком-нибудь существующему виртуалхосту:

Alias /munin/ /var/www/html/munin/

Options Indexes FollowSymlinks
AllowOverride All

Релоадим апач и устанавливаем munin-node (эту часть проделываем на всех серверах, которые надо мониторить):

yum install munin-node
chkconfig munin-node on
/etc/init.d/munin-node start

Если мы ставим оба пакета на одну машину, то нижесказанное проделывать не надо – все работает по дефолту.
Munin-node работает как демон, к которому на порт 4949 периодически подключается munin, поэтому в /etc/munin/munin-node.conf добавляем дериктиву allow ^127\.0\.0\.1$ с адресом munin.

На машине, на которой установлен Munin в /etc/munin/munin.conf добавляем новый хост по типу:

[my-second-server]
address 1.2.3.1
use_node_name yes

Устанавливаем акселлератор APC на CentOS+Apache

admin — Wed, 03 Aug 2011 13:13:15 +0000

Если у вас нагруженное веб-приложение и тесты показывают, что одно из узких мест это исполнение php-кода, то имеет смысл установить PHP-акселлератор. Один из лучших это APC от разработчиков самого PHP. Принцип его работы такой: он держит скомпилированный код php-файлов в памяти и при повторном обращении быстро его отдает.
Устанавливаем его из репозитория Remi:

yum --enablerepo=remi install php-pecl-apc

Теперь смотрим конфиг /etc/php.d/apc.ini, самые важные параметры:
# Включаем кэширование
apc.enabled=1
# количество блоков с кэшем в памяти
apc.shm_segments=1
# размер каждого блока
apc.shm_size=256M
# время устаревания кэшированных файлов
apc.ttl=3600
apc.max_file_size=1M
# если выключить, apc не будет проверять не изменился ли файл при обращении к нему.
apc.stat=1

Для каждого сервера надо подбирать свои параметры размера блока и срока устаревания кэша. Потому как иногда при заполнении памяти APC может падать с ошибкой “unable to allocate memory for pool” подробнее читать тут.
Для мониторинга состояния кэша APC удобно использовать прилагаемую к дистрибутиву утилиту apc.php. Просто скачиваете дистр и кладете файлик в любой виртуалхост.

Поиск шеллов на сервере

admin — Sat, 09 Jul 2011 05:34:04 +0000

Иногда возникает необходимость проверить нет ли на вашем сервере залитых шеллов через дырявые скрипты. Естественно, что гарантий тут никто не дает, но хотя бы простые проверки иногда запускать можно. Все нижесказанное относится к PHP шеллам:

egrep -rlZ -e "eval\(gzinflate\(" /usr/home
egrep -rlZ -e "gzinflate" /usr/home
egrep -rlZ -e "eval\(str_replace" /usr/home

grep -Rl "r57shell|c99madshell|eval\|base64_decode" /home

Так же имеет смысл поискать следующие строчки: passthru, shell_exec, system, phpinfo, base64_decode, edoced_46esab, chmod, mkdir

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

Для поиска руткитов рекомендую воспользоваться RKHunter. Но это тоже не дает гарантий. Если есть возможность рекомендуется переустановить систему и восстановить сайты из бэкапов.

Еще один неплохой Yum-репозиторий для СentOS

admin — Tue, 29 Mar 2011 12:38:22 +0000

Расположен здесь http://www.webtatic.com/.
Добавляем в систему:

rpm -Uvh http://repo.webtatic.com/yum/centos/5/latest.rpm

Замена диска в Raid на linux md

admin — Mon, 28 Mar 2011 05:37:23 +0000

Если вдруг ваш RAID1 поломался и
cat /proc/mdstat говорит:

md2 : active raid1 sda3[2] sdb3[1]
726266432 blocks [2/1] [_U]

Т.е. один диск в зеркале U – up, а другой вылетел.

Смотрим более подробнаю информацию о raid:

mdadm -D /dev/md2

То надо менять винт. Для этого выключаем сервер, меняем винт, включаемся и затем:
Смотрим dmesg |grep sda, что новый винт на месте (в моем случае вылетел sda).
Иногда саппорт дата-цента просит сказать серийный номер винта, который надо заменить. Вот так смотрим подробную инфорамацию по жесткому диску:

hdparm -I /dev/sda

Затем копируем информацию о разделах со старого рабочего винта на новый (не ошибитесь в источнике и назначении!):

sfdisk -d /dev/sdb | sfdisk /dev/sda

В моем случае винты были разбиты на три раздела каждый и каждый из них был собран в md-зеркало с соответствующим разделом на другом винте. Теперь подключаем разделы с sda в существующие md-рэйды:

mdadm --manage /dev/md2 --add /dev/sda3

Не ошибитесь с разделами!
И наблюдаем в cat /proc/mdstat как идет синхронизация.

Кэширование в nginx

admin — Thu, 24 Mar 2011 06:50:14 +0000

Включение кэширования средствами nginx позволяет повысить скорость отдачи часто используемых страниц в очень много раз. Фишка в том, что сгенерированная апачем страница сохраняется в виде готового html-файла на диске и при поступлении запроса на такой же урл (совпадение по md5) файл-кэш быстро отдается клиенту. Кэширование в nginx доступно с версии 0.7.44. Благо в репозитории EPEL уже штатно присутствует 0.8.
К настройке кэширования нужно относиться очень внимательно, потому что на динамических сайтах весьма высока вероятность обрубания функциональности сайта: перестанут работать корзины на сайтах-магазинах, поломаются счетчики просмотров и тд.
Самая простая настройка выглядит так:
Сначала в http-секции прописываем где будет лежать кэш, его размер и время устаревания:

proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=myzone:16m inactive=7d max_size=1024m;

Чистить кэш nginx будет сам. Кстати, в процессе отладки вы можете просто ходить в эту папку и смотреть что там закэшировалось.
Кэш можно включить либо для определенного location либо для всего виртуального хоста.

proxy_no_cache $cookie_logged; #условия, при которых ответ не будет сохраняться в кэш
proxy_cache_bypass $cookie_logged; #условия, при которых ответ не будет браться из кэша
proxy_cache_use_stale error timeout invalid_header updating http_500 http_502 http_503 http_504;
proxy_pass_header Set-Cookie;#разрешает передавать от проксируемого сервера клиенту запрещённые для передачи строки
proxy_ignore_headers "Expires" "Cache-Control"; #запрещает обработку некоторых строк заголовка из ответа проксированного сервера
proxy_cache_valid 200 301 302 304 1h; #время кэширования для разных ответов
proxy_cache myzone; #включает кэширование и задает зону

В процессе настройки посмотрите какие куки и в какой момент отправляет пользователю ваше приложение.
В интернете можно найти готовые конфиги nginx-а для кэширования под различные популярные CMS.
“Тупой” вариант кэширования с большим сроком устаревания кэша можно использовать в момент DDOS-а, тогда есть шанс, что сервер справится с наплывом запросов и сайт хоть и потеряет в функциональности, но останется доступен для поисковых систем и не уронит в след за собой остальные сайты на этом сервере.

Настройка logwatch

admin — Fri, 18 Feb 2011 12:18:21 +0000

Logwatch очень полезная утилита (перловый скрипт), которая ежедневно по крону анализирует системные логи и обо всех подозрительных вещах докладывает вам по почте. Она реально может помочь своевременно обнаружить компрометацию системы. Чаще всего она уже даже установлена в системе и прописана в cron.daily, но не активизирована. Если все-таки не установлена, то ставим:

yum install logwatch

Настройка проста до безобразия, а пользы от скрипта очень много. Просто копируем конфиг-пример /usr/share/logwatch/default.conf в /etc/logwatch/conf/logwatch.conf

В конфиге нужно поправить только MailTo – прописать мыло расположенное на внешнем сервисе, а не на проверяемой системе. Еще можно увеличить детализацию отчетов параметром Detail.

Разные php.ini для Apache и консольных скриптов

admin — Wed, 02 Feb 2011 13:04:27 +0000

Иногда бывает нужно сделать так, чтобы апач и скрипты запускаемые кроном имели разные php.ini. К примеру, для того чтобы ограничить скрипты апача разными disable_functions.
Просто создаем копию php.ini в любом месте, допустим, это будет версия для Apache. Добавляем в нее:

disable_functions=popen,exec,system,passthru,proc_open,shell_exec

Это серьезно усложнит жизнь злоумышленнику на пути повышения привилегий.
И прописываем путь к этому php.ini в httpd.conf:

PHPIniDir /etc/httpd/php.ini

Перезапускаем апач и простеньким скриптом проверяем что получилось:

system('ls -la');
?>

Права на файлы при ssh авторизации по ключу

admin — Tue, 30 Nov 2010 13:22:38 +0000

Все время забываю какие должны быть права поэтому сделаю заметку:
Права на домашний каталог юзера:

drwx------ 5 admin admin 4096 Nov 30 15:42 admin

Каталог .ssh

drwx------ 2 admin admin 4096 Nov 30 15:23 .ssh

authorized_keys

-rw------- 1 admin admin 213 Nov 30 15:23 authorized_keys

Скрипт синхронизации баз, сайтов и конфигов

admin — Wed, 24 Nov 2010 12:44:12 +0000

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

#!/bin/bash

param=" --progress -plzuogthr --compress-level=9 --delete-after"
sitesfromserver1="site1.ru site2.ru site3.ru"
basesfromserver1="basesite1 basesite2 basesite3"

### Apache vhosts - Not need "update" parametr
rsync -e "ssh -p222" --progress -plzogthr --compress-level=9 --delete-after /etc/httpd/vhosts root@server2.domain.com:/etc/httpd

### Nginx vhosts - Not need "update" parametr
rsync -e "ssh -p222" --progress -plzogthr --compress-level=9 --delete-after /etc/nginx/vhosts root@server2.domain.com:/etc/nginx

### Sites sync
for site in $sitesfromserver1
do
rsync -e "ssh -p222" $param /usr/local/www/$site root@server2.domain.com:/usr/local/www
done

### MySQL bases sync
echo "Lock bases on Server1 and Server2"
echo "FLUSH TABLES WITH READ LOCK; SET GLOBAL read_only = ON;" | /usr/bin/mysql -u backup -pPasWord
ssh -p222 root@server2.domain.com 'echo "FLUSH TABLES WITH READ LOCK; SET GLOBAL read_only = ON;" | /usr/bin/mysql -u backup -pPasWord'

echo "Sleep 15s"
sleep 15s

# Bases from Server1
for base in $basesfromserver1
do
rsync -e "ssh -p222" $param /var/lib/mysql/$base root@server2.domain.com:/var/lib/mysql
done

echo "Unlock bases"
echo "SET GLOBAL read_only = OFF; UNLOCK TABLES;" | /usr/bin/mysql -u backup -pPasWord
ssh -p222 root@server2.domain.com 'echo "SET GLOBAL read_only = OFF; UNLOCK TABLES;" | /usr/bin/mysql -u backup -pPasWord'

/etc/init.d/mysqld restart
ssh -p222 root@server2.domain.com /etc/init.d/mysqld restart