Xgu.ru теперь в Контакте  — приходите и подключайтесь.
Пока мы работаем над следующими видео, вы можете подключиться в Контакте. Познакомимся и обсудим новые страницы и ролики.

Vk-big.pngYoutube-big.jpeg

bcfg2

Материал из Xgu.ru

Перейти к: навигация, поиск
stub.png
Данная страница находится в разработке.
Эта страница ещё не закончена. Информация, представленная здесь, может оказаться неполной или неверной.

Если вы считаете, что её стоило бы доработать как можно быстрее, пожалуйста, скажите об этом.


Содержание

[править] Введение

bcfg2 - клиент-серверная система централизованного конфигурирования и управления N-го числа парка машин. В конфигурации описывается конечное состояние управляемых систем, что дает возможность абстрагироваться от различных особенностей управляемых ОС. Список поддерживаемых ОС:

  1. AIX
  2. FreeBSD
  3. OpenBSD
  4. Mac OS X
  5. OpenSolaris
  6. Solaris
  7. ArchLinux
  8. Blag
  9. Centos
  10. Debian
  11. Fedora
  12. Gentoo
  13. gNewSense
  14. Mandriva
  15. OpenSUSE
  16. RHEL
  17. SLES
  18. Trisuel
  19. Ubuntu

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

Note-icon.gif

Рассматривается версия bcfg2-1.2 в которой добавлены новые плагины, а некоторые старые уже не поддерживаются. Поэтому не все примеры, найденные на просторах сети будут рабочие (они как правило для версии 1.1.x и ниже). Самая актуальная документация идет в исходном коде или доступна по GIT

[править] Установка сервера

Gentoo (сервер)

# autounmask '=app-admin/bcfg2-1.2.0_rc2'
# vi /etc/portage/package.keywords

и меняем = на >=

# emerge bcfg2

Инициализация сервера

# bcfg2-admin init
Store Bcfg2 configuration in [/etc/bcfg2.conf]:
Location of Bcfg2 repository [/var/lib/bcfg2]:
Input password used for communication verification (without echoing; leave blank for a random):

(ввод пароля не виден)

