程式。語言。筆記

  型別是什麼？ 「型別」是電腦理解「資料的意義」的方式。  變數能儲存的資料種類 (ex：int、float、char、string、boolean) 變數能進行的操作 (ex：加減法、比較、串接) 編譯器或直譯器該如何管理記憶體與運算 簡單舉例說明： int a = 10; string b = "10"; 上面 a 是數字，b 是文字。   強型別 vs 弱型別  語言在不同型別之間容不容易被自動轉換，容易的是弱型別，不容易是強型別。 直觀上最大的差異感大概是：型別錯了是「直接報錯」還是「幫你偷偷轉換」。  下面直接整理成表，比較一目了然：  強型別 弱型別 定義 不允許或嚴格限制隱式型別轉換 允許自動轉換不同型別 代表語言 Python、Java、C#、Rust JavaScript、PHP(部分)、Perl 優點 避免隱性錯誤，程式更穩定 撰寫更靈活，快速原型方便 缺點 需要明確轉型，程式碼較冗長 容易出現非預期結果   靜態型別 vs 動態型別  兩者差在型別什麼時候被確定，需要先宣告、且執行期間不能變換的是靜態，反之為動態。 一樣放比較表： 靜態型別 動態型別 型別確認時機 編譯時 執行時 宣告方式 需明確宣告型別 型別由執行時自動判斷 代表語言 C、C++、Java、Rust、Go Python、JavaScript、Ruby 優點 錯誤早期偵測、效能佳 靈活快速、撰寫方便 缺點 需要較多樣板程式碼 錯誤可能在執行期才爆出   語言型別分類 下面列舉一些程式語言和它的型別。  強/弱型別 動/靜態型別 C 強 靜態 C++ 強 靜態 Java 強 靜態 Python 強 動態 PHP 弱 動態 JavaScript 弱 動態 Go 強 靜態 Lua 弱 動態   小結  ...

這篇承接了 BMC 、 IPMI 兩篇，如果對這兩個東西不熟，可以先複習一下在來看這篇。    Redfish 簡介    不免俗地先放 logo。 Redfish 是由 DMTF (Distributed Management Task Force) 在 2015 年正式提出的開放標準， 目標是 取代 IPMI ，提供「現代化、可擴充、安全」的伺服器管理協定。  其設計與 IPMI 相當不同，將傳輸上的 binary 改為 HTTP/HTTPS + JSON + RESTful API ，以此為基礎進行設計，因此任何支援 HTTP 的工具 (ex: Python、curl、Postman、瀏覽器) 都能直接與 BMC 溝通。   Redfish 架構   目前我對 redfish 的對外關係理解如上，基本上 Redfish 跑在 BMC 上，用來接收來自 Client 的 RESTful API，再由 BMC 透過 I2C、SMBus 等方式控制硬體。 前面提過 redfish 走的是 HTTP/HTTPS，所以這邊回傳的 status code 是用 HTTP Status Code。   Redfish Resource Model   基本上 redfish service root 會在 /redfish/v1/，直接 GET 此 URI 不需要權限驗證，會將 redfish 底下的 service 直接展示出來。 這邊只提主要的 model： Chassis：描述實體機體（物理外殼）與其內含的硬體元件 Managers：控制與監控中樞，會監控 Chassis、控制 Systems Systems：實際執行應用程式的系統   Authentication redfish 的身分驗證有二： 第一個是  HTTP Basic authentication ，內容點連結，這邊不細說。另一個則是 Session。 在 redfish 建立 session 的 URI 是 /redfish/v1/SessionService/Sessions，官方給的範例如下：  ...

  在 前一篇 中，我們提到 BMC 是伺服器主機板上的獨立控制器，負責監控各種狀態，並可在主系統關機時進行管理。然而，BMC 並非單獨運作；它之所以能與外部系統管理軟體（如 IPMItool、OpenManage、iDRAC、iLO）互通，是因為它遵循了標準化的 管理協定 。 我們接下來會講到兩種協議—— IPMI 與 Redfish (待續)。   IPMI 簡介 IPMI (Intelligent Platform Management Interface) 是由 Intel、Dell、HP、NEC 等公司在 1998 年共同制定的伺服器管理標準。  外部管理者可以透過它與 BMC 溝通，執行電源控制、感測器監控、事件記錄、遠端開關機、韌體更新等任務。   IPMI 架構 (圖片 reference )  這張圖片來自 intel，我想是目前最能說明 IPMI 與 BMC 的架構圖。 在找能說明 IPMI 的架構圖的同時，我也發現一個對 IPMI 實作有著詳細記錄的文章 (雖然是 2013 年的文章，可能跟 IPMI 2.0 有些出入)，貼上來以供參考： https://benjr.tw/11240   IPMI 的功能模組 Sensor & Event ：讀取溫度、電壓、風扇狀態，異常時會寫 log Chassis Control ：控制開關機、重開機 FRU Inventory ：讀取硬體序號、廠牌、型號等資訊 Watchdog ：監控主機 OS 狀態，失效時可自動重啟 Firmware Update ：更新 BIOS / BMC 韌體  另外，我們也經常會在這個領域聽到「OEM」一詞，這是指「各伺服器或主機板製造商在標準 IPMI 規範之外，自訂擴充的命令、事件、或感測器定義」。 像是特殊的電源資訊、 風扇模式切換……簡單來說就是 IPMI 的擴充包。 IPMI 的限制與挑戰 儘管隨著時間與科技進步，IPMI 進行多次更新 安全性不足 IPMI 在 2014 年升級到了 IPMI 2.0， 做了諸如：提升加密通訊為 RMCP+、變更預設密碼:、限制網路存取、隔離公用網路……等措施，但還是存在Cipher 0 ( CVE-2013-4786 )、未驗證韌體簽章、加密模式太弱等...

