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

Re: [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

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

[Paul Wolneykien]

В Птн, 30/10/2009 в 10:32 +0300, Stanislav Ievlev пишет:
> 3. Поскольку конфигурирование орудует с объектами очень разной
> природы, то как откатить какое-либо действие знает только бакенд.
> Поэтому возможно что в ответ на вызов метода-модификатора будет
> возвращаться команда для отката действия.

  А почему изменение конфигурации нужно как-то откатывать иначе чем
накатывать? Речь, на мой взгляд, просто в версии конфигурационного
файла. Git-справится. Другое дело, что git diff покажет дельту между
файлами, в которой чёрт ногу сломит. Поэтому я думаю, что стоит
показывать дельту между "/obj action read" который был раньше и "/obj
action read" который мы имеем сейчас. Вот в чём была моя основная идея.

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

[Anton Farygin]

30.10.2009 14:14, Paul Wolneykien пишет:
> В Птн, 30/10/2009 в 10:32 +0300, Stanislav Ievlev пишет:
>> 3. Поскольку конфигурирование орудует с объектами очень разной
>> природы, то как откатить какое-либо действие знает только бакенд.
>> Поэтому возможно что в ответ на вызов метода-модификатора будет
>> возвращаться команда для отката действия.
>
>    А почему изменение конфигурации нужно как-то откатывать иначе чем
> накатывать? Речь, на мой взгляд, просто в версии конфигурационного
> файла. Git-справится. Другое дело, что git diff покажет дельту между
> файлами, в которой чёрт ногу сломит. Поэтому я думаю, что стоит
> показывать дельту между "/obj action read" который был раньше и "/obj
> action read" который мы имеем сейчас. Вот в чём была моя основная идея.

Идея стоящая. Т.е. - можно добавить какую-то прослойку, которая будет 
хранить все состояния дерева объектов. И, в зависимости от команды 
-откатывать простым write нового значения ?

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

[Paul Wolneykien]

В Птн, 30/10/2009 в 14:51 +0300, Anton Farygin пишет:
> 30.10.2009 14:14, Paul Wolneykien пишет:
> > В Птн, 30/10/2009 в 10:32 +0300, Stanislav Ievlev пишет:
> >> 3. Поскольку конфигурирование орудует с объектами очень разной
> >> природы, то как откатить какое-либо действие знает только бакенд.
> >> Поэтому возможно что в ответ на вызов метода-модификатора будет
> >> возвращаться команда для отката действия.
> >
> >    А почему изменение конфигурации нужно как-то откатывать иначе чем
> > накатывать? Речь, на мой взгляд, просто в версии конфигурационного
> > файла. Git-справится. Другое дело, что git diff покажет дельту между
> > файлами, в которой чёрт ногу сломит. Поэтому я думаю, что стоит
> > показывать дельту между "/obj action read" который был раньше и "/obj
> > action read" который мы имеем сейчас. Вот в чём была моя основная идея.
> 
> Идея стоящая. Т.е. - можно добавить какую-то прослойку, которая будет 
> хранить все состояния дерева объектов. И, в зависимости от команды 
> -откатывать простым write нового значения ?

  Нет, простым write, к сожалению не получится. Стас, в своё время, не
завёл такого полиси, чтобы все операции выполнялись исключительно
посредством read/write. Так что я думаю использовать read и list только
для просмотра и сравнения. А восстанавливать конфигурационные файлы
напрямую из гита.

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

[Anton Farygin]

30.10.2009 14:58, Paul Wolneykien пишет:
> В Птн, 30/10/2009 в 14:51 +0300, Anton Farygin пишет:
>> 30.10.2009 14:14, Paul Wolneykien пишет:
>>> В Птн, 30/10/2009 в 10:32 +0300, Stanislav Ievlev пишет:
>>>> 3. Поскольку конфигурирование орудует с объектами очень разной
>>>> природы, то как откатить какое-либо действие знает только бакенд.
>>>> Поэтому возможно что в ответ на вызов метода-модификатора будет
>>>> возвращаться команда для отката действия.
>>>
>>>     А почему изменение конфигурации нужно как-то откатывать иначе чем
>>> накатывать? Речь, на мой взгляд, просто в версии конфигурационного
>>> файла. Git-справится. Другое дело, что git diff покажет дельту между
>>> файлами, в которой чёрт ногу сломит. Поэтому я думаю, что стоит
>>> показывать дельту между "/obj action read" который был раньше и "/obj
>>> action read" который мы имеем сейчас. Вот в чём была моя основная идея.
>>
>> Идея стоящая. Т.е. - можно добавить какую-то прослойку, которая будет
>> хранить все состояния дерева объектов. И, в зависимости от команды
>> -откатывать простым write нового значения ?
>
>    Нет, простым write, к сожалению не получится. Стас, в своё время, не
> завёл такого полиси, чтобы все операции выполнялись исключительно
> посредством read/write. Так что я думаю использовать read и list только
> для просмотра и сравнения. А восстанавливать конфигурационные файлы
> напрямую из гита.

Есть большая засада с тем, что не всё хранится именно в конфигурационных 
файлах.

Да, и таким образом, например, не откатить создание пользователя. Тут 
нужно подумать как следует.

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

[Paul Wolneykien]

В Птн, 30/10/2009 в 15:03 +0300, Anton Farygin пишет:
> 30.10.2009 14:58, Paul Wolneykien пишет:
> > В Птн, 30/10/2009 в 14:51 +0300, Anton Farygin пишет:
> >> 30.10.2009 14:14, Paul Wolneykien пишет:
> >>> В Птн, 30/10/2009 в 10:32 +0300, Stanislav Ievlev пишет:
> >>>> 3. Поскольку конфигурирование орудует с объектами очень разной
> >>>> природы, то как откатить какое-либо действие знает только бакенд.
> >>>> Поэтому возможно что в ответ на вызов метода-модификатора будет
> >>>> возвращаться команда для отката действия.
> >>>
> >>>     А почему изменение конфигурации нужно как-то откатывать иначе чем
> >>> накатывать? Речь, на мой взгляд, просто в версии конфигурационного
> >>> файла. Git-справится. Другое дело, что git diff покажет дельту между
> >>> файлами, в которой чёрт ногу сломит. Поэтому я думаю, что стоит
> >>> показывать дельту между "/obj action read" который был раньше и "/obj
> >>> action read" который мы имеем сейчас. Вот в чём была моя основная идея.
> >>
> >> Идея стоящая. Т.е. - можно добавить какую-то прослойку, которая будет
> >> хранить все состояния дерева объектов. И, в зависимости от команды
> >> -откатывать простым write нового значения ?
> >
> >    Нет, простым write, к сожалению не получится. Стас, в своё время, не
> > завёл такого полиси, чтобы все операции выполнялись исключительно
> > посредством read/write. Так что я думаю использовать read и list только
> > для просмотра и сравнения. А восстанавливать конфигурационные файлы
> > напрямую из гита.
> 
> Есть большая засада с тем, что не всё хранится именно в конфигурационных 
> файлах.

  Да. И вот тут как раз таки и нужна прослойка. И, кстати сказать, в
некоторых случаях она уже имеется. Например правила iptables статически
хранятся в etcnet.

> 
> Да, и таким образом, например, не откатить создание пользователя. Тут 
> нужно подумать как следует.

  Да, сфера применения ограниченная. Но, вообще говоря, такие вещи как
пакетная база и пользователи я не отношу к "настройкам".

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

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 1262 bytes --]

