最近我一直在進行相當多的 Zoraxy 更新。對於從未聽過 Zoraxy 的人來說，它是我的開源反向代理伺服器 (Reverse Proxy Server)。可以部署在你的 homelab 或server / NAS 裡面。 如果你對 Zoraxy 如何運作沒有興趣，單純是來找一個可以在 Windows 和 Linux 上運行的 Reverse Proxy Server，請按這裡。 v3 的新功能？ 嗯，如果你之前使用過 Zoraxy v2，每次打開 Web 管理界面，你都會感到一陣沮喪的感覺。這是因為在開發 v2 的過程中，我沒有多餘的時間仔細考慮配色方案或設計一個具吸引力的界面配色（然而作為開源項目來說，這界面已經算是到達夠好 + 能用的設計）。 v2 homepage v2 的代理清單 現在 v3 長這個樣子 除了界面更新之外，Zoraxy 還添加了大量新功能，以 optimize proxy core 的功能（或者我可以說，因為有太多 user 是從 Nginx Proxy Manager（NPM）轉過來用 Zoraxy，所以有一些部分如果盡量接近 NPM 的設計會省下我很多處理 issue 的麻煩）。一般來說，這不是 NPM 的替代品，而更像是一個讓你更容易在測試和debug 時切換 endpoint 的 Reverse Proxy。但無論如何，我不介意人們提出感覺像 NPM 的 enhancement issues。 Default Site 在 Zoraxy v3 中，我們新增了對 Default Site 和多個 host name 的支援。 Zoraxy 的前身（名為“Web Proxy”，是 ArozOS 系統的一個子服務）設計僅用於處理單一域名的反向代理，v2 版本添加了對子域和其他主機名的支援，但由於是沒經過設計加進去的，所以對 user 來說有夠混亂（ 使用者對 “Proxy ”、“Subdomain” 和 “Proxy Root” 的設定感到困惑然後又跑來開 issue。這就是為什麼在 v3 的設計中，我設計一個新的界面和設置邏輯。有了Default Site 的選項（對，就是 NPM 那個），那習慣用 NPM 的人可以輕鬆地切換到 Zoraxy 了。（順帶省下了我很多解釋東西怎樣用的時間） Default Site 提供 4 個選項供選擇。對於新手來說，你可能想要使用內部靜態網頁伺服器，在使用 "Static Web Server" 功能時將一個 "index.html" 文件作為你的網站首頁。這更像是傳統的 Apache 的用法，如果在 apache.conf 中沒有對應的 Virtual Host，所有的路由都會進入內置的靜態網頁伺服器，並從你的 /var/www/html 資料夾抓檔案來回應 request。 Redirection 和 404 Not Found 用起來也相對直接。對於 Redirection （重定向），你可以輸入要重定向的目標域名/IP 地址。在要將舊的（子）域名指向新域名，或者直接阻止那些未知/過時子域名的請求時滿有用的。 Wildcard 域名證書與 SNI 在 v3 中，我們 implement 了 TLS/SSL 證書查找邏輯中的 SNI。Zoraxy SNI 與其他 implementation 的區別在於，它不需要用戶輸入來將證書與特定主機名“鏈接”起來，而是會自動掃描並 serve 出對應的 TLS certificate。 在 v2 中，用戶需要手動為每個證書設置與匹配的域名。例如，如果你有一個證書可以涵蓋 a.example.com 和 b.example.com，你需要手動將其匹配關鍵字設置為 "example.com"，才能使這個域名的 TLS 加密正常工作（不然會出現 self sign certificate error）。現在有了 Zoraxy v3 的自動證書查找邏輯，你不需要設定任何東西。只需上傳你的證書（或使用內置的 ACME 工具從你選擇的 CA 生成一個），Zoraxy 將自動解析並選擇正確的 certificate。唯一的限制是對於包含多個主機名的證書（例如 domain.com 和 anotherdomain.com），速度會稍微慢一些（可能需要 O(n)…

