Апрель 10, 2012 | ITшное, Администрирование | Модные словечки freeBSD, rsync | Оставить свое мнение
Хотел просто поделиться радостью от работы с утилитой rsync.
Очень удобно, например, для релиза проекта. Сначала подготавливаете на локальной машине нужные файл, как вы это будете делать это уже зависит от стиля разработки. А потом запускаете rsync что бы закинуть файлы на удаленную машину. При этом еще настраиваете авторизацию ssh по ключу (что бы не вводить пароль каждый раз) и все происходит по одному запуску скрипта.
Можно так же настроить исключения файлов, которые не нужно закидывать на удаленную машину и всякие другие плюшки.
Только надо помнить что на удаленной машине тоже должен быть установлен rsync. Это меня несколько огорчило, но пока проблем не доставило, но вообще возможно доставит.
Такие пироги.
Март 16, 2012 | ITшное, Администрирование | Модные словечки cacti, freeBSD, nagios, nginx, rrd | Оставить свое мнение
Приветствую всех читателей моего уютного бложика!
Решил я на днях отделить систему мониторинга от обычных рядовых серверов и взял под эти нужды простенький впс на базе VDSManager. И стал я все настраивать да переносить, никаких сложностей не возникало, да вот только после того как все подготовительные работы были выполнены, оказалось что графики почему то не рисуются. При чем rrd файлы были на месте, но через веб интерфейс ответ rrdtool был пустым. Я пробовал выполнить от себя команду которая в дебаг режиме пишется в самом какти и в ответ получал либо
No match
либо
Bad system call
Все попытки справиться с этим у меня не увенчались успехом и в итоге я решил что я нифига не понимаю в фрибсд и передал работу разобраться с этой проблемой сторонним админам за деньги.
Несколько дней ожидания и админы дали свой вердикт — судя по всему vdsmanager накладывает какие то свои ограничения на ОС, что не позволяет правильно работать rrdtool которая должна рисовать графики.
Впринципе, для меня это было ожидаемо. Взял я себе тогда другой вдс уже покруче, на базе KVM, правда и стоит он в три раза дороже, но что ж, и тянуть должен бы больше, может еще что навешу на него.
Сразу скажу что на этом сервере все ишло без таких неожиданностей, все становилось сразу, если не считать того что я иногда тупил.
Так вот, исходя из этого опыта несколько советов как правильно переехать на новое место обитания мониторинга.
После того как на новом сервере настроены всякие веб сервера, пхп, мускули и т.п., то есть проделана вся работа как и для установки нового кактуса, делаем следующее:
- На старом сервере пакуем всю папку /usr/local/www/cacti и делаем дамп базы cacti
- Делаем дампы rrd файлов (как это сделать немного ниже)
- Скидываем надампеное на новый сервер
- На новом сервере копируем с заменой файлы config.php и все файлы из scripts/ без замены файлов, то есть добавляем то, чего не хватает на новом.
- Восстанавливаем из дампов rrd файлы
- Ставим скрипт кактуса в крон как и при сетапе нового сервера.
Как сделать бекап и восстановление.
Вообще говоря есть стандартная функциональность 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, а то сразу я его поставил и он стоял без дела фактически =)
Март 11, 2012 | ITшное, Администрирование | Модные словечки freeBSD, ssh, ttys | Оставить свое мнение
Сегодня краткий пост о том, как сделать проброс портов на фряшке.
Понадобится это может, как пример для того, что бы подключатся к базе данных, доступ к которой есть только с одного сервера, к которому у вас естественно есть доступ.
Для начала вам нужно заиметь приватный ключ от того пользователя через которого будем подключатся по ssh. Кладем файлик, на пример по пути /usr/local/etc/repl и выставляем права на этот файл 0700 потому что иначе фряха не будет его использовать.
Сам порт пробрасывается командой
/usr/bin/ssh -i /usr/local/etc/repl -N -L 3307:127.0.0.1:3306 repl@123.123.123.123
После запуска команды при подключении к локальному порту 3307 — на самом деле будет установлено соединение с портом 3306 на сервере 123.123.123.123.
При этом нужно обязательно сначала запустить эту команду вручную, так как если вы подключаетесь к этому хосту впервые, фряха спросит, желаем ли мы добавить хост в список с занесением его хеша или чего то такого, точно сам не знаю =)
После чего мы добавляем в /etc/ttys строку
repl "/usr/bin/ssh -i /usr/local/etc/repl -N -L 3307:127.0.0.1:3306 repl@123.123.123.123" unknown on
И команда для перечитывания ttys
kill -HUP 1
После этого у вас должен постоянно работать проброс и даже при обрыве связи он будет восстанавливаться автоматически благодаря ttys.
Март 10, 2012 | ITшное | Модные словечки apache, freeBSD, nginx, svn, usvn | 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://
Февраль 29, 2012 | ITшное | Модные словечки freeBSD, nginx, ошибки | Оставить свое мнение
Итак, если у вас хост настроен правильно, но при запросе любого статического контента сервер вам возвращается ответ 200 ok, но само тело ответа пустое, а логах nginx красуются строки типа
4140#0: *4 sendfile() failed (45: Operation not supported) while sending response to client
Это верный признак того, что вам нужно найти где в конфиге у вас прописано
sendfile on;
и удалить либо изменить на off его значение.
Уже второй раз сталваюсь с этой проблеммой и первый раз я было подумал что это что то с самой ОС, пришлось все переставить/пересобрать, и вот на второй раз таки нашел реальную причину.
Последние отзывы