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.


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.

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.

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.

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.

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.

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


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.
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:
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
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:
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 :)

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.

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.

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.
# apt-get install nagios3 nagios-nrpe-server  nagios-nrpe-plugin
Kurulumdan 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 restart
Tarayı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.
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.
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.txt 
Açarken de "--decrypt" parametresini kullansak yeterli olur.
$ gpg -ao public.key --export 711CB3B7
Açık anahtarı elde etmek için
$ gpg -ao private.key --export-secret-keys 711CB3B7 
Gizli 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 :)