WwW.TarikZengin.CoM

Bu yaziyi bir HowTo belgesi gibi dusunmeyin lutfen. Tamamen kendi denemelerimden olusmakta.

Nisan’da yeni donemin baslamasiyla beraber labda bazi bilgisayarlar bosa cikinca “Nasil degerlendirilebilir acaba bu eski bilgisayarlar?” dusuncesiyle boyle birsey yapmaya karar verdim. Makinelerden birini svn sunucusu olarak kullanabilirdik. Tum lab elemanlari da projelerini bu sunucuda tutabilirlerdi. Proje takibi icin de baslangicta trac kullanmayi dusunmustum. Fakat trac in ayni anda tek bir repo destekliyor olmasi dusunduruyodu beni. Tam bu sirada, daha once duymamis oldugum redmine ile ilgili bir kitap gordum kitapcida, subversion ve trac kitaplarinin hemen yaninda. Sonradan arastirinca kanim kaynadi hemen. Coklu proje destegi aklimi celdi. Bir de daha once hic Rails uygulamasi gormemistim, merak ettim.

Dagitim olarak da yabancilik cekmemek adina cok uzun suredir kullandigim Gentoo’yu sectim. Adim adim anlatmaya calisacagim.

Oncelikle bu sunucuda grafik arayuz kullanmayacagim, sadece uzaktan erisim saglayacagim icin X e gerek yok. Bu yuzden -X -gtk -gnome -qt -kde -alsa USE flaglerini kullaniyorum. Ayni zamanda bu makine oldukca eski (Celeron D) oldugu icin derleme suresini kisaltmak icin distcc kullaniyorum. Distcc’nin nasil ayarlandigina deginmeyecegim, zira zor bir yani yok. Sonuc olarak make.conf dosyasi su sekilde.

CFLAGS="-O2 -march=pentium4 -pipe -fomit-frame-pointer"
CXXFLAGS="-O2 -march=pentium4 -pipe -fomit-frame-pointer"
CHOST="i686-pc-linux-gnu"
FEATURES="distcc parallel-fetch userpriv"
DISTCC_VERBOSE="1"
MAKEOPTS="-j6"
USE="apache2 postgres gd xml -X -gtk -gnome -qt -kde -alsa sqlite sqlite3"

Base sistemin kurulumunun ardindan openssh ve bagimliliklari kurulduktan sonra islemleri uzaktan yapmaya devam edebilir hale geliyor sunucu.

Repolara web sunucu uzerinden erisecegimiz icin subversion paketini kurarken apache2 destegi ile derlemek gerekli. Binary dagitimlarda bu destek dogrudan acik olarak mi geliyor bilmiyorum.

Apache kurulduktan sonra hicbir ayar yapmadan calisabilir durumda oluyor. Yalnizca init scriptini calistirmak yeterli. Subversion repolarimiza https uzerinden webdav ile ulasmak istedigimiz icin apache’ye bazi modulleri eklememiz gerekiyor. /etc/conf.d/apache2 dosyasinda APACHE2_OPTS kismina -D SVN -D SVN_AUTHZ -D DAV -D DAV_FS -D SSL -D SSL_DEFAULT_VHOST degerlerini eklememiz gerekli. Benimki su sekilde

APACHE2_OPTS="-D DEFAULT_VHOST -D INFO -D LANGUAGE -D SSL -D SSL_DEFAULT_VHOST\
 -D SVN -D SVN_AUTHZ -D DAV -D DAV_FS -D PASSENGER"

Passenger kismina daha sonra deginecegim.

Repolari kullanacak tum kullanicilari sistemde olusturdum. Mail sunucusu olarak kullandigimiz bir de Fedora var labda, herkesin zaten bir hesabi mevcut bu makinede. Ldap kullanarak kullanicilari tekrar tanimlamadan kullanmanin bir yolu olabilir diye tahmin ediyorum fakat pek de detayli bir bilgim yok bu konuda.

Subversion depolarini kullanacaklar icin svnusers isminde bir kullanici grubu olusturdum ve kullanicilari bu gruba dahil ettim.

