Artık Google Apps'in ücretsizi yok!

Google tarafından verilen Google Apps hizmetinin bir de ücretsiz olanı vardı, kâr amacı gütmeyen kuruluşlar için. Bir süredir ücretsiz haline başvuru alt sayfalarda, sağda-köşede gizleniyormuş gibi geliyordu bana. Başvurmak için sürekli ücretli sürümlere yönlendirmele falan...

Derken geçen hafta Google artık Apps'in ücretsiz halinin olmayacağını duyurdu. Kendim de dahil birçok kişi ve kuruluş için tavsiye ettiğim Google Apps hizmeti, söylenenlere göre 7 yıldır varmış.

Daha önce başvuran ve bu hizmeti kullanmakta olan kişi ve kuruluşlar kullanmaya devam edebilecekler. Ama yeni başvurular artık alınmayacak. Bunun yerine ücretli sürümü varlığını sürdürecek: kullanıcı başına aylık 4 Avro!

Microsoft Exchange Server'ın maliyetlerine bir kıyaslama yapasım geldi. Şu sayfadan aldığım lisanslama fiyatlarını kullanarak:

	Server	CAL
Exch Std	$700	$67
Exch Ent	$4.000	$34
Google	0	48

Farklı sayıda kullanıcı sayıları için bu maliyetleri karşılaştıralım:

Kullanıcı	10	50	100	200	500
Std	$1.370,00	$4.050,00	$7.400,00	$14.100,00	$34.200,00
Ent	$4.340,00	$5.700,00	$7.400,00	$10.800,00	$21.000,00
Google	€ 480,00	€ 2.400,00	€ 4.800,00	€ 9.600,00	€ 24.000,00

Burada ilk dikkatimi çeken Exchange Standard ile Exchange Enterprise'ın maliyetleri 100 kullanıcıda kesişiyor. Bir de TL üzerinden görelim bu tabloyu:

Kullanıcı	10	50	100	200	500
Std	1.617 TL	4.779 TL	8.732 TL	16.638 TL	40.356 TL
Ent	5.121 TL	6.726 TL	8.732 TL	12.744 TL	24.780 TL
Google	1.104 TL	5.520 TL	11.040 TL	22.080 TL	55.200 TL

Eğer Google Apps'in 4 Avro/ay maliyeti (48 Avro/yıl) kullanıcı sayısı ile değişmediğin farzedersek (değiştiğine dair bir bilgi bulamadım) Google Apps her durumda "sadece lisansları göz önünde bulundurduğumuzda" pahalıya geliyor.

Bir de işin arka planını düşünelim. Bir Exchange sunucuya sahip olmak demek bu fiziksel sunucuyu 7/24 açık tutmak, soğutmak demek. Bu sunucunun çalışması için enerji, soğutma, gerekli depolama alanını sağlamak için disk masrafları var. Google Apps ile aynı depolamayı (25 GB/kullanıcı) sunduğumuzu düşünürsek 100 kullanıcı için ihtiyaç duyacağımız alan 100*25= 2,5 TB olur. Bunu 8 tane 600 GB 15.000 rpm SAS disklerle sağlıyor olsak, her bir diskin güç tüketimini 14 W olarak alırsak, sunucu ile birlikte güç tüketimi 350 W gibi birşey olur. Google ile aynı açık kalma yüzdesi (%99,9) ile çalıştırdığımızı düşünürsek 365*24*0,999=8.751 saat yapar. Bu da ~3.000 kWh gibi yıllık güç tüketimi yapar. Bir o kadar da soğutma harcaması düşünsek yıllık 6.000 kWh elektirk harcaması yapar. Tek terimli enerji tarifesinin en üst birim fiyatı ile hesaplama ile yıllık elektrik + soğutma maliyeti 1.500 TL'yı geçmez.

Donanım maliyetleri ise sunucu için yaklaşık 8000 $, depolama için ise 600*8=4800 $, toplamda 23.000 TL yapar. Bu hiç arıza yapmayan bir sistemin fiyatı. Zaman geçtikçe bazı disklerin değişmesi gerekebilir, sunucu donanımında bazı arızalar olabilir vs.

Elbette Google'a ödenmesi gereken rakamlar her yıl için. Exchange Sunucu lisans maliyetleri ise bir kez ödenecek tutarlar. Bir kere ödeme yaptıktan istersek 5 yıl herhangi bir lisansa ihtiyaç duymadan kullanabiliriz. Ama Google'da sürekli güncel tutulan bir sistem var. Exchange'i sabit lisanslama ile satın aldıktan sonra güncelleme yapmak için yeni maliyetleri hesaplamak gerek.

Enerji ve donanım maliyetlerini de düşünürsek yukarıdaki tablolara Exchange için yaklaşık 24.500 TL'lık bir ek yapmak gerekiyor. Bu durumda Google Apps 1 yıllık kullanım düşünüldüğünde Exchange'e göre avantajlı olabilir. Örneğin 100 kullanıcı için Exchange maliyeti 32.000 TL çıkarken, Google Apps sadece 11.000 TL. Bu da şu demek, Exchange Server'ın 3 senelik lisanslama bedeli ile Google Apps'in kullanım bedeli birbirine eşit. Zaten 3-4 senede bir Exchange Server'ın yeni sürümünün çıktığını ve yenileme ihtiyaçlarını düşününce Google Apps'ın avantajı ortaya çıkabilir. Elbette şimdiye kadar kendi kendine tümüyle yönetilen bir sistemin avantajlarından hiç bahsetmedik bile (güvenli web erişimi, ek hizmetler, yedekleme vs.).

Process Explorer'a farklı bir bakış

Çok değerli bir sistem aracı olan Process Explorer'ı hep yaratıcısı Mark Russinovich'ten dinledik/okuduk. Her ne kadar çok saygıdeğer bir kişilik olsa da duyduklarım/okuduklarım hep birbirinin kopyası olarak kaldı.

Bugün Process Explorer'a farklı bir bakış olabilecek bir video izledim. Andrew Richards'ın ağzından bazı yeni özellikleri farklı cümlelerle dinlemek güzeldi. Ama adamın ağzından çıkanları yakalayabilmek için ekstra çaba sarfetmek gerekiyor, o ayrı :)

X ışını cihazları ve manyetik diskler

Uzun zamandır kafamda olan bir sorunun cevabını Western Digital'ın web sitesinde dolaşırken buldum. Bütün alışveriş merkezleri, havaalanları vs. girişlerinde güvenlik sebebiyle konulan x ışını cihazlarına manyetik disklerimi bırakma konusunda tereddütlerim vardı. Western Digital'ın bilgisine göre x ışını cihazlarının yaydığı manyetik alan, sabit disklere zarar verebilecek boyutlarda değilmiş.

http://wdc.custhelp.com/app/answers/detail/a_id/1458/related/1/session/L2F2LzIvdGltZS8xMzQ4NjcwMjgzL3NpZC9DRm9ma2Q3bA%3D%3D

TR/Agent.AWQX.1 Truva Atı (zero day)

Başka bir zararlı kod aktivitesi. Avira Professional Security 12 kurulu bir bilgisayarında Excel.exe'ye virüs bulaştığına dair ekrana çıkan bir uyarı mesajı ile başladı hikaye.

Elbette bu gerçek bir antivirüs yazılımı değil ve Excel.exe'ye virüs bulaştığına dair görüntülenen bu uyarı da gerçekleri yansıtmıyor. Bu pembe tonlara sahip "Live Security Platinum" penceresi sahte; ona şüphe yok. Ama muhtemelen sadece sahte olmakla kalmayacak, bazı zararlı bileşenleri de olacak.

Söz konusu bilgisayarda görev yöneticisinin, process explorer'ıın ve komut satırının açılması engelleniyor. Uzak bir bilgisayardan pslist ile baktığımda ise %ALLUSERSPROFILE%\Application Data klasöründe 32 tane rastgele karakterden oluşan bir isme sahip klasör içinde aynı isimde bir exe dosyasının bu işin sorumlusu olduğunu gördüm. pskill ile sonlandıramadım maalesef. Ama Windows komut satırı aracı taskkill başarılı oldu.

Yukarıdaki resimde görüldüğü gibi sistem tepsisinde Avira'nın simgesi gözüküyor. Yani Avira bu işler olurken çalışıyormuş. Şimdi nasıl oluyor da antivirüs sistemi hiçbirşey yapmıyor diye düşünürken Avira TR/Agent.AWQX.1 tanımlamasıyla virüs bulduğu uyarısını verdi. O zaman yeni sorumuz şu: Niye sisteme bulaşmadan tespit edemedi?

Zararlı kodun adını (TR/Agent.AWQX.1 olarak gözüküyor) kullanarak Google'da yaptığım bir aramada şu an itibariyle kaydadeğer bir sonuç alamadım. Ama AWQX anahtar kelimesi ile yaptığım aramada bunun bir truva atı bileşeni olduğunu, çalıştığı bilgisayarlarda bir arka kapı (backdoor) açtığını, muhtemelen daha fazla zararlı bileşen indirerek bilgisayarı bir botnetin parçası haline getirdiğini öğrendim ^[1],[2],[3].

Sonra Avira'nın virüs tanımlamalarını (vdf) incelerken 7.11.41.238 numaralı vdf'inde bu virüsün adını gördüm. Avira web sitesinde bu tanımlamanın tam olarak hangi saatte yayınlandığı bilgisini vermiyor maalesef. Ama yerel ağımızdaki AMC Sunucu'nun kayıtlarından 7.11.41.238 numaralı güncellemenin bugün (6 Eylül) saat 4:15'te download edildiğini gördüm. Tahmin ediyorum ki bu güncelleme Avira.com'da saat 01:15-04:15 saatleri arasında yayınlanmış. Yani çok yeni. Kullanıcı sabah bilgisayarını açtıktan bir süre sonra güncellemeyi almış.

Peki acaba bu bilgisayarı kullanan kullanıcımız acaba bu trojanın bulaşmasına sebep olan aktiviteyi ne zaman yapmış? Bugün içinde kayda değer bir trafik gözükmüyordu. Bir önceki günün kayıtlarına baktığımızda bir şüphelimiz oldu: http://ucpbcsyt.justdied.com.

Kesinlikle bu site diyemiyorum ama bir önceki gün bu siteden bazı veri alışveri olmuş ve bu site şu anda McAfee'nin trustedsource.org sitesinde "Malicious Sites" olarak kategorize edilmiş ve yüksek riskli olarak işaretlenmiş.

Yukarıda bahsettiğim All Users\Application Data klasöründeki exe dosyasını sonlandırdıktan,

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run

altında bu exe dosyasına işaret eden ve sistem tekrar başladığında çalışmasını sağlayacak girişi de sildikten sonra Avira'nın 7.11.41.242 (daha da yeni) virüs tanım dosyası ile tarama yaptım. Birşey bulamadıktan sonra dosya kapandı.

Çok yeni bir virüstü (zero day) ama Avira yaklaşık 12 saat farkla bir güncelleme yayınladı. Herhangi bir zarar oluşmadan tehdit etkisiz hale getirildi.

Referanslar
[1] www . spywareviruscleaner . com/How-to-Remove-Generic12.AWQX.html
[2] http://www.emsisoft.com/en/malware/?Backdoor.Win32.LolBot.awqx.AMN
[3] http://www.paretologic.com/resources/definitions.aspx?remove=Magania%20Awqx%20Trojan

Avira Server Security 12 SP1

Daha önce Avira'nın hem Avira Professional Security 12 hem de Avira Server Security 12 ürünleri için service pack 1'i yayınlayacağını yazmıştım. Service Pack yayınlandı, Avira Management Console'da (AMC) gözüktü. Ağdaki Avira Professional Security 12 ürünü yüklü olan PC'lere otomatik olarak yeni sürüm yüklendi. Ama sunucularımda bu geçiş olmayınca duruma müdahale etmem gerekti.

Daha önce AMC'nin loglarında Avira Server Security 12 için de 12.0.0.2309 sürümün download edildiğini gördüğüm için elimde güncel sürümün olduğundan emin bir şekilde sunucuları elle güncellemek istedim. Ama fayda etmedi. Sunucular, AMC Server üzerinde yeni sürümün olmadığını söyleyerek güncellemeyi reddediyorlardı.

Hemen Avira Update Manager (AUM) altındaki Released Products kısmına giderek Avira Server Security 12 ürününün sürümünü kontrol ettim ve farkettim ki burada bir sorun var.

Görüldüğü gibi sürüm N/A (Not Available) olarak gözüküyor. Download edilmiş kurulum paketi ile ilgili bir sorun olabilir mi düşüncesiyle %ALLUSERSPROFILE%\Application Data\Avira\Avira Security Management Server\Softaware\751 klasörünün altındaki kurulum paketine baktım (hatta onu sunuculardan birine kurdum) ve sürümün 12.0.0.2309 olduğunu gördüm. Sorun burada değil.

AUM'un altındaki Released Products'ta listelenen Avira Server Security 12'yi silip tekrar eklemek istedim, ama böyle bir seçeneğim yoktu. Sonradan öğrendim ki AMC'de Configuration'ın altında Update arayüzündeki "Automatically syncronize software repositories between AMC and AUM servers" checkbox'ını işaretinin kaldırılarak silme işlemi mümkün olabiliyor.

Bu şekilde Avira Server Security 12'yi silip tekrar ekledim, ama bu da çözüm olmadı. Bir süre sonra Avira Türkiye Destek'ten aldığım bilgiye göre Avira, sunucu ürünleri için SP1'li ürünü dağıtmayı geçici olarak durdurmuş.

Yine hiçbir yerde hiçbir açıklama yok, bilgilendirme yok. AMC'nin içine Info Center diye bir bölüm koymuşlar. Çok güzel. SP1'in yayınlanacağı bilgisi de zaten *sadece* burada çıktı. Ama olumsuz bilgiler hiç paylaşılmıyor. Çok gizli bilgilere erişmek için illa ki kırmızı hattı kullanmak zorundayız.

IFrame zararlı kodları

McAfee kullanırken varlıklarından bile haberim yoktu. Avira kullanmaya başladıktan sonra ne kadar çok olduklarını farkettim. Bir süre öncesine kadar internette güvenli gezinmenin, güvenli web sitelerini ziyaret etmekten ibaret olduğu gibi bir fikrim vardı. Ancak son zamanlarda normal şartlar altında güvenli sayılabilecek bazı web sitelerinin bile bazı zararlı kodlar barındırabildiğini gördüm.

Birçok örnek var, ama Türkiye Masa Federasyonu'nun sitesi bir gov.tr sitesi olması açısından önemli bir örnek. Kullanıcılarımızdan birisinin www.tmtf.gov.tr sitesini ziyaret etmesinin ardından Avira AMC konsoluna düşen virüs uyarıları karşısında şaşırdım. Avira'nın virüs olduğunu düşündüğü dosyayı Avira Merkez'ine tekrar taranmak üzere gönderdim, muhtemelen yanlış alarm olabilir düşüncesiyle. Ama zararlı içerik doğrulandı.

Bundan sonra şu sayfayı buldum. Burada IFrame zararlı kodlarının (onları "badware" olarak adlandırmış) nasıl bulaştığı anlatılmış. Sitenin uzun süre bu zararlı kodların etkisi altında kalmasının sonucunda Google'ın siteyi farketmesi durumunda sitenin ziyaretçilerinin nasıl azalabileceği ve saygınlığını nasıl kaybedebileceği de anlatılmış. Bir sitenin Google tarafından karalisteye alınıp alınmadığını, son 90 günlük aktivitenin sonucunun ne olduğunu aşağıdaki adresten öğrenebiliriz.

http://www.google.com/safebrowsing/diagnostic?site=http://www.site-adi.com.tr

Ek (2019-12-10): Güncel adres:

https://transparencyreport.google.com/safe-browsing/search?url=siteadi.com.tr

Burada en sondaki site='dan sonra gelen adresi istediğiniz şekilde değiştirerek merak ettiğiniz bir sitenin son 90 günlük raporuna ulaşabilirsiniz.

Google bir siteyi karalisteye alınca ne oluyor? Yeni tarayıcılar Google tarafından yönetilen bu veritabanını periyodik olarak inceleyip bu veritabanındaki sitelerden birine erişilmek istendiğinde şöyle bir uyarı sayfası gösterebiliyorlar:

Google Chrome

Mozilla Firefox

Bu seçenekler Google'ın sunduğu Safe Browsing[1] hizmeti ile geliyor ve varsayılan olarak tarayıcılarda etkinleştirilmiş durumda. Firefox'ta bu ayarlara Seçenekler>Güvenlik sekmesinde ulaşılıyor. Google Chrome'da ise Seçenekler>Gelişmiş Seçenekleri Göster>Gizlilik altında.

Referanslar:

[1] Google Safe Browsing Protocol v2 : http://code.google.com/p/google-safe-browsing/wiki/Protocolv2Spec

Avira Service Pack-1

Avira'nın AMC console'unda yer alan InfoCenter'da görüntülenebilen bilgiye göre Avira'nın service pack 1'i 8 Ağustos'a kadar kurulabilir durumda olacakmış. Bu bilgiyi Avira neden web sitesinde paylaşmaz, bilemiyorum. Şimdilik sadece AMC'nin InfoCenter'ında var.

Burada yer alan bilgilere göre şu anda 12.0.0.1466 sürümüne sahip Avira Professional Security 2012 ürününün sürümü 12.0.0.1504'e, şu anda sürümü 12.0.0.2272 olan Avira Server Security 2012'nin sürümü de 12.0.0.2309'a yükseltilecek.

31 Temmuz tarihinde InfoCenter'a düşen bu haberde service pack 1'in piyasaya çıkışının 8 Ağustos'a kadar tamamlanacağı belirtiliyor. Çok sayıda bug'ı düzelteceği söylenmiş. Gerçi açıkça benim ve Avira kullanan binlerce kişinin şu derdine derman olacağı belirtilmemiş ama tüm beklentiler bu yönde.

Avira "Bad Image" hatası

McAfee antivirüsü bırakıp Avira'ya geçeli 6 ay oldu. Avira'nın genel performansından gayet memnunum. Ancak Windows Vista ve Windows 7 işletim sistemleri üzerinde bir türlü giderilemeyen bir hatası var. Bilgisayar açıldıktan bir süre sonra Avira güncelleme yapmayı durduruyor. Bunun sonucunda AMC üzerinde bu hatanın olduğu bilgisayar kırmızı ünlem işaretiyle görünmeye başlıyor.

Bu aşamadan sonra AMC üzerinden veya hatanın oluştuğu bilgisayarın konsolundan update yaptırmak mümkün olmuyor. Çünkü Avira'ya ait "About" hariç hiçbir grafik arayüz çalışmaz hale geliyor. Programın grafik arayüzlerine erişme girişimlerinin hepsi aşağıdaki gibi "Bad Image" hatası ile sonlanıyor ve

C:\Windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2\COMCTL.dll

konumundaki sistem dosyası ile ilgili bir hatanın olduğundan şikayet ediyor.

Comctl.dll, işletim sistemine ait bir dosya. Bu dosyada olabilecek bir hata, muhtemelen Windows'un daha ciddi hatalar vermesine sebep olurdu. Zaten Avira'nın forumunda açılan şu başlıkta belirtildiği gibi dosyayı tekrar yüklemek de sorunu gidermedi.

Forumda soruna çare olabilecek birkaç yöntemden daha bahsedilmiş ama hiçbirisi gerçek bir katkıda bulunmadı. Mayıs ayında Avira'nın yayınladığı Service Pack 0 da fayda etmedi.

Avira Türkiye sorunun Visual Studio Redistributable sürümleri ile ilgili olduğunu söyledi. Farklı sürümlerin varlığının bu soruna yol açtığını, mümkünse Visual Studio Redistributable'ları ve Avira bileşenlerini kaldırıp kurmamızı önerdi. Ama zaten Avira Professional Security 2012 ve Avira Management Console'u kurmak için Microsoft Visual Studio C++ 2008 Redistributable ve Microsoft Visual Studio C++ 2010 Redistributable bileşenlerinin kurulu olması gerekiyor.

Sorun Windows XP veya Windows Server işletim sistemlerinde görülmüyor. Hedef sadece Windows Vista ve Windows 7. Forumdaki asdasdasd adlı kullanıcının da dediği gibi, 10 aydır çözülemeyen bu sorun gerçekten inanılmaz!

14.08.2012 Ek: Avira Service Pack 0'dan sonra Service Pack 1 de bu sorunu çözemedi.  Avira ürün sürümü 12.0.0.1504 olan Windows 7 bir sistem üzerinde bu sorunla hala karşılaşıyorum.

30.04.2013 Ek: 2013 sürümlerinde bu sorun artık yok. Sorun olmadığı bilgisini vermek için acele etmedim. Uzun bir süredir kullanıyorum, artık bu hata giderilmiş.

Linux IO monitoring

VMware Server'ın yüklü olduğu linux sistemde kaynak sorunları yaşamamın üzerine sorunun bellek mi, işlemci mi yoksa disk mi olduğunu anlamaya çalıştım. Ama bu kolay olmadı. Window'da aşina olduğum Performans Monitor benzeri bir araç linux server'da yoktu. Bunun için araştırmaya başladım.

Biraz önbilgi. Linux çekirdeği disk IO'yu sayfalara böler. Birçok sistemde varsayılan sayfa boyutu 4K dır ($ getconf PAGESIZE komutu ile çalışan sistemin Page Size boyutunu görebilirsiniz). Linux, fiziksel adres alanı ile eşleştirilen bir "sanal bellek alanı" katmanı kullanır. Bir uygulamanın ihtiyaç duyduğu veri önce CPU cache'inde, daha sonra fiziksel bellekte aranır. Bulunamazsa bir majör sayfa hatası (MPF) oluşur ve aranan veri diskten okunarak RAM'deki tampon belleğe yazılır. Tampon bellekteki verilere erişim çağrıları minör sayfa hatasına (MnPF) sebep olur. MPF'ları azaltıp MnPF'ları artırmak için disk erişimlerinde buffer (yazma işlemleri için ayrılan tampon bellek) ve cache (okuma işlemleri için ayrılan tampon bellek) kullanılır. Bir sistemdeki toplam bellek miktarı, kullanılan bellek, buffer ve cache değerlerini

#cat /proc/meminfo

Komutu ile öğrenebiliriz.

Bir sistemde üç tip bellek sayfası vardır:
Read Pages: MPF ile diskten okunan sayfalar. Bellekte read-only olarak tutulur. Kütüphane dosyaları gibi hiç değişmeyecek dosyaların ait verileri içerirler. Çekirdek ihtiyaç duydukça bunları kullanır. Bellek sıkıntısı olması durumunda bir kısmı boş olarak işaretlenir, uygulamalar buradaki verilere tekrar ihtiyaç duyduğunda MPF'lerle onları tekrar belleğe getirir.
Dirty Pages: Bu alandaki veriler çekirdek tarafından değiştirilen verilerdir. Değişiklikler diskteki veriye, pdflush daemon tarafından, yansıtılmak (senkronize edilmek) zorundadır. Bellek sıkıntısı olduğunda buradaki veriler kswapd (ve pdflush) ile diske yazılarak yer açılabilir.
Anonymous Pages: Bu tip bellek alanları bir sürece ait değildir ve diskteki bir dosya ile senkronize edilmezler. Bellek sıkıntısı olduğunda buradaki veriler (kswapd ile) takas bölümüne yazılır.

İlk önce bulduğum araç iostat idi. Kullanabilmek için Ubuntu ve Fedora'da sysstat paketini kurmak gerekli.
Cyberciti'de güzelce açıklanmış. Örnek bir kullanım şöyle:

$ iostat -d -x 2 2

Device:  rrqm/s  wrqm/s  r/s   w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
fd0      0.00    0.00    0.00  0.00   0.00     0.00     8.00     0.00   10.32  10.32   0.00
sda      0.01    5.92    0.07  4.98   2.88    87.32    17.87     0.69  137.16   1.48   0.75

Device:  rrqm/s  wrqm/s  r/s   w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
fd0      0.00    0.00    0.00  0.00   0.00     0.00     0.00     0.00    0.00   0.00   0.00
sda      0.00  1130.00   2.50 28.50 368.00  9268.00   310.84     0.23    7.42   1.77   5.50

iostat'ın parametrelerinden d disk kullanım verilerini, x ise ayrıtılı (eXtended) verileri göstermesini sağlıyor. Sonraki sayılardan ilki kaç saniye arayla tekrar verileri göstereceğini, sonraki ise kaç kez bu işlemi tekrarlayacağını gösteriyor. Ben 2 saniye arayla 2 kez istedim. Gösterilen verilere gelirsek

