Mesela, Putty’nin -her ne kadar iyi bir SSH client olsa da- sessionları Windows Registry’de tutmak gibi bir adeti var. Bu nedenle, daha önceden tanımladığınız sessionları bir yerden bir yere taşımak ya da backuplamak için registry’i didklemek zorunda kalıyorsunuz. İşte, ilgili adreste tanıtımı yapılan add-on’lar bu ve buna benzer problemlere çözüm getirdiklerinden dolayı ilginizi çekebilirler.

Bu yazı şu ana kadar 7 kez görüntülenmiş.

Belki şu konular da ilginizi çeker:

• Linux’larda SSH Key Saldırısı (0)
• Yazılım Karşılaştırmaları (0)
• Wsus 3.0 - MMC Cannot open the file wsus.msc (0)
• Wsus 3.0 - Manuel Client Configuration Script (0)
• Webmin - Web-Based Unix Management (0)

Bir SSH bağlantısını, bağlanılmak istenen sisteme direk olarak kullanıcı adı ve şifre göndermek sureti ile gerçekleştirebildiğimiz gibi bağlantıyı SSH Key-Based Authentication isimli yöntemle kullanıcı adı ve şifreye gerek kalmaksızın sağlayabiliyoruz. Yönetiminden sorumlu olduğunuz birden çok *nix tabanlı serverınız olması durumunda Key-Based kimlik doğrulama yöntemi elbette işleri epey kolaylaştırıyor.

Bu yöntemde, uzaktaki sisteme bağlantıda bulunacağınız bilgisayarda public ve private key diye tabir edilen iki adet anahtar dosyası oluşturuyorsunuz, Public Key uzaktan erişim sağlanacak hedef bilgisayarda tutuluyor ve Private Key de, key’i oluşturduğunuz bilgisayarda kalıyor.  Kullanıcı private key’ini kullanarak bağlantı isteğinde bulunduğu zaman hedef bilgisayar gelen isteği elindeki public key ile karşılaştırıp doğruluyor bağlantıyı gerçekleştiriyor. Bağlantı sırasında bilmeniz gereken tek şey keyleri oluşturma sırasında belirlenen Passphrase denilen private key şifresi oluyor. Hatta isterseniz Passphrase dahi kullanmayabilirsiniz. Bu uygulamayı *nix tabanlı sistemlerinizde yaptığınız zaman uzaktan erişim işlemlerinde herserverin kullanıcı adı ve şifresini teker teker girmenize gerek kalmıyor.

Ancak, elbette bu uygulama tahmin edebileceğiniz gibi bazı güvenlik açıklarına neden olabiliyor; bu yazının ana konusu da aslında bu.

Key-Based Authentication kullanışlı olmasına rağmen aynı zamanda sistem güvenliğinizin yumuşak karnı da olabilecek bir potansiyele sahiptir. Zira client bilgisayarda bulunan bir private key başkalarının eline geçerse aynen sizin gibi o kişiler de sistemlerinize kullanıcı adı ve şifre olmaksızın bağlanabileceklerdir.

Bunun yanı sıra aslında bu bu yazıyı yazmamın ana nedeni yukarıdaki yumuşak karın mevzusundan çok, US-CERT tarafından 26 Ağustos’ta açıklanan, Linux Tabanlı işletim sistemleri için, key-based erişim uygulamasında keşfedilen bir saldırı yöntemi.

 http://www.us-cert.gov/current/index.html#ssh_key_based_attacks adresinde yayınlanan rapora göre, Linux tabanlı sistemlerde SSH Key-Based authentication kullanılması durumunda ortaya çıkabilecek yeni bir saldırı şekli tespit edilmiş. Buna göre saldırı şekli, ilk olarak SSH keyleri çalarak sisteme login olunup, sonrasında lokal kerneldeki zayıflıklardan yararlanılarak root erişiminin sağlanmasıymış. Root olarak sisteme erişildikten sonra ise sisteme "phalanx2" isimli bir rootkit kurulduğu söyleniyor.

Raporda, Phalanx2′nin amacının sistematik olarak, -key-based auth. konfigurasyonları nedeni ile- güvenilir olarak algılanan diğer sistemlerin SSH keylerini çalmak ve atakta bulunan kişiye göndermekten ibaret olduğu açıklandı. Böylece attacker bu keylerle, ilgili tüm sistemlere erişimde bulunmayı deneyerek sonuca ulaşmaya çalışıyormuş.

Sisteminizde bu rootkitin yüklü olup olmadığını anlamak için aşağıdaki adımlar işinize yarayabilir.

• rootkit /etc/khubd.p2/ dizininde bulunabiliyormuş. Ancak ls komutu ile bu dizini görmek mümkün değil; bu nedenle cd komutu ile dizinin içerisine girmek gerektiği söyleniyor.
• /dev/shm/ dizini altında atakla ilgili dosyaların bulunabileceği belirtiliyor.
• Ayrıca sistemde çalışan gizli bir proses olup olmadığının araştırılması,
• /etc’nin alt dizinlerini count ederek adet bilgisini "ls /etc" çıktısında belirtilen rakamla tutup tutmadığının kontrol edilmesi öneriliyor.

Hal böyle olunca bu ataktan etkilenmemek için, Key’lere muhakkak Passphrase tanımlamak, Tcp erişimlerini gözden geçirmek, sisem patchlerini düzenli geçmek gibi önlemler almak gerekiyor. Hatta belki de key-based authentication yöntemini rafa kaldırmak en iyisi gibi görünüyor.

Bu yazı şu ana kadar 16 kez görüntülenmiş.

Belki şu konular da ilginizi çeker:

• Kullanışlı Putty Add-on’ları (0)
• Webmin - Web-Based Unix Management (0)
• vi - find and replace komutu (0)
• Qmail logs ve timestamp hadisesi. (0)
• Phishing - Western Union (0)

Bu gün posta kutuma, içeriğini aşağıda görebileceğiniz gibi bir mail aldım. Özetle, Western Union’dan geliyormuş gibi görünen ve Moskova’dan Maksim Zverev isimli bir kişiye gönderdiğim Western Union çekinin güvenlik servisi tarafından bloklandığını, ekteki dosya içerisinde bulunan faturanın çıktısını alarak en yakın Western Union şubesine başvurmamı tembihleyen bir mail düştü. Moskova’da Maksim isimli bir tanıdığım olmadığı ve olsa bile Western Union ile kendisine para göndermemiş olduğumdan dolayı ve ayrıca daha önceden -Akbank’ta bir hesabım bulunmamasına rağmen- Akbank tarafından geliyormuş gibi görünen ve hesap bilgilerimi güncellememi isteyen benzer maillerden dolayı, konu hakkında geçmiş tecrübem sayesinde ekteki zip dosyasına itibar etmedim

Mailin içeriği şu şekilde:

From: Berry Humphrey [mailto:tegepjik@quiltbroker.uos.net]
Sent: Thu 8/28/2008 5:47 AM
To: ….@……..com
Subject: Western Union MTCN #1495202428

Hello!
Attention! The wire sent to Maksim Zverev, Moscow, Russia has been blocked by our security service.

Thank you!

Yukarıdaki içeriğe ve ekinde In776162.zip gibi bir isme sahip zip dosyası bulunan mailleri açmadan silmenizi önreririm. Çünkü, bu zip dosyasının içeriğinde clamav’ın Trojan.Zbot-1971 olarak tanımladığı bir trojan bulunuyor. Amacı ise öncelikli olarak PC’nin firewall’unu disable etmek ve önemli finansal bilgileri (kredi kartı numaraları, internet bankacılığı erişim şifreleri vs.) çalmaktan ibaret. Ayrıca screen snapshot alıyor, çeşitli componentleri download ediyor ve sisteme sızması için girişimleri için gerekli ortamı hazırlıyormuş.

Korunmak için antivirüs yazılımlarınızı muhakkak update etmeniz ve maili kesinlikle açmamak gerekiyor. Ben mail trafiğim için  üzerinde clamav.0.92 kurulu bir SMTP Gateway kullanıyorum ancak trojan yeni tanımlanmış olduğundan olsa gerek clamav’ın bu versiyonu trojanı tespit edemedi ve mail posta kutuma düşmeyi başardı. Bunun üzerine clamav’i son sürüm olan 0.93.3′a upgrade ettim. Şimdi tespit edilebiliyor. 

Detaylı bilgi için aşağıdaki adrese bakabilirsiniz.

http://blog.mxlab.be/2008/08/27/western-union-mtcn-troja/

Bu yazı şu ana kadar 32 kez görüntülenmiş.

Belki şu konular da ilginizi çeker:

• Portsnap ile Süratli Ports Collection Güncellemesi. (0)
• Linux’larda SSH Key Saldırısı (0)
• IPFIREWALL ve Snort_Inline ile IPS - Part 1: IPFW Kurulumu (2)
• DNS Cache Poisoning (0)
• IPFIREWALL ve Snort_Inline ile IPS - Part 2: Snort_Inline Kurulumu (0)

Geçenlerde, Huzeyfe Önal’ın bloğunda yeni yayınlanan bir güvenlik açığının haberini okudum ve ilgimi çektiğinden dolayı teknik detayları öğrenmek için biraz araştırdım. Hazır okumuş ve teknik detaylar konusunda fikir edinmişken paylaşmak istedim.

DNS cache poisoning olarak geçen bu zafiyet önlem alınmamış DNS serverları kolayca etkileyebilecek türden bir açık. Bu nedenle önemsenmesi ve gerekli güvenlik önlemlerinin alınması gerekiyor.

Ne gibi önlemler alınabileceğinden önce, bu zafiyetin tam olarak ne olduğu ve nasıl yapıldığına değinmek istiyorum. Zira, bir dns serverınız varsa ve gerekli önlemleri almamışsanız bu zafiyetten etkilenebilir ve dns serverınızı kullanan kişilere yanlış sorgu sonuçları dönmesine neden olabilirsiniz. İşte konunun teknik detayları:

DNS Cache Poisoning olarak adlandırılan bu zafiyet aslında ilk olarak 1993 yılında keşfedilmiş bir açık; geçenlerde yayınlanmış olanı ise yeni bir versiyonu. Geçenlerde yayınlanan veryion ile ilgili US-CERT sayfasına aşağıda belirtilen kaynakça bölümünden erişebilirsiniz.

Konunun teknik detaylarını teorik olarak sadece yazmak aslında pek de açıklayıcı olmuyor; bu nedenle okuduğum pek çok kaynakta da izlendiği üzere örnekler üzerinden anlatma yolu, zafiyetin teknik detaylarını kavramak için epey yararlı olacaktır.

Malum bir dns sorgusu yaptığınız zaman, DNS serverınız -eğer recursive sorgulara izin veriyorsa- ilgili alan adına ait kayıdın kendi üzerinde tanımlı olup olmadığına bakar ve kendi üzerinde bulunan bir kayıt olmaması durumunda kök dns sunucularına bir sorgu göndererek alan adını temsil eden dns sunucusuna ait ipyi alır ve daha sonra bu sunucuya ilgili alan adı için bir query daha gönderir; en sonunda da aldığı cevabı size iletir. Örnekte anlatılan query çeşidi recursivedir ve kendi üzerinde bulunmayan kayıtların cevaplarını sizin yerinize gidip ilgili sunucudan alır.

Zafiyeti anlatan http://www.avertlabs.com/research/blog/index.php/2008/07/23/the-cat-is-out-of-the-bag-dns-bug/ adresinde yayınlanan güzel bir grafik var; daha iyi anlamak için faydalı olacaktır:

Recursive dns query’lerde izlenen yol grafikte anlatıldığı gibidir. Ek bilgi olması açısından non-recursive querylere de değinmek iyi olur. Non-recursive diye tabir edilen query çeşidinde, eğer bir kayıt sorguyu gönderdiğiniz dns sunucuda yoksa gene kök sunucuya danışıp ilgili alan adına ait DNS serverın ipsini alır ve size "Bu alan adına ait kayıtlar bende değil ama kayıtları tutan dns’in ip adresi şudur, gidip ona sor" mealinde bir cevap gönderir; sizin clientiniz de ilgili ip’ye queryi tekrar göndererek cevabı alır. Bu noktada, non-recursive sorgular için dns serverınız etliye sütlüye pek karışmadığından dolayı zafiyetten etkilenme durumu olmaz. Zaten zafiyetten etkilenmemek için alınması gereken önlemlerden birisi de bu non-recursive sorgulara izin vermemek olarak geçiyor.

Konuyu çok fazla dağıtmadan cache poisoning’e dönelim. Yukarıdaki örnekte yapılan sorgu işleminden bahsederken söylemediğim bir durum daha var; örneğin www.cnn.com için recursive olarak bir query gönderdiğiniz zaman dns sunucunuz bu alan adına ait ip bilgisini gidip bularak size getiriyor ve bu bilgiyi bir müddetliğine saklamak üzere cache’ine alıyor. Böylece başka biri daha www.cnn.com için sorgu gönderdiği zaman aynı işlemleri tekrarlamak zorunda kalmıyor. İşte poisoning işleminin yapıldığı nokta burası.

Eğer siz www.cnn.com için recursive bir sorgu gönderdiğiniz zaman birisi, dns serverınız ve cnn.com’un dns serverının arasına girip, cnn.com dns’inden gelmesi gereken cevabı kendisi -yanlış ip içerir bir şekilde- göndermeyi başarırsa, dns serverınızın cacheini zehirlemiş olur. Bu durumda da siz ve dns serverınızı kullanan sizin gibi diğer tüm kişileri de istediği herhangi başka bir yere yönlendirme şansına sahip olur. İşte dns cache poisoning kısaca böyle yapılmaktadır.

Atakta bulunan kişilerin bu işlemi pratikte nasıl yaptıklarıyla ilgili detaylara değinmeden teroik olarak bilgi vereceğim. Zira ben de nasıl yapıldığını denemiş bir kişi değilim. Ancak saldırıdan korunmak için saldırının nasıl yapıldığı hakkında temel olarak bilgi edinmek fena olmaz.

Normal bir dns querysinde karşı tarafa gönderilen request paketi, "source ip", "source port", "destination ip", "destination port", "transaction ID" ve "question" bilgilerini içerir. Kısaca, eğer bir saldırgan, DNS serverınızdan çıkan bir request paketinin Transaction ID’sini ve Source Port’nu tahmin edebilirse,  muhattap olduğunuz DNS serverdan gelmesi gereken response paketini taklit edip DNS Serverınıza yanlış cevap döndürebilir.  Çünkü DNS Serverınız gönderdiği bir request’in cevabı olarak gelen paketi onaylamak için gelen response paketinin destination port’unun request paketinde belirtilen source port ile aynı olup olmadığına ve gelen Transaction ID’nin request paketindeki Transaction ID ile match edip etmediğine bakar. Eğer bu match işlemi doğrulanırsa DNS Server gelen paketin, gerçekten muhattap DNS sunucusunda geldiğini onaylar ve Cache’ine yazar, sonrasında da cliente gönderir.

Yukarıdaki cnn.com örneği üzerinden tekrar düşündüğümüz zaman konuyu daha iyi anlayabiliriz.

Cnn.com’un ip adresini öğrenmek için client pc’nizden (bundan sonra CP -Client PC- diyeceğim) recurvise sorgulara izin veren DNS serverınıza (bundan sonra CD -Client DNS- diyeceğim) bir request gönderdiniz. CD bu domainin kendi üzerinde tanımlı olup olmadığına bakıyor; haliyle tanımlı bir domain olmadığından ve cevabı bilmediğinden dolayı .com kök sunucusuna bu domaine ait kayıtları tutan DNS serverın ( bundan sonra AD -Authoritative DNS - diyeceğim) ip’sini aliyor; şimdi CD, AD’in ipsini bildiğine göre www.cnn.com’un IP adresini söylemesi için AD’ye,  bir request paketi gönderiyor. Saldırı tam bu noktada gerçekleştirildiği için gönderilen paketin ve gelecek paketin içeriğinden olması gerekenleri daha da detaylandırmak iyi olur.

Mesela, Client DNS olarak tabir ettiğimiz DNS serverınızın IP’si 192.168.1.254 ve AD olarak tabir ettiğimiz cnn.com dns serverının IP’si ise 149.174.213.151 olsun. Bu durumda CD’den AD’ye gidecek request paketinin içeriği örneğin aşağıdaki olacak.

"Source IP = 192.168.1.254, Source Port =28912, Destination IP = 149.174.213.151, Destination Port = 53, Transaction ID = 29290, Question = www.cnn.com’un ip adresi nedir ?"

İçeriği yukarıdaki gibi olan udp request paketi CD’den AD’ye gönderildi ve AD’den response paketinin gelmesi bekleniyor. Normalde AD’den gelecek response paketinin içeriği ise şu olmalı;

