Tag Archives: How-Tos

The Anatomy of a vBlog Part 1: Building a Blogging Platform

Earlier this week my good friend Matt Crape sent out a Tweet lamenting the fact that he was having issues uploading media to WordPress…shortly after that tweet went out Matt wasn’t short of Twitter and Slack vCommunity advice (follow the Twitter conversation below) and there where a number of options presented to Matt on how best to host his blogging site Matt That IT Guy.

Over the years I have seen that same question of “which platform is best” pop up a fair bit and thought it a perfect opportunity to dissect the anatomy of Virtualization is Life!. The answer to the specific question as to which blogging platform is best doesn’t have a wrong or right answer and like most things in life the platform that you use to host your blog is dependent on your own requirements and resources. For me, I’ve always believed in eating my own dog food and I’ve always liked total end to end control of sites that I run. So while, what I’m about to talk about worked for me…you might like to look at alternative options but feel free to borrow on my example as I do feel it gives bloggers full flexibility and control.

Brief History:

Virtualization is Life! started out as Hosting is Life! back in April of 2012 and I choose WordPress at the time mainly due to it’s relatively simple installation and ease of use. The site was hosted on a Windows Hosting Platform that I had built at Anittel, utilizing WebsitePanel on IIS7.5, running FastCGI to serve the PHP content. Server backend was hosted on a VMware ESX Cluster out of the Anittel Sydney Zones. The cost of running this site was approximately $10 US per month.

Tip: At this stage the site was effectively on a shared hosting platform which is a great way to start off as the costs should be low and maintenance and uptime should be included in the hosters SLA.

Migration to Zettagrid:

When I started at Zettagrid, I had a whole new class of virtual infrastructure at my hands and decided to migrate the blog to one of Zettagrid’s Virtual DataCenter products where I provisioned a vCloud Director vDC and created a vApp with a fresh Ubuntu VM inside. The migration from a Windows based system to Linux went smoother than I thought and I only had a few issues with some character maps after restoring the folder structure and database.

The VM it’s self is configured with the following hardware specs:

  • 2 vCPU (5GHz)
  • 4GB vRAM
  • 20GB Storage

As you can see above the actual usage pulled from vCloud Director shows you how little resource a VM with a single WordPress instance uses. That storage number actually represents the expanded size of a thin provisioned disk…actual used on the file system is less than 3GB, and that is with four and a half years and about 290 posts worth of media and database content  I’ll go through site optimizations in Part 2, but in reality the amount of resources required to get you started is small…though you have to consider the occasional burst in traffic and work in a buffer as I have done with my VM above.

The cost of running this Virtual Datacenter in Zettagrid is approx $120 US per month.

TipEven though I am using a vCloud Director vDC, given the small resource requirements initially needed a VPS or instance based service might be a better bet. Azure/AWS/Google all offer instance based VM instances, but a better bet might be a more boutique provider like DigitalOcean.

Networking and Security:

From a networking point of view I use the vShield/NSX Edge that is part of vCloud Director as my Gateway device. This handles all my DHCP, NAT and Firewall rules and is able to handle the site traffic with ease. If you want to look at what capabilities the vShield/NSX Edges can do, check out my NSX Edge vs vShield Series. Both the basic vShield Edges and NSX Edges have decent Load Balancing features that can be used in high availability situations if required.

As shown below I configured the Gateway rules from the Zettagrid MyAccount Page but could have used the vCloud Director UI. For a WordPress site, the following services should be configured at a minimum.

  • Web (HTTP)
  • Secure Web (HTTPS)
  • FTP (Locked down to only accept connections from specific IPs)
  • SSH (Locked down to only accept connections from specific IPs)

OS and Web Platform Details:

As mentioned above I choose Ubuntu as my OS of choice to run Wordpress though any Linux flavour would have done the trick. Choosing Linux over Windows obviously means you save on the Microsoft SPLA costs associated with hosting a Windows based OS…the savings should be around $20-$50 US a month right there. A Linux distro is a personal choice so as long as you can install the following modules it doesn’t really matter which one you use.

  • SSH
  • PHP
  • MySQL
  • Apache
  • HTOP

The only thing I would suggest is that you use a long term support distro as you don’t want to be stuck on a build that can’t be upgraded or patched to protect against vulnerability and exploits. Essentially I am running a traditional LAMP stack, which is Linux, Apache, MySQL and PHP built on a minimal install of Ubuntu with only SSH enabled. The upkeep and management of the OS and LAMP stack is not much and I would estimate that I have spent about five to ten hours a year since deploying the original server dealing with updates and maintenance. Apache as a web server still performs well enough for a single blog site, though I know many that made the switch to NGINX and use the LEMP Stack.

The last package on this list is a personal favorite of mine…HTOP is an interactive process viewer for Unix systems that can be installed with a quick apt-get install htop command. As shown below it has a detailed interface and is much better than trying to work through standard top.

TipIf you don’t want to deal with installing the OS or installing and configuring the LAMP packages, you can download a number of ready made appliances that contain the LAMP stack. Turnkey Linux offers a number of appliances that can be deployed in OVA format and have a ready made LAMP appliance as well as a ready made WordPress appliance.

That covers off the hosting and platform components of this blog…In Part 2 I will go through my WordPress install in a little more detail and look at themes and plugins as well as talk about how best to optimize a blogging site with the help of free caching and geo-distribution platforms.

References and Guides:




How-To: vCloud Director and Log Insight

Recently v2.0 of VMware Log Insight became GA, and I’ve been playing around with it since it’s release. Having been on the BETA of the 1.5 Version the 2.0 Version is streets ahead in terms of usability and completeness. Living day in and day out within vCloud Director I decided to look at hooking up the vCloud Cell Logs to Log Insight and create a basic Dash Board to assist us in working through vCD logs.

First up you need to SSH into your vCloud Cell and head to:

From there you want to edit the log4j.properties file. Probably worth making a backup of the file before the edit. Go to the bottom of the file and append the following, making sure to substitute the xxx.xxx.xxx.xxx on the second line below with the IP or hostname of your Log Insight Server.

You can see that we can control the level of logging being sent through to Log Insight by editing that last line and changing the threshold to WARN or CRITICAL. Once that section has been added, head back to the top of the file and modify line 2 as shown below

What we are doing there is adding the source we just configured in the first step. Save the file and restart the vmware-vcd service

Load up the Log Insight Web GUI and go to the Interactive Analytics Page. If you hit search a couple of times you should start seeing vCloud Director related entries appear in the Events pane.

Click on the Add Filter Icon and sort by Source -> Contains and Enter in the host name of the vCloud Cell. Depending on the amount of hosts you are logging the Cell may appear in the list as you click into the search box. Hit the Search button and you will see your filtered log entries in the events pane. To make for easier reading, I choose the Field Tab which makes reading the entries a little easier.


Finally we can create a basic Custom Dashboard to view cell log numbers over time. With the above Filter in play, click on the Add to Dashboard icon which is on the right hand side of the search button and give a name relating to the Cell. In the example below I already have a Dashboard created so it appears in the drop down list…otherwise you can create a new one from this window.


After clicking on Add you can go back to the Log Insight Dash Boards to view your creation.


Again, its a very basic display literally showing you the number of events in a period of time, however the usefulness here is that if you have to search for an event you can drill down and perform an Interactive Analysis with a little more accuracy.

Watch out for more Content Packs to Come out for Log Insight…the library will only grow and give more value add to this tool.

How To: DELL DSET Report Tool Live CD and Linux VLAN Config

Here is a quick post on generating support logs for DELL cases if you are running VMware ESX(i) on any of the DELL server hardware. I had a CPU alert appear in my vSphere Hardware status and raised a support ticket with DELL. Previously I’ve had to wrestle with the config/setup of the DSET tool on ESX(i) and even had it cause a boot up failures due to a comparability bug.

The Dell tech send me the link below which is a CENTOS LiveCD which can be downloaded and booted up on the server in question.


