WordPress on a VPS.. Ugh.

As part of my dumb journey to self-host things (well, on a VPS I pay for), I fired up Apache and chucked a virtual host on it. The plan will be to move all my hosted sites to this server, but for now I’m starting with a fresh WordPress install for a family member’s B&B website.

In the mix we have:

  • Apache2
  • Ubuntu 14.04 LTS 64bit
  • php5
  • MySQL
  • phpmyadmin
  • WordPress latest
  • Sweat coming out of my face

So the basic LAMP install was done without a hitch. Where WordPress started to suck was permissions. By default, somehow, I installed WordPress with the permissions set really way wide open (777 on directories).. I used some commands in the WordPress codex (inside my /var/www/sitename/public_html folder)..

james@chappie:~$ sudo find . -type f -exec chmod 664 {} +
james@chappie:~$ sudo find . -type d -exec chmod 775 {} +
james@chappie:~$ chmod 400 wp-config.php

So, there’s that. Then I found a user couldn’t upload a theme or plugin, because for some reason (despite www-data, the Ubuntu Apache user, having group rights to the files..) WordPress couldn’t write to wp-content/, the folder these things go in by default.

If I ran ‘su www-data touch check’ inside wp-content, the file “check” was created, so it wasn’t a permissions issue as far as I could tell. Weird. I ended up fixing it by explicitly telling WordPress to allow ‘direct’ uploading by adding:

define(‘FS_METHOD’, ‘direct’);

To the wp-config.php file.. All of a sudden.. It works.

I had read elsewhere (a 3 year old mysteriously written comment on WordPress’ own community site) that changing PHP’s config to use FastCGI/php-fpm was the solution.. I am still (and probably always will be) a noob with these web technologies, so I wasn’t really 100% sure what I was doing. I also failed, lucky ‘FS_METHOD’ being set to direct was what I wanted.


I found that changing the ‘server api’ of PHP5 to FPM/FastCGI (and removing the aformentioned FS_METHOD) also works. I followed the steps listed here (JDawg’s answer): http://askubuntu.com/a/527227/521633

Running your own VPS kind of sucks

I pay a good chunk of change to Dreamhost every year, I have done since I was old enough to have a credit card. It’s handy. They are a pretty chill hosting provider, by and large. I host about 8 or 9 WordPress sites. Some are mine, some for friends. As I get better at unix’y stuff, I’m becoming more of a cheapskate and am thinking that $140NZ or whatever Dreamhost costs per year is a bit steep for a shared hosting platform. I have trialled their more dedicated VPS offering and while it kills performance-wise, it’s too expensive for someone hosting sites on behalf of others for free…

A while back I got a good deal on Zappie Host, based in New Zealand, where most of my ‘clients’ are also based. It’s a dedicated VPS, 2 CPU cores and a gig of RAM for about $7NZ a month. I am also on a 50% off deal for the first year, so it’s a good deal. I’m paying for it in parallel with DH so I can get my shit together and migrate. Part of the motivation for sorting it all out before my next DH payment is due is financial, as I’m paying for 2 hosting solutions and not getting much benefit from the combination.

Some challenges:

  • Picking a web server (Apache or NGINX?!)
  • Picking a database (MariaDB or MySQL!?)
  • To use a cPanel or not?
  • Security
  • Mail (jeesus christ, email is complex!)
  • Virtualisation/separation of different client sites
  • Backups!?
  • Remote access for users
  • Unknown unknowns
  • DNS
  • Goddamn email
  • Resource monitoring

I think I need a coffee. What I want to do is use this list and knock out some posts detailing the crap you need to put up with to save a few bucks and call yourself a server administrator 🙂

Time for you and time for me,
And time yet for a hundred indecisions,
And for a hundred visions and revisions,
Before the taking of a toast and tea.

– T.S. Eliot (lol)

Firing up NetBox

Over at Packet Life, stretch has been talking about his/Digital Ocean’s cool new IPAM/DCIM. It’s open source, being developed like crazy and has some interesting features (for me, the ability to document my lab setup which is getting out of hand seems like a good place to start).

