OpenSSL 決定把 release site 改到 GitHub 上

OpenSSL 宣佈了之後會以 GitHub 為主要發佈平台:「Releases Distribution Changes」。

舊的 ftp & rsync 以及 git protocol (9418/tcp 的協定) 都打算淘汰掉:

We’re no longer using our old ftp, rsync, and git links for distributing OpenSSL. These were great in their day, but it’s time to move on to something better and safer.

其中 FTP 與 rsync 都已經停掉了,接下來是今年六月要停掉 ftp.openssl.org 的 HTTPS 介面以及 git.openssl.org 的 git protocol:

ftp://ftp.openssl.org and rsync://rsync.openssl.org are not available anymore. As of June 1, 2024, we’re also going to shut down https://ftp.openssl.org and git://git.openssl.org/openssl.git mirrors.

然後主力轉戰到 GitHub 上面:

GitHub is becoming the main distributor of the OpenSSL releases.

算是省事的作法,畢竟自己弄 infrastructure 不算太輕鬆

另外 OpenSSL 畢竟是個歷史頗久的軟體了,有「遵循古法」所以 release 都會有 PGP/GPG sign,這部分如果還是獨立於 GitHub 平台的話就沒什麼問題,代表還是有非 HTTPS 的 integrity 方法可以確認檔案沒被抽換過。

(但如果綁進 CI/CD 流程的話就廢了?)

Scaleway 的 RISC-V 伺服器

看到「Scaleway launches RISC-V servers (scaleway.com)」這篇,Scaleway 推出了 RISC-V 的伺服器:「Elastic Metal RV1」。

先看對消費者比較有感覺的部分,未稅 €15.99/mo 大約是 US$17.34/mo,有 16GB RAM 這點算是蠻有競爭力的,目前常見的 VPS 大約是 1:5 左右 (1GB RAM 大約要 $4/mo),這邊直接接近到 1:1,光是這點在吃 memory 比較重的環境下就蠻吃香的。

另外從 Scaleway 的角度來看,有蠻多特別的特性,像是超省電與超高密度:

EM-RV1 servers are extremely energy-efficient, consuming between 0.96W and 1.9W per 1.8GHz core.

Incredibly dense, a 52U rack holds up to 672 EM-RV1s!

所以一台機器的 4 core 跑滿大約是 7.6W,看功耗與手機用的 ARM CPU 有點像,只是不知道 CPU 效能到底在哪個區間,等後續看看好了?

測 IPv4 NAT VPS,以及架設 HTTPS Proxy

因為 AWS 開始收 Public IPv4 address 費用的關係 (而且頗貴,參考「AWS 將開始收取 IPv4 的 Public IP 費用」),我把其中一台主機改成只有 IPv6 address 後遇到不少問題 (在「把 AWS 上的 EC2 instance 改成 IPv6-only」這邊)。

由於有 proxy 的需求,剛好找機會玩一下 IPv4 NAT VPS... 這種 VPS 最基本的大概就是會給一個 IPv4 address 上 non-standard port 當作 SSH port,讓你可以連進去管理;另外通常會給 port forwarding 的功能,而且是固定不能換的,讓你可以開一些 port 出來用。

我的用途是 IPv6 address 的 proxy,所以要找有給固定的 IPv6 address 的,另外希望跑在日本,這樣其他用途也比較方便。

過年期間翻了一下找到 NAT VPS,有 256MB 跑個 proxy 類的應用應該還 OK,實際上是 256MB RAM + 64MB swap 的 OpenVZ 類環境,kernel 有到 5.2.0 還算堪用,上面可以選 Ubuntu 22.04 安裝。

費用的部分 US$7/year 還行,網路上是有看到 128MB RAM 的 機器,但這樣連裝東西都綁手綁腳的,太容易 OOM。

(剛拿到機器的時候還試著裝 Percona Server for MySQL,結果就 OOM 跑不完 setup 的流程,看起來得自己改設定混過去,但只是想確認 256MB RAM + 64MB swap 可以弄到什麼程度,就反安裝了...)

在上面把想測的東西測試完後,實際的 proxy 設定比較簡單... 先設定一個只有 IPv6 address 的 domain 申請 Let's Encrypt 的 SSL certificate,然後掛給 Squid 用。

然後在 IPv6-only 的機器上用 curl -v --proxy https://username:password@proxy-jp.example.com:12345/ https://home.gslin.org/robots.txt 確認沒問題後就可以把服務都掛過去。

有些服務會吃環境變數 HTTP_PROXYHTTPS_PROXY,有些是在設定檔內設定,基本上都是照著文件設就可以了。

我遇到的 application & library 都可以吃 HTTPS Proxy 協定,就沒什麼大問題... 如果有遇到不行的,也可以考慮在 Squid 裡面直接放行特定的 IPv6 address。

雲端的流量費用

在「Cloud Egress Costs (getdeploying.com)」這邊看到的文章,原文在「Cloud Egress Costs」這邊,主要是整理了表格出來可以快速了解不同雲端的流量費用差異,裡面不是單純 VPS 比較,而是各類的服務都拿出來比,像是 storage 類的以及 CDN 類的都有放進來...

Backblaze 的頻寬費用算法頗有趣,每個月給資料量的三倍大小當作免費頻寬,沒記錯的話因為 Cloudflare 是 Backblaze 的 partner,兩邊的傳輸費用不計費,如果資料是可以公開的,可以透過這個方式接出來;如果真的得走一般的流量輸出,收費是 US$0.01/GB (所以換算後是 US$10/TB)。

三家常被擺在一起的 VPS (LinodeDigitalOceanVultr) 的頻寬也都是 US$10/TB。

以前沒注意到的是 OVH CloudScaleway 的頻寬費用居然是免費的?另外 Hetzner 雖然要收費但也很低?有機會好像該玩看看,看一下品質如何?

npm 被拿來放影片...

這邊講的 npm 是指 official repository... 在 Lobsters 上看到在 npm 上放 ts 檔的文章:「npm flooded with 748 packages that store movies」,原文在這:「npm flooded with 748 packages that store movies」。

發現問題的是 wlwz 這個 user (不確定什麼時候會不見,不過備份在 Internet ArchiveArchive Today 上都有)。

以列出來的第一個 wlwz-2312-1405 來看,可以從裡面看到十個 ts 檔:

找了一下字串,看起來中國那邊有人認出來是「武林外傳」了 (縮寫剛好就是 wlwz):「npm 被用来保存盗版视频」。

這算是是各種 hosting 需要面對的問題...

捷克政府宣布 2032/06/06 政府網站將停用 IPv4 服務

看到「Czech republic sets IPv4 end date (konecipv4.cz)」這篇,捷克政府公告了政府網站將在 2032/06/06 停用 IPv4 服務:「Czech republic sets IPv4 end date」。

On 17 January 2024, the Government of the Czech Republic approved the material "Restarting the implementation of DNSSEC and IPv6 technologies in the state administration". On the basis of this decision, the Czech state administration will stop providing its services over IPv4 on 6 June 2032. Thus, the Czech Republic knows its IPv4 shutdown date.

剛好昨天在試著將手上 AWSEC2 instance 拔掉 IPv4 address (因為 2024/02/01 開始收費,參考先前寫的「AWS 將開始收取 IPv4 的 Public IP 費用」),結果還是遇到相依服務還沒有上 IPv6 endpoint 的問題,如果要轉移的話得開 DNS64NAT64,但因為目前就只有兩台小機器在 AWS 上,在上面租 NAT64 或是自己架 NAT64 的費用反而比付 IPv4 address 的費用還貴,就先暫時丟著了。

我這邊遇到的問題是 api.slack.com 目前只有 IPv4 address,這邊因為是走 HTTPS,也許可以靠其他在有 IPv6 address 的 VPS 上的 proxy server 解決 (我剛好有租一些 VPS instance),這幾天再來看看怎麼弄...

SourceHut 被 DDoS 後的報告

SourceHut 在 DDoS 後發表了報告:「SourceHut network outage post-mortem」。

這次的攻擊在 L3 層,直接塞爆 upstream bandwidth:

At around 06:00 UTC on January 10th, a layer 3 distributed denial-of-service (DDoS) attack began to target SourceHut’s PHL infrastructure.

上游 Cogent 選擇 null route 掉:

In response to the attack, Cogent announced null routes for our downstream AS, causing our PHL network to become unreachable both for SourceHut staff and the general public.

中間有試著問 Cloudflare 以及其他的方案,但依照他們的說法,費用上無法承受:

We initially researched a number of solutions, and spoke to Cloudflare in particular due to their ability to provide a rapid response to ongoing incidents. However, given our complex requirements, Cloudflare quoted us a figure which was not attainable within our financial means as a small company. Other options we researched (though we did not seek additional quotes) had similar economical constraints.

後來的解法是在 OVH 放 proxy server (搭配 OVH 的 DDoS 保護服務),然後導到沒有公開的 subnet:

However, we found that OVH’s anti-DDoS protections were likely suitable: they are effective, and their cost is amortized across all OVH users, and therefore of marginal cost to us. To this end the network solution we deployed involved setting up an OVH box to NAT traffic through OVH’s DDoS-resistant network and direct it to our (secret) production subnet in AMS; this met our needs for end-to-end encryption as well as service over arbitrary TCP protocols.

GitHub 在還沒被 Microsoft 併購前 (2018 年) 也有被打的記錄,2015 年的時候 Google 有放一些資料,當年有寫一篇記錄下來:「Google 對 GitHub 先前遭受 GFW 的 DDoS 攻擊的分析」,不過當年這波是 L7 的。

另外 2016 年的時候 GitHub 也有整理一篇關於 TCP SYN flood 的阻擋方式,這個看起來比較接近這次的攻擊:「GitHub 對抗 TCP SYN Flood 的方式:synsanity」。

Gitea 推出了自己的 Cloud 版本:Gitea Cloud

Gitea 推出了 Gitea Cloud:「Gitea Cloud: A brand new platform for managed Gitea Instances」。

費用是 $19/user/mo 或是 $190/user/y,這個價位會對應到 GitHub 裡 Enterprise 等級的費用 ($21/user/mo 或是 $231/user/y)。GitLab 的話 Premium 的費用是 $348/user/y,高出不少...

依照官方的說明,看起來是 instance 直接拆開,所以也可以選擇 region:

Dedicated instances, full control in your hand:

Chose your cloud provider and region

這應該算是架構面上與其他兩家最大的差異了,走的應該是 multi-tenancy 的模式。但市場接受度不曉得如何...

在實體機上跑 K8s 的記錄

Hacker News 上翻到「Bare-Metal Kubernetes, Part I: Talos on Hetzner (datavirke.dk)」,看起來作者試著記錄下實體機器上跑 K8s 的各種事情,系列文章的第一篇在「Bare-metal Kubernetes, Part I: Talos on Hetzner」這邊。

跟朋友聊天的時候會聊到 K8s 就是個 mini AWS,裡面包括了雲端基本該有的 building blocks,對於有自己地端機房的人可以用純軟體的方式把這些東西組出來,不用去買特殊的硬體設備來架設 (像是 F5 的 load balancer)。

另外一種用 K8s 的情境是需要真正的跨環境 (像是 container 可以自由的切來切去),像是地端與雲端的整合,或是雙雲端系統的整合。

但畢竟是自己架設一套 mini AWS,複雜度當然就不是一般架設服務可以比擬的。作者用了八篇把各個角落都帶過一次,還寫了一篇炸掉的處理:「Bare-metal Kubernetes: First Incident」。

一般的情況下應該是不需要用到這個東西,但記錄一下。

在 Fly.io 上面跑 PHP

Heroku 把 free tier 拔的差不多後 (「Heroku 公佈了廢止免費方案的時間表」、「Heroku 的替代方案」),大家手上的小專案都往其他的服務跑,目前看起來做的比較有規模的就是 Fly.io 了,一個人可以建很多個 organization,而每個 organization 都有 free quota 可以用...

Fly.io 官方的文件 FLy.io Docs 裡面可以看到說明,介紹怎麼把 Laravel 站台跑起來,不過沒介紹怎麼跑純 PHP 站台,所以就看了文件研究看看,發現可以用 Docker container 跑,那就簡單了。

專案放在 GitHubgslin/fly-vanilla-php 上面。

一開始我的 Fly App 用的是 V1 的版本,是跑起來了,但後來還是換到 V2 跑,雖然兩者用起來沒有太大區別 (參考「Fly Apps」這邊的說明),但畢竟官方打算都把 V1 掛上 legacy 了,新的專案就儘量別用了...

另外一開始用 buildpacks 編 Docker image,但發現太慢了,就還是去 Docker Hub 上找個大戶人家包好的 image 來用。

首先是 fly.toml 這個檔案,這邊就直接指定用 Dockerfile 來編。

然後是 Dockerfile 這個檔案,這邊用的 image 是 richarvey/nginx-php-fpm 這包,預設會開在 port 80,所以 fly.toml 裡面就把 internal_port 指定在 80

另外就是指定了 WEBROOT,我把 root 放在 public/ 下面。

跑起來以後就可以用他提供的網址測試了,我這個專案在 https://hidden-river-325.fly.dev/ 這邊可以看到,另外我有設定自己的 domain,在 https://test-fly.gslin.com/ 也可以看到一樣的 phpinfo(); 資訊。

這邊有個小插曲,我想要掛自己的 domain 上去跑 HTTPS,但如果機器沒有掛 IPv6 address 的話,Fly.io 的系統不會認定設定已經完成,也就不會往下去申請 Let's Encrypt 的憑證,我放了一天覺得奇怪,摸了辦天才發現這個 "feature"。