Категорії
FreeBSD Linux

Централизованное управление копьютерами через puppet.

Кто знаком с миром Windows, скажет, что это легко делается с помощью Active Directory и групповых политик. А как же дела обстоят в мире свободного програмного обеспечения? Неужели нет достойного конкурента “мелкомягким”? Ответ на это даёт статья, речь о которой пойдёт ниже.

На самом деле, это можно сделать многими способами: на страничке http://en.wikipedia.org/wiki/Comparison_of_open_source_configuration_management_software, вы найдёте много ПО, которое позволяет реализовать централизиванное управление машинами со свободным ПО. В этой же статье я расскажу именно о puppet (официальный сайт http://projects.puppetlabs.com/projects/puppet). На мой взгляд простота установки и настройки берёт вверх над тем, что нужно дополнительно ставить ruby на каждую машину, которой хотим управлять.

Пару слов скажу о самом puppet. Puppet, как и большинство систем аналогичного уровня, является клиент-серверной системой, использующей декларативный, то есть обязательный для выполнения язык для описания задач и библиотеки для их реализации. Клиенты периодически соединяются с центральным сервером и получают последнюю конфигурацию. Если полученные настройки не совпадают с системным состоянием, они будут выполнены, при необходимости серверу отсылается отчет о произведенных операциях. Сервер сообщения может сохранить в syslog или файл, создать RRD-график, отослать на указанный email.

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

Тестовый стенд: Gentoo (hostname=linuxAD.lin, сервер), Ubuntu (hostname= manager01.lin, клиент), FreeBSD (hostname=jail1.lin, клиент)

1) Подготовка

Проверить наличие необходимых библиотек Ruby можно командой:

$ ruby -ropenssl -e "puts :yep"
yep
$ ruby -rxmlrpc/client -e "puts :yep"
yep

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

2) Установка и настройка сервера

В gentoo как я понял нет разделения пакета на серверную и клиентскую часть: всё находится в одном пакете. Собственно ставим его:

#USE="shadow vim-syntax" emerge -av app-admin/puppet

Он потянет за собой около 8 пакетов (в том числе и ruby) и процес может затянуться на минут 20. По крайней мере у меня так было. После установки переходим в каталог /etc/puppet. Создаём файл puppetmasterd.conf такого содержания:

[puppetd]
logdir = /var/log/puppet
vardir = /var/lib/puppet
rundir = /var/puppet/run
report = true
check = true
httplog = /var/log/puppet/http.log
masterlog = /var/log/puppet/puppetmaster.log
railslog = /var/log/puppet/rails.log

Очень важно, что бы права на указанные файлы и папки в puppetmasterd.conf и в puppet.conf были puppet:puppet.

Файлы, в которых описывается желательная конфигурация систем, в терминологии Puppet называются манифестами (manifests). При запуске демон пытается прочитать файл /etc/puppet/manifests/site.pp, при его отсутствии выдает предупреждающее сообщение. Поэтому создаём папку manifests и в ней файл site.pp такого содержания:

class test {
file { "/etc/test":
owner => bin,
group => root,
mode => 600,
}
}
node default {
include test
}

Этими настройками мы определяем права для файла /tmp/test.

3) Установка и настройка клиента.

В ubuntu ставим только клиент:

#apt-get install -y puppet

После установки в папке /etc/puppet создаём файл puppet.conf (на клиенте) такого содержания:

[puppetd]
server = linuxAD.lin
logdir = /var/log/puppet
vardir = /var/lib/puppet
rundir = /var/puppet/run
report = true
puppetdlog = /var/log/puppet/puppetd.log
railslog = /var/log/puppet/rails.log

Очень важно, что бы адрес сервера был именно ДОМЕННЫМ имененим, а не IP-адресом. В противном случае при запросе сертификата будете получать такие сообщения:

#puppetd --verbose --test
warning: Certificate validation failed; consider using the certname configuration option err: Could not retrieve catalog: Certificates were not trusted: hostname was not match with the server certificate
warning: Not using cache on failed catalog

Если у вас нет возможности использовать DNS, то пропишите имена хостов в файле /etc/hosts на всех машинах, где будет использоваться puppet.

А теперь тоже самое, только на FreeBSD:

#cd /usr/ports/sysutils/puppet && make install clean

Конфигурационный файл отличается от Ubuntu лишь параметром vardir = /var/run/puppet и расположением самого конфигурационного файла (в freebsd он лежит в /usr/local/etc/puppet).

Ещё один приятный момент. Для генерации конфигурационного файла разработчики предоставили удобный инструмент:

$puppetd --genconfig >> /tmp/tmp.conf

