OpenLDAP Schema for Postfix

If you configure postfix-dovecot with OpenLDAP, you will need specific LDAP's attributes. So I writed a schema.

postfix-new.schema:
  • 4 Attributes ( mailacceptinggeneralid, maildrop, mailEnabled, mailQuota )
  • 1 ObjectClass ( postfixUser )

Libvirt ve OpenvSwitch

Bu yazimda libvirt ile openvswitch entegrasyonu hakkinda giris seviyesinde adim atacagiz. Kurulum ve entegrasyona gecmeden once bu iki yazilim nedir, ne degildir onlari taniyalim.

Libvirt [1] , Redhat tarafindan 2005'ten bu yana gelistirilmeye devam eden sanallastirma ortamlari icin daemon, API ve yonetim aracidir.

/images/libvirt_hypervisors.png

Libvirt bilinen bir cok hypervisor'u desteklemektedir. Iste bunlardan bazilari:

  • KVM
  • LXC
  • OpenVZ
  • Xen
  • User-mode Linux (UML)
  • Virtualbox
  • VMware ESX
  • VMware Workstation
  • Hyper-V
  • PowerVM
  • Parallels Workstation
  • Bhyve

OpenvSwitch [2] , kisaca sanal multilayer network switchtir. OpenvSwitch, bir SDN switch olarak hypervisor uzerindeki sanal makineleri fiziksel olarak ayri bulunan network switchler ile entegre calisarak yonetebilir.

/images/Distributed_Open_vSwitch_instance.png

Birden fazla protokolu desteklemektedir:

  • NetFlow
  • sFlow
  • SPAN
  • RSPAN
  • CLI
  • LACP
  • 802.1ag

Kurulum:

Paket yoneticiniz ile libvirt ve openvswitch kurulumunu yapalim. Siz kendi dagitiminiza ve paket yoneticinize gore kurulumu yapabilirsiniz. Gentoo uzerinde, libvirt icin gerekli "USE FLAG"lari aktif edip kurulumunu yapalim.Binary dagitimlar icin buna gerek yoktur. Siz direk paket yoneticiniz ile kurulumu yapin.

/etc/portage/package.use/libvirt:

app-emulation/libvirt macvtap vepa qemu virt-network

Simdi kurulumu yapabiliriz.

# emerge -av libvirt

OpenvSwitch kurulumunu yapalim.

# emerge -av openvswitch

Sistem baslangici icin bu servisleri enable edelim.

# rc-update add ovsdb-server default
# rc-update add ovs-vswitchd default
# rc-update add libvirtd default
# rc-update add libvirt-guests default

Note

openvswitch ve kvm kernel modullerinin yuklendiginden emin olunuz. Kernel uzerinde aktif etmek icin openvswitch , qemu.

Sistem acilisinda bu modullerin yuklenmesi icin

/etc/conf.d/modules:

modules_4="openvswitch kvm kvm_intel tun"

Servisleri baslatalim.

# /etc/init.d/ovsdb-server start
# /etc/init.d/ovs-vswitchd start
# /etc/init.d/libvirtd start
# /etc/init.d/libvirt-guests start
[1] https://libvirt.org/
[2] http://openvswitch.org

Ansible Gentoo-Portage Update

Ansible Portage module [1] ile Gentoo Linux sisteminizi guncelleyebilir ve upgrade edebilirsiniz. Asagidaki ornekte Ilk once buildfarm adini verdigimiz sunucu uzerinde compile edilip diger gentoo sunucularimiza binary paketleri elde edip guncellemelerini yapmaktadir.

Yukarda bahsettigim sekilde bir buildfarm sunucusu yani paketlerin compile edilecegi sunucuda binary paketleri uretip diger sunuculara bu binary paketleri sunmak icin portage uzerinde "buildpkg" ozelligini aktif etmek gerekmektedir.

/etc/portage/make.conf:

FEATURES="buildpkg"

Diger Gentoo sunucularin buildfarm uzerindeki paketleri alabilmesi icin yayinlamasi gerekli. Bunun birden fazla sekilde kendinize cozum saglayabilirsiniz. FTP, FTPS, NFS, SSH, HTTP, HTTPS gibi. Biz kucuk bir web sunucusu kurup paketleri bu sekilde yayinlayalim.

# emerge -av www-servers/lighttpd

lighttpd web sunucusunu kurduktan sonra olusturulan paketlerin buradan yayinlanmasini konfigure edelim."/etc/lighttpd/lighttpd.conf" dosyasinin sonuna asagidaki iki satiri ekleyin.

/etc/lighttpd/lighttpd.conf:

server.modules += ( "mod_alias" )
alias.url = ( "/packages" => "/usr/portage/packages/" )

