| Каталог документации / Раздел "Операционные системы" / Оглавление документа |
| |
|
Глава посвещена азам работы с Cfengine
Конфигурационный файл cfagent для крупной сети может оказаться длинным и запутанным. Поэтому прежде, чем перейти к деталям, мы попытаемся уйти от сложных вопросов и сосредоточить внимание на самом важном.
Каждая программа или конфигурационный файл cfagent представляет собой список объявлений того, что необходимо проверить и, возможно, настроить. Сначала нужно создать файл `cfagent.conf'. Самый простой, что-то значащий, файл может выглядеть примерно следующим образом:
В приведённом примере проверяется и (при необходимости) создаётся ссылка с`/bin' на `/usr/bin'.# Comment...
control:
actionsequence = ( links )
links:
/bin -> /usr/bin
Рассмотрим этот пример подробнее. В программе cfengine:
В рассмотренном выше простом примере представлены три из описанных типов записей. Секция control: любой программы указывает cfengine на его действия. В данном примере она добавляет в последовательность действий action sequence действие links. Вместо links можно вставить любое другое действие. Самое важное заключается в том, что если в тексте не задана последовательность действий (т.е. action sequence), то cfengine не будет ничего делать. Последовательность действий action sequence задаёт список действий, которые необходимо выполнить cfagent и порядок их выполнения.
Секция links: сообщает cfagent, что далее идёт список ссылок, которые необходимо создать. При создании данной секции необходимо добавить действие links в action sequence, иначе ссылки не создадутся. В данной части можно задавать любое количество ссылок, которые будут созданы в соответствующем порядке, но только если добавить links в action sequence.
В итоге, в файле должны быть:
Теперь проанализируем для чего можно использовать рассмотренный пример. Такая проверка может оказаться полезной в системе SunOS (Solaris), где папка /bin предполагается быть ссылкой. Но в другой системе, где /bin является не ссылкой, а отдельной папкой, cfagent выдаст сообщение об ошибке, говорящее, что /bin существует и не является ссылкой. Отсюда следует вывод, что при желании использовать cfagent для создания одой программы, которая смогла бы работать на всех хостах любого типа, необходимо каким-либо образом ограничить создание данной ссылки, чтобы оно осуществлялось только на системах SunOs. Для этого можно сделать следующее:# Comment...
control: actionsequence = ( links ) links: sun4:: /bin -> /usr/bin # other links osf:: # other links
Имена, оканчивающиеся на двойное двоеточие, называются классами и используются для введения ограничений на выполнение конкретного действия. Таким образом, действие будет совершаться только в том случае, если хост, на котором запускается программа, является членом данного класса. Знакомому с C++, такой синтаксис может напомнить процесс определения классов в C++. Принцип работы классов такой: cfagent сам определяет принадлежность классам sun4, sun3, osf и т.д.. Например, если файл запущен на хосте с операционной системой OSF, то данный хост автоматически становиться членом класса osf. Так как хост не может принадлежать более, чем к одному из определённых видов, то это выделяет его среди различных типов операционных систем и создаёт скрытые команды ifthenelse.
Таким образом в cfagent осуществляется процесс принятия решений. Главная идея состоит в том, что действия совершаются только тогда, когда они описаны в том классе, к которому относиться хост, на котором запущена программа. Подробнее о классах будет рассказано в следующей главе.
Рассмотрим, как добавить новое действие в последовательность action sequence:# Comment...
control: actionsequence = ( tidy links ) links: /bin -> /usr/bin tidy: /tmp pattern=* age=7 recurse=inf
Здесь добавлено новое объявление tidy:, которое удаляет файлы. В данном примере в папке /tmp производиться поиск файлов типа *, которые не открывались более семи дней. Поиск таких фалов распространяется рекурсивно на все подпапки данной директории.
Для того, чтобы запустить данной действие, в последовательность action sequence необходимо добавить слово tidy, в противном случае оно не будет выполняться. Важно, что несмотря на то, что links: были объявлены перед tidy:, порядок в action sequence говорит о том, что выполняться это действие будет после tidy:.
Описанная структура может быть использована для создания файла конфигурации или скрипта.
Для того, чтобы обобщить всё сказанное в предыдущем разделе, приведём образец типичной программы конфигурации cfagent. Различные секции описаны в том порядке, который, вполне вероятно, будет использоваться в action sequence.
Отдельное объявление секции в программе может выглядеть следующим образом:
action-type: class1:: список действий... class2:: список действий...
Тип действия может задаваться одним из зарезервированных слов:
groups, control, copy, homeservers, binservers, mailserver, mountables, import, broadcast, resolve, defaultroute, directories, miscmounts, files, ignore, tidy, required, links, disable, shellcommands, strategie seditfiles, processes
С синтаксической точки зрения, для cfagentне важен порядок, в котором объявлены действия, но некоторые из перечисленных выше действий определяют информацию, к которой в дальнейшем, возможно, потребуется обращение. Все переменные, классы, группы и т.д. должны быть определены до их использования. Таким образом, для секций первой строчки данного списка вполне разумно придерживаться описанного порядка.
Не стоит путать порядок, в котором определяются секции, классы и т.д. с порядком, в котором они исполняются. Этот порядок устанавливается в actionsequence(см.примечания к руководству). Скорее всего, эти порядки будут максимально совпадать.
Для полноты приведём окончательное краткий вариант структуры весьма обобщённой конфигурационной программы cfagent. На формат и использование пространства не действует никаких ограничений, хотя всегда желательно оставлять пустое место до и после скобок при определении переменных.
################################################################## # # Пример структуры # groups:
group1 = ( host host ... ) group2 = ( host host ... ) ...
##################################################################
control:
class::
site = ( mysite ) domain = ( mydomain ) ...
actionsequence = ( action name .... )
mountpattern = ( mountpoint ) homepattern = ( wildcards matching home directories )
addinstallable = ( foo bar ) addclasses = ( foo bar )
##################################################################
homeservers:
class:: home servers binservers: class:: binary servers mailserver: class:: mail server mountables: class:: list of resources
##################################################################
import:
class:: include file class:: include file
##################################################################
broadcast:
class:: ones # or zeros / zeroes
defaultroute:
class:: my-gw
##################################################################
resolve: any:: list of nameservers
Как распространить конфигурацию на несколько хостов, если она определена на одной центральной машине? Простейшее решение - использовать cfengine для распространения конфигурации на разные хосты. Для этого используется отдельный конфигурационный файл. Почему?
Что может случиться, если допустить ошибку (например, синтаксическую) в конфигурации, которая передастся на каждый хост? Тогда ни один из этих хостов не сможет запустить cfengine и, следовательно, загрузить исправленный файл конфигурации. Вся установка будет сорвана. Для того, чтобы избежать такой ситуации, для копирования файлов и двоичного кода на каждый хост используется отдельный файл конфигурации. Такая конфигурация должна быть простой и почти никогда не подвергаться редактированию: главным здесь является надёжность.
Файл update.conf может иметь примерно одну и ту же форму для всех сайтов и выглядеть примерно следующим образом:
####### # # BEGIN update.conf # # Этот скрипт распространяет конфигурацию, простой файл, так что # если в главном config есть синтаксические ошибки, мы по-прежнему можем # распространять правильную конфигурацию, даже если # главный config не будет анализироваться. Он читается и запускается # до анализа главного config. # ####### control:
actionsequence = ( copy tidy ) # Оставьте это постоянным
domain = ( iu.hio.no ) # Необходимо для удалённого копирования
# # Какой из хостов является главным для откачки конфигурации? #
policyhost = ( nexus.iu.hio.no ) master_cfinput = ( /masterfiles/inputs )
# # Некоторые удобные переменные #
workdir = ( /var/cfengine ) cf_install_dir = ( /usr/local/sbin )
# Избежать спор серверов
SplayTime = ( 5 )
################################################################## #` # Убедитесь, что существует локальная копия конфигурации и # самый важного двоичного кода на случай, если соединение отсутствует # например, для мобильных станции или DOS атак # copy: $(master_cfinput) dest=$(workdir)/inputs r=inf mode=700 type=binary exclude=*.lst exclude=*~ exclude=#* server=$(policyhost) $(cf_install_dir)/cfagent dest=$(workdir)/bin/cfagent mode=755 backup=false type=checksum $(cf_install_dir)/cfservd dest=$(workdir)/bin/cfservd mode=755 backup=false type=checksum $(cf_install_dir)/cfexecd dest=$(workdir)/bin/cfexecd mode=755 backup=false type=checksum
##################################################################
tidy: # # В этой директории Cfexecd сохраняет вывод. # Убедитесь, что мы не создавали файлов! # $(workdir)/outputs pattern=* age=7 ####### # # END cf.update # #######
Для организации удалённой рассылки с центрального сервера необходимо запустить cfdervd на хосте, с которого должна копироваться конфигурация. Кроме того, необходимо обеспечить возможность доступа к хостам, на которые предполагается выполнение загрузки. Ниже приведён простой стартовый файл, который выполняет данные действия:
#########################################################
#
# Это файл кончигурации cfservd config file, используемый для серверской
# части cfengine, для удалённой рассылки и управления
# за тем, как cfengine использует программу cfrun.
#
#########################################################
control:
domain = ( iu.hio.no )
cfrunCommand = ( "/var/cfengine/bin/cfagent" )
any::
IfElapsed = ( 1 )
ExpireAfter = ( 15 )
MaxConnections = ( 50 )
MultipleConnections = ( true )
#########################################################
grant:
# Обеспечивает доступ ко всем хостам на example.org.
# Файлы должны быть максимально понятны
/masterfiles/inputs *.example.org
# Убедитесь, что есть разрешение на выполнение cfrun
/var/cfengine/bin/cfagent *.example.org
########
#
# END cfservd.conf
#
########
Куда необходимо помещать файлы? Для организации хранения файлов в зависимости от преследуемой цели можно использовать три различных места:
Хранилище, контролируемое версией, для создания, проверки и внесения изменений в файлы. Как только версия одобрена для выпуска, главные файлы должны быть перенесены в область публикации, то есть в `/usr/local/masterfiles/cfengine/inputs' на `masterhost'.
Централизованное расположение, в котором осуществляется публикация изменённых и протестированных конфигураций. Это буферное хранилище, из которого каждый клиент будет загружать новые и проверенные версии главной конфигурации, например `/usr/local/masterfiles/cfengine/inputs' на masterhost'. Данное расположение служит как буфер для хранения между тестируемыми и готовыми файлами.
Рабочая папка. Здесь хранятся готовые файлы. Как правило, это частная папка, где cfagent предполагает найти свои файлы конфигурации, `/var/cfengine/inputs'. Задача update.conf состоит в копировании в данную папку из главного хранилища.
Модули и методы, как правило, хранятся в отдельной от входных файлов папке, поскольку им требуется директория с особыми правами доступа для выполнения. Такой способ организации весьма полезен. Поскольку update.conf помещает главные версии в нужную папку (обычно /var/cfengine/modules/) на локальном зосте, то всё будет выполнено правильно.
Не стоит пытаться копировать файлы непосредственно из папки контроля версий, так как это может привести к рассылке недоработанных или тестируемых файлов на все хосты.
# Пример update.conf
control:
master_cfinput = ( /usr/local/masterfiles/cfengine/inputs )
workdir = ( /var/cfengine )
copy:
# Копирование из bullet 2 в bullet 3
$(master_cfinput) dest=$(workdir)/inputs
r=inf
mode=700
type=binary
exclude=*.lst
exclude=*~
exclude=#*
server=$(policyhost)
trustkey=true
$(master_modules) dest=$(workdir)/modules
r=inf
mode=700
type=binary
exclude=*.lst
exclude=*~
exclude=#*
server=$(policyhost)
trustkey=true
Cfagent выполняет операции только по запросу. Во время работы он выводит какие-либо сообщения только в случае обнаружения ошибки. Он выполняет действия, только определённые в последовательности действия action sequence.
Однако, при желании cfagent можно настроить на режим диалога. Его можно запускать с рядом параметров командной строки (см. приложение к руководству). При запуске программы с параметрами -v или --verbose cfagent будет выводить сообщения о выполняемых им действиях. Режим диалога также поддерживает вывод определённых предупреждений о возникающих проблемах, поэтому он является удобным механизмом для выявления и устранения ошибок.
При желании cfagent может осуществлять проверку различных параметров, например, временной зоны или имени домена. Для проверки подобных вещей, он должен получить некоторую информацию от пользователя. Все параметры и переключатели, вносящие изменения в ход работы cfagent, определяются либо в командной строке, либо в секции control: контрольного файла. Для этого используются некоторые специальные управляющие переменные. Приведём короткий пример:
control:
domain = ( example.org ) netmask = ( 255.255.255.0 ) timezone = ( MET CET )
mountpattern = ( /mydomain/mountpoint )
actionsequence = ( checktimezone # check time zone netconfig # includes check netmask resolve # includes domain mountinfo # look for mounted disks under mountpattern )
Для того, чтобы включить режим диалога, необходимо запустить cfagent с соответствующей опцией командной строки --verbose или -v.
Следует обратить внимание на то, что установка значений имеет свой синтаксис: имя переменной, знак равенства, значение, записанное в скобках. Таким образом выражению, стоящему слева от знака равенства, присваивается значение, стоящее справа. На этом этапе может возникнуть ряд вопросов, которые будут рассматриваться в процессе и в последующих главах.
Прежде чем завершить краткий обзор управляющих параметров, стоит дать определить mountpatter, описанный выше. Он определяет директорию, в которой cfagent предполагает найти установочные диски(mounted disk). Подробнее об этом будет рассказано в дальнейшем, но пока стоит отметить, что такое определение может показаться весьма непродуманным и неудобным. Гораздо лучше было бы использовать переменные для задания пути к mounted filesystems. Естественно, такая возможность существует.
Кратко проанализировав возможности cfagent, перейдём к рассмотрению примеров и посмотрим, как может выглядеть окончательная программа (см. приложение к руководству). Если на данном этапе у Вас не возникло никаких вопросов, то Вы можете бегло просмотреть остальные части данного руководства и сосредоточить внимание только на непонятных моментах. Следующие главы рассматривают некоторые вопросы более детально.
Запуск cfagent может осуществляться несколькими способами. Приведём несколько примеров:
host% cfagent host% cfagent --file myfile host% cfagent -f myfile -v -n host% cfagent --help
В первом примере (команда по умолчанию, без аргументов) cfagent начинает искать файл cfagent.conf в папке, на которую указывают переменные среды CFINPUTS или /var/cfengine/inputs по умолчанию, и затем извлекает его, не выдавая никаких сообщений. Вторая команда производит чтение файла myfile, также не выдавая никаких сообщений. Третья работает в режиме диалога, а параметр -n устанавливает запрет на выполнение каких-либо действий за исключением вывода сообщений об ошибках. В последнем примере, cfagent выведет список своих параметров командной строки.
Полный список параметров приведён в кратком обзоре в начале руководства и также доступен при указании параметра -h (см.приложение к руководству).
Помимо запуска cfagent с помощью имени файла, его файлы также могут интерпретироваться в качестве скриптов, если запустить его со стандартной shell line (скрытой строкой):
#!/usr/local/sbin/cfagent -f # # My config script #
Здесь предполагается, что cfengine установлен в директории `/usr/local/sbin'. Добавление подобного заголовка в первую строку программы и запуск файла с помощью chmod shell command, позволит осуществлять запуск программы по имени, то есть не упоминая никоим образом cfagent.
Если вы впервые работаете с cfengine, то мы советуем проверить все программы с параметром -n перед тем, как полагаться на Вашу систему, по крайней мере, пока вы не познакомитесь с работой cfengine. Использование данного параметра позволит видеть, что cfengine собирается делать, не принимая в данном процессе никакого участия.
После успешной работы с cfengine, возможно потребуется запускать его в системе по меньшей мере один раз в течении часа. Этого можно легко добиться, если вставить следующую строку в корневой файл crontab каждой системы:
0,30 * * * * /usr/local/sbin/cfexecd -F
Этого достаточно, чтобы гарантировать запуск cfengine. Все получаемые в ходе этого процесса результаты будут храниться в `/var/cfengine/outputs'. Кроме того, вставка в файл cfagent.conf следующей строки позволит системному администратору получать e-mail сообщения о получаемых результатах:
control: smtpserver = ( mailhub.example.org ) # site MTA which can talk smtp sysadm = ( mark@example.org ) # mail address of sysadm
Данным переменным необходимо присвоить соответствующие значения. Ещё один, дополнительный, способ запуска cfengine запустить программу cfexecd с демонами (без -F) (daemon mode option). В таком режиме демон будет находиться в пассивном состоянии и активизироваться только согласно расписанию. Расписание по умолчанию - осуществлять запуск один раз в час (что соответствует Min00_05). Следующие модификации в cfagent.conf позволят демону будет запускать cfagent каждые пол часа:
control: # Когда cfexecd в режиме демона должен запустить cfagent? schedule = ( Min00_05 Min30_35 )
Стоит обратить внимание, что задание времени относится к базовым временным классам cfengine (см. раздел 5.3, [Создание гибких временных классов], стр 60). Несмотря на то, что одного из этих методов достаточно, параллельное использование cron и cfexecd не приведёт к возникновению проблем. Блокирующие механизмы cfagent исключают возможность возникновения конфликтов.
Остальные компоненты cfengine могут запускаться непосредственно cfagent:
processes:
"cfenvd" restart "/usr/local/sbin/cfenvd" "cfservd" restart "/usr/local/sbin/cfservd"
Обратите внимание, что для запуска cfexecd с помощью cfengine необходимо сделать следующее:
processes: "bin/cfexecd$" restart "/usr/local/sbin/cfexecd"
Важно по возможности использовать в совпадающих утверждениях регулярное выражение в качестве специального (в данном примере путь к программе и регулярное выражение metacharacter $, обозначающее конец строки), поскольку пустые строки зачастую могут соответствовать совершенно неожиданным процессам. Например, использование cfexecd самого по себе будет также соответствовать процессу, вызываемому cfagent F, который обнаружиться как /var/cfagent/bin/cfagent Dfrom_cfexecd в таблице процессов
Каждый раз при поиске файлов cfengine выясняет, является ли имя файла абсолютным (то есть начинающимся с /, например, /usr/file), лежит ли этот файл в той же директории, где запускается cfengine, или его необходимо искать в другом месте.
При использовании абсолютного имени файла (то есть, начинающееся с /), как в командной строке с помощью f, так и в секции import программы, cfengine доверяет ему и воспринимает буквально. Если же имя файла определено просто как . или -, то cfengine читает его входные данные из стандартного ввода.
Если запустить cfengine без указания аргументов (то есть имя файла по умолчанию cfagent.conf) или определить файл, не написав / вначале в секции import, то значение переменной среды CFINPUTS приписывается в начало имени файла. Это позволяет хранить конфигурацию в стандартном месте, на которое указывает CFINPUTS. Например,
host# setenv CFINPUTS /usr/local/masterfiles/cfengine/inputs host# cfagent -f myfile
В данном примере, cfengine будет пытаться открыть файл myfile в директории `/usr/local/masterfiles/cfengine/inputs. Если для CFINPUTS не установлено никакого значения, то местом по умолчанию считается доверенная директория cfengine `/var/cfengine/inputs'.
Начинающему работать с cfengine может быть не до конца понятно, как его можно использовать. Ниже приведены несколько подсказок от доктора Дэйстрома о том, как можно быстро производить необходимые операции.
Запускайте cfengine из cron на всех системах каждый час. Убедитесь, что определены все длинные задания или задания, которые не нужно выполнять. Чаще всего это делается с помощью time class, который предотвращает постоянное выполнение заданий (см. главу 5 [Использование cfengine в качестве front-end для cron], стр. 59).
Запуск cfengine из cron значит, что он может работать параллельно в нескольких системах. Для того, чтобы cfengine начал работу на одном хосте, он не должен ждать окончания работы cfengine на другом.
Установите cfservd на всех системах для возможности удалённого запуска cfengine. Это предоставляет возможность быстрого внесения изменений на все системы с помощью cfrun. Необходимо тщательно продумать, кому стоит предоставлять права на запуск cfengine из сети (см. раздел 6.3. [Конфигурация cfservd], стр. 68). Установите cfservd.conf соответствующим образом. Этот демон также может быть использован для предоставления прав на удалённое копирование файлов.
Cfrun периодически анализирует все хосты и выдаёт объединённый пронумерованный список проблем по всем хостам. Недостаток cfrun заключается в том, что каждый хост должен ждать своей очереди.
Не забудьте добавить cfservd в сценарий запуска системы или в inittab, чтобы он запускался при начальной загрузке системы.
Добавьте все хосты в файл cfrun.hosts, вне зависимости от того, являются они главными серверами или другими клиентами. Блокирующий механизм предотвратит возникновение глупых ошибок (см. раздел 6.2.5 [Тупики и неконтролируемые петли], стр. 67). Cfengine сможет решить их. Cfrun позволит осуществлять удалённый запуск cfengine на тех группах хостов, которые удовлетворяют списку классов cfengine.
После установки всех компонентов вся дальнейшая работа сведётся к простому редактированию файлов конфигурации и просмотру результатов.
|
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |