16
Tem

Bakımını yaptığım PiSi paketlerinin büyük kısmını başka geliştiricilere vermeye başladım geçen hafta. Yakında da (umarım) geçici olarak yürüttüğüm sistem yöneticiliği işini tam zamanlı olarak işe başlayacak sistem yöneticimize teslim edeceğim. Bu iş devirlerinin sebebi “ayrılık” değil, yanlış anlaşılmasın.

Bir seneye yakın zamandır birbirinden ayrı alanlarda iş yapıyor/takip ediyor olmam, her işe yeterince vakti ayıramamama ve işler arası geçiş yapaken kaybettiğim konsantrasyonum iş kalitesinin düşmesine sebep oluyordu. Çok sevdiğim yazılım geliştirme işine daha fazla vakit ayırmak, “sen ne zaman kod yazıyorsun?” diye soranlara “vakit mi var” cevabını vermemek ve ait olduğum sahalara geri dönmek için “mağdurum, şu işlerden bi kurtulsam” demem gerekiyordu; sağolsun arkadaşlar, ben geliştirici listesinde feryat etmeden üzerimdeki yükü aldılar. Bıraktığım PiSi paketlerine ve yakında bırakacağım sunucularımıza benden çok daha iyi bakacaklarına eminim. Paketlerimi ve sunucuları özleyeceğim, ama fazla değil.

Şimdi ne yapacaksın, günde 8 saat ne işle uğraşacaksınız diye sorar mısınız bilmem ama ben yine de cevaplayacağım. COMAR ve arkadaşlarının (konfigürasyon alyapısı, yönetim arabirimlerinin bir kısmı) ve Pardus Kurumsal’ın uzaktan yönetim sistemi Ahenk ve Ahenk’in yönetim arabirimi Lider’in geliştirilmesiyle uğraşacağım. UEKAE çalışanlarının tamamına yakınının ve Pardus ekibinin büyük kısmının tatile çıkacağı önümüzdeki iki hafta içinde ofiste kalıp özlediğim projelerle hasret gidermeyi ve 2 Ağustos ile başlayan hafta Ahenk’in Pardus Kurumsal 2′de kullanılabilir bir ön izleme sürümünü yayınlamayı planlıyorum. “Ahenk Mimarisi” ve “Ahenk Eklentileri Yazımı” belgelerini de bu ön izleme sürümüyle beraber yayınlayacağım. (Büyük laf ettik, o sürüm çıkacak).

26
Ara

ÇOMAR ve PiSi kardeş, sanırım herkes biliyor bunu. Biri paketleri kuruyor, güncelliyor; diğeri kurulu paketlerin yapılandırma işlerini üstleniyor. Peki, ÇOMAR ve PiSi beraber nasıl çalışıyor? Paket yapıyorsanız ya da yapmak istiyorsanız, eninde sonunda "ÇOMAR betiği yaz" diyecektir birileri size, ve elbet bu soruyu soracaksınız. PiSi paketi yapmak çocuk oyuncağı olduğundan, diğer paketlerdeki ÇOMAR betiklerini alıp ufak değişikliklerle kendi PiSi paketlerinizde kullanabildiğinizden cevabını bilmemeniz ya da öğrenmemeniz muhtemelen uzunca bir süre etkilemez sizi, ama paket yapım işinizi kolaylaştırabilir de.

PiSi kaynak paketlerinde (pspec.xml), ikili paketin (.pisi uzantılı) sağladığı ÇOMAR görevlerinin ve her görevin hangi Python dosyası tarafından sağlandığının listesi bulunur:

    <Package>
        <Name>python</Name>
        <Files>
            ...
        </Files>
        <Provides>
            <COMAR script="package.py">System.Package</COMAR>
            <COMAR script="packhandler.py">System.PackageHandler</COMAR>
        </Provides>
    </Package>

Betikler, kaynak paket ile aynı dizindeki comar/ dizininde (hiç akla gelmez, değil mi?) bulunur. System.Package, System.PackageHandler ve System.Service dışındaki görevler PiSi ile ilgili olmadığından başka bir yazının konusu, bunlar muhtemelen Sistem Ayarları ekranındaki uygulamalardan birinin ihtiyaç duyduğu altyapıyı sağlar.

