Locust, web uygulamaları üzerinde detaylı olarak stress test yapabilmeye olanak sağlayan açık kaynak kodlu çok güzel bir yazılım. Temel olarak yük testinin yapılacağı web uygulaması için hangi sayfalarda kaç kişinin gezeceğini, hangi sayfalardan hangi sayfalara geçileceği, toplam dolaşım süresinin ne olacağı vs. gibi detaylı senaryonuzu bir python scripti şeklinde tarif edip, locust’a bu senaryoyu simule etmesini söylüyorsunuz.

Aşağıdaki gibi güzel ve anlaşılır bir web arabirimi olan Locust aynı anda milyonlarca anlık ziyaretiçiyi belirlediğiniz eşik değerlerine göre web uygulamanıza dolduruyor ve arayüz üzerinden uygulamanızın kullanıcı isteklerine verdiği cevapların stabilitesini ölçüp sınırlarınızı tespit edebiliyorsunuz.

Yazinin devami icin tiklayin.

Daha önce, CentOS’lar için hızlıca qmail kurulumu yapmak üzere bir shell script yazmıştım;  ve buradan da yayınlamıştım. Ancak gel zaman git zaman RHEL’in 6 branch’ı çıktı ve  sistemde bazı yapısal değişiklikler olduğu için scripti eski hali ile CentOS 6.x sistemlerde kullanmak mümkün olmamaya başladı. Bu nedenle  6.x uyumlu yeni bir sürümünü  hazırlamam gerekti.

Lazım olursa aşağıdaki adresten indirebilirsiniz.

http://www.syslogs.org/qmail/scripts/qinstaller.cnt6x.tar.gz

Scripti çalıştırmadan önce mutlaka README dosyasını okumanızı tavsiye ederim. Arada sırada sorulduğu için ayrıca belirtmek isterim ki, script temel bileşenlerle (qmail-send ve qmail-smtpd) kurulumu yapıyor. Yani tam teşekküllü bir posta sunucusu kurmak için değil daha çok sadece mail gönderimi yapmak üzere ideal.

qmail default olarak ilgili RFC‘de belirtildiği üzere max 512 bytes’lık dns response paketlerini handle edebiliyor. Bu nedenle mx recordu için 512 byte’tan büyük cevap döndüren alan adlarına mail göndermek isterseniz “CNAME_lookup_failed_temporarily” hatası alırsınız ve durum deferral olduğu için mail kuyrukta bekletilir; queue lifetime sonunda da bounce eder.

Bu, pek rastlanır bir durum olmasa da qmail’in 512 byte’tan büyük cevap döndürülen dns query’lerini handle edebilmesi için http://www.ckdhr.com/ckd/qmail-103.patch adresinde yayınlanan patch’in sisteme geçilmesi gerekir. qmailtoaster gibi hazır sistemler kullanıyorsanız bu patch default olarak geçili geldiği için sorun yok ancak kendi kurulumlarınız için patch’i ihmal etmemekte yarar var.

Yazinin devami icin tiklayin.

Qmail sistemlerde rblsmtpd ile block list kontrolü yapmak spam mailleri engellemek adına tek başına bile olukça yeterli bir yöntem olsa da bazen false positive durumlar oluşabilmekte ve aslında spam gönderim yapmayan yerlerden gelen maillerin de engellenmesine neden olabilmektedir. Örnek olarak son zamanlarda Google App Engine kullanılarak gönderilen spam mailler nedeni ile google ipleri bazen spamcop, sorbs ya da spamhaus gibi major block listlerine girebiliyorlar ve bunun sonucu olarak da gmail’den gönderilen mailler rblsmtpd’ye takılarak reddedilebiliyor.

İşte bu gibi konuların önüne geçmek için bir whitelist oluşturup bu listeye örneğin google’a ait tüm ip adreslerini eklemek ve bu iplerden gelen smtp bağlantılarını rblsmtpd kontrolünden muaf tutmak yerinde bir tutumdur. Daha önce Rblsmtpd Yapılandırması isimli bir yazı yayınlamıştım; bu yazıda ise rblsmtpd için whitelist ve custom blacklist yapılandırma işlemlerinden bahsetmek istiyorum.

Yazinin devami icin tiklayin.

