SSH ve Public Key Doğrulaması

Sam Williams'ın GNU hareketi ve Richard Stallman üzerine, bu yılın Mart ayında kaleme aldığı "Free as in Freedom" adlı kitabın tamamına Internet üzerinden de erişebilirsiniz.

Kitabın belki de en zevkli bölümü 1. bölüm: Bu bölümde 80'li yılların başında MIT yapay zekâ laboratuvarında çalışan Stallman'ın bozuk bir XEROX yazıcının yazılımına düzeltmek için müdahale etmek istemesi ama XEROX'un kaynak kodunu vermemesi ve sonrasında gelişen olaylar anlatılıyor. Önce efendi ve nazik bir dille derdini anlatmaya çalışan Stallman, insanların "hadi len, biz burada ticari iş yapıyoruz, yok sana kaynak kod, mod, ne halin varsa gör!" demesi üzerine ufaktan bir şok geçiriyor ve "sizin allahınız, kitabınız var mı üleennn!" diye elini kolunu sıvıyor ve GNU isimli organizasyonu kuruyor. (Ve bugün çoğumuzun bu organizasyona ait olduğunu bilmeden, Linux ve benzeri sistemler üzerinde kullandığımız bir ton çok önemli yazılım geliştirilmeye başlanıyor.)

Bilgisayar mühendisliği ile ilgili güzel ve detaylı makaleleri barındıran derginin internet sitesine bir göz atmakta fayda var.

Kısaca bir göz atışta ilgi çeken ve güncel makaleler: Netfilter-1, COSEML, UML ile yazılım modellemesi, yapay zekâ, vs.

Bill Brandon’ın Learning Solutions e-Magazine’de dün yayınlanan “Nine Trends That Will Shape e-Learning in 2008″ başlıklı makalesi bu sene e-öğrenim dünyasında etkili olacak yeni ve gelişmekte olan eğilimleri ele alıp önemli noktalara dikkat çekiyor [1].

Amaç:
Bilgilerin şifreli olarak transfer edileceği bir sftp sunucusu yaratmak.

İhtiyaçlar:
SFTP kullanıcılarını işletim sistemi dosyalarından uzak tutmak. Bağlantıları için kendilerine özel bir chroot yaratmak.
SFTP kullanıcılarının sunucuya ssh üzerinden ulaşımını engellemek.
Becerebilirsek aynı servisi normal sistem yönetimi işlerinde de kullanabilecek şekilde ayarlamak.

Çözüm:
OpenSSH kaynak kodu içerisindeki sftp-server.c dosyasını yamamak ve kullanıcıları sınırlandıran bir kabuk yaratmak.

Nasıl?

Geliştirici dünyası iki kampa ayrılmıştır. Bir kampta dil üstadları vardır, bu yazılımcılar yüksek seviyeli programlamadan -- birinci-sınıf fonksiyonlar, aşamalı programlama, AOP, MOP, kendi kendini sorgulama -- bahsederler. Araç ustaları ise tümleşik geliştirme ve hata ayıklama araçlarında ustadırlar, kod tamamlama, "refactoring", vs. Dil üstadları Emacs ya da VIM kullanır, bu tür editörler yeni dilleri denemek için daha uygundur. Araç ustaları ise Visual Studio, Eclipse, IntelliJ gibi IDE'leri kullanırlar.

Laszlo ve Groovy gibi yeni diller ya da AOP (Aspect Oriented Programming) gibi dil uzantıları genellikle öncelikli olarak metin-editörü tabanlı yazılım geliştirme ortamlarında ortaya çıkarlar ve ancak ondan bir süre sonra IDE dünyası bu tür desteklere kavuşur. Eğer dil ya da uzantı gerçekten başarılı ise araçlar da bunu desteklemeye başlar. Bu ayrımın tek sebebi araç geliştirmenin dil geliştirmekten zor olması değildir. Asıl mesele bir dile hakim olmak ile bir araç setine hakim olmanın çok farklı iki mantalite olmasıdır, belli bir ölçüye dek bunlar birbirlerini dışlayan alternatiflerdir. Acaba neden? İşte sebepleri...

Oliver Steele'nin The IDE Divide başlıklı makalesini tüm yazılım geliştiricilerin okumasında fayda var. (Not: Şöyle sağlam bir FM üyesi çıksa da bahsi geçen makaleyi Türk diline kazandırsa... hani yani küçük bir olasılık olsa da, belki diyorum, belki biri üstlenir, FM'ye bir katkıda bulunur...)