Skip to main content

Ian Vellosa

Thanks to @ollispieps and @jugch for organising a great hands-on #ContinuousDelivery workshop and @cssversicherung for sponsoring

2 min read

The Java user group of Switzerland organised a continuous delivery workshop last night, which was run by Oliver Nautsch, with a really nice structure. Oliver has documented the process, with slides in GitHub, so if anyone missed the session, you can run through the exercises in your own time.

Before the session we were given instructions describing what we would need to install on our laptops ahead of time. This basically involved cloning a github repository and then using vagrant to start up a Linux virtual machine.


Within the Virtual machine was everything needed for the session, including the whole continuous delivery stack, and an example project which would be used for the hands on exercises.

Instructions for the workshop can again be found in github but the general gist was to:

  • Setup our infrastructure (code and artefact repositories, build server, deployment environment) using docker
  • Upload the application code to a central (gogs) git repository
  • Use Jenkins as a CI server to build the application code, with Gradle scripts.
  • Start setting up the whole continuous delivery pipeline in Jenkins pushing the tested application to our various environments.

Between the exercises there were discussions on continuous integration vs continuous delivery vs continuous deployment. We spoke about why you would want to do any of these things, and covered some best practices. However, in a three hour session it difficult to get into any real depth, and I feel that Oliver did a great job.

One really nice surprise was the quality of refreshments provided by CSS who also provided the facilities, so a big thanks to them for sponsoring the evening.

Ian Vellosa

Using Google Authenticator to protect sudo on Raspberry Pi

5 min read

For a long time, I've been thinking that it would be nice to play around with two factor authentication (2FA) for the root account on my Raspberry Pi's. This week I've finally got around to doing it, and as with so many tasks on the Pi, once you get going it's pretty straight forward, with the google authenticator. 

The steps that I want to follow would be:

  • Create a standard user account, from which the sudo commands will be issued.
  • Block ssh access to the root user
  • Enable Google authenticator for sudo commands

Setting up sudo access

If you have not already created personal accounts on your box, run the adduser command:

adduser -u 1001 <user>

We will also need to make sure that the sudo command has been installed. Therefore, as root we will run the commands:

apt-get update

apt-get install sudo

Leaving the current terminal window running (we want to have one session logged in as root on the Pi until we are certain that everything is running properly) start a new terminal window and log in to the Pi as your personal user, then try out the sudo command:

ssh <user>@pi

sudo su -

This will initially as you for your personal password, after which it will fail with a message that looks something like:

<user> is not in the sudoers file. This incident will be reported.

Next edit the /etc/group file, finding the line starting sudo, and add your user id:




If there is more than one user id in the group, then they should be separated by commas.

Now if you attempt to run the sudo command again, you should be asked for your personal (not root) password, which when entered will give you root access to the box.

Removing root ssh access

Now that we are able to log onto the box with our personal account, and run the sudo command, we should block the root user from being able to ssh onto the box too. This is done simply by editing the file /etc/ssh/sshd_config, and changing the authentication section, which has a value PermitRootLogin which should be changed from yes, to no:

# Authentication:

LoginGraceTime 120

PermitRootLogin no

StrictModes yes

While we are modifying the sshd_config file, we will also ensure that the ChallengeResponseAuthentication flag is set to yes (default was no)

# Change to yes to enable challenge-response passwords (beware issues with

# some PAM modules and threads)

ChallengeResponseAuthentication yes

You will then need to restart the ssh service for this to take effect:

service ssh restart

Now if you try ssh'ing over to the box as root, you will find that Permission is denied, as if you have entered an incorrect password. However, you should be able to log in as your personal account still.

Adding Google Authenticator 2FA

Firstly, make sure that you have google authenticator (or compatable tool) installed on your phone.

Now we are going to install the application code on the Raspberry Pi, again this is done via apt-get:

apt-get install libpam-google-authenticator

Once the installation has completed, we are going to create a time based token which will be used for authentication, for this we run the command:

google-authenticator --secret=/root/<user>.google_authenticator

This will place the key to the time based 2FA key in the root users home directory. By default, if you do not specify the location for the secret it will be placed in a .google_authenticator file in the users home directory, which the user has full access to. I didn't want to do this, as once you have access to the user account, having the secret to 2FA readable does not add anything from the security stand point.

