Yes. I admit it. I created a zombie. Very recently in fact. It was ugly (embarrassingly so) and, like all zombies, very hard to kill once it had been created.
No, this is not an excerpt from a Bela Lugosi movie â€“ I refer to something far more horrifying. A zombie session in CCXML.
The route to avoiding zombie sessions is pretty straightforward â€“ just follow the rules, set up your handlers properly and all will be well. Occasionally, however, mistakes are made and applications are not tested as thoroughly as they should be.
So as some self imposed penance, I’ve decided to list some tried and true methods for avoiding zombie sessions. Nothing new here, but it helps to go over this stuff every once in a while.
Always <exit> properly
When catching errors, be very careful not to get fancy, especially with a handler that is meant to catch multiple types of errors.
Some people try and get cute here, and execute logic inside this transition â€“ be very careful. If the logic has an error in it, you will enter a loop and have a really bad day. I don’t even like to put log statements in this kind of transition. Log files are generally verbose enough to tell you what the problem is.
Order <transition>s carefully
When a CCXML file is executed, <transition> elements are executed in document order â€“ even though a more appropriate <transition> for an event exists in a document, the CCXML platform will execute the first <transition> that matches the event/condition in document order. So, even though you place your catch all error handler (like the one above) at the end of your file, if you have another problem in a different <transition>, it may never get executed. For example, consider the following:
<log expr=â€’This log statement has an error’â€>
<!– A semantic error in another part of my CCXML app will get me stuck here –>
Set up your zombie killer in advance
Make it standard practice to send an event to the currently running session when the page loads to close things down after a certain period of time if the session doesn’t end normally.
<transition state=”‘initial'” event=”ccxml.loaded”>
<send event=”‘sessionEnd'” target=”session.id” delay=”‘600s'”/>
Test. Test again. Test some more…
The best way to ensure that your not going to create some zombie sessions (or do anything else really stupid) is to test thoroughly.
The best way to do this â€“ in my humble opinion â€“ is to download a copy of Voxeo Prophecy and use it to develop your application. You can use Prophecy to test your application in your own environment before moving it to Voxeo hosting, or upgrading to a production version of Prophecy to run your app.
Be careful. Follow these steps. Avoid all zombies. Good luck!
Once you’ve got your Trixbox all set up, you need to think about backups â€“ what happens if your system needs to be restored, or if you’re doing and upgrade (say from version 2.0 to 2.2)?
The FreePBX module in Trixbox has a handy â€œSystem Backupâ€ feature â€“ in FreePBX, go to Tools->Backup & Restore.
Click on the â€œAdd Backup Scheduleâ€ link and name your new schedule â€“ I personally take the simple approach of just doing a weekly backup on Sunday night.
When your backup is created, Trixbox places a â€œ.tar.gzâ€ file in the /var/lib/asterisk/backups/ directory. So, if you created a schedule called â€œWeeklyâ€ your backup file would be placed in the directory /var/lib/asterisk/backups/Weekly/. Here these files will stay â€“ a new one is created each time your scheduled backup is run â€“ unless you do something with them.
For obvious reasons, we want to move these backup files to another server for safe keeping. Additionally, one we’ve successfully moved our backup, we want to clean up the old files from our backup directory.
There are any number of ways of doing this. Here is my preferred method:
Create a new user on your Trixbox machine, and add that user to the â€œasteriskâ€ group. (The user will need to be a part of this group to access the backups directory.)
useradd -G asterisk backup
Log in as this new user, and create a key pair for ssh connections. When prompted to enter a pass phrase, simply hit enter (blank pass phrase).
ssh-keygen -t dsa
Export your public key to the machine where you will be storing your backups.
scp ~/.ssh/id_dsa.pub firstname.lastname@example.org:.ssh/authorized_keys
Make sure you can SSH to the machine where you will store your back up files. You’ll want to make sure that key-based authentication is working (i.e., that your not prompted for a password).
Make sure you can securely copy files to the machine where you will store your back up files (again, make sure that your not prompted for a password).
scp /var/lib/asterisk/backups/Weekly/* email@example.com:trixbox_backups/
If all of the above steps went successfully, you are now ready to set up your automated process. We’ll use CRON to do this.
Log on as the new backup user on your Trixbox machine.
Create a new crontab for this user.
Insert cron entries to copy backup files to the remote machine, and to clean up old files after they have been moved.
01 0 * * 1 scp /var/lib/asterisk/backups/Weekly/* firstname.lastname@example.org:trixbox_backups/
01 1 * * 1 rm -f /var/lib/asterisk/backups/Weekly/*
The first entry will move our weekly backup file at 12:01 a.m. on Monday morning to our remote server. The second entry will clear the Weekly directory an hour later. This way, when you go to the office on Monday, all of your backup process are done and your ready to start the week on a good note.
In the next article, we’ll discuss how to monitor your Trixbox to make sure that it is performing properly.
Great article on the current state of software patents and the need for fundamental patent reform, specifically as it relates to software.
Today I’ll start a series that I’ve been meaning to commit to writing for some time. The top 5 things to do after you finish installing Trixbox.
Trixbox 2.2 is now out, so if you’ve ever thought about setting up your own VoIP system I would strongly recommend giving Trixbox a try. The Trixbox forums provide a wealth of information, and there is some documentation available from the Trixbox project itself. However, most of the documentation focuses on the installation process, and does not provide a whole lot of information about what to do after your system is installed and running.
With this in mind, I’d like to share some of the things that I think are important to ensuring that your Trixbox system is running smoothly (and securely).
First things first — we need to lock down SSH.
If your not familiar with SSH, you should brush up on this remote connection method. Right out of the gate SSH is a more secure way of connecting to a Linux machine than alternatives like Telnet, but that doesn’t mean it’s perfect.
At a minimum, the following steps should be taken to improve SSH security:
- Run SSH on an alternate port (the default is port 22).
- Only use the SSH 2 protocol (SSH 1 is not as secure as 2)
- Do not allow root logins via SSH (in fact, it’s a much better approach to only allow specifically named users to log in via SSH, but never root).
- Use public key authentication, instead of passwords.
There are a number of other helpful tips and tricks available here.
Next up, we’ll walk through the process of backing up a Trixbox system and transferring the backup to a remote machine using scp and cron.
Recently came across some information from a small city in Mississippi that is using Asterisk/Trixbox for it’s internal phone system.
Vicksburg is a city of about 26,000 in Western Mississippi that looks to have a roughly 200 extension Asterisk system in place for city employees.
It’s nice to see governments making use of open source technologies, particularly Asterisk — it isn’t just for small businesses. I wonder how many other small to medium sized governments are using a flavor of Asterisk for their phone systems?
One of the very first jobs I had after getting my undergraduate degree was working on a political campaign. I learned first hand how tight campaigns can be with money â€“ I was paid next to nothing for countless hours of work. Lack of dough notwithstanding, I learned a lot and it opened up a number of opportunities for me down the road.
This first experience was a few years before websites started to be used in political campaigns (hope I didn’t date myself there). These days, having a campaign website is a requirement. Still, I’m always amazed at how campaigns choose to invest â€“ in terms of both money and time â€“ in their websites.
There are plenty of ways to stand up a quality web site with a small outlay of actual dollars. Clearly the prorogation of open source software has helped in this regard. I currently volunteer for a campaign that has built it’s website on the LAMP stack. We use the phenomenally useful PHP blogging platform WordPress for our site. WordPress comes with an active community that contributes a wealth of different plugins that are available to do almost anything a campaign (or any other kind of endeavor) could need.
But investment of dollars is only part of the equation. Anyone that works on a campaign website needs to be aware of security issues (at least the obvious ones), and must take steps to mitigate risks. This is the part that is so often missed, even by campings with deep pockets.
I had occasion recently to peruse the website of an elected official rumored to be interested in the same job my candidate is running for. Within about 2 minutes of looking at the site I happened upon a gaping security hole that looked like it was exposing sensitive information for the official in question, and a bunch of other campaigns. I have no idea how long the hole existed, or if anyone else happened upon it.
Based on what I saw, the issue in question could probably be fixed with a one line change to the servers’ Apache configuration file. The server with the gaping hole is maintained by a third-party company that claims to be a leader in supporting campaigns through the use of technology. The lesson here â€“ ask your consultants about security, and if needed get an objective outside opinion. This doesn’t cost much (if anything) but does require some time and attention.
Fortunately for the official in question, my candidate likes a fair fight. Our campaign contacted the other candidate with information on the security hole, and suggestions for how to work with their consultant to get it fixed. Hopefully, they’ll do this soon.
I’d like to think this will get us some good karma down the road in the event that the campaign gets ugly â€“ we’ll see…