Category: it

Speaker Rabbit

Охлох по-русски

Есть в России и такое: https://www.facebook.com/alena.vladimirskaya/posts/3791109369189

Для нежелающих смотреть в FB, дама-хэдхантер спрашивает, почему Хабр не сделает свой github для русскоязычных программистов "из провинции" и не монетизирует статистику их взаимодействия.

Ей там многое написали, включая "вон из профессии тех, кто не знает что такое и как пользоваться github", но меня интересует другой момент.

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

Если этот ресурс будет предоставлять коммерческий хостинг для проектов тех индивидуалов, которые не хотят публиковать свой исходный код, то на основании чего ресурс будет использовать статистику коммитов в такие проекты и непубличную тусовку вокруг них для сводничества? Понятно, что условия хостинга можно в том или ином виде определить и заложить в рамки договора, но будет ли доверие со стороны потенциальных пользователей системе хостинга, чья основная задача будет состоять в накоплении информации, которую они сознательно хотят скрывать, раз уж выбрали непубличность своего репозитария, а, следовательно, и непубличность взаимодействий с ним.

Чем такой ресурс/проект может завоевать признание и доверие непубличных пользователей?
Speaker Rabbit

Заначка

Согласно пункту 3.1.5.16 спецификации MS-FSA, "объектное хранилище ДОЛЖНО выставить Open.File.SecurityDescriptor в InputBuffer". Как результат, том NTFS должен хранить как есть данные, записанные приложением в DACL файла. Размер одной записи в ACL -- до 64Кб. Если учесть, что обычными средствами увидеть содержимое этих дополнительных записей невозможно, то вышеописанное представляет собой идеальный способ сокрытия данных на томах WinFS.

Такие дела, в изложении Микрософт: http://lists.samba.org/archive/samba-technical/2012-April/082770.html

Интересно, в специализированном ПО для forensic analysis этот случай учитывается? Если нет, то когда будет учитываться? На постсоветском пространстве эксперты соответствующего профиля о таком знают? А свядомые догадываются?

Теперь это реализовывать в Самбе... Bug for bug, feature for feature. :)
Speaker Rabbit

trust_fetch(): SUCCESS

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

Осталось дописать вызовы для установления доверительных отношений в код модуля FreeIPA и большая часть функционала для FreeIPA v3.0 будет реализована.
Speaker Rabbit

Бесконечная автоматизация

Конечные автоматы бывают разные. Есть генераторы исходного кода по схемам-описаниям, есть табличные исполнители, а есть неявные конечные автоматы. Они сложнее, но читаются как детективный роман -- со множеством веток предположений и откатов на исходные позиции, а так же с необходимостью найти на них время. Неявные конечные автоматы в разных проектах -- это то, что одновременно удерживает от прихода новых участников (нужно уметь раскручивать детективный сценарий) и позволяет глубже понять, что и как задумывалось. Разгадав очередной автомат, получаешь вполне осязаемое удовлетворение.
Collapse )
Speaker Rabbit

HBAC в SSSD/FreeIPA (часть 2)

Написал модуль для тестирования HBAC:
https://www.redhat.com/archives/freeipa-devel/2011-July/msg00375.html

1. Симулируем доступ к службе, используя все включенные правила в IPA:
[root host0 ~]# ipa  hbactest --user=a1a --srchost=foo --host=bar --service=ssh
--------------------
Access granted: True
--------------------

2. Симулируем доступ к службе, используя все включенные правила + указанные в --rules (возможно отключенные):
[root host0 ~]# ipa  hbactest --user=a1a --srchost=foo --host=bar --service=ssh --rules=my-second-rule
--------------------
Access granted: True
--------------------

3. Симулируем доступ, используя только правила, указанные в --rules (--validate ограничивает список правил только теми, что в --rules):
[root host0 ~]# ipa  hbactest --user=a1a --srchost=foo --host=bar --service=ssh --rules=my-second-rule,new-rule --validate
--------------------
Access granted: True
--------------------
  Passed rules: new-rule
  Denied rules: my-second-rule

