Last week you enjoyed my kindly introduction to the newest entry in the Asterisk-based VoIP server appliance category, PBX in a Flash. Today the gloves come off—I’ve been pummeling it mercilessly on my test machine, and scribing a merciless, no-holds-barred review. It’s not that I like making grown developers cry. Well, actually I do. It’s easy and fun.
A different kind of installation
In these here modern times, installing anything Linux-based is as easy as falling
over, and so, barely worthy of mention. But PBX in a Flash takes an unusual
approach. The usual way to package a Linux-based software appliance is to bundle
everything on a single CD—the operating system and all the applications. PBX
in a Flash gives you CentOS Linux 5, which is my personal favorite for VoIP
servers, because it’s rock-solid, stable, and well maintained. Which it should
be, as it is a direct clone of Red Hat Enterprise Linux. RHEL, according to
and good manners, makes its source code readily available. The CentOS team take
the RHEL source code, remove all the trademarked bits such as branding and artwork,
and re-compile it as CentOS. Anyone can do this, so what makes CentOS special?
First of all, it’s not a trivial task to re-compile an entire Linux distribution. Then find and weed out the trademarked and any other proprietary bits, and create and add your own artwork. Then you need download servers, and someone to handle ongoing maintenance. The CentOS team deliver a fair bit of added value by applying upstream patches and updates swiftly, supplying their own documentation, and their own user forums and mailing lists.
Okay then, back to the PBX in a Flash difference. The installation CD gives
you CentOS, and then, instead of bundling all the additional applications that
you need for a VoIP server, you get a batch of installation scripts that download
and compile the applications on the fly. This is an unusual approach that I
don’t believe has been done by anyone else. Because the VoIP applications are
maintained separately from the operating system, this (presumably, depending
on the diligence of the developers) ensures that you always get updated applications.
So you need an Internet connection to perform the installation, and a local
DHCP server—and not be in a hurry. On my old Duron box (800 MHz CPU, 256 MB
RAM) and not-very-fast DSL it took about an hour and a half. That’s a pretty
feeble box for a VoIP server, but it’s fine for a test machine.
If your installation hangs at the partitioning page, re-start your installation and try running the text installer by entering linux text on the boot command line. The installation is mostly hands-off, but you will have to remove the CD when the CentOS portion of the installation is completed, or it will boot the CD again.
Log in and run the genzaptelconf script after the installation is completed. You need this to set up the ztdummy timing device, or any Zaptel hardware you’ve installed. By default this loads a bale of kernel modules you don’t need, which eats up memory, so you should first edit /etc/sysconfig/zaptel and comment out all the interfaces that you don’t have, except the TELEPHONY=yes line.
Then you must assign a static IP address to your server. As the helpful PBX in a Flash prompt tells you, run the help-pbx command to see all of the nifty custom scripts at your disposal. Use netconfig to assign a proper static address. (Unless, of course, you assign one from DHCP.) Now reboot and everything will come back up all nice and spiffy.
There is a good installation
guide, but it has a couple of items with which I must take issue:
On page 17 you are advised that when you’re configuring your network interface,
your default gateway and primary nameserver must not have the same address.
This depends on how your network is set up, so if they do have the same address,
don’t let these instructions derail you.
And now for a really big quibble, please refer to page 21, where you are advised
to not write down your passwords. I’m sorry, my fine PBX in a Flash persons,
but this is bad advice. This is what has created a generation of users and admins
who use the same password for everything in the world, and who create easily
guessed, easily cracked passwords. You should always write down your passwords,
on paper, and keep them in a safe place. This is how you sanely manage multiple,
properly-difficult passwords. Security guru Bruce
Schneier recommends this if you don’t want to take my word for it.
Come back next week and we’ll take PBX in a Flash out on the test track and burn some rubber.
Special bonus: Where-are-the-IAX phones followup
A couple weeks ago I lamented about the dearth of IAX hard phones, and the limited selection of IAX softphones. The always-helpful Bill Miller of Digium offered this explanation:
“Actually, there are several IAX soft phones, including one by Securax…
Zoiper (previously called Idefisk). There are several others but not sure if
those are still active. There are several IAX ATAs—Digium still makes the
IAXy, of course, and Googling turned up several others (ever heard of “Freshtel”?).
“Among the soft phones, though not are all in the “traditional” soft phone
format (for example the Java soft phone that Tim Panton of Mexuar has
done). There are also a number of low-cost Chinese and Taiwanese hard
phones based on the AR-1688 chip (an IC commonly used for low-end ATAs and
such). What does not exist at this point are business phones for IAX2.
To hazard a guess, the low uptake in the biz-phone world stems from the
limited market (only Asterisk and Asterisk-derived systems support IAX2
while EVERYTHING supports SIP), the state of the standard (currently only
an Internet Draft rather than a full RFC) and the complexity in layering
business features onto IAX2.”
Me, I think it’s because most vendors are running in packs, all fighting for the same slice of the market, instead of trying to take advantage of the wider possibilities. A lot of folks still look at Open Source the same way they look at snakes. But that’s just my $0.02.