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

python uygulamalarında hata ayıklama – pdb

Program yazarken ortaya çıkan hataların sebeplerini bulmak kodun büyüklüğü, karmaşıklığı ile orantılı olarak zorlaşıyor. Çok sayıda geliştiricinin üzerinde çalıştığı projelerde ya da sonradan dahil olunan projelerde hata takibi daha da zor oluyor.

Python hata durumunda (çoğu zaman) güzel çıktılar sunuyor olsa bile işin o noktaya nasıl geldiğini ve değişkenlerin, argümanların o andaki değerlerini koda müdahale ederek öğrenmek gerekiyor. Bunun için koda print satırları ekleyip değerleri ekrana bastırmak (printf debugging) en sık tercih edilen yöntemlerden. Fakat bu basit yöntem çoğu zaman yetersiz kalıyor.

Bu noktada da `pdb` modülü imdada yetişiyor. debugger’a geçmek istediğimiz noktaya aşağıdaki satırı ekleyerek breakpoint oluşturuyoruz.

import pdb; pdb.set_trace()

Breakpoint’e gelindiğinde debugger shell’e düşüyoruz. Debugger komutlarıyla uygulamanın ilerleyişine müdahale edebiliyor, yeni breakpointler tanımlayabiliyor ve uygulamayı yeniden başlatabiliyoruz. Debugger komutlarının yanısıra tüm python ifadelerini de kullanabiliyoruz.

Sosyal medya editi: Serdar Dalgıç twitter’dan “pdb’den daha iyi bir yöntem olarak ipdb :) github.com/gotcha/ipdb” dedi. Gerçekten de python shell yerine çok daha yetenekli ipython shell’ini kullanabilmek büyük bir avantaj. pdb yerine ipdb kullanmak gayet mantıklı görünüyor.

23 Ocak 2013

Posted In: debug, Gezegen, Kendime notlar, pdb, programlama, python

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

strace ile birden çok süreci eşzamanlı takip etmek

Yazılım tarafında ortaya çıkan hatalar konusunda loglar yetersiz kaldığında veya uygulama segfault verip bir hata mesajı bile basamaz olduğunda `strace` aklıma gelen ilk uygulama oluyor. `strace` kendisine argüman olarak gösterdiğimiz süreç tarafından kullanılan sistem çağrılarını ve sinyallerini gösteriyor.

Bir süreci doğrudan `strace` kullanarak başlatmamız mümkün. Bunun için uygulamayı başlatırken satırın en başına `strace` eklememiz yetiyor.

$ strace ls -l

Fakat özellikle arkaplanda çalışan servis uygulamaları için bu yol her zaman kullanılamıyor. O zaman da halihazırda çalışmakta olan uygulamanın süreç numarasını (pid-process id) `strace`e gösteriyoruz.

$ pidof sshd

783

$ strace -p 783

Tabi günümüz sistemlerinde servisler eşzamanlı birçok süreç halinde çalışıyor. Bu durumda bu süreçlerden sadece birini takip etmek hatayı yakalamak için piyango gibi birşey oluyor :) Neyse ki `strace`in birden çok süreç numarası kabul etme özelliği imdadımıza yetişiyor. İstersek “-p” parametresini birçok kez kullanabiliyoruz.

$ pidof apache2
2155 2154 2153 2152 2147 2042 2041 2040 2039 2038 2035 2034

$ strace -p 2155 -p 2154 -p 2153 -p 2152 -p 2147 -p 2042 -p 2041 -p 2040 -p 2039 -p 2038 -p 2035 -p 2034

Örnekte olduğu gibi `pidof` çıktısındaki numaraları parametrelere aktarmak biraz zahmetli olduğundan genelde şu kısayolu kullanıyoruz.

$ strace $(pidof apache2 |sed ‘s/\([0-9]*\)/\-p \1/g’)

14 Ocak 2012

Posted In: Diğer, Gezegen

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

Özgür Yerelleştirme Kataloğu – Lictionary.in

Çeşitli özgür yazılımların yerelleştirme çalışmalarına dahil olduğum günden beri yerelleştirme sözlüğü ihtiyacı hep dikkatimi çekiyordu. Bazı projeler için proje özelinde yapılmış çalışmalar olsa da (eski kde sözlüğü vb.) bunlar içerik olarak çok sınırlı kalıyor hem de özgür yazılımlar arası ortaklığı sağlayamıyordu. Bu da elimizdeki büyük bilgi birikiminden edinilebilecek gücü kaçırdığımızı hissettiriyordu.

Birkaç ay önce yine bir uygulama çevirisi yaparken bazı terimlerin yaygın olarak nasıl kullanıldığını araştırmamız gerekti. Google üzerinden çeşitli taklalar atarak sonuçlara ulaşabilsek de bir sürü çöp veri arasından ihtiyacımız olan satırları cımbızlamamız gerekiyordu. Bir noktada canımıza tak etti, araştırma ve cımbızlama işlerini bilgisayara yaptırmaya niyetlendik.

Kısa süreli bir araştırma ve planlama sonrası işe koyulduk. Süreç içerisinde altyapıyı esnek ve geniş tutarak tüm özgür yazılım projelerinden verilerin tutulabileceği, sadece Türkçe için değil, özgür yazılımların çevrildiği tüm dilleri içeren geniş çaplı bir sistem oluşturmaya karar verdik.

