HAProxy backend sunucularına istemci ip adresini aktarma

Vekil sunucu (Proxy) ve/veya yük dengeleme (Load Balancing) servislerinin arkasında çalışan sistemler istemci ip adresi olarak bu servislerin ip adresini alırlar. Bu servislerin çoğu X-Forwarded-For ya da benzer bir ek başlık ile gerçek istemci adresini de sunuculara iletme desteği sunarlar.

HAProxy yük dengeleme servisinde de bu iş için yapılandırma dosyasına `option forwardfor` seçeneğinin eklenmesi gerekiyor. Bu seçenek ihtiyaca göre `defaults`, `frontend`, `listen` ya da `backend` bölümlerinden birinde tanımlanabiliyor. Yalnız bu seçenek ile ilgili çok önemli bir detay var.

Bu seçenek, HAProxy’nin çalışma yapısı gereği, geliştirme ya da test ortamında farkına varması güç bir soruna yol açıyor. Bir istemci HAProxy ile bağlantı kurduğunda bağlantının sadece ilk isteği analiz ediliyor, log’lanıyor ve işleniyor. Dolayısıyla X-Forwarded-For başlığı sadece ilk istekte ekleniyor, aynı bağlantıda gelen sonraki isteklerde sunuculara HAProxy ip adresi iletiliyor. Bu da yazılım tarafında istemci adresi olarak tutarsız değerler gelmesine neden oluyor. HAProxy loglarında da bu duruma dair bir kayıt oluşmadığından sorunun kaynağını tespit etmek zor olabiliyor.

Bu sorunun önüne geçmek ve tüm isteklerde bu başlığın eklenmesini sağlamak için ise yapılandırma dosyasına `option http-server-close` seçeneğinin eklenmesi gerekiyor. Bu seçenek de ihtiyaca göre `defaults`, `frontend`, `listen` ya da `backend` bölümlerinden birinde tanımlanabiliyor. Eğer `defaults` bölümünde tanımlandıysa ve iptal edilmek istenen bir bölüm varsa `no option httpclose` şeklinde iptal edilebiliyor. Bu seçenek istemciyle HAProxy arasındaki bağlantıyı açık tutarken, HAProxy ve sunucu arasındaki bağlantıyı kapatıyor ve tüm isteklerde başlığın doğru şekilde eklenmesini sağlıyor.

http-server-close seçeneği HAProxy’e 1.4 sürümünde eklendi. Daha eski bir sürüm kullanılıyorsa keepalive desteğini feda edip `option httpclose` seçeneğini kullanmak gerekiyor.

12 Nisan 2013

Posted In: backend, forwardfor, frontend, Gezegen, haproxy, http-server-close, httpclose, keepalived, load balancing, sistem yönetimi, x-forwarded-for

nginx ve php-fpm ile moodle2 kurulumu

PHP programcıları her geçen gün sistem yöneticilerine saç baş yolduracak acayip işler yapmaya devam ediyorlar.  En son karşılaştığım acayiplik Moodle‘dan geldi. (sürüm pek yeni değil ama kurulumunu yapmak nasip olmamıştı) Programcı arkadaşlar hangi akla hizmet yaptılarsa resim dosyalarını sunmak için kullandıkları image.php dosyasının parametlerini query_string‘ten almak yerine farklı bir yol seçmişler ve ortaya şu acayip adres çıkmış.

/theme/image.php/standard/core/1349561551/moodlelogo

php ile biten istekleri php-fpm’ye gönder şeklinde yazılmış mantıklı kurallar bu adres karşısında yetersiz kalıyor.  Location tanımına göre istek bir şekilde fpm’ye yönlendirilse bile parametrler doğru şekilde alınamadığından PHP tarafından Image was not found, sorry. hatası dönüyor.

Adres satırının içindeki dosya adını ve parametreleri ayrıştırıp php-fpm’ye göndermek için şu location tanımını kullanmak gerekiyor.

location ~ ^.+\.php {
fastcgi_split_path_info ^((?U).+\.php)(/?.+)$;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;

fastcgi_param  PATH_INFO          $fastcgi_path_info;
fastcgi_param  PATH_TRANSLATED    $document_root$fastcgi_script_name;

fastcgi_param  QUERY_STRING       $query_string;
fastcgi_param  REQUEST_METHOD     $request_method;
fastcgi_param  CONTENT_TYPE       $content_type;
fastcgi_param  CONTENT_LENGTH     $content_length;

fastcgi_param  SCRIPT_NAME        $fastcgi_script_name;
fastcgi_param  SCRIPT_FILENAME    $document_root$fastcgi_script_name;
fastcgi_param  REQUEST_URI        $request_uri;
fastcgi_param  DOCUMENT_URI       $document_uri;
fastcgi_param  DOCUMENT_ROOT      $document_root;
fastcgi_param  SERVER_PROTOCOL    $server_protocol;

fastcgi_param  GATEWAY_INTERFACE  CGI/1.1;
fastcgi_param  SERVER_SOFTWARE    nginx;

fastcgi_param  REMOTE_ADDR        $remote_addr;
fastcgi_param  REMOTE_PORT        $remote_port;
fastcgi_param  SERVER_ADDR        $server_addr;
fastcgi_param  SERVER_PORT        $server_port;
fastcgi_param  SERVER_NAME        $server_name;
}