Bilindiği gibi qmail’de ip tabanlı relaying işleri tcpserver’ın access listi olan tcp.smtp isimli dosyada tanımlanıyor. Tcpserver ile ilgili dökümanlarda ip range için relay tanımlamalarında verilebilecek en küçük ip range, aşağıdaki gibi tüm bir c class’ı ifade ediliyor:

1.1.1.:allow,RELAYCLIENT=""

Ancak tüm bir class’a izin vermek yerine daha küçük bir range’i belirtmek isterseniz, tanımlamayı şu şekilde yapmanız gerekiyor:

1.1.1.1-10:allow,RELAYCLIENT=""

Bu şekilde 1.1.1.1 ile 1.1.1.10 arası relay için izinli oluyor.

qmail’in smtp bağlantılarında reverse dns lookup işlemi yapması, client’ın herhangi bir ptr kaydı olmaması (fail) durumunda bağlantının epey yavaş kurulmasına neden olur.  Özellikle qmail’i sadece on-behalf gönderiler için kullanıyorsanız, client’ın reverse kaydıının olup olmadığı aslında pek önemli olan bir şey değildir. Dolayısı ile bu özelliği disable etmek qmail üzerinden ekstra bir işi almak anlamına geldiğinden dolayı performans anlamında da katkı sağlar.

qmail sistemlerde, reverse dns kontrol işlemini devre dışı bırakmak için qmail-smtpd supervise betiği içerisinden çağırılan tcpserver’a -H parametresini de eklemek yeterlidir ve aşağıdaki şekilde yapılabilir:

Yazinin devami icin tiklayin.

qmail serverlarda giden tüm maillerin başka bir smtp sunucusu üzerinden iletilmesini istemeniz durumunda, maillerin yönlendirileceği smtp serverda relay izninizin olması gerekir.  Bu şekilde, qmail’inizin smtproutes dosyasına giden tüm mailleri ilgili smtp server’a yönlendirmek demek için “:ip-adresi” şeklinde bir ibare girebilir ve yönlendirme işlemini yapabilirsiniz.

Fakat sunucunuzun static ipsi yoksa ya da uzaktaki smtp sunucusu üzerinde herhangi bir tasarrufunuz bulunmuyorsa ip üzerinden relay izni tanımlatma şansınız olmayabilir. Böyle bir durumda, uzaktaki sunucuda tanımlı kullanıcı bilgileriniz ile kimlik doğrulaması yapmayı ve otomatik olarak relay izni almayı düşünebilirsiniz fakat qmail sunucular giden postalar için öntanımlı olarak smtp authentication desteği sağlamadığından, bu işlem için qmail’e bir yama geçmeniz gerekir.

Neyseki qmail-remote’a smtp auth desteği sağlamak için için qmail-smtproute-auth isimli güzel bir yama bulunuyor. Aşağıda yama ile ilgili detaylı bilgi ve qmail’e uygulanarak, yapılandırılması konusunda kurulum notları bulabilirsiniz.
Yazinin devami icin tiklayin.

Gönderdiğiniz maillerin gerçekten sizin tarafınızdan gönderildiğini ispat etmeye yönelik bir kimlik doğrulama metodu olan DKIM konusuna önceki bir yazımda değinmiş ve qmail sunucularda giden maillerin DKIM (DomainKeys Identified Mail) ile imzalanmasının nasıl sağlanabileceğini anlatmıştım. Özellikle toplu mail gönderileri yapıyorsanız maillerinize mutlaka uygulanması gereken DKIM bildiğiniz gibi Domainkeys denilen bir diğer kimlik doğrulama metodunun geliştirilmiş ve yaygın olarak kullanılan versiyonudur.

DKIM ile DomainKeys aynı şeyi amaçlayıp aynı teknolojiyi kullanıyor olsalar ve sadece DKIM kullanmak yeterli gibi görünse de gönderdiğiniz mailleri hem DKIM hem de Domainkeys ile imzalamak elbette daha iyi olacaktır. Zira bazı sistemlerde sadece DKIM doğrulaması yapılırken bazılarında sadece DomainKeys kullanılıyor olabilir. Bu nedenle her iki yöntemi kullanarak yapılan imzalama, iki yöntemden sadece birini kullanan alıcı sistemlerle de iyi geçinmek anlamına gelir. Yazının devamında, daha önceki yazıma ek olarak qmail sistemlerde giden maillerin DKIM’in yanı sıra DomainKeys kullanılarak da imzalanmasından bahsedeceğim.

Yazinin devami icin tiklayin.