Управление конфигурациями и аудит

Спеки к шефовским рецептам. Беда в том, что тесты будут повторять точь-в-точь содержимое рецептов.

ansible

IMHO это задача не для puppet/chef/etc для для чего-то вроде zabbix/icinga, т.е. для систем мониторинга.

спеки же они для тестирования реептов, не? Или делать рецепт, к нему спеку, которая и будет ругаться, если какой-то параметр еверен?

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

Особой необходимости в скрипте, который проверяет, что в файлике X написана строчка Y, не может быть. Если у этого скрипта есть информация про файлик X и содержимое Y, то почему бы ему самому не писать в этом файлик. И кто проверит, что этот скриптик проверяет на самом деле файлик X и содержимое Y?

puppet и chef хотелось попутно использовать и по назначению - раскидывать конфиги на новых серверах. zabbix есть и рассматривается как один из вариантов, но потребует порядочного допиливания как минимум интерфейса для поиска по параметрам

Особой необходимости в скрипте, который проверяет, что в файлике X написана строчка Y, не может быть.

Файлики это меньшая часть параметров, чаще всего с ними все ок, новые сервера разворачиваются из темплейтов или mksysb и основные параметры уже установлены. Большая часть - это выборки типа «зазеркалирована ли rootvg?, собрана ли аггрегация eth адаптеров?». Все это выхлоп различных команд. Автоматически менять конфигурацию чаще всего либо нельзя, либо невозможно в принципе.

Выхлоп команд ты можешь получать в том же puppet.

Причём не через notify, а через exec. Всё, что выведет команда, ты получишь в отчёте puppet ( куда он попадёт - на диск, в лог или на почту, зависит от настроек ).

Я обычно определяю 2 ресурса: file со скриптом, и exec с командой по запуску этого скрипта.

define run-script($name) {
    file{"$name":
        path    => "/usr/local/sbin/$name",
        source  => "puppet:///files/$name",
        mode    => '0500',
        owner   => 'root',
        group   => 'root',
    }
    exec{"run-$name":
        logoutput   => true,
        schedule    => weekly,
        command => "/usr/local/sbin/$name",
        require => File["$name"],
    }
}

[...]
run-script{'check_aix_disk_queue'}

А сам скрипт лежит в files/check_aix_disk_queue

Но вообще использовать для этого puppet не слишком удобно, время применения по умолчанию полчаса

Подозреваю что тебе нужен «распределённый shell». вроде clusterssh или pssh, http://serverfault.com/questions/13322/what-distributed-shell-utilities-do-pe...

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

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

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

В идеале очень хочется описать где-то (puppet,cfengine, chef) необходимые требования, по которым будут производиться проверки и в случае какого-то отклонения как-то оповещать.

Да, как тут джентльмены сказали, puppet и компания не очень подходят для реализации подобного. Хотя бы потому, что запускается он не часто и не предназначен для мониторинга. Но, в принципе, такое конечно сделать можно с помощью фактера (facter):

• для каждой проверки пишется свой факт,
• значение этого факта проверяется паппетом,
• (не) выполняются какие-то действия.

P.S. Для создания простых фактов прямо из манифестов Puppet, я недавно соорудил один велосипед. По идее, для новых версий facter'а это уже не нужно, но мало ли. Может, пригодится кому.

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

puppet agent --test --detailed-exitcodes

http://docs.puppetlabs.com/man/agent.html

--detailed-exitcodes Provide transaction information via exit codes. If this is enabled, an exit code of '2' means there were changes, an exit code of '4' means there were failures during the transaction, and an exit code of '6' means there were both changes and failures.