About Patrick

just a veteran enjoying life.

Installing Apache Wave on Openstack

What is Apache Wave

You probably wouldn’t be here if you didn’t already know that Apache Wave is the port of Google’s defunct Wave protocol.

From the Wave incubator project page:
Wave is a distributed, near-real-time, rich collaboration platform that allows users to work together in new and exciting ways. Wave allows for flexible modes of communication, blending chat, email and collaborative document editing in to one seamless environment. Wave provides a lively and responsive environment that promotes more fluid and dynamic collaboration between users. The addition of Robots and [Gadgets] allow the Wave platform to provide intelligence, integration, and customizability to the users experience.

About this installation

There aren’t any reliable binaries for Apache Wave right now, so any running server binary has to be compiled from source. The source code is changing frequently, so ymmv on how often you’d like to recompile to get the latest updates.

For this installation, I’ll be using a CentOS 6.3 (x86_64) VM running on Openstack. My VM has 4GB RAM and 8GB root partition.  Because you’ll be compiling source code, I wouldn’t recommend less than 2GB RAM for the machine.

Preparation

You’ll need either access to the root user, or sudo permissions to run as root for package management tasks.
You’ll also need a user that manages the wave code — this user should NOT be root nor have sudo privileges.

Install dependencies

Using yum for package management, the basic command structure is:
$> sudo yum install -y [package1[,package2,...,packageN]]
The list of dependency packages is:

  • subversion
  • java-1.6.0-openjdk
  • java-1.6.0-openjdk-devel
  • mongodb
  • ant
  • git
  • ant-trax (used during test execution)
  • ant-junit (used during test execution)

Compile the Source

As your non-sudo wave user, fetch the source code using the link from the project’s source code page:
svn co https://svn.apache.org/repos/asf/incubator/wave/trunk

This will make a ./trunk subfolder from whatever folder you ran the command in. Enter the folder and execute the build commands to get started:
ant get-third-party; ant
The ant get-third-party initial command fetches a few packages needed by the build-common.xml. Mostly likely you’ll see emma and junit in this list; I haven’t seen any other dependencies yet. But, the build will quickly fail without these additional packages.

Depending on your machine, the build might take 10 minutes and it might take an hour (more power = faster) so grab a cup of coffee.

Configure and Startup

You need to provide a server configuration before starting up the wave server. You can do this as simply as:
ant -f server-config.xml to use all default values and generate a basic configuration file pointed to localhost:9898.
This works for some, but with Openstack this probably doesn’t get you the needed results. Assuming that you’re using both a fixed_ip and a floating_ip for your VM, you’ll get “unable to bind” exceptions if you try to start up the server configured to bind the floating_ip as the application’s public IP address. But, because Openstack already NATs the fixed and floating IPs, you can give this config file the VM’s fixed IP address and “it’ll work”.

Instead, you can use a few extra parameters to set additional values:
ant -f server-config.xml -Dwave_server_domain=(domain) -Dhttp_frontend_address=(VM's fixed private IP):9898 -Dhttp_websocket_presented_address=(VM's floating IP):9898

Once that is done, you’re ready to fire it up! In the trunk directory:
$> ./run-server.sh &
will start the server. I like to include the & to run it as a background process. You should be able to navigate to the VM floating_ip:9898 and get a login page.

Final Thoughts

There are additional fields in server.config that you’ll want to set. Minimally, you want to configure the admin_user field, and then register that user for an account. If you’re feeling adventurous, you can convert the data storage from files to mongodb.

Hope this has been helpful.

Setting up Additional Swap Space for Oracle on Openstack VMs

One of the Openstack flavors I administer is a “database-sized” flavor suitable for running an Oracle RDBM installation. It carries 16GB of RAM with it, but the base OS image only has 2GB of swap space. Oracle recommends 16GB swap for 16GB of RAM. If you’re reading this, you probably already know that, so on with how to create the new swapfile area…