"Source IP = 149.174.213.151, Source Port = 53, Destination IP = 192.168.1.254, Destination Port = 28912, Transaction ID = 29290, Answer = 64.236.91.21"

Örnekte görüldüğü gibi AD’de gelen paket içerisinde bulunan Destination Port, CD’nin gönderdiği paketteki Source Port ile örtüşüyor. Ayrıca her iki pakette de Transaction ID aynı. Bu durumda CD bu cevabın yetkili DNS serverdan geldiğini düşünecek ve aldığı cevabı -daha sonra aynı işlemi bir daha yapmamak için- Cache’ine yazacak ve CP’ye gönderecektir. Bu örnekte giden gelen paketlerin içerikleri ve eşleşen verilen ile ilgili aşağıdaki gibi güzel bir şema var.

Saldırıda bulunmak isteyen bir kişi yukarıdaki response paketini taklit etmek isterse ve response paketinin Destination Port’unu (yani request paketinin Source Port’u) ve Transaction ID’sini tahmin etmesi gerekecektir. Geri kalan verileri bilmesi için tahminde bulunmasına gerek yok. Zira, doğal olarak CD ve AD’nin IP’lerini biliyor olacaktır. Ayrıca response paketinin Source Port’u olan 53, genel olarak kullanılan DNS portu olduğundan bunu da bilmesi için fazla çaba harcamasına gerek yoktur. Diyelim ki saldırgan bir şekilde Transaction ID’yi ve request paketinin source portunu tahmin etti.  Bu durumda AD’den önce davranıp aynı paketi yanlış answer içerecek şekilde dns serverınıza gönderebilir. Böylece Cache Poisoning saldırısını gerçekleştirmiş olur. Aşağıdaki şema, bu spoof edilmiş response paketinin CD’ye nasıl gönderildiğini göstermektedir.

Transaction ID ve Source Port’unun nasıl tahmin edilebileceğine gelince. Dediğim gibi teknik olarak nasıl yapıldığını hiç denemedim ancak Transaction ID maksimum 16 bitlik bir field içerdiği için bir saldırganın doğru ID’yi tahmin etmesi için astronomik miktarlarda denemeler yapmasına gerek yok; çeşitli metodlar kullanılarak bir kaç bin denemede sonuca ulaşmanın mümkün olduğu pek çok kaynakta anlatılmaktadır . Aynı şekilde request paketinde belirtilen source port’un tahmin edilmesi de özellikle kullanılan DNS server ile alakalı olarak çok ter dökülmeden gerçekleştirilebilen bir durum.

Son olarak, bu atağın kurbanı olmamak için DNS Serverınızın patchlerini geçmeniz yararınızadır. Ayrıca Local DNS cache kullanabilir, recursion sorgulamalara izin vermeyebilirsiniz. Bunun dışında DNS serverınızın kullandığı source portu randomize etmek için giden dns querylerinin source portunu firewall’dan NAT’layabilirsiniz  Detaylı bilgi için aşağıdaki linklerden yararlanabilirsiniz.

Kaynaklar:

http://www.kb.cert.org/vuls/id/800113
http://www.avertlabs.com/research/blog/index.php/2008/07/23/the-cat-is-out-of-the-bag-dns-bug/
http://www.secureworks.com/research/articles/dns-cache-poisoning/
http://www.scanit.be/advisory-2007-11-14.html

Bu yazı şu ana kadar 10 kez görüntülenmiş.

Belki şu konular da ilginizi çeker:

• Phishing - Western Union (0)
• Linux’larda SSH Key Saldırısı (0)
• IPFIREWALL ve Snort_Inline ile IPS - Part 1: IPFW Kurulumu (2)
• IPFIREWALL ve Snort_Inline ile IPS - Part 2: Snort_Inline Kurulumu (0)

Bir MSSQL 2000 serverdaki joblar üzerinde değişiklik yapmak istediğimde "Error 14274: Cannot add, update, or delete a job (or its steps or schedules) that originated from an MSX server. The job was not saved." şeklinde bir hata aldım.  Server üzerindeki joblarda herhangi bir değişiklik işlemi için bu hatayı döndürüyor ve işleme izin vermiyordu.

Bu da ne ola ki diyerekten konuyu google’a danıştığımda bu adreste problemin nedenini ve çözümünü anlatan güzel bir döküman buldum.

