2 Ağustos 2009 Pazar

Subversion ile Salt Okunur Yansılama

Bu yazıda, salt okunur bir SVN (subversion) yansısı oluşturulması ve periyodik senkronizasyon yapacak şekilde konfigüre edilmesi anlatılmıştır.

SVN, versiyon kontrol sistemi olarak yazılım projelerinde oldukça kabul görmüş bir araçtır. Dağıtık olmayan yapısı nedeniyle geliştiricilerin yaptıkları değişiklikleri merkezi bir sunucuya göndermeleri kaçınılmazdır. Ancak SVN ambarlarının (repository) salt okunur yansıları oluşturularak aşağıdaki faydalar sağlanabilir:
  • Merkezi sunucunun yoğun iş yükü altında kalmadan salt okunur şekilde çok sayıda kullanıcının kullanımına açılabilir. Böylece, örneğin açık kaynak projelerin kodlarının geniş kitleler tarafından çekilebileceği bir platform oluşturulmuş olur.
  • Ana sunucu ağ üzerinde güvenli bir noktaya alınırken yansılar Internet üzerinden erişime açılabilir. Böylece ana sunucu ve üzerindeki ambarda tutulan dosyalar saldırılara karşı güvenceye alınmış olur.
  • Ana sunucuda tutulan dosyalar bu yolla yedeklenebilir.
Şimdi şöyle bir senaryo düşünelim. 2 sunucu makinası var. Üzerlerinde Debian Linux dağıtımı çalışır durumda. Bunlardan birisi ana SVN sunucusu, diğeri ise yansısı olacak.
  • Ana (kaynak) sunucunun alan adı main-site.x.y.z olsun.
  • Yansı (hedef) sunucunun alan adı mirror-site.x.y.z olsun.
Öncelikle ana SVN sunucusunda yansı alma amaçlı erişim verilecek bir kullanıcı tanımlanmalı ve bu kullanıcıya salt okunur erişim yetkisi verilmelidir. Bu amaçla ana ambar dizininde (örneğimizde /home/svn/main-repo), "conf/authz" dosyasında aşağıdaki gibi bir tanımlama olmalıdır:
[/]
svn = r
"conf/svnserve.conf" dosyasında da doğrulanmış (authenticated) kullanıcılara en azından okuma hakkı verilmiş olmalıdır:
auth-access = read
Yansı sunucusunda öncelikle SVN sunucusu kurulur:
apt-get install subversion
Örneğimizde yansının hizmet verme biçimi olarak inetd süper sunucusu tercih edildi. Bunun için aşağıdaki satır /etc/inetd.conf dosyasına eklenir:
svn  stream  tcp  nowait  svn  /usr/bin/svnserve svnserve -i -r /home/svn
inetd süper sunucusu yeniden başlatılır:
/etc/init.d/inetutils-inetd restart
veya
/etc/init.d/openbsd-inetd restart
Yansı alınacak ambar oluşturulur:
su - svn
svnadmin create mirror-repo
cd mirror-repo
Senkronizasyon işlemlerini ele alacak betik (hook script) oluşturulur:
touch hooks/pre-revprop-change
chmod u+x hooks/pre-revprop-change
Aşağıdaki içerik betiğe konulur. Burada, "svn" ana sunucuda salt okunur erişecek şekilde ayarladığımız kullanıcıyı ifade etmektedir.
#!/bin/sh
if [ "$3" = "svn" ]; then exit 0; fi
echo "Only the - svn - user may edit revision properties through svnsync" >&2
exit 1
Ana sunucu ve yansı sunucuları arasında, özellikle de aynı güvenli ağ içinde değillerse, güvenli bağlantı tercih edilmelidir. Bu amaçla yansı sunucusu tarafında gizli ve açık anahtar ikilisi üretilir:
su - svn
cd ~/.ssh
ssh-keygen -t dsa -b 1024 -f mirror-site.key
Böylece .ssh dizininde "mirror-site.key" adlı gizli anahtar ve buna karşılık gelen "mirror-site.key.pub" adlı açık anahtar dosyası üretilmiş olur. Bu açık anahtar dosyasının içeriği, ana sunucudaki "svn" kullanıcısının ".ssh/authorized_keys" dosyasına eklenir.
Yansı sunucusunda svn kullanıcısı ile linux oturumu açılır:
su - svn
SVN_SSH ortam değişkeni aşağıdaki gibi ayarlanır:
export SVN_SSH="ssh -i /home/svn/.ssh/mirror-site.key"
Yansı sunucusu aşağıdaki gibi ilklendirilir:
svnsync init file:///home/svn/mirror-repo svn+ssh://svn@main-site.x.y.z/home/svn/main-repo
İlk senkronizasyon başlatılır:
svnsync sync file:///home/svn/mirror-repo
Senkronizasyon işlemlerini zamanlanmış görev haline getirmek için crontab ayarlaması yapılır:
crontab -e
Açılan editör ekranına ağıdaki satır eklenir. Bu örnekte her saat başında senkronizasyon operasyonu başlatılacaktır.
0 * * * *     (export SVN_SSH="ssh -i /home/svn/.ssh/mirror-site.key"; svnsync sync file:///home/svn/mirror-repo)
Bu otomasyon yansı sunucusunu en fazla bir saat gecikmeyle ana sunucu ile senkron tutacaktır. Yarıda kalan senkronizasyon işlemleri nedeniyle yansı ambarı kilitlenir ve senkronize edilemez hale gelirse aşağıdaki komut yansıyı kilitli durumdan kurtaracaktır:
svn propdel svn:sync-lock --revprop -r 0 file:///home/svn/mirror-repo
Hepsi bu kadar.

5 yorum:

Unknown dedi ki...

darcs kullanıdn mı peki Hadi hocam ? http://darcs.net/

Mustafa Hadi Dilek dedi ki...

Merhaba Murat. Darcs kullanmadım. Dağıtık versiyon kontrol sistemleri sanırım merkezi kontrolün çok gerekmediği ve merkezi bir sunucuya sürekli online erişimin sağlanamadığı geliştirme ortamları için ideal gibi. Şimdilik, aynı anda kullanma durumunda olmadığım farkli bilgisayarlardaki kişisel verilerimi geçmiş bilgisi olacak şekilde senkronize etmek için kullanabilirim gibime geliyor. Bu amaçla mercurial (http://mercurial.selenic.com/) ile ufak denemelerim oldu. Kullanımı kolay. Ancak dediğim gibi ne tür kullanım durumlarında ideal oldukları konusu bende henüz tam olarak olgunlaşmadı. Deneyimlerimi aktaracağım.

Osman Karagöz dedi ki...

Merhaba. Güzel bir yazı olmuş. svn'i yeterince bilmemekle birlikte böyle bir şeye ihtiyacım vardı. Ama aklıma şöyle bir şey geldi. ana depo ve senkronize depolar birbirinden senkronize olabilirler mi? Yani ben hangi depoya commit edersem edeyim diğer depo bundan etkilensin diye bir düşünce. Ben arada senkronize depoyu kullanayım ve ana depo senkronize depodan kendini senkronize etsin desem bu yazdıklarınızla mümkün mü?

Mustafa Hadi Dilek dedi ki...

Merhaba. Burada ana depo yazılabilir, senkronize depolar salt-okunur olacak şekilde bir senaryoyu anlatmaya çalıştım. Değişikliklerin ana depo üzerinde (tek bir yerden) yapıldığı, ama okumaların senkronize sunucular tarafından yapılabildiği bir yapı söz konusu. Böyle bir yapıda senkron sunucuları, örneğin açık kaynak kodlu projelerin kaynak kodlarına salt-okunur yansılar oluşturup yoğun erişim talebine cevap verme amaçlı kullanabilirsiniz. Salt okunur olarak konfigüre edildikleri için de ana depodaki çalışmanın saldırılardan korunur olması sağlanmış olur. Aynı zamanda mevcut ana deponun periyodik yedeğini alma amacıyla kullanılabilir. SVN deposunun geçmişe dönük yedeklerini ayrı ayrı oluşturmanız gerekmez. Çünkü SVN deposu kendi içinde geçmişe dönük bilgiyi saklar durumdadır.

Sözünü ettiğiniz ihtiyaca yönelik olarak dağıtık versiyon kontrol sistemleri (mercurial ve darcs gibi) önerilebilir. Ancak bildiğim kadarıyla bunlarda da ana deponun kendini otomatik (belirli aralıklarla) senkronize etmesi şu an için söz konusu değil. Sizin ek crontab scriptler'i yazarak çözmeniz gerekir diye tahmin ediyorum.

Osman Karagöz dedi ki...

Bilgi için teşekkür ederim :D