Poštovní server Nginx. Nastavení NGINX pro poštovní proxy

Tento článek vysvětlí, jak nakonfigurovat NGINX Plus nebo NGINX Open Source jako proxy pro poštovní server nebo externí poštovní službu.

Úvod

NGINX může proxy protokoly IMAP, POP3 a SMTP k jednomu z upstream poštovních serverů, které jsou hostiteli poštovních účtů, a lze je tedy použít jako jediný koncový bod pro e-mailové klienty. To může přinést řadu výhod, například:

• snadné škálování počtu poštovních serverů
• výběr poštovního serveru na základě různých pravidel, například výběr nejbližšího serveru na základě IP adresy klienta
• rozložení zátěže mezi poštovní servery

Předpoklady

NGINX Plus (již obsahuje moduly Mail nezbytné pro e-mailový provoz proxy) nebo NGINX Open Source zkompilovaly moduly pošty pomocí parametru --with-mail pro funkci e-mailového proxy serveru a parametru --with-mail_ssl_module pro podporu SSL/TLS:

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

poštovní servery IMAP, POP3 a/nebo SMTP nebo externí poštovní služba

Konfigurace poštovních proxy serverů SMTP/IMAP/POP3

V konfiguračním souboru NGINX:

pošta ( #... )

mail (název_serveru mail.example.com; #...)

mail (název_serveru mail.example.com; auth_http localhost: 9000 /cgi-bin/nginxauth.cgi; #...)

Případně určete, zda má být uživatel informován o chybách z ověřovacího serveru, zadáním direktivy proxy_pass_error_message. To může být užitečné, když poštovní schránce dojde paměť:

mail (server_name mail.example.com; auth_http localhost: 9000 /cgi-bin/nginxauth.cgi; proxy_pass_error_message on; #...)

Nakonfigurujte každý server SMTP, IMAP nebo POP3 pomocí bloků serveru. Pro každý server zadejte:

• a číslo portu které odpovídají zadanému protokolu s direktivou listen
• a protokol s direktivou protokolu (pokud není uvedena, bude automaticky detekována z portu uvedeného v direktivě listen)
• povoleno autentizační metody s direktivami imap_auth, pop3_auth a smtp_auth:

server ( listen 25 ; protokol smtp ; smtp_auth přihlášení prostý cram-md5 ; ) server ( poslech 110 ; protokol pop3 ; pop3_auth prostý apop cram-md5 ; ) server ( poslech 143 ; protokol imap ; )

Nastavení ověřování pro poštovní proxy

Každý POP3/IMAP/SMTP požadavek od klienta bude nejprve ověřen na externím HTTP autentizačním serveru nebo autentizačním skriptem. Pro proxy poštovního serveru NGINX je povinné mít autentizační server. Server si můžete vytvořit sami v souladu s ověřovacím protokolem NGINX, který je založen na protokolu HTTP.

Pokud je autentizace úspěšná, autentizační server vybere upstream server a přesměruje požadavek. V tomto případě bude odpověď ze serveru obsahovat následující řádky:

HTTP/1.0 200 OK Auth-Status: OK Auth-Server: # název serveru nebo IP adresa upstream serveru, který bude použit pro zpracování pošty Auth-Port: # port upstream serveru

Pokud se ověření nezdaří, ověřovací server vrátí chybovou zprávu. V tomto případě bude odpověď ze serveru obsahovat následující řádky:

HTTP/1.0 200 OK Auth-Status: # chybová zpráva, která má být vrácena klientovi, například „Neplatné přihlašovací jméno nebo heslo“ Auth-Wait: # počet zbývajících pokusů o ověření do ukončení připojení

Všimněte si, že v obou případech bude odpověď obsahovat HTTP/1.0 200 OK což může být matoucí.

Další příklady požadavků na ověřovací server a odpovědí z něj naleznete v modulu ngx_mail_auth_http_module v dokumentaci NGINX Reference.

Nastavení SSL/TLS pro poštovní proxy

Pomocí POP3/SMTP/IMAP přes SSL/TLS zajistíte, že data předávaná mezi klientem a poštovním serverem jsou zabezpečena.

Povolení SSL/TLS pro poštovní proxy:

Ujistěte se, že je váš NGINX nakonfigurován s podporou SSL/TLS zadáním příkazu nginx -V do příkazového řádku a poté vyhledáním řádku with --mail_ssl_module ve výstupu:

$ nginx -V konfigurace argumentů: ... with--mail_ssl_module

Ujistěte se, že jste získali certifikáty serveru a soukromý klíč a vložte je na server. Certifikát lze získat od důvěryhodné certifikační autority (CA) nebo vygenerovat pomocí knihovny SSL, jako je OpenSSL.

ssl zapnuto;

starttls on ;

Přidejte certifikáty SSL: zadejte cestu k certifikátům (které musí být ve formátu PEM) pomocí direktivy ssl_certificate a zadejte cestu k soukromému klíči v direktivě ssl_certificate_key:

mail ( #... ssl_certificate /etc/ssl/certs/server.crt ; ssl_certificate_key /etc/ssl/certs/server.key ; )

S direktivami ssl_protocols a ssl_ciphers můžete používat pouze silné verze a šifry SSL/TLS, nebo můžete nastavit vlastní preferované protokoly a šifry:

mail ( #... ssl_protocols TLSv1 TLSv1.1 TLSv1.2 ; ssl_ciphers HIGH:!aNULL:!MD5 ; )

Optimalizace SSL/TLS pro Mail Proxy

Tyto rady vám pomohou zrychlit a zabezpečit poštovní server NGINX:

Nastavte počet pracovních procesů rovný počtu procesorů s direktivou worker_processes nastavenou na stejnou úroveň jako kontext pošty:

worker_processes auto ; pošta ( #... )

Povolte mezipaměť sdílené relace a deaktivujte vestavěnou mezipaměť relací pomocí automatického ; mail ( server_name 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 ; ssts/serverl_certificate/certificate klíč ; ssl_protocols TLSv1 TLSv1.1 TLSv1.2 ; ssl_ciphers HIGH:!aNULL:!MD5 ; ssl_session_cache shared:SSL:10m ; ssl_session_timeout 10m ; server ( listen 25 ; protokol smt-server smtp5 1 10 ; protokol pop3 ; pop3_auth prostý apop cram-md5 ; ) server ( poslech 143 ; protokol imap ; ) )

V tomto příkladu jsou tři e-mailové proxy servery: SMTP, POP3 a IMAP. Každý ze serverů je nakonfigurován s podporou SSL a STARTTLS. Parametry relace SSL budou uloženy do mezipaměti.

Proxy server používá HTTP autentizační server – jeho konfigurace je nad rámec tohoto článku. Všechny chybové zprávy ze serveru budou vráceny klientům.

iRedMail je připravená montáž poštovní server s otevřeným zdrojový kód. Sestavení je založeno na serveru Postfix SMTP (Mail Transfer Agent, zkráceně MTA). Sestava dále zahrnuje: Dovecot, SpamAssassin, Greylist, ClamAV, SOGo Roundcube, NetData a NGINX.

Dovecot - IMAP/POP3 server.

Spamassassin je nástroj pro filtrování spamu.

Greylist je antispamový nástroj založený na greylistu.

ClamAV je antivirus.

Roundcube a SOGo jsou weboví klienti pro práci s emailem.

NetData je program pro monitorování serveru v reálném čase.

Nginx je webový server.

Podporuje operační systémy: CentOS 7, Debian 9, Ubuntu 16.04/18.04, FreeBSD 11/12 a OpenBSD 6.4.

iRedMail má placenou a neplacenou verzi, které se od sebe liší funkčností vlastního webového rozhraní poštovního sestavení iRedAdmin. V bezplatná verze Můžete vytvářet pouze domény, uživatelské a administrátorské poštovní schránky. Pokud si potřebujete vytvořit alias, v bezplatné verzi přes iRedAdmin to již neuděláte. Naštěstí existuje bezplatné řešení s názvem PostfixAdmin, které vám to umožňuje. PostfixAdmin se snadno integruje do iRedMail a skvěle se s ním pracuje.

Instalace

K instalaci budeme potřebovat jeden z výše uvedených operačních systémů. Budu používat Ubuntu Server 18.04. Musíte mít také zakoupeno Doménové jméno a nakonfigurovanou zónu DNS. Pokud používáte DNS servery registrátora domény, pak musíte v sekci správy zóny domény provést dva záznamy: A a MX. Můžete také použít svůj vlastní DNS nastavením delegování v osobní účet registrátora vašeho doménového jména.

Nastavení zóny domény při použití registrátora DNS

Poznámka! Čas vstupu Nastavení DNS trvající od několika hodin do jednoho týdne. Dokud se nastavení neprojeví, poštovní server nebude fungovat správně.

Chcete-li nainstalovat, stáhněte si z webu iRedMail současná verze. Aktuálně je to 0.9.9.

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

Poté stažený archiv rozbalte.

# tar xjf iRedMail-0.9.9.tar.bz2

Rozbalení archivu

A přejděte do vytvořené složky.

# cd iRedMail-0.9.9

složka instalačního programu iRedMail

Kontrola obsahu složky

Obsah složky

A spusťte instalační skript iRedMail.

# bash iRedMail.sh

Spustí se instalace poštovního systému. Během procesu instalace budete muset odpovědět na řadu otázek. Souhlasíme se zahájením instalace.

Spusťte instalaci

Výběr instalačního adresáře

Nyní musíte vybrat webový server. Není moc na výběr, tak volíme NGINX.

Výběr webového serveru

Nyní musíte vybrat databázový server, který bude nainstalován a nakonfigurován pro práci s poštovním systémem. Vyberte MariaDB.

Výběr databázového serveru

Nastavte heslo uživatele root pro databázi.

Vytvoření hesla root databáze

Nyní označíme naši e-mailovou doménu.

Vytvoření poštovní domény

Poté vytvoříme heslo pro poštovní schránku správce [email protected].

Vytvoření hesla správce pošty

Výběr webových komponent

Potvrďte zadaná nastavení.

Potvrzení nastavení

Instalace byla zahájena.

Instalace

Po dokončení instalace potvrďte vytvoření pravidla iptables pro SSH a restartujte firewall. iRedMail pracuje s iptables. V Ubuntu je nejčastěji používaným nástrojem pro správu firewallu UFW. Pokud z toho či onoho důvodu máte takovou potřebu, nainstalujte UFW (apt install ufw) a přidejte pravidla, aby UFW (příklad: ufw povolte "Nginx Full" nebo ufw povolil Postfix) neblokovalo práci poštovního serveru. Seznam dostupných pravidel zobrazíte spuštěním příkazu: ufw app list . Poté povolte UFW: ufw povolte.

Vytvoření pravidla iptables

Restartování firewallu

Tím je instalace iRedMail dokončena. Systém nám poskytl adresy webového rozhraní a přihlašovací údaje. Chcete-li povolit všechny součásti poštovního systému, musíte restartovat server.

Dokončení instalace

Pojďme restartovat.

# restart

Nastavení

Nejprve se musíte ujistit, že vše funguje. Zkusme se přihlásit do ovládacího panelu iReadAdmin na https://domain/iredadmin. Přihlášení [email protected], heslo vytvořené během instalace. Existuje rozhraní v ruském jazyce.

Jak vidíte, vše funguje. Při přihlašování do iRedAdmin jste s největší pravděpodobností obdrželi bezpečnostní chybu související s certifikátem. K tomu dochází, protože iRedMail má vestavěný certifikát s vlastním podpisem, na který si prohlížeč stěžuje. Chcete-li tento problém vyřešit, musíte nainstalovat platný certifikát SSL. Pokud máte zakoupený, můžete si jej nainstalovat. V příkladu nainstaluji bezplatné SSL od Let's Encrypt.

Instalace certifikátu Let's Encrypt SSL

Certifikát nainstalujeme pomocí utility certbot. Nejprve přidáme úložiště.

# add-apt-repository ppa:certbot/certbot

Poté nainstalujeme samotný certboot s potřebnými komponentami.

# apt install python-certbot-nginx

Dostáváme certifikát.

# certbot --nginx -d domain.ru

Po spuštění příkazu vás systém vyzve k zadání vaší emailové adresy, enter. Poté se s největší pravděpodobností zobrazí chyba, že nelze najít blok serveru, pro který byl certifikát vygenerován. V tomto případě je to normální, protože nemáme žádný blok serveru. Hlavní je pro nás získat certifikát.

Získání certifikátu

Jak vidíme, certifikát byl úspěšně přijat a systém nám ukázal cesty k samotnému certifikátu a ke klíči. Jsou přesně to, co potřebujeme. Obecně jsme obdrželi 4 soubory, které budou uloženy ve složce "/etc/letsencrypt/live/domain". Nyní musíme o našem certifikátu informovat webový server, to znamená nahradit vložený certifikát tím, který jsme právě obdrželi. K tomu potřebujeme upravit pouze jeden soubor.

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

A měníme v něm poslední dva řádky.

Výměna certifikátu SSL

Cesty v souboru změníme na cesty, které nám systém řekl při příjmu certifikátu.

Výměna certifikátu SSL

A restartujte NGINX.

# restart služby nginx

Nyní se zkusme znovu přihlásit do iRedAdmin.

Ověření certifikátu SSL

Chyba certifikátu již neexistuje. Certifikát je platný. Můžete kliknout na zámek a zobrazit jeho vlastnosti. Po vypršení platnosti certifikátu by jej měl certboot automaticky obnovit.

Nyní budeme informovat o certifikátu Dovecot a Postfix. K tomu upravíme dva konfigurační soubory. My ano:

# nano /etc/dovecot/dovecot.conf

Nalezení bloku:

#SSL: Globální nastavení.

A certifikát tam registrovaný změníme na náš.

Náhradní certifikát pro Dovecot

Pozor také na řádek "ssl_protocols". Jeho hodnota musí být "!SSLv3", jinak se při restartu Dovecot zobrazí chyba "Upozornění: SSLv2 není podporováno OpenSSL. Zvažte jeho odstranění z ssl_protocols".

# nano /etc/postfix/main.cf

Nalezení bloku:

# Klíč SSL, certifikát, CA

A měníme v něm cesty na cestě k souborům našeho certifikátu.

Nahrazení certifikátu pro Postfix

Tím je instalace certifikátu dokončena. Je nutné restartovat Dovecot a Postfix, ale je lepší restartovat server.

# restart služby dovecot

# restart

Instalace PHPMyAdmin

Tento krok je volitelný, ale doporučuji to udělat a nainstalovat PHPMyAdmin pro snadnou práci s databázemi.

# apt install phpmyadmin

Instalační program se zeptá, se kterým webovým serverem má PHPMyAdmin pracovat, protože NGINX není na tomto seznamu, stačí stisknout TAB a pokračovat.

Instalace PHPMyAdmin

Po dokončení instalace, aby phpmyadmin fungoval, musíte vytvořit symbolický odkaz na adresář, se kterým NGINX standardně pracuje.

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

A zkusíme jít na https://domain/phpmyadmin/

PHPMyAdmin běží. Připojení je chráněno certifikátem, nedochází k žádným chybám. Pokračuj. Vytvořme správce databáze MySQL (MariaDB).

# mysql

A dostáváme se k řídící konzoli MariaDB. Dále spustíme příkazy jeden po druhém:

MariaDB > VYTVOŘIT UŽIVATELE "admin"@"localhost" IDENTIFIKOVANÉ PODLE "hesla";
MariaDB > UDĚLEJTE VŠECHNA PRIVILEGIA NA *.* "admin"@"localhost" S MOŽNOSTÍ UDĚLENÍ;
MariaDB > FLUSH PRIVILEGES;

Vytvoření uživatele MySQL

Vše v pořádku, přihlášení je dokončeno. PHPMyAdmin je připraven.

Instalace PostfixAdmin

PostfixAdmin, stejně jako PHPMyAdmin, v zásadě není potřeba instalovat. Poštovní server bude fungovat dobře i bez těchto komponent. Pak ale nebudete moci vytvářet poštovní aliasy. Pokud to nepotřebujete, můžete tyto sekce bezpečně přeskočit. Pokud stále potřebujete aliasy, máte dvě možnosti: zakoupit placenou verzi iReaAdmin nebo nainstalovat PostfixAdmin. Samozřejmě to můžete udělat bez dalšího softwaru, ruční registrací aliasů do databáze, ale to není vždy pohodlné a není vhodné pro každého. Doporučuji používat PostfixAdmin; nyní se podíváme na jeho instalaci a integraci s iRedMail. Začněme instalaci:

# apt install postfixadmin

Souhlasíme a vytváříme heslo pro systémovou databázi programu.

Instalace PostfixAdmin

Instalace PostfixAdmin

Symbolický odkaz vytvoříme stejným způsobem jako při instalaci PHPMyAdmin.

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

Vlastníkem adresáře činíme uživatele, jehož jménem je webový server spuštěn. V našem případě je NGINX spuštěn jako uživatel www-data.

# chown -R www-data /usr/share/postfixadmin

Nyní musíme upravit konfigurační soubor PostfixAdmin a přidat informace o databázi, kterou iRedAdmin používá. Ve výchozím nastavení se tato databáze nazývá vmail. Pokud přejdete na PHPMyAdmin, můžete to tam vidět. A tak, aby PostfixAdmin mohl provádět změny v databázi, registrujeme ji v konfiguraci PostfixAdmin.

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

Najdeme řádky:

$CONF["database_type"] = $dbtype;
$CONF["database_host"] = $dbserver;
$CONF["database_user"] = $dbuser;
$CONF["database_password"] = $dbpass;
$CONF["název_databáze"] = $dbname;

A připomeňme si to:

$CONF["database_type"] = "mysqli"; # Typ databáze
$CONF["database_host"] = "místní hostitel"; # Hostitel databázového serveru
$CONF["database_user"] = "admin"; # Přihlaste se s právy k zápisu do databáze vmail. Můžete použít dříve vytvořeného správce
$CONF["database_password"] = "heslo"; # Heslo pro uživatele uvedeného výše
$CONF["database_name"] = "vmail"; # Název databáze iRedMail

Zadávání informací o databázi

Pokud plánujete používat webového poštovního klienta SOGo, musíte udělat ještě jeden krok navíc, a to změnit šifrování PostfixAdmin v položce $CONF["encrypt"] z "md5crypt" na "dovecot:SHA512-CRYPT" . Pokud to neuděláte, pak se při pokusu o přihlášení do SOGo jako uživatel vytvořený v PostfixAdmin zobrazí chyba: nesprávné přihlašovací jméno nebo heslo.

Změna typu šifrování

Nyní, abyste úspěšně dokončili instalaci a neobdrželi chyby, musíte provést dotaz do databáze. Je vhodné to udělat přes PHPMyAdmin. Vyberte databázi vmail a přejděte na kartu SQL. V okně zadáme:

DROP INDEX doména na poštovní schránce;
DROP INDEX doména na alias;
ALTER TABLE alias ADD COLUMN `goto` text NOT NULL;

Databázový dotaz

A klikněte na „Vpřed“. Nyní jsme všichni připraveni, můžeme přejít do webového rozhraní PostfixAdmin a dokončit instalaci. Chcete-li to provést, musíte ve svém prohlížeči zadat: https://domain/postfixadmin/setup.php.

Mělo by se objevit následující:

Instalace PostfixAdmin

Pokud je vše provedeno podle pokynů, pak by neměly být žádné chyby. Pokud nějaké existují, pak je nutné je odstranit, jinak vám systém neumožní pokračovat. Nastavte instalační heslo a klikněte na „Vygenerovat hash hesla“. Systém vygeneruje hash hesla, který musí být vložen do parametru $CONF["setup_password"].

Dokončení instalace PostfixAdmin

Změna nastavení konfiguračního souboru

Nyní zadejte nově vytvořené heslo a vytvořte správce PostfixAdmin. Je lepší nevytvářet administrátora s přihlašovacím jménem postmaster, protože mohou nastat problémy s přihlášením do administračního panelu iRedAdmin.

Vytvoření správce PostfixAdmin

To je vše, správce byl vytvořen. Můžete se přihlásit.

Upozorňujeme, že z hlediska bezpečnosti je lepší přejmenovat nebo smazat soubor setup.php v adresáři postfixadmin.

Přejděte na: https://domain/postfixadmin/ a zadejte nově vytvořené přihlašovací údaje. V PostfixAdmin, stejně jako v iRedAdmin, je k dispozici ruský jazyk. Můžete jej vybrat při autorizaci.

Snažíme se vytvořit uživatelskou schránku.

Povolení/zakázání modulů iRedMail

iRedAPD je zodpovědný za správu modulů iRedMail. Má konfigurační soubor, ve kterém jsou registrovány pracovní moduly. Pokud konkrétní modul nepotřebujete, můžete jej odebrat z konfiguračního souboru a přestane fungovat. My ano:

# nano /opt/iredapd/settings.py

Najděte řádek „pluginy“ a odeberte z něj komponenty, které nepotřebujete. Odstraním komponentu „greylisting“. Před spamem samozřejmě chrání poměrně efektivně, ale potřebné dopisy často nedorazí.

Greylist je technologie automatické ochrany proti spamu založená na analýze chování serveru odesílatele pošty. Když je povolen „greylisting“, server poprvé odmítne přijmout dopis z neznámé adresy a hlásí dočasnou chybu. V tomto případě musí odesílající server odeslání zopakovat později. Spammerové programy to obvykle nedělají. Pokud je dopis odeslán znovu, je přidán do seznamu na 30 dní a poprvé dojde k výměně pošty. Sami se rozhodněte, zda tento modul využijete nebo ne.

Povolení/zakázání modulů pošty

Po provedení změn musíte restartovat iRedAPD.

# služba iredapd restart

Testování poštovního serveru

Tím je konfigurace poštovního serveru iRedMail dokončena. Můžete přejít do poslední fáze - testování. Vytvoříme dva poštovní schránky. Chcete-li zkontrolovat jeden přes iRedAdmin, druhý přes PostfixAdmin a poslat dopis z jedné poštovní schránky do druhé a naopak. V iRedAdmin vytvoříme poštovní schránku [email protected]. V PostfixAdmin - [email protected]

Vytvoření uživatele v iRedAdmin

Vytvoření uživatele v PostfixAdmin

Zkontrolujeme, že uživatelé byli vytvořeni.

Pokud budete věnovat pozornost sloupci „Komu“ v seznamu poštovních schránek PostfixAdmin, všimnete si rozdílu mezi poštovními schránkami vytvořenými v iRedAdmin a PostfixAdmin. Poštovní schránky vytvořené v iRedAdmin jsou označeny jako „Pouze přeposílat“ a schránky vytvořené v PostfixAdmin jsou označeny jako „Poštovní schránka“. Nejprve jsem dlouho nemohl pochopit, proč se to děje a jaký je mezi nimi rozdíl, a nakonec jsem si všiml jedné věci. Poštovní schránky v iRedAdmin jsou vytvořeny bez aliasů a poštovní schránky v PostfixAdmin jsou vytvořeny s vlastním aliasem.

A pokud jsou tyto aliasy smazány, pak se poštovní schránky zobrazí jako ty, které byly vytvořeny v iRedAdmin "Pouze přeposlat".

Odstranění aliasů

Aliasy byly odstraněny. Kontrola PostfixAdmin.

Jak můžete vidět, všechna pole se stala „Pouze vpřed“. Stejným způsobem, pokud si pro sebe vytvoříte alias v poštovní schránce vytvořené v iRedAdmin, stane se z ní „Schránka“. V zásadě to nijak neovlivňuje výkon pošty. Jediná věc je, že nebudete moci vytvořit alias na poštovní schránce vytvořené v PostfixAdmin. Místo vytvoření aliasu budete muset upravit existující. Když už mluvíme o aliasech, in nová verze iRedMail potřebuje provést změnu v jedné z map Postfixu, která zpracovává aliasy. A pokud to neuděláte, vytvořené aliasy nebudou fungovat. Chcete-li to provést, musíte v souboru /etc/postfix/mysql/virtual_alias_maps.cf opravit následující:

My ano:

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

A opravíme to.

Nastavení aliasů

Restartujte Postfix:

# restartování postfixu služby

Po tomto by mělo vše fungovat.

A tak začneme kontrolovat poštu. Přihlásíme se do schránky user1 přes Roundcube a do schránky user2 přes SOGo a odešleme dopis ze schránky user1 uživateli2 a zpět.

Odeslání e-mailu pomocí Roundcube

Přijetí dopisu v SOGo

Odeslání e-mailu na SOGo

Přijetí dopisu v Roundcube

Vše funguje bez problémů. Doručení dopisu trvá od dvou do pěti sekund. Stejně tak jsou dopisy perfektně doručovány na servery Yandex a mail.ru (testováno).

Nyní zkontrolujeme aliasy. Vytvoříme poštovní schránku uživatele3 a vytvoříme alias z poštovní schránky uživatel1 do poštovní schránky uživatel2. A odešleme dopis ze schránky uživatele3 do schránky uživatele1. V tomto případě by měl dopis dorazit do poštovní schránky uživatele2.

Vytvoření aliasu

Odeslání dopisu ze schránky uživatele 3 do schránky uživatele 1

Přijetí dopisu do poštovní schránky uživatele2

Práce aliasů je také v pořádku.

Vyzkoušíme fungování poštovního serveru přes místní poštovní klient. Příkladem je Mozilla Thunderbird. Vytvoříme další dva uživatele: klient1 a klient2. Jednu schránku propojíme přes IMAP, druhou přes POP3 a pošleme dopis z jedné schránky do druhé.

připojení IMAP

Připojení přes POP3

Zasíláme dopis od klienta 1 klientovi 2.

Odeslání od klienta 1

Potvrzení o klientovi 2

A v obráceném pořadí.

Odeslání od klienta 2

Potvrzení o klientovi 1

Všechno funguje.

Pokud přejdete na adresu: https://domain/netdata, můžete vidět grafy stavu systému.

Závěr

Tím je instalace, konfigurace a testování poštovního systému iRedMail dokončena. Díky tomu jsme dostali zcela zdarma plnohodnotný poštovní server s platným SSL certifikátem, dvěma různými webovými poštovními klienty, dvěma ovládacími panely a také antispamem a antivirem zabudovaným do pošty. Pokud chcete, můžete místo webových poštovních klientů použít lokální poštovní klienty jako např Microsoft Outlook nebo Mozilla Thunderbird. Pokud neplánujete používat webové poštovní klienty, nemůžete je vůbec nainstalovat, abyste nepřetížili server, nebo nainstalovat jednu věc, která se vám nejvíce líbí. Osobně se mi SOGo líbí více, protože jeho rozhraní je optimalizováno pro mobilní zařízení, takže je velmi pohodlné prohlížet e-mailem ze smartphonu. Totéž platí pro NetData a iRedAdmin, pokud je neplánujete používat, je lepší je neinstalovat. Tento poštovní systém není příliš náročný na zdroje. To vše funguje na VPS serveru s 1024 MB paměť s náhodným přístupem a jeden virtuální procesor. Pokud máte nějaké dotazy k tomuto poštovnímu systému, napište do komentářů.

P.S. Při testování tohoto produktu na různých operačních systémech s 1 GB RAM (Ubuntu, Debian, CentOS) se ukázalo, že 1 GB je pro ClamAV málo. Téměř ve všech případech při použití 1 GB paměti antivirus uvedl chybu související s databází. Zároveň na operačních systémech Debian a Ubuntu antivirus jednoduše nekontroloval poštu procházející serverem, jinak vše fungovalo dobře. Na CentOS byla situace poněkud odlišná. Služba clamd zcela zhroutila systém, čímž znemožnila normální provoz serveru. Při pokusu o přihlášení do webových rozhraní NGINX pravidelně produkoval 502 a 504 chyb. Pošta byla také odeslána pokaždé. Navíc, pokud přidáme až 2 GB RAM, pak ve všech případech nebyly žádné problémy s provozem antiviru a serveru jako celku. ClamAV naskenoval poštu procházející mailovým serverem, o které psala v protokolech. Při pokusu o odeslání viru jako přílohy bylo doručení zablokováno. Spotřeba paměti byla přibližně 1,2 – 1,7 GB.

Nginx je malý, velmi rychlý, poměrně funkční webový server a poštovní proxy server, vyvinutý Igorem Sysoevem (rambler.ru). Vzhledem k velmi nízké spotřebě systémových prostředků a provozní rychlosti, stejně jako flexibilitě konfigurace, web server Nginxčasto se používá jako frontend pro náročnější servery, jako je např Apache, v projektech s vysokou zátěží. Klasickou možností je kombinace, Nginx - Apache - FastCGI. Práce v takovém schématu, server Nginx, přijímá všechny požadavky přicházející přes HTTP a v závislosti na konfiguraci a samotném požadavku se rozhodne, zda požadavek zpracuje sám a dá klientovi připravenou odpověď, nebo pošle požadavek ke zpracování na některý z backendů ( Apache nebo FastCGI).

Jak víte, server Apache zpracovává každý požadavek v samostatném procesu (vlákně), který, nutno říci, spotřebovává poměrně malé množství systémových prostředků, pokud je takových procesů 10-20, je to nesmysl, a pokud existují 100-500 nebo více, systém přestane bavit.

Zkusme si představit podobnou situaci. Předpokládejme, že na Apache přijde 300 HTTP požadavky z klientů je 150 klientů na rychlých pronajatých linkách a dalších 150 na relativně pomalých internetových kanálech, i když ne na modemech. Co se v této situaci děje? A stane se následující: webový server Apache, aby zpracoval těchto 300 připojení, vytvoří pro každé proces (vlákno), rychle vygeneruje obsah a 150 rychlých klientů okamžitě převezme výsledek jejich požadavků, procesy, které jim slouží bude zabit a zdroje budou uvolněny a 150 je pomalých a bude dostávat výsledky svých požadavků pomalu, kvůli úzkému internetovému kanálu, v důsledku čehož 150 procesů bude v systému viset Apache, čeká, až si klienti vyzvednou obsah generovaný webovým serverem, a pohltí spoustu systémových zdrojů. Situace je přirozeně hypotetická, ale myslím, že podstata je jasná. Balíček pomáhá napravit výše popsanou situaci. Po přečtení celé žádosti od klienta ji předá ke zpracování Apache, který zase generuje obsah a co nejrychleji vrací připravenou odpověď Nginxu, načež může proces s klidným svědomím zabít a uvolnit systémové prostředky, které zabírá. Webový server Nginx, který přijímá výsledek požadavku Apache, zapisuje jej do vyrovnávací paměti nebo dokonce do souboru na disku a může jej poskytovat pomalým klientům na libovolně dlouhou dobu, zatímco jeho pracovní procesy spotřebovávají tak málo zdrojů, že .. „je dokonce legrační o tom mluvit“ ©. :) Toto schéma výrazně šetří systémové prostředky, opakuji, ale pracovní procesy Nginx spotřebovávají nepatrné množství zdrojů, to platí zejména pro velké projekty.

A to je jen malá část toho, co server Nginx umí; nezapomeňte na možnosti ukládání dat do mezipaměti a práce s memcached. Uvedu seznam hlavních funkčnost Webový server Nginx.

Funkce serveru Nginx jako HTTP server

• Léčba statický obsah, indexové soubory, výpisy adresářů, otevřená mezipaměť deskriptorů souborů;
• Zrychlené proxy s ukládáním do mezipaměti, rozložení zátěže a odolností proti chybám;
• Zrychlená podpora FastCGI servery s mezipamětí, rozložením zátěže a odolností proti chybám;
• Modulární struktura, podpora různých filtrů (SSI, XSLT, GZIP, resuming, chunked responses);
• Podpora SSL a TLS SNI rozšíření;
• Na základě IP nebo Na základě jména virtuální servery;
• Práce s KeepAlive a zřetězenými připojeními;
• Možnost konfigurovat libovolné časové limity a také počet a velikost vyrovnávacích pamětí na úrovni server Apache;
• Provádění různých akcí v závislosti na adrese klienta;
• Změna URI pomocí regulárních výrazů;
• Speciální chybové stránky pro 4xx a 5xx;
• Omezení přístupu na základě adresy klienta nebo hesla;
• Nastavení formátů souborů protokolu, rotace protokolů;
• Omezení rychlosti odezvy na klienta;
• Omezení počtu současných připojení a požadavků;
• Podporuje metody PUT, DELETE, MKCOL, COPY a MOVE;
• Změna nastavení a aktualizace serveru bez zastavení práce;
• Vestavěný Perl;

Funkce serveru Nginx jako poštovní proxy server

• Přeposílání na IMAP/POP3 backend pomocí externího HTTP autentizačního serveru;
• Kontrola uživatelského SMTP na externím HTTP server ověřování a předávání na interní server SMTP;
• Podporuje následující metody ověřování:
  • POP3 - USER/PASS, APOP, AUTH LOGIN/PLAIN/CRAM-MD5;
  • IMAP - PŘIHLÁŠENÍ, AUTHOVÁNÍ PŘIHLÁŠENÍ/PLAIN/CRAM-MD5;
  • SMTP - AUTH LOGI/ PLAIN/CRAM-MD5;
• podpora SSL;
• podpora STARTTLS a STLS;

Operační systémy a platformy podporované webovým serverem Nginx

• FreeBSD, od 3 do 8 - platformy, i386 a amd64;
• Linux, od 2.2 do 2.6 - platforma i386; Linux 2.6 – amd64;
• platformy Solaris 9 - i386 a sun4u; Platformy Solaris 10 - i386, amd64 a sun4v;
• platformy MacOS X ppc, i386;
• Windows XP, Windows Server 2003; (momentálně v beta testování)

Architektura a škálovatelnost serveru Nginx

• Hlavní (master) proces, několik (konfigurovaných v konfiguračním souboru) pracovních procesů běžících pod neprivilegovaným uživatelem;
• Podpora pro následující metody zpracování připojení:
  • select je standardní metoda. Odpovídající modul Nginx je sestaven automaticky, pokud není na dané platformě nalezena efektivnější metoda. Můžete vynutit povolení nebo zakázání sestavení daného modulu pomocí konfiguračních voleb --with-select_module nebo --without-select_module.
  • anketa je standardní metoda. Odpovídající modul Nginx je sestaven automaticky, pokud není na dané platformě nalezena efektivnější metoda. Můžete vynutit povolení nebo zakázání sestavení daného modulu pomocí konfiguračních voleb --with-poll_module nebo --without-poll_module.
  • kqueue - účinná metoda, používaný v operačních systémech FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0 a MacOS X. Při použití na dvouprocesorových strojích s MacOS X může způsobit paniku jádra.
  • epoll je efektivní metoda používaná v Linuxu 2.6+. Některé distribuce, jako je SuSE 8.2, mají záplaty na podporu epoll v jádře 2.4.
  • rtsig - signály v reálném čase, efektivní metoda používaná v Linuxu 2.2.19+. Ve výchozím nastavení nemůže být ve frontě více než 1024 signálů pro celý systém. Pro servery s vysokou zátěží to nestačí, velikost fronty je třeba zvýšit pomocí parametru jádra /proc/sys/kernel/rtsig-max. Od Linuxu 2.6.6-mm2 však tato možnost již není k dispozici, místo toho má každý proces samostatnou frontu signálu, jejíž velikost je určena pomocí RLIMIT_SIGPENDING.
  • Když je fronta plná, server nginx resetuje jej a zpracuje připojení pomocí metody dotazování, dokud se situace nevrátí k normálu.
  • /dev/poll je efektivní metoda podporovaná v operačních systémech Solaris 7 11/99+, HP/UX 11.22+ (eventport), IRIX 6.5.15+ a Tru64 UNIX 5.1A+.
  • eventport - porty událostí, efektivní metoda používaná v Solaris 10. Před použitím je třeba nainstalovat opravu, abyste se vyhnuli panice jádra.
• Použití funkcí metody kqueue, jako je EV_CLEAR, EV_DISABLE (pro dočasné zakázání události), NOTE_LOWAT, EV_EOF, počet dostupných dat, chybové kódy;
• Pracuje s sendfile (FreeBSD 3.1+, Linux 2.2.+, Mac OS X 10.5+), sendfile64 (Linux 2.4.21+) a sendfilev (Solaris 8 7/01+);
• Podpora akceptačních filtrů (FreeBSD 4.1+) a TCP_DEFER_ACCEPT (Linux 2.4+);
• 10 000 neaktivních udržovacích připojení HTTP spotřebuje přibližně 2,5 milionu paměti;
• Minimální počet operací kopírování dat;

NGINX lze použít nejen jako webový server nebo http-proxy, ale také pro proxy server přes protokoly SMTP, IMAP, POP3. To vám umožní nakonfigurovat:

• Jediný vstupní bod pro škálovatelný e-mailový systém.
• Vyrovnávání zátěže mezi všemi poštovními servery.

V tomto článku se instalace provádí na operačním sále. Linuxový systém. Jako poštovní službu, na kterou se zasílají požadavky, můžete použít postfix, exim, dovecot, exchange, iredmail Assembly a další.

Princip činnosti

NGINX přijímá požadavky a ověřuje se na webovém serveru. V závislosti na výsledku ověření přihlašovacího jména a hesla vrátí proxy odpověď s několika hlavičkami.

V případě úspěchu:

Server a port poštovního serveru tedy určíme na základě autentizace. To poskytuje mnoho příležitostí s odpovídající znalostí programovacích jazyků.

V případě selhání:

V závislosti na výsledku autentizace a hlavičce je klient přesměrován na poštovní server, který potřebujeme.

Příprava serveru

Udělejme nějaké změny v nastavení zabezpečení serveru.

SELinux

Zakažte SELinux, pokud používáme CentOS nebo pokud používáme tento systém zabezpečení na Ubuntu:

vi /etc/selinux/config

SELINUX=vypnuto

Firewall

Pokud používáme firewall (výchozí na CentOS):

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

firewall-cmd --reload

Pokud použijeme iptables (výchozí v Ubuntu):

iptables -A INPUT -p tcp --dport 25 -j PŘIJÍMAT

iptables -A INPUT -p tcp --dport 110 -j PŘIJÍMAT

iptables -A INPUT -p tcp --dport 143 -j PŘIJÍMAT

apt-get install iptables-persistent

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

* v tomto příkladu jsme povolili SMTP (25), POP3 (110), IMAP (143).

Instalace NGINX

Záleží na operační systém Instalace NGINX je trochu jiná.

nebo Linux Centos:

yum nainstalovat nginx

nebo Linux Ubuntu:

apt nainstalovat nginx

Umožňujeme automatické spuštění služby a její spuštění:

systemctl povolit nginx

systemctl spusťte nginx

Pokud je již NGINX v systému nainstalován, zkontrolujte, se kterými moduly pracuje:

Obdržíme seznam možností, se kterými je webový server postaven – mezi nimi bychom měli vidět --with-mail . Pokud tam požadovaný modul není, musíte aktualizovat nginx

Nastavení NGINX

Otevřete konfigurační soubor nginx a přidejte možnost pošty:

vi /etc/nginx/nginx.conf

pošta (

auth_http localhost:80/auth.php;

Server (
poslouchat 25;
protokol smtp;
smtp_auth přihlášení obyčejné cram-md5;
}

Server (
poslouchat 110;
protokol pop3;

}

Server (
poslouchat 143;
protokol imap;
}
}

* Kde:

• název_serveru je název poštovního serveru, který se zobrazí v pozdravu SMTP.
• auth_http - webový server a URL pro požadavek na ověření.
• proxy_pass_error_message - povolí nebo zakáže zobrazení zprávy, když se ověření nezdaří.
• listen - port, na kterém jsou požadavky naslouchány.
• protokol - aplikační protokol, pro který naslouchá odpovídající port.
• smtp_auth - dostupné metody ověřování pro SMTP.
• pop3_auth - dostupné metody ověřování pro POP3.

V sekci http - server přidejte:

Server (
listen 80 default_server;
poslouchat [::]:80 default_server;
...

Umístění ~ \.php$ (
nastavit $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;
zahrnout fastcgi_params;
fastcgi_param DOCUMENT_ROOT $root_path;
}
...

Restartujte server nginx:

systemctl restartujte nginx

Instalace a konfigurace PHP

Chcete-li provést autentizaci pomocí PHP, musíte do systému nainstalovat následující balíčky.

Pokud CentOS:

yum nainstalovat php php-fpm

Pokud Ubuntu:

apt-get install php php-fpm

Spusťte PHP-FPM:

systemctl povolit php-fpm

systemctl spusťte php-fpm

Autentizace

Ověření přihlášení a hesla se provádí skriptem, jehož cesta je určena volbou auth_http. V našem příkladu se jedná o PHP skript.

Příklad oficiální šablony pro skript pro ověření přihlašovacího jména a hesla:

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

* tento skript přijímá jakékoli přihlašovací jméno a heslo a přesměrovává požadavky na servery 192.168.1.22 a 192.168.1.33. Chcete-li nastavit ověřovací algoritmus, upravte řádky 61 - 64. Řádky 73 - 77 jsou zodpovědné za vrácení serverů, na které je přesměrování provedeno - v tomto příkladu, pokud přihlášení začíná znaky „a“, „c“, „f ”, “g”, pak bude přesměrování na server mailhost01, jinak na mailhost02. Mapování názvů serverů na IP adresy lze nastavit na řádcích 31, 32, jinak bude hovor uskutečněn pomocí názvu domény.

Nastavení poštovního serveru

Výměna dat mezi proxy NGINX a poštovním serverem probíhá v otevřený formulář. K výjimce je nutné přidat možnost autentizace pomocí mechanismu PLAIN. Chcete-li například nakonfigurovat dovecot, proveďte následující:

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

Přidejte řádky:

vzdálené 192.168.1.11 (
disable_plaintext_auth = ne
}

* v tomto příkladu jsme povolili požadavky na ověření PLAIN ze serveru 192.168.1.11.

Také kontrolujeme:

* pokud je ssl nastaveno na povinné , kontrola nebude fungovat, protože se ukáže, že na jedné straně server umožňuje požadavky v prostém textu, ale vyžaduje šifrování ssl.

Restartujte službu Dovecot:

systemctl restart dovecot

Nastavení klienta

Můžete pokračovat v kontrole nastavení proxy serveru. Chcete-li to provést, v nastavení klienta zadejte adresu nebo název serveru nginx jako IMAP/POP2/SMTP, například:

* v tomto příkladu je poštovní klient nakonfigurován pro připojení k serveru 192.168.1.11 přes otevřené porty 143 (IMAP) a 25 (SMTP).

Šifrování

Nyní nastavíme připojení SSL. Nginx musí být sestaven s modulem mail_ssl_module - zkontrolujte pomocí příkazu:

Pokud požadovaný modul chybí, přestavíme nginx.

Poté upravíme náš konfigurační soubor:

vi /etc/nginx/nginx.conf

pošta (
název_serveru mail.domena.místní;
auth_http localhost/auth.php;

Proxy_pass_error_message on;

Ssl zapnuto;
ssl_certificate /etc/ssl/nginx/public.crt;
ssl_certificate_key /etc/ssl/nginx/private.key;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;

Server (
poslouchat 110;
protokol pop3;
pop3_auth plain apop cram-md5;
}

Server (
poslouchat 143;
protokol imap;
}

Důvod: Spustil se bezpečnostní systém SELinux.

Řešení: vypněte nebo nakonfigurujte SELinux.

Nginx rychle získává na popularitě a mění se z pouhého statického akcelerátoru doručování pro Apache na plně funkční a vyvinutý webový server, který je stále více používán izolovaně. V tomto článku budeme hovořit o zajímavých a nestandardních scénářích pro používání nginx, které vám umožní vytěžit maximum z vašeho webového serveru.

Mail proxy

Začněme tím nejviditelnějším – schopností nginx fungovat jako poštovní proxy. Tato funkce je zpočátku přítomna v nginx, ale z nějakého důvodu se ve výrobě používá velmi zřídka; někteří lidé si její existenci ani neuvědomují. Ať je to jakkoli, nginx podporuje proxy protokoly POP3, IMAP a SMTP s různými metodami ověřování, včetně SSL a StartTLS, a dělá to velmi rychle.

Proč je to nutné? Tato funkce má minimálně dvě použití. Za prvé: použijte nginx jako štít proti otravným spammerům, kteří se snaží posílat nevyžádané e-maily přes náš server SMTP. Spammeři obvykle nevytvářejí mnoho problémů, protože jsou rychle odmítnuti ve fázi ověřování, ale když je jich opravdu hodně, nginx pomůže ušetřit zdroje procesoru. Za druhé: použijte nginx k přesměrování uživatelů na více poštovních serverů POP3/IMAP. Samozřejmě by to mohl zvládnout jiný poštovní proxy, ale proč ohradit servery, když je nginx již nainstalován na frontendu, aby obsluhoval statický obsah například přes HTTP?

Poštovní proxy server v nginx není zcela standardní. Využívá další vrstvu autentizace implementovanou pomocí HTTP a pouze pokud uživatel překročí tuto bariéru, je mu umožněno pokračovat dále. Tato funkcionalita je zajištěna vytvořením stránky/skriptu, na který nginx odešle uživatelská data a on/on vrátí odpověď ve formě standardního OK nebo důvodu odmítnutí (např. „Neplatné přihlašovací jméno nebo heslo“). Skript běží s následujícími hlavičkami:

Vstupní data ověřovacího skriptu HTTP_AUTH_USER: uživatel HTTP_AUTH_PASS: heslo HTTP_AUTH_PROTOCOL: poštovní protokol (IMAP, POP3 nebo SMTP)

A vrátí následující:

Výstup ověřovacího skriptu HTTP_AUTH_STATUS: OK nebo důvod selhání HTTP_AUTH_SERVER: skutečný poštovní server k přesměrování HTTP_AUTH_PORT: port serveru

Pozoruhodným rysem tohoto přístupu je, že jej nelze vůbec použít pro samotnou autentizaci, ale k rozptýlení uživatelů na různé interní servery v závislosti na uživatelském jménu, údajích o aktuální zátěži poštovních serverů nebo dokonce organizováním jednoduchého vyrovnávání zátěže. pomocí round-robin . Pokud však potřebujete pouze přenést uživatele na interní poštovní server, můžete místo skutečného skriptu použít stub implementovaný samotným nginx. Například nejjednodušší SMTP a IMAP proxy v konfiguraci nginx bude vypadat takto:

# vi /etc/nginx/nginx.conf mail ( # Adresa autentizačního skriptu auth_http localhost:8080/auth; # Vypněte příkaz XCLIENT, některé poštovní servery mu nerozumí xclient off; # Server serveru IMAP ( poslouchejte 143; protokol imap; proxy zapnuta; ) # server serveru SMTP (poslech 25; protokol smtp; proxy zapnuta; ) )

# vi /etc/nginx/nginx.conf http ( # Mapování na požadovaný port poštovního serveru v závislosti na portu odeslaném v mapě záhlaví HTTP_AUTH_PROTOCOL $http_auth_protocol $mailport (výchozí 25; smtp 25; imap 143; ) # Implementace autentizace „script“ - vždy vrátí OK a přenese uživatele na interní poštovní server, přičemž nastaví požadovaný port pomocí výše uvedeného mapovacího serveru ( listen 8080; umístění /auth ( add_header "Auth-Status" "OK"; add_header "Auth-Server" "192.168.0.1" ; add_header "Auth-Port" $mailport; return 200; ) ) )

To je vše. Tato konfigurace umožňuje transparentně přesměrovat uživatele na interní poštovní server bez vytváření režie ve formě skriptu, který je v tomto případě zbytečný. Pomocí skriptu lze tuto konfiguraci výrazně rozšířit: konfigurovat vyrovnávání zátěže, kontrolovat uživatele pomocí databáze LDAP a provádět další operace. Psaní skriptu je nad rámec tohoto článku, ale je velmi snadné jej implementovat i s pouze letmou znalostí PHP a Pythonu.

Živé vysílání videa

Je snadné nastavit běžný videohosting založený na nginx. Vše, co musíte udělat, je nahrát překódované video do adresáře přístupného serveru, zaregistrovat ho do konfigurace a nakonfigurovat přehrávač Flash nebo HTML5 tak, aby přebíral video z tohoto adresáře. Pokud však potřebujete nastavit nepřetržité vysílání videa z některých vnější zdroj nebo webovou kameru, toto schéma nebude fungovat a budete se muset poohlédnout po speciálních streamovacích protokolech.

Existuje několik protokolů, které tento problém řeší, nejúčinnějším a nejpodporovanějším z nich je RTMP. Jediným problémem je, že téměř všechny implementace serveru RTMP trpí problémy. Oficiální Adobe Flash Media Server je placený. Red5 a Wowza jsou napsány v Javě, a proto je neposkytují požadovaný výkon, Další implementace, Erlyvideo, je napsána v Erlangu, což je dobré pro nastavení clusteru, ale není tak efektivní pro jeden server.

Navrhuji jiný přístup - použijte modul RTMP pro nginx. Má vynikající výkon a také vám umožní používat jeden server pro obsluhu webového rozhraní webu i streamu videa. Jediný problém je, že tento modul je neoficiální, takže nginx s jeho podporou si budete muset postavit sami. Naštěstí se montáž provádí standardním způsobem:

$ sudo apt-get remove nginx $ cd /tmp $ wget http://bit.ly/VyK0lU -O nginx-rtmp.zip $ unzip 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

Nyní je potřeba modul nakonfigurovat. To se provádí jako obvykle prostřednictvím konfigurace nginx:

Rtmp ( # Aktivujte vysílací server na portu 1935 na adresovém webu/rtmp serveru ( poslech 1935; aplikace rtmp ( živě na; ) ) )

Modul RTMP nemůže pracovat ve vícevláknové konfiguraci, takže počet pracovních procesů nginx bude muset být snížen na jeden (později vám řeknu, jak tento problém obejít):

Pracovní_procesy 1;

Nyní můžete soubor uložit a přinutit nginx, aby znovu načetl konfiguraci. Nastavení nginx je dokončeno, ale ještě nemáme samotný video stream, takže ho musíme někde získat. Nechť je to například soubor video.avi z aktuálního adresáře. Abychom z něj udělali stream a zabalili jej do našeho vysílacího zařízení RTMP, použijeme starý dobrý FFmpeg:

# ffmpeg -re -i ~/video.avi -c copy -f flv rtmp://localhost/rtmp/stream

Pokud video soubor není ve formátu H264, musí být znovu zakódován. To lze provést za běhu pomocí stejného FFmpeg:

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

Stream lze také zachytit přímo z webové kamery:

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

Pro zobrazení streamu na straně klienta můžete použít jakýkoli přehrávač, který podporuje RTMP, například mplayer:

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

Nebo vložte přehrávač přímo na webovou stránku, kterou obsluhuje stejný nginx (příklad z oficiální dokumentace):

Nejjednodušší webový přehrávač RTMP

jwplayer("container").setup(( režimy: [( typ: "flash", src: "/jwplayer/player.swf", config: ( délka vyrovnávací paměti: 1, soubor: "stream", streamer: "rtmp:/) /localhost/rtmp", poskytovatel: "rtmp", ) )] ));

Jsou zde pouze dva důležité řádky: „file: „stream“ označující stream RTMP a „streamer: „rtmp://localhost/rtmp““, který označuje adresu streameru RTMP. Pro většinu úkolů bude takové nastavení zcela postačující. Můžete poslat několik různých streamů na jednu adresu a nginx je efektivně multiplexuje mezi klienty. To ale není vše, co modul RTMP umí. S jeho pomocí můžete například organizovat přenos video streamu z jiného serveru. Server FFmpeg k tomu vůbec není potřeba, stačí do konfigurace přidat následující řádky:

# vi /etc/nginx/nginx.conf aplikace rtmp ( live on; pull rtmp://rtmp.example.com; )

Pokud potřebujete vytvořit více streamů různé kvality, můžete zavolat transkodér FFmpeg přímo z nginx:

# vi /etc/nginx/nginx.conf aplikace rtmp ( žije dál; exec ffmpeg -i rtmp://localhost/rtmp/$name -c:v flv -c:a -s 320x240 -f flv rtmp://localhost /rtmp-320x240/$name; ) aplikace rtmp-320x240 ( aktivní dál; )

S touto konfigurací získáme hned dva broadcastery, z nichž jeden bude dostupný na adrese rtmp://site/rtmp a druhý, vysílající v kvalitě 320 x 240, na adrese rtmp://site/rtmp – 320 x 240. Dále můžete na stránku přidat flash přehrávač a tlačítka pro výběr kvality, která hráči poskytnou jednu nebo druhou adresu vysílatele.

A nakonec příklad vysílání hudby do sítě:

Zatímco pravda; do ffmpeg -re -i "`najít /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; Hotovo

Git proxy

Systém správy verzí Git je schopen poskytovat přístup k repozitářům nejen přes protokoly Git a SSH, ale také přes HTTP. Kdysi byla implementace HTTP přístupu primitivní a nedokázala zajistit plnohodnotnou práci s úložištěm. S verzí 1.6.6 se situace změnila a dnes lze pomocí tohoto protokolu obejít například omezení firewallu na obou stranách připojení nebo si vytvořit vlastní Git hosting s webovým rozhraním.

Oficiální dokumentace bohužel hovoří pouze o organizaci přístupu ke Gitu pomocí webového serveru Apache, ale protože samotná implementace je externí aplikace se standardním rozhraním CGI jej lze připojit téměř k jakémukoli jinému serveru, včetně lighttpd a samozřejmě nginx. To nevyžaduje nic kromě samotného serveru, nainstalovaného Gitu a malého FastCGI serveru fcgiwrap, který je potřeba, protože nginx neumí pracovat přímo s CGI, ale umí volat skripty pomocí protokolu FastCGI.

Celé schéma práce bude vypadat takto. Server fcgiwrap bude viset na pozadí a bude čekat na požadavek na spuštění aplikace CGI. Nginx bude zase nakonfigurován tak, aby požadoval provedení binárního CGI backendu git-http-backend prostřednictvím rozhraní FastCGI pokaždé, když se přistoupí na námi zadanou adresu. Po přijetí požadavku fcgiwrap spustí git-http-backend se zadanými argumenty CGI předanými klientem GIT a vrátí výsledek.

Chcete-li implementovat takové schéma, nejprve nainstalujte fcgiwrap:

$ sudo apt-get install fcgiwrap

Není potřeba jej konfigurovat, všechny parametry jsou přenášeny přes FastCGI protokol. Spustí se také automaticky. Zbývá tedy pouze nakonfigurovat nginx. Chcete-li to provést, vytvořte soubor /etc/nginx/sites-enabled/git (pokud takový adresář neexistuje, můžete zapisovat do hlavní konfigurace) a zapsat do něj následující:

# vi /etc/nginx/sites-enabled/git server ( # Visíme na portu 8080 listen 8080; # Adresa našeho serveru (nezapomeňte přidat záznam v DNS) server_name git.example.ru; # Logs access_log /var/log/nginx /git-http-backend.access.log; error_log /var/log/nginx/git-http-backend.error.log; # Primární adresa pro umístění anonymního přístupu / ( # Při pokusu o stažení, odeslat uživatele na soukromou adresu, pokud ($ arg_service ~* "git-receive-pack") ( přepište ^ /private$uri poslední; ) zahrňte /etc/nginx/fastcgi_params; # Adresa našeho git-http-backend fastcgi_param SCRIPT_FILENAME /usr/lib/git-core/git- http-backend; # Adresa úložiště Git fastcgi_param GIT_PROJECT_ROOT /srv/git; # Adresa souboru fastcgi_param PATH_INFO $uri; # adresa serveru fcgiwrap fastcgi_pass 127.0.0.1:9001; ) # Adresa pro přístup k zápisu umístění ~/private(/.* )$ ( # Uživatelská oprávnění auth_basic "git anonymní pouze pro čtení, ověřený zápis"; # Ověření HTTP založené na htpasswd auth_basic_user_file /etc/nginx/htpasswd; # Nastavení FastCGI zahrnuje /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; ))

Tato konfigurace předpokládá tři důležité věci:

Adresa úložiště bude /srv/git, nastavíme tedy příslušná přístupová práva: $ sudo chown -R www-data:www-data /srv/git

Samotné úložiště musí být otevřené pro čtení anonymním uživatelům a musí umožňovat nahrávání přes HTTP: $ cd /srv/git $ git config core.sharedrepository true $ git config http.receivepack true

Autentizace se provádí pomocí souboru htpasswd, musíte jej vytvořit a přidat do něj uživatele: $ sudo apt-get install apache2-utils $ htpasswd -c /etc/nginx/htpasswd user1 $ htpasswd /etc/nginx/htpasswd user2 . ..

To je vše, restartujte nginx:

Microcaching

Představme si situaci s dynamickým, často aktualizovaným webem, který najednou začne dostávat velmi velké zatížení (no, skončil na stránce jednoho z největších zpravodajských webů) a přestane zvládat návrat obsahu. Správná optimalizace a implementace správného schématu ukládání do mezipaměti bude trvat dlouho a problémy je třeba vyřešit hned. Co můžeme dělat?

Existuje několik způsobů, jak se z této situace dostat s co nejmenšími ztrátami, ale nejzajímavější nápad navrhl Fenn Bailey (fennb.com). Myšlenka je jednoduše umístit nginx před server a přinutit jej uložit do mezipaměti veškerý přenášený obsah, ale nejen mezipaměť, ale pouze na jednu sekundu. Zvrat je v tom, že stovky a tisíce návštěvníků webu za sekundu ve skutečnosti vygenerují pouze jeden požadavek na backend a obdrží stránku, která je většinou uložena v mezipaměti. Rozdíl si přitom sotva kdo všimne, protože i na dynamickém webu jedna vteřina většinou nic neznamená.

Konfigurace s implementací této myšlenky nebude vypadat tak složitě:

# vi /etc/nginx/sites-enabled/cache-proxy # Konfigurace mezipaměti proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=microcache:5m max_size=1000m; server ( listen 80; server_name example.com; # Umístění adresy v mezipaměti / ( # Mezipaměť je ve výchozím nastavení povolena $no_cache ""; # Zakázat mezipaměť pro všechny metody kromě GET a HEAD if ($request_method !~ ^(GET|HEAD) $) ( set $no_cache "1"; ) # Pokud klient nahraje obsah na stránku (no_cache = 1), zajistíme, aby data, která mu byla poskytnuta, nebyla uložena do mezipaměti po dobu dvou sekund a mohl vidět výsledek stahování 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"; ) # Povolit/zakázat mezipaměť v závislosti na stavu proměnné no_cache proxy_no_cache $no_cache; proxy_cache_bypass $no_cache; # Požadavky proxy na skutečný server proxy_pass http://appserver.example.ru; mikrocache proxy_cache proxy_cache_key $scheme$host$request_method$ request_uri, proxy_cache_valid 200 1s, # Ochrana před problémem stáda Thundering aktualizace proxy_cache_use_stale # Přidat standardní hlavičky proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # Neukládáme do mezipaměti soubory větší než 1 MB proxy_max_temp_file_size 1M; ))

Zvláštní místo v této konfiguraci zaujímá řádek „proxy_cache_use_stale update;“, bez kterého bychom dostávali periodické návaly zátěže na backend serveru kvůli požadavkům přijatým během aktualizace mezipaměti. Jinak je vše standardní a mělo by být jasné bez zbytečného vysvětlování.

Přiblížení proxy k cílovému publiku

Navzdory rozsáhlému globálnímu nárůstu rychlosti internetu stále hraje roli fyzická vzdálenost serveru od cílového publika. To znamená, že pokud ruský web běží na serveru umístěném někde v Americe, rychlost přístupu k němu bude a priori pomalejší než z ruského serveru se stejnou šířkou kanálu (samozřejmě, pokud zavřete oči před všemi ostatními faktory ). Další věcí je, že umístění serverů v zahraničí je často výnosnější, a to i z hlediska údržby. Proto, abyste získali zisk ve formě vyšších výplatních sazeb, budete muset použít některé triky.

Jedna z možných možností: umístit hlavní produktivní server na Západ a nasadit frontend, který není příliš náročný na zdroje a produkuje statická data v Rusku. To vám umožní získat rychlost bez vážných nákladů. Konfigurace nginx pro frontend bude v tomto případě jednoduchá a známá implementace proxy pro nás všechny:

# vi /etc/nginx/sites-enabled/proxy # Uložte mezipaměť na 30 dní na 100 GB úložiště proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=static:32m inactive=30d max_size=100g; server ( listen 80; server_name example.com; # Ve skutečnosti umístění našeho proxy ~* .(jpg|jpeg|gif|png|ico|css|midi|wav|bmp|js|swf|flv|avi|djvu|mp3) $ ( # Backend adresa 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;2 proxy_buffer_size 16k; 3 proxy_cache_valid 30d; proxy_ignore_headers "Cache-Control" "Platnost vyprší"; proxy_cache_key "$uri$is_args$args"; proxy_cache_lock zapnuto; ) )

závěry

Dnes můžete s pomocí nginx vyřešit mnoho různých problémů, z nichž mnohé vůbec nesouvisí s webovým serverem a protokolem HTTP. Mail proxy, streamovací server a rozhraní Git jsou jen některé z těchto úkolů.