Внедрение Asterisk - современное решение для создания IP телефонии на предприятии. Что значит IP телефония и почему современные предприятия не могут обойтись без нее?

IP телефония - это вид коммуникации, осуществляемой через всемирную сеть Интернет. Все вместе представляет систему программных и аппаратных средств, поддерживающих протокол IP. Говоря более простым языком, этот вид связи обеспечивает передачу данных (звук, изображение) по Интернету. Услуги IP-телефонии позволяют объединить в единую сеть все каналы посредством общей АТС, получать объективную оценку аналитики, маршрутизацию звонков. Связь через сеть лимитируется поставщиком услуг и стоит в разы дешевле.

В чем еще преимущество связи? Безопасность! Протоколы защищены, разговор по защищенной IP-линии невозможно прослушать.

Что значит Asterisk

Asterisk - готовая система для организации IP телефонии, которая полностью обеспечивает функции привычной АТС:

• Прием входящих звонков.
• Распределение вызовов по внутренним номерам.
• Автоответчик и IVR меню.
• Прием факсов.
• Запись, прослушивание звонков.
• Создание конференций и другое.

АТС Asterisk обладает расширенными возможностями, рассчитана на большее количество абонентов и проще в обслуживании.

Астерикс с легкостью примет и перешлет, а также сделает исходящий голосовой вызов. Передача данных проходит через VOIP - устройства для передачи данных между сетью интернет и другими видами связи (мобильная, стационарная).

Почему Asterisk так популярен

Существуют и другие компании, занимающиеся решениями IP телефонии. Но Asterisk вышел на рынок связи с принципиально новым решением - исходный код, разработанный компанией Digium, был открыт. А это означает бесплатное пользование программным продуктом.

Марк Спенсер, разработчик кода, предложил пользователям систем Линукс, FreeBSD, OpenBSD и другим пользоваться продуктом свободно. Сеть Интернет столь велика, что каждому найдется место, и когда появляется бесплатная возможность - предпочтение отдается ему.

Чтобы запустить работу IP-телефонии, достаточно обладать только программой. Это комплекс, в который входит соответствующий программный продукт, а специальное дополнительное оборудование не нужно. Установка занимает время и требует работу специалиста.

Внедрение Asterisk на предприятии

Внедрение Asterisk - состоит из нескольких этапов:

1. Формируются технические требования к телефонии
2. Подбирается мощность и конфигурация сервера, на котором будут установлены база данных и серверная часть программного обеспечения. Расчет идет из предполагаемой нагрузки. Настройка и конфигурирование сервера проводится специалистами компании.
3. Приобретение внешних телефонных линий (SIP номеров).
4. Настройка системы:

• Внутренние номера.
• Для связи с мобильными операторами устанавливается и настраивается шлюз GSM/VoIP. Это оборудование и программное обеспечение для состыковки IP-телефонии с мобильной и стационарной связью
• Специалист настраивает запись звонков. Функция необходима для ведения записи всех переговоров с возможностью их воспроизведения. Для этого создается хранилище на сервере, где будет храниться база аудио-записей.
• Настройка сценариев «Нет на месте», «Все операторы заняты», «Не рабочее время». Определяется индивидуально по заказу клиента
• Настройка функций, определяемых программой и осуществляющих работу виртуальной АТС - конференции, вызов из скайпа, очередность, прослушивание звонков, принятие и отправка факсов, настройка «черного списка» и многое другое.

Провести такой объем работ могут только квалифицированные специалисты. Наша компания обеспечивает и предлагает полный сервис - установку и конфигурирование систем Asterisk на предприятиях заказчика - на выгодных условиях, с гарантией сервиса.

Зачем это нужно

Давайте рассмотрим вариант небольшого предприятия, принимающего в день определенное количество звонков, в том числе и международных. Очевидно, что если существуют входящие, то появляется необходимость и в исходящих. Рабочий день компании состоит из переговоров: работает техподдержка удаленного доступа, консультации, решение других рабочих вопросов. При обыкновенных решениях связи, затраты на коммуникацию составляют львиную долю бюджета. Имея такой ресурс, как IP-телефония и виртуальная АТС в разовые траты входит:

• Покупка оборудования - сервер, маршрутизатор, шлюзы GSM/VoIP, телефонные аппараты для IP-связи.
• Оплата разового конфигурирования и настройки специалистами компании-поставщика.

Как показывает опыт, первоначальные затраты полностью окупаются во время эксплуатации. Заказчик получает безопасную связь, которая не прослушивается и соединяет абонентов по всему миру. Руководитель, находясь за границей, не потратится на роуминг, но будет в курсе всех событий - с помощью своего мобильного телефона он может связаться с сотрудниками предприятия, где установлен Asterisk, и быть в курсе всех событий.

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

