NTFS Filesystem support on Linux

Ubuntu တို႕ Fedora တို႕မွာေတာ့ NTFS support က အစကတည္းကပါလာလိမ့္ရွိပါတယ္။ ဒါေတာင္တခါတစ္ေလၾက read ပဲရျပီး write မရပဲျဖစ္တက္ေသးတယ္။ က်ေနာ္က CentOS အသုံးမ်ားေတာ့ CentOS မွာက NTFS write support မပါတက္ဖူး။ Kernel recompile ရင္ေတာ့ရေပမယ့္ NTFS write ေလးရဖို႕ kernel ေတာ့ recompile မလုပ္ခ်င္ဖူး။ NTFS read/write ရေအာင္ NTFS-3G ဆိုတယ့္ FS module ရွိတယ္။ RPMforge repository မွာရွိပါတယ္။ လြယ္လြယ္ကူကူ အဲဒါေလးပဲ install လိုက္တာေကာင္းပါတယ္။

အရင္ဆုံး rpm-forge repo ကို yum repo ထဲမွာထဲ့ဖို႕လိုပါတယ္။ ဒါမွ yum နဲ႕ install လုပ္ရင္ သူ႕ဟာသူ dependency resolving လုပ္သြားမွာ။ မဟုတ္ရင္ ကိုယ့္ဟာကိုယ္ dependency ေတြ install ေနရမယ္။ CentOS လို႕ယူဆျပီးပဲ ေျပာပါမယ္။ ဒါေပမယ့္ RPM အလုပ္လုပ္တယ့္ Linux တိုင္းမွာ ရမွာပါ။

1. rpmforge rpm ေလးအရင္ download မယ္။ (wget ကေတာ့ ရွိျပီးသားလို႕ ယူဆလိုက္ပါတယ္။ မရွိရင္ေတာ့ wget အရင္ သြင္းပါ။)

#wget http://apt.sw.be/redhat/el5/en/i386/RPMS.dag/rpmforge-release-0.3.6-1.el5.rf.i386.rpm

2. GPG key import လုပ္မယ္။ မဟုတ္ရင္ RPM ကို install လုပ္လို႕မရပဲျဖစ္ေနပါလိမ့္မယ္။ 3rd party RPM ျဖစ္ေနလို႕ပါ

#rpm --import http://dag.wieers.com/rpm/packages/RPM-GPG-KEY.dag.txt

3. RPM ကိုအရင္စစ္

#rpm -K rpmforge-release-0.3.6-1.el5.rf.i386.rpm

4. RPMforge repo install လုပ္မယ္

#rpm -i rpmforge-release-0.3.6-1.el5.rf.i386.rpm

ဒီလို လုပ္လိုက္ျခင္းအားျဖင့္ ေနာက္ install လုပ္တိုင္း CentOS repo က တင္မဟုတ္ပဲ RPMforge repo ကပါ package ေတြကိုရွာပါလိမ့္မယ္။

5. RPMforge repo မွာရွိတယ့္ package ေတြရဲ့ list ကို အရင္ build လုပ္ရပါအုန္းမယ္။

#yum check-update

6. Kernel version ေလး တစ္ခ်က္ ၾကည့္ရေအာင္။ ဒါအေရးၾကီးပါတယ္။ Kernel version နဲ႕ kernel-devel version က တူဖို႕လိုပါတယ္

#uname -r

7. Kernel-devel install လုပ္မယ္။

#yum install kernel-devel

တကယ္လို႕ Kernel devel နဲ႕ Kernel နဲ႕ version မတူရင္ kernel ပါျပန္ install လုပ္ျပီး restart တစ္ခါခ်ရပါလိမ့္မယ္။ Kernel အသစ္နဲ႕ boot လုပ္ျပီးမွ က်န္တာ ဆက္လုပ္ပါ။

8. လိုအပ္တယ့္ Package ေတြကို တစ္ခါထဲ install လုပ္ရေအာင္

#yum install fuse fuse-ntfs-3g dkms dkms-fuse

9. NTFS partition ကို Linux ေပၚမွာ mount လို႕ရပါျပီ

#mount -t ntfs-3g /mount_point /windows_partition

Mount point ကေတာ့ ကိုၾကိဳက္ရာနဲ႕ အစားထိုးေပါ့။ အစကတည္းက ၾကိဳျပီး create မထားရင္လည္း အခု create လို႕ရပါတယ္။ Windows partitions ကိုမသိရင္ေတာ့ fdisk နဲ႕ၾကည့္ပါ။

#fdisk -l

ၾကလာတယ့္ table ထဲက NTFS file system နဲ႕ partition ကိုမွတ္ထား။ ဆိုၾကပါေတာ့ /dev/hda2 ဆိုရင္ အေပၚက /windows-partition ေနရာမွာ /dev/hda2 ကို အစားထိုးလိုက္ပါ။ စမ္းၾကည့္ပါ အဆင္ေျပမွာပါ။


Divinity

Server Clustering ဆိုတာ . . . (2)

Clustering မွာ ဘယ္လိုအဆင့္ေတြရွိလည္း ?
ေခါင္းစဥ္က သိပ္မကြဲပါဘူး။ ျမန္မာစာ ပညာရွိမဟုတ္ေတာ့ စကားလုံးေရြးရတာ တခါတေလ မလြယ္ဘူး။ Clustering မွာ ဘယ္လို level အလိုက္ရွိလည္းလို႕ေျပာရင္ ပိုေကာင္းမယ္။
1. Network Level Clustering
2. Service Level Clustering
3. Application Level Clustering ဆိုျပီး ေယဘူရအားျဖင့္ သုံးခုရွိပါတယ္။ Failover ပံုစံအလုပ္လုပ္မလား၊ NLB အလုပ္လုပ္မလားဆိုတာက ဘယ္လို Setup လုပ္လည္းဆိုတာေပၚမွာ မူတည္ပါတယ္။ ဘယ္လို Level clustering မွာမဆို ႏွစ္မ်ိဳးလုံး ( တစ္မ်ိဳးမဟုတ္ တစ္မ်ိဳး) setup လုပ္ဖို႕ျဖစ္ႏိုင္ပါတယ္။

Network Level Clustering ( Vs Service Level Clustering)
သူကရွင္းပါတယ္။ တကယ္လို႕ Cluster ထဲမွာ Server 5 လုံးရွိတယ္ဆိုပါေတာ့။ ဒီ Server ငါးလုံးက အခ်င္းခ်င္း Network reachability ကို စစ္ေနပါတယ္။ Engineer က configure လုပ္ထားသလို 5 seconds ဆိုလည္း 5 seconds တိုင္းမွာ၊ 5 minutes ဆိုလည္း 5 minutes တိုင္းမွာ စစ္ေနပါတယ္။ Network reachability ဆိုတာကေတာ့ က်ေနာ္တို႕ ping ၾကည့္သလိုေပါ့။ ကိုယ္သုံးတယ့္ clustering technology ေပၚမွာမူတည္ျပီး ဘယ္လိုစစ္ေနလည္းဆိုတာေတာ့ ကြာပါလိမ့္မယ္။ တကယ္လို႕ unreachable ျဖစ္သြားျပီဆိုရင္ အဲ Server down သြားျပီလို႕ ယူဆျပီး Server ကို Cluster ထဲကေနဖယ္လိုက္ပါတယ္။ ဒီ Clustering ရဲ့ အားနည္းခ်က္ကေတာ့ Server ၾကီးက မ down ဘူး၊ Server ေပၚက Service ကပဲ down ေနရင္ သူမသိပါဘူး။ သူက Network အရ ping ၾကည့္လို႕ ဒီ Server alive ရွိမရွိ စစ္တာမ်ိဳးပဲစစ္ျပီး ဆုံးျဖတ္လို႕ Network Level Clustering လို႕ေျပာတာပါ။

