Ключевые слова:cfengine, config, (найти похожие документы)
From: Сергей Яремчук
Date: 16 Apr 2010
Subject: Централизованное управление при помощи Cfengine
Материал предоставлен редакцией журнала Системный администратор.
Опубликовано в журнале "Системный администратор" N 1 2010
Трудно управлять большим количеством систем без средств автоматизации.
Этот проект облегчит задачу и позволит централизовано устанавливать
параметры
Чтобы вручную произвести изменения в нескольких конфигурационных файлах
на серверах, выполняющих разную роль, придется потратить немало
времени. Как минимум потребуется проанализировать имеющиеся установки,
выбрать системы, на которых будут производиться перестройки,
подготовить новые конфигурационные файлы или выбрать другие средства
для изменения настроек серверов. И чем больше количество и
разнообразнее системы, находящиеся в подчинении администратора, тем
более значительных усилий потребует перестройка всей сети, тем больше
вероятность сделать ошибку. Использование единой точки, в которой были
бы собраны все настройки, позволило бы сократить время на активацию
новых установок и снизило вероятность ошибки. В журнале уже обсуждались
возможности системы централизованного управления Puppet [1]. Это
достаточно новый проект, его основные идеи были взяты Cfengine [2],
который имеет аналогичное назначение. О Cfengine и пойдет речь далее.
О Cfengine
Проект Cfengine анонсирован в 1993 году, его разработкой занимается в
основном один человек - профессор Норвежского университета (Осло) Марк
Бюргес (Mark Burgess). В основе построения Cfengine лежит "Теория
обязательств" (Promise Theory), адаптированная Марком Бюргесом
применительно к области автоматизации и управления. Основная идея
Promise Theory состоит в добровольном взаимодействии автономных агентов
между собой. При этом особое внимание уделяется стабильному состоянию
системы, а не перестройкам. Система дает обещание, что она правильно
настроена и проверяет это состояние. Изменения вносятся только в
случае, если обещания, то есть указания на перестройку, не выполнены. В
итоге при внесении каких- либо изменений вся сеть через некоторое время
приходит к единому состоянию.
Предоставляя достаточно большие возможности, Cfengine тем не менее так
и не стал популярен среди системных администраторов, несмотря на то что
за время существования проекта код был загружен более миллиона раз. О
низкой популярности косвенно свидетельствуют относительно небольшое
количество публикаций в специализированных журналах и отсутствие
сообществ.
Исходный код доступен и распространяется под лицензией GNU GPL, но все
изменения и пожелания весьма жестко контролировались Марком Бюргесом.
Вероятно поэтому, Cfengine ранее называли проектом одного человека.
Сегодня ситуация несколько изменилась, в том числе создана и
коммерческая версия продукта. Правила можно представить как язык
программирования очень высокого уровня, на изучение которого в любом
случае придется потратить некоторое время. Большие возможности сделали
систему относительно сложной в изучении, язык при этом выглядел
достаточно запутанным. Это главные причины малой популярности веток 1 и
2.
В апреле 2009 года была представлена 3-я (Сommunity edition) версия
Cfengine, лицензируемая под GPL v3. Беглого взгляда на документацию
достаточно, чтобы понять, что перед нами существенно переработанный
продукт, который даже позиционируется несколько по-иному, как
фреймворк. Здесь уже используется новый язык описания с более четким и
простым синтаксисом, поддержкой классов и шаблонов функций. Добавлены
новые функции отчетов, поддержка управления знаниями и виртуализации,
более тесной интеграции с другими программными продуктами. Однажды
созданная конфигурация легко читаема, и соответственно в нее просто
внести изменения. Возможно использование в одной сети систем Cfengine 2
и 3, что упрощает переход на новую ветку.
Следует отметить наличие многостраничных руководств на английском
языке, в которых расписаны многие тонкости по работе с Cfengine. Но,
как водится, написаны они самими разработчиками, часто "забывающими"
указать отдельные "мелочи", всплывающие во время настройки, или
вовремя не вносящими изменения.
В дальнейшем речь пойдет именно об Cfengine 3. В середине 2008 года
образована Cfengine AS, которая занимается распространением
коммерческой версии Cfengine Nova, построенной на тех же принципах, что
и Cfengine 3, но более удобной в развертывании, управлении и генерации
отчетов.
Возможности Cfengine
По своему принципу Cfengine относится к декларативным системам, то есть
подчиненные системы получают не инструкции по изменению состояния, а
описание желаемого/конечного состояния. Процесс проверки соответствия
цикличен и при несанкционированном изменении конфигурации управляемой
системы, возврат к нужному значению будет произведен автоматически.
Главные требования к Cfengine - работа в большой сети с изменяющейся
конфигурацией и высокая безопасность. Приложение способно работать
практически в любой гетерогенной среде, с любым количеством
компьютеров, в том числе при использовании низкоскоростных каналов, и в
мобильных агентах, редко подключающихся к сети. Написан Cfengine на
языке С. Поддерживаются Windows (cygwin), Linux, Mac OS X, Solaris,
AIX, HPUX и прочие UNIX-системы.
При помощи Cfengine можно автоматизировать:
* создание, изменение и удаление файлов и символических ссылок;
* изменение конфигурационных файлов в соответствии с правилами;
* проверку и настройку сетевых интерфейсов;
* проверку и установку прав доступа к файлам и каталогам;
* монтирование файловых систем;
* контроль над изменением файлов при помощи MD5-суммы;
* откат несанкционированных изменений;
* запуск скриптов и команд, контроль над выполнением;
* управление и контроль над работой сервисов (демонов);
* дублирование системных настроек - при замене сервера нужные
настройки будут произведены автоматически;
* изменение реестра Windows и зон Solaris.
Основная идея Cfengine - создание единого набора конфигурационных
файлов, описывающих настройку единой системы или всех узлов в сети.
Использована клиент-серверная архитектура, реализованная с несколькими
утилитами, выполняющими различные задачи. После установки Cfengine
агент связывается с сервером, где получает сведения о конфигурации и
применяет изменения, если такие будут обнаружены.
Типичная инфраструктура может состоять из трех компонентов:
1. Policy Definition Point - не обязательная, но очень желательная
часть системы, построенная на системе контроля версия вроде CVS,
позволяющая отслеживать все изменения в настройках;
2. Distribution point - один или несколько серверов, которые
распространяют файлы политики, описанные в promises.cf и расположенные
в каталоге /var/cfengine/masterfiles;
3. конечные узлы - на которых применяются политики, скопированные из
Distribution point в каталог /var/cfengine/inputs.
После получения политик в конечной точке извлекаются и применяются
только те настройки, которые имеют отношение к текущему узлу.
Подготавливаем систему к сборке
Установка Cfengine 3 в Ubuntu
В репозитарии текущей LTS-версии Ubuntu 8.04 доступна только вторая
версия Cfengine. Третья имеется лишь в Ubuntu 10.4 (Lucid Lynx),
который также планируется к выпуску с приставкой LTS (Long Term
Support). Поэтому установка последнего релиза возможна лишь из исходных
текстов. В качестве зависимостей указаны библиотеки OpenSSL, libc6,
база данных BerkeleyDB, компилятор и опционально PCRE (Perl Compatible
Regular Expression). В большинстве случаев все необходимое в системе
есть.
sudo apt-get install libdb4.6 libdb4.6-dev libssl0.9.8 libc6 libpcre3 bison flex
При наличии библиотек OpenLDAP, MySQL, PostgreSQL будут доступны
дополнительные возможности, хотя Cfengine cможет работать и без них.
Скачиваем исходные тексты Cfengine 3:
wget -с http://www.cfengine.org/tarballs/cfengine-3.0.2.tar.gz
Распаковываем архив и компилируем стандартным образом (./configure;
make; make install).
Обновления выходят приблизительно раз в полгода, исключение делается
только при обнаружении серьезных проблем. Доступна и версия для
разработчиков, в которой имеются все последние наработки:
$ mkdir cfengine
$ cd cfengine
$ svn checkout https://svn.iu.hio.no/projects/cfengine-3/trunk
После установки в каталоге /usr/local/sbin появится несколько
исполняемых файлов:
cf-agent - клиентская часть, агент, непосредственно выполняющий
конфигурирование системы, именно он осуществляет модификацию,
перезапуск сервисов, выполняет сценарии и прочие настройки;
cf-serverd -серверная часть, коорая обеспечивает агентам совместное
использование любых файлов, в том числе и конфигурационных, и получает
запросы на выполнение текущей политики;
cf-execd - планирует выполнение заданий, обеспечивает сбор
результата и отправку сообщения на системную учетную запись, может
служить заменой cron;
cf-key - создает открытые и частные ключи, используемые утилитами
cf-agent и cf-serverd для опознавания друг друга;
cf-know - агент, позволяющий построить карту семантической сети
обмена знаниями по стандарту ISO;
cf-monitord - агент мониторинга, контролирующий текущее состояние
системы (процессы, сетевые соединения, использование ресурсов и т.д.),
также анализирует изменения на предмет аномальности;
cf-promices - проверка набора конфигурации перед ее применением;
cf-report - создание отчетов в различных форматах;
cf-runagent - вспомогательная программа, при помощи которой можно
потребовать от cf-serverd выполнения cf-agent с существующей политикой.
Может применяться для имитации изменений на клиентских системах и
принудительного применения политик.
В Cfengine 2 названия исполняемых файлов отличались.
Для своей работы различные компоненты Cfengine используют подкаталоги в
/var/cfengine или ~/.cfagent (при запуске под учетной записью, отличной
от root). Причем некоторые пути в /var/cfengine жестко вшиты в исходный
код. Это сделано для повышения безопасности, поэтому при попытке
вынести отдельные файлы или настройки за пределы /var/cfengine утилит
из его состава не могут их найти.
Файлы, расположенные в /var/cfengine/masterfiles, содержат политики и
используются в Distribution point, в /var/cfengine/inputs на клиентских
системах хранятся полученные с Distribution point файлы, которые будут
считываться при запуске, в /var/cfengine/outputs - отчеты об изменениях
и текущем состоянии. Все каталоги, за исключением masterfiles, будут
созданы автоматически при запуске программы клиента.
После установки шаблоны политик находятся в каталоге
/usr/local/share/doc/cfengine. Их можно использовать при ознакомлении с
принципами работы. Создаем на Distribution point нужный каталог и
копируем в него шаблоны:
$ sudo mkdir -p /var/cfengine/masterfiles
$ sudo cp /usr/local/share/doc/cfengine/*.cf /var/cfengine/masterfiles
Хотя чтобы не быть заваленными сообщениями, лучше брать шаблоны по
одному и смотреть, как они работают.
Далее необходимо создать ключи сервера:
$ sudo /usr/local/sbin/cf-key
После запуска утилиты в /var/cfengine будет создано еще несколько
подкаталогов, ключи будут сохранены в /var/cfengine/ppkeys.
$ sudo ls /var/cfengine/ppkeys/
localhost.priv localhost.pub
По умолчанию имя начинается с localhost, но, используя дополнительные
параметры (их можно узнать при помощи -help), можно указать другое
название файла и каталог, но это не всегда желательно. Кроме политик, в
inputs должны находиться три обязательных файла:
promises.cf - основной конфигурационный файл, агент и сервер будут
считывать его при запуске;
update.cf - файл, определяющий настройки обновлений, получаемых агентами;
failsafe.cf - файл, считываемый сервером и агентом в том случае,
когда другие настройки недоступны или неправильны. С его помощью агент
может восстановить настройки.
Если таких файлов не будет найдено, получим сообщения вроде:
Can't stat file "/var/cfengine/inputs/failsafe.cf" for parsing
Кроме этого, возможно использование отдельных файлов для настройки
каждого компонента или вспомогательных целей. Имена можно задавать
произвольно, но обычно выбирают более описательные: cf-server.cf,
cf-execd.cf, cfbackup.cf и так далее. Но чтобы их задействовать, они
должны быть описаны в файле promises.cf в секции inputs в body common
control. Как это сделать, будет показано далее.
Заготовки основных файлов уже есть, копируем:
$ sudo /usr/local/share/doc/cfengine/inputs/*.cf /var/cfengine/inputs
Теперь, после изменений в файлах политики, можно запускать агента для
приведения их в действие.
По умолчанию cf-agent ищет настройки в текущем каталоге, inputs и
/home/user/.cfagent. Здесь есть несколько особенностей. Если для
удобства создать символическую ссылку в каталог /etc, например
/var/cfengine/inputs -> /etc/cfengine, то после запуска cf-agent она
будет переименована в inputs.cf-moved -> /etc/cfengine, а каталог
inputs будет создан вновь и, естественно, без конфигурационных файлов
внутри.
Кроме этого, агент требует, чтобы исполняемый файл cf-promises был
установлен в домашний каталог /var/cfengine/bin:
cf-promises needs to be installed in /var/cfengine/bin for
pre-validation of full configuration
Такое поведение в целях безопасности вшито в код, изменить его можно
только путем перекомпиляции, но вряд ли в этом есть смысл.
Проверяем:
$ whereis cf-promises
cf-promises: /usr/local/sbin/cf-promises
И устраняем:
$ sudo cp /usr/local/sbin/cf-promises /var/cfengine/bin
Текущая версия Cfengine 3.0.2 почему-то разрешает использование такой
символической ссылки, выходящей за пределы /var/cfengine:
$ sudo ln -s /usr/local/sbin/cf-promises /var/cfengine/bin
Но такое поведение несвойственно Cfengine, ранее символическая ссылка
не работала, поэтому файл лучше именно копировать. После первого
запуска агента в каталог /var/cfengine/bin или ~/.cfagent/bin будут
скопированы и все остальные исполняемые файлы, входящие в комплект
Cfengine. Кроме этого, здесь образуются символические ссылки для
запуска named-checkzone и утилит из комплекта dnssec-tools (если такие
есть в системе).
Теперь можно попробовать загрузить (восстановить) конфигурацию Cfengine
из failsafe.cf.
$ cd /var/cfengine/masterfiles
$ sudo /usr/local/sbin/cf-agent --bootstrap
Эта команда считает все файлы с расширением .cf в текущем каталоге и
переместит их в inputs. Кроме этого, в /var/cfengine будут созданы
файлы журналов (выполненных операций), базы с классами, аудита,
системными настройками и т.п.
Чтобы продвигаться дальше, необходимо разобраться с правилами и
обязательствами.
Описание политик
В терминологии Cfengine все указания называются обязательствами или
обещаниями (англ. promises), что полностью соответствует используемой
теории, но чтобы не путать, я буду использовать более привычные
компьютерные - политика и правила, чем они, собственно, и являются. В
отличие от предыдущей версии механизм описания правил переработан.
Сейчас политики стали более структурированными и могут содержать
правило (promises), коллекцию правил (promise bundles), которые также
группируются в большую единицу - promise body. Также присутствуют и
остальные атрибуты - классы, функции, циклы, массивы, переменные и
данные. Те, кто изучал язык Perl, найдут в готовых правилах много
знакомого.
Собственно, правила в Cfengine могут состоять из четырех компонентов -
типа, класса, объекта (promiser) и атрибутов:
type:
class::
"promiser" -> { "promisee1", "promisee2", ... }
attribute_1 => value_1,
...
attribute_2 => value_n.
Не все элементы используются в правилах, некоторые элементы содержат
неявные указания, которые могут опускаться.
Поле "тип" указывает на вид операции, то есть что необходимо сделать.
В зависимости от типа системы может быть использован один из следующих
классов:
в любом правиле - vars (переменная), classes (класс, показывающий
состояние системы), reports (отчет);
только в агентах - commands (выполнение команды), databases (настройка
базы данных), files (создание и наполнение файла, установка атрибутов),
interfaces (настройка сетевых интерфейсов), packages (установка
пакета), storage (проверка подключенного диска), methods (обработка
других правил);
относятся к остальным компонентам - access (доступ к объектам в
cf-serverd), measurements (выбор данных для отчета или мониторинга, в
Cfengine Nova), roles (разрешение активации отдельных классов при
удаленном запуске cf-agent через cf-serverd), topics (ассоциация с
именем при запуске cf-know) и occurrences (обращение к ресурсу в
cf-know).
Поле "класс" описывает группу объектов, к которым относятся правила.
Во многих встроенных правилах это поле отсутствует, что соответствует
значению any, то есть любой. Здесь могут стоять имя ОС (linux, solaris,
ubuntu, debian ...), имя или IP-адрес узла, название интерфейса, зона
Solaris, учетная запись или группа, время (год, день, час, минута, цикл
и т.п.). Просмотреть список классов на текущем узле можно при помощи
команды:
# cf-promises -v
cf3 -> Defined hard classes = { any verbose_mode Wednesday
Hr02 Night Min07 Min05_10 Q1 Hr02_Q1 Day16 December
Yr2009 Lcycle_2 GMT_Hr23 linux ubuntu undefined_domain
32_bit linux_2_6_24_19_server i686 linux_i686 linux_
i686_2_6_24_19_server linux_i686_2_6_24_19_server__1_
SMP_Wed_Jun_18_15_18_00_UTC_2008 compiled_on_linux_gnu
virtual net_iface_lo net_iface_eth0 ipv4_192_168_17_156
ipv4_192_168_17 ipv4_192_168 ipv4_192 fe80__20c_29ff_fed7_
a8e1 cfengine_3_0_2 cfengine_3_0 cfengine_3 debian
lsb_compliant ubuntu_hardy ubuntu_8_4 ubuntu_8 common }
Список классов также доступен в файле allclasses.txt, расположенном в
каталоге /var/cfengine/state. Кроме встроенных (hard) классов,
различают и пользовательские (soft) классы. Классы с типом common
являются глобальными, любые другие - локальные. При вызове класса можно
использовать круглые скобки для группировки и операторы сравнения (!, &
(или точка "."), | (или ||)). В итоге достаточно легко задать
практически любое условие выполнения, которое к тому же хорошо
читается.
Например:
ubuntu_hardy&Yr2010&(Monday| Friday)&Night&Min05
Такая запись класса задает условие: Ubuntu 8.04, 2010 год, ночь в
понедельник или пятницу, 5-я минута часа. Имя файла можно задать как
полностью, включая путь (например, /etc/passwd), так и использовать
регулярное выражение.
Для примера возьмем один из файлов шаблона unit_helloworld.cf, копируем
его в inputs.
$ whereis cf-promises
cf-promises: /usr/local/sbin/cf-promises
Смотрим, что внутри unit_helloworld.cf
# Объявляем глобальный набор классов control
body common control
{
bundlesequence => { "hello" }; # Определение класса
}
# Локальная коллекция hello, ориентированная на агентов
bundle agent hello
{
reports: # Тип отчеты
linux:: # Класс linux
"Hello world!"; # Выводимые данные
}
Перед применением необходимо проверить политику на отсутствие
синтаксических ошибок, для этого запускаем cf-promises. Чтобы получить
большую информацию по работе утилиты, используем дополнительно ключи -r
(создание отчета) и -d (отладочный режим). В обычном режиме они не
нужны, здесь лучше использовать ключ -v:
$ sudo cf-promises -d 3 -r -f /var/cfengines/inputs/unit_helloworld.cf
В выводе будет видно, как анализируются текущие системные установки,
устанавливаются классы и переменные, которые могут быть с ней
сопоставлены.
NewClass(ipv4_192)
NewScalar(sys,ipv4[eth0],192.168.17.156)
AddVariableHash(sys.ipv4[eth0]=192.168.17.156 (string) rtype=s)
Searching for scope context sys
Added Variable ipv4[eth0] at hash address 1834 in scope sys
with value (omitted)
NewScalar(sys,ipv4_3[eth0],192.168.17)
AddVariableHash(sys.ipv4_3[eth0]=192.168.17 (string) rtype=s)
...
NewClass(lsb_compliant)
cf_popen(/usr/bin/lsb_release --id)
cf_pclose(pp)
cf_pwait - Waiting for process 27979
NewClass(ubuntu)
cf_popen(/usr/bin/lsb_release --codename)
cf_pclose(pp)
cf_pwait - Waiting for process 27982
NewClass(ubuntu_hardy)
Далее идет проверка каталогов, доступа и так далее. Если все правильно,
последней строкой будет идти:
cf3 Inputs are valid
По окончании работы в текущем каталоге появятся два файла (txt и html)
с отчетом.
Если ошибок нет, запускаем политику на выполнение. Результат увидим в
консоли, кроме этого, будет создан журнал (в моем случае
/var/cfengine/c3.ubuntu.runlog).
Конечно, это самый простой пример, вполне достаточный, чтобы понять
структуру правил. При наличии большого количества параметров их
объединяют в списки или массивы. Например, список сервисов: Теперь к
нему можно обратиться, указав в правиле $(service).
"service" slist => { "ssh", "apache", "mysql" };
Описание рабочих систем может занимать много места и содержать не один
десяток правил. Часто одни правила зависят от результата выполнения
других, чтобы не возлагать на администратора задачу по их согласованию,
все объявления обрабатываются циклически, до их выполнения. Кроме
этого, если Cfengine изменяет файл, он создает его резервную копию с
префиксом - cf-before-edit.
Нюансов достаточно много, и, как уже говорилось, в поставке Cfengine
имеется несколько десятков готовых шаблонов, которые можно использовать
при изучении.
Настройка сервера
Сервер cf-serverd при запуске по умолчанию считывает файлы site.cf,
promises.cf, update.cf, library.cf, шаблоны которых мы скопировали из
/usr/local/share/doc/cfengine/inputs.
Разберем некоторые настройки из promises.cf. Вначале настраивается
периодичность работы агента:
body agent control
{
# Минимальное время (в минутах) перед проверкой, наличие новых правил
ifelapsed => "15";
# Expireafter - максимальное время ожидания завершения перестроек, по умолчанию 120 минут
}
В правиле body monitor control настраиваются параметры работы системы
мониторинга. Чуть ниже, в body executor control, настраивается запуск
агента. Здесь необходимо указать адрес электронной почты, на который
будут приходить сообщения, и SMTP-сервер:
mailto => "mail@example.org";
smtpserver => "localhost";
По умолчанию сервер принимает подключения только с localhost, чтобы
удаленные клиенты могли подключаться, необходимо отредактировать
правило body server control, указав в Allowconnects и/или
Allowallconnects IP-адреса или доменные имена, соединения с которых
будут приниматься.
body server control
{
Allowconnects => { "127.0.0.1" , "::1", "192.168.17.100" , "192.168.1.0/24" };
Allowallconnects => { "127.0.0.1" , "::1", "192.168.17.100" , "192.168.1.0/24" };
# Слушать только на определенном интерфейсе
bindtointerface => "192.168.17.1";
Trustkeysfrom => { "127.0.0.1" , "::1" ... };
}
Теперь при запуске сервер будет принимать подключения агентов,
прослушивая 5308 порт. Проверяем:
$ cf-serverd -v
$ netstat -an | grep 5308
tcp6 0 0 :::5308 :::* LISTEN
Кстати, если отследить процессы, то мы увидим, что запуск сервера
cf-serverd приведет к автоматическому старту сf-monitor и cf-agent.
Но удаленные клиенты еще не смогут подключаться к серверу. Для
обеспечения безопасности в Cfengine используется механизм защиты и
обмена ключами, подобный OpenSSH. При этом нет необходимости вручную
копировать открытый ключ на сервер (это делается автоматически при
первом подключении), такая децентрализованная структура более устойчива
к сбоям всякого рода.
По умолчанию только ключи локальной системы являются доверенными.
Поэтому при попытке удаленного соединения получим ответ:
Not authorized to trust the server=192.168.17.1's public key (trustkey=false)
Чтобы разрешить прием ключа, необходимо перечислить IP-адреса удаленных
систем в параметре Trustkeysfrom:
Trustkeysfrom => { "127.0.0.1" , "::1", "192.168.17.100" .... };
Дополнительно производится проверка соответствия DNS-имени IP-адресу.
Ее можно отключить, использовав параметр skipverify, что не
рекомендуется с точки зрения безопасности, но для локальных сетей такой
проверкой можно пренебречь.
skipverify => { "192.168.17.*" };
Теперь первый ключ, отправленный клиентом, автоматически принимается,
попытка передать следующий ключ будет заблокирована. Хотя в целях
безопасности, вероятно, все же лучше копировать открытые ключи вручную.
Имя файла открытого ключа необходимо изменить, чтобы оно указывало на
учетную запись и IP-адрес системы, к которой она относится. Например,
user-192.168.17.200.pub.
После того как подключение к серверу организовано, необходимо разрешить
узлам и пользователям доступ к файлам. Это делается при помощи правила
access в файле site.cf. Например, чтобы разрешить пользователю root
доступ ко всем файлам сервера со всех адресов, за исключением
192.168.17.200, создаем такое правило:
bundle server access_rules() {
access:
"/var/cfengine/masterfiles"
deny => { "192.168.17.200" };
admit => { "192.168.17.*" };
roles:
".*"
authorize => { "root" };
}
Теперь, используя masterfiles, мы можем автоматически распространять на
клиентские системы не только политики, но и обновления, и прочие файлы.
Следует учитывать, что по умолчанию привязка идет к /var/cfengine и
доступ к корню сервера невозможен. То есть использовать в предыдущем
правиле ("/") нельзя. Если же такая необходимость все же есть, то
следует пропатчить файл server.c, прописав в 1923 линии код,
разрешающий доступ к корню файловой системы сервера:
/* Exact match means single file to admit */
if (strcmp(ap->path,"/") == 0 )
{
res=true;
}
Следующее правило в promises.cf позволяет указать cf runagent и
cf-agent, где ему искать сервер Distribution point:
body runagent control
{
hosts => {
"127.0.0.1", "example.com:5308", .... };
}
Теперь при подключении агента увидим в консоли сервера примерно такую
запись:
cf3 Host localhost/::ffff:127.0.0.1 was found in the list of hosts to trust
В том случае если не ответит первый по списку сервер, агент будет
подключаться к следующему и так далее.
Для периодического запуска cf-agent вместо cron предлагается
использовать специальный демон cf-execd. В этом случае мы получаем
возможность управлять режимом запуска централизованно, при помощи
политик, и отправлять отчеты на электронный адрес.
Для управления запуском cf-execd создадим файл cf-execd.cf такого
содержания:
body executor control {
# Задержка запуска cf-agent, может потребоваться для завершения копирования файлов политик
splaytime => "1";
mailto => "mail@example.org";
smtpserver => "localhost";
mailmaxlines => "100";
schedule => { "Min00_05" }; # Собственно расписание
# Журналирование в syslog
executorfacility => { "LOG_DAEMON" };
}
# Команда запуска
bundle agent executor {
processes:
"cf-execf"
"cf-execf" restart_class => "start_cfexecd";
commands:
start_cfexecd::
"/usr/local/sbin/cf-execd";
}
Теперь, чтобы файл был "виден", объявим его в promices.cf в секции
inputs:
body common control {
inputs => {
"update.cf",
"site.cf",
"library.cf" ,
"cf-execd.cf" # Добавили
};
}
Вообще можно вместо создания cf-execd.cf все параметры вписать сразу в
promises.cf, но при наличии большого количества записей читаемость от
этого ухудшается. При запуске cf-agent будет загружен и cf-execd,
который периодически будет выполнять cf-agent.
Теперь можно полностью контролировать подчиненные системы,
распространяя изменения, устанавливая обновления, производя мониторинг
и получая отчеты.
На первый взгляд Cfengine кажется сложной и запутанной системой, но на
самом деле это не так. Поэкспериментировав несколько дней, можно
разобраться с его особенностями и возможностями.
1. Яремчук С. Централизованная настройка UNIX-систем с помощью Puppet.
//Системный администратор, No.7, 2007 г. - С. 58-61.
2. Сайт Cfengine и Open Source-сообщества Cfengine -
http://www.cfengine.com, http://www.cfengine.org
3. Wiki Cfengine - http://www.cfwiki.org
4. Cfengine на SourceForge - http://cfengine.sourceforge.net
5. Страница Cfengine в проекте GNU -
http://www.gnu.org/software/cfengine
6. Архив рассылки сообщений об ошибках -
http://www.mail-archive.com/bug-cfengine@cfengine.org/info.html
7. Cfengine reference manual -
http://www.cfengine.org/manuals/cf3-reference.html
Статью можно обсудить на Форуме журнала "Системный администратор" http://www.samag.ru/forum/
