Monitoring Linux Servers with Monitorix

Monitorix is a mature and open-source system monitoring tool for UNIX and Linux; it is written in Perl and is resource-friendly enabling it to be used quite happily on Raspberry Pi’s and embedded devices too.

Although there are other monitoring and graphing tools for Linux that I’ve used before such as Nagios and Cacti, I wanted to customise and create a single dashboard view for all of my Linux servers and therefore really just wanting something small that could monitor, graph (using RRD) and enable me to then embedded the graphs to a custom web page.

Following some research (Googling’) I settled on using Monitorix.

Monitorix works by running a Perl daemon in the background which monitors and record resource usage of system services, network interfaces, HDD temp etc. (these can be customised in the config file explained below) and has a lightweight, embedded web server which then enables you to view the graphs via. a web browser.

I’m running Ubuntu Server 16.04 LTS on most of my servers now but the same instructions should work for older versions of Ubuntu and other versions of Debian too!

First of all we need to add the APT repository to our server (you could alternatively download the .deb and install that way instead if you wanted), so first we’ll edit our sources.list file:

sudo nano /etc/apt/sources.list

At the bottom of the file, add the following lines:

# Monitorix repository
deb generic universe

Next we need to import the GPG key for the repository, run the following command to add it:

sudo apt-key add izzysoft.asc

Now we will need to update our local package list cache, run the following command to pick up the new packages that are now available to us so we can then install Monitorix:

sudo apt-get update
sudo apt-get install monitorix

Excellent! At this point you should now be able to navigate to http://{your_server_ip}:8080/monitorix and assuming that your firewall permits it, you should now see the Monitorix landing page.


Graphs will take a few minutes to start outputting statistics but you’re now up and running.

Personally I prefer to change the default port from 8080 to a different number and remove the /monitorix path requirement from the end, this is possible by updating the monitorix.conf file located in /etc/monitorix/monitorix.conf, after making changes you need to restart the Monitorix daemon by running:

service monitorix restart

If you intend on monitoring your MySQL server, you will need to install the Perl MySQL driver, you can do so by running this command, the MySQL module also requires a non-privileged user to be setup:

sudo apt-get install libdbd-mysql-perl

I also found that initially the statistics for MySQL on my server was not being captured, this was due to the fact that on Debian based systems, there is an addition configuration file found under /etc/monitorix/conf.d/00-debian.conf which was overriding the default MySQL connection parameters of which you will need to update.

I hope you found this useful, I would certainly recommend checking out the configuration file as there are loads of possible features and settings to really customise your setup.


Installing PHP7 on Windows Server 2012 R2 and IIS 8

At the time of writing PHP 7.0.6 is the latest stable release and given that we are going to be using Microsoft’s IIS as the web server on Windows Server 2012 R2 (x64) we will need to download the latest version of PHP 7.0.x ensuring that we download the NTS (Non-thread safe) version and the x64 build.

To get PHP7 installed on our server will will break down the installation into a number of separate, logical step; these are as follows:-

  • Download the PHP binaries
  • Download and install the VC14 (Visual C++ 2015) runtime.
  • Install the CGI module in IIS
  • Configure PHP in IIS

Downloading the PHP binaries

You can download the latest PHP binaries from the PHP website found here:

You must pay special attention to the version that you download, given that my server(s) run the 64-bit version of Windows, I will naturally choose to download and go for the x64 NTS (none-thread safe) version of PHP.

Once downloaded, extract all the files to C:\PHP, this directory will be used to store our PHP binaries and configuration files.

Download and install the Visual C++ 2015 runtime

PHP7 (at the time of writing at-least) has been compiled in Visual Studio 2015 and thus needs the VC 2015 runtime installed on the server, again, it is important that you install the version that matches your servers hardware architecture (x32 or x64) alternatively install both and you cannot therefore go wrong!

You can download the latest VC C++ 2015 runtimes from the Microsoft website here:

Install the runtime as described above, it is now recommended that you reboot your server for that changes to take full affect!

Installing the CGI Module for IIS

We now need to install the CGI module to enable IIS to “talk” to PHP.

Using explorer, open up the Administrative Tools section in the Control Panel of which can be found at this location: Control Panel\All Control Panel Items\Administrative Tools

Once the Server Manager tool opens, you should see a Add Roles link, click that and now ensure that “CGI” is ticked as per the below screenshot:

Screenshot 2016-05-02 23.54.46

Then click Next and Continue to install the CGI module, it is at this point that I would recommend you restart your server (or IIS at the minimum!)

Note: Although this post is for Windows Server 2012 R2, if you have stumbled across it specifically for installing PHP7 on Windows and are using Windows Vista or 7, you can find the CGI feature under: Control Panel\Programs and Features. After opening the Programs and Features icon you should click on the link to the left labeled Turn Windows Features On or Off – In the tree of services that are then displayed, navigate to Internet Information Services\World Wide Web Services\Application Development Features and then tick CGI.

Installing PHP7

Now that we have the required runtimes installed and IIS has the CGI module enabled we can now start the final part of the setup and that is to install PHP!

Using the Administrative Tools found under the Control Panel again, this time we are going to open up the Internet Information Services (IIS) Manager application:

Now, from the left hand menu click on the server’s name and then from the main panel double click the Handler Mappings icon as shown below:


You will now be presented with the current handler mappings supported by the server, on the right hand side of the window you should see a list of Action links, click on the link named Add Module Mapping… as shown here:


Once the Add Module Mapping window appears, populate the values as follows:


The click on the Request Restrictions button and tick the Invoke handler only if request is mapped to: and then select the File radio button…


Now click Ok and Ok again, the module mapping is now configured!

Although not madatory, it is recommended that you now set a default document so that directory level access to pages will automatically serve the “index” page, it is common when serving PHP sites to have “index.php” configured as a the default index page…

To set a new index page, select the server name from the left hand menu and then double-click on the Default Document icon as shown below:


On the right hand menu of the Default Document window you will have the option to Add a new one, click the Add link and then, in the window that pops up type index.php and then click Save as shown here:


Great stuff! – That’s it, adding a new site and add a index.php file into the root of the home directory should now work!

To test it out, create a file named index.php with the following content:

<?php phpinfo(); ?>

Load the file and you should then be able to see all of the PHP runtime configuration and loaded extensions.

At this point we have PHP7 installed in it’s vanilla form, this means that there are no other PHP extensions enabled at present and the timezone etc. has not yet been set.

We will now copy one of the PHP configuration templates to the “working” copy and then make some adjustments, using the Command Prompt run the following command:

copy C:\PHP\php.ini-production C:\PHP\php.ini

Firstly we will set the server’s timezone, so find and uncomment this line and then set your timezone accordingly to this list:

;date.timezone =

As I live in England (GB) and is where my server is located, I will personally choose to use ‘Europe/London’ as my timezone, therefore my line becomes:

date.timezone = Europe/London

Now we will configure the extension directory, so find this section:

; Directory in which the loadable extensions (modules) reside.
; extension_dir = "./"
; On windows:
; extension_dir = "ext"

…and un-comment (remove the preceding “;” character) the extension_dir = “ext” line so that it now becomes:

; Directory in which the loadable extensions (modules) reside.
; extension_dir = "./"
; On windows:
extension_dir = "ext"

Finally we will uncomment some CGI “fixes” for IIS, this will improve security and performance, so uncomment the following lines and set them to match the values below:

; cgi.force_redirect is necessary to provide security running PHP as a CGI under
; most web servers. Left undefined, PHP turns this on by default. You can
; turn it off here AT YOUR OWN RISK
; **You CAN safely turn this off for IIS, in fact, you MUST.**
cgi.force_redirect = 0

