Basic management of an Ubuntu Core installation

Part 1: Setting up an “All-Snap” Ubuntu Core image in a QEMU/KVM virtual machine
Part 2: Basic management of an Ubuntu Core installation
Part 3: Mir and graphics on Ubuntu Core
Part 4: Unity8 on Mir on Ubuntu Core
Part 5: Confinement

After I’ve set up an “All-Snap” Ubuntu Core virtual machine in the last post, let’s see what I can do with it.

Logging in

After logging in, the VM greets me with the following message:

$ ssh -p 8022 sturmflut@localhost
Welcome to Ubuntu Core 16 (GNU/Linux 4.4.0-53-generic x86_64) 
 
 * Documentation:  https://help.ubuntu.com 
 * Management:     https://landscape.canonical.com 
 * Support:        https://ubuntu.com/advantage 
 
The programs included with the Ubuntu system are free software; 
the exact distribution terms for each program are described in the 
individual files in /usr/share/doc/*/copyright. 
 
Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by 
applicable law. 
 
Welcome to Snappy Ubuntu Core, a transactionally updated Ubuntu. 
 
 * See https://ubuntu.com/snappy 
 
It's a brave new world here in Snappy Ubuntu Core! This machine 
does not use apt-get or deb packages. Please see 'snap --help' 
for app installation and transactional updates. 
 
sturmflut@localhost:~$

Hm, so there’s no apt-get and no deb packages? Really?

$ sudo apt-get update 
Ubuntu Core does not use apt-get, see 'snap --help'!

Ouch, that’s a clear message! Guess I’ll have to learn how to use Snappy.

Getting started

The first thing I want to do after logging in is to update the VM, the image was created in November 2016, so there’s probably a lot of outdated stuff. Ubuntu Core is transactionally updated, it cannot break, right? Let’s see what’s installed so I know what to update.

$ snap list 
Name       Version     Rev  Developer  Notes 
core       16.04.1     888  canonical  - 
pc         16.04-0.8   9    canonical  - 
pc-kernel  4.4.0-53-1  45   canonical  -

Just three packages! core is the base Ubuntu userspace with all the things common to all Ubuntu Core installs. pc-kernel is probably the generic AMD64 operating system kernel, but what’s pc?

$ snap info pc 
name:      pc 
summary:   "AMD64 generic package" 
publisher: canonical 
description: | 
  This package contains a simple OEM snappy package for system configuration 
   
type:        gadget 
tracking:    stable 
installed:   16.04-0.8 (9) 856kB - 
refreshed:   2016-09-01 09:27:22 +0000 UTC 
channels:                    
  stable:    16.04-0.8 (9)  856kB - 
  candidate: 16.04-0.8 (9)  856kB - 
  beta:      16.04-0.8 (9)  856kB - 
  edge:      16.04-0.8 (19) 856kB -

That was absolutely not helpful. Let’s look which files this package actually contains.

Snap packages and mounts

A Snap package is immutable, which means all the files it ships can not be changed. If a Snap wants to store data on the system, it can usually only do so in some additional, restricted paths pertaining to the Snap itself. Exceptions can be made for Snaps which have to access data in other places of the file system, but in general you try to limit things as much as possible. It’s called “Confinement” and it’s a basic feature of Ubuntu Core.

The solution to how to ship an immutable package is quite simple: a Snap package is a read-only, compressed SquashFS file system put into a single file. It’s not necessary to extract this file, you can simply mount it read-only to some place in your root file system tree, and that’s exactly what happens:

$ losetup 
NAME       SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE 
/dev/loop0         0      0         0  0 /writable/system-data/var/lib/snapd/snaps/core_888.snap 
/dev/loop1         0      0         1  0 /writable/system-data/var/lib/snapd/snaps/pc-kernel_45.snap 
/dev/loop2         0      0         1  0 /var/lib/snapd/snaps/pc_9.snap 
/dev/loop3         0      0         1  0 /var/lib/snapd/snaps/core_888.snap 
/dev/loop5         0      0         1  0 /var/lib/snapd/snaps/pc-kernel_45.snap

A-ha! All the installed Snaps have been bound to loopback devices. Let’s see where our pc Snap has been mounted to:

$ df -h /dev/loop2 
Filesystem      Size  Used Avail Use% Mounted on 
/dev/loop2      896K  896K     0 100% /snap/pc/9

Well, we could have guessed that. Every Snap is mounted to /snap/${PACKAGE}/${VERSION} (because multiple versions of a Snap can exist side-by-side), and /snap/${PACKAGE}/current points to the currently active snap. Now what’s inside the pc snap?

$ find /snap/pc/9 
/snap/pc/9
/snap/pc/9/grub.cfg
/snap/pc/9/grub.conf
/snap/pc/9/grubx64.efi
/snap/pc/9/meta
/snap/pc/9/meta/gadget.yaml
/snap/pc/9/meta/icon.png
/snap/pc/9/meta/snap.yaml
/snap/pc/9/notes.txt
/snap/pc/9/pc-boot.img
/snap/pc/9/pc-core.img
/snap/pc/9/shim.efi.signed

Looks like all the files necessary to enable system boot using the GRUB bootloader. It will be interesting to see how all of this fits together in the end. But on to updating and installing packages.

Updating the system

Now let’s finally try to update all our packages from the store.

sturmflut@localhost:~$ snap refresh 
[|] Setup snap "core" (1264) security profiles 
Broadcast message from root@localhost.localdomain (Tue 2017-02-21 18:38:42 UTC): 
 
reboot scheduled to update the system - temporarily cancel with 'sudo shutdown -c' 
The system is going down for reboot at Tue 2017-02-21 18:48:42 UTC! 
 
core 16-2 from 'canonical' refreshed

Okay, it updated the core Snap to version 1264 – and scheduled an automatic reboot ten minutes later. I’m not sure if I like that. While playing around I’ve actually run into a situation where snap refresh had to update a long list of packages, core was the first one and the reboot was scheduled immediately, but all the other packages still had to be updated and the Nextcloud Snap took a long time working on its database. Now this was in a (comparably) fast emulator, but imagine it happening on a slow ARM device. Ubuntu Core is transactional, but only in regard to the contents of the Snap packages, not in regards to the data those Snaps produce after installation. Would the Nextcloud database upgrade have been interrupted by the reboot, there would have been a probability of data corruption.

Often there won’t be anything to update though, even if you know there must be something new:

$ snap refresh
All snaps up to date.

Turns out the snapd daemon running in the background and doing all the work gets triggered  by a systemd timer every six hours to update all installed snaps.

$ cat /etc/systemd/system/timers.target.wants/snapd.refresh.timer                           
[Unit] 
Description=Timer to automatically refresh installed snaps 
 
[Timer] 
# spread the requests gently 
# https://bugs.launchpad.net/snappy/+bug/1537793 
OnCalendar=23,05,11,17:00 
RandomizedDelaySec=6h 
AccuracySec=10min 
Persistent=true 
OnStartupSec=15m 
 
[Install] 
WantedBy=timers.target

Notice the configuration introducing a randomized delay of six hours (see the referenced Launchpad bug 1537793), so not all Ubuntu Core instances decide to update at the same time and overload the store.

Installing Snaps

Now let’s install something I can actually use on a shell, since I haven’t gotten any proper graphics yet. snap has a find command to search for snaps.

$ snap find 
Name               Version   Developer   Notes  Summary 
docker             1.11.2-9  docker-inc  -      The docker app deployment mechanism 
lxd                2.8       canonical   -      LXD - the container lightervisor 
mongo32            3.2.7     niemeyer    -      MongoDB document-oriented database 
rocketchat-server  0.51.0    rocketchat  -      Group chat server for 100s,  installed in seconds.

Hmmm, it probably lists the most popular ones, but I don’t wany any of those. snap find game lists more interesting things, but a lot of those look like they need a graphics subsystem, and many need an X11 server, which doesn’t seem to exist on Ubuntu Core at all (it is built to use Mir). Many only work in a “classic” Ubuntu system (there’s a difference between using Snaps on “classic” Ubuntu and running it on Ubuntu Core). I found a game which runs on the command line:

$ snap install moon-buggy 
moon-buggy 1.0.51.11 from 'dholbach' installed

$ moon-buggy

Yay, happy playing!

Installing snapweb

I am going to install the web-based snapweb interface to make package management easier.

$ snap install snapweb
snapweb 0.21.2 from 'canonical' installed

snapweb runs on ports 4200 and 4021, which I haven’t forwarded from QEMU yet. So I have to reboot the virtual machine and extend the QEMU command line:

-netdev user,id=mynet0,hostfwd=tcp::8022-:22,hostfwd=tcp::8090-:80,hostfwd=tcp::8040-:4200,hostfwd=tcp::8041-:4201

After the virtual machine is back up again, I can now access https://localhost:8041/ using a browser. It is necessary to add a security exception because snapweb uses a self-signed certificate, then the following appears:

snapweb doesn’t allow access to just anybody, you have to prove you’re authorized to manage packages on this device. The necessary token can be generated on the command line:

$ sudo snapweb.generate-token
Snapweb Access Token:

## $TOKEN displayed here ##

Use the above token in the Snapweb interface to be granted access.

Once the token is submitted, snapweb switches to the list of installed Snaps.

Since there is no “official” web interface for the store and snap find is a bit of a pain, snapweb jumps into the gap and lets you browse for and install packages from the store.

If you want an even more comfortable way to browse for new Snaps, use uAppExplorer.

Now how about installing something actually useful now, like Nextcloud?

Installing Nextcloud

Installation is as easy as clicking on the “Install” button in snapweb, or one line in the shell:

$ snap install nextcloud
nextcloud 11.0.1snap3 from 'nextcloud' installed

The Nextcould Snap ships a full Nextcloud installation including an Apache HTTP server, a mySQL instance, PHP7, Redis, mDNS and several nextcloud services. The process list is not the shortest:

$ ps ax | grep nextcloud
 3621 ?        Ss     0:00 /bin/sh /snap/nextcloud/862/bin/delay-on-failure mdns-publisher nextcloud
 3647 ?        Sl     0:00 mdns-publisher nextcloud
 3670 ?        Ss     0:00 /bin/sh /snap/nextcloud/862/bin/run-httpd -k start -DFOREGROUND
 3719 ?        Ss     0:00 /bin/sh /snap/nextcloud/862/bin/start_mysql
 3764 ?        Ss     0:00 /bin/sh /snap/nextcloud/862/bin/start-redis-server
 3813 ?        Ss     0:00 /bin/sh /snap/nextcloud/862/bin/start-php-fpm
 3870 ?        Ss     0:00 /bin/sh /snap/nextcloud/862/bin/renew-certs
 3917 ?        Ss     0:00 /bin/sh /snap/nextcloud/862/bin/nextcloud-cron
 4236 ?        S      0:00 /bin/sh /snap/nextcloud/862/bin/mysqld_safe --datadir=/var/snap/nextcloud/862/mysql --pid-file=/var/snap/nextcloud/862/mysql/localhost.localdomain.pid --lc-messages-dir=/snap/nextcloud/862/share --socket=/var/snap/nextcloud/862/mysql/mysql.sock
 4406 ?        Sl     0:00 /snap/nextcloud/862/bin/mysqld --basedir=/snap/nextcloud/862 --datadir=/var/snap/nextcloud/862/mysql --plugin-dir=/snap/nextcloud/862/lib/plugin --lc-messages-dir=/snap/nextcloud/862/share --log-error=/var/snap/nextcloud/862/mysql/localhost.localdomain.err --pid-file=/var/snap/nextcloud/862/mysql/localhost.localdomain.pid --socket=/var/snap/nextcloud/862/mysql/mysql.sock
 4441 ?        Ss     0:00 php-fpm: master process (/snap/nextcloud/862/config/php/php-fpm.conf)
 4455 ?        S      0:00 /bin/sh /snap/nextcloud/862/bin/httpd-wrapper -k start -DFOREGROUND
 4457 ?        S      0:00 httpd -d /snap/nextcloud/862 -k start -DFOREGROUND
 4458 ?        Sl     0:00 httpd -d /snap/nextcloud/862 -k start -DFOREGROUND
 4459 ?        Sl     0:00 httpd -d /snap/nextcloud/862 -k start -DFOREGROUND
 4460 ?        Sl     0:00 httpd -d /snap/nextcloud/862 -k start -DFOREGROUND

As you can see all services have been configured to use paths, files and sockets within the scope of the Snap itself, so this Nextcloud installation doesn’t need to touch any “outside” data and stays confined. This is nice, since the whole package has been made to work “as is” without requiring the user to e.g. manually connect Nextcloud to a database server. On the other hand it’s a waste of resources in case you already have a mySQL server or a web server, but that’s not what this package was built for.

The bigger problem I see is that the included Apache server just goes and grabs port 80, which might already be in use. snapd would have a solution for this, but the nextcloud snap doesn’t seem to support it (yet):

$ snap set nextcloud apache_port=81

If there are no problems with binding to already assigned ports or something like that, and in my case there aren’t, nextcloud just works as expected. The QEMU command line I’ve given forwards port 80 to host port 8090, so the URL is http://localhost:8090. The default login is user admin with password nextcloud.

The Snap does not only ship the preconfigured servers and the Nextcloud files, but also some utilities, e.g. to automatically enable HTTPS using a certificate issued by Let’s Encrypt.

$ sudo nextcloud.enable-https lets-encrypt

In order for Let's Encrypt to verify that you actually own the
domain(s) for which you're requesting a certificate, there are a
number of requirements of which you need to be aware:
(..)

Because of confinement, this Nextcloud package does not have access to removable media by default. If you want it to, you have to “connect the right interfaces” first.

$ snap connect nextcloud:removable-media :removable-media

I’m going to look at interfaces in the next post, I’m going to need them quite a lot when I set up Mir and applications with graphical user interfaces.