Ve bir süre sonra Lictionary.in projesinin ilk sürümü ortaya çıktı. İlk sürümle birlikte 121 farklı dilde 60 bin benzersiz dizgeye ait yaklaşık 2.5 milyon satır çeviriden oluşan veritabanımızı kullanıma sunduk. Elbette bunun özgür yazılımların potansiyelinin sadece küçük bir kısm olduğunu farkındayız. Bu yüzden veritabanımızı an be an büyütüp yeni dizgeler, çeviriler ve diller ile zenginleştirmeye devam ediyoruz.

İlk sürüm sonrası projemizi destekleyen çok güzel geri dönüşler aldık. Ayrıca projemizi henüz duyurmuşken bizi mutlu eden gönüllü istekleri gelmeye başladı. Bu isteklerin de yönlendirmesi ile uluslararasılaştırma çalışmalarına öncelik vererek sayfamızı adına yakışır şekilde 4 farklı dilde kullanılabilir hale getirdik.

Lictionary.in özgür yazılımlardan aldığı gücü özgür yazılımlar için “özgür” olarak sunuyor. Şu an hazırlanmakta olan Lictionary.in API sayesinde birçok noktada Lictionary.in ile karşılaşıyor, işimizi kolaylaştıracak özgür yazılımlar hazırlayabiliyor olacağız. Ayrıca terimlerin çevirileri konusunda projeler arası uyumu sağlamak için oluşturmakta olduğumuz tavsiye/tartışma platformunun da bu konularda yaşanan sorunlara bir çözüm yolu olabileceğini düşünüyoruz.

Tüm özgür yazılımlarda olduğu gibi Lictionary.in için de kullanıcılardan gelecek eleştiriler bizim velinimetimiz. Lütfen olumlu/olumsuz eleştirilerinizi bizimle paylaşmaktan çekinmeyin.

19 Kasım 2011

Posted In: çeviri veritabanı, Gezegen, Lictionary, Özgür yazılım, sözlük, TS Design, yerelleştirme, Yerelleştirme kataloğu

(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

Google page rank sorgulama

Bugün bir iş için pagerank betiğine işim düşünce farkettim ki Google, “seo’cularin” gözbebeği olan Pagerank değerinin sorgulama sayfasında değişikliğe giderek kullandığı adres formatını değiştirmiş. Hatta son birkaç gündür forumlar ve twitter üzerinde bu konu ile ilgili çok yoğun bir mesaj trafiği varmış.

Elimdeki perl ve python betiklerinin çalışmadığını görünce ve güncellemelerden de hayır gelmeyince betiği kendim güncelleyerek github hesabıma eklemeye karar verdim. Yeni URL ve shell kullanımı ile ilgili bir iki satır ekledikten sonra commit ettim. Betiğin son haline http://github.com/dirigeant/google-pagerank adresinden ulaşılabilir. Betiği kabukta, istediğiniz adresi argüman olarak vererek ya da uygulamanızdan, kütüphane olarak çağırarak kullanabilirsiniz.

Son olarak belirtmek isterim ki, bu betik örnek bir çalışma olarak dağıtılmakta olup, kullanımından doğabilecek her türlü sorundan kullanıcının kendisi mesuldür. :)

9 Ekim 2011

Posted In: betikler, Gezegen, github, Google page rank, python, scraping, script

Google Summer Of Code 2011

Google Summer Of Code

Google’ın yükseköğretim öğrencilerini özgür yazılımlarla buluşturan projesi Google Summer Of Code bu yıl da başladı.
Yaz tatilinde özgür yazılımlara katkı vermek bir yandan da para kazanmak isteyen öğrenciler için kaçırılmayacak bir fırsat.

Programa katılmak için başvuru yapan yüzlerce özgür yazılım projesinden kabul edilenlerin listesi 18 Mart itibari ile açıklandı. Projeler tarafından önerilen fikirler öğrencilere sunuldu ve öğrenciler proje fikirlerini inceledikten sonra 28 Mart’ta başvurular alınmaya başlayacak.

Son üç – dört yıldır her geçen yıl daha fazla sayıda Türk öğrenciyi GSOC’ta görüyoruz. Sağolsun Necdet hoca Google’dan bile önce katılan arkadaşları listeliyor. Fakat bu yıl Türkiye’deki öğrencilerin önünde bir de sansür engeli var. GSOC hakkında tüm işlemleri gerçekleştirileceği Google Melange sitesi sansür engeline takıldığı için açılmıyor.

Başvuru yapmayı düşünen öğrenci arkadaşların en azından katılımcı organizasyonların linklerini ve “Ideas” sayfalarının bağlantılarını görebilmesi için ilgili sayfayı yansıladım. http://www.tsdesign.info/gsoc2011.html adresinden bu bilgilere ulaşmak mümkün. Umarım başvurular başlayana kadar sayfa üzerindeki sansür perdesi kalkar da başvuru sırasında da türlü taklalar atmak zorunda kalınmaz.

19 Mart 2011

Posted In: Diğer, Gezegen, google summer of code, gsoc, sansür, yansı

WP Twitter Auto Publish Powered By : XYZScripts.com