Nginx kogub kiiresti populaarsust, liikudes lihtsalt Apache'i staatilisest serveerimiskiirendist täisfunktsionaalne ja täiustatud veebiserver, mida kasutatakse üha enam isoleeritult. Selles artiklis räägime huvitavatest ja mittestandardsetest nginxi kasutamise stsenaariumidest, mis võimaldavad teil veebiserverist maksimumi võtta.

Meili puhverserver

Alustame kõige ilmsemast – nginxi võimest toimida meili puhverserverina. See funktsioon on algselt nginxis, kuid millegipärast kasutatakse seda tootmises üliharva, mõned isegi ei tea selle olemasolust. Olgu kuidas on, nginx toetab POP3, IMAP ja SMTP protokollide puhverserverit erinevate autentimismeetoditega, sealhulgas SSL ja StartTLS, ja teeb seda väga kiiresti.

Miks seda vaja on? Sellel funktsioonil on vähemalt kaks kasutust. Esiteks kasutage nginxi kaitsena tüütute rämpspostitajate eest, kes üritavad meie SMTP-serveri kaudu rämpsposti saata. Tavaliselt ei tekita rämpspostitajad palju probleeme, kuna nad põrkavad autentimisetapis kiiresti tagasi, kuid kui neid on tõesti palju, aitab nginx CPU ressursse säästa. Teiseks kasutage nginxi kasutajate ümbersuunamiseks mitmesse POP3/IMAP-postiserverisse. Muidugi saaks sellega hakkama mõni teine ​​meili puhverserver, aga milleks jännata serveritega, kui nginx on juba frontendisse installitud, et näiteks HTTP kaudu staatiliselt teenindada?

Nginxi meilipuhverserver pole päris standardne. See kasutab täiendavat autentimiskihti, mis on rakendatud HTTP abil ja ainult siis, kui kasutaja selle tõkke ületab, edastatakse ta edasi. Seda funktsiooni pakub lehe / skripti loomine, millele nginx annab kasutajale andmed ja ta tagastab vastuse standardse OK või keeldumise põhjuse kujul (nt "Vigane sisselogimine või parool"). Skript töötab järgmiste päistega:

Autentimisskripti sisend HTTP_AUTH_USER: kasutaja HTTP_AUTH_PASS: parool HTTP_AUTH_PROTOCOL: postiprotokoll (IMAP, POP3 või SMTP)

Ja see naaseb järgmiselt:

Autentimisskripti väljund HTTP_AUTH_STATUS: OK või tõrke põhjus HTTP_AUTH_SERVER: tõeline meiliserver HTTP_AUTH_PORT: serveri port

Selle lähenemisviisi tähelepanuväärne omadus on see, et seda ei saa kasutada üldse mitte autentimiseks, vaid kasutajate hajutamiseks erinevate sisemiste serverite vahel, olenevalt kasutajanimest, meiliserverite praeguste koormuste andmetest või isegi lihtsaima koormuse tasakaalustamise korraldamiseks. ringmäng . Kui teil on aga vaja lihtsalt kasutajad sisemisse meiliserverisse üle kanda, võite pärisskripti asemel kasutada nginxi enda juurutatud tünni. Näiteks nginxi konfiguratsiooni lihtsaim SMTP- ja IMAP-puhverserver näeb välja järgmine:

# vi /etc/nginx/nginx.conf mail ( # Autentimisskripti aadress auth_http localhost:8080/auth; # Keela XCLIENT käsk, mõned meiliserverid ei mõista seda xclient off; # IMAP serveri server ( kuula 143; protokoll imap; puhverserver sees; ) # SMTP-server (kuula 25; protokoll smtp; puhverserver sees; ) )

# vi /etc/nginx/nginx.conf http ( # Vastandatakse õige meiliserveri pordiga sõltuvalt HTTP_AUTH_PROTOCOL päisekaardil saadetud pordist $http_auth_protocol $mailport ( vaikimisi 25; smtp 25; imap 143; ) # Autentimise rakendamine " script" - tagastab alati OK ja suunab kasutaja ümber sisemisse meiliserverisse, määrates ülaltoodud vastendusserveri abil õige pordi ( kuula 8080; asukoht / auth ( add_header "Auth-Status" "OK"; add_header "Auth-Server" " 192.168.0.1" ; add_header "Auth-Port" $postiport; return 200; ) ) )

See on kõik. See konfiguratsioon võimaldab kasutajaid läbipaistvalt ümber suunata sisemisse meiliserverisse, ilma et tekiks skripti kujul lisakulusid, mis pole antud juhul vajalikud. Skripti abil saab seda konfiguratsiooni oluliselt laiendada: seadistada koormuse tasakaalustamine, kontrollida kasutajaid LDAP-andmebaasis ja teha muid toiminguid. Skripti kirjutamine ei kuulu selle artikli ulatusse, kuid seda on väga lihtne rakendada isegi PHP ja Pythoni algteadmiste korral.

Video voogesitus

Tavalise nginxi-põhise videomajutuse seadistamine on lihtne. Kõik, mida pead tegema, on laadida ümberkodeeritud video serverile juurdepääsetavasse kataloogi, lisada see konfiguratsiooni ja seadistada flash või HTML5-mängija nii, et see võtaks video sellest kataloogist. Kui aga soovite seadistada pidevat videoedastust mõnest välisest allikast või veebikaamerast, siis see skeem ei tööta ja peate kasutama spetsiaalseid voogedastusprotokolle.

Selle probleemi lahendamiseks on mitu protokolli, neist kõige tõhusam ja toetatum on RTMP. Ainus probleem on see, et peaaegu kõik RTMP-serveri rakendused kannatavad probleemide all. Ametlik Adobe Flash Media Server on tasuline. Red5 ja Wowza on kirjutatud Java keeles ega taga seetõttu soovitud jõudlust, teine ​​teostus Erlyvideo on kirjutatud Erlangis, mis on klastri seadistamise korral hea, kuid mitte nii tõhus ühe serveri jaoks.

Soovitan teist lähenemisviisi - kasutage nginxi jaoks RTMP moodulit. Sellel on suurepärane jõudlus ja see võimaldab teil kasutada üht serverit nii saidi veebiliidese kui ka videovoo teenindamiseks. Ainus probleem on selles, et see moodul on mitteametlik, nii et peate selle toega nginxi ise ehitama. Õnneks toimub kokkupanek standardsel viisil:

$ sudo apt-get eemalda 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

Nüüd tuleb moodul konfigureerida. Seda tehakse, nagu tavaliselt, nginxi konfiguratsiooni kaudu:

Rtmp (# Aktiveerige edastusserver pordis 1935 saidil/rtmp-serveris (kuula 1935; rakenduse rtmp ( otseülekanne; ) ))

RTMP-moodul ei saa töötada mitme lõimega konfiguratsioonis, seega tuleb nginxi tööprotsesside arvu vähendada ühele (hiljem räägin teile, kuidas sellest probleemist mööda hiilida):

töötaja_protsessid 1;

Nüüd saame faili salvestada ja lasta nginxil konfiguratsiooni uuesti lugeda. Nginxi seadistamine on lõpule viidud, kuid meil pole veel videovoogu, seega peame selle kuskilt hankima. Näiteks olgu selleks video.avi fail praegusest kataloogist. Selle voogu muutmiseks ja meie RTMP ringhäälinguorganisatsiooniks mähkimiseks kasutame vana head FFmpegi:

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

Kui videofail pole H264-vormingus, tuleks see uuesti kodeerida. Seda saab teha lennult, kasutades sama FFmpegi:

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

Voogu saab jäädvustada ka otse veebikaamerast:

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

Voo vaatamiseks kliendi poolel võite kasutada mis tahes RTMP-toega pleierit, näiteks mplayerit:

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

Või manustage pleier otse veebilehele, mida teenindab sama nginx (näide ametlikust dokumentatsioonist):

Lihtsaim RTMP veebipleier

Siin on ainult kaks olulist rida: “file: “stream””, mis näitab RTMP-voogu, ja “streamer: “rtmp://localhost/rtmp””, mis määrab RTMP-voogedastaja aadressi. Enamiku ülesannete jaoks piisab nendest sätetest. Ühel aadressil saab käivitada mitu erinevat voogu ja nginx multipleksib need tõhusalt klientide vahel. Kuid see pole veel kõik, milleks RTMP-moodul on võimeline. Tema abiga saad näiteks korraldada videovoo taasedastamist teisest serverist. FFmpeg serverit pole selleks üldse vaja, lihtsalt lisa konfiguratsioonile järgmised read:

# vi /etc/nginx/nginx.conf rakendus rtmp (aktiivne; tõmba rtmp://rtmp.example.com; )

Kui teil on vaja luua mitu erineva kvaliteediga voogu, saate helistada FFmpeg-transkooderile otse nginxist:

# vi /etc/nginx/nginx.conf rakendus rtmp (aktiivne; exec ffmpeg -i rtmp://localhost/rtmp/$name -c:v flv -c:a -s 320x240 -f flv rtmp://localhost /rtmp-320x240/$name; ) rakendus rtmp-320x240 (aktiivne; )

Selle konfiguratsiooniga saame korraga kaks ringhäälinguorganisatsiooni, millest üks on saadaval aadressil rtmp://site/rtmp ja teine, mis edastab 320 x 240 kvaliteediga, aadressil rtmp://site/rtmp–320x240. Edasi saidil saate riputada flash-mängija ja kvaliteedivaliku nupud, mis libistavad mängijale ühe või teise ringhäälinguorganisatsiooni aadressi.

Ja lõpuks näide muusika võrku edastamisest:

samas tõsi; do ffmpeg -re -i "`leia /var/muusika -tüüp f -nimi "*.mp3"|sort -R|head -n 1`" -vn -c:a libfaac -ar 44100 -ac 2 -f flv rtmp://localhost/rtmp/stream; tehtud

git puhverserver

Giti versioonikontrollisüsteem suudab anda juurdepääsu hoidlatele mitte ainult Git- ja SSH-protokolli, vaid ka HTTP kaudu. Kunagi oli HTTP-juurdepääsu juurutamine primitiivne ega suutnud andmehoidlaga täisväärtuslikku tööd pakkuda. Alates versioonist 1.6.6 on olukord muutunud ning tänaseks saab selle protokolli abil näiteks mõlemal pool ühendust saada olevatest tulemüüripiirangutest mööda minna või luua oma veebiliidesega Git hosting.

Kahjuks räägitakse ametlikus dokumentatsioonis ainult Gitile juurdepääsu korraldamisest Apache veebiserveri abil, kuid kuna teostus ise on standardse CGI liidesega väline rakendus, saab selle ühendada peaaegu iga teise serveriga, sealhulgas lighttpd ja loomulikult nginx. See ei nõua midagi peale serveri enda, paigaldatud Giti ja väikese FastCGI serveri fcgiwrap, mida on vaja, sest nginx ei oska CGI-ga otse töötada, kuid suudab FastCGI protokolli kasutades skripte välja kutsuda.

Kogu tööskeem näeb välja selline. Fcgiwrap server jääb taustal rippuma ja ootab CGI-rakenduse käivitamise taotlust. Nginx on omakorda konfigureeritud taotlema git-http-taustaprogrammi CGI binaarfaili käivitamist FastCGI liidese kaudu iga kord, kui meie määratud aadressi külastatakse. Päringu saamisel käivitab fcgiwrap git-http-taustaprogrammi GIT-kliendi poolt edastatud määratud CGI-argumentidega ja tagastab tulemuse.

Sellise skeemi rakendamiseks installime esmalt fcgiwrap:

$ sudo apt-get install fcgiwrap

Te ei pea seda konfigureerima, kõik parameetrid edastatakse FastCGI protokolli kaudu. See käivitub ka automaatselt. Seetõttu jääb üle ainult nginxi konfigureerimine. Selleks looge fail /etc/nginx/sites-enabled/git (kui sellist kataloogi pole, saate kirjutada põhikonfiguratsiooni) ja kirjutage sellele järgmine tekst:

# vi /etc/nginx/sites-enabled/git server ( # Hang on port 8080, kuula 8080; # Meie serveri aadress (ärge unustage lisada DNS-i kirjet) serveri_nimi git.example.ru; # Logib juurdepääsu_logi /var /log/nginx /git-http-backend.access.log; error_log /var/log/nginx/git-http-backend.error.log; # Anonüümse juurdepääsu asukoha esmane aadress / ( # Kui proovite üles laadida, saatke kasutaja privaatsele aadressile if ($ arg_service ~* "git-receive-pack") ( kirjuta ümber ^ /private$uri last; ) include /etc/nginx/fastcgi_params; # Meie git-http-taustaprogrammi fastcgi_param SCRIPT_FILENAME /usr aadress /lib/git-core/git- http-backend; # Git hoidla aadress fastcgi_param GIT_PROJECT_ROOT /srv/git; # Faili aadress fastcgi_param PATH_INFO $uri; # Serveri aadress fcgiwrap fastcgi_pass 127.0.0.1:9001; kirjutamiskoht ~/private(/.* )$ ( # Kasutajaõigused auth_basic "git anonüümne kirjutuskaitstud, autentitud kirjutamine"; # HTTP autentimine htpasswd alusel auth_basic_user_file /etc/nginx/htpasswd; # FastCGI sätted i nclude /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; ) )

See konfiguratsioon eeldab kolme olulist asja:

1. Hoidla aadress on /srv/git, seega määrake sobivad õigused: $ sudo chown -R www-data:www-data /srv/git
2. Hoidla ise peab olema Anonymouse poolt loetav ja võimaldama HTTP kaudu üleslaadimist: $ cd /srv/git $ git config core.sharedrepository true $ git config http.receivepack true
3. Autentimine toimub faili htpasswd abil, peate selle looma ja sinna kasutajaid lisama: $ sudo apt-get install apache2-utils $ htpasswd -c /etc/nginx/htpasswd user1 $ htpasswd /etc/nginx/htpasswd user2 . .

See on kõik, taaskäivitage nginx:

Mikropeituse säilitamine

Kujutagem ette olukorda dünaamilise, sageli uuendatava saidiga, mis hakkab ootamatult saama väga suuri koormusi (noh, see sattus ühe suurima uudistesaidi lehele) ja ei tule enam sisu tagastamisega toime. Õige vahemällu salvestamise skeemi pädev optimeerimine ja juurutamine võtab kaua aega ning probleemidega tuleb tegeleda kohe. Mida me saame teha?

Sellest olukorrast minimaalsete kaotustega välja pääsemiseks on mitu võimalust, kuid kõige huvitavam idee tuli Fenn Baileylt (fennb.com). Idee on lihtsalt panna nginx serveri ette ja sundida seda kogu edastatud sisu vahemällu salvestama, kuid mitte ainult vahemällu, vaid ainult üheks sekundiks. Siin on esiletõstetud see, et sajad ja tuhanded saidi külastajad sekundis genereerivad taustaprogrammile ainult ühe kõne, millest enamik saab vahemällu salvestatud lehe. Samas vaevalt keegi erinevust märkab, sest isegi dünaamilisel saidil ei tähenda üks sekund tavaliselt midagi.

Selle idee rakendamisega konfiguratsioon ei tundu nii keeruline:

# vi /etc/nginx/sites-enabled/cache-proxy # Konfigureeri vahemälu proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=microcache:5m max_size=1000m; server ( kuula 80; serveri_nimi näide.com; # Vahemälu aadressi asukoht / ( # Vahemälu on vaikimisi lubatud seatud $no_cache ""; # Keela vahemälu kõigi meetodite jaoks, välja arvatud GET ja HEAD if ($request_method !~ ^(GET|HEAD) $ ) ( määra $no_cache "1"; ) # Kui klient laadib saidile sisu üles (no_cache = 1), siis jälgime, et talle antud andmed ei oleks kahe sekundi jooksul vahemällu salvestatud ja ta näeb allalaadimise tulemust, kui ($no_cache = "1") ( add_header Set-Cookie "_mcnc=1; Max-Age=2; Path=/"; add_header X-Microcacheable "0"; ) if ($http_cookie ~* "_mcnc") ( set $no_cache "1"; ) # Vahemälu lubamine/keelamine olenevalt muutuja no_cache proxy_no_cache olekust $no_cache; proxy_cache_bypass $no_cache; # Puhverserveri päringud tegelikule serverile proxy_pass http://appserver.example.ru; proxy_cache microcache; proxy_cache_key $scheme$host$request_method$ request_uri; proxy_cache_valid 200 1s; # Kaitse karja äikeseprobleemi eest proxy_cache_use_stale värskendamine; # Lisa standardpäised proxy_set_h päis Host $host; puhverserveri_komplekti_päis X-Real-IP $kaug-addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # Ärge salvestage vahemällu faile, mis on suuremad kui 1 MB proxy_max_temp_file_size 1M; ) )

Selles konfiguratsioonis on eriline koht rida "proxy_cache_use_stale updating;", ilma milleta oleksime vahemälu värskendamise ajal saabunud taotluste tõttu saanud taustaserveri perioodilisi koormusi. Vastasel juhul on kõik standardne ja peaks olema selge ilma täiendavate selgitusteta.

Puhverserveri lähendamine sihtrühmale

Vaatamata Interneti-kiiruse laialdasele ülemaailmsele kasvule mängib endiselt rolli serveri füüsiline kaugus sihtrühmast. See tähendab, et kui kuskil Ameerikas asuvas serveris töötab vene sait, on sellele ligipääsu kiirus a priori aeglasem kui sama ribalaiusega Venemaa serverilt (muidugi kui sulgete silmad kõigi muude tegurite ees ). Teine asi on see, et sageli on kasulikum servereid võõrustada, sealhulgas hoolduse mõttes. Seetõttu peate kõrgema tulumäära näol kasumi saamiseks tegema triki.

Üks võimalikest variantidest: paigutada peamine tootlik server läände ja juurutada Venemaale mitte liiga ressursinõudlik, staatilist andev esiots. See võimaldab teil ilma tõsiste kuludeta kiirust võita. Sel juhul on kasutajaliidese nginxi konfiguratsioon lihtne puhverserveri rakendus, mis on meile kõigile tuttav:

# vi /etc/nginx/sites-enabled/proxy # Säilitage vahemälu 30 päeva 100 GB salvestusruumis proxy_cache_path /var/cache/nginx level=1:2 keys_zone=static:32m inactive=30d max_size=100g; server ( kuulake 80; serveri_nimi näide.com; # Tegelikult on meie puhverserveri asukoht ~* .(jpg|jpeg|gif|png|ico|css|midi|wav|bmp|js|swf|flv|avi|djvu|mp3) $ ( # Taustaaadress 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; 3 proxy_6sk;2 proxy_bufferk;2 proxy_bufferk;2 proxy_cache_valid 30d; proxy_ignore_headers "Cache-Control" "Expires"; proxy_cache_key "$uri$is_args$args"; proxy_cache_lock on; ) )

järeldused

Tänapäeval saab nginxi abil lahendada palju erinevaid ülesandeid, millest paljud ei ole veebiserveri ja HTTP-protokolliga üldse seotud. Meili puhverserver, voogedastusserver ja Giti liides on vaid mõned ülesannetest.

See artikkel selgitab, kuidas konfigureerida NGINX Plusi või NGINX avatud lähtekoodi meiliserveri või välise meiliteenuse puhverserverina.

Sissejuhatus

NGINX saab IMAP-, POP3- ja SMTP-protokolle puhverserveriga saata ühele ülesvoolu meiliserverile, mis majutab meilikontosid, ja seega saab seda kasutada meiliklientide ühe lõpp-punktina. See võib tuua kaasa mitmeid eeliseid, näiteks:

• meiliserverite arvu lihtne skaleerimine
• meiliserveri valimine erinevate reeglite alusel, näiteks lähima serveri valimine kliendi IP-aadressi alusel
• koormuse jaotamine meiliserverite vahel

Eeltingimused

NGINX Plus (sisaldab juba e-posti puhverserveri liikluse jaoks vajalikke mooduleid) või NGINX avatud lähtekoodiga kompileerisid meilimoodulid, kasutades meilipuhverserveri funktsioonide jaoks parameetrit --with-mail ja SSL/TLS-i toe jaoks parameetrit --with-mail_ssl_module:

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

IMAP, POP3 ja/või SMTP meiliserverid või väline meiliteenus

SMTP/IMAP/POP3 meilipuhverserverite konfigureerimine

NGINX-i konfiguratsioonifailis:

post (#...)

mail ( serveri_nimi mail.example.com ; #... )

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

Teise võimalusena määrake, kas teavitada kasutajat autentimisserveri vigadest, määrates käskkirja proxy_pass_error_message. See võib olla kasulik, kui postkasti mälu saab otsa:

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

Konfigureerige iga SMTP-, IMAP- või POP3-server serveriplokkidega. Iga serveri jaoks määrake:

• a pordi number mis vastavad kuulamiskäskkirjaga määratud protokollile
• a protokolli protokolli käskkirjaga (kui pole määratud, tuvastatakse automaatselt kuulamisjuhises määratud pordist)
• lubatud autentimismeetodid käskkirjadega imap_auth , pop3_auth ja smtp_auth:

server ( kuula 25 ; protokoll smtp ; smtp_auth login plain cram-md5 ; ) server ( kuula 110 ; protokoll pop3 ; pop3_auth tavaline apop cram-md5 ; ) server ( kuula 143 ; protokolli imap ; )

E-posti puhverserveri autentimise seadistamine

Iga kliendi POP3/IMAP/SMTP päring autentitakse esmalt välises HTTP autentimisserveris või autentimisskripti abil. Autentimisserveri olemasolu on NGINX-i meiliserveri puhverserveri jaoks kohustuslik. Serveri saab ise luua vastavalt NGINX autentimisprotokollile, mis põhineb HTTP-protokollil.

Kui autentimine õnnestub, valib autentimisserver ülesvooluserveri ja suunab päringu ümber. Sel juhul sisaldab serveri vastus järgmisi ridu:

HTTP/1.0 200 OK Auth-Status: OK Auth-Server: # posti töötlemiseks kasutatava ülesvoolu serveri serveri nimi või IP-aadress Auth port: # ülesvoolu serveri port

Kui autentimine ebaõnnestub, saadab autentimisserver veateate. Sel juhul sisaldab serveri vastus järgmisi ridu:

HTTP/1.0 200 OK autentimise olek: # kliendile tagastatav tõrketeade, nt "Vigane sisselogimine või parool" Auth-wait: # järelejäänud autentimiskatsete arv kuni ühenduse sulgemiseni

Pange tähele, et mõlemal juhul sisaldab vastus HTTP/1.0 200 OK mis võib segadusse ajada.

Rohkem näiteid autentimisserverile saadetavate taotluste ja vastuste kohta leiate NGINX-i viitedokumentatsiooni moodulist ngx_mail_auth_http_.

SSL/TLS-i seadistamine meilipuhverserveri jaoks

SSL-i/TLS-i kaudu POP3/SMTP/IMAP-i kasutades veendute, et kliendi ja meiliserveri vahel edastatavad andmed on kaitstud.

SSL/TLS-i lubamiseks meilipuhverserveri jaoks tehke järgmist.

Veenduge, et teie NGINX on konfigureeritud SSL/TLS-i toega, tippides käsureale käsu nginx -V ja seejärel otsides väljundist rida with --mail_ssl_module:

$ nginx -V seadistada argumendid: ... with---mail_ssl_module

Veenduge, et olete hankinud serveri sertifikaadid ja privaatvõtme ning sisestage need serverisse. Sertifikaadi saab hankida usaldusväärselt sertifitseerimisasutuselt (CA) või luua SSL-teegi (nt OpenSSL) abil.

ssl sees;

ehmatab sisse ;

Lisage SSL-sertifikaadid: määrake ssl_certificate direktiiviga sertifikaatide tee (mis peavad olema PEM-vormingus) ja määrake privaatvõtme tee direktiivis ssl_certificate_key:

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

Saate kasutada ainult tugevaid SSL/TLS-i versioone ja šifreid koos ssl_protocols ja ssl_ciphers direktiividega või saate määrata oma eelistatud protokollid ja šifrid:

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

SSL/TLS optimeerimine meilipuhverserveri jaoks

Need näpunäited aitavad teil muuta NGINX-i meilipuhverserveri kiiremaks ja turvalisemaks.

Määrake tööprotsesside arv protsessorite arvuga võrdseks, kui direktiiv worker_processes on seatud meilikontekstiga samale tasemele:

töötaja_protsessid auto ; post (#...)

Lubage jagatud seansi vahemälu ja keelake automaatse seansi vahemälu; mail ( serveri_nimi mail.example.com ; auth_http localhost : 9000 /cgi-bin/nginxauth.cgi ; proxy_pass_error_message on ; ssl on ; ssl_certificate /etc/ssl/certs/server_stslkeyer/servertslkeyer võti ; ssl_protocols TLSv1 TLSv1.1 TLSv1.2 ; ssl_ciphers HIGH:!aNULL:!MD5 ; ssl_session_cache shared:SSL:10m ; ssl_session_timeout 10m ; ssl_session_timeout 10m ; server ( kuulata 1 logindmtp ; protokoll pop3 ; pop3_auth tavaline apop cram-md5 ; ) server ( kuula 143 ; protokolli imap ; ) )

Selles näites on kolm e-posti puhverserverit: SMTP, POP3 ja IMAP. Kõik serverid on konfigureeritud SSL-i ja STARTTLS-i toega. SSL-i seansi parameetrid salvestatakse vahemällu.

Puhverserver kasutab HTTP autentimisserverit – selle konfigureerimine ei kuulu käesoleva artikli reguleerimisalasse. Kõik serveri veateated saadetakse klientidele tagasi.

Nginx- väikese suurusega, väga kiire, üsna funktsionaalne veebiserver ja meilipuhverserver, arendaja Igor Sysoev (rambler.ru). Süsteemi ressursside ja kiiruse väga madala tarbimise ning konfiguratsiooni paindlikkuse tõttu veeb nginx server kasutatakse sageli raskemate serverite (nt Apache, suure koormusega projektides. Klassikaline variant on hunnik, Nginx - Apache - FastCGI. Sellise skeemi järgi töötades nginx server, võtab vastu kõik HTTP kaudu saabuvad päringud ning, olenevalt konfiguratsioonist ja päringust endast, otsustab, kas töödelda päringut ise ja anda kliendile valmis vastus või saata taotlus töötlemiseks ühele taustaprogrammidest ( Apache või FastCGI).

Teatavasti töötleb Apache server iga päringut eraldi protsessis (lõimes), mis, peab ütlema, kulutab üsna MITTE vähe süsteemiressursse, kui selliseid protsesse on 10-20, siis on jama ja kui kui neid on 100–500 või rohkem, ei muutu süsteem lõbusaks.

Proovime sellist olukorda ette kujutada. Oletame, et sisse Apache 300 HTTP-päringut tulevad klientidelt, 150 klienti istuvad kiiretel püsiliinidel ja ülejäänud 150 suhteliselt aeglastel Interneti-kanalitel, isegi kui mitte modemitel. Mis selles olukorras juhtub? Ja juhtub järgmine: Apache veebiserver loob nende 300 ühenduse töötlemiseks iga protsessi (lõime) jaoks, see genereerib sisu kiiresti ja 150 kiiret klienti võtavad kohe oma päringu tulemuse, neid teenindanud protsessid. tapetakse ja ressursid vabastatakse ning 150 on aeglased ja nende päringute tulemused võtab kitsa Interneti-kanali tõttu aeglaselt, mille tagajärjel jääb süsteemi rippuma 150 protsessi Apache, oodates, kuni kliendid võtavad veebiserveri loodud sisu, ahmides palju süsteemiressursse. Loomulikult on olukord hüpoteetiline, kuid ma arvan, et olemus on selge. Ülaltoodud olukorra parandamiseks ja kimp aitab. Pärast kliendilt kogu päringu lugemist edastab ta selle töötlemiseks Apache, mis omakorda genereerib sisu ja tagastab valmis vastuse Nginxile nii kiiresti kui võimalik, misjärel saab see protsessi puhta südametunnistusega tappa ja vabastada hõivatud süsteemiressursid. Nginxi veebiserver, mis saab päringu tulemuse aadressilt Apache, kirjutab selle puhvrisse või isegi kettale faili ja võib anda suvaliselt pikaks ajaks aeglastele klientidele, samal ajal kui selle tööprotsessid tarbivad nii vähe ressursse, et .. "sellest on isegi naeruväärne rääkida" ©. :) Selline skeem säästab oluliselt süsteemiressursse, ma kordan, aga Nginxi tööprotsessid kulutavad vähe ressursse, seda olulisem on see suurte projektide puhul.

Ja see on vaid väike osa sellest, mida Nginxi server saab teha, ärge unustage andmete vahemällu salvestamise ja nendega töötamise võimalust puhverdatud. Siin on nimekiri Nginxi veebiserveri põhifunktsioonidest.

Nginxi serveri funktsionaalsus HTTP-serverina

• Staatiline sisuhaldus, registrifailid, kataloogide loend, failideskriptori vahemälu avamine;
• Kiirendatud puhverserver vahemällu salvestamise, koormuse tasakaalustamise ja tõrkevahetusega;
• Kiirendatud tugi FastCGI vahemällu salvestamise, koormuse tasakaalustamise ja tõrketaluvusega serverid;
• Modulaarne struktuur, erinevate filtrite tugi (SSI, XSLT, GZIP, resume, tükeldatud vastused);
• SSL ja TLS SNI laienduste tugi;
• ip-põhine või nimepõhine virtuaalserverid;
• KeepAlive'i ja toruühendustega töötamine;
• Võimalus konfigureerida tasemel mis tahes ajalõppe, samuti puhvrite arvu ja suurust Apache server;
• Erinevate toimingute tegemine sõltuvalt kliendi aadressist;
• URI muutmine regulaaravaldiste abil;
• Spetsiaalsed vealehed 4xx ja 5xx jaoks;
• Juurdepääsupiirang kliendi aadressi või parooli alusel;
• Logifailide vormingute seadistamine, logide pööramine;
• Kliendile reageerimise kiiruse piiramine;
• Samaaegsete ühenduste ja päringute arvu piiramine;
• PUT-, DELETE-, MKCOL-, COPY- ja MOVE-meetodite tugi;
• Seadete muutmine ja serveri värskendamine ilma tööd katkestamata;
• sisseehitatud Perl;

Nginxi serveri funktsionaalsus meili puhverserverina

• Edastamine IMAP/POP3 taustaprogrammi välise HTTP autentimisserveri abil;
• Kasutaja SMTP kontrollimine välises HTTP autentimisserveris ja edastamine sisemisse SMTP serverisse;
• Järgmiste autentimismeetodite tugi:
  • POP3 – KASUTAJA/PASS, APOP, AUTH LOGIN/PLAIN/CRAM-MD5;
  • IMAP - LOGIN, AUTH LOGIN/PLAIN/CRAM-MD5;
  • SMTP - AUTH LOGI / PLAIN / CRAM-MD5;
• SSL tugi;
• STARTTLS-i ja STLS-i tugi;

Nginxi veebiserveri toetatud operatsioonisüsteemid ja platvormid

• FreeBSD, platvormid 3 kuni 8, i386 ja amd64;
• Linux, 2.2 kuni 2.6 - i386 platvorm; Linux 2.6 - amd64;
• Solaris 9 - i386 ja sun4u platvormid; Solaris 10 - i386, amd64 ja sun4v platvormid;
• MacOS X platvormid ppc, i386;
• Windows XP, Windows Server 2003; (Praegu beetatestimisel)

Nginxi serveri arhitektuur ja skaleeritavus

• Põhi- (põhi)protsess, mitmed (konfiguratsioonifailis konfigureeritavad) tööprotsessid, mis töötavad privilegeerimata kasutaja all;
• Tugi järgmistele ühenduse haldamise viisidele:
  • vali on standardmeetod. Vastav Nginxi moodul ehitatakse automaatselt, kui antud platvormil tõhusamat meetodit ei leita. Saate sundida selle mooduli ehitamist sisse või välja lülitama, kasutades seadistusvalikuid --with-select_module või --without-select_module.
  • küsitlus on standardmeetod. Vastav Nginxi moodul ehitatakse automaatselt, kui antud platvormil tõhusamat meetodit ei leita. Saate sundida selle mooduli ehitamist sisse või välja lülitama, kasutades seadistusvalikuid --with-poll_module või --without-poll_module.
  • kqueue on tõhus meetod, mida kasutatakse operatsioonisüsteemides FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0 ja MacOS X. Kasutades kahe protsessoriga MacOS X masinates, võib see põhjustada kerneli paanikat.
  • epoll on tõhus meetod, mida kasutatakse operatsioonisüsteemis Linux 2.6+. Mõnel distributsioonil, näiteks SuSE 8.2-l, on paigad epolli toetamiseks 2.4 tuumas.
  • rtsig - reaalajas signaalid, tõhus meetod, mida kasutatakse operatsioonisüsteemis Linux 2.2.19+. Vaikimisi ei tohi kogu süsteemi järjekorras olla rohkem kui 1024 signaali. Suure koormusega serverite puhul sellest ei piisa, järjekorra suurust tuleb suurendada parameetri /proc/sys/kernel/rtsig-max kerneli abil. Kuid alates Linuxi versioonist 2.6.6-mm2 on see valik eemaldatud, selle asemel on igal protsessil eraldi signaalijärjekord, mille suuruse määrab RLIMIT_SIGPENDING.
  • Kui järjekord on täis, nginx server lähtestab selle ja käsitleb ühendusi küsitlusmeetodil, kuni olukord normaliseerub.
  • /dev/poll- tõhus meetod, mida toetavad operatsioonisüsteemid Solaris 7 11/99+, HP/UX 11.22+ (eventport), IRIX 6.5.15+ ja Tru64 UNIX 5.1A+.
  • eventport – sündmuste pordid, Solaris 10 kasutatav tõhus meetod. Enne kasutamist tuleb tuumapaanika vältimiseks paigaldada plaaster.
• Kasutades kqueue meetodi funktsioone, nagu EV_CLEAR, EV_DISABLE (sündmuse ajutiseks keelamiseks), NOTE_LOWAT, EV_EOF, saadaolevate andmete arv, veakoodid;
• Töötage sendfile'iga (FreeBSD 3.1+, Linux 2.2.+, Mac OS X 10.5+), sendfile64 (Linux 2.4.21+) ja sendfileviga (Solaris 8 7/01+);
• Aktsepteerimisfiltrite (FreeBSD 4.1+) ja TCP_DEFER_ACCEPT (Linux 2.4+) tugi;
• 10 000 jõudeolekus HTTP elushoidmise ühendust tarbivad ligikaudu 2,5 miljonit mälu;
• Andmete kopeerimise toimingute minimaalne arv;

iRedMail on avatud lähtekoodiga meiliserveri ehitus. Koost põhineb Postfix SMTP serveril (lühidalt MTA). Koost sisaldab ka: Dovecot, SpamAssassin, Greylist, ClamAV, SOGo Roundcube, NetData ja NGINX.

Tuvipuu- IMAP/POP3 server.

Spamassassin- rämpsposti filtreerimise tööriist.

Hallinimekiri- rämpspostitõrje tööriist hallidel loenditel.

ClamAV- viirusetõrje.

Ümarkuubik Ja Nii et mine- Veebikliendid e-postiga töötamiseks.

Net Andmed- programm serveri töö jälgimiseks reaalajas.

Nginx- veebiserver.

Toetab operatsioonisüsteeme: CentOS 7, Debian 9, Ubuntu 16.04/18.04, FreeBSD 11/12 Ja OpenBSD 6.4.

iRedMailil on tasulised ja tasuta versioonid, mis erinevad üksteisest iRedAdmini enda meilikomplekti veebiliidese funktsionaalsuse poolest. Tasuta versioonis saate luua ainult domeene, kasutajate ja administraatorite postkaste. Kui teil on vaja aliast luua, ei saa te seda tasuta versioonis iRedAdmini kaudu teha. Õnneks on olemas tasuta lahendus nimega PostfixAdmin, mis võimaldab seda teha. PostfixAdmin integreerub hõlpsalt iRedMailiga ja töötab sellega suurepäraselt.

Paigaldamine

Installimiseks vajame ühte ülaltoodud operatsioonisüsteemidest. Ma kasutan Ubuntu serverit 18.04. Samuti peab teil olema ostetud domeeninimi ja konfigureeritud DNS-tsoon. Kui kasutate oma domeeni registripidaja DNS-serverit, peate domeenitsooni halduse jaotises tegema kaks kirjet: A ja MX. Saate kasutada ka oma DNS-i, seadistades oma domeeninime registripidaja isiklikul kontol delegeerimise.

Domeenitsooni seadistamine DNS-i registripidaja kasutamisel

Märge! DNS-i sätted jõustuvad mitmest tunnist ühe nädalani. Kuni seadete jõustumiseni ei tööta meiliserver korralikult.

Installimiseks laadige iRedMaili veebisaidilt alla praegune versioon. Hetkel on see 0,9,9.

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

Seejärel pakkige allalaaditud arhiiv lahti.

# tar xjf iRedMail-0.9.9.tar.bz2

Arhiivi lahti pakkimine

Ja minge loodud kausta.

# cd iRedMail-0.9.9

iRedMaili installijaga kaust

Kausta sisu kontrollimine

Kausta sisu

Ja käivitage iRedMaili installiskript.

# bash iRedMail.sh

Algab meilisüsteemi installimine. Installiprotsessi käigus peate vastama mitmele küsimusele. Oleme nõus installimist alustama.

Paigaldamise algus

Installikataloogi valimine

Nüüd peate valima veebiserveri. Valik pole suur, seega valime NGINXi.

Veebiserveri valimine

Nüüd peate valima andmebaasiserveri, mis installitakse ja konfigureeritakse meilisüsteemiga töötama. Valige MariaDB.

Andmebaasiserveri valimine

Määrake andmebaasi juurparool.

Andmebaasi juurparooli loomine

Nüüd täpsustame oma meili domeeni.

Meili domeeni loomine

Seejärel looge administraatorikasti jaoks parool [e-postiga kaitstud] domain.ru.

Looge meili administraatori parool

Veebikomponentide valimine

Kinnitame määratud seaded.

Seadete kinnitamine

Installimine algas.

Paigaldamine

Pärast installimise lõpetamist kinnitage reegli loomine iptables jaoks SSH ja taaskäivitage tulemüür. iRedMail töötab iptables. Ubuntus kõige sagedamini kasutatav tulemüürihaldusutiliit UVW. Kui teil on ühel või teisel põhjusel selline vajadus, installige UVW (apt install ufw) ja lisage reeglid UVW(näide: ufw luba "nginx täis" või ufw luba Postfix) ei blokeerinud meiliserverit. Saate vaadata saadaolevate reeglite loendit, käivitades käsu: ufw rakenduste loend. Seejärel lülitage sisse UVW: ufw lubada.

Looge iptablesi reegel

Tulemüüri taaskäivitamine

See lõpetab iRedMaili installimise. Süsteem andis meile veebiliidese aadressid ja sisselogimismandaadid. Kõigi meilisüsteemi komponentide lubamiseks peate serveri taaskäivitama.

Installimise lõpp

Me taaskäivitame.

# taaskäivitamine

Seadistamine

Kõigepealt peate veenduma, et kõik töötab. Püüame siseneda iReadAdmini juhtpaneelile aadressil https://domain/iredadmin. Logi sisse [e-postiga kaitstud] domain.ru, parool loodi installimise ajal. Seal on venekeelne liides.

Nagu näete, kõik töötab. iRedAdminisse sisse logides saite tõenäoliselt sertifikaadiga seotud turvatõrke. Seda seetõttu, et iRedMailil on iseallkirjastatud sertifikaat, mida brauser vannub. Selle probleemi lahendamiseks peate installima kehtiva SSL-sertifikaadi. Kui olete selle ostnud, saate selle installida. Näites installin Let's Encrypt tasuta SSL-i.

Let's Encrypt SSL-sertifikaadi installimine

Paigaldame sertifikaadi utiliidi certbot abil. Esmalt lisame hoidla.

# add-apt-hoidla ppa:certbot/certbot

Seejärel installime certbooti enda koos vajalike komponentidega.

# apt install python-certbot-nginx

Saame tunnistuse.

# certbot --nginx -d domain.ru

Pärast käsu käivitamist palub süsteem teil sisestada e-posti aadress, sisestage. Pärast seda saate suure tõenäosusega veateate, et pole võimalik leida serveriplokki, mille jaoks sertifikaat genereeriti. Sel juhul on see normaalne, kuna meil pole ühtegi serveriplokki. Meie jaoks on põhiline tunnistuse saamine.

Sertifikaadi saamine

Nagu näha, saadi sertifikaat edukalt kätte ja süsteem näitas meile teed sertifikaadi enda ja võtmeni. Need on just need, mida me vajame. Üldiselt saime 4 faili, mis salvestatakse kausta "/etc/letsencrypt/live/domain". Nüüd peame oma sertifikaadist veebiserverit teavitama, st asendama manustatud sertifikaadi äsja saadud sertifikaadiga. Selleks peame redigeerima ainult ühte faili.

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

Ja muutke selles kaks viimast rida.

SSL-sertifikaadi asendamine

Muudame failis olevad teed nendeks, mille süsteem meile sertifikaadi saamisel ütles.

SSL-sertifikaadi asendamine

Ja taaskäivitage NGINX.

# teenuse nginx taaskäivitamine

Proovime nüüd uuesti sisse logida. iRedAdmin.

SSL-sertifikaadi kontrollimine

Sertifikaadi viga enam pole. Sertifikaat on kehtiv. Saate klõpsata lukul ja näha selle omadusi. Kui sertifikaat aegub, peaks certboot seda automaatselt uuendama.

Nüüd räägime Dovecoti ja Postfixi sertifikaadist. Selleks redigeerime kahte konfiguratsioonifaili. Me teeme:

# nano /etc/dovecot/dovecot.conf

Ploki leidmine:

#SSL: globaalsed seaded.

Ja muudame seal registreeritud sertifikaadi enda omaks.

Dovecoti sertifikaadi asendus

Pöörake tähelepanu ka reale "ssl_protocols". Selle väärtus peab olema "!SSLv3", vastasel juhul kuvatakse tõrketeade "Hoiatus: OpenSSL ei toeta SSLv2-d. Dovecoti taaskäivitamisel kaaluge selle eemaldamist kaustast ssl_protocols".

# nano /etc/postfix/main.cf

Ploki leidmine:

# SSL-võti, sertifikaat, CA

Ja muudame selles olevad teed meie sertifikaadi failide teedeks.

Sertifikaadi asendus Postfixile

See lõpetab sertifikaadi installimise. Dovecot ja Postfix on vaja taaskäivitada, kuid parem on server taaskäivitada.

# teenindustuvi taaskäivitamine

# taaskäivitamine

PHPMyAdmini installimine

See üksus on valikuline, kuid soovitan teil see lõpule viia ja oma andmebaasikogemuse huvides installida PHPMyAdmin.

# apt install phpmyadmin

Installer palub teil töötada, millise veebiserveriga PHPMyAdmini konfigureerida, kuna NGINX-i selles loendis pole, vajutage lihtsalt TAB ja liikuge edasi.

PHPMyAdmini installimine

Kui installimine on lõppenud, peate phpmyadmini töötamiseks looma sümboolika kataloogile, millega NGINX vaikimisi töötab.

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

Ja proovige minna https://domain/phpmyadmin/

PHPMyAdmin töötab. Ühendus on sertifikaadiga kaitstud, vigu pole. Liigu edasi. Loome MySQL andmebaasi administraatori (MariaDB).

# mysql

Ja me jõuame MariaDB halduskonsooli. Järgmisena täidame käsud ükshaaval:

MariaDB > LOO KASUTAJA "admin"@"localhost" TUNNISTATUD "parooliga";
MariaDB > ANNA KÕIK PRIVILEEGID *.*-LE TOOTMISVALIKKUGA ANDMINE "admin"@"localhost";
MariaDB > FLUSH PRIVILEEGID;

MySQL-i kasutaja loomine

Kõik on korras, olete sisse logitud. PHPMyAdmin on kasutamiseks valmis.

PostfixAdmini installimine

Põhimõtteliselt ei saa PostfixAdmini, nagu ka PHPMyAdmini, installida. Meiliserver töötab ilma nende komponentideta suurepäraselt. Kuid siis ei saa te meilinimesid luua. Kui te seda ei vaja, jätke need jaotised vabalt vahele. Kui vajate endiselt varjunimesid, on teil kaks võimalust: osta iReaAdmini tasuline versioon või installida PostfixAdmin. Loomulikult saab seda teha ilma lisatarkvarata, kirjutades andmebaasi varjunimed käsitsi, kuid see pole alati mugav ega sobi kõigile. Soovitan kasutada PostfixAdminit, nüüd kaalume selle installimist ja integreerimist iRedMailiga. Alustame paigaldamist:

# apt install postfixadmin

Lepime kokku ja loome programmi süsteemiandmebaasi parooli.

PostfixAdmini installimine

PostfixAdmini installimine

Teeme sümlingi analoogselt PHPMyAdmini installimisega.

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

Teeme kataloogi omanikuks kasutaja, kelle nimel veebiserver käivitatakse. Meie puhul käitatakse NGINX-i www-andmete kasutajana.

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

Nüüd peame redigeerima PostfixAdmini konfiguratsioonifaili ja lisama teavet iRedAdmini kasutatava andmebaasi kohta. Vaikimisi nimetatakse seda andmebaasi vmailiks. Kui lähete PHPMyAdminisse, näete seda seal. Ja selleks, et PostfixAdmin saaks andmebaasis muudatusi teha, kirjutame selle ette PostfixAdmini konfiguratsioonis.

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

Liinide leidmine:

$CONF["andmebaasi_tüüp"] = $dbtüüp;
$CONF["andmebaasi_host"] = $dbserver;
$CONF["andmebaasi_kasutaja"] = $dbuser;
$CONF["andmebaasi_parool"] = $dbpääs;
$CONF["andmebaasi_nimi"] = $dbname;

Ja tuletage meelde:

$CONF["database_type"] = "mysqli"; # Andmebaasi tüüp
$CONF["database_host"] = "kohalik host"; # Andmebaasiserveri host
$CONF["database_user"] = "administraator"; # Logige sisse vmaili andmebaasi kirjutamisõigusega. Võite kasutada varem loodud administraatorit
$CONF["database_password"] = "parool"; # Ülaltoodud kasutaja parool
$CONF["andmebaasi_nimi"] = "vmail"; # iRedMaili andmebaasi nimi

Andmebaasi teabe sisestamine

Kui kavatsete kasutada SOGo veebimeili klienti, peate tegema veel ühe täiendava sammu, nimelt muutma lõigus PostfixAdmini krüptimist $CONF["krüpti"] alates "md5crypt" peal "tuvikas: SHA512-CRYPT". Kui te seda ei tee, siis kui proovite SOGo-s autoriseerida PostfixAdminis loodud kasutaja, kuvatakse tõrketeade vale sisselogimise või parooliga.

Krüptimise tüübi muutmine

Installimise edukaks lõpuleviimiseks ja vigade vältimiseks peate nüüd andmebaasist päringu tegema. Seda on mugav teha PHPMyAdmini kaudu. Valige vmaili andmebaas ja minge vahekaardile SQL. Sisestage aknasse:

DROPP INDEX domeen postkasti;
DROP INDEX domeen aliasele;
ALTER TABLE alias ADD COLUMN 'goto' text NOT NULL;

Andmebaasi päring

Ja vajuta "Edasi". Nüüd on kõik valmis, võite minna PostfixAdmini veebiliidese ja installimise lõpule viia. Selleks peate brauserisse sisestama: https://domain/postfixadmin/setup.php.

Ilmuma peaks järgmine:

PostfixAdmini installimine

Kui kõik on tehtud vastavalt juhistele, ei tohiks vigu olla. Kui need ikka on, siis reedetakse need kõrvaldamiseks, muidu süsteem ei lase jätkata. Määrake installiparool ja klõpsake " Loo parooliräsi Süsteem genereerib parooli räsi, mis tuleb parameetrisse sisestada $CONF["setup_password"].

PostfixAdmini installimise lõpuleviimine

Konfiguratsioonifaili sätete muutmine

Nüüd sisestame äsja loodud parooli ja loome PostfixAdmini administraatori. Parem on mitte luua administraatorit postmasteri sisselogimisega, kuna iRedAdmini halduspaneelile sisselogimisel võib tekkida probleeme.

PostfixAdmini administraatori loomine

Kõik, administraator on loodud. Saate sisse logida.

Pange tähele, et turvalisuse seisukohast on parem postfixadmin kataloogis olev setup.php fail ümber nimetada või kustutada.

Lähme: https://domain/postfixadmin/ ja sisestage äsja loodud mandaadid. Nii PostfixAdminis kui ka iRedAdminis on vene keel saadaval. Seda saab valida autoriseerimise ajal.

Püüame luua kasutaja postkasti.

iRedMaili moodulite lubamine/keelamine

iRedMaili mooduleid haldab iRedAPD. Sellel on konfiguratsioonifail, mis sisaldab töömooduleid. Kui te konkreetset moodulit ei vaja, võite selle konfiguratsioonifailist eemaldada ja see lakkab töötamast. Me teeme:

# nano /opt/iredapd/settings.py

Leidke rida pistikprogrammid" ja eemaldage sellest komponendid, mida te ei vaja. Ma eemaldan komponendi "hall nimekiri". Muidugi kaitseb see rämpsposti eest üsna tõhusalt, kuid vajalikud kirjad sageli ei jõua.

Greylist (hall nimekiri) on automaatne rämpsposti kaitse tehnoloogia, mis põhineb saatja serveri käitumise analüüsil. Kui "greylisting" on lubatud, keeldub server esimest korda vastu võtmast kirju tundmatul aadressil, teatades ajutisest veast. Sel juhul peab saatja server proovima saata hiljem uuesti. Rämpsposti saatjad seda tavaliselt ei tee. Kui kiri saadetakse uuesti, lisatakse see nimekirja 30 päevaks ja posti vahetatakse juba esimesest korrast. Kasutage seda moodulit või ärge otsustage ise.

Meilimoodulite lubamine/keelamine

Pärast muudatuste tegemist peate taaskäivitama. iRedAPD.

# teenus iredapd taaskäivitamine

Meiliserveri testimine

See lõpetab iRedMaili meiliserveri seadistamise. Võite jätkata viimast etappi - testimist. Loome kaks postkasti. Ühe kontrollimiseks iRedAdmini kaudu, teise PostfixAdmini kaudu ja kirja saatmiseks ühest postkastist teise ja vastupidi. Looge iRedAdminis postkast [e-postiga kaitstud] domain.ru. PostfixAdminis - [e-postiga kaitstud] domain.ru

Kasutaja loomine iRedAdminis

Kasutaja loomine PostfixAdminis

Kontrollige, kas kasutajad on loodud.

Kui pöörate tähelepanu PostfixAdmini postkastide loendi veerule "Adressaat", näete erinevust iRedAdminis ja PostfixAdminis loodud postkastide vahel. iRedAdminis loodud postkastid on tähistatud kui " ainult edasi" ja need, mis on PostfixAdminis loodud kui - " Postkast". Algul ei saanud ma pikka aega aru, miks see nii juhtub ja mis vahe neil on ning lõpuks märkasin üht asja. iRedAdminis luuakse postkastid ilma aliasteta ja PostfixAdminis postkastid, millel on alias iseendale.

Ja kui need varjunimed kustutatakse, kuvatakse postkastid iRedAdminis loodud postkastidena. ainult edasi".

Alinimede eemaldamine

Varjunimed on eemaldatud. Kontrollige PostfixAdmin.

Nagu näete, on kõik kastid muutunud "Ainult edasi". Samamoodi, kui loote iRedAdminis loodud postkasti endale aliase, saab sellest "Postkast". Põhimõtteliselt ei mõjuta see posti jõudlust. Ainus asi on see, et PostfixAdminis loodud postkastile ei saa aliast luua. Pseudonüümi loomise asemel peate redigeerima olemasolevat. Rääkides varjunimedest, peate iRedMaili uues versioonis muutma üht aliaste eest vastutavat Postfixi kaarti. Ja kui te seda ei tee, siis loodud varjunimed ei tööta. Selleks on see failis vajalik /etc/postfix/mysql/virtual_alias_maps.cf parandada:

Me teeme:

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

Ja me parandame selle.

Alinimede seadistamine

Taaskäivitage Postfix:

# teenuse postfix taaskäivitamine

Pärast seda peaks kõik toimima.

Ja nii, alustame posti kontrollimist. Kastis kasutaja1 me läbime Roundcube'i ja siseneme kasti kasutaja2- SOGo kaudu ja saada postkastist kiri kasutaja1 peal kasutaja2 ja tagasi.

Meili saatmine Roundcube'iga

Meili vastuvõtmine SOGos

Meili saatmine SOGo-le

Meilide vastuvõtmine Roundcube'is

Kõik töötab ilma probleemideta. Kirja kohaletoimetamine võtab aega kaks kuni viis sekundit. Samamoodi toimetatakse kirjad suurepäraselt Yandexi ja mail.ru serveritesse (kontrollitud).

Nüüd kontrollime varjunimesid. Loome kasti kasutaja 3 ja tehke postkastist alias kasutaja1 kasti peal kasutaja2. Ja saatke kastist kiri kasutaja 3 kasti peal kasutaja1. Sel juhul peab kiri jõudma kasti kasutaja2.

Looge alias

Meili saatmine kasutaja3 postkastist kasutaja1 postkasti

Kirja saamine kasutaja2 postkasti

Ka varjunimede tööga on kõik korras.

Testime meiliserveri tööd läbi kohaliku meilikliendi. Näiteks kaaluge Mozilla Thunderbirdi. Loome veel kaks kasutajat: klient1 Ja klient2. Ühe postkasti ühendame IMAP-i, teise POP3 kaudu ja saadame kirja ühest postkastist teise.

Ühenduse loomine IMAP-i kaudu

POP3 ühendus

Saadame kirja kliendilt 1 kliendile 2.

Saatmine kliendilt 1

Võtke vastu kliendil 2

Ja vastupidises järjekorras.

Kliendilt saatmine 2

Saate kliendil 1

Kõik töötab.

Kui lähete: https://domain/netdata, siis saate jälgida süsteemi oleku graafikuid.

Järeldus

See lõpetab iRedMaili meilisüsteemi installimise, konfigureerimise ja testimise. Selle tulemusena saime täiesti tasuta täisväärtusliku meiliserveri, millel on kehtiv SSL sertifikaat, kaks erinevat veebipõhist meiliklienti, kaks juhtpaneeli, samuti e-posti sisse ehitatud rämpsposti- ja viirusetõrje. Soovi korral saate veebimeiliklientide asemel kasutada kohalikke meilikliente, nagu Microsoft Outlook või Mozilla Thunderbird. Kui te ei plaani veebimeili kliente kasutada, ei saa te neid üldse installida, et mitte serverit üle koormata, või installida üks asi, mis teile rohkem meeldib. Mulle isiklikult meeldib SOGo rohkem, sest selle liides on optimeeritud mobiilseadmetele, mis teeb meilide vaatamise nutitelefonist väga mugavaks. Sama kehtib ka NetData ja iRedAdmini kohta, kui te ei kavatse seda kasutada, on parem seda mitte installida. See meilisüsteem ei ole ressurssidele väga nõudlik. Kõik see töötab VPS-serveris, millel on 1024 MB muutmälu ja üks virtuaalne protsessor. Kui teil on selle meilisüsteemi kohta küsimusi, kirjutage kommentaaridesse.

P.S. Selle toote testimisel erinevatel 1 GB muutmäluga operatsioonisüsteemidel (Ubuntu, Debian, CentOS) selgus, et ClamAV-i toimimiseks 1 GB-st ei piisa. Peaaegu kõigil juhtudel viitas viirusetõrje 1 GB mälu kasutamisel andmebaasi veale. Samal ajal Debiani ja Ubuntu operatsioonisüsteemides viirusetõrje lihtsalt ei skaneerinud serverit läbivaid kirju, muidu töötas kõik hästi. CentOS-is oli olukord mõnevõrra erinev. Clamd-teenus katkestas süsteemi täielikult, muutes serveri normaalse töö võimatuks. Veebiliidestesse sisselogimisel andis NGINX perioodiliselt 502 ja 504 tõrkeid. Aja jooksul saadeti ka kirju. Samal ajal, kui lisate RAM-i kuni 2 GB, siis kõigil juhtudel ei olnud viirusetõrje ja serveri kui terviku tööga probleeme. ClamAV skaneeris meiliserverit läbivaid kirju ja kirjutas sellest logidesse. Kui üritati manusena viirust saata, siis saatmine blokeeriti. Mälu tarbimine oli umbes 1,2–1,7 GB.

NGINX-i saab kasutada mitte ainult veebiserverina või http-puhverserverina, vaid ka meili puhverserveriks SMTP, IMAP, POP3 protokollide kaudu. See seadistab:

• Skaleeritava postisüsteemi ühtne sisenemispunkt.
• Koormuse tasakaalustamine kõigi meiliserverite vahel.

See artikkel installib Linuxi operatsioonisüsteemi. Meiliteenusena, kuhu päringud saadetakse, saate kasutada postfixi, eximi, dovecot'i, Exchange'i, iredmaili kokkupanekut ja palju muud.

Toimimispõhimõte

NGINX aktsepteerib päringuid ja autentib veebiserveri. Sõltuvalt sisselogimise ja parooli kontrollimise tulemusest saadab puhverserver vastuse mitme päisega.

Edu korral:

Seega määrame meiliserveri serveri ja pordi autentimise põhjal. See annab palju võimalusi vastavate programmeerimiskeelte tundmisega.

Ebaõnnestumise korral:

Olenevalt autentimise tulemusest ja päisest suunatakse klient meile vajalikku meiliserverisse.

Serveri ettevalmistamine

Teeme mõned muudatused serveri turvaseadetes.

SELinux

Keelake SELinux, kui kasutate CentOS-i või kui kasutate seda turvasüsteemi Ubuntus:

vi /etc/selinux/config

SELINUX=keelatud

Tulemüür

Kui kasutame tulemüüri(vaikimisi CentOS-is):

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

firewall-cmd -- laadige uuesti

Kui kasutame iptablesi(vaikimisi Ubuntus):

iptables -A SISEND -p tcp --dport 25 -j ACCEPT

iptables -A SISEND -p tcp -dport 110 -j ACCEPT

iptables -A SISEND -p tcp -dport 143 -j ACCEPT

apt-get install iptables-persistent

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

* selles näites lubasime SMTP (25), POP3 (110), IMAP (143).

NGINX installimine

Sõltuvalt operatsioonisüsteemist on NGINX-i installimine veidi erinev.

või Linux centos:

yum installige nginx

või Linux ubuntu:

apt installida nginx

Lubame teenuse automaatse käivitamise ja käivitame selle:

systemctl lubab nginx

systemctl käivitage nginx

Kui NGINX on juba süsteemi installitud, kontrollige, milliste moodulitega see töötab:

Saame loendi võimalustest, millega veebiserver on üles ehitatud - nende hulgas peaksime nägema ---postiga. Kui vajalikku moodulit pole, peate nginxi värskendama

NGINX-i seadistamine

Avage nginxi konfiguratsioonifail ja lisage valik mail:

vi /etc/nginx/nginx.conf

mail (

auth_http localhost:80/auth.php;

server(
kuula 25;
protokoll smtp;
smtp_auth sisselogimine tavaline cram-md5;
}

server(
kuula 110;
protokoll pop3;

}

server(
kuula 143;
protokollikaart;
}
}

* kus:

• serveri_nimi— meiliserveri nimi, mida kuvatakse SMTP-tervituse ajal.
• auth_http— veebiserver ja autentimistaotluse URL.
• proxy_pass_error_message— lubab või keelab sõnumi kuvamise ebaõnnestunud autentimise korral.
• kuulake— port, mille kaudu päringuid kuulatakse.
• protokolli on rakendusprotokoll, mida vastav port kuulab.
• smtp_auth— SMTP jaoks saadaolevad autentimismeetodid.
• pop3_auth— POP3 jaoks saadaolevad autentimismeetodid.

Lisage jaotisesse http - server:

server(
kuula 80 default_server;
kuula [::]:80 vaikimisi_server;
...

Asukoht ~ \.php$ (
määra $root_path /usr/share/nginx/html;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $juurtee$fastcgi_script_name;
sisaldavad fastcgi_params;
fastcgi_param DOCUMENT_ROOT $juuretee;
}
...

Taaskäivitage nginxi server:

systemctl taaskäivitage nginx

PHP installimine ja konfigureerimine

PHP abil autentimise teostamiseks tuleb süsteemi installida järgmised paketid.

Kui CentOS:

yum installige php php-fpm

Kui ubuntu:

apt-get install php php-fpm

Käivitage PHP-FPM:

systemctl lubab php-fpm

systemctl käivitage php-fpm

Autentimine

Sisselogimist ja parooli kontrollib skript, mille tee määrab suvand auth_http. Meie näites on see PHP-skript.

Näide sisselogimise ja parooli kinnitamise skripti ametlikust mallist:

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

* see skript aktsepteerib mis tahes sisselogimist ja parooli ning suunab päringud serveritesse 192.168.1.22 Ja 192.168.1.33 . Autentimisalgoritmi seadistamiseks redigeerime ridu 61–64. Read 73–77 vastutavad serverite tagastamise eest, kuhu ümbersuunamine on pooleli – selles näites, kui sisselogimine algab tähemärkidega "a", "c", "f", "g", siis suunatakse ümber serverisse mailhost01, muidu sisse mailhost02. Serverite nimede vastendamist IP-aadressidega saab seadistada ridadel 31, 32, vastasel juhul toimub kõne domeeninime järgi.

Meiliserveri seadistamine

Andmevahetus NGINX-i puhverserveri ja meiliserveri vahel on selge. Erandile on vaja lisada PLAIN-mehhanismi autentimise võimalus. Näiteks dovecot'i konfigureerimiseks tehke järgmist.

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

Lisa ridu:

kaugjuhtimispult 192.168.1.11 (
disable_plaintext_auth = ei
}

* selles näites lubasime serverist LIHTSAID autentimistaotlusi 192.168.1.11 .

Samuti kontrollime:

* kui ssl läheb korda nõutud, kontroll ei tööta, sest selgub, et ühelt poolt lubab server päringuid selgeks, kuid nõuab ssl-krüptimist.

Taaskäivitage Dovecoti teenus:

systemctl taaskäivitage dovecot

Kliendi seadistamine

Saate jätkata meie puhverserveri seadete kontrollimist. Selleks määrake kliendi seadetes nginxi serveri aadress või nimi näiteks IMAP/POP2/SMTP:

* selles näites on meiliklient konfigureeritud serveriga ühenduse loomiseks 192.168.1.11 avatud sadamate kaudu 143 (IMAP) ja 25 (SMTP).

Krüpteerimine

Nüüd seadistame SSL-ühenduse. Nginx tuleb ehitada mooduliga mail_ssl_module- kontrollige käsuga:

Vajaliku mooduli puudumisel ehitame nginxi ümber.

Pärast meie konfiguratsioonifaili redigeerimist:

vi /etc/nginx/nginx.conf

mail (
serveri_nimi mail.domain.local;
auth_http localhost/auth.php;

proxy_pass_error_message on;

SSL sisse lülitatud;
ssl_certificate /etc/ssl/nginx/public.crt;
ssl_certificate_key /etc/ssl/nginx/private.key;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_session_cache jagatud:SSL:10m;
ssl_session_timeout 10m;

server(
kuula 110;
protokoll pop3;
pop3_auth tavaline apop cram-md5;
}

server(
kuula 143;
protokollikaart;
}

Põhjus: SELinuxi turvasüsteem käivitub.

Lahendus: keelake või konfigureerige SELinux.