强制 Cloudflared tunnel 使用 http2, 解决掉线问题

2023 年 3 月 1 一日附加:
Cloudflare LAX 的数据中心基本被墙的差不多了, Tunnel 最近越来越不好用, 刚刚关掉代理试了一下, 根本连不上了.
用 Tunnel 的小伙伴们不用往下看了, 本文不能解决你的问题, 也许是时候找个其他解决方法了.

最近 cloudflared argo tunnel 很不稳定.

我一开始根本没有意识到 tunnel 不稳定, 直到我跑了一个依赖 cloudflare tunnel 内网穿透的 api server, 才发现 api 的可用性还不到一半的时间, 我得每隔几个小时手动重启一下 cloudflared 的容器.

一开始我认为这是因为 cloudflared 的流量被代理了, 所以就去 openclash 设置了不代理流量, 给容器的源 ip 和目标域名都加了规则. 但是设置完之后不见好居然还更严重了. 我就开始思考难道是 cloudflare 被墙了? 防火墙敢墙 cloudflare?

閱讀全文 强制 Cloudflared tunnel 使用 http2, 解决掉线问题

V2Board 邮件 SSL routines:ssl3_get_server_certificate:certificate verify faile 解决方案

stream_socket_enable_crypto(): SSL operation failed with code 1. OpenSSL Error messages:
error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed

如题, 自己搭建的邮件服务器, 证书采用的是 Lets‘s Encrypt, 确定没有问题. PHP Openssl Extension 已装, 在命令行里跑 echo QUIT | openssl s_client -crlf -starttls smtp -CAfile /etc/ssl/certs/ca-certificates.crt -connect smtp.example.com:587 返回结果正常.

于是简单的读了一下代码, 发现发送邮件使用了 Laravel 提供的 Mail 模块. Laravel Mail 的配置文件位于 config/mail.php, 在 config/mail.php 尾部添加下面这段代码:

'stream' => [
        'ssl' => [
            'allow_self_signed' => true,
            'verify_peer' => false,
            'verify_peer_name' => false,
        ],
    ],
如图所示

保存, 再次发送测试邮件, 发送成功.

手賤刪除掉 EFI 分區嘗試重建 Windows Boot Manager

如題, 手賤刪掉了 EFI 分區 (100MB 的那個), 現在根本檢測不到 Windows Boot Manger.

首先因為我不熟 Windows 命令行, 所以打開 GParted , 在最前面空出的 100MB 新建一個 Fat32 分區, 卷標勾選 Boot、ESP.

重啟到 Windows 安裝碟, 選擇修復計算機, 選擇疑難排查, 選擇命令行, 輸入:

bcdboot c:\windows /s c:
bootrec /rebuildbcd

然後退回到疑難排查, 選擇修復啟動, 等轉一會圈之後自動開機. 成功.

這是一篇很簡單的紀錄, 最大的感想是隨身碟速度實在太慢, 希望有時間能自己焊一個 TLC 顆粒的固態盤.

WordPress Real Physical Media 插件意外導致圖片路徑錯亂救援日誌

起因

出於好奇我下載了 WordPress Real Physical Media 插件以及它要求安裝的 WordPress Media File Renamer 插件. 這個插件聲稱自己可以通過將文件 (主要是圖片) 的物理路徑和文件在 Real Media Library 中的路徑對應, 優化網站的 SEO 表現.

# 比方說, 運行插件後, 文件會被這樣移動

Old Path: /wp-content/uploads/2022/06/pic-name.png
New Path: /wp-content/uploads/2022/blog-post-name/pic-name.png

雖然知道這個對 SEO 排名沒有多大幫助, 出於好奇我還是下載並執行了該插件.

結果是災難性的, 圖片被丟的亂七八糟, 而且插件和 W3 Total Cache 的壓縮為 WEBP 功能完全不兼容, 所有 WEBP 文件都沒有被移動. 改插件更改了所有媒體庫中文件對應的文件路徑, 卻沒有更改文章中圖片的 Link, 僅僅是做了重定向, 從而大大拖慢了頁面載入速度, 大部分圖片根本不會載入, 或者顯示 404 Not Found.

經過慌亂的尋找之後, 我意識到不管是 WordPress Real Physical Media 還是 WordPress Media File Renamer 都沒有 Undo 按鈕. 又是一番尋找之後我絕望的發現我的 WordPress 沒有任何最近的備份.

閱讀全文 WordPress Real Physical Media 插件意外導致圖片路徑錯亂救援日誌

使用 DRM 更新一台二手 Dell r720xd 服务器的 LifeCycle Controller 和 iDRAC

撿垃圾收到一台 Dell r720xd 服務器做 All-in-one Homelab, 打算裝正版 Unraid, 非常不幸的是 Boot 進去就提示網絡接口不存在, 無法分配 IP.

初步鑑定為驅動問題, 于是打開 Dell 的 Lifecycle Controller (以下簡稱 LCC) 升级驱动.