最近因為我在開發 Zoraxy 時需要設計一個可以做到 high speed concurrent READ 跟間中 write 的 map，跟另一位高雄的工程師大佬討論了一個晚上，後來我發現原來滿多人對 concurrent / racing conditions 的處理有一定程度的誤解，所以我就來簡單的解釋一下最常見的誤解 - Check for locking。 問題 假設你有兩個 process，一邊要讀取一個無法同時讀寫的 map 資料結構（例如 Go 的 map[string]struct{}），另一個要寫入新的 key 到同一個 map。由於 map 並沒辦法處理 concurrent R/W，所以你要怎樣做呢？ 解決方法 1：改用專用的 concurrent map （如 Go 的 sync.Map） 這個解決方法簡單直接，我就不再詳細解釋了。然而由於我在開發 Zoraxy 的 high concurrent access 特質，使用 sync.Map 的話會做成很高的 over-head，因此我並不是很想用它（但是也不影響 sync.Map 作為沒法解決時用的最後方案的決定） 解決方法 2：mutex lock 這算是比較正規的方案之一。在讀取和寫入之前先對 map (或是 slice) 進行鎖定，然後在寫入或讀取之後解鎖。這樣就能確保同時間只有一個 process 對這個 map 有 R/W access。但是這同時也會產生另一個問題，就是在 read lock 了之後，假設有另一個 process 也想同時進行讀取的話就必須要等前面的讀完，因此這個方案對於高並發的 request handling 來說並不是太有效率。 那聽到這裡的時候很多人會直覺的覺得：那只有 write 的時候 lock 就好啦，read 的時候檢查 map 是不是被 lock，沒 lock 的話就讀取。由於檢查的時候不會 lock，因此其他需要 read 的 process 也不會被擋不是嗎？ 聽上去好像沒錯喔？讓我簡單寫一個 pseudocode 例子： function write(){ mutex.lock() map.write("foo", "bar") mutex.unlock() } function read(){ if (!mutex.isLocked()){ //Map is not locked var value = map.read("foo") print(value) }else{ //Map is locked, retry after 100ms delay(100) read() } } mutex 的部分可以是 programming language 自帶的 mutex 功能或是簡單的 boolean，效果都是一樣的。但是如果你有注意到，你不會找到 mutex.isLocked() 這個功能。 如果你需要用到這個，很大機會你寫錯了 這是為甚麼呢？那是因為 OS 層基本運作原理所引起的。這裡對於本科沒修 Computer Architecture （計算機架構）的工程師可能比較難理解。簡單來說就是，CPU 上就只有 n 個核心，但是你的作業系統上面有很多東西在執行，所以 OS 會對上面執行的工作（process）進行快速切換。每次切換的時候因為速度很快，所以會讓你有一種它們在並行處理的感覺。而實質上，每個 process switching 都會有一個 overhead，而這個 overhead 就是為甚麼 mutex lock 沒辦法被用於檢查的原因。 其中一種常用的 scheduling 演算法：Round Robin Process Switching 關於 CPU scheduling 跟 scheduling 演算法的詳情可以看這邊 所以為甚麼 Mutex 不能檢查是不是被其他 process 鎖上？ 當你去檢查一個 mutex 是否被鎖的時候，檢查當下可能沒被鎖，但是檢查完到執行下一個邏輯的時候可能已經被另一個 process 鎖上了…

說到我房間裡的 IoT 控制系統，從 2021 年起我就一直在用一套自己開發的 IoT 協議名為 Home Dynamic。這套系統的原理和詳情可在我另一篇文章（ 從零開始的 IoT 系統設計 ）裡找到，但是簡單來說它就是一個很簡單的 HTTP RESTful request 模型下的迷你 IoT 系統，可以用於開關電燈和透過 Tasmota firmware 來控制幾個 Sonoff 的 WiFi Smart Switch 而已。 到最近，因為我香港的房間要整修，所以我就把房間裡有點 hacky 的系統升級到新的自動化系統。Home Dynamic v2 （簡稱 HDSv2）雖然在設計的時候已經有考慮到很多不同的使用場景和可能出現的問題（如 off grid control，伺服器 / relay 的 SPOF 等等），但是其控制 latency 總是讓我覺得有點煩惱。即使後來 ArozOS 改用 Golang 重寫，從按按鈕到電燈真的亮起的時間大概也只是在 2 - 3 秒內，這個速度跟我去按一個物理開關還是有很明顯的差別。所以在新裝潢的房間裡，我採用了一個更新版本的 HDS 協議來開發我的新自動化系統，現在我把它暫稱為 HDSv3。 控制器硬體部分 那說到 IoT 跟自動化，在提軟體之前一定要先講講硬體。畢竟只要硬體夠強，軟體再爛也是能跑得很順暢（望向 python） 。這次為了未來的擴展性和標準化，這次我選用了半工業級的硬體。下圖中是我用的繼電器模組，是一片市售的 4 路 WiFi 繼電器模組。它是使用 ESP12E 作為主控制器，跟先前的 HDSv2 一樣都是基於相同的 MCU。因此大部分 HDSv2 的源碼能夠直接移植到 v3 然後下載到這片板子上。雖然這片東西可以使用 110 - 220V 輸入，但是因為我原先整套系統都是用 24V 的，因此這部分的機能就白白被我浪費掉了（ 那當然，這片東西不能就這樣放在我的桌面上。因此我買了一個 DIN Rail 用的外殼，然後把整個組好的安裝到 DIN Rail 上。 現時的照明控制系統 那你可能會好奇，既然是控制燈光，那一個簡單的繼電器模組就可以做到了。旁邊那兩個盒子又是甚麼？ 如果你仔細看一下那個繼電器模組的照片，你就會發現那個模組真的單純在做切換而已，它本身並沒有供電能力。所以為了讓接上去的 LED 燈條有電力供應，就必須透過另一個裝置為 Relay 的 NO （Normally Open）端供電。這裡中間的模組就是作為一個 power distribution hub 的用法來提供 4 個相同於 Vin 的輸出和 3 個可調節的輸出。 大概原理 而最左邊的是 LED strip 的限流模組，大概就是因為 24V 的燈條用 24V 供電的話會太光，所以那個小黑色模組裡面是一個簡單的 XL6009 自動升降壓模組來把電壓調整到大約 19.2V （我喜歡的亮度） 原本是長這樣的，後來想了想還是把它放到 DIN Rail 上比較好 軟體與控制部分 講到軟體部分，就不得不提一下 IoT 技術了。說真的，雖然我知道很多不同的 IoT 通訊協議，從 MQTT（DIY 很多人用，基於 TCP/IP）、 Zigbee （IKEA 那套）到工業用的 RS485 / RS232 之類的，我還是比較喜歡用 2.4Ghz WiFi。雖然距離短、用電量高，但是本來我的裝置就是用來控制電源的（aka 長期會有電源供應），加上香港地方實在太少，我想盡量省下一個放 hub 的空間 + 本身房間已經有 WiFi 覆蓋，所以自然地 WiFi 是最好的選擇，所以我還是選擇了基於 TCP/IP 的協議。 考慮到設備的相容性、不用額外安裝程式便能控制等優點，在眾多基於 TCP/IP 的協議下我選擇了 RESTFUL。一來是所有手機都有網頁瀏覽器，即使伺服器炸掉只要有一台手機能連接到同一網絡便可以透過 p2p 的方式控制 IoT 裝置。另一個好處是 RESTFUL API 實在太通用了，從 ESPHome 到 Home Assitant，最好支援的裝置類型依然是基於 RESTFUL API 的裝置，再加上怎樣看 HTTP request 這東西在未來 10 年應該都會還存在（畢竟是 Web 技術的基礎），選它一定沒錯（ 而為了解決…

最近我在開發的 Zoraxy v3 在我開發 Zoraxy 之前我也不知道 https 證書這東西對於 reverse proxy 伺服器來說到底有多複雜。一開始的時候因為我都是用一個域名（domain name），所以 reverse proxy 裡面也是只需要處理一個主機名稱（host name）。而初代的 Zoraxy 則是直接用 TLS hello info 裡面的 server name 作為 certificate 的 key 來找到合適的 certificate 並回傳給客戶端，所以時間複雜度（time complexity）而言是 O(1) 的速度。換成程式碼大概長這樣： http.ListenAndServeTLS(":443", "server.crt", "server.key", nil) 到後來發現 virtual directory 帶來的麻煩後，Zoraxy v2 加入了 sub-domain 的支援。為了解決找 certificate 的問題， v2 的做法是讓使用者把每個 sub-domain 都 map 到一張 certificate 上面，所以結果就是同一個域名下會有很多張證書（例如說 a.example.com 會有 a.example.com 的證書、b.example.com 會有 b.example.com 的證書）。這樣設計的好處是一來找 certificate 的演算法比較簡單，二來我們可以根據 hello info 的 server name 進行也是 O(1) 時間複雜度的 certificate lookup，不用任何存取 file system 的 loop 便可以直接找到證書。 if fileExists(helloInfo.ServerName+".pem") && fileExists( helloInfo.ServerName+".key") { //Direct hit pubKey = helloInfo.ServerName+".pem" priKey = helloInfo.ServerName+".key" } 然後在 Zoraxy v2 用了這一年多之後就又出現問題了。coauthor 的其中一張證書裡面包含了幾個不同的 domain 跟 subdomain，也有使用者的證書是含 wildcard 的，也有是舊版用 Common Name 來定義（而不是 DNS entry）來標記 host name 的，結果就是一大堆 issue 就出現在 repo 上面。 SNI 的基本概念 SNI 的原理大概就是由伺服器端跟據 TLS Hello Info 的 Server Name 來自動回傳合適的 certificate 給 Client （這裡因為 Zoraxy 是一個 http proxy，那我就以瀏覽器為 client 的例子）。對於很直接的域名例如說 v1 跟 v2 裡面出現的，基本上就是只要把 certificate map 到一個 string 轉 certificate 的資料結構裡面就可以了。但是對於 v3 之後的複雜案例，則是需要一些更複雜的邏輯來處理。 相信來得我部落格的人不是工程師應該都是技術大佬，所以我就直接把 code 拿出來講好了。這裡是 Zoraxy v3 TLS 解釋器裡面最重要的 function func(m * Manager) CertMatchExists(serverName string) bool { for _, certCacheEntry: = range m.LoadedCerts { if certCacheEntry.Cert.VerifyHostname(serverName) == nil || certCacheEntry.Cert.Issuer.CommonName ==…

之前有一段時間我都在想幫 ArozOS 的桌面做一個大更新，把最頂部的仿 Ubuntu 狀態欄拿掉，可是因為開刀和學業上各種事情一直沒空完成。最近新年前剛好指導教授不在一個禮拜，所以我就來更新了一下這個久久沒時間完成的小目標。 原先 web-desktop 的界面，上下都有一個黑色的功能欄 新的 web-desktop 界面，最頂部實色的被整合到下方的欄內 日曆和通知也被移到右下方 右下方角落的那個圈圈就是以前在右上方的背景執行工作列表 其中我最喜歡的功能大概就是這個系統一覽表了。從伺服器的在線狀態，名稱，SMART 狀態到各顆硬碟的使用量都能夠直接看清楚。 嘛當然除了這個以外還加入了很多微細的使用者體驗最佳化，例如說背景加深 + 模糊的狀態來突顯某個元件之類的 未打開日曆前的背景 打開日曆後加入的 backdrop-filter blur，突出了日曆和通知欄的前置感 另外也加入了能直接進入進階分享設定的功能按鈕，比起以往要進入到 File Manager 來更改進階設定要來得更方便。 這樣的界面大概已經算得上是追到近年的 web-desktop 界面水平了吧？雖然說在 github web-desktop 的分類排行中 ArozOS 是掉到了第四位，但是以完整性來說 ArozOS 還是跟 DSM 比得上的 web-desktop 類界面（

最近因為一些意外所以要頻繁跑醫院回診，結果就是在等待跟來回的時間前後多了很多零碎的時間，所以我就不浪費這些時間來幫我用了快 6 - 7 年的 ArozOS 系統做了點更新了。但是這篇部落格並不是在講我更新了甚麼（雖然某程度上也是），而是講一下關於 Golang 處理 exec 輸出的一個小發現。 背景故事 - ArozOS 的 Disk Properties 載很慢 ArozOS 的 Disk Properties ArozOS 因為採用半虛擬磁碟架構的設計，所以每次要列出 disk space 的時候，除了一般像 Windows 那樣會列出用了多少跟全部空間是多少以外，如果磁碟空間是使用者分隔的，就要多計算使用者佔用的空間比（圖上黃色條） 這個功能原本是使用 Walk function 來實現的。因為 ArozOS 的 vfs architecture 關系，這裡我使用的是 ArozOS 專用的 filepath module （你可以把它想像成 Go 原本的 filepath.Walk var size int64 = 0 fshAbs.Walk(rpath, func(_ string, info os.FileInfo, err error) error { if err != nil { return err } if !info.IsDir() { size += info.Size() } return err }) filesize = size fshAbs 是 file system handler abstraction 的意思，大概就是「這個虛擬磁碟的檔案系統層」的 object。 另外 rpath 就是從 user space translate 過來到這個 abstraction layer 的實質路徑，如果是本機磁碟的話就會是好像 /media/storage1/users/{username}/myfile.txt 這樣的 path；如果是 network drive 的話會是跟 mount-point 的相對路徑，例如 WebDAV 或是 FTP 下就可能會出現 /myfile.txt，或是 SMB 下的 /Share/myfile.txt 之類。 這樣的 implementation 你一看就可以知道這個在 Network Drive 上是不可能實現的，因為每一個檔案 Go 都要抓它的 Stat，即是遠端有多少個檔案就會送多少個 file request 過去，所以自很早之前就 ArozOS 的 File Manager 就加入了 這個簡單粗暴的解決方法… if fsh.IsNetworkDrive() { filesize = -1 } 然而隨著我在用的 NAS 東西越來越多，這個 walk function 即使在 local disk 下也開始變得很慢。 那改用 kernel 內置的 API 來抓不就好了嗎？ 確實如此。Linux kernel 裡其實有內置一個滿好用的指令叫 du，用起來也超簡單，只要： du -sb /media/storage1 481491222874 /media/storage1 那這個資料夾總大小（byte size）就出來了。如果你想要 block size 的話可以把 b 去掉。然後就是寫一個簡單的 Go function 去把資料抓出來。 /* Get Directory Size with native…

最近我在開發一個全自動 USB TYPE C 的回流焊加熱板，需要用到一顆特殊的 PD trigger IC - IP2721 （TSSOP-16），雖然它是存在於 JLC Library 裡面，可是因為全球性供貨問題而導致沒存貨。 Order Parts - 要求訂購零件 JLC 提供一個功能叫 Order Parts，但是它並不是訂購然後附在 PCB 盒子裡給你，而是只限於用在 PCBA 上的。這個就比較簡單，當你在 PCBA 下單的時候看到需要的零件沒貨，就可以先取消訂單，然後到 Parts Order 頁面下單你需要的零件 但是由於這顆 IC 實在太難找，所以在 Order Part 所有 Supplier 都沒有的情況下，我要求了一個新的 part request。 Part Request 的流程大概這樣： 填寫你要求的零件 Mft Part Number （ 原廠零件編號 ，例：IP2721）跟 package （封裝規格，例：TSSOP-16）它會預估一個金額給你（例：0.5590 / pcs），（這個金額是預估的，如果報價不準我猜他們應該會自行吸收或是要你補差價？）並以這個金額付款訂購它會進入一個叫 Quotation 的流程，一般來說這會卡個 2 - 3 天然後如果成功 quotation 的話應該很快就會出現在你的個人 part list 了。 然而由於這顆 IC 實在到處都沒貨，所以最後還是收到了 JLC 的退款。。。 那問題就來了： 如果連他們也沒辦法 source 到這顆 IC，到底還有甚麼辦法可以買到這顆東西呢？ 不說不知道，還真的有。 JLC 還備有最後一個 fallback 用的功能，就是 Consign parts。簡單來說就是你可以透過第三方郵寄材料到他們的 SMD 倉庫，然後再由他們手動加入到你的 part list。 做法也是很簡單，首先到 Consigned Part List 裡找到你要的零件 Mft 號碼跟 package，然後點 Add to Consignment 然後只要根據他提供的地址把零件送過去就可以了。說起來很簡單，但是最困難的部分還沒出現：就是採購和運輸。 在選擇好之後會顯示個人化的收貨地址，由於含個人資料所以這裡我是抓 JLC 網站的範例圖 你看，PCBA 這東西當然是不可能靠人手來做而是使用 PnP 機器來做。因此例如散裝、袋裝之類的零件，他們是沒辦法用的。對於這個，他們的客服跟我說如果送過去的包裝不對也能貼，但是會每顆收取 0.14USD 的手工貼片服務費，以通俗的說話來講就是「你他媽的最好不要送錯喔」 他們接收而免手續費的零件包裝種類只有兩種：1. 編帶 （一條 （不能是散裝多條用膠帶黏起來）或 一整卷編帶 ）2. 托盤 那了解這個之後就可以訂零件了。由於 JLC 只接收中國大陸內的物流，所以這個時候就需要聯系華強北的專家來處理了（還好平常進口電子零件的時候收集的店家名片沒扔掉）。簡單來說就是提供你要的零件 Mft 號碼、 package 、數量，跟指定一定要單一條編帶 + 防靜電袋 + 寫上 Mft No. 發貨即可。雖然說他們建議使用 SF 物流，但是基本上只要能送到即可。 大概 3 - 4 天之後就出現在 Consignment part list 裡面 最後只要在 PCBA 的時候選擇從 My Parts 裡面抓這顆零件就可以了~ 我的板子終於要生產了啦 備注 備用件 有時候部分零件 package size 是屬於容易貼錯的大小，在你第一次 PCBA preview 的時候它會出現建議數量 > 實際所需數量的情況（例如說這裡我只做 50 片，IRLR8726T 卻要求你給 52 片） 如果這個情況剛好出現在你的 Consignment parts 上面，記得多買幾顆送過去。一般來說中國買的集成電路（含郵票孔類的模組，除非你是從一些大廠那邊買）類產品會有 8 - 10% 的不良率，所以多準備 10% 應該是足夠的了。 DIP 與 SMT 價差 如果想省錢的話，把需要插件的零件都從 BOM 表中拿掉可以省不少喔！（不過更佳的做法當然是在設計電路板的時候盡可能換成…

自從我看了 ESP8266 的 SD Web Server Youtube 教學之後，我一直都很想要自己做一個來玩玩看。你想想看，有一根可以隨身攜帶（？）、足夠便宜到可以送人而且能夠把虛擬的東西（網站）實體化，不是一件很有趣的事情嗎？ 可是之前一直都沒有時間研究這個東西，其中一個原因是以前的焊接技術還沒足夠讓我可以直的完成這個 project，另外就是因為那個時候我對燒錄器設計還是沒有甚麼概念，導致到當我要做到跟一片 Wemos D1 mini 同等效能的 ESP8266 的時候，完全沒辦法好好的設計和焊接成成品出來。 開坑 早在 2018 年，我就已經買來了一片 Wemos D1 mini 跟超級難買的 SD shield 來當小型網頁伺服器。當時的我對網頁編程和嵌入式開發還是非常的入門，結果做出來的東西就是長這樣 Wemos D1 + SD Shield + 小容量 SD 卡 雖然是能用，而且我也把它用 USB 供電吊在我的桌面旁邊當作實驗品開發了一段時間，但是由於用的是別人的 code 加上當時我並不是太熟悉 Arduino C++ （和當時還沒有 ChatGPT），導致最後開發出來的東西不但不好看而且很難用 設計嘗試，失敗收場 之後一年我試著把這個設計弄成一片真正的電路板。由於當時我還沒有開發燒錄器的能力（特別是要想辦燒焊那兩個超小的 BC817 transistor），因此我的想法是先把 ESP8266 焊到板子上，再透過現成的燒錄器對它進行開發（見下面那一排燒錄用排針），然而後來我弄著弄著就覺得不對勁，而且這種每次都要插燒錄器才能寫東西的系統感覺開發起來就很麻煩，應該不會有人想用，所以最後還是沒拿來生產。 第一代的 ESP8266 網頁伺服器，最後沒做生產真是一個明智的決定 5 年之後，我終於做出了 WebStick 原型機 WebStick 這東西其實在我腦海中已經卡住很多年了。但是一直就軟硬體技術原因無法開坑。直到最近開始學會了 drag soldering 跟找到了一款可以讓我進行超精密焊接（但是缺點是一次性）的烙鐵頭後，我終於把這個封塵多年的 project 重新抓出來做。 首先：燒錄器 網上有很多不同的設計，有自動的也有半自動（燒錄的時候要按 FLASH 按鈕）。半自動的能省下兩顆 transistor 跟兩顆電阻，但是由於編程的時候每次都要按 FLASH 和 RESET 有夠麻煩，所以我在設計的時候便選擇了自動燒錄器。以下是我參考的設計圖： 燒錄器設計圖 但是這設計圖差了點東西，就是圖裡沒有標注到 GPIO15 應該要 PULL LOW。在設計電路板的時候記得把 GPIO15 經電阻（如 10k）接地，這樣 SPI CS 才能正常使用。 為甚麼我會知道？ 這真是個他媽的好問題（被坑） 這顆電阻雖然不加也可以，但是會無法使用 SPI 另外這兩顆 BC817 的 routing 也弄得我懷疑人生，不過後來還是在板上 route 好了。 我都不知道自己當晚是怎樣發神經想到可以這樣 route 的，嘛總之能動就好了。 其次：SD 卡 ESP8266 有內置的 SPI 針腳可以用來讀取 SD 卡。很多人以為 SD 卡模組上面有特別 IC 去把 SD 卡轉換成 ESP8266 可以讀取的信號，然而實際上的讀取方法聽上去有點奇妙，就是直接把 SD 卡當成 SPI Slave Device 來讀取。 那你會好奇，如果 SD 卡可以直接接 ESP8266，那外面在賣的 SD 卡模組上面那顆 IC 是幹甚麼用的？這是個好問題，那是防呆用的（不對） 你看，不是所有 MCU 都是在用 3.3V Logic Level 的說。例如說 Arduino UNO 在用的 Atmega328 就是支援 3.3v - 5v 輸入。SD 卡只能用 3.3V 讀取，過高的通訊電壓會把它弄壞，因此很多模組為了相容更多的開發板，只好加上一顆用來轉換信號線電壓的 IC，通稱 LLC （Logic Level Converter ，大陸好像叫 「電平轉換器」）。但是由於我在用的 ESP12E 只支援 3.3V，所以剛好與 SD 卡需要的電壓一樣，所以就不用轉直接接 MCU 就好啦。 不說不知道，如果你走去翻 Wemos D1 SD shield 的設計電路圖，它基本上就只有一個 SD 卡插槽，跟一顆差不多看不見大小的電容來做 ripple filter。真的有夠簡單欸 把兩個東西整合理起 當兩個電路都有了，剩下的部分就是把電路給整合到同一片板子上。我本來是打算用名片大小的設計，這樣做不但能有一種「這是送你的見面禮」感覺，而且也有更多的空間來寫使用教學，有點像國外嵌入式工程師大神做的能跑 Linux 的名片一樣 國外工程師做的，能跑 Linux…

講到多帳戶切換系統，通常你只會在一些類似 AWS 或者 Google 那樣大規模的系統裡面才會看到，然而這並不是沒有原因的。因為有時候部分功能為了權限上的分別，不少人比起想要設定一個擁有多權限群組的用戶，反而會比較喜歡以帳戶的方式來使用不同權限群組的作業環境。 早在好幾十個版本之前，ArozOS 就可以建立不同的權限群組而且讓一個用戶加入不同的群組 單用戶多權限群組設計 原先的 ArozOS 採用多用戶多權限群組的設計，簡單來說就是每個用戶都可以加入一個或以上的權限群組，而這個用戶能做的事情和存取的儲存裝置就是 UNION of 所有的權限群組。假設群組 A 只能存取 A 的儲存池，群組 B 只能存取 B 的儲存池，那一個用戶加入了 A 和 B 的群組之後便能存取 A 和 B 兩個儲存池的資料，並在此中間自由移動和開啟檔案。 然而，不知道是不是這設計對於現代人來說太複雜了，很多人就是不會用，然後問我到底要怎樣才可以建立更多自用的使用者帳戶。建立之後他們又會來問到底要怎樣才可以把檔案在用戶之間移動，我就一整個（嗯？？？ 多用戶單權限群組設計 所以後來我在跟用戶訪談的時候，發現其實他們比較多在用多用戶單群組的用法。簡單來說，就是一個用戶只有一個權限群組，當他們想要存取另一個權限群組的資料的時候，他們便會登出原先帳戶並登入另一個帳戶。這用法通常是用來處理一些對外的服務（例如 www 的帳號來處理跟 web service 相關的檔案），但是用在 cloud desktop 上的這種要求我猜我應該是第一個 implement 的說？ 所以為了體驗這種奇怪的使用方法，我特別在 test bench 上架了一個網站，讓 www 帳戶來保存檔案。 在 www 上架的一個 html file 然後就開始設計帳戶切換的邏輯。首先，一般的帳戶切換做法是使用 client side cookie / session 對每個帳戶進行登入，然後讓用戶可以自由切換在該 browser 上任何未過期的 login session。然而，在 ArozOS 上這有點不太可行 ArozOS 的 authentication 是基於 cookie 而非 localStorage。如果設計改了的話對一些依賴 legacy login API 的系統會帶來嚴重問題ArozOS 是網頁桌面系統，相比起其他網頁的 stateless 設計，ArozOS 的桌面是 stateful 的，而且整個狀態是儲存在伺服器端部分用戶在 ArozOS 上使用 oAuth / LDAP 作為登入認證伺服器，加上之後有打算加入 Cluster Authentication System 等伺服器端較複雜的結構，在客戶端上儲存登入狀態可能比較難做到跨伺服器間的 user state transfer 所以結合上述原因，我們最後採用了一個叫 Switchable Accounts Pool 的設計。 Switchable Accounts Pool (SAP) 是一個我們設計出來的實驗性東西。它的功能大概就是以一個 pool id 來對應一堆可以切換的帳戶，而這些帳戶又會有 main / secondary 的關系，讓帳戶的登出的時候在伺服器端對該瀏覽器的登入狀態進行切換。 一開始，當主帳戶登入的時候，一個在伺服器端的 SAP 便會被建立。Creator 的名字就會寫著是主帳戶的名字。之後，用戶可以透過登入 sub-account 以取得在這個 session 結束之前，可以不斷切換到 sub-account 的權利。 當 Sub account 登出的時候，由於 main account 的 session 仍存在，因此伺服器端會直接改寫 User 的 login cookie 到原先的 creator account。 而當 Main account （即 SAP 的 Creator）登出的時候，伺服器端便會直接 discard 整個 SAP 以保護其他 sub-account 的安全（非法透過登入 sub-account 以取得 main account 的存取權）。 在邏輯搞清楚之後，剩下的便是把功能寫出來了。這裡只是一點簡單的 Go programming，技術上沒甚麼特別的所以我就不再詳談。 網頁桌面上的可切換帳戶 新增帳戶的時候需要使用密碼登入，如果是近來切換過的而 session 沒過期可以透過伺服器端免密碼切換 在一些特殊情況下，例如說 main account 的 login session expire 但是 SAP 的 session 還沒 expire ，使用者便會在登入界面看到這樣的一個 popup，讓他可以快速回復之前登入過的…

我猜很多 web devs（網頁開發者）都知道什麼是反向代理伺服器 (Reverse Proxy Server)。當您在 homelab 或 cluster 上部署多個 service 並希望使用單一gateway server 和不同 subdomain 將它們 expose 在網際網路上時，反向代理伺服器尤其有用。在這篇部落格文章中，我就來分享一下我為什麼要用 Go 開發自己的反向代理伺服器來取代Apache / Nginx 和把它部署到我的分散式 homelab 中的經驗。 甚麼是 Reverse Proxy？ 想像一下，你正在音樂節上隨著你最喜愛的表演，突然你想要一杯 冰涼的飲料。由於你不想錯過任何的表演環節，所以你派你的好朋友（即反向代理伺服器），去替你把飲料拿來（網頁內容）。你的朋友穿過人群，排隊等候，完全不會打擾你觀賞表演，最後在不知甚麼時候帶回了那杯冰涼的飲料。在這種情況下，反向代理伺服器扮演著你和音樂節混亂背後的幕後伺服器之間的中間人角色，隔離你（用戶）和後面混亂的內部網絡 routing，直接由中間人向你提供所需的內容。 不僅僅是為你轉發和中繼網頁內容 ，現代的反向代理可做到比中繼代理之外更多的事情。例如說負載平衡、故障切換（failover）等。像Nginx Proxy Manager（NPM，不是那個黑洞 npm）這樣的管理工具甚至具有內置的自動 SSL證書更新等功能。這就是為什麼反向代理通常被認為是 homelab（或任何類型的網站系統）的“核心”的原因。 那為甚麼我要重新寫一個屬於自己的 Reverse Proxy 伺服器？ 如果你是一名資深的 devops 工程師，那你一定有親身體驗過寫 Apache 或 Nginx 配置文件的痛苦，那必定是一個難以忘懷的經歷。當你試圖從 Stack Overflow上 Copy & Paste 一些看不懂的東西到你的 config 檔，並試著根據自己的了解進行修改，卻發現怎樣 route 都是怪怪的。再加上很多開源專案都很依賴於 Rewrite Rules 和 Headers 中某些特殊設置的 Setting，要讓所有 service 都能正常運行真是一件讓人痛苦的事情。更多別提到你想加入一個臨時的 routing rules 做 testing 都要進入 ssh 到後台設置的麻煩（ 在開源世界中，有一些替代方案或解決方案可解決這些問題。像 NPM 是 r/selfhost 上 Reddit 用戶最推薦的方案之一。然而，它已經快兩年沒更新了，而且聽說最新版本會弄壞很多東西。這就是為什麼我決定自己開發一個 Reverse Proxy 伺服器以解決自己未來可預見的「所有」問題。 這就是 Zoraxy 誕生的原因 Zoraxy 是一個以 Go 開發的 Reverse Proxy 伺服器。除了基本的功能外，還附了很多不同的工具和機能讓你輕易管理你的伺服器集群（當然也能用於 docker 了）。以下是一些簡單易懂的系統截圖： 登入後的主頁 一些 overview status Subdomain 設定 建立新的 Proxy Rules Proxy root （預設路由路徑） Certificates 重導向設置 存取管理 Uptime Monitor MDNS 與 IP scanner Web SSH 功能 用戶統計 登入界面 TCP Proxy （主要用來當遊戲伺服器路由，如 Minecraft Server） ZeroTier controller 有興趣了解更多或下載試用可以到 https://zoraxy.arozos.com/ 看看喔