I ran through the installer on Github and squirted the install onto a fresh Ubuntu 14.04 LTS server on AWS. Here are my thoughts…

  • The install instructions were very well written for a fresh OSS product, pretty much nothing failed the first time through. This is reminiscent of other Digital Ocean documentation I have read. I did need to jump out of editing a config file to generate a key, but that’s minor.
  • From an absolute beginner with Linux pov (not quite the boat I’m in, but a boat I was fairly recently in) – there are a few things missing (like when to sudo/be root or not per command). It’s not a noobs setup guide, but it is pretty easy to follow otherwise.
  • The installation/setup takes around 10-15 mins including generating the AWS EC2 host
  • The interface of NetBox looks lovely and clean

That was pretty easy and quite smooth to install. Now it’s up and running I can’t wait to document my lab and post the results up here.


Owncloud 9.0.1 on Raspberry Pi 3 – Step by Step


I bought a Raspberry Pi 3 on the day it was announced, because I am easily excitable. When it arrived, I tried out a few things like compiling Synergy (much faster than a RPI2!) and the oblig. Quake 3. Once the fun wore off, I thought this might be a good time to finally sort out my cloud storage issues. The issues are as follows:

1) I am mildly concerned about having my data live on someone else’s computer
2) I really like and rely on Dropbox, but my 8GB isn’t enough anymore
3) I am a cheapskate

The solution for this is to self-host a ‘cloud’ storage system. While that’s a bit of a paradox, having a system (with apps!) that can have my files on me wherever I go and upload pictures I take on my phone automatically is too handy to give up – and too risky to have no real control over. The best open-source (free, see point 3 above) solution I’ve found so far is OwnCloud.

Note: If you want to do an OwnCloud install following this post – it doesn’t need to be on a Raspberry Pi 3 – you can do it on pretty much any Debian/Ubuntu server. One day I will move this whole thing to a proper server, but again, see point 3.

Note 2: There are hundreds/thousands/millions of ways to do this task. I am basing this whole thing on Dave Young’s very well written howto on Element14. In fact, you can probably follow that right now and skip my post – I am writing this down for my own benefit and there are a *few* changes in OwnCloud 9.0.1

OK, so what do you need to get this up and running?

  1. A Raspberry Pi 3 Model B – buy one here 
  2. A MicroSD card (Class 10 is speedy, you can get a 200GB one for $80USD at the moment, which is NUTS).
  3. The .img file for Raspbian OS. I suggest using Raspbian Jesse Lite
  4. An internet connection. Any one will do, but a decent 30/10Mbit/s is probably recommended.
  5. A static IP and a domain name (or a dynamic DNS service such as the one offered at system-ns.net)
  6. A keyboard and an HDMI capable monitor or screen. This is just for setting up the Pi
  7. Some basic Unix shell skills.. Although you can just follow along and hopefully I’ll spell everything out
  8. A router/firewall in your house that you can forward ports on

Optional extras:

  1. An external USB HDD (for more space)
  2. A smartphone, for the OwnCloud App

If you have the 8 things above (we’ll cover step 4 in some detail later) – then we’re good to start.

Steps to success

Section 1 – Setting up the Raspberry Pi 3