Artik web sunucumuzu baslatabiliriz.

# rc-update add lighttpd default
# /etc/init.d/lighttpd start

Buildfarm sunucumuz ile ayarlarimiz bu kadar. Artik diger sunucularimizi buildfarm sunucusu uzerinden binary paketleri almasi icin konfigure edebiliriz.

/etc/portage/make.conf:

FEATURES="getbinpkg"
PORTAGE_BINHOST="http://buildfarm.hostname/packages"

Artik ansible ile sistemizi ilk once buildfarm ile derlenip binary paketler ile diger sunucularinizi guncelleyebilirsiniz.

[1] http://docs.ansible.com/ansible/latest/portage_module.html

Ansible SSH Keys Deployment

Ansible authorized_key modulu 'delegate_to' ile sunuculara sshkey'leri deploy ederken bazi sshkey'lerin eklenmedigini gorebilirsiniz. Boyle bir sorun ile karsilasmamak icin asagidaki gibi bu module ihtiyac olmadan sshkey'leri ekleyebilirsiniz.

Nginx Reverse Proxy Cache

/images/nginx_logo.png

Bir websitesinin olmazsa olmaz unsurlardan biri performansli sekilde calismasidir. Performans ise birden fazla etkene bagli olabilir. Bu etkenler yazilan kodun kalitesinden tutun da websitenin yayinlandigi altyapiya kadar bagli olabilir. Fakat son kullanici sizin mukemmel kod kalitenize ya da sarsilmaz altyapiniza bakmaksizin kendine onune gelen performansdan memnun kalacaktir. Ayni zamanda dunyanin en iyi kodlarina yazarak cok iyi bir altyapi ile websitenizi yayina surseniz dahi kullaniciya giden iletisim surecleri belirlidir.

Bu yazida daha iyi bir performans ve hizli bir websitesi icin nginx uzerinde "content cache" hakkinda biraz bilgi vermeye calisacam. "Content Cache" kullanici ile proxy cache sunucusu arasinda saglanir. Asagidaki topolojiden inceleyebiliriz:

/images/nginx_reverse_proxy.jpg

Yukarda topolojide goruldugu gibi 'Client I' kullanicisi, reverse proxy sunucusu arkasindaki origin sunuculara ulasmaksizin website uzerindeki iceriklere reverse proxy uzerinden ulasir. Origin sunuculardan hic bir icerik istenmez.

Konfigurasyon:

Content cache islemi nginx uzerinde basit olarak "proxy_cache_path" ve "proxy_cache" konfigurasyonlari ile ayarlanabilir. Ilk olarak "/etc/nginx/nginx.conf" dosyasi icinde "http{}" arasina "proxy_cache_path" konfigurasyonunu girelim.

proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=cache:10m max_size=1g inactive=60m use_temp_path=off;

Yazdigimiz konfigurasyonu inceleyelim:

/var/cache/nginx
cache icin kullanilacak dizin. Eger bu dizin olusturulmamissa olusturun ve nginx kullanicisina yazma hakkini verdiginize emin olun.
# mkdir -p /var/cache/nginx
# chown nginx:nginx /var/cache/nginx
levels=1:2
Nginx yukarda olusturdugumuz dizin altinda two-level directory ile cachelenen tum icerikleri tek bir dizin altinda degilde two-level dizin altinda tutmasini istiyoruz. Eger levels konfigurasyonunu yapmazsaniz nginx tum icerikleri tek bir dizin altinda toplayacak ve buyuk boyutlu cachelenen iceriklerde dosyaya erisim hizlari azalacaktir.
keys_zone=cache:10m
Burada nginx cache key'ler icin shared memory zone olusturuyor. Cachelenen icerigi diske erisimi saglamadan direk olusturulan bu zone uzerinde okumasini sagliyor. "10m" ise cachelenecek olan keys buyuklugunu ayarliyoruz. 1 MB zone 8000 keys, 10MB zone 80000 keys icerebilir. Kendi cachelenecek sisteminize gore bu buyuklugu ayarlayabilirsiniz.
max_size=1g
Cachelenecek maksimum buyuklugu ifade eder.
inactive=60m
Cachelenmis bir icerige herhangi bir erisim olmuyorsa ne kadar sure sonra inactive olmasini ayarlar.
use_temp_path=off
Nginx yukarda bahsettigimiz '/var/cache/nginx' dizinine yazmadan once gecici olarak bir dizine yazmasini ya da ikinci bir dizine yazmayi kapatmayi ayarlar. Onerilen ikinci bir yazma olmamasi icin bu ayari her zaman "off" olarak ayarlamaniz.

