Yaklasik 2 yildir WZR-HP-G300NH model bir wifi router kullaniyorum. Buffalo, Japonya disinda da bilinen bir marka fakat Turkiye’de satisi var mi ya da duyan eden oldu mu bilmiyorum. Urunleri gayet kaliteli.

Japonya’da uretilen elektronik urunlerin cok buyuk bir cogunlugunun – firmanin ne kadar buyuk ve dunya capinda bilinirlige sahip oldugundan bagimsiz olarak – Japonca disindaki dillere destegi bulunmuyor. Bunun, bilgisayar alirken Ingilizce klavye alamamak, Ingilizce isletim sistemi alamamak, TVlerde yalnizca Japonca menu dili kullanmak zorunda kalmak gibi cesitli orneklerini verebilirim. Ilk ikisi her ne kadar, en azindan benim icin, sorun teskil etmese de, genel olarak bir sikinti soz konusu. Routerda da durum bu idi. 1 yil suresince Japonca arayuzu ile kullandim. Router’in ayarlari genel olarak asina oldugum seyler oldugu icin temel kullanimda pek sorun yasamadim. Fakat aletin donanimsal ozellikleri hic de fena sayilmayacak sekilde iyi ve orijinal firmware biraz yetersiz kalinca, yeni bir ROM yukleyerek hem farkli ozellikler kullanabilir hem de arayuzu istedigim dilde kullanabilir duruma getirmeye kalkistim.

Router uzerinde bir USB portu bulunuyor ve stock ROM buradan baglanan hard disk icin yalnizca FAT ve XFS destekliyor idi. Ben de routeri ilk aldigim zaman harici diski(Buffalo – 1TB) XFS ile formatlamistim. Ag paylasim isini Samba yapiyor. Bir de – sanirim kendi yazdiklari – bir torrent istemcisi calistiriyor. Yeni yuklenecek dagitimin da en az bu ozellikleri saglamasi ilk hedefti.

Oncelikle DD-Wrt dagitimini denedim. Stock ROM’dan DD-WRTye gecmek oldukca basit. Modele ozel ROM, stock web arayuzunden yuklendi. Yaklasik 1 haftalik kullanim suresinde, sistem genel itibariyle calisiyor olsa da, Samba nedenini bulamadigim bir sekilde fazla kaynak tuketiyordu. Alternatif olarak NFS ile de kullanmayi denedim fakat verim alamadim. Ustune ustluk torrent istemcisi yuklemekte sorun cikinca OpenWRT’ye de bir sans vermek istedim. Aralarinda bir halef-selef iliskisi var ama hangisi hangisi net bilmiyorum. Bir yerden sonra da ayriliyorlar sanirim. Neyse.

OpenWRT’nin yuklenmesi onceki kadar sorunsuz olmadi malesef. Once DD-WRT’de oldugu gibi web arayuzunden yuklemeyi denedigimde yukleniyor gorunmesine ragmen hic bir degisiklik olmadan tekrar eski halinde acildi. Biraz daha detayli bilgi alabilmek icin telnet uzerinden baglanip, yuklenecek dosyayi da tftp server uzerinden gonderip yuklemeyi denedigimde de yine sorunsuz yukleniyormus gibi gorunup, reboot ettikten sonra tekrar eski halinde aciliyordu. Disariya bakan bir seri arabirim de bulunmadigi icin eldeki tum imkanlar bitmis bulunuyordu. OpenWRT ve DD-WRT forumlarinda biraz vakit gecirince bunun sadece Japonya’da satilan Japonca arayuzlu (zaten baska yok) modellerde karsilasilan bir problem oldugunu ve birkac kisinin daha basina geldigini gordum. Japonya disinda satilan ayni modelde bir kisitlama yokken, buradaki modelde bootloader sifrelenmis olarak yazilmis ve ROM’un uzerine yazilmasina izin vermiyormus. DD-WRT nasil yuklenmisti onu hala cozemedim. Sorun ortaya ciktiktan sonra gelistiriciler ayni gun bunun icin yamanmis bir surum daha cikardilar. Zehir gibi adamlar.

Acikcasi is biraz uzadi. Bootloader uzerinde birkac islem yapmak, ardindan da imaji yine tftp uzerinden gonderip yuklemek gerekiyordu. Bunun icin de seri arabirim sart. Aletin karti uzerinde seri arabirim cikislari mevcut fakat pinleri takili degilmis. Oturup bunlari lehimleyip garanti kapsamindan ciktiktan sonra bir de RS232-TTL donusturucu bulmak vardi. Onu da kucuk bir karta yaptim.

Detaylarini yazmayacagim cunku bu sorun sadece burada satista olan modellerde gecerli. Kimsenin ihtiyaci olacagini sanmiyoyorum. Merak edenler OpenWRT’nin wiki sayfalarindan bilgi edinebilir. Zaten amac bu router icin tarif vermek degil OpenWRTyi anlatmak.

OpenWRT Web Arayuzu - Samba Ayarlari

Supported Devices sayfasindan uyumluluk kontrolu yapabilirsiniz. Eger elinizdeki alet desteklenenler arasindaysa, orijinal ozelliklerinin kat kat fazlasini kullanabilecek duruma gelmesi an meselesi demektir.Paketlerin yuklenmesi de APT’a benzeyen opkg araciyla ya da web arayuzu uzerinden yapilabiliyor.

Yapilabileceklere birkac ornek verecek olursak;

USB portuna bagli hard diski NFS ya da Samba ile ag uzerinden ulasip kullanabilirsiniz. Harici diskinizi devamli tak-cikar yapma zahmetinden kurtulur, wifi alaninda her noktadan kullanabilirsiniz. Daha once XFS dosya sistemiyle kullandigim diski artik ext4 ile kullaniyorum. (XFS dogru sekilde unmount etmeyip her seferinde journali tamir etmemi gerektiriyordu). Ayrica hd-idle ile de kullanilmadigi durumlarda diski bekleme konumuna alip hem enerji tasarrufu yapip hem de diskin omrunu uzatabilirsiniz. Bunun disinda basit bir port yonlendirmesiyle disaridan da erisilebilir duruma getirebilirsiniz.

Yine USB portuna baglayacaginiz kameraya uzaktan baglanabilir, guvenlik kamerasi olarak kullanabilirsiniz.

Daha fazla guvenlik icin VPN olusturabilirsiniz.

CUPS ile yazici sunucusu olusturup, ag yazicisi olmayan herhangi bir USB yaziciyi ag uzerinden ulasilabilir duruma getirebilirisiniz.

MiniDLNA ya da uShare ile uPNP ya da DLNA ozelligi olan cihazlara video, muzik ve fotograf yayini yapabilirisiniz. Televizyonda DLNA destegi var, miniDLNA ile tum muzik arsivimi ag uzerinde yayinliyorum. Bilgisayarin acik olmasina gerek kalmadan tum muziklere TV uzerinden ulasabiliyorum.

Transmission ile tum torrent islemlerini bilgisayardan bagimsiz hale getirebilirsiniz. Torrentler dogrudan USB portuna bagli hard diske indiriliyor. Bilgisayarda da transmission istemcisi router uzerindeki daemona baglanip kontrol edilebiliyor. Akilli telefonlar icin de Transmission remote control programlari var. Hic bilgisayar kullanmadan da torrent kullanilabilir.

Derlenen ya da yorumlanan herhangi bir dilde yazdiginiz program ya da scriptlere cron ile periyotlar belirleyip calistirabilirsiniz. Otomatik yedekleme icin kullanilabilir.

USB ses karti takip tamamen kendi basina calisan bir muzik caliciya donusturebilirsiniz.

Apache ile web sunucusuna donusturebilirsiniz.

Asterisk ile kendi VoIP sunucunuzu kurabilirsiniz.

Dansguardian ile icerik filtrelemesi yapabilirsiniz.

Isletme sahibiyseniz, musterilerin belirli bir sure icin ucretli ya da ucretsiz kablosuz baglantinizi kullanmasini saglayabilirisiniz. Havalimanlarindaki gibi.

Bunlarin disinda daha aklima gelmeyen bircok sey mumkun.

Saydiklarim arasinda yaptiklarim da bulunuyor, yapilmak icin sira bekleyen de. Ilk ikisi VPN ve CUPS. Ardindan da otomatik bir backup scripti, hem bilgisayardaki verileri hem de bu domain ve subdomain altindaki uygulamalari otomatik yedekleyen bir script yazilabilir. Bir gun yazarsam onu da paylasirim.

Tokyo’ya gitmişken, Akıhabara’da bir gün harcamadan edemedim. Dolaşırken birkaç parça ufak şey ve de ne zamandır almayı düşündüğüm Logitech Pro 9000 webcami aldım. Almadan önce de satıcıyla epey cebelleştim. İnatla Logitech’in Linux desteği vermediğini, driver bulamayacağımı söyledi. UVC sürücülerinin bu modeli çalıştırdığını önceden biliyordum. O yüzden satmak istememesine rağmen ısrar edip aldım. Bu yazıyı da almak isteyen olur da Linux’da çalışıp çalışmadığını merak eden olur diye yazıyorum. Linux-uvc sayfasında söylediğine gore bu serinin bazı modellerinde birtakım uyumsuzluklar ortaya çıkabiliyormuş. Bunun için de Logitech’in kendi yayınladığı şu listeye bakabilirsiniz.

Logitech Pro9000

Gerekli sürücü media-video/linux-uvc paketi ile birlikte geliyor. Derlemek için kernelde V4L2 desteğinin açık olması gerekli. Sonrasında Skype ile sorunsuz bir şekilde kullanabildim. media-video/luvcview ve media-video/guvcview de tüm özelliklerini kurcalamak ve kayıt yapmak için yeterli araçlar gibi görünüyor. Yazdığına gore oto-focus şu anda desteklenmiyormuş. Ben herhangi bir sorunla karşılaşmadım bu yüzden. Görüntü kalitesi gerçekten güzel. Tavsiye olunur.

Gurkan, Burak ve Serkan Gentoo Gezegeni acmislar. “Beni de alin” dedim, sagolsunlar kirmadilar. Ilk kesintisiz bos zamanimda bir Gentoo yazisi yolda.

Gezegene buradan buyrun.

Haziran ayi benim icin oldukca ozel. Nedeni de hayatimi degistiren seyin hayatima girisinin 10. yili olmasi. Hayir, sevgilim ya da esim degil.

1999 yilinin yaz baslariydi. Ben 15 tam 12′de 8 yasinda idim. Hersey iste tam da o zaman basladi.

Abit anakart kutusundan cikan Linux CD’si. Onu hala sakliyorum. Seviyorum.

Her ne kadar beni duymayacak, yazdiklarimi okumayacak, okusalar da anlamayacak olsalar da Torvalds, Stallman ve diger milyonlarca gelistiriciye minnet duydugumu belirtmek istiyorum.

99′da baslayan macera sayisiz dagitim denememe, hepsinin artisini eksisini gormeme, guzelliklerle buyulenmeme neden oldu. Bugun belli basli sayilabilecek dagitimlarin tumunu, ve artik tarih sahnesinden silinmis bazilarini deneme firsati buldum ve bunun icin kendimi sansli hissediyorum.

Yalnizca bu mu Haziran ayini ozel yapan? Degil. Aradan 5 yil gecmis, 2004 yilinin Haziran ayina gelinmis, ben ise 20 tam 12′de 8 yasima gelmistim. Ve o gune kadar denedigim en iyi dagitimla tanistim. Gentoo!!

O gun bu gun beraberiz. Mutluyuz. Bu arada ben 25 tam 12′de 8 yasima gelmisim. Saka gibi.

Linux ile tanismamin 10., Gentoo ile tanismamin 5. yili olmasi sebebiyle bir dizi etkinlik duzenleyecegim. Dunyanin bir ucunda olmam sebebiyle etkinliklere yalnizca benim istirak edecek olmam hic de umrumda degil. Buraya geldigimden beri 4 Gentoo, 3 Kubuntu ve 1 Vine Linux kurulumu yaptim ve eylemlerim devam edecek.

Ederi 10binlerce dolari bulan yazilimlari karsilik beklemeden onume seren GNU camiasi, tesekkur ederim.

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.

Abstract
The Domain Name System (DNS) is a naming system which transforms human readable domain names, into machine readable IP addresses and vice versa. The DNS servers create a database entry for each domain and send the equivalent IP address when they receive a query. DNS servers synchronize themselves with the authoritative DNS sources. When a query came to DNS server, it caches this request for future queries. If this request comes from a non-authentic client and has cached by DNS server, this causes a poisoned cache. This request may come from an improper software, a wrong configured name server or a malicious software which is created to exploit the DNS system.

Conventional DNS Query

Let’s explain this with an example. At first, the client makes a request for www.example.net to the IPS’s DNS server. The DNS server knows that this client is not an authoritative for the domain, so it also knows that it has to find it out of its cache, not in the local zone.

The DNS server forwards this query randomly to one of its 13 root servers. The root server receives this query but know nothing about this new domain. But it knows the Global Top Level Domain (GTLD) servers which are responsible for .net domains. GTLD server receives the same query from root server. If it also knows nothing about this domain, it adds a referral to the query and sends it back.
This cycle returns until one of the servers knows the exact answer of our query. This true equivalent of the domain is called A Record.

The DNS server also files away this answer into its own cache for the future queries.

A Normal DNS Query (from www.unixwiz.net)

Figure 1 shows a normal procedure of DNS query. Here, the client sends a DNS query for the site www.unixwiz.net. The local recursive nameserver doesn’t know the answer and asks to an other root server. It sends back the message with a referral to an other root server. Local server tries all the authoritative root servers, until it finds the closest name server which is in the same domain with the target site. Finally, it sends a query to that name server and receives back the IP address.

Cache Poisoning
The previous scenario was the way how a DNS query should be. The DNS server caches the A Record for future queries, but not forever, just for a while. This time interval is defined by the Time To Live (TTL) variable in the server configuration, and the only authorized person is the administrator of the DNS server. During TTL, each query for the same domain, will be answered from the local database. After the TTL passed, the record in the server database will be dropped and any query will cause a complete DNS cycle.

If our bad guy wants to redirect the innocent clients to his malicious site rather than the original “good one”, he has to change this local database entry with his fake data.

Indeed, it’s not so easy to send random DNS packets to the server. Because, DNS servers just allow the expected packets from other servers. And they have some specific messages between each other, that make the connection unique. Communication between servers is over UDP ports that the query (Question and Query ID of the DNS packet) was sent through.  So, the bad guy has to know these data to send a response to DNS server, which is like coming from an authoritative root server.

The method he used is, sending a query for the target site and replying his own query before the original root server will. Figure 2 shows this process over an example.

DNS Server Cache Poisoning (from www.unixwiz.net)

In this example, the bad guy sends a query to the DNS server for the target site www.bankofsteve.com. DNS server doesn’t know the IP address of this site and sends a query to a root server. The bad guy starts to flood at this point with increasing Query IDs. If he can find the true Query ID as fast as possible and sends back the poisoned DNS message to the victim name server with this Query ID, the DNS server accepts this response rather than the original one. In this example, the bad guy sends his malicious site’s IP address as a response of the original bank site query, before the bank’s original name server replies the query. The victim nameserver rejects the original nameserver’s response, because the Query ID will not be expected, after the bad guy sends the message by using this ID.

Dan Kaminsky Method for Cache Poisoning
In 2008, Dan Kaminsky who is a security researcher and Director of Penetration Testing for IOActive, found a way to poison not just the addresses one by one. He discovered a way to change the authority records too.

In this method, the basic idea is same with the early cache poisoning method, but there is a difference. The bad guy server floods the victim server with the response of the target site query and the authoritative record for the target domain. This means, the bad guy server becomes both the target site and the target name server.

How to Fix
The key point here is the Query ID. If the bad guy can not guess the Query ID, all the method collapses. But the problem is the number of Query IDs that DNS servers use. Old style DNS servers uses 16 bit Query IDs, which means 64k chance to find the ID number. So randomization of the Query ID is a solution. But it’s still feasible to find the ID by trying.

Increasing the Query ID bits may be a solution to this problem. But all the Internet infrastructure lies on the 16 bit DNS Query ID. So it’s impossible to change the Query ID structure.

The most effective way to solve this problem is randomizing both the Query ID and the ports. The client talks to a nameserver on port 53/tcp. And the nameservers talks to each other on random UDP ports with random Query IDs and finds the answer. And than, the nameserver answers back to the client on port 53/tcp.

By this way, finding the true Query ID and the port combination is a fat chance.

Conclusion
Today all the major DNS servers support the method above. The most common DNS servers, BIND and MS DNS server have already patched their software against this vulnerability.
The major Unix/Linux distributions such as RedHat, Gentoo and SuSE, have some security tools that scans the entire system against the vulnerabilities. Glsa-check tool of Gentoo Linux is one of them. It scans the system and updates the packets which are marked as insecure by the Gentoo Development Team. So being updated as fast as possible is the key point of being secure.

References
1.http://en.wikipedia.org/wiki/DNS_cache_poisoning
2.http://www.unixwiz.net/techtips/iguide-kaminsky-dns-vuln.html
3.http://bugs.gentoo.org/show_bug.cgi?id=231201
4.http://security.freebsd.org/advisories/FreeBSD-SA-08:06.bind.asc
5.http://www.softpanorama.org/DNS/dns_ports.shtml
6.http://www.doxpara.com/DMK_BO2K8.ppt

