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.

The snapcraft.io site: where snap developers and users meet

But as the popularity of snaps grows — some new Linux distros come with the snapd service installed by default — you might be forgiven for wondering how you’re supposed to make them work. Don’t get me wrong: there are all kinds of web-based guides for finding, installing, and removing snaps. And there are places developers can go for help building their applications as snaps. But right now I’m talking about configuring their behavior or troubleshooting when things go wrong.

Just for the record, you search for new snaps to install using something like:

snap find aws

When you find a package you like, you install it using:

snap install aws-cli

Oh, and you delete ‘em with remove.

snap remove aws-cli

There. You can’t say I never taught you anything. But that’s not what this article is about. What we are going to talk about is real management stuff, like changing configurations or troubleshooting things that broke.

Understanding the snap file system

Well, how’s that going to be different from the way you’d normally do it on Linux? Configuration files are usually going to be in /etc/, processes will reveal their deepest secrets through systemctl, and logs will find their way to /var/log/.

Not so fast there, pilgrim. That’s not always how things work in Snapland. You see, a snap is really nothing more than a single compressed file (named using the .snap extension) containing the entire file system needed for running a package. These files are never actually decompressed and “installed,” but are mounted dynamically at run time and exposed to the user as a virtual environment.

This means that the resources used by a program might not actually exist on the host system. Thus, for example, the Nextcloud snap creates its own versions of Apache and MySQL for its backend. So if, say, you want to configure a new virtual host in /etc/apache2/sites-available/ or create a new MySQL user the traditional way, you’re out of luck.

The advantages of this approach are significant: installation and setup will generally be much smoother and you’re far less likely to run into dependency issues and conflicts. But it also at least appears to mean that you get less access to the vital organs that power your software.

So, then, where does everything snappy happen? Take a look through your host file system for yourself: you’ll probably find more snap directories than you can shake a stick at (should you be so inclined). Here are the directories the snap install process probably created:

/snap/
/var/snap/
/var/lib/snapd/
/home/username/snap/

That many? What for? Let’s go through those one at a time. Feel free to poke around your own Linux machine to see all this for yourself.

The actual .snap files are kept in the /var/lib/snapd/snaps/ directory. When running, those files will be mounted within the root directory /snap/. Looking over there — in the /snap/core/ subdirectory — you’ll see what looks like a regular Linux file system. It’s actually the virtual file system that’s being used by active snaps.

ls /snap/core/current
bin   dev  home  lib64  meta  opt   root  sbin  srv  tmp  var
boot  etc  lib   media  mnt   proc  run   snap  sys  usr  writable

And here’s a subdirectory containing (read-only) configuration files used by the Nextcloud snap. That’ll only be there, of course, if you’ve installed Nextcloud (snap install nextcloud).

ls /snap/nextcloud/current/conf/
httpd.conf  mime.types  ssl.conf

Ok. Now what about /var/snap/? Very much like traditional inhabitants of /var/, the files within /var/snap/ contain various forms of user data and log files — the kind of data that’s generated and consumed by applications during operations. This example shows directories for data used by some desktop-related snaps, including the AWS CLI and the Slack team communication tool. (OK, technically speaking, the AWS CLI isn’t a desktop tool.)

ls /var/snap
aws-cli  core18           gnome-system-monitor  gnome-calculator
brave    gnome-3-26-1604  gnome-characters      gtk-common-themes
core     gnome-3-28-1804  gnome-logs            slack

Dive deep into the subdirectories within _/var/snap/_on your machine and see what you can discover.

That leaves just the ~/snap directory that exists in a user’s home directory on at least some Linux file systems. It’ll contain directories using some of the names you’ll see in /var/snap. What’s going on in there?

ls ~/snap
aws-cli  brave  gnome-calculator  slack

As far as I can tell, these directories are meant to store versioned data related to settings used by your user account.

Snap administration tools

So far I’ve shown you how to find various classes of data kept in configuration files (within /var/snap/), virtual file systems (/snap/), and collections of user settings (~/snap). I also showed you where not to look — /var/lib/snapd/ — which is where the .snap files themselves live; nothing to see here, move along now.

Now what about actual administration? This is a bit more complicated. Some snaps — like Nextcloud — expose a fully-featured admin interface. I talk about that in my Administrating Nextcloud as a Snap article. But it seems that the simplicity of snaps sometimes means that there just isn’t much hands-on configuration that’s possible.

However, that’s not always the case. But first, you’ll need to know about snap services. Some more complex applications require multi-layer software stacks. Nextcloud, for instance, creates and manages its own versions of Apache, MySQL, PHP, and Redis. Each one of those “layers” is, in snap terms, called a service.

If any snaps installed on your machine have their own services, you’ll be able to list them along with their status using this snapd command:

snap services
Service                    Startup  Current   Notes
nextcloud.apache           enabled  active    -
nextcloud.mdns-publisher   enabled  active    -
nextcloud.mysql            enabled  active    -
nextcloud.nextcloud-cron   enabled  active    -
nextcloud.nextcloud-fixer  enabled  inactive  -
nextcloud.php-fpm          enabled  active    -
nextcloud.redis-server     enabled  active    -
nextcloud.renew-certs      enabled  active    -

You can also control the run and startup status of a service. This example will stop Nextcloud’s Apache service and ensure that it doesn’t launch when the system reboots (although, just remember that this will disable Nextcloud — you probably don’t want to do that):

snap stop --disable nextcloud.apache

You can also use systemctl to manage snap service processes:

systemctl status snap.nextcloud.apache

If your snap includes at least one service, you can view its logs using snapd:

snap logs nextcloud

You can also specify a particular service:

snap logs nextcloud.mysql

For some snaps (like Nextcloud), snapd makes useful configurations available from the command line. You can display available settings using snap get:

snap get nextcloud
Key        Value
mode       production
nextcloud  {...}
php        {...}
ports      {...}
private    {...}

Drop down a level by adding the name of a specific setting. This example shows us that Nextcloud is currently listening on only ports 80 (HTTP) and 443 (HTTPS).

snap get nextcloud ports
Key          Value
ports.http   80
ports.https  443

You could change a setting using the set command. This one would tell Nextcloud to listen on port 8080 for insecure HTTP requests instead of 80.

snap set nextcloud ports.http=8080

Snapd also offers some system-wide configuration settings that are described here, documentation of environment variables is maintained here, and information on keeping your snaps updated can be found here.

All that’ll get you started when things need fixing. So get to it.

Looking for more? You might enjoy my books and Pluralsight courses on Linux, AWS, and Docker-related topics.