Пощенски сървър Nginx. Настройване на NGINX за проксииране на поща

Тази статия ще обясни как да конфигурирате NGINX Plus или NGINX Open Source като прокси за пощенски сървър или външна пощенска услуга.

Въведение

NGINX може да прокси IMAP, POP3 и SMTP протоколи към един от пощенските сървъри нагоре, които хостват имейл акаунти и по този начин може да се използва като единична крайна точка за имейл клиенти. Това може да донесе редица ползи, като например:

• лесно мащабиране на броя на пощенските сървъри
• избор на пощенски сървър въз основа на различни правила, например избор на най-близкия сървър въз основа на IP адреса на клиента
• разпределяне на натоварването между пощенските сървъри

Предпоставки

NGINX Plus (вече включва модулите за поща, необходими за прокси имейл трафик) или NGINX Open Source компилира модулите за поща, използвайки параметъра --with-mail за функционалност на имейл прокси и параметъра --with-mail_ssl_module за поддръжка на SSL/TLS:

$ ./configure --with-mail --with-mail_ssl_module --with-openssl=[ DIR] /openssl-1.1.1

IMAP, POP3 и/или SMTP пощенски сървъри или външна пощенска услуга

Конфигуриране на SMTP/IMAP/POP3 пощенски прокси сървъри

В конфигурационния файл на NGINX:

поща (#...)

поща (име_на_сървър mail.example.com; #...)

поща (сървър_име mail.example.com; auth_http localhost: 9000 /cgi-bin/nginxauth.cgi; #...)

Като алтернатива, укажете дали да информирате потребителя за грешки от сървъра за удостоверяване, като посочите директивата proxy_pass_error_message. Това може да е полезно, когато в пощенска кутия свърши паметта:

поща (сървър_име mail.example.com; auth_http localhost: 9000 /cgi-bin/nginxauth.cgi; proxy_pass_error_message on; #...)

Конфигурирайте всеки SMTP, IMAP или POP3 сървър със сървърните блокове. За всеки сървър посочете:

• на номер на пристанищекоито съответстват на посочения протокол с директивата за слушане
• на протоколс директивата на протокола (ако не е посочена, ще бъде автоматично открита от порта, посочен в директивата за слушане)
• разрешено методи за удостоверяванес директиви imap_auth, pop3_auth и smtp_auth:

сървър (слушане 25; протокол smtp; smtp_auth влизане обикновен cram-md5;) сървър (слушане 110; протокол pop3; pop3_auth обикновен apop cram-md5;) сървър (слушане 143; протокол imap;)

Настройване на удостоверяване за пощенски прокси

Всяка POP3/IMAP/SMTP заявка от клиента първо ще бъде удостоверена на външен HTTP сървър за удостоверяване или чрез скрипт за удостоверяване. Наличието на сървър за удостоверяване е задължително за прокси сървъра за електронна поща на NGINX. Сървърът може да бъде създаден от вас в съответствие с протокола за удостоверяване NGINX, който се основава на HTTP протокола.

Ако удостоверяването е успешно, сървърът за удостоверяване ще избере сървър нагоре по веригата и ще пренасочи заявката. В този случай отговорът от сървъра ще съдържа следните редове:

HTTP/1.0 200 OK Auth-Status: OK Auth-Server: # името на сървъра или IP адреса на сървъра нагоре по веригата, който ще се използва за обработка на поща Auth-Port: # порта на сървъра нагоре по веригата

Ако удостоверяването е неуспешно, сървърът за удостоверяване ще върне съобщение за грешка. В този случай отговорът от сървъра ще съдържа следните редове:

HTTP/1.0 200 OK Auth-Status: # съобщение за грешка, което трябва да бъде върнато на клиента, например „Невалидно потребителско име или парола“ Auth-Wait: # броя оставащи опити за удостоверяване до затваряне на връзката

Имайте предвид, че и в двата случая отговорът ще съдържа HTTP/1.0 200 OKкоето може да е объркващо.

За повече примери на заявки и отговори от сървъра за удостоверяване вижте ngx_mail_auth_http_module в справочната документация на NGINX.

Настройка на SSL/TLS за пощенски прокси

Използвайки POP3/SMTP/IMAP през SSL/TLS, вие гарантирате, че данните, предавани между клиент и пощенски сървър, са защитени.

За да активирате SSL/TLS за пощенския прокси:

Уверете се, че вашият NGINX е конфигуриран с поддръжка на SSL/TLS, като въведете командата nginx -V в командния ред и след това потърсете реда с --mail_ssl_module в изхода:

$ nginx -V конфигуриране на аргументи: ... с--mail_ssl_module

Уверете се, че сте получили сървърни сертификати и частен ключ и ги поставете на сървъра. Сертификатът може да бъде получен от доверен сертифициращ орган (CA) или генериран с помощта на SSL библиотека като OpenSSL.

ssl включен;

започва на ;

Добавяне на SSL сертификати: посочете пътя до сертификатите (които трябва да са във формат PEM) с директивата ssl_certificate и посочете пътя до частния ключ в директивата ssl_certificate_key:

поща ( #... ssl_certificate /etc/ssl/certs/server.crt ; ssl_certificate_key /etc/ssl/certs/server.key ; )

Можете да използвате само силни версии и шифри на SSL/TLS с директивите ssl_protocols и ssl_ciphers или можете да зададете свои собствени предпочитани протоколи и шифри:

поща ( #... ssl_protocols TLSv1 TLSv1.1 TLSv1.2 ; ssl_ciphers HIGH:!aNULL:!MD5 ;)

Оптимизиране на SSL/TLS за Mail Proxy

Тези съвети ще ви помогнат да направите вашето прокси за електронна поща NGINX по-бързо и по-сигурно:

Задайте броя на работните процеси, равен на броя на процесорите, като директивата worker_processes е зададена на същото ниво като контекста на пощата:

работни_процеси автоматично; поща (#...)

Активирайте споделения сесиен кеш и деактивирайте вградения сесиен кеш с автоматичния ; поща (сървър_име mail.example.com; auth_http localhost: 9000 /cgi-bin/nginxauth.cgi; proxy_pass_error_message on; ssl on; ssl_certificate /etc/ssl/certs/server.crt; ssl_certificate_key /etc/ssl/certs/server. ключ; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers HIGH:!aNULL:!MD5; ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m; сървър (слушайте 25; протокол smtp; smtp_auth login plain cram-md5;) сървър (слушай 1 10; протокол pop3; pop3_auth обикновен apop cram-md5;) сървър (слушайте 143; protocol imap;))

В този пример има три имейл прокси сървъра: SMTP, POP3 и IMAP. Всеки от сървърите е конфигуриран с поддръжка на SSL и STARTTLS. Параметрите на SSL сесията ще бъдат кеширани.

Прокси сървърът използва HTTP сървър за удостоверяване – неговата конфигурация е извън обхвата на тази статия. Всички съобщения за грешка от сървъра ще бъдат върнати на клиентите.

iRedMail е готов монтажпощенски сървър с отворен програмен код. Сглобката е базирана на Postfix SMTP сървър (Mail Transfer Agent, съкратено като MTA). Сглобяването включва също: Dovecot, SpamAssassin, Greylist, ClamAV, SOGo Roundcube, NetData и NGINX.

Dovecot - IMAP/POP3 сървър.

Spamassassin е инструмент за филтриране на спам.

Greylist е базиран на сив списък инструмент против спам.

ClamAV е антивирусна програма.

Roundcube и SOGo са уеб клиенти за работа с имейл.

NetData е програма за наблюдение на сървъри в реално време.

Nginx е уеб сървър.

Поддържа операционни системи: CentOS 7, Debian 9, Ubuntu 16.04/18.04, FreeBSD 11/12 и OpenBSD 6.4.

iRedMail има платени и безплатни версии, които се различават една от друга по функционалността на собствения си уеб интерфейс на пощенския модул iRedAdmin. IN безплатна версияМожете да създавате само домейни, потребителски и администраторски пощенски кутии. Ако трябва да създадете псевдоним, вече няма да можете да направите това в безплатната версия чрез iRedAdmin. За щастие има безплатно решение, наречено PostfixAdmin, което ви позволява да направите това. PostfixAdmin се интегрира лесно в iRedMail и работи чудесно с него.

Инсталация

За да инсталираме, ще ни трябва една от изброените по-горе операционни системи. Ще използвам Ubuntu Server 18.04. Трябва също да сте закупили Име на домейни конфигурирана DNS зона. Ако използвате DNS сървъривашия регистратор на домейни, тогава трябва да направите два записа в секцията за управление на домейн зона: A и MX. Можете също да използвате свой собствен DNS, като настроите делегиране в лична сметкавашия регистратор на име на домейн.

Настройка на домейн зона при използване на DNS регистратор

Забележка! Време на влизане DNS настройкис продължителност от няколко часа до една седмица. Докато настройките не влязат в сила, пощенският сървър няма да работи правилно.

За да инсталирате, изтеглете от уебсайта на iRedMail сегашна версия. В момента е 0.9.9.

# wget https://bitbucket.org/zhb/iredmail/downloads/iRedMail-0.9.9.tar.bz2

След това разопаковайте изтегления архив.

# tar xjf iRedMail-0.9.9.tar.bz2

Разопаковане на архива

И отидете в създадената папка.

# cd iRedMail-0.9.9

Папка за инсталиране на iRedMail

Проверка на съдържанието на папката

Съдържание на папката

И стартирайте инсталационния скрипт на iRedMail.

# bash iRedMail.sh

Инсталирането на пощенската система ще започне. По време на инсталационния процес ще трябва да отговорите на редица въпроси. Съгласни сме да започнем инсталацията.

Стартирайте инсталацията

Избор на инсталационна директория

Сега трябва да изберете уеб сървър. Няма голям избор, затова избираме NGINX.

Избор на уеб сървър

Сега трябва да изберете сървър на база данни, който ще бъде инсталиран и конфигуриран да работи с пощенската система. Изберете MariaDB.

Избор на сървър на база данни

Задайте root парола за базата данни.

Създаване на root парола за база данни

Сега посочваме нашия имейл домейн.

Създаване на пощенски домейн

След това създаваме парола за пощенската кутия на администратора [email protected].

Създаване на администраторска парола за поща

Избор на уеб компоненти

Потвърдете посочените настройки.

Потвърждаване на настройките

Инсталацията започна.

Инсталация

След като инсталацията приключи, потвърдете създаването на правилото iptables за SSH и рестартирайте защитната стена. iRedMail работи с iptables. В Ubuntu най-често използваната помощна програма за управление на защитна стена е UFW. Ако по една или друга причина имате такава нужда, тогава инсталирайте UFW (apt install ufw) и добавете правила, така че UFW (пример: ufw enable "Nginx Full" или ufw enable Postfix) да не блокира работата на пощенския сървър. Можете да видите списъка с налични правила, като изпълните командата: ufw app list. След това активирайте UFW: ufw enable.

Създаване на правило за iptables

Рестартиране на защитната стена

Това завършва инсталирането на iRedMail. Системата ни предостави адреси на уеб интерфейс и идентификационни данни за вход. За да разрешите всички компоненти на пощенската система, трябва да рестартирате сървъра.

Завършване на инсталацията

Да рестартираме.

# рестартиране

Настройки

Първо трябва да се уверите, че всичко работи. Нека се опитаме да влезем в контролния панел на iReadAdmin на https://domain/iredadmin. Вход [email protected], парола, създадена по време на инсталацията. Има интерфейс на руски език.

Както можете да видите, всичко работи. Когато влизате в iRedAdmin, най-вероятно сте получили грешка в сигурността, свързана със сертификата. Това се случва, защото iRedMail има вграден самоподписан сертификат, от който браузърът се оплаква. За да разрешите този проблем, трябва да инсталирате валиден SSL сертификат. Ако имате закупен, можете да го инсталирате. В примера ще инсталирам безплатен SSL от Let's Encrypt.

Инсталиране на Let's Encrypt SSL сертификат

Ще инсталираме сертификата с помощта на помощната програма certbot. Първо, нека добавим хранилище.

# add-apt-repository ppa:certbot/certbot

След това ще инсталираме самия certboot с необходимите компоненти.

# apt инсталирайте python-certbot-nginx

Получаваме сертификат.

# certbot --nginx -d domain.ru

След като изпълните командата, системата ще ви помоли да въведете своя имейл адрес, въведете. След това най-вероятно ще получите грешка, че не е възможно да намерите сървърния блок, за който е генериран сертификатът. В този случай това е нормално, тъй като нямаме сървърен блок. Основното за нас е да получим сертификат.

Получаване на сертификат

Както виждаме, сертификатът беше получен успешно и системата ни показа пътищата до самия сертификат и до ключа. Те са точно това, от което се нуждаем. Като цяло получихме 4 файла, които ще се съхраняват в папката "/etc/letsencrypt/live/domain". Сега трябва да информираме уеб сървъра за нашия сертификат, тоест да заменим вградения сертификат с този, който току-що получихме. За да направим това, трябва да редактираме само един файл.

# nano /etc/nginx/templates/ssl.tmpl

И променяме последните два реда в него.

Подмяна на SSL сертификата

Променяме пътищата във файла на пътищата, които системата ни каза при получаване на сертификата.

Подмяна на SSL сертификат

И рестартирайте NGINX.

# услуга рестартиране на nginx

Сега нека се опитаме да влезем в iRedAdmin отново.

Проверка на SSL сертификата

Вече няма грешка в сертификата. Сертификатът е валиден. Можете да щракнете върху ключалката и да видите нейните свойства. Когато сертификатът изтече, certboot трябва да го поднови автоматично.

Сега ще докладваме за сертификата Dovecot и Postfix. За да направим това, ще редактираме два конфигурационни файла. Ние правим:

# nano /etc/dovecot/dovecot.conf

Намиране на блока:

#SSL: Глобални настройки.

И сменяме регистрирания там сертификат с наш.

Сертификат за замяна на Dovecot

Обърнете внимание и на реда "ssl_protocols". Стойността му трябва да бъде "!SSLv3", в противен случай ще получите грешката "Предупреждение: SSLv2 не се поддържа от OpenSSL. Моля, обмислете премахването му от ssl_protocols", когато рестартирате Dovecot.

# nano /etc/postfix/main.cf

Намиране на блока:

# SSL ключ, сертификат, CA

И променяме пътищата в него по пътя към файловете на нашия сертификат.

Подмяна на сертификат за Postfix

Това завършва инсталирането на сертификата. Необходимо е да рестартирате Dovecot и Postfix, но е по-добре да рестартирате сървъра.

# рестартиране на услугата dovecot

# рестартиране

Инсталиране на PHPMyAdmin

Тази стъпка не е задължителна, но препоръчвам да я направите и да инсталирате PHPMyAdmin за по-лесна работа с бази данни.

# apt инсталирайте phpmyadmin

Инсталаторът ще попита с кой уеб сървър да конфигурира PHPMyAdmin да работи, тъй като NGINX не е в този списък, просто натиснете TAB и продължете напред.

Инсталиране на PHPMyAdmin

След като инсталацията приключи, за да работи phpmyadmin, трябва да направите символна връзка към директорията, с която NGINX работи по подразбиране.

# ln -s /usr/share/phpmyadmin /var/www/html

И ние се опитваме да отидем на https://domain/phpmyadmin/

PHPMyAdmin работи. Връзката е защитена със сертификат, няма грешки. Продължавай. Нека създадем MySQL администратор на база данни (MariaDB).

# mysql

И стигаме до конзолата за управление на MariaDB. След това изпълняваме командите една по една:

MariaDB > СЪЗДАВАНЕ НА ПОТРЕБИТЕЛ "admin"@"localhost" ИДЕНТИФИЦИРАН С "password";
MariaDB > ПРЕДОСТАВЯНЕ НА ВСИЧКИ ПРИВИЛЕГИИ НА *.* НА "admin"@"localhost" С ОПЦИЯ ЗА ПРЕДОСТАВЯНЕ;
MariaDB > FLUSH ПРИВИЛЕГИИ;

Създаване на MySQL потребител

Всичко е наред, влизането е завършено. PHPMyAdmin е готов за работа.

Инсталиране на PostfixAdmin

По принцип PostfixAdmin, подобно на PHPMyAdmin, не е необходимо да се инсталира. Пощенският сървър ще работи добре без тези компоненти. Но тогава няма да можете да създавате псевдоними за поща. Ако нямате нужда от това, тогава можете спокойно да пропуснете тези секции. Ако все още имате нужда от псевдоними, тогава имате две възможности: закупуване на платената версия на iReaAdmin или инсталиране на PostfixAdmin. Разбира се, можете да направите това без допълнителен софтуер, като регистрирате псевдоними в базата данни ръчно, но това не винаги е удобно и не е подходящо за всички. Препоръчвам да използвате PostfixAdmin; сега ще разгледаме неговата инсталация и интеграция с iRedMail. Да започнем инсталацията:

# apt инсталирайте postfixadmin

Ние се съгласяваме и създаваме парола за системната база данни на програмата.

Инсталиране на PostfixAdmin

Инсталиране на PostfixAdmin

Създаваме символна връзка по същия начин, както при инсталирането на PHPMyAdmin.

# ln -s /usr/share/postfixadmin /var/www/html

Ние правим потребителя, от чието име е стартиран уеб сървърът, собственик на директорията. В нашия случай NGINX се стартира като потребител на www-данни.

# chown -R www-данни /usr/share/postfixadmin

Сега трябва да редактираме конфигурационния файл на PostfixAdmin и да добавим информация за базата данни, която iRedAdmin използва. По подразбиране тази база данни се нарича vmail. Ако отидете на PHPMyAdmin, можете да го видите там. И така, за да може PostfixAdmin да прави промени в базата данни, ние го регистрираме в конфигурацията на PostfixAdmin.

# nano /etc/postfixadmin/config.inc.php

Намираме редовете:

$CONF["database_type"] = $dbtype;
$CONF["database_host"] = $dbserver;
$CONF["database_user"] = $dbuser;
$CONF["database_password"] = $dbpass;
$CONF["име_на_база_данни"] = $dbname;

И нека си го припомним:

$CONF["database_type"] = "mysqli"; # Тип база данни
$CONF["database_host"] = "localhost"; # Хост на сървър на база данни
$CONF["database_user"] = "администратор"; # Влезте с права за писане в базата данни на vmail. Можете да използвате предварително създадения администратор
$CONF["database_password"] = "парола"; # Парола за посочения по-горе потребител
$CONF["database_name"] = "vmail"; # Име на база данни iRedMail

Въвеждане на информация за базата данни

Ако планирате да използвате уеб мейл клиента SOGo, тогава трябва да направите още една допълнителна стъпка, а именно да промените криптирането на PostfixAdmin в елемента $CONF["encrypt"] от "md5crypt" на "dovecot:SHA512-CRYPT". Ако не направите това, когато се опитате да влезете в SOGo като потребител, създаден в PostfixAdmin, ще получите грешка: неправилно влизане или парола.

Промяна на типа криптиране

Сега, за да завършите успешно инсталацията и да не получавате грешки, трябва да изпълните заявка към базата данни. Удобно е да направите това чрез PHPMyAdmin. Изберете vmail базата данни и отидете на раздела SQL. В прозореца въвеждаме:

DROP INDEX домейн на пощенска кутия;
DROP INDEX домейн на псевдоним;
ALTER TABLE псевдоним ADD COLUMN `goto` текст NOT NULL;

Заявка за база данни

И щракнете върху „Напред“. Сега всички сме готови, можем да отидем до уеб интерфейса на PostfixAdmin и да завършим инсталацията. За да направите това, трябва да въведете в браузъра си: https://domain/postfixadmin/setup.php.

Трябва да се появи следното:

Инсталиране на PostfixAdmin

Ако всичко е направено според инструкциите, тогава не трябва да има грешки. Ако има такива, те трябва да бъдат елиминирани, в противен случай системата няма да ви позволи да продължите. Задайте паролата за инсталиране и щракнете върху „Генериране на хеш парола“. Системата ще генерира хеш парола, която трябва да бъде вмъкната в параметъра $CONF["setup_password"].

Завършване на инсталирането на PostfixAdmin

Промяна на настройките на конфигурационния файл

Сега въведете новосъздадената парола и създайте администратор на PostfixAdmin. По-добре е да не създавате администратор с името на postmaster, тъй като може да има проблеми с влизането в административния панел на iRedAdmin.

Създаване на PostfixAdmin администратор

Това е всичко, администраторът е създаден. Можете да влезете.

Моля, обърнете внимание, че от гледна точка на сигурността е по-добре да преименувате или изтриете файла setup.php в директорията postfixadmin.

Отидете на: https://domain/postfixadmin/ и въведете новосъздадените идентификационни данни. В PostfixAdmin, както и в iRedAdmin, руският език е наличен. Можете да го изберете по време на оторизация.

Опитваме се да създадем потребителска пощенска кутия.

Активиране/деактивиране на iRedMail модули

iRedAPD отговаря за управлението на модулите на iRedMail. Има конфигурационен файл, в който са регистрирани работещи модули. Ако не се нуждаете от определен модул, можете да го премахнете от конфигурационния файл и той ще спре да работи. Ние правим:

# nano /opt/iredapd/settings.py

Намерете реда „plugins“ и премахнете от него компонентите, които не ви трябват. Ще премахна компонента "сив списък". Разбира се, той предпазва от спам доста ефективно, но необходимите писма често не пристигат.

Сивият списък е автоматична технология за защита от спам, базирана на анализ на поведението на сървъра на подателя на пощата. Когато е активиран "сив списък", сървърът отказва да приеме писмо от неизвестен адрес за първи път, съобщавайки за временна грешка. В този случай изпращащият сървър трябва да повтори изпращането по-късно. Спамерските програми обикновено не правят това. Ако писмото бъде изпратено отново, то се добавя към списъка за 30 дни и обменът на поща се извършва първия път. Решете сами дали да използвате този модул или не.

Активиране/деактивиране на пощенски модули

След като направите промени, трябва да рестартирате iRedAPD.

# услуга iredapd рестартиране

Тестване на мейл сървъра

Това завършва конфигурацията на пощенския сървър iRedMail. Можете да продължите към последния етап - тестване. Нека създадем две пощенски кутии. За да проверите едното чрез iRedAdmin, второто през PostfixAdmin и да изпратите писмо от една пощенска кутия в друга и обратно. В iRedAdmin ще създадем пощенска кутия [email protected]. В PostfixAdmin - [email protected]

Създаване на потребител в iRedAdmin

Създаване на потребител в PostfixAdmin

Проверяваме дали потребителите са създадени.

Ако обърнете внимание на колоната „До“ в списъка с пощенски кутии на PostfixAdmin, ще забележите разликата между пощенските кутии, създадени в iRedAdmin и PostfixAdmin. Пощенските кутии, създадени в iRedAdmin, са маркирани като „Само за препращане“, а тези, създадени в PostfixAdmin, са маркирани като „Пощенска кутия“. Първоначално дълго време не можех да разбера защо се случва това и каква е разликата между тях и накрая забелязах едно нещо. Пощенските кутии в iRedAdmin се създават без псевдоними, а пощенските кутии в PostfixAdmin се създават с псевдоним за себе си.

И ако тези псевдоними бъдат изтрити, тогава пощенските кутии ще се показват като създадените в iRedAdmin „Само за препращане“.

Премахване на псевдоними

Псевдонимите са премахнати. Проверява се PostfixAdmin.

Както можете да видите, всички кутии са станали „Само напред“. По същия начин, ако създадете псевдоним за себе си в пощенска кутия, създадена в iRedAdmin, тя ще стане „Пощенска кутия“. По принцип това не влияе по никакъв начин на работата на пощата. Единственото нещо е, че няма да можете да създадете псевдоним на пощенска кутия, създадена в PostfixAdmin. Вместо да създавате псевдоним, ще трябва да редактирате съществуващ. Говорейки за псевдоними, в нова версия iRedMail трябва да направи промяна в една от картите на Postfix, която обработва псевдоними. И ако не направите това, създадените псевдоними няма да работят. За да направите това, трябва да коригирате следното във файла /etc/postfix/mysql/virtual_alias_maps.cf:

Ние правим:

# nano /etc/postfix/mysql/virtual_alias_maps.cf

И ние го поправяме.

Настройка на псевдоними

Рестартирайте Postfix:

# услуга postfix рестартиране

След това всичко трябва да работи.

И така, нека започнем да проверяваме пощата. Ще влезем в пощенската кутия на user1 чрез Roundcube и в пощенската кутия на user2 чрез SOGo и ще изпратим писмо от пощенската кутия на user1 до user2 и обратно.

Изпращане на имейл с Roundcube

Получаване на писмо в SOGo

Изпращане на имейл до SOGo

Получаване на писмо в Roundcube

Всичко работи без проблеми. Доставката на писмото отнема от две до пет секунди. По същия начин писмата се доставят перфектно до сървърите Yandex и mail.ru (тествани).

Сега нека проверим псевдонимите. Нека създадем пощенска кутия user3 и да създадем псевдоним от пощенската кутия user1 към пощенската кутия user2. И ние ще изпратим писмо от пощенската кутия user3 до пощенската кутия user1. В този случай писмото трябва да пристигне в пощенската кутия на user2.

Създаване на псевдоним

Изпращане на писмо от пощенска кутия на потребител3 до пощенска кутия на потребител1

Получаване на писмо в пощенската кутия на user2

Работата на псевдонимите също е добра.

Нека тестваме работата на пощенския сървър чрез локален пощенски клиент. Като пример, помислете за Mozilla Thunderbird. Нека създадем още двама потребители: client1 и client2. Ще свържем едната пощенска кутия чрез IMAP, другата чрез POP3 и ще изпратим писмо от едната пощенска кутия до другата.

IMAP връзка

Връзка чрез POP3

Изпращаме писмо от Клиент 1 до Клиент 2.

Изпращане от Клиент 1

Получаване на клиент 2

И в обратен ред.

Изпращане от Клиент 2

Получаване на клиент 1

Всичко работи.

Ако отидете на адрес: https://domain/netdata, можете да видите графики на състоянието на системата.

Заключение

Това завършва инсталирането, конфигурирането и тестването на пощенската система iRedMail. В резултат на това получихме напълно безплатен, пълноценен мейл сървър с валиден SSL сертификат, два различни уеб мейл клиента, два контролни панела, както и антиспам и антивирус, вградени в пощата. Ако желаете, вместо клиенти за уеб поща, можете да използвате локални клиенти за поща, като напр Microsoft Outlookили Mozilla Thunderbird. Ако не планирате да използвате клиенти за уеб поща, можете да не ги инсталирате изобщо, за да не претоварвате сървъра или да инсталирате нещо, което ви харесва най-много. Аз лично харесвам повече SOGo, защото интерфейсът му е оптимизиран за мобилни устройства, което го прави много удобен за разглеждане електронна пощаот смартфон. Същото важи и за NetData и iRedAdmin, ако не планирате да го използвате, по-добре не го инсталирайте. Тази пощенска система не е много взискателна към ресурсите. Всичко това работи на VPS сървър с 1024 MB оперативна памети един виртуален процесор. Ако имате въпроси относно тази пощенска система, пишете в коментарите.

P.S. При тестване на този продукт на различни операционни системи с 1 GB RAM (Ubuntu, Debian, CentOS) се оказа, че 1 GB не е достатъчно, за да работи ClamAV. В почти всички случаи, когато се използва 1 GB памет, антивирусът цитира грешка, свързана с базата данни. В същото време в операционните системи Debian и Ubuntu антивирусът просто не сканира пощата, преминаваща през сървъра, иначе всичко работи добре. В CentOS ситуацията беше малко по-различна. Услугата clamd напълно срина системата, като по този начин направи нормалната работа на сървъра невъзможна. При опит за влизане в уеб интерфейсите NGINX периодично извеждаше грешки 502 и 504. Пощата също беше изпратена всеки друг път. Освен това, ако добавим до 2 GB RAM, тогава във всички случаи не е имало проблеми с работата на антивируса и сървъра като цяло. ClamAV сканира поща, преминаваща през пощенския сървър, за което пише в регистрационните файлове. При опит за изпращане на вирус като прикачен файл доставката беше блокирана. Консумацията на памет беше приблизително 1,2 - 1,7 GB.

Nginx е малък, много бърз, доста функционален уеб сървър и прокси сървър за електронна поща, разработен от Игор Сисоев (rambler.ru). Поради много ниската консумация на системни ресурси и скорост на работа, както и гъвкавостта на конфигурацията, web Nginx сървърчесто се използва като интерфейс към по-тежки сървъри, като напр Apache, в проекти с голямо натоварване. Класическата опция е комбинацията Nginx - Apache - FastCGI. Работейки по такава схема, Nginx сървър, приема всички заявки, идващи през HTTP, и в зависимост от конфигурацията и самата заявка, решава дали да обработи самата заявка и да даде готов отговор на клиента или да изпрати заявката за обработка към някой от бекендовете ( Apacheили FastCGI).

Както знаете, Apache сървърът обработва всяка заявка в отделен процес (нишка), което, трябва да се каже, консумира доста малко системни ресурси, ако има 10-20 такива процеса, това е глупост, а ако има 100-500 или повече, системата не става забавна.

Нека се опитаме да си представим подобна ситуация. Да предположим на Apacheидва 300 HTTP заявкиот клиенти, 150 клиента са на бързи наети линии, а останалите 150 са на относително бавни интернет канали, дори и да не са на модеми. Какво се случва в тази ситуация? И се случва следното: уеб сървърът на Apache, за да обработи тези 300 връзки, създава процес (нишка) за всяка, той ще генерира бързо съдържание и 150 бързи клиента веднага ще вземат резултата от техните заявки, процесите, които ги обслужват ще бъдат убити и ресурсите ще бъдат освободени, а 150 са бавни и ще получават бавно резултатите от своите заявки, поради тесния интернет канал, в резултат на което 150 процеса ще висят в системата Apache, чакайки клиентите да вземат съдържанието, генерирано от уеб сървъра, поглъщайки много системни ресурси. Естествено, ситуацията е хипотетична, но мисля, че същността е ясна. Пакетът помага да се коригира ситуацията, описана по-горе. След прочитане на цялата заявка от клиента, той я предава за обработка Apache, който от своя страна генерира съдържание и връща готовия отговор на Nginx възможно най-бързо, след което може да убие процеса с чиста съвест и да освободи системните ресурси, които заема. Nginx уеб сървър, получаващ резултата от заявката от Apache, го записва в буфер или дори във файл на диска и може да го предоставя на бавни клиенти за толкова дълго, колкото желае, докато работните му процеси консумират толкова малко ресурси, че .. „дори е смешно да се говори за това“ ©. :) Тази схема значително спестява системни ресурси, повтарям, но работните процеси на Nginx консумират малко количество ресурси, това е особено вярно за големи проекти.

И това е само малка част от това, което сървърът Nginx може да направи; не забравяйте за възможностите за кеширане на данни и работа с memcached. Ще дам списък на основните функционалност Nginx уеб сървър.

Nginx сървърна функционалност като HTTP сървър

• Лечение статично съдържание, индексни файлове, списъци с директории, отворен кеш на файловия дескриптор;
• Ускорено прокси с кеширане, разпределение на натоварването и толерантност към грешки;
• Ускорена поддръжка FastCGIсървъри с кеширане, разпределение на натоварването и отказоустойчивост;
• Модулна структура, поддръжка на различни филтри (SSI, XSLT, GZIP, възобновяване, chunked отговори);
• Поддръжка на SSL и TLS SNI разширения;
• IP базиранили Базиран на имевиртуални сървъри;
• Работа с KeepAlive и конвейерни връзки;
• Възможност за конфигуриране на всякакви изчаквания, както и броя и размера на буферите, на ниво Apache сървър;
• Извършване на различни действия в зависимост от адреса на клиента;
• Промяна на URI чрез регулярни изрази;
• Специални страници за грешка за 4xx и 5xx;
• Ограничаване на достъпа въз основа на клиентски адрес или парола;
• Настройка на лог файлови формати, ротация на логове;
• Ограничаване на скоростта на отговор на клиента;
• Ограничаване на броя на едновременните връзки и заявки;
• Поддържа методи PUT, DELETE, MKCOL, COPY и MOVE;
• Промяна на настройки и обновяване на сървъра без спиране на работа;
• Вградена Perl;

Функционалност на Nginx сървър като прокси сървър за електронна поща

• Пренасочване към IMAP/POP3 бекенд с помощта на външен HTTP сървър за удостоверяване;
• Проверка на потребителски SMTP на външен HTTP сървърудостоверяване и пренасочване към вътрешен SMTP сървър;
• Поддържа следните методи за удостоверяване:
  • POP3 - ПОТРЕБИТЕЛ/PASS, APOP, AUTH LOGIN/PLAIN/CRAM-MD5;
  • IMAP - ВХОД, АВТОРИЗАЦИЯ ВХОД/ОБИКНОВЕН/CRAM-MD5;
  • SMTP - AUTH LOGI/ PLAIN/CRAM-MD5;
• SSL поддръжка;
• STARTTLS и STLS поддръжка;

Операционни системи и платформи, поддържани от уеб сървъра Nginx

• FreeBSD, от 3 до 8 - платформи, i386 и amd64;
• Linux, от 2.2 до 2.6 - i386 платформа; Linux 2.6 - amd64;
• Solaris 9 - i386 и sun4u платформи; Solaris 10 - i386, amd64 и sun4v платформи;
• MacOS X платформи ppc, i386;
• Уиндоус експи, Windows сървър 2003 г.; (в момента в бета тестване)

Nginx сървърна архитектура и мащабируемост

• Основният (главен) процес, няколко (конфигурирани в конфигурационния файл) работни процеси, работещи под непривилегирован потребител;
• Поддръжка за следните методи за обработка на връзката:
  • select е стандартен метод. Съответният модул Nginx се изгражда автоматично, ако на дадена платформа не бъде намерен по-ефективен метод. Можете да принудите изграждането на даден модул да бъде активирано или деактивирано, като използвате конфигурационните опции --with-select_module или --without-select_module.
  • анкетата е стандартният метод. Съответният модул Nginx се изгражда автоматично, ако на дадена платформа не бъде намерен по-ефективен метод. Можете да принудите изграждането на даден модул да бъде активирано или деактивирано, като използвате конфигурационните опции --with-poll_module или --without-poll_module.
  • kqueue - ефективен метод, използван на операционни системи FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0 и MacOS X. Когато се използва на двупроцесорни машини, работещи с MacOS X, може да предизвика паника в ядрото.
  • epoll е ефективен метод, използван в Linux 2.6+. Някои дистрибуции, като SuSE 8.2, имат пачове за поддръжка на epoll в ядрото 2.4.
  • rtsig - сигнали в реално време, ефективен метод, използван в Linux 2.2.19+. По подразбиране не може да има повече от 1024 сигнала в опашката за цялата система. Това не е достатъчно за сървъри с голямо натоварване; размерът на опашката трябва да се увеличи с помощта на параметъра на ядрото /proc/sys/kernel/rtsig-max. От Linux 2.6.6-mm2 обаче тази опция вече не е налична, вместо това всеки процес има отделна опашка от сигнали, чийто размер се определя с помощта на RLIMIT_SIGPENDING.
  • Когато опашката е пълна, nginx сървърнулира го и обработва връзките с помощта на метода на анкета, докато ситуацията се върне към нормалното.
  • /dev/poll е ефективен метод, поддържан от операционни системи Solaris 7 11/99+, HP/UX 11.22+ (порт на събитие), IRIX 6.5.15+ и Tru64 UNIX 5.1A+.
  • eventport - портове за събития, ефективен метод, използван в Solaris 10. Преди да използвате, трябва да инсталирате корекция, за да избегнете паника в ядрото.
• Използване на възможности на метода kqueue като EV_CLEAR, EV_DISABLE (за временно деактивиране на събитие), NOTE_LOWAT, EV_EOF, брой налични данни, кодове за грешки;
• Работи с sendfile (FreeBSD 3.1+, Linux 2.2.+, Mac OS X 10.5+), sendfile64 (Linux 2.4.21+) и sendfilev (Solaris 8 7/01+);
• Поддръжка на филтри за приемане (FreeBSD 4.1+) и TCP_DEFER_ACCEPT (Linux 2.4+);
• 10 000 неактивни HTTP поддържащи връзки консумират приблизително 2,5M памет;
• Минимален брой операции за копиране на данни;

NGINX може да се използва не само като уеб сървър или http-прокси, но и за прокси поща чрез SMTP, IMAP, POP3 протоколи. Това ще ви позволи да конфигурирате:

• Единична входна точка за мащабируема имейл система.
• Балансиране на натоварването между всички пощенски сървъри.

В тази статия инсталацията се извършва в операционната зала. Linux система. Като пощенска услуга, към която се изпращат заявки, можете да използвате postfix, exim, dovecot, exchange, iredmail и други.

Принцип на действие

NGINX приема заявки и се удостоверява към уеб сървъра. В зависимост от резултата от проверката на влизане и парола, проксито ще върне отговор с няколко заглавки.

В случай на успех:

По този начин ние определяме сървъра и порта на пощенския сървър въз основа на удостоверяване. Това предоставя много възможности с подходящо познаване на езиците за програмиране.

В случай на повреда:

В зависимост от резултата от удостоверяването и заглавката, клиентът се пренасочва към пощенския сървър, от който се нуждаем.

Подготовка на сървъра

Нека направим някои промени в настройките за сигурност на сървъра.

SELinux

Деактивирайте SELinux, ако използваме CentOS или ако използваме тази системасигурност на Ubuntu:

vi /etc/selinux/config

SELINUX=забранено

Защитна стена

Ако използваме firewalld (по подразбиране в CentOS):

firewall-cmd --permanent --add-port=25/tcp --add-port=110/tcp --add-port=143/tcp

firewall-cmd --reload

Ако използваме iptables (по подразбиране в Ubuntu):

iptables -A ВХОД -p tcp --dport 25 -j ПРИЕМАНЕ

iptables -A ВХОД -p tcp --dport 110 -j ПРИЕМАНЕ

iptables -A INPUT -p tcp --dport 143 -j ПРИЕМАНЕ

apt-get инсталирайте iptables-persistent

iptables-save > /etc/iptables/rules.v4

* в този пример разрешихме SMTP (25), POP3 (110), IMAP (143).

Инсталиране на NGINX

Зависи от операционна системаИнсталирането на NGINX е малко по-различно.

или Linux Centos:

yum инсталирайте nginx

или Linux Ubuntu:

apt инсталирайте nginx

Разрешаваме автоматично стартиране на услугата и я стартираме:

systemctl активира nginx

systemctl стартира nginx

Ако NGINX вече е инсталиран в системата, проверете с кои модули работи:

Ще получим списък с опции, с които е изграден уеб сървърът - сред тях трябва да видим --with-mail. Ако необходимият модул не е там, трябва да актуализирате nginx

Настройване на NGINX

Отворете конфигурационния файл на nginx и добавете опцията за поща:

vi /etc/nginx/nginx.conf

поща (

auth_http localhost:80/auth.php;

сървър (
слушам 25;
smtp протокол;
smtp_auth влизане обикновен cram-md5;
}

сървър (
слушам 110;
протокол pop3;

}

сървър (
слушай 143;
имап на протокола;
}
}

* Където:

• server_name е името на сървъра за електронна поща, който ще бъде показан в SMTP поздрава.
• auth_http - уеб сървър и URL за заявка за удостоверяване.
• proxy_pass_error_message - разрешава или забранява показването на съобщение при неуспешно удостоверяване.
• listen - порт, на който се слушат заявките.
• protocol - протоколът на приложението, за който съответният порт слуша.
• smtp_auth - налични методи за удостоверяване за SMTP.
• pop3_auth - налични методи за удостоверяване за POP3.

В секцията http - сървър добавете:

сървър (
слушане 80 default_server;
слушам [::]:80 default_server;
...

Местоположение ~ \.php$ (
задайте $root_path /usr/share/nginx/html;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $root_path$fastcgi_script_name;
включват fastcgi_params;
fastcgi_param DOCUMENT_ROOT $root_path;
}
...

Рестартирайте nginx сървъра:

systemctl рестартирайте nginx

Инсталиране и конфигуриране на PHP

За да извършите удостоверяване с помощта на PHP, трябва да инсталирате следните пакети на вашата система.

Ако CentOS:

yum инсталирайте php php-fpm

Ако Ubuntu:

apt-get инсталирате php php-fpm

Стартирайте PHP-FPM:

systemctl активира php-fpm

systemctl стартира php-fpm

Удостоверяване

Проверката на влизане и парола се извършва от скрипт, пътят до който се посочва от опцията auth_http. В нашия пример това е PHP скрипт.

Пример за официален шаблон за скрипт за проверка на вход и парола:

vi /usr/share/nginx/html/auth.php

* този скрипт приема всяко влизане и парола и пренасочва заявки към сървъри 192.168.1.22 и 192.168.1.33. За да зададете алгоритъма за удостоверяване, редактирайте редове 61 - 64. Редове 73 - 77 отговарят за връщането на сървърите, към които е направено пренасочването - в този пример, ако влизането започва със знаците "a", "c", "f" ”, “g”, тогава пренасочването ще бъде към сървъра mailhost01, в противен случай към mailhost02. Съпоставянето на имена на сървъри към IP адреси може да бъде зададено на редове 31, 32, в противен случай повикването ще бъде направено с помощта на името на домейна.

Настройка на пощенски сървър

Обменът на данни между NGINX проксито и пощенския сървър се извършва в отворена форма. Необходимо е към изключението да се добави възможността за удостоверяване с помощта на механизма PLAIN. Например, за да конфигурирате dovecot, направете следното:

vi /etc/dovecot/conf.d/10-auth.conf

Добавете редовете:

отдалечено 192.168.1.11 (
disable_plaintext_auth = не
}

* в този пример разрешихме обикновени заявки за удостоверяване от сървър 192.168.1.11.

Проверяваме също:

* ако ssl е настроен на required, проверката няма да работи, тъй като се оказва, че от една страна сървърът позволява заявки в чист текст, но изисква ssl криптиране.

Рестартирайте услугата Dovecot:

systemctl рестартирайте dovecot

Настройка на клиента

Можете да продължите към проверка на нашите прокси настройки. За да направите това, в настройките на клиента посочете адреса или името на nginx сървъра като IMAP/POP2/SMTP, например:

* в този пример клиентът за електронна поща е конфигуриран да се свързва със сървър 192.168.1.11 чрез отворени портове 143 (IMAP) и 25 (SMTP).

Шифроване

Сега нека настроим SSL връзка. Nginx трябва да бъде изграден с модула mail_ssl_module - проверете с командата:

Ако необходимият модул липсва, ние възстановяваме nginx.

След това редактираме нашия конфигурационен файл:

vi /etc/nginx/nginx.conf

поща (
сървър_име mail.domain.local;
auth_http localhost/auth.php;

Proxy_pass_error_message включено;

Ssl включен;
ssl_сертификат /etc/ssl/nginx/public.crt;
ssl_certificate_key /etc/ssl/nginx/private.key;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_session_cache споделен:SSL:10m;
ssl_session_timeout 10m;

сървър (
слушам 110;
протокол pop3;
pop3_auth обикновен apop cram-md5;
}

сървър (
слушай 143;
имап на протокола;
}

Причина: Системата за сигурност SELinux е задействана.

Решение: деактивирайте или конфигурирайте SELinux.

Nginx бързо набира популярност, превръщайки се от просто статичен ускорител за доставка за Apache в напълно функционален и разработен уеб сървър, който все повече се използва изолирано. В тази статия ще говорим за интересни и нестандартни сценарии за използване на nginx, които ще ви позволят да извлечете максимума от вашия уеб сървър.

Пощенски прокси

Нека започнем с най-очевидното – със способността на nginx да действа като прокси за електронна поща. Тази функция първоначално присъства в nginx, но по някаква причина се използва изключително рядко в производството; някои хора дори не знаят за нейното съществуване. Както и да е, nginx поддържа прокси POP3, IMAP и SMTP протоколи с различни методи за удостоверяване, включително SSL и StartTLS, и го прави много бързо.

Защо е необходимо това? Има поне две приложения за тази функционалност. Първо: използвайте nginx като щит срещу досадните спамери, опитващи се да изпращат нежелани имейли през нашия SMTP сървър. Обикновено спамърите не създават много проблеми, тъй като бързо се отхвърлят на етапа на удостоверяване, но когато наистина има много от тях, nginx ще помогне да се спестят ресурси на процесора. Второ: използвайте nginx за пренасочване на потребителите към множество POP3/IMAP пощенски сървъри. Разбира се, друг пощенски прокси би могъл да се справи с това, но защо да изолирате сървърите, ако nginx вече е инсталиран на предния край, за да обслужва статично съдържание чрез HTTP, например?

Пощенският прокси сървър в nginx не е съвсем стандартен. Той използва допълнителен слой за удостоверяване, реализиран с помощта на HTTP, и само ако потребителят премине тази бариера, му е позволено да продължи по-нататък. Тази функционалност се предоставя чрез създаване на страница/скрипт, на който nginx изпраща потребителски данни и той/той връща отговор под формата на стандартно OK или причина за отказ (като „Невалидно потребителско име или парола“). Скриптът се изпълнява със следните заглавки:

Входни данни на скрипта за удостоверяване HTTP_AUTH_USER: потребител HTTP_AUTH_PASS: парола HTTP_AUTH_PROTOCOL: пощенски протокол (IMAP, POP3 или SMTP)

И връща следното:

Изход от скрипта за удостоверяване HTTP_AUTH_STATUS: OK или причина за неуспех HTTP_AUTH_SERVER: истински пощенски сървър за пренасочване HTTP_AUTH_PORT: порт на сървъра

Забележителна характеристика на този подход е, че той изобщо не може да се използва за самото удостоверяване, а за разпръскване на потребителите между различни вътрешни сървъри, в зависимост от потребителското име, данни за текущото натоварване на пощенските сървъри или дори чрез организиране на просто балансиране на натоварването използвайки Round Robin. Ако обаче просто трябва да прехвърлите потребители към вътрешен пощенски сървър, можете да използвате мъниче, реализирано от самия nginx, вместо истински скрипт. Например, най-простият SMTP и IMAP прокси в конфигурацията на nginx ще изглежда така:

# vi /etc/nginx/nginx.conf mail ( # Адрес на скрипт за удостоверяване auth_http localhost:8080/auth; # Деактивирайте командата XCLIENT, някои пощенски сървъри не я разбират xclient off; # IMAP сървър сървър ( слушайте 143; protocol imap; прокси включен; ) # SMTP сървър сървър ( слушане 25; протокол smtp; прокси включен; ) )

# vi /etc/nginx/nginx.conf http ( # Съпоставяне към желания порт на сървъра за електронна поща в зависимост от порта, изпратен в картата на заглавката HTTP_AUTH_PROTOCOL $http_auth_protocol $mailport (по подразбиране 25; smtp 25; imap 143; ) # Изпълнение на удостоверяването “скрипт” - винаги връща OK и прехвърля потребителя към вътрешния пощенски сървър, като задава желания порт с помощта на горния сървър за картографиране ( listen 8080; местоположение /auth ( add_header "Auth-Status" "OK"; add_header "Auth-Server" "192.168.0.1" ; add_header "Auth-Port" $mailport; връща 200; ) ) )

Това е всичко. Тази конфигурация ви позволява прозрачно да пренасочвате потребителите към вътрешния пощенски сървър, без да създавате допълнителни разходи под формата на скрипт, който е ненужен в този случай. Чрез използване на скрипт тази конфигурация може да бъде значително разширена: конфигуриране на балансиране на натоварването, проверка на потребителите чрез базата данни LDAP и извършване на други операции. Писането на скрипта е извън обхвата на тази статия, но е много лесно за изпълнение дори само с междинни познания по PHP и Python.

Видео стрийминг

Лесно е да настроите обикновен видео хостинг, базиран на nginx. Всичко, което трябва да направите, е да качите транскодираното видео в директория, достъпна за сървъра, да го регистрирате в конфигурацията и да конфигурирате Flash или HTML5 плейъра, така че да взема видеото от тази директория. Въпреки това, ако трябва да настроите непрекъснато видео излъчване от някои външен източникили уеб камера, тази схема няма да работи и ще трябва да търсите специални протоколи за стрийминг.

Има няколко протокола, които решават този проблем, най-ефективният и поддържан от тях е RTMP. Единственият проблем е, че почти всички реализации на RTMP сървър страдат от проблеми. Официалният Adobe Flash Media Server е платен. Red5 и Wowza са написани на Java и следователно не предоставят необходима производителност, Друга реализация, Erlyvideo, е написана на Erlang, което е добро за настройка на клъстер, но не е толкова ефективно за един сървър.

Предлагам различен подход - използвайте RTMP модула за nginx. Той има отлична производителност и също така ще ви позволи да използвате един сървър, за да обслужвате както уеб интерфейса на сайта, така и видео потока. Единственият проблем е, че този модул е ​​неофициален, така че ще трябва сами да изградите nginx с неговата поддръжка. За щастие монтажът се извършва по стандартен начин:

$ sudo apt-get премахнете nginx $ cd /tmp $ wget http://bit.ly/VyK0lU -O nginx-rtmp.zip $ разархивирайте nginx-rtmp.zip $ wget http://nginx.org/download/nginx- 1.2.6.tar.gz $ tar -xzf nginx-1.2.6.tar.gz $ cd nginx-1.2.6 $ ./configure --add-module=/tmp/nginx-rtmp-module-master $ make $ sudo make install

Сега модулът трябва да бъде конфигуриран. Това се прави, както обикновено, чрез конфигурацията на nginx:

Rtmp ( # Активирайте излъчващия сървър на порт 1935 на адрес сайт/rtmp сървър ( слушайте 1935; приложение rtmp ( на живо; ) ) )

RTMP модулът не може да работи в многонишкова конфигурация, така че броят на работните процеси на nginx ще трябва да бъде намален до един (по-късно ще ви кажа как да заобиколите този проблем):

Работни_процеси 1;

Сега можете да запишете файла и да принудите nginx да прочете отново конфигурацията. Настройката на nginx е завършена, но все още нямаме самия видеопоток, така че трябва да го вземем някъде. Например, нека това да е файлът video.avi от текущата директория. За да го превърнем в поток и да го опаковаме в нашия RTMP разпространител, ще използваме добрия стар FFmpeg:

# ffmpeg -re -i ~/video.avi -c копиране -f flv rtmp://localhost/rtmp/stream

Ако видео файлът не е във формат H264, той трябва да бъде прекодиран. Това може да се направи в движение с помощта на същия FFmpeg:

# ffmpeg -re -i ~/video.avi -c:v libx264 -c:a libfaac -ar 44100 -ac 2 -f flv rtmp://localhost/rtmp/stream

Потокът може да бъде заснет и директно от уеб камера:

# ffmpeg -f video4linux2 -i /dev/video0 -c:v libx264 -an -f flv rtmp://localhost/rtmp/stream

За да видите потока от страна на клиента, можете да използвате всеки плейър, който поддържа RTMP, например mplayer:

$ mplayer rmtp://example.com/rtmp/stream

Или вградете плейъра директно в уеб страница, която се обслужва от същия nginx (пример от официалната документация):

Най-простият RTMP уеб плейър

jwplayer("container").setup(( modes: [( type: "flash", src: "/jwplayer/player.swf", config: ( bufferlength: 1, file: "stream", streamer: "rtmp:/ /localhost/rtmp", доставчик: "rtmp", ) )] ));

Тук има само два важни реда: „file: „stream““, указващ RTMP потока, и „streamer: „rtmp://localhost/rtmp““, който указва адреса на RTMP streamer. За повечето задачи такива настройки ще бъдат напълно достатъчни. Можете да изпратите няколко различни потока на един адрес и nginx ефективно ще ги мултиплексира между клиенти. Но това не е всичко, на което RTMP модулът е способен. С негова помощ, например, можете да организирате предаване на видео поток от друг сървър. FFmpeg сървърът изобщо не е необходим за това, просто добавете следните редове към конфигурацията:

# vi /etc/nginx/nginx.conf приложение rtmp ( live on; изтегляне rtmp://rtmp.example.com; )

Ако трябва да създадете множество потоци с различно качество, можете да извикате транскодера FFmpeg директно от nginx:

# vi /etc/nginx/nginx.conf приложение rtmp ( live on; exec ffmpeg -i rtmp://localhost/rtmp/$name -c:v flv -c:a -s 320x240 -f flv rtmp://localhost /rtmp-320x240/$name; ) приложение rtmp-320x240 ( на живо; )

С тази конфигурация ще получим два разпространителя наведнъж, единият от които ще бъде достъпен на адрес rtmp://site/rtmp, а вторият, излъчващ с качество 320 x 240, на адрес rtmp://site/rtmp –320x240. След това можете да добавите флаш плейър и бутони за избор на качество към сайта, което ще даде на играча един или друг адрес на излъчване.

И накрая, пример за излъчване на музика в мрежата:

Докато е вярно; направете ffmpeg -re -i "`find /var/music -type f -name "*.mp3"|sort -R|head -n 1`" -vn -c:a libfaac -ar 44100 -ac 2 -f flv rtmp://localhost/rtmp/stream; Свършен

Git прокси

Системата за контрол на версиите Git е в състояние да осигури достъп до хранилища не само чрез протоколите Git и SSH, но и чрез HTTP. Имало едно време внедряването на HTTP достъп беше примитивно и не можеше да осигури пълноценна работа с хранилището. С версия 1.6.6 ситуацията се промени и днес този протокол може да се използва например за заобикаляне на ограниченията на защитната стена от двете страни на връзката или за създаване на собствен Git хостинг с уеб интерфейс.

За съжаление официалната документация говори само за организиране на достъпа до Git с помощта на уеб сървъра Apache, но тъй като самото внедряване е външно приложениесъс стандартен CGI интерфейс, той може да бъде прикрепен към почти всеки друг сървър, включително lighttpd и, разбира се, nginx. Това не изисква нищо освен самия сървър, инсталиран Git и малък FastCGI сървър fcgiwrap, който е необходим, защото nginx не знае как да работи директно с CGI, но може да извиква скриптове, използвайки FastCGI протокола.

Цялата схема на работа ще изглежда така. Сървърът fcgiwrap ще виси във фонов режим и ще чака заявка за изпълнение на CGI приложението. Nginx, от своя страна, ще бъде конфигуриран да изисква изпълнение на git-http-backend CGI бинарния файл чрез интерфейса FastCGI всеки път, когато адресът, който посочим, е достъпен. При получаване на заявката fcgiwrap изпълнява git-http-backend с посочените CGI аргументи, предадени от GIT клиента, и връща резултата.

За да приложите такава схема, първо инсталирайте fcgiwrap:

$ sudo apt-get инсталирайте fcgiwrap

Няма нужда да го конфигурирате, всички параметри се предават чрез протокола FastCGI. Освен това ще се стартира автоматично. Следователно всичко, което остава, е да конфигурирате nginx. За да направите това, създайте файл /etc/nginx/sites-enabled/git (ако няма такава директория, можете да пишете в основната конфигурация) и напишете следното в него:

# vi /etc/nginx/sites-enabled/git сървър ( # Висим на порт 8080, слушаме 8080; # Адресът на нашия сървър (не забравяйте да добавите запис в DNS) име на сървър git.example.ru; # Регистрира access_log /var/log/nginx /git-http-backend.access.log; error_log /var/log/nginx/git-http-backend.error.log; # Основен адрес за местоположение за анонимен достъп / ( # При опит за изтегляне, изпрати потребителя на частен адрес, ако ($ arg_service ~* "git-receive-pack") ( rewrite ^ /private$uri last; ) include /etc/nginx/fastcgi_params; # Адрес на нашия git-http-backend fastcgi_param SCRIPT_FILENAME /usr/lib/git-core/git-http-backend; # Git адрес на хранилище fastcgi_param GIT_PROJECT_ROOT /srv/git; # Файлов адрес fastcgi_param PATH_INFO $uri; # fcgiwrap адрес на сървър fastcgi_pass 127.0.0.1:9001; ) # Адрес за достъп за запис местоположение ~/private(/.* )$ ( # Потребителски разрешения auth_basic "git анонимен само за четене, удостоверен запис"; # HTTP удостоверяване на базата на htpasswd auth_basic_user_file /etc/nginx/htpasswd; # FastCGI настройките включват /etc/nginx/fastcgi_params ; fastcgi_param SCRIPT_FILENAME /usr/lib/git-core/git-http-backend; fastcgi_param GIT_PROJECT_ROOT /srv/git; fastcgi_param PATH_INFO $1; fastcgi_pass 127.0.0.1:9001; ) )

Тази конфигурация предполага три важни неща:

Адресът на хранилището ще бъде /srv/git, така че задаваме подходящите права за достъп: $ sudo chown -R www-data:www-data /srv/git

Самото хранилище трябва да е отворено за четене от анонимни потребители и да позволява качване чрез HTTP: $ cd /srv/git $ git config core.sharedrepository true $ git config http.receivepack true

Удостоверяването се извършва с помощта на файла htpasswd, трябва да го създадете и да добавите потребители към него: $ sudo apt-get install apache2-utils $ htpasswd -c /etc/nginx/htpasswd user1 $ htpasswd /etc/nginx/htpasswd user2 . ..

Това е всичко, рестартирайте nginx:

Микрокеширане

Нека си представим ситуация с динамичен, често актуализиран уебсайт, който внезапно започва да получава много големи натоварвания (е, той се озова на страницата на един от най-големите новинарски сайтове) и престава да се справя с връщането на съдържание. Правилната оптимизация и прилагането на правилната схема за кеширане ще отнеме много време и проблемите трябва да бъдат решени сега. Какво можем да направим?

Има няколко начина да излезете от тази ситуация с най-малко загуби, но най-интересната идея е предложена от Фен Бейли (fennb.com). Идеята е просто да поставите nginx пред сървъра и да го принудите да кешира цялото предавано съдържание, но не само кеша, а само за една секунда. Обратът тук е, че стотици и хиляди посетители на сайта в секунда всъщност ще генерират само една заявка към бекенда, получавайки предимно кеширана страница. В същото време едва ли някой ще забележи разликата, защото дори и на динамичен сайт една секунда обикновено не означава нищо.

Конфигурацията с реализацията на тази идея няма да изглежда толкова сложна:

# vi /etc/nginx/sites-enabled/cache-proxy # Конфигурация на кеша proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=microcache:5m max_size=1000m; server ( listen 80; server_name example.com; # Кеширано местоположение на адреса / ( # Кешът е активиран по подразбиране set $no_cache ""; # Деактивиране на кеша за всички методи освен GET и HEAD if ($request_method !~ ^(GET|HEAD) $) ( set $no_cache "1"; ) # Ако клиентът качи съдържание на сайта (no_cache = 1), ние се уверяваме, че предоставените му данни не са кеширани за две секунди и той може да види резултата от изтеглянето if ($no_cache = "1") ( add_header Set-Cookie "_mcnc=1; Max-Age=2; Path=/"; add_header X-Microcachable "0"; ) if ($http_cookie ~* "_mcnc") ( set $no_cache "1 "; ) # Активиране/деактивиране на кеша в зависимост от състоянието на променливата no_cache proxy_no_cache $no_cache; proxy_cache_bypass $no_cache; # Прокси заявки към реалния сървър proxy_pass http://appserver.example.ru; proxy_cache microcache ; proxy_cache_key $scheme$host$request_method$ request_uri; proxy_cache_valid 200 1s; # Защита от проблема със стадото Thundering proxy_cache_use_stale updating; # Добавяне на стандартни заглавки proxy_set_header Хост $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # Ние не кешираме файлове, по-големи от 1 MB proxy_max_temp_file_size 1M; ) )

Специално място в тази конфигурация заема редът „proxy_cache_use_stale updating;“, без който щяхме да получаваме периодични изблици на натоварване на бекенд сървъра поради заявки, получени по време на актуализиране на кеша. Иначе всичко е стандартно и трябва да е ясно без излишни обяснения.

Доближаване на проксита до целевата аудитория

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

Един от възможните варианти: да поставите основния продуктивен сървър на Запад и да разположите фронтенд, който не е твърде изискващ ресурси и произвежда статични данни в Русия. Това ще ви позволи да спечелите скорост без сериозни разходи. Конфигурацията на nginx за интерфейса в този случай ще бъде проста и позната прокси реализация на всички нас:

# vi /etc/nginx/sites-enabled/proxy # Съхранявайте кеша за 30 дни в 100 GB място за съхранение proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=static:32m inactive=30d max_size=100g; сървър ( слушайте 80; име на сървър example.com; # Всъщност нашето прокси местоположение ~* .(jpg|jpeg|gif|png|ico|css|midi|wav|bmp|js|swf|flv|avi|djvu|mp3) $ ( # Backend адрес proxy_pass back.example.com:80; proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_buffer_size 16k; proxy_buffers 32 16k; proxy_cache sta тик; proxy_cache_valid 30d; proxy_ignore_headers "Cache-Control" "Expires"; proxy_cache_key "$uri$is_args$args"; proxy_cache_lock on; ) )

заключения

Днес с помощта на nginx можете да разрешите много различни проблеми, много от които изобщо не са свързани с уеб сървъра и HTTP протокола. Пощенски прокси, стрийминг сървър и Git интерфейс са само част от тези задачи.