Cfengine3 — немного о policy hub

В прошлой заметке я кратко рассказал о замечательной системе управления конфигурациями cfengine3. Сегодня рассмотрим ее немного подробнее касательно клиент-серверной настройки и более тонкой настройки клиентов в зависимости от предполагаемой функциональности.

Устанавливаем cfengine3 пакет, как и в прошлой замете, как на клиенте так и на сервере политики (policy hub). Рассмотрим следующую клиент-серверную cfengine3 конфигурацию. Положим: policyhub01 198.51.100.10, srv01.local 203.0.113.101. Инициализируем себя как policy hub (198.51.100.10 наш собственный IP). Полиси хаб, как раз и есть то место которое служит централизованным хранилищем наших политик, которые позднее будут скачаны с него клиентами. Почти все системы менеджмента конфигураций используют pull, а не push, тому есть много причин, рассмотрение которых займет не меньше чем объем этой заметки.
root@policyhub01:/tmp# /var/cfengine/bin/cf-agent —bootstrap —policy-server=198.51.100.10

** CFEngine BOOTSTRAP probe initiated     @@@          @@@      CFEngine               @ @@@ @    CFEngine Core 3.4.1  @ @@@ @      @ @@@ @      @     @        @@@          @ @          @ @          @ @        Copyright (C) CFEngine AS 2008-2012 See Licensing at http://cfengine.com/3rdpartylicenses   -> This host is: policyhub01.local  -> Operating System Type is linux  -> Operating System Release is 3.6.10-vs2.3.4.6  -> Architecture = x86_64  -> Internal soft-class is linux  -> No policy failsafe discovered, assume temporary bootstrap vector  -> No previous policy has been cached on this host  -> Assuming the policy distribution point at: 198.51.100.10:/var/cfengine/masterfiles  -> Attempting to initiate promised autonomous services...   ** This host recognizes itself as a CFEngine Policy Hub, with policy distribution and knowledge base.  -> The system is now converging. Full initialisation and self-analysis could take up to 30 minutes  R: This host assumes the role of policy distribution host R:  -> Updated local policy from policy server R:  -> Started the server R:  -> Started the scheduler -> Bootstrap to 198.51.100.10 completed successfully 

Теперь переходим к клиенту:
root@srv01:/tmp# /var/cfengine/bin/cf-agent —bootstrap —policy-server=198.51.100.10

-> No policy failsafe discovered, assume temporary bootstrap vector  -> No previous policy has been cached on this host  -> Assuming the policy distribution point at: 198.51.100.10:/var/cfengine/masterfiles  -> Attempting to initiate promised autonomous services...  Challenge response from server 198.51.100.10/198.51.100.10 was incorrect!  !! Authentication dialogue with 198.51.100.10 failed R: This autonomous node assumes the role of voluntary client R:  !! Failed to pull policy from policy server R:  !! Did not start the scheduler !! Bootstrapping failed, no input file at /var/cfengine/inputs/promises.cf after bootstrap  Часть вывода удалена. 

Не работает! По умолчанию cfengine3 доверяет только хостам из своей /16, а у нас сервер и клиент в разных сетях. Кроме того это слишком широкий диапазон и следует его сразу ограничить в файлах /var/cfengine/inputs/def.cf и /var/cfengine/inputs/controls/cf_serverd.cf.
Исправляем на plicyhub01 файл /var/cfengine/inputs/def.cf

    "acl" slist => {                    "$(sys.policy_hub)",                 "203.0.113.101/32",                    }, 

Можно было бы (и идеологически правильнее ?) сделать обмен ключами иным
способом, не же ли делать ‘trust’ по IP. Выполняем на srv01 опять: root@srv01:/tmp# /var/cfengine/bin/cf-agent —bootstrap —policy-server=198.51.100.10

** CFEngine BOOTSTRAP probe initiated     @@@          @@@      CFEngine               @ @@@ @    CFEngine Core 3.4.1  @ @@@ @      @ @@@ @      @     @        @@@          @ @          @ @          @ @        Copyright (C) CFEngine AS 2008-2012 See Licensing at http://cfengine.com/3rdpartylicenses   -> This host is: srv01.local  -> Operating System Type is linux  -> Operating System Release is 3.6.10-vs2.3.4.6  -> Architecture = x86_64  -> Internal soft-class is linux  -> An existing policy was cached on this host in /var/cfengine/inputs  -> Assuming the policy distribution point at: 198.51.100.10:/var/cfengine/masterfiles  -> Attempting to initiate promised autonomous services...  R: This autonomous node assumes the role of voluntary client -> Bootstrap to 198.51.100.10 completed successfully 

Успех! Теперь самое время написать несколько политик на стороне policyhub01 и убедится что все работает.
На policyhub01 в /var/cfengine/masterfiles создаем файлы
config_web_srv.cf:

bundle agent config_web_srv {  vars:   "package_list" slist => { "nginx" };   packages:   "${package_list}"   package_policy => "add",   package_method => generic;   processes:    "nginx"          restart_class => "start_nginx";  commands:     "/etc/init.d/nginx restart"        ifvarclass => canonify("start_nginx");  } 

и install_base_pkg.cf:

bundle agent install_base_pkg {  vars:   "package_list" slist => { "vim", "mc" };   packages:   "${package_list}"   package_policy => "add",   package_method => generic;    files:   linux::    "/etc/motd"    edit_line     => insert_lines("This host is managed by cfengine3!"); } 

Важно скопировать эти файлы так же в inputs: root@policyhub01:/var/cfengine/masterfiles# cp config_web_srv.cf install_base_pkg.cf ../inputs/. Теперь настало время сказать кто же из хостов должен выполнить эти полиси. В файле /var/cfengine/masterfiles/promises.cf находим body control inputs и добавляем туда наши файлы:

inputs => {           # Global common bundles             "def.cf",           # Control body for all agents             "controls/cf_agent.cf",             "controls/cf_execd.cf",             "controls/cf_monitord.cf",             "controls/cf_report.cf",             "controls/cf_runagent.cf",             "controls/cf_serverd.cf",           # COPBL/Custom libraries             "libraries/cfengine_stdlib.cf",           # Design Center              # MARKER FOR CF-SKETCH INPUT INSERTION              "cf-sketch-runfile.cf",           # User services from here             "services/init_msg.cf",           # our policies             "config_web_srv.cf",             "install_base_pkg.cf",              }; 

Далее, в этом же файле создаем наш бандл:

bundle agent config {  classes:     "web_srv"    or => { classmatch("web.*"),                          "srv01_local",                          "web3_example_com"                        };  methods:     web_srv::         "config_web_srv" usebundle => "config_web_srv";     any::         "install_everywhere" usebundle => "install_base_pkg";   reports:   cfengine_3::     "bundle agent config DONE";  } 

И добавляем его в bundlesequence:

 bundlesequence => {                   # Common bundles first for best practice                     "def",                   # Design Center                     "cfsketch_run",                   # Agent buddles from here                     "main",                   # Our ccustomisation                     "config",                     };  

Сохраняем и ждем примерно 5 минут. Проверяем и удостоверяемся, что пакеты из install_base_pkg и config_web_srv установлены. Разберем, что произошло. Клиент, как и положено, скачал себе в inputs файлы из masterfiles нашего полиси хаба. Далее cf-agen на стороне srv01 начинает их обрабатывать, предварительно установив хард классы:

Hard classes = { 203_0_113_101 2_cpus 64_bit Afternoon Day6 GMT_Hr17 Hr17 Hr17_Q2 January Lcycle_0 Min20_25 Min21 PK_MD5_877dfa1640c3c49a2065ce220a3b821f Q2 Sunday Yr2013 agent any cfengine cfengine_3 cfengine_3_4 cfengine_3_4_1 cfengine_in_high community_edition compiled_on_linux_gnu cpu0_normal cpu1_normal cpu_normal debian debian_7 debian_7_0 diskfree_high_normal entropy_misc_in_low entropy_misc_out_low entropy_postgresql_in_low entropy_postgresql_out_low have_aptitude ipv4_203 ipv4_203_0 ipv4_203_0_113 ipv4_203_0_113_101 linux linux_3_6_10_vs2_3_4_6 linux_x86_64 linux_x86_64_3_6_10_vs2_3_4_6 linux_x86_64_3_6_10_vs2_3_4_6__1_SMP_Mon_Dec_17_03_23_11_UTC_2012 local mac_00_25_64_3b_97_cb messages_high_ldt messages_high_normal net_iface_br0 opt_dry_run otherprocs_low rootprocs_high rootprocs_high_ldt srv01 srv01_local syslog_high_ldt syslog_high_normal users_low verbose_mode www_in_low x86_64 } 

Список хард классов на данном хосте можно получить запустив cf-agent -v. Выше мы сказали bundlesequence включить наш бандл ‘config’. Первым делом мы устанавливаем soft классы в зависимости от имеющихся hard классов. В случае нашего srv01 будет установлен soft класс web_srv, потому что произойдет совпадение по классу доменного имени. Соответственно, когда будет отрабатывать секция methods произойдет сравнение классов и будет вызван нужный bundle. Бандл install_base_pkg отработает для всех хостов, так как hard класс any установлен всегда. Для веб-серверов отработает и install_base_pkg и config_web_srv, который установит пакет nginx и периодически будет удостоверятся что он запущен. Этим как раз и занимается класс nginx типа proccess, который установит soft класс «start_nginx» если такого процесса нет, что соответственно, приведет к выполнению команды "/etc/init.d/nginx restart". Вы можете специально или случайно остановить nginx, но cfengine все равно его запустит через некоторое время!

На этом все, надеюсь эта заметка прояснила в некоторой мере вопрос «solo» и «клиен-сервер» конфигурации. Как всегда, официальный сайт, и в частности, готовые решения всегда придут на помощь!