Thursday, November 24, 2011

Building CentOS 5.7 images for Amazon EC2

I'm new to Amazon's EC2 platform so I've struggled a bit with it as of late. I had been using Rightscale's excellent AMI's (thanks guys). But I ran into some performance issues with conference bridges and sipXecs (openUC) when running in AWS space. According to the Freeswitch mailing list performance should have been better than what I was experiencing (any sort of media services in a virtual environment will at some point experience some quality issues, don't expect otherwise).

To help get to the root of the problem I wanted to find a bare-bones CentOS 5.7 64 bit AMI that was EBS (elastic block storage - storage maintained when server is rebooted) vs. Instance storage (storage that's reset to the base image each time the server is shutdown or rebooted). Well, guess what... there wasn't a public AMI available. This left me with two options, try to adapt somebody else's image or build my own. Not being the trust-in-others type I went for the second option.

I'll spare the trials and tribulations of what I went through and get to exactly how I now build my images...

Overview

The basic process I am using is as follows:
  1. Build a CentOS 5.7 64 bit machine to create the image on (this machine is not imaged, just used to build the image on).
  2. Use modified Rightscale build script to build image and load to AWS
  3. Register AMI in AWS.
  4. Convert Instance Store AMI to EBS backed AMI
If anybody has a better process, by all means please let me know...

Build a CentOS 5.7 64 bit machine

So it simplifies the process a bit to build on the same machine type as you want to end up with. I build a box on my Citrix Xen Server with 4 processors, 4 GB of RAM and 60 GB of hard disk (you'll want enough storage because we're going to build a 10 GB image plus have a bunch of files on the disk for a short period).

In building the server I select CentOS 5 as my image type, use a CentOS DVD in the system drive but when the install procedure begins select install from http server. Josh Patten had a bit of an explanation about this in a sipXecs blog post. Also this information on using the CentOS netinstall feature is handy.

I build the box with base packages only (de-select Workstation and any other packages).

Once the machine boots, install ruby:

yum install ruby

Rightscale Script

So Rightscale has creating these Amazon AMI's down to a science. It's fully scripted and installs customization tweaks for their cloud platform. Luckily they posted their scripts (although I haven't been able to find the version 4 scripts). The original blog post I found referenced version 1 scripts and I worked on this a bit but I later found version 3 scripts:
These of course still loaded all of the Rightscale tweaks but it was a great place to start.

The script I ended up with is here: http://www.box.com/s/rmt719k3ayjf2yzk5sst

In the CentOS system you created initially create a folder called /root/ec2:

Login to the system as root.

cd /root
mkdir ec2

Then copy the script into that folder:

cd /root/ec2
wget http://www.box.com/s/rmt719k3ayjf2yzk5sst

Make the script executable:

chmod +x Cent5.0X86_64V3.0.0InstallMWP.sh

Execute the script:

./Cent5.0X86_64V3.0.0InstallMWP.sh

Then the following menu will appear:

Hello root, Lets get started installing CentOS 5
........................................
Please Select an Option or 8 to quit
0) Set EC2 Variables
1) Create and Mount Image
2) Installing Yum and CentOS 5 Base
3) Install Additional Packages
4) Install RightScale Customizations
5) Clean Up FileSystem and Bundle Image
6) Upload Image
7) Clean Up
8) Quit

Now it's a matter of stepping through each of the menu options.

Step 0 - Set EC2 Variables

Please Select an Option or 4 to quit
1) Set EC2 Variables
2) Show EC2 Variables
3) Set AWS Bucket, Image Name & Kernel ID
4) Back

You'll need to set the following EC2 Variables:

EC2_CERT=/root/ec2/etc/cert-xxxxxxxxxxxxxxxx.pem
EC2_HOME=/root/ec2
EC2_PRIVATE_KEY=/root/ec2/etc/pk-xxxxxxxxxxxxxxx.pem

