Weil Jimmer's Blog

[筆記] Git 儲存庫從 SHA256 降級為 SHA1 經驗

前言

昨晚心血來潮，用了 Gitea 建了一個儲存庫，那時候手賤選了 SHA256，想說要用最新的，結果當我寫完專案，想要備份到 Github 上，才發現推送不上去，跳出錯誤。

fatal: the receiving end does not support this repository's hash algorithm
fatal: the remote end hung up unexpectedly

看到關鍵詞 hash algorithm 就知道是選了 SHA256 的黑鍋。

如果遇到，最快的方式是直接建一個新專案，然後 add 全部代碼，然後 commit，這是最快的解法。

當時，就是想要保留歷史紀錄，結果找老半天，沒找到怎麼保留歷史紀錄轉換成 SHA-1 的方法，真的是爬很多資料，試了一堆方法。

下面分享我試成功的命令。

將 SHA256 專案轉成 SHA1 的格式

在 SHA-256 repo 中，export 紀錄。

cd original-repo
git fast-export --all --use-done-feature --reencode=yes > ../export.dat

建立 SHA1 的新專案

cd ../new-repo
rm -rf * .git  # 清空目錄
git init --object-format=sha1

匯入所有歷史紀錄

git fast-import --quiet < ../export.dat

重建 & 清理

git checkout main
git gc --aggressive

重新簽章(非必要)(Rebase)

git rebase --root -i --exec 'git commit --amend --no-edit -S'
# -i 代表互動模式
# --root 從第一個提交開始
# -S 代表用目前的 GPG key 簽署

使用 PVE 與 OpenWrt 23.05 實現鏈路聚合 LACP 及 VLAN 建立多個虛擬區域網路的踩坑經驗

前言

按照最近的慣例，開頭要先說一段廢話，最近因為家裡空間不夠放交換器，於是訂了一個機櫃，打算重新整理我亂七八糟的網線和複雜的網路環境，以及升級我的 OpenWrt 版本，下為我房間的機櫃照。

花了我滿長的時間在進行除錯，裝設機櫃反而沒什麼，最大的問題在於用 OpenWrt 設定 VLAN。

先前我灌了 ImmortalWrt 23.05.2，想說我之前裝的 OpenWrt 有點舊，而且還是當時的 SNAPSHOT 版本，已經遇到過好幾次要安裝什麼軟體包，出現內核版本過新或過舊的問題，實在不能接受，所以趁這個時機升級一下。

然後在 ImmortalWrt 安裝鏈路聚合所需要的軟體：

opkg update
opkg install kmod-bonding luci-proto-bonding

試了老半天，都沒有成功耶，在交換器那邊總是顯示 Blocking，害我在思考是不是交換器的問題，但是後來我在 NAS 上設置成功，所以我覺得是 ImmortalWrt 的問題。

直到一天後，我才終於意識到問題出在哪裡，在於那個被我遺忘的 PVE 阿！原來我一直錯怪了 ImmortalWrt。

因為底層是 PVE，我在虛擬機中設置鏈路聚合只是在它的虛擬網卡上聚合而已啊，所以應該在 PVE 上設置。

在 PVE 上建立 Linux Bond

首先到你的資料中心，然後選擇你的「節點」，再選擇 System → Network，點 Create 選擇 「Linux Bond」。

Slaves 輸入你想要聚合的網卡，我目前軟路由上有四張網卡，但我只選擇其中三張聚合，其中一張要給 WAN 使用，而且 PVE 也使用這張網卡，設定下去的話，會失去 PVE 的連線，因此我只選中三張。

模式就用 LACP，接著直接創建即可，之後你多出來一個 bond0 網卡，就是你聚合後的結果。

接著就到你的交換器上設定鏈路聚合（Link Aggregation, LACP），LACP 是我比較推薦的模式。

在 PVE 上建立 Linux Bridge

建立一個虛擬網橋 vmbr1，作為我的 LAN 區網用，這裡有一步驟很重要，那就是要把 VLAN aware 打勾。

回想起幾個月前，第一次在 ImmortalWrt 設定的時候，老是出問題，其實就是 PVE 沒設定好，那時候沒有打勾這個選項（我也根本沒注意到這選項），自然 VLAN 接口收不到封包阿。

到這步，PVE 設定完之後就沒 PVE 的事了。

開啟 OpenWrt 23.05

這次我安裝的版本是 OpenWrt 官方的 openwrt-23.05.3-x86-64-generic-squashfs-combined-efi.img。

手動裝了一些軟體包，比如主題 (Argon)、和繁體中文。

建立 VLAN 裝置

鑒於有了先前的經驗，基本駕輕就熟。直接到 網路 → 介面 → 裝置 → 加入裝置設定。

這邊直接選擇 VLAN (802.1q)，預設值應該已經有了，新版本的 OpenWrt 已經拔掉了 Switch，所以很多文章和教學都過時了，很少人提到新版本的 OpenWrt VLAN 的設置。

