Nginx სწრაფად იძენს პოპულარობას, გადადის მხოლოდ სტატიკური სერვისის ამაჩქარებლიდან Apache-სთვის სრულფასოვანი და მოწინავე ვებ სერვერზე, რომელიც სულ უფრო ხშირად გამოიყენება იზოლირებულად. ამ სტატიაში ვისაუბრებთ nginx-ის გამოყენების საინტერესო და არასტანდარტულ სცენარებზე, რაც საშუალებას მოგცემთ მაქსიმალურად ისარგებლოთ ვებ სერვერიდან.

ფოსტის პროქსი

დავიწყოთ ყველაზე აშკარა - nginx-ის უნარი იმოქმედოს როგორც ფოსტის პროქსი. ეს ფუნქცია თავდაპირველად არის nginx-ში, მაგრამ რატომღაც იგი გამოიყენება წარმოებაში ძალიან იშვიათად, ზოგიერთმა არც კი იცის მისი არსებობის შესახებ. როგორც არ უნდა იყოს, nginx მხარს უჭერს POP3, IMAP და SMTP პროტოკოლების პროქსირებას ავთენტიფიკაციის სხვადასხვა მეთოდებით, მათ შორის SSL და StartTLS, და აკეთებს ამას ძალიან სწრაფად.

რატომ არის ეს საჭირო? ამ ფუნქციის მინიმუმ ორი გამოყენება არსებობს. პირველი, გამოიყენეთ nginx, როგორც ფარი შემაშფოთებელი სპამერებისგან, რომლებიც ცდილობენ უსარგებლო ფოსტის გაგზავნას ჩვენი SMTP სერვერის საშუალებით. ჩვეულებრივ, სპამერები არ ქმნიან ბევრ პრობლემას, რადგან ისინი სწრაფად იშლება ავტორიზაციის ეტაპზე, თუმცა, როდესაც ისინი მართლაც ბევრია, nginx დაგეხმარებათ დაზოგოთ CPU რესურსები. მეორე, გამოიყენეთ nginx მომხმარებლების რამდენიმე POP3/IMAP საფოსტო სერვერზე გადამისამართებისთვის. რა თქმა უნდა, სხვა ფოსტის პროქსიმ შეიძლება გაუმკლავდეს ამას, მაგრამ რატომ უნდა შეგაწუხოთ სერვერები, თუ nginx უკვე დაინსტალირებულია წინა პლანზე, რათა ემსახურებოდეს სტატიკური HTTP-ის საშუალებით, მაგალითად?

ფოსტის პროქსი nginx-ში არ არის საკმაოდ სტანდარტული. ის იყენებს დამატებით ავთენტიფიკაციის ფენას, რომელიც განხორციელებულია HTTP-ის საშუალებით და მხოლოდ იმ შემთხვევაში, თუ მომხმარებელი გადალახავს ამ ბარიერს, მას გადაეცემა. ეს ფუნქცია უზრუნველყოფილია გვერდის/სკრიპტის შექმნით, რომელსაც nginx აძლევს მომხმარებლის მონაცემებს და ის უბრუნებს პასუხს სტანდარტული OK ან უარის მიზეზის სახით (როგორიცაა „არასწორი შესვლა ან პაროლი“). სკრიპტი მუშაობს შემდეგი სათაურებით:

ავტორიზაციის სკრიპტის შეყვანა HTTP_AUTH_USER: მომხმარებელი HTTP_AUTH_PASS: პაროლი HTTP_AUTH_PROTOCOL: ფოსტის პროტოკოლი (IMAP, POP3 ან SMTP)

და ბრუნდება ასე:

ავთენტიფიკაციის სკრიპტის გამომავალი HTTP_AUTH_STATUS: კარგი ან წარუმატებლობის მიზეზი HTTP_AUTH_SERVER: რეალური ფოსტის სერვერი HTTP_AUTH_PORT გადამისამართებისთვის: სერვერის პორტი

ამ მიდგომის ღირსშესანიშნავი მახასიათებელია ის, რომ ის შეიძლება გამოყენებულ იქნას არა თვით ავთენტიფიკაციისთვის, არამედ მომხმარებლების გასაფანტად სხვადასხვა შიდა სერვერებზე, მომხმარებლის სახელიდან გამომდინარე, ფოსტის სერვერებზე მიმდინარე დატვირთვის მონაცემები, ან თუნდაც უმარტივესი დატვირთვის დაბალანსების ორგანიზებით. მრგვალი რობინი. თუმცა, თუ თქვენ უბრალოდ გჭირდებათ მომხმარებლების შიდა ფოსტის სერვერზე გადაყვანა, რეალური სკრიპტის ნაცვლად შეგიძლიათ გამოიყენოთ სკრიპტის ნაცვლად თავად nginx-ის მიერ დანერგილი სტუბი. მაგალითად, უმარტივესი SMTP და IMAP პროქსი nginx კონფიგურაციაში ასე გამოიყურება:

# vi /etc/nginx/nginx.conf ფოსტა ( # ავტორიზაციის სკრიპტის მისამართი auth_http localhost:8080/auth; # გამორთეთ XCLIENT ბრძანება, ზოგიერთ საფოსტო სერვერს არ ესმის xclient off; # IMAP სერვერის სერვერი ( მოსმენა 143; პროტოკოლი imap; პროქსი ჩართულია; ) # SMTP სერვერის სერვერი (მოსმენა 25; პროტოკოლი smtp; პროქსი ჩართულია; ))

# vi /etc/nginx/nginx.conf http ( # რუკა ფოსტის სერვერის სწორ პორტზე, დამოკიდებულია HTTP_AUTH_PROTOCOL სათაურის რუკაზე გაგზავნილ პორტზე $http_auth_protocol $mailport ( ნაგულისხმევი 25; smtp 25; imap 143; ) # იმპლემენტაცია ავტორიზაციის "სკრიპტი" - ყოველთვის აბრუნებს OK და გადამისამართებს მომხმარებელს შიდა ფოსტის სერვერზე, დააყენებს სწორ პორტს ზემოთ მოყვანილი რუკების სერვერის გამოყენებით (მოსმენა 8080; მდებარეობა / ავტორიზაცია ( add_header "Auth-Status" "OK"; add_header "Auth- სერვერი" "192.168.0.1" ; add_header "Auth-Port" $mailport; დაბრუნება 200; ) ) )

Სულ ეს იყო. ეს კონფიგურაცია საშუალებას გაძლევთ გამჭვირვალედ გადამისამართოთ მომხმარებლები შიდა ფოსტის სერვერზე ზედნადების შექმნის გარეშე სკრიპტის სახით, რომელიც ამ შემთხვევაში არასაჭიროა. სკრიპტის გამოყენებით, ეს კონფიგურაცია შეიძლება მნიშვნელოვნად გაფართოვდეს: დააყენეთ დატვირთვის დაბალანსება, შეამოწმეთ მომხმარებლები LDAP მონაცემთა ბაზაში და შეასრულეთ სხვა ოპერაციები. სკრიპტის დაწერა სცილდება ამ სტატიის ფარგლებს, მაგრამ მისი განხორციელება ძალიან მარტივია თუნდაც PHP-ისა და Python-ის ელემენტარული ცოდნით.

ვიდეო ნაკადი

რეგულარული nginx-ზე დაფუძნებული ვიდეო ჰოსტინგის დაყენება მარტივია. საკმარისია ატვირთოთ ტრანსკოდირებული ვიდეო სერვერისთვის ხელმისაწვდომ დირექტორიაში, დაამატოთ ის კონფიგურაციაში და დააკონფიგურიროთ ფლეშ ან HTML5 პლეერი ისე, რომ მან მიიღოს ვიდეო ამ დირექტორიადან. თუმცა, თუ გსურთ უწყვეტი ვიდეო მაუწყებლობის დაყენება რომელიმე გარე წყაროდან ან ვებკამერიდან, ეს სქემა არ იმუშავებს და თქვენ მოგიწევთ სტრიმინგის სპეციალური პროტოკოლებისკენ მიხედვა.

არსებობს რამდენიმე პროტოკოლი, რომელიც წყვეტს ამ პრობლემას, მათგან ყველაზე ეფექტური და მხარდაჭერილი არის RTMP. ერთადერთი პრობლემა ის არის, რომ თითქმის ყველა RTMP სერვერის იმპლემენტაცია განიცდის პრობლემებს. ოფიციალური Adobe Flash Media Server ფასიანია. Red5 და Wowza იწერება Java-ში და ამიტომ არ იძლევა სასურველ შესრულებას, კიდევ ერთი იმპლემენტაცია, Erlyvideo, იწერება Erlang-ში, რაც კარგია კლასტერის დაყენების შემთხვევაში, მაგრამ არც ისე ეფექტური ერთი სერვერისთვის.

მე გთავაზობთ სხვა მიდგომას - გამოიყენეთ RTMP მოდული nginx-ისთვის. მას აქვს შესანიშნავი შესრულება და ასევე საშუალებას გაძლევთ გამოიყენოთ ერთი სერვერი, როგორც საიტის ვებ ინტერფეისის, ასევე ვიდეო ნაკადის მოსამსახურებლად. ერთადერთი პრობლემა ის არის, რომ ეს მოდული არაოფიციალურია, ამიტომ მისი მხარდაჭერით თავად მოგიწევთ nginx-ის აშენება. საბედნიეროდ, შეკრება ხორციელდება სტანდარტული გზით:

$ sudo apt-get წაშალე 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

ახლა საჭიროა მოდულის კონფიგურაცია. ეს კეთდება, როგორც ყოველთვის, nginx კონფიგურაციის საშუალებით:

Rtmp ( # გაააქტიურეთ სამაუწყებლო სერვერი პორტზე 1935 საიტზე/rtmp სერვერზე (მოსმენა 1935; განაცხადის rtmp ( პირდაპირ ეთერში; ) ))

RTMP მოდული ვერ იმუშავებს მრავალ ხრახნიან კონფიგურაციაში, ამიტომ nginx worker პროცესების რაოდენობა უნდა შემცირდეს ერთამდე (მოგვიანებით გეტყვით, როგორ გადალახოთ ეს პრობლემა):

მუშა_პროცესები 1;

ახლა ჩვენ შეგვიძლია შევინახოთ ფაილი და nginx-ს ხელახლა წაიკითხოს კონფიგურაცია. nginx-ის დაყენება დასრულებულია, მაგრამ ჩვენ ჯერ არ გვაქვს თავად ვიდეო ნაკადი, ამიტომ ის სადმე უნდა მივიღოთ. მაგალითად, ეს იყოს ვიდეო.avi ფაილი მიმდინარე დირექტორიადან. ნაკადად გადასაქცევად და ჩვენს RTMP მაუწყებელში გადასატანად, გამოვიყენოთ კარგი ძველი FFmpeg:

# ffmpeg -re -i ~/video.avi -c ასლი -f flv rtmp://localhost/rtmp/stream

თუ ვიდეო ფაილი არ არის H264 ფორმატში, უნდა მოხდეს მისი ხელახალი კოდირება. ეს შეიძლება გაკეთდეს ფრენისას იგივე FFmpeg-ის გამოყენებით:

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

ნაკადის გადაღებაც შესაძლებელია პირდაპირ ვებკამერიდან:

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

კლიენტის მხარეს ნაკადის სანახავად შეგიძლიათ გამოიყენოთ ნებისმიერი RTMP ჩართული პლეერი, როგორიცაა mplayer:

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

ან ჩადეთ მოთამაშე პირდაპირ ვებ გვერდზე, რომელსაც ემსახურება იგივე nginx (მაგალითი ოფიციალური დოკუმენტაციიდან):

უმარტივესი RTMP ვებ პლეერი

აქ არის მხოლოდ ორი მნიშვნელოვანი სტრიქონი: "ფაილი: "ნაკადი", რომელიც მიუთითებს RTMP ნაკადზე და "სტრიმერი: "rtmp://localhost/rtmp"", რომელიც განსაზღვრავს RTMP ნაკადის მისამართს. ამოცანების უმეტესობისთვის, ეს პარამეტრები საკმარისი იქნება. რამდენიმე სხვადასხვა ნაკადის გაშვება შესაძლებელია ერთ მისამართზე და nginx ეფექტურად გაამრავლებს მათ კლიენტებს შორის. მაგრამ ეს არ არის ყველაფერი, რაც RTMP მოდულს შეუძლია. მისი დახმარებით, მაგალითად, შეგიძლიათ მოაწყოთ ვიდეო ნაკადის ხელახალი გადაცემა სხვა სერვერიდან. ამისთვის FFmpeg სერვერი საერთოდ არ არის საჭირო, უბრალოდ დაამატეთ შემდეგი ხაზები კონფიგურაციაში:

# vi /etc/nginx/nginx.conf განაცხადის rtmp ( პირდაპირ ეთერში; pull rtmp://rtmp.example.com; )

თუ თქვენ გჭირდებათ მრავალი ნაკადის შექმნა სხვადასხვა ხარისხით, შეგიძლიათ დარეკოთ FFmpeg ტრანსკოდერი პირდაპირ nginx-იდან:

# vi /etc/nginx/nginx.conf აპლიკაცია rtmp ( პირდაპირ ეთერში; exec ffmpeg -i rtmp://localhost/rtmp/$name -c:v flv -c:a -s 320x240 -f flv rtmp://localhost /rtmp-320x240/$name; ) აპლიკაცია rtmp-320x240 ( პირდაპირ ეთერში; )

ამ კონფიგურაციით ჩვენ მივიღებთ ერთდროულად ორ მაუწყებელს, რომელთაგან ერთი ხელმისაწვდომი იქნება rtmp://site/rtmp, ხოლო მეორე, მაუწყებლობა 320 x 240 ხარისხით, rtmp://site/rtmp–320x240. შემდგომ საიტზე შეგიძლიათ ჩამოკიდოთ ფლეშ ფლეერი და ხარისხის შერჩევის ღილაკები, რომლებიც მოთამაშის მაუწყებლის ამა თუ იმ მისამართს გადასრიალებენ.

და ბოლოს, ქსელში მუსიკის გადაცემის მაგალითი:

ხოლო მართალია; do ffmpeg -re -i "`find /var/music -type f -name "*.mp3"|sort -R|head -n 1`" -vn -c:a libfaac -ar 44100 -ac 2 -f flv rtmp://localhost/rtmp/stream; შესრულებულია

git პროქსი

Git ვერსიის კონტროლის სისტემას შეუძლია უზრუნველყოს საცავებზე წვდომა არა მხოლოდ Git და SSH პროტოკოლების, არამედ HTTP-ის საშუალებით. ოდესღაც HTTP წვდომის განხორციელება პრიმიტიული იყო და ვერ უზრუნველყოფდა სრულფასოვან მუშაობას საცავთან. 1.6.6 ვერსიიდან მოყოლებული სიტუაცია შეიცვალა და დღეს ეს პროტოკოლი შეიძლება გამოყენებულ იქნას, მაგალითად, კავშირის ორივე მხარეს Firewall-ის შეზღუდვების გვერდის ავლით, ან შექმნათ თქვენი Git ჰოსტინგი ვებ ინტერფეისით.

სამწუხაროდ, ოფიციალურ დოკუმენტაციაში საუბარია მხოლოდ Git-ზე წვდომის ორგანიზებაზე Apache ვებ სერვერის გამოყენებით, მაგრამ რადგან განხორციელება თავისთავად არის გარე აპლიკაცია სტანდარტული CGI ინტერფეისით, ის შეიძლება დაერთოს თითქმის ნებისმიერ სხვა სერვერს, მათ შორის lighttpd და, რა თქმა უნდა, ნგინქსი. ამას არ სჭირდება სხვა არაფერი, გარდა თავად სერვერისა, დაინსტალირებული Git და პატარა FastCGI სერვერის fcgiwrap, რომელიც საჭიროა, რადგან nginx-მა არ იცის როგორ იმუშაოს პირდაპირ CGI-თან, მაგრამ მას შეუძლია სკრიპტების გამოძახება FastCGI პროტოკოლის გამოყენებით.

მუშაობის მთელი სქემა ასე გამოიყურება. fcgiwrap სერვერი დაკიდება ფონზე და დაელოდება მოთხოვნას CGI აპლიკაციის შესასრულებლად. Nginx, თავის მხრივ, კონფიგურირებული იქნება იმისათვის, რომ მოითხოვოს git-http-backend CGI ბინარის შესრულება FastCGI ინტერფეისის მეშვეობით ყოველ ჯერზე, როცა ჩვენ მიერ მითითებულ მისამართზე წვდომა ხდება. მოთხოვნის მიღებისთანავე, fcgiwrap ახორციელებს git-http-backend-ს მითითებული CGI არგუმენტებით, რომლებიც გადაცემულია GIT კლიენტის მიერ და აბრუნებს შედეგს.

ასეთი სქემის განსახორციელებლად, ჩვენ ჯერ ვაყენებთ fcgiwrap:

$ sudo apt-get დააინსტალირე fcgiwrap

თქვენ არ გჭირდებათ მისი კონფიგურაცია, ყველა პარამეტრი გადადის FastCGI პროტოკოლით. ის ასევე ავტომატურად დაიწყება. ამიტომ, რჩება მხოლოდ nginx-ის კონფიგურაცია. ამისათვის შექმენით ფაილი /etc/nginx/sites-enabled/git (თუ ასეთი დირექტორია არ არის, შეგიძლიათ ჩაწეროთ მთავარ კონფიგურაციაში) და ჩაწერეთ მასში შემდეგი:

# vi /etc/nginx/sites-enabled/git server ( # Hang on port 8080 მოსმენა 8080; # ჩვენი სერვერის მისამართი (არ დაგავიწყდეთ დაამატოთ DNS ჩანაწერი) სერვერის სახელი git.example.ru; # Logs access_log /var /log/nginx /git-http-backend.access.log; error_log /var/log/nginx/git-http-backend.error.log; # ძირითადი მისამართი ანონიმური წვდომის მდებარეობისთვის / ( # ატვირთვის მცდელობისას გაგზავნეთ მომხმარებელი პირად მისამართზე, თუ ($ arg_service ~* "git-receive-pack") (გადაწერა ^ /private$uri ბოლო; ) მოიცავს /etc/nginx/fastcgi_params; # ჩვენი git-http-backend fastcgi_param SCRIPT_FILENAME /usr /lib/git-core/git- http-backend; # Git საცავის მისამართი fastcgi_param GIT_PROJECT_ROOT /srv/git; # ფაილის მისამართი fastcgi_param PATH_INFO $uri; # სერვერის მისამართი fcgiwrap fastcgi_pass 127.0.0.1:90 წვდომა მისამართისთვის; ~/private(/.*)$ ( # მომხმარებლის ნებართვები auth_basic "git ანონიმური მხოლოდ წაკითხვისთვის, ავტორიზებული ჩაწერა"; # HTTP ავტორიზაცია htpasswd auth_basic_user_file /etc/nginx/htpasswd; # FastCGI პარამეტრები i მოიცავს /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; ))

ეს კონფიგურაცია ითვალისწინებს სამ მნიშვნელოვან საკითხს:

1. საცავის მისამართი იქნება /srv/git, ამიტომ დააყენეთ შესაბამისი ნებართვები: $ sudo chown -R www-data:www-data /srv/git
2. თავად საცავი უნდა იკითხებოდეს ანონიმურმა და დაუშვას ატვირთვა HTTP-ით: $ cd /srv/git $ git config core.sharedrepository true $ git config http.receivepack true
3. ავთენტიფიკაცია ხდება htpasswd ფაილის გამოყენებით, თქვენ უნდა შექმნათ იგი და დაამატოთ მომხმარებლები: $ sudo apt-get install apache2-utils $ htpasswd -c /etc/nginx/htpasswd user1 $ htpasswd /etc/nginx/htpasswd user2. .

სულ ეს არის, გადატვირთეთ nginx:

მიკროქეშირება

წარმოვიდგინოთ სიტუაცია დინამიური, ხშირად განახლებული საიტით, რომელიც მოულოდნელად იწყებს ძალიან დიდი დატვირთვების მიღებას (ისე, ის მოხვდა ერთ-ერთი უდიდესი საინფორმაციო საიტის გვერდზე) და წყვეტს კონტენტის დაბრუნებას. კომპეტენტურ ოპტიმიზაციას და სწორი ქეშირების სქემის განხორციელებას დიდი დრო დასჭირდება და პრობლემები ახლავე უნდა მოგვარდეს. რა შეგვიძლია გავაკეთოთ?

ამ სიტუაციიდან მინიმალური დანაკარგებით გამოსვლის რამდენიმე გზა არსებობს, მაგრამ ყველაზე საინტერესო იდეა ფენ ბეილიმ (fennb.com) მიიღო. იდეა მდგომარეობს იმაში, რომ უბრალოდ დააყენოთ nginx სერვერის წინ და აიძულოთ მას ქეში შეინახოს ყველა გადაცემული შინაარსი, მაგრამ არა მხოლოდ ქეში, არამედ მხოლოდ ერთი წამით. აქ მთავარია ის, რომ ასობით და ათასობით საიტის ვიზიტორი წამში, ფაქტობრივად, წარმოქმნის მხოლოდ ერთ ზარს ბექენდზე, მათი უმეტესობა იღებს ქეშებულ გვერდს. ამავდროულად, ძნელად ვინმე შეამჩნევს განსხვავებას, რადგან დინამიურ საიტზეც კი, ერთი წამი ჩვეულებრივ არაფერს ნიშნავს.

ამ იდეის განხორციელების კონფიგურაცია არც ისე რთული გამოიყურება:

# vi /etc/nginx/sites-enabled/cache-proxy # configure cache proxy_cache_path /var/cache/nginx level=1:2 keys_zone=microcache:5m max_size=1000m; სერვერი ( მოსმენა 80; server_name example.com; # ქეში მისამართის მდებარეობა / ( # ქეში ჩართულია ნაგულისხმევად დააყენეთ $no_cache ""; # გამორთეთ ქეში ყველა მეთოდისთვის, გარდა GET და HEAD, თუ ($request_method !~ ^(GET|HEAD) $ ) ( დააყენეთ $no_cache "1"; ) # თუ კლიენტი ატვირთავს შინაარსს საიტზე (no_cache = 1), ჩვენ ვზრუნავთ, რომ მისთვის მიცემული მონაცემები არ არის ქეშირებული ორი წამის განმავლობაში და ის ხედავს ჩამოტვირთვის შედეგს, თუ ($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 "; ) # ჩართეთ / გამორთეთ ქეში ცვლადის მდგომარეობის მიხედვით no_cache proxy_no_cache $no_cache; proxy_cache_bypass $no_cache; # პროქსი ითხოვს რეალურ სერვერს proxy_pass http://appserver.example.ru; proxy_cache; proxy_cache_key $scheme$host$request_method$ request_uri; proxy_cache_valid 200 1s; # დაცვა ჭექა-ქუხილის ნახირის პრობლემისგან proxy_cache_use_stale განახლება; # დაამატეთ სტანდარტული სათაურები proxy_set_h header ჰოსტი $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # არ შეინახოთ 1 მბ-ზე დიდი ზომის ფაილები ქეშით, proxy_max_temp_file_size 1M; ))

ამ კონფიგურაციაში განსაკუთრებული ადგილი უკავია ხაზს "proxy_cache_use_stale updating;", რომლის გარეშეც ჩვენ მივიღებდით პერიოდულ დატვირთვას ბექენდის სერვერზე ქეშის განახლების დროს მოსული მოთხოვნების გამო. წინააღმდეგ შემთხვევაში, ყველაფერი სტანდარტულია და გასაგები უნდა იყოს დამატებითი ახსნა-განმარტების გარეშე.

პროქსის დაახლოება სამიზნე აუდიტორიასთან

ინტერნეტის სიჩქარის ფართო გლობალური ზრდის მიუხედავად, სერვერის ფიზიკური დაშორება სამიზნე აუდიტორიისგან მაინც აგრძელებს როლს. ეს ნიშნავს, რომ თუ რუსული საიტი მუშაობს სერვერზე, რომელიც მდებარეობს სადმე ამერიკაში, მასზე წვდომის სიჩქარე აპრიორი იქნება უფრო ნელი, ვიდრე იგივე გამტარუნარიანობის მქონე რუსული სერვერისგან (რა თქმა უნდა, თუ დახუჭავთ თვალებს ყველა სხვა ფაქტორზე. ). კიდევ ერთი რამ არის ის, რომ ხშირად უფრო მომგებიანია სერვერების ჰოსტინგი საზღვარგარეთ, მათ შორის მოვლის თვალსაზრისით. ამიტომ, მოგების მისაღებად, უფრო მაღალი დაბრუნების განაკვეთების სახით, მოგიწევთ ხრიკზე წასვლა.

ერთ-ერთი შესაძლო ვარიანტია: განვათავსოთ მთავარი პროდუქტიული სერვერი დასავლეთში და განათავსოთ ფრონტ-ენდი, რომელიც არც თუ ისე მომთხოვნი რესურსია, რაც სტატიკას იძლევა, რუსეთში. ეს საშუალებას მოგცემთ მოიგოთ სიჩქარე სერიოზული ხარჯების გარეშე. nginx კონფიგურაცია ფრონტენდისთვის ამ შემთხვევაში იქნება მარტივი პროქსი იმპლემენტაცია, რომელიც ყველა ჩვენგანისთვისაა ნაცნობი:

# vi /etc/nginx/sites-enabled/proxy # შეინახეთ ქეში 30 დღის განმავლობაში 100 გბაიტიან მეხსიერებაში proxy_cache_path /var/cache/nginx level=1:2 keys_zone=static:32m inactive=30d max_size=100g; სერვერი (მოსმენა 80; server_name example.com; # სინამდვილეში, ჩვენი პროქსის მდებარეობა ~* .(jpg|jpeg|gif|png|ico|css|midi|wav|bmp|js|swf|flv|avi|djvu|mp3) $ ( # Backend მისამართი proxy_pass back.example.com:80; პროქსი_გადამისამართება გამორთულია; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_proxy_add_x_forwardedx1; proxy_cache_valid 30d; proxy_ignore_headers "Cache-Control" "Expires"; proxy_cache_key "$uri$is_args$args"; proxy_cache_lock ჩართულია; ) )

დასკვნები

დღეს nginx-ის დახმარებით შეგიძლიათ გადაჭრათ მრავალი განსხვავებული ამოცანა, რომელთაგან ბევრი საერთოდ არ არის დაკავშირებული ვებ სერვერთან და HTTP პროტოკოლთან. ფოსტის პროქსი, ნაკადის სერვერი და Git ინტერფეისი მხოლოდ რამდენიმე ამოცანაა.

ეს სტატია აგიხსნით, თუ როგორ უნდა დააკონფიგურიროთ NGINX Plus ან NGINX ღია წყარო, როგორც პროქსი ფოსტის სერვერისთვის ან გარე ფოსტის სერვისისთვის.

შესავალი

NGINX-ს შეუძლია IMAP, POP3 და SMTP პროტოკოლების მარიონეტული გადაცემა ერთ-ერთ ზედა დინებაში ფოსტის სერვერზე, რომელიც მასპინძლობს ფოსტის ანგარიშებს და, შესაბამისად, შეიძლება გამოყენებულ იქნას როგორც ერთი საბოლოო წერტილი ელფოსტის კლიენტებისთვის. ამან შეიძლება მოიტანოს მრავალი სარგებელი, როგორიცაა:

• ფოსტის სერვერების რაოდენობის მარტივი სკალირება
• ფოსტის სერვერის არჩევა სხვადასხვა წესების საფუძველზე, მაგალითად, უახლოესი სერვერის არჩევა კლიენტის IP მისამართის საფუძველზე
• დატვირთვის განაწილება ფოსტის სერვერებს შორის

წინაპირობები

NGINX Plus (უკვე მოიცავს ფოსტის მოდულებს, რომლებიც აუცილებელია პროქსი ელ.ფოსტის ტრაფიკისთვის) ან NGINX ღია წყარომ შეადგინა ფოსტის მოდულები --with-mail პარამეტრის გამოყენებით ელფოსტის პროქსი ფუნქციონირებისთვის და --with-mail_ssl_module პარამეტრით SSL/TLS მხარდაჭერისთვის:

$ ./კონფიგურაცია --with-mail --with-mail_ssl_module --with-openssl=[ DIR] /openssl-1.1.1

IMAP, POP3 და/ან SMTP საფოსტო სერვერები ან გარე ფოსტის სერვისი

SMTP/IMAP/POP3 ფოსტის პროქსი სერვერების კონფიგურაცია

NGINX კონფიგურაციის ფაილში:

ფოსტა (#...)

ფოსტა (server_name mail.example.com; #...)

ფოსტა (server_name mail.example.com; auth_http localhost: 9000 /cgi-bin/nginxauth.cgi; #...)

ალტერნატიულად, მიუთითეთ, უნდა აცნობოს თუ არა მომხმარებელს ავტორიზაციის სერვერის შეცდომების შესახებ proxy_pass_error_message დირექტივის მითითებით. ეს შეიძლება იყოს მოსახერხებელი, როდესაც საფოსტო ყუთს მეხსიერება ამოიწურება:

ფოსტა (server_name mail.example.com; auth_http localhost: 9000 /cgi-bin/nginxauth.cgi; proxy_pass_error_message ჩართულია; #...)

თითოეული SMTP, IMAP ან POP3 სერვერის კონფიგურაცია სერვერის ბლოკებით. თითოეული სერვერისთვის მიუთითეთ:

• The პორტის ნომერირომლებიც შეესაბამება მითითებულ პროტოკოლს მოსმენის დირექტივით
• The ოქმიპროტოკოლის დირექტივით (თუ არ არის მითითებული, ავტომატურად გამოვლინდება მოსმენის დირექტივაში მითითებული პორტიდან)
• ნებადართული ავთენტიფიკაციის მეთოდები imap_auth , pop3_auth და smtp_auth დირექტივებით:

სერვერი (მოსმენა 25; პროტოკოლი smtp; smtp_auth შესვლა ჩვეულებრივი cram-md5;) სერვერი (მოსმენა 110; პროტოკოლი pop3; pop3_auth plain apop cram-md5;) სერვერი (მოსმენა 143; პროტოკოლის imap;)

ფოსტის პროქსისთვის ავთენტიფიკაციის დაყენება

კლიენტისგან თითოეული POP3/IMAP/SMTP მოთხოვნა პირველად დამოწმებული იქნება გარე HTTP ავთენტიფიკაციის სერვერზე ან ავტორიზაციის სკრიპტით. ავტორიზაციის სერვერის ქონა სავალდებულოა NGINX ფოსტის სერვერის პროქსისთვის. სერვერის შექმნა შესაძლებელია თქვენ მიერ NGINX ავთენტიფიკაციის პროტოკოლის შესაბამისად, რომელიც დაფუძნებულია HTTP პროტოკოლზე.

თუ ავტორიზაცია წარმატებულია, ავთენტიფიკაციის სერვერი აირჩევს ზედა ნაკადის სერვერს და გადამისამართებს მოთხოვნას. ამ შემთხვევაში, სერვერის პასუხი შეიცავს შემდეგ ხაზებს:

HTTP/1.0 200 OK Auth-Status: OK Auth-Server: # სერვერის სახელი ან IP მისამართი ზედა დინებაში სერვერის, რომელიც გამოყენებული იქნება ფოსტის დასამუშავებლადავტორიზაციის პორტი: # ზედა დინების სერვერის პორტი

თუ ავტორიზაცია ვერ მოხერხდა, ავთენტიფიკაციის სერვერი დააბრუნებს შეცდომის შეტყობინებას. ამ შემთხვევაში, სერვერის პასუხი შეიცავს შემდეგ ხაზებს:

HTTP/1.0 200 OK Auth-Status: # შეცდომის შეტყობინება, რომელიც უნდა დაუბრუნდეს კლიენტს, მაგალითად, „არასწორი შესვლა ან პაროლი“ავტორიზაცია-მოელოდე: # ავთენტიფიკაციის დარჩენილი მცდელობების რაოდენობა კავშირის დახურვამდე

გაითვალისწინეთ, რომ ორივე შემთხვევაში პასუხი შეიცავს HTTP/1.0 200 OKრომელიც შეიძლება დამაბნეველი იყოს.

ავთენტიფიკაციის სერვერზე მოთხოვნისა და პასუხების მეტი მაგალითებისთვის იხილეთ ngx_mail_auth_http_module NGINX Reference დოკუმენტაციაში.

SSL/TLS დაყენება ფოსტის პროქსისთვის

POP3/SMTP/IMAP-ის გამოყენებით SSL/TLS-ზე თქვენ დარწმუნდებით, რომ კლიენტსა და ფოსტის სერვერს შორის გადაცემული მონაცემები დაცულია.

SSL/TLS ფოსტის პროქსისთვის ჩასართავად:

დარწმუნდით, რომ თქვენი NGINX კონფიგურირებულია SSL/TLS მხარდაჭერით, ბრძანების სტრიქონში აკრიფეთ nginx -V ბრძანება და შემდეგ გამოსავალში მოძებნეთ --mail_ssl_module ხაზი:

$ nginx -V არგუმენტების კონფიგურაცია: ... with--mail_ssl_module

დარწმუნდით, რომ მიიღეთ სერვერის სერთიფიკატები და პირადი გასაღები და განათავსეთ ისინი სერვერზე. სერთიფიკატის მიღება შესაძლებელია სანდო სერტიფიკატის ორგანოდან (CA) ან გენერირებული SSL ბიბლიოთეკის გამოყენებით, როგორიცაა OpenSSL.

ssl on ;

უცებ ;

დაამატეთ SSL სერთიფიკატები: მიუთითეთ სერთიფიკატებისკენ მიმავალი გზა (რომელიც უნდა იყოს PEM ფორმატში) ssl_certificate დირექტივით და მიუთითეთ გზა პირადი გასაღებისკენ ssl_certificate_key დირექტივაში:

ფოსტა (#... ssl_certificate /etc/ssl/certs/server.crt; ssl_certificate_key /etc/ssl/certs/server.key;)

თქვენ შეგიძლიათ გამოიყენოთ SSL/TLS მხოლოდ ძლიერი ვერსიები და შიფრები ssl_protocols და ssl_ciphers დირექტივებით, ან შეგიძლიათ დააყენოთ თქვენი სასურველი პროტოკოლები და შიფრები:

ფოსტა (#... ssl_protocols TLSv1 TLSv1.1 TLSv1.2 ; ssl_ciphers HIGH:!aNULL:!MD5 ; )

SSL/TLS ოპტიმიზაცია ფოსტის პროქსისთვის

ეს მინიშნებები დაგეხმარებათ გახადოთ თქვენი NGINX ფოსტის პროქსი უფრო სწრაფი და უსაფრთხო:

დააყენეთ მუშა პროცესების რაოდენობა ტოლი პროცესორების რაოდენობასთან ერთად worker_processes დირექტივა დაყენებულია იმავე დონეზე, როგორც ფოსტის კონტექსტი:

მუშა_პროცესები ავტო ; ფოსტა (#...)

ჩართეთ გაზიარებული სესიის ქეში და გამორთეთ ჩაშენებული სესიის ქეში ავტო ; ფოსტა (server_name mail.example.com; auth_http localhost: 9000 /cgi-bin/nginxauth.cgi; proxy_pass_error_message ჩართულია; ssl ჩართულია; ssl_certificate /etc/ssl/certs/server.crtsl. გასაღები ; ssl_protocols TLSv1 TLSv1.1 TLSv1.2 ; ssl_ciphers HIGH:!aNULL:!MD5 ; ssl_session_cache გაზიარებული:SSL:10m ; ssl_session_timeout 10m ; სერვერი (მოსმენა 25 logsmmtm ; სერვერი (col 25msmmtm ; ; პროტოკოლი pop3 ; pop3_auth plain apop cram-md5 ;) სერვერი (მოსმენა 143; პროტოკოლის imap;))

ამ მაგალითში არის სამი ელ.ფოსტის პროქსი სერვერი: SMTP, POP3 და IMAP. თითოეული სერვერი კონფიგურირებულია SSL და STARTTLS მხარდაჭერით. SSL სესიის პარამეტრები შეინახება.

პროქსი სერვერი იყენებს HTTP ავთენტიფიკაციის სერვერს – მისი კონფიგურაცია სცილდება ამ სტატიის ფარგლებს. ყველა შეცდომის შეტყობინება სერვერიდან დაუბრუნდება კლიენტებს.

ნგინქსი- მცირე ზომის, ძალიან სწრაფი, საკმაოდ ფუნქციონალური ვებ სერვერი და ფოსტის პროქსი სერვერი, დეველოპერი იგორ სისოევი (rambler.ru). სისტემის რესურსების და სიჩქარის ძალიან დაბალი მოხმარების, ასევე კონფიგურაციის მოქნილობის გამო, ვებ nginx სერვერიხშირად გამოიყენება როგორც წინა ნაწილი უფრო მძიმე სერვერებისთვის, როგორიცაა აპაჩი, მაღალი დატვირთვის პროექტებში. კლასიკური ვარიანტი არის რამოდენიმე, ნგინქსი - აპაჩი - FastCGI. ასეთ სქემით მუშაობა, nginx სერვერი, იღებს ყველა მოთხოვნას, რომელიც შემოდის HTTP-ით და, კონფიგურაციისა და თავად მოთხოვნის მიხედვით, წყვეტს, თავად დაამუშაოს მოთხოვნა და კლიენტს მზა პასუხი გასცეს, ან დამუშავების მოთხოვნა გაგზავნოს ერთ-ერთ ბექენდზე ( აპაჩიან FastCGI).

მოგეხსენებათ, Apache სერვერი ამუშავებს თითოეულ მოთხოვნას ცალკე პროცესში (thread), რომელიც, უნდა ითქვას, მოიხმარს არც თუ ისე მცირე რაოდენობის სისტემურ რესურსებს, თუ 10-20 ასეთი პროცესია, ეს სისულელეა და თუ არსებობს. არის 100-500 ან მეტი მათგანი, სისტემა ხდება არა სახალისო.

შევეცადოთ წარმოვიდგინოთ ასეთი სიტუაცია. დავუშვათ აპაჩი 300 HTTP მოთხოვნა მოდის კლიენტებისგან, 150 კლიენტი ზის სწრაფ იჯარით ხაზებზე, ხოლო დანარჩენი 150 შედარებით ნელ ინტერნეტ არხებზე, თუნდაც არა მოდემებზე. რა ხდება ამ სიტუაციაში? და ხდება შემდეგი, Apache ვებ სერვერი, ამ 300 კავშირის დასამუშავებლად, ქმნის თითოეული პროცესისთვის (thread), ის სწრაფად გამოიმუშავებს შინაარსს და 150 სწრაფი კლიენტი დაუყოვნებლივ მიიღებს მათი მოთხოვნების შედეგს, იმ პროცესებს, რომლებიც მათ ემსახურებოდა. დაიღუპება და რესურსები გამოთავისუფლდება, 150 კი ნელია და მათი შეკითხვის შედეგებს ნელა წაიღებს, ვიწრო ინტერნეტ არხის გამო, რის შედეგადაც სისტემაში 150 პროცესი ჩამოიხრჩო. აპაჩი, ელოდება კლიენტებს ვებ სერვერის მიერ გენერირებული კონტენტის მიღებას, რაც შთანთქავს სისტემის უამრავ რესურსს. ბუნებრივია, სიტუაცია ჰიპოთეტურია, მაგრამ ვფიქრობ, არსი გასაგებია. ზემოაღნიშნული სიტუაციის გამოსწორება და პაკეტი ეხმარება. კლიენტისგან მთლიანი მოთხოვნის წაკითხვის შემდეგ, იგი გადასცემს მას დამუშავებას აპაჩი, რომელიც თავის მხრივ ქმნის კონტენტს და რაც შეიძლება სწრაფად აბრუნებს მზა პასუხს Nginx-ს, რის შემდეგაც მას შეუძლია მოკლას პროცესი სუფთა სინდისით და გაათავისუფლოს სისტემის რესურსები, რომელიც მას უჭირავს. Nginx ვებ სერვერი, რომელიც იღებს მოთხოვნის შედეგს აპაჩი, წერს მას ბუფერში ან თუნდაც დისკზე არსებულ ფაილზე და შეუძლია მისცეს ნელი კლიენტებს თვითნებურად დიდი ხნის განმავლობაში, ხოლო მისი სამუშაო პროცესები მოიხმარს იმდენ რესურსს, რომ .. "სასაცილოა ამაზე საუბარი" ©. :) ასეთი სქემა მნიშვნელოვნად ზოგავს სისტემის რესურსებს, ვიმეორებ, მაგრამ Nginx მუშა პროცესები მოიხმარს მწირ რესურსებს, ეს მით უფრო აქტუალურია დიდი პროექტებისთვის.

და ეს მხოლოდ მცირე ნაწილია იმისა, რისი გაკეთებაც შეუძლია Nginx სერვერს, ნუ დაივიწყებთ მონაცემთა ქეშირებისა და მასთან მუშაობის შესაძლებლობის შესახებ. მემქეშირებული. აქ არის Nginx ვებ სერვერის ძირითადი მახასიათებლების სია.

Nginx სერვერის ფუნქციონირება, როგორც HTTP სერვერი

• სტატიკური შინაარსის დამუშავება, ინდექსის ფაილები, დირექტორია სია, ღია ფაილის აღწერის ქეში;
• დაჩქარებული პროქსირება ქეშირებით, დატვირთვის დაბალანსებით და ფაილოვერით;
• დაჩქარებული მხარდაჭერა FastCGIსერვერები ქეშირებით, დატვირთვის დაბალანსებით და შეცდომების ტოლერანტობით;
• მოდულური სტრუქტურა, სხვადასხვა ფილტრების მხარდაჭერა (SSI, XSLT, GZIP, რეზიუმე, დაქუცმაცებული პასუხები);
• SSL და TLS SNI გაფართოებების მხარდაჭერა;
• ip-ზე დაფუძნებულიან სახელზე დაფუძნებულივირტუალური სერვერები;
• მუშაობა KeepAlive და მილსადენის კავშირებთან;
• ნებისმიერი დროის ამოწურვის, ასევე ბუფერების რაოდენობის და ზომის კონფიგურაციის შესაძლებლობა დონეზე Apache სერვერი;
• კლიენტის მისამართიდან გამომდინარე სხვადასხვა მოქმედებების შესრულება;
• URI-ის შეცვლა რეგულარული გამონათქვამების გამოყენებით;
• სპეციალური შეცდომის გვერდები 4xx და 5xx;
• წვდომის შეზღუდვა კლიენტის მისამართის ან პაროლის საფუძველზე;
• ჟურნალის ფაილის ფორმატების დაყენება, ჟურნალის როტაცია;
• კლიენტზე რეაგირების სიჩქარის შეზღუდვა;
• ერთდროული კავშირებისა და მოთხოვნების რაოდენობის შეზღუდვა;
• PUT, DELETE, MKCOL, COPY და MOVE მეთოდების მხარდაჭერა;
• პარამეტრების შეცვლა და სერვერის განახლება მუშაობის შეწყვეტის გარეშე;
• ჩაშენებული პერლ;

Nginx სერვერის ფუნქციონირება, როგორც ფოსტის პროქსი სერვერი

• გადამისამართება IMAP/POP3 backend-ში გარე HTTP ავთენტიფიკაციის სერვერის გამოყენებით;
• მომხმარებლის SMTP-ის შემოწმება გარე HTTP ავთენტიფიკაციის სერვერზე და გადამისამართება შიდა SMTP სერვერზე;
• ავტორიზაციის შემდეგი მეთოდების მხარდაჭერა:
  • POP3 - USER/PASS, APOP, AUTH LOGIN/PLAIN/CRAM-MD5;
  • IMAP - LOGIN, AUTH LOGIN/PLAIN/CRAM-MD5;
  • SMTP - AUTH LOGI / PLAIN / CRAM-MD5;
• SSL მხარდაჭერა;
• STARTTLS და STLS მხარდაჭერა;

ოპერაციული სისტემები და პლატფორმები, რომლებიც მხარდაჭერილია Nginx ვებ სერვერის მიერ

• FreeBSD, პლატფორმები 3-დან 8-მდე, i386 და amd64;
• Linux, 2.2-დან 2.6-მდე - i386 პლატფორმა; Linux 2.6 - amd64;
• Solaris 9 - i386 და sun4u პლატფორმები; Solaris 10 - i386, amd64 და sun4v პლატფორმები;
• MacOS X პლატფორმები ppc, i386;
• Windows XP, Windows Server 2003; (ამჟამად ბეტა ტესტირებაშია)

Nginx სერვერის არქიტექტურა და მასშტაბურობა

• ძირითადი (მასტერ) პროცესი, რამდენიმე (კონფიგურირებული კონფიგურაციის ფაილში) მუშა პროცესი, რომელიც მიმდინარეობს არაპრივილეგირებული მომხმარებლის ქვეშ;
• კავშირის მართვის შემდეგი მეთოდების მხარდაჭერა:
  • აირჩიეთარის სტანდარტული მეთოდი. Nginx-ის შესაბამისი მოდული აგებულია ავტომატურად, თუ მოცემულ პლატფორმაზე უფრო ეფექტური მეთოდი არ მოიძებნება. თქვენ შეგიძლიათ აიძულოთ ამ მოდულის აშენების იძულებითი ჩართვა ან გამორთვა --with-select_module ან --without-select_module კონფიგურაციის ვარიანტების გამოყენებით.
  • გამოკითხვაარის სტანდარტული მეთოდი. Nginx-ის შესაბამისი მოდული აგებულია ავტომატურად, თუ მოცემულ პლატფორმაზე უფრო ეფექტური მეთოდი არ მოიძებნება. თქვენ შეგიძლიათ აიძულოთ ამ მოდულის აშენების იძულებითი ჩართვა ან გამორთვა --with-poll_module ან --without-poll_module კონფიგურაციის ვარიანტების გამოყენებით.
  • რიგშიარის ეფექტური მეთოდი, რომელიც გამოიყენება FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0 და MacOS X ოპერაციულ სისტემებზე. ორმაგი პროცესორიან MacOS X მანქანებზე გამოყენებისას შეიძლება გამოიწვიოს ბირთვის პანიკა.
  • ეპოლიარის ეფექტური მეთოდი, რომელიც გამოიყენება Linux 2.6+-ში. ზოგიერთ დისტრიბუციას, როგორიცაა SuSE 8.2, აქვს პატჩები 2.4 ბირთვში epoll-ის მხარდასაჭერად.
  • rtsig - რეალურ დროში სიგნალები, ეფექტური მეთოდი, რომელიც გამოიყენება Linux 2.2.19+-ში. ნაგულისხმევად, მთელი სისტემის რიგში არ შეიძლება იყოს 1024 სიგნალზე მეტი. ეს არ არის საკმარისი მაღალი დატვირთვის მქონე სერვერებისთვის, რიგის ზომა უნდა გაიზარდოს /proc/sys/kernel/rtsig-max kernel პარამეტრის გამოყენებით. თუმცა, Linux 2.6.6-მმ2-დან ეს პარამეტრი ამოღებულია, სამაგიეროდ, თითოეულ პროცესს აქვს ცალკე სიგნალის რიგი, რომლის ზომა განისაზღვრება RLIMIT_SIGPENDING-ით.
  • როცა რიგი სავსეა, nginx სერვერიაღადგენს მას და ამუშავებს კავშირებს გამოკითხვის მეთოდით, სანამ სიტუაცია ნორმალურად არ დაბრუნდება.
  • /dev/გამოკითხვა- ეფექტური მეთოდი, მხარდაჭერილი Solaris 7 11/99+, HP/UX 11.22+ (eventport), IRIX 6.5.15+ და Tru64 UNIX 5.1A+ ოპერაციულ სისტემებზე.
  • eventport - ღონისძიების პორტები, ეფექტური მეთოდი, რომელიც გამოიყენება Solaris 10-ში. გამოყენებამდე უნდა დამონტაჟდეს პაჩი ბირთვის პანიკის თავიდან ასაცილებლად.
• kqueue მეთოდის ფუნქციების გამოყენება, როგორიცაა EV_CLEAR, EV_DISABLE (მოვლენის დროებით გამორთვა), NOTE_LOWAT, EV_EOF, ხელმისაწვდომი მონაცემების რაოდენობა, შეცდომის კოდები;
• მუშაობა sendfile-თან (FreeBSD 3.1+, Linux 2.2.+, Mac OS X 10.5+), sendfile64 (Linux 2.4.21+) და sendfilev (Solaris 8 7/01+);
• მიღების ფილტრების მხარდაჭერა (FreeBSD 4.1+) და TCP_DEFER_ACCEPT (Linux 2.4+);
• 10,000 უმოქმედო HTTP-ის შენარჩუნება-ცოცხალი კავშირი მოიხმარს დაახლოებით 2,5 მ მეხსიერებას;
• მონაცემთა კოპირების ოპერაციების მინიმალური რაოდენობა;

iRedMail არის ღია კოდის ფოსტის სერვერის აშენება. ასამბლეა დაფუძნებულია Postfix SMTP სერვერზე (Mail Transfer Agent, მოკლედ MTA). ასამბლეაში ასევე შედის: Dovecot, SpamAssassin, Greylist, ClamAV, SOGo Roundcube, NetData და NGINX.

Dovecot- IMAP/POP3 სერვერი.

Spamassassin- სპამის ფილტრაციის ინსტრუმენტი.

გრეილისტი- სპამის საწინააღმდეგო ინსტრუმენტი ნაცრისფერი სიების საფუძველზე.

ClamAV- ანტივირუსი.

მრგვალი კუბიდა SOGo- ვებ კლიენტები ელექტრონული ფოსტით მუშაობისთვის.

წმინდა მონაცემები- პროგრამა რეალურ დროში სერვერის მუშაობის მონიტორინგისთვის.

ნგინქსი- ვებ სერვერი.

მხარს უჭერს ოპერაციულ სისტემებს: CentOS 7, Debian 9, Ubuntu 16.04/18.04, FreeBSD 11/12და OpenBSD 6.4.

iRedMail-ს აქვს ფასიანი და უფასო ვერსიები, რომლებიც ერთმანეთისგან განსხვავდებიან ფოსტის ასამბლეის iRedAdmin-ის საკუთარი ვებ ინტერფეისის ფუნქციონირებით. უფასო ვერსიაში შეგიძლიათ შექმნათ მხოლოდ დომენები, მომხმარებლის და ადმინისტრატორის საფოსტო ყუთები. თუ თქვენ გჭირდებათ მეტსახელის შექმნა, თქვენ ვერ შეძლებთ ამის გაკეთებას უფასო ვერსიაში iRedAdmin-ის საშუალებით. საბედნიეროდ, არსებობს უფასო გადაწყვეტა, სახელწოდებით PostfixAdmin, რომელიც საშუალებას გაძლევთ ამის გაკეთება. PostfixAdmin ადვილად ინტეგრირდება iRedMail-თან და მშვენივრად მუშაობს მასთან.

ინსტალაცია

ინსტალაციისთვის გვჭირდება ზემოთ ჩამოთვლილი ერთ-ერთი ოპერაციული სისტემა. მე ვიყენებ Ubuntu Server 18.04-ს. თქვენ ასევე უნდა გქონდეთ შეძენილი დომენის სახელი და კონფიგურირებული DNS ზონა. თუ იყენებთ თქვენი დომენის რეგისტრატორის DNS სერვერს, მაშინ დომენის ზონის მართვის განყოფილებაში უნდა გააკეთოთ ორი ჩანაწერი: A და MX. თქვენ ასევე შეგიძლიათ გამოიყენოთ თქვენი საკუთარი DNS თქვენი დომენის სახელის რეგისტრატორის პირად ანგარიშზე დელეგაციის დაყენებით.

დომენის ზონის დაყენება DNS რეგისტრატორის გამოყენებისას

Შენიშვნა! DNS პარამეტრები მოქმედებს რამდენიმე საათიდან ერთ კვირამდე. სანამ პარამეტრები ამოქმედდება, ფოსტის სერვერი არ იმუშავებს სწორად.

ინსტალაციისთვის, ჩამოტვირთეთ მიმდინარე ვერსია iRedMail ვებსაიტიდან. ამ დროისთვის არის 0.9.9.

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

შემდეგ ამოალაგეთ გადმოწერილი არქივი.

# tar xjf iRedMail-0.9.9.tar.bz2

არქივის გახსნა

და გადადით შექმნილ საქაღალდეში.

# cd iRedMail-0.9.9

საქაღალდე iRedMail ინსტალერით

საქაღალდის შიგთავსის შემოწმება

საქაღალდის შინაარსი

და გაუშვით iRedMail ინსტალაციის სკრიპტი.

# bash iRedMail.sh

ფოსტის სისტემის ინსტალაცია დაიწყება. ინსტალაციის პროცესში, თქვენ მოგიწევთ უპასუხოთ რამდენიმე კითხვას. ჩვენ ვეთანხმებით ინსტალაციის დაწყებას.

ინსტალაციის დაწყება

ინსტალაციის დირექტორიას შერჩევა

ახლა თქვენ უნდა აირჩიოთ ვებ სერვერი. არჩევანი არ არის დიდი, ამიტომ ვირჩევთ NGINX.

ვებ სერვერის შერჩევა

ახლა თქვენ უნდა აირჩიოთ მონაცემთა ბაზის სერვერი, რომელიც იქნება დაინსტალირებული და კონფიგურირებული ფოსტის სისტემასთან მუშაობისთვის. აირჩიეთ MariaDB.

მონაცემთა ბაზის სერვერის შერჩევა

დააყენეთ root პაროლი მონაცემთა ბაზისთვის.

მონაცემთა ბაზის root პაროლის შექმნა

ახლა ჩვენ ვაზუსტებთ ჩვენი ფოსტის დომენს.

ფოსტის დომენის შექმნა

შემდეგ შექმენით პაროლი ადმინისტრატორის ყუთისთვის [ელფოსტა დაცულია] domain.ru.

შექმენით ფოსტის ადმინისტრატორის პაროლი

ვებ კომპონენტების შერჩევა

ჩვენ ვადასტურებთ მითითებულ პარამეტრებს.

პარამეტრების დადასტურება

ინსტალაცია დაიწყო.

ინსტალაცია

ინსტალაციის დასრულების შემდეგ დაადასტურეთ წესის შექმნა iptablesამისთვის SSHდა გადატვირთეთ firewall. iRedMail მუშაობს iptables. Ubuntu-ში, ყველაზე ხშირად გამოყენებული firewall-ის მართვის პროგრამა UVW. თუ ამა თუ იმ მიზეზით გაქვთ ასეთი საჭიროება, მაშინ დააინსტალირეთ UVW (apt install ufw) და დაამატეთ წესები UVW(მაგალითი: ufw დაუშვას "nginx full"ან ufw დაუშვას Postfix) არ დაბლოკა ფოსტის სერვერი. თქვენ შეგიძლიათ ნახოთ ხელმისაწვდომი წესების სია ბრძანების გაშვებით: ufw აპლიკაციების სია. შემდეგ ჩართეთ UVW: ufw ჩართვა.

შექმენით iptables წესი

Firewall-ის გადატვირთვა

ეს ასრულებს iRedMail-ის ინსტალაციას. სისტემამ მოგვცა ვებ ინტერფეისის მისამართები და შესვლის რწმუნებათა სიგელები. ფოსტის სისტემის ყველა კომპონენტის გასააქტიურებლად, თქვენ უნდა გადატვირთოთ სერვერი.

ინსტალაციის დასასრული

ჩვენ გადატვირთეთ.

# გადატვირთვა

დაყენება

ჯერ უნდა დარწმუნდეთ, რომ ყველაფერი მუშაობს. ჩვენ ვცდილობთ შევიდეთ iReadAdmin მართვის პანელში https://domain/iredadmin. Შესვლა [ელფოსტა დაცულია] domain.ru, პაროლი შეიქმნა ინსტალაციის დროს. არის რუსულენოვანი ინტერფეისი.

როგორც ხედავთ ყველაფერი მუშაობს. iRedAdmin-ში შესვლისას, სავარაუდოდ, მიიღეთ უსაფრთხოების შეცდომა სერტიფიკატთან დაკავშირებით. ეს იმიტომ ხდება, რომ iRedMail-ს აქვს ხელმოწერილი სერტიფიკატი, რომელსაც ბრაუზერი ფიცს აგებს. ამ პრობლემის გადასაჭრელად, თქვენ უნდა დააინსტალიროთ მოქმედი SSL სერთიფიკატი. თუ თქვენ იყიდეთ, შეგიძლიათ დააინსტალიროთ. მაგალითში დავაინსტალირებ უფასო SSL-ს Let's Encrypt-ისგან.

Let's Encrypt SSL სერთიფიკატის ინსტალაცია

ჩვენ დავაინსტალირებთ სერთიფიკატს certbot უტილიტის გამოყენებით. ჯერ დავამატოთ საცავი.

# add-apt-repository ppa:certbot/certbot

შემდეგ ჩვენ ვაინსტალირებთ თავად certboot-ს საჭირო კომპონენტებით.

# apt install python-certbot-nginx

ვიღებთ სერთიფიკატს.

# certbot --nginx -d domain.ru

ბრძანების გაშვების შემდეგ სისტემა მოგთხოვთ შეიყვანოთ ელექტრონული ფოსტის მისამართი, შეიყვანოთ. ამის შემდეგ, სავარაუდოდ, მიიღებთ შეცდომას, რომ შეუძლებელია სერვერის ბლოკის პოვნა, რომლისთვისაც შეიქმნა სერტიფიკატი. ამ შემთხვევაში, ეს ნორმალურია, რადგან ჩვენ არ გვაქვს სერვერის ბლოკი. ჩვენთვის მთავარია სერთიფიკატის აღება.

სერთიფიკატის მიღება

როგორც ხედავთ, სერთიფიკატი წარმატებით იქნა მიღებული და სისტემამ გვაჩვენა გზები თავად სერთიფიკატამდე და გასაღებამდე. ისინი მხოლოდ ის არიან, რაც ჩვენ გვჭირდება. ზოგადად, მივიღეთ 4 ფაილი, რომლებიც შეინახება "/etc/letsencrypt/live/domain" საქაღალდეში. ახლა ჩვენ უნდა ვუთხრათ ვებ სერვერს ჩვენი სერთიფიკატის შესახებ, ანუ ჩავანაცვლოთ ჩაშენებული სერთიფიკატი იმით, რომელიც ახლახან მივიღეთ. ამისათვის საჭიროა მხოლოდ ერთი ფაილის რედაქტირება.

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

და შეცვალეთ მასში ბოლო ორი ხაზი.

SSL სერთიფიკატის შეცვლა

ჩვენ ვცვლით ფაილში არსებულ ბილიკებს იმ ბილიკებზე, რომლებიც სისტემამ გვითხრა სერტიფიკატის მიღებისას.

SSL სერთიფიკატის შეცვლა

და გადატვირთეთ NGINX.

# სერვისის nginx გადატვირთვა

ახლა ვცადოთ ხელახლა შესვლა. iRedAdmin.

SSL სერთიფიკატის დადასტურება

სერთიფიკატის შეცდომა აღარ არის. სერთიფიკატი მოქმედებს. შეგიძლიათ დააჭიროთ საკეტს და ნახოთ მისი თვისებები. როდესაც სერთიფიკატი იწურება, certboot ავტომატურად უნდა განაახლოს იგი.

ახლა მოდით ვისაუბროთ Dovecot-ისა და Postfix-ის სერტიფიკატზე. ამისათვის ჩვენ დავარედაქტირებთ ორ კონფიგურაციის ფაილს. Ჩვენ ვაკეთებთ:

# nano /etc/dovecot/dovecot.conf

ბლოკის პოვნა:

#SSL: გლობალური პარამეტრები.

და ჩვენ ვცვლით იქ რეგისტრირებულ სერთიფიკატს ჩვენთან.

სერთიფიკატის შეცვლა Dovecot-ისთვის

ასევე ყურადღება მიაქციეთ ხაზს "ssl_protocols". მისი მნიშვნელობა უნდა იყოს "!SSLv3", წინააღმდეგ შემთხვევაში თქვენ მიიღებთ "გაფრთხილება: SSLv2 არ არის მხარდაჭერილი OpenSSL-ის მიერ. გთხოვთ გაითვალისწინოთ, რომ წაშალოთ ის ssl_protocols" Dovecot-ის გადატვირთვისას.

# nano /etc/postfix/main.cf

ბლოკის პოვნა:

# SSL გასაღები, სერთიფიკატი, CA

და ჩვენ ვცვლით მასში არსებულ ბილიკებს ჩვენი სერტიფიკატის ფაილებისკენ მიმავალ ბილიკებზე.

სერთიფიკატის შეცვლა Postfix-ისთვის

ეს ასრულებს სერთიფიკატის ინსტალაციას. აუცილებელია Dovecot-ის და Postfix-ის გადატვირთვა, მაგრამ უმჯობესია სერვერის გადატვირთვა.

# სერვისის მტრედი გადატვირთვა

# გადატვირთვა

მიმდინარეობს PHPMyAdmin-ის ინსტალაცია

ეს ელემენტი არჩევითია, მაგრამ გირჩევთ, დაასრულოთ და დააინსტალიროთ PHPMyAdmin თქვენი მონაცემთა ბაზის გამოცდილებისთვის.

# apt დააინსტალირე phpmyadmin

ინსტალერი მოგთხოვთ იმუშაოთ რომელ ვებ სერვერთან დააკონფიგურიროთ PHPMyAdmin, რადგან NGINX არ არის ამ სიაში, უბრალოდ დააჭირეთ TAB-ს და გადადით.

მიმდინარეობს PHPMyAdmin-ის ინსტალაცია

ინსტალაციის დასრულების შემდეგ, იმისათვის, რომ phpmyadmin-მა იმუშაოს, თქვენ უნდა გააკეთოთ სიმლინკი იმ დირექტორიასთან, რომლითაც NGINX მუშაობს ნაგულისხმევად.

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

და სცადე წასვლა https://domain/phpmyadmin/

PHPMyAdmin მუშაობს. კავშირი დაცულია სერტიფიკატით, არ არის შეცდომები. Გაინძერი. მოდით შევქმნათ MySQL მონაცემთა ბაზის ადმინისტრატორი (MariaDB).

# mysql

და ჩვენ შევდივართ MariaDB მართვის კონსოლში. შემდეგი, ჩვენ ვასრულებთ ბრძანებებს სათითაოდ:

MariaDB > შექმენით მომხმარებლის "admin"@"localhost" იდენტიფიცირებული "პაროლით";
MariaDB > მიანიჭეთ ყველა პრივილეგია *.*-ზე "admin"@"localhost"-ს გრანტის ვარიანტით;
MariaDB > FLUSH პრივილეგიები;

MySQL მომხმარებლის შექმნა

ყველაფერი რიგზეა, თქვენ შესული ხართ. PHPMyAdmin მზად არის წასასვლელად.

PostfixAdmin-ის ინსტალაცია

პრინციპში, PostfixAdmin, ისევე როგორც PHPMyAdmin, არ შეიძლება დაინსტალირდეს. ფოსტის სერვერი კარგად იმუშავებს ამ კომპონენტების გარეშე. მაგრამ მაშინ ვერ შეძლებთ ფოსტის მეტსახელების შექმნას. თუ ეს არ გჭირდებათ, მაშინ თავისუფლად გამოტოვეთ ეს განყოფილებები. თუ თქვენ ჯერ კიდევ გჭირდებათ მეტსახელები, მაშინ გაქვთ ორი ვარიანტი: იReaAdmin-ის ფასიანი ვერსიის ყიდვა ან PostfixAdmin-ის ინსტალაცია. რა თქმა უნდა, ამის გაკეთება შეგიძლიათ დამატებითი პროგრამული უზრუნველყოფის გარეშე, მონაცემთა ბაზაში ფსევდონიმების ხელით ჩაწერით, მაგრამ ეს ყოველთვის არ არის მოსახერხებელი და ყველასთვის შესაფერისი არ არის. მე გირჩევთ გამოიყენოთ PostfixAdmin, ახლა განვიხილავთ მის ინსტალაციას და iRedMail-თან ინტეგრაციას. ჩვენ ვიწყებთ ინსტალაციას:

# apt install postfixadmin

ჩვენ ვეთანხმებით და ვქმნით პაროლს პროგრამის სისტემური მონაცემთა ბაზისთვის.

PostfixAdmin-ის ინსტალაცია

PostfixAdmin-ის ინსტალაცია

ჩვენ ვქმნით სიმლინკს ანალოგიით PHPMyAdmin-ის ინსტალაციასთან.

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

ჩვენ ვქმნით მომხმარებელს, რომლის სახელითაც ვებ სერვერი გაშვებულია დირექტორიაში. ჩვენს შემთხვევაში, NGINX მუშაობს როგორც www-data მომხმარებელი.

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

ახლა ჩვენ გვჭირდება PostfixAdmin კონფიგურაციის ფაილი და დავამატოთ ინფორმაცია მონაცემთა ბაზის შესახებ, რომელსაც იყენებს iRedAdmin. ნაგულისხმევად, ამ მონაცემთა ბაზას ეწოდება vmail. თუ გადადიხართ PHPMyAdmin-ზე, შეგიძლიათ ნახოთ იგი იქ. ასე რომ, იმისათვის, რომ PostfixAdmin-მა შეიტანოს ცვლილებები მონაცემთა ბაზაში, ჩვენ მას ვუნიშნავთ PostfixAdmin კონფიგურაციაში.

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

ხაზების პოვნა:

$CONF [" database_type "] = $dbtype;
$CONF ["database_host"] = $dbserver;
$CONF ["database_user"] = $dbuser;
$CONF ["database_password"] = $dbpass;
$CONF ["მონაცემთა_სახელი"] = $dbname;

და გაიხსენე:

$CONF["database_type"] = "mysqli"; # მონაცემთა ბაზის ტიპი
$CONF["database_host"] = "localhost"; # მონაცემთა ბაზის სერვერის ჰოსტი
$CONF["database_user"] = "ადმინისტრატორი"; # შედით vmail მონაცემთა ბაზაში ჩაწერის წვდომით. შეგიძლიათ გამოიყენოთ ადრე შექმნილი ადმინისტრატორი
$CONF["database_password"] = "პაროლი"; ზემოთ მითითებული მომხმარებლის # პაროლი
$CONF["database_name"] = "vmail"; # iRedMail მონაცემთა ბაზის სახელი

მონაცემთა ბაზის ინფორმაციის შეყვანა

თუ გეგმავთ SOGo ვებ ფოსტის კლიენტის გამოყენებას, მაშინ თქვენ უნდა გააკეთოთ კიდევ ერთი დამატებითი ნაბიჯი, კერძოდ, შეცვალოთ PostfixAdmin დაშიფვრა აბზაცში. $CONF ["დაშიფვრა"]დან "md5crypt"ზე "მტრედი:SHA512-CRYPT". თუ ამას არ გააკეთებთ, მაშინ როდესაც ცდილობთ ავტორიზაციას SOGo-ში PostfixAdmin-ში შექმნილი მომხმარებლის მიერ, თქვენ მიიღებთ შეცდომას არასწორი შესვლის ან პაროლით.

დაშიფვრის ტიპის შეცვლა

ახლა, იმისათვის, რომ წარმატებით დაასრულოთ ინსტალაცია და არ მიიღოთ შეცდომები, თქვენ უნდა მოიძიოთ მონაცემთა ბაზა. ამის გაკეთება მოსახერხებელია PHPMyAdmin-ის საშუალებით. აირჩიეთ vmail მონაცემთა ბაზა და გადადით SQL ჩანართზე. ფანჯარაში შეიყვანეთ:

DROP INDEX დომენი საფოსტო ყუთზე;
DROP INDEX დომენი მეტსახელზე;
TABLE ALTER alias ADD COLUMN `goto` ტექსტი NOT NULL;

მონაცემთა ბაზის მოთხოვნა

და დააჭირეთ "წინ". ახლა ყველაფერი მზად ვართ, შეგიძლიათ გადახვიდეთ PostfixAdmin ვებ ინტერფეისზე და დაასრულოთ ინსტალაცია. ამისათვის ბრაუზერში უნდა აკრიფოთ: https://domain/postfixadmin/setup.php.

შემდეგი უნდა გამოჩნდეს:

PostfixAdmin-ის ინსტალაცია

თუ ყველაფერი კეთდება ინსტრუქციის მიხედვით, მაშინ შეცდომები არ უნდა იყოს. თუ მაინც არიან, მაშინ ღალატობენ, რომ აღმოიფხვრას, თორემ სისტემა არ მოგცემთ გაგრძელების საშუალებას. დააყენეთ ინსტალაციის პაროლი და დააჭირეთ " პაროლის ჰეშის გენერირებასისტემა გამოიმუშავებს პაროლის ჰეშს, რომელიც უნდა იყოს ჩასმული პარამეტრში $CONF ["setup_password"].

PostfixAdmin-ის ინსტალაციის დასრულება

კონფიგურაციის ფაილის პარამეტრების შეცვლა

ახლა ჩვენ შევიყვანთ პაროლს, რომელიც ახლახან შევქმენით და ვქმნით PostfixAdmin ადმინისტრატორს. სჯობს არ შექმნათ ადმინისტრატორი პოსტმასტერ ლოგინით, რადგან შეიძლება პრობლემები იყოს iRedAdmin ადმინისტრაციის პანელში შესვლისას.

PostfixAdmin ადმინისტრატორის შექმნა

ყველაფერი, ადმინისტრატორი იქმნება. შეგიძლიათ შეხვიდეთ.

გთხოვთ გაითვალისწინოთ, რომ უსაფრთხოების თვალსაზრისით უმჯობესია გადარქმევა ან წაშალოთ setup.php ფაილი postfixadmin დირექტორიაში.

Წავედით: https://domain/postfixadmin/და შეიყვანეთ ახლად შექმნილი რწმუნებათა სიგელები. PostfixAdmin-ში, ისევე როგორც iRedAdmin-ში, ხელმისაწვდომია რუსული ენა. მისი შერჩევა შესაძლებელია ავტორიზაციის დროს.

ჩვენ ვცდილობთ შევქმნათ მომხმარებლის საფოსტო ყუთი.

ჩართეთ/გამორთეთ iRedMail მოდულები

iRedMail მოდულებს მართავს iRedAPD. მას აქვს კონფიგურაციის ფაილი, რომელიც შეიცავს სამუშაო მოდულებს. თუ არ გჭირდებათ კონკრეტული მოდული, შეგიძლიათ ამოიღოთ იგი კონფიგურაციის ფაილიდან და ის შეწყვეტს მუშაობას. Ჩვენ ვაკეთებთ:

# nano /opt/iredapd/settings.py

იპოვეთ ხაზი დანამატებიდა ამოიღეთ ის კომპონენტები, რომლებიც არ გჭირდებათ. მე ამოვიღებთ კომპონენტს "ნაცრისფერი სია". რა თქმა უნდა, ის საკმაოდ ეფექტურად იცავს სპამისგან, მაგრამ საჭირო ასოები ხშირად არ აღწევს.

Greylist (ნაცრისფერი სია) არის ავტომატური სპამისგან დაცვის ტექნოლოგია, რომელიც დაფუძნებულია გამგზავნის სერვერის ქცევის ანალიზზე. როდესაც "ნაცრისფერი სია" ჩართულია, სერვერი უარს ამბობს პირველად უცნობი მისამართის წერილის მიღებაზე, აცნობებს დროებით შეცდომის შესახებ. ამ შემთხვევაში, გამომგზავნი სერვერმა მოგვიანებით უნდა სცადო გაგზავნა. ჩვეულებრივ, სპამერები ამას არ აკეთებენ. თუ წერილი ხელახლა გაიგზავნება, ის ემატება სიას 30 დღით და ფოსტა უკვე გაცვლილია პირველივე ჯერზე. გამოიყენეთ ეს მოდული ან არ გადაწყვიტოთ თქვენთვის.

ფოსტის მოდულების ჩართვა/გამორთვა

ცვლილებების შეტანის შემდეგ უნდა გადატვირთოთ. iRedAPD.

# სერვისი iredapd გადატვირთვა

ფოსტის სერვერის ტესტირება

ეს ასრულებს iRedMail ფოსტის სერვერის დაყენებას. შეგიძლიათ გადახვიდეთ ფინალურ ეტაპზე - ტესტირებაზე. მოდით შევქმნათ ორი საფოსტო ყუთი. ერთი iRedAdmin-ის მეშვეობით შესამოწმებლად, მეორე PostfixAdmin-ის მეშვეობით და გაგზავნეთ წერილი ერთი საფოსტო ყუთიდან მეორეში და პირიქით. შექმენით საფოსტო ყუთი iRedAdmin-ში [ელფოსტა დაცულია] domain.ru. PostfixAdmin-ში - [ელფოსტა დაცულია] domain.ru

მომხმარებლის შექმნა iRedAdmin-ში

მომხმარებლის შექმნა PostfixAdmin-ში

შეამოწმეთ, რომ მომხმარებლები შეიქმნა.

თუ ყურადღებას მიაქცევთ "To" სვეტს PostfixAdmin საფოსტო ყუთების სიაში, შეგიძლიათ იხილოთ განსხვავება iRedAdmin-სა და PostfixAdmin-ში შექმნილ საფოსტო ყუთებს შორის. iRedAdmin-ში შექმნილი საფოსტო ყუთები მონიშნულია როგორც " მხოლოდ წინ", და PostfixAdmin-ში შექმნილი როგორც - " საფოსტო ყუთი". თავიდან დიდი ხნის განმავლობაში ვერ ვხვდებოდი რატომ ხდება ასე და რა განსხვავებაა მათ შორის და ბოლოს ერთი რამ შევამჩნიე. iRedAdmin-ში საფოსტო ყუთები იქმნება ფსევდონიმების გარეშე, ხოლო საფოსტო ყუთები PostfixAdmin-ში თავისი ალიასით.

და თუ ეს მეტსახელები წაიშლება, მაშინ საფოსტო ყუთები გამოჩნდება, როგორც iRedAdmin-ში შექმნილი. მხოლოდ წინ".

მეტსახელების ამოღება

მეტსახელები ამოღებულია. შეამოწმეთ PostfixAdmin.

როგორც ხედავთ, ყველა ყუთი გახდა "მხოლოდ წინ". ანალოგიურად, თუ iRedAdmin-ში შექმნილ საფოსტო ყუთში თქვენთვის ალიასს შექმნით, ის გახდება „ფოსტის ყუთი“. პრინციპში, ეს არ იმოქმედებს ფოსტის მუშაობაზე. ერთადერთი ის არის, რომ თქვენ ვერ შექმნით ალიასს PostfixAdmin-ში შექმნილ საფოსტო ყუთზე. მეტსახელის შექმნის ნაცვლად, დაგჭირდებათ არსებულის რედაქტირება. მეტსახელებზე საუბრისას, iRedMail-ის ახალ ვერსიაში, თქვენ უნდა შეცვალოთ Postfix-ის ერთ-ერთ ბარათზე, რომელიც პასუხისმგებელია მეტსახელებზე. და თუ ამას არ გააკეთებთ, მაშინ შექმნილი მეტსახელები არ იმუშავებს. ამისათვის საჭიროა ფაილში /etc/postfix/mysql/virtual_alias_maps.cfშესწორება:

Ჩვენ ვაკეთებთ:

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

და ვასწორებთ.

მეტსახელების დაყენება

გადატვირთეთ Postfix:

# სერვისის პოსტფიქსის გადატვირთვა

ამის შემდეგ ყველაფერი უნდა იმუშაოს.

ასე რომ, დავიწყოთ ფოსტის შემოწმება. ყუთში მომხმარებელი 1ჩვენ გავივლით Roundcube-ს და ყუთში მომხმარებელი 2- SOGo-ს საშუალებით და გაგზავნეთ წერილი საფოსტო ყუთიდან მომხმარებელი 1ზე მომხმარებელი 2და უკან.

ელფოსტის გაგზავნა Roundcube-ით

ელფოსტის მიღება SOGo-ში

წერილის გაგზავნა SOGo-ზე

ელფოსტის მიღება Roundcube-ში

ყველაფერი უპრობლემოდ მუშაობს. წერილის მიწოდებას ორიდან ხუთ წამამდე სჭირდება. ანალოგიურად, წერილები შესანიშნავად მიეწოდება Yandex და mail.ru სერვერებს (შემოწმებულია).

ახლა შევამოწმოთ მეტსახელები. მოდით შევქმნათ ყუთი მომხმარებელი 3და გააკეთეთ მეტსახელი საფოსტო ყუთიდან მომხმარებელი 1ყუთზე მომხმარებელი 2. და გაგზავნეთ წერილი ყუთიდან მომხმარებელი 3ყუთზე მომხმარებელი 1. ამ შემთხვევაში, წერილი ყუთში უნდა მივიდეს მომხმარებელი 2.

შექმენით მეტსახელი

ელ.წერილის გაგზავნა user3-ის საფოსტო ყუთიდან user1-ის საფოსტო ყუთში

წერილის მიღება user2-ის საფოსტო ყუთში

მეტსახელების მუშაობითაც ყველაფერი რიგზეა.

მოდით შევამოწმოთ ფოსტის სერვერის მუშაობა ლოკალური ფოსტის კლიენტის მეშვეობით. მაგალითად, განიხილეთ Mozilla Thunderbird. მოდით შევქმნათ კიდევ ორი ​​მომხმარებელი: კლიენტი 1და კლიენტი 2. ჩვენ დავაკავშირებთ ერთ საფოსტო ყუთს IMAP-ით, მეორეს POP3-ით და გავაგზავნით წერილს ერთი საფოსტო ყუთიდან მეორეში.

დაკავშირება IMAP-ის საშუალებით

POP3 კავშირი

ჩვენ ვუგზავნით წერილს კლიენტი 1-ისგან კლიენტ 2-ს.

გაგზავნა კლიენტისგან 1

მიიღეთ კლიენტზე 2

და საპირისპირო თანმიმდევრობით.

იგზავნება კლიენტისგან 2

მიიღეთ კლიენტზე 1

ყველაფერი მუშაობს.

თუ მიდიხარ: https://domain/netdata, მაშინ შეგიძლიათ დააკვირდეთ სისტემის მდგომარეობის გრაფიკებს.

დასკვნა

ეს ასრულებს iRedMail ფოსტის სისტემის ინსტალაციას, კონფიგურაციას და ტესტირებას. შედეგად, ჩვენ მივიღეთ სრულიად უფასო სრულფასოვანი ფოსტის სერვერი მოქმედი SSL სერთიფიკატით, ორი განსხვავებული ვებ-დაფუძნებული ფოსტის კლიენტი, ორი საკონტროლო პანელი, ასევე ანტი-სპამი და ანტივირუსი, რომელიც ჩაშენებულია ფოსტაში. თუ გსურთ, ვებ ფოსტის კლიენტების ნაცვლად, შეგიძლიათ გამოიყენოთ ადგილობრივი ფოსტის კლიენტები, როგორიცაა Microsoft Outlook ან Mozilla Thunderbird. თუ არ გეგმავთ ვებ ფოსტის კლიენტების გამოყენებას, მათ საერთოდ ვერ დააინსტალირებთ, რათა არ გადატვირთოთ სერვერი, ან დააინსტალიროთ ერთი რამ, რაც უფრო მოგწონთ. მე პირადად SOGo უფრო მომწონს, რადგან მისი ინტერფეისი ოპტიმიზებულია მობილური მოწყობილობებისთვის, რაც ძალიან კომფორტულს ხდის სმარტფონიდან ელფოსტის ნახვას. იგივე ეხება NetData-ს და iRedAdmin-ს, თუ მის გამოყენებას არ გეგმავთ, ჯობია არ დააინსტალიროთ. ფოსტის ეს სისტემა არ არის ძალიან მოთხოვნადი რესურსებზე. ეს ყველაფერი მუშაობს VPS სერვერზე 1024 მბ ოპერატიული და ერთი ვირტუალური პროცესორით. თუ თქვენ გაქვთ რაიმე შეკითხვა ამ ფოსტის სისტემის შესახებ, დაწერეთ კომენტარებში.

P.S. ამ პროდუქტის ტესტირებისას სხვადასხვა ოპერაციულ სისტემაზე 1 GB ოპერატიული მეხსიერებით (Ubuntu, Debian, CentOS), აღმოჩნდა, რომ 1 GB არ არის საკმარისი ClamAV-ის მუშაობისთვის. თითქმის ყველა შემთხვევაში, 1 გბ მეხსიერების გამოყენებისას, ანტივირუსი მიუთითებდა მონაცემთა ბაზის შეცდომაზე. ამავდროულად, Debian და Ubuntu ოპერაციულ სისტემებზე ანტივირუსი უბრალოდ არ ასკანირებდა სერვერზე გამავალ ფოსტას, წინააღმდეგ შემთხვევაში ყველაფერი კარგად მუშაობდა. CentOS-ზე სიტუაცია გარკვეულწილად განსხვავებული იყო. Clamd სერვისმა მთლიანად გათიშა სისტემა, რითაც შეუძლებელი გახდა სერვერის ნორმალურად მუშაობა. ვებ ინტერფეისებში შესვლის მცდელობისას NGINX პერიოდულად აძლევდა 502 და 504 შეცდომებს. ფოსტაც დროთა განმავლობაში გაიგზავნა. ამავდროულად, თუ დაამატებთ 2 გბ-მდე ოპერატიული მეხსიერებას, მაშინ ყველა შემთხვევაში არანაირი პრობლემა არ ყოფილა ანტივირუსისა და მთლიანად სერვერის მუშაობასთან დაკავშირებით. ClamAV-მა დაასკანირა ფოსტა, რომელიც გადიოდა ფოსტის სერვერზე და დაწერა ამის შესახებ ჟურნალებში. როდესაც ცდილობდით ვირუსის გაგზავნას დანართში, გაგზავნა დაიბლოკა. მეხსიერების მოხმარება იყო დაახლოებით 1.2 - 1.7 GB.

NGINX შეიძლება გამოყენებულ იქნას არა მხოლოდ როგორც ვებ სერვერი ან http-პროქსი, არამედ SMTP, IMAP, POP3 პროტოკოლების მეშვეობით ფოსტის პროქსინგისთვის. ეს დააყენებს:

• ერთი შესვლის წერტილი მასშტაბირებადი საფოსტო სისტემისთვის.
• დატვირთვის დაბალანსება ყველა ფოსტის სერვერს შორის.

ეს სტატია ინსტალირებულია Linux ოპერაციულ სისტემაზე. როგორც საფოსტო სერვისი, რომელზეც იგზავნება მოთხოვნები, შეგიძლიათ გამოიყენოთ postfix, exim, dovecot, exchange, iredmail ასამბლეა და სხვა.

მოქმედების პრინციპი

NGINX იღებს მოთხოვნებს და ახდენს ავთენტიფიკაციას ვებ სერვერზე. შესვლისა და პაროლის შემოწმების შედეგიდან გამომდინარე, პროქსი უბრუნებს პასუხს რამდენიმე სათაურით.

წარმატების შემთხვევაში:

ამრიგად, ჩვენ განვსაზღვრავთ ფოსტის სერვერის სერვერს და პორტს ავტორიზაციის საფუძველზე. ეს იძლევა უამრავ შესაძლებლობას პროგრამირების ენების შესაბამისი ცოდნით.

წარუმატებლობის შემთხვევაში:

ავტორიზაციის შედეგიდან და სათაურიდან გამომდინარე, კლიენტი გადამისამართდება ჩვენთვის საჭირო ფოსტის სერვერზე.

სერვერის მომზადება

მოდით შევიტანოთ გარკვეული ცვლილებები სერვერის უსაფრთხოების პარამეტრებში.

SELinux

გამორთეთ SELinux, თუ იყენებთ CentOS-ს ან თუ იყენებთ ამ უსაფრთხოების სისტემას Ubuntu-ზე:

vi /etc/selinux/config

SELINUX=გამორთულია

Firewall

თუ ჩვენ ვიყენებთ firewald-ს(ნაგულისხმევი CentOS-ზე):

firewall-cmd --მუდმივი --add-port=25/tcp --add-port=110/tcp --add-port=143/tcp

firewall-cmd --გადატვირთვა

თუ ვიყენებთ iptable-ებს(ნაგულისხმევი Ubuntu-ში):

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

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

* ამ მაგალითში ჩვენ დავუშვით SMTP (25), POP3 (110), IMAP (143).

NGINX-ის ინსტალაცია

ოპერაციული სისტემის მიხედვით, NGINX-ის დაყენება ოდნავ განსხვავებულია.

ან Linux ცენტოს:

დააინსტალირე nginx

ან Linux უბუნტუ:

apt დააინსტალირე nginx

ჩვენ ვუშვებთ სერვისის ავტომატურ დაწყებას და ვიწყებთ მას:

systemctl ჩართეთ nginx

systemctl start nginx

თუ NGINX უკვე დაინსტალირებულია სისტემაში, შეამოწმეთ რომელ მოდულებთან მუშაობს:

ჩვენ მივიღებთ იმ ვარიანტების ჩამონათვალს, რომლებითაც აგებულია ვებ სერვერი - მათ შორის უნდა ვნახოთ ---ფოსტით. თუ საჭირო მოდული არ არსებობს, თქვენ უნდა განაახლოთ nginx

NGINX-ის დაყენება

გახსენით nginx კონფიგურაციის ფაილი და დაამატეთ ვარიანტი ფოსტა:

vi /etc/nginx/nginx.conf

ფოსტა (

auth_http localhost:80/auth.php;

სერვერი (
მოსმენა 25;
პროტოკოლი smtp;
smtp_auth შესვლა ჩვეულებრივი cram-md5;
}

სერვერი (
მოუსმინე 110;
პროტოკოლი pop3;

}

სერვერი (
მოუსმინე 143;
პროტოკოლიმაპი;
}
}

* სად:

• სერვერის სახელი— ფოსტის სერვერის სახელი, რომელიც გამოჩნდება SMTP მისალმების დროს.
• auth_http— ვებ სერვერი და URL ავტორიზაციის მოთხოვნისთვის.
• proxy_pass_error_message— უშვებს ან უარყოფს შეტყობინების ჩვენებას წარუმატებელი ავთენტიფიკაციის შემთხვევაში.
• მოუსმინე- პორტი, რომელზედაც ისმენს მოთხოვნებს.
• ოქმიარის აპლიკაციის პროტოკოლი, რომელსაც შესაბამისი პორტი უსმენს.
• smtp_auth— SMTP-სთვის ავტორიზაციის ხელმისაწვდომი მეთოდები.
• pop3_auth— POP3-ისთვის ავტორიზაციის ხელმისაწვდომი მეთოდები.

http - სერვერის განყოფილებაში დაამატეთ:

სერვერი (
მოსმენა 80 default_server;
მოსმენა [::]:80 default_server;
...

მდებარეობა ~ \.php$ (
დააყენეთ $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;
მოიცავს fastcgi_params;
fastcgi_param DOCUMENT_ROOT $root_path;
}
...

გადატვირთეთ nginx სერვერი:

systemctl გადატვირთეთ nginx

PHP-ის ინსტალაცია და კონფიგურაცია

PHP-ის გამოყენებით ავთენტიფიკაციის შესასრულებლად, სისტემაზე უნდა იყოს დაინსტალირებული შემდეგი პაკეტები.

თუ CentOS:

yum დააინსტალირე php php-fpm

თუ უბუნტუ:

apt-get დააინსტალირეთ php php-fpm

დაიწყეთ PHP-FPM:

systemctl ჩართეთ php-fpm

systemctl დაწყება php-fpm

ავთენტიფიკაცია

შესვლა და პაროლი მოწმდება სკრიპტით, რომლის გზაც მითითებულია auth_http ვარიანტით. ჩვენს მაგალითში ეს არის PHP სკრიპტი.

შესვლისა და პაროლის გადამოწმების სკრიპტის ოფიციალური შაბლონის მაგალითი:

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

* ეს სკრიპტი იღებს ნებისმიერ შესვლას და პაროლს და გადამისამართებს მოთხოვნებს სერვერებზე 192.168.1.22 და 192.168.1.33 . ავტორიზაციის ალგორითმის დასაყენებლად, ჩვენ ვასწორებთ 61 - 64 სტრიქონებს. 73 - 77 სტრიქონები პასუხისმგებელია სერვერების დაბრუნებაზე, რომლებზეც გადამისამართება მიმდინარეობს - ამ მაგალითში, თუ შესვლა იწყება სიმბოლოებით. "ა", "გ", "ფ", "გ",შემდეგ გადამისამართება იქნება სერვერზე mailhost01, წინააღმდეგ შემთხვევაში, on mailhost02. სერვერის სახელების IP მისამართებზე დაფიქსირება შეიძლება დაყენდეს 31, 32 ხაზებზე, წინააღმდეგ შემთხვევაში, ზარი წარიმართება დომენის სახელით.

ფოსტის სერვერის დაყენება

მონაცემთა გაცვლა NGINX პროქსისა და ფოსტის სერვერს შორის აშკარაა. გამონაკლისს უნდა დაემატოს ავთენტიფიკაციის შესაძლებლობა PLAIN მექანიზმით. მაგალითად, dovecot-ის კონფიგურაციისთვის, გააკეთეთ შემდეგი:

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

ხაზების დამატება:

დისტანციური 192.168.1.11 (
disable_plaintext_auth = არა
}

* ამ მაგალითში, ჩვენ დავუშვებთ სერვერის ავთენტიფიკაციის PLAIN მოთხოვნას 192.168.1.11 .

ჩვენ ასევე ვამოწმებთ:

* თუ sslმნიშვნელობა ექნება საჭირო, შემოწმება არ იმუშავებს, რადგან ირკვევა, რომ ერთის მხრივ, სერვერი ნებას რთავს მოთხოვნებს გარკვევით, მაგრამ მოითხოვს ssl დაშიფვრას.

Dovecot სერვისის გადატვირთვა:

systemctl გადატვირთეთ dovecot

კლიენტის დაყენება

შეგიძლიათ გააგრძელოთ ჩვენი პროქსის პარამეტრების შემოწმება. ამისათვის, კლიენტის პარამეტრებში, მიუთითეთ nginx სერვერის მისამართი ან სახელი, როგორც IMAP/POP2/SMTP, მაგალითად:

* ამ მაგალითში ფოსტის კლიენტი კონფიგურირებულია სერვერთან დასაკავშირებლად 192.168.1.11 ღია პორტებით 143 (IMAP) და 25 (SMTP).

დაშიფვრა

ახლა მოდით დავაყენოთ SSL კავშირი. Nginx უნდა აშენდეს მოდულით mail_ssl_module- შეამოწმეთ ბრძანებით:

საჭირო მოდულის არარსებობის შემთხვევაში, ჩვენ ვაშენებთ nginx-ს.

ჩვენი კონფიგურაციის ფაილის რედაქტირების შემდეგ:

vi /etc/nginx/nginx.conf

ფოსტა (
server_name mail.domain.local;
auth_http localhost/auth.php;

proxy_pass_error_message ჩართულია;

SSL ჩართულია;
ssl_certificate /etc/ssl/nginx/public.crt;
ssl_certificate_key /etc/ssl/nginx/private.key;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_session_cache გაზიარებული:SSL:10m;
ssl_session_timeout 10მ;

სერვერი (
მოუსმინე 110;
პროტოკოლი pop3;
pop3_auth plain apop cram-md5;
}

სერვერი (
მოუსმინე 143;
პროტოკოლიმაპი;
}

მიზეზი: SELinux უსაფრთხოების სისტემა გააქტიურებულია.

გამოსავალი: გამორთეთ ან დააკონფიგურირეთ SELinux.