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 /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

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

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 ကိုၾကည့္ရင္

$ 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

Spring Framework

Spring Framework အေၾကာင္းေလ႔လာခ်င္တဲ႔သူေတြအတြက္ လြယ္ကူသက္သာတဲ႔စာအုပ္ေလးသတင္းေပးခ်င္လုိ႕ပါ။ အခုလည္းဖတ္ေနပါတယ္။ လုိင္ဘရီက ငွားဖတ္ျပီးၾကိဳက္လုိ႕၀ယ္လုိက္ပါတယ္။ ၄၇ SGD ပဲေပးရပါတယ္။ Spring, A Developer's Notebook. ျဖစ္ပါတယ္။ Oreilly ကထုတ္တာပါပဲ။

၂၀၀၅ April ကထုတ္ပါတယ္။ နည္းနည္းေလးေတာ႔ ေနာက္က်ေနပါျပီ။ ဒါေပမယ္႔ ေတာ္ေတာ္ေလးေကာင္းပါတယ္။

Agile Development စာအုပ္နဲ႕ ဒီစာအုပ္ႏွစ္အုပ္ထဲကဘာယူမလဲေသခ်ာေတြးျပီးေရြးလုိက္တာပါ။ ဟိုစာအုပ္က ၂၀၀၆ မွာထုတ္တာပါ။ ေစ်းက 57 SGD ပါ။ အဲဒီတစ္အုပ္ကေတာ႔ သီအိုရီနည္းနည္းပိုမ်ားပါတယ္။ အခုစာအုပ္ေလးကေတာ႔ အခ်င္းခ်င္းေျပာျပထားသလိုေရးထားေတာ႔ပိုအဆင္ေျပမယ္ထင္ပါတယ္။

Developer ေကာင္းျဖစ္ခ်င္ရင္ အလုပ္မ်ားမ်ားလုပ္စရာမလိုပါဘူး။ မ်ားမ်ားဖတ္ျပီး နည္းနည္းေလာက္ စမ္းၾကည္႕ဖုိ႕ပဲလိုပါတယ္။ လုပ္တတ္ရင္ရပါျပီ။ေႏွးတာျမန္တာေတြက skills ပါ။ knowledge ရိွရင္ skill ကိုျဖည္႕ဖုိ႕ကလြယ္ပါတယ္။

ေရးတဲ႔သူႏွစ္ေယာက္က Bruce A.Tate နဲ႕ Justin Gehtland ပါ။

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

ေနာက္ထပ္ Level ဟာ Architect ျဖစ္တဲ႔အတြက္ ... ဒါေတြကို မေလ႔လာရင္ ေပါေတာေတာ Architect ပဲျဖစ္လာပါမယ္။ Developer ပဲျဖစ္ျဖစ္ Architect ပဲျဖစ္ျဖစ္ foundation ခုိင္ခံ႕ဖုိ႕လိုပါတယ္။

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

တစ္ခါတစ္ေလ အေသးစိတ္ေရးဖုိ႕ အခ်ိန္ကမရိွတဲ႔အတြက္ စာအုပ္ညႊန္းလုိက္ပါတယ္။

ဖတ္တာျပီးသြားရင္လည္း အေရးၾကီးတဲ႔အခန္းေတြအေၾကာင္းသံုးသပ္ခ်က္ေရးျဖစ္ပါမယ္။

Regards,

Zero

IT Trends

ေရးခဲ့ဖူးတယ့္ စာေတြ အားလုံးကို ျပန္စုထားခ်င္လို႕ ဒီ post ကို ဒီမွာပါျပန္တင္လိုက္ပါတယ္။ Post အေနနဲ႕ဆို သိပ္ရွည္လို႕ pdf ကိုပဲတင္လိုက္ပါတယ္။
လြန္ခဲ့တယ့္ တစ္ႏွစ္ေက်ာ္ June 2009 က က်ေနာ္ Mystery Zillions မွာေရးခဲ့တယ့္ ေဆာင္းပါးပါ။ က်ေနာ့ရဲ့ ပထမဆုံးေသာ ျမန္မာစာကို ရွည္ရွည္ေရးတယ့္ post တစ္ခုေပါ့။ IT career ဘာေရြးရမွန္းမသိဘူး ဆိုတယ့္သူေတြအတြက္၊ ေရြးခ်ယ္ထားတယ့္လမ္းမွာ ဘယ္လို အဆင့္ေတြရွိမလည္းဆိုတာ နည္းနည္းေလာက္ ေတြးမိသြားေအာင္ေရးခဲ့တာပါ။ ျမန္မာစာကို ကိုစိုးမင္းၾကီးရဲ့ Burglish.com ကေန ႐ိုက္ခဲ့တာမို႕၊ စာလုံးေပါင္းအမွားေတြ အမ်ားၾကီးျဖစ္ေနပါတယ္။ ( အခုလည္း burglish သုံးေနတုန္းပါ၊ စာလုံးေပါင္းအမွားနည္းလာတာပဲရွိတယ္ ၊ ) ဒီ post ကို pdf ျပန္လုပ္ျပီး တင္ေပးခဲ့တယ့္ ကိုရသာကိုလည္း ေက်းဇူးတင္ပါတယ္။

PDF ကို ဒီမွာ download ပါ

Thanks
Divinity

Effective Java

အခု Effective Java ဖတ္ေနပါတယ္။

ဒီေန႕ အေရးၾကီးတာႏွစ္ခု သံုးခုျပန္ေျပာလုိက္ပါတယ္။

Developer ေတြသတိထားရမွာေတြပါ ....။

No.1

Collection ေတြကို raw type မသံုးပါနဲ႕။ အဲဒါက run time error ျဖစ္ေစႏိုင္တဲ႔အတြက္ ..ေနာက္မွေခါင္းမကိုက္ခ်င္ရင္ ေစာေစာကတည္းက Type ကို Define လုပ္ပါ။

N0.2

Parameters အခု ၁၀၀ နဲ႕ method ေတြ မေရးပါနဲ႕။ ျဖစ္ႏုိင္ရင္ Bean တစ္ခုလုပ္လုိက္ပါ။ Bean ကိုပဲ ပို႕လုိက္ပါ။ ပိုေကာင္းတဲ႔နည္းလမ္းက Builder သံုးတာပါ။

No.3

Garbage colletion ကို သတိျပဳပါ။ သံုးျပီးရင္ ဒီအတုိင္းမထားခဲ႔ပါနဲ႕။ အိမ္သာတက္ျပီးေရေလာင္းရသလို သံုးျပီးသား object တိုင္းက ပစ္မထားခဲ႔ပါနဲ႕။ Memory leakage ျဖစ္လာတဲ႔အခါ အသံုးမက်တဲ႔ Developer ျဖစ္သြားတတ္ပါတယ္။ ျဖစ္ႏိုင္ရင္ သူ႕ဘာသာသူ garbage collection လုပ္တဲ႔ Java ပဲ ... သူ႕အလုပ္သူလုပ္ပါေစ ဆုိျပီး မလုပ္ပါနဲ႕ ..ျဖစ္ႏိုင္ရင္ ကိုယ္႔ဘာသာကိုယ္ပဲ null ပစ္ပါ။ Null pointer ေတြၾကံဳရတာက Memory Leakage ထက္ ေျဖရွင္းရ ျမန္ပါတယ္ ...။ ေနာက္ပိုင္းမွာ အက်င္႔လုပ္ထားရင္ အသားက်လာပါလိမ္႔မယ္။ Excepiton ကိုလည္း throw Exception လုပ္ပါ။ ၾကိတ္ျပီးဟိုဟာျပင္ ဒီဟာျပင္မလုပ္ပါနဲ႕။ Java ကို သူ႕သဘာ၀ကေန မကင္းကြာပါေစနဲ႕။

စာအုပ္ကိုလည္း upload လုပ္ထားေပးပါမယ္။

အားတဲ႔အခါ ဖတ္ၾကပါ။ စာမဖတ္ဘဲ ရမ္းလုပ္ေနတာ ေရရွည္မွာ ကိုယ္႔ေသတြင္းကိုယ္တူးေနတာမ်ိဳးျဖစ္လာပါမယ္။ သက္သာခ်င္ရင္ လူမ်ားထက္ သိေအာင္လုပ္ထားပါ။

တစ္ခ်ိန္ခ်ိန္မွာ Java ေရးၾကမယ္႔

ညီငယ္ညီမငယ္မ်ားအတြက္ ...

Zero

Oracle SQL developer

http://st-curriculum.oracle.com/tutorial/SQLDeveloper/index.htm

အခုတေလာ ရံုးမွာ စာပဲထုိင္ဖတ္ေနရလုိ႕ … ပ်င္းေနတာနဲ႕ Oracle SQL developer သံုးရင္ အလြယ္ေလးေတြ သံုးလုိ႕ရတဲ႔ manual တစ္ခုဖတ္ျဖစ္ပါတယ္။ သိျပီးသားေတြေပမယ္႔ IDE သံုးတဲ႔အခါ သိထားရင္ ပိုေကာင္းပါတယ္။ setup က ၁၅ မိနစ္ေလာက္နဲ႕ ဖတ္ၾကည္႕တာက နာရီ၀က္ေလာက္ပါပဲ ….။ အပ်င္းေျပ လုပ္ၾကည္႕ေစခ်င္ပါတယ္။ အလကားေပးတဲ႔ oracle client ေတြထဲမွာေတာ႔ အေတာ္ေလးသေဘာက်ပါတယ္။

Java နဲ႕ပတ္သက္တာေတြလည္း အမ်ားၾကီးေရးထားျပီး မျပီးေသးဘူးျဖစ္ေနလုိ႕မတင္ျဖစ္ပါဘူး။

ရံုးမွာက blog ေတြကိုဖတ္လုိ႕ပဲရပါတယ္။ ဒီေန႕မွ၀င္လို႕ရပါတယ္။ အခုေရးေနတာကေတာ႔ အိုနာေသဂ်ာဗားနဲ႕ … Effective Java ထဲက တစ္ခ်ိဳ႕မွတ္သားစရာေလးေတြပါ။

သႏိၲတအားျဖင္႔ (With Peace In Pali)

Zero

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