"proxy_cache_path" ile ilgili kismimiz bu kadar. Artik herhangi bir upstream sitemiz ile ilgili ayarlamalarimizi yapalim. Asagidaki konfigurasyonlari tekil dosya kullaniyorsaniz "/etc/nginx/nginx.conf" dosyasi icinde, ayrisik konfigurasyon kullaniyorsaniz ornek olarak "/etc/nginx/conf.d/upstream01.conf" icinde "location / {}" arasinda ayarlamaniz gerekmektedir.

Ornek olarak:

location / {
     proxy_cache cache;
     proxy_cache_valid  200 302  60m;
     proxy_cache_valid  404      1m;
     proxy_cache_revalidate on;
     proxy_cache_min_uses 3;
     proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
     proxy_cache_background_update on;
     proxy_cache_lock on;
     add_header X-Proxy-Cache $upstream_cache_status;
     proxy_ignore_headers Set-Cookie;
     proxy_pass http://upstream01;
}

Yukarda yazdigimiz konfigurasyona kisaca goz atalim.

proxy_cache cache;
proxy_cache_path konfigurasyonunda olusturdugumuz shared memory zone adini belirttik.
proxy_cache_valid 200 302 60m;
HTTP cevap kodu 200 ile 302 donen sayfalarin cache suresi 60 dakika olmasini belirttik.Kendi sisteminize gore konfigure edebilirsiniz.
proxy_cache_valid 404 1m;
404 cevabi donen sayfalarin cache surelerini 1 dakika olarak ayarladik. Kendi sisteminize gore konfigure edebilirsiniz.
proxy_cache_revalidate on;
Nginx, origin sunuculardan GET istegi gondererek icerekleri yeniler. Nginx 'If-Modified-Since' ve 'Last-Modified' cache control headerlari ekleyerek, cache kontrolunu yapar.Bir kullanici guncellenmis bir icerige istek yaparsa nginx sadece guncellenen icerigin cacheni yenileyerek performans ve band genisligininden tasarruf saglar.
proxy_cache_min_uses 3;
Nginx, bir icerigin cachelenmesi icin minimum istek sayisini belirtemeniz halinde icerigi cacheleyecektir. Default olarak 1 olan istegi ben 3 yaptim. Kendi isteginize ve sisteminize gore konfigure edebilirsiniz.
proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
Eger origin sunuculari down olursa ya da hata verirse cachelenmis icerigi kullanicilari sunar.
proxy_cache_background_update on;
Yukardaki 'stale' konfigurayonunda belirttigimiz hata aninda cachelenmis icerigi yayinlamasi icin iceriklerin backgrounddan guncellenmesi direktifini verir.
proxy_cache_lock on;
Eger birden fazla kullanici ayni anda cachelenmemis bir icerige istek yollarsa sadece bir tanesinin istegi origin servera gonderilerek cachelenmesi saglanir.Diger istek ya da istekler icerik cachelenme islemi bitine kadar bekletilir.
add_header X-Proxy-Cache $upstream_cache_status;
HTTP header'i icine 'X-Proxy-Cache' headerini ekler. Bu basligi eklemek daha sonra proxy cache isleminin calisip calismadigini kontrol etmek icin kullanabilirsiniz.
proxy_ignore_headers Set-Cookie;
'Set-Cookie' headerinin cachelenmemesini belirttik.

Test:

Yukardaki gibi konfigurasyonlari girip nginx web sunucunuzu reload/restart ettikten sonra Proxy Cache'in calisip calismadigini test edelim.

$ curl -I http://www.example.com
  HTTP/1.1 200 OK
  Server: nginx
  ...
  X-Proxy-Cache: HIT

'X-Proxy-Cache' headeri, gonderilen istedigin gecerli oldugunu ve cevabin cache'den gonderildigi gosteriyor.

Diger Cache status cevaplari:

MISS:
Gonderilen istedigin gecersiz oldugunu ve cache icinde istek gonderilen sayfanin olmadigini belirtir. Cevap origin sunucudan kullaniciya gonderilmistir.
BYPASS:
Gonderilen icerik direk olarak origin sunuculardan kullaniciya gonderilmistir.
EXPIRED:
Icerik cache uzerinde suresi dolmus ve origin sunucu uzerinden gonderilmis.
STALE:
Origin sunucular cevap vermedigini ve icerigin cache uzerinden verildigini belirtir.
UPDATING:
Icerigin stale durumda oldugunu ve bir onceki istek ile guncellemede oldugunu belirtir.
REVALIDATED:
Daha once yukarida(proxy_cache konfigurasyonu kisminda) acikladigim gibi revalidated isleminde oldugunu belirtir.

Sizde yapmis oldugunuz konfigurasyonu test ederek cache durumunuzu kontrol edebilirsiniz. Kolay gelsin :)