Adding Swift to DevStack

If you find yourself needing to enable Swift on DevStack and you already have DevStack deployed and running and do not want to redo the whole thing I can relate. I found myself in this exact spot tonight. By default DevStack does not enable Swift, but its really trivial to enable it. The tricky part may be once its enabled how do you make it work without just redoing the whole thing?

Getting Swift enabled is pretty simple. First open your local.conf file in your /home/stack/devstack directory using your favorite editor. Next add the following lines to it:
enable_service s-proxy s-object s-container s-account
And save the file. If you havent built your DevStack yet now you can simply proceed with ./stack.sh If you have already built your DevStack and its up and running simply proceed with ./unstack.sh and when that completes then proceed with the ./stack.sh During the install it will prompt you for a hash/passphrase and I just used the same password I used for the initial DevStack install. Once this process finishes you should have Swift added to your DevStack. Happy Stacking!

pyvmomi now available in Fedora 19 20 and 21

Back in 2005 I got into making RPMs for Fedora, and by 2006 I became a sponsored packager. It was a hobby I really enjoyed, but back in 2009 or 2010 I just got too busy with work and had to pass the baton. About a month and a half ago I was looking for issues on the pyvmomi project that I could help close when I found this one asking for help making an RPM for Fedora. I got excited all over again about making RPMs so I made one and headed down the path to become sponsored again to package for Fedora. I created this bug report and became re-sponsored, and after a lengthy process I am happy to report that pyvmomi is now available in Fedora 19, 20, and 21. It is still in the testing phases for EPEL 6 and 7 but in another week or so should be available there as well. This puts us one step closer to being able to port the current OpenStack driver for vSphere to pyvmomi!

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 172.16.214.130 and it was running 3.3.1 so I ran the command:

importum 172.16.214.130 331

Here is the output from my command:


localhost:~ # importum 172.16.214.130 331
Connecting to Usage Meter at 172.16.214.130 to dump and compress the database and copy files to transfer directory
The authenticity of host '172.16.214.130 (172.16.214.130)' 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 '172.16.214.130' (RSA) to the list of known hosts.
VMware vCloud Usage Meter
root@172.16.214.130's password:
Copying files from old Usage Meter
root@172.16.214.130'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!

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-5.5.0.10000-1624811 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-5.5.0.10000-1624811-system.vmdk 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`
    CODE=0

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:

    vagrant:x:1519:100::/home/vagrant:/bin/bash

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.

    vagrant:$6$gxhfnuHm$FMUpGdh2kca12joVHFFV33bhJSvxE5xQWAn3RzkQmP1X/KeckBW2ODcYhe2a2y5D3ROUTtMDgu0Djzlpz4E7B/:16271:1:60:7:::

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 https://raw.githubusercontent.com/mitchellh/vagrant/master/keys/vagrant.pub -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 http://download.opensuse.org/distribution/11.4/repo/oss/ 11.4
    zypper --gpg-auto-import-keys ar http://download.opensuse.org/update/11.4/ 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 VBoxLinuxAdditions.run 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 VBoxLinuxAdditions.run
    ./VBoxLinuxAdditions.run --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 package.box

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@127.0.0.1 < provision/configure_vcsa.sh

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.

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.
wget http://mirror.symnds.com/software/Apache/tomcat/tomcat-7/v7.0.34/bin/apache-tomcat-7.0.34.tar.gz
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
jsse.jar…
Error: Could not open input file: /usr/java/jdk1.7.0_10/jre/lib/jsse.pack
charsets.jar…
Error: Could not open input file: /usr/java/jdk1.7.0_10/jre/lib/charsets.pack
tools.jar…
Error: Could not open input file: /usr/java/jdk1.7.0_10/lib/tools.pack
localedata.jar…
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 java.sh Using your favorite text editor create the file /etc/profile.d/java.sh 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/*

PATH=$PATH:$JAVA_HOME/bin

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

chmod +x /etc/profile.d/java.sh

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:

echo $JAVA_HOME

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:

/usr/java/default

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.

make

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 https://raw.github.com/michaelrice/tomcat_files/master/init.d/tomcat -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:

TOMCAT_USER=tomcat

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.

CATALINA_PID=/var/run/tomcat/tomcat.pid
TOMCAT_LOCK_FILE=/var/lock/subsys/tomcat/tomcat

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/tomcat.sh ] && . /etc/profile.d/tomcat.sh
[ -f /etc/profile.d/java.sh ] && . /etc/profile.d/java.sh

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 tomcat.sh file needs to be created and make executable. Using your favorite text editor create the file /etc/profile.d/tomcat.sh 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/tomcat.sh

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:127.0.0.1:8009 :::* users:((“jsvc”,20103,39))
LISTEN 0 100 ::ffff:127.0.0.1:8080 :::* 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>
ServerName tomcat-demo.mrice.me
ProxyRequests Off
<Proxy *>
Order deny,allow
Allow from all
</Proxy>
ProxyPass / ajp://localhost:8009/
</VirtualHost>

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.
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT
-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
COMMIT

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

Install vmware tools on Debian

Just a quick post. If you are running Debian 6 as a virtual machine and want to get the vmware tools installed in the vm its pretty simple. I recommend using the open-vm-tools package (I recommend using these for ALL Linux distros). In Debian 6 this package is provided in the contrib repo. To enable access to this repo you simply edit (as root or sudo) your /etc/apt/sources.list file and add contrib to it like so:

deb http://ftp.us.debian.org/debian/ squeeze main contrib
deb-src http://ftp.us.debian.org/debian/ squeeze main contrib

deb http://security.debian.org/ squeeze/updates main contrib
deb-src http://security.debian.org/ squeeze/updates main contrib

# squeeze-updates, previously known as 'volatile'
deb http://ftp.us.debian.org/debian/ squeeze-updates main
deb-src http://ftp.us.debian.org/debian/ squeeze-updates main

Once you save, still as root or sudo simply run:
apt-get update
Once it finishes you can run:
apt-get install open-vm-tools.
Thats all there is to it.

Install yum on your vmware vma

DANGER!! Please note this will likely null and void any kind of warranty or support you may have on your vma, and it will also break vima-update depending on what you allow yum yo update, it might even cause the world to explode.. I dont know and Im not responsible for anything that goes wrong following this..

With that out of the way.. So you want to install yum on your vma so you can install some packages on your vma, and you dont want to track down rpms for it.. I had the same desire. Here is how I took care of the problem.. First I found that /etc/redhat-release stated I was using a Red Hat Enterprise Linux Server release 5.2 (Tikanga). Once I found this out I decided to use CentOS mirrors to get me a copy of yum and to update rpm and such so I could have yum.

First the base vma is missing some stuff in order to just grab yum and start using it. I found mine to be missing python-initparse, yum-fastestmirror, and yum-metadata-parser. For me I got a root shell using sudo -s, next I ran the following command from my root shell:
# rpm -Uvh http://mirror.centos.org/centos/5/os/x86_64/CentOS/yum-3.2.22-39.el5.centos.noarch.rpm http://mirror.centos.org/centos/5/os/x86_64/CentOS/python-iniparse-0.2.3-4.el5.noarch.rpm http://mirror.centos.org/centos/5/os/x86_64/CentOS/yum-fastestmirror-1.1.16-21.el5.centos.noarch.rpm http://mirror.centos.org/centos/5/os/x86_64/CentOS/yum-metadata-parser-1.1.2-3.el5.centos.x86_64.rpm

This installed yum and the missing libs I needed to use it. Next I had to create a yum.conf repo file that the system can use to pull packages from. I used the following:

[main]
cachedir=/var/cache/yum
keepcache=0
debuglevel=2
logfile=/var/log/yum.log
distroverpkg=redhat-release
tolerant=1
exactarch=1
obsoletes=1
gpgcheck=1
plugins=1
bugtracker_url=http://bugs.centos.org/yum5bug

# Note: yum-RHN-plugin doesn't honor this.
metadata_expire=1h

installonly_limit = 5

# PUT YOUR REPOS HERE OR IN separate files named file.repo
# in /etc/yum.repos.d

[base]
name=CentOS-5.2 - Base
mirrorlist=http://mirrorlist.centos.org/?release=5&arch=$basearch&repo=os
#baseurl=http://mirror.centos.org/centos/5/os/$basearch/
gpgcheck=1
gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-centos4
protect=1

#released updates
[update]
name=CentOS-5.2 - Updates
mirrorlist=http://mirrorlist.centos.org/?release=5&arch=$basearch&repo=updates
#baseurl=http://mirror.centos.org/centos/5/updates/$basearch/
gpgcheck=1
gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-centos4
protect=1

Please note the repo info like the file states can be added to a .repo file if you want, but to shorten this for me Im doing it all in 1 place. I would also suggest going though and adding things like kernel* to the excludes= section (that is really beyond what Im trying to cover here though). Once you have this minimal info in your file you can save it. Next you need to import the RPM-GPG-KEY so you can install files.. As root:

rpm --import http://mirror.centos.org/centos/5/os/x86_64/RPM-GPG-KEY-CentOS-5

Now you can update things like rpm, or even install vim-common or emacs 🙂 You could also go a step further and install the epel repo and then install puppet so if you are in a large scale environment you can keep the system updated and files in sync with all your other hosts.

Switching Falconstor IPStor to use 1 to 1 mapping for LUN assignment

Switching your Falconstor IPStor server to use 1 to 1 mapping from any of the other avaliable mapping options Like All to All or All to 1 can be an annoying task, but if you have VMWare ESX or ESXi and have VMotion you can do this with 0 down time and Ill show you how. These steps will assume you are NOT in a fail over cluster with Falconstor

In my example I am using 2 ESX 4.1 hosts. Monster01 and Monster02. Each one of my hosts is designed to support running all our virtual machines from so moving all the vms to a single host like this is not going to have a negative impact on any vm and users will never know this is going on.

First Im going to need to vmotion all the machines to a single host. I move all the virtual machines running on Monster01 to the host Monster02. Once this is done I put Monster01 in maintence mode, then shut it down. This step is only needed if you are SAN booting your ESX/i host and need to change the LUN the ESX/i OS is running on.

Once its shut down comes the hard part if no one ever documented what WWPN is used for what. If that is the case for you like it was for me then you can figure this out by looking at your physical adapters and finding all the adapters that are in target mode. Write down the WWPN of each one. You might have a bunch.. Thankfully I only had 2 adapters in terget mode that were online. Yay!! a 50/50 chance of getting it right on the first try! I took LUN 0 which has my ESX 4.1 install on it and did a 1 to 1 map. On the ESX host this was simple since we only had 1 adapter plugged in and configred. Next I had to take a shot in the dark because our cables are a mess and no one documented what WWPN was used for what. I got it wrong the first time because once I assigned the LUN and turned the host back on the box failed
to boot. I switched to my other choice and Bam it booted!

Next to quickly switch the other 40 LUNS I went to the Falconstor management console and went into the SAN Clients and selected Monster01 I right clicked on each LUN and selected properties. From here you can switch from your current mapping to 1 to 1 using a select box. You will get a warning about data transmission stopping when you do this. That is fine since there are no running virtual machines on Monster01 (remember its still in maint mode) Next you select the 2 WWPNs needed for the initiator (the ESX host) and the target (the Falconstor server). Once you have completed this for all LUNs you can bring the ESX host out of maint mode and VMotion the machines from Monster02 to Monster01 and then repeat this process on Monster02.

Add a new disk to a volume group for use with lvm

Today I built a new server for us to start testing out splunk. When I built it I used LVM. I also agreed to the default layout using split partitions on the Debian 6 install. So I ended up with a partition for / /var and /home and /tmp. I always like splitting partitions up like this, and I ALWAYS use LVM. Once the new server was booted up and ready for me to begin the splunk install I did so using their deb package. That put everything for splunk into /opt which did not have its own partition, and as a result I needed to add a new disk, and create a partition that could be mounted to /opt. Since I used LVM this became a trivial task. I will show you the steps to take if you need to do what I did.

First we need to stop splunk and move it out of /opt for a moment.
/opt/splunk/bin/splunk stop
Once you see this info you should be ready to move splunk:

Stopping splunkweb…
Stopping splunkd…
Shutting down. Please wait, as this may take a few minutes.
.
Stopping splunk helpers…

Done.

Next we will move the splunk install to /tmp while we do this disk stuff. If you do not move it you will notice once the new opt is created that splunk is gone (sort of, its really just hidden), so its best to just move it for now.
mv /opt/splunk /tmp
This will move the splunk install to /tmp.
Next, I am going to assume your new disk is already accessible to the system. If its not then make it that way, so we can partition it with fdisk
fdisk /dev/sdb
sdb Was the disk I added to my system. Here I am going to create a new primary partition and set its type to 8e which is Linux LVM. I want to use the whole disk but you may want to only allocate a small amount of it.. Once you have written the changes and fdisk is done its time to begin the LVM steps.
The first step is to create a disk using pvcreate
pvcreate /dev/sdb1
You should get a message like this:

Physical volume “/dev/sdb1” successfully created

If so we can move on to the next step. In my setup I want to add this new disk to the existing volume group which is named splunk. To do that I will use vgextend
vgextend splunk /dev/sdb1
If the command was successful you should be greeted with the following message:

Volume group “splunk” successfully extended

You can verify this using vgdisplay
vgdisplay splunk
You should see something similar showing the new Free PE or the Total PE as being larger. In my case the Total increased by 10G, and the Free shows I now have 10G free.

— Volume group —
VG Name splunk
System ID
Format lvm2
Metadata Areas 2
Metadata Sequence No 8
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 6
Open LV 6
Max PV 0
Cur PV 2
Act PV 2
VG Size 29.75 GiB
PE Size 4.00 MiB
Total PE 7617
Alloc PE / Size 5058 / 19.76 GiB
Free PE / Size 2559 / 10.00 GiB
VG UUID DtBgbf-pDPY-JLFo-cjv2-ydUC-nyiH-lzqzys

Now I can create a new logical volume. I am only going to use 8 of the 10G I added, and name it “opt” since that will be its mount point:
lvcreate -L 8G -nopt splunk
If that command was successful you will see a message like mine:

Logical volume “opt” created

You can look at the info about the new volume using lvdisplay
lvdisplay
Here is the opt section of my output

— Logical volume —
LV Name /dev/splunk/opt
VG Name splunk
LV UUID 5fAiFp-fpmd-dlUa-mgHl-nNcy-kX9G-RLHDaC
LV Write Access read/write
LV Status available
# open 0
LV Size 8.00 GiB
Current LE 2048
Segments 1
Allocation inherit
Read ahead sectors auto
– currently set to 256
Block device 254:6

Now all thats left is adding a filesystem to this volume and mounting it. I am using ext3, so I will use the following command:
mke2fs -j /dev/mapper/splunk-opt
After the normal output from mke2fs I need to amend my fstab to auto mount my new filesystem for me on boot.
$EDITOR /etc/fstab
I will add the following to that file:

/dev/mapper/splunk-opt /opt ext3 defaults 0 2

Save this file. Now mount the new file system. You should also move anything else that is currently in /opt to /tmp while you do this or it will also appear to be gone.. To mount the new file system simply:
mount -a
This will mount the new logical volume to /opt for you. Verify that with df or mount. Once its verified that it is in fact mounted you can safely move all your data back to /opt
mv /tmp/splunk /opt
Now you can start splunk back up
/opt/splunk/bin/splunk start
All done.