Обзор таблиц поиска PostfixОбзор таблиц поиска PostfixPostfix использует таблицы для хранения и поиска информации по управлению доступом (access control), правке адресов (address rewriting) и фильтрации содержимого (content filtering). Все таблицы поиска Postfix указываются, как "type(тип):table(таблица)", где "type(тип)" - это один из типов, описанных в параграфе ""Типы таблиц поиска Postfix"", а "table(таблица)" - имя таблицы поиска. В документации Postfix термины "таблица поиска" и "база данных" подразумевают одно и то же.
Примеры таблиц поиска, которые часто встречаются в документации Postfix:
/etc/postfix/main.cf:
alias_maps = hash:/etc/postfix/aliases (локальные алиасы)
header_checks = regexp:/etc/postfix/header_checks (фильтрация содержимого)
transport_maps = hash:/etc/postfix/transport (таблица маршрутов для почты)
virtual_alias_maps = hash:/etc/postfix/virtual (правка адресов)
Все таблицы поиска Postfix хранят информацию в виде пары (ключ, значение). Это представление данных может показаться примитивным, на первый взгляд, но в действительности является весьма мощным и эффективным решением. Интерфейс запросов (ключ, значение) полностью скрывает сложные структуры данных LDAP или SQL от Postfix-а. Это хороший пример взаимодействия сложных систем через простой интерфейс.
Преимущества интерфейса запросов Postfix-а (ключ, значение):
Большинство таблиц Postfix-а используются для поиска информации. Например, при правке адресов (address rewriting) (строка поиска - это старый адрес, результат поиска - новый) или при управлении доступом (строка поиска - клиент, отправитель или получатель, а результат - действие, например "отклонить"("reject")).
В некоторых таблицах, тем не менее, Postfix-у важно лишь существование ключа поиска, а результат поиска не используется. Например, таблица local_recipient_maps, которая определяет локальных получателей (для них Postfix принимает почту из сети), или параметр mydestination, указывающий домены, для которых Postfix доставляет почту локально. Параметр mynetworks содержит адреса авторизованных клиентов или подсетей. Чисто технически это списки, а не таблицы. Несмотря на разницу, списки Postfix описаны здесь, так как они опираются на ту же инфраструктуру, что и таблицы поиска.
LDAP и SQL - сложные системы. Попытка "сходу" заставить их работать вместе, вероятно, не самая хорошая идея. Вы можете избежать напрасной траты времени, изначально настроив Postfix для работы с локальными файлами, такими, как Berkeley DB. При работе с локальными файлами гораздо сложнее сделать ошибку. Проблемы легко отлаживаются с помощью команды postmap(1):
% postmap -q info@example.com hash:/etc/postfix/virtual
Как только Вы добились корректной работы Postfix с локальными базами, можете следовать инструкциям в файлах ldap_table(5), mysql_table(5) или pgsql_table(5) и заменить поиск в локальных файлах на поиск в LDAP или SQL. Как только Вы сделали это, необходимо использовать команду postmap(1), чтобы убедиться, что запросы к базе данных выдают корректные результаты (т.е. те же, что выдавал поиск в локальных файлах):
% postmap -q info@example.com ldap:/etc/postfix/virtual.cf
Убедитесь, что правильно функционируют все отдельные запросы почтовых адресов, доменов, которые описаны в разделе "порядок поиска в таблицах (table search order) " соответствующих страниц руководства (man pages): access(5), canonical(5), virtual(5),transport(5), или в руководстве к соответствующему конфигурационному параметру: mynetworks, relay_domains, parent_domain_matches_subdomains.
Желательно, чтобы Postfix не считывал данные из таблиц поиска во время их изменения Вами. Также было бы неплохо вносить изменения в таблицы без необходимости последующего выполнения "postfix reload", чтобы заставить Postfix использовать новую информацию. Каждый раз при выполнении "postfix reload" почтовый сервер теряет производительность.
Если Вы вносите изменения в сетевую базу данных (LDAP, NIS или SQL), то нет необходимости выполнять "postfix reload". LDAP, NIS или SQL позаботятся о конфликтах доступа при чтении/записи и выдадут новые данные Postfix-у, как только они будут готовы.
Если Вы редактируете файлы regexp: или pcre:, Postfix может подхватить, а может и не подхватывать изменения немедленно. Такое поведение связано с тем, что процесс Postfix-а считывает весь файл в память и не проверяет его на наличие изменений впоследствии.
Если файл используется короткоживущими процессами, как, например, smtpd(8), cleanup(8) или local(8), то нет необходимости выполнять "postfix reload" после внесения изменений.
Если файл используется долго функционирующим процессом, как, например, trivial-rewrite(8) на загруженном сервере, то, вероятно, понадобится выполнение команды "postfix reload".
Если Вы меняете локальную базу данных типа DBM или Berkeley DB, то нет необходимости выполнять "postfix reload". Postfix использует блокировки файлов, чтобы избежать конфликтов чтения/записи. Как только демон Postfix-а понимает, что файл изменен, он завершает свою работу перед выполнением следующего клиентского запроса, чтобы вновь запущенный процесс прочитал обновленную базу.
Несмотря на то, что Postfix использует блокировки файлов, чтобы избежать конфликтов доступа во время обновления Berkeley DB или других локальных файлов баз данных, у Вас все еще остаются проблемы, когда обновление срывается из-за нехватки места на диске или другой непредвиденной неприятности. Это связано с тем, что команды типа postmap(1) или postalias(1) переписывают существующие файлы. Если обновление срывается на полпути, то у Вас не остается функционирующей базы данных, соответственно, Postfix перестает функционировать. Это не проблема с базами данных CDB, доступных в Postfix, начиная с версии 2.2, так как ребилд (rebuild) в CDB - атомарная операция.
В случае с базами, хранящими данные в нескольких файлах (таких, как DBM), нет простого решения. С Berkeley DB и другими "однофайловыми" базами данных, можно добавить некоторую отказоустойчивость, используя "mv" чтобы ЗАМЕНЯТЬ существующий файл базы вместо его перезаписи:
# postmap access.in && mv access.in.db access.db
Эта строка конвертирует входной файл "access.in" в "access.in.db", а потом заменяет "access.db" файлом "access.in.db", но только в случае успешного завершения команды postmap(1). Безусловно, набор таких длинных команд быстро надоедает (и есть вероятность допустить ошибку - прим.перев.), поэтому весьма удобно для автоматизации использовать утилиту "make", как показано ниже. Пользовательский ввод выделен жирным шрифтом.
# cat Makefile all: aliases.db access.db virtual.db ...etcetera... # Примечание 1: команды в файле указываются после символа TAB. # Примечание 2: используйте postalias(1) для локальных алиасов, postmap(1) для остального. aliases.db: aliases.in postalias aliases.in mv aliases.in.db aliases.db access.db: access.in postmap access.in mv access.in.db access.db virtual.db: virtual.in postmap virtual.in mv virtual.in.db virtual.db ...etcetera... # vi access.in ...сессия редактирования не показана... # make postmap access.in mv access.in.db access.db #
Команда "make" обновляет только файлы, в которые были внесены изменения. В случае ошибки, "make" остановится и не будет производить перемещение (замену) командой "mv", таким образом Postfix продолжит использование старой базы, как будто ничего не произошло.
Чтобы определить типы баз данных, которые поддерживает Ваша система, используйте команду "postconf -m". Ниже приведен список типов таблиц поиска, которые зачастую поддерживаются:
- btree
- Отсортированная, сбалансированная древовидная структура. Доступна лишь на системах, которые поддерживают базы данных Berkeley DB. Файлы базы создаются командами postmap(1) или postalias(1). Имя таблицы поиска, которое используется в "btree:table", - это имя файла базы данных без суффикса ".db".
- cdb
- Структура, оптимизированная для чтения, без поддержки инкрементных обновлений. Файлы базы создаются командами postmap(1) или postalias(1). Имя таблицы поиска, которое используется в "cdb:table", - это имя файла базы данных без суффикса ".cdb". Эта возможность присутствует в Postfix, начиная с версии 2.2.
- cidr
- Таблица, в которой значения ассоциируются с адресами безклассовой междоменной маршрутизации (Classless Inter-Domain Routing - CIDR). Этот формат базы данных описан в файле cidr_table(5).
- dbm
- Это индексированный тип файла, основанный на хешировании. Он доступен только на системах, которые поддерживают базы данных DBM. Файлы базы создаются командами postmap(1) или postalias(1). Имя таблицы поиска, которое используется в "dbm:table", - это имя файла базы данных без суффикса ".dir" или ".pag".
- environ
- Поиск в массиве переменных окружения UNIX-процесса. Ключ поиска - это имя переменной. Имя таблицы поиска в "environ:table" игнорируется.
- hash
- Это индексированный тип файла, основанный на хешировании. Он доступен только на системах, которые поддерживают базы данных Berkeley DB. Файлы базы создаются командами postmap(1) или postalias(1). Имя таблицы поиска, которое используется в "hash:table", - это имя файла базы данных без суффикса ".db".
- ldap (только чтение)
- Производит поиск, используя протокол LDAP. Детали конфигурации описаны в файле ldap_table(5).
- mysql (только чтение)
- Производит запросы к базе данных MySQL. Детали конфигурации описаны в файле mysql_table(5).
- netinfo (только чтение)
- Производит поиск в базе данных Netinfo.
- nis (только чтение)
- Производит поиск в базе данных NIS.
- nisplus (только чтение)
- Производит поиск в базе данных NIS+. Детали конфигурации описаны в файле nisplus_table(5).
- pcre (только чтение)
- Таблица поиска, основанная на Perl-совместимых регулярных выражениях (Perl Compatible Regular Expressions - PCRE). Формат файла описан в pcre_table(5). Имя таблицы поиска, которое используется в "pcre:table", - это имя файла, содержащего регулярные выражения.
- pgsql (только чтение)
- Производит запросы к базе данных PostgreSQL. Детали конфигурации описаны в файле pgsql_table(5).
- proxy (только чтение)
- Получает доступ к информации через сервис Postfix-а proxymap(8). Синтаксис таблицы поиска имеет следующий вид: "proxy:type:table".
- regexp (только чтение)
- Таблица поиска, основанная на регулярных выражениях. Формат файла описан в regexp_table(5). Имя таблицы поиска, которое используется в "regexp:table", - это имя файла, содержащего регулярные выражения.
- sdbm
- Это индексированный тип файла, основанный на хешировании. Он доступен только на системах, которые поддерживают базы данных SDBM. Файлы базы создаются командами postmap(1) или postalias(1). Имя таблицы поиска, которое используется в "sdbm:table", - это имя файла базы данных без суффикса ".dir" или ".pag".
- static (только чтение)
- Всегда возвращает имя таблицы, как результат поиска. Например, таблица поиска "static:foobar" всегда возвращает строку "foobar" в качестве результата.
- tcp
- Получает доступ к информации на TCP/IP сервере. Протокол описан в файле tcp_table(5). Имя таблицы поиска "tcp:host:port", где "host" содержит символьное имя или IP адрес, а "port" - символьное имя сервиса или числовое значение порта. Этот протокол недоступен в Postfix до версии 2.2 включительно.
- unix (только чтение)
- Ограниченный способ запрашивать информацию в аутентификационной базе UNIX. Реализованы следующие таблицы поиска:
- unix:passwd.byname
- Таблица - это база данных паролей UNIX (password database). Ключом является имя пользователя (логин, login name). Результат - запись файла паролей (password file) в формате passwd(5).
- unix:group.byname
- Таблица - это база данных паролей UNIX (password database). Ключом является имя группы. Результат - запись файла групп (group file) в формате group(5).
Другие таблицы поиска могут присутствовать в зависимости от способа компиляции (сборки) Postfix. В некоторых дистрибутивах Postfix список типов динамически расширяем, так как поддержка таблиц поиска динамически включается (dynamically linked) в Postfix.
