RSS Feed

December, 2011

  1. Konsol iyidir

    December 23, 2011 by Oğuz Yarımtepe

    Bilgi İşlemde sanallaştırma ile sanal sunucular oluşturup kullanıyoruz. Citrix Xen Sunucu arayüzünden kolay bir şekilde sanal bir makine oluşturup herhangi bir sistemi oluşturmak mümkün.  Bugüne kadar sıkıntısız Linux kurduğumuz sanal makineler çalışıyor idi. Bugün makinelerden birisine ssh üzerinden erişmek istediğimde ulaşamadım. Citrix arayüzünden konsoluna bakayım dediğimde göremedim. Makineyi yeniden başlat dediğimde de Citrix arayüzünde bu işe engel olan başka bir süreç var diye hata verdi. Bu durumda hatayı aratınca Xen konsolundan yardım alabileceğimi gördüm.

    Tüm sanal makinelerin olduğu sunucunun bir de konsol arayüzü var. Xene özgü komutları çalıştırmak mümkün olduğu gibi bildiğiniz Linux. Sorunu görmek için


    xen task-list

    komutunu çalıştırmanız yetiyor. Çıkan konsol yanıtında “Pending” olarak bir sürecin işaretlenmiş olduğunu gördüm. Sonrasında


    xe vm-reset-powerstate vm=makineniniziadi --force

    komutunu çalıştırdım. “… a domain still exits for the specified VM” diye bir mesaj verip altında da VM e ait bilgileri gördüm. Yazan bilgilerden birisi de domid idi.

    Sonrasında bu bilgiyi kullanarak


    /opt/xensource/debug/destroy_domain -domid yukaridakidomid

    demem yeterli oldu.

    İş yapan insan için elindeki sisteme sorun olduğunda ne kadar müdahale edebileceği en önemli nokta. Alt tarafında Linux olması, konsolla müdahale edilecek olması. Bunlar faydalı özellikler. Korkmamak lazım.


  2. December 17, 2011 by Oğuz Yarımtepe

    Android için gerçek zamanlı “push” servisine ihtiyacımız vardı. Hem Internet hem de Intranette çalışssın istiyorduk. Android için böylesi bir araştırma yapınca ilk akla gelen c2dm oluyor. android 2.2 ile gelen bu servis Google sunucularını kullanarak gerçek zamanlı olarak cihazınıza mesaj göndermenizi sağlıyor. Gel gör ki bunu için Internet gerekiyor. En tipik örneği cihaz kapalı iken, Android Markete girip bir uygulamayı indir dedikdten sonra cihazınız açılıp Internete bağlandıktan sonra o uygulamayı indirmeye başlaması.

    Biraz araştırınca MQTT kullanarak, bir aracı sunucu ile de bu işin yapılabileceğini gördüm. Hatta yapılmış örnekler de bulmak mümkün. Ben buradaki örnek uygulamasını Android projesi olarak Eclipse’e aktardım. Yerelime “broker” denilen ve MQTT üzerinden iletişip gönderdiğiniz mesajları Android cihazlara yollayacak olan bir sunucu kurdum. Tercihim Mosquitto‘dan yana oldu. Ubuntu için


    apt-add-repository ppa:mosquitto-dev/mosquitto-ppa

    demek ve sonrasında mosquitto paketini kurmak yeterli. Ayar dosyasında cihaz erişimleri için güvenlik tanımlamaları yapmak mümkün. Kullanıcı adı tanımlamak, üye olunacak başlıkları belirlemek ve bu başlıklar için cihaz IDleri tanımlamak mümkün.

    Varsayılan ayarlarla da örnek Android uygulaması çalışıyor. Derlemenin olabilmesi için MQTT için bir jar dosyasına ihtiyaç var. IBM sayfasından indirilebilir. wmqtt.jar dosyasını (J2SE dizini altındaki) Android projenizin derleme yoluna harici bir jar olarak eklemeniz gerekiyor.

    Gelen arşiv dosyası içerisinde wmqttSample.jar isimli bir de istemci örneği var. J2SE dizini altındaki bu uygulamayı yerelinizde


    java -jar wmqttSample.jar

    deyip çalıştırabiliyorsunuz. Gelen ekranda “Connect” kısmına tıklayıp sonrasında da “testing” dite bir başlığa üye olup yazdığınız mesajları “Publish” kısmına tıklayarak Android uygulamanızda görebilirsiniz.  Kaynak koddaki String topics[] = { “testing/#” }; kısmını testing olarak değiştirdim.

    Bu sayede yerel ağda/Internet’te çalışan bir MQTT sunucu kullanarak bir API aracılığı ile (Python APIsi var) Android cihazlarınıza yerel/Internet üzerinden gerçek zamanlı mesajlar göndermiş olabilirsiniz.


  3. December 13, 2011 by Oğuz Yarımtepe

    Android için uygulama yazarken genel olarak Eclipse ve Android SDK kullanarak yazılan kod derleme sırasında sanal bir cihazda test ediliyor. Sanal makinenin açılması, oluşan derlenmiş apknın makineye kurulması, kurulduktan sonra sizin açılan sanal cihazda etkileşim ile menulerde gezinmeniz bazen yavaş olabiliyor. Beraber çalıştığımız öğrenciler X86 için derlenmiş ve sanal makineye kurmanızı sağlayan bir iso bulmuşlar. Projenin sayfasında sadece 2.2 için değil 2.3 ve farklı donanımlar için derlenmiş isoları da bulmak mümkün. Ben 2.2 olanını VirtualBox’a kurdum. Kurulum yapıldıktan sonra çıkan “Create Fake SD Card” seçeneğini de aktif edip kurulumdan sonra sanal bir SD kart oluşturulmasını sağlamak gerekiyor. Android’in kurulacağı bir disk yanında Virtualbox’ta oluşturulan sanal makineye ikinci bir disk ekleyip ext2 ile formatlayıp, etiket olarak SDCARD atanması da söyleniyor.[1][2]

    Sonuçta elinizde daha hızlı çalışan bir Android oluyor. Bu sanal Android’e dışarıdan bir apk kurmak da epey kolay. Bunun için Android SDK içerisinden çıkan adb komutunu kullanmak lazım:

    adb connect :5555

    ile cihaza bağlandıktan sonra


    adb install -r apk_dosyasi.apk

    komutu ile kurulum yapmak mümkün.

    Bu komut sonunda eğer sertifika hatası alınıyor ise uygulamanın kök dizininde önce


    update project --target hedef_cihaz_numarası --path .

    demek gerekiyor. Hedef cihaz numarası da


    android list targets

    komutu ile öğrenilebiliyor. android komutu da android-sdk içerisinde bulunuyor. Bu işlemden sonra


    ant -Dsdk.dir=android_sdk_yolu release

    ile uygulamanın bulunduğu dizinde bin altında imzalanmamış bir apk oluşturmak mümkün. Oluşan apkyı imzalamak için ise http://developer.android.com/guide/publishing/app-signing.html#ExportWizard adresinde yazılanları takip etmek yeterli. Sonrasında uygulamayı adb ile kurup sanal makinede denemek mümkün.


  4. Yeni nesil log tutma

    December 10, 2011 by Oğuz Yarımtepe

    Bir süredir bir log sunucusu kurmanın derdindeydik. Benim açımdan okunabilir bir şekilde tutmak önemli idi. Konsoldan dosya dosya bir takım grep bash işlemleri ile gerektiğinde log analizi yapmak istemiyordum. Klasik yaklaşım syslog-ng ile bir sunucuda logları düz metin olarak tutmak idi. Necati Graylog2 ile MongoDB kullanarak log sunucusu kurduğundan bahsetmişti. Ben de güncel yaklaşımı biraz araştırayım dedim. Sonuç olarak Logstash + Graylog2 çözümüne vardım.Aslında önerilen yaklaşım bu ikisine ek olarak bir de Elasticsearch kullanmak. Sebebi de Graylog2’nin arşivleme özelliği üzerine kurulmamış olması. Elasticsearch ile arama ve arşivleme işini büyük (örneğin 5GB) veri tabanı boyutlarında hızlandırmak. Logstash bu işin hem sunucu hem de istemci tarafımda kullanılıyor.

    Logu gönderilmek istenen sunucularda logstash çalıştırılarak Linux konsolundan bildiğimiz “tail” işlemi ile log dosyasına her eklenen satır ayar dosyasındaki çıktıya gönderiliyor. Sürekli bir takım kayıtların gönderileceği düşünülürse, gönderilecek kısmın doğrudan veritabanı değil de bir kuyruk olması daha mantıklı. Bu noktada Logstash, RabbitMQ gibi mesaj kuyruğu sistemleri ile haberleşebiliyor.Altta Apache’nin erişim loglarını gönderdiğim ayar dosyası var.


    input {

    file {
    type => "apache-access"
    path => "/var/log/apache2/other_vhosts_access.log"
    }

    }

    output {
    # Output events to stdout for debugging. Feel free to remove
    # this output if you don't need it.
    # stdout { }

    # Ship events to the amqp fanout queue named 'rawlogs"
    amqp {
    host => "A.B.C.D"
    exchange_type => "fanout"
    name => "rawlogs"
    }
    }

    A.B.C.D ile yazılan kısım RabbitMQ koşan ve log sunucusu görevi yapacak olan sunucunun IP adresi.

    Logu gönderilecek olan kısımda java komutunun çalıştırılabilir olması gerekir.

    Konsolda aşağıdaki komut ile ayar dosyasının okunup Apache erişim kayıtlarının mesaj kuyruğuna yollanması sağlanabilir.


    sudo java -Dlog4j.debug -Dlog4j.configuration=file:/home/oguz/logstash/log4j.properties -jar logstash-1.0.17-monolithic.jar agent -f logstash.conf


    Log sunucusu görevi görecek olan kısımda RabbiMQ yanında Graylog2 sunucusunun koşması gerekiyor. Graylog2 sunucusunun ve web arayüzünün kurulum ve çalıştırılması wikisinde gayet güzel anlatılıyor. Logstashın’da çalışıp RabbitMQ kuyruğundaki mesajları alıp Graylog2’nin anlayacağı Gelf biçiminde ona göndermesi gerekiyor. Ayar dosyası şu şekilde:


    input {
    amqp {
    # ship logs to the 'rawlogs' fanout queue.
    type => "all"
    host => "A.B.C.D"
    exchange_type => "fanout"
    name => "rawlogs"
    }
    }

    filter {

    grok {
    type => "apache-access" # for logs of type 'apache-access'
    pattern => "%{COMBINEDAPACHELOG}"
    }

    date {
    type => "apache-access"
    timestamp => "dd/MMM/yyyy:HH:mm:ss Z"
    }
    }
    {>
    output {
    #stdout { }
    }>
    gelf
    {
    host => "A.B.C.D"
    }

    }

    Logstash burada Grok isimli filtreleme ile gelen mesajları biçimlendirip o şekilde kaydetmenizi sağlıyor. Graylog2 web arayüzünde de kaydedilen log kayıtlarını anlık olarak görmek mümkün. Arayüz gerçek zamanlı olarak size sonuç gösteriyor. Filtreleme yapıp arama yapmanız rahat. Hangi uçlardan ne mesajı görmeniz gayet kolay. Otomatik olarak uçlardan gelen logları size toplu olarak gösteriyor.  İşin 5651 kısmı için böylesi bir yaklaşım uygun mudur pek emin değilim. Sorduğum arkadaşlar log kaydının metin olması, belli bir biçimi olması gerektiğini söyledi. Ben bu veri tabanının “dump” edilmiş halini imzalasam ve saklasam da 5651 için uygun olur diye düşünüyor idim. Böyle değilse bile Logstash sadece log dosyanızın sonuna eklenen satırları anlık olarak işlediğinden, hala elimizdeki log dosyalarını syslog-ng ile bir yerlerde saklamak mümkün. Bence bir web arayüzünden kaydı tutulan loglar ile ilgili neler olup bittiğini görmek için güzel bir çözüm.