Canonical 告訴你如何不通過 Snap 商店使用 Snap 包 | Linux 中國

導讀：雖然你可能聽到不同的看法，但實際上，它並未像一些批評者所想象的那樣完全專有。

本文字數： 7541，閱讀時長大約： 10分鐘

https://linux.cn/article-16371-1.html作者：Liam Proven譯者：ChatGPT

對 Ubuntu 的 Snap 打包格式最常見的誤解之一是它是專有的 —— 但是深入研究其文檔後，會發現這個說法並不對。

在上週末拉脫維亞的里加舉行的 Ubuntu 峰會上，筆者有幸採訪到 Ubuntu 的開發者大使(developer advocate)，Igor Ljubuncic。期間，他們詳細探討了關於 Snap 的各種誤區，包括它被視爲完全閉源的、受 Canonical 控制、必須使用 Canonical 的 Snap 商店等衆多謬論。

如果說有什麼比糟糕的軟件更加厭惡的，那一定是謊言。正如我們在 www.theregister.com 時所注意到的，即使在 Linux 誕生之前，各種軟件的擁躉們就經常爆發各種 catb.org。但我們至少希望能堅守事實的公道。毫無根據的惡意指責是沒有必要的：生活本身已經足夠糟糕。

筆者的立場很明確，我們並不特別偏愛任何 Linux 發行版或其打包工具。像許多資深電腦技術人員一樣，在長期和各種軟件打交道後，筆者已經對所有的軟件厭煩至極。一句廣爲接受的說法就是：harmful.cat-v.org。

Linux 就是一個軟件，因而它難免讓人頭疼。承此，所有的 Linux 發行版也都不盡如人意。包管理器也是一個軟件，同樣也不盡人意。但幸運的是，至少大多數 Linux 發行版都有一個包管理器。這比沒有軟件包管理器要好，或者更糟糕的是，有不止一個以上的包管理器，這一點 xkcd.com 漫畫體現的淋漓盡致。

我們並不特別青睞 Snap，也不特別反對 Flatpak。筆者個人更偏好 appimage.org 格式，它不需要其他額外的框架。但雖然有個 www.appimagehub.com，但該格式卻並沒有提供軟件更新的工具，這個問題就留給了應用本身來解決。

鑑於所有的軟件都不完美，那唯一重要的區別就在於其問題嚴重的程度。一段時間以後，你最關注的就是它是否可運行，能否滿足你的需要，以及它的可靠性。

我在早年的職業生涯中花了很多時間在技術支持上，修復其他人的軟件。因此，我學到了一個經驗，那就是降低軟件讓人厭煩程度的一個重要因素就是它工作的方式是否容易理解。

Btrfs 是複雜的，而修復它則更是如此。Git 屬於本質複雜，其 dictionary.cambridge.org 就體現出這一點。（沒錯，“git” 是一個名詞，而非縮寫或代號，有實際的意思 —— “飯桶”。）OStree 可以說是針對二進制文件的 Git，這使得它比普通 Git 至少複雜兩倍。而 Flatpak 則是 OStree 的封裝。

這意味着增加了兩層額外的複雜度：首先，對複雜事物的封裝只能隱藏其複雜性，而不能消除其複雜性。其次，你不能使用 Flatpak 構建一個操作系統，因此你還需要 OStree。

因此，我們將來逐一揭穿關於 Snap 格式和工具的一些誤解。這不是一篇入門指南，而是對那些不那麼顯而易見，並且對 Snap 有所誤解的人的一份快速概覽。

無需商店進行分發

Snap 包其實就是一個 docs.kernel.org，類似於大多數 Linux 安裝介質上的系統鏡像。Snap 包以兩個文件傳遞：其中一個是命名爲 _.snap，該文件包含了軟件本身；另一個則是一個伴隨的 snapcraft.io，它爲 Snap 提供了數字簽名。然後，Canonical 還進一步 snapcraft.io 了版本修訂的工作原則。

使用 snap download 的指令（而非 snap install）可以容易獲取這些基本文件：

# snap download firefox

Fetching snap "firefox"

Fetching assertions for "firefox"

Install the snap with:

snap ack firefox_3252.assert

snap install firefox_3252.snap

然後，這些文件便可以被複制到另一臺設備上進行安裝，這種操作不需要訪問 Snap 商店，僅需使用輸出中的指令即可。

如 Igor 所說：

安裝無需聲明文件的 Snap 包

通常來說，snap ack 命令會首先讀取並驗證簽名，但是你可以選擇跳過這個步驟。

snap install "downloaded snap" --dangerous

上述指令會安裝該 Snap 包，並不會驗證其簽名。請注意，這樣做雖然操作簡單，但也有一個重要的限制：使用 --dangerous 選項安裝的 Snap 包不會自動從商店中更新。

所以，實際上，你可以在你的網絡內部分發 Snap 包，避免它們試圖連接到 Snap 商店，並自主管理更新。

