abbra: (Speaker Rabbit)
Отписался о прошедшей конференции SambaXP: https://vda.li/en/posts/2015/05/23/SambaXP-report/

Делать русскоязычную версию пока не хочу -- надо ли?
abbra: (Speaker Rabbit)
На последней линуксовке в году рассказал о том, что мы готовим для Fedora 21. Даже демо отработало, чего не было уже давно. Без демо-эффекта не обошлось, но в целом все получилось. Видео обещали выложить, а слайды доступны тут: http://talks.vda.li/2013/12-mlug/
abbra: (Default)
На ЛОРе анонсировали некий проект по созданию аналога Active Directory для не-Windows. Проект как проект, автору придется еще многое понять и выяснить, а также реализовать. Я обратил внимание на то, что у него "не срослось" с FreeIPA, поэтому он решил написать самостоятельно, используя тот же 389-ds и MIT krb5 в качестве базиса. Посмотрел я на патчи, зацепился взглядом за патчи к MIT krb5 KDC, которые добавляют поддержку нечувствительных к регистру идентификаторов (case-insensitive principals). Вот патч, можете оценить сами: http://relay.logotek.ru/~viking/opendirectory/patches/krb5-1.9-mscompat.patch

Зацепился я за этот по той причине, что для FreeIPAv3 я как раз делал поддержку нечувствительных к регистру идентификаторов. Вот она: http://git.fedorahosted.org/git/?p=freeipa.git;a=commitdiff;h=cbb1d626b913a7ce802150aa15bda761c9768695. Особенность задачи в том, что сравнивать "нечувствительно" идентификаторы необходимо только при обработке TGS запросов и только, если KDC разрешает это делать, указав специальный флаг. Во всех остальных случаях это чревато проблемами с безопасностью, которые Артемий игнорирует. Ну и особенность LDAP схемы для хранения базы данных идентификаторов Керберос в том, что оба атрибута krbPrincipalName и krbCanonicalName в схеме определены как EQUALITY caseExactIA5Match SUBSTR caseExactSubstringsMatch, что не дает возможности поиска в базе нечувствительно к регистру, а принудительно приводить к нижнему регистру перед сохранением нельзя, потому что это сломает софт, использующий поиск по этим атрибутам непосредственно в LDAP.

Далее автор заявляет, цитирую:
Но даже эта "связка" [FreeIPA] не позволит вам без мата или бешеной доли везения сделать например такую простую вещь как smbclient -L windowshost.company.com -k.

Что же происходит, когда мы хотим сделать упомянутую простую вещь? Read more... )
abbra: (Default)
То, о чем мы с Андреасом рассказывали на SambaXP, теперь доступно в git master Samba и выйдет в рамках Samba 4.0 beta1. Хорошая отметка после полутора лет работы, из которых я полноценно поучаствовал в последних шести месяцах.

Теперь нужно доделать куски во FreeIPA и собрать пакеты.
abbra: (Default)
PDF-ка нашего доклада на SambaXP: http://abbra.fedorapeople.org/freeipa.pdf

Доклад начнется где-то через час. Увы, выложить демо в ЖЖ пока не представляется возможным, но во время доклада мы его покажем. Надеюсь, что к июню все фрагменты будут доступны в Fedora (18?).
abbra: (Default)
Скелет начинает обрастать мясом. Одной из важных частей будущего FreeIPA v3.0 является возможность настраивать доверительные отношения с доменами Active Directory. Все это для того, чтобы пользователи FreeIPA и пользователи AD считались в обеих системам доверенными и не надо было их между собой синхронизировать. Теоретически, для того, чтобы это все работало, необходимо "лишь" использовать Kerberos. Проблема в том, что AD считает необходимым атрибутом доверительных отношений ответы по тем протоколам, которые она использует для своей внутренней деятельности. То есть, в первую очередь CLDAP и CIFS, причем так, что контекстуально информация, переданная по одному каналу (например, Kerberos протокол) должна быть понятна и в рамках запросов, использующих другие протоколы (CLDAP, LSA RPC). Это означает, что сервер Kerberos и другие службы как бы работают под одним крылом.

