System Engineer ဒါမွမဟုတ္ Unix / Linux engineer လုပ္ဖို႕ ရည္ရြယ္ခ်က္ထားရင္ Ubuntu လို OS မ်ိဳးထက္ CentOS ကို ပိုေလ့လာဖို႕ ေျပာဖူးပါတယ္။ ဘာလို႕လည္း ? Ubuntu လည္း Server သုံးလို႕ရတယ္၊ Debian လည္း ေတာ္ေတာ္ေကာင္းတယ္၊ CentOS က ဘာပိုသာသလည္း ?
ဒီလိုေမးရင္ေတာ့ Technically ဘာမွ ပိုမသာဘူး လို႕ပဲေျဖရပါမယ္။ Package update ေတြမွာဆိုလည္း Debian / Ubuntu ကပိုျမန္တယ္။ Ubuntu နဲ႕ Debian မွာဆိုရင္ေတာ့ Server အတြက္ဆိုရင္ Debian ကပိုေကာင္းေနပါေသးတယ္။ Free Opensource ျဖစ္ခ်င္း community အားေကာင္းျခင္းေတြေၾကာင့္ Debian နဲ႕ Ubuntu က SME server ေတြမွာ Redhat / CentOS ထက္ ေနရာပိုယူလာႏိုင္ပါတယ္။ ဒါေပမယ့္.... ဒါဟာ စာလုံးၾကီးၾကီးနဲ႕ ေရးသင့္တယ့္ 'ဒါေပမယ့္'ပါ ..
Enterprise environment ေတြမွာ Redhat ကို ေက်ာ္ႏိုင္တယ့္ Linux မရွိေသးဘူးလို႕ပဲ ေျပာရပါမယ္။ Commercial support ဆိုတာကို ခဏေမ့ထားျပီး server တစ္ခုအတြက္ တျခားအေၾကာင္းအရာေတြကို ထဲ့စဥ္းစားၾကည့္ရေအာင္။ Enterprise ၾကီးတစ္ခုရဲ့ database server လို႕ေျပာရင္ MySQL , PostgreSQL တို႕မျဖစ္ဖို႕မ်ားပါတယ္။ Oracle ျဖစ္ရင္ျဖစ္မယ္၊ IBM DB2 လည္းျဖစ္ရင္ျဖစ္မယ္၊ ဒီလို giant commercial product ၾကီးေတြက သူတို႕ product အတြက္ support ကို branded OS ေတြအတြက္ပဲ ေပးပါတယ္။ ဆိုလိုတာကေတာ့ Oracle က AIX , HP-UX မွာပဲ support လုပ္တယ္လို႕ ေျပာထားရင္ ၊ တျခား OS မွာသြင္းလို႕ ျဖစ္သမွ် ျပသနာကို သူတို႕တာဝန္မယူပါဘူး။ သုံးေနရင္းနဲ႕မွ ျဖစ္ရင္ သူတို႕ product က ျပသနာဆိုရင္ေတာင္ unsupported configuration ဆိုျပီး technical support ေပးဖို႕ ျငင္းႏိုင္ပါတယ္။ User ဘက္က supported hardware / supported OS မွာမသုံးရင္ သူတို႕ ျပသနာမဟုတ္ဖူးလို႕ သတ္မွတ္ပါတယ္။ အဲေတာ့လည္း Enterprise company ၾကီးေတြက အမွားမခံႏိုင္တယ့္ Server ေတြမွာ branded OS ၾကီးေတြသုံးဖို႕ပဲ စဥ္းစားပါတယ္။ ဒါက Redhat ပိုေနရာရရျခင္း အေၾကာင္းတစ္ခု။
ေနာက္တစ္ခုက stability ပါ။ Redhat မွာ fancy new stuffs ေတြမပါပါဘူး။ Package တိုင္းက ေနာက္ဆုံး up to date ကိုမရႏိုင္ပါဘူး။ ဒါက drawback လို႕ေျပာလို႕လည္း ရပါတယ္။ လုံးဝ stable လို႕သတ္မွတ္တယ့္ version အထိပဲ ေပးပါတယ္။ New feature ေတြကိုစမ္းသပ္ျပီး အဆင္ေျပရင္ေတာ့ back ported လုပ္ေပးပါတယ္။
ေနာက္တစ္ခုက Support။ Commercial Support ဆိုတာ ပိုက္ဆံေပးရတာကိုပဲ တြက္လို႕မရပါဘူး။ တစ္ခုခုျဖစ္ရင္ ေနာက္မွာ ဒီ product ကို specialize လုပ္တဲ့ expert ေတြရွိတယ္လို႕ စိတ္ထဲထားလို႕ရပါတယ္။ Red Hat ရဲ့ L3 support ေတြက အမ်ားအားျဖင့္ RH ရဲ့ သက္ဆိုင္ရာအပိုင္းကို in and out သိတဲ့သူေတြပါ။ ဒါ Commercial Support ေတာ္ေတာ္မ်ားမ်ား အတူတူပါပဲ။ အဲဒီအတြက္ ျပသနာ ေတာ္ေတာ္မ်ားမ်ားကို ေနာက္ဆုံး ကိုယ့္ IT team က မေျဖရွင္းႏိုင္ရင္ေတာင္၊ သက္ဆိုင္ရာ support team က ကူညီႏိုင္လိမ့္မယ္လို႕ ယံုၾကည္လို႕ရပါတယ္။
ဒါေတြက MNC ေတြ Enterprise company ၾကီးေတြက Red Hat ကို Debian ထက္ ပိုသုံးတဲ့ အေၾကာင္းရင္းေတြထဲက တခ်ိဳ႕ပါ။ အဲေတာ့ Debian ကိုကြၽမ္းက်င္တာထက္ Red Hat ကြၽမ္းက်င္တာက Big sh*t company ၾကီးေတြက ေခၚတယ့္ အလုပ္ေတြနဲ႕ ပိုအဆင္ေျပႏိုင္ပါတယ္။ ဒါေၾကာင့္ CentOS ကိုေလ့လာတာက ပိုျပီး အခြင့္အေရးရွိပါတယ္။ (SuSE ေလလာခ်င္ရင္လည္း OpenSuSE ေလ့လာပါ။ )
တကယ္တမ္း Red Hat expertise လို႕ ေျပာရင္ OS တစ္ခုထဲနဲ႕ မရပါဘူး။ JBoss လို႕ middleware ေတြ၊ RH Cluster ေတြ၊ RHN Satellite တို႕ product ေတြပါ သိဖို႕ လိုလာမွာပါ။ ဒါက Career အရ ေနာက္မွ Advance ျဖစ္သြားပါလိမ့္မယ္။ ဒီ post က ႏိုင္ငံျခားကို ထြက္ျပီး အလုပ္ရွာဖို႕ ရည္ရြယ္ထားၾကတဲ့ Administrator level အတြက္ကို ရည္ရြယ္တာပါ။ Linux ကို Career အျဖစ္ေရြးခ်င္တယ္ဆိုျပီး ၊ ဒါေပမဲ့ ေလ့လာတာ မွားေနရင္ အလုပ္ရွာရင္ အခက္အခဲေလးေတြ ရွိတတ္ပါတယ္။ ႏိုင္ငံျခားကို ထြက္ျပီး အလုပ္လုပ္ၾကရင္ အလုပ္ဝင္ဝင္ခ်င္းမွာ ရွိတတ္တဲ့ stress နဲ႕ ကိုယ္ေသခ်ာမသိတာကို စမ္းတဝါးဝါးလုပ္ရရင္ ျဖစ္တဲ့ stress က တခ်ိဳ႕ကို လက္ေျမႇာက္ျပီးျပန္ခ်င္ေလာက္ေအာင္ျဖစ္ေစတဲ့အထိ ဆိုးပါတယ္။ အဲဒါေၾကာင့္ Linux သမားလုပ္ခ်င္တယ္၊ ႏိုင္ငံျခားထြက္မယ္ဆိုရင္ေတာ့ CentOS ကိုေလ့လာဖို႕ အၾကံေပးခ်င္ပါတယ္။
.............
ဒီ စာက ေရးထားတာ လြန္ခဲ့တဲ့ ႏွစ္ႏွစ္ကပါ ။ Linux တစ္ရပ္စာ ေမ်ာ္စင္ post သုံးခုျပီးေတာ့ ေရးထားတာ။ အခု စာျပန္ေရးမည္စဥ္းစားေတာ့ ဘာေရးရမွန္းမသိလို႕ ဒါကို ျပန္ရွာျပီး တင္လိုက္တယ္ ဟဲဟဲ ။ စာျပန္ေရးဖို႕ ၾကိဳးစားပါအုန္းမယ္ ။
Divinity
Related Posts
Linux တစ္ရပ္စာ ေမွ်ာ္စဥ္ထက္က ျမင္ကြင္း
Linux တစ္ရပ္စာ ေမွ်ာ္စဥ္ထက္က ျမင္ကြင္း (2)
Linux တစ္ရပ္စာ ေမွ်ာ္စဥ္ထက္က ျမင္ကြင္း (3)
Showing posts with label Divinity. Show all posts
Showing posts with label Divinity. Show all posts
Thursday, February 7, 2013
ဪ ssh logon attempt ေတြ
Log file ေတြထဲမွာ လိုခ်င္တာရွာရတာ အခက္ဆုံးနဲ႕ စိတ္ညစ္စရာ အေကာင္းဆုံးက auth.log ျဖစ္မယ္ထင္တယ္။ Internet facing server ေတြမွာ ( Internet ကတိုက္႐ိုက္သုံးလို႕ရတယ့္ ၊ company အတြင္းပဲသုံးတာမဟုတ္တယ့္ server မ်ိဳးကိုေျပာခ်င္တာပါ) တစ္နာရီမွာ failed login attempt က 500 ေလာက္ရွိတတ္ပါတယ္။ ေျပာရရင္ေတာ့.. ဒါပံုမွန္ပါ။ တကယ္ target ထားျပီး လုပ္တာမ်ိဳးမဟုတ္ပါဘူး။ Botnet တစ္ခုက IP range တစ္ခုအတြင္း ရွိသမွ် server ေတြကို dictionary ေသးေသးတစ္ခုနဲ႕ attempt လုပ္ၾကည့္တာေလာက္ပဲရွိမယ္။ ရည္ရြယ္ခ်က္ရွိရွိေတာင္မဟုတ္ဖူး၊ ဒီလိုပဲ ေရာေကာေသာေကာပါသြားတာေတာင္ ဒီေလာက္ေတာ့ရွိမယ္။ ဟုတ္တယ္ တစ္ခါတစ္ေလ ကံေကာင္းရင္ တစ္နာရီေလာက္အတြင္း attempt ေလး ငါးေသာင္းေလာက္လဲျဖစ္ႏိုင္တယ္။ Failed attempt ပဲ ျပသနာမဟုတ္ပါဘူးလို႕ေျပာလို႕ရေပမယ့္ attempt လုပ္ခံရတာဟာ cracked ျဖစ္ဖို႕ တစ္ဆင့္နီးတာပဲ။ ( က်ေနာ္အတြက္ကေတာ့ ဘာပဲျဖစ္ျဖစ္ မ်က္စိေနာက္ပါတယ္။)
SSH service ရွိေနသမွ် ဒါမ်ိဳးေတြရွိမွာပဲ၊ SSH service disable လိုက္တာေကာင္းမယ္။ ဟုတ္တာေပါ့။ ဒါဆို attacker တင္မဟုတ္ဖူး ကိုယ္ပါဝင္လို႕မရေတာ့ဘူး ဟဲဟဲ၊ ဒါဆိုအလုပ္နည္းတာေပါ့။ အမွန္က SSH service run ထားရင္ သတိထားသင့္တာေလးေတြ ေရးမလို႕ပါ။ က်ေနာ္လို failed attempt ေတြကိုမ်က္စိေနာက္တဲ့သူအတြက္ ၊ ဒါမ်ိဳးေတြ နည္းသြားေအာင္လို႕ လုပ္လို႕ရတဲ့ နည္းေလးေတြေပါ့။
1. Root login
SSH ကေန direct root login ကို disable လုပ္ထားသင့္ပါတယ္။ Normal user နဲ႕ပဲဝင္ျပီး sudo သုံးတာျဖစ္ျဖစ္ ၊ root user နဲ႕သုံးရမွ ေက်နပ္ရင္လည္းေနာက္မွ su ျပန္ေျပာင္းျပီးျဖစ္ျဖစ္သုံးသင့္ပါတယ္။ ဘာလို႕လည္းဆို အေၾကာင္းျပခ်က္တစ္ခုက ၊ bot ေတြရဲ့ အဓိက target က known user account ေတြကိုပါ။ Linux / Unix မွန္ရင္ root ဆိုတယ့္ နာမည္နဲ႕ user ကရွိမွာပါပဲ။ အဲေတာ့ username မွန္းစရာမလိုပဲ password ေလာက္ပဲမွန္းရေတာ့မွာေပါ့။ အဲဒါမ်ိဳးမျဖစ္ေအာင္ root login ကို disable ထားျပီး admin ဆိုျပီး user account လုပ္ျပီးသုံးရင္လည္း သိပ္မထူးဘူးေပါ့။ ျဖစ္ႏိုင္ရင္ အဲလို username မ်ိဳးကိုလည္း မသုံးသင့္ပါဘူး။
2. SSH service port
ဒါက မထင္မွတ္စရာ အသုံးတဲ့ပါတယ္။ SSH attempt အေတာ္မ်ားမ်ားက port 22 ကိုပဲ ၾကိဳးစားၾကတာမ်ားပါတယ္။ Port scan တစ္ခါဖတ္၊ တစ္ခါ attempt လုပ္ဆိုတာမ်ိဳးက bot နဲ႕ random စမ္းတယ့္သူမ်ိဳးက သိပ္မၾကိဳးစားပါဘူး။ SSH port ကို တျခား port တစ္ခုေျပာင္းသုံးသင့္ပါတယ္။
3. public-key authentication
ျဖစ္ႏိုင္ရင္ public-key authentication only သုံးသင့္ပါတယ္။ Password နဲ႕ authenticate လုပ္တာကို လံုေလာက္တဲ့ security measure လို႕ မသတ္မွတ္ေတာ့တာ ၾကာပါျပီ။ SSH tunnel ေဆာက္တယ့္အခ်ိန္ username / password အဆင့္မေရာက္ခင္မွာ key အရင္စစ္ပါတယ္။ ( ssh -v နဲ႕ စမ္းၾကည့္ပါ။) တကယ္လို႕ public key authentication only ဆိုရင္ rsa / dsa key မမွန္ရင္၊ မေတြ႕ရင္ကို authentication break out ျဖစ္သြားပါျပီ ။ Username / password အဆင့္ကို မဆက္ေတာ့ပါဘူး။ အဲေတာ့ Security ပိုေကာင္းတယ္ေပါ့။ Log ကေတာ့ တက္အုန္းမွာပါ။
ေျပာလက္စနဲ႕မို႕လို႕ပါ။ Account password ေတြကို လြယ္လြယ္ကူကူမေပးသင့္ပါဘူး။ Username = admin , password = admin ဆိုတာမ်ိဳးကေတာ့ ပါသြားရင္နည္းေတာင္ နည္းေသးတယ္ေျပာရမွာပါပဲ။
ဆယ္မိနစ္မၾကာတယ့္ implementation ပါ။ ဒါေပမယ့္ security အရေတာ့ အမ်ားၾကီးကို ကြာသြားပါတယ္။ SSH brute force ကိုလည္း အတိုင္းအတာ တစ္ခုထိ ကာကြယ္ျပီးသားျဖစ္ပါတယ္။ တစ္ခါတစ္ေလေတာ့လည္း သိပ္မပ်င္းတာ ေကာင္းပါတယ္ :D
Divinity
SSH service ရွိေနသမွ် ဒါမ်ိဳးေတြရွိမွာပဲ၊ SSH service disable လိုက္တာေကာင္းမယ္။ ဟုတ္တာေပါ့။ ဒါဆို attacker တင္မဟုတ္ဖူး ကိုယ္ပါဝင္လို႕မရေတာ့ဘူး ဟဲဟဲ၊ ဒါဆိုအလုပ္နည္းတာေပါ့။ အမွန္က SSH service run ထားရင္ သတိထားသင့္တာေလးေတြ ေရးမလို႕ပါ။ က်ေနာ္လို failed attempt ေတြကိုမ်က္စိေနာက္တဲ့သူအတြက္ ၊ ဒါမ်ိဳးေတြ နည္းသြားေအာင္လို႕ လုပ္လို႕ရတဲ့ နည္းေလးေတြေပါ့။
1. Root login
SSH ကေန direct root login ကို disable လုပ္ထားသင့္ပါတယ္။ Normal user နဲ႕ပဲဝင္ျပီး sudo သုံးတာျဖစ္ျဖစ္ ၊ root user နဲ႕သုံးရမွ ေက်နပ္ရင္လည္းေနာက္မွ su ျပန္ေျပာင္းျပီးျဖစ္ျဖစ္သုံးသင့္ပါတယ္။ ဘာလို႕လည္းဆို အေၾကာင္းျပခ်က္တစ္ခုက ၊ bot ေတြရဲ့ အဓိက target က known user account ေတြကိုပါ။ Linux / Unix မွန္ရင္ root ဆိုတယ့္ နာမည္နဲ႕ user ကရွိမွာပါပဲ။ အဲေတာ့ username မွန္းစရာမလိုပဲ password ေလာက္ပဲမွန္းရေတာ့မွာေပါ့။ အဲဒါမ်ိဳးမျဖစ္ေအာင္ root login ကို disable ထားျပီး admin ဆိုျပီး user account လုပ္ျပီးသုံးရင္လည္း သိပ္မထူးဘူးေပါ့။ ျဖစ္ႏိုင္ရင္ အဲလို username မ်ိဳးကိုလည္း မသုံးသင့္ပါဘူး။
2. SSH service port
ဒါက မထင္မွတ္စရာ အသုံးတဲ့ပါတယ္။ SSH attempt အေတာ္မ်ားမ်ားက port 22 ကိုပဲ ၾကိဳးစားၾကတာမ်ားပါတယ္။ Port scan တစ္ခါဖတ္၊ တစ္ခါ attempt လုပ္ဆိုတာမ်ိဳးက bot နဲ႕ random စမ္းတယ့္သူမ်ိဳးက သိပ္မၾကိဳးစားပါဘူး။ SSH port ကို တျခား port တစ္ခုေျပာင္းသုံးသင့္ပါတယ္။
3. public-key authentication
ျဖစ္ႏိုင္ရင္ public-key authentication only သုံးသင့္ပါတယ္။ Password နဲ႕ authenticate လုပ္တာကို လံုေလာက္တဲ့ security measure လို႕ မသတ္မွတ္ေတာ့တာ ၾကာပါျပီ။ SSH tunnel ေဆာက္တယ့္အခ်ိန္ username / password အဆင့္မေရာက္ခင္မွာ key အရင္စစ္ပါတယ္။ ( ssh -v နဲ႕ စမ္းၾကည့္ပါ။) တကယ္လို႕ public key authentication only ဆိုရင္ rsa / dsa key မမွန္ရင္၊ မေတြ႕ရင္ကို authentication break out ျဖစ္သြားပါျပီ ။ Username / password အဆင့္ကို မဆက္ေတာ့ပါဘူး။ အဲေတာ့ Security ပိုေကာင္းတယ္ေပါ့။ Log ကေတာ့ တက္အုန္းမွာပါ။
ေျပာလက္စနဲ႕မို႕လို႕ပါ။ Account password ေတြကို လြယ္လြယ္ကူကူမေပးသင့္ပါဘူး။ Username = admin , password = admin ဆိုတာမ်ိဳးကေတာ့ ပါသြားရင္နည္းေတာင္ နည္းေသးတယ္ေျပာရမွာပါပဲ။
ဆယ္မိနစ္မၾကာတယ့္ implementation ပါ။ ဒါေပမယ့္ security အရေတာ့ အမ်ားၾကီးကို ကြာသြားပါတယ္။ SSH brute force ကိုလည္း အတိုင္းအတာ တစ္ခုထိ ကာကြယ္ျပီးသားျဖစ္ပါတယ္။ တစ္ခါတစ္ေလေတာ့လည္း သိပ္မပ်င္းတာ ေကာင္းပါတယ္ :D
Divinity
Monday, July 30, 2012
Command ေတြကို Bash History ကေဖ်ာက္ရေအာင္
Bash မွာ ေရွ႕က႐ိုက္သြားတဲ့ history ကိုသိမ္းထားပါတယ္။ ျပန္ၾကည့္ခ်င္ရင္ 'history' ဆိုတဲ့ command နဲ႕ ျပန္ေခၚၾကည့္လို႕ရပါတယ္။ System administrator ေတြ ၊ system engineer ေတြ တစ္ခုခုေမ့သြားရင္ ျပန္ၾကည့္ဖို႕လည္း လြယ္သလို၊ Team လိုက္ဆိုရင္ သူမ်ားဘာလုပ္ထားလည္းျပန္ၾကည့္လို႕ ရတယ္။
တစ္ခါတစ္ေလ ကိုယ္႐ိုက္ထားတဲ့ command ကို သူမ်ားကိုမၾကည့္ေစခ်င္ဘူး။ 'root' ေပးမသုံးတဲ့ locked down system မွာဆိုရင္ ကိုယ့္ bash history နဲ႕ကိုယ္ရွိေပမဲ့ 'root' ကို share ျပီးသုံးၾကရင္ bash history ကတစ္ခုထဲ။ကိုယ္ဘာလုပ္သြားလည္း ေနာက္လူက history မွာျပန္ၾကည့္လို႕ရတယ္ ။ တစ္ခါတစ္ေလ ကိုယ္ troubleshoot လုပ္ထားပံုကို ေနာက္လူကို မသိေစခ်င္ရင္ ဘယ္လိုလုပ္မလည္း ? ( Team ေတြ Department ေတြ ကြဲတဲ့ Company ေတြမွာ အခ်င္းခ်င္းျပိဳင္ဆိုင္မႈေတြ ရွိပါတယ္။ ဟိုဘက္ Team ကေကာင္ေတြ စသုံးမက်ဘူးလို႕ ေျပာဖို႕ ေစာင့္ေနၾကေတာ့ ကိုယ့္အလွည့္က်ရင္လည္း ကိုယ့္ knowledge ကို တျခား team ကိုမေပးခ်င္တာေတြ ရွိတတ္ပါတယ္။)
တစ္ခါတစ္ေလၾက audit ေပါ့။ Server မွာ ျပသနာ တစ္ခုခုျဖစ္သြားရင္ ၊ ဘယ္သူ႕ေၾကာင့္လည္း ျပန္ရွာတယ္။ ကိုယ္ကအမွားလုပ္လိုက္မိလို႕ ျပန္ fix လုပ္ျပီး ဖုံးထားခ်င္ရင္ေတာင္ bash history ကလိမ္ဖို႕ ခက္တယ္။bash_history file ကို edit လုပ္ရင္လည္း file integrity ပ်က္တယ္။ ေနာက္ျပီး edit လုပ္ထားမွန္းက ေဖ်ာက္ဖို႕မလြယ္ ။
ကဲ ကိုယ္႐ိုက္ထားတဲ့ command ေတြ ဘယ္လို ေဖ်ာက္ထားမလည္း ?
'history' command ရဲ့ output ကိုတစ္ခ်က္ၾကည့္ရေအာင္ ။
994 exit
995 cd /etc
996 ls
997 ls
998 vi rc.local
999 ps -ef|more
1000 exit
ဒီမွာ ဘယ္ဘက္က နံပါတ္ေတြကို offset လို႕ေခၚပါတယ္။ ညာဘက္ျခမ္းကေတာ့ command ေပါ့။ Offset number ကိုသိရင္ အဲ offset number ကို bash history ကေနဖ်က္ဖို႕ command ရွိပါတယ္။
'history' command မွာ '-d' ဆိုတဲ့ option ရွိပါတယ္ ။ ကိုယ္ဖ်က္ခ်င္တဲ့ command ကို history ကဖ်က္လို႕ရပါတယ္။ တစ္ခုပဲ ျပသနာက ။ 'history -d xx' ဆိုတဲ့ ဖ်က္လိုက္တယ္ဆိုတဲ့ line ၾကီးကေတာ့ history ထဲဝင္သြားတယ္။ ဥပမာ offset number 998 ( vi rc.local) ဆိုတာကို history ကဖ်က္ခ်င္တယ္ဆိုရင္ ' history -d 998' လို႕ ဖ်က္ရပါတယ္ ။ ဒါေပမဲ့ ေနာက္တစ္ခါ history ျပန္ၾကည့္ရင္ ဒီလိုၾကီး ေပၚလိမ့္မယ္။
994 exit
995 cd /etc
996 ls
997 ls
998 ps -ef|more
999 exit
1000 history -d 998
အဲေတာ့မွ ဘာဖ်က္ထားတာလည္းဆိုျပီး ရွုပ္ကုန္မွာ။ နည္းနည္း ပိုေကာင္းတဲ့ နည္းလမ္းေတြရွိပါတယ္ ။
Bash မွာ Shell Variable တစ္ခုရွိပါတယ္။ HISTCMD လို႕ေခၚတဲ့ Variable ပါ။ 'echo $HISTCMD' လို႕႐ိုက္ၾကည့္ရင္ နံပါတ္တစ္ခုကိုေပးပါလိမ့္မယ္။ အဲဒါက ေနာက္ command အတြက္ offset ပါ။ ခုနက 1000 အထိေရာက္ျပီးတဲ့ အခ်ိန္မွာ 'echo $HISTCMD' လို႕႐ိုက္ၾကည့္ရင္ 1002 ဆိုတဲ့ output ကိုေပးပါလိမ့္မယ္။ ဘာလို႕လည္းဆို 1000 က 'history -d 998' ဆိုတဲ့ command ျဖစ္ျပီး echo $HISTCMD က 1001 ပါ။ အဲေတာ့ output က ေနာက္ command အတြက္ ရမယ့္ offset 1002 လို႕ရတာပါ။ ဒီ Variable ကိုသုံးျပီး bash history ကိုလိမ္လို႕ရပါတယ္။
$HISTCMD က ေနာက္လာမဲ့ command ရဲ့ offset ကိုေပးတယ္လို႕ ခုနကေျပာထားတယ္ေနာ္။ $HISTCMD-1 ဆိုရင္ လက္ရွိ command ရဲ့ offset ေပါ့။ 'history -d (($HISTCMD-1)) ဆိုရင္ ဒီ command ကို bash history ကေန ျပန္ျပန္ဖ်က္ေနတာနဲ႕ အတူတူပဲ။
ေနာက္တစ္ခု သိရမွာက Bash ရဲ့ operator ေတြပါ ။ Bash ရဲ့ '&&' ဆိုတဲ့ operator က 'AND' ကို ကိုယ္စားျပဳပါတယ္။ Command ႏွစ္ခုကို တစ္ခုျပီး တစ္ခု ဆက္လုပ္သြားဖို႕ သုံးပါတယ္။ Package compilation အတြက္ 'make && make install' ဆိုတာမ်ိဳး႐ိုက္ျပီး ထမင္းသြားစာတာမ်ိဳးေပါ့။ ပထမ command က completed successful ျဖစ္ရင္ ဒုတိရ command ကို ဆက္အလုပ္လုပ္ပါတယ္။ Error ျဖစ္သြားရင္ေတာ့ ရပ္သြားတယ္။ Command ႏွစ္ခုျဖစ္ေပမဲ့ Bash History မွာေတာ့ offset တစ္ခုနဲ႕ entry တစ္ခုပဲ ဝင္ပါတယ္။
1003 ls -l && history
ကဲ ဒီေလာက္ဆို မွန္းမိေလာက္ပါျပီ ။ ႐ိုက္ခ်င္တဲ့ command ကို႐ိုက္ ၊ ျပီးရင္ေနာက္က && ခံျပီး 'history -d (($HISTCMD-1))' ထဲ့႐ိုက္ရင္ ကိုယ္႐ိုက္သမွ် bash history ထဲ မေရာက္ေတာ့ဘူး။ ဒါမ်ိဳးေပါ့ ..
# rm -rf /etc && history -d (($HISTCMD-1))
ဒါဆို /etc ကို ဖ်က္လိုက္တဲ့ command က history ထဲမေရာက္ေတာ့ဘူး။ 'history -d' ကို အေရွ႕မွာထားထား အေနာက္မွာထားထား တူတူပါပဲ။ တစ္ခါတစ္ေလ ေနာက္က ထဲ့႐ိုက္ဖို႕ေမ့သြားရင္လို႕ bash history ထဲေရာက္သြားရင္ေတာ့ ဒီလို ကြန္႕လိုက္ေပါ့။ ဒါဆို ေနာက္ဆုံး history ႏွစ္ခု ဖ်က္သြားလိမ့္မယ္။ ေရွ႕က ေမ့သြားတဲ့ command ေရာ ၊ ဒီဖ်က္တဲ့ဟာကိုေရာ။
# history -d $((HISTCMD-2)) && history -d $((HISTCMD-1))
Catch တစ္ခုေတာ့ ရွိပါတယ္။ ဒါက Bash Variable ပါ ။ ဒါေတာင္ Bash version အေဟာင္းေတြမွာ ဒီ Variable မရွိပါဘူး။ ksh တို႕ဘာတို႕မွာလည္း မရွိဘူး ထင္တယ္။ HISTCMD မရွိရင္ နည္းနည္း ေလး အလုပ္ပိုပါတယ္။
TMP=$(history | tail -1 | awk '{print $1}') && history -d $TMP
ဒါလည္း ေရွ႕ကထားထား ေနာက္ကထားထား ရပါတယ္ ။
႐ိုက္ရတာ ရွုပ္ရင္ ကိုယ့္ bashrc ထဲမွာ ကိုယ့္ဟာကို alias ေပးထားလိုက္ေပါ့ ။ ဒါေပမယ့္ trace မက်န္ေအာင္ဖ်က္ပါတယ္ဆို bashrc မွာ trace ၾကီးက်န္ေနမွာေတာ့ မမိုက္ပါဘူး ၊ ဒါေပမဲ့ က်ေနာ္လို lazy ေတြကေတာ့ ဝင္ဝင္ခ်င္း alias ေလးေပး ၊ ျပီး session close မလုပ္ခင္မွာ bashrc ကေန ျပန္ဖ်က္ျပီး အေပၚမွာေပးထားတဲ့အတိုင္း ေနာက္ဆုံး command ႏွစ္ခုဖ်က္ခဲ့လိုက္တယ္။
တစ္ခုေတာ့ Caution ေပးပါတယ္။ တစ္ခ်ိဳ႕ environment မွာ VPN နဲ႕မွ servers ေတြကို ဝင္လို႕ရျပီး VPN မွာ keystroke log လုပ္ထားတတ္ပါတယ္။ ဒါဆိုရင္ေတာ့ ဟဲဟဲ ။
ကဲ ကိုယ့္ trace ကိုယ္ ေဖ်ာက္ႏိုင္ပါေစ ။ က်ေနာ္ သိတဲ့ ၊ သုံးတဲ့ technique တစ္ခုကို share တာပါ ။ က်ေနာ္မသိတဲ့ catch ရွိေကာင္းရွိႏိုင္ပါတယ္ ။
Divinity
Tuesday, April 3, 2012
လာျပန္ျပီ Spam ေတြ
# mailq | grep marketing@blahblah\.com | cut -d ' ' -f1 | tr -d '*!' | postsuper -d -
မေန႕က ထမင္းစားေနတုန္း ၊ Mail server ၾကီးက respond ေႏွးလို႕တဲ့ ။ ဒါကပုံမွန္လိုျဖစ္ေနလို႕ က်ေနာ္လည္း သိပ္ေတာင္ ဂ႐ုမစိုက္မိဘူး။ Mail Server က dedicated လည္းမဟုတ္ ။ ဒီ Server ေပၚမွာ Website 200 ေက်ာ္ ၊ Database 100 ေက်ာ္ ၊ DNS server အပါအဝင္ တျခား service ေတြကရွိေသးတယ္။ Mail Server က Postfix သုံးျပီး Domain 200 ေက်ာ္အတြက္ Mailbox 3000 ေလာက္ရွိတယ္။ Server က အေဟာင္း၊ ေရွ႕မွာ IPS ေလာက္မဟုတ္ရင္ေတာင္ spam filter ေကာင္းေကာင္းခံဖို႕ ေျပာတာ သုံးႏွစ္ေလာက္ရွိျပီ ။ ဒီတိုင္းပဲ ။ Website ေတြ ဘာျဖစ္ျဖစ္က က်ေနာ္တို႕ ဂ႐ုမစိုက္လို႕ရေပမယ့္ spam ဝင္လို႕ Server MTA နဲ႕ Spamd က ေလးလာရင္ ၊ mail delivery ေႏွးလာရင္ က်ေနာ္တို႕ ဖုန္းေတြ အဆက္မျပတ္ျမည္ပါျပီ ။ Server ကလည္း သိပ္ေကာင္းလွတာမဟုတ္ေတာ့ Mail Queue ထဲမွာ သုံးေထာင္ေလာက္ရွိရင္ စေလးလာေလ့ရွိပါတယ္။ ငါးေထာင္ေလာက္ဆို ေဘးခ်င္းကပ္ပို႕ရင္ေတာင္ ဆယ္မိနစ္ေလာက္ေနမွေရာက္တယ္။ Server ေပၚမွာက Opensource Spam filter တစ္မ်ိဳးပဲရွိတာမို႕ သိပ္ handle မလုပ္ႏိုင္ပါဘူး။ သူကလည္း 60% efficiency ေလာက္ပဲရွိတယ္ထင္တယ္။ ဘယ္ေတာ့မွ Spam ကိုႏိုင္တယ္လို႕မရွိဘူး။ ဒါမ်ိဳးက ျဖစ္ေနၾကမို႕လို႕ မေန႕က ဖုန္းေတြလာေတာ့ ေအးေဆးပဲ ။ ထမင္းစားေနလို႕ ျပီးရင္ ၾကည့္လိုက္မယ္လို႕ ေျပာလိုက္တယ္ ။
ရုံးျပန္ေရာက္ေတာ့လည္း က်ေနာ္က အလုပ္ထြက္ေတာ့မယ့္လူမို႕လို႕ ေတာ္႐ံု က်ေနာ္ ဝင္မပါပါဘူး။ က်ေနာ္ေနရာရဲ့ replacement အစ္ကိုၾကီးကလည္း ဒီေန႕ off ပါတယ္။ အငယ္တစ္ေယာက္ပဲရွိတယ္။ ဒါေပမဲ့ သူက က်ေနာ္စီက ဒီ hosting service ေတြကို handover လုပ္ယူထားရတဲ့ သူ ၊ ေနာက္ျပီး သူက Redhat certified System Administrator ။ အဟဲ ။ သူ မသိရင္ေတာင္ သူကသင္ရင္ သိပ္မၾကိဳက္ဖူး။ သူ႕ကိုပဲ Mail Service မွာ spam ဝင္တယ္ထင္တယ္ ၾကည့္လိုက္အုန္းလို႕ေျပာလိုက္မိတယ္။ Spam ဝင္ရင္ mailq မွာ deferred ေတြ ဘယ္လို ဖ်က္ဆိုတာေလာက္ေတာ့ သူ႕ကို ျပထားဖူးတယ္။ သူကလည္း CD drive ထဲသာ DVD ထဲ့ျပီး ဒီ server က boot မတက္ဘူးေျပာရင္ေျပာတာ၊ ဒါမ်ိဳးခိုင္းရင္ သူသိတယ္ ဆိုတာၾကီးပဲ။ လူေရွ႕မွာ သိပ္သင္လို႕ မရဘူး။ သူက က်ေနာ့ထက္ အသက္ေရာ လုပ္သက္ေရာၾကီးပါတယ္။ ဘာေတြလုပ္ေနခဲ့လည္းေတာ့ သိပ္မေသခ်ာဘူး။
သုံးနာရီေလာက္ အထိ mail send / receive ေႏွးေနေသးတာ က်ေနာ္သိပါတယ္။ ေရာက္လား မေရာက္လားသာ မသိတာ ။ ဒါေပမဲ့ accountability အတြက္ production server ေတြကို က်ေနာ္ login မဝင္ေတာ့ပါဘူး။ ဒါက်ေနာ့ ေနာက္ဆုံး အပတ္ေလ။ သူလည္း ၾကိဳးစားပန္းစားလုပ္ေနေတာ့ အဆင္ေျပလား သြားေမးလိုက္ေသးတယ္။ ေနာက္ေတာ့ GM က ဖုန္းဆက္တယ္။ ၾကည့္လိုက္ပါတဲ့ ၊ ငါ့ဖုန္း ၾကာရင္ explode ျဖစ္ေတာ့မယ္တဲ့။ Reseller ေတြကလည္း တဂြမ္ဂြမ္ဆက္ေနျပီ ။ ျဖစ္ေနတာ သုံးနာရီေလာက္ ရွိသြားျပီကိုး။
Login ဝင္ျပီး အရင္ဆုံး Mail Queue ကိုၾကည့္မိတယ္ ။ လြယ္လြယ္ကူကူ
# mailq | tail
လို႕ ၾကည့္ေတာ့ ေတာ္ေတာ္နဲ႕ return မလာဘူး ။ ေတာ္ေတာ္မ်ားေနလို႕ျဖစ္မယ္ လို႕စဥ္းစားျပီး mailq ပဲ႐ိုက္ၾကည့္လိုက္တယ္ ။ အဲမွာ စေတြ႕တာပဲ ။ ပုံမွန္ ေလးငါးေထာင္ေလာက္ဆိုရင္ mailq က ဆယ္စကၠန့္ေလာက္အတြင္းမွာတင္ ဆုံးပါတယ္။ ေပၚလာတာကလည္း ျမန္လို႕ လိုက္ဖတ္ဖို႕ မမွီပါဘူး။ ဒီတစ္ေခါက္ေတာ့ တစ္မ်က္ႏွာခ်င္း ေျဖးေျဖးခ်င္းေပၚေနတယ္။ ေတာ္ေတာ္ၾကာတဲ့အထိလည္း မျပီးေတာ့ escape လိုက္တယ္ ။ top နဲ႕ၾကည့္ေတာ့ load က postfix-queue process က အျမဲတန္း CPU usage 40% ေလာက္ တက္ေနတယ္။ ဒီေလာက္နဲ႕ေတာ့ mailq က အဲေလာက္ ေႏွးမေနသင့္ဘူးေပါ့။ အခုက mailq ထဲ mail ဘယ္ေလာက္ရွိေနမွန္းကို မသိရေသးဘူး။
ခုနက mailq ၾကည့္တုန္းက marketing@blahblah.com ဆိုတဲ့ mail ေတြ အမ်ားၾကီးေတြ႕လိုက္တယ္ ။ ျမင္လိုက္သမွ်အားလုံးနီးပါး သူ့ mail ေတြၾကီးပဲ။ အဲဒီ client ကိုလည္း က်ေနာ္သိပါတယ္။ ေတြ႕ကရာ click ျပီး မၾကာမၾကာ virus ဝင္ေလ့ရွိသလို password ကိုလည္း password တို႕ 123456 တို႕ သိပ္ေပးလြန္းလို႕ မၾကာမၾကာ ျပသနာ တက္ေလ့ရွိတယ္။ သူတို႕ mail address တစ္ခု ျပသနာျဖစ္ျပန္တာလား၊ သူတို႕ပဲ mail advertisement ကို စြတ္လုပ္ေနသလားမသိဘူး။ Maillog မွာ သြားရွာၾကည့္ေတာ့ ဒီ mail address marketing@blahblah.com ဆိုျပီး IP အစုံကေန authenticate လုပ္ထားတာေတြ႕လိုက္တယ္။ သြားျပီဆိုတာ ေသခ်ာပါတယ္။ သူတို႕ကို ဖုန္းဆက္အေၾကာင္းၾကားေပးဖို႕ တစ္ေယာက္ကိုေျပာလိုက္တယ္။
ဘယ္သူ႕မ်က္ႏွာမွမၾကည့္ပဲ ၊ ဖ်က္စရာရွိတာ ဖ်က္ တဲ့ေနရာမွာ က်ေနာ္ ထိပ္ဆုံးကပါမယ္ထင္တယ္။ ဘာမွလည္း ၾကည့္လို႕မရေတာ့ အရင္ဆုံး postfix service ကို ခဏပိတ္လိုက္တယ္။ Lag ေနတာလည္း ေတာ္ေတာ္ၾကာျပီမို႕ တစ္မိနစ္ေလာက္ downtime က ေျပာပေလာက္ေအာင္မရွိဘူးလို႕ ယူဆလိုက္တယ္။ Service ပံုမွန္ ျပန္ျဖစ္ဖို႕ ခဏေတာ့ အနစ္နာခံရမွာပဲ။
# service postfix stop
အဲဒီ mail address ကေန mail ပို႕တာကို temporary barred လိုက္ပါတယ္ ။ ဘယ္လိုလုပ္လည္းဆိုရင္ေတာ့ Postfix မွာ smtpd_recipient_restrictions နဲ႕ smtpd_sender_restrictions ဆိုတာရွိပါတယ္။ အဲမွာ ဘယ္ mail address ကေနလာတဲ့ mail ၊ သို႕မဟုတ္ ဘယ္ mail address ကို ပို႕မယ့္ mail ကို drop ေပးပါလို႕ configure လို႕ရပါတယ္။ အဲမွာ marketing@blahblah.com ကို smtpd_sender_restrictions မွာ ထဲ့လိုက္ပါတယ္။ ေနာက္ေတာ့ အရင္ postfix service ကိုျပန္စလိုက္တယ္။
# service postfix start
ေနာက္ျပီး mailq ထဲမွာ marketing@blahblah.com က mail ဘယ္ေလာက္ရွိသလည္းလို႕ သိခ်င္လို႕ ဒီ command ေလး run ၾကည့္တယ္။
# mailq | grep marketing@blahblah\.com | wc -l
ဒါေပမဲ့ ခုနက ဒီအတိုင္း mailq ႐ိုက္တာေတာင္ result ကမဆုံးတာ ၊ ဒီလိုလည္း ေတာ္ေတာ္နဲ႕ result မရပါဘူး။ အဲဒီမွာပဲ client ကအေၾကာင္းျပန္တယ္။ သူတို႕ ဒီေန႕ အဲ marketing email ကေန ဘာမွမပို႕ပါဘူးတဲ့။ Password က password လို႕ေပးထားေၾကာင္း အေၾကာင္းျပန္တယ္။ ဒါဆို mail queue ထဲကဟာေတြက က်ေနာ္တို႕ဖ်က္ျပစ္လိုက္လို႕ရတာ ေသခ်ာပါျပီ။ အမွန္က မေသခ်ာလည္း က်ေနာ္ဖ်က္ဖို႕ပါပဲ။ သူတို႕ဟာေတြဆိုလည္း ေနာက္မွ ျပန္ပို႕ပါလို႕ ေျပာျပီး ဖ်က္မွာပါပဲ။
ကဲ ဘယ္လိုဖ်က္မလည္း ? Mail ID ေတြကလည္းမသိ၊ mailq ကလည္း ၾကည့္မရေတာ့ ဘယ္ေလာက္ရွိမွန္းလည္းမသိ ၊ queue တစ္ခုလုံး flush ျပစ္လိုက္ရင္လည္း ေပါက္ဆိန္နဲ႕ ေပါက္သလိုျဖစ္ေတာ့မယ္ ။ Script ေလးတစ္ေၾကာင္း ေရးလိုက္လို႕ရရင္ ေကာင္းမယ္ ။ ပထမဆုံး mailq ရဲ့ output ကို ၾကည့္ရေအာင္။
0BEA87C8029* 111654 Tue Apr 3 10:56:46 marketing@blahblah.com
Database စကားနဲ႕ ေျပာရင္ primary key က ေရွ႕ဆုံးကေကာင္ Mail ID / Queue ID ။ ဒါက Queue ထဲရွိသမွ် mail တိုင္းမွာ unique ျဖစ္တယ္။ SQL မွာ select .. where .. ဆိုျပီး ေရးရသလိုပါပဲ ။ marketing@blahblah.com က mail ေတြကိုစစ္ထုတ္ျပီး delete လိုက္ရင္ ရမယ္။ Mail ကို Queue ထဲက delete လုပ္တာက postsupre -d ။ ဒါေပမယ့္ ID ေသခ်ာ ေပးမွျဖစ္မွာ ။ ကဲ ဆက္ေရးၾကည့္မယ္။
ခုနက result ေတြထဲက marketing@blahblah.com ဆိုတဲ့ address ပါတဲ့ result ေတြကိုပဲ ယူမယ္ ။
# mailq | grep marketing@blahblah\.com
ခုနက result မွာ က်ေနာ္တို႕လိုတာ ေရွ႕ဆုံးက ID ၊ ေနာက္က time stamp ေတြဘာေတြ မလိုခ်င္ဘူး filter လုပ္ဖို႕လိုျပီ ။
# mailq | grep marketing@blahblah\.com | cut -d ' ' -f1
အဲမွာလည္း ID မွာ * ေတြ ပါတယ္။ Queue ထဲမွာ Active ျဖစ္ေနတယ္လို႕ ျပတာပါ။ အဲ asterisk ကိုလည္း ဖ်က္မွ ၊ မဟုတ္ရင္ postsuper က အလုပ္လုပ္ႏိုင္မွာမဟုတ္ဖူး ။
# mailq | grep marketing@blahblah\.com | cut -d ' ' -f1 | tr -d '*!'
ဒီေလာက္ဆို က်ေနာ္လိုခ်င္တဲ့ marketing@blahblah.com ကလာတဲ့ mail ေတြရဲ့ ID တစ္လုံးထဲ ရျပီ ။ အဲဒါကို postsuper ကို pass ေပးလိုက္ျပီး ဖ်က္လိုက္ရင္ ရပါျပီ ။
# mailq | grep marketing@blahblah\.com | cut -d ' ' -f1 | tr -d '*!' | postsuper -d -
58964 messages deleted တဲ့ ။ ပလုတ္တုတ္ ။ ဒီ mail address ကေနဝင္လာတဲ့ mail ၊ Queue ထဲမွာတင္ ေျခာက္ေသာင္းေလာက္ရွိတယ္။ အဲကလာတာ မဟုတ္တဲ့ mail ၊ Queue ထဲမွာ ႏွစ္ေထာင္ေက်ာ္ က်န္ပါတယ္။ Spam ေတြရွုပ္ေနတာနဲ႕ deliver မလုပ္ႏိုင္ေသးတဲ့ mail ေတြေပါ့။
အဲေနာက္မွာေတာ့ mail server က ပံုမွန္ ျပန္ျဖစ္သြားပါတယ္။ marketing@blahblah.com က mail ေတြ အဝင္ကေတာ့ရွိဆဲ။ ဒါေပမဲ့ deliver attempt မလုပ္ေတာ့ပဲ တန္း drop ေတာ့ load သက္သာတာေပါ့။ ဒါေပမဲ့ traffic နဲ႕ socket ကေတာ့ စားဆဲမို႕လို႕ ေနာက္ေတာ့ သူတို႕ marketing email ကို temporary deactivate လိုက္ပါတယ္ ။ အဲေတာ့မွ Queue ထဲက ေကာင္ေတြ ေကာင္းေကာင္းမြန္မြန္ ထြက္ေတာ့တယ္။
တစ္ေၾကာင္း bash script ေလးပါပဲ ။ ဒါေပမဲ့ ျပသနာ ေတာ္ေတာ္ ေျပလည္သြားတယ္ ။ ညေန ေျခာက္နာရီအထိ အားလုံး အဆင္ေျပေနတာနဲ႕ စီးတီးေဟာကို ထမင္းစားဖို႕ သြားလိုက္ႏိုင္တယ္ ။ ေတာ္ပါေသးရဲ့ ။ ေတာ္ၾကာ ထြက္ခါနီးမွ ထြက္ခတ္ခတ္ျပီး မိုးခ်ဳပ္ေအာင္ ေနေနရအုန္းမယ္။
Divinity
Friday, March 30, 2012
Linux commands (2)
အသုံးတည့္တဲ့ Linux command ေလးေတြ ၊ bash shell မွာ သုံးလို႕ရတဲ့ ပံုစံေလးေတြ ဟိုးအရင္ကေရးဖူးပါတယ္ ။
Linux commands (1)
အခုက်ေနာ္တို႕ ေန႕စဥ္ အသုံးမ်ားတဲ့ command ေလးေတြကို ၾကည့္ရေအာင္။
top
top command က Linux မွာေတာ့ Task Manager ပါပဲ။ လက္ရွိ run ေနတဲ့ process ေတြရဲ့ PID ေတြ CPU usage ၊ Memory usage ေတြျပပါတယ္ ။ Process တစ္ခုခုက CPU usage အရမ္းမ်ားေနသလား ၊ လိုအပ္တာထက္ျပီျပီး memory usage တက္ေနလား top ကေနၾကည့္ေလ့ရွိပါတယ္။
ဒါ Linux Administrator ေတြ အလုပ္လုပ္ခ်င္ေယာင္ေဆာင္တဲ့ command ပါ။ ဘာအလုပ္မွ မရွိရင္ terminal ေလးတစ္ခုဖြင့္ top ေလး run ထားျပီး အလုပ္လုပ္ေနသလိုလို အေယာင္ေဆာင္ေနလို႕ရတယ္။ Process ေတြက တက္လာလိုက္ ေပ်ာက္သြားလိုက္ေန ၊ terminal ေပၚမွာ ရွုပ္ေနေတာ့ မသိတဲ့လူၾကည့္ရင္ အလုပ္ေတြ လုပ္ေနတယ္ထင္မွာပဲ။
kill / killall
Process တစ္ခုခု hang ေနရင္ပဲျဖစ္ျဖစ္ ၊ မလိုအပ္တဲ့ process မို႕လို႕ end လုပ္ခ်င္ရင္ပဲျဖစ္ျဖစ္ linux မွာေတာ့ kill တယ္လို႕ သုံးပါတယ္။ kill နဲ႕ killall ဘာကြာလည္းဆို ေယဘူရေျပာရရင္ေတာ့ kill က PID နဲ႕ kill ရျပီးေတာ့ killall ကေတာ့ process name နဲ႕ သုံးပါတယ္။ killall မွာ interactive mode တို႕ ၊ specific user's process ပဲ kill တာတို႕လုပ္လို႕ရပါတယ္ ။
man
Nix user ေတြ Admin ေတြ ဘယ္လိုမွ ကင္းရွင္းေအာင္ေနလို႕မရတဲ့ command ပါပဲ။ Command တစ္ခုခုရဲ့ sub command ေတြ parameter ေတြ syntax ေတြေမ့ေနရင္ man နဲ႕ ျပန္ၾကည့္ရတာပဲ။ Manual ဆိုတဲ့ စကားလုံးကို အတိုေခၚတာပါ။ Man page လို႕ေခၚတဲ့ command manual ကို ျပန္ေဖာ္ျပပါတယ္။
ls
ေန႕တိုင္း သုံးၾကတဲ့ command တစ္ခုပါ။ DOS ရဲ့ dir command ရဲ့ Linux version ေပါ့။ List ဆိုတဲ့ စကားလုံးကို အတိုယူထားတာပါ။ ls ပဲ႐ိုက္ရင္ file / folder list ပဲျပပါတယ္။ ls -l ဆိုရင္ေတာ့ file size ေတြ ၊ time stamp ေတြနဲ႕ျပပါတယ္။ File size ကို MB ေတြ GB ေတြနဲ႕ ျပေစခ်င္ရင္ ls -lh လို႕ ႐ိုက္ရပါတယ္။
pwd
လက္ရွိ ကိုယ္ဘယ္ path ေအာက္မွာ ေရာက္ေနလည္း ျပန္ျပန္ၾကည့္တဲ့ command ပါ။ Print Working Directory ဆိုတာကို အတိုေခၚတာပါ။ တစ္ခါတစ္ေလ ကိုယ့္ home directory ထဲက backup file ကို ျပင္ေနမိတာလား ၊ /etc/ ေအာက္က တကယ့္ config file ကို ျပင္ေနမိတာလားမေသခ်ာရင္ ကိုယ္ဘယ္ေရာက္ေနလည္း ျပန္ၾကည့္ရတာေပါ့ ။
Linux command ေတြက ေျပာရရင္ အမ်ားၾကီးပါ ။ ေန႕တိုင္း သုံးျဖစ္တာေလးေတြေလာက္ပဲ အခု ေရးထားတာပါ ။ ေန႕တိုင္းမဟုတ္ေပမဲ့ မၾကာမၾကာ သုံးတဲ့ less / more တို႕ tar တို႕ tail / head တို႕ ေနာက္မွ ေရးေတာ့မယ္ ။ Linux command list ကို ဒီေအာက္က link မွာ ၾကည့္ႏိုင္ပါတယ္ ။
Linux commands (1)
အခုက်ေနာ္တို႕ ေန႕စဥ္ အသုံးမ်ားတဲ့ command ေလးေတြကို ၾကည့္ရေအာင္။
top
top command က Linux မွာေတာ့ Task Manager ပါပဲ။ လက္ရွိ run ေနတဲ့ process ေတြရဲ့ PID ေတြ CPU usage ၊ Memory usage ေတြျပပါတယ္ ။ Process တစ္ခုခုက CPU usage အရမ္းမ်ားေနသလား ၊ လိုအပ္တာထက္ျပီျပီး memory usage တက္ေနလား top ကေနၾကည့္ေလ့ရွိပါတယ္။
ဒါ Linux Administrator ေတြ အလုပ္လုပ္ခ်င္ေယာင္ေဆာင္တဲ့ command ပါ။ ဘာအလုပ္မွ မရွိရင္ terminal ေလးတစ္ခုဖြင့္ top ေလး run ထားျပီး အလုပ္လုပ္ေနသလိုလို အေယာင္ေဆာင္ေနလို႕ရတယ္။ Process ေတြက တက္လာလိုက္ ေပ်ာက္သြားလိုက္ေန ၊ terminal ေပၚမွာ ရွုပ္ေနေတာ့ မသိတဲ့လူၾကည့္ရင္ အလုပ္ေတြ လုပ္ေနတယ္ထင္မွာပဲ။
kill / killall
Process တစ္ခုခု hang ေနရင္ပဲျဖစ္ျဖစ္ ၊ မလိုအပ္တဲ့ process မို႕လို႕ end လုပ္ခ်င္ရင္ပဲျဖစ္ျဖစ္ linux မွာေတာ့ kill တယ္လို႕ သုံးပါတယ္။ kill နဲ႕ killall ဘာကြာလည္းဆို ေယဘူရေျပာရရင္ေတာ့ kill က PID နဲ႕ kill ရျပီးေတာ့ killall ကေတာ့ process name နဲ႕ သုံးပါတယ္။ killall မွာ interactive mode တို႕ ၊ specific user's process ပဲ kill တာတို႕လုပ္လို႕ရပါတယ္ ။
man
Nix user ေတြ Admin ေတြ ဘယ္လိုမွ ကင္းရွင္းေအာင္ေနလို႕မရတဲ့ command ပါပဲ။ Command တစ္ခုခုရဲ့ sub command ေတြ parameter ေတြ syntax ေတြေမ့ေနရင္ man နဲ႕ ျပန္ၾကည့္ရတာပဲ။ Manual ဆိုတဲ့ စကားလုံးကို အတိုေခၚတာပါ။ Man page လို႕ေခၚတဲ့ command manual ကို ျပန္ေဖာ္ျပပါတယ္။
ls
ေန႕တိုင္း သုံးၾကတဲ့ command တစ္ခုပါ။ DOS ရဲ့ dir command ရဲ့ Linux version ေပါ့။ List ဆိုတဲ့ စကားလုံးကို အတိုယူထားတာပါ။ ls ပဲ႐ိုက္ရင္ file / folder list ပဲျပပါတယ္။ ls -l ဆိုရင္ေတာ့ file size ေတြ ၊ time stamp ေတြနဲ႕ျပပါတယ္။ File size ကို MB ေတြ GB ေတြနဲ႕ ျပေစခ်င္ရင္ ls -lh လို႕ ႐ိုက္ရပါတယ္။
pwd
လက္ရွိ ကိုယ္ဘယ္ path ေအာက္မွာ ေရာက္ေနလည္း ျပန္ျပန္ၾကည့္တဲ့ command ပါ။ Print Working Directory ဆိုတာကို အတိုေခၚတာပါ။ တစ္ခါတစ္ေလ ကိုယ့္ home directory ထဲက backup file ကို ျပင္ေနမိတာလား ၊ /etc/ ေအာက္က တကယ့္ config file ကို ျပင္ေနမိတာလားမေသခ်ာရင္ ကိုယ္ဘယ္ေရာက္ေနလည္း ျပန္ၾကည့္ရတာေပါ့ ။
Linux command ေတြက ေျပာရရင္ အမ်ားၾကီးပါ ။ ေန႕တိုင္း သုံးျဖစ္တာေလးေတြေလာက္ပဲ အခု ေရးထားတာပါ ။ ေန႕တိုင္းမဟုတ္ေပမဲ့ မၾကာမၾကာ သုံးတဲ့ less / more တို႕ tar တို႕ tail / head တို႕ ေနာက္မွ ေရးေတာ့မယ္ ။ Linux command list ကို ဒီေအာက္က link မွာ ၾကည့္ႏိုင္ပါတယ္ ။
http://www.oreillynet.com/linux/cmd/
Thursday, March 29, 2012
chkconfig script သို႕မဟုတ္ init script
ဟိုေန႕က client တစ္ခုက အင္ဂ်င္နီယာက သူဟာဟာသူေရးထားတဲ့ script တစ္ခုကို server boot time မွာ run ခ်င္လို႕တဲ့ လွမ္းေမးတယ္ ။ သူတို႕ က RHEL 6 သုံးေနတာပါ ။ အဲဒါနဲ႕ init script ေလးေရးျပီး init.d ထဲထဲ့ထားလိုက္လို႕ ျပန္ေျပာလိုက္တယ္။ ေနာက္ေန႕က် ေရးေပးပါတဲ့။ သူက ဘာ script run ခ်င္မွန္းမသိတာနဲ႕ template ပံုစံေလးေရးေပးလိုက္တယ္။
( Note: blogspot မွာ script ေရးျပရတာ ေတာ္ေတာ္ စိတ္ညစ္စရာ ေကာင္းတာပဲ syntax အကုန္ေပ်ာက္ျပီး left align ေတြျဖစ္ကုန္တယ္ )
(script) ဆိုတဲ့ ေနရာေလးေတြ မွာ ကိုယ့္ script နဲ႕ အစားထိုးပါလို႕ဆိုျပီး ေပးလိုက္တယ္ ။ အဆင္ေျပသြားတယ္တဲ့ ။ Init script က ဒီ syntax နဲ႕ပဲ အလုပ္လုပ္ပါတယ္ ။ ကိုယ့္ဟာကိုယ္ တျခား script တစ္ခုခုကို စခ်င္လည္း ဒီ template ကိုသုံးလို႕ရပါတယ္ ။ အေရးၾကီးတာ No.4 လိုင္းပါ ။ အဲမွာ chkconfig 235 35 55 လို႕ေပးထားပါတယ္ ။
အေရွ႕ဆုံးက 235 ဆိုတာက ဒီ script ကို run မဲ့ runlevel ေတြပါ ။ Runlevel ဆိုတာ ဘာလည္းမေသခ်ာရင္ ရွာဖတ္ၾကည့္ေစခ်င္ပါတယ္။ ပံုမွန္အားျဖင့္ 0 to 6 ရွိပါတယ္ ။
ဒီ init script မွာဆို လိုခ်င္တဲ့ service / script ကို runlevel 2 , 3 နဲ႕ 5 မွာပဲ စမယ္လို႕ ေျပာထားပါတယ္ ။
အေနာက္က 35 နဲ႕ 55 က script ကို boot up time မွာစမဲ့ priority နဲ႕ shutdown time မွာ kill မဲ့ priority ပါ။ /etc/rcx.d/ ထဲမွာ script ေတြကို S55httpd ၊ K55httpd ဆိုျပီး အေရွ႕မွာ Sxx ၊ Kxx ေတြနဲ႕ ရွိေလ့ရွိပါတယ္။ ဒါကဘာကို ေဖာ္ျပတာလည္းဆိုရင္ ၊ ဆိုၾကပါစို႕ rc3.d ထဲမွာ S10sshd နဲ႕ S55httpd ဆိုျပီးရွိတယ္ ။ ဒါဆို တကယ္လို႕ server က runlevel 3 ကို run တယ္ဆိုရင္ Inittab က rc3.d ထဲက start script ေတြကို အစီအစဥ္အလိုက္ စပါတယ္ ။ ဒီမွာဆို S10 ျဖစ္တဲ့ sshd က အရင္စပါလိမ့္မယ္ ၊ ေနာက္မွ S55 ျဖစ္တဲ့ httpd က စပါလိမ့္မယ္။ အဲေတာ့ ကိုယ့္ script ကို ေစာေစာစီးစီး စေစခ်င္ရင္ အဲမွာ 35 ေနရာမွာ နံပါတ္ေသးေသး ေပးရပါလိမ့္မယ္ ။ rcx.d ကို ဖြင့္ၾကည့္ရင္ ကိုယ့္ script က ဘယ္အခ်ိန္ေလာက္မွာ စရင္ အဆင္ေျပမလည္း စဥ္းစားလို႕ရမွာပါ။ အေနာက္က 55 က လည္း ထိုနည္းတူပါပဲ ။ Shutdown လုပ္တဲ့အခ်ိန္မွာ ေစာေစာ kill ေစခ်င္ရင္ နံပါတ္ေသးေသးေပးပါ။ ေနာက္ဆုံးမွ kill ေစခ်င္ရင္ 99 လို႕ေပးလိုက္ပါ။
ဒီ init script က သူ run ခ်င္တာကို root အေနနဲ႕ run ဖို႕ ေရးထားတာပါ ။ တကယ္လို႕ တျခား user အေနနဲ႕ run ခ်င္ရင္ လိုင္းနံပါတ္ 9 မွာ su ကိုသုံးရပါမယ္ ။ ဒါဆို ဒီလိုျဖစ္သြားမယ္
Stop လုပ္တဲ့ အပိုင္းကေတာ့ လြယ္လြယ္ကူကူ PID ကိုရွာျပီး kill လိုက္တာပဲ ေရးထားပါတယ္ ။
ျပီးရင္ေတာ့ ဒီ init script ေလးကို /etc/init.d/ ေအာက္ထဲမွာ သြားထားရပါမယ္။ testscript လို႕ filename ကိုေပးလိုက္တယ္ ဆိုပါေတာ့။ ျပီးရင္ ဒါကို executable ျဖစ္ေအာင္ ေပးရပါတယ္။ ဒီ command ကို႐ိုက္ပါ ။
ျပီးရင္ chkconfig မွာ register လုပ္ရပါတယ္ ။ /etc/init.d ေအာက္ထဲမွာရွိတိုင္း rcx.d မွာမရွိပါဘူး ။ အဲထဲကို သက္ဆိုင္ရာ S နံပါတ္ K နံပါတ္နဲ႕ ေရာက္ေအာင္က register ရပါတယ္ ။
အဲဒါျပီးရင္ ကိုယ့္ရဲ့ script က server bootup တိုင္းမွာ သူ့ဘာသာသူ start ေနပါလိမ့္မယ္
( Note : rcx.d ဆိုတာ nix နဲ႕ နဲနဲ ရင္းႏွီးရင္ သိပါတယ္။ /etc ေအာက္မွာ rc1.d ၊ rc2.d ဆိုျပီး rc5.d အထိရွိပါတယ္ ။ သက္ဆိုင္ရာ runlevel မွာ စတဲ့ service ေတြရဲ့ start script ၊ stop script ေတြက အဲဒီထဲမွာရွိပါတယ္ ။ )
Divinity
( Note: blogspot မွာ script ေရးျပရတာ ေတာ္ေတာ္ စိတ္ညစ္စရာ ေကာင္းတာပဲ syntax အကုန္ေပ်ာက္ျပီး left align ေတြျဖစ္ကုန္တယ္ )
#! /bin/bash
# (script) init script
###
# chkconfig: 235 35 55
# description: Starting ( your script ) at boot up
case "$1" in
start)
/path/to/your/script &
echo "(script) is starting"
;;
stop)
kill -9 `ps -ef | grep (script) | grep -v grep| cut -d" " -f6`
echo "(script) is stopping"
;;
*)
exit 1
echo "Usage : /sbin/service (script) {start|stop}"
esac
exit 0
(script) ဆိုတဲ့ ေနရာေလးေတြ မွာ ကိုယ့္ script နဲ႕ အစားထိုးပါလို႕ဆိုျပီး ေပးလိုက္တယ္ ။ အဆင္ေျပသြားတယ္တဲ့ ။ Init script က ဒီ syntax နဲ႕ပဲ အလုပ္လုပ္ပါတယ္ ။ ကိုယ့္ဟာကိုယ္ တျခား script တစ္ခုခုကို စခ်င္လည္း ဒီ template ကိုသုံးလို႕ရပါတယ္ ။ အေရးၾကီးတာ No.4 လိုင္းပါ ။ အဲမွာ chkconfig 235 35 55 လို႕ေပးထားပါတယ္ ။
အေရွ႕ဆုံးက 235 ဆိုတာက ဒီ script ကို run မဲ့ runlevel ေတြပါ ။ Runlevel ဆိုတာ ဘာလည္းမေသခ်ာရင္ ရွာဖတ္ၾကည့္ေစခ်င္ပါတယ္။ ပံုမွန္အားျဖင့္ 0 to 6 ရွိပါတယ္ ။
0 = shutdown ၊
6 = reboot ၊
1 = single user mode
2 = multi-user mode without networking
3 = multi-user mode with networking
4 = User-definable
5 = multi-user mode with networking + GUI
ဒီ init script မွာဆို လိုခ်င္တဲ့ service / script ကို runlevel 2 , 3 နဲ႕ 5 မွာပဲ စမယ္လို႕ ေျပာထားပါတယ္ ။
အေနာက္က 35 နဲ႕ 55 က script ကို boot up time မွာစမဲ့ priority နဲ႕ shutdown time မွာ kill မဲ့ priority ပါ။ /etc/rcx.d/ ထဲမွာ script ေတြကို S55httpd ၊ K55httpd ဆိုျပီး အေရွ႕မွာ Sxx ၊ Kxx ေတြနဲ႕ ရွိေလ့ရွိပါတယ္။ ဒါကဘာကို ေဖာ္ျပတာလည္းဆိုရင္ ၊ ဆိုၾကပါစို႕ rc3.d ထဲမွာ S10sshd နဲ႕ S55httpd ဆိုျပီးရွိတယ္ ။ ဒါဆို တကယ္လို႕ server က runlevel 3 ကို run တယ္ဆိုရင္ Inittab က rc3.d ထဲက start script ေတြကို အစီအစဥ္အလိုက္ စပါတယ္ ။ ဒီမွာဆို S10 ျဖစ္တဲ့ sshd က အရင္စပါလိမ့္မယ္ ၊ ေနာက္မွ S55 ျဖစ္တဲ့ httpd က စပါလိမ့္မယ္။ အဲေတာ့ ကိုယ့္ script ကို ေစာေစာစီးစီး စေစခ်င္ရင္ အဲမွာ 35 ေနရာမွာ နံပါတ္ေသးေသး ေပးရပါလိမ့္မယ္ ။ rcx.d ကို ဖြင့္ၾကည့္ရင္ ကိုယ့္ script က ဘယ္အခ်ိန္ေလာက္မွာ စရင္ အဆင္ေျပမလည္း စဥ္းစားလို႕ရမွာပါ။ အေနာက္က 55 က လည္း ထိုနည္းတူပါပဲ ။ Shutdown လုပ္တဲ့အခ်ိန္မွာ ေစာေစာ kill ေစခ်င္ရင္ နံပါတ္ေသးေသးေပးပါ။ ေနာက္ဆုံးမွ kill ေစခ်င္ရင္ 99 လို႕ေပးလိုက္ပါ။
ဒီ init script က သူ run ခ်င္တာကို root အေနနဲ႕ run ဖို႕ ေရးထားတာပါ ။ တကယ္လို႕ တျခား user အေနနဲ႕ run ခ်င္ရင္ လိုင္းနံပါတ္ 9 မွာ su ကိုသုံးရပါမယ္ ။ ဒါဆို ဒီလိုျဖစ္သြားမယ္
su username -c /path/to/your/script &
Stop လုပ္တဲ့ အပိုင္းကေတာ့ လြယ္လြယ္ကူကူ PID ကိုရွာျပီး kill လိုက္တာပဲ ေရးထားပါတယ္ ။
ျပီးရင္ေတာ့ ဒီ init script ေလးကို /etc/init.d/ ေအာက္ထဲမွာ သြားထားရပါမယ္။ testscript လို႕ filename ကိုေပးလိုက္တယ္ ဆိုပါေတာ့။ ျပီးရင္ ဒါကို executable ျဖစ္ေအာင္ ေပးရပါတယ္။ ဒီ command ကို႐ိုက္ပါ ။
# chmod +x /etc/init.d/testscript
ျပီးရင္ chkconfig မွာ register လုပ္ရပါတယ္ ။ /etc/init.d ေအာက္ထဲမွာရွိတိုင္း rcx.d မွာမရွိပါဘူး ။ အဲထဲကို သက္ဆိုင္ရာ S နံပါတ္ K နံပါတ္နဲ႕ ေရာက္ေအာင္က register ရပါတယ္ ။
# chkconfig --add testscript
အဲဒါျပီးရင္ ကိုယ့္ရဲ့ script က server bootup တိုင္းမွာ သူ့ဘာသာသူ start ေနပါလိမ့္မယ္
( Note : rcx.d ဆိုတာ nix နဲ႕ နဲနဲ ရင္းႏွီးရင္ သိပါတယ္။ /etc ေအာက္မွာ rc1.d ၊ rc2.d ဆိုျပီး rc5.d အထိရွိပါတယ္ ။ သက္ဆိုင္ရာ runlevel မွာ စတဲ့ service ေတြရဲ့ start script ၊ stop script ေတြက အဲဒီထဲမွာရွိပါတယ္ ။ )
Divinity
Thursday, June 2, 2011
Copy ကူးတာကိုလည္း တစ္ခါတေလ backup လုပ္တယ္လို႕ေခၚတယ္
တစ္ခ်ိဳ႕ေတြေပါ့၊ လိုခ်င္ေတာ့ ၾကီးၾကီးက်ယ္က်ယ္ ။ Daily full backup ၊ one month cycle တဲ့။ Backup software ေတာ့မဝယ္ခ်င္ဘူး ၊ ဘယ္လိုပဲရရတဲ့ backup ျဖစ္ရင္ျပီးေရာတဲ့။ File ေတြမွားမွားဖ်က္ၾက overwrite ေတြ မွားမွားလုပ္ၾကလြန္းလို႕တဲ့။ ဒီလိုလား ၊ ရပါတယ္။ xcopy နဲ႕ပဲ လုပ္လို႕ရပါတယ္။ အဲဒါနဲ႕ပဲ ဒီေန႕ သုံးေၾကာင္း bat script ေလးတစ္ခုေရးျဖစ္တယ္။ အမွန္က ဘယ္မွာေတြ့ဖူးမွန္းမသိတာတစ္ခုကို မွီညမ္းျပီး ဟိုးအရင္တစ္ခါက ေရးထားတာပါ။ နည္းနည္းေလးပဲျပင္လိုက္ရတယ္။
ဒုတိယ တစ္ေၾကာင္းက ပံုမွန္ဆိုမလိုပါဘူး။ ဒီ user ေတြက ဘာေတြလုပ္မွန္းမသိ မၾကာမၾကာ recycle bin corrupted error ျဖစ္တယ္။ ဘာလို႕ျဖစ္လည္း သူတို႕ဘာလုပ္လည္းဆိုတာ သူတို႕ကိုတိုင္လည္းမသိဘူး။ Recycle bin ကအေရးမၾကီးဘူး၊ ရတယ္တဲ့။ ဟုတ္တယ္ေလ မွားဖ်က္မိလို႕ ျပန္လိုခ်င္ရင္ backup ေတြရွိေနမွာပဲ။ အဲဒါနဲ႕ က်ေနာ့ script ထဲမွာ အဲ quickfix ေလးထဲ့ေရးလိုက္တာ။
ပထမလိုင္းကေတာ့ အလကား output ေတြေပၚေပၚလာရင္ မ်က္စိေနာက္လို႕ echo off လိုက္တာ ။ Bat ေရးဖူးတဲ့သူတိုင္း သိပါတယ္။
ဒုတစ္ယလိုင္းကေတာ့ recycle bin error ကို quickfix အေနနဲ႕ Empty recycle bin လုပ္လိုက္တာ။ အမွန္က Recycle.Bin directory ကို ဖ်က္လိုက္တာပါ။ ဒါေပမယ့္ တစ္ခုခု delete လုပ္ရင္ျဖစ္ျဖစ္၊ logout / login လုပ္ရင္ျဖစ္ျဖစ္ recycle.bin folder က ျပန္ create ျဖစ္ပါတယ္။ အဲေတာ့ ဒါ command line က empty recycle bin လုပ္လိုက္တာပဲလို႕ သေဘာထားပါတယ္။ :D
ေနာက္ဆုံးလိုင္းကေတာ့ Windows ရဲ့ အသုံးတည့္ command ေလးတစ္ခုျဖစ္တဲ့ xcopy နဲ႕ files ေတြကို ကူးဖို႕ပါ။ ဒီမွာ ျပသနာ နည္းနည္းရွိပါတယ္။ က်ေနာ္တို႕က one month cycle လိုခ်င္တာပါ။ ဆိုလိုတာက ေန႕စဥ္ overwrite မလုပ္ခ်င္ပါဘူး။ ေန႕စဥ္ new backup set ထားသြားျပီး တစ္လၾကာမွ ပထမေန႕က backup set ကို overwrite ခ်င္တာပါ။ အဲဒါေၾကာင့္ ေနာက္က destination မွာ %date~:4,2% ဆိုတာေလးပါေနတာပါ။ Windows မွာ %date% environmental variable က system date ကို ကိုယ္စားျပဳပါတယ္။ %date% ကမွ ေလးလုံးေျမာက္ကေန ငါးလုံးေျမာက္အထိ ( ႏွစ္လုံးထဲ) လိုခ်င္လို႕ %date~:4,2% လို႕ေရးတာပါ။ ကိုယ္ယူထားတယ့္ date / time format ေပၚမွာ မူတည္ပါလိမ့္မယ္။ mm-dd-yyyy ဆိုရင္ေတာ့ 7,2 လို႕ယူရပါလိမ့္မယ္။ အေနာက္က /Y ကေတာ့ overwrite ဖို႕ yes / no prompt ေတြမွာ အကုန္ yes လို႕သတ္မွတ္ျပီး overwrite သြားဖို႕၊ /Q ကေတာ့ process output မျပဖို႕နဲ႕ ၊ /S ကေတာ့ subdirectories ေတြပါ ကူးဖို႕ ထဲ့ထားတာပါ။
Diskspace ပိုးဆိုးပက္စက္တက္တာကလြဲရင္ သူတို႕လိုခ်င္သလိုျဖစ္ပါတယ္။ Diskspace ကေတာ့ အမွန္ဆို compress ေလးေလာက္လုပ္သင့္တာေပါ့ေနာ္။ ဒါေပမယ့္ user က ဒီတိုင္းက သူတို႕အတြက္ ပိုေကာင္းတယ္၊ ဘာမွမလုပ္ရပဲ backup file ေတြကို ျမင္ရတာ ပိုသေဘာက်တယ္ဆိုလို႕ ျဖစ္သလိုပဲ လုပ္ေပးလိုက္ပါတယ္။ အမွန္က backup လုပ္တာလို႕ ေျပာဖို႕ေတာင္ ခက္ပါတယ္၊ တစ္ျခားတစ္ေနရာရာကို copy ကူးထားလိုက္တာပါပဲ။ ကိုယ့္ဟာကို compression လုပ္ခ်င္ရင္ေတာ့ winrar command line tools ေလးနဲ႕ လုပ္လို႕ရပါတယ္။
Divinity
@Echo off
rd /s /q E:\$Recycle.bin
xcopy D:\Company\* E:\Serverbackp\Company\%date:~4,2%\* /Y /Q /S
ဒုတိယ တစ္ေၾကာင္းက ပံုမွန္ဆိုမလိုပါဘူး။ ဒီ user ေတြက ဘာေတြလုပ္မွန္းမသိ မၾကာမၾကာ recycle bin corrupted error ျဖစ္တယ္။ ဘာလို႕ျဖစ္လည္း သူတို႕ဘာလုပ္လည္းဆိုတာ သူတို႕ကိုတိုင္လည္းမသိဘူး။ Recycle bin ကအေရးမၾကီးဘူး၊ ရတယ္တဲ့။ ဟုတ္တယ္ေလ မွားဖ်က္မိလို႕ ျပန္လိုခ်င္ရင္ backup ေတြရွိေနမွာပဲ။ အဲဒါနဲ႕ က်ေနာ့ script ထဲမွာ အဲ quickfix ေလးထဲ့ေရးလိုက္တာ။
ပထမလိုင္းကေတာ့ အလကား output ေတြေပၚေပၚလာရင္ မ်က္စိေနာက္လို႕ echo off လိုက္တာ ။ Bat ေရးဖူးတဲ့သူတိုင္း သိပါတယ္။
ဒုတစ္ယလိုင္းကေတာ့ recycle bin error ကို quickfix အေနနဲ႕ Empty recycle bin လုပ္လိုက္တာ။ အမွန္က Recycle.Bin directory ကို ဖ်က္လိုက္တာပါ။ ဒါေပမယ့္ တစ္ခုခု delete လုပ္ရင္ျဖစ္ျဖစ္၊ logout / login လုပ္ရင္ျဖစ္ျဖစ္ recycle.bin folder က ျပန္ create ျဖစ္ပါတယ္။ အဲေတာ့ ဒါ command line က empty recycle bin လုပ္လိုက္တာပဲလို႕ သေဘာထားပါတယ္။ :D
ေနာက္ဆုံးလိုင္းကေတာ့ Windows ရဲ့ အသုံးတည့္ command ေလးတစ္ခုျဖစ္တဲ့ xcopy နဲ႕ files ေတြကို ကူးဖို႕ပါ။ ဒီမွာ ျပသနာ နည္းနည္းရွိပါတယ္။ က်ေနာ္တို႕က one month cycle လိုခ်င္တာပါ။ ဆိုလိုတာက ေန႕စဥ္ overwrite မလုပ္ခ်င္ပါဘူး။ ေန႕စဥ္ new backup set ထားသြားျပီး တစ္လၾကာမွ ပထမေန႕က backup set ကို overwrite ခ်င္တာပါ။ အဲဒါေၾကာင့္ ေနာက္က destination မွာ %date~:4,2% ဆိုတာေလးပါေနတာပါ။ Windows မွာ %date% environmental variable က system date ကို ကိုယ္စားျပဳပါတယ္။ %date% ကမွ ေလးလုံးေျမာက္ကေန ငါးလုံးေျမာက္အထိ ( ႏွစ္လုံးထဲ) လိုခ်င္လို႕ %date~:4,2% လို႕ေရးတာပါ။ ကိုယ္ယူထားတယ့္ date / time format ေပၚမွာ မူတည္ပါလိမ့္မယ္။ mm-dd-yyyy ဆိုရင္ေတာ့ 7,2 လို႕ယူရပါလိမ့္မယ္။ အေနာက္က /Y ကေတာ့ overwrite ဖို႕ yes / no prompt ေတြမွာ အကုန္ yes လို႕သတ္မွတ္ျပီး overwrite သြားဖို႕၊ /Q ကေတာ့ process output မျပဖို႕နဲ႕ ၊ /S ကေတာ့ subdirectories ေတြပါ ကူးဖို႕ ထဲ့ထားတာပါ။
Diskspace ပိုးဆိုးပက္စက္တက္တာကလြဲရင္ သူတို႕လိုခ်င္သလိုျဖစ္ပါတယ္။ Diskspace ကေတာ့ အမွန္ဆို compress ေလးေလာက္လုပ္သင့္တာေပါ့ေနာ္။ ဒါေပမယ့္ user က ဒီတိုင္းက သူတို႕အတြက္ ပိုေကာင္းတယ္၊ ဘာမွမလုပ္ရပဲ backup file ေတြကို ျမင္ရတာ ပိုသေဘာက်တယ္ဆိုလို႕ ျဖစ္သလိုပဲ လုပ္ေပးလိုက္ပါတယ္။ အမွန္က backup လုပ္တာလို႕ ေျပာဖို႕ေတာင္ ခက္ပါတယ္၊ တစ္ျခားတစ္ေနရာရာကို copy ကူးထားလိုက္တာပါပဲ။ ကိုယ့္ဟာကို compression လုပ္ခ်င္ရင္ေတာ့ winrar command line tools ေလးနဲ႕ လုပ္လို႕ရပါတယ္။
Divinity
Tuesday, May 31, 2011
MySQL root password reset
MySQL ကဘယ္ သေကာင့္သားက install သြားမွန္းမသိ၊ root password လည္း ဘယ္နားမွာမွ မွတ္မထား၊ documentation ကလည္းမရွိ ၊ ဟုတ္ေတာ့ေနျပီ ။ ဒီထဲက database ေတြကို ေရႊ႕ဖို႕ဟာ ဘယ္ mysql account password မွမသိဘူး။ ဘယ္လို export ထုတ္ရပါ့။ o_O
တျခား database ေတြလည္း သိပ္မရင္းႏွီးေတာ့ တျခား database ေတြမွာ ခက္လားမခက္လား ေတာ့ မသိဘူး။ MySQL မွာေတာ့ မခက္ပါဘူး။ MySQL server command ေတြထဲမွာ skip-grant-tables ဆိုတယ့္ option ရွိပါတယ္။ Privileges system ကို မသုံးပဲ ၊ database အားလုံးကို unrestricted access ျဖစ္သြားပါတယ္။ Database downtime ေလး မိနစ္ဝက္ေလာက္ေတာ့ ရွိမွာေပါ့။ ဘယ္တတ္ႏိုင္မလည္း ။
ပထမဆုံး MySQL ကို --skip-grant-tables option နဲ႕ ျပန္စပါ။
ေနာက္ဆုံးက Ampersand (&) ေလးကေတာ့ process ကို background process အျဖစ္ run လိုက္တာပါ ။ ဒီလို run လိုက္ရင္ MySQL က ဝင္ခ်င္တိုင္းဝင္ ထြက္ခ်င္တိုင္းထြက္လို႕ရျပီ ။
Root user အေနနဲ႕ MySQL ထဲကို ဝင္သြားပါလိမ့္မယ္။ အဲၾကမွ password ျမန္ျမန္ reset လုပ္ေပါ့။
Mysql database ထဲက user ဆိုတယ့္ table မွာ password ဆိုတယ့္ column ကို update လိုက္တာေပါ့။ ေနာက္က Password(' ') ဆိုတာၾကီးကေတာ့ MySQL ရဲ့ password hashing function ပါ။ Query မွာတုန္းက plain text ၾကီးနဲ႕ ႐ိုက္ေပမယ့္ database ထဲကို hash အေနနဲ႕ insert သြားလုပ္လိမ့္မယ္။ ဒီ query က တျခား mysql account password ေမ့ရင္လည္း အသုံးတဲ့ပါတယ္။
ျပီးရင္ flush privileges လုပ္လိုက္ရင္ privileges system ျပန္ျပီး active ျဖစ္ပါျပီ။ ဆိုလိုတာက ပံုမွန္အတိုင္ တျခား account restriction ေတြျပန္ရွိျပီေပါ့။ က်ေနာ္ကေတာ့ MySQL ကို restart ျပန္လုပ္ေလ့ရွိပါတယ္။ init script ကို ျပန္ေခၚျပီး restart ခ်လိုက္တာ ဘာေလာက္မွမၾကာပါဘူး။
ကဲ ဒါဆို MySQL root password reset ရသြားျပီ။ က်န္တာေတာ့ ကိုယ့္ဟာကို export ဆက္လုပ္ေတာ့ေပါ့။ :)
Divinity
တျခား database ေတြလည္း သိပ္မရင္းႏွီးေတာ့ တျခား database ေတြမွာ ခက္လားမခက္လား ေတာ့ မသိဘူး။ MySQL မွာေတာ့ မခက္ပါဘူး။ MySQL server command ေတြထဲမွာ skip-grant-tables ဆိုတယ့္ option ရွိပါတယ္။ Privileges system ကို မသုံးပဲ ၊ database အားလုံးကို unrestricted access ျဖစ္သြားပါတယ္။ Database downtime ေလး မိနစ္ဝက္ေလာက္ေတာ့ ရွိမွာေပါ့။ ဘယ္တတ္ႏိုင္မလည္း ။
ပထမဆုံး MySQL ကို --skip-grant-tables option နဲ႕ ျပန္စပါ။
> mysqld_safe --skip-grant-tables &
ေနာက္ဆုံးက Ampersand (&) ေလးကေတာ့ process ကို background process အျဖစ္ run လိုက္တာပါ ။ ဒီလို run လိုက္ရင္ MySQL က ဝင္ခ်င္တိုင္းဝင္ ထြက္ခ်င္တိုင္းထြက္လို႕ရျပီ ။
> mysql
Root user အေနနဲ႕ MySQL ထဲကို ဝင္သြားပါလိမ့္မယ္။ အဲၾကမွ password ျမန္ျမန္ reset လုပ္ေပါ့။
mysql> UPDATE mysql.user SET password=PASSWORD('New-password') WHERE User='root';
Mysql database ထဲက user ဆိုတယ့္ table မွာ password ဆိုတယ့္ column ကို update လိုက္တာေပါ့။ ေနာက္က Password(' ') ဆိုတာၾကီးကေတာ့ MySQL ရဲ့ password hashing function ပါ။ Query မွာတုန္းက plain text ၾကီးနဲ႕ ႐ိုက္ေပမယ့္ database ထဲကို hash အေနနဲ႕ insert သြားလုပ္လိမ့္မယ္။ ဒီ query က တျခား mysql account password ေမ့ရင္လည္း အသုံးတဲ့ပါတယ္။
ျပီးရင္ flush privileges လုပ္လိုက္ရင္ privileges system ျပန္ျပီး active ျဖစ္ပါျပီ။ ဆိုလိုတာက ပံုမွန္အတိုင္ တျခား account restriction ေတြျပန္ရွိျပီေပါ့။ က်ေနာ္ကေတာ့ MySQL ကို restart ျပန္လုပ္ေလ့ရွိပါတယ္။ init script ကို ျပန္ေခၚျပီး restart ခ်လိုက္တာ ဘာေလာက္မွမၾကာပါဘူး။
ကဲ ဒါဆို MySQL root password reset ရသြားျပီ။ က်န္တာေတာ့ ကိုယ့္ဟာကို export ဆက္လုပ္ေတာ့ေပါ့။ :)
Divinity
Friday, May 20, 2011
OpenSource ေတြသုံးၾကည့္ရေအာင္ (1) ( Openfiler - Opensource NAS)
ဒီေန႕ေခတ္က OpenSource ရဲ့ေခတ္လို႕ေျပာရင္ေတာင္ လြန္မယ္မထင္ဘူး။ Commercial products ေတာ္ေတာ္မ်ားမ်ားအတြက္ alternative အေနနဲ႕ Opensource product ေတြရွိေလ့ရွိပါတယ္။ Microsoft Office ေလာက္မေကာင္းဘူးလို႕ေျပာလို႕ရေပမယ့္ OpenOffice.org ဆိုလည္း သုံးလို႕ အဆင္ေျပပါတယ္။ Firewall မွာလည္း Fortinet တို႕ Checkpoint တို႕ကို မမွီေပမယ့္ home and small office users ေတြေလာက္အတြက္ လံုေလာက္တယ့္ capability ကိုေပးႏိုင္တယ့္ Opensource firewall ေတြအမ်ားၾကီးပါ ။ Licensed version လည္း ဝယ္သုံးရတာ သက္သာတာ က်ေနာ္တို႕ႏိုင္ငံမွာပဲရွိပါတယ္။တျခားႏိုင္ငံေတြက က်ေနာ္တို႕ေလာက္ License version မသုံးႏိုင္လို႕ Opensource ေတြကို အားကိုးရတယ္။ EMC ကိုဖို႕မျဖစ္ႏိုင္ေပမယ့္ budget cut down ျဖစ္ျပီး အသုံးတဲ့တယ့္ Opensource NAS တစ္ခုအေၾကာင္း သတင္းေပးခ်င္ပါတယ္။
Small office တစ္ခုအေနနဲ႕ centralized file storage တစ္ခုေတာ့ထားခ်င္တယ္၊ ဒါေပမယ့္ storage server license ဝယ္ရမွာလည္း ေစ်းၾကီးတယ္။ Office မွာကမွ လူက ဆယ္ေယာက္ေလာက္ရွိတာ၊ server license ေတာ့မဝယ္ခ်င္ဖူးဆိုရင္ Opensource nas ေတြအမ်ားၾကီးရွိပါတယ္။ အဲဒီထဲမွာေတာ့့ OpenNAS နဲ႕ Openfiler က stable ျဖစ္ျပီး လူသုံးမ်ားတယ္။ Small office မဟုတ္ေပမယ့္လည္း budget cut down လုပ္ခ်င္ရင္ stable ျဖစ္လို႕ သုံးလို႕ အဆင္ေျပႏိုင္ပါတယ္။ ဒီ post မွာ က်ေနာ္တို႕ Openfiler ရဲ့ capability ကို ၾကည့္ၾကည့္ရေအာင္ ။
Overview
Linux based ပါပဲ။ OpenLDAP ၊ NFS ၊ NIFS ၊ SAMBA ၊ iSCSI initiator အစရွိသျဖင့္ NAS တစ္ခုအတြက္ လိုအပ္တာေတြျပန္ ေပါင္းထဲ့ထားတယ့္ Linux based တစ္ခုပါပဲ။ Software RAID ၊ Hardware RAID ႏွစ္ခုလုံးကို support လုပ္ပါတယ္။ WebUI ပါလို႕ administration လြယ္ကူပါတယ္။ ဒါေပမယ့္ UI ကေနမရတယ့္ configuration အတြက္လည္း ကိုယ့္ဟာကိုယ္ console terminal ကေန ျပင္လို႕ troubleshoot လုပ္လို႕ရတာမို႕ သုံးရတာ flexible ျဖစ္ပါတယ္။ WebUI မွာတင္ Java servlet တစ္ခုနဲ႕ console access ထဲ့ေပးထားပါတယ္။ ( init 1 ႐ိုက္ဖို႕လိုရင္ေတာ့ သုံးလို႕မရႏိုင္ေပမယ့္ ေတာ္ရုံေတာ့ အသုံးတဲ့ပါတယ္)
Storage Flexibility
Openfiler မွာ iSCSI configure လုပ္လို႕ရလို႕ iSCSI capable external enclosure တစ္ခုခုနဲ႕ ခ်ိတ္ဆက္သုံးလို႕ရပါတယ္။ Storage တိုးခ်င္ရင္ enclosure ထဲမွာ hard disk ေတြထပ္တိုးျပီး Openfiler က Volume Group expend လုပ္လိုက္ရင္ရျပီ ။ အဲေတာ့ အျမဲတိုးတက္လာတယ့္ storage space လိုအပ္ခ်က္ကို အမွီလိုက္ႏိုင္ပါတယ္။ လက္ရွိ version မွာ 60 TB အထိ support လုပ္ပါတယ္။ Online volume resizing လုပ္လို႕ရတာမို႕ space expend လုပ္ခ်င္ရင္ေတာင္ downtime မရွိ လုပ္ႏိုင္ပါတယ္။
User Account Control
OpenLDAP ပါတာမို႕ local ldap server configure လုပ္ျပီး user acct control လုပ္လို႕ရပါတယ္။ တကယ္လို႕ network ထဲမွာ authentication server ရွိျပီးသားဆိုလည္း ရွိေနျပီးသား LDAP server သို႕မဟုတ္ AD ကိုခ်ိတ္ဆက္အသုံးျပဳႏိုင္ပါတယ္။ ဘယ္ user / group က ဘယ္ share ကို အသုံးျပဳႏိုင္သလည္းဆိုတာကိုလည္း configure လုပ္ရတာ လြယ္ကူပါတယ္။
Quota control
User ေတြကို quota သတ္မွတ္လို႕ရသလို ၊ share တစ္ခုခ်င္းကိုလည္း ဘယ္ share က ဘယ္ေလာက္ space ထိပဲ grow လုပ္ခြင့္ျပဳမယ္ဆိုျပီး သတ္မွတ္လို႕ရပါတယ္။ Company အတြင္းက ဘယ္ department က ဘယ္ေလာက္ space ပဲသုံးလို႕ရမယ္ဆိုျပီး သက္မွတ္တာမ်ိဳးအတြက္ အဆင္ေျပပါတယ္။
Rich Communication methods
SSH ၊ SMB ၊ CIFS ၊ NFS ၊ FTP အကုန္ support လုပ္လို႕ Unix ၊ Linux ၊ Mac ၊ Windows မေရြး ခ်ိတ္ဆက္အသုံးျပဳႏိုင္ပါတယ္။
High Availability
Openfiler မွာ HA cluster setup လုပ္လို႕ရပါတယ္။ တစ္လုံးထက္ပိုတယ့္ Openfiler server ေတြကေတာ့ Cluster တစ္ခုအေနနဲ႕ serve လုပ္ႏိုင္တာမို႕ single point of failure ကိုေရွာင္ႏိုင္ပါတယ္။ (ဒါကလည္း iSCSI လိုမ်ိဳးနဲ႕ တြဲမွ အဆင္ေျပမွာပါ။ )
Snapshot
Openfiler ရဲ့ volume တစ္ခုခ်င္းကို snapshot ႐ိုက္ျပီးတစ္ေနရာရာ ျပန္သြားထားလို႕ရပါေသးတယ္။ Storage server ကို backup ျပန္လုပ္တာေပါ့။ Revert ျပန္လုပ္ရတာလည္း လြယ္လြယ္ကူကူပဲ။
Easy Administration
ခုနကေျပာသလို ႐ိုးရွင္းျပီး ျပည့္စံုတယ့္ WebUI ေၾကာင့္ administrate လုပ္ရတာ လြယ္ကူလြန္းပါတယ္။ Volume group ေတြ၊ User / group quota ေတြနဲ႕ မစိမ္းဖူးဆိုရင္ ဘာမွ အထူးအစမ္းမရွိႏိုင္ပါဘူး။
Openfiler ရဲ့ ေကာင္းတယ့္အခ်က္ေတြအမ်ားၾကီးရွိပါေသးတယ္။ အလကားရတာမို႕ Cost effective ျဖစ္တယ္လို႕ေျပာရင္ လြန္မယ္မထင္ပါဘူး။ Exchange server ၊ VMware စတာတို႕နဲ႕တြဲျပီး storage အျဖစ္သုံးလို႕လည္းရပါတယ္။ Opensource တို႕ရဲ့ထုံးစံအတိုင္း documentation ကေတာ့ သိပ္အားမေကာင္းပါဘူး။ ဒါေပမယ့္ feature ေတာ္ေတာ္မ်ားမ်ားက ဘာ technical skills မွမလိုပဲ လြယ္လြယ္ကူကူပဲ သုံးလို႕ရပါတယ္။
က်ေနာ့္ ပတ္ဝန္းက်င္မွာ က်ေနာ္ေန႕စဥ္အမွ် ထိေတြ႕ေနရတယ့္ Opensource product ေတြအေၾကာင္း တစ္ခုခ်င္း ေရးပါအုန္းမယ္ ။ ( ေျပာျပန္ျပီ)
Divinity
Small office တစ္ခုအေနနဲ႕ centralized file storage တစ္ခုေတာ့ထားခ်င္တယ္၊ ဒါေပမယ့္ storage server license ဝယ္ရမွာလည္း ေစ်းၾကီးတယ္။ Office မွာကမွ လူက ဆယ္ေယာက္ေလာက္ရွိတာ၊ server license ေတာ့မဝယ္ခ်င္ဖူးဆိုရင္ Opensource nas ေတြအမ်ားၾကီးရွိပါတယ္။ အဲဒီထဲမွာေတာ့့ OpenNAS နဲ႕ Openfiler က stable ျဖစ္ျပီး လူသုံးမ်ားတယ္။ Small office မဟုတ္ေပမယ့္လည္း budget cut down လုပ္ခ်င္ရင္ stable ျဖစ္လို႕ သုံးလို႕ အဆင္ေျပႏိုင္ပါတယ္။ ဒီ post မွာ က်ေနာ္တို႕ Openfiler ရဲ့ capability ကို ၾကည့္ၾကည့္ရေအာင္ ။
Overview
Linux based ပါပဲ။ OpenLDAP ၊ NFS ၊ NIFS ၊ SAMBA ၊ iSCSI initiator အစရွိသျဖင့္ NAS တစ္ခုအတြက္ လိုအပ္တာေတြျပန္ ေပါင္းထဲ့ထားတယ့္ Linux based တစ္ခုပါပဲ။ Software RAID ၊ Hardware RAID ႏွစ္ခုလုံးကို support လုပ္ပါတယ္။ WebUI ပါလို႕ administration လြယ္ကူပါတယ္။ ဒါေပမယ့္ UI ကေနမရတယ့္ configuration အတြက္လည္း ကိုယ့္ဟာကိုယ္ console terminal ကေန ျပင္လို႕ troubleshoot လုပ္လို႕ရတာမို႕ သုံးရတာ flexible ျဖစ္ပါတယ္။ WebUI မွာတင္ Java servlet တစ္ခုနဲ႕ console access ထဲ့ေပးထားပါတယ္။ ( init 1 ႐ိုက္ဖို႕လိုရင္ေတာ့ သုံးလို႕မရႏိုင္ေပမယ့္ ေတာ္ရုံေတာ့ အသုံးတဲ့ပါတယ္)
Storage Flexibility
Openfiler မွာ iSCSI configure လုပ္လို႕ရလို႕ iSCSI capable external enclosure တစ္ခုခုနဲ႕ ခ်ိတ္ဆက္သုံးလို႕ရပါတယ္။ Storage တိုးခ်င္ရင္ enclosure ထဲမွာ hard disk ေတြထပ္တိုးျပီး Openfiler က Volume Group expend လုပ္လိုက္ရင္ရျပီ ။ အဲေတာ့ အျမဲတိုးတက္လာတယ့္ storage space လိုအပ္ခ်က္ကို အမွီလိုက္ႏိုင္ပါတယ္။ လက္ရွိ version မွာ 60 TB အထိ support လုပ္ပါတယ္။ Online volume resizing လုပ္လို႕ရတာမို႕ space expend လုပ္ခ်င္ရင္ေတာင္ downtime မရွိ လုပ္ႏိုင္ပါတယ္။
User Account Control
OpenLDAP ပါတာမို႕ local ldap server configure လုပ္ျပီး user acct control လုပ္လို႕ရပါတယ္။ တကယ္လို႕ network ထဲမွာ authentication server ရွိျပီးသားဆိုလည္း ရွိေနျပီးသား LDAP server သို႕မဟုတ္ AD ကိုခ်ိတ္ဆက္အသုံးျပဳႏိုင္ပါတယ္။ ဘယ္ user / group က ဘယ္ share ကို အသုံးျပဳႏိုင္သလည္းဆိုတာကိုလည္း configure လုပ္ရတာ လြယ္ကူပါတယ္။
Quota control
User ေတြကို quota သတ္မွတ္လို႕ရသလို ၊ share တစ္ခုခ်င္းကိုလည္း ဘယ္ share က ဘယ္ေလာက္ space ထိပဲ grow လုပ္ခြင့္ျပဳမယ္ဆိုျပီး သတ္မွတ္လို႕ရပါတယ္။ Company အတြင္းက ဘယ္ department က ဘယ္ေလာက္ space ပဲသုံးလို႕ရမယ္ဆိုျပီး သက္မွတ္တာမ်ိဳးအတြက္ အဆင္ေျပပါတယ္။
Rich Communication methods
SSH ၊ SMB ၊ CIFS ၊ NFS ၊ FTP အကုန္ support လုပ္လို႕ Unix ၊ Linux ၊ Mac ၊ Windows မေရြး ခ်ိတ္ဆက္အသုံးျပဳႏိုင္ပါတယ္။
High Availability
Openfiler မွာ HA cluster setup လုပ္လို႕ရပါတယ္။ တစ္လုံးထက္ပိုတယ့္ Openfiler server ေတြကေတာ့ Cluster တစ္ခုအေနနဲ႕ serve လုပ္ႏိုင္တာမို႕ single point of failure ကိုေရွာင္ႏိုင္ပါတယ္။ (ဒါကလည္း iSCSI လိုမ်ိဳးနဲ႕ တြဲမွ အဆင္ေျပမွာပါ။ )
Snapshot
Openfiler ရဲ့ volume တစ္ခုခ်င္းကို snapshot ႐ိုက္ျပီးတစ္ေနရာရာ ျပန္သြားထားလို႕ရပါေသးတယ္။ Storage server ကို backup ျပန္လုပ္တာေပါ့။ Revert ျပန္လုပ္ရတာလည္း လြယ္လြယ္ကူကူပဲ။
Easy Administration
ခုနကေျပာသလို ႐ိုးရွင္းျပီး ျပည့္စံုတယ့္ WebUI ေၾကာင့္ administrate လုပ္ရတာ လြယ္ကူလြန္းပါတယ္။ Volume group ေတြ၊ User / group quota ေတြနဲ႕ မစိမ္းဖူးဆိုရင္ ဘာမွ အထူးအစမ္းမရွိႏိုင္ပါဘူး။
Openfiler ရဲ့ ေကာင္းတယ့္အခ်က္ေတြအမ်ားၾကီးရွိပါေသးတယ္။ အလကားရတာမို႕ Cost effective ျဖစ္တယ္လို႕ေျပာရင္ လြန္မယ္မထင္ပါဘူး။ Exchange server ၊ VMware စတာတို႕နဲ႕တြဲျပီး storage အျဖစ္သုံးလို႕လည္းရပါတယ္။ Opensource တို႕ရဲ့ထုံးစံအတိုင္း documentation ကေတာ့ သိပ္အားမေကာင္းပါဘူး။ ဒါေပမယ့္ feature ေတာ္ေတာ္မ်ားမ်ားက ဘာ technical skills မွမလိုပဲ လြယ္လြယ္ကူကူပဲ သုံးလို႕ရပါတယ္။
က်ေနာ့္ ပတ္ဝန္းက်င္မွာ က်ေနာ္ေန႕စဥ္အမွ် ထိေတြ႕ေနရတယ့္ Opensource product ေတြအေၾကာင္း တစ္ခုခ်င္း ေရးပါအုန္းမယ္ ။ ( ေျပာျပန္ျပီ)
Divinity
Friday, May 6, 2011
Geez, what hardware spec i've got there ?
တစ္ခါတစ္ေလ Server ေတြရဲ့ Hardware spec ျပန္ၾကည့္ခ်င္တယ္၊ Serial Number ျပန္ၾကည့္ခ်င္တယ္၊ Server ကလည္း အနားမွာမရွိဘူး ၊ က်ေနာ္လို႕ documentation ေကာင္းရင္ ဘာ server သုံးခဲ့မိမွန္းေတာင္ မမွတ္မိေတာ့ဘူးဆိုရင္ command line ကေန ၾကည့္လို႕ရပါတယ္။ အမ်ားဆုံးျဖစ္တတ္တာက က်ေနာ္တို႕ဆို memory upgrade လုပ္ခ်င္တာ၊ memory type သိခ်င္ရုံနဲ႕လည္း Data center အထိမသြားခ်င္၊ သြားျဖစ္လည္း ဒါေလးအတြက္နဲ႕ BIOS ထဲဝင္မၾကည့္ခ်င္ရင္ အသုံးတဲ့ပါတယ္။
Linux မွာေတာ့ dmidecode command က ေတာ္ေတာ္အသုံးဝင္ပါတယ္။
Serial number ေလာက္ျပန္ၾကည့္ခ်င္တာဆို
လို႕႐ိုက္လိုက္ရင္ Chassis က serial number ကိုျပေပးပါတယ္။ Memory slot ေတြနဲ႕ ပတ္သက္တယ့္ information က type 16 ျဖစ္ေလ့ရွိပါတယ္။ Slot အေရအတြက္နဲ႕ Max capacity ျပပါလိမ့္မယ္။ အခုလက္ရွိတပ္ထားတယ့္ memory ကိုၾကည့္ခ်င္ရင္ေတာ့ Server အဖုံးဖြင့္ၾကည့္ရပါတယ္။ အခုလက္ရွိ တပ္ထားတယ့္ memory ရဲ့ information ေလာက္ပဲၾကည့္ခ်င္ရင္ေတာ့ 'dmidecode --type 17' ဆိုရင္ရပါတယ္။ DDR အမ်ိဳးအစားနဲ႕ speed ကိုျပပါလိမ့္မယ္။
Type နံပါတ္မေသခ်ာရင္လည္း dmidecode ရဲ့ output တစ္ခုလုံးကို output pipe နဲ႕ more ဒါမွမဟုတ္ less ဆိုျပီး ၾကည့္ရင္လည္းရပါတယ္။ Output ကရွင္းပါတယ္ ၊ လိုတယ့္ information ကိုရွာလို႕ လြယ္ပါတယ္။ ဒါဆို command က ဒါမ်ိဳးေပါ့။
Linux ရဲ့ dmidecode ကေတာ့ hardware info ကိုပဲ အဓိကျပပါတယ္။
Windows မွာဆိုရင္ေတာ့ wmic ဆိုတယ့္ command တစ္ခု ပါပါတယ္။ Windows Management Instrumentation ေပၚမွာ အေျခခံထားတယ့္ command ပါ။ wmic command output ကရွုပ္လို႕ တစ္ခါမွ လိုက္မၾကည့္ဖူးပါဘူး။ လိုတာပဲမွတ္ထားမိတယ္။ ဒါေပမယ့္ သူကေတာ့ ပိုျပီး information မ်ားမ်ား retrieve လုပ္ႏိုင္ပါတယ္။
Serial number ကေတာ့ BIOS မွာရွိပါတယ္ ။
ဆိုရင္ မ်က္စိေနာက္စရာ output နဲ႕ျပပါတယ္။ လိုခ်င္တာေလးျပန္ ျဖတ္ၾကည့္ရတယ္။
ဒါမွ လိုခ်င္တာေလးျပတယ္။
Memory speed ကေတာ့ memorychip ထဲမွာပါ။
ဒါမွမဟုတ္ပဲ တျခားဘာေတြရွိေသးလည္းၾကည့္ခ်င္ရင္ ေနာက္က get speed ျဖဳတ္႐ိုက္ေပါ့။ အဲ Memory capacity က်ေတာ့ memphysical ထဲမွာ ။
ဆိုရင္ maximum capacity ျပျပီး ၊
ဆိုရင္ slot ဘယ္နခုရွိလည္း ျပပါတယ္။
WMIC က hardware info retrieve လုပ္ဖို႕ေလာက္ လုပ္ထားတာမဟုတ္ပဲ current system ရဲ့ info ေတာ္ေတာ္မ်ားမ်ား process info ေတြ ၊ partition table ေတြပါၾကည့္လို႕ရပါတယ္။ WMIC အေၾကာင္းထပ္သိခ်င္ေသးရင္ ဒီ link မွာ ရွိပါေသးတယ္။ အေသးစိတ္ကေတာ့ Google ကရွာျပီး Microsoft technet article သာရွာဖတ္ၾကည့္ေပါ့။
Divinity
Linux မွာေတာ့ dmidecode command က ေတာ္ေတာ္အသုံးဝင္ပါတယ္။
Serial number ေလာက္ျပန္ၾကည့္ခ်င္တာဆို
# dmidecode --type 1
လို႕႐ိုက္လိုက္ရင္ Chassis က serial number ကိုျပေပးပါတယ္။ Memory slot ေတြနဲ႕ ပတ္သက္တယ့္ information က type 16 ျဖစ္ေလ့ရွိပါတယ္။ Slot အေရအတြက္နဲ႕ Max capacity ျပပါလိမ့္မယ္။ အခုလက္ရွိတပ္ထားတယ့္ memory ကိုၾကည့္ခ်င္ရင္ေတာ့ Server အဖုံးဖြင့္ၾကည့္ရပါတယ္။ အခုလက္ရွိ တပ္ထားတယ့္ memory ရဲ့ information ေလာက္ပဲၾကည့္ခ်င္ရင္ေတာ့ 'dmidecode --type 17' ဆိုရင္ရပါတယ္။ DDR အမ်ိဳးအစားနဲ႕ speed ကိုျပပါလိမ့္မယ္။
Type နံပါတ္မေသခ်ာရင္လည္း dmidecode ရဲ့ output တစ္ခုလုံးကို output pipe နဲ႕ more ဒါမွမဟုတ္ less ဆိုျပီး ၾကည့္ရင္လည္းရပါတယ္။ Output ကရွင္းပါတယ္ ၊ လိုတယ့္ information ကိုရွာလို႕ လြယ္ပါတယ္။ ဒါဆို command က ဒါမ်ိဳးေပါ့။
# dmidecode | less
Linux ရဲ့ dmidecode ကေတာ့ hardware info ကိုပဲ အဓိကျပပါတယ္။
Windows မွာဆိုရင္ေတာ့ wmic ဆိုတယ့္ command တစ္ခု ပါပါတယ္။ Windows Management Instrumentation ေပၚမွာ အေျခခံထားတယ့္ command ပါ။ wmic command output ကရွုပ္လို႕ တစ္ခါမွ လိုက္မၾကည့္ဖူးပါဘူး။ လိုတာပဲမွတ္ထားမိတယ္။ ဒါေပမယ့္ သူကေတာ့ ပိုျပီး information မ်ားမ်ား retrieve လုပ္ႏိုင္ပါတယ္။
Serial number ကေတာ့ BIOS မွာရွိပါတယ္ ။
> wmic bios
ဆိုရင္ မ်က္စိေနာက္စရာ output နဲ႕ျပပါတယ္။ လိုခ်င္တာေလးျပန္ ျဖတ္ၾကည့္ရတယ္။
> wmic bios get serialnumber
ဒါမွ လိုခ်င္တာေလးျပတယ္။
Memory speed ကေတာ့ memorychip ထဲမွာပါ။
> wmic memorychip get speed
ဒါမွမဟုတ္ပဲ တျခားဘာေတြရွိေသးလည္းၾကည့္ခ်င္ရင္ ေနာက္က get speed ျဖဳတ္႐ိုက္ေပါ့။ အဲ Memory capacity က်ေတာ့ memphysical ထဲမွာ ။
>wmic memphysical get maxcapacity
ဆိုရင္ maximum capacity ျပျပီး ၊
>wmic memphysical get memorydevices
ဆိုရင္ slot ဘယ္နခုရွိလည္း ျပပါတယ္။
WMIC က hardware info retrieve လုပ္ဖို႕ေလာက္ လုပ္ထားတာမဟုတ္ပဲ current system ရဲ့ info ေတာ္ေတာ္မ်ားမ်ား process info ေတြ ၊ partition table ေတြပါၾကည့္လို႕ရပါတယ္။ WMIC အေၾကာင္းထပ္သိခ်င္ေသးရင္ ဒီ link မွာ ရွိပါေသးတယ္။ အေသးစိတ္ကေတာ့ Google ကရွာျပီး Microsoft technet article သာရွာဖတ္ၾကည့္ေပါ့။
http://www.robvanderwoude.com/ntadmincommands.phpအသုံးတဲ့မယ္ထင္ပါတယ္။ မတဲ့လည္း သုံးၾကည့္ေပါ့ ။ :D
Divinity
Wednesday, April 27, 2011
Make your own shutdown command :D
စာေရးမယ္ ေျပာတုန္းကေျပာျပီး ေရးဖို႕ၾက ပ်င္းတယ္။ Game က လည္း ဆက္ကစားရအုန္းမယ္ ။ အခ်ိန္ေတြက ေလာက္ကို မေလာက္ဖူး ။ ေခါင္းစဥ္ဖတ္ျပီး ၾကီးၾကီးက်ယ္က်ယ္ေတာ့ မထင္ပါနဲ႕ ။ Linux ေပၚမွာ ေပါက္ကရ ေပါက္စေလးတစ္ခုေလာက္ လုပ္ၾကည့္ရေအာင္။
Bash မွာ command alias ေလးတစ္ခုေလာက္ ေရးၾကည့္ရေအာင္ ။ ကိုယ့္နာမည္႐ိုက္လိုက္ရင္ laptop က shutdown က်သြားတာမ်ိဳးေလးဆို မဆိုးဘူး။
$HOME ရဲ့ေအာက္မွာ .bash_profile သို႕မဟုတ္ .profile ဆိုတယ့္ file ရွိပါတယ္။ Bash shell မွာ .bash_profile လို႕ေတြ႕ရျပီး Sh မွာေတာ့ .profile လို႕ေတြ႕ရပါတယ္။ ( မိုးေလဝသ ေၾကညာတယ့္ ေလသံမ်ားေပါက္သြားလားမသိဘူး) Filename မွာ ေရွ႕မွာ full stop ပါပါတယ္။ ဒါ nix မွာ ေတာ့ hidden attribute ပါ။ ls နဲ႕ၾကည့္ရင္ ls -a ဆိုမွ ျမင္ရပါလိမ့္မယ္။ ကဲ အဲဒီ file ကို edit လုပ္ၾကမယ္။ vi ပဲျဖစ္ျဖစ္ vim ပဲျဖစ္ျဖစ္ nano ပဲျဖစ္ျဖစ္ ၾကိဳက္ရာနဲ႕ ဖြင့္၊ edit ျပီး save လို႕ရရင္ ျပီးတာပဲ။ ျပီးရင္ ဒီ ႏွစ္လိုင္းကို ေအာက္ဆုံးမွာ ျဖည့္လိုက္ပါ။
Generic ျဖစ္ေအာင္ ႏွစ္လိုင္းေရးလိုက္တာပါ။ Shutdown file ရွိတယ့္ path ကိုတန္းေပးျပီး $gant လို႕ မေပးေတာ့ရင္လည္း ရပါတယ္။ divinity ေနရာကေတာ့ ကိုယ့္နာမည္ ကိုေျပာင္းေပါ့။ Save လုပ္ျပီးရင္ စမ္းခ်င္ရင္ logout ျပီး ျပန္ login ဝင္ရပါတယ္။ Shell environment ကို edit တာမို႕ ခ်က္ခ်င္း effective မျဖစ္ပဲ next login မွာမွ effective ျဖစ္ပါတယ္။ ကဲ အခုဆိုရင္ေတာ့ ကိုယ့္နာမယ္ ကိုယ္႐ိုက္ျပီး shutdown ခ်လို႕ ရပါျပီ ။ ( စားၾကမယ္ေဟ့ ေကာင္းေကာင္း ေလသံေပါက္သြားလားမသိ )
Divinity
Bash မွာ command alias ေလးတစ္ခုေလာက္ ေရးၾကည့္ရေအာင္ ။ ကိုယ့္နာမည္႐ိုက္လိုက္ရင္ laptop က shutdown က်သြားတာမ်ိဳးေလးဆို မဆိုးဘူး။
$HOME ရဲ့ေအာက္မွာ .bash_profile သို႕မဟုတ္ .profile ဆိုတယ့္ file ရွိပါတယ္။ Bash shell မွာ .bash_profile လို႕ေတြ႕ရျပီး Sh မွာေတာ့ .profile လို႕ေတြ႕ရပါတယ္။ ( မိုးေလဝသ ေၾကညာတယ့္ ေလသံမ်ားေပါက္သြားလားမသိဘူး) Filename မွာ ေရွ႕မွာ full stop ပါပါတယ္။ ဒါ nix မွာ ေတာ့ hidden attribute ပါ။ ls နဲ႕ၾကည့္ရင္ ls -a ဆိုမွ ျမင္ရပါလိမ့္မယ္။ ကဲ အဲဒီ file ကို edit လုပ္ၾကမယ္။ vi ပဲျဖစ္ျဖစ္ vim ပဲျဖစ္ျဖစ္ nano ပဲျဖစ္ျဖစ္ ၾကိဳက္ရာနဲ႕ ဖြင့္၊ edit ျပီး save လို႕ရရင္ ျပီးတာပဲ။ ျပီးရင္ ဒီ ႏွစ္လိုင္းကို ေအာက္ဆုံးမွာ ျဖည့္လိုက္ပါ။
gant=`which shutdown`
alias divinity='$gant -h now'
Generic ျဖစ္ေအာင္ ႏွစ္လိုင္းေရးလိုက္တာပါ။ Shutdown file ရွိတယ့္ path ကိုတန္းေပးျပီး $gant လို႕ မေပးေတာ့ရင္လည္း ရပါတယ္။ divinity ေနရာကေတာ့ ကိုယ့္နာမည္ ကိုေျပာင္းေပါ့။ Save လုပ္ျပီးရင္ စမ္းခ်င္ရင္ logout ျပီး ျပန္ login ဝင္ရပါတယ္။ Shell environment ကို edit တာမို႕ ခ်က္ခ်င္း effective မျဖစ္ပဲ next login မွာမွ effective ျဖစ္ပါတယ္။ ကဲ အခုဆိုရင္ေတာ့ ကိုယ့္နာမယ္ ကိုယ္႐ိုက္ျပီး shutdown ခ်လို႕ ရပါျပီ ။ ( စားၾကမယ္ေဟ့ ေကာင္းေကာင္း ေလသံေပါက္သြားလားမသိ )
Divinity
Religion : Googlism
Google သာမရွိရင္ က်ေနာ္တို႕ engineer ျဖစ္ပါ့မလား ? Google သာမရွိရင္ က်ေနာ္လည္း mechanical engineer ပဲလုပ္ျဖစ္မယ္ထင္တယ္။ အခုလို IT ျဖစ္လာမွာမဟုတ္ဖူး။ က်ေနာ္တို႕ အတြက္ Google က ဘဝပဲ ဟဲဟဲ။ ဒါလည္း ေျပာရရင္ေတာ့ မေကာင္းဘူး။ က်ေနာ္တို႕ မွတ္ဉာဏ္ထက္ Google docs ေတြ Google bookmarks ေတြ ကိုပိုအားကိုးလာရင္ မေကာင္းဘူးလို႕ထင္တာပဲ။ အတိုင္းအတာ တစ္ခုထိ သုံးရေပမယ့္ ဒီေပၚမွာပဲ depends မလုပ္မိသင့္ပါဘူး။ က်ေနာ္ဒီေန႕ MySQL cluster setup လုပ္ျဖစ္လို႕ က်ေနာ္ရဲ့ ပထမဆုံး setup လုပ္ျဖစ္တယ့္ အေတြ႕အၾကံုနဲ႕ ျပန္ယွဥ္စဥ္းစားမိပါတယ္။
က်ေနာ္တို႕ ဒီက Telecom တစ္ခုအတြက္ application တစ္ခု setup လုပ္တုန္းကပါ၊ က်ေနာ္က servers setup လုပ္ရပါတယ္။ Solaris 8 ေပၚမွာ။ သူတို႕ server ေတြထားတယ့္ server room ေတြမွာ က်ေနာ္တို႕အတြက္ internet access မရွိပါဘူး။ အဲ server ကိုတိုင္လည္း IP က approve မျဖစ္ေသးလို႕ link activate မျဖစ္ေသးပါဘူး။ အဲေတာ့ ေျပာရင္ ဘာ network connection မွမရွိပါဘူး။ Documentation ျပင္ဆင္သြားေပမယ့္ ရွန္းတတ္တယ့္က်ေနာ္ documentation မွာအဆင့္ေက်ာ္သြားပါတယ္။ ရွာစရာ internet လည္းမရွိဘူး။ အဲတုန္းက iphone မေပၚေသးဘူး။ :D Windows mobile မေကာင္းေၾကာင္းကေတာ့ က်ေနာ္မေျပာေတာ့ဘူး။ က်ေနာ္တို႕မွာ internet ကေန ရွာဖို႕ phone မွာရွာ လိုက္ဖတ္ ၊ ေနာက္မွ က်ေနာ္ အဆင့္ေက်ာ္သြားတာမွန္းသိတယ္။ အဲတုန္းကဘာပဲလိုလို Google မွာရွာ ေတြ႕တယ့္ အတိုင္းလုပ္လိုက္တာပဲ။ ရရင္ရ ၊ မရရင္ ဆက္ရွာ။ ဒါပဲလုပ္တတ္တယ္။ အဲဒါကိုပဲ လုပ္တတ္ေနျပီလို႕ ကိုယ့္ဟာကို ထင္တာ။ Internet မရွိတယ့္ ေနရာမွာ အလုပ္လုပ္ဖူးျပီးမွ ငါေတာ္ေတာ္လိုေသးတယ္လို႕ သိတာ။ ဒါေတာင္ compilation မလုပ္ရလို႕။
Internet က ေလ့လာၾကတာ အလြန္ေကာင္းေပမယ့္ internet ရွိမွ ျဖစ္ရင္ေတာ့ မေကာင္းဘူး။ Howto ေတြရွာၾကရင္လည္း ဘာေၾကာင့္ ဒီ howto မွာ ဒီလို လုပ္သလည္းဆိုတာကို ေလ့လာဖို႕ သိပ္မလုပ္ၾကဖူး။ Ubuntu howto ကို Fedora ေပၚမွာ ျပန္အသုံးမခ်ႏိုင္တယ့္ linux ဆရာေတြ ေတြ႕ဖူးပါတယ္။ ဒီ command ကရွိမွ မရွိတာ ဆိုျပီး fedora version howto ရေအာင္ လိုက္ရွာတာမ်ိဳး။ ေနာက္ေတာ့ က်ေနာ္ README file ေတြ ဖတ္ျဖစ္လာတယ္။ ဘာပဲ compile လုပ္လုပ္ README အရင္ဖတ္တယ္။ ျပီးမွ internet မွာရွာတယ္။ ဒါလည္း reference အေနနဲ႕ပါ။ Linux မွာ source file ေတြမွာပါတယ့္ text file ေတြမွာ compilation / installation အတြက္ ရွင္းျပထားတာမ်ိဳး ပါေလ့ရွိပါတယ္။ က်ေနာ္လည္း ေနာက္မွေတြ႕တယ္။ MySQL source file ထဲမွာ INSTALL-BINARY ဆိုတယ့္ file တစ္ခုမွာ အဆင့္လိုက္ရွင္းျပထားပါတယ္။ အဲတုန္းကေတာ့ 20C temperature အခန္းထဲ ေခြၽးေတြပ်ံလို႕။
အျမဲတန္း အလုပ္ျဖစ္သြားရုံထက္ explore လုပ္ၾကည့္ပါ အမွားမရွိပါဘူး။ ဒီလို စကားမ်ိဳး Zero ေရးတယ့္ post ေတြမွာ ပါေလ့ရွိပါတယ္။ တစ္ခုကို ေကာင္းေကာင္းနားလည္ထားရင္ မသိေသးတာတစ္ခုကို ရွာေဖြဖတ္ရင္လည္း နားလည္လြယ္ပါတယ္။ Google က က်ေနာ္တို႕ရဲ့ ကိုးကြယ္ရာ မဟုတ္ပဲ ခိုင္းစားရုံေလာက္ပဲ ခိုင္းစားၾကရေအာင္။
Divinity
က်ေနာ္တို႕ ဒီက Telecom တစ္ခုအတြက္ application တစ္ခု setup လုပ္တုန္းကပါ၊ က်ေနာ္က servers setup လုပ္ရပါတယ္။ Solaris 8 ေပၚမွာ။ သူတို႕ server ေတြထားတယ့္ server room ေတြမွာ က်ေနာ္တို႕အတြက္ internet access မရွိပါဘူး။ အဲ server ကိုတိုင္လည္း IP က approve မျဖစ္ေသးလို႕ link activate မျဖစ္ေသးပါဘူး။ အဲေတာ့ ေျပာရင္ ဘာ network connection မွမရွိပါဘူး။ Documentation ျပင္ဆင္သြားေပမယ့္ ရွန္းတတ္တယ့္က်ေနာ္ documentation မွာအဆင့္ေက်ာ္သြားပါတယ္။ ရွာစရာ internet လည္းမရွိဘူး။ အဲတုန္းက iphone မေပၚေသးဘူး။ :D Windows mobile မေကာင္းေၾကာင္းကေတာ့ က်ေနာ္မေျပာေတာ့ဘူး။ က်ေနာ္တို႕မွာ internet ကေန ရွာဖို႕ phone မွာရွာ လိုက္ဖတ္ ၊ ေနာက္မွ က်ေနာ္ အဆင့္ေက်ာ္သြားတာမွန္းသိတယ္။ အဲတုန္းကဘာပဲလိုလို Google မွာရွာ ေတြ႕တယ့္ အတိုင္းလုပ္လိုက္တာပဲ။ ရရင္ရ ၊ မရရင္ ဆက္ရွာ။ ဒါပဲလုပ္တတ္တယ္။ အဲဒါကိုပဲ လုပ္တတ္ေနျပီလို႕ ကိုယ့္ဟာကို ထင္တာ။ Internet မရွိတယ့္ ေနရာမွာ အလုပ္လုပ္ဖူးျပီးမွ ငါေတာ္ေတာ္လိုေသးတယ္လို႕ သိတာ။ ဒါေတာင္ compilation မလုပ္ရလို႕။
Internet က ေလ့လာၾကတာ အလြန္ေကာင္းေပမယ့္ internet ရွိမွ ျဖစ္ရင္ေတာ့ မေကာင္းဘူး။ Howto ေတြရွာၾကရင္လည္း ဘာေၾကာင့္ ဒီ howto မွာ ဒီလို လုပ္သလည္းဆိုတာကို ေလ့လာဖို႕ သိပ္မလုပ္ၾကဖူး။ Ubuntu howto ကို Fedora ေပၚမွာ ျပန္အသုံးမခ်ႏိုင္တယ့္ linux ဆရာေတြ ေတြ႕ဖူးပါတယ္။ ဒီ command ကရွိမွ မရွိတာ ဆိုျပီး fedora version howto ရေအာင္ လိုက္ရွာတာမ်ိဳး။ ေနာက္ေတာ့ က်ေနာ္ README file ေတြ ဖတ္ျဖစ္လာတယ္။ ဘာပဲ compile လုပ္လုပ္ README အရင္ဖတ္တယ္။ ျပီးမွ internet မွာရွာတယ္။ ဒါလည္း reference အေနနဲ႕ပါ။ Linux မွာ source file ေတြမွာပါတယ့္ text file ေတြမွာ compilation / installation အတြက္ ရွင္းျပထားတာမ်ိဳး ပါေလ့ရွိပါတယ္။ က်ေနာ္လည္း ေနာက္မွေတြ႕တယ္။ MySQL source file ထဲမွာ INSTALL-BINARY ဆိုတယ့္ file တစ္ခုမွာ အဆင့္လိုက္ရွင္းျပထားပါတယ္။ အဲတုန္းကေတာ့ 20C temperature အခန္းထဲ ေခြၽးေတြပ်ံလို႕။
အျမဲတန္း အလုပ္ျဖစ္သြားရုံထက္ explore လုပ္ၾကည့္ပါ အမွားမရွိပါဘူး။ ဒီလို စကားမ်ိဳး Zero ေရးတယ့္ post ေတြမွာ ပါေလ့ရွိပါတယ္။ တစ္ခုကို ေကာင္းေကာင္းနားလည္ထားရင္ မသိေသးတာတစ္ခုကို ရွာေဖြဖတ္ရင္လည္း နားလည္လြယ္ပါတယ္။ Google က က်ေနာ္တို႕ရဲ့ ကိုးကြယ္ရာ မဟုတ္ပဲ ခိုင္းစားရုံေလာက္ပဲ ခိုင္းစားၾကရေအာင္။
Divinity
Note : က်ေနာ္ MySQL cluster setup လုပ္ရင္း စဥ္းစားမိတာ ေရးလိုက္တာပါ။ MySQL cluster setup ကေတာ့ ဆက္ပါအုန္းမယ္။ MySQL cluster အတြက္ လိုအပ္တယ့္ ndbd က CentOS repo ထဲမွာ မရွိပါဘူး။ Mysql-max က Redhat မွာ enterprise subscriber ေတြအတြက္ပဲရွိပါတယ္။ အျပင္ rpm ကို download မွာထက္ေတာ့ MySQL site က tgz ေလး download ျပီး ကိုယ့္ဟာကို setup လုပ္တာ က်ေနာ့္အတြက္ ပို အဆင္ေျပပါတယ္။ ဒီည game မေဆာ့ျဖစ္ရင္ mysql cluster ေရးပါအုန္းမယ္။ :D
Tuesday, April 19, 2011
VMware vCenter Converter
http://www.vmware.com/products/converter/
Go green ဖို႕ လက္ရွိသုံးေနတယ့္ server ေတြကို Virtualize လုပ္ခ်င္တယ္။ ခက္တာက Downtime မရွိခ်င္ဘူး ။
Server ေသးေသးေလးေတြ အမ်ားၾကီး run ရတာ မီတာကုန္တယ္၊ အားလုံးကို ေပါင္းျပစ္ခ်င္တာ။
ျဖစ္ပါတယ္။ က်ေနာ့္အတြက္ အသုံးအတဲ့ဆုံး ျဖစ္ေနတယ့္ tools တစ္ခုပါ။ အဓိက သုံးျဖစ္တယ့္ အေၾကာင္းရင္းက Power on machine တစ္ခု၊ actual server တစ္ခုကို ၊ downtime မလိုပဲ VMware server image အျဖစ္ ေျပာင္းေပးႏိုင္လို႕ပါ။ ေျပာင္းတယ့္အခါမွာလည္း လိုအပ္ရင္ disk space ကိုျခံု႕လို႕ရပါတယ္။ Spec ကိုျပန္ configure လုပ္လို႕ရပါတယ္။
အရင္က office မွာ project ေတြျပီးသြားရင္ Code ေတြ Data ေတြ backup လုပ္သလို တစ္ခ်ိဳ႕ project မွာက် သုံးခဲ့တယ့္ HDD ကိုသိမ္းထားပါတယ္။ လိုအပ္ရင္ demo ျပန္ျပဖို႕ပါ။ ျပန္ setup မလုပ္ရပဲ လိုအပ္ရင္ ခ်က္ျခင္း ျပန္ run ျပႏိုင္ေအာင္လို႕။ အဲေတာ့ က်ေနာ္မွာ အျမဲတမ္း Hard disk ေတြအပိုကုန္တယ္။ ေနာက္ေတာ့ အဲ HDD ေတြအကုန္ VM image ေျပာင္းျပစ္လိုက္တယ္။ Storage ေပၚကို အကုန္ပို႕ထားလိုက္တယ္။ ေနာက္ျပီး office ထဲမွာ ဘယ္တုန္းကတည္းက run ထားမွန္းမသိတယ့္ P3 server ေတြရွိပါတယ္။ အလကား power ကုန္ heat တက္ပါတယ္။ အဲေကာင္ေတြ အကုန္လုံးလည္း ESXi တစ္လုံး setup ျပီး အကုန္ေျပာင္းလိုက္တယ္။ Server ခန္းထဲက desktop အားလုံး လႊင့္ျပစ္ေရးၾကိဳးစားမႈမွာ ဒီ tool က ေတာ္ေတာ္ အေထာက္အကူျဖစ္ပါတယ္။ တစ္ခါတစ္ေလ UAT မွာ အားလုံးေကာင္းျပီး Production က်မွ ျဖစ္ေနတာဆိုတယ့္ ခက္ဆိုးဆိုး bug မ်ိဳးကို troubleshoot ဖို႕လည္း Production environment ကို downtime မရွိပဲ clone ပြါးလို႕ရပါတယ္။
က်ေနာ္လို႕ မၾကာမၾကာ server ေတြ format ခ် development အတြက္ ျပင္ဆင္ေပး၊ ျပီးရင္ ျပန္ format လုပ္ သံသရာလည္သူေတြအတြက္ VMware product ေတြက ေတာ္ေတာ္အဆင္ေျပပါတယ္။ အလကားလည္း ရပါတယ္။ ပ်င္းပ်င္းရွိရင္ အခု ဒီ blog ကိုဖတ္ေနတယ့္ computer / laptop ကို VM image အျဖစ္ ေျပာင္းၾကည့္ပါလား။ သူ႕ wizard ေလးအတိုင္း လိုတယ့္ username / password ေလးျဖည့္ျပီး next next သြားရုံပါပဲ။ လြယ္ပါတယ္။ :D
Divinity
Friday, April 15, 2011
CVS to Git migration
ဟိုတစ္ေလာက အလုပ္ထဲမွာ source code repository ကို CVS ကေန Git ကိုေျပာင္းမယ္ဆိုျပီး Git server setup လုပ္ထားတာၾကာပါျပီ ။ ထပ္ရတယ့္ project အသစ္ေတြသာ Git မွာသုံးျပီး အေဟာင္းေတြ CVS ကေန မေျပာင္းျဖစ္ေသးဘူး။ Project တာဝန္ခံက ဒီ project migrate ေပးပါလို႕ဆိုမွ က်ေနာ္က ေျပာင္းေပးရတာ။ သူတို႕လည္း ပ်င္းလို႕ထင္တယ္ ။ ဘယ္သူမွ လာမေျပာၾကဘူး။ ဒီေန႕ေတာ့ အရင္ Project အေဟာင္းေလးခု migrate လုပ္ျဖစ္တယ္။ လြယ္လြယ္ကူကူပါပဲ။ Git က CVS ကို ေကာင္းေကာင္းနားလည္းပါတယ္။ သူ႕ဟာသူ ဝင္ checkout လုပ္ျပီး fetch သြားတာပဲ။ က်ေနာ္တို႕ သိဖို႕လိုတာဆိုလို႕ CVS server IP ၊ CVS accessible account တစ္ခု၊ CVSROOT path နဲ႕ migrate လုပ္ခ်င္တယ့္ CVS နာမည္ပဲလိုပါတယ္။
1. ပထမဆုံး လိုအပ္တယ့္ tools ေတြအရင္စစ္ရမယ္။ cvsimport က git-core ထဲမွာ ပါေလ့ရွိပါတယ္။ ဒါေပမယ့္ distro ကျပန္ျပီး package ေတြခြဲထားတာမ်ိဳးဆိုရင္ မပါတတ္ပါဘူး။ Fedora မွာဆို git-core အျပင္ git-cvs ကိုသက္သက္ install ျပန္လုပ္ရပါတယ္။ ကို install ထားတယ့္ git-core ထဲမွာ cvsimport ပါမပါကို git help -a နဲ႕ ၾကည့္လို႕ရပါတယ္။ Support လုပ္တယ့္ git command ေတြထြက္လာပါလိမ့္မယ္။ မ်က္စိေနာက္ရင္ grep နဲ႕ filter လုပ္ၾကည့္ေပါ့။ git help -a | grep cvsimport လို႕ filter လုပ္ၾကည့္ပါ။
2. ေနာက္တစ္ခုက cvsps command line tools ရွိမရွိၾကည့္ပါ။ CVS patchset generate လုပ္တယ့္ tools ပါ။ Patchset ဆိုတာကေတာ့ change history ေတြ၊ revision information ေတြ၊ commit history ေတြကို CVS log ကေန patch set ေျပာင္းေပးပါတယ္။ ( ပက္စက္တယ္ေပါ့ဗ်ာ )။
3. CVS server ကို login လုပ္မယ့္ credential ကို အရင္ prepare လုပ္ထားရေအာင္ ။ ဒီအဆင့္က optional ပါ။ ဒါေပမယ့္ CVS ထဲက repo တစ္ခုမက ခဏခဏ migrate လုပ္ဖို႕လိုရင္ေတာ့ ဒီအဆင့္ေလးကို ေက်ာ္မသြားတာေကာင္းပါတယ္။ Command syntax ကေတာ့
CVSROOT=:cvs-login-method:cvs-user-name@cvs.server.name:/path/to/CVS/root cvs login
ဒီမွာ cvs-login-method ၊ username ၊ servername ၊ CVSROOT path ေတြကို အစားထိုးရပါမယ္။ ဥပမာ cvs-login-method က pserver၊ username က ngar ၊ Servername / IP က 1.2.3.4 ၊ CVSROOT path က /share/cvs ဆိုပါေတာ့၊ ဒါဆို ဒီလိုျဖစ္သြားပါမယ္ ။
CVSROOT=:pserver:ngar@1.2.3.4:/share/cvs cvs login
ဒါဆို password ႐ိုက္ဖို႕ prompt လုပ္လိမ့္မယ္။ Password ႐ိုက္လိုက္ရင္ password ကို hash လုပ္ျပီး ကိုယ့္ $HOME ေအာက္မွာ .cvspass ဆိုတယ့္ file နဲ႕ သြားသိမ္းပါလိမ့္မယ္။
4. ေနာက္ဆုံး အေနနဲ႕ ( အခုမွ စတာပါ တကယ္က ) CVS ကို Git အေနနဲ႕ import လုပ္ပါတယ္။ Command syntax ကေတာ့
git cvsimport -v -d :cvs-login-method:username@servername:/CVSROOT cvs-module-name -C output-directory-name.git
ခုနက အေပၚမွာ ေျပာခဲ့တယ့္ server ေပၚက zephyr ဆိုတယ့္ CVS module ကို import လုပ္ခ်င္တာဆိုရင္ command က ဒီလိုျဖစ္သြားပါမယ္။
git cvsimport -v -d :pserver:ngar@1.2.3.4:/share/cvs zephyr -C zephyr.git
ဒါဆို CVS ကေန checkout လုပ္ျပီး Git repo အျဖစ္နဲ႕ import လုပ္ပါလိမ့္မယ္။ ဇိုက္ဖာရ္ ေဒါ့ ဂစ္ ဆိုျပီး Git repo တစ္ခုရပါလိမ့္မယ္။
အမွန္က ဒါကို Server ကို master အေနနဲ႕ ျပန္ push လုပ္ေပးရပါတယ္။ က်ေနာ္လို ငပ်င္းကေတာ့ တစ္ခါ import လုပ္ တစ္ခါ push လုပ္၊ ႏွစ္ခါ အခ်ိန္ကုန္မခံပါဘူး။ Server ေပၚကေနပဲ import လုပ္ပါတယ္။ ျပီးရင္ repo directory (e.g: zephyr.git) ရဲ့ေအာက္မွာရွိတယ့္ .git ထဲက file ေတြ folder ေတြကို ကူးထုတ္လိုက္ပါတယ္။ .git ( dot git ) ရဲ့ေအာက္မွာ Description တို႕ ၊ head တို႕ ၊ hook တို႕၊ refs တို႕ နဲ႕အတူ branches ေတြရွိပါတယ္။ ဒါေတြ အျပင္ကို ကူးထုတ္လိုက္ရင္ တျခား git client တစ္ခုကေန clone/pull လို႕ရပါျပီ။
Divinity
1. ပထမဆုံး လိုအပ္တယ့္ tools ေတြအရင္စစ္ရမယ္။ cvsimport က git-core ထဲမွာ ပါေလ့ရွိပါတယ္။ ဒါေပမယ့္ distro ကျပန္ျပီး package ေတြခြဲထားတာမ်ိဳးဆိုရင္ မပါတတ္ပါဘူး။ Fedora မွာဆို git-core အျပင္ git-cvs ကိုသက္သက္ install ျပန္လုပ္ရပါတယ္။ ကို install ထားတယ့္ git-core ထဲမွာ cvsimport ပါမပါကို git help -a နဲ႕ ၾကည့္လို႕ရပါတယ္။ Support လုပ္တယ့္ git command ေတြထြက္လာပါလိမ့္မယ္။ မ်က္စိေနာက္ရင္ grep နဲ႕ filter လုပ္ၾကည့္ေပါ့။ git help -a | grep cvsimport လို႕ filter လုပ္ၾကည့္ပါ။
2. ေနာက္တစ္ခုက cvsps command line tools ရွိမရွိၾကည့္ပါ။ CVS patchset generate လုပ္တယ့္ tools ပါ။ Patchset ဆိုတာကေတာ့ change history ေတြ၊ revision information ေတြ၊ commit history ေတြကို CVS log ကေန patch set ေျပာင္းေပးပါတယ္။ ( ပက္စက္တယ္ေပါ့ဗ်ာ )။
3. CVS server ကို login လုပ္မယ့္ credential ကို အရင္ prepare လုပ္ထားရေအာင္ ။ ဒီအဆင့္က optional ပါ။ ဒါေပမယ့္ CVS ထဲက repo တစ္ခုမက ခဏခဏ migrate လုပ္ဖို႕လိုရင္ေတာ့ ဒီအဆင့္ေလးကို ေက်ာ္မသြားတာေကာင္းပါတယ္။ Command syntax ကေတာ့
CVSROOT=:cvs-login-method:cvs-user-name@cvs.server.name:/path/to/CVS/root cvs login
ဒီမွာ cvs-login-method ၊ username ၊ servername ၊ CVSROOT path ေတြကို အစားထိုးရပါမယ္။ ဥပမာ cvs-login-method က pserver၊ username က ngar ၊ Servername / IP က 1.2.3.4 ၊ CVSROOT path က /share/cvs ဆိုပါေတာ့၊ ဒါဆို ဒီလိုျဖစ္သြားပါမယ္ ။
CVSROOT=:pserver:ngar@1.2.3.4:/share/cvs cvs login
ဒါဆို password ႐ိုက္ဖို႕ prompt လုပ္လိမ့္မယ္။ Password ႐ိုက္လိုက္ရင္ password ကို hash လုပ္ျပီး ကိုယ့္ $HOME ေအာက္မွာ .cvspass ဆိုတယ့္ file နဲ႕ သြားသိမ္းပါလိမ့္မယ္။
4. ေနာက္ဆုံး အေနနဲ႕ ( အခုမွ စတာပါ တကယ္က ) CVS ကို Git အေနနဲ႕ import လုပ္ပါတယ္။ Command syntax ကေတာ့
git cvsimport -v -d :cvs-login-method:username@servername:/CVSROOT cvs-module-name -C output-directory-name.git
ခုနက အေပၚမွာ ေျပာခဲ့တယ့္ server ေပၚက zephyr ဆိုတယ့္ CVS module ကို import လုပ္ခ်င္တာဆိုရင္ command က ဒီလိုျဖစ္သြားပါမယ္။
git cvsimport -v -d :pserver:ngar@1.2.3.4:/share/cvs zephyr -C zephyr.git
ဒါဆို CVS ကေန checkout လုပ္ျပီး Git repo အျဖစ္နဲ႕ import လုပ္ပါလိမ့္မယ္။ ဇိုက္ဖာရ္ ေဒါ့ ဂစ္ ဆိုျပီး Git repo တစ္ခုရပါလိမ့္မယ္။
အမွန္က ဒါကို Server ကို master အေနနဲ႕ ျပန္ push လုပ္ေပးရပါတယ္။ က်ေနာ္လို ငပ်င္းကေတာ့ တစ္ခါ import လုပ္ တစ္ခါ push လုပ္၊ ႏွစ္ခါ အခ်ိန္ကုန္မခံပါဘူး။ Server ေပၚကေနပဲ import လုပ္ပါတယ္။ ျပီးရင္ repo directory (e.g: zephyr.git) ရဲ့ေအာက္မွာရွိတယ့္ .git ထဲက file ေတြ folder ေတြကို ကူးထုတ္လိုက္ပါတယ္။ .git ( dot git ) ရဲ့ေအာက္မွာ Description တို႕ ၊ head တို႕ ၊ hook တို႕၊ refs တို႕ နဲ႕အတူ branches ေတြရွိပါတယ္။ ဒါေတြ အျပင္ကို ကူးထုတ္လိုက္ရင္ တျခား git client တစ္ခုကေန clone/pull လို႕ရပါျပီ။
Divinity
Nearly Related Post:
Thursday, January 20, 2011
TCP နဲ႕ UDP ဘာကြာ လည္း ?
TCP နဲ႕ UDP ဘာကြာ လည္း ? အလုပ္ထဲမွာ NLB အေၾကာင္းေျပာရင္းနဲ႕ ေျပာျဖစ္တယ္ ။ TCP က destination အတိအက်ကို လာျပီး ၊ UDP က broadcast ပုံစံသြားတယ္လို႕ ထင္ေနတယ့္ သူေတြ ေတြ႕လိုက္ရလို႕ပါ။ UDP မွာ Dest အမွန္က pick-up လုပ္၊ မဟုတ္တယ့္သူေတြ က drop တယ္လို႕ထင္ေနၾကတယ္။ Hub နဲ႕ Switch ကြာပံုနဲ႕ ေရာေနတယ္ထင္တယ္။ Tech engineer ေတြနဲ႕ေျပာတာမဟုတ္လို႕ (က်ေနာ္တို႕ PM နဲ႕ senior software eng တစ္ေယာက္ပါ)၊ non-technical ပံုစံပဲေျပာျဖစ္တယ္။
တစ္ခုက က်ေနာ္ severfault မွာဖတ္ဖူးတယ့္ CEO level explanation ။ ဆိုက်ပါေတာ့၊ CEO က စာရြက္သုံးရြက္ကို လုံးျပီး အမိႈက္ပုံးထဲကို ျပစ္ခ်င္တယ္။ စာရြက္သုံးရြက္က သူပို႕ခ်င္တယ့္ data ( packets) ပါ။ CEO ၾကီးက source ၊ အမိႈက္ပုံးက destination ေပါ့။ ဘယ္လိုျပစ္မလည္းဆိုတယ့္ manner က TCP / UDP ပါပဲ။ TCP လိုျပစ္ရင္ေတာ့ ပထမ တစ္ရြက္ျပစ္တယ္၊ ဝင္မဝင္ၾကည့္တယ္၊ ဝင္ရင္ ေနာက္တစ္ရြက္ထပ္ျပစ္တယ္။ ျပဳတ္က်သြားရင္ေတာ့ ( ထေကာက္ျပီးေတာ့) ေနာက္တစ္ခါထပ္ျပစ္တယ္။ အဓိကက စာရြက္သုံးရြက္လုံး အမိႈက္ပုံးထဲဝင္တာ ေသခ်ာဖို႕ စနစ္တက်ျပစ္တယ္ပဲ ဆိုပါေတာ့။ UDP ဆိုရင္ေတာ့ တစ္ ႏွစ္ သုံး ဆိုျပီး အမိႈက္ပုံးရွိမယ့္ဘက္ကို အကုန္ျပစ္လိုက္မယ္၊ ဝင္တာမဝင္တာ ဂ႐ုမစိုက္ဘူး ၊ မဝင္လည္းေနပါေစေပါ့။
CEO level က အရမ္း briefly ျဖစ္ေနတယ္။ ေနာက္ example တစ္ခုေျပာမယ္။ We should call it "Project manager level explanation" လို႕ေျပာေတာ့ PM က မ်က္ေထာင့္နီနဲ႕ၾကည့္တယ္။
က်ေနာ္တို႕ စာတစ္ေစာင္ ပို႕မယ္ဆိုပါေတာ့။ စာက Data ၊ က်ေနာ္က source ၊ က်ေနာ္ပို႕ခ်င္တယ့္ လိပ္စာက Destination ေပါ့။ ဘယ္လိုပို႕မလည္း ( transmission method ) ႏွစ္ခုေရြးစရာရွိမယ္ ။ DHL နဲ႕ ပံုမွန္ unregistered post mail ေပါ့။
DHL နဲ႕ပို႕တယ္ဆိုပါေတာ့ ၊
1. DHL က အိမ္ေရွ႕ကိုေရာက္ေအာင္လာမယ္ ( route)
2. အိမ္တခါးကို လာေခါက္မယ္ ( 3 way hand-shake)
3. ဒီ address မွာ ဒီစာကို လက္ခံႏိုင္ေၾကာင္း ေသခ်ာမွ
4. စာကိုေပးျပီးရင္လည္း လက္ခံရရွိေၾကာင္း လက္မွတ္ထိုးခိုင္းမယ္ ( Acknowledgement)
5. တကယ္လို႕ လက္ခံမယ့္ဘက္က လူမရွိရင္ပဲျဖစ္ျဖစ္ ၊ လက္ခံဖို႕အရမ္းအလုပ္ေတြရွုပ္ေနရင္ပဲျဖစ္ျဖစ္ ၊ ေနာက္တစ္ေခါက္ျပန္ပို႕မယ္ ( transmission control, windowing)
6. ဒီလိပ္စာက ဒီလူမရွိေတာ့တာမ်ိဳး၊ လိပ္စာမွားေနတာမ်ိဳးဆို sender ကိုျပန္ အေၾကာင္းၾကားမယ္။
Sender ဖက္က ပို႕လိုက္တာ ေရာက္မေရာက္ သိႏိုင္မယ္ ၊ လိုအပ္ရင္ ေနာက္တစ္ေခါက္ ၊ ေနာက္တစ္ေနရာ ပို႕ဖို႕လိုအပ္ရင္ လည္းသိရမွာေပါ့။
Unregisterd post mail ဆိုရင္ေတာ့
1. အိမ္ေအာက္က mailbox ကိုလာမယ္ ( route)
2. စာတိုက္ပုံးထဲ ထဲခဲ့မယ္
လက္ခံရမယ့္လူ အိမ္ေျပာင္းသြားလို႕ သူလက္ထဲမေရာက္လည္း တာဝန္မယူဖူး။ ေရာက္လားမေရာက္လားလည္း မသိႏိုင္ဘူး။
ဒီ example မွာ connection less နဲ႕ connection oriented ပံုစံကို ထဲ့မေျပာႏိုင္ေပမယ့္ ႏွစ္ခုလုံးက destination ကိုသိျပီး destination ကိုပဲေရာက္ေအာင္လာၾကတာပါပဲ။ Transmission control ပါတာနဲ႕ မပါတာပဲ အဓိကကြဲတယ္လို႕ ေျပာရင္ရပါတယ္။
Technical engineer ကိုဒါမ်ိဳးေျပာလို႕ မရႏိုင္ေပမယ့္ ၊ ဘာမွန္းမသိ စြတ္ေျပာတတ္တယ့္ သူေဌးေတြ ( PM ေတြေရာေပါ့) အတြက္ေတာ့ သူတို႕ညာဏ္နဲ႕ လိုက္မွီတယ့္ explanation ျဖစ္မယ္ထင္ပါတယ္ :D ။
စာမေရးတာၾကာျပီ ၊ ဘာမွ မလုပ္တာၾကာျပီ ။ တစ္ခုခုေသျခာျပန္လုပ္မယ္လို႕ စိတ္ကူးျပီး တျခား colleague တစ္ေရာက္စီကေန သူ download လုပ္ထားတယ့္ game အသစ္ေတြ 36 GB ဒီေန႕ copy လုပ္လိုက္ပါတယ္ ။
Divinity
တစ္ခုက က်ေနာ္ severfault မွာဖတ္ဖူးတယ့္ CEO level explanation ။ ဆိုက်ပါေတာ့၊ CEO က စာရြက္သုံးရြက္ကို လုံးျပီး အမိႈက္ပုံးထဲကို ျပစ္ခ်င္တယ္။ စာရြက္သုံးရြက္က သူပို႕ခ်င္တယ့္ data ( packets) ပါ။ CEO ၾကီးက source ၊ အမိႈက္ပုံးက destination ေပါ့။ ဘယ္လိုျပစ္မလည္းဆိုတယ့္ manner က TCP / UDP ပါပဲ။ TCP လိုျပစ္ရင္ေတာ့ ပထမ တစ္ရြက္ျပစ္တယ္၊ ဝင္မဝင္ၾကည့္တယ္၊ ဝင္ရင္ ေနာက္တစ္ရြက္ထပ္ျပစ္တယ္။ ျပဳတ္က်သြားရင္ေတာ့ ( ထေကာက္ျပီးေတာ့) ေနာက္တစ္ခါထပ္ျပစ္တယ္။ အဓိကက စာရြက္သုံးရြက္လုံး အမိႈက္ပုံးထဲဝင္တာ ေသခ်ာဖို႕ စနစ္တက်ျပစ္တယ္ပဲ ဆိုပါေတာ့။ UDP ဆိုရင္ေတာ့ တစ္ ႏွစ္ သုံး ဆိုျပီး အမိႈက္ပုံးရွိမယ့္ဘက္ကို အကုန္ျပစ္လိုက္မယ္၊ ဝင္တာမဝင္တာ ဂ႐ုမစိုက္ဘူး ၊ မဝင္လည္းေနပါေစေပါ့။
CEO level က အရမ္း briefly ျဖစ္ေနတယ္။ ေနာက္ example တစ္ခုေျပာမယ္။ We should call it "Project manager level explanation" လို႕ေျပာေတာ့ PM က မ်က္ေထာင့္နီနဲ႕ၾကည့္တယ္။
က်ေနာ္တို႕ စာတစ္ေစာင္ ပို႕မယ္ဆိုပါေတာ့။ စာက Data ၊ က်ေနာ္က source ၊ က်ေနာ္ပို႕ခ်င္တယ့္ လိပ္စာက Destination ေပါ့။ ဘယ္လိုပို႕မလည္း ( transmission method ) ႏွစ္ခုေရြးစရာရွိမယ္ ။ DHL နဲ႕ ပံုမွန္ unregistered post mail ေပါ့။
DHL နဲ႕ပို႕တယ္ဆိုပါေတာ့ ၊
1. DHL က အိမ္ေရွ႕ကိုေရာက္ေအာင္လာမယ္ ( route)
2. အိမ္တခါးကို လာေခါက္မယ္ ( 3 way hand-shake)
3. ဒီ address မွာ ဒီစာကို လက္ခံႏိုင္ေၾကာင္း ေသခ်ာမွ
4. စာကိုေပးျပီးရင္လည္း လက္ခံရရွိေၾကာင္း လက္မွတ္ထိုးခိုင္းမယ္ ( Acknowledgement)
5. တကယ္လို႕ လက္ခံမယ့္ဘက္က လူမရွိရင္ပဲျဖစ္ျဖစ္ ၊ လက္ခံဖို႕အရမ္းအလုပ္ေတြရွုပ္ေနရင္ပဲျဖစ္ျဖစ္ ၊ ေနာက္တစ္ေခါက္ျပန္ပို႕မယ္ ( transmission control, windowing)
6. ဒီလိပ္စာက ဒီလူမရွိေတာ့တာမ်ိဳး၊ လိပ္စာမွားေနတာမ်ိဳးဆို sender ကိုျပန္ အေၾကာင္းၾကားမယ္။
Sender ဖက္က ပို႕လိုက္တာ ေရာက္မေရာက္ သိႏိုင္မယ္ ၊ လိုအပ္ရင္ ေနာက္တစ္ေခါက္ ၊ ေနာက္တစ္ေနရာ ပို႕ဖို႕လိုအပ္ရင္ လည္းသိရမွာေပါ့။
Unregisterd post mail ဆိုရင္ေတာ့
1. အိမ္ေအာက္က mailbox ကိုလာမယ္ ( route)
2. စာတိုက္ပုံးထဲ ထဲခဲ့မယ္
လက္ခံရမယ့္လူ အိမ္ေျပာင္းသြားလို႕ သူလက္ထဲမေရာက္လည္း တာဝန္မယူဖူး။ ေရာက္လားမေရာက္လားလည္း မသိႏိုင္ဘူး။
ဒီ example မွာ connection less နဲ႕ connection oriented ပံုစံကို ထဲ့မေျပာႏိုင္ေပမယ့္ ႏွစ္ခုလုံးက destination ကိုသိျပီး destination ကိုပဲေရာက္ေအာင္လာၾကတာပါပဲ။ Transmission control ပါတာနဲ႕ မပါတာပဲ အဓိကကြဲတယ္လို႕ ေျပာရင္ရပါတယ္။
Technical engineer ကိုဒါမ်ိဳးေျပာလို႕ မရႏိုင္ေပမယ့္ ၊ ဘာမွန္းမသိ စြတ္ေျပာတတ္တယ့္ သူေဌးေတြ ( PM ေတြေရာေပါ့) အတြက္ေတာ့ သူတို႕ညာဏ္နဲ႕ လိုက္မွီတယ့္ explanation ျဖစ္မယ္ထင္ပါတယ္ :D ။
စာမေရးတာၾကာျပီ ၊ ဘာမွ မလုပ္တာၾကာျပီ ။ တစ္ခုခုေသျခာျပန္လုပ္မယ္လို႕ စိတ္ကူးျပီး တျခား colleague တစ္ေရာက္စီကေန သူ download လုပ္ထားတယ့္ game အသစ္ေတြ 36 GB ဒီေန႕ copy လုပ္လိုက္ပါတယ္ ။
Divinity
Thursday, July 29, 2010
Linux commands (1)
Linux console ေပၚမွာ အလုပ္လုပ္တယ့္ အခါ တစ္ခ်ိဳ႕ command ေတြက သိထားရင္ command line interface မွာ အေတာ္အသုံးဝင္ပါတယ္။ မသိလည္းရတယ္ ၊ သိရင္ ပိုအဆင္ေျပတယ့္ command ေလးေတြေပါ့။ နည္းနည္းခ်င္း ေခါင္းထဲေပၚလာသေလာက္ ေရးသြားပါမယ္။
...........
Log file လိုဟာမ်ိဳးကို ဖတ္တယ့္အခါမွာ tail command ကသုံးဝင္ပါတယ္ ။ ဆိုၾကပါေတာ့၊ httpd ရဲ့ access_log file ။ Apache process run ေနျပီး user ေတြက access လုပ္ေနတိုင္း access_log ကေရးေနပါတယ္။ ဒီလို log မ်ိဳးရဲ့ ေနာက္ဆုံး process ေတြ log ကို လိုခ်င္ရင္ အလြယ္တကူက `cat /var/log/httpd/access_log ဆိုျပီး cat ထုတ္လိုက္တာမ်ိဳး ၊ tail -n50 /var/log/httpd/access_log ဆိုျပီး ေနာက္ဆုံး လိုင္း 50 ေခၚၾကည့္တာတို႕ လုပ္လိုက္တာမ်ားတယ္။ ဒါေတြက ဒီ command ကို ႐ိုက္လိုက္တယ့္ အခ်ိန္က log ထဲမွာရွိတာကိုျပတာပါ။ Real time ေတာက္ေလွ်ာက္လာေရးေနတာကို ဖတ္ခ်င္ရင္ေတာ့
ဆိုျပီး tail -f ကိုသုံးပါတယ္။ ဒါဆို console ထဲမွာ log file ကပြင့္လာျပီး log မွာ တစ္လိုင္းအသစ္လာေရးတိုင္း တစ္လိုင္းတက္တက္လာတယ္။ ဒါဆို debug လုပ္ဖို႕ ပို အဆင္ေျပပါတယ္။
........
တစ္ခါတစ္ေလ log file ( text file တစ္ခုခုေပါ့) ကို ရွင္းလိုက္ခ်င္တာမ်ိဳးေတြမွာ ၊ အထဲက စာေတြ လိုက္ဖ်က္ရရင္လည္း မလြယ္ဘူး။ File ကိုဖ်က္ျပစ္လိုက္ျပီး ၊ process က log ျပန္လာေရးခိုင္းတာကလည္း ေျပာရင္ သိပ္မေကာင္းဖူး။ File ကို ဖ်က္ျပစ္လိုက္ရတာကိုက မေကာင္းဘူး။ အထဲက content ကိုပဲ ရွင္းလိုက္ခ်င္ရင္ ဒီလိုေလးက လြယ္တယ္ ။
အေရွ႕က '>' ေလးက command ထဲမွာပါပါတယ္။ တစ္ကယ္က
ကိုလုပ္သြားတာပါ။ echo command နဲ႕ output pipe '>' ကိုသိရင္ ဒါကိုသိပါလိမ့္မယ္။ File ထဲက content ကို blank space တစ္ခုနဲ႕ overwrite လုပ္လိုက္တာပါ။ အဲေတာ့ log file က empty log ျဖစ္သြားတာေပါ့။
..........
ေနာက္တစ္ခုကေတာ့ shell arguments ေတြပါ။ အသုံးျဖစ္ဆုံးကေတာ့ ! နဲ႕ !$ ပါ ။
! က ေနာက္ဆုံးသုံးခဲ့တယ့္ argument ကို ကိုယ္စားျပဳပါတယ္။ တကယ္လို႕ အေပၚမွာ file တစ္ခုကို vi သုံးျပီး edit ထားတယ္။ အခု တျခား directory ကိုေရာက္ေနျပီ ။ File path ၾကီးကရွည္လို႕ ျပန္မ႐ိုက္ခ်င္ဖူးဆိုရင္
လို႕ သုံးလို႕ရပါတယ္။ Shell history ထဲက ေနာက္ဆုံး vi command ကိုျပန္ေခၚေပးပါလိမ့္မယ္။
.......
!$ ကေတာ့ last command ရဲ့ argument ကိုပဲယူတာပါ။
လို႕ ရွာျပီး၊ ေနာက္တစ္လိုင္းမွာ အဲ file ကို vi မွာ edit ဖို႕ဆိုရင္ ပံုမွန္ဆို vi /bar/nyar/thar/da/kar/file ဆိုျပီး ရွည္ရွည္လွ်ားလွ်ား႐ိုက္ေနရပါမယ္။ အဲေတာ့
လို႕႐ိုက္လိုက္ရင္ ေနာက္ဆုံး command ရဲ့ argument ကိုျပန္ယူျပီး vi သြားပါလိမ့္မယ္ ။
( Up arrow နဲ႕ last command ကိုျပန္ေခၚ၊ Home ကိုႏွိပ္ျပီး ls -l ကိုဖ်က္ vi လို႕႐ိုက္ ၊ ဒါလည္းရပါတယ္။ ဒါေပမယ့္ ပိုမရွည္ဖူးလား။ ဒါေတာင္ Home တို႕ End တို႕ကို Shell environment ထဲမွာ set ထားမွပါ။ Unix အမ်ားစုမွာ default အားျဖင့္မပါပါဘူး။ Home ႏွိပ္လိုက္ရင္ ^ ေတြနဲ႕ ေပၚလာပါလိမ့္မယ္။ )
..........
အခုေတာ့ ေတာ္ေလာက္ျပီ။ အခုသုံးလိုက္မိတာေလးေတြ ေျပာျပတာပါ။ ေနာက္ၾကံုရင္ ၾကံုတာေတြ ေရးပါအုန္းမယ္ ။ တစ္ခ်ိဳ႕ command ေတြက သူ႕ေနာက္က option ေတြအရမ္း powerful ျဖစ္တာေတြရွိပါတယ္။ find တို႕လို command မ်ိဳးေပါ့။ exec လို အသုံးတယ့္တာေတြလည္း ရွိပါေသးတယ္။ ေနာက္မ်ားမွ ....
Divinity
...........
Log file လိုဟာမ်ိဳးကို ဖတ္တယ့္အခါမွာ tail command ကသုံးဝင္ပါတယ္ ။ ဆိုၾကပါေတာ့၊ httpd ရဲ့ access_log file ။ Apache process run ေနျပီး user ေတြက access လုပ္ေနတိုင္း access_log ကေရးေနပါတယ္။ ဒီလို log မ်ိဳးရဲ့ ေနာက္ဆုံး process ေတြ log ကို လိုခ်င္ရင္ အလြယ္တကူက `cat /var/log/httpd/access_log ဆိုျပီး cat ထုတ္လိုက္တာမ်ိဳး ၊ tail -n50 /var/log/httpd/access_log ဆိုျပီး ေနာက္ဆုံး လိုင္း 50 ေခၚၾကည့္တာတို႕ လုပ္လိုက္တာမ်ားတယ္။ ဒါေတြက ဒီ command ကို ႐ိုက္လိုက္တယ့္ အခ်ိန္က log ထဲမွာရွိတာကိုျပတာပါ။ Real time ေတာက္ေလွ်ာက္လာေရးေနတာကို ဖတ္ခ်င္ရင္ေတာ့
tail -f /var/log/httpd/access_log
ဆိုျပီး tail -f ကိုသုံးပါတယ္။ ဒါဆို console ထဲမွာ log file ကပြင့္လာျပီး log မွာ တစ္လိုင္းအသစ္လာေရးတိုင္း တစ္လိုင္းတက္တက္လာတယ္။ ဒါဆို debug လုပ္ဖို႕ ပို အဆင္ေျပပါတယ္။
........
တစ္ခါတစ္ေလ log file ( text file တစ္ခုခုေပါ့) ကို ရွင္းလိုက္ခ်င္တာမ်ိဳးေတြမွာ ၊ အထဲက စာေတြ လိုက္ဖ်က္ရရင္လည္း မလြယ္ဘူး။ File ကိုဖ်က္ျပစ္လိုက္ျပီး ၊ process က log ျပန္လာေရးခိုင္းတာကလည္း ေျပာရင္ သိပ္မေကာင္းဖူး။ File ကို ဖ်က္ျပစ္လိုက္ရတာကိုက မေကာင္းဘူး။ အထဲက content ကိုပဲ ရွင္းလိုက္ခ်င္ရင္ ဒီလိုေလးက လြယ္တယ္ ။
> /path/to/log.file
အေရွ႕က '>' ေလးက command ထဲမွာပါပါတယ္။ တစ္ကယ္က
echo "" > /path/to/log.file
ကိုလုပ္သြားတာပါ။ echo command နဲ႕ output pipe '>' ကိုသိရင္ ဒါကိုသိပါလိမ့္မယ္။ File ထဲက content ကို blank space တစ္ခုနဲ႕ overwrite လုပ္လိုက္တာပါ။ အဲေတာ့ log file က empty log ျဖစ္သြားတာေပါ့။
..........
ေနာက္တစ္ခုကေတာ့ shell arguments ေတြပါ။ အသုံးျဖစ္ဆုံးကေတာ့ ! နဲ႕ !$ ပါ ။
! က ေနာက္ဆုံးသုံးခဲ့တယ့္ argument ကို ကိုယ္စားျပဳပါတယ္။ တကယ္လို႕ အေပၚမွာ file တစ္ခုကို vi သုံးျပီး edit ထားတယ္။ အခု တျခား directory ကိုေရာက္ေနျပီ ။ File path ၾကီးကရွည္လို႕ ျပန္မ႐ိုက္ခ်င္ဖူးဆိုရင္
!vi
လို႕ သုံးလို႕ရပါတယ္။ Shell history ထဲက ေနာက္ဆုံး vi command ကိုျပန္ေခၚေပးပါလိမ့္မယ္။
.......
!$ ကေတာ့ last command ရဲ့ argument ကိုပဲယူတာပါ။
ls -l /bar/nyar/thar/da/kar/file
လို႕ ရွာျပီး၊ ေနာက္တစ္လိုင္းမွာ အဲ file ကို vi မွာ edit ဖို႕ဆိုရင္ ပံုမွန္ဆို vi /bar/nyar/thar/da/kar/file ဆိုျပီး ရွည္ရွည္လွ်ားလွ်ား႐ိုက္ေနရပါမယ္။ အဲေတာ့
vi !$
လို႕႐ိုက္လိုက္ရင္ ေနာက္ဆုံး command ရဲ့ argument ကိုျပန္ယူျပီး vi သြားပါလိမ့္မယ္ ။
( Up arrow နဲ႕ last command ကိုျပန္ေခၚ၊ Home ကိုႏွိပ္ျပီး ls -l ကိုဖ်က္ vi လို႕႐ိုက္ ၊ ဒါလည္းရပါတယ္။ ဒါေပမယ့္ ပိုမရွည္ဖူးလား။ ဒါေတာင္ Home တို႕ End တို႕ကို Shell environment ထဲမွာ set ထားမွပါ။ Unix အမ်ားစုမွာ default အားျဖင့္မပါပါဘူး။ Home ႏွိပ္လိုက္ရင္ ^ ေတြနဲ႕ ေပၚလာပါလိမ့္မယ္။ )
..........
အခုေတာ့ ေတာ္ေလာက္ျပီ။ အခုသုံးလိုက္မိတာေလးေတြ ေျပာျပတာပါ။ ေနာက္ၾကံုရင္ ၾကံုတာေတြ ေရးပါအုန္းမယ္ ။ တစ္ခ်ိဳ႕ command ေတြက သူ႕ေနာက္က option ေတြအရမ္း powerful ျဖစ္တာေတြရွိပါတယ္။ find တို႕လို command မ်ိဳးေပါ့။ exec လို အသုံးတယ့္တာေတြလည္း ရွိပါေသးတယ္။ ေနာက္မ်ားမွ ....
Divinity
Thursday, July 22, 2010
RAID is not *Backup*
Well,I've heard of this since a few years back. It could never protect from Human errors, e.g, mistakenly issued a DROP database command. :)
Some people believe RAID 1 could save them from the risk of data looses due to hardware failure since they have 2 copies of every things. That's partially true. RAID 1 could save you from data looses due to 'a hard drive failure', not any of hardware failure. In a RAID 1 system, it includes 2 hard drives minimum ( could be 3 with a hot-spare) and a RAID controller card. Everything on a primary HDD is mirrored across on secondary one. So even if the primary HDD is failed, we could still continue our business since every bits of data are still exist on the secondary HDD. Probability of failing both HDDs at the same time is a very rare chance, approximately 0.01% chances only. Looks promising, right ?
But as I've said above, RAID controllers are involved in RAID systems and they play the main role in it. In most cases, when a RAID controller fails, it might make some improper I/O onto the hard drives which can bring your system into file system corruption. The chances of failing RAID controller is a bit high if we are dealing with integrated raid cards. Dedicated RAID controllers are much better in this case.
...................................
I've had this problem one time a year ago on Windows System running on RAID 5. It makes my system hang and gives BSOD on next reboot ( still BSOD even on the other known good machines). At that time I got a few luck to copy out all data using a Linux Live CD and it was a development server which is not too critical.
Just in a few days ago, one of our client gives us a call and says their payment gateway system is not accessible. What a generic report from a user 'not accessible' with no specific details. I could browse to their admin web UI and ssh in and looks around. But when i tried to create a file using 'touch' I got an error. Well, this's it. Initially, I was totally clam as I know this system is running on 2 mirrored HDDs. If a HDD fails, I can just swap it with a new HDD and bingo. That is what I've in my mind while travelling down to data center.
But it was not that fortunate. I was surprised to see both HDD having the same IO issue. Magic fsck could not help me this time. Try those HDDs with another spare identical machine, Kernel panic. I whispers "that's good. you give me something interesting bullsh*t for today". By running ServeRAID on the problematic machine, I could see it can't detect the HDDs all the the time even to the new HDD I just brought from office. Only thing I can do is I can backup databases and some data from linux rescue mode. Yes, some lib directories are not even browsable at this point.
I've left with no choice but to prepare a new server to replace. This existing system has self compiled Apache and some modules, including openssl and some libraries which supports TLS. It's not a difficult things, but it takes time. It's 11pm already when I started installing a new server. Well, that's an almost overnight working day.
...................................
When a RAID controller's gone, it has a chance all your data could be gone/corrupted too. So backup is a 'must' even if you are running on RAID 50. Be planned, be prepared.
Divinity
Some people believe RAID 1 could save them from the risk of data looses due to hardware failure since they have 2 copies of every things. That's partially true. RAID 1 could save you from data looses due to 'a hard drive failure', not any of hardware failure. In a RAID 1 system, it includes 2 hard drives minimum ( could be 3 with a hot-spare) and a RAID controller card. Everything on a primary HDD is mirrored across on secondary one. So even if the primary HDD is failed, we could still continue our business since every bits of data are still exist on the secondary HDD. Probability of failing both HDDs at the same time is a very rare chance, approximately 0.01% chances only. Looks promising, right ?
But as I've said above, RAID controllers are involved in RAID systems and they play the main role in it. In most cases, when a RAID controller fails, it might make some improper I/O onto the hard drives which can bring your system into file system corruption. The chances of failing RAID controller is a bit high if we are dealing with integrated raid cards. Dedicated RAID controllers are much better in this case.
...................................
I've had this problem one time a year ago on Windows System running on RAID 5. It makes my system hang and gives BSOD on next reboot ( still BSOD even on the other known good machines). At that time I got a few luck to copy out all data using a Linux Live CD and it was a development server which is not too critical.
Just in a few days ago, one of our client gives us a call and says their payment gateway system is not accessible. What a generic report from a user 'not accessible' with no specific details. I could browse to their admin web UI and ssh in and looks around. But when i tried to create a file using 'touch' I got an error. Well, this's it. Initially, I was totally clam as I know this system is running on 2 mirrored HDDs. If a HDD fails, I can just swap it with a new HDD and bingo. That is what I've in my mind while travelling down to data center.
But it was not that fortunate. I was surprised to see both HDD having the same IO issue. Magic fsck could not help me this time. Try those HDDs with another spare identical machine, Kernel panic. I whispers "that's good. you give me something interesting bullsh*t for today". By running ServeRAID on the problematic machine, I could see it can't detect the HDDs all the the time even to the new HDD I just brought from office. Only thing I can do is I can backup databases and some data from linux rescue mode. Yes, some lib directories are not even browsable at this point.
I've left with no choice but to prepare a new server to replace. This existing system has self compiled Apache and some modules, including openssl and some libraries which supports TLS. It's not a difficult things, but it takes time. It's 11pm already when I started installing a new server. Well, that's an almost overnight working day.
...................................
When a RAID controller's gone, it has a chance all your data could be gone/corrupted too. So backup is a 'must' even if you are running on RAID 50. Be planned, be prepared.
Divinity
Wednesday, July 21, 2010
SUID ဆိုတာ
Linux / Unix system ေတြအေၾကာင္းေလ့လာရင္ SUID / SGID ဆိုတယ့္ အသုံးအႏွုန္းမ်ိဳး ေတြ႕ရတတ္ပါတယ္ ။ SUID ဆိုတာ Set User ID ကို အတိုေခၚတာပါ။ Executable file ေတြရဲ့ permission မွာ ေပးေလ့ရွိပါတယ္ ။ SUID ေပးရတယ့္ ရည္ရြယ္ခ်က္က executable permission ရွိတယ့္ ဘယ္ user ကပဲ execute လုပ္လုပ္ ၊ ဒီ command / file ကို file owner ရဲ့ identity နဲ႕ run လိုက္ပါတယ္။ ဆိုလိုတာကေတာ့ root user ရဲ့ file တစ္ခုကို everyone executable ေပးထားမယ္၊ ဒါေပမဲ့ SUID set ထားရင္ ဘယ္ user ကပဲ run run ဒီ file က root user အေနနဲ႕ run ပါမယ္။ အနီးစပ္ဆုံး လို႕ ထင္တယ့္ windows ဥပမာကေတာ့ run as administrator နဲ႕ run သလိုေပါ့။ ( သိပ္ေတာ့မတူသလိုပါပဲ။ Run as administrator ကိုေသခ်ာမသိလို႕ မေျပာႏိုင္ပါဘူး)
Linux / Unix မွာ file permission ကို rwx ( Read, Write, Execute) ဆိုျပီး သတ္မွတ္ပါတယ္။ SGID / SUID ေပးထားရင္ေတာ့ s ဆိုတာေလးေတြ႕ရေလ့ရွိပါတယ္။ဥပမာေလး ေျပာရေအာင္ ။
User တိုင္းကို cd တို႕ ls တို႕လို command မ်ိဳးကိုေတာ့ ေပးသုံးရပါတယ္။ အဲလို command တစ္ခုရဲ့ permission ကိုၾကည့္ရင္
File ရဲ့ owner က root ျဖစ္ျပီး other users ( Everyone ေပါ့ဗ်ာ Windows မွာေတာ့) ကို Executable permission ေပးထားတာေတြ႕ပါလိမ့္မယ္ ။ Linux File permission ( rwx တို႕ ၊ 700 တို႕ 777 တို႕ )အေၾကာင္းသိျပီးသား လို႕ ယူစလို႕ ဒါကိုမရွင္းေတာ့ပါဘူး။ ls command ကို User တိုင္းက အသုံးျပဳႏိုင္တယ္။ ေနာက္ထပ္ User တိုင္း သုံး လို႕ရတယ့္ command ေလးတစ္ခုကိုၾကည့္ရေအာင္။ Password change တယ့္ passwd command ပါ။
သူလည္း everyone executable ေပးထားတယ္ ဒါေပမယ့္ တတိယအလုံးမွာ x မဟုတ္ပဲ s ျဖစ္ေနတယ္။ ဒါ SUID set ထားတယ္လို႕ ေဖာ္ျပတာပါ။ ls command တုန္းကလိုပဲ သူ႕မွာလည္း ေနာက္ဆုံးအလုံးက 'x' ၊ ဒါဆို others မွာ executable permission ေပးထားတာေပါ့။ ကြာတာက ၊ ေရွ႕မွာ 's' ျဖစ္ေနတယ္။ ls command တုန္းကလိုပဲ User တိုင္းကသုံးႏိုင္တယ္။ ဒါေပမဲ့ ဒီ passwd command ကို သုံးျပီး လုပ္သမွ်အလုပ္တိုင္းကိုေတာ့ root အေနနဲ႕ လုပ္သြားမွာျဖစ္ပါတယ္။ SUID ကို security consideration တစ္ခုအေနနဲ႕ သတ္မွတ္ၾကေလ့ရွိပါတယ္။ Command တိုင္း file တိုင္းကို အားတိုင္း SUID set မလုပ္ဖို႕ အျပင္းအထန္ ကန္႕ကြက္ပါတယ္။ ဘာလို႕လည္း ?
ခုနက passwd command ေလးကိုပဲ ၾကည့္ရေအာင္။ User တစ္ေယာက္ရဲ့ password ဟာ /etc/shadow ဆိုတယ့္ file ထဲမွာ hash အေနနဲ႕ ရွိပါတယ္။ တကယ္လို႕သာ ဒီ hash ေတြကို ရရင္ rainbow table ေတြဘာေတြနဲ႕ decipher လုပ္ႏိုင္ေကာင္းလုပ္ႏိုင္ပါတယ္။ Root user ရဲ့ password လည္း hash အေနနဲ႕ ရွိပါတယ္။ အဲေတာ့ ဒီ /etc/shadow file ထဲက data က အရမ္းအေရးၾကီးတယ့္ sensitive data ပါ။ ျဖစ္ႏိုင္ရင္ ဘယ္ user ကိုမွ ေပးမၾကည့္သင့္ဖူးေပါ့။ ဒီ /etc/shadow file ရဲ့ owner က default အေနနဲ႕ root ျဖစ္ျပီး permission က 700 ( Owner သာလွ်င္ rwx ရွိျပီး က်န္တယ့္လူေတြ read ေတာင္လုပ္လို႕မရတယ့္ permission) ေပးထားေလ့ရွိပါတယ္။
အဲမွာ စတာပါပဲ ၊ User တစ္ေယာက္က password change ရင္ passwd command ရဲ့ process တစ္ခုအေနနဲ႕ password အသစ္ကို hash ေျပာင္းျပီး ဒီ /etc/shadow file ထဲမွာရွိတယ့္ သူ႕ရဲ့ password hash ကို ျပင္ရပါမယ္။ ဒါမွ password အသစ္ျဖစ္မွာကိုး။ ဒါေပမယ့္ root user ကပဲ ဒီ file ကို edit လို႕ရတယ္။ ဒါဆို password change တိုင္း root ကိုလွမ္း change ခိုင္းရမွာလား ။ ဒါဆိုလည္း မဟုတ္ေသးဘူး။ ဒါေတြေၾကာင့္ password change ရာမွာသုံးတယ့္ passwd command ကို root အေနနဲ႕ SUID set ထားလိုက္ပါတယ္။ passwd command က လုပ္တယ့္ အလုပ္မွန္သမွ် ၊ /etc/shadow မွာ hash update လုပ္တာအပါအဝင္၊ အားလုံးကို ဒီ file ရဲ့ owner ျဖစ္တယ့္ root user အေနနဲ႕ လုပ္သြားလိုက္တယ္။ /etc/shadow ကို everyone editable ေပးရတာထက္ အမ်ားၾကီးေကာင္းတာေပါ့။ ဒီေလာက္ဆိုရင္ SUID ဆိုတာ ဘာလုပ္တယ္၊ ဘယ္လိုဆိုတာ သိေလာက္ပါျပီ။
အေပၚမွာ ေျပာခဲ့သလိုပဲ SUID set ရင္ အလြန္သတိထားရပါတယ္။ ဒီ executable file က ဘာေတြလုပ္သလည္းဆိုတာရယ္ သူ႕ source ရယ္ကို သိသင့္ပါတယ္။ SGID set ထားတယ့္ file တစ္ခုက တစ္ျခား user ကို write permission မေပးရပါဘူး။ Edit လုပ္ျပီး သူလိုခ်င္တယ့္ command ေတြေျပာင္းသြားရင္ ကိုယ္ပဲ ျပသနာျဖစ္ပါမယ္။ Shell script လိုဟာမ်ိဳး ၊ source file လိုဟာမ်ိဳးကို SUID မေပးသင့္ပါဘူး။ Content ကိုျမင္ေနရလို႕ Buffer Over Flow(BOF) flaw ရွိတာတို႕ဘာတို႕ ျဖစ္ႏိုင္ပါတယ္။ ျဖစ္ႏိုင္ရင္ Compiled binary ကိုပဲ SUID ေပးသင့္ပါတယ္။ ဒါေတာင္ safe လို႕ေျပာလို႕မရပါဘူး။
ခုတစ္ေလာ စာမေရးျဖစ္တာၾကာလို႕ Clonezilla ေလးနဲ႕ server တစ္ခုကို image အျဖစ္ေျပာင္းေနတာ ထိုင္ေစာင့္ရင္း ဒီ post ကိုေရးလိုက္ပါတယ္။ SGID ေတာ့ ေနာက္မွေပါ့ ။ ဘာေရးရမွန္းမသိသလို စာစီမရတာလည္းၾကာျပီ ။ :D
Regards
Divinity
Linux / Unix မွာ file permission ကို rwx ( Read, Write, Execute) ဆိုျပီး သတ္မွတ္ပါတယ္။ SGID / SUID ေပးထားရင္ေတာ့ s ဆိုတာေလးေတြ႕ရေလ့ရွိပါတယ္။ဥပမာေလး ေျပာရေအာင္ ။
User တိုင္းကို cd တို႕ ls တို႕လို command မ်ိဳးကိုေတာ့ ေပးသုံးရပါတယ္။ အဲလို command တစ္ခုရဲ့ permission ကိုၾကည့္ရင္
$ ls -l /bin/ls
-rwxr-xr-x 1 root root 116688 2010-04-28 23:56 /bin/ls
File ရဲ့ owner က root ျဖစ္ျပီး other users ( Everyone ေပါ့ဗ်ာ Windows မွာေတာ့) ကို Executable permission ေပးထားတာေတြ႕ပါလိမ့္မယ္ ။ Linux File permission ( rwx တို႕ ၊ 700 တို႕ 777 တို႕ )အေၾကာင္းသိျပီးသား လို႕ ယူစလို႕ ဒါကိုမရွင္းေတာ့ပါဘူး။ ls command ကို User တိုင္းက အသုံးျပဳႏိုင္တယ္။ ေနာက္ထပ္ User တိုင္း သုံး လို႕ရတယ့္ command ေလးတစ္ခုကိုၾကည့္ရေအာင္။ Password change တယ့္ passwd command ပါ။
ls -l /usr/bin/passwd
-rwsr-xr-x 1 root root 25836 2009-09-14 20:14 /usr/bin/passwd
သူလည္း everyone executable ေပးထားတယ္ ဒါေပမယ့္ တတိယအလုံးမွာ x မဟုတ္ပဲ s ျဖစ္ေနတယ္။ ဒါ SUID set ထားတယ္လို႕ ေဖာ္ျပတာပါ။ ls command တုန္းကလိုပဲ သူ႕မွာလည္း ေနာက္ဆုံးအလုံးက 'x' ၊ ဒါဆို others မွာ executable permission ေပးထားတာေပါ့။ ကြာတာက ၊ ေရွ႕မွာ 's' ျဖစ္ေနတယ္။ ls command တုန္းကလိုပဲ User တိုင္းကသုံးႏိုင္တယ္။ ဒါေပမဲ့ ဒီ passwd command ကို သုံးျပီး လုပ္သမွ်အလုပ္တိုင္းကိုေတာ့ root အေနနဲ႕ လုပ္သြားမွာျဖစ္ပါတယ္။ SUID ကို security consideration တစ္ခုအေနနဲ႕ သတ္မွတ္ၾကေလ့ရွိပါတယ္။ Command တိုင္း file တိုင္းကို အားတိုင္း SUID set မလုပ္ဖို႕ အျပင္းအထန္ ကန္႕ကြက္ပါတယ္။ ဘာလို႕လည္း ?
ခုနက passwd command ေလးကိုပဲ ၾကည့္ရေအာင္။ User တစ္ေယာက္ရဲ့ password ဟာ /etc/shadow ဆိုတယ့္ file ထဲမွာ hash အေနနဲ႕ ရွိပါတယ္။ တကယ္လို႕သာ ဒီ hash ေတြကို ရရင္ rainbow table ေတြဘာေတြနဲ႕ decipher လုပ္ႏိုင္ေကာင္းလုပ္ႏိုင္ပါတယ္။ Root user ရဲ့ password လည္း hash အေနနဲ႕ ရွိပါတယ္။ အဲေတာ့ ဒီ /etc/shadow file ထဲက data က အရမ္းအေရးၾကီးတယ့္ sensitive data ပါ။ ျဖစ္ႏိုင္ရင္ ဘယ္ user ကိုမွ ေပးမၾကည့္သင့္ဖူးေပါ့။ ဒီ /etc/shadow file ရဲ့ owner က default အေနနဲ႕ root ျဖစ္ျပီး permission က 700 ( Owner သာလွ်င္ rwx ရွိျပီး က်န္တယ့္လူေတြ read ေတာင္လုပ္လို႕မရတယ့္ permission) ေပးထားေလ့ရွိပါတယ္။
အဲမွာ စတာပါပဲ ၊ User တစ္ေယာက္က password change ရင္ passwd command ရဲ့ process တစ္ခုအေနနဲ႕ password အသစ္ကို hash ေျပာင္းျပီး ဒီ /etc/shadow file ထဲမွာရွိတယ့္ သူ႕ရဲ့ password hash ကို ျပင္ရပါမယ္။ ဒါမွ password အသစ္ျဖစ္မွာကိုး။ ဒါေပမယ့္ root user ကပဲ ဒီ file ကို edit လို႕ရတယ္။ ဒါဆို password change တိုင္း root ကိုလွမ္း change ခိုင္းရမွာလား ။ ဒါဆိုလည္း မဟုတ္ေသးဘူး။ ဒါေတြေၾကာင့္ password change ရာမွာသုံးတယ့္ passwd command ကို root အေနနဲ႕ SUID set ထားလိုက္ပါတယ္။ passwd command က လုပ္တယ့္ အလုပ္မွန္သမွ် ၊ /etc/shadow မွာ hash update လုပ္တာအပါအဝင္၊ အားလုံးကို ဒီ file ရဲ့ owner ျဖစ္တယ့္ root user အေနနဲ႕ လုပ္သြားလိုက္တယ္။ /etc/shadow ကို everyone editable ေပးရတာထက္ အမ်ားၾကီးေကာင္းတာေပါ့။ ဒီေလာက္ဆိုရင္ SUID ဆိုတာ ဘာလုပ္တယ္၊ ဘယ္လိုဆိုတာ သိေလာက္ပါျပီ။
အေပၚမွာ ေျပာခဲ့သလိုပဲ SUID set ရင္ အလြန္သတိထားရပါတယ္။ ဒီ executable file က ဘာေတြလုပ္သလည္းဆိုတာရယ္ သူ႕ source ရယ္ကို သိသင့္ပါတယ္။ SGID set ထားတယ့္ file တစ္ခုက တစ္ျခား user ကို write permission မေပးရပါဘူး။ Edit လုပ္ျပီး သူလိုခ်င္တယ့္ command ေတြေျပာင္းသြားရင္ ကိုယ္ပဲ ျပသနာျဖစ္ပါမယ္။ Shell script လိုဟာမ်ိဳး ၊ source file လိုဟာမ်ိဳးကို SUID မေပးသင့္ပါဘူး။ Content ကိုျမင္ေနရလို႕ Buffer Over Flow(BOF) flaw ရွိတာတို႕ဘာတို႕ ျဖစ္ႏိုင္ပါတယ္။ ျဖစ္ႏိုင္ရင္ Compiled binary ကိုပဲ SUID ေပးသင့္ပါတယ္။ ဒါေတာင္ safe လို႕ေျပာလို႕မရပါဘူး။
ခုတစ္ေလာ စာမေရးျဖစ္တာၾကာလို႕ Clonezilla ေလးနဲ႕ server တစ္ခုကို image အျဖစ္ေျပာင္းေနတာ ထိုင္ေစာင့္ရင္း ဒီ post ကိုေရးလိုက္ပါတယ္။ SGID ေတာ့ ေနာက္မွေပါ့ ။ ဘာေရးရမွန္းမသိသလို စာစီမရတာလည္းၾကာျပီ ။ :D
Regards
Divinity
Thursday, July 1, 2010
Wired Equivalent Privacy ( WEP)
WEP နဲ႕ WEP cracking tutorial ကိုျပန္ရွင္းျပတာမ်ိဳး က်ေနာ္ Myanmar IT Resource Forums မွာ ေရးဖူးပါတယ္။ အဲတုန္းက Forum post ဆိုေတာ့ ေမးတာေျဖ၊ ျပန္ေျပာနဲ႕ article ပံုစံေတာ့မဟုတ္ဖူးေပါ့။ အဲတုန္းက ေရးခဲ့ဖူးတာကို က်ေနာ္ blog post ပံုစံ ျပန္ေရးၾကည့္ခ်င္တယ္။ Cracking tuto ေတာ့ ျပန္မရွင္းေတာ့ဖူး။
Wireless ရဲ့ အလုပ္လုပ္ပံုကစရေအာင္။ Wireless connection တစ္ခုခ်ိတ္ရင္ ပထမ Authenticate လုပ္ရတယ္။ ဒါကို associate လုပ္တယ္လို႕ေခၚပါတယ္။ Laptop တစ္ခုက Access point တစ္ခုကို ခ်ိတ္မယ္ဆိုရင္ ပထမဆုံး associate လုပ္ရပါတယ္။ ေနာက္ေတာ့ Association passed ျဖစ္သြားျပီဆိုရင္ data transmission စလုပ္လို႕ရပါျပီ။ ဒီ data ေတြက ေလထဲကသြားေနမွာဆိုေတာ့ Encrypt လုပ္ဖို႕လိုပါတယ္။ Wireless security method ေတြရဲ့ ကြာျခားမႈက ဘယ္လို encrypt လုပ္လည္း၊ ဘယ္လို data packet structure မ်ိဳးနဲ႕ ပို႕လည္းဆိုတာေတြပဲကြဲသြားတာပါ။ WEP key ေရာ WPA key ေရာ WPA2 key ေရာ လက္နဲ႕ ႐ိုက္ထဲ့ရတာၾကီးပဲ။ WEP အေၾကာင္းဆက္ရေအာင္။
WEP 64 bits key က Hexadecimal 10 လုံး၊ က်ေနာ္တို႕ wireless ခ်ိတ္ရင္ ႐ိုက္႐ိုက္ထဲ့ေနၾက။ Hex ကတစ္လုံးမွာ 4 bits ရွိတာ သင္ဖူးတယ္။ Hex 10 လုံးဆိုရင္ 40 bits ရွိရမွာ ၊ ဒါေပမယ့္ 64 bits key လို႕သုံးပါတယ္။ အဲဒီ 40 bits Hex 10 လုံးကိုေတာ့ password လို႕ပဲ သတ္မွတ္ပါတယ္။ ဒီ password က both ends မွာ သိဖို႕လိုပါတယ္ ။ ဆိုလိုတာကေတာ့ Wireless Access Point ဖက္မွာေရာ ၊ ခ်ိတ္မယ့္ client ( laptop ဆိုပါေတာ့) ဖက္မွာပါ ဒီ password ကို သိထားရမယ္။ ဒါကိုသုံးျပီး Associate လုပ္ရမွာကိုး။ ဒီ password က Hex 10 လုံး 40 bits၊ က်န္တယ့္ 24 bits ကိုေတာ့့ Initialization Vector(IV) လို႕ေခၚပါတယ့္ random generated binary string ပါ။ Password 40 bits + IV 24 bits = WEP Key 64 bits ျဖစ္သြားတယ္။ ဒါက WEP key အေၾကာင္း။ data transaction လုပ္ေတာ့ ဒီ key ကို ဘယ္ေနရာမွာသုံးလည္းဆိုေတာ့ ..
( နည္းနည္း ရွုပ္ရေအာင္ ။) WEP မွာ hash / encryption အတြက္ RC4 Algorithm ကိုသုံးပါတယ္။ ခုနက ရထားတယ့္ 64 bits key ကို RC4 ကိုသုံးျပီး encrypt လုပ္လိုက္ပါတယ္။ အဲဒီကေနရလာတယ့္ hash ကိုသုံးျပီး ပို႕ခ်င္တယ့္ data ကို Eclusive Or (XOR) လုပ္လိုက္ပါတယ္။ DATA ကို XOR လုပ္လိုက္လို႕ ရလာတယ့္ Cipher text ကိုမွ ခုနက 24 bits IV နဲ႕ တြဲျပီး transmit လုပ္ပါတယ္ ။ လက္ခံရရွိတယ့္ ဘက္မွာက 40 bits password ကသိေနျပီးသားေလ။ အဲေတာ့ သိျပီးသား Password ရယ္၊ ပို႕တယ့္ ထဲမွာပါတယ့္ IV ရယ္ေပါင္းလိုက္၊ ျပီးေတာ့ RC4 နဲ႕ Encrypt ျပန္လုပ္၊ ရလာတယ့္ hash နဲ႕ ခုနက လက္ခံရရွိတယ့္ Cipher text ကို XOR ျပန္လုပ္၊ ဒါဆို data ကို decipher text အေနနဲ႕ ျပန္ျမင္ရျပီ။ ေတာ္ေတာ္ ရွုပ္သြားတယ္။ ငယ္မူျပန္ျပီး ABCD ေတြနဲ႕ စဥ္းစားၾကည့္ရေအာင္။
40 bits Password က A လို႕ဆိုပါေတာ့။ WEP အတြက္ randomly generate လုပ္လိုက္တယ့္ 24 bits IV ကို B လို႕ ဆိုပါေတာ့။ ဒါဆို 64 bits WEP key က AB ျဖစ္သြားျပီ။ ဒီ AB ကို RC4 ကိုသုံးျပီး hash လုပ္လိုက္ေတာ့ C ဆိုတယ့္ hash တစ္ခုရလာပါတယ္ ။
ပို႕မယ့္ Data က 'X' လို႕ထားပါေတာ့။ ( Data လို႕ဆိုတယ့္ေနရာမွာ Integrity check အတြက္ checksum ပါ ပါပါတယ္။) ခုနက ရထားတယ့္ hash 'C' နဲ႕ Data 'X' ကို XOR လုပ္လိုက္ပါတယ္။ Result ကေတာ့ Cipher text တစ္ခုျဖစ္တယ့္ 'Y' ကိုရလာပါတယ္ ။ ဒါဆိုပို႕လို႕ရျပီ။ Cipher text ျဖစ္ေနတယ့္ Y ရယ္၊ IV ျဖစ္တယ့္ B ရယ္ကို data packet ထဲမွာ ထဲ့ပို႕လိုက္ပါတယ္။
လက္ခံရရွိတယ့္ ဘက္ကေရာ။ သူက Cipher text 'Y' ရယ္၊ IV 'B' ရယ္ ရတယ္။ Data က cipher text ဆိုေတာ့ ဖတ္လို႕မရေသးဘူး။ Decrypt ျပန္လုပ္ရအုန္းမယ္။ သူ႕မွာ Password 'A' ကရွိေနျပီးသား၊ သိျပီးသားပါ။ လက္ခံရရွိတယ့္ packet ထဲမွာ IV ျဖစ္တယ့္ 'B' က plain text အျဖစ္ပါလာတယ္။ အဲေတာ့ ဒီႏွစ္ခုေပါင္း AB ကိုရျပီ။ AB ကို သူ႕ဘက္မွာလည္း RC4 encrypt လုပ္လိုက္ေတာ့ hash ျဖစ္တယ့္ 'C' ကိုရပါျပီ။ လက္ခံရရွိထားတယ့္ Cipher text 'Y' ကို hash 'C' နဲ႕ျပန္ျပီးေတာ့ XOR ျပန္လုပ္လိုက္ရင္ Data ျဖစ္တယ့္ 'X' ကို plain text အျဖစ္ျပန္ရပါတယ္။ ( XOR က symmetric ပါ။ C နဲ႕ X ကို xor ရင္ Y ကိုရသလို၊ C နဲ႕ Y ကို xor ျပန္လုပ္ရင္ X ကိုျပန္ရပါတယ္။ အျပန္အလွန္ရတယ္ေပါ့။ ) ဒီပံုက KSA နဲ႕ PRGA ဆိုတာ RC4 ရဲ့ အဆင့္ေတြပါ။ (Disclaimer: I grubbed this image from Google image search)
WEP ရဲ့ အားနည္းခ်က္က အဓိကျဖစ္တယ့္ IV က 24 bits ထဲျဖစ္ေနျပီးေတာ့၊ transmission မွာ plain text အျဖစ္ပို႕ဖို႕ လိုအပ္ေနတာပါပဲ။ အရင္ကေတာ့ WEP မွာ IV ကို ဘယ္လို generate လုပ္မလည္းဆိုတာ ေပၚမွာ ၊ ကြဲျပားပါေသးတယ္။ တခ်ိဳ႕ hardware vendor ေတြက IV ကို အစီအစဥ္တၾက generate လုပ္တယ္။ 00 .. 01 .. 10 .. 11 အဲလိုေပါ့။ ဒါက မွန္းရတာလြယ္လို႕ ေနာက္ေတာ့ pattern တစ္ခုနဲ႕ generate လုပ္ၾကတယ္။ ဒါလည္း pattern ကို ရွာရတာ မခက္ျပန္ဖူး။ ေနာက္ေတာ့ လုံးဝ စိတ္ကူးတဲ့သလို randomly generate လုပ္တာကို သုံးၾကတယ္။ ဒါေပမယ့္ ျပသနာကရွိေနပါေသးတယ္။ 24 bits မို႕ range ကနည္းပါတယ္ 16 သန္းေက်ာ္ေက်ာ္ပဲရွိပါတယ္။ အဲေတာ့ random pick တယ့္ အခါမွာ အခ်ိန္အတိုင္းအတာ တစ္ခုမွာ ျပန္ထပ္တတ္ပါတယ္။ အမ်ားအားျဖင့္ 10000 နဲ႕ 20000 ၾကားမွာ တစ္ခါ ထပ္ပါတယ္။
WEP ကို crack တယ့္ သူက အမ်ားအားျဖင့္ ARP request တစ္ခုကိုေစာင့္ျပီး အၾကိမ္ၾကိမ္ ဒီ request ကိုပဲ reply လုပ္ပါတယ္။ ဆိုလိုတာက data ကေျပာင္းလည္းမသြားဘူး၊ Wireless AP ဘက္က respond မွာသာ IV က random ျဖစ္ေနလို႕ reply ျပန္လာတယ့္ cipher text 'Y' က အမ်ိဳးမ်ိဳးျဖစ္ေနမယ္။ တကယ့္ data 'X" ကမေျပာင္းလည္းဘူးဆိုတာကို သိေနတယ့္ knowledge ကို အေျခခံျပီး IV ျပန္ထပ္သြားတယ့္ အခ်ိန္မွာ collect လုပ္ထားတယ့္ IV ေတြကေန WEP password ကိုျပန္တြက္ယူလို႕ရပါတယ္။ ဒါကေတာ့ algorithm ကို study လုပ္ဖို႕လိုပါမယ္၊ သိခ်င္ရင္ေျပာတာပါ။
Hacker ၾကီးေတြအတြက္ေရးတယ့္ စာမဟုတ္လို႕ Technical ပိုင္းေတြကို တတ္ႏိုင္သေလာက္ရွင္းထားပါတယ္။ WLAN နဲ႕ WAN ဘာကြာမွန္းမသိတယ့္ သူမ်ားအတြက္လည္းမဟုတ္လို႕ ခေရေစ့တြင္းက် မေရးႏိုင္တာကိုလည္း ခြင့္လႊတ္ပါ။ :D
With regards,
Divinity
Wireless ရဲ့ အလုပ္လုပ္ပံုကစရေအာင္။ Wireless connection တစ္ခုခ်ိတ္ရင္ ပထမ Authenticate လုပ္ရတယ္။ ဒါကို associate လုပ္တယ္လို႕ေခၚပါတယ္။ Laptop တစ္ခုက Access point တစ္ခုကို ခ်ိတ္မယ္ဆိုရင္ ပထမဆုံး associate လုပ္ရပါတယ္။ ေနာက္ေတာ့ Association passed ျဖစ္သြားျပီဆိုရင္ data transmission စလုပ္လို႕ရပါျပီ။ ဒီ data ေတြက ေလထဲကသြားေနမွာဆိုေတာ့ Encrypt လုပ္ဖို႕လိုပါတယ္။ Wireless security method ေတြရဲ့ ကြာျခားမႈက ဘယ္လို encrypt လုပ္လည္း၊ ဘယ္လို data packet structure မ်ိဳးနဲ႕ ပို႕လည္းဆိုတာေတြပဲကြဲသြားတာပါ။ WEP key ေရာ WPA key ေရာ WPA2 key ေရာ လက္နဲ႕ ႐ိုက္ထဲ့ရတာၾကီးပဲ။ WEP အေၾကာင္းဆက္ရေအာင္။
WEP 64 bits key က Hexadecimal 10 လုံး၊ က်ေနာ္တို႕ wireless ခ်ိတ္ရင္ ႐ိုက္႐ိုက္ထဲ့ေနၾက။ Hex ကတစ္လုံးမွာ 4 bits ရွိတာ သင္ဖူးတယ္။ Hex 10 လုံးဆိုရင္ 40 bits ရွိရမွာ ၊ ဒါေပမယ့္ 64 bits key လို႕သုံးပါတယ္။ အဲဒီ 40 bits Hex 10 လုံးကိုေတာ့ password လို႕ပဲ သတ္မွတ္ပါတယ္။ ဒီ password က both ends မွာ သိဖို႕လိုပါတယ္ ။ ဆိုလိုတာကေတာ့ Wireless Access Point ဖက္မွာေရာ ၊ ခ်ိတ္မယ့္ client ( laptop ဆိုပါေတာ့) ဖက္မွာပါ ဒီ password ကို သိထားရမယ္။ ဒါကိုသုံးျပီး Associate လုပ္ရမွာကိုး။ ဒီ password က Hex 10 လုံး 40 bits၊ က်န္တယ့္ 24 bits ကိုေတာ့့ Initialization Vector(IV) လို႕ေခၚပါတယ့္ random generated binary string ပါ။ Password 40 bits + IV 24 bits = WEP Key 64 bits ျဖစ္သြားတယ္။ ဒါက WEP key အေၾကာင္း။ data transaction လုပ္ေတာ့ ဒီ key ကို ဘယ္ေနရာမွာသုံးလည္းဆိုေတာ့ ..
( နည္းနည္း ရွုပ္ရေအာင္ ။) WEP မွာ hash / encryption အတြက္ RC4 Algorithm ကိုသုံးပါတယ္။ ခုနက ရထားတယ့္ 64 bits key ကို RC4 ကိုသုံးျပီး encrypt လုပ္လိုက္ပါတယ္။ အဲဒီကေနရလာတယ့္ hash ကိုသုံးျပီး ပို႕ခ်င္တယ့္ data ကို Eclusive Or (XOR) လုပ္လိုက္ပါတယ္။ DATA ကို XOR လုပ္လိုက္လို႕ ရလာတယ့္ Cipher text ကိုမွ ခုနက 24 bits IV နဲ႕ တြဲျပီး transmit လုပ္ပါတယ္ ။ လက္ခံရရွိတယ့္ ဘက္မွာက 40 bits password ကသိေနျပီးသားေလ။ အဲေတာ့ သိျပီးသား Password ရယ္၊ ပို႕တယ့္ ထဲမွာပါတယ့္ IV ရယ္ေပါင္းလိုက္၊ ျပီးေတာ့ RC4 နဲ႕ Encrypt ျပန္လုပ္၊ ရလာတယ့္ hash နဲ႕ ခုနက လက္ခံရရွိတယ့္ Cipher text ကို XOR ျပန္လုပ္၊ ဒါဆို data ကို decipher text အေနနဲ႕ ျပန္ျမင္ရျပီ။ ေတာ္ေတာ္ ရွုပ္သြားတယ္။ ငယ္မူျပန္ျပီး ABCD ေတြနဲ႕ စဥ္းစားၾကည့္ရေအာင္။
40 bits Password က A လို႕ဆိုပါေတာ့။ WEP အတြက္ randomly generate လုပ္လိုက္တယ့္ 24 bits IV ကို B လို႕ ဆိုပါေတာ့။ ဒါဆို 64 bits WEP key က AB ျဖစ္သြားျပီ။ ဒီ AB ကို RC4 ကိုသုံးျပီး hash လုပ္လိုက္ေတာ့ C ဆိုတယ့္ hash တစ္ခုရလာပါတယ္ ။
ပို႕မယ့္ Data က 'X' လို႕ထားပါေတာ့။ ( Data လို႕ဆိုတယ့္ေနရာမွာ Integrity check အတြက္ checksum ပါ ပါပါတယ္။) ခုနက ရထားတယ့္ hash 'C' နဲ႕ Data 'X' ကို XOR လုပ္လိုက္ပါတယ္။ Result ကေတာ့ Cipher text တစ္ခုျဖစ္တယ့္ 'Y' ကိုရလာပါတယ္ ။ ဒါဆိုပို႕လို႕ရျပီ။ Cipher text ျဖစ္ေနတယ့္ Y ရယ္၊ IV ျဖစ္တယ့္ B ရယ္ကို data packet ထဲမွာ ထဲ့ပို႕လိုက္ပါတယ္။
လက္ခံရရွိတယ့္ ဘက္ကေရာ။ သူက Cipher text 'Y' ရယ္၊ IV 'B' ရယ္ ရတယ္။ Data က cipher text ဆိုေတာ့ ဖတ္လို႕မရေသးဘူး။ Decrypt ျပန္လုပ္ရအုန္းမယ္။ သူ႕မွာ Password 'A' ကရွိေနျပီးသား၊ သိျပီးသားပါ။ လက္ခံရရွိတယ့္ packet ထဲမွာ IV ျဖစ္တယ့္ 'B' က plain text အျဖစ္ပါလာတယ္။ အဲေတာ့ ဒီႏွစ္ခုေပါင္း AB ကိုရျပီ။ AB ကို သူ႕ဘက္မွာလည္း RC4 encrypt လုပ္လိုက္ေတာ့ hash ျဖစ္တယ့္ 'C' ကိုရပါျပီ။ လက္ခံရရွိထားတယ့္ Cipher text 'Y' ကို hash 'C' နဲ႕ျပန္ျပီးေတာ့ XOR ျပန္လုပ္လိုက္ရင္ Data ျဖစ္တယ့္ 'X' ကို plain text အျဖစ္ျပန္ရပါတယ္။ ( XOR က symmetric ပါ။ C နဲ႕ X ကို xor ရင္ Y ကိုရသလို၊ C နဲ႕ Y ကို xor ျပန္လုပ္ရင္ X ကိုျပန္ရပါတယ္။ အျပန္အလွန္ရတယ္ေပါ့။ ) ဒီပံုက KSA နဲ႕ PRGA ဆိုတာ RC4 ရဲ့ အဆင့္ေတြပါ။ (Disclaimer: I grubbed this image from Google image search)
WEP ရဲ့ အားနည္းခ်က္က အဓိကျဖစ္တယ့္ IV က 24 bits ထဲျဖစ္ေနျပီးေတာ့၊ transmission မွာ plain text အျဖစ္ပို႕ဖို႕ လိုအပ္ေနတာပါပဲ။ အရင္ကေတာ့ WEP မွာ IV ကို ဘယ္လို generate လုပ္မလည္းဆိုတာ ေပၚမွာ ၊ ကြဲျပားပါေသးတယ္။ တခ်ိဳ႕ hardware vendor ေတြက IV ကို အစီအစဥ္တၾက generate လုပ္တယ္။ 00 .. 01 .. 10 .. 11 အဲလိုေပါ့။ ဒါက မွန္းရတာလြယ္လို႕ ေနာက္ေတာ့ pattern တစ္ခုနဲ႕ generate လုပ္ၾကတယ္။ ဒါလည္း pattern ကို ရွာရတာ မခက္ျပန္ဖူး။ ေနာက္ေတာ့ လုံးဝ စိတ္ကူးတဲ့သလို randomly generate လုပ္တာကို သုံးၾကတယ္။ ဒါေပမယ့္ ျပသနာကရွိေနပါေသးတယ္။ 24 bits မို႕ range ကနည္းပါတယ္ 16 သန္းေက်ာ္ေက်ာ္ပဲရွိပါတယ္။ အဲေတာ့ random pick တယ့္ အခါမွာ အခ်ိန္အတိုင္းအတာ တစ္ခုမွာ ျပန္ထပ္တတ္ပါတယ္။ အမ်ားအားျဖင့္ 10000 နဲ႕ 20000 ၾကားမွာ တစ္ခါ ထပ္ပါတယ္။
WEP ကို crack တယ့္ သူက အမ်ားအားျဖင့္ ARP request တစ္ခုကိုေစာင့္ျပီး အၾကိမ္ၾကိမ္ ဒီ request ကိုပဲ reply လုပ္ပါတယ္။ ဆိုလိုတာက data ကေျပာင္းလည္းမသြားဘူး၊ Wireless AP ဘက္က respond မွာသာ IV က random ျဖစ္ေနလို႕ reply ျပန္လာတယ့္ cipher text 'Y' က အမ်ိဳးမ်ိဳးျဖစ္ေနမယ္။ တကယ့္ data 'X" ကမေျပာင္းလည္းဘူးဆိုတာကို သိေနတယ့္ knowledge ကို အေျခခံျပီး IV ျပန္ထပ္သြားတယ့္ အခ်ိန္မွာ collect လုပ္ထားတယ့္ IV ေတြကေန WEP password ကိုျပန္တြက္ယူလို႕ရပါတယ္။ ဒါကေတာ့ algorithm ကို study လုပ္ဖို႕လိုပါမယ္၊ သိခ်င္ရင္ေျပာတာပါ။
Hacker ၾကီးေတြအတြက္ေရးတယ့္ စာမဟုတ္လို႕ Technical ပိုင္းေတြကို တတ္ႏိုင္သေလာက္ရွင္းထားပါတယ္။ WLAN နဲ႕ WAN ဘာကြာမွန္းမသိတယ့္ သူမ်ားအတြက္လည္းမဟုတ္လို႕ ခေရေစ့တြင္းက် မေရးႏိုင္တာကိုလည္း ခြင့္လႊတ္ပါ။ :D
With regards,
Divinity
Sunday, June 27, 2010
Linux မွာ virus မရွိဘူးဆို ?
အခုတစ္ေလာ Linux မွာ virus မရွိလို႕သုံးတယ္ဆိုတယ့္ သူေတြမ်ားလာတယ္ဆိုတယ့္အေၾကာင္း ညီေလးတစ္ေယာက္ကလာလာေျပာေနတယ္။ Virus ေၾကာက္စရာမလိုလို႕ Ubuntu ပဲသုံးတယ္ဆိုတယ့္ သူေတြေပါ့။ Linux ကေပ်ာ္စရာ လည္းေကာင္းသလို challenging လည္း ပိုမ်ားပါတယ္။ သူတို႕ဘာသာ ဘာေၾကာင့္ပဲသုံးသုံးပါ သုံးျဖစ္ဖို႕က အဓိကေပါ့။ သုံးျဖစ္သြားရင္ သုံးရင္း ေလ့လာရင္း သိလာလိမ့္မယ္။ ဒါေပမယ့္ မသုံးျဖစ္တယ့္ သူေတြ၊ ေလ့လာမႈ အားမေကာင္းတယ့္ သူေတြအတြက္ idea အမွားၾကီးျဖစ္ျပီး 'ဪ ၾကားျပီးျပီလား၊ Linux ဆိုတာၾကီးက virus မရွိဖူးတဲ့' ဆိုျပီး ေယာင္ေတာင္ေတာင္နဲ႕ ကိုယ္တိုင္လည္းမသိပဲ သံေယာင္လိုက္မယ့္သူေတြ အတြက္ေတာ့ မေကာင္းဖူး။
Linux က bullet proof operating system တစ္ခုမဟုတ္ပါဖူး။ Security ကို အဓိက ဦးစားေပးစဥ္းစားထားတယ့္ Unix ကို အေျခခံထားတာပဲရွိတယ္။ လူလုပ္တယ့္ ကိစၥ ဘယ္ေတာ့မွ perfect မျဖစ္ဖူး၊ စိတ္ပူမေနနဲ႕။ Windows နဲ႕ ယွဥ္လိုက္ရင္ Virus နည္းတယ္လို႕ပဲေျပာလို႕ရတယ္။ နည္းလြန္းလို႕ မရွိသလိုျဖစ္ေနတာပါ။ ဘာေၾကာင့္ နည္းတာလည္း ဆိုရင္ေတာ့ ဒါေတြေၾကာင့္လို႕ က်ေနာ္က ျမင္တယ္။
၁။ အသုံးျပဳမႈနည္းပါးျခင္း
Home user ေတြၾကားထဲမွာ Linux အသုံးျပဳသူက 2% ေလာက္ပဲရွိပါတယ္။ ဒီေလာက္ေလးနဲ႕ၾက virus/trojan ေရးတယ့္သူေတြကို မဆြဲေဆာင္ႏိုင္ပါဘူး။ ကိုယ္ေရးတယ့္ virus/trojan ျပန္႕ႏိုင္စြမ္းလည္း နည္းမယ္။ အလုပ္လည္းသိပ္မျဖစ္ဖူးေပါ့။ ဒါနဲ႕ပဲ Linux မွာ virus ေရးဖို႕ သိပ္စိတ္မဝင္စားၾကတာျဖစ္မယ္။ ေနာက္ေတာ့ ရွိလာၾကမွာပါ။
၂။ Advanced Users
လြန္ခဲ့တယ့္ သုံးႏွစ္ 2007 ေလာက္ကထိ Linux ကသုံးရတာမလြယ္ကူပါဘူး။ လြယ္လြယ္ကူကူ သုံးခ်င္သူေတြ၊ Computer အေၾကာင္း သိပ္မသိခ်င္ပါဖူး၊ သုံးလို႕ရျပီးတာပဲ ဆိုတယ့္ သူေတြရဲ့ choice မျဖစ္ခဲ့ပါဖူး။ Linux သုံးတယ့္ သူေတာ္ေတာ္မ်ားမ်ားက IT နယ္ပယ္ထဲကလူေတြ၊ IT ကို အနည္းနဲ႕ အမ်ား စိတ္ဝင္စားတယ့္ သူေတြ မ်ားပါတယ္။ ဒီ computer ေပၚမွာ သူတို႕ ဘာလုပ္ေနတယ္ဆိုတာကို ေသျခာသိတယ့္ သူေတြမို႕ ၊ security sense ရွိၾကပါတယ္။ ေတြ႕ကရာ ေလွ်ာက္ click ၊ install ဆိုျပီး လုပ္ၾကမယ့္ သူေတြမဟုတ္လို႕ ဒီလိုလူေတြကို target ထားတာထက္စာရင္ ၊ Pop-up ေတြ႕ရင္ ေကာက္ click လိုက္မယ့္ novice ေတြကို ပိုျပီး target ထားတာေကာင္းမွာေပါ့။ အဲလို novice ေတြက သုံးရတာပိုလြယ္ကူတယ့္ windows သုံးေလ့ရွိတယ္ေလ။ အဲလို user ေတြ Linux မ်ားမ်ားသုံးလာရင္ Linux လည္း target ေကာင္းတစ္ခုျဖစ္လာမွာပါ၊ စိတ္ဓာတ္မက်ပါနဲ႕။
၃။ Fix ေတြထြက္တာျမန္တယ္
Opensource မို႕လို႕ lib ေတြမွာ exploit ေတြ flaw ေတြရွိေနရင္ ရွာေဖြေတြ႕ရွိသူကတာ inform လုပ္၊ ေနာက္က fix လုပ္မယ့္ သူေတြက အမ်ားၾကီး။ ဒါေၾကာင့္ Linux ရဲ့ exploit ေတြက သိပ္ျပီး ၾကိဳးစားၾကည့္ခ်င္စရာ မေကာင္းဖူး။ ကိုယ္က ဒီေန႕ရွာေတြ႕ ေနာက္ေန႕ fix ထြက္ေနျပီ။ User ေတြ patch install လုပ္တာ မလုပ္တာ တစ္ပိုင္းေပါ့။ MS မွာေတာ့ Conficker တုန္းက exploit ရွာေတြ႕တာနဲ႕ fix က ႏွစ္လေလာက္ၾကာပါတယ္။ User က update မလုပ္မိတာေတြရွိလို႕ ဒီ exploit က တစ္ႏွစ္ေလာက္ ေကာင္းေကာင္း အလုပ္ျဖစ္ေနတာပဲ။ ဒီလိုေတြရွိေတာ့လည္း လုပ္စားရ ပိုေကာင္းတယ့္ Windows က virus/trojan ပိုထြက္တာေပါ့။
ဒါ ထင္သာ ျမင္သာ အခ်က္ေတြပါ။ ဒါထက္ပိုတာေတြ ရွိအုန္းမွာပါ။ Unix / Linux မွာ အရင္တုန္းက rootkit ဆိုတယ့္ အသုံးအႏွုန္းက ပိုေခတ္စားပါတယ္။ Trojan လို backdoor လို ေကာင္မ်ိဳးပါပဲ။ Backdoor ပိုဆန္မယ္ထင္တယ္။ Kernel module တစ္ခုအျဖစ္၊ device driver တစ္ခုအျဖစ္ ကိုယ့္ကိုကိုယ္ ဟန္ေဆာင္ျပီး Operation system တက္တိုင္း သူကပါလိုက္တက္လာမယ္၊ service တစ္ခု port တစ္ခု compromise ထားမယ္၊ attacker အတြက္ ဝင္လမ္း ထြက္လမ္းဖြင့္ေပးထားမယ္ေပါ့။ ဒါေပမယ့္ process list ထဲမွာေတာ့ မေပၚဘူး။ ဒါမ်ိဳးက တကယ္ intrude လုပ္ျပီးသြားမွ ေနာက္တစ္ခါ ျပန္ဝင္ရလြယ္ေအာင္ လုပ္တာမ်ိဳးပါ။ Virus / Trojan ဆိုတာမ်ိဳးထက္ advance ျဖစ္ပါတယ္။
ခုေတာ့ user information ခိုးတယ့္ trojan လိုေကာင္ေတြေတာင္ linux မွာ ေပါလာပါျပီ။ Ubuntu / debian package ျဖစ္တယ့္ deb file ေတြမွာ trojan ေလးေတြထဲ့ေပးတာတို႕၊ tarball မွာကို ပါလာတာတို႕ရွိလာပါျပီ။ Opensource မို႕လို႕ security fix ထြက္တာျမန္သလို ၊ opensource မို႕လို႕ trojan ေလးထဲ့ေပးလိုက္ဖို႕လည္း ပိုလြယ္ပါတယ္။ Deb တို႕ rpm တို႕ဆိုတာ လြယ္လြယ္ေျပာရင္ exe installer ေတြလိုပါပဲ။ Run လိုက္ရင္ ဘာေတြလုပ္မယ္၊ ဘယ္လမ္းေၾကာင္းေအာက္မွာ ဘာထားမယ္၊ ဘယ္ service ကို startup မွာတင္ run ေအာင္ service register မယ္၊ ဒါမ်ိဳးေတြပါပဲ။ ပံုမွန္ install လုပ္မယ့္ action ေလးအျပင္ trojan install ေလးပါထဲ့ေပးထားရင္ သိမွာမဟုတ္ပါဘူး။
Tarball source file ေတြဆိုလည္း ျပန္ျပင္ထားတယ့္ source file ေလးေတြထဲ့ေပးထား၊ user က compile ျပီး install လည္းလုပ္လိုက္ေရာ trojan ေလးပါဝင္။ ဒါလည္းျဖစ္တာပဲ။ ပံုမွန္ကေတာ့ ယံုၾကည္ရတယ့္ site က repository ကမဟုတ္ရင္ install မလုပ္ဖို႕ပဲရွိပါတယ္။ Security အတြက္ instller package က original အတိုင္းဟုတ္မဟုတ္ ၊ ေျပာင္းလည္းထားတာရွိမရွိ PGP တို႕ GPG တို႕လို hash matching / keys ေတြနဲ႕ ေပးေလ့ရွိပါတယ္။ ဒါကေတာ့ သုံးေနတယ့္သူေတြ သိမွာပါ။ GPG မကိုက္လို႕ ၊ ဒါမွမဟုတ္ official GPG မရွိလို႕ install လုပ္မွာ ေသခ်ာလား ဆိုတယ့္ confirmation မ်ိဳးေမးတာ Ubuntu မွာလည္း ရွိပါတယ္။ ဒါမ်ိဳးေလးေတြ နည္းနည္း ေတာ့ ဂ႐ုစိုက္ေပးရင္ ပိုေကာင္းပါမယ္။
AppArmor တို႕ SELinux တို႕လို႕ security layer မ်ိဳးထပ္သုံးရင္ေတာ့ ပိုေကာင္းပါတယ္။ ဘယ္ user ၊ ဘယ္ process က ၊ ဘယ္ folder ကိုပဲ access ရမယ္၊ ဘယ္လို action မ်ိဳးပဲရမယ္ ဆိုတာမ်ိဳးေတြက ပံုမွန္ Unix / Linux ရဲ့ native ACL ထက္ အမ်ားၾကီး ပိုျပည့္စံုပါတယ္။ ဒါေပမယ့္ အလုပ္ပိုလို႕ Fedora တို႕ ဘာတို႕မွာဆို ေတာ္ေတာ္မ်ားမ်ားက disable ျပီး သုံးၾကတယ္။ က်ေနာ္အပါအဝင္ပါ :D ။ သတိဆိုတာေတာ့ ပိုတယ္မရွိေပါ့ဗ်ာ။ ( သူမ်ားေတြအတြက္ေျပာတာပါ )
ခုတစ္ေလာ Unreal IRCD ရဲ့ news ကိုဖတ္မိလို႕ ဒီ post ေရးျဖစ္သြားတာ။ Unreal IRCD ဆိုတာ opensource IRC server patform တစ္ခုပါ။ IRCD ထဲမွာေတာ့ နာမည္ အရွိဆုံးပဲထင္တယ္။ သူတို႕ရဲ့ Official download mirror တစ္ခ်ိဳ႕က tarball ေတြကို တစ္ေယာက္ေယာက္က trojan ပါတယ့္ file ေတြနဲ႕ အစားထိုးသြားပါတယ္။ Compile / install လုပ္လိုက္ရင္ trojan ေလးပါ ပါလာမယ္။ ဒါေတာင္ official mirror ေတြ။ သူတို႕က GPG နဲ႕ေပးတာမ်ိဳးမဟုတ္ေတာ့ file ရဲ့ integrity check မပါဖူးေပါ့။ ျပင္ထားလည္း User ဘက္ကမသိႏိုင္ဖူး။
Linux မွာ virus ေတြ trojan ေတြရွိတယ္လို႕ လွန္႕တာမဟုတ္ပါဘူး။ Windows နဲ႕ယွဥ္ရင္ အေတာ္ကိုနည္းပါတယ္။ ရွိတာေတာ့ ရွိတာပါပဲ။ Linux က idiot proof OS တစ္ခုမဟုတ္ေၾကာင္းနဲ႕ 'ငါတို႕ကေတာ့ virus မေၾကာက္ရလို႕ Linux ပဲသုံးတယ္' လို႕ ျပဳံးျပဳံးၾကီး မေျပာမိေအာင္ သတိေပးတာပါ။ ကိုယ္ကိုတိုင္လည္း အမွားၾကီးကို မွတ္ထား၊ သူမ်ားေတြကိုလည္း အမွားေတြ ေလွ်ာက္ေျပာေနမိရင္ ဆက္ေလ့လာတယ့္ေနရာမွာ သိထားတယ့္ အေၾကာင္းအရာ အမွားၾကီးေတြက ကန္႕လန္႕ခံေနလို႕ ပိုျပီး ခက္ခဲေနမွာ ဆိုးလို႕ပါ။ Santa Clause တကယ္ရွိမရွိနဲ႕ ၊ Linux မွာ virus / trojan တကယ္ရွိမရွိက သူမ်ားေျပာတာထက္. . သုံးရင္း ၊ ေလ့လာရင္း ရွာေဖြေတြ႕ရွိပါလိမ့္မယ္။
Divinity
Linux က bullet proof operating system တစ္ခုမဟုတ္ပါဖူး။ Security ကို အဓိက ဦးစားေပးစဥ္းစားထားတယ့္ Unix ကို အေျခခံထားတာပဲရွိတယ္။ လူလုပ္တယ့္ ကိစၥ ဘယ္ေတာ့မွ perfect မျဖစ္ဖူး၊ စိတ္ပူမေနနဲ႕။ Windows နဲ႕ ယွဥ္လိုက္ရင္ Virus နည္းတယ္လို႕ပဲေျပာလို႕ရတယ္။ နည္းလြန္းလို႕ မရွိသလိုျဖစ္ေနတာပါ။ ဘာေၾကာင့္ နည္းတာလည္း ဆိုရင္ေတာ့ ဒါေတြေၾကာင့္လို႕ က်ေနာ္က ျမင္တယ္။
၁။ အသုံးျပဳမႈနည္းပါးျခင္း
Home user ေတြၾကားထဲမွာ Linux အသုံးျပဳသူက 2% ေလာက္ပဲရွိပါတယ္။ ဒီေလာက္ေလးနဲ႕ၾက virus/trojan ေရးတယ့္သူေတြကို မဆြဲေဆာင္ႏိုင္ပါဘူး။ ကိုယ္ေရးတယ့္ virus/trojan ျပန္႕ႏိုင္စြမ္းလည္း နည္းမယ္။ အလုပ္လည္းသိပ္မျဖစ္ဖူးေပါ့။ ဒါနဲ႕ပဲ Linux မွာ virus ေရးဖို႕ သိပ္စိတ္မဝင္စားၾကတာျဖစ္မယ္။ ေနာက္ေတာ့ ရွိလာၾကမွာပါ။
၂။ Advanced Users
လြန္ခဲ့တယ့္ သုံးႏွစ္ 2007 ေလာက္ကထိ Linux ကသုံးရတာမလြယ္ကူပါဘူး။ လြယ္လြယ္ကူကူ သုံးခ်င္သူေတြ၊ Computer အေၾကာင္း သိပ္မသိခ်င္ပါဖူး၊ သုံးလို႕ရျပီးတာပဲ ဆိုတယ့္ သူေတြရဲ့ choice မျဖစ္ခဲ့ပါဖူး။ Linux သုံးတယ့္ သူေတာ္ေတာ္မ်ားမ်ားက IT နယ္ပယ္ထဲကလူေတြ၊ IT ကို အနည္းနဲ႕ အမ်ား စိတ္ဝင္စားတယ့္ သူေတြ မ်ားပါတယ္။ ဒီ computer ေပၚမွာ သူတို႕ ဘာလုပ္ေနတယ္ဆိုတာကို ေသျခာသိတယ့္ သူေတြမို႕ ၊ security sense ရွိၾကပါတယ္။ ေတြ႕ကရာ ေလွ်ာက္ click ၊ install ဆိုျပီး လုပ္ၾကမယ့္ သူေတြမဟုတ္လို႕ ဒီလိုလူေတြကို target ထားတာထက္စာရင္ ၊ Pop-up ေတြ႕ရင္ ေကာက္ click လိုက္မယ့္ novice ေတြကို ပိုျပီး target ထားတာေကာင္းမွာေပါ့။ အဲလို novice ေတြက သုံးရတာပိုလြယ္ကူတယ့္ windows သုံးေလ့ရွိတယ္ေလ။ အဲလို user ေတြ Linux မ်ားမ်ားသုံးလာရင္ Linux လည္း target ေကာင္းတစ္ခုျဖစ္လာမွာပါ၊ စိတ္ဓာတ္မက်ပါနဲ႕။
၃။ Fix ေတြထြက္တာျမန္တယ္
Opensource မို႕လို႕ lib ေတြမွာ exploit ေတြ flaw ေတြရွိေနရင္ ရွာေဖြေတြ႕ရွိသူကတာ inform လုပ္၊ ေနာက္က fix လုပ္မယ့္ သူေတြက အမ်ားၾကီး။ ဒါေၾကာင့္ Linux ရဲ့ exploit ေတြက သိပ္ျပီး ၾကိဳးစားၾကည့္ခ်င္စရာ မေကာင္းဖူး။ ကိုယ္က ဒီေန႕ရွာေတြ႕ ေနာက္ေန႕ fix ထြက္ေနျပီ။ User ေတြ patch install လုပ္တာ မလုပ္တာ တစ္ပိုင္းေပါ့။ MS မွာေတာ့ Conficker တုန္းက exploit ရွာေတြ႕တာနဲ႕ fix က ႏွစ္လေလာက္ၾကာပါတယ္။ User က update မလုပ္မိတာေတြရွိလို႕ ဒီ exploit က တစ္ႏွစ္ေလာက္ ေကာင္းေကာင္း အလုပ္ျဖစ္ေနတာပဲ။ ဒီလိုေတြရွိေတာ့လည္း လုပ္စားရ ပိုေကာင္းတယ့္ Windows က virus/trojan ပိုထြက္တာေပါ့။
ဒါ ထင္သာ ျမင္သာ အခ်က္ေတြပါ။ ဒါထက္ပိုတာေတြ ရွိအုန္းမွာပါ။ Unix / Linux မွာ အရင္တုန္းက rootkit ဆိုတယ့္ အသုံးအႏွုန္းက ပိုေခတ္စားပါတယ္။ Trojan လို backdoor လို ေကာင္မ်ိဳးပါပဲ။ Backdoor ပိုဆန္မယ္ထင္တယ္။ Kernel module တစ္ခုအျဖစ္၊ device driver တစ္ခုအျဖစ္ ကိုယ့္ကိုကိုယ္ ဟန္ေဆာင္ျပီး Operation system တက္တိုင္း သူကပါလိုက္တက္လာမယ္၊ service တစ္ခု port တစ္ခု compromise ထားမယ္၊ attacker အတြက္ ဝင္လမ္း ထြက္လမ္းဖြင့္ေပးထားမယ္ေပါ့။ ဒါေပမယ့္ process list ထဲမွာေတာ့ မေပၚဘူး။ ဒါမ်ိဳးက တကယ္ intrude လုပ္ျပီးသြားမွ ေနာက္တစ္ခါ ျပန္ဝင္ရလြယ္ေအာင္ လုပ္တာမ်ိဳးပါ။ Virus / Trojan ဆိုတာမ်ိဳးထက္ advance ျဖစ္ပါတယ္။
ခုေတာ့ user information ခိုးတယ့္ trojan လိုေကာင္ေတြေတာင္ linux မွာ ေပါလာပါျပီ။ Ubuntu / debian package ျဖစ္တယ့္ deb file ေတြမွာ trojan ေလးေတြထဲ့ေပးတာတို႕၊ tarball မွာကို ပါလာတာတို႕ရွိလာပါျပီ။ Opensource မို႕လို႕ security fix ထြက္တာျမန္သလို ၊ opensource မို႕လို႕ trojan ေလးထဲ့ေပးလိုက္ဖို႕လည္း ပိုလြယ္ပါတယ္။ Deb တို႕ rpm တို႕ဆိုတာ လြယ္လြယ္ေျပာရင္ exe installer ေတြလိုပါပဲ။ Run လိုက္ရင္ ဘာေတြလုပ္မယ္၊ ဘယ္လမ္းေၾကာင္းေအာက္မွာ ဘာထားမယ္၊ ဘယ္ service ကို startup မွာတင္ run ေအာင္ service register မယ္၊ ဒါမ်ိဳးေတြပါပဲ။ ပံုမွန္ install လုပ္မယ့္ action ေလးအျပင္ trojan install ေလးပါထဲ့ေပးထားရင္ သိမွာမဟုတ္ပါဘူး။
Tarball source file ေတြဆိုလည္း ျပန္ျပင္ထားတယ့္ source file ေလးေတြထဲ့ေပးထား၊ user က compile ျပီး install လည္းလုပ္လိုက္ေရာ trojan ေလးပါဝင္။ ဒါလည္းျဖစ္တာပဲ။ ပံုမွန္ကေတာ့ ယံုၾကည္ရတယ့္ site က repository ကမဟုတ္ရင္ install မလုပ္ဖို႕ပဲရွိပါတယ္။ Security အတြက္ instller package က original အတိုင္းဟုတ္မဟုတ္ ၊ ေျပာင္းလည္းထားတာရွိမရွိ PGP တို႕ GPG တို႕လို hash matching / keys ေတြနဲ႕ ေပးေလ့ရွိပါတယ္။ ဒါကေတာ့ သုံးေနတယ့္သူေတြ သိမွာပါ။ GPG မကိုက္လို႕ ၊ ဒါမွမဟုတ္ official GPG မရွိလို႕ install လုပ္မွာ ေသခ်ာလား ဆိုတယ့္ confirmation မ်ိဳးေမးတာ Ubuntu မွာလည္း ရွိပါတယ္။ ဒါမ်ိဳးေလးေတြ နည္းနည္း ေတာ့ ဂ႐ုစိုက္ေပးရင္ ပိုေကာင္းပါမယ္။
AppArmor တို႕ SELinux တို႕လို႕ security layer မ်ိဳးထပ္သုံးရင္ေတာ့ ပိုေကာင္းပါတယ္။ ဘယ္ user ၊ ဘယ္ process က ၊ ဘယ္ folder ကိုပဲ access ရမယ္၊ ဘယ္လို action မ်ိဳးပဲရမယ္ ဆိုတာမ်ိဳးေတြက ပံုမွန္ Unix / Linux ရဲ့ native ACL ထက္ အမ်ားၾကီး ပိုျပည့္စံုပါတယ္။ ဒါေပမယ့္ အလုပ္ပိုလို႕ Fedora တို႕ ဘာတို႕မွာဆို ေတာ္ေတာ္မ်ားမ်ားက disable ျပီး သုံးၾကတယ္။ က်ေနာ္အပါအဝင္ပါ :D ။ သတိဆိုတာေတာ့ ပိုတယ္မရွိေပါ့ဗ်ာ။ ( သူမ်ားေတြအတြက္ေျပာတာပါ )
ခုတစ္ေလာ Unreal IRCD ရဲ့ news ကိုဖတ္မိလို႕ ဒီ post ေရးျဖစ္သြားတာ။ Unreal IRCD ဆိုတာ opensource IRC server patform တစ္ခုပါ။ IRCD ထဲမွာေတာ့ နာမည္ အရွိဆုံးပဲထင္တယ္။ သူတို႕ရဲ့ Official download mirror တစ္ခ်ိဳ႕က tarball ေတြကို တစ္ေယာက္ေယာက္က trojan ပါတယ့္ file ေတြနဲ႕ အစားထိုးသြားပါတယ္။ Compile / install လုပ္လိုက္ရင္ trojan ေလးပါ ပါလာမယ္။ ဒါေတာင္ official mirror ေတြ။ သူတို႕က GPG နဲ႕ေပးတာမ်ိဳးမဟုတ္ေတာ့ file ရဲ့ integrity check မပါဖူးေပါ့။ ျပင္ထားလည္း User ဘက္ကမသိႏိုင္ဖူး။
Linux မွာ virus ေတြ trojan ေတြရွိတယ္လို႕ လွန္႕တာမဟုတ္ပါဘူး။ Windows နဲ႕ယွဥ္ရင္ အေတာ္ကိုနည္းပါတယ္။ ရွိတာေတာ့ ရွိတာပါပဲ။ Linux က idiot proof OS တစ္ခုမဟုတ္ေၾကာင္းနဲ႕ 'ငါတို႕ကေတာ့ virus မေၾကာက္ရလို႕ Linux ပဲသုံးတယ္' လို႕ ျပဳံးျပဳံးၾကီး မေျပာမိေအာင္ သတိေပးတာပါ။ ကိုယ္ကိုတိုင္လည္း အမွားၾကီးကို မွတ္ထား၊ သူမ်ားေတြကိုလည္း အမွားေတြ ေလွ်ာက္ေျပာေနမိရင္ ဆက္ေလ့လာတယ့္ေနရာမွာ သိထားတယ့္ အေၾကာင္းအရာ အမွားၾကီးေတြက ကန္႕လန္႕ခံေနလို႕ ပိုျပီး ခက္ခဲေနမွာ ဆိုးလို႕ပါ။ Santa Clause တကယ္ရွိမရွိနဲ႕ ၊ Linux မွာ virus / trojan တကယ္ရွိမရွိက သူမ်ားေျပာတာထက္. . သုံးရင္း ၊ ေလ့လာရင္း ရွာေဖြေတြ႕ရွိပါလိမ့္မယ္။
Divinity
Subscribe to:
Posts (Atom)