Online မွာေလ႔လာတဲ႔အခါ အခ်ိန္နဲ႕ ေငြေၾကးလုိပါတယ္။
ေငြေၾကးထက္ အေရးၾကီးတာ အခ်ိန္ပါ။ အခ်ိန္မရိွရင္ မေလ႔လာႏုုိင္ပါဘူး။ အခ်ိန္ေရာေငြေၾကးပါ ျပည္႕စံုရင္ သင္ယူမႈဟာ ျမန္ဆန္ပါတယ္။
Java သမားေတြအတြက္ဆုုိရင္လည္း အေျခခံက အစ သင္ေပးတဲ႔ course ေလးေတြရိွပါတယ္။ ဥပမာအားျဖင္႔ udemy မွာ Eclipse ကုိ ဘယ္လုိ install လုပ္တယ္ကအစ၊ အသံုုးဝင္တဲ႔ ၊ သိသင္႔သိထုိက္တဲ႔ အခ်က္ေလးေတြေျပာျပေပးတဲ႔ course ဆုိရင္ တစ္နာရီဝန္းက်င္ေလာက္ပဲ။ အလကားသင္ႏုိင္တယ္။
https://www.udemy.com/luv2code-eclipse-ide-for-beginners/learn/#/lecture/1979654
တစ္ခ်ိဳ႕ကုုိယ္သိခ်င္တာေလးေတြရိွရင္ course တစ္ခုု သံုုးေလးဆယ္နဲ႕ ေလးနာရီ၊ငါးနာရီေလာက္ ေလ႔လာလုိက္ရင္ အဆင္ေျပသြားႏုိင္တယ္။ ဥပမာ Node JS သင္ခန္းစာမ်ိဳး။ Amazon Web Service Certificate အတြက္သင္တန္းဆုိရင္ ၄၇ ေဒၚလာေလာက္ပဲ။
Chess ထုိးတဲ႔သင္ခန္းစာေတြလည္းရိွတယ္။ ဓာတ္ပံုုပညာအတြက္လည္း သင္ခန္းစာအတုိေလးေတြရိွတယ္။
Coursera မွာ ဆုိရင္လည္း အလကားသင္လုိ႕ရတာအမ်ားၾကီးရိွတယ္။ Computer နဲ႕ပတ္သက္တာေတြလည္းရိွသလို၊ စီးပြားေရးနဲ႕ပတ္သက္တာေတြလည္းရိွတယ္။ ကမာၻ႕အဆင္႔မီ တကၠသုိလ္ေတြက ပါေမာကၡေတြ၊ ကထိကေတြသင္တာဆုိေတာ႔ ေျပာစရာမလုိေအာင္ေကာင္းတယ္။ အဆင္႔အတန္းျမင္႔တဲ႔ ပညာေတြကုုိ အလကားသင္ယူႏုုိင္တာဟာ မဂၤလာတစ္ပါးပါ။
တစ္သက္တာ ပညာသင္ယူမႈကုုိ လက္မေလွ်ာ႔သူေတြ ျဖစ္ႏိုိင္ၾကပါေစ။
စာမေရးတာ အခ်ိန္ေတာ္ေတာ္ၾကာသြားျပီ။ ဒီလထဲမွာေတာ႔ ျပန္အားလာတာနဲ႕ နည္းနည္းစေရးလုုိက္ပါတယ္။ ေရးစရာေတြ အမ်ားၾကီးရိွေနပါေသးတယ္။ ေလာေလာဆယ္ဖတ္ျဖစ္တဲ႔ ITIL foundation နည္းနည္းေလာက္ေရးဦးမယ္။
Regards,
0/0
Saturday, January 2, 2016
Wednesday, April 9, 2014
WebLogic Clustered Env:
WebLogic Clustered Env:
Corporate ေတြရဲ႕ web application ေတာ္ေတာ္မ်ားမ်ားဟာ Clustered Environment မွာထားၾကတယ္။
Clustering အေၾကာင္းေျပာေနရင္ ရွည္လ်ားေထြျပားကုန္မယ္။ အၾကမ္းဖ်င္းကေတာ႔ Availability ျမင္႔ေအာင္ၾကပါတာပါ။ Weblogic မွာေတာ႔ Managed Server အေနနဲ႕လုပ္ၾကပါတယ္။ App1 ကို အရင္စ။ cluster ထဲသြင္းထား။ ေနာက္ထပ္ App2 ကုိစ Cluster ထဲသြင္း။ cluster နဲ႕မွန္မွန္ကန္ကန္ေလးတက္လာတဲ႔ server ေတြမွာဆို
အဲဒီ BEA 000102 ေလးေတြ႕ရလိမ္႔မယ္။ အဲဒီ IP နဲ႕ Port ေနာက္မွာ Clusters 2 ခုရိွတယ္ေပါ႔။ App1 နဲ႕ App2 ကို Node ေတြလုိ႕လည္းေခၚတယ္။ ဒါက အလြယ္ဆံုး ဥပမာေျပာတာ။
မ်ားေသာအားျဖင္႔ေတာ႔ Load Balancer Hardware/software/Plug-in တစ္ခုခု ေရွ႕နားကေန ခံထားေလ႔ရိွတယ္။ အဲဒါမွမဟုတ္ရင္လည္း အလကားလုပ္ထားသလိုျဖစ္ကုန္မွာကိုး။
ၾကံဳေလ႔ၾကံဳထရိွတဲ႔ ျပႆနာသံုးေလးခုအေၾကာင္းေျပာၾကရေအာင္။ ပထမဆံုးက cluster လုပ္ထားရင္ session ကို share ရမယ္။ မဟုတ္ရင္ ပထမ request က App1 ေၾကာင္႔၊ ဒုတိယ request က App2 ေရာက္ေတြျဖစ္ကုန္ရင္ Session Timeout ေတြျဖစ္ေစႏုိင္တယ္။
Load Balancer က App ကို တုိက္ရုိက္လႊဲလိုက္တာေတာ႔မဟုတ္ဘူး။ App ေတြရဲ႕ အေပၚမွာ Web ရိွဦးမယ္။ Balancer က Web ရဲ႕ အေပၚမွာရိွရမယ္။ အဲဒီလုိထားၾကတယ္။
ဒုတိယတစ္ခု သတိထားရမွာက session ကို share ပါျပီတဲ႔။ session ထဲကို ထည္႕လုိက္တဲ႔ bean ေတြက serializable ျဖစ္ရမယ္။ အဲဒါမွမဟုတ္ရင္ အဆင္မေျပဘူး။ Clustered Env မွာ Serialized မလုပ္ထားတဲ႔ object ေတြ ဒြတ္ခေရာက္ကုန္မယ္။ Good Practice ကေတာ႔ Object မွန္သမွ် Base object တစ္ခုကို extends လုပ္ခိုင္းထားျပီး၊ အဲဒီ base Object ကို serializable interface implements လုပ္လုိက္ရင္ ေနာက္လာေနာက္သားေတြ စိတ္ေအးရတယ္။
ေနာက္တစ္ခုကေတာ႔ ဂြစာေတြ။ third party plug-in ေတြက တစ္ခ်က္တစ္ခ်က္ serialized လုပ္လုိ႕မရတာရိွတယ္။ အဲဒီ lib ေတြပါလာရင္ ေစာေစာစီးစီး ေျပာင္းသံုးလုိ႕ရတုန္း ေျပာင္းသံုးထားလုိက္။မဟုတ္ရင္ ေနာက္မွာ ဒုကၡေသခ်ာေပါက္ေပးလိမ္႔မယ္။
အခုလက္ရိွလုပ္ေနတဲ႔ project အေဟာင္းတစ္ခုမွာ user ကို active ျဖစ္ေနလား၊ မျဖစ္ေနလားကို log-in လုပ္ကတည္းက user ID နဲ႕ session ID ကို persist လုပ္ထားလုိက္ျပီး၊ ျပန္ျပန္စစ္တာမ်ိဳး။ ဆာဗာတစ္လံုးထဲဆိုရင္ ဘာမွမျဖစ္ဘူး။ Load Balancer ကို sticky session လုပ္ထားရင္လည္း အဆင္ေျပတယ္။(သို႕ေသာ္ မေကာင္းဘူး။ std: အရလည္း မလုပ္သင္႔တာေတြရိွတယ္။) session ID ကို ျပန္သံုးတဲ႔အခါမွာ session.getSessionID() method နဲ႕သံုးထားတာေတြ႕တယ္။ အဲဒီမွာ ျပႆနာအၾကီးၾကီးရိွတယ္။ cluster ေတြမွာ session ထဲမွာ သိမ္းထားတဲ႔ Java Object ေတြကို replicate လုပ္တာမွန္ေပမယ္႔၊ session ID ႏွစ္ခုဟာ somehow identical ျဖစ္မေနတာေတြ႕တယ္။ အဲဒီမွာ logical error ျဖစ္ကုန္ျပီး၊ users မွန္သမွ် session timeout ၾကေလသတည္းျဖစ္ကုန္တယ္။ အရင္က အလုပ္မလုပ္တဲ႔ load balancer က သူ႕ဟာသူ ၂ ႏွစ္ေလာက္ပ်က္ေနတုန္းက အေကာင္းပဲ။ သူအလုပ္စလုပ္တာနဲ႕ အဲဒီျပႆနာေပၚလာတယ္။ ေနာက္ေတာ႔ session ID ကို user Obj ထဲေပါင္းထည္႕ထားျပီး အဲဒီ user Obj ကို session ထဲျပန္ထည္႕ထားလုိက္မွေအးသြားတယ္။ Obj ေတြက cluster မွာ replicate-if-cluster ဆိုတဲ႔ parameter on ထားလုိက္ရင္ အဆင္ေျပတယ္။ weblogic.xml မွာျပင္ရတယ္။
အခုကိစၥေတြဟာ ဖတ္ထားရင္ လြယ္လြယ္သိတယ္။ ကုိယ္တုိင္ၾကံဳမွဆုိရင္ ရြာလည္တတ္တယ္။ အထူးသျဖင္႔ Production Environment လိုမ်ိဳး Clustered Env မရိွရင္သာေတာင္ခက္တယ္။ အဲဒီ Setup Local မွာလုပ္တာကိုေတာ႔ ေနာက္ထပ္ post တစ္ခုမွာ ေရးလုိက္ပါဦးမယ္။
Regards,
Zero
Ref:http://docs.oracle.com/cd/E13222_01/wls/docs103/webapp/weblogic_xml.html#wp1071982
Corporate ေတြရဲ႕ web application ေတာ္ေတာ္မ်ားမ်ားဟာ Clustered Environment မွာထားၾကတယ္။
Clustering အေၾကာင္းေျပာေနရင္ ရွည္လ်ားေထြျပားကုန္မယ္။ အၾကမ္းဖ်င္းကေတာ႔ Availability ျမင္႔ေအာင္ၾကပါတာပါ။ Weblogic မွာေတာ႔ Managed Server အေနနဲ႕လုပ္ၾကပါတယ္။ App1 ကို အရင္စ။ cluster ထဲသြင္းထား။ ေနာက္ထပ္ App2 ကုိစ Cluster ထဲသြင္း။ cluster နဲ႕မွန္မွန္ကန္ကန္ေလးတက္လာတဲ႔ server ေတြမွာဆို
အဲဒီ BEA 000102 ေလးေတြ႕ရလိမ္႔မယ္။ အဲဒီ IP နဲ႕ Port ေနာက္မွာ Clusters 2 ခုရိွတယ္ေပါ႔။ App1 နဲ႕ App2 ကို Node ေတြလုိ႕လည္းေခၚတယ္။ ဒါက အလြယ္ဆံုး ဥပမာေျပာတာ။
မ်ားေသာအားျဖင္႔ေတာ႔ Load Balancer Hardware/software/Plug-in တစ္ခုခု ေရွ႕နားကေန ခံထားေလ႔ရိွတယ္။ အဲဒါမွမဟုတ္ရင္လည္း အလကားလုပ္ထားသလိုျဖစ္ကုန္မွာကိုး။
ၾကံဳေလ႔ၾကံဳထရိွတဲ႔ ျပႆနာသံုးေလးခုအေၾကာင္းေျပာၾကရေအာင္။ ပထမဆံုးက cluster လုပ္ထားရင္ session ကို share ရမယ္။ မဟုတ္ရင္ ပထမ request က App1 ေၾကာင္႔၊ ဒုတိယ request က App2 ေရာက္ေတြျဖစ္ကုန္ရင္ Session Timeout ေတြျဖစ္ေစႏုိင္တယ္။
Load Balancer က App ကို တုိက္ရုိက္လႊဲလိုက္တာေတာ႔မဟုတ္ဘူး။ App ေတြရဲ႕ အေပၚမွာ Web ရိွဦးမယ္။ Balancer က Web ရဲ႕ အေပၚမွာရိွရမယ္။ အဲဒီလုိထားၾကတယ္။
ဒုတိယတစ္ခု သတိထားရမွာက session ကို share ပါျပီတဲ႔။ session ထဲကို ထည္႕လုိက္တဲ႔ bean ေတြက serializable ျဖစ္ရမယ္။ အဲဒါမွမဟုတ္ရင္ အဆင္မေျပဘူး။ Clustered Env မွာ Serialized မလုပ္ထားတဲ႔ object ေတြ ဒြတ္ခေရာက္ကုန္မယ္။ Good Practice ကေတာ႔ Object မွန္သမွ် Base object တစ္ခုကို extends လုပ္ခိုင္းထားျပီး၊ အဲဒီ base Object ကို serializable interface implements လုပ္လုိက္ရင္ ေနာက္လာေနာက္သားေတြ စိတ္ေအးရတယ္။
ေနာက္တစ္ခုကေတာ႔ ဂြစာေတြ။ third party plug-in ေတြက တစ္ခ်က္တစ္ခ်က္ serialized လုပ္လုိ႕မရတာရိွတယ္။ အဲဒီ lib ေတြပါလာရင္ ေစာေစာစီးစီး ေျပာင္းသံုးလုိ႕ရတုန္း ေျပာင္းသံုးထားလုိက္။မဟုတ္ရင္ ေနာက္မွာ ဒုကၡေသခ်ာေပါက္ေပးလိမ္႔မယ္။
အခုလက္ရိွလုပ္ေနတဲ႔ project အေဟာင္းတစ္ခုမွာ user ကို active ျဖစ္ေနလား၊ မျဖစ္ေနလားကို log-in လုပ္ကတည္းက user ID နဲ႕ session ID ကို persist လုပ္ထားလုိက္ျပီး၊ ျပန္ျပန္စစ္တာမ်ိဳး။ ဆာဗာတစ္လံုးထဲဆိုရင္ ဘာမွမျဖစ္ဘူး။ Load Balancer ကို sticky session လုပ္ထားရင္လည္း အဆင္ေျပတယ္။(သို႕ေသာ္ မေကာင္းဘူး။ std: အရလည္း မလုပ္သင္႔တာေတြရိွတယ္။) session ID ကို ျပန္သံုးတဲ႔အခါမွာ session.getSessionID() method နဲ႕သံုးထားတာေတြ႕တယ္။ အဲဒီမွာ ျပႆနာအၾကီးၾကီးရိွတယ္။ cluster ေတြမွာ session ထဲမွာ သိမ္းထားတဲ႔ Java Object ေတြကို replicate လုပ္တာမွန္ေပမယ္႔၊ session ID ႏွစ္ခုဟာ somehow identical ျဖစ္မေနတာေတြ႕တယ္။ အဲဒီမွာ logical error ျဖစ္ကုန္ျပီး၊ users မွန္သမွ် session timeout ၾကေလသတည္းျဖစ္ကုန္တယ္။ အရင္က အလုပ္မလုပ္တဲ႔ load balancer က သူ႕ဟာသူ ၂ ႏွစ္ေလာက္ပ်က္ေနတုန္းက အေကာင္းပဲ။ သူအလုပ္စလုပ္တာနဲ႕ အဲဒီျပႆနာေပၚလာတယ္။ ေနာက္ေတာ႔ session ID ကို user Obj ထဲေပါင္းထည္႕ထားျပီး အဲဒီ user Obj ကို session ထဲျပန္ထည္႕ထားလုိက္မွေအးသြားတယ္။ Obj ေတြက cluster မွာ replicate-if-cluster ဆိုတဲ႔ parameter on ထားလုိက္ရင္ အဆင္ေျပတယ္။ weblogic.xml မွာျပင္ရတယ္။
အခုကိစၥေတြဟာ ဖတ္ထားရင္ လြယ္လြယ္သိတယ္။ ကုိယ္တုိင္ၾကံဳမွဆုိရင္ ရြာလည္တတ္တယ္။ အထူးသျဖင္႔ Production Environment လိုမ်ိဳး Clustered Env မရိွရင္သာေတာင္ခက္တယ္။ အဲဒီ Setup Local မွာလုပ္တာကိုေတာ႔ ေနာက္ထပ္ post တစ္ခုမွာ ေရးလုိက္ပါဦးမယ္။
Regards,
Zero
Ref:http://docs.oracle.com/cd/E13222_01/wls/docs103/webapp/weblogic_xml.html#wp1071982
Thursday, March 20, 2014
SQLPLUS Notes
SQLPLUS Notes
1.Spool file ထုတ္တဲ႔အခါမွာ ေနာက္မွာ space ေတြ အရွည္ၾကီးပါေနတတ္တယ္။
အဲဒီလိုပါေနရင္ ဖုိင္ size ဟာ မလုိအပ္ဘဲသိပ္ရွည္လာတယ္။ အဲဒါဆိုရင္ Trimspool ကို On လုိက္ရင္ ျငိမ္းပါတယ္။ မဟုတ္ရင္ေတာ႔ ဖြင္႔မရေအာင္ၾကီးတဲ႔ဖုိင္ေတြျဖစ္လာမယ္။ procedure ေတြcompare လုပ္တဲ႔အခါ file size သိပ္ၾကီးေနတာဟာ အာရံုေနာက္တယ္။
Set Trimspool on ၾကပါ။
2. Database က Date Format က Oracle မွာ ပံုမွန္အားျဖင္႔ DD-MON-RR ပံုစံျပတယ္။ ကိုယ္႔စိတ္ၾကိဳက္ေျပာင္းခ်င္ရင္ to_char(sample_date,'DD-MON-YYYY') ဆိုျပီး တစ္ခုစီလုိက္ေျပာင္းေနရတာ အာရံုေနာက္တယ္။ column အခု တစ္ရာေလာက္ေျပာင္းရရင္ စိတ္ညစ္စရာၾကီး။ အဲဒါမ်ိဳးျဖစ္ရင္ Spool file ထုတ္တဲ႔အခါမွာ
ALTER SESSION SET nls_date_format = 'DD-MON-YYYY'; လုပ္ထားလုိက္လုိ႕ရပါတယ္။
အဲဒါက session မွာ သူ႕ default ရိွေနတဲ႔ nls_date_format ကို ကိုယ္႔စိတ္ၾကိဳက္ change လို႕ရသြားေစပါလိမ္႔မယ္။
3.Requirement တစ္ခုက ေတာ္ေတာ္ရယ္စရာေကာင္းတယ္။ Spool file ထုတ္တဲ႔အခါမွာ Column name က repetitive ျဖစ္ပါတယ္။ အဲဒါကိုေဖ်ာက္ခ်င္တာပါ။ Linesize ကလည္း ၅ေသာင္းလား၊ ၆ေသာင္းလားအထိပဲရပါတယ္။ အဲဒါေက်ာ္သြားရင္ အလုပ္မလုပ္ေတာ႔ဘူး။ Production မွာရိွတဲ႔ records က သိန္းနဲ႕၊သန္းနဲ႕ျဖစ္ေနတာဆိုေတာ႔ column name repetitive မျဖစ္ေအာင္ Line Size ကို 0 ထားျပီး Column Name ကို Prompt နဲ႕ ကိုယ္႔ဟာကိုယ္ ေရးလုိက္ရပါတယ္။ Forum ေတြဖတ္ၾကည္႕ရင္ အဲဒီလို ကိစၥေတြလူမ်ားေတြ ေတြ႕ျပီးသားျဖစ္ေနတာဖတ္ရပါတယ္။ ကိုယ္တုိင္ၾကံဳေတာ႔လည္း အသံုးဝင္သြားတာပါပဲ။
ႊRegards,
Zero
1.Spool file ထုတ္တဲ႔အခါမွာ ေနာက္မွာ space ေတြ အရွည္ၾကီးပါေနတတ္တယ္။
အဲဒီလိုပါေနရင္ ဖုိင္ size ဟာ မလုိအပ္ဘဲသိပ္ရွည္လာတယ္။ အဲဒါဆိုရင္ Trimspool ကို On လုိက္ရင္ ျငိမ္းပါတယ္။ မဟုတ္ရင္ေတာ႔ ဖြင္႔မရေအာင္ၾကီးတဲ႔ဖုိင္ေတြျဖစ္လာမယ္။ procedure ေတြcompare လုပ္တဲ႔အခါ file size သိပ္ၾကီးေနတာဟာ အာရံုေနာက္တယ္။
Set Trimspool on ၾကပါ။
2. Database က Date Format က Oracle မွာ ပံုမွန္အားျဖင္႔ DD-MON-RR ပံုစံျပတယ္။ ကိုယ္႔စိတ္ၾကိဳက္ေျပာင္းခ်င္ရင္ to_char(sample_date,'DD-MON-YYYY') ဆိုျပီး တစ္ခုစီလုိက္ေျပာင္းေနရတာ အာရံုေနာက္တယ္။ column အခု တစ္ရာေလာက္ေျပာင္းရရင္ စိတ္ညစ္စရာၾကီး။ အဲဒါမ်ိဳးျဖစ္ရင္ Spool file ထုတ္တဲ႔အခါမွာ
ALTER SESSION SET nls_date_format = 'DD-MON-YYYY'; လုပ္ထားလုိက္လုိ႕ရပါတယ္။
အဲဒါက session မွာ သူ႕ default ရိွေနတဲ႔ nls_date_format ကို ကိုယ္႔စိတ္ၾကိဳက္ change လို႕ရသြားေစပါလိမ္႔မယ္။
3.Requirement တစ္ခုက ေတာ္ေတာ္ရယ္စရာေကာင္းတယ္။ Spool file ထုတ္တဲ႔အခါမွာ Column name က repetitive ျဖစ္ပါတယ္။ အဲဒါကိုေဖ်ာက္ခ်င္တာပါ။ Linesize ကလည္း ၅ေသာင္းလား၊ ၆ေသာင္းလားအထိပဲရပါတယ္။ အဲဒါေက်ာ္သြားရင္ အလုပ္မလုပ္ေတာ႔ဘူး။ Production မွာရိွတဲ႔ records က သိန္းနဲ႕၊သန္းနဲ႕ျဖစ္ေနတာဆိုေတာ႔ column name repetitive မျဖစ္ေအာင္ Line Size ကို 0 ထားျပီး Column Name ကို Prompt နဲ႕ ကိုယ္႔ဟာကိုယ္ ေရးလုိက္ရပါတယ္။ Forum ေတြဖတ္ၾကည္႕ရင္ အဲဒီလို ကိစၥေတြလူမ်ားေတြ ေတြ႕ျပီးသားျဖစ္ေနတာဖတ္ရပါတယ္။ ကိုယ္တုိင္ၾကံဳေတာ႔လည္း အသံုးဝင္သြားတာပါပဲ။
ႊRegards,
Zero
Thursday, October 31, 2013
စင္ကာပူအစိုးရ၊ အေနာနမတ္စ္နဲ႕ ဆကယူရထီ
စင္ကာပူအစိုးရ၊ အေနာနမတ္စ္နဲ႕ ဆကယူရထီ
ဘာမဆိုျဖစ္ႏုိင္တယ္။
software ဆိုတာေတြက ေလေပၚမွာ စိတ္ခ်ရေတာ႔တာမဟုတ္တာၾကာျပီ။ အလြယ္ေျပာရရင္ေတာ႔ အခ်င္းခ်င္းနားနားကပ္ေျပာတာကို အနားက တစ္ေယာက္က ၾကားရသလုိမ်ိဳး၊ သူတုိ႕ဟာသူတို႕ အထာနဲ႕ေျပာလုိ႕ (encrypted) ျဖစ္ေနလို႕ ခ်က္ခ်င္းသေဘာမေပါက္တာသာရိွတယ္။ အဲဒီအထာစကားကို နားလည္တဲ႔သူကို ၾကားခဲ႔တဲ႔စကားကို ျပန္ဖြင္႔ျပႏိုင္ရင္ နားလည္သြားႏုိင္တာနဲ႕ဆင္တယ္။
စင္ကာပူအစိုးရဝဘ္ဆုိဒ္မ်ား။
.gov.sg ေတြမွာ တူညီတာေတြ အမ်ားၾကီးရိွတယ္။ စင္ကာပူက အစိုးရမွာ မူဝါဒတစ္ခ်ိဳ႕ရိွတယ္။ ဥပမာ single sign-on သေဘာမ်ိဳးအတြက္သံုးတာေတြက တစ္ခုနဲ႕တစ္ခုခပ္ဆင္ဆင္ဆိုရမယ္။ Authentication အတြက္ေတာ႔ အဓိက Singpass ကိုသံုးတယ္။ SingPass ကို individual အေနနဲ႕သံုးတယ္ေျပာရမယ္။ စင္ကာပူမွာ လူတုိင္းနီးပါး SingPass ရိွတယ္။ အခြန္ေဆာင္ေဆာင္၊ အစိုးရနဲ႕ပတ္သက္တာဘာလုပ္လုပ္ SingPass က လိုသလိုျဖစ္ေနတယ္။ SingPass ကို Crimson Logic ဆိုတဲ႔ ကုမ္ပနီကေရးတယ္။ Singapore Government websites ေတြရဲ႕ ၉၀ ရာခုိင္ႏႈန္းေက်ာ္ဟာ SingPass authentication ေပၚမူတည္တယ္။ အေနာနမတ္စ္ ေတြဟာ ဒါေတြကို သိမွာပဲ။ စင္ကာပူမွာလည္း အေနာနမတ္စ္ေတြရိွေကာင္းရိွေနမွာကိုး။
SingPass သံုးဖုိ႕ API ကို အစိုးရ websites လုပ္တဲ႔ ရံုးတုိင္းနီးပါးမွာ ရိွတယ္ထင္တယ္။ အဲဒါေတြကလည္း system ေပၚမူတည္တဲ႔အတြက္ system တုိင္းမွာရိွတဲ႔ အားနည္းခ်က္ေတြရိွမွာပဲ။ ေနာက္ထပ္ Authentication ႏွစ္ခုက EASY(e-Services Authorisation System) နဲ႕၊ ကုမ္ပနီေတြအတြက္သံုးတဲ႔ UEN နဲ႕ Login ဝင္တာေတြပဲ။
ေနာက္တစ္ခုက RSA keying လို႕ေခၚတယ္။ ဘဏ္ေတြမွာ 2-factor သံုးသလိုမ်ိဳး၊ စင္ကာပူမွာ အစိုးရ ဝက္ဘ္ဆုိထ္စ္ေတြမွာသံုးတယ္။ first layer provider ေတြထဲမွာေတာ႔ NCS က ေစ်းကြက္ရွယ္ရာေတာ္ေတာ္ရထားတယ္။ medinet.gov.sg ဆိုတာမ်ိဳးပဲ။ အဲဒီကေနမွတစ္ဆင္႔ government network ထဲေနာက္တစ္ဆင္႔ဝင္လုိ႕ရတယ္။ secured channel လုပ္လုိက္တာနဲ႕တူတယ္။ ျပီးေတာ႔ encrypted url ထပ္လုပ္တယ္။ ဆိုလုိတာကေတာ႔ ပထမအဆင္႔ကိုေဖာက္ျပီးမွ ဒုတိယအဆင္႔ကိုေရာက္မယ္။ အဲဒီပထမအဆင္႔ log-in server ကမွသာ ဝန္ၾကီးဌာနအသီးသီးရဲ႕ system ေတြကို သြားႏုိင္တယ္။ အဲဒီမွာ firewall setting ေတြရိွတယ္။ ဆိုလုိတာကေတာ႔ အဲဒါေတြဟာ မိန္းဂိတ္ေပါက္ဝေတြပဲ။ ဒီကေနမွျဖတ္သန္းဝင္ေရာက္ႏုိင္မယ္။ ေနာက္ထပ္ ၾကားေပါက္တစ္ခုေတာ႔ရိွေသးတယ္။ အစိုးရရံုးေတြမွာ ရံုးက အုိင္ပီနဲ႕ဆိုရင္ေတာ႔ production server ကို တိုက္ရိုက္ဖြင္႔ေပးထားတာရိွတယ္။ အဲဒါေတြကေတာ႔ first level authentication ကို bypass လုပ္ႏုိင္တယ္။
Hack တယ္ဆိုတဲ႔ေနရာမွာလည္း web ကေန hack တာက ခက္ခဲပင္ပန္းတဲ႔နည္းလမ္းလို႕ဆုိရမယ္ထင္တယ္။ attack ေတာ္ေတာ္မ်ားမ်ားဟာ os level ေတြေလာက္ကိုပစ္မွတ္ထားကုန္ၾကတာေတြ႕ပါတယ္။ cloud server မွာ Host ထားတာကိုေတာင္ down လုနီးပါးျဖစ္သြားတာ ဟိုတစ္ေလာကပဲၾကားလုိက္ပါေသးတယ္။ ရိုးရိုး စက္စုတ္ေလးေတြဆိုရင္ေတာ႔ ဝပ္စင္းျပီး ျပန္ေတာင္မတက္ေတာ႔ဘူး။ DB ကို ဦးတည္ျပီး တိုက္ခိုက္တာေတြလည္း အလြယ္နည္းေတြရိွပါတယ္။ ဥပမာ FAQ တို႕၊ Feedback တို႕အတြက္ကို main database မွာမ်ား table အေနနဲ႕ထားလိုက္ရင္ေတာ႔ အန္တရာယ္အလြန္ၾကီးသြားတတ္ပါတယ္။ network layer မွာ attack လုပ္တာေတြကလည္း ရိုးရွင္းထိေရာက္ပါတယ္။ ဆာဗာေတြအားလံုး CPU 100% ျဖစ္ေအာင္လုပ္တာတုိ႕၊ Switch ေတြ၊ Routers ေတြ match ျဖစ္ေအာင္မသံုးထားတဲ႔ Data Center ထဲအထိ သာသာယာယာေလးဝင္လာတာတုိ႕ျဖစ္တတ္ပါတယ္။ ဟိုတေလာက PA ဆိုတဲ႔ အစုိးရစနစ္တုိက္ခိုက္ခံလုိက္ရပါေသးတယ္။ အရင္ေရးတဲ႔သူေတြေရာ၊ အခုလက္ရိွ ထိန္းသိ္မ္းေနတဲ႔သူေတြပါ အေမးျမန္းခံထိပါတယ္။
ေနာက္တစ္ခုက Shine portal ဆိုတာ ရိွပါတယ္။ NCS ကေနလုပ္ထားတာပါ။ အစိုးရစစ္စစ္လုပ္ငန္းေတြဆိုရင္ အဲဒီကေနပဲသြားဖုိ႕ အစိုးရရဲ႕ ဆုိက္ဘာလံုျခံဳေရးမူထဲမွာပါပါတယ္။ သူတုိ႕ရဲ႕ standard sets ေတြရိွပါတယ္။ အဲဒါေတြကို လုိက္နာရပါတယ္။ email ပို႕ဖုိ႕ကအစ၊ web service သံုးရင္လည္း service တစ္ခုခ်င္းစီလုိက္ ပုိက္ဆံေပးရတဲ႔ central web service system ကေနသာ ျဖတ္သန္းသြားလာဖုိ႕ဆိုတဲ႔ စည္းကမ္းေတြရိွပါတယ္။ security certificate ေတြကိုလည္း အဆင္႔ဆင္႔လုိက္နာၾကရတာေတြရိွပါတယ္။ သုိ႕ေသာ္လည္း ဧည္႕ဆုိးဆိုတာေတာ႔ ဧည္႕စာရင္းတုိင္ရတဲ႔လမ္းဘက္က ဘယ္လာပါ႔မလဲဗ်ာ။
ေနာက္တစ္ခုက အစိုးရေတြဟာ အေျပာင္းအလဲတစ္ခုတစ္ခုအတြက္ အခ်ိန္ေတာ္ေတာ္ယူတယ္။ အဲဒါဟာ တျခားေနရာမွာေတာ႔ ေကာင္းရင္ေကာင္းမယ္။ software အတြက္ေတာ႔ သိပ္မေကာင္းလွဘူး။ Java upgrade ကို ၁.၄ ေတြ အမ်ားၾကီးရိွတယ္။ အဲဒါေတြကို 1.7 ကိုေျပာင္းတယ္။ 2013 ေလာက္မွ ညီညီညာညာ တေပ်ာ္တပါးေျပာင္းၾကတာ။ 1.7 မွာလည္း သူ႕ျပႆနာနဲ႕သူရိွတယ္။ java update ေတြဟာ ျပႆနာရွင္းဖုိ႕ ထုတ္ေနတာကို နားမလည္တဲ႔သူက နားမလည္ဘူး။ တစ္ခ်ိဳ႕ကေတာ႔ နားလည္ပါရဲ႕ သို႕ေသာ္လည္း web server ေတြ၊ app server ေတြက ေနာက္ဆံုးထုတ္ေတြနဲ႕ တစ္ခ်က္တစ္ခ်က္ ခ်က္ခ်င္း သဟဇာတမျဖစ္ေတာ႔ မျပင္ၾကဘူး။ known issue ကို မျပင္ရင္ေတာ႔ ကိုယ္႔ေသတြင္းကို ကိုယ္႔လက္နဲ႕တူးသြားတာမ်ိဳးျဖစ္တတ္တယ္။ Web Logic patch ေတြဆိုလည္း update လုပ္ခ်င္မွ လုပ္တာေတြ႕တယ္။ Strut 2 မွာ vulnerable ရိွတယ္ဆိုတာ ဟိုတစ္ေလာက email ပို႕တယ္။ အမွန္ေတာ႔အဲဒါေတြအတြက္ security team ေတြက ေစာင္႔ၾကည္႕ေလ႔လာေနရမွာ။ vendor ေတြအားကိုးလုိ႕ကေတာ႔ ဘာမွျဖစ္လာမယ္မထင္ဘူး။ Java နဲ႕ေရးထားတဲ႔ application အေဟာင္းေတြ ေတာ္ေတာ္မ်ားမ်ားဟာ ေတာ္ေတာ္ေလး outdated ျဖစ္ေနျပီ။ Spring သံုးတဲ႔ application ေတြမွာလည္း spring security မသံုးၾကတာမ်ားတယ္။ အမ်ားဆံုးအတြဲအစပ္ကေတာ႔ Struts/Spring/Oracle/Weblogic အဲဒါပဲ။ အဲဒီမွာမွ clustering ခပ္စုတ္စုတ္ေလးတစ္ခုေလာက္ပါမယ္။ App1/App2 လုပ္ထားမယ္။ (မစြံတာမ်ားတယ္။) System အေဟာင္းေတြဆိုရင္ sftp ကေန file upload ေတြေတာင္ပါေသး။ အဲဒါမ်ိဳးေတြက မသမာတဲ႔သူနဲ႕ေတြ႕ရင္ အန္တရာယ္သိပ္မ်ားတယ္။ data file uploading ေတြဟာ UI မွာလုိ စစ္ထားေဆးထားတာ မပါတာမ်ားတယ္။ vendor ခ်င္းနားလည္မႈနဲ႕လုပ္စားေနၾကသလုိျဖစ္ေနတယ္။
SingPass မွာလည္း username က FIN/IC no. ဆိုေတာ႔ အဲဒီ အယ္လ္ဂိုရစ္သမ္ကို သိရင္ အလြယ္ေလးပဲ။ အေရွ႕ဆံုးတစ္လံုး၊ ေနာက္ဆံုးတစ္လံုး။ checksum ကို ဘယ္အယ္လ္ဂိုရသမ္နဲ႕စစ္ဆိုတာမ်ိဳးရိွတယ္။ ဒါမွလည္း system ေတြမွာ NRIC လက္ခံတဲ႔အခါ valid ျဖစ္၊မျဖစ္ စစ္ေပးႏုိင္မွာကိုး။
အခုနေျပာခဲ႔တဲ႔ Struts တို႕၊ Spring တို႕လို MVC framework ေတြက အလကားေပးတာေတြပါ။ အဲဒီေတာ႔ source ကိုလည္း ၾကည္႕လုိ႕ရပါတယ္။ Framework တစ္ခုခ်င္းစီမွာ သူ႕အားသာခ်က္၊ သူ႕အားနည္းခ်က္နဲ႕ပါပဲ။ စနစ္တက်မသံုးရင္ loophole ျဖစ္တတ္ပါတယ္။ ဂ်ာဗားေပၚကာစတုန္းက applet ေတြစိတ္ခ်ရတယ္၊စိတ္ခ်ရတယ္လုပ္ေနရာက applet ခ်င္း session sharing လုပ္ေနတဲ႔ ျပႆနာကို ေစာေစာသိလုိက္လို႕ ျပႆနာသိပ္မၾကီးက်ယ္ဘဲ ျငိမ္းသြားဖူးတယ္။ web ေပၚမွာေတာ႔ ဘာမွ စိတ္ခ်ရတယ္မရိွပါဘူး။ ဖ်က္လိုဖ်က္စီးမလုပ္ခ်င္တဲ႔သူေတြ မဖ်က္လို႕၊ မပ်က္တာပဲရိွတယ္။ NASA က web ကို စမ္းသပ္ျပီးေတာ႔ စိတ္တုိင္းမက်လို႕ လူေတြသံုးဖုိ႕ေပးလုိက္တာဆုိေတာ႔ စကတည္းက အေျခခံျပႆနာေလးေတြရိွျပီးသား။ protocol ေတြက ကိုယ္ျပင္လုိ႕ရတာမဟုတ္ဘူး။ web architecture အတိုင္းရိွျပီးသားကို သံုးၾကရတာ။ browser ေတြကို ႏုိင္နင္းတဲ႔သူမ်ားၾကေတာ႔လည္း လုိသလို ဖ်ားေယာင္းႏုိင္ျပန္ေရာ။
တိုက္ခိုက္ခံရရင္ recovery အတြက္ Contingency Plan ရိွဖုိ႕အင္မတန္အေရးၾကီးပါတယ္။ အထူးသျဖင္႔ database ေတြပါပဲ။ က်န္တာေတြက ျပန္တက္လာေအာင္ တစ္နည္းနည္းနဲ႕ၾကံစည္လုိ႕ရေသးတယ္။ confidential data ေတြ ေပါက္ၾကားသြား၊ ပ်က္သြားရင္ေတာ႔ အစိုးရအေနနဲ႕လည္း အင္မတန္အထိနာႏုိင္တယ္။ တစ္ခ်ိဳ႕စနစ္ေတြမွာ ရံုးတြင္းမွာပဲ ေနာက္ေရြးေကာက္ပြဲအတြက္ အမတ္ေနရာေပးဖုိ႕ ရည္ရြယ္ထားျပီးသားလူေတြစာရင္းတုိ႕ဘာတုိ႕ရိွတတ္ေသးတယ္ဆိုေတာ႔ ဒါေတြလည္းပါသြားလို႕မျဖစ္ဘူး။ database ေတြကလည္း size ေပၚမူတည္ျပီး backup လုပ္ရတာၾကာတယ္။ port ေတြ ip ေတြကို trusted ကပဲ access လုပ္ႏုိင္ေအာင္ ဘယ္ေလာက္လုပ္ထားလုပ္ထား ေရွ႕နားက အကာအရံေတြ၊ မီးတံတုိင္းေတြျပိဳျပီဆိုရင္ေတာ႔ သူ႕မွာလည္း မစြမ္းသာေတာ႔ဘူး၊ရန္သူ႕လက္က်ရတာပဲ။
ဒါေတြကို တန္ျပန္ႏုိင္ဖုိ႕ ရုရွနဲ႕တရုတ္က geek ေတြကို စင္ကာပူအစိုးရက ေမြးစားဦးမယ္ထင္မိတယ္။ မၾကာခင္မွာ DSTA ရဲ႕အသံုးစားရိတ္၊ စင္ကာပူမွာ ယာယီစစ္မႈထမ္းရင္း ေသဆံုးတဲ႔စာရင္း၊ ဆီမီးအစိုးရကုမ္ပနီမ်ားအၾကားသေဘာတူညီမႈ၊ ဝန္ထမ္းအသံုးစားရိတ္၊ အီးအာရ္ပီ ေန႕စဥ္အျမတ္ေငြ၊ အစိုးရတစ္ဖက္လွည္႕လုပ္ငန္းမ်ားျဖစ္ေသာ MRT, singapore POOLS ေတြရဲ႕ အျမတ္ေငြ၊ CPF စီမံခန္႕ခြဲေရးမူဝါဒ၊ အစိုးရ၏ ဘဏ္လုပ္ငန္းအေပၚစည္းၾကပ္မႈေတြကို ၾကားရင္ၾကားရမယ္။
ဘာေတြဆက္ျဖစ္ဦးမလဲဆုိတာေတာ႔ ကိုယ္႔ဟာကိုယ္ထုိင္ၾကည္႕တာ ပိုေကာင္းပါတယ္။ ဘာမွမျဖစ္ဘဲလည္း ျငိမ္းခ်င္ျငိမ္းသြားမွာ။ ဖုန္းေရႊအစြမ္းနဲ႕ကယ္တင္သြားတာမ်ိဳးမျဖစ္ဘူးမေျပာႏုိင္ဘူး။ ဒီမွာလည္း အဲဒါေတြကို ယံုၾကည္ပါဘိသနဲ႕။ ။
Regards,
သုည
ဘာမဆိုျဖစ္ႏုိင္တယ္။
software ဆိုတာေတြက ေလေပၚမွာ စိတ္ခ်ရေတာ႔တာမဟုတ္တာၾကာျပီ။ အလြယ္ေျပာရရင္ေတာ႔ အခ်င္းခ်င္းနားနားကပ္ေျပာတာကို အနားက တစ္ေယာက္က ၾကားရသလုိမ်ိဳး၊ သူတုိ႕ဟာသူတို႕ အထာနဲ႕ေျပာလုိ႕ (encrypted) ျဖစ္ေနလို႕ ခ်က္ခ်င္းသေဘာမေပါက္တာသာရိွတယ္။ အဲဒီအထာစကားကို နားလည္တဲ႔သူကို ၾကားခဲ႔တဲ႔စကားကို ျပန္ဖြင္႔ျပႏိုင္ရင္ နားလည္သြားႏုိင္တာနဲ႕ဆင္တယ္။
စင္ကာပူအစိုးရဝဘ္ဆုိဒ္မ်ား။
.gov.sg ေတြမွာ တူညီတာေတြ အမ်ားၾကီးရိွတယ္။ စင္ကာပူက အစိုးရမွာ မူဝါဒတစ္ခ်ိဳ႕ရိွတယ္။ ဥပမာ single sign-on သေဘာမ်ိဳးအတြက္သံုးတာေတြက တစ္ခုနဲ႕တစ္ခုခပ္ဆင္ဆင္ဆိုရမယ္။ Authentication အတြက္ေတာ႔ အဓိက Singpass ကိုသံုးတယ္။ SingPass ကို individual အေနနဲ႕သံုးတယ္ေျပာရမယ္။ စင္ကာပူမွာ လူတုိင္းနီးပါး SingPass ရိွတယ္။ အခြန္ေဆာင္ေဆာင္၊ အစိုးရနဲ႕ပတ္သက္တာဘာလုပ္လုပ္ SingPass က လိုသလိုျဖစ္ေနတယ္။ SingPass ကို Crimson Logic ဆိုတဲ႔ ကုမ္ပနီကေရးတယ္။ Singapore Government websites ေတြရဲ႕ ၉၀ ရာခုိင္ႏႈန္းေက်ာ္ဟာ SingPass authentication ေပၚမူတည္တယ္။ အေနာနမတ္စ္ ေတြဟာ ဒါေတြကို သိမွာပဲ။ စင္ကာပူမွာလည္း အေနာနမတ္စ္ေတြရိွေကာင္းရိွေနမွာကိုး။
SingPass သံုးဖုိ႕ API ကို အစိုးရ websites လုပ္တဲ႔ ရံုးတုိင္းနီးပါးမွာ ရိွတယ္ထင္တယ္။ အဲဒါေတြကလည္း system ေပၚမူတည္တဲ႔အတြက္ system တုိင္းမွာရိွတဲ႔ အားနည္းခ်က္ေတြရိွမွာပဲ။ ေနာက္ထပ္ Authentication ႏွစ္ခုက EASY(e-Services Authorisation System) နဲ႕၊ ကုမ္ပနီေတြအတြက္သံုးတဲ႔ UEN နဲ႕ Login ဝင္တာေတြပဲ။
ေနာက္တစ္ခုက RSA keying လို႕ေခၚတယ္။ ဘဏ္ေတြမွာ 2-factor သံုးသလိုမ်ိဳး၊ စင္ကာပူမွာ အစိုးရ ဝက္ဘ္ဆုိထ္စ္ေတြမွာသံုးတယ္။ first layer provider ေတြထဲမွာေတာ႔ NCS က ေစ်းကြက္ရွယ္ရာေတာ္ေတာ္ရထားတယ္။ medinet.gov.sg ဆိုတာမ်ိဳးပဲ။ အဲဒီကေနမွတစ္ဆင္႔ government network ထဲေနာက္တစ္ဆင္႔ဝင္လုိ႕ရတယ္။ secured channel လုပ္လုိက္တာနဲ႕တူတယ္။ ျပီးေတာ႔ encrypted url ထပ္လုပ္တယ္။ ဆိုလုိတာကေတာ႔ ပထမအဆင္႔ကိုေဖာက္ျပီးမွ ဒုတိယအဆင္႔ကိုေရာက္မယ္။ အဲဒီပထမအဆင္႔ log-in server ကမွသာ ဝန္ၾကီးဌာနအသီးသီးရဲ႕ system ေတြကို သြားႏုိင္တယ္။ အဲဒီမွာ firewall setting ေတြရိွတယ္။ ဆိုလုိတာကေတာ႔ အဲဒါေတြဟာ မိန္းဂိတ္ေပါက္ဝေတြပဲ။ ဒီကေနမွျဖတ္သန္းဝင္ေရာက္ႏုိင္မယ္။ ေနာက္ထပ္ ၾကားေပါက္တစ္ခုေတာ႔ရိွေသးတယ္။ အစိုးရရံုးေတြမွာ ရံုးက အုိင္ပီနဲ႕ဆိုရင္ေတာ႔ production server ကို တိုက္ရိုက္ဖြင္႔ေပးထားတာရိွတယ္။ အဲဒါေတြကေတာ႔ first level authentication ကို bypass လုပ္ႏုိင္တယ္။
Hack တယ္ဆိုတဲ႔ေနရာမွာလည္း web ကေန hack တာက ခက္ခဲပင္ပန္းတဲ႔နည္းလမ္းလို႕ဆုိရမယ္ထင္တယ္။ attack ေတာ္ေတာ္မ်ားမ်ားဟာ os level ေတြေလာက္ကိုပစ္မွတ္ထားကုန္ၾကတာေတြ႕ပါတယ္။ cloud server မွာ Host ထားတာကိုေတာင္ down လုနီးပါးျဖစ္သြားတာ ဟိုတစ္ေလာကပဲၾကားလုိက္ပါေသးတယ္။ ရိုးရိုး စက္စုတ္ေလးေတြဆိုရင္ေတာ႔ ဝပ္စင္းျပီး ျပန္ေတာင္မတက္ေတာ႔ဘူး။ DB ကို ဦးတည္ျပီး တိုက္ခိုက္တာေတြလည္း အလြယ္နည္းေတြရိွပါတယ္။ ဥပမာ FAQ တို႕၊ Feedback တို႕အတြက္ကို main database မွာမ်ား table အေနနဲ႕ထားလိုက္ရင္ေတာ႔ အန္တရာယ္အလြန္ၾကီးသြားတတ္ပါတယ္။ network layer မွာ attack လုပ္တာေတြကလည္း ရိုးရွင္းထိေရာက္ပါတယ္။ ဆာဗာေတြအားလံုး CPU 100% ျဖစ္ေအာင္လုပ္တာတုိ႕၊ Switch ေတြ၊ Routers ေတြ match ျဖစ္ေအာင္မသံုးထားတဲ႔ Data Center ထဲအထိ သာသာယာယာေလးဝင္လာတာတုိ႕ျဖစ္တတ္ပါတယ္။ ဟိုတေလာက PA ဆိုတဲ႔ အစုိးရစနစ္တုိက္ခိုက္ခံလုိက္ရပါေသးတယ္။ အရင္ေရးတဲ႔သူေတြေရာ၊ အခုလက္ရိွ ထိန္းသိ္မ္းေနတဲ႔သူေတြပါ အေမးျမန္းခံထိပါတယ္။
ေနာက္တစ္ခုက Shine portal ဆိုတာ ရိွပါတယ္။ NCS ကေနလုပ္ထားတာပါ။ အစိုးရစစ္စစ္လုပ္ငန္းေတြဆိုရင္ အဲဒီကေနပဲသြားဖုိ႕ အစိုးရရဲ႕ ဆုိက္ဘာလံုျခံဳေရးမူထဲမွာပါပါတယ္။ သူတုိ႕ရဲ႕ standard sets ေတြရိွပါတယ္။ အဲဒါေတြကို လုိက္နာရပါတယ္။ email ပို႕ဖုိ႕ကအစ၊ web service သံုးရင္လည္း service တစ္ခုခ်င္းစီလုိက္ ပုိက္ဆံေပးရတဲ႔ central web service system ကေနသာ ျဖတ္သန္းသြားလာဖုိ႕ဆိုတဲ႔ စည္းကမ္းေတြရိွပါတယ္။ security certificate ေတြကိုလည္း အဆင္႔ဆင္႔လုိက္နာၾကရတာေတြရိွပါတယ္။ သုိ႕ေသာ္လည္း ဧည္႕ဆုိးဆိုတာေတာ႔ ဧည္႕စာရင္းတုိင္ရတဲ႔လမ္းဘက္က ဘယ္လာပါ႔မလဲဗ်ာ။
ေနာက္တစ္ခုက အစိုးရေတြဟာ အေျပာင္းအလဲတစ္ခုတစ္ခုအတြက္ အခ်ိန္ေတာ္ေတာ္ယူတယ္။ အဲဒါဟာ တျခားေနရာမွာေတာ႔ ေကာင္းရင္ေကာင္းမယ္။ software အတြက္ေတာ႔ သိပ္မေကာင္းလွဘူး။ Java upgrade ကို ၁.၄ ေတြ အမ်ားၾကီးရိွတယ္။ အဲဒါေတြကို 1.7 ကိုေျပာင္းတယ္။ 2013 ေလာက္မွ ညီညီညာညာ တေပ်ာ္တပါးေျပာင္းၾကတာ။ 1.7 မွာလည္း သူ႕ျပႆနာနဲ႕သူရိွတယ္။ java update ေတြဟာ ျပႆနာရွင္းဖုိ႕ ထုတ္ေနတာကို နားမလည္တဲ႔သူက နားမလည္ဘူး။ တစ္ခ်ိဳ႕ကေတာ႔ နားလည္ပါရဲ႕ သို႕ေသာ္လည္း web server ေတြ၊ app server ေတြက ေနာက္ဆံုးထုတ္ေတြနဲ႕ တစ္ခ်က္တစ္ခ်က္ ခ်က္ခ်င္း သဟဇာတမျဖစ္ေတာ႔ မျပင္ၾကဘူး။ known issue ကို မျပင္ရင္ေတာ႔ ကိုယ္႔ေသတြင္းကို ကိုယ္႔လက္နဲ႕တူးသြားတာမ်ိဳးျဖစ္တတ္တယ္။ Web Logic patch ေတြဆိုလည္း update လုပ္ခ်င္မွ လုပ္တာေတြ႕တယ္။ Strut 2 မွာ vulnerable ရိွတယ္ဆိုတာ ဟိုတစ္ေလာက email ပို႕တယ္။ အမွန္ေတာ႔အဲဒါေတြအတြက္ security team ေတြက ေစာင္႔ၾကည္႕ေလ႔လာေနရမွာ။ vendor ေတြအားကိုးလုိ႕ကေတာ႔ ဘာမွျဖစ္လာမယ္မထင္ဘူး။ Java နဲ႕ေရးထားတဲ႔ application အေဟာင္းေတြ ေတာ္ေတာ္မ်ားမ်ားဟာ ေတာ္ေတာ္ေလး outdated ျဖစ္ေနျပီ။ Spring သံုးတဲ႔ application ေတြမွာလည္း spring security မသံုးၾကတာမ်ားတယ္။ အမ်ားဆံုးအတြဲအစပ္ကေတာ႔ Struts/Spring/Oracle/Weblogic အဲဒါပဲ။ အဲဒီမွာမွ clustering ခပ္စုတ္စုတ္ေလးတစ္ခုေလာက္ပါမယ္။ App1/App2 လုပ္ထားမယ္။ (မစြံတာမ်ားတယ္။) System အေဟာင္းေတြဆိုရင္ sftp ကေန file upload ေတြေတာင္ပါေသး။ အဲဒါမ်ိဳးေတြက မသမာတဲ႔သူနဲ႕ေတြ႕ရင္ အန္တရာယ္သိပ္မ်ားတယ္။ data file uploading ေတြဟာ UI မွာလုိ စစ္ထားေဆးထားတာ မပါတာမ်ားတယ္။ vendor ခ်င္းနားလည္မႈနဲ႕လုပ္စားေနၾကသလုိျဖစ္ေနတယ္။
SingPass မွာလည္း username က FIN/IC no. ဆိုေတာ႔ အဲဒီ အယ္လ္ဂိုရစ္သမ္ကို သိရင္ အလြယ္ေလးပဲ။ အေရွ႕ဆံုးတစ္လံုး၊ ေနာက္ဆံုးတစ္လံုး။ checksum ကို ဘယ္အယ္လ္ဂိုရသမ္နဲ႕စစ္ဆိုတာမ်ိဳးရိွတယ္။ ဒါမွလည္း system ေတြမွာ NRIC လက္ခံတဲ႔အခါ valid ျဖစ္၊မျဖစ္ စစ္ေပးႏုိင္မွာကိုး။
အခုနေျပာခဲ႔တဲ႔ Struts တို႕၊ Spring တို႕လို MVC framework ေတြက အလကားေပးတာေတြပါ။ အဲဒီေတာ႔ source ကိုလည္း ၾကည္႕လုိ႕ရပါတယ္။ Framework တစ္ခုခ်င္းစီမွာ သူ႕အားသာခ်က္၊ သူ႕အားနည္းခ်က္နဲ႕ပါပဲ။ စနစ္တက်မသံုးရင္ loophole ျဖစ္တတ္ပါတယ္။ ဂ်ာဗားေပၚကာစတုန္းက applet ေတြစိတ္ခ်ရတယ္၊စိတ္ခ်ရတယ္လုပ္ေနရာက applet ခ်င္း session sharing လုပ္ေနတဲ႔ ျပႆနာကို ေစာေစာသိလုိက္လို႕ ျပႆနာသိပ္မၾကီးက်ယ္ဘဲ ျငိမ္းသြားဖူးတယ္။ web ေပၚမွာေတာ႔ ဘာမွ စိတ္ခ်ရတယ္မရိွပါဘူး။ ဖ်က္လိုဖ်က္စီးမလုပ္ခ်င္တဲ႔သူေတြ မဖ်က္လို႕၊ မပ်က္တာပဲရိွတယ္။ NASA က web ကို စမ္းသပ္ျပီးေတာ႔ စိတ္တုိင္းမက်လို႕ လူေတြသံုးဖုိ႕ေပးလုိက္တာဆုိေတာ႔ စကတည္းက အေျခခံျပႆနာေလးေတြရိွျပီးသား။ protocol ေတြက ကိုယ္ျပင္လုိ႕ရတာမဟုတ္ဘူး။ web architecture အတိုင္းရိွျပီးသားကို သံုးၾကရတာ။ browser ေတြကို ႏုိင္နင္းတဲ႔သူမ်ားၾကေတာ႔လည္း လုိသလို ဖ်ားေယာင္းႏုိင္ျပန္ေရာ။
တိုက္ခိုက္ခံရရင္ recovery အတြက္ Contingency Plan ရိွဖုိ႕အင္မတန္အေရးၾကီးပါတယ္။ အထူးသျဖင္႔ database ေတြပါပဲ။ က်န္တာေတြက ျပန္တက္လာေအာင္ တစ္နည္းနည္းနဲ႕ၾကံစည္လုိ႕ရေသးတယ္။ confidential data ေတြ ေပါက္ၾကားသြား၊ ပ်က္သြားရင္ေတာ႔ အစိုးရအေနနဲ႕လည္း အင္မတန္အထိနာႏုိင္တယ္။ တစ္ခ်ိဳ႕စနစ္ေတြမွာ ရံုးတြင္းမွာပဲ ေနာက္ေရြးေကာက္ပြဲအတြက္ အမတ္ေနရာေပးဖုိ႕ ရည္ရြယ္ထားျပီးသားလူေတြစာရင္းတုိ႕ဘာတုိ႕ရိွတတ္ေသးတယ္ဆိုေတာ႔ ဒါေတြလည္းပါသြားလို႕မျဖစ္ဘူး။ database ေတြကလည္း size ေပၚမူတည္ျပီး backup လုပ္ရတာၾကာတယ္။ port ေတြ ip ေတြကို trusted ကပဲ access လုပ္ႏုိင္ေအာင္ ဘယ္ေလာက္လုပ္ထားလုပ္ထား ေရွ႕နားက အကာအရံေတြ၊ မီးတံတုိင္းေတြျပိဳျပီဆိုရင္ေတာ႔ သူ႕မွာလည္း မစြမ္းသာေတာ႔ဘူး၊ရန္သူ႕လက္က်ရတာပဲ။
ဒါေတြကို တန္ျပန္ႏုိင္ဖုိ႕ ရုရွနဲ႕တရုတ္က geek ေတြကို စင္ကာပူအစိုးရက ေမြးစားဦးမယ္ထင္မိတယ္။ မၾကာခင္မွာ DSTA ရဲ႕အသံုးစားရိတ္၊ စင္ကာပူမွာ ယာယီစစ္မႈထမ္းရင္း ေသဆံုးတဲ႔စာရင္း၊ ဆီမီးအစိုးရကုမ္ပနီမ်ားအၾကားသေဘာတူညီမႈ၊ ဝန္ထမ္းအသံုးစားရိတ္၊ အီးအာရ္ပီ ေန႕စဥ္အျမတ္ေငြ၊ အစိုးရတစ္ဖက္လွည္႕လုပ္ငန္းမ်ားျဖစ္ေသာ MRT, singapore POOLS ေတြရဲ႕ အျမတ္ေငြ၊ CPF စီမံခန္႕ခြဲေရးမူဝါဒ၊ အစိုးရ၏ ဘဏ္လုပ္ငန္းအေပၚစည္းၾကပ္မႈေတြကို ၾကားရင္ၾကားရမယ္။
ဘာေတြဆက္ျဖစ္ဦးမလဲဆုိတာေတာ႔ ကိုယ္႔ဟာကိုယ္ထုိင္ၾကည္႕တာ ပိုေကာင္းပါတယ္။ ဘာမွမျဖစ္ဘဲလည္း ျငိမ္းခ်င္ျငိမ္းသြားမွာ။ ဖုန္းေရႊအစြမ္းနဲ႕ကယ္တင္သြားတာမ်ိဳးမျဖစ္ဘူးမေျပာႏုိင္ဘူး။ ဒီမွာလည္း အဲဒါေတြကို ယံုၾကည္ပါဘိသနဲ႕။ ။
Regards,
သုည
Tuesday, October 8, 2013
Explain Plan Oracle
Explain Plan
EXPLAIN PLAN FOR
SELECT * from [table] where [col1]='sth' and [col2]='sth' and and [col3]='sth' ;
select * from PLAN_TABLE;
Oracle မွာေတာ႔ အဲဒီလို execute လုပ္ၾကည္႕ေလ႔ရိွၾကတယ္။ ဒါမွ ကိုယ္႔ query က ဘယ္လို ဘယ္လို အလုပ္လုပ္ေနတယ္ဆိုတာ ေသခ်ာသိႏုိင္တယ္။
EXPLAIN PLAN FOR
SELECT * from [table] where [col1]='sth' and [col2]='sth' and and [col3]='sth' ;
select * from PLAN_TABLE;
Oracle မွာေတာ႔ အဲဒီလို execute လုပ္ၾကည္႕ေလ႔ရိွၾကတယ္။ ဒါမွ ကိုယ္႔ query က ဘယ္လို ဘယ္လို အလုပ္လုပ္ေနတယ္ဆိုတာ ေသခ်ာသိႏုိင္တယ္။
Thursday, October 3, 2013
weblogic errors
weblogic errors
weblogic 8 က error ႏွစ္ခုအေၾကာင္းေျပာမယ္စိတ္ကူးတယ္။
တစ္ခုက stuck thread ပါ။ thread ေတြရဲ႕ maximum time ေက်ာ္သြားတာပါ။ process ေတြၾကာတဲ႔အခါျဖစ္ေလ႔ရိွပါတယ္။ report ေတြဘာေတြ ေႏွးေကြးေလးလံလာရင္ မၾကာမၾကာၾကံဳရပါလိမ္႔မယ္။ အလြယ္လမ္းကေတာ႔ ၁၅ မိနစ္မေလာက္ရင္ မိနစ္ ၂၀ တုိး၊ မိနစ္ ၂၀ မေလာက္ရင္ မိနစ္ ၃၀ တုိးေပါ႔။ ျဖစ္တဲ႔ root cause ကိုေတာ႔ ေနာက္မွ ေအးေဆးရွာေပါ႔။ ေလာေလာဆယ္ error မျမင္ရတာစိတ္ခ်မ္းသာရတာပဲ။ တစ္ခ်ိဳ႕ scenerio ေတြမွာဆိုရင္ အခ်ိန္ၾကာသြားရင္း stuck ျဖစ္ေနရာက unstuck ျပန္ျဖစ္သြားပါတယ္။ အျမဲေတာ႔ အဲဒီေလာက္အထိမၾကာဘူး။ stuck threads ေတြမ်ားလာရင္ instance တစ္ခုလံုး down သြားတာပဲ။
တကယ္ျဖစ္တာက ေရးတဲ႔သူေတြ လက္စြမ္းျပျပီး တလြဲေတြလုပ္ၾကလြန္းတာေၾကာင္႔ျဖစ္တယ္။ နည္းပညာေတြ ဘယ္ေလာက္တုိးတက္တုိးတက္၊ သံုးစြဲတဲ႔သူက နည္းလမ္းမမွန္ရင္ အဲဒါေတြက ၾကံဳျမဲၾကံဳေနရဦးမယ္။
မၾကာမီႏွစ္ေတြမွာ software ေတြကို app store မွာ game ေရာင္းေနသလုိ တစ္ခု တစ္က်ပ္နဲ႕ေရာင္းရေတာ႔မယ္ထင္တယ္။ အဲဒီေခတ္ေရာက္ရင္ေတာ႔ တကယ္ေကာင္းတဲ႔ဟာကိုပဲ တစ္က်ပ္တိတိေပးဝယ္ရလိမ္႔မယ္။ ေတာ္ရိေရာ္ရိေတြကေတာ႔ အလကားေပးေတာင္ မသံုးေလာက္ေတာ႔ဘူး။
ဒုတိယတစ္ခုက major. minor ဆိုလား။
အဲဒီတစ္ခုလည္း မွတ္ထားၾကပါ။ ရွာစားေဖြစားရတာခက္ရတဲ႔အထဲ တျခားသူေတြရဲ႕ျပႆနာေၾကာင္႔ ကိုယ္က်ိဳးမနည္းေအာင္ သတိထားရပါတယ္။ အဲဒါကေတာ႔ deployment လုပ္တဲ႔ Linux သမားေတြေၾကာင္႔ျဖစ္တာပါ။ ပံုမွန္အားျဖင္႔ java ဗာရွင္းတစ္ခုတည္းဆိုရင္ေတာ႔ ဘာမွမျဖစ္ပါဘူး။ production server မွာ jdk တစ္ခုထက္ပိုရိွေနရင္ root account နဲ႕ weblogic ကို restart လုပ္မိရင္ 1.5 နဲ႕တက္လာလိမ္႔မယ္။ အဲဒါဆို 1.4 နဲ႕ app ေတြမွာ compile လုပ္လိုက္တုိင္း jsp version conflict ေတြျဖစ္ျပီး page ေတြ တက္တစ္ခ်ိဳ႕၊မတတက္တစ္ခ်ိဳ႕ျဖစ္ကုန္မယ္။ အဲဒါဆိုရင္ restart လုပ္လုိက္တဲ႔သူကုိ weblogic user account နဲ႕ ျပန္ျပီး restart လုပ္ခုိင္းရတယ္။ အဲဒါေလးေတြက system အေဟာင္းေတြကို ထိန္းသိမ္းေနတဲ႔သူေတြအတြက္ေတာ႔ သိထားရမယ္႔ကိစၥေတြ။
အခုတေလာ log file ေတြၾကည္႕ရင္ အဲဒီ error ႏွစ္ခုကိုအရင္စစ္ျဖစ္တယ္။ မၾကာမၾကာၾကံဳခဲ႔ျပီးျပီ။
ျဖစ္ကတတ္ဆန္းေရးခဲ႔ျခင္း အခ်င္းခ်င္း ကင္းရွင္းၾကပါေစ။
Zero
weblogic 8 က error ႏွစ္ခုအေၾကာင္းေျပာမယ္စိတ္ကူးတယ္။
တစ္ခုက stuck thread ပါ။ thread ေတြရဲ႕ maximum time ေက်ာ္သြားတာပါ။ process ေတြၾကာတဲ႔အခါျဖစ္ေလ႔ရိွပါတယ္။ report ေတြဘာေတြ ေႏွးေကြးေလးလံလာရင္ မၾကာမၾကာၾကံဳရပါလိမ္႔မယ္။ အလြယ္လမ္းကေတာ႔ ၁၅ မိနစ္မေလာက္ရင္ မိနစ္ ၂၀ တုိး၊ မိနစ္ ၂၀ မေလာက္ရင္ မိနစ္ ၃၀ တုိးေပါ႔။ ျဖစ္တဲ႔ root cause ကိုေတာ႔ ေနာက္မွ ေအးေဆးရွာေပါ႔။ ေလာေလာဆယ္ error မျမင္ရတာစိတ္ခ်မ္းသာရတာပဲ။ တစ္ခ်ိဳ႕ scenerio ေတြမွာဆိုရင္ အခ်ိန္ၾကာသြားရင္း stuck ျဖစ္ေနရာက unstuck ျပန္ျဖစ္သြားပါတယ္။ အျမဲေတာ႔ အဲဒီေလာက္အထိမၾကာဘူး။ stuck threads ေတြမ်ားလာရင္ instance တစ္ခုလံုး down သြားတာပဲ။
တကယ္ျဖစ္တာက ေရးတဲ႔သူေတြ လက္စြမ္းျပျပီး တလြဲေတြလုပ္ၾကလြန္းတာေၾကာင္႔ျဖစ္တယ္။ နည္းပညာေတြ ဘယ္ေလာက္တုိးတက္တုိးတက္၊ သံုးစြဲတဲ႔သူက နည္းလမ္းမမွန္ရင္ အဲဒါေတြက ၾကံဳျမဲၾကံဳေနရဦးမယ္။
မၾကာမီႏွစ္ေတြမွာ software ေတြကို app store မွာ game ေရာင္းေနသလုိ တစ္ခု တစ္က်ပ္နဲ႕ေရာင္းရေတာ႔မယ္ထင္တယ္။ အဲဒီေခတ္ေရာက္ရင္ေတာ႔ တကယ္ေကာင္းတဲ႔ဟာကိုပဲ တစ္က်ပ္တိတိေပးဝယ္ရလိမ္႔မယ္။ ေတာ္ရိေရာ္ရိေတြကေတာ႔ အလကားေပးေတာင္ မသံုးေလာက္ေတာ႔ဘူး။
ဒုတိယတစ္ခုက major. minor ဆိုလား။
အဲဒီတစ္ခုလည္း မွတ္ထားၾကပါ။ ရွာစားေဖြစားရတာခက္ရတဲ႔အထဲ တျခားသူေတြရဲ႕ျပႆနာေၾကာင္႔ ကိုယ္က်ိဳးမနည္းေအာင္ သတိထားရပါတယ္။ အဲဒါကေတာ႔ deployment လုပ္တဲ႔ Linux သမားေတြေၾကာင္႔ျဖစ္တာပါ။ ပံုမွန္အားျဖင္႔ java ဗာရွင္းတစ္ခုတည္းဆိုရင္ေတာ႔ ဘာမွမျဖစ္ပါဘူး။ production server မွာ jdk တစ္ခုထက္ပိုရိွေနရင္ root account နဲ႕ weblogic ကို restart လုပ္မိရင္ 1.5 နဲ႕တက္လာလိမ္႔မယ္။ အဲဒါဆို 1.4 နဲ႕ app ေတြမွာ compile လုပ္လိုက္တုိင္း jsp version conflict ေတြျဖစ္ျပီး page ေတြ တက္တစ္ခ်ိဳ႕၊မတတက္တစ္ခ်ိဳ႕ျဖစ္ကုန္မယ္။ အဲဒါဆိုရင္ restart လုပ္လုိက္တဲ႔သူကုိ weblogic user account နဲ႕ ျပန္ျပီး restart လုပ္ခုိင္းရတယ္။ အဲဒါေလးေတြက system အေဟာင္းေတြကို ထိန္းသိမ္းေနတဲ႔သူေတြအတြက္ေတာ႔ သိထားရမယ္႔ကိစၥေတြ။
အခုတေလာ log file ေတြၾကည္႕ရင္ အဲဒီ error ႏွစ္ခုကိုအရင္စစ္ျဖစ္တယ္။ မၾကာမၾကာၾကံဳခဲ႔ျပီးျပီ။
ျဖစ္ကတတ္ဆန္းေရးခဲ႔ျခင္း အခ်င္းခ်င္း ကင္းရွင္းၾကပါေစ။
Zero
Tuesday, October 1, 2013
Maven config
Maven config
Java မွာ ANT build က အေတာ္နာမည္ၾကီးတယ္။ maven ကေတာ႔ dependency ကိစၥေတြအတြက္ပိုအသံုးဝင္သလုိရိွတယ္။ အၾကမ္းဖ်င္း အဲဒီလိုေတာ႔ နားလည္တယ္။ အရင္ရံုးမွာေတာ႔ maven သံုးတယ္။ အခုရံုးနဲ႕က်န္ရံုးေတြမွာေတာ႔ ANT build ပဲသံုးတယ္။
အမွန္ေတာ႔ သိပ္မလိုလွဘူး။
သို႕ေသာ္လည္း တစ္စုတစ္ေဝးျဖစ္သြားေအာင္ အဲဒါေလးေရးလုိက္တယ္။
http://maven.apache.org/download.cgi ကေနျပီး maven ဗာရွင္းတစ္ခုခု download အရင္လုပ္။
ျပီးရင္ extract လုပ္စရာလိုရင္လုပ္။
Environment variable ကေနျပီး MAVEN_HOME လုပ္ခ်င္လုပ္။ JAVA_HOME နဲ႕ခပ္ဆင္ဆင္ပဲ။ PATH ထဲမွာ bin folder ကို point လုပ္။ အဲဒါက အလုပ္ရွဳပ္တယ္ထင္တယ္။ အဲဒီေတာ႔ command line ကပဲ။
set PATH=C:\maven\bin;%PATH%
C:\maven ကေတာ႔ ကိုယ္extract လုပ္ထားတဲ႔ location ေပါ႔။ အဲဒီလိုလုပ္လုိက္ျပီးရင္။ mvn --version ဆိုျပီး command prompt ကေနရိုက္။ အိုေကတယ္ဆိုရင္ maven version ေတြေပၚလာမယ္။ jdk 5 သို႕မဟုတ္ 6 နဲ႕ေတာ႔ရတယ္။ က်န္တဲ႔ ဗာရွင္းေတြေတာ႔ မသိ။ maven ရဲ႕ default local folder က .m2 ဆိုတဲ႔ဟာ။ User folder ေအာက္မွာရိွတယ္။ အဲဒါကိုလည္း ေျပာင္းခ်င္ရင္ maven folder ထဲက config မွာျပင္လုိက္လုိ႕ရတယ္။ ခပ္လြယ္လြယ္ပဲ။
maven ရိွမွ pom.xml ဆိုတဲ႔ build file ေတြကို build လုပ္ႏုိင္မယ္။ web service စာအုပ္ဖတ္ရင္း maven setup လုပ္စရာလိုတာနဲ႕ တစ္ခါတည္းေရးထားလုိက္တာပါ။ web service ေတြအေၾကာင္းဘက္ ဆက္ေရးမယ္စိတ္ကူးတယ္။
ref:
http://maven.apache.org/download.cgi
Java မွာ ANT build က အေတာ္နာမည္ၾကီးတယ္။ maven ကေတာ႔ dependency ကိစၥေတြအတြက္ပိုအသံုးဝင္သလုိရိွတယ္။ အၾကမ္းဖ်င္း အဲဒီလိုေတာ႔ နားလည္တယ္။ အရင္ရံုးမွာေတာ႔ maven သံုးတယ္။ အခုရံုးနဲ႕က်န္ရံုးေတြမွာေတာ႔ ANT build ပဲသံုးတယ္။
အမွန္ေတာ႔ သိပ္မလိုလွဘူး။
သို႕ေသာ္လည္း တစ္စုတစ္ေဝးျဖစ္သြားေအာင္ အဲဒါေလးေရးလုိက္တယ္။
http://maven.apache.org/download.cgi ကေနျပီး maven ဗာရွင္းတစ္ခုခု download အရင္လုပ္။
ျပီးရင္ extract လုပ္စရာလိုရင္လုပ္။
Environment variable ကေနျပီး MAVEN_HOME လုပ္ခ်င္လုပ္။ JAVA_HOME နဲ႕ခပ္ဆင္ဆင္ပဲ။ PATH ထဲမွာ bin folder ကို point လုပ္။ အဲဒါက အလုပ္ရွဳပ္တယ္ထင္တယ္။ အဲဒီေတာ႔ command line ကပဲ။
set PATH=C:\maven\bin;%PATH%
C:\maven ကေတာ႔ ကိုယ္extract လုပ္ထားတဲ႔ location ေပါ႔။ အဲဒီလိုလုပ္လုိက္ျပီးရင္။ mvn --version ဆိုျပီး command prompt ကေနရိုက္။ အိုေကတယ္ဆိုရင္ maven version ေတြေပၚလာမယ္။ jdk 5 သို႕မဟုတ္ 6 နဲ႕ေတာ႔ရတယ္။ က်န္တဲ႔ ဗာရွင္းေတြေတာ႔ မသိ။ maven ရဲ႕ default local folder က .m2 ဆိုတဲ႔ဟာ။ User folder ေအာက္မွာရိွတယ္။ အဲဒါကိုလည္း ေျပာင္းခ်င္ရင္ maven folder ထဲက config မွာျပင္လုိက္လုိ႕ရတယ္။ ခပ္လြယ္လြယ္ပဲ။
maven ရိွမွ pom.xml ဆိုတဲ႔ build file ေတြကို build လုပ္ႏုိင္မယ္။ web service စာအုပ္ဖတ္ရင္း maven setup လုပ္စရာလိုတာနဲ႕ တစ္ခါတည္းေရးထားလုိက္တာပါ။ web service ေတြအေၾကာင္းဘက္ ဆက္ေရးမယ္စိတ္ကူးတယ္။
ref:
http://maven.apache.org/download.cgi
sequence Vs Max+1
sequence Vs Max+1
Max+1 ေရးတဲ႔သူေတြ အရင္တုန္းက ေတာ္ေတာ္မ်ားမွန္းသတိထားမိတယ္။ unique key တစ္ခုကို ရဖုိ႕ ရိွျပီးသား ေဒတာေတြအားလံုးကိုျပန္ဖတ္ျပီး ၁ေပါင္းရတာ ေရးတဲ႔သူအတြက္လြယ္ေပမယ္႔ ေဒတာေဘ႔စ္အတြက္ေရရွည္မွာ မလြယ္ဘူး။ အဲဒီလိုေရးတာပ်င္းတဲ႔သူေတြထင္တယ္။ table ၾကီးေတြ ဝဝဖုိင္႔ဖုိင္႔ျဖစ္လာတဲ႔အခါ Max+1 က ဒုကၡေပးတတ္ပါတယ္။ sequence table လုပ္ျပီး .nextValue နဲ႕သြားပါ။ အင္မတန္ျမန္ပါလိမ္႔မယ္။
sequence တစ္ခုနမူနာျပရရင္ ေဟာသလိုေရးပါတယ္။
CREATE SEQUENCE auto_icrrm_attendance_seq
MINVALUE 1
MAXVALUE 999999999999999999999999999
START WITH 2013000079
INCREMENT BY 1
CACHE 20;
အဲဒီလို create လုပ္ျပီးရင္ ဒီလို သံုးရံုပါပဲ။
select auto_icrrm_attendance_seq.nextval from dual
Cache 20 ေပးထားတာကေတာ႔ memory မွာ အခု ၂၀ တစ္ခါတည္းသိမ္းထားလုိ႕ရေအာင္ oracle ကိုသတိေပးတာပါ။ အဲဒါက နည္းနည္းပိုျမန္ေစပါတယ္။ ကိုယ္လိုခ်င္တာက unique ျဖစ္ရံုပဲလား။ sequence ျဖစ္ဖုိ႕လုိသလားဆိုတာေပၚမူတည္ျပီး နည္းနည္းေလာက္ေတာ႔ စဥ္းစားျပီးသံုးၾကပါ။
Regards,
Zero
Max+1 ေရးတဲ႔သူေတြ အရင္တုန္းက ေတာ္ေတာ္မ်ားမွန္းသတိထားမိတယ္။ unique key တစ္ခုကို ရဖုိ႕ ရိွျပီးသား ေဒတာေတြအားလံုးကိုျပန္ဖတ္ျပီး ၁ေပါင္းရတာ ေရးတဲ႔သူအတြက္လြယ္ေပမယ္႔ ေဒတာေဘ႔စ္အတြက္ေရရွည္မွာ မလြယ္ဘူး။ အဲဒီလိုေရးတာပ်င္းတဲ႔သူေတြထင္တယ္။ table ၾကီးေတြ ဝဝဖုိင္႔ဖုိင္႔ျဖစ္လာတဲ႔အခါ Max+1 က ဒုကၡေပးတတ္ပါတယ္။ sequence table လုပ္ျပီး .nextValue နဲ႕သြားပါ။ အင္မတန္ျမန္ပါလိမ္႔မယ္။
sequence တစ္ခုနမူနာျပရရင္ ေဟာသလိုေရးပါတယ္။
CREATE SEQUENCE auto_icrrm_attendance_seq
MINVALUE 1
MAXVALUE 999999999999999999999999999
START WITH 2013000079
INCREMENT BY 1
CACHE 20;
အဲဒီလို create လုပ္ျပီးရင္ ဒီလို သံုးရံုပါပဲ။
select auto_icrrm_attendance_seq.nextval from dual
Cache 20 ေပးထားတာကေတာ႔ memory မွာ အခု ၂၀ တစ္ခါတည္းသိမ္းထားလုိ႕ရေအာင္ oracle ကိုသတိေပးတာပါ။ အဲဒါက နည္းနည္းပိုျမန္ေစပါတယ္။ ကိုယ္လိုခ်င္တာက unique ျဖစ္ရံုပဲလား။ sequence ျဖစ္ဖုိ႕လုိသလားဆိုတာေပၚမူတည္ျပီး နည္းနည္းေလာက္ေတာ႔ စဥ္းစားျပီးသံုးၾကပါ။
Regards,
Zero
xss attack
xss attack
xss attack အတြက္ Java သမားေတြ JSTL သံုးပါ။
အေျခခံကိစၥေတြ နားေအးသြားပါလိမ္႔မယ္။
မဟုတ္ရင္ေတာ႔ secuirty audit လာရင္ ျပင္မဆံုးျဖစ္ေနလိမ္႔မယ္။
Regards,
Zero
xss attack အတြက္ Java သမားေတြ JSTL သံုးပါ။
အေျခခံကိစၥေတြ နားေအးသြားပါလိမ္႔မယ္။
မဟုတ္ရင္ေတာ႔ secuirty audit လာရင္ ျပင္မဆံုးျဖစ္ေနလိမ္႔မယ္။
Regards,
Zero
submit Vs button
submit vs button
Struts မွာ ေတာ္ေတာ္ေလးၾကံဳရတဲ႔တစ္ခုက အဲဒီျပႆနာပဲ။ input type ကုိ submit လုိ႕ေရးျပီး onclick မွာ javascript submitPage စတဲ႔ function ေရးၾကတာေတြ႕တယ္။ အဲဒါ ျပႆနာရိွတယ္။
double submission ျဖစ္ေစႏုိင္သလို၊ parameter passing တစ္ခုခုကို javascript submitPage မွာ set လုပ္ထားရင္ၾကေတာ႔ တစ္ခါတစ္ခါ အဲဒီ parameter set မလုပ္ခင္ submit button ရဲက submit နဲ႕ form က submit ျဖစ္သြားျပီး set လုပ္ရမယ္႔ variable က null ျဖစ္သြားတတ္ပါတယ္။
အဲဒီေတာ႔ အလြယ္ဆံုးနည္းက submitPage လို javascript နဲ႕ form submit လုပ္မယ္လို႕ရည္ရြယ္ရင္ input type ကို button ပဲေပးပါ။ တစ္ျခားအေထြအထူးဘာမွမလုပ္ဘဲ click ႏွိပ္တာနဲ႕ form submit လုပ္ခ်င္မွ input type=submit သံုးပါ။
အဲဒီဟာက ေျပာလုိက္ရင္ အင္မတန္လြယ္တယ္။ ျပႆနာျဖစ္တဲ႔အခါ ရွာၾကည္႕ရင္ေတာ္ေတာ္နဲ႕မေတြ႕ဘူး။ လူမ်ားေတြရဲ႕ အမွားကေန သင္ခန္းစာယူပါ။ ကိုယ္တုိင္မွားၾကည္႕ေနစရာမလိုေတာ႔ဘူးေပါ႔။
Regards,
Zero
Oracle SQL optimization
Oracle SQL optimization
Oracle SQL optimizationနဲ႕ပတ္သက္ျပီး နည္းနည္းေလာက္ေျပာခ်င္တယ္။ background scenerio က ရွင္းရွင္းေလးပဲ။ table တစ္ခုက date ကို minimum function နဲ႕ရွာတာပဲ။ min(attendance_date) ဆိုပါေတာ႔။ အဲဒါကို ဒီအတိုင္းေရးျပီး development database မွာေရာ၊ UAT/QA ေတြမွာေရာအိုေကတယ္။ production မွာၾကေတာ႔ attendance_date မွာက index မေပးထားေတာ႔ ၁၀ နာရီေက်ာ္ၾကာသြားတယ္။ ဒါမ်ိဳးက မျဖစ္ဘူးမေျပာႏုိင္ဘူး။ ျဖစ္တာမ်ားတယ္။ index ေသခ်ာမလုပ္ထားရင္ query လုပ္တဲ႔အခါမွာ oracle က full scanning လုပ္ရတယ္။ အဲဒီမွာ table က ဧရာမၾကီးျဖစ္ေနရင္ query တစ္ေၾကာင္းခ်င္းစီအတြက္ အခ်ိန္က သိပ္ၾကာသြားတတ္တယ္။ အေကာင္းဆံုးကေတာ႔ attendance_date အပါအဝင္ query criteria ေတြကို index ေပးလိုက္တာပဲေပါ႔။
အဲဒီကိစၥကို သံုးေလးငါးရက္ research လုပ္ၾကည္႕တယ္။ oracle မွာက index အမ်ိဳးမ်ိဳးေဆာက္ထားျပီး ကိုယ္သံုးခ်င္တဲ႔ index ကို hint ေပးလုိ႕ရတယ္။
ေနာက္တစ္ခုက ကိုယ္ေရးလုိက္တဲ႔ query ေတြကို Explain Plan လုပ္ၾကည္႕ၾကဖုိ႕ပါ။ အဲဒါဆိုရင္ ေတာ္ရံုတန္ရံု အမ်ားၾကီးၾကီးေတြ မွားစရာသိပ္မရိွေတာ႔ဘူးေပါ႔။
ေနာက္တစ္ခုက သိပ္ကို ေႏွးေကြးေလးလံျပီး ဒုကၡေပးေနတဲ႔ query ေတြကို DBA privilage နဲ႕ဒီလိုရွာၾကည္႕လို႕ရပါတယ္။
SELECT * FROM (SELECT * FROM v$sql ORDER BY cpu_time DESC) WHERE ROWNUM <= 250;
ဒါဆိုရင္ cpu_time အၾကာဆံုး ထိပ္သီး ၂၅၀စာရင္းရပါမယ္။ အဲဒီထဲကမွ ကိုယ္႔ကို ဒုကၡေပးေနတဲ႔ query ကိုရွာၾကည္႕ရင္ေတြ႕ႏုိင္ေလာက္ပါတယ္။
ေနာက္တစ္ခုကေတာ႔ ဘယ္ယူဆာအေကာင္႔ထ္ေတြနဲ႕ကိုယ္႔ database ကိုလာခ်ိတ္ထားသလဲဆိုတာကို session ကိုၾကည္႕ျပီးသိႏုိင္ပါတယ္။
SELECT * FROM v$session WHERE ROWNUM < 250;
index ေတြနဲ႕ပတ္သက္ျပီး rule ေတြရိွပါေသးတယ္။ အၾကမ္းဖ်င္းေျပာရင္ေတာ႔ index ထည္႕လုိက္ရင္ select query ေတြျမန္ျပီး update နဲ႕ insert နဲ႕ေႏွးသြားတတ္ပါတယ္။ ကိုယ္႔ရဲ႕ system ေပၚမူတည္ျပီး အလြန္အကြ်ံမျဖစ္ေအာင္သတိထားျပီးသံုးၾကရတာပါပဲ။
ကိုယ္ၾကံဳလိုက္တာတစ္ခုကို အမွတ္တရအေနနဲ႕ျပန္ေရးလုိက္တာပါ။ သိျပီးသားဆိုရင္ ပိုမွတ္မိေအာင္၊ မသိေသးရင္ သတိထားဖုိ႕။ အဲဒီေလာက္ပဲရည္ရြယ္ပါတယ္။
ref:
http://docs.oracle.com/cd/B19306_01/server.102/b14211/hintsref.htm
Regards,
Zero
Oracle SQL optimizationနဲ႕ပတ္သက္ျပီး နည္းနည္းေလာက္ေျပာခ်င္တယ္။ background scenerio က ရွင္းရွင္းေလးပဲ။ table တစ္ခုက date ကို minimum function နဲ႕ရွာတာပဲ။ min(attendance_date) ဆိုပါေတာ႔။ အဲဒါကို ဒီအတိုင္းေရးျပီး development database မွာေရာ၊ UAT/QA ေတြမွာေရာအိုေကတယ္။ production မွာၾကေတာ႔ attendance_date မွာက index မေပးထားေတာ႔ ၁၀ နာရီေက်ာ္ၾကာသြားတယ္။ ဒါမ်ိဳးက မျဖစ္ဘူးမေျပာႏုိင္ဘူး။ ျဖစ္တာမ်ားတယ္။ index ေသခ်ာမလုပ္ထားရင္ query လုပ္တဲ႔အခါမွာ oracle က full scanning လုပ္ရတယ္။ အဲဒီမွာ table က ဧရာမၾကီးျဖစ္ေနရင္ query တစ္ေၾကာင္းခ်င္းစီအတြက္ အခ်ိန္က သိပ္ၾကာသြားတတ္တယ္။ အေကာင္းဆံုးကေတာ႔ attendance_date အပါအဝင္ query criteria ေတြကို index ေပးလိုက္တာပဲေပါ႔။
အဲဒီကိစၥကို သံုးေလးငါးရက္ research လုပ္ၾကည္႕တယ္။ oracle မွာက index အမ်ိဳးမ်ိဳးေဆာက္ထားျပီး ကိုယ္သံုးခ်င္တဲ႔ index ကို hint ေပးလုိ႕ရတယ္။
ေနာက္တစ္ခုက ကိုယ္ေရးလုိက္တဲ႔ query ေတြကို Explain Plan လုပ္ၾကည္႕ၾကဖုိ႕ပါ။ အဲဒါဆိုရင္ ေတာ္ရံုတန္ရံု အမ်ားၾကီးၾကီးေတြ မွားစရာသိပ္မရိွေတာ႔ဘူးေပါ႔။
ေနာက္တစ္ခုက သိပ္ကို ေႏွးေကြးေလးလံျပီး ဒုကၡေပးေနတဲ႔ query ေတြကို DBA privilage နဲ႕ဒီလိုရွာၾကည္႕လို႕ရပါတယ္။
SELECT * FROM (SELECT * FROM v$sql ORDER BY cpu_time DESC) WHERE ROWNUM <= 250;
ဒါဆိုရင္ cpu_time အၾကာဆံုး ထိပ္သီး ၂၅၀စာရင္းရပါမယ္။ အဲဒီထဲကမွ ကိုယ္႔ကို ဒုကၡေပးေနတဲ႔ query ကိုရွာၾကည္႕ရင္ေတြ႕ႏုိင္ေလာက္ပါတယ္။
ေနာက္တစ္ခုကေတာ႔ ဘယ္ယူဆာအေကာင္႔ထ္ေတြနဲ႕ကိုယ္႔ database ကိုလာခ်ိတ္ထားသလဲဆိုတာကို session ကိုၾကည္႕ျပီးသိႏုိင္ပါတယ္။
SELECT * FROM v$session WHERE ROWNUM < 250;
index ေတြနဲ႕ပတ္သက္ျပီး rule ေတြရိွပါေသးတယ္။ အၾကမ္းဖ်င္းေျပာရင္ေတာ႔ index ထည္႕လုိက္ရင္ select query ေတြျမန္ျပီး update နဲ႕ insert နဲ႕ေႏွးသြားတတ္ပါတယ္။ ကိုယ္႔ရဲ႕ system ေပၚမူတည္ျပီး အလြန္အကြ်ံမျဖစ္ေအာင္သတိထားျပီးသံုးၾကရတာပါပဲ။
ကိုယ္ၾကံဳလိုက္တာတစ္ခုကို အမွတ္တရအေနနဲ႕ျပန္ေရးလုိက္တာပါ။ သိျပီးသားဆိုရင္ ပိုမွတ္မိေအာင္၊ မသိေသးရင္ သတိထားဖုိ႕။ အဲဒီေလာက္ပဲရည္ရြယ္ပါတယ္။
ref:
http://docs.oracle.com/cd/B19306_01/server.102/b14211/hintsref.htm
Regards,
Zero
Monday, April 1, 2013
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
ျဖစ္ေလ႔ျဖစ္ထရိွတဲ႔ျပႆနာတစ္ခုပါ။
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
Thursday, February 7, 2013
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)
ဒီလိုေမးရင္ေတာ့ 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
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
Wednesday, December 12, 2012
Wednesday, November 7, 2012
Oracle 11g R2 RAC Essentials SLA for availability
Wednesday, August 1, 2012
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
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
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, May 22, 2012
Jasper Reports
Jasper Reports
iReport Designer ေလးနဲ႕ Report ေလးတစ္ေခုေလာက္လုပ္ၾကည္႕ဖုိ႕ေကာင္းပါတယ္။ JasperSoft ကေန download လုပ္ႏုိင္ပါတယ္။
Java ရဲ႕ ျပႆနာက jdk version ေတြ တစ္ခုနဲ႕တစ္ခု အဆင္ေျပဖုိ႕ သတိထားရတာျဖစ္ပါတယ္။ iReport မွာ ဘယ္ Jre version သံုးသလဲသိခ်င္ရင္ About မွာၾကည္႕လုိက္လုိ႕ရပါတယ္။
jrxml ဆိုတဲ႔ template design ေလးကို compile လုပ္လုိက္ရင္ .jasper ဆုိတဲ႔ complied class file ထြက္လာပါတယ္။
iReport ရဲ႕ default jre ကို configure လုပ္ခ်င္ရင္ etc folder ေအာက္က config file မွာ jdk home ျပင္လုိ႕ရပါတယ္။
iReport မွာ Add parameter ထည္႕ျပီး အဲဒီ parameter ေတြကို text box မွာ ျပန္တြဲလုိက္ရင္ parameter ေပၚမူတည္ျပီး report ထုတ္လုိ႕ရပါျပီ။ preview ၾကည္႕လုိက္ရင္ parameter value ေတြ ေတာင္းတာကို ေတြ႕ရပါလိမ္႔မယ္။
အဲဒီလို report တစ္ခုလုပ္ျပီးရင္ java servlet တစ္ခုကေနျပီး အဲဒီ report ကို လွမ္းေခၚသံုးလုိ႕ရပါျပီ။
web server မွာ deploy လုပ္တဲ႔အခါမွာ groovy jar, iText jar နဲ႕ common collection jar ေတြလုိပါလိမ္႔မယ္။
Java ဘက္မွာေတာ႔ Report အတြက္ jasper အသံုးမ်ားပါတယ္။ Elixir လည္းသံုးပါတယ္။ .Net ဘက္မွာေတာ႔ Crystal Report ကို အသံုးမ်ားပါတယ္။ အားလံုးရဲ႕တူညီခ်က္ကေတာ႔ သပ္ရပ္လွပတဲ႔ output file ရႏိုင္တာျဖစ္မယ္ထင္ပါတယ္။ pdf , doc, xls စတဲ႔ output files ေတြ ထုတ္ဖုိ႕ အသံုးျပဳပါတယ္။ report ဟာ software development မွာ အင္မတန္ အေရးပါပါတယ္။
Report ကို Application မွာ တခါတည္း ထည္႕ေရးတာရိွသလို၊ Report Engine ကို Server တစ္လံုးမွာ run ထားျပီး url နဲ႕ Parameter List ပို႕ျပီးသံုးတာမ်ိဳးလည္းရိွပါတယ္။
ဒါကေတာ႔ ဗဟုသုတအျဖစ္ေျပာရံုျဖစ္တဲ႔အတြက္ ဘာ sample code မွမပါပါဘူး။ နားလည္လြယ္မယ္လုိ႕ေမွ်ာ္လင္႔ပါတယ္။ ကိုယ္တုိင္ လုပ္ၾကည္႕လုိက္တာပိုေကာင္းပါတယ္။ မ်ားမ်ားသိျပီး နမူနာတစ္ခုစီေလာက္ လုပ္ဖူးထားရင္ လြယ္ပါတယ္။
Regards,
Zero
Notes: ဒါကေတာ႔ အဆစ္ေပးတာပါ။
Recurrsion နဲ႕ Looping အေၾကာင္း။
Subscribe to:
Posts (Atom)