VLAN ID，按照我這邊的環境，就是 10、20、30、40、50，直接重複五次，建好建滿。即使網路孔位沒有那麼多也沒關係，這邊已經虛擬化了。

像這樣，我建立了 VLAN 10～50 的網路裝置。

建立網卡介面

到「介面」列表，點「新增新介面」，靜態位址，選擇各自的 VLAN 裝置。

比如 LAN 配 eth0.10，LAN2 配 eth0.20，LAN3 配 eth0.30…

IP 的話，按照慣例，根據 VLAN TAG 定義 Gateway IP，VLAN 10 的話，設定 192.168.10.1/24。

然後是巨坑，防火牆要建立一個新的 Zone，如果沒設定防火牆是不會通的，沒有路由的話，DHCP Server 連分配 IP 都不會分配！

然後是必須的 DHCP 伺服器，直接點安裝即可。

這邊都不需要動，維持預設就可以了。

為了防止意外，建議開啟這個功能，「強制」DHCP，以防詭異的狀況發生。

建立防火牆規則

這裡就是老話重談了，為每個新創建的區域網路新增規則，允許轉發到 WAN。

我這邊比較特別，LAN 轉發到 WG0，是 VPN 通道，這個不是通常操作。而 LAN5，我是想建立一個隔離的網路，所以沒有轉發的能力。

建立 DNS 伺服器

建立好網路後，記得要在監聽介面打開剛剛新建的所有介面，否則即使有連線遠端 IP 的能力，卻沒辦法解析網域。

到這步，基本就大功告成。

接下來就是配置交換器，設置路由器所連接的 3 個 Port 為 TRUNK 接口。

同時給予其接口為 VLAN 10、20、30、40、50 的成員。

之後有空，會再補篇關於 VLAN 的基礎知識的文章。

[筆記] 解決 Git 錯誤 fatal: repository <http://git-url> not found 的問題

問題：

最近遇到了一個從沒見過的錯誤，為此特別紀錄一下，明明已經初始化 git 倉庫，卻沒辦法從遠端經由 HTTP 進行 pull、clone、push 等動作。

會出現下面的錯誤：

fatal: repository 'http://xxxxxxx/xxx.git/' not found

但是實際上目錄是有資料的，不論是初始化過的或是直接複製 .git 資料夾都沒辦法正常的 clone 或 push。

解決方法：

直接開門見山，講重點，只是因為伺服端建倉庫時少下一個指令：

git update-server-info

只要下完這個指令後，git 會進行一系列更新或建立索引的動作（建立objects/info/packs），類似於建立一個檔案目錄清單的動作。

之後，從遠端伺服器就可以透過 HTTP clone 下 repo 了。

原由：

其實會發生這個問題的主因在於伺服端不是 Smart HTTP server。

Smart HTTP vs. Dumb HTTP：

• Smart HTTP： 支援 Git 所有功能的 HTTP 協定實現，例如 git push、git pull 等操作。 需要專門的伺服器軟體，例如 Gitea、GitLab、GitHub 等。
• Dumb HTTP： 僅支援基本的 HTTP 檔案下載功能，無法進行 git push 等操作。 通常用於簡單的 Git 倉庫發布，例如靜態網站。

Dumb HTTP 只是提供簡單的網頁儲存託管倉庫而已。

深入研究 iWin 網路封鎖的模式 以及 如何免 VPN 繞過網路封鎖

前言

最近我朋友向我抱怨，iWin 此舉竟然開始影響到他的生活，讓他覺得很幹。我個人也是這麼覺得的，既然剛好有這個案例，何不來深入研究呢，前幾日本該發文的，不過身體不舒服就懶得發文了，一直沒什麼時間，現在忙太多專案，沒什麼空。

釐清

首先呢，avhu.com 這組網域被封鎖了，依照朋友提供給我的圖片是這樣。

第一直覺應該不是擋 IP 而是擋解析，先嘗試用了一下 VPN 發現完全正常，解除了 VPN 後，發現還是能正常訪問，讓我懷疑了一下是否真有封鎖？

原來，只是因為我自己本身的網路就不是走中華的 DNS ，最終確定，應該是 DNS 汙染無誤。

DNS 汙染

何謂 DNS 污染呢，上網搜尋應該會有一大堆文章，這邊也不細說太多，基本上對岸的防火長城有一部分阻擋的方法就是 DNS 汙染。

各位在瀏覽網頁時，都會需要將網域名稱（例如weils.net）轉換成 IP (例如123.123.123.123)，然後再發送封包到目的地IP。

而 DNS 服務就是為了讓人查詢正確的 IP 是多少，使用者會去詢問這個網域他的 IP 是多少呢？DNS 伺服器才會返回正確的 IP 給使用者，這樣使用者才可以連線。

那 DNS 汙染又是什麼？只要在 DNS 伺服器投毒，讓上游的伺服器給出錯誤的 IP 地址，那你就沒辦法連線到正確的網站，會被導向到他所給予的錯誤 IP 地址，以至於無法訪問你要去的網站。

基本上 iWin 的所作所為就是 DNS 汙染，只感染國內的 ISP 業者提供的 DNS，例如中華電信的 DNS 被汙染了。

