2019年2月21日 星期四

[經驗分享]LibreNMS 更新 PHP 7.2 問題與解決方法



LibreNMS 自 2019 二月起,由於 PHP 自己都已經放棄對 5.6 與 7.0 版的支援,因此 LibreNMS 開始要求使用者必須把 PHP 版本更新到 7.1 以上,這表示我原本 PHP 7.0 版也需要進行更新。在沒有更新至 7.1 以上前,LibreNMS 的更新將無法繼續。







更新 PHP 版本

我的作業系統發行版本是 Ubuntu 16.04,要更新 PHP 至 7.2 時需要做點手工。
Ubuntu 準備更新至 PHP 7.2
sudo add-apt-repository ppa:ondrej/php
sudo apt update

Debian 準備更新至 PHP 7.2
sudo apt install apt-transport-https lsb-release ca-certificates
sudo wget -O /etc/apt/trusted.gpg.d/php.gpg https://packages.sury.org/php/apt.gpg
sudo sh -c 'echo "deb https://packages.sury.org/php/ $(lsb_release -sc) main" > /etc/apt/sources.list.d/php.list'
sudo apt update


更新完成後,請繼續安裝相關套件,您缺少的不一定會跟我這邊呈現的一樣,但可依此執行。
安裝 PHP 擴充套件
apt install php7.2 php7.2-common php7.2-cli php7.2-fpm
apt install php7.2-mysqlnd 
apt install php7.2-curl 
apt install php7.2-gd
apt install php7.2-zip






更新 LibreNMS 版本

接下來,即可以 daily.sh 將 LibreNMS 進行更新。

不過我的情況是更新完成後,開啟網頁會產生 http 500 錯誤,查看 Librenms 的 log 發現以下訊息:

登入 LibreNMS 錯誤
2019/02/13 10:20:29 [error] 7983#7983: 
  *74 FastCGI sent in stderr: "
  PHP message: PHP Parse error: syntax error, 
  unexpected '=' in /opt/librenms/vendor/laravel/framework/src/Illuminate/Support/Arr.php on line 388" 
  while reading response header from upstream, 
  client: 123.123.123.123, server: xxx.xxx.com.tw,
  request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/var/run/php/php7.0-fpm.sock:", 
  host: "xxx.xxx.xxx.tw" 


問題是出在 PHP 更新版本以後,原本 php7.x-fpm.sock 的位置已經不同,現在更完成的服務所執行是 7.2,我們可以用指令確認一下服務。

查看 php-fpm 服務狀態
service php7.2-fpm status   

依據狀態中顯示的 php7.2-fpm 設定檔位置,前往查看內容。

查看 php7.2-fpm 服務狀態



接著依據 php-fpm.conf 設定檔,內容再追往 pool.d/ 下的設定檔查看。

查看 php-fpm.conf 設定