; cgi.fix_pathinfo provides *real* PATH_INFO/PATH_TRANSLATED support for CGI. PHP's
; previous behaviour was to set PATH_TRANSLATED to SCRIPT_FILENAME, and to not grok
; what PATH_INFO is. For more information on PATH_INFO, see the cgi specs. Setting
; this to 1 will cause PHP CGI to fix its paths to conform to the spec. A setting
; of zero causes PHP to behave as before. Default is 1. You should fix your scripts

; FastCGI under IIS (on WINNT based OS) supports the ability to impersonate
; security tokens of the calling client. This allows IIS to define the
; security context that the request runs under. mod_fastcgi under Apache
; does not currently support this feature (03/17/2002)
; Set to 1 if running under IIS. Default is zero.
fastcgi.impersonate = 1

Once you’ve saved the php.ini file you can restart your app pool(s) or simple restart IIS for the changes to take effect…

I hope you found this useful!


Setup an OpenVPN site-to-site remote router (OpenVPN client) on Ubuntu Server 14.04 LTS

In my last couple of blog posts (here and here) I demonstrated how to setup an OpenVPN server using Windows Server 2012 R2 and enable IP forwarding to enable OpenVPN client roaming access to the server network; today I will explain how to setup a Ubuntu Server 14.04 LTS based server which we will ultimately use as a site-site client router.

To give you some background of what I’m doing, I’m going to use my existing OpenVPN server setup as per my last couple of posts (here and here) but I now want to setup a Raspberry Pi2 (running Ubuntu Server 14.04 LTS) as a router given that it consumes a low amount of power  and small in size. The plan is to set this up at my mums house so that when it’s connected she can access my home network and vice-versa (a site-to-site VPN) this will enable her to then access my file servers, store all her photos and ensure that they are aways backed up to the cloud (my home file storage server runs FreeNAS using the ZFS file system and automatically backs up to a cloud storage service daily).

A couple of considerations here, firstly my mum’s home router is a BT HomeHub and not something you can set static routes on (these kind of features normally only come with commercial grade routers), therefore I will instead install a DHCP server on the Raspberry Pi2 in addition to the OpenVPN client to enable the publishing of static routes to the clients on her local network, the set-up will ensure that only local network traffic bound for the server network is routed via. the Raspberry Pi2 (over the VPN) and local internet browsing traffic continues to route through the BT HomeHub (the default gateway) to maintain a fast web browsing experience!

Lets start…

So first of all, I will make the assumption that you already have a clean version of Ubuntu Server 14.04 installed on your Pi2 (or other hardware).

