Здравствуйте,<br>
<br>
спешу сообщить, что сегодня вечером были завершены последние<br>
приготовления перед началом публичной работы на нашим проектом.<br>
Минимальная часть материалов уже выложена на странице<br>
<a href="http://www.tartarus.ru/wiki/Docs" target="_blank">http://www.tartarus.ru/wiki/Docs</a><br>
<br>
Оглядываясь назад, я просто поражаюсь тому насколько много было<br>
приложено усилий, для казалось бы простого развёртывания базового<br>
набора пакетов. Ещё более печально осознавать тот факт, что до выхода<br>
беты, мы даже не готовы принимать широкий набор отчётов об ошибках,<br>
поскольку объёмы оставшейся работы сами по себе необычайно велики.<br>
<br>
___Краткое описание___<br>
<br>
Что же собой представляет альфа? Это набор серверных и клиентских<br>
компонентов, позволяющих создавать сетевых пользователей, управлять<br>
ими с помощью графической утилиты администрирования и "работать" от<br>
имени этих пользователей на тех клиентских компьютерах, которые<br>
подключены к нашей сетевой среде. "Работать" означает входить локально<br>
и быть распознанными (атутентифицированными) любым приложением,<br>
использующим протокол Ice, в том числе и на другом хосте.<br>
<br>
Для того, что это всё заработало пришлось пойти на определённую<br>
степень интеграции в ALTLinux, поэтому ряд ключевых компонент -<br>
правильно собранный openssl, дополненный нашим патчем для kerberos<br>
Ice, libnss_role, модифицированный pam_control - внесены прямо в<br>
Сизиф. Всё это можно собрать и отдельно. Но, по факту, мы сейчас не<br>
можем просто так предложить набор tar.bz2 архивов с исходниками, из<br>
того что пока ещё привязаны к RPM (у нас некоторые пакеты вообще<br>
устанавливаются в секции %install), а также учесть<br>
дитрибутиво-зависимые части вроде init-скрптов, средств и методов<br>
настройки PAM и NSS и др.<br>
<br>
___Текущие проблемы и задачи___<br>
<br>
Почему же это альфа? Потому, что даже не бета... Потому, что<br>
перечислить то, чего ещё нет, гораздо проще, чем то, что есть. А нет<br>
пока много чего:<br>
- Стабильного сетевого API для доступа к системным объектам и<br>
полностью документированной базовой архитектуры;<br>
- Иерархической базы данных, для которой и требуется стабильное API;<br>
- Это ужасно, но нет нормальной авторизации и библиотеки, для её<br>
использвания в сетевых сервисах. Группы проверять можно, но информации<br>
о правах доступа на системные объекты нет пока как раз из-за<br>
отсутствия стабильного API для доступа к иерархичесой базе данных.<br>
- Полностью многопоточного ядра базового сервиса и организации ядра<br>
обработки запросов на C++<br>
- Нет локального кеша для хранения авторизационной информации в NSS модуле.<br>
- Нет локальных политик, которые бы грамотно применили модуль ролей,<br>
политку удалёного входа на рабочие станции, путь корневого каталога<br>
для домашних каталогов сетевых пользователей, а также многих других<br>
политик. Политики я планирую основывать на freedesktop стандарте и<br>
типичном подходе, основанном на использовании протокола D-Bus.<br>
- Нет грамотной настройки NSS. Сейчас это делают %post скрипты в<br>
пакетах, при установке модулей в систему...<br>
- В свете особенностей реализации GLIBC, теперь ещё и нет "чистых"<br>
NSS-модулей не слинкованных c libstdc++ или чем-нибудь по-сложнее...<br>
- Нет централизованной базы данных (в нашем случае это PostgreSQL) для<br>
хранения бекендов всех базовых системных объектов и компонент.<br>
- Нет поддержки локального входа сетевых пользователей, имена которых<br>
совпадают с именами локальных<br>
- Нет консольного варианта утилит управления, что снова обусловлено<br>
отсуствием базового API - не хотелось бы их по нескольку раз<br>
переписывать.<br>
- Нет полноценного документирования внутренней и внешней архитектуры<br>
<br>
Всего вышеперечисленного ещё нет, и что-то из этого как-то<br>
проглядывается к бете, но есть и то, что к бете даже не<br>
проглядывается:<br>
- мультимастерная репликация (в нашем случае для распределённой среды<br>
сетевых сервисов довольно специфичная)<br>
- дополнительные сервисы управления почтой и групповой работы,<br>
межсетевым экраном и др.<br>
- интеграция с основными графическими средами (адресная книга<br>
календарь в KDE и/или Gnome)<br>
- сквозная аутентификация между цепочкой сервисов через forwarding тикеты<br>
- интеграция с cifs (меня пугает, что SMB2, с ним уже не совместим...<br>
хотя там и без этого сплошные проблемы) и прозрачное монтирование<br>
через kerberos<br>
<br>
____Технические подпробнсти основной проблемы____<br>
<br>
Почему же альфа получилась такой аскетичной? Дело в том, что для<br>
реализации высокоуровеных решений на основе среды, сама среда уже<br>
необходима. Как компилятор для компилятора... Текущее решение - это<br>
контур, в котором понятно что и чем нужно наполнять, а также можно<br>
проверять как это будет работать...<br>
<br>
Основной и ключевой проблемой в уточнении базовой архитектуры и<br>
разработке базового API, на текущий момент, является необходимость<br>
длительной и тщательной проработки этой самой архитектуры. Сейчас мы<br>
вплотную к этому подошли.<br>
<br>
Кроме того я сейчас раздумываю на вопросом учёта в архитектуре<br>
современных особенностей, связанных с засилией LDAP-based решений и<br>
идеологии. С одной стороны, мы не можем себе позволить использовать<br>
LDAP как протокол, поскольку мы сознательно от него отказались. С<br>
другой стороны мы не можем закрывать глаза на то, что первые, кому<br>
может понадобится наше решение - это текущие пользователи LDAP,<br>
которые захотят, по крайней мере мигрировать, а в лучшем случае<br>
сохранить обратную совместимость в LDAP-based клиентами, которые уже<br>
существуют и работают...<br>
<br>
Я уже упоминал, в личных разговорах, о предпололжительном копрмиссном<br>
варианте по созданию аналога SysDB, основанного на LDAP и<br>
транслирующего запросы из Ice в LDAP. Тут важным является соответствие<br>
стандартной схемы LDAP для POSIX пользователей и групп нашему базовому<br>
API на уровне интерпретации.<br>
<br>
___Не технические вопросы___<br>
<br>
Не технические вопросы публикации решения. У нас есть необходимость<br>
уточнить перед официальным анонсом следубщие вопросы:<br>
- выбор лицензии (сейчас это GPLv2+, кое-где GPLv3)<br>
- выбор условий приёма патчей... На <a href="http://freeipa.org/" target="_blank">freeipa.org</a> по этому поводу есть<br>
описание и несколько документов, гласящих о том, что содействие<br>
(contribution) принимается на тех условиях, что все права от вложенных<br>
затрат переходят RedHat. У нас есть некая минимальная предполагаемая<br>
необходимость в том же самом... Поскольку, в нашем случае, чтобы<br>
закрыть хоть какую-то часть системы основанной на библиотеке,<br>
распрастраняемой по полному GPLv2, кроме приобретения лицензии от<br>
ZeroC потребуется ещё и разрешение от каждого содействующего из тех,<br>
кто внёс свой вклад в нашу систему.<br>
В общем, бизнес модель, без такого ограничения уже чётко не прослеживается...<br>
Я полагаюаю, что существует бизнес модель, причём не одна, которая<br>
может быть эффективно использована в рамках полного GPLv2, но чёткой<br>
уверенности у меня в этом нет. Примером, как минимум, является сам Ice<br>
и ZeroC... Но у нас всё чуть посложнее...<br>
- выбор приоритетов в разработке системы...<br>
- стратегический выбор возможности участия в проекте сторонних<br>
участников и степени их участия в разработке. Кто является последней<br>
инстанцией? Мы или коллективный разум? Мне не совсем понятно как это у<br>
других - везде по-разному и нигде открыто не описано.<br>
<font color="#888888"><br>
<br>
</font>-- <br>Sin (Sinelnikov Evgeny)<br>