2018年12月26日 星期三

[經驗分享]讓 Proxmox VE 中 VM 放本機磁碟者做線上遷移



Proxmox VE 支援線上遷移 (Online Migration) 與離線遷移 (Offline Migration)。

不過,若把 VM Disk 放在節點 (Node) 的本機磁碟 (Local Disk) 則無法做線上遷移。



先決條件

要讓放在本機磁碟的 VM 可以線上遷移,有幾件事需要注意:

  1. 來源節點與目的節點的儲存 (Storage) 名稱需要有相同的名稱存在。
     
  2. 來源節點與目的節點需在同一個叢集 (Cluster) 內。
     
  3. 建議先在來源節點的 VM 裡設定過複寫 (Replication) 並至少執行過一次,若沒有的話時間將較久。

    [2018/12/26 更正:不能有複寫過 Disk 存在目的端,會影響遷移]
     
  4. 來源節點與目的節點的儲存 (Storage) 檔案格式最好使用 ZFS




執行指令


本機磁碟的 VM 要線上遷移只能透過指令來做,請先登入來源節點的 Console,並做如下指令:
qm migrate <vmid> <targetnode>  --with-local-disks --online 


即可開始進行線上遷移。

輸入支援本地磁碟的線上遷移指令


支援本地磁碟的線上遷移完成





參考



2018年11月28日 星期三

[經驗分享]LibreNMS無法取得某些FreeNAS儲存區資訊



我在機房中有一台 FreeNAS 9.10 版,但這台機器一直無法讓 LibreNMS 讀取到正確的儲存區資訊,困擾已久。



狀況

LibreNMS 可以經由 SNMP 協定取得儲存伺服器的儲存區容量,對於管理者來說可以統一管理並制訂警報發送條件,但這台一直無法抓到,困擾很久。

從一開始就懷疑是這台 FreeNAS 版本的問題,因為其它台 FreeNAS 的版本都是 9.10.2 以上,沒有這個情況存在。




完全空白的儲存區資訊




追查


直到最近,我將這台 FreeNAS 原地更新到 9.10.2-U6,沒想到情況仍然存在。

這樣看來變數就多了,我試著在 LibreNMS 用 SNMP v3 去對這台 FreeNAS 連接,一樣沒有改善。

不經意在 LibreNMS Github 的 Issue 裡瞄了一篇,提到同樣的問題:

FreeNAS 9.10 - Storage disks/mounts not discovered

沒錯,真的是 9.10 才有的問題,但我從 9.10 升級到 9.10.2-U6 還是發生,但如果是全新安裝則不會。

再往下看,這名網友分享了這個資訊:

It's definitely some bug in FreeNAS or FreeBSD. Discovery works OK when using SNMP v1. Older FreeNAS server is polled using SNMPv2, and it is working OK.


我抱著嘗試心態試了一下,改用 SNMP v1 去問這台 FreeNAS,竟然真的都出現啦!



終於正常的儲存區資訊



設定位置在 Device 裡的 SNMP 頁籤,簡單切換即可。



切換 Device 輪詢時使用的 SNMP 版本




參考

2018年11月26日 星期一

[經驗分享]基礎程式locale、ldconfig等消失事件



繼前陣子發生 MariaDB 會自己消失的離奇事件後,今天又發生另一起消失事件。



狀況

為了搞定 BookStack 套件的 PDF 中文匯出問題需要安裝 gblic 2.27 版本,但 Ubuntu 16.04 能提供到的版本是 2.23,後來搞了半天是真的把 2.23 給移除了,但結果是連許多基礎套件都幹掉了。




移除 libc-bin 時同時也移除好幾個套件




追查


本來只是為了移除 gblic 2.23,結果不僅 2.27 裝不上去,連其它基礎程式都掛了,例如 locale、apt 等很多東西都異常,類似以下的訊息

Can’t exec “locale”: No such file or directory at /usr/share/perl5/Debconf/Encoding.pm line 16. Use of uninitialized value $Debconf::Encoding::charmap in scalar chomp at /usr/share/perl5/Debconf/Encoding.pm line 17.

這下麻煩了。

翻查資料研究後,需要手動把 ldconfig 給弄回來。

apt-get download libc-bin
dpkg -x libc-bin*.deb unpackdir/
sudo cp unpackdir/sbin/ldconfig /sbin/

接著再重新安裝一次 gblic 套件。

sudo apt-get install --reinstall libc-bin 
sudo apt-get install -f

    好了,現在修復完成。

    等等,你可能會想到一件事:開頭提到的 BookStack 匯出 PDF 中文版問題需要 2.27,可是你裝回的是 2.23 還是沒解決啊?

    是的,經過爬文,需要 Ubuntu 18.04 才能使用 2.27,所以...... 我做了 do-release-upgrade 把 Ubuntu 16.04 更新到 18.04 了,結案!

    補充一下大版本更新經驗:

    • 10.04 to 12.04 = 死
    • 12.04 to 14.04 = 死
    • 14.04 to 16.04 = 系統活著,但死掉一堆套件 (那還是不能用啊)
    • 16.04 to 18.04 = 奇蹟的活下來了!



    參考




    2018年11月22日 星期四

    [經驗分享]MariaDB服務消失的離奇事件



    近日架設 Moodle 當做測驗平台,卻無意中遇到一件離奇的事:資料庫服務自己消失了。



    狀況

    為了快速建置,這次我採用了 TurnKeyLinux (TKL) 所打包的 VM 檔,直接開機後一步一步往下操作,就立即完成可用的 Moodle 系統。

    上線一天後,忽然 LibreNMS 發出 Moodle 服務異常警報,一試之下真的出錯。

    Moodle 掛了



    追查

    第一次發生時,以為是自己架設有問題或沒調整好,就先倒回正常的快照點,讓系統恢復運作。

    沒想到隔天下午又發生一次,ssh 連至主機查看,發現 mariadb 服務沒有運作,甚至連 service 的status/start/stop 都無法執行!

    這可嚇壞我了,檢查一下設定檔都還在,但是關鍵的 mariadb.service 卻消失了。
    Mariadb.Service 消失



    這就有點不太對勁了,難道是惡意程式或入侵?

    認真想了一下,是不是更新造成的問題?因為我有開啟 TurnKeyLinux 的 Security Patch 自動安裝,那就來試試看。



    執行 TurnKeyLinux Security Patch


    手動執行更新後發現關鍵字了,更新時「REMOVED」、「mariadb-server-10.1」 ...等,Mariadb 在這裡被移除,再往下看又另安裝了「mariadb-server-core-10.1」這個版本。

    既然有重新安裝起來,為什麼服務會不見呢?

    所以我又還原一次快照點,這次先把 mariadb.service 備份起來,更新完再 copy 回去,服務就能繼續正常運作。




    參考

    就在我解決不久後,同事剛好也查到相關資料,不看還好,一看令人扼腕。

    因為我在 11/20 遇到問題,11/21 自己追查解決,結果這問題正是 11/20 超級新鮮,剛出爐的就被我遇到........

    TurnKeyLinux 的官方說法,表示這問題是 Debian 的更新出了問題,大約有 70% 的使用者會遇到,他們建議的方法是「重新安裝一次 mariadb 即可」。

    apt update
    apt install default-mysql-server






    2018年11月21日 星期三

    [功能測試]各家Office軟體"裝訂線"對決



    公務文件最常出現的「裝訂線」,經常是讓 Microsoft Office 以外文書軟體顯示問題的應用,我們再來看看在各家 Office 近期版本上呈現到底會如何呢?

    一次全開,立知高下。

    ※ 這篇文章其實在五月時已經完成,卻一直忘了發。


    裝訂線呈現對照圖 (點選看大圖)


    圖中由左至右分別為:

    1. NDC ODF Application Tools (國發會ODF文件應用工具)
    2. LibreOffice
    3. FreeOffice
    4. OnlyOffice
    5. Microsoft Office


    從結果來看,第1、2、4都可以呈現裝訂線,但4會有文字破碎問題。

    因此,若要非 Microsoft Office 開啟這類文件,可以參考 NDC ODF Application Tools、LibreOffice。

    註:奇怪的是,這次測試第1、2項裝釘線上有留空卻沒呈現文字(之前會有),這個我再測試看看。




    參考資料



    2018年11月18日 星期日

    [行業觀察]IT維運六備輪迴




    經過多年的IT職涯心得,歸納出我稱之為「六備輪迴」的悲劇事實。


    六個「備」字


    越往下走,成本越驚人。

    備註

    對於手上管理的主機都要做好說明與記錄。

    備份

    重要資料都應該保存一個以上的複本,更理想的是 3-2-1

    備品

    沒有不會故障的零件,隨時備妥即時更換。

    備援

    若有備援系統,線上主機故障可以立即切換,繼續運作。

    備員

    天有不測風雲,人有旦夕禍福。代理或接手人員的重要性不亞於備援設備。

    備案

    嗯...只好上警局寫簿子了。



    最後的備案可能導致丟了工作,所以下一份工作又從備註開始了...



    ※ 這篇文章純屬喇賽
    ※ 如有雷同純屬巧合

      

    2018年11月10日 星期六

    [議程簡報]LibreNMS 企業實戰經驗分享



    LibreNMS 是我使用多年的優秀開源套件,在這次議程中我將分享它的功能介紹、進階功能,以及我在企業中實際應用的經驗談。




    管理問題


    在網路裝置日益成長的情況下,管理人員的負擔也持續加劇。






    相信身為資訊人員的你,寥寥數語肯定讓你看的直是點頭。


    評估重點


    當時如何評估選擇要使用的方案呢?

    以我的經驗,最終歸納出為這幾點,做為比較套件時的指標:

    • 監控眾多裝置
    • 保存歷史數據
    • 支援類型廣泛
    • 自訂裝置分組
    • 美觀好用介面
    • 設定簡單容易
    • 多種認證機制
    • 多樣警報機制
    • 外掛擴充能力
    • 支援二次開發



    監測方式


    LibreNMS 採了基本 + 進階 + 外掛的監視方法,您可以依據需求決定要做到那個程度。








    剩下的細節,請直接前往簡報平台閱讀,若您未參與活動,則建議先閱讀相關資料的第二個連結,再前往觀看完整簡報。



    相關資料



      

    2018年10月13日 星期六

    [期刊文章]Proxmox VE、FreeNAS、Zimbra 企業應用經驗談



    去年我以企業應用經驗為主,撰寫了三篇與開源軟體相關的文章,於 Linuxpilot 國際中文版期刊登載,有興趣者歡迎前往翻閱。



    連結




    2018年10月9日 星期二

    [工具推薦]開源議題協作平台 SenseMap




    團隊溝通或專案討論時,若有個良好且跨時間與地區的協作工具,可以很便利的收容討論成果。

    TFC (台中自由軟體愛好者社群) 十月第二場活動「開源科技社群如何參與科技政策規劃?」中,將會介紹到這個開源套件。




    工具


    這個好工具,由 Sense.tw 團隊所開發,MIT 製造,MIT 授權。

    Sense.tw 前身是 2013 年社群發起的 g0v 專案「鄉民關心您」,一個企圖蒐集、整理、串連、行動、追蹤去中心化群眾參與社會議題平台。2017 年獲科技會報補助,研究如何讓公眾意見進入 2030 科技願景與政策討論中。

    它是一套以地圖式呈現的協作工具,讓團隊以類似心智圖模式進行議題討論,還有其它協助整理資料與網路意見並疏理議題架構的功能。


    議題協作畫面


    項目清單收合畫面




    結論


    您可以直接前往 Sense.tw 網站開啟議題進行討論,亦可到 GitHub 專案下載後自行架設。




    2018年9月20日 星期四

    [問題處理]讓 Nagios Plugin 域名檢查支援 tw


    LibreNMS 支援 Nagios Plugins 來擴充檢測的功能,其中 check_domain 是 nagios plugins 套件裡非常實用的機制,可以提醒我們在域名過期之前儘快續約。





    可惜故事沒這麼簡單,開源套件踩坑是家常便飯。

    一用就遇到問題,每每執行 check_domain 檢測域名都會失敗。

    檢測域名失敗


    怪了,但是參考該 plugin 本身的文件指令來測試 github.io 等域名卻又正常,花點時間查看原始碼後,確認原因是該 check_domain 不支援 .tw 的 whois 結果格式


    好在,開源的好處就是有問題可以自己動手來,我修改好了,已經可以正常取得。

    檢測域名成功




    結論


    修改完成以後,就可以在 LibreNMS 上搭配 Service 功能,對域名即將到期做出檢測與警告,可參考本文第一張圖,對 IT 人員來說非常方便好用。

    修改好的分支版本我已放置 GitHub,有需要的朋友可以取用。







    2018年8月14日 星期二

    [專案更新]PHP Server Monitor 支援 Telegram 與繁體中文語系更新



    開源伺服器監視系統 PHP Server Monitor 是一款輕巧的系統監視工具,功能雖然沒有 LibreNMS 這麼豐富,但是用來架在外點或是做為 LibreNMS 本身狀態檢查,是一款剛剛好的套件。

    原本 PHP Server Monitor 的推播通知只支援 Pushover,直到前陣子它釋出新版本 v3.3.1 支援了 Telegram 通知能力,我終於可以將他與 LibreNMS 一起使用相同的通知服務,而且更加方便。

    更新方式相當簡單,下載新版本覆蓋後,再執行一次 install.php 更新資料庫即可完成,可參閱相關說明。






    繁體中文


    過去我曾經製作過中文語系檔,這次依然為新版再次提供(不過之前是放在我的 GitHub 專案上,沒有提交回去),下圖是 Telegram 通知設定畫面。

    繁體中文語系介面



    這次最新的繁體中文語系檔,已經提交回官方團隊,預計在下一次新版本釋出時即會內建。

    若您想先更新至 v3.3.1 並立即套用繁體中文檔,可先下載我提交中的分支版本。







    結論

    PHP Server Monitor 功能貴精不貴多,做為外部監控或 LibreNMS 的輔助可以說是非常適合,尤其本次又加入了 Telegram 支援,實用性大為提升。







    2018年8月12日 星期日

    [問題處理]LibreNMS 1.42 版 Alert 功能異常



    開源網路裝置管理系統 LibreNMS 簡單易用,而且可以每天自動從 GitHub 自動更新至最新版,進展快速。

    不過,就在最近發生一件慘案,更新至 1.42 以後,原本我有整合 Telegram 做即時的 Alert 警報推播就失效了。



    嚴重了,我每天都依靠推備警報來判斷目前的系統運作狀況,忽然沒了 Telegram 丟出來的訊息,看似平靜,但卻害怕這會是暴風雨前的寧靜。


    情況追查


    試過更新版本還是沒有解決問題,在 Alert Transport 處,做 Test 發送卻是正常的,這表示 整合 Telegram 機制本身沒問題,是將警報推出之前出了問題。


    收不到警報推播令人害怕


    既然如此,在 WebUI 上能做的已經沒有了,回到 CLI 來看一下輸出的資訊,節錄一小段。
    Alert 發送
    # /opt/librenms/alerts.php
    Start: Fri, 03 Aug 2018 10:30:56 +0800
    ClearStaleAlerts():
    RunFollowUp():
    RunAlerts():
    Issuing Alert-UID #40852/1: telegram => ^[[A
    string(21) "API '' returned Error"
    string(8) "Params: "
    string(152) "Return: {"ok":false,"error_code":400,"description":"Bad Request: can't parse entities: Unsupported start tag \"xxx@xxx.com.tw\" at byte offset 120"}"
    ERROR: HTTP Status code 400;
    Issuing Alert-UID #40723/1:
    In alerts.inc.php(394) : eval()'d code line 11:
      Parse error: syntax error, unexpected '' (T_ENCAPSED_AND_WHITESPACE), expecting identifier (T_STRING) or variable (T_VARIABLE) or number (T_NUM_STRING)
    

    確實有錯誤。


    處理問題一


    在查看資料後,其中一個問題是 1.42 版起,Alert Template 的作法改了,宣告變數的方法不同,所以更新上來後提供了一個 Update Template 的按鈕幫我們轉換,但是這個轉換按鈕有問題,造成 Template 內容有誤,所以警報出不出去。

    新的宣告法正確是 {{ $value['string'] }},但轉換後會少缺符號 $value['string']

    相關資訊可以參考這一篇:



    好了,本以為高枕無憂,那知還是無法發送........



    處理問題二


    還是無法發送有點惱人,回頭看看錯誤訊息還有沒有線索,確實有看到一點。

    Unsupported start tag \"xxx@xxx.com.tw\" at byte

    看起來跟 Email 有關,去查遍所有設定與測試都還是無法解決,直到後來發現帳號有個欄位裡面有 Email:


    造成無法發送的元兇


    測試一下,把紅線部份的字全刪掉,警報即可恢復運作。




    結論

    想不到啊..... 是個小小問題卻搞到無法送出警報訊息。

    這個問題已提報開發單位參考,之後的版本應該會修正此問題。





    2018年7月16日 星期一

    [議程簡報]開放或封閉的安全之刃



    長久以來,對於使用閉源軟體或開源軟體何者較為安全,一直是個議題。

    今年,於國際資訊安全組織台灣高峰會 (TWCSA) 其中 OWASP 系列議程,我以經驗分享的分式介紹這個議題,以下擷取部份內容。




    安全問題


    例如以下這些對比,經常上演。








    以開源與閉源做為討論的主題,在這次內容並不另就自由軟體、專有軟體...等其它近似議題做細分。




    開源軟體


    容易看見的優點。








    特別注意,開源軟體並不代表免費,許多知名且成功的開源軟體,背後是由商業公司所推動,同時提供收費的商業服務。



    閉源軟體


    眾所皆知的優點。






    付費採用商業軟體服務,可以讓你專注在核心事務上。



    如何選擇


    在這議程中,從我的經驗中將開源與閉源軟體的優點與缺點均與予以列出,提供參考。

    不管是開源或閉源,都會有安全問題存在。





    協助工具


    第三方程式庫採用開放原始碼的比例越來越高,如何確保所選用的程式庫穩定與安全,在簡報中介紹了幾項工具,可以協助開發者降低評估風險的時間與難易度。

    更重要的,因為老朋友老問題,我將儘量提供開源工具的資訊。







    相關資料


    2018年5月19日 星期六

    [新貨測試]SoftMaker FreeOffice 2018 新版推出



    軟體開發商 SoftMaker 推出新版 FreeOffice 2018,在介面上大改版為 Ribbon Toolbar,對於習慣 Microsoft Office 使用者會相當容易轉換。

    基於同樣支持免費軟體的角度,趕快來試一試,以台灣最常舉例的「中文直書」來對比。



    中文直書呈現對照圖


    圖中由左至右分別為:FreeOffice、LibreOffice、Microsoft Office。

    從結果來看並不理想,LibreOffice 所呈現的效果明顯好過 FreeOffice,因此,我建議繼續使用 LibreOffice





    參考資料



    2018年5月15日 星期二

    台中社群與共創空間




    本篇整理台中在地社群,方便日後檢索,如有異動會直接修改下列內容。



    技術



    空間