Сроки и выполнение зависят от конфигурации серверов и сложности настроек. Результат работы - полноценная и многофункциональная связь со всеми отделениями, клиентами и сотрудниками. Новый уровень связи выводит бизнес на высокий уровень отношений внутри коллектива и с клиентами.

Виды работ по настройке телефонии производимые нашими специалистами

• Установка и настройка сервера, Установка серверного ПО для управления IP телефонией.
• Настройка внутреннего номера
• Настройка записи звонков
• Регистрация SIP линии
• Настройка GSM шлюза
• Настройка VoIP шлюза
• Настройка IVR меню
• Сценарий «Нет на месте»
• Сценарий «Все операторы заняты»
• Сценарий «Не рабочее время»
• Очередь звонков
• Настройка конференции
• Звонки на SKYPE
• Парковка звонка
• Прослушивание разговоров
• Вторжение в разговор
• Голосовая почта с отправкой на почту
• Удалённый доступ с обратным вызовом callback
• Отправка факса
• Чёрный список

Термины IP телефонии

VOIP Шлюз - Оборудование, предназначенное для перевода аналогового телефонного сигнала в цифровой сигнал. (VoIP)
GSM Шлюз - Оборудование предназначенное для подключения SIM карт мобильных операторов к аналоговой линни.
GSM-VoIP шлюз - Оборудование предназначенное для подключения SIM карт мобильных операторов к IP линии.
IP линия - Это линия между сервером и клиентом, по которой сигнал передается по протоколу SIP.
Внутренний номер - Внутренний номер сотрудника на который он будет принимать звонки

Администрирование виртуальных серверов с использованием Puppet

Часть 1. Установка и настройка Puppet

Серия контента:

В процессе организации серверной среды с использованием средств виртуализации или облачных сервисов быстро растет количество отдельных серверов. Каждый раз при создании нового сервера возникает необходимость установки и конфигурации соответствующего программного обеспечения. Более того, синхронизация серверных конфигураций требует дополнительных усилий, таких, например, как написание cценариев на языке командной оболочки shell .

С помощью программного средства Puppet можно быстро создать новый сервер и настроить его параметры буквально в несколько команд без каких-либо затруднений. Кроме того, Puppet будет периодически синхронизировать конфигурации созданных серверов.

Несмотря на то, что эта программа обычно используется для управления крупными серверными структурами (например, в дата-центрах или на Web-сервисах с большим количеством пользователей), её вполне можно применить и для обслуживания нескольких серверов (скажем, в локальной сети небольшого офиса или в домашней сети).

История Puppet

Проект Puppet является разработкой компании Puppet Labs и распространяется как ПО с открытым исходным кодом (Open Source Software). Программа имеет гибкую модульную структуру: в настоящее время для Puppet написано уже более 200 модулей расширения.

Puppet поддерживается не только компанией-разработчиком, но и весьма активным сообществом пользователей .

Установка и подготовка Puppet к работе

Функционирование Puppet организовано по схеме "клиент-сервер". Каждый клиент периодически устанавливает связь с главным управляющим сервером (или несколькими такими серверами) и выполняет синхронизацию конфигурации. По умолчанию такие сеансы связи происходят каждые полчаса. Поэтому для обеспечения нормальной работы Puppet потребуются как минимум два установленных сервера: один будет выполнять функции главного управляющего сервера (master server), а другой (или другие) выступать в роли подчинённых ему серверов, то есть, в данном контексте можно назвать их серверами-"клиентами".

Для того, чтобы установить Puppet на хосте, который будет управлять другими серверами в качестве главного управляющего сервера, необходимо выполнить команды, показанные в листинге 1. Следует отметить, что эти команды выполняются от имени суперпользователя root .

Листинг 1. Установка пакета puppet-server на главный управляющий сервер

# yum -y install puppet-server # chkconfig puppetmaster on # service puppetmaster start

Пакеты для подчинённых серверов устанавливаются на клиентских хостах, как показано в листинге 2 (команды выполняются также от имени суперпользователя root ).

Листинг 2. Установка пакета puppet на хосте-клиенте

# yum -y install puppet # chkconfig puppet on # service puppet start

Если хост главного управляющего сервера защищён сетевым экраном, а хосты-клиенты расположены "снаружи" относительно этого сетевого экрана (например, компьютеры в локальной сети), то на главном сервере необходимо открыть TCP-порт с номером 8140 и, по возможности, сделать его доступным только для клиентских хостов. Если все операции будут выполняться на одном компьютере (localhost), то никаких манипуляций с сетевым экраном не требуется.

Основы использования Puppet

