[devel] Песочница и аудит для Альтератора (новая тема)

[Stanislav Ievlev]

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

В письме было поднято очень много тем. Выскажусь на одну из них.

Возможно для массового администрирования и возможности отката действий
подошла бы такая схема.
1. Все команды оформляются как задания, информация о заданиях хранятся в БД.
2. У каждого задания есть некий job retention, что позволит не засорять базу.
3. Поскольку конфигурирование орудует с объектами очень разной
природы, то как откатить какое-либо действие знает только бакенд.
Поэтому возможно что в ответ на вызов метода-модификатора будет
возвращаться команда для отката действия.
4. Команды для отката действия также сохраняются в БД вмести с
заданием и при необходимости могут быть вызваны.

Всё это навеяно архитектурой бакулы ;)

29 октября 2009 г. 1:19 пользователь Paul Wolneykien
<manowar �� altlinux.org> написал:
> Всем привет.
>
>  В ходе проектирования ЦМУ для Кольчуг и прочих кластеров, я пришёл к
> выводу, что комплексное обновление параметров кластера является
> стрессовой ситуацией для администратора и представляет проблему даже при
> большой степени автоматизации. Для того, чтобы как-то облегчить ему эту
> процедуру, было бы логичным дать ему возможность провести анализ
> предстоящих изменений и скорректировать свои действия.
>
>  Поскольку состояние системы представляется через Альтератор как набор
> параметров объектов, то возможно и логично показать администратору
> сводную таблицу параметров, с указанием их текущего и будущего состояния
> на каждом из узлов сети. С каждым параметром в этом случае должно быть
> связано некоторое внешнее имя или название, но это не проблема, я думаю.
>
>  Поскольку каждая совершаемая в подобных условиях операция может быть
> снабжена временным штампом и комментариями производящего действие лица,
> кроме возможности проанализировать свои действия, администратор получает
> возможность вести учёт действий, совершаемых им или третьими лицами. В
> перспективе можно предположить даже возможность "отката" определённых
> действий, т.е. возврата системы в состояние, соответствующее
> определённому временному штампу.
>
>  Основная проблема с организацией такого предварительного просмотра
> изменений -- это необходимость как-то предсказывать будущие значения
> параметров объектов или, говоря другими словами, реакцию системы на
> производимые действия. Самым надёжным способом такого предсказания было
> бы производить заданные действия с дубликатом системы, однако такое
> решение, очевидно, слишком накладно. Удешевить его нам позволяет тот
> факт, что дубликат системы вовсе не обязательно должен обладать полной
> её функциональностью, а напротив, быть эквивалентным ей лишь по строго
> ограниченному набору входных и выходных параметров. Вместо исходных
> служб в системе дубликате могут работать "службы-заглушки", и основным
> вопросом становится вопрос об эффективной методике построения таких
> заглушек.
>
>  Одним из критериев для заглушки я полагаю возможность её работы в
> окружении Hasher, поскольку именно Hasher я считаю наиболее вероятной
> платформой для построения системы-дубликата.
>
>  Дальше можно попытаться произвести проекцию типичных функций исходных
> служб в типичные функции заглушек. Первое что приходит на ум -- это
> свести функцию запуска службы к проверки корректности её
> конфигурационных файлов: если конфигурационный файл был признан
> корректным, то заглушка приобретает статус "работает"; иначе заглушка
> должна сообщать о невозможности запуска. Некоторые программы имеют
> доступные для вызова функции проверки конфигурационных файлов, и этим
> можно было бы воспользоваться.
>
>  В рамках данной задачи, отдельную категорию служб представляют, как
> мне кажется, программы, динамически приобретающие некоторое переменное
> состояние, такие как iptables. Можно ли каким-либо образом безопасно
> задействовать исходную программу iptables в качестве заглушки я не знаю.
> Мне представляется, что для этого нужно было бы иметь соответствующую
> заглушку для ядра, однако как эффективно построить последнюю я не знаю.
> Как я уже указывал, вариант полностью функционирующей системы-дубликата,
> пусть даже и в виртуальной машине, затрачивал бы ресурсы системы
> впустую.
>
>  Мне было бы интересно узнать, что вы обо всём этом думаете, нужна на
> ваш взгляд ли такая система и как её можно было бы реализовать.
>
>    Паша.
>
>
> _______________________________________________
> Devel mailing list
> Devel �� lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel