Speaker Rabbit

abbra


CIFS: curious information funneled sometimes


Previous Entry Share Next Entry
Как взаимодействуют проекты и компании
Speaker Rabbit
abbra
Меня всегда интересовало, могут ли люди договариваться в сложных ситуациях -- часто приходилось видеть как раз обратное. Однако иногда бывают и положительные примеры.


Вот пример Самбы. Для реализации Active Directory Services в Samba 4 необходимо довольно тесное взаимодействие между серверами DCE/RPC, WINS, DNS, Kerberos V, LDAP, DHCP. Первые два -- традиционные предоставляемые самой Самбой куски. Kerberos V имеет две свободные реализации -- MIT Krb5 и Heimdal и одну полуживую в виде GNU Shishi. С LDAP обычно еще хуже -- модельная свободная реализация одна, с окончательным открытием кода RedHat Directory (бывший Netscape Directory) будет фактически две. С DNS/DHCP ситуация похожая на LDAP не с точки зрения реализации, а с точки зрения эксплуатации.

При этом довольно тесное взаимодействие подразумевает возможность выполнения запросов со стороны клиента ADS (обычно это Windows XP или Samba 4) таким образом, что один фрагмент запроса выполняется посредством одного протокола/набора протоколов (DCE/RPC), затем результат этой операции “забирается” посредством другого протокола (например, LDAP или CLDAP), следующий фрагмент запроса опять выполняется посредством какого-нибудь еще протокола и так далее, вперемешку. Чтобы представить объем, типичное присоединение машины с Windows XP к домену в дереве ADS обходится в 600-800 сетевых пакетов-запросов в зависимости от того, участвует ли в этом процессе Kerberos 5 или нет (да, как оказалось, можно все выполнить и отключив Kerberos 5 на этой стадии).

Таким образом, получается, что идеальным с точки зрения реализации будет разделение одного и того же контекста соединения на стороне сервера всеми участвующими процессами. Естественно, что добиться этого от разнородных процессов и проектов крайне сложно. Типичный подход -- попытка хранить все данные в одной общедоступной базе данных, изменение которой видно всем участникам сразу и при этом существует некоторая система семафоров, позволяющих не наступать друг другу на ноги в реальной работе. Подход типичен в том смысле, что именно его и начинают обсуждать проекты -- в данном случае “наступания” наиболее актуальны для KDC, SMBD и SLAPD (сервер Kerberos 5, сервер DCE/RPC и сервер LDAP).

Увы, как оказалось, не все возможно сделать при разделенном запуске процессов. В случае MIT Krb5 пока невозможно вклиниваться на всех необходимых этапах авторизации, а не только на этапе хранения информации -- последний удалось абстрагировать руками Novell (DAL -- Data Abstraction Layer -- планируется включить в MIT krb5 1.4 и старше), а вот с остальными уровнями пока сложно. Да и противодействие хардкорных пользователей MIT KRB5 в лице Стэнфордского университета и некоторых американских вояк пока еще велико.

Аналогичная проблема наблюдается и с OpenLDAP: требуется достаточно много модификаций, несовместимых с тем, что требует от LDAP-сервера стандартная спецификация LDAPv3. Так уж получилось у Microsoft и приходится с этим иметь дело. Фактически, в текущей архитектуре нельзя реализовать такую сборку OpenLDAP, которая работала бы одновременно и как полностью соответствующий LDAPv3-сервер, и как ADS-совместимый LDAP-сервер.

Когда нет возможности договориться, приходится делать модельные реализации самим. Так вышло с LDAP в Samba 4 -- LDAP-клиент полностью свой, CLDAP-сервер тоже, как и LDAP-сервер, совместимый с ADS. CLDAP-сервера, кстати, в OpenLDAP/RH Directory нет и скорее всего не будет, поскольку этот специфический зверь (connectionless LDAP) фактически нужен только в ADS, хотя и представляет из себя интересный вариант функционального языка, где LDAP-запросы выступают в роли вызова удаленных процедур.

К счастью, в случае Kerberos 5, когда не удалось временно договориться с MIT, удалось добиться приемлемого сотрудничества с Heimdal. Samba 4 фактически может использовать Heimdal самых последних недель (то, что выйдет под именем 0.7) в виде библиотеки, выступая в этом случае в роли Key Distribution Center и подменяя все механизмы общения с сетью в Heimdal KDC на свои. Этот KDC продолжает быть рабочим для Unix-клиентов, но информация в нем становится доступной и для ADS. Вообщем, сплошная благодать на текущем этапе.

При чем тут первоначальная тема взаимодействия? А вот при чем: думаю, что вопрос с MIT тем или иным образом все же будет решен -- Novell на сегодня финансирует довольно большой объем работ как по MIT Krb5, так и по Samba (3 и 4). Достаточно сказать, что в Novell за последние полтора месяца теперь работают четыре человека из Samba Team, включая Jeremy Allison и Andrew Bartlett. Последний как раз и отвечает за авторизационные подсистемы в Самбе, добился впечатляющей интеграции с Heimdal и во многом переубедил MIT-овцев, работающих в Novell над совершенствованием MIT Krb5. Его текущие мысли по поводу того, что требуется от сервера Kerberos 5 для реализации ADS представлены здесь: http://samba.org/ftp/unpacked/samba4/source/auth/kerberos/kerberos-notes.txt -- документ этот живой и меняется постоянно.

Чтобы дополнить межпроектную картину в этой ситуации, Love Hörnquist Åstrand, один из основных разработчиков Heimdal, с недавних пор также входит в Samba Team, где занимается тем, что поддерживает необходимые расширения Heimdal в минимальном состоянии -- так, чтобы патч-разница был как можно меньше и тривиальнее.

Вообщем, межпроектное взаимодействие в реальности.

  • 1
Это же сколько всего пришлось раскурочить только чтобы поддержку AD реализовать.

  • 1
?

Log in

No account? Create an account