This section you can skip if you already have a freshly installed Raspberry Pi 3 running Raspbian.

  1. First up, install Raspbian OS on the SD card. Steps to do this for your main PC OS are here.
  2. When you have booted into your newly installed Pi, log in with username pi and password raspberry. You’ll change this soon. I suggest you do this bit with the Pi plugged into a TV or screen, with a keyboard. We’ll SSH in and control the Pi from another machine later on.
  3. Run the raspi-config tool – you can set your hostname, expand the file system (use all of your SD card, not just a couple of GB)

    pi@rasbian:~ $ sudo raspi-config

    rpi-confIn there, I suggest you run Option 1 and 2. Inside Option 9, I set the Memory Split to 4MB (this is mostly a headless install, why waste RAM on a GPU that won’t get much use), and enable SSH. I changed the hostname to ‘cloud’, pick a name you like. Finish up, then reboot the Pi

    pi@cloud:~ $ sudo reboot
  4. Find your IP address. I am using the Ethernet interface (physically plugged into a switch), but you could use WiFi if you wanted (Raspberry Pi 3 has in-built WiFi, google will show you how to set it up!)

    pi@cloud:~ $ ip addr | grep eth0 | grep inet
       inet brd scope global eth0

    Here is a command to show the IP DHCP has given you (Raspbian uses DHCP by default). I could set this manually by editing /etc/network/interfaces and changing eth0 inet DHCP to inet static, but I won’t be doing that. I’ll be assigning a static DHCP lease in my router config to keep my Pi on for good. ANYWAY – my IP is found, so I can SSH in from my main computer and live an easier life.

  5. Log in to your Pi from a terminal. iTerm2 for OSX, Putty for Windows, uhh, Terminal from *nix. I use password-less entry as a security feature and because I’m lazy – if you want a hand setting that up let me know – otherwise, you’re in and can run the following commands:

    pi@cloud:~ $ sudo usermod -a -G www-data www-data
  6. pi@cloud:~ $ sudo apt-get install nginx openssl php5-cli php5-sqlite php5-gd php5-common php5-cgi sqlite3 php-pear php-apc php5-curl libapr1 libtool curl libcurl4-openssl-dev php-xml-parser php5 php5-dev php5-gd php5-fpm memcached php5-memcache varnish php5-apcu git
  7. That chunky block will install some key pieces of software for us
    1. NGINX – the web server we’ll be using
    2. PHP5 – PHP, bane of all existence
    3. Lots of PHP bits and pieces, PHP5-apuc is the memory cache we’ll use, for example
    4. git – to allow us to grab a nice SSL certificate from Let’s Encrypt

