Lost or starting from here?
You just need to type in a terminal “snap install chuck-norris-webserver” as this is the snap we will need.
Here is a bag of various tricks that will turn your from a snap user to a real expert! Let’s not lose time and dive in right away!
Snap environment variables and paths
If you remember a few sections ago, we were only able to access to the user’s home directory in devmode or classic confinement. We should have used the home plug to make a snap able to access and write into the user’s home directory while being confined. Indeed, by default, snaps are only able to read and write to very few paths. Those are defined through environment variables.
Accessible files
snap run is a command that runs a snap command. This is the mechanism internally used to run application snaps. When adding the --shell option, it will drop you into a subshell where you can act “as the command”, with the same permissions (plug), seeing the same file system it has access to:
$ snap run --shell chuck-norris-webserver.cli
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.
didrocks@tidus:/home/didrocks$ ls /
ls: cannot open directory '/': Permission denied
didrocks@tidus:/home/didrocks$ touch foo
touch: cannot touch 'foo': Permission denied
Of course “didrocks” is currently my user name. We keep the prompt in the subshell to highlight we are typing command there.
Ok, let’s look at what we can thus access.
Get access to environment variables
Rather than listing them all, let’s have a look at them ourselves! This new bash instance can be used to print (and filter) environment variables, for instance:
didrocks@tidus:/home/didrocks$ env | grep SNAP
SNAP_USER_COMMON=/home/didrocks/snap/chuck-norris-webserver/common
SNAP_REEXEC=
SNAP_LIBRARY_PATH=/var/lib/snapd/lib/gl:/var/lib/snapd/void
SNAP_COMMON=/var/snap/chuck-norris-webserver/common
SNAP_DID_REEXEC=1
SNAP_USER_DATA=/home/didrocks/snap/chuck-norris-webserver/10
SNAP_DATA=/var/snap/chuck-norris-webserver/10
SNAP_REVISION=x1
SNAP_NAME=chuck-norris-webserver
SNAP_ARCH=amd64
SNAP_VERSION=1.0.0
SNAP=/snap/chuck-norris-webserver/10
You can see some internal env variables, like SNAP_NAME, SNAP_ARCH, SNAP_VERSION, SNAP_REVISION which could be used internally by the snap application.
You will then notice that most of the paths are versioned. They contain the revision as the last element of the path. This is how snapd enables installing multiple revisions of an application in parallel, and store data in a revisioned manner for solid rollbacks.
Application code path
One of the first variable to look at is $SNAP, it corresponds to the application code itself.
didrocks@tidus:/home/didrocks$ ls $SNAP
CHANGELOG.md README.md command-cli.wrapper etc lib share
LICENSE bin command-node-service.wrapper include meta snap
This directory is read-only:
didrocks@tidus:/home/didrocks$ touch $SNAP/foo
touch: cannot touch '/snap/chuck-norris-webserver/10/foo': Read-only file system
Ok, it’s useful to know where the application code is, but it’s even more interesting to know where the snap can write!
User writeable paths
Users can read and write to a directory referenced under $SNAP_USER_DATA and $SNAP_USER_COMMON.
didrocks@tidus:/home/didrocks$ echo $SNAP_USER_DATA
/home/didrocks/snap/chuck-norris-webserver/10
didrocks@tidus:/home/didrocks$ echo "test content" > $SNAP_USER_DATA/foo
didrocks@tidus:/home/didrocks$ ls -l $SNAP_USER_DATA
total 4
-rw-rw-r-- 1 didrocks didrocks 13 Mar 16 12:08 foo
didrocks@tidus:/home/didrocks$ cat $SNAP_USER_DATA/foo
test content
didrocks@tidus:/home/didrocks$ echo $SNAP_USER_COMMON
/home/didrocks/snap/chuck-norris-webserver/common
As you can see above, we can read and write as our user into those directories. (root user will have it under the root’s home directory as well, typically/root)
The difference between $SNAP_USER_DATA and $SNAP_USER_COMMON is that the first one is versioned by revision and not the last one. It means that applications should write revision-specific data in the _DATA* directory. Those will be copied on upgrade. The benefits, despite the extra space needed is that you can revert both the code and associated data, ensuring you always have a compatible configuration within your snap on any upgrade/revert combination!
Big files that aren’t related to a specific revision of a snap should use the _COMMON directory, which, as its names indicates, is available to any revision of the snap. Big assets like video files or any applications ensuring their configuration is both backward and forward compatible should use that directory.
Last tip! $HOME (if the home plug isn’t used) is set to $SNAP_USER_DATA:
didrocks@tidus:/home/didrocks$ echo $HOME
/home/didrocks/snap/chuck-norris-webserver/10
didrocks@tidus:/home/didrocks$ echo $SNAP_USER_DATA
/home/didrocks/snap/chuck-norris-webserver/10
Global writeable paths
Similarly to $SNAP_USER_DATA and $SNAP_USER_COMMON, there is $SNAP_DATA and $SNAP_COMMON. Those are only writable by root, but can be read by any other users.
didrocks@tidus:/home/didrocks$ touch $SNAP_DATA/foo
touch: cannot touch '/var/snap/chuck-norris-webserver/10/foo': Permission denied
didrocks@tidus:/home/didrocks$ ls -l $SNAP_DATA
total 0
-rw-r--r-- 1 root root 0 Mar 16 10:31 config
We can see that there is a config file in $SNAP_DATA! Let’s set some config values the values (in another terminal, outside of our snap run subshell):
$ snap set chuck-norris-webserver port="90" title="Test Title"
And let’s have a look in our snap subshell environment (note that the file modification date just changed):
didrocks@tidus:/home/didrocks$ ls -l $SNAP_DATA/config
total 0
-rw-r--r-- 1 root root 0 Mar 16 12:23 /var/snap/chuck-norris-webserver/10/config
didrocks@tidus:/home/didrocks$ cat $SNAP_DATA/config
port=90
title=Test title
This is thus where our config hook was storing its configuration (AHAH!). You can observe as well that the script was run as root (visible through permissions on the config file). This is a snap implementation detail and will depend on the snap itself of course, but that illustrates that those global writeable paths can be used to store global configuration, or data that will be used by snap services (running as root, as opposed to command line snaps which run as the current user). Nevertheless, the user has access to that directory and can read its content.
The difference between $SNAP_DATA and $SNAP_COMMON is similar to the one between $SNAP_USER_DATA and $SNAP_USER_COMMON, meaning that the first is revision-dependent (and its data will be copied on upgrade), while the second one is common amongst all revisions.
Enough deep diving, let’s now exit the subshell!
didrocks@tidus:/home/didrocks$ exit
snap info
General usage
The info command shows detailed information about a snap.
$ snap info chuck-norris-webserver
name: chuck-norris-webserver
summary: "Chuck Norris quotation nodejs server and cli"
publisher:
description: |
This example shows how to build a nodejs web server and cli. This enables us
to demonstrate how service works, basic confinement rules to access and listen
on the network, as well as the nodejs snapcraft plugin.
The command line demonstrate various file-based access permissions.
commands:
- chuck-norris-webserver.cli
tracking: stable
installed: 1.0.0 (10) 10MB -
refreshed: 2017-03-15 14:19:58 +0100 CET
channels:
stable: 1.0.0 (10) 10MB -
candidate: 1.0.1 (18) 11MB -
beta: 1.0.3 (22) 11MB -
edge: 1.0.3 (24) 11MB -
Snap info shows the snap name, summary and long description of the snap. In addition to this, available commands and paths to use them.
The revision, size and publication states corresponds to the ones that were available at the time of this writing.
The more interesting part is that, here, you can see that we are tracking the stable channel, that we are up to date (the installed revision 10 is the one published in the stable). The size of the snap is indicated. We can observe as well that there are different revision numbers depending on the channel. The human-readable version is also available for each.
Here is a confirmation that the version string is different between revision number: both beta and edge channels have 1.0.3 with different snap revisions. This could mean that:
- The snap author pushed a 1.0.3 version as revision 22 in the beta and edge channels.
- The author then got some user feedback on that revision and fixed issues.
- Those fixes are now pushed again (still as 1.0.3 which isn’t released) in the edge channel only (for now) as revision 24.
- This revision 24 will certainly migrate up to other channels as time goes by, if there isn’t any regression noticed.
Here is a full demonstration of the power of snaps!
Information for unpublished snaps
snap info is also a good way to see the status of a snap which isn’t published on the stable channel. Remember that snap find only show stable channel snaps, but if you have the name of a snap and want to see its revisions and general info, you can use it too!
$ snap info face-detection-demo
name: face-detection-demo
summary: "Web interface detecting faces from webcam shots"
publisher: didrocks
description: |
Web interface detecting faces from webcam shots every few seconds
channels:
beta: 1.0 (52) 37MB devmode
edge: 2.0alpha1 (51) 37MB devmode
As this snap is not fully confined (see the devmode annotation), it is only available in the beta and edge channels (with different versions and revisions)
snap find
We have already seen that snap find <query> is looking for keywords in snap name and descriptions in the stable channel to display what you are looking for. But there is way more than this!
sections
snap find without any search key display some featured snaps:
$ snap find
Name Version Developer Notes Summary
docker 1.11.2-9 docker-inc - The docker app deployment mechanism
lxd 2.11 canonical - System container manager and API
mongo32 3.2.7 niemeyer - MongoDB document-oriented database
rocketchat-server 0.53.0 rocketchat - Group chat server for 100s, installed in seconds.
In fact, it shows the “featured” section of the snap store. You can easily look for other sections with the --section option:
$ snap find --section internet-of-things
Name Version Developer Notes Summary
openhab 2.0.0 canonical - openHAB smart home server
nextcloud 11.0.2snap2 nextcloud - Nextcloud Server
How to know what are the available sections? Using snap command tab completion is your best bet!
$ snap find --section [TAB][TAB]
database internet-of-things messaging
featured media ops
Private snaps
Developers can put their snaps in private mode. Those are usually snap applications in development which aren’t ready for wider consumption yet. Of course, to get access to yours, you need to be logged in with the snap login command.
$ snap find --private
The search "" returned 0 snaps
As you can see, this account doesn’t have any private snap (yet! ;))
snap list
snap list enables us to see the list of all installed snaps, as we have already practiced:
$ snap list
Name Version Rev Developer Notes
booth-demo-manager 1.0 17 didrocks devmode
chuck-norris-webserver 1.0.0 10 didrocks -
chuck-norris-webserver-classic 1.0.0 14 didrocks classic
core 16-2 1441 canonical -
hello 2.10 20 canonical -
nethack 3.4.2-2 2 ogra -
snappy-debug 0.30 28 canonical -
ubuntu-app-platform 1 34 canonical -
ubuntu-webapp 1.0 x2 try
We can see there the snap name, version, revision, publisher as well as the mode (devmode, classic, try…).
You will note that the ubuntu-webapp snap has a special revision (x2) and mode (try) without any publisher name. This is due to the fact it’s a locally developed snap for a local revision of a snap not published to the store yet. You will thus mainly see those combinations on snap developer machines.
However, this is a partial view of what’s really installed on your system. Remember that multiple revisions of a snap can be installed in parallel (and only one is enabled). You can have the list of all snaps and revisions installed on the system via the --all switch:
$ snap list --all
Name Version Rev Developer Notes
booth-demo-manager 1.0 17 didrocks devmode
chuck-norris-webserver 1.0.0 10 didrocks -
chuck-norris-webserver 1.0.0 8 didrocks disabled
chuck-norris-webserver 0.9.1 4 didrocks disabled
chuck-norris-webserver-classic 1.0.0 14 didrocks classic
core 16-2 1264 canonical disabled
core 16-2 1441 canonical -
core 16-2 1337 canonical disabled
hello 2.10 20 canonical -
nethack 3.4.2-2 2 ogra -
snappy-debug 0.30 28 canonical -
snappy-debug 0.29 27 canonical disabled
ubuntu-app-platform 1 34 canonical -
ubuntu-webapp 1.0 x2 try
ubuntu-webapp 1.0 x1 disabled,try
We can see here that some snaps have multiple revisions installed (sometimes, with the same user string version, sometimes with different ones). Only the active revision doesn’t have the “disabled” status note next to it.
Older version will be garbage collected after some time of inactivity or depending on the number of revisions of the same snap installed. Associated version data directories we previously discussed will be purged as well. However as long as the snap revision is available on the system, you can revert to it!
snap revert (–revision)
We already skimmed over the snap revert functionality in the basic snap usage. The revert command reverts the given snap to its state before its latest refresh. This will reactivate the previous snap revision, and will use the original data that were associated with that revision,
discarding any data changes that were done by the latest revision. As an exception, data which the snap explicitly chooses to share across revisions is not touched by the revert process.
But there is more than that! We can revert to a specific revision. In case you want to try it yourself and you have multiple versions of a snap, have a go!
I see that I have 3 versions of chuck-norris-webserver:
$ snap list --all
Name Version Rev Developer Notes
[…]
chuck-norris-webserver 1.0.0 10 didrocks -
chuck-norris-webserver 1.0.0 8 didrocks disabled
chuck-norris-webserver 0.9.1 4 didrocks disabled
A simple snap revert would revert to revision 8 (version 1.0.0). But let’s say I want to revert to revision 4, this is easy with the --revision option:
$ snap revert chuck-norris-webserver --revision 4
chuck-norris-webserver reverted to 0.9.1
$ snap list --all
Name Version Rev Developer Notes
[…]
chuck-norris-webserver 1.0.0 10 didrocks disabled
chuck-norris-webserver 1.0.0 8 didrocks disabled
chuck-norris-webserver 0.9.1 4 didrocks -
And here we go!
The additional benefit is that automated refreshes won’t refresh to revision 10 automatically. This one is blacklisted. So we will get:
$ snap refresh
All snaps up to date.
Of course, if a new version is released or any other snap, snap refresh will update the relevant snaps.
We can still force refreshing to latest chuck-norris-webserver no matter:
$ snap refresh chuck-norris-webserver
chuck-norris-webserver 1.0.0 from 'didrocks' refreshed
$ snap list --all
Name Version Rev Developer Notes
[…]
chuck-norris-webserver 1.0.0 10 didrocks -
chuck-norris-webserver 1.0.0 8 didrocks disabled
chuck-norris-webserver 0.9.1 4 didrocks disabled
And we are back to revision 10!
Phew! That was it for the latest tips and tricks that will make you an advanced snap user! Let’s recap quietly all this.
