本篇 TL;DR 因包含腳本及 K8s yaml 內容較長，有興趣直接閱讀全文的讀者可以按此跳到正文。

TL;DR

分成 FreeIPA 與 cert-manager 兩個部分設定：

FreeIPA

# ipa-acme-manage enable
# tsig-keygen -a hmac-sha512 cert-manager-acme | tee -a /etc/named/ipa-ext.conf
# systemctl restart named-pkcs11.service || systemctl restart named.service
# ipa dnszone-mod ${IPA_DNS_ZONE} --dynamic-update=True \
    --update-policy='grant cert-manager-acme wildcard * TXT;'

順便記下印出來的 TSIG Key Secret。

cert-manager

---
apiVersion: v1
kind: Secret
type: Opaque
metadata:
  namespace: cert-manager
  name: ipa-tsig
data:
  cert-manager-acme: ${TSIG_SECRET_IN_BASE64}
---
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: ipa
spec:
  acme:
    caBundle: ${IPA_CA_CERT_IN_BASE64}
    privateKeySecretRef:
      name: ipa-acme-account-key
    server: https://${IPA_CA_SERVER}/acme/directory
    solvers:
    - dns01:
        rfc2136:
          nameserver: ${IPA_NS_IP}
          tsigAlgorithm: HMACSHA512
          tsigKeyName: cert-manager-acme
          tsigSecretSecretRef:
            key: cert-manager-acme
            name: ipa-tsig
      selector:
        dnsZones:
        - ${IPA_DNS_ZONE}

完成。如果要從 Ingress 自動發憑證的話要記得加上 cert-manager.io/cluster-issuer: ipa 的 annotation。

前言

我們在管理 Kubernetes^[1] 的時候常常會需要提供一個 TLS Ingress^[2]，在沒有自動化工具的協助下，我們會需要手動將憑證及金鑰塞進 Cluster 裡。

此時 cert-manager^[3] 就能幫我們處理自動簽發憑證的問題，cert-manager 支援透過 ACME^[4] 來完成自動化簽發憑證。通常，我們可能會拿來簽發 Let's Encrypt^[5] 的憑證，但如何讓 Let's Encrypt 通過驗證就會是個問題，cert-manager 同時支援了 HTTP-01^[6] 及 DNS-01^[7] 兩種方式。

今天想要來跟大家聊聊，如果想透過 cert-manager 自動簽發憑證的話，我們可以怎麼設定。本篇以想要讓 FreeIPA^[8] 作為憑證簽發者，而且透過 DNS-01 通過驗證當作目標來進行（適用於用 FreeIPA 管理 DNS zone 的場景，所以你想用 Let's Encrypt 簽發憑證也可以）：

FreeIPA DNS

由於我們打算採用 DNS-01 作為 ACME 的認證手段，我們得先來搞定如何讓 cert-manager 自動來修改 FreeIPA 的 DNS 記錄。

FreeIPA 使用 BIND9^[9] 作為其 DNS 的解決方案，由於 BIND 與 cert-manager 都支援^[10] RFC-2136^[11]，因此我們可以透過 UPDATE 指令來更新 RR^[12]。而為了讓 FreeIPA 的 BIND 確認這個更新的指令是從被授權的 cert-manager 來的，我們還必須透過 TSIG^[13] RR 來進行簽名認證。

TSIG Secret Key

說到簽名，就必須要有一個可以拿來簽名^[14]的 Secret Key，於是讓我們從建立這把金鑰開始：

# export TSIG_KEY_NAME=cert-manager-acme
# tsig-keygen -a hmac-sha512 ${TSIG_KEY_NAME} | tee -a /etc/named/ipa-ext.conf
key "cert-manager-acme" {
        algorithm hmac-sha512;
        secret "<...base64 encoded secret here...>";
};
# systemctl restart named.service || systemctl restart named-pkcs11.service
#

請自行將 ${TSIG_KEY_NAME} 替換成想要的金鑰名稱，像筆者是使用容易識別的 cert-manager-acme，表示這把金鑰是給 cert-manager 作為 ACME 用的金鑰。

另外，輸出的 secret 內容請記下來，此為 TSIG Secret Key，後面會用 ${TSIG_SECRET} 表示，在設定 cert-manager 時還會用到。我們在這裡建立了一把使用 HMAC-SHA512^[15] 作為簽名演算法的金鑰。

上面的指令除了建立 TSIG Secret Key 以外，還會將這個設定寫入 BIND9 的設定檔中，並重新啓動 BIND9^[16]，讓 BIND9 認識這把金鑰的存在。

設定更新策略

光是讓 BIND9 認得 TSIG 金鑰是不夠的，我們還必須設定更新策略以讓 BIND9 可以按照允許規則來放行該金鑰的更新指令：

透過 FreeIPA WebUI

我們可以透過 WebUI 來進行更新策略的設定，在登入 WebUI 後點選 "Network Service" 選擇要用來簽發憑證的 DNS Zone 後，來到 Settings 並按照下方截圖說明設定：（如果你的 WebUI 不是英文版本，可參考截圖內的相對位置進行設定）

• 啓用 "Dynamic update"
• 在 "BIND update policy"^[17] 中加入規則：（截圖中反白內容）
  • grant cert-manager-acme wildcard *.k8s.davy.home TXT;
  • 請將 cert-manager-acme 替換成剛剛設定的 ${TSIG_KEY_NAME} 值
  • 請將 *.k8s.davy.home 替換成讀者想要簽發憑證的 Domain name，筆者在此想讓 cert-manager 可以簽發 k8s.davy.home. 下的所有 Subdomain^[18]，因而如此設定

儲存後即可完成更新策略的設定。

透過 ipa CLI

如果不想要再花時間登入 WebUI 的話，也有透過 ipa 指令設定的方式：

# export IPA_DNS_ZONE=davy.home
# ipa dnszone-mod ${IPA_DNS_ZONE} --dynamic-update=True \
    --update-policy='grant cert-manager-acme wildcard *.k8s.davy.home TXT;'
#

請讀者自行依照實際情形替換 ${IPA_DNS_ZONE} 為對應的 DNS Zone，以及將 cert-manager-acme 與 *.k8s.davy.home 替換成對應的內容。

cert-manager ClusterIssuer/Issuer

在 cert-manager 這側，我們需要做的事情就相對簡單了，只需要建立兩個資源 —— Secret 及 ClusterIssuer/Issuer。

首先我們必須先決定這個 Issuer 是 Cluster-wide 的還是 Namespace-wide[^namespace] 的，如果你打算讓整個 Cluster 內的資源都能使用這個 Issuer 的話就選擇建立 ClusterIssuer，反之，就選擇建立 Issuer。