BMC 是什麼？ BMC 全名為「Baseboard Management Controller」，中文直譯就是「基板管理控制器」，是嵌在主機板上一個獨立於主系統的微控制器 (通常會是一顆低功耗的 MCU)，有專用的記憶體、韌體，通常用於 Server。 縱使在主系統關機、當機、或失效時，仍可以獨立監控並管理整個硬體平台。   (BMC 對周邊通訊如圖，圖片 reference )    核心功能有： 獨立運作：有自己的處理器、記憶體、韌體、網路，能在主系統電源關閉時仍保持通電 監控：透過感測器收集溫度、電壓、風扇轉速、電源狀態等資訊 遠端控制：支援遠端開機、關機、重啟、記錄事件等功能  網路系統：可以獨立、可以與主系統共用、也可以兩種都支援，取決於成本與可靠性 獨立 (Dedicated NIC)：BMC 擁有一個獨立的乙太網路埠，直接連接到 BMC 的內部 MAC/PHY，通常該網路只供管理用途 (Management LAN) 除了會提高晶片成本外，機房還需額外拉線 共用 (Shared NIC) ：BMC 與主 CPU 共用相同的乙太網路實體介面 (通常透過 MUX 或 Sideband 通道切換)、封包亦會共用同一個 port，再另外透過 NC-SI (Network Controller Sideband Interface) 或 SMBus/PCIe 在主系統 NIC 晶片內部切分資料 BMC 與主系統會分別擁有不同的 MAC Address 或 VLAN ID 雖然成本降低了，但主系統異常時會被影響(包含斷線、延遲)、資安上也有 BMC 管理介面被入侵影響主系統的事件(ex： CVE-2024-54085 )   BMC 的硬體架構 如前面所述，BMC 通常是一顆低功耗 MCU (常見製造商：ASPEED、Nuvoton、Renesas)，包含的硬體大致如下： ARM Core 處理器 SRAM / Flash 網路介面 (Ethernet MAC/PHY) 通訊匯流排 (I²C / SMBus / UART 介面)：與硬體監視器交流用 GPIO 控制器    小結 BMC 是嵌入式系統中「系統管理層」的關鍵元件，它讓硬體具備「自我監控與遠端維運能力」，是 Serve...