Evvela Redmine uzaktaki bir git deposunu okuyamıyor. Bu bir dezavantaj değil tabii ki, git’in yapısıyla ilgili bir mesele. Dolayısıyla Redmine’a doğrudan github’daki (ya da herhangi bir git servisi) clone adresini vermeniz mümkün değil. Redmine’ın çalıştığı makinede bir git yansısı tutarak bunu halledebilirsiniz.

Bu yazım git deposu ile Redmine’ın aynı sunucuda olduğu kurulumlar için geçerli olacak haliyle.

Evvela sorunu bir tanımlayalım. Yerelde gitolite tarafından oluşturulmuş depoyu Redmine’a eklediğinizde depo içeriğini görüntülemek istediğinizde depo içeriği yerine havanızı alıyorsunuz (404). Redmine her ne kadar dosya izinlerine ilişkin bir hata vermese bile (rails’ın production veya development logları dahil) sorunun dosya izinlerinden kaynaklandığı anlaşılıyor.

Nedeni ise gitolite belgelendirmesinde açıkça yazıyor zaten. gitolite öntanımlı umask olarak 0077 kullanıyor. Haliyle gitolite kullanıcısı hariç kimse depo içeriğine ulaşamıyor.

Bu aşamada bu sıkıntıyı gidermek için 2 yöntem bulunuyor:

1. gitolite tarafından sunulan deponun, redmine’ı çalıştıran kullanıcı tarafından yansılanması. Eğer güvenlik konusunda endişeleriniz varsa bu yöntemi kullanabilirsiniz.

2. Diğer yöntem ise benim tercih ettiğim yöntem. Disk üzerinde ikinci bir depo yansısı tutmak yerine gitolite’ın öntanımlı umask’ını 0022 yapmak.

İkinci yöntem üzerinden devam ettiğimizde yapmamız gereken işlemler oldukça basit.
Gitolite’ı kurduğunuzda (ister dağıtımınızın paket deposundan, ister gitolite’ın git deposundan) .gitolite.rc isimli dosyamızı düzeltmemiz gerekiyor. .gitolite.rc gitolite kullanıcısının ev dizininde tutuluyor. (Red Hat türevlerinde EPEL’den gitolite kurmuşsanız eğer /var/lib/gitolite dizini altında bulunuyor bu dosya)

İlgili dosyayı açıp şu değişikliği yapmanız yeni depolar için yeterli olacaktır:


$REPO_UMASK = 0022;


Yaptığımız bu değişiklik tahmin edebileceğiniz üzere daha önce oluşturduğunuz depoların izinlerine etki etmeyecektir. Burada eski depoların izinlerini değiştirmek için bir manuel bir işlem yapmamız gerekecek:


find depo_ismi.git -type d -exec chmod 755 {} \;
find depo_ismi.git -type f -exec chmod 644 {} \;
chmod a+x depo_ismi.git/hooks/*


Bu şekilde vermiş eski depoların da umask’ını 0022′ye çekmiş oluyorsunuz. Artık Redmine üzerinden depoyu ekleyebilir ve içeriğini görüntüleyebilirsiniz.

Son olarak da eğer commitlerinizin otomatik olarak Redmine’ı tetiklemesini istiyorsanız yapmanız gereken işlem basit. post-receive betiğinizin sonuna şunu ekleseniz yeterli.


curl (ya da wget) "http(s)://redmine.adresi/sys/fetch_changesets?key=redmine_depo_api_anahtarı"


Eğer custom bir SSL sertifikası kullanıyorsanız curl sertifika hakkında sızlanacaktır. Bunu aşmak için curl’e parametre olarak -k verebilirsiniz:


curl -k "https://redmine.adresi/sys/fetch_changesets?key=api_anahtarı"


API anahtarınızı Redmine -> Yönetim -> Ayarlar -> Depo kısmından oluşturabilir/öğrenebilirsiniz.

Neyse git şöyle güzeldir, git böyle güzeldir yerine başlığa değineyim doğrudan. Bir konumdaki depoyu alıp başka bir depoya (mesela github, yerel gitosis veya gitolite deponuz yahut gitorious vs.) aktarmak istiyorsanız şunları yapmanız yeterli. (Bu arada işi yapmanın farklı yöntemleri de mevcut)


git clone --bare --mirror (git|ssh)://...
git remote add depo (git|ssh)://...
git config remote.depo.mirror true


Bu işlem ile git’e kaynak ve yansıyı belirtmiş oluyorsunuz. Daha sonra depo içeriğini aktarmak için de şu komutları vermeniz yeterli olacaktır (–quiet parametresini tercihen kullanabilirsiniz):


git fetch (--quiet) origin
git push (--quiet) depo


Daha sonrasında bu işlemi otomatik gerçekleştirmek için cron kullanabilirsiniz.

Zyxel NWD 2205 de Realtek’in bu çipsetini kullanıyor. Dolayısıyla bu yazı doğrudan NWD 2205 kullanıcılarına da hitap ediyor.

2.6.18′den 3.1 sürümüne kadar olan tüm çekirdekleri destekleyen sürücüsünü Realtek’in web sitesinden indirebilirsiniz.

İndirdiğiniz dosya bir çekirdek modülünün kaynak kodu olduğu için ve bu çekirdek modülünü derlemek için öncelikle kullandığınız çekirdek için headers paketini kurmalısınız. (Mesela Pardus üzerinde kernel-headers paketi.)

Daha sonra kaynak kodu bir dizine açıp; o dizine girdikten sonra şu komutları vermeniz yeterli:


make
(root değilseniz, sudo) make install


Daha sonra modprobe 8192cu komutunu vererek kablosuz aygıtını kullanmaya başlayabilirsiniz. 3.2 serisi çekirdekte sürücü çekirdeğe dahil olduğu için bu işlemleri yapmanıza gerek bulunmuyor.

3.6 geçtiğimiz ay yayınlandı ve yeni özellikler eklendi. 3.4 sürümüne ise 3.4.7 güncellemesi geldi. 3.2 sürümünde ise sadece güvenlik güncellemesi/hata düzeltmesi yapılıyor. Her büyük sürümden farklı bir ekip sorumlu ve dinamik bir gelişim süreci sağlıyorlar. Ayrıca Koha topluluğu oldukça yardımsever. E-posta listeleri ve IRC üzerinde günün her saati sorularınıza yanıt alabiliyorsunuz.

Koha ile ilk ilgilenmeye başladığımda 3.4 sürümü yeni çıkmıştı ve Pardus kurulu bir sistemde çalıştırmam gerekiyordu. Ben de boş durmayıp Koha ve bağımlılıkları (74 adet perl kitaplığına ihtiyaç duyuyor) için Pardus paketini oluşturdum. Çevirisi üzerinde de oldukça uğraştık; zira kullandıkları pootle’a spambot dadanmış ve Türkçe dizgileri oldukça bozmuş. Güncelleyip gönderdiğimiz çeviriler ise henüz kendi çeviri sistemleri tarafından kabul edilmediği için bu şekilde yayınlıyoruz.

Netice olarak Koha 3.4 serisi için güncel Türkçe çevirisine buradan, Koha paketlerinin inşa dosyalarına ise buradan ulaşabilirsiniz. Pisi paketlerine nereden ulaşırım diyorsanız şu an için bir ikili depo hazırlama gereği duymadım, LKD katkı deposuna koyarım diye. Ancak bazı sebeplerden dolayı depoya alınamıyor.

Bu arada 3.6 için de çeviri çalışmalarına çoktan başladık, bir kere başlayınca bağımlılık yapıyor

Herkese şimdiden mutlu yıllar

Elle sertifika oluşturmak çoğu zaman hepimizin işine geliyor. Dışarıya açmayacağımız hizmetler için de SSL sertifikası satın almayacağımızı göz önünde bulundurursak, semi-public diyebileceğimiz yalnızca belirli bir kesimi hedef alan projelerde CAcert sertifikalarından yararlanarak elle sertifika oluşturma zahmetinden ve kullanıcıların “arkadaşım bu güvenli değil bak uyarı veriyor” geribildirimlerinden bir nebze olsa da kurtulmuş oluyorsunuz.

Peki kök sertifikayı nasıl kullanabilirsiniz?

Dağıtımlar açısından ele aldığımızda yukarıda saydığım 3 dağıtım CAcert kök sertifikasını “nss” paketlerine dahil ediyor. Pardus’a da dahil edilmesi için bir hata kaydı da ben açtım

Sadece web tarayıcınız ile kullanacaksanız (Firefox) bu bağlantıya tıklamanız yeterli. Sizden onay aldıktan sonra CACert sertifikası kullanan sitelerde SSL güvenlik uyarısı vermeyi bırakacaktır.

Diğer bir seçenek ise nssdb’ye el ile müdahale etmek. Böylece nss’den yararlanan tüm uygulamalarda CAcert sertifikaları güvenlik uyarısı vermeyi bırakacaktır. nssdb’ye müdahale etmek için:

Normal kullanıcı olarak:
1. root.crt’yi ev dizininize kopyalayın. (http://www.cacert.org/certs/root.crt)
2. certutil -d sql:$HOME/.pki/nssdb -A -t "C,," -n cacert -i root.crt komutunu verin.

Ya da root olarak root.crt’yi indirdikten sonra:
certutil -d sql:/etc/ssl/nssdb -A -t "C,," -n cacert -i root.crt komutunu verebilirsiniz. Bu şekilde mevcut nss veritabanına CAcert’i eklemiş olursunuz.

E-posta ile yönetmekten kastım, iş açma/kapama, durum değişikliği ve iş kaydı altına yorum yazma gibi işlemlerin tamamı oluyor. Bunu yapabilmek için öncelikle yönetici arayüzünden bir API key oluşturmanız gerekiyor. (Application settings -> Incoming emails)

Daha sonra Redmine dizini altındaki extra/mail_handler/rdm-mailhandler.rb dosyasını çalıştırılabilir yaptıktan sonra ister o dizin altında, isterseniz ise $PATH içerisinde bir yere kopyalayabilirsiniz.

Bundan sonra ise eğer Postfix kullanıyorsanız şöyle bir alias tanımlamanız yeterli olacaktır:

redmine: "|/path/to/rdm-mailhandler.rb --url http://sunucu --key oluşturduğunuz_key"

Bunu tanımladıktan sonra redmine@sunucu adresine e-posta gönderdiğinizde Redmine üzerinde işleri otomatik açabilir/güncelleyebilir, Redmine’dan gelen e-postalara yanıtla diyerek yanıtınızın Redmine üzerinde yorum olarak görünmesini sağlayabilirsiniz. Bunu yaparken e-postanızın içerisinde şöyle bir satır olması yeterli:

Project: proje

Yukarıdaki alias tanımında tüm projelerde geçerli olmasını sağlamıştık. Eğer ben her e-postada proje ismi belirtmek istemiyorum ve sadece belirli bir projeyi e-posta ile yönetmek istiyorum diyorsanız alias’ı şu şekilde değiştirebilirsiniz:

redmine: "|/path/to/rdm-mailhandler.rb --url http://sunucu --key oluşturduğunuz_key -p proje_ismi"

Bu şekilde göndereceğiniz e-postalar sadece belirtilen proje için geçerli olacaktır.

E-posta ile iş açmak için yapmanız gerekenler ise şu şekilde:

- Konu kısmına iş için başlık girin.
- Mesaj kısmında ise işle ilgili yazacağınız ne varsa yazıp alt kısmına şunları ekleyebilirsiniz:

Project: proje
Tracker: Hata
Priority: Acil
Status: Durum (resolved vb.)

İş açmak bu şekildeyken, işe yorum yazmak çok kolay. Sadece yanıtla demeniz yeterli

Redmine’ı e-posta ile kullanırken dikkat etmeniz gereken tek husus gönderen adresinin Redmine’daki hesabınızdaki e-posta adresi ile aynı olması, bunu da mutlaka göz önünde bulundurun .

-Collaboration suite ile kullanmaya başladım. Zarafa ve zimbra açık kaynak çözümler olduğu için ilk olarak onları denedim.

Sistem kaynağı tüketimi bakımından Zarafa tercih sebebim oldu. Zira zimbra oldukça fazla kaynağa ihtiyaç duyuyor.

Zarafa’nın LDAP yapılandırmasına gelirsek, oldukça kolay bir yapılandırması var. Kurulum yaptıktan sonra paket içinden çıkan ldap.cfg dosyasında DN’leri LDAP ağacına uyarladıktan sonra “zarafa-admin -s” demem yetti, kullanıcıları otomatik kendi veritabanına aktardı. (değişiklik yapıldığında da yansıyor otomatik)

- Doküman yönetim sistemi olarak OpenKM ve Alfresco’yu (Community Edition – Topluluk Sürümü) denedim.

Kullanım kolaylığı ve eklentileri nedeniyle OpenKM her zaman öncelikli tercihim oluyordu. Ancak LDAP yapılandırma konusunda maalesef durum o kadar kolay değil. Bunda biraz da OpenKM dokümantasyonunun ücrete tabi olması da önemli rol oynuyor. Şu ana kadar kimlik doğrulamanın ötesine geçemedim maalesef OpenKM ile. Çözdüğüm anda bununla ilgili bir günlük yazısı yazmak farz oldu

Alfresco da OpenKM kadar esnek ve kullanışlı bir doküman yönetim sistemi. Alfresco ile OpenKM’den önce tanışmış olsaydım muhtemelen OpenKM kullanmıyor olurdum şimdi . Oldukça kapsamlı ve güzel bir dokümantasyonu var. Ayrıca LDAP yapılandırması oldukça basit. Bu yüzden kullanmanızı tavsiye edebilirim. Tek dezavantajı son kullanıcıya sunduğu görsel arabirimin OpenKM’ye kıyasla zayıf olması. (ah şu son kullanıcılar)

- Proje yönetimi için şimdiye kadar hep Trac’i savunurdum, kullanırdım, kullanmaya zorlardım.

Ancak Redmine ile tanıştıktan sonra Trac gördüğüm yerden kaçıyorum artık. Redmine proje yönetimi konusunda çok spesifik istekleriniz yoksa işinizi fazlasıyla görecek bir uygulama.

LDAP yapılandırması ise oldukça basit. Doğrudan desteği olduğu için Redmine ayarlarında bir kaç parametreyi değiştirdikten sonra kullanıcıları LDAP’tan almasını sağlamak 1 dakikadan daha az sürdü .

Trac’ta ise bunun için eklentiye ihtiyacınız olduğunu ek bilgi olarak not düşeyim.

- İçerik yönetim sistemi için bu konuda artık kendisini fazlasıyla kanıtlamış 2 farklı içerik yönetim sistemi (Drupal ve WordPress) ile LDAP doğrulama yapmayı denedim.

WordPress için çeşitli eklentiler denedim, bunlar içerisinde en basit ve en hızlı yapılandırılabilir eklentinin “LDAP LPRM” olduğuna karar verdim. Oldukça esnek ve oldukça basit bir yapı sunuyor; dolayısıyla yapılandırma işi bir kaç dakikayı geçmeyecektir.

Drupal’in LDAP modülüne ise tabiri caizse aşık oldum. Öyle özelleştirilebilir seçenekler sunuyor ki keşke her LDAP desteği olan uygulama bunun kadar esnek çözümler sunabilse diyorsunuz . Drupal 6 için ldap_integration, Drupal 7 için ldap modülü aynı işi yapıyor ve arabirim olarak aynı arabirimi sunuyorlar. İzin gruplarına kadar her şeye müdahale etmeniz mümkün kılıyorlar. İlk defa kullanan birinin 10 dakika içerisinde ayağa kaldırabileceği kolaylıkta olması da ayrı bir güzelliği.

Bu arada Apache ile daha spesifik LDAP yönetimi için mod_authz_ldap modülünü sıkça kullanıyorum ve bir sonraki yazımda Apache ve LDAP konusuna ayrıca değinmeyi planlıyorum.

Bu arada her şeyi web’den yapıyorken LDAP ağacını da webden yönetmenin mümkün olduğunu hatırlatmak isterim. phpLDAPadmin ile oldukça rahat bir biçimde LDAP ağacını yönetebiliyorum. Tabii standart desteklenen (phpLDAPadmin’in desteklemesi gerekiyor) şema kullanmıyorsanız şablonlara biraz müdahale etmeniz gerekebiliyor.

Unutmadan ekleyeyim, spam/antivirus gateway olarak amavisd-new’i beraberinde gelen şema ile kullanmak oldukça keyifli oluyor ve her kullanıcının spam, virus vb. skorlarını ayrı ayrı tanımlayabilmek oldukça rahatlık sağlıyor. Şemanızı OpenLDAP’a tanıttıktan sonra amavisd’nin yapılandırma dosyasına şunları eklemeniz yeterli (zarafa için örnek):

$enable_ldap = 1; # 0 = devredışı, 1 = etkin

$default_ldap = {
hostname => 'ldap.domain.com', # ldap hostname
timeout => 5,
tls => 1, # 0 = false, 1 = true
base => 'cn=people,dc=domain,dc=com', # dizin
query_filter =>
'(&(objectClass=amavisAccount)(|(mail=%m)(zarafaAliases=%m)))'
};


Bunlara ek olarak diğer açık kaynak/özgür yazılımlarla ilgili deneyimlerinizi paylaşırsanız bu listeyi daha da genişletebilirim

Hi,
This is one place where Scientific Linux differs from RHEL.

The default setting for Scientific Linux is for you to "sit on a
release". This means that you do not automatically update to the next
release, unless you want to. So if you install SL 5.4, you willstay at
SL 5.4, getting security updates, until you manually update to whichever
release you want.

If you want the same functionality as RHEL (your machine is
automatically updated to the latest release) you need to install
yum-conf-sl6x.
yum-conf-sl6x