lighttpd 居然出新版支援 HTTP/2 與 Brotli 了...

從 mailing list 收到 lighttpd 出新版的通知信,本來以為是 security fix,結果看了一下發現雖然版號是從 1.4.55 變到 1.4.56,但這個版本支援了 HTTP/2,以及 Brotli 壓縮:「Release-1 4 56 - Lighttpd - lighty labs」。

lighttpd 應該是我還在學校的時候幫 PIXNET 用的東西?他跑 FastCGI 模式接 PHP 當時效能還不錯... 現在自己架站的習慣是用 nginx 了。

反倒是他當年因為要更方便的支援 FastCGI 而生的 spawn-fcgi 讓 nginx 與其他專案沿用,後來是各家專案自己都原生支援 FastCGI 或是其他協定,所以重要性就淡了一些...

這次的更新推出的 HTTP/2 算是補上蠻重要的功能,不知道會對 lighttpd 社群帶來什麼能量...

Apple M1 的效能與省電原因

Hacker News Daily 上看到 Apple M1 為什麼這麼快又省電的解釋,可以當作一種看法:

可以在 Thread reader 上面讀:「Thread by @ErrataRob on Thread Reader App – Thread Reader App」。

看起來 Apple 在規劃的時候就有考慮 x86 模擬問題,所以在記憶體架構上直接實做了對應的模式,大幅降低了當年 MicrosoftSurface 上遇到的問題:

3/ The biggest hurdle was "memory-ordering", the order in which two CPUs see modifications in memory by each other. It's the biggest problem affecting Microsoft's emulation of x86 on their Arm-based "Surface" laptops.

4/ So Apple simply cheated. They added Intel's memory-ordering to their CPU. When running translated x86 code, they switch the mode of the CPU to conform to Intel's memory ordering.

另外一個比較有趣的架構是,Apple M1 上面的兩個 core 有不同的架構,一顆對效能最佳化,另外一顆對效率最佳化:

13/ Apple's strategy is to use two processors: one designed to run fast above 3 GHz, and the other to run slow below 2 GHz. Apple calls this their "performance" and "efficiency" processors. Each optimized to be their best at their goal.

在 wikipedia 上的介紹也有提到這兩個 core 的不同,像是 L1 cache 的差異 (128KB 與 192KB),以及功耗的差異:

The M1 has four high-performance "Firestorm" and four energy-efficient "Icestorm" cores, providing a configuration similar to ARM big.LITTLE and Intel's Lakefield processors. This combination allows power-use optimizations not possible with Apple–Intel architecture devices. Apple claims the energy-efficient cores use one tenth the power of the high-performance ones. The high-performance cores have 192 KB of instruction cache and 128 KB of data cache and share a 12 MB L2 cache; the energy-efficient cores have a 128 KB instruction cache, 64 KB data cache, and a shared 4 MB L2 cache. The Icestorm "E cluster" has a frequency of 0.6–2.064 GHz and a maximum power consumption of 1.3 W. The Firestorm "P cluster" has a frequency of 0.6–3.204 GHz and a maximum power consumption of 13.8 W.

再加上其他架構上的改善 (像是針對 JavaScript 的指令集、L1 的提昇,以及用 TSMC 最新製程),累積起來就變成把 Intel 版本壓在地上磨蹭的結果了...

關閉 GitLab 的 nginx,使用自己裝的 nginx

我自己架設的 GitLab 是透過「Install self-managed GitLab」這邊的方法裝進 Ubuntu 系統內的 (我在自己的 wiki 上也有整理:「GitLab」),他會自己下載所有對應的套件,包括了 nginx

但這樣就直接把 TCP port 80/443 都吃掉了,同一台機器要放其他的 virtual host 就比較麻煩,所以找了些方法讓 GitLab 不要佔用 TCP port 80/443。

首先是找到這篇,資料有點舊,但裡面關掉 nginx 的方法還算是有用:「How to setup gitlab without embedded nginx」。

現在只要把 /etc/gitlab/gitlab.rb 裡面的:

  • nginx['enable'] 改成 false
  • web_server['external_users'] 改成 ['www-data']

