科技新知
Ubuntu 的簡易日常更新
早陣子跟新認識的朋友聊天，聽到他們因為要轉伺服器平台，煩惱如何做作業系統層面的定期更新。筆者亦都分享一下自己是如何做 Ubuntu OS 層面的定期維護。
沒錢，就用最原始的方式解決
因為Ubuntu也算是常見的linux品牌，所以基本有有商用軟件可以偵測OS的狀態，並針對它推送更新。不過如果你像筆者一樣，是個貧窮的革命家，那就只有土炮一點自己做鏡像點及做測試。
- 建立一個 ubuntu 的 deb 包 mirror。手動單次地用步 mirror，確保自己其他 server 同一個時間段都只會取得同一個更新。
- 停了 ubuntu 的 kernal 自動更新。不然的話，mirror 有更新，ubuntu 亦會偷偷地自動安裝了新的kernal，只是等待你的重啟。
- 使用一個測試機，先經 mirror 更新到最新的狀態。運行一段日子後，其他機再陸續更新。如果你投産環境有多於一種配置，就考慮要多個不同的測試機。更新指令直接做成 script，方便在其他機器中重複。
- 輪流 ssh 登入各台機，執行相同的更新指令。更新指令經 git 同步到其他機器。為確保不受 ssh 斷線的風除，必要時還需加入 tmux 。
多機器的煩惱
上述的做法雖然可行，不過當你有十台以上的機器，重複做 ssh, tmux, git checkout, script 互動，也是很累人。考慮一次性地全自動化執行，還是有必要的。筆者對上述的第四步驟，作出一些取捨，以確保更新速度足夠快，可以順暢地執行。
什麼是必需要更新的？
筆者觀察到，在 container 技術出現後，其實很多時安裝應用都不會直接在 OS 層安裝 deb / rpm 包，都是直接經 docker image 去做。所以OS層面，或者很多服務都不會被啟動。筆者亦發現，至少在ubuntu下，只更新kernel，對比無腦全更新所有 deb 包，會快很多很多。
如果可以，我們只更新kernel，再加對應的 container runtime，是不是更新對令相對地穩定，而且可以經外部統一管理。也就是不用在每一台機中進行 tmux + git checkout ，全數在外部推送 ssh 指令？
筆者就用 multipass VM + ssh key，表達一下執行概念。
ssh -i /var/snap/multipass/common/data/multipassd/ssh-keys/id_rsa ubuntu@10.115.189.200 -- apt-get autoremove -y
ssh -i /var/snap/multipass/common/data/multipassd/ssh-keys/id_rsa ubuntu@10.115.189.200 -- apt-get update
ssh -i /var/snap/multipass/common/data/multipassd/ssh-keys/id_rsa ubuntu@10.115.189.200 -- apt-get install -y linux-generic linux-headers-generic linux-image-generic
ssh -i /var/snap/multipass/common/data/multipassd/ssh-keys/id_rsa ubuntu@10.115.189.200 -- reboot
上述最大的假設，是第一、三步，更新 kernel 時不會因為網絡問題導致 ssh 斷線，因為它們都是系統級別的改寫，中斷後並不能確保可以重來。第二步就很安全，隨時重來也沒有問題。
這樣，我們就可以在任一台管理機，經過一個 shell script for loop，更新所有其他機器。
如果我們對於網絡還是有些疑慮，我們也可以試用一次性排程式的方式去做。
ssh -i /var/snap/multipass/common/data/multipassd/ssh-keys/id_rsa ubuntu@10.115.189.200
echo '/your/script/location' | at 08:00 PM 17.12.2025
這樣的好處是，我們可以連 tmux 的開啟也省略，git checkout 也可以經固定的 script 執行（只是很煩鎖）。但這也會有壞處，就是看不到執行的情況，只能事後檢查系統狀態，是否已更新過。
當然前述 ssh key 的方法也可以加入 git checkout 更加深化不同的更新 script，但這又會增大斷線可能。ssh key 還是以快速完成指令更實際。
註：因為網安原因，筆者把上述 script 中的 S U D O 關鍵字去掉，這樣 blog 才能發出。
