Posts tagged ‘установка’

Centreon+Nagios: установка и первоначальная настройка

Centreon
Итак, как и обещал, в этой статье расскажу как установить Centreon Enterprise Server и выполнить первоначальную настройку Centreon.
Для установки нам понадобится дистрибутив CES 3.0 или 3.1, скачать его можно отсюда: https://download.centreon.com/
Если вы еще не уверены стоит ли вообще тратить время на изучение Centreon, советую поиграться с online-demo того что у вас может получиться: https://www.centreon.com/en/centreon-demo/

Continue reading ‘Centreon+Nagios: установка и первоначальная настройка’ »

Puppet: в шкуре кукловода. Часть 1

К моему глубочайшему удивлению, такая отличная и полезная система как Puppet, практически не описана в русскоязычном Интернете. Те статьи что имеются(см. в конце поста) не заходят дальше поверхностного описания установки Puppet и настройки прав на файлы /etc/passwd, /etc/sudoers. Я вижу, что с помощью Puppet я и мои коллеги смогут сэкономить себе кучу времени при установке софта или переносе инфраструктуры на новое железо, поэтому хочу поделиться опытом и описать КАК я это сделаю :).

Что это?

PuppetPuppet – это система управления конфигурациями, инструмент который позволяет автоматизировать настройку и управление большим парком машин, систем, сервисов. Его магия состоит в том что вам достаточно один раз написать “рецепт” по настройке какого-то ПО или опции системы, и вы уже можете тиражировать эти изменения на сколь угодно большое количество серверов, для этого достаточно установить на целевой машине Puppet и произвести маленькую настройку.

Как это работает?

Pupet - system diagram

Есть центральный демон, так называемый pupetmaster(кукловод), у него хранятся данные о настройке сервисов, файлах, шаблонах конфигурации и т.д.
На сервера и рабочие станции под управлением Linux, *BSD, MacOS ставиться puppet(марионетка/кукла), раз в 30 минут этот сервис забирает данные о конфигурации ПО и системы у puppetmaster`а.
Конфигурировать можно практически все: установленные программы, репозитории ПО, права на файлы и папки, пользователей системы, файлы конфигурации, сервисы в системе и т.д. Также функциональность puppet`а можно расширять при помощи модулей или достаточно легко подключаемых плагинов к Facter и самому Puppet.

Устанновка PuppetMaster из репозитория (CentOS/Fedora)

Этот способ установки наиболее предпочтителен, т.к. позволяет в дальнейшем достаточно просто обновляться до новых версий.
Для установки puppetmaster в систему нужно добавить репозиторий EPEL
Создаем файл /etc/yum.repos.d/epel.repo*:

[epel]
name=Extra Packages for Enterprise Linux 5 - $basearch
mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=epel-5&arch=$basearch
failovermethod=priority
enabled=1
gpgcheck=1
gpgkey=http://download.fedora.redhat.com/pub/epel/RPM-GPG-KEY-EPEL
includepkgs=ruby*,puppet*,facter*,augeas*

Далее ставим пакет puppet-server.noarch:

yum install 'puppet*'

Вот и все, просто как палка :). Далее можно переходить к конфигурированию и проверке работы puppet (см. ниже)

Установка PuppetMaster через Gem

Для установки Puppet нужно установить Ruby и Ruby gems (здесь уже на ваш выбор как :)).

Для установки Puppet и Puppetmaster`а нужно установить gem puppet:

gem install puppet

Вместе с puppet будет установлено еще несколько gem`ов по зависимостям.
Теперь нужно прописать puppet в системе, для этого заходим в папку с gem`ом puppet(по идее /opt/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/puppet-0.25.5, точное расположение папки ruby может быть другим, ставил из сорцов) и выполняем следующие команды по интеграции в систему:

confdir='conf/redhat/'
cp $confdir/client.sysconfig /etc/sysconfig/puppet
cp $confdir/client.init /etc/init.d/puppet
cp $confdir/server.sysconfig /etc/sysconfig/puppetmaster
cp $confdir/server.init /etc/init.d/puppetmaster
cp $confdir/fileserver.conf /etc/puppet/fileserver.conf
cp $confdir/puppet.conf /etc/puppet/puppet.conf
cp $confdir/logrotate /etc/logrotate.d/puppet

Редактируем файл /etc/init.d/puppetmaster:

...
PUPPETMASTER=/opt/ruby-enterprise-1.8.7-2010.01/bin/$prog
...

Редактируем файл /etc/init.d/puppet:

...
puppetd='/opt/ruby-enterprise-1.8.7-2010.01/bin/puppetd'
...

Как видите этот способ установки более длинный и муторный.

Первоначальное конфигурирование puppetmaster (проверка работоспособности)

Создаем тестовый манифест для проверки работоспособности Puppet:

# Создаем файл для проверки
touch /tmp/tmp
chown ftp:ftp /tmp/tmp
chmod 777 /tmp/tmp
# Создаем файл манифест
vim /etc/puppet/manifests/site.pp

Забиваем в site.pp следующие данные:

file { "/tmp/tmp":
    owner => root, group => root, mode => 440
}

Далее запускаем команду:

puppetmaster --verbose --no-daemonize

Мы запускам puppet не как демон, а в полу-интерактивном режиме, с выводом всех происходящих действий в терминал. Должна появиться строчка:

notice: Starting Puppet server version 0.25.5

И на этом все. Теперь открываем еще один терминал к серверу (терминал с puppetmaster`ом не закрываем) и набираем команду

puppetd --verbose --waitforcert 60 --no-daemonize

Таким образом мы запускаем puppet на нашем сервере, в интерактивном режиме как и puppetmaster.
После запуска должны появиться следующие строчки:

notice: Starting Puppet client version 0.25.5
info: Caching catalog for mail.rulimony.ru
info: Applying configuration version '1274869753'
notice: //File[/tmp/tmp]/owner: owner changed 'ftp' to 'root'
notice: //File[/tmp/tmp]/group: group changed 'ftp' to 'root'
notice: //File[/tmp/tmp]/mode: mode changed '777' to '440'
notice: Finished catalog run in 0.02 seconds

Это говорит о том что конфигурация удачно передалась с puppetmaster`а клиенту.

Останавливаем puppetmaster и puppet через Ctrl+c.

Все, puppetmaster и puppet можно запускать:

chkconfig puppetmaster on
chkconfig puppet on
service puppetmaster start
service puppet start

Что это было?

Мы установили Puppet и Puppetmaster на один сервер, создали тестовый манифест (site.pp) который изменяет владельца и права на файл /tmp/tmp.
Дальше нужно ставить puppet на другие сервера (ноды) и создавать настройки конфигурации.
Об этом постараюсь написать в течении недели. А пока советую приглядеться к следующим ресурсам:

Puppet, система управления конфигурациями. Часть I
Puppet, система управления конфигурациями. Часть II
Puppet против Chef: 10 причин, из-за которых выигрывает Puppet
Puppet Docs

Pingus в OpenSuSE 11.2

И вот я поставил OpenSuSE 11.2 и возрадовался, система стала отлично и работала на ура (почти). И все в ней было хорошо, но я не обнаружил там своей любимой Linux-игры Pingus…

Попытка поставить из сорсов (у меня мания все новые пакеты в сусе ставить из сорсов) не увенчалась успехом т.к. Pingus “из тарбола” не заточен на GCC 4.3 и выше (пруфлинк от вездесущего Debian).

Решение

Помог вот этот патч, он добавляет нехватающие инклуды и Pingus`ам становистя хорошо.

Процесс установки

Предпологается что вы установили devel пакеты SDL: SDL-devel, SDL_image-devel, SDL_mixer-devel etc.

wget -c http://pingus.seul.org/files/pingus-0.7.2.tar.bz2
tar xjf pingus-0.7.2.tar.bz2
cd pingus-0.7.2
wget -c "http://svn.uludag.org.tr/viewcvs/devel/applications/games/pingus/files/gcc-4.3.patch?revision=43817&root=pardus&pathrev=43817"
patch -p0 -i gcc-4.3.patch
scons

По идее все должно пройти нормально, и вы сможете запустить игру командой

./pingus

P.S.

Мои старания были вознаграждены новым levelset, который я еще не проходил:
Pingus 0.7.2