ဥပမာ စဥ္းစားၾကည့္ရေအာင္။ Windows Server 2003 မွာ Windows NLB Manager ဆိုတာ ပါပါတယ္။ သူက Network Level Clustering ပါ။ NLB ပံုစံ Clustering ပါ။ Server သုံးလုံးကို IIS web server run ျပီး Cluster လုပ္လိုက္ၾကတယ္ဆိုပါေတာ့ ။ User က Access လုပ္ရင္ Server သုံးလုံး တစ္လွည့္စီ respond လုပ္ေနမွာေပါ့။ တကယ္လို႕ Svr 1 က hang သြားတယ္ ဆိုပါေတာ့ ၊ ဒါမွမဟုတ္လည္း network ၾကိဳးလြတ္သြားတာပဲျဖစ္ျဖစ္၊ ဒါမ်ိဳးဆိုရင္ Svr 1 down သြားတာကို က်န္တယ့္ Sever ႏွစ္လုံးက သိပါတယ္။ လာသမွ် user ကို Svr 2 နဲ႕ 3 ကပဲ မွ်ျပီး respond လုပ္ပါလိမ့္မယ္။

ဒါေပမယ့္ တကယ္လို႕ Server 1 ၾကီးက ဘာမွမျဖစ္ဖူး ၊ IIS ကပဲ crash ျဖစ္ျပီး stop ျဖစ္သြားတယ္။ ဒီလို scenario မွာ က်န္တယ့္ Server ႏွစ္လုံးက မသိပါဘူး။ Network aspect အားျဖင့္ Server 1 က alive ရွိေနပါတယ္။ IIS Service down သြားတာ ၊ ဒီ Network Level Cluster မွာ ဒါကို မသိပါဘူး။ ဒါဆို ဘာျဖစ္မလည္း ? Cluster က Svr1 down ေနတာကို မသိတယ့္အတြက္ request 3 ခါမွာ တစ္ခါကို ထုံးစံအတိုင္း Svr1 ဆီကို ပို႕ေနပါလိမ့္မယ္။ ဒါေပမယ့္ IIS ၾကီးက down ေနေတာ့ သုံးခါမွာ တစ္ခါ error ျပေနမွာေပါ့။ Reload လုပ္လိုက္ရင္ ျပန္ေကာင္းသြားျပန္ေရာ။

ဒါဆိုဘယ္လိုလုပ္မလည္း ? Service Level ကိုပါ monitor လုပ္ႏိုင္ဖို႕လိုပါတယ္။ Windows ရဲ့ built-in ေတြမွာေတာ့ မေတြ႕မိပါဘူး။ က်ေနာ္မသိတာလည္းျဖစ္ႏိုင္ပါတယ္။ Linux မွာေတာ့ heartbeat version 2 တို႕ LDirector တို႕ေတာ့ Opensource ေတြရွိပါတယ္။ သူတို႕က Service port ကိုပဲျဖစ္ျဖစ္ Service ကိုတစ္နည္းနည္းနဲ႕ စစ္ေပးျပီး Service down ရင္လည္း Server down တယ္လို႕ သတ္မွတ္ျပီး Cluster ထဲကေန isolate လုပ္ေပးလိုက္ပါတယ္။

API ေတြနဲ႕ခ်ိတ္ဆက္ျပီး Application တစ္ခု Process တစ္ခုကို Server ေတြအမ်ားၾကီးေပၚမွာ ခြဲေဝျပီး အလုပ္လုပ္တယ့္ Application Level Clustering ကေတာ့ က်ေနာ္ ေသခ်ာမရွင္းႏိုင္တယ့္ အေၾကာင္းအရာမို႕ ေက်ာ္လိုက္ပါရေစ။

Divinity

Auto Increment ID

တစ္ခါတစ္ေလ ဒီလိုမ်ိဳးေလးမလား ၾကံဳဖူးမလားမသိဘူး။

Database Table ႏွစ္ခုရိွတယ္ဆုိပါေတာ႔။

Hibernate မသံုးတဲ႔ ရိုးရုိး ကိစၥေလးေတြမွာေျပာတာပါ။

ပထမ table ကို TableA လုိ႕ထားပါေတာ႔။

ဒုတိယ table က TableB. TableA မွာ Id က auto increment လုပ္ထားတယ္။

ရိုးသားၾကိဳးစားတဲ႔ DB Admin က normalize ေသခ်ာလုပ္ထားတဲ႔အတြက္ TableA ရဲ႕ primary key က TableB မွာ Foreign key အျဖစ္နဲ႕ ရိွပါတယ္။ ကြ်န္ေတာ္တို႕လုပ္ရမွာက Table A မွာ record တစ္ခုထည္႕လုိက္ျပီးတုိင္း TableB မွာ အဲဒီ ID ကို Foreign key အေနနဲ႕သံုးထားတဲ႔ ေနာက္ထပ္ Record တစ္ခုကို ထည္႕ရပါမယ္။

နမူနာပံုေလးကို ၾကည္႕ပါ။

Table A

ID Name NRIC

1 Zero 140222

Table B

ID ---- TableA_ID ----- Address

1 -------- 1 ---------------- Eunos Rainbow

အဲဒီလို record တစ္ေၾကာင္းစီ ထည္႕ခ်င္တာပါ။ ကြ်န္ေတာ္ေျပာခ်င္တာက Table A ကို row တစ္ခု insert လုပ္တာက ငွက္ေပ်ာသီး အခြံႏႊာတာထက္လြယ္ပါတယ္။ ေနာက္ေတာ႔ ID ကို ျပန္ရွာရတာက ပ်င္းစရာေကာင္းပါတယ္။ Select ျပန္လုပ္ရင္ရေပမယ္႔ ပ်င္းပါတယ္။ အဲဒီလို မလုိအပ္တဲ႔ code ေတြေရးမယ္႔အတူတူေတာ႔ ဘာလို႕ Developer လုပ္မွာလဲ ... ေဆာ႔ခေရတၱိေခတ္က စာကူးတဲ႔သူသြားလုပ္ေနမွာေပါ႔။ အဲဒီလုိ ငပ်င္းေတြအတြက္ တစ္ခုလုပ္လုိ႕ရတာရိွပါတယ္။ auto increment လုပ္ထားတဲ႔ ID ကို ျပန္ယူလိုက္လုိ႕ရပါတယ္။ စိတ္ခ်မ္းသာစရာေကာင္းပါတယ္။ မဟုတ္ရင္ ေနာက္တစ္ခါ သြား select လုပ္ရတဲ႔အတြက္ connection လည္းေျခေထာက္ေညာင္းမွာပဲ။ လူအေယာက္ တစ္သန္းသံုးတဲ႔ System မွာဆို အခ်ိန္အမ်ားၾကီးကုန္သြားမယ္။ ေလးငါးဆယ္ေယာက္ေလာက္သံုးဖုိ႕အတြက္ေတာ႔ System မလုိပါဘူး။ လက္နဲ႕ပဲ ေကာက္ေရးထားလုိက္ရင္ ရတာပါပဲ။ ပံုမွန္ အားျဖင္႔ Developer တစ္ေယာက္ဟာ database ကို တတ္ႏိုင္သေလာက္ အသြားအလာေလွ်ာ႔ရပါမယ္။ တစ္ခါသြားျပီး အကုန္ယူလုိ႕ရတာ ယူႏိုင္ရပါမယ္။ မယူႏုိင္ဘူးဆိုရင္ ကိုယ္႔ SQL ကို ျမွင္႔တင္ဖုိ႕လိုပါတယ္။ မဟုတ္ရင္ သြားတယ္ျပန္တယ္...ျပန္သြားတယ္ ထပ္သြားဦးမယ္ဆိုရင္ System ကေလးတယ္ ပိုေလးတယ္ ...အလုပ္မလုပ္ေတာ႔ေလာက္ေအာင္ေႏွးတယ္၊ DB sever ရဲ႕ CPU က ၁၀၀ရာခုိင္ႏႈန္း ကေနကို ျပန္က်မလာေတာ႔ဘူး။ အဲဒါမ်ဳိဳးေတြျဖစ္မယ္။ အဲဒီလိုေျပာင္ေျပာင္ေျမာက္ေျမာက္ ဒုကေပးတတ္တဲ႔ ခပ္ညံ႕ညံ႔ developer ေတြရဲ႕ code ကို boiler-plate code ေတြလုိ႕ေခၚပါတယ္။ maintain လုပ္ရတဲ႔သူကေတာ႔ ေမတၱာ အၾကိမ္ၾကိမ္ပို႕မွာ အေသအခ်ာပါပဲ။