После этого можно открыть файл /etc/tmp.conf. Но сильно не надейтесь на него, так как он вставляет в пути текущий каталог и многие параметры придётся поправлять. Так что, на самом деле это не что иное, как обычный мануал к составлению файла настроек puppet.conf

4) Запуски проверка работоспособности.

Запускаем клиент и сервер на соотвествующих машинах (для запуска на freebsd нужно добавить строчку pupptd_enable=”YES” в /etc/rc.conf):

#/etc/init.d/puppet start
#/etc/init.d/puppetmaster start
#/usr/local/etc/rc.d/puppetd start

При старте клиента на freebsd я получил такое сообщение:

Value of 'preferred_serialization_format' (pson) is invalid for report, using default (marshal)

но можно не волноваться. Отчёты будут приходить в формате по умолчанию marshal. Но можно избавиться от этого сообщения, прописав параметр

preferred_serialization_format = marshal

в конфигурационные файлы клиента и сервера. Не забудьте перегрузить демоны puppet и puppetmaster. Успешность запуска можно проверить через ps:

#ps auxww | grep puppet
root 12323 0.2 5.7 39504 28604 ? Ssl 10:39 0:25 /usr/bin/ruby1.8 /usr/sbin/puppetd
#ps auxww | grep puppet
root 4325 0.0 4.9 27928 24904 ? Ss 12:34 0:00 /usr/bin/ruby18 /usr/sbin/puppetd
puppet 4684 0.0 5.7 31508 28812 ? Ss 12:37 0:06 /usr/bin/ruby18 /usr/sbin/puppetmasterd

Отправляем с клиента запрос на полписание сертификата

#puppetd --server linuxAD.lin --waitforcert 60 --test
info: Requesting certificate
warning: peer certificate won't be verified in this SSL session
notice: Did not receive certificate

Иногда получаем и такое сообщение:

info: Creating a new certificate request for manager01.lin
info: Creating a new SSL key at /var/lib/puppet/ssl/private_keys/manager01.lin.pem
warning: peer certificate won't be verified in this SSL session
notice: No certificates; exiting

В сети интернет пишут, что при отсутствии параметра –waitforcert возникают проблемы. Поэтому, его лучше не игнорировать.

Теперь на сервере смотрим список сертификатов, нужнающихся в подписи :

#puppetca --list
manager01.lin
jail1.lin

Подписываем сертификат:

#puppetca --sign manager01.lin
#puppetca --sign jail1.lin

Если ошибок нет, то проверим, всё ли прошло успешно. Для этого на клиенте выполним повторный запрос:

#puppetd --verbose --test
info: Caching catalog at /var/lib/puppet/state/localconfig.yaml
notice: Starting catalog run
info: Sent transaction report in 0.12 seconds
notice: Finished catalog run in 0.21 seconds

Успешное применении правил будет сопровождаться такими сообщениями:

Apr 9 12:48:51 jail1 puppetd[63813]: (//sudo/File[/etc/test]/owner) owner changed 'root' to 'bin'
Apr 9 12:48:51 jail1 puppetd[63813]: (//sudo/File[/etc/test]/group) group changed 'wheel' to 'bin'
Apr 9 12:48:51 jail1 puppetd[63813]: (//sudo/File[/etc/test]/mode) mode changed '644' to '666'

Мы так же можем удостовериться, посмотрев на владельца и права на файл /etc/test:

$ls -la /etc/test
-rw-rw-rw- 1 bin bin 0 2010-04-06 10:51 /etc/test

они изменились на те, которые нужно.

5) Dashboard: web доступ к отчётам.

Что это такое? Puppet Dashboard – это Web интерфейс к puppet, который предоставляет управление нодами (клиентами) и отчётами. Официальный сайт puppetlabs.com. Ниже будет приведена установка и настройка Dashboard.

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

– rake >= 0.8.3
– MySQL
– ruby mysql bindings (gem install mysql for ruby >= 1.8.6 )

Если у вас его нет, ставим:

#emerge -av dev-ruby/rake
#emerge -av dev-db/mysql
#emerge -av dev-ruby/mysql-ruby

Так же потребуется установить git (распределённая система управления версиями файлов). С помощью его можно загрузить исходники puppet-dashboard.

#emerge -av dev-vcs/git

Теперь переходим к установке самого dashboard. Предполагается, что установочная директория будет /opt/puppet-dashboard (саму папку puppet-dashboard создавать не нужно, она создастся автоматически, при скачивании исходников).

#cd /opt
#git clone git://github.com/reductivelabs/puppet-dashboard.git
Initialized empty Git repository in /opt/puppet-dashboard/.git/ remote: Counting objects: 8692, done.
remote: Compressing objects: 100% (4763/4763), done.
remote: Total 8692 (delta 3405), reused 8533 (delta 3272)
Receiving objects: 100% (8692/8692), 6.60 MiB | 601 KiB/s, done.
Resolving deltas: 100% (3405/3405), done.

Теперь осталось немного подправить настройки БД и запускать сервер. Идём в каталог /opt/puppet-dashboard/config и приводим файл database.yml к такому виду:

development:
adapter: mysql
database: puppet_dash
username: root
password: rootpassword
encoding: utf8
host: localhost

test:
adapter: mysql
database: dashboard_test
username: root
encoding: utf8

production:
adapter: mysql
database: dashboard_production
username: root
encoding: utf8

где в разделе development обязательно должно быть username: root и password (ваш пароль юзера root на БД mysql). Обязательно должно быть имя пользователя root. В противном случае будут выдаваться сообщения, что невозможно создать БД в процессе установки. При желании можно настроить и другие параметры по своему усмотрению. Идём дальше – установка dashboard:

#cd /opt/puppet-dashboard
#rake install

После установки заходим в /opt/puppet-dashboard/script и запускаем web-сервер lighttpd:

./server

По умолчанию открывается соединение на порту 3000, поэтому заходить нужно так: Учтите, что данный сервер запускается не как демон, поэтому нужно написать стартовый скрипт для его запуска в режиме демона. Пару слов об обчётах. Для успешного просмотра отчётов, нужно их импортировать в dashboard. Делается это так:

#rake reports:import

Единственно но, что это нужно делать периодически. По умолчанию отчёты присылаются каждые 30 минут (но при желании это можно изменить через параметр splaylimit в конфигурационном файле клиента), поэтому, можно добавить задание демону cron для выполнения команды каждые 30 минут:

*/30 * * * * root rake -f /opt/puppet-dashboard/Rakefile reports:import

Осталось дать понять puppet’y, что теперь он должен свои отчёты обрабатывать через dashboard. Для этого добавим такую строчку в файл /etc/conf.d/puppetmaster (это конфигурационный файл для запуска службы puppetmaster; в вашей системе он может быть другим)

PUPPETMASTER_EXTRA_OPTS="––reports puppet_dashboard"

В комплекте с dashboard идёт файл библиотеки обработки отчётов. Другими словами, это модуль ruby для обработки отчётов. Его нужно скопировать в папку puppet с модулями ruby (у вас может быть другой путь к модулями ruby):

#cp /opt/puppet-dashboard/puppet/lib/puppet_dashboard.rb /usr/lib/ruby/site_ruby/1.8/puppet/reports/

Теперь осталось перезапустить сервер puppetmaster:

#/etc/init.d/puppetmaster restart

Через некоторое время отчёты станут доступными через web. Что бы посмотреть отчёты, заходим по адресу http://your.website.com:3000. Можно не регистрировать, и сразу приступать к просмотру отчётов. Для более детального знакомства с puppet-dashboard можно воспользоваться официальным сайтом.

6) Послесловие.

Добавлю от себя, что вещь эта полезная, но есть некоторые нюансы. Измнения на клиенте применяются примерно через некоторое время после внесения измнений на сервере.

Ещё один момент. Он связан с тем, что в разных системах настройки могут отличаться. К пример, в freebsd нет группы root по умолчанию. В результате чего у меня появлялись сообшения :

(//sudo/File[/etc/test]) Failed to retrieve current state of resource: Could not find group root at /etc/puppet/manifests/site.pp:12

при каждой попытке клиента применить правила.

Примечание: обязательно должна присутствовать строчка report = true в конфигурационных файлах клиентов для успешного отображения отчётов.

Ещё один немаловажный факт, так это то, что отчёты в статистике видны согласно GTM+0, а не так, как у вас настроен часовой пояс. Хотя на самом сервере и клинте, даты создания файлов отчётов видны под правильной датой. На официальном сайте эта тема помечена как баг. Вот ссылка http://projects.reductivelabs.com/issues/3528. В других же источниках утверждается, что это из-за того, что на компьютерах время настроено как UTC.

В этой статье я рассказал только общие вещи. Для более тесного взаимодействия обращайтесь к справочным руководствам или на официальный сайт. Так же можно использовать man puppet.conf, puppetdoc

Залишити відповідь

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *

Домашняя страничка Andy
Записки молодого админа
Самостоятельная подготовка к Cisco CCNA
Самостоятельная подготовка к Cisco CCNP
Powered by Muff