Проекты

Надеюсь со временем в этом разделе появятся подразделы, а пока проект всего один -

LDAP-ориентированная почтовая служба
со следующими возможностями:

Содержание

  1. Предпосылки
  2. Средства
  3. Как это должно работать
  4. Задачи
  5. Схема службы каталогов
  6. Управление учётными записями пользователей
  7. Средства установки и конфигурирования

1. Предпосылки

В настоящий момент я работаю в издательстве, которое несмотря на то, что и так является одним из крупнейших издательств России, продолжает быстро расти, и, как следствие, в разных городах России, Украины и Белоруссии появляются и растут новые филиалы. Филиалы обзаводятся локальными сетями. У пользователей в этих филиалах со временем возникает потребность в доступе к Интернету. Поначалу пользователям достаточно модемного подключения, потом их апетиты растут, и в офис проводится выделенная линия. Встаёт задача предоставления пользователям сервиса электронной почты.

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

user_name@provider_name.ru

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

Можно разместить все ящики на почтовом сервере центрального офиса, но такое решение вряд ли можно назвать хорошо масштабируемым. Однако эта идея не лишена смысла, особенно если наделить центральный сервер способностью маршрутизировать предназначенную для филиалов почту на другие серверы, а не помещать её сразу в локальные почтовые ящики. Попробуем её развить. Итак...

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

user_name@company_name.ru

Что обязательно должно понравится начальству, пекущемуся об имидже фирмы. Кроме того, на центральном сервере можно разместить почтовые ящики тех пользователей, которые работают из дома или постоянно находятся в коммандировках, и обеспечить доступ к этим ящикам по протоколам POP3, IMAP4 или через web-интерфейс. Однако для нас это означает необходимость решения следующих задач:

Первая задача лучше всего решается делегированием полномочий по управлению аккаунтами системным администраторам филиалов, а вторая - введением репликации информации об аккаунтах на вторичные резервные серверы.

2. Средства

Для реализации вышеописанной почтовой системы и решения возникших задач, по моему мнению, могут подойти следующие программные средства:

В качестве операционной системы, но мой взгляд, лучше всего воспользоваться Debian GNU/Linux.

Почему OpenLDAP?

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

Почему Exim?

Exim - один из лучших MTA на сегодняшний день, обладающий возможностью очень гибкой и тонкой настройки, включая поиск конфигурационной информации в базах данных и, самое главное, на LDAP-сервере. Кроме того Exim поддерживает mailquota и почтовые ящики в формате Maildir. Для пользователей, работающих из дома, полезной окажется поддержка SMTP AUTH и TLS, дающая возможность отправлять почту с динамически-получаемого IP-адреса в защищенном режиме.

Почему Courier?

Во-первых, потому что Courier поддерживает аутентификацию через LDAP. Во-вторых, в Courier реализована работа протоколов IMAP и POP через SSL. Ну, и кроме того, в дистрибутив Courier уже включена CGI-программа доступа к почтовым ящикам через web-интерфейс - SqWebMail.

Почему Debian?

Конечно, выбор той или иной операционной системы - это во многом дело вкуса и привычки, но для меня решающее значение имеют простота сопровождения и функциональность системы управления пакетами. Все это присутствует в Debian в куда большей степени, чем в других дистрибутивах Linux и даже в BSD-like системах.

3. Как это должно работать

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

  1. В головном офисе и во всех филиалах устанавливаются LDAP-серверы.
  2. LDAP-сервер головного офиса настраивается для работы в качестве корневого сервера для ветви DIT dc=company_name,dc=com. Ветви DIT, содержащие информацию об объектах в тех филиалах, которые подключены к Интернету, делегируются LDAP-серверам филиалов посредством следующих записей-ссылок
    dn: dc=branch_name,dc=company_name,dc=com
    objectClass: referral
    objectClass: extensibleObject
    dc: branch_name
    ref: ldap://branch2.company_name.com/dc=branch_name,dc=company_name,dc=com
  3. LDAP-серверы филиалов, имеющих постоянное подключение к Интернету, настраиваются для обслуживания ветвей dc=branch_name,dc=company_name,dc=com.
  4. В качестве вышестоящего LDAP-сервера в файле конфигурации указывается корневой LDAP-сервер головного офиса.
  5. Если филиалы имеют подключены к Интернету по медленному каналу, то поиск в службе каталогов, очевидно, будет производиться медленно. Поэтому необходимо рассмотреть возможность репликации ветвей DIT на остальные LDAP-серверы. Или для филиалов с медленным подключением применять схему, используемую в случае филиалов без постоянного подключения.
  6. Для того, чтобы информация корпоративной службы каталогов была доступна в филиалах, подключающихся к Интернету эпизодически, будет лучше, видимо (лучшего решения я пока не знаю), использовать схему вытягивания данных с корневого сервера: раз в сутки на корневом LDAP-сервере генерировать файл в формате LDIF и забирать его скриптом, запускаемым по крону на сервере филиала. К сожалению, главный недостаток - необходимость централизованного управления аккаунтами пользователей на сервере головного офиса. Впрочем, этот недостаток может быть устранен, если дать возможность сисадминам таких филиалов управлять информацией в некоторой ветви DIT удаленно (например, посредством web-интерфейса).

