Trying out Canonical LivePatch service

So, after a few months of being subscribed to the Ubuntu Security Mailing list and being emailed every time there’s a kernel vulnerability, I have decided to try out Canonical’s Live Patching service (free for personal use, up to three computers), based on the super simple tutorial by cyberciti.

So, first impressions were that it is in fact really easy to install. However, as soon as I tried to register my token, I hit a snag:

# canonical-livepatch enable a471d5444cbe4ccccccc1acccccccccc
2017/02/23 22:14:53 Error executing enable?auth-token=a471d5444cbe4ccccccc1acccccccccc.
Connection to the daemon failed: Put http://127.0.0.1/enable?auth-token=a471d5444cbe4ccccccc1acccccccccc: dial unix /var/snap/canonical-livepatch/17/livepatchd-priv.sock: connect: no such file or directory

After a bit of digging, I found that the service is installed as “snap.canonical-livepatch.canonical-livepatchd.service” and the logs can be seen with:

journalctl -f -u snap.canonical-livepatch.canonical-livepatchd.service

In the output is the error message “Only Ubuntu 16.04 LTS is supported”:

Feb 23 21:57:52 ip-10-0-0-78 systemd[1]: Started Service for snap application canonical-livepatch.canonical-livepatchd.
Feb 23 21:57:52 ip-10-0-0-78 /usr/bin/snap[3949]: cmd.go:111: DEBUG: restarting into "/snap/core/current/usr/bin/snap"
Feb 23 21:57:52 ip-10-0-0-78 snap[3949]: 2017/02/23 21:57:52 Only Ubuntu 16.04 LTS is supported, exiting.
Feb 23 21:57:52 ip-10-0-0-78 systemd[1]: snap.canonical-livepatch.canonical-livepatchd.service: Main process exited, code=exited, status=1/FAILURE

Which is weird, because the server is running 16.04.02:

root@ip-10-0-0-78:~# cat /etc/issue
Ubuntu 16.04.2 LTS

root@ip-10-0-0-78:~# lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 16.04.2 LTS
Release:	16.04
Codename:	xenial

root@ip-10-0-0-78:~# uname -a
Linux ip-10-0-0-78 4.4.0-64-generic #85-Ubuntu SMP Mon Feb 20 11:50:30 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

I’m not sure whether this is intended (maybe kernel changes between minor versions are not supported?) or someone wrote an “exact match” regex when doing the version check.

Have asked on the community forums about it.

Getting Firefox Sync server running

Have been setting up Firefox Sync, following the instructions found at: https://docs.services.mozilla.com/howtos/run-sync-1.5.html

The instructions were pretty straight-forward, got it up and running in no time (even ran the tests to ensure everything was passing).

However, after reconfiguring the browser to point to the new Sync URL, nothing happened. (In the end it turned out I forgot the “/token/” part of the URL: https://bugzilla.mozilla.org/show_bug.cgi?id=1032039)

Debugging Tips:

* By default if you run the server using “local/bin/pserve syncserver.ini” the server logs to console.

* The database the server saves to (by default) is “syncserver/syncserver.db”, which you can view using SQLite Browser.

* To manually start a Sync, you can go to “Tools” -> “Sync Now”

* To view the browser (client) sync logs, enter “about:sync-log” in the URL bar. You can turn on logging on successful sync by toggling the “services.sync.log.appender.file.logOnSuccess” configuration variable.

* At time of writing there’s a bug where the URL can be set back to the default in some instances: https://bugzilla.mozilla.org/show_bug.cgi?id=1003708

* You can modify the “services.sync.syncInterval” variable to make the browser attempt to sync more frequently (value is in milliseconds).

Getting Risk of Rain working

I bought the Humble Indie Bundle 13 and downloaded Risk of Rain (non-Steam version). Tried firing it up, when it wouldn’t run, giving error:

“error while loading shared libraries: libopenal.so.1”

Found that it required a bunch of 32-bit packages, namely:

* libopenal1:i386
* libxrandr2:i386
* libglu1-mesa:i386

 which you had to install with “sudo apt-get install [package name]”

NOTE: To get “Shadowrun Returns” working, also had to install the “libxcursor1:i386” package.

NOTE2: Am running Ubuntu 14.04LTS 64-bit

Configuring boot services

One of the common tasks when setting up a server is to configure whether a service is set to start up on boot or not. This is handled differently on different versions of Linux.

To list all services and whether they’re set to run on boot:

RHEL/CentOS/Fedora

chkconfig –list

Debian/Ubuntu

rcconf

NOTE: this program doesn’t come installed by default

Enable a service to run on boot:

RHEL/CentOS/Fedora

chkconfig [service name] on

Debian/Ubuntu

update-rc.d [service name] enable

Disable a service from running on boot

RHEL/CentOS/Fedora

chkconfig [service name] off

Debian/Ubuntu

update-rc.d [service name] disable

Ubuntu – The following packages have been kept back

If you’ve used Ubuntu for long enough, you’ll find that eventually you’ll run into a problem when upgrading the installed packages. When running apt-get from the command line, the problem manifests itself as the following:

$ sudo apt-get upgrade
[sudo] password for srdan:
Reading package lists… Done
Building dependency tree      
Reading state information… Done
The following packages have been kept back:
  linux-headers-server linux-image-server linux-server
0 upgraded, 0 newly installed, 0 to remove and 3 not upgrade

The short answer is that you should be able to upgrade by running the “apt-get dist-upgrade” command:

$ sudo apt-get dist-upgrade
Reading package lists… Done
Building dependency tree      
Reading state information… Done
Calculating upgrade… Done
The following NEW packages will be installed:
  linux-headers-3.2.0-27 linux-headers-3.2.0-27-generic linux-image-3.2.0-27-generic
The following packages will be upgraded:
  linux-headers-server linux-image-server linux-server
3 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 51.2 MB of archives.
After this operation, 217 MB of additional disk space will be used.
Do you want to continue [Y/n]?

The long answer comes from the man page of the “apt-get” command. In particular, if you look at the description of the “upgrade” argument, two sentences stick out:

“under no circumstances are currently installed packages removed, or packages not already installed retrieved and installed.”

“New versions of currently installed packages that cannot be upgraded without changing the install status of another package will be left at their current version.”

Because you can’t upgrade the “linux-image-server” (a.k.a. the kernel) without upgrading the headers as well (technically you can, but it can lead to serious problems) it won’t let you upgrade them using the “upgrade” command. Either that, or the “new” linux image package requires that a “new” linux headers package be installed, violating the requirement that packages not already installed not be installed.

The reason that the “dis-upgrade” command works, where the “upgrade” command does not is that “dist-upgrade” takes into account dependencies between packages. Also from the man page:

“dist-upgrade … intelligently handles changing dependencies with new versions of packages; apt-get has a ‘smart’ conflict resolution system, and it will attempt to upgrade the most important packages at the expense of less important ones if necessary.”

This does beg the question though as to why not just use “dist-upgrade” all the time or incorporate the conflict resolution system into the “upgrade” command?

I suspect the answer has something to do with how each “edition” of a distribution is defined. i.e. Ubuntu 12.04 will ship with version 3.1.13 of the “at” package and all other packages that are a part of this “edition” should work with that version. Having many different packages depend on specific versions of other packages could end up in a situation where it becomes very difficult to upgrade any individual package.