Repolar icin /var/svn/repos dizinini , konfigurasyon dosyalari icin de /var/svn/conf dizinini kullaniyorum. repos dizinine gruba dahil tum kullanicilar yazip okuma yapacagi icin izinlerini 775 olarak verdim. Unutulmamasi gereken bir nokta da apache kullanicisini da svnusers grubuna dahil etmek. Apace kullanicisi dagitima goredegisebiliyor. Sanirim Debian’da bu kullanici www-data ismiyle geciyor.

Repolara apache uzerinden ulasacak kullanicilar icin htpasswd dosyasi tanimlamamiz gerekiyor. Bunun icin de hal-i hazirda sisteme ekledigimiz kullanicilara

htpasswd2 /var/svn/conf/svnusers kullanici_adi

seklinde sifre belirlememiz gerekiyor. svnusers dosyasini olusturmak icin ilk calistirmada komuta -c parametresi eklemek gerekli.

Ardindan da olusturulan repoya hangi kullanicilarin hangi haklarla erismesine izin verecegimizi de /var/svn/conf/svnpolicy dosyasindan ayarlamamiz gerekiyor.

Bu islemleri basitlestirmek icin kisa bir bash script yazdim. Yazinin ilerleyen kisminda bulabilirsiniz.

Apache’yi svn repolarimizi gosterecek sekilde ayarlamakta sira. /etc/apache2/modules.d/47_mod_dav_svn.conf dosyasinda asagidaki duzenlemeyi yazpiyoruz.

<IfDefine SVN>
        <IfModule !mod_dav_svn.c>
                LoadModule dav_svn_module       modules/mod_dav_svn.so
        </IfModule>
        <Location /svn/repos>
                DAV svn
                SVNParentPath /var/svn/repos
                #SSLRequireSSL
                AuthType Basic
                AuthName "System Integration Lab SVN Repository"
                AuthUserFile /var/svn/conf/svnusers
                AuthzSVNAccessFile /var/svn/conf/svnpolicy
#                <LimitExcept GET PROPFIND OPTIONS REPORT>
                Require valid-user
#                </LimitExcept>
                SVNIndexXSLT /svnindex.xsl
        </Location>
        <IfDefine SVN_AUTHZ>
                <IfModule !mod_authz_svn.c>
                        LoadModule authz_svn_module     modules/mod_authz_svn.so
                </IfModule>
        </IfDefine>
</IfDefine>

Comment edilmis 2 satir var goruldugu gibi. Bu limitlemeyi acarsam bazi sorunlarla karsilastim. Bu sekilde benim icin yeterli sekilde calisiyor.

SVNIndexXSLT satirinda belirttigimiz svnindex.xsl ve svnindex.css dosyalarini da sunucunun ana dizinine kopyaliyoruz. Bu durumda /var/www/localhost/htdocs/

Henuz bir repo olusturmadik fakat olusturdugumuz takdirde http://localhost/svn/repos/repo_adi adresinden ulasabiliyor durumdayiz su an. Yalniz dikkat http, https degil henuz.

Http uzerinden tum iletisimi kesmek icin /etc/apache2/vhosts.d/00_default_vhost.conf dosyasinda tanimli ayarlarin hepsini comment ederek kapattim. Artik http uzerinden erisim yok. Https uzerinden de yok. Oh ne guzel. Yazi burada bitse ne kotu olur.

Simdi Redmine kurulumuna gecelim. http://www.redmine.org/wiki/redmine/RedmineInstall adresinde kurulum ile ilgili bilgiler mevcut. Svn ile redmine kodunu checkout edip istedigimiz bir dizine koyabiliriz. Ben /var/rails/redmine dizinine koydum.

Sistemde bulunmasi gereken paketler ruby, ruby-gems, mysql-ruby, rails ve bunlarin bagimliliklari. Kurulumdan sonra

gem install rails -v=2.2.2

ile rails versiyonunu ayarliyoruz.