Однако мы не можем достичь высокой надёжности, используя подобную схему. Очевидно, что репликация LDAP-базы является необходимой. В настоящий момент я пробую настроить LDAP-серверы для одновременной работы в качестве master-сервера для ветви DIT, которая соответствует тому филиалу, в котором находится данный LDAP-сервер, и в качестве slave-сервера для ветвей, соответствующих другим филиалам. Сказанное поясняется рисунком.

области ответственности ldap-серверов

Рис.1 Области ответственности LDAP-серверов.

Рассмотрим LDAP-сервер в филиале branch1. Этот LDAP-сервер будет содержать информацию обо всех пользователях во всех филиалах, но master-сервером он будет только для ветви dc=branch1,dc=company_name,dc=com. В задачи демона slurpd, запущенного на этом сервере, входит репликация ветви ou=People,dc=branch1,dc=company_name,dc=com (помечена зеленым цветом) на LDAP-серверы в других филиалах. Для всех остальных ветвей ou=People,*,dc=company_name,dc=com (помечены желтым цветом) данный LDAP-сервер является slave'ом. Таким образом в случае обрыва линии, например, до сервера филиала branch2 информация об учетных записях в этом филиале все равно будет доступна во всех остальных филиалах, а системные администраторы этих остальных филиалов по прежнему будут иметь возможность модифицировать учетные записи своих пользователей.

Для построения транспортной инфраструктуры проделываются следующие действия:

  1. Для домена company_name.com в DNS в качестве почтовых релеев прописываются почтовые сервера головного офиса и тех офисов, которые имеют постоянное подключение к Интернету.
  2. Exim, принимая почту, на основе адреса получателя производит запрос к локальному LDAP-серверу с целью выяснить, как следует обработать полученное сообщение.
  3. Если в LDAP не находится записей, содержащих указанный адрес получателя, письмо в обработку не принимается.
  4. Если в найденой записи имеется атрибут mailRoutingAddress, письмо перенаправляется на адрес, указнный в атрибуте mailRoutingAddress.
  5. Если в найденой записи содержимое атрибута mailHost соответствует доменному имени принявшего письмо сервера, оно кладется в локальный почтовый ящик.
  6. Если в найденой записи содержимое атрибута mailHost не соответствует доменному имени принявшего письмо сервера, оно отправляется напрямую серверу имя которого содержится в mailHost.
  7. Если в найденой записи содержимое атрибута mailHost не соответствует доменному имени принявшего письмо сервера, атрибут mailDeliveryOption содержит значение offline, это означает, что письмо предназначено для филиала, не имеющего постоянного подключения к Интернету. В этом случае письмо помещается в почтовую очередь Exim для отправки на такой сервер специальным smtp-транспортом (имеется в виду транспорт в терминах файла конфигурации Exim), предназначенным для обслуживания dial-up серверов: почтовые серверы в филиалах, не имеющих постоянного соединения с Интернетом, периодически подключаются к Сети и опрашивают все почтовые сервера филиалов, имеющих постоянное подключение к Интернету, используя SMTP-команду ETRN, чтобы забрать, предназначенную для них почту.

После того, как письмо успешно помещено в почтовый ящик, пользователи могут получить доступ к нему либо по IMAP4, либо по POP3, либо через web-интерфейс. Весь этот сервис доступа к ящикам обеспечивается с помощью пакета Courier, чьё главное достоинство - аутентификация пользователей через LDAP.

Для повышения уровня безопасности предлагается использовать везде, где это возможно шифрование соединений с помощью SSL: запрещается использование "plain" POP3 и IMAP4 для пользователей, работающих дома; доступ к web-интерфейсу осуществляется исключетельно по HTTPS; все почтовые серверы компании для почтового обмена друг с другом должны использовать TLS и, по возможности, аутентификацию по CRAM-MD5.

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

