Asterisk, and other worldly endeavours.

A blog by Leif Madsen

Rumors of my death have been greatly exaggerated

It’s been way too long since I’ve blogged. And this post isn’t going to be all the impressive unfortunately. However, I recently have been running a BBS and some friends and I have been playing LORD.

We’ve been playing this for the last few months, and I think I’m going to run a tournament. Perhaps with some sort of buy in like $10 or something, winner takes all.

Going to build it out in such a way that first person to beat the dragon 3 times will win the game, and at that point that person will win the pot.

Additionally, I’ve been reading a lot about the Go language and trying to get myself up to speed on that. Very interesting programming language. Essentially C but for concurrency (multiple processors).

I’m hoping to start blogging in the near future, but my current work has just kept me too busy and I haven’t really had anything all that worth of blogging about. I hope to start changing that around soon and get back to blogging on a semi-regular basis with things I’ve learned in the world of telecommunications and cloud platforms / virtualization.

Additionally, I don’t have any confirmation yet, but I’m pretty sure I’ll be attending AstriCon in Las Vegas this year. I’m going to figure it out either way, so hopefully i can meet up with some of you this year! The last few years I’ve just kind of mostly kept to myself and hung out with those I’ve met previously. I’m going to make a better attempt at reaching out to those I haven’t met before, so if you see me, come say hi please!

Written by Leif Madsen

2014/07/24 at 9:49 pm

Posted in Life, Musings

Asterisk: The Definitive Guide 4th Edition goes to print

Howdy folks,

Sorry for the lack of updates lately. I’ve recently (December 2012) started at Thinking Phone Networks as the Lead UC Systems Engineer, and we’ve been incredibly busy there. In addition, the authors and I had been working on the final touches to the 4th edition of Asterisk: The Definitive Guide, which documents Asterisk 11 LTS.

Late last week, the book went to print, and should start to appear on store shelves and start shipping from Amazon and other locations within the next 6-8 weeks I believe. However, if you’ve purchased the digital version, it’s already available!

I got mine from O’Reilly, and sync’d it to my Dropbox and shared it with my co-workers. There are usually deals around on Amazon and the O’Reilly website that will let you purchase both the digital and printed versions. The digital should be available immediately, with the printed version shipping as soon as it’s available.

Thanks to everyone who helped make the 4th edition a success, and to get it done in the last 8 months! It’s been quite the journey since the 1st edition was released in 2005.

Written by Leif Madsen

2013/05/16 at 8:31 am

Brother printer doesn’t print in Fedora 17

Tip: If your Brother printer won’t print after installing the drivers, install glibc.i686

Today ran into an issue with my new Brother MFC-7460DN (which is a really nice laser printer with auto-feed scanner, Scan-to-FTP which creates a PDF file, and other things). I had just recently done a clean install of Fedora 17, and I could install the RPMs (which are i386 files on my x86_64 based system), add the printer to CUPS and all sorts of things that looked fine.

However when I went to print, it wouldn’t error out, but the printer wouldn’t actually print. I tried changing a file per https://bbs.archlinux.org/viewtopic.php?pid=940524#p940524 but it didn’t help.

Then I found this post http://forums.fedoraforum.org/showthread.php?t=280753 which reminded me to install glibc.i686. Wish the Brother drives would just make that a dependency in the RPM.

Written by Leif Madsen

2012/11/24 at 5:06 pm

Posted in Technology

Tagged with , , , ,

Digium D40 and D70 Phone Unboxing

Today I received a couple of phones from Digium; the D40 and D70. I’ll be using these phones for testing and documentation in the 4th edition of Asterisk: The Definitive Guide (which Jim Van Meggelen, Russell Bryant and myself are working on right now).

Here is my unboxing of the phones and some commentary about my initial impressions of the hardware itself.

Pretty boxes!

Phones arrived in some nice looking boxes.

Digium D40

Comes with a little pamphlet to help you get the phones setup on your network.

Comes with all the little things you need to get the phone up and running, including a network cable. I was just using POE to power the phone, so I didn’t end up with the 5VDC power adapter.

Nice looking base. Easy to put onto the phone. Just uses friction to hold the phones on the base. Not sure how well that’ll work over time, but this isn’t something that should be getting attached and detached a lot. The space for cables in the base is also quite large.

Holes to mount to wall. Requires adapter.

Easy access!

Lots of space for my hand to plug in cables. Much nicer than any of the Polycom bases where I usually give up and just remove it.

Boot screen

Booting up with the Digium logo.

Handset hook access

The tab on the back here is well designed so that you don’t require a tool to pull out and flip around. I prefer to have the hook for the handset so it doesn’t fall off the base easily. On the Polycoms (which have the same type of setup) it’s nearly impossible to remove with your fingers

D40 vs IP335 size comparison

