[Devel] Tartarus alpha

[Evgeny Sinelnikov]

Здравствуйте,

спешу сообщить, что сегодня вечером были завершены последние
приготовления перед началом публичной работы на нашим проектом.
Минимальная часть материалов уже выложена на странице
http://www.tartarus.ru/wiki/Docs

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

___Краткое описание___

Что же собой представляет альфа? Это набор серверных и клиентских
компонентов, позволяющих создавать сетевых пользователей, управлять
ими с помощью графической утилиты администрирования и "работать" от
имени этих пользователей на тех клиентских компьютерах, которые
подключены к нашей сетевой среде. "Работать" означает входить локально
и быть распознанными (атутентифицированными) любым приложением,
использующим протокол Ice, в том числе и на другом хосте.

Для того, что это всё заработало пришлось пойти на определённую
степень интеграции в ALTLinux, поэтому ряд ключевых компонент -
правильно собранный openssl, дополненный нашим патчем для kerberos
Ice, libnss_role, модифицированный pam_control - внесены прямо в
Сизиф. Всё это можно собрать и отдельно. Но, по факту, мы сейчас не
можем просто так предложить набор tar.bz2 архивов с исходниками, из
того что пока ещё привязаны к RPM (у нас некоторые пакеты вообще
устанавливаются в секции %install), а также учесть
дитрибутиво-зависимые части вроде init-скрптов, средств и методов
настройки PAM и NSS и др.

___Текущие проблемы и задачи___

Почему же это альфа? Потому, что даже не бета... Потому, что
перечислить то, чего ещё нет, гораздо проще, чем то, что есть. А нет
пока много чего:
- Стабильного сетевого API для доступа к системным объектам и
полностью документированной базовой архитектуры;
- Иерархической базы данных, для которой и требуется стабильное API;
- Это ужасно, но нет нормальной авторизации и библиотеки, для её
использвания в сетевых сервисах. Группы проверять можно, но информации
о правах доступа на системные объекты нет пока как раз из-за
отсутствия стабильного API для доступа к иерархичесой базе данных.
- Полностью многопоточного ядра базового сервиса и организации ядра
обработки запросов на C++
- Нет локального кеша для хранения авторизационной информации в NSS модуле.
- Нет локальных политик, которые бы грамотно применили модуль ролей,
политку удалёного входа на рабочие станции, путь корневого каталога
для домашних каталогов сетевых пользователей, а также многих других
политик. Политики я планирую основывать на freedesktop стандарте и
типичном подходе, основанном на использовании протокола D-Bus.
- Нет грамотной настройки NSS. Сейчас это делают %post скрипты в
пакетах, при установке модулей в систему...
- В свете особенностей реализации GLIBC, теперь ещё и нет "чистых"
NSS-модулей не слинкованных c libstdc++ или чем-нибудь по-сложнее...
- Нет централизованной базы данных (в нашем случае это PostgreSQL) для
хранения бекендов всех базовых системных объектов и компонент.
- Нет поддержки локального входа сетевых пользователей, имена которых
совпадают с именами локальных
- Нет консольного варианта утилит управления, что снова обусловлено
отсуствием базового API - не хотелось бы их по нескольку раз
переписывать.
- Нет полноценного документирования внутренней и внешней архитектуры

Всего вышеперечисленного ещё нет, и что-то из этого как-то
проглядывается к бете, но есть и то, что к бете даже не
проглядывается:
- мультимастерная репликация (в нашем случае для распределённой среды
сетевых сервисов довольно специфичная)
- дополнительные сервисы управления почтой и групповой работы,
межсетевым экраном и др.
- интеграция с основными графическими средами (адресная книга
календарь в KDE и/или Gnome)
- сквозная аутентификация между цепочкой сервисов через forwarding тикеты
- интеграция с cifs (меня пугает, что SMB2, с ним уже не совместим...
хотя там и без этого сплошные проблемы) и прозрачное монтирование
через kerberos

____Технические подпробнсти основной проблемы____

Почему же альфа получилась такой аскетичной? Дело в том, что для
реализации высокоуровеных решений на основе среды, сама среда уже
необходима. Как компилятор для компилятора... Текущее решение - это
контур, в котором понятно что и чем нужно наполнять, а также можно
проверять как это будет работать...

Основной и ключевой проблемой в уточнении базовой архитектуры и
разработке базового API, на текущий момент, является необходимость
длительной и тщательной проработки этой самой архитектуры. Сейчас мы
вплотную к этому подошли.

Кроме того я сейчас раздумываю на вопросом учёта в архитектуре
современных особенностей, связанных с засилией LDAP-based решений и
идеологии. С одной стороны, мы не можем себе позволить использовать
LDAP как протокол, поскольку мы сознательно от него отказались. С
другой стороны мы не можем закрывать глаза на то, что первые, кому
может понадобится наше решение - это текущие пользователи LDAP,
которые захотят, по крайней мере мигрировать, а в лучшем случае
сохранить обратную совместимость в LDAP-based клиентами, которые уже
существуют и работают...

Я уже упоминал, в личных разговорах, о предпололжительном копрмиссном
варианте по созданию аналога SysDB, основанного на LDAP и
транслирующего запросы из Ice в LDAP. Тут важным является соответствие
стандартной схемы LDAP для POSIX пользователей и групп нашему базовому
API на уровне интерпретации.

___Не технические вопросы___

Не технические вопросы публикации решения. У нас есть необходимость
уточнить перед официальным анонсом следубщие вопросы:
- выбор лицензии (сейчас это GPLv2+, кое-где GPLv3)
- выбор условий приёма патчей... На freeipa.org по этому поводу есть
описание и несколько документов, гласящих о том, что содействие
(contribution) принимается на тех условиях, что все права от вложенных
затрат переходят RedHat. У нас есть некая минимальная предполагаемая
необходимость в том же самом... Поскольку, в нашем случае, чтобы
закрыть хоть какую-то часть системы основанной на библиотеке,
распрастраняемой по полному GPLv2, кроме приобретения лицензии от
ZeroC потребуется ещё и разрешение от каждого содействующего из тех,
кто внёс свой вклад в нашу систему.
В общем, бизнес модель, без такого ограничения уже чётко не
прослеживается...
Я полагаюаю, что существует бизнес модель, причём не одна, которая
может быть эффективно использована в рамках полного GPLv2, но чёткой
уверенности у меня в этом нет. Примером, как минимум, является сам Ice
и ZeroC... Но у нас всё чуть посложнее...
- выбор приоритетов в разработке системы...
- стратегический выбор возможности участия в проекте сторонних
участников и степени их участия в разработке. Кто является последней
инстанцией? Мы или коллективный разум? Мне не совсем понятно как это у
других - везде по-разному и нигде открыто не описано.


-- 
Sin (Sinelnikov Evgeny)
----------- следующая часть -----------
Вложение в формате HTML было удалено...
URL: <http://lists.etersoft.ru/pipermail/devel/attachments/20081129/6ad7bb6f/attachment.html>