用 Amazon SES 發 Trac 通知信的問題

Trac 在發 ticket 的通知信時,會定義自己的 Message-ID,另外後續變更的通知信件會增加 References 欄位,讓 mail client 可以配對起來 (變成一個 thread)。

Amazon SES 會把原來的 Message-ID 改掉,使用自己的 Message-ID 欄位,可是 References 欄位仍然維持不變... 這就導致 mail client 無法將第一封信 (只有被改過的 Message-ID) 與後續的信件 (References 所指到的信件不存在) 配對起來,只剩下後續的信件因為有相同的 References,所以 mail client 可以正確的配對起來。

所以我就決定生一個 workaround plugin,只要是沒有 References 的信件 (像是每張 ticket 的第一封信),就從 Message-ID 複製一份到 References 裡,這樣就可以讓後續的通知信件與第一封也連結起來了。另外評估這個 workaround 的副作用應該還好,所以就不判斷是不是 ticket 的通知信了...

這就是 trac-references-mail-decorator 這個套件的由來...

Raspberry Pi 4 的 Type C 無法使用 Macbook Charger 供電的問題

Raspberry Pi 4 出來後有些災情 (畢竟又加了不少東西近去),在 Hacker News 上看到的 Type C 介面的充電問題:「Raspberry Pi 4 not working with some chargers (scorpia.co.uk)」,引用的原文可以在「Pi4 not working with some chargers (or why you need two cc resistors)」這邊看到,裡面提到了新的 Type C 供電介面在接某些充電器時不會供電 (包括了 Macbook 的充電器):

The new pi has been released and it has a USB Type-C connector for power however people are finding some chargers are not working with it (notably macbook chargers). Some have speculated that this is due to a manufacturer limitation on the power supplies however it is actually due to the incorrect detection circuitry on the Pi end of the USB connection.

這樣說有點偏頗,但是 Macbook 的充電器一向是 Type C 裡的指標,如果這顆充電器跟其他裝置配合上有問題,通常都是代表其他裝置的實作有問題... (噗)

這次發現的電阻問題看起來有點苦 (看起來需要改版子),目前文章作者建議的 workaround 主要就是「不要用那麼好的設備」,比較簡單的包括了 Type C 的線不要那麼好 (像是找充手機用的線就好,不要找拿可以跑 5A 的線),或是透過 Type A 轉 Type C 的線也應該可以避開這個問題,最差的情況應該是找其他的充電器:

Now onto some solutions. Assuming the issue you are having is caused by the problem discussed above, using a non e-marked cable (most USB-C phone charger cables are likely this type) rather than an e-marked cable (many laptop charger/thunderbolt cables and any 5A capable cable will be in this category) will allow for the pi to be powered. In addition using older chargers with A-C cables or micro B to C adaptors will also work if they provide enough power as these don’t require CC detection to provide power. Ultimately though the best solution in the long run will be for there to be a board revision for the pi 4 which adds the 2nd CC resistor and fixes the problem.

對於已經入手的人,如果真的中獎,workaround cost 應該還在可以控制的範圍...

HiNet 對於 DNS flag day 的公告

先前提到了各大 Public DNS 服務將會在二月正式關閉對 EDNS 的 workaround,也就是 DNS flag day:「從二月開始不回應 EDNS 的 DNS server 將會無法查詢」,而 HiNet 也發出對應的公告了:「(DNS flag day) 部分Public DNS業者將於2019年2月1日執行EDNS符合性驗證」。

說明:一、 因應部分Public DNS服務(如Cloudflare 1.1.1.1、Google 8.8.8.8、IBM 9.9.9.9等)將於2019年2月1日執行EDNS符合性驗證(Extension mechanisms for DNS, DNS延伸機制),屆時如不支援EDNS協定之域名將造成Public DNS無法順利解析或解析反應變慢。 ( 參閱TWNIC 2019-01-23最新消息 https://blog.twnic.net.tw/2019/01/23/2286/ ) 二、 使用HiNet DNS服務(168.95.1.1與168.95.192.1)及HiNet代管DNS服務,皆可正常解析不受影響。 三、 若使用上述Public DNS服務,發生有部分域名無法解析情況,可改使用HiNet DNS服務,即可恢復正常解析。

一方面說明他們有處理他們自己的 DNS hosting,另外一方面順便推廣一下自家本來的 168.95.1.1168.95.192.1,但目前沒打算拿掉 DNS flag day 的 workaround XDDD

從二月開始不回應 EDNS 的 DNS server 將會無法查詢

在「DNS flag day」這邊看到 EDNS 的 workaround。

目前的 workaround 是在 DNS server 對於 EDNS 查詢沒有回應時,就改用不帶 EDNS 的查詢再問一次,以確保相容於不支援 EDNS 而且會直接過濾掉這些封包的環境。

而從今年二月開始,這個 workaround 將會被拿掉,當帶 EDNS 的查詢沒有回應時就直接當作伺服器死掉,不會再用沒有 EDNS 的查詢問一次:

The main change is that DNS software from vendors named above will interpret timeouts as sign of a network or server problem. Starting February 1st, 2019 there will be no attempt to disable EDNS as reaction to a DNS query timeout.

This effectivelly means that all DNS servers which do not respond at all to EDNS queries are going to be treated as dead.

往下可以看到會做出改變的廠商包括了 GoogleCloudflare,可以預期 8.8.8.8 (8.8.4.4) 與 1.1.1.1(1.0.0.1) 都會進行更新。

網站上面有可以查詢的工具,剛剛查了一下以前的公司與競爭對手,發現 1111.com.tw 看起來會掛掉,不知道二月前會不會修正這個問題... XD

VirtualBox 5.2 的 0day 爆破...

Hacker News Daily 上看到「VirtualBox E1000 Guest-to-Host Escape」這篇,講 VirtualBox 5.2 的機器上 E1000 + NAT 模式的爆破... 另外在 Hacker News 上的討論也提到了很多這樣做的背景:「VirtualBox E1000 Guest-to-Host Escape | Hacker News」。

Oracle 對社群的態度 (無論是 open source community 或是 security community) 都一直是社群很不爽的事情。

這次爆破的發現人之前找到一個 VirtualBox 的 security bug (參考「SSD Advisory – VirtualBox VRDP Guest-to-Host Escape」),回報後先是回應他們在處理中,然後被發現 VirtualBox 在 5.2.18 修掉了,但是完全沒有提到安全性問題的事情。所以這次作者也懶得囉唆了,找到就 full disclosure 出來。

作者給的 workaround 有兩個,優先建議暫時先用 PCnet 系列的界面,如果不行的話,至少不要用 NAT。

作者發表後沒多久馬上就有 5.2.22 推出,不過看 changelog 應該是沒有修正這個問題?(或是修掉又沒提...)

解 ocserv 因為沒有使用 DTLS 而導致速度很慢的問題...

最近偏好用 ocserv 來跑 VPN。在連上 full-route VPN 後測試發現速度偏慢,發現是沒有走 UDP 的 DTLS,只有 TCP 的 TLS 流量... 找了一下發現用有人遇過了,可以用 workaround 解:「OpenConnect not working with DTLS」。

作者發現是 ocserv.socket 有問題,打算整個抽開。方法是註解掉 /lib/systemd/system/ocserv.service 裡的 Requires=ocserv.socketAlso=ocserv.socket,然後在 systemd 裡一起處理:

sudo systemctl stop ocserv
sudo systemctl disable ocserv.service
sudo systemctl disable ocserv.socket
sudo systemctl daemon-reload
sudo systemctl start ocserv
sudo systemctl enable ocserv

重新連上去後跑 tcpdump 可以看到是 UDP 了,測速也可以看出來快不少...

在 Ubuntu 18.04 (Bionic) 上跑 Percona Server 5.7

Percona 的文件「Installing Percona Server on Debian and Ubuntu」這邊雖然還沒列 Ubuntu 18.04 上去,但已經有東西在裡面可以安裝了。不過還是屬於官方未正式支援的情況,用的時候自己要注意。

另外查資料的時候有看到「Ubuntu 18.04 (bionic) - percona-xtradb-cluster-server installation break」這篇提到 Percona XtraDB Cluster 裝不起來,但有 workaround 可以硬裝進去,要玩的人也可以參考一下 XD

這樣可以把 14.04 機器換一換了。(先前清點時本來以為已經是 16.04,做一些操作時才發現是 14.04...)

MySQL 的 binlog 對效能的影響

Percona 的 CTO Vadim Tkachenko 在比較 InnoDB 與 MyRocks 時意外發現了 binlog 會影響不少效能穩定性,再加上 MySQL 8.0 有改變 binlog 相關的預設值,所以他後續花了不少時間測試,寫了兩篇關於 binlog 對於 MySQL 效能的影響:「How Binary Logs (and Filesystems) Affect MySQL Performance」與「How Binary Logs Affect MySQL 8.0 Performance」。

第一篇是想要知道在 Percona Server 5.7 上開 binlog 的影響,做出來後可以看到明顯的效能波動 (因為 binlog 導致 flush 時效能暴跌):

而其中的 workaround 就是調整 flush 參數,讓他比較頻繁的小量寫入,而不是突然要寫很多資料。這樣一來對平均效能也許比較差,但對前端應用衝擊會比較小:

在測試可以看到 sync_binlog=1000 是個妥協點。各單位要自己去找出適合的數字:

The strict setting also comes with noted performance penalties. I will also test sync_binlog=1000 and sync_binlog=10000, which means perform synchronous writes of binary logs every 1000 and 10000 transactions, respectively.

另外有測試 ext4 與 XFS 是否有影響,就測試的結果看起來 ext4 比 XFS 好一些,但差距有限:

第二篇則是拿 MySQL 8.0 與 Percona Server 5.7 比較,可以發現在 MySQL 8.0 開啟 binlog 時有時會有不少的效能損失:

It seems that binary logs have quite an effect MySQL 8.0, and we see up to a 30% performance penalty as opposed to the 13% for Percona Server for MySQL 5.7.

雖是推銷一下自家產品在這塊還不錯 XD

針對 Ubuntu 16.04 + PPPoE 時,OpenNTPD 的 -s 不會在啟動時直接校正的問題 workaround...

發現機器時間跟標準時間差了 40 秒左右,結果有些服務因為會看雙方時間,就不讓我跑... XDDD

找問題找了半天,發現開機後 ntpdate 會回報找不到伺服器,看起來是網路根本就還沒通就跑起來了:

Jan 25 13:10:30 home ntpdate[757]: name server cannot be used: Temporary failure in name resolution (-3)
Jan 25 13:10:30 home ntpdate[1171]: name server cannot be used: Temporary failure in name resolution (-3)
Jan 25 13:10:30 home ntpdate[1347]: name server cannot be used: Temporary failure in name resolution (-3)
Jan 25 13:10:30 home ntpdate[1410]: name server cannot be used: Temporary failure in name resolution (-3)

而理論上 與 openntpd 加上 -s 也會做類似的事情,所以這邊就在 /etc/default/openntpd 先加上 -s,讓他開機時強制對時一次,看看能不能解... 結果也是一樣在網路還沒通的時候就跑起來而失敗了:

Jan 25 13:10:45 home ntpd[1457]: no reply received in time, skipping initial time setting

由於這台機器是 HiNet 的 PPPoE,看起來有可能是某些條件沒寫好,造成執行順序不對... 所以就找個 workaround 來解決 @_@

後來找的方法是直接到 /etc/ppp/ip-up.d/ 下放一個 script 實作 workaround,直接在 PPPoE 連上後重跑 openntpd,然後用 hwclock 寫回主機裡,下次開機的時間就會比較準一些了:

#!/bin/sh -e

/usr/sbin/service openntpd restart
/sbin/hwclock -w

不過實際上還是要找看看要怎麼把 PPPoE 掛到 networking 那層行為裡面...