Проект одного человека. Централизованное управление при помощи Cfengine

 СЕРГЕЙ ЯРЕМЧУК, фрилансер. Автор более 800 статей и четырех книг. С «СА» с первого номера. Интересы: сетевые технологии, защита информации, свободные ОС

Проект одного человека
Централизованное управление при помощи Cfengine

Трудно управлять большим количеством систем без средств автоматизации. Этот проект облегчит задачу и позволит централизовано устанавливать параметры

Чтобы вручную произвести изменения в нескольких конфигурационных файлах на серверах, выполняющих разную роль, придется потратить немало времени. Как минимум потребуется проанализировать имеющиеся установки, выбрать системы, на которых будут производиться перестройки, подготовить новые конфигурационные файлы или выбрать другие средства для изменения настроек серверов. И чем больше количество и разнообразнее системы, находящиеся в подчинении администратора, тем более значительных усилий потребует перестройка всей сети, тем больше вероятность сделать ошибку. Использование единой точки, в которой были бы собраны все настройки, позволило бы сократить время на активацию новых установок и снизило вероятность ошибки. В журнале уже обсуждались возможности системы централизованного управления 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 агент связывается с сервером, где получает сведения о конфигурации и применяет изменения, если такие будут обнаружены.

Типичная инфраструктура может состоять из трех компонентов:

• Policy Definition Point – не обязательная, но очень желательная часть системы, построенная на системе контроля версия вроде CVS, позволяющая отслеживать все изменения в настройках;
• Distribution point – один или несколько серверов, которые распространяют файлы политики, описанные в promises.cf и расположенные в каталоге /var/cfengine/masterfiles;
• конечные узлы – на которых применяются политики, скопированные из Distribution point в каталог /var/cfengine/inputs.

После получения политик в конечной точке извлекаются и применяются только те настройки, которые имеют отношение к текущему узлу.

Рисунок 1. Подготавливаем систему к сборке

Установка 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, но, используя дополнительные параметры (их можно узнать при помощи -help), можно указать другое название файла и каталог, но это не всегда желательно. Кроме политик, в inputs должны находиться три обязательных файла:

• promises.cf – основной конфигурационный файл, агент и сервер будут считывать его при запуске;
• update.cf – файл, определяющий настройки обновлений, получаемых агентами;
• failsafe.cf – файл, считываемый сервером и агентом в том случае, когда другие настройки недоступны или неправильны. С его помощью агент может восстановить настройки.

Если таких файлов не будет найдено, получим сообщения вроде:

Кроме этого, возможно использование отдельных файлов для настройки каждого компонента или вспомогательных целей. Имена можно задавать произвольно, но обычно выбирают более описательные: 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:

Такое поведение в целях безопасности вшито в код, изменить его можно только путем перекомпиляции, но вряд ли в этом есть смысл.

Проверяем:

$ whereis 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

Список классов также доступен в файле 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

Смотрим, что внутри:

$ cat 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

В выводе будет видно, как анализируются текущие системные установки, устанавливаются классы и переменные, которые могут быть с ней сопоставлены.

Далее идет проверка каталогов, доступа и так далее. Если все правильно, последней строкой будет идти:

По окончании работы в текущем каталоге появятся два файла (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

Кстати, если отследить процессы, то мы увидим, что запуск сервера cf-serverd приведет к автоматическому старту сf-monitor и cf-agent.

Но удаленные клиенты еще не смогут подключаться к серверу. Для обеспечения безопасности в Cfengine используется механизм защиты и обмена ключами, подобный OpenSSH. При этом нет необходимости вручную копировать открытый ключ на сервер (это делается автоматически при первом подключении), такая децентрализованная структура более устойчива к сбоям всякого рода.

По умолчанию только ключи локальной системы являются доверенными. Поэтому при попытке удаленного соединения получим ответ:

Чтобы разрешить прием ключа, необходимо перечислить 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", ….  };

}

Теперь при подключении агента увидим в консоли сервера примерно такую запись:

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

Для периодического запуска 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. //Системный администратор, №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.

Комментарии могут оставлять только зарегистрированные пользователи