查看 pool.d/*.conf 設定


來到這裡確認了新版 php7.2 的 .sock 檔名已經改變,成為 /run/php/php7.2-fpm.sock








修正 LibreNMS Web 設定

既然已經知道問題,即可對症下藥,首先開啟 /etc/nginx/conf.d/librenms.conf 這個設定檔,若您是 apache,請開啟相對應的設定檔即可。

開啟後,找到 php-fpm 的相關設定處。

修改 Librenms Web 設定


將上圖中原本為 php7.0-fpm.sock 修改為 php7.2-fpm.sock,存檔離開後重新啟動 nginx / apache 服務,即可生效。







結論

LibreNMS 更新頻繁,當出現錯誤時切莫驚慌,通常會在 Web 介面出錯時同時顯示解決方案。若是比較嚴重連 Web 都無法出來的情況,來到 Log 檔中也會顯示相關線索,讓我們能夠以此為引,找到解決問題的方法。

同時提醒,更新至 PHP 7.2 以後,原本如有設定過 PHP 時區者,仍然需要重新修改 php.ini 一次。






參考資料



2019年2月20日 星期三

[專案分享]netdata 繁體中文化更新檔



netdata 是非常實用且即時的效能監視套件,對於每項效能指標不僅標示用途,更詳細說明造成的原因以及影響,只可惜這麼棒的說明全都是英文,所以....我動了點手腳。

目前 netdata 尚未支援多語系的架構,因此我是直接修改相關檔案,目前已經中文化較常見的部份。期待之後的版本可以加入多語系架構,將可以造福更多的朋友。






使用效果

請至 GitHub 專案下載檔案,覆蓋後再重新整理網頁即可生效,細節請參考專案的說明文件。

套用以後的成果如下:

KSM & NUMA


容器


設定




參考資料




2019年2月18日 星期一

[經驗分享]淺談 Proxmox VE 版本更新與授權模式



Proxmox VE 是一款功能齊全的開源虛擬化平台,在推廣的過程中,最常被問到的其中一個問題是:「為什麼這麼好的東西,竟然免費?

這是一個很有趣的議題,今天就讓我們來談談關於 Proxmox VE 的授權模式。






授權條款

Proxmox VE 軟體授權條款,採用的是 GNU AGPL (Affero General Public License) 條款,而 Proxmox VE 本身是 Free Software 自由軟體,也是 Open Source Software 開源軟體。

Proxmox VE 官方授權說明


這表示 PVE 是讓所有人都可以無償取得使用,包括原始程式碼,對於標準的「使用者」而言,並不需要付費給 PVE 開發團隊即可進行使用。

若您對於 PVE 進行程式碼修改,依據授權條款,您必須將您修改的部份也公開原始碼。

然而自由軟體與開源軟體並不等於免費,這件事必須特別說明。軟體使用不須付費,但可以是經由其它模式而進行收費,例如技術支援、版本更新等等,知識無價,但服務有價,不是只有單純的買賣產品才能是軟體盈利的唯一模式,例如 RedHat 紅帽公司運用 RedHat 自由軟體系統,提供企業客戶資訊服務而非賣 RedHat 系統軟體,就是一個經典的成功案例。





更新版本

同樣的,您可以在無需支付費用的情況下使用 PVE 軟體,毫無疑問。除了登入畫面出現您沒有付費授權金鑰以外,使用起來並沒有任何限制與功能差異。

登入時提醒目前沒有付費授權資訊



但是,如果您在使用上需要更新 PVE 版本,就可能遇到這個問題:

更新 PVE 時發生錯誤


這個情況,是因為預設安裝完成的 PVE 是連接到 Enterprise Repository 的更新來源,而您沒有付費取得授權金鑰因此無法更新。

解決辦法容易,您可以將 PVE 的更新來源切換為 No-Subscription Repository 或 Test Repository,即可順利更新。

請以文字編輯器開啟 /etc/apt/sources.list,並加入以下這行。
切換更新來源為 No-Subscription Repository
deb http://download.proxmox.com/debian/pve stretch pve-no-subscription

再將原本的 Enterprise Repository 給取消,請以文字編輯器開啟 /etc/apt/sources.list.d/pve-enterprise.list,將它註解。
取消 Enterprise Repository 更新來源
# deb https://enterprise.proxmox.com/debian/pve stretch pve-enterprise




這三種更新來源的差異,說明如下:
  • Enterprise Repository
    預設更新來源,提供給付費授權並取得金鑰的客戶更新使用。這個更新來源的特點是提供最穩定的版本,適合已經正式上線的環境使用。
     
  • No-Subscription Repository
    顧名思義,這個更新來源不需取得付費後的授權密鑰即可用來更新。官方建議將此更新來源用在測試與非正式上線的環境,因為部份套件可能還未經過大量的測試與驗證。不過在我的經驗裡,它非常的穩定。
     
  • Test Repository
    這個更新來源包含最新版本的套件包,開發團隊大量使用它來測試新功能。這個更新來源最好只用於測試新功能或是除錯,絕對不要使用在正式環境





服務模式

若您想要使用 Enterprise Repository 做為更新來源,或是需要原廠的技術支援,就需要付費才可取得相關管道與服務。

Proxmox VE 提供了多種的模式,可以依據您的使用情況做選擇。



Proxmox VE 收費模式表


這幾種收費模式,都是以年與 CPU 插槽數來做計價單位,因此您可以很容易的計算出您需要的數量為何。

四種級別都可以使用 Enterprise 更新來源、全部功能、技術支援,差異部份說明如下:

  • PREMIUM
  • 提供專用客戶支援服務窗口
  • 不限制技術支援請求數
  • 提供上班日 2 小時內的回應速度
  • 提供 ssh 遠端技術支援
  • STANDARD
  • 提供專用客戶支援服務窗口
  • 一年 10 次技術支援請求數
  • 提供上班日 4 小時內的回應速度
  • 提供 ssh 遠端技術支援 
  • BASIC
  • 提供專用客戶支援服務窗口
  • 一年 3 次技術支援請求數
  • 提供上班日 1 天內的回應速度 
  • COMMUNITY
  • 以官方社群做為技術支援


在付費頁面時會顯示有歐元 VAT 20% 的稅金,請在後面的地區選擇切換為 Taiwan,就會扣除這一筆費用。





結論

Proxmox VE 以自由、開放的精神提供給大家好用的虛擬化管理平台,若您有餘力或需求,建議可以付費取得支援並對這一群用心開發的團隊成員做出鼓勵,畢竟若沒有他們,就沒有好用的 PVE 讓我們享用。

或者,您可能資金運用短缺,也可選擇投入貢獻的行列,您可以加入 PVE 開發團隊的貢獻者之一,或是以使用者的角度進行推廣,讓更多人享受到自由、開源軟體的好處。

就如我一般,使用以後發現 PVE 是款非常棒的軟體,這讓我開始投注心力在台灣推廣 PVE 的使用。同時,為了降低入門使用者的門檻,我也加入開發團隊並貢獻了屬於我們使用的繁體中文語系檔 (已經在 PVE 5.3 併入正式版本)。

當我們享用到其它人努力的美好成果時,也不要吝嗇於付出一點點的回饋,讓世界越來越好,好嗎?




參考資料



2019年2月17日 星期日

[經驗分享]以 netdata 強化 Proxmox VE 效能監視戰力



在 Proxmox VE 的 WebUI 上,儀表板已經俱備效能圖表的顯示功能,但仍然有些不足之處,例如:

  • 保存的資料時間有限,超過圖表範圍就看不見
  • 無法自由的放大或縮小刻度顯示
  • 分鐘級的更新頻率,對於秒級變化的效能無法感知


而在前幾天的文章中,我們也提到如何搭配其它套件來加強 Proxmox VE 的效能監視部份,不過當時僅就 DISK I/O 部份討論。

今天我們就來針對 netdata 應用在 Proxmox VE 之時,有那些可以觀看的指標,以提升問題定位的作業速度。







安裝套件

netdata 安裝非常簡單快速,到官網上就有完整的說明。

netdata


請到 netdata 專案 GitHub 網站,在網頁中搜尋 Quick Start 的字樣。

netdata 快速安裝


在 netdata 說明頁面上,提供的懶人包式的一行安裝,在幾乎所有的 Linux 發行版本都可以此用這個方法進行快速安裝。
一行安裝 netdata
bash <(curl -Ss https://my-netdata.io/kickstart.sh)

執行至所有流程都成功以後,請以瀏覽器輸入 http://ip:19999,即可開始享用 netdata。









效能指標

開啟 netdata 畫面以後,映入眼廉的是精美的圖表,即時的更新,並且是深色系的科技感佈景主題。

netdata 深色佈景主題


如果不習慣或是不喜歡深色佈景主題,可以點選頂端列的齒輪圖示 > Visua 頁籤 > 將 Dark 切換為 White 即可。

netdata 淺色佈景主題


我相信,絕大多數的朋友看完淺色佈景主題後又會切回去深色主題。






NODE 節點


對於 PVE 節點原本的 WebUI 儀表板數據,在 netdata 裡全都可以找到相對應的圖表呈現。


NODE 節點 CPU


請展開右方清單的 CPU 即可觀看。

觀看節點 CPU 圖表


此處的 CPU 使用率可以查看每一個核心的個別情況,若要查看總量,請點選右方清單 System Overview 裡的 CPU 即可。


NODE 節點 IO Delay


請展開右方清單 System Overview 裡的 CPU,並只點亮圖表中的 iowait 這個項目。

觀看節點 IO Delay 圖表


NODE 節點 Memory


請展開右方清單的 Memory 即可觀看。

觀看節點 Memory 圖表



NODE 節點 KSM


請展開右方清單的 Memory ,並點選下方的 deduper (ksm) 即可觀看。

觀看節點 KSM 圖表



NODE 節點 Swap


請展開右方清單的 System Overview,並點選下方的 Swap 即可觀看。

觀看節點 Swap 圖表



NODE 節點 Disk I/O


請展開右方清單的 Disks,再點選要觀看的磁碟名稱即可。

觀看節點 Disk I/O 圖表



NODE 節點 ZFS


請展開右方清單的 ZFS filesystem,再點選要觀看的項目即可。

觀看節點 ZFS 圖表


在 ZFS 項目裡,提供了 ZFS 效能關鍵的 ARC 與 L2 ARC Size 資訊,以及歸類在 accesses 裡的 ZFS 與 L2 ARC 讀寫資料量,還有 efficiency 下的 Cache Hits 快取命中率。

這些資訊對於 ZFS 效能的掌握以及調校提供了非常重要的參考資訊,在過去我們會使用命令列的 arcstat.py 與 arc_summary.py 來取得這樣的資訊,但 netdata 以圖表即時呈現,就是可以讓我們更輕易一目瞭然,加速作業能力。





KVM 虛擬機器


在 netdata 裡,要獨立觀看 PVE 節點下的 KVM 虛擬機器情況,可以在右方的清單中找到以 qemu 開頭的項目,在 qemu.slice 名稱後面的三位數字,就是對應 PVE 給客體機所編號的三位數 VMID。


KVM 虛擬機器 CPU


點選後即可觀看該虛擬機器的 CPU 使用率圖表。

觀看虛擬機器 CPU 圖表



KVM 虛擬機器 Network


接下來,請在右方清單找到 Network Interfaces,展開後可以找到 tap 開頭的項目,後方接著的三位數同樣是 VMID,點選後即可查看虛擬機器的網路流量。

觀看虛擬機器的網路流量圖表


若同一台虛擬機器配有兩張以上的網卡,則可以從名稱的最後一位數判斷。例如 tap104i0 表示為 104 這台虛擬機器的第一張網卡,tap104i1 表示為 104 這台虛擬機器的第二張網卡,依此類推。



KVM 虛擬機器 Memory


虛擬機器的 Memory 記憶體使用量,目前在 netdata 上仍無法個別查看。




KVM 虛擬機器 DISK


若要查看虛擬機器的 DISK 讀寫使用率,只能用在使用 ZFS Block Level 形式的才可以,請搭配「[經驗分享]找尋虛擬機磁碟 I/O 效能問題所在」這一篇所提到的技巧先找到對應的 zdN 設備名稱,再於右方清單展開 Disks,點選裡面的 zdN 以查看圖表。

觀看虛擬機器的磁碟讀寫量圖表










LXC 容器


至於 LXC 容器,則會直接以該容器在 PVE 中所命名的方式出現,請在右方清單直接點選即可。



LXC 容器 CPU


展開 LXC 容器名稱後,下方點選 CPU 即可查看使用率圖表。

觀看容器 CPU 圖表




LXC 容器 Network


展開 LXC 容器名稱後,下方點選網卡名稱 (如 eth0) 即可查看使用率圖表。

觀看容器的網路流量圖表



LXC 容器 Memory


展開 LXC 容器名稱後,下方點選 Memory 即可查看使用率圖表。

觀看容器 Memory 圖表




LXC 容器 DISK


容器的 DISK 磁碟讀寫量,目前在 netdata 上仍無法個別查看。








結論

善用各種同樣是開源的工具,可以讓我們在使用 Proxmox VE 時如虎添翼,直線式的往上拉升工作效率,這就是開源的能量,開放的力量。






參考資料



2019年2月16日 星期六

[經驗分享]Proxmox VE 快照機制與遺失快照處理



絕大多數的人使用虛擬機方案,就是為了方便的 Snapshot 快照機制,萬一機器操作損毀,一次按鈕回到正常的時間點。

在 Proxmox VE 裡,同樣也完整支援快照機制,而且應對不同的 Storage 儲存還有不同的特性。






快照功能

在 PVE 的 WebUI 上使用快照,簡直是易如反掌,絕對比你吃一頓晚餐還容易。


PVE 製作快照功能


只要你會用手點滑鼠左鍵,你就會用 PVE 的快照功能,完全沒有任何難度。

不過,若虛擬機器與容器用的多後,會發現在某些情況下無法製作快照,這是為什麼呢?







快照支援

本文一開始提到 PVE 應對不同 Storage 儲存有不同的快照特性,那麼有那些儲存支援快照,那些不行?



儲存種類與對應功能表


在官方文件上有整理一張非常詳細的對照表,明確列出有那些 Stroage 可以使用快照功能,請參閱表中的 Snapshots 欄位。

依據表中的結果,我們可以先簡化成以下結論:
  • 支援快照
    ZFS、LVM-Thin、Ceph/RBD、Ceph/CephFS、Sheepog、ZFS over iSCSI


表面上看起來能做快照的種類不多,但表格上同時也寫了但書:在 Flie Level 的儲存區 + 使用 qcow2 格式,則仍然可以使用快照功能。

注意是僅限 qcow2,PVE 所另外支援的兩種 File Level 檔案 vmdk 與 raw 是不支援快照能力的。

qcow2 能提供快照是 KVM/QEMU 虛擬機器本身所支援的功能,但既然是 File Level 格式,效能自然會比 Block Level 的檔案系統 (如 ZFS) 效能較為落後,若對於效能有較高要求的使用者,請留意。

所以我們應該修正結論為:
  • 支援 Block Level 快照
    ZFS、LVM-Thin、Ceph/RBD、Ceph/CephFS、Sheepdog、ZFS over iSCSI
     
  • 支援 File Level 快照
    Directory、NFS、CIFS、GlusterFS






快照標記

當我們使用快照功能以後,除了儲存會製作快照內容,客體機的設定檔也會有相對應的內容存寫入。

WebUI 製作快照完成


客體機設定檔內容


除了在儲存上產生快照內容,設定檔本身也會長出相對應的區塊,如上圖會記下快照標記名稱、當時的主機設定等等。

但是在某些情況下,例如 xxx.conf 設定檔損毀重建、遺失等等,客體機的設定檔會與當時有做過快照的資訊不太相符,儘管可以正常使用,但總覺得怪怪的。






處理問題

如果是虛擬磁碟沒有快照點,但虛擬機器的 xxx.conf 裡面有,請直接手動刪除該標記的區塊即可。

但最常見的,是實際上有做過快照且存在磁碟,而設定檔裡沒有。

我們可以用指令針對指定的虛擬磁碟儲存顯示快照點,以 vmid 為 108 這台機器,它配有一個虛擬磁碟做為展示:
查看指定虛擬磁碟快照點 (qcow2)
qemu-img snapshot -l vm-108-disk-0.qcow2
查看指定虛擬磁碟快照點 (zfs)
zfs list -t snapshot | grep vm-108-disk-0

執行以後,分別可以查看到快照點的結果:

查看 qcow2 快照點


查看 zfs 快照點



如果在虛擬機器的設定檔 108.conf 裡,已經沒有 test1 與 test2 這兩個快照點的設定區塊存在,我們可以自行針對虛擬磁碟操作,以讓佔去的空間釋放。


刪除指定虛擬磁碟快照點 (qcow2)
qemu-img snapshot -d test2 vm-108-disk-0.qcow2
qemu-img snapshot -d test1 vm-108-disk-0.qcow2
刪除指定虛擬磁碟快照點 (zfs)
zfs destroy /zfspool/vm-108-disk-0@test2
zfs destroy /zfspool/vm-108-disk-0@test1


不管是 qcow2 還是 zfs,刪除快照的指令都是成功執行沒訊息,失敗才會出錯誤,若想確認是否成功,可以依據前面的查看快照點指令再做一次。






結論

在 PVE WebUI 或 CLI 正常使用時,設定檔中的快照標記與實際磁碟絕對是一致的。因此,上述這些操作建議僅在特殊情況發生時才使用,以免一時不慎,反而造成更多的損失。

同時切記,即便有了強大的快照功能,仍然要做好備份。









參考資料


2019年2月15日 星期五

[經驗分享]Proxmox VE 中 LXC Swap 神秘爆增之謎



Proxmox VE 除了 KVM 虛擬機器之外,還提供了 LXC 容器,可以讓我們用最省的資源建置最大的應用。

不過,若您 LXC 使用的多,可能會發現一件奇怪的事:Swap 數字怎麼是錯的?






容器設定

先來看看一個實例,這裡有一台 LXC 容器,Memory 配予 1G,Swap 配予 512M。

LXC 機器記憶體配置


在 PVE 的介面上看起來都相當良好,接下來我們進入 LXC 容器裡面看看會發生何事。






容器內部

一般查看記憶體使用情況的指令,會使用 free 來操作。

使用 free 指令查看 Swap 情況


呃!Swap 怎麼變成  1.5G  了?竟然比 Memory 還多,太可怕了!

這一驚非同小可,趕快用其它方式查查看。

使用 top 工具查看 Swap 情況


使用 htop 工具查看 Swap 情況


天啊,也都是一樣的結果,再換一支神器等級的工具來看看...

使用 glances 查看 Swap 情況


欸?不一樣了喔,glances 所看到的 Swap 容量是 3.6G...這容量也對不上,這台 LXC 是 512M。

回頭思考一下,其實 3.6G 這個數字是來自於這裡:

PVE Host Swap 使用情況


原來 3.6G 是 Host 主機的 Swap 容量,並不是 LXC 的,讓人有滿腦子的疑惑。







繼續追查

深入一點,我們從不同的地方來看 Swap 容量的資訊。

使用 fdsik 查看 Swap 使用情況


想要使用 fdisk -l 來查看 swap 區的資訊.... 沒有!


查看 /proc 下的 Swap 使用情況


情況不同了,在 /proc/meminfo 裡面的 Swap 大小仍然是錯的,但是 /proc/swaps 裡面就是正確的數字 (單位為 KB),這表示 LXC 裡面其實能有正確的資訊,但不是全部。

可是 /proc/swaps 裡面的 swap type 為何是 virtual?一般我們使用的是 partition 或 file,幾乎沒有看過是 virtual 的。








結論

依據這些數據來看,我們可以發現 Swap 在 LXC 裡面的大小,幾乎都是 LXC 設定裡的 Memory + Swap 的大小,也就是 1G + 512M = 1.5G。

為什麼會有這麼有趣的現象呢?PVE 開發團隊有做出過解釋。

他們的說法,是因為他們還沒有得到完全的 cgroups v2 支援,在沒有能支援之前,他們是不可能解決這個問題。

當我們建立 LXC 以後需要給予配置的 Memory 與 Swap,但是在目前的 Kernel 以 lxcfs (這也就是為什麼 Swap type 顯示為 virtual 的原因) 所能作出的限制,只能有兩種:
  • Memory
  • Memory + Swap

通常我們建立系統時,都會一併指定 Swap,在這個情況下,就造成了 LXC 裡面看到的 Swap 是兩者相加。

雖然 Swap 顯示的數字錯誤,但實際運作時這兩者會獨立分開,依據原有的設定做限制,只是看起來令人困擾。







參考資料



2019年2月14日 星期四

[經驗分享]關於 Proxmox VE 漏洞修補與更新速度



Proxmox VE 是一套開放原始碼的平台套件,但是在更新速度上的效率如何呢?安全性的狀況又如何呢?

除了去年我在一場演講中提到「開源與閉源的安全性議題」之外,最近剛好也有個案例可以分享。






容器漏洞

就在最近,有個容器經常使用的 runC 套件被揭露具有嚴重的問題 (CVE-2019-5736),能夠讓入侵者掌握容器的管理權限甚至是建立新的容器。

由於容器技術在雲端世代運用極為廣泛,這個問題幾乎涵蓋了所有平台,諸如 Amazon、Google、Redhat...等,各家也立即展開修補動作。


iThome 報導 runC 套件漏洞資訊






修補狀況

對於我們很喜愛使用的 Proxmox VE 使用者來說,使用的 LXC 容器技術同樣也受到這個問題的威脅,那麼 Proxmox VE 這邊的修補情況又是如何呢?

我們來到官方團隊的 git 伺服器,看看專案的狀況進行了解。

PVE 修正進度


依據 iThome 新聞指向的來源顯示,在 2/11 揭露 runC 漏洞存在,PVE 團隊在 2/12 就立即合併了來自 Debian 的修補檔。

PVE 版本更新進度


在完成修補檔的合併之後,PVE 團隊立刻在同一時間就推進了 lxc-pve 套件的版本號,而且立即開放使用者更新。

PVE 版本更新






結論

對於 PVE 開發團重視安全的程度以及處理的時效,讓我們身為使用者感受到非常安心。儘管他是開源軟體,但是更新與修補的速度並沒有比較慢,在很多情況下甚至比閉源軟體還要快速。

類似的案例在過去也多次上演,例如 Intel CPU 的 Spectre & Meltdown 漏洞,甚至是更早之前的 SambaCry 等,都在上游套件發出更新修補後,PVE 在極快的時間內合併進入且發出更新。

除了推出更新與修補檔以外,更重要的是 PVE 一直以來的版本更新非常嚴謹,每次版本更新均相當順利,我從來沒有因為更新而造成虛擬機器停止服務,或是系統故障。

我想若每次更新都要要停機,或是需要很複雜的手續,或是都要靠運氣來賭更新會不會成功,這是很可怕的事,還好我選擇了 PVE,沒有這回事。






參考資料