9-11 Aralık'ta İstanbul Üniversitesi'nde düzenlenen İnternet Konferansı'na katıldım. Hafta içine denk gelmesi ve derslerimin olması nedeniyle sadece son gününe katılabildim. Konferansta 2 panel dinledim. Aynı zamanda sunum yapmak için konuşmacı olarak katıldım. Etkinliğin son günü sanırım yoğun kar yağışı nedeniyle katılım oldukça azdı.
Sunumu Galatasaray Üniversite'sinden Tülin ile birlikte yaptık. Aslında Tülin ile daha önceden hiç görüşmemiştik. Geçen yıl Gnome Opw'ye katıldığından listede e-postalarını görüyordum. Tülin geçen yaz Opw'de Linux çekirdeği projesinde staj yaptı.
Konferansta "Linux Çekirdeğine Nasıl Katkı Verilir?" başlığı altında sunum yaptık. Tülin ile birlikte sunum yapmayı Necdet hoca önermişti, bizde kabul ettik :) Sunuma birlikte hazırlanma fırsatımız olmadı. İnternet üzerinden bir kaç kez görüşüp değineceğimiz yerleri belirledik.
Sunumda anlattıklarımızı bildiri olarak yayınladık. Bildiriye buradan ulaşabilirsiniz. Aynı zamanda diğer sunumların bildirilerine buradan bakabilirsiniz.
23 Aralık 2013 Pazartesi
LPI 102 Sınavı
Bu yılın başlarında Lpi 101 sınavına girip geçmiştim. Dün Lpi 102 sınavına girdik. Bence sınav hiç kolay değildi :) Aslında kolay olmadığını düşünmemde geçen yıla göre az çalışmış olmamın da etkisi var. Geçen yıl bölümden sınava katılan arkadaşlarımla bir sınıfta toplanıp, konulara hepimiz hazırlanıp sonra her hafta bir kişinin o konuyu bize sunmasıyla ilerlemişti. Necdet hoca konuyu anlattığımız sınıfta olup, onun da ek bir şeyler anlatmasıyla konular ilerliyordu. Lpi 102'de böyle yapamadık malesef. Topluca çalışmadık, bireysel hazırlandık. Biz 102 sınavına girerken, 101'e girmemiş olan arkadaşlardan da 101 sınavına katılanlar oldu. Sınava hazırlanma sürecinde en çok X yapılandırmasından ve yönetimsel görevler konusundan (kullanıcı ekleme, silme, grupları yönetme) çok sıkıldım :) Bu yüzden ilk ağ yapılandırması konusundan çalışmaya başladım.
Geçen yıl örnek soru çözmeye çok vakit bulamamıştım. Aslında örnek soru derken Lpi sınav sorularını,sınava girdikten sonra herhangi bir yerde paylaşmak ve çoğaltmak yasak. Ama Lpi konularını içeren sorular hazırlanmış o soruları çözdüm. Çünkü çok fazla komut oluyor ve parametreleri akılda tutmak örnek soruyla daha rahat olabiliyor. Ya da eğer bir komutun tam ne işe yaradığını anlamadıysak soruda görmemiz yardımcı olabiliyor. Bunun için aşağıda linkini verdiğim sitelere baktım. Aslında bu siteleri Tuğçe önerdi, Tuğçe sınıf arkadaşım. Bir de son gece buraya baktım, buradaki bazı sorular kolay ama bazıları gerçekten zor :) Bir de konu dağılımındaki ağırlıklar nasıl diye merak edenler için burası var.
[1] http://www.penguintutor.com/quiz/
[2] http://www.gocertify.com/quizzes/linux-practice-questions/linux-lpi102-lx0102-quiz.html
Bu yıl sınava daha az hazırlanma fırsatı bulmamla birlikte geçersem Lpi 201'e daha fazla çalışacağımı düşünüyorum.
Aslında sertifika almak her şey değil tabi, neticede insan 3 ay sonra bile sınava çalıştığı zamanki kadar ayrıntılı hatırlayamaz her şeyi. Ancak Linux üzerinde çalışırken nelerin daha fazla yapılabildiğini bilmek (ne gibi araçların olduğunu anımsamak) proje geliştirmeyi kolaylaştırır. Eğer sadece neler yapılabiliyor Linux'ta diye açıp bir kitaba baksam muhtemelen baktıktan sonra hatırlayacaklarım bir sınava hazırlandıktan sonra hatırlayacaklarımdan oldukça az olacak. Linux'a olan bakış açımı geliştirdiğini düşündüğümden Lpi konularına çalışmayı seviyorum.
Geçen yıl örnek soru çözmeye çok vakit bulamamıştım. Aslında örnek soru derken Lpi sınav sorularını,sınava girdikten sonra herhangi bir yerde paylaşmak ve çoğaltmak yasak. Ama Lpi konularını içeren sorular hazırlanmış o soruları çözdüm. Çünkü çok fazla komut oluyor ve parametreleri akılda tutmak örnek soruyla daha rahat olabiliyor. Ya da eğer bir komutun tam ne işe yaradığını anlamadıysak soruda görmemiz yardımcı olabiliyor. Bunun için aşağıda linkini verdiğim sitelere baktım. Aslında bu siteleri Tuğçe önerdi, Tuğçe sınıf arkadaşım. Bir de son gece buraya baktım, buradaki bazı sorular kolay ama bazıları gerçekten zor :) Bir de konu dağılımındaki ağırlıklar nasıl diye merak edenler için burası var.
[1] http://www.penguintutor.com/quiz/
[2] http://www.gocertify.com/quizzes/linux-practice-questions/linux-lpi102-lx0102-quiz.html
Bu yıl sınava daha az hazırlanma fırsatı bulmamla birlikte geçersem Lpi 201'e daha fazla çalışacağımı düşünüyorum.
Aslında sertifika almak her şey değil tabi, neticede insan 3 ay sonra bile sınava çalıştığı zamanki kadar ayrıntılı hatırlayamaz her şeyi. Ancak Linux üzerinde çalışırken nelerin daha fazla yapılabildiğini bilmek (ne gibi araçların olduğunu anımsamak) proje geliştirmeyi kolaylaştırır. Eğer sadece neler yapılabiliyor Linux'ta diye açıp bir kitaba baksam muhtemelen baktıktan sonra hatırlayacaklarım bir sınava hazırlandıktan sonra hatırlayacaklarımdan oldukça az olacak. Linux'a olan bakış açımı geliştirdiğini düşündüğümden Lpi konularına çalışmayı seviyorum.
2 Aralık 2013 Pazartesi
Watchdog İle Bildirim Alma
Bu yıl bitirme projemin bir kısmında watchdog kullandım. Watchdog ile makinemizde meydana gelen çeşitli değişiklikleri izleyebiliriz. Ben sadece dosyalar üzerindeki değişiklikleri izlemek için Pyhon modülünü kullandım.
Benim düşüncem Watchdog'un kullanıma hazır denilebilmesi için eksikleri var. Çünkü dosyalar üzerindeki değişiklikleri izleme işlemini Watchdog'u başka bir yazılım ile bütünleştirerek yapmak çok sağlıklı değil. Örneğin, eğer var olan bir dosyayı değiştiriyorsak o dosya için sırasıyla "Silindi, Oluşturuldu, Değiştirildi" bilgisini döndürüyor (editörden bağımsız olarak) . Oysa tek döndürmesi gereken bilgi "Değiştirildi" olmalı. Aynı zamanda dosya taşıma işleminde, eğer izlemediğimiz bir yerden dosyayı izlediğimiz alana taşıyorsak "Oluşturuldu" ya da "Taşındı" bilgisini döndüremiyor.
Burada Watchdog için istenen özellikler, hatalar listelenmiş. Belki dönem içerisinde bende kaynak kodu incelerim. Benim yukarıda bahsettiğim eksikliklerin bir kısmı için Github'a yama gönderilmiş. Ancak ben yamaları koda eklediğimde doğru çalışmadı.
Bu yılki projemde Watchdog'u kullanmam dışında, Necdet hoca "/etc"yi izleyip orada meydana gelen değişiklikleri e-posta gönderen bir betik yazmamı istedi. Bunun için yazdığım kodda oldukça kısa. Buradan ulaşabilirsiniz.
28 Kasım 2013 Perşembe
Özgür Web Teknolojileri Günleri 2013
Geçen hafta sonu Yeditepe Üniversitesi'nde Özgür Web Teknolojileri Günleri etkinliği yapıldı. Çömü'den Necdet hoca ve Aybüke ile katıldık. Bu yıl etkinlik sınav zamanına denk geldiğinden bizim üniversiteden sadece Aybüke ve ben katılabildik. 1. ve 3. sınıfların sınavları hafta sonuna kadar sürdü. Tabi Çömü'lü mezunlardan da bir sürü gelen vardı :)
Bu yıl genel konu "Ölçeklenebilirlik" üzerineydi. Aybüke ve ben aynı zamanda konuşmacı olarak katılmıştık. Ben geçen dönem Kaan ile çalıştığım projeden, Nagios, Couchbase, eklenti yazımı gibi konulardan bahsettim. Aybüke yazın stajı Kaan'ın yanında yaptı. Staj sırasında yazdığı haproxy-tools'dan bahsetti.
Bu yaptığım 2. konuşma olması ile birlikte bu sefer daha fazla heyecanlandım. İlki Muğla'daydı. Orada genelde dinleyiciler öğrencilerden oluştuğu için daha rahattım, çünkü ben de öğrenciyim. Sunum öncesi Doruk Fişek tavsiyelerde bulundu ama sunumu izlediğimde fark ettim ki, pek uygulamamışım :) Bir sonraki sunumumda muhtemelen daha rahat konuşurum diye düşünüyorum.
Dinlediğim sunumlardan en çok Gökhan'ın konuşmasını beğendim. Sunum başlığı "Ölçeklenebilir Web Mimarisi"ydi. Gökhan, Çömü'den mezun. Ben 1. sınıftayken, o 4. sınıftı ve ÇOMaK projesinde çalışıyordu. Sunumda oldukça güzel ve eğlenceli anlattı.
Etkinliğin 2. günü mezun olan üst dönemlerle toplanıp, görüşme fırsatım oldu. Ben çalışma hayatıyla ilgili merak ettiklerimi sordum. Mezuniyet sonrası için düşüncelerim biraz değişti. Aslında bu dönem başında Necdet hoca mezuniyet sonrası için aynı şeyleri önermişti.
Son olarak etkinlik hediyesi tişörtü çok beğendim :)
Bu yıl genel konu "Ölçeklenebilirlik" üzerineydi. Aybüke ve ben aynı zamanda konuşmacı olarak katılmıştık. Ben geçen dönem Kaan ile çalıştığım projeden, Nagios, Couchbase, eklenti yazımı gibi konulardan bahsettim. Aybüke yazın stajı Kaan'ın yanında yaptı. Staj sırasında yazdığı haproxy-tools'dan bahsetti.
Bu yaptığım 2. konuşma olması ile birlikte bu sefer daha fazla heyecanlandım. İlki Muğla'daydı. Orada genelde dinleyiciler öğrencilerden oluştuğu için daha rahattım, çünkü ben de öğrenciyim. Sunum öncesi Doruk Fişek tavsiyelerde bulundu ama sunumu izlediğimde fark ettim ki, pek uygulamamışım :) Bir sonraki sunumumda muhtemelen daha rahat konuşurum diye düşünüyorum.
Dinlediğim sunumlardan en çok Gökhan'ın konuşmasını beğendim. Sunum başlığı "Ölçeklenebilir Web Mimarisi"ydi. Gökhan, Çömü'den mezun. Ben 1. sınıftayken, o 4. sınıftı ve ÇOMaK projesinde çalışıyordu. Sunumda oldukça güzel ve eğlenceli anlattı.
Etkinliğin 2. günü mezun olan üst dönemlerle toplanıp, görüşme fırsatım oldu. Ben çalışma hayatıyla ilgili merak ettiklerimi sordum. Mezuniyet sonrası için düşüncelerim biraz değişti. Aslında bu dönem başında Necdet hoca mezuniyet sonrası için aynı şeyleri önermişti.
Son olarak etkinlik hediyesi tişörtü çok beğendim :)
8 Kasım 2013 Cuma
Linux Çekirdeğine Nasıl Katkı Verilir?
Gnome'un düzenlemiş olduğu Outreach for Women etkinliğine başvuru süreci 11 Kasım'da bitiyor. Ben bu süreçte Linux Kernel için hazırlandım. Geçen yıl Gnome'un kendi araçlarına başvuruyordum ama sürekli bir şeyler derlemek, kütüphane sürümlerini uyuşturmaya çalışmak bir miktar sıkıcı olabiliyor. Bunun için jhbuild ya da Fedora'nın bir sonraki, henüz çıkmamış sürümünü kullanmak tavsiye ediliyor :) Çünkü katkı vereceğimiz Gnome aracının depodaki son hali üzerine değişiklik yapmalıyız. Çekirdek üzerinde çalışmanın nasıl olduğunu bilmediğimden bu sefer çekirdeğe başvurmaya karar verdim.
Opw Kernel sayfasında tüm yapılması gerekenler, okumak için önerilen bir kaç kitap var. Öncelikle örnek olarak ethernet kodu içine printk("..") ile bir şeyler yazdırıp, çıktısını dmesg logunda görmek var. Burada Greg Kroah-Hartman ilk yamanın nasıl yapılacağından bahsetmiş. Temel olarak yama göndermeye kernel.org'dan aldığımız çekirdek kodları dizini içerisindeki drivers/staging'den başlayabiliriz. Buradaki kodların yazılış biçimini düzeltmeyle işe başlayabiliriz. Greg'de linkini verdiğim sunumunda bundan bahsetmiş. Çok temel kodlama biçimi düzeltmeleri yapabileceğimiz gibi, daha karma düzeltmeler de yapabiliriz. Bir de yama gönderirken e-posta konu satırına uyarı çıktısının tam halini yazmamız gerekiyor. Kendimiz uyarıyı yorumlayıp "bu yama bunu düzeltiyor" şeklinde yazdıklarımız genelde kabul edilmeyebiliyor. Bu yüzden tekrar göndermemiz gerekiyor.
Opw Kernel'a başvurmak için bu temel yamalardan göndermek yeterli. Hatta bu yılki Opw projelerinden birisi de kodlama biçimi düzeltme ve Todo dosyalarındaki eksikleri kapatma. Todo dosyalarındaki eksikleri kapatmak biraz daha alt seviye, aslında baya bir alt seviye :). Çünkü yapılması istenenler de o kadar açık belirtilmemiş dosyada. Ben de çekirdek uyarı mesajlarını analiz etme ve iyileştirme projesine başvurdum.
Başlangıç olarak Linux Kernel'a kodlama biçimi düzeltme dışında Sparse ve Coccinelle araçlarını kullanarak katkı verebiliriz. Bu araçlarla drivers/staging altındaki kodları derlediğimizde aldığımız uyarı mesajlarına göre düzeltmeler yapabiliriz. Bir de kodlar içerisinde yer alan Fixme etiketlerinden yararlanarak katkı vermek de yapabileceğimiz seçeneklerden birisi. Katkı verirken zorlanabileceğimiz yanlardan birisi, Linux Kernel ekibi kodlama biçimine oldukça önem veriyor. Bu yüzden aynı yamayı defalarca göndermek gerekebiliyor. Hatta kodlama biçimini test etmek için yazdıkları bir Perl betiği var. Zaten kodlama biçimi düzeltme yamalarını gönderebilmek için bu betiği kullanmalıyız.
Sparse aracı ile fonksiyon tiplerinin ya da değişken tiplerinin doğruluğu, gereksiz fonksiyonları kaldırma, tip dönüşüm işlemlerinin doğruluğu gibi uyarıları analiz edebiliriz. Bu düzeltmeleri yapmak için koddaki fonksiyonları okuyup, çağırılma sıralarını kontrol etmek, kzallac, kmalloc, volatile gibi tiplere, tip dönüşümlerine bakmak gerekli. Çeşitli tiplerin ne olduğunu öğrenmek için burayı okumak faydalı olabilir.
Coccinelle aracını ise ben henüz kullanmadım. Ancak önümüzdeki günlerde onu da denemeyi düşünüyorum. Bir de daha karmaşık hataları çözebilmek için bir kitap bulup okumayı düşünüyorum.
Opw ekibi projede çalışmak için kişi seçerken genelde öğrenci olmamasını tercih ediyor :( . Okul dönemi içerisinde olan bir öğrenci seçmektense herhangi bir işte çalışmayan birisini seçmenin daha verimli olacağı düşüncesindeler. Bu yüzden öğrencilerin Opw yaz dönemine başvurunca seçilme ihtimali daha yüksek. Çünkü proje sürecinde bir işin var mı sorusuna, sınav haftalarını yazmaktansa hiç işim yok yazmak, şansımızı artıran bir etken. Eğer ben de bu dönem kabul edilmezsem, yaz dönemi tekrar başvuracağım.
Opw Kernel sayfasında tüm yapılması gerekenler, okumak için önerilen bir kaç kitap var. Öncelikle örnek olarak ethernet kodu içine printk("..") ile bir şeyler yazdırıp, çıktısını dmesg logunda görmek var. Burada Greg Kroah-Hartman ilk yamanın nasıl yapılacağından bahsetmiş. Temel olarak yama göndermeye kernel.org'dan aldığımız çekirdek kodları dizini içerisindeki drivers/staging'den başlayabiliriz. Buradaki kodların yazılış biçimini düzeltmeyle işe başlayabiliriz. Greg'de linkini verdiğim sunumunda bundan bahsetmiş. Çok temel kodlama biçimi düzeltmeleri yapabileceğimiz gibi, daha karma düzeltmeler de yapabiliriz. Bir de yama gönderirken e-posta konu satırına uyarı çıktısının tam halini yazmamız gerekiyor. Kendimiz uyarıyı yorumlayıp "bu yama bunu düzeltiyor" şeklinde yazdıklarımız genelde kabul edilmeyebiliyor. Bu yüzden tekrar göndermemiz gerekiyor.
Opw Kernel'a başvurmak için bu temel yamalardan göndermek yeterli. Hatta bu yılki Opw projelerinden birisi de kodlama biçimi düzeltme ve Todo dosyalarındaki eksikleri kapatma. Todo dosyalarındaki eksikleri kapatmak biraz daha alt seviye, aslında baya bir alt seviye :). Çünkü yapılması istenenler de o kadar açık belirtilmemiş dosyada. Ben de çekirdek uyarı mesajlarını analiz etme ve iyileştirme projesine başvurdum.
Başlangıç olarak Linux Kernel'a kodlama biçimi düzeltme dışında Sparse ve Coccinelle araçlarını kullanarak katkı verebiliriz. Bu araçlarla drivers/staging altındaki kodları derlediğimizde aldığımız uyarı mesajlarına göre düzeltmeler yapabiliriz. Bir de kodlar içerisinde yer alan Fixme etiketlerinden yararlanarak katkı vermek de yapabileceğimiz seçeneklerden birisi. Katkı verirken zorlanabileceğimiz yanlardan birisi, Linux Kernel ekibi kodlama biçimine oldukça önem veriyor. Bu yüzden aynı yamayı defalarca göndermek gerekebiliyor. Hatta kodlama biçimini test etmek için yazdıkları bir Perl betiği var. Zaten kodlama biçimi düzeltme yamalarını gönderebilmek için bu betiği kullanmalıyız.
Sparse aracı ile fonksiyon tiplerinin ya da değişken tiplerinin doğruluğu, gereksiz fonksiyonları kaldırma, tip dönüşüm işlemlerinin doğruluğu gibi uyarıları analiz edebiliriz. Bu düzeltmeleri yapmak için koddaki fonksiyonları okuyup, çağırılma sıralarını kontrol etmek, kzallac, kmalloc, volatile gibi tiplere, tip dönüşümlerine bakmak gerekli. Çeşitli tiplerin ne olduğunu öğrenmek için burayı okumak faydalı olabilir.
Coccinelle aracını ise ben henüz kullanmadım. Ancak önümüzdeki günlerde onu da denemeyi düşünüyorum. Bir de daha karmaşık hataları çözebilmek için bir kitap bulup okumayı düşünüyorum.
Opw ekibi projede çalışmak için kişi seçerken genelde öğrenci olmamasını tercih ediyor :( . Okul dönemi içerisinde olan bir öğrenci seçmektense herhangi bir işte çalışmayan birisini seçmenin daha verimli olacağı düşüncesindeler. Bu yüzden öğrencilerin Opw yaz dönemine başvurunca seçilme ihtimali daha yüksek. Çünkü proje sürecinde bir işin var mı sorusuna, sınav haftalarını yazmaktansa hiç işim yok yazmak, şansımızı artıran bir etken. Eğer ben de bu dönem kabul edilmezsem, yaz dönemi tekrar başvuracağım.
7 Kasım 2013 Perşembe
Çekirdeğe Katkı Sürecinde Git Kullanımı
Git uzaktan birlikte çalışmak için oldukça yetenekli bir araç. Bu dönem Linux Kernel'a katkı verirken git'in daha fazla özelliğini kullanmam gerekti. Çünkü çok fazla kişinin sürekli aynı dosyalar üzerinde değişiklik yapıyor olması durumunda daha gelişmiş bir biçimde sürüm takip sistemi kullanmak gerekiyor.
git-send-mail
Tarayıcı üzerinden yamayı mail gövdesine kopyaladığımızda girintilerde kaymalar, satırlarda kaymalar meydana gelebilir. Bunun için yama dosyasını e-postada ek olarak göndermeliyiz, ya da git-send-mail ile göndermeliyiz. git-send-mail için temel bir kaç ayar gerekli, bu ayarları her seferinde yeniden girmemek için yapılandırma dosyasına yazabiliriz. Ev dizinimizdeki .gitconfig dosyası için gerekli olan ayarları ben buradan örnek alarak ayarlamıştım
git-rebase
Yerelimdeki Linux Kernel deposuyla uzaktaki depoyu senkron tutmam gerekti. Opw Kernel sayfasında bahsedildiği gibi depomda değişiklikler yaptım. Bunun için öncelikle "git remote add" diyerek "staging" adı altında depoyu izlediğim depolar arasına ekledim. Bu şekilde depo ekleyip, deponun istediğimiz dallarını çekebiliriz. Daha sonra "git rebase staging/staging-next" ile rebase işlemini tamamlamış oluyoruz.
Aslında burada aklıma takılan "merge" kullanarak da bir çok şeyi halledemez miyiz, olmuştu. Ancak merge kullandığımızda aynı depo üzerinde çalışan herkesin, her şeyi kusursuz yapmış olmasını beklemek gerekir. Eğer küçük bir ekiple çalışıyorsak "merge" yeterli oluyor.
git-rebase ile aynı zamanda commit tarihimizi değiştirebiliriz, eskiden yaptığımız bir committeki değişiklikleri düzenleyebiliriz. Bunun için "git rebase --interacative commit_id" diyoruz. Bu şekilde rebase etme sürecini başlatabiliriz.
Eğer son yaptığımız committe bir değişiklik yapacaksak "git commit --amend" olarak kullanabiliriz, ancak son committen daha eski commitler üzerinde oynamak için "git rebase --interactive" kullanmalıyız. Daha sonra karşımıza çıkan editörde commit mesajını değiştirmek istediğimiz commitin başındaki "pick" ifadesini "edit" olarak değiştirmeliyiz. Daha sonra "git commit --amend" kullanıp, commit mesajını değiştirmeye başlayabiliriz. Son olarak "git rebase --continue" ile commit mesajı değiştirme sürecini bitirmiş oluruz.
Üzerinde oynadığım büyük bir dosyada 9 tane commit yapmıştım ve bu commitlerde yaptığım değişikliklerin arasından 4-5 tanesini düzeltmem gerekti. Son değişikliklerde öncekilere bağlı olduğundan, dosyanın son hali üzerinden tekrar düzeltip göndersem, dosyanın depodaki orjinali bu değil diye geliştiriciler kabul etmiyorlar. Bu durumda eğer 5. commit değişmeliyse, dosyanın 5. committeki hali üzerinden düzeltmek gerekli. Ya da tüm yama serisini baştan hazırlamalıyız ki, bu zorlaştıran bir iş.
Bu yüzden git rebase'i kullanıp, edit şeklinde committi seçiyoruz. Daha sonra değişiklikleri yapıp "git add üzerinde_çalıştığımız_dosya" ve "git rebase --continue" şeklinde bu işlemi bitirebiliriz. "--continue" parametresini rebase ile yapacağımız değişiklikler bittikten sonra kullanmalıyız.
edit, dışında bir de "squash" ile yaptığımız commitleri birleştirebiliriz. Eğer altı kere değişiklik yapıp bunları hepsini ayrı ayrı commitlediysek format-patch ile oluşturacağımız yamalarda altı parçadan oluşacak. Eğer bunların hepsini tek bir commit mesajı altında birleştirmek istiyorsak "pick" yerine "squash" yazarak bir kaç commit mesajını bir mesajda birleştirmeyi sağlayabiliriz.
17 Eylül 2013 Salı
Kadın Geliştiriciler İçin Gnome Etkinliği
Gnome'un kadınlar için düzenlediği Outreach Program for Women (OPW) etkinlik süreci yaklaşıyor. Bu etkinlik yılda iki kez düzenleniyor. Her hangi bir akademik kısıtlaması olmamakla birlikte 18 yaşından büyük kadınlar katılabilir. Bu etkinlik GSOC gibi, belirli bir süre, bir danışman yardımı ile uzaktan çalışma gerçekleştiriliyor. Eğer projeyi başarılı bir şekilde tamamlarsak karşılığında $5,000 dolar gibi bir burs da alabiliriz.
OPW 2013 yaz döneminde ise Linux Kernel Gnome'un düzenlediği bu etkinliğe katılmaya başladı. Linux Kernel'a katkı vermeye yeni başlayanlar için güzel bir yazı hazırlamışlar. 2013 yaz dönemi Linux Kernel için çok az bakabilme fırsatı bulduğumdan yama gönderemedim. Bu etkinlikler genel olarak sınav dönemine çok yakın bir zamana denk geliyor :) Diğer projelerle birlikte bu etkinliklere katılmak biraz zor olabiliyor. Eğer bu yıl katılırsam Linux Kernel'a kaldığım yerden devam ederim muhtemelen.
Aslında geçen yıl kış dönemi etkinliğine projelere katkı verip katılmıştım. Ancak seçtiğim proje OPW tarafından geliştirilmek için seçilmedi. Yaz döneminde ise çekirdekle ilgili projeler görünce, o daha çok ilgimi çektiğinden ona katkı vermek istedim.
Gnome'un bu staj etkinliğine GSOC kadar geniş ölçüde organizasyon katılmıyor. Bu yüzden proje seçmek için daha az bir alan var. Etkinliğe katılan organizasyonları görmek için buraya bakabilirsiniz.
OPW 2013 yaz döneminde ise Linux Kernel Gnome'un düzenlediği bu etkinliğe katılmaya başladı. Linux Kernel'a katkı vermeye yeni başlayanlar için güzel bir yazı hazırlamışlar. 2013 yaz dönemi Linux Kernel için çok az bakabilme fırsatı bulduğumdan yama gönderemedim. Bu etkinlikler genel olarak sınav dönemine çok yakın bir zamana denk geliyor :) Diğer projelerle birlikte bu etkinliklere katılmak biraz zor olabiliyor. Eğer bu yıl katılırsam Linux Kernel'a kaldığım yerden devam ederim muhtemelen.
Aslında geçen yıl kış dönemi etkinliğine projelere katkı verip katılmıştım. Ancak seçtiğim proje OPW tarafından geliştirilmek için seçilmedi. Yaz döneminde ise çekirdekle ilgili projeler görünce, o daha çok ilgimi çektiğinden ona katkı vermek istedim.
Gnome'un bu staj etkinliğine GSOC kadar geniş ölçüde organizasyon katılmıyor. Bu yüzden proje seçmek için daha az bir alan var. Etkinliğe katılan organizasyonları görmek için buraya bakabilirsiniz.
23 Temmuz 2013 Salı
Yakından Eğitim Projem Nagios Exchange'de Yer Aldı
Nagios Exchange Nagios için yazılan belgeler, eklentiler, Nagios ile birlikte çalışan uygulamaların yer aldığı resmi sistesi. Kaan ile birlikte üzerinde çalıştığım Yakından Eğitim projesi olan nagios-couchbase-plugin'in Nagios Exchange'de yer alması için dün istekte bulundum ve bugün Nagios Exchange'den proje kabul edildi maili aldım :)
Eklenti eğer resmi sayfada yer alırsa daha çok kullanılır ve daha yararlı olur diye düşündüm. Projenin linkine buradan ulaşabilirsiniz.
Eklenti eğer resmi sayfada yer alırsa daha çok kullanılır ve daha yararlı olur diye düşündüm. Projenin linkine buradan ulaşabilirsiniz.
12 Temmuz 2013 Cuma
Chef Server'ın Oluştuğu Bileşenler
Chef Server'da cookbookları depolayabiliriz demiştik, her cookbook'un kendi içeriğindeki dosyalara göre de sunucuları yapılandırabiliriz. Chef istemcileri de Chef sunucusundan nasıl davranması gerektiği bilgisini alır ve ona göre sunucuyu yapılandırır. Chef Server Erlang kullanılarak yazılmıştır ve Chef Server'ın sağladığı hizmetler aşağıdaki bileşenlerle sağlanır:
Bookshelf: Bookshelf ile cookbook dosyalarının depolanması ve workstationdaki cookbookların Chef sunucusuna gönderilmesi sağlanır. Eğer farklı cookbooklar aynı dosyayı içeriyorsa ya da aynı cookbookun farklı sürümlerinde aynı dosyalar varsa Bookshelf bu dosyaları sadece bir kez depolar.
WebUI: Ruby on Rails ile kodlanmış, Chef Server için bir arayüzdür.
Erchef (Erlang API Server): Chef Server için bir API'dir. Bu API hala orjinal Ruby tabanlı Chef Server için uyumludur.
Mesaj Kuyruğu: Mesajlar search indexlerine gönderilirler. RabbitMQ Chef Server'da mesaj kuyruğu olarak için kullanılır.
Nginx: Chef Server için yük dengeleyici (front end load balancer) olarak kullanılan bir sunucudur. Chef Server Api'sine gelen tüm istekler Nginx sayesinde yönlendirilirler.
PostgreSQL: Verileri tutmak için kullanılan depodur.
Bookshelf: Bookshelf ile cookbook dosyalarının depolanması ve workstationdaki cookbookların Chef sunucusuna gönderilmesi sağlanır. Eğer farklı cookbooklar aynı dosyayı içeriyorsa ya da aynı cookbookun farklı sürümlerinde aynı dosyalar varsa Bookshelf bu dosyaları sadece bir kez depolar.
WebUI: Ruby on Rails ile kodlanmış, Chef Server için bir arayüzdür.
Erchef (Erlang API Server): Chef Server için bir API'dir. Bu API hala orjinal Ruby tabanlı Chef Server için uyumludur.
Mesaj Kuyruğu: Mesajlar search indexlerine gönderilirler. RabbitMQ Chef Server'da mesaj kuyruğu olarak için kullanılır.
Nginx: Chef Server için yük dengeleyici (front end load balancer) olarak kullanılan bir sunucudur. Chef Server Api'sine gelen tüm istekler Nginx sayesinde yönlendirilirler.
PostgreSQL: Verileri tutmak için kullanılan depodur.
11 Temmuz 2013 Perşembe
Chef Server'da Knife Kullanımı
Geçen hafta Chef Server kullanımı, cookbook kavramı, cookbookların içerdikleri dosyalar, cookbook kullanma gereksinimi gibi kavramlara baktım. Stajın 4. gününden sonra baya bir hastalandım. Bu sefer midem değil ama ofis biraz serindi sanırım ondan kusma, ateşlenme meydana geldi. Bir kaç gün izin aldım Kaanlardan.
Bu haftada knife ile Chef istemcisi oluşturma, data bag, roller gibi kavramlara baktım. Burada Chef sunucusunu knife eklentisi kullanarak yönetmeden bahsetmiş. İlk önce kendi makinem üzerinde vagrant ile bir sanal makine açıp onun Amazon'daki Chef sunucumuz için bir istemci olmasını sağladık.
Oluşturduğumuz istemci üzerinde bir kaç cookbook çalıştırmak için workstation üzerinde roller tanımladım. Kullanmak istediğimiz cookbook'u "knife cookbook site install cookbook_name" şeklinde workstationdaki Chef deposuna (chef dizini) indirebiliriz. Daha sonra chef/roles içine çalıştırmak istediğimiz cookbooklar içindeki recipe'leri run_list'e ekliyoruz. Bu şekilde istediğimiz kadar istemciye istediğimiz şeyleri tek seferde yaptırabiliriz. İndirdiğimiz cookbookları aynı zamanda Chef sunucumuza "knife cookbook upload --all" şeklinde göndermeliyiz. Yoksa istemci üzerinde cookbookları çalıştıramayız. Eklediğimiz rolü de yüklemeliyiz. Bunu da "knife role from file roles/role.rb" şeklinde yapabiliriz.
Data bag kavramı Chef istemcilerinde kullanıcı oluşturmak için kullanılan, json şeklinde depolanan dosyalardır. users cookbook'u eğer kullanıcılar data bag'de varsa, o kullanıcıları istediğimiz özelliklerde istediğimiz makineye eklememizi sağlar. Burada data bag'e kullanıcı ekleme işleminin nasıl yapılacağından ve json dosyasının nasıl yazılması gerektiğinden bahsetmiş. Workstation'daki chef/databags/users dizini altında istediğimiz kullanıcıları tanımlayıp, "knife data bag from file kaan.json" şeklinde kullanıcıyı data bag'e ekleyebiliriz.
Bu haftada knife ile Chef istemcisi oluşturma, data bag, roller gibi kavramlara baktım. Burada Chef sunucusunu knife eklentisi kullanarak yönetmeden bahsetmiş. İlk önce kendi makinem üzerinde vagrant ile bir sanal makine açıp onun Amazon'daki Chef sunucumuz için bir istemci olmasını sağladık.
Oluşturduğumuz istemci üzerinde bir kaç cookbook çalıştırmak için workstation üzerinde roller tanımladım. Kullanmak istediğimiz cookbook'u "knife cookbook site install cookbook_name" şeklinde workstationdaki Chef deposuna (chef dizini) indirebiliriz. Daha sonra chef/roles içine çalıştırmak istediğimiz cookbooklar içindeki recipe'leri run_list'e ekliyoruz. Bu şekilde istediğimiz kadar istemciye istediğimiz şeyleri tek seferde yaptırabiliriz. İndirdiğimiz cookbookları aynı zamanda Chef sunucumuza "knife cookbook upload --all" şeklinde göndermeliyiz. Yoksa istemci üzerinde cookbookları çalıştıramayız. Eklediğimiz rolü de yüklemeliyiz. Bunu da "knife role from file roles/role.rb" şeklinde yapabiliriz.
Data Bag
Environment
Her Chef organizasyonunun varsayılan ortamı (environment) _default'tur. Environment kavramı ortamları ayırmak için kullanılır. Workstationdaki chef/environments dizini altına tanımladığımız ortamın özelliklerini (cookbook sürümleri gibi) environment_name.json şeklinde kaydedip gene knife kullanarak istediğimiz istemci için bu ortamı kullanabiliriz.
LWRPs
LWRPs (Lightweight resources and recipes) Chef'te paket yükleme, servis başlatma gibi işlemler için kullanılır. Benim de sunucular üzerinde işlem yaptırırken kendim bu gibi işlemleri tanımlamam gerekecek.
3 Temmuz 2013 Çarşamba
Vagrant, Chef Solo, Chef Server ile Sunucu Yönetimi
Bu yaz stajı 2 sistem yöneticisinin yanında yapıyorum. Öğreneceğim teknolojiler de gene sunucu bakımı, yönetimi üzerine olacak. Şuan çok fazla bilmediğim kavram olduğu için bir süreyi kavramları öğrenmeye, temel bir kaç deneme yapmaya ayırdık. Kullanmam gereken şeyler arasında tek bildiğim şey Ruby, kullanacağım diğer her şeyi ben de daha önce kullanmadım. Zaten on tane makine açayım onları yapılandıran betikler yazayım gibi bir düşüncesi olmuyor insanın durup dururken :)
Dün Kaan kendi kullandıkları teknolojilerden bahsetti. Yeni duyduğum, öğrendiğim şeyler karşısında verdiğim standart tepki olarak "insanlar biliyorlar, insanlar yapıyorlar" oldu :)
Çalışmaya önce Vagrant ile başladım. Vagrant sanal makine açarken istediğimiz özellikleri daha rahat verebildiğimiz bir araç. Örneğin ram ayarlarını bir Vagrantfile içerisinden makineyi ilk oluştururken yapabiliyoruz. Komut satırından yönetim yaptığımız için hızlı.
Chef solo kullanımı ilk Vagrantfile içerisinden yaptım. Vagrantfile içerisinden çalıştırılması gereken cookbookları tanımlayabiliyoruz. Bu şekilde Chef sunucusu, Chef istemcisi gibi konulara bakmadan temel bir cookbook çalışmasını ve dosyalarını inceleyebiliriz. Cookbooklar ise Chef'teki makinelerin nasıl çalışacağının adımları tanımlayan dosyalardan oluşuyor. Biraz Couchbase cookbookunun kodunu incelemiştim. Burada temel bir cookbook yapmışlar. Çalıştırıp denemedim henüz ama belgesinde Couchbase kurulumu ve yapılandırması sağladığı yazıyor, ama Couchbase'de yapılan diğer işlere destek vermiyor. Cookbooklar da temel olarak aşağıdaki işlemler sağlanabiliyor:
1) Düğüm (node) üzerindeki temel ayarlar
2) Dosya dağılımları
3) Versiyon kısıtlamaları, desteklediği platformlar
4) Recipes dizini içerisindeki dosyaların hangi tarife göre çalıştırılacağı
Cookbooklarda karşımıza çıkan kavramlardan kaynaklar (resources) ve sağlayıcı (provider) ise şu şekilde: Kaynaklar, Chef farklı görevler için çalışırken (paket yükleme, dosya sistemine erişme, servis çalışabilir durumda mı, hangi kullanıcı, hangi grup için, dosyaların nereye kopyalanacağı gibi) hangi sağlayıcının kullanılacağını söyler. Çünkü her kaynak bir sağlayıcı ile ilişkilendirilmiştir. Sağlayıcı ise bu çalışma işlemlerini sağlar. Yani sağlayıcı, kaynaktaki adımları tanımlar. Örneğin paket yüklemesinde "apt_package" kaynağı apt kullanan sistemler için yükleme yapar, bu kaynağın yapabileceği işlemler ise install, remove, upgrade gibi "action" kavramı olarak tanımlı. Bu temel örnekteki gibi cookbooklar içerisinde istediğimiz işlemleri sırayla işletebiliriz.
Chef ise sunucuları yerleştirmeyi yönetmeyi sağlayan bir alt yapıdır ve bu yönetim cookbooklar ile sağlanır. Her makinenin kendi platformuna uygun ve isteniyorsa aynı özelliklere sahip olması sağlanır. Chef'te kullanılan kavramlar ise sunucu, çalışma alanı, ve düğümler.
Çalışma alanı denilen kavram cookbookların konumudur. Ve her düğüm ihtiyaçlarına göre bir Chef istemcisi içerir.
Son olarak knifedan da bahsedeyim. Knife, Chef üzerinde işlem yapmak için kullanılan bir araç. Chef sunucusu kurulumunu ve kullanımını kolaylaştırıyor. Ben ilk olarak Chef'i depodan indirip yapılandırmak istedim, ancak İşbaran karşı çıktı, ben biraz direndim, derken knife ile kurulum sağladık. Çünkü knife ile kurulum gerçekten daha kolay oluyormuş. Bize kurulum sırasında çeşitli seçenekler sunuyor, ve dosyaları gerekli yerlere kendisi kopyalıyor.
Dün Kaan kendi kullandıkları teknolojilerden bahsetti. Yeni duyduğum, öğrendiğim şeyler karşısında verdiğim standart tepki olarak "insanlar biliyorlar, insanlar yapıyorlar" oldu :)
Çalışmaya önce Vagrant ile başladım. Vagrant sanal makine açarken istediğimiz özellikleri daha rahat verebildiğimiz bir araç. Örneğin ram ayarlarını bir Vagrantfile içerisinden makineyi ilk oluştururken yapabiliyoruz. Komut satırından yönetim yaptığımız için hızlı.
Chef solo kullanımı ilk Vagrantfile içerisinden yaptım. Vagrantfile içerisinden çalıştırılması gereken cookbookları tanımlayabiliyoruz. Bu şekilde Chef sunucusu, Chef istemcisi gibi konulara bakmadan temel bir cookbook çalışmasını ve dosyalarını inceleyebiliriz. Cookbooklar ise Chef'teki makinelerin nasıl çalışacağının adımları tanımlayan dosyalardan oluşuyor. Biraz Couchbase cookbookunun kodunu incelemiştim. Burada temel bir cookbook yapmışlar. Çalıştırıp denemedim henüz ama belgesinde Couchbase kurulumu ve yapılandırması sağladığı yazıyor, ama Couchbase'de yapılan diğer işlere destek vermiyor. Cookbooklar da temel olarak aşağıdaki işlemler sağlanabiliyor:
1) Düğüm (node) üzerindeki temel ayarlar
2) Dosya dağılımları
3) Versiyon kısıtlamaları, desteklediği platformlar
4) Recipes dizini içerisindeki dosyaların hangi tarife göre çalıştırılacağı
Cookbooklarda karşımıza çıkan kavramlardan kaynaklar (resources) ve sağlayıcı (provider) ise şu şekilde: Kaynaklar, Chef farklı görevler için çalışırken (paket yükleme, dosya sistemine erişme, servis çalışabilir durumda mı, hangi kullanıcı, hangi grup için, dosyaların nereye kopyalanacağı gibi) hangi sağlayıcının kullanılacağını söyler. Çünkü her kaynak bir sağlayıcı ile ilişkilendirilmiştir. Sağlayıcı ise bu çalışma işlemlerini sağlar. Yani sağlayıcı, kaynaktaki adımları tanımlar. Örneğin paket yüklemesinde "apt_package" kaynağı apt kullanan sistemler için yükleme yapar, bu kaynağın yapabileceği işlemler ise install, remove, upgrade gibi "action" kavramı olarak tanımlı. Bu temel örnekteki gibi cookbooklar içerisinde istediğimiz işlemleri sırayla işletebiliriz.
Chef ise sunucuları yerleştirmeyi yönetmeyi sağlayan bir alt yapıdır ve bu yönetim cookbooklar ile sağlanır. Her makinenin kendi platformuna uygun ve isteniyorsa aynı özelliklere sahip olması sağlanır. Chef'te kullanılan kavramlar ise sunucu, çalışma alanı, ve düğümler.
Çalışma alanı denilen kavram cookbookların konumudur. Ve her düğüm ihtiyaçlarına göre bir Chef istemcisi içerir.
Son olarak knifedan da bahsedeyim. Knife, Chef üzerinde işlem yapmak için kullanılan bir araç. Chef sunucusu kurulumunu ve kullanımını kolaylaştırıyor. Ben ilk olarak Chef'i depodan indirip yapılandırmak istedim, ancak İşbaran karşı çıktı, ben biraz direndim, derken knife ile kurulum sağladık. Çünkü knife ile kurulum gerçekten daha kolay oluyormuş. Bize kurulum sırasında çeşitli seçenekler sunuyor, ve dosyaları gerekli yerlere kendisi kopyalıyor.
29 Haziran 2013 Cumartesi
UNIX Manual Page Editor: RManEdit
RManEdit is a editor to prepare man page. I used Ruby & Gtk for RManEdit. RManEdit has many features like other editors. You can get more information from here.
27 Haziran 2013 Perşembe
Nagios plugin to monitor Couchbase
I've created CouchBase plugin for Nagios. I used Python for plugin. I put plugin in Github. You can access here. Nagios Plugin Couchbase is available under the GPLv3. Your suggestions and feedbacks will be valued and highly appreciated.
Nagios plugin couchbase supply to monitor a lot of summary statistics:
Cache miss ratio, creates per second, disk read, high and low watermark, set per second, memory usage, operations per second.. etc.
You can monitor vbucket resources with option "--vbucket". You can see all option using "--help" parameter and you should read from Readme for more information about usage. And a screenshot:
Nagios plugin couchbase supply to monitor a lot of summary statistics:
Cache miss ratio, creates per second, disk read, high and low watermark, set per second, memory usage, operations per second.. etc.
You can monitor vbucket resources with option "--vbucket". You can see all option using "--help" parameter and you should read from Readme for more information about usage. And a screenshot:
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 :)
31 Mart 2013 Pazar
Konsolda Eğlenceli Şekiller Yapmak
Bu ara aklıma takıldı konsolda farklı araçlarla eğlenceli görseller yapılabiliyordu. Aslında ssh için parola girdiğimde randomart ile ekranda gördüğüm görselde aklıma geldi. Bunun için öncelikle
#apt-get install cowsay xcowsay
diyoruz. cowsay karakterlerden oluşan görsel için xcowsay ise resimli olan görüntü için. cowsay kullanarak yapılabilecek belli başlı görseller şu şekilde:
$cowsay hello
$cowsay -f gnu bir gnu :\)
dediğimizde ise ekranda gnu resmi görüyoruz. Burada ben ":)" ifadesini bu şekilde kullandığımda ')' karakteri için beklenmeyen ifade gibi bir değer döndürdü. Bu yüzden '\' karakteri ile yazdım.
$cowsay -f /usr/share/cowsay/cows/turtle.cow çok yavaşım :\)
şeklinde de görüntü elde edebiliriz. "/usr/share/cowsay/cows/" dizini altında görüntüleyebileceğimiz şekillerin listesini görebiliriz.
$xcowsay --think mesaj
şeklinde daha fiyakalı bir görüntü elde edebiliriz.
Buradaki --think parametresi konuşmadaki baloncuklar için.
Eğer önümüzden bir tren geçsin istiyorsak da "sudo apt-get install sl" diyoruz :). sl komutunun parametreleri oldukça az, aslında cowsay'in de alabileceği çok fazla parametsi yok.
Bunlar gibi benzer işler yapan bir kaç farklı araçla daha konsolda eğlenceli görseller elde edebiliriz.
#apt-get install cowsay xcowsay
diyoruz. cowsay karakterlerden oluşan görsel için xcowsay ise resimli olan görüntü için. cowsay kullanarak yapılabilecek belli başlı görseller şu şekilde:
$cowsay hello
$cowsay -f gnu bir gnu :\)
dediğimizde ise ekranda gnu resmi görüyoruz. Burada ben ":)" ifadesini bu şekilde kullandığımda ')' karakteri için beklenmeyen ifade gibi bir değer döndürdü. Bu yüzden '\' karakteri ile yazdım.
$cowsay -f /usr/share/cowsay/cows/turtle.cow çok yavaşım :\)
şeklinde de görüntü elde edebiliriz. "/usr/share/cowsay/cows/" dizini altında görüntüleyebileceğimiz şekillerin listesini görebiliriz.
$xcowsay --think mesaj
şeklinde daha fiyakalı bir görüntü elde edebiliriz.
Buradaki --think parametresi konuşmadaki baloncuklar için.
Eğer önümüzden bir tren geçsin istiyorsak da "sudo apt-get install sl" diyoruz :). sl komutunun parametreleri oldukça az, aslında cowsay'in de alabileceği çok fazla parametsi yok.
Bunlar gibi benzer işler yapan bir kaç farklı araçla daha konsolda eğlenceli görseller elde edebiliriz.
Couchbase Nagios Plugin
Yakından Eğitim projelerinden Couchbase Nagios Plugin'e başvuru yaptım. Başvuru sürecinde yapmamız gerekenler burada belirtilmişti. Ben de cv'mi ve gereken soruları yanıtlayıp başvuru mailimi gönderdim. Bir zaman sonra başvuru sonuçları açıklandı. Kabul edildiğimi öğrendim.
Projeye başvuru nedenim aslında Necdet hoca önermişti Nagios Plugin'e başvurmamı. Eğer severek yapmayacağın bir iş olacaksa başvurma dedi. Twitterdaki tweetleri gözümde canlandırabiliyorum demişti :) Kaan'la çalışmak benle çalışmaktan daha eğlencelidir diye de belirtmişti (aslında Necdet hocayla çalışmak da çok eğlenceli bence). Ben birkaç akşam proje nasılmış, bu süreçte neler öğrenmem gerekecek diye bir kaç belge baktım. Çünkü NoSql'in sadece adını duymuştum daha önce kullanmadım. Sonrasında aklıma yatınca başvurmaya karar verdim. Aslında genelde bir işe başlarken seçme nedenlerim içinde bilmediğim şeyler olsun ve sıkılarak yapmayayım oluyor. Başvuru sorularını yanıtlarken de belirtmiştim bilmediğim işler ufkumu açıyor, bu şekilde ne üzerinde çalışmak isteyeceğim hakkında görüş alanımı genişletmeye çalışıyorum diye.
Projelerde çabuk sıkılma gibi bir eksi yanımda vardı eskiden ama artık daha geç sıkılıyorum bir iş uzarsa. Zaten yazılımda da yaptım bitti şeklinde değilde hep geliştirme ve bakım isteyen işler oluyor. Nagios Plugin'de de bu şekilde. Başvuru yapmadan önce okuduğum yazıda da proje bittikten sonra projenin gelişimine devam edilmesi gerektiği belirtilmişti. Başvuru yaptıktan sonra kimin seçileceği henüz belli değilken danışmanıma mail attım nelere bakmam faydalı olur konusunda. Kabul edilmek için danışmanlar genelde başvuru sürecinde başvuranlardan projeyle ilgili bir şeyler yapmasını istiyorlar. Danışmanım Nagios'u kur, çalıştır bak demişti. Bunun için belge önerdi bunları okuyabilirsin diye, ben de ek bir kaç yerden daha okumuştum, sonra kurup çalıştırdım. Kurulumla ilgili blog yazmamı istemişti. Bir kaç gün sonrasında zaten başvuru sonuçları açıklandı. Kabul edilmesem bile Nagios'un nasıl kurulup çalıştırıldığı hakkında bilgi edinmiş olacaktım.
Önümüzdeki 2 aylık süreçte projeyi geliştiriyor olacağım. Ayrıca her hafta freenode #yakından eğitim kanalında projelerin durumu hakkında konuşuyoruz. Ben de proje üzerinde bir şeyler yaptıkça, danışmanımın yönlendirmesi ile bu konuda yazmaya devam edeceğim.
Projeye başvuru nedenim aslında Necdet hoca önermişti Nagios Plugin'e başvurmamı. Eğer severek yapmayacağın bir iş olacaksa başvurma dedi. Twitterdaki tweetleri gözümde canlandırabiliyorum demişti :) Kaan'la çalışmak benle çalışmaktan daha eğlencelidir diye de belirtmişti (aslında Necdet hocayla çalışmak da çok eğlenceli bence). Ben birkaç akşam proje nasılmış, bu süreçte neler öğrenmem gerekecek diye bir kaç belge baktım. Çünkü NoSql'in sadece adını duymuştum daha önce kullanmadım. Sonrasında aklıma yatınca başvurmaya karar verdim. Aslında genelde bir işe başlarken seçme nedenlerim içinde bilmediğim şeyler olsun ve sıkılarak yapmayayım oluyor. Başvuru sorularını yanıtlarken de belirtmiştim bilmediğim işler ufkumu açıyor, bu şekilde ne üzerinde çalışmak isteyeceğim hakkında görüş alanımı genişletmeye çalışıyorum diye.
Projelerde çabuk sıkılma gibi bir eksi yanımda vardı eskiden ama artık daha geç sıkılıyorum bir iş uzarsa. Zaten yazılımda da yaptım bitti şeklinde değilde hep geliştirme ve bakım isteyen işler oluyor. Nagios Plugin'de de bu şekilde. Başvuru yapmadan önce okuduğum yazıda da proje bittikten sonra projenin gelişimine devam edilmesi gerektiği belirtilmişti. Başvuru yaptıktan sonra kimin seçileceği henüz belli değilken danışmanıma mail attım nelere bakmam faydalı olur konusunda. Kabul edilmek için danışmanlar genelde başvuru sürecinde başvuranlardan projeyle ilgili bir şeyler yapmasını istiyorlar. Danışmanım Nagios'u kur, çalıştır bak demişti. Bunun için belge önerdi bunları okuyabilirsin diye, ben de ek bir kaç yerden daha okumuştum, sonra kurup çalıştırdım. Kurulumla ilgili blog yazmamı istemişti. Bir kaç gün sonrasında zaten başvuru sonuçları açıklandı. Kabul edilmesem bile Nagios'un nasıl kurulup çalıştırıldığı hakkında bilgi edinmiş olacaktım.
Önümüzdeki 2 aylık süreçte projeyi geliştiriyor olacağım. Ayrıca her hafta freenode #yakından eğitim kanalında projelerin durumu hakkında konuşuyoruz. Ben de proje üzerinde bir şeyler yaptıkça, danışmanımın yönlendirmesi ile bu konuda yazmaya devam edeceğim.
30 Mart 2013 Cumartesi
Sistemi Single User Modda Açma
Bu dönemin başlarında minik bilgisayarıma Fedora kurmuştum. Miniği çok az kullanıyorum. Bir zaman sonra bilgisayarı tekrar açınca buna chrome kursam da firefox kullanmasam dedim. Baktım ki kendime sudo yetkileri vermemişim ve root parolamı da hatırlamıyorum.
Bu yüzden bilgisayarı single user modunda açma gereği duydum. Bunu geçen yaz nette bir şeyler okurken single user modda başlatınca root yetkileri direkt veriliyormuş şeklinde okumuştum. Aslında single user mod, init 1 seviyesi oluyor. Bu seviyede herhangi bir ağ bağlantısı ve grafik ekran olmadan sistemi kullanıyorsunuz.
Sistemi single user mod seviyesinde açmak için grub ekranından Fedora seçiliyken 'e' tuşuna bastım. Zaten açılış ekranında alt kısımda da 'e', 'c' gibi seçenekler belirtilmiş. Sonra çekirdeğin bulunduğu satırın en sonuna (vmlinuz ile başlayan satır) '1' yazdım. ctrl+x ile çıkış yapıp, sistem başladğında root yetkilerime kavuşmuştum :)
Daha sonra ekrana gelen root yetkileri verilmiş konsolda 'passwd' komutuyla root parolamı değiştirmiş oldum.
23 Mart 2013 Cumartesi
Nagios Kurulumu ve Kullanımı
Nagios kullanarak bir makinenin üzerindeki bellek, işlemci gibi yerel kaynakları ya da vermiş olduğu smtp, mysql gibi servisleri izleyebiliriz. Ayrıca bu servislerin durumlarıyla ilgili kullanıcıya mail, sms gibi yollarla uyarıyı verebiliriz. Nagios ağ üzerinden servis ya da kaynak dinleme işlemini çeşitli eklentileri (plugin) kullanarak yapar. Nrpe'de bu sistem kaynaklarını dinlemek için kullanılan bir eklentidir. Nrpe kaynakları izlenecek olan makineye kurulur.
Kurulum
Kurulum için nagiosu ana makineye nrpe'yi ise kaynakları izlenecek olan makineye kurmamız gerekir. Nagios kurulumunu aşağıdaki gibi her iki makinede yapalım.
Ayrıca nagiosta çalıştırabileceğimiz komutların listesi /usr/lib/nagios/plugin dizini altındadır. Oradaki komutların alabilecekleri parametreleri aşağıdaki gibi --help parametresiyle görüntüleyebilirsiniz.
Kurulum
Kurulum için nagiosu ana makineye nrpe'yi ise kaynakları izlenecek olan makineye kurmamız gerekir. Nagios kurulumunu aşağıdaki gibi her iki makinede yapalım.
# apt-get install nagios3 nagios-nrpe-server nagios-nrpe-pluginKurulumdan sonra web arayüzünden izleme yapabilmek için aşağıdaki gibi kullanıcı oluşturmalıyız
sudo htpasswd -c /etc/nagios3/htpasswd.users nagiosadminŞimdi nrpe ile başka bir makinanın yerel kaynak durumlarını izleyelim. Bunun için /etc/nagios3 dizini altında ubuntu_remote.cfg adında bir dosya oluşturalım. Bunun içine yapmamız gereken tanımlamalar şu şekilde:
# host tanimlamasi define host{ use generic-host # tum host tanimlamalarinda olmasi zorunlu host_name Ubuntu2 alias Ubuntu2Alias address ip_adres # dinleyecegimiz makine ip } # nrpeyi tanimliyoruz define command{ command_name check_nrpe command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -c $ARG1$ } # izlemek istedigimiz kaynak define service{ use generic-service # tum servis tanimlamalarinda olmasi zorunlu host_name Ubuntu2 service_description Current Users check_command check_nrpe!check_users }/etc/nagios3/conf.d/ dizini altındaki hostgroups_nagios2.cfg dosyasında aşağıdaki gibi tanımladığımız host ismini referans vermeliyiz.
define hostgroup {
hostgroup_name ubuntu-servers
alias Ubuntu GNU/Linux Servers
members localhost, Ubuntu2
}
/etc/nagios.cfg dosyasında da tanımladığımız ubuntu_remote.cfg dosyasının yolunu "cfg_file=/etc/nagios3/ubuntu_remote.cfg" şeklinde belirtmeliyiz. Aynı zamanda kaynaklarını dinleyeceğimiz makinede /etc/nagios/ dizini altındaki nrpe.cfg dosyasında sunucu makinenin ip adresini "allowed_host=nagios_server_ip" olarak belirtmeliyiz. Daha sonra nagios ve nagios-nrpe-server süreçlerini yeniden başlatalım./etc/init.d/nagios3 restart /etc/init.d/nagios-npre-server restartTarayıcıda localhost/nagios3 adresiyle yerelimizde karşıdaki makinenin durumlarını kontrol edebiliriz.
Ayrıca nagiosta çalıştırabileceğimiz komutların listesi /usr/lib/nagios/plugin dizini altındadır. Oradaki komutların alabilecekleri parametreleri aşağıdaki gibi --help parametresiyle görüntüleyebilirsiniz.
/usr/lib/nagios/plugin/check_disk --help
14 Mart 2013 Perşembe
Açık Anahtarlı Şifreleme & GPG
Bu dönem okuldaki seçmeli dersler arasından Kriptoloji seçtim. Derste çeşitli şifreleme algoritmaları gördük. Sezar, Vigenere, Kerberos gibi.
Şifreleme işlemlerinde temel kaygı şifreleme yapan anahtar ve deşifreleme yapan anahtar aynı olduğu zamanlarda birisi anahtarı ele geçirirse, şifreli metni deşifreleyebileceğidir. Yani bu durumda en başta anahtarın güvenliğinin sağlanması gerekir. Açık anahtarlı şifreleme algoritmalarında ise bu probleme çözüm olarak bir anahtar ya sadece şifreleyebilsin, ya da sadece deşifreleyebilsin olmuştur. Biz de geçen hafta derste açık anahtarlı şifreleme algoritmalarından biri olan RSA'yı işledik. Bu işlemde kişi kendi belirlediği iki asal sayıyı belirli işlemlerden geçirip bir açık anahtar bir de gizli anahtar üretmektir. Açık anahtarı kendisine şifreli metin gönderilebilmesi için herkese verir. Sonra kendisine gelen şifreli metinleri kendi gizli anahtarı ile açar.
Bu şekilde açık ve gizli anahtarlar oluşturmak için çeşitli araçlar vardır. E-posta istemcileri, Seahorse gibi. Ben burada terminalden gpg ile gizli ve açık anahtarın nasıl üretibileceğinden bahsettim. gpg zaten dağıtımlarda genelde kurulu geliyor. Bu arada GPG (GNU Privacy Guard), GPL ile lisanslanmış bir şifreleme yazılımı.
Terminalden aşağıdaki gibi parametresiyle gpg komutunu verelim:
$ gpg --gen-key
gpg (GnuPG) 1.4.11; Copyright (C) 2010 Free Software Foundation,Inc. This is free
software: you are free to change and redistribute it. There is NO WARRANTY, to the
extent permitted by law.
Şifreleme işlemlerinde temel kaygı şifreleme yapan anahtar ve deşifreleme yapan anahtar aynı olduğu zamanlarda birisi anahtarı ele geçirirse, şifreli metni deşifreleyebileceğidir. Yani bu durumda en başta anahtarın güvenliğinin sağlanması gerekir. Açık anahtarlı şifreleme algoritmalarında ise bu probleme çözüm olarak bir anahtar ya sadece şifreleyebilsin, ya da sadece deşifreleyebilsin olmuştur. Biz de geçen hafta derste açık anahtarlı şifreleme algoritmalarından biri olan RSA'yı işledik. Bu işlemde kişi kendi belirlediği iki asal sayıyı belirli işlemlerden geçirip bir açık anahtar bir de gizli anahtar üretmektir. Açık anahtarı kendisine şifreli metin gönderilebilmesi için herkese verir. Sonra kendisine gelen şifreli metinleri kendi gizli anahtarı ile açar.
Bu şekilde açık ve gizli anahtarlar oluşturmak için çeşitli araçlar vardır. E-posta istemcileri, Seahorse gibi. Ben burada terminalden gpg ile gizli ve açık anahtarın nasıl üretibileceğinden bahsettim. gpg zaten dağıtımlarda genelde kurulu geliyor. Bu arada GPG (GNU Privacy Guard), GPL ile lisanslanmış bir şifreleme yazılımı.
Terminalden aşağıdaki gibi parametresiyle gpg komutunu verelim:
$ gpg --gen-key
gpg (GnuPG) 1.4.11; Copyright (C) 2010 Free Software Foundation,Inc. This is free
software: you are free to change and redistribute it. There is NO WARRANTY, to the
extent permitted by law.
Please select what kind of key you want:
(1) RSA and RSA (default)
(2) DSA and Elgamal
(3) DSA (sign only)
(4) RSA (sign only)
Your selection? 1
Burada RSA'yı seçip diğer sorularıda geçtikten sonra karşımıza anahtarların üretilmesi için şöyle bir yazı çıkacak:
We need to generate a lot of random bytes. It is a good idea to perform some other action
(type on the keyboard, move the mouse, utilize the disks) during the prime generation;
this gives the random number generator a better chance to gain enough entropy.
Ben bu işlem için "ls -R /" diyorum :) Sonra bir yerde kesiyorum tabi listelemeyi. Anahtarlar üretildikten sonra anahtarların parmak izi bilgisini ekranda görebiliriz.
Aslında gpg daha bir çok kullanışlı parametreye sahip. Çok da sevdim kendisini. Ama ben burada bu kadar bahsedebildim. Afiyet olsun :)
(1) RSA and RSA (default)
(2) DSA and Elgamal
(3) DSA (sign only)
(4) RSA (sign only)
Your selection? 1
Burada RSA'yı seçip diğer sorularıda geçtikten sonra karşımıza anahtarların üretilmesi için şöyle bir yazı çıkacak:
We need to generate a lot of random bytes. It is a good idea to perform some other action
(type on the keyboard, move the mouse, utilize the disks) during the prime generation;
this gives the random number generator a better chance to gain enough entropy.
Ben bu işlem için "ls -R /" diyorum :) Sonra bir yerde kesiyorum tabi listelemeyi. Anahtarlar üretildikten sonra anahtarların parmak izi bilgisini ekranda görebiliriz.
Key fingerprint = D9F2 4673 D60E 47EE EB46 1BB3 1EDE B418 711C B3B7
uid Ebru Akagunduz (Açıklama)
sub 2048R/07684591 2013-03-14
Daha sonra bir dosyadaki metni aşağıdaki gibi açık anahtarımızla "--encrypt" diyerek şifreleyebiliriz.
$ gpg --encrypt -r ebru.akagunduz@gmail.com duzmetin.txtAçarken de "--decrypt" parametresini kullansak yeterli olur.
$ gpg -ao public.key --export 711CB3B7Açık anahtarı elde etmek için
$ gpg -ao private.key --export-secret-keys 711CB3B7Gizli anahtarı elde etmek için kullanılır. Burada -a parametresi düz metin formatında almak için, -o parametresi de dosyaya yazıdrmak için kullanılır.
Aslında gpg daha bir çok kullanışlı parametreye sahip. Çok da sevdim kendisini. Ama ben burada bu kadar bahsedebildim. Afiyet olsun :)
2 Mart 2013 Cumartesi
LPI 101 Sınavı Hakkında
1. dönem okulda açılan seçmeli ders olan Linux ile Sistem Yönetimi dersini aldım. Necdet hoca derste LPI 101 içeriklerini anlatmıştı. LPI (Linux Proffesional Institute), Linux bilgilerimizi ölçmek için tüm dünyada geçerli olan standartları içermektedir. LPI hakkında ayrıntılı bilgiyi LPI Türkiye sayfasından edinebilirsiniz.
Bu yıl ara tatilde Necdet hoca LPI 101 sınavının yapılacağını bize bildirdi. Aslında dersi alırken zaten dönem başında bize bunu söylemişti. Ara tatilde hep birlikte sınav tarihi belirledik. Sonra iki hafta öncesinde de sınav yaklaştığı için konuları bir de birlikte takip edersek daha iyi olur dedi. Bunun için tüm 101 konularını baştan taradık. Haftada iki gün 4-5 saat kadar birbirimize LPI 101 konularını anlattık. Aslında çalışmamız şu şekilde oldu, çalışma günlerimizde ortak bir konu belirleyip, o konuya hepimiz çalışıyorduk. Her konu için bir kişiyi o konuyu hepimize anlatması için atıyorduk. Bu şekilde sınava girmeyecek olan arkadaşlar da dinleme imkanı buldular.
Bugün de 101 sınavına girdik. Sınavı Türkiye LPI sorumlusu olan İsmail Yenigül yaptı. Sınava girmeden önce arkadaşlarımla biraz gergindik. Çünkü eğer yapılsa inanılmaz zor bir sınav yapılabilir, gerçi bu her sınav için böyledir. Sınav genel olarak çok zor değildi. Kimi sorular biraz dikkat istiyordu. Sınavdan önce aklıma gelmeyen bir kaç soruda vardı aslında.
Sınavdan sonra İsmail Yenigül ve Barış Şimşek ile sohbet etme fırsatı bulduk. Onların bize kendi üniversite deneyimlerinden, sektörden, bir işi iyi bilmenin öneminden bahsettikleri çok yararlı gördüğüm bir konuşma ile günü bitirdik :)
Bu yıl ara tatilde Necdet hoca LPI 101 sınavının yapılacağını bize bildirdi. Aslında dersi alırken zaten dönem başında bize bunu söylemişti. Ara tatilde hep birlikte sınav tarihi belirledik. Sonra iki hafta öncesinde de sınav yaklaştığı için konuları bir de birlikte takip edersek daha iyi olur dedi. Bunun için tüm 101 konularını baştan taradık. Haftada iki gün 4-5 saat kadar birbirimize LPI 101 konularını anlattık. Aslında çalışmamız şu şekilde oldu, çalışma günlerimizde ortak bir konu belirleyip, o konuya hepimiz çalışıyorduk. Her konu için bir kişiyi o konuyu hepimize anlatması için atıyorduk. Bu şekilde sınava girmeyecek olan arkadaşlar da dinleme imkanı buldular.
Bugün de 101 sınavına girdik. Sınavı Türkiye LPI sorumlusu olan İsmail Yenigül yaptı. Sınava girmeden önce arkadaşlarımla biraz gergindik. Çünkü eğer yapılsa inanılmaz zor bir sınav yapılabilir, gerçi bu her sınav için böyledir. Sınav genel olarak çok zor değildi. Kimi sorular biraz dikkat istiyordu. Sınavdan önce aklıma gelmeyen bir kaç soruda vardı aslında.
Sınavdan sonra İsmail Yenigül ve Barış Şimşek ile sohbet etme fırsatı bulduk. Onların bize kendi üniversite deneyimlerinden, sektörden, bir işi iyi bilmenin öneminden bahsettikleri çok yararlı gördüğüm bir konuşma ile günü bitirdik :)
25 Şubat 2013 Pazartesi
Man Sayfası Hazırlama Editörü: RManEdit
RManEdit Ruby ve Gtk kullanarak yazdığım bir özgür yazılım. İlk sürümü hazır, kodları github'ta. Uygulama hakkında öneri, hata bildirimi gibi katkılarınızdan oldukça memnun olurum.
Bu arada RManEdit'i yazarken aslında ne kadar mutsuz olduğumdan da bahsetmeden geçmeyeyim ;) Geçen dönem midemden rahatsızdım, bu yüzden istediğim verimle çalışamayıp çok mutsuz olmuştum. Onun mutsuzluğu kışın tatilde de devam ediyordu. Bu yüzden RManEdit'in logosu üzülmüş sima içeren bir şeyler olsun diye Necdet Hoca'ya çok ısrar etmiştim ama kabul ettiremedim tabi ;)
29 Ocak 2013 Salı
Webkit, Gtk & Ruby
Bu ara Ruby ile kodlamaya geri döndüm. Yaptığım uygulamada bir html sayfasını pencerede görüntülemem gerekti. Bunun için webkit kullandım. Webkit kurulumunda biraz problem oluştu. Normalde "gem install gtk-webkit-ruby" şeklinde kurabilmemiz gerekir. Ancak benim aldığım hata şu şekilde oldu:
Building native extensions. This could take a while...
ERROR: Error installing gtk-webkit-ruby:
ERROR: Failed to build gem native extension.
/usr/bin/ruby1.9.1 extconf.rb
Hatayı nette aradım ancak çözüm bulamadım. Bazı yerlerde şu kütüphaneler eksiktir yazıyordu ancak ben hepsini kurmuştum. Sonra Ruby ile ilgili bir forumda bu sorunu belirttim. Forumdan ilk aldığım cevap eksik kütüphaneler vardır oldu. Ama gereken ek araçları kurmuştum. Sonra kullandığım dağıtım, Ruby sürümü, mkmf.log dosyası gibi ek bilgiler verdim. Aslında mkmf.log dosyasına ben de bakmıştım ama içeriği bana hatayı çözecek kadar anlamlı gelmemişti. Sonra forumdan gem install -v 0.005 gtk-webkit-rubyşeklinde kurmamı istediler. Dedikleri gibi yaptığımda kurulum gerçekleşti. Aslında teşekkür ederken içimden "\0/" ifadesi koymak geçmedi değil :) Webkit kullanımı ise şu şekilde:
webview = WebKit::WebView.new
content = "<html><head>Foo</head><body></body></html>"
webview.load_string(content,"text/html", "UTF-8", "file://home")
content = "<html><head>Foo</head><body></body></html>"
webview.load_string(content,"text/html", "UTF-8", "file://home")
window.add(webview)
Normalde bir çok yerde "load_string" methodu "load_html_string" şeklinde geçiyor. Ama o şekilde kullandığımda bu isimde bir method yok hatası aldım. Sonra sadece bir yerde Github'daki bir kodun içinde load_string şeklinde kullanıldığını gördüm. Benden sonraki arkadaşlar bu kadar aramasınlar diye anlatma ihtiyacı duydum. Afiyet olsun :)
28 Ocak 2013 Pazartesi
Akademik Bilişim 2013
Bu yıl Akademik Bilişim Konferans öncesi yapılan 4 gün süren android kursuna katıldım. Eğitimlere katılan arkadaşların seçtikleri kursla ilgili bilgisayarlarına gerekli programları yüklemiş olarak katılmaları gerekiyor. Kalacak yer ise gayet kolay sağlanıyor, KYK için başvuru yaparsanız orada kalma imkanınız var, ya da ab2013 sitesinde kalacak mekan önerileri bulunuyor.
4 günlük eğitim süreci gayet verimli geçti. Ben daha önce hiç android programlama ile ilgilenmemiştim. Açıkçası çok karışık ve zor olduğunu düşünüyordum, gene de düşüncem "nedir ki çok kolaymış" yerine "çalışılsa yapılır, o kadar zor değilmiş" oldu. Ama android ile yazılım geliştirmeye o kadar da sıcak bakamadım ne yazık ki. Java ile kodlanıyor çünkü :( Java'nın yazımı bana çok uzun geliyor açıkçası. O kodlar uzadıkça ömrüm geçiyormuş gibi hissediyorum. Aynı zamanda kodlarken bir telefon için yazıldığının da düşünülmesi gerekli demişti eğitim veren arkadaşlar. Yazılım telefonun ısınmasına ya da bataryasının çok harcanmasına çok fazla olanak vermemeli gibi özellikler belirtmişlerdi. Sınıftan bir arkadaşım ise Yazılım için özgür araçlar eğitimine katıldı. O da gayet memmun kalmış. Ben de önümüzdeki yıl ona benzer bir eğitime katılmayı düşünüyorum. Netice şu ki gayet güzel ve keyifli bir etkinlik oldu :)
4 günlük eğitim süreci gayet verimli geçti. Ben daha önce hiç android programlama ile ilgilenmemiştim. Açıkçası çok karışık ve zor olduğunu düşünüyordum, gene de düşüncem "nedir ki çok kolaymış" yerine "çalışılsa yapılır, o kadar zor değilmiş" oldu. Ama android ile yazılım geliştirmeye o kadar da sıcak bakamadım ne yazık ki. Java ile kodlanıyor çünkü :( Java'nın yazımı bana çok uzun geliyor açıkçası. O kodlar uzadıkça ömrüm geçiyormuş gibi hissediyorum. Aynı zamanda kodlarken bir telefon için yazıldığının da düşünülmesi gerekli demişti eğitim veren arkadaşlar. Yazılım telefonun ısınmasına ya da bataryasının çok harcanmasına çok fazla olanak vermemeli gibi özellikler belirtmişlerdi. Sınıftan bir arkadaşım ise Yazılım için özgür araçlar eğitimine katıldı. O da gayet memmun kalmış. Ben de önümüzdeki yıl ona benzer bir eğitime katılmayı düşünüyorum. Netice şu ki gayet güzel ve keyifli bir etkinlik oldu :)
Kaydol:
Kayıtlar (Atom)