Unwanted Emails

Unwanted Emails

ျဖစ္ေလ႔ျဖစ္ထရိွတဲ႔ျပႆနာတစ္ခုပါ။
testing လုပ္ရင္း users အစစ္ေတြဆီကို test enviornment ကေန mails ေတြပို႕မိတဲ႔ျပႆနာပါ။
 development လုပ္တာျဖစ္ျဖစ္၊ maintenance လုပ္တာျဖစ္ျဖစ္ ၃ ႏွစ္နဲ႕ ငါးႏွစ္ၾကားေလာက္ၾကာရင္ ဒီလိုျပႆနာအနည္းဆံုးတစ္ခါေလာက္ေတာ႔ ၾကံဳဖူးတတ္တယ္။

ဘယ္လိုေရွာင္သင္႔သလဲဆိုတာကေတာ႔ နည္းေတြ အမ်ားၾကီးရိွပါတယ္။ အဲဒီအထဲက က်ေနာ္သေဘာက်တဲ႔နည္းတစ္ခ်ိဳ႕ကို နည္းနည္းေဝငွခ်င္ပါတယ္။

Rule1.
production ကေန ေဒတာကို ယူတုိင္း mask လုပ္သင္႔တာေတြကို တစ္ခါတည္း mask လုပ္ျပီးမွ extract လုပ္ပါ။

Name, NRIC, email စတာေတြက confidential ေတြပါ။ ျဖစ္ႏုိင္ရင္ production data ကို functional test လုပ္ဖုိ႕မသံုးတာအေကာင္းဆံုးပဲ။

Rule2.
Switch off Email function

စမ္းခ်င္တာက အီးေမးလ္ပို႕၊မပို႕စမ္းတာမဟုတ္ရင္ အီးေမးလ္ပို႕တဲ႔ function ကို off လုပ္ထားပါ။ ျဖစ္တတ္တာတစ္ခုက စုတ္စုတ္ျပတ္ျပတ္ coding ေတြမွာ ေနရာတကာက အီးေမးလ္ပို႕ေနတတ္တာပါပဲ။ ေသခ်ာလုိက္ရွာျပီး၊ တစ္ခုမက်န္ပိတ္ထားပါ။ ဒါမွမဟုတ္ configuration တစ္ဆင္႔ခံထားျပီး UAT environment ဆိုရင္ auto off ေနေအာင္လုပ္ထားပါ။

မလုိလားအပ္တဲ႔ အီးေမးလ္ကို မပို႕သင္႔တဲ႔ေနရာပို႕မိရင္ ျပႆနာက အက်ယ္အက်ယ္မျငိမ္းဖြယ္ျဖစ္ႏုိင္တယ္ဆိုတာကို သတိထားပါ။ ကိုယ္႔ဖက္က မမွားသင္႔တာမမွားေအာင္ဂရုစိုက္တာအေကာင္းဆံုးပဲ။

Rule3.
Check scheduler for sending out email

Reminder email ေတြကို scheduler နဲ႕ run ေလ႔ရိွပါတယ္။ တတိယေျမာက္အလုပ္မွာ ေရွ႕ကတစ္ေယာက္ထြက္သြားေတာ႔ testing ဝင္လုပ္ရင္း sheduler testing မွာ အဲဒီျပႆနာၾကံဳလုိက္ရပါတယ္။ တစ္ပတ္ကို တစ္ေစာင္ေလာက္ သူ႕ဖာသာသူပို႕ေနတာ။ ေနာက္ေတာ႔မွ တရားခံကိုေတြ႕တယ္။ ေရွ႕လူက ဘာမွမေျပာသြားရင္ အဲဒါေတြသိဖုိ႕မလြယ္ဘူး။ test data ေတြကို production က ကူးထားတာလားကအစ ေသခ်ာေအာင္ေမးထားဖုိ႕လုိတယ္။

တစ္ခါတစ္ေလ ၾကားျဖတ္ျပီး တာဝန္ယူရတဲ႔အခါေတြမွာ ကိုယ္မသိႏုိင္တာေတြ အမ်ားၾကီးရိွမယ္။ အဲဒီလိုဆုိရင္ အလြယ္တကူ assume မလုပ္ပါနဲ႕။ ေသခ်ာေအာင္စစ္ျပီးမွ confirm လုပ္ပါ။

