Tag: ubuntu

GitHub 支援 SSH 使用 Security Key 了

GitHub 宣佈支援使用 security key 的 SSH key 操作了：「Security keys are now supported for SSH Git operations」。

也就是需要 SSH key + security key 才有辦法認證，只有拿到 SSH key 或是 security key 都是沒有辦法認證過。

目前官方支援 ecdsa-sk 與 ed25519-sk：

Now you can use two additional key types: ecdsa-sk and ed25519-sk, where the “sk” suffix is short for “security key.”

不過在 Ubuntu 20.04 下用預設的系統只能支援 ecdsa-sk，因為 ed25519-sk 會遇到類似「ed25519 problem with libressl」這邊的問題，就算你用的是 OpenSSL。

然後生完 key 後在 ~/.ssh/config 裡面指定對 github.com 使用這把 key：

Host github.com
    IdentityFile ~/.ssh/id_ecdsa_sk

接下來操作的時候就會需要碰一下 security key 了。

Ubuntu 20.04 下用 resolvconf 取代 systemd-resolved (因為 PPPoE)

如同在「升級跳板機」這邊提到的，這台跳板機是跑 Ubuntu 20.04，加上需要跑 PPPoE，我就遇到透過 PPPoE 拿到的 DNS 無法套用的系統內。

這點在「add pppoe support to systemd-networkd」這邊有被提到，而且看起來 Debian 那邊已經套用 patch 上去了，但 Ubuntu 這邊似乎還沒...

我看了看還是決定先暫時先回頭用 resolvconf，可以只用指令解決：

sudo apt install -y resolvconf
sudo systemctl disable systemd-resolved

然後重開確認後就可以收工...

ZFS 租用服務

看到「zfs.rent」這個網站：

We have a couple of ZFS-based NAS systems. We wanted a simple cloud service so we could run:

$ zfs send -v -R -I pool/snapshot_034 pool/snapshot_042 |\
    ssh marvin@marvin.zfs.rent zfs recv -v -Fu pool/snapshots

看起來是用 Linux 上的 OpenZFS 架的，每個 instance 提供 4GB RAM，這個部份應該還好，但只提供 1TB 的流量 (上傳與下載都要算)，這部份看起來就有點不太夠用了，以這種服務來說蠻容易踩到 overcharge 的部份。

作業系統的部份可以選擇 Ubuntu 20.04 或是 CentOS 8.2。

以架構上來說可以當作是某種特化的 VPS (底層的 raw disk 直接掛上來)，以這個角度來看的話，機器部份的費用看起來還好，但頻寬部份會拉高整體成本。

這個服務看起來比較像是噱頭吧，看看就好...

Ubuntu 16.04 (xenial) 的 ESM 準備中...

Ubuntu 的 ESM (Extended Security Maintenance) 是指 LTS (Long Term Support) 版本在五年的維護期過了以後，可以付費取得安全性更新的方案。

剛剛看到 Ubuntu 官方的文章，說明 Ubuntu 16.04 的 ESM 差不多要開始了：「Less than 6 months to Ubuntu 16.04 ESM: 6 things to prepare」。

ESM 在早期是延長三年，但最近則是改成五年。第一次提供 ESM 的 12.04 到後續的 14.04 與 16.04 都是三年，而 18.04 與 20.04 則是五年。

剛剛翻資料的時候發現原來 ESM 有提供個人免費使用 (在 Ubuntu Advantage 的 Essential 方案內)，一般是三台，如果是社群成員的話有機會到五十台：

Free for personal use
Canonical provides Ubuntu Advantage Essential subscriptions, which include ESM, free of charge for individuals on up to 3 machines. For our community of Ubuntu members we will gladly increase that to 50 machines. Your personal subscription will also cover Livepatch, FIPS and CIS hardening tools.

不過手上 16.04 的機器也升的差不多了，好像用不太到...

Travis CI 支援 Arm64 平台的編譯與測試了

剛剛看到 Travis CI 宣佈支援 Arm64 的編譯與測試環境了：「Announcing General Availability of Graviton2 CPU Support!」。

架構上是利用 AWS 推出的機器來做，其中支援的 OS image 目前看起來是以 Ubuntu 為主，其中 16.04 (xenial) 與 18.04 (bionic) 只有 LXD container 的環境，而 20.04 (focal) 則除了 LXD container 環境外，也有完整的 VM 環境可以跑：

Following Arm64 distributions of Ubuntu are available for you as LXD containers:

Xenial (16.04)
Bionic (18.04)
Focal (20.04)

Following Arm64 distribution of Ubuntu is available for you as a full VM option:

Focal (20.04)

看起來底層是用 Ubuntu 20.04 為主力，然後提供 container 跑其他版本。

Ubuntu 16.04 出更新了...

看到 Ubuntu 16.04 (xenial) 在 support cycle 剩下不到一年的時候推出了 16.04.7：「Ubuntu 16.04.7 LTS released」。

看起來主要是修正 GRUB 的安全性問題：「USN-4432-1: GRUB 2 vulnerabilities」。

這次修正的 CVE 好像有點多，但全部都是與 GRUB 相關的... 另外可以看到包括 14.04 (trusty) 都有修正 (ESM，付費提供支援的版本)。

目前手上大多數機器都是 18.04 (bionic) 與 20.04 (focal) 了，會在 16.04 (xenial) 主要是 OpenVZ 的關係，雖然看起來還是有一台一直懶得動，該找機會弄一弄了...

Travis CI 推出 20.04 的環境了

看到 Travis CI 推出 Ubuntu 20.04 的測試環境公告，嚇了一跳：「Ubuntu 20.04 (Focal Fossa) build environment is available!」。

要知道當年是在 2017 年七月才支援 Ubuntu 14.04 (參考「Travis CI 總算要把 Trusty 當作預設環境了...」這篇)，在 2018 年十一月才支援 Ubuntu 16.04 (參考「Travis CI 居然記得要支援 16.04 了...」這篇)，然後 18.04 上線乾脆不公告了 (翻了一下社群的討論「Ubuntu 18.04.1 LTS (Bionic Beaver)」，是在 2019 年的七月左右支援的)...

這次 20.04 出來還不到半年居然支援了！

Ubuntu 20.04 推出

代號 Focal Fossa (focal) 的 Ubuntu 20.04 推出了，在官網上可以下載，另外也可以翻「FocalFossa/ReleaseNotes」這邊看看有什麼新功能。

ReleaseNotes 翻了一輪後看起來還好，主要是看到新版的 OpenSSH 支援了 U2F，可以找機會玩玩看，然後 ZFS 那邊有一些新玩具可以玩，其他的倒是還好...

另外裡面也有提到各家雲端平台都上架了，找一下對應的 image 應該是可以測試看看...

WireGuard 1.0.0 的釋出

在「[ANNOUNCE] WireGuard 1.0.0 for Linux 5.6 Released」這邊看到的消息，看起來 WireGuard 1.0.0 會回過頭來 backport 到幾個重要的版本：

We'll also continue to maintain our wireguard-linux-compat [2] backports repo for older kernels. On the backports front, WireGuard was backported to Ubuntu 20.04 (via wireguard-linux-compat) [4] and Debian Buster (via a real backport to 5.5.y) [5]. I'm also maintaining real backports, not via the compat layer, to 5.4.y [6] and 5.5.y [7], and we'll see where those wind up; 5.4.y is an LTS release.

包括 Debian 與 Ubuntu 的新版，以及 5.4.x 的 LTS 版本，讓使用起來更方便一些...

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.

來跑跑看好了...