Говард Чу - главный архитектор проекта OpenLDAP (http://www.openldap.org) и его основного корпоративного спонсора Symas Corporation. OpenLDAP - это свободная (и с открытым исходным кодом) реализация протокола LDAP, обеспечивающего общие адресные книги, единую аутентификацию, автоматическое подключение домашних каталогов и совместный доступ к файлам для клиентов, работающих под управлением ОС Linux, Unix, Mac и Windows.
Вопрос: Не могли бы вы немного рассказать о своей работе, проекте OpenLDAP и его отношениях с Symas?
Ответ: Что же, как главный архитектор проекта OpenLDAP я принимаю решения о том, что следует включать в код, а что - нет. По большей части разработчики сообщества OpenLDAP работают над тем, что выберут сами.Я внес свой первый вклад в OpenLDAP в 1998 году и вскоре после этого был приглашен в основную команду разработчиков. Под руководством Курта Зейленга (Kurt Zeilenga) бОльшая часть ранней разработки OpenLDAP была сфокусирована на устранении проблем, связанных с переносимостью и реализации LDAPv3.
Более радикальная эволюция кода со времен работы, проделанной над ним в Мичиганском университете была моей инициативой и это по большей части мой код. Я был полностью занят в работе над проектом, начиная с 1999 года как основатель Symas, решивший инвестировать средства в проект путем финансирования моего участия в нем.
Вопрос: Как вы сравниваете OpenLDAP с проприетарными службами каталогов, такими как Active Directory или SunOne?
Ответ: Active Directory настолько неправильно реализована, что едва заслуживает упоминания. Она попросту несовместима со спецификациями LDAP, что ухудшает возможности взаимодействия. А дизайн ее базы данных настолько плох, что сам по себе может вывести эту службу каталогов из строя.Наша недавняя оценка работы Active Directory и Active Directory Application Mode (ADAM) в качестве LDAP-серверов и тесты производительности, показавшие, что AD и ADAM работают в 3-5 раз медленнее (по сравнению с OpenLDAP - прим. пер.), убедили нас в том, что корпоративные стратегии опирающиеся на эти службы каталогов ведут к неприятностям.
SunOne в течение нескольких лет была, пожалуй, ведущим образцом технологии службы каталогов. Тем не менее, первоначальные разработчики уже давно отошли от работы с кодовой базой и теперь она показывает свой возраст и многочисленные хорошо документированные проблемы со стабильностью и удобством сопровождения.
OpenLDAP сегодня занимает лидирующие позиции в области производительности, масштабируемости и надежности.
К сожалению, мы не можем опубликовать результаты сравнения OpenLDAP и SunOne из-за лицензионных ограничений.SunOne ныне заменяется на OpenDS, проект каталога с открытым исходным кодом, написанный на Java, но это ничего не значит.
OpenLDAP не имеет себе равных среди других служб каталогов, проприетарных или с открытым исходным кодом. И проприетарные службы среди прочих - это лишь попытка спрятать грязное белье и пустая трата времени и денег.
Вопрос: Мы наблюдаем возникновение большого количества ПО с открытым исходным кодом, которое прекрасно работает в корпоративной среде. Какое место в этом множестве вы отводите OpenLDAP?
Ответ: Я думаю, что лучший ответ на этот вопрос вы получите, обратившись к Open Source Investment Portfolio и Open Source Middleware Stack компании Hewlett-Packard. В качестве службы каталогов они выбрали OpenLDAP (а Symas - в качестве партнера для техподдержки).Несколько меньших независимых поставщиков ПО также выбрали OpenLDAP (наиболее заметными среди них являются Ventyx и Zimbra) и мы ожидаем, что их количество будет расти.
Вопрос: Похоже, что у каждого Open Source проекта есть своя собственная схема LDAP. Как решаете проблемы, связанные с множеством схем, а также вытекающие отсюда проблемы несовместимости и сложности?
Ответ: Множественность схем в каталогах LDAP на самом деле вполне поддается управлению. Главное - убедить разработчиков публиковать спецификации их схем для облегчения адаптации. Например, мы работаем с разработчиками Samba и группой разработчиков Kerberos из IETF над созданием стандартной схемы LDAP для центра распределения ключей Kerberos.Мы создаем рациональное надмножество схем, в настоящее время использующихся в Heimdal и MIT, которые затем могут быть использованы в Samba и других приложениях, которым нужны Kerberos и LDAP. Все очень просто: люди должны взаимодействовать для того, чтобы могли взаимодействовать создаваемые ими программы.
Меня слегка удивляет, что эти проблемы вообще относят на счет LDAP. Вы крайне редко сможете столкнуться с настоящей несовместимостью в определениях схемы. Обычно вы всего лишь обнаруживаете, что опубликованная стандартная схема является неполной или неподходящей для какого-то определенного приложения.
Этого и следует ожидать, поскольку большинство опубликованных схем - это стартовые варианты и подразумевается, что они будут расширяться и дорабатываться для совместимости с другими схемами. Для сравнения: управление схемами в реляционных базах данных - по-настоящему трудная проблема.В мире SQL нет общих определений, как в X.500/LDAP. Фактически нет даже общего SQL - есть множество несовместимых между собой диалектов. Даже такие фундаментальные вещи, как элементарные типы данных (целое, 64-битное целое и т. д.) не имеют стандартного определения в разных реализациях SQL.
Конечно, нам приходится сталкиваться с ситуациями, когда необходимо обучение. Мы проводим много официальных и неофициальных консультаций для организаций, переходящих на OpenLDAP. Время от времени возникают проблемы совместимости, но они легко устраняются по мере того, как технические специалисты начинают проходить подготовку в "университете LDAP" компании Symas.
Вопрос: Каким образом сообществу Open Source следует пропагандировать использование OpenLDAP организациями?
Ответ: Во-первых, о выборе LDAP в качестве службы каталогов. Мы видим организации и Open Source-проекты, реализующие хранилища данных с использованием других технологий и их масштабируемость, производительность или управляемость крайне редко оказываются адекватными для развертывания в масштабах предприятия. LDAP предоставляет превосходную и легкодоступную базу для хранения данных каталога.Во-вторых, потратьте некоторое время на то, чтобы дать оценку вашему использованию OpenLDAP. После принятия решения о вложении денег в LDAP вам следует провести сравнение технологий LDAP, наиболее соответствующих стандартам и предложить вашим пользователям возможность легкого развертывания OpenLDAP.
В-третьих, следует протестировать производительность службы каталогов с открытым исходным кодом с использованием предложенной схемы, репрезентативных образцов данных, нагрузок и количества записей, соответствующих нуждам организации.
URL: http://www.computerworlduk.com/community/blogs/index.cfm?ent...
Новость: http://www.opennet.ru/opennews/art.shtml?num=14723
Может кто меня просветит, что eDirectory - это забытое вчера без будущего? ну или жутко специализированная и уже не нужная реализация LDAP?Просто я для себя ни как не пойму, зачем нынче нужен eDirectory и что с ним еще делают опытные люди.
А что в нем так плохо? И почему это прошлое? Как я понимаю это аналог АД от Новела, нет?
Да вот не могу понять как в NTFS (на компах пользователей) права из NDS прописываются.Собственно хочу обойтись совсем без серверов от M$ (в плана максимально сократить их использование, т.к. сильно напрягает неободимость поднимать всю систему из арива после очередного сбоя, да и сбои очень надоели и тормоза после обновления, давно в общем накопилось...). Ну SQL+1C видно придется оставить, т.ч. один видно останется, чтоб MS SQL крутить (но не AD).
Переводить серваки и оставить юзеров на винде? Я сейчас смотрю в сторону eDirectory + SLED для юзеров. бухов под вайн(Etersoftовский или какихтам) скорее всего. Ставить неAD для виндовых машин - увеличивать кол-во гемора имхо.
Etersoftовский скоро к постгри смогет, но программеры 1С народ туповатый - чуть ошибка где в их коде, будут на тебя показывать, и придется тебе 1С Кучить (а 1С как известно светлое ВЧЕРА, таким образом кобала это для вас батенька будет).Реализация 1С такова, что постгри будет лежать от такого обращения.
1С 8.0 + db2 хоть какое-то решение, но эта убогая поделка (имхо) для винды.
Узеры дома на винде сидят, а о UBUNTU и не слышали - будут вопить, что компьютр сам выключается, финансовый отдел откажется переходить с винды.ИМХО опять же - пусть работают на чем могут, а сервера под виндой держать = укрупнять отдел системных администраторов (виндузовых), т.к. винда валится раз в три месяца (у меня валится). Да и дорого обходится эта винда, проще сувать деньги себе в карман и ставить вместо винды freebsd+samba на сервера (геморой обеспечен, но уже другого характера и если систему не перегружать функциями - не требовать что то кроме центра регистрации в виде домена, то все будет пучком(надеюсь)).
Ну у нас 1С база вообще на шаре лежит. Не такая большая.Домен уже год(тьфу тьфу) работает. ДНСка правда пглючит постоянно, но это мелочи. Вопрос с юзерами решил в два счета - поставил гендиру Висту на ноут, что посмотрели, какое Г придется кушать ложками. Начальство готово к линуксу :) Можно прямо М$у спасибо сказать.
Мое почтение. Мне до этого далеко.
Скупая слеза по щике ...
Что жа вы там с виндами то этими делаете ... непотребное, что они у вас раз в три месяца то валяться ?! У меня сервак w2к3 (с тем же убогим 1с и не менее убогим AD) полгода в апе без единого ребута, если бы не замена материнки и рейда, еще в 10 раз дольше простоял бы ...
Может у Вас один-два узера + один админ на все? а у нас сотни узеров и пара отупевших от AD админа.
Если надо полностью убежать от M$, посмотрите (погуглите) на тему 1C-сервера для Linux. Он, кажется, еще в бете, но уже что-то. И поддерживает PostgreSQL.
Какая бета ???
Уже давным-давно используется. Только толку мало от него, т.к. поддержка DB2 и PostgreSQL реализована через одно место. Со стандартными конфигурациями использовать сложно.
Не так уж и сложно со стандартными. Да, текущие конфигурации требуют не очень большой модификации, после которой связка "сервер 1С+PostgreSQL" на Linux ничуть не хуже, чем "сервер 1С+MS SQL Server" на Windows. Причем сам PostgreSQL тоже надо с напильничком.
Управляемые блокировки нужно делать, а для этого нужно ОЧЕНЬ хорошо разобраться в конфигурации, а некоторые конфигурации вообще хочется только на поставке оставить.
Понимаю, что тему про мертвую 1С толку мало малить, но все же. Какого порядка база 1С крутится? Есть удачные примеры на 100-150 узеров 1С (+столько же конектов через ADO) и размер базы от 15 гб? (собственно без кластеров!) лучше ткните где посмотреть с кем поговорить.
Не могли бы вы немного точней задать вопрос?
Есть пример базы 7.7 SQL 80 Гб - тормозит :-)
>Не могли бы вы немного точней задать вопрос?
>Есть пример базы 7.7 SQL 80 Гб - тормозит :-)Не вопрос:
80гб говоришь... turboMD.dll, 1cpp.dll, ADO (или ODBC из 1С++). Что за SQL у базы MS SQL, db2 или Postgree? 1C это клиент бд в традиционном понимании (типовая кофа к примеру) или картинка (т.е. документы и справочники в обычном понимании программистов 1С)? Сколько конектов к базе (про блокировки мне неинтересно, это решается не на клиенте)? Как моксели в эксель сохраняются?Сколько памяти на сервере и что за ось?
>максимально сократить
>их использование, т.к. сильно напрягает неободимость поднимать всю систему из арива
>после очередного сбоя, да и сбои очень надоели и тормоза после
>обновления, давно в общем накопилось...). Ну SQL+1C видно придется оставить, т.ч.
>один видно останется, чтоб MS SQL крутить (но не AD).Чтоже у вас за кривость рук, что у вас цитирую:"напрягает неободимость поднимать всю систему из арива после очередного сбоя". Да и рэйд уже придумали имхо давно, чтобы не париться со сбоями, если таковые даже(!) и имеются :)
Правда, что это?
>Да вот не могу понять как в NTFS (на компах пользователей) праваВ рамках NTFS - по человечески никак. Ограничение виндовозной системы раздачи прав и файловой системы.
Вот этого ответа я ждал и боялся. Спасибо.PS: Остается только надеяться на бездисковые (или *nix-овые) станции и цитриксы + сервак под SQL (для 1С). Админить сеть из сотен компов и кучей каких-то политик - это геморой еще тот!
Было бы удивительно, если бы он сказал, что у них есть проблемы с мульти-мастер репликацтией, не совместимом форматом ACL с ведущими DS, от SUN и Red Hat, нет равных OpenLDAP, только об этом не знают в Red Hat, делая свой RHDS/FDS...:)З.Ы. SunONE давным давно переименован в Sun Java Sytem Derictory Server, не чем его не заменяют, просто код пишут в рамках OpenDS, а потом бекпортируют в него, что весьма логично, ибо эта модель очень удобна для корпараций...:)
Мультимастера у них небудет никогда. Мультимастер противоречит самой идее LDAP где у нас есть одно дерево. Про это прямо сказано у них в FAQ. Насчет ACL все просто. Там нет стандарта. Будет стандарт будет совместимо со стандартом.
Я не был бы столь категоричным. Все меняется. Мультимастер есть в тестовой ветке 2.4.х. Так что ждите стабилизации и - на танках в светлое будущее!
А разве eDirectory под линукс склепали не на основе допиляного новеловцами OpenLDAP'а?
>А разве eDirectory под линукс склепали не на основе допиляного новеловцами OpenLDAP'а?
>Думаешь я знаю?
Ладно развивать мою тему, это не по теме новости.
Ну так для затравки:Новелловцы сделали свою NDS (прообраз eDirectory) в 1993 году
ActiveDirectory первый раз показали в 1996 году
Проект OpenLDAP был запущен в 1998 году
\по материалам Википедии\
Кто чего у кого допиливал? =-)
LDAP - это стандарт, нет? АД, OpenLDAP (насчет еДира хз) - его реализации. Или я курю не ту траву?
А кто вам сказал, что в openldap нет мультимастера?
Но резковат дядечка, круче него только горы.
Жаль, что нет сравнения с FedoraDS.
+1Даешь полномасштабное сравнение FDS vs MDS vs OpenLDAP
Что такое MDS?
>Что такое MDS?Mandriva Directory Server
>>Что такое MDS?
>
>Mandriva Directory ServerА вот Mandriva Directory Server это набор средств для управления в том числе LDAP сервером. В качестве которых используется или Fedora DS или OpenLDAP. Тка-что тестировать тут нечего кроме юзабилити.
>>>Что такое MDS?
>>
>>Mandriva Directory Server
>
>А вот Mandriva Directory Server это набор средств для управления в том
>числе LDAP сервером. В качестве которых используется или Fedora DS или
>OpenLDAP. Тка-что тестировать тут нечего кроме юзабилити.Да ну, они использую Linbox Derictory Server, который они купили вместе с конторой, так на чём основан Linbox там, на FDS или OpenLDAP???:)
>Да ну, они использую Linbox Derictory Server, который они купили вместе с
>конторой, так на чём основан Linbox там, на FDS или OpenLDAP???:)По-моему Вы не правы. Насколько мне не изменяет память - MDS - открытый продукт. Только его поддержка будет стоить денег. Юзает он OpenLDAP и это точно, поставьте и убедитесь, что он просто добавляет схему свои и свою морду предоставляет. А Linbox был куплен вместе с его продуктами Linbox Rescue Server и никакого отношения к директориям сия прога не имеет - это что-то для централизованного управления серверами, надо полагать (хотя тут могу ошибаться, т.к. ещё не успел посчупать).
По-моему Вы не правы. Насколько мне не изменяет память - MDS - открытый продукт. Только его поддержка будет стоить денег. Юзает он OpenLDAP и это точно, поставьте и убедитесь, что он просто добавляет схему свои и свою морду предоставляет. А Linbox был куплен вместе с его продуктами Linbox Rescue Server и никакого отношения к директориям сия прога не имеет - это что-то для централизованного управления серверами, надо полагать (хотя тут могу ошибаться, т.к. ещё не успел посчупать).Возможно и не прав, но судя по этой страничке на их оф сайте, всё же прав http://mds.mandriva.org/ прочтите там же новости, о том, что Mandriva покупает Linbox и её Linbox Directory Server, а ещё переименовывает его в Mandriva Directory Server, да и Linbox Directory Server раньше был закрытым продуктом, значит он к OpenLDAP не имеет не какого отношения, посему, если сейчас они взяли OpenLDAP за основу, то может быть...:)
>Возможно и не прав, но судя по этой страничке на их оф
>сайте, всё же прав http://mds.mandriva.org/ прочтите там же новости, о том,
>что Mandriva покупает Linbox и её Linbox Directory Server, а ещё
>переименовывает его в Mandriva Directory Server, да и Linbox Directory Server
>раньше был закрытым продуктом, значит он к OpenLDAP не имеет не
>какого отношения, посему, если сейчас они взяли OpenLDAP за основу, то
>может быть...:)Гм. Действительно Вы правы.
Самое интересное, что тут http://www.linbox.com/ucome.rvt/any/en/Produits/ нет никаких упоминаний о LDS. Но факт остаётся фактом, что MDS функционирует на OpenLDAP. Я его ставил версии 2.1 и юзал он именно OpenLDAP, а Linbox Directory Server просто название для надстройки для удобного управления OpenLDAP'ом, равно как и нынешний Mandriva Directory Server.
P.S. Напоминания нашлись на linbox.org
Меня вот что интересует: Какая-либо свободная реализация LDAP (OpenLDAP, FDS и.т.п, кроме eDirectory т.к eDirectory, насколько я понял, этого не умеет.) позволяет создавать учетные записи только на сервере, без необходимости предварительного создания их на клиентской машине, как это сделано в проприетарной AD от MS? Кто-нибудь в курсе?
>Меня вот что интересует: Какая-либо свободная реализация LDAP (OpenLDAP, FDS и.т.п, кроме
>eDirectory т.к eDirectory, насколько я понял, этого не умеет.) позволяет создавать
>учетные записи только на сервере, без необходимости предварительного создания их на
>клиентской машине, как это сделано в проприетарной AD от MS? Кто-нибудь
>в курсе?Ничего не понял !
Учетные записи создаются в ldap-каталоге
При этом /home/user можно не создавать.В чем проблема ?
>>Ничего не понял !
>>Учетные записи создаются в ldap-каталоге
>>При этом /home/user можно не создавать.
>>В чем проблема ?Конкретизирую вопрос: мне действительно не придется создавать руками учетки на клиентских машинах, при использовании свободных реализаций LDAP? Конкретно, при использовании OpenLDAP или FDS?
>>>Ничего не понял !
>>>Учетные записи создаются в ldap-каталоге
>>>При этом /home/user можно не создавать.
>>>В чем проблема ?
>
>Конкретизирую вопрос: мне действительно не придется создавать руками учетки на клиентских машинах,
>при использовании свободных реализаций LDAP? Конкретно, при использовании OpenLDAP или FDS?
>
>учетки на клиентских машинах,это вообще что такое? $HOME? если воспользуетесь pam_mkhomedir то $HOME создаться при первом логине.
>
>это вообще что такое? $HOME? если воспользуетесь pam_mkhomedir то $HOME создаться при
>первом логине.А чем мне воспользоваться, что бы домашний каталог с соответсвующими локальными правами создался на маздайной машине?
Смысл такой: мне нужно решение, позволяющее при наличии учетной записи в ldap-каталоге
безболезненно регистрироваться под этой учеткой на любой машине - члене контроллера домена, без необходимости каких-либо предварительных манипуляций на этой машине. Тупо введя логин и пароль на этой машине. С маздайными тачками и AD это проканывает. Нужен аналогичный функционал, реализованный свободными продуктами. Что непонятного-то?
>[оверквотинг удален]
>>первом логине.
>
>А чем мне воспользоваться, что бы домашний каталог с соответсвующими локальными правами
>создался на маздайной машине?
>Смысл такой: мне нужно решение, позволяющее при наличии учетной записи в ldap-каталоге
>
>безболезненно регистрироваться под этой учеткой на любой машине - члене контроллера домена,
>без необходимости каких-либо предварительных манипуляций на этой машине. Тупо введя логин
>и пароль на этой машине. С маздайными тачками и AD это
>проканывает. Нужен аналогичный функционал, реализованный свободными продуктами. Что непонятного-то?используйте www.pgina.org . позволяет логинится на Windows машине с вытаскиванием юзверей откуда угодно. хоть из PostgreSQL :) такой себе PAM для Windows.
>[оверквотинг удален]
>>первом логине.
>
>А чем мне воспользоваться, что бы домашний каталог с соответсвующими локальными правами
>создался на маздайной машине?
>Смысл такой: мне нужно решение, позволяющее при наличии учетной записи в ldap-каталоге
>
>безболезненно регистрироваться под этой учеткой на любой машине - члене контроллера домена,
>без необходимости каких-либо предварительных манипуляций на этой машине. Тупо введя логин
>и пароль на этой машине. С маздайными тачками и AD это
>проканывает. Нужен аналогичный функционал, реализованный свободными продуктами. Что непонятного-то?Тебе тогда надо поднять домен на самбе с аутентификацией на LDAP сервере. Диски с домашними директориями будут монтироваться по SMB с соответствующими правами. Это делает logon скрипт. Обязательно ознакомься с документацией по самбе.
>Тебе тогда надо поднять домен на самбе с аутентификацией на LDAP сервере.
>Диски с домашними директориями будут монтироваться по SMB с соответствующими правами.
>Это делает logon скрипт. Обязательно ознакомься с документацией по самбе.Дык тогда придётся пароли светить. Либо вводить лишний раз.
>[оверквотинг удален]
>>>>При этом /home/user можно не создавать.
>>>>В чем проблема ?
>>
>>Конкретизирую вопрос: мне действительно не придется создавать руками учетки на клиентских машинах,
>>при использовании свободных реализаций LDAP? Конкретно, при использовании OpenLDAP или FDS?
>>
>>учетки на клиентских машинах,
>
>это вообще что такое? $HOME? если воспользуетесь pam_mkhomedir то $HOME создаться при
>первом логине.Нет, это просто учётные записи или пользователи. Похоже в вопросе смешиваются две различные схемы аутенфикации. Вопрос звучит следующим образом: в случае использования openLDAP есть ли необходимость создавать локальные учётные записи? Ответ: нет, это не обязательно, но желательно иметь локальную учётную запись для root (Linux-клиент) и Administrator (Windows-клиент). А ещё лучше иметь кешированную локальную базу данных с LDAP сервера. Это на случай если LDAP сервер по какой-либо причине будет недоступен. Windows это делает автоматически, а в Linux это надо указать явно. В последнем случае для реализации нет необходимости вбивать руками заново. Смотрите man nss_updatedb и конфигурацию для nsswitch.conf.
>>>Ничего не понял !
>>>Учетные записи создаются в ldap-каталоге
>>>При этом /home/user можно не создавать.
>>>В чем проблема ?
>
>Конкретизирую вопрос: мне действительно не придется создавать руками учетки на клиентских машинах,
>при использовании свободных реализаций LDAP? Конкретно, при использовании OpenLDAP или FDS?Если под учеткой подразумевается uid,gid,username и прочее тогда не придется
А вот собственно home-каталог пользователя создается либо руками ( скриптом )
либо автоматически через pam_mkhomedirА вообще рекомендую сначала почитать чего-нибудь.
C такими знаниями внедрить ldap будет тяжело :)
>>>Ничего не понял !
>>>Учетные записи создаются в ldap-каталоге
>>>При этом /home/user можно не создавать.
>>>В чем проблема ?
>
>Конкретизирую вопрос: мне действительно не придется создавать руками учетки на клиентских машинах,
>при использовании свободных реализаций LDAP? Конкретно, при использовании OpenLDAP или FDS?
>Придёться, но только один раз в обоих случаях. Как показывает опыт может и несколько раз если раньше вы этого не делали. Как минимум вы должны зарегистрировать клиентскую машину в домене, как минимум вам придёться ввести имя лица, его контактную информацию, имя менеджера, название отдела и т.д.
Всем ответившим спасибо, сохраняю топик и буду копать тему глубже.
спасибо за перевод
> OpenLDAP - это свободная (и с открытым исходным
>кодом) реализация протокола LDAP, обеспечивающего общие адресные книги, единую аутентификацию, автоматическое
>подключение домашних каталогов и совместный доступ к файлам для клиентов, работающихТак, так. А вот тут поподробней. Каким же замечательным макаром OpenLDAP позволяет автоматом подключать домашние каталоги?? Раз так написано => подразумевается, что они могут монтироваться с удалённого файл-сервера. Верно?? Какое к этому имеет отношение OpenLDAP, кроме тупой раздачи хоума??
Если есть замена pam_mount - просвятите пожалуйста.
Наверно тут также как и про "единую аутентификацию" - просто единое хранилище, а чтобы сделать хотя бы централизованную авторизацию уже нужно выходить за рамки OpenLDAP'а и трахетси с памом, а вот сделать именно "единую авторизацию" надо полагать вообще в данный момент под линуксом невозможно, ибо общая "керберезированность" пока что низкая. Буду рад пообщаться по существу на данную тему.
>[оверквотинг удален]
>>подключение домашних каталогов и совместный доступ к файлам для клиентов, работающих
>
>Так, так. А вот тут поподробней. Каким же замечательным макаром OpenLDAP позволяет автоматом подключать домашние каталоги?? Раз так написано => подразумевается, что они могут монтироваться с удалённого файл-сервера. Верно?? Какое к этому имеет отношение OpenLDAP, кроме тупой раздачи хоума??
>Если есть замена pam_mount - просвятите пожалуйста.
>Наверно тут также как и про "единую аутентификацию" - просто единое хранилище,
>а чтобы сделать хотя бы централизованную авторизацию уже нужно выходить за
>рамки OpenLDAP'а и трахетси с памом, а вот сделать именно "единую
>авторизацию" надо полагать вообще в данный момент под линуксом невозможно, ибо
>общая "керберезированность" пока что низкая. Буду рад пообщаться по существу на
>данную тему.Вы совершенно правы, openLDAP не монтирует диски. Это вообще из другой области. Он содержит информацию о пользователях и группах и пр. перечисленное выше и, в частности, где находится домашняя директория пользователя. Каким образом и почему она там находится openLDAP совершенно не заботит. Он только предоставляет эту информацию.
Аутенфикация - это процесс, при котором вы подтверждаете себя. Авторизация - это процесс, подтверждающий использование ресурсов на основании вашей аутенфикации. Вы можете быть залогинены(аутенфицированы), но не авторизованы использовать файл/директорию с помощью прав доступа. Так что единая авторизация есть. Только средства доступа к ней, читай аутенфикация, различны, что есть хорошо.
>Аутенфикация - это процесс, при котором вы подтверждаете себя. Авторизация - это
>процесс, подтверждающий использование ресурсов на основании вашей аутенфикации. Вы можете быть
>залогинены(аутенфицированы), но не авторизованы использовать файл/директорию с помощью прав доступа. Так
>что единая авторизация есть. Только средства доступа к ней, читай аутенфикация,
>различны, что есть хорошо.Спасибо конечно, но чем они друг от друга отличаются я знаю.
Мне кажется Вы не совсем правы. Дело в том, что я могу делать - определяет далеко не лдап. Как Вы правильно написали он (лдап) только выдаёт уид, гид, хоум... А что мне можно и чего нельзя определяет ядро и политики вроде SELinux'а (RBAC, etc) опираясь на свои законы и оперируя тем, что мне принадлежит конкретный уид и исходя из этого разрешает или нет мне что-то делать.
Смотря что понимать конечно под единой авторизацией, можно конечно по-разному трактовать. Но для большинства, я думаю, единая авторизация, это когда ты залогинился и ломишься на какой-то сервис (включая сетевой) и он смотря кем ты залогинен даёт или не даёт что-нить делать. Я уверен, что для большинства - единая авторизация и её прелесть состоит как раз таки в том, что залогинившись тебе без лишних паролей дают права на удалённом, допустим, самба-сервере. Централизованное хранилище аккаунтов, паролей ещё не обозначает, что везде будет пускать, а так хотелось бы...