What is the server's hostname [workstation]:
Input the server location [https://workstation:6789]:
Input base Operating System for clients: 
1: Red Hat/Fedora/RHEL/RHAS/Centos 
2: SUSE/SLES 
3: Mandrake 
4: Debian 
5: Ubuntu 
6: Gentoo 
7: FreeBSD 
: 6 
The following questions affect SSL certificate generation. 
If no data is provided, the default values are used. 
Country name (2 letter code) for certificate: ru 
State or Province Name (full name) for certificate: ru 
Locality Name (eg, city) for certificate: town
Warning: /etc/bcfg2.conf already exists. Overwrite? [y/N]: 
Generating a 2048 bit RSA private key 
..............................................................................................................+++ 
.....................................................................+++ 
writing new private key to '/etc/bcfg2.key' 
----- 
Signature ok 
subject=/C=ru/ST=ru/L=town/CN=workstation 
Getting Private key 
Repository created successfuly in /var/lib/bcfg2 

Эти темы не раскрыты: Выбор Input base Operating System for clients судя по всему является формальным. Смысл этого выбора пока не обнаружен.

[править] Конфигурация сервера

Файл /etc/bcfg2.conf

[server] 
repository = /var/lib/bcfg2 
plugins = Bundler,Cfg,Metadata,Pkgmgr,Rules,SSHbase 

[statistics] 
sendmailpath = /usr/lib/sendmail 
database_engine = sqlite3 
# 'postgresql', 'mysql', 'mysql_old', 'sqlite3' or 'ado_mssql'. 
database_name = 
# Or path to database file if using sqlite3. 
#<repository>/etc/brpt.sqlite is default path if left empty 
database_user = 
# Not used with sqlite3. 
database_password = 
# Not used with sqlite3. 
database_host = 
# Not used with sqlite3. 
database_port = 
# Set to empty string for default. Not used with sqlite3. 
web_debug = True 

[communication] 
protocol = xmlrpc/ssl 
username = bcfg2 
password = passwordbcfg2 
certificate = /etc/bcfg2.crt 
key = /etc/bcfg2.key 
ca = /etc/bcfg2.crt 

[components] 
bcfg2 = https://192.168.169.1:6789 

Проверка соединения сервера на клиенте

# bcfg2 -qvn       
!!! Default action for this module has changed in Gentoolkit 0.3. 
!!! Use globbing to simulate the old behavior (see man equery). 
!!! Use '*' to check all installed packages. 
!!! Use 'foo-bar/*' to filter by category. 
!!! Default action for this module has changed in Gentoolkit 0.3. 
!!! Use globbing to simulate the old behavior (see man equery). 
!!! Use '*' to check all installed packages. 
!!! Use 'foo-bar/*' to filter by category. 
Loaded tool drivers: 
 Action    POSIX     Portage   RcUpdate  VCS      

Phase: initial 
Correct entries:	0 
Incorrect entries:	0 
Total managed entries:	0 
Unmanaged entries:	1195 


Phase: final 
Correct entries:	0 
Incorrect entries:	0 
Total managed entries:	0 
Unmanaged entries:	1195 

-q – ускоренный режим работы, -v – подробный вывод, -n – не применять никаких действий

[править] Установка на клиентах

[править] UBUNTU

Добавления ключа репозитория

# apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 98932BEC
Executing: gpg --ignore-time-conflict --no-options --no-default-keyring --secret-keyring /etc/apt/secring.gpg --trustdb-name /etc/apt/trustdb.gpg --keyring /etc/apt/trusted.gpg --primary-keyring /etc/apt/trusted.gpg --keyserver keyserver.ubuntu.com --recv-keys 98932BEC 
gpg: keyring `/etc/apt/secring.gpg' created 
gpg: requesting key 98932BEC from hkp server keyserver.ubuntu.com 
gpg: /etc/apt/trustdb.gpg: trustdb created 
gpg: key 98932BEC: public key "Launchpad PPA for Bcfg2" imported 
gpg: Total number processed: 1 
gpg:               imported: 1  (RSA: 1) 

[править] Ubuntu 10.04

Репозиторий с последней версией

deb http://ppa.launchpad.net/bcfg2/ppa/ubuntu lucid main 
deb-src http://ppa.launchpad.net/bcfg2/ppa/ubuntu lucid main

Установка клиента

# apt-get update && apt-get install bcfg2

[править] Ubuntu 8.04

deb http://ppa.launchpad.net/bcfg2/ppa/ubuntu hardy main 
deb-src http://ppa.launchpad.net/bcfg2/ppa/ubuntu hardy main

Установка клиента

# apt-get update && apt-get install bcfg2 python-ssl

[править] Debian 6

# wget ftp://ftp.mcs.anl.gov/pub/bcfg/bcfg2-1.2.0rc2.tar.gz ftp://ftp.mcs.anl.gov/pub/bcfg/bcfg2-1.2.0rc2.tar.gz.gpg
# gpg --recv-keys 0x75bf2c177f7d197e 0x80B8492FA88FFF4B && gpg --verify bcfg2-*.tar.gz.gpg bcfg2-*.tar.gz

...
...
gpg: keyring `/root/.gnupg/secring.gpg' created 
gpg: requesting key 7F7D197E from hkp server keys.gnupg.net 
gpg: requesting key A88FFF4B from hkp server keys.gnupg.net 
gpg: /root/.gnupg/trustdb.gpg: trustdb created 
gpg: key 7F7D197E: public key "Narayan Desai <desai@mcs.anl.gov>" imported 
gpg: key A88FFF4B: public key "Sol Jerome <solj@soljerome.com>" imported 
gpg: no ultimately trusted keys found 
gpg: Total number processed: 2 
gpg:               imported: 2 
root@debian:~# gpg --verify bcfg2-*.tar.gz.gpg bcfg2-*.tar.gz 
gpg: Signature made Fri Oct 28 23:30:56 2011 MSK using DSA key ID A88FFF4B 
gpg: Good signature from "Sol Jerome <solj@soljerome.com>" 
gpg: WARNING: This key is not certified with a trusted signature! 
gpg:          There is no indication that the signature belongs to the owner. 
Primary key fingerprint: 3B98 92AF 1154 BB24 AA26  52EA 80B8 492F A88F FF4B 

Сборка и установка пакета

# tar zxf bcfg2-1.2.0rc2.tar.gz && cd bcfg2-1.2.0rc2
# aptitude --add-user-tag=bcfg2build build-dep bcfg2ls
# dpkg-buildpackage -us -uc -rfakeroot
# aptitude purge "?user-tag(bcfg2build)"
# aptitude install debsums python-apt && dpkg -i ../bcfg2_1.2.0rc2-0.0_all.deb

[править] CentOS 6

# yum install python-devel python-sphinx10 rpm-build python-setuptools python-docutils
# wget ftp://ftp.mcs.anl.gov/pub/bcfg/bcfg2-1.2.0rc2.tar.gz ftp://ftp.mcs.anl.gov/pub/bcfg/bcfg2-1.2.0rc2.tar.gz.gpg
# rpmbuild -bb misc/bcfg2.spec
# yum localinstall --nogpgcheck ~/rpmbuild/RPMS/noarch/bcfg2-1.2.0rc2-0.1.noarch.rpm

[править] Конфигурация клиентов

Файл /etc/bcfg2.conf

[communication] 
protocol = xmlrpc/ssl 
user = UUID or FQDN
password = passwordbcfg2 
ca = /etc/bcfg2.crt 
# key = /etc/bcfg2.key 

[components] 
encoding = UTF-8
bcfg2 = https://192.168.169.1:6789 

Следует обратить внимание на 2 момента:

  • UUID клиента (если клиент за NAT) или FQDN.
  • ca - это сертификат сервера


[править] Проверка клиентов

[править] Ubuntu 10

root@ubuntu:/# bcfg2 -qvn 
Loaded tool drivers: 
 APT      Action   DebInit  POSIX    Upstart  VCS     

Phase: initial 
Correct entries:	0 
Incorrect entries:	0 
Total managed entries:	0 
Unmanaged entries:	326 


Phase: final 
Correct entries:	0 
Incorrect entries:	0 
Total managed entries:	0 
Unmanaged entries:	326 

[править] Ubuntu 8

root@ubuntu8:/# bcfg2 -qvn 
Loaded tool drivers: 
 APT      Action   DebInit  POSIX    VCS     

Phase: initial 
Correct entries:	0 
Incorrect entries:	0 
Total managed entries:	0 
Unmanaged entries:	290 


Phase: final 
Correct entries:	0 
Incorrect entries:	0 
Total managed entries:	0 
Unmanaged entries:	290 

[править] Debian

root@debian:/# bcfg2 -qvn 
Loaded tool drivers: 
 APT      Action   DebInit  POSIX    VCS     

Phase: initial 
Correct entries:	0 
Incorrect entries:	0 
Total managed entries:	0 
Unmanaged entries:	317 


Phase: final 
Correct entries:	0 
Incorrect entries:	0 
Total managed entries:	0 
Unmanaged entries:	317 

[править] CentOS

[root@centos SOURCES]# bcfg2 -qvn 
Loaded plugins: fastestmirror 
Loading mirror speeds from cached hostfile 
 * base: mirror.yandex.ru 
 * extras: mirror.yandex.ru 
 * updates: mirror.yandex.ru 
Loaded plugins: fastestmirror 
Loading mirror speeds from cached hostfile 
 * base: mirror.yandex.ru 
 * extras: mirror.yandex.ru 
 * updates: mirror.yandex.ru 
Loaded tool drivers: 
 Action     Chkconfig  POSIX      VCS        YUMng     

Phase: initial 
Correct entries:	0 
Incorrect entries:	0 
Total managed entries:	0 
Unmanaged entries:	267 


Phase: final 
Correct entries:	0 
Incorrect entries:	0 
Total managed entries:	0 
Unmanaged entries:	267 

[править] Принцип работы

Наборы конфигураций хранятся в репозитории сервера. Репозиторий определяется в в файле /etc/bcfg2.conf

[server] 
repository = /var/lib/bcfg2 

Содержимое репозитория после установки

% tree -f /var/lib/bcfg2 
/var/lib/bcfg2 
├── /var/lib/bcfg2/Bundler 
├── /var/lib/bcfg2/Cfg 
├── /var/lib/bcfg2/etc 
├── /var/lib/bcfg2/Metadata 
│   ├── /var/lib/bcfg2/Metadata/clients.xml 
│   └── /var/lib/bcfg2/Metadata/groups.xml 
├── /var/lib/bcfg2/Pkgmgr 
├── /var/lib/bcfg2/Rules 
└── /var/lib/bcfg2/SSHbase 

Директории Bundler, Metadata, Pkgmgr, Rules и SSHbase соответствуют подключённым к серверу плагинам:

plugins = Bundler,Cfg,Metadata,Pkgmgr,Rules,SSHbase 

Это не все имеющиеся плагины. Что бы подключить новый плагин, надо прописать его имя в параметр plugins и создать одноимённую директорию в репозитории. На данном этапе конфигурация минимальна и определена в файле /var/lib/bcfg2/Metadata/groups.xml:

<Groups version='3.0'> 
   <Group profile='true' public='true' default='true' name='basic'> 
      <Group name='gentoo'/> 
   </Group> 
   <Group name='ubuntu'/> 
   <Group name='debian'/> 
   <Group name='freebsd'/> 
   <Group name='gentoo'/> 
   <Group name='redhat'/> 
   <Group name='suse'/> 
   <Group name='mandrake'/> 
   <Group name='solaris'/> 
</Groups> 

Все обозначенные группы носят исключительно смысловую нагрузку, кроме группы basic. Смысл группы basic заключается в том, что клиенты именно из этой группы берут по умолчанию задания на исполнение (за это отвечает default='true'). Группа basic находится в составе группы gentoo, поэтому все задания, которые будут закреплены за gentoo-группой выполнятся по умолчанию на клиентах.

Note-icon.gif

Следует обратить внимание на пример описания принадлежности группы basic к группе gentoo. Дело в том, что запись вида

<Group name='gentoo'>
   <Group name='basic'>
</Group>

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

bcfg2-info showclient <name_of_client>

При этом, клиент должен должен быть описан в Metadata/clients.xml. В случае его отсутствия, запись будет занесена автоматически.

Note-icon.gif

На файл clients.xml пока можно не обращать внимание. Содержимое его может меняться автоматически, это не должно настораживать.

Эти темы не раскрыты: Описать подробно принцип работы плагина Metadata.

Рассмотрим вывод клиента на примере Ubuntu 10.
Loaded tool drivers: 
 APT      Action   DebInit  POSIX    Upstart  VCS  

Эта запись говорит о подгруженных драйверах на стороне клиента, которые выполняют все действия, которые описаны в конфигурации для заданного клиента.

Фаза initial
Phase: initial 
Correct entries:	0 
Incorrect entries:	0 
Total managed entries:	0 
Unmanaged entries:	326 

показывает число известных и уже выполненных заданий (Correct entries), число известных но не выполненных заданий (Incorrect entries) и их общее число (Total managed entries)

Фаза final
Phase: final 
Correct entries:	0 
Incorrect entries:	0 
Total managed entries:	0 
Unmanaged entries:	326 

показывает те же значения, но уже после всех действий, применённых клиентом bcfg2 на стороне управляемого хоста.

Note-icon.gif

Запуск клиентов осуществляется как минимум двумя способами: через ssh или через скрипты в /etc/cron.hourly (по умолчанию).

[править] Примеры

[править] Распространение файла по хостам

К примеру, необходимо раскидать одинаковый файл test по все хостам в директорию /tmp. Для этого понадобится конфигурация трёх плагинов в репозитории (/var/lib/bcfg2 ) : Bundler,Cfg и Metadata.

Конфигурация плагина Cfg
# mkdir -p Cfg/tmp/test
# echo "this is a test" > Cfg/tmp/test/test
Конфигурация плагина Bundler
# cat Bundler/puttestfile.xml 
<Bundle name='puttestfile'> 
	<Path name='/tmp/test' /> 
</Bundle> 

Note-icon.gif

Имя name='puttestfile' и имя файла должны быть одинаковыми.

Конфигурация плагина Metadata
<Groups version='3.0'> 
	<Group profile='true' public='true' default='true' name='basic'> 
			<Bundle name='puttestfile'/> 
			<Group name='gentoo'/> 
	</Group> 
	<Group name='ubuntu'/> 
	<Group name='debian'/> 
	<Group name='freebsd'/> 
	<Group name='gentoo'/> 
	<Group name='redhat'/> 
	<Group name='suse'/> 
	<Group name='mandrake'/> 
	<Group name='solaris'/> 
</Groups> 
Проверка репозитория
# bcfg2-repo-validate    
Применение настроек
# /etc/init.d/bcfg2-server restart

Note-icon.gif

Рестартить сервер не обязательно, так как при обращении клиента сервер обновляет свою конфигурацию автоматически

Запускаем клиента в холостом режиме на Debian
root@debian:/# bcfg2 -qvn 
Loaded tool drivers: 
 APT      Action   DebInit  POSIX    VCS     
Failed to read /tmp/test: [Errno 2] No such file or directory: '/tmp/test' 

Phase: initial 
Correct entries:	0 
Incorrect entries:	1 
Total managed entries:	1 
Unmanaged entries:	317 

In dryrun mode: suppressing entry installation for: 
 Path:/tmp/test 

Phase: final 
Correct entries:	0 
Incorrect entries:	1 
 Path:/tmp/test 
Total managed entries:	1 
Unmanaged entries:	317 

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

root@debian:/# bcfg2 -v 
Loaded tool drivers: 
 APT      Action   DebInit  POSIX    VCS     
Failed to read /tmp/test: [Errno 2] No such file or directory: '/tmp/test' 

Phase: initial 
Correct entries:	0 
Incorrect entries:	1 
Total managed entries:	1 
Unmanaged entries:	317 

Installing file /tmp/test 
The Following Bundles have been modified: 
 puttestfile 
 

Phase: final 
Correct entries:	1 
Incorrect entries:	0 
Total managed entries:	1 
Unmanaged entries:	317 

Информация фазы “финал” говорит о том, что задание выполнено успешно. Total managed entries 1 говорит о том, что клиенту известно одно задние и он контролирует актуальность результата его выполнения. Теперь можно централизованно редактировать файл /tmp/test в репозитории bcfg2-server и распространять его по хостам.

[править] Добавление информации о правах на файл

Добавляем файл с содержимым:

/var/lib/bcfg2 # cat Cfg/tmp/test/info.xml 
<FileInfo> 
	<Info owner='root' group='root' perms='0666' encoding='utf-8'/> 
</FileInfo> 

И далее

/var/lib/bcfg2 # bcfg2-repo-validate 
/var/lib/bcfg2 # /etc/init.d/bcfg2-server restart 

Имя файла info.xml выбрано не случайно. Именно это (и плюс 2 альтернативных имени :info, info) имя является служебным для сервера. В случае некорректного имени, bcfg2-repo-validate выдаст ошибку. То, что info.xml относится именно к файлу test говорит само расположение этого файла: в директории /tmp/test/. Если бы надо было раскидать файл /etc/test1 с нужными правами, то конфигурация плагина Cfg выглядела бы следующим образом:

#mkdir -p Cfg/ect/test1/

и в Cfg/ect/test1/ содержалось бы 2 файла: test1 и info.xml.

Note-icon.gif

Поддержка :info, info прекращена в версии 1.3.х и будет полностью удалена в версии 1.4.х

[править] Распространение файла с учётом группы, к которой принадлежит хост

Надо раскидать файл /tmp/testgroup по хостам при том, что хост debian принадлежит группе debian, а хост centos принадлежит группе centos. Принадлежность хоста к группе можно определить двумя способами. Первый заключается в том, что нужно прописать параметры хоста Metadata/cliets.xml, но на данный момент можно это не делать, так как подобная манипуляция еще не до конца осмыслена :). Поэтому остановимся на втором варианте. Вариант второй – это запуск клиетна на хосте с ключом -p <groupname>. Создаём конфигурацию:

/var/lib/bcfg2 # mkdir Cfg/tmp/testgroup 
/var/lib/bcfg2 # echo "a test group debian" > Cfg/tmp/testgroup/testgroup.G50_debian 
/var/lib/bcfg2 # echo "a test group centos" > Cfg/tmp/testgroup/testgroup.G50_centos 

где Gxx - приоритет.

Эти темы не раскрыты: Как работают приоритеты?

/var/lib/bcfg2 # cat Bundler/testgroup.xml 
<Bundle name='testgroup'> 
	<Path name='/tmp/testgroup'/> 
</Bundle> 

В Metadata/groups.xml добавляем

<Group name='centos' public='true'> 
	<Bundle name='testgroup'/> 
 </Group> 
<Group name='debian' public='true'> 
	<Bundle name='testgroup'/> 
 </Group> 

public='true' означает, что данная группа анонсируется для клиентов, иначе бы на клиенте была бы ошибка

[root@centos bcfg2-1.2.0rc2]# bcfg2 -vqn -p centos 
Fatal error: Failed to set client profile 

Проверка репозитория и обновление конфигурации

# bcfg2-repo-validate    
# /etc/init.d/bcfg2-server restart

Запуск на centos

[root@centos bcfg2-1.2.0rc2]# bcfg2 -v -p centos 
Loaded plugins: fastestmirror 
Loading mirror speeds from cached hostfile 
 * base: mirror.yandex.ru 
 * epel: ftp.rhd.ru 
 * extras: mirror.yandex.ru 
 * updates: mirror.yandex.ru 
Loaded plugins: fastestmirror 
Loading mirror speeds from cached hostfile 
 * base: mirror.yandex.ru 
 * epel: ftp.rhd.ru 
 * extras: mirror.yandex.ru 
 * updates: mirror.yandex.ru 
Loaded tool drivers: 
 Action     Chkconfig  POSIX      VCS        YUMng     
Failed to read /tmp/testgroup: [Errno 2] No such file or directory: '/tmp/testgroup' 

Phase: initial 
Correct entries:	0 
Incorrect entries:	1 
Total managed entries:	1 
Unmanaged entries:	270 

Installing file /tmp/testgroup 
The Following Bundles have been modified: 
 testgroup 


Phase: final 
Correct entries:	1 
Incorrect entries:	0 
Total managed entries:	1 
Unmanaged entries:	270 
[root@centos bcfg2-1.2.0rc2]# cat /tmp/testgroup 
a test group centos 


Запуск на debian

root@debian:/# bcfg2 -v -p debian 
Loaded tool drivers: 
 APT      Action   DebInit  POSIX    VCS     
Failed to read /tmp/testgroup: [Errno 2] No such file or directory: '/tmp/testgroup' 

Phase: initial 
Correct entries:	0 
Incorrect entries:	1 
Total managed entries:	1 
Unmanaged entries:	317 