.Size comparison between the D40 and IP335.

Digium D70

Open box

Hidden compartment

Back of the D70


I don’t quite get the base with the wall mount holes, but impossible mounting angles on the base. Must have something to do with the manufacturing process and not having separate molds for footing.

Update: Michael pointed out that the A-frame is actually two separate pieces, so with a (separately purchased) piece, you can attach it to the base and make the system wall mountable. With the number of phones I’ve actually wall mounted in deployments (I think the number is only one or two), I think I prefer the 2 options for steep and shallow angles. Neat idea.

Side cut outs for cables that I didn’t even notice the first time through. Michael pointed out they are for cable management. Nice!

Oh my! So much space! Very roomy :)
Side by side comparison of the D70 vs the IP650 w/ sidecar.
Front to back comparison of the D70 vs IP650 w/ sidecar.

Written by Leif Madsen

2012/10/11 at 3:43 pm

Posted in Asterisk, Musings

Tagged with , , , , ,

Selecting Chef Servers With Environment Variables

Today I got playing around with dynamically selecting different chef servers in preparation for migrating some of our nodes away from our chef-dev server to our chef-live server (which I’m currently in the process of building and populating with data). I had been talking in the #chef IRC channel a few weeks back about making things dynamic, or at least easily switchable, when using multiple chef servers for different groups of servers in an environment.

What I want to do, is be able to set an environment variable at my console in order to switch between chef servers. Previously I had been doing this with different files in my ~/.chef/ directory and changing symlinks between the files. This method works, but is kind of annoying. So with the help of some of the folks in #chef, and with this gist of a sample file that someone is using for their hosted chef environment, I was able to build my own knife.rb and commit it to our chef.git repository.

In our chef.git repository, I created a directory .chef and placed a knife.rb file in it:

$ cd ~/src/chef-repo
$ mkdir .chef
$ touch .chef/knife.rb

I then filled knife.rb with the following contents:

current_dir = File.dirname(__FILE__)

sys_user = ENV["USER"]

log_level                :info
log_location             STDOUT
node_name                sys_user
client_key               "#{ENV["HOME"]}/.chef/#{ENV["KNIFE_ENV"]}/#{ENV["USER"]}.pem"
validation_client_name   "chef-validator"
validation_key           "#{ENV["HOME"]}/.chef/#{ENV["KNIFE_ENV"]}/validator.pem"
chef_server_url          "http://chef-#{ENV["KNIFE_ENV"]}.shifteight.org:4000"
cache_type               'BasicFile'
cache_options( :path => "#{ENV['HOME']}/.chef/checksums" )
cookbook_path            [ "#{current_dir}/../cookbooks", "#{current_dir}/../site-cookbooks" ]

The main key is the KNIFE_ENV environment variable which I set using: export KNIFE_ENV=dev or export KNIFE_ENV=live

After setting the environment variable, which server I’m using is selected for me. Additionally, I copied my validation.pem and client.pem files into corresponding directories in my ~/.chef/ directory: $ mkdir ~/.chef/{live,dev}

With all that done, I can now easily switch between our different servers in order to start the migration of our nodes. (I might create another blog post about that in the future if I get a chance.)

“BUT HOW DO I KNOW WHICH ENVIRONMENT I’M WORKING WITH?!?!?!”, you say? Oh fancy this little PS1 and function I added to my ~/.bashrc file:

if [ "$KNIFE_ENV" == "" ]; then
 export KNIFE_ENV="dev"
fi

function which_env {
  if [ "$KNIFE_ENV" == "live" ]; then
    echo "31"
  else
    echo "32"
  fi
}

export PS1='[\u@\h \[\033[0;36m\]\W$(__git_ps1 "\[\033[0m\]\[\033[0;33m\](%s) \[\033[0;`which_env`m\]~$KNIFE_ENV~")\[\033[0m\]]\$ '

Is nice :)

Written by Leif Madsen

2012/08/22 at 1:49 pm

Posted in DevOps

Tagged with , , , , , ,

CentOS 5.8 On AWS EC2 With Xen Kernel (PVGRUB)

At CoreDial we’ve been using a lot of AWS EC2 lately for building sandbox infrastructure for testing. Part of the infrastructure is a voice platform utilizing Asterisk 1.4 and 1.8, and those voice platforms are using Zaptel and DAHDI respectively for use with MeetMe(). This hasn’t been an issue previously as our testing has either been on bare metal, or in other virtual machine systems where installation of a base image and standard kernel are not an issue.

However, with the introduction of a lot of EC2 instances in our testing process, we ran into issues with building our own DAHDI RPMs since there aren’t any EC2 kernel development packages outside of OpenSuSE (which we don’t use). After spending a day of trying to hack around it, Kevin found a PDF from Amazon that states AWS now supports the ability to load your own kernels via PVGRUB. Great! If I can do that, then I can just continue using the same RPMs I’d be building anyways (albeit the xen based kernel, but that’s easy to do in the spec file).

