在 Proxmox 主機上執行社群腳本之前：先讀這五件事

社群腳本確實很好用。這些腳本承載著某人用許多白白耗掉的夜晚換來的經驗，處理了半夜才會撞上的棘手情況，而且在許多工作上，腳本寫得比自己動手寫的還要好。本文並不是在反對社群腳本。

本文談的是一個特定的落差。用套件安裝和貼上一行腳本安裝，在畫面上看起來同樣稀鬆平常，但兩者根本不是同一回事。

套件能提供，貼上的一行指令卻提供不了的東西

簽章。套件經過簽署，而且簽章會被檢查。URL 唯一經過的檢查，只是使用者假設這個 URL 是對的。

版本。能明確說出目前裝的是哪個版本，協助排查問題的人也說得出來。幾週前照著 readme 抓下來的那個腳本，算不上是一個版本。

解除安裝的途徑。套件會記錄放了哪些東西，也能把它們移除。腳本常常把檔案放在六個地方，事後卻完全不記得做過這些事。

與維護者的關係。套件改變行為時會有變更記錄。腳本則可能在同一個 URL 底下改變，卻沒有任何東西可讀。

這些都不代表腳本不好。只代表腳本是另一種東西，值得用另一種習慣對待。

該讀的五件事

不必讀完整個腳本，也不必逐行細讀。這五個答案通常讀過一遍就看得出來。

① 它會動到自身目錄以外的哪些地方？只在自己資料夾底下寫入的腳本，行為很容易推斷。會修改系統設定目錄底下檔案的腳本，做出的變更在腳本結束之後仍會一直留著。

② 它會不會新增套件庫或金鑰？這是多數腳本裡後果最重大的一行，卻在一秒內就閃過去。新增套件來源，代表那台機器往後的每一次更新都會信任一個新的對象。這可能完全合理，但應該是一個決定，而不是副作用。

③ 它會不會動到開機、核心或網路？這三項可能讓主機連不上或開不了機，而在虛擬化主機上，這代表上面的一切都會跟著停擺。安裝網頁應用程式的腳本沒有理由修改開機載入程式的設定，如果它真的這麼做，值得在執行前先弄清楚原因。

④ 有沒有回頭路？先找找看有沒有解除安裝的途徑，沒有的話，至少找一份它建立了哪些東西的清單。兩者都沒有時，回頭路就是事先建立的快照，也就是說，必須自己先建立一個。

⑤ 執行兩次會怎樣？許多腳本是為乾淨的機器而寫，重新執行會造成項目重複、重設已手動修改過的設定，或是執行到一半失敗，留下半套的狀態。遲早會有執行第二次的時候，通常是因為第一次看起來像是失敗了。

特別談談貼上的一行指令

把抓下來的腳本直接以管線送進 shell 執行，這種做法有一個值得點明的特性：執行過的東西根本無法讀到。不是沒有讀，而是無法讀，因為它從來就不是一個檔案。

還有一種更隱微的情況。在瀏覽器裡閱讀腳本，和執行抓取後導向 shell 的指令，是兩次各自獨立的請求。沒有任何機制保證兩次拿到的是相同的位元組。

解法只多一個步驟。先下載檔案，看過內容，再執行本機上的副本。這樣就知道實際執行了什麼，之後可以再執行一模一樣的東西，萬一出了問題，手上也有真正的文字可以查看，而不是對某個網頁的模糊記憶。

虛擬化主機不是用來嘗試的地方

這正是 Proxmox 主機和筆電的不同之處。機器上的其他一切都建立在它之上。一個腳本把筆電弄成奇怪的狀態，損失的是一個晚上；同一個腳本放在主機上，會把每一台虛擬機器一起拖下水。

有兩個習慣，幾乎能讓這一切都變得安全：

只要可行，先在虛擬機器裡執行。大多數安裝服務的腳本根本不需要放在主機上。這不是權宜之計，通常那才是正確的位置。

如果真的必須在主機上執行，先建立快照。不是因為腳本可疑，而是因為一句先試試看再說，往往正是事後需要回頭路的開端。

本文不是在說什麼

不是要對社群失去信任。大家分享的腳本是這個生態系最好的部分之一，而且作者通常比執行腳本的人更謹慎。

也不是要逐行閱讀。讀一遍、問五個問題，就足以抓出真正會造成傷害的那類意外。

Atlas 的做法

Atlas 在會變更主機狀態的操作之前先建立快照，因此回頭路一直都在，不必靠記性去建立。這涵蓋了上面清單的第四項，也就是大家最常跳過的那一項。

稽核記錄會記下誰在何時、對什麼執行了什麼，以及結果如何，讓上週二好像有什麼變了的疑問，變成一個讀得懂的答案，而不需要一場調查。

資源鏈幫助的是事後，而不是決策：安裝之後若有東西的行為不一樣，地圖會顯示機器現在實際的樣子，從客體一路到實體磁碟。

而 Atlas 自己透過應用程式目錄安裝軟體時，版本是固定的，來源是固定的，安裝開始之前也會建立還原點。這是一條刻意收窄、經過挑選的路徑，並不取代社群腳本。它只是把同樣的五個問題，針對它所提供的應用程式事先回答好。