AWS 的 CA 更新 (CA-2019),將會影響與資料庫相關的服務

AWS 要開始使用新的 CA 發各種資料庫相關服務的 SSL endpoint (包括 RDSAuroraDocumentDB),看一下差不多是十多天前的消息,不知道為什麼突然發個緊急通告:「Urgent & Important – Rotate Your Amazon RDS, Aurora, and Amazon DocumentDB (with MongoDB compatibility) Certificates」。

本來的 CA 是 CA-2015,將在 2020 年到期:

March 5, 2020 – The CA-2015 certificates will expire. Applications that use certificate validation but have not been updated will lose connectivity.

所以會有裡面提到的事項要處理,其中前幾天讓新的 CA-2019 變成新機器的預設值,但如果有需要,還是可以選舊的:

January 14, 2020 – Instances created on or after this date will have the new (CA-2019) certificates. You can temporarily revert to the old certificates if necessary.

可以把 https://s3.amazonaws.com/rds-downloads/rds-ca-2019-root.pem 拉下來用 openssl x509 -text -in rds-ca-2019-root.pem 看,另外把網址裡的 2019 改成 2015 也可以拉到舊版的。

不過看起來沒有用 X.509 Name Constraints 限制在只有自家 RDS 的網域...

CloudFront 的新拓點...

Amazon CloudFront 這次公告增加了新的節點,都是該地區的第一個點,可以大幅降低 latency:「Amazon CloudFront launches in five new countries - Bulgaria, Greece, Hungary, Kenya, and Romania」。

這種點就是拿來認地名的,這波算是比較熟悉的... 保加利亞、希臘、匈牙利、肯亞、羅馬尼亞,拉維基百科的資料:

保加利亞共和國(保加利亞語:Република България) 通稱保加利亞,是位於歐洲東南部巴爾幹半島上的一個國家。它與羅馬尼亞、塞爾維亞、北馬其頓、希臘和土耳其接壤,東部濱臨黑海。

希臘共和國(希臘語:Ελληνική Δημοκρατία,希臘語發音:[eliniˈci ðimokraˈti.a])[8][9],通稱希臘(希臘語:Ελλάδα,希臘語發音:[eˈlaða]),是位於歐洲東南部的跨大洲國家。2019年其人口為1,080萬。雅典為希臘首都及最大城市,塞薩洛尼基為第二大城市。

匈牙利(匈牙利語:Magyarország),是一個位於中歐的內陸國家[10],但是長期和東歐、南歐歷史有關聯。匈牙利與奧地利、斯洛伐克、烏克蘭、羅馬尼亞、塞爾維亞、克羅埃西亞和斯洛維尼亞接壤,人口976萬,首都為布達佩斯。官方語言為匈牙利語,這是歐洲最廣泛使用的非印歐語系語言[11]。

肯亞共和國(斯瓦希里語:Jamhuri ya Kenya,英語:Republic of Kenya,/ˈkɛnjə/,或/ˈkiːnjə/) 通稱肯亞,是位於東非,瀕臨印度洋,與索馬利亞、衣索比亞、南蘇丹、烏干達、坦尚尼亞接壤,面積約58萬平方公里[2]。肯亞人口約5051萬,一共有42個民族[8],分成班圖、尼羅和庫施特三大語系[9],官方語言是英語和斯瓦希里語。全國分為47個縣市[2],首都為奈洛比[10]。

羅馬尼亞(羅馬尼亞語:România),位於歐洲東南部。羅馬尼亞國境西方分別為匈牙利與塞爾維亞接壤,保加利亞在南方,北方與東北方則是烏克蘭與摩爾多瓦共和國。羅馬尼亞有一小段位於黑海邊的海岸線,多瑙河幾乎佔了南邊與保加利亞之間的國界大半,並且從該國東邊海岸流入黑海的西岸。羅馬尼亞的首都為布加勒斯特,位於該國南部多瑙河支流登博維察河所流經的平原地帶上,是羅馬尼亞第一大城與工商業城市。

所以是東歐、東南歐、中歐、東非、東南歐...

Windows 7 終止支援

Windows 7 跳出畫面才發現 2020/01/14 終止支援,官方的說明可以在「Windows 7 support ended on January 14, 2020」這邊看到。維基百科上也查的到資料:

Mainstream support ended on January 13, 2015.
Extended support ended on January 14, 2020.
Extended Security Updates paid in yearly installments for 1, 2, or 3 years (or free for Windows Virtual Desktop users) until at most January 10, 2023 only for Professional and Enterprise volume licensed editions.

大量授權用戶可以採購延伸授權,另外 Windows Virtual Desktop (跑在 Azure 上的版本) 則是免費提供。雖然沒有更新,但我猜可能還是會有人把 patch 整理出來讓使用者裝吧...

TCP Congestion Control Algorithm 的選擇

先前 Ubuntu 桌機用 BBR 跑了一陣子,但有遇到一些問題 (可以參考「Dropbox 測試 BBRv2 的結果」這篇),所以暫時換成 Westwood,但還是陸陸續續會看一下各種研究。

剛剛在「[tor-relays] TCP CCA for Tor Relays (and especially Bridges)」這邊看到一個經驗談:

Here are my completely unscientific scribbles of how all the various algorithms behaved. The scenario is uploading for a minute or so, observing the speed in MB/sec visually, then recording how it appeared to change during that minute (and then repeating this a couple of times to be certain).

tcp_bic.ko       -- 6...5...4
tcp_highspeed.ko -- 2
tcp_htcp.ko      -- 1.5...3...2
tcp_hybla.ko     -- 3...2...1
tcp_illinois.ko  -- 6...7...10
tcp_lp.ko        -- 2...1
tcp_scalable.ko  -- 5...4...3
tcp_vegas.ko     -- 2.5
tcp_veno.ko      -- 2.5
tcp_westwood.ko  -- <1
tcp_yeah.ko      -- 2...5...6

上面是「目視法」觀察到的速度 (MB/sec),看了一下維基百科上 TCP-Illinois 的說明,看起來設計的目的是提供給頻寬大、latency 高的情境下:

It is especially targeted at high-speed, long-distance networks.

來跑跑看好了...

nginx + fcgiwrap (spawn-fcgi) + Mailgraph

手上還是有固定一台機器是自己架設 Postfix 管理郵件系統,所以還是想跑個 Mailgraph 看一下有多少量在上面跑...

不過因為 Mailgraph 的 web interface 只有 CGI 界面,但 nginx 不支援 CGI,所以需要找個工具透過 nginx 支援的 FastCGI 轉換進去。

概念與設定都不算太難,但是得把工具找齊才會動 (這段花了不少時間),所以記錄一下怎麼做,以後找比較好找資料。

首先先裝 Mailgraph 與 fcgiwrap:

sudo apt install -y fcgiwrap mailgraph

這兩個程式預設都會跑起來。如果沒有的話自己用 sudo service fcgiwrap statussudo service mailgraph status。接下來在 nginx 的找個 virtual host 裡面這樣設:

    location /mailgraph/ {
        index mailgraph.cgi;

        location ~ \.cgi$ {
            include fastcgi.conf;

            fastcgi_pass unix:/var/run/fcgiwrap.socket;
        }
    }

然後把 Mailgraph 的 CGI 與 css 透過 symbolic link 建到 document root 的 mailgraph/ 下:

export DOCUMENT_ROOT="/srv/home.gslin.org"
cd "${DOCUMENT_ROOT}"
sudo mkdir mailgraph
sudo ln -s /usr/lib/cgi-bin/mailgraph.* .

接著重讀設定檔,或是重跑 nginx,就應該可以在 https://virtualhost.com/mailgraph/ 下看到了。

在家裡遺失 Kindle 的找法...

Hacker News Daily 上看到的文章,作者遺失了 Kindle,但是確定在家裡 (因為在 router log 上看得到):「Any way to find a lost Kindle inside a house?」。

然後作者發現每天早上五點半到六點半 Kindle 會自己同步,所以塞了一個夠大的 PDF 進去以確保有夠長的時間連在網路上,然後用三台跑 Kali Linux 的筆電定位,完全是一個殺雞用牛刀的概念 XDDD (還是他家真的超大?)

但記得這要在剛遺失的時候就要找,不然等到 Kindle 的電池也沒電就沒救了 XDDD 以原文作者的情況,如果真的是這種 case 說不定到時候會拿金屬探測器掃 XDDD

Arch Linux 決定把套件壓縮演算法從 xz 換成 Zstandard