KDE4.2 üzerindeki maskenin kalkmasıyla beraber emerge yolları gözüktü yine. kde-testing overlay’i de çok güzel setler oluşturmuş. @kdebase-4.2 , @kdenetwork-4.2 gibi birçok set hazır halde geliyor. Geriye de

emerge @kdebase-4.2

demek kalıyor. kde-3.5 ile epey bağımlılık çakışması problemi oldu. Önceleri o da kalsın istedim ama kdelibs fena çakışıyor.

kdeprefix USE flag’ini kullanarak derledim. Kullanmadan yaptığım deneme hüsran ile sonuçlandı.
Bu da henüz tazecik kde4.2 masaüstüm.

Yeni KDE4.2 Masaüstüm

Evde kullandigim internet baglantisi bana biraz acayip geliyor. DHCP ile IP aldiktan sonra bir de ISP nin login sayfasina girip kullanici adi ve sifre ile login olmak gerekiyor. Bu tip baglantiya ne isim veriliyor hic bilmiyorum. Sorun su ki boot esnasinda DHCP sorgusu yapip IP almama ragmen firefox ile login sayfasina girip sifre girene kadar internete ulasamiyor olmak sinir bozucu. Ornegin NTP ile saat guncellemesi yapamiyorum bu durumda. Ya da en azindan gatget tarzi ufak uygulamalar desktop acildigi anda nete ulasamiyor ve sorunlarla karsilasiyorum. Login sayfasinin yapisi oldukca basit. Kullanici adi ve sifrenin girildigi basit bir form submit ediliyor. Bir kac sene once Sesli’de kullandigim Mechanize ile yine ayni yapiyi kullanarak ufak bir script hazirladim. Yine Perl ile. Zaten neredeyse Sesli’deki betigin aynisini kullandim denebilir.Perl ile parsing yapmayi bilsem bash script’e de hic gerek kalmayacak ama su anda onu ogrenmeye ne vaktim ne de hevesim var. Yine yalnizca kendi isimi gorecek, benden baska kimsenin ne ihtiyac duyacagi ne de deneyebilecegi birsey cikti ortaya.

#!/usr/bin/perl
use strict;
use WWW::Mechanize;
use HTTP::Cookies;
 
my $username = $ARGV[0];
my $password = $ARGV[1];
my $adres = "http://login.iam.ne.jp";
 
#çıktının yazılacağı dosya
my $linkfile = "out.html";
 
my $mech = WWW::Mechanize->new();
$mech->cookie_jar(HTTP::Cookies->new());
$mech->get($adres);
$mech->form_name('LoginUser');    #form adı LoginUser
$mech->field(username => $username);    #kullanıcı adının yazılacağı değişken username
$mech->field(passwd => $password);    #şifrenin yazılacağı değişken passwd
$mech->click();
 
my $link_page = $mech->content();
open(OUTFILE, ">$linkfile");
print OUTFILE "$link_page";
close(OUTFILE);

#!/bin/bash
#Degiskenleri tanimla
USER=kullanici-adim-buraya
PASS=sifrem-de-buraya
LINK=link.html
OUT=out.html
LOG=log
DIR=/home/tarik/login
 
cd $DIR
 
./gir $USER $PASS
 
export logintime=`cat $OUT | grep "Login Time"  | awk '{print $5 " " $6 " "  $7 " "  $8 $9 $10}' | cut -d '<' -f1`
 
if test "x$logintime" = x
then
echo "Connection Problem. User : $USER . "
echo "Check your settings!"
export errordate=`date`
echo "Failed  : $USER $errordate" >> $LOG
else
echo "Connection Established"
echo "Login Time : $logintime"
echo "Success : $USER $logintime" >> $LOG
fi

Ilk betigi “gir” ismiyle kaydedip ikinci betik icerisinden cagiriyorum. Baslikta da soyledigim gibi “Amele” programlama Login esnasinda calismasi icin de .bashrc’ye ekledim betigin yolunu. Aslinda en guzeli bir init script yazmak. Hemen net.eth0 ardindan kosacak bir init scripti daha mantikli. Bu yolla NTP update yapamam haliyle. O kismi hala sorunlu. Ama en azindan masaustu acildiginda internet calisir durumda oluyor. Bu da bir asama. Simdi bir problem daha kaldi. Evdeyken DHCP kullaniyorum. Ardindan yukaridaki betikle login olmam gerekiyor. Labda statik IP kullaniyorum. Okulun diger kisimlarinda Wireless kullaniyorum, yine DHCP. Bunlarin tumu icin ayri profiller olusturmam gerekiyor /etc/conf.d/net dosyasinda. Su anda gozume biraz karisik gozukuyor. Bu betigin de yalnizca evden baglanirken calisiyor olmasini istiyorum. Su anda hic icimden gelmiyor Belki yakinda duzgun bir ayar yaparim.