更新: 其实问题在于因为 tg3 的网卡驱动和 Intel VT-d 同时开会导致数据损毁 (原文如此), 因此 Unraid 手动 Ban 掉了 tg3 的驱动. 解决方法是关闭 VT-d (重启就好了), 或者在 Unraid 启动盘 config/modprobe.d/ 目录下创建空文件 tg3.conf 来绕过检测机制, 详情请见官方 release note.

但是升级驱动界面的 ftp.dell.com 提示 DNS 解析失敗, 在網上一查發現大概在 2017 年年底就已經廢棄了 ftp.dell.com, 改為使用 downloads.dell.com , 但是 LCC 太舊不支持 HTTPS 方式更新, 插入 USB 提示找不到儲存庫.

閱讀全文 使用 DRM 更新一台二手 Dell r720xd 服务器的 LifeCycle Controller 和 iDRAC

樹莓派靜電導致外接硬盤斷開: 解決方案

問題描述

因為冬季乾燥, 家裡還養著兩隻貓, 手上常常帶著靜電. 最近常常用樹莓派跑很重的任務, 就忍不住去用手試它的溫度. (儘管有內置溫度傳感器) 結果一試就出了問題, 常常就听見一聲劈啪的靜電放電聲音, 然後用 USB 連接的磁盤就直接斷開, 如果定位到磁盤的掛載點, 就會看到下面的情況:

➜  data ls
ls: 正在讀取目錄'.': 輸入/輸出錯誤

解決這個方法最快的辦法只有重啟. 先 umount 再 mount 有沒有用我并没有去尝试.

一開始我以為是樹莓派本身的問題, 因為比較忙碌也一直沒想到解決.(不碰它就可以羅) 有一天我偶然使用朋友一台古老的 Macbook Air 時手在觸摸板上激起靜電, 結果外接的移動硬盤突然斷連, 才意識到靜電大概對 USB 3.0 有點不友好.

我找這篇文章, 大意就是靜電 (ESD) 會導致 USB 線路暫時短路, 所以 USB 電路碰到靜電就會直接斷開. 我的散熱殼和樹莓派的 USB 端口是導通的, 也怪不得靜電會影響到 USB 的連接.

閱讀全文 樹莓派靜電導致外接硬盤斷開: 解決方案

解決 Openwrt 隨機重啟/死機 問題

在裝完 Openwrt 之後, 隨機重啟的問題就一直如影隨形. 經常在 大半夜/看 Youtube 看到一半 這種尷尬的場合聽到它 滴滴滴滴滴 重啟的聲音. 嘗試過很多種辦法, 無果.

每次重啟都會導致運行在 Openwrt 下的一堆設備停擺 5 – 10 分鐘. 期間 Wifi 無法使用, 博客也無法訪問. 幸而 Openwrt 可以自動重啟, 因此問題不算太大.

JetPack 毫不留情的轟炸我的郵箱
閱讀全文 解決 Openwrt 隨機重啟/死機 問題

WordPress Enligher 插件適配主題

感覺博客缺少一個代碼高亮插件, 所以我就挑了一個免費的, 功能比較多的插件 Enligher 安裝到博客.

好用但是挺好用, 但是好像和當前的主題不太兼容, 具體症狀請見下圖:

可以看見, 不管是編輯器還是實際文章, 這個插件都有兼容性問題.

所以我馬上要做的事情, 就是找出問題並自己解決掉.

我沒有學過任何關於 CSS 或者 JS 的知識, 以下所有紀錄都來源於常識… 如果我有哪邊做錯, 歡迎在評論區指正😄

(下文所有的修改都會寫在文末的 patch 文件中)

編輯器部分

錯位修正

margin 的左右都是 0

這個比較簡單, 修改 enlighter/resources/gutenberg/enlighterjs.gutenberg.min.css , 如下所示:

div[data-type="enlighter/codeblock"] {
	border: 1px solid #cccbcb;
	border-radius: 5px;
	/* max-width: 100%; */
	padding: 15px
}

刪除/移動 干擾信息

右下角的提示 “EnligherJS Syntax Highlighter” 一直都在那裡, 非常佔空間而且還會產生打擾的效果, 所以我們不能讓它達到目的, 可以直接把它刪掉. 另外, 左上角的粗體字提示 Highlighting 種類未免有些太過喧賓奪主, 要是可以把它移到右下角的話豈不完美.

所以我就將 enlighter-footer 的部分刪掉, 然後將 enlighter-title 的部分移到 原來的 footer 的部分. 目前一切進行的都比較順利.

