Nginx strauji iegūst popularitāti, attīstoties no tikai statiska Apache apkalpošanas paātrinātāja par pilnvērtīgu un modernu tīmekļa serveri, kas arvien vairāk tiek izmantots atsevišķi. Šajā rakstā mēs runāsim par interesantiem un nestandarta nginx izmantošanas scenārijiem, kas ļaus jums maksimāli izmantot tīmekļa servera iespējas.
Pasta starpniekserveris
Sāksim ar acīmredzamāko - nginx spēju darboties kā pasta starpniekserveri. Šī funkcija sākotnēji ir nginx, taču kaut kādu iemeslu dēļ tā tiek izmantota ražošanā ārkārtīgi reti, daži pat nezina par tās esamību. Lai kā arī būtu, nginx atbalsta POP3, IMAP un SMTP protokolu starpniekserveri ar dažādām autentifikācijas metodēm, tostarp SSL un StartTLS, un dara to ļoti ātri.
Kāpēc tas ir vajadzīgs? Šai funkcionalitātei ir vismaz divi lietojumi. Pirmkārt, izmantojiet nginx kā vairogu pret kaitinošiem surogātpasta izplatītājiem, kas mēģina sūtīt nevēlamo pastu, izmantojot mūsu SMTP serveri. Parasti surogātpasta izplatītāji nerada daudz problēmu, jo autentifikācijas stadijā tie ātri atlec, tomēr, ja to ir patiešām daudz, nginx palīdzēs ietaupīt CPU resursus. Otrkārt, izmantojiet nginx, lai novirzītu lietotājus uz vairākiem POP3/IMAP pasta serveriem. Protams, ar to varētu rīkoties arī cits pasta starpniekserveris, bet kāpēc norobežot servera dārzu, ja nginx jau ir instalēts priekšgalā, lai apkalpotu statiskos datus, piemēram, izmantojot HTTP?
Pasta starpniekserveris programmā nginx nav gluži standarta. Tas izmanto papildu autentifikācijas slāni, kas ieviests ar HTTP palīdzību, un tikai tad, ja lietotājs šķērso šo barjeru, viņš tiek nodots tālāk. Šī funkcionalitāte tiek nodrošināta, izveidojot lapu/skriptu, kuram nginx sniedz lietotājam datus, un viņa/viņš atgriež atbildi standarta OK vai atteikuma iemesla veidā (piemēram, “Nederīgs pieteikšanās vārds vai parole”). Skripts darbojas ar šādām galvenēm:
Autentifikācijas skripta ievade HTTP_AUTH_USER: lietotājs HTTP_AUTH_PASS: parole HTTP_AUTH_PROTOCOL: pasta protokols (IMAP, POP3 vai SMTP)
Un tas atgriežas šādi:
Autentifikācijas skripta izvade HTTP_AUTH_STATUS: Labi vai kļūmes iemesls HTTP_AUTH_SERVER: reāls pasta serveris, lai novirzītu HTTP_AUTH_PORT: servera ports
Šīs pieejas ievērojama iezīme ir tā, ka to var izmantot nevis pašai autentifikācijai, bet gan lietotāju izkliedēšanai pa dažādiem iekšējiem serveriem atkarībā no lietotājvārda, datiem par pašreizējām pasta serveru ielādēm vai pat organizējot vienkāršāko slodzes līdzsvarošanu, izmantojot aplis . Tomēr, ja jums vienkārši ir jāpārsūta lietotāji uz iekšējo pasta serveri, reāla skripta vietā varat izmantot stublu, ko ieviesis pats nginx. Piemēram, vienkāršākais SMTP un IMAP starpniekserveris nginx konfigurācijā izskatīsies šādi:
# vi /etc/nginx/nginx.conf mail ( # Autentifikācijas skripta adrese auth_http localhost:8080/auth; # Atspējojiet komandu XCLIENT, daži pasta serveri to nesaprot xclient off; # IMAP servera serveris ( klausieties 143; protokols imap; starpniekserveris ieslēgts; ) # SMTP servera serveris (klausīties 25; protokols smtp; starpniekserveris ieslēgts; ) )
# vi /etc/nginx/nginx.conf http ( # Karte uz pareizo pasta servera portu atkarībā no porta, kas nosūtīts HTTP_AUTH_PROTOCOL galvenes kartē $http_auth_protocol $mailport (noklusējums 25; smtp 25; imap 143; ) # Ieviešana autentifikācijas "skripts" - vienmēr atgriež OK un novirza lietotāju uz iekšējo pasta serveri, iestatot pareizo portu, izmantojot iepriekš minēto kartēšanas serveri ( klausieties 8080; atrašanās vieta / auth ( add_header "Auth-Status" "OK"; add_header "Auth- Serveris" "192.168.0.1" ; add_header "Auth-Port" $mailport; return 200; ) ) )
Tas viss. Šī konfigurācija ļauj pārskatāmi novirzīt lietotājus uz iekšējo pasta serveri, neradot papildu izmaksas skripta veidā, kas šajā gadījumā ir nevajadzīgs. Izmantojot skriptu, šo konfigurāciju var ievērojami paplašināt: iestatīt slodzes līdzsvarošanu, pārbaudīt lietotājus LDAP datubāzē un veikt citas darbības. Skripta rakstīšana ir ārpus šī raksta darbības jomas, taču to ir ļoti viegli ieviest, pat ja ir tikai elementāras PHP un Python zināšanas.
Video straumēšana
Parasta uz nginx balstīta video mitināšanas iestatīšana ir vienkārša. Viss, kas jums jādara, ir augšupielādēt pārkodēto video direktorijā, kas pieejams serverim, pievienot to konfigurācijai un konfigurēt zibatmiņas vai HTML5 atskaņotāju tā, lai tas uzņemtu video no šī direktorija. Tomēr, ja vēlaties iestatīt nepārtrauktu video apraidi no kāda ārēja avota vai tīmekļa kameras, šī shēma nedarbosies, un jums būs jāmeklē īpaši straumēšanas protokoli.
Ir vairāki protokoli, kas atrisina šo problēmu, visefektīvākais un atbalstītākais no tiem ir RTMP. Vienīgā problēma ir tā, ka gandrīz visas RTMP servera implementācijas cieš no problēmām. Oficiālais Adobe Flash Media Server tiek apmaksāts. Red5 un Wowza ir rakstīti Java valodā, un tāpēc nenodrošina vēlamo veiktspēju, cita implementācija Erlyvideo ir rakstīta Erlang valodā, kas ir laba klastera iestatīšanas gadījumā, bet ne tik efektīva vienam serverim.
Es iesaku citu pieeju - izmantojiet RTMP moduli nginx. Tam ir lieliska veiktspēja, kā arī tas ļauj izmantot vienu serveri, lai apkalpotu gan vietnes tīmekļa saskarni, gan video straumi. Vienīgā problēma ir tā, ka šis modulis ir neoficiāls, tāpēc jums pašiem būs jāveido nginx ar tā atbalstu. Par laimi, montāža tiek veikta standarta veidā:
$ sudo apt-get noņemt 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
Tagad modulis ir jākonfigurē. Tas tiek darīts, kā parasti, izmantojot nginx konfigurāciju:
Rtmp (# Aktivizējiet apraides serveri portā 1935 vietnē/rtmp serverī (klausieties 1935; lietojumprogramma rtmp (tiešraide; ) ))
RTMP modulis nevar darboties vairāku pavedienu konfigurācijā, tāpēc nginx darbinieka procesu skaits būs jāsamazina līdz vienam (vēlāk es jums pastāstīšu, kā apiet šo problēmu):
darbinieka_procesi 1;
Tagad mēs varam saglabāt failu un likt nginx atkārtoti izlasīt konfigurāciju. Nginx iestatīšana ir pabeigta, taču mums vēl nav pašas video straumes, tāpēc mums tā kaut kur jāiegūst. Piemēram, lai tas būtu video.avi fails no pašreizējā direktorija. Lai to pārvērstu straumē un ietītu mūsu RTMP raidītājā, izmantosim veco labo FFmpeg:
# ffmpeg -re -i ~/video.avi -c kopēt -f flv rtmp://localhost/rtmp/stream
Ja video fails nav H264 formātā, tas ir jāpārkodē. To var izdarīt lidojumā, izmantojot to pašu FFmpeg:
# ffmpeg -re -i ~/video.avi -c:v libx264 -c:a libfaac -ar 44100 -ac 2 -f flv rtmp://localhost/rtmp/stream
Straumi var tvert arī tieši no tīmekļa kameras:
# ffmpeg -f video4linux2 -i /dev/video0 -c:v libx264 -an -f flv rtmp://localhost/rtmp/stream
Lai skatītu straumi klienta pusē, varat izmantot jebkuru atskaņotāju ar iespējotu RTMP, piemēram, mplayer:
$ mplayer rmtp://example.com/rtmp/stream
Vai arī ieguliet atskaņotāju tieši tīmekļa lapā, kuru apkalpo tas pats nginx (piemērs no oficiālās dokumentācijas):
Vienkāršākais RTMP tīmekļa atskaņotājs
Šeit ir tikai divas svarīgas rindas: “fails: “straume”, kas norāda RTMP straumi, un “straumētājs: “rtmp://localhost/rtmp””, kas norāda RTMP straumētāja adresi. Lielākajai daļai uzdevumu ar šiem iestatījumiem pietiks. Vienā adresē var palaist vairākas dažādas straumes, un nginx tās efektīvi multipleksēs starp klientiem. Bet tas nav viss, ko spēj RTMP modulis. Ar tās palīdzību, piemēram, var organizēt video straumes retranslāciju no cita servera. Šim nolūkam FFmpeg serveris vispār nav vajadzīgs, vienkārši pievienojiet konfigurācijai šādas rindiņas:
# vi /etc/nginx/nginx.conf lietojumprogramma rtmp (tiešraidē; velciet rtmp://rtmp.example.com; )
Ja jums ir jāizveido vairākas straumes dažādās kvalitātēs, varat izsaukt FFmpeg pārkodētāju tieši no nginx:
# vi /etc/nginx/nginx.conf lietojumprogramma rtmp (tiešraidē; exec ffmpeg -i rtmp://localhost/rtmp/$name -c:v flv -c:a -s 320x240 -f flv rtmp://localhost /rtmp-320x240/$name; ) lietojumprogramma rtmp-320x240 (tiešraidē; )
Izmantojot šo konfigurāciju, mēs iegūsim uzreiz divas raidorganizācijas, no kurām viena būs pieejama vietnē rtmp://site/rtmp, bet otra, kas raidīs 320 x 240 kvalitātē, vietnē rtmp://site/rtmp–320x240. Tālāk vietnē jūs varat piekārt flash atskaņotāju un kvalitātes izvēles pogas, kas atskaņotājam noslīdēs vienu vai otru raidorganizācijas adresi.
Un visbeidzot, piemērs mūzikas pārraidīšanai tīklā:
kamēr patiesība; do ffmpeg -re -i "`atrast /var/music -type f -name "*.mp3"|kārtot -R|head -n 1`" -vn -c:a libfaac -ar 44100 -ac 2 -f flv rtmp://localhost/rtmp/stream; darīts
git starpniekserveris
Git versiju kontroles sistēma spēj nodrošināt piekļuvi krātuvēm ne tikai caur Git un SSH protokoliem, bet arī caur HTTP. Kādreiz HTTP piekļuves ieviešana bija primitīva un nespēja nodrošināt pilnvērtīgu darbu ar repozitoriju. Kopš versijas 1.6.6 situācija ir mainījusies, un šodien šo protokolu var izmantot, lai, piemēram, apietu ugunsmūra ierobežojumus abās savienojuma pusēs vai izveidotu savu Git hostingu ar tīmekļa saskarni.
Diemžēl oficiālajā dokumentācijā ir runāts tikai par piekļuves organizēšanu Git, izmantojot Apache tīmekļa serveri, taču, tā kā pati ieviešana ir ārēja lietojumprogramma ar standarta CGI interfeisu, to var pievienot gandrīz jebkuram citam serverim, ieskaitot lighttpd un, protams, nginx. Tas neprasa neko citu kā pašu serveri, instalēto Git un nelielu FastCGI serveri fcgiwrap, kas ir nepieciešams, jo nginx neprot strādāt tieši ar CGI, bet tas var izsaukt skriptus, izmantojot FastCGI protokolu.
Visa darba shēma izskatīsies šādi. Fcgiwrap serveris darbosies fonā un gaidīs pieprasījumu izpildīt CGI lietojumprogrammu. Savukārt Nginx tiks konfigurēts, lai pieprasītu git-http-backend CGI bināra izpildi, izmantojot FastCGI interfeisu ikreiz, kad tiek piekļūts mūsu norādītajai adresei. Saņemot pieprasījumu, fcgiwrap izpilda git-http-backend ar norādītajiem CGI argumentiem, ko nosūtījis GIT klients, un atgriež rezultātu.
Lai ieviestu šādu shēmu, vispirms instalējam fcgiwrap:
$ sudo apt-get instalēt fcgiwrap
Jums tas nav jākonfigurē, visi parametri tiek nodoti, izmantojot FastCGI protokolu. Tas arī sāksies automātiski. Tāpēc atliek tikai konfigurēt nginx. Lai to izdarītu, izveidojiet failu /etc/nginx/sites-enabled/git (ja šāda direktorija nav, varat rakstīt galvenajā konfigurācijā) un ierakstiet tajā sekojošo:
# vi /etc/nginx/sites-enabled/git serveris ( # Uzgaidiet portu 8080, klausieties 8080; # Mūsu servera adrese (neaizmirstiet pievienot DNS ierakstu) servera_nosaukums git.example.ru; # Žurnāli access_log /var /log/nginx /git-http-backend.access.log; error_log /var/log/nginx/git-http-backend.error.log; # Primārā adrese anonīmas piekļuves vietai / ( # Mēģinot augšupielādēt, nosūtiet lietotājam uz privātu adresi, ja ($ arg_service ~* "git-receive-pack") (pārrakstīt ^ /private$uri pēdējo; ) ietver /etc/nginx/fastcgi_params; # Mūsu git-http-backend fastcgi_param adrese SCRIPT_FILENAME /usr /lib/git-core/git- http-backend; # Git repozitorija adrese fastcgi_param GIT_PROJECT_ROOT /srv/git; # Faila adrese fastcgi_param PATH_INFO $uri; # Servera adrese fcgiwrap fastcgi_pass 127.0.0.1:9001; ) # Adrese rakstīšanas vietai ~/private(/.* )$ ( # Lietotāja atļaujas auth_basic "git anonīms tikai lasāms, autentificēts rakstīšana"; # HTTP autentifikācija, pamatojoties uz htpasswd auth_basic_user_file /etc/nginx/htpasswd; # FastCGI iestatījumi 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; ) )
Šajā konfigurācijā ir iekļautas trīs svarīgas lietas:
- Repozitorija adrese būs /srv/git, tāpēc iestatiet atbilstošās atļaujas: $ sudo chown -R www-data:www-data /srv/git
- Pašai krātuvei ir jābūt lasāmai Anonymous un jāļauj augšupielādēt, izmantojot HTTP: $ cd /srv/git $ git config core.sharedrepository true $ git config http.receivepack true
- Autentifikācija tiek veikta, izmantojot htpasswd failu, tas ir jāizveido un tam jāpievieno lietotāji: $ sudo apt-get install apache2-utils $ htpasswd -c /etc/nginx/htpasswd user1 $ htpasswd /etc/nginx/htpasswd user2. .
Tas arī viss, restartējiet nginx:
Mikrokešings
Iedomāsimies situāciju ar dinamisku, bieži atjauninātu vietni, kas pēkšņi sāk saņemt ļoti lielas slodzes (nu, tā nokļuva vienas no lielākajām ziņu vietnēm) un vairs netiek galā ar satura atgriešanos. Kompetenta optimizācija un pareizas kešatmiņas shēmas ieviešana prasīs ilgu laiku, un problēmas ir jārisina tagad. Ko mēs varam darīt?
Ir vairāki veidi, kā izkļūt no šīs situācijas ar minimāliem zaudējumiem, taču visinteresantākā ideja radās Fennam Beilijam (fennb.com). Ideja ir vienkārši novietot nginx servera priekšā un piespiest to kešatmiņā saglabāt visu pārraidīto saturu, bet ne tikai kešatmiņu, bet tikai vienu sekundi. Šeit galvenais ir tas, ka simtiem un tūkstošiem vietnes apmeklētāju sekundē faktiski ģenerēs tikai vienu aizmugursistēmas zvanu, un lielākā daļa no tiem saņem kešatmiņā saglabātu lapu. Tajā pašā laikā diez vai kāds pamanīs atšķirību, jo pat dinamiskā vietnē viena sekunde parasti neko nenozīmē.
Konfigurācija ar šīs idejas īstenošanu neizskatīsies tik sarežģīta:
# vi /etc/nginx/sites-enabled/cache-proxy # Konfigurēt kešatmiņu proxy_cache_path /var/cache/nginx level=1:2 keys_zone=microcache:5m max_size=1000m; serveris ( klausieties 80; servera_nosaukums example.com; # Kešatmiņas adreses atrašanās vieta / ( # Kešatmiņa iespējota pēc noklusējuma iestatīt $no_cache ""; # Atspējot kešatmiņu visām metodēm, izņemot GET un HEAD if ($request_method !~ ^(GET|HEAD) $ ) ( iestatiet $no_cache "1"; ) # Ja klients augšupielādē saturu vietnē (no_cache = 1), mēs pārliecināmies, ka viņam sniegtie dati netiek saglabāti kešatmiņā divas sekundes un viņš var redzēt lejupielādes rezultātu, ja ($no_cache = "1") ( add_header Set-Cookie "_mcnc=1; Max-Age=2; Path=/"; add_header X-Microcachable "0"; ) if ($http_cookie ~* "_mcnc") ( set $no_cache "1 "; ) # Iespējot/atspējot kešatmiņu atkarībā no mainīgā stāvokļa no_cache proxy_no_cache $no_cache; proxy_cache_bypass $no_cache; # Starpniekservera pieprasījumi reālajam serverim proxy_pass http://appserver.example.ru; proxy_cache microcache; proxy_cache_key $scheme$host$request_method$ pieprasījums galvene Host $host; proxy_set_header X-Real-IP $ attālās_adrese; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # Neglabājiet kešatmiņā failus, kas lielāki par 1 MB proxy_max_temp_file_size 1M; ) )
Īpašu vietu šajā konfigurācijā ieņem rinda "proxy_cache_use_stale updating;", bez kuras mēs būtu saņēmuši periodiskus aizmugursistēmas servera slodzes uzliesmojumus kešatmiņas atjaunināšanas laikā saņemto pieprasījumu dēļ. Pretējā gadījumā viss ir standarta, un tam jābūt skaidram bez papildu paskaidrojumiem.
Starpniekservera tuvināšana mērķauditorijai
Neskatoties uz plaši izplatīto interneta ātruma pieaugumu pasaulē, servera fiziskajai attālumam no mērķauditorijas joprojām ir nozīme. Tas nozīmē, ka, ja krievu vietne darbojas serverī, kas atrodas kaut kur Amerikā, piekļuves ātrums tai a priori būs lēnāks nekā no Krievijas servera ar tādu pašu joslas platumu (protams, ja aizverat acis uz visiem citiem faktoriem ). Cita lieta, ka serverus bieži vien ir izdevīgāk mitināt ārzemēs, arī uzturēšanas ziņā. Tāpēc, lai gūtu peļņu augstāku atdeves likmju veidā, jums būs jāķeras pie viltības.
Viens no iespējamiem variantiem: galveno produktīvo serveri novietot Rietumos, bet front-end, kas nav pārāk resursietilpīgs, dodot statiku, izvietot Krievijā. Tas ļaus jums uzvarēt ātrumā bez nopietnām izmaksām. Nginx konfigurācija priekšgalam šajā gadījumā būs vienkārša starpniekservera ieviešana, kas mums visiem ir pazīstama:
# vi /etc/nginx/sites-enabled/proxy # Glabājiet kešatmiņu 30 dienas 100 GB krātuves proxy_cache_path /var/cache/nginx level=1:2 keys_zone=static:32m inactive=30d max_size=100g; serveris ( klausieties 80; servera_nosaukums example.com; # Patiesībā mūsu starpniekservera atrašanās vieta ~* .(jpg|jpeg|gif|png|ico|css|midi|wav|bmp|js|swf|flv|avi|djvu|mp3) $ ( # Aizmugursistēmas adrese 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; 1 proxy_bufferk; 1 proxy_bufferk; 1 proxy_bufferk proxy_cache_valid 30d; proxy_ignore_headers "Cache-Control" "Expires"; proxy_cache_key "$uri$is_args$args"; proxy_cache_lock on; ) )
atklājumiem
Mūsdienās ar nginx palīdzību var atrisināt daudz dažādu uzdevumu, no kuriem daudzi vispār nav saistīti ar tīmekļa serveri un HTTP protokolu. Pasta starpniekserveris, straumēšanas serveris un Git saskarne ir tikai daži no uzdevumiem.
Šajā rakstā ir paskaidrots, kā konfigurēt NGINX Plus vai NGINX Open Source kā starpniekserveri pasta serverim vai ārējam pasta pakalpojumam.
Ievads
NGINX var starpniekserveri IMAP, POP3 un SMTP protokolus vienam no augšupējiem pasta serveriem, kas mitina pasta kontus, un tādējādi to var izmantot kā vienu galapunktu e-pasta klientiem. Tas var sniegt vairākas priekšrocības, piemēram:
- vienkārša pasta serveru skaita mērogošana
- pasta servera izvēle, pamatojoties uz dažādiem noteikumiem, piemēram, tuvākā servera izvēle, pamatojoties uz klienta IP adresi
- slodzes sadale starp pasta serveriem
Priekšnoteikumi
NGINX Plus (jau ietver pasta moduļus, kas nepieciešami starpniekservera e-pasta trafikam) vai NGINX Open Source apkopoja pasta moduļus, izmantojot parametru --with-mail e-pasta starpniekservera funkcionalitātei un --with-mail_ssl_module parametru SSL/TLS atbalstam:
$ ./configure --with-mail --with-mail_ssl_module --with-openssl=[ DIR] /openssl-1.1.1
IMAP, POP3 un/vai SMTP pasta serveri vai ārējais pasta pakalpojums
SMTP/IMAP/POP3 pasta starpniekserveru konfigurēšana
NGINX konfigurācijas failā:
- uz porta numurs kas atbilst norādītajam protokolam ar klausīšanās direktīvu
- uz protokols ar protokola direktīvu (ja nav norādīts, tiks automātiski noteikts no klausīšanās direktīvā norādītā porta)
- atļauts autentifikācijas metodes ar direktīvām imap_auth , pop3_auth un smtp_auth:
pasts (#...)
pasts ( servera_nosaukums pasts.example.com ; #... )
pasts ( servera_nosaukums mail.example.com ; auth_http localhost : 9000 /cgi-bin/nginxauth.cgi ; #... )
Vai arī norādiet, vai informēt lietotāju par kļūdām no autentifikācijas servera, norādot proxy_pass_error_message direktīvu. Tas var būt noderīgi, ja pastkastē pietrūkst atmiņas:
pasts ( servera_nosaukums mail.example.com ; auth_http localhost : 9000 /cgi-bin/nginxauth.cgi ; proxy_pass_error_message on ; #... )
Konfigurējiet katru SMTP, IMAP vai POP3 serveri ar servera blokiem. Katram serverim norādiet:
serveris (klausīt 25; protokols smtp; smtp_auth login plain cram-md5; ) serveris (klausīt 110; protokols pop3; pop3_auth vienkāršs apop cram-md5;) serveris (klausīties 143; protokols imap;)
Pasta starpniekservera autentifikācijas iestatīšana
Katrs klienta POP3/IMAP/SMTP pieprasījums vispirms tiks autentificēts ārējā HTTP autentifikācijas serverī vai ar autentifikācijas skriptu. NGINX pasta servera starpniekserveram ir jābūt autentifikācijas serverim. Serveri var izveidot pats saskaņā ar NGINX autentifikācijas protokolu, kura pamatā ir HTTP protokols.
Ja autentifikācija ir veiksmīga, autentifikācijas serveris izvēlēsies augšupējo serveri un novirzīs pieprasījumu. Šajā gadījumā atbildē no servera būs šādas rindas:
HTTP/1.0 200 OK Auth-Status: OK Auth-Server:
Ja autentifikācija neizdodas, autentifikācijas serveris atgriezīs kļūdas ziņojumu. Šajā gadījumā atbildē no servera būs šādas rindas:
HTTP/1.0 200 OK Auth-Status:
Ņemiet vērā, ka abos gadījumos atbilde saturēs HTTP/1.0 200 Labi kas varētu būt mulsinoši.
Lai iegūtu citus autentifikācijas serverim nosūtīto pieprasījumu un atbilžu piemērus, skatiet ngx_mail_auth_http_module NGINX atsauces dokumentācijā.
SSL/TLS iestatīšana pasta starpniekserverim
Izmantojot POP3/SMTP/IMAP, izmantojot SSL/TLS, pārliecinieties, ka dati, kas tiek pārsūtīti starp klientu un pasta serveri, ir aizsargāti.
Lai iespējotu SSL/TLS pasta starpniekserverim:
Pārliecinieties, vai jūsu NGINX ir konfigurēts ar SSL/TLS atbalstu, komandrindā ierakstot komandu nginx -V un pēc tam izvadā meklējot rindu ar --mail_ssl_module:
$ nginx -V konfigurēt argumentus: ... with--mail_ssl_module
Pārliecinieties, vai esat ieguvis servera sertifikātus un privāto atslēgu, un ievietojiet tos serverī. Sertifikātu var iegūt no uzticamas sertifikātu iestādes (CA) vai ģenerēt, izmantojot SSL bibliotēku, piemēram, OpenSSL.
ssl ieslēgts;
starls on ;
Pievienojiet SSL sertifikātus: norādiet ceļu uz sertifikātiem (kam jābūt PEM formātā) ar direktīvu ssl_certificate un norādiet ceļu uz privāto atslēgu direktīvā ssl_certificate_key:
pasts (#... ssl_certificate /etc/ssl/certs/server.crt; ssl_certificate_key /etc/ssl/certs/server.key;)
Varat izmantot tikai spēcīgas SSL/TLS versijas un šifrus ar ssl_protocols un ssl_ciphers direktīvām, vai arī varat iestatīt savus vēlamos protokolus un šifrus:
pasts ( #... ssl_protocols TLSv1 TLSv1.1 TLSv1.2 ; ssl_ciphers HIGH:!aNULL:!MD5 ; )
SSL/TLS optimizēšana pasta starpniekserverim
Šie padomi palīdzēs padarīt jūsu NGINX pasta starpniekserveri ātrāku un drošāku:
Iestatiet darbinieku procesu skaitu, kas vienāds ar procesoru skaitu, ja direktīvu worker_processes ir iestatītas tādā pašā līmenī kā pasta konteksts:
darbinieka_procesi auto ; pasts (#...)
Iespējojiet koplietoto sesijas kešatmiņu un atspējojiet iebūvēto sesijas kešatmiņu, izmantojot automātisko ; pasts ( servera_nosaukums mail.example.com ; auth_http localhost : 9000 /cgi-bin/nginxauth.cgi ; proxy_pass_error_message on ; ssl on ; ssl_certificate /etc/ssl/certs/server_slkeyer atslēga; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers HIGH:!aNULL:!MD5; ssl_session_cache share:SSL:10m; ssl_session_timeout 10m; ssl_session_timeout 10m; serveris (klausīt ; protokols pop3 ; pop3_auth vienkāršs apop cram-md5 ; ) serveris ( klausieties 143 ; protokola imap ; ) )
Šajā piemērā ir trīs e-pasta starpniekserveri: SMTP, POP3 un IMAP. Katrs no serveriem ir konfigurēts ar SSL un STARTTLS atbalstu. SSL sesijas parametri tiks saglabāti kešatmiņā.
Starpniekserveris izmanto HTTP autentifikācijas serveri — tā konfigurācija ir ārpus šī raksta darbības jomas. Visi kļūdu ziņojumi no servera tiks atgriezti klientiem.
Nginx- mazs izmērs, ļoti ātrs, diezgan funkcionāls tīmekļa serveris un pasta starpniekserveris, izstrādātājs Igors Sysoev (rambler.ru). Sakarā ar ļoti zemo sistēmas resursu patēriņu un ātrumu, kā arī konfigurācijas elastību, web nginx serveris bieži izmanto kā priekšgalu smagākiem serveriem, piemēram Apache, lielas slodzes projektos. Klasiskais variants ir ķekars, Nginx - Apache - FastCGI. Strādājot šādā shēmā, nginx serveris, pieņem visus pieprasījumus, kas nāk caur HTTP, un atkarībā no konfigurācijas un paša pieprasījuma izlemj, vai apstrādāt pieprasījumu pašu un sniegt klientam gatavu atbildi vai nosūtīt apstrādes pieprasījumu uz kādu no aizmugursistēm ( Apache vai FastCGI).
Kā zināms, Apache serveris katru pieprasījumu apstrādā atsevišķā procesā (thread), kas, jāsaka, patērē diezgan NE mazu sistēmas resursu, ja tādi procesi ir 10-20, tas ir absurds, un ja ir ir 100-500 vai vairāk, sistēma kļūst nejautra.
Mēģināsim iedomāties šādu situāciju. Pieņemsim, ka ieslēgts Apache 300 HTTP pieprasījumi nāk no klientiem, 150 klienti sēž uz ātrajām nomātajām līnijām, bet pārējie 150 - salīdzinoši lēnos interneta kanālos, pat ja ne modemos. Kas notiek šajā situācijā? Un notiek sekojošais: Apache tīmekļa serveris, lai apstrādātu šos 300 savienojumus, izveido katram procesam (pavedienam), ātri ģenerēs saturu, un 150 ātrie klienti uzreiz uzņems savu pieprasījumu rezultātu, procesus, kas tos apkalpoja. tiks nogalināti un resursi tiks atbrīvoti, un 150 ir lēni, un tas lēni uzņems viņu vaicājumu rezultātus šaurā interneta kanāla dēļ, kā rezultātā sistēmā karāsies 150 procesi Apache, gaidot, kad klienti paņems tīmekļa servera ģenerēto saturu, aprijot daudz sistēmas resursu. Protams, situācija ir hipotētiska, bet es domāju, ka būtība ir skaidra. Lai labotu iepriekš minēto situāciju, un komplekts palīdz. Pēc visa klienta pieprasījuma izlasīšanas tas nodod to apstrādei Apache, kas savukārt ģenerē saturu un pēc iespējas ātrāk atgriež gatavu atbildi Nginx, pēc tam ar tīru sirdsapziņu var nogalināt procesu un atbrīvot sistēmas resursus, ko tas aizņem. Nginx tīmekļa serveris, kas saņem pieprasījuma rezultātu no Apache, ieraksta to buferī vai pat failā diskā un var patvaļīgi ilgu laiku dot lēniem klientiem, kamēr tā strādnieku procesi patērē tik maz resursu, ka .. "par to ir pat smieklīgi runāt" ©. :) Šāda shēma ievērojami ietaupa sistēmas resursus, es atkārtoju, bet Nginx darba procesi patērē niecīgu resursu daudzumu, jo vairāk tas attiecas uz lieliem projektiem.
Un šī ir tikai neliela daļa no tā, ko var paveikt Nginx serveris, neaizmirstiet par iespēju saglabāt datus kešatmiņā un strādāt ar iespiests atmiņā. Šeit ir Nginx tīmekļa servera galveno funkciju saraksts.
Nginx servera kā HTTP servera funkcionalitāte
- Statiskā satura apstrāde, indeksa faili, direktoriju saraksts, atvērtā failu deskriptora kešatmiņa;
- Paātrināta starpniekservera izmantošana ar kešatmiņu, slodzes līdzsvarošanu un kļūmjpārlēci;
- Paātrināts atbalsts FastCGI serveri ar kešatmiņu, slodzes līdzsvarošanu un kļūdu toleranci;
- Modulāra struktūra, atbalsts dažādiem filtriem (SSI, XSLT, GZIP, CV, chunked responses);
- Atbalsts SSL un TLS SNI paplašinājumiem;
- uz ip bāzes vai uz vārda bāzes virtuālie serveri;
- Darbs ar KeepAlive un cauruļvadu savienojumiem;
- Iespēja konfigurēt visus taimautus, kā arī buferu skaitu un lielumu līmenī Apache serveris;
- Dažādu darbību veikšana atkarībā no klienta adreses;
- URI maiņa, izmantojot regulārās izteiksmes;
- Īpašas kļūdu lapas 4xx un 5xx;
- Piekļuves ierobežojums, pamatojoties uz klienta adresi vai paroli;
- Žurnāla failu formātu iestatīšana, žurnāla rotācija;
- Ierobežot atbildes ātrumu klientam;
- Vienlaicīgu savienojumu un pieprasījumu skaita ierobežošana;
- PUT, DELETE, MKCOL, COPY un MOVE metožu atbalsts;
- Iestatījumu maiņa un servera atjaunināšana, nepārtraucot darbu;
- iebūvēts Perl;
Nginx servera kā pasta starpniekservera funkcionalitāte
- Pārsūtīšana uz IMAP/POP3 aizmugursistēmu, izmantojot ārēju HTTP autentifikācijas serveri;
- Lietotāja SMTP pārbaude ārējā HTTP autentifikācijas serverī un pārsūtīšana uz iekšējo SMTP serveri;
- Atbalsts šādām autentifikācijas metodēm:
- POP3 - LIETOTĀJS/PASS, APOP, AUTH LOGIN/PLAIN/CRAM-MD5;
- IMAP — LOGIN, AUTH LOGIN/PLAIN/CRAM-MD5;
- SMTP - AUTH LOGI / PLAIN / CRAM-MD5;
- SSL atbalsts;
- STARTTLS un STLS atbalsts;
Operētājsistēmas un platformas, ko atbalsta Nginx tīmekļa serveris
- FreeBSD, platformas no 3 līdz 8, i386 un amd64;
- Linux, no 2.2 līdz 2.6 - i386 platforma; Linux 2.6 - amd64;
- Solaris 9 - i386 un sun4u platformas; Solaris 10 - i386, amd64 un sun4v platformas;
- MacOS X platformas ppc, i386;
- Windows XP, Windows Server 2003; (Pašlaik tiek testēts beta versijā)
Nginx servera arhitektūra un mērogojamība
- Galvenais (galvenais) process, vairāki (konfigurācijas failā konfigurēti) strādnieku procesi, kas darbojas bezpriviliģēta lietotāja vadībā;
- Atbalsts šādām savienojuma apstrādes metodēm:
- izvēlieties ir standarta metode. Atbilstošais Nginx modulis tiek izveidots automātiski, ja konkrētajā platformā netiek atrasta efektīvāka metode. Varat piespiest šī moduļa būvējumu ieslēgt vai izslēgt, izmantojot konfigurācijas opcijas --with-select_module vai --without-select_module.
- aptauja ir standarta metode. Atbilstošais Nginx modulis tiek izveidots automātiski, ja konkrētajā platformā netiek atrasta efektīvāka metode. Varat piespiest šī moduļa būvējumu ieslēgt vai izslēgt, izmantojot konfigurācijas opcijas --with-poll_module vai --without-poll_module.
- kqueue ir efektīva metode, ko izmanto operētājsistēmās FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0 un MacOS X. Lietojot divu procesoru MacOS X iekārtās, tā var izraisīt kodola paniku.
- epoll ir efektīva metode, ko izmanto operētājsistēmā Linux 2.6+. Dažiem izplatījumiem, piemēram, SuSE 8.2, ir ielāpi, lai atbalstītu epoll 2.4 kodolā.
- rtsig - reāllaika signāli, efektīva metode, ko izmanto operētājsistēmā Linux 2.2.19+. Pēc noklusējuma visas sistēmas rindā var būt ne vairāk kā 1024 signāli. Ar to nepietiek serveriem ar lielu slodzi, rindas lielums ir jāpalielina, izmantojot /proc/sys/kernel/rtsig-max kodola parametru. Taču no Linux 2.6.6-mm2 šī opcija ir noņemta, tā vietā katram procesam ir atsevišķa signāla rinda, kuras lielumu nosaka RLIMIT_SIGPENDING.
- Kad rinda ir pilna, nginx serveris atiestata to un apstrādā savienojumus ar aptaujas metodi, līdz situācija atgriežas normālā stāvoklī.
- /dev/poll- efektīva metode, kas atbalstīta operētājsistēmās Solaris 7 11/99+, HP/UX 11.22+ (eventport), IRIX 6.5.15+ un Tru64 UNIX 5.1A+.
- eventport - notikumu porti, efektīva metode, ko izmanto Solaris 10. Pirms lietošanas ir jāuzstāda ielāps, lai izvairītos no kodola panikas.
- Izmantojot kqueue metodes iespējas, piemēram, EV_CLEAR, EV_DISABLE (lai īslaicīgi atspējotu notikumu), NOTE_LOWAT, EV_EOF, pieejamo datu skaits, kļūdu kodi;
- Darbs ar sendfile (FreeBSD 3.1+, Linux 2.2.+, Mac OS X 10.5+), sendfile64 (Linux 2.4.21+) un sendfile (Solaris 8 7/01+);
- Atbalsts pieņemšanas filtriem (FreeBSD 4.1+) un TCP_DEFER_ACCEPT (Linux 2.4+);
- 10 000 dīkstāves HTTP uzturēšanas savienojumu patērē aptuveni 2,5 M atmiņas;
- Minimālais datu kopēšanas operāciju skaits;
iRedMail ir atvērtā koda pasta servera versija. Montāžas pamatā ir Postfix SMTP serveris (Mail Transfer Agent, saīsināti MTA). Komplektācijā ietilpst arī: Dovecot, SpamAssassin, Greylist, ClamAV, SOGo Roundcube, NetData un NGINX.
Baložu kūts- IMAP/POP3 serveris.
Spamassassin- surogātpasta filtrēšanas rīks.
Pelēkais saraksts- pretsurogātpasta rīks, kura pamatā ir pelēkie saraksti.
ClamAV- antivīruss.
Apaļkubs un SOGo- Web klienti darbam ar e-pastu.
Tīkla dati- programma servera darbības uzraudzībai reāllaikā.
Nginx- tīmekļa serveris.
Atbalsta operētājsistēmas: CentOS 7, Debian 9, Ubuntu 16.04/18.04, FreeBSD 11/12 un OpenBSD 6.4.
iRedMail ir maksas un bezmaksas versijas, kas viena no otras atšķiras ar paša iRedAdmin pasta komplekta tīmekļa saskarnes funkcionalitāti. Bezmaksas versijā varat izveidot tikai domēnus, lietotāju un administratoru pastkastes. Ja jums ir jāizveido aizstājvārds, jūs to nevarēsit izdarīt bezmaksas versijā, izmantojot iRedAdmin. Par laimi, ir pieejams bezmaksas risinājums PostfixAdmin, kas ļauj to izdarīt. PostfixAdmin viegli integrējas ar iRedMail un lieliski darbojas ar to.
Uzstādīšana
Lai instalētu, mums ir nepieciešama viena no iepriekš minētajām operētājsistēmām. Es izmantošu Ubuntu Server 18.04. Jums ir jābūt arī iegādātam domēna nosaukumam un konfigurētai DNS zonai. Ja izmantojat sava domēna reģistratora DNS serveri, tad domēna zonas pārvaldības sadaļā ir jāveic divi ieraksti: A un MX. Varat arī izmantot savu DNS, iestatot deleģēšanu sava domēna vārda reģistratūras personīgajā kontā.
Domēna zonas iestatīšana, izmantojot DNS reģistratūru
Piezīme! DNS iestatījumi stājas spēkā no vairākām stundām līdz vienai nedēļai. Kamēr iestatījumi stāsies spēkā, pasta serveris nedarbosies pareizi.
Lai instalētu, lejupielādējiet pašreizējo versiju no iRedMail vietnes. Šobrīd tas ir 0,9,9.
# wget https://bitbucket.org/zhb/iredmail/downloads/iRedMail-0.9.9.tar.bz2
Pēc tam izsaiņojiet lejupielādēto arhīvu.
# tar xjf iRedMail-0.9.9.tar.bz2
Arhīva izpakošana
Un dodieties uz izveidoto mapi.
# cd iRedMail-0.9.9
Mape ar iRedMail instalētāju
Mapes satura pārbaude
Mapes saturs
Un palaidiet iRedMail instalācijas skriptu.
# bash iRedMail.sh
Sāksies pasta sistēmas instalēšana. Instalēšanas procesa laikā jums būs jāatbild uz vairākiem jautājumiem. Mēs piekrītam sākt instalēšanu.
Uzstādīšanas sākums
Instalācijas direktorija izvēle
Tagad jums ir jāizvēlas tīmekļa serveris. Izvēle nav liela, tāpēc izvēlamies NGINX.
Tīmekļa servera izvēle
Tagad jums ir jāizvēlas datu bāzes serveris, kas tiks instalēts un konfigurēts darbam ar pasta sistēmu. Izvēlieties MariaDB.
Datu bāzes servera izvēle
Iestatiet datu bāzes saknes paroli.
Datu bāzes saknes paroles izveide
Tagad mēs norādām savu pasta domēnu.
Pasta domēna izveide
Pēc tam izveidojiet paroli administratora lodziņā [aizsargāts ar e-pastu] domain.ru.
Izveidojiet pasta administratora paroli
Web komponentu izvēle
Mēs apstiprinām norādītos iestatījumus.
Iestatījumu apstiprināšana
Sākta instalēšana.
Uzstādīšana
Kad instalēšana ir pabeigta, apstipriniet kārtulas izveidi iptables priekš SSH un restartējiet ugunsmūri. iRedMail darbojas ar iptables. Ubuntu, visbiežāk izmantotā ugunsmūra pārvaldības utilīta UVW. Ja kāda iemesla dēļ jums ir tāda vajadzība, instalējiet UVW (apt instalēt ufw) un pievienojiet noteikumus UVW(piemērs: ufw atļaut "nginx full" vai ufw atļaut Postfix) nebloķēja pasta serveri. Varat apskatīt pieejamo noteikumu sarakstu, izpildot komandu: ufw lietotņu saraksts. Pēc tam ieslēdziet UVW: ufw iespējot.
Izveidojiet iptables kārtulu
Ugunsmūra restartēšana
Tas pabeidz iRedMail instalēšanu. Sistēma mums iedeva tīmekļa saskarnes adreses un pieteikšanās akreditācijas datus. Lai iespējotu visus pasta sistēmas komponentus, restartējiet serveri.
Instalācijas beigas
Mēs pārstartējam.
# atsāknēšana
Iestatījums
Vispirms jums jāpārliecinās, ka viss darbojas. Mēs cenšamies iekļūt iReadAdmin vadības panelī plkst https://domain/iredadmin. Pieslēgties [aizsargāts ar e-pastu] domain.ru, parole tika izveidota instalēšanas laikā. Ir krievu valodas interfeiss.
Kā redzat, viss darbojas. Piesakoties iRedAdmin, jūs, visticamāk, saņēmāt drošības kļūdu saistībā ar sertifikātu. Tas ir tāpēc, ka iRedMail ir pašparakstīts sertifikāts, kuru pārlūkprogramma apņemas. Lai novērstu šo problēmu, jums ir jāinstalē derīgs SSL sertifikāts. Ja esat to iegādājies, varat to instalēt. Piemērā es instalēšu bezmaksas SSL no Let's Encrypt.
Let's Encrypt SSL sertifikāta instalēšana
Mēs instalēsim sertifikātu, izmantojot utilītu certbot. Vispirms pievienosim repozitoriju.
# add-apt-repository ppa:certbot/certbot
Pēc tam instalējam pašu certboot ar nepieciešamajiem komponentiem.
# apt instalēt python-certbot-nginx
Saņemam sertifikātu.
# certbot --nginx -d domain.ru
Pēc komandas palaišanas sistēma lūgs ievadīt e-pasta adresi, ievadiet. Pēc tam, visticamāk, tiks parādīts kļūdas ziņojums, ka nav iespējams atrast servera bloku, kuram tika ģenerēts sertifikāts. Šajā gadījumā tas ir normāli, jo mums nav neviena servera bloka. Mums galvenais ir iegūt sertifikātu.
Sertifikāta iegūšana
Kā redzat, sertifikāts tika veiksmīgi saņemts un sistēma mums parādīja ceļus līdz pašam sertifikātam un atslēgai. Tie ir tieši tie, kas mums ir vajadzīgi. Kopumā mēs saņēmām 4 failus, kas tiks saglabāti mapē "/etc/letsencrypt/live/domain". Tagad mums ir jāpaziņo tīmekļa serverim par mūsu sertifikātu, tas ir, jāaizstāj iegultais sertifikāts ar to, ko tikko saņēmām. Lai to izdarītu, mums ir jārediģē tikai viens fails.
# nano /etc/nginx/templates/ssl.tmpl
Un mainiet tajā pēdējās divas rindiņas.
SSL sertifikāta nomaiņa
Mēs mainām failā esošos ceļus uz tiem ceļiem, kurus sistēma mums teica, saņemot sertifikātu.
SSL sertifikāta aizstāšana
Un restartējiet NGINX.
# pakalpojuma nginx restartēšana
Tagad mēģināsim pieteikties vēlreiz. iRedAdmin.
SSL sertifikāta pārbaude
Sertifikāta kļūdu vairs nav. Sertifikāts ir derīgs. Varat noklikšķināt uz slēdzenes un redzēt tās īpašības. Kad sertifikāta derīguma termiņš beidzas, programmai certboot tas automātiski jāatjauno.
Tagad parunāsim par Dovecot un Postfix sertifikātu. Lai to izdarītu, mēs rediģēsim divus konfigurācijas failus. Mēs darām:
# nano /etc/dovecot/dovecot.conf
Bloka atrašana:
#SSL: globālie iestatījumi.
Un tur reģistrēto sertifikātu nomainām pret savējo.
Dovecot sertifikāta nomaiņa
Pievērsiet uzmanību arī rindai "ssl_protocols". Tās vērtībai ir jābūt "!SSLv3", pretējā gadījumā tiks parādīts kļūdas ziņojums "Brīdinājums: OpenSSL neatbalsta SSLv2. Lūdzu, apsveriet iespēju to noņemt no ssl_protocols", restartējot Dovecot.
# nano /etc/postfix/main.cf
Bloka atrašana:
# SSL atslēga, sertifikāts, CA
Un mēs tajā esošos ceļus mainām uz ceļiem uz mūsu sertifikāta failiem.
Sertifikāta nomaiņa Postfix
Tas pabeidz sertifikāta instalēšanu. Ir nepieciešams restartēt Dovecot un Postfix, bet labāk ir restartēt serveri.
# servisa baloža restartēšana
# atsāknēšana
PHPMyAdmin instalēšana
Šis vienums nav obligāts, taču iesaku to aizpildīt un instalēt PHPMyAdmin, lai izmantotu datubāzi.
# apt instalēt phpmyadmin
Instalēšanas programma lūgs jums strādāt ar kuru tīmekļa serveri konfigurēt PHPMyAdmin, jo NGINX nav šajā sarakstā, vienkārši nospiediet TAB un turpiniet.
PHPMyAdmin instalēšana
Kad instalēšana ir pabeigta, lai phpmyadmin darbotos, jums ir jāizveido saite uz direktoriju, ar kuru NGINX darbojas pēc noklusējuma.
# ln -s /usr/share/phpmyadmin /var/www/html
Un mēģiniet iet uz https://domain/phpmyadmin/
PHPMyAdmin darbojas. Savienojums ir aizsargāts ar sertifikātu, kļūdu nav. Dodieties tālāk. Izveidosim MySQL datu bāzes administratoru (MariaDB).
# mysql
Un mēs nokļūstam MariaDB pārvaldības konsolē. Tālāk mēs izpildām komandas pa vienam:
MariaDB > IZVEIDOT LIETOTĀJU "admin"@"localhost" Identificēts AR "paroli";
MariaDB > PIEŠĶIRT VISAS PRIVILĒĢIJAS *.* UZ "admin"@"localhost" AR PIEŠĶIRŠANAS OPTION;
MariaDB > FLUSH PRIVILĒĢIJAS;
MySQL lietotāja izveide
Viss ir kārtībā, jūs esat pieteicies. PHPMyAdmin ir gatavs darbam.
PostfixAdmin instalēšana
Principā PostfixAdmin, tāpat kā PHPMyAdmin, nevar instalēt. Pasta serveris darbosies lieliski bez šiem komponentiem. Bet tad jūs nevarēsit izveidot pasta aizstājvārdus. Ja jums tas nav nepieciešams, izlaidiet šīs sadaļas. Ja jums joprojām ir nepieciešami aizstājvārdi, jums ir divas iespējas: iegādāties iReaAdmin maksas versiju vai instalēt PostfixAdmin. Protams, jūs varat to izdarīt bez papildu programmatūras, manuāli ierakstot aizstājvārdus datu bāzē, taču tas ne vienmēr ir ērti un nav piemērots visiem. Es iesaku izmantot PostfixAdmin, tagad mēs apsvērsim tā instalēšanu un integrāciju ar iRedMail. Mēs sākam instalēšanu:
# apt install postfixadmin
Mēs vienojamies un izveidojam paroli programmas sistēmas datubāzei.
PostfixAdmin instalēšana
PostfixAdmin instalēšana
Mēs izveidojam simbolisku saiti pēc analoģijas ar PHPMyAdmin instalēšanu.
# ln -s /usr/share/postfixadmin /var/www/html
Mēs padarām lietotāju, kura vārdā tiek palaists tīmekļa serveris, par direktorija īpašnieku. Mūsu gadījumā NGINX tiek palaists kā www-data lietotājs.
# chown -R www-data /usr/share/postfixadmin
Tagad mums ir jārediģē PostfixAdmin konfigurācijas fails un jāpievieno informācija par datu bāzi, ko izmanto iRedAdmin. Pēc noklusējuma šo datu bāzi sauc par vmail. Ja dodaties uz PHPMyAdmin, varat to redzēt tur. Un tāpēc, lai PostfixAdmin veiktu izmaiņas datu bāzē, mēs to paredzam PostfixAdmin konfigurācijā.
# nano /etc/postfixadmin/config.inc.php
Līniju atrašana:
$CONF["datubāzes_tips"] = $dbtype;
$CONF["datubāzes_host"] = $dbserveris;
$CONF["datubāzes_lietotājs"] = $dbuser;
$CONF["datubāzes_parole"] = $dbpass;
$CONF["datubāzes_nosaukums"] = $dbname;
Un atcerieties:
$CONF["database_type"] = "mysqli"; # Datu bāzes tips
$CONF["database_host"] = "localhost"; # Datu bāzes servera resursdators
$CONF["database_user"] = "administrators"; # Piesakieties ar rakstīšanas piekļuvi vmail datu bāzei. Varat izmantot iepriekš izveidoto administratoru
$CONF["database_password"] = "parole"; # Iepriekš norādītā lietotāja parole
$CONF["datubāzes_nosaukums"] = "vmail"; # iRedMail datu bāzes nosaukums
Datu bāzes informācijas ievadīšana
Ja plānojat izmantot SOGo tīmekļa pasta klientu, jums ir jāveic vēl viena papildu darbība, proti, rindkopā jāmaina PostfixAdmin šifrēšana $CONF["šifrēt"] ar "md5crypt" uz "balodis: SHA512-CRYPT". Ja jūs to neizdarīsiet, tad, mēģinot SOGo autorizēties ar PostfixAdmin izveidoto lietotāju, tiks parādīts kļūdas ziņojums ar nepareizu pieteikumvārdu vai paroli.
Šifrēšanas veida maiņa
Tagad, lai veiksmīgi pabeigtu instalēšanu un nerastos kļūdas, jums ir jāveic datu bāze. To ir ērti izdarīt, izmantojot PHPMyAdmin. Atlasiet vmail datu bāzi un dodieties uz cilni SQL. Logā ievadiet:
DROP INDEX domēnu pastkastē;
DROP INDEX domēnu uz aizstājvārda;
ALTER TABLE aizstājvārdu ADD COLUMN `goto` teksts NOT NULL;
Datu bāzes vaicājums
Un nospiediet "Uz priekšu". Tagad viss ir iestatīts, varat doties uz PostfixAdmin tīmekļa saskarni un pabeigt instalēšanu. Lai to izdarītu, pārlūkprogrammā jāievada: https://domain/postfixadmin/setup.php.
Jāparāda sekojošais:
PostfixAdmin instalēšana
Ja viss tiek darīts saskaņā ar instrukcijām, tad kļūdām nevajadzētu būt. Ja tie joprojām ir, tad tiek nodoti, lai tos likvidētu, pretējā gadījumā sistēma neļaus jums turpināt. Iestatiet instalācijas paroli un noklikšķiniet uz " Ģenerēt paroles jaucējkodu". Sistēma ģenerēs paroles jaucējkodu, kas jāievada parametrā $CONF["setup_password"].
PostfixAdmin instalēšanas pabeigšana
Konfigurācijas faila iestatījumu maiņa
Tagad mēs ievadām tikko izveidoto paroli un izveidojam PostfixAdmin administratoru. Labāk nav izveidot administratoru ar postmaster pieteikšanos, jo var rasties problēmas ar pieteikšanos iRedAdmin administrācijas panelī.
PostfixAdmin administratora izveide
Viss, administrators ir izveidots. Jūs varat pierakstīties.
Lūdzu, ņemiet vērā, ka no drošības viedokļa ir labāk pārdēvēt vai izdzēst failu setup.php direktorijā postfixadmin.
Ejam: https://domain/postfixadmin/ un ievadiet jaunizveidotos akreditācijas datus. PostfixAdmin, kā arī iRedAdmin ir pieejama krievu valoda. To var izvēlēties autorizācijas laikā.
Mēs cenšamies izveidot lietotāja pastkasti.
Iespējot/atspējot iRedMail moduļus
iRedMail moduļus pārvalda iRedAPD. Tam ir konfigurācijas fails, kurā ir darba moduļi. Ja jums nav nepieciešams konkrēts modulis, varat to noņemt no konfigurācijas faila, un tas pārtrauks darboties. Mēs darām:
# nano /opt/iredapd/settings.py
Atrodiet līniju spraudņi" un izņemiet no tā sastāvdaļas, kas jums nav vajadzīgas. Es noņemšu komponentu "pelēkais saraksts". Protams, tas diezgan efektīvi pasargā no surogātpasta, taču nepieciešamie burti bieži nesasniedz.
Greylist (pelēkais saraksts) ir automātiska surogātpasta aizsardzības tehnoloģija, kuras pamatā ir sūtītāja servera darbības analīze. Ja ir iespējots "pelēkais saraksts", serveris pirmo reizi atsakās pieņemt vēstuli no nezināmas adreses, ziņojot par īslaicīgu kļūdu. Šādā gadījumā sūtītāja serverim vēlāk jāmēģina nosūtīt vēlreiz. Surogātpasta izplatītāji parasti to nedara. Ja vēstule tiek nosūtīta atkārtoti, tā tiek pievienota sarakstam uz 30 dienām un pasta apmaiņa notiek jau no pirmās reizes. Izmantojiet šo moduli vai neizlemiet pats.
Pasta moduļu iespējošana/atspējošana
Pēc izmaiņu veikšanas jums ir jārestartē. iRedAPD.
# pakalpojums iredapd restart
Pasta servera pārbaude
Tas pabeidz iRedMail pasta servera iestatīšanu. Jūs varat pāriet uz pēdējo posmu - testēšanu. Izveidosim divas pastkastītes. Lai pārbaudītu vienu, izmantojot iRedAdmin, otru, izmantojot PostfixAdmin, un nosūtītu vēstuli no vienas pastkastes uz citu un otrādi. Izveidojiet pastkasti programmā iRedAdmin [aizsargāts ar e-pastu] domain.ru. Programmā PostfixAdmin — [aizsargāts ar e-pastu] domain.ru
Lietotāja izveide programmā iRedAdmin
Lietotāja izveide programmā PostfixAdmin
Pārbaudiet, vai ir izveidoti lietotāji.
Ja pievēršat uzmanību slejai "Kam" PostfixAdmin pastkastu sarakstā, varat redzēt atšķirību starp pastkastēm, kas izveidotas programmās iRedAdmin un PostfixAdmin. Programmā iRedAdmin izveidotās pastkastes ir atzīmētas kā " tikai uz priekšu", un tie, kas izveidoti programmā PostfixAdmin kā - " Pastkaste". Sākumā es ilgu laiku nevarēju saprast, kāpēc tas notiek un kāda ir atšķirība starp tām, un beidzot pamanīju vienu lietu. Pastkastes programmā iRedAdmin tiek veidotas bez aizstājvārdiem, savukārt PostfixAdmin pastkastes ar aizstājvārdu sev.
Un, ja šie aizstājvārdi tiek izdzēsti, pastkastes tiks parādītas kā tās, kas izveidotas programmā iRedAdmin. tikai uz priekšu".
Pseidonīmu noņemšana
Pseidonīmi ir noņemti. Pārbaudiet PostfixAdmin.
Kā redzat, visas kastes ir kļuvušas par "Tikai uz priekšu". Tādā pašā veidā, ja iRedAdmin izveidotajā pastkastē izveidojat sev aizstājvārdu, tas kļūs par "Pastkaste". Principā tas neietekmē pasta darbību. Vienīgais ir tas, ka jūs nevarēsit izveidot aizstājvārdu pastkastē, kas izveidota programmā PostfixAdmin. Tā vietā, lai izveidotu aizstājvārdu, jums būs jārediģē esošs aizstājvārds. Runājot par aizstājvārdiem, jaunajā iRedMail versijā jums ir jāveic izmaiņas vienā no Postfix kartēm, kas ir atbildīga par aizstājvārdiem. Un, ja jūs to nedarīsit, izveidotie aizstājvārdi nedarbosies. Šim nolūkam tas ir nepieciešams failā /etc/postfix/mysql/virtual_alias_maps.cf izlabot:
Mēs darām:
# nano /etc/postfix/mysql/virtual_alias_maps.cf
Un mēs to salabojam.
Pseidonīmu iestatīšana
Restartējiet Postfix:
# pakalpojuma postfix restartēšana
Pēc tam visam vajadzētu darboties.
Un tā, sāksim pārbaudīt pastu. Kastē lietotājs1 mēs iesim cauri Roundcube un iesim kastē lietotājs2- izmantojot SOGo un nosūtīt vēstuli no pastkastītes lietotājs1 uz lietotājs2 un atpakaļ.
E-pasta sūtīšana ar Roundcube
E-pasta saņemšana SOGo
E-pasta sūtīšana uz SOGo
E-pasta saņemšana Roundcube
Viss darbojas bez problēmām. Vēstules piegāde ilgst no divām līdz piecām sekundēm. Tādā pašā veidā vēstules tiek lieliski piegādātas Yandex un mail.ru serveriem (pārbaudīts).
Tagad pārbaudīsim aizstājvārdus. Izveidosim kastīti lietotājs3 un izveidojiet aizstājvārdu no pastkastes lietotājs1 uz kastes lietotājs2. Un nosūtiet vēstuli no kastes lietotājs3 uz kastes lietotājs1. Šajā gadījumā vēstulei būs jānonāk kastē lietotājs2.
Izveidojiet aizstājvārdu
E-pasta sūtīšana no lietotāja 3 pastkastes uz lietotāja 1 pastkasti
Vēstules saņemšana lietotāja2 pastkastē
Arī ar pseidonīmu darbu viss ir kārtībā.
Pārbaudīsim pasta servera darbību caur vietējo pasta klientu. Piemēram, apsveriet Mozilla Thunderbird. Izveidosim vēl divus lietotājus: klients1 un klients2. Vienu pastkastīti savienosim caur IMAP, otru caur POP3 un nosūtīsim vēstuli no vienas pastkastītes uz otru.
Savienojuma izveide, izmantojot IMAP
POP3 savienojums
Mēs nosūtām vēstuli no 1. klienta klientam 2.
Nosūtīšana no klienta 1
Saņemt uz Client 2
Un apgrieztā secībā.
Sūtīšana no klienta 2
Saņemt uz Klienta 1
Viss darbojas.
Ja dodaties uz: https://domain/netdata, tad var novērot sistēmas stāvokļa grafikus.
Secinājums
Tas pabeidz iRedMail pasta sistēmas instalēšanu, konfigurēšanu un testēšanu. Rezultātā ieguvām pilnīgi bezmaksas pilnvērtīgu pasta serveri ar derīgu SSL sertifikātu, divus dažādus tīmekļa pasta klientus, divus vadības paneļus, kā arī pastā iebūvētu pretspam un antivīrusu. Ja vēlaties, tīmekļa pasta klientu vietā varat izmantot vietējos pasta klientus, piemēram, Microsoft Outlook vai Mozilla Thunderbird. Ja neplānojat izmantot tīmekļa pasta klientus, varat tos vispār neinstalēt, lai nepārslogotu serveri, vai instalēt vienu lietu, kas jums patīk vairāk. Man personīgi SOGo patīk vairāk, jo tā interfeiss ir optimizēts mobilajām ierīcēm, kas ļauj ļoti ērti skatīt e-pastu no viedtālruņa. Tas pats attiecas uz NetData un iRedAdmin, ja neplānojat to izmantot, labāk to neinstalēt. Šī pasta sistēma nav īpaši prasīga pret resursiem. Tas viss darbojas VPS serverī ar 1024 MB RAM un vienu virtuālo procesoru. Ja jums ir kādi jautājumi par šo pasta sistēmu, rakstiet komentāros.
P.S. Testējot šo produktu dažādās operētājsistēmās ar 1 GB RAM (Ubuntu, Debian, CentOS), izrādījās, ka ClamAV darbībai nepietiek ar 1 GB. Gandrīz visos gadījumos, izmantojot 1 GB atmiņu, antivīruss atsaucās uz datu bāzes kļūdu. Tajā pašā laikā operētājsistēmās Debian un Ubuntu antivīruss vienkārši neskenē pastu, kas iet caur serveri, pretējā gadījumā viss darbojās labi. CentOS situācija bija nedaudz atšķirīga. Clamd pakalpojums pilnībā pārtrauca sistēmu, tādējādi padarot neiespējamu servera normālu darbību. Mēģinot pieteikties tīmekļa saskarnēs, NGINX periodiski sniedza 502 un 504 kļūdas. Laika gaitā tika nosūtīts arī pasts. Tajā pašā laikā, ja pievienojat RAM līdz 2 GB, tad visos gadījumos nebija problēmu ar antivīrusa un servera darbību kopumā. ClamAV skenēja pastu, kas iet caur pasta serveri, un ierakstīja par to žurnālos. Mēģinot nosūtīt vīrusu pielikumā, sūtīšana tika bloķēta. Atmiņas patēriņš bija aptuveni 1,2–1,7 GB.
NGINX var izmantot ne tikai kā tīmekļa serveri vai http starpniekserveri, bet arī pasta starpniekserveri, izmantojot SMTP, IMAP, POP3 protokolus. Tas iestatīs:
- Vienots ieejas punkts mērogojamai pasta sistēmai.
- Slodzes līdzsvarošana starp visiem pasta serveriem.
Šis raksts tiek instalēts operētājsistēmā Linux. Kā pasta pakalpojumu, uz kuru tiek nosūtīti pieprasījumi, varat izmantot postfix, exim, dovecot, Exchange, iredmail montāžu un daudz ko citu.
Darbības princips
NGINX pieņem pieprasījumus un autentificējas tīmekļa serverī. Atkarībā no pieteikšanās un paroles pārbaudes rezultāta starpniekserveris atgriezīs atbildi ar vairākām galvenēm.
Veiksmes gadījumā:
Tādējādi mēs nosakām pasta servera serveri un portu, pamatojoties uz autentifikāciju. Tas dod daudz iespēju ar atbilstošām programmēšanas valodu zināšanām.
Neveiksmes gadījumā:
Atkarībā no autentifikācijas rezultāta un galvenes klients tiek novirzīts uz mums nepieciešamo pasta serveri.
Servera sagatavošana
Veiksim dažas izmaiņas servera drošības iestatījumos.
SELinux
Atspējojiet SELinux, ja izmantojat CentOS vai šo drošības sistēmu Ubuntu:
vi /etc/selinux/config
SELINUX=atspējots
Ugunsmūris
Ja mēs izmantojam ugunsmūri(pēc noklusējuma CentOS):
firewall-cmd --permanent --add-port=25/tcp --add-port=110/tcp --add-port=143/tcp
firewall-cmd -- pārlādēt
Ja mēs izmantojam iptables(noklusējums Ubuntu):
iptables -A IEVADE -p tcp -dport 25 -j ACCEPT
iptables -A IEVADE -p tcp -dport 110 -j ACCEPT
iptables -A IEVADE -p tcp -dport 143 -j ACCEPT
apt-get instalēt iptables-persistent
iptables-save > /etc/iptables/rules.v4
* šajā piemērā mēs atļāvām SMTP (25), POP3 (110), IMAP (143).
NGINX instalēšana
Atkarībā no operētājsistēmas NGINX instalēšana nedaudz atšķiras.
vai Linux centos:
yum instalējiet nginx
vai Linux ubuntu:
apt instalēt nginx
Mēs atļaujam pakalpojuma automātisko palaišanu un startējam:
systemctl iespējot nginx
systemctl start nginx
Ja NGINX jau ir instalēts sistēmā, pārbaudiet, ar kuriem moduļiem tas darbojas:
Mēs iegūsim to opciju sarakstu, ar kurām tiek veidots tīmekļa serveris - starp tām mums vajadzētu redzēt --ar pastu. Ja vajadzīgā moduļa nav, jums ir jāatjaunina nginx
Notiek NGINX iestatīšana
Atveriet nginx konfigurācijas failu un pievienojiet opciju pastu:
vi /etc/nginx/nginx.conf
pasts (
auth_http localhost:80/auth.php;
serveris(
klausies 25;
protokols smtp;
smtp_auth pieteikšanās vienkāršs cram-md5;
}
serveris(
klausies 110;
protokols pop3;
}
serveris(
klausies 143;
protokola karte;
}
}
* kur:
- servera_nosaukums— pasta servera nosaukums, kas tiks parādīts SMTP sveiciena laikā.
- auth_http— tīmekļa serveris un URL autentifikācijas pieprasījumam.
- proxy_pass_error_message— ļauj vai liedz ziņojuma parādīšanu neveiksmīgas autentifikācijas gadījumā.
- klausies— ports, kurā tiek uzklausīti pieprasījumi.
- protokols ir lietojumprogrammas protokols, kuru klausās atbilstošais ports.
- smtp_auth— pieejamās SMTP autentifikācijas metodes.
- pop3_auth— pieejamās POP3 autentifikācijas metodes.
Sadaļā http - serveris pievienojiet:
serveris(
klausies 80 default_server;
klausies [::]:80 default_server;
...
Atrašanās vieta ~ \.php$ (
iestatīt $root_path /usr/share/nginx/html;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $saknes_ceļš$fastcgi_skripta_nosaukums;
iekļaut fastcgi_params;
fastcgi_param DOCUMENT_ROOT $saknes_ceļš;
}
...
Restartējiet nginx serveri:
systemctl restartējiet nginx
PHP instalēšana un konfigurēšana
Lai veiktu autentifikāciju, izmantojot PHP, sistēmā ir jāinstalē šādas pakotnes.
Ja CentOS:
yum instalējiet php php-fpm
Ja ubuntu:
apt-get instalēt php php-fpm
Sāciet PHP-FPM:
systemctl iespējot php-fpm
systemctl start php-fpm
Autentifikācija
Pieteikšanās vārdu un paroli pārbauda skripts, kura ceļš ir iestatīts ar opciju auth_http. Mūsu piemērā tas ir PHP skripts.
Pieteikšanās un paroles verifikācijas skripta oficiālas veidnes piemērs:
vi /usr/share/nginx/html/auth.php
* Šis skripts pieņem jebkuru pieteikumvārdu un paroli un novirza pieprasījumus uz serveriem 192.168.1.22 un 192.168.1.33 . Lai iestatītu autentifikācijas algoritmu, mēs rediģējam 61. - 64. rindiņu. 73. - 77. rinda ir atbildīga par to serveru atgriešanu, uz kuriem notiek novirzīšana - šajā piemērā, ja pieteikšanās sākas ar rakstzīmēm. "a", "c", "f", "g", tad novirzīšana būs uz serveri mailhost01, pretējā gadījumā, ieslēgts mailhost02. Serveru nosaukumu kartēšanu ar IP adresēm var iestatīt 31., 32. rindā, pretējā gadījumā zvans notiks pēc domēna nosaukuma.
Pasta servera iestatīšana
Datu apmaiņa starp NGINX starpniekserveri un pasta serveri ir skaidra. Izņēmumam ir jāpievieno iespēja autentificēties ar PLAIN mehānismu. Piemēram, lai konfigurētu baložu novietni, rīkojieties šādi:
vi /etc/dovecot/conf.d/10-auth.conf
Pievienot rindas:
tālvadības pults 192.168.1.11 (
disable_plaintext_auth = nē
}
* šajā piemērā mēs atļāvām PLAIN autentifikācijas pieprasījumus no servera 192.168.1.11 .
Mēs arī pārbaudām:
* ja ssl būs nozīme nepieciešams, pārbaude nedarbosies, jo izrādās, ka no vienas puses serveris atļauj pieprasījumus skaidrā, bet prasa ssl šifrēšanu.
Restartējiet pakalpojumu Dovecot:
systemctl restartējiet dovecot
Klienta iestatīšana
Varat turpināt pārbaudīt mūsu starpniekservera iestatījumus. Lai to izdarītu, klienta iestatījumos norādiet nginx servera adresi vai nosaukumu kā IMAP/POP2/SMTP, piemēram:
* šajā piemērā pasta klients ir konfigurēts, lai izveidotu savienojumu ar serveri 192.168.1.11 ar atvērtām ostām 143 (IMAP) un 25 (SMTP).
Šifrēšana
Tagad iestatīsim SSL savienojumu. Nginx ir jāveido ar moduli mail_ssl_module- pārbaudiet ar komandu:
Ja nav vajadzīgā moduļa, mēs pārbūvējam nginx.
Pēc mūsu konfigurācijas faila rediģēšanas:
vi /etc/nginx/nginx.conf
pasts (
servera_nosaukums mail.domain.local;
auth_http localhost/auth.php;
proxy_pass_error_message ieslēgts;
SSL ieslēgts;
ssl_certificate /etc/ssl/nginx/public.crt;
ssl_certificate_key /etc/ssl/nginx/private.key;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_session_cache share:SSL:10m;
ssl_session_timeout 10m;
serveris(
klausies 110;
protokols pop3;
pop3_auth vienkāršs apop cram-md5;
}
serveris(
klausies 143;
protokola karte;
}
Iemesls: SELinux drošības sistēma ir aktivizēta.
Risinājums: atspējojiet vai konfigurējiet SELinux.