然後跑 gitlab-ctl reconfigure 讓他更新設定檔,接下來停掉整個 GitLab 再打開 (或是重開機) 讓 nginx 完全失效就可以了。

接下來弄好自己的 nginx 以及 HTTPS 設定,這個部份我自己偏好用 dehydrated,其他人會有不同的偏好設法。

在弄完 nginx 後再來是 proxy_pass 類的資訊要帶進去,這個部份可以參考本來 GitLab 的 nginx 設定檔 (在 /var/opt/gitlab/nginx/conf/ 這下面),其中最重要的就是 GitLab 本身,我們會在 /etc/nginx/conf.d/upstream.conf 裡面寫入對應的 upstream 資訊 (沒這個檔案就自己生一個):

upstream gitlab-workhorse {
    server unix:/var/opt/gitlab/gitlab-workhorse/sockets/socket;
}

接下來是在對應的 virtual host 下設定 proxy_pass

    location / {
        proxy_pass http://gitlab-workhorse;
    }

另外我有啟用 GitLab 提供的 Mattermost,所以也要翻設定導進去:

#
upstream gitlab_mattermost {
    server 127.0.0.1:8065;
}

與:

    location / {
        proxy_pass http://gitlab_mattermost;
    }

都弄好後叫 nginx 重讀設定,接下來應該就會動了... 然後 TCP port 80/443 也算自由了,要掛其他的網域上去應該都 OK。

一人團隊的技術架構

Hacker News Daily 上看到的文章,在講一人團隊時所設計的技術架構:「The Tech Stack of a One-Man SaaS」。這種資訊通常帶有個人偏好,維護成本算是蠻重要的重點,在多人團隊就未必會這樣選,但就拿著爆米花看戲的心態來說應該還 OK。

像是作者很明顯熟悉 Python,就可以看到他裡面會列出許多 Python 相關的 toolchain 與維護工具。

裡面比較有趣的是他對 DigitalOcean 的 K8S 問題很多抱怨了一番,然後換去 Linode 後又因為不想要自己管 PostgreSQL 而決定搬到 AWS 上面,可以用 RDS 省事... 花錢解決 XD

算是當短文小說在看...

Canonical 與 Docker 合作,推出了一系列 LTS Docker Image

CanonicalDocker 合作,推出了一系列 LTS Docker Image:「Canonical publishes LTS Docker Image Portfolio on Docker Hub」。

這邊的 LTS 是十年:

Ten year maintenance commitment on app images provides secure cloud software supply chain

另外有提到這些 LTS Docker Image 將不受 per-user rate limit 限制:

Canonical and Docker will collaborate on Docker Official Images and LTS Docker Image Portfolio to bring the best of the two to the community and ecosystem. The entire LTS Docker Image Portfolio will be exempted from per-user rate limits.

發佈的 image 可以在 https://hub.docker.com/u/ubuntu 上面翻到,主要就是常見的 server 軟體,算是多一個選擇...

AWS 推出 Amazon Managed Workflow,把 Airflow 包成服務

AWS 推出了 Amazon Managed Workflow,把 Apache Airflow 包成服務:「Introducing Amazon Managed Workflows for Apache Airflow (MWAA)」。

看起來就是預設提供 HA 架構,然後把設定放到 web 上管理,以及整了 AWS 自家的服務。價錢上看起來不便宜,不過看起來定位主要還是方便用...

AWS 推出了 AWS Network Firewall

AWS 推出了 AWS Network Firewall,可以在 VPC 層做更多細緻的設定了:「AWS Network Firewall – New Managed Firewall Service in VPC」。

本來的 Network ACLs 的設計也是對 VPC 做過濾,但就是很標準的 stateless filtering:

Network ACLs are stateless, which means that responses to allowed inbound traffic are subject to the rules for outbound traffic (and vice versa).

而這次推出的 AWS Network Firewall 引入了 stateful filtering 的能力:

另外介紹裡面也提到支援 Suricata 的語法,不過太久沒碰 IDS 這塊了,我只知道 Snort

A stateful rule group with Suricata compatible IPS rules has all settings defined within the Suricata compatible specification. For example, as following is to detect SSH protocol anomalies. For information about Suricata, see the Suricata website.