Eğer bir Sql 2000 server üzerinde bir takım joblar düzenleyip bir zaman sonra serverın ismini değiştirirseniz, serverın multi-instances özelliğinden dolayı bu sorun yaşanıyormuş.

Çünkü, eski servernamede oluşturduğunuz joblar o anki servername’e atandığı için, ad değişikliğinden sonra bu joblar üzerinde işlem yapmak istediğiniz zaman server, jobların başka bir instance’a ait olduğunu varsayarak bu hatayı döndürüyor.

Yukarıdaki linkte anlatılan işlemleri yaparak sorunu bu karışıklığı çözmem mümkün oldu.

İşlem adımları şöyle;

Bir query analyzer açıp aşağıdaki komut ile Server’ın servername’i ne olarak kaydettiğine baktım.

Sonuç olarak eski servername döndü. Bunun üzerine aşağıdaki komutları çalıştırarak eski servername’i drop edip yenisini set ettim.

Sonra sql servislerini restart ettim.

Not: Eğer ilk query’de server name doğru olarak dönüyorsa yukarıdaki adımları yapmanıza gerek yok. Ancak bundan sonraki aşamayı uygulamak gerekiyor. Ben de server name eskiydi o nedenle drop / set işlemini yaptım.

Yeni bir query analyzer açarak aşağıdaki query ile originating_server kolonunda tanımlanmış servername’i kontrol ettim.

Eğer cevap olarak yeni servername dönüyorsa sorun hallolmuş oluyor. Ancak eski servername dönüyorsa o durumda ilgili kolonları yeni servername olacak şekilde update etmeniz gerekiyor:

Bu işlemlerden sonra sorun çözüldü ve joblarda değişiklik yapabildim.

Ayrıca bkz: http://support.microsoft.com/kb/281642

Bu yazı şu ana kadar 3 kez görüntülenmiş.

Belki şu konular da ilginizi çeker:

• sp_addumpdevice (T-SQL) (0)
• MSSQL - Dump Transaction (0)
• Wsus 3.0 - MMC Cannot open the file wsus.msc (0)
• Wsus 3.0 - Manuel Client Configuration Script (0)
• Windows Vista - Shrink Partition (0)

Eğer, MS Outlook 2007 kullanıyorsanız default bir RSS readerınız var demektir. Ancak Outlook 2003 için üçüncü parti bir yazılım kullanmanız gerekiyor. Bu işi yapan Newsgator isimli bir program mevcut. Ben denedim ve gayet başarılı buldum.

Ayrıca, newsgator’un Windows, Mac, Mobile, Iphone için de versiyonları mevcut. Download etmek için aşağıdaki linki kullanabilirsiniz.

 http://www.newsgator.com/Individuals/Default.aspx

Bu yazı şu ana kadar 4 kez görüntülenmiş.

Belki şu konular da ilginizi çeker:

• Wsus 3.0 - MMC Cannot open the file wsus.msc (0)
• Wsus 3.0 - Manuel Client Configuration Script (0)
• sp_addumpdevice (T-SQL) (0)
• Yazılım Karşılaştırmaları (0)
• Windows Vista - Shrink Partition (0)

Bunun nedeni rm komutuna alabileceğinden çok daha fazla sayıda parametre verilmiş olmasından kaynaklanıyor. Sorunu çözmek için aşağıdaki komut ile önce find yapıp sonra silme işlemine gidebilirsiniz.

EnderUnix’in *nix ipuçlarına yer verdiği http://ipucu.enderunix.org/ adresinde konuyla ilgili bir kaç tane daha değişik yöntem mevcut. Detaylarla ilgili olarak oradan yararlanabilirsiniz.

Ayrıca find komutunun manuel sayfasından da yararlanabilirsiniz.

http://www.freebsdmanpage.com/man/find-1.html

Bu yazı şu ana kadar 9 kez görüntülenmiş.

Belki şu konular da ilginizi çeker:

• count (0)
• Webmin - Web-Based Unix Management (0)
• vi - find and replace komutu (0)
• Top ile I/O monitoring (0)
• Qmail logs ve timestamp hadisesi. (0)