The EC2 Cert and Private key are the X.509 Certificates associated with your AWS account (I've assumed you're already signed up). In the upper right of your AWS console, click on your account name drop down and select 'Security Credentials'. On that page under Access Credentials you'll see a tab for X.509 Certficates, click on that and Create a new certificate if you don't have one already then download the cert-xxxxxxxxxxxxxx.pem file and the private key pk-xxxxxxxxxxx.pem file and save to your computer. Then on your CentOS machine, create a /root/ec2/etc folder and copy the files there (I use winscp because I'm a Windows weenie sometimes).

AWS_ACCOUNT_NUMBER=

Your AWS Account Number is displayed on the 'Security Credentials' page in the upper right.

AWS_ACCESS_KEY_ID=
AWS_SECRET_ACCESS_KEY=

Your AWS Access Key ID and Secret Access Key are also available on the Security Credentials page under Access Credentials.

Now set the AWS Bucket, Image Name and Kernel ID

AWS_BUCKET=

The AWS Bucket is an S3 bucket that you must create in your AWS console prior to running this script. It is simply the bucket name.

IMAGE_NAME=

The Image Name is simply what you'd like to name this image. I avoided any noon alpha-numeric characters.

KERNEL_ID=

The Kernel ID is the Amazon Kernel ID you'd like to use. Amazon only allows certain kernels on their infrastructure.

The Current Amazon Kernel ID's for CentOS 5 (2.6.18) as of this writing are:

US region32-bit:
aki-f5c1219c
ari-dbc121b2

64-bit:
aki-e5c1218c
ari-e3c1218a

EU region
32-bit:
aki-966a41e2
ari-906a41e4

64-bit:
aki-aa6a41de
ari-946a41e0

I used aki-e5c1218c for my system.

Once you have all of the variables and bucket info setup, simply run down through menu options 1 - 8 to complete the process.

Register AMI in AWS

Ok, now with the Image fully loaded to your S3 bucket, now we can register the AMI in your AWS console. In the EC2 tab of the console, click on 'AMIs' under the Images section of the left side menu.

Now click on the 'Register New AMI' button. A Register Image dialog box will appear asking for the AMI Manifest Path. In the box enter your bucketname/imagename.manifest.xml

So if your bucket name was centos and your image name was centos5764 you would enter:

centos/centos5764.manifest.xml

Next, click the 'Register' button and your new AMI will be displayed as an AMI owned by you. It will be an Instance store at this point however.

Convert Instance Store AMI to EBS backed AMI

There are a number of web sites the explain how to create an EBS backed AMI from an Instance Store AMI. The process is basically to create a new EBS Volume, mount it in a running version of your instance store system, copy the instance store drive to the EBS volume.

I found a handy web site for doing this. The guys at CloudyScripts created a bunch of tools for working with cloud systems. The tool for making this conversion is here: https://cloudyscripts.com/tool/show/2

You'll want to create a separate Access Key (on the AWS Security Credentials Page) for your AWS account that you can disable / delete and a temporary account key pair (in your EC2 management console, left side menu at the bottom) that the service can use to log in to the AMI while it is working. Also, in the security group that you specify in the tool, you'll need to temporarily allow SSH access inbound from anywhere (0.0.0.0/0).

Conclusion

Hopefully I haven't left anything out. I went through quite a few days of pain to figure all of this out and end up with something that was very reusable by me. I hope others will find it useful!

Tuesday, March 22, 2011

Installing sipXecs / openUC from USB Memory Stick

Jim Canfield of EMStar Solutions posted this in the sipx-users mailing list and I thought I'd share it...

1. Download<>the Fedora *liveusb-creator-x-x.zip* and extract to your PC
2. Download<>the *sipxecs-4.2.1-100820-x86_64.iso*
3. Navigate to the *liveusb-creator-x-x* folder and click * liveusb-creator.exe* to launch the tool


1. Under *Use existing Live CD*, browse to where you saved the *
sipxecs-4.2.1-100820-x86_64.iso* and select it
2. Set the *Target Device* to point to your USB flash drive
3. Click *Create Live USB* to begin the creation process

ISSUES:

- SEE COMMENTS BELOW - sipxecs setup script is looking specifically for device CDROM during the install. I suggest using the CentOS netinstall method described in the comments section if you don't have a CDROM (or DVD for new 4.4 install).

- Depending on your bios, you may have to edit you grub.conf after install because the install will assume the USB drive is (hd0,0) and the primary hard drive is (hd1,0). To fix, simply edit on boot fail the first time, then edit grub.conf manually once booted. Press ENTER on the fail message, at the menu screen press 'e' and then 'e' again to edit the 'root(hd1,0)' line and change to 'root (hd0,0)', Press ENTER and then press 'b' to boot. After you boot, to edit grub.conf 'nano -w /etc/grub.conf' and change all references to 'root (hd1,0)' to 'root (hd0,0)'.

- Windows 7 users must "run as administrator"

Saturday, March 19, 2011

Java memory problems...

Java virtual machine running out of memory in sipXecs / openUC?

This will manafest itself as Configuration pages not loading and other
Java related errors...


Edit /usr/bin/sipxconfig.sh and change a command that looks like this:

exec $JavaCmd \
$SystemProps \
$JavaOpts \
$TrustStoreOpts \
$KeyStoreOpts \
-classpath "$Classpath" \
....

to one that looks like this:

exec $JavaCmd \
-XX:MaxPermSize=128M \
-Xmx1024m \
$SystemProps \
$JavaOpts \
$TrustStoreOpts \
$KeyStoreOpts \
-classpath "$Classpath" \
.....

That should increase the fixed memory allocated in the JVM...

Tuesday, February 8, 2011

Exchange 2010 / Lync

/rant

How did Microsoft manage to make Exchange 2010 such a pig?

Can you tell I'm a little frustrated? I'm trying to with with Exchange 2010 Unified Messaging to test out interoperability with sipXecs/openUC. I've been at this now for well over 2 days worth of time between installing and trying to get systems upgraded.

I'm trying to install Exchange 2010 SP1 at this point and the requirements are killing me. First off, stupid IE won't download anything on the 2008 R2 server so I have chrome installed on that box which works but you can't directly click on the pre-reqs in Microsoft's setup tool. The links don't come up correctly in Chrome. Ok, so I type them all in and get to the last one... Microsoft Speech Server Runtime. The freaking thing won't install because something else is in place. Well, MS in their wisdom upgraded another component that replaced this piece but the server needs this one installed in order to do the upgrade.

What happened to the nice simple days of Exchange 5.5? Man they've gone down hill with this product since then. At least 5.5 was manageable (even if the database puked once in a while, it was easy to fix).

I'm sure Lync will be much better to work with.... gack! No praise coming from this camp.

/rant

Thursday, January 20, 2011

Disaster Recovery & sipXecs

Wrote a blog post on Disaster Recovery & sipXecs over at sipFoundry.org web site...

Disaster Recovery & sipXecs

Wednesday, May 12, 2010

Capture Traffic on your sipXecs Server

Just a quick note on capturing traffic directly on the sipXecs PBX.

Personally, I'm a network guy and I like to use Wireshark to evaluate network traffic. Sure SipViewer shows you what the PBX is seeing for SIP traffic, but I want it all...

To capture directly on the sipXecs server, use the following command:

sipXecs: tcpdump -n -s 0 -i any -w filename.cap

Then you'll be able to use winscp to copy the file to your PC and open it with wireshark.



Saturday, May 1, 2010

sipXecs... the alternate build...

It's kind of like an alternate movie ending, or director's cut...

Douglas Hubler (aka, Lazyboy, aka, lazieburd) (Douglas' Blog) a long time sipXecs contributor and former Pingtel employee is offering up an alternative sipXecs build to the community build offered by Avaya.

Douglas has added back in some code that had 'disappeared' before 4.2.0 was released. Also, he is setting up build shop on the open suse build service which makes it easier to build for many other distributions. There are also some more builds for other distros than supported by the Avaya builds.

Basically the process to start using the new builds is to change your sipxecs.repo file and do a 'yum update'.

Backup your system and get the backup off of the PBX (the update does an in-place upgrade, but you can never be too safe).

Login to your sipXecs box as root and edit your sipxecs.repo file ('nano -w /etc/yum.repos.d/sipxecs.repo').

Comment out the existing sipXecs yum info with '#' in front of each line.

Add the following lines to the bottom of the repo:

[home_sipfoundry]
name=SIPfoundry sipXecs IP PBX Unified Communications Solution (CentOS_5)
type=rpm-md
baseurl=http://download.opensuse.org/repositories/home:/sipfoundry/CentOS_5/
gpgcheck=0
gpgkey=http://download.opensuse.org/repositories/home:/sipfoundry/CentOS_5/repodata/repomd.xml.key
enabled=1

The above is for a CentOS_5 distro... (ie., the sipXecs install from ISO). Check out http://download.opensuse.org/repositories/home:/sipfoundry for other builds. Builds are currently available in 32 bit and 64 bit for:

  • CentOS 5
  • Fedora 10, 11, 12
  • RHEL 5
  • Suse Enterprise Linux 10 & 11
  • openSuse 11.1 and 11.2

Once you have your .repo file setup properly, run a 'yum clean' and then a 'yum update' from the command line.

I rebooted my sipXecs box after the yum completed.

Big thanks to Douglas for the hard work he's putting in!


Sunday, April 25, 2010

A little off-topic... ok, a lot off topic...

Just finished re-writing a configuration I built for a Proxy server.

Proxy servers are a great way to tighten up your network security. Point all your users at the proxy server in their browser settings and allow only the proxy server to go out to the Internet in your inside interface firewall rules.

This example is built on CentOS 5.4 and utilizes squid, dansguardian, clamav and webmin. Daily downloads of malware and various blacklists are included.

Here's the build doc: SetupProxyServer.pdf

Very low overhead for this box. I built it on a single processor virtual machine with 512 MB RAM and a 10 GB virtual drive.

Some things I'd like to add include logging of userid to make logging a little nicer than just by IP address.

Friday, April 16, 2010

sipXecs 4.0.4 to 4.2.0 upgrade notes and impressions

Upgrade Notes:

Installed 4.0.4 fresh from ISO (dev build 4.1.7 on my test system was trashed).
Added a user / tested.
Fixed sipxecs.repo file replacing all '5.2' mirror references with '5'. (see previous blog post)
Ran YUM update from command line (265 items to be installed / upgraded, 374 MB worth).
Rebooted server.
A little patience was required on my relatively slow lab machine (800 MHz, Xeon w/1GB of RAM)... web services came up after a couple minutes.

Impressions:

New login screen is a little bland w/o graphic image.

Background job listed as failed on first login (problem listed as File replication: sipxpage.properties).
Created a paging group and re-sent the server profile and paging seemed to come up properly.

New GUI is better? different? I wish the tabs were starting from the left instead of centered.

Domain aliases of system IP address and host name are added automatically.

New user portal is nicer. Can't seem to import GMail contacts.

Branch concept in place... need to test.

Still no live attendant option as part of Auto Attendant.

Special Mode Auto Attendant configuration prominently available on Auto Attendants page.

GUI is much more sluggish on my dog of a test system (800 MHz, Xeon w/1GB of RAM)... time to upgrade I guess :-)

NTP server config in GUI is a nice add.

Alarm SNMP MIB now available on Alarm Configuration screen.

Alarm groups are now available for different notifications to different users (now including SMS and SNMP notification methods)

Much more but that's all I have time for at the moment...

Upgrading from sipXecs 4.0.4 to 4.2.0

One note that went across the mailing list (in case you missed it...).

Important Note on Upgrading:

There is a bug in 4.0.4 that breaks upgrading from the web user

interface. Specifically, it disables to use of the CentOS

repositories during the upgrade, which causes some prerequisites

to be unavailable, which makes the upgrade fail. The bug has

been fixed in 4.2 (and a bunch of other improvements to the

upgrade interface have been made too).


The best way to avoid the problem is to just do the upgrade from

the command line. Modify your yum repository configuration to

point to the repo where the 4.2 version is, and run 'yum

update', and when it's done, reboot.


I'm working on testing a 4.0.4 to 4.2.0 upgrade now.