Labdaki Samba File Server’a erismek icin kullanici adi ve sifre aldim gecenlerde. Samba ayarlarim dogru olmasina ragmen ilk gunlerde sorunsuzca ulasabildigim workgroup simdilerde nedense ulasilamaz durumda. Bunu henuz cozebilmis degilim. Konqueror devamli “Unable to find any workgroups in your local network. This might be caused by an enabled firewall.” uyarisi veriyor smb:/ protokolunu kullandigim zaman. Bilgisi olan varsa yardimlarini beklerim. Konqueror’dan Lisa ayarlarini “Kendi IPm”/”Subnet Mask” seklinde yapinca file server’i gorup erisebiliyorum lan:// protokolu uzerinden. Fakat daha buyuk bir sorun daha var Dosya sunucusu uzerindeki cogu dosya ve klasor ismi Japonca yazilmis. Keza icerikleri de oyle Haliyle ilk etapta dosya isimlerini sacma sapan karakterler olarak gordum. Konquror, Tools menusunde “Select Remote Charset” isminde tam da benim sorunumu cozebilecek bir ayar gordum. Sevindim tabi hemen. Epey bi sevindirik oldum. Ta ki charset secene kadar. Konqueror dondu kaldi. Kill ettim. Tekrar actigimda sectigim charset set edilmisti. Ama halen karakterler duzgun degildi. Farkli charsetler icin “Sec / Konqueror donsun / Kill et / Tekrar ac / Olmasin” kombinasyonunu defalarca denedim. Gentoo Bugzilladan baktim, sanirim Gentoo’ya has bi bug bu. Neden sonra Samba Charset ayarlarini degistirmek geldi aklima. Aradim taradim, birkac ufak bilgi bulabildim. En cok da su adresteki HOWTO isime yaradi. Kisacasi; Display Charset :CP932 Unix Charset :UTF-8 DOS Charset :CP932 olarak ayarlamak gerekiyor. smb.conf dosyasini da asagidaki sekilde duzenleyince herkes mutlu oldu sonsuza kadar mutlu yasadi.

[global]
restrict anonymous = no
domain master = no
preferred master = no
workgroup = KLAB
max protocol = NT
acl compatibility = winnt
ldap ssl = No
server signing = Auto
display charset = CP932
dos charset = CP932
wins server = XX.XX.XX.XX (gizli bu soylenmez)

Japanese Samba File Server by Konqueror

Yeni öğrendiğim ve işleri pratikleştirebilecek bir ipucunu paylaşmak istiyorum. Portage’da paket maskelerini kaldırmak için hepimizin bildiği üzere package.unmask ve package.keywords dosyalarını kullanıyoruz. Yine çok iyi bildiğimiz gibi bunlar /etc/portage altında bulunuyor. Madem biliyoruz daha ne değil mi?

Bilmediğim şey şuydu ki, /etc/portage altına package.unmask ve package.keywords isimlerinde dizinler oluşturarak bunların altında ister ayrı ayrı dosyalarda ister ayrı dizinler altında yine ayrı dosyalarda, dosyaların isimlerinden bağımsız olarak unmask işlemi yapılabiliyormuş. Bu ne demek şimdi?

Kararsız bir paket derlemek istediğimizde beraberinde gelecek olan onlarca maskeli paketi package.keywords dosyamıza değil de /etc/portage/package.keywords/kararsizpaket isimli bir dosyaya ekleyip derleme işlemini yapabilir, ardından da maskeleri tekrar açmak istediğimizde kararsizpaket isimli dosyayı silebiliriz.

Normalde aynı işlemi package.keywords dosyasına gruplar halinde ekliyor, her grubun başına comment ekleyerek grubun maskesini neden kaldırdığımı not düşüyordum. Yeni yöntem, takip etmesi biraz daha kolay göründü bana. Bu arada Portage versiyonum 2.1.4.4. Önceki versiyonlarda desteklenip desteklenmediği hakkında bir bilgim yok.

Bir ipucunun daha sonuna geldiğimiz şu dakikalarda, sağlık ve esenlikler diliyorum.

Ya da dilemiyorum.