4. Симулируем доступ и получаем подробный отчет, какие из включенных в IPA правил сработали:
[root host0 ~]# ipa  hbactest --user=a1a --srchost=foo --host=bar --service=ssh  --validate
--------------------
Access granted: True
--------------------
  Passed rules: allow_all
  Denied rules: my-second-rule, my-third-rule, myrule

--validate включает детальный показ результатов применения правил, а если используется вместе с --rules, то ограничивает список проверяемых правил только указанными в --rules.

По всей видимости, --validate нужно переименовать во что-то иное (--detail?) и перекрыть --all для указания того, что к --rules надо добавить все включенные правила в IPA, иначе логика не очень ясна, по крайней мере, коллега уже успел ошибиться при тестировании.
Speaker Rabbit

HBAC в SSSD/FreeIPA

Немного о том, чем я сейчас занят. Записи с тегом "заметки-на-полях" -- моя внутренняя кухня, не предназначенная для активного обсуждения и цитирования вне этого ЖЖ. Мой мозг пока с трудом привыкает к большому объему нового (и вспоминанию старого) кода, поэтому заметки скорее для себя, чем разъяснения для других. Если объем превысит выделяемое самим собой время, я просто отключу комментарии, чтобы не отвлекаться, не обессудьте.

Collapse )
Speaker Rabbit

Контейнеры

Бойцы из НезлойИмперии пытаются родить новый формат изображений, WebP. За основу взят кодек VP8 и контейнер RIFF. Желание поскорее использовать VP8 для замены JPEG так велико, что бойцы совсем забыли вторую важную часть любого внятного формата изображений: хранение мета-данных. Я даже могу представить, что ими двигало: предложенные четыре блока мета-данных ICMT, ICOP, IART, INAM без какой-либо спецификации содержимого (кодировка, ожидания по структуре, ...) явно базируются на аналогичных блоках из спецификации PNG.

Если посмотреть на проблему серьезнее, то EXIF+IPTC+XMP сегодня описывают порядка нескольких сотен тегов. Если для каждого из них выделять отдельный блок в контейнере, указывать точные структуры хранения и кодирования, то загнутся реализаторы, а формат просто никто не будет внятно поддерживать.

Игнорирование мета-данных в изображениях в данном контексте отражает общий подход клиентской стороны гугловцев. Лишь относительно недавно в Picasa появилась полноценная поддержка XMP. Параллельного слияния тегов из разных контейнеров у них нет до сих пор (например, title/description могут храниться во всех трех указанных выше типах хранилищ мета-данных в одном изображении -- что делать, если пользователь хочет изменить title, какое из хранилищ будет приоритетным, как изменить данные в остальных?). Теперь Хром хочет ускориться за счет уменьшения объема перекачиваемых данных (это единственная фича, которую объявляют стоящей для себя разработчики WebP). Для браузеров мета-данные в изображениях бесполезны, API доступа к таким данным в рамках спецификаций W3C просто отсутствуют. Вот и рождается очередной контейнер-недоконтейнер. WebM, кстати, тоже поддержку мета-данных зажилил.
Speaker Rabbit

Видео (1)

Построение экранного изображения, в принципе, довольно примитивное занятие. Если отбросить все безумные подробности, X11 и OpenGL, то дело сводится к наличию некоторого количества фрагментов памяти (буферов), имеющих разную структуру (глубина цвета, цветовое пространство, упаковка пикселов) и к механизму смешивания этих буферов. В конце концов, в контроллер дисплея попадает один или несколько буферов, представляющих растр, которые по довольно простым правилам смешиваются между собой. Скажем, в N900, таких аппаратных буферов три. Называются они планами -- графический и два видео-плана -- и по сути дела ничего, кроме этих планов в N900 и не важно. То, что имеется еще "трехмерный ускоритель", ситуацию особенно не меняет -- в конце концов, трехмерный ускоритель выдает "на гора" растровый буфер, который используется для заполнения графического плана.

Collapse )

