[Gelistirici] Ahenk 2.0 Planları
Gürer Özen
gurer at pardus.org.tr
17 Nis 2009 Cum 12:53:23 EEST
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 :)
Gelistirici mesaj listesiyle ilgili
daha fazla bilgi