Redmine dizini altindaki config/database.yml dosyasinda gerekli database ayarlamasini yaptiktan sonra

rake db:migrate RAILS_ENV="production"

ile gerekli tablolari olusturuyoruz.

Artik redmine uygulamasini

ruby script/server webrick -e production

komutu ile calistirip http://localhost:3000/adresinden uygulamayi gorebiliyor olmamiz gerekir.

/var/rails/redmine/config/email.yml dosyasinda da smtp ayarlarini yaparak Redmine’in kullanicilara e-mail yollayabilmesini saglayabiliriz.

Bir sonraki adim Redmine uygulamasini bu sekilde daemon modunda degil, apache icerisinden calisir hale getirebilmek. Bunun icin de apache’nin mod_rails destegi ile calismasi gerekli. Yukarida bahsettigim Passenger da iste tam bu ise yariyor.

Rails uygulamasi, public dizininde apache tarafindan sunulacak dosyalari barindiriyor. Burada .htaccess dosyasinda apache’ye Rails uygulamalarini mod-fcgid ile calistirmasini soylememiz gerekli.

# General Apache options
#AddHandler fastcgi-script .fcgi
#AddHandler cgi-script .cgi
AddHandler fcgid-script .fcgi
Options +FollowSymLinks +ExecCGI

RewriteEngine On

RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f
#RewriteRule ^(.*)$ dispatch.cgi [QSA,L]
RewriteRule ^(.*)$ dispatch.fcgi [QSA,L]

ErrorDocument 500 "<h2>Application error</h2>Rails application failed to start properly"

Ben bu sekilde kullaniyorum. Ardindan apache’nin https uzerinden rails uygulamizi sunmasi icin /etc/apache2/vhosts.d/00_default_ssl_vhost.conf dosyasinda DocumentRoot bolumunu ayarlamamiz gerekli.

<IfDefine SSL>
<IfDefine SSL_DEFAULT_VHOST>
<IfModule ssl_module>

Listen 443

<VirtualHost _default_:443>
        ServerName XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
        Include /etc/apache2/vhosts.d/default_vhost.include
        ErrorLog /var/log/apache2/ssl_error_log

        <IfModule log_config_module>
                TransferLog /var/log/apache2/ssl_access_log
        </IfModule>

        SSLEngine on

        SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL

        SSLCertificateFile /etc/apache2/ssl/server.crt

        SSLCertificateKeyFile /etc/apache2/ssl/server.key

        <FilesMatch "\.(cgi|shtml|phtml|php)$">
                SSLOptions +StdEnvVars
        </FilesMatch>

        <Directory "/var/www/localhost/cgi-bin">
                SSLOptions +StdEnvVars
        </Directory>

        <IfModule setenvif_module>
                BrowserMatch ".*MSIE.*" \
                        nokeepalive ssl-unclean-shutdown \
                        downgrade-1.0 force-response-1.0
        </IfModule>

        <IfModule log_config_module>
                CustomLog /var/log/apache2/ssl_request_log \
                        "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
        </IfModule>

        DocumentRoot /var/rails/redmine/public/

        <Directory /var/rails/redmine/public>
                Options ExecCGI FollowSymLinks
                AllowOverride all
                Order allow,deny
                Allow from all
        </Directory>

</VirtualHost>
</IfModule>
</IfDefine>
</IfDefine>

# vim: ts=4 filetype=apache

ServerName kismi onemli. Domain ismini tam olarak yazmak gerekiyor, yoksa sertifika problemleri ile karsilasilabilir.

Apache, Redmine uygulamasini https uzerinden sunmaya hazir. Yukarida belirttigimiz sertifika dosyalarini da olusturtuktan sonra islem neredeyse tamam oluyor. SSLCertificateFile ve SSLCertificateKeyFile ile belirtilen 2 dosyayi openssl kullanarak olusturmaliyiz. Buna self-signed certificate deniyor. Bunun icin su sayfaya bakabilirsiniz. Uzun uzun anlatmaya gerek yok.

/etc/init.d/apache2 restart

