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