wp.element.createElement("div", {
                    className: "enlighter-header"
                },
                    /*wp.element.createElement("div", {
                        className: "enlighter-title"
                    }, (e = t.language, s()[e] || "Unknown language"))), wp.element.createElement(u, {
                        value: t.content,
                        onChange: function (e) {
                            return n({
                                content: e
                            })
                        },
                        placeholder: "Insert Sourcecode..",
                        "aria-label": "Code"
                    }),*/
                    /*wp.element.createElement("div", {
                        className: "enlighter-footer"
                    },
                        wp.element.createElement("div", {
                            className: "enlighter-footer-label"
                        },
                            wp.element.createElement("strong", null, "EnlighterJS"), " Syntax Highlighter"))*/
                    wp.element.createElement(u, {
                        value: t.content,
                        onChange: function (e) {
                            return n({
                                content: e
                            })
                        },
                        placeholder: "Insert Sourcecode..",
                        "aria-label": "Code"
                    }), wp.element.createElement("div", {
                        className: "enlighter-footer"
                    }, wp.element.createElement("div", {
                        className: "enlighter-footer-label",
                    }, (e = t.language, s()[e] || "Unknown language")))),

美化

到這一步, 編輯器 Enlighter 區塊的效果是這個樣子的:

不夠完美啊!

從使用的角度來說, 它已經夠用了.
但是右下角的那一行字總覺得有點不和諧.

所以我就把它往下移動了一點點, 並且加粗.

div[data-type="enlighter/codeblock"] {
	border: 1px solid #cccbcb;
	border-radius: 5px;
	padding: 15px;
	padding-block-end: 1px /* New */
}
div[data-type="enlighter/codeblock"] .enlighter-footer-label {
	text-align: right;
	font-size: 10px;
	font-family: Menlo,Consolas,monaco,monospace;
	color: #23282d;
	cursor: pointer;
	padding-top: 3px; /* New */
	font-weight: 800 /* New */
}

( 以上所有代碼全部由我目測得到, 且並不理解其含義, 均未考慮兼容性. 使用前請再三考慮 )

最終效果

現在感覺好多了 👌

網頁展示部分

EnlighterJS 官網按鈕倒不難去掉, 插件提供了開關可以直接把它關掉.

將 EnlighterJS website button 設為 Disable 就可以了

那麼接下來要做到就是適配暗黑模式.

適配暗黑模式的話… (撓頭) 要改的變量好像有點太多了, 暫時就不寫了吧.
本身 MDX 的暗黑模式就不太好看, 我的解決方法就是 徹 . 底 . 不 . 開 ! 這下不會有問題了吧?

Patch via Gist

Docker 默認網段巨坑

簡單的紀錄一下我瞎搞Docker的時候碰到的一個坑:
我現在要配置一個Nginx, 跑在路由器上, 地址是 192.168.10.1 ;
我要用 Nginx 反向代理一個網站, 跑在這個局域網裡面, 地址是 192.168.10.10
這其實根本就超簡單, 正常情況下沒有 Docker, 我們就直接編輯 /etc/nginx/conf.d/default.conf, 然後在裡面扔以下配置, 就直接 Ok (緩存啥的都有照顧到, 我就拿這個作為模板)

server {
    listen 80;
    listen 443 ssl http2;
    server_name 127.0.0.1;

    ssl_certificate /etc/ssl/fullchain.pem;
    ssl_certificate_key /etc/ssl/private.key;
    ssl_protocols TLSv1.1 TLSv1.2 TLSv1.3;
    ssl_ciphers EECDH+CHACHA20:EECDH+CHACHA20-draft:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:!MD5;
    ssl_prefer_server_ciphers on;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 10m;
    add_header Strict-Transport-Security "max-age=31536000";
    error_page 497 https://$host$request_uri;


    location / {
        proxy_pass https://justin.education;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header REMOTE-HOST $remote_addr;

        add_header X-Cache $upstream_cache_status;

        #Set Nginx Cache

        proxy_set_header Accept-Encoding "";
        sub_filter "http://192.168.10.10" "https://192.168.10.1";
        sub_filter "https://192.168.10.10" "https://192.168.10.1";
        sub_filter_once off;


        proxy_ignore_headers Set-Cookie Cache-Control expires;
        proxy_cache_key $host$uri$is_args$args;
        proxy_cache_valid 200 304 301 302 10m;
    }
}

然後就一直提示我 502 Bad Gateway, 我就 …

光看截圖你就知道我該有多 Mad

愣是浪費我整整一個小時時間來檢查哪裡有問題, 所以說思維定勢真的不可取, 你說他每次用都好好的, 怎麼一到 Docker 上面就出問題?

不過萬幸的是我想起來起看了一眼日誌 (日誌一定得看啊) , 然後發現一直提示訪問 172.17.0.1 報錯…

於是我去谷歌上面搜了一下 鏈接 , 發現 172.17.0.1/16 是 Docker 自己的一個網段, 是通過 NAT 橋接到 Host 網絡的.

這就… 怪不得. 都不在一個網段裡面, 訪問得到才有鬼

知道就好辦, 直接在 Portainer 裡面從 Bridge 改為 Host 就解決了問題.