Для решения этой проблемы в Samba4 уже давно реализуются свой LDAP-сервер (и CLDAP в нем) и свой встроенный Kerberos-сервер (на основе Heimdal). Для того, чтобы внешние реализации LDAP и Kerberos могли бы обеспечить аналогичную функциональность, необходимо научить Samba отдавать некоторые операции наружу. В CIFS для этого теоретически существует end-point mapper, аналогичный RPC map для Sun RPC. То есть, один порт слушается smbd, а затем приходящие запросы раскидываются на обработчиков в отдельных процессах. На реализацию работающего диспетчера внешних обработчиков ушло несколько лет в Samba3, этот код стал стабильным относительно недавно.

Для того, чтобы установить доверительное отношение между двумя доменами достаточно не так и много вызовов. Создается пароль для доверительного отношения и, используя необходимые административные привилегии, отправляются два запроса LSA RPC CreateTrustedDomainEx2 -- к нашему серверу домена и к сервер доверяемого домена. Фактически, из основных требований здесь только административный доступ к чужому домену. В Samba3 в утилите net есть специальный раздел 'net rpc trust', который позволяет установить это самое доверие вручную. Утилита предполагает, что она запущена на своем же сервере с правами привилегированного пользователя, поскольку при работе ей требуется запись в некоторые базы данных Samba3, права на запись в которые выданы только руту, а открывает эти базы она самостоятельно.

В случае FreeIPA сам сервер FreeIPA, который занимается настройкой остальных сущностей, запущен как WSGI процесс, работающий под непривилегированным пользователем. При обращении к нему по XML-RPC или JSON со стороны клиента происходит делегирование имеющегося пользовательского билета Kerberos, на основании которого сервер FreeIPA и обращается к различным службам от имени этого пользователя. Службы в этом случае должны понимать авторизацию силами Kerberos, но сами по себе они работают тоже под непривилегированными пользователями, отличными от того, под которым работает WSGI процесс. Коммуникация между процессами идет средствами Unix domain sockets. То есть, использовать net rpc trust для установления доверительного отношения не получится, поскольку утилита net, запущенная из под пользователя apache, не сможет открыть напрямую соответствующую привилегированную базу, права на доступ к которой есть только у root. Впрочем, если бы они были у кого-то другого, это тоже было бы невозможно без принудительной выдачи прав на запись пользователю apache, что ломает всю стройную картину разделения прав.

У Samba4 есть автоматически генерируемые питоновые модули для довольно большой часть внутренних библиотек. Эти модули позволяют реализовать практически весь функционал 'net rpc trust' самостоятельно, обращаясь из кода на Питоне, запущенного под каким угодно пользователем, к соответствующим CIFS серверам, в том числе и локальному, работающему на том же сервере, что и FreeIPA. Беда только в том, что все эти модули не имеют нормальной документации и довольно неустойчивы к некорректным данным.

Это было введение. После некоторого количества итераций и патчей, как к FreeIPA, так и к Samba, удалось, наконец, реализовать подход, при котором все операции по установлению доверительных отношений выполняются из-под непривилегированного пользователя с применением делегированного билета администратора. Вот как выглядит простой запрос информации о домене (LSA RPC OpenInfoPolicy2), необходимый для определения параметров для заполнения запросов на установление доверительных отношений:Read more... )

Осталось дописать вызовы для установления доверительных отношений в код модуля FreeIPA и большая часть функционала для FreeIPA v3.0 будет реализована.
abbra: (Default)
На следующей неделе в Брно (Чехия) пройдет конференция разработчиков Fedora Project, http://fedoraproject.org/wiki/DeveloperConference2012. Поскольку я там буду и мой доклад будет в самом начале первого дня, появляется шанс послушать остальные выступления, не отвлекаясь на подготовку презентации и демонстраций.

Поэтому, принимаются пожелания -- что послушать и о чем впоследствии написать заметку в этом журнале?
abbra: (Default)
Выложил на http://abbra.fedorapeople.org/freeipa-extensibility.html первый драфт руководства для разработчика FreeIPA по написанию расширений. Еще полировать и полировать, но это уже что-то, что можно использовать в качестве руководства, чтобы читать имеющийся код и понимать что в нем к чему.

Смена погоды убивает голову.
abbra: (Default)
Выложил на http://abbra.fedorapeople.org/freeipa-extensibility.html первый драфт руководства для разработчика FreeIPA по написанию расширений. Еще полировать и полировать, но это уже что-то, что можно использовать в качестве руководства, чтобы читать имеющийся код и понимать что в нем к чему.