本文將以 ClusterIssuer 作為範例，最大差別在於同一個 Issuer 的相關資源（例如 Secret 等）必須放在同一個 namespace 下；而 ClusterIssuer 則是將相關資源放在 cert-manager 指定的 namespace（預設與 cert-manager 同一個 namespace^[19]），自己本身並沒有 namespace 的屬性。

TSIG Secret Key

首先，我們將建立一個存放 TSIG Secret Key 的 Secret 資源：

$ kubectl -n cert-manager create secret generic ipa-tsig \
    --from-literal=secret="${TSIG_SECRET}"
secret/ipa-tsig created
$

此處的 ${TSIG_SECRET} 在前面〈FreeIPA DNS → TSIG Secret Key〉一節中有提到過，如果還沒有取得的讀者請先往前翻閱。

如果讀者想建立的是 Issuer 資源，請在這一步驟中將 Secret 資源建立在對應的 Namespace 中。

建立 ClusterIssuer

有了存放 TSIG Secret Key 的資源後，我們就可以來建立 ClusterIssuer 資源了：

---
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: ipa
spec:
  acme:
    caBundle: ${IPA_CA_CERT_IN_BASE64}
    privateKeySecretRef:
      name: ipa-acme-account-key
    server: https://${IPA_CA_SERVER}/acme/directory
    solvers:
    - dns01:
        rfc2136:
          nameserver: ${IPA_NS_IP}
          tsigAlgorithm: HMACSHA512
          tsigKeyName: ${TSIG_KEY_NAME}
          tsigSecretSecretRef:
            name: ipa-tsig
            key: secret
      selector:
        dnsZones:
        - ${IPA_DNS_ZONE}

其中有幾個值需要讀者根據實際情況替換：

• ${IPA_CA_CERT_IN_BASE64}
  • FreeIPA 的 CA 憑證（以 base64 編碼的 PEM 格式表示）
  • 可以從 FreeIPA 主機的 /etc/ipa/ca.crt 取得
• ${IPA_CA_SERVER}
  • 通常會是 ipa-ca.<IPA REALM DOMAIN>，以筆者的環境來說就是 ipa-ca.davy.home
• ${IPA_NS_IP}
  • FreeIPA 的 DNS Primary IP，通常就是 FreeIPA 的 Primary Server IP
• ${TSIG_KEY_NAME}
  • TSIG Secret Key 的名稱，在〈FreeIPA DNS → TSIG Secret Key〉一節有提到，以筆者的案例來說就是 cert-manager-acme
• ${IPA_DNS_ZONE}
  • 你想要簽發的 DNS Zone 或 Subdomain，以筆者的案例來說就是 k8s.davy.home
• ipa-acme-account-key
  • 這裡會自動建立用於存放 ACME 註冊資訊的 Secret，讀者可自由更換其名稱
• server: https://${IPA_CA_SERVER}/acme/directory
  • 如果讀者想要透過 Let's Encrypt 或其他來源簽發憑證，而非從 FreeIPA 的話，請自行設定成對應適合的 server，並提供該簽發服務足夠的資料，詳細請參見 cert-manager 說明文件〈ACME → Introduction → Creating a Basic ACME Issuer〉一節

如果讀者想建立的是 Issuer 資源，請在這一步驟中改建立 Issuer 資源，並將此建立在對應的 Namespace 中。

接下來我們可以透過 kubectl describe 來觀察 ClusterIssuer 與我們 FreeIPA ACME 服務的註冊情形：

$ kubectl describe clusterissuer ipa
...
Status:
  Acme:
    Last Private Key Hash:  BbkPF6ZPgulgisJ80ISEIq10JXHIB19M9I2eYOHIFAQ=
    Uri:                    https://ipa.davy.home/acme/rest/acct/Mt72_fSdmemIOK8cj89x6AZhwujqenQ5MyIxqCAnC1Y
  Conditions:
    Last Transition Time:  2024-07-18T15:18:40Z
    Message:               The ACME account was registered with the ACME server
    Observed Generation:   2
    Reason:                ACMEAccountRegistered
    Status:                True
    Type:                  Ready
$

如果可以看到 Reason: ACMEAccountRegistered，表示我們的 FreeIPA 已經受理我們的 ACME 註冊手續了。但這還並不表示我們設定的 TSIG Secret Key 已經正確被驗證了，這會等到我們真的進行 DNS-01 驗證時，要修改 TXT RR 的時候才會去驗證。

TLS Ingress

到目前為止，我們已經大致上完成了 FreeIPA 及 cert-manager 兩側的串接了，我們可以透過新增一個測試用的 TLS Ingress 來測試是否真的成功了：

---
kind: Namespace
metadata:
  name: cert-manager-acme-test
---
apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: cert-manager-acme-test
  name: hello-deployment
spec:
  selector:
    matchLabels:
      app: hello
  template:
    metadata:
      labels:
        app: hello
    spec:
      containers:
      - image: nginx:1.14.2
        imagePullPolicy: IfNotPresent
        name: nginx
        ports:
        - containerPort: 80
          protocol: TCP
---
apiVersion: v1
kind: Service
metadata:
  namespace: cert-manager-acme-test
  name: hello-service
spec:
  type: ClusterIP
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: hello
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    cert-manager.io/cluster-issuer: ipa
  namespace: cert-manager-acme-test
  name: hello-ingress
spec:
  rules:
  - host: hello.k8s.davy.home
    http:
      paths:
      - backend:
          service:
            name: hello-service
            port:
              name: http
        path: /
        pathType: Prefix
  tls:
  - hosts:
    - hello.k8s.davy.home
    secretName: hello-tls

上面的 yaml 會部署一組 Deployment、Service 及 Ingress 到一個新的 Namespace cert-manager-acme-test 中。

注意我們在 Ingress 的地方除了設定 TLS 相關的內容以外，還多了一個 Annotation cert-manager.io/cluster-issuer，cert-manager 會自行過濾帶有此 Annotation 的 Ingress 並以其值對應的 ClusterIssuer 來簽發憑證^[20]。

如果想使用 Issuer 的話，此處換成 cert-manager.io/issuer 即可。

上方的 Ingress 在設定 TLS 時一併設定了一個 secretName，此為存放 TLS 憑證及金鑰用的 Secret 資源的名稱，如果不存在的話會自動建立。而我們亦可以透過觀察這個 Secret 及其對應的 cert-manager.io/v1/CertificateRequest 資源來看到憑證簽發的狀態如何：

$ kubectl -n cert-manager-acme-test get secret hello-tls -o yaml
apiVersion: v1
data:
  tls.crt: ...
  tls.key: ...