Installing file /tmp/testgroup 
The Following Bundles have been modified: 
 testgroup 


Phase: final 
Correct entries:	1 
Incorrect entries:	0 
Total managed entries:	1 
Unmanaged entries:	317 
root@debian:/# cat /tmp/testgroup 
a test group debian 

[править] Распространение файла с учётом имени хоста

Ситуация аналогична предыдущему примеру, но шаблон имени файла выглядит как fstab.H_host.example.com

Эти темы не раскрыты: Нужен пример

[править] Распространение файла с учетом изменений, проделанных в нем локально

Стоит задача распространять по хостам только часть файла, которая модифицируется централизованно, не трогая изменений, сделанных локально на хосте. Например, распространим root crontab для систем в группе centos. Как выглядит crontab на хосте:

# BCFG2 start
MAILTO=root
10       10      */2     *       *       yum --security check-update
# BCFG2 end

#Другие инструкции
00        15        *      *       *     echo ok

Все, что ограничено

 # BCFG2 start 
 ...
 # BCFG2 end

является той частью, которая модифицируется сервером bcfg2. Все, что ниже - правится локально на хосте.

Порядок действий, который проделает bcfg2 сервер:

  • анализ наличия файла crontab на хосте и его содержомого с учетом группы
  • объединение локальных данных с централизованными данными
  • генерация нового файла и замена им файла на хосте, в случае необходимости