P.P.S.

Как оказалось есть еще и Windows и Mac версия игры: http://pingus.seul.org/download.html

Сага о Nagios: чекаем в труднодоступных местах (NRPE)

Если уж вы решили заняться мониторингом серверов, вряд ли вам удалось ограничиться проверками пинга и доступа к сайтам по HTTP. Проверка загрузки CPU, свободного места на сервере и т.д. можно конечно проверять с помощью SNMP, но искать новые модули для проверки проверки или лазить по дереву SNMP не самое интересное занятие, да и не очень нужное, ведь есть отличные команды для локальной проверки сервера из стандартного комплекта модулей “check_load, check_storage” и т.д. Изобретать велосипед конечно благородно, но бесполезно. Дальше речь пойдет о мониторинге Unix серверов при помощи NRPE.

Общий обзор NRPE

На помощь может прийти NRPE, приложение созданное специально для проверки удаленного сервера с помощью “локальных” команд. Алгоритм работы можно видеть на рисунке ниже:

Хост с Nagios (слева), инициирует проверку с помощью команды check_nrpe к удаленному серверу (справа), на котором установлен NRPE, в зависимости от конфигурации выполняется та или иная команда проверки. На хостк с NRPE можно еще раз выполнить команду check_nrpe для проверки хоста с NRPE, это позволяет создавать конфигурации при которых Nagios не находиться в той-же подсети что и хосты, но при этом может проверять хосты из другой сети:

Преимуществами NRPE по сравнению с SNMP можно считать:

  • проверки произволяться “локальными” командами
  • ненужно расшаривать какие-то области SNMP, это может быть небезопасно
  • NRPE имеет возможность создания защищенного соединения (SSL) между Nagios и хостом, в отличии от SNMP, который чуть ли не UDP пакеты посылает
  • для добавления новой проверки достаточно написать консольный скрипт в Perl или Bash, не заморачиваясь на SNMP-ловушках или еще чем-нибудь более заумном

Установка NRPE

Ну думаю теории хватит, можно приступать к практике.
Для начала скачайте последнюю версию NRPE с официального сайта http://www.nagios.org/download/addons/

