Linux Package Management with Snaps

A big part of administrating Linux machines - especially remote machines - is managing and installing software.

When something goes wrong with a local application or when something on the file system breaks and needs fixing, you're often going to want to push updates without having to travel many miles to sit down in front of a physical screen.

A lot of problems can be solved through Bash scripts, of course, but there are still plenty of use-cases where there's no alternative to a good old fashioned binary.

Imagine that some of your remote systems need new applications installed so the team members using those computers will be able to perform some business function. Being able to leverage the integration and automation of one of the major Linux repository systems - like Debian or RPM - can make your administration tasks a whole lot easier.

In this article we'll explore a relatively new standalone package management system: Snap.

As Linus Torvalds never tires of reminding us, the problem with many Linux software managements systems is that there are too many Linux software management systems.

App development and even Linux adoption have, over the years, become more complicated. All the time and work you invest in preparing your software for, say, Debian repos, won't help you if you want to get them into RPM systems. And neither will help for SUSE's zypper manager.

As I show in my Pluralsight course: Linux System Maintenance and Troubleshooting, one promising solution to the software silo problem is to distribute applications with their own self-contained environments that'll work on any Linux distribution.

The two big standards in this young and growing field are AppImage and snap. We'll start with snaps.

Working with Snaps

The snap system - under the guidance of Canonical, the company that sponsors Ubuntu - installs each individual application on your system within its own virtual partition. All those loop partitions sure make a royal mess of the output of the df command, but they also represent a rational approach to distributing a single version of software across any and all Linux installations.

$ df
Filesystem     1K-blocks      Used Available Use% Mounted on
udev             7101884         0   7101884   0% /dev
tmpfs            1432092      3936   1428156   1% /run
/dev/sda2      479152840 183520724 271222724  41% /
tmpfs            7160452    329336   6831116   5% /dev/shm
tmpfs               5120         4      5116   1% /run/lock
tmpfs            7160452         0   7160452   0% /sys/fs/cgroup
/dev/loop2           384       384         0 100% /snap/gnome-characters/539
/dev/loop4         56320     56320         0 100% /snap/core18/1705
/dev/loop5         56320     56320         0 100% /snap/core18/1754
/dev/loop3        145664    145664         0 100% /snap/slack/23
/dev/loop0          2560      2560         0 100% /snap/gnome-calculator/730
/dev/loop6         15360     15360         0 100% /snap/aws-cli/130
[...]
/dev/loop21       521216    521216         0 100% /snap/onlyoffice-desktopeditors/38
/dev/loop22       145664    145664         0 100% /snap/slack/22
/dev/loop23       185472    185472         0 100% /snap/spotify/36
/dev/loop25        96128     96128         0 100% /snap/core/8935
/dev/loop26       319104    319104         0 100% /snap/onlyoffice-desktopeditors/43
/dev/loop27         1152      1152         0 100% /snap/drawing/16
/dev/loop24        56192     56192         0 100% /snap/gtk-common-themes/1502
/dev/loop31         2560      2560         0 100% /snap/gnome-calculator/748
/dev/sda1         523248      6152    517096   2% /boot/efi
tmpfs            1432088        12   1432076   1% /run/user/121
tmpfs                100         0       100   0% /var/lib/lxd/shmounts
tmpfs                100         0       100   0% /var/lib/lxd/devlxd
tmpfs            1432088        68   1432020   1% /run/user/1000

In this demo, I'm going to show you how to package a GitHub-based application as a snap. With such a package, you would theoretically be able to submit it to the official snap store where, if accepted, it would be freely available to anyone on earth.

Now, I could pretend that I worked tirelessly to figure out the very best way to get all this done from the command line - but that wouldn't be completely honest. Actually, it wouldn't be honest at all.

In fact, I simply used the "first snap" tutorial on the snapcraft.io website that lets you select a language and then helpfully guides you through each step of the process. At the very end, it shows you how to submit your snap to the official snap store.

I'm going to take you through the process from the command line but, if you're doing this for yourself, it would probably make sense to check out the website to make sure nothing has changed.

So let's begin. You'll first need to make sure that the virtual machine manager Multipass is properly installed, since that's what snap uses to create the VMs where the images will be build. Naturally, Multipass itself is available as a snap.

Likewise, you'll need the snapcraft package. After installing snapcraft, you should follow it up with "hash -r" to refresh the list of places your shell will look for known programs.

$ sudo snap install multipass --classic
$ sudo snap install snapcraft --classic
$ hash -r

As I went with Python for my language, the tutorial provided me with a link to the GitHub site of an open source Python email backup project called OfflineIMAP. Don't feel you're restricted to Python, for that matter. And, obviously, you can substitute your own project for the example.

When I've cloned the project locally, I'll cd into the new offlineimap directory. Next, I'll use wget to download the special Python-specific version of the YAML configuration file.

Since there's already a file with that name in the directory, this one will get an alternative name, so I'll just overwrite the old copy by changing the name of the new one. We'll then open the file and edit the three places where the word "name" appears in curly braces. I need to replace those with the name I'd actually like to use.

$ git clone https://github.com/snapcraft-docs/offlineimap
$ cd offlineimap
$ wget https://snapcraft.io/first-snap/python/snapcraft.yaml

From here, running "snapcraft" will take care of the packaging process. This can be a long process, especially if there's software you need - like Multipass - that's not yet installed and set up. You may see some errors, but the odds are that the install script with automatically fix them on the fly.

When that's all died down, you can install the snap locally using the regular "snap install" command, but you'll need to add --devmode and --dangerous because this isn't an official, supported snap so, technically, no one knows what might happen when you start it up.

You can prove it's installed by running "snap list" and then confirm that everything worked by running the test-offlineimap-mysnap command with -h to get the help screen.

Enjoy the software - I know that this kind of email backup is something I've been meaning to get to for years.

$ snapcraft
$ sudo snap install --devmode --dangerous *.snap
$ snap list
$ test-offlineimap-mysnap -h

If you're interested in learning how to manage snaps within your Linux environment, you might also enjoy my "How to manage Ubuntu Snaps: the stuff no one tells you" and "snapd Makes Administering Nextcloud a Snap" articles.

Working with other package managers

We just got a pretty good look at snaps. But perhaps now is the perfect time to admit that I've left out some other big players in the alternative package manager world, in particular Flatpak and AppImages.

I discuss AppImages in some depth here, but a quick word or two about Flatpak wouldn't be out of place here.

Flatpak's primary goal is to let developers build their applications into a single package and then distribute them to any Linux distribution. As an end-user, you would install the Flatpak system using your regular software manager - like Apt on Ubuntu or Yum on CentOS. Flatpak is installed by default on Fedora. From there, it's pretty much smooth sailing. Solves all the right problems, doesn't it?

Perhaps. There's been some recent criticism over possible (and significant) security weaknesses in the fundamental design of Flatpak. I'll let you decide for yourself.

There's much more administration goodness in the form of books, courses, and articles available at my bootstrap-it.com.