[Gelistirici] Ahenk 2.0 Planları

[Gürer Özen]

On Friday 17 April 2009 12:01:14 Emre Erenoglu wrote:

> policyleri ldap'ta tutmak, cok kisir bir deklaratif dil kullanmak demek.
> (sadece key=value diyebiliyorusunuz, bence kotu fikir.)

O kısır dille Active Directory gayet güzel çalışıyor ve piyasayı ele geçirmiş 
durumda. Yönetim işinde çalışan elemanlar ve 3. parti yazılımlar bu yapıları 
ve protokolleri iyi biliyorlar. Kurumların halihazırdaki dizin yapılarını 
bozmadan bizim LDAP'a aktarmak ve kullanmak çok kolay. Unix adminlere 
puppet'ı satmak kolay olabilir ama kurumlara pek öyle değil maalesef.

> yine deklaratif bir dil kullandigi icin  puppet dilinde policy ureten
> bir gui yazip istemci yonetimini puppet vasitasiyla yapmak daha kisa
> zamanda daha guclu bir urun ortaya cikmasina yardimci olacaktir. (gui
> ile policyleri uretin, gerisini puppet yapsin)

İstemcideki ajana yazacağımız kod yerine gui tarafında script üretici kod 
yazıyoruz, toplam emek değişmiyor pek.

Şunu da belirteyim, Ahenk toplamda birkaç yüz satır kod ile kullanıcı, yazılım 
güncelleme ve servis yönetimi yapabiliyor zaten şu anda. Bunu eldeki LDAP, 
Çomar, Pisi'yi kullanarak ve Python ile kodlayarak sağladık.

Kendi arayüzümüz çok gelişmiş olmasa da iş görüyor, ve halihazırdaki bir ton 
LDAP arayüzü ile çalışabiliyor bu sistem.

> boylece hem gui isteyen 
> insan hem de script yazmak isteyen insani mutlu edebiliriz.

puppet'a ihtiyacı olan puppet'ın kendisini kurup kullanabilir zaten. puppet 
yada cfengine kullanmayın demiyoruz ki.

> bu dagitim isi guvenilir(?) it personeli tarafindan elle yapilacaksa
> sorun yok. ama pratikte bu islem otomatik yapilacaktir.

Sertifika dağıtım işi konunun dışında bir problem. Onu tartışmaya girersek 
içinden çıkamayız. Ama her güvenlik yönteminde bu tür problemler vardır. Bunu 
çözemeyecek bir kurumun Kerberos'u kurup takır takır çalıştırabileceğine 
inanmıyorum :)

> peki kerberos bunlari nasil cozer ? cok basitlestirilmis bir sekilde:
> istemci, kerberos sunucusuna (AS) kullanici adini cleartext olarak
> gonderir. kerberos sunucusu encrypted bir mesaj gonderir. mesajin
> sifresi kullanicinin sifresidir. istemci kullanicinin girdigi sifre ile
> gelen mesaji decrypt eder ve ortaya cikan yeni mesaji TGS'ye gonderir.
> eger TGS gelen mesajdan birsey anlayabilmisse (== sifre dogruysa)
> istemciye bir ticket gonderir. vesaire.

Yani simetrik şifreleme var. Peki burada her bilgisayarın kendi şifresini 
bilmesi gerekmiyor mu? Bunun pratikte sertifika dağıtımı probleminden farkı 
nedir?

> son olarak belirtmek istedigim bir nokta var ki o da su: kriptografi ile
> hobi olarak ugrasan birisi olarak(asil isim istatistiksel dogal dil
> isleme), kriptografide turkiyenin et yetkin kurumu olarak bildigimiz bir
> kurumun calisanlarina kriptografi anlatirken ellerim terlemiyor degil.

Bir yanlış anlaşılma olmasın, bildiğim kadarıyla Pardus geliştiricilerinin 
hiçbirinin UEKAE'nin kripto gruplarıyla bir alakası yok. Çalıştığım sürede 
enstitüden bu konuda herhangi bir bilgi destek alındığını da görmedim 
duymadım. Sorarsak bilgi verirler mi ondan da emin değilim :)