Получилось довольно большое введение. Зачем оно надо -- в следующей заметке.
Speaker Rabbit

(no subject)

Для завтрашнего мероприятия в Мариотт Гранд, гоняли сегодня тестики по кластерной самбе. Простейший кластер из двух узлов, (2х1Гбит/с, один в пользовательскую сеть, один -- служебный), полка с десятью 15К RPM дисками. Внутре -- GPFS, поверх которой крутится кластерная Самба 3.2.3 в рамках IBM Scale out File Services. Все это воткнуто в Active Directory на базе Windows 2003 Server, так что с системой могут работать в принципе любые клиенты -- от линуксовых до самых распоследних вист.

Берем четыре клиентских машины, каждая с 1Гбит/с, запускаем на них smbtorture из Samba4 с тестом BENCH-NBENCH, который имитирует "отраслевой стандарт" NetBench. Сам скрипт для теста -- чтение блоками по 64Кб из файлов размером в 1Гб. Строка запуска:
bin/smbtorture //filer/test -UПользователь%Пароль BENCH-NBENCH \
     --loadfile=loadfiles/read_1G_64k_at_a_time.load \
     -t 100 --num-progs 4 --option=torture:readonly=yes

То есть, запускаем на каждом клиенте по 4 параллельных процесса, которые читают блоками по 64Кб из файлов рамером в 1Гб и даем 100 секунд на выполнение. BENCH-NBENCH грузит скрипт, форкается и запускает четыре процесса обработки скрипта. Через некоторое время "прогрева" (пока процессы соединятся с серверами...), начинают идти результаты. Указанный адрес сервера (//filer) на самом деле представляет собой "имя сервера" в CIFS. Ему соответствуют разные IP узлов нашего кластера в DNS, так что клиенты получают их при разрешении имени в режиме round-robin.

Поскольку запускал я тесты руками, то между запусками были временные разрывы. Так что какой-то из клиентов успел "отъесть" больше полосы пропускания, чем другие. У нас теоретически 4Гбит/с от клиентов (1Гбит/с от каждого) и 2Гбит/с от кластера. Между коммутаторами настроено объединение каналов -- по 4 1Гбит/с порта с каждой стороны, то есть теоретически мы могли бы "прокинуть" 4Гбит/с, если бы со стороны кластера они были. Каждый клиент мог "съесть" свой 1Гбит/с, если бы получилось.

Тест воспроизводит типичную картину "голода" в офисе, когда возможностей файлового сервера не хватает на всех клиентов из-за ограничений полосы пропускания. В данном случае важным становится эффективное распределение нагрузки между узлами кластера. То есть, в обычном офисном случае у нас файловый сервер на самом деле один и максимум, что мы можем сделать -- это "съесть" его сетевые возможности. С кластерной самбой становится возможным "размазать" этот поток запросов и ответов между несколькими серверами одновременно, а не помещать все сетевые карты в один сервер. Когда-нибудь возможности одного сервера закончатся -- либо по пропускной способности его сетевой подсистемы, либо по затратам на память при обслуживании клиентов (Самба 3.2 требует приблизительно 500-700Кб служебных данных на клиента и порядка 5-7Мб кода на процесс, что транслируется в реальности в 400-500 одновременных пользователей на 1Гб ОЗУ сервера). И если память нарастить еще можно, то слоты для сетевых карт закончатся довольно быстро, пусть и с многопортовками.

В результате, мы получаем приблизительно следующую картину для четырех клиентов:
$ cat client?-1.log|grep Throughput
Throughput 38.7363 MB/sec
Throughput 38.8454 MB/sec
Throughput 100.868 MB/sec
Throughput 40.1211 MB/sec


Видно, что один из клиентов "сообразил" раньше и захватил всю доступную себе полосу пропускания -- из 1Гбит/с ему было доступно 100.868 МБайт/с, или 80.69% канальной емкости. Остальные запустились более-менее одновременно и потому распределили между собой оставшийся объем канала. Суммарно вышло 218.5708МБайт/с из доступных 2Гбит/с, которые кластер мог отдать. Или 87.42% канальной емкости.

Забавно посмотреть, что творилось в это время в кластере:Collapse )
Speaker Rabbit

