Friday, 20 December 2013

Windows - Automatic VPN dialer Batch script

Sometimes I need to work on several customers or environments at the same time. This means that sometimes I need to have several (Windows) VPN connections open at the same time or I need to connect and disconnect from them several times a day.

In order to simplify the process and to enable me to keep my network settings mostly undisturbed when I connect to VPNs I have created a simple batch file to allow me to quickly connect to a VPN and set the appropriate routes.

The batch file is available here: vpn_dialer_template.bat

Usually when you connect to a VPN you lose your default gateway and become unable to access your local resources. This can be avoided by configuring the connection not to use the VPN gateway, but this comes with a cost: you have to manually set the required routes yourself.

In order to make this process simpler and quicker I came up with a batch file that makes the VPN connection and set the routes all by itself. However, It has some "requirements": I only tested it on Windows 7, although it should work on Vista and Windows 8; it has to be run as Administrator since setting the routes requires privilege escalation; to make it effective you have to disable the "use default gateway" option on the VPN connection this implies you have to know the remote gateway address and other routes that you also need.

I'll guide you through the process of deactivating the remote gateway option:

First goto "Network and Sharing Center". Next, choose the "Change Adapter Settings" option on the left. Then right-click on the VPN connection and choose "Properties"

Then select the Networking tab.

In the Networking tab, select "Internet Protocol Version 4" and then click on Properties:

Click Advanced:

Uncheck the option: "Use default gateway on remote network" and click OK->OK->OK.

Now the VPN Connection is ready to use with the batch file.
Of course, you can also use this trick on your own.

Next I'll explain how the batch file is used.

You can configure your setting in the USER VARIABLES section in the beginning of the file:
REM **************************************
REM **************************************

REM If you do not use a Domain then set VPNDOMAIN to empty: SET VPNDOMAIN=

REM EXAMPLE: ROUTE1=route add mask

REM **************************************

You need to change the VPNNAME to the name you gave your VPN.
The VPNUSER, VPNPASS are the username and password used to connect to the VPN. If you have an issue with having the plain-text password in a file then you should placed it in an encrypted folder (that works for me).

The VPNDOMAIN is optional and you only need to set it if the VPN connection requires it. Otherwise simply leave it empty.

By default you can configure the script to add up to 5 routes (more than enough for my needs).
But you can add more with a simple tuning of the file.

The ROUTE# variables need to contain the actual route command used to add the route.
For example:
SET ROUTE1=route add mask

(See the syntax of the route command for further explanations).

The batch file works as follows:
1 - Connect the VPN with the credentials supplied in the USER VARIABLES section.
2 - If the connection is successful then loop trough all the connections to check for the interface id. This only work properly on more recent versions of Windows as I mentioned earlier. Windows XP for instance uses an hexadecimal notion for the interface ID which totally messes things up.
3 - Go through the ROUTE# variables, add the interface id to the route command and set the route.
4 - Pause until user presses a key.

The batch file doesn't disconnect the VPN automatically, but if you take a look at it you can see this option is commented out since I was accidently pressing a key and sending the VPN connection down too often. :D

In the (unlikely) case you need to add more routes you can add another ROUTE# variable and then duplicate on the "Set route" sections on the last part of the file:

echo . 
if defined ROUTE# (
    set CMD=%ROUTE#% if %IFNUMBER%
        echo Error Setting %ROUTE#%!
        goto :disconnect

Just replace the 3 references to the ROUTE# variable with your one variable.

Hope you find this useful!

Tuesday, 17 December 2013

Linux (RHEL) - Simple application watchdog script (aka how to make an application automatically restart)

In order to make sure some of applications are running non-stop and required no human intervention to be restarted in case of failures we usually really on a cluster infrastructure (in our case Red Hat Cluster Suite). This works great when you have the hardware to run it but sometimes we also need to make sure we have this behaviour on a standalone machine.

This is accomplished by using a watchdog script that mimics the behaviour of the cluster (in regards to application monitoring).

In the new Red Hat EL versions (>6.0) a similar effect can be achieved with upstart respawn option. But the watchdog script has some advantages since it allows for a bit more fine-tuning. Besides, I'm still stuck on RHEL 5 which has no upstart, only sysvinit.

To make implementation and deployment fast and easy I have a template script which enables me to add monitoring to a script/service in a couple of minutes.

The template script can be downloaded here:

I'll try to explain how it works:

First, you must replaces all instances of the text: <app> with the name of the script/service you are trying to monitor.

This can quickly be done in vi with:

Press ESC (to enter command mode)


(myapp is your script/service name :-) )
Press Enter

Next you need to alter the settings in the script:
#APP specific Configurations
INTERVAL=30     #Interval between status checks
LOCKFILE=/var/run/<app>.pid #monitor app if this files exists.

INTERVAL is the number of seconds between each status check

LOCKFILE is a file which is used to start the monitor cycle, usually it can be the application's pidfile ou lockfile or anything you want, just make sure it only exists when your application should be running.

SERVICE_SCRIPT is the complete path to the script that is used to monitor the application.

SYSLOGNAME is the tag name that is send to syslog. This makes it easy to see what the watchdog's actions in the system's logs.

The main action happens in the monitor function, which I'll explain below:

   #infinite loop until stop is called
   while [ 1 -eq 1 ]
      #no restarting if there is no pidfile, this ensures there are no unsolicited restarts
      #it also means that the application must delete its pidfile when stop is called.
      if [ -f $PIDFILE ]
         $SERVICE_SCRIPT status 2>&1 >/dev/null
         if [ $STATUS -gt 0 ]
            logger -t $SYSLOGNAME "Status returned ERROR!"
      sleep $INTERVAL

First it enters an infinite loop which checks the app at $INTERVAL seconds.

The monitoring is only done if it finds the LOCKFILE, this ensures it only restarts the application if it is supposed to be running.  This also implies the application's script needs to remove the LOCKFILE when it stops. If the LOCKFILE is not removed once the application is stopped the watchdog will continue to check the script status which could lead to a restart loop.

The watchdog relies on the service/script status exit code to verify if a restart is required.

By default, if the status returns a value other than 0 then the script/service is restarted. This also sends messages through syslog so you can debug later.

You can configure this loop to do whatever you want based on the status return value. :-)

Friday, 13 December 2013

Squeezeplay 7.8 compiled for Raspberry Pi

For my upcoming Raspberry PI project, an Internet Radio with built-in speakers, I had to compile the Logitech Squeezeplay (aka jive) player for the Raspberry Pi.

I followed several instruction and eventually got it to compile. It was very tricky....
I started with the information from slimdevices wiki and started the compilation process.

The compile process takes a long time on the pi (over 10 hours) and along the way there were several errors that needed to be addressed. I googled most of the errors so anyone should be able to overcome the difficulties in the compilation process.

Since this was cumbersome and painful to complete,  I'm making the compiled version available for anyone to use.

You can download it here. It's compiled for the Raspbian Wheezy.
I used the version from SVN so it should be mostly up to date.

If you also need squeezecenter you can use the version provided by Logitech, the ARM version works fine in the Pi.
You can run Squeezecenter and squeezeplay on the same Pi, but it can be a bit slow to start, at least on my version A Pi (only 256MB RAM).

I've also purchased a LCD module and I'm planning on using it to display the Jive app which will basically turn the Pi into a DIY Logitech Touch.

There are other options for this, namely SoftSqueeze (get it from here) which is Java based and squeezeslave (from here) which is a command line version (which can also be used with a char LCD).
Now all I need is a DAC, some speakers and I'll be ready to go...

Hope you find it useful!

Wednesday, 11 December 2013

Red Hat Cluster Suite fence agent for HP C7000 enclosure

Some of the projects I've worked on used the C7000 blade enclosure from HP.

It's a neat solution to implement clustering since it has almost all of the required hardware in one package.

Our software also uses Red Hat Enterprise Linux 5 (RHEL5)  and Red Hat Cluster Suite.
The system seemed to work properly but there were some issues with the fencing.

We were using the iLO of the Blades servers for fencing nodes. Everything works fine until you pull out one node... Since the iLO port is no longer active and neither is the server the cluster stops and goes into a loop trying to fence the node. From this point on nothing works until you do a fence_ack_manual...
A similar situation as also occurred when one of the nodes suddenly died, by this I mean it had a complete hardware failure and it stopped responding. This hardware fault also affected the iLO port and so the cluster went into a fencing failed loop...

In order to solve this problem a new fencing level must be added that uses the C7000.
When fencing through the iLO port fails the cluster must try to do a fence through the enclosure management (OnBoard Administrator).
To make this work a new fence agent was added.

I modified the fence script for a IBM Bladecenter (/sbin/fence_bladecenter) so it works with the C7000 enclosure, the configuration in the cluster.conf is the same as with the IBM Bladecenter except that for the agent property:

<fencedevice agent="fence_c7000" ipaddr="" login="Administrator" name="HP_C7000_OA_P" passwd="passwd"/>

the fence level configuration can be set as:

<clusternode name="node1" nodeid="1" votes="1">
<method name="1">
<device name="node1_ilo" action="off"/>
<device name="node1_ilo" action="on"/>
<method name="2">
<device blade="1" name="HP_C7000_OA_P"/>

This enables the cluster to fence through the iLo port first and then try the Onboard Administrator, in this case it would power cycle the blade in slot 1 (blade="1").

You can get the fence script here: fence_c7000

To get this to work you need to place the script in the /sbin directory and give it execute permissions:

chmod 0755 /sbin/fence_c7000

Then it's just a matter of configuring the cluster.conf with the examples above.

Hope this helps!