ile apache’yi tekrar baslattiktan sonra Redmine uygulamamizi https://domain_adi seklinde gorebiliyor olmaliyiz.

Eger buraya kadar sorunsuz geldiysek (ki cok kucuk bir ihtimal), simdi biraz sorun yaratalim.

Svn repolarimiza https://domain/svn/repos/repo_adi adresinden ulasabiliyorduk. Fakat bu DocumentRoot degerini degistirmeden once idi. Yeni DocumentRoot dizininde svnindex.xsl ve svnindex.css dosyalari bulunmuyor. Bu da demektir ki artik repolara ulasamiyoruz. Aslinda apache ayarlarindan her alt dizine, her alt-domain’e gore farkli ayarlamalar yapilabiliyor. Ama ben yine en amele yolu secip bu iki dosyayi Redmine public dizinine koymayi tercih ettim. Sonucta isimi goruyorsa tamamdir, profesyonel degilim ne de olsa. Hobi olarak ugrasiyorum bu islerle. Hayir, hobilerim arasinda kendime iskence etmek gibi mazosist seyler yok.

Simdi gozden gecirelim neler yaptigimizi:

• Subversion repolarina https://domain/svn/repos/repo_adi adresinden ulasilabiliyor.
• Redmine uygulamasi apache tarafindan calistirilip https://domain adresinden ulasilabiliyor.

Iki maddecik, az gibi gorunuyor fakat cok gunlerdir bununla ugrasiyorum.

Simdi gelelim isleri kolaylastirmaya. Yaklasik 15 kullanici kullanacak bu sistemi. Her biri icin bir kullanici hesabi var sistemde. Reponun olusturulmasi ve gerekli izinlerin duzenlenmesi bazi asamalarda root yetkileri gerektiriyor. Herkesin reposuyla tek tek ilgilenmemek icin bu isi otomatize etmek gerekiyor.

#!/bin/bash
DIR=/var/svn
REPODIR=$DIR/repos
CONFDIR=$DIR/conf
export USER=`whoami`
echo -n "SVN Database Name: "
read -e DATABASE
if test -e $REPODIR/$DATABASE
then
echo "This database exists. Please try another name."
else
svnadmin create $REPODIR/$DATABASE
sudo chown -R apache:svnusers $REPODIR/$DATABASE/
sudo chmod -R g-w $REPODIR/$DATABASE/
sudo chmod -R g+rw $REPODIR/$DATABASE/db/
sudo chmod -R g+rw $REPODIR/$DATABASE/locks/
echo "[$DATABASE:/]" | sudo tee -a $CONFDIR/svnpolicy
echo "$USER = rw" | sudo tee -a $CONFDIR/svnpolicy
echo "User $USER has been authorized to read-write the $DATABASE repository"
echo "ユーザ $USER は $DATABASE に対する書き込み/読み込みを許可されました"
echo "If you want to authorize more users, please contact with the admin"
echo "追加でユーザを許可したい場合は、管理者に問い合わせてください。"
echo ""
echo "Your database is now accessible from https://domain/svn/repos/$DATABASE"
fi

Kullanicilara tamamen root yetkileri vermektense sudo kullanmak daha akilci geldi. Yukarida gorelecegi uzere yalnizca 3 komut sudo ile calistiriliyor. Bunlari da sudoers dosyasinda tanimliyorum.

%svnusers ALL=/bin/chown, /bin/chmod, /usr/bin/tee

Aslinda hala tehlikeli bir is, chmod ve chown kullanarak bile kolayca dagitilabilir sistem.

Ilk once daha farkli bir script hazirlamistim. Onun icinde bu sekilde sudo kullanmiyordum. Kullanici o scripti sudo ile calistiriyordu. Daha guvenli bir yontem. Fakat benim komutu calistiran kullanicinin adina ihtiyacim var ve whoami komutu sudo ile calistirildiginda dogal olarak root donduruyor. Aklima bir yol gelmedi simdilik. Onerilere acigim.