С точки зрения Puppet все конфигурации определяются и описываются как ресурсы (resources ), которые можно назвать основными структурными компонентами управляющей среды. Ресурсами могут быть файлы, сервисы (server services), программные пакеты (software packages) и т.д. Более того, ресурсом может быть даже одиночный вызов команды оболочки shell. Например, описываемый в листинге 3 ресурс типа file представляет известный всем файл /etc/passwd, владельцем которого является root .

Листинг 3. Описание ресурса - файла /etc/passwd

file { "/etc/passwd": owner => root, mode => 644, }

Ресурсы можно группировать по определённым характеристикам: так, например, любой файл имеет владельца и расположен по конкретному адресу (path) в файловой системе, у каждого пользователя есть регистрационное имя (login), личный идентификатор (UID) и идентификатор группы (GID). В соответствии с этими характеристиками формируются типы ресурсов. Кроме того, самые важные характеристики типа ресурса в общем смысле одинаковы для любых операционных систем, независимо от незначительных деталей реализации. То есть описание ресурса вполне можно абстрагировать от его реализации в той или иной операционной системе.

На основе вышеописанных предпосылок сформирован уровень абстракции ресурсов (resource abstraction layer - RAL ) программы Puppet. RAL разделяет ресурсы на типы (types ), являющиеся моделями высокого уровня, и провайдеры (providers ), которые представляют более низкий уровень, то есть реализации ресурсов, зависящие от конкретной платформы. Такая организация RAL позволяет составлять описания ресурсов способом, применимым практически на любой системе.

Цикл синхронизации RAL

Puppet использует RAL как для чтения, так и для изменения состояния ресурсов системы. Являясь декларативной системой контроля и управления, Puppet начинает рабочий цикл с получения информации о том, в каком состоянии должен находиться тот или иной ресурс. При синхронизации ресурса используется RAL для запроса текущего состояния, сравнения его с требуемым и внесения всех необходимых изменений при обнаружении каких-либо различий.

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

Как было сказано выше, в Puppet каждый ресурс является экземпляром некоторого типа (resource type ), с указания которого начинается собственно описание. Ресурс идентифицируется именем (title ), которое записывается в одиночных кавычках после открывающей фигурной скобки и сопровождается символом двоеточия. Далее с новой строки определяются атрибуты типа (attributes ), причём некоторые атрибуты являются общими для всех типов, другие же присущи только данному конкретному типу ресурса. Каждый атрибут имеет значение (value ), таким образом, записи атрибутов с соответствующими значениями имеют общую форму attribute => value .

Общее представление о синтаксисе языка описания ресурсов Puppet можно получить из листинга 4, в котором показан самый простой случай - описание ресурса типа "пользователь" (user ).

Листинг 4. Синтаксис языка описания ресурсов Puppet на примере пользователя

user { "alex": ensure => present, uid => "501", gid => "admin", shell => "/bin/bash", home => "/home/alex", managehome => true, }

Каждая строка определения атрибута заканчивается запятой, а закрывающая фигурная скобка сообщает о том, что описание ресурса завершено.

Следующая конфигурация, демонстрируемая в листинге 5, позволяет установить пакет openssh-server , разрешить использование сервиса sshd по умолчанию и выполнить проверку, чтобы убедиться в том, что этот сервис действительно активизирован и работает.

Листинг 5. Описание ресурса - сервиса sshd (установка, запуск, проверка)

package { "openssh-server": ensure => installed, } service { "sshd": enable => true, ensure => running, require => Package["openssh-server"], }

Теперь необходимо применить описанные выше конфигурации к соответствующим серверам. В пакет Puppet по умолчанию включён специальный файл конфигурирования ресурсов site.pp , который располагается в каталоге /etc/puppet/manifests . Если параметры конфигурации ресурсов не очень сложны, то их можно добавить в этот файл вручную: например, содержимое вышеприведённых листингов 3 и 4.

После того, как все требуемые программы установлены и активированы, а файлы конфигурации сформированы, обязательно нужно зарегистрировать все подчинённые серверы (клиенты) на главном управляющем сервере и подтвердить достоверность регистрации (sign ), то есть пройти своеобразную сертификацию. На подчинённых серверах регистрация выполняется следующей командой (также требуются права суперпользователя root ):

puppetd --test --waitforcert 30 --server MASTER_SERVER_ADDRESS

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

После регистрации всех необходимых клиентов на главном управляющем сервере выполняются команды, показанные в листинге 6.

Листинг 6. Сертификация зарегистрированных клиентов на главном управляющем сервере

puppetca --list # выводится список адресов зарегистрированных клиентов puppetca --sign CLIENT_SERVER_ADDRESS # вместо CLIENT_SERVER_ADDRESS следует указать реальный адрес клиента # команда повторяется для адреса каждого клиента