ျပႆနာက ႏွစ္ပိုင္းကြဲေနတာကို သတိျပဳမိမလားမသိဘူး။ တစ္ခုက ကိုယ္တုိင္ အစအဆံုးသိေနတာမ်ိဳး။ အဲဒါမ်ိဳးက သိပ္ျပႆနာမတက္ဘူး။ ေနာက္တစ္ခုက ကိုယ္က အသစ္ဝင္တုန္း၊ ေရွ႕ကဘယ္လိုလုပ္သြားမွန္းမသိတာမ်ိဳးက ပိုအႏၱရာယ္မ်ားတယ္။ အဲဒါကို ေသခ်ာ ဂရုတစုိက္လုပ္ဖုိ႕လိုပါတယ္။

testing အတြက္ Environment ကို သီးသန္႕ျပင္ဆင္ျပီး၊ test data ကိုလည္း ကိုယ္စမ္းခ်င္တဲ႔ fuction အတုိင္း လုိသေလာက္ျပင္ဆင္ထားရင္ ေတာ္ေတာ္ေလး စိတ္ခ်ရပါျပီ။ အဲဒီအျပင္ email ကို config လုပ္တဲ႔အက်င္႔ထားျပီး၊ Environment အလုိက္ သံုးရမယ္႔အီးေမးလ္၊ပို႕ရမယ္႔ အီးေမးလ္ တစ္ခါတည္း pre-defined လုပ္ထားလုိက္ရင္ ေနာင္လားေနာက္သားေတြလည္းအဆင္ေျပတာေပါ႔ခင္ဗ်ာ။

ANT build ေတြကိုလည္း တစ္ခါတည္း UAT,QA,PROD ခြဲထားလုိက္ျပီး၊ build လုပ္တာနဲ႕ အီးေမးလ္ဆက္တင္ေတြ ကိုယ္လုိသလိုအလုပ္လုပ္ေအာင္ ျပင္ဆင္ထားရင္လည္း သင္႔တာပါပဲ။

ဒါက နည္းပညာအခက္အခဲေတာ႔ မဟုတ္ပါဘူး။ အလုပ္ထဲမွာ ၾကံဳရတတ္တာတစ္ခုကို သတိထားႏုိင္ဖုိ႕ေရးလုိက္တာပါ။ သတိထားႏုိင္ရင္ အမွားနည္းတာပါပဲ။


Regards,
Zero

Why CentOS ?

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)

ဪ 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

Extract Package in Oracle DB

Extract Package in Oracle DB

=========================================================================METHOD 1

=========================================================================

SET LINESIZE 29999;

SET TERM OFF;

SET PAGESIZE 100000;

SET LONG 10000000;

SPOOL TEST_PACKAGE.TXT;

SELECT dbms_metadata.get_ddl( 'PACKAGE', 'TEST_PACKAGE', 'ILTCIS') FROM dual;

SPOOL OFF;

===========================================================================

METHOD 2

===========================================================================

SET LINESIZE 29999;

SET TERM OFF;

SET PAGESIZE 999;

SPOOL TEST_PACKAGE_1.txt

select TEXT from user_source where name='TEST_PACKAGE' and type='PACKAGE BODY';

=========================================================================

တစ္ခါတစ္ေလ လိုအပ္တတ္ပါတယ္။ package ကူးထားခ်င္တဲ႔အခါမွာအသံုးဝင္ပါလိမ္႔မယ္။

Hackpad သံုးၾကပါ။

Hackpad သံုးၾကပါ။

https://hackpad.com/

အသံုးဝင္၊လြယ္ကူ၊ျမန္ဆန္ေသာ hackpad။

Oracle 11g R2 RAC Essentials SLA for availability

ဒါကို တင္ရတာအေၾကာင္းရိွပါတယ္။ Blog တစ္ခုမွာ စလံုးတစ္ေယာက္က  Oracle 11g R2 RAC Essentials စာအုပ္ထဲကဟာကို သူေရးသလိုလိုတင္ထားတာေတြ႕တာနဲ႕ စာအုပ္ထဲကပံုကို screen capture လုပ္ျပီးတင္ထားတာျဖစ္ပါတယ္။

Some useful software

Some useful software

First of all, sorry for writing in English since my office PC doesn't have Myanmar keyboard.

1.cavaj
which is a java decompiler. Useful and elegant when you need to decompile your source code (class files)

2.fiddler
it is good for web developer to keep track of the server response such as json strings, server's status response. It is a must for web developer these days.

3..Net Reflector
In one of my projects, I had to use a third party DLL. No source code. I used it to decompile it. It is not free. For me, it is good enough.

Regards,
Zero