Server di posta Nginx. Configurazione di NGINX per il proxy di posta

Segni di gravidanza dopo l'impianto dell'embrione

Questo articolo spiegherà come configurare NGINX Plus o NGINX Open Source come proxy per un server di posta o un servizio di posta esterno.

introduzione

NGINX può eseguire il proxy dei protocolli IMAP, POP3 e SMTP su uno dei server di posta upstream che ospitano gli account di posta e quindi può essere utilizzato come singolo endpoint per i client di posta elettronica. Ciò può comportare una serie di vantaggi, come ad esempio:

  • scalare facilmente il numero di server di posta
  • scegliere un server di posta in base a regole diverse, ad esempio scegliere il server più vicino in base all'indirizzo IP di un client
  • distribuzione del carico tra i server di posta
Prerequisiti

    NGINX Plus (include già i moduli Mail necessari per proxy il traffico email) o NGINX Open Source hanno compilato i moduli Mail utilizzando il parametro --with-mail per la funzionalità proxy email e il parametro --with-mail_ssl_module per il supporto SSL/TLS:

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

    Server di posta IMAP, POP3 e/o SMTP o un servizio di posta esterno

Configurazione dei server proxy di posta SMTP/IMAP/POP3

Nel file di configurazione NGINX:

posta (#...)

posta (nome_server mail.esempio.com; #...)

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

In alternativa, specificare se informare un utente sugli errori dal server di autenticazione specificando la direttiva proxy_pass_error_message. Questo può essere utile quando una casella di posta esaurisce la memoria:

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

Configura ciascun server SMTP, IMAP o POP3 con i blocchi server. Per ciascun server, specificare:

  • IL numero di porta che corrispondono al protocollo specificato con la direttiva listen
  • IL protocollo con la direttiva protocollo (se non specificato, verrà rilevato automaticamente dalla porta specificata nella direttiva di ascolto)
  • consentito metodi di autenticazione con le direttive imap_auth , pop3_auth e smtp_auth:

server (ascolta 25; protocollo smtp; smtp_auth login plain cram-md5;) server (ascolta 110; protocollo pop3; pop3_auth plain apop cram-md5;) server (ascolta 143; protocollo imap;)

Configurazione dell'autenticazione per un proxy di posta

Ogni richiesta POP3/IMAP/SMTP proveniente dal client verrà prima autenticata su un server di autenticazione HTTP esterno o tramite uno script di autenticazione. Disporre di un server di autenticazione è obbligatorio per il proxy del server di posta NGINX. Il server può essere creato da solo secondo il protocollo di autenticazione NGINX che si basa sul protocollo HTTP.

Se l'autenticazione ha esito positivo, il server di autenticazione sceglierà un server upstream e reindirizzerà la richiesta. In questo caso la risposta del server conterrà le seguenti righe:

HTTP/1.0 200 OK Auth-Status: OK Auth-Server: # il nome del server o l'indirizzo IP del server upstream che verrà utilizzato per l'elaborazione della posta Auth-Port: # la porta del server upstream

Se l'autenticazione fallisce, il server di autenticazione restituirà un messaggio di errore. In questo caso la risposta del server conterrà le seguenti righe:

HTTP/1.0 200 OK Auth-Status: # un messaggio di errore da restituire al client, ad esempio “Login o password non validi” Auth-Wait: # il numero di tentativi di autenticazione rimanenti fino alla chiusura della connessione

Tieni presente che in entrambi i casi la risposta conterrà HTTP/1.0 200 OK il che potrebbe creare confusione.

Per ulteriori esempi di richieste e risposte dal server di autenticazione, consultare ngx_mail_auth_http_module nella documentazione di riferimento NGINX.

Configurazione di SSL/TLS per un proxy di posta

Utilizzando POP3/SMTP/IMAP su SSL/TLS ti assicuri che i dati trasmessi tra un client e un server di posta siano protetti.

Per abilitare SSL/TLS per il proxy di posta:

Assicurati che NGINX sia configurato con il supporto SSL/TLS digitando il comando nginx -V nella riga di comando e quindi cercando la riga with --mail_ssl_module nell'output:

$ nginx -V configura argomenti: ... with--mail_ssl_module

Assicurati di aver ottenuto i certificati del server e una chiave privata e di inserirli nel server. Un certificato può essere ottenuto da un'autorità di certificazione (CA) attendibile o generato utilizzando una libreria SSL come OpenSSL.

SSL attivo;

inizia;

Aggiungi certificati SSL: specifica il percorso dei certificati (che devono essere in formato PEM) con la direttiva ssl_certificate e specifica il percorso della chiave privata nella direttiva ssl_certificate_key:

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

Puoi utilizzare solo versioni e cifrature complesse di SSL/TLS con le direttive ssl_protocols e ssl_ciphers oppure puoi impostare i tuoi protocolli e cifrature preferibili:

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

Ottimizzazione SSL/TLS per proxy di posta

Questi suggerimenti ti aiuteranno a rendere il tuo proxy di posta NGINX più veloce e sicuro:

Imposta il numero di processi di lavoro uguale al numero di processori con la direttiva lavoratore_processes impostata sullo stesso livello del contesto di posta:

processi_operaio automatico; posta (#...)

Abilita la cache della sessione condivisa e disabilita la cache della sessione integrata con l'auto ; mail ( nome_server mail.example.com ; auth_http host locale : 9000 /cgi-bin/nginxauth.cgi ; proxy_pass_error_message attivo ; ssl attivo ; ssl_certificate /etc/ssl/certs/server.crt ; ssl_certificate_key /etc/ssl/certs/server. key ; ssl_protocols TLSv1 TLSv1.1 TLSv1.2 ; ssl_ciphers HIGH:!aNULL:!MD5 ; ssl_session_cache shared:SSL:10m ; ssl_session_timeout 10m ; server ( ascolta 25 ; protocollo smtp ; smtp_auth login plain cram-md5 ; ) server ( ascolta 1 10; protocollo pop3; pop3_auth plain apop cram-md5;) server (ascolta 143; protocollo imap;))

In questo esempio sono presenti tre server proxy di posta elettronica: SMTP, POP3 e IMAP. Ciascuno dei server è configurato con il supporto SSL e STARTTLS. I parametri della sessione SSL verranno memorizzati nella cache.

Il server proxy utilizza il server di autenticazione HTTP: la sua configurazione va oltre lo scopo di questo articolo. Tutti i messaggi di errore dal server verranno restituiti ai client.

iRedMail lo è montaggio pronto server di posta con aperto codice sorgente. L'assemblaggio si basa sul server SMTP Postfix (Mail Transfer Agent, abbreviato in MTA). L'insieme comprende anche: Dovecot, SpamAssassin, Greylist, ClamAV, SOGo Roundcube, NetData e NGINX.

Dovecot: server IMAP/POP3.

Spamassassin è uno strumento di filtraggio dello spam.

Greylist è uno strumento anti-spam basato su greylist.

ClamAV è un antivirus.

Roundcube e SOGo sono client Web per lavorare con la posta elettronica.

NetData è un programma di monitoraggio del server in tempo reale.

Nginx è un server web.

Supporta i sistemi operativi: CentOS 7, Debian 9, Ubuntu 16.04/18.04, FreeBSD 11/12 e OpenBSD 6.4.

iRedMail ha versioni a pagamento e gratuite, che differiscono l'una dall'altra per la funzionalità della propria interfaccia web dell'assembly di posta iRedAdmin. IN versione gratuita Puoi creare solo domini, caselle di posta utente e amministratore. Se hai bisogno di creare un alias, non potrai più farlo nella versione gratuita tramite iRedAdmin. Fortunatamente esiste una soluzione gratuita chiamata PostfixAdmin che ti consente di farlo. PostfixAdmin si integra facilmente in iRedMail e funziona benissimo con esso.

Installazione

Per l'installazione avremo bisogno di uno dei sistemi operativi sopra elencati. Utilizzerò Ubuntu Server 18.04. Devi anche aver acquistato Nome del dominio e zona DNS configurata. Se stai usando Server DNS il tuo registrar di domini, allora devi inserire due voci nella sezione di gestione della zona del dominio: A e MX. Puoi anche utilizzare il tuo DNS configurando la delega in account personale il registrar del tuo nome di dominio.

Configurazione di una zona di dominio quando si utilizza un registrar DNS

Nota! Orario di ingresso Impostazioni DNS durata da alcune ore a una settimana. Fino a quando le impostazioni non avranno effetto, il server di posta non funzionerà correttamente.

Per installarlo, scaricalo dal sito web iRedMail Versione attuale. Attualmente è 0.9.9.

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

Quindi decomprimere l'archivio scaricato.

# tar xjf iRedMail-0.9.9.tar.bz2

Disimballaggio dell'archivio

E vai alla cartella creata.

# cd iRedMail-0.9.9

Cartella di installazione di iRedMail

Controllo del contenuto della cartella

Contenuto della cartella

Ed esegui lo script di installazione di iRedMail.

# bash iRedMail.sh

Verrà avviata l'installazione del sistema di posta. Durante il processo di installazione dovrai rispondere a una serie di domande. Accettiamo di iniziare l'installazione.

Avvia l'installazione

Selezione della directory di installazione

Ora devi selezionare un server web. Non c’è molta scelta, quindi scegliamo NGINX.

Selezione di un server Web

Ora devi selezionare un server database che verrà installato e configurato per funzionare con il sistema di posta. Seleziona MariaDB.

Selezione di un server di database

Imposta la password di root per il database.

Creazione di una password root del database

Adesso indichiamo il nostro dominio email.

Creazione di un dominio di posta

Quindi creiamo una password per la casella di posta dell'amministratore [email protected].

Creazione di una password di amministratore di posta

Selezione dei componenti Web

Conferma le impostazioni specificate.

Conferma delle impostazioni

L'installazione è iniziata.

Installazione

Una volta completata l'installazione, conferma la creazione della regola iptables per SSH e riavvia il firewall. iRedMail funziona con iptables. In Ubuntu, l'utilità di gestione del firewall più comunemente utilizzata è UFW. Se per un motivo o per l'altro hai questa necessità, installa UFW (apt install ufw) e aggiungi regole in modo che UFW (esempio: ufw consenta "Nginx Full" o ufw consenta Postfix) non blocchi il funzionamento del server di posta. Puoi visualizzare l'elenco delle regole disponibili eseguendo il comando: ufw app list . Quindi abilita UFW: ufw abilita.

Creazione di una regola iptables

Riavvio del firewall

Questo completa l'installazione di iRedMail. Il sistema ci ha fornito indirizzi di interfaccia web e credenziali di accesso. Per abilitare tutti i componenti del sistema di posta, è necessario riavviare il server.

Completamento dell'installazione

Riavviamo.

# riavviare

Impostazioni

Per prima cosa devi assicurarti che tutto funzioni. Proviamo ad accedere al pannello di controllo di iReadAdmin su https://domain/iredadmin. Accedi a [email protected], password creata durante l'installazione. C'è un'interfaccia in lingua russa.

Come puoi vedere, funziona tutto. Quando accedi a iRedAdmin, molto probabilmente hai ricevuto un errore di sicurezza relativo al certificato. Ciò accade perché iRedMail ha un certificato autofirmato integrato, di cui il browser si lamenta. Per risolvere questo problema, è necessario installare un certificato SSL valido. Se ne hai uno acquistato, puoi installarlo. Nell'esempio installerò SSL gratuito da Let's Encrypt.

Installazione di un certificato Let's Encrypt SSL

Installeremo il certificato utilizzando l'utilità certbot. Innanzitutto, aggiungiamo un repository.

# aggiungi-apt-repository ppa:certbot/certbot

Quindi installeremo il certboot stesso con i componenti necessari.

# apt installa python-certbot-nginx

Riceviamo un certificato.

# certbot --nginx -d dominio.ru

Dopo aver eseguito il comando, il sistema ti chiederà di inserire il tuo indirizzo email, inserisci. Successivamente molto probabilmente riceverai un errore che indica che non è possibile trovare il blocco del server per il quale è stato generato il certificato. In questo caso è normale, poiché non abbiamo alcun blocco del server. La cosa principale per noi è ottenere un certificato.

Ottenere un certificato

Come possiamo vedere, il certificato è stato ricevuto con successo e il sistema ci ha mostrato i percorsi del certificato stesso e della chiave. Sono esattamente ciò di cui abbiamo bisogno. In generale, abbiamo ricevuto 4 file che verranno archiviati nella cartella "/etc/letsencrypt/live/domain". Ora dobbiamo informare il server web del nostro certificato, ovvero sostituire il certificato incorporato con quello appena ricevuto. Per fare ciò, dobbiamo modificare un solo file.

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

E cambiamo le ultime due righe in esso.

Sostituzione del certificato SSL

Modifichiamo i percorsi nel file con i percorsi che il sistema ci ha comunicato al momento della ricezione del certificato.

Sostituzione di un certificato SSL

E riavvia NGINX.

# riavvio del servizio nginx

Ora proviamo ad accedere nuovamente a iRedAdmin.

Verifica del certificato SSL

Non ci sono più errori di certificato. Il certificato è valido. Puoi fare clic sul lucchetto e visualizzarne le proprietà. Quando il certificato scade, certboot dovrebbe rinnovarlo automaticamente.

Ora parleremo del certificato Dovecot e Postfix. Per fare ciò, modificheremo due file di configurazione. Noi facciamo:

# nano /etc/dovecot/dovecot.conf

Trovare il blocco:

#SSL: impostazioni globali.

E cambiamo il certificato registrato lì con il nostro.

Certificato sostitutivo per Dovecot

Prestare attenzione anche alla riga "ssl_protocols". Il suo valore deve essere "!SSLv3", altrimenti riceverai l'errore "Attenzione: SSLv2 non supportato da OpenSSL. Considera la possibilità di rimuoverlo da ssl_protocols" al riavvio di Dovecot.

# nano /etc/postfix/main.cf

Trovare il blocco:

# Chiave SSL, certificato, CA

E cambiamo i percorsi al suo interno nel percorso dei file del nostro certificato.

Sostituzione di un certificato per Postfix

Questo completa l'installazione del certificato. È necessario riavviare Dovecot e Postfix, ma è meglio riavviare il server.

#riavvio del servizio colombaia

# riavviare

Installazione di PHPMyAdmin

Questo passaggio è facoltativo, ma consiglio di eseguirlo e di installare PHPMyAdmin per lavorare facilmente con i database.

# apt installa phpmyadmin

Il programma di installazione chiederà con quale server web configurare PHPMyAdmin per lavorare, poiché NGINX non è in questo elenco, basta premere TAB e andare avanti.

Installazione di PHPMyAdmin

Una volta completata l'installazione, affinché phpmyadmin funzioni, è necessario creare un collegamento simbolico alla directory con cui NGINX funziona per impostazione predefinita.

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

E proviamo ad andare su https://domain/phpmyadmin/

PHPMyAdmin è in esecuzione. La connessione è protetta da certificato, non sono presenti errori. Andare avanti. Creiamo un amministratore del database MySQL (MariaDB).

#mysql

E arriviamo alla console di gestione di MariaDB. Successivamente, eseguiamo i comandi uno per uno:

MariaDB > CREA UTENTE "admin"@"localhost" IDENTIFICATO DA "password";
MariaDB > CONCEDI TUTTI I PRIVILEGI SU *.* A "admin"@"localhost" CON L'OPZIONE DI CONCESSIONE;
MariaDB > PRIVILEGI FLUSH;

Creazione di un utente MySQL

Tutto ok, login completato. PHPMyAdmin è pronto.

Installazione di PostfixAdmin

In linea di principio, PostfixAdmin, come PHPMyAdmin, non ha bisogno di essere installato. Il server di posta funzionerà correttamente senza questi componenti. Ma in questo caso non sarai in grado di creare alias di posta. Se non ne hai bisogno, puoi tranquillamente saltare queste sezioni. Se hai ancora bisogno di alias, hai due opzioni: acquistare la versione a pagamento di iReaAdmin o installare PostfixAdmin. Certo, puoi farlo senza software aggiuntivo, registrando manualmente gli alias nel database, ma questo non è sempre conveniente e non è adatto a tutti. Consiglio di utilizzare PostfixAdmin; ora ne esamineremo l'installazione e l'integrazione con iRedMail. Iniziamo l'installazione:

# apt installa postfixadmin

Accettiamo e creiamo una password per il database di sistema del programma.

Installazione di PostfixAdmin

Installazione di PostfixAdmin

Creiamo un collegamento simbolico allo stesso modo dell'installazione di PHPMyAdmin.

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

Rendiamo proprietario della directory l'utente per conto del quale viene avviato il server web. Nel nostro caso, NGINX viene lanciato come utente www-data.

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

Ora dobbiamo modificare il file di configurazione PostfixAdmin e aggiungere informazioni sul database utilizzato da iRedAdmin. Per impostazione predefinita questo database si chiama vmail. Se vai su PHPMyAdmin puoi vederlo lì. Pertanto, affinché PostfixAdmin possa apportare modifiche al database, lo registriamo nella configurazione di PostfixAdmin.

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

Troviamo le righe:

$CONF["tipo_database"] = $tipodb;
$CONF["host_database"] = $dbserver;
$CONF["utente_database"] = $dbuser;
$CONF["password_database"] = $dbpass;
$CONF["nome_database"] = $nomedb;

E ricordiamolo:

$CONF["tipo_database"] = "mysqli"; # Tipo di database
$CONF["database_host"] = "localhost"; # Host del server di database
$CONF["utente_database"] = "amministratore"; # Accedi con i diritti per scrivere nel database vmail. È possibile utilizzare l'amministratore creato in precedenza
$CONF["database_password"] = "password"; # Password per l'utente specificato sopra
$CONF["nome_database"] = "vmail"; # Nome del database iRedMail

Immissione delle informazioni sul database

Se prevedi di utilizzare il client di posta web SOGo, devi eseguire un ulteriore passaggio aggiuntivo, ovvero modificare la crittografia PostfixAdmin nell'elemento $CONF["encrypt"] da "md5crypt" a "dovecot:SHA512-CRYPT" . In caso contrario, quando provi ad accedere a SOGo come utente creato in PostfixAdmin, riceverai un errore: login o password errati.

Modifica del tipo di crittografia

Ora, per poter completare con successo l'installazione e non ricevere errori, è necessario eseguire una query sul database. È conveniente farlo tramite PHPMyAdmin. Seleziona il database vmail e vai alla scheda SQL. Nella finestra inseriamo:

Dominio DROP INDEX sulla casella di posta;
Dominio DROP INDEX su alias;
ALTER TABLE alias ADD COLUMN `goto` testo NOT NULL;

Interrogazione della banca dati

E fare clic su "Avanti". Ora che siamo tutti pronti, possiamo andare all'interfaccia web di PostfixAdmin e completare l'installazione. Per fare ciò, devi digitare nel tuo browser: https://domain/postfixadmin/setup.php.

Dovrebbe apparire quanto segue:

Installazione di PostfixAdmin

Se tutto viene eseguito secondo le istruzioni, non dovrebbero esserci errori. Se ce ne sono, devono essere eliminati, altrimenti il ​​sistema non ti consentirà di continuare. Impostare la password di installazione e fare clic su "Genera hash password". Il sistema genererà un hash della password, che dovrà essere inserito nel parametro $CONF["setup_password"].

Completamento dell'installazione di PostfixAdmin

Modifica delle impostazioni del file di configurazione

Ora inserisci la password appena creata e crea l'amministratore PostfixAdmin. È meglio non creare un amministratore con il login postmaster, poiché potrebbero esserci problemi nell'accedere al pannello di amministrazione di iRedAdmin.

Creazione di un amministratore PostfixAdmin

Questo è tutto, l'amministratore è stato creato. Puoi accedere.

Tieni presente che dal punto di vista della sicurezza è meglio rinominare o eliminare il file setup.php nella directory postfixadmin.

Vai su: https://domain/postfixadmin/ e inserisci le credenziali appena create. In PostfixAdmin, così come in iRedAdmin, è disponibile la lingua russa. Puoi selezionarlo durante l'autorizzazione.

Stiamo provando a creare una casella di posta utente.

Abilitare/Disabilitare i moduli iRedMail

iRedAPD è responsabile della gestione dei moduli iRedMail. Ha un file di configurazione in cui sono registrati i moduli funzionanti. Se non hai bisogno di un modulo particolare, puoi rimuoverlo dal file di configurazione e smetterà di funzionare. Noi facciamo:

# nano /opt/iredapd/settings.py

Trova la riga "plugin" e rimuovi da essa i componenti che non ti servono. Rimuoverò il componente "greylisting". Naturalmente protegge dallo spam in modo abbastanza efficace, ma spesso le lettere necessarie non arrivano.

Greylist è una tecnologia di protezione automatica dallo spam basata sull'analisi del comportamento del server del mittente della posta. Quando il "greylisting" è abilitato, il server rifiuta di accettare per la prima volta una lettera da un indirizzo sconosciuto, segnalando un errore temporaneo. In questo caso il server mittente dovrà ripetere l'invio successivamente. I programmi spammer di solito non lo fanno. Se la lettera viene inviata nuovamente, viene aggiunta all'elenco per 30 giorni e lo scambio di posta avviene una prima volta. Decidi tu stesso se utilizzare questo modulo o meno.

Abilitazione/disabilitazione dei moduli di posta

Dopo aver apportato le modifiche, è necessario riavviare iRedAPD.

# riavvio del servizio iredapd

Testare il server di posta

Questo completa la configurazione del server di posta iRedMail. Puoi procedere alla fase finale: il test. Creiamone due cassette postali. Controllarne uno tramite iRedAdmin, il secondo tramite PostfixAdmin e inviare una lettera da una casella di posta all'altra e viceversa. In iRedAdmin creeremo una casella di posta [email protected]. In PostfixAdmin - [email protected]

Creazione di un utente in iRedAdmin

Creazione di un utente in PostfixAdmin

Controlliamo che gli utenti siano stati creati.

Se presti attenzione alla colonna "A" nell'elenco delle caselle di posta PostfixAdmin, noterai la differenza tra le caselle di posta create in iRedAdmin e PostfixAdmin. Le caselle di posta create in iRedAdmin sono contrassegnate come "Solo inoltro" e quelle create in PostfixAdmin sono contrassegnate come "Cassetta postale". All’inizio non sono riuscito a capire per molto tempo perché ciò stesse accadendo e quale fosse la differenza tra loro, e alla fine ho notato una cosa. Le caselle di posta in iRedAdmin vengono create senza alias e le caselle di posta in PostfixAdmin vengono create con un alias proprio.

E se questi alias vengono eliminati, le caselle di posta verranno visualizzate come quelle create in iRedAdmin "Solo inoltro".

Rimozione degli alias

Gli alias sono stati rimossi. Controllo PostfixAdmin.

Come puoi vedere, tutte le caselle sono diventate “Solo avanti”. Allo stesso modo, se crei un alias per te stesso in una casella di posta creata in iRedAdmin, diventerà “Mailbox”. In linea di principio, ciò non influisce in alcun modo sulla prestazione della posta. L'unica cosa è che non sarai in grado di creare un alias su una casella di posta creata in PostfixAdmin. Invece di creare un alias, dovrai modificarne uno esistente. A proposito di alias, in nuova versione iRedMail deve apportare una modifica a una delle mappe Postfix che gestisce gli alias. E se non lo fai, gli alias creati non funzioneranno. Per fare ciò, è necessario correggere quanto segue nel file /etc/postfix/mysql/virtual_alias_maps.cf:

Noi facciamo:

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

E lo sistemiamo.

Impostazione degli alias

Riavvia Postfix:

# riavvio del suffisso del servizio

Dopodiché tutto dovrebbe funzionare.

E quindi, iniziamo a controllare la posta. Accederemo alla casella di posta dell'utente1 tramite Roundcube e alla casella di posta dell'utente2 tramite SOGo e invieremo una lettera dalla casella di posta dell'utente1 all'utente2 e viceversa.

Invio di un'e-mail con Roundcube

Ricevere una lettera in SOGo

Invio di un'e-mail a SOGo

Ricevere una lettera in Roundcube

Tutto funziona senza problemi. La consegna della lettera richiede da due a cinque secondi. Allo stesso modo, le lettere vengono consegnate perfettamente ai server Yandex e mail.ru (testati).

Ora controlliamo gli alias. Creiamo una casella di posta utente3 e creiamo un alias dalla casella di posta utente1 a quella di utente2. E invieremo una lettera dalla casella di posta dell'utente3 alla casella di posta dell'utente1. In questo caso, la lettera dovrebbe arrivare alla casella di posta dell'utente2.

Creazione di un alias

Invio di una lettera dalla casella di posta dell'utente3 alla casella di posta dell'utente1

Ricezione di una lettera sulla casella di posta dell'utente2

Va bene anche il lavoro degli alias.

Testiamo il funzionamento del server di posta via locale client di posta. Ad esempio, considera Mozilla Thunderbird. Creiamo altri due utenti: client1 e client2. Collegheremo una casella di posta tramite IMAP, l'altra tramite POP3 e invieremo una lettera da una casella di posta all'altra.

Connessione IMAP

Connessione tramite POP3

Inviamo una lettera dal Cliente 1 al Cliente 2.

Invio dal cliente 1

Ricevuta sul cliente 2

E in ordine inverso.

Invio dal cliente 2

Ricevuta sul cliente 1

Tutto funziona.

Se vai all'indirizzo: https://domain/netdata, puoi vedere i grafici dello stato del sistema.

Conclusione

Questo completa l'installazione, la configurazione e il test del sistema di posta iRedMail. Di conseguenza, abbiamo ricevuto un server di posta completamente gratuito e completo con un certificato SSL valido, due diversi client di posta web, due pannelli di controllo, nonché un antispam e un antivirus integrati nella posta. Se lo desideri, invece dei client di posta web, puoi utilizzare client di posta locali come Microsoft Outlook o Mozilla Thunderbird. Se non prevedi di utilizzare client di posta web, non puoi installarli affatto, per non sovraccaricare il server, oppure installare qualcosa che ti piace di più. Personalmente preferisco SOGo perché la sua interfaccia è ottimizzata dispositivi mobili, rendendolo molto comodo da visualizzare e-mail da uno smartphone. Lo stesso vale per NetData e iRedAdmin, se non prevedi di utilizzarlo è meglio non installarlo. Questo sistema di posta non richiede molto risorse. Tutto questo funziona su un server VPS con 1024 MB memoria ad accesso casuale e un processore virtuale. Se hai domande su questo sistema di posta, scrivi nei commenti.

PS Durante il test di questo prodotto su vari sistemi operativi con 1 GB di RAM (Ubuntu, Debian, CentOS), si è scoperto che 1 GB non è sufficiente per far funzionare ClamAV. In quasi tutti i casi, quando si utilizza 1 GB di memoria, l'antivirus ha segnalato un errore relativo al database. Allo stesso tempo, sui sistemi operativi Debian e Ubuntu, l'antivirus semplicemente non ha scansionato la posta che passava attraverso il server, altrimenti tutto ha funzionato bene. Su CentOS la situazione era leggermente diversa. Il servizio clamd ha bloccato completamente il sistema, rendendo impossibile il normale funzionamento del server. Durante il tentativo di accedere alle interfacce web, NGINX produceva periodicamente errori 502 e 504. La posta veniva inviata anche ogni due volte. Inoltre, se aggiungiamo fino a 2 GB di RAM, in tutti i casi non si sono verificati problemi con il funzionamento dell'antivirus e del server nel suo complesso. ClamAV ha scansionato la posta che passava attraverso il server di posta, di cui ha scritto nei registri. Durante il tentativo di inviare un virus come allegato, la consegna è stata bloccata. Il consumo di memoria è stato di circa 1,2 - 1,7 GB.

Nginx è un server web e proxy di posta piccolo, molto veloce e abbastanza funzionale, sviluppato da Igor Sysoev (rambler.ru). Grazie al consumo molto basso di risorse di sistema e velocità operativa, nonché alla flessibilità di configurazione, web Server Nginx spesso utilizzato come frontend per server più pesanti, come ad esempio Apache, in progetti ad alto carico. L'opzione classica è la combinazione Nginx - Apache - FastCGI. Lavorando in un tale schema, Server Nginx, accetta tutte le richieste provenienti tramite HTTP e, a seconda della configurazione e della richiesta stessa, decide se elaborare la richiesta stessa e fornire al client una risposta pronta o inviare la richiesta per l'elaborazione a uno dei backend ( Apache O CGI veloce).

Come sapete, il server Apache elabora ogni richiesta in un processo separato (thread), che, va detto, consuma una quantità piuttosto piccola di risorse di sistema, se ci sono 10-20 processi di questo tipo, non ha senso e se ci sono 100-500 o più, il sistema diventa non divertente.

Proviamo a immaginare una situazione simile. Supponiamo Apache arriva a 300 Richieste HTTP dai client, 150 client sono su linee affittate veloci e gli altri 150 su canali Internet relativamente lenti, anche se non su modem. Cosa sta succedendo in questa situazione? E accade quanto segue: il server web Apache, per elaborare queste 300 connessioni, crea per ognuna un processo (thread), genererà rapidamente il contenuto e 150 client veloci prenderanno immediatamente il risultato delle loro richieste, i processi che li servono verranno uccisi e le risorse verranno rilasciate, e 150 sono lente e riceveranno i risultati delle loro richieste lentamente, a causa dello stretto canale Internet, a seguito del quale 150 processi si bloccheranno nel sistema Apache, aspettando che i client raccolgano il contenuto generato dal server web, divorando molte risorse di sistema. Naturalmente la situazione è ipotetica, ma penso che l'essenza sia chiara. Il pacchetto aiuta a correggere la situazione sopra descritta. Dopo aver letto l'intera richiesta del cliente, la invia per l'elaborazione Apache, che a sua volta genera contenuto e restituisce la risposta pronta a Nginx il più rapidamente possibile, dopodiché può interrompere il processo con la coscienza pulita e liberare le risorse di sistema che occupa. Server Web Nginx, da cui si riceve il risultato della richiesta Apache, lo scrive in un buffer o anche in un file su disco e può cederlo ai client lenti per tutto il tempo desiderato, mentre i suoi processi di lavoro consumano così poche risorse che .. “è persino divertente parlarne” ©. :) Questo schema consente di risparmiare in modo significativo le risorse di sistema, ripeto, ma i processi di lavoro Nginx consumano una piccola quantità di risorse, questo è particolarmente vero per i progetti di grandi dimensioni.

E questa è solo una piccola parte di ciò che può fare il server Nginx; non dimenticare le capacità di memorizzazione nella cache dei dati e di lavoro con memcached. Darò un elenco dei principali funzionalità Server web Nginx.

Funzionalità del server Nginx come server HTTP
  • Trattamento contenuto statico, file indice, elenchi di directory, cache dei descrittori di file aperti;
  • Proxy accelerato con memorizzazione nella cache, distribuzione del carico e tolleranza agli errori;
  • Supporto accelerato CGI veloce server con caching, distribuzione del carico e tolleranza agli errori;
  • Struttura modulare, supporto per vari filtri (SSI, XSLT, GZIP, ripresa, risposte in blocchi);
  • Supporto per estensioni SSL e TLS SNI;
  • Basato su IP O Basato sul nome Server virtuali;
  • Lavorare con KeepAlive e connessioni in pipeline;
  • Possibilità di configurare eventuali timeout nonché il numero e la dimensione dei buffer, a livello Server Apache;
  • Esecuzione di varie azioni a seconda dell'indirizzo del cliente;
  • Modifica degli URI utilizzando espressioni regolari;
  • Pagine di errore speciali per 4xx e 5xx;
  • Limitare l'accesso in base all'indirizzo o alla password del cliente;
  • Impostazione dei formati dei file di registro, rotazione dei registri;
  • Limitare la velocità di risposta al cliente;
  • Limitare il numero di connessioni e richieste simultanee;
  • Supporta i metodi PUT, DELETE, MKCOL, COPY e MOVE;
  • Modifica delle impostazioni e aggiornamento del server senza interrompere il lavoro;
  • Integrato Perl;
Funzionalità del server Nginx come server proxy di posta
  • Inoltro al backend IMAP/POP3 utilizzando un server di autenticazione HTTP esterno;
  • Controllo SMTP dell'utente su esterno serverHTTP autenticazione e inoltro a un server SMTP interno;
  • Supporta i seguenti metodi di autenticazione:
    • POP3 - UTENTE/PASS, APOP, LOGIN AUT/PLAIN/CRAM-MD5;
    • IMAP - LOGIN, LOGIN AUT/PLIN/CRAM-MD5;
    • SMTP - LOGI AUT./Semplice/CRAM-MD5;
  • supporto SSL;
  • Supporto STARTTLS e STLS;
Sistemi operativi e piattaforme supportati dal server web Nginx
  • FreeBSD, da 3 a 8 - piattaforme, i386 e amd64;
  • Linux, da 2.2 a 2.6 - piattaforma i386; Linux 2.6-amd64;
  • Solaris 9 - piattaforme i386 e sun4u; Solaris 10 - piattaforme i386, amd64 e sun4v;
  • Piattaforme MacOS X ppc, i386;
  • Windows XP, WindowsServer 2003; (attualmente in fase di beta testing)
Architettura e scalabilità del server Nginx
  • Il processo principale (master), diversi processi di lavoro (configurati nel file di configurazione) in esecuzione sotto un utente non privilegiato;
  • Supporto per i seguenti metodi di elaborazione della connessione:
    • select è un metodo standard. Il modulo Nginx corrispondente viene creato automaticamente se non viene trovato un metodo più efficiente su una determinata piattaforma. Puoi forzare l'attivazione o la disattivazione della compilazione di un determinato modulo utilizzando le opzioni di configurazione --with-select_module o --without-select_module.
    • il sondaggio è il metodo standard. Il modulo Nginx corrispondente viene creato automaticamente se non viene trovato un metodo più efficiente su una determinata piattaforma. Puoi forzare l'attivazione o la disattivazione della compilazione di un determinato modulo utilizzando le opzioni di configurazione --with-poll_module o --without-poll_module.
    • kqueue - metodo efficace, utilizzato su sistemi operativi FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0 e MacOS X. Se utilizzato su macchine a doppio processore che eseguono MacOS X, può causare un panico nel kernel.
    • epoll è un metodo efficiente utilizzato in Linux 2.6+. Alcune distribuzioni, come SuSE 8.2, hanno patch per supportare epoll nel kernel 2.4.
    • rtsig - segnali in tempo reale, un metodo efficiente utilizzato in Linux 2.2.19+. Per impostazione predefinita, non possono esserci più di 1024 segnali in coda per l'intero sistema. Questo non è sufficiente per i server con carico elevato; la dimensione della coda deve essere aumentata utilizzando il parametro del kernel /proc/sys/kernel/rtsig-max. Tuttavia, a partire da Linux 2.6.6-mm2, questa opzione non è più disponibile, ogni processo ha invece una coda di segnali separata, la cui dimensione è determinata utilizzando RLIMIT_SIGPENDING.
    • Quando la coda è piena, server nginx lo reimposta ed elabora le connessioni utilizzando il metodo poll finché la situazione non torna alla normalità.
    • /dev/poll è un metodo efficace, supportato sui sistemi operativi Solaris 7 11/99+, HP/UX 11.22+ (eventport), IRIX 6.5.15+ e Tru64 UNIX 5.1A+.
    • eventport - porte degli eventi, un metodo efficace utilizzato in Solaris 10. Prima dell'uso, è necessario installare una patch per evitare il panico del kernel.
  • Utilizzando le funzionalità del metodo kqueue come EV_CLEAR, EV_DISABLE (per disabilitare temporaneamente un evento), NOTE_LOWAT, EV_EOF, numero di dati disponibili, codici di errore;
  • Funziona con sendfile (FreeBSD 3.1+, Linux 2.2.+, Mac OS X 10.5+), sendfile64 (Linux 2.4.21+) e sendfilev (Solaris 8 7/01+);
  • Supporto per accettare filtri (FreeBSD 4.1+) e TCP_DEFER_ACCEPT (Linux 2.4+);
  • 10.000 connessioni HTTP keep-alive inattive consumano circa 2,5 Mb di memoria;
  • Numero minimo di operazioni di copia dati;

NGINX può essere utilizzato non solo come server web o proxy http, ma anche per inoltrare la posta tramite i protocolli SMTP, IMAP, POP3. Ciò ti consentirà di configurare:

  • Un unico punto di ingresso per un sistema di posta elettronica scalabile.
  • Bilanciamento del carico tra tutti i server di posta.

In questo articolo l'installazione viene eseguita in sala operatoria. Sistema Linux. Come servizio di posta a cui vengono inviate le richieste, puoi utilizzare postfix, exim, dovecot, exchange, iredmail assembly e altro.

Principio di funzionamento

NGINX accetta richieste e si autentica sul server web. A seconda del risultato della verifica del login e della password, il proxy restituirà una risposta con diverse intestazioni.

In caso di successo:

Pertanto, determiniamo il server e la porta del server di posta in base all'autenticazione. Ciò offre molte opportunità con un'adeguata conoscenza dei linguaggi di programmazione.

In caso di guasto:

A seconda del risultato dell'autenticazione e dell'intestazione, il client viene reindirizzato al server di posta di cui abbiamo bisogno.

Preparazione del server

Apportiamo alcune modifiche alle impostazioni di sicurezza del server.

SELinux

Disabilitare SELinux se utilizziamo CentOS o se utilizziamo questo sistema sicurezza su Ubuntu:

vi /etc/selinux/config

SELINUX=disabilitato

Firewall

Se utilizziamo firewalld (impostazione predefinita su CentOS):

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

firewall-cmd --reload

Se usiamo iptables (predefinito in Ubuntu):

iptables -A INPUT -p tcp --dport 25 -j ACCETTA

iptables -A INPUT -p tcp --dport 110 -j ACCETTA

iptables -A INPUT -p tcp --dport 143 -j ACCETTA

apt-get installa iptables-persistent

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

* in questo esempio abbiamo consentito SMTP (25), POP3 (110), IMAP (143).

Installazione di NGINX

Dipende da sistema operativo L'installazione di NGINX è leggermente diversa.

o Linux Centos:

gnam installa nginx

o LinuxUbuntu:

apt installa nginx

Consentiamo l'avvio automatico del servizio e avviamolo:

systemctl abilita nginx

systemctl avvia nginx

Se NGINX è già installato nel sistema, controlla con quali moduli funziona:

Riceveremo un elenco di opzioni con cui è costruito il server web - tra queste dovremmo vedere --with-mail . Se il modulo richiesto non è presente, è necessario aggiornare nginx

Configurazione di NGINX

Apri il file di configurazione nginx e aggiungi l'opzione mail:

vi /etc/nginx/nginx.conf

posta (

auth_http localhost:80/auth.php;

Server (
ascolta 25;
protocollo smtp;
smtp_auth login semplice cram-md5;
}

Server (
ascolta 110;
protocollo pop3;

}

Server (
ascolta 143;
protocollo imap;
}
}

* Dove:

  • nome_server è il nome del server di posta che verrà visualizzato nel messaggio di saluto SMTP.
  • auth_http: server Web e URL per la richiesta di autenticazione.
  • proxy_pass_error_message - consente o nega la visualizzazione di un messaggio quando l'autenticazione fallisce.
  • listen - porta su cui vengono ascoltate le richieste.
  • protocollo - il protocollo dell'applicazione per il quale è in ascolto la porta corrispondente.
  • smtp_auth: metodi di autenticazione disponibili per SMTP.
  • pop3_auth: metodi di autenticazione disponibili per POP3.

Nella sezione http - server aggiungi:

Server (
ascolta 80 default_server;
ascolta [::]:80 default_server;
...

Posizione ~ \.php$ (
imposta $root_path /usr/share/nginx/html;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index indice.php;
fastcgi_param SCRIPT_FILENAME $root_path$fastcgi_script_name;
includere fastcgi_params;
fastcgi_param DOCUMENT_ROOT $root_percorso;
}
...

Riavvia il server nginx:

systemctl riavvia nginx

Installazione e configurazione di PHP

Per eseguire l'autenticazione utilizzando PHP, è necessario installare i seguenti pacchetti sul proprio sistema.

Se CentOS:

gnam installa php php-fpm

Se Ubuntu:

apt-get installa php php-fpm

Avvia PHP-FPM:

systemctl abilita php-fpm

systemctl avvia php-fpm

Autenticazione

La verifica dell'accesso e della password viene eseguita da uno script, il cui percorso è specificato dall'opzione auth_http. Nel nostro esempio, questo è uno script PHP.

Un esempio di modello ufficiale per uno script di verifica di login e password:

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

* questo script accetta qualsiasi login e password e reindirizza le richieste ai server 192.168.1.22 e 192.168.1.33. Per impostare l'algoritmo di autenticazione, modificare le righe 61 - 64. Le righe 73 - 77 sono responsabili della restituzione dei server a cui viene effettuato il reindirizzamento - in questo esempio, se il login inizia con i caratteri "a", "c", "f ”, “g”, il reindirizzamento avverrà al server mailhost01, altrimenti a mailhost02. La mappatura dei nomi dei server agli indirizzi IP può essere impostata alle righe 31, 32, altrimenti la chiamata verrà effettuata utilizzando il nome di dominio.

Configurazione di un server di posta

Lo scambio di dati tra il proxy NGINX e il server di posta avviene in forma aperta. È necessario aggiungere all'eccezione la possibilità di autenticazione tramite il meccanismo PLAIN. Ad esempio, per configurare dovecot, procedere come segue:

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

Aggiungi le righe:

remoto 192.168.1.11 (
disable_plaintext_auth = no
}

* in questo esempio, abbiamo consentito le richieste di autenticazione PLAIN dal server 192.168.1.11.

Controlliamo inoltre:

* se ssl è impostato su require , il controllo non funzionerà, poiché risulta che da un lato il server consente richieste in chiaro, ma richiede la crittografia SSL.

Riavviare il servizio Dovecot:

systemctl riavvia dovecot

Configurazione del cliente

Puoi procedere alla verifica delle nostre impostazioni proxy. Per fare ciò, nelle impostazioni del client, specifica l'indirizzo o il nome del server nginx come IMAP/POP2/SMTP, ad esempio:

* in questo esempio il client di posta è configurato per connettersi al server 192.168.1.11 tramite porti aperti 143 (IMAP) e 25 (SMTP).

Crittografia

Ora impostiamo una connessione SSL. Nginx deve essere compilato con il modulo mail_ssl_module - controlla con il comando:

Se manca il modulo richiesto, ricostruiamo nginx.

Quindi modifichiamo il nostro file di configurazione:

vi /etc/nginx/nginx.conf

posta (
nome_server mail.dominio.local;
auth_http localhost/auth.php;

Proxy_pass_error_message attivo;

SSL attivo;
ssl_certificate /etc/ssl/nginx/public.crt;
ssl_certificate_key /etc/ssl/nginx/private.key;
ssl_ciphers ALTO:!aNULL:!MD5;
ssl_session_cache condiviso:SSL:10m;
ssl_session_timeout 10m;

Server (
ascolta 110;
protocollo pop3;
pop3_auth semplice apop cram-md5;
}

Server (
ascolta 143;
protocollo imap;
}

Motivo: il sistema di sicurezza SELinux è attivato.

Soluzione: disabilitare o configurare SELinux.

Nginx sta rapidamente guadagnando popolarità, trasformandosi da semplice acceleratore di consegna statico per Apache in un server web completamente funzionale e sviluppato, che viene sempre più utilizzato in modo isolato. In questo articolo parleremo di scenari interessanti e non standard per l'utilizzo di nginx che ti permetteranno di ottenere il massimo dal tuo server web.

Procura di posta

Cominciamo con la cosa più ovvia: la capacità di nginx di agire come proxy di posta. Questa funzione è inizialmente presente in nginx, ma per qualche motivo viene utilizzata molto raramente nella produzione; alcune persone non sono nemmeno consapevoli della sua esistenza. Comunque sia, nginx supporta i protocolli proxy POP3, IMAP e SMTP con vari metodi di autenticazione, inclusi SSL e StartTLS, e lo fa molto rapidamente.

Perché è necessario? Esistono almeno due usi per questa funzionalità. Primo: usa nginx come scudo contro i fastidiosi spammer che tentano di inviare e-mail spazzatura attraverso il nostro server SMTP. In genere, gli spammer non creano molti problemi, poiché vengono rapidamente respinti in fase di autenticazione, tuttavia, quando ce ne sono davvero molti, nginx aiuterà a risparmiare risorse del processore. Secondo: utilizzare nginx per reindirizzare gli utenti a più server di posta POP3/IMAP. Naturalmente, un altro proxy di posta potrebbe gestire questa situazione, ma perché isolare i server se nginx è già installato sul front-end per fornire contenuto statico tramite HTTP, ad esempio?

Il server proxy di posta in nginx non è del tutto standard. Utilizza un ulteriore livello di autenticazione implementato tramite HTTP e solo se l'utente supera questa barriera può procedere oltre. Questa funzionalità viene fornita creando una pagina/script a cui nginx invia i dati dell'utente e lui/lei restituisce una risposta sotto forma di OK standard o un motivo per il rifiuto (come "Login o password non validi"). Lo script viene eseguito con le seguenti intestazioni:

Dati di input dello script di autenticazione HTTP_AUTH_USER: utente HTTP_AUTH_PASS: password HTTP_AUTH_PROTOCOL: protocollo di posta (IMAP, POP3 o SMTP)

E restituisce quanto segue:

Output dello script di autenticazione HTTP_AUTH_STATUS: OK o motivo dell'errore HTTP_AUTH_SERVER: server di posta reale da reindirizzare HTTP_AUTH_PORT: porta del server

Una caratteristica notevole di questo approccio è che può essere utilizzato non per l'autenticazione stessa, ma per distribuire gli utenti su diversi server interni, a seconda del nome utente, dei dati sul carico corrente sui server di posta o anche organizzando un semplice bilanciamento del carico utilizzando il girone all'italiana. Tuttavia, se hai solo bisogno di trasferire gli utenti su un server di posta interno, puoi utilizzare uno stub implementato da nginx stesso invece di uno script vero e proprio. Ad esempio, il proxy SMTP e IMAP più semplice nella configurazione nginx sarà simile a questo:

# vi /etc/nginx/nginx.conf mail ( # Indirizzo script di autenticazione auth_http localhost:8080/auth; # Disabilita il comando XCLIENT, alcuni server di posta non lo capiscono xclient off; # Server server IMAP ( ascolta 143; protocollo imap; proxy attivo; ) # Server server SMTP ( ascolta 25; protocollo smtp; proxy attivo; ) )

# vi /etc/nginx/nginx.conf http ( # Mappatura alla porta del server di posta desiderata a seconda della porta inviata nell'intestazione HTTP_AUTH_PROTOCOL map $http_auth_protocol $mailport ( default 25; smtp 25; imap 143; ) # Implementazione dell'autenticazione “script” - restituisce sempre OK e trasferisce l'utente al server di posta interno, impostando la porta desiderata utilizzando il server di mappatura sopra ( ascolta 8080; location /auth ( add_header "Auth-Status" "OK"; add_header "Auth-Server" "192.168.0.1" ; add_header "Porta-autenticazione" $mailport; return 200; ) ) )

Questo è tutto. Questa configurazione consente di reindirizzare in modo trasparente gli utenti al server di posta interno, senza creare un sovraccarico sotto forma di script che in questo caso non è necessario. Utilizzando uno script, questa configurazione può essere notevolmente ampliata: configurare il bilanciamento del carico, controllare gli utenti utilizzando il database LDAP ed eseguire altre operazioni. Scrivere lo script va oltre lo scopo di questo articolo, ma è molto semplice da implementare anche con una conoscenza minima di PHP e Python.

Video streaming

È facile configurare un normale hosting video basato su nginx. Tutto quello che devi fare è caricare il video transcodificato in una directory accessibile al server, registrarlo nella configurazione e configurare il lettore Flash o HTML5 in modo che prenda il video da questa directory. Tuttavia, se è necessario impostare la trasmissione video continua da alcuni fonte esterna o una webcam, questo schema non funzionerà e dovrai cercare protocolli di streaming speciali.

Esistono diversi protocolli che risolvono questo problema, il più efficace e supportato è RTMP. L'unico problema è che quasi tutte le implementazioni del server RTMP presentano problemi. Il server ufficiale Adobe Flash Media è a pagamento. Red5 e Wowza sono scritti in Java e quindi non prevedono prestazione richiesta, Un'altra implementazione, Erlyvideo, è scritta in Erlang, che è utile per la configurazione di un cluster, ma non altrettanto efficace per un singolo server.

Suggerisco un approccio diverso: utilizzare il modulo RTMP per nginx. Ha prestazioni eccellenti e ti consentirà anche di utilizzare un server per servire sia l'interfaccia web del sito che il flusso video. L'unico problema è che questo modulo non è ufficiale, quindi dovrai creare tu stesso nginx con il suo supporto. Fortunatamente l'assemblaggio viene effettuato in modo standard:

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

Ora il modulo deve essere configurato. Questo viene fatto, come al solito, attraverso la configurazione di nginx:

Rtmp ( # Attiva il server di trasmissione sulla porta 1935 all'indirizzo sito/server rtmp ( ascolta 1935; applicazione rtmp ( live on; ) ) )

Il modulo RTMP non può funzionare in configurazione multi-thread, quindi il numero di processi di lavoro nginx dovrà essere ridotto a uno (più avanti ti dirò come aggirare questo problema):

Processi_lavoratore 1;

Ora puoi salvare il file e forzare nginx a rileggere la configurazione. La configurazione di nginx è completa, ma non abbiamo ancora lo streaming video, quindi dobbiamo trovarlo da qualche parte. Ad esempio, lascia che questo sia il file video.avi dalla directory corrente. Per trasformarlo in uno stream e avvolgerlo nel nostro broadcaster RTMP, utilizzeremo il buon vecchio FFmpeg:

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

Se il file video non è in formato H264, deve essere ricodificato. Questo può essere fatto al volo usando lo stesso FFmpeg:

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

Lo streaming può anche essere catturato direttamente da una webcam:

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

Per visualizzare lo streaming sul lato client, puoi utilizzare qualsiasi player che supporti RTMP, ad esempio mplayer:

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

Oppure incorpora il player direttamente in una pagina web, servita dallo stesso nginx (esempio dalla documentazione ufficiale):

Il web player RTMP più semplice

jwplayer("container").setup(( modalità: [( tipo: "flash", src: "/jwplayer/player.swf", config: ( bufferlength: 1, file: "stream", streamer: "rtmp:/ /localhost/rtmp", provider: "rtmp", ) )] ));

Ci sono solo due righe importanti qui: “file: “stream””, che indica lo stream RTMP, e “streamer: “rtmp://localhost/rtmp””, che indica l'indirizzo dello streamer RTMP. Per la maggior parte delle attività, tali impostazioni saranno abbastanza sufficienti. Puoi inviare diversi flussi diversi a un indirizzo e nginx li multiplexerà efficacemente tra i client. Ma questo non è tutto ciò di cui è capace il modulo RTMP. Con il suo aiuto, ad esempio, puoi organizzare l'inoltro di un flusso video da un altro server. Il server FFmpeg non è affatto necessario per questo, basta aggiungere le seguenti righe alla configurazione:

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

Se devi creare più flussi di qualità diversa, puoi chiamare il transcoder FFmpeg direttamente da nginx:

# vi /etc/nginx/nginx.conf applicazione rtmp ( live on; exec ffmpeg -i rtmp://localhost/rtmp/$nome -c:v flv -c:a -s 320x240 -f flv rtmp://localhost /rtmp-320x240/$nome; ) applicazione rtmp-320x240 ( live on; )

Con questa configurazione otterremo due emittenti contemporaneamente, una delle quali sarà disponibile all'indirizzo rtmp://site/rtmp, e la seconda, che trasmette in qualità 320 x 240, all'indirizzo rtmp://site/rtmp –320x240. Successivamente, puoi aggiungere un flash player e pulsanti di selezione della qualità al sito, che forniranno al lettore l'uno o l'altro indirizzo dell'emittente.

E infine, un esempio di trasmissione di musica in rete:

Sebbene sia vero; do 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; Fatto

Proxy Git

Il sistema di controllo della versione Git è in grado di fornire accesso ai repository non solo tramite i protocolli Git e SSH, ma anche tramite HTTP. Una volta, l'implementazione dell'accesso HTTP era primitiva e incapace di fornire un lavoro completo con il repository. Con la versione 1.6.6 la situazione è cambiata e oggi con questo protocollo è possibile, ad esempio, aggirare le restrizioni del firewall su entrambi i lati della connessione o creare il proprio hosting Git con un'interfaccia web.

Sfortunatamente, la documentazione ufficiale parla solo di organizzare l'accesso a Git utilizzando il server web Apache, ma poiché l'implementazione stessa lo è applicazione esterna con un'interfaccia CGI standard, può essere collegato a quasi tutti gli altri server, inclusi lighttpd e, ovviamente, nginx. Ciò non richiede altro che il server stesso, Git installato e un piccolo server FastCGI fcgiwrap, necessario perché nginx non sa come lavorare direttamente con CGI, ma può chiamare script utilizzando il protocollo FastCGI.

L'intero schema di lavoro sarà simile a questo. Il server fcgiwrap si bloccherà in background e attenderà una richiesta per eseguire l'applicazione CGI. Nginx, a sua volta, sarà configurato per richiedere l'esecuzione del binario CGI git-http-backend tramite l'interfaccia FastCGI ogni volta che si accede all'indirizzo da noi specificato. Dopo aver ricevuto la richiesta, fcgiwrap esegue git-http-backend con gli argomenti CGI specificati passati dal client GIT e restituisce il risultato.

Per implementare tale schema, installa prima fcgiwrap:

$ sudo apt-get install fcgiwrap

Non è necessario configurarlo; tutti i parametri vengono trasmessi tramite il protocollo FastCGI. Inoltre verrà avviato automaticamente. Non resta quindi che configurare nginx. Per fare ciò, crea un file /etc/nginx/sites-enabled/git (se non esiste una directory di questo tipo, puoi scrivere nella configurazione principale) e scrivi quanto segue:

# vi /etc/nginx/sites-enabled/git server ( # Siamo bloccati sulla porta 8080 ascolta 8080; # Il nostro indirizzo del server (non dimenticare di aggiungere una voce nel 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; # Indirizzo primario per la posizione di accesso anonimo / ( # Quando si tenta di scaricare, invia l'utente a un indirizzo privato if ($ arg_service ~* "git-receive-pack") ( rewrite ^ /private$uri last; ) include /etc/nginx/fastcgi_params; # Indirizzo del nostro git-http-backend fastcgi_param SCRIPT_FILENAME /usr/lib/git-core/git- http-backend; # Indirizzo del repository Git fastcgi_param GIT_PROJECT_ROOT /srv/git; # Indirizzo del file fastcgi_param PATH_INFO $uri; # Indirizzo del server fcgiwrap fastcgi_pass 127.0.0.1:9001; ) # Indirizzo di accesso in scrittura location ~/private(/.* )$ ( # Autorizzazioni utente auth_basic "git anonimo di sola lettura, scrittura autenticata"; # Autenticazione HTTP basata su htpasswd auth_basic_user_file /etc/nginx/htpasswd; # Le impostazioni FastCGI includono /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; ) )

Questa configurazione presuppone tre cose importanti:

  • L'indirizzo del repository sarà /srv/git, quindi impostiamo i diritti di accesso appropriati: $ sudo chown -R www-data:www-data /srv/git
  • Il repository stesso deve essere aperto alla lettura da parte di utenti anonimi e consentire il caricamento tramite HTTP: $ cd /srv/git $ git config core.sharedrepository true $ git config http.receivepack true
  • L'autenticazione viene eseguita utilizzando il file htpasswd, è necessario crearlo e aggiungervi utenti: $ sudo apt-get install apache2-utils $ htpasswd -c /etc/nginx/htpasswd user1 $ htpasswd /etc/nginx/htpasswd user2 . ..

    • Questo è tutto, riavvia nginx:

    Microcaching

    Immaginiamo una situazione con un sito Web dinamico e aggiornato di frequente che improvvisamente inizia a ricevere carichi molto pesanti (beh, è ​​finito sulla pagina di uno dei più grandi siti di notizie) e smette di far fronte alla restituzione dei contenuti. L'ottimizzazione e l'implementazione corrette dello schema di memorizzazione nella cache richiederanno molto tempo e i problemi devono essere risolti ora. Ciò che possiamo fare?

    Esistono diversi modi per uscire da questa situazione con il minor numero di perdite, ma l'idea più interessante è stata proposta da Fenn Bailey (fennb.com). L'idea è semplicemente di mettere nginx davanti al server e forzarlo a memorizzare nella cache tutto il contenuto trasmesso, ma non solo nella cache, ma solo per un secondo. La svolta qui è che centinaia e migliaia di visitatori del sito al secondo genereranno, di fatto, solo una richiesta al backend, ricevendo una pagina per lo più memorizzata nella cache. Allo stesso tempo quasi nessuno noterà la differenza, perché anche su un sito dinamico un secondo di solito non significa nulla.

    La configurazione con l'implementazione di questa idea non sembrerà così complicata:

    # vi /etc/nginx/sites-enabled/cache-proxy # Configurazione della cache proxy_cache_path /var/cache/nginxlevels=1:2 keys_zone=microcache:5m max_size=1000m; server ( ascolta 80; nome_server esempio.com; # Posizione dell'indirizzo memorizzato nella cache / ( # La cache è abilitata per impostazione predefinita set $no_cache ""; # Disabilita la cache per tutti i metodi tranne GET e HEAD if ($request_method !~ ^(GET|HEAD) $) ( set $no_cache "1"; ) # Se il cliente carica contenuti sul sito (no_cache = 1), ci assicuriamo che i dati che gli sono stati forniti non vengano memorizzati nella cache per due secondi e che possa vedere il risultato del download 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 "; ) # Abilita/disabilita la cache in base allo stato della variabile no_cache proxy_no_cache $no_cache; proxy_cache_bypass $no_cache; # Richieste proxy al real server proxy_pass http://appserver.example.ru; proxy_cache microcache ; proxy_cache_key $scheme$host$request_method$ request_uri; proxy_cache_valid 200 1s; # Protezione dal problema Thundering Herd proxy_cache_use_stale aggiornamento; # Aggiungi intestazioni standard proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # Non memorizziamo nella cache file più grandi di 1 MB proxy_max_temp_file_size 1M; ) )

    Un posto speciale in questa configurazione è occupato dalla riga “proxy_cache_use_stale update;”, senza la quale avremmo ricevuto periodici picchi di carico sul server backend a causa delle richieste ricevute durante l'aggiornamento della cache. Altrimenti tutto è standard e dovrebbe essere chiaro senza spiegazioni inutili.

    Avvicinare i proxy al pubblico target

    Nonostante il diffuso aumento globale della velocità di Internet, la distanza fisica del server dal pubblico target continua a svolgere un ruolo importante. Ciò significa che se un sito russo viene eseguito su un server situato da qualche parte in America, la velocità di accesso ad esso sarà a priori più lenta rispetto a un server russo con la stessa larghezza di canale (ovviamente, se chiudi gli occhi su tutti gli altri fattori ). Un'altra cosa è che posizionare i server all'estero è spesso più redditizio, anche in termini di manutenzione. Pertanto, per ottenere profitti, sotto forma di tassi di pagamento più elevati, dovrai utilizzare alcuni trucchi.

    Una delle opzioni possibili: posizionare il principale server produttivo in Occidente e implementare un frontend che non richieda troppo risorse e produca dati statici in Russia. Ciò ti consentirà di guadagnare velocità senza costi gravi. La configurazione nginx per il frontend in questo caso sarà un'implementazione proxy semplice e familiare a tutti noi:

    # vi /etc/nginx/sites-enabled/proxy # Archivia la cache per 30 giorni in uno spazio di archiviazione da 100 GB proxy_cache_path /var/cache/nginx Levels=1:2 keys_zone=static:32m inactive=30d max_size=100g; server ( ascolta 80; nome_server esempio.com; # In realtà, la posizione del nostro proxy ~* .(jpg|jpeg|gif|png|ico|css|midi|wav|bmp|js|swf|flv|avi|djvu|mp3) $ ( # Indirizzo 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 static; proxy_cache_valid 30d; proxy_ignore_headers "Cache-Control" "Scade"; proxy_cache_key "$uri$is_args$args"; proxy_cache_lock attivo; ) )

    conclusioni

    Oggi, con l'aiuto di nginx, puoi risolvere molti problemi diversi, molti dei quali non sono affatto legati al server web e al protocollo HTTP. Proxy di posta, server di streaming e interfaccia Git sono solo alcune di queste attività.

    Pubblicazioni sull'argomento