管控 snapd 內置的更新機制

另一方面，你可以在不忽略驗證機制的前提下，管理和控制操作系統何時以及如何更新 Snap 包。Igor 則曾撰寫過關於如何使 Snap snapcraft.io 的文章。

你可以設置暫停 Snap 的更新一段時間，或永久暫停，甚至只選擇暫停特定的 Snap 包，同時也能簡單取消此設置。例如：

snap refresh --hold

Auto-refresh of all snaps held indefinitely.

另外，你也可以通過以下方式設置防火牆攔截 Snap API：

sudo iptables -A OUTPUT -d api.snapcraft.io -j DROP

在無 snapd 環境下運行 snaps

.snap 文件實際上就是一個壓縮的文件系統，它包含着程序文件（以及各種庫等），這些都被存放在一個傳統的目錄結構中，而該目錄結構對於打包在 Snap 應用程序內的應用來說，就是它的根目錄。Snapd 負責爲此設置掛載名空間，並通過 apparmor.net 和 man7.org 實現安全隔離。

你可以將其內容解壓並直接運行：

unsquashfs firefox_3252.snap

Parallel unsquashfs: Using 20 processors

565 inodes (5428 blocks) to write

[=====================/] 5428/5428 100%

created 399 files

created 149 directories

created 166 symlinks

created 0 devices

created 0 fifos

created 0 sockets

ll squashfs-root/

total 80

drwxr-xr-x 7 igor igor 4096 lis 10 02:33 ./

drwxr-xr-x 10 igor igor 4096 lis 19 15:32 ../

drwxr-xr-x 5 igor igor 4096 lis 10 02:33 data-dir/

-rw-r--r-- 1 igor igor 32441 lis 10 02:33 default256.png

-rw-r--r-- 1 igor igor 9146 lis 10 02:33 firefox.desktop

-rwxr-xr-x 1 igor igor 2680 lis 10 02:33 firefox.launcher*

drwxr-xr-x 2 igor igor 4096 lis 10 02:33 gnome-platform/

drwxr-xr-x 4 igor igor 4096 lis 10 02:33 meta/

-rwxr-xr-x 1 igor igor 3716 lis 10 02:33 patch-default-profile.py*

drwxr-xr-x 4 igor igor 4096 lis 10 02:33 snap/

drwxr-xr-x 4 igor igor 4096 sij 19 2022 usr/

如果你查看 Snap 內 Firefox 二進制文件的動態依賴，你會注意到它希望從根文件系統中獲取文件：

ldd usr/lib/firefox/firefox-bin

linux-vdso.so.1 (0x00007fff33cc5000)

libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f6cf2c00000)

libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f6cf2e40000)

libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f6cf2be0000)

libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6cf2800000)

/lib64/ld-linux-x86-64.so.2 (0x00007f6cf300e000)

在 Snap 內部，這個“根”就是你的基礎系統（比如 core18 或 core20 等）。但是一旦你解壓了這個 Snap，沒有 snapd 在安裝和運行 Snap 時提供的安全隔離，Firefox 將會嘗試直接訪問你的根目錄的庫。這可能會導致執行時的不一致性。

舉例來說，你的 Snap 內可能包含的是 GNOME 3.38 版的庫，但是你的主機上運行的可能是 GNOME 3.32。如果你嘗試解壓並運行這個應用，它可能會試圖從主機中加載庫，這可能引起不一致 —— 更甚者，可能會讓程序崩潰。

爲了避免這種情況發生，你需要做的唯一事情就是設置 LD_LIBRARY_PATH 環境變量，以讓程序知道其庫在何處，確保它首選這些庫，而不是使用可能導致其運行失敗的操作系統中的庫副本。

LD_LIBRARY_PATH: ${SNAP_LIBRARY_PATH}${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}:$SNAP/usr/lib:$SNAP/usr/lib/x86_64-linux-gnu

通常，你會希望 LD_LIBRARY_PATH 開始於 /snap//，然後是 /lib、/usr/lib 和其他常用路徑。至於其他內容，firefox.launcher 文件負責準備運行環境，剩餘的，比如 firefox.desktop，都用於桌面集成：如圖標、全名、文件關聯等。這些內容雖然使應用看起來效果更好，但它們並非嚴格的必需品。

其實，你甚至不需要解壓 Snap 的內容，你可以直接將 Snap 文件本身作爲一個 tldp.org 掛載 —— 你甚至可以設置爲只讀 —— 但沒有掛載命名空間隔離。並且，如果沒有設置環境讓 Snap 內部的應用在尋找它的庫時首先從 Snap 內部開始，你仍然需要正確地設置庫路徑。

代理和緩存 Snap 包

