Модная штучка

Переносим Cacti и Nagios на другой сервер

Март 16, 2012 | ITшное, Администрирование | Модные словечки , , , , | Оставить свое мнение

Приветствую всех читателей моего уютного бложика!

Решил я на днях отделить систему мониторинга от обычных рядовых серверов и взял под эти нужды простенький впс на базе VDSManager. И стал я все настраивать да переносить, никаких сложностей не возникало, да вот только после того как все подготовительные работы были выполнены, оказалось что графики почему то не рисуются. При чем rrd файлы были на месте, но через веб интерфейс ответ rrdtool был пустым. Я пробовал выполнить от себя команду которая в дебаг режиме пишется в самом какти и в ответ получал либо

No match

либо

Bad system call

Все попытки справиться с этим у меня не увенчались успехом и в итоге я решил что я нифига не понимаю в фрибсд и передал работу разобраться с этой проблемой сторонним админам за деньги.

Несколько дней ожидания и админы дали свой вердикт — судя по всему vdsmanager накладывает какие то свои ограничения на ОС, что не позволяет правильно работать rrdtool которая должна рисовать графики.

Впринципе, для меня это было ожидаемо. Взял я себе тогда другой вдс уже покруче, на базе KVM, правда и стоит он в три раза дороже, но что ж, и тянуть должен бы больше, может еще что навешу на него.

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

Так вот, исходя из этого опыта несколько советов как правильно переехать на новое место обитания мониторинга.

После того как на новом сервере настроены всякие веб сервера, пхп, мускули и т.п., то есть проделана вся работа как и для установки нового кактуса, делаем следующее:

  1. На старом сервере пакуем всю папку /usr/local/www/cacti и делаем дамп базы cacti
  2. Делаем дампы rrd файлов (как это сделать немного ниже)
  3. Скидываем надампеное на новый сервер
  4. На новом сервере копируем с заменой файлы config.php и все файлы из scripts/ без замены файлов, то есть добавляем то,  чего не хватает на новом.
  5. Восстанавливаем из дампов rrd файлы
  6. Ставим скрипт кактуса в крон как и при сетапе нового сервера.

Как сделать бекап и восстановление.

Вообще говоря есть стандартная функциональность rrdtool делать dump & restore. Почему мне этого было мало? — файлов несколько десятков, а запускать команду нужно на каждый файл отдельно, это просто издевательство так делать.

Выход прост — нагуглил уже готовый скрипт для масового переноса —  вот на этом форуме (второй пост)

Для надежности продублирую скрипт еще тут

 

#!/bin/bash

set_dump_values () {
        src_ftype="rrd"
        dest_ftype="xml"
}

set_restore_values () {
        src_ftype="xml"
        dest_ftype="rrd"
}

set_search_path () {
        search_path=$1
        log_path="${search_path}/rra_batch.log"
}

print_usage () {
        echo "Usage: $0 [COMMAND] [-c | -d [PATH]]"
        echo " "
        echo "Summary:"
        echo "Does either an rrdtool dump or an rrdtool restore of all files in the search directory."
        echo "This script will not look for .rrd files or .xml files to use outside of the specified search directory, but will recursively search throught the specified directory."
        echo " "
        echo "Commands:"
        echo "dump     Dumps files with .rrd in the file name to an XML file."
        echo "dump-nh  Dumps files with .rrd in the file name to an XML file."
        echo "         This command puts no headers in the output XML for compatibility with rrdtools 1.2.x."
        echo "restore  Restores files with .xml in the file name to an RRD file."
        echo " "
        echo "Options:"
        echo "-c  Search current working directory."
        echo "-d  Specify search directory."
        exit 0
}

log () {
        echo "[`date +%Y%m%d%H%M%S`] $1" >> ${log_path}
}

rrdtool_command () {
        case $1 in
                dump)
                        log "Dumping \"$name\" to ${new_name}.${dest_ftype}"
                        rrdtool $1 "$name" > "${new_name}.${dest_ftype}"
                        ;;
                dump-nh)
                        log "Dumping with no header \"$name\" to ${new_name}.${dest_ftype}"
                        rrdtool dump "$name" --no-header > "${new_name}.${dest_ftype}"
                        ;;
                restore)
                        log "Restoring \"$name\" to ${new_name}.${dest_ftype}"
                        rrdtool $1 "$name" "${new_name}.${dest_ftype}"
                        ;;
                *)
                        log "Illegal command: ${1}"
                        exit 1
                        ;;
        esac
}

case $1 in
        dump)
                set_dump_values
                ;;
        dump-nh)
                set_dump_values
                ;;
        restore)
                set_restore_values
                ;;
        *)
                print_usage $0
                ;;
esac

case $2 in
        -d)
                set_search_path $3
                ;;
        -c)
                set_search_path `pwd`
                ;;
        *)
                print_usage $0
                ;;
esac

echo "Logging output to $log_path..."
log "Search path set to \"$search_path\"."

