03.12.08
postfix,dovecot.
Чуть раньше, чем я стал выяснять вопрос с sqlite хранилищем я пытался нарисовать немного другую схему с, так сказать, распределенным хранилищем всей информации, как то домены, аккаунты и алиасы. Для тех, кто работал с CommuniGate (я пишу о ветке 4.1.x, с обновленным монстром, включающим себя сильно позднее даже ip телефонию я не работал) сервером, полагаю, понятно, что я имею в виду. Но, все-таки поясню для остальных. В CGP информация обо всем этом лежит не в каком-то отдельном месте, отдельной базе, но в каталогах самих доменов, аккаунтов следующим образом:
о домене
/var/CommuniGate/Domains/domain.ru/Settings/access.settings
/var/CommuniGate/Domains/domain.ru/Settings/domain.settings
/var/CommuniGate/Domains/domain.ru/Settings/domainAliases.data
об аккаунте:
/var/CommuniGate/Domains/domain.ru/mail.macnt/account.info
/var/CommuniGate/Domains/domain.ru/mail.macnt/account.settings
/var/CommuniGate/Domains/domain.ru/mail.macnt/INBOX.mdir
При запуске Коммунигейта вся информация считывается в память. Что может быть весьма долго, до 2-3 минут на моей памяти при большом кол-ве доменов/аккаунтов. (сотни доменов и тысячи аккаунтов), зато это компенсируется дальнейшим очень быстрым доступом до этих данных. При этом, правда, следует учесть,
что изменения данных на уровне файловой системы, не через
Коммунигейтовские интерфейсы будут замечены только после перезапуска сервера.
Соответсвенно, я стал выяснять, нельзя ли что-то похожее реализовать в связке postfix/dovecot. В процессе изысканий выяснилось, что умничка dovecot умеет работать со можеством passwd-ike файлов. По шаблону. В версии 1.0.x это будет выглядеть
так (из минусов - файлы будут перечитываться каждый раз заново, а может, только если mtime менялся - нужно смотреть сам код):
passdb passwd-file {
args = /mail/%d/%n/settings
}
где :%d, как вы догадались, домен, а %n - имя аккаунта.
Красота? Красота. Уже довольно похоже на файловую структуру CGP.
Но этого, конечно, маловато. Нам недостаточно только логина и пароля. А что делать с квотой и пр? Это тоже пока не из области фантастики, благодаря гибкости довекота:
userdb passwd-file {
args = /mail/%d/%n/settings
}
userdb prefetch {
}
Последний пункт, according documentation, попытка выйграть
некоторое кол-во тактов процессора, возвращая вместе с паролем
дополнительную информацию об аккаунте. Один запрос вместо двух. Все это вобщем-то есть в вики.
Вот, например, что мы еще можем хранить в passwd-like файле:
# cat /mail/skymail.local/hensen/settings
hensen:{plain}test:2000:2000::::userdb_nice=10 userdb_quota=maildir:storage=2048 quota=maildir:storage=2048
Пояснять отдельные моменты не буду, отмечу лишь, что home задается mail_loction, но можно и здесь. Плюс, что нам дает еще эта схема? Возвращять один uid на пользователя, если нужно, а можно один для домена. Что хорошо для виртуального хостинга, для использования общей файловой квоты на аккаунты. В общем, наметки выглядят довольно вкусно, если еще учитывать возможности плагина xexec, о котором я напишу отдельным постом. Получается, на этой базе можно выстроить хорошую конфигурацию pop3/imap сервера, дополнительно используя namespaces и managesieve. Да,
к довекоту есть интерфейс managesieve, правда на данный момент отдельным патчем. К версии 2.0, которая пока неизвестно, когда
будет, Timo Sirainen предполагает переработать патч и включить в основную ветку.
А что, собственно, делать с postfix? Каким он боком будет в этой схеме? На часть вопросов ответ у меня есть. Из-за других, я собственно и стал рассматривать другие варианты хранилища.
Первая - хорошая новость. Postfix c версии 2.3 может использовать
процесс dovecot-auth для авторизации (через sasl) пользователей.
Одним зайцем меньше. Что существенно. Но остаются самые большие зайцы. Как вписывать в эту схему алиасы и домены я пока не придумал. Использовать для них отдельное хранилище? Дублируются данные и встает вопрос о необходимости постоянной синхронизации. Мне этот вариант не нравится. Пришлось гнать от себя прочь всякие
извращенные мысли,типа inotify демона, который будет отслеживать
изменения файлов settings,aliases в этих каталогах и обновлять базу
postfix’а. Или демона, который будет считывать информацию из каталогов домена и по tcp будет отвечать postfix’у.
Т.к. Postfix поддерживает такой тип таблиц в девел версии: tcp:
Но это ни разу не production решения.
Все должно быть проще. Чем больше компонентов в системе, тем больше шансов, что что-то отвалится. Может быть в будущих версиях postfix’а что-то изменится к лучшему, а может найдется решение, которое вроде бы перед глазами, но я его пока не вижу.