LDAP vs DB

[Alex Keda]

умеющий читать.
привык, знаешьли, обильно комментировать сделанное

[Хостинг HostFood.ru]

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

[princeps]

все равно заебется.
Вообще все это флейм. У меня есть одна знакомая контора - человек 20-30 работников, офиса нету, есть только сервер на колокейшене. Каждый из дома работает. Там менеджеры по продажам, дизайнеры всякие, проджект-менеджеры и т.п. Так вот для групповой работы они юзают следующие сервисы: почту, джаббер, фтп, что-то типа интрасайта на друпале, sugarcrm для работы с клиентами, какую-то веб-бэйзед систему управления проектами. Естественно, заставлять работника запоминать столько логинов\паролей - нет смысла. Тут-то и выручает лдап, на который можно завязать авторизацию. Можно, конечно, и на MySQL завязать, даже будет быстрее работать, наверное, но сколько возни? и кто потом возьмется поддерживать эту реализаию, если разработчик накроется? А лдап - он на то и стандарт, он для того и создан, чтоб учетные данные через него получать. При этом sugar свои данные (кроме юзеров) хранит, конечно же, в мусе, никому и в голову не приходит хранить их в лдапе. Такие дела.

[Alex Keda]

т.е. реализация 1 таблицы с тремя полями и двумя ключами в мусе менее понятна нежели лдап?

[princeps]

реализация использования этой таблицы вышеуказанными сервисами

[Alex Keda]

а реализация использования ими лдапа - проще?
да вы гоните
===========
либо в них уже БЫЛ ПРЕДУСМОТРЕН лдап как точка авторизации.
тогда - пример в принципе некорректен. ибо таблица на мусе проще

[princeps]

либо в них уже БЫЛ ПРЕДУСМОТРЕН лдап как точка авторизации.

Конечно был, я об этом и говорю. Потому что лдап - это стандарт. И именно поэтому пример как раз корректен.

[Alex Keda]

нет. он там был - и ты сделал как проще.
и клал ты на стандарты.
как и все кругом

[princeps]

не согласен я просто хочу донести до народа, что СУБД и ЛДАП - в несколько разных плоскостях лежат. Если вам не надо расшаривать учетные данные на много сервисов, то нафиг вам ЛДАП? Конечно лучше sql. Если же нужно - то лдап по-любому удобнее, потому как стандарт и производители софта включают в свои продукты его поддержку. Можно, конечно, придумать стандарт с хранением в SQL, но это будет тот же самый ЛДАП, тем более, что для бэкенда лдапа можно использовать SQL.

[ev]

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

нет. он там был - и ты сделал как проще.

не как проще, а как правильнее
слова стандартизовано и проще далеко не всегда соседствуют
взять хотябы ГОСТы - ничего простого там нет, однако довольно часто спасает именно следование стандартам

[princeps]

я в одном офисе не очень большом видел, как чуваки, что провода тянули, озаботились тем, что в витой паре четыре провода простаивают. И сделали так, что одним проводом подключались сразу два компьютера. Не знаю, провода экономили или просто было нечем заняться, но я бы таким вот выдумщикам собственных стандартов руки бы отрывал.

[Alex Keda]

я в армии тоже так делал...
а ещё у нас кабель 50 жильный выходил из канала и на десяток витых пар разбегался.... - сетка между этажами и корпусами была так сделана )

[princeps]

как живо идет обсуждение, похоже в пятницу после обеда айтишникам совсем нехрен заняться

я в армии тоже так делал...

и что, до сих пор считаешь, что это правильно?

[ev]

и что, до сих пор считаешь, что это правильно?

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

[princeps]

Да, конечно, с этим никто и не спорит. Но все-таки, мне кажется, надо стараться им следовать, где это возможно

[Гость]

На этом сайте есть неплохая статья как замутить Exim на Лдапе: http://www.lissyara.su/?id=1331.
Вроде все правильно, но автору пришлось придумывать свою схему MailAccount для этого, поскольку стандартные не подошли. Вот и конец стандартам... Учитавывая также, что тип предложенной схемы - STRUCTURAL, прикрутить к объекту в такой схеме дополнительно еще inetOrgPerson тоже типа STRUCTURAL уже не удастся. А это означает, что список почтовых аккаунтов будет идти отдельной веткой ЛДАП, параллельно с аккаунтами Самба, ФТП и т.д.
Тогда уж надо брать АД от МС ) - а там уж от стандартов ЛДАП совсем ничего не осталось...

[Alex Keda]

вот и конец обсуждению.
получили что стандартом стал АД от M$

[ev]

автору пришлось придумывать свою схему MailAccount для этого, поскольку стандартные не подошли

в каком RFC определены стандартные схемы?
их вроде только 4 довольно общие... да и не зря есть стандарт написания схем
сравнить можно с SNMP - там тоже MIB может дополняться

[varav]

в каком RFC определены стандартные схемы?

Да, далеко не все схемы определены в RFC, но при этом они считаются стандартными, например Самба схема идет без RFC. Попытка придумать свою схему может в конце концов привести к внутреннему противоречию в базе ЛДАП, даже если вначале будет все Ок. Разобраться в этом будет посложнее, чем в простой реляционной базе с 3- 4 таблицами.
И еще по поводу стандартов - эти стандарты все таки придумали в США в соответствии с требованиями их бюрократии. В наших условиях долго приходится гадать, к какому нашему российскому параметру привязать конкретный атрибут.

[varav]

Все это, конечно, флейм, но в процессе все равно возникает конструктивная мысль - на ЛДАПе все уже давно сделано, но не всех удовлетворяет (слишком глобально и монстроидально). На MySQL ( и может даже PosgreSQL?!) по частям сделано наверняка тоже почти все - exim/postfix, samba, squid, jabber и т.д. Наверняка найдется большой гуру, который сможет свести это все воедино и получится легкий и понятный всем каталог. Ведь не обязательна мульти-мастер работа и распределенная база для организаций с персоналом ~ 100...

[princeps]

возьми и сделай .

[ev]

Наверняка найдется большой гуру, который сможет свести это все воедино и получится легкий и понятный всем каталог.

так уже есть - LDAP
надо только нормальный клиент и схемы более вменяемые

[varav]

возьми и сделай

Здесь я не гуру...
Вот тут http://avist.biz/article/show/31.html что-то пытались начать похожее, но сейчас там все остановилось, похоже. Ссылка сейчас открывает только главную страницу сайта, а не "Хранение информации о пользователях корпоративной системы в БД MySQL для всех используемых сервисов", но в кэше Гугля инфа все еще есть...