အင္း ... အဲဒီ auto increment id ေလးျပန္ယူတာေလးေရးၾကည္႕ပါမယ္။

PreparedStatement pst = conn.prepareStatement(sQuery,Statement.RETURN_GENERATED_KEYS);

ResultSet rs = pst.getGeneratedKeys();

rs.next();

autoId = rs.getInt(1);

အဲဒီလိုေလးေရးလုိက္ရင္ autoId ကို ေနာက္တစ္ခါ ထပ္သြားမယူဘဲ သိရပါတယ္။ အသြားအလာ သက္သာသြာပါတယ္။ ေျခေထာက္မေညာင္းေတာ႔ပါဘူး။ အဲဒီ autoId ေလးကို ေကာက္ျပီး ဒုတိယ TableB မွာ insert လုပ္လုိက္ပါ။ မ်ားမ်ားစဥ္းစားျပီးနည္းနည္းပဲ အလုပ္လုပ္ပါ။ လြယ္တဲ႔နည္းေတြ ထြင္ထားျပိးသားရိွပါတယ္။ မ်ားမ်ားေလ႔လာျပီး သက္သာေအာင္ေနပါ။

သိပ္ပ်င္းတဲ႔သူေတြပဲ ထူးခြ်န္ႏိုင္တယ္။

try and error နည္းက လူပင္ပန္းသေလာက္ အက်ိဳးမရိွဘူး။ တြက္ေျခမကိုက္ဘူး။

work hard ဆိုတဲ႔စကားလံုးကို Developer ေတြမွာမသံုးပါဘူး။ Work smart လုိ႕ပဲ သံုးပါတယ္။ ပ်င္းတဲ႔သူဟာ Smart ၾကတဲ႕နည္းေတြအမ်ားၾကီးသိပါတယ္။ work hard ၾကီးေတြကို လူၾကီးေတြက ခ်ီးက်ဴးပါတယ္။ Work Smart ေတြကိုေတာ႔ ေလးစားၾကပါတယ္။ သက္သက္သာသာေလး ေလးစားခံထုိက္တဲ႔သူေတြျဖစ္ေအာင္ ၾကိဳးစားႏိုင္ၾကပါေစ။

Commit and Rollback

ဆုိၾကပါေတာ႔ ...။

လူတစ္ေယာက္က ပစၥည္းတစ္ခုကို ၀ယ္တယ္။

Discount ရတယ္။

ကံစမ္းမဲအတြက္လည္း သူ႕စာရင္းကို သြင္းတယ္။

Database View နဲ႕ Table သံုးခုလို႕ပဲ ယူဆလုိက္ပါ။

ပစၥည္း၀ယ္ေတာ႔ Purchase ဆိုတဲ႔ table မွာ တစ္ေၾကာင္း၊

Discount ရေတာ႔ Discount table မွာ တစ္ေၾကာင္း၊

Lucky Draw အတြက္ Lucky Draw table မွာတစ္ေၾကာင္း စုစုေပါင္း table သံုးခုမွာ record row သံုးေၾကာင္း insert လုပ္တယ္ဆုိပါေတာ႔။

ျဖစ္ခ်င္ေတာ႔ အင္တာနက္ၾကီးက လမ္းခုလတ္မွာေဒါင္းသြားတယ္ဆိုပါေတာ႔။Purchase table မွာ ပဲ insert လုပ္ရေသးတယ္။ Discount ေတြ၊ Lucky Draw ေတြမွာ record မေရးခင္လည္း interrupt ျဖစ္တယ္ဆုိပါေတာ႔။ ဘယ္လုိလုပ္မွာလဲ။ ဒီအတိုင္းထားလုိက္ရင္ေတာ႔၊ သူ႕အတြက္ Discount လည္းမရ၊ Lucky Draw လည္းမရတဲ႕ Customer က ဒီ Shopping Mall ၾကီးကို စိတ္အနာၾကီးနာေနေတာ႔မွာ။

လူတစ္ေယာက္တည္းျဖစ္သြားတယ္ဆိုရင္ သိပ္မသိသာဘူး။ အေယာက္ ႏွစ္ေသာင္းေလာက္ တစ္ျပိဳင္နက္၀ယ္ေနုတုန္းျဖစ္တယ္ဆိုပါေတာ႔ ....။ဟဲဟဲ ....။ ေနာက္ဘယ္ေတာ႔မွလာမ၀ယ္ေတာ႔ဘူးဆို မခက္ဘူးလား။

လူေတြလည္း သီးခ်ိန္တန္သီးပြင္႔ခ်ိန္တန္ပြင္႔ရသလို ... prepared statement ေတြလည္း commit ခ်ိန္တန္ commit ...rollback ခ်ိန္တန္ rollback ရတယ္။ အဲဒါဆို ... half way ျဖစ္ေနတဲ႔ process က rollback ျပန္လုပ္လုိက္တဲ႔အတြက္ တစ္၀က္တစ္ပ်က္ျဖစ္မေနေတာ႔ဘူး။ ေနာက္တစ္ခု ျပန္ျပီး upload လုပ္လုိက္ရံုပဲ။ ဒါကလည္း အျမဲတမ္းဂရုစိုက္ရမယ္႔အခ်က္ျဖစ္ပါတယ္။

ဘယ္ေနရာမွာပဲလုပ္ေနလုပ္ေန Java Developer တစ္ေယာက္ဟာ အျမဲတမ္း standard က်တဲ႔ procedure နဲ႕ ေရးဖုိ႕ ၾကိဳးစားေစခ်င္ပါတယ္။ ကိုယ္ေရးထားတဲ႔ codes ကို သိၾကားမင္း ဆင္းျပီး bug လုပ္ေတာင္ မရဘူးကြ ဆိုတာမ်ိဳး ေရးႏို္င္ဖုိ႕ၾကိဳးစားရပါမယ္။ အထူးသျဖင္႔ မေရးခင္ အားလံုး ကို စဥ္းစားပါ။ ေပ်ာ္ေပ်ာ္ၾကီး ခ်မေရးခ်င္ သူ႕ရဲ႕ business logic ကို flow chart ေလးျဖစ္ျဖစ္ အၾကမ္းဆြဲထားလိုက္ပါ။ စာရြက္နဲ႕ျဖစ္ျဖစ္ေပါ႔။ ဒါဆို ဘာေတြ ၾကံဳရႏိုင္လဲဆိုတာကို ပိုသိလာပါလိမ္႔မယ္။ တစ္ခု process ေတြကို scenario တစ္မ်ိဳးထဲမွာ ၾကိတ္ျပီးစဥ္းစားျပီး ေပ်ာ္မေနပါနဲ႕။ တကယ္႔ေလာကၾကီးက ကိုယ္ေတြးထားတာေလးပဲျဖစ္မယ္လုိ႕ အာမမခံထားပါဘူး။

အၾကမ္းဖ်င္းေျပာရရင္ commit အတြက္ autoCommit ကို false ေပးထားပါ။

connection တစ္ခုထဲကိုပဲ parameter အေနနဲ႕ parse လုပ္သြားျပီး table သံုးခုစလံုးကို insert လုပ္ပါ။