[править] Анализ наличия файла crontab на хосте и его содержомого с учетом группы хоста

Данная операция осуществляется плагином Probes сервера bcfg2. В директорию ./Probes/ помещается файл root_cron (зонд), следующго содержания

#! /bin/sh

if [ -f /var/spool/cron/root ] ; then
        sed '/BCFG2 start/,/BCFG2 end/d' /var/spool/cron/root 
else
        echo ""
fi

# vim:filetype=sh

Note-icon.gif

Если со временем изменится путь к этому файлу, то это надо обязательно учесть и в этом пробнике, иначе все локальные данные в новом файле cront/root потеряются.


Для того, что бы данный зонд отрабатывал только для хостов группы centos, надо задать данное условие в свойствах зонда.

Все зонды конфигурируются в одном файле FileProbes/config.xml

<FileProbes>
  <Group name="centos">
    <FileProbe name="/var/spool/cron/root"/>
  </Group>
</FileProbes>

При этом необходимо подключение плагина в bcfg2.conf.

Note-icon.gif

Плагин FileProbes является экспериментальным. За место него можно использовать специальное имя зонда root_cron, переименовав его в root_cron.G00_centos

Данный зонд выведет в stdout все изменения в файле, сделанные локально. Весь вывод сохраняется в Probes/probed.xml (см. поле value) для дальнейшего обращения к этим данным. Если имеется угроза появления большого числа зондов, то для уменьшения нагрузки можно создать 1 зонд, который будет собирать всю нужную информацию и содержание к которой можно получить из probed.xml. Описание расширенной обработки данных описан в документации.

Note-icon.gif

Передача параметров в зонд (argc, argv и т.п) не поддерживается.

[править] Объединение данных и генерация нового файла

Создаем файл Cfg/var/spool/cron/root/root.cheetah (расширение файла указывает на применение генератора TCheetah)