看到 Arch Linux 的公告,他們決定把套件的壓縮演算法從 xz 換成 Zstandard:「Now using Zstandard instead of xz for package compression」。

從 xz 換成 Zstandard 主要的原因在於不用犧牲太多空間 (多 0.8% 的空間),但解壓縮的速度可以大幅提昇 (提昇 13 倍):

zstd and xz trade blows in their compression ratio. Recompressing all packages to zstd with our options yields a total ~0.8% increase in package size on all of our packages combined, but the decompression time for all packages saw a ~1300% speedup.

看起來是不斷發酵... 在幾個月前隔壁棚的 Fedora 先換過去了,計畫在「Changes/Switch RPMs to zstd compression」這邊可以翻到,而 issue tracking system 上的記錄可以參考「Issue #350: F31 System-Wide Change: Switch RPMs to zstd compression - release-notes - Pagure.io」。

看起來會是趨勢了...

CVE 成長速度好快啊...

看到 phpBB 公告的「phpBB 3.2.9 Release - Please Update」這邊,裡面提到了安全性更新的 CVE 編號:

The issues have been assigned CVE-2020-5501 and CVE-2020-5502 respectively.

想說今年也才過完六天而已... 撈了一下資料,發現寫這篇文章當下,CVE 編號已經被申請到 CVE-2020-5956 了,這速度有夠快 XDDD

Raspberry Pi 4 的散熱問題

找被動散熱資料的時候翻到的,Raspberry Pi 4 有新的韌體可以刷,而新的韌體會降低一些功率消耗,也讓溫度降一些:「Thermal testing Raspberry Pi 4」。

會找被動散熱是因為手上的 Raspberry Pi (一代) 已經壞了兩顆風扇了,大概每年要換一次,風扇的成本是不高,但換起來總是頗麻煩...

而新的 Raspberry Pi 4 在拿到後,發現整包附的是散熱片 + 風扇組合,跑起來也還不錯,但長遠來看還是希望找個被動散熱方案...

目前看到幾個測試,一個是搜尋到在 Reddit 上的「Raspberry Pi 4 heatsink testing」這篇 (或是作者自己的 blog 上:「Raspberry Pi 4 heatsink testing」),裡面提到散熱片夠大,或是用銅製散熱片,在全速跑的時候不會降速:

另外在「Raspberry Pi 4 ICE Tower CPU Cooling Fan Tested」這邊也有看到不開風扇情況下,用散熱塔也行:

另外是整個機殼都拿來散熱的方式,看起來也還行:

如果真的不夠用而需要再拼的話,也許會考慮製冷片,不過先買個殼測試看看...

Dropbox 測試 BBRv2 的結果

BBRv1 有不少問題,在 BBRv2 有一些改善 (目前還在測試階段,在「TCP BBR v2 Alpha/Preview Release」這邊可以看到一些說明),而 Dropbox 則是跳下去測試,並且公佈結果:「Evaluating BBRv2 on the Dropbox Edge Network」。

Spoiler alert: BBRv2 is slower than BBRv1 but that’s a good thing.

在文章開頭的這張圖就說明了 BBRv2 的速度比較慢,但是說明這是朝好的方向改善。

BBRv1 的問題其實我自己都有遇到:我自己的 Ubuntu 桌機跑 BBRv1,在我上傳大量資料的時候 (只開一條連線),會導致 PPPoE 的 health check 失敗,於是就斷線了,另外 VM 裡面的 Windows 7 因為也是 bridge mode 跑 PPPoE,也可以看到斷線嘗試重連的訊息,於是只好改掉...

上面提到的問題就是 BBRv1 造成 packet loss 過高,除了我遇到的問題外,這對於其他 loss-based 的 TCP congestion algorithm 來說會有很大的傷害 (i.e. 不公平):

Other tradeoffs were quite conceptual: BBRv1’s unfairness towards loss-based congestion controls (e.g. CUBIC, Compound), RTT-unfairness between BBRv1 flows, and (almost) total disregard for the packet loss:

另外一個改善是 BBRv2 加入了 ECN 機制,可以更清楚知道塞住的情況。

整體上來說應該會好不少,不知道之後正式釋出後會不會直接換掉 Linux Kernel 裡的 BBRv1,或是不換,讓 BBRv1 與 BBRv2 共存?