rrqm/s (Read ReQuests Merged per second): Sanyiede birleştirilmiş okuma istekleri (diskte sıraya alınmış)
wrqm/s (Write ReQuests Merged per second): Saniyede birleştirilmiş yazma istekleri (diskte sıralya alınmış)
r/s (Reads per second): Saniyedeki okuma istekleri
w/s (Writes per second): Saniyedeki yazma istekleri
rsec/s (Read Sectors per second): Saniyede okunan sektör sayısı
wsec/s (Write Sectors per second): Saniyede yazılan sektör sayısı
avgrq-sz (AVeraGe ReQuest sector SiZe ): Diske gelen tüm isteklerin sektör sayısı olarak ortalaması
avgqu-sz (AVeraGe ReQuest QUeue SiZe): Diske gelen tüm isteklerin kuyruk uzunluğu olarak ortalaması
await: Diske gelen tüm isteklerin ortalama (milisaniye) karşılanma süresi (kuyrukta bekleme + işlem)
svctm (SerViCe TiMe): Diske gelen tüm isteklerin ortalama işlem süresi (= await - queue time)
%util (bandwidth utilization): Diskin bant genlişliği kullanımı. %100'e yakın olması sınıra yaklaşılmış demek.

İkinci olarak iotop adındaki araç buldum.iotop varsayılan olarak etkileşimli olarak çalışan, sürekli olarak süreçlerin DISK READ ve DISK WRITE değerlerini görüntüleyen bir araç. Kullanabilmek için Ubuntu ve Fedora'da iotop paketini kurmak gerek. Örnek kullanım şöyle:

$ iotop -o

Total DISK READ: 93.45 K/s | Total DISK WRITE: 124.60 K/s
  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND
 2590 be/3 root        0.00 B/s  797.45 B/s  ?unavailable?  [kjournald]
 4203 be/3 root        0.00 B/s 1594.90 B/s  ?unavailable?  [kjournald]
15645 be/2 root        0.00 B/s  797.45 B/s  ?unavailable?  vmware-vmx -C /vmacs/TESTM~ndard x64 Edition.vmx -@ ""
15649 be/2 root        0.00 B/s  797.45 B/s  ?unavailable?  vmware-vmx -C /vmacs/TESTM~ndard x64 Edition.vmx -@ ""
15652 be/4 root        0.00 B/s  353.56 K/s  ?unavailable?  vmware-vmx -C /vmacs/TESTM~ndard x64 Edition.vmx -@ ""
15656 be/2 root        0.00 B/s  450.12 K/s  ?unavailable?  vmware-vmx -C /vmacs/TESTM~ndard x64 Edition.vmx -@ ""
15661 be/2 root       17.13 K/s  797.45 B/s  ?unavailable?  vmware-vmx -C /vmacs/TESTM~ndard x64 Edition.vmx -@ ""
15662 be/2 root        2.34 K/s  797.45 B/s  ?unavailable?  vmware-vmx -C /vmacs/TESTM~ndard x64 Edition.vmx -@ ""
15663 be/2 root        6.23 K/s  797.45 B/s  ?unavailable?  vmware-vmx -C /vmacs/TESTM~ndard x64 Edition.vmx -@ ""
15664 be/2 root       58.41 K/s  797.45 B/s  ?unavailable?  vmware-vmx -C /vmacs/TESTM~ndard x64 Edition.vmx -@ ""
15666 be/2 root        9.35 K/s 1594.90 B/s  ?unavailable?  vmware-vmx -C /vmacs/TESTM~ndard x64 Edition.vmx -@ ""
15667 be/2 root        0.00 B/s 1594.90 B/s  ?unavailable?  vmware-vmx -C /vmacs/TESTM~ndard x64 Edition.vmx -@ ""
15668 be/4 root        0.00 B/s  276.46 K/s  ?unavailable?  vmware-vmx -C /vmacs/TESTM~ndard x64 Edition.vmx -@ ""


Burada SWAPIN ve IO sütunlarının altında ?unavailable? yazmasının sebebini ekranın altındaki

CONFIG_TASK_DELAY_ACCT not enabled in kernel, cannot determine SWAPIN and IO %

hatasıyla açıklamış. Buna göre kernel'i uygun config ile tekrar derlemek gerek. Etkileşimli çalışma kipinde sağ ve sol ok tuşlarını kullanarak verilerin hangi alana göre sıralanacağını seçebiliriz. Seçilen alanın yanında bir ">" işareti belirir. Komut satırında kullandığım -o anahtarı ise sadece I/O yapan süreç ve thread'leri göster demek.

Üçüncü olarak budluğu araç ise vmstat. Bunu kullanabilmek için de sysstat paketini kurmak gerekli. Ben en çok bunu sevdim. Komut satırından çalıştırırken sadece kaç saniyede bir güncel verileri görüntüleyeceğini seçmek gerekiyordu, 1 ile ben her saniye görüntülemesini belirttim. Durdurana kadar her saniye yeni bir satır ekleyerek verileri tekrar yazıyor:

$ vmstat 1

procs  -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache    si   so    bi    bo   in   cs us sy id wa
 0  1  27800  39548  14796 3500092    0    0  2720     0  145 1991  1  3 88  8
 0  5  27800  36204  14828 3502532    0    0  2644   520  194 2258  0  3 65 32
 0  5  27800  33804  14848 3504596    0    0  2116     4  348 1922  1  3 26 70
 0  1  27800  30848  14892 3506260    0    0  1584     0  232 2508  1  3 71 25
 0  1  27800  26772  14940 3509760    0    0  3396     0  279 2924  1  4 74 21
 0  1  27800  23332  14992 3512740    0    0  3028     0  225 2501  0  4 74 22
 0  3  27800  25696  14984 3508956    0    0  1816   816  239 2168  0  5 59 36
 0  3  27800  25368  15004 3509372    0    0   332  1408  486 1123  0  1 40 59
 0  3  27800  29500  13272 3506900    0    0  1352   344  338 2122  1  2 32 64
 1  2  27800  27004  13284 3509260    0    0  2308     0  230 2060  1  3 53 42
 0  3  27800  30180  13288 3509732    0    0   748     0  152 2104  0  9 66 25
 0  2  27800  25196  13324 3511936    0    0  1888     0  853 2381  3 12 52 33
 1  2  27800  23768  13336 3513756    0    0  1832    48 1285 2756  5  9 60 26

Yukarıda görülen alanların anlamları (veri miktarı birimi KiB)
r (runtime):  "Number of processes waiting for runtime". Çalışmak için bekleyen süreç sayısı diyelim. Ya süreç IO bekliyor, ya da CPU meşgul, bu sebeple bazı süreçler henüz görevlerini tamamlayamamış.
b (blocked): IO kaynağı eksikliği sebebiyle hizmet verilemeyen thread sayısı (başka bir kaynakta ise bekleme sebebinin IO olmayabileceği yazıyordu).
swpd: Kullanılan sanal bellek miktarı
free: Kullanılmayan bellek miktari
buff: Yazma işlemleri için ayrılan tampon bellek miktarı (RAM)
cache: Okuma işlemleri için ayrılan tampon bellek miktarı (RAM)
si (swap-in): Swap'ten okunan bellek miktarı
so (swap-out): Swap'e yazılan bellek miktarı
bi (block-in): Diskten okunan blok miktarı
bo (block-out): Diske yazılan blok miktarı
in: Saniyede gelen kesme (interrupt) sayısı (saat dahil)
cs: Saniyede yapılan context switching sayısı

Toplam CPU zamanını (% olarak) şöyle açıklayabiliriz:

%CPU zamanı = %Kullanıcı_süreçleri + %Kernel_süreçleri + %Boşta_zaman + %WIO

Buna göre (tümü yüzde olarak):
us: Kullanıcı süreçlerinin işletilmesine harcanan CPU zamanı
sy: Kernel (çekirdek) süreçlerini işletmek için harcanan CPU zamanı
id: Idle. CPU'nun boşta durma zamanı
wa: WIO, ya da wait-IO. CPU zamanın IO işlemlerini beklemek için harcanan kısmı

Artık şöyle yazabiliriz:
%CPU zamanı=us + sy + id + wa

