Nginx, Apache için yalnızca statik bir hizmet hızlandırıcıdan giderek daha fazla izole olarak kullanılan tam özellikli ve gelişmiş bir web sunucusuna geçerek hızla popülerlik kazanıyor. Bu yazımızda web sunucusundan en iyi şekilde yararlanmanızı sağlayacak nginx kullanımına ilişkin ilginç ve standart dışı senaryolardan bahsedeceğiz.
Posta proxy'siEn bariz olanla başlayalım: nginx'in posta proxy'si görevi görme yeteneği. Bu işlev başlangıçta nginx'tedir, ancak bazı nedenlerden dolayı üretimde son derece nadiren kullanılır, bazıları onun varlığından bile haberdar değildir. Ancak nginx, POP3, IMAP ve SMTP protokollerinin SSL ve StartTLS dahil olmak üzere çeşitli kimlik doğrulama yöntemleriyle proxylenmesini destekler ve bunu çok hızlı bir şekilde yapar.
Buna neden ihtiyaç var? Bu işlevin en az iki kullanımı vardır. Öncelikle, SMTP sunucumuz üzerinden önemsiz posta göndermeye çalışan sinir bozucu spam göndericilere karşı nginx'i bir kalkan olarak kullanın. Genellikle spam gönderenler çok fazla sorun yaratmazlar, çünkü kimlik doğrulama aşamasında hızla geri dönerler, ancak gerçekten çok sayıda olduğunda nginx, CPU kaynaklarının korunmasına yardımcı olacaktır. İkinci olarak, kullanıcıları birden fazla POP3/IMAP posta sunucusuna yönlendirmek için nginx'i kullanın. Elbette başka bir posta proxy'si bunu halledebilir, ancak örneğin HTTP aracılığıyla statik hizmet vermek için ön uçta nginx zaten kuruluysa neden sunucularla uğraşasınız ki?
Nginx'teki posta proxy'si pek standart değil. HTTP aracılığıyla uygulanan ek bir kimlik doğrulama katmanı kullanır ve yalnızca kullanıcı bu engeli geçerse aktarılır. Bu işlevsellik, nginx'in kullanıcı verilerini verdiği ve standart Tamam veya reddetme nedeni ("Geçersiz giriş veya şifre" gibi) şeklinde bir yanıt döndürdüğü bir sayfa / komut dosyası oluşturularak sağlanır. Komut dosyası aşağıdaki başlıklarla çalışır:
Kimlik doğrulama komut dosyası girişi HTTP_AUTH_USER: kullanıcı HTTP_AUTH_PASS: şifre HTTP_AUTH_PROTOCOL: posta protokolü (IMAP, POP3 veya SMTP)
Ve şu şekilde geri döner:
Kimlik doğrulama komut dosyası çıktısı HTTP_AUTH_STATUS: Tamam veya hata nedeni HTTP_AUTH_SERVER: yeniden yönlendirilecek gerçek posta sunucusu HTTP_AUTH_PORT: sunucu bağlantı noktası
Bu yaklaşımın dikkate değer bir özelliği, kimlik doğrulamanın kendisi için değil, kullanıcı adına, posta sunucularındaki mevcut yüklere ilişkin verilere ve hatta yuvarlak kullanarak en basit yük dengelemeyi organize etmeye bağlı olarak kullanıcıları farklı dahili sunuculara dağıtmak için kullanılabilmesidir. -robin. Ancak, kullanıcıları yalnızca dahili bir posta sunucusuna aktarmanız gerekiyorsa, gerçek bir komut dosyası yerine nginx'in kendisi tarafından uygulanan bir saplamayı kullanabilirsiniz. Örneğin, nginx yapılandırmasındaki en basit SMTP ve IMAP proxy'si şöyle görünecektir:
# vi /etc/nginx/nginx.conf mail ( # Kimlik doğrulama komut dosyasının adresi auth_http localhost:8080/auth; # XCLIENT komutunu devre dışı bırakın, bazı posta sunucuları bunu anlamıyor xclient kapalı; # IMAP sunucu sunucusu ( dinle 143; protokol imap; proxy açık; ) # SMTP sunucu sunucusu (dinle 25; protokol smtp; proxy açık; ))
# vi /etc/nginx/nginx.conf http ( # HTTP_AUTH_PROTOCOL başlık eşlemesinde gönderilen bağlantı noktasına bağlı olarak doğru posta sunucusu bağlantı noktasıyla eşleme $http_auth_protocol $mailport ( varsayılan 25; smtp 25; imap 143; ) # Kimlik doğrulamanın uygulanması " script" - her zaman Tamam'ı döndürür ve yukarıdaki eşleme sunucusunu kullanarak doğru bağlantı noktasını ayarlayarak kullanıcıyı dahili posta sunucusuna yönlendirir ( dinle 8080; konum / auth ( add_header "Kimlik Doğrulama Durumu" "Tamam"; add_header "Kimlik Doğrulama Sunucusu" " 192.168.0.1" ; add_header "Auth-Port" $mailport; return 200; )) )
Hepsi bu. Bu yapılandırma, bu durumda gereksiz olan komut dosyası biçiminde bir ek yük oluşturmadan kullanıcıları şeffaf bir şekilde dahili posta sunucusuna yönlendirmenize olanak tanır. Bir komut dosyası kullanılarak bu yapılandırma önemli ölçüde genişletilebilir: yük dengelemeyi ayarlayın, kullanıcıları LDAP veritabanına göre kontrol edin ve diğer işlemleri gerçekleştirin. Bir komut dosyası yazmak bu makalenin kapsamı dışındadır, ancak yalnızca temel düzeyde PHP ve Python bilgisiyle bile uygulanması çok kolaydır.
Video akışıNormal bir nginx tabanlı video barındırma kurulumu kolaydır. Tek yapmanız gereken, kodu dönüştürülmüş videoyu sunucunun erişebileceği bir dizine yüklemek, yapılandırmaya eklemek ve flash veya HTML5 oynatıcıyı bu dizinden video alacak şekilde yapılandırmaktır. Ancak bazı sitelerden sürekli video yayını ayarlamak istiyorsanız dış kaynak veya web kameraları, böyle bir şema işe yaramayacak ve özel akış protokollerine bakmanız gerekecek.
Bu sorunu çözen çeşitli protokoller vardır; bunların en verimlisi ve destekleneni RTMP'dir. Tek sorun, hemen hemen tüm RTMP sunucu uygulamalarında sorun yaşanmasıdır. Resmi Adobe Flash medya sunucusu paralı. Red5 ve Wowza Java'da yazıldığı için istenen performansı sağlayamıyor. Başka bir uygulama olan Erlyvideo, Erlang'da yazılmış, bu da küme kurulumu durumunda iyi, ancak tek bir sunucu için o kadar verimli değil.
Başka bir yaklaşım öneriyorum - nginx için RTMP modülünü kullanın. Mükemmel performansa sahiptir ve aynı zamanda hem sitenin web arayüzüne hem de video akışına hizmet etmek için tek bir sunucu kullanmanıza olanak tanır. Tek sorun, bu modülün resmi olmamasıdır, bu nedenle nginx'i onun desteğiyle kendiniz oluşturmanız gerekecek. Neyse ki montaj standart bir şekilde gerçekleştiriliyor:
$ sudo apt-get nginx'i kaldır $ cd /tmp $ wget http://bit.ly/VyK0lU -O nginx-rtmp.zip $ nginx-rtmp.zip dosyasını açın $ 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
Şimdi modülün yapılandırılması gerekiyor. Bu, her zamanki gibi nginx yapılandırması aracılığıyla yapılır:
Rtmp ( # Site/rtmp sunucusunda 1935 numaralı bağlantı noktasında yayın sunucusunu etkinleştirin (1935'i dinle; uygulama rtmp (canlı yayında; )) )
RTMP modülü çok iş parçacıklı bir yapılandırmada çalışamaz, bu nedenle nginx çalışan işlemlerinin sayısının bire düşürülmesi gerekecektir (daha sonra size bu sorunu nasıl aşacağınızı anlatacağım):
işçi_işlemleri 1;
Artık dosyayı kaydedebilir ve nginx'in yapılandırmayı yeniden okumasını sağlayabiliriz. Nginx kurulumu tamamlandı, ancak video akışının kendisi henüz elimizde değil, bu yüzden onu bir yere götürmemiz gerekiyor. Örneğin, geçerli dizindeki video.avi dosyası olsun. Bunu bir akışa dönüştürmek ve RTMP yayıncımıza sarmak için eski güzel FFmpeg'i kullanalım:
# ffmpeg -re -i ~/video.avi -c copy -f flv rtmp://localhost/rtmp/stream
Video dosyası H264 formatında değilse yeniden kodlanmalıdır. Bu, aynı FFmpeg kullanılarak anında yapılabilir:
# ffmpeg -re -i ~/video.avi -c:v libx264 -c:a libfaac -ar 44100 -ac 2 -f flv rtmp://localhost/rtmp/stream
Akış doğrudan web kamerasından da yakalanabilir:
# ffmpeg -f video4linux2 -i /dev/video0 -c:v libx264 -an -f flv rtmp://localhost/rtmp/stream
Akışı istemci tarafında görüntülemek için mplayer gibi RTMP özellikli herhangi bir oynatıcıyı kullanabilirsiniz:
$ mplayer rmtp://example.com/rtmp/stream
Veya oynatıcıyı doğrudan aynı nginx tarafından sunulan web sayfasına gömün (resmi belgelerden bir örnek):
En basit RTMP web oynatıcısı
jwplayer("container").setup(( modlar: [( type: "flash", src: "/jwplayer/player.swf", config: ( bufferlength: 1, file: "stream", Streamer: "rtmp:/ /localhost/rtmp", sağlayıcı: "rtmp", ) )] ));
Burada yalnızca iki önemli satır vardır: RTMP akışını belirten “file: “stream”” ve RTMP aktarıcının adresini belirten “streamer: “rtmp://localhost/rtmp””. Çoğu görev için bu ayarlar yeterli olacaktır. Tek bir adreste birkaç farklı akış başlatılabilir ve nginx bunları istemciler arasında etkili bir şekilde çoğaltacaktır. Ancak RTMP modülünün yapabileceği tek şey bu değil. Onun yardımıyla, örneğin, bir video akışının başka bir sunucudan yeniden iletilmesini organize edebilirsiniz. Bunun için FFmpeg sunucusuna hiç gerek yok, sadece aşağıdaki satırları config'e ekleyin:
# vi /etc/nginx/nginx.conf uygulaması rtmp ( canlı yayında; rtmp://rtmp.example.com'u çekin; )
Farklı niteliklerde birden fazla akış oluşturmanız gerekiyorsa FFmpeg kod çözücüyü doğrudan nginx'ten arayabilirsiniz:
# vi /etc/nginx/nginx.conf uygulaması rtmp ( canlı; exec ffmpeg -i rtmp://localhost/rtmp/$name -c:v flv -c:a -s 320x240 -f flv rtmp://localhost /rtmp-320x240/$name; ) uygulama rtmp-320x240 ( yayında; )
Bu konfigürasyonla aynı anda iki yayıncıya sahip olacağız, bunlardan biri rtmp://site/rtmp adresinde, ikincisi ise 320 x 240 kalitesinde rtmp://site/rtmp–320x240 adresinde yayın yapacak. Sitenin ilerisinde, oynatıcıyı yayıncının bir veya başka bir adresine kaydıracak bir flash oynatıcı ve kalite seçim düğmeleri asabilirsiniz.
Ve son olarak, ağa müzik yayınlamanın bir örneği:
doğru iken; ffmpeg yap -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; Tamamlandı
git vekiliGit sürüm kontrol sistemi, depolara yalnızca Git ve SSH protokolleri üzerinden değil aynı zamanda HTTP üzerinden de erişim sağlayabilmektedir. Bir zamanlar, HTTP erişiminin uygulanması ilkeldi ve depoyla tam teşekküllü çalışma sağlayamıyordu. Sürüm 1.6.6'dan bu yana durum değişti ve bugün bu protokol, örneğin bağlantının her iki tarafındaki güvenlik duvarı kısıtlamalarını atlamak veya bir web arayüzü ile kendi Git barındırma hizmetinizi oluşturmak için kullanılabilir.
Ne yazık ki, resmi belgeler yalnızca Apache web sunucusunu kullanarak Git'e erişimin organize edilmesinden bahsediyor, ancak uygulamanın kendisi standart bir CGI arayüzüne sahip harici bir uygulama olduğundan, lighttpd ve tabii ki dahil olmak üzere hemen hemen tüm diğer sunuculara eklenebilir. nginx. Bu, Git tarafından yüklenen sunucunun kendisinden ve küçük bir FastCGI sunucusu fcgiwrap'ten başka bir şey gerektirmez; bu gereklidir, çünkü nginx, CGI ile doğrudan nasıl çalışacağını bilmez, ancak FastCGI protokolünü kullanarak komut dosyalarını çağırabilir.
Tüm çalışma planı böyle görünecek. Fcgiwrap sunucusu arka planda kalacak ve bir CGI uygulaması yürütme isteğini bekleyecektir. Nginx ise, belirttiğimiz adrese her erişildiğinde, FastCGI arayüzü aracılığıyla git-http-backend CGI ikili dosyasının yürütülmesini talep edecek şekilde yapılandırılacaktır. Bir istek alındığında fcgiwrap, GIT istemcisi tarafından iletilen belirtilen CGI bağımsız değişkenleriyle git-http-backend'i çalıştırır ve sonucu döndürür.
Böyle bir şemayı uygulamak için önce fcgiwrap'i kuruyoruz:
$ sudo apt-get fcgiwrap'i yükle
Yapılandırmanıza gerek yoktur, tüm parametreler FastCGI protokolü üzerinden iletilir. Ayrıca otomatik olarak başlayacaktır. Bu nedenle geriye yalnızca nginx'i yapılandırmak kalır. Bunu yapmak için /etc/nginx/sites-enabled/git dosyasını oluşturun (böyle bir dizin yoksa ana yapılandırmaya yazabilirsiniz) ve aşağıdakileri yazın:
# vi /etc/nginx/sites-enabled/git sunucusu ( # 8080 numaralı bağlantı noktasını bekle 8080'i dinle; # Sunucumuzun adresi (DNS girişi eklemeyi unutmayın) sunucu_adı git.example.ru; # Günlükler erişim_log /var /log/nginx /git-http-backend.access.log; error_log /var/log/nginx/git-http-backend.error.log; # Anonim erişim konumu için birincil adres / ( # İndirmeye çalışırken, if ($ arg_service ~* "git-receive-pack") ( rewrite ^ /private$uri last; ) include /etc/nginx/fastcgi_params; # Git-http-backend fastcgi_param'ımızın adresi SCRIPT_FILENAME /usr /lib/git-core/git- http-backend; # Git deposu adresi fastcgi_param GIT_PROJECT_ROOT /srv/git; # Dosya adresi fastcgi_param PATH_INFO $uri; # Sunucu adresi fcgiwrap fastcgi_pass 127.0.0.1:9001; ) # Yazma erişim konumu adresi ~/private(/.* )$ ( # Kullanıcı izinleri auth_basic "git anonim salt okunur, kimliği doğrulanmış yazma"; # htpasswd'ye dayalı HTTP kimlik doğrulaması auth_basic_user_file /etc/nginx/htpasswd; # FastCGI ayarları /etc/nginx/fastcgi_params'ı içerir; 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; ))
Bu yapılandırma üç önemli şeyi varsayar:
Hepsi bu, nginx'i yeniden başlatın:
Mikro önbelleğe almaAniden çok büyük yükler almaya başlayan (en büyük haber sitelerinden birinin sayfasına girmiş) ve içeriğin geri dönüşüyle başa çıkmayı bırakan dinamik, sık sık güncellenen bir sitenin olduğu bir durumu hayal edelim. Doğru önbellekleme şemasının yetkin bir şekilde optimizasyonu ve uygulanması uzun zaman alacaktır ve sorunların şimdi ele alınması gerekmektedir. Ne yapabiliriz?
Bu durumdan minimum kayıpla çıkmanın birkaç yolu var ama en ilginç fikir Fenn Bailey'den (fennb.com) geldi. Buradaki fikir, nginx'i basitçe sunucunun önüne koymak ve onu iletilen tüm içeriği önbelleğe almaya zorlamaktır, ancak yalnızca önbelleğe almakla kalmayıp, yalnızca bir saniyeliğine. Burada öne çıkan nokta, saniyede yüzlerce ve binlerce site ziyaretçisinin aslında arka uca yalnızca bir çağrı oluşturacağı ve çoğunun önbelleğe alınmış bir sayfa alacağıdır. Aynı zamanda pek kimse farkı fark etmeyecektir çünkü dinamik bir sitede bile bir saniyenin genellikle hiçbir anlamı yoktur.
Bu fikrin uygulanmasıyla ilgili yapılandırma o kadar karmaşık görünmeyecek:
# vi /etc/nginx/sites-enabled/cache-proxy # Önbelleği yapılandır proxy_cache_path /var/cache/nginx seviyeleri=1:2 tuşları_zon=microcache:5m max_size=1000m; sunucu ( listen 80; sunucu_adı example.com; # Önbellek adresi konumu / ( # Önbellek varsayılan olarak etkin set $no_cache ""; # GET ve HEAD dışındaki tüm yöntemler için önbelleği devre dışı bırakın if ($request_method !~ ^(GET|HEAD) $ ) ( set $no_cache "1"; ) # İstemci siteye içerik yüklüyorsa (no_cache = 1), kendisine verilen verilerin iki saniye boyunca önbelleğe alınmamasını ve indirme sonucunu görebilmesini sağlıyoruz. ($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 değişkeninin durumuna bağlı olarak önbelleği etkinleştirin / devre dışı bırakın proxy_no_cache $no_cache; proxy_cache_bypass $no_cache; # Gerçek sunucuya proxy istekleri proxy_pass http://appserver.example.ru; proxy_cache mikrocache; proxy_cache_key $scheme$host$request_method$ request_uri; proxy_cache_valid 200 1s; # Gürleyen sürü sorunundan koruyun proxy_cache_use_stale güncelleme; # Standart başlıklar ekleyin proxy_set_header Ana Bilgisayar $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # 1 MB proxy_max_temp_file_size 1M'den büyük dosyaları önbelleğe almayın; ))
Bu yapılandırmada özel bir yer "proxy_cache_use_stale update;" satırı tarafından işgal edilmiştir; bu satır olmasaydı, önbellek güncellemesi sırasında gelen istekler nedeniyle arka uç sunucusunda periyodik yük patlamaları alırdık. Aksi takdirde her şey standarttır ve daha fazla açıklamaya gerek kalmadan açık olmalıdır.
Proxy'nin hedef kitleye yaklaştırılmasıİnternet hızlarındaki yaygın küresel artışa rağmen, sunucunun hedef kitleden fiziksel uzaklığı hala rol oynamaya devam ediyor. Bu, eğer bir Rus sitesi Amerika'da bir yerde bulunan bir sunucuda çalışıyorsa, ona erişim hızının önceden olduğundan daha yavaş olacağı anlamına gelir. Rus sunucusu aynı kanal genişliğiyle (tabii ki diğer tüm faktörlere gözlerinizi kapatırsanız). Başka bir şey de, bakım açısından da dahil olmak üzere sunucuları yurtdışında barındırmanın genellikle daha karlı olmasıdır. Bu nedenle, daha yüksek getiri oranları şeklinde kar elde etmek için bir numaraya gitmeniz gerekecek.
Biri seçenekler: Ana üretken sunucuyu Batı'ya yerleştirmek ve Rusya'da konuşlandırmak için çok fazla kaynak gerektirmeyen, statik sağlayan ön uç. Bu, ciddi maliyetler olmadan hızlı bir şekilde kazanmanıza olanak sağlayacaktır. Bu durumda ön uç için nginx yapılandırması, hepimizin aşina olduğu basit bir proxy uygulaması olacaktır:
# vi /etc/nginx/sites-enabled/proxy # Önbelleği 30 gün süreyle 100 GB depolama alanında saklayın proxy_cache_path /var/cache/nginx seviyeleri=1:2 tuşları_zon=statik:32m etkin değil=30d max_size=100g; sunucu ( listen 80; sunucu_adı example.com; # Aslında proxy konumumuz ~* .(jpg|jpeg|gif|png|ico|css|midi|wav|bmp|js|swf|flv|avi|djvu|mp3) $ ( # Arka uç adresi proxy_pass back.example.com:80; proxy_redirect kapalı; proxy_set_header Ana Bilgisayar $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_buffer_size 16k; proxy_buffers 32 16k; proxy_cache statik; proxy_cache_valid 30d; proxy_ignore_headers "Önbellek Kontrolü" "Sona Eriyor"; proxy_cache_key "$uri$is_args$args"; proxy_cache_lock açık; ))
sonuçlarGünümüzde nginx'in yardımıyla, çoğu web sunucusu ve HTTP protokolü ile ilgisi olmayan birçok farklı görevi çözebilirsiniz. Posta proxy'si, akış sunucusu ve Git arayüzü görevlerden yalnızca birkaçıdır.
Bu makalede NGINX Plus veya NGINX Açık Kaynak'ın bir posta sunucusu veya harici posta hizmeti için proxy olarak nasıl yapılandırılacağı açıklanacaktır.
giriişNGINX, posta hesaplarını barındıran yukarı akış posta sunucularından birine IMAP, POP3 ve SMTP protokollerini proxy olarak gönderebilir ve böylece e-posta istemcileri için tek bir uç nokta olarak kullanılabilir. Bu, aşağıdakiler gibi bir dizi fayda sağlayabilir:
- posta sunucularının sayısını kolayca ölçeklendirme
- farklı kurallara göre bir posta sunucusu seçmek; örneğin, müşterinin IP adresine göre en yakın sunucuyu seçmek
- yükü posta sunucuları arasında dağıtma
NGINX Plus (vekil e-posta trafiği için gerekli Posta modüllerini zaten içerir) veya NGINX Açık Kaynak, e-posta proxy işlevi için --with-mail parametresini ve SSL/TLS desteği için --with-mail_ssl_module parametresini kullanarak Posta modüllerini derledi:
$ ./configure --with-mail --with-mail_ssl_module --with-openssl=[ DIR] /openssl-1.1.1
IMAP, POP3 ve/veya SMTP postası sunucular veya harici bir posta hizmeti
NGINX yapılandırma dosyasında:
posta(#...)
posta ( sunucu_adı mail.example.com ; #... )
posta ( sunucu_adı mail.example.com ; auth_http localhost : 9000 /cgi-bin/nginxauth.cgi ; #... )
Alternatif olarak, proxy_pass_error_message yönergesini belirterek, kimlik doğrulama sunucusundaki hatalar hakkında kullanıcıya bilgi verilip verilmeyeceğini belirtin. Bir posta kutusunun belleği yetersiz kaldığında bu kullanışlı olabilir:
posta ( sunucu_adı mail.example.com ; auth_http localhost : 9000 /cgi-bin/nginxauth.cgi ; proxy_pass_error_message açık ; #... )
Her SMTP, IMAP veya POP3 sunucusunu sunucu bloklarıyla yapılandırın. Her sunucu için şunları belirtin:
- the Port numarası dinleme yönergesiyle belirtilen protokole karşılık gelen
- the protokol protokol direktifi ile (belirtilmemişse, listen direktifinde belirtilen porttan otomatik olarak algılanacaktır)
- izin verildi kimlik doğrulama yöntemleri imap_auth, pop3_auth ve smtp_auth direktifleriyle:
sunucu (dinle 25; protokol smtp; smtp_auth oturum açma düz cram-md5;) sunucu (dinle 110; protokol pop3; pop3_auth düz apop cram-md5;) sunucu (dinle 143; protokol imap;)
Posta Proxy'si için Kimlik Doğrulamayı Ayarlamaİstemciden gelen her POP3/IMAP/SMTP isteğinin kimliği ilk olarak harici bir HTTP kimlik doğrulama sunucusunda veya bir kimlik doğrulama komut dosyasıyla doğrulanır. NGINX posta sunucusu proxy'si için bir kimlik doğrulama sunucusuna sahip olmak zorunludur. Sunucu, HTTP protokolünü temel alan NGINX kimlik doğrulama protokolüne uygun olarak kendiniz oluşturulabilir.
Kimlik doğrulama başarılı olursa, kimlik doğrulama sunucusu bir yukarı akış sunucusu seçecek ve isteği yönlendirecektir. Bu durumda sunucudan gelecek yanıt aşağıdaki satırları içerecektir:
HTTP/1.0 200 Tamam Kimlik Doğrulama Durumu: Tamam Kimlik Doğrulama Sunucusu: # posta işleme için kullanılacak yukarı akış sunucusunun sunucu adı veya IP adresi Kimlik Doğrulama Bağlantı Noktası: # yukarı akış sunucusunun bağlantı noktası
Kimlik doğrulama başarısız olursa, kimlik doğrulama sunucusu bir hata mesajı döndürecektir. Bu durumda sunucudan gelecek yanıt aşağıdaki satırları içerecektir:
HTTP/1.0 200 Tamam Kimlik Doğrulama Durumu: # istemciye döndürülecek bir hata mesajı, örneğin “Geçersiz kullanıcı adı veya şifre” Kimlik Doğrulama Bekleme: # bağlantı kapatılana kadar kalan kimlik doğrulama denemelerinin sayısı
Her iki durumda da yanıtın şunları içereceğini unutmayın: HTTP/1.0 200 Tamam bu kafa karıştırıcı olabilir.
Kimlik doğrulama sunucusuna gelen istekler ve yanıtlara ilişkin daha fazla örnek için NGINX Referans belgelerindeki ngx_mail_auth_http_module'e bakın.
Posta Proxy'si için SSL/TLS KurulumuSSL/TLS üzerinden POP3/SMTP/IMAP kullanarak, istemci ile posta sunucusu arasında aktarılan verilerin güvenliğinin sağlandığından emin olursunuz.
Posta proxy'sine yönelik SSL/TLS'yi etkinleştirmek için:
Komut satırına nginx -V komutunu yazıp ardından çıktıda with --mail_ssl_module satırını arayarak NGINX'inizin SSL/TLS desteğiyle yapılandırıldığından emin olun:
$ nginx -V argümanları yapılandır: ... with--mail_ssl_module
Sunucu sertifikaları ve özel anahtar aldığınızdan ve bunları sunucuya koyduğunuzdan emin olun. Sertifika, güvenilir bir sertifika yetkilisinden (CA) alınabilir veya OpenSSL gibi bir SSL kitaplığı kullanılarak oluşturulabilir.
ssl açık;
irkiliyor;
SSL sertifikaları ekleyin: ssl_certificate direktifiyle sertifikaların yolunu belirtin (PEM formatında olmalıdır) ve ssl_certificate_key direktifinde özel anahtarın yolunu belirtin:
posta ( #... ssl_certificate /etc/ssl/certs/server.crt ; ssl_certificate_key /etc/ssl/certs/server.key ; )
SSL/TLS'nin yalnızca güçlü sürümlerini ve şifrelerini ssl_protocols ve ssl_ciphers yönergeleriyle kullanabilir veya kendi tercih ettiğiniz protokolleri ve şifreleri ayarlayabilirsiniz:
posta ( #... ssl_protocols TLSv1 TLSv1.1 TLSv1.2 ; ssl_ciphers HIGH:!aNULL:!MD5 ; )
Posta Proxy'si için SSL/TLS'yi optimize etmeBu ipuçları NGINX posta proxy'nizi daha hızlı ve daha güvenli hale getirmenize yardımcı olacaktır:
İşçi_işlemleri yönergesi posta bağlamıyla aynı düzeyde ayarlandığında, çalışan süreçlerin sayısını işlemci sayısına eşitleyin:
işçi_işlemleri otomatik; posta(#...)
Paylaşılan oturum önbelleğini etkinleştirin ve yerleşik oturum önbelleğini auto ile devre dışı bırakın; posta ( sunucu_adı mail.example.com ; auth_http localhost : 9000 /cgi-bin/nginxauth.cgi ; proxy_pass_error_message açık ; ssl açık ; ssl_certificate /etc/ssl/certs/server.crt ; ssl_certificate_key /etc/ssl/certs/server. anahtar ; ssl_protocols TLSv1 TLSv1.1 TLSv1.2 ; ssl_ciphers HIGH:!aNULL:!MD5 ; ssl_session_cache paylaşılan:SSL:10m ; ssl_session_timeout 10m ; sunucu ( dinle 25 ; protokol smtp ; smtp_auth oturum açma düz cram-md5 ; ) sunucu ( dinle 11 0 ; protokol pop3 ; pop3_auth düz apop cram-md5 ; ) sunucu ( dinle 143 ; protokol imap'i ; ))
Bu örnekte üç e-posta proxy sunucusu vardır: SMTP, POP3 ve IMAP. Sunucuların her biri SSL ve STARTTLS desteği ile yapılandırılmıştır. SSL oturum parametreleri önbelleğe alınacaktır.
Proxy sunucusu HTTP kimlik doğrulama sunucusunu kullanır; yapılandırması bu makalenin kapsamı dışındadır. Sunucudan gelen tüm hata mesajları istemcilere döndürülecektir.
Nginx, Igor Sysoev (rambler.ru) tarafından geliştirilen küçük, çok hızlı, oldukça işlevsel bir web sunucusu ve posta proxy sunucusudur. Sistem kaynaklarının çok düşük tüketimi ve hızının yanı sıra yapılandırma esnekliği nedeniyle web nginx sunucusu genellikle aşağıdaki gibi daha ağır sunuculara ön uç olarak kullanılır: Apaçi, yüksek yüklü projelerde. Klasik seçenek Nginx - Apache - FastCGI paketidir. Böyle bir şemada çalışmak, nginx sunucusu, HTTP yoluyla gelen tüm istekleri kabul eder ve yapılandırmaya ve isteğin kendisine bağlı olarak, isteğin kendisini işleyip istemciye hazır bir yanıt verip vermeyeceğine veya arka uçlardan birine işlenmek üzere bir istek gönderip göndermeyeceğine karar verir ( Apaçi veya FastCGI).
Bilindiği gibi, Apache sunucusu, her istek ayrı bir işlemde (iş parçacığı) işlenir, şunu söylemeliyim ki, oldukça az miktarda sistem kaynağı tüketmiyor, bu tür 10-20 işlem varsa, bu saçmalık ve 100-500 veya varsa bunların sayısı arttıkça sistem eğlenceli olmaktan çıkıyor.
Böyle bir durumu hayal etmeye çalışalım. varsayalım Apaçi 300 geliyor HTTP istekleri Müşterilerden 150 müşteri hızlı kiralık hatlarda, diğer 150 müşteri ise modem olmasa bile nispeten yavaş İnternet kanallarında oturuyor. Bu durumda ne olur? Ve aşağıdakiler olur, Apache web sunucusu, bu 300 bağlantıyı işlemek için, her işlem (iş parçacığı) için oluşturur, hızlı bir şekilde içerik üretir ve 150 hızlı istemci, isteklerinin sonucunu, onlara hizmet eden süreçleri anında alır. ölecek ve kaynaklar serbest bırakılacak ve 150'si yavaş olacak ve dar bir İnternet kanalı nedeniyle isteklerinin sonuçlarının toplanması yavaş olacak, bunun sonucunda 150 süreç sistemde askıda kalacak Apaçi, istemcilerin web sunucusu tarafından oluşturulan içeriği almasını bekleyerek birçok sistem kaynağını tüketir. Doğal olarak durum varsayımsal ama özün açık olduğunu düşünüyorum. Yukarıdaki durumu düzeltmek için paket yardımcı olur. İstemciden gelen isteğin tamamını okuduktan sonra, onu işlenmek üzere iletir. Apaçi, bu da içerik üretir ve Nginx'e mümkün olan en kısa sürede hazır yanıtı döndürür, ardından süreci rahat bir şekilde sonlandırabilir ve işgal ettiği sistem kaynaklarını serbest bırakabilir. Nginx web sunucusu, isteğin sonucunu alıyor Apaçi, bunu bir arabelleğe veya hatta diskteki bir dosyaya yazar ve onu yavaş istemcilere keyfi olarak uzun bir süre verebilir, bu sırada çalışan süreçleri o kadar az kaynak tüketir ki .. "bunun hakkında konuşmak bile saçma" ©. :) Böyle bir plan, sistem kaynaklarından önemli ölçüde tasarruf sağlar, tekrar ediyorum, ancak Nginx çalışan süreçleri çok az miktarda kaynak tüketiyor, bu büyük projeler için daha da önemli.
Ve bu, Nginx sunucusunun yapabileceklerinin yalnızca küçük bir kısmı, verileri önbelleğe alma ve onunla çalışma olasılığını unutmayın. önbelleğe alınmış. Ana olanları listeleyeceğim işlevsellik Nginx web sunucusu.
Nginx sunucusunun HTTP sunucusu olarak işlevselliği- Statik içerik işleme, dizin dosyaları, dizin listeleme, açık dosya tanımlayıcı önbelleği;
- Önbelleğe alma, yük dengeleme ve yük devretme ile hızlandırılmış proxy oluşturma;
- Hızlandırılmış Destek FastCGIönbelleğe alma, yük dengeleme ve hata toleransına sahip sunucular;
- Modüler yapı, çeşitli filtreler için destek (SSI, XSLT, GZIP, özgeçmiş, parçalanmış yanıtlar);
- SSL ve TLS SNI uzantıları desteği;
- IP tabanlı veya isme dayalı sanal sunucular;
- KeepAlive ve ardışık düzen bağlantılarıyla çalışma;
- Herhangi bir zaman aşımını ve arabelleklerin sayısını ve boyutunu aynı düzeyde yapılandırma yeteneği Apache sunucusu;
- Müşterinin adresine bağlı olarak çeşitli eylemlerin gerçekleştirilmesi;
- Düzenli ifadeler kullanarak URI'yi değiştirme;
- 4xx ve 5xx için özel hata sayfaları;
- İstemci adresine veya şifreye dayalı erişim kısıtlaması;
- Günlük dosyası formatlarını ayarlama, günlük döndürme;
- Müşteriye yanıt verme hızının sınırlandırılması;
- Eşzamanlı bağlantı ve isteklerin sayısını sınırlamak;
- PUT, DELETE, MKCOL, COPY ve MOVE yöntemleri desteği;
- Çalışmayı durdurmadan ayarların değiştirilmesi ve sunucunun güncellenmesi;
- yerleşik perl;
- Harici bir HTTP kimlik doğrulama sunucusu kullanarak IMAP/POP3 arka ucuna iletme;
- Kullanıcının SMTP'sinin harici bir HTTP kimlik doğrulama sunucusunda kontrol edilmesi ve dahili bir SMTP sunucusuna iletilmesi;
- Aşağıdaki kimlik doğrulama yöntemleri için destek:
- POP3 - KULLANICI/ŞİFRE, APOP, KİMLİK GİRİŞİ/DÜZ/CRAM-MD5;
- IMAP - GİRİŞ, YETKİLENDİRME GİRİŞİ/DÜZ/CRAM-MD5;
- SMTP - YETKİLENDİRME LOGI / DÜZ / CRAM-MD5;
- SSL desteği;
- STARTTLS ve STLS desteği;
- FreeBSD, 3'ten 8'e kadar platformlar, i386 ve amd64;
- Linux, 2.2'den 2.6'ya - i386 platformu; Linux 2.6 - amd64;
- Solaris 9 - i386 ve sun4u platformları; Solaris 10 - i386, amd64 ve sun4v platformları;
- MacOS X platformları ppc, i386;
- Windows XP, Windows Server 2003; (Şu anda beta test aşamasındadır)
- Ana (ana) işlem, ayrıcalığı olmayan bir kullanıcı altında çalışan birkaç (yapılandırma dosyasında yapılandırılabilir) çalışan işlemler;
- Aşağıdaki bağlantı işleme yöntemleri için destek:
- seçme- standart yöntem. Belirli bir platformda daha verimli bir yöntem bulunamazsa ilgili Nginx modülü otomatik olarak oluşturulur. --with-select_module veya --without-select_module yapılandırma seçeneklerini kullanarak bu modülün yapısını açılmaya veya kapatılmaya zorlayabilirsiniz.
- anket standart yöntemdir. Belirli bir platformda daha verimli bir yöntem bulunamazsa ilgili Nginx modülü otomatik olarak oluşturulur. --with-poll_module veya --without-poll_module yapılandırma seçeneklerini kullanarak bu modülün yapısını açılmaya veya kapatılmaya zorlayabilirsiniz.
- kqueue, FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0 ve MacOS X işletim sistemlerinde kullanılan etkili bir yöntemdir.Çift işlemcili MacOS X makinelerde kullanıldığında çekirdek paniğine neden olabilir.
- epoll, Linux 2.6+'da kullanılan etkili bir yöntemdir. SuSE 8.2 gibi bazı dağıtımların 2.4 çekirdeğinde epoll'u destekleyen yamaları vardır.
- rtsig - gerçek zamanlı sinyaller, Linux 2.2.19+'da kullanılan etkili bir yöntem. Varsayılan olarak tüm sistem için kuyrukta 1024'ten fazla sinyal bulunamaz. Bu, yüksek yüke sahip sunucular için yeterli değildir, /proc/sys/kernel/rtsig-max çekirdek parametresi kullanılarak kuyruk boyutunun arttırılması gerekir. Ancak Linux 2.6.6-mm2'den itibaren bu seçenek kaldırılmıştır; bunun yerine her işlemin boyutu RLIMIT_SIGPENDING tarafından belirlenen ayrı bir sinyal kuyruğu vardır.
- Sıra dolduğunda, nginx sunucusu onu sıfırlar ve durum normale dönene kadar anket yöntemiyle bağlantıları yönetir.
- /dev/poll verimli bir yöntemdir ve Solaris 7 11/99+, HP/UX 11.22+ (eventport), IRIX 6.5.15+ ve Tru64 UNIX 5.1A+ işletim sistemlerinde desteklenir.
- eventport - olay bağlantı noktaları Solaris 10'da kullanılan etkili bir yöntemdir. Kullanmadan önce çekirdek paniğini önlemek için bir yama kurulmalıdır.
- EV_CLEAR, EV_DISABLE (olayın geçici olarak devre dışı bırakılması için), NOTE_LOWAT, EV_EOF, mevcut veri sayısı, hata kodları gibi kqueue yönteminin özelliklerini kullanma;
- sendfile (FreeBSD 3.1+, Linux 2.2.+, Mac OS X 10.5+), sendfile64 (Linux 2.4.21+) ve sendfilev (Solaris 8 7/01+) ile çalışın;
- Kabul filtreleri (FreeBSD 4.1+) ve TCP_DEFER_ACCEPT (Linux 2.4+) desteği;
- 10.000 boşta kalan HTTP canlı tutma bağlantısı yaklaşık 2,5 milyon bellek tüketir;
- Minimum veri kopyalama işlemi sayısı;
iRedMail açık kaynaklı bir posta sunucusu yapısıdır. Derleme, Postfix SMTP sunucusunu (Posta Aktarım Aracısı, kısaca MTA) temel alır. Yapı ayrıca şunları içerir: Dovecot, SpamAssassin, Greylist, ClamAV, SOGo Roundcube, NetData ve NGINX.
Dovecot - IMAP/POP3 sunucusu.
Spamassassin bir spam filtreleme aracıdır.
Gri liste, gri listeye giren bir anti-spam aracıdır.
ClamAV bir antivirüstür.
Roundcube ve SOGo web tabanlı e-posta istemcileridir.
NetData gerçek zamanlı bir sunucu izleme programıdır.
Nginx bir web sunucusudur.
İşletim sistemlerini destekler: CentOS 7, Debian 9, Ubuntu 16.04/18.04, FreeBSD 11/12 ve OpenBSD 6.4.
iRedMail'in, iRedAdmin'in posta derlemesinin kendi web arayüzünün işlevselliği açısından birbirinden farklı olan ücretli ve ücretsiz sürümleri vardır. Ücretsiz sürümde yalnızca etki alanları, kullanıcı ve yönetici posta kutuları oluşturabilirsiniz. Bir takma ad oluşturmanız gerekiyorsa bunu ücretsiz sürümde iRedAdmin aracılığıyla yapamazsınız. Neyse ki PostfixAdmin adında bunu yapmanıza olanak tanıyan ücretsiz bir çözüm var. PostfixAdmin, iRedMail ile kolayca bütünleşir ve onunla harika çalışır.
KurulumKurulum için yukarıda listelenen işletim sistemlerinden birine ihtiyacımız var. Ubuntu Sunucusu 18.04 kullanacağım. Ayrıca satın alınmış bir alan adınızın ve yapılandırılmış bir DNS bölgenizin olması gerekir. Alan adı kayıt kuruluşunuzun DNS sunucusunu kullanıyorsanız, alan adı bölgesi yönetimi bölümünde iki kayıt yapmanız gerekir: A ve MX. Alan adı kayıt kuruluşunuzun kişisel hesabında yetkilendirmeyi ayarlayarak kendi DNS'nizi de kullanabilirsiniz.
DNS kayıt şirketi kullanırken etki alanı bölgesi ayarlama
Not! DNS ayarları birkaç saatten bir haftaya kadar geçerli olur. Ayarlar geçerli olana kadar posta sunucusu düzgün çalışmayacaktır.
Yüklemek için güncel sürümü iRedMail web sitesinden indirin. Şu anda 0.9.9.
# wget https://bitbucket.org/zhb/iredmail/downloads/iRedMail-0.9.9.tar.bz2
Daha sonra indirilen arşivi açın.
# tar xjf iRedMail-0.9.9.tar.bz2
Arşivi açma
Ve oluşturulan klasöre gidin.
# cd iRedMail-0.9.9
iRedMail yükleyicisinin bulunduğu klasör
Bir klasörün içeriğini kontrol etme
Klasör içeriği
Ve iRedMail kurulum komut dosyasını çalıştırın.
# bash iRedMail.sh
Mail sisteminin kurulumu başlayacaktır. Kurulum işlemi sırasında bir takım soruları yanıtlamanız gerekecektir. Kuruluma başlamayı kabul ediyoruz.
Kurulum başlangıcı
Bir kurulum dizini seçme
Şimdi bir web sunucusu seçmeniz gerekiyor. Seçim pek iyi değil, bu yüzden NGINX'i seçiyoruz.
Bir web sunucusu seçme
Artık kurulacak ve posta sistemiyle çalışacak şekilde yapılandırılacak veritabanı sunucusunu seçmeniz gerekiyor. MariaDB'yi seçin.
Bir veritabanı sunucusu seçme
Veritabanının kök parolasını ayarlayın.
Veritabanı kök parolası oluşturma
Şimdi mail alanımızı belirliyoruz.
Posta alanı oluşturma
Daha sonra [email protected] yönetici posta kutusu için bir şifre oluşturuyoruz.
Posta yöneticisi şifresi oluşturun
Web Bileşenlerini Seçme
Belirtilen ayarları onaylıyoruz.
Ayarların onaylanması
Kurulum başladı.
Kurulum
Kurulumun sonunda SSH için iptables kuralının oluşturulduğunu onaylıyor ve güvenlik duvarını yeniden başlatıyoruz. iRedMail iptables ile çalışır. Ubuntu en yaygın olarak UFW güvenlik duvarı yönetim yardımcı programını kullanır. Herhangi bir nedenden dolayı UFW (apt install ufw ) yüklemeniz ve UFW'nin (örnek: ufw Allow "Nginx Full" veya ufw Allow Postfix ) posta sunucusunu engellememesi için kurallar eklemeniz gerekiyorsa. Şu komutu çalıştırarak mevcut kuralların listesini görüntüleyebilirsiniz: ufw app list . Ardından UFW'yi etkinleştirin: ufw etkinleştirme.
Bir iptables kuralı oluşturun
Güvenlik duvarı yeniden başlat
Bu, iRedMail kurulumunu tamamlar. Sistem bize web arayüzü adreslerini ve giriş bilgilerini verdi. Posta sisteminin tüm bileşenlerini etkinleştirmek için sunucuyu yeniden başlatmanız gerekir.
Kurulum sonu
Yeniden başlatıyoruz.
# yeniden başlat
Öncelikle her şeyin çalıştığından emin olmanız gerekir. https://domain/iredadmin adresindeki iReadAdmin kontrol paneline gitmeye çalışıyoruz. Giriş [email protected], kurulum sırasında oluşturulan şifre. Rusça bir arayüz var.
Gördüğünüz gibi her şey çalışıyor. iRedAdmin'de oturum açarken büyük olasılıkla sertifikayla ilgili bir güvenlik hatası aldınız. Bunun nedeni, iRedMail'in, tarayıcının yemin ettiği kendinden imzalı bir sertifikaya sahip olmasıdır. Bu sorunu çözmek için geçerli bir SSL sertifikası yüklemeniz gerekir. Eğer satın aldıysanız kurulumunu yapabilirsiniz. Örnekte Let's Encrypt'tan ücretsiz SSL kuracağım.
Let's Encrypt SSL Sertifikası KurulumuSertifikayı certbot yardımcı programını kullanarak yükleyeceğiz. Önce bir depo ekleyelim.
# add-apt-repository ppa:certbot/certbot
Daha sonra gerekli bileşenlerle birlikte certboot'un kendisini kuruyoruz.
# apt install python-certbot-nginx
Sertifika alıyoruz.
# certbot --nginx -d alan adı.ru
Komutu çalıştırdıktan sonra sistem sizden bir e-posta adresi girmenizi isteyecek, girin. Bundan sonra büyük olasılıkla sertifikanın oluşturulduğu sunucu bloğunu bulmanın mümkün olmadığına dair bir hata alacaksınız. Bu durumda herhangi bir sunucu bloğumuz olmadığından bu durum normaldir. Bizim için önemli olan sertifika almaktır.
Sertifika almak
Gördüğünüz gibi sertifika başarıyla alındı ve sistem bize sertifikaya ve anahtara giden yolları gösterdi. Onlar tam da ihtiyacımız olan şeyler. Genel olarak "/etc/letsencrypt/live/domain" klasöründe saklanacak 4 dosya aldık. Şimdi web sunucusuna sertifikamızdan bahsetmemiz, yani katıştırılmış sertifikayı yeni aldığımız sertifikayla değiştirmemiz gerekiyor. Bunu yapmak için yalnızca bir dosyayı düzenlememiz gerekiyor.
# nano /etc/nginx/templates/ssl.tmpl
Ve içindeki son iki satırı değiştirin.
SSL sertifikasını değiştirme
Dosyadaki yolları, sertifikayı aldığımızda sistemin bize söylediği yollarla değiştiriyoruz.
SSL Sertifikasını Değiştirme
Ve NGINX'i yeniden başlatın.
# hizmet nginx'i yeniden başlat
Şimdi tekrar iRedAdmin'e gitmeye çalışıyoruz.
SSL sertifikası doğrulaması
Artık sertifika hatası yok. Sertifika geçerlidir. Kilidin üzerine tıklayıp özelliklerini görebilirsiniz. Sertifikanın süresi dolduğunda, certboot'un onu otomatik olarak yenilemesi gerekir.
Şimdi Dovecot ve Postfix sertifikasından bahsedelim. Bunu yapmak için iki yapılandırma dosyasını düzenleyeceğiz. Yaparız:
# nano /etc/dovecot/dovecot.conf
Bir blok bulma:
#SSL: Genel ayarlar.
Ve orada kayıtlı olan sertifikayı kendi sertifikamızla değiştiriyoruz.
Dovecot için sertifika değişimi
Ayrıca "ssl_protocols" satırına da dikkat edin. Değeri "!SSLv3" olmalıdır, aksi takdirde Dovecot'u yeniden başlatırken "Uyarı: SSLv2 OpenSSL tarafından desteklenmiyor. Lütfen onu ssl_protocols'dan kaldırmayı düşünün" hatası alırsınız.
# nano /etc/postfix/main.cf
Bir blok bulma:
# SSL anahtarı, sertifika, CA
Ve içindeki yolları, sertifikamızın dosyalarının yollarına değiştiriyoruz.
Postfix için sertifika değişimi
Bu, sertifikanın kurulumunu tamamlar. Dovecot ve Postfix'i yeniden başlatmak gerekir, ancak sunucuyu yeniden başlatmak daha iyidir.
# hizmet güvercinliği yeniden başlatma
# yeniden başlat
PHPMyAdmin'in KurulumuBu öğe isteğe bağlıdır, ancak veritabanı deneyiminiz için onu tamamlayıp PHPMyAdmin'i yüklemenizi öneririm.
# apt phpmyadmin'i yükleyin
Yükleyici sizden PHPMyAdmin'i yapılandırmak için hangi web sunucusuyla çalışmanızı isteyecektir, çünkü NGINX bu listede yoktur, sadece SEKME tuşuna basın ve devam edin.
PHPMyAdmin'in Kurulumu
Kurulum tamamlandıktan sonra phpmyadmin'in çalışabilmesi için NGINX'in varsayılan olarak çalıştığı dizine sembolik bağlantı yapmanız gerekir.
# ln -s /usr/share/phpmyadmin /var/www/html
Ve https://domain/phpmyadmin/ adresine gitmeyi deneyin
PHPMyAdmin çalışıyor. Bağlantı bir sertifika ile korunmaktadır, hata yoktur. Devam etmek. Bir MySQL veritabanı yöneticisi (MariaDB) oluşturalım.
#mysql
Ve MariaDB yönetim konsoluna giriyoruz. Daha sonra komutları tek tek yürütüyoruz:
MariaDB > "şifre" İLE TANIMLANAN "admin"@"localhost" KULLANICISINI OLUŞTURUN;
MariaDB > *.* ÜZERİNDEKİ TÜM AYRICALIKLARI "admin"@"localhost" İÇİN HİBE SEÇENEĞİYLE VERİN;
MariaDB > FLUSH AYRICALIKLARI;
MySQL Kullanıcısı Oluşturma
Her şey yolunda, giriş yaptınız. PHPMyAdmin kullanıma hazır.
PostfixAdmin'in KurulumuPrensip olarak PostfixAdmin, PHPMyAdmin gibi yüklenemez. Posta sunucusu bu bileşenler olmadan gayet iyi çalışacaktır. Ancak bu durumda posta takma adları oluşturamazsınız. Buna ihtiyacınız yoksa bu bölümleri atlamaktan çekinmeyin. Hala takma adlara ihtiyacınız varsa iki seçeneğiniz vardır: iReaAdmin'in ücretli sürümünü satın almak veya PostfixAdmin'i yüklemek. Elbette bunu ek yazılım olmadan, takma adları veritabanına manuel olarak yazarak yapabilirsiniz, ancak bu her zaman uygun değildir ve herkes için uygun değildir. PostfixAdmin'i kullanmanızı öneririm, şimdi kurulumunu ve iRedMail ile entegrasyonunu ele alacağız. Kuruluma başlıyoruz:
# apt install postfixadmin
Programın sistem veritabanı için bir şifre kabul ediyoruz ve oluşturuyoruz.
PostfixAdmin'in Kurulumu
PostfixAdmin'in Kurulumu
PHPMyAdmin kurulumuna benzeterek bir sembolik bağlantı oluşturuyoruz.
# ln -s /usr/share/postfixadmin /var/www/html
Adına web sunucusu başlatılan kullanıcıyı dizinin sahibi yaparız. Bizim durumumuzda NGINX www-data kullanıcısı olarak çalıştırılıyor.
# chown -R www-data /usr/share/postfixadmin
Şimdi PostfixAdmin yapılandırma dosyasını düzenlememiz ve iRedAdmin'in kullandığı veritabanı hakkında bilgi eklememiz gerekiyor. Varsayılan olarak bu veritabanına vmail adı verilir. PHPMyAdmin'e giderseniz orada görebilirsiniz. Ve böylece PostfixAdmin'in veritabanında değişiklik yapabilmesi için bunu PostfixAdmin yapılandırmasında yazıyoruz.
# nano /etc/postfixadmin/config.inc.php
Satırları bulma:
$CONF["database_type"] = $dbtype;
$CONF["veritabanı_anasistemi"] = $dbsunucusu;
$CONF["veritabanı_kullanıcısı"] = $dbuser;
$CONF["veritabanı_şifresi"] = $dbpass;
$CONF["veritabanı_adı"] = $veritabanı adı;
Ve aklıma şunu getiriyorum:
$CONF["database_type"] = "mysqli"; # Veritabanı türü
$CONF["database_host"] = "localhost"; # Veritabanı sunucusu ana bilgisayarı
$CONF["database_user"] = "yönetici"; # Vmail veritabanına yazma erişimiyle giriş yapın. Daha önce oluşturulan yöneticiyi kullanabilirsiniz
$CONF["database_password"] = "şifre"; # Yukarıda belirtilen kullanıcının şifresi
$CONF["veritabanı_adı"] = "vmail"; # iRedMail veritabanı adı
Veritabanı bilgilerini girme
SOGo web posta istemcisini kullanmayı planlıyorsanız yapılması gereken ek bir adım daha vardır; bu da $CONF["encrypt"] içindeki PostfixAdmin şifrelemesini "md5crypt" yerine "dovecot:SHA512-CRYPT" olarak değiştirmektir. Bunu yapmazsanız PostfixAdmin'de oluşturulan bir kullanıcı tarafından SOGo'da yetkilendirmeye çalıştığınızda yanlış kullanıcı adı veya şifreyle ilgili bir hata alırsınız.
Şifreleme Türünü Değiştirme
Artık kurulumu başarıyla tamamlamak ve hata almamak için veritabanını sorgulamanız gerekiyor. Bunu PHPMyAdmin aracılığıyla yapmak uygundur. Vmail veritabanını seçin ve SQL sekmesine gidin. Pencereye şunu girin:
Posta kutusunda DROP INDEX alanı;
Takma adla DROP INDEX alanı;
ALTER TABLE takma adı ADD COLUMN `goto' metni NULL DEĞİL;
Veritabanı sorgusu
Ve "İleri"ye basın. Artık hepimiz hazırız, PostfixAdmin web arayüzüne gidip kurulumu tamamlayabilirsiniz. Bunu yapmak için tarayıcıya şunu yazın: https://domain/postfixadmin/setup.php .
Aşağıdakiler görünmelidir:
PostfixAdmin'in Kurulumu
Her şey talimatlara göre yapılırsa hiçbir hata olmamalıdır. Eğer hala öyleyseler, o zaman elenmeleri için ihanete uğrarlar, aksi takdirde sistem devam etmenize izin vermez. Kurulum şifresini ayarlayın ve "Şifre karması oluştur"a tıklayın. Sistem, $CONF["setup_password"] parametresine eklenmesi gereken şifrenin bir karmasını oluşturacaktır.
PostfixAdmin kurulumunu tamamlama
Yapılandırma dosyası ayarlarını değiştirme
Şimdi az önce oluşturduğumuz şifreyi girip PostfixAdmin yöneticisini oluşturuyoruz. iRedAdmin yönetim panelinde oturum açmada sorunlar olabileceğinden, postmaster oturum açma bilgilerine sahip bir yönetici oluşturmamak daha iyidir.
PostfixAdmin Yöneticisi Oluşturma
Her şey yönetici tarafından yaratılmıştır. Oturum açabilirsiniz.
Güvenlik açısından postfixadmin dizinindeki setup.php dosyasını yeniden adlandırmanın veya silmenin daha iyi olacağını lütfen unutmayın.
Şu adrese gidin: https://domain/postfixadmin/ ve yeni oluşturduğunuz kimlik bilgilerini girin. PostfixAdmin'de ve iRedAdmin'de Rusça dili mevcuttur. Yetkilendirme sırasında seçilebilir.
Bir kullanıcı posta kutusu oluşturmaya çalışıyoruz.
iRedAPD, iRedMail modüllerinin yönetiminden sorumludur. Çalışan modülleri içeren bir konfigürasyon dosyasına sahiptir. Belirli bir modüle ihtiyacınız yoksa, onu yapılandırma dosyasından kaldırabilirsiniz; modül çalışmayı durduracaktır. Yaparız:
# nano /opt/iredapd/settings.py
"Eklentiler" satırını buluyoruz ve ihtiyacınız olmayan bileşenleri ondan kaldırıyoruz. "Gri listeleme" bileşenini kaldıracağım. Elbette spam'e karşı oldukça etkili bir koruma sağlar, ancak gerekli harfler çoğu zaman ulaşmaz.
Gri liste (gri liste), gönderenin sunucusunun davranışının analizine dayanan otomatik bir spam koruma teknolojisidir. "Gri listeleme" etkinleştirildiğinde, sunucu ilk kez bilinmeyen bir adresten gelen mektubu kabul etmeyi reddederek geçici bir hata bildirir. Bu durumda gönderen sunucunun gönderimi daha sonra yeniden denemesi gerekir. Spam gönderenler genellikle bunu yapmazlar. Mektubun tekrar gönderilmesi durumunda 30 gün süreyle listeye eklenir ve posta ilk defadan itibaren gönderilmektedir. Bu modülü kullanın veya kendiniz karar vermeyin.
Posta modüllerini Etkinleştirme/Devre Dışı Bırakma
Değişiklik yaptıktan sonra iRedAPD'yi yeniden başlatmalısınız.
# hizmet iredapd yeniden başlat
Posta sunucusu testiBu, iRedMail posta sunucusu kurulumunu tamamlar. Son aşama olan teste geçebilirsiniz. İki posta kutusu oluşturalım. Birini iRedAdmin aracılığıyla, ikincisini PostfixAdmin aracılığıyla kontrol etmek ve bir posta kutusundan diğerine veya tam tersi bir mektup göndermek için. iRedAdmin'de [email protected] posta kutusunu oluşturun. PostfixAdmin'de - [email protected]
iRedAdmin'de kullanıcı oluşturma
PostfixAdmin'de kullanıcı oluşturma
Kullanıcıların oluşturulduğunu kontrol edin.
PostfixAdmin posta kutuları listesindeki "Kime" sütununa dikkat ederseniz iRedAdmin ve PostfixAdmin'de oluşturulan posta kutuları arasındaki farkı görebilirsiniz. iRedAdmin'de oluşturulan posta kutuları "Yalnızca ilet" olarak, PostfixAdmin'de oluşturulanlar ise "Posta Kutusu" olarak işaretlenir. İlk başta uzun süre bunun neden olduğunu ve aralarındaki farkın ne olduğunu anlayamadım ve sonunda bir şeyi fark ettim. iRedAdmin'deki kutular takma ad olmadan, PostfixAdmin'deki kutular ise kendi takma adı ile oluşturulur.
Ve eğer bu takma adlar silinirse, posta kutuları iRedAdmin'de oluşturulanlar gibi "Yalnızca ilet" olarak görüntülenecektir.
Takma adları kaldırma
Takma adlar kaldırıldı. PostfixAdmin'i kontrol edin.
Gördüğünüz gibi tüm kutular "Yalnızca ileri" haline geldi. Aynı şekilde iRedAdmin'de oluşturulan posta kutusunda kendinize bir takma ad oluşturursanız bu "Posta Kutusu" olacaktır. Prensip olarak bu, postanın performansını etkilemez. Tek sorun PostfixAdmin'de oluşturulan bir posta kutusunda takma ad oluşturamayacak olmanızdır. Bir takma ad oluşturmak yerine mevcut olanı düzenlemeniz gerekecektir. Takma adlardan bahsetmişken, Yeni sürüm iRedMail'in takma adları işleyen Postfix haritalarından birinde değişiklik yapması gerekiyor. Ve eğer bunu yapmazsanız, oluşturulan takma adlar çalışmayacaktır. Bunu yapmak için /etc/postfix/mysql/virtual_alias_maps.cf dosyasında aşağıdakileri düzeltmeniz gerekir:
Yaparız:
# nano /etc/postfix/mysql/virtual_alias_maps.cf
Ve düzeltiyoruz.
Takma adları ayarlama
Postfix'i yeniden başlatın:
# hizmet postfix'i yeniden başlatma
Bundan sonra her şey işe yaramalı.
O halde postaları kontrol etmeye başlayalım. Roundcube aracılığıyla kullanıcı1'in posta kutusuna, SOGo aracılığıyla kullanıcı2'nin posta kutusuna gideceğiz ve kullanıcı1'in posta kutusundan kullanıcı2'ye ve kullanıcıya bir mektup göndereceğiz.
Roundcube ile e-posta gönderme
SOGo'da e-posta alma
SOGo'ya e-posta gönderme
Roundcube'da e-posta alma
Her şey sorunsuz çalışıyor. Mektubun teslimi iki ila beş saniye sürer. Aynı şekilde, mektuplar Yandex ve mail.ru sunucularına mükemmel bir şekilde iletilir (işaretli).
Şimdi takma adları kontrol edelim. Bir kullanıcı3 posta kutusu oluşturalım ve kullanıcı1 posta kutusundan kullanıcı2 posta kutusuna bir takma ad yapalım. Ve kullanıcı3'ün posta kutusundan kullanıcı1'in posta kutusuna bir mektup gönderin. Bu durumda mektubun kullanıcı2'nin posta kutusuna gelmesi gerekecektir.
Takma ad oluştur
Kullanıcı3'ün posta kutusundan Kullanıcı1'in posta kutusuna e-posta gönderme
Kullanıcı2'nin posta kutusuna bir mektup alınması
Takma adların çalışmasıyla da her şey yolunda.
Posta sunucusunun çalışmasını yerel posta istemcisi aracılığıyla test edelim. Örneğin Mozilla Thunderbird'ü düşünün. İki kullanıcı daha oluşturalım: client1 ve client2 . Bir posta kutusunu IMAP üzerinden, diğerini POP3 aracılığıyla bağlayacağız ve bir posta kutusundan diğerine mektup göndereceğiz.
IMAP aracılığıyla bağlanma
POP3 bağlantısı
Müşteri 1'den Müşteri 2'ye bir mektup gönderiyoruz.
Müşteri 1'den Gönderim
İstemci 2'de Alma
Ve ters sırada.
İstemci 2'den Gönderme
İstemci 1'de Alma
Her şey çalışıyor.
https://domain/netdata adresine giderseniz sistem durumu grafiklerini görebilirsiniz.
Bu, iRedMail posta sisteminin kurulumunu, yapılandırmasını ve test edilmesini tamamlar. Sonuç olarak, geçerli bir SSL sertifikasına sahip, tamamen ücretsiz, tam teşekküllü bir posta sunucusuna, iki farklı web tabanlı posta istemcisine, iki kontrol paneline ve ayrıca postaya yerleşik anti-spam ve anti-virüse sahip olduk. Dilerseniz web mail istemcileri yerine Microsoft Outlook veya Mozilla Thunderbird gibi yerel mail istemcilerini kullanabilirsiniz. Web posta istemcilerini kullanmayı planlamıyorsanız, sunucuyu aşırı yüklememek veya daha çok sevdiğiniz bir şeyi yüklemek için bunları hiç kuramazsınız. Kişisel olarak SOGo'yu daha çok seviyorum çünkü arayüzü mobil cihazlar için optimize edilmiş, bu da e-postaları akıllı telefondan görüntülemeyi çok kolaylaştırıyor. Aynı şey NetData ve iRedAdmin için de geçerlidir, kullanmayı planlamıyorsanız kurmamak daha iyidir. Bu posta sistemi kaynak açısından çok fazla talepkar değildir. Tüm bunlar 1024 MB RAM ve bir sanal işlemciye sahip bir VPS sunucusunda çalışır. Bu e-posta sistemi hakkında sorularınız varsa yorumlara yazın.
Not: Bu ürünün 1 GB RAM'e sahip çeşitli işletim sistemlerinde (Ubuntu, Debian, CentOS) test edilmesi sırasında ClamAV'ın çalışması için 1 GB'ın yeterli olmadığı ortaya çıktı. Neredeyse tüm durumlarda, 1 GB bellek kullanıldığında antivirüs bir veritabanı hatasına atıfta bulundu. Aynı zamanda, Debian ve Ubuntu işletim sistemlerinde antivirüs, sunucudan geçen postaları taramadı, aksi takdirde her şey yolunda gitti. CentOS'ta durum biraz farklıydı. Clad hizmeti sistemi tamamen kapattı ve böylece sunucunun normal çalışmasını imkansız hale getirdi. Web arayüzlerine giriş yapmaya çalışırken NGINX periyodik olarak 502 ve 504 hataları veriyordu. Posta da zaman içinde gönderildi. Aynı zamanda, 2 GB'a kadar RAM eklerseniz, her durumda antivirüsün ve bir bütün olarak sunucunun çalışmasında herhangi bir sorun yaşanmadı. ClamAV, posta sunucusundan geçen postaları taradı ve bunu günlüklere yazdı. Ekte virüs göndermeye çalışırken gönderim engellendi. Bellek tüketimi yaklaşık 1,2 - 1,7 GB idi.
NGINX yalnızca bir web sunucusu veya http-proxy olarak değil, aynı zamanda SMTP, IMAP, POP3 protokolleri aracılığıyla postaların proxylenmesi için de kullanılabilir. Bu şunları kuracaktır:
- Ölçeklenebilir bir posta sistemi için tek bir giriş noktası.
- Tüm posta sunucuları arasında yük dengeleme.
Bu makale bir Linux işletim sistemine kurulur. Gibi posta hizmetiİsteklerin gönderildiği , postfix, exim, dovecot, exchange, iredmail montajı ve daha fazlasını kullanabilirsiniz.
Çalışma prensibiNGINX istekleri kabul eder ve web sunucusunda kimlik doğrulaması yapar. Kullanıcı adı ve şifre doğrulamasının sonucuna bağlı olarak proxy, birkaç başlık içeren bir yanıt döndürecektir.
Başarı durumunda:
Böylece kimlik doğrulamaya dayalı olarak posta sunucusunun sunucusunu ve portunu belirliyoruz. Bu, uygun programlama dilleri bilgisine sahip birçok fırsat sunar.
Arıza durumunda:
Kimlik doğrulama sonucuna ve başlığa bağlı olarak istemci, ihtiyacımız olan posta sunucusuna yönlendirilir.
Sunucu hazırlığıSunucu güvenlik ayarlarında bazı değişiklikler yapalım.
SELinuxCentOS kullanıyorsanız veya Ubuntu'da bu güvenlik sistemini kullanıyorsanız SELinux'u devre dışı bırakın:
vi /etc/selinux/config
SELINUX=devre dışı
Güvenlik duvarıFirewalld kullanılıyorsa (CentOS'ta varsayılan):
güvenlik duvarı-cmd --kalıcı --add-port=25/tcp --add-port=110/tcp --add-port=143/tcp
güvenlik duvarı-cmd --yeniden yükle
İptables kullanılıyorsa (Ubuntu'da varsayılan):
iptables -A GİRİŞ -p tcp --dport 25 -j KABUL
iptables -A GİRİŞ -p tcp --dport 110 -j KABUL
iptables -A GİRİŞ -p tcp --dport 143 -j KABUL
apt-get install iptables-kalıcı
iptables-save > /etc/iptables/rules.v4
*bu örnekte SMTP (25), POP3 (110), IMAP (143)'e izin verdik.
NGINX'i yüklemeİşletim sistemine bağlı olarak NGINX'in kurulumu biraz farklıdır.
veya Linux Centos:
yum nginx'i yükle
veya Linux Ubuntu'yu:
nginx'i uygun şekilde yükleyin
Hizmetin otomatik olarak başlatılmasına izin veriyoruz ve başlatıyoruz:
systemctl nginx'i etkinleştir
systemctl nginx'i başlat
NGINX sistemde zaten yüklüyse hangi modüllerle çalıştığını kontrol edin:
Web sunucusunun oluşturulduğu seçeneklerin bir listesini alacağız; bunların arasında --with-mail'i görmeliyiz. Gerekli modül mevcut değilse nginx'i güncellemeniz gerekir
NGINX'i kurmaNginx yapılandırma dosyasını açın ve posta seçeneğini ekleyin:
vi /etc/nginx/nginx.conf
posta (
auth_http localhost:80/auth.php;
Sunucu(
25 dinle;
protokol smtp'si;
smtp_auth giriş düz cram-md5;
}
Sunucu(
110'u dinle;
protokol pop3;
}
Sunucu(
143'ü dinle;
protokol imap;
}
}
* Nerede:
- sunucu_adı, SMTP selamlamasında görüntülenecek posta sunucusunun adıdır.
- auth_http - Kimlik doğrulama isteğinde bulunacak web sunucusu ve URL.
- proxy_pass_error_message - Kimlik doğrulama başarısız olduğunda bir mesajın görüntülenmesini etkinleştirir veya devre dışı bırakır.
- Listen, isteklerin dinleneceği bağlantı noktasıdır.
- protokol - İlgili bağlantı noktasının dinlediği uygulama protokolü.
- smtp_auth - SMTP için kullanılabilir kimlik doğrulama yöntemleri.
- pop3_auth - POP3 için mevcut kimlik doğrulama yöntemleri.
http - sunucu bölümüne şunu ekleyin:
Sunucu(
dinle 80 default_server;
dinle [::]:80 default_server;
...
Konum ~ \.php$ (
$root_path /usr/share/nginx/html'yi ayarlayın;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $root_path$fastcgi_script_name;
fastcgi_params'ı dahil edin;
fastcgi_param DOCUMENT_ROOT $root_path;
}
...
Nginx sunucusunu yeniden başlatın:
systemctl nginx'i yeniden başlat
PHP'yi yükleme ve yapılandırmaPHP kullanarak kimlik doğrulama gerçekleştirmek için aşağıdaki paketlerin sistemde kurulu olması gerekir.
CentOS ise:
yum php php-fpm'yi yükleyin
Ubuntu ise:
apt-get install php php-fpm
PHP-FPM'yi başlatın:
systemctl php-fpm'yi etkinleştir
systemctl php-fpm'yi başlat
Kimlik doğrulamaKullanıcı adı ve şifre, yolu auth_http seçeneğiyle belirlenen bir komut dosyası tarafından kontrol edilir. Örneğimizde bu bir PHP betiğidir.
Giriş ve şifre doğrulama komut dosyası için resmi şablon örneği:
vi /usr/share/nginx/html/auth.php
* bu komut dosyası her türlü kullanıcı adını ve parolayı kabul eder ve istekleri 192.168.1.22 ve 192.168.1.33 sunucularına yönlendirir. Kimlik doğrulama algoritmasını ayarlamak için 61 - 64. satırları düzenliyoruz. 73 - 77. satırlar, yönlendirmenin devam ettiği sunuculara geri dönmekten sorumludur - bu örnekte, oturum açma işlemi "a", "c" karakterleriyle başlıyorsa, "f", "g" ise yönlendirme mailhost01 sunucusuna, aksi takdirde mailhost02'ye olacaktır. Sunucu adlarının IP adresleriyle eşleştirilmesi 31, 32 numaralı satırlarda ayarlanabilir, aksi takdirde çağrı alan adına göre yapılacaktır.
Posta sunucusu kurulumuNGINX proxy'si ile posta sunucusu arasındaki veri alışverişi açıktır. İstisnaya PLAIN mekanizması tarafından kimlik doğrulama olasılığını eklemek gerekir. Örneğin güvercinliği yapılandırmak için aşağıdakileri yapın:
vi /etc/dovecot/conf.d/10-auth.conf
Satır ekle:
uzak 192.168.1.11 (
disable_plaintext_auth = hayır
}
* bu örnekte 192.168.1.11 sunucusundan PLAIN kimlik doğrulama isteklerine izin verdik.
Ayrıca şunları da kontrol ediyoruz:
* eğer SSL zorunlu olarak ayarlanmışsa, kontrol çalışmayacaktır, çünkü bir yandan sunucunun isteklere açıkça izin verdiği, ancak SSL şifrelemesi gerektirdiği ortaya çıkmıştır.
Dovecot hizmetini yeniden başlatın:
systemctl güvercinliği yeniden başlat
İstemci kurulumuProxy ayarlarımızı kontrol etmeye devam edebilirsiniz. Bunu yapmak için istemci ayarlarında nginx sunucusunun adresini veya adını IMAP/POP2/SMTP olarak belirtin, örneğin:
* bu örnekte, posta istemcisi 143 (IMAP) ve 25 (SMTP) açık bağlantı noktalarından 192.168.1.11 sunucusuna bağlanacak şekilde yapılandırılmıştır.
ŞifrelemeŞimdi SSL bağlantısı kuralım. Nginx, mail_ssl_module modülüyle oluşturulmalıdır - şu komutla kontrol edin:
Gerekli modülün yokluğunda nginx'i yeniden oluşturuyoruz.
Yapılandırma dosyamızı düzenledikten sonra:
vi /etc/nginx/nginx.conf
posta (
sunucu_adı mail.domain.local;
auth_http localhost/auth.php;
proxy_pass_error_message açık;
SSL açık;
ssl_certificate /etc/ssl/nginx/public.crt;
ssl_certificate_key /etc/ssl/nginx/private.key;
ssl_ciphers YÜKSEK:!aNULL:!MD5;
ssl_session_cache paylaşılan:SSL:10m;
ssl_session_timeout 10 dk;
Sunucu(
110'u dinle;
protokol pop3;
pop3_auth düz apop cram-md5;
}
Sunucu(
143'ü dinle;
protokol imap;
}
Sebep: SELinux güvenlik sistemi tetiklendi.
Çözüm: SELinux'u devre dışı bırakın veya yapılandırın.