7 Ekim 2012

Posted In: Gezegen, Kendime notlar, sistem yönetimi

Virtualenv içinde ‘import random’ hatası

Uzun süredir python uygulamalarının kurulumları için virtualenv kullanıyorum. Bugün bir güncelleme sırasında django uygulamasındaki kütüphanelerden gelen ekstra komutların kullanılamaz olduğunu farkettim. ./manage.py komutu herhangi bir hata vermeden sadece öntanımlı django komutlarını listeliyordu. ./manage.py runserver komutu ise aşağıdaki hatayı veriyordu.


Traceback (most recent call last):
File “./manage.py”, line 14, in
execute_manager(settings)


File “/usr/lib/python2.6/email/utils.py”, line 27, in
import random
File “/usr/lib/python2.6/random.py”, line 47, in
from os import urandom as _urandom
ImportError: cannot import name urandom

StackOverflow sayesinde bu ubuntu hata kaydını buldum. Sebebine dair bir bilgi olmasa da belirtilen hata kullandığım Pardus makine ve Debian sunuculardaki aynı. Çözümü içinse virtualenv komutunu  sorunlu virtualenv dizinleri için çalıştırmak gerekiyor.

sandbox $ virtualenv /sandbox/env/

6 Ekim 2012

Posted In: Gezegen, Kendime notlar, sistem yönetimi

scp ile dosya transferinde boşluk içeren dosya adları

Konsoldan uygulamalara argüman olarak boşluk, bölü, parantez vb. özel karakterler içeren değerler vermek bazen beklenenden daha zor olabiliyor. Bazı durumlarda bu değerleri tırnak içine almak iş görse de kimi zaman kaçış karakteri (ters bölü karakteri “\”) veya karakterleri devreye girmek zorunda kalıyor.

scp ile dosya transferi de buna örnek durumlardan biri. Uygulamaya verdiğimiz argümanlar hem bizim sistemimizde hem de uzak sistemde yorumlandığı için kaçış karakteri mevzusunda normalden iki adım öteye gitmek gerekiyor. Boşluk içeren dosya adları kullanırken dosya yolunu tırnak içine almalı ve boşluk vb. karakterler için “çift” kaçış karakteri kullanmalıyız.

scp user@10.0.0.1:”/home/user/Gutenberg\\ Project/The\\ White\\ Crystals\\ by\\ Howard\\ Roger\\ Garis.epub”

14 Ocak 2012

Posted In: bash, dosya transferi, Gezegen, ipucu, Kendime notlar, scp, sistem yönetimi, ssh

(Hala kullanılmakta olan) Silinen dosyaları kurtarma

Kullandığımız uygulamalar çalışırken okudukları/yazdıkları dosyaları (ya da uygulamaya göre dosyanın bir kısmını) bellekte tutarlar. Linux üzerinde birçok kez karşılaştığım bir güzellik olarak, siz kullanılan dosyayı sistemden silseniz bile uygulama bellekteki kopya ile çalışmaya devam eder. Bu duruma güzel bir örnek olarak çalışan bir uygulamayı sistemden silebilmeniz ve siz uygulamayı kapatana kadar uygulamanın sorunsuz çalışması gösterilebilir. (Tabi daha önce kullanılmamış ve sistemden silinmiş bir dosyaya ihtiyaç duymazsa.)

Bu özelliği yanlışlıkla sildiğimiz dosyaları kurtarmak için de kullanabiliriz. Örnek üzerinden gitmek gerekirse, firefox ile bir dosyayı upload etmekte olduğumuzu ve işlem bitmeden dosyayı yanlışlıkla sildiğimizi düşünelim.

Bu durumda dosyayı kurtarmak için önce firefox’un pid numarasını öğreniyoruz.

~$ pidof firefox
7945

Ardından firefox’un kullandığı dosyaların listesinden silinen dosyaları buluyoruz.

~$ lsof -p 7945 | grep deleted
firefox 7945 username    2w   REG        8,6   153447  1531906 /home/username/.xsession-errors (deleted)

Aradığımız dosyanın satırında dördüncü sütunda (FD sütununda) yazan değeri not ediyoruz. (Örnek satırdaki 2w değeri)

Son olarak elimizdeki iki bilgiyi kullanarak /proc dizini altında pid numarası ile oluşturulmuş dizin içindeki fd dizininden dosyamızı geri kopyalıyoruz. lsof çıktısındaki değer fd dizini içinde hangi dosyayı kopyalamamız gerektiğini gösteriyor. Aşağıdaki komutla dosyamızı sisteme geri kopyalıyoruz. Dosya adını orijinali ile aynı ya da farklı seçebilirsiniz.

~$ cp /proc/7945/fd/2 /home/username/kurtarilan_dosya

16 Kasım 2011

Posted In: Gezegen, sistem yönetimi

WP Twitter Auto Publish Powered By : XYZScripts.com