[devel] Alterator non root access

[Stanislav Ievlev]

On Tue, May 29, 2007 at 07:16:08PM +0400, Vitaly Ostanin wrote:
> Stanislav Ievlev wrote:
> > On Mon, May 28, 2007 at 06:34:04PM +0400, Vitaly Ostanin wrote:
> >> Здравствуйте.
> >>
> >> Скажите, можно ли выполнять какие-либо действия в alterator не
> >> под рутом?
> >>
> >> Некоторые действия можно доверить и оператору, например,
> >> инициирование процедуры backup, запись его на dvd и т.п.
> > Можно конечно, главное чтобы эти сами действия исполнялись из под пользователя.
> 
> Тема письма оказалась точнее содержимого :( Я имею в виду
> аутентификацию пользователей (не только root) в web-интерфейсе и
> доступ к модулям в зависимости от пользователя. Иногда
> администратору приходится делегировать часть действий.
> 
> Я уже понял, что такой возможности нет. Можно узнать, планируется
> ли она?
Вот именно на это я и отвечал ;)
Да, сейчас такой возможности нет, но она реальна, и если будем успевать -
сделаем это для десктопа ...
> 
> Вообще было бы очень интересно почитать (хотя бы вкратце) про
> историю развития alterator, какие технологии были испробованы, от
> каких отказались и почему, какие планируется использовать.
К сожалению все эти технологии обдумываются и реализуются одним человеком,
соотв. я не успеваю всё задокументировать.

Могу попытаться кратко перечислить основные вехи, ну а вы уж потом
спрашивайте дальше (и было бы неплохо чтобы это сразу появилось на
wiki.sisyphus.ru/Alterator, а то иногда бывают такие вопросы - типа почему
это тут так, а не эдак).

Вот первый слой истории:
1. Эпоха "voins" и "george"- alterator для SOHO сервер.
  Имел только http-интерфейс, свой маленький web-сервер.
  Написан целиком и полностью на C++ (+ boost).
  Были зачатки модульности, но вцелом оставался монолитом.
  Даже html-ные интерфейсы вкомпиливались в бинарник.
2. Эпоха "voins" и "inger" #1 - alterator начала проекта Compact 3.0.
  Разрабатывался только для GUI, но с запасом на http.
  Самая первая версия была чудовищно модульная. Фактически это было
  множество процессов, общающихся через stdin-stdout.
  Интерфейс описывался на xml, похожим на XUL. Динамика на простейшем
  lisp-подобном языке (собственного разлива).

  Однако описание интерфейса оказалось крайне неудачным.
  Поэтому была предпринята идея использовать libguile, ибо оно
  встраивается и на подобном синтаксисе показалось описывать динамические
  интерфейсы проще чем на xml + наше изобретение.

  Где-то в это же время отказались и от красивой идеи admfs - то есть
  хотелось запузырить всё в файловую систему, чтобы потом была красивая
  возможность работать с ней вручную, загонять в CVS и даже бекапить
  конфигурацию. Причина - низкая производительность и сложность сделать
  аккуратную реализацию в многопоточном режиме.

  Вот тогда так называемый backend1 перекочевал из под fuse
  непосредственно под alterator. Отсюда и его странный протокол - был
  сделан для других целей ;) (однако ценные бакенды уже были написаны и их
  не хотелось терять).

  
3. Эпоха "voins" и "inger" #2 - середина проекта Compact 3.0
  Примерно в тоже время выяснилось что производительность оной системы
  оставляет желать лучшего. Килобайты данных бегущих по десятку процессов
  делали своё грязное дело.

  В результате началось переворачивание c++ + libguile в guile + c++ ;)
  Идеальная шина (главный процесс на который крепились все другие
  модули-процессы), была переписана на scheme и стала центром вселенной
  alterator. Наряду с бакендами внешними (backend1) появились бакенды
  нативные (backend2).

  Процесс переворачивания был хорошо растянут во времени, но где-то к
  выпуску Compact 3.0 был победоносно завершён.

  В это время был сделан модуль packages - один из самых навороченных на
  тот момент, что потребовало определённых изменений в идеальной модели
  описания интерфейсов ...

4. Эпоха "inger" #1 - после выпуска Compact 3.0

  Всё более менее утряслось. Язык описания интерфейсов получился
  достаточно гибким (кажется он в этом месте истории существенно
  изменился, о чём было радостно рассказано на очередной протве) - штуки
  типа packages уже легко на это ложились.

  Но тут все вспомнили про http. И тут началось ... GUI был гораздо гибче
  и требовал гораздо более активного общения между отображателем и
  отображаемым.

  В результате от alterator отделился браузер интерфейса (qt-browser).
  Ну и соотв. возник эдаки x-протокол между ними.

  Была предпринята попытка воспользоваться сладким миром AJAX. и для http
  была сооружен тоже эдакий браузер. Сначала использовался qooxdoo. Штука
  мощная, но всё-таки она не могла переварить GUI сделанные под QT -
  иногда firefox заявлял что скрипт исполняется слишком медленно ;)

  Однако что-то более менее интересное всё-таки нарисовалось и попало в
  мир в виде терминальной прошивки (с двумя интерфейсами одновременно).
  
  Потом был опробован вариант с quix (часть проекта porcupine). Он был
  более быстр, более прост - но более глючен ;)

  Где-то в тоже время возник и backend3 - замена устаревшему backend1.
  Там были учтены все недостатки, которые мешали сильно работать. В том
  числе появились состояния и снялось ограничение на возможные операции.

  Для x-протокола был сделан асинхроный протокол по принципу "генерить не
  парсить". Для браузеров шёл xml, а для alterator - родные и близкие ему
  sexp'ы.

  backend3 - унаследовал эту идею (за что я недавно получил критику).
  В сторону бакенда протокол остался от backend1 - то есть достаточно
  простой чтобы обработать можно было даже на shell, а обратно идут
  sexp'ы. Последние сделаны максимально простыми. Заодно снялся ряд
  ограничений на возможные ответы от бакенда.

  Кроме того там появилось понятие сообщение. Раньше бакенд мог обработать
  только часть сообщения, даже если оно не пришло полностью (например
  из-за падения alterator).

5. Эпоха "inger" #2 - выпуск серверного

  Однако время не стояло на месте. На горизонте засветил серверный, а
  ничего простого и надёжного для http не было.
  Кроме того пользователи (особенно сисадмины) с большим трудом понимали
  как писать интерфейсы на guile.

  В какой-то момент support@ запросил модуль, чтобы они просто писали
  бакенд, А он тут же и рисовался в http.

  В результате этих экспериментов и возник первый вариант fbi.
  Потом возника идея. А что если соединить опыт Ajax + кондовость простых
  форм. В результате этого симбиоза и возник нынешний fbi, где:
  1. бакенды рисуются быстро
  2. автоматически приклеиваются к html-ному шаблону и работают.
  3. свистелки, которые так любят пользователи - делаются через Javascript и AJAX.

  Получилось идеально - пользователи полноценных браузеров получали
  почти-что GUI, а пользователи elinks (или пользователи консоли) -
  вариант из простых форм.

  В какой-то момент мне показалось - а зачем тащить тогда на себе этот
  старый GUI, если http к этому времени дорос до него ...
  Но это уже из будущего ;)

> 
> Почему, например, description пакета alterator-fbi содержит
> манящее "alterator on rails", и не следы ли это экспериментов с
> Ruby in Rails :) Чтобы не повторять пройденные этапы.
Думаю, ответ был выше ;))

Нет, я не экспериментировал с рельсами, только читал про них ... у нас с
ними несколько разные цели. Просто получилось вот такое рекламное название ;)