Unfortunately this was not nearly as trivial and simple as it appeared at first. The first problem was that I had to figure out the correct magic kernel AKI that needed to be loaded, and the PDF wasn’t incredibly clear about which one to use. (There is two different styles of the AKI, one called “hd0″ and another called “hd00″ which I’ll get into shortly.) After searching Google and looking through several forum posts and other blogs (linked at the end), I finally found a combination that seems to work for our imported CentOS 5.8 base image. Below is a list of the steps I executed after loading up an image from our base AMI:

  • yum install grub kernel-xen kernel-xen-devel
  • grub-install /dev/sda
  • cd /boot/
  • mkinitrd -f -v –allow-missing –builtin uhci-hcd –builtin ohci-hcd –builtin ehci-hcd –preload xennet –preload xenblk –preload dm-mod –preload linear –force-lvm-probe /boot/initrd-2.6.18-308.13.1.el5xen.img 2.6.18-308.13.1.el5xen
  • touch /boot/grub/menu.lst
  • cat /boot/grub/menu.lst
default 0
timeout 1

title EC2
     root (hd0)
     kernel /boot/vmlinuz-2.6.18-308.11.1.el5xen root=/dev/sda1
     initrd /boot/initrd-2.6.18-308.11.1.el5xen.img

Once the changes were made to the image, I took a snapshot of the running instances volume. I then created an image from the snapshot. When creating the image, I selected a new kernel ID. The kernel ID’s for the various zones and architectures are listed in the PDF. As our base image was CentOS 5.8 i386 in the us-east-1 zone, I had to select between either aki‐4c7d9525 or aki‐407d9529. The paragraph above seems to indicate there is a difference based on what type of machine you’re using, and references S3 or EBS based images. We are using EBS based images, so I tried the first one, which in the end failed miserably. After reading through the IonCannon blog post it became clear that the hd0 and hd00 AKIs are really differences in whether you have a single partition, or multiple partitions with a separate /boot/ partition.

With that bit of knowledge, and knowing that we only had a single partition that contained our /boot/ directory, I knew to use aki-407d9529 (hd0). Another forum post also pointed out that I needed to enable some modules for the xen kernel or the system wouldn’t boot (and I verified that by stepping through each of the steps listed above to make sure it was required). With those two major items checked off, I am now able to build an AMI that will load with a stock CentOS Xen kernel image, making it trivial to build RPMs against now.

Note: If you do happen to use separate partitions, make sure you use the hd00 AKI. In the menu.lst you need to make sure to use root (hd0,0) instead of just (hd0). Additionally, your menu.lst file needs to live at /boot/boot/grub/menu.lst since AWS is going to look in the /boot/grub/menu.lst location on the /boot/ partition. On a single partition the file can just live at /boot/grub/menu.lst.

References

Written by Leif Madsen

2012/08/22 at 9:10 am

Assign unique hostname to dhcp client with dnsmasq

Today I’ve been getting our lab environment setup with vagrant to auto-provision our lab servers with chef server in order to allow the development team to quickly and easily turn up and tear down web application servers.

Because when the server gets spun up with vagrant, it registers itself as a new node to the chef server using its hostname. Since using localhost for every node pretty much makes the chef server useless for more than 1 virtual machine at a time, I needed to figure out how to get dnsmasq to assign a unique hostname based on the IP address being provided by dnsmasq to the dhcp client.

I had seen a similar thing done with Amazon EC2 instances that when they turn up, they gets a hostname that looks similar to the private IP address it has been assigned. For example, if the private IP address assigned to the server was 192.168.12.14 it would get a hostname like ip-192-168-12-14. I wanted to do a similar thing with our server.

After a little bit of Googling and reading the dnsmasq configuration file, it donned on me how simple this really was. You simply need to define the hostnames that the dnsmasq server could assign to a server, list those in the /etc/hosts file on the dnsmasq server, and then define the hostname you wanted to provide to the server. I didn’t want to use the MAC address of the servers (a la dhcp-host option) since the MAC address will be dynamic each time I spin up a virtual machine.

So in my dnsmasq.conf file I might have something defined like

dhcp-range=90.100.1.120,90.100.1.124,24h

 

So in my /etc/hosts file I’d just place the following to assign those unique hostnames:

90.100.1.120    ip-90-100-1-120
90.100.1.121    ip-90-100-1-121
90.100.1.122    ip-90-100-1-122
90.100.1.123    ip-90-100-1-123
90.100.1.124    ip-90-100-1-124

Written by Leif Madsen

2012/07/23 at 2:14 pm

Follow

Get every new post delivered to your Inbox.

Join 1,970 other followers