puppet

sed -i 's/badone/goodone/' /etc/somefile

это не так. augeas несколько более функционален. а вот такой вот sed - действительно багогенерилка.

не все сервисы умеют такой синтаксис.

Непонятно зачем хочется описание конфигурации сервиса держать в паппете в одном файле, а не в двух? Или вообще не в файле, а в sql/ldap/etc ? Паттерн в паппете останется прежним.

Ну, я утрировал, конечно - sed умеет вещи и более сложные делать.

Но нет, augeas делает именно это. Единственный его бонус - он считает, что "понимает" формат конфига. Со всеми вытекающими...

Смысл был в том, что лучше подобного редактирования избегать. Использовать шаблоны, дробить конфигурацию.

Это тоже повод для выбора сервисов, верно? Не умеет - не берем.

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

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

Явно удобнее, нежели вручную изобретать с нуля велосипед для sed.

Как обычно, зависит от ситуации.

В ситуации, когда у меня в сети разные версии центоса, редхатов, убунт, дебианов - и мне на всех них надо добавить ключик в sshd_config, не перезаписывая конфиг - augeas удобно.

Ну когда выбор есть - то это может быть одним из поводов. Но далеко не всегда выбор есть.

эээ... считаем что конфиг для vhost конфигурится единым шаблоном, на основании данных из файлика, описания vhost'а. Ну и vhost'ы однотипные, мы же про mod-proxy в данном случае говорим.

Это далеко не так-то просто.

Удобнее чем s/one/two/ - Вы шутите? :)

Да, в ней - явно "удобнее". Но данная ситуация называется бардак и тут уже речь не об удобстве, а о том как от нее избавиться ;)

Например? Системный администратор выбирает софт, не наоборот.

Ну да. Хотя шаблоны могут быть и разными.

Тем не менее, у нас есть "файлик описания" (yaml, json, etc) и привязка vhost к серверам.

Ну мы же говорим только о профпригодных системных администраторах, которые не боятся читать документацию и писать скрипты-конфиги? ))

Разумеется. ибо в общем случае такой простой regexp не пойдет. Под one может попасть масса ненужного. Разумеется, в каждом конкретном случае можно придумать хитрый регексп.. Но врятли это удобнее augeas )

Очевидно Вам не приходилось встречаться с девелоперскими конторами, в которых разные группы разработчиков в силу ТЗ проектов должны работать с разными версиями ОС. Гораздо проще, основываясь на собственном опыте, назвать эту ситуацию бардаком, да.

Когда есть из чего выбирать. Предложите, например, аналог isc'шного dhcpd, умеющего fault tolerance?

Это один и тот же файл. Сервер, на котором должен будет располагаться vhost, является одним из атрибутов vhost'a и должен быть указан в файлике описания.

Понимаете, вот я - слабо знакомый с этим чудом человек - моментально обнаружил, что абсолютно никакого "понимания" синтаксиса sshd_config или апача у этой штуки нет. Короче: Вы вполне можете получить нерабочий sshd на выходе.

Ну например. Для sshd_config - не учитывается порядок следования директив. Для httpd.conf - контекст, в котором директива может/не может быть. И т.п. и т.д.

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

Увы, работает вся эта сказка разве для /etc/hosts (не факт, кстати - не смотрел ;)). Оно Вам сильно надо - /etc/hosts править?

Здесь есть некоторое оправдание... Но бардак, да.

dhcpd разучился include делать? 0_0

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

И в чем же тут бардак?

Тут я привел пример dhcpd как софта, которому при некотором наборе требований замены нет.

А include он умеет, да.

В конкретно моем случае этого не нужно, но

ради бога, пусть в поле конфига, отвечающего за сервер, будет не единичное значение, а список.

Очевидно в том, что плодится гетерогенная система просто потому, что кто-то не подумал над другими вариантами. Для тестирования, к примеру - такой бардак вряд-ли стоило устраивать.

Могу, конечно, и ошибаться - точнее сказать получится только если Вы посвятите чуть подробнее в детали ТЗ.

При "некотором наборе требований" - вполне однозначно выделяется ровно один "пример софта". Вы без фанатизма, идея ведь была проста: вменяемая конфигурация - очень даже весомый критерий для выбора сервиса. Кстати, возможность "include" обычно более чем легко прикрутить. Имхо, это куда лучше костылей-монстров типа augeas.

rhn/spacewalk используют puppet для распространения конфигурации.

посвящу. Есть n заказчиков, у некоторых из них четкое требование - решение должно работать под такой то версией такой то ОС. И соответственно для построения лабы используется именно та ОС именно той версии, указанной в требовании заказчика. Но вместе с тем все лабы должны удовлетворять неким корпоративным стандартам в настройке. И с этой задачей puppet+augeas справляются отлично.

Я не о том совсем. Не нравится augeas - не пользуйте. Меня он более чем устраивает.

Речь была о другом. Есть набор требований - dhcp сервер, с поддержкой ldap и fault tolerance.

Решение - ровно одно, isc dhcpd. Соответственно независимо от его остальных качеств, альтернатив нет - приходится использовать его. Это я пытаюсь показать на примере, что далеко не всегда есть возможность выбирать.