vmstat ile ilgili güzel bir açıklama şu adreste var.

2019-08-28 Ek: vmstat sonuçlarının grafiğinin çizilmesi ile ilgili güzel bir proje buldum. git clone ile önce bir klasöre kopyaladım. vmstat değerlerini dosyaya yazabilmek için önce ekranda gördüğümüz sonuçları bir dosyaya yazmak lazım. En basit haliyle

 # vmstat 1 > vmstat.txt

ile ekrana basmadan doğrudan dosyaya, ya da hem ekrana hem dosyaya göndermek için

# vmstat 1 | tee vmstat.txt

ile verileri dosyada biriktirdikten sonra clone'ladığımız klasörün içindeki index.html dosyasını browser ile açıp, vmstat.txt dosyasını sürükleyerek browser penceresinin ortasındaki alana bırakmamız, ya da hiç yerele girmeden doğrudan http://jsargiot.github.io/vmstatly/ adresinden çalışmamız mümkün.

Referanslar:
[1] www.ufsdump.org/papers/io-tuning.pdf

Tespitin zorluğu

Siber-tehditler gün geçtikçe daha da karmaşlıklaşıyor. Tespit edilmeleri zorlaşıyor. Eskiden antivirüs yazılımları sadece imzaya dayalı tarama teknikleri kullanırlardı. Şimdi daha tanınmamış olan virüsleri de bulabilmek için yeni teknikler kullanmaya başladılar.

Elbette hiçbir antivirüs yazılımı mükemmel değil. Bir süre öncesine kadar antivirüs yazılımlarının tespit edemediği virüsleri Sysinternals'ın araçları gibi programlar kullanarak tespit etmenin mümkün olduğunu düşünürdüm. Artık fikrim değişti.

Bir dosyanın "şüpheli" sınıfına girebilmesi için birkaç koşul vardır (ya da eskiden vardı):

1. Dosya adı. Dosya adı saçma sapan karakterlerden oluşmuşsa bu birinci sırada dikkat çeken bir özellik olurdu. Bu sebeple birçok zararlı kod dosyalarının isimlerini sistem dosyalarının isimlerine benzetmeye, veya doğrudan onların isimlerini vermeye yönelmişti. Örneğin svchost.exe gibi. %systemroot%\system32 klasörünün haricinde bir konumda karşılaşılan svchost.exe dosyası bir numaralı zanlı olurdu.
2. Üretici bilgisi ve dosya tanımı. 16 bitlik çalıştırılabilir dosyalar hariç diğer çalıştırılabilir dosyalarda bir metadata bilgisi yer alır. Burada dosyanın üreticisi ve dosyanın adının haricinde bir de dosyanın tanımı yer alır. Bu bilgiler de bir fikir verirdi. Sistemdeki bir donanımın sürücüsünün mü, antivirüs yazılımının mı olduğu hakkında bir yol gösterirdi. Daha sonra geçerli bir dosya olup olmadığını anlamak kolaylaşırdı.
3. Sayısal imza. Yukarıdaki yöntemleri sıradan bir kötü amaçlı programcı bile kendi kötü amaçlı yazılımına uygulayabilirdi. Bunun için sayısal imza diye bir konu vardı. Üreticiler sürücülerini imzalar, veya çalıştırılabilir dosyalarının da kendileri tarafından üretildiğini kanıtlamak için sayısal imza kullanırlardı.

Ancak yeni tehditler artık bu yöntemlerin ne kadar cılız kaldığını gösterdi. Örneğin bir süre önce Mark Russinovich'in blog'unda incelediği Stuxnet virüsü.

Bulaşma yöntemi mükemmel. Windows 7'de bile var olan bir açığı kullanarak USB sürücüler üzerinden bulaşıyor (ki bu açık Ağustos 2010'da KB2286198 yamasıyla kapanmış). Bilgisayarınıza taktığınız USB sürücüde gayet zararsız gibi görünen birkaç dosya var. Bunlardan birisi bir kısayol. Ama kısayolun ikonu yok. Windows Explorer ikonu okumak için işaret edilen dosyaları okumaya çalışınca Windows'un açığını kullanarak virüs sisteme bulaşıyor. Bundan sonra da bu dosyalar rootkit teknikleriyle gizleniyor.

Sisteme bulaşan bileşen ise MRxNet.exe ismiyle Windows klasörüne kopyalanıyor. Virüs bunu gizleme zahmetine girmemiş. Daha iyisini yapıp bunu bir donanımın sürücüsü gibi göstermiş. Üstelik bunu Realtek ve JMicron gibi donanım üreticilerinin sertifikalarını kullanarak yapmış. Kullanılan sertifikaların çalındığı ve dağıtan şirket tarafından farkedildikten sonra iptal edildiği belirtilmiş.

Mark Russinovich, yazılarında (1,2,3) ayrıntılı olarak bulaşma adımlarını inceleyerek tespit edilebilirliğini göstermiş, ama bu yöntemler gayet ileri seviye yöntemler.

Sonuçta Stuxnet'in İsrail hükümetinin desteklediği bir proje kapsamında geliştirildiği ve gayet açık bir şekilde İran'daki santrallerde kullanılan Siemens marka ürünleri hedef aldığı yönünde spekülasyon ötesi bazı iddialar var. Bu önemli değil. Önemli olan yeteri kadar güçlü motivasyonla nelerin yapılabiliyor olduğu. Artık korkmak lazım.

findstr ve unicode dosyalar

Windows'un komut satırı araçlarından findstr ile yaptığım bir aramada bir sonuç alamadığımda gördüm ki bu komut unicode desteğine sahip değilmiş. Örneğin çok sayıda log dosyasına ait bir klasörde

findstr /s /i "2272" *.log

aramasıyla içinde 2272 geçen dosyaları bulmak istediğimde hiç sonuç dönmedi. Bunun üzerine kardeş arama komutu find'ı denedim.

find "2272" *.log

Bu şekilde başarılı oldum, ancak find'ın /s gibi alt klasörleri de taramayı sağlayan bir anahtarı olmadığından bu durumda sadece mevcut klasörle sınırlı kaldım. Aslında find'ı daha çok başka bir komutun çıktısını süzmek için kullanırdım. Örneğin

dir /q | find "administrator"

komutuyla mevcut klasörde sahibi administrator olan dosyaları bulabilirdim. Ancak şu andan itibaren bu komut farklı bir kullanım daha kazanmış oluyor.

Windows Server'da C: sürücüsünde yer kalmayınca

Sistem sürücüsünde yer kalmayınca çalıştırılan Disk Temizleme Aracı (Disk Cleanup Tool) yeteri kadar yer açmıyorsa yapılacak elbette başka şeyler de vardır.

Aslında Disk Temizleme aracı çok belli başlı durumların haricinde hiçbir fayda sağlamaz ve zaten masaüstü sistemlerde nispeten daha az bilgisayar kullanım becerisine sahip kullanıcılar için tasarlanmıştır.

Benim için asıl sorun Windows 2003 sunucumuz üzerinde Windows Update dosyalarının kapladığı yerdi. Microsoft'un KB956324 makalesinde anlatıldığı gibi bu klasörleri temizlemem benim için faydalı oldu. Bu makaleye rastlayıncaya kadar gördüm ki forumlarda bu konu hararetli olarak tartışılmakta. Bu sebeple uyguladığım ve faydasını gördüğüm adımları paylaşmak istedim. Her ne kadar "silmek" fiilini kullansam da aslında yaptığım bu dosyaları yer kalmayan sistem sürücüsünden başka bir depolama ortamına taşımaktı. Tüm adımları uygulamak okuyanın sorumluluğundadır - hadi o da olmadı, KB956324 numaralı makalenin Türkçesini okuyun; sorumluluk kabul edilmez.

1. Windows Update dosyaları

%Windir%/$NtUninstallKB number$

klasöründe depolanır. Aslında buradaki dosyalar güncellemenin kendisi değil, bu güncellemenin değiştirdiği "eski" sistem dosyalarıdır. Bu dosyaları silmek, gerektiğinde bu güncellemeyi kaldırmayı imkansız hale getirir. Bu sebeple KB956324 makalesinde 30 gün veya daha uzun süre önce yüklenmiş güncellemelere ait klasörlerin silinmesi önerilmiş. Ben buradan 100 MB yer kazandım.

