Записи с тегом «freebsd»

Прежде всего хочу отметить очень хороший сайт по настройке postifx. Подобрать себе нужное HOW-TO там можно без проблем. В моём случае пришлось пользоваться несколькими документами по настройке сабжа и немного погуглить. Цель была построить почтовый рилей + POP3/IMAP сервер для клиентов с повышеной безопасностью. А для почтового сервиса это практически означает криптование всего что только можно криптануть :). Не буду писать про настройку связки с базой и прочей приевшейся документации, а просто обращу Ваше внимание на несколько моментов. Также я не буду писать полное HOW-TO для ленивых :) Итак, что мы будем криптовать:

• пароли в базе;
• всю авторизацию клиентов (как SMTP так и POP3/IMAP);
• обмен данными клиент-сервер и сервер-сервер;

Первым делом настроим сам postfix на предмет работы с SSL. Прежде всего он должен был скомпилирован с поддержкой SSL. Для каждой платформы проверять надо по разному. Потом надо сгенерировать ключ, как это сделать тоже много статей и описаний. По быстрому так:

# mkdir /postfix/configs_dir/ssl

# cd /postfix/configs_dir/ssl

# openssl req -new -x509 -nodes -out smtpd.pem -keyout smtpd.pem -days 3650

Следующим шагом будет настройка postfix (добавляем в main.cf):

smtp_use_tls = yes smtpd_use_tls = yes smtp_tls_note_starttls_offer = yes smtpd_tls_key_file = /postfix/configs_dir/ssl/smtpd.pem smtpd_tls_cert_file = /postfix/configs_dir/ssl/smtpd.pem smtpd_tls_CAfile = /postfix/configs_dir/ssl/smtpd.pem smtpd_tls_loglevel = 1 smtpd_tls_received_header = yes smtpd_tls_session_cache_timeout = 3600s tls_random_source = dev:/dev/urandom После этого получаем криптование при отправки и приёме почты на рилее. Потом ещё добавляем авторизацию через SASL для клиентов, чтоб могли с любого места пользоваться своим рилеем. Подразумевается что SASL тоже стоит в системе и postfix умеет с ним работать. Так как в нашем случае в качестве POP3/IMAP сервера выбран Courier-IMAP, то и авторизовать SMTP нам надо через него. Следовательно используем Courier-authlib, с которой умеет работать SASL. В postfix это выглядит так:

broken_sasl_auth_clients = yes smtpd_sasl_security_options = noanonymous smtpd_sasl_auth_enable = yes В SASL, (lib/sasl2/smtpd.conf)

pwcheck_method: authdaemond log_level: 7 mech_list: PLAIN LOGIN authdaemond_path:/var/run/authdaemond/socket Получаем такую цепочку:

postfix <-> sasl <-> courier-authlib <-> sql-backend

Теперь о граблях... точнее об одной. В postfix есть такая опция smtpd_sasl_local_domain, она мешает ему авторизовать клиента. Глубоко не копал, просто погуглил и нашёл что такая бага есть, а всё остально заработало гладко.

Последнюю неделю пришлось немного повозиться с почтовым хостинговым сервером. Наступил как всегда на ряд граблей :). Но благодаря этому появилось несколько тем для заметок. Так что ближайшие дни они появятся. Хочу только заметить, что теперь наш почтовый сервер всё что возможно криптует и хорошо защищён от 100% спама. Если уточнить то это шифрованый pop3/imap и smtp, а также проверку имён хостов отправителей и другие приятные мелочи.

Решил поделиться опытом по этой теме. Значит у меня задача звучала примерно так: "не сложный клиент-серверный монитор загрузки сервера с веб-интерфейсом". Если конкретезировать то попросту рисовалка графиков и желательно сделанная на rrdtool. Начал как всегда с гугления и freshmeat.net. В итоге остановился на двух интересных софтинах. Первая cacti (кактус типа). Сделана на rrdtool + php + cactid (написанный на Си даемон-poller, который опрашивает хосты). Использование cactid - опционально. Для хранения конфигурации используется MySQL. Софтина позиционируется автором как комлексное средство монитроинга для сетей локального и глобального масшатаба с размахом до тысячи хостов. Мои запросы оказались поскромнее, поэтому пришлось отказаться от неё. Но в принципе очень стоящая вещь: гибкость на высоком уровне, мониторить может почти всё что угодно (не только стандартные заготовки по параметрам, которые кстати позволяют и так чуть ли не всё мониторить, есть framework для написания своих скриптов). Для сбора статистики по сети с хостов пришлось бы поднимать ещё snmpd - тоже минус. Вторая софтина - symon. На порядок проще. Рисует тоже через rrdtool и веб-интерфейс работает на php. Но своей простотой она меня и привлекла. В комлекте получается три компоненты: symon - локальный даемон для сбора статистики на хосте, symux - серверный даемон для сбора статистики с хостов и syweb - веб-интерфейс. Всё в принципе очень быстро поднялось. Вся конфигурация в текстовых файлах, взаимодействие symon и symux по tcp. Думаю что этот вариант подойдёт и для больших сетей хостов в 100. Главный минус этого варианта - мониторинг только unix-серверов, с устройствами (например switches, cisco routers) он не заработает, SNMP не умеет. Тут как раз выигрывает cacti. Но на данный момент нам как раз и нужно мониторинг только unix-серверов. В итоге мы получили мониторинг загрузки I/O на дисках, процессора, памяти, сетевых интерфейсов, системных буферов (mbuf), кол-ва и состояния процессов Apache, файервола (OpenBSD PF в нашем случае).