On Fri, Oct 30, 2009 at 03:03:56PM +0300, Anton Farygin wrote:
> Есть большая засада с тем, что не всё хранится именно в конфигурационных 
> файлах.
> Да, и таким образом, например, не откатить создание пользователя. Тут 
> нужно подумать как следует.
Ruby on Rails database migrations:

$ cat db/migrate/002_issue_move.rb
class IssueMove < ActiveRecord::Migration
  # model removed
  class Permission < ActiveRecord::Base; end

  def self.up
    Permission.create :controller => "projects", :action => "move_issues", :description => "button_move", :sort => 1061, :mail_option => 0, :mail_enabled => 0
  end

  def self.down
    Permission.find(:first, :conditions => ["controller=? and action=?", 'projects', 'move_issues']).destroy
  end
end

$ rake --describe db:migrate:     
rake db:migrate:down
    Runs the "down" for a given migration VERSION.

rake db:migrate:redo
    Rollbacks the database one migration and re migrate up. If you want to rollback more than one step, define STEP=x. Target specific version with VERSION=x.

rake db:migrate:reset
    Resets your database using your migrations for the current environment

rake db:migrate:up
    Runs the "up" for a given migration VERSION.

-- 
Regards,
Sir Raorn.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Paul Wolneykien]

В Птн, 30/10/2009 в 15:24 +0300, Alexey I. Froloff пишет:
> On Fri, Oct 30, 2009 at 03:03:56PM +0300, Anton Farygin wrote:
> > Есть большая засада с тем, что не всё хранится именно в конфигурационных 
> > файлах.
> > Да, и таким образом, например, не откатить создание пользователя. Тут 
> > нужно подумать как следует.
> Ruby on Rails database migrations:
> 
> $ cat db/migrate/002_issue_move.rb
> class IssueMove < ActiveRecord::Migration
>   # model removed
>   class Permission < ActiveRecord::Base; end
> 
>   def self.up
>     Permission.create :controller => "projects", :action => "move_issues", :description => "button_move", :sort => 1061, :mail_option => 0, :mail_enabled => 0
>   end
> 
>   def self.down
>     Permission.find(:first, :conditions => ["controller=? and action=?", 'projects', 'move_issues']).destroy
>   end
> end

  Только что шла речь про ответы на английском.
  Отвечать на Ruby тоже нехорошо! ;)

  Прокомментируй, пожалуйста. :)

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