2. Windows Update indirmeleri için önbellek (cache) konumu

%Windir%\SoftwareDistribution\download

olarak belirtilmiş. Bu klasörün içinde 10 günden daha uzun süre önce oluşturulmuş klasörlerin silinebileceği yazılmış. Ben buradan 800 MB yer kazandım.

3. Güncelleme dosyalarına ait kurulum kayıtları ve geçici dosyalar için

%Windir%

klasörünün altındaki

kb*.log

setup*.log

setup*.old

setuplog.txt

winnt32.log

set*.tmp

dosyalarının silinmesi önerilmiş. Benim durumda bu dosyalar sadece 4 MB kadar bir yer kazandırdı.

4. Service Pack ile ilgili klasörü silmek için

%Windir%\$NtServicePackUninstall$
%Windir%\ServicePackFiles

klasörleri gösterilmiş. Ancak service pack ile gelen dosyalardan herhangi birinde bir sorun olması durumunda bu klasöre ihtiyaç duyulacağı hatırlatılmış.Ben toplam boyutu 1200 MB olan bu klasörleri silmedim, gelecekte uygulayabileceğim bir adım olarak bıraktım.

Sonuçta 900 MB yer kazandım, bir sonraki acil durumda kullanabileceğim 1200 MB'lık bir alan buldum.

Sen de mi Avira

Bu daha önce de olmuştu, muhtemelen yine olacak. Sistemlerimizi virüslerden korusun diye kurduğumuz antivirüs yazılımlarının sistemlerimize virüslerden daha çok zarar vermesi artık alışıldık birşey. Hangi yazılım olursa olsun...

Avira 14 Mayıs'ta bir service pack yayınladı. Akşam üzeri yapılan düzenli güncellemeler sırasında Avira'nın internet sunucularından bizim sunucumuz üzerine indirildi, ve akşam üzeri yapılacak son güncelleme ile bilgisayarlara dağıtıldı (Avira Professional Security 12 için product version 12.0.0.1462, Avira Server Security 12 için 12.0.0.2272). Özellikle akşam üzeri olması güzel oldu diye düşünüyordum; bilgisayarların ayrıca kapatılıp açılmasına gerek kalmadan ertesi gün herşey kurulmuş olur beklentisiyle.

15 Mayıs sabahı çok sayıda telefon çağrısıyla başladık güne. Bir çok kişi Avira'nın çalıştırdıkları bazı programları engellediğini belirten şikayetler ilettiler.

Google'da "avira startup of the application blocked for your security" araması beni, bu dertten muzdarip kullanıcıların yazıştığı acil durum toplanma noktasına götürdü. Evet, anlaşılan o ki olay sadece iexplore.exe ile ilgili değil. Muhtemelen daha çok sayıda uygulama bu engele takılacak.

Baştan sadece belli bir işletim sistemi için olduğunu düşünsek de, bu durum dün akşam bilgisayarlarını kapatarak yeni service pack'ın kurulumunu tamamlamış kişilerin bilgisayarlarında görülüyordu. Forumda açılan başlık altında bir felaketzede, offline çalışan, güncellemeleri aldıktan sonra bilgisayarını bile açamayacak duruma gelmiş kullanıcılarından bahsetmiş. Antivirüs yazılımına para verme mantığını oturtamamış bilişim özürlü Türk malı bir patrona, antivirüs yazılımlarına ödenen lisans paralarına rağmen bir yığın bilgisayarın hem de virüslerden kaynaklanmayan, aksine antivirüs yazılımındaki bir hatadan kaynaklandığını anlatmak zorunda kalmadığım için kendimi şanslı hissettim, halime şükrettim.

Neyse, ben bilgisayarımı kapatmadığım için bende bir engelleme olmamıştı. Avira Forum'unda yazılanlara göre bu ProActiv bileşeninde yaşanan bir sorundan kaynaklanıyordu. avguard.log dosyasında service pack kurulumu gerçekleştikten sonra ProActiv'in etkin olduğu bilgisayarlarda şöyle satırlar yer alıyordu:

[INFO] ProActiv blocked access to the following application:
  C:\Windows\system32\DllHost.exe
[INFO] ProActiv blocked access to the following application:
  C:\Program Files\Internet Explorer\iexplore.exe
 
Bazıları engellenen her uygulamayı Allow beyazlistesine eklemeyi önermiş. Ama çok sayıda program engele takılma potansiyeline sahip olduğu için ProActiv'i -umarım kısa- bir süre devre dışı bırakmak daha iyi olacak. Avira gün içinde yayınladığı destek sayfasında da benzer önerilerde bulundu.

Avira Forum'daki moderatör, "Avira'nın bu durumun farkında olduğunu ve öncelikli olarak bu şüpheli durumla ilgili çözüm önerileri arayışında olduklarını" belirtmiş. Ama service pack'in yayınlanmasının üzerinden neredeyse 24 saat geçmesine rağmen "Dünyanın en hızlı tepki verebilen antivirüs üreticisinden" (bu onların iddiası) henüz bir çözüm çıkmadı.

 

Avira'nın reklam e-postası

16.05.2012 Ek: Avira, dün akşam üzeri yayınladığı bir güncelleme ile ProActiv bileşenini tüm ürünlerinden kaldırdı (Avira Professional Security 12 için product version 12.0.0.1463). Ancak bunu genel bir açıklama yaparak değil, sessiz sedasız yaptı. Durumu Salı sabahı forumları okurken ve Avira'nın değişen arayüzüne bakarken farkettim.

24.05.2012 Ek: http://www.zdnet.com/blog/security/avira-antivirus-update-cripples-millions-of-windows-pcs/12129
http://www.computerworlduk.com/news/security/3357997/avira-antivirus-service-pack-wreaks-havoc-on-windows-pcs/

14.06.2012 Ek: Avira'nın en kötü yanı bu herhalde. Güncellemeler sessiz sedasız. Bugün farkettim ki bu sorun 12.0.0.1466 güncellemesiyle çözülmüş (kayıtlara göre 14 Haziran'da). ProActiv bileşeni aktif ve sorunsuz çalışıyor.

Windows 7'de Gezgin'in adres çubuğuna ulaşmak

Şurada verilmiş. Denmiş ki, Windows 7 altında Windows Gezgini'ni kullanırken adres çubuğuna ulaşmak için klavye kısayolu ALT+D'dir. E öyleyse ben niye ALT+D ile adres çubuğuna erişemiyorum? Şurada da konunun muzdaribi bu durumu üreticinin forumlarında dile getirmiş. Ama aklı evvelin biri "F4 işinizi görür" demiş. Aynısı olsa Microsoft ALT+D'yi koymazdı.

Sorun galiba adres çubuğu kısayolu ile dosya menüsü kısayolunun çakışmasından kaynaklanıyor. Birinden biri değişmeli. Windows XP'nin Türkçe sürümünde Gezgin adres çubuğunun kısayolu ALT+E idi. Türkçe Windows 7 için de aynı kısayol kullanılsaydı olurdu. Şimdi soruna çözüm bulabilmenin iki yolu var. Ya menünün kısayolu değiştirilecek, ya da adres çubuğunun kısayolu.

Resource Hacker adında bir program vardı, tam bu işler için tasarlanmış. Onu kullanmayı düşünüyorum. Çözüm bulabilirsem paylaşırım.

Avira yüklü bilgisayarlardaki yavaşlığın sebebi

Avira antivirüs yazılımlarını merkezi olarak yönetebilmek için AMC (Avira Management Console) adında bir mmc konsolu var. Bu yönetim biriminden Avira kurulu bilgisayarları incelerken bazen bilgisayarların üzerinde kırmızı bir ünlem işareti beliriyor. Kırmızı ünlem işareti, bilgisayarın antivirüs yazılımı ile ilgili bir sorunun olduğunun göstergesi.

Böyle bir durumda Security Environment'i genişletip Product Status'a baktığımda Avira'nın yüklü bileşenlerinden birisiyle ilgili bir sorun olduğunu görüyorum. Eğer bilgisayar uzun süredir güncellenmemişse sorun sadece Status of Update'te gözükür. Bu değilse sorun ya Web Protection ve Mail Protection (genelde ikisi aynı anda olur), bazen de Realtime Protection ile ilgili olabilir.

Bu hafta farkettim ki eğer sorun Realtime Protection'da ise bilgisayar son derecede yavaşlayabiliyor, işlem yapmak gerçekten zorlaşabiliyor. Böyle bir durumda ne görev yöneticisi, ne de Process Explorer gibi araçlar suçluyu bulmamda yardımcı olmuyor. Ancak olay görüntüleyicisi sistem kaydında avipbb (eski sürümde avgntflt) kaynaklı hatalar birbiri ardına düşmeye başlıyor. Örneğin şöyle:

Event Type    :    Warning
Event Source  :    avipbb
Event Category:    None
Event ID      :    18
Date          :    11.05.2012
Time          :    09:23:45
User          :    N/A
Computer      :    PC-ADI
Description   :
TIMEOUT       : event=2 PID=2612
Data:
0000: 00 00 00 00 02 00 56 00   ......V.
0008: 00 00 00 00 12 00 07 80   .......?
0010: 00 00 00 00 00 00 00 00   ........
0018: 00 00 00 00 00 00 00 00   ........
0020: 00 00 00 00 00 00 00 00   ........


Bilgisayarın hizmetlerine baktığımdaysa "Avira Realtime Protection" hizmeti "Durduruluyor" durumunda gözüküyor. En son güncelleme görevi sırasında muhtemelen hizmeti yeniden başlatma işlemi gerekmiş, ancak hizmet durdurulma aşamasında takılıp kalmış; hiç başlayamamış. Yapılması gereken bu hizmetin tekrar başlatılması. Ama hizmetler applet'inde durdurmak ve tekrar başlatmak için düğmeler basılabilir durumda değil. Baktığımda bu hizmetten sorumlu süreç avguard.exe olarak gözüküyordu. Ben de bu süreci uzaktan sonlandırmayı denedim:

pskill \\pc-adi avguard.exe

pskill, bir Windows Sysinternals aracı. Bunun yerine Windows'un taskkill aracını da kullanabilirdim, ama pskill hem daha basit, hem de daha şık bir kullanıma sahip.

Neyse, pskill ile avguard.exe sürecini sonlandırdıktan sonra uzak makine üzerindeki "Avira Realtime Protection" hizmetini başlattım. Bundan sonra AMC üzerindeki kırmızı ünlem işareti gitti, olay görüntüleyicisindeki hata kayıtları son buldu ve makinenin çalışması normale döndü.

Avira Antivirus Premium 2012'yi tekrar kurmak

Avira Antivirus Premium 2012 kurdum. Lisans anahtarını kurulum sırasında girerek lisanslamayı da yaptım. Ama daha sonra bilgisayarımdaki işletim sistemini tekrar yüklemem gerekti. İşletim sisteminizi tekrar kurduktan sonra Avira'yı da tekrar kurmak istediğimde program lisans anahtarımı tekrar girmemi istedi. Ancak ilk seferde girdiğim lisans anahtarını ikinci kez girmemi kabul etmedi.

İzlenmesi gereken yol önce Avira'yı kaldırmak, daha sonra işletim sistemimi tekrar kurmak ve sonrasında Avira'yı da yeniden kurmaktı. Böyle yapmış olsaydım lisans anahtarını ikinci kez kullanmama izin verecekti [1,2]. Ama ben öyle yapmadığım için bu mümkün olmadı.

İkinci seçenek olarak eğer hbedv.key dosyasını yedeklemiş olsaydım kurulum sırasında bunu gösterip lisans anahtarımı tekrar girmeme gerek kalmayacaktı. Maalesef bunu yapmamışım. Ya da her zamanki gibi nereye koyduğumu bulamadım.

Sonra Avira Forum'da şu sayfada başka bir öneri vardı. Avira'yı kurduktan sonra bir de kayıt işlemi vardı. Buraya e-posta adresimi verip bir şifre almış ve kaydımı yaptırmıştım. İşte o sayfada hbedv.key dosyamı tekrar download edebileceğim bir bölüm vardı.

O sayfadan hbedv.key dosyamı tekrar edindim, kurulum sırasında gösterdim ve kurulumum, lisans süremi göstererek tamamlandı. Lisans süremin bitişi, Avira Premium'u bilgisayarıma ilk kurduğum günden 1 sene sonrasıydı; ikinci kurulumdan 1 sene sonrası değil.

Başka bir ihtimal var mıydı diye düşünmeye başladım. Acaba "Ürünü Sına" seçeneği ile kurulum yapsam ardından hbedv.key dosyasını gösterebilecek miydim? Denemek için sanal makineme bir kurulum yaptım ve uzun uzun yeniden lisanslama yapacağım bir arayüz arayıp durdum. Sonra farkettim ki .key uzantısı Avira için kaydediliyor. Yani elimde bir hbedv.key dosyası varsa bunu çift tıklayarak lisanslamayı kolayca yapabiliyorum.

Bu güzeldi. Ama bundan hemen sonra programın kurulum klasöründeki fact.exe dosyası ile lisanslamayı tekrar yapabildiğimi farkettim. Hatta yeni lisans anahtarı girecek bir alan bile var. Dosya böylece kapandı.

Avira Kurtarma CD'si

Avira'nın ev kullanıcıları için sunduğu ücretsiz antivirüs yazılımı güzel birşey. Ama zaten virüslü olduğu bilinen bir bilgisayara antivirüs kurmak çok mantıklı değil. Antivirüs sadece bilgisayar yeni virüslere karşı korur. Virüslü bir bilgisayara muhtemelen bir antivirüs yazılımını nizami bir şekilde kurmak bile mümkün olmayacaktır. Bunun için önce bilgisayarı temizlemek gerek. İşte tam bu noktada offline yöntemler çok faydalı. Avira da böyle bir durumda kullanmak için kurtarma CD'leri yaratmış. Şu adresten download edilebilecek iso dosyalarını bir CD'ye yazdıktan sonra sisteminizi bu CD'den açınca linux tabanlı bir sistemle bilgisayarınızı tarayabilirsiniz. Bu kurtarma CD'lerinin de ücretsiz olması işi daha da güzel yapıyor.

Türkçe internet forumlarının kullanımı ile ilgili

Internetteki forumlar çok kullanışlı. Herkesin kafasına takılabilecek önemli konuların tartışılabilmesi için sanal ortamlar. Ne güzel. Ama her aracı doğru kullanmak gerek. Özellikle Türkçe forumlarda her başlık altında sorulan sorulara verilen cevaplar karşısında dumur olmamak elde değil.

Örnek olarak bir "köpek kovucu" (ultrasonik ses dalgaları yayan küçük bir elektronik cihaz) almak isteyen birisinin bunu nasıl temin edeceğini sorduğu donanimhaber.com'de 2005 yılında açılan şu başlıklı girişe denk geldim. İlk soruyu soran kişi bir köpek kovucu almak istediğini söyleyip bunu nereden bulabileceğini sormuş. Normalde soruya verecek bir cevabınız yoksa birşey yazmamanız gerek. Kalkıp konuyu dallandırmanın anlamı yok.

Bu başlık altında bugüne kadar yazılan 91 mesajda şunlar yazılmış:

1. Önce ultrasonik değil, 50 Hz altı ses dalgaları üreten bir el yapımı yanlış cihaza yönlendirme yapılmış.
2. Sivrisinek kovabilen Symbian telefonların bunu da başarabileceği iddiası ortaya atılmış.
3. Köpeklerden en iyi korunma yönteminin kaçmak olduğu iddia edilmiş.
4. Köpeklerden en iyi korunma yönteminin oturmak olduğu iddia edilmiş.
5. Köpeklerden en iyi korunma yönteminin ona "yavşakça davranmamak" olduğu iddia edilmiş.
6. Köpeklere karşı "göz yaşatrıcı sprey" kullanımı önerilmiş.
7. Göz yaşartıcı spreylerin yasal durumunu tartışılmış.
8. Birisi teyzesinin jeepiyle 70 km/s hızla bir köpeğe çarpma anısını anlatmış.
9. İki kilo kıyma ve fare zehiri kullanarak köpeklere tuzak hazırlama görüşülmüş.
10. Başka birisi bu yöntemi filler üzerinde uygulamamak gerektiğini vurgulamış.
11. Bir subwoofer ile korunmak önerilmiş.
12. Sağır köpeklere karşı kullanabilmek için önce köpeğe işitme cihazı takmak gerektiği espirisi sabırla yapılmış.
13. Bu kadar çelişkili bilgiye isyan eden kişiye "tıbbın pozitif bir bilim olmadığının" hatırlatılması ihtiyacı hissedilmiş.
14. Böyle bir cihaza para vermek yerine "el feneri" kullanmak önerilmiş.
15. Köpekten korkulmaması, daha atak olunması gerektiği öğütlenmiş. Köpeklerin burnuna atılacak bir yumrukla köpeğin nakavt edilebileceği, veya kulağını kıvırmakla "iyk iyk" şeklinde bağıracağı bilgisi günyüzüne çıkarılmış.
16. Bu duruma karşı çıkan bir hayvansever "Ne istersiniz köpeklerden, ben karşıma bir köpek çıksa da sevsem diye bakıyorum" şeklindeki görüşüyle konuyu çeşitlendirmiş.
17. Eline taş alıp atar gibi yapılırsa köpeğin korkup kaçacağı iddia edilmiş.
18. Oyuncak tabancanın çıkaracağı ses ile köpeğin korkacağı iddia edilmiş.
19. Daha da ileri gidip su tabancasına kolonya doldurup köpeğin gözüne sıkılırsa köpeğin kaçacağına dair bir işkence yöntemi dillendirilmiş.