Diyelim ki, büyük ölçekli bir portal yazılımının sistem adminliğini yapıyorsunuz ve günün birinde portalın yeni versiyonu yazılarak uygulamaya konulma aşamasına getirildi ve sistemsel değişikliklerin yapılması için top size atıldı. Ve diyelim ki sisteminiz, içerisinde onlarca ve hatta yüzlerce serverdan oluşan karmaşık bir server farmdan oluşuyor.

Hadi buyrun deployment’a.

Normalde, yeni versiyonun yayına geçirilmesi için sistem tarafında yapılan deployment çalışmaları; web serverlara yeni kodların atılması, sql serverlarda yeni versiyon databaselerinin oluşturulması, eski versiyon datasının yeni versiyon db’sine convert’ü gibi işlerden oluştuğu gibi eski versiyonda olmayan herhangi yeni bir özelliğin devreye alınmasıyla ilgili implementasyonlar, dns kayıtlarında eklemeler, çıkarmalar, smtp altyapısında değişiklikler gibi muhtelif işleri de beraberinde getirebiliyor.

Söz konusu olan sistem bir çok sunucu üzerinde parça parça koşan bir yapı olduğundan dolayı bir sistem admininin böylesi durumlarda epey ter dökeceği aşikardır değil mi ?

İşte Capistrano da, sistem adminleri ter dökmesin, işleri nispeten kolaylaşsın da şu deployment işini kolaycana yapabilsinler diye düşünülmüş bir uygulama.

Ruby dilinde yazılmış bir script uygulaması olan Capistrano ile oluşturacağınız scriptler vasıtası ile serverlarınıza SSH üzerinden bağlanabiliyor ve gerekli deployment işlemlerini otomatize edebiliyorsunuz. 

Ancak open source bir uygulama olduğu için Windows serverlar üzerinde yapılmak istenen deployment işlemlerinde bazı sıkıntılar yaşanması muhtemeldir. Zira serverlara bağlanıp sizin yerinize -önceden tanımladığınız- komutları çalıştırarak deployment yapan Capistrano, serverlara SSH üzerinden bağlanıyor. Eğer windows serverlar üzerinde denemek isterseniz öncelikli olarak Windows’un SSH desteklemesini sağlamanız gerekiyor.

Velhasıl güzel düşünülmüş bir uygulama olan Capistrano’yu denemekte fayda var.

Detaylı bilgi ve dökümanları için web sitesi şöyle: http://www.capify.org/

Bu yazı şu ana kadar 4 kez görüntülenmiş.

Belki şu konular da ilginizi çeker:

• Bandwidth Monitoring - Bandwidthd (0)
• Memcachedb (0)
• Yazılım Karşılaştırmaları (0)
• Wsus 3.0 - MMC Cannot open the file wsus.msc (0)
• Wsus 3.0 - Manuel Client Configuration Script (0)

Mesela içerisinde Armut kelimesi geçen bir text dosyasını vi ile editleyip aşağıdaki komutu verirseniz; tüm Armutlar  Ayva ile replace edilecektir.

:%s/Armut/Ayva

Bu komuta çok fazla işim düşmediğinden ne zaman lazım olsa unutmuş oluyorum. Bu nedenle tarihe not düşeyim dedim .

Daha fazla bilgi için bkz: http://unix.t-a-y-l-o-r.com/VBsr.html

Bu yazı şu ana kadar 12 kez görüntülenmiş.

Belki şu konular da ilginizi çeker:

• Webmin - Web-Based Unix Management (0)
• Qmail logs ve timestamp hadisesi. (0)
• Argument list too long… (0)
• Top ile I/O monitoring (0)
• Squid ile web sitelerini manupule etmek. (0)

Döküman olması açısından, detaylı bilgi ve güzel bir sunumuna aşağıdaki linklerden erişebilirsiniz.

http://memcachedb.org/
http://memcachedb.org/memcachedb-guide-1.0.pdf

Henüz uygulama şansım olmadı ama belki bir gün deneme fırsatım olursa detaylı Türkçe bir döküman hazırlarım elbet.

Bu yazı şu ana kadar 10 kez görüntülenmiş.

Belki şu konular da ilginizi çeker:

• sp_addumpdevice (T-SQL) (0)
• Capistrano (0)
• Bandwidth Monitoring - Bandwidthd (0)
• Yazılım Karşılaştırmaları (0)
• Wsus 3.0 - MMC Cannot open the file wsus.msc (0)