Современные офисы автоматически отключают свет, если долгое время никто не ходит по помещению. В результате сосредоточенный программист оказывается в темноте. Таким образом достигаются две цели: экономится электроэнергия и программист вынужден двигаться.

Отлично, что у нас кресла на колесиках!

Скелет начинает обрастать мясом. Одной из важных частей будущего 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 будет реализована.

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

Смена погоды убивает голову.

В память о Деннисе Ритчи, Red Hat снимает шляпу.

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

Ради развлечения почитайте увлекательную инструкцию "как заставить все это взлететь на Ubuntu Oneiric"

Переехали, даже с многострадальными цветами, которые пережили -6 на Ленинградском вокзале в Москве, -16 на пероне при посадке в поезд, -24 в Выборге и уже вполне приемлемые -7 в Хельсинки. Теперь они отходят от шока в StayAt Senate на Кауппиаанкату, 5 в Катаянокке.

Огромное спасибо ykaliuta за встречу и помощь с вещами, а Оле и Ире -- за веселый день и перетягивание каната. Завтра идем по властям и осваиваемся, а во вторник едем смотреть отобранные квартиры.

Огромное спасибо также и чертовой дюжине, которая устроила проводы в пятницу. Все было чудесно, а над фотографиями Москвы я буду пускать слюну еще о-о-чень долго. Kiitos!

Думаю, что через некоторое время, когда придет контейнер с вещами, я попробую свой опыт подготовки и переезда изложить в серии заметок, если это будет интересно. Если все-таки будет -- оставляйте в этой записи свои вопросы, постараюсь ответить.

Год работы коту под хвостнапоказ: IBM официально выпустила продукт, над которым наша команда работала последнее время: Scale-out file services. Ключевыми компонентами этого решения является кластерная версия Samba и кластерная база данных для нее, CTDB. Совместно со специальной графической системой управления ресурсами (куда же без нее), с кластерной файловой системой GPFS и системой архивирования получилось решение, позволяющее объединить воедино все островки данных, которые могут присутствовать в организации. Собственно, это объединение и обыгрывается в образе продукта на страницах ibm.com:


Проект этот показателен тем, что для его реализации требовалась очень плотная и напряженная работа как внутренних, коммерческих разработчиков, так и свободных разработчиков, формально не работающих на IBM и даже не финансируемых ею для этого проекта. Собственно, в результате сообщество имеет работающий кластерный вариант CIFS, аналогов которому просто нет. Пусть на свободных кластерных файловых системах это решение не достигает той производительности, которая показывается в случае GPFS, однако самостоятельно решение "без GPFS" полностью на свободном ПО развернуть можно и со временем, я уверен, заинтересованные лица смогут доработать GFS, Lustre и другие системы до нужного уровня.

Несколько демо-роликов возможностей системы: http://samba.org/~tridge/ctdb_movies/

Сегодня прошла презентация сертификата, который ФСТЭК выдала IBM и VDEL. Теперь RedHat Enterprise Linux 4 QU1 (RHEL4 QU1) сертифицирован в России на платформе IBM (System x, BladeCenter, System p5, System i5, System z9) по ОУД4 и НДВ4.

Если не такими запутанными словами -- RHEL4 получил сертификат, соответствующий уже имеющемуся в США по сертификации Common Criteria EAL4+ на технике IBM. Несмотря на то, что в России действует сертификация по тому же ISO 15408, по которому сертифицируют и в странах с Common Criteria, уже выданные "заграничные" сертификаты здесь не признаются, так что все приходится делать с нуля.

( Немного фотографий и слов )