Fixing a problem with VMware vcloud when putting a Virtual Machine back into the cloud Catalog

If you use vcloud, then I'm sure you have pushed fully patched and configured virtual machines back into the catalog as gold masters many times. If you have customised scripts, then you may or may not have come across this problem.

However yesterday, I came across a problem where the custom script settings within vcloud version 5.5 were not working, and the init scripts were not be run when you created a new vapp. This is a setting that tells the VM, if they have been run or not

It turns out the code for pushing VM's back into the catalog was not resetting the static file needed, to tell the init scripts to run correctly. If you look in .customisation in roots home directory, you can see the file it is looking for.

So , the work around - after much digging around in the code to find the file that VMware tools were looking for - is as follows

On a Linux system just type the following.

touch /.guest-customisation-post-reboot-pending

Once this file is in place, shutdown your VM, copy it back to the catalog, and all will be fine on the next start - it will run your desired init scripts as you wanted in the first place ;-)

Hope this saves you some time.

Using an External Node Classifier in a masterless configuration with Puppet

I use standalone puppet a lot for managing my own machines and cloud servers, but the site.pp file was starting to grow large and it became obvious the solution was to use an external node classifier or ENC.

There is lots of documentation on the web on how to do this with a puppet master/ agent configuration, but nothing I could find on how to do this.

The key change is where you specify the change of node class information in the puppet.conf file. If you follow the puppetlabs documents , it won't work. If however you put the new ENC definition into the [main] section , it works just fine. Only a minor change , but it will not work unless you do.

The code you need looks like this:


node_terminus = exec
external_nodes = /usr/local/bin/node_classifier.py

The node classifier can be whatever you want, but I used python just to get it up and running quickly for testing.


I hope this saves someone hours of hunting around to get this sorted.

During my research , I have also found that it should be possible in the latest releases to use Hiera as your ENC to generate the YAML required. Next on my list to try.

Link to Puppet Labs ENC documentation

Using Hiera as your ENC

The power and felixibility of OpenSSH tunneling in the cloud

If you didn't realise it, the secure shell that is used every day, all over the internet is written and managed by the OpenBSD project team, and we all owe them a huge debt of thanks for their efforts. It lets us communicate securely with our servers and other devices.

Well, one of the great features of ssh , is the ability to set up tunnels , that you can use to connect traffic across , and indeed reverse tunnels which can be very useful for connecting to remote servers.

As this tool has become so ubiquitous, there are other tools that have been built around it, and some examples of these are autossh, which allows you keep a tunnel monitored and open for when you need it. Also corkscrew , which allows you to connect to remote hosts by encapsulating you traffic in https packets, thus cutting holes through proxies.

When these are combined you have the ability to connect to remote hosts, hidden behind corporate firewalls and proxies, so that you can get some work done.

Here is an example. I have a servers than can connect to all the internal network, but you can't get to this server externally, but is has access to a proxy.

Firstly you set up it's ssh config file so that it can talk through the proxy, and then you create a reverse tunnel to a machine in the cloud. You then use autossh to manage that link, so that when you need to use it , it is available.

There are so many variables in this that covering them all is not feasible, but here is an example:

First, make sure that the ssh public keys for both servers have been put into the authorized_keys file in .ssh on the other machines. Swap public keys, in other words.

Configure you .ssh/config for the user to include the following parameters
TCPKeepAlive yes
ServerAliveInterval 270
ProxyCommand /usr/bin/corkscrew 192.168.2.1 8080 %h %p

Where 192.168.2.1 is the IP of your proxy and 8080 is the port it listens on

So when we make the connection to the cloud servers, it will use this encapsulation.

Now we create the tunnel

/usr/bin/autossh -M 29001 -f -nN -R 1102:localhost:10000 billblogs@cloud01.tangerine.co.uk

Ok, lets break the command down
autossh uses -M to specify it's keep alive port, and -f to place the job in the background.

ssh uses the -nN and -R to say this is going to be a reverse tunnel, and on the cloud server it will open port 1102 and connect it to port 10000 on the internal server running the ssh daemon that we start this job from. In other words, the sshd daemon on the internal server is listening on port 10000.

So, once this is all configured, you can go to your cloud server, connect on port 1102, and it will be as if you were sat at your desk, voila

Here is the command you would use to connect:

ssh -p 1102 billbloggs@localhost

NB You need to make these connections as secure as possible, and disable root logins and only allow keys.