Альтернатива OpenLDAP

[Игорь Вершинин]

Наш техотдел на выходных потестировал разные LDAP-сервера (на наших примерах, никаких общих тестов, только то, что нас интересует). Результаты, в принципе, не сильно удивили, но заставили призадуматься. Сравнивались OpenLDAP (OL) и Fedora Directory Server (FDS) - а это будущий RedHat Directory Server. С секундомером особенно никто не сидел, но тем не менее...

1. Скорость авторизации пользователя (пользователи в LDAP, авторизуемся с Вин-станции через Самбу). Отставание OL в ряде случаев. Визуально FDS быстрее. Было проведено 30 логинов с разных станций под разными пользователями... Видимо проблемы в кэшировании запросов, хотя....

2. Занесение 100 000 записей пользователей в базу. OL нервно курил, в несколько раз быстрее оказался FDS. Заносилось все из LDIF-файла. Пользователи создавались из ... обработки 1С . Просто сформировали текстовый файл, чтобы руками не набивать.

3. Администрирование. Что-то калечное встроенное есть у FDS, обещают сделать полноценную администрилку. Пока нет. У OL никогда ничего подобного и не было. Похоже, и не будет. Сейчас и то, и то приходится руками и сторонними утилитами править.

4. Краш-тест. В обоих случаях все ставилось на ext3. Работает сервер и вдруг пропало питание... OL из 20 13 раз требовал ручного восстановления БД. Но вроде после восстановления никаких сбоев не наблюдалось. С FDS больше повезло. Там само собой все восстанавливалось. Опять-таки ничего не пропало.

Понятно, что эти пионерские тесты ничего особо и не показывают. Сотры просто решили посравнивать, сделали это как могли (что в голову пришло). Но результаты несколько удивили. Так как истоки обоих серверов лежат в Netscape. По функционалу сервера особо не сравнивали, так как то, что нам необходимо, есть и там, и там.

Еще в FDS есть ACL, по аналогии с eDir, т.е. in-tree, а не в текстовом конфиге. Но вроде как это есть и в OL. Но без средств администрирования это как-то бесполезно.

В общем пока сидим на OL (так исторически сложилось, когда уходили с NW - это первое бесплатное, что подвернулось из нормального и документированного), но похоже это ненадолго. Как только выйдет релиз 1.1 FDS, уйдем на него. Все-таки скорость, все-таки управляемость, все-таки похожесть на eDir (к чему привыкли за время работы с NW), все-таки большая стабильность. Меня еще, кстати, радуют темпы развития и мощная финансовая поддержка FDS (последнее, со стороны RedHat). С OL мне кажется (может я и ошибаюсь) как-то все медленно и застойно...

[Андрей Фисенко]

данные каталоги на серверах, более одного. Репликацию, синхронизацию, партишионинг...
Ну так, в самых утрированных вариантах. Пороняйте один из двух серваков, ну, все, как обычно в жизни... 100 000 юзверей наверняка не на одном серваке будут крутиться...

[Андрей Тр. aka RH]

Еще ради интереса можно посмотреть размер базы и его рост как функцию от количества объектов.

[Михаил Григорьев]

Меня еще, кстати, радуют темпы развития и мощная финансовая поддержка FDS (последнее, со стороны RedHat). С OL мне кажется (может я и ошибаюсь) как-то все медленно и застойно...

Как вы правильно заметили, именно мощная финансовая поддержка FDS и помогает в его развитии, если бы так же проспонсировали разработчиков OL, то наверняка бы и они потрудились над быстродействием и системой поднятия базы после холодного останова сервера.

[Михаил Григорьев]

Еще ради интереса можно посмотреть размер базы и его рост как функцию от количества объектов.

Кстате говоря о контроле роста бызы, в OL до версии 2.3.x как раз контроля то и небыло, но уже наверно с год если не больше это реализовали и очень неплохо! база получается довольно компактной. Раньше большой объем в ней занимал журнал транзакций и именно его и нужно было чистить.

[Игорь Вершинин]

На эти выходные дал своим задание проверить объемы баз у FDS и OL на одном и том же количестве объектов....

Кстати, eDir доделали, чтобы она могла подменять Active Directory? Кажется, ходила такая информация....

[Иван Левшин aka Ivan L.]

Кстати, eDir доделали, чтобы она могла подменять Active Directory? Кажется, ходила такая информация....

Сначала началось слюноотделение, когда прочел "доделали eDir" (т.к. ИМХО это МАД доделывать надо, а не едыр), но потом спохватился Да, в оес2 обещали сделать практически полную интеграцию. Проверить пока возможности не имею бо не имею этого мутанта под руками (я про мад говорю ).

[Андрей Тр. aka RH]

На эти выходные дал своим задание проверить объемы баз у FDS и OL на одном и том же количестве объектов....

