Canonical 告訴你如何不通過 Snap 商店使用 Snap 包
對 Ubuntu 的 Snap 打包格式最常見的誤解之一是它是專有的 —— 但是深入研究其文檔后，會發現這個說法并不對。
在上周末拉脫維亞的里加舉行的 Ubuntu 峰會上，筆者有幸采訪到 Ubuntu 的開發者大使developer advocate，Igor Ljubuncic。期間，他們詳細探討了關于 Snap 的各種誤區，包括它被視為完全閉源的、受 Canonical 控制、必須使用 Canonical 的 Snap 商店等眾多謬論。
如果說有什么比糟糕的軟件更加厭惡的，那一定是謊言。正如我們在 點評 Fedora 39 時所注意到的，即使在 Linux 誕生之前，各種軟件的擁躉們就經常爆發各種 圣戰。但我們至少希望能堅守事實的公道。毫無根據的惡意指責是沒有必要的：生活本身已經足夠糟糕。
筆者的立場很明確，我們并不特別偏愛任何 Linux 發行版或其打包工具。像許多資深電腦技術人員一樣，在長期和各種軟件打交道后，筆者已經對所有的軟件厭煩至極。一句廣為接受的說法就是：沒有一個軟件不讓人頭疼。
Linux 就是一個軟件，因而它難免讓人頭疼。承此，所有的 Linux 發行版也都不盡如人意。包管理器也是一個軟件，同樣也不盡人意。但幸運的是，至少大多數 Linux 發行版都有一個包管理器。這比沒有軟件包管理器要好，或者更糟糕的是，有不止一個以上的包管理器，這一點 XKCD 927 漫畫體現的淋漓盡致。
我們并不特別青睞 Snap，也不特別反對 Flatpak。筆者個人更偏好 AppImage 格式，它不需要其他額外的框架。但雖然有個 AppImageHub，但該格式卻并沒有提供軟件更新的工具，這個問題就留給了應用本身來解決。
鑒于所有的軟件都不完美，那唯一重要的區別就在于其問題嚴重的程度。一段時間以后，你最關注的就是它是否可運行，能否滿足你的需要，以及它的可靠性。
我在早年的職業生涯中花了很多時間在技術支持上，修復其他人的軟件。因此，我學到了一個經驗，那就是降低軟件讓人厭煩程度的一個重要因素就是它工作的方式是否容易理解。
Btrfs 是復雜的，而修復它則更是如此。Git 屬于本質復雜，其 名稱 就體現出這一點。（沒錯，“git” 是一個名詞，而非縮寫或代號，有實際的意思 —— “飯桶”。）OStree 可以說是針對二進制文件的 Git，這使得它比普通 Git 至少復雜兩倍。而 Flatpak 則是 OStree 的封裝。
這意味著增加了兩層額外的復雜度：首先，對復雜事物的封裝只能隱藏其復雜性，而不能消除其復雜性。其次，你不能使用 Flatpak 構建一個操作系統，因此你還需要 OStree。
因此，我們將來逐一揭穿關于 Snap 格式和工具的一些誤解。這不是一篇入門指南，而是對那些不那么顯而易見，并且對 Snap 有所誤解的人的一份快速概覽。
無需商店進行分發
Snap 包其實就是一個 Squashfs，類似于大多數 Linux 安裝介質上的系統鏡像。Snap 包以兩個文件傳遞：其中一個是命名為 <name>_<revision>.snap，該文件包含了軟件本身；另一個則是一個伴隨的 聲明文件，它為 Snap 提供了數字簽名。然后，Canonical 還進一步 詳細闡明 了版本修訂的工作原則。
使用 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 包（如 Firefox），將其放入你的內部倉庫中，或是 FTP，或是 NFS 上。接著你可以使用它作為在內部安裝 Snap 的來源，而這不需要去訪問商店。此外，你還可以將這個操作與你所使用的任何調度或部署機制結合起來，就如配置管理那樣。”
安裝無需聲明文件的 Snap 包
通常來說，snap ack 命令會首先讀取并驗證簽名，但是你可以選擇跳過這個步驟。
snap install "downloaded snap" --dangerous上述指令會安裝該 Snap 包，并不會驗證其簽名。請注意，這樣做雖然操作簡單，但也有一個重要的限制：使用 --dangerous 選項安裝的 Snap 包不會自動從商店中更新。
所以，實際上，你可以在你的網絡內部分發 Snap 包，避免它們試圖連接到 Snap 商店，并自主管理更新。
管控 snapd 內置的更新機制
另一方面，你可以在不忽略驗證機制的前提下，管理和控制操作系統何時以及如何更新 Snap 包。Igor 則曾撰寫過關于如何使 Snap 更新暫停 的文章。
你可以設置暫停 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 和 seccomp 實現安全隔離。
你可以將其內容解壓并直接運行：
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/<snap name>/，然后是 /lib、/usr/lib 和其他常用路徑。至于其他內容，firefox.launcher 文件負責準備運行環境，剩余的，比如 firefox.desktop，都用于桌面集成：如圖標、全名、文件關聯等。這些內容雖然使應用看起來效果更好，但它們并非嚴格的必需品。
其實，你甚至不需要解壓 Snap 的內容，你可以直接將 Snap 文件本身作為一個 回環設備 掛載 —— 你甚至可以設置為只讀 —— 但沒有掛載命名空間隔離。并且，如果沒有設置環境讓 Snap 內部的應用在尋找它的庫時首先從 Snap 內部開始，你仍然需要正確地設置庫路徑。
代理和緩存 Snap 包
正如 Igor 所說，如果客戶并不打算自行運營一家具備完整品牌屬性的 Snap 商店，他們可以選擇手動設置一個 Snap 代理。對此，Canonical 也提供了相應的 文檔，并描述了所需的 網絡訪問 權限。
同時，你也可以 配置 一個緩存 Snap 代理 —— 這項任務稍微簡單一些，對于希望降低下載帶寬的家庭網絡來說，可能是個不錯的選擇。
搭建自己的 Snap 商店
就如我們之前所述，你完全可以忽略所有來自 Canonical 的基礎設施，直接運行自己的 Snap 商店。去年，我們寫過一篇關于 Ubuntu Unity 維護者 Rudra Saraswat 的文章，他就 做到了這一點，這只是他的眾多項目中之一。據悉，好幾個在生產環境中使用 Ubuntu Core 的組織都采取了此種做法，而所有所需的工具都存放在 Ubuntu 倉庫中。
Canonical 在這方面發布了大量的文檔，包括怎樣構建你的 第一個 Snap 包，以及如何用 不同的編程語言 構建。今年的峰會上有多場關于如何構建 Snap 的演講 － 包括 在平板電腦上構建 Snap 包，以及如何 自動化構建更新的 Snap 包，雖然這對筆者來說有點過于復雜。
學習一些新的術語是有必要的，同時也有 官方文檔 提供幫助。這段解釋我們特別喜歡：
- 插槽slots
- 插口plugs
- 接口interfaces
從我們與 Canonical 代表的對話中，他們似乎對 Snap 商店被誤解，以及 Snap 被視為封閉、專有系統的爭論顯得尤為不滿。
大約十五年前，有人曾聲稱 Canonical 的代碼托管和項目管理平臺 Launchpad 是專有的，所以 Canonical 在整理代碼后在 2009 年 公開發布 了代碼庫。但如我們交談的人所言：“沒人在意。” 它是 Canonical 的內部工具，對其他人來說并沒有太大的用處。他們表示，他們不希望再經歷一次這樣的情況。
我們還注意到，紅帽正在朝反方向前進，即從開源的 Bugzilla 遷移 到封閉的、基于云的 Jira —— 這并未引起太大的爭議。
snapd 自身的代碼已經托管在 GitHub 上，作為 Canonical 的 snapcore 倉庫的一部分。這個被大多數發行版使用的打包格式是一個已經存在、有文檔記錄的格式。用于進行隔離的工具，是已經存在并在其他發行版中使用的第三方工具，比如，Debian 和 SUSE 家族也使用了 AppArmor，這與 Arch 維基中的 描述 相符，而它的主要競品，SELinux，則更復雜，主要在紅帽及其衍生產品中使用。
盡管 Canonical 自家定制的 Snap 商店 的后端仍然 閉源，但 Snap 格式、snapcore 軟件、snapcraft.io 前端，以及更多組件都是開放的。我們再次強調，你完全可以自行搭建 自己的 Snap 商店。
請不要受到憤怒的論壇噴子們的誤導。
最后再說一點...
實際上，撰寫這篇文章的作者曾經就職于紅帽和 SUSE，但他主要還是使用 Ubuntu，從 2004 年 Ubuntu 剛剛發布起就開始一直使用。Ubuntu 不但運行順暢，使用起來也十分便捷。然而，早在多年前他就已經從他的主要工作電腦上刪除了 snapd 和相關的一切工具，取而代之的是 deb-get —— 最初這是 Ubuntu MATE 的創造者 Martin Wimpress 編寫的。為了更加迅速，他還選擇使用 Nala 包管理器 而不是 Apt。
如果可以的話，筆者很希望可以放棄各種形式的 Unix，除了服務器，其他情況下更傾向于使用 RISC OS 或是經典的 MacOS。但是遺憾的是，這兩個操作系統在網絡瀏覽器、網絡連接，還有多核支持和整體穩定性上有待改進。
筆者今年參加 Ubuntu 峰會的費用是由 Canonical 承擔的，這一點他愿意公開。類似的，Linux 基金會曾資助他參加 今年 在 Bilbao 的開源峰會，而紅帽則資助了他在 2016 年在 Kraków 參加 Flock to Fedora 峰會。這類贊助可以讓我們將廣告預算分配到其他地方，但并不會對我們的報道產生影響：我們總會積極追蹤那些 IT 新聞。