目前支援的區域很少,只有 us-east-1us-west-2eu-west-1 可以用:

AWS Network Firewall is now available in US East (N. Virginia), US West (Oregon), and Europe (Ireland) Regions. Take a look at the product page, price, and the documentation to learn more.

另外價錢上不算便宜:「AWS Network Firewall Pricing」,比較特別的是用 AWS Network Firewall 的話,包含了免費的 NAT Gateway 額度可以用...

印象中 Network ACLs 不用另外付費 (找了一下沒找到收費的標準?),如果可以用 Network ACLs 解決就用 Network ACLs,不能的再考慮用 AWS Network Firewall 吧...

無風扇系統的 CPU 散熱片

最近剛好弄家裡跳板機的硬體,蝦皮上弄了一顆 Intel i3-8100T 回來用,這顆標 35W 的 CPU 基本上還是需要個風扇會比較保險,不像先前在弄 Intel J1900 只有 10W,原廠在上面就放一顆散熱片就搞定了。

剛好手上有一顆 LGA 115x 的風扇可以用,裝上去後平常就在 35 度,跑個程式讓系統滿載大約 55 度,而且這還是沒有系統風扇的情況下,看起來是夠用了。

不過因為好奇,還是找了一下無風扇的方案,結果就看到這顆:「ARCTIC Alpine 12 Passive - Silent Intel CPU Cooler for Intel Sockets 115x and 1200, up to 47 W, Pre-Applied MX-2 Thermal Paste, 95 x 96 mm - Black」。

這顆在 Ptt 上有被提過:「[情報] Arctic推出Alpine 12被動式CPU散熱器」,基本上就是個卡個超大顆的散熱片,看描述可以壓 47W 的發熱量,只要機殼內能通風,應該就有機會把溫度壓住?

之後找機會來玩看看好了...

Dehydrated 使用 ZeroSSL 的方式

上一篇「ZeroSSL 也提供免費的 SSL Certificate (DV) 了」提到 ZeroSSL 的服務,而各家 acme client 也都陸陸續續支援了。

Dehydrated 是在 2020/09/15 的時候實做:「EAB + ZeroSSL support」,我就抓了個新版,更新之前自己包的 PPA dehydrated-lite...

Dehydrated 的設定方式還蠻簡單的,在 /etc/dehydrated/config 裡面這樣寫:

CA=zerossl
EAB_HMAC_KEY=x
EAB_KID=y

其中兩個 EAB 的資訊可以在 ZeroSSL 網站上面取得,然後其他就照舊跑...

ZeroSSL 也提供免費的 SSL Certificate (DV) 了

Facebook 上被朋友敲可以測 ZeroSSL,另外一個透過 ACME 協定提供免費的 SSL Certificate,不過目前只有支援單一網域名稱 (DV):「Another free CA as an alternative to Let's Encrypt (scotthelme.co.uk)」。

我先前就有在測 ZeroSSL,不過驗證一直過不去,當時有在 Twitter 上找 ZeroSSL 帳號問,但 ZeroSSL 的人說 ACME 的部份不在客服範圍,就先丟著...

剛剛發現是自己耍笨了,原因是 nginx 沒設好造成驗證卡住,一改好後就正常了。

SSL LabsSSL Server Test 翻了一下,他的 Root CA 看起來歷史更久,應該是有機會解決 Let's Encrypt 明年會產生的 Root CA 憑證信任問題,也就是先前在「Let's Encrypt 在 Android 平台上遇到的問題」提到的問題,在 Hacker News 上的討論也可以看到有人提到這點:

Good to know, and I'm glad there's an alternative to Let's Encrypt, just in case. Is ZeroSSL trusted by old Android devices? If so, that might be a work-around for Let's Encrypt's cross-signing from IdenTrust expiring.

不過也有些人有疑慮,畢竟提供這個服務後面的公司幹過不少壞事:

If zerossl is reselling/a subsidiary of sectigo, that’s enough reason to never use this.
Sectigo is the new name for Comodo. The same bunch of pricks who tried to trademark “Let’s Encrypt”.

Other players in the acme cert “business” is great. Renaming a slime ball name and carrying on like nothing happened is not ok.

但看起來至少是多了一個選擇...