[Paul Wolneykien]

В Птн, 30/10/2009 в 15:14 +0300, Paul Wolneykien пишет:
>   Да, сфера применения ограниченная. Но, вообще говоря, такие вещи как
> пакетная база и пользователи я не отношу к "настройкам".

  Но мне кажется, что для управления шлюзами вполне годится.

  Я завёл страничку на вики, где попытался более подробно описать такую
систему. Она называется ЦМПУ -- Центр мониторинга, прогнозирования и
управления.

  http://www.altlinux.org/ЦМПУ

  Паша.

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

[Stanislav Ievlev]

30 октября 2009 г. 14:58 пользователь Paul Wolneykien
<manowar@altlinux.org> написал:
> В Птн, 30/10/2009 в 14:51 +0300, Anton Farygin пишет:
>> 30.10.2009 14:14, Paul Wolneykien пишет:
>> > В Птн, 30/10/2009 в 10:32 +0300, Stanislav Ievlev пишет:
>> >> 3. Поскольку конфигурирование орудует с объектами очень разной
>> >> природы, то как откатить какое-либо действие знает только бакенд.
>> >> Поэтому возможно что в ответ на вызов метода-модификатора будет
>> >> возвращаться команда для отката действия.
>> >
>> >    А почему изменение конфигурации нужно как-то откатывать иначе чем
>> > накатывать? Речь, на мой взгляд, просто в версии конфигурационного
>> > файла. Git-справится. Другое дело, что git diff покажет дельту между
>> > файлами, в которой чёрт ногу сломит. Поэтому я думаю, что стоит
>> > показывать дельту между "/obj action read" который был раньше и "/obj
>> > action read" который мы имеем сейчас. Вот в чём была моя основная идея.
>>
>> Идея стоящая. Т.е. - можно добавить какую-то прослойку, которая будет
>> хранить все состояния дерева объектов. И, в зависимости от команды
>> -откатывать простым write нового значения ?
>
>  Нет, простым write, к сожалению не получится. Стас, в своё время, не
> завёл такого полиси, чтобы все операции выполнялись исключительно
> посредством read/write. Так что я думаю использовать read и list только
> для просмотра и сравнения. А восстанавливать конфигурационные файлы
> напрямую из гита.
Полиси не завелось само собой ибо если всё сводить к файловым
операциям, то достаточно быстро это перестаёт быть естественным
процессом и приходится заниматься изобретательством и притягиваниями
за уши. Это ,кстати, одна из причин почему отказались от admfs.