Section 2 – Configuring and installing other bits

  1. Let’s get an SSL cert, so browsing to our Cloud will show a nice green lock in browser, and the OwnCloud app won’t complain *too much*. Of course, this also helps to keep the contents of the cloud machine nice and secure. I use Let’s Encrypt for free signed certificates – something you couldn’t even dream of 5 years ago. As there isn’t a packaged Let’s Encrypt installer for ARM7 Debian at the moment, we’ll use git to grab one:

    git clone https://github.com/letsencrypt/letsencrypt
    cd letsencrypt
    ./letsencrypt-auto --help

    This will grab Let’s Encrypt (the software) and chuck it in a folder in the pi user’s home directory called letsencrypt, then move us in there. It took about 10 minutes on my Pi 3 and reasonable internet connection, your results may vary.

    When that’s installed, we need to break out and get a DNS name (and a dynamic one, at that, as my ISP doesn’t offer static IP addressing)…

  2. Head to System NS, sign up and create a Dynamic DNS name. For the rest of this bit, I’ll refer to my domain as cloudy.system-ns.net. Next thing we need to do is automate the IP<>DNS mapping, as my ISP might pull the rug out and change my allocated IPv4 address at any time. System NS has a guide to do this for your OS (makes sense to do it on the Raspberry Pi, though!) – which can be found here.Basically, you create a file on the Raspberry Pi which tells the Pi to download the System NS page responsible for tying your current public IP to the chosen DNS name. Then you schedule it with crontab to run every 5 minutes. This means in the worst case, you will be a DNS orphan for around 5 minutes (System NS TTL for A records seems to be very short, which helps).
  3. OK – so now we have a domain, let’s get back to sorting out a SSL cert for it. As this Raspberry Pi will be used solely for OwnCloud (as far as the webserver side of things goes) I will generate the certificate for the /var/www/owncloud directory:

    pi@cloud:~ $ sudo mkdir /var/www/owncloud
    pi@cloud:~ $ cd ~
    pi@cloud:~ $ cd letsencrypt/
    pi@cloud:~ $ ./letsencrypt-auto certonly --webroot -w /var/www/owncloud -d cloudy.system-ns.net

    This will go away and pull a cert down from Let’s Encrypt. In fact, it will pull down a public certificate and a private key. They will be (by default) lurking in /etc/letsencrypt/live/cloudy.system-ns.net (you need to be root to look in there, which you can do with ‘sudo su’. Type ‘exit’ to get back to the pi user when you’re done gawking at the nice new certs.

  4. So, that’s some housekeeping done. Next, I’ll steal wholesale from Dave, and give a modified version of his NGINX config (remember, that’s the web server we installed back in section 1).Let’s edit the nginx config file! (Actually, let’s delete everything in it and start again)!

    pi@cloud:~ $ sudo nano /etc/nginx/sites-available/default

    This will open nano, the wusses text editor. I love it, because I can remember how to use it in a hurry. Anyway, delete everything in there (ctrl-k deletes a whole line at a time in nano).  Then edit this, and throw it in:

    upstream php-handler {
    #server unix:/var/run/php5-fpm.sock;
    server {
    listen 80;
    server_name cloudy.system-ns.net;
    return 301 https://$server_name$request_uri;  # enforce https
    server {
    listen 443 ssl;
    server_name cloudy.system-ns.net>;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
    ssl_certificate /etc/letsencrypt/live/cloudy.system-ns.net/cert.pem;
    ssl_certificate_key /etc/letsencrypt/live/cloudy.system-ns.net/privkey.pem;
    # Path to the root of your installation
    root /var/www/owncloud;
    client_max_body_size 2000M; # set max upload size
    fastcgi_buffers 64 4K;
    rewrite ^/caldav(.*)$ /remote.php/caldav$1 redirect;
    rewrite ^/carddav(.*)$ /remote.php/carddav$1 redirect;
    rewrite ^/webdav(.*)$ /remote.php/webdav$1 redirect;
    index index.php;
    error_page 403 /core/templates/403.php;
    error_page 404 /core/templates/404.php;
    location = /robots.txt {
    allow all;
    log_not_found off;
    access_log off;
    location ~ ^/(?:\.htaccess|data|config|db_structure\.xml|README) {
    deny all;
    location / {
                    # The following 2 rules are only needed with webfinger
                    rewrite ^/.well-known/host-meta /public.php?service=host-meta last;
                    rewrite ^/.well-known/host-meta.json /public.php?service=host-meta-json last;
                    rewrite ^/.well-known/carddav /remote.php/carddav/ redirect;
                    rewrite ^/.well-known/caldav /remote.php/caldav/ redirect;
                    rewrite ^(/core/doc/[^\/]+/)$ $1/index.html;
                    try_files $uri $uri/ index.php;
    location ~ \.php(?:$|/) {
                    fastcgi_split_path_info ^(.+\.php)(/.+)$;
                    include fastcgi_params;
                    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                    fastcgi_param PATH_INFO $fastcgi_path_info;
                    fastcgi_param HTTPS on;
                    fastcgi_pass php-handler;
    # Optional: set long EXPIRES header on static assets
    location ~* \.(?:jpg|jpeg|gif|bmp|ico|png|css|js|swf)$ {
                    expires 30d;
                    # Optional: Don't log access to assets
                    access_log off;

    You can copy mine and replace all the bits with cloudy, etc..

  5. Now we can change the PHP settings to allow for larger uploads of files. Dave suggests 2GB, so we’ll go with that. In practice you can set it so whatever your filesystem allows. I’ll combo in a couple of steps here (changing where php-fqm listens as well)

    sudo nano /etc/php5/fpm/php.ini
    search for upload_max_filesize and set it to 2000M
    search for post_max_size and set it to 2000M
    sudo nano /etc/php5/fpm/pool.d/www.conf
    Then Change:
    listen = /var/run/php5-fpm.sock 
    to :
    listen =
    sudo nano /etc/dphys-swapfile
    Then Change:
    to :

    I didn’t follow all of these exactly, so I’ll copy-pasta Dave’s advice and leave you to try it out.

  6. Reboot the Pi!

    sudo reboot
  7. Now you need to install OwnCloud (hey, finally!). The way to do it on a Raspberry Pi 3 running Raspbian is simple.
    1. Grab the tarball from here

      pi@cloud:~ $ cd
      pi@cloud:~ $ mkdir downloads
      pi@cloud:~ $ cd downloads/
      pi@cloud:~/downloads $ wget https://download.owncloud.org/community/owncloud-9.0.1.tar.bz2
    2. Extract the files

      pi@cloud:~ $ sudo tar xvf owncloud-9.0.1.tar.bz2
    3. Now you end up with a nice folder called ‘owncloud’. We want to stick that where NGINX is looking for websites, so we’ll move it to /var/www, change the ownership of the folder to belong to the www-data user and delete all the evidence.

      pi@cloud:~/downloads $ sudo mv owncloud/ /var/www
      pi@cloud:~/downloads $ sudo chown -R www-data:www-data /var/www
      pi@cloud:~/downloads $ rm -rf owncloud*
    4. Dave now recommends you edit a couple of files in the /var/www/owncloud folder to tweak the filesizes:

      pi@cloud:~/ $ sudo nano .htaccess 
      Then set the following values to 2000M: 
      Php_value upload_max_filesize 
      Php_value post_max_size 
      Php_value memory_limit 
      pi@cloud:~/ $ sudo nano .user.ini 
      Then set the following values to 2000M: upload_max_filesize 
    5. Do a final ‘sudo reboot’
    6. Browse to your (whatever you called it) and set up OwnCloud. I have mine set to use the SD card for storage, if you wish to use an external HDD, consult Dave’s excellent post.
  8. When you first load OwnCloud it might complain about a few things, they can usually be solved by installing a memcache, tightening up file/folder permissions or tweaking other security features. As you have a valid SSL cert, you can probably get going pretty well straight away. I’ve added the necessary tweaks to the NGINX config that should get you past most of the pains, at least under Owncloud 9.0.1.
  9. That should be it! I lied, above, though. I use both the SD card and a backup onto an external HDD. This gives me the ability to live without my external HDD if I need it for anything temporarily, and keep 2 copies locally of all my stuff. To do it, I use a nice program called rsync and a little script + crontab to schedule it to run. rsync has a million uses, but one is copying files from one place to another in a really smart way, using deltas (i.e. it only copies the files that have changed). This way, I can schedule it to run every 6 hours, and it only takes as long as transfering the new or changed files to run.
    1. Install rsync!

      pi@cloud:~ $ sudo apt-get install rsync
    2. Create a script to run the sync..

      pi@cloud:~ $ mkdir scripts
      pi@cloud:~ $ cd scripts
      pi@cloud:~ $ nano oc-backup.sh
      sudo rsync -avz /var/www/owncloud/ /media/shamu/oc-backup/ | tail -n 2
      exit 0
      pi@cloud:~ $ chmod +x oc-backup.sh
      pi@cloud:~ $ crontab -e
      Add the following to crontab (which is a bit like nano, or vi, depending on what you select the first time you run it)
      0 0,6,12,18 * * * ~/scripts/oc-backup.sh >> /media/shamu/oc-backup.log
    3. Now every 6 hours from midnight that will run, doing an rsync and adding a date-stamped line to the file oc-backup.log. My 1TB external drive is permanently mounted to /media/shamu, by the way.

So, that’s it. Up and running. Mine has been working for 2 weeks now, approx 128MB of RAM free during normal operation (I check a little too often). php-fqm eats the CPU for breakfast when doing things like generating image previews in the app (I use the Android one and it’s great).. But mostly it all works. In fact, today I deleted my Dropbox app and all the files on it – I’m eating my own dogfood here, trusting this setup for better or worse. If you use it, let me know!

How to migrate a Raspberry Pi SD card to a bigger SD Card

Snazzy title, James.

I recently bought a 200GB SD card from Amazon for what I consider to be a completely crazy price (around $80USD). My Raspberry Pi 3 is running OwnCloud (howto post coming soon) and the 32GB card currently serving as the OS’ home is a little on the small side. It’s also quite an old card, so I’m worried it will one day up and die.

Here’s a quick step-by-step on how to move your SD card to a bigger one, using a Mac with OSX El Capitan (or basically any Unix based computer with an SD card reader).

Step 0: Backup anything important. Things can go wrong any time you mess with this stuff, so caution.

Step 1: Shutdown your Pi (pull the plug out)

Step 2: Take the SD card you want to copy out of the pi, and stick it in your Mac (with an adaptor). It will mount automatically, so run Disk Utility and unmount the ‘boot’ partition, which is what Raspbian OS calls it by default. Once the partitions are greyed out, they’re not mounted anymore.

Screen Shot 2016-04-26 at 2.28.51 pm

Step 3: Check you have space. You will need as much free hard-drive space on your Mac as equals the size of the SD card, even if it’s not full. Mine is 32GB, so I need 32GB hard drive space free. Sadly, I don’t have that much free on my tiny SSD, so I will be using an external USB 3 drive with ample space.

Step 4: Find the BSD name of your SD card reader/card. You do this by opening a terminal and entering:

Jamess-MacBook-Pro:~ james$ diskutil list

Yeah which will spit out a list of your connected media. We’re looking for something that matches the 32GB size of the SD Card (yours might be 8GB, 16GB… whatever)

   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *31.4 GB    disk2

Here we see ‘disk2’ under Identifier, which is what we want.

Step 5: Find out where the file copy of the SD card should go. I want to stick it on my external HDD called SUGAR ROSS (for some reason), so I need to find where it’s mounted.

Jamess-MacBook-Pro:~ james$ cd /Volumes/
Jamess-MacBook-Pro:Volumes james$ ls
Jamess-MacBook-Pro:Volumes james$ cd SUGAR\ ROSS/
Jamess-MacBook-Pro:SUGAR ROSS james$ pwd

There I show you that the 1TB external drive I have connected is located at /Volumes/Sugar\ Ross/ . The extra \ I have in there is an escape character, which helps Unix based Operating Systems handle things like spaces in folder names, which it didn’t historically like.

Step 6: Copy that floppy. We’re now going to use one of the oldest Unix commands there is – dd. Once again, in the terminal, tell the computer to make a direct byte-for-byte copy of the SD card and stick it in a file called sdcard.img (or whatever you fancy).

Jamess-MacBook-Pro:~ james$ sudo dd if=/dev/rdisk2 of=/Volumes/SUGAR\ ROSS/sdcard.img bs=1m

This will take a long while. It’s pretty oldschool and takes its job very seriously. You can tell what’s going on behind the scenes by pressing control-t every now and then. So far, mine has written 23GB in 1226 seconds, and still running. Won’t be much longer now, have a cup of tea. (I will not be doing this for my 200GB card.. Hopefully).

Step 7: Check your image. Ok, 27 minutes elapsed time later, and dd tells me it has finished. As I never believe anything my computer tells me, I want to check the output file.

Jamess-MacBook-Pro:SUGAR ROSS james$ cd /Volumes/SUGAR\ ROSS/
Jamess-MacBook-Pro:SUGAR ROSS james$ ls -la
total 61315256
d.........  1 james  staff         4096 21 Jan 19:19 $RECYCLE.BIN
d.........  1 james  staff         4096 26 Apr 14:22 .
d.........@ 5 root   admin          170 26 Apr 14:08 ..
-.........  1 james  staff  31393316864 26 Apr 14:49 sdcard.img

Using ‘ls -la’ shows me all the files on SUGAR ROSS, and I can see my nice .img file there at just shy of 32GB.

Step 8: Format wars. The SD card I am replacing my Pi’s with is 200GB, and I’m told that gargantuan SD cards have a funny filesystem that’s not compatible with the Pi. As I am writing a physical copy of the existing card onto the new one, I don’t think I’ll have a problem. If you do, I suggest formatting it to FAT32 and going from there. The dd process (this time in reverse) we just ran will take care of everything, as we didn’t copy a partition of the SD card, we copied the whole thing.

Step 9: Prepare the new card. Stick the new (bigger) SD Card into the Mac’s card reader. Use diskutil list again to find the BSD name of the disk, and then unmount any partitions that automatically mounted.

Step 10: Write to disk. This time, we use dd in reverse (and wait a lot longer).

Jamess-MacBook-Pro:~ james$ sudo dd if=/Volumes/SUGAR\ ROSS/sdcard.img of=/dev/disk2 bs=4m

Hint: make sure you unmount, not eject the SD card partition on the card you want to write out to. Disk Utility is good for this.

Step 11: Fire it up. Now that we’ve spent 11,000 seconds writing the 32GB image back to the new card, unmount it (if you succeed with dd in step 10, it should auto mount on OSX). Place the new card into the Pi and power it up. With any luck, it will fire up as it did before. Note, you’ll still only see the original filesize, for now..

pi@cloud:~ $ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root        29G  9.7G   18G  36% /
devtmpfs        483M     0  483M   0% /dev

(See how it still says 29G? That’s a good indication my old SD card (and all the partitions on it) were copied over to the 200G card.

Step 12: Expand the filesystem. Run the following command to stretch out the filesystem to the full 200G.

pi@cloud:~ $ sudo raspi-config

You can then select ‘Expand filesystem’ from the menu and reboot..

Step 13: Revel in your success.

pi@cloud:~ $ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root       181G  9.7G  164G   6% /
devtmpfs        483M     0  483M   0% /dev

Here we see 181GiB of usable space (roughly 200GB). Hooray!

Regex for private-ASN on Junos

Hi, super quick note to share something I’ve made to match 2 Byte Private ASN numbers (64512-65535) in Junos. You can apply it to match a community, or in an AS-PATH.


I will try and expand it to catch “0”, and also 4 Byte Private ASN, but I can’t burn time on that at the moment.

This one catches “0” (also an invalid community), but doesn’t work in Juniper as the \D toggle doesn’t compute…


RYU Faucet (SDN Controller) on Raspberry Pi

I think I finally have a use for one of my 3 Raspberry Pi computers – an SDN controller.

I have an Allied Telesis switch about to arrive, which I will be using as an SDN device – buzzy and buzzwordy at the same time. I was planning on running Ryu-Faucet as my controller stack on a VM, but I had the genius move of moving my R730 server into another location – thinking the SDN controller should be near to the switch for noob-level troubleshooting (despite that being kind of against the spirit of SDN…) – I went with the nextmost NIX thing I could find – a Raspberry Pi 2 running Ubuntu 14.04 LTS.

So – how to go about doing this from a fresh Ubuntu install? Some garbled notes to follow – but first up – I am not a software developer, I can barely code to save myself – so using things like PyPi are new to me.

First up – an apt-get update / upgrade (I run everything from root for this process)

james@ubuntu:/# sudo su
root@ubuntu:/home/ubuntu# apt-get update
root@ubuntu:/home/ubuntu# apt-get upgrade

That gets us up to date. On my home connection with the Raspberry Pi 2 it took about 15 minutes to complete. Next up, installing enough Python tools to install more Python tools.. Ubuntu 14.04 LTS comes with Python 2.7 by default – so that’s a good start.

Now, we grab Pip (more deets here):

root@ubuntu:/home/ubuntu# wget https://bootstrap.pypa.io/get-pip.py
root@ubuntu:/home/ubuntu# python get-pip.py

Cool, so that grabs Pip for us. Note: I ran get-pip.py twice, the first time it installed an old version, then it smoothly upgraded it (from version 1.5 to version 7.2!).

With Pip installed, we’re good to go installing Ryu-Faucet.. Except not quite. The instructions here don’t account for the fact that we’re not hardened Python devs (and that we’re running on an ARM CPU not an Intel one – I guess).

Grab some extra tools from apt:
root@ubuntu:/home/ubuntu# apt-get install python-dev
Now we can run Pip and pull down the file we want to install (ryu-faucet!):

root@ubuntu:/home/ubuntu# pip install https://pypi.python.org/packages/source/r/ryu-faucet/ryu-faucet-0.28a.tar.gz

Watch the magic occur!

root@ubuntu:/home/ubuntu# pip show ryu-faucet
Metadata-Version: 2.0
Name: ryu-faucet
Version: 0.28a0
Summary: Ryu application to perform Layer 2 switching with VLANs.
Home-page: http://http://openflowsdn.github.io/faucet
Author: Shivaram Mysore, OpenflowSDN.Org
Author-email: faucet-dev@OpenflowSDN.Org
License: Apache License 2.0
Location: /usr/local/lib/python2.7/dist-packages
Requires: ryu, pyyaml

Cool. Next time, we’ll configure the Pi’s single ethernet interface to handle management and SDN controller duties and fling some packets across the data plane.

Select an IPv6 address with a double-click in PuTTY

This ranks highly on the nerd-alert scale, but anyway, here we are.

Putty has a nice feature where you can select a word with a double click. It’s really handy, especially when you are dealing with IPv4 prefixes. It doesn’t work with IPv6 addresses by default. You can edit what Putty uses as a delimiter, under Settings -> Selection.


Scroll down to ‘:’ (or whatever character you want to change the behaviour of!) and change its class from 1 to 2. If you save this as your default settings, from now on you can get a nice double click selection of IPv6 addresses.

More info on classes here.

FreeRADIUS 3 on Ubuntu 14.04 – some notes

Ugh. Nothing worse than setting out to install something relatively simple (like FreeRADIUS) only to find the documentation confusing, inconsistent and contradictory. FreeRADIUS has some pretty decent documentation for the actual operation of the software, but getting things going up-front can be a real mission, especially, if, like me, you’ve never done it before. I’m writing this as I go. My goal is to have a FreeRADIUS server running on my server, which I can use to test RADIUS functionality with some lab routers – Juniper MX480, MX960 and M120s.

First of all, why are you installing FreeRADIUS? What do you stand to gain here? If you already know and you’re hitting some glitches with the installation, these notes might help. If you want something a bit more comprehensive written by an expert – try here.

As FreeRADIUS comes with a pre-compiled package for my poorly chosen operating system (after many problems with Ubuntu 14.04 I’ve gone back to Debian 7.8 for nearly everything). That’s great news – simply run the lazy person’s favourite command:

sudo apt-get install freeradius -y

Now that bit is done, the docs tell you to run the ‘radiusd -X’ commands. From what I can see, that program doesn’t come with the Ubuntu package anymore. Simply replace it with ‘freeradius -X’ – it starts FreeRADIUS in debug mode, and away you go. Note – you might find that the ‘freeradius’ service has already started post installation.. Check with:

ps aux | grep freerad

If it’s in there, do a quick ‘sudo service freeradius stop’ and then you can fire it up again in debug (-X) mode.

Due to the way FreeRADIUS is recommended to be installed, the folder ‘/etc/freeradius’ (where the installer assumes you want things put) is owned by root. It might pay to do the rest of the work as root, if you can. Makes things a bit smoother, than having to use sudo all the time.

Add a user in the /etc/freeradius/users file, add a client in the /etc/freeradius/clients.conf and start the service up (I recommend debug). The formatting for adding a user/client is actually documented well. Remember, a user is a user on your router/device, a client is the configuration knob required on your RADIUS gateway (in this case, also a router). You need a secret phrase between the router and RADIUS server to allow them to talk, as well as a user defined on both sides (the subject of the talk between client and server).

Step-by-Step guide to installing Smokeping on Ubuntu 14.04 LTS

Installing Smokeping on Ubuntu used to be a total breeze. Since 14.04 however, it’s been a bit of a mission.

This guide assumes a fresh out of the box Ubuntu install. I’m using the 64bit Server variety, but this should work on any 14.04 system.

UPDATE – It also works perfectly on Ubuntu 16.04 LTS Server :~)

Note – I am a noob with Apache and a relative noob with Linux, but even I got it to work fairly painlessly.

Step 1: install smokeping (aaand you’re done).
 sudo apt-get install smokeping -y

Step 2:  normally, you’d be done by now.. But things have changed.
 sudo nano /etc/smokeping/config.d/pathnames

You’re going to want to go into the pathnames file and comment out the line about mail. Setting up mail to work with smokeping is outside the scope of this post. Because I’m lazy.

Do this: #sendmail = /usr/sbin/sendmail
Then hit CTRL-O, Enter, CTRL-X. That’s how you save a file in Nano, I won’t stick that bit in again.

Step 3: If you made it this far, you’re going to be fine. Start ‘er up…
sudo service smokeping start

Step 4: Head over to a web browser and enter the IP of your server/cgi-bin/smokeping.cgi
(Hint: it will fail, giving you a 404 error).
(Hint 2: you can find the IP address of your server by entering ifconfig, it’s typically eth0)

Step 5: It’s not working because you’re missing a couple of things. One is a slight config change in a smokeping config file,  one is some missing symlinks.. the other is (likely) the cgi module for Apache2 isn’t enabled. Fix it!

sudo nano /etc/smokeping/config.d/General

Edit the line that has cgiurl in it to read like:
cgiurl =

Save and quit nano.

Next you want to edit the following Apache config file:
sudo nano /etc/apache2/conf-available/serve-cgi-bin.conf

Under the lines

“Require all granted

You want to add:

ScriptAlias /smokeping/smokeping.cgi /usr/lib/cgi-bin/smokeping.cgi
 Alias /smokeping /usr/share/smokeping/www
 <Directory “/usr/share/smokeping/www”>
 Options FollowSymLinks

(Save and quit editing the file)

Finally, enable CGI:
sudo a2enmod cgi

Step 6: Kind of threw 3 things into step 5 there, whoops. Anyway now you want to restart smokeping and apache, just to see if you broke anything:
sudo service apache2 restart
sudo service smokeping restart

Now head back to your browser, throw in

It should work… If not, drop me a line.