Month: August 2020

斷線討論的 mailing list

在 Hacker News 的首頁上看到的，昨天 Level3 看起來有大規模異常：「[outages] Level3 (globally?) impacted (IPv4 only)」，對應的討論串在「Level 3 Global Outage (nether.net)」這邊。

參考「AS Rank: A ranking of the largest Autonomous Systems (AS) in the Internet.」這邊可以看到 Level 3 目前的排名是 #1，這次大規模故障影響的範圍會讓很多人都有感覺...

比較好玩的是有個 mailing list 在討論這種狀況的：「Outages -- Outages (planned & unplanned) Reporting.」，雖然上面的人看起來不多就是了...

AWS 推出 Route 53 Resolver Query Logs

AWS 推出可以讓你 debug 的功能：「Log your VPC DNS queries with Route 53 Resolver Query Logs」。

這個功能可以記錄 VPC 內的 DNS query：

然後也可以統計與分析：

主要是很多 debug 會需要 DNS query，但 AWS 上不太容易看到 DNS query 資訊 (常見的方式是自己另外架 DNS Resolver)，這個功能可以緩解這個問題...

AWS 在 Los Angeles 開第二個 Local Zone

AWS 在 Los Angeles 開了第二個 Local Zone：「Announcing a second Local Zone in Los Angeles」，所以現在兩個 zone 的代碼分別是 us-west-2-lax-1a 與 us-west-2-lax-1b。

稍微回頭複習一下，發現大阪區 (Local Region) 跟東京的直線距離大約是 400km 左右，但如果是以 Los Angeles (Local Zone) 與 Portland 的話則是 1300km 左右，如果是 Seattle 的話就會到 1500km 左右。

而且 Los Angeles 的 Local Zone 是掛在 us-west-2 而不是 us-west-1 (N. California) 上面，看起來這兩個主要的差異是在商業考量上，us-west-2 應該是目前的主力 (從各種產品推出的發佈時程看得出來)，所以才會這樣規劃...

回頭翻「AWS 在 us-west-2 開 Local Zone」這篇的時候，發現當時我應該是把 Local Region 與 Local Zone 搞混了...

用 Monitorix 代替自己搞的 MRTG

先前我家裡的有線電視網路上我放了一顆 Raspberry Pi 跑各種分析，包括用 MRTG 抓流量與溫度，還有用 SmokePing 抓網路狀況。

前幾天系統掛了，本來以為是 SD 卡掛掉，換了一張上去發現還是開不了機，後來才發現是板子掛了，記得這張板子是當年還在 K 社時 zonble 送的，記得是當年一代剛出沒多久很紅，算了一下這台也跑了七八年了...

網路上找了一下找到了便宜的 Raspberry Pi 3，弄了回來後裝一裝，剛好最近接觸 Monitorix 後發現裡面已經有很多現成的設定設好，只要開起來就可以自己抓到...

現在的版本自帶 HTTP server，但我希望透過 nginx 轉進去 (包成 HTTPS)，這樣的話需要在 /etc/monitorix/monitorix.conf 裡加上：

url_prefix_proxy = https://rpi.gslin.com/

如果想要抓 Raspberry Pi 的電壓與溫度資訊，只要把檔案裡面的 raspberrypi = n 改成 raspberrypi = y 就可以了。

在 nginx 裡面把 /monitorix 與 /monitorix-cgi 轉進去，像是這樣的設髮：

    location /monitorix {
        proxy_pass http://127.0.0.1:8080/monitorix;
    }

    location /monitorix-cgi {
        proxy_pass http://127.0.0.1:8080/monitorix-cgi;
    }

比起自己搞 MRTG 設定一堆 shell script 簡單多了，cfgmaker 跟 indexmaker 用起來還是不順手。

不過 Ubuntu 上要 20.04 才有內建包進來，18.04 看起來沒有：「Ubuntu – Package Search Results -- monitorix」，目前還沒有在 18.04 上跑的需求，之後遇到再看看要怎麼處理...

Chromium (Google Chrome) 實做對 Root DNS 的影響

前幾天在 APNIC 上的這篇文章受到社群注意：「Chromium’s impact on root DNS traffic」，在 Hacker News 上也有對應的討論：「Chromium's Impact on Root DNS Traffic (apnic.net)」。

文章作者 Matthew Thomas 是 Verisign 的員工 (Verisign Labs)，可以看出來主力在 DNS 的部份。

Chromium (以及 Google Chrome) 會隨機產生一組 hostname，確認所在的網路是否有 DNS hijack：

這導致了在 Root DNS 上會看到大量不存在網域的 DNS query，這點隨著 Google Chrome 的市占率愈來愈高，在 Root DNS 上這些 DNS query 甚至佔到 40% 以上：

不過 Root Server 有上千台在跑，就目前的效能來說應該是還 OK：

As of 2020-08-27, the root server system consists of 1097 instances operated by the 12 independent root server operators.

把這個問題丟到 bugs.chromium.org 上翻，看起來有三張票在進行中：

瞄了一下裡面的討論，目前的方向有兩類，一種是主張完全關掉，這樣確定可以大幅減少對 Root DNS 的壓力，另外一種是設計 cache，使得 Root DNS 的 loading 降低。

這次有不少新聞都有報導，受到 PR 壓力看起來是動起來了... (這三張票看起來之前都沒什麼人有動力要處理)

對 Amazon Aurora (MySQL-Compatible Edition) 另外建 Replica

Percona 的人寫了一篇怎麼對 Amazon Aurora (MySQL-Compatible Edition) 生 replica 的文章：「Creating an External Replica of AWS Aurora MySQL with Mydumper」。

這邊用的方法主要是出自「Replication with Amazon Aurora」這篇，裡面有提到有 binlog 可以用，所以 Percona 的作法應該是屬於「雖然不能 100% 保證以後還是可以用，但 99% 的機會以後應該還是可以用」。

這樣搞主要應該是用在 1) 省錢，2) 需要特殊的調整；如果不是這兩種，一般會選 Aurora 版本，應該不會太在意成本，直接用他提供的 read replica 就好？

家裡搞小機櫃的文章

在 Hacker News 的首頁上看到有趣的文章，在講怎麼搞個小機櫃弄起來專業一點的玩：「Home Lab Beginners guide – Hardware」，對應的評論在「Building a Home Lab Beginners Guide (haydenjames.io)」這邊可以看到。

照這個搞法好像可以塞兩三台 1U server，不過搞的大太就會像 Brad Fitzpatrick 搞的那樣，直接上 42U rack 了 XDDD

這好像也算是某種浪漫？

NIST 對密碼學演算法建議的長度 (2020 版)

在「Comparing SSH Encryption Algorithms - RSA, DSA, ECDSA, or EdDSA?」這邊一路翻到「Keylength - NIST Report on Cryptographic Key Length and Cryptoperiod (2020)」這篇，裡面引用的是 NIST 的「NIST Special Publication 800-57 Part 1 Revision 5」。

在 NIST 的文件裡面，不同的演算法散落在不同地方，Keylength 整理起來後比較方便看。

想要特別拉出來講是因為看到 RSA 2048 bits 被放到 112 這個等級 (Security Strength)，我一直以為是 128，不過查了一下發現好像以前是就 112 了...

Amazon EBS 推出新的 io2 類型

Amazon EBS 保障 IO 效能的版本 Provisioned IOPS io1 進化了，推出了 Provisioned IOPS io2：「New EBS Volume Type (io2) – 100x Higher Durability and 10x More IOPS/GiB」。

目前先看了一下美國與新加坡的價錢，應該都還是一樣，看起來這次主要是功能性上的進步，有兩個比較顯著的改變。

第一個是每 GB 可以租用的 IOPS 數量上升了，io1 是 50 IOPS，在 io2 給到 500 IOPS；不過最大值不變，都還是 64k IOPS。這個看起來對於追求 IOPS 的人彈性增加不少，不過算了一下成本差距應該是還好，以最大的 64k IOPS 來算，光 IOPS 的費用就要 USD$4160/month，而最低的空間租量上，io1 租 1280 GB (USD$160/month) 與 io2 租 128 GB (USD$16/month) 在這個部分只能算零頭了...

第二個是持久性 (durability)，從 io1 的 99.9% 到 io2 變成 99.999% 了，這邊應該主要是受益於這十年 SSD 技術的進步。我猜本來的 io1 其實也拉高不少，只是 SLA 合約上沒有增加而已...

應該還是會守在 gp2 上，便宜大碗，不過效能的保證少了些，對於一般性的應用來說應該是夠用。