Serveri i postës Nginx. Konfigurimi i NGINX për proksimin e postës

Ky artikull do të shpjegojë se si të konfiguroni NGINX Plus ose NGINX Open Source si një përfaqësues për një server poste ose një shërbim postar të jashtëm.

Prezantimi

NGINX mund të proksojë protokollet IMAP, POP3 dhe SMTP në një nga serverët e postës në rrjedhën e sipërme që pret llogaritë e postës dhe kështu mund të përdoret si një pikë e vetme përfundimtare për klientët e postës elektronike. Kjo mund të sjellë një sërë përfitimesh, të tilla si:

• shkallëzimi i lehtë i numrit të serverëve të postës
• zgjedhja e një serveri mail bazuar në rregulla të ndryshme, për shembull, zgjedhja e serverit më të afërt bazuar në adresën IP të një klienti
• shpërndarja e ngarkesës midis serverëve të postës

Parakushtet

NGINX Plus (tashmë përfshin modulet e Mail-it të nevojshëm për të transmetuar trafikun e postës elektronike) ose NGINX Open Source përpiloi modulet Mail duke përdorur parametrin --with-mail për funksionalitetin e përfaqësuesit të postës elektronike dhe parametrin --with-mail_ssl_module për mbështetjen SSL/TLS:

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

Serverët e postës IMAP, POP3 dhe/ose SMTP ose një shërbim postar i jashtëm

Konfigurimi i serverëve proxy të postës SMTP/IMAP/POP3

Në skedarin e konfigurimit NGINX:

postë (#...)

mail (emri i serverit mail.example.com; #...)

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

Përndryshe, specifikoni nëse duhet të informoni një përdorues për gabimet nga serveri i vërtetimit duke specifikuar direktivën proxy_pass_error_message. Kjo mund të jetë e dobishme kur një kuti postare mbaron memorien:

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

Konfiguro çdo server SMTP, IMAP ose POP3 me blloqet e serverit. Për secilin server, specifikoni:

• të numri i portit që korrespondojnë me protokollin e specifikuar me direktivën e dëgjimit
• të protokoll me direktivën e protokollit (nëse nuk specifikohet, do të zbulohet automatikisht nga porti i specifikuar në direktivën e dëgjimit)
• lejohet metodat e vërtetimit me direktivat imap_auth, pop3_auth dhe smtp_auth:

server (dëgjo 25; protokolli smtp; smtp_auth login i thjeshtë cram-md5;) server (dëgjo 110; protokolli pop3; pop3_auth i thjeshtë apop cram-md5;) server (dëgjo 143; imazh protokolli;)

Vendosja e vërtetimit për një përfaqësues të postës

Çdo kërkesë POP3/IMAP/SMTP nga klienti do të vërtetohet fillimisht në një server të jashtëm vërtetimi HTTP ose nga një skript vërtetimi. Pasja e një serveri vërtetimi është e detyrueshme për përfaqësuesin e serverit të postës NGINX. Serveri mund të krijohet vetë në përputhje me protokollin e vërtetimit NGINX i cili bazohet në protokollin HTTP.

Nëse vërtetimi është i suksesshëm, serveri i vërtetimit do të zgjedhë një server në rrjedhën e sipërme dhe do ta ridrejtojë kërkesën. Në këtë rast, përgjigja nga serveri do të përmbajë rreshtat e mëposhtëm:

HTTP/1.0 200 OK Auth-Status: OK Auth-Server: # emri i serverit ose adresa IP e serverit në rrjedhën e sipërme që do të përdoret për përpunimin e postës Auth-Port: # porti i serverit në rrjedhën e sipërme

Nëse vërtetimi dështon, serveri i vërtetimit do të kthejë një mesazh gabimi. Në këtë rast, përgjigja nga serveri do të përmbajë rreshtat e mëposhtëm:

HTTP/1.0 200 OK Auth-Status: # një mesazh gabimi që do t'i kthehet klientit, për shembull "Identifikimi ose fjalëkalimi i pavlefshëm" Auth-Prit: # numri i përpjekjeve të mbetura për vërtetim derisa lidhja të mbyllet

Vini re se në të dyja rastet përgjigja do të përmbajë HTTP/1.0 200 OK të cilat mund të jenë konfuze.

Për më shumë shembuj të kërkesave dhe përgjigjeve nga serveri i vërtetimit, shihni ngx_mail_auth_http_module në dokumentacionin e referencës NGINX.

Konfigurimi i SSL/TLS për një përfaqësues të postës

Duke përdorur POP3/SMTP/IMAP mbi SSL/TLS, ju siguroheni që të dhënat e kaluara ndërmjet një klienti dhe një serveri poste janë të siguruara.

Për të aktivizuar SSL/TLS për përfaqësuesin e postës:

Sigurohuni që NGINX juaj të jetë i konfiguruar me mbështetje SSL/TLS duke shtypur komandën nginx -V në vijën e komandës dhe më pas duke kërkuar linjën me --mail_ssl_module në dalje:

$ nginx -V konfiguroni argumentet: ... me--mail_ssl_module

Sigurohuni që të keni marrë certifikatat e serverit dhe një çelës privat dhe t'i vendosni ato në server. Një certifikatë mund të merret nga një autoritet certifikues i besuar (CA) ose të gjenerohet duke përdorur një bibliotekë SSL si OpenSSL.

ssl në ;

befasohet;

Shtoni certifikatat SSL: specifikoni rrugën drejt certifikatave (të cilat duhet të jenë në formatin PEM) me direktivën ssl_certificate dhe specifikoni shtegun drejt çelësit privat në direktivën ssl_certificate_key:

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

Mund të përdorni vetëm versione dhe shifra të forta të SSL/TLS me direktivat ssl_protocols dhe ssl_ciphers, ose mund të vendosni protokollet dhe shifrat tuaja të preferuara:

mail ( #... ssl_protocols TLSv1 TLSv1.1 TLSv1.2 ; ssl_shifrore LARTË:!aNULL:!MD5 ; )

Optimizimi i SSL/TLS për përfaqësuesin e postës

Këto sugjerime do t'ju ndihmojnë ta bëni përfaqësuesin tuaj të postës NGINX më të shpejtë dhe më të sigurt:

Vendosni numrin e proceseve të punës të barabartë me numrin e përpunuesve me direktivën worker_processes të vendosur në të njëjtin nivel me kontekstin e postës:

punëtori_proceset auto ; postë (#...)

Aktivizo cache-në e përbashkët të sesioneve dhe çaktivizo memorien e integruar të sesionit me automatik; mail (emri i serverit mail.example.com; auth_http localhost: 9000 /cgi-bin/nginxauth.cgi; proxy_pass_error_message i aktivizuar; ssl në; ssl_certificate /etc/ssl/certs/server.crtsertsific. çelësi ; ssl_protocols TLSv1 TLSv1.1 TLSv1.2 ; ssl_ciphers LARTË:!aNULL:!MD5 ; ssl_session_cache e ndarë:SSL:10m ; ssl_session_timeout 10m ; server (dëgjim 25 loginthmtm-protocol ;) server (dëgjo 1 10 ; protokolli pop3 ; pop3_auth i thjeshtë apop cram-md5 ; ) server (dëgjo 143 ; imazh protokolli ; ) )

Në këtë shembull, ekzistojnë tre serverë proxy email: SMTP, POP3 dhe IMAP. Secili prej serverëve është i konfiguruar me mbështetje SSL dhe STARTTLS. Parametrat e sesionit SSL do të ruhen në memorie të fshehtë.

Serveri proxy përdor serverin e vërtetimit HTTP - konfigurimi i tij është përtej qëllimit të këtij artikulli. Të gjitha mesazhet e gabimit nga serveri do t'u kthehen klientëve.

iRedMail është montim i gatshëm serveri i postës me të hapur Kodi i burimit. Asambleja bazohet në serverin Postfix SMTP (Agjenti i Transferimit të Mailit, shkurtuar si MTA). Asambleja përfshin gjithashtu: Dovecot, SpamAssassin, Greylist, ClamAV, SOGo Roundcube, NetData dhe NGINX.

Dovecot - server IMAP/POP3.

Spamassassin është një mjet për filtrimin e spamit.

Greylist është një mjet anti-spam i bazuar në listën gri.

ClamAV është një antivirus.

Roundcube dhe SOGo janë klientë në internet për të punuar me email.

NetData është një program monitorimi i serverit në kohë reale.

Nginx është një server në internet.

Mbështet sistemet operative: CentOS 7, Debian 9, Ubuntu 16.04/18.04, FreeBSD 11/12 dhe OpenBSD 6.4.

iRedMail ka versione me pagesë dhe falas, të cilat ndryshojnë nga njëri-tjetri në funksionalitetin e ndërfaqes së tyre të internetit të asamblesë së postës iRedAdmin. NË version falas Mund të krijoni vetëm domene, kuti postare përdoruesi dhe administratori. Nëse keni nevojë të krijoni një pseudonim, nuk do të jeni më në gjendje ta bëni këtë në versionin falas nëpërmjet iRedAdmin. Për fat të mirë, ekziston një zgjidhje falas e quajtur PostfixAdmin që ju lejon ta bëni këtë. PostfixAdmin integrohet lehtësisht në iRedMail dhe funksionon shkëlqyeshëm me të.

Instalimi

Për të instaluar, do të na duhet një nga sistemet operative të listuara më sipër. Unë do të përdor Ubuntu Server 18.04. Duhet të keni blerë gjithashtu Emri i domenit dhe zona e konfiguruar DNS. Nëse jeni duke përdorur serverët DNS regjistruesi i domenit tuaj, atëherë duhet të bëni dy hyrje në seksionin e menaxhimit të zonës së domenit: A dhe MX. Ju gjithashtu mund të përdorni DNS-në tuaj duke vendosur delegimin në llogari personale regjistruesi i emrit tuaj të domenit.

Vendosja e një zone domeni kur përdorni një regjistrues DNS

Shënim! Koha e hyrjes Cilësimet e DNS zgjat nga disa orë deri në një javë. Derisa cilësimet të hyjnë në fuqi, serveri i postës nuk do të funksionojë siç duhet.

Për ta instaluar, shkarkoni nga faqja e internetit iRedMail versioni aktual. Aktualisht është 0.9.9.

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

Pastaj shpaketoni arkivin e shkarkuar.

# tar xjf iRedMail-0.9.9.tar.bz2

Shpaketimi i arkivit

Dhe shkoni te dosja e krijuar.

# cd iRedMail-0.9.9

Dosja e instaluesit iRedMail

Kontrollimi i përmbajtjes së dosjes

Përmbajtja e dosjes

Dhe ekzekutoni skriptin e instalimit iRedMail.

# bash iRedMail.sh

Do të fillojë instalimi i sistemit të postës. Gjatë procesit të instalimit do t'ju duhet t'i përgjigjeni një numri pyetjesh. Ne pranojmë të fillojmë instalimin.

Filloni instalimin

Zgjedhja e drejtorisë së instalimit

Tani ju duhet të zgjidhni një server në internet. Nuk ka shumë zgjedhje, kështu që ne zgjedhim NGINX.

Zgjedhja e një serveri në internet

Tani ju duhet të zgjidhni një server të bazës së të dhënave që do të instalohet dhe konfigurohet për të punuar me sistemin e postës. Zgjidhni MariaDB.

Zgjedhja e një serveri të bazës së të dhënave

Vendosni fjalëkalimin rrënjë për bazën e të dhënave.

Krijimi i një fjalëkalimi rrënjë të bazës së të dhënave

Tani ne tregojmë domenin tonë të postës elektronike.

Krijimi i një domeni poste

Pastaj krijojmë një fjalëkalim për kutinë postare të administratorit [email protected].

Krijimi i një fjalëkalimi të administratorit të postës

Përzgjedhja e komponentëve të uebit

Konfirmoni cilësimet e specifikuara.

Po konfirmon cilësimet

Instalimi ka filluar.

Instalimi

Pasi të përfundojë instalimi, konfirmoni krijimin e rregullit iptables për SSH dhe rinisni murin e zjarrit. iRedMail punon me iptables. Në Ubuntu, mjeti më i zakonshëm i menaxhimit të murit të zjarrit është UFW. Nëse për një arsye ose një tjetër keni një nevojë të tillë, atëherë instaloni UFW (apt install ufw) dhe shtoni rregulla në mënyrë që UFW (shembull: ufw lejon "Nginx Full" ose ufw allow Postfix) të mos bllokojë funksionimin e serverit të postës. Ju mund të shikoni listën e rregullave të disponueshme duke ekzekutuar komandën: ufw app list . Pastaj aktivizoni UFW: ufw aktivizoni.

Krijimi i një rregulli iptables

Rinisja e murit të zjarrit

Kjo përfundon instalimin e iRedMail. Sistemi na dha adresat e ndërfaqes në internet dhe kredencialet e hyrjes. Për të aktivizuar të gjithë komponentët e sistemit të postës, duhet të rindizni serverin.

Përfundimi i instalimit

Le të rinisim.

# rindezje

Cilësimet

Së pari ju duhet të siguroheni që gjithçka funksionon. Le të përpiqemi të identifikohemi në panelin e kontrollit iReadAdmin në https://domain/iredadmin. Hyni [email protected], fjalëkalimi i krijuar gjatë instalimit. Ekziston një ndërfaqe në gjuhën ruse.

Siç mund ta shihni, gjithçka funksionon. Kur hyni në iRedAdmin, ka shumë të ngjarë të keni marrë një gabim sigurie në lidhje me certifikatën. Kjo ndodh sepse iRedMail ka një certifikatë të integruar të vetë-nënshkruar, për të cilën ankohet shfletuesi. Për të zgjidhur këtë problem, duhet të instaloni një certifikatë të vlefshme SSL. Nëse keni një të blerë, mund ta instaloni. Në shembull, unë do të instaloj SSL falas nga Let's Encrypt.

Instalimi i një certifikate Let's Encrypt SSL

Ne do ta instalojmë certifikatën duke përdorur programin certbot. Së pari, le të shtojmë një depo.

# add-apt-repository ppa:certbot/certbot

Pastaj do të instalojmë vetë certboot me komponentët e nevojshëm.

# apt instaloni python-certbot-nginx

Ne marrim një certifikatë.

# certbot --nginx -d domain.ru

Pas ekzekutimit të komandës, sistemi do t'ju kërkojë të shkruani adresën tuaj të emailit, shkruani. Më pas ka shumë të ngjarë të merrni një gabim se nuk është e mundur të gjesh bllokun e serverit për të cilin u krijua certifikata. Në këtë rast, kjo është normale, pasi ne nuk kemi asnjë bllok server. Gjëja kryesore për ne është të marrim një certifikatë.

Marrja e një certifikate

Siç mund ta shohim, certifikata u mor me sukses dhe sistemi na tregoi shtigjet drejt vetë certifikatës dhe çelësit. Janë pikërisht ato që na duhen. Në përgjithësi, kemi marrë 4 skedarë që do të ruhen në dosjen "/etc/letsencrypt/live/domain". Tani duhet të informojmë serverin në internet për certifikatën tonë, domethënë të zëvendësojmë certifikatën e integruar me atë që sapo morëm. Për ta bërë këtë, duhet të modifikojmë vetëm një skedar.

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

Dhe ne ndryshojmë dy rreshtat e fundit në të.

Zëvendësimi i certifikatës SSL

Ne i ndryshojmë shtigjet në skedar në shtigjet që na ka thënë sistemi gjatë marrjes së certifikatës.

Zëvendësimi i një certifikate SSL

Dhe rinisni NGINX.

# rinis shërbimi nginx

Tani le të përpiqemi të regjistrohemi përsëri në iRedAdmin.

Verifikimi i certifikatës SSL

Nuk ka më gabime të certifikatës. Certifikata është e vlefshme. Mund të klikoni në bllokues dhe të shihni vetitë e tij. Kur certifikata skadon, certboot duhet ta rinovojë atë automatikisht.

Tani do të raportojmë për certifikatën Dovecot dhe Postfix. Për ta bërë këtë, ne do të modifikojmë dy skedarë konfigurimi. Ne bejme:

# nano /etc/dovecot/dovecot.conf

Gjetja e bllokut:

#SSL: Cilësimet globale.

Dhe ne e ndryshojmë certifikatën e regjistruar atje me tonën.

Certifikatë zëvendësimi për Dovecot

Kushtojini vëmendje edhe rreshtit "ssl_protocols". Vlera e tij duhet të jetë "!SSLv3", përndryshe do të merrni gabimin "Kujdes: SSLv2 nuk mbështetet nga OpenSSL. Ju lutemi, konsideroni ta hiqni atë nga ssl_protocols" kur rinisni Dovecot.

# nano /etc/postfix/main.cf

Gjetja e bllokut:

# Çelësi SSL, certifikata, CA

Dhe ne i ndryshojmë shtigjet në të në rrugën drejt skedarëve të certifikatës sonë.

Zëvendësimi i një certifikate për Postfix

Kjo përfundon instalimin e certifikatës. Është e nevojshme të rinisni Dovecot dhe Postfix, por është më mirë të rindizni serverin.

# rinis shërbimi pëllumbash

# rindezje

Instalimi i PHPMyAdmin

Ky hap është opsional, por unë rekomandoj ta bëni atë dhe të instaloni PHPMyAdmin për lehtësinë e punës me bazat e të dhënave.

# apt instaloni phpmyadmin

Instaluesi do të pyesë se me cilin server ueb të konfigurojë PHPMyAdmin për të punuar, pasi NGINX nuk është në këtë listë, thjesht shtypni TAB dhe vazhdoni.

Instalimi i PHPMyAdmin

Pas përfundimit të instalimit, në mënyrë që phpmyadmin të funksionojë, duhet të bëni një lidhje simbolike në drejtorinë me të cilën funksionon NGINX si parazgjedhje.

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

Dhe ne përpiqemi të shkojmë në https://domain/phpmyadmin/

PHPMyAdmin po funksionon. Lidhja është e mbrojtur me një certifikatë, nuk ka gabime. Shkoni përpara. Le të krijojmë një administrator të bazës së të dhënave MySQL (MariaDB).

# mysql

Dhe arrijmë te tastiera e menaxhimit të MariaDB. Më pas, ne ekzekutojmë komandat një nga një:

MariaDB > KRIJO PERDORUES "admin"@"localhost" Identifikuar me "fjalëkalim";
MariaDB > DHËNO TË GJITHA PRIVILETET NË *.* "admin"@"localhost" ME OPTION GRANT;
MariaDB > PRIVILEGJET FLUSH;

Krijimi i një përdoruesi MySQL

Gjithçka është në rregull, identifikimi është i plotë. PHPMyAdmin është gati për të filluar.

Instalimi i PostfixAdmin

Në parim, PostfixAdmin, si PHPMyAdmin, nuk ka nevojë të instalohet. Serveri i postës do të funksionojë mirë pa këto komponentë. Por atëherë nuk do të jeni në gjendje të krijoni pseudonime postare. Nëse nuk ju nevojitet kjo, atëherë mund t'i kaloni me siguri këto seksione. Nëse ende keni nevojë për pseudonime, atëherë keni dy mundësi: të blini versionin me pagesë të iReaAdmin ose të instaloni PostfixAdmin. Sigurisht, ju mund ta bëni këtë pa softuer shtesë, duke regjistruar pseudonime në bazën e të dhënave me dorë, por kjo nuk është gjithmonë e përshtatshme dhe nuk është e përshtatshme për të gjithë. Unë rekomandoj përdorimin e PostfixAdmin; ne do të shikojmë instalimin dhe integrimin e tij me iRedMail tani. Le të fillojmë instalimin:

# apt instalo postfixadmin

Ne pajtohemi dhe krijojmë një fjalëkalim për bazën e të dhënave të sistemit të programit.

Instalimi i PostfixAdmin

Instalimi i PostfixAdmin

Ne krijojmë një lidhje simbolike në të njëjtën mënyrë si instalimi i PHPMyAdmin.

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

Ne e bëjmë përdoruesin në emër të të cilit hapet serveri në internet pronar i drejtorisë. Në rastin tonë, NGINX lëshohet si përdorues www-data.

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

Tani duhet të modifikojmë skedarin e konfigurimit PostfixAdmin dhe të shtojmë informacione rreth bazës së të dhënave që përdor iRedAdmin. Si parazgjedhje kjo bazë të dhënash quhet vmail. Nëse shkoni te PHPMyAdmin, mund ta shihni atje. Dhe kështu, në mënyrë që PostfixAdmin të mund të bëjë ndryshime në bazën e të dhënave, ne e regjistrojmë atë në konfigurimin PostfixAdmin.

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

Ne gjejmë linjat:

$CONF ["lloji_bazë e të dhënave"] = $dbtype;
$CONF["database_host"] = $dbserver;
$CONF["database_user"] = $dbuser;
$CONF["pass_password"] = $dbpass;
$CONF [" emri_bazës së të dhënave"] = $dbname;

Dhe le ta sjellim në mendje:

$CONF [ " database_type " ] = " mysqli " ; # Lloji i bazës së të dhënave
$CONF["database_host"] = "localhost"; # Pritësi i serverit të bazës së të dhënave
$CONF["database_user"] = "admin"; # Hyni me të drejta për të shkruar në bazën e të dhënave vmail. Ju mund të përdorni administratorin e krijuar më parë
$CONF["database_password"] = "fjalëkalim"; # Fjalëkalimi për përdoruesin e specifikuar më sipër
$CONF [ " emri i bazës së të dhënave " ] = " vmail " ; # Emri i bazës së të dhënave iRedMail

Futja e informacionit për bazën e të dhënave

Nëse planifikoni të përdorni klientin e postës në ueb SOGo, atëherë duhet të bëni një hap tjetër, domethënë të ndryshoni kriptimin PostfixAdmin në artikullin $CONF["encrypt"] nga "md5crypt" në "dovecot:SHA512-CRYPT" . Nëse nuk e bëni këtë, atëherë kur përpiqeni të identifikoheni në SOGo si përdorues i krijuar në PostfixAdmin, do të merrni një gabim: hyrje ose fjalëkalim i gabuar.

Ndryshimi i llojit të kriptimit

Tani, në mënyrë që të përfundoni me sukses instalimin dhe të mos merrni gabime, duhet të ekzekutoni një pyetje në bazën e të dhënave. Është i përshtatshëm për ta bërë këtë përmes PHPMyAdmin. Zgjidhni bazën e të dhënave vmail dhe shkoni te skeda SQL. Në dritare futemi:

DROP INDEX domain në kutinë postare;
DROP INDEX domain në pseudonim;
ALTER TABLE alias SHTO KOLONA teksti `goto` JO NULL;

Pyetja e bazës së të dhënave

Dhe klikoni "Përpara". Tani jemi të gjithë gati, mund të shkojmë në ndërfaqen e internetit PostfixAdmin dhe të përfundojmë instalimin. Për ta bërë këtë, duhet të shkruani në shfletuesin tuaj: https://domain/postfixadmin/setup.php.

Duhet të shfaqen sa vijon:

Instalimi i PostfixAdmin

Nëse gjithçka është bërë sipas udhëzimeve, atëherë nuk duhet të ketë gabime. Nëse ka, atëherë ato duhet të eliminohen, përndryshe sistemi nuk do t'ju lejojë të vazhdoni. Vendosni fjalëkalimin e instalimit dhe klikoni "Generate password hash". Sistemi do të gjenerojë një hash fjalëkalimi, i cili duhet të futet në parametrin $CONF["setup_password"].

Përfundimi i instalimit të PostfixAdmin

Ndryshimi i cilësimeve të skedarit të konfigurimit

Tani futni fjalëkalimin e krijuar rishtazi dhe krijoni administratorin PostfixAdmin. Është më mirë të mos krijoni një administrator me hyrjen e postmasterit, pasi mund të ketë probleme me hyrjen në panelin e administrimit iRedAdmin.

Krijimi i një administratori PostfixAdmin

Kjo është ajo, administratori është krijuar. Ju mund të identifikoheni.

Ju lutemi vini re se nga pikëpamja e sigurisë, është më mirë të riemërtoni ose fshini skedarin setup.php në drejtorinë postfixadmin.

Shkoni te: https://domain/postfixadmin/ dhe futni kredencialet e krijuara rishtazi. Në PostfixAdmin, si dhe në iRedAdmin, gjuha ruse është e disponueshme. Mund ta zgjidhni gjatë autorizimit.

Ne po përpiqemi të krijojmë një kuti postare të përdoruesit.

Aktivizimi/Çaktivizimi i moduleve iRedMail

iRedAPD është përgjegjës për menaxhimin e moduleve iRedMail. Ka një skedar konfigurimi në të cilin janë regjistruar modulet e punës. Nëse nuk keni nevojë për një modul të veçantë, mund ta hiqni atë nga skedari i konfigurimit dhe ai do të ndalojë së punuari. Ne bejme:

# nano /opt/iredapd/settings.py

Gjeni rreshtin "shtojca" dhe hiqni përbërësit që nuk ju nevojiten prej tij. Unë do të heq komponentin "greylisting". Natyrisht, mbron në mënyrë mjaft efektive kundër spamit, por letrat e nevojshme shpesh nuk arrijnë.

Greylist është një teknologji automatike e mbrojtjes së spamit të bazuar në analizën e sjelljes së serverit të dërguesit të postës. Kur aktivizohet "lista gri", serveri refuzon të pranojë një letër nga një adresë e panjohur për herë të parë, duke raportuar një gabim të përkohshëm. Në këtë rast, serveri dërgues duhet të përsërisë dërgimin më vonë. Programet spammer zakonisht nuk e bëjnë këtë. Nëse letra dërgohet përsëri, ajo shtohet në listë për 30 ditë dhe shkëmbimi i postës ndodh herën e parë. Vendosni vetë nëse do ta përdorni këtë modul apo jo.

Aktivizimi/Çaktivizimi i moduleve të postës

Pasi të bëni ndryshime, duhet të rinisni iRedAPD.

# rinis shërbimi iredapd

Testimi i serverit të postës

Kjo përfundon konfigurimin e serverit të postës iRedMail. Mund të vazhdoni në fazën përfundimtare - testimin. Le të krijojmë dy kuti postare. Për të kontrolluar njërën përmes iRedAdmin, të dytën përmes PostfixAdmin dhe për të dërguar një letër nga një kuti postare në tjetrën dhe anasjelltas. Në iRedAdmin ne do të krijojmë një kuti postare [email protected]. Në PostfixAdmin - [email protected]

Krijimi i një përdoruesi në iRedAdmin

Krijimi i një përdoruesi në PostfixAdmin

Ne kontrollojmë që përdoruesit janë krijuar.

Nëse i kushtoni vëmendje kolonës "Për" në listën e kutive postare PostfixAdmin, do të vini re ndryshimin midis kutive postare të krijuara në iRedAdmin dhe PostfixAdmin. Kutitë postare të krijuara në iRedAdmin shënohen si "Vetëm Përpara", dhe ato të krijuara në PostfixAdmin shënohen si "Kutia postare". Në fillim nuk munda ta kuptoja për një kohë të gjatë pse po ndodhte kjo dhe cili ishte ndryshimi midis tyre dhe më në fund vura re një gjë. Kutitë postare në iRedAdmin krijohen pa pseudonime, dhe kutitë postare në PostfixAdmin krijohen me një pseudonim për veten e tyre.

Dhe nëse këto pseudonime fshihen, atëherë kutitë postare do të shfaqen si ato të krijuara në iRedAdmin "Vetëm përpara".

Heqja e pseudonimeve

Pseudonimet janë hequr. Po kontrollon PostfixAdmin.

Siç mund ta shihni, të gjitha kutitë janë bërë "Vetëm përpara". Në të njëjtën mënyrë, nëse krijoni një pseudonim për veten tuaj në një kuti postare të krijuar në iRedAdmin, ai do të bëhet "Kutia postare". Në parim, kjo nuk ndikon në performancën e postës në asnjë mënyrë. E vetmja gjë është se nuk do të jeni në gjendje të krijoni një pseudonim në një kuti postare të krijuar në PostfixAdmin. Në vend që të krijoni një pseudonim, do t'ju duhet të redaktoni një ekzistues. Duke folur për pseudonimet, në version i ri iRedMail duhet të bëjë një ndryshim në një nga hartat Postfix që trajton pseudonimet. Dhe nëse nuk e bëni këtë, pseudonimet e krijuara nuk do të funksionojnë. Për ta bërë këtë, duhet të korrigjoni sa vijon në skedarin /etc/postfix/mysql/virtual_alias_maps.cf:

Ne bejme:

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

Dhe ne e rregullojmë atë.

Vendosja e pseudonimeve

Rinisni Postfix:

# rinis shërbimi postfiks

Pas kësaj, gjithçka duhet të funksionojë.

Dhe kështu, le të fillojmë të kontrollojmë postën. Ne do të hyjmë në kutinë postare të përdoruesit1 nëpërmjet Roundcube, dhe në kutinë postare të përdoruesit2 nëpërmjet SOGo dhe do të dërgojmë një letër nga kutia postare e përdoruesit1 tek përdoruesi2 dhe mbrapa.

Dërgimi i një emaili me Roundcube

Marrja e një letre në SOGo

Dërgimi i një emaili te SOGo

Marrja e një letre në Roundcube

Gjithçka funksionon pa asnjë problem. Dorëzimi i letrës zgjat nga dy deri në pesë sekonda. Në të njëjtën mënyrë, letrat dorëzohen në mënyrë të përsosur në serverët Yandex dhe mail.ru (të testuara).

Tani le të kontrollojmë pseudonimet. Le të krijojmë një kuti postare user3 dhe të bëjmë një pseudonim nga kutia postare user1 në kutinë postare user2. Dhe ne do të dërgojmë një letër nga kutia postare user3 në kutinë postare user1. Në këtë rast, letra duhet të arrijë në kutinë postare të përdoruesit2.

Krijimi i një pseudonimi

Dërgimi i një letre nga kutia postare e përdoruesit3 në kutinë postare të përdoruesit1

Marrja e një letre në kutinë postare të përdoruesit2

Puna e pseudonimeve është gjithashtu e mirë.

Le të testojmë funksionimin e serverit të postës përmes lokalit klienti i postës. Për shembull, merrni parasysh Mozilla Thunderbird. Le të krijojmë dy përdorues të tjerë: klient1 dhe klient2. Ne do të lidhim një kuti postare përmes IMAP, tjetrën përmes POP3 dhe do të dërgojmë një letër nga një kuti postare në tjetrën.

Lidhja IMAP

Lidhja përmes POP3

Ne dërgojmë një letër nga Klienti 1 te Klienti 2.

Dërgimi nga klienti 1

Faturë tek klienti 2

Dhe në rend të kundërt.

Dërgimi nga klienti 2

Dëftesa për Klientin 1

Gjithçka po funksionon.

Nëse shkoni në adresën: https://domain/netdata, mund të shihni grafikët e gjendjes së sistemit.

konkluzioni

Kjo përfundon instalimin, konfigurimin dhe testimin e sistemit të postës iRedMail. Si rezultat, ne morëm një server poste plotësisht falas, të plotë, me një certifikatë të vlefshme SSL, dy klientë të ndryshëm të postës në ueb, dy panele kontrolli, si dhe antispam dhe antivirus të integruar në postë. Nëse dëshironi, në vend të klientëve të postës në ueb, mund të përdorni klientët lokalë të postës si p.sh Microsoft Outlook ose Mozilla Thunderbird. Nëse nuk planifikoni të përdorni klientët e postës në internet, nuk mund t'i instaloni fare, në mënyrë që të mos mbingarkoni serverin ose të instaloni një gjë që ju pëlqen më shumë. Unë personalisht më pëlqen më shumë SOGo sepse ndërfaqja e tij është e optimizuar pajisje celulare, duke e bërë atë shumë të përshtatshëm për t'u parë email nga një smartphone. E njëjta gjë vlen edhe për NetData dhe iRedAdmin, nëse nuk planifikoni ta përdorni, është më mirë të mos e instaloni. Ky sistem poste nuk kërkon shumë burime. E gjithë kjo funksionon në një server VPS me 1024 MB kujtesë e gjallë dhe një procesor virtual. Nëse keni ndonjë pyetje në lidhje me këtë sistem postar, shkruani në komente.

P.S. Gjatë testimit të këtij produkti në sisteme të ndryshme operative me 1 GB RAM (Ubuntu, Debian, CentOS), rezultoi se 1 GB nuk mjafton që ClamAV të funksionojë. Pothuajse në të gjitha rastet, kur përdorni 1 GB memorie, antivirusi përmendi një gabim në lidhje me bazën e të dhënave. Në të njëjtën kohë, në sistemet operative Debian dhe Ubuntu, antivirusi thjesht nuk skanoi postën që kalonte përmes serverit, përndryshe gjithçka funksionoi mirë. Në CentOS situata ishte pak më ndryshe. Shërbimi Clamd e rrëzoi plotësisht sistemin, duke e bërë të pamundur funksionimin normal të serverit. Kur përpiqej të regjistrohej në ndërfaqet e internetit, NGINX prodhoi periodikisht 502 dhe 504 gabime. Posta dërgohej gjithashtu çdo herë tjetër. Për më tepër, nëse shtojmë deri në 2 GB RAM, atëherë në të gjitha rastet nuk ka pasur probleme me funksionimin e antivirusit dhe serverit në tërësi. ClamAV skanoi postën që kalonte përmes serverit të postës, për të cilin shkruante në regjistra. Kur përpiqeni të dërgoni një virus si një bashkëngjitje, dërgimi u bllokua. Konsumi i memories ishte afërsisht 1,2 - 1,7 GB.

Nginx është një server i vogël, shumë i shpejtë, mjaft funksional në internet dhe server proxy mail, i zhvilluar nga Igor Sysoev (rambler.ru). Për shkak të konsumit shumë të ulët të burimeve të sistemit dhe shpejtësisë së funksionimit, si dhe fleksibilitetit të konfigurimit, ueb Serveri Nginx shpesh përdoret si frontend për serverë më të rëndë, si p.sh Apache, në projekte me ngarkesë të lartë. Opsioni klasik është kombinimi, Nginx - Apache - FastCGI. Duke punuar në një skemë të tillë, Serveri Nginx, pranon të gjitha kërkesat që vijnë nëpërmjet HTTP, dhe në varësi të konfigurimit dhe vetë kërkesës, vendos nëse do ta përpunojë vetë kërkesën dhe t'i japë klientit një përgjigje të gatshme ose ta dërgojë kërkesën për përpunim në një nga backend-et ( Apache ose FastCGI).

Siç e dini, serveri Apache përpunon çdo kërkesë në një proces të veçantë (fije), i cili, duhet thënë, konsumon një sasi mjaft të vogël të burimeve të sistemit, nëse ka 10-20 procese të tilla, është e pakuptimtë, dhe nëse ka 100-500 ose më shumë, sistemi bëhet jo argëtues.

Le të përpiqemi të imagjinojmë një situatë të ngjashme. Supozoni më Apache vjen 300 Kërkesat HTTP nga klientët, 150 klientë janë në linja të shpejta me qira dhe 150 të tjerët janë në kanale interneti relativisht të ngadalta, edhe nëse jo në modem. Çfarë po ndodh në këtë situatë? Dhe ndodh si më poshtë: serveri në internet Apache, për të përpunuar këto 300 lidhje, krijon një proces (thread) për secilën, ai do të gjenerojë përmbajtje shpejt dhe 150 klientë të shpejtë do të marrin menjëherë rezultatin e kërkesave të tyre, proceset që u shërbejnë atyre. do të vriten dhe burimet do të lëshohen, dhe 150 janë të ngadaltë dhe do të marrin rezultatet e kërkesave të tyre ngadalë, për shkak të kanalit të ngushtë të internetit, si rezultat i të cilit 150 procese do të varen në sistem Apache, duke pritur që klientët të marrin përmbajtjen e gjeneruar nga serveri në internet, duke gllabëruar shumë burime të sistemit. Natyrisht, situata është hipotetike, por mendoj se thelbi është i qartë. Pakoja ndihmon në korrigjimin e situatës së përshkruar më sipër. Pasi lexon të gjithë kërkesën nga klienti, ai e dorëzon për përpunim Apache, e cila nga ana tjetër gjeneron përmbajtje dhe i kthen përgjigjen e gatshme Nginx sa më shpejt që të jetë e mundur, pas së cilës mund ta vrasë procesin me një ndërgjegje të pastër dhe të çlirojë burimet e sistemit që zë. Ueb serveri Nginx, duke marrë rezultatin e kërkesës nga Apache, e shkruan atë në një buffer apo edhe në një skedar në disk dhe mund t'ia japë klientëve të ngadaltë për aq kohë sa të dëshirohet, ndërkohë që proceset e tij të punës konsumojnë aq pak burime sa .. "madje është qesharake të flasësh për të" ©. :) Kjo skemë kursen ndjeshëm burimet e sistemit, e përsëris, por proceset e punëtorëve Nginx konsumojnë një sasi të vogël burimesh, kjo është veçanërisht e vërtetë për projektet e mëdha.

Dhe kjo është vetëm një pjesë e vogël e asaj që mund të bëjë serveri Nginx; mos harroni për aftësitë e ruajtjes së të dhënave dhe punës me të memcached. Unë do të jap një listë të kryesoreve funksionalitetin Serveri në internet Nginx.

Funksionaliteti i serverit Nginx si një server HTTP

• Mjekimi përmbajtje statike, skedarët e indeksit, listat e drejtorive, cache e përshkruesit të skedarëve të hapur;
• Proxying i përshpejtuar me caching, shpërndarje të ngarkesës dhe tolerancë ndaj gabimeve;
• Mbështetje e përshpejtuar FastCGI serverë me caching, shpërndarje të ngarkesës dhe tolerancë ndaj gabimeve;
• Struktura modulare, mbështetje për filtra të ndryshëm (SSI, XSLT, GZIP, rifillimi, përgjigjet e copëtuara);
• Mbështetje për shtesat SSL dhe TLS SNI;
• i bazuar në IP ose Bazuar në emër serverë virtualë;
• Puna me KeepAlive dhe lidhjet me tubacione;
• Aftësia për të konfiguruar çdo afat kohor, si dhe numrin dhe madhësinë e buferave, në nivel Server Apache;
• Kryerja e veprimeve të ndryshme në varësi të adresës së klientit;
• Ndryshimi i URI-ve duke përdorur shprehje të rregullta;
• Faqet e gabimeve speciale për 4xx dhe 5xx;
• Kufizimi i aksesit bazuar në adresën ose fjalëkalimin e klientit;
• Vendosja e formateve të skedarëve të regjistrave, rrotullimi i regjistrave;
• Kufizimi i shpejtësisë së përgjigjes ndaj klientit;
• Kufizimi i numrit të lidhjeve dhe kërkesave të njëkohshme;
• Mbështet metodat PUT, DELETE, MKCOL, COPY dhe MOVE;
• Ndryshimi i cilësimeve dhe përditësimi i serverit pa ndërprerë punën;
• I integruar Perl;

Funksionaliteti i serverit Nginx si një server proxy postar

• Përcjellja në prapavijën IMAP/POP3 duke përdorur një server të jashtëm vërtetimi HTTP;
• Kontrollimi i përdoruesit SMTP në të jashtme Server HTTP vërtetimi dhe përcjellja në një server të brendshëm SMTP;
• Mbështet metodat e mëposhtme të vërtetimit:
  • POP3 - USER/PASS, APOP, AUTH LOGIN/PLAIN/CRAM-MD5;
  • IMAP - LOGIN, AUTH LOGIN/PLAIN/CRAM-MD5;
  • SMTP - AUTH LOGI/ PLAIN/CRAM-MD5;
• mbështetje SSL;
• mbështetje STARTTLS dhe STLS;

Sistemet operative dhe platformat e mbështetura nga serveri në internet Nginx

• FreeBSD, nga 3 në 8 - platforma, i386 dhe amd64;
• Linux, nga 2.2 në 2.6 - platforma i386; Linux 2.6 - amd64;
• Platformat Solaris 9 - i386 dhe sun4u; Platformat Solaris 10 - i386, amd64 dhe sun4v;
• platformat MacOS X ppc, i386;
• Windows XP, Windows Server 2003; (aktualisht në testim beta)

Arkitektura dhe shkallëzueshmëria e serverit Nginx

• Procesi kryesor (master), disa procese pune (të konfiguruara në skedarin e konfigurimit) që funksionojnë nën një përdorues të paprivilegjuar;
• Mbështetje për metodat e mëposhtme të përpunimit të lidhjes:
  • zgjidhni është një metodë standarde. Moduli përkatës Nginx ndërtohet automatikisht nëse nuk gjendet një metodë më efikase në një platformë të caktuar. Ju mund ta detyroni ndërtimin e një moduli të caktuar të aktivizohet ose çaktivizohet duke përdorur opsionet e konfigurimit --with-select_module ose --without-select_module.
  • sondazhi është metoda standarde. Moduli përkatës Nginx ndërtohet automatikisht nëse nuk gjendet një metodë më efikase në një platformë të caktuar. Ju mund ta detyroni ndërtimin e një moduli të caktuar të aktivizohet ose çaktivizohet duke përdorur opsionet e konfigurimit --with-poll_module ose --without-poll_module.
  • rradhë - metodë efektive, përdoret në sistemet operative FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0 dhe MacOS X. Kur përdoret në makineritë me procesorë të dyfishtë që përdorin MacOS X, mund të shkaktojë panik kernel.
  • epoll është një metodë efikase e përdorur në Linux 2.6+. Disa shpërndarje, të tilla si SuSE 8.2, kanë arna për të mbështetur epoll në kernel 2.4.
  • rtsig - sinjale në kohë reale, një metodë efikase e përdorur në Linux 2.2.19+. Si parazgjedhje, nuk mund të ketë më shumë se 1024 sinjale në radhë për të gjithë sistemin. Kjo nuk mjafton për serverët me ngarkesë të lartë; madhësia e radhës duhet të rritet duke përdorur parametrin e kernelit /proc/sys/kernel/rtsig-max. Megjithatë, që nga Linux 2.6.6-mm2, ky opsion nuk është më i disponueshëm, përkundrazi çdo proces ka një radhë sinjali të veçantë, madhësia e së cilës përcaktohet duke përdorur RLIMIT_SIGPENDING.
  • Kur radha është plot, server nginx e rivendos atë dhe përpunon lidhjet duke përdorur metodën e sondazhit derisa situata të kthehet në normale.
  • /dev/poll është një metodë efektive, e mbështetur në sistemet operative Solaris 7 11/99+, HP/UX 11.22+ (eventport), IRIX 6.5.15+ dhe Tru64 UNIX 5.1A+.
  • eventport - portet e ngjarjeve, një metodë efektive e përdorur në Solaris 10. Përpara përdorimit, duhet të instaloni një patch për të shmangur panikun e kernelit.
• Përdorimi i aftësive të metodës kqueue si EV_CLEAR, EV_DISABLE (për të çaktivizuar përkohësisht një ngjarje), NOTE_LOWAT, EV_EOF, numri i të dhënave të disponueshme, kodet e gabimit;
• Punon me sendfile (FreeBSD 3.1+, Linux 2.2.+, Mac OS X 10.5+), sendfile64 (Linux 2.4.21+) dhe sendfilev (Solaris 8 7/01+);
• Mbështetje për pranimin e filtrave (FreeBSD 4.1+) dhe TCP_DEFER_ACCEPT (Linux 2.4+);
• 10,000 lidhje joaktive HTTP që mbajnë gjallë konsumojnë afërsisht 2.5M memorie;
• Numri minimal i operacioneve të kopjimit të të dhënave;

NGINX mund të përdoret jo vetëm si një server në internet ose http-proxy, por edhe për proxying postën përmes protokolleve SMTP, IMAP, POP3. Kjo do t'ju lejojë të konfiguroni:

• Një pikë e vetme hyrëse për një sistem emaili të shkallëzuar.
• Balancimi i ngarkesës midis të gjithë serverëve të postës.

Në këtë artikull, instalimi kryhet në sallën e operacionit. Sistemi Linux. Si një shërbim poste tek i cili dërgohen kërkesat, mund të përdorni postfix, exim, dovecot, exchange, montim iredmail dhe më shumë.

Parimi i funksionimit

NGINX pranon kërkesa dhe vërteton në serverin e uebit. Në varësi të rezultatit të verifikimit të hyrjes dhe fjalëkalimit, përfaqësuesi do të kthejë një përgjigje me disa tituj.

Në rast suksesi:

Kështu, ne përcaktojmë serverin dhe portin e serverit të postës bazuar në vërtetimin. Kjo ofron shumë mundësi me njohuri të përshtatshme të gjuhëve të programimit.

Në rast dështimi:

Në varësi të rezultatit të vërtetimit dhe kokës, klienti ridrejtohet në serverin e postës që na nevojitet.

Përgatitja e serverit

Le të bëjmë disa ndryshime në cilësimet e sigurisë së serverit.

SELinux

Çaktivizoni SELinux nëse përdorim CentOS ose nëse përdorim këtë sistem siguria në Ubuntu:

vi /etc/selinux/config

SELINUX=i çaktivizuar

Firewall

Nëse përdorim firewalld (i parazgjedhur në CentOS):

firewall-cmd --i përhershëm --add-port=25/tcp --add-port=110/tcp --add-port=143/tcp

firewall-cmd --ringarkoni

Nëse përdorim iptables (i parazgjedhur në Ubuntu):

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

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

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

apt-get install iptables-persistent

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

* në këtë shembull kemi lejuar SMTP (25), POP3 (110), IMAP (143).

Instalimi i NGINX

Varet nga sistemi operativ Instalimi i NGINX është pak më ndryshe.

ose Linux Centos:

yum instaloni nginx

ose Linux Ubuntu:

apt instaloni nginx

Ne lejojmë fillimin automatik të shërbimit dhe e nisim atë:

systemctl aktivizoni nginx

systemctl start nginx

Nëse NGINX është instaluar tashmë në sistem, kontrolloni me cilat module punon:

Do të marrim një listë opsionesh me të cilat është ndërtuar serveri në internet - ndër to duhet të shohim --with-mail . Nëse moduli i kërkuar nuk është aty, duhet të përditësoni nginx

Konfigurimi i NGINX

Hapni skedarin e konfigurimit nginx dhe shtoni opsionin e postës:

vi /etc/nginx/nginx.conf

postë (

auth_http localhost:80/auth.php;

Serveri (
dëgjo 25;
protokolli smtp;
smtp_auth login i thjeshtë cram-md5;
}

Serveri (
dëgjo 110;
protokolli pop3;

}

Serveri (
dëgjo 143;
imazhi i protokollit;
}
}

* Ku:

• server_name është emri i serverit të postës që do të shfaqet në përshëndetjen SMTP.
• auth_http - serveri në internet dhe URL-ja për kërkesën e vërtetimit.
• proxy_pass_error_message - lejon ose mohon shfaqjen e një mesazhi kur vërtetimi dështon.
• listen - port në të cilën dëgjohen kërkesat.
• protokolli - protokolli i aplikacionit për të cilin po dëgjon porti përkatës.
• smtp_auth - metodat e disponueshme të vërtetimit për SMTP.
• pop3_auth - metodat e disponueshme të vërtetimit për POP3.

Në seksionin http - server shtoni:

Serveri (
dëgjo 80 default_server;
dëgjo [::]:80 default_server;
...

Vendndodhja ~ \.php$ (
vendos $root_path /usr/share/nginx/html;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $root_path$fastcgi_script_name;
përfshijnë fastcgi_params;
fastcgi_param DOCUMENT_ROOT $root_path;
}
...

Rinisni serverin nginx:

systemctl rinisni nginx

Instalimi dhe konfigurimi i PHP

Për të kryer vërtetimin duke përdorur PHP, duhet të instaloni paketat e mëposhtme në sistemin tuaj.

Nëse CentOS:

yum instaloni php php-fpm

Nëse Ubuntu:

apt-get instaloni php php-fpm

Hapni PHP-FPM:

systemctl aktivizoni php-fpm

systemctl filloni php-fpm

Autentifikimi

Verifikimi i hyrjes dhe fjalëkalimit kryhet nga një skript, shtegu për të cilin specifikohet nga opsioni auth_http. Në shembullin tonë, ky është një skript PHP.

Një shembull i një shablloni zyrtar për një skript të verifikimit të hyrjes dhe fjalëkalimit:

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

* ky skript pranon çdo hyrje dhe fjalëkalim dhe ridrejton kërkesat te serverët 192.168.1.22 dhe 192.168.1.33. Për të vendosur algoritmin e vërtetimit, modifikoni rreshtat 61 - 64. Rreshtat 73 - 77 janë përgjegjës për kthimin e serverëve në të cilët është bërë ridrejtimi - në këtë shembull, nëse identifikimi fillon me karakteret "a", "c", "f ”, “g”, atëherë ridrejtimi do të jetë te serveri mailhost01, përndryshe, te mailhost02. Hartëzimi i emrave të serverëve me adresat IP mund të vendoset në rreshtat 31, 32, përndryshe thirrja do të bëhet duke përdorur emrin e domenit.

Vendosja e një serveri postar

Shkëmbimi i të dhënave midis përfaqësuesit NGINX dhe serverit të postës ndodh në formë e hapur. Është e nevojshme të shtohet mundësia e vërtetimit duke përdorur mekanizmin PLAIN në përjashtim. Për shembull, për të konfiguruar pëllumbat, bëni sa më poshtë:

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

Shtoni rreshtat:

në distancë 192.168.1.11 (
disable_plaintext_auth = nr
}

* në këtë shembull, ne lejuam kërkesat e vërtetimit PLAIN nga serveri 192.168.1.11.

Ne gjithashtu kontrollojmë:

* nëse ssl është vendosur si kërkohet, kontrolli nuk do të funksionojë, pasi rezulton se nga njëra anë serveri lejon kërkesat në tekst të qartë, por kërkon enkriptim ssl.

Rinis shërbimin e Dovecot:

systemctl rinisni pëllumbat

Konfigurimi i klientit

Mund të vazhdoni të kontrolloni cilësimet tona të përfaqësuesit. Për ta bërë këtë, në cilësimet e klientit, specifikoni adresën ose emrin e serverit nginx si IMAP/POP2/SMTP, për shembull:

* në këtë shembull, klienti i postës është konfiguruar të lidhet me serverin 192.168.1.11 nëpërmjet portet e hapura 143 (IMAP) dhe 25 (SMTP).

Enkriptimi

Tani le të konfigurojmë një lidhje SSL. Nginx duhet të ndërtohet me modulin mail_ssl_module - kontrolloni me komandën:

Nëse mungon moduli i kërkuar, ne rindërtojmë nginx.

Pastaj ne redaktojmë skedarin tonë të konfigurimit:

vi /etc/nginx/nginx.conf

postë (
emri i serverit mail.domain.lokal;
auth_http localhost/auth.php;

Proxy_pass_error_message është aktivizuar;

Ssl në;
ssl_certificate /etc/ssl/nginx/public.crt;
ssl_certificate_key /etc/ssl/nginx/private.key;
ssl_ciphers LARTË:!aNULL:!MD5;
ssl_session_cache e ndarë:SSL:10m;
ssl_sesion_timeout 10m;

Serveri (
dëgjo 110;
protokolli pop3;
pop3_auth thjeshtë apop cram-md5;
}

Serveri (
dëgjo 143;
imazhi i protokollit;
}

Arsyeja: Sistemi i sigurisë SELinux është aktivizuar.

Zgjidhja: çaktivizoni ose konfiguroni SELinux.

Nginx po fiton me shpejtësi popullaritet, duke u kthyer nga thjesht një përshpejtues statik i shpërndarjes për Apache në një server në internet plotësisht funksional dhe të zhvilluar, i cili përdoret gjithnjë e më shumë në izolim. Në këtë artikull do të flasim për skenarë interesantë dhe jo standardë për përdorimin e nginx që do t'ju lejojnë të përfitoni sa më shumë nga serveri juaj në internet.

Përfaqësuesi i postës

Le të fillojmë me më të dukshmen - me aftësinë e nginx për të vepruar si një përfaqësues i postës. Ky funksion është i pranishëm në nginx fillimisht, por për disa arsye përdoret në prodhim jashtëzakonisht rrallë; disa njerëz as nuk janë të vetëdijshëm për ekzistencën e tij. Sido që të jetë, nginx mbështet proksimin e protokolleve POP3, IMAP dhe SMTP me metoda të ndryshme vërtetimi, duke përfshirë SSL dhe StartTLS, dhe e bën atë shumë shpejt.

Pse është e nevojshme kjo? Ka të paktën dy përdorime për këtë funksionalitet. Së pari: përdorni nginx si një mburojë kundër spammerëve të bezdisshëm që përpiqen të dërgojnë email të padëshiruar përmes serverit tonë SMTP. Në mënyrë tipike, spammers nuk krijojnë shumë probleme, pasi ato refuzohen shpejt në fazën e vërtetimit, megjithatë, kur ka vërtet shumë prej tyre, nginx do të ndihmojë në kursimin e burimeve të procesorit. Së dyti: përdorni nginx për të ridrejtuar përdoruesit në shumë serverë postarë POP3/IMAP. Natyrisht, një përfaqësues tjetër i postës mund ta trajtojë këtë, por pse t'i mbyllni serverët nëse nginx është instaluar tashmë në pjesën e përparme për të shërbyer përmbajtje statike përmes HTTP, për shembull?

Proxy serveri i postës në nginx nuk është mjaft standard. Ai përdor një shtresë shtesë të vërtetimit të zbatuar duke përdorur HTTP, dhe vetëm nëse përdoruesi e kalon këtë pengesë lejohet të vazhdojë më tej. Ky funksionalitet ofrohet duke krijuar një faqe/skript në të cilin nginx dërgon të dhënat e përdoruesit dhe ai/ajo kthen një përgjigje në formën e OK standardit ose një arsye për refuzim (si "Hyrja ose fjalëkalimi i pavlefshëm"). Skripti funksionon me titujt e mëposhtëm:

Të dhënat e hyrjes së skriptit të vërtetimit HTTP_AUTH_USER: përdoruesi HTTP_AUTH_PASS: fjalëkalimi HTTP_AUTH_PROTOCOL: protokolli i postës (IMAP, POP3 ose SMTP)

Dhe kthen sa vijon:

Dalja e skriptit të vërtetimit HTTP_AUTH_STATUS: OK ose arsyeja e dështimit HTTP_AUTH_SERVER: serveri i vërtetë i postës për të ridrejtuar HTTP_AUTH_PORT: porta e serverit

Një tipar i jashtëzakonshëm i kësaj qasjeje është se ajo mund të përdoret aspak për vërtetim në vetvete, por për të shpërndarë përdoruesit nëpër serverë të ndryshëm të brendshëm, në varësi të emrit të përdoruesit, të dhënave mbi ngarkesën aktuale në serverët e postës, apo edhe duke organizuar balancimin e thjeshtë të ngarkesës. duke përdorur rrumbullakët . Sidoqoftë, nëse thjesht duhet të transferoni përdoruesit në një server të brendshëm të postës, mund të përdorni një cung të zbatuar nga vetë nginx në vend të një skripti të vërtetë. Për shembull, përfaqësuesi më i thjeshtë SMTP dhe IMAP në konfigurimin nginx do të duket kështu:

# vi /etc/nginx/nginx.conf mail ( # Adresa e skriptit të vërtetimit auth_http localhost:8080/auth; # Çaktivizoni komandën XCLIENT, disa serverë të postës nuk e kuptojnë xclient off; serveri i serverit IMAP (dëgjo 143; imazhi i protokollit; përfaqësuesi aktiv; ) # Serveri i serverit SMTP (dëgjo 25; protokolli smtp; përfaqësuesi aktiv;) )

# vi /etc/nginx/nginx.conf http ( # Harta në portin e dëshiruar të serverit të postës në varësi të portit të dërguar në hartën e kokës HTTP_AUTH_PROTOCOL $http_auth_protocol $mailport ( default 25; smtp 25; imap 143; ) # Implementimi i vërtetimit "Script" - kthen gjithmonë OK dhe transferon përdoruesin në serverin e brendshëm të postës, duke vendosur portin e dëshiruar duke përdorur serverin e mësipërm të hartës (dëgjo 8080; vendndodhjen /auth ( add_header "Auth-Status" "OK"; add_header "Auth-Server" "192.168.0.1" ; add_header "Auth-Port" $mailport; kthimi 200; ) ) )

Kjo është e gjitha. Ky konfigurim ju lejon të ridrejtoni përdoruesit në mënyrë transparente në serverin e brendshëm të postës, pa krijuar shpenzime të sipërme në formën e një skripti që është i panevojshëm në këtë rast. Duke përdorur një skript, ky konfigurim mund të zgjerohet ndjeshëm: konfiguroni balancimin e ngarkesës, kontrolloni përdoruesit duke përdorur bazën e të dhënave LDAP dhe kryeni operacione të tjera. Shkrimi i skriptit është përtej qëllimit të këtij artikulli, por është shumë i lehtë për t'u zbatuar edhe me një njohuri kalimtare të PHP dhe Python.

Transmetimi i videos

Është e lehtë të konfigurosh një pritje të rregullt video bazuar në nginx. E tëra çfarë ju duhet të bëni është të ngarkoni videon e transkoduar në një direktori të aksesueshme nga serveri, ta regjistroni atë në konfigurim dhe të konfiguroni luajtësin Flash ose HTML5 në mënyrë që të marrë videon nga kjo direktori. Megjithatë, nëse keni nevojë të vendosni transmetim të vazhdueshëm video nga disa burim i jashtëm ose një kamerë në internet, kjo skemë nuk do të funksionojë dhe do t'ju duhet të shikoni drejt protokolleve speciale të transmetimit.

Ka disa protokolle që zgjidhin këtë problem, më efektivi dhe më i mbështeturi prej tyre është RTMP. Problemi i vetëm është se pothuajse të gjitha implementimet e serverit RTMP vuajnë nga probleme. Serveri zyrtar Adobe Flash Media paguhet. Red5 dhe Wowza janë shkruar në Java, dhe për këtë arsye nuk ofrojnë performanca e kërkuar, Një zbatim tjetër, Erlyvideo, është shkruar në Erlang, i cili është i mirë për një konfigurim grupi, por jo aq efektiv për një server të vetëm.

Unë sugjeroj një qasje të ndryshme - përdorni modulin RTMP për nginx. Ka performancë të shkëlqyeshme dhe gjithashtu do t'ju lejojë të përdorni një server për të shërbyer si ndërfaqen e internetit të faqes ashtu edhe transmetimin e videos. Problemi i vetëm është se ky modul është jozyrtar, kështu që ju do të duhet të ndërtoni vetë nginx me mbështetjen e tij. Për fat të mirë, montimi është kryer në mënyrë standarde:

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

Tani moduli duhet të konfigurohet. Kjo bëhet, si zakonisht, përmes konfigurimit nginx:

Rtmp ( # Aktivizoni serverin e transmetimit në portin 1935 në adresën e sajtit/serverit rtmp (dëgjoni 1935; aplikacioni rtmp ( drejtpërdrejt; )))

Moduli RTMP nuk mund të funksionojë në një konfigurim me shumë fije, kështu që numri i proceseve të punëtorëve nginx do të duhet të reduktohet në një (më vonë do t'ju tregoj se si ta kapërceni këtë problem):

Punëtori_proceset 1;

Tani mund ta ruani skedarin dhe ta detyroni nginx të rilexojë konfigurimin. Konfigurimi i nginx ka përfunduar, por ne nuk e kemi ende vetë transmetimin e videos, kështu që duhet ta marrim diku. Për shembull, le të jetë ky skedari video.avi nga drejtoria aktuale. Për ta kthyer atë në një transmetim dhe për ta mbështjellë atë në transmetuesin tonë RTMP, ne do të përdorim FFmpeg të mirë të vjetër:

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

Nëse skedari video nuk është në formatin H264, ai duhet të rikodohet. Kjo mund të bëhet në fluturim duke përdorur të njëjtin FFmpeg:

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

Transmetimi gjithashtu mund të kapet drejtpërdrejt nga një kamerë në internet:

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

Për të parë transmetimin në anën e klientit, mund të përdorni çdo lojtar që mbështet RTMP, për shembull mplayer:

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

Ose futni luajtësin direkt në një faqe interneti, e cila shërbehet nga i njëjti nginx (shembull nga dokumentacioni zyrtar):

Luajtësi më i thjeshtë në internet RTMP

jwplayer("container").setup(( modes: [( type: "flash", src: "/jwplayer/player.swf", config: (bufferlength: 1, file: "stream", streamer: "rtmp:/ /localhost/rtmp", ofruesi: "rtmp", ) )] ));

Këtu ka vetëm dy rreshta të rëndësishëm: "skedari: "transmetim"", që tregon transmetimin RTMP dhe "transmetues: "rtmp://localhost/rtmp"", që tregon adresën e transmetuesit RTMP. Për shumicën e detyrave, cilësime të tilla do të jenë mjaft të mjaftueshme. Ju mund të dërgoni disa transmetime të ndryshme në një adresë dhe nginx do t'i shumëfishojë ato në mënyrë efektive midis klientëve. Por kjo nuk është gjithçka që mund të bëjë moduli RTMP. Me ndihmën e tij, për shembull, mund të organizoni një transmetim të një transmetimi video nga një server tjetër. Serveri FFmpeg nuk nevojitet fare për këtë, thjesht shtoni linjat e mëposhtme në konfigurim:

# vi /etc/nginx/nginx.conf aplikacioni rtmp ( drejtpërdrejt; tërhiq rtmp://rtmp.example.com; )

Nëse keni nevojë të krijoni transmetime të shumta me cilësi të ndryshme, mund të telefononi transkoderin FFmpeg direkt nga nginx:

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

Me këtë konfigurim do të marrim dy transmetues njëherësh, njëri prej të cilëve do të jetë i disponueshëm në adresën rtmp://site/rtmp dhe i dyti, me cilësi 320 x 240, në adresën rtmp://site/rtmp. – 320x240. Më pas, mund të shtoni një flash player dhe butona të përzgjedhjes së cilësisë në sajt, të cilat do t'i japin lojtarit një ose një adresë tjetër transmetuesi.

Dhe së fundi, një shembull i transmetimit të muzikës në rrjet:

Ndërsa e vërtetë; bëj 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; bërë

Proxy Git

Sistemi i kontrollit të versionit Git është i aftë të sigurojë akses në depo jo vetëm nëpërmjet protokolleve Git dhe SSH, por edhe nëpërmjet HTTP. Njëherë e një kohë, zbatimi i aksesit HTTP ishte primitiv dhe i paaftë për të ofruar punë të plotë me depon. Me versionin 1.6.6, situata ka ndryshuar dhe sot ky protokoll mund të përdoret, për shembull, për të anashkaluar kufizimet e murit të zjarrit në të dy anët e lidhjes ose për të krijuar hostin tuaj Git me një ndërfaqe në internet.

Fatkeqësisht, dokumentacioni zyrtar flet vetëm për organizimin e aksesit në Git duke përdorur serverin në internet Apache, por meqenëse vetë zbatimi është aplikimi i jashtëm me një ndërfaqe standarde CGI, mund të bashkëngjitet pothuajse në çdo server tjetër, duke përfshirë lighttpd dhe, natyrisht, nginx. Kjo nuk kërkon asgjë përveç vetë serverit, Git të instaluar dhe një server të vogël FastCGI fcgiwrap, i cili nevojitet sepse nginx nuk di të punojë drejtpërdrejt me CGI, por mund të thërrasë skriptet duke përdorur protokollin FastCGI.

E gjithë skema e punës do të duket kështu. Serveri fcgiwrap do të varet në sfond dhe do të presë një kërkesë për të ekzekutuar aplikacionin CGI. Nginx, nga ana tjetër, do të konfigurohet për të kërkuar ekzekutimin e binarit Git-http-backend CGI nëpërmjet ndërfaqes FastCGI sa herë që aksesohet adresa që ne specifikojmë. Me marrjen e kërkesës, fcgiwrap ekzekuton git-http-backend me argumentet e specifikuara CGI të kaluara nga klienti GIT dhe kthen rezultatin.

Për të zbatuar një skemë të tillë, së pari instaloni fcgiwrap:

$ sudo apt-get instalo fcgiwrap

Nuk ka nevojë ta konfiguroni atë; të gjithë parametrat transmetohen përmes protokollit FastCGI. Ai gjithashtu do të nisë automatikisht. Prandaj, gjithçka që mbetet është të konfiguroni nginx. Për ta bërë këtë, krijoni një skedar /etc/nginx/sites-enabled/git (nëse nuk ka një direktori të tillë, mund të shkruani në konfigurimin kryesor) dhe shkruani sa vijon në të:

# vi /etc/nginx/sites-enabled/git server ( # Ne jemi të varur në portin 8080, dëgjoni 8080; # Adresa e serverit tonë (mos harroni të shtoni një hyrje në DNS) emri i serverit git.example.ru; # Regjistrat akses_log /var/log/nginx /git-http-backend.access.log; error_log /var/log/nginx/git-http-backend.error.log; # Adresa primare për vendndodhjen anonime të aksesit / ( # Kur përpiqeni të shkarkoni, dërgoni përdoruesin në një adresë private nëse ($ arg_service ~* "git-receive-pack") ( rishkruaj ^ /private$uri e fundit; ) përfshin /etc/nginx/fastcgi_params; # Adresa e git-http-backend tonë fastcgi_param SCRIPT_FILENAME /usr/lib/git-core/git- http-backend; # Adresa e depove Git fastcgi_param GIT_PROJECT_ROOT /srv/git; # Adresa e skedarit fastcgi_param PATH_INFO $uri; # fcgiwrap adresa e serverit fastcgi_pass 127.0.0.1.1:9) vendndodhja ~/private(/.*)$ ( # Lejet e përdoruesit auth_basic "git anonim vetëm për lexim, shkrim i vërtetuar"; # Vërtetimi HTTP bazuar në htpasswd auth_basic_user_file /etc/nginx/htpasswd; # FastCGI/msg_inx ; 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; ) )

Ky konfigurim supozon tre gjëra të rëndësishme:

Adresa e depove do të jetë /srv/git, kështu që ne vendosim të drejtat e duhura të aksesit: $ sudo chown -R www-data:www-data /srv/git

Vetë depoja duhet të jetë e hapur për lexim nga përdoruesit anonimë dhe të lejojë ngarkimin nëpërmjet HTTP: $ cd /srv/git $ git config core.sharedrepository e vërtetë $ git config http.receivepack e vërtetë

Autentifikimi kryhet duke përdorur skedarin htpasswd, ju duhet ta krijoni atë dhe të shtoni përdorues në të: $ sudo apt-get install apache2-utils $ htpasswd -c /etc/nginx/htpasswd user1 $ htpasswd /etc/nginx/htpasswd user2. ..

Kjo është e gjitha, rinisni nginx:

Microcaching

Le të imagjinojmë një situatë me një faqe interneti dinamike, të përditësuar shpesh, që befas fillon të marrë ngarkesa shumë të rënda (epo, përfundoi në faqen e një prej faqeve më të mëdha të lajmeve) dhe pushon së përballuari me kthimin e përmbajtjes. Optimizimi i duhur dhe zbatimi i skemës së saktë të memorizimit do të marrë shumë kohë dhe problemet duhet të zgjidhen tani. Cfarë mund të bëjmë?

Ka disa mënyra për të dalë nga kjo situatë me sa më pak humbje, por ideja më interesante u propozua nga Fenn Bailey (fennb.com). Ideja është që thjesht të vendosni nginx përpara serverit dhe ta detyroni atë të ruajë të gjithë përmbajtjen e transmetuar, por jo vetëm cache, por vetëm për një sekondë. Kthesa këtu është se qindra e mijëra vizitorë të faqes në sekondë, në fakt, do të gjenerojnë vetëm një kërkesë për pjesën e pasme, duke marrë një faqe kryesisht të ruajtur në memorie. Në të njëjtën kohë, vështirë se dikush do ta vërejë ndryshimin, sepse edhe në një faqe dinamike një sekondë zakonisht nuk do të thotë asgjë.

Konfigurimi me zbatimin e kësaj ideje nuk do të duket aq i ndërlikuar:

# vi /etc/nginx/sites-enabled/cache-proxy # Konfigurimi i cache proxy_cache_path /var/cache/nginx nivelet=1:2 tastet_zone=mikrocache:5m max_size=1000m; server (dëgjo 80; emri i serverit shembull.com; # Vendndodhja e adresës së memorizuar / ( # Cache është aktivizuar si parazgjedhje, vendos $no_cache ""; # Çaktivizo cache për të gjitha metodat përveç GET dhe HEAD if ($request_method !~ ^(GET|HEAD) $) ( vendos $no_cache "1"; ) # Nëse klienti ngarkon përmbajtje në sajt (no_cache = 1), ne sigurohemi që të dhënat që i janë dhënë të mos ruhen në memorie për dy sekonda dhe ai mund të shohë rezultatin e shkarkimit if ($no_cache = "1") (add_header Set-Cookie "_mcnc=1; Max-Age=2; Path=/"; add_header X-Microcachable "0"; ) if ($http_cookie ~* "_mcnc") ( vendos $no_cache "1 "; ) # Aktivizo/çaktivizo cache-në në varësi të gjendjes së variablit no_cache proxy_no_cache $no_cache; proxy_cache_bypass $no_cache; # Kërkesat e përfaqësuesit në serverin real proxy_pass http://appserver.example.ru; proxy_cache proxy_cache_key $scheme$host$request_method$ request_uri;proxy_cache_valid 200 1s;# Mbrojtje nga problemi i tufës Thundering përditësim proxy_cache_use_stale;# Shto tituj 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; # Ne nuk ruajmë skedarë memorie më të mëdha se 1 MB proxy_max_temp_file_size 1M; ) )

Një vend të veçantë në këtë konfigurim zë rreshti "proxy_cache_use_stale përditësimi;", pa të cilin do të kishim marrë shpërthime periodike të ngarkesës në serverin e pasme për shkak të kërkesave të marra gjatë përditësimit të cache. Përndryshe, gjithçka është standarde dhe duhet të jetë e qartë pa shpjegime të panevojshme.

Sjellja e përfaqësuesve më afër audiencës së synuar

Pavarësisht rritjes së përhapur globale të shpejtësisë së internetit, distanca fizike e serverit nga audienca e synuar ende vazhdon të luajë një rol. Kjo do të thotë që nëse një sajt rus funksionon në një server të vendosur diku në Amerikë, shpejtësia e aksesit në të do të jetë a priori më e ngadaltë sesa nga një server rus me të njëjtën gjerësi kanali (natyrisht, nëse mbyllni sytë ndaj të gjithë faktorëve të tjerë ). Një tjetër gjë është se vendosja e serverëve jashtë vendit është shpesh më fitimprurëse, përfshirë edhe në aspektin e mirëmbajtjes. Prandaj, për të marrë fitim, në formën e normave më të larta të pagesave, do t'ju duhet të përdorni disa truke.

Një nga opsionet e mundshme: vendosni serverin kryesor produktiv në Perëndim dhe vendosni një frontend që nuk kërkon shumë burime dhe prodhon të dhëna statike në Rusi. Kjo do t'ju lejojë të fitoni shpejtësi pa kosto serioze. Konfigurimi i nginx për frontend në këtë rast do të jetë një zbatim i thjeshtë dhe i njohur proxy për të gjithë ne:

# vi /etc/nginx/sites-enabled/proxy # Ruajeni cache-in për 30 ditë në 100 GB hapësirë ​​ruajtëse proxy_cache_path /var/cache/nginx nivele=1:2 taste_zone=static:32m joaktive=30d max_size=100g; server (dëgjo 80; emri i serverit shembull.com; # Në fakt, vendndodhja jonë e përfaqësuesit ~* .(jpg|jpeg|gif|png|ico|css|midi|wav|bmp|js|swf|flv|avi|djvu|mp3) $ ( # Adresa e pasme 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 $buk_add_x_proxizex1_forwarded; 6k, proxy_cache statike; proxy_cache_valid 30d; proxy_ignore_headers "Cache-Control" "Skadon"; proxy_cache_key "$uri$is_args$args"; proxy_cache_lock aktiv; ) )

konkluzionet

Sot, me ndihmën e nginx, ju mund të zgjidhni shumë probleme të ndryshme, shumë prej të cilave nuk lidhen fare me serverin në internet dhe protokollin HTTP. Përfaqësuesi i postës, serveri i transmetimit dhe ndërfaqja Git janë vetëm disa nga këto detyra.