Bu arada birkaç kişi yazılanlardan dolayı kafasının karıştığını, alıp almama konusunda daha da kararsız hale geldiğini belirtmiş. Birkaç kişi bu cihazın nereden temin edileleceğini de söylemiş tabi, ama 91 mesajın içinde onlar azınlıkta kalmış.

Sonuç, Türkçe forumlarda sorunuza cevap bulmak çok zor.

Flash'ın yeni sürümlerindeki güncelleme düzeni

Bazen FlashPlayer'ın güncellenme penceresi çıkar karşıma. Çok dikkat etmem, muhtemelen bilgisayarı yeni başlattığımda görünür.

Ama o pencere nasıl açılır, günlük mü, haftalık mı, aylık mı, bilmiyorum. Bir gün yine açıldığında bekletip Process Explorer'ı açtım. Bir penceredan ilgili prosesi bulan butona basarak bunu Flash'ın update penceresinin üzerine sürükledim.

Nihayetinde Flash Update'in prosesi ortaya çıktı: %systemroot%\system32\Macromed\Flash klasörünün altındaki FlashUtil11c_Plugin.exe dosyası. Process Explorer'da bu prosesi çift tıklayarak komut satırından nasıl başlatıldığını görmek istedim. Nihayetinde aşağıdaki pencerede görüleceği gibi -update plugin argümanlarıyla çağrıldığını gördüm.

Peki bu proses durup dururken nasıl oluyor da çalışıyor? Muhtemelen registry'de bir giriş vardır diye düşünüp registry'yi aradım, ama hiçbir ilgili giriş bulamadım. Bu garip işte. Biraz uğraşmam gerekecek.

Avı için pusuya yatan avcı misali, uzun bir gözlem sürecine girdim. Bu sefer de Process Monitor'ü açtım. Sadece registry olaylarını takip etmek istiyorum. Bu sebeple önce araç çubuğundaki sadece registry butonunun basılı kalmasını sağladım.

Daha sonra Ctrl+L'ye basarak yakalanacak olayların arasından sadece registry yolunda flash geçen olayları süzmek amacıyla aşağıdaki girişi yapıp "Add" butonuna bastım.

Bir de Filter menüsünden "Drop Filtered Events"i işaretledim, çünkü uzun süre Process Monitor'ü açık tutmak milyonlarca gereksiz olayı yakalayacak, ve bunlar da sanal bellekte depolanacağından (eğer File menüsünden Backing Files ile bunu değiştirmediysek) bir süre sonra yetersiz sanal bellek hataları ile karşılaşacağız.


Bu işi birkaç gün tekrarladım. Sonunda oltama birşey takıldı. FlashUtil11c_Plugin.exe'in çalışmasını sağlayan [HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce\] anahtarının altındaki FlashPlayerUpdate girişiymiş.

 

 

 Bu giriş,yukarıda bahsettiğim gibi daha önce yoktu. Buraya bunu kim yazıyor? Bunu bulmak için yukarıdaki süreci bir daha, fakat bu sefer filtre olarak yine path'e flash yerine runonce yazarak tekrarladım. Aynı şekilde "Drop Filtered Events" seçili olmalı.

Bu da birkaç gün sürdü. Sonunda katlili buldum: plugin-container.exe!

plugin-container.exe, firefox'un. Plugin'lerinin firefox.exe prosesinden bağımsız olarak çalışması için geliştirilmiş bir yöntem. Bu sayede Flash gibi plugin'lerde bir sorun olduğunda sadece plugin sonlanıyor, asıl sekme veya firefox prosesine birşey olmuyor. Eskiden böyle olmuyordu, flash sebebiyle bütün firefox çöküyordu, herkes sebebinin firefox olduğunu düşünüyor, "firefox çok çöküyor" şeklinde bir yanılgı oluşuyordu.

Flash'ın güncellenme işini bir browser bileşenine bırakması garip gibi görünse de aslında olay şöyle oluyor; sistemdeki flash sürümü her tarayıcı için farklı olabiliyor. Örneğin benim sistemimdeki durum şöyle (Denetim Masasındaki flash appleti)

Buradaki ActiveX sürümü Internet Explorer'ın kullandığı Flash'ın sürümü, Plug-in sürümü ise Firefox'un kullandığı Flash sürümü. Çıkan sonuç şudur ki, Flash sadece kullandığınız tarayıcı için, ve kullandığınız sürece güncelleniyor. Firefox kullanıyorsanız bu iş bu şekilde. Internet Explorer'ımın sürümünün eski olmasının sebebi de onu daha seyrek kullanıyor olmam. Google Chrom ise kim bilir bu işi nasıl yapıyor.

PowerPoint 2007 bazı resimleri sıkıştırmıyor

Normalde PowerPoint sunularına eklediğiniz resimler, çok yüksek çözünürlüklüyse, bunları slayta sığdırmak için ölçeklendirebilir veya kırpabilirsiniz. Bu durumda slayta sığmayan ayrıntıları sunu dosyasının içinde depolamaya gerek yoktur. Office 2003'ten beri var olan "sunudaki tüm resimleri sıkıştırma" seçeneği ile resimleri sıkıştırarak PowerPoint sunu dosyasının boyutunu ciddi olarak düşürebiliriz. Bunun için PowerPoint 2007'de resmi seçtikten sonra açılan Format (Biçim) araç çubuğunun Adjust (Ayarla) sekmesindeki Compress Pictures (Resimleri Sıkıştır) butonuna basmak gerekir.

Ancak bugün elime geçen 140 MB'lık devasa sunu dosyası için bunu bir türlü yapamadım. Sebebi, eklenen resimlerin renk düzeninin RGB değil, CMYK olmasıymış. Office 2003'te bunu yapabiliyorken Office 2007'de mümkün olmaması garip.

Bu soruna kolay bir çözüm bulamadım. PowerPoint 2003 bulup resimleri sıkıştırabilir, veya üşenmezseniz tüm resimleri tek tek kopyalayıp başka bir program içinde RGB>CMYK dönüşümünü yapıp/kırpıp tekrar sunuya yapıştırmak gibi değişik ihtimalleri deneybilirsiniz.

Ülkelere göre en çok kullanılan tarayıcı

Şu anda tüm dünya istatistiklerine bakınca en çok tercih edilen tarayıcı, birçok kaynağa göre [1,2,3,4] Internet Explorer. Durum üç aşağı beş yukarı Türkiye'de de aynı. Ancak durumun böyle olmadığı ülkeler de varmış. Wikipedia'da bulduğum şu sayfadaki istatistiki veriler dikkatimi çekti.

Yukarıdaki haritada mavi alanlar IE, turuncular Firefox, yeşiller Google Chrome, kırmızılarsa Opera'nın en çok kullanıldığı ülkeleri gösteriyor. Türkiye'nin rengi mavi. Bu tarayıcı savaşları biraz ilgimi çektiği için son zamanlarda daha yakından takip ediyorum. Son birkaç aydır Chrome, Firefox'u sollayarak IE'nin peşine takıldı. Bu gidişle yakında Türkiye'nin rengi yeşile dönecek.