О лоралитиках

ЛОР добрался до заметки Эндрю Бартлетта о сентябрьской сессии по тестированию Samba4 вместе с Microsoft.

Microsoft присоединяется к разработке Samba
Как сообщили участники проекта Samba, разработчики Active Directory из Microsoft начали работу по улучшению Samba в плане совместимости с Active Directory и протоколом CIFS. В качестве первого шага они передали необходимую документацию и спецификации на протоколы.

Первые шаги в данном направлении были сделаны Microsoft на конференции Samba eXPerience 2008. Где были представлены доклады: "Model-Based Quality Assurance of the SMB2 Protocol Document" и "SMB Version 2: Scaling From Kilobits to Gigabits".


Ни заголовок новости, ни содержимое первого абзаца не отражают реальности. Во-первых, Microsoft не присоединяется к разработке Samba. Microsoft принуждена судом к открытию спецификаций на протоколы, по которым взаимодействуют между собой сервер рабочих групп и его клиенты. Документация на эти протоколы, полученная Samba Team в декабре 2007, безусловно полезна, но не надо переоценивать деятельность коммерческой компании, принужденной к этому юридической системой. То, что в дальнейшем она открыла еще больше спецификации на несвязанные темы, не означает, что компания фундаментально изменилась.

С другой стороны, в Microsoft последнее десятилетие присутствует системный кризис в разработке ключевых компонент операционной системы. В частности, долгое время отдельные элементы (стек протоколов CIFS, драйвер NTFS) не имели нормальной внутренней документации, кроме кода, приходилось прибегать к внешним сотрудникам для получения приемлемых результатов (документирование NTFS в 1998, "археология CIFS" в 2008). Сам код был плохо приспособлен к изменяющемуся состоянию внешней среды (рост применений в высоколатентных сетях, увеличение проблем с безопасностью в сетевой инфраструктуре). Поэтому к апрелю 2008, к SambaXP, Microsoft подошел с необходимостью реинжиниринга собственных процессов разработки, тестирования и проектирования сложных компонент ОС.

Встречи и дискуссии во время SambaXP и последующих встреч, одну из которых описывает Эндрю Бартлетт, идут на пользу обеим сторонам, это очевидно. Не нужно только делать из этого выводы в стиле "Microsoft присоединяется к разработке Samba". Пока единственным практическим взносом в разработку Samba от Microsoft является man-страница smbtorture в Samba4. Именно потому, что это самый важный компонент Samba для Microsoft -- в методологии тестирования CIFS взгляды Samba Team и Microsoft существенно расходятся и лидирует тут совсем не Microsoft.

Открытие документации -- это попытка убить зайцев на многих фронтах, из которых вынужденная помощь конкурентам является скорее меньшим злом, чем выигрыш от достижений. Crowd-sourcing по документации (Microsoft обязана решением суда отвечать в четко отведенное время на запросы лицензиатов WSPP, а "дыр" в документации много), перекрестное опыление в методологии тестирования ПО, методах оптимизации систем для высоколатентных соединений важны и стоят тех средств, которые они вкладывают (в июньском отчете минюста США говорилось о группе сотрудников Microsoft и контракторов более 700 человек, занятых на этом фронте).

Так что "в качестве первого шага" стоит скорее рассматривать не передачу документации, а отказ от аппеляции. И не забывать, что публичные коммерческие компании прежде всего направлены на увеличение дохода держателей своих акций, а не помощь своим конкурентам. Последнее играет важную роль до тех пор, пока помогает оптимизировать извлечение прибыли. Подтверждением может служить и практическая польза задавания вопросов через публичный форум разработчиков, где многие вопросы остаются без ответов значительно дольше, чем хотелось бы, в отличие от рассылки для сабконтракторов PFIF. Рынок IT сегодня сильно отличается от черно-белой картины, которая существует в головах подтверждающих новости на ЛОРе.