После завершения операций регистрации и сертификации Puppet автоматически применит описанные выше конфигурации ресурсов на зарегистрированных клиентах.

# здесь также записывается реальный адрес сервера server = MASTER_SERVER_ADDRESS

Теперь Puppet полностью настроен и работает. Автоматическая синхронизация конфигураций ресурсов подчинённых серверов будет производиться каждые 30 минут. Пронаблюдать процесс можно выполнив команду:

tail -f /var/log/messages

Заключение

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

Статья написана в журнале Системный администратор

World Revolution

Управление множеством Unix систем нельзя называть комфортабельным. Для конфигурации 1-го параметра администратору приходится обращаться к каждой машине, скрипты только частично могут помочь, ну и не во всех ситуациях.

Следует признать, что администраторы Windows сетей находятся все-таки в более успешном положении. Достаточно поменять функции групповых политик и через некоторое время все компютеры сети, в том числе и с не так издавна установленной операционной системой “выяснят” о нововведении, если они их естественно касаются.

Оглянувшись на длиннющий период развития Unix, можно узреть, что ничего подобного так и не прижилось. Есть решения вроде kickstart, которые помогают при первичной установке операционной системы, но грядущая доводка потребует важных усилий.

Коммерческие решения вроде BladeLogic и OpsWare , делему автоматизации опций решают только отчасти, основное их достоинство наличие графического интерфейса, ну и позволить их приобрести могут только в огромных организациях. Есть естественно и проекты предлагающие свободные решения, но за всегда собственного существования они так и не смогли сделать большого общества.

Например Cfengine не очень пользуется популярностью у администраторов, хотя не считая Linux, может употребляться в *BSD, Windows и Mac OS X. Может быть это связано с относительной сложностью в разработке конфигураций. При описании заданий приходится учитывать особенности каждой определенной системы, и вручную контролировать последовательность действий при выполнении команд.

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

Не смотря на GPL лицензию Cfengine фактически проект 1-го человека, который контролирует все конфигурации и не очень заинтересован в построении открытого общества. В конечном итоге возможности cfengine вполне удовлетворяют разработчика, а для других администраторов это резвее лишняя боль в голове.

Чтобы улучшить cfengine сторонними разработчиками были изготовлены различные дополнения, что часто только ухудшало ситуацию. Создатель нескольких таких модулей к cfengine Люке Каниес (Luke Kanies) в итоге решил сделать похожий инструмент, но лишенный многих недостатков cfengine.

Возможности Puppet

Puppet как и cfengine является клиент-серверной системой использующей декларативный, другими словами неотклонимый для выполнения язык для описания задач и библиотеки для их реализации. Клиенты периодически (по умолчанию 30 минут) соединяются с центральным сервером и получают последнюю конфигурацию.

Если обретенные функции не совпадают с системным состоянием, они будут выполнены, при необходимости серверу отсылается отчет о изготовленных операциях. Сервер сообщения может сохранить в syslog или файл, сделать RRD график, отослать на обозначенный e-mail.

Дополнительные уровни абстракции Transactional и Resource обепечивают наивысшую сопоставимость с существующими опциями и приложениями, позволяя сфокусироваться на системных объектах, не заботясь о различиях в реализации и описании подробных команд и форматах файлов. Администратор оперирует только с типом объекта, остальное Puppet берет на себя. Так тип packages знает о Семнадцать пакетных системах, подходящая автоматом будет распознана на основании инфы о версии дистрибутива или системы, хотя при необходимости пакетный менеджер можно задать принудительно.

В отличие от скриптов, которые часто не может быть использовать в других системах, конфигурации Puppet написанные сторонними администраторами будут в большинстве без заморочек работать в хоть какой другой сети. В Puppet CookBook уже имеется три 10-ка готовых рецептов. В настоящее время Puppet официально поддерживает следующие операционные системы и сервисы: Debian, RedHat/Fedora, Solaris, SUSE, CentOS, Mac OS X, OpenBSD, Gentoo и MySQL, LDAP.

Язык Puppet

Чтобы идти дальше, поначалу следует разобраться с основными элементами и возможностями языка. Язык это одна из сильных сторон Puppet. С его помощью описываются ресурсы которыми администратор планирует управлять и деяния.

В отличие от большинства похожих решений, в Puppet язык позволяет упростить обращение ко всем схожим ресурсам на хоть какой системе в гетерогенной среде. Описание ресурса, обычно, состоит из наименования, типа и атрибутов. Например укажем на файл /etc/passwd и установим его атрибуты:

file { «/etc/passwd»:

owner => root,

group => root,

На данный момент клиенты, подключившись к серверу скопируют файл /etc/passwd и установят обозначенные аттрибуты. В одном правиле можно определять слету несколько ресурсов, разделяя их с помощью точки с запятой.

А что делать если конфигурационный файл используемый на сервере отличается от клиентских или вообще не употребляется? Например такая ситуация может показаться при настройках VPN соединений. В этом случае следует на файл можно указать директивой source.

Здесь два варианта, как обычно указать путь к другому файлу, также поддерживается два URI протокола: file и puppet. В первом случае употребляется ссылка на внешний NFS сервер, во втором варианте на сервере Puppet, запускается NFS похожий сервис, который и экспортирует ресурсы.

В последнем случае по умолчанию путь указывается относительно корневого каталога puppet - /etc/puppet. Другими словами ссылка puppet://server.domain.com/config/sshd_config будет соответствовать файлу /etc/puppet/config/sshd_config.

Переопределить этот каталог, можно с помощью директивы filebucket, хотя более правильно использовать одноименную секцию в файле /etc/puppet/fileserver.conf. В этом случае можно ограничить доступ к сервису только с определенных адресов. Например опишем секцию config.

path /var/puppet/config

allow *.domain.com

allow 192.168.0.*

allow 192.168.1.0/24

deny *.wireless.domain.com

А позже обращаемся к этой секции при описании ресурса.

source => «puppet://server.domain.com/config/sshd_config»

Перед двоеточием располагается название ресурса. В самых обыденных случаях в качестве имени можно просто указатьлучше использовать псевдоним или переменные. Псевдоним устанавливается с помощью директивы alias. полный путь к файлу. В более сложных конфигурациях

file { «/etc/passwd»:

alias => passwd

Другой вариант сотворения псевдонима, прекрасно подходит в данном случае, когда приходится иметь дело с разными операционными системами. Например, создадим ресурс описывающий файл sshd_config:

file { sshdconfig:

name => $operatingsystem ? {

solaris => «/usr/local/etc/ssh/sshd_config»,

default => «/etc/ssh/sshd_config»

В этом примере мы столкнулись с возможностью выбора. Раздельно указан файл для Solaris, для всех других будет избран файл /etc/ssh/sshd_config. На данный момент к этому ресурсу можно обращаться как к sshdconfig, зависимо от операционной системы будет избран подходящий путь.

Например укажем, что в случае если бес sshd запущен и получен новый файл, следует перезапустить сервис.

ensure => true,

subscribe => File

Переменные часто используются при работе с пользовательскими данными. Например описываем месторасположение домашнних каталогов юзеров:

$homeroot = «/home»

На данный момент к файлам определенного пользователя можно обратиться как

${homeroot}/$name

В параметр $name будет подставлено учетное имя пользователя. В некоторых случаях комфортабельно отыскать значение по умолчанию для некоторого типа. Например для типа exec очень часто указывают сборники в каких он должен отыскивать исполняемый файл:

Exec { path => «/usr/bin:/bin:/usr/sbin:/sbin» }

В том случе если нужно указать на несколько вложенных файлов и каталогов, можно использовать параметр recurse.

file { «/etc/apache2/conf.d»:

source => «puppet:// puppet://server.domain.com/config/apache/conf.d»,

recurse => «true»

Несколько ресурсов могут быть объеденены в классы или определения. Классы являются законченным описанием системы или сервиса и употребляются обособленно.

«/etc/passwd»: owner => root, group => root, mode => 644;

«/etc/shadow»: owner => root, group => root, mode => 440

Как и в объектно-ориентированных языках классы могут переопределяться. Например в FreeBSD группой-владельцем этих файлов является wheel. Поэтому чтобы не переписывать ресурс полностью, создадим новый класс freebsd, который будет наследовать класс linux:

class freebsd inherits linux {

File["/etc/passwd"] { group => wheel };

File["/etc/shadow"] { group => wheel }

Для удобства все классы можно вынести в отдельный файл, который подключать директивой include. Определения могут принимать многочисленные свойства в качестве аргументов, но не поддерживают наследования и употребляются в данном случае если нужно описать не один раз используемые объекты. Например определим домашний каталог юзеров и команды нужные для сотворения новой учетной записи.

define user_homedir ($group, $fullname, $ingroups) {

user { «$name»:

ensure => present,

comment => «$fullname»,

gid => «$group»,

groups => $ingroups,

membership => minimum,

shell => «/bin/bash»,

home => «/home/$name»,

require => Group[$group],

exec { «$name homedir»:

command => «/bin/cp -R /etc/skel /home/$name; /bin/chown -R $name:$group /home/$name»,

Сергей Яремчук

Централизованная настройка UNIX-систем с помощью Puppet

Управление большим количеством UNIX-систем нельзя назвать удобным. Для изменения одного параметра администратору приходится обращаться к каждой машине, скрипты лишь частично могут помочь, да и не во всех ситуациях.

Следует признать, что администраторы Windows-сетей находятся все-таки в более выгодном положении. Достаточно изменить настройки групповых политик, и через некоторое время все компьютеры сети, в том числе и с недавно установленной операционной системой, «узнают» о нововведении, если они их, конечно, касаются. Оглянувшись на долгий период развития UNIX, можно заметить, что ничего подобного так и не прижилось. Есть решения вроде kickstart, которые помогают при первичной установке операционной системы, но дальнейшая доводка потребует значительных усилий. Коммерческие решения, вроде BladeLogic и OpsWare , проблему автоматизации настроек решают лишь отчасти, основное их достоинство – наличие графического интерфейса, да и позволить их приобрести могут только крупные организации. Есть, конечно, и проекты, предлагающие свободные решения, но за все время своего существования они так и не смогли создать большого сообщества. Например, Cfengine не очень пользуется популярностью уадминистраторов, хотя, кроме Linux, может использоваться в *BSD, Windows и Mac OS X. Возможно, это связано с относительной сложностью в создании конфигураций. Приописании заданий приходится учитывать особенности каждой конкретной системы и вручную контролировать последовательность действий при выполнении команд. То есть администратор должен помнить, что для одних систем следует писать adduser для других – useradd, учитывать расположение файлов в разных системах и так далее. Это на порядок усложняет процесс написания команд, с ходу создать правильную конфигурацию очень сложно, а созданные конфигурации прочитать через некоторое время практически нереально. Несмотря на GPL-лицензию Cfengine, фактически проект одного человека, который контролирует все изменения и не очень заинтересован в построении открытого общества. В результате возможности Cfengine вполне удовлетворяют разработчика, а для остальных администраторов это скорее лишняя головная боль. Чтобы улучшить Cfengine, сторонними разработчиками были созданы различные дополнения, что часто только ухудшало ситуацию. Автор нескольких таких модулей к Cfengine Люке Каниес (Luke Kanies) витоге решил разработать подобный инструмент, но лишенный многих недостатков Cfengine.

Возможности Puppet

Puppet , как и Cfengine, является клиент-серверной системой, использующей декларативный, то есть обязательный для выполнения язык для описания задач и библиотеки дляихреализации. Клиенты периодически (по умолчанию каждые 30 минут) соединяются с центральным сервером и получают последнюю конфигурацию. Если полученные настройки не совпадают с системным состоянием, они будут выполнены, при необходимости серверу отсылается отчет о произведенных операциях. Сервер сообщения может сохранить вsyslog или файл, создать RRD-график, отослать на указанный e-mail. Дополнительные уровни абстракции Transactional и Resource обеспечивают максимальную совместимость ссуществующими настройками и приложениями, позволяя сфокусироваться на системных объектах, не заботясь о различиях в реализации и описании подробных команд иформатах файлов. Администратор оперирует лишь с типом объекта, остальное Puppet берет на себя. Так, тип packages знает о 17 пакетных системах, нужная автоматически будет распознана на основании информации о версии дистрибутива или системы, хотя при необходимости пакетный менеджер можно задать принудительно.

В отличие от скриптов, которые часто невозможно использовать в других системах, конфигурации Puppet, написанные сторонними администраторами, будут в большинстве безпроблем работать в любой другой сети. В Puppet CookBook уже имеется три десятка готовых рецептов. В настоящее время Puppet официально поддерживает следующие операционные системы и сервисы: Debian, RedHat/Fedora, Solaris, SUSE, CentOS, Mac OS X, OpenBSD, Gentoo и MySQL, LDAP.

Язык Puppet

Чтобы идти дальше, вначале следует разобраться с основными элементами и возможностями языка. Язык – это одна из сильных сторон Puppet. С его помощью описываются ресурсы, которыми администратор планирует управлять, и действия. В отличие от большинства подобных решений, в Puppet язык позволяет упростить обращение ко всем схожим ресурсам на любой системе в гетерогенной среде. Описание ресурса, как правило, состоит из названия, типа и атрибутов. Например, укажем на файл /etc/passwd и установим его атрибуты:

file { "/etc/passwd":

Owner => root,

Group => root,

Mode => 644,

Теперь клиенты, подключившись к серверу, скопируют файл /etc/passwd и установят указанные атрибуты. В одном правиле можно определять сразу несколько ресурсов, разделяя их с помощью точки с запятой. А что делать, если конфигурационный файл, используемый на сервере, отличается от клиентских или вообще не используется? Например, такая ситуация может возникнуть при настройках VPN-соединений. В этом случае следует указать на файл директивой source. Здесь два варианта, можно, как обычно указать путь кдругому файлу, а также с помощью поддерживающихся двух URI протоколов: file и puppet. В первом случае используется ссылка на внешний NFS-сервер, во втором варианте насервере Puppet запускается NFS-подобный сервис, который и экспортирует ресурсы. В последнем случае по умолчанию путь указывается относительно корневого каталога puppet– /etc/puppet. То есть ссылка puppet://server.domain.com/config/sshd_config будет соответствовать файлу /etc/puppet/config/sshd_config. Переопределить этот каталог можно спомощью директивы filebucket, хотя более правильно использовать одноименную секцию в файле /etc/puppet/fileserver.conf. В этом случае можно ограничить доступ к сервису только сопределенных адресов. Например, опишем секцию config:

Path /var/puppet/config

Allow *.domain.com

Allow 127.0.0.1

Allow 192.168.0.*

Allow 192.168.1.0/24

Deny *.wireless.domain.com

А затем обращаемся к этой секции при описании ресурса:

source => "puppet://server.domain.com/config/sshd_config"

Перед двоеточием располагается название ресурса. В самых простых случаях в качестве имени можно просто указать полный путь к файлу. В более сложных конфигурациях лучше использовать псевдоним или переменные. Псевдоним устанавливается с помощью директивы alias:

file { "/etc/passwd":

Alias => passwd

Другой вариант создания псевдонима хорошо подходит в том случае, когда приходится иметь дело с разными операционными системами. Например, создадим ресурс, описывающий файл sshd_config:

file { sshdconfig:

Name => $operatingsystem ? {

Solaris => "/usr/local/etc/ssh/sshd_config",

Default => "/etc/ssh/sshd_config"

В этом примере мы столкнулись с возможностью выбора. Отдельно указан файл для Solaris, для всех остальных будет выбран файл /etc/ssh/sshd_config. Теперь к этому ресурсу можно обращаться как к sshdconfig, в зависимости от операционной системы будет выбран нужный путь. Например, укажем, что в случае, если демон sshd запущен и получен новый файл, следует перезапустить сервис:

service { sshd:

Ensure => true,

Subscribe => File

Переменные часто используются при работе с пользовательскими данными. Например описываем месторасположение домашних каталогов пользователей:

$homeroot = "/home"

Теперь к файлам конкретного пользователя можно обратиться как:

${homeroot}/$name

В параметр $name будет подставлено учетное имя пользователя. В некоторых случаях удобно определить значение по умолчанию для некоторого типа. Например, для типа exec очень часто указывают каталоги, в которых он должен искать исполняемый файл:

Exec { path => "/usr/bin:/bin:/usr/sbin:/sbin" }

В том случае, если нужно указать на несколько вложенных файлов и каталогов, можно использовать параметр recurse:

file { "/etc/apache2/conf.d":

Source => "puppet:// puppet://server.domain.com/config/apache/conf.d",

Recurse => "true"

Несколько ресурсов могут быть объединены в классы или определения. Классы являются законченным описанием системы или сервиса и используются обособленно:

class linux {

File {

"/etc/passwd": owner => root, group => root, mode => 644;

"/etc/shadow": owner => root, group => root, mode => 440

Как и в объектно-ориентированных языках, классы могут переопределяться. Например, в FreeBSD группой-владельцем этих файлов является wheel. Поэтому, чтобы не переписывать ресурс полностью, создадим новый класс freebsd, который будет наследовать класс linux:

class freebsd inherits linux {

File["/etc/passwd"] { group => wheel };

File["/etc/shadow"] { group => wheel }

Для удобства все классы можно вынести в отдельный файл, который нужно подключать директивой include. Определения могут принимать многочисленные параметры в качестве аргументов, но не поддерживают наследования и используются в том случае, если нужно описать многократно используемые объекты. Например, определим домашний каталог пользователей и команды, необходимые для создания новой учетной записи:

define user_homedir ($group, $fullname, $ingroups) {

User { "$name":

Ensure => present,

Comment => "$fullname",

Gid => "$group",

Groups => $ingroups,

Membership => minimum,

Shell => "/bin/bash",

Home => "/home/$name",

Require => Group[$group],

Exec { "$name homedir":

Command => "/bin/cp -R /etc/skel /home/$name; /bin/chown -R $name:$group /home/$name",

Creates => "/home/$name",

Require => User[$name],

Теперь, чтобы создать новую учетную запись, достаточно обратиться к user_homedir:

user_homedir { "sergej":

Group => "sergej",

Fullname => "Sergej Jaremchuk",

Ingroups => ["media", " admin]

Отдельно стоят описания узлов (node), которые поддерживают наследование, как и классы. При подключении клиента к серверу Puppet будет произведен поиск соответствующей секции node и выданы специфические только для этого компьютера настройки. Для описания всех остальных систем можно использовать node default. Описание всех типов приведено в документе «Type Reference», с которым необходимо ознакомиться в любом случае, хотя бы для того, чтобы понять все возможности языка Puppet. Различные типы позволяют выполнять указанные команды, в том числе и при выполнении определенных условий (например, изменение конфигурационного файла), работать с cron, учетными данными и группами пользователей, компьютерами, монтированием ресурсов, запуском и остановкой сервисов, установкой, обновлением и удалением пакетов, работой с SSH-ключами, зонами Solaris и так далее. Вот так просто можно заставить обновлять список пакетов в дистрибутивах, использующих apt, ежедневно между 2 и 4 часами:

schedule { daily:

Period => daily,

Range =>

exec { "/usr/bin/apt-get update":

Schedule => daily

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

Установка Puppet

Для работы Puppet потребуются Ruby (начиная с версии 1.8.1 и выше) с поддержкой OpenSSL и библиотеками XMLRPC, а также библиотека Faster . В репозитарии Ubuntu 7.04, который использовался при тестовой установке, уже включен пакет puppy:

$ sudo apt-cache search puppet

~$ ruby -rxmlrpc/client -e "puts:yep"

yep

Если не получено ошибок, значит, все необходимое уже включено. Файлы, в которых описывается желательная конфигурация систем, в терминологии Puppet называются манифестами (manifests). При запуске демон пытается прочитать файл /etc/puppet/manifests/site.pp, при его отсутствии выдает предупреждающее сообщение. При тестировании можно указать демону на работу в автономном режиме, при котором манифест не требуется:

$ sudo /usr/bin/puppetmasterd --nonodes

При необходимости к site.pp можно подключать другие файлы, например, с описаниями классов. Для тестового запуска в этот файл можно занести самую простую инструкцию.

class sudo {

File { "/etc/sudoers":

Owner => root,

Group => root,

Mode => 440,

node default {

Include sudo

Все конфигурационные файлы, как сервера так и клиентов, расположены в /etc/puppet. Файл fileserver.conf, о котором мы уже говорили, не обязателен и используется только в том случае, когда Puppet будет работать еще и как файл-сервер. В Ubuntu в этом файле экспортируется подкаталог /etc/puppet/files. В подкаталоге ssl расположены сертификаты и ключи, которые будут использоваться для шифрования при подключениях клиентов. Ключи создаются автоматически при первом запуске puppetmasterd, вручную их можно создать командой:

$ sudo /usr/bin/puppetmasterd --mkusers

Файлы puppetd.conf и puppetmasterd.conf похожи. В них указываются некоторые параметры работы демонов на клиентской системе и сервере. Клиентский файл отличается только наличием параметра server, указывающего на компьютер, на котором запущен puppetmasterd:

server = grinder.com

logdir = /var/log/puppet

vardir = /var/lib/puppet

rundir = /var/run

# отсылаем отчет серверу

report = true

Чтобы не печатать все вручную, можно создать шаблон с помощью самого puppetd:

$ puppetd --genconfig > /etc/puppet/puppetd.conf

Аналогично можно создать и site.pp на сервере:

$ puppetd --genmanifest > /etc/puppet/manifests/site.pp

Еще один файл tagmail.conf, позволяет указать почтовые адреса, на которые будут отсылаться отчеты. В простейшем случае можно использовать одну строку:

all: [email protected]

Конфигурационных файлов недостаточно, чтобы клиент мог подключаться к серверу. Для этого необходимо еще подписать сертификаты.

Сначала, чтобы сервер узнал о новом компьютере, на клиентской системе вводим команду:

$ sudo puppetd --server grinder.com --waitforcert 60 –test

Межсетевой экран должен разрешать соединения на порт 8140.

На сервере получаем список сертификатов, нуждающихся в подписи:

$ sudo puppetca –list

nomad.grinder.com

И подписываем сертификат клиента:

$ sudo puppetca –sign nomad.grinder.com

Теперь клиент может свободно подключаться к серверу и получать настройки.

К сожалению, все возможности Puppet в пределах статьи показать невозможно. Но, как видите, это функциональный и гибкий инструмент, позволяющий решить большую часть задач по одновременному администрированию большого числа систем. И самое главное, проекту удалось собрать пока небольшое, но постоянно растущее сообщество. Поэтому будем надеяться, что хорошей идее не дадут умереть или уйти в сторону.

Удачи!

1. Сайт проекта BladeLogic – http://www.bladelogic.com .
2. Сайт проекта OpsWare – http://www.opsware.com .
3. Сайт проекта Cfengine – http://www.cfengine.org .
4. Сайт проекта Puppet – http://reductivelabs.com/projects/puppet .
5. Puppet CookBook – http://www.reductivelabs.com/trac/puppet/tagspuppet%2Crecipe .
6. Библиотека Faster –