Hep hareketli bir "tag" bulutu oluşturmak istemişimdir. Oldukça verimli ve işe yarar , aynı zamanda da görsellik derecesi yüksek bir öğe olduğunu düşünüyorum.
Ekteki sayfada bunun nasıl yapılabileceği basit bir şekilde anlatılıyor. Blogumda da bu kodu kullandım.
VMware ESX 3.5 sunucularına bir IIS sunucusunu kullanarak konsol üzerinden kontrollü yama yükleyebilmek için aşağıdaki gibi güzel bir yol önerilmiş.
http://virtrix.blogspot.com/2007/03/vmware-autopatching-your-esx-host.html
Backup Exec 12.5 Linux agent’ını CentOS sunucularına yüklerken aşağıdaki gibi bir hata mesajı alıyordum.
Installing VRTSralus 12.5.2213 on xxxx Unable to copy, /home/tomcat/gecici/Backup\ Exec Linux/RALUS64/pkgs/Linux/VRTSralus.tar.gz, on xxxx to, /var/tmp/vxif/RALUS/VRTSralus, on xxxx
…………………………………………………… failed to install
BE agent’ın olduğu tar dosyasını “Backup Exec Install” adında bir klasöre açmışım. Farkedilebileceği üzere arada boşluk karakterleri var. Bu boşluk karakterlerini kaldırınca yükleme sorunsuz gerçekleşti.
Sysinternals araçlarıyla ISA ADAM kaynaklı sorunların incelenmesine yönelik yeni bir makale yayınlandı. Oldukça ilginç bulduğum için paylaşmak istedim.
Tüm işletim sistemlerinde olduğu gibi ESX sunucuları için de güvenliğin optimum düzeye yükseltilmesi sistem yöneticilerinin görevleri arasında yer alıyor. ESX OS üzerinde tanımlanmış kullanıcı hesaplarının logon / logoff / lockout aktivitelerinin izlenmesi de bu görevin bir parçası. Bu konuda fazla ahkam kesmeden deneyimlerimden bahsetmek istiyorum.
Test sunucusunda yaptığım çalışmalarda bir kaç kategoride log üretmek ve izlemek için denemeler yaptım.
# last -x| grep “`date -d y ‘+%B %d’`” >/tmp/last.log
# faillog| grep “`date -d y ‘+%B %d’`”
ESX 3.5′da faillog komutu çalıştırıldığında/var/log/faillog dosyasının oluşturulması istenmektedir.
# touch /var/log/faillog
# chmod 600 /var/log/faillog
# chown root:root /var/log/faillog
komutlarıyla dosyayı oluşturabilirsiniz.
Ancak bu da dosyaya kayıtların gelmesini sağlamayacaktır. Yaptığım araştırmalarda bunun ESX’te kullanılan OpenSSH sürümüne ilişkin bir bug olduğuna dair forum yazışmaları görmüştüm.
http://communities.vmware.com/message/1180677#1180677
Ancak kendi denemelerimde # esxcfg-auth –maxfailedlogins=3 komutu çalıştırıldıktan sonra şifresini yanlış girdiği için lockout konumuna düşen kullanıcı hesaplarına dair kayıtların bu log dosyasına yazıldığını gördüm. Ancak bu durum, sistemde tanımlı kullanıcı hesapları için gerçekleşiyor. Eğer bir saldırgan yetkili bir hesap bulabilmek için değişik isimler deniyorsa gördüğüm kadarıyla şu an bunu loglayabilecek bir mekanizma göremedim. Bilen ve bu bloga katkıda bulunmak isteyen varsa memnuniyetle yayınlayabiliriz.
Bunu yapmak bana çok daha kolay geldi. /root klasöründeki ./bash_profile dosyasının içine aşağıdaki komut setini ekleyince tüm root loginlerinden haberdar olduk.
# /usr/local/bin/smtp_send.pl -t linuxyonetimi@sirket.com.tr -s “`echo $HOSTNAME` Root login islemi” -f `echo $USER`@company.com.tr -r smtphost.sirket.local
SMTP hizmetinin nasıl kurulacağını ayrıca anlatacağız.
Bir saldırganın ele geçirmek isteyebileceği veya fark ettirmeden değiştirerek root yetkilerine ulaşabilecek bir zaafiyet yaratabileceği noktalardan biri de zaman ayarlı görevlerdir. Bu nedenle root kullanıcısının crontab loglarını da izlemenin faydalı olacağını düşünüyorum.
Buradaki mantık çok basit. /var/log/cron log dosyasının dünkü ve bugünkü hallerini ‘diff’ komutuyla karşılaştırarak farklılık varsa epostayla sistem yöneticisine gönderiyoruz.
# tail -n 20 /var/log/cron|grep -v ‘hourly\|daily\|weekly’ >/root/cron_gunluk_durum
not : grep komutunda ‘içinde A veya B veya C’ geçen satırları filtrele diyebilmek için diziler arasına | konması gereklidir. | OR mantıksal operatörüdür. Ancak |’nin algılanabilmesi için önüne \ (backslash) konmasına da ihtiyaç var.
# /usr/local/bin/smtp_send.pl -t linuxyonetimi@sirket.com.tr -s “`echo $HOSTNAME` root Cron islemleri” -f `echo $USER`@sirket.com.tr -r smtphost.sirket.local -m “`cat /root/cron_gunluk_durum`”
http://www.yellow-bricks.com/2008/01/23/howto-sending-html-email-from-the-service-console/
VMware ESX Server 3.5 işletim sisteminde açılacak kullanıcı hesaplarının belirli bir şifre politikasına uymasını sağlamak için esxcfg-auth komutu kullanılmaktadır.
Aşağıda bu komutun hesap ve şifre yönetimine dair bazı örneklerini bulabilirsiniz.
Şifrenin maksimum kullanım süresini belirler.
# esxcfg-auth –passmaxdays=45
Şifrenin tekrar değiştirilebilmesi için aradan geçmesi gereken minimum gün sayısını belirler.
# esxcfg-auth –passmindays=1
Şifrenin kullanım süresi dolmadan kaç gün önce kullanıcıya uyarı mesajının gösterileceğini belirler.
# esxcfg-auth –passwarnage=36
Hesap kilitlenmeden önceki yanlış şifre deneme sayısı.
# esxcfg-auth –maxfailedlogins=3
vSphere 4.0′in VMware’in resmi web sitesinden indirilebileceğine dair duyuru bugün yayınlandı.
Temp klasörlerinin şişmesi sonucu PC performanslarının düştüğüne dair hepimizin zaman zaman deneyimleri oluyor.
IE 6 kullanan PC’lerde Icsweep.exe adında küçük bir program ile Group Policy’e shutdown script olarak ekleyerek tüm PC’lerdeki tüm kullanıcı profillerinden
C:\Documents and Settings\%USERNAME%\Local Settings\Temporary Internet Files
C:\Documents and Settings\%USERNAME%\Local Settings\Temp
klasörlerini silmeyi başardık. Normal bir batch dosyası ile bunu yapmak profiller arası yetki sorunları ve tüm rastgele klasör isimlerini tahmin etmenin zorunluluğu nedeniyle kolay olmayacaktı. Ancak bu program çok başarılı şekilde yapıyor bu işi.
IE 7 kullanılan bilgisayarlarda ise Rundll ile bir API çağırarak user context altında bu işi yapmak da mümkün. Daha şık görünüyor 
Tercih tabi ki kullanacak kişiye kalmış.
http://www.howtogeek.com/howto/windows/clear-ie7-browsing-history-from-the-command-line/
ISA 2006′da sunucu yayınlama hakkında çok detaylı bilgi içeren, faydalı bir makale yayınlandı.
http://technet.microsoft.com/en-us/library/dd547089.aspx
Bu da birden fazla sayıda Web sunucusunun NLB halinde yayınlanmasını gösteren başka bir makale.
http://www.isaserver.org/tutorials/Explaining-ISA-Server-2006-Web-Server-load-balancing.html
Sun Microsystems, Solaris 10 öğrenmek isteyenler için bir uzaktan öğrenim sistemi oluşturmuş. İlginizi çekebilir. Ancak kayıt olmak gerekiyor.
Windows XP, Group Policy ile ilgili log dosyalarını C:\windows\debug\UserMode altında userenv.log adıyla metin formatında oluşturmaktadır. Bu dosyaların boyu maksimum 1 MB olabileceği için dosya boyunun aşılması halinde, userenv.bak ismiyle arşivlenmekte ve yeni bir dosya açılmaktadır.
Loglama seviyesini nasıl arttırırım ?
XP, varsayılan modda düşük seviyede loglama yapmaktadır. Registry’de yapılacak değişikliklerle loglamayı maksimum seviyeye çıkartmak mümkündür. Bunun için aşağıdaki değerler kullanılabilir. Daha detaylı bilgi için bkz : http://support.microsoft.com/default.aspx?scid=kb;en-us;221833
Subkey: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon
Entry: UserEnvDebugLevel
Type: REG_DWORD
Value data: 10002 (Hexadecimal)
UserEnvDebugLevel can have the following values:
NONE 0×00000000
NORMAL 0×00000001
VERBOSE 0×00000002
LOGFILE 0×00010000
DEBUGGER 0×00020000
Kişisel not olarak, loglamayı maksimum seviyeye çekince (0×00010002) makinayı yeniden başlatmaya gerek kalmadan loglama seviyesinin arttığını söyleyebilirim. Ancak loglama bu seviyede gerçekten çok fazla kayıt üretiyor. Sorunsuz bir PC’de sıradan bir Gpupdate /force sonrası 600 satıra yakın kayıt eklendiğini belirteyim. Bu nedenle, iş bitiminde loglama seviyesinin eski haline döndürülmesi kesinlikle önemli bir detay.
Loglardaki bu kayıtlar ne anlama geliyor ?
Group policy’nin istemci tarafındaki loglaması çoğunlukla anlaşılabilir bir dilde hazırlanmış ve kodlardan çok anlamlı cümleler şeklinde geçiyor. Ancak bazı noktalarda hata kodlarını ve “Return code”ları bilmek gerekiyor. Bu konudaki en detaylı kaynak aşağıda yer alıyor.
http://technet.microsoft.com/en-us/library/cc786775.aspx
Loglarda görülen en büyük eksiklik, saatle birlikte tarih kaydının olmaması. Bu durumda biraz tahmin yürütmek gerekiyor. Aşağıdaki prosesi soldan sağa doğru okuyacak olursak şöyle sıralanıyor.
İşlem kodu, işlemin saati, İşlemin adı, hatanın kısa açıklaması.
Nelere dikkat etmeli
Her GPO’nun bir master ve de bir DC replikası olduğunu hatırlıyoruz. Zaman zaman FRS problemleri nedeniyle replikasyon eksikleri olan şube DC’lerinde GPO’ların eksiksiz kopyalanmadığını da görmüştük. Bir PC’de GPO’nun sağlıklı uygulanıp uygulanmadığını anlayabilmek için aşağıdaki kayıtlara da dikkat etmek gerekiyor. Örnekteki gibi her GPO’nun GPC ve GPT numaraları aynı olmalı. Aynı olması GPO’nun senkron olduğu anlamına gelecektir.
Aşağıda sıralanmış hata örnekleri sıkça karşınıza çıkabilir ancak bizim aradığımız hatalar bunlar değil. Gözardı edebilirsiniz.
1- USERENV(3b8.3bc) 19:13:56:917 MyRegUnLoadKey: Failed to unmount hive 00000005
2- USERENV(3b8.3bc) 19:01:33:705 UnloadUserProfileP: Didn’t unload user profile
Daha yakışıklı hatalar arıyoruz J. Bunlar gibi :
1- USERENV(2c0.c4) 08:39:20:562 GetWbemServices: CoCreateInstance returned 0×800401f0
2- USERENV(2c0.280) 23:28:22:072 ProcessGPOs: GetGPOInfo failed.
Elbette daha dikkat edilmesi gereken bir çok detay var ama bunları da başka bir yazıda aktarmaya çalışacağım.
Microsoft tarafında GPO’larda scriptlerin çalışmasıyla ilgili bir dizi makale yayınlanmış. Bunları okumak da çok yardımcı olacaktır.
The two sides of group policy script extension processing
http://www.microsoft.com/technet/scriptcenter/topics/gp/extension1.mspx
http://www.microsoft.com/technet/scriptcenter/topics/gp/extension2.mspx
İşiniz bittiğinde loglama seviyesini eski haline getirmeyi unutmayın lütfen. Kolay gelsin.
EMC E-mail Xtender 4.81.655 e-posta arşivle yazılımını kullanmanın hayatımıza kattığı bir sürü zihin egzersizleri ve güzellikler (!) var. Bu aralar yaşadığımız klasik bir septomdan bahsetmek istiyorum kısaca.
(Bunu başka bir bakışla EMC’nin değil de Active Directory’nin bir sorunu gibi görmek de mümkün. Bakış açısına göre değişir tabi.)
Exchange ortamında dağıtım gruplarını GAL’in en tepesinde görebilmek için başına boşluk koymak gibi bir yöntem benimsenmiş durumda ortamımızda. Bu boşluk işareti Display Name ve Alias alanlarının her ikisinde de bulunuyor.
Bir şubeyi teker teker kullanıcı bazında değil de DG’ye dayanarak arşivlemeye çalıştığımızda önce Türkçe karakterlerin EX’in shortcut ekranında ş>s vb. klasik Türkçe karakter problemi sonucunda dönüştüğünü ve arşivlemenin çalışmadığını gördük. EMC’ye açtığımız çağrıda ilk olarak sunucunun İngilizce olan dil ayarlarını Türkçe’ye çevirmemizi önerdiler. Bunu yaptık ama hala SQL, indeksleme vb. konulardaki olası yan etkileri hakkında emin değiliz. Hala test ediyoruz. Umarım bir sorun çıkmayacaktır.
Ancak bu adımdan sonra da sorunun düzelmediğini gördük. Bunun üzerine daha önceden başak bir sorundan hatırladığım gibi Alias’daki boşluk karakterini kaldırdım. ve bingo ! Sorun çözüldü.
Şimdi GAL’deki bu boşluk kullanan DG’leri nasıl değiştiririz, en az kullanıcı rahatsızlığı yaratarak bu sorundan nasıl kurtuluruzu düşünüyoruz.
Bir yandan da dil ayarı değişen sunucuda sorun çıkmaması için dua üstüne dua ediyoruz
Uzun zamandır LogParser’ı kullanmayı ihmal etmişim. 2.2 yeni sürümde (en azından benim için yeni) oldukça güzel özellikler katmışlar. Bunları burada saymakla zaman kaybetmeyeceğim. Basit ama etkili bir uygulamamızdan örnek vermek istiyorum.
AD ortamımızda bazı PC’lerin (özellikle uzak noktalardaki PC’ler) Active Directory ile sorunları olduğunu ve Group policy güncellemelerini sağlıklı yapamadıklarını farkettik. Ancak bu makinelerin listesini toplamak zahmetli bir iş olduğundan tüm PC’lerden event log dosyasını belirlediğimiz olay tiplerine göre filtreleyerek araştıracak bir araç aramaya başladık.
Bu noktada tekrar LogParser aklıma geldi
Aşağıda kullandığım komutu bulabilirsiniz.
“c:\program files\Log Parser 2.2\LogParser” -o:CSV “SELECT EventLog, TimeGenerated, EventID, EventType, ComputerName, SID, Message INTO \\XXserver\Pcloglari\%COMPUTERNAME%-%date%.csv FROM Application WHERE TimeGenerated >= TO_LOCALTIME ( SUB ( SYSTEM_TIMESTAMP(), TIMESTAMP( ‘01-02′, ‘MM-dd’) ) ) AND ( EventID = 1058 OR EventID = 1059 OR EventID = 1054)”
Bu komutla Application Event Log içinden “dün” oluşan tüm 1058,1059 ve 1054 nolu olayların çıktısını uzaktaki bir sunucuya CSV olarak alabiliyoruz.
Eğer PC adıyla bir log varsa bu GPO sorununa delil olabilir. Log yoksa o gün o PC’de bir sorun olmamıştır. Çok sayıda çıktının hızlıca değerlendirilmesinde bu mantık da kullanılabilir.
Elbette EventComb gibi araçları da kullanmak mümkün ancak, bu şekilde log toplamak ; eş zamanlı olarak uzaktaki bilgisayarlara bağlanıp kısıtlı data hatları üzerinden senkron olarak bilgi çekmeye çalışmaktan daha makul ve maliyeti düşük bir yöntem.
ISA arrayler kurduk, NLB’ler yaptık ama her seferinde şu garip ADAM problemi nedeniyle ikinci CSS’i kuramıyorduk. Replika olarak ikinci CSS’i kurmak istediğimizde “Setup failed to install ADAM in replica mode error 0×80074e46″ hatası alınıyor ve kurulum gerçekleşmiyordu.
En sonunda yaptığım araştırmada aşağıdaki blogu buldum.
http://www.networkplumbing.org/2007/06/error-0×80074e46-while-installing-isa.html
Test ortamımda da denedim. Gerçekten bir geçici Any > LocalHost rule yazılınca CSS kurulumu yapılabiliyor.
VMware ESX vcenter sunucusunun sanal ortama kurulmasıyla ilgili güzel bir VMware makalesi
ISA Firewall client kullanıcılarının bazı kurumların FTP sunucularına dosya yüklemelerinde sıkıntı yaşamaya başladık. Şöyle ki, dosya indirirken hiç bir sorun görülmeyen bilgisayarlarda yükleme sırasında “Access denied” mesajları alınıyordu.
Yaygın olarak FileZilla FTP istemcisi kullandığımızdan önce bunu FTP programıyla ilgili bir sorun gibi değerlendirdik ve passive / active FTP iletişimini sağlıklı yapıp yapmadığını araştırmaya başladım.
Ancak sorunun çözümü çok ama çok basit bir yerden çıktı.
FTP için oluşturulan her kural üzerindeki sağ klik “configure FTP” yaparak “Read Only” seçeneğini kaldırmak yeterliydi
Yani sonuç olarak bunun pasif veya aktif FTP’yle uğraşmayı gerektirecek kadar derin ve karmaşık bir çözüme ihtiyacı yok.