正如 Igor 所說，如果客戶並不打算自行運營一傢俱備完整品牌屬性的 Snap 商店，他們可以選擇手動設置一個 docs.ubuntu.com。對此，Canonical 也提供了相應的 docs.ubuntu.com，並描述了所需的 forum.snapcraft.io 權限。

同時，你也可以 snapcraft.io 一個緩存 Snap 代理 —— 這項任務稍微簡單一些，對於希望降低下載帶寬的家庭網絡來說，可能是個不錯的選擇。

搭建自己的 Snap 商店

就如我們之前所述，你完全可以忽略所有來自 Canonical 的基礎設施，直接運行自己的 Snap 商店。去年，我們寫過一篇關於 Ubuntu Unity 維護者 www.theregister.com 的文章，他就 gitlab.com，這只是他的衆多項目中之一。據悉，好幾個在生產環境中使用 Ubuntu Core 的組織都採取了此種做法，而所有所需的工具都存放在 Ubuntu 倉庫中。

Canonical 在這方面發佈了大量的文檔，包括怎樣構建你的 snapcraft.io，以及如何用 snapcraft.io 構建。今年的峰會上有多場關於如何構建 Snap 的演講 － 包括 events.canonical.com，以及如何 events.canonical.com，雖然這對筆者來說有點過於複雜。

學習一些新的術語是有必要的，同時也有 snapcraft.io 提供幫助。這段解釋我們特別喜歡：

◈ 插槽(slots) 是指提供方（即 Snap 提供的資源）

◈ 插口(plugs) 是指消費者（即使用 Snap 提供的資源的用戶）

◈ 接口(interfaces) 是交互的地方（負責將插口和插槽連接起來）

從我們與 Canonical 代表的對話中，他們似乎對 Snap 商店被誤解，以及 Snap 被視爲封閉、專有系統的爭論顯得尤爲不滿。

大約十五年前，有人曾聲稱 Canonical 的代碼託管和項目管理平臺 www.theregister.com 是專有的，所以 Canonical 在整理代碼後在 2009 年 canonical.com 了代碼庫。但如我們交談的人所言：“沒人在意。” 它是 Canonical 的內部工具，對其他人來說並沒有太大的用處。他們表示，他們不希望再經歷一次這樣的情況。

我們還注意到，紅帽正在朝反方向前進，即從開源的 Bugzilla www.theregister.com 到封閉的、基於雲的 Jira —— 這並未引起太大的爭議。

github.com 自身的代碼已經託管在 GitHub 上，作爲 Canonical 的 github.com 倉庫的一部分。這個被大多數發行版使用的打包格式是一個已經存在、有文檔記錄的格式。用於進行隔離的工具，是已經存在並在其他發行版中使用的第三方工具，比如，Debian 和 SUSE 家族也使用了 AppArmor，這與 Arch 維基中的 wiki.archlinux.org 相符，而它的主要競品，selinuxproject.org，則更復雜，主要在紅帽及其衍生產品中使用。

儘管 Canonical 自家定製的 snapcraft.io 的後端仍然 askubuntu.com，但 Snap 格式、snapcore 軟件、github.com，以及更多組件都是開放的。我們再次強調，你完全可以自行搭建 ubuntu.com。

請不要受到憤怒的論壇噴子們的誤導。

最後再說一點...

實際上，撰寫這篇文章的作者曾經就職於紅帽和 SUSE，但他主要還是使用 Ubuntu，從 2004 年 Ubuntu 剛剛發佈起就開始一直使用。Ubuntu 不但運行順暢，使用起來也十分便捷。然而，早在多年前他就已經從他的主要工作電腦上刪除了 snapd 和相關的一切工具，取而代之的是 trendoceans.com —— 最初這是 Ubuntu MATE 的創造者 ubuntu-mate.org 編寫的。爲了更加迅速，他還選擇使用 github.com 而不是 Apt。

如果可以的話，筆者很希望可以放棄各種形式的 Unix，除了服務器，其他情況下更傾向於使用 RISC OS 或是經典的 MacOS。但是遺憾的是，這兩個操作系統在網絡瀏覽器、網絡連接，還有多核支持和整體穩定性上有待改進。

筆者今年參加 Ubuntu 峰會的費用是由 Canonical 承擔的，這一點他願意公開。類似的，Linux 基金會曾資助他參加 www.theregister.com 在 Bilbao 的開源峰會，而紅帽則資助了他在 2016 年在 Kraków 參加 www.theregister.com 峰會。這類贊助可以讓我們將廣告預算分配到其他地方，但並不會對我們的報道產生影響：我們總會積極追蹤那些 IT 新聞。

（題圖：MJ/520ba58f-9e07-4acb-af4a-f4832762311f）

via:

作者： 譯者： 校對：

本文由 原創編譯， 榮譽推出

歡迎遵照 CC-BY-SA 協議規定轉載，

如需轉載，請在文章下留言 “ 轉載：公衆號名稱”，

我們將爲您添加白名單，授權“ 轉載文章時可以修改”。