4. Задачи

Как можно было заметить, развертывание такой распределенной системы и её конфигурирование не самая простая задача. Поэтому попробуем разобраться в том, какие шаги необходимо предпринять, чтобы максимально эту задачу облегчить. Очевидно, что часть проблемы - это выбор схемы службы каталогов, которая более или менее будет стандартной. Далее - реализация средств доступа к LDAP-серверу для добавления, редактирования и удаления записей. И наконец, были бы очень полезны средства для более удобной инсталляции и конфигурирования LDAP-сервера, Exim и Courier. К сожалению, те инсталляционные скрипты, которые выполняют первоначальную конфигурацию указанных пакетов не вполне функциональны в том смысле, что для нетривиальной настройки требуют серьёзной правки файлов конфигурации уже после инсталляции.

5. Схема службы каталогов

Для достижения заданной функциональности совершенно необходимыми окажутся стандартные схемы CORE, COSINE, NIS и inetOrgPerson. Однако данные схемы не содержат атрибутов, необходимых для реализации маршрутизации почты. К сожалению, у меня нет информации о существовании стандартных схем, предназначенных для маршрутизации почты, поэтому я позволил себе составить собственную схему на основании документа "LDAP Schema Definitions for Intranet Mail Routing - The mailRecipient Object Class", в котором определён класс объектов mailReceipient.

Составленная мной схема содержит всего один класс объектов - mailReceipient. Однако я решил пока не создавать дополнительный класс, а дополнить класс mailReceipient несколькими атрибутами, которые присутствуют в схеме, используемой в Netscape Messaging Server.

Если вам известно, что класс mailReceipient уже стандартизирован, то, пожалуйста, дайте мне об этом знать.

6. Управление учётными записями пользователей

Для реализации средств управления аккаунтами я предпочел использовать самостоятельно разрабатываемое web-приложение вместо имеющихся в настоящее время программ редактирования LDAP-базы, например, Directory administrator или GQ. Использование web-интерфейса имеет два решающих для меня преимущества:

Эти преимущества проявляются в полной мере тогда, когда системному администратору филиала, не имеющего постоянного подключения к Интернету, требуется предоставить доступ к управлению ветви DIT, содержащей информацию об аккаунтах пользователей такого филиала.

В качестве средства разработки были выбраны PHP4 и библиотека PHPLib. В php4 реализованы функции для работы с LDAP. В PHPLib имеются готовые классы для управления сеансами работы пользователей и аутентификацией.

В настоящее программа находится в стадии разработки, однако кое-что уже сделано и работает. Схема её работы пока такова:

  1. все пользователи входят в те или иные группы (атрибут posixGroup)
  2. среди всех групп пользователей, существует две привилегированные группы:
    • powerusers,
    • supervisors.
  3. Пользователи, входящие в первую группу имеют право создавать и редактировать новые аккаунты для пользователей и помещать их в непривилегированные группы.
  4. Пользователи, входящие в группу supervisors, имеют полный доступ к созданию и редактированию любых пользовательских аккаунтов, включая тех, которые входят в группы powerusers или supervisors.
  5. Все остальные пользователи имеют право только изменять свой пароль.

Посмотреть на систему управления можно здесь. Чтобы вы могли составить хоть какое-то представление о системе, я создал пользователя test с паролем test. Вы можете изменить пароль, но огромная просьба вернуть впоследствие пароль test на место. Доступ к почтовому ящику [email protected] возможен по протоколам pop3s, imaps (сервер mail.rojkov.spb.ru), а также через web-интерфейс SqWebMail. Я не очень доволен SqWebMail и хочу сделать собственную реализацию, но это произойдёт только тогда, когдя я смогу посвящать больше времени этому проекту.

Чтобы функциональность системы управления аккаунтами была достаточной для полной реализации описываемой почтовой системы я планирую добавить поля для атрибутов mailQuota и mailDeliveryOption. А также добавить возможность раздельного доступа к записям ветвей DIT, принадлежащим филиалам без постоянного подключения к Интернету.

7. Средства установки и конфигурирования

В данный момент я считаю, что проще будет не создавать отдельный большой инсталляционный пакет, а воспользоваться штатными средствами, которые предоставляет Debian. То есть взять за основу те deb-пакеты, что уже есть и модифицировать в них инсталляционные скрипты, используя все возможности debconf, и поместить модифицированные пакеты в отдельный apt-репозитарий.

to be continued...