Once downloaded and attached via the iDRAC Virtual Media Manager you will automatically go through to the desktop where you can double click on the DSET Tool Icon. Let it do it’s thing and gather all the relevant info which is then packaged into a zip file under \tmp\data\

Ok, so now that you have the file…how do you get it off the LiveCD instance? The answer would be simple if you had interfaces configured with DHCP, but the majority of these servers are configured with NICs on VLAN enabled ports which are not easily switched over or able to be reconfigured without going through change management etc etc.

The Network Configuration GUI in CENTOS doesn’t have the ability to configure VLAN tagging on the interfaces so you need to jump into the shell and manually configure the network settings as shown below.

Create a new config file for eth0 and configure it as shown below…key here is to take note of the MAC Address, no include and IP or Subnet details and I disabled IPv6.

Once saved, copy that file and save to ifcfg-eth0.x where is is the VLAN you want the interface to communicate in. This time you are adding relevent IP info along with specifying the device name as eth0.x and VLAN=yes which obviously enabled the VLAN tag config.

Fire up the new interfaces and restart network and you have a VLAN enabled connection that you can now grab the DSET zip file off and send to DELL for analysis.

As a side note, being the good VMware fanboy that I am, I used my Octopus Beta service to upload the file and make it available via the Octopus URL for sharing…because getting access to the Horizon Suite BETA is currently near on impossible 🙂

How-To: Citrix NetScaler GeoIP Restrictions

I had a request from a Hosting Client this week to look at options around blocking malicious users from causing trouble on a local Auction site. As the site was only for Australian and New Zealand users we needed to come up with a solution to block the whole world except AU and NZ visitors. Obviously I know there are mechanisms in existence that have annoyed me in the past while trying to source overseas content and getting the message telling you that you can’t access this site in your region.

I’ve never personally had to act on a request like this, and thought about options relating to some sort of code based filtering or filtering at the gateway level. I’ve known that in real terms I haven’t even scratched the surface of what our Citrix NetScaler VPX’s can do, and with that I searched for some guidelines on getting up GeoIP Responder rules at the Load Balancer’s Virtual Server level. Not being able to find anything definitive end to end, here are the steps I took to achieve the end result.

Citirx NetScaler ArticleHow to Block Access to a Site by Country using a Location Database

First step is to enable the Responder Feature is it’s not already enabled. Citrix suggest you disable any feature not in use to save on system resources.


In order for the NetScaler to work our what location a visitor is coming from it needs to reference a GeoIP database. MaxMind offer a free database from here: These are updated on the first Tuesday of everymonth, so a little upkeep is required moving forward. There are IPv4/6 versions as well as an extended database City version which lets you get very granular in terms of allowing city access. For this exercise we will use the GeoIPCountryWhois CSV database.

Jump into the shell of the NetScaler and create a new directory. Note that if you have a HA setup, you need to do this on each NetScaler node.

Use SCP to upload the CSV database to that location just created on the NetScaler and then run the following command to import the location parameters. Once done you can query the location database to ensure you have  imported the CSV line items.

Now that you have the GeoIP location locked and loaded, you can created the Responder Policy. I had a little trouble trying to work out how to structure the rule to work correctly limiting visitors to only .AU and .NZ. I’ll be honest here and admit that trial and error was the winner here, but eventually I came up with the following that works.

Reading through the policy it’s easy enough to see what’s going on…this page references the Location Database General Information and formats, however it’s confusing at best..my advice is for Country Based GeoIP use the above as a template and simply change the country codes to suit.

Back to the GUI of the NetScaler and under Load Balancing settings of the Virtual Server(s) in question, open the Virtual Server for editing and go to the Policies Tab -> Click on the Responder sub tab and right click to Insert Policy and the end result will be similar to what’s shown below.


I was able to use Twitter contacts with servers in global locations to test out the rule which was behaving exactly as expected. If you go back to the Policy menu item under Responder and check the Responder Policies you will be able to see if the rule is active and how many hits the rule has triggered.


The default action of the policy is to DROP or RESET the connection. You do have the option of creating a custom REDIRECT rule that will allow you to make the end user a little nicer in terms of presenting the user with a HTML page letting them know the page is restricted ..with the DROP and REST the browser simply shows a page not found or connection reset. I’ll update this post once i’ve created the REDIRECT rule.

Update: Turns out that if you apply the above rule it’s not that great for Google Analytics and the bots that hit your site. If you want to get the GoogleBot User Agent through the rule, create a rule similar to below

Looking at that additional condition  you are looking in the HTTP Request Header, ignoring case and matching Googlebot.

How To: Setting Up Nagios User for ESXi

Unless my Google skills are seriously on the decline I wasn’t able to find a definitive post on correctly setting up a nagios user to facilitate esx_checks for monitoring systems such as OpsView and similar Nagios based systems.

For our ESXi monitoring we have chosen to use the OS – vSphere Service Checks. Post here on how to get the OpsView side going. Having a look at the checks in OpsView you see the following checks are used


Our current ESXi 4.1 hosts where working a treat, and this being my first time adding new hosts to the monitoring set, I was confronted with the following errors via Nagstamon:


So, to get the reporting up the following actions need to be taken on the ESXi host.

  • Log into the host directly with the VI Client
  • Go to the Local Users & Groups Tab
  • Add/Modify the nagios user and set the password
  • Add the user to the users group and click ok
  • On the Permissions tab and Add a new permission for the nagios user as Read-Only.



If you want you can run the commands to test access directly from the cli of the OpsView system.

Alerts are gone and we are good to move onto the next job…finally!

How-To: vCenter 5.1 SSO Adding AD Identity Source

The SSO Component of vCenter 5.1 throws a couple of spanners in the works with regards to a straight forward upgrade of an existing vCenter install. While not overly complicated in terms of understanding what and how the SSO Service fits into the 5.1 puzzle, I found that it did add a couple of additional configuration steps that where not expected during and after the upgrade process. There are a heap of resources out there already on the end to end install of the SSO…be it a Simple Server install or a multi-server HA set-up, but your best bet is to catch up on the official VMware Documentation here.

EDIT: @VMwareKB vSphere Blog SSO Help Page http://t.co/9y20Kk22

In my environment we already employed AD authentication by way of Group Membership that dictated access to the vSphere Datacenters and Clusters. This was well established and working without too much hassle. My first attempt at the vCenter 5.1 upgrade yielded mixed results with the SSO, but lesson learnt was that I made the mistake of being too eager to jump into the upgrade without RTFM!

What I am now calling an exercise in executing a roll-back plan came about because I didn’t bother to understand how the SSO component affects an existing set-up and also from not paying attention during the install. In truth, I thought the first upgrade failed to install SSO correctly as I was getting errors when trying to login and the Web Client wasn’t able to connect to the SSO service. Couple of points here is that I rushed through the “Error 29155 Identity source discovery error” which is referenced by KB 2034374 and I attempted to “fix” the service by messing with the SSO Service Log-on user configuration. In the end I got impatient and rolled back the vCenter SnapShot I had taken before upgrade and started again. (Side note: that actually worked ok even after 5.1 agents where deployed to hosts managed by the vCenter…after rolling back the snap the 5.0 agent’s where re-redeployed without hassle)

So, once 5.1 had been installed and all components have been upgraded, you need to add your AD LDAP profile as an Identity Source via the vCenter Web Client. Without this, your existing AD credentials will not be honoured.

Log into the vCenter Web Client with the credentials provided during setup:


Click through Administration -> Sign-On and Discovery -> Configuration and click on the green + Button in the centre window pane.


Collect all your relevant AD LDAP information and complete the set-up as shown below.


If all the settings are correct you will get a positive Test Connection response.


Now that you have your Identity Source configured you can add the new source to the default domains by clicking Add to default domains in the top bar and bump the new source to the top of the list in the bottom pane. This allows you to not have to enter the NETBIOS name of the domain during login. eg DOMAN\username vs username.

Final thing to check now is to ensure that your previous Permissions based on AD groups are still in place relative to the vCenter, Datacenters, Clusters etc. As shown below, from this point forward you can configure access as you would have previously…the only change now is you have the option of selecting the Domain to reference.


What this means, is in theory you could pull in external/client LDAP Identity Sources to use as authentication mechanisms on your vCenter…not sure it’s totally useful for vCenter’s, but can see this being extremely useful for management and automation layers like vCloud and vCOPs or even vCO.

Load Balancer Internal IP’s Appearing in IIS/Apache Logs: Quick Fix

If you are NAT’ing public to private addresses with a load balancer in between your web server and your Gateway/FireWall device you might come across the situation where the IIS/Apache logs report the IP of the Load Balancer, when what you really want, is the client IP.

It’s obvious that the biggest issue with this is that any Log Parser/Analytic’s you do against the site will all be relative to the IP of the load balancer. All useful client and geographical information is lost.

Most Load Balancer’s get around this by inserting a Header into the packet that relates to Client IP. In most cases that I have seen, both Juniper and NetScalers the Header is set to rlnclientipaddr.

What needs to be done at the web server configuration level to help pick up on and translate the header info so it can be used to translate the correct client IP into the log files. There are obviously different way to achieve this in Apache, compared to IIS and Apache has a much simply solution than IIS.


In your apache.conf go to the LogFormat sections and modify the default format as shown below (Replace the Red text with the green text) and restart the Apache Service.


The IIS 5/6/7/8 solution is a little more involved, but still just as efficient and not overly complicated at the end of the day…in fact for me the hardest part was actually chasing up the DLL’s linked below. It must be noted that while this has worked perfectly for me against both a Juniper DX and NetScaler VPX load balancer I would suggest testing the solution before putting it into production. Reason being is that the ISAPI filters are specifically sourced for the Juniper DX series, but in my testing I found that they worked for the NetScalers as well. Sourcing the x64 DLL’s was a mission, so in this I am saving you a great deal of time by provided the files below.


Download and extract those files into your Windows root. Go to the Features View -> ISAPI Filters and Click on Add. Enter in the Name and Executable Location and click ok. Note that it’s handy to add both 32 and 64 bit version to a 64bit IIS Web Server just in case you are dealing with legacy Application that are required to run in 32bit mode. Adding the ISAPI Filter at the root config of the Web Server so it propagates down to all existing sites and any newly created sites.


vCenter Operations Manager 5 – UI Time-out Settings

A little after vCenter Operations Manager 5.0 went GA I posted this forum thread in regards to the default time-out value of the Web UI…Thanks to ILIO and VEIgel for follow-up posts with the initial solution, which at this time wasn’t documented. This is now covered in the release notes for 5.0.1 under known issues. But for those who haven’t read through the issues see the below to adjust the UI Time-out on vCOPS 5.0 (and now 5.0.1). The default time-out value is 30 minutes.

To change the default timeout value in the vSphere UI in the vApp:

  1. On the UI VM, edit /usr/lib/vmware-vcops/tomcat/webapps/vcops-vsphere/WEB-INF/web.xml and adjust the value for session-timeout parameter. Minus one (-1) results in an infinite timeout ” the session will not expire at all.
  2. Restart the Apache Tomcat web server by running the command: service vcopsweb restart

With the release of 5.0.1 it looks like any customizations you may have done get overwritten, so this process will have to be repeated upon every update. I’ve read posts about having to save any custom dashboards you may have created as well.

As a side note, I’ve noticed that by default you are able to use the login credentials relative to the vCenter instance(s) you have registered in the admin console…however I’ve found that when I added vCenters that use different LDAP sources the UI won’t let you login with any previously working LDAP account and you will need to log in with the default admin account…not sure if that’s a bug, or by design…I was surprised that it picked up user auth without any additional config from the first vCenter registered. In my example I had three vCenters registered, the first two had common LDAP profiles, while the third was standalone…

sources (1)