System.Package görevini yerine getiren betik, paket kurulduktan sonra, kaldırılmadan önce ve kaldırıldıktan sonra çalıştırılacak metodları içerir. Betik içinde, metodlardan herhangi birinin tanımlı olması zorunlu değildir. Dosya haklarını ve sahiplerini değiştirecekseniz postInstall() metodu, paket kaldırılmadan önce ayar dosyalarında değişiklik yapacaksanız (mod_php'yi kaldırmadan önce Apache ayarlarını değiştirmek gibi) preRemove() metodu, paket kaldırıldıktan sonra artık dosyaları temizleyecekseniz postRemove() metodu kodlarınızı yazmanız gereken yer.

import re

def postInstall(fromVersion, fromRelease, toVersion, toRelease):
    module_enable('PHP5')

def preRemove():
    module_disable('PHP5')

def module_enable(mod):
    ...

def module_disable(mod):
    ...

System.PackageHandler'da durum biraz daha farklı. Bu betikler, betiğin çıktığı paket kurulması/kaldırılması sırasında değil, sisteme herhangi bir paket kurulduğunda ya da kaldırıldığında çalıştırılıyor. Çekirdek modülleri ve Python kütüphaneleri gibi, paket deposunda onlarcası bulunan ve hepsine birer System.Package betiği yazsanız üç aşağı beş yukarı aynı betiğin ortaya çıkacağı paketlerde, paketçinin yükünü ve kod tekrarını azaltmak için kullanılıyorlar.

Django paketini kurduğunuzda, sistemdeki her System.PackageHandler betiği çalıştırılır ve betik içindeki metodlara, pakete ait iki XML dosyası parametre olarak verilir: metadata.xml ve files.xml. Bu dosyalardan ilki, pakete ait kimlik bilgilerinin barındırır, ikincisi ise, paketten çıkan her dosyayı ve dosyalara ait özet bilgileri. ÇOMAR betikleri, files.xml dosyasında, kendilerini ilgilendiren bir dosya varsa (mesela, Python'a ait SPH betiği, ikili paket .py dosyası içeriyorsa) ya da metadata.xml'de ilgili oldukları bir veri/etiket bulunuyorsa işlem yaparlar.

Python'a ait SPH betiği aşağıda, yeni başlayanlar için ağır bir örnek ancak örnek olsun diye yazacağım basit bir betik gerçekçi olmazdı.

import piksemel
import sys
import os

pythonPath = "/usr/lib/python%d.%d" % sys.version_info[:2]

def byteCompile(filepath):
    doc = piksemel.parse(filepath)
    paths = []
    for item in doc.tags("File"):
        path = item.getTagData("Path")
        if path.endswith(".py"):
            paths.append("/"+path)

    if paths:
        os.system("/usr/bin/python %s/py_compile.py %s" % (pythonPath, " ".join(paths)))

def removeByteCompiled(filepath):
    doc = piksemel.parse(filepath)
    for item in doc.tags("File"):
        path = item.getTagData("Path")
        if path.endswith(".py"):
            try:
                # Remove .pyc and .pyo
                os.unlink("/%sc" % path)
                os.unlink("/%so" % path)
            except OSError:
                pass

def setupPackage(metapath, filepath):
    byteCompile(filepath)

def postCleanupPackage(metapath, filepath):
    removeByteCompiled(filepath)

Bu gecelik bu kadar...

22
Ara

ÇOMAR (COnfiguration MAnageR - Yapılandırma Yöneticisi), sıradan bir işi yapmak için Google'da saatler geçirmeyin, anlamadığınız bir formatta yazılmış ayar dosyalarını kurcalamayın ve bu sırada sisteminizi uçurmayın diye oluşturulmuş bir ayar yönetim sistemi. PiSi'nin kardeşi olur kendisi; biri uygulamaları kurar, diğeri yapılandırır - ya da en azından yapılandırma işi için kolay kullanılabilir bir ortam yaratır.

Misal, ağ bağlantısı kurmak istiyorsunuz. Bunu farklı yollarla, farklı yöntemlerle yapabilirsiniz. Ethernet, wireless, modem ve 3G kullanabilirsiniz. Ethernet ile yapacaksanız iş nispeten kolaydır; DHCP istemcisini açar, IP almaya çalışırsınız. makul bir süre sonra IP alamazsanız, ağda bir sorun olduğunu anlarsınız; ya da IP alıp hayatınıza devam edersiniz. Kablosuzda durum biraz daha karışıktır. DHCP ile IP almadan önce -varsa- kimlik doğrulama yaparsınız, doğrulama şekline göre farklı ayarlar yapar, farklı uygulamalar çalıştırırsınız. Her işi konsoldan yapmanızı gerektiren sadist bir işletim sistemi kullanmıyorsanız, genelde bu iş için bir araç kullanırsınız. İşlem yapmadan önce sizden yetkili kullanıcı parolasını ister, ilgili dosyaları değiştirir, gerekli programları çalıştırır.

Çoğu Linux dağımı bu işi böyle yapar. Belirli bir görevi yerine getirmek için oluşturulmuş -çoğu dağıtıma özgü- yönetim arabirimleri, kendi yöntemleri ile ayarları değiştirir, komut çalıştırır ve sonuçta kullanıcının isteğini yerine getirir. Sorun ise, aynı ayar dosyaları ya da uygulamalar farklı yönetim araçları ve bu araçlardan bilgi almak isteyen diğer uygulamalar tarafından kullanılmak istendiğinde ve kullanıcılara bir işi yapabilmeleri için yetkili kullanıcı (root) hesabı parolası verilmesi gerektiğinde ortaya çıkar.

ÇOMAR, burada devreye girer, sade ve basit bir çözüm ile. Pardus'ta sık yapılan işler için görev modelleri tanımlanır ve bu görevleri üstlenecek uygulamaların birbirlerinin ayağına basmadan, altyapıdaki değişikliklerden (değişen sürümler, kullanılan yeni teknolojiler, ...) çalışmalarını sağlayacak ve gerektiğinde yetki kontrolü yapabilen bir yönetim katmanı oluşturulur.

  • Ağ bağlantısı yönetimi
    • Aygıtları listele
    • Aygıt üzerinde bir bağlantı oluştur
    • Adres ayarları yap
    • Bağlantıyı aç
    • Bağlantı bilgilerini göster
    • ...
  • Servis yönetimi
    • Servisleri listele
    • Servisi aç
    • Servis bilgilerini al
    • ...
  • ...

Görev modelleri yukarıda görüldüğü gibi olabildiğince sadedir, uygulamalardan ve teknolojilerden bağımsızdır. Alt görevleri yerine getirecek kodlar ise görevi yerine getirecek uygulamanın PiSi paketi ile beraber gelen Python betikleridir (bunlara ÇOMAR betikleri diyoruz) ve bu betikler içinde modelde tanımlı her alt görevi yerine getiren bir fonksiyon bulunmaktadır. Her uygulama, aynı görevi farklı şekillerde yerine getirdiğinden, her uygulamanın ÇOMAR betiği farklıdır. Betikler, uygulamaların PiSi paketlerini hazırlayan -teorik olarak, Pardus geliştiricileri arasında, o uygulamayı en iyi bilen- geliştiriciler tarafından yazıldığından, arabirimlerin keyfi yöntemlerle ayar dosyası değiştirme ya da komut çalıştırmasından daha güvenli ve düzenlidirler. Detaylı bilgi için, mevcut görev modelleri ve bu görevleri yerine getirecek ÇOMAR betiklerinin formatları incelenebilir.

Arabirimler ve ÇOMAR betikleri arasında duran ve yetki kontrolü yapan katmanda ise, yapılan iş teknik olarak karışık görünse de, aslında son derece basittir. Arabirimden alınan bir çağrı, örneğin ağ bağlantısı kurma emri; çağrıyı yapan kullanıcının o işi yapmaya yetkisi olup olmadığı kontrol edildikten sonra, ilgili uygulamanın ÇOMAR betiğine yönlendirilir ve betikte tanımlı fonksiyon çalıştırılır. Sıkıcı detaylar için, iletişim için kullanılan DBus'a (İngilizce) belgeler ve ara katman ile ilgili tasarım notları incelenebilir.

Arabirimlerin, bu ara katman ile iletişimi kolay bir şekilde yapabilmeleri için -nispeten- basit bir Python kütüphanesi bulunmaktadır:

    import comar
    link = comar.Link()
    print "Servis betiği olan uygulamalar:"
    print list(link.System.Service)

Bu Python kütüphanesi ile ilgili daha fazla örnek, COMAR API projesine ait Beni Oku dosyasında ve örnekler dizininde bulunabilir.

19
Tem

Pardus 2008′de Wicd’i yükleyip hemen ardından çalıştırdığımız zaman, bir bildirim penceresiyle karşılaşıyorduk, “Wicd servisini başlatınız!” gibisinden. Pardus 2009′da son Wicd güncellemesiyle, her Wicd servisini başlatmayı unuttuğunuzda sizden PolicyKit yardımıyla yetkilendirme için parola istenecek ve hemen ardından Wicd çalışabilecek. Tabi bu ayrıntı, son kullanıcıların çok da farkına varabilecek ve onları ilgilendirecek gibi durmasa da, bir geliştirici olarak COMAR’ı oldukça ilgi çekici bulduğumu söylemeden edemeyeceğim.

Wicd & PolicyKit on Pardus from Gökmen Görgen on Vimeo.

Bununla beraber, Wicd’e yaptığım PolicyKit yamasını ve yazdığım betiği şuradan bakabilirsiniz:
http://svn.pardus.org.tr/contrib/2009/devel/network/connection/wicd/files/