kind: Secret
metadata:
  annotations:
    cert-manager.io/alt-names: hello.k8s.davy.home
    cert-manager.io/certificate-name: hello-tls
    cert-manager.io/common-name: hello.k8s.davy.home
    cert-manager.io/ip-sans: ""
    cert-manager.io/issuer-group: cert-manager.io
    cert-manager.io/issuer-kind: ClusterIssuer
    cert-manager.io/issuer-name: ipa
    cert-manager.io/uri-sans: ""
  labels:
    controller.cert-manager.io/fao: "true"
  name: hello-tls
  namespace: cert-manager-acme-test
type: kubernetes.io/tls
$ kubectl -n cert-manager-acme-test get CertificateRequest \
  -o custom-columns="NAME:.metadata.name,Secret:.metadata.annotations.cert-manager\.io/certificate-name,Issuer:.spec.issuerRef.name,Issued:.status.conditions[?(@.type=='Ready')].status"
NAME          Secret      Issuer   Issued
hello-tls-1   hello-tls   ipa      True
$ kubectl -n cert-manager-acme-test get CertificateRequest hello-tls-1 -o yaml
apiVersion: cert-manager.io/v1
kind: CertificateRequest
metadata:
  annotations:
    cert-manager.io/certificate-name: hello-tls
    cert-manager.io/certificate-revision: "1"
    cert-manager.io/private-key-secret-name: hello-tls-7nrlt
  name: hello-tls-1
  namespace: cert-manager-acme-test
  ownerReferences:
  - apiVersion: cert-manager.io/v1
    blockOwnerDeletion: true
    controller: true
    kind: Certificate
    name: hello-tls
spec:
  issuerRef:
    group: cert-manager.io
    kind: ClusterIssuer
    name: ipa
  request: ...
status:
  certificate: ...
  conditions:
  - lastTransitionTime: "2024-07-18T14:58:21Z"
    message: Certificate request has been approved by cert-manager.io
    reason: cert-manager.io
    status: "True"
    type: Approved
  - lastTransitionTime: "2024-07-18T15:19:48Z"
    message: Certificate fetched from issuer successfully
    reason: Issued
    status: "True"
    type: Ready
$

從 Secret 及對應的 CertificateRequest 中可以看出來，cert-manager 已經幫我們完成了一條龍 —— 從設定 TLS Ingress 到設定 TXT RR 到通過 DNS-01 驗證再回到設定 Ingress 憑證。

我們也可以打開對應的 Ingress URL 來看到結果：

後記

原本以為可以在兩天內連續產出的這篇文章結果又拖了兩天才終於寫完，準備環境明明只花了一個晚上，結果大部分的時間都花在找對應的 Reference。 Orz

總之，這個技巧除了讓 FreeIPA 簽發憑證外，只要是透過 FreeIPA 或甚至純粹地用 BIND9 管理 DNS 的人都能使用這個方式自動化設定 TXT RR 來自動完成 DNS-01 驗證。

或是也可以延伸出其他的用法，其實並不限於 ACME 的場景而已，如果能夠理解背後的設定的意義的話就會有更多有趣的應用可以發掘。 ：）

cat <<-EOF | sudo tee /etc/systemd/system/mnt-wsl-instances-${WSL_DISTRO_NAME}.mount
[Unit]
Description=WSL Instances

[Mount]
What=/
Where=/mnt/wsl/instances/${WSL_DISTRO_NAME}
Type=none
Options=defaults,bind,X-mount.mkdir

[Install]
WantedBy=multi-user.target
EOF
sudo systemctl daemon-reload
sudo systemctl enable --now mnt-wsl-instances-${WSL_DISTRO_NAME}.mount

podman-remote run \
  -v /mnt/wsl/instances/${WSL_DISTRO_NAME}/`pwd`:/app \
  docker.io/library/busybox ls /app

前情提要

Podman^[1] 是一個由 Redhat^[2] 主推的 Container^[3] 工具，如果有用過容器的讀者們應該對於與其類似的 Docker^[4] 不陌生，Podman 就是一個這樣的容器管理工具。

與 Docker 不同的是，Podman 另外引入了 Pod^[5] 的概念，以及具有預設支援 rootless 及去 daemon 化等特色。

Podman Desktop

Podman 團隊在各平臺上推出了桌面管理工具 —— Podman Desktop^[6]，類似於 Docker Desktop 提供視覺化的管理功能外，也能協助使用者安裝 Podman 至系統中並提供各種設定及擴充功能。

有興趣從 Docker 跳船的讀者可以參考 Podman Desktop 提供的跳船指南： https://podman-desktop.io/docs/migrating-from-docker

Windows 下的 Podman

在 Windows 上，Podman 會在 Windows 中安裝 podman.exe，協助你在 Host 的 Command line 中輕鬆存取 Podman，例如我們可以打開一個 PowerShell（或 CMD），執行 podman version，即可看到類似下方截圖的結果：

大家可以注意到，雖然我們可以在 Windows 下面執行 Podman 指令，但實際上的 Podman Engine 卻是執行在 Linux 上的，這是因為 Podman 目前只能管理 Linux Container，因此 Podman 決定將 Podman Engine 跑在 WSL2 中，如果有安裝 Windows Terminal 的話，可以從自動產生的下拉選單中發現一個新的 WSL2 的 Distro。

並且 Podman 會幫你做好與 Windows Host 的整合，例如可以直接掛載 Windows 的目錄或檔案進容器中，例如：

PS C:\Users\Davy\podman-test> echo "Hi Podman from Windows" > hello.txt
PS C:\Users\Davy\podman-test> podman run --rm -v .\hello.txt:/hello.txt docker.io/library/busybox cat /hello.txt
Trying to pull docker.io/library/busybox:latest...
Getting image source signatures
Copying blob sha256:ec562eabd705d25bfea8c8d79e4610775e375524af00552fe871d3338261563c
Copying config sha256:65ad0d468eb1c558bf7f4e64e790f586e9eda649ee9f130cd0e835b292bbc5ac
Writing manifest to image destination
��Hi Podman from Windows
PS C:\Users\Davy\podman-test>

（請忽略那兩個看不見的 BOM 符號……）

也就是說，我們可以隨意地編寫 PowerShell 腳本（或 CMD 批次檔）來操作 Podman！😏

WSL2 下的 Podman

那麼，通常會使用 Podman 的話，應該會對 WSL2^[7] 也不陌生吧！

於是，我們可能會想，既然 Windows Host 都能如此順暢地與 WSL2 中的 Podman 整合了，那麼原本就在 WSL2 的其他 Distro 應該可以更好地整合吧……嗎？

很可惜，Podman Desktop 只丟了一個頁面^[8]告訴你，你要自己整合。

