My version of hygge is having friends come together for a dinner. When the dinner menu has just enough new flavors to make food interesting and just enough old favourites so that no one goes hungry. It’s about conversation that flows effortlessly, includes everyone, and makes us laugh. Most importantly, it’s about seeing my friends relaxed, cozy, and feeling at home – helping themselves to more food or a drink from the fridge and being happy in the moment.

Running unattented systemd user service

In the process of learning how to deploy a Django webapp using Microsoft’s TFS build + release tools, I came across the need to convert several systemd services that used to be started by root  user to systemd user services, so that they could be started and managed by a non-privileged user. Here is one of my original services that is used to run gunicorn (*** designates values that have been redacted):

I ran these steps to convert the original service to a user service:

To my surprise, that worked well and the service has started without complaints. However, I soon discovered two problems:

  1. The service no longer started automatically after server reboot
  2. The service only ran when I was SSHed into the server as the user who now managed the service

Turns out, the fix for both issue is relatively straight-forward, once you know what to do, which is the hard part. In order to fix the first problem, I ended up changing the service file:

It turns out that such thing as multi-user.target does not exist for systemd user services, but default.target does.

The second issue was a bit more interesting. Roughly speaking, systemd only runs user services when a user is logged in. When the user logs out, their services are promptly stopped. In order to overcome that, you need to indicate to the login manager that user needs to linger. On Ubuntu 16.04, the command to do so is:

After applying both changes and rebooting, my systemd user services where chugging along happily without the need for manual intervention.

False hope…

Due to a change in the number of years you have been claims free, we are pleased to advise your premium has been reduced…

Screenshot from 2016-02-17 17:49:17

Um… thanks? It’s likely that the insurance company simply has not thought this scenario through but given that just a few months ago I got adjusted up by $20-30 because reasons, this looks facetious.

Managing your DigitalOcean MySQL databases with MySQL Workbench

I am trying out the excellent DigitalOcean to host this blog along with a few other personal projects. This is my first time using a dedicated VPS for hosting and while it provides me with a great deal of control over my resources, one obvious down side is that I am also directly responsible for all system administration work. Instead of trying to install phpMyAdmin to administer my database or mocking with iptables, I’ve decided to use SSH tunneling and MySQL Workbench to do just that.

You can use the following command to tunnel the remote port 3306 of your VPS to the locally available port 8888:

If all worked well, you will be logged into your remote machine and, while keeping that terminal window open, you will be able to use MySQL Workbench to connect to in order to access your database. By the way, you don’t have to use  8888 for your local port, I use  3306 locally as well, in which case the command becomes: