Бывают такие конфиги которые парсить практически бесполезно. Например dhcp.<br><br>С одной стороны есть пользовательский интерфейс решающий конкретную задачу, с другой стороны есть конфиг позволяющий подетально описать топологию сети с огромным количеством "извращений". То есть прочитать-то подобный конфиг можно, но что потом с ним делать.<br>
<br>Аналогичные проблемы у средств работы с iptables.<br><br>Оповещать пользователей о "тронутых" конфигах хорошая идея, давайте что-нибудь сделаем на эту тему ... но кроме хранения для этого где-то в отдельном месте md5sum ничего не приходит в голову ибо пользователь может поправить очень незаметно, но достаточно для поломки интерфейса. Давайте эту проблему обсудим в отдельном треде.<br>
<br>Ну а насчёт Т-500 и недостойного для него alterator мы не сговорились прежде всего не в стратегиях развития, а примерно в том же в чём не сговорились сейчас в Сизифе с rpm5 и co.<br><br>Прежде всего я не видел конкретных предложений (ну кроме того что всё надо выкинуть, но это я и так знаю) , зато было какое-то тихое шуршание в привате и предложения ездить за знаниями в соседний часовой пояс.<br>
<br>Ну а стратегия ... да, мне надо постоянно поддерживать и развивать нынешнюю версию, но я многократно рассказывал и показывал, что я переписывал целые куски заново а потом аккуратно перетаскивал туда накопившийся багаж. Не верят ... <br>
<br><div class="gmail_quote">11 апреля 2009 г. 14:20 пользователь Michael Shigorin <span dir="ltr"><<a href="mailto:mike@osdn.org.ua">mike@osdn.org.ua</a>></span> написал:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Thu, Apr 09, 2009 at 04:07:57PM +0400, Pavel Wolneykien wrote:<br>
> > >> metalterator - Alterator meta-backend with additional Guile modules<br>
</div><div class="im">> > > Расскажете подробнее? На <a href="http://www.altlinux.org/Alterator" target="_blank">http://www.altlinux.org/Alterator</a><br>
> > > и в окрестностях ничего не нашёл, а интересно.<br>
> Это радует, что интересно. ;)<br>
<br>
</div>Погодите радоваться, вон у Стаса можете спросить,<br>
во что такой интерес порой выливается :)<br>
<br>
А это письмо бы всё равно хорошо на вики в качестве описания.<br>
<div class="im"><br>
> Значит дело было так. Собрался я писать модуль для Squid (во<br>
> второй раз, но это отдельная история). После разговора с wart@<br>
> и ldv@ мне стало совершенно понятно, что для работы с<br>
> относительно сложным конфигурационным файлом нужна БД: ни<br>
> читать, ни писать отдельные значения в файл нельзя -- всё<br>
> перепутается. Зато сгенерировать такой файл целиком задача на<br>
> порядок проще.<br>
<br>
</div>Возможно, wart@ и ldv@ не настраивают squid в повседневной<br>
деятельности -- перед изменением, которое по сути представляет<br>
из себя воспроизведение через много-много лет одной из худших<br>
черт SuSE YaST -- "конфиг руками не трогать", стоит советоваться<br>
не в закрытом режиме (как нам пеняли вот), а с теми, кому с этим<br>
жить. Т.е. в sysadmins@ и с support@.<br>
<br>
Я могу только заметить, что перегенерация файла с довольно<br>
нетривиальным, обширным и _не_ покрываемым никакой настраивалкой<br>
с обозримым интерфейсом синтаксисом -- это плохая идея, хотя так<br>
писать настраивалку проще, конечно.<br>
<br>
Причём это принципиальная разница языка и книжки-раскраски:<br>
нетривиальные проекты склонны реализовывать именно _язык_<br>
конфигурации, а самая лучшая настраивалка ничем не отличается<br>
от сколь угодно удобной в использовании, направляющей, упреждающе<br>
подсказывающей, но неизбежно ограниченной стопки шаблонов.<br>
<br>
При этом в жизни мы пользуемся языком, а не счётными палочками.<br>
Потому как задачи сложнее. Но начинали -- со счётных палочек.<br>
Так и тут: хорошая настраивалка должна быть под рукой, когда<br>
задача новая или редкая и при этом типичная; замечательная<br>
настраивалка позволит отойти от её использования и не цепляться.<br>
А для этого -- не будет держать под страхом того, что конфиг ни<br>
на йоту нельзя трогать мимо неё.<br>
<div class="im"><br>
> Тогда я стал думать: какую БД мне выбрать? Ясно что самую<br>
> простую, поскольку данных, которыми может управлять<br>
> пользователь в пределах одного модуля, скорее всего, немного.<br>
> Поэтому критерием поиска БД стало удобство отображения в неё<br>
> объектов Альтератора. И вот тут я понял, что неплохим<br>
> хранилищем для этих объектов будет обычная файловая система! На<br>
> что inger@ сказал: "ФС -- это одна из самых клёвых встроенных<br>
> БД!".<br>
<br>
</div>Интересно, а не вспоминал ли он при этом один из предложенных<br>
нами в своё время фрагментов насчёт "распределённой базы<br>
состояния и правил"?<br>
<br>
Понятно, что всему своё время, но уж если добрались до желания<br>
базы и решили засунуть её просто на ФС (которая является ещё и<br>
_иерархической_ базой, если уж на то пошло, а не реляционной;<br>
это важно) -- то мне немного страшно представлять себе, как потом<br>
будет решаться задача расшаривания этой самой базы для настройки<br>
стайки тех же squid'ов по региональным отделениям заказчика.<br>
<div class="im"><br>
> Таким образом, вместо библиотеки я решил написать отдельный<br>
> бакенд, который бы отображал woo-команды на файловую систему.<br>
<br>
</div>Шеллы наши бЫстры, но всё-таки плохо подходят для насыщенных<br>
слоёв абстракции. В код не смотрел (c), но возможно,<br>
сериализовать сразу структуры данных и бросать их целиком через<br>
native backend было бы несколько меньшим ударом по скорости.<br>
Если уж идти таким путём.<br>
<div class="im"><br>
> Если была дана команда прочесть атрибут, который не задан в<br>
> объекте, то будет явно возвращено значение #f.<br>
<br>
</div>Ммм... а с существующими булевыми должны долетать тоже уже #t/#f<br>
или ещё yes/no? Может возникнуть ситуация "неразборчиво".<br>
<br>
Ещё пока опять вспомнил на ту же тему: в процессе написания<br>
alterator-ltsconf встал вопрос о понятии дефолта или дефолтности<br>
значения параметра -- там по логике работы удобно иметь<br>
возможность регулировать общие для всех тонких клиентов параметры<br>
или указывать для конкретных частные (при этом не засоряем UI<br>
копиями общего значения и можно отличить, на что именно повлияет<br>
изменение дефолтов).<br>
<br>
Это один из шажков к управлению неединичными системами, и в его<br>
процессе оказалось, что в альтераторе для такого сейчас нет ничего.<br>
См. <a href="http://tinyurl.com/ltsconf-defaultness" target="_blank">http://tinyurl.com/ltsconf-defaultness</a> и ниже, что пришлось<br>
накостылять в качестве частного "решения".<br>
<div class="im"><br>
> Да, совсем забыл: полное имя объекта, т.е. всё, что идёт после /meta<br>
> интерпретируется как путь месту в ФС! К примеру,<br>
> alterator-cmdline /meta/etc/metalterator/squid/squid "write" http_port "3128"<br>
> обновит значение http_port в файле /etc/metalterator/squid/squid.scm.<br>
<br>
</div>Не следует писать в /etc по каждому чиху, для этого есть /var<br>
и прочие $TMP. Внезапное выключение питания или кернел паник<br>
в самый неподходящий момент -- эффективный учитель :(<br>
<div class="im"><br>
> В настоящее время единственным пользователем метабакенда<br>
> является бакенд squid из пакета alterator-squid-1.0-alt1.<br>
> Кстати сказать: конфигурацию по умолчанию этот пакет несёт с<br>
> собой в виде набора файлов, которые он кладёт как есть прямо в<br>
> /etc/metalterator/squid. По моему это тоже очень удобно!<br>
<br>
</div>Кому и чем?<br>
<br>
Сисадмину удобен (потому как привычен) /etc/squid/squid.conf,<br>
который можно править $EDITOR.<br>
<br>
Разработчику модулей (вот мне) -- видится тупиковой идея генерата.<br>
<br>
Ну и честно говоря, пока не вижу никакого особенного мета- в ещё<br>
одном бэкенде -- то, что уже давно было продумано и сделано,<br>
гораздо более метаинструмент, и притом его всё равно есть куда<br>
и надо обобщать. О чём мы, собсно, и говорили.<br>
<br>
Можно сказать "ну так и сделай, раз такой умный", и это будет<br>
правильно; собственно, за прошлый год мы попытались совместить<br>
свои планы по разработке системы управления множеством<br>
компьютеров с Alterator, но по разным причинам это благополучно<br>
затухло. Поскольку прикладной задачей сейчас здесь является<br>
мониторинг и управление кластером размером с Т-500, то понятно,<br>
что распределённость и масштабируемость приходится закладывать<br>
сразу, а не оставлять на "когда-нибудь"; при этом анализ текущего<br>
Alterator показал, что проще взять хорошие изначальные идеи и<br>
переписать начисто, чем пытаться эволюционировать -- вот в этом<br>
со Стасом возникло различие мнений.<br>
<br>
Надо будет поинтересоваться текущим статусом разработки и есть ли<br>
уже что полезного и публикуемого, но мож хоть Вам пригодится<br>
(хотя честно говоря -- не уверен). Если хотите, могу покопать<br>
переписку и пофорвардить обсуждение. (или даже лучше сюда?..)<br>
<font color="#888888"><br>
--<br>
---- WBR, Michael Shigorin <<a href="mailto:mike@altlinux.ru">mike@altlinux.ru</a>><br>
------ Linux.Kiev <a href="http://www.linux.kiev.ua/" target="_blank">http://www.linux.kiev.ua/</a><br>
</font><div><div></div><div class="h5">_______________________________________________<br>
devel-conf mailing list<br>
<a href="mailto:devel-conf@lists.altlinux.org">devel-conf@lists.altlinux.org</a><br>
<a href="https://lists.altlinux.org/mailman/listinfo/devel-conf" target="_blank">https://lists.altlinux.org/mailman/listinfo/devel-conf</a></div></div></blockquote></div><br>