for name in $(find $search_path -type f -print | grep [.]${src_ftype})
do
        if [ $name != "." ] ; then
                new_name=""
                OIFS=$IFS
                IFS='.'
                for name_element in $name
                do
                        if [ $name_element != $src_ftype ] ; then
                                if [ -z $new_name ] ; then
                                        new_name=$name_element
                                else
                                        new_name="${new_name}.${name_element}"
                                fi
                        fi
                done
                IFS=$OIFS
                if [ -n $name ] ; then
                        rrdtool_command $1
                fi
        fi
done

log "Finished batch."
echo "Done."
exit 0

Пользоваться им очень просто. Сохраняем скрипт где угодно, пусть это будет ~/rrdmove.sh

После этого на старом сервере:

bash ~/rrdmove.sh dump -d /usr/local/www/cacti/rra/
# создаем архив с дампами
tar -czf ~/rrd.tar.gz /usr/local/www/cacti/rra/*.xml
# кидаем файл на новый сервер
scp ~/rrd.tar.gz user@server:~/

После чего на новом сервер надо закинуть этот же скрипт куда либо, я для примера возьму тот же самый файл ~/rrdmove.sh и делаем следующее:

cd /usr/local/www/cacti/rra/
# распаковываем дампы
tar -xzf ~/rrd.tar.gz
# запускаем скрипт восстановления
bash ~/rrdmove.sh restore -d /usr/local/www/cacti/rra/
# удаляем дампы, они больше не нужны
rm /usr/local/www/cacti/rra/*.xml

Кто то может спросить — почему бы просто не скопировать rrd файлы и не дрочить мозг? — И я отвечу, что именно такой способ у меня возник первым. Но, как оказалось, rrd файлы платформо-зависимы, что означает что не всякие rrd файлы подойдут для новой системы. Отсюда и необходимость в их дампе/ресторе.

Касательно Nagios — там все просто — нужно скопировать и перенести папку /usr/local/etc/nagios/

Только не трогать /usr/local/www/nagios, во всяком случае cgi скрипты там, потому что они тоже платформо-зависимы и я потратил пару часов на то, что бы определить, почему бляха cgi скрипты не работают. Там только конфиг файл стоит перенести со старого, да и то, лучше его поправить заново ручками, а то может на новом сервере нагиос другой версии и там файл немного отличается.

Позже еще будет пост о настройке nagios, а то сразу я его поставил и он стоял без дела фактически  =)

USVN — переводим хост на SSL

Март 10, 2012 | ITшное | Модные словечки , , , , | 1 мнение »

В предыдущем посте я рассказал, как настроить usvn для управления свн на сервере.

Сейчас я тут решил переехать с локальной виртуальной машины на удаленный сервер и соответственно свн поднять там. В целом все делал как и раньше, но решил сайт перевести на ssl соединение.

Сделать это очень просто.

1. Генерирует SSL сертификат.

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout mysitename.key -out mysitename.crt

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

2. Подключаем ssl на nginx, для чего нужно изменить значение listen с 80 на 443 и добавить опции, выкладываю итоговый конфиг nginx:

server {
        listen  443;
        server_name  svn.site.com;

        ssl on;
        ssl_certificate /usr/local/etc/nginx/ssl/svn.site.com.crt;
        ssl_certificate_key /usr/local/etc/nginx/ssl/svn.site.com.key;

        access_log  /var/log/nginx/svn.2kumba.com_access.log;

        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   /usr/local/www/nginx-dist;
        }
        root /usr/local/www/usvn-1.0/public/;

         location /medias {
                try_files       $uri
                                @usvn-backend;
        }

        location  / {
            fastcgi_pass   php-backend;
            fastcgi_param  SCRIPT_FILENAME  /usr/local/www/usvn-1.0/public/index.php;
            include        fastcgi_params;
        }

        location @usvn-backend {
            fastcgi_pass   php-backend;
            fastcgi_param  SCRIPT_FILENAME  /usr/local/www/usvn-1.0/public/index.php;
            include        fastcgi_params;
        }

}

Где путь «/usr/local/etc/nginx/ssl/» это путь к папке где лежит сгенерированный сертификат.

3. Подключаем ssl для apache, для этого добавляю просто перед нужным Location параметры, включащие поддержку ssl. При этом стоит заметить что в этом случае ssl включится для всех хостов которые обслуживаются апачем, но так как  апач у меня используется только для svn то мне это по барабану.

Мой конфиг апача:

 SSLEngine on
    SSLCertificateFile /usr/local/etc/apache22/ssl/svn.site.com.crt
    SSLCertificateKeyFile /usr/local/etc/apache22/ssl/svn.site.com.key

<Location /usvn/svn>
    DAV svn
    SVNParentPath /usr/local/www/usvn-1.0/files/svn
    SVNListParentPath off
    SVNPathAuthz on
    AuthzSVNAnonymous Off

    AuthType Basic
    AuthName "svn repository"
    AuthUserFile /usr/local/www/usvn-1.0/files/htpasswd
    AuthzSVNAccessFile /usr/local/www/usvn-1.0/files/authz
    Require valid-user
</Location>

Путь к SSL сертификатам указывайте тот же что и для nginx. Я себе просто сделал симлинк для удобства.

Рестартуем nginx, apache и все должно уже работать через https://

FreeBSD: проблемма со статикой на nginx.

Февраль 29, 2012 | ITшное | Модные словечки , , | Оставить свое мнение

Итак, если у вас хост настроен правильно, но при запросе любого статического контента сервер вам возвращается ответ 200 ok, но само тело ответа пустое, а логах nginx красуются строки типа

4140#0: *4 sendfile() failed (45: Operation not supported) while sending response to client

Это верный признак того, что вам нужно найти где в конфиге у вас прописано

sendfile on;

и удалить либо изменить на off его значение.

Уже второй раз сталваюсь с этой проблеммой и первый раз я было подумал что это что то с самой ОС, пришлось все переставить/пересобрать, и вот на второй раз таки нашел реальную причину.

График загрузки NGINX для cacti

Декабрь 22, 2011 | ITшное, Администрирование | Модные словечки , , , | Оставить свое мнение

Начал делать график для какти по скриптах, из этого форума http://forums.cacti.net/about26458.html

При тесте скрипта столкнулся с ошибкой:

no (LWP::UserAgent not found)

Свидетельствует о том, что собственно в perl не найдено модуля LWP.

Ставим его так (спасибо за мануалы с http://docstore.mik.ua/orelly/perl3/lwp/ch01_03.htm ):

Вкратце именно то что делал я:

perl -MCPAN -eshell

cpan> install Bundle::LWP

cpan> exit

(были еще промежуточные вопросы так как запускал я первый раз, нажимал просто энтер — предлагалось сделать первоначальную конфигурацию и подобрать лучшие зеркала).

После этого  скрипты выдавали правильную информацию.

./get_nginx_clients_status.pl http://******/nginx_status
nginx_active:256 nginx_reading:3 nginx_writing:4 nginx_waiting:249

