LINUX.ORG.RU
решено ФорумAdmin

Tree structure в LDAP и MTA: как подружить?

 , ,


0

1

Для хранения виртуальных доменов, ящиков, алиасов используется древовидная структура в LDAP:

o=p
ou=Domains,o=p
dc=local,ou=Domains,o=p
dc=test,dc=local,ou=Domains,o=p

для домена test.local и mail=example@test.local,dc=test,dc=local,ou=Domains,o=p для почтового ящика example@test.local. Таким образом, если у нас 100500 разных доменов, то такая структура уменьшает объёмы повторяющейся информации.

Чтобы запросить нужную информацию, надо сформировать соответствующий запрос. Для exim он выглядит примерно так, скажем, если ищем local_domains:

LDAP_AUTH = user="uid=exim,ou=S,o=p" pass="123"
LDAP_URL = ldapi://%2fvar%2frun%2fopenldap%2fslapd.sock

DOMAIN_IN_DC = ${sg{$domain}{[.]}{,dc=}}
LDAP_BASE = dc=DOMAIN_IN_DC,ou=Domains,o=p

LDAP_QUERY_DOMAINS = dc?base?(&(objectClass=mailDomain)(accountStatus=active))


domainlist local_domains = @ : ${lookup ldap {LDAP_AUTH LDAP_URL/LDAP_BASE?LDAP_QUERY_DOMAINS}{$domain}fail}

Основное тут следующее: в макросе DOMAIN_IN_DC мы test.local приводим к виду test,dc=local, затем, LDAP_BASE возвращает dc=test,dc=local,ou=Domains,o=p и мы ищем нужные данные в ветке, зависящей от домена.

Решил посмотреть, что на эту тему есть у postfix и не нашёл ничего интересного. Т.е., да, postfix умеет искать в LDAP, но делает это примитивно, в расчёте на то, что все домены представляют собой плоский список, а поскольку я не создаю для записи dc=test,dc=local,ou=Domains,o=p атрибута типа virtDomain со значением test.local, т.к. не вижу смысла дублировать уже имеющуюся информацию, то получается, что в древовидной схеме постфикс не найдёт доменов.

Вопросы: это неизлечимый дефект в дизайне постфикса? Если излечимый, то как его можно поправить? Написать отдельный аутентификатор, который это умеет? Написать отдельный демон, который будет сам общаться с LDAP и отдавать postfix результаты поиска?

такая структура уменьшает объёмы повторяющейся информации.

Не понял, в каком месте повторяется инфа.

zgen ★★★★★ ()
Ответ на: комментарий от zgen

Если вместо

local
test.local
foobar.local
example.foobar.local
morexample.foobar.local
another.local

сделать

local
  |
  test
  |
  foobar
  | |
  | example
  | |
  | morexample
  |
  another
то видно, что в первом случае повторяется часть local и foobar.local, во втором случае каждая запись ограничивается только уникальной частью dc, не повторяя каждую из них много тысяч раз.

Вдобавок, некоторое ПО, которое использует те же данные, что и почтовый сервер, шустрее обрабатывает их, если они структурированы в виде дерева, а не плоским списком.

HolyBoy ()
Последнее исправление: HolyBoy (всего исправлений: 2)
Ответ на: комментарий от HolyBoy

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

zgen ★★★★★ ()
Последнее исправление: zgen (всего исправлений: 2)

Вы спутали, дерево LDAP не предназначено для построения дерева интернет доменов. Можно, но не нужно :)

Более того, ваше дерево экономит (что там экономить-то?) место только вашем случае. Постфикс, зимбра и прочий софт работает в расчете стандартной схемы: ou=People,dc=example,dc=com, ou=Groups.., ou=Users...,. И учетки все заведены в ou=Peopele,dc=example,dc=com или в ou=Users. Но вы конечно можете пропатчить постфикс как вам удобно.

Вообще, от openldap не стоит ждать сверх производительности, если вы говорите про 100500 аккаунтов. Не стоит также ждать, что он удобно и легко распределяется. Это очень сложная в настройке система и если вы не спец. по этой теме, и хотите чтобы все было «чики-пуки», то прикручивайте постгрес, на худой конец мускл/марию.

gh0stwizard ★★★★★ ()
Ответ на: комментарий от gh0stwizard

Вообще, от openldap не стоит ждать сверх производительности…

Ну… я бы так не сказал. Проверял: на LDAP при прочих равных выжимается больше qps, например, при работе с DNS.

Что касается MySQL — не смешно. При тех нагрузках, что имеются, MySQL просто умрёт или будет требовать непомерно мощного железа.

HolyBoy ()

Всем спасибо за ответы. Будем думать.

HolyBoy ()

Ну либо ты гуру по ldap (ты про openldap?), либо не видел его перформанс тесты. У меня он захлебывался даже с выделенном гигом ОЗУ на нескольких миллионах записей (hdb/bdb).

gh0stwizard ★★★★★ ()
Последнее исправление: gh0stwizard (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.