整合方式大致就是在 WSL2 中安裝一個 Podman，並將 podman-machine-default 提供的 Podman socket 接上這個 Podman，方法如下：

安裝 Podman / Podman Remote

Podman Desktop 推薦安裝 podman-remote^[9] 作為你在 WSL2 中使用的 Podman CLI，安裝方式也很簡單，到 containers/podman 的 Release 頁面中下載適合的 podman-remote 執行檔後放入 $PATH（例如 /usr/local/bin 或 /usr/bin） 中，並將 podman alias 成 podman-remote 或直接 ln -s podman-remote podman。

接下來就可以嘗試在 WSL2 中執行看看 podman（或 podman-remote）了！

$ podman-remote ps
Cannot connect to Podman. Please verify your connection to the Linux system using `podman system connection list`, or try `podman machine init` and `podman machine start` to manage a new Linux VM
Error: unable to connect to Podman socket: Get "http://d/v5.1.2/libpod/_ping": dial unix /mnt/wsl/podman/podman-machine-default.socket: connect: connection refused

咦？為什麼不會動呢？ 啊，原來是忘記將 podman-remote 與 podman-machine-default 中的 Podman 連結在一起了，還需要下面的設定才行：

$ podman-remote system connection add --default \
  podman-machine-default-root \
  unix:///mnt/wsl/podman-sockets/podman-machine-default/podman-root.sock
# usermod --append --groups 10 $(whoami)

設定完成之後重新登入 Shell（或重新打開一個新的 Terminal），再執行一次 podman-remote 看看：