There are a number of questions asked of you when generating the authentication key, you can simply answer yes to all of these.

There are two ways you can setup the key in your phone, pressing the big plus symbol at the bottom of the screen starts this process. The first option would be to just scan the 3D barcode which is produced as part of the generation script. The second is to enter your new secret key via the keyboard. After doing this you should see a 6 digit number on your phone which changes every 30 seconds.

Finally, at the end of the files:

  • /etc/pam.d/su
  • /etc/pam.d/sudo

Add in the line:

auth required user=root secret=/root/${USER}.google_authenticator

Now if you start a new session, logging into your pi as your personal user and run the sudo command, you should be asked first for your password, and then once this is successful you will be asked for the verification code from your authenticator app on the phone.


While putting together this guide, there were a couple of sources that helped:

  • How-To Geek had a nice write up of the basics, and
  • archlinux Wiki has a nice page describing the parameters that can be used when generating the key, and configuring the pam.

Ian Vellosa

Philips Hue motion sensor: I like it, but not for the living room (yet?) @tweethue

2 min read

Over the past few months I've been changing out the light in our apartment for some of the plain white Philips Hue lamps. On the whole I've been pretty impressed. Using apps like Yonomi I was able to set up a kids bedtime routine, where with the click of a single button, the main lamp in the kids room turns off, the side lamp dims to 1% and the Sonos starts playing lullabies at 15% volume.

When the Philips Hue motion sensor came out, I thought that this had great promise for the living room. With the two modes (night and day time) it can be set so that during the day when the light level is low, the lights come on when motion is detected. At night if motion is detected, then the lights come on dimmed, so that your not startled on the way to the bathroom. It all sounded great.

I'm also using the Harmony remote to control the lights. (After sunset) when watching the TV the lights dim to 85%, or when watching a film they dim to 65%. When the TV turns off the lights come up again. However, while the lights are dimmed, and the motion sensor sensor picks up movement, it turns the lights back to full brightness. Not quite the result I was looking for.

On the whole I do still like the motion sensor idea. We are having some issues remembering _not_ to turn the lights off when leaving the room, and relying on the motion sensor to do this.

Ian Vellosa

#Chromecast get a wired connection, and I love it!

2 min read

Since the Google Chromecast was first introduced I've loved the device. It just feels like the fight way to control the TV, you use the rich interface on your phone to find what you want to watch and then with the press of a button it's on your TV. Having only played briefly with Apple TV, and it's silly little remote control, Chromecast just feels right.

There were some issues with the original Chromecast where streaming would occasionally buffer. With Netflix it was fine, but Plex did have quite a few issues, even with the WiFi access point in the same room. Ensuring that the WiFi connection to the Chromecast was not encrypted by Plex did help (as the Chromecast only has limited processing power), but there were still issues.

Rumour had it that the second version of Chromecast had better WiFi connectivity, so I upgraded, but unfortunately it didn't really help.

When the latest, Chromecast Ultra came out, again I started to look into the connectivity again. This time I saw that there is the option of a wired connection, using a specialised power adapter. Even better still, this is backwards compatible with the prior Chromecasts. As soon as I saw this I ordered one up, and last night it was installed.


So far I've been impressed. Installation was simple, just plug in and go. After that I was able to immediately able to start casting.  

Ian Vellosa

Why can't my @QNAP_nas play nicely with @CrashPlan?

1 min read

I should start this off by saying I love both my QNAP NAS and the online backup service provided by CrashPlan. When I found that there were packages that could be installed on the NAS which would automatically backup to the cloud it seemed like the perfect solution. At home I make sure all photos get copied to the NAS, then the CrashPlan process does it's magic and makes sure that they are all backedup.


Another really nice feature is there are periodic email reports with the current state of your backups, i.e.:


CrashPlan backup report

As you can see, there is a small issue with the backup (for the past 3 months!) This appears to happen often when the QNAP software gets updated. I tried removing and reinstalling the package, without success.


Finally, I resorted to the google searching and found a post on the QNAP forums, where dynek has patched the latest version of Java. This is worked for me, and everything is back as expected. 


Why is it that we need to rely on users to patch the JDK? Why can't QNAP fix these issues?