(Более полную информацию по NRPE можно найти по адресу http://nagios.sourceforge.net/docs/nrpe/NRPE.pdf)

В моем случае версия NRPE была 2.12, далее начнем компиляцию и установку.
Распакуем архив

tar xzf nrpe-2.12.tar.gz
cd nrpe-2.12/

Далее проводим конфигурирование, опция –disable-ssl отключает SSL в NRPE, если у вас действительно большое количество проверок на одном сервере SSL лучше отключить, чтобы не загружать сервер. Опция –enable-command-args определяет можно ли будет командам передавать аргументы, заранее подумайте над тем стоит ли их включать, т.к. это может создать проблемы в безопасности системы, к примеру если в качестве аргумента передать что-нибудь типа “-w=5 -c=6; cat /etc/passwd” в bash эта строка будет интерпретирована не совсем так как вы хотите

./configure --disable-ssl --enable-command-args

Далее создаем пользователя и группу под которыми будет работать NRPE, опцию -d /home/nagios лучше оставить т.к. в дальнейшем домашняя директория для NRPE вам еще пригодиться

groupadd nagios
useradd nagios -d /home/nagios -g nagios -m

Последний этап компиляции, собственно компиляция, установка плагина check_nrpe, установка демона NRPE и конфигов для xinetd

make all && make install-plugin && make install-daemon && make install-xinetd

Для работы NRPE лучше всего использовать xinetd, т.к.он позволяет обновлять конфигурацию без перезагрузки демона и вам не нужно следить за тем загружен NRPE или нет. Также xinetd обеспечивает некоторую дополнительную безопасность с помощью определения списка IP адресов с которых может инициироваться доступ к порту NRPE.

Если у вас не установлен xinetd нужно его установить:

yum install xinetd
zypper install xinetd
apt-get install xinetd (зависит от системы)

Дальше редактируем /etc/xinetd.d/nrpe, находим строку

	only_from            = 127.0.0.1 IP1 IP2

вместо IP1 и IP2 подставляет IP-адреса Nagios или хостов с которых будет осуществляться проверка, адреса должны быть написаны через пробел.

Добавить описание NRPE в конец файла /etc/services.

	nrpe                 5666/tcp            # NRPE

После нужно перезагрузить xinetd:

service xinetd restart

Возможно вам также придется добавить правило в firewall, которое бы разрешало подключения на порт 5666:

iptables -I RH-Firewall-1-INPUT -p tcp -m tcp –dport 5666 -j ACCEPT
service iptables save

Далее вам нужно скопировать плагины для проверки в папку /usr/local/nagios/libexec/. Плагины можно взять из этой папки на сервере с Nagios (или в папке /usr/lib/nagios/plugins/, если вы ставили Nagios из бинарных архивов).

Если все сделано правильно мы можем проверить работоспособность NRPE, выполнив следующий скрипт:

/usr/lib/nagios/plugins/check_nrpe -H localhost

Должно вы появиться что-то вроде:

NRPE v2.12

Все, установку закончили.

Конфигурирование NRPE

После установки файл конфигурации по умолчанию находиться в файле /usr/local/nagios/etc/nrpe.cfg. Первое что стоит отредактировать это опять таки хосты с которых будет производиться проверка:

	allowed_hosts=127.0.0.1,IP1,IP2

опция allowed_hosts определяет список хостов с которых будут идти проверки, адреса должны быть перечислены через запятую.
Дальше определяем количество можно ли передавать аргументы командам:

	dont_blame_nrpe=0

если “0” аргументы передавать нельзя, если “1” можно.

Далее можно перейти непосредственно к команда которыми мы будем оперировать. Общий синтаксис таков:

	command[command_name]=/path/to/check/command args

например:

	command[check_users]=/usr/local/nagios/libexec/check_users -w 5 -c 10

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

	command[check_users]=/usr/local/nagios/libexec/check_users -w $ARG1$ -c $ARG2$

Командой может быть любой скрипт или строка bash, главное чтобы она удовлетворяла правилам написания модулей для Nagios.

для выполнения команды проверки check_users выполните:

/usr/lib/nagios/plugins/check_nrpe -H localhost -c check_users или
/usr/lib/nagios/plugins/check_nrpe -H localhost -c check_users -a 5 10

Получим что-нибудь вроде этого:

USERS OK - 1 users currently logged in |users=1;5;10;0

Конфигурирование Nagios для работы с NRPE

После того как NRPE успешно установлен можно приступить к конфигурированию самого Nagios.
Первое что следует сделать, это скопировать скрипт check_nrpe в папку с плагинами Nagios (см. выше). Дальше открываем файл с описанием комманд (чаще всего commands.cfg) и добавляем вот такую конфигурацию:

define command{
	command_name		check_nrpe
	command_line		$USER1$/check_nrpe -H $HOSTADDRESS$ -c $ARG1$
}

таким образом мы добавили команду check_nrpe в список команд NRPE, далее создаем новый сервис (проверку):

define service{
	use			generic-service
	host_name		remotehost
	service_description	USERS
	check_command		check_nrpe!check_users
}

после “!” передается команда которая будет вызвана на хосте с NRPE.

Для того чтобы уменьшить количество ошибок и недочетов при конфигурировании Nagios лучше всего создавать команды с заранее определенными параметрами, так лучше пример приведенный выше лучше представить так:

define command{
	command_name		check_nrpe_users
	command_line		$USER1$/check_nrpe -H $HOSTADDRESS$ -c check_users
}
 
....
 
define service{
	use			generic-service
	host_name           	remotehost
	service_description	USERS
	check_command		check_nrpe_users
}

таким образом мы определяем соответствие команды Nagios команде NRPE и допускаем меньше ошибок при конфигурировании.

ВНИМАНИЕ
Если вы собирали NRPE –disable-ssl, в описании команды проверки добавляйте “-n” т.е.

command_line $USER1$/check_nrpe -n -H $HOSTADDRESS$ -c check_users

иначе при проверке возникнет ошибка.

P.S.
Чуть позже думаю появяться стать по автоматизации обновления NRPE и правилах написания модулей(плагинов).