Смена погоды убивает голову.
abbra: (Default)
Картина маслом в здоровом апстриме: два сотрудника Red Hat добавляют поддержку Ubuntu поверх только что сделанной платформизации FreeIPA (делалась для добавления поддержки systemd, над которой я работаю уже третью неделю), а бывший сисадмин университета Аалто, перейдя в Canonical, берется за добавление отсутствующих и исправление присутствующих пакетов.

Ради развлечения почитайте увлекательную инструкцию "как заставить все это взлететь на Ubuntu Oneiric"
abbra: (Default)
Картина маслом в здоровом апстриме: два сотрудника Red Hat добавляют поддержку Ubuntu поверх только что сделанной платформизации FreeIPA (делалась для добавления поддержки systemd, над которой я работаю уже третью неделю), а бывший сисадмин университета Аалто, перейдя в Canonical, берется за добавление отсутствующих и исправление присутствующих пакетов.

Ради развлечения почитайте увлекательную инструкцию "как заставить все это взлететь на Ubuntu Oneiric"
abbra: (Default)
Выпустили FreeIPA 2.1. Это первый релиз с начала моей работы над проектом. В релиз вошел уже описанный ранее hbactest -- команда для тестирования работоспособности правил доступа к различным службам.

Параллельно коллеги выпустили бету RHEV 3, в описании которой The Register отметил и нас:
You can still use Microsoft's Active Directory for authentication of users and access to resources on the network, but Red Hat is also allowing customers to go all-red and use its own Enterprise IPA (which is not a hoppy beer*, but rather an identity manager based on LDAP and Kerberos).
* (IPA у британских и американских любителей пива однозначно ассоциируется с Indian Pale Ale).

Впереди работа над FreeIPA 3.0 -- помимо общих усовершенствований основу составит поддержка доверенности между доменами (cross-domain trusts). Надеюсь, что в обновление стабильной ветки (2.1) успею дописать поддержку других дистрибутивов, начатую вот здесь. В первую очередь для клиентской стороны, потому что серверная требует серьезного участия со стороны дистрибутиво-делателей.

Примером может служить недавний выпуск обновления по безопасности curl. В curl в рамках этого обновления оторвали возможность делегирования билетов Kerberos от клиента к серверу. И это правильно -- но только в том случае, когда неизвестно, можно ли этому серверу доверять. Клиент FreeIPA использует XML-RPC для доступа к серверу FreeIPA. Реализовано это средствами библиотеки xmlrpc-c, которая внутри использует libcurl для предоставления транспорта. Библиотека xmlrpc-c позволяет, если libcurl собран с поддержкой GSSAPI, делегировать имеющиеся билеты на сервер. Когда в libcurl эту поддержку "вырвали", то клиент FreeIPA (а их два -- консольный и административный интерфейс в браузере) не смог общаться с сервером.

Поскольку первоначальное исправление было связано с потенциальной проблемой с безопасностью, потребовалось доказать апстриму libcurl, что поддержку GSSAPI нужно вернуть хотя бы опицонально (дать возможность пользователю API решать, можно ли делегировать билеты или нет). Ушло несколько недель и на то, чтобы патч, возвращающий поддержку GSSAPI (уже в опциональном виде) был принят в апстрим -- libcurl очень серьезно относится к совместимости своего API с предыдущими версиями. В конце концов, все это было сделано и добавлено.

Как результат, необходимо было:
  1. собрать новую версию libcurl
  2. добавить патч к xmlrpc-c для поддержки опционально GSSAPI в libcurl
  3. исправить код, использующий xmlrpc-c, чтобы использовать опциональную поддержку GSSAPI
  4. собрать все это для Fedora 14 (обновления), 15 (обновления), 16, RHEL5 (обновления), RHEL6 (обновления)
  5. Вспомнить, что некоторые утилиты использовали утилиту curl для общения и подразумевали делегирование билетов -- значит, надо добавить поддержку этой опции в curl, собранный с новым libcurl
  6. собрать новый curl в Fedora 14 (обновления), 15 (обновления), 16, RHEL5 (обновления), RHEL6 (обновления)