И есть с чем сравнивать - Novell eDirectory vs. Microsoft Active Directory. Правда, там данные по 8.7.3 и 2003, но я не слышал, чтобы в 8.8 как-то сильно оптимизировали размер базы ( скорость - это да ).

Кстати, eDir доделали, чтобы она могла подменять Active Directory? Кажется, ходила такая информация....

Я надеюсь, вы не ждете, что через "доделанный" еДир можно будет раздавать права в NTFS или хранить доменные Group Policies для клиентов ? Не зная наверняка, я предполагаю, что такого не будет никогда. Так что вы расшифруйте, в каких местах вам бы хотелось, чтобы одно другое подменяло.

[Сергей Дубров]

Я надеюсь, вы не ждете, что через "доделанный" еДир можно будет раздавать права в NTFS

А права на NTFS в самой файловой системе и хранятся, не в AD.

или хранить доменные Group Policies для клиентов ? Не зная наверняка, я предполагаю, что такого не будет никогда. Так что вы расшифруйте, в каких местах вам бы хотелось, чтобы одно другое подменяло.

Ну, если честно, то и в AD групповые политики не хранятся, точнее, хранится их малая часть - в дереве создаются по сути объекты-указатели, а соответствущие их GUID-ам директории в файловой системе и содержат реальные файлы, относящиеся к GP (живёт всё это в шаре SYSVOL домен-контроллера). Курс 2279B "Planning, Implementing and Maintaining a Microsoft Windows Server 2003 Active Directory Infrastructure", Module 5 . Кстати, новеловский zen в части работы с групповыми политиками поступает ровно также (политика хранится в виде .POL-файла на файловой системе).

Недавно осознал, в чём новеловская поддержка GP (ZEN Desktop) уступает микрософтовской - через микрософтовскую GP можно доставлять приложения (publish or assign) совершенно штатными для венды средствами, а Новел для этого тащит специальный и отдельный Application Launcher. Самое обидное, что микрософтовскими средствами деинсталяция распространённого на десктоп приложения делается легко и просто - правый клик мыши -> Uninstall (или полный, с реальной деинсталяцией у клиента, или приложение у клиента остаётся, но убирается из списка распространяемых). У Новела почему-то такой простой процедуры - деинсталляции распространённого ранее приложения по требованию - не существует. Можно, конечно, по расписанию приложение ограничить, но... неудобно.

Зато в назначении GP новеловский ZEN на порядок удобнее - если у M$ минимальная единица, с которой можно проассоциировать политику, это только OU (кроме OU это может быть домен или сайт), то ZEN-ом можно назначать политику вплоть до отдельного пользователя/машины (не говоря уж про группы и OU).

[Андрей Фисенко]

Самое обидное, что микрософтовскими средствами деинсталяция распространённого на десктоп приложения делается легко и просто - правый клик мыши -> Uninstall (или полный, с реальной деинсталяцией у клиента, или приложение у клиента остаётся, но убирается из списка распространяемых). У Новела почему-то такой простой процедуры - деинсталляции распространённого ранее приложения по требованию - не существует. Можно, конечно, по расписанию приложение ограничить, но... неудобно.

Как это нету?... Я сейчас с точностью до закладки конфига не скажу, но в одной из них можно сделать приложение Uninsallable (при этом при De-Ассоциации с пользователем, оно будет удаляться ровно так, как ставилось) и Enable User Uninstall - опция, активирующая у пользователя по правой кнопке мыши на значок приложения функцию Uninstall.
Кроме того, есть даже отдельные опции, в окторых говорится, что можно удалять, а что нет. Например, стирать каталог (со всеми наработанными пользователем временными файлмаи и конфигами) или оставить.
Приложение венды иногда оставляет за собой такие полупустые директории...

[Андрей Тр. aka RH]

Я надеюсь, вы не ждете, что через "доделанный" еДир можно будет раздавать права в NTFS

А права на NTFS в самой файловой системе и хранятся, не в AD.

или хранить доменные Group Policies для клиентов ?.

Ну, если честно, то и в AD групповые политики не хранятся, точнее, хранится их малая часть - в дереве создаются по сути объекты-указатели, а соответствущие их GUID-ам директории в файловой системе и содержат реальные файлы, относящиеся к GP (живёт всё это в шаре SYSVOL домен-контроллера).

Сергей, это-то все понятно, и где и в каком виде реально хранятся GP я знаю ( хотя тех курсов не посещал, но всё это становится очевидно, когда начинаешь ковырять эту службу каталогов и сами политики ).

Просто у народа ( в данном случае речь уже про абстрактный "народ", ничего личного ! ) то и дело возникает желание / вопросы - а как через еДир управлять виндозными серверами ? А если то нельзя, это нельзя - на кой тогда его ( еДир ) туда ставить ? Я пользователю на нескольких серверах назначил права на файл в NTFS, пользователь откуда ? Из АД. Вот и сделайте чтобы так же можно было, только с пользователем из еДира.