./get_nginx_socket_status.pl http://******/nginx_status
nginx_accepts:15638 nginx_handled:15638 nginx_requests:40322

Далее я сделал импорт дата темплейтов через веб интерфейс кактуса и добавил графики по этим темплейтам, указав в параметре url по которому доступен nginx_status (http://******/nginx_status).

После этого правда началось шаманство с кактусом. Прошло несколько часов, но график был пустой. При этом по логам все ок, файлы rrd обновляются и не понятно в чем дело. Попробовал было удалить графики и добавить по новой, но результата так и не было.

Но потом уже вечером увидел что на графике появились таки данные и дальше все рисовалось четко. Не могу объяснить этот феномен, кактус выделывает такое, да и вообще он сложноват в администрировании, если что идет не так. При чем это не только мое мнение, а и многих админов.

Касательно расшифровки показаний статуса nginx: http://wiki.nginx.org/HttpStubStatusModule — оригинал или например вот тут http://alegenk.livejournal.com/22071.html на русском.

P.S. не забудьте закрыть доступ к /nginx_status для всех айпишников кроме айпи сервера или хотя бы поменяйте  путь на другой ( типа /nginx_kmf3md ).

Уютный сервер на FreeBSD: определяем страну посетителя через nginx

Декабрь 12, 2011 | ITшное, Администрирование | Модные словечки , , , | Оставить свое мнение

И снова здравствуйте!

Этот небольшой пост будет о том, как легко и непринужденно сделать определение страны посетителя через nginx, что бы программисту не нужно было с этим заморачиваться.

Итак, как мы помним из предыдущих серий, при установке nginx я выбрал модуль geoip, поэтому порт /usr/ports/net/GeoIp/ уже должен быть установлен, если это не так то вам нужно поставить его дополнительно и потом переустановкить nginx с этим модулем.

Далее качаем бесплатную (или платную, кто что может =) версию бинарной базы geoip:

cd /usr/local/etc/nginx/
mkdir data
mkdir data/geo && cd data/geo
wget http://geolite.maxmind.com/download/geoip/database/GeoLiteCountry/GeoIP.dat.gz
gunzip GeoIP.dat.gz

А потом всего лишь добавляем немного конфига:

geoip_country /usr/local/etc/nginx/data/geo/GeoIP.dat;

в секцию http файла nginx.conf (если у вас файл данных геоайпи лежит в другом месте то естественно указываете его)

И что бы этот параметр прокидывался скриптам, добавляем

# GeoIP
fastcgi_param GEOIP_COUNTRY_CODE $geoip_country_code;
fastcgi_param GEOIP_COUNTRY_NAME $geoip_country_name;

В fastcgi_params.

service nginx  restart

И вуаля, в $_SERVER видим что то типа

    [GEOIP_COUNTRY_CODE] => NL
    [GEOIP_COUNTRY_NAME] => Netherlands