Artik kullanicilar kendileri svn repolarini olusturabiliyor durumdalar. Fakat hala Redmine uzerinde proje olusturma isi bana ait. Bunun bir yolu olup olmadigini bilmiyorum, fakat bir yandan da iyi oldugunu dusunuyorum. Onune gelen proje olusturmasin. Simdilik dusuncem bu.

Gelelim bir baska probleme. http uzerinden calisirken hersey gulluk-gulistanlik fakat https uzerinden ortaya cikan bir sorun var. Bununla epey cebellestikten sonra farkina vardim. Kullanici repoyu olusturuyor, https://domain/svn/repos/repo_adi adresinden goruntuleyebiliyor, Redmine’a sorunsuz bir sekilde login olup kullanabiliyor fakat Redmine’da olusturdugu projesine svn reposunu eklemeye kalktiginda bir turlu basarili olamiyordu. Uzun sure dusundukten sonra, svn checkout sirasinda  sertifikanin gecici mi kalici mi olmasini istedigimizi soran soru kafamda bir isik yakti. Biraz arastirinca anladim ki, Redmine svn reposuna ulasirken apache kullanicisini kullaniyor ve bu kullanici gerekli sertifikaya sahip degil.

Daha mantikli bir cozumunun oldugunu dusunuyorum fakat ben yine biraz amele bir yontem kullandim. apache kullanicisi ile svn checkout yapip sertifikayi almasini sagladim.

sudo -u apache svn co https://domain/svn/repos/repo_adi

Bu adimdan sonra Redmine icerisinden sorunsuz olarak repo ekleyip, goruntulenebiliyor hale geldi.

Son adim olarak, repolarin ve mysql vertabaninin duzenli olarak yedegininin alinmasi icin bir script hazirladim. Bu da repolardan ve veri tabanindan dump alip bunu labdaki dosya sunucusunda yedek icin ayirdigim alana periyodik olarak atmaya yariyor.

#!/bin/bash

# Mount Tera Station
mount -t cifs //xxx.xxx.xxx.xxx/usr /mnt/tera -o user=xxxxx,pass=xxxxx

export whatisdate=`date +%F`

cd /var/svn/repos

# Backup the Subversion Databases
for i in $( ls ); do
echo $i repository is now backing up...
svnadmin dump $i > /mnt/tera/redmine/Subversion\ Backups/$i-$whatisdate.dump;
echo "`date` - Subversion Backup : $i" >> /mnt/tera/redmine/log.txt
done

# Backup the Redmine Database
echo Redmine Mysql Database is now backing up...
mysqldump -u root --password=xxxxx redmine | gzip > /mnt/tera/redmine/Redmine\ Database\ Backups/redmine_`date +%y_%m_%d`.gz
echo "`date` - Redmine Database Backup" >> /mnt/tera/redmine/log.txt

# Unmount Tera Station
umount /mnt/tera

Bu scriptin soft linkini de /etc/cron.weekly/ dizinine atarak haftada bir kez calismasini saglamis oluyorum.

Guvenlik acisindan pek cok eksigin oldugunun, scriptlerin icerisinde acik acik sifre ve kullanici adi kullandigimin farkindayim. Gunlerdir bu sistemi adam etmeye calisiyorum ve yaptiklarimin bir kismini simdiden unuttum. Bunlari da unutmadan yazayim dedim. Belki guvenlikle ilgili bazi iyilestirmeler yapabilirim.

Bazi kisimlarda hala sorunlarim var. Ornegin, farkli kullanicilar icin farkli repolar tanimli. Browser’da bunlardan birini https://domain/svn/repos/repo_adi seklinde actigimda beklendigi gibi kullanici adi ve sifre soruyor. Ardindan bir baska kullaniciya ait diger repoyu actigimda, tekrar kullanici adi ve sifre sormak yerine 403 Forbidden hatasi veriyor. Tekrar sormasi icin browser’i kapatip tekrar acmam gerekiyor. Bunun nedenini bulabilmis degilim. Burada da fikir ve onerilere acigim.

Iyi aksamlar Turkiye, her nerede commit ediliyor ve ettiriliyorsa.