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

[Paul Wolneykien <manowar@altlinux.org>]

Всем привет.

  В ходе проектирования ЦМУ для Кольчуг и прочих кластеров, я пришёл к
выводу, что комплексное обновление параметров кластера является
стрессовой ситуацией для администратора и представляет проблему даже при
большой степени автоматизации. Для того, чтобы как-то облегчить ему эту
процедуру, было бы логичным дать ему возможность провести анализ
предстоящих изменений и скорректировать свои действия.

  Поскольку состояние системы представляется через Альтератор как набор
параметров объектов, то возможно и логично показать администратору
сводную таблицу параметров, с указанием их текущего и будущего состояния
на каждом из узлов сети. С каждым параметром в этом случае должно быть
связано некоторое внешнее имя или название, но это не проблема, я думаю.

  Поскольку каждая совершаемая в подобных условиях операция может быть
снабжена временным штампом и комментариями производящего действие лица,
кроме возможности проанализировать свои действия, администратор получает
возможность вести учёт действий, совершаемых им или третьими лицами. В
перспективе можно предположить даже возможность "отката" определённых
действий, т.е. возврата системы в состояние, соответствующее
определённому временному штампу.

  Основная проблема с организацией такого предварительного просмотра
изменений -- это необходимость как-то предсказывать будущие значения
параметров объектов или, говоря другими словами, реакцию системы на
производимые действия. Самым надёжным способом такого предсказания было
бы производить заданные действия с дубликатом системы, однако такое
решение, очевидно, слишком накладно. Удешевить его нам позволяет тот
факт, что дубликат системы вовсе не обязательно должен обладать полной
её функциональностью, а напротив, быть эквивалентным ей лишь по строго
ограниченному набору входных и выходных параметров. Вместо исходных
служб в системе дубликате могут работать "службы-заглушки", и основным
вопросом становится вопрос об эффективной методике построения таких
заглушек.

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

  Дальше можно попытаться произвести проекцию типичных функций исходных
служб в типичные функции заглушек. Первое что приходит на ум -- это
свести функцию запуска службы к проверки корректности её
конфигурационных файлов: если конфигурационный файл был признан
корректным, то заглушка приобретает статус "работает"; иначе заглушка
должна сообщать о невозможности запуска. Некоторые программы имеют
доступные для вызова функции проверки конфигурационных файлов, и этим
можно было бы воспользоваться.

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

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

    Паша.