How to update vCloud Usage Meter to fix Shell Shock Bug

If you are running vCloud Usage Meter 3.3.1 or older your appliance is at risk and needs to be updated. VMware released an update but didnt exactly provide the best instructions for getting your systems updated. The purpose of this blog is to fill that gap and provide some detailed instructions.

To get started you should first go download 3.3.2 or newer vCloud Usage Meter OVA. Once you have that file you should make sure your current system has all the prerequisites taken care of, because if you dont when you upgrade and try to visit your updated Usage Meter you will only be greeted by a big ugly stack trace. Lets take care of those now. By default sshd is not running, but the upgrade script called importum requires it, and requires it to be running on the default port of 22. You can check your system by logging in as root and running the command service sshd status. If you get the response:

Checking for service sshd unused

then its not running and you will need to use service sshd start to start it up. Next just to be sure you should verify it is running on port 22 and listening on all interfaces like this: ss -an|grep 22 That should give you some output like the following:

LISTEN 0 128 :::22 :::*
LISTEN 0 128 *:22 *:*

If your output shows this then you are ready to move on to the next step which is to make sure your root password is set. By default there is no root password set and if that is the case with your system its time to set a password using passwd. Once that is set you should test ssh connectivity to make sure you can connect to the server as root. Once you have successfully logged in as root from a remote system you are ready to upgrade.

The upgrade process is pretty simple. All you need to do is deploy your new OVA and once it boots up log in as root with no password. Next issue the importum command. It takes 2 params. The first one should be the hostname or IP of the old Usage Meter, the next param is the version of the usage meter software. In my case I wanted to update the host and it was running 3.3.1 so I ran the command:

importum 331

Here is the output from my command:

localhost:~ # importum 331
Connecting to Usage Meter at to dump and compress the database and copy files to transfer directory
The authenticity of host ' (' can't be established.
RSA key fingerprint is 42:d7:3a:ad:9c:b1:b0:41:7f:93:5a:fd:a5:13:d9:01.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '' (RSA) to the list of known hosts.
VMware vCloud Usage Meter
root@'s password:
Copying files from old Usage Meter
root@'s password:
Moving existing keystore file to /opt/vmware/cloudusagemetering/encryption/defaultks-20141004_195153
Renaming existing database to usgmtr_20141004_195153
Import is complete. See /var/log/usgmtr/import-20141004_195153.log for details.

Once this is complete you are all done. If you have any problems check the logs in /var/log/usgmtr/ Happy updating!

vCloud Usage Meter

Recently I was tasked with building a tool that would create customers and rules in vCloud Usage Meter to help enhance our monthly usage reports. The way this tool needed to work was to connect to all of our vCenter Servers, pull some data from them then connect to vCloud Usage Meter and create a customer, then make a rule that would tie their inventory to some managed object. Normally I do most of my code work in Groovy using the Grails framework, but for this project I decided to use python. The main reason for that was we needed to run this tool once a month, and they wanted it hands off. I knew our Ops Team would want to create a crontab for it on one of our Linux servers so I wanted to make something very portable. Python was an obvious choice for this based off of that requirement.

When I got started I went looking for some library that would make it easier for me to interact with vCloud Usage Meter but I didnt find anything. vCloud Usage Meter provides a REST based API so I decided to just write my own library and called it thunderhead. I thought it might be useful to others so I went ahead and open sourced the work via Apache-2.0. At the time of this writing it is not 100% feature complete, but does provide a lot of functionality, and I plan to continue development on it to get it 100% complete. I also always appreciate pull requests so if you need something I havent implemented please feel free to send me a pull request. For examples of how to use the library see the tests that are included. To install thunderhead simply

pip install thunderhead

Virtualbox + Vagrant + VCSA + VCSIM To Automate Your vCenter Test Environment

Just The Facts..

Before we even get started I have to say this. What follows in this article is 100% completely unsupported in anyway form or fashion. You should only even consider doing this if you are in a situation like me where you need to do some form of automated testing. Some of these things may even violate the EULA of one or more technologies used. Last but not least: In no way is this something my employer (current or former) endorses doing or had any role in. This mess is all mine.

What Problem Are You Trying To Solve Here?

I am a software developer. I work full time developing applications that interface directly with various VMware (and at times OpenStack) technologies. While working on the VMware stuff I almost always need a vCenter with a complete inventory to test my code with. Thankfully people like William Lam have created wonderful blog posts that have helped me get a lot of what I needed done with out even having to do anything myself except modify a script to meet my needs. This blog post is going to take what I have learned from doing this stuff manually and wrapping it all up into Vagrant using Virtualbox and a couple of command line tools from VMware.

Press The Any Key?

If you have ever tried running the VCSA on Virtualbox you will have seen this message for sure:

    The profile does not allow you to run the products on this system.
    Proceeding to run this installation will leave you in an unsupported state and might impact your compliance requirements.

You will also know how annoying it is to have to press any key to continue during subsequent boots post install. These issues make it very difficult to create automated test environemts that you can spin up and down as need. Thankfully the VCSA is a Linux box so if you are crafty you can do some things to bypass these checks before they ever happen.

What Are All Those Tools in Your Toolbox?

First to keep the messages above from ever showing in the first place we have to modify the system files on the VMDK of the system disk. The first tool Ill be using is one supplied by VMware. Its called vmware-mount, and its part of the vSphere Virtual Disk Development Kit (vddk from here out). For some reason it got
removed from the 5.5 kit but in my testing thus far the 5.1 kit has worked fine on my 5.5 VCSA setup. I wont be discussing how to setup the vddk or the prereqs it needs for it to work. Please use the documentation provided by VMware for that. Next Ill be using Virtualbox, Vagrant, and then some scripts from William Lam to customize the VCSA and configure VCSIM. In my environment I will be using Debian Linux Wheezy 7.5, Virtualbox 4.3.12, Vagrant 1.6.3, and VMware-vCenter-Server-Appliance- You should download these things and install them before you get started. The VCSA only needs to be downloaded, but Virtualbox and Vagrant, and the vddk will need to be installed and configured. This process may work on other versions but YMMV

Everything Has A Place, And There Is A Place For Everything

Before we start making any changes I found this whole process works best if you import the VCSA OVF into Virtualbox first. To do that start Virtualbox.Next click on the File menu, and select Import appliance. Now navigate to where you downloaded the VCSA files from VMware. Select the OFV file and follow the instructions to complete the process. You do not need to power on nor should you power on the newly created VM. If you skip this step you can end up struggling with your mounted VMDK going read-only as soon you as try to make any changes to files on its file system further along in this process. With that out of the way I am now going to move on to the changes that have to be made.

Change, The Only Constant

With all the prereqs out of the way lets get this party started. We need to start by using vmware-mount to mount the VCSA system VMDK so we can make some changes to bypass those pesky messages I discussed in the begining of this article. I store my Virtualbox files in ~/Virtualbox Vms/vmware/vcsa

    cd ~/Virtualbox Vms/vmware/vcsa
    mkdir /tmp/vcsa
    sudo vmware-mount VMware-vCenter-Server-Appliance- 3 /tmp/vcsa

Now with the disk mounted we can make some changes to the proper files. There are several files we are interested in. For Vagrant to work happily we need to make some changes to the sshd_config file. Next to stop the pesky messages we get on boot we need to modify a file called boot.compliance. Lets makes these changes now. Lets start with sshd_config. In this file we want to enable password auth, turn off DNS lookups.

    vim /tmp/vcsa/etc/ssh/sshd_config

In this file look for the following lines to edit so they look like the following lines:

    PasswordAuthentication yes
    UseDNS no
    #AllowGroups shellaccess wheel

Just a note on the PasswordAuthentication. It is optional and honestly not used in this process. We will be using keys, I only enable it for some other not discussed in this blog stuff. First off I found this value listed 2 times. The first value was set to yes already, then near the bottom of the file it was set again and was set to no. I simply removed the second entry leaving only the first one. Leaving it to no does not keep ssh password auth from working. The sshd_config documentation can be confusing here because you can set this to no and still get prompted for a user name and password. This is normally from the keyboard-interactive login method (which still uses a password which is where people can get confused). There is a really boring RFC you can read about it here if you need some help getting to sleep some time. UseDNS no tells the sshd server not to do a reverse lookup of people trying to connect. Since this will be running from my own local host on virtualbox there is no need for the DNS lookup to happen. The last line removes the requirement for being in the shellaccess or wheel group. Next lets shut up the warnings about being unsupported, and disable having to press the any key. For that we have to edit that boot.compliance file.

    vim /tmp/vcsa/etc/init.d/boot.compliance

In this file look for the following lines and make them look like this:

    MSG=`/usr/bin/isCompliant -q`

Here I add the -q which tells the isCompliant script (which is GPL code and looks to be part of the base SUSE install) to run in quiet mode and not output any of the messages it finds when something isnt compliant. Next I hard code CODE=0 because I know that isCompliant will return a non 0 status causing yet another message to pop up on screen. This is the message asking us to “press any key to continue”. Setting this value to 0 makes that message not show and the boot process to continue with out human intervention being required.

Next I need to add the vagrant user. Normally I might use something like adduser/useradd but here I will just make the changes those tools do manually. To do that Ill be editing the passwd and shadow files by hand.

    vim /tmp/vcsa/etc/passwd

Here I will add the following line to the bottom of the file:


For an explination of what each of the colon seperated sections mean see the passwd(5) Linux man page. Next I edit the shadow file.

    vim /tmp/vcsa/etc/shadow

I add the following info to the file and save it. FYI The shadow file is read only even for root so I have to force the save.


Here I am setting the password to for the vagrant user to vagrant. For a full explaination of what each colon seperated section means see the shadow(5) Linux man page. Now I need to add a home directory and copy in the basic files that come with a home directory. Those files are typically located in /etc/skel and on the VCSA that is no exception.

    mkdir -p /tmp/vcsa/home/vagrant/.ssh
    cp /tmp/vcsa/etc/skel/.{b*,e*,i*,pro*,vim*} /tmp/vcsa/home/vagrant
    chown -R 1519:100 /tmp/vcsa/home/vagrant
    chmod 700 /tmp/vcsa/home/vagrant/.ssh

Now I need to add the vagrant insecure ssh key to the authorized_keys

    wget -O /tmp/vcsa/home/vagrant/.ssh/authorized_keys
    chown 1519:100 /tmp/vcsa/home/vagrant/.ssh/authorized_keys
    chmod 600 /tmp/vcsa/home/vagrant/.ssh/authorized_keys

Finally I need to add the vagrant user to the sudoers file and give them full access with out a password.

    visudo -f /tmp/vcsa/etc/sudoers
    vagrant ALL=(ALL) NOPASSWD: ALL

The Light At The End Of The Tunnel

We are getting close to being finished. Now there are only a few steps left. The next few steps took me some time. Not because they are hard but because finding the packages needed to do them was not easy. Almost everything I am doing is to make it so I can use Vagrant and Virtualbox. After having done all this Im still not 100% sure it was worth all this effort, but I digress. Lets move on to finish this.

The last few steps are:

  1. Unmount the system vmdk we mounted earlier.
  2. Start the VCSA (but do not do anything other than power it on).
  3. Install packages to allow you to build kernel modules
  4. Install VBoxLinuxAdditions into VCSA
  5. Power off VCSA & Export into Vagrant

First I unmount the vmdk using vmware-mount -x, next I power on my VCSA. Once its booted I will log in as root using the default password it has of “vmware”. Next using zypper I install make and gcc:

    zypper --gpg-auto-import-keys ar 11.4
    zypper --gpg-auto-import-keys ar 11.4-updates
    zypper install make gcc

When I run this command the system tells me there is a problem and I can pick an option to get past it. I pick option 1 which is downgrade binutils. Once that install finished it warned me about needing to restart but I ignored that because Im only going to install a couple more things then power it off anyway. Here comes the hard part (at least for me it was). Locate and install kernel-source-3.0.101-0.5.1 kernel-default-devel-3.0.101-0.5.1. For me the locating of those packages was the most difficult thing in this whole process. You cant use zypper to install this, at least not using the repos from above. I honestly found these packages on an FTP server in Russia.. Seriously it was not fun tracking them down. Once located download them and install them using:

    rpm -Uvh kernel-*

Now you are finally ready to build the Virtualbox Guest Additions. This will allow you to use port forwarding in Vagrant, as well as shared folders and many other features of Vagrant. To install the guest additions you need to copy the up to the VCSA. The file can be found in the VBoxGuestAdditions.iso which will then need to be mounted somewhere so you can get the file off of it you need. I did this by doing:

    mkdir /tmp/guest_add
    mount -o loop /usr/share/virtualbox/VBoxGuestAdditions.iso /tmp/guest_add/

Next I did a scp to place the file on the VCSA. Next simply set the file executable and execute it:

    chmod +x
    ./ --nox11

Once this process finishes you are done-ish.

Wrapping it all up

All that is left now is to power off the VCSA, and export the image into vagrant. I do that by running:

    vagrant package --base VMware_vCenter_Server_Appliance

Where VMware_vCenter_Server_Appliance is the name I gave the image in Virtualbox when I imported it. This process on my laptop which is a Dell with an i-7, 32G of RAM, and an SSD took 27 mins. Once it completes you need to import this into vagrant. I did that by doing this:

    vagrant box add vcsa-5.5

This process never took more than 5 mins. Next If you use my vagrant files you can almost vagrant up. I say almost because I hit a snag where I couldnt get the vCenter configuration script to run properly with out doing this goofy hack. Once you have my files you can vagrant up like this and it will work:

     vagrant up && ssh -p 2222 -o "StrictHostKeyChecking=no" -i vagrant root@ < provision/

Thats it. Now just wait like 20-50 mins for it to completely complete and you can log in to your VCSA at: https://localhost:8443/ (user administrator@vsphere.local password: password this is also where to hit for the API access into vCenter) for the vCenter and the web client is at https://localhost:9443/ (user administrator@vsphere.local password: password) and you can access the config page at https://localhost:5480/ (user root password vmware)

The End

Thanks for going through this. I know it was long. It took me a while to get this all working and I tried to keep this blog to only important bits about the process. Again I must say you are 100% not supported by doing this stuff. First the VCSIM is not supported but furthermore making all these crazy changes like I did to the VCSA really goes beyond the realm of no support. If you have question or comments about this process please feel free to reach out to me. I will be glad to help where I can, but dont read into this as me offering to support you if you do this.. Its a very advanced topic and one that should only be attempted if you are comfortable doing this stuff.

Monitor the vSphere API with PERL using nagios or icinga

I spend all day every day doing development against the vSphere API. It is crucial that we know when the API is down. If this is something you need to know about you have many choices out there to do your monitoring. Some names that come to mind for me are Nagios and Icinga. In the past icinga was something I used to take care of this task. In this post I will discuss how you can do the same thing and I will provide the PERL code required to take care of this task.

First it is important to note I will not be discussing how to setup nagios or icinga, that is beyond the scope of this post, so make sure you already have it setup and are familiar with how to do configuration tasks with it. With that out of the way lets get started.

Monitoring the API is a pretty simple task. I have found that all it takes is something as basic as logging in and checking the time the vSphere API returns. If you are unable to preform this basic task there is no chance any of the advanced features in the API will work. To get this task done you really only need to do 3 steps.

  1. Login
  2. Obtain a ServiceInstance
  3. Call the CurrentTime method on the ServiceInstance

Thats it. If you can do this your API is up and usable.

VMWare provides the vi-perl tool kit which makes the code pretty simple to write, and the code I provide at the end of this article depends on it to function. Now you just need to configure Nagios or Icinga to run that code at what ever time interval you deem fit. For me I like to know right away so I always had it run every 3 mins and alert me on any failure. As promised here is a link to the code.

How to contribute to an opensource project like a boss

So you found a cool project online and its opensource and now you want to give some of your time and efforts back to the community, but you dont know where to start. This blog post should help get you started and help you get your code accepted on just about any project out there.

The first step you should take is to read the documentation that comes with the project. A great place to start is often the README in the project. Generally you will find all kinds of info in this file. Some of that information may be code standards, where to find help, TODO lists, or just general project guide lines.

Next get familiar with the tools used in the project. This could mean having to learn to use a new revision control system such as git with a focus on using it via github or bitbucket. Many projects have some special requirements when it comes to their source code. You do not have to be a master with these tools, but you should at least understand how to do some basic tasks with them. For example, with projects using git and github you should understand forking, branching, fetching, merging, pushing, and most importantly pull requests. Its OK to ask for help getting these things done, and you can generally find where to get that help in the README.

Next it may be helpful for you to look at the rest of the code in the project, or at least some of it. I know this may be a lot of work because some projects are so large. Maybe you don’t need to see every line of every piece of code but it will help to look at some of it to get an idea of how the rest of the code is written so that you do not camelCase where the rest of the project uses underscore_syntax.

Next you should be open to community feedback. Opensource development generally speaking works differently than what you may be used to doing at work. Most projects I have worked on have some kind of peer review system where community members and projects owners will look at your code and make sure it meets the code standards, and has logic in it that is easy to follow and makes sense. These reviewers may ask you to make changes, but don’t take it personally. This feedback should not be taken as a personal attack. Remember you are going to donate this code and you may never come back again, so it will be up to other community members and project owners to maintain it. You may be doing this on your free time, but odds are that so are some if not all of the other people reviewing your code. Generally speaking no one will ask you to make changes to your code that they wouldn’t expect of their own code.

On the topic of changes no one is forcing you to make these changes. Generally speaking it is just an ask. If you don’t want to make the changes kindly tell the reviewers something like “Im sorry I am not interested in making these changes, please feel free to take my code if you can”. Most projects would rather have working code that needs to be “reformatted” than have nothing while others may not be interested in your code if you don’t make the changes.

Finally and this may seem very obvious but try to write good, well documented, clean code that is easy to follow and understand. I have been doing this for almost 15 years now and I have never run into some code where I said “Damn this documentation is way too good, and there is just way too much of it”, and I am willing to bet I never will. Often it is the opposite of that and I am cussing as I read through line by line trying to figure out how or why something is the way it is.

If you follow these steps, or suggestions as they really are, it should help the process be very smooth and pain free for all parties involved. If you have any suggestions about things that I should add to this list please feel free to let me know. I would love your feedback. I hope this blog post will be helpful to someone out there who is thinking about getting into working on opensource projects.

Making the id field start at 1000 instead of 1 in a Grails domain class

Recently I wanted to make a domain class in a grails app and have the built in id field not start at 1. I wanted it to start at 1000. This was for a generic “Device” class I plan on extending with specific devices like Virtualmachine and Hostsystem devices. I wanted these devices to have numbers starting with 1000 for no reason other than ‘just because’. I did some searches but couldnt find many simple explanations so once I got a working solution I thought I would share what I used.

Ive been working on a tool I will be talking about in future posts, and will only talk about in this post for the code used to make our id generator work. If you look at my Device.groovy you will see exactly what to do.

static mapping = {
id generator: "", params: [initial_value:1000, increment_size:1]

Here I select the type of generator to use, then in the params I set an initial_value of 1000 You can set this to be anything, next I tell it to increment by 1. I found this documentation helpful in my quest: I hope you find this post helpful.

How to install Python 2.7 on CentOS 6.x

I needed to install python 2.7 on a CentOS server. I did some searching and found some very broken scripts on github. I picked one of them and started hacking til I got it working. You can now find it here: centos_python_env_setup To use it, you can simply grab the raw version using wget, set the script executable with chmod, then as root run it. I tested this script about 25 times using my Rackspace Cloud server and picking the CentOS 6.4 option. Please let me know if you have any issues running it.

Simple Tomcat Hosting using Tomcat 7, Java 7, and httpd with mod_proxy_ajp

Ive been spending a lot of time in the last year and a half dealing with Apache Tomcat. The DevOps team I am on focuses on Grails for almost all development needs. We use Tomcat 6 and 7 to host a variety of applications we have written. As such I have learned a lot about Tomcat, and Im going to use this opportunity to share some of the things I have learned with you.

The server setup

I like using CentOS on my personal stuff, so for this example Ill be using CentOS 6.3 and using my Rackspace Cloud Server. Im just using the default image provided by Rackspace. From the cloud server control panel I name my server tomcat-dev1. Next I selected CentOS 6.3 for the image and 512M of RAM for the server size. Finally in the networks section I leave it defaulted to a public and private adapter, and then press the create server button to begin building my new cloud server. Keep in mind this is just a development server for me so I dont need much RAM, for a production system you will need to calculate your needs accordingly and make your server as large as you need it. Once my server is done building I will log on and install:

  • httpd
  • jdk 7 from Oracle
  • Tomcat 7
  • git (optional, but I like to keep my config files in version control)
  • jsvc (this is bundled with tomcat)

First steps

Lets begin by logging into our new cloud server as root. The first thing I do to a new cloud server is change the password. Once that is done we can begin by updating the system.
yum -y update
This is done because the base image could be several months old so we want to get the latest updates from the vendor before we begin. Once that finishes reboot if you need, if you do not know if you need a reboot or not just do it anyway to be sure.

Gathering the goods

Some of what we will be installing is either not provided by yum, or is older and we want flashy and new. We need to fetch the jdk; I will download the x64 rpm to my local desktop then upload it to my cloud server using winscp. Next we need Tomcat, and jsvc. Since these two things do not require me agreeing to some terms I will download them directly from the server.
Now on my server I should have the jdk rpm, and the Tomcat 7, and jsvc packages.(jsvc is bundled with tomcat)

Installing the jdk, Tomcat, and jsvc

We need to install the jdk first. To do that lets install the rpm:
rpm -Uvh jdk-7u10-linux-x64.rpm
If you see output like this:

Error: Could not open input file: /usr/java/jdk1.7.0_10/jre/lib/rt.pack
Error: Could not open input file: /usr/java/jdk1.7.0_10/jre/lib/jsse.pack
Error: Could not open input file: /usr/java/jdk1.7.0_10/jre/lib/charsets.pack
Error: Could not open input file: /usr/java/jdk1.7.0_10/lib/tools.pack
Error: Could not open input file: /usr/java/jdk1.7.0_10/jre/lib/ext/localedata.pack

It is safe to ignore. I didnt dig into why this output happened but it did not seem to affect my install. Now that Java is installed we need to add the java install to the alternatives system, and make it so that the JAVA_HOME environment variable is set for all our users when they log in. Lets do that by creating a file in /etc/profile.d called Using your favorite text editor create the file /etc/profile.d/ and enter the following lines into the file and then save it:

export JAVA_HOME=/usr/java/default
export JRE_HOME=/usr/java/default/jre
export JAVA_OPTS=””
export JAVA_CLASSPATH=/usr/share/java/*


Now the file needs to be set executable so issue the following command:

chmod +x /etc/profile.d/

Now to add java to the alternatives system

alternatives --install /usr/bin/java java /usr/java/latest/jre/bin/java 20000
alternatives --install /usr/bin/jar jar /usr/java/latest/bin/jar 20000
alternatives --install /usr/bin/javac javac /usr/java/latest/bin/javac 20000

Lets test that this works by typing:


Right now we should get no output. Now try logging off our server, and logging back in. Once you do that type the command again. We should now see:


Now we need to unpack Tomcat, and the jsvc daemon.

tar xzvf apache-tomcat-7.0.34.tar.gz -C /opt/

This will unpack Tomcat into the /opt directory into a folder named apache-tomcat-7.0.34 Once that is done unpack the commons-daemon source code. That code is bundled with tomcat:

cd /opt/apache-tomcat-7.0.34/bin/
tar xzvf commons-daemon-native.tar.gz -C /usr/local/src/

The source code for the jsvc daemon is now in /usr/local/src/commons-daemon-1.0.10-native-src and needs to be built. Before we can build it we still need to install a couple of things on our server. According to the docs we need a compiler, and make. In an effort to make it simple I will be using yum and the groupinstall option to install “Development tools” This will provide git, make, gcc, cpp, and many other tools.

yum -y groupinstall "Development tools"

Once that is complete we have what we need to build jsvc, so lets do that now. Since we are using CentOS we will want to:

cd /usr/local/src/commons-daemon-1.0.10-native-src/unix

From here we can issue the configure command:

./configure --with-java=/usr/java/default

This should render some output, the last thing it says if you were successful is this:

*** All done ***
Now you can issue “make”

Lets do that now.


If you got no errors you should now have a binary file in the same directory as you called jsvc. Since this Makefile does not have a target for install the next natural step of make install would fail. You have to manually place the binary somewhere on your system. I like to just put it with the tomcat binaries since thats the only thing I use jsvc for, so thats what Ill do now:

cp jsvc /opt/apache-tomcat-7.0.34/bin/

You should now have Java 7, Tomcat 7, and jsvc 1.0.10 installed on your system. We are getting close to being done. Only a few more steps left!! 🙂

Doing some Tomcat configuration, and making Tomcat start at boot

Now that we have all these things installed we need to do some configuration, and also make it so Tomcat will start when the system boots up. Lets begin with making tomcat start at boot. Im going to provide you with the init script I wrote and use on my systems. You can get the latest version from here. Download it and save the file in /etc/init.d as tomcat

wget -O /etc/init.d/tomcat

This file needs to be executable so lets issue the following command:

chmod +x /etc/init.d/tomcat

Now we need to make sure tomcat will start at boot:

chkconfig --add tomcat && chkconfig tomcat on

This will add tomcat to the chkconfig system, and enable it for start up on boot. Lets take a look at what this file does for us. On line 4 we see this:

# chkconfig: – 85 15

This is needed for chkconfig so our command above would work. For more information see man chkconfig. Scroll down in the file until you see:


This is where the user that tomcat will run as is defined. By default it wants to run as the user named tomcat. We have not created that user yet, but we will shortly. The next two things to notice are right below the TOMCAT_USER line.


These locations on the file system are not there by default so we need to add them, and make sure our tomcat user has access to them, but lets keep looking through this file for now and we will fix all the things at once. Lets scroll down to lines 20 and 21

[ -f /etc/profile.d/ ] && . /etc/profile.d/
[ -f /etc/profile.d/ ] && . /etc/profile.d/

This is checking to see if these files exist and if so source them, this will set up our environment variables for us. The tomcat file is missing still, but we will add it soon. I think one of the last things to note here in this file is the JSVC_BIN variable. If you put jsvc in some other location than where I put it then you need to adjust this to your location. Finally on line 62 we have the command we use to start tomcat. You should not need to adjust this, but if you need to thats where to do it. Now that we know what this file will do for us, lets fix all the things we found while going through it.

Finializing the Tomcat bits

The first problem we found above was our script is looking for a “tomcat” user and we dont have one yet, so lets add one:

useradd -r tomcat -m

This added a new system user named tomcat, and created a group also named tomcat. A home dir was created in /home/tomcat The next problem we found was that a couple of files need to be created, and our tomcat user needs access to them. Lets make it happen:

mkdir -p /var/lock/subsys/tomcat/
mkdir -p /var/run/tomcat/
chown -R tomcat. /var/run/tomcat
chown -R tomcat. /var/lock/subsys/tomcat

Finally the file needs to be created and make executable. Using your favorite text editor create the file /etc/profile.d/ and add the following to it, then save it:

export CATALINA_HOME=/opt/tomcat
export CATALINA_TMPDIR=/opt/tomcat
export CATALINA_OPTS=”-XX:MaxPermSize=256m”

Now we need to make it executable:

chmod +x /etc/profile.d/

You may have noticed that the location of CATALINA_HOME and CATALINA_TMPDIR dont exist on our server, good catch. I use symlinks to this. Lets get them created.

cd /opt
ln -s /opt/apache-tomcat-7.0.34/ /opt/tomcat

I do this so if I update tomcat I only have to update this symlink and do not have to edit my init script, or my profile.d script. Now all we have left for tomcat is to make sure we have the server.xml file created correctly, and if we want to allow access to the manager we need to make a tomcat-users.xml file as well. I have provided the server.xml and the tomcat-users.xml file I used here. Those files need to be saved in /opt/tomcat/conf/ as server.xml and tomcat-users.xml Once you have done that you should be able to start tomcat, so lets try that now.

service tomcat start

Lets verify its running:

ss -nap

We should see some output like the following:

[root@tomcat-demo unix]# ss -nap
State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 100 ::ffff: :::* users:((“jsvc”,20103,39))
LISTEN 0 100 ::ffff: :::* users:((“jsvc”,20103,38))

This shows us that jsvc has a process listening on port 8009 and 8080, on the local loop back interface only, just like we setup in our config file. This is wonderful now we are done with tomcat for now. Lets move on to httpd and setting up the ajp.

Apache httpd and mod_proxy_ajp

We need to install httpd now.

yum -y install httpd && chkconfig httpd on

We do not need to do anything to get mod_proxy_ajp it is part of the base httpd install as of 2.2. Now that our web server is installed lets configure our first vhost, and serve up some tomcat content. Using your favorite text editor open the httpd.conf file located at /etc/httpd/conf/httpd.conf The vhost section is at the bottom of the file by default. In my case I added the following:

NameVirtualHost *:80
<VirtualHost *:80>
ProxyRequests Off
<Proxy *>
Order deny,allow
Allow from all
ProxyPass / ajp://localhost:8009/

Next I need to open port 80 on my firewall, since the default firewall will be blocking traffic on port 80. Using my text editor I will edit /etc/sysconfig/iptables so it looks like so:

# Firewall configuration written by system-config-firewall
# Manual customization of this file is not recommended.
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -i eth0 -m tcp -p tcp –dport 80 -j ACCEPT
-A INPUT -m state –state NEW -m tcp -p tcp –dport 22 -j ACCEPT
-A INPUT -j REJECT –reject-with icmp-host-prohibited
-A FORWARD -j REJECT –reject-with icmp-host-prohibited

Next I need to load this new rule set like so:

iptables-restore < /etc/sysconfig/iptables

Now I am done, and Im ready to fire up httpd and visit my site.

service httpd start

You can now visit your site in a browser and see the default Tomcat landing page, as well as add a /manager and log in using "tomcat" as the user, and "s3cret" as your password. In the coming weeks I will be adding more info about how to do vhosting using this method, and eventually covering how to do this all in a few mins using chef

SYSPRP Parse Commands:No action flag was specified

Ive been doing a fair bit of work around the vmware vix api. One of the things I needed to do was run sysprep after a clone is taken, and beofre the vm is brought on to the network and rejoined to AD. I decided to use vix to do it. Getting the command to run using vix is simple enough with VMRunProgramInGuest(). The issue I ran into was with the parameters I was passing to sysprep.exe

Sysprep will log into:


In those files is where I found the error:

SYSPRP Parse Commands:No action flag was specified

I was leaving off the Action flag clearly, but what are valid Actions? It wasnt clear to me until I ran sysprep with out any command line args and saw the gui. Then you can see that oobe and audit are your 2 options. oobe best fit my needs. Once I added that my error was corrected and sysprep would successfully run