26 Haziran 2013 Çarşamba
Unix Man Sayfası Hazırlama Editörü: RManEdit 2.0.2
Ruby ve Gtk kullanarak kodladığım RManEdit 1.0.1 sürümünde tek sayfa açılabiliyordu. Şimdi 2.0.2 sürümünde ise çoklu sekme yapısı, bul değiştir, sihirbaz özellikleri ekledim. RManEdit diğer metin editörlerinin sahip olduğu bir çok özelliğe sahip. Projenin kurulum ve kullanım bilgilerine buradan ulaşabilirsiniz. Projeden bir kaç ekran görüntüsü:
24 Haziran 2013 Pazartesi
Ruby Kodlama Biçimi Önerisi
Bir çok dilde kodlama yapılırken uyulan kurallar var. Aslında bu kurallar bir zorunluluk değil, kodun anlaşılırlığını kolaylaştırmak, kod yazımında bir ortaklık sağlamak için üzerinde anlaşılmış tavsiyeler. Python için bu konuda PEP 8 ile belirlenmiş kuralların bir kısmı. PEP 8 belgesi hakkındaki Türkçe yazıyı da bir üst dönemden Ahmet Can burada yazmış. Oldukça da güzel olmuş yazı.
Ruby ile kodlamayı daha çok sevdiğimden ve genelde Ruby kullandığımdan, Ruby için kodlama standartları nasıl diye biraz araştırdım. Resmi bir belge bulamadım. Ancak Github'da bir kaç belge buldum bu konuda. Bunlardan en çok yıldız alan, en çok kullanılana uymak daha doğru diye düşündüm. Bu belge baktıklarım arasında en çok kullanılan anladığım kadarıyla. Bu yüzden bu belgenin Türkçesini de Github'da tutmaya karar verdim. Ancak bire bir çeviri yapmadım. Yazdığım belgeye buradan ulaşabilirsiniz.
Belgede yazan girintiler 2 boşluk olmalı, fonksiyon yazımları, while kullanımı gibi bir kaç konuda daha Ruby'ciler ile aynı görüşte olduğumu öğrenince pek mutlu oldum :) Mesela bana sorarsanız Python'daki 4 boşluk fazla ama herkes böyle 4 boşluk kullandığından 2'ye düşürmüyorum Python'da, ya da özellikle betik dillerinde çok fazla farklı for yapısı oluyor. Bu durum Ruby'de de böyle. O zaman benim için bu durum kafa karıştırıcı oluyor. Dizi, hash yapısı gibi yerlerde .shift, .each gibi yapılar kullanıyorum. Herhangi bir for yapısını ise while ile sağlıyordum. Bu çevirdiğim belgede de bu durum böyle önerilmiş :)
Bir de belgeyi okurken Ruby ve programlamada bilmediğim kavramları öğrendim. Duck-typing, factory method pattern gibi kavramları daha önceden duymamıştım açıkçası. Mesela Ruby'de "%" karakterinin dizge (string) yazımında bilmediğim özellikleri varmış, Ruby'de sembol kavramını da daha önce kullanmamıştım. Bu gibi bilmediğim kavramları öğrenmek de bana faydalı oldu.
15 Haziran 2013 Cumartesi
3. Sınıf Biter Sonrası Staj
Bu yıl 3. sınıfı bitirip artık 4 oldum. Biraz tuhaf bir yıl oldu benim için. Hem biraz hastaydım, biraz küsmüş derken yılı sonlandırdım. İlk dönem fazlasıyla rahatsızdım midemden. Zaten zayıf bir insan olarak hepten zayıfladım :) Ama gene de boş geçirmedim tabiki yılı. Tabi Necdet hoca boş geçirmemem için dürtükleyip duruyordu o ayrı :)
Bu dönem aslında hiç istediğim gibi çalışamadım. Okul sınavlarımı çok boşladım bu yıl, aslında pek boşlamazdım sene sonunda genelde iyi sonuçlar elde ederdim. Sanırım bu yıl sınavlara sallamadan nasıl oluyor bir deniyim mi istedim ne istedim ben de bilemedim :) İlk dönem olan derslerden Java vardı ama ben Java'yı sevmiyorum. Yazımı gereksiz uzun bence. C++ daha çok seviyorum açıkçası. Bir de 2. sınıftayken okuldaki derslere çok hevesli başlardım. Ancak okuldaki hocalarda aynı tepkiyi alamadım. O yüzden artık okuldaki derslerde pek heveslenmiyorum "vay be bunu öğreneceğim" şeklinde. Zaten 3. sınıf olduğumuz için aldığımız son programlama dersi olarak Java vardı. Bundan sonraki dersler hep işletim sisteminin çalışması, programlama dilleri ve kavramları, mikro işlemciler gibi dersler. 3'ün ilk döneminde veri tabanı dersi de aldık, ben bu yıl pek çalışmadığımdan onu pek verimli geçiremedim, açıkçası buna da üzüldüm biraz. Veri tabanı iyi öğrenmek isterdim. Aslında arka planda tamamen veri tabanı tasarımına dayanan uygulamalar yazmayı sevmem, ama sevmemem boşlamamı pek gerektirmezdi. Belirli bir seviyeye kadar varlıklar arasında ilişki kurmayı ben de yapıyorum tabi. Ama daha karmaşık şeyler üzerinde çalışmadım.
Bu dönem bana sorarsanız dersler bakımından ağır değildi. Konular 2. sınıfı geçirdikten sonra daha rahat anlaşılırdı benim için. Bir de okul dışında uygulama yapınca kavraması daha basit oluyor. Ezberleyip geçmekten farklı bir hal alıyor. 2. sınıftan daha fazla okul dışında işlere bakmak için vakit vardı bence. Ancak ben zaman yönetimini pek yapamadım.
Bu yıl Linux dağıtımlarına yönelik 2. sınıfa oranla oldukça şey öğrendim. Lpi 101 sınavına çalışmıştık bir grup olarak okulda, ona giren her arkadaşımla birlilkte başarıyla sonuçlandırdık Lpi 101 sınavını. 1. dönem fazla rahatsız olduğumdan ara tatilde RManEdit'i yaptık. Ve gene ilk dönem Gnome'un Outreach for Women etkinlğine katılarak projelere katkı vermeye başladım. Aslında katkı verdiğim uygulamayı da zor şartlar altında çalıştırıp yamayı göndermiştim. Benim makinemde problem olduğundan okuldan bir makine kullanmak zorunda kalıyordum. O zamanda sabahtan akşama kadar okulda durduğumdan dışarıda yemek yemek (yiyememek) midemi daha fena getiriyordu. Ara tatilde uzun bir süre ev yemekleri yediğimden midem biraz daha düzeldi. Derken 2. dönem ortasından sonra mide ilaçları kullanmadan devam edecek kadar iyileşebildim :)
2. dönem RManEdit'in eksik yerlerinin bir kısmını tamamladım. Bir de Yakından Eğitim projesi olan Nagios Couchbase Plugin'e başvurdum. Nagios eklentisi projesini de başarı ile neticelendirebildim. Bir de gene Necdet hocanın Gnome projelerine katkı ver sıkıştırmaları nedeniyle jhbuildi kurmak ile olan yakından ilişkim bilgisayara her format attığımda yeniden başladı. Aslında bana sorarsanız projelere katkı vermek için en güzeli dağıtımların kararlı olmayan hallerini kullanmak. Gündelik ihtiyaçlar için iyi diyemem, ama katkı vermek için iyi. 2. dönem bir de Muğla'da ilk sunumumu yaptım. 4. sınıflardan Ahmet ve Serhat ile birlikte Özgür Yazılım projelerine nasıl katkı verilirden bahsetmiştik. Muğla'da yoldan, heyecandan, midem fena olursa yemek yiyemediğimden halsiz kalırım ve kötü olur diye korkmuştum aslında. Ancak öyle olmadı :)
Reflü kötü bir şey :( İlk zamanlar kötü aslında bir süre ilaç kullandıktan sonra midenizi pek zorlamazsanız çok sorun olmuyor.
Şimdi ise bu hafta çalışmam gereken bir sınavım kaldı. Sonrasında staja başlamadan önce okumam gerekli olan belgeler var. Stajımı sistem yönetimi üzerine yapacağım. Kaan ve İşbaran sistem yönetimi üzerine bir kaç şeyden bahsetti staj görüşmemde. Artık sistem yöneticilerinin sunucu bakımını tek tek elle yapmadığını, çalışan makine sayısının da sürekli değiştiğini, bunun için sistem yöneticilerinin sunucu yönetimi sağlayan betikler yazdğından bahsetti. Aslında sistem yöneticisi olmak istemiyorum ama sistem yöneticilerinin kullandıkları teknolojilere karşı merakım var :) Bu yüzden stajda bu tür şeyler öğrenmenin beni sıkacağını sanmıyorum.
Son olarak bu dönem de bittiği için artık ben de 4. sınıfım :)
Bu dönem aslında hiç istediğim gibi çalışamadım. Okul sınavlarımı çok boşladım bu yıl, aslında pek boşlamazdım sene sonunda genelde iyi sonuçlar elde ederdim. Sanırım bu yıl sınavlara sallamadan nasıl oluyor bir deniyim mi istedim ne istedim ben de bilemedim :) İlk dönem olan derslerden Java vardı ama ben Java'yı sevmiyorum. Yazımı gereksiz uzun bence. C++ daha çok seviyorum açıkçası. Bir de 2. sınıftayken okuldaki derslere çok hevesli başlardım. Ancak okuldaki hocalarda aynı tepkiyi alamadım. O yüzden artık okuldaki derslerde pek heveslenmiyorum "vay be bunu öğreneceğim" şeklinde. Zaten 3. sınıf olduğumuz için aldığımız son programlama dersi olarak Java vardı. Bundan sonraki dersler hep işletim sisteminin çalışması, programlama dilleri ve kavramları, mikro işlemciler gibi dersler. 3'ün ilk döneminde veri tabanı dersi de aldık, ben bu yıl pek çalışmadığımdan onu pek verimli geçiremedim, açıkçası buna da üzüldüm biraz. Veri tabanı iyi öğrenmek isterdim. Aslında arka planda tamamen veri tabanı tasarımına dayanan uygulamalar yazmayı sevmem, ama sevmemem boşlamamı pek gerektirmezdi. Belirli bir seviyeye kadar varlıklar arasında ilişki kurmayı ben de yapıyorum tabi. Ama daha karmaşık şeyler üzerinde çalışmadım.
Bu dönem bana sorarsanız dersler bakımından ağır değildi. Konular 2. sınıfı geçirdikten sonra daha rahat anlaşılırdı benim için. Bir de okul dışında uygulama yapınca kavraması daha basit oluyor. Ezberleyip geçmekten farklı bir hal alıyor. 2. sınıftan daha fazla okul dışında işlere bakmak için vakit vardı bence. Ancak ben zaman yönetimini pek yapamadım.
Bu yıl Linux dağıtımlarına yönelik 2. sınıfa oranla oldukça şey öğrendim. Lpi 101 sınavına çalışmıştık bir grup olarak okulda, ona giren her arkadaşımla birlilkte başarıyla sonuçlandırdık Lpi 101 sınavını. 1. dönem fazla rahatsız olduğumdan ara tatilde RManEdit'i yaptık. Ve gene ilk dönem Gnome'un Outreach for Women etkinlğine katılarak projelere katkı vermeye başladım. Aslında katkı verdiğim uygulamayı da zor şartlar altında çalıştırıp yamayı göndermiştim. Benim makinemde problem olduğundan okuldan bir makine kullanmak zorunda kalıyordum. O zamanda sabahtan akşama kadar okulda durduğumdan dışarıda yemek yemek (yiyememek) midemi daha fena getiriyordu. Ara tatilde uzun bir süre ev yemekleri yediğimden midem biraz daha düzeldi. Derken 2. dönem ortasından sonra mide ilaçları kullanmadan devam edecek kadar iyileşebildim :)
2. dönem RManEdit'in eksik yerlerinin bir kısmını tamamladım. Bir de Yakından Eğitim projesi olan Nagios Couchbase Plugin'e başvurdum. Nagios eklentisi projesini de başarı ile neticelendirebildim. Bir de gene Necdet hocanın Gnome projelerine katkı ver sıkıştırmaları nedeniyle jhbuildi kurmak ile olan yakından ilişkim bilgisayara her format attığımda yeniden başladı. Aslında bana sorarsanız projelere katkı vermek için en güzeli dağıtımların kararlı olmayan hallerini kullanmak. Gündelik ihtiyaçlar için iyi diyemem, ama katkı vermek için iyi. 2. dönem bir de Muğla'da ilk sunumumu yaptım. 4. sınıflardan Ahmet ve Serhat ile birlikte Özgür Yazılım projelerine nasıl katkı verilirden bahsetmiştik. Muğla'da yoldan, heyecandan, midem fena olursa yemek yiyemediğimden halsiz kalırım ve kötü olur diye korkmuştum aslında. Ancak öyle olmadı :)
Reflü kötü bir şey :( İlk zamanlar kötü aslında bir süre ilaç kullandıktan sonra midenizi pek zorlamazsanız çok sorun olmuyor.
Şimdi ise bu hafta çalışmam gereken bir sınavım kaldı. Sonrasında staja başlamadan önce okumam gerekli olan belgeler var. Stajımı sistem yönetimi üzerine yapacağım. Kaan ve İşbaran sistem yönetimi üzerine bir kaç şeyden bahsetti staj görüşmemde. Artık sistem yöneticilerinin sunucu bakımını tek tek elle yapmadığını, çalışan makine sayısının da sürekli değiştiğini, bunun için sistem yöneticilerinin sunucu yönetimi sağlayan betikler yazdğından bahsetti. Aslında sistem yöneticisi olmak istemiyorum ama sistem yöneticilerinin kullandıkları teknolojilere karşı merakım var :) Bu yüzden stajda bu tür şeyler öğrenmenin beni sıkacağını sanmıyorum.
Son olarak bu dönem de bittiği için artık ben de 4. sınıfım :)
6 Haziran 2013 Perşembe
Yakından Eğitim Projemde Son Durum
Üzerinde çalıştığım Yakından Eğitim projesi olan Couchbase'i Nagios üzerinden izlemek için yaptığım eklentide geçen haftadan bu yana eksiklerin büyük kısmını kapattım. Sınav haftam nedeniyle danışmanımdan izin almıştım. Zaten final dönemi sıkıştırdığından 10 gün daha proje bitirme süresi uzatıldı.
Eklentiyi ilk şuan master dalında bulunan haliyle yayınlamıştım. Ordaki hali sorguyu sadece düğüm (node) seviyesinde yapıyordu ve Couchbase üzerindeki daha az özelliği kontrol ediyordu. Bu hafta githubda yapmam gereken bulabildiğim özellikleri ekledim. Ayrıca Rest Api kullanarak sorguları küme (cluster) seviyesinde yapılmasını da sağladım. Deb ve Rpm paketleri için bir alt yapı hazırlayıp, proje Readme'sini oldukça genişlettim. Eklenti web arayüzünden kullanılabildiği çıktılar konsolda ekranada dökülebildiği için "--help" ile çalıştırıldığında parametrelerinin açıklamasının görülmesini sağladım ve bir de uygulama için man sayfası hazırladım. En son dün kodu PEP 8 ile uyumlu hale getirdim.
Aslında projenin devel dalındaki hali bile şuan alınıp kullanılabilir durumda. Hatta bu hafta master ve devel dallarındaki halini alıp deneye bir kaç arkadaş projeye yönelik geri bildirimde bulundu. Oldukça mutlu oldum bu duruma. Projeyi buradan alıp deneyebilirsiniz hata bildirimi, özellik ekleme gibi geri bildirimlerde bulunulursa da oldukça mutlu olurum :)
Eklentiyi ilk şuan master dalında bulunan haliyle yayınlamıştım. Ordaki hali sorguyu sadece düğüm (node) seviyesinde yapıyordu ve Couchbase üzerindeki daha az özelliği kontrol ediyordu. Bu hafta githubda yapmam gereken bulabildiğim özellikleri ekledim. Ayrıca Rest Api kullanarak sorguları küme (cluster) seviyesinde yapılmasını da sağladım. Deb ve Rpm paketleri için bir alt yapı hazırlayıp, proje Readme'sini oldukça genişlettim. Eklenti web arayüzünden kullanılabildiği çıktılar konsolda ekranada dökülebildiği için "--help" ile çalıştırıldığında parametrelerinin açıklamasının görülmesini sağladım ve bir de uygulama için man sayfası hazırladım. En son dün kodu PEP 8 ile uyumlu hale getirdim.
Aslında projenin devel dalındaki hali bile şuan alınıp kullanılabilir durumda. Hatta bu hafta master ve devel dallarındaki halini alıp deneye bir kaç arkadaş projeye yönelik geri bildirimde bulundu. Oldukça mutlu oldum bu duruma. Projeyi buradan alıp deneyebilirsiniz hata bildirimi, özellik ekleme gibi geri bildirimlerde bulunulursa da oldukça mutlu olurum :)
5 Haziran 2013 Çarşamba
Python Uygulamalarına Debian ve Rpm Paketi Yapmak
Yazdığımız uygulamaları paketlemek kullanım açısından oldukça kolaylık sağlar. Eğer yaptığımız projeyi Python kullanarak kodladıysak bir setup.py dosyası oluşturarak hem paket oluşturmak hem de paket oluşturmadan kullanmak için de bir kolaylık sağlamış oluruz. setup.py dosyasında hangi dosyanın sistemde hangi dizin altına kopyalanacağı, proje lisansı, geliştiricisi, web adresi gibi bilgileri tanımlarız. Sadece setup.py'yi kullanarak "sudo python setup.py install" diyerek sistemimize uygulamayı kurabiliriz.
Debian Paketi Hazırlamak:
Debian tabanlı sistemler için paket oluştururken öncelikle bir uygulama içerisinde "debian" dizini oluşturmalıyız. Bu dizin içerisinde mutlaka olması gereken dosyalar ise şu şekilde:
ebru@debian:~/nagios-plugin-couchbase$ ls -ll debian/
toplam 20
-rw-rw-r-- 1 ebru ebru 153 Haz 5 22:00 changelog
-rw-rw-r-- 1 ebru ebru 2 Haz 5 22:00 compat
-rw-rw-r-- 1 ebru ebru 374 Haz 5 22:00 control
-rw-rw-r-- 1 ebru ebru 660 Haz 5 22:00 copyright
-rwxrwxr-x 1 ebru ebru 175 Haz 5 22:00 rules
Bu dosyaların her birini kendimiz elle tek tek oluşturabileceğimiz gibi "debianize" distutils komutunu da kullanabiliriz. Ben ilk önce tüm dosyaları kendim oluşturuyordum ancak bu şekilde biraz zahmetli. Çünkü ürettiğimiz control, changelog dosyalarının basitte olsa kendilerine özel herkes tarafından ortak kullanılan biçimi var. Örneğin changelog dosyasında yıldızdan sonra bir boşluk bırak değişiklikleri yaz, "--" ifadesinden sonra geliştirici adını yaz gibi. Bu tanımlamaları kendim yaparken biraz buradan ve Debian'ın kendi sayfasından yararlanıyordum. Daha sonra burada paketleme işinin daha basit yöntemini gördüm.
$ python setup.py --command-packages=stdeb.command debianize
Yukarıdaki gibi setup.py'yi kullanarak debian dizinimizi ve içerisinde olması gereken dosyaları üretebiliriz. Bu dosyaları ürettikten sonra geriye kalan sadece küçük kontroller oluyor. Zaten bunun sonucunda yukarıda belirttiğim (debian dizini altında) dosyaları oluşturuyor. Eğer setup.py'yi işimizi görecek şekilde doğru bir şekilde yazmışsak her şey debian dizini altında eksiksiz geliyor. Örneğin ben setup.py içinde uygulama adını kelimeler arasında boşluk bırakarak yazdığım için deb paketi üretirken uygulama adını parse edemiyorum gibi bir hata verdi. Bu gibi durumlar oluşmazsa hatasız debian dizini altındaki dosyalarımız oluşacaktır. debian dizini altındaki dosyalarımızın içeriği nasıl diye bakacak olursak:
debian/changelog # projemizde sürümden sürüme meydana gelen değişiklileri belirttiğimiz dosya.
debian/compat # Tek satırdan oluşan, debhelper paketinin sürümünü belirtir. debhelper deb paketlerini inşa etmek için kullanılır.
debian/control # Bu dosyada projenin sürümü, bağımlılık bilgisi, geliştiricisi, lisansı, uygun olduğu mimari bilgisi bulunur.
debian/copyright # Projeyi kimin hangi lisans ile lisansladığı bilgisi yer alır.
debian/rules # deb paketini üretmek için bir debian Makefile'dır.
Daha sonra aşağıdaki gibi deb paketimizi oluşturabiliriz:
$ dpkg-buildpackage -rfakeroot -uc -us
RPM Paketi Hazırlamak:
Rpm paketlerinide Fedora tabanlı sistemler için gene setup.py yardımı ile hazırlayabiliriz. Eğer setup.py'mizde bir eksiklik yoksa sorunsuz bir şekilde spec dosyamızı oluşturabiliriz. Ben rpm paketi üretirken ilk başta hata aldığımdan önce sadece bir .spec dosyası üretmeyi denedim. .spec dosyası rpm paketi üretilirken bağımlılık, lisans, geliştirici bilgisi, hangi dosyanın nasıl kopyalanmasının gerçekleştirileceği gibi standartların bulundğu bir dosya. deb paketleri için olan debian dizinin toplanmış hali gibi düşünebiliriz. Direkt rpm paketini "python setup.py bdist_rpm" şeklinde üretebiliriz. Eğer önce benim gibi .spec üretip içeriğine bakmak istersenizde "python setup.py bdist_rpm --spec-only" şeklinde yapabilirsiniz.
Debian Paketi Hazırlamak:
Debian tabanlı sistemler için paket oluştururken öncelikle bir uygulama içerisinde "debian" dizini oluşturmalıyız. Bu dizin içerisinde mutlaka olması gereken dosyalar ise şu şekilde:
ebru@debian:~/nagios-plugin-couchbase$ ls -ll debian/
toplam 20
-rw-rw-r-- 1 ebru ebru 153 Haz 5 22:00 changelog
-rw-rw-r-- 1 ebru ebru 2 Haz 5 22:00 compat
-rw-rw-r-- 1 ebru ebru 374 Haz 5 22:00 control
-rw-rw-r-- 1 ebru ebru 660 Haz 5 22:00 copyright
-rwxrwxr-x 1 ebru ebru 175 Haz 5 22:00 rules
Bu dosyaların her birini kendimiz elle tek tek oluşturabileceğimiz gibi "debianize" distutils komutunu da kullanabiliriz. Ben ilk önce tüm dosyaları kendim oluşturuyordum ancak bu şekilde biraz zahmetli. Çünkü ürettiğimiz control, changelog dosyalarının basitte olsa kendilerine özel herkes tarafından ortak kullanılan biçimi var. Örneğin changelog dosyasında yıldızdan sonra bir boşluk bırak değişiklikleri yaz, "--" ifadesinden sonra geliştirici adını yaz gibi. Bu tanımlamaları kendim yaparken biraz buradan ve Debian'ın kendi sayfasından yararlanıyordum. Daha sonra burada paketleme işinin daha basit yöntemini gördüm.
$ python setup.py --command-packages=stdeb.command debianize
Yukarıdaki gibi setup.py'yi kullanarak debian dizinimizi ve içerisinde olması gereken dosyaları üretebiliriz. Bu dosyaları ürettikten sonra geriye kalan sadece küçük kontroller oluyor. Zaten bunun sonucunda yukarıda belirttiğim (debian dizini altında) dosyaları oluşturuyor. Eğer setup.py'yi işimizi görecek şekilde doğru bir şekilde yazmışsak her şey debian dizini altında eksiksiz geliyor. Örneğin ben setup.py içinde uygulama adını kelimeler arasında boşluk bırakarak yazdığım için deb paketi üretirken uygulama adını parse edemiyorum gibi bir hata verdi. Bu gibi durumlar oluşmazsa hatasız debian dizini altındaki dosyalarımız oluşacaktır. debian dizini altındaki dosyalarımızın içeriği nasıl diye bakacak olursak:
debian/changelog # projemizde sürümden sürüme meydana gelen değişiklileri belirttiğimiz dosya.
debian/compat # Tek satırdan oluşan, debhelper paketinin sürümünü belirtir. debhelper deb paketlerini inşa etmek için kullanılır.
debian/control # Bu dosyada projenin sürümü, bağımlılık bilgisi, geliştiricisi, lisansı, uygun olduğu mimari bilgisi bulunur.
debian/copyright # Projeyi kimin hangi lisans ile lisansladığı bilgisi yer alır.
debian/rules # deb paketini üretmek için bir debian Makefile'dır.
Daha sonra aşağıdaki gibi deb paketimizi oluşturabiliriz:
$ dpkg-buildpackage -rfakeroot -uc -us
RPM Paketi Hazırlamak:
Rpm paketlerinide Fedora tabanlı sistemler için gene setup.py yardımı ile hazırlayabiliriz. Eğer setup.py'mizde bir eksiklik yoksa sorunsuz bir şekilde spec dosyamızı oluşturabiliriz. Ben rpm paketi üretirken ilk başta hata aldığımdan önce sadece bir .spec dosyası üretmeyi denedim. .spec dosyası rpm paketi üretilirken bağımlılık, lisans, geliştirici bilgisi, hangi dosyanın nasıl kopyalanmasının gerçekleştirileceği gibi standartların bulundğu bir dosya. deb paketleri için olan debian dizinin toplanmış hali gibi düşünebiliriz. Direkt rpm paketini "python setup.py bdist_rpm" şeklinde üretebiliriz. Eğer önce benim gibi .spec üretip içeriğine bakmak istersenizde "python setup.py bdist_rpm --spec-only" şeklinde yapabilirsiniz.
27 Mayıs 2013 Pazartesi
Rest Api ve cbstats kullanarak CouchBase'den Bilgi Çekme
Bu hafta Nagios CouchBase eklentisinde eksik kalan kısımları tamamladım. Vbucket resources, disk queues gibi diğer alanlar eksikti. Ancak eklemem gereken yerlerin bir kısmını bulamadım. Couhcbase'den bu istatistikleri alabilmek için şuan "cbstats" komutunu kullanıyorum. En başta Rest api ile istatistikleri alırken daha sonra Rest Api ile bu istatistiklerin büyük bir kısmını bu şekilde alamayacağımı düşünüp "cbstats" kullanmaya başladım. Madem cbstats kullanıyorsam tüm bilgiyi onula çekeyim diye tüm kodu cbstats ile kullanılabilecek hale getirdim.
cbstats ile bilgi çekme şu şekilde:
./cbstats ip:11220 all -b bucket_name
"all" dediğimde bucket için olan tüm bilgiyi döndürüyor. İlgili alanı string üzerinde oynayarak elde ediyorum.
cbstats kullanmaya karar verdiğim akşam cbstats çıktısını nasıl anlamlandırıp hangi alan, web arayüzündeki değere karşılık geliyor diye nasıl bulacağımı düşünürken şunu fark ettim. cbstats komutunda değerler "vb_active_ops_update", "delete_hits" şeklindeki stringlere karşılık gelen değerler şeklinde dönüyor. Web arayüzünde de bilgisini çekmek istediğim alanın üzerine fare ile gelince ilgili alanın hangi değerler üzerinde işlem yapılarak hesaplandığı yazıyordu. Bunu bir kaç durum için kontrol edince cbstatsın değerleri byte olarak döndürdüğünü ve arayüzdeki belirtilen değerlerden bu sonuçların elde edildiğine emin oldum. Zaten "cache_miss_ratio" değerini kontrol etmeyi eklentiye ekleyecekken coucbase listesinde "cache_miss_ratio" nun hesaplanma şeklinin web arayüzünde fare ile üzerine gelince hesaplanan değerlerden oluştuğunu görünce emin oldum. Aslında hangi alanın cbstats'ın hangi çıktısına geldiği belgesinde de yazılı ancak hepsi yazılmış değil.
Bu haftaki eksikleri tamamlamak için baktığımda ise eksik kalan istatistikleri "cbstats" ile hesaplatamadığımı fark ettim. Aslında bir cevap dönüyor geriye ancak bu web arayüzünde gördüğümden farklı ve olması gerektiği değere nasıl dönüştüreceğimi bulamadım ve bu her istatistik için geçerli değil. Bazılarında durum bu şekilde. Listede Rest api kullanarak tüm istatistikleri bulabileceğimin önerilmesi ile birlikte Rest apide dönen değerler için bazı istatistik değerleri web arayüzündekinin aynısı. Ancak direkt arayüzdekinin aynısı bilgi döndüğü için, dönen değer gb mı, mb mı bilemiyorum. Bu iyi bir şey değil. Çünkü ben eklentiye birim bilgiside eklesem iyi olur :) Ve Rest api kullanarak da gene cbstats da olduğu gibi dönen değeri web arayüzdeki biçime dönüştüremiyorum. Çok bir şey değişmedi aslında bu durumda. Yani eklemem gereken istatistik bilgisi için bir cevap bulabiliyorum ancak webdeki ile aynı biçimde olmuyor. Bu durum cbstatsda da böyleydi. Muhtemelen yanlış bilgi dönmüyor ancak Rest apide elde ettiğim cevaplarda bir dizi içinde aynı değer 43 kere yazıyor gibi bir durum var. Ve webdeki bilgi ile aynı değil. Bu bilgiyi webdeki gibi anlamlı şekle nasıl dönüştürebilirim diye listede sordum. Ancak henüz cevap alamadım ve CouchBase belgesinde de bu yazılı değil, başka kaynak da bulamıyorum açıkçası.
Ben en başta Rest api ile bir çok bilgi eksik kalıyor zannettim dediğimde Rest apide dönen cevapta "streaming uri" gibi kısımlar var. Buradaki uri bilgisiyle bir kez daha http request isteğinde bulunduğumda ilgili alanları elde edebiliyorum. Bu istek için olan uri ise şu şekilde:
"ip:8091/pools/default/buckets/test_bucket/stats/vb_active_num"
Aslında burada son kısımda belirtilen "vb_active_num" alanı bilgisine "cbstats" ile de ulaşabiliyorum. Bu uri ile "vb_active_num" bilgisine ulaşacağımı
ip:8091/pools/default/buckets/default/statsDirectory
urisini kullanarak elde ediyorum. En başta cbstats ile arayüzde hesaplanan değerleri elde edebileceğimi bilmeden de buraya ulaşamazdım aslında.
Son olarak web arayüzde belirtilen "summary" kısmını eksiksiz olarak eklentiye ekledikten sonra projeyi paketleme ve belge yazma kısmına geçmeme karar verdik.
cbstats ile bilgi çekme şu şekilde:
./cbstats ip:11220 all -b bucket_name
"all" dediğimde bucket için olan tüm bilgiyi döndürüyor. İlgili alanı string üzerinde oynayarak elde ediyorum.
cbstats kullanmaya karar verdiğim akşam cbstats çıktısını nasıl anlamlandırıp hangi alan, web arayüzündeki değere karşılık geliyor diye nasıl bulacağımı düşünürken şunu fark ettim. cbstats komutunda değerler "vb_active_ops_update", "delete_hits" şeklindeki stringlere karşılık gelen değerler şeklinde dönüyor. Web arayüzünde de bilgisini çekmek istediğim alanın üzerine fare ile gelince ilgili alanın hangi değerler üzerinde işlem yapılarak hesaplandığı yazıyordu. Bunu bir kaç durum için kontrol edince cbstatsın değerleri byte olarak döndürdüğünü ve arayüzdeki belirtilen değerlerden bu sonuçların elde edildiğine emin oldum. Zaten "cache_miss_ratio" değerini kontrol etmeyi eklentiye ekleyecekken coucbase listesinde "cache_miss_ratio" nun hesaplanma şeklinin web arayüzünde fare ile üzerine gelince hesaplanan değerlerden oluştuğunu görünce emin oldum. Aslında hangi alanın cbstats'ın hangi çıktısına geldiği belgesinde de yazılı ancak hepsi yazılmış değil.
Bu haftaki eksikleri tamamlamak için baktığımda ise eksik kalan istatistikleri "cbstats" ile hesaplatamadığımı fark ettim. Aslında bir cevap dönüyor geriye ancak bu web arayüzünde gördüğümden farklı ve olması gerektiği değere nasıl dönüştüreceğimi bulamadım ve bu her istatistik için geçerli değil. Bazılarında durum bu şekilde. Listede Rest api kullanarak tüm istatistikleri bulabileceğimin önerilmesi ile birlikte Rest apide dönen değerler için bazı istatistik değerleri web arayüzündekinin aynısı. Ancak direkt arayüzdekinin aynısı bilgi döndüğü için, dönen değer gb mı, mb mı bilemiyorum. Bu iyi bir şey değil. Çünkü ben eklentiye birim bilgiside eklesem iyi olur :) Ve Rest api kullanarak da gene cbstats da olduğu gibi dönen değeri web arayüzdeki biçime dönüştüremiyorum. Çok bir şey değişmedi aslında bu durumda. Yani eklemem gereken istatistik bilgisi için bir cevap bulabiliyorum ancak webdeki ile aynı biçimde olmuyor. Bu durum cbstatsda da böyleydi. Muhtemelen yanlış bilgi dönmüyor ancak Rest apide elde ettiğim cevaplarda bir dizi içinde aynı değer 43 kere yazıyor gibi bir durum var. Ve webdeki bilgi ile aynı değil. Bu bilgiyi webdeki gibi anlamlı şekle nasıl dönüştürebilirim diye listede sordum. Ancak henüz cevap alamadım ve CouchBase belgesinde de bu yazılı değil, başka kaynak da bulamıyorum açıkçası.
Ben en başta Rest api ile bir çok bilgi eksik kalıyor zannettim dediğimde Rest apide dönen cevapta "streaming uri" gibi kısımlar var. Buradaki uri bilgisiyle bir kez daha http request isteğinde bulunduğumda ilgili alanları elde edebiliyorum. Bu istek için olan uri ise şu şekilde:
"ip:8091/pools/default/buckets/test_bucket/stats/vb_active_num"
Aslında burada son kısımda belirtilen "vb_active_num" alanı bilgisine "cbstats" ile de ulaşabiliyorum. Bu uri ile "vb_active_num" bilgisine ulaşacağımı
ip:8091/pools/default/buckets/default/statsDirectory
urisini kullanarak elde ediyorum. En başta cbstats ile arayüzde hesaplanan değerleri elde edebileceğimi bilmeden de buraya ulaşamazdım aslında.
Son olarak web arayüzde belirtilen "summary" kısmını eksiksiz olarak eklentiye ekledikten sonra projeyi paketleme ve belge yazma kısmına geçmeme karar verdik.
13 Mayıs 2013 Pazartesi
Nagios'da Kullanıcı Oluşturma
Nagios'da web arayüzünden kimlik kanıtlaması yaparak sistem durumunu inceleyebiliriz. Bu durumda birden fazla farklı yetkilere sahip kullanıcılar oluşturumamız gerekebilir. Örneğin bir kullanıcı sadece web arayüzündeki bilgileri okusun ancak değiştiremesin (read-only) istiyorsak şu şekilde yapmalıyız. Öncelikle belirlediğimiz kullanıcı adı ve parolayı "htpaswd" komutuyla "/etc/nagios3/htpasswd.users" dosyasına yazdırmalıyız. "htpasswd htpasswd.users testuser" diyerek "testuser" isimli bir kullanıcı adı ve parolası belirlemiş olduk. htpaswd komutunun bir miktar parametresi var. Şifrelenmesi gereken parolanın şifreleme algoritması türünü seçebiliriz, parolayı düz metin olarak tutabiliriz, oluşturduğumuz kulllanıcıları silebiliriz gibi.
Oluşturduğumuz bu kullanıcıya sadece webten okuma yetkisi vermek ise şu şekilde:
Öncelikle "/etc/nagios3/cgi.cfg" dosyasında muhtemelen yorum satırı halinde bulunan "authorized_for_read_only=" satırının başındaki "#" kaldırıp oluşturduğumuz kullanıcı adını ekliyoruz. Zaten cgi.cfg dosyasından oluşturulan kullanılacalara hangi yetkileri verebileceğimiz ile ilgili bilgiler var. Oradan istediğimiz özellikleri açabiliriz.
Oluşturduğumuz kullanıcıyı contact.cfg ( /etc/nagios3/conf.d/contacts_nagios2.cfg ) dosyasında da tanımlamalıyız.
Bu tanımlamalarıda ekledikten sonra, Nagios'da çalıştırdığımız komutların tanımlamalarını yaptığımız yerlere "testuser" kullanıcısını ait olduğu grup adını eklemeliyiz ki, izlenen servisler "testuser" kullanıcısı tarafından görülebilsin. O da şu şekilde olmalı:
Oluşturduğumuz bu kullanıcıya sadece webten okuma yetkisi vermek ise şu şekilde:
Öncelikle "/etc/nagios3/cgi.cfg" dosyasında muhtemelen yorum satırı halinde bulunan "authorized_for_read_only=" satırının başındaki "#" kaldırıp oluşturduğumuz kullanıcı adını ekliyoruz. Zaten cgi.cfg dosyasından oluşturulan kullanılacalara hangi yetkileri verebileceğimiz ile ilgili bilgiler var. Oradan istediğimiz özellikleri açabiliriz.
Oluşturduğumuz kullanıcıyı contact.cfg ( /etc/nagios3/conf.d/contacts_nagios2.cfg ) dosyasında da tanımlamalıyız.
define contact{
contact_name testuser
alias alias2
service_notification_period 24x7
host_notifications_enabled 1
service_notifications_enabled 1
host_notification_period 24x7
service_notification_options w,u,c,r
host_notification_options d,r
service_notification_commands notify-service-by-email
host_notification_commands notify-host-by-email
email mail_adresiniz
}
define contactgroup{
contactgroup_name test
alias alias_test
members testuser
}
Bu tanımlamalarıda ekledikten sonra, Nagios'da çalıştırdığımız komutların tanımlamalarını yaptığımız yerlere "testuser" kullanıcısını ait olduğu grup adını eklemeliyiz ki, izlenen servisler "testuser" kullanıcısı tarafından görülebilsin. O da şu şekilde olmalı:
define command{
command_name cb_disk_read
command_line $USER1$cb_disk_read $ARG1$ $ARG2$ ...
}
define service{
use generic-service
host_name localhost
service_description Couchbase Disk Read
check_command cb_disk_read!10!0
contact_groups admins, test # testuser'in bulundugu grup
}
Nagios Couchbase Eklentisinin Canlı Demosu Hazır
Bu dönem Kaan ile birlikte üzerinde çalıştığım Yakından Eğitim projesi olan Nagios Couchbase eklentisinin bu hafta büyük bir kısmını tamamladık, ve demosunu hazırladık. Uygulamanın çalışır halini web arayüzünden "testuser" kullanıcı adı ve "password" parolası ile "http://54.234.80.73/nagios3/" linkinden görebilirsiniz. Kullanıcı adı ve parolamızla sisteme girdikten sonra şöyle bir arayüzle karşılacağız:
Sol köşede "Current Status" kısmındaki "Services" bölümüne tıkladıktan sonra nagios kullanarak izlediğimiz servisleri görebiliriz.
Nagios CouchBase Plugin diğer yaptığım projeler gibi bir özgür yazılım projesi ve GPL ile lisansladık. Uygulamanın kaynak koduna buradan bakabilir ve alıp kullanabilirsiniz. Gördüğünüz hataları, eksikleri, tavsiyelerinizi almaktan da oldukça memmun oluruz.
Bir kaç hafta içerisinde de CouchBase'den çekilmesi gereken diğer bilgilerle birlikte, daha fazla test etme, kod iyileştirme gibi kısımlarıda yaptıktan sonra projeyi bitirmiş olacağım.
Sol köşede "Current Status" kısmındaki "Services" bölümüne tıkladıktan sonra nagios kullanarak izlediğimiz servisleri görebiliriz.
Burada sistemin kendi üzerindeki kullanıcı sayısı, http servisi, ssh gibi çalışan süreçleri dışında benim CouchBase'den bilgi çekerek izlemimizi sağladığım özellikler de var. CouchBase, nagios ile aynı makine üzerine kurulu olduğundan localhost tanımlamasıyla nagios üzerinden izleme yaptım. Buradaki Couchbase'den aldığımız bilgilerin açıklaması ise şu şekilde:
CouchBase CAS: CAS aslında "check and set methods" kısaltması olarak kullanılıyor. Bu methodlarla var olan bilgiyi güncelleyebiliyoruz.
CouchBase Create per second: Saniye başına disk üzerinde oluşturulan yeni verilerdir.
CouchBase Delete per second: Saniye başına disk üzerinde silinen verilerdir.
CouchBase Disk read: Belirtilen bucket için disk üzerinde yapılan okuma işlemleridir.
CouchBase Disk write queue: Belirtilen bir bucket üzerinde yazılmayı bekleyen kuyruktaki veriler.
CouchBase Memory usage: Kullanılmış olan bellek miktarı.
CouchBase Operation per second: Disk üzerinde saniye başına yapılan işlem sayısı.
CouchBase Disk update per second: Saniye başına disk üzerinde güncellenen veri miktarı.
CouchBase Disk set per second: Saniye başına disk üzerinde yapılan yazma işlemleri.
Bir kaç hafta içerisinde de CouchBase'den çekilmesi gereken diğer bilgilerle birlikte, daha fazla test etme, kod iyileştirme gibi kısımlarıda yaptıktan sonra projeyi bitirmiş olacağım.
6 Mayıs 2013 Pazartesi
Nagios Bildirimlerini Eposta Yoluyla Almak
Nagios'ta izlediğimiz hostların, servislerin durumlarından mail ya da sms ile haberdar olabiliriz. Bunun için ayar dosyalarında bir kaç tanımlama yapmak gerekli. Bu tanımlamalar ise şu şekilde:
1) /etc/nagios3/conf.d/contacts_nagios2.cfg dosyasında "contact" ve "contacgroup" tanımlamalarını ekliyoruz. Bu tanımlamalarda "contact" kısmındaki "contact_name", "contactgroup" daki "members"a referans verilmeli.
1) /etc/nagios3/conf.d/contacts_nagios2.cfg dosyasında "contact" ve "contacgroup" tanımlamalarını ekliyoruz. Bu tanımlamalarda "contact" kısmındaki "contact_name", "contactgroup" daki "members"a referans verilmeli.
define contact{
contact_name root
alias Important Server Admin
host_notifications_enabled 1
service_notifications_enabled 1
service_notification_period 24x7
host_notification_period 24x7
service_notification_options w,u,r,c
host_notification_options d,r
service_notification_commands notify-service-by-email
host_notification_commands notify-host-by-email
email mail_adresiniz
}
define contactgroup{
contactgroup_name admins
alias Important Administrators
members root
}
Daha sonra çalıştırmak istediğimiz hostun ve servisin tanımlamasını yaptığımız yerde de "contact_groups" bilgisini eklemeliyiz. Şu şekilde:
define host{
use generic-host
host_name localhost
alias localhost
address 127.0.0.1
contact_groups admins
}
define service{
use generic-service
host_name localhost
service_description Couchbase Mem Usage
check_command ...
contact_groups admins
}
1 Mayıs 2013 Çarşamba
Muğla Özgür Yazılım Semineri
Geçen hafta cuma günü Muğla'ya özgür yazılım semineri için gittik. Seminerin ana konusunu "Özgür yazılım projelerine nasıl katılabilir ve nasıl kendinizi yetiştirebilirsiniz?" olarak belirlemiştik. Seminerde Necdet hoca özgür yazılım felsefesinden bahsetti. Ahmet, Serhat ve ben de projelere nasıl katkı verilebileceğinden, özgür yazılımda hangi imkanların sunulduğundan bahsettik. Projelere katkı verme konusunda kendi deneyimlerimizden bahsedeceğimiz için anlatması biraz daha rahat oldu benim için. Konuşma yaptığım ilk seminer olduğu için oldukça heyecanlıydım. Genelde yüksek sesle konuşan biri olmadığımdan konuşma sırasında insanlar ne dediğimi duymazlar, anlatmak istediğimi anlatamam gibi olası durumlardan korkmadım değil :) Ama neyseki hiç böyle olmadı, anlatırken insanlara baygınlık geçirtmeden anlatabildim :) En çok korktuğum şeylerden biri sıkıcı bir şekilde anlatmaktı çünkü. Ahmet ve Serhat sunum konusunda geçen yıldan tecrübeli olduklarından onlar benden daha sakinlerdi.
Muğla'da Enis hoca ve Esra'nın misafiri olduk :) Enis hoca bizi çok güzel bir şekilde ağırladı. Seminerden sonraki gün Muğla'da bir kaç yer gezdik. Kahvaltı için gittiğimiz yerlerdeki her şey çok doğaldı, bu yüzden midem (reflüden dolayı) fazla zorlanmadı :) Eski Muğla dedikleri bir semti de gezdik en çok orayı beğendim. Kurtuluş savaşı dönemine çok ilgiliyim, Eski Muğla'daki evler aynı öyleydi. O yüzden Eski Muğla'yı çok beğendim.
Muğla'daki seminer bu biraz yorucu ve bolca heyecanlı bir şekilde sonlandı benim için. Umarım herkes için faydalı olmuştur :)
Muğla'da Enis hoca ve Esra'nın misafiri olduk :) Enis hoca bizi çok güzel bir şekilde ağırladı. Seminerden sonraki gün Muğla'da bir kaç yer gezdik. Kahvaltı için gittiğimiz yerlerdeki her şey çok doğaldı, bu yüzden midem (reflüden dolayı) fazla zorlanmadı :) Eski Muğla dedikleri bir semti de gezdik en çok orayı beğendim. Kurtuluş savaşı dönemine çok ilgiliyim, Eski Muğla'daki evler aynı öyleydi. O yüzden Eski Muğla'yı çok beğendim.
Muğla'daki seminer bu biraz yorucu ve bolca heyecanlı bir şekilde sonlandı benim için. Umarım herkes için faydalı olmuştur :)
29 Nisan 2013 Pazartesi
Nagios Makro Kullanımı
Makrolar Nagios'ta komut tanımlamaları, host tanımlamaları, servis tanımlamaları gibi kısımlarda değişkenlerde kullanılırlar.
Host adres makrosu:
Aşağıdaki komut tanımlamasındaki "$HOSTADDRESS$" ile ifade edilen kısım host tanımlamasındaki ip adresiyle aynı değerdir.
Makroların kullanım şekillerinde bunun gibi bir kaç durum daha mevcut. Ancak temel olarak bilinmesi gerekenler bu kadar olduğu için ben de şimdilik bu kadar bahsettim.
Host adres makrosu:
Aşağıdaki komut tanımlamasındaki "$HOSTADDRESS$" ile ifade edilen kısım host tanımlamasındaki ip adresiyle aynı değerdir.
define host{
host_name linux
address 192.168.1.2
check_command check_ping
...
}
define command{
command_name check_http
command_line $USER1$/check_ping -H $HOSTADDRESS$ -w ..
}
Komut Argüman Makrosu: define service{
host_name linuxbox
service_description PING
check_command check_ping!200.0,80%!400.0,40%
...
}
/path/check_ping -H 192.168.1.2 -w 200.0,80% -c 400.0,40%
Yukarıdaki servis tanımlamasında ise "!" işaretleriyle ayrılan her bir kısım komutta tanımlamanan "-w", "-c" gibi parametrelerin aldıkları değere karşılık gelir.Makroların kullanım şekillerinde bunun gibi bir kaç durum daha mevcut. Ancak temel olarak bilinmesi gerekenler bu kadar olduğu için ben de şimdilik bu kadar bahsettim.
22 Nisan 2013 Pazartesi
Nagios Couchbase Eklentileri
Yapacağım Nagios Couchbase eklentisinde veri tabanlarından çektiğimiz her bilgiyi hem Couchbase'deki kümeden (cluster), hem de belirli bir sunucu üzerinden çekmem gerekiyordu. Github'ta yapılmasını istediğimiz eklentilerden bir kaçını cluster ve sunucular için bu hafta yapıp, nagios için olan ayar dosyalarını githuba koydum. Gene optparse kullanarak parametre aldırdım. Kullanıcı adı ve parolasıyla kimlik kanıtlaması kısımını geçirdikten sonra sıra veri çekmedeydi. İlk yazdığım eklenti saniye başına yapılan işlem bilgisi çekmeydi. Bunun için girilecek parametre "--OPS" (operation per second) diye belirledim. Ancak burda şöyle bir şey gerekli, kullanıcı --OPS parametresini, parametreye bir değer atamadan giriyor. Kullanıcının parametreye bir değer ataması gerekse bu parametreye bir değer atanıp atanmadığını kontrol edebilirdim. Hiç değer girilmeyen bir parametrenin komut satırından yazılıp yazılmadığını kontrol etmek için tekrar optparse belgesini okudum ama orada buna benzer bir şey göremedim. Okuduğum bloglar ve örnek nagios eklentilerinden yola çıkarak şu şekilde yapmaya karar verdim:
Yaptığım eklentide mail atma ve bir kaç test betiği yazdıktan sonra ilk sürümü bitirmiş olmayı planlıyoruz. Mail atma ve test etme kısımlarını tamamlamak için hafta sonu bir de Couchbase SDK'sına baktım. Kendi bilgisayarımdan Couchbase'in kurulu olduğu makine için sorgular falan yapıp, kalan kısımları tamamlayacaktım. Ama Couchbase'e bağlandıktan sonraki kısım timeout hatası verdi. Ben önce uzun döngülere girdirecek yanlış bir fonksiyon yazdım ondan kaynaklı sandım. Bir süre daha fazla beklediğimde timeout hatası aldım. Couchbase'in timeout değerleriyle oynasam bile işlemler çok uzun sürecekti bu şekilde. Sonra Couchbase'in kurulu olduğu makineye bağlanıp aynı sorguları çalıştırdığımda hata vermedi. Bu yüzden diğer makine üzerinde devam etmeye karar verdik. Eklentiler bittiğinde Couchbase'de tutulan neredeyse bir çok durumun çekildiği eklentiler tamamlanmış olacak.
parser.add_option('--OPS', action='callback', callback=option_none, dest='operations_per_second')
Yukarıda parametre tanımlaması yaparken 'action' kısmında bu parametre kullanılırsa bir fonksiyona gitmesi gerektiği için 'callback' ve fonksiyon ismi tanımlaması yaptım. Bu şekilde kullanıcı --OPS parametresini girdiği anda callback kısmında tanımlanan fonksiyon çalıştırılacak. Tanımladığımız fonksiyonda ise komut satırında --OPS seçeneğinden sonra girilen değerlere bakarak --OPS değer girilme durumunu kontrol ettim. O da bu şekilde:def option_none(option, opt, value, parser):
if parser.rargs and not parser.rargs[0].startswith('-'):
print "Option arg error"
...
....
setattr(parser.values, option.dest, True)
Eğer --OPS seçeneğinden sonra değer ataması olacak bir şey girilmediyse --OPS değerini True yapıp, bu değere bakarak sonrasındaki işlemleri devam ettirdim. optparse belgesinde parser.rargs ile ilgili bir şey yazmıyordu bana lazım olan kısım burasıydı. Buna bakarken artık optparse'dan ziyade argParse'ın kullanılsa daha iyi gibi bir şeyler okudum. argParse'da parametrelerle ilgili daha gelişmiş özellikler var. Ama incelediğim bir çok nagios eklentisinde herkes hala optparse kullanıyor. Bu konuyu Kaan'a danışacaktım ama unuttum :) Daha sonra kimlik kanıtlaması yapıp dönen veriyi hangi tipe çevirip veri tabanından bilgi çekmek daha kolay oluyorsa o tip üzerinde oynayarak istediğimiz bilgiyi elde ediyoruz.Yaptığım eklentide mail atma ve bir kaç test betiği yazdıktan sonra ilk sürümü bitirmiş olmayı planlıyoruz. Mail atma ve test etme kısımlarını tamamlamak için hafta sonu bir de Couchbase SDK'sına baktım. Kendi bilgisayarımdan Couchbase'in kurulu olduğu makine için sorgular falan yapıp, kalan kısımları tamamlayacaktım. Ama Couchbase'e bağlandıktan sonraki kısım timeout hatası verdi. Ben önce uzun döngülere girdirecek yanlış bir fonksiyon yazdım ondan kaynaklı sandım. Bir süre daha fazla beklediğimde timeout hatası aldım. Couchbase'in timeout değerleriyle oynasam bile işlemler çok uzun sürecekti bu şekilde. Sonra Couchbase'in kurulu olduğu makineye bağlanıp aynı sorguları çalıştırdığımda hata vermedi. Bu yüzden diğer makine üzerinde devam etmeye karar verdik. Eklentiler bittiğinde Couchbase'de tutulan neredeyse bir çok durumun çekildiği eklentiler tamamlanmış olacak.
15 Nisan 2013 Pazartesi
Nagios CouchBase Kimlik Doğrulama Eklentisi
Geçen cuma biten sınav haftam ardından hafta sonu NoSql, CouchBase gibi kavramlara baktım. Daha öncesinde çok az bilgim olan bu konulara hakkında yazılmış bloglar okudum. Sonrasında Couchbase kurulumu yaptım. Aslında Couchbase'i kendi yerelimde kurup deneyecektim. Ama benim makinem kaldırmadı. 4 gb ram gerekli, şu gerekli, bu gerekli dediği için kurulumu kesmek zorunda kaldım. Sonrasında daha yeterli başka bir makine üzerinde kurulum yapıp kendi bilgisayarımdan uzaktaki makineye bağlandım.
Couchbase kullanımını öğrenmek için Couchbase'in kendi sitesinden faydalandım. Orada bir çok şey anlatılıyor zaten. Hafta sonu Kaan webten kullanımı nasıl ve Rest Api nasıl gibi kavramlara baksan yeterli olur demişti. Burada anlatılanlar oldukça uzun çünkü hepsini 1 günde kavramam zor olabilirdi :)
Okuduğum kavramlar arasında temel olanlar cluster ve buckettı. Belgede cluster diyerek bahsettiği üzerinde Couchbase'in çalıştığı her bir makine, bucket ise bu makineler üzerinde oluşturulmuş olan veri tabanı. Couchbase'de veriler json belgeler olarak veri tabanında saklanır ve her json belgesi diğer belgeleri değiştirmeye ihtiyaç duymadan içeriği değiştirilebilir. Zaten Couchbase'i hızlı kılan özelliklerden biri bu.
Hafta sonu Couchbase'de kimlik kanıtlaması yapan bir nagios eklentisi yazdım. Nagios eklentisi yazarken Python ile yazıyorsak optparse adında bir kütüphane ile parametre alarak çalışan kodlar yazabileceğimizi bu yazımda belirtmiştim.
Kimlik kanıtlamasını kısmını ise rest api ile http isteği göndererek yapıyoruz. Bu isteklere karşılık dönen durum kodlarının ne anlama geldiği ise burada belirtilmiş. Ben de bu eklentiyi yazarken "import requests" diyerek http isteklerini gönderebilmem için olan kütüphaneyi import ettim. Sonrasında
Couchbase kullanımını öğrenmek için Couchbase'in kendi sitesinden faydalandım. Orada bir çok şey anlatılıyor zaten. Hafta sonu Kaan webten kullanımı nasıl ve Rest Api nasıl gibi kavramlara baksan yeterli olur demişti. Burada anlatılanlar oldukça uzun çünkü hepsini 1 günde kavramam zor olabilirdi :)
Okuduğum kavramlar arasında temel olanlar cluster ve buckettı. Belgede cluster diyerek bahsettiği üzerinde Couchbase'in çalıştığı her bir makine, bucket ise bu makineler üzerinde oluşturulmuş olan veri tabanı. Couchbase'de veriler json belgeler olarak veri tabanında saklanır ve her json belgesi diğer belgeleri değiştirmeye ihtiyaç duymadan içeriği değiştirilebilir. Zaten Couchbase'i hızlı kılan özelliklerden biri bu.
Hafta sonu Couchbase'de kimlik kanıtlaması yapan bir nagios eklentisi yazdım. Nagios eklentisi yazarken Python ile yazıyorsak optparse adında bir kütüphane ile parametre alarak çalışan kodlar yazabileceğimizi bu yazımda belirtmiştim.
Kimlik kanıtlamasını kısmını ise rest api ile http isteği göndererek yapıyoruz. Bu isteklere karşılık dönen durum kodlarının ne anlama geldiği ise burada belirtilmiş. Ben de bu eklentiyi yazarken "import requests" diyerek http isteklerini gönderebilmem için olan kütüphaneyi import ettim. Sonrasında
r = requests.get("http://ip_adress/pools", auth=("username", "password"))
print r.status_code
şeklinde kullanıcı adı ve parola göndererek sistemde kimlik kanıtlaması yapıldığında 200, yapılmazsa 401 kodu döndüren bir eklenti yazmış oldum.
İlişkisel Olmayan Veri Tabanı: NoSQL
NoSql Facebook, Twitter, LinkedIn, Google gibi bir çok şirket tarafından kullanılır. NoSql ilişkisel veri tabanı olmamakla birlikte ona rakip de değildir. İlişkisel veri tabanına alternatif olarak ortaya çıkmıştır.
Düşündüğümüzde internet ortamında gün geçtikçe saklanan veri miktarı artmakta ve verilerin işlenmesi de zorlaşmaktadır. Artan veri miktarıyla birlikte verilerin birbirleriyle olan bağlantısı artıp karmaşıklaşmıştır. NoSql ile bu verileri işlemek kolaylaşmıştır.
Google, Twitter gibi büyük şirketlerin NoSql'i kullanma sebepleri arasında tuttukları verinin çok büyük olması yanında aynı veri bloğuna sürekli başka bilgiler eklenip güncellenmesidir. NoSql ile veri güncelleme işlemleri daha hızlı yapılır. Çünkü ilişkisel veri tabanındaki gibi bir tablodaki tüm verilerin sütun sayısı aynı olmak zorunda değildir. Verilerin tutulma şekli Sql'den daha basittir.
NoSql çeşitlerini veri tutma biçimlerine göre 4 temel kategoride inceleyebiliriz:
Anahtar-Değer Şeklinde Depolama Yapanlar: Bu sistemlerde anahtara karşılık gelen değerler tutulur. Bu şekilde veri depolanmasında genelde önbellekleme işlemleri çok büyük performans harcar. Örnek olarak Amazon tarafından oluşturulmuş olan Dynomo.
Sütunlar Şeklinde Tutulanlar: Bu yapı genelde bir çok farklı makine üzerine dağıtılmış oldukça büyük veriler için kullanılır. Örnek olarak Google tarafından üretilip kullanılan Big Table.
Döküman Tabanlı Depolama Yapanlar: Veriler döküman şeklinde tutulur. Bu dökümanlar ise json biçminde saklanır. MongoDB, CouchDB gibi.
Graf Tabanlılar: Düğümlerden oluşur. Düğümler arasındaki ilişki saklanır.
9 Nisan 2013 Salı
Nagios Plugin Yazma
Nagios ile servisleri izlemek için çeşitli pluginler (eklentiler) kullanır. Bu eklentiler betiklerden oluşur. Ben de geçen hafta python kullanılarak yazılmış bir kaç örnek betik inceledim. Genelde betiklerde izlenen yöntem şu şekildeydi: konsoldan parametreler alıp o parametrelere değer girilme ya da girilmeme durumuna göre cevaplar döndüren betiklerdi. Yazılan kodun konsoldan parametre alarak çalışması için genelde optparse kütüphanesi kullanmışlar.
optparse kullanırken temelde yapılan işlem: sisteme verilebilecek parametreleri tanımlama. Küçük bir örnek ile bakacak olursak:
optparse kullanırken temelde yapılan işlem: sisteme verilebilecek parametreleri tanımlama. Küçük bir örnek ile bakacak olursak:
from optparse import OptionParser #standart kullanım tanımlaması parser = OptionParser(usage='%prog [options <arg1> <args2>') #parametre tanimlamalari parser.add_option('-H', dest='hostname') parser.add_option('-u', dest='username') parser.add_option('-p', dest='password') #program calisirken verilen parametreleri optionsa atar options, args = parser.parse_args() #bu sekilde istenen durumlar tanimlanir for option in ('hostname', 'username', 'password'): ..... ..... .......Bu şekilde parametre vererek çalıştırabileceğimiz bir betik yazmış olduk. Ben mysql_check eklentisi yazmıştım. Bunun için yukarıdaki koda ek olarak mysql'e bağlanma kısımlarını eklemiştim. Yazdığımız betiği nagios ile birlikte çalıştırabilmek ise şu şekilde:
#linux_remote.cfg dosyasi define host{ use generic-host host_name Ubuntu2 alias Ubuntu2Alias address ip_adres } define command{ command_name mysql_check #betik dosyasinin tam yolunun yazilmasi command_line $USER1$/mysql_check.py -H host -u username -p paswd } define service{ use generic-service host_name Ubuntu2 service_description MYSQL CONNECT check_command mysql_check }
Yukarıdaki $USER1$ makrosu "/etc/nagios3/resource.cfg" dosyası içinde "$USER1$=/usr/lib/nagios/plugins" şeklinde tanımlı olduğu için kullanabiliyorum. Bunu kullanmayıp kendimiz /dosya_tam_yolu/ şeklinde tanımlasak da olurdu. Ayrıca bu kendi yazmış olduğumuz betikten hariç .cfg dosyasını da /etc/nagios3/nagios.cfg dosyası içerisinde tam yolunu aşağıdaki gibi belirtmeliyiz:
cfg_file=/etc/nagios3/linux_remote.cfg
Bir de bu optparse kullanırken şöyle bir hataya düştüm. Ben kendi tanımladığım "-H" parametresini "-h" olarak tanımladım zannedip o şekilde parametre verip çalıştırıp sürekli "usage" kısmının döndürülmesine neden oluyordum. Ben başka bir yerde hata yaptım diye sürekli başka şeyleri kontrol ettim durdum.
Normalde "-h" ya da "--help" seçeneği varsayılan olarak mevcut olan, tanımlanan yardım kısmını geri döndürmek için olan parametreler. --help'in "usage" kısmını döndürdüğü biliyordum, ancak "-H"ı "-h" niyetine kullandığıma dikkat etmemişim. Akşam analiz ödevini yaptıktan sonra gece eklenti yazmaya bakayım derken uzunca bir süre "-h" dediğim için "usage"i döndürdü. Sonra optparse nasıl belgesine tekrar bakayım derken -h'ın --help ile aynı şeyi yaptığını öğrenince bir an kendimi camdan atmak istedim :)
Normalde "-h" ya da "--help" seçeneği varsayılan olarak mevcut olan, tanımlanan yardım kısmını geri döndürmek için olan parametreler. --help'in "usage" kısmını döndürdüğü biliyordum, ancak "-H"ı "-h" niyetine kullandığıma dikkat etmemişim. Akşam analiz ödevini yaptıktan sonra gece eklenti yazmaya bakayım derken uzunca bir süre "-h" dediğim için "usage"i döndürdü. Sonra optparse nasıl belgesine tekrar bakayım derken -h'ın --help ile aynı şeyi yaptığını öğrenince bir an kendimi camdan atmak istedim :)
Kaydol:
Kayıtlar (Atom)