 |
|
|
|
Почтовая система для среднего и малого офиса
Почтовая система для среднего и малого офиса Недавно один из знакомых администраторов попросил помочь ему в создании почтовой системы для фирмы, в которой он работает. Подумав о сакраментальном слове RTFM и вспомнив, что недавних переселенцев с Windows надо поощрять, я все же решил поискать для него хорошую документацию, подробно описывающую то, что ему предстоит выполнить. Побродив некоторое время в сети, я с удивлением обнаружил отсутствие того, за чем пришел. Не то чтобы документации не было совсем. Скорее, ее было даже слишком много. Очень часто мне на глаза попадались продвинутые статьи, описывающие настройку магистральных систем, способных работать в качестве почтовых серверов крупных интернет-провайдеров. Встречались тексты, объясняющие способы взаимодействия почтовой системы с SQL-, RADIUS-, LDAP-серверами. Для нашего случая все эти ухищрения были чрезмерны. К сожалению, подробной инструкции по настройке почтовой системы для малого и среднего офиса так и не было найдено. Свою систему мы будем строить на основе FreeBSD 4.5. В тоже время практически все описанное далее после мелких исправлений будет работать во многих других UNIX-подобных системах. Главное, чтобы для целевой системы удалось найти версии программ postfix, popa3d, drweb, pflogsumm. Кратко обсудим, зачем нужен каждый из этих компонентов. Postfix будет обеспечивать принятие входящих и отправку исходящих сообщений по протоколу smtp. Обычно программы такого типа называют MTA – Mail Transfer Agent. Popa3d позволит пользователям читать полученную почту. С помощью drweb мы будем проверять на вирусы все проходящие через нас письма. Для того чтобы знать, насколько хорошо функционирует построенная нами система, нужно собирать статистику ее работы. К тому же при случае начальству можно показать, что не зря ешь свой хлеб с маслом. Выполнять это полезное действо мы будем с помошью pflogsumm. Стоит обратить внимание, что машина, на которой все это устанавливается, имеет два сетевых интерфейса 192.168.10.252 и 80.80.120.163. Первый направлен во внутреннюю подсеть. К сожалению, авторизации на основе пароля и имени пользователя для протокола smtp у нас не будет. Отправка писем будет разрешена всем пользователям сети 192.168.10.0. С другой стороны, для малых и средних сетей в большинстве случаев этого не потребуется. Соответственно, через второй интерфейс мы будем общаться с внешним миром. Также стоит помнить, что для авторизации по pop3 мы будем использовать имена и пароли пользователей, хранящиеся в файле /etc/passwd. А это значит, что при необходимости создания новых почтовых аккаунтов мы должны добавлять новых пользователей системы с помощью программы useradd. В качестве кандидатов на место smtp-демона рассматривались exim, postfix, qmail, sendmail. Давайте кратко рассмотрим достоинства и недостатки каждого из них. Стоит оговориться, что все нижеизложенное является всего лишь моим личным мнением. Как говорится, вольному – воля, поэтому читатель может на свой страх и риск использовать в качестве MTA все что ему заблагорассудится. Sendmail является самым старым MTA из нашего списка. Несмотря на впечатляющий и мощный функционал, его пришлось отбраковать сразу же. В первую очередь, произошло это из-за того, что программа представляет из себя один монолитный блок. По этой же причине за ней тянется огромный шлейф уязвимостей и проблем с быстродействием. Вторым недостатком является процедура конфигурирования. Перспективы программы, для создания простейшей конфигурации которой необходимо некоторое время повозиться с компилятором m4, по моему мнению, выглядят весьма грустно. Хотя старый монстр все еще не сдается по причине многочисленности своих приверженцев. Заключительным гвоздем в гроб Sendmail послужило то, что использование его для офиса среднего размера похоже на погоню за мухой с молотом в руках. В то же время самый безопасный из претендентов qmail мне не понравился слишком жесткой иерархией запуска служебных программ. Для выполнения каждого класса своих задач он порождает дочерние процессы специальных программ. После выполнения задачи процесс дочерней программы уничтожается. С одной стороны, это обеспечивает безопасность и запас прочности программы, но с другой – создает некоторые накладные расходы на постоянное создание дочерних процессов и межпроцессорное взаимодействие. К тому же лично мне развитие проекта qmail кажется слишком медленным. Приступив к осмотру Exim, с огорчением замечаю, что процесс установки, на мой взгляд, все же довольно нетривиален и не особенно подходит новичкам мира UNIX. Для включения тех или иных возможностей приходится редактировать Makеfile. Да и сам процесс последующей настройки показался мне слегка странным. Если не обращать внимания на описанные только что недостатки, то мощный функциональный потенциал, заложенный в эту программу, вас очень обрадует. Postfix, являющийся ближайшим конкурентом qmail, делает упор на быстродействие и безопасность. Принципы деления выполняемой задачи очень похожи на те, что применяются в qmail, но дизайн системы совершенно другой. Основой идеологии postfix является наличие независимых резидентных модулей. Ни один из модулей не является дочерним процессом другого. В то же время за счет постоянного присутствия модулей в памяти каждый из них может независимо пользоваться услугами других. Проект postfix на данный момент является самым динамично развивающимся из всех перечисленных. Покончив с теорией, приступим к осуществлению наших планов. Для работы с исходными текстами всего скачанного программного обеспечения я буду использовать директорию /tmp. Читатель может выбрать любую другую. Приступим к установке postfix. Нужно создать группы postfix и postdrop. А затем в группу postfix добавить пользователя по имени postfix. Почтовая система будет работать с правами пользователя postfix, а группа postdrop будет владеть очередью сообщений. Наличие двух групп и одного пользователя увеличивает запас прочности и безопасности демона smtp. В зависимости от вашей операционной системы действия по созданию пользователя можно будет выполнить с помощью команды adduser или useradd. После успешного создания пользователя и групп принимаемся за установку postfix. Во время установки всего программного обеспечения нами будет создан еще один служебный пользователь. Нужно убедиться, что никто не сможет войти в систему, пользуясь всеми вышеупомянутыми аккаунтами. Для этого в качестве рабочей оболочки в файле /etc/passwd определяем для них /sbin/nologin. Берем postfix-2.0.0.2.tar.gz с официального сайта проекта www.postfix.org и как обычно распаковываем и устанавливаем: # tar zxvf postfix-2.0.0.2.tar.gz # cd postfix-2.0.0.2 # make tidy # make # make install Теперь нужно дать ответы на несколько вопросов, задаваемых во время инсталляции. В большинстве случаев нужно просто нажать ENTER, подтверждая использование настроек, предлагаемых по умолчанию. Корневой каталог файловой системы, используемой для установки:
Сюда будут падать временные файлы, создаваемые в процессе инсталляции:
Тут будут находиться файлы настроек postfix:
А здесь будет лежать выполняемый файл демона postfix:
Тут будут располагаться выполняемые файлы административных команд postfix:
Директория, в которой будет находиться очередь писем, обрабатываемых postfix:
Путь к команде, используемой взамен стандартного sendmail:
Путь к исполняемому файлу, используемому для перестройки почтовых псевдонимов:
Путь к команде, отображающей состояние почтовой очереди:
Имя пользователя, с правами которого работает почта:
Группа, от имени которой будут работать команды обработки почтовой очереди:
В этой директории находится база документации на все устанавливаемые программы:
Директория, в которую нужно положить примеры конфигурационных файлов postfix. Смешивать примеры с реальными файлами конфигурации охоты нет. Поэтому вводим имя директории /etc/postfix/sample/:
Директория, куда нужно положить файлы документации. Выбираем имя директории /etc/postfix/readme/:
По завершению установки приступим к настройке. Конфигурационные файлы postfix находятся в директории /etc/postfix/. Все настройки, которые нам нужно поменять, находятся в файле /etc/postfix/main.cf. Большинство опций можно оставить со значениями по умолчанию. Я опишу только те из них, которые нужно изменять. Итак, приступим: myhostname = mail.test.ru # Имя нашего хоста. Лучше всего устанавливать в соответствии с выводом, получаемым после выполнения команды hostname. mydomain = test.ru # Имя нашего домена. Рекомендуется описать явно. Если переменная не определена, то postfix будет использовать # значение myhostname минус первый компонент. inet_interfaces = 192.168.10.252, 80.80.120.163 # Адреса интерфейсов, на которых нужно ждать smtp-соединений. Для упрощения конфигурации можно использовать слово all # для установки прослушивания всех интерфейсов. Также можно использовать переменные localhost и $myhostname. Тогда # будут задействованы интерфейсы 127.0.0.1 и адрес, соответствующий имени, определенному в переменной $myhostname. mydestination = $myhostname, $mydomain # Список доменов, которыми себя считает эта машина. То есть почта, приходящая для пользователей описанных доменов, # не отправляется куда-либо, а разбирается локально. mynetworks = 192.168.10.0/24, 127.0.0.0/8 # Определяем список доверенных сетей. Клиенты с адресами, принадлежащими этим сетям, смогут рассылать через нас # почту. Если этот параметр не определен, то доверенной сетью считается IP-подсеть, к которой принадлежит машина # с postfix. alias_database = dbm:/etc/mail/aliases.db # Путь к файлу почтовых псевдонимов. Сохранив изменения, считаем что настройка postfix закончена. Еще одним важным шагом является настройка почтового псевдонима пользователя root. Нам необходимо сделать так, чтобы все письма, приходящие пользователю root, перенаправлялись пользователю tigrisha. Открываем файл /etc/mail/aliases и ищем подобную строку. root: Затем заменяем на вот такое: root: tigrisha@test.ru Сохранив файл c помощью команды newaliases, выполняем перестройку системной базы почтовых псевдонимов, находящейся в файле /etc/mail/aliases.db Покончив с настройками, проверим нашу конфигурацию. # postfix check Если ошибок не появилось, значит, все у нас хорошо. Самое время запустить демона smtp в лице postfix. # postfix start А на другой консоли смотрим, какие сообщения попадают в файл протокола /var/log/maillog. # tail –f /var/log/maillog Должно получиться что-то похожее на эти строчки:
Пришло время проверить, как работает отправка почты. С помощью telnet присоединяемся к локальной системе на 25-й порт. # telnet localhost 25
Затем с помощью команды mail from: указываем серверу, от кого будет письмо: mail from:
Командой rcpt to: задаем адрес получателя: rcpt to:
И наконец, с помощью data начинаем ввод текста письма: data
Закончить ввод текста можно нажав <Enter>, затем “.” и снова <Enter>:
Последнее сообщение, выданное системой, означает, что письмо помещено в очередь на отправку. Все описанные действия можно выполнить любым почтовым клиентом. Хотя я считаю, что администратор должен знать, как выполнить большинство задач по настройке и управлению системой, используя минимум инструментов. На другой консоли смотрим, что система пишет в файл /var/log/maillog. Должны увидеть появление следующих строк:
Если все так и произошло, значит smtp работает как положено. По умолчанию для хранения полученных писем postfix использует формат mailbox. Это означает, что у каждого пользователя есть файл, в котором хранятся все его письма. Обычно он должен находиться в директории /var/mail/. Соответственно для адреса tigrisha@test.ru файл будет называться /var/mail/tigrisha. Посмотрим, как себя чувствует этот файл. # ll /var/mail/
Итак, судя по всему, письмо благополучно попало в нужный файл. Теперь необходимо настроить pop3, для того чтобы пользователи могли забирать почту с сервера. В качестве демона pop3 мы будем использовать popa3d. За этой программой закрепилась слава одного из самых быстрых, надежных и безопасных демонов pop3. К сожалению, процедура установки этой программы из исходного кода очень неудобна. Перед тем как приступить к компиляции, приходится вносить в исходный код множество исправлений, чтобы включить требуемую функциональность. Лично мне не понятно, почему автор не может написать нормальный скрипт configure. Большинству других администраторов такой подход тоже не нравится. Поэтому, оберегая собственные нервы, воспользуемся системой портов. # cd /usr/ports/mail/popa3d/ # make # make install # make clean После успешной инсталляции проверяем, чтобы в файле /etc/services были подобные фрагменты. pop3 110/tcp pop-3 # POP version 3 pop3 110/udp pop-3 В отличие от postfix, демон popa3d не находится постоянно в памяти машины. Вместо этого при каждом входящем соединении он будет запускаться супердемоном. В качестве супердемона чаще всего используются либо inetd, либо xinetd. В моем случае это был именно inetd. А раз так, то нам нужно внести в файл etc/inetd.conf следующий фрагмент: pop3 stream tcp nowait root /usr/local/libexec/popper popper Для того чтобы изменения вступили в силу, нужно перезапустить демон inetd. Ищем номер его процесса. # ps -ax | grep inetd | grep -v “grep”
Получается, что интересующий нас процесс имеет номер идентификатора 86. Вооружившись этими знаниями, перезапускаем inetd. # kill -HUP 86 После перезагрузки наступает самое время протестировать работу демона pop3. Делаем это, как обычно, с помощью telnet. # telnet localhost 110
Командой user указываем серверу, почту какого пользователя мы желаем читать: user tigrisha
Передаем наш сложнейший пароль: pass Sx12DF234
После того как нас авторизовали, посмотрим с помощью команды stat состояние нашего почтового ящика. Судя по ответу сервера, в ящике одно письмо размером 597 байт. Просмотреть содержимое письма можно с помощью команды top 1 20: Stat
Приказываем показать верхние 20 строк первого письма: top 1 20
Налюбовавшись на дело рук своих, уходим: Quit
Процесс получения почты прошел гладко, словно по маслу. На этом можно было бы завершить наши занятия, но все же стоит подумать о безопасности наших пользователей. Давайте приступим к созданию антивирусной защиты для нашего сервера. Как я уже говорил, в качестве антивируса мы будем использовать drweb. Грустный опыт работы с KAV для FreeBSD подтолкнул меня к правильному выбору. Также стоит обратить внимание на отличное качество русской документации, поставляющейся вместе с дистрибутивом drweb. Возможностей, заложенных в пробной версии, которую мы будем использовать достаточно для надежной защиты от вирусов. Для получения обновлений антивирусных баз нам понадобится программа wget. Кроме всего прочего она поможет нам скачивать все необходимое программное обеспечение. Устанавливаем wget, используя механизм портов. #cd /usr/ports/ftp/wget # make # make install # make clean Пользователи других операционных систем могут взять исходный код этой утилиты тут http://www.gnu.org/software/wget/wget.html. С помощью только что установленного wget скачиваем последнюю версию drweb: # /usr/local/bin/wget ftp://ftp.drweb.ru/pub/unix/4.29.5/drweb-4.29.5-freebsd4.tar.gz Если выполнить это действие по каким-либо причинам не удалось, то для скачивания можно воспользоваться любыми другими инструментами. Но все же стоит разобраться, почему произошел такой казус. Иначе в дальнейшем мы не сможем автоматически обновлять антивирусные базы. После окончания закачки, распаковываем полученный дистрибутив. Создаем пользователя drweb, принадлежащего группе drweb. Внимательно читаем инструкции в файле /tmp/drweb-4.29.5-freebsd4/install/opt/drweb/README.RUS. А затем запускаем скрипт инсталляции. # cd drweb-4.29.5-freebsd4 # ./install.sh К сожалению, установить антивирус с помощью стандартного скрипта, да еще и с первого раза мне не удалось. Он все время жаловался, что не может создать директорию /opt/drweb/, поэтому пришлось создать ее вручную. # mkdir /opt # mkdir /opt/drweb/ После этого пошли жалобы на невозможность использования уже созданной директории по причине того, что она уже существует. Ну что же, придется обработать скрипт инсталляции напильником. Открываем install.sh любимым текстовым редактором, ищем такой фрагмент текста. if [ -d "$INPUT" ] ; then echo "Directory $INPUT already exists!" else mkdir $INPUT if [ ! -d "$INPUT" ] ; then echo "Can not create $INPUT!" else INSTALL_DIR=$INPUT fi fi Удаляем или переводим этот фрагмент в комментарии. А вместо него вставляем строку: INSTALL_DIR=$INPUT Сохраняемся, выходим из редактора и запускаем install.sh снова. Теперь нужно по порядку отвечать на вопросы, задаваемые скриптом. Директория инсталляции:
Язык интерфейса. Мне больше нравится английский, поэтому я выбрал «0»:
После завершения установки начинаем редактировать /etc/drweb.ini. Ищем строку: ;User = drweb Удаляем из нее символ «;» и идем дальше. Таким образом мы указываем демону drweb, что он должен работать с правами одноименного пользователя. Итак, антивирус установлен. Запускаем его с помошью файла /opt/drweb/drwebd. Полюбовавшись на сообщения в /var/log/messages, понимаем, что антивирус запустился и работает как надо. Но к сожалению, проку нам от этого пока мало. Для того чтобы подключить его к проверке почты, нужно настроить интерфейс от postfix к drweb. Давайте разберемся, как взаимодействуют друг с другом вышеуказанные программы, проследив весь жизненный цикл письма. На приведенной ниже схеме интересующий нас маршрут прохождения письма помечен синим цветом.
Письмо может войти в postfix двумя способами. C помощью входящего соединения по smtp через демона smtpd. Если же письмо отправлено с локальной машины, то через программу, заменяющую собой sendmail. После этого письмо попадает в модуль cleanup, который занимается проверкой и зачисткой заголовков письма. Затем письмо переходит в модуль queue, который передает его через pipe фильтру postfix-drweb. Фильтр, в свою очередь, сохраняет письмо во временном файле и передает путь к нему клиенту антивируса. Усилиями клиента письмо попадает к демону drweb. В свою очередь, он с помощью набора антивирусных баз проверяет письмо. Если вирусов не найдено, то используя программу, заменяющую sendmail, письмо передается модулю pickup. Затем, вторично пройдя через cleanup и queue, в зависимости от того, где находится получатель, письмо попадает либо в local и доставляется локально, либо в smtp и отсылается на другой сервер. Если drweb считает письмо зараженным, оно переносится в карантин. С помощью программы sendmail письма с уведомлениями о данном неприятном факте направляются всем, кто указан в секции [VirusNotify] файла drweb_postfix.conf. Обычно это администратор, отправитель и получатель. Разобравшись с теорией, приступим к настройке. Берем фильтр drweb для postfix: # /usr/local/bin/wget ftp://ftp.drweb.ru/pub/unix/drweb-postfix-4.29.10-freebsd4.tar.gz В обязательном порядке читаем документацию, поставляемую вместе с фильтром. После распаковки получаем две директории etc и opt. Содержимое директории etc копируем в /etc/drweb/, а файлы из opt соответственно кладем в /opt/drweb/. Создаем директорию, в которую фильтр будет складывать письма, приготовленные для проверки. # mkdir /var/spool/drweb Настраиваем права доступа так, чтобы работать с этой директорией мог только единственный пользователь группы drweb. Аналогичным способом расставляем нужные права на остальные интересные для нас директории. # chmod 770 /var/spool/drweb # chown drweb:drweb /var/spool/drweb # chown -R drweb:drweb /opt # chown -R drweb:drweb /var/drweb/ # chown -R drweb:drweb /etc/drweb/ Теперь нужно указать postfix, что каждое входящее письмо должно проходить через антивирусный фильтр. В файле /etc/postfix/master.cf ищем строку: smtp inet n - n - - smtpd И заменяем ее на вот это: smtp inet n - n - - smtpd -o content_filter=filter:dummy Затем в конец этого же файла добавляем описание нашего фильтра: filter unix - n n - - pipe flags=R user=drweb argv=/opt/drweb/drweb-postfix -f ${sender} -- ${recipient} В файле /etc/drweb/drweb_postfix.conf найти такие строки и вписать в них следующие значения. AdminMail = # почтовый адрес администратора FilterMail = # почтовый адрес демона drweb Перезапускаем postfix c помощью команды restart. Если ошибок на консоли и в файле /var/log/maillog не появилось, значит, все идет как надо. Итак, почтовая система запустилась, но нам нужно проверить, как работает антивирус. Специально для таких целей вместе с drweb поставляется тестовый файл, опознаваемый многими антивирусными программи как вирус. В нем описан так называемый EICAR-вирус. Подробнее об этом имитаторе вируса читайте в документации, поставляемой вместе с drweb. А точнее, в файле /opt/drweb/doc/readme.eicar. Теперь с помощью любого текстового редактора создаем файл test.com, содержащий EICAR-вирус и записываем в него вот такую строку: X5O!P%@AP[4PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS -TEST-FILE!$H+H* Сохраняем полученый файл. С помощью любой почтовой программы пишем себе письмо, прикрепив к нему только что созданный файл test.com. Отправив письмо, получим ответ с уведомлением о том, что мы пытались отправить себе вирус. В письме должны быть строки, подобные нижеследующим:
Итак, антивирусная система работает как положено. К сожалению, вирусописатели не сидят, сложа руки. Каждый месяц появляется несколько десятков новых вирусов. Для того чтобы наша система могла ловить новейшие вирусы, нужно настроить автоматическое обновление антивирусных баз. Выполнение этой важной задачи возложим на /opt/drweb/update.pl, который будет самостоятельно скачивать новые базы. После получения всех баз этот же скрипт будет перезапускать демона drweb. Это делается для того, чтобы демон мог загрузить полученные только что базы. Настраиваем crontab пользователя drweb так, чтобы с помощью вышеописанного скрипта обновление антивирусных баз происходило через каждые 10 часов. # crontab –e –u drweb 00 0-24/10 * * * /opt/drweb/update/update.pl Приближаясь к финишу, необходимо исправить еще несколько ошибок программистов, создававших скрипты для drweb. После перезагрузки FreeBSD запускает на выполнение все скрипты, находящиеся в /usr/local/etc/rc.d/. Во время инсталляции drweb автоматически создал скрипт, который будет выполнять запуск демона drweb после перезагрузки системы. Также у нас появится возможность управлять работой демона с помощью команд stop, reload, start, restart. Рассмотрим каждую из этих команд подробнее.
Вся проблема в том, что создался этот файл не с тем именем, которое нам необходимо. Для FreeBSD он должен называться drweb.sh, а не drweb. # mv /usr/local/etc/rc.d/drweb /usr/local/etc/rc.d/drweb.sh Во-вторых, в операционной системе FreeBSD до версии 4.6 после перезагрузки файл drweb.sh будет выполнен без единого параметра командной строки. Для правильного выполнения последовательности запуска демона drweb, этот файл нужно выполнить с параметром start. Сейчас мы это исправим. Открываем файл для редактирования и ищем строку: echo "Usage: $0 {start|stop|restart|reload}" После нее добавляем вот такую строку: /usr/local/etc/rc.d/drweb.sh start Таким образом, мы своего добились. Скрипт drweb.sh, не получив параметров из командной строки, рекурсивно выполнит сам себя с параметром start. В качестве теста перезагружаем систему с помощью команды reboot для того, чтобы убедиться, что демоны postfix и drweb будут запущены автоматически. Теперь займемся настройкой скритпа pflogsumm. Давайте посмотрим, какие данные сможет предложить нам pflogsumm:
Англоязычную версию pflogsumm-1.0.4.pl можно взять на сайте автора. Но все же мне кажется, что гораздо приятнее читать отчеты на родном языке. Поэтому я предпочитаю использовать версию, переведенную мною лично на русский язык. Скачать модифицированную версию скрипта можно http://www.onix.opennet.ru/files/pflogsumm_rus_1.0.4.tar.gz. Создаем директорию для размещения скрипта и прочих файлов. # mkdir /usr/local/pflogsumm Теперь кладем туда pflogsumm-1.0.4.pl. Переименовываем его для краткости в pflogsumm.pl. Устанавливаем файлу владельца, группу и право на выполнение. # chmod 100 /usr/local/pflogsumm/pflogsumm.pl # chown root:wheel /usr/local/pflogsumm/ pflogsumm.pl Для выполнения pflogsumm желательно иметь Perl версии не ниже 5.004. Стабильная работа с более ранними версиями интерпретатора Perl не гарантируется. Узнать версию Perl, установленного в системе, можно с помощью комманды perl -v. Запустив модуль pflogsumm на выполнение, вы, скорее всего, получите ошибки подобные этим: # ./pflogsumm.pl
Это означает, что у вас отсутствует модуль Perl по имени Date-Calc, написанный Steffen Beyer. Он состоит из библиотеки языка С и модуля perl, который использует эту библиотеку. Нам этот модуль необходим для работы с датами Грегорианского календаря. Стандарт календаря описывается документами ISO/R 2015-1971, DIN 1355 и ISO 8601. На данный момент календарь такого типа используется во всех Европейских странах. В свою очередь, для работы модуля Date-Calc нам потребуется модуль Bit-Vector. Берем самую последнюю версию вышеописанных пакетов на сайте автора http://www.engelschall.com/~sb/download. В случае если это сделать не удастся, скачайте те же пакеты из центрального хранилища CPAN (Comprehensive Perl Archive Network). На момент написания статьи были актуальны версии Date-Calc-5.3 и Bit-Vector-6.3. Кладем оба пакета во временную директорию, например в /tmp. А затем начинаем распаковывать и устанавливать: # tar zxvf Bit-Vector-6.3.tar.gz # cd Bit-Vector-6.3 # perl Makefile.PL # make # make test # make install Если с Bit-Vector все прошло удачно, выполняем аналогичные действия для пакета Date-Calc. По окончанию установки снова запускаем pflogsumm.pl. Если на экране не появилось ни одной ошибки, значит, все требуемые модули находятся на месте и готовы к использованию. Технология работы pflogsumm довольно проста. Пользователь передает на стандартный ввод скрипта файлы протокола почтовой системы. А результаты получает из стандартного вывода. Мне кажется, что статистика должна собираться за прошедшую неделю, предыдущий и текущий день. Для выполнения этих задач мы напишем три вспомогательных скрипта. После их выполнения сформированные файлы должны записываться в директорию /usr/local/apache/htdocs/traffic/. С помощью веб-сервера apache, работающего на этой же машине, файлы из этой директории будут доступны начальству для просмотра с помощью любого веб-браузера. В дополнение к этому хотелось, чтобы недельная и ежедневная статистика приходила по почте администратору. Для систем FreeBSD характерно хранение протокола почтовой системы длиной в одну неделю. В некоторых диалектах Linux принято хранить протоколы длиной в один месяц. Как и во многих других UNIX-подобных системах, с помощью демона cron каждую ночь запускается задача ротации файлов протоколов. В результате работы этой задачи файл /var/log/maillog упаковывается с помощью программы gunzip и записывается вместо файла /var/log/maillog.0.gz. В других системах вместо gunzip используется bzip, но основной принцип это не меняет. Старое содержимое файла /var/log/maillog.0.gz записывается в файл /var/log/maillog.1.gz. Таким образом, все файлы по цепочке смещаются вниз на один день. И только содержимое файла /var/log/maillog.6.gz никуда не копируется, а просто перезаписывается файлом /var/log/maillog.5.gz. Обдумав все вышесказанное, приходим к выводу, что недельный и ежедневный скрипты подсчета статистики должны запускаться после того, как задача ротации логов успешно завершится. Во избежание всяких казусов уточните время запуска и завершения задачи ротации протоколов для вашей системы. Ниже приводится содержимое файла /usr/local/pflogsumm/weekly.sh, создающего недельную статистику. Этот скрипт запускается каждый понедельник в 1 час 00 минут. #!/bin/sh zcat /var/log/maillog.0.gz > /usr/local/pflogsumm/weekly.maillog zcat /var/log/maillog.1.gz >> /usr/local/pflogsumm/weekly.maillog zcat /var/log/maillog.2.gz >> /usr/local/pflogsumm/weekly.maillog zcat /var/log/maillog.3.gz >> /usr/local/pflogsumm/weekly.maillog zcat /var/log/maillog.4.gz >> /usr/local/pflogsumm/weekly.maillog zcat /var/log/maillog.5.gz >> /usr/local/pflogsumm/weekly.maillog zcat /var/log/maillog.6.gz >> /usr/local/pflogsumm/weekly.maillog # Собираем полный недельный протокол в файл weekly.maillog такой подход облегчает обработку файла. Но в то же время # стоит убедиться, что в системе хватит места для этого файла. echo "/usr/local/apache/htdocs/traffic/" > /usr/local/pflogsumm/weekly.name date -v-7d "+%d%b%Y-" >> /usr/local/pflogsumm/weekly.name date -v-1d "+%d%b%Y" >> /usr/local/pflogsumm/weekly.name # Записываем в файл weekly.name полный путь к результирующему файлу. Должны получаться имена файлов вроде 17Apr2003-24Apr2003 /usr/local/pflogsumm/pflogsumm.pl /usr/local/pflogsumm/weekly.maillog --smtpd_stats --mailq --problems_first --rej_add_from --verbose_msg_detail --iso_date_time > `tr -d " " < /usr/local/pflogsumm/weekly.name` # Запускаем расчеты и перенаправляем стандартный вывод в результирующий файл cat `tr -d " " < /usr/local/pflogsumm/weekly.name` | mail -s `date -v-7d "+%d%b%Y-"``date -v-1d "+%d%b%Y"` # Отправляем копию файла почтой администратору rm /usr/local/pflogsumm/weekly.maillog rm /usr/local/pflogsumm/weekly.name # Убираем за собой мусор Закончив с еженедельным скриптом, перейдем к ежедневному, собирающему данные за вчерашний день /usr/local/pflogsumm/daily.sh. Комментировать в нем нечего, потому что это всего лишь упрощенная версия еженедельного расчета. Этот скрипт запускается каждую ночь в 2 часа 00 минут. #!/bin/sh zcat /var/log/maillog.0.gz > /usr/local/pflogsumm/daily.maillog echo "/usr/local/apache/htdocs/traffic/" > /usr/local/pflogsumm/daily.name date -v-1d "+%d%b%Y" >> /usr/local/pflogsumm/daily.name /usr/local/pflogsumm/pflogsumm.pl -d yesterday /usr/local/pflogsumm/daily.maillog --mailq --problems_first --rej_add_from --verbose_msg_detail –iso_date_time > `tr -d " " < /usr/local/pflogsumm/daily.name` date -v-1d "+%d%b%Y" > /usr/local/pflogsumm/tmp.date cat `tr -d " " < /usr/local/pflogsumm/daily.name` | mail -s `date -v-1d "+%d%b%Y"` tigrisha@test.ru rm /usr/local/pflogsumm/daily.name rm /usr/local/pflogsumm/tmp.date rm /usr/local/pflogsumm/daily.maillog Последней и самой простой версией скрипта является задача, запускающаяся для сбора данных об активности за текущий день /usr/local/pflogsumm/hourly.sh. Этот скрипт запускается в 20 минут каждого часа. #!/bin/sh echo "/usr/local/apache/htdocs/traffic/" > /usr/local/pflogsumm/tmp.name date "+%d%b%Y" >> /usr/local/pflogsumm/tmp.name /usr/local/pflogsumm/pflogsumm.pl -d today /var/log/maillog --mailq --problems_first --rej_add_from --verbose_msg_detail –iso_date_time > `tr -d " " < /usr/local/pflogsumm/tmp.name` rm /usr/local/pflogsumm/tmp.name Для моей системы оптимально было установить время выполнения этих скриптов таким образом: # crontab -e -u root 0 1 * * 1 /usr/local/pflogsum/weekly.sh 0 2 * * * /usr/local/pflogsum/daily.sh 20 * * * * /usr/local/pflogsum/hourly.sh Исходные тексты всех трех скриптов можно скачать здесь: http://www.onix.opennet.ru/files/mail_stats.tar.gz. К сожалению, пользователи других систем, скорее всего, столкнутся с проблемами при использовании первых двух скриптов. Это может произойти из-за того, что внутри наших скриптов мы используем команду date c ключем -v. Не все операционные системы поддерживают такую опцию, и, возможно, вам придется исправлять эти скрипты. Выполнив все вышеописаное, вы должны стать счастливым обладателем собственного почтового сервера. |
АНДРЕЙ БЕШКОВ
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