The next thing you should set the hostname of the server, it is important that the hostname of the server matches the SSL certificate common name that we will set up later, so for now I would recommend you set the hostname (I’ll use ovpn-router-aaa in this example, just replace with whatever you wish to use!) and update the /etc/hosts file (so that the hostname matches the address like so:

echo "ovpn-router-aaa" > /etc/hostname

Next, update the line that starts with (normally this will be on line #2) so that is follows with the hostname (unless it already does):

nano /etc/hosts

…and ammend like so:            ovpn-router-aaa

Now save the file and try to ping your hostname like so:

ping ovpn-router-aaa

It should resolve and respond back with and by doing this, the sudo command will stop complaining about being unable to lookup the hostname – As well as many other benefits ofcourse! 😉

Next you should give some thought to your IP addresses that you will use, for the new remote network I will be using 10.10.0.x subnet you can ofcourse use whatever you like and I would recommend that you adjust any references to this subnet below if you choose to use a different one.

So, for clarity, will be the static IP address that be assigned to the BT HomeHub router at my mums house, will be the static IP address that will be assigned to the Ubuntu Server that will be running the OpenVPN client, the DHCP server and will provide the routing for our VPN LAN’s. We will keep – free for any static IP address requirements and will configure the DHCP server running on the Ubuntu Server to distribute a scope of – to internal clients.

Now that we have the IP addressing stuff out of the way, it is now time to configure the servers NIC with these details, so we will now edit the /etc/networking/interfaces file like so:

nano /etc/network/interfaces

…and adjust it so it looks similar (or the same if you are using the same IP addressing as myself):

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static

Next you will need to restart the network interfaces (or simply reboot the server) for the changes to take affect.

Create client certificates

We will need to create the SSL certificate for the OpenVPN client (router) that we are configuring, so in order to do this, logon to your Windows Server and open up the command prompt and run the following commands:

cd \
cd "C:\Program Files\OpenVPN\easy-rsa"
build-key.bat ovpn-router-aaa

You can accept the defaults when asked for the Country, Org unit etc. but ensure that when prompted for the Common Name and Name attributes that these match your hostname (eg. ovpn-router-aaa) and ensure that when prompted for a challenge password you skip it!!

If you would like to re-cap the process of creating the client certificates, see my original post here.

Once you have created the client certificates you now need to locate the following files in the C:\Program Files\OpenVPN\easy-rsa\keys directory and keep them for later (we will need to upload these to our Ubuntu Server later!

  • ca.crt
  • ovpn-router-aaa.crt
  • ovpn-router-aaa.key

Enable IP forwarding

We now need to enable IP packet forwarding on our Ubuntu Server to enable the routing functionality on our server. To enable IP forwarding we need to run the following commands:

nano /etc/sysctl.conf

We need to uncomment the following line and make sure it is set to ‘1’ (and not ‘0’):


Save the file and now run the following command to enable the change:

sysctl -p /etc/sysctl.conf

Great stuff! – Lets move on…

Install OpenVPN

We will now install OpenVPN and configure it:

apt-get install openvpn

We now need to configure the client VPN configuration file, to do this we will create a new configuration file:

nano /etc/openvpn/vpn.conf

We will need to populate it with the following content (replace XXX.XXX.XXX.XXX with your OpenVPN server public IP address or FQDN):


dev tun
proto udp
remote XXX.XXX.XXX.XXX 1194

log-append /var/log/openvpn.log

resolv-retry infinite


ca ca.crt
cert client.crt
key client.key

verb 3


Now upload the ca.crt, ovpn-router-aaa.crt and ovpn-router-aaa.key to the server  (in the /etc/openvpn directory) and for best practice (seems to be the convention around the OpenVPN community), we will now rename both the ovpn-router-aaa.* files to simply ‘client’:-

cd /etc/openvpn
mv ovpn-router-aaa.crt client.crt
mv ovpn-router-aaa.key client.key

We will now configure OpenVPN to start automatically and connect to the VPN at boot, to do this we need to edit the following file:

nano /etc/default/openvpn

…now set (or uncomment) the AUTOSTART directive to ALL like so:


Save the file!

By restarting the openvpn service the VPN configuration should now try and connect to the remote network, lets test it out:

service openvpn restart

You can check the status of this by looking at the OpenVPN logs like so:

tail /var/log/openvpn.log

Any error messages should be visible here but you should be all good!

Test ping!

If you followed my other tutorials then you will remember that the IP address for our VPN server (on the Tun interface) is:, therefore lets see if we can ping it:


Assuming all went well you should now be getting a response back from the server!

Test reboot functionality…

At this point, it may be a good idea to reboot the Ubuntu Router and then login and try pinging immediately (to check that the OpenVPN service has auto-connected at reboot)

 Install a DHCP server and advertise the static routes to our LAN clients.

So at this point we have our router connecting to our remote network and we have tested that we can route to the server using the 10.8.0.x subnet but now we need our local client machines (those machines on the client network) to know how to route traffic to the remote (server-side) LAN – In my situation this will be my home network!

We will therefore configure DHCP on the Ubuntu Server and advertise a static route for our clients to ensure that they don’t have to manually add the static routes their side:

# Stop OpenVPN service just for interface reasons...
service openvpn stop

# Install the DHCP server...
sudo apt-get install isc-dhcp-server

Now we will tell the DHCP service to only run on our eth0 interface (so we don’t try to advertise DHCP leases to other networks (including over VPN tunnel) by adding eth0 into the INTERFACES=”” directive:

nano /etc/default/isc-dhcp-server

So simply replace the line INTERFACES=”” with INTERFACES=”eth0″ and then save the file!

Now we will set out configuration up, edit the main DHCP service configuration file here:

nano /etc/dhcp/dhcpd.conf

And we will now set up as per our requirements, the following file contains everything that we will need, copy and paste it and tweak where required:

ddns-update-style none;
log-facility local7;

subnet netmask {
    # We set the BT HomeHub as the default gateway...
    option routers;
    option subnet-mask;
    option broadcast-address;
    # The domain name for the local network
    option domain-name "arads.local";
    # The name of your ActiveDirectory Domain (and other local domains)
    option domain-search "arads.local", "";
    # To resolve computer names from local DNS, I set this to the Windows 2012 R2 Server
    option domain-name-servers;
    # Put all the static routes for your other networks here!!
    option static-routes,;
    # If you have a server running NTP, you can set it here!
    option ntp-servers;
    default-lease-time 86400;
    max-lease-time 86400;
    # The IP range that we will serve...

Save the file and restart the service like so:

service isc-dhcp-server restart

OpenVPN Server Configuration changes

Now we need to logon to our Windows Server and make a slight change, we need to add our new route using the “push” directive and add a new directive for a CCD (Client Configuration Directory)

On the Windows server, using Notepad (or another text editor) open up the file: C:\Program Files\OpenVPN\config\server.ovpn

Add his new “push” directive (under the ones that already exist):

push "route"

We now need to un-comment (or add) the following directives further down to enable client specific configuration:

client-config-dir ccd

Lets create the ‘ccd‘ directory now, this should be created under C:\Program Files\OpenVPN\config – Do this now!

Next up, we have to create new configuration file in the new ccd directory (C:\Program Files\OpenVPN\config\ccd), this file should be named the same as the hostname/cert common name – Therefore in my scenario, the file should be name ‘ovpn-router-aaa‘ and you MUST ensure that the file DOES NOT have a file extention eg. if you are using for example, Microsoft Notepad, this will automatically add this for you, make sure you remove it if required!

In the file we have to specify the internal route (using the iroute directive) this will force the remote LAN router (in our case, this will be the Ubuntu Router that will be located at my mums house) NOT to route the local LAN traffic over the VPN!

The contents of the file should be as follows:

# Set a static IP address for the Router's client connection (to OpenVPN)

# Set the internal IP range for this network.

Save the file and restart the OpenVPN service using the Administrative Tools > Services panel.

Given that we have just restarted the OpenVPN service you should force all your clients/other VPN routers to reconnect to ensure they get the latest configuration!

Configure IPTables

Ubuntu Server, by default comes with IPTables tables installed, we need to add two persistent rules to ensure that all routed traffic is permitted like so:

apt-get install iptables-persistent

# Add the rule to enable IP packet forwarding through the firewall...
sudo iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

# Save the current IP tables configuration so it is persistent.
sudo /etc/init.d/iptables-persistent save
sudo /etc/init.d/iptables-persistent reload

I would suggest rebooting your Ubuntu Server at this point!!

Adding the new route to the DHCP server on the server network.

We will now RDP to our Windows Server (the one that is running the OpenVPN server) and we will now add the new static route to our DHCP configuration.

Add the following static route ( to your existing routes:

Screenshot 2016-03-07 16.54.55

Ensuring that the router address is your Windows Server’s physical NIC address.

To check that it has been successfully added to the DHCP configuration, renew the IP address on one of your server LAN clients and then run the following command:

route print

Or if you are using a Mac, instead use:

netstat -nr

If using a Mac, You should now see it in the list like so:

Screenshot 2016-03-07 16.58.46

We should now be able to ping the remote client network devices from our client machines (and our Windows server) like so:

# Ping the BT HomeHub (the client network Default Gateway)

# Ping the Ubuntu Server (VPN router)

# Ping out first DHCP client (assuming one is connected!)...

Congratulations – You should now be all up and working!!

A couple of things to keep in mind…

  • If you have any servers with manually entered static IP addresses (not distributed by DHCP) these will need the static routes added manually if you wish to have them accessible to the other subnets.

Enabling OpenVPN clients to access to the LAN.

In my previous post I wrote about how to setup an SSL VPN server on Windows 2012 R2 and enable external network access to the server using OpenVPN.

This article will walk you through the process of configuring IP forwarding on our Windows server and exposing static routes to enable VPN clients to access network devices on the LAN given that Out-the-box OpenVPN will only allow the clients to access the resources on the OpenVPN server.

This article will cover the following things:

  • Enable IP Forwarding on Windows Server 2012 R2 (so that our VPN traffic can route to our internal network and vice-versa)
  • Add static routes to our server.ovpn configuration so the routes are advertised to the client machines so they understand how to route to our LAN network.
  • Add static routes to our internal network clients (using Windows DHCP and I will also demonstrate adding them manually for servers using static IP addresses) so that LAN clients and servers can “see” the VPN clients. – What goes up must come down!!
  • Use our internal DNS server for name resolution by adding some additional client configuration to the server.ovpn file to enable better hostname resolution for a more “transparent” configuration.

Lets get going…

Enable IP forwarding

To enable IP forwarding on the server we will need to use Regedit (Windows Registry Editing Tool), this change is very simple to make and although this can also be achieved by enabling Routing and Remote Access on the server there is little point given that we simply don’t need it.

On the server, open up Command Prompt and run:


Navigate to: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Double click the IPEnableRouter entry and set the Value data field to ‘1’

The result of which should look as follows:


You can now close Regedit!

At this point I had to restart my server as the IP Forwarding did not appear to work immediately! – I’d therefore recommend that you restart your server at this point too!

Add static routes to our server.ovpn configuration

By adding a static route for our internal network to the server.ovpn file, these static routes will be downloaded and set on the client machines when they connect to the VPN and is required to enable the client machines to understand how to route to our LAN.

In our example we will assume that our internal network subnet is: and we will use the default OpenVPN subnet of for the VPN clients.

To add the static route we need to edit our OpenVPN Server Configuration file; using notepad open the following file:

C:\Program Files\OpenVPN\config\server.ovpn

Now scroll down the file until you find this section:

# Push routes to the client to allow it
# to reach other private subnets behind
# the server. Remember that these
# private subnets will also need
# to know to route the OpenVPN client
# address pool (
# back to the OpenVPN server.
;push "route"
;push "route"

As you can see there is already two examples of how to add routes but instead of deleting the examples (The ‘;’ character is an comment!) we’ll add a new one below it:

push "route"

This will tell OpenVPN clients that when the computer tries to access any IP address in the subnet that it should route through our OpenVPN server (as the default gateway for this network).

You should also find the following configuration section and uncomment (remove the ‘;’ character) the client-to-client directive as demonstrated below:

# Uncomment this directive to allow different
# clients to be able to "see" each other.
# By default, clients will only see the server.
# To force clients to only see the server, you
# will also need to appropriately firewall the
# server's TUN/TAP interface.

For the changes to take effect, save the file and restart the OpenVPN Service from the Control Panel > Administrative Tools > Services panel.

If all has gone well, your VPN clients should not be able to route to the network.

Add static routes to our LAN connected computers so they can “talk” to our VPN clients

There are a number of ways in which we can advertise the route to our network devices on the LAN, for example you could add the static route on the primary gateway (eg. your router) but for simplicity I will show you how to add these static routes in via. DHCP using Microsoft DHCP services given that we are also using Microsoft DNS services it makes sense to do it this way:

Lets open up the DHCP Server MMC by navigating to:

Control Panel > Administrative Tools > DHCP

Expand your current server and expand “IPv4“, and then expand “Scope” now select “Scope Options“, if you don’t already have an option setup called:

121 Classless Static Routes

Then add a new route as per this screenshot:


That’s it, now on your internal network machines, the next time they get a new IP address they will also obtain the static route information!

The other way in which you can add these routes (if you have servers or machines that do not get their network configuration from a DHCP server) is to add it manually using the terminal/command prompt.

On a Windows-based PC/Server the command you need to run is:

route add mask

This will add a static route for the network with a netmask of to route via.; is the IP address of the “gateway” and is our Windows Server 2012 R2 server which is running the OpenVPN server software as well as our DHCP and DNS server.

To test that the route has been added successfully use the following command to “print” out the routing table:

route print

Now test that the route is successfully working by using an internal network machine to “ping” a connected VPN client using it’s IP address eg. ping (that is ping-able as most firewalls will block ICMP requests!!)

Configure VPN clients to query our internal DNS servers

By default OpenVPN is configured to use a split tunnel configuration and therefore client-side DNS settings will default to use the ISP’s DNS servers and due to this, internal server name resolution will fail to work (unless you are using a manually updated hosts file)

On my network I’m using Windows DNS services to manage DNS name resolution for all my internal servers and dynamic hostnames from DHCP leases.

Given that we have already added a static route to the internal network, we can now specify to the OpenVPN clients to use our internal DNS server, in this example my DNS server has an IP address of, we will also set the domain suffix and search suffix properties so that clients do not have to use the FQDN when attempting to locate hostnames.

Open up the server.ovpn file again as we did when we added the static routes and locate the following configuration block:

# Certain Windows-specific network settings
# can be pushed to clients, such as DNS
# or WINS server addresses. CAVEAT:
# The addresses below refer to the public
# DNS servers provided by
;push "dhcp-option DNS"
;push "dhcp-option DNS"

We will now add our internal DNS server (for any external address our DNS server is configured to forward requests to Google’s external DNS servers) under the above configuration block:

# Use our internal DNS server
push "dhcp-option DNS"
# Custom Domain and Search Suffix
push "dhcp-option DOMAIN mydomain.local"
push "dhcp-option SEARCH mydomain.local"

Save the file and restart the service again and reconnect all VPN clients for the changes to take effect!

For your reference, you can see my server.ovpn example that is tested as working here.

Setting up OpenVPN Server on Windows 2012 R2

This weekend a friend of mine asked my advice on setting up a VPN for his  business to enable remote workers to connect and access the office’s file server and other internally hosted data.

The requirements really consisted of a using Windows Server (ease of management) with the ability for MacOSX laptops to connect over a VPN to it.

A couple of years ago, I had a similar setup that I used to connect to my home network using my own MacBook Pro but this time I thought I’d document it to help others.

So, for this setup we’ll use the following software to set-up this solution up:

Server (running Windows Server 2012 R2)

Client (running MacOSX 10.11 El Capitan)

At the time of writing, the following latest stable versions and the versions that are installed as part of this guide are as follows:

You can download both of these versions from my site if you wish!

Once installed, this will enable the client machine (the MacOSX laptop) to connect to the VPN using a split tunnel configuration; using a split tunnel will ensure that only traffic that is destined for the VPN network will be routed over the VPN, your internet connection and other traffic will be routed locally of which will increase speed and performance – Again, this was another requirement, before doing this yourself please understand the security implications of such a setup.

Installing the OpenVPN Server software

We will now log on to our Windows Server 2012 R2 desktop and then run the OpenVPN Server installer (openvpn-install-2.3.10-I601-x86_64.exe) installer, the following screen will appear, click Next to start the installation…

Screenshot 2016-01-31 22.10.01

Next you will be presented with the License Agreement, read and click the I Agree button to continue…

Screenshot 2016-01-31 22.10.16

You’ll then be asked to choose which components to install, you will need to ensure that you select ALL components, this is very important otherwise you will not get Easy-RSA and other utilities that we will need, when you are happen then click Next

Choose where you want to install the software and where the configuration will be stored, I simply accepted the defaults and then click Install

Screenshot 2016-01-31 22.10.49

During the installation you will be prompted to install the virtual TAP NIC adapter, this is a virtual network device that is required by OpenVPN server, you will need to click Install here…

Screenshot 2016-01-31 22.11.04

Once the installation is complete, you’ll then need to click Next

Screenshot 2016-01-31 22.11.22

Installation is now complete, now click Finish and we’ll move on to configuring the server.

Screenshot 2016-01-31 22.11.45

Configure easy-rsa

easy-rsa is a CLI utility to build and manage a PKI CA. In laymen’s terms, this means to create a root certificate authority, and request and sign certificates, including sub-CAs and certificate revokation lists (CRL).

If you are interested, the source code, further information on the utility and the issue tracker can be found on it’s GitHub project page.

Anyway, it’s get on and configure easy-rsa, open up Command Prompt and then type the following commands:

cd \
cd "C:\Program Files\OpenVPN\easy-rsa"

Running init-config.bat script will generate a new vars.bat file in our easy-rsa directory, this file will contain our configuration. So now we need to open up the following directory using Windows Explorer:

C:\Program Files\OpenVPN\easy-rsa

Now, using Notepad (or another text editor) edit the batch file named vars.bat, we need to configure some variables…

Change the following settings (nearer the bottom of the file) to meet your requirements:

set KEY_CITY=SanFrancisco
set [email protected]
set KEY_CN=changeme
set KEY_NAME=changeme
set KEY_OU=changeme
set PKCS11_MODULE_PATH=changeme
set PKCS11_PIN=1234

Mine now looks as follows – These values are only defaults that will be pre-populated when using the build scripts, and given that the KEY_CN and KEY_NAME will be unique for each build request, I’ve changed them just for reference notes really – this will be outputted so will act as a note to you (the admin) in future:

set KEY_PROVINCE=Suffolk
set KEY_CITY=Ipswich
set [email protected]
set KEY_CN=Unique/machine name
set KEY_NAME=Use same as the Common Name!
set PKCS11_MODULE_PATH=changeme
set PKCS11_PIN=1234

For the security paranoid amongst us, you may also look at increasing the value of the KEY_SIZE variable from 1024 to, for example 2048 but this will slow down TLS negotiation performance – your call really!

Next you should save the changes to the file and then using Command Prompt, run the following commands:

cd \
cd "C:\Program Files\OpenVPN\easy-rsa"

Generate the CA and Server certificates

Great, now we will build the CA (certificate authority) by running the following command:


When asked for input, you should be able to accept the defaults (as we set in the vars.bat file earlier but remember, we must specify a KEY_CN (Common Name) and when asked for the Name, it should match the Common Name.

Given that we are creating the Certificate Authority and the standard practice is to call this certificate file ‘ca’, when asked for the Common Name and the Name use ‘ca’ as shown in the screenshot below:

Screenshot 2016-02-01 09.43.43

We now need to build the servers’ certificate file and again, we’ll keep it as simple as possible so we will set the “Common Name” for the servers’ certificate file as ‘server‘ and again, the Name will match this (notice that the name is passed in as the first argument on the build-key-server.bat call):

build-key-server.bat server

In addition to the last created ‘ca’ certificate, this time you will be asked if you wish to sign and then commit the certificate (in both instances, as per the screenshot below choose yes (type ‘y’ and press enter for both!):

Screenshot 2016-02-01 09.49.47

Building client certificates

For each VPN client that connects to the VPN they will need to connect using an SSL certificate and therefore the following process must be ran for each client device that will connect to the VPN.

As a rule of thumb, you could generate and use an SSL certificate for each user that could be used on multiple machine but there should be a single SSL certificate generated for each device so that in the event that a laptop or other device is lost or stolen, the associated certificate can be revoked from the server to prevent unauthorised access to your network.

So for each new client device, run the following command and then input the requested information:

cd \
cd "C:\Program Files\OpenVPN\easy-rsa"
build-key.bat {machine_name}

As before, when prompted for the “Common Name” and the “Name” use the name of the machine, therefore in this instance “bobby-macbookpro” as demonstrated in the example screenshot below:

Screenshot 2016-02-01 10.13.50

Generate Diffie Hellman parameters

To complete the set-up of encryption we must now generate the Diffie Hellman parameters, we do this by typing the following command:


The output of running the above command should look as follows:-

Screenshot 2016-02-01 10.20.52

To learn more about the Diffie Hellman protocol, check the Wikipedia article.

Copy the generated certificates to the “config” directory

When using easy-rsa to generate the certificates they are generated and stored under: C:\Program Files\OpenVPN\easy-rsa\keys, the following files in this directory need to be copied to the C:\Program Files\OpenVPN\config directory:

  • ca.crt
  • dh1024.pem
  • server.crt
  • server.key

Once complete, we should start the OpenVPN service in the Services Manager as shown here:

Screenshot 2016-02-01 11.15.00

Be aware: By default the OpenVPN service is set to start manually, therefore if your server reboots you will need to manually start this service before VPN clients can re-connect. If you want to set this to ‘Automatic’, right-click the service name, choose properties and then configure the startup as ‘Automatic’.

Configuring OpenVPN server

Now that we have the certificate and CA creation out of the way, we will now configure the OpenVPN server.

Lets copy the sample configuration files to the ‘config’ directory to give us a base to start our configuration on:

copy "C:\Program Files\OpenVPN\sample-config\server.ovpn"C:\Program Files\OpenVPN\config"
copy "C:\Program Files\OpenVPN\sample-config\client.ovpn"C:\Program Files\OpenVPN\config"

We can now edit the “cloned” sample configuration files and of which, once fully configured to meet our preference we will then be used in our production environment.

So, using a text editor (for example, NotePad) edit the server.ovpn file:

notepad "C:\Program Files\OpenVPN\config\server.ovpn"

We need to set the location of the certificates that we generated earlier, therefore locate the following block:

# Any X509 key management system can be used.
# OpenVPN can also use a PKCS #12 formatted key file
# (see "pkcs12" directive in man page).
ca ca.crt
cert server.crt
key server.key # This file should be kept secret

# Diffie hellman parameters.
# Generate your own with:
# openssl dhparam -out dh2048.pem 2048
dh dh2048.pem

and replace the paths so they match as shown here:

# Any X509 key management system can be used.
# OpenVPN can also use a PKCS #12 formatted key file
# (see "pkcs12" directive in man page).
ca "C:\\Program Files\\OpenVPN\\config\\ca.crt"
cert "C:\\Program Files\\OpenVPN\\config\\server.crt"
key "C:\\Program Files\\OpenVPN\\config\\server.key" # This file should be kept secret

# Diffie hellman parameters.
# Generate your own with:
# openssl dhparam -out dh2048.pem 2048
dh "C:\\Program Files\\OpenVPN\\config\\dh1024.pem"

Save the file – Lets move on to configuring the Client configuration!

Configure the Client OpenVPN config file

Similar to the server configuration, we just need to edit the client configuration file and set the remote IP/hostname of our OpenVPN server.

The Client OpenVPN configuration file is then used on the client machines to configure the OpenVPN client to connect to the remote VPN server.

Be aware: If you edit this using NotePad on Windows the line endings will be formatted CLRF of which, will cause issues when trying to load it on the Mac, therefore it is recommended that you use a LF aware editor to edit it or convert the file using dos2unix when using it for the first time on your MacOSX/Linux machine.

Lets edit the file and set the remote server address:

notepad "C:\Program Files\OpenVPN\config\client.ovpn"

Locate the following line:

remote my-server-1 1194

and replace it with your public IP address or hostname that your clients will use to connect to your OpenVPN server, for example:

remote 1194

Save the file and we’re nearly ready to start testing!!

Configuring port forwarding and firewall rule exceptions

We’re nearly ready to start testing but before we do, assuming you have a router/firewall between your server and the internet you will need to first of all open up port 1194/UDP (don’t forget to enable it on the Windows Server 2012 R2 software firewall too if you haven’t already!) and ensure that the traffic is forwarding to your server without this the VPN clients will not be able to connect and use the newly configured VPN service.

From a “best practice” point of view it is advisable to change the default UDP port in your server and client configurations and ensure that the firewall/router is also updated too this makes it harder for hackers to identify which services are running on your server.

Configuring the OpenVPN client (TunnelBlick) on MacOSX

Now that we have the server and network configured we now need to install TunnelBlick on the MacOSX client device.

The installation of TunnelBlick is so simple that I won’t cover it here but once you have it installed lets continue…

First of all we need to create a directory in our home directory to store the client and CA certificates that we will copy from our server shortly.

I would recommend that you create a directory in the root of your home directory called ‘OpenVPN Client Config’, you can do this in the terminal like so:

mkdir ~/OpenVPN\ Client\ Config

Now copy the following file from your Server:

  • C:\Program Files\OpenVPN\config\client.ovpn
  • C:\Program Files\OpenVPN\easy-rsa\keys\ca.cert
  • C:\Program Files\OpenVPN\easy-rsa\keys\bobby-macbookpro.crt
  • C:\Program Files\OpenVPN\easy-rsa\keys\bobby-macbookpro.key

Into the new OpenVPN Client Config directory in your home directory like so:

Screenshot 2016-02-01 11.53.31

Now we have to make some minor adjustments to he certificate paths in the client.ovpn file so, using a text editor, open the file on your Mac and update the certificate paths to match your environment like so:

# SSL/TLS parms.
# See the server config file for more
# description. It's best to use
# a separate .crt/.key file pair
# for each client. A single ca
# file can be used for all clients.
ca "/Users/ballen/OpenVPN Client Config/OpenVPN Config/ca.crt"
cert "/Users/ballen/OpenVPN Client Config/bobby-macbookpro.crt"
key "/Users/ballen/OpenVPN Client Config/bobby-macbookpro.key"

Save the file and close the text editor, we then need to install our new configuration by double-clicking the client.ovpn icon as shown in the above screenshot.

Double-clicking the icon will prompt as follows, click “Only Me”:

Screenshot 2016-02-01 11.56.11

Once the configuration has been added, you’ll get notification of success as shown here:

Screenshot 2016-02-01 11.57.32

Connecting to the VPN for the first time

Now that the configuration has been added to TunnelBlick, using the TunnelBlick icon in the top-right hand corner you should now be able to connect to it:

Screenshot 2016-02-01 11.58.18

TunnelBlick should now happily connect to the VPN…

Screenshot 2016-02-01 11.58.28

Now that you are connected to your VPN, test out by “pinging” the server IP address:


To disconnect from it, simply click the TunnelBlick icon and choose ‘Disconnect client’…

Screenshot 2016-02-01 11.58.41

In my next post (otherwise this post will be huge) I will cover the advanced configuration of the server to enable your VPN clients to “see” your internal network and your internal network to “see” your VPN clients this will bidirectional transfer of data eg. accessing network shares on the network and other services provided on the office network.

Dark theme (Dracula) for NetBeans

I’ve personally used NetBean for about five years now; I’ve learn’t to love it and despite all the “cool kids” recently moving to the likes of PHPStorm and Sublime Text, everytime I try to switch over I just miss my trusty NetBeans and come flying back.

Since recently purchasing my latest MacBook Pro, I went through the motions of re-installing all of my software development tools again and went on the hunt for a dark theme that looks similar to that of the PHPStorm theme for NetBeans.

I really like the dark theme (Dracula) that comes with PHPStorm and the other JetBrains IDEA family IDE’s and to my surprise I was shocked to find that someone has actually very recently developed and released one

JetBrains PHPStorm Dark (Dracula) Theme for NetBeans

Although at present the folder icons in the project explorer panel do not match the ones that come with the JetBrains IDEA IDE’s the developer is apparently working on getting them added!

Screenshot 2016-01-17 22.47.35-resized

You can add the theme via. the Plugins menu in Netbeans.

I’m really chuffed with my new eye candy and look forward to further improvements to the theme in time!!


Setup a Ubuntu 14.04 LTS (MATE) terminal server with LTSP

In this post I’m going to explain how to set-up a terminal server that you can use at home or in the office; the terminal server (running LTSP) will enable you to run a central terminal server or “mainframe” type network where you can have a large number of “diskless clients” (also know as “dumb terminals” or “thin clients”) connecting to the central server and of which is used to run all the applications.

Once we have set-up our terminal server you can then use any PXE bootable device to connect to our terminal server, you could use a normal desktop PC, a branded “thin client” device and even a Raspberry PI as a super cheap thin client solution!

There are various tutorials on the internet for setting up such an environment but most of them force you to run DHCP on the terminal server itself, in this tutorial I will be configuring a DHCP proxy (dnsmasq) to enable our server to provide PXE boot information whilst still using our existing DHCP server configuration.

So lets get started…

Installing the operating system

I’ve personally chosen to use Ubuntu MATE distribution as I perfect the Gnome 2 style desktop environment but this tutorial should work exactly the same for the standard Ubuntu distribution, Lubuntu, Xubuntu and potentially any other Ubuntu derivative!

So, I’ll assume now that you’ve installed the operating system and logged in using your account that you setup during installation!

At this point it would also be advisable that you set a static IP address on your server!

Installing the LTSP server, dnsmasq and the TFTP server

We need to install the following software of which makes up all the core of what we will need for our setup; lets run the following commands:

sudo apt-get update
sudo apt-get install ltsp-server dnsmasq tftpd-hpa

As you probably noticed we are installing three pieces of software here, firstly we install the ltsp-server package (note that we’re NOT installing the ltsp-server-standalone package as this will force the installation of a DHCP server on our Terminal server of which will break our “existing” DHCP set-up) secondly we’re installing dnsmasq; Dnsmasq will provide us with the DHCP proxy functionality of which will enable us to use our existing DHCP server on our network and then still provide the required PXE boot information and then last but not least we install tftpd-hpa of which provides us with TFPP functionality thus allowing our “thin clients” to download the boot images.

Though Dnsmasq can do both DHCP and TFTP, There has been a crucial bug identified when functioning as a TFTP server specifically with Ubuntu 14.04, so we’ll be using the tftpd-hpa package for managing the TFTP services instead.

Building the “thin client” images

Now that the server has the packages installed, we now need to generate the “thin client” bootable image, this image is based on the current terminal server’s setting and is then served to our “thin clients” via. TFTP when they boot using PXE.

 sudo ltsp-build-client --arch i386

The above command will take some time as it will download all packages for this stripped-down Ubuntu-based “thin client” operating system and install them under: /opt/ltsp/i386/. It will then compress this into /opt/ltsp/images/i386.img, this is the the actual image that will be served to the client via. TFTP.

If you wish to build x64 client images (although these won’t work for older hardware and the Raspberry Pi’s) simply omit the ‘–arch i386‘ from the above command and all other related commands in this post, you’ll also have to pay special attention to the rest of this post as you’ll need to manually updated paths in the configuration files.

It is worth noting that client boot image will be based on your current Ubuntu version using the at the current state of packages in its repositories. Since this is merely a thin client operating system, it shouldn’t really matter if the image is stays “old”, as long as it works. Remember, the software is actually running on your server, not the client!

Enabling DCHP proxy support in our image

The configuration of PXELINUX does not ship with support for DCHP Proxy support by default so we need to fix this by running the following command:

sudo sed -i 's/ipappend 2/ipappend 3/g' /var/lib/tftpboot/ltsp/i386/pxelinux.cfg/default

Note: If you’ve chosen to build the 64bit version of the LTSP client images, you’ll need to replace the i386 directory with amd64.

It is also important to note that if you update your thin client images using the command below (in the Upgrading your “thin client” boot images section) that you’ll have to re-run this command afterwards!

Creating the LTSP configuration for Dnsmasq

Next we need to create a new configuration file so that Dnsmasq will provide the PXE boot information and thus serving our boot image using our new TFTP server.

Create the new configuration file by running this command:

sudo nano /etc/dnsmasq.d/ltsp.conf

….then add the following configuration (copy and paste) to the file:

# Dnsmasq running as a proxy DHCP


# Tell PXE clients not to use multicast discovery
# See section in
# Better support for old or broken DHCP clients
# Enable this for better debugging

# Note the file paths are relative to our "tftp-root" and that ".0" will be appended
pxe-prompt="Press F8 for boot menu", 3
pxe-service=x86PC, "Boot from network", /ltsp/i386/pxelinux
pxe-service=x86PC, "Boot from local hard disk"

Before saving the file ensure that you update the dhcp-range setting to match your network settings and, if applicable the “i386” in the /ltsp/i386/pxelinux path and “x86PC” section in the pxe-service section at the bottom of this configuration file.

The last thing we need to do now is to restart the the dnsmasq service using the following command:

sudo service dnsmasq restart

Great, we’re now ready to test it out… You can now either create a virtual machine in Oracle VirtualBox, setting the network adapter type to ‘bridged’ you should now be able to start it (and if Network boot is enabled) and you will, after a few seconds see the LTSP client login screen like so…

Ubuntu LTSP Client Login screen.


Upgrading your “thin client” boot images in future….

It is possible to upgrade this image to latest Ubuntu packages this will include updates for hardware drivers too, this something that you might want to do once in a while and for security reasons this is good practice, it’s simply a case of running the following command from the terminal on your server:

# Regenerate the thin client boot image
sudo ltsp-update-image

# As mentioned above we need to reset the PXELINUX DCHP proxy settings:
sudo sed -i 's/ipappend 2/ipappend 3/g' /var/lib/tftpboot/ltsp/i386/pxelinux.cfg/default

For these changes to take affect, you’ll need to reboot your “thin clients” in order for them to download and use the new image.

Changed your server IP address after the initial installation of LTSP?

If after this point you change your IP address on the LTSP  server you need to update your ssh keys and rebuild your client image using the following commands (the first one updates our SSH keys and the following two are our standard “rebuild the client image” commands):

sudo ltsp-update-sshkeys
sudo ltsp-update-image
sudo sed -i 's/ipappend 2/ipappend 3/g' /var/lib/tftpboot/ltsp/i386/pxelinux.cfg/default

…then reboot your “thin clients” for the changes to take affect!

Understanding how the “thin client” devices boot

The network boot process is a two process so in order to download, decompress and boot into the i386.img (or amd64.img depending on your choice during installation) we need a network OS bootloader; so once our thin-client has got it’s IP address from our existing network DHCP server, it will then receive TFTP information from our DHCP Proxy server (provided by our new terminal server) and then load the network OS bootloader of which is provided by PXELINUX, PXELINUX is a tiny Linux-based bootloader. The “ltsp-build-client” command that we ran above created it for us under /var/lib/tftpboot/ltsp/i386/. It is approximately 20MB in size. So, the client gets this pxelinux directly over TFTP and executes it, PXELINUX then downloads the i386.img image files, decompresses it into a RAM drive, and then boots.

Configuring and hosting Laravel 5.x applications on Windows Azure

Over the past three weeks myself and a colleague have been busy (both at work and a lot of overtime at home) building a new light-weight CMS built on top of the Laravel framework, this will power a new recruitment campaign website, of which is to be hosted on the Windows Azure cloud platform (our corporate hosting strategy means moving as many sites and application to Microsoft Azure Cloud hosting as possible)

So anyway, today I had a play around with the Azure hosting platform but with the very small amount of information available on the web, it took me at-least three hours trial and error trying to get my head around how to get Laravel working on what is essentially a Windows environment of which is not something I normally deploy PHP applications/webstes to.

I worked on getting our new application automatically deployed (from BitBucket) to Windows Azure Websites (PaaS) so I thought that now would be a good time to document it, in the hope that it may help others in future.

In this guide, I’ve cloned the vanilla Laravel repository here to a private BitBucket repository just to demonstrate how the automatic deployment via. BitBucket work.

Configuring the web application instance

First thing is first, login to the Azure management portal by visiting:

Once logged in, on the left side of your browser you will see a set of icons, click on the ‘Web apps’ icon to display the list of current web applications/sites you have configured, then click on the ‘New +’ link,  a new modal window will open and enter your application details like so:

Screenshot 2015-06-26 17.50.10

Once you click on the ‘CREATE WEB APP’ button at the bottom of the window, your application instance will be created and then you’ll be taken back to the ‘WEB APPS’ dashboard where your newly created application will be listed.

The next thing we’ll do is, configure the application instance to use the latest version of PHP (5.6) at the time of writing, so click on the application name to bring up the application information section and then from the top links, click ‘CONFIGURE’.

The following screen will then be displayed, click on PHP 5.6 as shown below:

Screenshot 2015-06-26 17.52.57

Continue scrolling down this page and now add the following environment variables:

Screenshot 2015-06-26 18.52.32

By default the ‘WEBSITE_NODE_DEFAULT_VERSION’ will already be set, simply ignore this. You’ll need to (at a minimum) add the following with the values shown above in the screenshot:


You’ll find that if you fail to set the APP_KEY value to a valid 32 character encryption key (you can use php artisan key:generate command to create one if you wish!) otherwise you’ll encounter a Laravel Encryption exception as demonstrated here.

In my example above, I’ve also added APP_ENV and APP_DEBUG for testing purposes but ideally these should obviously be set appropriately in a production environment, you’ll also have a load more environmental variables that you’ll want to add here (basically the ones that you would normally place in your .env file!)

Now, we’re going to update the default applicaiton root directory; by default your application will serve the root directory from ‘site\wwwroot’, we need to change this to ‘site\public’ as per this screenshot:

Screenshot 2015-06-26 17.54.03

After adding or modifying the environmental variables and set the virtual application directory path ensure you SAVE your changes and it’s a good idea for you to ‘RESTART’ the application to ensure that these environmental variables are passed through and accessible to your Laravel application.

Adding IIS rewrite support

Out of the box Laravel provides an Apache .htaccess file that routes all requests to the public/index.php file of which is the entry point to our application and  passes all requests to the routing layer of which then dispatches the required controller requests/responses etc.

In order for Laravel to work correctly we need to now create a new file in our D:\sites\public directory (in your project you’ll want to commit this file to source control to save you having to do it manually in future), the file should be named ‘web.config’, in this file you should copy and paste the content of this GitHub Gist.

Restart your web application for the changes to take effect, you’ll now find that your application request routing works the same as it does with Apache or your Homestead development VM.

Enabling Composer support

You should already know by now that you can access your site on a sub-domain of, in this example, I can access my test site at:

In order for us to enable Composer support for our application, we need to access the Kudu management panel; to do this we simply add ‘scm‘ between our application name and the ‘’ part, so in this example, it would be:

Screenshot 2015-06-26 17.58.25

When the Kudu management panel loads, you should click on ‘Site extensions’ from the top navigation bar…

Next, click on the ‘Gallery’ tab (as at present you won’t have any installed extensions in the ‘Installed’ tab), scroll down and find ‘Composer’ and then click on blue ‘+’ button to install it.

Screenshot 2015-06-26 17.58.43

Great, now we can move on to configuring the automatic deployment of our application using Git.

We’ll come back to Kudu later as this provides us with CLI access to our hosting instance and enables us to run Composer and Artisan commands.

Configuring automatic deployment from BitBucket

From our web application dashboard, click the ‘Setup deployment from source control’ of which is situated under the ‘Integrate source control’ section as shown below.

Screenshot 2015-06-26 18.00.58

A modal window will then appear this will allow you to choose your SCM hosting provider…

Screenshot 2015-06-26 18.01.11

Click on ‘BitBucket’ and the click the next button.

Next you will have to authorise your BitBucket account and then choose your repository that you wish you deploy from, you’ll also have the option to choose the deployment branch.

For this test I’ve simply used ‘master’ but I would highly recommend using a dedicated deployment branch, in our configuration I plan to have both a ‘deploy-production’ and ‘deploy-uat’ branches of which can then be used to push-deploy once we are happy with the code state of the ‘master’ branch.

Screenshot 2015-06-26 18.01.29

Clicking on the finish button, will start an automatic deployment of your code to your application instance as shown here:

Screenshot 2015-06-26 18.01.50

Once deployment has finished the screen will change to following showing the latest commit message and author details etc.

Screenshot 2015-06-26 18.05.26

Any new code pushed to the ‘master’ branch will now trigger an automatic deployment of the code (including a “composer install”).

If you’ve deployed a clone of the vanilla Laravel codebase, you should now be able to view your site using your application URL, in this example it would be:

If you need to run database migrations however (your application is using a DB) then you’ll need to access the CLI to run those first of which we’ll cover now…

Running artisan tasks and using the CLI

Using the Debug Console in Kudu we can execute CLI commands, we can check the version of PHP that is running, run artisan console commands as well as run composer commands etc.

Let’s now jump back to the Kudu management panel (eg. and lets bring up the CLI, so just click on ‘Debug Console > CMD’ from the top navigation bar and lets run a few example commands to check that everything is working as required:

Screenshot 2015-06-26 18.06.59

Change (cd) into the ‘D:\home\site’ directory of which will then enable you to execute artisan commands and general command prompt commands (eg. copy, move etc.)

As per my screenshot above, you can type ‘php -v‘ to display the current version of PHP that is running, you can also call your artisan console commands and composer commands too as required.

That’s pretty much it….

Well hopefully this post helped you get your Laravel 5.x application hosted on Windows Azure, feel free to comment on this post and ask any questions you may have etc.

Setting up and running a server with Ubuntu Server 14.04 on Raspberry Pi 2

The RaspberryPi is something that I’ve always been interested in but never really got around to actually ordering one… until this week!

In February the RaspberryPi Foundation released the RaspberryPi 2, this models sports a quad core, 900Mhz ARM7 processor with 1GB of RAM, this is a massive improvement on the previous models so I thought, well why not order one now, they’re even more powerful and easily be able to run a web server and various other tasks relatively fast!

So this morning, my bits came and in under an hour I had assembled the Pi2 in it’s fancy case that I bought for it too, my parts list that I ordered and received are as follows:

  • 1x Raspberry Pi 2
  • 1x FLIRC case
  • 1x 5v 2A Micro-USB charger
  • 1x SanDisk Ultra 32GB MicroSD (Class 10) Card (Plus MicroSD to SD adapter)

Originally I really wanted to run FreeBSD 10.1 on it but after doing some research online currently FreeBSD is not yet compatible on the RPi2 which was a little disappointing but I knew I had my trusty Ubuntu Server instead so though, I’d use that instead!

Downloading the Ubuntu Server 14.04.2 LTS Server Image for ARMv7

You can download the Ubunu Server 14.04.2 LTS Server image that is compatible with the Raspberry Pi2 using this link.

The default username and password for this image is “ubuntu” and “ubuntu”!

Installing the image on to your MicroSD card is covered on the Raspberry Pi2 website, so instead of me repeating what they’ve already documented, see these links for copying the image to your MicroSD card:

Once you’ve formatted and copied the image to the MicroSD card (as documented in the links provided above) it’s time to insert the MicroSD card into your Pi2 and start it up…

Logging in for the first time

Once you have booted the Pi up using the Ubuntu Server 14.04 image that we flashed to the MicroSD card we should now be able to login, the default username and password is: ubuntu / ubuntu

It’s now a good idea to change this password, to do that type:


Then enter your new password!

I’ve personally, set a new ‘root’ password and created a new user account and deleted the old ‘ubuntu’ account as a safety precaution, I recommend you do the same really!

Install NTP Client

The Raspberry Pi/Pi2 does not have a realtime clock therefore unless using NTP and having it updated on boot-up the RaspberryPi2 will start it’s clock from Jan 1st 1970 each time, to avoid this I’ll now install the NTP (Network Time Protocol) client to ensure that each time the Pi boot’s up that it connects to web to set it’s time automatically…

sudo apt-get install ntp

You will also find that by default the Ubuntu Server image that we are using is set to use UTC (Universal Time Coordination), I’m now going to set this to my actual timezone (BST), so to do that run the following command to reconfigure your server’s current timezone:

sudo dkpg-reconfigure tzdata

Now once you’ve set the new timezone, test and ensure that the correct date shows when you run


Excellent stuff… lets move on!

Installing OpenSSH server

Ideally, we want to run the Pi without a keyboard, mouse or monitor. There is no need for me to keep a keyboard and mouse attached as all configuration can be done remotely using SSH.

I plan to run the RPi2 completely headless and the only two cables being connected is the Power and Ethernet!

So to do this, we’ll install OpenSSH server like so:

sudo apt-get install openssh-server

Although I don’t recommend it, if you want to enable ‘root’ user logins over SSH then you should edit the SSH server configuration file here: /etc/ssh/sshd_config.

Installing some useful tools

Personally I like using htop, htop provides a nice display of running processes and memory utilisation, you can install it like so:

sudo apt-get install htop

Expanding the available disk space

The image size that we’re using is configured for a 4GB flash card, if you are using a card larger than 4GB like myself, it is a good idea to expand the partition sizes so we can utilise the entire card, luckily this can be easily achieved by following these simple steps:

sudo fdisk /dev/mmcblk0

You’ll then be presented with a ‘Command’ prompt, press the following keystrokes in order to delete the second partition:

  1. d
  2. 2

Now you need to re-create it like so, by recreating it, it will then use all the available space, so now press the following keystrokes a the ‘Command’ prompt

  1. n
  2. p
  3. 2
  4. [enter]
  5. [enter]

Finally to save and write the changes to disk and then exit out of the fdisk tool you must now press the follow key at the ‘Command’ prompt

  1. w

Great stuff, we’re done with fdisk now!

Now quickly reboot the Pi using this command:

sudo shutdown -r now

Once logged back on, we need to complete the resize of the partition by running this command:

sudo resize2fs /dev/mmcblk0p2

Adding SWAP space

The image is not setup with an SWAP space, if you would like to add some you can install a cool tool that will automatically configure a default SWAP space for you (~2GB by default but you can change if you wish).

To install like I did, run the following command:

sudo apt-get install dphys-swapfile

Woohoo, you are now ready to install whatever server software your require, I won’t cover installing a web server here as I’ve already covered this in some of my other blog posts and will be the same regardless of running a Raspberry Pi2!

Set-up your own MineCraft server on FreeBSD 10.1

My daughter (Ruby) has been bugging me to get her MineCraft and so I thought I’d set her up with her own server that we could both play on together so I thought I’d compile this blog post as a quick tutorial on how to set up a MineCraft server on FreeBSD 10.1, hopefully others will find this tutorial will useful and easy to follow!

If you don’t already have a server, you can go rent one from DigitalOcean, they’re $5 a month and I could not recommend them enough, the server’s from DigitalOcean all come with SSD’s as standard and run Minecraft servers perfectly! If you need one, go get one now and then carry on with this tutorial!

Installing the server

Firstly ensure that you have a FreeBSD 10.1 server setup and ready to go, lets
first setup a couple of packages that we will need:

pkg install screen nano wget

Next we’ll install the OpenJDK, you may wish to use the Oracle JDK but I’m not
covering that in this post, so lets install the OpenJDK like so:

pkg install java/openjdk7

Fantastic! – Lets just check that it is installed correctly by checking the version
number like so:

java -version

As long as you see some OpenJDK Runtime information then it’s looking good, we can move on!

Lets now download MineCraft to our server and put it into a seperate directory
in case we wish to run more than one game server on our server 🙂

cd ~
mkdir minecraft_server_1
cd minecraft_server_1
wget --no-check-certificate

So now we have a folder in our home directory called ‘minecraft_server_1’ and in their we have the main Minecraft server application.

Now we have to accept the EULA, simply run this command to ‘accept’ it

echo "eula=true" > eula.txt

Now we create the main start-up script for this server, run this:

echo "java -Xmx1024M -Xms1024M -jar minecraft_server.1.8.4.jar nogui" >

Now we’ll create a new user on the server named ‘minecraft’ this user will be used for running all our Minecraft server instances, create the new user using this command:

adduser minecraft

Then lets update the file ownership like so:

chown -R minecraft:minecraft .

You can now start your server by running:

screen su -m minecraft -c "sh"

If you wish to run multiple servers, you can add a server-port=XXXX setting to the file to enable you to run multiple game servers on the save physical server.

Congratulation, you should now be able to access your new Minecraft server running on the awesomely stable FreeBSD OS!

Using Supervisor to automatically start and keep your MineCraft server running

I noticed after a couple of days that every now and again the MineCraft server was crashing whilst no one was connected to it and mean’t that I had to log into the server via. SSH and re-start it.

I’ve used Supervisord in the past and seems like a good idea in this sitaution also, the result will be that if the server reboots or the game server crashes Supervisor will restart the Minecraft server for us automatically…

So lets install it now:

sudo pkg install py27-supervisor

Now we need to enable it by adding it to the rc.conf file, do it using the following command:

sudo sh -c 'echo supervisord_enable=\"YES\" >> /etc/rc.conf'

Now we have to add our Minecraft server configuration to the supervisor.conf file so that Supervisor knows what it needs to execute and handle the task etc.

So, edit /usr/local/etc/supervisord.conf and add the following content (obviously make path changes as required):

command=/usr/local/openjdk7/bin/java -Xmx1024M -Xms1024M -jar minecraft_server.1.8.4.jar nogui

Now lets just create our supervisor logs directory like so:

mkdir -p /root/supervisor_logs/minecraft_server_1/

Excellent, now lets start the service like so:

service supervisord start

That’s great, your Minecraft server should now be running and is managed via. Supervisor!

So in future you can check the status of your Minecraft server(s) using supervisorctl tool like so:


You can start, stop and restart your Minecraft servers using:

stop minecraft_server_1
start minecraft_server_1
restart minecraft_server_1

Have fun and hope this was helpful!