# BCFG2 start
MAILTO=root
10       10      */2     *       *       yum --security check-update
# BCFG2 end

$self.metadata.Probes['root_cron']

Note-icon.gif

Все символы $ внутри блока (BCFG2 start..BCFG2 end) нужно эранироать символом \, иначе будет выдаваться ошибка

 Entry Path:/etc/make.conf reports bind failure: bind error:
 Cannot install entry Path:/etc/make.conf with bind failure


и файл Cfg/var/spool/cron/root/info.xml

<FileInfo> 
        <Info owner='root' group='root'  perms='0600' encoding='utf-8'/> 
</FileInfo> 

$self.metadata.Probes['root_cron'] - функция, которая поместит в файл те данные, которые вывел в stdout зонд root_cron

Эти темы не раскрыты: Генератор TGenshi может проделать туже операцию, но функция ${metadata.Probes['probes']} выводит все данные в одну строку. Каким-то образом можно прикрутить к ней метод .split("/n")

http://comments.gmane.org/gmane.comp.sysutils.bcfg2.devel/4636


Создаем Bundle (Bundler/rootcron.xml) для файла var/spool/cron/root/root

<Bundle name='rootcron' version='2.0'>
        <Group name="centos">
                <Path name='/var/spool/cron/root'/>
        </Group>
</Bundle>

Эти темы не раскрыты: В Path name возможны значения:

  • <Path name='/var/spool/cron/root' update="true"/>
  • <Path name='/var/spool/cron/root' base64="true"/>

и помещаем Bundle в Metadata/groups.xml

...
<Group default='false' name='centos' profile='false' public='true'>
        <Bundle name='bcfg2'/>
        <Bundle name='centosdeploy'/>
        <Bundle name='snmpd'/>
        <Bundle name='nsca'/>
        <Bundle name='nagiosplugins'/>
        <Bundle name='rootcron'/>
</Group>
...

[править] Просмотр предварительных результатов

Работает при условии использования ТGenshi.

На хосте надо выполнить

 bcfg2 -qvn 

и на сервере

 bcfg2-info buildfile /var/spool/cron/root apcagent2.host.net

[править] Управление сервисами

Предположим, стоит задача управлять сервисом apache с учетом изменения фала php.ini, т.е. всякие изменение этого файла приведет к тому, что apache перечитает конфигурацию.

[править] Конфигурация Cfg

# ls -1  Cfg/etc/php/apache2-php5.3/php.ini/
info.xml
php.ini

# cat Cfg/etc/php/apache2-php5.3/php.ini/info.xml
<FileInfo>
 	<Info owner='root' group='root' perms='0644' encoding='UTF-8'/>
</FileInfo>

[править] Конфигурация Bundler

# cat  Bundler/phpini.xml 
<Bundle name='phpini' version='2.0'>
	<Service name='apache2'/>
	<Path name='/etc/php/apache2-php5.3/php.ini'/>
</Bundle>

[править] Конфигурация Rules

В этом файле задается описние всех сервисов (а так же пакетов для установки) с учетом операционной системы, на которой работает агент bcfg2.

# cat  Rules/services.xml 
<Rules priority='0'>                                                                                                                                         
	<Service name='apache2' type='rc-update' status='on' target='reload'/>                                                                              
</Rules>                 

type - зависит от операционной системы (см. Rules)

[править] Конфигурация Metadata

Добавляем Bundler в Metadata/groups.xml

   <Group name='php'>
   	<Bundle name='phpini'/>
   </Group>


[править] Обновление grub2

При всяком обновлении файлов конфигурации grub2 есть необходимость генерации новых конфигурационных файлов методом запуска update-grub. В примере ниже рассмотрен случай для настройки grub2 на редирект консоли в ttyS1 в ubuntu 12.04.

Структура конфигурации

.
├── Bundler
│   ├── grub.xml
├── Cfg
│   └── etc
│       ├── default
│       │   └── grub
│       │       ├── grub
│       │       └── info.xml
│       ├── init
│       │   └── ttys1.conf
│       │       ├── info.xml
│       │       └── ttys1.conf
├── Metadata
│   ├── clients.xml
│   └── groups.xml
├── Rules
    └── services.xml

Файл grub.xml

<Bundle name='grub'>
	<Group name="ubuntu12">
		<Path name="/etc/default/grub"/>
		<Path name="/etc/init/ttys1.conf"/>
		<Action name='update-grub'/>
	</Group>
