[Gelistirici] [RFC] Kullanıcı/Grup Yönetimi

[S.Çağlar Onur]

Selamlar;

Malum elimizde /etc/passwd ve /etc/group isminde iki harika dosya var. Bu 
paketler baselayout paketi ile geliyor ve baselayout paketi upgrade'ler 
sırasında yanında taşıdığı dosyaları sisteme YAZMIYOR.

Yazmamasının en büyük nedeni kullanıcının kendi kendine eklediği 
kullanıcı/grupları kaybetmemek.

Bu konu beta öncesi hatta mümkünse bu gece bir sonuca varmalı, stable'daki 
udev/hal/PolicyKit ve bunlara bağlı olarak müdürün yeni release'ler yapması 
için gerekiyorlar. PolicyKit sisteme bir kullanıcı ve grup eklemek zorunda.

Bunu nasıl yapacağımızı konuşmak için Gürer'le bir seri kopete görüşmesi 
yaptık, hızlıca seçenekleri özetleyeyim.

* İlk aklımıza gelen çözüm baselayout içindeki tüm gereksiz kullanıcı/grupları 
silmek ve bu kullanıcılara ihtiyaç duyan paketlerin postInstall betiklerinde 
sisteme ekletmek.

Bu noktada ilk sorun bu seçimin paket geliştiricisine kalması oysa bu noktada 
dağıtımın bir duruşu olmalı. Bunun üzerine statik bir listeyi paket 
geliştirme dökümanına koyalım dedik. Fakat madem static bir liste koyacağız 
neden onu kullanmıyoruz diyerek bu çözümden vazgeçtik.

* İkinci aklımıza gelen baselayout paketinin passwd ve group dosyalarını 
postInstall'unda bir şekilde sisteme _merge_ etmesiydi. Fakat bununda 
gereksiz komplek bir yapı gerektirdiğini düşündük. Ayrıca kullanıcı eklemek 
işi ÇOMAR'ın olmalıydı postInstall betiğini her ne kadar ÇOMAR çalıştırsada 
provide ettiği yöntemi kullanmış olmuyorduk. Bu da böyle yattı.

* Son çözümümüz ise baselayot paketinin şu anda olduğu gibi svn içinde 
kalması, paket geliştirisinin uid/gid ihtiyacı durumunda geliştirici e-posta 
listesine mail atması uygun bulununca bu uid/gid'in svn'de baselayout içine 
eklenmesi esasına dayanıyor yani şimdiki yönteme.

Bir farkla, baselayout paketi temizlenecek ve /etc/passwd ile /etc/group 
dosyası min. UNIX uyumluluğu için sadece gerekli kullanıcıları tutacak. 
Örneğin;

root:...
whell:...
users:...

Buraya yeni kullanıcı/grup eklenmesi gerektiğinde baselayout paketinin 
postInstall betiğine ÇOMAR'ın provide ettiği addUser methodu ile bu kullanıcı 
eklenecek. Örneğin;

comar.addUser(uid="123", name="polkit",shell="/bin/false")

Bu sayede;

* svn'deki baselayout paketi gereksiz kullanıcılardan (mesela qmail, nuts, gdm 
gibi) kurtulacak.

* Baselayout paketi upgrade sırasında merge etmekle falan uğraşmayacak 
postInstall'u işleten ÇOMAR olmayan kullanıcıları ekleyecek ve gerçekten 
ÇOMAR kullanmış olacağız

* Eski bir baselayout sürümünden bile upgrade edilse aradaki tüm diff 
postInstall betiğinde olduğu için upgrade gerçekten upgrade olacak.

Bu noktada seçimimiz bu seçenekte birleşti gibi. Bilgi olması açısından diğer 
dağıtımlar bunu nasıl yapıyor diye bir bilgi;

* Debian static liste tutuyor, merge işini kullanıcıya bırakıyor
* Gentoo static liste tutuyor, merge işini kullanıcıya bırakıyor
* SuSE ve Fedora RPM specleri içinde bildiğiniz adduser ile kullanıcı/grup 
ekliyorlar ama buna bir yöntem belirlememişler sorumluluk paket 
geliştiricisinde

Bu noktada ortada kalan tek sorun derlenme zamanında çıkıyor. Örneğin hal yada 
PolicyKit paket derlenmeden önce kullanılacak kullanıcı/grubun sistemde 
olmasını istiyor. 

Fakat ideal dünyada paket derleyecek adamın paket geliştiricisi olduğu gerçeği 
ile bu sorumluluğun zaten geliştiriciye ait olduğunu ve uid/gid gerekince 
gerekenleri kendi sistemine ekleyip, geliştirici listesine e-posta atıp bunu 
dağıtıma ekletip durumu kontrol altına almalı diye düşünüyorum. 

Aksi düşünen varsa PiSi'ye preInstall isminde bir hook eklenmesi gerektiğini 
ve ÇOMAR'ında PiSi build sürecine dahil olacağını hatırlatmak isterim. Ve bu 
durumda olan az sayıdaki paketin istisna olduğunu kabul etmeyi öneriyorum 
(daha iyi bir fikri olan yoksa)

Ve son olarak bu konuyu geçen yazdığımda kimseden ses çıkmadı, yarın akşam 9'a 
kadar gene kimseden ses çıkmazsa 3. seçeneğin kabul edildiğini varsayıp 
paketlerde gerekli değişiklikleri yapmaya başlayacağım.

Saygılar
-- 
S.Çağlar Onur <caglar at pardus.org.tr>
http://cekirdek.pardus.org.tr/~caglar/

Linux is like living in a teepee. No Windows, no Gates and an Apache in house!
-------------- sonraki bölüm --------------
A non-text attachment was scrubbed...
Name: kullanılamıyor
Type: application/pgp-signature
Size: 189 bytes
Desc: kullanılamıyor
URL: <http://liste.pardus.org.tr/gelistirici/attachments/20060828/18965a01/attachment-0002.pgp>