Skip to content

HAProxy backend sunucularına istemci ip adresini aktarma

12-Apr-13

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.

python uygulamalarında hata ayıklama – pdb

23-Jan-13

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.

nginx ve php-fpm ile moodle2 kurulumu

07-Oct-12

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;
}

Virtualenv içinde ‘import random’ hatası

06-Oct-12

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/

MySQL sunucuda replikasyonu tamamen iptal etme

22-Jan-12

Son zamanlarda kurduğum neredeyse tüm MySQL sunucularda en az 1 slave makine ile replikasyon yapısını da oluşturuyorum. Bazen veri okuma isteklerine yanıt verecek ikinci bir sunucu olması için, bazen de yedekleri sistemde kesintiye yol açmadan alabilmek için replikasyona başvuruyoruz.

Temelde pek karışık olmayan replikasyon yapılandırması detaylarda sıkıntı çıkarabiliyor. Özellikle MySQL ayar dosyasından verilen parametrelerle iş yapmak mümkün gibi görünmesine rağmen MySQL’in buradaki değerleri sadece ilk yazıldığında dikkate alıyor olması bunu bilmeyen birini çıldırtabiliyor.

MySQL, replikasyonla ilgili tüm verileri data dizini içinde `master.info` dosyasında tutuyor ve buradaki değerler MySQL ayar dosyasındaki değerlerden daha öncelikli. Dolayısı ile replikasyon ile ilgili ayarlamaları ayar dosyasından değil mysql komut satırından yapmak gerekiyor.

Bu durum replikasyonu iptal ederken de geçerli. Ayar dosyasından master sunucu bilgilerini silsek de replikasyon aynen çalışmaya devam ediyor. Replikasyonu iptal etmek için yapmamız gerekenler şunlar;

STOP SLAVE; # Slave süreçleri durduruyoruz

RESET SLAVE; # Slave ayarlarını siliyoruz.

RESET SLAVE ALL; # MySQL 5.5.16 ve sonraki sürümler için bu komut kullanılmalı.

Varsa my.cnf dosyasından ilgili satırları siliyoruz.

Böylece replikasyondan ilelebet kurtulmuş oluyoruz. Eğer daha sonra yeniden etkinleştirmeyi düşünüyorsanız my.cnf içindeki satırları silmek yerine dosyaya “skip-slave-start” seçeneğini ekleyerek replikasyonun MySQL sunucu ile birlikte başlatılmasını engelleyebilirsiniz.

The Masters 2012 Başladı

16-Jan-12

Snooker dünyasının ilk 16 sırasındaki isimlerin karşılaştığı The Masters, iki çok güzel ve çekişmeli maçla başladı.

İlk maçta, Ding Junhui’nin dönüşü karşısında eskiden yaptığı gibi oyunu bırakmayan Ronnie O’Sullivan açılış maçını kazandı.

İkinci maçın tamamını -teknik sorunlardan ötürü- izleyememiş de olsam seans arasına gidilirken 4-0 geride kalan Maguire’ın geri dönüşünün oyuna kattığı heyecan ikinci maçı da keyifli bir hale getirmiş.

Turnuvanın gelecek maçlarını kaçırmak istemeyenler için aşağıda turnuva takvimi bağlantılarını paylaşıyorum. Maçları BBC ve Eurosport’tan izlemek mümkün.

XML: https://www.google.com/calendar/feeds/916f00o7tbsdtbj1hpq91p39ao%40group.calendar.google.com/public/basic

ICAL: https://www.google.com/calendar/ical/916f00o7tbsdtbj1hpq91p39ao%40group.calendar.google.com/public/basic.ics

HTML: https://www.google.com/calendar/embed?src=916f00o7tbsdtbj1hpq91p39ao%40group.calendar.google.com&ctz=Europe/London

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

14-Jan-12

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’)

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

13-Jan-12

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”

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

19-Nov-11

Ç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.

More…

(Hala kullanılmakta olan) Silinen dosyaları kurtarma

16-Nov-11

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