</Bundle>

Файл services.xml

<Rules priority='0'>
    <Group name='ubuntu12'>
	<Action timing='post' name='update-grub' command='update-grub2' when='modified' status='check'/>
    </Group>
</Rules>

Ключевое значение играет директива Action с именем name='update-grub'. Согласно директиве, всякое изменение файлов "/etc/default/grub" или "/etc/init/ttys1.conf" приведет к действию команды command='update-grub2'. Где

  • timing='post' - выполнение директивы именно после удачного процесса изменения файлов bcfg2 клиентом
  • when='modified' - выполнение директивы только в том случае, если файлы были изменены
  • status='check' - проверять код возврата команды command.


Файл grub

GRUB_DEFAULT=0
GRUB_TIMEOUT=30
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="console=tty0 console=ttyS1,115200 nomodeset"
GRUB_CMDLINE_LINUX=""
GRUB_TERMINAL=console
GRUB_GFXMODE=640x480

Файл ttys1.conf

# ttyS1 - agetty
#
# This service maintains a getty on ttyS0 from the point the system is
# started until it is shut down again.

start on stopped rc or RUNLEVEL=[2345]
stop on runlevel [!2345]

respawn
exec /sbin/agetty -L 115200 ttyS1 vt100

[править] Проверка

[править] bcfg2-repo-validate

Проверка структоры данных.

[править] bcfg2-lint

Проверка структуры дынных. Предпочтительна команде bcfg2-repo-validate.

[править] bcfg2-test

Самая глубокая проверка. Проверка синаксиса в генераторах cheetah, genshi и прочих.

[править] Генераторы конфигураций и плагины

[править] Accounts

Неподдерживается в версии 1.3.х. В версиях 1.4.х будет удален.

[править] BB

Удален в версии 1.3.

[править] Bundler

Schema.

[править] Cfg

Поддержка файлов :info, info прекращена в версии 1.3.х и будет полностью удалена в версии 1.4.х.

[править] Decisions

[править] DBStats

Заменен на Reporting с версии 1.3.

[править] FileProbes

Экспериментальный плагин.

[править] Hostbase

Неподдерживается в версии 1.3.х. В версиях 1.4.х будет удален.

[править] NagiosGen

[править] Packages

[править] Pkgmgr

[править] POSIXCompat

Для сервера. Появился в версии 1.3.x.

[править] Reporting

Бывший DBStats (пришел на замену в версии 1.3).

tools/upgrade/1.3/migrate_dbstats.py

- миграция данных в новый формат.

[править] Probes

[править] Rules

Документация

[править] Значение type

  • chkconfig
  • deb
  • rc-update
  • smf
  • upstart
  • systemd
  • launchd
  • freebsd


[править] SGenshi

Удален в версии 1.3.

[править] Snapshots

Неподдерживается в версии 1.3.х. В версиях 1.4.х будет удален.

[править] SSHbase

[править] Svcmgr

Удален в версии 1.3.

[править] SVN

[править] SSLCA

[править] TGenshi

Неподдерживается в версии 1.3.х. В версиях 1.4.х будет удален. Функционал реализуется в плагине Cfg потем добавление в имени файла расширения .genshi. В версии 1.2.3 нет необходимости подключать явно этот плагин через bcfg2.conf.

[править] TCheetah

Неподдерживается в версии 1.3.х. В версиях 1.4.х будет удален. Функционал реализуется в плагине Cfg потем добавление в имени файла расширения .cheetah. В версии 1.2.3 нет необходимости подключать явно этот плагин через bcfg2.conf.

[править] Переопределение директив

#compiler-settings
directiveStartToken = ^ 
commentStartToken = \#
#end compiler-settings

[править] Trigger

Скрипты, выполняющиеся только на сервере. Подробности.

[править] Визуализация конфигурации

 bcfg2-admin viz -bkH -o 123.png

bcfg2viz.png

[править] Устаревшие плагины

  • Base

[править] Разное

[править] Смена интерпретатора для Probes

Файл /usr/sbin/bcfg2

(probe.attrib.get('interpreter', '/bin/sh')))

[править] Ссылки

1.3.0 Prerelease 1 Release Announcement

1.3.0 Prerelease 2 Release Announcement

1.3.0 Release Announcement

1.3.1 Release Announcement

1.3.2 Release Announcement

1.3.3 Release Announcement

1.3.4,1.3.5 Release Announcement

Источник — «http://xgu.xgu.ru/wiki/bcfg2»