Последнее время рассуждаю на тему оптимального языка для системного программирования под unix. Т.е. то что традиционно делается мною на perl (day to day system tasks). Меня perl во многом устраивает, но сомнения по его производительности и "приятности работы" с ним немного терзают. Зато вот всё больше меня привлекает Python. Честно говоря начал его серьёзно воспринимать после того как увидил несколько работающих софтин на нём. Тот же yum, который использует redhat или взять Google, который тоже много где его в вебе использует. А Nokia вообще его портировала на свои телефоны. На данный момент мне интересна работа с XML и интеграция с системой. Попробую ближайшее время Python + XML в привязке к нашему хостингу. Посмотрим что из этого получится, напишу позже отчёт.

Первый интересующий меня вопрос при тестировании был "какое количество соединений сможет отработать корректно апач на статическом контенте". Начнём с того что отличительная фича работы apahce2 с запросами это возможность использования тредов. Напомню, что в 1-ой версии апач на каждое соединение делал fork процесса, во 2-ой ветке есть возможность собрать его со старой схемой обработки, но было бы глупо на продакшене не воспользоваться тредовой сборкой. Кому интересно можно почитать в официальной документации апача про многопоточность и мультипроцессные модули. В моём варианте апач был собран с многопоточным модулем worker. Вопрос тюнинга немного не в топик, обсудим его позже подробно. Ещё одно примечание - количество соединений, которое может отработать апач во многом ещё зависит от тюнинга ОС (в нашем случае это FreeBSD) об этом тоже отдельно. Утилита, которой я тестировал называется siege, она позиционриуется автором как стресс-тестер для веб-сервера, что как раз нам и надо. Скажу от себя что утилита вполне справляется со своим предназначением и была выбрана мной из-за простоты использования, гибкости и подробных отчётов. Теперь о процессе тестирования. Для начала я заготовил файлы разного размера на веб-сервере (размер почти произвольный), я брал вариации маленьких файлов до пол-мегабайта и один больше 8 мегабайт (кеш на винте был 8 мегабайт); потом сгенерировал текстовый файл с ссылками. Прочитав мануал по siege настроил конфиг (командой siege.config можно создать темплейт конфига - .siegerc в домашней директории, откуда он и будет читаться). Мои рекомендации по конфигу:

1. переключить connection в режим close (keep-alive был по умолчанию) - как ни печально, но у меня siege не захотел нормально отработать keep-alive, с этим я ещё поразбераюсь и может что-то отдельно напишу;
2. установить адекватный concurrent - это количество воображаемых пользователей "гуляющих" по ссылкам, которые генерирует siege;
3. установить путь к файлу содержащему ссылки (если вы работаете больше чем с одним url) - директива file;
4. установить время тестирования директивой time;
5. рекомендую использовать директиву internet для рандомного перебора url-ами из списка (симуляция реальных запросов);
6. timeout выбирайте на свой вкус, желательно чтоб он был согласован с таймаутом апача и был приближен к таймаутам браузеров.

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

• среднее время ответа сервера на запрос;
• среднее кол-во транзакций в секунду (отработанных запросов);
• пиковое кол-во одновременных запросов в секунду, после которого производительность апача начинает уменьшаться;
• процентное отношение корректно обработанных запросов к общему кол-ву запросов;
• кол-во необработанных запросов (не завершённых).

Публиковать свои результаты думаю не стоит, т.к. аппаратная и программная часть всё-равно у всех будет значительно отличаться. Может будут примеры к статьям о тюнинге самого апача и FreeBSD. Вообщем первая часть на этом заканчивается. To be continued... :-)