$ podman-remote ps
CONTAINER ID  IMAGE       COMMAND     CREATED     STATUS      PORTS       NAMES
$ podman-remote run --rm quay.io/podman/hello
Trying to pull quay.io/podman/hello:latest...
Getting image source signatures
Copying blob sha256:81df7ff16254ed9756e27c8de9ceb02a9568228fccadbf080f41cc5eb5118a44
Copying config sha256:5dd467fce50b56951185da365b5feee75409968cbab5767b9b59e325fb2ecbc0
Writing manifest to image destination
!... Hello Podman World ...!

         .--"--.
       / -     - \
      / (O)   (O) \
   ~~~| -=(,Y,)=- |
    .---. /`  \   |~~
 ~/  o  o \~~~~.----. ~~
  | =(X)= |~  / (O (O) \
   ~~~~~~~  ~| =(Y_)=-  |
  ~~~~    ~~~|   U      |~~

Project:   https://github.com/containers/podman
Website:   https://podman.io
Desktop:   https://podman-desktop.io
Documents: https://docs.podman.io
YouTube:   https://youtube.com/@Podman
X/Twitter: @Podman_io
Mastodon:  @Podman_io@fosstodon.org
$

如此一來就可以在 WSL2 中操作與 Windows 摸到的同一個 Podman 了！

掛載 WSL2 中的路徑至 Podman

就算按照步驟將 WSL2 與 Podman 整合起來之後，你還會發現一些小小小問題 —— 例如掛載不到 WSL2 中的目錄……

~/podman-example$ echo "Hello from WSL2" > hello.txt
~/podman-example$ cat `pwd`/hello.txt
Hello from WSL2
~/podman-example$ podman-remote run --rm \
  -v `pwd`/hello.txt:/hello.txt \
  docker.io/library/busybox \
  cat /hello.txt
Error: statfs /home/davy/podman-example/hello.txt: no such file or directory
~/podman-example$

咦？ 奇怪？ 為什麼他會跟我說這個測試用的檔案不存在，明明直接 cat 會動的呀……

而且在 Docker 裡面如果這樣子做的話是會動的，為什麼在 Podman 中不行呢？

原來是在 Docker Desktop 中，對於掛載 WSL2 Distro 中的路徑時，Docker 會轉而向一個輔助工具求助，這個工具會協助 Docker 存取其他 WSL2 中的資料^[10]。因為 WSL2 中各個 Distro 的資料是各自獨立的，所以 Docker/Podman 的 WSL2 預設沒有辦法直接存取其他 Distro 的資料，此時會導致掛載路徑時會只能在自己的 WSL2 中搜尋，我們可以來做個實驗：

我們嘗試將 /home 掛載到 Podman container 中，在此之前我們先來確認在兩個 WSL2 中的檔案狀態：

user@podman-machine-default:~ $ ls /home/
user

davy@Ubuntu:~ $ ls /home/
davy

接下來我們開始嘗試掛載：

davy@Ubuntu:~ $ podman-remote run --rm -v /home/:/the-home docker.io/library/busybox ls /the-home
user
davy@Ubuntu:~ $

可以看到，podman-remote 將 podman-machine-default 中的 /home 掛載到了容器中，而非我們期望的 WSL2 Distro 中的 /home。

也就是說，--volume/-v 參數，不論在那個 WSL2 Distro，對應到的都是 podman-machine-default 中的路徑。

那麼，我們該如何掛載 WSL2 中其他 Distro 的路徑呢？

WSL2 的神奇共用目錄

在 WSL2 中，有一個神祕的路徑是全 WSL2 Distro 共享的，那就是 /mnt/wsl，Podman 也是藉由將 Podman Engine 的 socket 放在這個地方來讓其他 Distro 可以存取^[11]。WSL2 將這個神奇目錄用在存放與全 Distro 共享的設定等資料，大家可以嘗試下面的指令：

$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 20 Jul 17 22:11 /etc/resolv.conf -> /mnt/wsl/resolv.conf
$ ls -l /mnt/wsl/resolv.conf
-rw-r--r-- 1 root root 213 Jul 13 09:12 /mnt/wsl/resolv.conf
$ cat /mnt/wsl/resolv.conf
# This file was automatically generated by WSL. To stop automatic generation of this file, add the following entry to /etc/wsl.conf:
# [network]
# generateResolvConf = false
nameserver 10.255.255.254
search local
$

可以看到其實所有 Distro 的 /etc/resolv.conf^[12]，都是指向 /mnt/wsl/resolv.conf，而這個檔案會被 WSL2 自動地更新，WSL2 藉由這個方式來讓所有的 Distro 共用相同的設定。

於是，我們可以透過這個神奇的小地方來把我們要分享的東西放在這裡，再讓 podman-machine-default 來這裡存取即可！

解決方案

既然知道了方法，那麼我們就往下來執行，最簡單的方式就是利用 mount 指令將 WSL2 各個 Distro 的根目錄分享到 /mnt/wsl 下面，如此一來 podman-machine-default 就可以存取到裡面的內容了！^[13]

$ echo $WSL_DISTRO_NAME
Ubuntu
# mount -t bind -o defaults,bind,X-mount.mkdir / /mnt/wsl/instances/${WSL_DISTRO_NAME}
$ ls /mnt/wsl/instances/
Ubuntu
$ ls /mnt/wsl/instances/Ubuntu/home/
davy
$ podman-remote run --rm \
  -v /mnt/wsl/instances/${WSL_DISTRO_NAME}`pwd`/hello.txt:/hello.txt \
  docker.io/library/busybox \
  cat /hello.txt
Hello from WSL2
$

終於成功啦！🎉

systemd.mount

目前主流版本的 WSL2 引擎都已經支援 systemd^[14][15] 了，於是我們可以再多做一點事情 —— 自動掛載。

由於前面我們是手動使用 mount 指令來進行掛載，在每次 WSL2 重新啓動的時候都會復原，因此我們希望在 WSL2 啓動的時候就幫我們把這個 mountpoint 掛載上去，我們可以透過 systemd.mount 來幫我們完成這個任務。

在 /etc/systemd/system/ 下建立一個新的檔案 mnt-wsl-instances-${WSL_DISTRO_NAME}.mount，內容如下（此例中以 Ubuntu 取代 ${WSL_DISTRO_NAME}，請讀者自行依照自己的環境作更換）：

[Unit]
Description=WSL Instances

[Mount]
What=/
Where=/mnt/wsl/instances/${WSL_DISTRO_NAME}
Type=none
Options=defaults,bind,X-mount.mkdir

[Install]
WantedBy=multi-user.target

接下來執行下列指令來啓用這個 mount：

# umount /mnt/wsl/instances/${WSL_DISTRO_NAME}
$ ls /mnt/wsl/instances/${WSL_DISTRO_NAME}

# systemctl daemon-reload
# systemctl enable --now mnt-wsl-instances-${WSL_DISTRO_NAME}.mount
Created symlink /etc/systemd/system/multi-user.target.wants/mnt-wsl-instances-Ubuntu.mount → /etc/systemd/system/mnt-wsl-instances-Ubuntu.mount.
$ ls /mnt/wsl/instances/Ubuntu/home/
davy
$

這次終於是大功告成了！🎊

結語

其實原本不是要寫 Podman 相關的內容的…… 但剛好遇到要使用 Podman 的情景就想說順便把這件事情寫下來好了，原本是打算之後再跟大家分享的，現在提前先分享給大家 :)

Podman 在環境整合這方面真的還沒有做的 Docker 好，但還算在能搞懂原理的情況下自行 Hack，使用上或許沒有這麼方便，不過我個人還是覺得 Podman 還算是好用且方便的。

前幾天拿到了新的 M1 MacBook Air，想說來試試看一些平常使用的工具以及 iOS App，結果發現很多常用的 iOS App 都還沒有開放 macOS 下載使用…… 但很多常用的工具都已經有原生支援的版本了，在使用上也沒有什麼太多的問題，但有些小技巧想分享給大家，希望大家在這個轉換之路（？）上可以再更順暢一些~

• Rosetta 2 相關
• iOS App 相關
• CLI 相關
• 雜記

Rosetta 2 相關

這裡會列出一些與 Intel 相容模式（Rosetta 2）有關的一些小技巧：

原生支援？

在活動監視器（Activity Monitor）可以看到一個叫做「建築」^[1]的欄位，在這裡我們可以看到有分成 Apple 以及 Intel，分別對應到原生 Apple silicon 以及 Rosetta 2^[2] 相容的 Intel 模式。

如果你發現正在執行的應用程式是 Intel 表示他正在 Rosetta 2 底下運作。

手動安裝 Rosetta 2

個人覺得這個技巧至關重要，因為我曾經在 11.0.1 升級到 11.1 之後，Rosetta 就消失了，導致我還在用 Intel 架構的輸入法（對！連輸入法都可以靠 Rosetta 相容）死亡，也不知道為什麼 macOS 沒有主動提醒我要再安裝一次 Rosetta，直到我要安裝別的 Intel 應用程式時才又提醒，當時我才恍然大悟，原來我的 Rosetta 在升級的時候消失了……

方法也很簡單，只要打開終端機然後用軟體升級的方式安裝就可以了：

$ /usr/sbin/softwareupdate --install-rosetta --agree-to-license

雖然加了 --agree-to-license 之後就不會提醒你再看一次 SLA，但第一次使用前還是看一下吧XD

強制使用 Rosetta 來執行 Universal 應用程式

蘋果在轉換到 Apple silicon 的時候提出了一個以前^[3]也用過的解決方案，對於這樣的通用架構應用程式，我們可以透過「取得資訊」來將通用架構應用程式設定為使用 Rosetta 開啓。

透過 CLI 強制使用 Rosetta

前面講的是可以將 .app 應用程式以 Rosetta 方式開啓的技巧，但如果在 CLI 下的話該如何操作呢？

方法也很簡單，我們可以透過 arch 這個指令來幫我們跳入 x86_64 的世界：

$ which uname
/usr/bin/uname
$ file /usr/bin/uname
/usr/bin/uname: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64e:Mach-O 64-bit executable arm64e]
/usr/bin/uname (for architecture x86_64):	Mach-O 64-bit executable x86_64
/usr/bin/uname (for architecture arm64e):	Mach-O 64-bit executable arm64e
$ uname -u
arm64
$ arch -arch x86_64 uname -u
x86_64
$

同理，我們也可以靠 arch 指令來讓我們打開一個 x86_64 的 Shell，在裡面運作的程式就都會以 x86_64 優先了：

$ arch -arch x86_64 bash
[x86_64] $ uname -m
x86_64
$ arch -arch arm64e bash
[arm64e] $ uname -m
arm64
[arm64e] $

雖然這個範例中表示可以在 x86_64 模式下再跳回 arm64e 模式^[4]，但其實這件事情在 11.0.1 的時候還是不行的，會噴出不認識的 architecture 錯誤，但在 11.1 之後就可以了！

透過 sysctl 取得目前是不是在 Rosetta 中運作

這個也是一個實用的小技巧，我們可以透過 sysctl 瞭解目前的環境是不是在 Rosetta 中：

$ sysctl -n sysctl.proc_translated
0
$ arch -arch x86_64 sysctl -n sysctl.proc_translated
1
$

如果 sysctl.proc_translated 的值是 1 表示目前正在 Rosetta 中執行。

iOS App 相關

這裡會列出一些與 iOS App 相關的小技巧：

安裝 ipa 後無法執行

有時候會遇到安裝 .ipa 之後，macOS 卻阻止你執行的情況，這時候有可能是因為這個 App 被上了 com.apple.quarantine 這個屬性，我們只要用下面的方式就可以解開束縛：

$ sudo xattr -dr com.apple.quarantine <Installed.app>

通常這個屬性代表的是不安全的應用程式，例如從瀏覽器下載回來的應用程式就會自動打上這個屬性，只是不知道為何從 ipa 安裝的 App 並不會提醒你是否允許執行，而是直接拒絕你執行。

CLI 相關

這裡列出一些跟 CLI 有關的小技巧，如果是有關如何在 CLI 執行 Rosetta 的話可以往上面的節次看：

安裝 Homebrew

這好像不管是不是 M1 Mac 都會用到，但由於 Homebrew 散佈的執行檔都是單一架構的，所以這邊會另外展示如何安裝 Intel 架構的 Homebrew（以取得 Intel 架構的執行檔）。

Apple Silicon 版本的 Homebrew，按照原先的安裝方式就可以了：

$ /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

再來是 Intel 架構的 Homebrew，雖然 Homebrew 是用 Ruby 撰寫而成，其實可以直接用前面提到的 arch 來切換至 Intel 架構執行，但我是建議把 Intel 架構用的 Homebrew 跟 Apple 架構用的 Homebrew 分開，避免 Homebrew 搞不清楚跨架構 library 之間的相依性。

所以我們需要用替代安裝^[5]的方式把 Homebrew 安裝到指定的位置（這裡舉例是 /opt/homebrew.x86_64）：

$ mkdir -p /opt/homebrew.x86_64
$ curl -L https://github.com/Homebrew/brew/tarball/master | tar xz --strip 1 -C /opt/homebrew.x86_64

接下來我會在我的 Terminal 中設定兩個 Profile，一個是 Apple 架構的 Shell、另一個是 Intel 架構的（一樣用 arch 關進 Intel 模式）Shell，並且在 shellrc 中加入環境偵測來判斷使用哪個 Homebrew：

# ~/.zprofile

if [ "$(sysctl -n sysctl.proc_translated)" = "1" ]; then
	eval $(/opt/homebrew.x86_64/bin/brew shellenv)
else
	eval $(/opt/homebrew/bin/brew shellenv)
fi

# ~/.config/fish/config.fish

set is_rosetta (sysctl -n sysctl.proc_translated)
if [ $is_rosetta = '1' ]
    set homebrew /opt/homebrew.x86_64/bin
else
    set homebrew /opt/homebrew/bin
end

set default_path /usr/local/bin /usr/bin /usr/sbin /bin /sbin
set -gx PATH $homebrew $default_path

雜記

最後小小抱怨一下 macOS 11.0.1 根本就是還沒有完成的版本……
Bug 有夠多^[6]，而且還沒辦法做雙向轉換（人家 Windows <> WSL 就可以互相呼叫），好險 11.1 之後這些缺點都有補回來。
再用一陣子也許還會再增加一些技巧，不過基於我還在複習 macOS（畢竟有好多年沒用 Mac 了……），所以可能需要再一下下才會更新XD

雖然微軟在 BUILD 2020 上已經宣佈，未來會讓 WSL2 可以執行 GUI 應用程式^[1]，但不知道什麼時候才會正式支援這個功能，對於想體驗看看效果到底如何的我呢，就打算先在 Windows 端啓動一個 X Window Server 來嚐鮮看看。

事前準備

首先，對於一個習慣 Ubuntu 的我來說，如果可以體驗到完整的 Ubuntu 桌面是再好不過了，換句話說，我們需要在上面可以跑一個完整的 Gnome Shell 環境，並加上 Ubuntu 的 Extension 們。

取得完整 systemd 環境

Gnome Shell 從 3.34 版開始，就已經跟 systemd 整合^[2]了，也就是說，我們必須要先有一個完整的 systemd 環境才能順利的執行 Gnome Shell。由於 WSL2 的實作機制其實是啓動一個 Tiny Linux VM，然後利用 Linux Namespace 機制來執行並隔離各個發行版，並且由微軟實作了一個 init (PID 1) 來辦到快速啓動以及作為與 windows 溝通的橋樑^[3]。

也因此，在 WSL2 的系統裡面，其實是沒有啓用 systemd 的，我們可以簡單的透過下面的方式來檢查看看：

$ systemctl
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down
$ ps u -q 1
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root           1  0.0  0.0    908   592 ?        Sl   10:31   0:00 /init

可以很明顯的看到，當我們執行 systemctl 的時候，會顯示出我們的 init system (PID 1) 並非 systemd，而是微軟提供的 /init。

那我們如果想要擁有一個 systemd 環境的話，該怎麼辦呢？

由於 systemd 必須以 PID 1 的方式執行，所以直接執行 systemd 是沒有用的，但多虧了 Linux Namespace 我們可以在 WSL2 中建立新的 Namespace 並把 systemd 作為 PID 1 來執行，也就是在 WSL2 中再多加一層 PID Namespace，使得我們可以建築一個 systemd 的環境並跳進這個新的 Namespace 中。

所幸，我們不需要自己來研究這部分該如何操作，GitHub 上已經有幾個專案可以直接拿來參考並使用：

• arkane-systems
• DamionGans/ubuntu-wsl2-systemd-script

我們下面會使用 DamionGans/ubuntu-wsl2-systemd-script 來當作範例，只要按照說明操作就可以了：

$ git clone https://github.com/DamionGans/ubuntu-wsl2-systemd-script.git
Cloning into 'ubuntu-wsl2-systemd-script'...
remote: Enumerating objects: 76, done.
remote: Counting objects: 100% (76/76), done.
remote: Compressing objects: 100% (55/55), done.
remote: Total 76 (delta 40), reused 41 (delta 21), pack-reused 0
Unpacking objects: 100% (76/76), 19.46 KiB | 996.00 KiB/s, done.
$ cd ubuntu-wsl2-systemd-script/
ubuntu-wsl2-systemd-script $ bash ubuntu-wsl2-systemd-script.sh
[sudo] password for davy:
Hit:1 http://security.ubuntu.com/ubuntu focal-security InRelease
Hit:2 http://archive.ubuntu.com/ubuntu focal InRelease
Hit:3 http://archive.ubuntu.com/ubuntu focal-updates InRelease
Hit:4 http://archive.ubuntu.com/ubuntu focal-backports InRelease
Reading package lists... Done
(Reading database ... 31836 files and directories currently installed.)
Preparing to unpack .../0-dbus-user-session_1.12.16-2ubuntu2.1_amd64.deb ...
Unpacking dbus-user-session (1.12.16-2ubuntu2.1) over (1.12.16-2ubuntu2) ...
Preparing to unpack .../1-dbus-x11_1.12.16-2ubuntu2.1_amd64.deb ...
Unpacking dbus-x11 (1.12.16-2ubuntu2.1) over (1.12.16-2ubuntu2) ...
Preparing to unpack .../2-dbus_1.12.16-2ubuntu2.1_amd64.deb ...
Unpacking dbus (1.12.16-2ubuntu2.1) over (1.12.16-2ubuntu2) ...
Preparing to unpack .../3-libdbus-1-3_1.12.16-2ubuntu2.1_amd64.deb ...
Unpacking libdbus-1-3:amd64 (1.12.16-2ubuntu2.1) over (1.12.16-2ubuntu2) ...
Selecting previously unselected package daemonize.
Preparing to unpack .../4-daemonize_1.7.8-1_amd64.deb ...
Unpacking daemonize (1.7.8-1) ...
Selecting previously unselected package fontconfig.
Preparing to unpack .../5-fontconfig_2.13.1-2ubuntu3_amd64.deb ...
Unpacking fontconfig (2.13.1-2ubuntu3) ...
Setting up fontconfig (2.13.1-2ubuntu3) ...
Regenerating fonts cache... done.
Setting up libdbus-1-3:amd64 (1.12.16-2ubuntu2.1) ...
Setting up dbus (1.12.16-2ubuntu2.1) ...
Setting up daemonize (1.7.8-1) ...
Setting up dbus-x11 (1.12.16-2ubuntu2.1) ...
Setting up dbus-user-session (1.12.16-2ubuntu2.1) ...
Processing triggers for systemd (245.4-4ubuntu3) ...
Processing triggers for man-db (2.9.1-1) ...
Processing triggers for libc-bin (2.31-0ubuntu9) ...
rm: cannot remove '/lib/systemd/system/sysinit.target.wants/proc-sys-fs-binfmt_misc.mount': No such file or directory
'\\wsl$\Ubuntu-20.04\home\davy\ubuntu-wsl2-systemd-script'
是目前用來啟動 CMD.EXE 的目錄路徑。不支援 UNC 路徑。
預設目錄是 Windows 目錄。

成功: 已經儲存指定的值。
'\\wsl$\Ubuntu-20.04\home\davy\ubuntu-wsl2-systemd-script'
是目前用來啟動 CMD.EXE 的目錄路徑。不支援 UNC 路徑。
預設目錄是 Windows 目錄。

成功: 已經儲存指定的值。
ubuntu-wsl2-systemd-script $

安裝完畢後我們需要重啓整個 WSL2，假定我們的 WSL 名稱是 ubuntu-20.04，在命令提示字元（CMD）中執行下列指令以關閉 WSL2：

> wsl.exe -t ubuntu-20.04

接者使用一般使用者啓動 WSL2，就可以發現有不一樣的地方了（多了一個啓動 systemd 的提示），透過檢查 PID 1 也可以發現整個環境已經是由 systemd 掌握了：

Sleeping for 1 second to let systemd settle
Welcome to Ubuntu 20.04 LTS (GNU/Linux 4.19.104-microsoft-standard x86_64)

$ ps u -q 1
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root           1  2.8  0.0 175224 12920 ?        Ss   21:48   0:06 /lib/systemd/systemd --system-unit=basic.target
$

移除用不到的 snap（可選）

由於 Ubuntu 安裝 systemd 時，會連 snap 也一併啓用，如果大家用不到的話可以把 snap 從系統中移除，這麼一來也可以提升啓動速度，我們可以看到系統啓動時也連著一些 snap 的元件一起啓動了（而且還不少 Processes）：

$ ps aux
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root           1  1.3  0.0 108788 11360 ?        Ss   22:03   0:00 /lib/systemd/systemd --system-unit=basic.targ
root          43  2.1  0.1  45248 14600 ?        S<s  22:03   0:00 /lib/systemd/systemd-journald
root          61  0.4  0.0  21592  8496 ?        Ss   22:03   0:00 /lib/systemd/systemd-udevd
systemd+      63  1.2  0.0  18548  7896 ?        Ss   22:03   0:00 /lib/systemd/systemd-networkd
root         152  0.0  0.0  10572  4588 pts/0    S    22:03   0:00 /bin/login -p -f      'HOSTTYPE=x86_64' 'PWD=
root         219  1.2  0.0   3608  1792 ?        Ss   22:03   0:00 snapfuse /var/lib/snapd/snaps/core18_1705.sna
root         220  0.3  0.0   3660  1476 ?        Ss   22:03   0:00 snapfuse /var/lib/snapd/snaps/lxd_14804.snap
root         221  0.1  0.0   3488  1536 ?        Ss   22:03   0:00 snapfuse /var/lib/snapd/snaps/snapd_7264.snap
systemd+     228  1.1  0.0  24116 12592 ?        Ss   22:03   0:00 /lib/systemd/systemd-resolved
root         231  0.1  0.0 241020  9280 ?        Ssl  22:03   0:00 /usr/lib/accountsservice/accounts-daemon
message+     232  0.2  0.0   7428  4640 ?        Ss   22:03   0:00 /usr/bin/dbus-daemon --system --address=syste
root         235  0.3  0.1  29216 17788 ?        Ss   22:03   0:00 /usr/bin/python3 /usr/bin/networkd-dispatcher
syslog       236  0.1  0.0 224328  4296 ?        Ssl  22:03   0:00 /usr/sbin/rsyslogd -n -iNONE
root         238  2.1  0.2 1457156 35432 ?       Ssl  22:03   0:00 /usr/lib/snapd/snapd
root         240  1.1  0.0  16852  7728 ?        Ss   22:03   0:00 /lib/systemd/systemd-logind
root         261  0.0  0.0 236408  9084 ?        Ssl  22:03   0:00 /usr/lib/policykit-1/polkitd --no-debug
root         302  0.0  0.0   8540  2764 ?        Ss   22:03   0:00 /usr/sbin/cron -f
root         307  0.4  0.1 108036 20512 ?        Ssl  22:03   0:00 /usr/bin/python3 /usr/share/unattended-upgrad
daemon       308  0.0  0.0   3796  2200 ?        Ss   22:03   0:00 /usr/sbin/atd -f
root         318  0.0  0.0   7356  2172 tty1     Ss+  22:03   0:00 /sbin/agetty -o -p -- \u --noclear --keep-bau
root         326  0.0  0.0   5832  1744 ?        Ss   22:03   0:00 /sbin/agetty -o -p -- \u --noclear tty1 linux
davy         376  0.2  0.0  18444  9612 ?        Ss   22:03   0:00 /lib/systemd/systemd --user
davy         377  0.0  0.0 110132  3188 ?        S    22:03   0:00 (sd-pam)
davy         387  0.2  0.0  10048  4992 pts/0    S    22:03   0:00 -bash
davy         431  0.0  0.0  10604  3224 pts/0    R+   22:04   0:00 ps aux
$

首先我們先將所有 snap 都列出後，一個一個移除：

$ snap list
Name    Version   Rev    Tracking         Publisher   Notes
core18  20200311  1705   latest/stable    canonical✓  base
lxd     4.0.1     14804  latest/stable/…  canonical✓  -
snapd   2.44.3    7264   latest/stable    canonical✓  snapd
# snap remove lxd
# snap remove core18
# snap remove snapd
$ snap list
No snaps are installed yet. Try 'snap install hello-world'.
# apt purge snapd
$ ps aux
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root           1  0.6  0.0 109692 12692 ?        Ss   22:03   0:03 /lib/systemd/systemd --system-unit=basic.targ
root          43  0.1  0.1  53444 15456 ?        S<s  22:03   0:00 /lib/systemd/systemd-journald
root          61  0.0  0.0  21592  8496 ?        Ss   22:03   0:00 /lib/systemd/systemd-udevd
systemd+      63  0.1  0.0  18548  7896 ?        Ss   22:03   0:00 /lib/systemd/systemd-networkd
root         152  0.0  0.0  10572  4588 pts/0    S    22:03   0:00 /bin/login -p -f      'HOSTTYPE=x86_64' 'PWD=
systemd+     228  0.0  0.0  24116 12592 ?        Ss   22:03   0:00 /lib/systemd/systemd-resolved
root         231  0.0  0.0 241020  9280 ?        Ssl  22:03   0:00 /usr/lib/accountsservice/accounts-daemon
message+     232  0.0  0.0   7428  4640 ?        Ss   22:03   0:00 /usr/bin/dbus-daemon --system --address=syste
root         235  0.0  0.1  29216 17788 ?        Ss   22:03   0:00 /usr/bin/python3 /usr/bin/networkd-dispatcher
syslog       236  0.0  0.0 224328  4296 ?        Ssl  22:03   0:00 /usr/sbin/rsyslogd -n -iNONE
root         240  0.1  0.0  16852  7728 ?        Ss   22:03   0:00 /lib/systemd/systemd-logind
root         261  0.0  0.0 236408  9084 ?        Ssl  22:03   0:00 /usr/lib/policykit-1/polkitd --no-debug
root         302  0.0  0.0   8540  2764 ?        Ss   22:03   0:00 /usr/sbin/cron -f
root         307  0.0  0.1 108036 20512 ?        Ssl  22:03   0:00 /usr/bin/python3 /usr/share/unattended-upgrad
daemon       308  0.0  0.0   3796  2200 ?        Ss   22:03   0:00 /usr/sbin/atd -f
root         318  0.0  0.0   7356  2172 tty1     Ss+  22:03   0:00 /sbin/agetty -o -p -- \u --noclear --keep-bau
root         326  0.0  0.0   5832  1744 ?        Ss   22:03   0:00 /sbin/agetty -o -p -- \u --noclear tty1 linux
davy         376  0.0  0.0  18444  9708 ?        Ss   22:03   0:00 /lib/systemd/systemd --user
davy         377  0.0  0.0 110132  3188 ?        S    22:03   0:00 (sd-pam)
davy         387  0.0  0.0  10180  5252 pts/0    S    22:03   0:00 -bash
root        1168  0.0  0.1 283780 15888 ?        Ssl  22:07   0:00 /usr/lib/packagekit/packagekitd
davy        1273  0.0  0.0  10604  3316 pts/0    R+   22:11   0:00 ps aux

結束後我們就可以發現 Processes 數量減少了許多，讓我們的環境又稍微輕量了些。

在 Windows 準備 X Window Server

這邊有很多選擇，我選擇了 X410^[4]（付費），大家也可以選擇 VcXsrv^[5] 之類的解決方案，這邊就不多贅述了，在這裡的範例中會需要將 X Window Server 開在 Windows 的 6000 port 上。

安裝 Ubuntu 桌面

接著我們就可以來安裝 Ubuntu 的預設桌面了，這裡會需要比較多的硬碟空間：

# apt install ubuntu-desktop
...
10 upgraded, 1077 newly installed, 0 to remove and 64 not upgraded.
Need to get 605 MB of archives.
After this operation, 2260 MB of additional disk space will be used.
Do you want to continue? [Y/n] y
...

安裝結束後，我們需要先取得 Windows 的 IP 位置^[6]，並嘗試對 X Window Server 連線看看：

$ cat /etc/resolv.conf
# This file was automatically generated by WSL. To stop automatic generation of this file, add the following entry to /etc/wsl.conf:
# [network]
# generateResolvConf = false
nameserver 172.17.160.1
$ nc -v 172.17.160.1 6000
Connection to 172.17.160.1 6000 port [tcp/x11] succeeded!
^C
$

成功連線後，我們可以撰寫一個啓動腳本，將 DISPLAY 指向 Windows 上的 X Window Server 中並且加上一些 Ubuntu 桌面的設定後執行 Gnome Shell：

$ cat - > gnome.sh <<'EOF'
#!/bin/bash
export DISPLAY=$(cat /etc/resolv.conf | grep nameserver | awk '{print $2}'):0.0;
export XDG_SESSION_TYPE="x11"
export XDG_RUNTIME_DIR=~/.cache/xdg
export XDG_SESSION_CLASS="user"
export XDG_SESSION_DESKTOP=ubuntu
export XDG_CURRENT_DESKTOP=ubuntu:GNOME
export DESKTOP_SESSION=ubuntu
export GDMSESSION=ubuntu
export GNOME_SHELL_SESSION_MODE=ubuntu

gnome-session "$@"
EOF
$ chmod +x gnome.sh
$ ./gnome.sh

當然，如果想要在這個桌面中執行 Windows CMD 也是沒有問題的，而系統也可以正確的偵測到 Virtualization 是 WSL 呢。

關閉 systemd-resolved

這裡是一個可選的項目，由於筆者在透過 /etc/resolv.conf 取得 Windows IP 時有遇到 resolv.conf 被 systemd-resolved 替換成 127.0.0.53 的問題，這邊提供一個方式將這個東西停用，操作完重啓 WSL2 即可：

# systemctl stop systemd-resolved
# systemctl disable systemd-resolved
Removed /etc/systemd/system/multi-user.target.wants/systemd-resolved.service.
Removed /etc/systemd/system/dbus-org.freedesktop.resolve1.service.

後記

由於目前的 WSL2 還沒有 GPGPU 加速，所以拿來執行 GUI 程式的話可能還是會有點 lag，微軟提出的最終方案是透過 RDP 來執行 GUI 應用程式也許會透過 RemoteApp 來將顯卡加速做在 Windows 端，但作為嚐鮮一下，目前的結果已經算是還可以的了XD