You’ll need ephemeral disk as part of your VM instance. If you don’t have it, I’m not sure if this will work because I’ve not tried it, but it seems unlikely. As a side note, you won’t likely have good success trying to use NFS-layer storage as a physical device; that’s not what it’s designed for and, if you do somehow make it work, the context switching involved with 4kB pagesizes might be a nightmare on your VM host’s NAT gateway. Ymmv; I don’t recommend it.

1. Install LVM if you don’t already have it.
sudo apt-get install lvm2

2. Create a physical volume from the ephemeral disk
In the instances I typically run, the root HDD is /dev/vda and the ephemeral disk is /dev/vdb. We’ll make a physical volume of /dev/vdb.

sudo pvcreate /dev/vdb
If you want to limit the volume size, use the –setphysicalVolumeSize flag. There are other options via the –help flag if desired. You can check your work after the fact by using pvscan.

3. Create a volume group using LVM.
LVM is a powerful shell for managing logical devices. If you’ve never used it, enter the LVM shell with the lvm command and look at the help options. To create a volume group, this simple syntax does the trick:
vgcreate vg0 /dev/vdb

This creates a volume group named vg0 from physical device /dev/vdb. You can apply other options here if desired; if you’re unsure on executing the command, you can always use the --test flag the first time through to see what would happen.

4. Create a swap volume in the volume group.
Using the volume group that was just created — in this case vg0 — we now need to create a swap volume that brings our total swap space up to 16GB. In my example, I already had 2GB of swap space, so I need a 14GB volume. This command creates a volume named swapvol from /dev/vdb inside volume group vg0
lvm> lvcreate --size 14G --name swapvol vg0 /dev/vdb

5. Format the swap volume as swap.
Now that there’s a logical container dedicated for usage as swap space, it needs to be formatted as such.
The –check flag in this command will scan for bad blocks before creating the space. You can omit it if desired but I generally recommend using it.
mkswap --check /dev/vg0/swapvol

The result of this command should also add an entry into /etc/fstab for the new swap space. You should verify this by looking for the entry. cat /etc/fstab

If there’s not an entry, you need to add one before proceeding to the next step. I’m assuming that you know how to do that; google is your friend if not, sorry.

6. Turn the swap space on.
swapon is the general command for managing page/swap files. Its counterpart is swapoff. In the command below, the -v flag provides verbose output; the -a flag marks all swap devices in /etc/fstab as available (no effect on currently-available devices). The -a flag won’t work if, for some reason, your /etc/fstab entry includes the noauto property in the mount options.
swapon -va

Verify the amount of swap space available has risen to 16GB and you are home free:
free -g

How to run Jenkins as a different user

By default, the Jenkins app runs as user jenkins:jenkins.  This is sometimes well and good, but if you need to run shell commands from within Jenkins as part of a build, generally running the process with user jenkins as the owner causes permissions issues on the filesystem.  So, here is how to change the user that runs it.  I’m using CentOS 6.2.

The jenkins init script in /etc/init.d/jenkins exposes the $JENKINS_USER and $JENKINS_CONFIG environment variables.  While you could simply change the $JENKINS_USER variable within that script, it would be quite confusing to have a mismatch between what appears in the config file and what actually happens.  The correct place to change this is wherever the $JENKINS_CONFIG points.  By default it points to /etc/sysconfig/jenkins.

When editing JENKINS_USER within the Jenkins config file, right above that it warns you that you also need to fix ownership on /var/log/jenkins.  That’s true, but it’s not the whole story. This is what needs to be changed.  If your Jenkins instance is not installed to /var/lib, then adjust the path as needed.


chown -R user:group /var/lib/jenkins
chown -R user:group /var/log/jenkins
chown -R user:group /var/cache/jenkins

Once you’ve made those changes, a restart of Jenkins should change the user for you


service jenkins restart
ps -ef | grep jenkins