အားလံုးျပီးရင္ အဲဒီ connection ကို commit လုပ္ပါ။

exception ျဖစ္ရင္ rollback ျပန္လုပ္လုိက္ပါ။ အဲဒါဆိုရင္ေတာ႔ စိတ္ခ်ရသေလာက္ရိွပါျပီ။

Java Developer ေတြဟာ ငပ်င္းေတြျဖစ္ပါတယ္။

Codes တစ္ခုကို တစ္သက္လံုး ႏွစ္ခါျပန္မေရးပါဘူး။

Reusable ျဖစ္ေအာင္ေရးျပီး ဘယ္ေနရာမွာမဆို ျပန္သံုးလုိ႕ရေအာင္ ေရးရပါတယ္။

Process တစ္ခုကို Method တစ္ခုေရးျပီး ကိုယ္႔ကိုယ္ကို သက္သာေအာင္ေနပါ။

လူအမ်ားနဲ႕ေရးတဲ႔အခါ ... ကိုယ္႔ codes ေတြလူမ်ားၾကည္႕ျပီး ထုိင္မငိုပါေစနဲ႕ ...။

ႏွစ္ခါသံုးခါ ေရးရမယ္႔ method ေတြကို သပ္သပ္ခြဲထုတ္ထားလုိက္ပါ။ Eclipse မွာ ctrl+click ေခါက္ျပီး လုိက္ၾကည္႕လုိ႕ရပါတယ္။ ကိုယ္႔အတြက္ အဆင္ေျပေအာင္ေရးပါ။ နားမလည္မွာစိုးရင္ Comment ေတြကို သပ္သပ္ရပ္ရပ္ေရးပါ။ ျဖစ္ႏုိင္ရင္ comment ကို ရွည္ရွည္ေရးျပီး အၾကမ္းဖ်င္းရွင္းျပပါ။ ဒါဟာ ေနာက္လူအတြက္ သိပ္ေကာင္းပါတယ္။ ေရွ႕က ေရးသြားတဲ႔သူ ညံ႕တိုင္း လုိက္မညံ႕တဲ႔ developer ျဖစ္ႏိုင္ပါေစ။

ွ

အခုေရးထားတဲ႔ post ေလးက သီအိုရီ အေနနဲ႕ပဲေျပာထားပါတယ္။

တကယ္လည္းေရးၾကည္႕ၾကပါမယ္။ အခုလည္း hosting အတြက္ စဥ္းစားေနပါတယ္။ ရံုးက Server တစ္လံုးမွာ host လုပ္ျပီးေရးရင္လည္း illegal ျဖစ္ေနမယ္ ....။

ဘာပဲျဖစ္ျဖစ္ပါဗ်ာ ...။ ကြ်န္ေတာ္တို႕ေတြ ပိုေတာ္တဲ႔ ညီငယ္၊ညီမငယ္ေလးေတြ ဖတ္ႏိုင္ ေလ႔လာႏိုင္ဖို႕ အမ်ားၾကီးေရးျဖစ္မွာပါ။

ျမန္မာေတြဟာ well-educated ေတြဆိုတာကို ကြ်န္ေတာ္တို႕ သက္ေသျပခ်င္ပါတယ္။ ဒီလိုသက္ေသျပႏုိင္ဖို႕ ကြ်န္ေတာ္တို႕ေတြ အားလံုး ၾကိဳးစားေနၾကပါတယ္။

ကိုယ္႔အတြက္ ဘာမွမဟုတ္တာေလးေတြဟာ လုိအပ္ေနတဲ႔ တစ္ေယာက္ေယာက္အတြက္ အဆင္ေျပသြားတာမ်ိဳးျဖစ္သြားႏိုင္တယ္ဆိုကို ယံုၾကည္တဲ႔အတြက္ ဒီထက္ ပိုေကာင္းတဲ႔၊ ပိုစနစ္က်တဲ႔ သင္ခန္းစာေတြနဲ႕ ေဆြးေႏြးမႈေတြကိုလည္း ဆက္ျပီး ေရးသြားပါဦးမယ္။

Java in Linux

Java in Linux

အေသးအဖြဲေလးႏွစ္ခုေျပာမလုိ႕ပါ။

တခါတေလ ... Java Servlet အေဟာင္းေတြကို ဟိုေရႊ႕ဒီေရႊ႕လုပ္ေနရတဲ႔အခါ ...မေတာ္လို႕မ်ား Linux ေပၚကို ေရႊ႕ရတဲ႔အခါၾကရင္ ... တစ္ခါတစ္ေလ Servlet ကေန ရိုက္ထုတ္လုိက္တဲ႔ html ေတြက html လုိမေပၚဘဲ text ေတြလိုေပၚေနတတ္ပါတယ္။ မေၾကာက္သြားပါနဲ႕ ...။ ပထမဆံုးလုပ္ရမယ္႔အလုပ္က အရင္က Developer ကို တစ္ခါေလာက္ဆဲပါ။ ... ျပီးရင္ response.setContentType("html/text") လုပ္ထားသလားစစ္ပါ။ .. အသံုးမက်တဲ႔ငနဲတစ္ခ်ိဳ႕ဟာ response type ကို ထည္႕ထားေလ႔မရိွပါဘူး။ Window မွာလို ... Linux မွာ သူ႕ဘာသာသူသိမယ္ လို႕ အယူမလြဲပါနဲ႕။ Linux မွာ File extension မရိွလို႕ သူက မသိပါဘူး။ Content type ကို response လုပ္မွပဲ သူသိပါလိမ္႔မယ္။ ဒါက ၾကံဳရတတ္တဲ႔ ၾကံၾကံဖန္ဖန္တစ္ခုပါ။

ေနာက္တစ္ခုရိွပါေသးတယ္။

Java ဟာ Garbage Collection အတြက္ အမ်ားၾကီးျပဳျပင္ထားျပီးသား language ျဖစ္ပါတယ္။ ဒါေပမယ္႔ ...လက္ေတြ႕မွာ ထင္သလိုမျဖစ္တာေတြလည္း ရိွပါတယ္။ con.close() နဲ႕ပိတ္လုိက္ေပမယ္႔ Linux မွာ ပိတ္သာပိတ္တယ္ ... အဲဒီ connection ကို destroyed မလုပ္လုိက္တဲ႔အခါမ်ိဳးမွာ ... မထင္မွတ္တဲ႔ Multiple Connections Errors ေတြေတြ႕ရတတ္ပါတယ္။ ေပ်ာ္ေပ်ာ္ပါးပါးတစ္ခုလုပ္လိုက္ပါ။ con=null; ဆိုျပီး con.close(); အျပီးေတြနဲ႕ Exception handling ေတြမွာ ထည္႕ေပးလိုက္ရင္ အိုေကသြားပါတယ္။

Linux မွာ Java ကို cron နဲ႕ run တာေလးေတြလည္းေရးဖုိ႕ရိွပါေသးတယ္။

ဒီမွာေရးေနၾကတဲ႔ သူေတြက အျပင္းစားေတြမဟုတ္ဘဲ အပ်င္းစားေတြျဖစ္ေနပါတယ္ ....။ ပံုေတြနဲ႕ ေရးပါဦးမယ္ဆိုတဲ႔သူေတာင္ ပံုဆြဲရမွာပ်င္းတယ္ဆိုျပီး ငိုက္ေနတာေတြ႕ပါတယ္။

ဒီ blog ကို ပိုျပီး active ျဖစ္ေအာင္လုပ္တဲ႔အေနနဲ႕ .. Java သင္ခန္းစာေတြပါ တင္ဖုိ႕ စိတ္ကူးေနပါတယ္။

