RSS Feed

‘Sunucu’ Category

  1. Apache sunucuda IPv6 ayarları

    August 3, 2013 by Oğuz Yarımtepe

    Apache2 ile sunduğunuz alt alan adlarını IPv6 üzerinden erişilebilir kılmak isterseniz yapmanız gereken adımlar şu şekilde:

    Apache2 varsayılan olarak hem v4 hem de v6  üzerinden erişimi destekler geliyor. Hali hazırda v4 ayarlarınızı bozmadan v6 için ayar yapıp yolunuza devam edebilirsiniz.

    /etc/apache2/sites-enabled dizininde etkinleştirilmiş alan adlarınızdan birinin foo.edu.tr olduğunu varsayalım. foo.edu.tr için oluşturduğunuz basit bir sanal uç dosyası aşağıdakine benziyor olabilir.

    <VirtualHost AAA.BBB.CC.DD>
    DocumentRoot /var/www/foo
    ServerName foo.edu.tr

    <Directory /var/www/foo>
    php_admin_value open_basedir /var/www/foo:/tmp
    allow from all
    Options -Indexes SymLinksIfOwnerMatch
    </Directory>
    </VirtualHost>

    Burada VirtualHost etiketi içerisine IPv4 adresi yazmışız. v4 adresinden sonra köşeli parantezler içerisinde v6 adresini ekleyebilir veya * ile olası tüm adresleri kapsatabilirsiniz.

    <VirtualHost AAA.BBB.CC.DD [2001:a98:a080:2:xxxx:xxxx:xxxx:xxx]>

    Sonrasında /etc/apache2/ports.conf altında

    NameVirtualHost *:80
    Listen *:80

    satırlarının olduğunu kontrol etmeniz gerekiyor. Ben buradaki NameVirtualHost satırını # ile yorum satırı haline getirip tek tek IP adresi yazmayı tercih ettim. /etc/apache2/httpd.conf içerisine

    NameVirtualHost AAA.BBB.CC.DD
    NameVirtualHost [2001:a98:a080:2:xxxx:xxxx:xxxx:xxx]

    satırlarını ekledim. Sonrasında yapılan ayarları Apache’nin algılaması için

    $ sudo /etc/init.d/apache2 reload

    komutunu çalıştırmalısınız. NameVirtualHost *:80 tanımında * kullanımlarında sanal uç dosyalarında da * kullanmak gerekiyor olabilir. * ile kullanımı denemediÄŸimi belirtmiÅŸ olayım. Buraya kadar yaptıklarınız ile v6 adresinden sunduÄŸunuz web sayfanıza eriÅŸmek isteyenlere Apache’nin cevap vermesini saÄŸladınız. Bu v6 adresine dışarıdan eriÅŸilebilmesi için eÄŸer bir ateÅŸ duvarı kullanıyorsanız web sunucusundaki servislere eriÅŸim için kural tanımlaması da yapmalısınız. Son olarak da DNS kayıtlarınızda v6 tanımlamasının olabilmesi için şöyle bir satır girmelisiniz:

    foo.edu.tr.        IN      AAAA    2001:a98:a080:2:xxxx:xxxx:xxxx:xxx/code>


  2. Farklı kodlamalı MySQL veri tabanına veri aktarmak

    September 25, 2012 by Oğuz Yarımtepe

    Olur da UTF-8 ayarları olan bir MySQL sunucudaki veri tabanından dışarı aktarılmış verileri kendi varsayılan ayarları UTF-8 olmayan MySQL sunucunuzda oluşturacağınız bir veri tabanına aktarmak isterseniz, veri tabanını UTF-8 kodlaması ile oluşturmak yetmeyebilir.

    mysql > CREATE DATABASE db_adi CHARACTER SET utf8 COLLATE utf8_bin;

    COLLATE kısmına utf8_general_ci gibi başka bir değer de yazılabilir. Ne yazacağınıza eldeki dışarı aktarılmış ve içerisinde SQL komutları olan metin dosyasına bakarak karar verebilirsiniz. Oluşturulan tabloların COLLATE verileri size bilgi verecektir.

    Dışarı aktarılmış dosyanın sql komutları başına şu üç satırı yazmak, sunucuya gönderilecek verilerin de UTF-8 olduğunu söylemenizi ve içeri aktarma sırasında verilerin varsayılan sunucu kodlamasına dönüştürülmesini önleyecektir.

    SET NAMES 'utf8';
    SET CHARACTER SET 'utf8';
    SET COLLATION_CONNECTION = 'utf8_bin';


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


  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.