以上圖為例，如果將 DNS 伺服器設定為 中華電信 DNS。

我查詢了 weils.net 返回的結果，完全是正常的 IP 位置，也就是他是正確的 IP 地址。

而一旦查詢 avhu.com 則返回錯誤的地址（被汙染的結果）。

反之，如果我將 DNS 伺服器設定為 Google DNS，進行查詢。

結果會截然相反，avhu.com 返回的 IP 會是他原本正確的 IP。

而 IP 150.242.101.120 直接訪問的話會到下圖這個網站。

由此可知，目前的阻擋方法是屬於落後的 DNS 汙染，並沒有解析封包，攔截 SNI Host，如果這麼做的話，成本也有點太大。

解決方法

只要了解原理，基本上這種低能方法，只要改個 DNS 就可以繞過了，比如換成 Google DNS，或是其他國外的 DNS，任何一個能夠查詢到權威紀錄的 DNS 就可以了。

直接去「控制台」，找到網路和共用中心，點乙太網路，然後再點「內容」，設定IPv4，把 DNS 修改為 8.8.8.8 及 8.8.4.4 (Google DNS) 即可繞過封鎖。

就這麼簡單，沒什麼難度。

RAID 陣列降級與重建：一個自組 NAS 使用者的親身經驗 Truenas Scale

前言

記得上次組完 NAS 經過了約略一個月半，五十天左右的時間，沒想到我的二手硬碟就出事了（果然便宜沒好貨，其實是我人品太差了），就順便來寫篇文章記錄一下。

原本還期望大概可以撐個一兩年再開始慢慢換硬碟的說，沒想到兩個月不到就壞了一顆硬碟。

簡單來說就是週日下午，突然聽到很吵的聲音，正思考是什麼東西發出來的，仔細聽才發現是 NAS 傳來的，是那種磁頭反覆到硬碟上讀不到資料又復位的感覺（聲音非常像下面的影片），一聽到這聲音我就覺得這硬碟大概是沒救了。

既然沒救了，我就先提前拔掉硬碟，並且火速上網買了 ST6000NT001，而 NAS 直接呈現「降級狀態（DEGRADED）」，跳出警告。

TrueNAS @ truenas  
  
New alert:

  * Pool z2cpool1 state is DEGRADED: One or more devices is currently being resilvered. The pool will continue to function, possibly in a degraded state.  
The following devices are not healthy:

    * Disk ST6000NM0024-1HT17Z Z4D04HLW is UNAVAIL

這一連串事件，真的是打個我措手不及，我每天都在做 S.M.A.R.T. Short Test，根本沒想到硬碟會直接 GG。雖說這批硬碟剛到的時候，我其實偶爾發現硬碟會有怪聲音，但都是非常突然冒出一下就沒了，我也沒辦法定位到是哪個硬碟有問題，我上網查聽說企業硬碟讀取很吵是正常的，所以也不在意，以為企業硬碟本來就是這樣。

而現在那硬碟真的是吵到我光用聽的就知道是哪個槽出事，而且讀寫燈號也是不停的閃爍，就那槽長亮綠燈，其他的燈號都是暗的，更是直接就鎖定了是它出事。拔掉之後也沒聽到怪聲了，因此確定就那硬碟問題。

所幸，我是用 6顆 6TB 硬碟組 RAID-Z2，能容忍兩顆硬碟同時壞掉，應該算挺保險的組法了。

更換硬碟

拿到剛買的新硬碟後，就立刻將其鎖上螺絲直接裝進 NAS 中，就完全熱插拔沒有關機。

登入管理員畫面，就能看到一顆未被配置的新硬碟。

之後直接點 Manage Devices，然後選取被拔掉的硬碟，直接點 Replace 替換上目前的新硬碟。

選取硬碟，然後按下「Replace Disk」（替換硬碟）。

之後就是等待漫長的重建時間了。

畫面會顯示 REPLACING （替換中）。

同時右上角刷新的圈圈也會不斷地旋轉，顯示「Resilvering」（重建中）。

到目前為止，一切都滿順利，挺無腦的，基本上沒有甚麼大問題。UI 點開按鈕點一點就好了，剩下只需要等待重建完成。

重建狀態，大概消耗了我 30% 左右的 CPU。全部硬碟的讀寫燈號都呈現綠燈常亮，很明顯可以聽到正在寫入資料的聲音。

最後，花了我大概 65 分鐘完成重建，其實比我想像中的還快速。

看不少網路文章提到，組 NAS 必須有 UPS 不斷電系統，就是擔心在這種重建資料的關鍵時刻，突然來個停電，真的會氣死。重建的時候，似乎其他硬碟也同時死掉機會滿高的……光是想想就瑟瑟發抖。

之後系統狀態就全部正常了，原本的健康度的紅燈和橙色警告全部都沒有了。

大概是這樣，操作的部分非常簡單。

其他文章：
DIY 自組 NAS 家用私有雲 TrueNAS 安裝經驗分享