သင္တန္းတက္ဖုိ႕အခ်ိန္မရတဲ႔ ၀ါသနာရွင္ေတြအတြက္ပါ ....။ Setup လုပ္တာေတြ အားလံုး တစ္ဆင္႔ခ်င္း လုပ္ၾကည္႕ၾကတာေပါ႔ ...။ ေပ်ာ္စရာေကာင္းပါတယ္။ ၀ါသနာပါရင္ေပါ႔ေလ။

စာေရးမယ္ေျပာထားျပီး အခုအထိ မေရးေသးတဲ႔သူေတြကိုလည္း warning ထပ္ေပးပါတယ္။ ...

With Regards,

Zero Div Zero=Zero

Server Clustering ဆိုတာ . . . (1)

Clustering ဆိုတာ ဘာလည္း ?
ႏွစ္လုံး သို႕မဟုတ္ ႏွစ္လုံးထက္ပိုတယ့္ Server ေတြ၊ ဒါမွမဟုတ္လည္း Computer ေတြဟာ Application တစ္ခု ( တနည္းအားျဖင့္ အလုပ္တစ္ခု) ကို အတူတကြ အလုပ္လုပ္ၾက ၊ serve လုပ္ၾကတာျဖစ္ပါတယ္။ website ေတြ လူသုံးအလြန္မ်ားလာတာမ်ိဳး ၊ database ေတြ query access အလြန္မ်ားလာတာမ်ိဳးၾကရင္ Server တစ္လုံးထဲနဲ႕ ျပန္ျပီး respond လုပ္ဖို႕ မႏိုင္ေတာ့ပါဘူး။ Server ေတြခြဲျပီး Cluster လုပ္လိုက္ခ်င္းအားျဖင့္ ပိုေကာင္းတယ့္ respond time ကိုလည္းရႏိုင္သလို ၊ Server တစ္လုံးလုံးမွာ network error ပဲျဖစ္ျဖစ္ hardware failure ပဲျဖစ္ျဖစ္ ( HDD ပ်က္သြားတာမ်ိဳး) တစ္ခုခုျဖစ္ရင္ Site တစ္ခုလုံး ၊ Database တစ္ခုလုံး ရပ္သြားျခင္းမွလည္း ကာကြယ္ႏိုင္ပါတယ္။

Clustering လုပ္တဲ့ ပံုစံ အမ်ိဳးမ်ိဳးရွိပါတယ္။ Cluster တစ္ခုမတည္ေဆာက္ခင္မွာ ကိုယ့္ရဲ့ လိုအပ္ခ်က္ ေပၚမွာ မူတည္ျပီး ဘယ္လို Clustering မ်ိဳးလုပ္မလဲဆိုတာ ဆုံးျဖတ္ရပါတယ္။ ေယဘူရ အားျဖစ္ေတာ့ Clustering ပံုစံ ႏွစ္မ်ိဳးရွိပါတယ္။

Failover cluster
Server ႏွစ္လုံးရွိေနမယ္၊ တစ္လုံးက down သြားရင္ ေနာက္တစ္လုံးက ခ်က္ခ်င္း ပထမ server ေနရာကိုယူျပီး respond ဆက္လုပ္ေနတာမ်ိဳးပါ။ User ေတြဘက္ကၾကည့္ရင္ Server တစ္လုံး down သြားတာ သိလိုက္မွာမဟုတ္ပါဘူး။ Active - Passive setup လို႕လည္း ေခၚပါတယ္။

ဥပမာ WebSvr1 နဲ႕ WebSvr2 ဆိုၾကပါဆို႕။Server ႏွစ္လုံးစလုံးက www.example.org ဆိုတဲ့ Website ကို host လုပ္ထားတယ္ ဆိုပါေတာ့။ ပံုမွန္အားျဖင့္ WebSvr1 ကပဲ respond လုပ္ပါတယ္။ User 1 က www.example.org လို႕ surf လုပ္ရင္ WebSvr1 ကပဲ respond ျပန္သလို၊ User 2 က www.example.org လို႕ surf ရင္လည္း WebSvr1 ကပဲ respond လုပ္ပါတယ္။ WevSvr1 အေၾကာင္းတစ္ခုခုေၾကာင့္ down သြားရင္ေတာ့ WevSvr2 က အစားထိုးဝင္ေရာက္ျပီး User 1 နဲ႕ User 2 ကို respond လုပ္ပါတယ္။ User 1 နဲ႕ User 2 အေနနဲ႕ Svr1 down သြားေၾကာင္း သိလိုက္မွာ မဟုတ္ပါဘူး။ ဒါ Failover cluster ပါ။

Load balance cluster
Active - Active setup လို႕လည္း သုံးေလ့ရွိပါတယ္။ Server ႏွစ္လုံး သို႕မဟုတ္ ႏွစ္လုံးထက္ပိုတယ့္ server ေတြက အလုပ္တစ္ခုကို မွ်ေဝလုပ္ၾကတာမ်ိဳးပါ။ ( Grid computing ၊ Server System Image တို႕ကို hardware level clustering အျဖစ္ေျပာၾကေလ့ရွိပါတယ္။ Server clustering technology တစ္ခုခ်င္းကို ေနာက္မွ အခြင့္သင့္ရင္ အေသးစိတ္ေရးပါအုန္းမယ္။ )

အခုေတာ့ ျမင္သာေအာင္ Network Load Balancing Cluster ကို ဥပမာေပးပါရေစ။၊ အေပၚက ဥပမာအတိုင္း Website တစ္ခုကို web server ႏွစ္လုံးက round-robin network load balanced ပံုစံနဲ႕ ဥပမာ ေျပာရရင္၊ Web Server ႏွစ္လုံးရွိမယ္ WebSvr1 နဲ႕ WebSvr2။ Server ႏွစ္လုံးစလုံးက www.example.org ဆိုတဲ့ Website ကို host လုပ္ထားတယ္ ဆိုပါေတာ့။ User 1 က www.example.org လို႕ surf လုပ္လိုက္ရင္ WebSvr1 က respond လုပ္ပါမယ္။ User 2 က surf လုပ္ရင္ WebSvr2 က respond လုပ္ပါမယ္။ တကယ္လို႕ User 3 ထပ္ေရာက္လာရင္ WebSvr1 က respond လုပ္ပါလိမ့္မယ္။ Server loading ကို balance လုပ္ယူလိုက္တာပါ။ User 4 ထပ္ေရာက္လာရင္ Svr2 က respond လုပ္ပါလိမ့္မယ္။ တကယ္လို႕ Svr1 ကသာ down သြားရင္ User ေလးေယာက္လုံးကို Svr2 က ဆက္ျပီး respond လုပ္ပါလိမ့္မယ္။ Load balanced လုပ္ထားရာကေန ၊ တစ္လုံးျပဳတ္သြားေတာ့ ပိုေတာ့ ေႏွးသြားေကာင္း ေႏွးသြားႏိုင္ပါတယ္။

Failover နဲ႕ NLB ဘာကြာလဲ
Srv 1 down သြားရင္ Srv 2 က အလုပ္လုပ္ေပးတာ၊ ဒါဆို သိပ္မကြာဘူးလို႕ ထင္ႏိုင္ပါတယ္။ ေရာေနႏိုင္လို႕ ျပန္ရွင္းပါမယ္။ Failover မွာတုန္းက Server ႏွစ္လုံးက Active-Passive ပါ။ Active အလုံးက ေကာင္းေကာင္းအလုပ္လုပ္ေန ေသးသမွ် Passive အလုံးက standby အေနအထားမွာပဲေနပါတယ္။ အလုပ္ဝင္မလုပ္ပါဘူး။ သူ႕ဟာသူ မႏိုင္မနင္းျဖစ္လည္း ဂ႐ုမစိုက္ပါဘူး။ သူ down မွ ငါ role တက္မွာဆိုတာမ်ိဳးစိတ္ထားနဲ႕ကို လစ္လွ်ဴ႐ႉထားပါတယ္။ NLB မွာကေတာ့ Active-Active ပါ။ ရွိသမွ် Server အားလုံးက load ကို ခြဲယူထားတာပါ။ အေပၚက Scenario မွာ server ႏွစ္လုံးဆိုေပမယ့္ Server သုံးလုံး အေနနဲ႕ စဥ္းစားရင္ ပိုရွင္းမယ္ထင္ပါတယ္။ User ေျခာက္ေယာက္ကို Server သုံးလုံးက ႏွစ္ေယာက္စီခြဲျပီး respond လုပ္ေနရာကေန၊ Srv 1 down သြားရင္ Srv 2 ေန႕ Srv 3 က သုံးေယာက္ဆီ ခြဲယူျပီး respond လုပ္ေပးပါလိမ့္မယ္။ Srv 1 မ down ခင္ကလည္း သူတို႕ အလုပ္လုပ္ေနပါတယ္။ Srv 1 down သြားေတာ့ သူတို႕ပိုအလုပ္ရွုပ္သြားတယ္။

အခုေနာက္ပိုင္းမွာ failover စစ္စစ္ကို သုံးတာ ရွားပါတယ္။ NLB server ငါးလုံးအတြက္ Srv တစ္လုံးကို standby အေနနဲ႕ ထားေပးထားတာမ်ိဳးပဲရွိပါေတာ့တယ္။ Server တစ္လုံးအတြက္ ေနာက္တစ္လုံး standby ထားေပးထားတာမ်ိဳး မလုပ္ၾကေတာ့ပါဘူး။ ကုန္က်စရိတ္အရေရာ ၊ မီတာအလကား ကုန္ေနတာမ်ိဳးလည္း မျဖစ္ေအာင္ပါ။


Server ေတြကို cluster လုပ္ျပီး သုံးရင္ ဘာေတြပိုေကာင္းမလည္း ?
1 . High Availability
ႏွစ္လုံးထက္ပိုတယ့္ Server ေတြကို အတူတကြ အလုပ္လုပ္ေစတာမို႕လို႕ Failover မွာပဲျဖစ္ျဖစ္ NLB မွာပဲျဖစ္ျဖစ္ Server တစ္လုံး down သြားရုံနဲ႕ operational state ရပ္မသြားပါဘူး။ ဆက္ျပီး အလုပ္လုပ္ေနႏိုင္ေသးတယ့္ အတြက္ Availability အသုံးျပဳႏိုင္စြမ္း ပိုျမင့္ေစပါတယ္။ ဒါဟာ User ေတြရဲ့ စိတ္ေၾကနပ္မႈအတြက္ အေရးပါပါတယ္။
2. Better Performance
Failover cluster မွာေတာ့ ဒီအခ်က္ဟာ သိပ္အၾကဳံးမဝင္ပါဘူး။ NLB cluster မွာေတာ့ Request 200 ကို Server တစ္လုံးထဲက reply လုပ္တာထက္၊ Server ႏွစ္လုံးက reply လုပ္တာမို႕ ပိုျမန္ျမန္ဆန္ဆန္ respond လုပ္ႏိုင္တာ ေတြ႕ရပါလိမ့္မယ္။
( Note: CPU 3.0 MHz နဲ႕ Memory 4GB server ႏွစ္လုံးကို cluster လုပ္တာနဲ႕ CPU 3.0 MHz Dual Processor နဲ႕ Memory 8GB server တစ္လုံး performance ခ်င္းယွဥ္ရင္ Cluster ကသာပါလိမ့္မယ္။ ကိန္း ဂဏန္းအရ အတူတူေလာက္ရွိေပမယ့္ motherboard က bus speed တို႕၊ Network traffic တို႕ ထဲ့တြက္ရပါလိမ့္မယ္။ Critical application ဆိုရင္ High-Availablity(HA) ကိုလည္း အေရးပါတယ့္ factor အေနနဲ႕ ထဲ့တြက္ရပါတယ္။ )
3. Better Scalability
User ေတြအရမ္းမ်ားလာမွ တစ္လုံးထဲကေန ပိုျပီး powerful ျဖစ္တယ့္ Server ကိုေရႊ႕ရရင္ မလြယ္ပါဘူး။ Clustered environment မွာေတာ့ cluster ကို တိုးခ်ဲ႕ရတာ ပိုလြယ္ပါတယ္။ Cluster ထဲကို Server ေတြတိုးျပီး ၊ load ကိုျပန္ထိန္းဖို႕က ပိုျပီး အဆင္ေျပ လြယ္ကူပါတယ္။

Clustering မွာ ဒီႏွစ္ခုကိုပဲေျပာေနတယ္ ထင္အုန္းမယ္။ ဒီ concept ႏွစ္ခုအတြက္ technology အမ်ိဳးမ်ိဳး ကြဲျပီးျဖစ္လာတာမို႕၊ ဒီႏွစ္ခုကို အရင္ေျပာခ်င္လို႕ပါ။ ဒါေပမယ့္ ဆက္ေျပာခ်င္တယ့္ အေၾကာင္းအရာေတြက စာၾကီးပဲဖတ္ဖို႕ထက္ ပံုေလးေတြနဲ႕မွပိုအဆင္ေျပမယ္ထင္တယ္။ ပံုေလးေတြဆြဲျပီးမွ ေနာက္ post တစ္ခုဆက္ေရးေတာ့မယ္ဗ်ာ။

Divinity

Linux Directory Structure

Linux system ကိုစေလ့လာမယ္ဆိုရင္ Linux ရဲ့ directory structure ဟာ Windows နဲ႕ လုံးဝကြဲျပားေနတာကို ေတြ႕ရပါလိမ့္မယ္။ Windows မွာတုန္းကလို C: D: ေတြလည္းမရွိေတာ့ သလို Windows directory လိုမ်ိဳးလည္း ရွာေတြ႕မွာမဟုတ္ပါဘူး။Windows မွာဆိုရင္ ဒါကေတာ့ C:\windows ေအာက္မွာ၊ ဒါဆိုရင္ေတာ့ system32 ေအာက္မွာ ဆိုတာမ်ိဳး ရင္းႏွီးေနေပမယ့္ Linux မွာဆိုရင္ေတာ့ ဘယ္လို file ေတြက ဘယ္ directory ေအာက္မွာရွိတတ္တယ္ဆိုတာ စစခ်င္းမွာ ရွာဖို႕ခက္ေနတတ္ပါတယ္။ ဒါဆို Linux မွာဘာေတြရွိလည္း၊ အဲဒါေတြက ဘာေတြလည္းဆိုတာ နည္းနည္းေလ့လာၾကည့္ရေအာင္။ (Linux / Unix environment မွာ directory ဆိုတယ့္ အသုံးအႏွုန္းအစား File System လို႕လည္းသုံးတတ္ပါတယ္။ )

Linux distribution အလိုက္ တျခား directory ေတြရွိတတ္ေပမယ့္ က်ေနာ္တို႕ Linux တိုင္းမွာပါတယ့္ Generic ျဖစ္တယ့္ directory ေတြကို အဓိက ၾကည့္ၾကရေအာင္။

Linux မွာdirectory( file system) ေတြ အားလုံးက System Root directory လို႕ေခၚတယ့္ '/' ကေနစပါတယ္။ System root directory ျဖစ္တဲ့ “/” ေအာက္ကေန က်န္တဲ့ directory ေတြအားလံုး ဆက္သြားပါတယ္။ ဒါေၾကာင့္ /boot တို႕ /etc တို႕ဆိုျပီး '/' ရဲ့ေနာက္မွာ ဆက္ျပီးေရးၾကတာပါ။ ( ဒါဆို '/' က C: ၾကီးေပါ့လို႕ေတာ့ မထင္ပါနဲ႕။ တူတာေတြရွိေပမယ့္ မတူတာေတြလည္းရွိပါတယ္။) Linux ရဲ့ directory structure ကေတာ့


/ --
- /boot
- /sbin
- /bin
- /etc
- /home
- /root
- /lib
- /usr
- /var
- /tmp
- /dev
- /mnt
- /proc
- /opt



/
ဒီ directory ကေတာ့ Linux directory structure ရဲ့ အစမွတ္ျဖစ္ပါတယ္။ System Root directory လို႕ ေခၚပါတယ္။ ဒါေပမယ့္ အလြယ္တကူ root directory လို႕ပဲေခၚၾကတယ့္ အတြတ္ Root user ရဲ့ home directory ျဖစ္တယ့္ /root နဲ႕ ေရာတတ္ၾကပါတယ္။ က်န္တယ့္ directory ေတြဟာ Root directory ( '/' ) ကေနမွ directory tree အျဖစ္ခြဲထြက္လာၾကတာပါ။
Root directory ( '/' )က ပုံမွန္အားျဖင့္ directory ေတြစုထားတယ့္ ပင္မ directory တစ္ခုပါ။ Root directory ( '/' ) ရဲ့ ေအာက္မွာ (/usr တို႕ /bin တို႕လို) directory ေတြပဲရွိတတ္ပါတယ္။ ပံုမွန္ file တစ္ခုကို '/' ေအာက္မွာ ဖြဲ႕စည္းေလ့မရွိပါဘူး။


/boot
Boot directory ကေတာ့ Operation system တစ္ခု boot တက္လာဖို႕လိုအပ္တယ့္ file ေတြ သိမ္းစည္းထားတယ့္ ေနရာပါ။ /boot directory ရဲ့ ေအာက္မွာ Boot loader လို႕ေခၚတယ့္ Grub တို႕ lilo တို႕ရဲ့ config file ေတြ၊ Kernel image ေတြ initrd file ေတြရွိပါတယ္။


/sbin
System binary directory ပါ။ ဒီ /sbin directory မွာ System administrator တစ္ေယာက္အတြက္ လိုအပ္မယ့္ command ေတြ binary ေတြကိုထားပါတယ္။ /sbin ေအာက္မွာရွိတယ့္ တစ္ခ်ိဳ႕ command ေတြကို System Administrator ကသာ Access လုပ္ခြင့္ရွိပါတယ္။ Harddisk ကို partition ပိုင္းတယ့္ fdisk တို႕ ၊ format ခ်တယ့္ mkfs command ေတြကို /sbin ေအာက္မွာထားပါတယ္။ /sbin ရဲ့ ပံုစံတူ ေနာက္ထပ္ directory တစ္ခုကေတာ့ /usr/sbin directory ပါ။ Administrator ေတြပဲသုံးရတယ့္ useradd / userdel / groupadd တို႕လို command မ်ိဳးေတြ ထားပါတယ္။


/bin
User ေတြအားလုံး ေန႕စဥ္ အသုံးျပဳေနတယ့္ binary ( commands) ေတြကို /bin directory ေအာက္မွာထားပါတယ္။ cp / mv / rm / ls တို႕လို command ေတြအျပင္ SHELL ေတြျဖစ္တယ့္ bash တို႕ csh တို႕ကိုနဲ႕ ဆိုင္တယ့္ binary ေတြကို /bin directory ထဲမွာ ထားပါတယ္။


/etc
Editable Text Configuration directory လို႕ ဆိုတယ့္ အတိုင္း System မွာရွိတယ့္ services ေတြရဲ့ configuration file ေတြကို /etc directory ထဲမွာ ထားေလ့ရွိၾကပါတယ္။ Hostname configuration အတြက္ hosts file တို႕၊ DNS server address မွတ္တယ့္ resolve.conf တို႕လို configuration file ေတြအျပင္၊ GUI windows အတြက္ လိုအပ္တယ့္ X11 ရဲ့ configuration ေတြလည္းရွိပါတယ္။ တကယ္လို႕ သင့္ရဲ့ System ေပၚကို တစ္ျခား application ေတြ တင္မယ္ဆိုရင္ ၊ ဆိုၾကပါဆို႕ Apache တို႕ MySQL server တို႕ တင္မယ္ဆိုရင္ Apache service အတြတ္ Mysql-server service အတြက္ လိုအပ္တယ့္ Configuration file ေတြကို /etc ေအာက္မွာ /etc/apache2 စသျဖင့္ သက္ဆိုင္ရာ sub-directory ေအာက္မွာ ထားသြားမွာျဖစ္ပါတယ္။


/home
User ေတြရဲ့ home directory ပါ။ User တစ္ေယာက္ခ်င္းအတြက္ /home directory ရဲ့ေအာက္မွာ username နဲ႕ sub-directory တစ္ခုဆီ တည္ေဆာက္ေပးေလ့ရွိပါတယ္။ (ဥပမာ၊ divinity ဆိုတယ့္ user အတြတ္ /home/divinity ဆိုတဲ့ directory ကိုေဆာက္ေပးမွာျဖစ္ျပီး user 'divinity' ရဲ့ ကိုယ္ပိုင္ home directory အျဖစ္သတ္မွတ္ေပးမွာ ျဖစ္ပါတယ္။)User တစ္ေယာက္ရဲ့ home directory ကို တစ္ျခား user တစ္ေယာက္က ဝင္ၾကည့္ ဝင္ျပင္ လုပ္လို႕မရေအာင္ လုပ္ထားေလ့ရွိပါတယ္။ User တစ္ေယာက္ခ်င္းစီရဲ့ Environmental variable / parameter ေတြကိုလည္း သက္ဆိုင္ရာ User ရဲ့ home directory ေအာက္မွာ သက္မွတ္ေပးေလ့ရွိပါတယ္။


/root
ဒီ directory ကို directory tree ရဲ့ အစျဖစ္တယ့္ System Root directory ( '/' ) နဲ႕ ေရာတတ္ၾကပါတယ္။ ဒီ /root directory က Linux system ေတြရဲ့ SuperUser ျဖစ္တယ့္ root user ရဲ့ home directory ျဖစ္ပါတယ္။ System root directory ( '/' ) နဲ႕ဘာမွမဆိုင္ပဲ System root ရဲ့ေအာက္မွာ ဒိုက္႐ိုက္ရွိေနတယ့္ directory တစ္ခုမွ်သာျဖစ္ပါတယ္။


/lib
Linux system နဲ႕ သူ႕ရဲ့ Program ေတြက အသုံးျပဳမယ့္ library files ေတြထားတယ့္ေနရာျဖစ္ပါတယ္။ Library file ဆိုတာ Windows မွာ ဆိုရင္ေတာ့ DLL file ေတြနဲ႕ တူပါတယ္။


/usr
User application ေတြနဲ႕ သက္ဆိုင္တဲ့ file ေတြကို ထားတယ့္ေနရာျဖစ္ပါတယ္။ User ေတြအသုံးျပဳမယ့္ telnet တို႕ ftp တို႕အတြတ္ binary ေတြ configuration ေတြကို /usr ေအာက္က သက္ဆိုင္ရာ sub-directory ေတြထဲမွာ ထားပါတယ္။ ( ဥပမာ၊ တကယ္လို႕ Apache ကို install လုပ္ထားမယ္ဆိုရင္ Apache configuration file က /etc ေအာက္ကိုေရာက္ေနေပမယ့္ က်န္တယ့္ Apache module ေတြက /usr ေအာက္မွာ ရွိမွာျဖစ္ပါတယ္။ )


/var
ဒီ directory ကေတာ့ Spooling လုပ္ဖို႕လိုအပ္တယ့္ data ေတြကို ထားတယ့္ ေနရာလို႕ ေျပာလို႕ရပါတယ္။ Variable data directory လို႕ေခၚတယ့္ အတိုင္း အျမဲတန္းေျပာင္းလဲေနတယ့္ file ေတြပါ။ Printer deamon ရဲ့ printer spool လိုမ်ိဳးေတြ၊ Mail server ေတြရဲ့ mailbox ေတြ mail queue ေတြကို /var ေအာက္မွာထားပါတယ္။ Linux system ရဲ့ system log file ေတြကိုလည္း /var/log directory ထဲမွာ ထားေလ့ရွိပါတယ္။ System မွာ run ေနတယ့္ service ေတြနဲ႕ system ရဲ့ လုပ္ေဆာင္ခ်က္အားလုံးနည္းပါးကို /var/log ေအာက္မွာ သက္ဆိုင္ရာ log file ေတြနဲ႕ မွတ္ပါတယ္။


/tmp
User တိုင္း Service တိုင္း everyone full permission ရတယ့္ directory တစ္ခုပါပဲ။ Service ေတြအတြက္ လိုအပ္တယ့္ temporary file ေတြကို /tmp directory ထဲမွာ ထားေလ့ရွိပါတယ္။ /tmp ထဲက temporary file ေတြကို အခ်ိန္အပိုင္းအျခားတစ္ခုနဲ႕ျဖစ္ေစ၊ Program ကအသုံးျပဳျပီးသြားရင္ သူ႕အလိုအေလ်ာက္ျဖစ္ေစ၊ system reboot မွာျဖစ္ေစ ရွင္းျပစ္ေလ့ရွိပါတယ္။


/dev
Linux system ရဲ့ အထူးစမ္းဆုံး directory ပါ။ Computer မွာရွိေနတယ့္ hardware ေတြကို file ေတြအျဖစ္နဲ႕ ျပထားတာကို ေတြ႕ရပါလိမ့္မယ္။ /dev/cdrom, /dev/fd0 အစရွိသျဖင့္ computer ရဲ့ CDrom device နဲ႕ floppy device ကို ကိုယ္စားျပဳတယ့္ file ေတြ ကိုေတြ႕ရပါလိမ့္မယ္။ IDE hard drive ေတြကို ပထမ hard drive ကို /dev/hda၊ ဒုတိယ hard drive ကို /dev/hdb အစရွိသျဖင့္၊ SATA, SCSCI drive ေတြကို /dev/sda , /dev/sdb အစရွိသျဖင့္ ကိုယ္စားျပဳေလ့ရွိပါတယ္။ /dev directory မွာရွိတယ့္ file တိုင္းဟာ read ႏိုင္ write ႏိုင္ျပီး hardware device ေတြကို direct communicate လုပ္ပါတယ္။ ဥပမာေျပာရရင္ /dev/dsp ဆိုတယ့္ file ဟာ system speaker ကို ကိုယ္စားျပဳပါတယ္။ Speaker file ကို တစ္ခုခုေရးၾကည့္ရေအာင္။ echo "Hello testing" >> /dev/dsp လို႕ command ႐ိုက္ရင္ speaker က အသံတစ္မ်ိဳးထြက္ပါလိမ့္မယ္။ (Hello Testing လို႕ေတာ့ မဟုတ္ဖူးေပါ့ဗ်ာ။ /dev ေအာက္က fileေတြကို read / write လုပ္ခ်င္းအားျဖင့္ hardware device ေတြကို access လုပ္တယ္ဆိုတာ သိေစ႐ံု သက္သက္မွ်သာ ျဖစ္ပါတယ္။ )


/mnt
Linux system ေတြရဲ့ Generic mount point ျဖစ္ပါတယ္။ Default မွာေတာ့ directory အလြတ္ၾကီးတစ္ခုပါ။ ဥပမာ pen drive ေလးတပ္လိုက္တယ္ဆိုရင္ တကယ္လို႕ pen drive ကို detect ျဖစ္မယ္ဆိုရင္ Linux က /mnt ေအာက္မွာ mount point တစ္ခု တည္ေဆာက္ေပးသြားမွာ ျဖစ္ပါတယ္။ /mnt/FAT ဆိုတာမ်ိဳးေပါ့။ အဲဒီ /mnt/FAT ကို ဖြင့္ၾကည့္ရင္ ကိုယ့္ pen drive ထဲက file ေတြကို ျမင္ရမွာျဖစ္ပါတယ္။ တစ္ခ်ိဳ႕ device ေတြကို manual mount လုပ္ေပးရရင္လည္း Generic အေနနဲ႕ /mnt ေအာက္မွာပဲ mount လုပ္ၾကေလ့ရွိပါတယ္။


/proc
Linux ရဲ့ ထူးစမ္းတဲ့ file system / directory ေနာက္တစ္ခုျဖစ္ပါတယ္။ /proc directory ဟာ ဘယ္ hardware media ေပၚမွာမွ မရွိပါဘူး။ Virtual memory ထဲမွာ ယာယီတည္ေဆာက္ထားတယ့္ directory တစ္ခုျဖစ္ပါတယ္။ Operation system ရဲ့ လက္ရွိ အေျခအေန (Current state) ကိုေဖာ္ျပတယ့္ file ေတြကို tree structure တစ္ခုလို directory အဆင့္ဆင့္နဲ႕ တည္ေဆာက္ထားျပီး အခ်ိန္နဲ႕အမွ်ေျပာင္းလည္းေနႏိုင္တယ့္ filesystem တစ္ခုလည္းျဖစ္ပါတယ္။ /proc အေၾကာင္း အေသးစိတ္ကေတာ့ ဒီ URL ကို ညႊန္ပါရေစ
http://www.freeos.com/articles/2879/


/opt
Unix standard directory တစ္ခုျဖစ္ျပီး Linux system ေတြမွာ အသုံးနည္းတဲ့ directory တစ္ခုပါ။ Default installation တုန္းက မပါခဲ့တယ့္ system / operation system နဲ႕လည္း မသက္ဆိုင္တယ့္ Application ေတြကို /opt ေအာက္မွာ install ၾကေလ့ရွိပါတယ္။ Linux distribution အမ်ားဆုကေတာ့ /usr ကို ပိုအသုံးမ်ားျပီး /opt ကို သိပ္အသုံးျပဳေလ့မရွိပါဘူး။

................

ဒီ directory structure အေၾကာင္း ဒီတိုင္းဖတ္ရင္ နည္းနည္း ေခါင္းေနာက္သြားႏိုင္ပါတယ္။ ဒါေပမယ့္ Linux computer တစ္လုံးနဲ႕ ယွဥ္ျပီး ၾကည့္ရင္ အလြန္လြယ္လြယ္ကူကူ သေဘာေပါက္ႏိုင္ပါတယ္။ Linux community ေတြမွာ ေျပာေလ့ရွိတယ့္ စကားတစ္ခုရွိပါတယ္။ 'Get your hands dirty'။ လက္ေတြ႕လုပ္ဖို႕ တိုက္တြန္းတယ့္ idiom တစ္ခုျဖစ္ပါတယ္။ စမ္းသပ္ရင္း နားလည္လာရင္ Linux installation လုပ္ကတည္းက ကိုယ္က ဒီ linux box ကို ဘာ အတြက္အသုံးျပဳမလည္း ဆိုတာေပၚမူတည္ျပီး partitioning ကို လိုသလို partition ပိုင္းျပီး ပိုေကာင္းတယ့္ read / write speed ကို လည္း ရႏိုင္ပါလိမ့္မယ္။

Linux system တစ္ခုအတြက္ partitioning stage အေၾကာင္းကိုလည္း ေနာက္ doc တစ္ခုမွာ ေရးဖို႕ၾကိဳးစားပါမယ္။ Guide line ဆိုတာမ်ိဳးထက္ partitioning အေၾကာင္းရွင္းျပရင္းနဲ႕ ဘယ္လို server မ်ိဳးအတြက္ ဘယ္လို partition scheme မ်ိဳးထားသင့္တယ္ဆိုတာမ်ိဳး ေဆြးေႏြးခ်င္ပါေသးတယ္။ ေက်းဇူးတင္ပါတယ္။


Divinity