August 30, 2010
ptsp_installer projesi ile ilgili, daha önce de yapacağım dediğim, dosyaları düzenlerken girdilerin varlığı kontrolünü ekledim.
Şimdilik hosts ve exports dosyasındakilere bakıyor, dhcpd.conf dosyasında eskisi gibi kalıyor. Bu kontrolü ilk başta:
for line in file_pointer.readlines()
şeklinde yapıyordum. Fakat bu şekilde yapmanın bir açık/sorun yaratabileceğine karar verdim ve bu döngülerden önce:
orig_exports = file_pointer.readlines()
ya da
orig_hosts = file_pointer.readlines()
yapıyor ve ondan hemen sonra da:
file_pointer.close()
yaparak dosya ile işimi bitiriyorum.
Bundan sonra da for döngüsü ile satır satır okuyarak içinde IP'leri arıyorum. Eğer yok ise bunları bir string'e aktarıyorum. En son ise dosyayı "w" modunda oluşturarak (yok ise yarat var ise üzerine yaz) hepsini:
file_pointer.writelines(new_hosts)
veya
file_pointer.writelines(new_exports)
ile yazıyordum. Şimdilik bunlar sorunsuz çalışıyor. Bir sonraki iş olarak dhcpd.conf dosyasını da bu şekilde düzenlemek var.
Guestlogin projesinde de en son Onur'un fikri olan girişte parola sorma fikrini nasıl uygularız diyordum ve aklıma daha önce de gelmiş olan başka birisinin o kullanıcı adı ile giriş yapmasını nasıl engelleriz diye düşündüm. Ben, guestlogin.py üzerinden eğer kullanıcı adı guestX şeklinde ise reddet desem bile bir sonraki modül olan pam_unix burdan giriş yapılmasına izin verecektir.
Şimdilik aklıma bununla ilgili bir çözüm gelmiyor ama bunun bir sorun olacağı kanaatindeyim çünkü bu kullanıcı çıkış yaparken bütün verileri de silinecek ve öbür oturumdaki kullanıcının oturumu muhtemelen kilitlenecek. Bunu önlemenin bir yolunu bulmak lazım.
30 August 2010 @ 09:00 PM
August 28, 2010
Son olarak kısa bir kaç şey yazmak istedim.
Bence bir bilgisayar mühendisinin ve ya Linux ile ilgilenen, kendini geliştirmek isteyen herhangi birisinin kesinlikle gelip görmesi/staj yapması/çalışması gereken bir yer. Ben 20 iş günlük staj süresi boyunca bir çok şey öğrendim. Geliştiriciler hakikatten çok iyi insanlar. Yani kelimeler ile anlatmak gerçekten mümkün mü bilmiyorum ama süper diyelim şimdilik. (bir kelime bulursam ya da bulunursa yazacağım bunu :) )
Buradan herkese tek tek teşekkür ediyorum. Bana bu staj süresinin çok zevkli geçmesini sağladılar. Her gün yeni bir şeyler öğrenme heyecanı gerçekten çok güzel bir şey. (zaten böyleydi ama burada ve Necdet Hoca'nın yanında gerçekten bir başka oluyor bu)
Süper ya :)
28 August 2010 @ 03:21 AM
Eveeeet, işte geldik stajın son gününe. Bugün ayrıca yaptığımız projeler ile ilgili bir sunum yapacaktık. Sunumlarımızı yaptık ve stajlarımızı tamamladık.
Sunumlara geçmeden önce yaptıklarımdan bahsedeyim. Öncelikle kdm için yapmış olduğum yamadaki ufak bir hata (aslında blog'a doğru yazmış olduğum ama yamaya yanlış geçirdiğim) sorunu çözmemi biraz geciktirdi. Bugün Fatih'in göstermesi sayesinde SVN'deki yamayı düzelttim. Son yama, Pardus 2009 için hem guestlogin'in hem de AutoLogin'in sorunsuz çalışmasını sağladı.
Yamanın eski hali şu şekilde idi
if (!curuser || psrv != "kde4-np" )
burda psrv'nin tipi char'a pointer olduğu için bir adres döndürüyordu ve "kde4-np" dizgisi (string) de bir adres döndürüyordu ve doğal olarak bunlar aynı olmuyordu. Bu yüzden yama yüzünden AutoLogin çalışmıyordu. Fakat bunu denemek için yazılan ufak C kodu çalışabilir çünkü psrv = "kde4-np" dediğinizde sanırım bir eniyileştirme (optimizasyon) yapılarak adresler eşitleniyor böylece yukarıdaki if sorunsuz çalışıyor. Ama kesinlikle yanlış. Demek ki dikkat etmek gerekiyormuş, dalgınlığa gelmiyor :)
Yamanın sondan bir önceki hali şu şekilde idi: (sadece if kısmı, zaten sadece burası değişiyor)
if (!curuser || strcmp(psrv, "kde4-np") ) {
Fakat sunum sırasında Onur bunun yerine strncmp kullanmamın daha güvenli olduğunu söyledi, anladığım kadarıyla strncmp ile strcmp arasındaki fark da strncmp yaparken ikinci verdiğimiz parametrenin uzunluğu kadar karşılaştırma yapıyor. Yamada bu olay daha iyi anlaşılıyor. Yamanın son hali:
if (!curuser || strncmp(psrv, "kde4-np", strlen("kde4-np"))) {
yani burda karşılaştırma "kde4-np" nin boyutu kadar olacak. Tabiki de bu yamayı da upstream'a yolladım. Upstream'a bizim yama haricinde KDM'deki bug'un çözümü olan yamayı da yolladım. Aradaki tek fark || yerine && kullanıyor olmam. Bunun sebebi de bizde PluginsLogin=generic iken curuser NULL olması gerekirken bir değer atanıyor. (kullanıcı adı) Bu yüzden OR kullanıyorum. KDM'deki bugda da buraya girmesini engellemek gerekiyor. (AutoLogin aktif iken) Bunun için de AND ile "kde4-np" ye eşit olup olmadığını kontrol ediyorum.
Ayrıca bugün bir de bu projeyi Pardus 2011'de de denedim. İlk olarak pam_python paketini oluşturmam gerekiyordu. Zaten review'de olan paketin inşa dosyalarını SVN ile çektikten paketini yapmaya çalıştım fakat henüz python-sphinx paketi daha depoya girmediği için hata veriyordu. Makefile içerisinde dökümantasyonu kapatıp bunu bir yama ile inşa dosyalarına koydum ve paket sorunsuz oluştu. Kurulum da sorunsuz tamamlandı. Guestlogin ile ilgili yapılandırma ve betik dosyalarını gerekli yerlere koyduktan sonra /etc/pam.d/system-auth dosyasında gerekli eklemeleri yaptım. Konsolda sorunsuz çalışıyordu. Sırada KDM vardı. KDM'de çalışabilmesi için kendi yamamı 2011'deki kdebase-workspace'in içine koyup derlemem gerekiyordu. Derleme sırasındaki bir kaç bağımlılıkla ilgili olan sorun sebebiyle (derleme zamanı bağımlılığı eksikliği: akonadi-devel ve docbooc-xml4_2) derlenmiyordu. Bunları Fatih'in yardımıyla hallettim. Aynı zamanda da bu eksiklikleri paket sorumlusuna da bildirdim. İkilik dosyalar oluştuktan sonra KDM'yi sistemden kaldırıp yeni oluşturduğum halini kurdum ve sorunsuz çalıştı. Yani projem Pardus 2011'de de çalışıyordu.
Bir de Onur'dan gelen bir istek olan, misafir kullanıcı giriş yaptığında kullanacağı parolanın sorulmasını araştıracağım. Mesela KDE'de oturup kilitlendiği zaman kullanıcının parolası soruluyor. Aslında misafir kullanıcı sırasında bu kapatılabilir ama parola işlemi mantıklı gözüküyor. Bunu araştırıp uygulamaya çalışacağım.
Şimdilik aklıma gelenler böyle, tabi ki de Pardus'a vereceğim desteğe her zaman devam edeceğim. Bu zaten staj ile sınırlı değildi (daha öncesinden) ve bundan sonrasında da devam edecek.
Ayrıca yapmış olduğum sunumu SVN'e koyacağım. Koyduktan sonra buraya yine adresi vereceğim.
Staj boyunca bana her konuda yardımcı olan herkese, bütün Pardus çalışanlarına çok teşekkür ediyorum.
Staj bitti diye de yazmayı bırakmayacağım tabi ki. Araştırmaya, kendimi geliştirmeye, bir şeyler öğrenmeye devam edeceğim. Ve bunları da buradan aktarmaya çalışacağım.
28 August 2010 @ 03:05 AM
August 27, 2010
Tıpkı telif hakları meselesinde olduğu gibi, içine girdiğimiz dünyada baskın olanın bir de ezelden beri var olduğunu düşünmek kolay oluyor ve bir çok insana aslında yazılım geliştirme (daha gündelik dille ‘program yazma’) sürecinin aslında en başında özgür olduğunu, sonradan mevcut sahipli iş modellerinin çıktığını anlatmak zorlaşıyor…
Güzel dilimizde bir deyiş “böyle gelmiş böyle gider…” karamsarlığıyla özetler bu durumu. Böyle gelmiş olması, oradaki “ezelden beri” imasını da koyuverir ruhumuz duymadan. Öyle değildir halbuki.
XIX. yüzyılın sonlarına doğru ortaya çıkan telif hakları ve fikri mülkiyet kavramı var olana kadar gayri maddi mülkiyetin doğal hali kabaca bugün kamu malı (public domain) olarak adlandırılan biçimdeydi. Fikri mülkiyet epeyce yeni ortaya çıktı ve hatta XX. yüzyıl ortalarına kadar tüm dünyada bu kavramdan aynı şey anlaşılmıyordu. Aynı şekilde ticari ve sahipli yazılım modeli geliştirilene kadar, programcılar ürettikleri kodları paylaşır, herkes kodu kendi ihtiyacına göre düzenler ve kullanırdı.
Böyle masal gibi anlatırken kullandığımız terim ve kavramlar, geçmişte farklı anlamlarla var olabilir, bunun da altını çizmek lazım. Örneğin o gün “kendi ihtiyaçlarına göre…” denilen şey bir yapılandırma farklılığı değil, daha çok var olan programı eldeki bilgisayarda çalışacak hale getirmek anlamını taşıyordu. Eh, programların neredeyse tamamen kişisel üretimler olduğunu (bir grup olarak hazırlansa bile, o grubun ‘şahsına özel’ biçimler içerdiğini) hatırlamak gerekiyor. Daha da önemlisi, programlama dillerinin bugünkü gibi olmadığını, yaygın, doğal dile benzeyen ve sürümler halinde sunulan çerçeveler yerine (Python gibi) kadim dillerin (Assembly gibi) kullanıldığını da ekleyelim.
Özgür yazılımın bilindik tarihi
Özgür yazılım meraklıları mutlaka defalarca dinlemiştir, Richard Stallman bir gün kullandığı yazıcının yeni modeli gelince bakar ki daha önceki modelde şikayet ettiği bir özellik hâlâ aynı. Önceki modelde sürücüye bir yama yaparak istediği işlemleri yapmaktadır, fakat yeni modelle birlikte sürücü kaynak kodu gelmemiştir. Firmayı arar, firmadakiler sürücü kaynak kodu şirketin fikri mülkiyetinde olduğu için paylaşamayacaklarını söylerler. Stallman eski köye gelen bu yeni adeti çok isabetli biçimde okur ve “bütün firmalar böyle davranırsa, elveda hacker kültürü, elveda programcılık, her şey standart ve hata dolu ürünlere dönecek, işin bütün esprisi kaçacak…” diye düşünür. (Bu konularda Türkçe okunabilecek kitaplar LKD tarafından listelenmiş durumda)
Yine bir parantez, Stallman’ın o sırada yapay zeka araştırmaları yapan bir ekibin üyesi olarak çalıştığını, içinde bulunduğu ortamı şekillendiren özellikler arasında meseleye neredeyse hobi olarak yaklaşmakla paralel sayılabilecek bir amatör hevesin ön planda olduğunu kaydetmek lazım. Bu kabaca hacker kültürü diye adlandırabileceğimiz ve bugün neredeyse her türlü bilişim teknolojisini borçlu olduğumuz bir birikim…
Velhasıl, özgür yazılım hareketinin tohumları Stallman tarafından o gün bu aydınlanma üzerine atılıyor. GNU hareketi, (olasılıkla o yıllarda her türlü sisteme kaynaklık eden, bir çeşit Lingua franca olduğu için) Unix benzeri bir sistem yaratma fikriyle başlıyor. Yani Unix bilenlerin kolayca kullanabileceği, onun yapabildiği her şeyi yapabilen, ama özgür yazılım olan bir işletim sistemi.
Linux sözcüğünün hikayeye katılması
Tabii burada özgür yazılım nedir sorusu doğuyor. Stallman’ın dört özgürlükle özetlediği şey aslında bir felsefe. GNU projesi de, bu felsefesi destekleyen, paylaşan kişilerin katkılarıyla bir gün tamamlanacak olan bir işletim sistemi hayali denebilir. Projenin tamamlanması için kritik bileşenlerden biri Hurd çekirdeği. Bu çekirdek istenen olgunluğa gelmeden (2011 yılı itibariyle gelmiş sayılır mı, o bile tartışmalı bana göre) Linux projesi çıkıyor (1991) piyasaya… Aynı amatör ruhla başlayan proje, GNU projesinin özgür yazılım modeli ve devamında bunu güvence altına almak için önerilen Genel Kamu Lisansı (GPL) ile çığ gibi büyümeye başlıyor. Böylece eksik parçanın da yerine oturmasıyla resim tamamlanıyor.
1984 yılı, GNU projesinin doğuşuna paralel olarak Orwell’in meşhur distopyasının ismi olarak kötü çağrışımlara da sahip bir yıl. Aynı yıl Apple firmasının Mac OS kullanan bilgisayarları sektörde grafik arabirim (GUI) kullanan ilk yaygın sistemleri sunuyor. Bu kırılma noktası Apple’ın kurucu ortaklarından, şimdiki patronu Steve Jobs’un kurduğu NeXT firmasının BSD çekirdeği ile inşa ettiği NeXTSTEP platformu sayesinde gerçekleşiyor. Çok kısa sürede GNU projesi de GNUStep ile benzer bir atılım gerçekleştiriyor. (O yıllarda alınan ekran görüntülerine bakacak olursanız, aslında Mac ile Linux’un o günlerde ne kadar aynı yollarda ilerlediği görülebilir. Sonra epey ayrılıp, uzun yıllar sonra tekrar benzemeye başladılar… Ama bu başka bir yazının konusu)
Bilgisayar dünyasında yaşanan diğer gelişmeler
Çok yüzeysel bir özetle toparlayacak olursak, 80′li yılların ortalarına doğru, oda büyüklüğündeki bilgisayarlar ve onlara bağlı çalışan terminaller dünyasından, bugünkü bilgisayarlara doğru giden sürecin belki de en kritik dönüm noktaları peşpeşe yaşanıyordu. GNU hareketi ve özgür yazılımlar da bu bağlamda sürecin başından beri belirleyici aktörleri arasında yer aldı. Bu durum nasıl böyle uzun yazılarla anlatılmak zorunda kalınacak hale geldi diye bakınca, üçüncü önemli hattı da özetlemek gerekli.
Çok bilgim olmadığı bir konu ve araştırıp detay topladıkça bu yazı bitmeyecek gibi görünüyor, bu yüzden yine çok yüzeysel bir özetle; IBM ve Microsoft firmalarının birlikte evlerde rahatlıkla kullanılacak ölçekte bilgisayarlar yapmaya giriştiler. Projenin bir noktasında kırılma yaşandı, Microsoft, Windows adını verdiği grafik arabirime dayalı işletim sistemini çıkardı, IBM de ürettiği bilgisayarları OS/2 adıyla satmaya başladı.
Bu, bir çok harika özelliği ilk kez deneyimlediğimiz işletim sistemi bir yandan Windows ile bir yandan da IBM’in Linux’la flörtüne karşı çok arkasında durulabilen bir ürün olmayınca öldürülecekti… Sahipli bir yazılım olduğu için teknolojilerinden faydalanmak çok mümkün olmadı. Sadece sesli komutla işletilmek gibi özellikleri sağlayan kodları Apache Vakfına hibe edildi… Hâlâ özgür yazılım dünyasıyla içli dışlı olmayı bir şekilde önemseyen IBM’in neden bu projenin kaynak kodlarını açarak bir noktada özgür yazılım camiasının bir parçası haline getirmediğini anlamakta zorlanırım.
Bilgisayarların firmalara, fabrikalara, işletmelere özel üretim araçları olmaktan çıkıp, evlerde de kullanılabilmelerinin önünü açan şey tamamen ekonomikti bu açıdan bakınca. IBM’in kişisel bilgisayar (personal computer) adını verdiği ölçekteki cihazlar, bir süre sonra bilgisayardan anladığımız şey haline gelecekti…
Stallman ve Torvalds gibilerin ve GNU projesine dahil olan bir çok programcının aksine saydığım diğer aktörler sahipli yazılım modelini tercih ederek, geliştirilen teknolojileri firmalarının fikri mülkiyetleri olarak tescil ettiler. Stallman endişelerinde haklı çıktı. Bugün bir adım ötesine geçerek, bu teknolojilerin patentlerini de almaya çalışmaları durumu daha da vahim hale getiriyor. Bu da başka bir konu…
Özgür yazılım dünyasının iç dinamikleri ve sektör
Bu geniş tarihçeden (aslında konuya bakılırsa kısa özet de denebilir ama…) sonra asıl tartışmak ve bahsetmek istediğim konuya bağlayabilirim sanırım… Stallman yazılımların sahipleri olması fikrini analiz ederek geliştirdiği modelde bir çok aksiyom yer aldı. Bunların büyük kısmı adı konmuş, hatta lisansa yazılarak yasal hale getirilmiş aksiyomlar… Fakat çok temel bir tanesi var ki, tam olarak somutlaştırılmadığı için bir çok tartışmaya kaynaklık ediyor olmasına rağmen, kendisine ulaşamıyor, etrafında dolanıyormuşuz gibi geliyor.
Özgür yazılım dünyasında amatör bir ruh dolaşıyor…
Stallman bence, GNU’yu ortaya çıkartan isabetli tespitine paralel olarak, şöyle bir tespit daha yaptı: “Yazılım geliştirme kültürü ve bunun sonucu olarak yazılımlar, her zaman gelişim süreci devam eden, hevesi ve kişiselliği barındıran biçimini korumalı. Eğer endüstri bu ortaya çıkan yazılımları ürün olarak, paketlenebilir mal olarak kullanamıyorsa, bu onun sorunu… Kullanıcılar da, bu kültürden faydalanan yazılımlarla, bunun onlara sunduğu özgürlükle çalışmayı hak ediyorlar. Kim bilir hangi hataları ya da açık bırakılmış arka kapıları, kötü niyetli yazılımlara geçit veren abuk subuk mimarileri içeren sözüm ona ürünleri değil…”
Bu, tamamen benim Stallman’ın hareketleri ve söylemlerinden yola çıkarak vardığım bir niyet okuma… Tamamıyla haksız olabilirim, bu tartışılabilir… Fakat günümüzde 600′den fazla Linux dağıtımı varken, GNU sitesinde, projenin kurallarına uygun kabul ettiği dağıtım sayısının sekiz (8) olması bir şeyler söylüyor.
Özgür yazılım, açık kaynak, F/LOSS, FOSS… Nedir bunun adı?
Aslında özgür yazılım camiasındaki ayrışma belki de bütün bu kocaman ailenin artık farklı isimlerle bölünmüş, akrabalık ilişkileri devam eden bir sülale olmakla yetindiğini düşündürebilir. Bu ayrım, en iyi özgür yazılım (free software) / açık kaynak (open source) terimlerinin kullanımında ortaya çıkıyor gibi görünüyor. Bu konuda yaşananların tarihçesi bir vikipedi sayfasında İngilizce olarak anlatılmış.
Kısaca özetlemek gerekirse, ayrım bugün Firefox ile tüm dünyada haklı bir üne sahip olan tarayıcının doğuşuyla, daha doğrusu Netscape firmasının Navigator adlı web tarayıcısının kaynak kodlarını Mozilla projesi ile dağıtacağını açıklamasıyla başlıyor. 1998 yılında kurumsal iş dünyasında İngilizce terminoloji karışıklığının da etkisiyle (free sözcüğü hem özgür hem de bedava anlamına gelebiliyor) özgür yazılımın yeterince karşılık bulamadığını, firmaların kendi ürünlerini özgür olarak geliştirmek bir yana, bu şekilde geliştirilen ürünleri kullanmak ya da ortak projelere girişme konusunda çekinceleri olabileceğini öne süren bir grup, “açık kaynak yazılım” teriminin tercih edilmesini önermişler.
Bu bir grubun içinde kimler mi var? Kimler yok ki demek de mümkün. PGP’nin yaratıcısı ve sonrasında VoIP şifreleme metodları konusunda da önemli katkılar veren Phil Zimmermann, Python programlama dilinin yaratıcısı Guido van Rossum, bu alandaki önemli eserlerin yayınlanmasını sağlayan, bir anlamda modeli yayın dünyasına taşıyan Tim O’Reilly, Linux çekirdeğinin ana geliştiricisi Linus Torvalds, dünyaya SourceForge gibi bir geliştirme platformu sunan isimlerin başını çeken Larry Augustin, Türkiye’de daha çok tufaya getirilip meren’e h selamı yapmasıyla akıllara kazınan, dünyada ise Linux International’ın başındaki kişi olarak bilinen Jon “maddog” Hall gibi, bugün özgür yazılım dünyasını bildiğimiz haline getirmek için çok kıymetli katkıları olan bir sürü isim. Ha, bir de Eric Raymond…
Bu ekibin Kaliforniya’daki bir konferansta ortaya attığı fikri takiben Eric Raymond ve Bruce Perens önderliğinde Açık Kaynak İnisiyatifi (Open Source Initiative – OSI) doğuyor ve tıpkı Stallman’ın dört temel özgürlüğü gibi, bir yazılımın açık kaynak olarak adlandırılması için hangi kurallara uyması gerektiği konusunda bir belge hazırlıyor. Bu belge de aslında Bruce Perens’in, Debian sosyal sözleşmesinin bir parçası olarak hazırladığı Debian Özgür Yazılım Yönergesi (The Debian Free Software Guidelines – DFSG) taslağından, Debian’a özgü kısımların çıkartılmasıyla meydana geliyor.
Bugün her ne kadar stratejik ve taktik anlamlarda FSF ve OSI (ve belki Linux International ve Linux Foundation ve başka bazı kurumlar/oluşumlar) bir arada tek bir camia olarak algılanıyor ve bunun adı kimi zaman “Linuxçular” kimi zaman “özgür yazılımcılar” kimi zaman da “açık kaynak” diye konuyorsa da, aslında ortada net bir ayrım var. OSI yaklaşımı çok daha pragmatik ve endüstrinin kurallarına uyarak, bir parçası olarak ona yön vermeyi hedefliyor. FSF ise çok daha ilkesel bir duruştan yola çıkarak, o ilkelerle uyumlu olduğu sürece endüstriyle ortaklaşıp, yön verme kısmında tavsiyelerinin dinlenmesini bekleyen bir havada…
Bugün felsefi olarak GNU projesi ve -deyim yerindeyse ruhani- lideri Stallman’ı sözünden çıkılmayan büyükbaba gibi görmeyi bırakmamış olsa da, bir çok dağıtım OSI’nin çizdiği pragmatik yolu takip ediyor. Zira, toplam kullanıcı sayılarının 20-30 milyon olduğunu iddia eden en büyük üç dağıtım (Ubuntu, Fedora, OpenSuSe) bu popülerliğe Stallman’ın amatör ruhun korunumu ilkesini kenara koymadan varmayı başaramazlardı. Burada kastettiğim özgürlük ilkeleri ya da başka ilkeler değil. Stallman’ın adını bir türlü koymadığı, net biçimde belirleyip ilke haline getirmediği amatör ruh yaklaşımı…
Geçtiğimiz günlerde kaybedişimizin üzerinden 25 yıl geçmiş olan Turgut Uyar bu hissiyatı “acemilik efendimiz” diye tarif ediyor:
“Efendimiz acemilik. Bir taş alacaksınız, yontmaya başlayacaksınız. Şekillenmeye yüz tutmuşken atacaksınız elinden. Bir başka taş, bir başka daha. Sonunda bir yığın yarım yamalak biçimler bırakacaksınız. Belki başkaları sever tamamlar. Ama her taşa sarılırken gücünüz, aşkınız korkunuz yenidir, tazedir. Başaramamak endişenizin zevkiyle çalışacaksınız.”
Bir sonuca varacaksam…
Kişisel olarak özgür yazılım yaklaşımında, felsefesinde heyecan verici bulduğum şeylerden biri de bu aslında. Başına geçtiğim bilgisayara iyice yabancılaşarak, onu bir televizyon ya da başka bir “ürün” gibi değil, içinde olup bitenlerle ilişkimin güçlü olduğu bir araç olarak kullanma hevesi… OS/2′nun öleceği belli olduğu günlerde Linux’la tanışmam tesadüfi olmuştu; ama ona olan sevgim hiç de tesadüfi değildi.
Apple meşhur iPad’i tanıtmaya başladığı günlerde bir blog yazısı okudum. İlk bilgisayarının bir Commodore 64 olduğunu anlatan yazar, o bilgisayar üzerinde Basic programlama diliyle yaptığı denemelerin bilgisayarla arasındaki ilişkiyi tarif ettiğini, bugün bir programcı olmasını o bilgisayara borçlu olduğunu düşündüğünü yazdıktan sonra soruyordu, iPad ile büyüyen çocuklar, programların “yazılıyor” olduğunu bilecekler mi acaba?
Bugün netbook adı verilen dizüstü bilgisayarlardan biraz daha hafif ve az donanımlı, ama daha uzun süre pil ömürlü ve taşınabilirliği artmış olan donanımlar popülerleşiyor. Basitliği sadece işlev anlamında değil, fiyatlarına da yansıdığı için tek yapacağı e-postalarını takip etmek, arada İnternet üzerinden çeşitli bilgi ya da servislere ulaşmak olan insanlar bu kolaylığı cep telefonlarında ya da bu tür daha taşınabilir cihazlarda arıyorlar. Bu tür cihazlar üzerinde Google’ın Android’i ya da Intel’in Moblin’i gibi tercihler çok rağbet görüyor. Yani bu alanda belki kişisel bilgisayarlardan ziyade sunucu dünyasındaki gibi erken bir özgür yazılım etkinliği, baskınlığından bahsedilebilir… Bu başlı başına bir başarı mı? Bu biraz da bilişimle ilişkimizi düşünmekten geçiyor. Stallman gözümde huzursuz biçimde “bilişim böyle, meyveli yoğurt gibi, paketlenmiş ürün kadar kolay tüketilir olmamalı, bu bir düşünme biçimi, bir araç…” diye homurdanırken canlanıyor örneğin… Peki bu sektöre girmeyelim, bunlar hazırlop tüketim araçları demek mümkün mü? En azından Linux dağıtımları açısından?
Bir başka analojiyle final yapmayı deneyeyim, et yemeyi ne kadar severse sevsin, kurban bayramında beslediği kuzunun, yediği ete dönüşmesi tanık olan her çocuk için büyüme sürecinde sancılı bir adımdır. Kentliler canlıları tükettiğimizi fark etmek için böylesi travmalara ihtiyaç duyarlar. Kent kültürü, ürünleri birbirinden farklılaştırıp araya mesafe koyarken, bizi onlara bir kat daha yabancılaştırır. Markette bir tabağın içinde paketlenmiş biçimdeki tavuk parçalarından lezzetli yemekler yapmak, o tavuğu yetiştirip, kafasını kopartıp tencereye atmakla aynı şey sayılmaz… Farklı uzmanlıklar ve farklı sonuçlardır bunlar.
Bilişim sektörünün gidişatı her geçen gün kullanıcıları ürünleri market raflarından almaya çağırıyor, özgür yazılım fikrini ortaya atan Stallman ise köyümüze geri dönüp kümes edinmemizi… Ben Linux dağıtımlarını ikisinin ortasında bir çözüm bulmuş gibi tanımlıyorum. Gönlüm köye dönmekten yana bile olsa, kentte yaşamamın nedenleri konusunda her gün kendimi sorgulamaktan beni kurtaracak kadar pragmatik, köy kadar doğal ve lezzetli…
27 August 2010 @ 01:16 PM
Artık Pardus 2010 Yaz stajında son günlere geldik. Proje ile ilgili son sorunlardan birisi olan KDM'ye giriş yapamama ile ilgili başka gelişmeler oldu. Aslında dün hallettim dediğim KDM hallolmamıştı. Başka sorunlar çıktı.
Daha önceden Oswald ile konuştuğum kadarıyla PluginsLogin'i generic yaptığımda istediğim gibi çalışması gerekiyordu. Fakat bizim depoya aldığımız KDM'nin 2 yaması:
same-pam-generic-classic.diff
ve
kdm-fix-generic-greeter.diff
PluginsLogin generic olsa bile classic'miş gibi davranmasına sebep oluyor. Yani kdm/backend/client.c dosyasındaki curuser değişkenine bir şey atamaması gerekirken bir şeyler atıyor. Bununla ilgili nasıl bir çözüm bulabileceğimizi Oswald'a sordum ve haftasonundan sonra halledebileceğimizden bahsetti.
Şimdilik kendi eklediğim yama ile sorunsuz çalışıyor. Biraz daha düzeltme yapmam gerekecek tabi. Tam olarak çalıştığına karar verdiğim halini yine buraya yazmayı düşünüyorum.
Bir de KDM'nin açılış ekranında ek bir menü mü yoksa buton mu koysak konusunda kararsız kalıyorum. Eğer buton koyar isek görünür olup olmamasını kdmrc dosyasına koyacağımız
guestlogin
değişkeni ile sağlayabiliriz. Yani eğer guestlogin true ise buton görünecek, değil ise görünmeyecek. Tabi hem bunun için hem de PluginsLogin için pardus-air temasının xml dosyasını buna göre düzenlemem gerekecek.
Ya da başka bir fikir olarak kdmrc dosyasının içine herhangi bir değişken koymadan, xml dosyasından 2 tane oluşturup biri guestlogin'li diğeri ise guestlogin'siz yapabilirim. Guestlogin'lide buton olur.
Bugün Pardus 2011'in Alpha'sı çıktı. Bunu test etmek için sanal makina'ya bunu kurdum. Öncelikle X'in açılabilmesi için sistem açılırken (ve kurulurken) kernel'e (grub sırasında)
xorg=driver:fbdev
parametresini giriyorum. Bu parametre sayesinde kurulumu tamamladıktan sonra yeniden başlatınca sistem açılmadı. Onur'un ve Gökçen'in çalışmaları sonucu sorunu çözüldü. Anladığım kadarıyla sorun, YALI'da sistem saatinin değiştirilmesinden kaynaklanıyor. YALI saati yanlış ayarladığı için onu düzeltmiştim.
Ayrıca bugün bir şey daha oldu. Serdar'ın uğraştığı ve configure işlemi tamamlandıktan sonra make sırasında tekrar configure dosyasını çağırması sonucu make işlemi patlayan bir paket var, libmpcdec.
En sonunda hatayı çözmüşler ama bana söylemeden hadi bu kodu derle dedi Onur. :). Hmmm diyerek başladım uğraşmaya, sorun aslında basit gibi görünüyordu ilk configure'de sorun olmadığına göre ikinci kez yapılan configure'ü bir şekilde kapatırsam sorun çözülecekti. Configure'ün çağırıldığı yerdeki yazan yazıyı grep'leyip kaynak kodda araştırdım. config.status'de çağırılıyor. Ve düzeltmek için ./configure sırasında oluşturulan "config.status" dosyası içinde ufak bir değişiklik yaptım. Sorunsuz derleniyordu ama neden configure'u tekrar çağırıyordu? Tam olarak bir çözüm bulamıyordum. Onur geldi ve benim bunun neden olabileceği konusunda düşünmeme yardımcı oldu. Sonuç olarak sorun configure.ac dosyasının configure'den yeni olmasıymış. Yani makefile bir yerde bu dosyanın tarihini kontrol ediyor ve tarihi yeni olduğu için bu dosyanın değiştirildiğine kanaat getirip tekrar configure'ü çalıştırıyor.
Bana yukarıda yazdığım deneyimi yaşattığı için buradan tekrar Onur'a teşekkür ediyorum. Ayrıca sabahki yapmış olduğu disk kurtarma operasyonu ile kendisinin bu konulardaki (Linux vb.) bilgisine olan +sonsuzdaki saygımı yine +sonsuz ekleyerek +sonsuza götürmüştür.
27 August 2010 @ 01:32 AM
August 26, 2010
Linux Vakfı’nın düzenlediği ve geçtiğimiz yıl Portland’da -Linus Torvalds’ın memleketi- başlayan LinuxCon yıllık konferansları bu sene Yeni İngiltere’nin kalbi Boston’daydı. Tabii ki bendeniz de orada…
OSDL ve FSG’nin birleşerek Linux Vakfı’nı kurmasına, ve hatta vakfın adına şüpheyle yaklaşmıştım zamanında. Ama gerek Jim Zemlin önderliğinde yaptıklarına ve gerekse sadece LinuxCon toplantılarına bakınca ne kadar yanıldığımı görebiliyorum. Linux Vakfı gerçekten Linux’un, ve neredeyse daha geniş çerçevede özgür yazılımın, marka ve satıcı bağımsız sözcüsü ve önderi haline geliyor yavaş yavaş.
Birinci Gün
Boston’a dönelim… Konferans’ın açılışını Jim Zemlin yaptı ve bombayı patlattı: Özgür yazılım lisans ihlali yapan firmaların çoğu bunu kasıtlı olarak yapmıyorlardı ve alsında hemen hepsi lisans uygun davranmayı tercih edecek durumdalardı. İhlalin temel nedeni bilgi eksikliği idi. Ve Linux Vakfı özgür yazılım ürünlerini kullanarak türev ürünler üreten firmaların lisans uyumlarına yardımcı olabilmek için yeni bir program başlatıyordu: The Linux Foundation Open Compliance Program, yani Linux Vakfı Açık Uyumluluk Programı. Eğitim, Araçlar, SPDX, Değerlendirme kontrol listesi, Uyumluluk rehberi ve FOSS Bazaar bileşenlerinden oluşan program ilerleyen sat ve günlerde tüm katılımcılardan son derece olumlu tepkiler aldı. Bir Linux Vakfı kazanımı daha…
Açılış konuşmasını Oracle’dan Wim Coekaerts yaptı ve Oracle/Sun ekseninde (MySQL eksenini biraz es geçip) özgür yazılım perspektifini anlattı. Yeni ve ilginç bir veri Oracle’ın kullanıcı temelinin %20′nin üzerinde Linux kullanmakta olduğu idi, karşılaştırma için Solaris %27′de. İkinci konuşmayı Qualcomm’dan Rob Chandhok verdi ve ismi özgür yazılımla pek yanyana gelmeyen Qualcomm’uın mobil özgür yazılım geliştirme amacıyla QuIC: Qualomm Innovation Center ismiyle bir şirket kurduğunu (ki Chandhook bu şirketin başında) ve QuIC’in başta kernel MSM bakıcılığı olmak üzere şimdiden çeşitli işlere girmiş olduğunu gururla ilan etti kendisi.
Paralel oturumlarda geleneksel iş – hukuk çemberini kırmak istedim bu kez ve daha teknik konuşmaları izlemeye çalıştım. Varşova Üniversitesi ve SuSE’den Rafael Wysocki çalışma zamanı güç kontrolü gibi son derece ilginç bir başlık altında son derece sıkıcı ve dağınık bir sunuş yaptı. Ardından Smack grubundan Casey Schaufler’in dosya içeriği temelli erişim kontrolü konuşmasını izledim, pek güzel ve heyecanlı bir konuşma idi. Olay soru-cevapta çıktı, meğersem bu amca SELinux’çuların ile kanlısıymış, epeyce bir atışma oldu. Ama asıl kızılca kıyamet paralel Android oturumunda yaşanmış, Android’in kernel ağacından uzak kalması zaten bir tartışma konusu, konuşmalar hararetlenince sesler yükselmiş, sonunda konuşmacı bir izleyiciyi salondan kovmuş, vb.
Öğleden sonra teknik yazar Jeff Osier-Mixon’ın dağıtım kapışması vardı. Geleneksel hale gelen bu kapışma önde gelen üç masaüstü dağıtımının (fedora, openSuSE ve Ubuntu) 7 alanda (kurulum, açılış zamanı, uygulama yükleme, sistem yapılandırma, çevrimiçi yardım, yeni donanım ve ağ servisleri kurma) hız, kullanışlılık ve estetik açıdan değerlendirilmesine dayanıyor. Sonuçlar oldukça yakın çıktı: Ubuntu 156, openSuSE 155 ve fedora 144. Pardus’umuzu bu kapışmaya soksak sanırım 120-130 arası bir puan alır, hala gidecek hayli yolumuz var yani. Konuşmadan önemli bir tartışma dağıtımların kullanıcı sayısı üzerine idi, fedora (milyonlarca kullanıcı) ile openSuSE (3 milyon kullanıcı) bu sayılara nasıl ulaştıklarına dair ayrıntılı bir metodoloji açıklarken Ubuntu (12 milyon kullanıcı) yalnızca şakadan bir sayı çıkarıyor denildi. Pardus’un kullanıcı sayısı hakkında ettiğimiz lafların güvenilirliğini en başta ben sorguluyorum, biline…
Günün en eğlenceli oturumu basın gözünden Linux üzerine paneldi. 2000′lerin en büyük Linux hikayesi için SCO, IBM’in desteği, RHEL, mobil, Ubuntu yanıtları geldi. Özellikle openSuSE’nin eski camia yöneticisi Joe Zonker Borckmeier fedora ve openSuSE’nin Ubuntu’nun çıkışı sonrasında kendilerine çeki düzen verdiklerini, yoksa RedHat ve Novell’in camia dağıtımlarını pek de takmaz bir halde olduklarını iddia etti. Bugünün büyük hikayesi olarak da Android, Chrome OS, Linux Vakfı, mobil gösterildi. Ardından analistlerin rakamları konuşuldu ve bolca atıldı analiz firmaları ardından. Neden büyük Linux haberleri yapılmadığı tartışıldı ve temel neden olarak Linux’un artık her yerde ve harcıalem olması gösterildi, yani bu iyiye bir işaretmiş. Linux haberlerini daha çok teknoloji meraklılarının okuduğu, Microsoft’un bolca reklam verdiği, firmaların bloglar vb. aracılığı ile “yayıncılık”a soyunmasının alışıldık medya için aslında çok da bir tehdit oluşturmadığı vb. konuşuldu. Pek güzeldi…
İlk günün kapanış oturumu yine geleneksel kernel paneli idi. Geçtiğimiz yılın kernel olayını James Bottomley “barriers’in ölümü” olarak ilan etti, depolama altsistemindeki gelişmeler tüm panelistler tarafından taktirle anıldı. “Kimse ana kerneli test ediyor mu? Yoksa herkes bir çatalını mı kullanıyor” gibi kışkırtıcı bir soru ile devam edili. Dave Jones yükselen kaliteye koşut olarak Linux kerneline girişin gittikçe daha zor olduğunu vurguladı, hem iyi hem de kötü bir şey olarak. Ted T’so RedHat ve SuSE’nin kernel’i çok daha fazla çatallamasına karşın paparayı Google ve Android’in yemesinden şikayet etti.
İlk günün sosyal etkinliği -yine geleneksel- bowling partisi idi. Yerel biralar eşliğinde hoş ve eğlenceli bir akşam geçirdik.
İkinci Gün
Ana konuşmada Novell’den Markus Rex inovasyon politika ve tekniklerini anlattı. Forrester’dan Jeffrey Hammond rakamlarla Linux’un artık gelecekteki bir olay olmaktan çıkıp bir olgu haline geldiğini gösterdi. Önemli bir bilgi geliştiricilerin (Eclipse geliştiricileri üzerine yapılan bir araştırma sonuçlarını verdi) hem geliştirme ve hem de üretim ortamında dağıtım olarak Ubuntu’yu tercih etmesiydi. Üretimde RHEL ciddi bir paya sahip, ama bir numara değil!
Paralel oturumlarda önce IBM’den Jean Staten-Healy sunumuna gittim. Masaüstünde Linux’un kullanılabileceğini ZSL inc’de Ubuntu, Cybernet-SlashSupport’ta RHEL örnekleri ile anlattı. Artık CIO’ların Linux’u stratejilerinin bir parçası yapmak istediklerinden bahsetti. Dünya ile Türkiye’yi karşılaştırıp moralimi bozmaya devam ettim ben de 
Scott James Remnant’ın Ubuntu’yu daha hızlı başlatma üzerine bir konuşmasına takıldım. Moblin kazanımları üzerine bir-iki ufak numara dışında fazla bir şey yoktu, etkilenmedim.
İkinci günün bombası Monty Widenius’un MariaDB (ya da My’ya karşı Maria) konuşması idi. Votkalı çikolata ile başlayıp kara votka ile bitmesini geçeyim oturumun, içerik ile ilgili yok. Monty, bildiğiniz Linus’un veritabanı hali… Zaten o da Finlandiya’dan ve MySQL’den kazandığı milyonlarca dolara karşın tam bir geek görünümünde. MySQL’in 2002′den başlayarak nasıl camiaya sırtını döndüğünü ve nasıl “son”unu hazırladığını anlattı. Yeni özellik ve yamaların camiaya verilmeden yalnızca kurumsal ürüne konulmasının nasıl müşterilerin sorunlarını ve test zamanlarını katladığını söyledi. MySQL’in bir ürün olarak başarılı olduğunu, ama bir proje olarak battığını iddia etti. MariaDB’nin bir ürün değil bir proje olduğunu söyledi. Son derece keyfili bir oturumdu…
IDC’den Al Gillen ilk önce “dün gazeteciler bizim hakkımızda atıp tutmuşlar, onlardan kimse var mı bu salonda” dedi, olanlar indiler yerlerinde, biz de ispiyonlamadık. Yine rakamlarla Linux’un ne kadar iyi durumda olduğunu anlattı… Solaris’in zayıflamasını ve bulut bilişimi Linux için önemli fırsatlar olarak saydı. SuSE Studio’dan beğeni ile söz etti. Gerek Forrester ve gerek IDC konuşmacılarının vurguladığı birşey vardı: “Tebrikler, kazanan takımdasınız!”, artık Linux “geliyor mu, gelecek mi” diye sorulan, az bilinen ve merak edilen birşey değil, bilişim dünyasının, -hem de son derece önemli- bir parçası. Özellikle bulutun yaygınlaşması ile masaüstü işletim sistemlerinin alakasızlaşması süreci tamamlanınca Linux her alanda mücadelesini kazanmış olacak, dünya hakimiyeti!
Geleneksel hukuk oturumlarıma döndüm sonunda, Eben Moglen’den harika bir konuşma izledik. ABD patent sisteminin çöküşü konusu etrafında mükemmel bir yolculuğa çıkardı bizi Eben, her zamanki gibi muhteşemdi… Dinlemekle konuşmayı sindirmeye çalışmak arasında gidip geldik.
Gün MeeGo oturumu ile tamamlandı, Nokia ve intel temsilcilerinin katıldığı bir mini panel şeklinde. Önemli haber 2011 başında Nokia’nın ilk MeeGo telefonunu çıkaracağı idi. Özellikle MeeGo’nun ne kadar anakaynağa yakın durduğu vurgulanarak “Android gibi herşeyi çatallamıyoruz, ağır entegre bir sistem de yapmıyoruz, burada herkese ekmek var” mesajı verildi. Güzeldi… Nokia’nın Symbian’ı ve ovi dükkanı ilginç sorular arasındaydı.
İkinci günün sosyal aktivitesi Boston körfezinde tekne gezisi oldu. Monty ile aynı masaya düşmeyi becerebildiğimden sohbeti genişlettik. Ekim ayında İstanbul’da yapacakları geliştirici toplantısında birlikte neler yapabilirizi konuştuk, kara votka ile beyaz rakı birlikteliğine kadar uzattık hikayeyi. Serin güvertede Boston’un ışıklı silüetini izleyerek günü tamamladı penguenler…
Üçüncü Gün
Ana konuşmacı GNOME Vakfı’nda Stormy Peters idi, buluttaki verilerin güvenliği ve gizliliğinden bahsetti, internet servisi olarak da özgür alternatifleri seçmemiz gerektiğini vurguladı. GNOME ve Stormy’nin tüm konuşmaları gibi özgürlüğe vurgu yapan pek güzel bir çağrıydı…
Bir kullanıcı olarak Virgin havayollarından Ravi Simhambhatla geldi sonra, Linux’u nasıl kullandıklarını anlattı. Ravi yanılmıyorsam OSBC’de de konuşmuştu, aynı kurumsal kullanıcıyı 6 ay ara ile iki kez konuşturmak ters geldi bana. Türkiye’de olsa “zaten kaç kurumsal kullanıcımız var ki” diyeceğim, ama küresel ölçekte olmamış…
Yine hukuk ve RedHat’ten Richard Fontana katkıcı politikaları anlatıyor. fedora’nın yeni katkıcı sözleşmesinin hikayesini genel bir perspektifle öyle güzel verdi ki, tam da camia tartışmalarımız arasında ilaç gibi geldi. Soru-cevapta bir yandan Eben Moglen, diğer yandan Canonical’ın baş hukuk danışmanı konuya girince oturum iyice şenlendi…
Canonical’an Matt Asay’in yönettiği “What Next for Linux?” paneline girdim öğleden sonra. Asay son derece kötü yönetti paneli, izleyicilerin soruları da olmasa tam bir fiyasko olacaktı. Sonuçta Linux’un masaüstünde başarısız, mobilde başarılı olduğunu öğrendik 
Bdale Garbee bu kez gerçekten roket anlatıyordu. Kapalı sistemlerin nasıl sakıncalı olduğunu ve kendi özgür platformlarını nasıl oluşturduklarını bir dizi embedded ve Make geek’i ile bana anlattı, her zamanki gibi pek güzeldi…
Yavaş yavaş kapanışa geldik. Geleneksel geek’ler nerd’lere karşı yarışması ile sona erdi konferans. Nerd’ler ağır bir yenilgiye uğrattılar geek’leri, Zemlin’in bütün çabasına karşın…
Boston, dedim ya, Yeni İngiltere’nin kalbi. Hafifi İngiltere’yi çağrıştıran 19. yy mimarisi, limanı ve Charles nehri, deniz ürünleri, MIT ve Harvard başta üniversiteleri ile hoş bir şehir. ABD’nin her büyük şehri gibi yaşaması kolay, özellikle paran varsa Gelecek yıl Kanada’ya geçiyor LinuxCon ve Vancouver’a gidiyor…
26 August 2010 @ 05:13 AM
August 25, 2010
Artık Pardus 2010 Yaz Stajının son günlerine yaklaştık. Elimde bir adet sorun vardı. Ve yeterince büyüktü. KDM üzerinden giriş yapamıyordum.
Daha önce düşündüğüm gibi
if (!curuser)
yazan yere şimdilik
if (!curuser || strcmp(curuser, "guest") )
olarak değiştirdim ve çalışacak mı diye denedim. Çalıştı. Fakat bu biraz kötü bir çözüm yoluydu. Bununla ilgili upstream ile konuştum.(Oswald Buddenhagen) Bunun yanlış bir yöntem olduğunu ve kdmrc dosyasında
PluginsLogin=generic
yaparsam zaten curuser ataması yapılmadığı için o bloğa girileceğinden bahsetti. Denediğimde çalışmadı çünkü bizim (Pardus) varsayılan temamız "pardus-air" bu kimlik doğrulama metodunu kabul etmiyordu. Değiştirip "oxygen-air" yaptığımda sorunsuz çalıştı. Ama bu sefer de AutoLogin aktif iken çalışmıyordu.
Bununla ilgili hata mesajlarını Oswald'a yolladım ve bunun bir bug olduğuna karar verdik.
Bu hata mesajlarını incelerken dikkatimi çeken şey ise AutoLogin aktif iken PAM doğrulama metodu "kde4-np" yani nopassword girişi. Bu "kde4-np" değerini tutan değişken ise psrv değişkeni. Bunun pam dosyasına baktığımda ise:
#%PAM-1.0
auth required pam_nologin.so
auth required pam_permit.so
satırlarını görüyorum auth bölümünde. Sadece bunlar olduğu için ve bu modüller de kullanıcı adını pek önemsemeden girişe izin verdiği için pam_get_item() fonksiyonunda çakılıyor KDM.
AutoLogin kapalı iken PAM doğrulama metodu "kde4" olarak seçili. Bunun üzerine bir başka yama daha yaptım.
Bu yama
if (!curuser) {
satırını
if (!curuser && psrv != "kde4-np" ) {
olarak değiştiriyor. Bu şekilde denediğimde sorunsuz olarak çalıştı. Bunu upstream'a da yolladım. Aslında doğru bir yöntem değil ama en azından çözüm yolundan bahsetmek açısından yaptım bunu. Bunun yerine de eğer AutoLogin aktif ise curuser in boş olmaması gibi değişiklikler yapılırsa sorunun halledilebileceğinden de bahsettim.
Son aldığımız başka bir karar da KDM ekranında alttaki menüler gibi ayrı bir menü olsun ve simgesi anahtar olsun. (girişi simgelemek adına)
Bu menünün içine bir yandaki kapat, x i yeniden başlat'ın olduğu yerin ordaki konsol girişi ve uzaktan girişi alıp bir de misafir girişini ekleyecektim.
Bu misafir girişi temel olarak kullanıcı adını /etc/security/guestlogin.conf dan alıcak ve kullanıcı adına yazacak sonra da giriş yapacak.
Şimdilik bunun üzerine araştırmalar yapıyorum. Oswald'ın da yardımları sayesinde sanırım menü ekleme işi gayet kolay olacak.
25 August 2010 @ 11:50 PM
Bugün ptsp_installer projesine ufak bir ekleme yaptım. Bu ekleme her adım çalışmadan önce çalıştırılsın mı diye sormak. Henüz bunun kesinlikle kalıp kalmaması konusunda emin değilim ama bence böyle olması daha iyi çünkü bazı dosyaları güncellemek istemeyebilir. (daha önceden güncellenmişi olabilir)
Bunu yaptıktan sonra Pardus Bugzilla'sında benim eklemiş olduğum yamadan sonra oluşan hatayı inceledim. Kendim hatayı tekrarlayamıyordum. Hatayı alan arkadaşın kdmrc dosyasını incelediğimde "AutoLogin" özelliğinin aktif hale getirildiğini fark ettim. Bunun için kendi kdmrc dosyamda da bunu açtım. Fakat yine hata ile karşılaşamadım. Biraz daha araştırdıktan sonra AutoLoginDelay=0 olduğunu gördüm. Bunu uyguladığımda hakikatten kdm'nin çöktüğünü fark ettim. Kdm yi tekrar:
kdm -debug 1
ile açtıktan sonra "/var/log/syslog" dosyasını inceledim. Benim kaldırdığım if bloğu her zaman çalıştığı için orada çakılıyor.
Yaptığım yamayı kaldırdığımda ise bu sorun düzeliyor. Bunun için çözüm arayışlarındayım.
AutoLoginDelay aslında 0 haricinde bir değer olsa sorunsuz çalışıyor ve kdmrc dosyasında '#' lı halinde AutoLoginDelay=10 olarak verilmiş ve varsayılan da 0 gözüküyor. Bunu kullanıcının elle mi oluşturduğunu araştırırken YALI'da eğer otomatik giriş seçilirse bunun 0 olarak ayarlandığını fark ettim.
Öncelikle tahminime göre AutoLoginDelay=0 ise KDM, PAM'i ya çağırmıyor ya da başka bir şekilde çağırıyor ki pam_get_item() fonkisoyunda sorun çıkıyor.
Bunu önlemek için de aklıma bir kaç yöntem geldi.
Başlangıç olarak kdmrc ye
guestlogin=true
satırını ekleyip buna göre o if bloğunu çalıştırmak olabilirdi
if(!curuser || guestLogin)
şeklide mesela. Ama burada da hem guestlogin aktif olup hem de AutoLoginDelay=0 olduğunda sorun olurdu ki bu da istenebilecek bir şey bir şey.
İlk olarak sorunu anlamamıştım ama o if bloğu ile ilgili bir şey olduğunu düşünüp oraya girip girmemesini kontrol etmek adına kullanıcı adını pam_get_item() ile çekiyor ve daha önce çekilmiş olan kullanıcı ismi olan curuser ile karşılaştırıyordum. Fakat bu kodda da kullanıcı adını çekerken sorun olduğunu fark ettim ve sorunun yukarıda da dediğim gibi PAM'ın çağrımı ile ilgili olduğunu düşündüm.
Şimdilik aklımda 2 çözüm var, bunları uygulayacağım.
1. si eğer kdmrc dosyasında
guestlogin=true
ise ve PAM'dan gelen kullanıcı adı eğer
/etc/security/guestlogin.conf (aslında burayı da kdmrc ye koyabiliriz, sonuçta günün birinde bunu değiştirmek istediğimizde kodda tekrar değişiklik yapmamız gerekecek) dosyasındaki
guestname=
satırındaki eşitliğin sağ tarafına eşit ise if bloğu çalışsın diyebilirim. Ya da
yine kdmrc dosyasında
guestlogin=true
ise bir şekilde PAM'in çalışıp çalışmadığını kontrol edip (pamh değişkeninden olabilir belki) ona göre if bloğu çalıştırılabilir.
Bunlar ile ilgili araştırma ve uygulamayı yarın yapmayı düşünüyorum.
25 August 2010 @ 12:19 AM
August 24, 2010
Eklemem gereken fonksiyonların tamamını ekledim. Şimdilik ptsp_installer projesi de temel hatlarıyla tamamlandı diyebilirim sanırım.
Tabi ki bunun üzerine iyileştirmeler yapmam gerekecek. Şimdilik iyice test ettikten sonra bunlara bakmayı düşünüyorum. Ağ profili oluşturma işi biraz uğraştırdı ama MÜDÜR'ün network.py betiğine bakarak hallettim.
Ayrıca Ağ Profili oluştururken, durumu değiştirme(up/down), ağ kartını listeleme, profilleri listeleme gibi işlemleri fonksiyon fonksiyon yapmanın da bayağı faydasını gördüm. Mesela hem yeni profil oluştururken hem de var olanı aktif ederken durum değiştirme fonksiyonunu kullanıyorum. İleride başka şeyler lazım olduğunda da çok fazla uğraşmadan ekleyebileceğim. Bunların yanı sıra kodun okunabilirliği de artıyor.
Daha önceden de yazmış olduğum yapılandırma dosyasındaki boşluk sebebiyle oluşturmuş olduğum set_key_with_spaces ile set_key fonksiyonlarını birleştirdim.
En sonuna da white_spaces == true ise ona göre işlem yap dedim.
Bir önceki proje olan guestlogin'de sevgili Gökçen ve Koray ile ufak bir şeyler ekleme kararı aldık.
KDM ekranındaki kapat ikonunu açıldığı listeye Misafir Girişi diye bir şey ekleyip, orada tıklandığında giriş yapılmasını sağlamak.
Bunun için bir de kdmrc dosyasına:
guestlogin = true
gibi bir satır eklenerek o listede Misafir Girişinin olup olmayacağı ve KDM için Misafir Girişinin sağlanıp sağlanamayacağını kontrol edeceğim.
Bu arada da ptsp_installer projesinin iyileştirme çalışmaları devam edecek.
24 August 2010 @ 01:19 AM
August 23, 2010
Yaklaşık 12-13 sene evvel, annemin yazdığı bir kitabın bilgisayarda dizilmesine yardımcı olurken, klasik cildin bölümlerini ve isimlerini anlatan bir grafik çizmiştim. Çizim yeteneğim sıfır olduğu ve düz çizgi olmayan kısımları Amiga'nın baba programı Deluxe Paint ile piksel piksel yerleştirerek çizdiğim için bazı yamuklukları olan bir grafik oldu.
Resme dikkatli bakarsanız, bazı okların ortalanmamış olduğunu ve şemsenin sağ ve sol uçlarının hizalı olmadığını görebilirsiniz. Bu kitap Haziran 1998 de, İş Bankası Kültür Yayınları'ndan, Türk Cilt Sanatı adıyla yayımlandı.
Yıllar sonra Dr. Hasan Özönder'in Ansiklopedik Hat ve Tezhip Sanatları Deyimleri, Terimleri Sözlüğü adlı 2003 yılında yayımlanmış kitabını gördüm. Alanında ilk ve tek olduğu, tüm telifinin yazara ait olduğu iddiasındaki bu kitap ilginç şekilde bolca copy-paste içeriyordu :) Hatta tanıdık bir de grafik vardı :)
Bunu çok önemsemedik. Daha sonra Dr. Abdulkadir Yılmaz'ın Türk Kitap Sanatları Tabir ve Istılahatları adlı 2004 yılında yayımlanan kitabında da gene o grafik çıkmasın mı :)
Açıkçası bu yamuk çizimi yaratıp yaymış olmaktan rahatsızım. Modern teknolojinin imkanlarıyla (bkz: Inkscape), yamukluklarını düzeltip SVG formatında yeniden çizdim. Gelecek yazarlar buradan alıp kullanırsa bir ilerleme kaydedilmiş olur en azından :)
23 August 2010 @ 07:21 AM
Ptsp_installer projesinin çalışmaları iyiye gidiyor diyebilirim.
Hafta sonunda bir kaç fonksiyon daha ekledim. Şimdilik en önemli ihtiyacım olan ağ profili oluşturma ve gerekli bilgileri alma fonksiyonunu sonraya bıraktım. Yeni eklediğim fonksiyonlar:
hosts dosyası güncelleme
exports dosyası güncelleme
pts-client.conf dosyası güncelleme
fonksiyonları. Bu dosyaları güncelleyebilmem için sunucu adresi (ip address), ağ maskesi adresi (netmask), ağ geçidi adresi (gateway) gibi adreslere ihtiyacım var. Bunları ilerde ÇOMAR ile alacağım ama şimdilik elle verdim.
Bir de hosts dosyasını düzenlerken kullandığım bir yöntem var. IP adresini aldıktan sonra onun en sonunu alıyorum ve ona istemci sayısına gelene kadar o anki istemciyi ekliyorum.
10.0.0.1(+1)
10.0.0.1(+2)
gibi. IP den maskelerken bunu int() in içinde yapıyorum. Yoksa onu da string olarak algılıyor ve ekleme yapamıyorum.
Karşılaştığım bir sorun ise pts-client.conf dosyasındaydı. Kdmrc dosyasını düzenlemek için kullandığım fonksiyon bunda pek işe yaramıyor çünkü bunda eşittir('=')'den önce ve sonra birer boşluk var. Bunu çözmek için şimdilik set_key fonksiyonunun yanına bir de set_key_with_spaces diye bir fonksiyon daha yarattım. Daha iyi bir çözümü olabilir ona da bakacağım. Bunlardan biri mesela set_key fonksiyonuna bir tane daha değişken alıp oradan dosya ismi pts-client.conf ise ona göre boşluklu atama yap ya da boşluksuz atama yap derim.
Şimdilik durum böyle. Eklemem gereken sanırım 3 tane fonksiyon kaldı. Çalışmaya devam.
23 August 2010 @ 02:12 AM
August 21, 2010
PTSP installer projesinde, paketlerin kurulu olup olmadığını kontrol ettikten sonra sıradaki iş olarak "kdmrc" dosyasını güncellemeyi yaptım.
Bunu yaparken ilk başta aklıma ConfigParser ile o dosyayı okuyup, gerekli değişikliği de set() fonksiyonu ile sağlamaktı. Fakat bu komut tam olarak istediğim işi yapmıyor. Ben, verdiğim parametrelere uyan değişkeni dosyanın içinde bulup değiştireceğini düşünüyordum fakat yanılmışım.
Bununla ilgili araştırmaya devam ettim. Sonuç olarak, Gökçen'in YALI için yazmış olduğu kdmrc düzenleme fonksiyonunu kullandım. Tam olarak işimi görüyor bu fonksiyon. Bu fonksiyon, YALI'nın kaynak kodundaki users.py betiğinin içindeki setKey fonksiyonu.
Bunu da hallettikten sonra sıradaki iş olarak servisleri başlatmayı yazmaya başladım. Bunun için ÇOMAR API'si kullanacağımı biliyordum.
ÇOMAR API'si ayrıca bana ağ profilinde de lazım olacaktı. Temel olarak bunu kullanabilmek için:
link = comar.Link()
satırını ekledikten sonra,
link.System.Service["servisadi"]
şeklinde erişebiliyordum. info() ile gerekli bilgilere erişiyordum, bununla çalışıp çalışmadığını kontrol edip eğer çalışıyorsa stop() ile durdurup sonra da start() ile başlatıyordum.
Yani:
link.System.Service["dhcp"].info()[2].find("on") veya .find("started") ile çalışıp çalışmadığını kontrol ediyor. Eğer çalışıyorsa:
link.System.Service["dhcp"].stop() ve sonra da
link.System.Service["dhcp"].start() satırlarını ekleyerek, servis başlatma fonksiyonunu tamamlıyorum. Tabi ki de bu servis işlemlerini bir try-except bloğu içerisinde yapıyorum ki herhangi bir servis başlatılamadığı zaman onunla ilgili uyarı verdirip betiği sonlandırabileyim.
Bunu da tamamladıktan sonra sırada ağ profili oluşturma var. Bu sefer de yine ÇOMAR API'sini kullanacağım.
Henüz bunu bitirmedim ama uygularken MÜDÜR'ün network.py adlı betiğinden ve iptables paketinin firewall.py betiğinden de yararlanıyorum.
Şimdilik bütün ağ aygıtlarını listeleyip (kablosuz ağ aygıtları şimdilik desteklenmediği için onları listelemiyorum) o aygıtı seçtirebiliyorum. Sıradaki iş ise o aygıt üzerinde var olan profilleri listelemek olacak.
Bir de servisleri ve gerekli paketleri en yukarıya bir listede tutmamın bana büyük faydası oldu. Öncelikle "for x in y" şeklinde hepsini sırayla gezebiliyorum, bu kolaylığı sağladı hem de ilerde bir gün bir paket ekleneceği zaman en yukarıya sadece eklemek yeterli olacak. Tek tek nerede bakıyor buna diye aramaya gerek olmayacak.
21 August 2010 @ 02:35 AM
August 20, 2010
Yapmaya karar vermiş olduğum /etc/pam.d/ içerisindeki dosyaları düzenleme projesinin epostalaşmış olduğum Debian geliştiricisi tarafından Perl ile yazıldığını öğrendikten sonra bu projeden vazgeçtim.
Var olan projeye "http://bazaar.launchpad.net/~ubuntu-core-dev/pam/ubuntu/files/head%3A/debian/local/" adresinden ulaşabilirsiniz.
Bu adresteki pam-auth-update adlı betik bu işi yapıyor. Ayrıca pam-auth-update.8 isminde bir man dosyası var.
Bunun üzerine başka proje arayışlarına geçtim ve Bahadır ile PTSP kurulum betiği hazırlamaya karar verdim.
Öncelikle PTSP nedir ile başlayayım.
PTSP, ince istemciler için bir çözümdür. Yani bir tane sunucu üzerinde PTSP sunucu çalışacak ve diğer istemciler ağ kablosu üzerinden ona bağlanacak. Bu bağlantı ile X üzerinden de işlemler yapmak mümkün, yani bildiğiniz Pardus kullanıyor olacaksınız ama bir sunucu üzerinde. Aynı zamanda da benim hazırlamış olduğum Misafir Kullanıcı projesi de PTSP ile çalışması çok faydalı olacak.
Bununla ilgili bir belge pardus wikisinde var.
Adresi: http://tr.pardus-wiki.org/NASIL:PTSP
İlk iş olarak ben bu adres üzerindeki işlemleri yapıp PTSP sunucu yaratıp, hem nasıl çalıştığını anladım hem de PTSP ile beraber Misafir Kullanıcı'yı deneme fırsatı buldum.
Sonuç güzel, gördüğüm kadarıyla sorunsuz çalışıyor. Hem sunucudan hem de istemciden "guest" ismi ile bağlandım. İkisine de ayrı isimler ve ev dizinleri belirleyip sorunsuzca çalıştırdım.
Şimdi ise sırada bu yaptığım işlemleri yapacak bir betik hazırlamak.
Hazırlıklara başladım. http://svn.pardus.org.tr/uludag/trunk/playground/intern/ptsp-installer içerisindeki TODO dosyasındaki işlemleri sırasıyla yapacağım. Bu TODO dosyasını yukarıda vermiş olduğum Pardus wikisindeki belgeden yararlanarak oluşturdum.
Şimdilik gerekli olan paketler kurulu mu diye kontrol eden bir metot yazdım. Bu metotta PiSi'nin API'sini kullandım.
Yapılandırma dosyalarını düzenlerken dikkatli olmam gerekiyor. Diğer ihtimalleri göz önünde bulundurarak bunu yaptıktan sonra geriye kalan işlemler pek de zor gözükmüyor.
20 August 2010 @ 12:30 AM
August 18, 2010
NOT: Bu güvenlik açığını başka şekilde hallettiğim için buradaki control kısmına sadece sufficient yazmam yeterli oldu. Ama yine de aşağıdaki yazıyı bırakıyorum.
Biraz önce yazdığım yazıdaki kodu kontrol ederken akıl almaz bir güvenlik açığı ile karşı karşıya geldiğimi öğrendim. Açık şu: Sistemdeki herhangi bir kullanıcı parola yazmadan giriş yapabiliyor. Bunun sebebi yazdığım metot her türlü SUCCESS döndürmesi. Bunun yerine hata döndürse bu sefer başka sorunlar ortaya çıkacak.
Bu şekilde aklıma /etc/pam.d/ nin içerisinde bir şeyleri değiştirmek geldi. man pam.d yaparak kolları sıvadım. Ve çözüm:
auth [user_unknown=ok success=done new_authtok_reqd=done default=ignore] pam_python.so guestlogin.py
İkinci yazdığımız sufficient yerine bunları yazıyorum. Şu an daha iyi durumda.
Şimdilik aklıma gelen düzeltme yapılması gereken yerlerden birisi de bu durumda her bilinmeyen/kayıtlı olmayan kullanıcı için SUCCESS döndürmesi. Bunun kontrolünü python betiğinin içerisinde uygulamam gerekiyor.
18 August 2010 @ 11:31 PM
Hazırlamakta olduğum guestlogin projesinde şimdilik giriş yapılabiliyor ve /home/ dizininin altında guestX şeklinde bir dizini ev dizini olarak gösteriyordu.
Geçici ve parolasız girilen bir hesap için fazlasıyla tehlikeliydi. Bunun için tmpfs ve mktemp komutlarını araştırdım. Tabi bir de kullanıcıyı ev dizini olmadan oluşturmaya baktım.
Öncelikle ev dizini olmadan kullanıcı oluşturmak gayet kolay. Komutumuz:
adduser -M kullanici_adi
şeklinde. -M ev dizini olmadan yarat anlamına geliyor.
mktemp komutu ile /tmp/ dizini içerisinde rasgele bir klasör oluşturuyoruz. Bunu da
mktemp -td guestX.XXXXXX ile yapıyoruz. Buradaki guestX bildiğimiz gibi misafir kullanıcıya vermiş olduğum geçici kullanıcı adı. Noktadan sonraki 6 tane X ise rasgele oluşturacak 6 rakam-harf karışımına denk geliyor. Yani oluşturulan dizin /tmp/guest6.6jHx4f gibi bir şey oluyor.
Buraya kolay bir şekilde gelmiştim fakat önümde biraz araştırmam gereken bir konu vardı. mktemp komutu o XXXXXX leri doldurup stdout a gönderiyordu bunu. Bunu da benim bir şekilde bir değişkene atayıp o dizini tmpfs ile bağlayıp bir de o kullanıcıya atayıp ev dizini yapmam gerekiyordu. Geliştiricilerden Serdar'ın yardımıyla birlikte python ile bunu yapmak için subprocess'leri araştırdım.
Dosyanın başına import subprocess yaptıktan sonra :
procOutput = subprocess.Popen(["mktemp -td %s.XXXXXX" % username], shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
homeDir = procOutput.communicate()[0][:-1]
satırları ile çözüme ulaştım. Burda yaptığım iş tam olarak alt bir süreç başlatmak. yanına yazdığım diğer argümanlar sayesinde stdout ve stderr'i okuyabilecektim.
bu Popen fonksiyonunun geri dönüş değerini bir değişkene atadıktan sonra communicate() fonksiyonu ile bakabiliyordum. Aslında bu bile sonucu bir değişkene atamak için yeterliydi fakat sonuç şu şekildeydi:
('/tmp/guest5.d6E3gh\n', None)
bu haliyle benim işimi görmüyordu. Bunun de küçük bir düzenleme yaptım. İlk baştaki lazım olduğu için communicate() den sonra [0] ı kullandım. O değişkenin içinde de en son karakter \n olduğu için [:-1] ile en son karakteri attım. Sonuç olarak elimde sadece
/tmp/guest5.d6E3gh
kaldı ve bu benim için yeterli bir bilgiydi. Bunu homeDir değişkenine atadıktan sonra bunu tmpfs ile bağladım. Bunu da:
os.system("mount -t tmpfs -o mode=700 none %s" % homeDir)
ile sağladım. Sırada ise kullanıcıyı oluşturma, bu dizini kullanıcıya verme ve onun ev dizini haline getirmek vardı. Kullanıcının sistem tarafından verilmiş adını (guestX olan) username değişkenine daha önceden attığım için aşağıdaki komutlar bunlar için yeterli oldu.
os.system("useradd -M %s 2>> /var/log/guestacc.log" % username)
os.system("chown %s:%s %s" % (username, username, homeDir))
os.system("usermod -d %s %s" % (homeDir, username))
Burda dikkatinizi çeken bir şey de 2>> olmalı. Normalde >> komutu ile stdout'u başka bir dosyaya yönlendirebiliyoruz ama stderr yine ekrana düşüyor. stderr'in dosyaya yazılması için 2>> ekliyoruz.
Başlangıç ayarlarını bu şekilde halletmiştim bir de çıkışta da bu dizini umount edip, kullanıcıyı ve ev dizinini sistemden silmem gerekiyordu. İlk olarak /etc/pam.d/system-auth dosyası üzerinde kullanıcı çıkış yaparkan bir metotun çalışması için bir ekleme yapmam gerekiyordu. Bu da:
session sufficient pam_python.so guestlogin.py
satırı idi. Bu satırı:
session required pam_unix.so
satırının hemen üstüne ekledim. Bu satırı eklediğimde ek olarak:
pam_sm_open_session
ve
pam_sm_close_session
metotları çalışıyordu. Benim işime yarayan ise close_session metotuydu.
Bu metot içinden kullanıcı adını pamh.get_user(None) ile aldım fakat burada os.environ['HOME'] komutu işe yaramıyordu. Bunun için de :
homeDir = os.path.expanduser("~%s" % username)
komutunu çözüm olarak buldum.
Diğer umount işlemlerini de normal bir şekilde devam ettirdim. Ve kod daha iyi bir durumdaydı.
Şimdilik yapmam gerekenlerden biri /tmp/ nin içersinde öyle bir dizin olsa bile mktemp komutu guestX.XXXXXX dizinini oluşturmayıp ona bağlamamı sağlıyorsa bu bir güvenlik açığı olur. Bunun bir araştırmasını yapıp, gerekirse oraya bir kontrol koymak olacak.
18 August 2010 @ 11:30 PM
Bugün halihazırda tamamlamış olduğum kod üzerinde bir kaç iyileştirme yaptım. README, AUTHORS ve COPYING dosyalarını düzenledim.
Yaptığım iyileştirmeler, eğer yapılandırma dosyasında değer atanmamış ise varsayılan değerleri kullanacak. Başlangıçta eğer sistemde guest_name isminde bir kullanıcı var ise modülü çalıştırmayacak, guest_group isminde bir grup yok ise bunu oluşturacak ve en önemlilerinden birisi ise ev dizinini bağlarken noexec özelliği ile bağlamak.
noexec bize önemli derecede güvenlik sağlıyor. Bu özellik sayesinde kullanıcı bağlandığı ev dizini içerisinde ikilik dosya çalıştıramayacak. Aynı zamanda da kendisi de ikilik dosya yazıp bunu çalıştıramayacak.
Varsayılan değerleri kullanma kısmını da, yapılandırma dosyasını okurken bir hata oluşursa except bloğuna geçip aktarıyor ve hata ayıklama (debug) modunda ekrana dosya okunamadı diye hata veriyor ya da değerleri okurken boş çıkar ise onun varsayılan değerlerini aktarıyorum.
Kullanıcının varlığını ise pwd.getpwnam() ile sorguluyorum. Bunu try-except bloğu içerisinde yapıyorum. try içerisinde bu başarılı olur ise geriye başarısız diye değer döndürüyor, eğer başarısız olur ise except bloğuna geçiyor ve burada da hiç bir şey yapmadan normal koda devam ediyor.
Grubun varlığını da grp.getgrnam() ile sorguluyorum. Yok ise yine hata ayıklama modunda ekrana grup bulunamadı, grup oluşturulacak yazıyor ve grubu "groupadd %s" % guest_group ile oluşturuyorum.
Ayrıca daha önceden /etc/pam.d/ içerisindeki dosyalardaki control yerine uzun uzun yazılar yazıyorduk. Sadece sufficient yazmak yeterli şu an. Daha önceden de yazdığım yazıda bunu düzelteceğim.
Bahadır'ın aklındaki bir proje olan /etc/pam.d/ içerisindeki yapılandırma dosyalarını düzenleme projesini biraz araştırdım ve bunu Ubuntu'da yapmakta olan birileri olduğunu öğrendim.
İstek ise şu adreste: https://blueprints.launchpad.net/ubuntu/+spec/pam-config-framework
Ayrıca 2003 yılında da http://www.mail-archive.com/debian-wnpp@lists.debian.org/msg18384.html adresinde belirtildiği gibi istenmiş fakat zaman aşımından kapanmış.
Ubuntu'daki bu projeyi hazırlayan arkadaşa eposta yolladım. Bana bu paketin Ubuntu ve Debian için pam içerisine koyduklarını söyledi. Bunu biraz daha araştırıp Pardus'a uygulanabilirliğini araştırmayı düşünüyorum.
Sırada bir de PiSi paketi yapmak var. Daha önceden almaya karar verip paketini yaptığım paketleri düzenleyip ve yeni alacağım paketleri belirleyip bunlar üzerine çalışmalar yapacağım.
Yani Pardus 2010 Yaz Stajı, benim için tam hızıyla, zevkli, heyecanlı, öğretici yani her şeyiyle çok güzel devam ediyor.
18 August 2010 @ 11:27 PM
Bugün içerisinde iyi gelişmeler oldu. KDM sorununu hallettim. Oswald ile epostalaşma sonucunda bir çözüme ulaşamınca kendim KDM'nin kaynak kodunu inceleyerek bir çözüme ulaşmaya çalıştım.
Ve aşağıdaki gibi bir çözüme ulaştım, aşağıdaki yama dosyası tam olarak PAM'dan bir kez daha PAM_USER'i alıyor. Bu şekilde hem 2 kez kontrol edilmiş oluyor hem de misafir kullanıcı hesabı çalışmış olur.
yama dosyası:
--- kdm/backend/client.c.old 2010-08-17 11:43:02.775903757 +0300
+++ kdm/backend/client.c 2010-08-17 11:43:19.548533659 +0300
@@ -474,14 +474,13 @@
* the module needs an own conversation plugin which does not cause
* curuser being set.
*/
- if (!curuser) {
- debug( " asking PAM for user ...\n" );
- pam_get_item( pamh, PAM_USER, &pitem );
- reInitErrorLog();
- strDup( &curuser, (const char *)pitem );
- gSendInt( V_PUT_USER );
- gSendStr( curuser );
- }
+ /* Always check username from PAM */
+ debug( " asking PAM for user ...\n" );
+ pam_get_item( pamh, PAM_USER, &pitem );
+ reInitErrorLog();
+ strDup( &curuser, (const char *)pitem );
+ gSendInt( V_PUT_USER );
+ gSendStr( curuser );
if (pretc != PAM_SUCCESS) {
/* Log the failed login attempt */
log_to_audit_system (curuser, td->remoteHost, td->name, AU_FAILED);
Bu yamayı kaynak koda uygulayıp, derleyip kurduğumuzda Misafir Kullanıcı sorunsuz olarak çalışıyor.
Şimdilik projede sadece ssh ile bağlantı sorunu kaldı, o da önemli bir sorun olarak görülmüyor.
Ayrıca PAM yapılandırma (/etc/pam.d/ içerisindeki) dosyaları düzenleme aracı yazmak gibi bir plan var. README dosyasını düzenledikten sonra burada yayınlamayı düşünüyorum.
Yama ise Pardus SVN depolarında mevcut. KDM nin de bir parçası olduğu "kdebase-workspace" paketinin bakımcısı olan Gökçen ile bu durumu konuştuktan sonra yamayı ona yolladım.
Paket Adresi: http://svn.pardus.org.tr/pardus/2009/devel/desktop/kde/base/kdebase-workspace/
Yama Adresi: http://svn.pardus.org.tr/pardus/2009/devel/desktop/kde/base/kdebase-workspace/files/pardus/kdm-pam-fix-for-guest-account.patch
18 August 2010 @ 01:01 AM
August 16, 2010
Bugün pam_python'u geliştiren kişiye yani Russell Stuart'a eposta yolladım. Bu epostada kısaca yazdığım modülün ne işe yaradığını, nerelerde sorunsuz çalıştığını, nerelerde sorun yarattığını, sorunların nerelerden kaynaklandığını, gerekli yapılandırma dosyalarının içeriklerini yazdım.
Kendisi gayet yardımcı olacak bir şekilde epostalarımı yanıtladı. Sorunun benim kodumda değil de KDM'nin kendi kodunda olduğundan bahsetti. Yani KDM, eğer PAM modülü içerisinde kullanıcı adı değişiyorsa değişen kullanıcı adını yok sayıp eski girilen ile devam ediyor.
Bunu denemek için, sistemde var olan iki kullanıcı arasında PAM modülü yardımıyla kullanıcı adlarını değiştirdim. Yani "pars" ve "parsik" sistemde var olan iki kullanıcı olsun. PAM modülünü eğer kullanıcı adı "pars" ise onu "parsik" olarak değiştirip PAM_SUCCESS geri döndürdüm.
Sonuç olarak kde ye ilk girdiğim kullanıcı adı olan "pars" ile giriş yaptım. Yani KDM, PAM modülü içerisinde yapılan değişikliği yok sayıyor.
Bunun üzerine açılışta kdm yerine xdm ile deneyeyim dedim. Bunun için /etc/default/xdm içerisinde:
DISPLAY_MANAGER="kdm"
satırını
DISPLAY_MANAGER="xdm"
olarak değiştirdim. Ekran açıldığında kullanıcı adına "guest" yazıp entere bastıktan sonra kde açıldı. Yani sorun KDM'deymiş. Bunun üzerine ofiste önce Bahadır ile sorunu nasıl çözebiliriz diye konuştuk sonra Ozan ile bunun üzerine önce bunu başka türlü nasıl çözebiliriz, acaba böyle bir çözüm uygun bir çözüm değil mi üzerine konuştuk sonra da kısa bir süre kodları inceledik. Tam olarak bir çözüme ulaşamadık, biraz daha fazla incelememiz gerekiyor.
Bu blog girdimi girmeden yaklaşık 1 saat önce de KDE KDM geliştiricisi olan Oswald Buddenhagen'a eposta attım. Ona da yazdığım modülü ve karşılaştığım hatalar ile ilgili bilgi içeren bir eposta attım. Onun cevabını bekleyene kadar da KDM'nin kaynak kodunu inceleyip Russell Stuart'ın dediği gibi PAM_USER ile ilgili olan yerleri inceleyeceğim.
Herhangi bir gelişmeyi yine buraya yazacağım.
16 August 2010 @ 11:47 PM
Haftasonumu projedeki sıkıntıları araştırmakla geçirdim diyebilirim. 2 tane sorun var şimdilik bilinen. Bunlardan biri ssh bağlantı sağlanamaması, öteki ise kdm den bağlantı sağlanamaması.
Ssh'daki sorun da şu şekilde: Eğer normal bağlanmaya çalışırsam kesinlikle bağlanmıyor ve
Connection closed by ::1
Şeklinde hata alıyorum. Sanırım bunun sebebi var olmayan bir kullanıcı ile bağlanmaya çalıştığım için oluyor dedim ve "/etc/ssh/sshd_config" dosyasında bununla ilgili bir şeyler aradım. Sonuç olarak yapılandırma dosyasında 3 tane değişken ile oynamak gerekiyormuş. Bunlar:
UsePAM yes
PasswordAuthentication no
ChallengeResponseAuthentication no
Bunları bu şekilde düzelttikten sonra (kimisinin başında # vardı kimisi yes idi no yaptım) tekrar denedim. Bu sefer de:
Permission denied (publickey).
Hatası aldım. Bunu da araştırdığımda openssh'ın PAM'daki kullanıcı ismi değişikliğini kabul etmemesinin buna sebep olabileceğini öğrendim. Bununla ilgili bir yama buldum ve Pazartesi günü (16.08.2010) bunu uyguladıktan sonra sonuçları ile birlikte buraya yazacağım.
XDM sorununun çözümünü bulmak için başta google'da ayrıntılı bir arama yaptım, fakat hala bir çözüm yoktu. Sonra xdm/kdm'de kullanılan benim projeme benzer modülleri araştırdım. Zaten benimki gibi bir proje bulmak çok zordu ama parmak izi gibi kimlik doğrulama modülleri kullananlara baktım. Kaynak kodunu indirip inceledim, bir kaç şey gözüme çarptı.
Kaynak kod içerisinde $XAUTHORITY ortam değişkenine "$HOME/.Xauthority" değerini atıyorlar ve $DISPLAY ortam değişkenine de pam_tty değerini atıyorlar(pam_python'daki karşılığı pamh.tty oluyor). Ben de bunları gördükten sonra. os.environ[]'u kullanarak bu ortam değişkenlerine gerekli değerleri atadım ama hala sorun çözülmemişti.
Sonra sorun acaba kullanıcıyı PAM modülü üzerinden oluşturduğum için mi oluyor diye şüphelendim. Bunun için yarattığım kullanıcı adını da girilen kullanıcı adıyla aynı yaptım (yani guest adında kullanıcı oluşturdum guestX değil) ve sorunsuz bir şekilde çalıştı.
Kullanıcıyı PAM modülü içerisinde yaratmanın da bir sıkıntı yaratmadığını anladıktan sonra aklıma acaba kullanıcı adı değiştirmenin bir sorun yaratıp yaratmadığı geldi. Bunun için de kullanıcı adını varolan bir kullanıcı adına yönlendirdim. Yani:
pamh.user = sistemde_varolan_bir_kullanici
şeklinde atadım. Ve bunda da sorunsuz bir şekilde açıldı. Benim aklıma gelenler arasında geriye tek bir seçenek kalmıştı. Bu da girilen kullanıcı adı ile PAM tarafından verilen kullanıcı adının aynı olmamasıydı. Yani bir şekilde KDM, girilen kullanıcı adını alıyor bir yerlere yazıyor ya da onunla ilgili kimlik doğrulaması yapmaya çalışıyordu.
KDM nin de kendi kimlik doğrulamaları vb. şeyler var mı diye bir araştırma yaptım. Xauth'u biraz inceledim. Burada cevap bulamayınca "/etc/X11/kdm/" içerisindeki yapılandırma dosyalarında işime yarayacak herhangi bir şey aradım ama nafile. Sanırım şimdi yapmam gereken şey KDM nin kendi kimlik doğrulamasını kapatmak veya bunu PAM dan sonra yapmasını sağlamak. Bunun için de KDM nin kaynak kodunu indirdim ve incelemeye başladım. Şimdilik kodu inceleyip anlama kısmındayım. Gerçi daha yeni başladım KDM nin kaynak kodunu incelemeye ama yarın Pardus ofisinde bu incelemeyi hızlandırıp bu KDM sorununu da çözmeyi düşünüyorum.
16 August 2010 @ 11:20 PM
Bugün, Misafir kullanıcı modülüne eğer işlemlerde bir sorun varsa ona göre işlemleri geri alıp geri değer döndürme fonksiyonu hazırladım.
Bu fonksiyon ayrıca sadece geri değer döndürme işine de yarıyor. Aldığı integer tipindeki değere göre işlem yapıyor. Böylece geri döndürülen değer sırasında bir işlem yapma veya diğer işlemlerde büyük esneklik kazandırmış oldu.
İşlemleri geri alma da şu şekilde oluyor. Her adım sırasında yapılan işlemi kontrol ediyor ve bir önceki adımların zıttını uyguluyorum. Mesela eğer klasör oluşturulup bağlama sırasında bir sorun olursa dizini silip, bir hata kodu gönderiyorum. Bu şekilde bütün kodda kontroller var artık.
Ayrıca tüm komutları subprocess ile kullanamamak gibi bir sorunla karşılaştım demiştim. Aslında o öyle değilmiş, o işlemin bitmesini beklemek gerekiyormuş yani
a = subprocess.Popen([..........])
a.wait()
buradaki wait komutu bütün işi halletti. Yani koddaki bütün os.system leri Popen ile hallettim.
Ayrıca sistem politikaları gereği chown, usermod ile değişiklik yapmak yerine kullanıcı oluştururken ev dizinini belirlemenin daha uygun olduğunu düşündük. Bunun için bunları kaldırıp, rastgele isim üreten bir fonksiyon oluşturup kullanıcıya bu dizini vermek gibi bir plan yaptık.
Fakat burada bir güvenlik açığı oluşuyordu. O dizini kullanıcıya verene kadar bir şey olup olmayacağını bilmiyorduk. flock vb. komutları incelememize rağmen bir çözüme ulaşamıyorduk çünkü flock ile kilitlesek bile useradd komutu sırasında bir şeyler olabilirdi ve useradd komutu eğer ev dizini varsa bile 0 değerini geri döndürüyor. Bunun için başka bir çözüm arayışına girdik.
Sonuç olarak yine mktemp ile rasgele dizin oluşturup onun içerisinde home diye bir dizini o kullanıcıya vermek kararına vardık.
Kod ise aşağıdaki şekilde:
"mktemp -td %s.XXXXXX" % username
"mount -t tmpfs -o size=%sm -o mode=711 none %s" % (guest_home_dir_size, home_dir)
useradd -m -d %s/home -g %s %s" % (home_dir, guest_group_name, username)
Burada mode=711 sayesinde useradd ile ev dizinini oluşturabiliyoruz.
guest_home_dir_size -> ev dizin boyutu, home_dir -> ev dizininin konumu, username -> kullanıcı adı (guestX şeklindeki)
bu şekilde bu sorunun da üstesinden geldik. Pardus 2010 Yaz Stajının 2. haftası da bitti. Her şey çok güzel gidiyor. Burada çalışmak gerçekten çok zevkli ve çok güzel.
Şimdilik çözülmesi gereken sorunlar:
ssh üzerinden bağlantı sağlanmıyor.
kdm ile de bağlanılamıyor.
16 August 2010 @ 11:17 PM
Hikâye bu ya, Osman Efendi bir sabah müthiş bir baş ağrısıyla uyanır.
İlaç alır, geçmez. Bir iki gün bekler, ağrı devam eder.
Doktor çağrılır. Doktor muayene eder, ağrı kesiciler verir, gider. Lakin Osman Efendi’nin baş ağrısı artarak sürer.
Üstüne üstlük baş ağrısı yanı sıra gözleri de yaşarmaya baslar. Başka doktorlar çağrılır… Osman Efendi ağrıyı kesene servet vaat eder. Doktorların hiçbiri ağrıyı durduramadığı gibi sebebini de bulamaz. Ev halkı birbirine karışır, baş ağrısından geceleri uyuyamayan Osman Efendi’yi İstanbul’a götürmeye karar verirler.
İstanbul’da en iyi doktorlar seferber olur. Röntgenler, beyin tomografileri çekilir, testler yapılır… Görünüşe bakılırsa Osman Efendi turp gibidir. Oysa dayanması gittikçe zorlaşan baş ağrısı ve gözyaşları hayatı çekilmez hale getirmiştir.
Ağrı kesici iğnelerle zor ayakta duran Osman Efendi bu defa da apar topar yurtdışına götürülür. O devirde Amerika değil İsviçre moda, Zürih’e gidilir. Haftalarca hastanede kalınır, onlarca profesör konsültasyon yapar, testler tekrarlanır.
(…)
Osman Efendi’ye teşhis konulamaz. Artık yerinden kalkamayan Osman Efendi’ye ağrı kesici iğneler verilir, ülkesine dönüp “dinlenmesi”, daha doğrusu son günlerini -evinde- geçirmesi tavsiye edilir. Osman Efendi bitkin, aile perişan. “Kader” denilir, Uşak’a dönülür.
Osman Efendi yayla evinde bir odaya yatırılır ve ağrı kesici iğnelerle ölümü beklemeye başlar. Bir gün, hastanın keyfi gelsin diye, Osman Efendi’nin eski berberi Berber Mehmet çağrılır. Berber yataktan kalkamayan Osman Efendi’yi tıraş ederken, adamcağız derdini anlatır ve ölümü beklediğini söyler.
Berber Mehmet bir an düşünür. “Beyim?” der, “Sakın sizin burnunuzda kıl dönmüş olmasın.” Bir bakar, “Hah işte” der. “Kıl dönmüş.” Osman Efendi’nin şaşkın bakışlarına aldırmaksızın çantasından cımbızı kaptığı gibi kılı çeker. Ev halkı Osman Efendinin köyü ayağa kaldıran çığlığıyla odaya koşar.
Berber Mehmet, Osman Efendi’nin elinden zor alınır ve cımbızın ucunda tuttuğu 20 santimlik kılla kapı dışarı edilir.
Osman Efendi’nin kanayan burnuna pansumanlar yapılır, kolonyalar koklatılır ve yaşlı adam tekrar yatağına yatırılır. Ertesi sabah Osman Efendi aylardır ilk defa rahat bir uykudan uyanır. Gözlerinin yaşarması geçmiştir. Baş ağrısından ise eser kalmamıştır. Dönen kılın sinire yürüyüp gittikçe uzayarak dayanılmaz ıstıraplara yol açtığını doktorlar ancak o zaman keşfeder. Çözümün bu kadar basit olabileceği kimsenin aklına gelmemiştir. Sapasağlam ayağa kalkan Osman Efendi, Berber Mehmet’i çağırtır ve ona bir servet bağışlar.
(…)
Hikâye böyle işte..
Gelelim bu kıssadan çıkarılacak hisseye…
Üç hisse çıkarılabilir hikâyede:
1) Berber Mehmet efendilerin fikirleri var, dinlemek gerek.
2) Empati eksikliğiniz varsa, yorum yapmayın. İnsanları küçümsemeyin, çözümün parçası olun.
3) Burnundan kıl aldırtmayanların başı çok ağrıyabilir.
16 August 2010 @ 10:06 AM
August 15, 2010
Birkaç saat evvel, Freenode sunucularındaki #ozgurlukicin kanalında; önceki staj döneminde yapılan fikir arayüzü hakkında bilgi vermek, yeni staj döneminde geliştiricilecek tema bölümü için fikir toplamak, Pardus 2011′e Öİ’den gelecek katkılar ve Öİ 3.0 olarak tabir edilen yeni site altyapısı ile ilgili beyin fırtınası yapmak (toplantı sırasında bu madde atlandı) gibi dört ana gündem maddesine sahip bir IRC toplantısı yapıldı. Merak edenler, sohbet kayıtlarını Pardus-Wiki‘den okuyabilir.
3 saate yakın süren bu yazılı toplantı sonrası nüksetti yazma isteği. Onca konuşma arasında sesimin duyulmamasından, herşeyi söyleyemediğimden, biraz da Pazar gecesinin son saatlerini yanlış geçirdiğim düşüncesinden.
6 adam*haftalık çalışma sonrası yenilenen yeni fikirler arayüzü “Beyin 2″ ile başladı tartışma, programa uygun olarak. Uygulamanın işleyişinden ve Pardus 2011 özellik seçimindeki rolünden bahsedildikten sonra, arayüzün en sağlıklı nasıl kullanılacağı/yönetileceği konusu tartışmaya açıldı. 10 dakika süren kısa ve öz konuşmaların ardından kanaldaki moderasyon kaldırıldı ve yarım saatten biraz daha uzun bir süre, fikir arayüzünde oyların gizli olup olmaması, yorum yazma zorunluluğu, yorum uzunluğu gibi; keşke 6 adam*haftalık çalışma öncesinde forumda karara bağlansaydı dediğim tartışmalarla israf edildi.
İlk yarım saatin ardından başlayan “neler fikirdir, neler değildir”, “tekrarlar nasıl engellenir” tartışması sahalarda görmek istediğimiz hareketlerden olsa da; fikirlerin geliştiricilere nasıl iletileceği tartışması, SCT (Sürüm Camia Temsilcisi) kavramını ve camiayı ciddiye aldığımızı, Öİ’nin en aktif katkıcılarına dahi iyi anlatamadığımızın göstergesi gibiydi. 1 saat geçtiğinde, Pardus 2011 için kullanıcıların daha fazla fikir girmeleri için bir “seferberlik” başlatılması, haberler yazılması, banner’lar hazırlanması kararlarıyla, ilk toplantı maddesinin yanına büyük bir “tik” konmuş oldu.
Bir söylentiye göre açık 220′den fazla “fikir” vardı ortada. “15 gün sürecek bir seferberlik, mevcut fikirlerin tekrarlanmasından öteye geçebilecek mi?” ve “seferberlik olmasa da, insanlar fikirlerini beyan etmeye devam etmeyecek mi?” gibi sorular hala aklımda. Belki, o an farkında olmasam da, ana sürümler arası camiadan uzaklaşan kullanıcıları hareketlendirmek, heyecanı artırmak için bir taktikti bu aslında…
Konu temalara geldi sonra, henüz kodlanmaya başlanmamış yeni arayüz için iyi-kötü fikirler atıldı ortaya, 2011 için tema ve duvarkağıdı yarışması ve Öİ tarafından hazırlanacağını öğrendiğim 2011 Pardus Turu uygulaması konuşuldu. Moderasyonun kaldırılmış olmasından belki, önemli fikirler aradan cımbızla seçildi bu tartışmada. Ne yazık ki yine, 1 saatin çok az kısmından verim alınabildi zannımca.
2. saatin sonlarına doğru başlayan ve en çok merak ettiğim “Pardus 2011′e Özgürlükİçin tarafında verilebilecek katkılar” bölümü ise, tahmin ettiğim gibi, yeni fikirler arayüzünde konuşulması gereken konuların ve -daha kötüsü- yeni fikirler arayüzünde bile yeri olmayan “KDE güncel olsun”, “kernel son sürüm olsun”, “Müdür (Pardus’un açılış sistemi) ölsün” türü temennilerin ortaya atıldığı bir serbest atışa dönüştü. Bir arkadaşın dediği gibi, “Çözünürlük değiştirirken oturumu kapatmak gerekmesin” türü bir fikir gelseydi, içim cız etmeyecekti. Hem yeni fikirler arayüzü, hem de SCT; sanki bu tartışmada çiğnendi.
Saat gece yarısına yaklaşınca toplantı bitti, katılımcıların yarısından çoğu kanalda durmaya devam edince; öğrenci temsilciliği, Pardus Kurumsal 2 sürüm takvimi haberler, Ajans Pardus içeriği gibi konulara geçildi. Ben ve Akın (Ömeroğlu) dışında kimse atlanan haberler konusunda fikir beyan etmese de; 2011′in geliştiriciler için hazırlanan ön sürüm haberinin Pardus-Linux.Org tarafından “taze taze” servis edilirken, Öİ’de “kullanıcılar bu sürümü kurarsa sorun yaşarlar” düşüncesiyle yer verilmemesi; Oracle’ın Google’a Android işletim sistemindeki patent ihlalleri hakkında dava açması haberinin “çevirilecekler” listesinde sahipsiz beklemesi ve en büyük Linux konferanslarından LinuxCon 2010′un çeviri listesinde bile kendine yer bulamaması önemli konular arasındaydı. Muhalif olmamdan belki, toplantının en faydalı bulduğum kısmı burasıydı.
Yakın zamanda Pardus 2011 geliştirici toplantısı yapacağız IRC’de, aynı adresteki #pardus kanalında. Umarım zamanımızı iyi yönetebilir, gereksiz ayrıntılardan kaçabilir ve mümkün olduğunca az insanın “zaman kaybettim” düşüncesiyle bilgisayarını kapatmasını sağlayabiliriz. İyi geceler.
15 August 2010 @ 10:35 PM
August 13, 2010
Misafir kullanıcı çalışmaları son hızda devam ederken öbür yandan da pam_python'un PiSi paketini oluşturdum. Kurarken karşılaştığım bir sorun olan libpython2.6.so.1'in bulunamaması için de bir yama yaptım.
Bu yama kaynak koddaki src/setup.py dosyasında libpython2.6.so.1 yerine libpython2.6.so.1.0 yapıyor. (aslında versiyonu sistemden alıyor)
Bu paket üzerinden kurulduğu zaman herhangi bir sorun olmadan pam_python'u kullanabiliyorsunuz.
Paketi oluşturduktan sonra yapılacak işlerden olan hata çözümleme modu yaratmakla başladım. Bunun için argv değişkeninin içerisinde debug var ise debugging değişkenini True yapmak en mantıklısı olacak diye düşünüp bu şekilde uyguladım.
Kod içerisinde de if(debugging) ile kontrol ederek eğer doğru ise hazırlamış olduğum log fonksiyonuna bir çıktı gönderiyor.
log fonksiyonu ise bu şekilde
def log(text):
sys.stdout.write(text)
sys.stdout.flush()
burda sys.stdout.write şeklinde yazmak en mantıklısı olacak çünkü eğer X açıkken yapılacak olursa bu işlemler print ya da başka fonksiyonlar işe yaramayabilir. Stdout ise her durumda işimize yarayacak bir şey. Tabi bu işlemler için de sys modülünü kullandığım için yukarıda import sys yapıyorum.
İçeride de loglama şu şekilde:
if(debugging):
log("Yazı")
kodda aşama aşama ilerlemeler bu şekilde yapılıyor.
Debugging işlemini hallettikten sonra da bir sonraki iş olarak os.system yerine subprocess.popen ile yapabileceklerimi belirleyip onları değiştirdim.
Bir de girilecek kullanıcı adı, ev dizini boyutu ve girebilecek en fazla kullanıcı sayısını tutmak için bir yapılandırma dosyası oluşturdum. Bunu da /etc/security/ nin içerisine koydum.
Dosya adı guestlogin.conf. Üzerinden değişkenleri almak için ConfigParser modülünü kullanıyorum. Kod ise aşağıdaki şekilde:
try:
config = ConfigParser.ConfigParser()
config.read('/etc/security/guestlogin.conf')
guest_name = config.get('guest', 'guestname')
guest_limit = config.getint('guest', 'guestlimit')
guest_home_dir_size = config.getint('guest', 'homedirsize')
except:
return pamh.PAM_AUTHINFO_UNAVAIL
guestlogin.conf dosyası ise aşağıdaki gibi:
[guest]
guestname = guest
guestlimit = 50
homedirsize = 100
Bu şekilde biraz daha esneklik kazandırmış olduk.
Şimdilik aklıma gelenler bunlar fakat projeye eklemeler yapılacak.
13 August 2010 @ 01:27 AM
Bugün işe PAM'ı iyice araştırarak başladım. Nasıl modül oluşturulacağına kadar bir çok belge okudum ve geliştiricilerden sevgili Bahadır'ın da yardımıyla bu modülü Python ile yazmaya karar verdik.
Bunun için de pamobc gibi paketin de olduğu listeden pam_python'u kurmayı uygun gördük. kaynak kodunu
http://www.stuart.id.au/russell/files/pam_python adresinden indirdikten sonra tar ile açıp
./configure
make
sudo make install
komutları ile sorunsuz kurdum.
Kontrol amaçlı pam_python.so dosyasını /lib/security/ nin içerisine koyup koymadığına baktım ve oradaydı. Yani sıra gerekli modülümüzü yazmaktaydı.
Modülü yazmak için sıradan bir python betiği yazmamız gerekiyordu. Tek farkı bu betik dışarıdan çağırılacağı için, çağırıldığı yere göre belirli metotlara sahip olması gerekiyordu. Bu çağrıldığı yerler ise /etc/pam.d/ dizinin içinden seçilen dosyalar.
Mesela biz system-auth içerisine:
auth sufficient pam_python.so guestlogin.py
satırını ekledik. İlk sırada auth var çünkü kimlik denetimi sırasında çalışmasını istiyoruz. Sufficient ise bunun yeterli olduğunu söylüyor. Diğerleri ise pam_python kullanılacağını ve guestlogin.py betiğinin kullanılacağını söylüyor.
İlk başta merak ettiğiniz soru guestlogin.py dosyası nerede olacak olabilir. Çözümü basit, tahmin edilen ilk yer gibi pam_python.so dosyasıyla aynı yerde yani varsayılan olarak /lib/security/ dizininin içerisinde.
Bu dosyanın içerisinde bulunması gereken metotlar:
def pam_sm_authenticate(pamh, flags, argv):
ve
def pam_sm_setcred(pamh, flags, argv):
metotları. Tabii ki şimdilik bunlar lazım. Çünkü system-auth dosyasında ilk başa auth yazdık. Diğer yazacağımız account, session, password için farklı metotlara ihtiyaç duyuyor pam_python.
Ben şimdilik sadece pam_sm_authenticate metotunda işlem yapıyorum. Öbür metot olan pam_sm_setcred ise pamh.PAM_SUCCESS değerini döndürüyor. Bu da bu aşamadan geçmesini sağlıyor.
İlk iş olarak, pam_sm_authenticate metotunda ilk olarak oturum açıldığında /tmp/ nin içerisinde bir dosya açıp onun içerisine herhangi bir şey yazdırmakla başladım. Sonuç başarısız. Auth.log, syslog ne varsa inceledim bir sonuç elde edemedim. Sorun acaba pam_python da mı diye biraz bakındım ama olma ihtimali da pek yüksek değildi. Kafayı yemeden yemek yemeye gittik.
Dönüşte Bahadır ile beraber debugging yaptık. /etc/pam.d/system-auth dosyasındaki sırayla oynadık. Öncelikle en altta idi. Bir yukarıda da sonuç değişmedi. Sonra pam_unix.so nun üzerine koyduk. Ve çalıştı. Meğersem PAM, pam_unix.so çalıştıktan sonra alttakilere hiç bakmıyormuş.
Bu şekilde bu sorunu çözdükten sonra auth.log dosyasına düşen bir şey yüzünden çalışmadığını ve çalışmayacağını anladım. Sorun /usr/lib/libpython2.6.so.1 dosyasının bulunmamasıydı. pam_python paketi bu dosyayı arıyor ve bulamayınca çalışmıyordu. Bunun için şimdilik bir çözüm olarak orada libpython2.6.so.1.0 a sembolik link olacak şekilde aradığı isimde dosya oluşturdum.
Bu sorunu da hallettikten sonra sırada bizi bambaşka ve çok önemli bir sorun bekliyordu. Şimdi bizim yapmamız gereken eğer kullanıcının ismi guest ise parolasız olarak direk konsola düşmesini sağlamaktı. Bunun için de metotun içerisine kullanıcı adı eğer guest ise pamh.PAM_SUCCESS sonucunu döndürerek konsola düşmesini sağlayacak kod yazdım. Kod çalışıyor lakin konsola düşmüyordu. Ne olabileceğini düşünürken Bahadır'ın aklına gelen nss (nameserverswitch) hayallerimizi biraz yıktı diyebilirim. Login işlemi sırasında nss den alınan ev dizini bilgisi kullanılıyordu ve bizim de buna çok ihtiyacımız vardı çünkü guest adıyla giriş yapmaya çalışan birisine ev dizinini bizi oluşturup tmpfs ile bağlayıp atamamız gerekiyordu. /etc/nsswitch.conf dosyasının içine baktığımızda da işe yarar bir çözüm bulamadık. NSS'ye modül yazma araştırmasından da bir çözüm çıkmayınca bu sorunun etrafından dolaşarak (workaround) bir çözüm bulma çabalarına girdik. Çözüm şu şekildeydi:
eğer girilen kullanıcı adı guest ise pwd yi kullanarak sıradaki ilk guestX (X bir tamsayı)'i buluyor, os.system()'i kullanarak adduser ile guestX adlı kullanıcıyı oluşturuyor ve pam ile bu kullanıcıyı buna atıyorduk. PAM'ın yaptığı girilen kullanıcının ismini (username) guestX yapıp konsola düşmesini sağlıyor. Bu şekilde hem kullanıcı hem de ev dizini yaratıyorduk. Tabi bu şimdilik bir çözümdü, ilerde (belki de bu yazıyı yazdıktan sonra :)) tmpfs ile bir klasörü bağlayıp kullanıcının ev dizini olarak onu belirleyecektik.
Buradaki guestX'in de elde edimini pwd modülünü kullanarak sağlıyorum. Kod parçacığı aşağıdaki şekilde:
users = [x.pw_name for x in pwd.getpwall()]
i = 1
while guest_name + str(i) in users:
i = i + 1
önce users değişkeninin içerisine bütün kullanıcı listesini atıyorum. Sonra da bunun içerisinde guestX var mı diye bakıyorum. Eğer var ise guest1,2,3... diye ilerliyor.
Burada kullanmış olduğum guest_name ise misafir kullanıcının adının tutulduğu değişken (mesela varsayılan olarak "guest" oluyor)
Şimdilik bu çözüm üzerinden giderek guest ile giriş yapılmasını sağladım. Sorun yok gibi gözüküyor. Tabi sıradaki ilk iş kullanıcı çıkış yaptığında da kullanıcının ve ev dizininin silinmesi.
13 August 2010 @ 12:14 AM
August 11, 2010
iO kartımızla kolayca çeşitli hareketli prototipler yaparken motor sürücülere de sık sık işimiz düşüyordu.
Her seferinde uğraşmak yerine, kullanışlı ve küçük bir tane ürettik. Sizin de ilginizi çekiyorsa bu sayfadan detaylı bilgi alabilirsiniz.
11 August 2010 @ 09:04 PM
Yaklaşık bir yıl önce yazmış olduğum bir yazıdan yola çıkarak, topluluğun başlangıcından büyümesine kadar nasıl evrelerden geçebildiğini ve ne gibi sorunlar ile karşılaşabildiğini farklı ve daha ayrıntılı bir yazı olarak ortaya çıkardım.
Bu yazmış olduğum yazı geçen hafta sonu yapmış olduğumuz Pardus Camia Zirvesin’de benim payıma düşen kısmın sunumlarını hazırlamak için oldukça yararlı oldu. (Sunumlar: topluluk başlangıcı & gelişimi ve bebek->genç pardus)
Yazımı aşağıda bulabilirsiniz:
Özet
Açık kaynak toplulukları ilginç bir şekilde güvenli ve kaliteli yazılımlar üretmektedir. Bu makalede, topluluklarının ve geliştirme ortamının tamamıyla açık olduğu bir yazılımın nasıl güvenli ve kaliteli bir şekilde üretilebileceğini açıklamaya çalışacağız. Bir özgür yazılım projesi olan Pardus Linux Dağıtımının organizasyonel davranışı ile yazılım kalitesi ve güvenilirliği arasındaki bağ anlatılacaktır.
Şu ana kadar edindiğimiz topluluk geçmişi deneyimlerine dayanarak diyebiliriz ki; bir açık kaynak projesinde, yazılımı kullanan katkıcıların çokluğu, iletişim ve bilgi akışının tamamıyla açık olması güvenli ve kaliteli yazılım üretilmesini sağlamaktadır.
1. Giriş
Açık kaynak toplulukları farklı ilgi, eğilim ve becerileri olan yüzlerce, bazen binlerce gönüllü kişinin oluşturduğu gruplardır. İlginç bir şekilde, bu gönüllü kişilerden oluşmuş toplulukların üyeleri, neredeyse hayatları boyunca sanal ortam dışında ve birbirleriyle hiç yüz yüze görüşmeden, bir ekip olarak; büyük, karmaşık ve güvenilir yazılım projeleri geliştirmekte ve iyileştirmektedirler. Üstelik bu projeler birçok bireysel, kurumsal ve devletsel alanda dünya çapında kullanılmaktadır.
Pardus depolarında yaklaşık olarak 4,500,000 satır kod bulunmasına karşın, Pardus’u kullanan tüm kullanıcılara açık olan hata takip sisteminde raporlanan hata sayısı yaklaşık 1500 civarındadır. Bu raporlanan hataların yaklaşık 200 kadarı yeni özellik bildirimlerini oluşturmaktadır. Bu durumda 100 satır başına düşen hata yoğunluğu yaklaşık olarak 0,031 bulunmaktadır[1].
Bu iyi sonuç karşısında aklımıza bir takım sorular takılabilmektedir: Bu gibi bir davranış nasıl bir yazılım projesi olarak sonuçlanabilir? Kararları kim vermektedir? Yazılım projesi sürecinde karşılaşılan anlaşmazlıklar nasıl çözülmektedir? Ortaya çıkan projenin kalitesi ve güvenilirliği nasıl garantilenmektedir?
[2]Dünyanın diğer bir ucunda bulunan hiç tanımadığınız bir yabancı, bir yama gönderebilir ve bu sizin geliştirmekte olduğunuz yazılımda bulunan bir hatayı çözebilmektedir. Açık kaynak yazılımların hız aldığı nokta burasıdır, bir hata ortaya çıktığında, birçok kullanıcının elinde bulunan kaynak kod, birden bire birilerinin elinde bir cevhere dönüşmekte ve hata hemen çözülebilmektedir. Peki bu yapılan değişikliğin kabul edilme ve tüm kullanıcıların karşısına çıkma süreci nasıl işlemektedir?
Bu makale ile, bu süreci, Pardus Linux Dağıtımının organizasyonel yapısı ile güvenli ve kaliteli yazılım üretmenin arasındaki ilişkiyi açıklayarak, anlatmaya çalışacağız.
2. Organizasyonel Davranış
Bu bölümde sırası ile organizasyonel davranış ve yapı, topluluk, topluluk oluşumu ve büyümesi ve toplulukta etik kavramlarından bahsedilecektir.
2.1. Organizasyonel Davranış
Belirli bir organizasyonun etkili ve verimli çalışması için kişiler, gruplar ve organizasyon yapılarının birbirleri arasındaki etkileşimini inceleyen çalışma alanıdır.
Organizasyonel davranışın temelinde;
- Organizasyon içerisinde bulunan üyeler arası iletişim ve etkileşim
- Organizasyon içerisinde bulunan üyelerin var olma amacı
- Organizasyon üyelerini motive eden unsurlar
- Organizasyon içi etik kısıtlar
- Organizasyon arası bilgi akışı ve organizasyonu etkili bir hale getirmek için bir bilgi birikimi oluşturmak yer almaktadır.
Organizasyonel davranış model olarak ilk önce bireyleri daha sonra grupları ve en son olarak da organizasyonların davranışlarını incelemekte; üretimi arttırmayı ve emek veren kitlenin motivasyonunu ve memnuniyetini ve bulunduğu organizasyona bağlılığını arttırmayı amaçlamaktadır.
2.2. Organizasyonel Yapı
Bir organizasyonun yapısının oluşmasında çevresindeki ekosistem büyük etkiye sahiptir. Çünkü organizasyonun güç bulacağı nokta ekosistemidir.
Ekosistemi ile etkileşim halinde olan organizasyonlar daha çabuk değişebilen ve gelişebilen bir yapıya sahiptir [4].
Bu ekosistemlere bağlı olarak farklı organizasyon yapıları oluşmuştur. Pardus’un bulunmuş olduğu ekosistem, bilgi paylaşımının ve iletişimin tamamıyla açık olduğu özgür bir sistemdir. Bu ekositem içerisinde oluşmuş bir organizasyonel yapı kendi kendine öğrenebilir ve gelişebilir bir yapı olarak ortaya çıkmıştır.
Kendi kendine öğrenen organizasyonlar, harekete geçmek için organizasyon üyelerinin gelişmesini amaçlar. Bu nedenle öğrenen organizasyon yaratıcılığı arttırma amacı güderek, devamlı olarak organizasyon içerisinde bulunan bireylerin tecrübelerini artırmaya çalışır.
2.3. Topluluk
Kendi kendine öğrenen organizasyonlar bir topluluk etrafında toplanmıştır. Bir organizasyon, hayat boyu öğrenici, değişikliklere karşı ilgili, karşıtlıklara karşı yapıcı ve farklı birçok alternatif olguya karşı bilinçli olabildiği sürece topluluk olarak tanımlanabilmektedir. Topluluk belirli bir unsur çerçevesinde sonsuz bir iletişim sağlayabilen insan topluluğudur [3].
2.4. Topluluğun Oluşması ve Büyümesi
Belirli bir amaç için oluşturulan bir organizasyonun başlangıcında, heyecan, yenilikçilik, yaratıcılık ve sıkı sıkıya bir birliktelik ve anlaşma bulunmaktadır. Fakat zaman içerisinde organizasyon hem yaptığı iş hem de üyeleri bakımından büyümekte ve farklı düşüncelere sahip olan bireyler ortaya çıkmaktadır. Bu dönem içerisinde farklı fikirlerin ortaya çıkışı bir organizasyonun iyiye gitmesi ve gelişmesi için olumludur. Fakat bu farklı fikirlerin ortaya çıkışı sırasında gerçekleşen tartışmaların çeşidi ve türü çok önemlidir [5].
Bu türler genel olarak iki şekilde ifade edilmektedir:
Fonksiyonel tartışma: Organizasyonun amaçları doğrultusunda olan bir konu hakkında, bireylerin bilgi ve becerileri ile nesnel olarak fikirlerini belirttikleri tartışma türleridir. Bu tip tartışmalarda farklı bakış açıları, yapılacak olan işin tüm yönleri ile görülmesini ve işin performansının artmasını sağlamaktadır.
Duygulanımlı Tartışma: Bu tip tartışmalar, bireyler arasında çeşitli nedenlerden dolayı ortaya çıkan ve öznel bilgileri içeren ve duygusal bir bakış açısı ile yapılan tartışmadır.
Bu iki tür tartışmanın organizasyon için yararları ve aynı zamanda zararları bulunabilmektedir.
Avantajları:
- Üretkenliği arttırır: Tartışma yaşayan gruplar yaşamayanlara göre daha hızlı bir büyüme çizgisine sahiptirler.
- Sürü psikolojisinin olmasını engeller: Fonksiyonel tartışmalar organizasyon üyelerini doğru düşünme, kritize etme ve alternatif yaratma gibi konularda tetikler.
- Yaratıcılığı arttırır: Fonksiyonel tartışmalar merak ve ilgiyi arttırmaktadır.
- Devamlılığı arttırır: Bir organizasyon içerisinde tartışma bir konu hakkında iyi ve kötü yönlerin iyi bir şekilde ortaya çıkmasını ve adil bir dengenin oluşmasını sağlar.
Dezavantajları:
- Duygulanımlı tartışmalar yıkıcı ve güçlü negatif etki yaratıcı, körü körüne bir düşünceye bağlanma ve bu şekilde bir dayanışma oluşturma ve bu uğurda agresifleşmeye yol açmaktadır.
- Duygulanımlı tartışmalar isteksizliğe neden olabilmektedir: Herkes düşüncesini belirtmek için kendi değer yargıları ve ilgi alanlarına sahiptir. Fakat nesnel olmayan tartışmaların yaşandığı organizasyonlarda bireysel değer yargıları incinmekte ve bu da isteksizliğe neden olmaktadır.
- Duygulanımlı tartışmalar toplulukların devamlılığını tehlikeye sokabilirler: Bir topluluğun başarısının tartışmaları çözme yönteminin kolaylığı ve var olmasına bağlı olduğu söylenmektedir.
Bir topluluğun oluşma evresi dört aşamada gerçekleşmektedir. İlk evre farklı düşüncelerin ve karşı çıkışların ortaya çıkmasıdır. Bu evrede yukarıda da bahsetmiş olduğumuz tartışmalar yaşanmakta, farklılıklar oluşmakta ve topluluk kavramı organizasyon için oturmaya başlamaktadır. Bir sonraki evre ise bireylerin farklılıklarının tam anlamıyla ortaya çıktığı ve netleştiği evredir. Bu evrede topluluğu iyiye götürecek birçok farklı düşünce üretilmekte ve denenmektedir. Bu evre aynı zamanda topluluğun iletişimin geliştiği ve iletişim yapısının oluştuğu evredir. Üçüncü evre ise topluluğun iletişimi ve öğrenim yapısı ve farklılıkları düşünülüp, topluluğun ekosistem ile nasıl etkileşime geçeceğini ve kendi arasında yönetilebileceğini anlatan kuralların oluşturulduğu ve standartlaştırıldığı dönemdir. Bu dönem içerisinde topluluk içerisinde yapılan iş ve nitelik farklılıkları oluşup alt gruplara ayrılabilmektedirler. Bu kurallar sayesinde kaotik olan süreç sona ermekte ve herkesin topluluk içerisinde mutlu bir şekilde var olduğu, kendini ve çevresindekileri geliştirebildiği bir ortam oluşmaktadır. En son evre, topluluk içi farklılıkların kucaklaştığı, topluluğun öğrenme, büyüme ve yaratma hızının devamlılığının sağlandığı ve topluluk var olduğu sürece yeni durum ve risklerin oluşması ile tekrarlanarak devam edecek bir evredir.
2.4. Toplulukta Etik
Topluluk oluşumu ve büyümesi gerçekleşirken bir kurallar bütünü oluşumundan önceki bölümde bahsetmiştik. Topluluk ve içinde bulunduğu bireylerin yararına ve yapılan işin daha sağlıklı düşünceler ile oluşmasına olanak sağlayacak olan görünmez sisteme etik demekteyiz.
Etik kendi kendine öğrenen bir topluluğun sağlıklı büyümesi, devam etmesi ve kaliteli işler çıkarabilmesi için önemlidir. Topluluk bu kurallar doğrultusunda yeni bireyeler kazanır, yeni oluşumlar sağlar ve etkin ve etkili bir şekilde bilgisini paylaşıp, yaratıcılığını ortaya çıkarır, güvenilir ve kaliteli işler çıkarabilir.
3. Pardus Topluluğu
Pardus Topluluğu’nun bu gibi topluluk oluşumu süreçlerinin bir kısmından geçtiği ve bir kısmından geçeceği kuşkusuzdur.
Pardus 2010 yılı içerisinde beşinci yılını kutlamış genç bir projedir. Burada genç dememizin nedeni, topluluk oluşum safhasının ilk aşamasını geçiği ve ikinci aşamasından çıkmak üzere olduğu ve diğer kısımları için yola çıktığıdır.
Pardus Topluluğu son iki yıldır belirli değişikliklere sahne olmakta ve çeşitli geliştirme süreç lerinde yeniden yapılanma yoluna gitmektedir.
Bu yeniden yapılanmanın nedenleri[6]:
- Topluluğun gelişimi ve yeni bireylerin katılımı için öğrenme mekanizmasını daha aktif kullanmak.
- Topluluk içi bilgi birikimi oluşumunu sağlamak.
- Yapılan işin izlenebilirliğini ve kontrolünü arttırmak ve tüm bireyleri bu işten haberder etmek
- Topluluk bireylerinin motivasyonun bağlılığını arttırmak
Yukarıda anlatılan nedenlerin hepsi aynı zamanda işin güvenilirliğini ve kalitesini arttırmaktadır.
Bu yukarıda sıralamış olduğumuz tüm nedenler doğrultusunda topluluk içerisinde uygulanmakta olan ve yeniden yapılanma içerisine girmiş olan kavramlardan ve yararlarından bahsedilecektir.
3.1. Katkıcı
Pardus’un geliştirme süreçleri içerisinde yapmış olduğu işlerin zamanla belirli farklılıklar içerdiğinin gözlemlenmesi ve kendi arasında amaç farklılıkları oluşması nedeni ile daha önce genel olarak geliştirici kavramı içerisinde olan birçok kavram ayrıştırılma ve farklı gruplar oluşturulma yoluna gidilmiştir. Böylece Pardus topluluğu içerisinde katkı veren her bir bireye katkıcı denilmiş ve katkıcı kavramının alt bölümleri ise farklı amaçlara sahip gruplara ayrılmıştır. [7]
Bu gruplar şu hali ile geliştirme, test, çeviri, belgeleme, görsel tasarım, tanıtım şeklindedir.
Toplulukta bulunan her bir birey sadece bir gruba dahil olabileceği gibi aynı anda birden fazla gruba da dahil olabilmektedir.
3.1.1. Sorumlulukları
Pardus Projesi var olduğundan bu yana katkı sağlayan her bir bireyin yapılan işe ve topluluğa karşı sorumluluklarının bulunması gerektiği düşünülmüştür. Bu sorumluluklar bireyler arası ilişkiyi güçlendirici, iletişimi ve bilgi akışını arttırıcı niteliktedir.
Devamlılık:
Bir katkıcının üzerinde çalıştığı projelerde sürekli olarak çalışabilmeyi göze almasıdır. Burada süreklilik ile ifade edilen 7/24 bir çalışma değil, fakat üzerinde çalışılan konunun devamlılığının sağlanmasıdır.
Doğruluk:
Proje içerisinde birden fazla katkıcı aynı konu üzerinde çalışıyor olabilir. Bunun yanında bir katkıcının yaptığı işten bir diğerinin etkilendiği durumlar da olabilir. Bu yüzden yapılan çalışmaların yalnızca sürekliliği değil, diğer katkıcıları etkilediği oranda doğruluğu da önemlidir.
Kararlılık:
Yapılan işte sık karar değişiklikleri yapılmamalıdır. Kararın sık bir şekilde değiştirilmesi, diğer katkıcıların gelişimi takip etmesini, fakat daha önemlisi o çalışmaya bağımlı olan katkıcıların çalışmalarını güçleştirecektir. Bu yüzden kararlar iyi düşünerek ve diğer katkıcıların de fikirleri alınarak verilmelidir.
İletişim:
Alınan kararlardan, küçük de olsa yapılan değişikliklerden diğer katkıcıları haberdar etmek gerekmektedir. Böylece ortak iş yapan katkıcılar daha uyumlu ve hızlı bir şekilde çalışabilmekte ve yeni katkıcılar da yapılan işi izleme imkanı bularak çalışılan konuya daha kolay adapte olabilmektedirler.
Bu iletişim ve bilgi akışı sayesinde yapılan çalışmada sorun yaşanılan bir noktada daha fazla fikir beyan edilebilmekte ve daha hızlı çözüm üretilebilmektedir.
3.1.2. Katkıcı alma ve yetiştirme sürecinin önemi
Pardus Projesine katılmak isteyen her bir birey belirli bir bilgilendirme sürecinden geçmektedir. Bu süreç bilgi akışını katkıcı adaylarına aktarabilmek adına oluşturulmuş bir süreçtir. Oluşturulmuş sistem sayesinde her bir adaya katılmak istediği alan doğrultusunda bir mentor atanmakta ve mentoru ile geçirdiği dönem boyunca gerekli tüm bilgiyi hızlı bir şekilde öğrenmesi sağlanmaktadır. Ayrıca mentorlar adayı bu dönem içerisinde izleyerek katkıcı sorumluluklarını yerine getirip getirmediğini de takip etmektedirler [8].
Pardus için katkı sağlayacak her bir bireyin topluluk içerisinde sorun yaşamadan çalışmalara katılması, verimli ve mutlu bir şekilde çalışması, sağlıklı iletişim kurması ve böylece kaliteli ve güvenilir iş çıkarabilmesi sağlanmaya çalışılmaktadır.
3.2. Hata Takip Sistemi
Hata takip sistemleri geliştirici ve kullanıcı arasında bir köprü oluşturarak, yaşanılan problem hakkında bilgi alışverişini ve çözüme kavuşması için yol göstericiliğini sağlamaktadır [9].
Bu bilgi alışverişinin iyileştirilmesi, hatanın hızlı çözümü ve dolayısı ile yapılan işin kalitesini arttırmaktadır.
3.2.1. Hata Raporlamak
Sistemin hızlı ve etkili kullanabilmesi, bilinçli hata raporlayan kullanıcıların çokluğuna bağlıdır. Hata takip sistemi deneyimlerimize dayanarak söyleyebiliriz ki, iyi raporlanmış ve kullanıcı, geliştirici bilgi alışverişinin hızlı olduğu hataların çözülme hızı diğerlerine göre fazladır[10].
Bu durumda, iyi hata raporlayan geniş bir kullanıcı kitlesi, yapılan işin kalitesini olumlu yönde etkileyen etmenlerden biridir denebilir.
3.2.2. Hata Kontrolü
Raporlanan hataların düzenli olarak gözden geçirilip, hangi tip hata olduğunun, öneminin ne olduğunun, eksik bilgiler içerip içermediğinin kontrol edilmesi, hata eğer kritik veya önemli bir hata ise, hızlı bir şekilde çözüme kavuşmasını sağlar [11].
3.3. Bilgi Kontrolü
Projenin her bir aşamasında birçok farklı gözün yer alması, yorumunu iletebilmesi ve bunların düzenli hale getirilmesi iş kalitesini ve güvenilirliğini arttırmaktadır.
Pardus Projesi yaptığı işleri farklı süreçlerden geçirerek kalite ve güvenilirliğini daha iyiye götürmeyi amaçlamaktadır.
3.3.1. Kod Gözden Geçirme
Pardus’ta bulunan yazılımların (paketlerin) geliştirme deposuna alınmadan önce diğer geliştiriciler tarafından onay aldığı bir süreç bulunmaktadır. Bu onay sırasında paketin Pardus’un paket politikalarına uygun olup olmadığı tecrübeli geliştiriciler tarafından gözden geçirilmektedir. [12]
Bu süreç sayesinde Pardus paket depolarında, paket kalitesini arttırıcı nitelikte alınmış kararların dışına çıkılmamış olunmaktadır.
3.3.1. Güvenlik Süreci
Pardus depolarında bulunan özgür yazılımların güvenlik açıklarını takip etmek ve bu açıklıkların kapatılmasını sağlamak için bir güvenlik ekibi oluşturulmuştur. Bu ekip diğer dağıtımlar ile ortak çalışır ve vendor-sec, oss-security gibi e-posta listelerini takip ederek, güvenlik açıklarının takibini gerçekleştir.
Bu süreç sayesinde hızlı bir şekilde güvenlik açıkları ortaya çıkarılmakta ve geliştiricileri tarafından kapatılmaktadır.
3.3.3. Test Süreci
Kararlı depoya aktarılacak ve kullanıcı karşısına çıkacak olan her paket test sürecinden geçmek zorundadır.
Bu amaç doğrultusunda Pardus test ekibi oluşturulmuştur [13]. Bu ekip sayesinde güvenlik güncellemeleri testleri ve düzenli olarak takip edilen kararlı depo testleri gerçekleştirilmekte ve paketlerin sistem içerisinde düzgün çalışıp çalışmadığının testi yapılmaktadır.
4. Sonuç
Pardus topluluğu ve oluşturmuş ve oluşturmakta olduğu süreçler; sağlıklı iletişimi, karşılıklı bilgi aktarımını ve birikimini iyileştirmeyi, etkili ve bilinçli büyümeyi amaçlamaktadır.
Bu amaçlarının varacağı nokta dünyanın herhangi bir yerinden geliştirme süreçlerine katılmış ve farklılıkları olan birçok bireyin aynı çatı altında güvenli ve kaliteli işler çıkarmasıdır.
5. Teşekkür
Bu yazıyı yazarken yardımlarını esirgemeyen ve geçmiş deneyimlerini paylaşan Pardus topluluğu üyelerine teşekkürlerimi sunarım.
6. Kaynaklar
[1] Geek.net, “Pardus Linux”, http://www.ohloh.net/p/pardus-linux/analyses/latestTrans. , 2010.
[2] Con Zymaris, “Linux security strong as ever”, http://www.zdnet.com/news/linux-security-strong-as-ever/298545. , 2010.
[3] David S. Walonick, “Organizational Theory and Behavior”, http://www.survey-software-solutions.com/walonick/organizational-theory.htm. , 2010.
[4] Knowledge Jump Production, “Leadership and Organizational Behavior”, http://www.nwlink.com/~donclark/leader/leadob.html. , 2010.
[5] Ruben van Wendel de Joode, “Managing Conflicts in Open Source Communities” , 2010.
[6] Carla C.J.M. Millar, Chong Ju Choi and Edward T. Russell, Jai-Boem Kim, “Open source communities: an integrally informed approach” , 2005.
[7] Pardus Linux, “New Contributors”, http://developer.pardus.org.tr/guides/newcontributor/index.html. , 2010.
[8] Pardus Linux, “How to be a Contirbutor?”, http://developer.pardus.org.tr/guides/newcontributor/how-to-be-contributor.html. , 2010.
[9] Pardus Linux, “Bug Tracking Guide”, http://developer.pardus.org.tr/guides/bugtracking/index.html. , 2010.
[10] Pardus Linux, “Bug Tracking System”, http://bugs.pardus.org.tr. , 2010.
[11] Pardus Linux, “Bug Tracking System”, http://developer.pardus.org.tr/guides/bugtracking/howto_bug_triage.html. , 2010.
[12] Pardus Linux, “Bug Tracking System”, http://developer.pardus.org.tr/guides/packaging/package-review-process.html. , 2010.
[13] Pardus Linux, “Bug Tracking System”, http://tr.pardus-wiki.org/Pardus:Test_Ekibi. , 2010.
11 August 2010 @ 07:56 AM
August 09, 2010
Bugün diğerlerine nazaran daha heyecanlı başladı. Bugünün başlarında daha çok bize verilen projeler listesindeki projeler üzerinde genel bir araştırma yaptık. Herkes kafasında bir proje belirledi ve onlar üzerinde yoğunlaştı.
Biraz daha araştırma yaptıktan sonra Staj Koordinatörümüz Renan Çakırerk geldi ve herkes projelerini belirledi.
Ben de Pardus'a Misafir Kullanıcı Ekleme projesini aldım.
Bu projeyi geliştirirken PAM (Pluggable Authentication Modules) ve Shell Script kullanacağım.
Bugün içerisinde şimdilik Misafir Kullanıcısında olması gerekenler, olmaması gerekenler üzerinde bir araştırma yaptım. Bir de PAM nedir onu araştırdım.
Biraz da Kabuk Programlama (Shell Scripting) araştırdım.
Bugünlük böyle.
09 August 2010 @ 10:41 PM
August 08, 2010
Pardus 2010 Yaz stajının Ağustos ayı döneminde staja kabul edildim.
Zaten heyecanlı olan staj başvuru ve sonuç açıklanma süresinden sonra staja gitmek için olan heyecanlı bekleme sona erdi.
İlk gün staj yapacağımız yer olan Tübitak MAM'a kendi imkanlarımızla ulaştık ki bu da benim oturduğum yer olan Kanarya Mah./Küçükçekmece'den yaklaşık olarak 2 Saat 30 Dakika sürdü. Yerleşke kesinlikle çok güzel bir yer. Üniversite kampüsü gibi. Staj yapacağım ofisi oradan sonra bulmak pek vakit almadı ama oranın güzelliğini incelemek bile çok güzel. İçeriye girdikten sonra Fotoğraf çekimi de yapmak yasak. Zaten UEKAE binasıının içerisine girerken Cep Telefonu, Ses kayıt cihazı, Taşınabilir bellek ve Mp3 çalar sokmak yasak.
Staja geldiğimde Staj Koordinatörümüz ve eski bir stajyer olan Renan Çakırerk bize, hem orada uymamız gereken kurallar ile ilgili bir belge hem de stajyerin el kılavuzu adında ilk hafta araştırmamız gereken ve yapmamız gerekenlere ilgili bir belge verdi.
Verdiği belge içerisinde öncelikle Linux'u, Pardus'u, Pardus Teknolojileri ve Mimarileri, kullanacağımız geliştirme araçları, PiSi paket yapımı ve yama yapımı gibi bilgiler barındırıyor. İlk hafta içerisinde de bunları okuyup bunlar üzerinde araştırmalar yaptık. Bilgisayarlar üzerinde de uygulayabileceklerimizi uyguladık. İlk haftanın son gününde , bize, yapabileceğimiz projeler ile ilgili bir kağıt dağıtıldı. Hafta sonu da bu projeler üzerinde genel olarak bir araştırma yapıp pazartesi günü eğer bir sorun çıkmaz ise bunlardan bir tanesini seçip başlayacağımız söylendi.
İlk hafta genel olarak böyle geçti. Pardus ekibiyle tanışıp kaynaşma, Pardus'u, Linux'u ve diğer teknolojileri araştırma.
Haftaya daha dolu dolu ve yoğun geçeceğe benziyor.
Bize kolay gelsin.
08 August 2010 @ 03:05 PM
August 02, 2010
Geçen gün Pardus proje yöneticisi Erkan Tekman'dan çok yakında düzenleyecekleri bir Pardus Camia Zirvesi'ne çağıran bir davet aldım. Zirveye çağrılan diğer kişilerin listesi belirtilmemiş. Davetin samimiyetine inanmakla birlikte, aşağıya da aldığım yanıtımda belirttiğim nedenlerden ötürü katılmayacağım.
Merhaba,
Özgür Yazılım felsefesine güçlü bir adanmışlık göstermediğiniz ve bunun devam edeceğini taahhüt etmediğiniz sürece üzerinde birleşebileceğimiz ortak bir vizyonumuz olmuyor. Bu konuda tartışacak bir şey yok. Hedefleriniz farklıysa o hedefleri paylaşan başka insanlar aramalısınız.
Camiayla yaşanan sorunlar konusuna gelelim. Bu konuda hatalarınız olduğunu yazmışsınız. Bunları kabul etmeniz olumlu ve olgun bir başlangıç. Bu toplantı da iyi yönde gelişme sağlar umarım. Ancak sorunların nedeni yalnızca iletişim eksikliği değil. Ortada somut sorunlar, ve konuşarak pek de kolay değişmeyecek gibi görünen bakış açısı sorunları var. Bu noktada konuşmadan önce, gönüllülerin yıllardır şikayet ettiği somut sorunların teker teker çözüldüğünü görmeyi tercih ederim.
Bu sebeplerle toplantıya katılmayacağım.
02 August 2010 @ 09:28 AM
July 30, 2010
Bir süre önce geliştirici e-posta listesinde başlayan tartışma ve sonrasında yaşanan tepkiler ışığında Pardus camiasının daha sağlıklı bir şekilde yapılanabilmesi için ciddi adımlar atmamız gerektiğini gördük. Atılacak adımları mevcut ve eski katkıcılarımızın, camia kanaat önderlerinin ve camiamızın daha az sesli ve fakat son derece önemli bir parçasını oluşturan kullanıcı camiası temsilcilerinin katılımı ile kararlaştırmanın en doğru yol olduğuna karar verdik. Bu amaçla 8 Ağustos 2010 Pazar günü İstanbul‘da bir “Pardus Camia Zirvesi” düzenliyoruz.
Toplantının yönetilebilirliği ve beklenen çıktıların yoğunluğu açısından toplantıya yalnızca davetlilerin katılmasını uygun gördük. Aşağıda gönderdiğimiz davet metnini sizlerle paylaşıyoruz. Henüz bir davetiye almamış iseniz ve bununla birlikte toplantıya katılmanız gerektiğini düşünüyorsanız bana (tekman _o işaret_ pardus.org.tr) bir e-posta göndererek davetiye talep edebilirsiniz. Ancak vurgulamalıyım ki toplantının yönetilebilirliği ve beklenen çıktıların yoğunluğu nedeniyle ancak geçmişte camia konusundaki tartışma ve çalışmalara katkıda bulunmuş ve bu toplantıda önemli bir katkı verebilecek arkadaşlarımıza davetiye gönderebileceğiz. Bununla birlikte toplantı tutanaklarının son derece hassas bir şekilde hazırlanarak tüm camiamız ile paylaşacağız ve toplantıya katıl(a)mayanların da görüşlerini alacağız.
İlk Pardus Camia Zirvesi’nin hem Pardus projesi ve hem de Türkiye özgür yazılım camiası için hayırlı sonuçlar doğurması dileğiyle…
Sayın <Pardus geliştiricisi/katkıcısı/kullanıcısı>,
TÜBİTAK UEKAE bünyesinde 2003 yılı sonbaharında başlatılan Pardus ulusal işletim sistemi geliştirme projesi, henüz tasarım ve geliştirme aşamaları öncesinde, araştırma ve planlama aşamasında Türkiye Linux ve özgür yazılım camiası ile ilişkiler kurmaya ve ortak çalışma olanaklarını aramaya başlamıştı. Bunun bir sonucu olarak, daha ilk ürünümüz olan Pardus Çalışan CD 2005 yılı başlarında yayımlanırken dahi, belgelemeden teste, kod katkısından paket yapmaya çeşitli alanlarda UEKAE ekibi ile birlikte geliştirme çalışmalarına katılan bir camia oluşmaya başlamıştı. Geçen zaman içerisinde ürünle birlikte camiamız da büyüdü ve gelişti.
Türkiye’de özgür yazılımın yayılması yanında yerel bilgi birikiminin ve yüksek katma değerli üretimin artmasını temel hedefleri arasına koyan Pardus projesi, özellikle katkıcılarının sayı ve özellik olarak artmasını, bu katkıcıların Pardus projesinin ve diğer özgür yazılım proje ve şirketlerinin gelişmesinde temel unsurlardan biri haline gelmesini, Türkiye özgür yazılım camiasının küresel camianın daha etkin ve bilinen bir parçası haline gelmesini arzulamaktadır.
Ancak, her özgür yazılım camiasında, hatta her camiada görülebileceği gibi iletişim sorunları, yanlış anlamalar, anlaşmazlıklar ve gereğinden sert tartışmalar Pardus camiasında da ortaya çıktı. Çeşitli zamanlarda, ve en son da geçtiğimiz haftalarda, bu tip sıkıntılar sonucu çok sayıda geliştiricimiz proje ile yollarını ayırmaya karar verdi ve bunu ilan etti. Katkıcıların sirkülasyonu özgür yazılım camiaları için doğal ve sağlıklı bir hareket olmakla birlikte, Pardus camiasında yaşanan kimi hareketlerin bu sağlıklı değişim dışında, gereksiz kimi durumlardan doğduğunu söylemek mümkün. Bu gereksiz durumların oluşmasında, başta proje yönetimi olmak üzere, UEKAE ekibinin toplu ve bireysel hal ve tavırlarının da olumsuz katkısı oldu. Doğan sonuçlar itibarı ile bu tip olumsuz katkılarımızdan dolayı üzüntü duymaktayız ve büyüyen ve gelişen Pardus projesinin geleceğinde benzeri durumların oluşmaması için üzerimize düşeni yapmaya hazırız.
Şimdi, öncelikli hedefimiz hızla ve sağlıklı büyüyebilecek, işlevsel ve etkin, şeffaf ve katılımcı bir yönetişim altyapısına sahip bir Pardus camiası altyapısı oluşturmaktır. Bunun için de mevcut ve eski katkıcılarımızla, camia kanaat önderleri ve camiamızın daha az sesli ve fakat son derece önemli bir parçasını oluşturan kullanıcı camiası temsilcileri ile biraraya gelmek istiyoruz. Amacımız camiamızın temel tanım ve kurallarını bir kez daha gözden geçirmek ve bu kez bunu daha sistemli ve belgelendirilmiş bir şekilde yapmak olacaktır. Bu amaçla ilk Pardus Camia Zirvesi için oluşturduğumuz gündem taslağı şöyledir:
* Katkıcı tanımı
* Katkıcı alma ve yetiştirme süreci
* Pardus camiasının mevcut iyileri ve kötüleri
* Camia yönetişim modeli
* Katkıcı sözleşme taslağı
Gündemin ilk 2 maddesinde UEKAE ekibi tarafından yürütülen çalışmalar hakkında sizleri bilgilendirecek ve eleştiri ve önerilerinizi alacağız. Bu çalışmalarla ilgili belgeler önümüzdeki günlerde sizlerle paylaşılacaktır.
Gündemin 3. maddesi daha çok UEKAE ile camia ilişkilerinde işlemeyen (ve işleyen) noktaların belirlenmesi ve çözüm önerilerine yoğunlaşacaktır.
Gündemin son 2 maddesinde ise oluşturulması gereken bir dizi camia belgesi ile ilgili olarak önerilerin alınacak ve görevliler belirlenecektir.
Bu toplantıda teknik konulara ve kimi ayrıntı süreçlere çok fazla girilmeyecek olup, yakın gelecekte düzenlenecek bir dizi toplantıda, başta Pardus 2011 olmak üzere, bu konular da ele alınacaktır.
8 Ağustos 2010 Pazar günü İstanbul’da düzenlenecek olan toplantı ile ilgili ayrıntılı yer, zaman ve ulaşım bilgileri önümüzdeki günlerde size ulaştırılacaktır. Sizden ricamız, 4 Ağustos 2010 Çarşamba günü saat 12:00′den geç olmamak üzere toplantıya katılıp katılmayacağınızı bize iletmenizdir.
Daha sağlıklı ve güçlü bir Pardus camiası oluşturmak için şimdiye kadar vermiş olduğunuz ve bundan sonra vereceğiniz katkılar için teşekkürlerimi sunarım.
–
Erkan Tekman
TÜBİTAK UEKAE
Proje Yöneticisi ::: Pardus
::: Özgürlük İçin… :::
www.pardus.org.tr
30 July 2010 @ 11:47 AM
July 28, 2010
Sevgili Bahadır Kandemir, bir süredir gayet arsızca “blog yazın eyyy Linux taifesiii” şeklinde çemkirdiğinden, onu utandırmak için bu yazıyı kaleme almaya karar verdim. Sanırım bir sürü hayırlı gelişmenin ve güzel yazının da habercisi olacak bu yazı :)…
Yaklaşık iki yıldır soluksuz ve dinlenmesiz bir şekilde devam eden topluluk yöneticisi görevime bir-iki hafta ara vermeye ve tatile gitmeye karar verdim. Ama Pardus’tan uzak kalmanın mümkün var mı? Pazartesi günü üzerimdeki “İçinde Pardus Var” t-shirt’üm, Pardus’a hevesli iki genç kızın yanıma gelmesiyle sonuçlandı. Hanım da yok yanımda, allah kahretsin!
Neyse, “karda yürürüm izimi belli etmem” hesabı, eyleme giriştim. Kendimi kızlara “genç kızların sevgilisi” Erkan Tekman olarak tanıttım. “Erkan ve manitaları” şeklinde mutlu mesut yaşıyoruz burada.
Erkan’ın adı çıkmış dokuza, inmez sekize zaten… Yarın laf çıksa “Erkan Tekman bilgisayar mühendisi genç kızları kandırıyor, onların saf ve temiz duygularıyla oynuyor” diye, bunun inananı bol olacağından, benim burada karnım bile ağrımaz!
(…)
Bugün, Bozcaada’dan Çanakkale’ye geçtim ve sevgili Necdet Yücel ve Mete Bilgin ile gizli bir sabah kahvaltısı organize ettik.
Aslında bu toplantıların gizli bir ajandası var. “Derin Pardus“a alternatif bir yapılanma olarak kurulan ve toplantılarını tatil beldelerinde düzenlediğimiz “Serin Pardus“, herkesi itinayla çekiştiriyor, masada olmayan herkesin arkasından sırayla bok atıyor. İşin tek kötü yanı, masada iki kişi kalıncaya kadar, sürekli don lastiği gibi uzayan bir gerilim yaşamanız.
“Ulan şimdi kalkarsam arkamdan konuşacaklar” gerilimi, gün boyunca sürüyor. Günün sonuna doğru allahtan Mete dayanamayıp da masadan kalktı da, Necdet Hoca ile onu çekiştirmeye başladık. Tek dersten çakmış sıpa! Hem de “mimari” dersinden! 64 bit mimari kimlere kalmış, yarabbi…
Necdet Hoca “Gözüm tutmamıştı zaten sıpayı, şimdiki aklım olsa kesin bırakırdım” diyor.
Bu arada nedensiz bir şekilde, Onur KÜÇÜK‘e, Renan ÇAKIRERK‘e ve İşbaran‘a da diş biliyoruz fena halde. Necdet Hoca bir hırsla “Kıstıralım oğlum şunları bir kuytuda ve eşek sudan gelinceye kadar dövelim…” diyor ama sonra cüsselerini aklımıza getirince bu projeden vazgeçiyoruz. Bizi fena harcayabileceklerini düşününce, “aslında o kadar da fena çocuklar” olmadıklarına kanaat getiriyoruz.
Sonrasında Mehmet Emre ATASEVER ve Eren TÜRKAY gibi “ekonomik boy” arkadaşları gözümüze kestirip, hain planlar yapmaya devam ediyoruz…
(…)
Son tartışmalardan sonra, dışarıya böyle bir görüntü verdiğimizin farkındayım.
Şaka bir yana, Pardus geliştiricileri kendi aralarında e-posta listesinde çok sert bir şekilde tartışsa da, birbirimizi ne kadar çok sevdiğimizi anlıyoruz.
“Hani” diyoruz, “Tekman da olsa masada…” diyoruz. Koray ve Doruk’un çok sağlam birer meze sever olduğu düşüyor aklıma. Gürer’in muhteşem bir rakı sofrası arkadaşı olduğunu; Meren’in eser miktarda alkolle sarhoş, Gökmen Göksel’in ise içmeden sarhoş olabilmesini anımsıyorum.
Birbirimize Pardus ekibinin komik hikayelerini, İsmail’e yaptığımız eşek şakalarını, “sözümona avukat olan” Akın’ın apartmanındaki asansörün programını değiştirerek hep yedinci katta durmasını sağlamasını falan anlatıp, saatlerce gülüyoruz. Bütün yemek boyunca, hep iyi şeylerden bahsediyoruz.
Ulan! Birbirimizi fena halde özlüyoruz galiba!
Sonra bir anda, birbirimize ne kadar benzediğimizi ve ne kadar az kişi olduğumuzu anlıyoruz…
Biz işte böyle bir ekibiz…
28 July 2010 @ 03:54 PM
July 27, 2010
2500‘den fazla özgür yazılımı bir araya getirerek oluşturuyoruz Pardus’u. Bu, binlerce geliştirici demek. Binlerce insan, hepsi birbirinden farklı. Kullandıkları programlama dilleri, yöntemler, kütüphaneler, stiller de öyle. Bu farklı parçaları düzgün ve çalışır bir şekilde bir araya getirmekten sorumlu biz geliştiriciler için zorlu engeller bunlar. Bir şekilde aşıyoruz bu engelleri; bazen kendi çözümlerimizle geliyoruz, bazen yazılımın geliştiricisine havale ediyoruz.
Bütün bu işleri yaparken onlarca parçaya bölünüyoruz; birkaç satır kod yazarak çözülecek bir iş için hata takip sisteminde, e-posta listelerinde, (bazen aşina olmadığımız dillerde yazılmış) kaynak kodlarda cirit atıyoruz; kendi çalışma ortamımızda ve test sistemlerimizde tekrarlayamadığımız ancak var olduğundan emin olduğumuz hataları üretmek için saatlerimizi harcıyoruz (tekrarladıktan sonra çocuklar gibi seviniyoruz); istikrarlı ve başarılı bir şekilde olmasa da yaptıklarımızı yazıyor, anlatıyor, o da olmazsa “twitliyoruz”. Soran olursa “her işi yapıyoruz”.
Geliştirici dünyası dönmeye/duraklamaya devam ederken, fark ettiğiniz üzere, hata yapıyor ya da başkalarının yaptığı hataları çözmekte problem yaşıyoruz. Kendi yaptığımız hataları azaltmaya, başkalarının yaptığı hataları çabuk düzeltmeye çalışsak da; her zaman başarılı olamıyoruz. Bu yazıyı yazmaya başlarken açık olan 1419 hata gibi, hiçbir zaman sıfıra düşmeyeceğini bildiğimiz bir kusur listesini kısaltmak ya da en kötü ihtimalle uzamasını engellemek için çaba harcıyoruz.
Birbirimize ara sıra Superman, Pardusman, aslan, kaplan diyoruz ama aslında yazılım geliştirme ve işletim sistemi dağıtımı oluşturma konusunda tecrübe sahibi ve bu işi yapacak zamana/enerjiye/kaynağa sahip GNU/Linux kullanıcıları olarak sizinle aynı yerde duruyoruz. Bu yüzden (farkında olmadan) sizin de bizimle aynı dili konuşmanızı istiyor, “dmes ve lspci çıktısını ver” dediğimizde anlamanızı bekliyoruz, “/proc dedim, /sys demedim” diye azarlıyoruz. Biliyoruz, arada yazılımsal olmayan hatalar da yapıyoruz.
Bu bir gerçek, yakın zamanda hata sayısını dörtte üçüne bile indiremeyeceğiz, ancak hata düzeltme süreci hep birlikte daha az acılı hale getirebiliriz. Önerileri dikkatli takip ederek, sorulanları mümkün olduğunca detaylı şekilde cevaplayarak, bir şeyler anlaşılmadığında soru sormaktan çekinmeyerek (“lspci de ne kardeşim?” gibi), her zaman (karşılıklı) sakin olarak ve -en önemlisi- sabırla bekleyerek, bazen sadece bekleyerek bunu sağlayabiliriz. Farklı bir iş yapıyoruz; siz diye birşey yok aslında, biz varız, ve biz kendimiz için çalışıyoruz. En sık karşılaştığımız mekan olan http://hata.pardus.org.tr‘de daha uygun şartlarda bir araya gelmek istiyoruz.
27 July 2010 @ 11:31 AM
July 25, 2010
Özgürlükİçin Tema bölümüne girip bakıyorum ara sıra, KDE’nin ne kadar fazla özelleştirilebilir olduğunu bilsem de, beni şaşırtan masaüstü tercihleri ile karşılaşabiliyorum. Bazılarının tamamını, bazılarının parçalarını kendi bilgisayarlarıma uygulamak istiyorum; ancak bunu yaparken sistem ayarları uygulamasındaki onlarca seçenek arasında kaybolmak, sağdan soldan duvarkağıdı, yazıtipi, simge seti indirmek istemiyorum.
Tembel adam yaratıcı olurmuş derler ya, benimki de aynı durum. Daha ismini koyamadım (önerilere açığım), yeni projem çok az arkadaşıma bahsettiğim ancak fırsat bulup yazmaya başlayamadığım masaüstü ayarları paylaşım uygulaması. Birkaç tıklama ile, kendi masaüstü ayarlarınızı tek bir paket haline getirip istediğiniz kişilerle paylaşabilmeniz için. Aktarılacak masaüstü ayarlarının listesi şimdilik kısa, yorumlarınızla şekilleneceğini umuyorum. Sıralama, kolaydan zora doğru:
- Yazıtipleri
- Simgeler
- Duvarkağıdı
- Renk temaları
- Masaüstü tipi (plasma taşıyıcı, dizin görünümü, ara&çalıştır, …)
- Plasma temaları ve plasmoid ayarları
Pardus 2011 için verilmiş bir söz değil bu, sadece uygulanması zor olmayacağını düşündüğüm bir fikir. İsim, özellik, uygulamanın arayüz tasarımı ve davranışı konularında önerilere açığım. Bileşenler belirgin hale gelip ihtiyaçlar ortaya çıktığında, bu bileşenleri kodlayacak geliştiricileri (ya da geliştirici adaylarını) yardıma beklerim.
Not 1: Yukarıdaki enfes duvarkağıdı, masaüstü sihirbazı dediğim Kerim Aydın‘dan. Projeyi tamamlamak ve onun gibi masaüstü sihirbazlarının temalarını zahmetsizce bilgisayarımda kullanmak için sabırsızlanıyorum.
Not 2: Ahenk yazılarımdan sıkılanlar için teknik mambo-jambo içermeyen bir yazı yazdığım için de pek menunum :)
25 July 2010 @ 03:11 PM
July 24, 2010
Yüzlerce sunucunun bağlı olduğu bir ağ var elimizde, her biri merkezi bir sunucuya bağlanarak kendilerine ait politikaları alıyor ve uyguluyor. Adını duymaktan sıkıldığınız uzaktan yönetim sistemi Ahenk ile, elbette. 10′ar dakika ara basit bir sorgulama, uzun olmayan bir cevap. Tek noktadan nadir değiştirilen, yüzlerce noktadan sıkça okunan politikalar. Tam LDAP‘lık bir senaryo: Yazma nadir, okuma sık.
Politikaların daha çabuk uygulanması gerekiyor bazen, 10 dakika beklememek. Elbette bunu, sorgulama aralığını 30 saniyeye çekmeden, düzgün bir şekilde yapmak. Bir şekilde, “anında uygulama” sağlanması, çoğu zaman da yapılan işlemin sonucunun anlık olarak öğrenilmesi gerekiyor. Problem, işte burada başlıyor.
İstemcilerin belirli aralıklarla “çekme” yapması yerine, sunucunun bir değişiklik varsa “itme” yapması gerektiği durumlarda, LDAP’ın yanında çalışacak bir protokol ihtiyacı ortaya çıkıyor. Yerine değil, yanında; çünkü politikaların tutulması için “hafif” bir veritabanı çözümü gerekiyor ve LDAP bunu başarılı bir şekilde sağlıyor. Mevcut LDAP sunucularının yedekleme ve çoğaltma konusunda hazır çözümlerle gelmesi de ayrı bir avantaj, vazgeçilecek özellikler değil bunlar.
“İtme” kısmına geri dönersek, bu konuda aklıma ilk gelen çözüm, XMPP (Jabber) kullanmak ve “anında mesajlaşma” işini zahmetsizce halletmek oluyor. “Hata ayıklama işini Kopete ile yaparım” düşünceleri beliriyor tabi ister istemez, sonra çevreden “slm, asl?” yazınca işlemci bilgilerini versin esprileri yapılıyor :)
XMPP, LDAP kadar olmasa da eski bir standart. Açık, ücretsiz; kullanımı, geliştirmesi, genişletilmesi kolay. Birden fazla sunucu/istemci/kütüphane mevcut, kararlılığı kanıtlanmış. Alternatif arama gereği hissettirmiyor. Özgür, çalışıyor, işimi görüyor, daha ne isterim? Düzgün bir XMPP kütüphanesi, saç-baş yoldurmayacak bir sunucu; hepsi var, hatta hepsi (Twisted ve EJabberd) Pardus depolarında var. Noktaları birleştirmek kalıyor geriye, eğlenceli kısım burası işte.
Dökümanın yetmediği yerlerde kaynak kodları açılıyor, “döküman kötü ama kodlar tertemiz” deniyor, birkaç deneme sonrasında Jabber sohbet botu geliştiriliyor, sonra da aynı mesajlaşma tekniği Ahenk prototipine ekleniyor, sonra Kopete ile sistem yönetimi oyunu oynanıyor: “selam, nerden?”
24 July 2010 @ 09:21 PM
Hemen hemen herkes tatilde demiştim. TÜBİTAK’ın toplu izin döneminin ilk haftası geride kaldı, havalandırma ve klima sistemlerini bakıma alınması yüzünden içerde mi kalsak, dışarı mı çıksak bilemediğimiz bunaltıcı bir haftada, ilk dönem stajına geç başlayan iki stajyer aramızdan ayrıldı, iki geliştirici de kalan işlerinin tamamlayarak tatile çıktı.
Geliştirici sayısının azlığından, depolara (tahminen) pek fazla commit yapılmayacak bu hafta. Ancak her toplu izin döneminde olduğu gibi, güvenlik açıkları ve kritik hatalar için hazırda bekleniyor olacak. Ofisteki sessizlikten istifade eden geliştiriciler sürpriz projelerle ortaya çıkabilir, bazı geliştiricilerin de gizli ajandasındaki önemli tarihler, tam da bu toplu iznin ortasına denk gelebilir…
Benim proje artık sürpriz değil [1] [2], Ahenk ile ilgili kod ve belgeler bu hafta depoya girmeye başlayacak. Ardından da proje ajandası şekillenecek. Ara verip farklı projelerle uğraşmam gereken zamanlarda Pardus 2011′deki yapılandırma altyapısı (COMAR) değişiklikleri ve danışmanı olduğum GSoC projesi ile iligileneceğim. Çok az arkadaşıma bahsettiğim ve Özgürlükİçin – Temalar bölümünde “reyting patlaması” yaratacağını düşündüğüm çok gizli proje ile ilgili de bir şeyler karalarım belki :)
Gidenlere iyi tatiller, kalanların acılarını paylaşıyorum, selamlar…
24 July 2010 @ 03:33 PM
July 23, 2010
Milli Savunma Bakanlığı’ndaki bir ihtiyaç için geliştirilen Ahenk 1.0‘da (Pardus’un uzaktan yönetim sistemi), politikaların LDAP üzerinde tutulduğu ve istemcilerin belirli aralıklarla bu politikaları aldığı ve uyguladığı bir yapı mevcut. Olabildiğince basit ve sade. Büyük resme bakıldığında, yapılan iş aşağıdaki metnin veritabanına yazılması, okunması ve bu bilgiler ile işlem yapılması:
dn: cn=server1, dc=pardus, dc=org, dc=tr
pisiRepository: http://192.168.1.1/packages/2009/pisi-index.xml.bz2
pisiUpdateInterval: 3600
pisiUpdateType: security
comarUserSource: ldap
comarUserURL: ldap://192.168.1.1/dc=pardus,dc=org,dc=tr
...
Yönetim arabiriminde yapılan iş, bir arabirim kullanarak yukarıdaki politika metnini oluşturmak ve LDAP’a kayıt etmek. Nispeten kolay bir iş, ve bir sonraki Ahenk blogumun konusu :). Sisteme dahil köle bilgisayarlarda çalışacak Ajan uygulaması ise “sihrin” gerçekleştiği, ve benim en çok sevdiğim Ahenk bileşeni.
Ajan’ın yapısı aşağıdaki gibi. XMPP ile ilgili kısım 2.0 ile geldi:
LDAP istemcisi belirli aralıklarla, “bu bilgisayara ait politika var mı?” diye soruyor: Yaptığı şey “ldapsearch” komutu çalıştırmaktan çok farklı değil. Politika bulursa kuyruğa atıyor, ve kuyruktaki politikalar ilgili Ajan modüllerine gönderilerek işleniyor. Misal, PiSi ile ilgili politika metinleri -eğer kuruluysa- yazılım güncellemelerinden sorumlu modülde (bildiğiniz Python modülü) işleniyor.
XMPP istemcisi ise politikaların “anında” uygulanması ya da bilgisayarlara komut gönderilmesi gerektiğinde kullanılacak “opsiyonel” iletişim kanalı.
23 July 2010 @ 01:56 PM
July 19, 2010
TÜBİTAK MAM Kampüsü bomboş, 5000+ çalışanın %90′ı 2 haftalık toplu (bazı işkoliklere göre “zorunlu”) izinde. Ben dahil birçok Pardus geliştiricisi ise, UEKAE binasındaki ofiste mesaide. Proje çalışanlarının, farklı zamanlarda izne çıkmasının çalışmaları olumsuz yönde etkilemesi sebebiyle böyle bir karar alınmış MAM kampüsünde. Tatile çıkanlar alınan bu karardan memnun, geride kalanlar ise ıssız koridorlarda vahşi batı kasabalarında yuvarlanan çalılar gibiler: Yalnız ve mutsuz.
Schindler’s List OST dinlerken okursanız halimizi biraz olsun anlayabilirsiniz :)
19 July 2010 @ 05:00 AM
July 18, 2010
Adım adım neler yaptık anlatacağım demiştim, blog yazma konusunda istikrarsız olduğumu bildiğinizden inanmamışsınızdır tahminen. Yarı dönem değerlendirme formuna birkaç paragraf yazarken bile araya türlü türlü aktiviteler sokarak “yazma” işinden kaytaran ben, artık “macroblogger” olduğuma göre oturum adam gibi bir değerlendirme yazısı yazmak zorunda oluyorum değil mi? Evet, buyrun:
GSoC koordinatörü (yine) Renan hızlı, temiz ve sessiz bir iş çıkararak 3. kez yaz stajına kabul edilmemizi sağladı. Biz onu kod yazıyor ya da birileriyle yazışıyor sanıyorduk, meğer teklif metni yazıyormuş gizli gizli. Yaz döneminin büyük bir kısmında ofis dışında olmayı planlayan (ilk aylarda iş, sonraki aylarda tatil için) bir geliştirici olarak bu sene de GSoC danışmanlığı yapmayacağını düşünen ve yanılan bendeniz, 2. kez danışman olarak buldum kendimi. Danışman olduğum Jain Basil‘in ilgisi ve proje gözden geçirmenin en az kod yazmak kadar eğlenceli gelmeye başlaması, 2 aya yakın zamanı keyifli geçirmemi sağladı.
Proje, ev dizinindeki (şimdilik sadece KDE) ayar dosyalarındaki değişiklikleri takip etme, değişiklikleri yedekleyebilme, paylaşabilme ve geri alabilme için gerekli altyapının hazırlanmasını ve arayüzlerin yazılmasını kapsıyor. Detaylar için Jain Basil’in günlüğüne göz atabilirsiniz. “Bir ayar değiştirdim ama neredeydi unuttum, nereden geri alıyorduk bunu?” diyenler için kurtarıcı olacağından eminim.
Jain başvuruda bulunmadan, kodlamaya başlamadan önce yapılması gereken herşeyi yapmış, bunu başvuru mektubunda göstermiş ve başvuruları değerlendiren geliştiricilerin “E sadece kod yazmak kalmış, seçelim bu arkadaşı” demesini sağlamıştı. Aktif geliştirme süreci boyunca Jain iyi bir geliştirici olduğunu gösterdi, takvime uydu ve ilk dönemde geçer notu aldı.
SVN kayıtlarını ve Jain’in İngilizce günlüğünü takip etmeyenler için yaptıkları hakkında bir özet şöyle:
- ~/.kde dizinini kullarak bir yerel GIT deposu oluşturan bir servis yazdı.
- Dizindeki her değişikliği KDirWatch ile takip etme ve değişiklikleri GIT deposuna gönderme desteği ekledi.
- Değişiklikleri görme ve geri almak için gerekli kitaplık metodlarını yazdı.
- 2. dönem geliştireceği arayüz için örnek bir tasarımı depoya gönderdi.
SVN kayıtlarına, kodlara, geliştirici günlüğüne ya da yukarıdaki özete bakarak “ne var bunda, ben de yaparım bunu” diyenlerdenseniz, sizi bir sonraki sene yapılacak olan yaz stajına bekleriz. Proje geliştirmek zor değil. Enerjiniz, hevesiniz, zamanınız ve bu işi yapmak için tutkunuz varsa bu ekipte size de yer var. Selamlar.
18 July 2010 @ 08:24 AM
