Alper'in günlüğü

Bugün PCLabs‘ta ilginç bir habere rastladım. ABD’de telif haklarının korunması konusunda “çeşitli” çalışmalar yapan MPAA, RIAA ve IIPA adlı kuruluşlar biliniyordu. Bunlardan ABD çıkarlarını gözetme misyonuna sahip olan IIPA‘in Special 301 adlı bir tür kara listesi de varmış. Türkiye de izlenenler olarak bu listede yerini almış durumda.

Burada PCLabs editörlerinden Murat Gamsız’dan alıntılayayım:

Edinburgh Üniversitesinden Andres Guadamuz bir araştırma yapmış ve IIPA’nın Amerikan hükumetine açık kaynağın korsanla eş tutulmasını, hatta tehdit listesine alınmasını öngören bir istekte bulunuğunu tespit etmiş. Endonezya, Brezilya ve Hindistan’ın Special 301 listesine alınmasını, zira bu ülkelerin açık kaynak kullanımı teşvik ettikleri ve dolayısıyla da Amerikan yazılım şirketlerinin zarara uğradığı belirtilmiş. Telif hakları ile ilgili algının da zayıflamasına yol açıyormuş açık kaynak kullanımı. Bir bakıma yazılımın mutlaka parayla alınacak bir şey olduğu algısı desek yeridir.

Türkiye raporunun yaptırımlar bölümünde en çok P2P ağları üzerinde durulmuş. Tam da İstanbul Vatan Caddesi’nde Bilişim Suçları Üssü‘nün temelleri atılırken ilginç bir rastlaşma oldu. Umalım da birçok yönden dışa bağımlı olan ülkemiz özgür yazılım ile korsanın ayrımını yapabilsin.

Hayır fragmantasyondan veya fsck’ten bahsetmeyeceğim. İstanbul’da 9 Eylül’deki yağmurun ertesinde bir GSM operatörünün sistem odasında bulunan sunucularımıza erişimimiz kesilmişti. Ne Internet’ten ulaşabiliyorduk ne de IVR servislerimiz yanıt veriyordu. Henüz sel haberleri de televizyonlarda yeni yeni çıkmaya başladığından ilgili olabileceğini ilk anda düşünememiştik. Atladık arabaya, Maslak’tan İkitelli’ye 3.5 saatte gittik.

Vardığımızda sistem odasının hali şöyleydi:

(büyük halleri için resimlere tıklayabilirsiniz)

Binaya 5-6 basamakla giriliyor. Buna rağmen sanırım suyun geldiği seviye 1. ve 3. resimlerdeki çamur izinden anlaşılıyordur. Tabi zavallı  HP ML370 sunucu rack’e vidalı olduğundan kaçıp kurtulamamış..

Sunucu ve içerdiği IVR kartlarından umudu kesmiştik. Ancak disklerdeki verilerin bazılarının yedeğinin olmadığı ortaya çıkınca şansımı denemeye karar verdim. Disklerin ikisi de 36 GB U320 SCSI. Önce güzel bir temizlik yaptım (ne kadar oluyorsa artık):

Aşağıdaki iki disk arasındaki 7 farkı bulanı parlak bir sistem yöneticiliği kariyeri beklemektedir.

Bundan sonra bir gün kadar diskleri sıcak bir cihazın üzerinde kurumaya bıraktım ve ilginç bir şekilde yıkanan iki disk de sorunsuz bir şekilde çalıştı, içindeki verileri rahatça kopyaladım. Ne demişler? Çıkmadık candan ümit kesilmezmiş.

Diskleri envanterden düşmeye muhasebecimizi ikna ettikten sonra içini açıp duvarıma asmayı planlıyorum.

Binayı su bastığı sıradaki güvenlik kamerası görüntülerine buradan ve buradan ulaşabilirsiniz.

Geçenlerde e-posta’larımı Google’a teslim etmiştim. MX kayıtları bile Google tarafından kolayca ulaşılabilecek bir yerde bulunmuyorken, Jabber için yapılması gerekenleri bulmanın kolay olmaması normal sayılabilir mi bilmiyorum. Her neyse, ileride gereksinim duyabilecekler için DNS alan (zone) dosyasına eklenmesi gerekenleri buraya yazayım:

Önce MX kayıtları:

@      IN     MX    10 ASPMX.L.GOOGLE.COM.
@      IN     MX    20 ALT1.ASPMX.L.GOOGLE.COM.
@      IN     MX    30 ALT2.ASPMX.L.GOOGLE.COM.
@      IN     MX    40 ASPMX2.GOOGLEMAIL.COM.
@      IN     MX    50 ASPMX3.GOOGLEMAIL.COM.

MX sunucusu daha fazla var ama farklı gruplardan bunları harmanladım. Google’ın docs, calender vb hizmetlerine kolay ulaşabilmek için CNAME de tanımlayabiliyorsunuz:

posta     IN     CNAME    ghs.google.com.
takvim    IN     CNAME    ghs.google.com.
belgeler  IN     CNAME    ghs.google.com.

Son olarak da kendi alan adınızdan Jabber (yani Google Talk) kullanmak için eklemeniz gerekenler:

_xmpp-server  IN SRV 5 0 5269 xmpp-server.l.google.com.
_xmpp-server  IN SRV 20 0 5269 xmpp-server1.l.google.com.
_xmpp-server  IN SRV 20 0 5269 xmpp-server2.l.google.com.
_xmpp-server  IN SRV 20 0 5269 xmpp-server3.l.google.com.
_xmpp-server  IN SRV 20 0 5269 xmpp-server4.l.google.com.
_jabber._tcp  IN SRV 5 0 5269 xmpp-server.l.google.com.
_jabber._tcp  IN SRV 20 0 5269 xmpp-server1.l.google.com.
_jabber._tcp  IN SRV 20 0 5269 xmpp-server2.l.google.com.
_jabber._tcp  IN SRV 20 0 5269 xmpp-server3.l.google.com.
_jabber._tcp  IN SRV 20 0 5269 xmpp-server4.l.google.com.
_xmpp-client._tcp  IN SRV 5 0 5222 talk.l.google.com.

Pidgin vb Jabber istemcisine ise bilgileri şu şekilde giriyorsunuz:

Kullanıcı adı: sadece hesap adı, sona alan adı eklenmiyor.
Alan adı: sadece alan adınız.
Bağlantı sunucusu: talk.google.com
Port: 5222 ve SSL/TLS’i işaretliyoruz.
Kaynak: Genelde Home ayarlı gelir, aynı anda birden fazla Jabber açmıyorsanız değiştirmenize gerek yok.

Google’ın bir banka ve GSM operatörü kurmasını bekliyorum. Bu sayede maaş hesabımı ve cep telefonumu da Google’a teslim edebilirim.

Son olarak Godaddy; hiç kredi kartımı kaydetmediğim ve auto-renew seçmediğim halde, bitmek üzere olan alan adlarım ve derneğin SSL sertifikası için kredi kartımdan para çekmeye çalışınca oradan taşınma kararı aldım. Neyse ki sanal kart kullanmıştım para çekemediler. Zaten para çekemediklerine dair uyarı attılar da öylece haberim oldu. Şimdilik Domainsite‘a taşınmaya başladım. İyi (basit-hızlı) görünüyor, sayfaları Godaddy’deki gibi yüzlerce reklamla kaplı değil.

Şu an itibariyle Apache‘nin sitesindeki mesaj:

The Infrastructure Team of The Apache Software Foundation is currently investigating a potential compromise of one of our servers. For security reasons most apache.org services are therefore offline, but will be restored shortly. We apologies for any inconvenience this may cause.

10:42am UTC: Compromise was due to a compromised SSH Key, not due to any software exploits in Apache itself.

More details soon.

10:53am UTC: We have restored services on our european mirror machine which was not compromised. DNS should be shifting you over right about … now..

Geçmiş olsun.

Bugün Temmuz’un son Cuma’sı, yani Dünya Sistem Yöneticileri Günü.

Sistem yöneticinize alabileceğiniz hediyelerden bazıları.

Ve şarkımız:

http://www.youtube.com/watch?v=FE_p5N89XQI&

Bugün PHP Classes‘da yazdığına göre, Hindistan PHP geliştirici sayısı olarak dünya birincisi olmak üzereymiş.

Üstelik bundan birkaç yıl önceki istatistiklerde ABD’deki PHP geliştirici sayısı genelin %20’si, Hindistan’daki geliştirici sayısı ise %3′ün altında iken, bugünlerde çok büyük bir artışla neredeyse eşitlenmiş olması (ABD:%11,8 / Hindistan:%10,5) ilginç bir ivmeye işaret ediyor.

Bu siteye erişim mahkeme kararıyla engellenmiştir.

T.C. Beyoğlu Cumhuriyet Başsavcılığı’nın 24.03.2009 tarih ve 2009/25 sayılı kararı gereği erişime kapanmıştır.

Evet PCLabs, Asus, AMD ve Kingston bir araya gelmiş ve Şırnak’taki 5 adet ilköğretim okuluna Pardus yüklü PC bağışı yapmışlar. Katılan tüm firmaları ve PCLabs ekibini tebrik ediyor, ileride başka firmaların da katılımlarını diliyorum.

Her gün düzenli olarak takip ettiğim sitelerden PCLabs, şurada “Linux kullanıcıları: Neden Linux kullanıyorsunuz?” adlı bir anket düzenlemiş. Soruları güzel seçmişler, ama bence en önemli seçeneklerden biri olan “Özgür yazılım olduğu için” benzeri bir yanıt koysalarmış daha iyi olurmuş.

Debian’da Xen’i düşük bir olasılık olsa da bir çekirdek sorunu yaşamadan çalıştırmayı başarırsanız konsola ve syslog’a şuna benzer satırlar düşebilir:

4gb seg fixup, process xxxx (pid xxxx), cs:ip xx:xxxxxxxx

Sorunun kaynağı; stable dağıtım da kullansanız Xen hypervisor ve Xen çekirdeği ile libc6′nın uyumsuz olması. Çözüm olarak Xen için hazırlanan libc6′yı kurmalısınız (yahu bağımlılık diye bir şey icat etmişler, insan kullanır):

# apt-get install libc6-xen

Bunu kurarken libc6-i686′yı kaldırmak için onay isteyecektir. Kabul edin ve arkasında ldconfig çalıştırıp, emin olmamakla birlikte makineyi yeniden başlatın.

Tabi stable bir Debian kullanmanızın sonucunda hiç sorun/uyumsuzluk çıkmamasını umabilirsiniz. Ama bazen maalesef öyle olmuyor. Makine açıldığında aynı mesajlarla karşılaşmaya devam ederseniz,  şu dosyalarda ufak birer değişiklik gerekiyor demektir:

/etc/ld.so.conf.d/libc.conf
/etc/ld.so.conf.d/libc6-xen.conf

Bu iki dosyanın içerisine şu satırı ekliyoruz:

wcap 0 nosegneg

wcap 1 nosegneg şeklinde bir satır zaten varsa bunu yukarıdaki gibi 0 (sıfır) haline getiriyorsunuz.

Bundan sonra ldconfig & sunucuyu yeniden başlattığınızda bu hata mesajlarının kesilmiş olması gerek. (ben bir günümü harcadım, başkaları harcamasın)