Отсюда и был вопрос : "расшифруйте, в каких местах вам бы хотелось, чтобы одно другое подменяло". Хотя вопрос, скорее, риторический, т.к. от меня "доделка" еДира никак не зависит

[Сергей Дубров]

Самое обидное, что микрософтовскими средствами деинсталяция распространённого на десктоп приложения делается легко и просто - правый клик мыши -> Uninstall (или полный, с реальной деинсталяцией у клиента, или приложение у клиента остаётся, но убирается из списка распространяемых). У Новела почему-то такой простой процедуры - деинсталляции распространённого ранее приложения по требованию - не существует. Можно, конечно, по расписанию приложение ограничить, но... неудобно.

Как это нету?... Я сейчас с точностью до закладки конфига не скажу, но в одной из них можно сделать приложение Uninsallable (при этом при De-Ассоциации с пользователем, оно будет удаляться ровно так, как ставилось)
и Enable User Uninstall - опция, активирующая у пользователя по правой кнопке мыши на значок приложения функцию Uninstall.
Кроме того, есть даже отдельные опции, в окторых говорится, что можно удалять, а что нет. Например, стирать каталог (со всеми наработанными пользователем временными файлмаи и конфигами) или оставить.

Приложение венды иногда оставляет за собой такие полупустые директории...

Сорри, был не совсем прав и не очень точно выразился - в микрософтовском варианте явный вызов деисталляции приложения оформлен понятнее и проще. А в zen-е разрешение (для ручного анистала) и автоматического - по деассоциации приложения, - находятся в одной и той же закладке:

Enable Uninstall Enabling this option turns on the automatic
uninstall. The other uninstall options are available
only if this option is enabled.
If the Unassociated days to uninstall is set to 0,
this causes the application to be removed from the
workstation as soon as the application is
unassociated from the user or workstation.

Но у M$ существует два варианта деинсталяции - "жёсткий", с реальным удалением приложения с диска клиентской машины, и "мягкий" - без такового. Вот этого Новеловский zen не обеспечивает.

[Timur Kazimirov]

Зато в назначении GP новеловский ZEN на порядок удобнее - если у M$ минимальная единица, с которой можно проассоциировать политику, это только OU (кроме OU это может быть домен или сайт)

Во-во... Этот идиотизм добивает. Ржу над админами соседних филиалов, которые только тем и занимаются, что понасоздавали себе несколько OU только ради того, чтобы раздать настройки автообновления WSUS, а потом целыми днями перетаскивают пользователей, компьютеры (и сервера!!!) туда-сюда... Не-е-е... ЗЕН рулит!!!

[Андрей Тр. aka RH]

Вот только у меня назначение GP отдельному пользователю почему-то все равно не работало - все так же применялись GP для его OU. Хотя, как я понял, в Зене GP для пользователя должна их победить ( что было бы логично, GP же не аддитивны - а жаль, кстати ). Хотелось таким образом сделать послабление отдельным юзерам.

[Сергей Дубров]

Вот только у меня назначение GP отдельному пользователю почему-то все равно не работало - все так же применялись GP для его OU. Хотя, как я понял, в Зене GP для пользователя должна их победить ( что было бы логично, GP же не аддитивны - а жаль, кстати ). Хотелось таким образом сделать послабление отдельным юзерам.

Порядок поиска политик определяется контейнерной политикой (Search Policy), по умолчанию он такой: User -> Group -> OU. Порядок можно переопределить, в частности, в курсе по ZEN7 вообще выкидываются группы, т.е., ассоциации для них не будут работать (объяснение простое - если пользователь состоит в большом кол-ве групп, то это может сильно замедлить поиск).

Дальше, про (не)аддитивность GP - это не совсем точно, они кумулятивные. Вообще политики бывают сингулярные, плюральные (множественные) и кумулятивные (group policy, за исключением security settings). Вот кусок из курса:

How Policies Are Applied
The policies inside of policy packages can be categorized into the following types:
■ Singular Policies. Let you have only one effective policy at one time. Most policies offered in ZENworks are singular policies.
The first policy found is brought into effect. Examples of singular policies include iPrint, Windows Desktop Preferences, and Dynamic Local User policies.
Most policies in ZENworks Desktop Management fall into this category.
■ Plural Policies. Let you have multiple policies per policy package. Plural policies are rare. Examples of a plural policy include the wake-on-LAN and scheduled action policies.
You can tell that a policy is a plural policy if you have to select the Add button in the package for it to show up.
■ Cumulative Policies (Windows Group Policies). Let you have multiple policies be effective when multiple policy packages are associated with the object, group, and container.
However, unlike plural policies, these settings may have conflicting settings. When cumulative policies have conflicting settings, the policy associated closest to the object is used.

The only cumulative policies in ZENworks Desktop Management are Windows Group Policies. These policies are cumulative with the exception of the Security Settings.