Tuesday, February 17, 2015

Goodbye SIPfoundry / sipXecs, Hello sipXcom!

Based on increasing difficulties working with project leadership at SIPfoundry, eZuce will no longer be supporting the sipXecs project at SIPfoundry.  We plan however to continue our support for open source communications projects. It has been a very productive five years and we have supported the community diligently during this time. It has certainly been an amazing journey from where the product was in 2010 at version 4.2 to where it is today with release 14.10. This past year we continued our support with 14.04 and 14.10 releases despite comments by SIPfoundry leadership in recent months.

Where do we go from here?

eZuce has created a new organization in Github called sipXcom and forked all of the sipXecs project repositories. All of the sipFoundry licensing of course remains in place for all the existing code so as to honor the copy left requirements from the AGPL3 license. Additional fixes will be freely available in sipXcom repositories.

The experts who have helped to build sipXecs into the incredible product that it is will be found in the Google Groups sipxcom-users@googlegroups.com (https://groups.google.com/d/forum/sipxcom-users) and sipxcom-dev@googlegroups.com (https://groups.google.com/d/forum/sipxcom-dev). We invite the rest of the sipX-users and sipX-dev mailing list users to join us there.

eZuce employees will not be participating in the sipX-users or sipX-dev mailing lists from this point forward. Unfortunately we'll lose some mailing list history with this move, but the search and indeed the entire mailing list has been a mess for quite a while anyway.

We'll be publishing update 4 soon for 14.04. And update 1 to 14.10 with a couple fixes that need to get in there. RPM's and ISO's will be available at http://download.sipxcom.org. Moving forward from the 15.04 release in April, we'll be publishing monthly releases (15.05, 15.06, 15.07, etc.).

A new project page will be available at http://www.sipxcom.org.

With so many of us who have so much energy and time invested, its with sad hearts that we leave sipFoundry and sipXecs behind.

However, we have great optimism for the future with sipXcom and we are very excited about our next generation open source communications project.  Please join us.

Sincerely,
  Mike

Convert .key/.crt to pem for use with AWS

I always have to look this up...  hence the post here...

Even though you might have a key file in text form, it won't work with AWS if you need to connect from ssh command line (keys work fine from Putty / WinSCP).

To convert a key file you also need the crt file.

Here's how from Mac / Linux command line:

openssl rsa -in server.key -text > private.pem
openssl x509 -inform PEM -in server.crt > public.pem

Once you have the pem, don't forget to:

chmod 600 public.pem

Otherwise you won't be able to use it to ssh to AWS.

Wednesday, December 24, 2014

Logitech K810 Keyboard on Fedora

Alright, so just randomness...

Replaced my Ubuntu 14.10 installation (weird things with video drivers and performance going downhill...  basically, time for a rebuild) with Fedora 21 Workstation.

I use a Logitech K810 Bluetooth Keyboard with my laptop (Samsung Series 5 Ultra) when at my desk.  And like with Ubuntu it didn't work out of the box (everything else did on Fedora, including suspend! great job Fedora team!).

Reports that this keyboard doesn't work in Linux are hogwash.

Found this article that pertained to Ubuntu: http://programsketches.org/?p=6

For my system I did the following:

hcitool dev

mine is hci0, so next I disable ssmpmode:

sudo hciconfig hci0 sspmode 0

To re-enable it, replace the 0 with a 1 in the above command.

Verify that it is disabled:

hciconfig hci0 sspmode

This include the text in the output:

Simple Pairing mode: Disabled

Attempt to pair the keyboard by holding down one of the 3 Bluetooth buttons until it flashes.

Go to Bluetooth settings in the drop-down menu in the upper right of the screen.  Connect to the keyboard and a code will be presented to connect the device.  Enter that code on the keyboard and your keyboard should be working.








Friday, May 2, 2014

WebRTC Updates

Exciting updates from the WebRTC / Chrome Team: https://www.youtube.com/watch?v=DvzDzIXoncg

Refinement, refinement, refinement.  Plus WebRTC on iOS news!

Interestingly they bring up Jitsi...

WebRTC Sample repo is now on github: http://github.com/GoogleChrome/webrtc



Wednesday, August 15, 2012

Restarting Services in openUC / sipXecs 4.6

Restarting services in openUC and sipXecs 4.6 has totally changed.  Gone is the use of 'sipxproc -R xxxxx'.

All services can be started/stopped/restarted from command line with '/etc/init.d/xxxxxx start/stop/restart'.

The services can be found with 'ls /etc/init.d'.

For instance, to restart sipxbridge:
   /etc/init.d/sipxbridge restart

Tuesday, June 12, 2012

Create a Larger Boot Disk Amazon Linux AMI

I know these last couple posts don't have a lot to do with sipXecs but I thought I'd share a few of the Amazon AWS tips I've been accumulating.


Sometimes you just need more than the 8 GB EBS volume that Amazon provides with Amazon Linux.  Sure you can just create another volume and attach it somewhere, but sometime it’s just easier to have one big drive.

The following instructions are used to create a 64 bit Amazon Linux AMI with a boot drive up to 1 TB in size.

Servers can then be rapidly deployed from your new custom AMI.

Create Base System

Starting from
AMI:amzn-ami-pv-2012.03.1.x86_64-ebs (ami-e565ba8c)

Launch a new instance.

If you’d like, login and update system
SSH to new Instance with key, login as ec2-user
sudo sh
yum update
shutdown -h now

Build AMI

In EC2 console create a snapshot of the root EBS volume.

Create an ESB volume from that snapshot with the new desired size. (Please ensure it is in the same Availability Zone as the instance)

Detach the root 8 GB EBS volume and attach the newly created EBS volume to /dev/sda1 on the instance.

Start the instance and then login.

Resize the disk to get the rest of the expanded disk
sudo resize2fs /dev/sda1

From the EC2 console, click on the Instance and Create AMI from the running Instance.

There you have it!

Saturday, June 9, 2012

Build your own cloud hosted mail service... Zimbra in AWS


Install Zimbra 7.2 in Amazon Web Services on Amazon Linux (or CentOS 6)

Notes

Creating an AWS instance in normal AWS space and stopping and starting a server will have profound repercussions if:
The AMI used is Instance Store - Drive image reset (all data lost)
The Instance is not in VPC - Internal IP assigned to server will change

VPC = Virtual Private Cloud

Setup VPC

Login to the AWS Console

Click on VPC tab.

Click on VPC Dashboard

Create a VPC with Single Public Subnet Only (default option)

VPC Defaults to 10.0.0.0/16 network space with the server within 10.0.0.0/24.

Note which availability zone the VPC subnet was created in (in VPC tab, see subnets on left side menu)

To add a server to the VPC, click on Launch EC2 Instances which will take you back to the EC2 tab.  When you create your host following, make sure that it is in the proper availability zone.

Setup VPC Firewall

Allow the following ports to host (create a security group if you don’t have one already).

TCP Ports

80, 443, 22 (restrict from address to known hosts), 25, 110, 143, 993, 995, 7071

Configure DNS

Configure DNS A-Record for your host in your Internet Facing DNS service
elastic.ip.addr.ess    A      mail.yourdomain

Configure MX Record for your mail domain
yourdomain     MX     10    mail.yourdomain

Setup local bind server to resolve ‘yourdomain’ to internal IP addresses.
yum install bind

Modify /etc/named.conf to load a custom zone file:
nano -w /etc/named.conf

Add forwarders section in ‘options’ to forward to AWS DNS servers (typically .2 in your VPC ip range, mine is 172.30.1.2 in my example below and my server is 172.30.1.10).  Just put this as the last line in the options { ... } section:
forwarders { 172.30.1.2; };     

Add the zone file settings:
zone "yourmaildomain" {
       type master;
       file "yourmaildomain.zone";
       allow-update { none; };
};

Create zone data file:
nano -w /var/named/yourdomain.zone

Your zone file should look as follows (change yourmaildomain to your email domain, my mail server host name is mail, so fqdn = mail.yourdomain) (also, change the IP to be the IP of your server in the AWS VPC):

$TTL 1800
@       IN     SOA    ns1.yourdomain. root.yourmaildomain. (
                      2012041902 ; serial#
                      1800            ; refresh, seconds
                      1800            ; retry, seconds
                      1800            ; expire, seconds
                      1800 )          ; minimum TTL, seconds

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; DNS Servers for 'zimbra.yourmaildomain’'
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;


yourmaildomain.            IN     NS     mail.yourmaildomain.

yourmaildomain.            MX     10       mail.yourmaildomain.

mail.yourmaildomain.       IN      A       172.30.1.10

Make sure DNS starts on server boot:
chkconfig named on

Reboot server and make sure DNS is started:
reboot

ssh back in...

service named status

Configure Server Name

Edit the hosts file:
nano -w /etc/hosts

Add a line that looks like:
ip.addr.ofserver.invpc     fqdn.of.server     hostnameofserver

The fqdn should match what you specified in the external DNS and the hostname is the part of the FQDN before the domain (I used ‘mail’ in the example above)

Edit the network file:
nano -w /etc/sysconfig/network

Modify HOSTNAME=fqdn.of.server


Modify Amazon VPC DHCP

Modify the Amazon VPC setup’s DHCP Server so that the local DNS server is handed out first.

VPC Management -> DHCP Options Sets

Create DHCP Options Set

Set domain-name = your mail domain

Set Domain-name-servers = ip.addr.of.host,amazondnsserver

(in my case the above two values were - 172.30.1.10, 172.30.1.2)

Your VPCs -> Check mark next to the VPC to modify, Change DHCP Options Set to new options set.

Setup Zimbra Host


Starting from
AMI:amzn-ami-pv-2012.03.1.x86_64-ebs (ami-e565ba8c)
(I’m use the East Region so this is mine... ymmv)

Launch a new instance.

Create a 20 GB EBS Volume (make sure it is created in the same AWS availability zone as the VPC subnet) and then Attach it to new instance (/dev/sdf)

Assign an elastic IP to the new server.

SSH to new Instance
login with ec2-user  and certificate

ssh -i key.pem ec2-user@elasticip

Sudo to sh
sudo sh

Mount new drive, format, copy /var folder to it, then mount it back to /var
mke2fs -F -j /dev/sdf
mkdir /mnt/ec2
mount /dev/sdf /mnt/ec2
cp -a /var/* /mnt/ec2
mount /dev/sdf /var
umount /mnt/ec2

Make system mount this volume every time
nano -w /etc/fstab

Add the following line to the bottom of the file:
/dev/sdf       /var      ext3    defaults    0   0

Continue with Installation & update Amazon Linux:
yum update

Reboot server to pickup updates.
reboot

SSH back into system
ssh -i key.pem ec2-user@elasticip

Login as root...
sudo sh

Install Zimbra

It’s important to make sure DNS is working right before this point...
dig yourmaildomain
dig yourmaildomain MX

Make sure this is being resolved locally...  LDAP stuff will mess up during install if you don’t do this.

SSH back into system
ssh -i key.pem ec2-user@elasticip

Login as root...
sudo sh

Change to root folder
cd /root

Download current Red Hat Enterprise Linux 6 RPM from http://www.zimbra.com/downloads/os-downloads.html


Unpack the file
tar xzvf zcs-7.2.0_GA_2669.RHEL6_64.20120410002025.tgz

Change to the directory created
cd zcs-7.2.0_GA_2669.RHEL6_64.20120410002025

Uninstall sendmail
yum erase sendmail

Fix sudoers file
nano -w /etc/sudoers

comment out ‘Defaults requiretty’

# Defaults requiretty

Fix for libstdc++
Create symbolic link to the following file :
ln -s /usr/lib64/libstdc++.so.6 /usr/lib/libstdc++.so.6

Start the Installation
./install.sh --platform-override

Set the admin password (menu option 3, and then menu option 4).

Enter ‘r’ to return to previous menu.

Enter ‘a’ to apply settings.

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...