Понятно, что почти все эти действия подразумевают также привязывание сборочных зависимостей и зависимостей в пакетах к правильным версиям пакетов libcurl и xmlrpc-c, поскольку иначе вся машинерия не будет работать и количество отчетов о странных ошибках в стиле "оно просто не работает" будет огромным. Эта типичная работа создателей дистрибутивов совместно с апстримными проектами -- особенно для тех случаев, когда эти проекты имеют развесистые зависимости на другие проекты. Времени на такую координацию уходит много, особенно когда ответственные мейнтейнеры в отпусках или слабо доступны.

Такие дела.
abbra: (Default)
Выпустили FreeIPA 2.1. Это первый релиз с начала моей работы над проектом. В релиз вошел уже описанный ранее hbactest -- команда для тестирования работоспособности правил доступа к различным службам.

Параллельно коллеги выпустили бету RHEV 3, в описании которой The Register отметил и нас:
You can still use Microsoft's Active Directory for authentication of users and access to resources on the network, but Red Hat is also allowing customers to go all-red and use its own Enterprise IPA (which is not a hoppy beer*, but rather an identity manager based on LDAP and Kerberos).
* (IPA у британских и американских любителей пива однозначно ассоциируется с Indian Pale Ale).

Впереди работа над FreeIPA 3.0 -- помимо общих усовершенствований основу составит поддержка доверенности между доменами (cross-domain trusts). Надеюсь, что в обновление стабильной ветки (2.1) успею дописать поддержку других дистрибутивов, начатую вот здесь. В первую очередь для клиентской стороны, потому что серверная требует серьезного участия со стороны дистрибутиво-делателей.

Примером может служить недавний выпуск обновления по безопасности curl. В curl в рамках этого обновления оторвали возможность делегирования билетов Kerberos от клиента к серверу. И это правильно -- но только в том случае, когда неизвестно, можно ли этому серверу доверять. Клиент FreeIPA использует XML-RPC для доступа к серверу FreeIPA. Реализовано это средствами библиотеки xmlrpc-c, которая внутри использует libcurl для предоставления транспорта. Библиотека xmlrpc-c позволяет, если libcurl собран с поддержкой GSSAPI, делегировать имеющиеся билеты на сервер. Когда в libcurl эту поддержку "вырвали", то клиент FreeIPA (а их два -- консольный и административный интерфейс в браузере) не смог общаться с сервером.

Поскольку первоначальное исправление было связано с потенциальной проблемой с безопасностью, потребовалось доказать апстриму libcurl, что поддержку GSSAPI нужно вернуть хотя бы опицонально (дать возможность пользователю API решать, можно ли делегировать билеты или нет). Ушло несколько недель и на то, чтобы патч, возвращающий поддержку GSSAPI (уже в опциональном виде) был принят в апстрим -- libcurl очень серьезно относится к совместимости своего API с предыдущими версиями. В конце концов, все это было сделано и добавлено.

Как результат, необходимо было:
  1. собрать новую версию libcurl
  2. добавить патч к xmlrpc-c для поддержки опционально GSSAPI в libcurl
  3. исправить код, использующий xmlrpc-c, чтобы использовать опциональную поддержку GSSAPI
  4. собрать все это для Fedora 14 (обновления), 15 (обновления), 16, RHEL5 (обновления), RHEL6 (обновления)
  5. Вспомнить, что некоторые утилиты использовали утилиту curl для общения и подразумевали делегирование билетов -- значит, надо добавить поддержку этой опции в curl, собранный с новым libcurl
  6. собрать новый curl в Fedora 14 (обновления), 15 (обновления), 16, RHEL5 (обновления), RHEL6 (обновления)
Понятно, что почти все эти действия подразумевают также привязывание сборочных зависимостей и зависимостей в пакетах к правильным версиям пакетов libcurl и xmlrpc-c, поскольку иначе вся машинерия не будет работать и количество отчетов о странных ошибках в стиле "оно просто не работает" будет огромным. Эта типичная работа создателей дистрибутивов совместно с апстримными проектами -- особенно для тех случаев, когда эти проекты имеют развесистые зависимости на другие проекты. Времени на такую координацию уходит много, особенно когда ответственные мейнтейнеры в отпусках или слабо доступны.

Такие дела.

Profile

abbra: (Default)
abbra

April 2016

S M T W T F S
     12
3456789
1011121314 1516
17181920212223
24252627282930

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Aug. 18th, 2017 04:57 am
Powered by Dreamwidth Studios